From duke at openjdk.org  Wed May  1 00:01:52 2024
From: duke at openjdk.org (ExE Boss)
Date: Wed, 1 May 2024 00:01:52 GMT
Subject: RFR: 8331320: ClassFile API OutOfMemoryError with certain class
 files
In-Reply-To: <4TYCNDjryMTitN8tYklgk875gEWN8d-JrA-i5hLLW_A=.bdb5aa44-2a56-43fc-ae64-9737c54b6472@github.com>
References: <XGhWV1bHWk6QqxHcnJ5y85MocUoC0YUZVRIqz1z1vXA=.9d83f151-9e5c-4189-9327-f4ac10d484c5@github.com>
 <4TYCNDjryMTitN8tYklgk875gEWN8d-JrA-i5hLLW_A=.bdb5aa44-2a56-43fc-ae64-9737c54b6472@github.com>
Message-ID: <qU0Ngz-eTUmL-S0kUi4T_g08Hl0nxFCsOQDKoWXibRE=.217336b4-6d25-4c12-adf7-1c8d57a7539b@github.com>

On Tue, 30 Apr 2024 18:18:30 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>> Class files with specifically corrupted tableswitch or lookupswitch instructions in the bytecode cause OutOfMemoryError while parsing with Class-File API.
>> This patch performs additional checks to avoid OOME and adds relevant tests.
>> 
>> Please review.
>> 
>> Thank you,
>> Adam
>
> src/java.base/share/classes/jdk/internal/classfile/impl/AbstractInstruction.java line 320:
> 
>> 318:             int low = code.classReader.readInt(ap + 4);
>> 319:             int high = code.classReader.readInt(ap + 8);
>> 320:             if (high < low || high - low > code.codeLength >> 2) {
> 
> May be its also an opportunity to reduce duplication e.g., replace line 316 with a call to `afterPadding()`

`BoundTableSwitchInstruction?::afterPadding()` is?an?instance?method, and?`BoundTableSwitchInstruction?::size(?)` is?a?static?method, so?this would?require further?refactoring.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19024#discussion_r1585700103

From asemenyuk at openjdk.org  Wed May  1 00:05:11 2024
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Wed, 1 May 2024 00:05:11 GMT
Subject: RFR: 8331222: Malformed text in the jpackage doc page
Message-ID: <D3pV9xgZGB4YF99vE_kkYjD3yPbfcXYIcNNwRovFu_c=.22483620-b656-4f1e-b296-c5b0f99d222c@github.com>

Rerun pandoc on updated source man page file

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

Commit messages:
 - 8331222: Malformed text in the jpackage doc page

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

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

From almatvee at openjdk.org  Wed May  1 00:09:51 2024
From: almatvee at openjdk.org (Alexander Matveev)
Date: Wed, 1 May 2024 00:09:51 GMT
Subject: RFR: 8331222: Malformed text in the jpackage doc page
In-Reply-To: <D3pV9xgZGB4YF99vE_kkYjD3yPbfcXYIcNNwRovFu_c=.22483620-b656-4f1e-b296-c5b0f99d222c@github.com>
References: <D3pV9xgZGB4YF99vE_kkYjD3yPbfcXYIcNNwRovFu_c=.22483620-b656-4f1e-b296-c5b0f99d222c@github.com>
Message-ID: <ioShs5pESe3cMNUFHAL9K-DA6r-MwCMwy6mrw3hDaAo=.001343ef-e4d3-4c4c-9d4a-8244ed4b2ae1@github.com>

On Tue, 30 Apr 2024 23:58:49 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> Rerun pandoc on updated source man page file

Looks good.

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

Marked as reviewed by almatvee (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19028#pullrequestreview-2032839569

From prappo at openjdk.org  Wed May  1 09:45:53 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Wed, 1 May 2024 09:45:53 GMT
Subject: RFR: 8331427: Rename confusingly named
 ArraysSupport.signedHashCode
In-Reply-To: <2gE7ua7k3xeIWm0TL2TCFNtTYL7ZP19G61aGEn1VP0U=.73d54a23-23ae-4359-b298-3077a760ab6c@github.com>
References: <2gE7ua7k3xeIWm0TL2TCFNtTYL7ZP19G61aGEn1VP0U=.73d54a23-23ae-4359-b298-3077a760ab6c@github.com>
Message-ID: <SIz4GrOvXReXfC97PB0lfSLMvqo4i5xvFNlV1Bky-e4=.0ac8cf74-bb39-49cb-82f2-230107a10967@github.com>

On Tue, 30 Apr 2024 14:38:11 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> Please review this trivial method rename. While this issue was originally spotted in [another PR], it makes sense to address it separately. Test results are pending; not that I expect failures, but still.
> 
> [another PR]: https://github.com/openjdk/jdk/pull/14831#issuecomment-1655477396

Test results were ok.

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

PR Comment: https://git.openjdk.org/jdk/pull/19023#issuecomment-2088219397

From prappo at openjdk.org  Wed May  1 10:05:52 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Wed, 1 May 2024 10:05:52 GMT
Subject: RFR: 8278255: Add more warning text in ReentrantLock and
 ReentrantReadWriteLock [v2]
In-Reply-To: <FbeaxqsS5SF9koVG-pHExVNRoWir-4kmJgu6VaOEt1g=.3ff0eff0-a80d-44b3-b955-63fcf3693912@github.com>
References: <nb-F4YENhZMQth9RCQsvTAiiMEVnW-MKKJbe3NWWSgg=.86a1c9ab-c13b-4d37-8ef2-b495df14fa17@github.com>
 <ZjrjlUeRM-AtyH49lJMQPJkfad_MmEtWtS0n1gVPnkQ=.70f799bb-acb0-45ac-95c0-9001517128cd@github.com>
 <FbeaxqsS5SF9koVG-pHExVNRoWir-4kmJgu6VaOEt1g=.3ff0eff0-a80d-44b3-b955-63fcf3693912@github.com>
Message-ID: <1YLryRpwC2JhbJQqVYfQ-dn2TMm42U3nV3Ad6p52Hr0=.b6659fe2-37ec-46fb-afeb-b06b611070d6@github.com>

On Tue, 30 Apr 2024 19:41:54 GMT, Doug Lea <dl at openjdk.org> wrote:

> The grammar rules prefer "that" because it is a restrictive clause, even though "which" might sound better. See for example: https://owl.purdue.edu/owl/general_writing/grammar/that_vs_which.html

Thanks for that link, Doug.

I understand that two "that"s that are that close to each other might sound a bit weird. (Obviously, I exaggerated the issue in that preceding sentence.) Can we maybe rephrase it then?


 *     // If code could throw, make sure that it is executed inside try block

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

PR Comment: https://git.openjdk.org/jdk/pull/18974#issuecomment-2088240552

From vklang at openjdk.org  Wed May  1 10:58:53 2024
From: vklang at openjdk.org (Viktor Klang)
Date: Wed, 1 May 2024 10:58:53 GMT
Subject: RFR: 8278255: Add more warning text in ReentrantLock and
 ReentrantReadWriteLock [v2]
In-Reply-To: <ZjrjlUeRM-AtyH49lJMQPJkfad_MmEtWtS0n1gVPnkQ=.70f799bb-acb0-45ac-95c0-9001517128cd@github.com>
References: <nb-F4YENhZMQth9RCQsvTAiiMEVnW-MKKJbe3NWWSgg=.86a1c9ab-c13b-4d37-8ef2-b495df14fa17@github.com>
 <ZjrjlUeRM-AtyH49lJMQPJkfad_MmEtWtS0n1gVPnkQ=.70f799bb-acb0-45ac-95c0-9001517128cd@github.com>
Message-ID: <tVQJGKdyqf-njZG5OoCnYI8rsl54whp56Xh5VsVa8wM=.74f706ff-28ed-481b-a9f0-aa0261f77311@github.com>

On Sat, 27 Apr 2024 11:52:18 GMT, Viktor Klang <vklang at openjdk.org> wrote:

>> This is an attempt to be more clear about recommendations on Lock usage.
>
> Viktor Klang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update src/java.base/share/classes/java/util/concurrent/locks/ReentrantReadWriteLock.java
>   
>   Co-authored-by: Pavel Rappo <32523691+pavelrappo at users.noreply.github.com>

src/java.base/share/classes/java/util/concurrent/locks/ReentrantReadWriteLock.java line 162:

> 160:  *       }
> 161:  *     }
> 162:  *     // Make sure that code that could throw is executed inside the try block

@pavelrappo Or something like:

Suggestion:

 *     // Potentially throwing code should be placed inside the try block

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18974#discussion_r1586174747

From redestad at openjdk.org  Wed May  1 11:12:51 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Wed, 1 May 2024 11:12:51 GMT
Subject: RFR: 8331427: Rename confusingly named
 ArraysSupport.signedHashCode
In-Reply-To: <2gE7ua7k3xeIWm0TL2TCFNtTYL7ZP19G61aGEn1VP0U=.73d54a23-23ae-4359-b298-3077a760ab6c@github.com>
References: <2gE7ua7k3xeIWm0TL2TCFNtTYL7ZP19G61aGEn1VP0U=.73d54a23-23ae-4359-b298-3077a760ab6c@github.com>
Message-ID: <mpf8y2C3xETenyeW56KO5FrNSoy7UheBByf-WPqRnhI=.70c727ff-4119-4d83-b55d-b9ca0140c0b9@github.com>

On Tue, 30 Apr 2024 14:38:11 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> Please review this trivial method rename. While this issue was originally spotted in [another PR], it makes sense to address it separately. Test results are pending; not that I expect failures, but still.
> 
> [another PR]: https://github.com/openjdk/jdk/pull/14831#issuecomment-1655477396

Marked as reviewed by redestad (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/19023#pullrequestreview-2033464010

From jlahoda at openjdk.org  Wed May  1 12:23:40 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Wed, 1 May 2024 12:23:40 GMT
Subject: RFR: 8328481: Implement Module Imports [v13]
In-Reply-To: <qyvysdjU6Gx6waBESJl8_UoLbZtYmIaALDWzTzmee80=.c60cc9a8-2061-4c68-886c-57823084a941@github.com>
References: <qyvysdjU6Gx6waBESJl8_UoLbZtYmIaALDWzTzmee80=.c60cc9a8-2061-4c68-886c-57823084a941@github.com>
Message-ID: <p7IXqBQTq14EQ2O2Js-24jO8vJ7Ce2ijJGsu4SBijFQ=.365acb11-c8af-41e1-8767-ff62ed1443c4@github.com>

> This is an implementation of JEP JDK-8315129: Module Import Declarations (Preview). Please see the JEP for details:
> https://bugs.openjdk.org/browse/JDK-8315129
> 
> It is mostly straightforward - the module imports are parsed, and then expanded to import-on-demand in `TypeEnter`.
> There is a few notable aspects, however:
> - the AST node for import (`JCImport`) is holding the imported element as a field access, because so far, the imported element always had to have a '.' (even for import-on-demand). But for module imports, it is permissible to import from a module whose name does not have a dot (`import module m;`). The use of field access for ordinary import seems very useful, so I preferred to keep that, and created a new internal-only AST node for module imports. There is still only one public API AST node/interface, so this is purely an implementation choice.
> - JShell now supports module imports as well; and the default, implicit, script is changed to use it to import all of `java.base` if preview is enabled. It is expected that the default would be changed if/when the module imports feature is finalized.

Jan Lahoda has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 28 commits:

 - Merge branch 'master' into module-imports
 - Fixing test on Windows (2).
 - Fixing Imports test on Windows.
 - Adding test for ImportTree.isModule, as suggested.
 - Reflecting review feedback - improving the 'module (current) does not read (target).
 - Updating JEP number and caption.
 - Fixing ListModuleDeps test.
 - Cleanup.
 - Merge branch 'master' into module-imports
 - Including current module name as suggested.
 - ... and 18 more: https://git.openjdk.org/jdk/compare/4e5c25ee...43a1e0f6

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

Changes: https://git.openjdk.org/jdk/pull/18614/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18614&range=12
  Stats: 1343 lines in 31 files changed: 1268 ins; 17 del; 58 mod
  Patch: https://git.openjdk.org/jdk/pull/18614.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18614/head:pull/18614

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

From prappo at openjdk.org  Wed May  1 12:26:09 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Wed, 1 May 2024 12:26:09 GMT
Subject: RFR: 8331427: Rename confusingly named
 ArraysSupport.signedHashCode [v2]
In-Reply-To: <2gE7ua7k3xeIWm0TL2TCFNtTYL7ZP19G61aGEn1VP0U=.73d54a23-23ae-4359-b298-3077a760ab6c@github.com>
References: <2gE7ua7k3xeIWm0TL2TCFNtTYL7ZP19G61aGEn1VP0U=.73d54a23-23ae-4359-b298-3077a760ab6c@github.com>
Message-ID: <-WLcVysKTusFftkzbrS1w9eklAwvAVtyGeNJlZPdh6c=.fb65042e-fec8-44bd-b097-68484294c170@github.com>

> Please review this trivial method rename. While this issue was originally spotted in [another PR], it makes sense to address it separately. Test results are pending; not that I expect failures, but still.
> 
> [another PR]: https://github.com/openjdk/jdk/pull/14831#issuecomment-1655477396

Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:

  Update copyright years
  
  Note: any commit hashes below might be outdated due to subsequent
  history rewriting (e.g. git rebase).
  
   + update src/java.base/share/classes/jdk/internal/util/ArraysSupport.java due to e83c991fb5d

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/19023/files
  - new: https://git.openjdk.org/jdk/pull/19023/files/e83c991f..69f56778

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

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

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

From prappo at openjdk.org  Wed May  1 12:26:09 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Wed, 1 May 2024 12:26:09 GMT
Subject: Integrated: 8331427: Rename confusingly named
 ArraysSupport.signedHashCode
In-Reply-To: <2gE7ua7k3xeIWm0TL2TCFNtTYL7ZP19G61aGEn1VP0U=.73d54a23-23ae-4359-b298-3077a760ab6c@github.com>
References: <2gE7ua7k3xeIWm0TL2TCFNtTYL7ZP19G61aGEn1VP0U=.73d54a23-23ae-4359-b298-3077a760ab6c@github.com>
Message-ID: <JM4dbkl_njJnTG6Ylzuj-BVoM6AQtSOgUVwKuKVZE7U=.0ffbd019-b7fa-477f-830b-0d30db7c31f3@github.com>

On Tue, 30 Apr 2024 14:38:11 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> Please review this trivial method rename. While this issue was originally spotted in [another PR], it makes sense to address it separately. Test results are pending; not that I expect failures, but still.
> 
> [another PR]: https://github.com/openjdk/jdk/pull/14831#issuecomment-1655477396

This pull request has now been integrated.

Changeset: 4f529f8c
Author:    Pavel Rappo <prappo at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/4f529f8c232b4082aa4aa39766bcf42b09885ee4
Stats:     3 lines in 1 file changed: 0 ins; 0 del; 3 mod

8331427: Rename confusingly named ArraysSupport.signedHashCode

Reviewed-by: redestad

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

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

From wxiao at openjdk.org  Wed May  1 14:58:19 2024
From: wxiao at openjdk.org (Weibing Xiao)
Date: Wed, 1 May 2024 14:58:19 GMT
Subject: RFR: 8331077 : nroff man page update for jar tool
Message-ID: <VvciUQPi57eVG2wi5yyxZVmq3p1MZ6OdXTxWUYSXlAs=.117817e5-59e6-4b47-af38-d09c58443dd3@github.com>

nroff man page update for jar tool. <br>

This update is caused by the change of https://bugs.openjdk.org/browse/JDK-8318971. While the .md man pages got updated in other repos, the corresponding nroff man page was never updated in OpenJDK repos

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

Commit messages:
 - 8331077 : nroff man page update for jar tool

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

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

From wxiao at openjdk.org  Wed May  1 15:16:07 2024
From: wxiao at openjdk.org (Weibing Xiao)
Date: Wed, 1 May 2024 15:16:07 GMT
Subject: RFR: 8331077 : nroff man page update for jar tool [v2]
In-Reply-To: <VvciUQPi57eVG2wi5yyxZVmq3p1MZ6OdXTxWUYSXlAs=.117817e5-59e6-4b47-af38-d09c58443dd3@github.com>
References: <VvciUQPi57eVG2wi5yyxZVmq3p1MZ6OdXTxWUYSXlAs=.117817e5-59e6-4b47-af38-d09c58443dd3@github.com>
Message-ID: <ULaDOvQvJUdPV41S8rv3BS8E_b8ORuXU-oL1UkFEQsM=.6547bdc6-2867-4cd5-a271-378e98c8bc18@github.com>

> nroff man page update for jar tool. <br>
> 
> This update is caused by the change of https://bugs.openjdk.org/browse/JDK-8318971. While the .md man pages got updated in other repos, the corresponding nroff man page was never updated in OpenJDK repos

Weibing Xiao has updated the pull request incrementally with one additional commit since the last revision:

  update the year of copyright

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/19034/files
  - new: https://git.openjdk.org/jdk/pull/19034/files/c78bc5dd..333dbc36

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

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

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

From asemenyuk at openjdk.org  Wed May  1 15:29:56 2024
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Wed, 1 May 2024 15:29:56 GMT
Subject: Integrated: 8331222: Malformed text in the jpackage doc page
In-Reply-To: <D3pV9xgZGB4YF99vE_kkYjD3yPbfcXYIcNNwRovFu_c=.22483620-b656-4f1e-b296-c5b0f99d222c@github.com>
References: <D3pV9xgZGB4YF99vE_kkYjD3yPbfcXYIcNNwRovFu_c=.22483620-b656-4f1e-b296-c5b0f99d222c@github.com>
Message-ID: <vXOZ1tFypWI1XQRx5254ZTle1caCdH42tR5ZfBJ7FKg=.97d54987-40f9-4342-8bae-898f2b56d8af@github.com>

On Tue, 30 Apr 2024 23:58:49 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> Rerun pandoc on updated source man page file

This pull request has now been integrated.

Changeset: e833bfc8
Author:    Alexey Semenyuk <asemenyuk at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/e833bfc8ac6104522d037e7eb300f5aa112688bb
Stats:     3 lines in 1 file changed: 0 ins; 0 del; 3 mod

8331222: Malformed text in the jpackage doc page

Reviewed-by: almatvee

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

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

From jlu at openjdk.org  Wed May  1 16:15:03 2024
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 1 May 2024 16:15:03 GMT
Subject: RFR: 8295153: java/util/Base64/TestEncodingDecodingLength.java ran out
 of memory
Message-ID: <7WCCWuRTV5zB5_YbC57rZ-Yene5L7ky80YJscldD-lk=.53af1f27-031c-4ab4-836f-7d9a0269a42d@github.com>

Please review this PR which converts _TestEncodingDecodingLength.java_ into a whitebox test which allows for testing to be done without memory usage issues.

Currently, the test requires about ~2.75 `Integer.MAX_VALUE` sized byte arrays worth of memory. (2 for the initial array allocation, .75 for the target array in `decode()`). While the `-Xms6g -Xmx8g` options should address this, there have been intermittent memory issues, as the underlying machine machine may be running other tests simultaneously.

By converting this test to a white-box test not only does it get rid of memory issues, but it also gets rid of the need to decode 2GB of data 3 times. The change is done using reflection to test the private visibility methods `encodedOutLength` and `decodedOutLength`, which the public `encode` and `decode` overloaded methods call respectively.

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

Commit messages:
 - init

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

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

From wxiao at openjdk.org  Wed May  1 16:15:12 2024
From: wxiao at openjdk.org (Weibing Xiao)
Date: Wed, 1 May 2024 16:15:12 GMT
Subject: RFR: 8331077 : nroff man page update for jar tool [v3]
In-Reply-To: <VvciUQPi57eVG2wi5yyxZVmq3p1MZ6OdXTxWUYSXlAs=.117817e5-59e6-4b47-af38-d09c58443dd3@github.com>
References: <VvciUQPi57eVG2wi5yyxZVmq3p1MZ6OdXTxWUYSXlAs=.117817e5-59e6-4b47-af38-d09c58443dd3@github.com>
Message-ID: <LwRmnKXd4j4SbZDw2GEUDOSTIFHO1YoSTDSkrDZi-CM=.faeee1b7-98cc-4c04-9a8b-daef13b744c9@github.com>

> nroff man page update for jar tool. <br>
> 
> This update is caused by the change of https://bugs.openjdk.org/browse/JDK-8318971. While the .md man pages got updated in other repos, the corresponding nroff man page was never updated in OpenJDK repos

Weibing Xiao has updated the pull request incrementally with one additional commit since the last revision:

  Revert "8331427: Rename confusingly named ArraysSupport.signedHashCode"
  
  This reverts commit 4f529f8c232b4082aa4aa39766bcf42b09885ee4.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/19034/files
  - new: https://git.openjdk.org/jdk/pull/19034/files/333dbc36..051da56e

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

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

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

From wxiao at openjdk.org  Wed May  1 16:19:57 2024
From: wxiao at openjdk.org (Weibing Xiao)
Date: Wed, 1 May 2024 16:19:57 GMT
Subject: RFR: 8331077 : nroff man page update for jar tool [v3]
In-Reply-To: <LwRmnKXd4j4SbZDw2GEUDOSTIFHO1YoSTDSkrDZi-CM=.faeee1b7-98cc-4c04-9a8b-daef13b744c9@github.com>
References: <VvciUQPi57eVG2wi5yyxZVmq3p1MZ6OdXTxWUYSXlAs=.117817e5-59e6-4b47-af38-d09c58443dd3@github.com>
 <LwRmnKXd4j4SbZDw2GEUDOSTIFHO1YoSTDSkrDZi-CM=.faeee1b7-98cc-4c04-9a8b-daef13b744c9@github.com>
Message-ID: <UQmhKoyvYDuVYt76XuwrzUGpyqZpUX7Cndqadh1Ier4=.9fb68ea9-8b9e-4993-b073-ab3f3e923e10@github.com>

On Wed, 1 May 2024 16:15:12 GMT, Weibing Xiao <wxiao at openjdk.org> wrote:

>> nroff man page update for jar tool. <br>
>> 
>> This update is caused by the change of https://bugs.openjdk.org/browse/JDK-8318971. While the .md man pages got updated in other repos, the corresponding nroff man page was never updated in OpenJDK repos
>
> Weibing Xiao has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert "8331427: Rename confusingly named ArraysSupport.signedHashCode"
>   
>   This reverts commit 4f529f8c232b4082aa4aa39766bcf42b09885ee4.

Close this one as I plan to use make command to update this nroff man page.

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

PR Comment: https://git.openjdk.org/jdk/pull/19034#issuecomment-2088703685

From wxiao at openjdk.org  Wed May  1 16:19:57 2024
From: wxiao at openjdk.org (Weibing Xiao)
Date: Wed, 1 May 2024 16:19:57 GMT
Subject: Withdrawn: 8331077 : nroff man page update for jar tool
In-Reply-To: <VvciUQPi57eVG2wi5yyxZVmq3p1MZ6OdXTxWUYSXlAs=.117817e5-59e6-4b47-af38-d09c58443dd3@github.com>
References: <VvciUQPi57eVG2wi5yyxZVmq3p1MZ6OdXTxWUYSXlAs=.117817e5-59e6-4b47-af38-d09c58443dd3@github.com>
Message-ID: <bZEkfCA1mX7_11djhotlHXdMot2-PbbJe-AegcLz7qI=.7934445f-89d2-453b-a2b4-0fc572ddf70e@github.com>

On Wed, 1 May 2024 14:54:02 GMT, Weibing Xiao <wxiao at openjdk.org> wrote:

> nroff man page update for jar tool. <br>
> 
> This update is caused by the change of https://bugs.openjdk.org/browse/JDK-8318971. While the .md man pages got updated in other repos, the corresponding nroff man page was never updated in OpenJDK repos

This pull request has been closed without being integrated.

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

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

From rriggs at openjdk.org  Wed May  1 17:13:53 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 1 May 2024 17:13:53 GMT
Subject: RFR: 8330276: Console methods with explicit Locale [v2]
In-Reply-To: <3PG6UCpNxIV2SSDuHcQ66RhUisK1MNtWT-IX68iXuEc=.c3f3e3b5-988f-4178-8ec7-992b8de6b8ca@github.com>
References: <GT275XVwYlYL3PhYwOTQ_-HwKqp9QYUeIzEIeJKEwkQ=.9a7faf08-8637-45a3-97bd-fd58756a6711@github.com>
 <3PG6UCpNxIV2SSDuHcQ66RhUisK1MNtWT-IX68iXuEc=.c3f3e3b5-988f-4178-8ec7-992b8de6b8ca@github.com>
Message-ID: <8hJNdHFB4b_BNB3gv6-5zX5TIfr8IC_otcbtpu0QPxE=.b66ab258-58b4-48af-a9b3-533657e0c2c6@github.com>

On Mon, 29 Apr 2024 23:22:21 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Proposing new overloaded methods in `java.io.Console` class that explicitly take a `Locale` argument. Existing methods rely on the default locale, so the users won't be able to format their prompts/outputs in a certain locale explicitly.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Addressed review comments

src/java.base/share/classes/java/io/ProxyingConsole.java line 89:

> 87:     @Override
> 88:     public Console format(String format, Object ... args) {
> 89:         return format(Locale.getDefault(Locale.Category.FORMAT), format, args);

Given the number of calls to Locale.getDefault(Locale.Category.FORMAT) it might be worthwhile to cache that in the Proxying Console or in the JdkConsoleImpl.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18923#discussion_r1586523255

From naoto at openjdk.org  Wed May  1 17:21:20 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 1 May 2024 17:21:20 GMT
Subject: RFR: 8331202: Support for Duration until another Instant [v3]
In-Reply-To: <QgXldf9AnNqL8Vix38fsGGS0WnMTSbEO1Zo5ndd3Tdw=.5587eb0f-645d-4b9c-a6ef-87eaf8d7badf@github.com>
References: <QgXldf9AnNqL8Vix38fsGGS0WnMTSbEO1Zo5ndd3Tdw=.5587eb0f-645d-4b9c-a6ef-87eaf8d7badf@github.com>
Message-ID: <XB3CH0FfzXRlqRuGgU8ErfR4IkT1sb8rfGTIbQSKR1s=.40ad8e30-f2f9-4d14-b8b0-84f7799f688a@github.com>

> A new method on Instant to return the duration `until` another Instant is suggested per the following discussion thread:
> 
> https://mail.openjdk.org/pipermail/core-libs-dev/2024-April/122131.html
> 
> A CSR has also been drafted.

Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:

  Addressing CSR reviews

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/19007/files
  - new: https://git.openjdk.org/jdk/pull/19007/files/df2c1157..cccdf00c

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

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

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

From naoto at openjdk.org  Wed May  1 17:42:58 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 1 May 2024 17:42:58 GMT
Subject: RFR: 8330276: Console methods with explicit Locale [v2]
In-Reply-To: <8hJNdHFB4b_BNB3gv6-5zX5TIfr8IC_otcbtpu0QPxE=.b66ab258-58b4-48af-a9b3-533657e0c2c6@github.com>
References: <GT275XVwYlYL3PhYwOTQ_-HwKqp9QYUeIzEIeJKEwkQ=.9a7faf08-8637-45a3-97bd-fd58756a6711@github.com>
 <3PG6UCpNxIV2SSDuHcQ66RhUisK1MNtWT-IX68iXuEc=.c3f3e3b5-988f-4178-8ec7-992b8de6b8ca@github.com>
 <8hJNdHFB4b_BNB3gv6-5zX5TIfr8IC_otcbtpu0QPxE=.b66ab258-58b4-48af-a9b3-533657e0c2c6@github.com>
Message-ID: <k_WUc4k2xFD5fENgfaJPLNpLZO7f_U8VNo96tQgvjd0=.7ced3a14-c13a-4635-8cdb-f1512912b2ba@github.com>

On Wed, 1 May 2024 17:10:53 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Addressed review comments
>
> src/java.base/share/classes/java/io/ProxyingConsole.java line 89:
> 
>> 87:     @Override
>> 88:     public Console format(String format, Object ... args) {
>> 89:         return format(Locale.getDefault(Locale.Category.FORMAT), format, args);
> 
> Given the number of calls to Locale.getDefault(Locale.Category.FORMAT) it might be worthwhile to cache that in the Proxying Console or in the JdkConsoleImpl.

Initially, I thought about it but did not cache it here because it is cached in the `Locale` class, and the call returns the cached value.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18923#discussion_r1586554554

From lancea at openjdk.org  Wed May  1 17:48:56 2024
From: lancea at openjdk.org (Lance Andersen)
Date: Wed, 1 May 2024 17:48:56 GMT
Subject: RFR: 8295153: java/util/Base64/TestEncodingDecodingLength.java ran
 out of memory
In-Reply-To: <7WCCWuRTV5zB5_YbC57rZ-Yene5L7ky80YJscldD-lk=.53af1f27-031c-4ab4-836f-7d9a0269a42d@github.com>
References: <7WCCWuRTV5zB5_YbC57rZ-Yene5L7ky80YJscldD-lk=.53af1f27-031c-4ab4-836f-7d9a0269a42d@github.com>
Message-ID: <xLb2z7a4cYuLqx3KB9pV-lyXjRKrWxhWffOE4Bx93Dc=.d934abfc-c4e1-415b-9911-64fd4889c538@github.com>

On Wed, 1 May 2024 16:10:06 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which converts _TestEncodingDecodingLength.java_ into a whitebox test which allows for testing to be done without memory usage issues.
> 
> Currently, the test requires about ~2.75 `Integer.MAX_VALUE` sized byte arrays worth of memory. (2 for the initial array allocation, .75 for the target array in `decode()`). While the `-Xms6g -Xmx8g` options should address this, there have been intermittent memory issues, as the underlying machine machine may be running other tests simultaneously.
> 
> By converting this test to a white-box test not only does it get rid of memory issues, but it also gets rid of the need to decode 2GB of data 3 times. The change is done using reflection to test the private visibility methods `encodedOutLength` and `decodedOutLength`, which the public `encode` and `decode` overloaded methods call respectively.

Thank you for taking this on Justin and converting to a junit test as part of your updates.

Overall it looks good on an initial pass.

Please see a few suggestions for your consideration

test/jdk/java/util/Base64/TestEncodingDecodingLength.java line 47:

> 45: public class TestEncodingDecodingLength {
> 46: 
> 47:     private static final int size = Integer.MAX_VALUE - 8;

Perhaps consider size-> SIZE and maybe tweak the name and add an additional comment to its purpose

test/jdk/java/util/Base64/TestEncodingDecodingLength.java line 67:

> 65: 
> 66:         // OOME case
> 67:         try {

Perhaps make this a separate test case so that the IAE test fails the OOME still runs

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

PR Review: https://git.openjdk.org/jdk/pull/19036#pullrequestreview-2033944705
PR Review Comment: https://git.openjdk.org/jdk/pull/19036#discussion_r1586493998
PR Review Comment: https://git.openjdk.org/jdk/pull/19036#discussion_r1586499085

From wxiao at openjdk.org  Wed May  1 17:57:14 2024
From: wxiao at openjdk.org (Weibing Xiao)
Date: Wed, 1 May 2024 17:57:14 GMT
Subject: RFR: 8331077 : nroff man page update for jar tool
Message-ID: <0O_4EK5PFKWHY-XCTgNyck8ILQueXJT9JVjobSG-ECw=.8e55a73a-72d5-44c6-8b16-67e71a2ed7c0@github.com>

nroff man page update for jar tool. <br>
This update is caused by the change of?https://bugs.openjdk.org/browse/JDK-8318971. While the .md man pages got updated in other repos, the corresponding nroff man page was never updated in OpenJDK repos

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

Commit messages:
 - 8331077 : nroff man page update for jar tool

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

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

From jjg at openjdk.org  Wed May  1 18:08:53 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Wed, 1 May 2024 18:08:53 GMT
Subject: RFR: 8331077 : nroff man page update for jar tool
In-Reply-To: <0O_4EK5PFKWHY-XCTgNyck8ILQueXJT9JVjobSG-ECw=.8e55a73a-72d5-44c6-8b16-67e71a2ed7c0@github.com>
References: <0O_4EK5PFKWHY-XCTgNyck8ILQueXJT9JVjobSG-ECw=.8e55a73a-72d5-44c6-8b16-67e71a2ed7c0@github.com>
Message-ID: <fkEFoptoh-ICD6ZA9zbIzlhWTxQ-fTkUaY8T1sjAGVk=.7b9617d2-f9a8-48be-89f9-aa088d105be0@github.com>

On Wed, 1 May 2024 17:52:13 GMT, Weibing Xiao <wxiao at openjdk.org> wrote:

> nroff man page update for jar tool. <br>
> This update is caused by the change of?https://bugs.openjdk.org/browse/JDK-8318971. While the .md man pages got updated in other repos, the corresponding nroff man page was never updated in OpenJDK repos

Changes requested by jjg (Reviewer).

src/jdk.jartool/share/man/jar.1 line 38:

> 36: . ftr VBI CBI
> 37: .\}
> 38: .TH "JAR" "1" "2024" "JDK 23-internal" "JDK Commands"

should remain as `ea` -- not `internal`

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

PR Review: https://git.openjdk.org/jdk/pull/19039#pullrequestreview-2034148426
PR Review Comment: https://git.openjdk.org/jdk/pull/19039#discussion_r1586584726

From jlahoda at openjdk.org  Wed May  1 18:35:55 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Wed, 1 May 2024 18:35:55 GMT
Subject: RFR: 8330998: System.console() writes to stderr when stdout is
 redirected [v2]
In-Reply-To: <AgPIsLMYyLc6_iCfo4b-tiVW6MMEsPxhfQeGgH4ocxM=.81a948e8-e20a-496a-8054-b0fa5e7da998@github.com>
References: <A8XxdrFyHsuO_Kj27Y9eLMSgYnhvYW9ZKzs_sVJnTDM=.8a53eac4-2d84-4264-a591-8872071ecda1@github.com>
 <eMk7DeAISMbeK9czK6rvnqYruYvSwit6FYmig3whCsQ=.0449e2f1-4009-40da-998d-134f44dd279b@github.com>
 <AgPIsLMYyLc6_iCfo4b-tiVW6MMEsPxhfQeGgH4ocxM=.81a948e8-e20a-496a-8054-b0fa5e7da998@github.com>
Message-ID: <kDfhfAobptsuCc5K26QBOK3NrRqmLlrBIUEdNrWF3aw=.848df900-667d-453a-a1f3-b39b2010948e@github.com>

On Mon, 29 Apr 2024 18:41:44 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Looks good to me. Left some minor suggestions. BTW, should we file an issue at the `JLine` project, not to redirect to stderr, or suggest a new config (sorry if it has already been taken care of)?

The code to choose the output stream is quite elaborate, so I assume that is intentional. For new versions of JLine, the `systemOutput(SystemOutput.SysOut)` forces the use of stdout, however, so the patch to JLine itself will not be needed anymore after we upgrade.

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

PR Comment: https://git.openjdk.org/jdk/pull/18996#issuecomment-2088894660

From wxiao at openjdk.org  Wed May  1 18:42:12 2024
From: wxiao at openjdk.org (Weibing Xiao)
Date: Wed, 1 May 2024 18:42:12 GMT
Subject: RFR: 8331077 : nroff man page update for jar tool [v2]
In-Reply-To: <0O_4EK5PFKWHY-XCTgNyck8ILQueXJT9JVjobSG-ECw=.8e55a73a-72d5-44c6-8b16-67e71a2ed7c0@github.com>
References: <0O_4EK5PFKWHY-XCTgNyck8ILQueXJT9JVjobSG-ECw=.8e55a73a-72d5-44c6-8b16-67e71a2ed7c0@github.com>
Message-ID: <NByHVjaKm_or4Z0dc9SMxvy1tVxaArLnTz8l01T7Mg4=.b6e45e9b-04a6-4208-b8b8-80e5e0240dac@github.com>

> nroff man page update for jar tool. <br>
> This update is caused by the change of?https://bugs.openjdk.org/browse/JDK-8318971. While the .md man pages got updated in other repos, the corresponding nroff man page was never updated in OpenJDK repos

Weibing Xiao has updated the pull request incrementally with one additional commit since the last revision:

  version of java

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/19039/files
  - new: https://git.openjdk.org/jdk/pull/19039/files/2808853c..b0ef5dff

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

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

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

From wxiao at openjdk.org  Wed May  1 18:42:12 2024
From: wxiao at openjdk.org (Weibing Xiao)
Date: Wed, 1 May 2024 18:42:12 GMT
Subject: RFR: 8331077 : nroff man page update for jar tool
In-Reply-To: <0O_4EK5PFKWHY-XCTgNyck8ILQueXJT9JVjobSG-ECw=.8e55a73a-72d5-44c6-8b16-67e71a2ed7c0@github.com>
References: <0O_4EK5PFKWHY-XCTgNyck8ILQueXJT9JVjobSG-ECw=.8e55a73a-72d5-44c6-8b16-67e71a2ed7c0@github.com>
Message-ID: <8KnazAaTQ1d1Hjp5egXdwG35Skp2s0Ux0xBfXE3Gd30=.17a154eb-da94-49bd-a129-519381ca9db0@github.com>

On Wed, 1 May 2024 17:52:13 GMT, Weibing Xiao <wxiao at openjdk.org> wrote:

> nroff man page update for jar tool. <br>
> This update is caused by the change of?https://bugs.openjdk.org/browse/JDK-8318971. While the .md man pages got updated in other repos, the corresponding nroff man page was never updated in OpenJDK repos

reverted to "JDK 23-ea"

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

PR Comment: https://git.openjdk.org/jdk/pull/19039#issuecomment-2088901772

From naoto at openjdk.org  Wed May  1 18:45:52 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 1 May 2024 18:45:52 GMT
Subject: RFR: 8330998: System.console() writes to stderr when stdout is
 redirected [v3]
In-Reply-To: <bJ99HAH1H96JfGviZb0bcGd5sKqTd0Pe06mgRxcG4Cc=.f1e8001f-1302-4385-be67-7686609ffa61@github.com>
References: <A8XxdrFyHsuO_Kj27Y9eLMSgYnhvYW9ZKzs_sVJnTDM=.8a53eac4-2d84-4264-a591-8872071ecda1@github.com>
 <bJ99HAH1H96JfGviZb0bcGd5sKqTd0Pe06mgRxcG4Cc=.f1e8001f-1302-4385-be67-7686609ffa61@github.com>
Message-ID: <MFV0jGRWediMw8brXec7tHAZlipgzDQlF5d0RckFdUk=.3c66304e-15da-4487-89a8-0d9cca2d1f56@github.com>

On Tue, 30 Apr 2024 15:02:21 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> Consider code like:
>> 
>> public class ConsoleTest {
>>     public static void main(String... args) {
>>         System.console().printf("Hello!");
>>     }
>> }
>> 
>> 
>> When run as:
>> 
>> $ java ConsoleTest.java >/dev/null
>> 
>> 
>> it prints `Hello!` to stderr, instead of to stdout (where it would be redirected).
>> 
>> The proposed fix is to simply force the use of stdout. Sadly, this cannot be done solely using JLine configuration, we actually need to change the JLine's code for that.
>> 
>> The most tricky part is a test. There are two sub-tests, one effectively testing a case where all of stdin/out/err are redirected, the other is attempting to test the case where stdin is attached to a terminal, while stdout is redirected. The second sub-test using a native functions to create a pty and to attach to it, and should run in a separate VM, as it leaves the VM attached to the terminal.
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adjusting test, as suggested.

Looks good!

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

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18996#pullrequestreview-2034202479

From coffeys at openjdk.org  Wed May  1 18:48:53 2024
From: coffeys at openjdk.org (Sean Coffey)
Date: Wed, 1 May 2024 18:48:53 GMT
Subject: RFR: 8331077 : nroff man page update for jar tool [v2]
In-Reply-To: <NByHVjaKm_or4Z0dc9SMxvy1tVxaArLnTz8l01T7Mg4=.b6e45e9b-04a6-4208-b8b8-80e5e0240dac@github.com>
References: <0O_4EK5PFKWHY-XCTgNyck8ILQueXJT9JVjobSG-ECw=.8e55a73a-72d5-44c6-8b16-67e71a2ed7c0@github.com>
 <NByHVjaKm_or4Z0dc9SMxvy1tVxaArLnTz8l01T7Mg4=.b6e45e9b-04a6-4208-b8b8-80e5e0240dac@github.com>
Message-ID: <ntVltHsBuVU2ReWJY2UpqyN6OfK43F1hH9Z_npg1rG4=.02701fef-f390-4b63-a537-5dd928e43a53@github.com>

On Wed, 1 May 2024 18:42:12 GMT, Weibing Xiao <wxiao at openjdk.org> wrote:

>> nroff man page update for jar tool. <br>
>> This update is caused by the change of?https://bugs.openjdk.org/browse/JDK-8318971. While the .md man pages got updated in other repos, the corresponding nroff man page was never updated in OpenJDK repos
>
> Weibing Xiao has updated the pull request incrementally with one additional commit since the last revision:
> 
>   version of java

Looks ok to me

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

Marked as reviewed by coffeys (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19039#pullrequestreview-2034212366

From rriggs at openjdk.org  Wed May  1 18:50:02 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 1 May 2024 18:50:02 GMT
Subject: RFR: 8331224: ClassCastException in ObjectStreamClass during
 deserialization - cannot assign instance of java.util.CollSer to field of type
 java.util.Map
Message-ID: <WwGt00cM9kdSmRkkh5Vs27AanKC0I4DwCBoWhai7itI=.3dde8683-9701-4d87-bf5f-0d0d501bd037@github.com>

The issue reported a ClassCastException "cannot assign instance of java.util.CollSer to field of type java.util.Map"
while deserializing an object referring to an immutable Map that contained a reference to a class that was not available.
Immutable Collections such as Map utilize a serialization proxy in their serialized form.
During deserialization the serialization proxy (a private implementation class) was attempted to be set in a field resulting in the ClassCastException. The ClassCastException and bug hid the ClassCastException that should have been thrown.

When reading record fields or fields of a class, the results of deserialization of individual fields are recorded as dependencies of the object being constructed.
The apparent bug is that the summary of those dependencies is not checked between reading the fields and invoking the constructor to create the record or assigning the fields to an object being constructed.

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

Commit messages:
 - 8331224: ClassCastException in ObjectStreamClass during deserialization

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

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

From jlu at openjdk.org  Wed May  1 18:52:06 2024
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 1 May 2024 18:52:06 GMT
Subject: RFR: 8295153: java/util/Base64/TestEncodingDecodingLength.java ran
 out of memory [v2]
In-Reply-To: <7WCCWuRTV5zB5_YbC57rZ-Yene5L7ky80YJscldD-lk=.53af1f27-031c-4ab4-836f-7d9a0269a42d@github.com>
References: <7WCCWuRTV5zB5_YbC57rZ-Yene5L7ky80YJscldD-lk=.53af1f27-031c-4ab4-836f-7d9a0269a42d@github.com>
Message-ID: <N5lKHsI4_Z0b7wpXWP6KM-o6gmUf0O8_pfD-3mqHNzg=.ea2beccc-14ec-4de5-b5a1-c4d00a5894b0@github.com>

> Please review this PR which converts _TestEncodingDecodingLength.java_ into a whitebox test which allows for testing to be done without memory usage issues.
> 
> Currently, the test requires about ~2.75 `Integer.MAX_VALUE` sized byte arrays worth of memory. (2 for the initial array allocation, .75 for the target array in `decode()`). While the `-Xms6g -Xmx8g` options should address this, there have been intermittent memory issues, as the underlying machine machine may be running other tests simultaneously.
> 
> By converting this test to a white-box test not only does it get rid of memory issues, but it also gets rid of the need to decode 2GB of data 3 times. The change is done using reflection to test the private visibility methods `encodedOutLength` and `decodedOutLength`, which the public `encode` and `decode` overloaded methods call respectively.

Justin Lu has updated the pull request incrementally with one additional commit since the last revision:

  Reflect review comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/19036/files
  - new: https://git.openjdk.org/jdk/pull/19036/files/6958ba5a..aa25c9a7

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

  Stats: 49 lines in 1 file changed: 20 ins; 7 del; 22 mod
  Patch: https://git.openjdk.org/jdk/pull/19036.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19036/head:pull/19036

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

From jlu at openjdk.org  Wed May  1 18:52:06 2024
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 1 May 2024 18:52:06 GMT
Subject: RFR: 8295153: java/util/Base64/TestEncodingDecodingLength.java ran
 out of memory [v2]
In-Reply-To: <xLb2z7a4cYuLqx3KB9pV-lyXjRKrWxhWffOE4Bx93Dc=.d934abfc-c4e1-415b-9911-64fd4889c538@github.com>
References: <7WCCWuRTV5zB5_YbC57rZ-Yene5L7ky80YJscldD-lk=.53af1f27-031c-4ab4-836f-7d9a0269a42d@github.com>
 <xLb2z7a4cYuLqx3KB9pV-lyXjRKrWxhWffOE4Bx93Dc=.d934abfc-c4e1-415b-9911-64fd4889c538@github.com>
Message-ID: <uH0PxuG-xHWw7mjBes9QiomQpiSpQsgJRO6A8NJCOHA=.61a7dc3f-fd22-4336-a381-69d8bf76f904@github.com>

On Wed, 1 May 2024 16:40:31 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Reflect review comments
>
> test/jdk/java/util/Base64/TestEncodingDecodingLength.java line 47:
> 
>> 45: public class TestEncodingDecodingLength {
>> 46: 
>> 47:     private static final int size = Integer.MAX_VALUE - 8;
> 
> Perhaps consider size-> SIZE and maybe tweak the name and add an additional comment to its purpose

Thanks for the review Lance, both comments should be addressed in https://github.com/openjdk/jdk/pull/19036/commits/aa25c9a72d218401f70bb19bd0e1d911b19b6361

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19036#discussion_r1586643285

From lancea at openjdk.org  Wed May  1 19:04:54 2024
From: lancea at openjdk.org (Lance Andersen)
Date: Wed, 1 May 2024 19:04:54 GMT
Subject: RFR: 8295153: java/util/Base64/TestEncodingDecodingLength.java ran
 out of memory [v2]
In-Reply-To: <N5lKHsI4_Z0b7wpXWP6KM-o6gmUf0O8_pfD-3mqHNzg=.ea2beccc-14ec-4de5-b5a1-c4d00a5894b0@github.com>
References: <7WCCWuRTV5zB5_YbC57rZ-Yene5L7ky80YJscldD-lk=.53af1f27-031c-4ab4-836f-7d9a0269a42d@github.com>
 <N5lKHsI4_Z0b7wpXWP6KM-o6gmUf0O8_pfD-3mqHNzg=.ea2beccc-14ec-4de5-b5a1-c4d00a5894b0@github.com>
Message-ID: <MwL3TZzCM1YD3gEzfpNDO3Pb6KvF6I9rAvmUOCIwgpg=.2e5bfab8-62ef-4d25-b9f2-fcda9dac1c25@github.com>

On Wed, 1 May 2024 18:52:06 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please review this PR which converts _TestEncodingDecodingLength.java_ into a whitebox test which allows for testing to be done without memory usage issues.
>> 
>> Currently, the test requires about ~2.75 `Integer.MAX_VALUE` sized byte arrays worth of memory. (2 for the initial array allocation, .75 for the target array in `decode()`). While the `-Xms6g -Xmx8g` options should address this, there have been intermittent memory issues, as the underlying machine machine may be running other tests simultaneously.
>> 
>> By converting this test to a white-box test not only does it get rid of memory issues, but it also gets rid of the need to decode 2GB of data 3 times. The change is done using reflection to test the private visibility methods `encodedOutLength` and `decodedOutLength`, which the public `encode` and `decode` overloaded methods call respectively.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reflect review comments

Marked as reviewed by lancea (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/19036#pullrequestreview-2034254050

From jjg at openjdk.org  Wed May  1 20:04:52 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Wed, 1 May 2024 20:04:52 GMT
Subject: RFR: 8331077 : nroff man page update for jar tool [v2]
In-Reply-To: <NByHVjaKm_or4Z0dc9SMxvy1tVxaArLnTz8l01T7Mg4=.b6e45e9b-04a6-4208-b8b8-80e5e0240dac@github.com>
References: <0O_4EK5PFKWHY-XCTgNyck8ILQueXJT9JVjobSG-ECw=.8e55a73a-72d5-44c6-8b16-67e71a2ed7c0@github.com>
 <NByHVjaKm_or4Z0dc9SMxvy1tVxaArLnTz8l01T7Mg4=.b6e45e9b-04a6-4208-b8b8-80e5e0240dac@github.com>
Message-ID: <20GrCftVAeKdPcU-TbdG8F2mRCeOr2u3rx4n3-Ky4Cg=.24e625d4-4b53-4982-bf48-13a21f94ed9c@github.com>

On Wed, 1 May 2024 18:42:12 GMT, Weibing Xiao <wxiao at openjdk.org> wrote:

>> nroff man page update for jar tool. <br>
>> This update is caused by the change of?https://bugs.openjdk.org/browse/JDK-8318971. While the .md man pages got updated in other repos, the corresponding nroff man page was never updated in OpenJDK repos
>
> Weibing Xiao has updated the pull request incrementally with one additional commit since the last revision:
> 
>   version of java

Approved, as corresponding to the upstream Markdown file.

That being said, the descriptions about arg files in lines 334-343 look somewhat clunky, and could benefit from some improvements in a later update.

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

Marked as reviewed by jjg (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19039#pullrequestreview-2034355345

From naoto at openjdk.org  Wed May  1 20:20:54 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 1 May 2024 20:20:54 GMT
Subject: RFR: 8295153: java/util/Base64/TestEncodingDecodingLength.java ran
 out of memory [v2]
In-Reply-To: <N5lKHsI4_Z0b7wpXWP6KM-o6gmUf0O8_pfD-3mqHNzg=.ea2beccc-14ec-4de5-b5a1-c4d00a5894b0@github.com>
References: <7WCCWuRTV5zB5_YbC57rZ-Yene5L7ky80YJscldD-lk=.53af1f27-031c-4ab4-836f-7d9a0269a42d@github.com>
 <N5lKHsI4_Z0b7wpXWP6KM-o6gmUf0O8_pfD-3mqHNzg=.ea2beccc-14ec-4de5-b5a1-c4d00a5894b0@github.com>
Message-ID: <fAhzWPMMmBqmr48J-m8cd2dkEcW7kdGYj8TLHw1GgSQ=.76cffee0-5caa-42cf-8db8-a00ad0208feb@github.com>

On Wed, 1 May 2024 18:52:06 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please review this PR which converts _TestEncodingDecodingLength.java_ into a whitebox test which allows for testing to be done without memory usage issues.
>> 
>> Currently, the test requires about ~2.75 `Integer.MAX_VALUE` sized byte arrays worth of memory. (2 for the initial array allocation, .75 for the target array in `decode()`). While the `-Xms6g -Xmx8g` options should address this, there have been intermittent memory issues, as the underlying machine machine may be running other tests simultaneously.
>> 
>> By converting this test to a white-box test not only does it get rid of memory issues, but it also gets rid of the need to decode 2GB of data 3 times. The change is done using reflection to test the private visibility methods `encodedOutLength` and `decodedOutLength`, which the public `encode` and `decode` overloaded methods call respectively.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reflect review comments

test/jdk/java/util/Base64/TestEncodingDecodingLength.java line 75:

> 73:         } catch (InvocationTargetException ex) {
> 74:             Throwable rootEx = ex.getCause();
> 75:             assertEquals(OutOfMemoryError.class, rootEx.getClass(), "00ME should be thrown");

Sorry if it is intentional, but I wonder if you meant "OOME" instead of "00ME" here?

test/jdk/java/util/Base64/TestEncodingDecodingLength.java line 100:

> 98:             m.invoke(DECODER, src, -LARGE_MEM_SIZE + 1, 1);
> 99:         } catch (InvocationTargetException ex) {
> 100:             fail("Decode should neither throw NASE or OOME: " + ex.getCause());

Should we check the cause is either NASE or OOME here?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19036#discussion_r1586777571
PR Review Comment: https://git.openjdk.org/jdk/pull/19036#discussion_r1586781336

From lancea at openjdk.org  Wed May  1 20:29:54 2024
From: lancea at openjdk.org (Lance Andersen)
Date: Wed, 1 May 2024 20:29:54 GMT
Subject: RFR: 8295153: java/util/Base64/TestEncodingDecodingLength.java ran
 out of memory [v2]
In-Reply-To: <fAhzWPMMmBqmr48J-m8cd2dkEcW7kdGYj8TLHw1GgSQ=.76cffee0-5caa-42cf-8db8-a00ad0208feb@github.com>
References: <7WCCWuRTV5zB5_YbC57rZ-Yene5L7ky80YJscldD-lk=.53af1f27-031c-4ab4-836f-7d9a0269a42d@github.com>
 <N5lKHsI4_Z0b7wpXWP6KM-o6gmUf0O8_pfD-3mqHNzg=.ea2beccc-14ec-4de5-b5a1-c4d00a5894b0@github.com>
 <fAhzWPMMmBqmr48J-m8cd2dkEcW7kdGYj8TLHw1GgSQ=.76cffee0-5caa-42cf-8db8-a00ad0208feb@github.com>
Message-ID: <0CURQv729CB4a_kuV7iFgSbTYXY9RoA6Pw-unztWWU4=.ebe7c6bf-72d5-4c97-afe5-172952193cb0@github.com>

On Wed, 1 May 2024 20:12:33 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Reflect review comments
>
> test/jdk/java/util/Base64/TestEncodingDecodingLength.java line 75:
> 
>> 73:         } catch (InvocationTargetException ex) {
>> 74:             Throwable rootEx = ex.getCause();
>> 75:             assertEquals(OutOfMemoryError.class, rootEx.getClass(), "00ME should be thrown");
> 
> Sorry if it is intentional, but I wonder if you meant "OOME" instead of "00ME" here?

Good catch, you sometimes see what you want to see

> test/jdk/java/util/Base64/TestEncodingDecodingLength.java line 100:
> 
>> 98:             m.invoke(DECODER, src, -LARGE_MEM_SIZE + 1, 1);
>> 99:         } catch (InvocationTargetException ex) {
>> 100:             fail("Decode should neither throw NASE or OOME: " + ex.getCause());
> 
> Should we check the cause is either NASE or OOME here?

The original test just validated there was no exception thrown, so I think we can just update the message to indicate an unexpected Exception.

I had added this as a comment but must have missed hitting the comment button

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19036#discussion_r1586789013
PR Review Comment: https://git.openjdk.org/jdk/pull/19036#discussion_r1586788635

From jlu at openjdk.org  Wed May  1 20:35:10 2024
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 1 May 2024 20:35:10 GMT
Subject: RFR: 8295153: java/util/Base64/TestEncodingDecodingLength.java ran
 out of memory [v3]
In-Reply-To: <7WCCWuRTV5zB5_YbC57rZ-Yene5L7ky80YJscldD-lk=.53af1f27-031c-4ab4-836f-7d9a0269a42d@github.com>
References: <7WCCWuRTV5zB5_YbC57rZ-Yene5L7ky80YJscldD-lk=.53af1f27-031c-4ab4-836f-7d9a0269a42d@github.com>
Message-ID: <TJhP4Q7gj-D7yPBNJ5rKtOrh4whpgMAAFM40OUnhSvg=.e906cf18-ab71-4db5-b87c-cf8f78b61192@github.com>

> Please review this PR which converts _TestEncodingDecodingLength.java_ into a whitebox test which allows for testing to be done without memory usage issues.
> 
> Currently, the test requires about ~2.75 `Integer.MAX_VALUE` sized byte arrays worth of memory. (2 for the initial array allocation, .75 for the target array in `decode()`). While the `-Xms6g -Xmx8g` options should address this, there have been intermittent memory issues, as the underlying machine machine may be running other tests simultaneously.
> 
> By converting this test to a white-box test not only does it get rid of memory issues, but it also gets rid of the need to decode 2GB of data 3 times. The change is done using reflection to test the private visibility methods `encodedOutLength` and `decodedOutLength`, which the public `encode` and `decode` overloaded methods call respectively.

Justin Lu has updated the pull request incrementally with one additional commit since the last revision:

  reflect further review

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/19036/files
  - new: https://git.openjdk.org/jdk/pull/19036/files/aa25c9a7..eb1f64ce

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

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

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

From jlu at openjdk.org  Wed May  1 20:35:10 2024
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 1 May 2024 20:35:10 GMT
Subject: RFR: 8295153: java/util/Base64/TestEncodingDecodingLength.java ran
 out of memory [v2]
In-Reply-To: <0CURQv729CB4a_kuV7iFgSbTYXY9RoA6Pw-unztWWU4=.ebe7c6bf-72d5-4c97-afe5-172952193cb0@github.com>
References: <7WCCWuRTV5zB5_YbC57rZ-Yene5L7ky80YJscldD-lk=.53af1f27-031c-4ab4-836f-7d9a0269a42d@github.com>
 <N5lKHsI4_Z0b7wpXWP6KM-o6gmUf0O8_pfD-3mqHNzg=.ea2beccc-14ec-4de5-b5a1-c4d00a5894b0@github.com>
 <fAhzWPMMmBqmr48J-m8cd2dkEcW7kdGYj8TLHw1GgSQ=.76cffee0-5caa-42cf-8db8-a00ad0208feb@github.com>
 <0CURQv729CB4a_kuV7iFgSbTYXY9RoA6Pw-unztWWU4=.ebe7c6bf-72d5-4c97-afe5-172952193cb0@github.com>
Message-ID: <0aQ3y2QI1qfbdEb9pQhlLiHK6WRjkg84KnZjVpdrdUo=.8763fadb-fec2-4f2a-9bc0-a701df263656@github.com>

On Wed, 1 May 2024 20:27:19 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> test/jdk/java/util/Base64/TestEncodingDecodingLength.java line 75:
>> 
>>> 73:         } catch (InvocationTargetException ex) {
>>> 74:             Throwable rootEx = ex.getCause();
>>> 75:             assertEquals(OutOfMemoryError.class, rootEx.getClass(), "00ME should be thrown");
>> 
>> Sorry if it is intentional, but I wonder if you meant "OOME" instead of "00ME" here?
>
> Good catch, you sometimes see what you want to see

That was unexpected, wonder how I did that unconsciously...

>> test/jdk/java/util/Base64/TestEncodingDecodingLength.java line 100:
>> 
>>> 98:             m.invoke(DECODER, src, -LARGE_MEM_SIZE + 1, 1);
>>> 99:         } catch (InvocationTargetException ex) {
>>> 100:             fail("Decode should neither throw NASE or OOME: " + ex.getCause());
>> 
>> Should we check the cause is either NASE or OOME here?
>
> The original test just validated there was no exception thrown, so I think we can just update the message to indicate an unexpected Exception.
> 
> I had added this as a comment but must have missed hitting the comment button

Improved the error message to be more general, (as no exception should be thrown). Comments clarify that the method used to throw NASE and OOME.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19036#discussion_r1586793517
PR Review Comment: https://git.openjdk.org/jdk/pull/19036#discussion_r1586793148

From lancea at openjdk.org  Wed May  1 20:40:56 2024
From: lancea at openjdk.org (Lance Andersen)
Date: Wed, 1 May 2024 20:40:56 GMT
Subject: RFR: 8295153: java/util/Base64/TestEncodingDecodingLength.java ran
 out of memory [v3]
In-Reply-To: <TJhP4Q7gj-D7yPBNJ5rKtOrh4whpgMAAFM40OUnhSvg=.e906cf18-ab71-4db5-b87c-cf8f78b61192@github.com>
References: <7WCCWuRTV5zB5_YbC57rZ-Yene5L7ky80YJscldD-lk=.53af1f27-031c-4ab4-836f-7d9a0269a42d@github.com>
 <TJhP4Q7gj-D7yPBNJ5rKtOrh4whpgMAAFM40OUnhSvg=.e906cf18-ab71-4db5-b87c-cf8f78b61192@github.com>
Message-ID: <XVp9QXiFDtpSTMbzV7Uxe8rhCHMcd4gNvZWqbUmroU0=.93feb052-b922-4503-adc9-2f131c3351b4@github.com>

On Wed, 1 May 2024 20:35:10 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please review this PR which converts _TestEncodingDecodingLength.java_ into a whitebox test which allows for testing to be done without memory usage issues.
>> 
>> Currently, the test requires about ~2.75 `Integer.MAX_VALUE` sized byte arrays worth of memory. (2 for the initial array allocation, .75 for the target array in `decode()`). While the `-Xms6g -Xmx8g` options should address this, there have been intermittent memory issues, as the underlying machine machine may be running other tests simultaneously.
>> 
>> By converting this test to a white-box test not only does it get rid of memory issues, but it also gets rid of the need to decode 2GB of data 3 times. The change is done using reflection to test the private visibility methods `encodedOutLength` and `decodedOutLength`, which the public `encode` and `decode` overloaded methods call respectively.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   reflect further review

Marked as reviewed by lancea (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/19036#pullrequestreview-2034414118

From rriggs at openjdk.org  Wed May  1 20:45:54 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 1 May 2024 20:45:54 GMT
Subject: RFR: 8331202: Support for Duration until another Instant [v3]
In-Reply-To: <XB3CH0FfzXRlqRuGgU8ErfR4IkT1sb8rfGTIbQSKR1s=.40ad8e30-f2f9-4d14-b8b0-84f7799f688a@github.com>
References: <QgXldf9AnNqL8Vix38fsGGS0WnMTSbEO1Zo5ndd3Tdw=.5587eb0f-645d-4b9c-a6ef-87eaf8d7badf@github.com>
 <XB3CH0FfzXRlqRuGgU8ErfR4IkT1sb8rfGTIbQSKR1s=.40ad8e30-f2f9-4d14-b8b0-84f7799f688a@github.com>
Message-ID: <jHivR6hftrlZmd6Kgf2dhOcL_aU9MIIXLCduWyY8kVM=.f47a2be1-8b02-4ae2-a3af-988ea766bd70@github.com>

On Wed, 1 May 2024 17:21:20 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> A new method on Instant to return the duration `until` another Instant is suggested per the following discussion thread:
>> 
>> https://mail.openjdk.org/pipermail/core-libs-dev/2024-April/122131.html
>> 
>> A CSR has also been drafted.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Addressing CSR reviews

Marked as reviewed by rriggs (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/19007#pullrequestreview-2034423684

From jjg at openjdk.org  Wed May  1 21:19:54 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Wed, 1 May 2024 21:19:54 GMT
Subject: RFR: 8331051: Add an `@since` checker test for `java.base` module
In-Reply-To: <NRZmbFYvDwXPuizcmCilJx5Yb6HjZ-2fJa-YILxYUl8=.a79f79e4-77d5-4910-b3df-5e78bb7e402b@github.com>
References: <NRZmbFYvDwXPuizcmCilJx5Yb6HjZ-2fJa-YILxYUl8=.a79f79e4-77d5-4910-b3df-5e78bb7e402b@github.com>
Message-ID: <AfQ_W0YfDsCy5MF6k1MFdnudCJEUy4JA3sz_8o73rRk=.260aed3f-b8d5-45d7-b19b-e17560bb567a@github.com>

On Wed, 24 Apr 2024 14:10:29 GMT, Nizar Benalla <duke at openjdk.org> wrote:

> This checker checks the values of the `@since` tag found in the documentation comment for an element against the release in which the element first appeared.
> 
> Real since value of an API element is computed as the oldest release in which the given API element was introduced. That is:
> - for modules, classes and interfaces, the release in which the element with the given qualified name was introduced
> - for constructors, the release in which the constructor with the given VM descriptor was introduced
> - for methods and fields, the release in which the given method or field with the given VM descriptor became a member of its enclosing class or interface, whether direct or inherited
> 
> Effective since value of an API element is computed as follows:
> - if the given element has a `@since` tag in its javadoc, it is used
> - in all other cases, return the effective since value of the enclosing element
> 
> The since checker verifies that for every API element, the real since value and the effective since value are the same, and reports an error if they are not.
> 
> Preview method are handled as per JEP 12, if `@PreviewFeature` is used consistently going forward then the checker doesn't need to be updated with every release. The checker has explicit knowledge of preview elements that came before `JDK 14` because they weren't marked in a machine understandable way and preview elements that came before `JDK 17` that didn't have `@PreviewFeature`.
> 
> Important note : We only check code written since `JDK 9` as the releases used to determine the expected value of `@since` tags are taken from the historical data built into `javac` which only goes back that far
> 
> The intial comment at the beginning of `SinceChecker.java` holds more information into the program.
> 
> I already have filed issues and fixed some wrong tags like in #18640, #18032, #18030, #18055, #18373, #18954, #18972.

test/jdk/TEST.groups line 669:

> 667: # Set of tests for `@since` checks in source code documentation
> 668: jdk_since_check = \
> 669:    tools/sincechecker/testjavabase/CheckSince_javaBase.java

Generally, the symbol of a red line in a red circle is indicative of a missing final newline at the end of the file.
It is recommend that files end with exactly one newline character.

test/jdk/tools/sincechecker/SinceChecker.java line 53:

> 51: - This checker checks the values of the `@since` tag found in the documentation comment for an element against the release in which the element first appeared.
> 52: - The source code containing the documentation comments is read from `src.zip` in the release of JDK used to run the test.
> 53: - The releases used to determine the expected value of `@since` tags are taken from the historical data built into `javac`.

(Minor, suggest wrapping lines somewhere between 80-100 characters long)

test/jdk/tools/sincechecker/SinceChecker.java line 72:

> 70: 
> 71: Real since value of an API element is computed as the oldest release in which the given API element was introduced. That is:
> 72: - for modules, classes and interfaces, the release in which the element with the given qualified name was introduced

What about packages?  packages should be in this list as well.

test/jdk/tools/sincechecker/SinceChecker.java line 223:

> 221:             try (FileSystem zipFO = FileSystems.newFileSystem(uri, Collections.emptyMap())) {
> 222:                 Path root = zipFO.getRootDirectories().iterator().next();
> 223:                 Path packagePath = root.resolve(moduleName);

Here, and in uses of this name, including in method signatures, it is strange to see the variable named `packagePath` since it appears to be the path of the unnamed package in the module.

`modulePath` would likely be a better name, unless you are worried about possible confusion with the `--module-path` option, in which case maybe `moduleDir` or `moduleDirectory` would work.

test/jdk/tools/sincechecker/SinceChecker.java line 239:

> 237:                     } catch (Exception e) {
> 238:                         e.printStackTrace();
> 239:                         error("Initiating javadocHelperFailed " + e.getMessage());

You probably want just `e`, not `e.getMessage()` because `e` (actually `e.toString()`) will include the name of the exception as well, whereas `e.getMessage()` does not.)

test/jdk/tools/sincechecker/SinceChecker.java line 249:

> 247:     }
> 248: 
> 249:     private void processModuleCheck(ModuleElement moduleElement, JavacTask ct, Path packagePath, EffectiveSourceSinceHelper javadocHelper) {

see comment line 223, about use of `packagePath`

test/jdk/tools/sincechecker/SinceChecker.java line 280:

> 278:     }
> 279: 
> 280:     private String getModuleVersionFromFile(Path packagePath) {

see comment line 223, about `packagePath`

test/jdk/tools/sincechecker/SinceChecker.java line 296:

> 294:     }
> 295: 
> 296:     private String getPackageVersionFromFile(Path packagePath, ModuleElement.ExportsDirective ed) {

see comment line 223, about `packagePath`

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18934#discussion_r1586830124
PR Review Comment: https://git.openjdk.org/jdk/pull/18934#discussion_r1586813217
PR Review Comment: https://git.openjdk.org/jdk/pull/18934#discussion_r1586834143
PR Review Comment: https://git.openjdk.org/jdk/pull/18934#discussion_r1586823529
PR Review Comment: https://git.openjdk.org/jdk/pull/18934#discussion_r1586817831
PR Review Comment: https://git.openjdk.org/jdk/pull/18934#discussion_r1586824342
PR Review Comment: https://git.openjdk.org/jdk/pull/18934#discussion_r1586824992
PR Review Comment: https://git.openjdk.org/jdk/pull/18934#discussion_r1586825818

From duke at openjdk.org  Wed May  1 21:19:55 2024
From: duke at openjdk.org (Nizar Benalla)
Date: Wed, 1 May 2024 21:19:55 GMT
Subject: RFR: 8331051: Add an `@since` checker test for `java.base` module
In-Reply-To: <AfQ_W0YfDsCy5MF6k1MFdnudCJEUy4JA3sz_8o73rRk=.260aed3f-b8d5-45d7-b19b-e17560bb567a@github.com>
References: <NRZmbFYvDwXPuizcmCilJx5Yb6HjZ-2fJa-YILxYUl8=.a79f79e4-77d5-4910-b3df-5e78bb7e402b@github.com>
 <AfQ_W0YfDsCy5MF6k1MFdnudCJEUy4JA3sz_8o73rRk=.260aed3f-b8d5-45d7-b19b-e17560bb567a@github.com>
Message-ID: <gZ0q3FPKxA2nUXgbp2TAB9EE5mcvPXxIEggyQJNwxc4=.30ca54bc-d9ac-40d2-b6b4-40c89ac52f7b@github.com>

On Wed, 1 May 2024 20:53:08 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> This checker checks the values of the `@since` tag found in the documentation comment for an element against the release in which the element first appeared.
>> 
>> Real since value of an API element is computed as the oldest release in which the given API element was introduced. That is:
>> - for modules, classes and interfaces, the release in which the element with the given qualified name was introduced
>> - for constructors, the release in which the constructor with the given VM descriptor was introduced
>> - for methods and fields, the release in which the given method or field with the given VM descriptor became a member of its enclosing class or interface, whether direct or inherited
>> 
>> Effective since value of an API element is computed as follows:
>> - if the given element has a `@since` tag in its javadoc, it is used
>> - in all other cases, return the effective since value of the enclosing element
>> 
>> The since checker verifies that for every API element, the real since value and the effective since value are the same, and reports an error if they are not.
>> 
>> Preview method are handled as per JEP 12, if `@PreviewFeature` is used consistently going forward then the checker doesn't need to be updated with every release. The checker has explicit knowledge of preview elements that came before `JDK 14` because they weren't marked in a machine understandable way and preview elements that came before `JDK 17` that didn't have `@PreviewFeature`.
>> 
>> Important note : We only check code written since `JDK 9` as the releases used to determine the expected value of `@since` tags are taken from the historical data built into `javac` which only goes back that far
>> 
>> The intial comment at the beginning of `SinceChecker.java` holds more information into the program.
>> 
>> I already have filed issues and fixed some wrong tags like in #18640, #18032, #18030, #18055, #18373, #18954, #18972.
>
> test/jdk/tools/sincechecker/SinceChecker.java line 53:
> 
>> 51: - This checker checks the values of the `@since` tag found in the documentation comment for an element against the release in which the element first appeared.
>> 52: - The source code containing the documentation comments is read from `src.zip` in the release of JDK used to run the test.
>> 53: - The releases used to determine the expected value of `@since` tags are taken from the historical data built into `javac`.
> 
> (Minor, suggest wrapping lines somewhere between 80-100 characters long)

My idea was that, even when comparing files in a merge conflit, there wouldn't be problems here. 

But I will fix, some lines in the code are a bit long as well

> test/jdk/tools/sincechecker/SinceChecker.java line 72:
> 
>> 70: 
>> 71: Real since value of an API element is computed as the oldest release in which the given API element was introduced. That is:
>> 72: - for modules, classes and interfaces, the release in which the element with the given qualified name was introduced
> 
> What about packages?  packages should be in this list as well.

Small oversight, will fix

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18934#discussion_r1586840002
PR Review Comment: https://git.openjdk.org/jdk/pull/18934#discussion_r1586838616

From jjg at openjdk.org  Wed May  1 21:19:56 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Wed, 1 May 2024 21:19:56 GMT
Subject: RFR: 8331051: Add an `@since` checker test for `java.base` module
In-Reply-To: <_7Mrae5rQivsrCMCNaFkhYaa57PJtD3uy6IN5tP0EDA=.7d8d0679-a88f-4442-af4d-1df39aa59976@github.com>
References: <NRZmbFYvDwXPuizcmCilJx5Yb6HjZ-2fJa-YILxYUl8=.a79f79e4-77d5-4910-b3df-5e78bb7e402b@github.com>
 <uxWVocHQyxO3dccmeJEjYShE3B49Kynf6O5FTfxmZsE=.b585b19a-1216-44ca-b475-99f0003352e5@github.com>
 <_7Mrae5rQivsrCMCNaFkhYaa57PJtD3uy6IN5tP0EDA=.7d8d0679-a88f-4442-af4d-1df39aa59976@github.com>
Message-ID: <5Wc5eRtrFZ2e6SQtxrTuMvHAtss51nvBLSRX0eVid00=.0316b7ca-3a31-4f11-a72c-ac46d41a36db@github.com>

On Mon, 29 Apr 2024 11:31:23 GMT, Nizar Benalla <duke at openjdk.org> wrote:

>> test/jdk/tools/sincechecker/SinceChecker.java line 423:
>> 
>>> 421:     }
>>> 422: 
>>> 423:     //these were preview in before the introduction of the @PreviewFeature
>> 
>> Just curious: where do you find this information?
>
> Used a script to get all the elements with `@Deprecated(forRemoval=true, since=...)`, `@jdk.internal.preview`, `{@preview Associated with ....` in their javadoc.
> And then had to cross reference with a document that had all the ids

Thanks for the update

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18934#discussion_r1586827124

From joehw at openjdk.org  Wed May  1 22:33:29 2024
From: joehw at openjdk.org (Joe Wang)
Date: Wed, 1 May 2024 22:33:29 GMT
Subject: RFR: 8330542: Add two JAXP configuration files in preparation for
 a secure by default configuration [v6]
In-Reply-To: <v1bAYKgH9zfooXpvnBw4Vu2TIqHuKqqtSmgB0hiNp-Q=.31661a99-ecfc-4a05-8045-67b5f680db60@github.com>
References: <v1bAYKgH9zfooXpvnBw4Vu2TIqHuKqqtSmgB0hiNp-Q=.31661a99-ecfc-4a05-8045-67b5f680db60@github.com>
Message-ID: <EPpleChHksHT2g_WYiIpLkUd8P8bhrCQ8u1pMCGWiGA=.facdce75-f0c2-4376-b30e-587e05785899@github.com>

> Add two sample configuration files:
> 
>   jaxp-strict.properties: used to set strict configuration, stricter than jaxp.properties in previous versions such as JDK 22
> 
>   jaxp-compat.properties: used to regain compatibility from any more restricted configuration than previous versions such as JDK 22

Joe Wang has updated the pull request incrementally with one additional commit since the last revision:

  Add implNote to java.xml module summary; Update make file; Update the config files; Add test.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18831/files
  - new: https://git.openjdk.org/jdk/pull/18831/files/93b66312..af351a4d

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

  Stats: 195 lines in 6 files changed: 179 ins; 10 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/18831.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18831/head:pull/18831

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

From naoto at openjdk.org  Wed May  1 21:34:54 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 1 May 2024 21:34:54 GMT
Subject: RFR: 8295153: java/util/Base64/TestEncodingDecodingLength.java ran
 out of memory [v3]
In-Reply-To: <TJhP4Q7gj-D7yPBNJ5rKtOrh4whpgMAAFM40OUnhSvg=.e906cf18-ab71-4db5-b87c-cf8f78b61192@github.com>
References: <7WCCWuRTV5zB5_YbC57rZ-Yene5L7ky80YJscldD-lk=.53af1f27-031c-4ab4-836f-7d9a0269a42d@github.com>
 <TJhP4Q7gj-D7yPBNJ5rKtOrh4whpgMAAFM40OUnhSvg=.e906cf18-ab71-4db5-b87c-cf8f78b61192@github.com>
Message-ID: <QEvrGama46a5utZCedGI2geyX33kxfC986nLTkNCzT4=.f25f0310-2a44-478a-8207-2f9711f351ea@github.com>

On Wed, 1 May 2024 20:35:10 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please review this PR which converts _TestEncodingDecodingLength.java_ into a whitebox test which allows for testing to be done without memory usage issues.
>> 
>> Currently, the test requires about ~2.75 `Integer.MAX_VALUE` sized byte arrays worth of memory. (2 for the initial array allocation, .75 for the target array in `decode()`). While the `-Xms6g -Xmx8g` options should address this, there have been intermittent memory issues, as the underlying machine machine may be running other tests simultaneously.
>> 
>> By converting this test to a white-box test not only does it get rid of memory issues, but it also gets rid of the need to decode 2GB of data 3 times. The change is done using reflection to test the private visibility methods `encodedOutLength` and `decodedOutLength`, which the public `encode` and `decode` overloaded methods call respectively.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   reflect further review

LGTM

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

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19036#pullrequestreview-2034493941

From liach at openjdk.org  Wed May  1 22:39:05 2024
From: liach at openjdk.org (Chen Liang)
Date: Wed, 1 May 2024 22:39:05 GMT
Subject: RFR: 8323707: Adjust Classfile API's type arg model to better
 represent the embodied type [v5]
In-Reply-To: <MHOvwnWcnocbfiiIdkzyqB6qdt-f2HwiaTurds0p3Pg=.cda1d910-6ef4-4577-a539-10a959adcd1f@github.com>
References: <MHOvwnWcnocbfiiIdkzyqB6qdt-f2HwiaTurds0p3Pg=.cda1d910-6ef4-4577-a539-10a959adcd1f@github.com>
Message-ID: <vTgBP598zJ-5pso8xIU-4DTuHcRGvhTLhrbS15PQbBg=.6b225886-fe55-4a02-ae67-f0d14c710d49@github.com>

> API changes as discussed on the mailing list: https://mail.openjdk.org/pipermail/classfile-api-dev/2023-November/000419.html
> 
> Additional questions:
> 1. Whether to rename `WildcardIndicator.DEFAULT` to `NONE`

Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 15 commits:

 - Missing since tags
 - Merge branch 'master' of https://github.com/openjdk/jdk into fix/typearg-model
 - Merge branch 'master' of https://github.com/openjdk/jdk into fix/typearg-model
 - Missed renaming in tests, thanks to Adam Sotona
   
   Co-authored-by: Adam Sotona <10807609+asotona at users.noreply.github.com>
 - Rename no wildcard indicator, improve docs slightly
 - Merge branch 'master' of https://github.com/openjdk/jdk into fix/typearg-model
 - Merge branch 'master' into fix/typearg-model
 - redundant line
 - Fix a test in langtools, copyright year
 - Merge branch 'master' of https://github.com/openjdk/jdk into fix/typearg-model
 - ... and 5 more: https://git.openjdk.org/jdk/compare/0a24daec...f9af4182

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

Changes: https://git.openjdk.org/jdk/pull/16517/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16517&range=04
  Stats: 137 lines in 6 files changed: 54 ins; 32 del; 51 mod
  Patch: https://git.openjdk.org/jdk/pull/16517.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16517/head:pull/16517

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

From jpai at openjdk.org  Thu May  2 04:35:12 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 2 May 2024 04:35:12 GMT
Subject: RFR: 8331514: Tests should not use the "Classpath" exception form of
 the legal header
Message-ID: <dt7D1nPTmhc2JajCsyO71EJVn70oipJPbLJ359i-Tws=.60e18663-2a1a-4207-a7b1-3129a9f20031@github.com>

Can I please get a review of this copyright text only change which removes the "Classpath" exception from the `test/jdk/java/lang/ProcessBuilder/JspawnhelperWarnings.java` test file and thus addresses https://bugs.openjdk.org/browse/JDK-8331514?

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

Commit messages:
 - 8331514: Tests should not use the Classpath exception form of the legal header

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

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

From thartmann at openjdk.org  Thu May  2 06:02:14 2024
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Thu, 2 May 2024 06:02:14 GMT
Subject: RFR: 8331518: Tests should not use the Classpath exception form of the
 legal header
Message-ID: <_3VjI3abxvxKuqUcaQsEsEGQ1WB2MuJlk3yWn7boJxI=.c8012113-6517-434b-9dc3-ab39df449f75@github.com>

Removed the Classpath exception from the copyright header of some compiler tests and benchmarks.

Thanks,
Tobias

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

Commit messages:
 - 8331518: Tests should not use the Classpath exception form of the legal header

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

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

From asotona at openjdk.org  Thu May  2 07:31:24 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Thu, 2 May 2024 07:31:24 GMT
Subject: RFR: 8323058: Revisit j.l.classfile.CodeBuilder API surface [v7]
In-Reply-To: <HnSlddnQJi47nmj_MTxi2SooHNzaI_JCAuLk68DuxzY=.25dcf5e9-657f-4225-8952-aa4c741edb08@github.com>
References: <HnSlddnQJi47nmj_MTxi2SooHNzaI_JCAuLk68DuxzY=.25dcf5e9-657f-4225-8952-aa4c741edb08@github.com>
Message-ID: <3jiiI6zCRmVyrCg5EDrM36BhBywwFy1e9ImWT5a-8wE=.587c9ae2-3647-46db-9ec5-c908449de00e@github.com>

> `java.lang.classfile.CodeBuilder` contains more than 230 API methods.
> Existing ClassFile API use cases proved the concept one big CodeBuilder is comfortable. However there are some redundancies, glitches in the naming conventions, some frequently used methods are hard to find and some methods have low practical use.
> 
> This patch revisits the `CodeBuilder` API methods and introduces some changes.
> 
> For more details, please, visit the [CSR ](https://bugs.openjdk.org/browse/JDK-8323067)
> 
> Please review.
> 
> Thank you,
> Adam

Adam Sotona has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 16 commits:

 - fixed StringConcatFactory
 - Merge branch 'master' into JDK-8323058-CodeBuilder
 - Merge branch 'master' into JDK-8323058-CodeBuilder
   
   # Conflicts:
   #	src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java
   #	test/jdk/jdk/classfile/helpers/RebuildingTransformation.java
 - added @since 23 tags for new CodeBuilder methods
 - fixed ClassFile API use in new tests
 - Merge branch 'master' into JDK-8323058-CodeBuilder
 - removed CodeBuilder::newObject methods
 - Merge branch 'master' into JDK-8323058-CodeBuilder
   
   # Conflicts:
   #	src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java
   #	src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/SystemModulesPlugin.java
 - extended CodeBuilder::conversion functionality
 - removed CodeBuilder::newPrimitiveArray, newReferenceArray, newMultidimensionalArray and operator methods
 - ... and 6 more: https://git.openjdk.org/jdk/compare/9108091f...4b901d90

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

Changes: https://git.openjdk.org/jdk/pull/17282/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17282&range=06
  Stats: 933 lines in 53 files changed: 56 ins; 207 del; 670 mod
  Patch: https://git.openjdk.org/jdk/pull/17282.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17282/head:pull/17282

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

From dholmes at openjdk.org  Thu May  2 07:44:55 2024
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 2 May 2024 07:44:55 GMT
Subject: RFR: 8331518: Tests should not use the "Classpath" exception form
 of the legal header
In-Reply-To: <_3VjI3abxvxKuqUcaQsEsEGQ1WB2MuJlk3yWn7boJxI=.c8012113-6517-434b-9dc3-ab39df449f75@github.com>
References: <_3VjI3abxvxKuqUcaQsEsEGQ1WB2MuJlk3yWn7boJxI=.c8012113-6517-434b-9dc3-ab39df449f75@github.com>
Message-ID: <BbiWM4pDD1VTHntEjERSr1wyeuGFueJ7Ams6c7aJUWI=.7f2e10bd-be0e-4876-b989-b93fa78301da@github.com>

On Thu, 2 May 2024 05:57:50 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> Removed the Classpath exception from the copyright header of some compiler tests and benchmarks.
> 
> Thanks,
> Tobias

LGTM. Thanks. I'd consider this a trivial fix too.

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

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19047#pullrequestreview-2035042618

From thartmann at openjdk.org  Thu May  2 07:51:55 2024
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Thu, 2 May 2024 07:51:55 GMT
Subject: Integrated: 8331518: Tests should not use the "Classpath" exception
 form of the legal header
In-Reply-To: <_3VjI3abxvxKuqUcaQsEsEGQ1WB2MuJlk3yWn7boJxI=.c8012113-6517-434b-9dc3-ab39df449f75@github.com>
References: <_3VjI3abxvxKuqUcaQsEsEGQ1WB2MuJlk3yWn7boJxI=.c8012113-6517-434b-9dc3-ab39df449f75@github.com>
Message-ID: <5mrHBQlLsVmlnl8hMSirNOfnBy71QLlF7ajun-SCbFU=.ba0e51c2-4643-4cbc-bf13-cbd9d3a8a2e3@github.com>

On Thu, 2 May 2024 05:57:50 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> Removed the Classpath exception from the copyright header of some compiler tests and benchmarks.
> 
> Thanks,
> Tobias

This pull request has now been integrated.

Changeset: d3bf5262
Author:    Tobias Hartmann <thartmann at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/d3bf52628efb79e1b98749d628c4b6d035e1d511
Stats:     15 lines in 5 files changed: 0 ins; 10 del; 5 mod

8331518: Tests should not use the "Classpath" exception form of the legal header

Reviewed-by: dholmes

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

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

From thartmann at openjdk.org  Thu May  2 07:51:55 2024
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Thu, 2 May 2024 07:51:55 GMT
Subject: RFR: 8331518: Tests should not use the "Classpath" exception form
 of the legal header
In-Reply-To: <_3VjI3abxvxKuqUcaQsEsEGQ1WB2MuJlk3yWn7boJxI=.c8012113-6517-434b-9dc3-ab39df449f75@github.com>
References: <_3VjI3abxvxKuqUcaQsEsEGQ1WB2MuJlk3yWn7boJxI=.c8012113-6517-434b-9dc3-ab39df449f75@github.com>
Message-ID: <d0z8xpyvQ8s29UbsePBml0Ld9qNzxUI45ZNfIOrNWKU=.92084e4e-836f-4a6e-bf9d-7b19bf2db3ed@github.com>

On Thu, 2 May 2024 05:57:50 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> Removed the Classpath exception from the copyright header of some compiler tests and benchmarks.
> 
> Thanks,
> Tobias

Thanks for the review David!

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

PR Comment: https://git.openjdk.org/jdk/pull/19047#issuecomment-2089828156

From dfuchs at openjdk.org  Thu May  2 08:45:53 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 2 May 2024 08:45:53 GMT
Subject: RFR: 8331514: Tests should not use the "Classpath" exception form
 of the legal header
In-Reply-To: <dt7D1nPTmhc2JajCsyO71EJVn70oipJPbLJ359i-Tws=.60e18663-2a1a-4207-a7b1-3129a9f20031@github.com>
References: <dt7D1nPTmhc2JajCsyO71EJVn70oipJPbLJ359i-Tws=.60e18663-2a1a-4207-a7b1-3129a9f20031@github.com>
Message-ID: <Bgxvr0o7l5hp4nePZzPgbqEAINRcel0JXU7EO-Cxr_U=.c3409f68-624c-422f-81bc-4bea19fbaec5@github.com>

On Thu, 2 May 2024 04:29:26 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this copyright text only change which removes the "Classpath" exception from the `test/jdk/java/lang/ProcessBuilder/JspawnhelperWarnings.java` test file and thus addresses https://bugs.openjdk.org/browse/JDK-8331514?

LGTM

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

Marked as reviewed by dfuchs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19046#pullrequestreview-2035163452

From asotona at openjdk.org  Thu May  2 09:13:01 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Thu, 2 May 2024 09:13:01 GMT
Subject: RFR: 8331511: Tests should not use the "Classpath" exception form of
 the legal header
Message-ID: <VGcYJz9rnUMHKxm_IaBM-dye53uOSJ5IOyvuSiEY8h0=.f521fdc6-140f-4483-9ac6-9648fafea92c@github.com>

This patch removes "Classpath" exception from test/jdk/jdk/classfile/OptionsTest.java header.

Please review.

Thanks,
Adam

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

Commit messages:
 - 8331511: Tests should not use the "Classpath" exception form of the legal header

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

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

From asotona at openjdk.org  Thu May  2 10:10:58 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Thu, 2 May 2024 10:10:58 GMT
Subject: Integrated: 8323058: Revisit j.l.classfile.CodeBuilder API surface
In-Reply-To: <HnSlddnQJi47nmj_MTxi2SooHNzaI_JCAuLk68DuxzY=.25dcf5e9-657f-4225-8952-aa4c741edb08@github.com>
References: <HnSlddnQJi47nmj_MTxi2SooHNzaI_JCAuLk68DuxzY=.25dcf5e9-657f-4225-8952-aa4c741edb08@github.com>
Message-ID: <HkujVbj9s16waSBOdpV6JEYh72pnHpOz--Pl67pCJls=.aa91d073-d07d-4caa-a018-ae9313443d58@github.com>

On Fri, 5 Jan 2024 15:17:13 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> `java.lang.classfile.CodeBuilder` contains more than 230 API methods.
> Existing ClassFile API use cases proved the concept one big CodeBuilder is comfortable. However there are some redundancies, glitches in the naming conventions, some frequently used methods are hard to find and some methods have low practical use.
> 
> This patch revisits the `CodeBuilder` API methods and introduces some changes.
> 
> For more details, please, visit the [CSR ](https://bugs.openjdk.org/browse/JDK-8323067)
> 
> Please review.
> 
> Thank you,
> Adam

This pull request has now been integrated.

Changeset: ae82405f
Author:    Adam Sotona <asotona at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/ae82405ff7a48bc6e61b1d05bf74839b7ed50c11
Stats:     933 lines in 53 files changed: 56 ins; 207 del; 670 mod

8323058: Revisit j.l.classfile.CodeBuilder API surface

Reviewed-by: briangoetz, psandoz

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

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

From asotona at openjdk.org  Thu May  2 10:30:06 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Thu, 2 May 2024 10:30:06 GMT
Subject: RFR: 8320396: Class-File API ClassModel::verify should include
 checks from hotspot/share/classfile/classFileParser.cpp [v4]
In-Reply-To: <0a66asWcJ4_zBrjmReA18BZmsovN1ZeJRRSAPZDMZmo=.5bada03f-d88d-46cd-962d-c1e42c3048c1@github.com>
References: <0a66asWcJ4_zBrjmReA18BZmsovN1ZeJRRSAPZDMZmo=.5bada03f-d88d-46cd-962d-c1e42c3048c1@github.com>
Message-ID: <qPSb3Xaw2eNwYqG7vbfWfKbvS0doeN1yG8Uvh1dkhCE=.366c0ba1-26c5-463e-9b26-f0d9428879ea@github.com>

> ClassFile API `jdk.internal.classfile.verifier.VerifierImpl` performed only bytecode-level class verification.
> This patch adds `jdk.internal.classfile.verifier.ParserVerifier` with additional class checks inspired by `hotspot/share/classfile/classFileParser.cpp`.
> 
> Also new `VerifierSelfTest::testParserVerifier` has been added.
> 
> Please review.
> 
> Thanks,
> Adam

Adam Sotona has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 28 commits:

 - Merge branch 'master' into JDK-8320396-verifier-extension
 - added references to jvms
 - Merge remote-tracking branch 'openjdk/master' into JDK-8320396-verifier-extension
 - work in progress
 - work in progress
 - work in progress
 - work in progress
 - work in progress
 - removed string templates from test
 - work in progress
 - ... and 18 more: https://git.openjdk.org/jdk/compare/ae82405f...3ebc780a

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

Changes: https://git.openjdk.org/jdk/pull/16809/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16809&range=03
  Stats: 714 lines in 6 files changed: 680 ins; 8 del; 26 mod
  Patch: https://git.openjdk.org/jdk/pull/16809.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16809/head:pull/16809

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

From jpai at openjdk.org  Thu May  2 10:51:03 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 2 May 2024 10:51:03 GMT
Subject: RFR: 8331514: Tests should not use the "Classpath" exception form
 of the legal header
In-Reply-To: <dt7D1nPTmhc2JajCsyO71EJVn70oipJPbLJ359i-Tws=.60e18663-2a1a-4207-a7b1-3129a9f20031@github.com>
References: <dt7D1nPTmhc2JajCsyO71EJVn70oipJPbLJ359i-Tws=.60e18663-2a1a-4207-a7b1-3129a9f20031@github.com>
Message-ID: <K3mEm7GiP-LyKy-9AWUR7c6qEuoDpG0bx1VCBS-iidk=.3f363d54-33ea-4f07-aefc-bd877e3d2b53@github.com>

On Thu, 2 May 2024 04:29:26 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this copyright text only change which removes the "Classpath" exception from the `test/jdk/java/lang/ProcessBuilder/JspawnhelperWarnings.java` test file and thus addresses https://bugs.openjdk.org/browse/JDK-8331514?

Thank you Daniel for the review.

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

PR Comment: https://git.openjdk.org/jdk/pull/19046#issuecomment-2090171863

From jpai at openjdk.org  Thu May  2 10:51:03 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 2 May 2024 10:51:03 GMT
Subject: Integrated: 8331514: Tests should not use the "Classpath" exception
 form of the legal header
In-Reply-To: <dt7D1nPTmhc2JajCsyO71EJVn70oipJPbLJ359i-Tws=.60e18663-2a1a-4207-a7b1-3129a9f20031@github.com>
References: <dt7D1nPTmhc2JajCsyO71EJVn70oipJPbLJ359i-Tws=.60e18663-2a1a-4207-a7b1-3129a9f20031@github.com>
Message-ID: <tCLc6ZPo-F5bqkwQ3k8_pAmOmDigokVugE_bw1f0Dys=.afb23147-809f-4a79-87f4-293abe64f8e9@github.com>

On Thu, 2 May 2024 04:29:26 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this copyright text only change which removes the "Classpath" exception from the `test/jdk/java/lang/ProcessBuilder/JspawnhelperWarnings.java` test file and thus addresses https://bugs.openjdk.org/browse/JDK-8331514?

This pull request has now been integrated.

Changeset: c9255f3f
Author:    Jaikiran Pai <jpai at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/c9255f3f5d3b826b9502e21aa953f0cf9f9abdec
Stats:     3 lines in 1 file changed: 0 ins; 2 del; 1 mod

8331514: Tests should not use the "Classpath" exception form of the legal header

Reviewed-by: dfuchs

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

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

From asotona at openjdk.org  Thu May  2 10:53:20 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Thu, 2 May 2024 10:53:20 GMT
Subject: RFR: 8294960: Convert java.base/java.lang.invoke package to use
 the Classfile API to generate lambdas and method handles [v12]
In-Reply-To: <sP2SGhfcyggOAfbQT4Cm_lVg2Fsz3Z24PIoy2DX8WUg=.0aef65de-43fe-4140-b81d-11013c33529b@github.com>
References: <sP2SGhfcyggOAfbQT4Cm_lVg2Fsz3Z24PIoy2DX8WUg=.0aef65de-43fe-4140-b81d-11013c33529b@github.com>
Message-ID: <0RD91EJODWF6-0ZGxMuwSVt0JLopqyG9qlTt72zcBx8=.75d28623-06d4-4694-b83b-b0d85ce47631@github.com>

> java.base java.lang.invoke package heavily uses ASM to generate lambdas and method handles.
> 
> This patch converts ASM calls to Classfile API.
> 
> This PR is continuation of https://github.com/openjdk/jdk/pull/12945
> 
> Any comments and suggestions are welcome.
> 
> Please review.
> 
> Thank you,
> Adam

Adam Sotona has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 22 commits:

 - fixed CodeBuilder use in j.l.invoke
 - Merge branch 'master' into JDK-8294960-invoke
 - Merge pull request #4 from cl4es/boxunbox_holder
   
   Only create box/unbox MethodRefEntries on request
 - Only create box/unbox MethodRefEntries on request
 - Merge pull request #3 from cl4es/minor_init_improvements
   
   Reduce init overhead of InvokeBytecodeGenerator and StackMapGenerator
 - Remove stray MRE_LF_interpretWithArguments
 - Reduce init overhead of InvokeBytecodeGenerator and StackMapGenerator
 - Deferred initialization of attributes map by moving into a holder class
   
   Co-authored-by: Claes Redestad <redestad at openjdk.org>
 - Merge branch 'master' into JDK-8294960-invoke
 - Merge branch 'master' into JDK-8294960-invoke
   
   # Conflicts:
   #	src/java.base/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java
 - ... and 12 more: https://git.openjdk.org/jdk/compare/ae82405f...eea36525

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

Changes: https://git.openjdk.org/jdk/pull/17108/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17108&range=11
  Stats: 2123 lines in 11 files changed: 424 ins; 862 del; 837 mod
  Patch: https://git.openjdk.org/jdk/pull/17108.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17108/head:pull/17108

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

From asotona at openjdk.org  Thu May  2 11:08:16 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Thu, 2 May 2024 11:08:16 GMT
Subject: RFR: 8331291: java.lang.classfile.Attributes class performs a lot
 of static initializations [v4]
In-Reply-To: <SHIvjbwCWBPERKxlytEsY_O_kEiJbSeEmSusuDwjTIw=.ae8dd21e-a822-476e-9760-dd489532dbf1@github.com>
References: <SHIvjbwCWBPERKxlytEsY_O_kEiJbSeEmSusuDwjTIw=.ae8dd21e-a822-476e-9760-dd489532dbf1@github.com>
Message-ID: <OQ_7GvZY9aR_wDxoXfR3ZpnVndRz3_Y4RnuZRKsg2Do=.acfbeec6-2e24-45db-b2b7-8b5aa250a873@github.com>

> Hi,
> During performance optimization work on Class-File API as JDK lambda generator we found some static initialization killers.
> One of them is `java.lang.classfile.Attributes` with tens of static fields initialized with individual attribute mappers, and common set of all mappers, and static map from attribute names to the mappers.
> 
> I propose to turn all the static fields into lazy-initialized static methods and remove `PREDEFINED_ATTRIBUTES` and `standardAttribute(Utf8Entry name)` static mapping method from the `Attributes` API class.
>  
> Please let me know your comments or objections and please review the [PR](https://github.com/openjdk/jdk/pull/19006) and [CSR](https://bugs.openjdk.org/browse/JDK-8331414), so we can make it into 23.
> 
> Thank you,
> Adam

Adam Sotona 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 seven additional commits since the last revision:

 - Merge branch 'master' into JDK-8331291-attributes
 - changed order in allowed modules attributes check
 - added bug number
 - added impl comment
 - removed list of predefined attributes
   standard attributes mapping hard-coded and moved to BoundAttribute
   added AttributesTest::testAttributesMapping
 - move mappers implementations to AbstractAttributeMapper
 - 8331291: java.lang.classfile.Attributes class performs a lot of static initializations

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/19006/files
  - new: https://git.openjdk.org/jdk/pull/19006/files/f0d9174e..fd8da774

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

  Stats: 4061 lines in 236 files changed: 1910 ins; 657 del; 1494 mod
  Patch: https://git.openjdk.org/jdk/pull/19006.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19006/head:pull/19006

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

From asotona at openjdk.org  Thu May  2 11:13:22 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Thu, 2 May 2024 11:13:22 GMT
Subject: RFR: 8331320: ClassFile API OutOfMemoryError with certain class
 files [v2]
In-Reply-To: <XGhWV1bHWk6QqxHcnJ5y85MocUoC0YUZVRIqz1z1vXA=.9d83f151-9e5c-4189-9327-f4ac10d484c5@github.com>
References: <XGhWV1bHWk6QqxHcnJ5y85MocUoC0YUZVRIqz1z1vXA=.9d83f151-9e5c-4189-9327-f4ac10d484c5@github.com>
Message-ID: <fp1cq7bwvcmcWi93RLLhqPTDUoJXUHqqczcbPmfxIpM=.05ff67b8-818c-4789-9fe4-6d6da01ef14d@github.com>

> Class files with specifically corrupted tableswitch or lookupswitch instructions in the bytecode cause OutOfMemoryError while parsing with Class-File API.
> This patch performs additional checks to avoid OOME and adds relevant tests.
> 
> Please review.
> 
> Thank you,
> Adam

Adam Sotona has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:

 - Merge branch 'master' into JDK-8331320-OOME
 - 8331320: ClassFile API OutOfMemoryError with certain class files

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/19024/files
  - new: https://git.openjdk.org/jdk/pull/19024/files/7a3f37c1..914ae074

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

  Stats: 2966 lines in 194 files changed: 1373 ins; 409 del; 1184 mod
  Patch: https://git.openjdk.org/jdk/pull/19024.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19024/head:pull/19024

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

From wxiao at openjdk.org  Thu May  2 11:50:56 2024
From: wxiao at openjdk.org (Weibing Xiao)
Date: Thu, 2 May 2024 11:50:56 GMT
Subject: Integrated: 8331077 : nroff man page update for jar tool
In-Reply-To: <0O_4EK5PFKWHY-XCTgNyck8ILQueXJT9JVjobSG-ECw=.8e55a73a-72d5-44c6-8b16-67e71a2ed7c0@github.com>
References: <0O_4EK5PFKWHY-XCTgNyck8ILQueXJT9JVjobSG-ECw=.8e55a73a-72d5-44c6-8b16-67e71a2ed7c0@github.com>
Message-ID: <z2olIA79Zeoe4hpBIonMGiDuXnKDj_OXAJN_ipKo3hY=.bbb0a0a9-be91-465e-bf08-d47fde3a0d86@github.com>

On Wed, 1 May 2024 17:52:13 GMT, Weibing Xiao <wxiao at openjdk.org> wrote:

> nroff man page update for jar tool. <br>
> This update is caused by the change of?https://bugs.openjdk.org/browse/JDK-8318971. While the .md man pages got updated in other repos, the corresponding nroff man page was never updated in OpenJDK repos

This pull request has now been integrated.

Changeset: c21672d8
Author:    Weibing Xiao <wxiao at openjdk.org>
Committer: Sean Coffey <coffeys at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/c21672d8c94da6aa613174744ceaa945ca2a474a
Stats:     8 lines in 1 file changed: 4 ins; 0 del; 4 mod

8331077: nroff man page update for jar tool

Reviewed-by: jjg, coffeys

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

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

From asotona at openjdk.org  Thu May  2 12:03:15 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Thu, 2 May 2024 12:03:15 GMT
Subject: RFR: 8182774: Verify code in javap
Message-ID: <khSsamCrV5bkc6ySKQDBYoTHsSyjGggfqkzoc7YxfTo=.2588f7fa-e91e-4e99-bd75-1e77e4b17c6a@github.com>

This patch adds `javap -verify` option to check the class and print obvious verification errors found.
Implementation depends on extended Class-File API verification support, so PR #16809 is important to precede.
The new `javap` option is mentioned in man pages and a release note will be provided.

Please review.

Thank you,
Adam

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

Depends on: https://git.openjdk.org/jdk/pull/16809

Commit messages:
 - added VerificationTest
 - Merge branch 'JDK-8320396-verifier-extension' into JDK-8182774-javap-verify
 - added description to javap cmd help and man page
 - 8182774: Verify code in javap

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

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

From jpai at openjdk.org  Thu May  2 12:08:51 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 2 May 2024 12:08:51 GMT
Subject: RFR: 8331511: Tests should not use the "Classpath" exception form
 of the legal header
In-Reply-To: <VGcYJz9rnUMHKxm_IaBM-dye53uOSJ5IOyvuSiEY8h0=.f521fdc6-140f-4483-9ac6-9648fafea92c@github.com>
References: <VGcYJz9rnUMHKxm_IaBM-dye53uOSJ5IOyvuSiEY8h0=.f521fdc6-140f-4483-9ac6-9648fafea92c@github.com>
Message-ID: <H-Xlr3oW8zytYQMPNNKycTA0aoYyvr7puK7BAg2V0Bc=.c71440ec-8aae-4efa-bb6a-fbe10475f470@github.com>

On Thu, 2 May 2024 09:01:22 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> This patch removes "Classpath" exception from test/jdk/jdk/classfile/OptionsTest.java header.
> 
> Please review.
> 
> Thanks,
> Adam

This copyright text only change looks good to me.

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

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19050#pullrequestreview-2035564107

From alanb at openjdk.org  Thu May  2 12:13:53 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 2 May 2024 12:13:53 GMT
Subject: RFR: 8330005: RandomGeneratorFactory.getDefault() throws exception
 when the runtime image only has java.base module [v5]
In-Reply-To: <gvKhmWgKxHoB7cl9uQvGUWB5yKhqJS5NkSTHd9lPLf0=.5575df1c-8298-4682-ba3f-fc5594dc8ea2@github.com>
References: <FymnGzlEZUHwHgW6At_bqYIoF7wYsjD_vBhk60PrwFE=.1ef4072e-c3a4-4930-8d18-ba132fa90c56@github.com>
 <gvKhmWgKxHoB7cl9uQvGUWB5yKhqJS5NkSTHd9lPLf0=.5575df1c-8298-4682-ba3f-fc5594dc8ea2@github.com>
Message-ID: <QqjeU9nuzg_BW6oN2FF7DrDGICKBD23PhQHeHMqUO2Y=.97f4b7ea-c67d-4e84-a70d-fe4a3686f4dc@github.com>

On Tue, 30 Apr 2024 10:21:49 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> Move all random generators mandated in package `java.util.random` and currently implemented in module `jdk.random` to module `java.base`, and remove module `jdk.random`.
>
> Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Typo.

I assume this PR should be returned to Draft until the complete set of changes is ready.

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

PR Comment: https://git.openjdk.org/jdk/pull/18932#issuecomment-2090344307

From asotona at openjdk.org  Thu May  2 12:22:23 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Thu, 2 May 2024 12:22:23 GMT
Subject: RFR: 8182774: Verify code in javap [v2]
In-Reply-To: <khSsamCrV5bkc6ySKQDBYoTHsSyjGggfqkzoc7YxfTo=.2588f7fa-e91e-4e99-bd75-1e77e4b17c6a@github.com>
References: <khSsamCrV5bkc6ySKQDBYoTHsSyjGggfqkzoc7YxfTo=.2588f7fa-e91e-4e99-bd75-1e77e4b17c6a@github.com>
Message-ID: <2GHZB_ErRLVx9TKJmJLr_A8wfJbCHzo1K8AGUCkefTs=.fddde400-76e6-441c-8201-a78aeb745aef@github.com>

> This patch adds `javap -verify` option to check the class and print obvious verification errors found.
> Implementation depends on extended Class-File API verification support, so PR #16809 is important to precede.
> The new `javap` option is mentioned in man pages and a release note will be provided.
> 
> Please review.
> 
> Thank you,
> Adam

Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:

  fixed typo

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18629/files
  - new: https://git.openjdk.org/jdk/pull/18629/files/353dd090..48f1e7a5

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

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

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

From asotona at openjdk.org  Thu May  2 12:22:57 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Thu, 2 May 2024 12:22:57 GMT
Subject: Integrated: 8331511: Tests should not use the "Classpath" exception
 form of the legal header
In-Reply-To: <VGcYJz9rnUMHKxm_IaBM-dye53uOSJ5IOyvuSiEY8h0=.f521fdc6-140f-4483-9ac6-9648fafea92c@github.com>
References: <VGcYJz9rnUMHKxm_IaBM-dye53uOSJ5IOyvuSiEY8h0=.f521fdc6-140f-4483-9ac6-9648fafea92c@github.com>
Message-ID: <WT4AS-rKK_7ehe_w76ohBAg59q1KXVsVVFrzMMpTy3c=.0753aee7-9add-4e77-acfd-ff0dc954a9e8@github.com>

On Thu, 2 May 2024 09:01:22 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> This patch removes "Classpath" exception from test/jdk/jdk/classfile/OptionsTest.java header.
> 
> Please review.
> 
> Thanks,
> Adam

This pull request has now been integrated.

Changeset: 257a07d5
Author:    Adam Sotona <asotona at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/257a07d5ca4d876f7f79a5f2598054ca261777ee
Stats:     3 lines in 1 file changed: 0 ins; 2 del; 1 mod

8331511: Tests should not use the "Classpath" exception form of the legal header

Reviewed-by: jpai

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

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

From rgiulietti at openjdk.org  Thu May  2 12:33:52 2024
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Thu, 2 May 2024 12:33:52 GMT
Subject: RFR: 8330005: RandomGeneratorFactory.getDefault() throws exception
 when the runtime image only has java.base module [v5]
In-Reply-To: <gvKhmWgKxHoB7cl9uQvGUWB5yKhqJS5NkSTHd9lPLf0=.5575df1c-8298-4682-ba3f-fc5594dc8ea2@github.com>
References: <FymnGzlEZUHwHgW6At_bqYIoF7wYsjD_vBhk60PrwFE=.1ef4072e-c3a4-4930-8d18-ba132fa90c56@github.com>
 <gvKhmWgKxHoB7cl9uQvGUWB5yKhqJS5NkSTHd9lPLf0=.5575df1c-8298-4682-ba3f-fc5594dc8ea2@github.com>
Message-ID: <o-Gees8F7Zz6IaiV--mtreu_6XeCnpSY1MjS9g8BZVI=.ce2611d9-b36c-44ba-aa81-079660ddacd8@github.com>

On Tue, 30 Apr 2024 10:21:49 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> Move all random generators mandated in package `java.util.random` and currently implemented in module `jdk.random` to module `java.base`, and remove module `jdk.random`.
>
> Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Typo.

This PR's goal is to fix one specific problem: being able to link a minimal image containing only `java.base` while still having all _mandated_ algorithms available at runtime.
The fix does not improve on the discoverability and participation of other random generator algorithms, but it minimally contributes to solve the linking issue.
Thus, I think the proposed fix, apart from possible minor details, has a value on its own.

Work on evolving the _design aspects_ to allow additional algorithms to participate in service discovery should be done in a future PR.

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

PR Comment: https://git.openjdk.org/jdk/pull/18932#issuecomment-2090383759

From emcmanus at openjdk.org  Thu May  2 13:33:56 2024
From: emcmanus at openjdk.org (Eamonn McManus)
Date: Thu, 2 May 2024 13:33:56 GMT
Subject: RFR: 8331202: Support for Duration until another Instant [v3]
In-Reply-To: <XB3CH0FfzXRlqRuGgU8ErfR4IkT1sb8rfGTIbQSKR1s=.40ad8e30-f2f9-4d14-b8b0-84f7799f688a@github.com>
References: <QgXldf9AnNqL8Vix38fsGGS0WnMTSbEO1Zo5ndd3Tdw=.5587eb0f-645d-4b9c-a6ef-87eaf8d7badf@github.com>
 <XB3CH0FfzXRlqRuGgU8ErfR4IkT1sb8rfGTIbQSKR1s=.40ad8e30-f2f9-4d14-b8b0-84f7799f688a@github.com>
Message-ID: <mrRUE8u2xMG3g8K_V-n1KDbpnI60sSXnm4jFxXoMSto=.55ef110f-b154-44e6-8815-09c6478e38a8@github.com>

On Wed, 1 May 2024 17:21:20 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> A new method on Instant to return the duration `until` another Instant is suggested per the following discussion thread:
>> 
>> https://mail.openjdk.org/pipermail/core-libs-dev/2024-April/122131.html
>> 
>> A CSR has also been drafted.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Addressing CSR reviews

Hi, I'm on the same team as Kurt (@kluever) and I'd like to note that we think this PR is a little premature. Discussion on the core-libs-dev thread wasn't conclusive and we're not yet convinced that `until` is better than the `minus` that was originally proposed. Can we hold off for a bit while discussion on the thread continues?

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

PR Comment: https://git.openjdk.org/jdk/pull/19007#issuecomment-2090505385

From duke at openjdk.org  Thu May  2 13:45:55 2024
From: duke at openjdk.org (Nizar Benalla)
Date: Thu, 2 May 2024 13:45:55 GMT
Subject: RFR: 8331051: Add an `@since` checker test for `java.base` module
In-Reply-To: <NRZmbFYvDwXPuizcmCilJx5Yb6HjZ-2fJa-YILxYUl8=.a79f79e4-77d5-4910-b3df-5e78bb7e402b@github.com>
References: <NRZmbFYvDwXPuizcmCilJx5Yb6HjZ-2fJa-YILxYUl8=.a79f79e4-77d5-4910-b3df-5e78bb7e402b@github.com>
Message-ID: <6GXrB8KTCoG_ZVXbDlm2-u_Z6YQATjGm3770lTXPIVI=.8ff74787-bdeb-4404-9aba-5cc5b2d0288c@github.com>

On Wed, 24 Apr 2024 14:10:29 GMT, Nizar Benalla <duke at openjdk.org> wrote:

> This checker checks the values of the `@since` tag found in the documentation comment for an element against the release in which the element first appeared.
> 
> Real since value of an API element is computed as the oldest release in which the given API element was introduced. That is:
> - for modules, classes and interfaces, the release in which the element with the given qualified name was introduced
> - for constructors, the release in which the constructor with the given VM descriptor was introduced
> - for methods and fields, the release in which the given method or field with the given VM descriptor became a member of its enclosing class or interface, whether direct or inherited
> 
> Effective since value of an API element is computed as follows:
> - if the given element has a `@since` tag in its javadoc, it is used
> - in all other cases, return the effective since value of the enclosing element
> 
> The since checker verifies that for every API element, the real since value and the effective since value are the same, and reports an error if they are not.
> 
> Preview method are handled as per JEP 12, if `@PreviewFeature` is used consistently going forward then the checker doesn't need to be updated with every release. The checker has explicit knowledge of preview elements that came before `JDK 14` because they weren't marked in a machine understandable way and preview elements that came before `JDK 17` that didn't have `@PreviewFeature`.
> 
> Important note : We only check code written since `JDK 9` as the releases used to determine the expected value of `@since` tags are taken from the historical data built into `javac` which only goes back that far
> 
> The intial comment at the beginning of `SinceChecker.java` holds more information into the program.
> 
> I already have filed issues and fixed some wrong tags like in #18640, #18032, #18030, #18055, #18373, #18954, #18972.

test/jdk/tools/sincechecker/SinceChecker.java line 300:

> 298:                         .getQualifiedName()
> 299:                         .toString()
> 300:                         .replaceAll("\\.", "/")

Note for readers: I will change this tomorrow to be more platform agnostic using `File.separatorChar` instead

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18934#discussion_r1586919223

From hannesw at openjdk.org  Thu May  2 13:51:54 2024
From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Thu, 2 May 2024 13:51:54 GMT
Subject: RFR: 8331051: Add an `@since` checker test for `java.base` module
In-Reply-To: <NRZmbFYvDwXPuizcmCilJx5Yb6HjZ-2fJa-YILxYUl8=.a79f79e4-77d5-4910-b3df-5e78bb7e402b@github.com>
References: <NRZmbFYvDwXPuizcmCilJx5Yb6HjZ-2fJa-YILxYUl8=.a79f79e4-77d5-4910-b3df-5e78bb7e402b@github.com>
Message-ID: <M82KuHGrMxvqPWg068GBdy-b_Sp8mc5n5RwXkI57fkY=.43856903-9930-463c-9ebd-c8c4d2d36419@github.com>

On Wed, 24 Apr 2024 14:10:29 GMT, Nizar Benalla <duke at openjdk.org> wrote:

> This checker checks the values of the `@since` tag found in the documentation comment for an element against the release in which the element first appeared.
> 
> Real since value of an API element is computed as the oldest release in which the given API element was introduced. That is:
> - for modules, classes and interfaces, the release in which the element with the given qualified name was introduced
> - for constructors, the release in which the constructor with the given VM descriptor was introduced
> - for methods and fields, the release in which the given method or field with the given VM descriptor became a member of its enclosing class or interface, whether direct or inherited
> 
> Effective since value of an API element is computed as follows:
> - if the given element has a `@since` tag in its javadoc, it is used
> - in all other cases, return the effective since value of the enclosing element
> 
> The since checker verifies that for every API element, the real since value and the effective since value are the same, and reports an error if they are not.
> 
> Preview method are handled as per JEP 12, if `@PreviewFeature` is used consistently going forward then the checker doesn't need to be updated with every release. The checker has explicit knowledge of preview elements that came before `JDK 14` because they weren't marked in a machine understandable way and preview elements that came before `JDK 17` that didn't have `@PreviewFeature`.
> 
> Important note : We only check code written since `JDK 9` as the releases used to determine the expected value of `@since` tags are taken from the historical data built into `javac` which only goes back that far
> 
> The intial comment at the beginning of `SinceChecker.java` holds more information into the program.
> 
> I already have filed issues and fixed some wrong tags like in #18640, #18032, #18030, #18055, #18373, #18954, #18972.

test/jdk/tools/sincechecker/SinceChecker.java line 51:

> 49: 
> 50: /*
> 51: - This checker checks the values of the `@since` tag found in the documentation comment for an element against the release in which the element first appeared.

In addition to the long lines mentioned by Jon which make the comments hard to read, I find it strange that every sentence is formatted as a list item with a leading dash. I think it's ok when describing different parts/steps of the algorithm, but at least the first sentence in the comment should not be a list item IMO.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18934#discussion_r1587671249

From hannesw at openjdk.org  Thu May  2 14:08:53 2024
From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Thu, 2 May 2024 14:08:53 GMT
Subject: RFR: 8331051: Add an `@since` checker test for `java.base` module
In-Reply-To: <NRZmbFYvDwXPuizcmCilJx5Yb6HjZ-2fJa-YILxYUl8=.a79f79e4-77d5-4910-b3df-5e78bb7e402b@github.com>
References: <NRZmbFYvDwXPuizcmCilJx5Yb6HjZ-2fJa-YILxYUl8=.a79f79e4-77d5-4910-b3df-5e78bb7e402b@github.com>
Message-ID: <BLFQhjRnqOkf-bjf2ib2emZJhkTzAw7RW6RS15Uq4N4=.31e5b90c-0dcb-4f43-ae49-445bd572bbef@github.com>

On Wed, 24 Apr 2024 14:10:29 GMT, Nizar Benalla <duke at openjdk.org> wrote:

> This checker checks the values of the `@since` tag found in the documentation comment for an element against the release in which the element first appeared.
> 
> Real since value of an API element is computed as the oldest release in which the given API element was introduced. That is:
> - for modules, classes and interfaces, the release in which the element with the given qualified name was introduced
> - for constructors, the release in which the constructor with the given VM descriptor was introduced
> - for methods and fields, the release in which the given method or field with the given VM descriptor became a member of its enclosing class or interface, whether direct or inherited
> 
> Effective since value of an API element is computed as follows:
> - if the given element has a `@since` tag in its javadoc, it is used
> - in all other cases, return the effective since value of the enclosing element
> 
> The since checker verifies that for every API element, the real since value and the effective since value are the same, and reports an error if they are not.
> 
> Preview method are handled as per JEP 12, if `@PreviewFeature` is used consistently going forward then the checker doesn't need to be updated with every release. The checker has explicit knowledge of preview elements that came before `JDK 14` because they weren't marked in a machine understandable way and preview elements that came before `JDK 17` that didn't have `@PreviewFeature`.
> 
> Important note : We only check code written since `JDK 9` as the releases used to determine the expected value of `@since` tags are taken from the historical data built into `javac` which only goes back that far
> 
> The intial comment at the beginning of `SinceChecker.java` holds more information into the program.
> 
> I already have filed issues and fixed some wrong tags like in #18640, #18032, #18030, #18055, #18373, #18954, #18972.

test/jdk/tools/sincechecker/SinceChecker.java line 106:

> 104:     public static void main(String[] args) throws Exception {
> 105:         if (args.length == 0) {
> 106:             throw new SkippedException("Test module not specified");

I don't think `SkippedException` is the right exception to throw here, since invoking the method with a missing argument is probably a configuration error that shouldn't be ignored. Maybe `IllegalArgumentException` or just `RuntimeException`?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18934#discussion_r1587701335

From hannesw at openjdk.org  Thu May  2 14:30:56 2024
From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Thu, 2 May 2024 14:30:56 GMT
Subject: RFR: 8331051: Add an `@since` checker test for `java.base` module
In-Reply-To: <NRZmbFYvDwXPuizcmCilJx5Yb6HjZ-2fJa-YILxYUl8=.a79f79e4-77d5-4910-b3df-5e78bb7e402b@github.com>
References: <NRZmbFYvDwXPuizcmCilJx5Yb6HjZ-2fJa-YILxYUl8=.a79f79e4-77d5-4910-b3df-5e78bb7e402b@github.com>
Message-ID: <MVN0uGgJABi_8BAhrMaULafTnvVwcymdQam6whrom-s=.ae28c02e-4aa4-4017-8987-dd4b772fc20c@github.com>

On Wed, 24 Apr 2024 14:10:29 GMT, Nizar Benalla <duke at openjdk.org> wrote:

> This checker checks the values of the `@since` tag found in the documentation comment for an element against the release in which the element first appeared.
> 
> Real since value of an API element is computed as the oldest release in which the given API element was introduced. That is:
> - for modules, classes and interfaces, the release in which the element with the given qualified name was introduced
> - for constructors, the release in which the constructor with the given VM descriptor was introduced
> - for methods and fields, the release in which the given method or field with the given VM descriptor became a member of its enclosing class or interface, whether direct or inherited
> 
> Effective since value of an API element is computed as follows:
> - if the given element has a `@since` tag in its javadoc, it is used
> - in all other cases, return the effective since value of the enclosing element
> 
> The since checker verifies that for every API element, the real since value and the effective since value are the same, and reports an error if they are not.
> 
> Preview method are handled as per JEP 12, if `@PreviewFeature` is used consistently going forward then the checker doesn't need to be updated with every release. The checker has explicit knowledge of preview elements that came before `JDK 14` because they weren't marked in a machine understandable way and preview elements that came before `JDK 17` that didn't have `@PreviewFeature`.
> 
> Important note : We only check code written since `JDK 9` as the releases used to determine the expected value of `@since` tags are taken from the historical data built into `javac` which only goes back that far
> 
> The intial comment at the beginning of `SinceChecker.java` holds more information into the program.
> 
> I already have filed issues and fixed some wrong tags like in #18640, #18032, #18030, #18055, #18373, #18954, #18972.

test/jdk/tools/sincechecker/SinceChecker.java line 175:

> 173:     }
> 174: 
> 175:     public void persistElement(Element explicitOwner, Element element, Types types, String version) {

I'm not sure `persistElement` is a good name for this, it sounds like the element is being stored permanently (beyond the runtime of this program). I can't think of a really good name, but I think `processElement` would be ok.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18934#discussion_r1587736640

From liach at openjdk.org  Thu May  2 14:43:00 2024
From: liach at openjdk.org (Chen Liang)
Date: Thu, 2 May 2024 14:43:00 GMT
Subject: RFR: 8331291: java.lang.classfile.Attributes class performs a lot
 of static initializations [v4]
In-Reply-To: <OQ_7GvZY9aR_wDxoXfR3ZpnVndRz3_Y4RnuZRKsg2Do=.acfbeec6-2e24-45db-b2b7-8b5aa250a873@github.com>
References: <SHIvjbwCWBPERKxlytEsY_O_kEiJbSeEmSusuDwjTIw=.ae8dd21e-a822-476e-9760-dd489532dbf1@github.com>
 <OQ_7GvZY9aR_wDxoXfR3ZpnVndRz3_Y4RnuZRKsg2Do=.acfbeec6-2e24-45db-b2b7-8b5aa250a873@github.com>
Message-ID: <FoflkW6Ead7EClZw5ub9wXq1-Rrr392uqsVVSw4m_Wc=.4eb1899f-ce8c-443e-b19b-b9c1ceca99fa@github.com>

On Thu, 2 May 2024 11:08:16 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> Hi,
>> During performance optimization work on Class-File API as JDK lambda generator we found some static initialization killers.
>> One of them is `java.lang.classfile.Attributes` with tens of static fields initialized with individual attribute mappers, and common set of all mappers, and static map from attribute names to the mappers.
>> 
>> I propose to turn all the static fields into lazy-initialized static methods and remove `PREDEFINED_ATTRIBUTES` and `standardAttribute(Utf8Entry name)` static mapping method from the `Attributes` API class.
>>  
>> Please let me know your comments or objections and please review the [PR](https://github.com/openjdk/jdk/pull/19006) and [CSR](https://bugs.openjdk.org/browse/JDK-8331414), so we can make it into 23.
>> 
>> Thank you,
>> Adam
>
> Adam Sotona 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 seven additional commits since the last revision:
> 
>  - Merge branch 'master' into JDK-8331291-attributes
>  - changed order in allowed modules attributes check
>  - added bug number
>  - added impl comment
>  - removed list of predefined attributes
>    standard attributes mapping hard-coded and moved to BoundAttribute
>    added AttributesTest::testAttributesMapping
>  - move mappers implementations to AbstractAttributeMapper
>  - 8331291: java.lang.classfile.Attributes class performs a lot of static initializations

On a side note, will we update JEP 466 to include this patch?

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

Marked as reviewed by liach (Author).

PR Review: https://git.openjdk.org/jdk/pull/19006#pullrequestreview-2035945054

From hannesw at openjdk.org  Thu May  2 14:44:56 2024
From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Thu, 2 May 2024 14:44:56 GMT
Subject: RFR: 8331051: Add an `@since` checker test for `java.base` module
In-Reply-To: <NRZmbFYvDwXPuizcmCilJx5Yb6HjZ-2fJa-YILxYUl8=.a79f79e4-77d5-4910-b3df-5e78bb7e402b@github.com>
References: <NRZmbFYvDwXPuizcmCilJx5Yb6HjZ-2fJa-YILxYUl8=.a79f79e4-77d5-4910-b3df-5e78bb7e402b@github.com>
Message-ID: <Qn5SDysp-tW68iNftTMsYx61bez6IomtmKVMvInGgps=.4b1a4c30-dd0c-4a18-9c6d-0e715ca1493e@github.com>

On Wed, 24 Apr 2024 14:10:29 GMT, Nizar Benalla <duke at openjdk.org> wrote:

> This checker checks the values of the `@since` tag found in the documentation comment for an element against the release in which the element first appeared.
> 
> Real since value of an API element is computed as the oldest release in which the given API element was introduced. That is:
> - for modules, classes and interfaces, the release in which the element with the given qualified name was introduced
> - for constructors, the release in which the constructor with the given VM descriptor was introduced
> - for methods and fields, the release in which the given method or field with the given VM descriptor became a member of its enclosing class or interface, whether direct or inherited
> 
> Effective since value of an API element is computed as follows:
> - if the given element has a `@since` tag in its javadoc, it is used
> - in all other cases, return the effective since value of the enclosing element
> 
> The since checker verifies that for every API element, the real since value and the effective since value are the same, and reports an error if they are not.
> 
> Preview method are handled as per JEP 12, if `@PreviewFeature` is used consistently going forward then the checker doesn't need to be updated with every release. The checker has explicit knowledge of preview elements that came before `JDK 14` because they weren't marked in a machine understandable way and preview elements that came before `JDK 17` that didn't have `@PreviewFeature`.
> 
> Important note : We only check code written since `JDK 9` as the releases used to determine the expected value of `@since` tags are taken from the historical data built into `javac` which only goes back that far
> 
> The intial comment at the beginning of `SinceChecker.java` holds more information into the program.
> 
> I already have filed issues and fixed some wrong tags like in #18640, #18032, #18030, #18055, #18373, #18954, #18972.

test/jdk/tools/sincechecker/SinceChecker.java line 216:

> 214:             srcZip = testJdk.getParent().resolve("images").resolve("jdk").resolve("lib").resolve("src.zip");
> 215:         }
> 216:         if (!Files.exists(srcZip) && !Files.isDirectory(srcZip)) {

This condition looks wrong. If `exists` returns false, it also implies that `isDirectory` returns false. I think there's no need to check for a (not-)directory here.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18934#discussion_r1587758643

From rriggs at openjdk.org  Thu May  2 14:47:56 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 2 May 2024 14:47:56 GMT
Subject: RFR: 8331202: Support for Duration until another Instant [v3]
In-Reply-To: <XB3CH0FfzXRlqRuGgU8ErfR4IkT1sb8rfGTIbQSKR1s=.40ad8e30-f2f9-4d14-b8b0-84f7799f688a@github.com>
References: <QgXldf9AnNqL8Vix38fsGGS0WnMTSbEO1Zo5ndd3Tdw=.5587eb0f-645d-4b9c-a6ef-87eaf8d7badf@github.com>
 <XB3CH0FfzXRlqRuGgU8ErfR4IkT1sb8rfGTIbQSKR1s=.40ad8e30-f2f9-4d14-b8b0-84f7799f688a@github.com>
Message-ID: <yLXQPs61aakrDx6PMXbStAx4bocPImQT44Be-aLWa9w=.046922bc-0561-4bef-981b-c3d173d246a8@github.com>

On Wed, 1 May 2024 17:21:20 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> A new method on Instant to return the duration `until` another Instant is suggested per the following discussion thread:
>> 
>> https://mail.openjdk.org/pipermail/core-libs-dev/2024-April/122131.html
>> 
>> A CSR has also been drafted.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Addressing CSR reviews

@kluever Your comment isn't visible yet, there's a checkbox to accept OpenJDK terms.
It would be good to know what you've commented.

My reservation about `minus(Instant)` is that all of the current `minus(...)` methods return an `Instant` as do the `plus(...)` methods.
Adding a `minus` method that returns `Duration` adds a bit of fuzziness to the plus and minus method uses.
A similar concern could be raised about adding `Duration until(Instant)` as there is already a `until(Temporarl, TemporalUnit)` method. But there is smaller opportunity to mix them up.

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

PR Comment: https://git.openjdk.org/jdk/pull/19007#issuecomment-2090693079

From kak at google.com  Thu May  2 14:57:54 2024
From: kak at google.com (Kurt Alfred Kluever)
Date: Thu, 2 May 2024 10:57:54 -0400
Subject: In support of Instant.minus(Instant)
In-Reply-To: <81a8ee1c-807e-4a0b-8320-ff892fca76c0@oracle.com>
References: <CAB3z6AiAvi2q12dB761fYTx8a6qV9syu6HGUq=vkR-dcYZyv=Q@mail.gmail.com>
 <CACzrW9CgGc=qNhmhyTNKponBSP1g37t1tNFkpeGj7oqGtn7ihA@mail.gmail.com>
 <81a8ee1c-807e-4a0b-8320-ff892fca76c0@oracle.com>
Message-ID: <CAB3z6Aj9cev+JvCSGFRpOW6UEKmNQJsACzR-BnBxZpZP+3YJvg@mail.gmail.com>

Hi all,

Thanks for filing JDK-8331202 (https://bugs.openjdk.org/browse/JDK-8331202).

I think this proposal is definitely a step in the right direction. The
Instant instance method is much more discoverable than the Duration static
method. I also think there's a much lower chance of users accidentally
swapping the arguments.

However, I still have concerns about the method name (and thus indirectly
the ordering of the arguments). Users are very accustomed to performing
this calculation with primitives as (end - start). This is a basic, common,
familiar way of thinking about this operation (especially with primitives),
and it's a good idea to lean into that familiarity. I understand there's
some precedent for until() (thanks for pointing this out, Stephen!), but I
think it requires too much "mental gymnastics" to translate from conceptual
model to Actual Code.

Kevin Bourillion has written a great programming guide called "How to Think
About Time" (internal to Google for now, but we hope to publish it sometime
later this year). One section enumerates the available math operations for
the time types:

   - instant ? instant = duration // what we're discussing
   - instant + duration = instant // satisfied by instant.plus(duration)
   - instant - duration = instant // satisfied by instant.minus(duration)
   - duration + duration = duration // satisfied by duration.plus(duration)
   - duration - duration = duration // satisfied by duration.minus(duration)
   - duration ? real number = duration // satisfied by
   duration.multipliedBy(long)
   - duration ? real number = duration // satisfied by
   duration.dividedBy(long)

All but the first operation have very clear translations from conceptual
model to code. I'm hoping we can achieve the same clarity for instant -
instant by using the obvious name: instant.minus(instant)

Thanks!

-Kurt Alfred Kluever

On Fri, Apr 26, 2024 at 11:07?AM Roger Riggs <roger.riggs at oracle.com> wrote:

> A constructive API enhancement.
> Created  JDK-8331202 <https://bugs.openjdk.org/browse/JDK-8331202>
> Support for duration between Instants
>
> Regards, Roger
>
> On 4/25/24 4:53 PM, Stephen Colebourne wrote:
>
> java.time.* already has the `until(ChronoLocalDate)` method on
> LocalDate. It would be reasonable to add a similar method to various
> other classes. This potentially gives you
>
>  Duration dur = start.until(end)
>
> I'm wary of adding the opposite (given until() is already there). I'm
> particularly wary of using minus() as the verb for the opposite as
> minus() means something different in other parts of the API (minus()
> is used to subtract a TemporalAmounrt, not a Temporal).
>
> Stephen
>
>
> On Thu, 25 Apr 2024 at 19:57, Kurt Alfred Kluever <kak at google.com> <kak at google.com> wrote:
>
> Hi core-libs-dev,
>
> The java.time API already supports subtracting two Instants (end - start) via Duration.between(Temporal, Temporal), but we've found the parameter ordering (which requires a bit of "mental gymnastics") and API location to be a bit unnatural.
>
> Parameter Ordering
>
> We very often see folks write code like this: Duration elapsed = Duration.ofMillis(end.toEpochMilli() - start.toEpochMilli());
>
> This closely matches the mental model of what they're trying to accomplish, but it is longer (and more complex) than it needs to be, it drops sub-millisecond precision, and it requires decomposing the java.time types (which we strongly discourage). If you want to "simplify" the above statement, you must remember to swap the argument order: Duration elapsed = Duration.between(start, end);
>
> Many of us find representing (end - start) as between(start, end) to be confusing.
>
> API Location
>
> We do not believe Duration is the most obvious place to find this method; if you want a way to subtract two Instant values, an instance method on Instant is a more obvious place to look. Pushing what could be an instance method to a static utility method feels unnatural.
>
> JDK-8276624 (https://bugs.openjdk.org/browse/JDK-8276624) proposes to add Temporal.minus(Temporal) as a default method (which would effectively accomplish the same thing), but we do not recommend implementing that proposal as specified. A default method on Temporal would require runtime exceptions to be thrown from other Temporal types like LocalDate or Year. It would also allow oddities like instant.minus(year) to compile (but presumably throw at runtime). Conceptually, this API would not make sense for certain types (e.g., LocalDate ? the difference between two LocalDates is a Period, not a Duration).
>
> Instead, we recommend adding a new instance method: instant.minus(instant) (which returns a Duration), and possibly also adding localDate.minus(localDate) (which returns a Period). However note that we've seen a lot of confusion using the Period API (but that's a separate discussion).
>
> While we generally don't like having 2 public APIs that accomplish the same thing, in this case we feel the discoverability and simplicity of the new API(s) outweighs the cost of an additional public API.
>
> Please consider this a +1 from our team to add instant.minus(instant).
>
> Regards,
>
> -Kurt Alfred Kluever (kak at google.com)
> (on behalf of Google's Java and Kotlin Ecosystem Team, aka the Guava team)
>
>
>

-- 
kak
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240502/a4e56de9/attachment.htm>

From psandoz at openjdk.org  Thu May  2 16:13:55 2024
From: psandoz at openjdk.org (Paul Sandoz)
Date: Thu, 2 May 2024 16:13:55 GMT
Subject: RFR: 8331320: ClassFile API OutOfMemoryError with certain class
 files [v2]
In-Reply-To: <fp1cq7bwvcmcWi93RLLhqPTDUoJXUHqqczcbPmfxIpM=.05ff67b8-818c-4789-9fe4-6d6da01ef14d@github.com>
References: <XGhWV1bHWk6QqxHcnJ5y85MocUoC0YUZVRIqz1z1vXA=.9d83f151-9e5c-4189-9327-f4ac10d484c5@github.com>
 <fp1cq7bwvcmcWi93RLLhqPTDUoJXUHqqczcbPmfxIpM=.05ff67b8-818c-4789-9fe4-6d6da01ef14d@github.com>
Message-ID: <MHlA5R_KNrX-nK5P0Je_zwei-o877hNf4VfdIZAL6Yo=.7bb91e23-4f47-4fa3-a38e-6a3761d69a2a@github.com>

On Thu, 2 May 2024 11:13:22 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> Class files with specifically corrupted tableswitch or lookupswitch instructions in the bytecode cause OutOfMemoryError while parsing with Class-File API.
>> This patch performs additional checks to avoid OOME and adds relevant tests.
>> 
>> Please review.
>> 
>> Thank you,
>> Adam
>
> Adam Sotona has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:
> 
>  - Merge branch 'master' into JDK-8331320-OOME
>  - 8331320: ClassFile API OutOfMemoryError with certain class files

Marked as reviewed by psandoz (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/19024#pullrequestreview-2036210957

From naoto at openjdk.org  Thu May  2 16:14:53 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 2 May 2024 16:14:53 GMT
Subject: RFR: 8331202: Support for Duration until another Instant [v3]
In-Reply-To: <XB3CH0FfzXRlqRuGgU8ErfR4IkT1sb8rfGTIbQSKR1s=.40ad8e30-f2f9-4d14-b8b0-84f7799f688a@github.com>
References: <QgXldf9AnNqL8Vix38fsGGS0WnMTSbEO1Zo5ndd3Tdw=.5587eb0f-645d-4b9c-a6ef-87eaf8d7badf@github.com>
 <XB3CH0FfzXRlqRuGgU8ErfR4IkT1sb8rfGTIbQSKR1s=.40ad8e30-f2f9-4d14-b8b0-84f7799f688a@github.com>
Message-ID: <sQ-s3ZDEgV497Qb_bBhBQT8KVhZEhHzTdUAurFeQypM=.dc305f2c-9a61-4582-848a-090ff11b39cd@github.com>

On Wed, 1 May 2024 17:21:20 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> A new method on Instant to return the duration `until` another Instant is suggested per the following discussion thread:
>> 
>> https://mail.openjdk.org/pipermail/core-libs-dev/2024-April/122131.html
>> 
>> A CSR has also been drafted.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Addressing CSR reviews

+1 to Roger's observation. Adding a conceptually different `minus` method would be confusing.

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

PR Comment: https://git.openjdk.org/jdk/pull/19007#issuecomment-2090926275

From scolebourne at joda.org  Thu May  2 17:04:20 2024
From: scolebourne at joda.org (Stephen Colebourne)
Date: Thu, 2 May 2024 18:04:20 +0100
Subject: In support of Instant.minus(Instant)
In-Reply-To: <CAB3z6Aj9cev+JvCSGFRpOW6UEKmNQJsACzR-BnBxZpZP+3YJvg@mail.gmail.com>
References: <CAB3z6AiAvi2q12dB761fYTx8a6qV9syu6HGUq=vkR-dcYZyv=Q@mail.gmail.com>
 <CACzrW9CgGc=qNhmhyTNKponBSP1g37t1tNFkpeGj7oqGtn7ihA@mail.gmail.com>
 <81a8ee1c-807e-4a0b-8320-ff892fca76c0@oracle.com>
 <CAB3z6Aj9cev+JvCSGFRpOW6UEKmNQJsACzR-BnBxZpZP+3YJvg@mail.gmail.com>
Message-ID: <CACzrW9AWCDYJdM7Y0rxpf8EeOohKLVnxwpKOa_KGWaVoZK2nvQ@mail.gmail.com>

On Thu, 2 May 2024 at 15:58, Kurt Alfred Kluever <kak at google.com> wrote:
> instant ? instant = duration // what we're discussing
> instant + duration = instant // satisfied by instant.plus(duration)
> instant - duration = instant // satisfied by instant.minus(duration)
> duration + duration = duration // satisfied by duration.plus(duration)
> duration - duration = duration // satisfied by duration.minus(duration)
> duration ? real number = duration // satisfied by duration.multipliedBy(long)
> duration ? real number = duration // satisfied by duration.dividedBy(long)
>
> All but the first operation have very clear translations from conceptual model to code. I'm hoping we can achieve the same clarity for instant - instant by using the obvious name: instant.minus(instant)

But you can't have
 instant + instant = ???
It doesn't make sense.

This is at the heart of why minus isn't right in this case.
Stephen

From cushon at openjdk.org  Thu May  2 17:20:54 2024
From: cushon at openjdk.org (Liam Miller-Cushon)
Date: Thu, 2 May 2024 17:20:54 GMT
Subject: RFR: 8328995: launcher can't open jar files where the offset of
 the manifest is >4GB [v6]
In-Reply-To: <mFJD586uS9BKVdghAP0y8c1qkULzQbEgypPZwkd2YDI=.4c643822-c8b2-41ad-955a-2420c7e0af5e@github.com>
References: <bgsm1_QUL0EbnTCEdpLZq2KV5kJJ2vB-A_E6uBOFi3c=.f322218f-d68e-428b-b518-bb51dfc470b7@github.com>
 <mFJD586uS9BKVdghAP0y8c1qkULzQbEgypPZwkd2YDI=.4c643822-c8b2-41ad-955a-2420c7e0af5e@github.com>
Message-ID: <VFuDxLuTusX92xrPzCW2OkZc8q0ojzRcRZa9acDzW7M=.ce2206fd-d8c3-4d2a-8963-64eb56668ef8@github.com>

On Thu, 4 Apr 2024 16:57:40 GMT, Liam Miller-Cushon <cushon at openjdk.org> wrote:

>> This change fixes a zip64 bug in the launcher that is prevent it from reading the manifest of jars where the 'relative offset of local header' field in the central directory entry is >4GB. As described in APPNOTE.TXT 4.5.3, the offset is too large to be stored in the central directory it is stored in a 'Zip64 Extended Information Extra Field'.
>
> Liam Miller-Cushon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Move test to test/jdk/tools/launcher

> To avoid this, simply add a new comment to the pull request. Feel free to ask for assistance if you need help with progressing this pull request towards integration!

Please keep this open, assistance on progressing this pull request is welcome

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

PR Comment: https://git.openjdk.org/jdk/pull/18479#issuecomment-2091104044

From alanb at openjdk.org  Thu May  2 17:26:53 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 2 May 2024 17:26:53 GMT
Subject: RFR: 8328995: launcher can't open jar files where the offset of
 the manifest is >4GB [v6]
In-Reply-To: <VFuDxLuTusX92xrPzCW2OkZc8q0ojzRcRZa9acDzW7M=.ce2206fd-d8c3-4d2a-8963-64eb56668ef8@github.com>
References: <bgsm1_QUL0EbnTCEdpLZq2KV5kJJ2vB-A_E6uBOFi3c=.f322218f-d68e-428b-b518-bb51dfc470b7@github.com>
 <mFJD586uS9BKVdghAP0y8c1qkULzQbEgypPZwkd2YDI=.4c643822-c8b2-41ad-955a-2420c7e0af5e@github.com>
 <VFuDxLuTusX92xrPzCW2OkZc8q0ojzRcRZa9acDzW7M=.ce2206fd-d8c3-4d2a-8963-64eb56668ef8@github.com>
Message-ID: <JXIWpAbCK7zFwSY-r6TKAdERscSrUGasJqlEWlnA6FI=.04074f3f-0de1-407a-b98f-5768f83df4e9@github.com>

On Thu, 2 May 2024 17:17:54 GMT, Liam Miller-Cushon <cushon at openjdk.org> wrote:

> Please keep this open, assistance on progressing this pull request is welcome

ACK. There was a lengthy bug tail when zip64 support was added. We've got away without needing this for executable JAR files for a long time so it's great to see effort on it. I think it will take time to review closely.

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

PR Comment: https://git.openjdk.org/jdk/pull/18479#issuecomment-2091116931

From lowasser at google.com  Thu May  2 17:28:53 2024
From: lowasser at google.com (Louis Wasserman)
Date: Thu, 2 May 2024 10:28:53 -0700
Subject: In support of Instant.minus(Instant)
In-Reply-To: <CACzrW9AWCDYJdM7Y0rxpf8EeOohKLVnxwpKOa_KGWaVoZK2nvQ@mail.gmail.com>
References: <CAB3z6AiAvi2q12dB761fYTx8a6qV9syu6HGUq=vkR-dcYZyv=Q@mail.gmail.com>
 <CACzrW9CgGc=qNhmhyTNKponBSP1g37t1tNFkpeGj7oqGtn7ihA@mail.gmail.com>
 <81a8ee1c-807e-4a0b-8320-ff892fca76c0@oracle.com>
 <CAB3z6Aj9cev+JvCSGFRpOW6UEKmNQJsACzR-BnBxZpZP+3YJvg@mail.gmail.com>
 <CACzrW9AWCDYJdM7Y0rxpf8EeOohKLVnxwpKOa_KGWaVoZK2nvQ@mail.gmail.com>
Message-ID: <CAGB9EW8fST6o4q7yqZxGO7OTkU52LYGSheHz+G0+R2OyA40uTQ@mail.gmail.com>

That doesn't follow for me at all.

The structure formed by Instants and Durations is an affine space
<https://en.wikipedia.org/wiki/Affine_space#Definition>, with instants the
points and durations the vectors.  (An affine space is a vector space
without a distinguished origin, which of course Instants don't have.)  It
is 100% standard to use the minus sign for the operation "point - point =
vector," even when "point + point" is not defined, and to use all the other
standard idioms for subtraction; the Wikipedia article uses "subtraction"
and "difference" ubiquitously.

Personally, I'd be willing to live with a different name for the operation,
but consider "users keep getting it wrong" a strong enough argument all by
itself for a version with the swapped argument order; it's not obvious to
me that another API with the same argument order adds enough value over
Duration.between to bother with.

On Thu, May 2, 2024 at 10:04?AM Stephen Colebourne <scolebourne at joda.org>
wrote:

> On Thu, 2 May 2024 at 15:58, Kurt Alfred Kluever <kak at google.com> wrote:
> > instant ? instant = duration // what we're discussing
> > instant + duration = instant // satisfied by instant.plus(duration)
> > instant - duration = instant // satisfied by instant.minus(duration)
> > duration + duration = duration // satisfied by duration.plus(duration)
> > duration - duration = duration // satisfied by duration.minus(duration)
> > duration ? real number = duration // satisfied by
> duration.multipliedBy(long)
> > duration ? real number = duration // satisfied by
> duration.dividedBy(long)
> >
> > All but the first operation have very clear translations from conceptual
> model to code. I'm hoping we can achieve the same clarity for instant -
> instant by using the obvious name: instant.minus(instant)
>
> But you can't have
>  instant + instant = ???
> It doesn't make sense.
>
> This is at the heart of why minus isn't right in this case.
> Stephen
>


-- 
Louis Wasserman (he/they)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240502/ef970768/attachment-0001.htm>

From emcmanus at google.com  Thu May  2 17:41:16 2024
From: emcmanus at google.com (=?UTF-8?Q?=C3=89amonn_McManus?=)
Date: Thu, 2 May 2024 10:41:16 -0700
Subject: In support of Instant.minus(Instant)
In-Reply-To: <CAGB9EW8fST6o4q7yqZxGO7OTkU52LYGSheHz+G0+R2OyA40uTQ@mail.gmail.com>
References: <CAB3z6AiAvi2q12dB761fYTx8a6qV9syu6HGUq=vkR-dcYZyv=Q@mail.gmail.com>
 <CACzrW9CgGc=qNhmhyTNKponBSP1g37t1tNFkpeGj7oqGtn7ihA@mail.gmail.com>
 <81a8ee1c-807e-4a0b-8320-ff892fca76c0@oracle.com>
 <CAB3z6Aj9cev+JvCSGFRpOW6UEKmNQJsACzR-BnBxZpZP+3YJvg@mail.gmail.com>
 <CACzrW9AWCDYJdM7Y0rxpf8EeOohKLVnxwpKOa_KGWaVoZK2nvQ@mail.gmail.com>
 <CAGB9EW8fST6o4q7yqZxGO7OTkU52LYGSheHz+G0+R2OyA40uTQ@mail.gmail.com>
Message-ID: <CAChqX892D+f+xkoFJ4E=FcdZbeSaEuYzy5Z0JVP7U0Rohg+uOA@mail.gmail.com>

I'd say too that this makes intuitive sense based on algebra. If we have:
*instant1* + *duration* = *instant2*
then we can subtract *duration* from both sides:
*instant1 = instant2 - duration*
or we can subtract *instant1* from both sides:
*duration = instant2 - instant1*

There's no manipulation we can do that would cause us to try to add
instants together, and it's a bit surprising for the API to allow the first
subtraction but not the second.
I also think that if I see instant2.minus(instant1) it's immediately
obvious to me what that means, while instant1.until(instant2) seems both
less discoverable and less obvious.

On Thu, 2 May 2024 at 10:29, Louis Wasserman <lowasser at google.com> wrote:

> That doesn't follow for me at all.
>
> The structure formed by Instants and Durations is an affine space
> <https://en.wikipedia.org/wiki/Affine_space#Definition>, with instants
> the points and durations the vectors.  (An affine space is a vector space
> without a distinguished origin, which of course Instants don't have.)  It
> is 100% standard to use the minus sign for the operation "point - point =
> vector," even when "point + point" is not defined, and to use all the other
> standard idioms for subtraction; the Wikipedia article uses "subtraction"
> and "difference" ubiquitously.
>
> Personally, I'd be willing to live with a different name for the
> operation, but consider "users keep getting it wrong" a strong enough
> argument all by itself for a version with the swapped argument order; it's
> not obvious to me that another API with the same argument order adds enough
> value over Duration.between to bother with.
>
> On Thu, May 2, 2024 at 10:04?AM Stephen Colebourne <scolebourne at joda.org>
> wrote:
>
>> On Thu, 2 May 2024 at 15:58, Kurt Alfred Kluever <kak at google.com> wrote:
>> > instant ? instant = duration // what we're discussing
>> > instant + duration = instant // satisfied by instant.plus(duration)
>> > instant - duration = instant // satisfied by instant.minus(duration)
>> > duration + duration = duration // satisfied by duration.plus(duration)
>> > duration - duration = duration // satisfied by duration.minus(duration)
>> > duration ? real number = duration // satisfied by
>> duration.multipliedBy(long)
>> > duration ? real number = duration // satisfied by
>> duration.dividedBy(long)
>> >
>> > All but the first operation have very clear translations from
>> conceptual model to code. I'm hoping we can achieve the same clarity for
>> instant - instant by using the obvious name: instant.minus(instant)
>>
>> But you can't have
>>  instant + instant = ???
>> It doesn't make sense.
>>
>> This is at the heart of why minus isn't right in this case.
>> Stephen
>>
>
>
> --
> Louis Wasserman (he/they)
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240502/e674b4f2/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4014 bytes
Desc: S/MIME Cryptographic Signature
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240502/e674b4f2/smime.p7s>

From asotona at openjdk.org  Thu May  2 18:10:56 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Thu, 2 May 2024 18:10:56 GMT
Subject: Integrated: 8331320: ClassFile API OutOfMemoryError with certain class
 files
In-Reply-To: <XGhWV1bHWk6QqxHcnJ5y85MocUoC0YUZVRIqz1z1vXA=.9d83f151-9e5c-4189-9327-f4ac10d484c5@github.com>
References: <XGhWV1bHWk6QqxHcnJ5y85MocUoC0YUZVRIqz1z1vXA=.9d83f151-9e5c-4189-9327-f4ac10d484c5@github.com>
Message-ID: <WZptkdyHrwQG8AbFv9lb9nBi6-7ahG1paLIIaRybowg=.a8635c10-9f15-4b94-b907-d84ad2ce63ae@github.com>

On Tue, 30 Apr 2024 15:31:02 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> Class files with specifically corrupted tableswitch or lookupswitch instructions in the bytecode cause OutOfMemoryError while parsing with Class-File API.
> This patch performs additional checks to avoid OOME and adds relevant tests.
> 
> Please review.
> 
> Thank you,
> Adam

This pull request has now been integrated.

Changeset: e2c0cfef
Author:    Adam Sotona <asotona at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/e2c0cfef1468e1081d1e68f74caae71266815cb6
Stats:     60 lines in 2 files changed: 59 ins; 0 del; 1 mod

8331320: ClassFile API OutOfMemoryError with certain class files

Reviewed-by: psandoz

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

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

From mullan at openjdk.org  Thu May  2 19:15:56 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Thu, 2 May 2024 19:15:56 GMT
Subject: RFR: 8330542: Add two JAXP configuration files in preparation for
 a secure by default configuration [v6]
In-Reply-To: <EPpleChHksHT2g_WYiIpLkUd8P8bhrCQ8u1pMCGWiGA=.facdce75-f0c2-4376-b30e-587e05785899@github.com>
References: <v1bAYKgH9zfooXpvnBw4Vu2TIqHuKqqtSmgB0hiNp-Q=.31661a99-ecfc-4a05-8045-67b5f680db60@github.com>
 <EPpleChHksHT2g_WYiIpLkUd8P8bhrCQ8u1pMCGWiGA=.facdce75-f0c2-4376-b30e-587e05785899@github.com>
Message-ID: <CaqUvQc0VlWkPh4tEWkfAyc5ISF6Li2sp5GEIXDMZq0=.b3c7336c-2fcf-4323-a839-d829e4e5ce24@github.com>

On Wed, 1 May 2024 22:33:29 GMT, Joe Wang <joehw at openjdk.org> wrote:

>> Add two sample configuration files:
>> 
>>   jaxp-strict.properties: used to set strict configuration, stricter than jaxp.properties in previous versions such as JDK 22
>> 
>>   jaxp-compat.properties: used to regain compatibility from any more restricted configuration than previous versions such as JDK 22
>
> Joe Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add implNote to java.xml module summary; Update make file; Update the config files; Add test.

src/java.xml/share/classes/module-info.java line 446:

> 444:  * This file allows deployments to test the more secure/strict behavior,
> 445:  * identify issues such as a processor unknowingly makes outbound network
> 446:  * connections to fetch DTD, or processes XML that relies on extension functions.

Some wording suggestions: 

 ```
* This file allows deployments to test the more secure/strict behavior and
 * identify issues such as a processor unknowingly making outbound network
 * connections to fetch a DTD, or processing XML that relies on extension functions.

src/java.xml/share/classes/module-info.java line 453:

> 451:  * be used to regain compatibility from a more strict configuration in a future release.
> 452:  * The difference from the default {@code jaxp.properties} is that it contains
> 453:  * additional properties that were not included in {@code jaxp.properties},

s/were/are/

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18831#discussion_r1588197231
PR Review Comment: https://git.openjdk.org/jdk/pull/18831#discussion_r1588201546

From naoto.sato at oracle.com  Thu May  2 20:01:16 2024
From: naoto.sato at oracle.com (Naoto Sato)
Date: Thu, 2 May 2024 13:01:16 -0700
Subject: In support of Instant.minus(Instant)
In-Reply-To: <CAChqX892D+f+xkoFJ4E=FcdZbeSaEuYzy5Z0JVP7U0Rohg+uOA@mail.gmail.com>
References: <CAB3z6AiAvi2q12dB761fYTx8a6qV9syu6HGUq=vkR-dcYZyv=Q@mail.gmail.com>
 <CACzrW9CgGc=qNhmhyTNKponBSP1g37t1tNFkpeGj7oqGtn7ihA@mail.gmail.com>
 <81a8ee1c-807e-4a0b-8320-ff892fca76c0@oracle.com>
 <CAB3z6Aj9cev+JvCSGFRpOW6UEKmNQJsACzR-BnBxZpZP+3YJvg@mail.gmail.com>
 <CACzrW9AWCDYJdM7Y0rxpf8EeOohKLVnxwpKOa_KGWaVoZK2nvQ@mail.gmail.com>
 <CAGB9EW8fST6o4q7yqZxGO7OTkU52LYGSheHz+G0+R2OyA40uTQ@mail.gmail.com>
 <CAChqX892D+f+xkoFJ4E=FcdZbeSaEuYzy5Z0JVP7U0Rohg+uOA@mail.gmail.com>
Message-ID: <0ac5b3f0-a35f-41cc-bd48-a10035233226@oracle.com>

`Temporal` interface is clear that its `minus` methods return objects of 
the same `Temporal` type, and `until` calculates the amount of time 
until another `Temporal` type. Introducing `Instant.minus` that returns 
`Duration` would be confusing to me.

Naoto

On 5/2/24 10:41 AM, ?amonn McManus wrote:
> I'd say too that this makes intuitive sense based on algebra. If we have:
> /instant1/?+ /duration/ = /instant2/
> then we can subtract /duration/?from both sides:
> /instant1 = instant2 - duration/
> or we can subtract /instant1/?from both sides:
> /duration = instant2 - instant1/
> 
> There's no manipulation we can do that would cause us to try to add 
> instants together, and it's a bit surprising for the API to allow the 
> first subtraction but not the second.
> I also think that if I see instant2.minus(instant1) it's immediately 
> obvious to me what that means, while instant1.until(instant2) seems both 
> less discoverable and less obvious.
> 
> On Thu, 2 May 2024 at 10:29, Louis Wasserman <lowasser at google.com 
> <mailto:lowasser at google.com>> wrote:
> 
>     That doesn't?follow for me at all.
> 
>     The structure formed by Instants and Durations is an affine space
>     <https://en.wikipedia.org/wiki/Affine_space#Definition>, with
>     instants the points and durations the vectors.? (An affine space is
>     a vector space without a distinguished origin, which of course
>     Instants don't have.)? It is 100% standard to use the minus sign for
>     the operation "point - point = vector," even when "point?+ point" is
>     not defined, and to use all the other standard idioms for
>     subtraction; the Wikipedia article uses "subtraction" and
>     "difference" ubiquitously.
> 
>     Personally, I'd be willing to live with a different name for the
>     operation, but consider?"users keep getting it wrong" a strong
>     enough argument all by itself for a version with the swapped
>     argument order; it's not obvious to me that another API with the
>     same argument order adds enough value over Duration.between to
>     bother with.
> 
>     On Thu, May 2, 2024 at 10:04?AM Stephen Colebourne
>     <scolebourne at joda.org <mailto:scolebourne at joda.org>> wrote:
> 
>         On Thu, 2 May 2024 at 15:58, Kurt Alfred Kluever <kak at google.com
>         <mailto:kak at google.com>> wrote:
>          > instant ? instant = duration // what we're discussing
>          > instant + duration = instant // satisfied by
>         instant.plus(duration)
>          > instant - duration = instant // satisfied by
>         instant.minus(duration)
>          > duration + duration = duration // satisfied by
>         duration.plus(duration)
>          > duration - duration = duration // satisfied by
>         duration.minus(duration)
>          > duration ? real number = duration // satisfied by
>         duration.multipliedBy(long)
>          > duration ? real number = duration // satisfied by
>         duration.dividedBy(long)
>          >
>          > All but the first operation have very clear translations from
>         conceptual model to code. I'm hoping we can achieve the same
>         clarity for instant - instant by using the obvious name:
>         instant.minus(instant)
> 
>         But you can't have
>          ?instant + instant = ???
>         It doesn't make sense.
> 
>         This is at the heart of why minus isn't right in this case.
>         Stephen
> 
> 
> 
>     -- 
>     Louis Wasserman (he/they)
> 

From naoto at openjdk.org  Thu May  2 21:00:00 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 2 May 2024 21:00:00 GMT
Subject: RFR: 8331582: Incorrect default Console provider comment
Message-ID: <zyPDM7c7Q9VhOIJs64c-YUOQ3nWBGQBBbGiDRr2e1sU=.a3e718e5-864c-46c9-95ea-73dd7e2bcd5e@github.com>

Fixing a comment in `java.io.Console`, which was a leftover from the fix to https://bugs.openjdk.org/browse/JDK-8308591

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

Commit messages:
 - initial commit

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

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

From azvegint at openjdk.org  Thu May  2 21:12:14 2024
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Thu, 2 May 2024 21:12:14 GMT
Subject: RFR: 8331605:
 jdk/test/lib/TestMutuallyExclusivePlatformPredicates.java test failure
Message-ID: <I3BwbitErEKWqbrIP5elhPR_ocp_3fCEswuK0vVKHMQ=.cfbb8f82-759d-4f97-9afd-f7227f58315c@github.com>

Trivial fix.

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

Commit messages:
 - initial

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

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

From prr at openjdk.org  Thu May  2 21:16:51 2024
From: prr at openjdk.org (Phil Race)
Date: Thu, 2 May 2024 21:16:51 GMT
Subject: RFR: 8331605:
 jdk/test/lib/TestMutuallyExclusivePlatformPredicates.java test failure
In-Reply-To: <I3BwbitErEKWqbrIP5elhPR_ocp_3fCEswuK0vVKHMQ=.cfbb8f82-759d-4f97-9afd-f7227f58315c@github.com>
References: <I3BwbitErEKWqbrIP5elhPR_ocp_3fCEswuK0vVKHMQ=.cfbb8f82-759d-4f97-9afd-f7227f58315c@github.com>
Message-ID: <4NO8RnTx4r7rhfVCbFSV4zharmY4P5uAS4IGYCpiph8=.b293ee26-8bb8-4fab-b088-e74bd283a8e0@github.com>

On Thu, 2 May 2024 21:05:38 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

> Trivial fix.

I'd love to approve this but could you please explain what this is about ?
I see the failure log in the bug report but I am none the wiser.

Why exactly is this a problem ?

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

PR Comment: https://git.openjdk.org/jdk/pull/19071#issuecomment-2091639231

From prr at openjdk.org  Thu May  2 21:21:56 2024
From: prr at openjdk.org (Phil Race)
Date: Thu, 2 May 2024 21:21:56 GMT
Subject: RFR: 8331605:
 jdk/test/lib/TestMutuallyExclusivePlatformPredicates.java test failure
In-Reply-To: <I3BwbitErEKWqbrIP5elhPR_ocp_3fCEswuK0vVKHMQ=.cfbb8f82-759d-4f97-9afd-f7227f58315c@github.com>
References: <I3BwbitErEKWqbrIP5elhPR_ocp_3fCEswuK0vVKHMQ=.cfbb8f82-759d-4f97-9afd-f7227f58315c@github.com>
Message-ID: <tIp8ARyFLd5Jg32WVBZyxqq0I_5p551GsDDzdJ2RX7U=.102c7968-3d60-4835-83b0-b182c78b56ac@github.com>

On Thu, 2 May 2024 21:05:38 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

> Trivial fix.

I see you added test.lib.Platform.isOnWayland() in this PR
https://github.com/openjdk/jdk/pull/18995/files#diff-a1fe81399728999601f16ae9aaf5caae27f009c394377d2cd86c71f6d5e0e54c

So, that helps me understand why it is a new problem, but I still don't understand why the failing test cares.

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

PR Comment: https://git.openjdk.org/jdk/pull/19071#issuecomment-2091670387

From prr at openjdk.org  Thu May  2 21:27:53 2024
From: prr at openjdk.org (Phil Race)
Date: Thu, 2 May 2024 21:27:53 GMT
Subject: RFR: 8331605:
 jdk/test/lib/TestMutuallyExclusivePlatformPredicates.java test failure
In-Reply-To: <I3BwbitErEKWqbrIP5elhPR_ocp_3fCEswuK0vVKHMQ=.cfbb8f82-759d-4f97-9afd-f7227f58315c@github.com>
References: <I3BwbitErEKWqbrIP5elhPR_ocp_3fCEswuK0vVKHMQ=.cfbb8f82-759d-4f97-9afd-f7227f58315c@github.com>
Message-ID: <OFjAs7Zgsh_s7fQ48t2pJXIZRJH0bblHzEhOA1uDk24=.1556abf5-b6b3-464b-a912-97c3623b4c5b@github.com>

On Thu, 2 May 2024 21:05:38 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

> Trivial fix.

Marked as reviewed by prr (Reviewer).

OK. I see. The problem is that the test is out of sync with the actual usage of Platform.
Arguably isOnWayland() and all these others should be in some OTHER class entirely.
Something like PlatformAttribute.java or JDKBuildAttribute.java

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

PR Review: https://git.openjdk.org/jdk/pull/19071#pullrequestreview-2036959388
PR Comment: https://git.openjdk.org/jdk/pull/19071#issuecomment-2091703042

From azvegint at openjdk.org  Thu May  2 21:31:57 2024
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Thu, 2 May 2024 21:31:57 GMT
Subject: Integrated: 8331605:
 jdk/test/lib/TestMutuallyExclusivePlatformPredicates.java test failure
In-Reply-To: <I3BwbitErEKWqbrIP5elhPR_ocp_3fCEswuK0vVKHMQ=.cfbb8f82-759d-4f97-9afd-f7227f58315c@github.com>
References: <I3BwbitErEKWqbrIP5elhPR_ocp_3fCEswuK0vVKHMQ=.cfbb8f82-759d-4f97-9afd-f7227f58315c@github.com>
Message-ID: <S6AeRJIq_9_Z2lcwcLJXDGTo8vkDrtggaow6ocy_gug=.92b35a3b-d8dc-4e04-aac7-d5c75a15655a@github.com>

On Thu, 2 May 2024 21:05:38 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

> Trivial fix.

This pull request has now been integrated.

Changeset: 01125fa2
Author:    Alexander Zvegintsev <azvegint at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/01125fa21b733199d4fe670ecf38b82cd917e242
Stats:     2 lines in 1 file changed: 0 ins; 0 del; 2 mod

8331605: jdk/test/lib/TestMutuallyExclusivePlatformPredicates.java test failure

Reviewed-by: prr

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

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

From azvegint at openjdk.org  Thu May  2 21:34:57 2024
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Thu, 2 May 2024 21:34:57 GMT
Subject: RFR: 8331605:
 jdk/test/lib/TestMutuallyExclusivePlatformPredicates.java test failure
In-Reply-To: <tIp8ARyFLd5Jg32WVBZyxqq0I_5p551GsDDzdJ2RX7U=.102c7968-3d60-4835-83b0-b182c78b56ac@github.com>
References: <I3BwbitErEKWqbrIP5elhPR_ocp_3fCEswuK0vVKHMQ=.cfbb8f82-759d-4f97-9afd-f7227f58315c@github.com>
 <tIp8ARyFLd5Jg32WVBZyxqq0I_5p551GsDDzdJ2RX7U=.102c7968-3d60-4835-83b0-b182c78b56ac@github.com>
Message-ID: <eE9CylWKUyd723GiuxrI3-4m_7yd5DRbAFkLeGR9c8o=.a23315bf-5d05-4da6-8a71-a1ff65d93d64@github.com>

On Thu, 2 May 2024 21:19:14 GMT, Phil Race <prr at openjdk.org> wrote:

> I see you added test.lib.Platform.isOnWayland() in this PR https://github.com/openjdk/jdk/pull/18995/files#diff-a1fe81399728999601f16ae9aaf5caae27f009c394377d2cd86c71f6d5e0e54c
> 
> So, that helps me understand why it is a new problem, but I still don't understand why the failing test cares.

The test was introduced by [JDK-8058846](https://bugs.openjdk.org/browse/JDK-8058846). Its title is self-explanatory "c.o.j.t.Platform::isX86 and isX64 may simultaneously return true"

So methods that should not be true at the same time are placed in different groups, or in ignored group.

https://github.com/openjdk/jdk/blob/master/test/lib-test/jdk/test/lib/TestMutuallyExclusivePlatformPredicates.java#L48-L52

The test also checks if there is a new method that is not in any of these groups, hence the failure

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

PR Comment: https://git.openjdk.org/jdk/pull/19071#issuecomment-2091738433

From joehw at openjdk.org  Thu May  2 23:22:51 2024
From: joehw at openjdk.org (Joe Wang)
Date: Thu, 2 May 2024 23:22:51 GMT
Subject: RFR: 8331582: Incorrect default Console provider comment
In-Reply-To: <zyPDM7c7Q9VhOIJs64c-YUOQ3nWBGQBBbGiDRr2e1sU=.a3e718e5-864c-46c9-95ea-73dd7e2bcd5e@github.com>
References: <zyPDM7c7Q9VhOIJs64c-YUOQ3nWBGQBBbGiDRr2e1sU=.a3e718e5-864c-46c9-95ea-73dd7e2bcd5e@github.com>
Message-ID: <iqPXVvLWAfAsa--Y7asywzziLHWvvMtnrdU38OvsV1Q=.2d342eee-1efc-400f-bb31-4fe13ca39019@github.com>

On Thu, 2 May 2024 20:54:58 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Fixing a comment in `java.io.Console`, which was a leftover from the fix to https://bugs.openjdk.org/browse/JDK-8308591

Marked as reviewed by joehw (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/19070#pullrequestreview-2037110083

From duke at openjdk.org  Fri May  3 00:17:53 2024
From: duke at openjdk.org (Nizar Benalla)
Date: Fri, 3 May 2024 00:17:53 GMT
Subject: RFR: 8331051: Add an `@since` checker test for `java.base` module
In-Reply-To: <6GXrB8KTCoG_ZVXbDlm2-u_Z6YQATjGm3770lTXPIVI=.8ff74787-bdeb-4404-9aba-5cc5b2d0288c@github.com>
References: <NRZmbFYvDwXPuizcmCilJx5Yb6HjZ-2fJa-YILxYUl8=.a79f79e4-77d5-4910-b3df-5e78bb7e402b@github.com>
 <6GXrB8KTCoG_ZVXbDlm2-u_Z6YQATjGm3770lTXPIVI=.8ff74787-bdeb-4404-9aba-5cc5b2d0288c@github.com>
Message-ID: <RnCd4ybhH5s4Xlbn9ncaOWA8zwtdRQ7nEJ9GxwuTphY=.a2d6a9c8-297b-4166-8d22-8bd570efaff0@github.com>

On Wed, 1 May 2024 23:28:20 GMT, Nizar Benalla <duke at openjdk.org> wrote:

>> This checker checks the values of the `@since` tag found in the documentation comment for an element against the release in which the element first appeared.
>> 
>> Real since value of an API element is computed as the oldest release in which the given API element was introduced. That is:
>> - for modules, classes and interfaces, the release in which the element with the given qualified name was introduced
>> - for constructors, the release in which the constructor with the given VM descriptor was introduced
>> - for methods and fields, the release in which the given method or field with the given VM descriptor became a member of its enclosing class or interface, whether direct or inherited
>> 
>> Effective since value of an API element is computed as follows:
>> - if the given element has a `@since` tag in its javadoc, it is used
>> - in all other cases, return the effective since value of the enclosing element
>> 
>> The since checker verifies that for every API element, the real since value and the effective since value are the same, and reports an error if they are not.
>> 
>> Preview method are handled as per JEP 12, if `@PreviewFeature` is used consistently going forward then the checker doesn't need to be updated with every release. The checker has explicit knowledge of preview elements that came before `JDK 14` because they weren't marked in a machine understandable way and preview elements that came before `JDK 17` that didn't have `@PreviewFeature`.
>> 
>> Important note : We only check code written since `JDK 9` as the releases used to determine the expected value of `@since` tags are taken from the historical data built into `javac` which only goes back that far
>> 
>> The intial comment at the beginning of `SinceChecker.java` holds more information into the program.
>> 
>> I already have filed issues and fixed some wrong tags like in #18640, #18032, #18030, #18055, #18373, #18954, #18972.
>
> test/jdk/tools/sincechecker/SinceChecker.java line 300:
> 
>> 298:                         .getQualifiedName()
>> 299:                         .toString()
>> 300:                         .replaceAll("\\.", "/")
> 
> Note for readers: I will change this tomorrow to be more platform agnostic using `File.separatorChar` instead

Replaced with `.replace(".", File.separator)`

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18934#discussion_r1588545737

From duke at openjdk.org  Fri May  3 00:21:15 2024
From: duke at openjdk.org (Nizar Benalla)
Date: Fri, 3 May 2024 00:21:15 GMT
Subject: RFR: 8331051: Add an `@since` checker test for `java.base` module
 [v2]
In-Reply-To: <NRZmbFYvDwXPuizcmCilJx5Yb6HjZ-2fJa-YILxYUl8=.a79f79e4-77d5-4910-b3df-5e78bb7e402b@github.com>
References: <NRZmbFYvDwXPuizcmCilJx5Yb6HjZ-2fJa-YILxYUl8=.a79f79e4-77d5-4910-b3df-5e78bb7e402b@github.com>
Message-ID: <8BoG1WYohIAzTlExGDKdRb7QHihCvHUOIK-SmqqYHUM=.98ed8ebe-7fa6-49e5-a3de-8a43d20adbff@github.com>

> This checker checks the values of the `@since` tag found in the documentation comment for an element against the release in which the element first appeared.
> 
> Real since value of an API element is computed as the oldest release in which the given API element was introduced. That is:
> - for modules, classes and interfaces, the release in which the element with the given qualified name was introduced
> - for constructors, the release in which the constructor with the given VM descriptor was introduced
> - for methods and fields, the release in which the given method or field with the given VM descriptor became a member of its enclosing class or interface, whether direct or inherited
> 
> Effective since value of an API element is computed as follows:
> - if the given element has a `@since` tag in its javadoc, it is used
> - in all other cases, return the effective since value of the enclosing element
> 
> The since checker verifies that for every API element, the real since value and the effective since value are the same, and reports an error if they are not.
> 
> Preview method are handled as per JEP 12, if `@PreviewFeature` is used consistently going forward then the checker doesn't need to be updated with every release. The checker has explicit knowledge of preview elements that came before `JDK 14` because they weren't marked in a machine understandable way and preview elements that came before `JDK 17` that didn't have `@PreviewFeature`.
> 
> Important note : We only check code written since `JDK 9` as the releases used to determine the expected value of `@since` tags are taken from the historical data built into `javac` which only goes back that far
> 
> The intial comment at the beginning of `SinceChecker.java` holds more information into the program.
> 
> I already have filed issues and fixed some wrong tags like in #18640, #18032, #18030, #18055, #18373, #18954, #18972.

Nizar Benalla has updated the pull request incrementally with one additional commit since the last revision:

  -Wrap lines at 80-100
  -Changes `e.getMessages` to `e`
  -`File.separator` to be platform indepedant
  -Added a newline character at the end of files
  -Rename `persistElement` to `processElement`
  -Now throwing IllegalArgumentException instead of SkippedException

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18934/files
  - new: https://git.openjdk.org/jdk/pull/18934/files/599477bf..1bdb25d9

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

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

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

From duke at openjdk.org  Fri May  3 00:25:16 2024
From: duke at openjdk.org (Nizar Benalla)
Date: Fri, 3 May 2024 00:25:16 GMT
Subject: RFR: 8331051: Add an `@since` checker test for `java.base` module
 [v3]
In-Reply-To: <NRZmbFYvDwXPuizcmCilJx5Yb6HjZ-2fJa-YILxYUl8=.a79f79e4-77d5-4910-b3df-5e78bb7e402b@github.com>
References: <NRZmbFYvDwXPuizcmCilJx5Yb6HjZ-2fJa-YILxYUl8=.a79f79e4-77d5-4910-b3df-5e78bb7e402b@github.com>
Message-ID: <je8qDrB2j3pPzkbq5uNDK2nspbH_LVMMVrInvW48b_o=.65e6f18f-5b5d-4255-a6b0-50135f42e599@github.com>

> This checker checks the values of the `@since` tag found in the documentation comment for an element against the release in which the element first appeared.
> 
> Real since value of an API element is computed as the oldest release in which the given API element was introduced. That is:
> - for modules, classes and interfaces, the release in which the element with the given qualified name was introduced
> - for constructors, the release in which the constructor with the given VM descriptor was introduced
> - for methods and fields, the release in which the given method or field with the given VM descriptor became a member of its enclosing class or interface, whether direct or inherited
> 
> Effective since value of an API element is computed as follows:
> - if the given element has a `@since` tag in its javadoc, it is used
> - in all other cases, return the effective since value of the enclosing element
> 
> The since checker verifies that for every API element, the real since value and the effective since value are the same, and reports an error if they are not.
> 
> Preview method are handled as per JEP 12, if `@PreviewFeature` is used consistently going forward then the checker doesn't need to be updated with every release. The checker has explicit knowledge of preview elements that came before `JDK 14` because they weren't marked in a machine understandable way and preview elements that came before `JDK 17` that didn't have `@PreviewFeature`.
> 
> Important note : We only check code written since `JDK 9` as the releases used to determine the expected value of `@since` tags are taken from the historical data built into `javac` which only goes back that far
> 
> The intial comment at the beginning of `SinceChecker.java` holds more information into the program.
> 
> I already have filed issues and fixed some wrong tags like in #18640, #18032, #18030, #18055, #18373, #18954, #18972.

Nizar Benalla has updated the pull request incrementally with one additional commit since the last revision:

  mention packages in initial comment

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18934/files
  - new: https://git.openjdk.org/jdk/pull/18934/files/1bdb25d9..5df2151e

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

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

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

From liach at openjdk.org  Fri May  3 01:07:03 2024
From: liach at openjdk.org (Chen Liang)
Date: Fri, 3 May 2024 01:07:03 GMT
Subject: RFR: 8323707: Adjust Classfile API's type arg model to better
 represent the embodied type [v5]
In-Reply-To: <vTgBP598zJ-5pso8xIU-4DTuHcRGvhTLhrbS15PQbBg=.6b225886-fe55-4a02-ae67-f0d14c710d49@github.com>
References: <MHOvwnWcnocbfiiIdkzyqB6qdt-f2HwiaTurds0p3Pg=.cda1d910-6ef4-4577-a539-10a959adcd1f@github.com>
 <vTgBP598zJ-5pso8xIU-4DTuHcRGvhTLhrbS15PQbBg=.6b225886-fe55-4a02-ae67-f0d14c710d49@github.com>
Message-ID: <7qaVKWiE2NXgTvxxRDIDELhbr8lJMp_0vKEnLJOZ_Nc=.d94b359e-3dd0-4ba0-96c1-30bb7e9bd94d@github.com>

On Wed, 1 May 2024 22:39:05 GMT, Chen Liang <liach at openjdk.org> wrote:

>> API changes as discussed on the mailing list: https://mail.openjdk.org/pipermail/classfile-api-dev/2023-November/000419.html
>> 
>> Additional questions:
>> 1. Whether to rename `WildcardIndicator.DEFAULT` to `NONE`
>
> Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 15 commits:
> 
>  - Missing since tags
>  - Merge branch 'master' of https://github.com/openjdk/jdk into fix/typearg-model
>  - Merge branch 'master' of https://github.com/openjdk/jdk into fix/typearg-model
>  - Missed renaming in tests, thanks to Adam Sotona
>    
>    Co-authored-by: Adam Sotona <10807609+asotona at users.noreply.github.com>
>  - Rename no wildcard indicator, improve docs slightly
>  - Merge branch 'master' of https://github.com/openjdk/jdk into fix/typearg-model
>  - Merge branch 'master' into fix/typearg-model
>  - redundant line
>  - Fix a test in langtools, copyright year
>  - Merge branch 'master' of https://github.com/openjdk/jdk into fix/typearg-model
>  - ... and 5 more: https://git.openjdk.org/jdk/compare/0a24daec...f9af4182

I have added a few missing since tags. Because other since tag additions don't go through CSR review, I will not re-draft the CSR and propose to directly merge this patch.

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

PR Comment: https://git.openjdk.org/jdk/pull/16517#issuecomment-2091975802

From duke at openjdk.org  Fri May  3 01:48:02 2024
From: duke at openjdk.org (Nizar Benalla)
Date: Fri, 3 May 2024 01:48:02 GMT
Subject: RFR: 8331051: Add an `@since` checker test for `java.base` module
 [v3]
In-Reply-To: <je8qDrB2j3pPzkbq5uNDK2nspbH_LVMMVrInvW48b_o=.65e6f18f-5b5d-4255-a6b0-50135f42e599@github.com>
References: <NRZmbFYvDwXPuizcmCilJx5Yb6HjZ-2fJa-YILxYUl8=.a79f79e4-77d5-4910-b3df-5e78bb7e402b@github.com>
 <je8qDrB2j3pPzkbq5uNDK2nspbH_LVMMVrInvW48b_o=.65e6f18f-5b5d-4255-a6b0-50135f42e599@github.com>
Message-ID: <6eIDXZg4uZNO0H-QKCisMGaBZOFCWm7OjzoSRVzO4Jk=.8d8da266-6fd7-4edf-8fb5-083461c4e4c4@github.com>

On Fri, 3 May 2024 00:25:16 GMT, Nizar Benalla <duke at openjdk.org> wrote:

>> This checker checks the values of the `@since` tag found in the documentation comment for an element against the release in which the element first appeared.
>> 
>> Real since value of an API element is computed as the oldest release in which the given API element was introduced. That is:
>> - for modules, classes and interfaces, the release in which the element with the given qualified name was introduced
>> - for constructors, the release in which the constructor with the given VM descriptor was introduced
>> - for methods and fields, the release in which the given method or field with the given VM descriptor became a member of its enclosing class or interface, whether direct or inherited
>> 
>> Effective since value of an API element is computed as follows:
>> - if the given element has a `@since` tag in its javadoc, it is used
>> - in all other cases, return the effective since value of the enclosing element
>> 
>> The since checker verifies that for every API element, the real since value and the effective since value are the same, and reports an error if they are not.
>> 
>> Preview method are handled as per JEP 12, if `@PreviewFeature` is used consistently going forward then the checker doesn't need to be updated with every release. The checker has explicit knowledge of preview elements that came before `JDK 14` because they weren't marked in a machine understandable way and preview elements that came before `JDK 17` that didn't have `@PreviewFeature`.
>> 
>> Important note : We only check code written since `JDK 9` as the releases used to determine the expected value of `@since` tags are taken from the historical data built into `javac` which only goes back that far
>> 
>> The intial comment at the beginning of `SinceChecker.java` holds more information into the program.
>> 
>> I already have filed issues and fixed some wrong tags like in #18640, #18032, #18030, #18055, #18373, #18954, #18972.
>
> Nizar Benalla has updated the pull request incrementally with one additional commit since the last revision:
> 
>   mention packages in initial comment

test/jdk/tools/sincechecker/SinceChecker.java line 145:

> 143:     private void processModuleElement(ModuleElement moduleElement, String releaseVersion, JavacTask ct) {
> 144:         for (ModuleElement.ExportsDirective ed : ElementFilter.exportsIn(moduleElement.getDirectives())) {
> 145:             processElement(moduleElement, moduleElement, ct.getTypes(), releaseVersion);

For consideration for tomorrow: move this one line up - to map the module id even if the module has no export directives

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18934#discussion_r1588597273

From kevinb9n at gmail.com  Fri May  3 03:08:03 2024
From: kevinb9n at gmail.com (Kevin Bourrillion)
Date: Thu, 2 May 2024 23:08:03 -0400
Subject: In support of Instant.minus(Instant)
In-Reply-To: <CAGB9EW8fST6o4q7yqZxGO7OTkU52LYGSheHz+G0+R2OyA40uTQ@mail.gmail.com>
References: <CAB3z6AiAvi2q12dB761fYTx8a6qV9syu6HGUq=vkR-dcYZyv=Q@mail.gmail.com>
 <CACzrW9CgGc=qNhmhyTNKponBSP1g37t1tNFkpeGj7oqGtn7ihA@mail.gmail.com>
 <81a8ee1c-807e-4a0b-8320-ff892fca76c0@oracle.com>
 <CAB3z6Aj9cev+JvCSGFRpOW6UEKmNQJsACzR-BnBxZpZP+3YJvg@mail.gmail.com>
 <CACzrW9AWCDYJdM7Y0rxpf8EeOohKLVnxwpKOa_KGWaVoZK2nvQ@mail.gmail.com>
 <CAGB9EW8fST6o4q7yqZxGO7OTkU52LYGSheHz+G0+R2OyA40uTQ@mail.gmail.com>
Message-ID: <CAFMUOF7aqMFYN661Kma4ZbpEg=J-FB5Rb=ba1xXnaCYGGJUqtg@mail.gmail.com>

Most users don't and won't know anything about "affine spaces" *per se*,
however, it's not a super unusual relationship for two types to have. A few
examples

Point2D and Vector2D
Instant and Duration
Pitch and Interval (i.e. music theory)

If Java has operator overloading one day, I would feel it perfectly
appropriate to apply it to these kinds of affine pairs-of-types.

All of this to say that minus() is IMHO reasonable here.

However, isn't until() just better anyway? Keeping the exprrssions in
chrono order is nice, and I think everyone knows the order too (earlier
until later). Whereas with minus it seems like you miiiight get it
reversed. What am I missing?


On Thu, May 2, 2024, 1:52?PM Louis Wasserman <lowasser at google.com> wrote:

> That doesn't follow for me at all.
>
> The structure formed by Instants and Durations is an affine space
> <https://en.wikipedia.org/wiki/Affine_space#Definition>, with instants
> the points and durations the vectors.  (An affine space is a vector space
> without a distinguished origin, which of course Instants don't have.)  It
> is 100% standard to use the minus sign for the operation "point - point =
> vector," even when "point + point" is not defined, and to use all the other
> standard idioms for subtraction; the Wikipedia article uses "subtraction"
> and "difference" ubiquitously.
>
> Personally, I'd be willing to live with a different name for the
> operation, but consider "users keep getting it wrong" a strong enough
> argument all by itself for a version with the swapped argument order; it's
> not obvious to me that another API with the same argument order adds enough
> value over Duration.between to bother with.
>
> On Thu, May 2, 2024 at 10:04?AM Stephen Colebourne <scolebourne at joda.org>
> wrote:
>
>> On Thu, 2 May 2024 at 15:58, Kurt Alfred Kluever <kak at google.com> wrote:
>> > instant ? instant = duration // what we're discussing
>> > instant + duration = instant // satisfied by instant.plus(duration)
>> > instant - duration = instant // satisfied by instant.minus(duration)
>> > duration + duration = duration // satisfied by duration.plus(duration)
>> > duration - duration = duration // satisfied by duration.minus(duration)
>> > duration ? real number = duration // satisfied by
>> duration.multipliedBy(long)
>> > duration ? real number = duration // satisfied by
>> duration.dividedBy(long)
>> >
>> > All but the first operation have very clear translations from
>> conceptual model to code. I'm hoping we can achieve the same clarity for
>> instant - instant by using the obvious name: instant.minus(instant)
>>
>> But you can't have
>>  instant + instant = ???
>> It doesn't make sense.
>>
>> This is at the heart of why minus isn't right in this case.
>> Stephen
>>
>
>
> --
> Louis Wasserman (he/they)
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240502/afb3fb73/attachment-0001.htm>

From jlahoda at openjdk.org  Fri May  3 06:42:54 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Fri, 3 May 2024 06:42:54 GMT
Subject: RFR: 8331582: Incorrect default Console provider comment
In-Reply-To: <zyPDM7c7Q9VhOIJs64c-YUOQ3nWBGQBBbGiDRr2e1sU=.a3e718e5-864c-46c9-95ea-73dd7e2bcd5e@github.com>
References: <zyPDM7c7Q9VhOIJs64c-YUOQ3nWBGQBBbGiDRr2e1sU=.a3e718e5-864c-46c9-95ea-73dd7e2bcd5e@github.com>
Message-ID: <USEuAHs1D3byC8cj2cv3-xqDNlOPkm7kIv4Esfd-2mU=.a40520ce-1604-4c7e-99be-1ed65f0c997d@github.com>

On Thu, 2 May 2024 20:54:58 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Fixing a comment in `java.io.Console`, which was a leftover from the fix to https://bugs.openjdk.org/browse/JDK-8308591

Looks good to me, thanks!

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

Marked as reviewed by jlahoda (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19070#pullrequestreview-2037481621

From jlu at openjdk.org  Fri May  3 08:17:53 2024
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 3 May 2024 08:17:53 GMT
Subject: RFR: 8331582: Incorrect default Console provider comment
In-Reply-To: <zyPDM7c7Q9VhOIJs64c-YUOQ3nWBGQBBbGiDRr2e1sU=.a3e718e5-864c-46c9-95ea-73dd7e2bcd5e@github.com>
References: <zyPDM7c7Q9VhOIJs64c-YUOQ3nWBGQBBbGiDRr2e1sU=.a3e718e5-864c-46c9-95ea-73dd7e2bcd5e@github.com>
Message-ID: <a_LVSZThm1RW-D_iyqvaXzFIT93rbh011lFbQO1jG2Q=.f46c4c3b-91fd-4445-a0b3-e88c57ba7909@github.com>

On Thu, 2 May 2024 20:54:58 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Fixing a comment in `java.io.Console`, which was a leftover from the fix to https://bugs.openjdk.org/browse/JDK-8308591

Marked as reviewed by jlu (Committer).

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

PR Review: https://git.openjdk.org/jdk/pull/19070#pullrequestreview-2037632558

From mbaesken at openjdk.org  Fri May  3 08:18:53 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 3 May 2024 08:18:53 GMT
Subject: RFR: 8329653: JLILaunchTest fails on AIX after JDK-8329131
In-Reply-To: <y9wItIb8Yr_ZrHfN_kV5lDCp-d-VtYam3MuHX1OxurU=.ce3378d2-90b3-4396-8951-4651439e4f90@github.com>
References: <y9wItIb8Yr_ZrHfN_kV5lDCp-d-VtYam3MuHX1OxurU=.ce3378d2-90b3-4396-8951-4651439e4f90@github.com>
Message-ID: <rZIbaK9HWDwf5BB0tAXq2EHhQ3DSoq3A0dzI1t2y-YY=.9ad5d264-e9db-4a2a-b2ef-1ef9534b201e@github.com>

On Mon, 29 Apr 2024 14:45:07 GMT, Joachim Kern <jkern at openjdk.org> wrote:

> Since ~ end of March, after [JDK-8329131](https://bugs.openjdk.org/browse/JDK-8329131), tools/launcher/JliLaunchTest.java fails on AIX. Failure is :
> 
>  stdout: [];
>  stderr: [Error: could not find libjava.so
> Error: Could not find Java SE Runtime Environment.
> ]
>  exitValue = 2
> 
> java.lang.RuntimeException: Expected to get exit value of [0], exit value is: [2]
> at jdk.test.lib.process.OutputAnalyzer.shouldHaveExitValue(OutputAnalyzer.java:521)
> at JliLaunchTest.main(JliLaunchTest.java:58)
> at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
> at java.base/java.lang.reflect.Method.invoke(Method.java:580)
> at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:333)
> at java.base/java.lang.Thread.run(Thread.java:1575)
> 
> Maybe we need to do further adjustments to BUILD_JDK_JTREG_EXECUTABLES_LIBS_exeJliLaunchTest / BUILD_JDK_JTREG_EXECUTABLES_LDFLAGS_exeJliLaunchTest on AIX ?
> Or somehow adjust the coding that attempts to find parts of "JRE" (libjava.so) ? The libjli.so is gone on AIX after [JDK-8329131](https://bugs.openjdk.org/browse/JDK-8329131), and with this also the image discovery based on GetApplicationHomeFromDll which uses libjli.so .
> 
> Without libjli.so we have to analyze the LD-LIBRARY_PATH / LIBPATH envvar. There is no other methos available on AIX, because it lacks the $ORIGIN feature of the rpath.

The naming GetApplicationHomeFromLD_LIBRARY_PATH looks a bit unconventional ; maybe adjust this ?
Regarding if  the code should be added for all platforms or just AIX, let's hear what Alan and others have to say.

On AIX we have the bad situation that  GetApplicationHomeFromDll  stopped working after JDK-8329131.

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

PR Comment: https://git.openjdk.org/jdk/pull/19000#issuecomment-2092530647

From jlu at openjdk.org  Fri May  3 08:51:23 2024
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 3 May 2024 08:51:23 GMT
Subject: RFR: 8331485: Odd Results when Parsing Scientific Notation with Large
 Exponent
Message-ID: <lTOZ4RbzZFMN0yLrQKGOcMihdTop24YbYJe2h36SodM=.0addc2ad-b0d1-4721-b860-a9395fa14977@github.com>

Please review this PR which corrects an edge case bug for java.text.DecimalFormat that causes incorrect parsing results for strings with very large exponent values.

When parsing values with large exponents, if the value of the exponent exceeds `Integer.MAX_VALUE`, the parsed value  is equal to 0. If the value of the exponent exceeds `Long.MAX_VALUE`, the parsed value is equal to the mantissa. Both results are confusing and incorrect.

For example,


NumberFormat fmt = NumberFormat.getInstance(Locale.US);
fmt.parse(".1E2147483648"); // returns 0.0
fmt.parse(".1E9223372036854775808"); // returns 0.1
// For comparison
Double.parseDouble(".1E2147483648"); // returns Infinity
Double.parseDouble(".1E9223372036854775808"); // returns Infinity


After this change, both parse calls return `Double.POSITIVE_INFINITY` now.

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

Commit messages:
 - init

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

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

From jlahoda at openjdk.org  Fri May  3 10:17:08 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Fri, 3 May 2024 10:17:08 GMT
Subject: RFR: 8331535: Incorrect prompt for Console.readLine
Message-ID: <IQvUAYG5zj0JqUbWiQiryAuBrtV6jrVCvy9useQZmlc=.a4dd8dfc-e835-4405-83f8-fd1bda8480f6@github.com>

When JLine reads a line, there may be a prompt provided. However, JLine will not interpret the prompt literally, it will handle `%` specially. As a consequence, doing:

System.console().readLine("%%s");


will not print `%s`, as first `String.format` is used, which will convert `%%s` to `%s`, and then JLine will interpret the `%`. The proposed solution is to duplicate the `%`, so that JLine will print it.

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

Depends on: https://git.openjdk.org/jdk/pull/18996

Commit messages:
 - 8331535: Incorrect prompt for Console.readLine

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

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

From mcimadamore at openjdk.org  Fri May  3 10:31:54 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 3 May 2024 10:31:54 GMT
Subject: RFR: 8182774: Verify code in javap [v2]
In-Reply-To: <2GHZB_ErRLVx9TKJmJLr_A8wfJbCHzo1K8AGUCkefTs=.fddde400-76e6-441c-8201-a78aeb745aef@github.com>
References: <khSsamCrV5bkc6ySKQDBYoTHsSyjGggfqkzoc7YxfTo=.2588f7fa-e91e-4e99-bd75-1e77e4b17c6a@github.com>
 <2GHZB_ErRLVx9TKJmJLr_A8wfJbCHzo1K8AGUCkefTs=.fddde400-76e6-441c-8201-a78aeb745aef@github.com>
Message-ID: <25DDHLGu7Zjddw1ysfuv1QBf-PzHctzLVU4v6fIRt9M=.ba009d4c-42aa-4932-bcc3-9eb42a3322c0@github.com>

On Thu, 2 May 2024 12:22:23 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> This patch adds `javap -verify` option to check the class and print obvious verification errors found.
>> Implementation depends on extended Class-File API verification support, so PR #16809 is important to precede.
>> The new `javap` option is mentioned in man pages and a release note will be provided.
>> 
>> Please review.
>> 
>> Thank you,
>> Adam
>
> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fixed typo

Looks great - this was a long-awaited enhancement!

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

Marked as reviewed by mcimadamore (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18629#pullrequestreview-2037858606

From liach at openjdk.org  Fri May  3 11:10:57 2024
From: liach at openjdk.org (Chen Liang)
Date: Fri, 3 May 2024 11:10:57 GMT
Subject: Integrated: 8323707: Adjust Classfile API's type arg model to better
 represent the embodied type
In-Reply-To: <MHOvwnWcnocbfiiIdkzyqB6qdt-f2HwiaTurds0p3Pg=.cda1d910-6ef4-4577-a539-10a959adcd1f@github.com>
References: <MHOvwnWcnocbfiiIdkzyqB6qdt-f2HwiaTurds0p3Pg=.cda1d910-6ef4-4577-a539-10a959adcd1f@github.com>
Message-ID: <Z4EF2lEjI9kAAfVWA7SJ0Dy5eMo6Z5HDHTGMiRoFVzw=.01d7063c-4a94-482f-a970-ba62ed5a9a13@github.com>

On Mon, 6 Nov 2023 07:30:41 GMT, Chen Liang <liach at openjdk.org> wrote:

> API changes as discussed on the mailing list: https://mail.openjdk.org/pipermail/classfile-api-dev/2023-November/000419.html
> 
> Additional questions:
> 1. Whether to rename `WildcardIndicator.DEFAULT` to `NONE`

This pull request has now been integrated.

Changeset: c60474b1
Author:    Chen Liang <liach at openjdk.org>
Committer: Adam Sotona <asotona at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/c60474b1229b67265acbd709f6ba081303329be4
Stats:     137 lines in 6 files changed: 54 ins; 32 del; 51 mod

8323707: Adjust Classfile API's type arg model to better represent the embodied type

Reviewed-by: asotona

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

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

From prappo at openjdk.org  Fri May  3 11:24:54 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Fri, 3 May 2024 11:24:54 GMT
Subject: RFR: 8331535: Incorrect prompt for Console.readLine
In-Reply-To: <IQvUAYG5zj0JqUbWiQiryAuBrtV6jrVCvy9useQZmlc=.a4dd8dfc-e835-4405-83f8-fd1bda8480f6@github.com>
References: <IQvUAYG5zj0JqUbWiQiryAuBrtV6jrVCvy9useQZmlc=.a4dd8dfc-e835-4405-83f8-fd1bda8480f6@github.com>
Message-ID: <3m2vXDnx0X_2f3aJxt61yStX_9jyuzIjjhhpgGBmm0Q=.9597c9c6-586a-4ad1-ad91-2a7fa779a427@github.com>

On Fri, 3 May 2024 10:11:02 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> When JLine reads a line, there may be a prompt provided. However, JLine will not interpret the prompt literally, it will handle `%` specially. As a consequence, doing:
> 
> System.console().readLine("%%s");
> 
> 
> will not print `%s`, as first `String.format` is used, which will convert `%%s` to `%s`, and then JLine will interpret the `%`. The proposed solution is to duplicate the `%`, so that JLine will print it.

src/jdk.internal.le/share/classes/jdk/internal/org/jline/JdkConsoleProviderImpl.java line 101:

> 99:             try {
> 100:                 initJLineIfNeeded();
> 101:                 return jline.readLine(fmt.formatted(args).replace("%", "%%"));

I understand that [JLine interprets `%` in a prompt](https://github.com/openjdk/jdk/blob/4ed38f5ad5f822ab948257ed39717ea919fd32ed/src/jdk.internal.le/share/classes/jdk/internal/org/jline/reader/impl/LineReaderImpl.java#L4050), but are the interpretation rules documented on JLine GitHub page or elsewhere?

src/jdk.internal.le/share/classes/jdk/internal/org/jline/JdkConsoleProviderImpl.java line 116:

> 114:             try {
> 115:                 initJLineIfNeeded();
> 116:                 return jline.readLine(fmt.formatted(args).replace("%", "%%"), '\0')

I find `'\0'` more cryptic and confusing than `(char) 0`, but okay. (Had to re-read https://docs.oracle.com/javase/specs/jls/se22/html/jls-3.html#jls-EscapeSequence)

test/jdk/jdk/internal/jline/JLineConsoleProviderTest.java line 27:

> 25:  * @test
> 26:  * @bug 8331535
> 27:  * @summary Verify the jdk.internal.le's console provider works properly.

There's a hidden assumption in this test below that the _default_ console is `jdk.internal.le`. Is there any way to assert that?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19081#discussion_r1589074603
PR Review Comment: https://git.openjdk.org/jdk/pull/19081#discussion_r1589065719
PR Review Comment: https://git.openjdk.org/jdk/pull/19081#discussion_r1589067927

From alanb at openjdk.org  Fri May  3 11:33:52 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 3 May 2024 11:33:52 GMT
Subject: RFR: 8329653: JLILaunchTest fails on AIX after JDK-8329131
In-Reply-To: <rZIbaK9HWDwf5BB0tAXq2EHhQ3DSoq3A0dzI1t2y-YY=.9ad5d264-e9db-4a2a-b2ef-1ef9534b201e@github.com>
References: <y9wItIb8Yr_ZrHfN_kV5lDCp-d-VtYam3MuHX1OxurU=.ce3378d2-90b3-4396-8951-4651439e4f90@github.com>
 <rZIbaK9HWDwf5BB0tAXq2EHhQ3DSoq3A0dzI1t2y-YY=.9ad5d264-e9db-4a2a-b2ef-1ef9534b201e@github.com>
Message-ID: <aMmj708XjRxHp9n2qmUpon4Wqy5juiFrwi-BOEBU3N0=.0ba17230-37bc-4493-8538-098940f8f4a5@github.com>

On Fri, 3 May 2024 08:15:32 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> The naming GetApplicationHomeFromLD_LIBRARY_PATH looks a bit unconventional ; maybe adjust this ? Regarding if the code should be added for all platforms or just AIX, let's hear what Alan and others have to say.

I was busy with other things and missed JoKern65's comment. I would be less risky to limit this to AIX for now.

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

PR Comment: https://git.openjdk.org/jdk/pull/19000#issuecomment-2092820489

From mbaesken at openjdk.org  Fri May  3 11:37:54 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 3 May 2024 11:37:54 GMT
Subject: RFR: 8329653: JLILaunchTest fails on AIX after JDK-8329131
In-Reply-To: <aMmj708XjRxHp9n2qmUpon4Wqy5juiFrwi-BOEBU3N0=.0ba17230-37bc-4493-8538-098940f8f4a5@github.com>
References: <y9wItIb8Yr_ZrHfN_kV5lDCp-d-VtYam3MuHX1OxurU=.ce3378d2-90b3-4396-8951-4651439e4f90@github.com>
 <rZIbaK9HWDwf5BB0tAXq2EHhQ3DSoq3A0dzI1t2y-YY=.9ad5d264-e9db-4a2a-b2ef-1ef9534b201e@github.com>
 <aMmj708XjRxHp9n2qmUpon4Wqy5juiFrwi-BOEBU3N0=.0ba17230-37bc-4493-8538-098940f8f4a5@github.com>
Message-ID: <iWS6VsUDDIyq1gD9uNt0a28jFvFqgUiGbsZchhwcnF0=.14453737-063e-468f-8454-e2f2f7a4e0df@github.com>

On Fri, 3 May 2024 11:31:35 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> 
> I was busy with other things and missed JoKern65's comment. I would be less risky to limit this to AIX for now.

Thanks for your comment;  we see the issue only on AIX so it makes sense to limit it to this platform.

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

PR Comment: https://git.openjdk.org/jdk/pull/19000#issuecomment-2092825223

From prappo at openjdk.org  Fri May  3 11:59:55 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Fri, 3 May 2024 11:59:55 GMT
Subject: RFR: 8331582: Incorrect default Console provider comment
In-Reply-To: <zyPDM7c7Q9VhOIJs64c-YUOQ3nWBGQBBbGiDRr2e1sU=.a3e718e5-864c-46c9-95ea-73dd7e2bcd5e@github.com>
References: <zyPDM7c7Q9VhOIJs64c-YUOQ3nWBGQBBbGiDRr2e1sU=.a3e718e5-864c-46c9-95ea-73dd7e2bcd5e@github.com>
Message-ID: <j6K4Odg3gxvxW9vG6Ud3BbpAL2g9-Z_wcz-1LjLccL4=.5fc56cec-afec-475c-bcee-2a41fbed08c6@github.com>

On Thu, 2 May 2024 20:54:58 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Fixing a comment in `java.io.Console`, which was a leftover from the fix to https://bugs.openjdk.org/browse/JDK-8308591

Looks good.

src/java.base/share/classes/java/io/Console.java line 409:

> 407:              * The JdkConsole provider used for Console instantiation can be specified
> 408:              * with the system property "jdk.console", whose value designates the module
> 409:              * name of the implementation, and which defaults to the value

Might read slightly better:
Suggestion:

             * name of the implementation, and which defaults to the value of

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

Marked as reviewed by prappo (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19070#pullrequestreview-2037983570
PR Review Comment: https://git.openjdk.org/jdk/pull/19070#discussion_r1589103639

From roger.riggs at oracle.com  Fri May  3 13:39:01 2024
From: roger.riggs at oracle.com (Roger Riggs)
Date: Fri, 3 May 2024 09:39:01 -0400
Subject: In support of Instant.minus(Instant)
In-Reply-To: <0ac5b3f0-a35f-41cc-bd48-a10035233226@oracle.com>
References: <CAB3z6AiAvi2q12dB761fYTx8a6qV9syu6HGUq=vkR-dcYZyv=Q@mail.gmail.com>
 <CACzrW9CgGc=qNhmhyTNKponBSP1g37t1tNFkpeGj7oqGtn7ihA@mail.gmail.com>
 <81a8ee1c-807e-4a0b-8320-ff892fca76c0@oracle.com>
 <CAB3z6Aj9cev+JvCSGFRpOW6UEKmNQJsACzR-BnBxZpZP+3YJvg@mail.gmail.com>
 <CACzrW9AWCDYJdM7Y0rxpf8EeOohKLVnxwpKOa_KGWaVoZK2nvQ@mail.gmail.com>
 <CAGB9EW8fST6o4q7yqZxGO7OTkU52LYGSheHz+G0+R2OyA40uTQ@mail.gmail.com>
 <CAChqX892D+f+xkoFJ4E=FcdZbeSaEuYzy5Z0JVP7U0Rohg+uOA@mail.gmail.com>
 <0ac5b3f0-a35f-41cc-bd48-a10035233226@oracle.com>
Message-ID: <156760df-b775-48a9-a20d-cc900d9df6e4@oracle.com>

Hi,

I would also reinforce Stephen's early observation that the pattern for 
"until" methods in java.time includes those of the XXXDate classes, with 
a single Temporal parameter.? Period and Duration are similar values 
holding relative TemporalAmounts.

 ? ? public Period until(ChronoLocalDate endDateExclusive)

In addition to Instant, the LocalTime class might also benefit from adding:

     public Duration until(LocalTime endExclusive)`

The API design of java.time included an emphasis on consistent naming 
across the packages.

Regards, Roger


On 5/2/24 4:01 PM, Naoto Sato wrote:
> `Temporal` interface is clear that its `minus` methods return objects 
> of the same `Temporal` type, and `until` calculates the amount of time 
> until another `Temporal` type. Introducing `Instant.minus` that 
> returns `Duration` would be confusing to me.
>
> Naoto
>
> On 5/2/24 10:41 AM, ?amonn McManus wrote:
>> I'd say too that this makes intuitive sense based on algebra. If we 
>> have:
>> /instant1/?+ /duration/ = /instant2/
>> then we can subtract /duration/?from both sides:
>> /instant1 = instant2 - duration/
>> or we can subtract /instant1/?from both sides:
>> /duration = instant2 - instant1/
>>
>> There's no manipulation we can do that would cause us to try to add 
>> instants together, and it's a bit surprising for the API to allow the 
>> first subtraction but not the second.
>> I also think that if I see instant2.minus(instant1) it's immediately 
>> obvious to me what that means, while instant1.until(instant2) seems 
>> both less discoverable and less obvious.
>>
>> On Thu, 2 May 2024 at 10:29, Louis Wasserman <lowasser at google.com 
>> <mailto:lowasser at google.com>> wrote:
>>
>> ??? That doesn't?follow for me at all.
>>
>> ??? The structure formed by Instants and Durations is an affine space
>> <https://en.wikipedia.org/wiki/Affine_space#Definition>, with
>> ??? instants the points and durations the vectors.? (An affine space is
>> ??? a vector space without a distinguished origin, which of course
>> ??? Instants don't have.)? It is 100% standard to use the minus sign for
>> ??? the operation "point - point = vector," even when "point?+ point" is
>> ??? not defined, and to use all the other standard idioms for
>> ??? subtraction; the Wikipedia article uses "subtraction" and
>> ??? "difference" ubiquitously.
>>
>> ??? Personally, I'd be willing to live with a different name for the
>> ??? operation, but consider?"users keep getting it wrong" a strong
>> ??? enough argument all by itself for a version with the swapped
>> ??? argument order; it's not obvious to me that another API with the
>> ??? same argument order adds enough value over Duration.between to
>> ??? bother with.
>>
>> ??? On Thu, May 2, 2024 at 10:04?AM Stephen Colebourne
>> ??? <scolebourne at joda.org <mailto:scolebourne at joda.org>> wrote:
>>
>> ??????? On Thu, 2 May 2024 at 15:58, Kurt Alfred Kluever <kak at google.com
>> <mailto:kak at google.com>> wrote:
>> ???????? > instant ? instant = duration // what we're discussing
>> ???????? > instant + duration = instant // satisfied by
>> ??????? instant.plus(duration)
>> ???????? > instant - duration = instant // satisfied by
>> ??????? instant.minus(duration)
>> ???????? > duration + duration = duration // satisfied by
>> ??????? duration.plus(duration)
>> ???????? > duration - duration = duration // satisfied by
>> ??????? duration.minus(duration)
>> ???????? > duration ? real number = duration // satisfied by
>> ??????? duration.multipliedBy(long)
>> ???????? > duration ? real number = duration // satisfied by
>> ??????? duration.dividedBy(long)
>> ???????? >
>> ???????? > All but the first operation have very clear translations from
>> ??????? conceptual model to code. I'm hoping we can achieve the same
>> ??????? clarity for instant - instant by using the obvious name:
>> ??????? instant.minus(instant)
>>
>> ??????? But you can't have
>> ???????? ?instant + instant = ???
>> ??????? It doesn't make sense.
>>
>> ??????? This is at the heart of why minus isn't right in this case.
>> ??????? Stephen
>>
>>
>>
>> ??? -- ??? Louis Wasserman (he/they)
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240503/873fcb2b/attachment-0001.htm>

From jkern at openjdk.org  Fri May  3 15:25:05 2024
From: jkern at openjdk.org (Joachim Kern)
Date: Fri, 3 May 2024 15:25:05 GMT
Subject: RFR: 8329653: JLILaunchTest fails on AIX after JDK-8329131 [v2]
In-Reply-To: <y9wItIb8Yr_ZrHfN_kV5lDCp-d-VtYam3MuHX1OxurU=.ce3378d2-90b3-4396-8951-4651439e4f90@github.com>
References: <y9wItIb8Yr_ZrHfN_kV5lDCp-d-VtYam3MuHX1OxurU=.ce3378d2-90b3-4396-8951-4651439e4f90@github.com>
Message-ID: <0Zk_GFIiqp21uI11y2ae6oRJbGYcxcuVrjf4YwQg4CI=.073efa87-9736-46ee-a1b0-bd8232196039@github.com>

> Since ~ end of March, after [JDK-8329131](https://bugs.openjdk.org/browse/JDK-8329131), tools/launcher/JliLaunchTest.java fails on AIX. Failure is :
> 
>  stdout: [];
>  stderr: [Error: could not find libjava.so
> Error: Could not find Java SE Runtime Environment.
> ]
>  exitValue = 2
> 
> java.lang.RuntimeException: Expected to get exit value of [0], exit value is: [2]
> at jdk.test.lib.process.OutputAnalyzer.shouldHaveExitValue(OutputAnalyzer.java:521)
> at JliLaunchTest.main(JliLaunchTest.java:58)
> at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
> at java.base/java.lang.reflect.Method.invoke(Method.java:580)
> at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:333)
> at java.base/java.lang.Thread.run(Thread.java:1575)
> 
> Maybe we need to do further adjustments to BUILD_JDK_JTREG_EXECUTABLES_LIBS_exeJliLaunchTest / BUILD_JDK_JTREG_EXECUTABLES_LDFLAGS_exeJliLaunchTest on AIX ?
> Or somehow adjust the coding that attempts to find parts of "JRE" (libjava.so) ? The libjli.so is gone on AIX after [JDK-8329131](https://bugs.openjdk.org/browse/JDK-8329131), and with this also the image discovery based on GetApplicationHomeFromDll which uses libjli.so .
> 
> Without libjli.so we have to analyze the LD-LIBRARY_PATH / LIBPATH envvar. There is no other methos available on AIX, because it lacks the $ORIGIN feature of the rpath.

Joachim Kern has updated the pull request incrementally with one additional commit since the last revision:

  only for AIX

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/19000/files
  - new: https://git.openjdk.org/jdk/pull/19000/files/d2fac20e..caf806b3

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

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

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

From asotona at openjdk.org  Fri May  3 15:32:00 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Fri, 3 May 2024 15:32:00 GMT
Subject: RFR: 8331655: ClassFile API ClassCastException with verbose output of
 certain class files
Message-ID: <n31DtePlZliq4n5BIxk8ybpVWEu56Dvd1eEcq1RtL1o=.139af610-5aec-40b4-b6d3-203872e2a0db@github.com>

Specifically corrupted constant pool of a class file can cause ClassCastException, when the entries are accessed by Class-File API in exact order.

This fix avoids the ClassCastException and throws ConstantPoolException instead.
Test is attached.

Please review.

Thanks,
Adam

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

Commit messages:
 - 8331655: ClassFile API ClassCastException with verbose output of certain class files

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

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

From sgehwolf at openjdk.org  Fri May  3 15:57:53 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Fri, 3 May 2024 15:57:53 GMT
Subject: RFR: 8261242: [Linux] OSContainer::is_containerized() returns true
 when run outside a container [v2]
In-Reply-To: <HrCfJ_QTcggLdq-EC_tT7bfoAeDxjxYxzjONnP_RkA4=.5e5a2271-f25e-4eb1-a844-0bb2079149bb@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>
 <HrCfJ_QTcggLdq-EC_tT7bfoAeDxjxYxzjONnP_RkA4=.5e5a2271-f25e-4eb1-a844-0bb2079149bb@github.com>
Message-ID: <NU1gZuqhkiITVFFSKPN_X6CqWOQ6Q2yC7n2QZatjYjE=.7b477cbb-7087-4b3a-83bd-7c9e45298d18@github.com>

On Tue, 16 Apr 2024 18:10:08 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

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

Correct. Note that `%s %*[^-]` doesn't work for files without optionals. Since `%*[^-]` requires a non-empty match and the optionals are, well, optional :-) I've added more verbose comments to clarify this.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18201#discussion_r1589390841

From sgehwolf at openjdk.org  Fri May  3 15:57:57 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Fri, 3 May 2024 15:57:57 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: <51Pz76bzLcZkgBLkoQeslRRTqztF2mIfSsvAZjo38uY=.7c1b4958-56b2-49c8-9311-74d83dfc355f@github.com>

On Tue, 16 Apr 2024 18:16:33 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/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"?

`ctrl` was short for `controller`. I've changed the naming.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18201#discussion_r1589391426

From sgehwolf at openjdk.org  Fri May  3 16:00:54 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Fri, 3 May 2024 16:00:54 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: <iBhi7zbbFxq1cGhkXd5F60t3SXHlxxy75FXhR1-ap6A=.7f8cff51-494a-4f06-b196-5545423d2c83@github.com>

On Tue, 16 Apr 2024 18:21:29 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> Why return here?

Because it's not useful to see containerized settings (other than the cg version in use) after this patch. The JVM won't use them (uses the physical settings instead). Why would you want to show the settings?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18201#discussion_r1589396352

From sgehwolf at openjdk.org  Fri May  3 16:05:30 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Fri, 3 May 2024 16:05:30 GMT
Subject: RFR: 8261242: [Linux] OSContainer::is_containerized() returns true
 when run outside a container [v3]
In-Reply-To: <ElCWVtphfdgi651yIzNsfJS3C5ewhpvOH9ZXjqt3PFE=.de11a3f2-c2fd-4cc4-8c6d-e20f9c8de03d@github.com>
References: <ElCWVtphfdgi651yIzNsfJS3C5ewhpvOH9ZXjqt3PFE=.de11a3f2-c2fd-4cc4-8c6d-e20f9c8de03d@github.com>
Message-ID: <fjbRaZcJI5fetXc1CnGpQK18sjgkhp2Ir6UWNhzYvLs=.f7bd259d-dc6a-46ea-bb58-e062d18eeedb@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 12 additional commits since the last revision:

 - Add doc for mountinfo scanning.
 - Unify naming of variables
 - Merge branch 'master' into jdk-8261242-is-containerized-fix
 - 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
 - ... and 2 more: https://git.openjdk.org/jdk/compare/06fa7bd3...434430ca

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18201/files
  - new: https://git.openjdk.org/jdk/pull/18201/files/0df26ebd..434430ca

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

  Stats: 82529 lines in 2377 files changed: 37138 ins; 34932 del; 10459 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 sgehwolf at openjdk.org  Fri May  3 16:05:30 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Fri, 3 May 2024 16:05:30 GMT
Subject: RFR: 8261242: [Linux] OSContainer::is_containerized() returns true
 when run outside a container
In-Reply-To: <bocf_l6kKagKeqgEhID2Y4UN-yxMC3tL_lXcrFfgyWA=.24552163-bf2e-4e13-8c47-40a65a36f882@github.com>
References: <ElCWVtphfdgi651yIzNsfJS3C5ewhpvOH9ZXjqt3PFE=.de11a3f2-c2fd-4cc4-8c6d-e20f9c8de03d@github.com>
 <c294bf3f-6df7-4d47-b68d-13b2c2222b5a@oracle.com>
 <bocf_l6kKagKeqgEhID2Y4UN-yxMC3tL_lXcrFfgyWA=.24552163-bf2e-4e13-8c47-40a65a36f882@github.com>
Message-ID: <XYvopW80AoPjjrZi3EjaUNMoXGcxDI_FgRcJF8u0Z1w=.2d8a6999-99aa-4465-b425-52f1ec5ee042@github.com>

On Mon, 22 Apr 2024 13:56:23 GMT, Jan Kratochvil <jkratochvil at openjdk.org> wrote:

> 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`.

I've tried to unify the naming a bit. Thanks for the review!

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

PR Comment: https://git.openjdk.org/jdk/pull/18201#issuecomment-2093300919

From sgehwolf at openjdk.org  Fri May  3 16:12:53 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Fri, 3 May 2024 16:12:53 GMT
Subject: RFR: 8261242: [Linux] OSContainer::is_containerized() returns true
 when run outside a container [v2]
In-Reply-To: <iBhi7zbbFxq1cGhkXd5F60t3SXHlxxy75FXhR1-ap6A=.7f8cff51-494a-4f06-b196-5545423d2c83@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>
 <iBhi7zbbFxq1cGhkXd5F60t3SXHlxxy75FXhR1-ap6A=.7f8cff51-494a-4f06-b196-5545423d2c83@github.com>
Message-ID: <h0zT2JxPmx_4Drmpb81rMkZdev3oKkcOTGVPku1rxgg=.f9451674-46fe-45e0-9b67-8c460dc7656f@github.com>

On Fri, 3 May 2024 15:58:11 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> 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)
>
>> Why return here?
> 
> Because it's not useful to see containerized settings (other than the cg version in use) after this patch. The JVM won't use them (uses the physical settings instead). Why would you want to show the settings?

To clarify. `showSettings:system` output on a host system:


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)


... and in a container (with memory limit 500m):


Operating System Metrics:
    Provider: cgroupv1
    Effective CPU Count: 12
    CPU Period: 100000us
    CPU Quota: -1
    CPU Shares: -1
    List of Processors, 12 total: 
    0 1 2 3 4 5 6 7 8 9 10 11 
    List of Effective Processors, 12 total: 
    0 1 2 3 4 5 6 7 8 9 10 11 
    List of Memory Nodes, 1 total: 
    0 
    List of Available Memory Nodes, 1 total: 
    0 
    Memory Limit: 500.00M
    Memory Soft Limit: Unlimited
    Memory & Swap Limit: 500.00M
    Maximum Processes Limit: 2048

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)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18201#discussion_r1589407238

From naoto at openjdk.org  Fri May  3 16:17:10 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 3 May 2024 16:17:10 GMT
Subject: RFR: 8331582: Incorrect default Console provider comment [v2]
In-Reply-To: <zyPDM7c7Q9VhOIJs64c-YUOQ3nWBGQBBbGiDRr2e1sU=.a3e718e5-864c-46c9-95ea-73dd7e2bcd5e@github.com>
References: <zyPDM7c7Q9VhOIJs64c-YUOQ3nWBGQBBbGiDRr2e1sU=.a3e718e5-864c-46c9-95ea-73dd7e2bcd5e@github.com>
Message-ID: <_0IR8yN5tdPNKn1_9o5za6kSO0XdPVL9rSVZxaDIpbE=.53840eb8-bebd-43a4-b666-df7f817cd527@github.com>

> Fixing a comment in `java.io.Console`, which was a leftover from the fix to https://bugs.openjdk.org/browse/JDK-8308591

Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:

  Update src/java.base/share/classes/java/io/Console.java
  
  Thanks. That reads better
  
  Co-authored-by: Pavel Rappo <32523691+pavelrappo at users.noreply.github.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/19070/files
  - new: https://git.openjdk.org/jdk/pull/19070/files/2ab4fdf9..ea465ee2

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

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

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

From naoto at openjdk.org  Fri May  3 16:17:10 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 3 May 2024 16:17:10 GMT
Subject: RFR: 8331582: Incorrect default Console provider comment
In-Reply-To: <zyPDM7c7Q9VhOIJs64c-YUOQ3nWBGQBBbGiDRr2e1sU=.a3e718e5-864c-46c9-95ea-73dd7e2bcd5e@github.com>
References: <zyPDM7c7Q9VhOIJs64c-YUOQ3nWBGQBBbGiDRr2e1sU=.a3e718e5-864c-46c9-95ea-73dd7e2bcd5e@github.com>
Message-ID: <ohsjMilcl3Eew-gwy0lu9fTG0ukVwVJ0yaa-Nz9k-lY=.aa0f67fd-24ba-4b52-bee8-7e14fbf6ac64@github.com>

On Thu, 2 May 2024 20:54:58 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Fixing a comment in `java.io.Console`, which was a leftover from the fix to https://bugs.openjdk.org/browse/JDK-8308591

Thank you for the reviews!

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

PR Comment: https://git.openjdk.org/jdk/pull/19070#issuecomment-2093318995

From naoto at openjdk.org  Fri May  3 16:17:10 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 3 May 2024 16:17:10 GMT
Subject: Integrated: 8331582: Incorrect default Console provider comment
In-Reply-To: <zyPDM7c7Q9VhOIJs64c-YUOQ3nWBGQBBbGiDRr2e1sU=.a3e718e5-864c-46c9-95ea-73dd7e2bcd5e@github.com>
References: <zyPDM7c7Q9VhOIJs64c-YUOQ3nWBGQBBbGiDRr2e1sU=.a3e718e5-864c-46c9-95ea-73dd7e2bcd5e@github.com>
Message-ID: <oT_TTh7uv7M5Ep3rRb8MAAydryXWWg074vUVX2jpuGQ=.00f6396b-0c8b-4fd9-a514-67db0e4e14bc@github.com>

On Thu, 2 May 2024 20:54:58 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Fixing a comment in `java.io.Console`, which was a leftover from the fix to https://bugs.openjdk.org/browse/JDK-8308591

This pull request has now been integrated.

Changeset: cf2c80e4
Author:    Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/cf2c80e4fcd74b9d1d60e2358e7883bdd8a4ac80
Stats:     2 lines in 1 file changed: 1 ins; 0 del; 1 mod

8331582: Incorrect default Console provider comment

Reviewed-by: joehw, jlahoda, jlu, prappo

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

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

From psandoz at openjdk.org  Fri May  3 16:27:51 2024
From: psandoz at openjdk.org (Paul Sandoz)
Date: Fri, 3 May 2024 16:27:51 GMT
Subject: RFR: 8331655: ClassFile API ClassCastException with verbose output
 of certain class files
In-Reply-To: <n31DtePlZliq4n5BIxk8ybpVWEu56Dvd1eEcq1RtL1o=.139af610-5aec-40b4-b6d3-203872e2a0db@github.com>
References: <n31DtePlZliq4n5BIxk8ybpVWEu56Dvd1eEcq1RtL1o=.139af610-5aec-40b4-b6d3-203872e2a0db@github.com>
Message-ID: <xTsOd9DsoxaDOl2H0bDu_N95CLjmgbKVrNDI4A0Fl28=.b01210e5-8228-4e47-8503-d7bc1e38a496@github.com>

On Fri, 3 May 2024 15:28:05 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> Specifically corrupted constant pool of a class file can cause ClassCastException, when the entries are accessed by Class-File API in exact order.
> 
> This fix avoids the ClassCastException and throws ConstantPoolException instead.
> Test is attached.
> 
> Please review.
> 
> Thanks,
> Adam

src/java.base/share/classes/jdk/internal/classfile/impl/ClassReaderImpl.java line 402:

> 400:             int tag = readU1(offset);
> 401:             final int q = offset + 1;
> 402:             if (tag == TAG_UTF8) {

Can we call into the tag accepting entryByIndex? e.g.,

if (entryByIndex(index, TAG_UTF8) instanceof AbstractPoolEntry.Utf8EntryImpl utf8) {
  return ...
}
throw new ...

?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19088#discussion_r1589423345

From jlu at openjdk.org  Fri May  3 17:01:57 2024
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 3 May 2024 17:01:57 GMT
Subject: Integrated: 8295153: java/util/Base64/TestEncodingDecodingLength.java
 ran out of memory
In-Reply-To: <7WCCWuRTV5zB5_YbC57rZ-Yene5L7ky80YJscldD-lk=.53af1f27-031c-4ab4-836f-7d9a0269a42d@github.com>
References: <7WCCWuRTV5zB5_YbC57rZ-Yene5L7ky80YJscldD-lk=.53af1f27-031c-4ab4-836f-7d9a0269a42d@github.com>
Message-ID: <eQTuFgSBJdE4RQ6soIsatXiTw6t56wKapt7fEE5dQ-8=.f6932619-6ec4-45c7-9855-949da41968ed@github.com>

On Wed, 1 May 2024 16:10:06 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which converts _TestEncodingDecodingLength.java_ into a whitebox test which allows for testing to be done without memory usage issues.
> 
> Currently, the test requires about ~2.75 `Integer.MAX_VALUE` sized byte arrays worth of memory. (2 for the initial array allocation, .75 for the target array in `decode()`). While the `-Xms6g -Xmx8g` options should address this, there have been intermittent memory issues, as the underlying machine machine may be running other tests simultaneously.
> 
> By converting this test to a white-box test not only does it get rid of memory issues, but it also gets rid of the need to decode 2GB of data 3 times. The change is done using reflection to test the private visibility methods `encodedOutLength` and `decodedOutLength`, which the public `encode` and `decode` overloaded methods call respectively.

This pull request has now been integrated.

Changeset: b33096f8
Author:    Justin Lu <jlu at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/b33096f887108c3d7e1f4e62689c2b10401234fa
Stats:     81 lines in 1 file changed: 44 ins; 4 del; 33 mod

8295153: java/util/Base64/TestEncodingDecodingLength.java ran out of memory

Reviewed-by: lancea, naoto

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

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

From naoto at openjdk.org  Fri May  3 17:10:54 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 3 May 2024 17:10:54 GMT
Subject: RFR: 8331535: Incorrect prompt for Console.readLine
In-Reply-To: <3m2vXDnx0X_2f3aJxt61yStX_9jyuzIjjhhpgGBmm0Q=.9597c9c6-586a-4ad1-ad91-2a7fa779a427@github.com>
References: <IQvUAYG5zj0JqUbWiQiryAuBrtV6jrVCvy9useQZmlc=.a4dd8dfc-e835-4405-83f8-fd1bda8480f6@github.com>
 <3m2vXDnx0X_2f3aJxt61yStX_9jyuzIjjhhpgGBmm0Q=.9597c9c6-586a-4ad1-ad91-2a7fa779a427@github.com>
Message-ID: <hAmrGczr1ChxLcKOeV62E5Gwa2nMiAW0NqMS9JyaADA=.a7d37721-9fd0-46cc-a8d5-2b5ac5b43c29@github.com>

On Fri, 3 May 2024 11:12:48 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> When JLine reads a line, there may be a prompt provided. However, JLine will not interpret the prompt literally, it will handle `%` specially. As a consequence, doing:
>> 
>> System.console().readLine("%%s");
>> 
>> 
>> will not print `%s`, as first `String.format` is used, which will convert `%%s` to `%s`, and then JLine will interpret the `%`. The proposed solution is to duplicate the `%`, so that JLine will print it.
>
> test/jdk/jdk/internal/jline/JLineConsoleProviderTest.java line 27:
> 
>> 25:  * @test
>> 26:  * @bug 8331535
>> 27:  * @summary Verify the jdk.internal.le's console provider works properly.
> 
> There's a hidden assumption in this test below that the _default_ console is `jdk.internal.le`. Is there any way to assert that?

Or maybe we could explicitly specify `-Djdk.console=jdk.internal.le` to the test.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19081#discussion_r1589477775

From asotona at openjdk.org  Fri May  3 17:13:04 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Fri, 3 May 2024 17:13:04 GMT
Subject: RFR: 8331655: ClassFile API ClassCastException with verbose output
 of certain class files [v2]
In-Reply-To: <n31DtePlZliq4n5BIxk8ybpVWEu56Dvd1eEcq1RtL1o=.139af610-5aec-40b4-b6d3-203872e2a0db@github.com>
References: <n31DtePlZliq4n5BIxk8ybpVWEu56Dvd1eEcq1RtL1o=.139af610-5aec-40b4-b6d3-203872e2a0db@github.com>
Message-ID: <Bv1anYv6bT8-cWShf-8-enLiM9rrJs03cqlwN6KhpL4=.eb49e876-1726-4939-af02-8a7aead5a6b9@github.com>

> Specifically corrupted constant pool of a class file can cause ClassCastException, when the entries are accessed by Class-File API in exact order.
> 
> This fix avoids the ClassCastException and throws ConstantPoolException instead.
> Test is attached.
> 
> Please review.
> 
> Thanks,
> Adam

Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:

  applied suggested changes

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/19088/files
  - new: https://git.openjdk.org/jdk/pull/19088/files/59191c6f..2e94a1b0

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

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

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

From asotona at openjdk.org  Fri May  3 17:13:04 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Fri, 3 May 2024 17:13:04 GMT
Subject: RFR: 8331655: ClassFile API ClassCastException with verbose output
 of certain class files [v2]
In-Reply-To: <xTsOd9DsoxaDOl2H0bDu_N95CLjmgbKVrNDI4A0Fl28=.b01210e5-8228-4e47-8503-d7bc1e38a496@github.com>
References: <n31DtePlZliq4n5BIxk8ybpVWEu56Dvd1eEcq1RtL1o=.139af610-5aec-40b4-b6d3-203872e2a0db@github.com>
 <xTsOd9DsoxaDOl2H0bDu_N95CLjmgbKVrNDI4A0Fl28=.b01210e5-8228-4e47-8503-d7bc1e38a496@github.com>
Message-ID: <QEELKowqUmabB0Sjlcg03x9O4qZdN207GCt7LuYtYcE=.e96b5399-16de-488a-aeb4-116ae7f66614@github.com>

On Fri, 3 May 2024 16:25:30 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   applied suggested changes
>
> src/java.base/share/classes/jdk/internal/classfile/impl/ClassReaderImpl.java line 402:
> 
>> 400:             int tag = readU1(offset);
>> 401:             final int q = offset + 1;
>> 402:             if (tag == TAG_UTF8) {
> 
> Can we call into the tag accepting entryByIndex? e.g.,
> 
> if (entryByIndex(index, TAG_UTF8) instanceof AbstractPoolEntry.Utf8EntryImpl utf8) {
>   return ...
> }
> throw new ...
> 
> ?

Yes, it is a good opportunity to reduce the code a bit.
Thanks!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19088#discussion_r1589483133

From psandoz at openjdk.org  Fri May  3 17:54:52 2024
From: psandoz at openjdk.org (Paul Sandoz)
Date: Fri, 3 May 2024 17:54:52 GMT
Subject: RFR: 8331655: ClassFile API ClassCastException with verbose output
 of certain class files [v2]
In-Reply-To: <Bv1anYv6bT8-cWShf-8-enLiM9rrJs03cqlwN6KhpL4=.eb49e876-1726-4939-af02-8a7aead5a6b9@github.com>
References: <n31DtePlZliq4n5BIxk8ybpVWEu56Dvd1eEcq1RtL1o=.139af610-5aec-40b4-b6d3-203872e2a0db@github.com>
 <Bv1anYv6bT8-cWShf-8-enLiM9rrJs03cqlwN6KhpL4=.eb49e876-1726-4939-af02-8a7aead5a6b9@github.com>
Message-ID: <U8tP-ZRDTJW3YSZEP6tg6pJvEoIaFfsxpi_XmQ4IyYo=.46abfcbf-00ee-4191-a01c-b170bd6267cc@github.com>

On Fri, 3 May 2024 17:13:04 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> Specifically corrupted constant pool of a class file can cause ClassCastException, when the entries are accessed by Class-File API in exact order.
>> 
>> This fix avoids the ClassCastException and throws ConstantPoolException instead.
>> Test is attached.
>> 
>> Please review.
>> 
>> Thanks,
>> Adam
>
> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
> 
>   applied suggested changes

Nice!

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

Marked as reviewed by psandoz (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19088#pullrequestreview-2038729421

From naoto at openjdk.org  Fri May  3 18:16:54 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 3 May 2024 18:16:54 GMT
Subject: RFR: 8331485: Odd Results when Parsing Scientific Notation with
 Large Exponent
In-Reply-To: <lTOZ4RbzZFMN0yLrQKGOcMihdTop24YbYJe2h36SodM=.0addc2ad-b0d1-4721-b860-a9395fa14977@github.com>
References: <lTOZ4RbzZFMN0yLrQKGOcMihdTop24YbYJe2h36SodM=.0addc2ad-b0d1-4721-b860-a9395fa14977@github.com>
Message-ID: <YeL46-TtglynK2-C59N2V06gZ7Q1OjNl7kFyGKgK6UY=.81c206e6-0d3c-4445-83c8-5bdf691f27f2@github.com>

On Fri, 3 May 2024 08:47:03 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which corrects an edge case bug for java.text.DecimalFormat that causes incorrect parsing results for strings with very large exponent values.
> 
> When parsing values with large exponents, if the value of the exponent exceeds `Integer.MAX_VALUE`, the parsed value  is equal to 0. If the value of the exponent exceeds `Long.MAX_VALUE`, the parsed value is equal to the mantissa. Both results are confusing and incorrect.
> 
> For example,
> 
> 
> NumberFormat fmt = NumberFormat.getInstance(Locale.US);
> fmt.parse(".1E2147483648"); // returns 0.0
> fmt.parse(".1E9223372036854775808"); // returns 0.1
> // For comparison
> Double.parseDouble(".1E2147483648"); // returns Infinity
> Double.parseDouble(".1E9223372036854775808"); // returns Infinity
> 
> 
> After this change, both parse calls return `Double.POSITIVE_INFINITY` now.

Looks good. Left some minor comments.

src/java.base/share/classes/java/text/DecimalFormat.java line 2590:

> 2588: 
> 2589:                     if (subparse(text, pos, "", symbols.getMinusSignText(), exponentDigits, true, stat)) {
> 2590:                         // We parse the exponent with isExponent true, thus fitsIntoLong

Nit: `==` or `being` between `isExponent` and `true` may read better.

src/java.base/share/classes/java/text/DecimalFormat.java line 2596:

> 2594:                             exponent = -exponent;
> 2595:                         }
> 2596:                         sawExponent = true;

I see you removed this assignment. I am wondering if we need this variable at all.

test/jdk/java/text/Format/DecimalFormat/LargeExponentsTest.java line 128:

> 126:                 // Trailing zeroes
> 127:                 Arguments.of("1.23E0000123", 1.23E123),
> 128:                 // Trailing zeroes - Past Long.MAX_VALUE length

Leading zeroes?

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

PR Review: https://git.openjdk.org/jdk/pull/19075#pullrequestreview-2038744656
PR Review Comment: https://git.openjdk.org/jdk/pull/19075#discussion_r1589560835
PR Review Comment: https://git.openjdk.org/jdk/pull/19075#discussion_r1589558570
PR Review Comment: https://git.openjdk.org/jdk/pull/19075#discussion_r1589573332

From ron.pressler at oracle.com  Fri May  3 18:20:02 2024
From: ron.pressler at oracle.com (Ron Pressler)
Date: Fri, 3 May 2024 18:20:02 +0000
Subject: [External] : Re: New candidate JEP: 471: Deprecate the
 Memory-Access Methods in sun.misc.Unsafe for Removal
In-Reply-To: <CANghgrShsK7AuWsiuNLj-5Fmy6Dyf5yjUz7fmevXCWQ_dj21Vw@mail.gmail.com>
References: <20240503151140.68BE06C9AEE@eggemoggin.niobe.net>
 <CANghgrShsK7AuWsiuNLj-5Fmy6Dyf5yjUz7fmevXCWQ_dj21Vw@mail.gmail.com>
Message-ID: <7E6CBAA2-470D-4F20-9935-4061D1FD221B@oracle.com>



> On 3 May 2024, at 18:33, David Lloyd <david.lloyd at redhat.com> wrote:
> 
> 
> On Fri, May 3, 2024 at 10:12?AM Mark Reinhold <mark.reinhold at oracle.com> wrote:
> https://openjdk.org/jeps/471
> 
>   Summary: Deprecate the memory-access methods in sun.misc.Unsafe for
>   removal in a future release.
> 
> 
> We still use Unsafe fairly often in various Red Hat products (primarily because our baseline support JDK for these products is typically 11 or 17 at present), in a variety of ways for a variety of reasons. Most of these uses of Unsafe should be transitionable to `MemorySegment` using multi-release JARs, and a bit of exploratory work has already been done on this. However there is one unfortunate exception (that I know of).
> 
> In order to avoid false sharing in certain specific high-concurrency situations, I have lately used arrays to space out certain value locations by using the smallest data cache line size (which is detected via an existing library) and dividing it by the array scale to determine the length of array to allocate in order to accommodate these values. I then use multiples of the cache line size (in bytes), offset from the array base, to locate the elements to access.
> 
> It is possible to continue this more or less as-is for primitive types (at least, it is if one assumes certain facts around primitive data type size and alignment to be true), but for objects, without knowing their size, we can't know how much padding to reserve around the value location to ensure that the contended values are not falsely shared.
> 
> I seem to recall (years ago now so I might be a bit fuzzy on it) that the lack of public API around `@Contended` was mildly controversial in the past. The proposed remedy was to use arrays for this purpose, if I recall correctly. However there does not seem to be any good way to do this anymore (at least for objects) without simply guessing, and this seems like a small but significant hole in this plan as it stands for now.
> 
> It seems to me that the JDK could fill this gap by introducing some API which can construct and provide access to an array or something like it, with striding and/or alignment guarantees that each element will reside on a separate data cache line (or barring that, perhaps using a minimum per-element size and/or alignment that is given as an argument to the factory), and with the gamut of atomic accessors via a `VarHandle` or similar. This could be especially valuable if/when objects start coming in a variety of shapes and sizes in memory, once value types hit.
> 
> Could such a thing be added into the plan?
> 
> -- 
> - DML ? he/him

[redirecting to core-libs]

Adding some VarHandle operation that takes into account the cache lines size is interesting ? although preserving cache-line *alignment* could be tricky as the GC relocates arrays, so an array element that?s at the start of a cache line at time t0 might not be at the start of a cache line at time t1 ? but that?s unrelated to this JEP.

What is related to this JEP is that you?re using Unsafe to determine the size of an oop (in particular, to tell if oops are compressed or no)t. Is that what you?re asking for?

? Ron

From jlu at openjdk.org  Fri May  3 18:29:23 2024
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 3 May 2024 18:29:23 GMT
Subject: RFR: 8331485: Odd Results when Parsing Scientific Notation with
 Large Exponent [v2]
In-Reply-To: <lTOZ4RbzZFMN0yLrQKGOcMihdTop24YbYJe2h36SodM=.0addc2ad-b0d1-4721-b860-a9395fa14977@github.com>
References: <lTOZ4RbzZFMN0yLrQKGOcMihdTop24YbYJe2h36SodM=.0addc2ad-b0d1-4721-b860-a9395fa14977@github.com>
Message-ID: <RkWCGlAEl-DXGMCbPtB8d7YE3F1jo-nhUFBtTOVkw9A=.120e8d1d-c2b1-44d4-9f8a-085a70df254a@github.com>

> Please review this PR which corrects an edge case bug for java.text.DecimalFormat that causes incorrect parsing results for strings with very large exponent values.
> 
> When parsing values with large exponents, if the value of the exponent exceeds `Integer.MAX_VALUE`, the parsed value  is equal to 0. If the value of the exponent exceeds `Long.MAX_VALUE`, the parsed value is equal to the mantissa. Both results are confusing and incorrect.
> 
> For example,
> 
> 
> NumberFormat fmt = NumberFormat.getInstance(Locale.US);
> fmt.parse(".1E2147483648"); // returns 0.0
> fmt.parse(".1E9223372036854775808"); // returns 0.1
> // For comparison
> Double.parseDouble(".1E2147483648"); // returns Infinity
> Double.parseDouble(".1E9223372036854775808"); // returns Infinity
> 
> 
> After this change, both parse calls return `Double.POSITIVE_INFINITY` now.

Justin Lu has updated the pull request incrementally with two additional commits since the last revision:

 - correct other test comment
 - reflect review

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/19075/files
  - new: https://git.openjdk.org/jdk/pull/19075/files/5bf5d6ef..bc391f96

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

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

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

From jlu at openjdk.org  Fri May  3 18:29:23 2024
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 3 May 2024 18:29:23 GMT
Subject: RFR: 8331485: Odd Results when Parsing Scientific Notation with
 Large Exponent [v2]
In-Reply-To: <YeL46-TtglynK2-C59N2V06gZ7Q1OjNl7kFyGKgK6UY=.81c206e6-0d3c-4445-83c8-5bdf691f27f2@github.com>
References: <lTOZ4RbzZFMN0yLrQKGOcMihdTop24YbYJe2h36SodM=.0addc2ad-b0d1-4721-b860-a9395fa14977@github.com>
 <YeL46-TtglynK2-C59N2V06gZ7Q1OjNl7kFyGKgK6UY=.81c206e6-0d3c-4445-83c8-5bdf691f27f2@github.com>
Message-ID: <D08MH2tMeR2I920kJwVUOxGOBaHojhh3bEEKS2mDl9Q=.dd989d44-9109-4925-8b39-3e53e28cbfb1@github.com>

On Fri, 3 May 2024 18:02:05 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Justin Lu has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - correct other test comment
>>  - reflect review
>
> src/java.base/share/classes/java/text/DecimalFormat.java line 2596:
> 
>> 2594:                             exponent = -exponent;
>> 2595:                         }
>> 2596:                         sawExponent = true;
> 
> I see you removed this assignment. I am wondering if we need this variable at all.

Should be updated in the latest commit, I had forgotten to remove the assignment as well as the check. As we always `break` once we parse the exponent, we have no need for the boolean flag. Thanks for the review!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19075#discussion_r1589587379

From jlu at openjdk.org  Fri May  3 18:29:23 2024
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 3 May 2024 18:29:23 GMT
Subject: RFR: 8331485: Odd Results when Parsing Scientific Notation with
 Large Exponent [v2]
In-Reply-To: <D08MH2tMeR2I920kJwVUOxGOBaHojhh3bEEKS2mDl9Q=.dd989d44-9109-4925-8b39-3e53e28cbfb1@github.com>
References: <lTOZ4RbzZFMN0yLrQKGOcMihdTop24YbYJe2h36SodM=.0addc2ad-b0d1-4721-b860-a9395fa14977@github.com>
 <YeL46-TtglynK2-C59N2V06gZ7Q1OjNl7kFyGKgK6UY=.81c206e6-0d3c-4445-83c8-5bdf691f27f2@github.com>
 <D08MH2tMeR2I920kJwVUOxGOBaHojhh3bEEKS2mDl9Q=.dd989d44-9109-4925-8b39-3e53e28cbfb1@github.com>
Message-ID: <EjK-_Y138sw0v7ffJ9OZ6rY4mrqUHFhR547f824DcJc=.c71fa752-beb4-464e-aed0-e391bb6ff605@github.com>

On Fri, 3 May 2024 18:24:31 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> src/java.base/share/classes/java/text/DecimalFormat.java line 2596:
>> 
>>> 2594:                             exponent = -exponent;
>>> 2595:                         }
>>> 2596:                         sawExponent = true;
>> 
>> I see you removed this assignment. I am wondering if we need this variable at all.
>
> Should be updated in the latest commit, I had forgotten to remove the assignment as well as the check. As we always `break` once we parse the exponent, we have no need for the boolean flag. Thanks for the review!

Perhaps there was a planned reason for it before, but as it stands it serves no purpose, so until there is a reason to have it, I think we can safely remove it to de-clutter the code.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19075#discussion_r1589588844

From naoto at openjdk.org  Fri May  3 18:42:58 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 3 May 2024 18:42:58 GMT
Subject: RFR: 8331485: Odd Results when Parsing Scientific Notation with
 Large Exponent [v2]
In-Reply-To: <RkWCGlAEl-DXGMCbPtB8d7YE3F1jo-nhUFBtTOVkw9A=.120e8d1d-c2b1-44d4-9f8a-085a70df254a@github.com>
References: <lTOZ4RbzZFMN0yLrQKGOcMihdTop24YbYJe2h36SodM=.0addc2ad-b0d1-4721-b860-a9395fa14977@github.com>
 <RkWCGlAEl-DXGMCbPtB8d7YE3F1jo-nhUFBtTOVkw9A=.120e8d1d-c2b1-44d4-9f8a-085a70df254a@github.com>
Message-ID: <gbifoC5lIJJOg4tYjky9ZyN7xJ28hWu17hVE9Niovzo=.cf4f9b4a-9e65-4610-9b85-810e01fdd38c@github.com>

On Fri, 3 May 2024 18:29:23 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please review this PR which corrects an edge case bug for java.text.DecimalFormat that causes incorrect parsing results for strings with very large exponent values.
>> 
>> When parsing values with large exponents, if the value of the exponent exceeds `Integer.MAX_VALUE`, the parsed value  is equal to 0. If the value of the exponent exceeds `Long.MAX_VALUE`, the parsed value is equal to the mantissa. Both results are confusing and incorrect.
>> 
>> For example,
>> 
>> 
>> NumberFormat fmt = NumberFormat.getInstance(Locale.US);
>> fmt.parse(".1E2147483648"); // returns 0.0
>> fmt.parse(".1E9223372036854775808"); // returns 0.1
>> // For comparison
>> Double.parseDouble(".1E2147483648"); // returns Infinity
>> Double.parseDouble(".1E9223372036854775808"); // returns Infinity
>> 
>> 
>> After this change, both parse calls return `Double.POSITIVE_INFINITY` now.
>
> Justin Lu has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - correct other test comment
>  - reflect review

Marked as reviewed by naoto (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/19075#pullrequestreview-2038805949

From prappo at openjdk.org  Fri May  3 18:54:52 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Fri, 3 May 2024 18:54:52 GMT
Subject: RFR: 8331535: Incorrect prompt for Console.readLine
In-Reply-To: <hAmrGczr1ChxLcKOeV62E5Gwa2nMiAW0NqMS9JyaADA=.a7d37721-9fd0-46cc-a8d5-2b5ac5b43c29@github.com>
References: <IQvUAYG5zj0JqUbWiQiryAuBrtV6jrVCvy9useQZmlc=.a4dd8dfc-e835-4405-83f8-fd1bda8480f6@github.com>
 <3m2vXDnx0X_2f3aJxt61yStX_9jyuzIjjhhpgGBmm0Q=.9597c9c6-586a-4ad1-ad91-2a7fa779a427@github.com>
 <hAmrGczr1ChxLcKOeV62E5Gwa2nMiAW0NqMS9JyaADA=.a7d37721-9fd0-46cc-a8d5-2b5ac5b43c29@github.com>
Message-ID: <ZyGQrhrrVBjBxbOaTmSMhIdtUm6AgvSE9U3Sg8tBGOM=.651480e9-34d1-4517-baab-a6ddefb16fe5@github.com>

On Fri, 3 May 2024 17:07:59 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Or maybe we could explicitly specify `-Djdk.console=jdk.internal.le` to the test.

We could do that, or we could replace `jdk.internal.le` with "default" in the summary.

Ideally, we should have separate tests that make sure that jdk.internal.le is the default impl. We should also test this behaviour (i.e. % interpretation) on jdk.internal.io Console impl. What do you think?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19081#discussion_r1589620826

From brian.burkhalter at oracle.com  Fri May  3 19:01:39 2024
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Fri, 3 May 2024 19:01:39 +0000
Subject: Need for a sponsor for JDK-8313674
In-Reply-To: <CA+wBRWAESfCOEB0=Oj7gr=PtVBd3qgvSxFEfNocbFg4TNKhSAw@mail.gmail.com>
References: <CA+wBRWAESfCOEB0=Oj7gr=PtVBd3qgvSxFEfNocbFg4TNKhSAw@mail.gmail.com>
Message-ID: <823A67C0-152A-4F04-86FE-16B72E768267@oracle.com>

Hello,

This is the PR [1]. This is the sequence that should be followed:

1. Align the name title of the PR with the issue. (you)
2. Continue the conversation until at least one Reviewer approves it. (one or more of us)
3. Comment with /integrate command. (you)
4. Comment with /sponsor command. (one of us).

Alan might have more comments on this, and given that it is after close of business in his time zone, I don?t think we?ll see further progress before Monday.

Thanks,

Brian

[1] https://github.com/openjdk/jdk/pull/19021

On Apr 24, 2024, at 9:23?PM, I?igo Mediavilla <imediava at gmail.com> wrote:

For my first contribution to OpenJDK, I've started looking into JDK-8313674, an issue that falls into core-libs. According to the OpenJDK Developers? Guide I'd need a sponsor to help me through the contribution process, would anyone be available to help me ?

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240503/4174eeb6/attachment-0001.htm>

From naoto at openjdk.org  Fri May  3 19:05:54 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 3 May 2024 19:05:54 GMT
Subject: RFR: 8331535: Incorrect prompt for Console.readLine
In-Reply-To: <ZyGQrhrrVBjBxbOaTmSMhIdtUm6AgvSE9U3Sg8tBGOM=.651480e9-34d1-4517-baab-a6ddefb16fe5@github.com>
References: <IQvUAYG5zj0JqUbWiQiryAuBrtV6jrVCvy9useQZmlc=.a4dd8dfc-e835-4405-83f8-fd1bda8480f6@github.com>
 <3m2vXDnx0X_2f3aJxt61yStX_9jyuzIjjhhpgGBmm0Q=.9597c9c6-586a-4ad1-ad91-2a7fa779a427@github.com>
 <hAmrGczr1ChxLcKOeV62E5Gwa2nMiAW0NqMS9JyaADA=.a7d37721-9fd0-46cc-a8d5-2b5ac5b43c29@github.com>
 <ZyGQrhrrVBjBxbOaTmSMhIdtUm6AgvSE9U3Sg8tBGOM=.651480e9-34d1-4517-baab-a6ddefb16fe5@github.com>
Message-ID: <-1kM8rbTDNczIqktUIsWDXpreQLTJvqSkEINSVdLJ6g=.3ab5d6c5-dde6-4204-aed2-c4d62b5024ef@github.com>

On Fri, 3 May 2024 18:52:12 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> Ideally, we should have separate tests that make sure that jdk.internal.le is the default impl.

We have a test that checks if `System.console()` returns the correct Console (or null) from the expected module (`test/jdk/java/io/Console/ModuleSelectionTest.java`)

> We should also test this behaviour (i.e. % interpretation) on jdk.internal.io Console impl.

Yeah, that would be helpful.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19081#discussion_r1589629655

From asotona at openjdk.org  Fri May  3 19:17:56 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Fri, 3 May 2024 19:17:56 GMT
Subject: Integrated: 8331655: ClassFile API ClassCastException with verbose
 output of certain class files
In-Reply-To: <n31DtePlZliq4n5BIxk8ybpVWEu56Dvd1eEcq1RtL1o=.139af610-5aec-40b4-b6d3-203872e2a0db@github.com>
References: <n31DtePlZliq4n5BIxk8ybpVWEu56Dvd1eEcq1RtL1o=.139af610-5aec-40b4-b6d3-203872e2a0db@github.com>
Message-ID: <S9GzTDoPqX1-f9iDjeeg9KcMwoyaepjEmS_b6oUHxCo=.57c04903-bff0-4b82-9976-91a50ebb0661@github.com>

On Fri, 3 May 2024 15:28:05 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> Specifically corrupted constant pool of a class file can cause ClassCastException, when the entries are accessed by Class-File API in exact order.
> 
> This fix avoids the ClassCastException and throws ConstantPoolException instead.
> Test is attached.
> 
> Please review.
> 
> Thanks,
> Adam

This pull request has now been integrated.

Changeset: c1a16452
Author:    Adam Sotona <asotona at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/c1a164528a538d5de78f99c4c92291b1906703f5
Stats:     24 lines in 2 files changed: 9 ins; 11 del; 4 mod

8331655: ClassFile API ClassCastException with verbose output of certain class files

Reviewed-by: psandoz

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

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

From kevin.rushforth at oracle.com  Fri May  3 19:27:48 2024
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Fri, 3 May 2024 12:27:48 -0700
Subject: Need for a sponsor for JDK-8313674
In-Reply-To: <823A67C0-152A-4F04-86FE-16B72E768267@oracle.com>
References: <CA+wBRWAESfCOEB0=Oj7gr=PtVBd3qgvSxFEfNocbFg4TNKhSAw@mail.gmail.com>
 <823A67C0-152A-4F04-86FE-16B72E768267@oracle.com>
Message-ID: <187833a8-c5bd-40c2-8b61-067affa14c3e@oracle.com>

Also , as a helpful hint, Skara has reminded you not to force push [1]. 
I see that you have done this a couple times, which suggests you might 
be in the habit of doing this as part of your workflow. Please don't. 
Instead, if you need to make changes, push the changes as additional 
commits. Skara will squash all of the commits into a single commit with 
the proper title, list of reviewers, etc.

Thanks.

-- Kevin

[1] https://github.com/openjdk/jdk/pull/19021#issuecomment-2085328329


On 5/3/2024 12:01 PM, Brian Burkhalter wrote:
> Hello,
>
> This is the PR [1]. This is the sequence that should be followed:
>
> 1. Align the name title of the PR with the issue. (you)
> 2. Continue the conversation until at least one Reviewer approves it. 
> (one or more of us)
> 3. Comment with /integrate command. (you)
> 4. Comment with /sponsor command. (one of us).
>
> Alan might have more comments on this, and given that it is after 
> close of business in his time zone, I don?t think we?ll see further 
> progress before Monday.
>
> Thanks,
>
> Brian
>
> [1] https://github.com/openjdk/jdk/pull/19021
>
>> On Apr 24, 2024, at 9:23?PM, I?igo Mediavilla <imediava at gmail.com> wrote:
>>
>> For my first contribution to OpenJDK, I've started looking into 
>> JDK-8313674, an issue that falls into core-libs. According to the 
>> OpenJDK Developers? Guide I'd need a sponsor to help me through the 
>> contribution process, would anyone be available to help me ?
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240503/a702c17e/attachment-0001.htm>

From rriggs at openjdk.org  Fri May  3 19:54:54 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 3 May 2024 19:54:54 GMT
Subject: RFR: 8330276: Console methods with explicit Locale [v2]
In-Reply-To: <3PG6UCpNxIV2SSDuHcQ66RhUisK1MNtWT-IX68iXuEc=.c3f3e3b5-988f-4178-8ec7-992b8de6b8ca@github.com>
References: <GT275XVwYlYL3PhYwOTQ_-HwKqp9QYUeIzEIeJKEwkQ=.9a7faf08-8637-45a3-97bd-fd58756a6711@github.com>
 <3PG6UCpNxIV2SSDuHcQ66RhUisK1MNtWT-IX68iXuEc=.c3f3e3b5-988f-4178-8ec7-992b8de6b8ca@github.com>
Message-ID: <9mG8LRGPDCyJUH6ftDQ1w9nNA23pfj1HVtLFksbI1vo=.af217a17-1a9e-4375-9921-9e0cd448cccb@github.com>

On Mon, 29 Apr 2024 23:22:21 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Proposing new overloaded methods in `java.io.Console` class that explicitly take a `Locale` argument. Existing methods rely on the default locale, so the users won't be able to format their prompts/outputs in a certain locale explicitly.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Addressed review comments

lgtm

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

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18923#pullrequestreview-2038907502

From john.r.rose at oracle.com  Fri May  3 21:18:03 2024
From: john.r.rose at oracle.com (John Rose)
Date: Fri, 03 May 2024 14:18:03 -0700
Subject: [External] : Re: New candidate JEP: 471: Deprecate the
 Memory-Access Methods in sun.misc.Unsafe for Removal
In-Reply-To: <7E6CBAA2-470D-4F20-9935-4061D1FD221B@oracle.com>
References: <20240503151140.68BE06C9AEE@eggemoggin.niobe.net>
 <CANghgrShsK7AuWsiuNLj-5Fmy6Dyf5yjUz7fmevXCWQ_dj21Vw@mail.gmail.com>
 <7E6CBAA2-470D-4F20-9935-4061D1FD221B@oracle.com>
Message-ID: <F97470D2-17B9-49B4-9211-DB4EB415BD73@oracle.com>

Some of these sorts of use cases could be covered by somehow discovering
a platform-specific parameter N such that a[I] and a[I+N] are not likely
to have false sharing in a data cache, for any I.  (Or a series of N0,
N1, ? that prevent a[N0], a[N1]? from being falsely shared.)  David is
right that this parameter depends on the physical array stride,
and that depends on (1) compressed oops or not, and/or (2) flattening
of specific element types.  It depends on cache architecture also.
Throw Leyden into the mix, and it is not clear that just querying
a number is the right answer, either, since it might be predicted
one way by Leyden and end up differently in application deployment.

But this is fragile and error-prone, I think.  It might be nicer
to encapsulate it as folks suggest, even though its users are
power users.  (They are probably power users in a different
domain from VM implementation.)

So I also would prefer to see, rather than a fragile idiom for using
arrays, an API that features an opaque container object and a varhandle
for accessing its (un-)contended ?lanes?. The thing would feel like
an ?array with varhandles?.  And the opaque object might even be
an array of some sort, if you looked at it closely.  I don?t think
it needs to be wrapped in an envelope to hide its nature.  Power
users ought to know not to look too closely at the container object.

It seems to me that this should be built first on top of the JDK,
not inside the JDK, as a way to shake out the design before the JDK
commits to such a design.

The @Contended feature does not ensure that (un-)contended fields
fall at the start of a cache line, because the VM does not align
objects that precisely (by default).  Likewise, an indexed version
like we are talking about here would not guarantee any particular
offset that the data lanes would fall in (within cache lines).
It would simply set unrelated ones far enough apart to ensure that
that they cannot fall on the same cache line; this requires that
the platform guarantee an appropriate minimum distance.

BTW, the @Contended feature allows fields to be grouped.  A good
corresponding feature for arrays (with varhandles) should allow
for grouping similarly.

So, a first draft API might look something like this:

class ContendedArrayFactory {
  ContendedArrayFactory(Class<?> elementType, int groupSize);
  VarHandle accessor(int which);  // which < groupSize
  ContendedArrayFactory(Class<?> elementType); // default groupSize=1
  VarHandle accessor();  // default which=0
  Object make(int length);  // storage len = roundup(groupSize,D$len)*length
}

In a Leyden setting, each ContendedArrayFactory, and the arrays it
makes, should be (re)generated fresh at startup, if there is suspicion
that data cache size could change.  Frankly, I don?t think there will
be such a suspicion.  Leyden tends to ?bake in? environmental settings
such as whether oop compression is enabled.

(The real core libs people should weigh in; I?m just brainstorming here.)

On 3 May 2024, at 11:20, Ron Pressler wrote:

>> On 3 May 2024, at 18:33, David Lloyd <david.lloyd at redhat.com> wrote:
>>
>>
>> On Fri, May 3, 2024 at 10:12?AM Mark Reinhold <mark.reinhold at oracle.com> wrote:
>> https://openjdk.org/jeps/471
>>
>>   Summary: Deprecate the memory-access methods in sun.misc.Unsafe for
>>   removal in a future release.
>>
>>
>> We still use Unsafe fairly often in various Red Hat products (primarily because our baseline support JDK for these products is typically 11 or 17 at present), in a variety of ways for a variety of reasons. Most of these uses of Unsafe should be transitionable to `MemorySegment` using multi-release JARs, and a bit of exploratory work has already been done on this. However there is one unfortunate exception (that I know of).
>>
>> In order to avoid false sharing in certain specific high-concurrency situations, I have lately used arrays to space out certain value locations by using the smallest data cache line size (which is detected via an existing library) and dividing it by the array scale to determine the length of array to allocate in order to accommodate these values. I then use multiples of the cache line size (in bytes), offset from the array base, to locate the elements to access.
>>
>> It is possible to continue this more or less as-is for primitive types (at least, it is if one assumes certain facts around primitive data type size and alignment to be true), but for objects, without knowing their size, we can't know how much padding to reserve around the value location to ensure that the contended values are not falsely shared.
>>
>> I seem to recall (years ago now so I might be a bit fuzzy on it) that the lack of public API around `@Contended` was mildly controversial in the past. The proposed remedy was to use arrays for this purpose, if I recall correctly. However there does not seem to be any good way to do this anymore (at least for objects) without simply guessing, and this seems like a small but significant hole in this plan as it stands for now.
>>
>> It seems to me that the JDK could fill this gap by introducing some API which can construct and provide access to an array or something like it, with striding and/or alignment guarantees that each element will reside on a separate data cache line (or barring that, perhaps using a minimum per-element size and/or alignment that is given as an argument to the factory), and with the gamut of atomic accessors via a `VarHandle` or similar. This could be especially valuable if/when objects start coming in a variety of shapes and sizes in memory, once value types hit.
>>
>> Could such a thing be added into the plan?
>>
>> -- 
>> - DML ? he/him
>
> [redirecting to core-libs]
>
> Adding some VarHandle operation that takes into account the cache lines size is interesting ? although preserving cache-line *alignment* could be tricky as the GC relocates arrays, so an array element that?s at the start of a cache line at time t0 might not be at the start of a cache line at time t1 ? but that?s unrelated to this JEP.
>
> What is related to this JEP is that you?re using Unsafe to determine the size of an oop (in particular, to tell if oops are compressed or no)t. Is that what you?re asking for?
>
> ? Ron

From john.r.rose at oracle.com  Fri May  3 21:24:47 2024
From: john.r.rose at oracle.com (John Rose)
Date: Fri, 03 May 2024 14:24:47 -0700
Subject: [External] : Re: New candidate JEP: 471: Deprecate the
 Memory-Access Methods in sun.misc.Unsafe for Removal
In-Reply-To: <F97470D2-17B9-49B4-9211-DB4EB415BD73@oracle.com>
References: <20240503151140.68BE06C9AEE@eggemoggin.niobe.net>
 <CANghgrShsK7AuWsiuNLj-5Fmy6Dyf5yjUz7fmevXCWQ_dj21Vw@mail.gmail.com>
 <7E6CBAA2-470D-4F20-9935-4061D1FD221B@oracle.com>
 <F97470D2-17B9-49B4-9211-DB4EB415BD73@oracle.com>
Message-ID: <6644F832-3BA7-4E44-BEFD-2F09F8A3673D@oracle.com>

P.S. I didn?t directly address David?s request for that magic number N.
I would just assume 32 bits as the conservative element size (for oops)
and work from there.  If the cache line size is 64 bytes, then N=16.
These are robust assumptions, even if they waste a little space
when N could be 8 (because oops are 64 bits).  If the objects are
flattened, N=16 is still conservatively correct, as long as they
flatten to at least 4 bytes (which is very likely, and if not just
use a primitive array).  The same external considerations that
determine the D$ line size, to a value other than 64, can also
configure the parameter N, to a value other than 16.  That is
how I would build David?s widget without using Unsafe.

From prappo at openjdk.org  Fri May  3 22:01:57 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Fri, 3 May 2024 22:01:57 GMT
Subject: RFR: 8331535: Incorrect prompt for Console.readLine
In-Reply-To: <-1kM8rbTDNczIqktUIsWDXpreQLTJvqSkEINSVdLJ6g=.3ab5d6c5-dde6-4204-aed2-c4d62b5024ef@github.com>
References: <IQvUAYG5zj0JqUbWiQiryAuBrtV6jrVCvy9useQZmlc=.a4dd8dfc-e835-4405-83f8-fd1bda8480f6@github.com>
 <3m2vXDnx0X_2f3aJxt61yStX_9jyuzIjjhhpgGBmm0Q=.9597c9c6-586a-4ad1-ad91-2a7fa779a427@github.com>
 <hAmrGczr1ChxLcKOeV62E5Gwa2nMiAW0NqMS9JyaADA=.a7d37721-9fd0-46cc-a8d5-2b5ac5b43c29@github.com>
 <ZyGQrhrrVBjBxbOaTmSMhIdtUm6AgvSE9U3Sg8tBGOM=.651480e9-34d1-4517-baab-a6ddefb16fe5@github.com>
 <-1kM8rbTDNczIqktUIsWDXpreQLTJvqSkEINSVdLJ6g=.3ab5d6c5-dde6-4204-aed2-c4d62b5024ef@github.com>
Message-ID: <01jKa1Vle6swIlyHyAGC9RLlkvKMABNV4gARTNkctb0=.db05c58c-cae1-4860-a41f-542d55b58671@github.com>

On Fri, 3 May 2024 19:02:41 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> We have a test that checks if `System.console()` returns the correct Console (or null) from the expected module (`test/jdk/java/io/Console/ModuleSelectionTest.java`)
>

Good; then here we should indeed specify `-Djdk.console=jdk.internal.le`. Initially, I suggested an alternative wording (i.e. "default"), but that's inappropriate. After all, the test in question resides in `test/jdk/jdk/internal/jline`. So it only makes sense that it tests that concrete implementation. 

> Yeah, that would be helpful.
>

I filed a bug: https://bugs.openjdk.org/browse/JDK-8331681

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19081#discussion_r1589756489

From sgibbons at openjdk.org  Fri May  3 23:22:31 2024
From: sgibbons at openjdk.org (Scott Gibbons)
Date: Fri, 3 May 2024 23:22:31 GMT
Subject: RFR: 8320448: Accelerate IndexOf using AVX2 [v18]
In-Reply-To: <uWi4QxH31hL93771gkl_GgvP0m84IRSoR_1Yi8hD17E=.bc6ed458-7081-4c3f-9348-f59358fa05a4@github.com>
References: <uWi4QxH31hL93771gkl_GgvP0m84IRSoR_1Yi8hD17E=.bc6ed458-7081-4c3f-9348-f59358fa05a4@github.com>
Message-ID: <daUur0Wvlm-_89LbVTWtJ4UCPxPe_23_Ijvhgi03220=.df7ed5ae-a16d-4d7c-a560-6698c979bb1e@github.com>

> Re-write the IndexOf code without the use of the pcmpestri instruction, only using AVX2 instructions.  This change accelerates String.IndexOf on average 1.3x for AVX2.  The benchmark numbers:
> 
> 
> Benchmark	                                               Score		Latest		
> StringIndexOf.advancedWithMediumSub   343.573		317.934		0.925375393x
> StringIndexOf.advancedWithShortSub1	  1039.081		1053.96		1.014319384x
> StringIndexOf.advancedWithShortSub2	      55.828		110.541		1.980027943x
> StringIndexOf.constantPattern	                9.361		11.906		1.271872663x
> StringIndexOf.searchCharLongSuccess	        4.216		4.218		1.000474383x
> StringIndexOf.searchCharMediumSuccess	3.133		3.216		1.02649218x
> StringIndexOf.searchCharShortSuccess	3.76		        3.761		1.000265957x
> StringIndexOf.success	                                9.186		9.713		1.057369911x
> StringIndexOf.successBig	                      14.341		46.343		3.231504079x
> StringIndexOfChar.latin1_AVX2_String	  6220.918		12154.52		1.953814533x
> StringIndexOfChar.latin1_AVX2_char	  5503.556		5540.044		1.006629895x
> StringIndexOfChar.latin1_SSE4_String	  6978.854		6818.689		0.977049957x
> StringIndexOfChar.latin1_SSE4_char	  5657.499		5474.624		0.967675646x
> StringIndexOfChar.latin1_Short_String	  7132.541		6863.359		0.962260014x
> StringIndexOfChar.latin1_Short_char	16013.389	      16162.437		1.009307711x
> StringIndexOfChar.latin1_mixed_String	  7386.123	      14771.622		1.999915517x
> StringIndexOfChar.latin1_mixed_char	  9901.671		9782.245		0.987938803

Scott Gibbons has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 50 commits:

 - Merge remote-tracking branch 'origin/master' into indexof
 - Move arrays_equals back to c2_MacroAssembler
 - Merge branch 'openjdk:master' into indexof
 - Remove infinite loop (used for debugging)
 - Merge branch 'openjdk:master' into indexof
 - Cleaned up, ready for review
 - Pre-cleanup code
 - Add JMH. Add 16-byte compares to arrays_equals
 - Better method for mask creation
 - Merge branch 'openjdk:master' into indexof
 - ... and 40 more: https://git.openjdk.org/jdk/compare/b20fa7b4...f52d281d

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

Changes: https://git.openjdk.org/jdk/pull/16753/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16753&range=17
  Stats: 4345 lines in 17 files changed: 4183 ins; 26 del; 136 mod
  Patch: https://git.openjdk.org/jdk/pull/16753.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16753/head:pull/16753

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

From david.lloyd at redhat.com  Sat May  4 15:10:26 2024
From: david.lloyd at redhat.com (David Lloyd)
Date: Sat, 4 May 2024 10:10:26 -0500
Subject: [External] : Re: New candidate JEP: 471: Deprecate the
 Memory-Access Methods in sun.misc.Unsafe for Removal
In-Reply-To: <7E6CBAA2-470D-4F20-9935-4061D1FD221B@oracle.com>
References: <20240503151140.68BE06C9AEE@eggemoggin.niobe.net>
 <CANghgrShsK7AuWsiuNLj-5Fmy6Dyf5yjUz7fmevXCWQ_dj21Vw@mail.gmail.com>
 <7E6CBAA2-470D-4F20-9935-4061D1FD221B@oracle.com>
Message-ID: <CANghgrRN-vjmYqen2=tm_Qt8HwjVqc-EpBFk8Yf_1ihqf0oLNQ@mail.gmail.com>

On Fri, May 3, 2024 at 1:20?PM Ron Pressler <ron.pressler at oracle.com> wrote:

>
>
> > On 3 May 2024, at 18:33, David Lloyd <david.lloyd at redhat.com> wrote:
> > It seems to me that the JDK could fill this gap by introducing some API
> which can construct and provide access to an array or something like it,
> with striding and/or alignment guarantees that each element will reside on
> a separate data cache line (or barring that, perhaps using a minimum
> per-element size and/or alignment that is given as an argument to the
> factory), and with the gamut of atomic accessors via a `VarHandle` or
> similar. This could be especially valuable if/when objects start coming in
> a variety of shapes and sizes in memory, once value types hit.
> >
> > Could such a thing be added into the plan?
>
> [redirecting to core-libs]
>

Good call, I should have thought of that.

Adding some VarHandle operation that takes into account the cache lines
> size is interesting ? although preserving cache-line *alignment* could be
> tricky as the GC relocates arrays, so an array element that?s at the start
> of a cache line at time t0 might not be at the start of a cache line at
> time t1 ? but that?s unrelated to this JEP.
>
> What is related to this JEP is that you?re using Unsafe to determine the
> size of an oop (in particular, to tell if oops are compressed or no)t. Is
> that what you?re asking for?
>

What I need - my actual use case - is some way to guarantee that some piece
of data is stored alone on its own cache line. This may be a subset of a
broader use case where some set of values should be stored alone on its own
cache line.

To achieve this use case I am presently making assumptions about objects in
an array - specifically that they are stored as oops, and that an oop is
smaller than a cache line (okay that's a fairly reasonable assumption I
guess), and that I can find out the size of an oop so that I can scale
things appropriately. But recognizing that this is not a good kind of
assumption to make, I would rather have an API that (for example) lets me
create and access an array (probably via VarHandle) such that I can
guarantee that each item is a of minimum size (and that size, for my use
case, is going to be what I can determine as the minimum data cache line
size).

A general API which does this would be cool, but I'd be hard-pressed to
imagine a use case for target size other than the data cache line size.

On preserving larger alignment of array contents - that would be generally
pretty interesting. It is not necessary for my use case though, and
probably would be very difficult to implement anyway.

As John suggests, I can probably work around the problem by being very
conservative in my estimates. I can assume that an oop is 4 bytes for
example, and this would work (possibly at the cost of a bit of extra empty
space, and in the hope that nobody will invent some even smaller oop
encoding). I can also assume that a `long` is 8 bytes (this is a safer
assumption) without too much risk.  But it feels like there could be a more
optimal solution in the JDK for this.

-- 
- DML ? he/him
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240504/048fe1db/attachment-0001.htm>

From rgiulietti at openjdk.org  Sat May  4 18:29:25 2024
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Sat, 4 May 2024 18:29:25 GMT
Subject: RFR: 8330005: RandomGeneratorFactory.getDefault() throws exception
 when the runtime image only has java.base module [v6]
In-Reply-To: <FymnGzlEZUHwHgW6At_bqYIoF7wYsjD_vBhk60PrwFE=.1ef4072e-c3a4-4930-8d18-ba132fa90c56@github.com>
References: <FymnGzlEZUHwHgW6At_bqYIoF7wYsjD_vBhk60PrwFE=.1ef4072e-c3a4-4930-8d18-ba132fa90c56@github.com>
Message-ID: <ZCknDWh6FaLWfXb9c9QFsnK9GrqdTXaHSVcG5jmZ6g8=.c1dd43f6-c571-46e8-880f-7f864fc56b62@github.com>

> Move all random generators mandated in package `java.util.random` and currently implemented in module `jdk.random` to module `java.base`, and remove module `jdk.random`.

Raffaello Giulietti 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 seven additional commits since the last revision:

 - Merge branch 'master' into 8330005
 - Restrict RandomGenerator service providers to those loadable by the platform class loader.
 - Typo.
 - Added @uses javadoc tag for j.u.r.RandomGenerator in java.base.
 - Terminology changes.
 - Renamed package jdk.random to jdk.internal.random.
 - 8330005: RandomGeneratorFactory.getDefault() throws exception when the runtime image only has java.base module

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18932/files
  - new: https://git.openjdk.org/jdk/pull/18932/files/59c86b43..8a5598ea

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

  Stats: 22890 lines in 1641 files changed: 7834 ins; 9521 del; 5535 mod
  Patch: https://git.openjdk.org/jdk/pull/18932.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18932/head:pull/18932

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

From sgibbons at openjdk.org  Sat May  4 19:35:21 2024
From: sgibbons at openjdk.org (Scott Gibbons)
Date: Sat, 4 May 2024 19:35:21 GMT
Subject: RFR: 8320448: Accelerate IndexOf using AVX2 [v19]
In-Reply-To: <uWi4QxH31hL93771gkl_GgvP0m84IRSoR_1Yi8hD17E=.bc6ed458-7081-4c3f-9348-f59358fa05a4@github.com>
References: <uWi4QxH31hL93771gkl_GgvP0m84IRSoR_1Yi8hD17E=.bc6ed458-7081-4c3f-9348-f59358fa05a4@github.com>
Message-ID: <eQ4OBFrF8JlDJ1h9awTDOc0kfCc37IlL5vdqtuaqls0=.8f00616d-08e1-4f28-a7a5-5095116d2595@github.com>

> Re-write the IndexOf code without the use of the pcmpestri instruction, only using AVX2 instructions.  This change accelerates String.IndexOf on average 1.3x for AVX2.  The benchmark numbers:
> 
> 
> Benchmark	                                               Score		Latest		
> StringIndexOf.advancedWithMediumSub   343.573		317.934		0.925375393x
> StringIndexOf.advancedWithShortSub1	  1039.081		1053.96		1.014319384x
> StringIndexOf.advancedWithShortSub2	      55.828		110.541		1.980027943x
> StringIndexOf.constantPattern	                9.361		11.906		1.271872663x
> StringIndexOf.searchCharLongSuccess	        4.216		4.218		1.000474383x
> StringIndexOf.searchCharMediumSuccess	3.133		3.216		1.02649218x
> StringIndexOf.searchCharShortSuccess	3.76		        3.761		1.000265957x
> StringIndexOf.success	                                9.186		9.713		1.057369911x
> StringIndexOf.successBig	                      14.341		46.343		3.231504079x
> StringIndexOfChar.latin1_AVX2_String	  6220.918		12154.52		1.953814533x
> StringIndexOfChar.latin1_AVX2_char	  5503.556		5540.044		1.006629895x
> StringIndexOfChar.latin1_SSE4_String	  6978.854		6818.689		0.977049957x
> StringIndexOfChar.latin1_SSE4_char	  5657.499		5474.624		0.967675646x
> StringIndexOfChar.latin1_Short_String	  7132.541		6863.359		0.962260014x
> StringIndexOfChar.latin1_Short_char	16013.389	      16162.437		1.009307711x
> StringIndexOfChar.latin1_mixed_String	  7386.123	      14771.622		1.999915517x
> StringIndexOfChar.latin1_mixed_char	  9901.671		9782.245		0.987938803

Scott Gibbons has updated the pull request incrementally with one additional commit since the last revision:

  Rearrange; add lambdas for clarity

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16753/files
  - new: https://git.openjdk.org/jdk/pull/16753/files/f52d281d..fb4da92a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16753&range=18
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16753&range=17-18

  Stats: 2561 lines in 1 file changed: 804 ins; 954 del; 803 mod
  Patch: https://git.openjdk.org/jdk/pull/16753.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16753/head:pull/16753

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

From alanb at openjdk.org  Sun May  5 05:31:00 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Sun, 5 May 2024 05:31:00 GMT
Subject: RFR: 8330005: RandomGeneratorFactory.getDefault() throws exception
 when the runtime image only has java.base module [v6]
In-Reply-To: <ZCknDWh6FaLWfXb9c9QFsnK9GrqdTXaHSVcG5jmZ6g8=.c1dd43f6-c571-46e8-880f-7f864fc56b62@github.com>
References: <FymnGzlEZUHwHgW6At_bqYIoF7wYsjD_vBhk60PrwFE=.1ef4072e-c3a4-4930-8d18-ba132fa90c56@github.com>
 <ZCknDWh6FaLWfXb9c9QFsnK9GrqdTXaHSVcG5jmZ6g8=.c1dd43f6-c571-46e8-880f-7f864fc56b62@github.com>
Message-ID: <U-VQakCK9sQ48FprsvaBHQ4qSEjgBSaNAQPIvHDFMfA=.24154813-b533-404b-b598-88302143fc41@github.com>

On Sat, 4 May 2024 18:29:25 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> Move all random generators mandated in package `java.util.random` and currently implemented in module `jdk.random` to module `java.base`, and remove module `jdk.random`.
>
> Raffaello Giulietti 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 seven additional commits since the last revision:
> 
>  - Merge branch 'master' into 8330005
>  - Restrict RandomGenerator service providers to those loadable by the platform class loader.
>  - Typo.
>  - Added @uses javadoc tag for j.u.r.RandomGenerator in java.base.
>  - Terminology changes.
>  - Renamed package jdk.random to jdk.internal.random.
>  - 8330005: RandomGeneratorFactory.getDefault() throws exception when the runtime image only has java.base module

src/java.base/share/classes/java/util/random/RandomGeneratorFactory.java line 147:

> 145:             FactoryMapHolder.class.getModule().addUses(RandomGenerator.class);
> 146:             return ServiceLoader
> 147:                 .load(RandomGenerator.class, ClassLoader.getPlatformClassLoader())

SecurityManager is still a supported execution mode so you'll need to get the platform class loader in a privileged block until the SM feature is removed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18932#discussion_r1590212532

From rgiulietti at openjdk.org  Sun May  5 12:08:59 2024
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Sun, 5 May 2024 12:08:59 GMT
Subject: RFR: 8330005: RandomGeneratorFactory.getDefault() throws exception
 when the runtime image only has java.base module [v6]
In-Reply-To: <U-VQakCK9sQ48FprsvaBHQ4qSEjgBSaNAQPIvHDFMfA=.24154813-b533-404b-b598-88302143fc41@github.com>
References: <FymnGzlEZUHwHgW6At_bqYIoF7wYsjD_vBhk60PrwFE=.1ef4072e-c3a4-4930-8d18-ba132fa90c56@github.com>
 <ZCknDWh6FaLWfXb9c9QFsnK9GrqdTXaHSVcG5jmZ6g8=.c1dd43f6-c571-46e8-880f-7f864fc56b62@github.com>
 <U-VQakCK9sQ48FprsvaBHQ4qSEjgBSaNAQPIvHDFMfA=.24154813-b533-404b-b598-88302143fc41@github.com>
Message-ID: <6yLPSUJjn8jCm3_TREmyS8QgPKdLlrgNmZ-2owFp7a4=.5d9bc537-4125-429d-a993-2d593774a089@github.com>

On Sun, 5 May 2024 05:28:07 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Raffaello Giulietti 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 seven additional commits since the last revision:
>> 
>>  - Merge branch 'master' into 8330005
>>  - Restrict RandomGenerator service providers to those loadable by the platform class loader.
>>  - Typo.
>>  - Added @uses javadoc tag for j.u.r.RandomGenerator in java.base.
>>  - Terminology changes.
>>  - Renamed package jdk.random to jdk.internal.random.
>>  - 8330005: RandomGeneratorFactory.getDefault() throws exception when the runtime image only has java.base module
>
> src/java.base/share/classes/java/util/random/RandomGeneratorFactory.java line 147:
> 
>> 145:             FactoryMapHolder.class.getModule().addUses(RandomGenerator.class);
>> 146:             return ServiceLoader
>> 147:                 .load(RandomGenerator.class, ClassLoader.getPlatformClassLoader())
> 
> SecurityManager is still a supported execution mode so you'll need to get the platform class loader in a privileged block until the SM feature is removed.

Yes, I considered the interactions with a security manager.

But here the call to `getPlatformClassLoader()` is done from a platform class, namely `FactoryMapHolder` itself. According to its documentation, the call succeeds in this case because the security manager is not even consulted.

When experimenting with the following code and the default manager, as with `-Djava.security.manager=default`, no exceptions are thrown, neither with the full JDK nor with the minimal image that just includes `java.base`. There's only a warning about future removal of `SecurityManager`, as expected from JEP 411.


import java.util.random.*;

public class Foo {
    public static void main(final String[] args) throws Exception {
        RandomGeneratorFactory.all().forEach(g -> System.out.println(g.name()));
        final RandomGeneratorFactory<RandomGenerator> rgf = RandomGeneratorFactory.getDefault();
        System.out.println("Got " + rgf);
    }
}


But if the call to `getPlatformClassLoader()` is done directly from an app loaded by the system class loader, then an exception is thrown when the default security manager is active.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18932#discussion_r1590295056

From alanb at openjdk.org  Sun May  5 13:52:52 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Sun, 5 May 2024 13:52:52 GMT
Subject: RFR: 8330005: RandomGeneratorFactory.getDefault() throws exception
 when the runtime image only has java.base module [v6]
In-Reply-To: <6yLPSUJjn8jCm3_TREmyS8QgPKdLlrgNmZ-2owFp7a4=.5d9bc537-4125-429d-a993-2d593774a089@github.com>
References: <FymnGzlEZUHwHgW6At_bqYIoF7wYsjD_vBhk60PrwFE=.1ef4072e-c3a4-4930-8d18-ba132fa90c56@github.com>
 <ZCknDWh6FaLWfXb9c9QFsnK9GrqdTXaHSVcG5jmZ6g8=.c1dd43f6-c571-46e8-880f-7f864fc56b62@github.com>
 <U-VQakCK9sQ48FprsvaBHQ4qSEjgBSaNAQPIvHDFMfA=.24154813-b533-404b-b598-88302143fc41@github.com>
 <6yLPSUJjn8jCm3_TREmyS8QgPKdLlrgNmZ-2owFp7a4=.5d9bc537-4125-429d-a993-2d593774a089@github.com>
Message-ID: <kKTqY4-0gl_IHmSdBEoYx028twUOAWuEUnlnQmE6BJI=.f4ea3a40-ece5-4477-8a7f-6164a0726fd8@github.com>

On Sun, 5 May 2024 12:05:48 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> src/java.base/share/classes/java/util/random/RandomGeneratorFactory.java line 147:
>> 
>>> 145:             FactoryMapHolder.class.getModule().addUses(RandomGenerator.class);
>>> 146:             return ServiceLoader
>>> 147:                 .load(RandomGenerator.class, ClassLoader.getPlatformClassLoader())
>> 
>> SecurityManager is still a supported execution mode so you'll need to get the platform class loader in a privileged block until the SM feature is removed.
>
> Yes, I considered the interactions with a security manager.
> 
> But here the call to `getPlatformClassLoader()` is done from a platform class, namely `FactoryMapHolder` itself. According to its documentation, the call succeeds in this case because the security manager is not even consulted.
> 
> When experimenting with the following code and the default manager, as with `-Djava.security.manager=default`, no exceptions are thrown, neither with the full JDK nor with the minimal image that just includes `java.base`. There's only a warning about future removal of `SecurityManager`, as expected from JEP 411.
> 
> 
> import java.util.random.*;
> 
> public class Foo {
>     public static void main(final String[] args) throws Exception {
>         RandomGeneratorFactory.all().forEach(g -> System.out.println(g.name()));
>         final RandomGeneratorFactory<RandomGenerator> rgf = RandomGeneratorFactory.getDefault();
>         System.out.println("Got " + rgf);
>     }
> }
> 
> 
> But if the call to `getPlatformClassLoader()` is done directly from an app loaded by the system class loader, then an exception is thrown when the default security manager is active.

Thanks, I'd forgotten the check in that method is caller sensitive.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18932#discussion_r1590318688

From duke at openjdk.org  Sun May  5 14:29:19 2024
From: duke at openjdk.org (Nizar Benalla)
Date: Sun, 5 May 2024 14:29:19 GMT
Subject: RFR: 8331051: Add an `@since` checker test for `java.base` module
 [v4]
In-Reply-To: <NRZmbFYvDwXPuizcmCilJx5Yb6HjZ-2fJa-YILxYUl8=.a79f79e4-77d5-4910-b3df-5e78bb7e402b@github.com>
References: <NRZmbFYvDwXPuizcmCilJx5Yb6HjZ-2fJa-YILxYUl8=.a79f79e4-77d5-4910-b3df-5e78bb7e402b@github.com>
Message-ID: <A2ISLF0Bw0nYML_hzPknq6AIZe-Xc47TJ8gW_W2RB_4=.6d23b21f-1a0d-41c0-8b8b-ac5bd2760ab0@github.com>

> This checker checks the values of the `@since` tag found in the documentation comment for an element against the release in which the element first appeared.
> 
> Real since value of an API element is computed as the oldest release in which the given API element was introduced. That is:
> - for modules, classes and interfaces, the release in which the element with the given qualified name was introduced
> - for constructors, the release in which the constructor with the given VM descriptor was introduced
> - for methods and fields, the release in which the given method or field with the given VM descriptor became a member of its enclosing class or interface, whether direct or inherited
> 
> Effective since value of an API element is computed as follows:
> - if the given element has a `@since` tag in its javadoc, it is used
> - in all other cases, return the effective since value of the enclosing element
> 
> The since checker verifies that for every API element, the real since value and the effective since value are the same, and reports an error if they are not.
> 
> Preview method are handled as per JEP 12, if `@PreviewFeature` is used consistently going forward then the checker doesn't need to be updated with every release. The checker has explicit knowledge of preview elements that came before `JDK 14` because they weren't marked in a machine understandable way and preview elements that came before `JDK 17` that didn't have `@PreviewFeature`.
> 
> Important note : We only check code written since `JDK 9` as the releases used to determine the expected value of `@since` tags are taken from the historical data built into `javac` which only goes back that far
> 
> The intial comment at the beginning of `SinceChecker.java` holds more information into the program.
> 
> I already have filed issues and fixed some wrong tags like in #18640, #18032, #18030, #18055, #18373, #18954, #18972.

Nizar Benalla has updated the pull request incrementally with one additional commit since the last revision:

  - Added some legacy modules that existed long before preview features (they were incubating)
  - Not checking elements enclosed withing a record
  - Only check if the file is readable using `Files.isReadable`
  - Dropped the use of `Files.exists` and `Files.isDirectory`
  - Use `--add-modules` option now to resolve certain modules

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18934/files
  - new: https://git.openjdk.org/jdk/pull/18934/files/5df2151e..3f226ef9

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

  Stats: 71 lines in 1 file changed: 32 ins; 8 del; 31 mod
  Patch: https://git.openjdk.org/jdk/pull/18934.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18934/head:pull/18934

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

From duke at openjdk.org  Sun May  5 14:29:19 2024
From: duke at openjdk.org (Nizar Benalla)
Date: Sun, 5 May 2024 14:29:19 GMT
Subject: RFR: 8331051: Add an `@since` checker test for `java.base` module
 [v4]
In-Reply-To: <M82KuHGrMxvqPWg068GBdy-b_Sp8mc5n5RwXkI57fkY=.43856903-9930-463c-9ebd-c8c4d2d36419@github.com>
References: <NRZmbFYvDwXPuizcmCilJx5Yb6HjZ-2fJa-YILxYUl8=.a79f79e4-77d5-4910-b3df-5e78bb7e402b@github.com>
 <M82KuHGrMxvqPWg068GBdy-b_Sp8mc5n5RwXkI57fkY=.43856903-9930-463c-9ebd-c8c4d2d36419@github.com>
Message-ID: <y0FeKSPeoZmNr9Rtb9afpyKQNZvEqfy5CTT_3lRjrMg=.c7419168-914a-4031-b214-a08ad13d3d55@github.com>

On Thu, 2 May 2024 13:49:43 GMT, Hannes Walln?fer <hannesw at openjdk.org> wrote:

>> Nizar Benalla has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   - Added some legacy modules that existed long before preview features (they were incubating)
>>   - Not checking elements enclosed withing a record
>>   - Only check if the file is readable using `Files.isReadable`
>>   - Dropped the use of `Files.exists` and `Files.isDirectory`
>>   - Use `--add-modules` option now to resolve certain modules
>
> test/jdk/tools/sincechecker/SinceChecker.java line 51:
> 
>> 49: 
>> 50: /*
>> 51: - This checker checks the values of the `@since` tag found in the documentation comment for an element against the release in which the element first appeared.
> 
> In addition to the long lines mentioned by Jon which make the comments hard to read, I find it strange that every sentence is formatted as a list item with a leading dash. I think it's ok when describing different parts/steps of the algorithm, but at least the first sentence in the comment should not be a list item IMO.

Fixed, thanks.

> test/jdk/tools/sincechecker/SinceChecker.java line 216:
> 
>> 214:             srcZip = testJdk.getParent().resolve("images").resolve("jdk").resolve("lib").resolve("src.zip");
>> 215:         }
>> 216:         if (!Files.exists(srcZip) && !Files.isDirectory(srcZip)) {
> 
> This condition looks wrong. If `exists` returns false, it also implies that `isDirectory` returns false. I think there's no need to check for a (not-)directory here.

Fixed in [3f226ef](https://github.com/openjdk/jdk/pull/18934/commits/3f226ef9134b71a1b63b6562b8381be909c30343), I now only check if the file is readable.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18934#discussion_r1590327624
PR Review Comment: https://git.openjdk.org/jdk/pull/18934#discussion_r1590327722

From duke at openjdk.org  Sun May  5 14:36:59 2024
From: duke at openjdk.org (Nizar Benalla)
Date: Sun, 5 May 2024 14:36:59 GMT
Subject: RFR: 8331051: Add an `@since` checker test for `java.base` module
 [v4]
In-Reply-To: <BLFQhjRnqOkf-bjf2ib2emZJhkTzAw7RW6RS15Uq4N4=.31e5b90c-0dcb-4f43-ae49-445bd572bbef@github.com>
References: <NRZmbFYvDwXPuizcmCilJx5Yb6HjZ-2fJa-YILxYUl8=.a79f79e4-77d5-4910-b3df-5e78bb7e402b@github.com>
 <BLFQhjRnqOkf-bjf2ib2emZJhkTzAw7RW6RS15Uq4N4=.31e5b90c-0dcb-4f43-ae49-445bd572bbef@github.com>
Message-ID: <ZWl5uV-GFSvI4qgAj5Vi3X1YnpSFcojD8NbJQLNXeuI=.f28f2ae6-6316-4c81-8c1c-1889045348d2@github.com>

On Thu, 2 May 2024 14:06:25 GMT, Hannes Walln?fer <hannesw at openjdk.org> wrote:

>> Nizar Benalla has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   - Added some legacy modules that existed long before preview features (they were incubating)
>>   - Not checking elements enclosed withing a record
>>   - Only check if the file is readable using `Files.isReadable`
>>   - Dropped the use of `Files.exists` and `Files.isDirectory`
>>   - Use `--add-modules` option now to resolve certain modules
>
> test/jdk/tools/sincechecker/SinceChecker.java line 106:
> 
>> 104:     public static void main(String[] args) throws Exception {
>> 105:         if (args.length == 0) {
>> 106:             throw new SkippedException("Test module not specified");
> 
> I don't think `SkippedException` is the right exception to throw here, since invoking the method with a missing argument is probably a configuration error that shouldn't be ignored. Maybe `IllegalArgumentException` or just `RuntimeException`?

Fixed it, now throwing `IllegalArgumentException`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18934#discussion_r1590329254

From duke at openjdk.org  Sun May  5 15:22:15 2024
From: duke at openjdk.org (Nizar Benalla)
Date: Sun, 5 May 2024 15:22:15 GMT
Subject: RFR: 8331051: Add an `@since` checker test for `java.base` module
 [v5]
In-Reply-To: <NRZmbFYvDwXPuizcmCilJx5Yb6HjZ-2fJa-YILxYUl8=.a79f79e4-77d5-4910-b3df-5e78bb7e402b@github.com>
References: <NRZmbFYvDwXPuizcmCilJx5Yb6HjZ-2fJa-YILxYUl8=.a79f79e4-77d5-4910-b3df-5e78bb7e402b@github.com>
Message-ID: <PlsvKjixjw77eZxhBvJzNJe-PUHhcgrJW20-4LMJdAA=.c743c945-d71a-4a5c-865d-e1b0da2476b3@github.com>

> This checker checks the values of the `@since` tag found in the documentation comment for an element against the release in which the element first appeared.
> 
> Real since value of an API element is computed as the oldest release in which the given API element was introduced. That is:
> - for modules, classes and interfaces, the release in which the element with the given qualified name was introduced
> - for constructors, the release in which the constructor with the given VM descriptor was introduced
> - for methods and fields, the release in which the given method or field with the given VM descriptor became a member of its enclosing class or interface, whether direct or inherited
> 
> Effective since value of an API element is computed as follows:
> - if the given element has a `@since` tag in its javadoc, it is used
> - in all other cases, return the effective since value of the enclosing element
> 
> The since checker verifies that for every API element, the real since value and the effective since value are the same, and reports an error if they are not.
> 
> Preview method are handled as per JEP 12, if `@PreviewFeature` is used consistently going forward then the checker doesn't need to be updated with every release. The checker has explicit knowledge of preview elements that came before `JDK 14` because they weren't marked in a machine understandable way and preview elements that came before `JDK 17` that didn't have `@PreviewFeature`.
> 
> Important note : We only check code written since `JDK 9` as the releases used to determine the expected value of `@since` tags are taken from the historical data built into `javac` which only goes back that far
> 
> The intial comment at the beginning of `SinceChecker.java` holds more information into the program.
> 
> I already have filed issues and fixed some wrong tags like in #18640, #18032, #18030, #18055, #18373, #18954, #18972.

Nizar Benalla has updated the pull request incrementally with one additional commit since the last revision:

  - Not checking elements enclosed within a record, I doubt a record class will change after being created
  - Added a null check as `toString` can return an exception

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18934/files
  - new: https://git.openjdk.org/jdk/pull/18934/files/3f226ef9..48c87814

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

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

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

From duke at openjdk.org  Sun May  5 21:00:53 2024
From: duke at openjdk.org (Axel Hauschulte)
Date: Sun, 5 May 2024 21:00:53 GMT
Subject: RFR: 8331485: Odd Results when Parsing Scientific Notation with
 Large Exponent [v2]
In-Reply-To: <RkWCGlAEl-DXGMCbPtB8d7YE3F1jo-nhUFBtTOVkw9A=.120e8d1d-c2b1-44d4-9f8a-085a70df254a@github.com>
References: <lTOZ4RbzZFMN0yLrQKGOcMihdTop24YbYJe2h36SodM=.0addc2ad-b0d1-4721-b860-a9395fa14977@github.com>
 <RkWCGlAEl-DXGMCbPtB8d7YE3F1jo-nhUFBtTOVkw9A=.120e8d1d-c2b1-44d4-9f8a-085a70df254a@github.com>
Message-ID: <v4d-Q8WcpPc9a9Ou3IIeat_SZo1NJNE-oM-j5_lqSEA=.67fd6e12-3f1e-413f-a04b-b02814794487@github.com>

On Fri, 3 May 2024 18:29:23 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please review this PR which corrects an edge case bug for java.text.DecimalFormat that causes incorrect parsing results for strings with very large exponent values.
>> 
>> When parsing values with large exponents, if the value of the exponent exceeds `Integer.MAX_VALUE`, the parsed value  is equal to 0. If the value of the exponent exceeds `Long.MAX_VALUE`, the parsed value is equal to the mantissa. Both results are confusing and incorrect.
>> 
>> For example,
>> 
>> 
>> NumberFormat fmt = NumberFormat.getInstance(Locale.US);
>> fmt.parse(".1E2147483648"); // returns 0.0
>> fmt.parse(".1E9223372036854775808"); // returns 0.1
>> // For comparison
>> Double.parseDouble(".1E2147483648"); // returns Infinity
>> Double.parseDouble(".1E9223372036854775808"); // returns Infinity
>> 
>> 
>> After this change, both parse calls return `Double.POSITIVE_INFINITY` now.
>
> Justin Lu has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - correct other test comment
>  - reflect review

Hello, I filed [JDK-8331485](https://bugs.openjdk.org/browse/JDK-8331485). Thank you for addressing this bug so quickly.

I have a thought/concern regarding the handling of exponents that exceed `Long.MAX_VALUE` in this PR:

> If the value of the exponent exceeds `Long.MAX_VALUE`, the parsed value is equal to the mantissa. Both results are confusing and incorrect.
> 
> For example,
> 
> ```
> NumberFormat fmt = NumberFormat.getInstance(Locale.US);
> fmt.parse(".1E2147483648"); // returns 0.0
> fmt.parse(".1E9223372036854775808"); // returns 0.1
> // For comparison
> Double.parseDouble(".1E2147483648"); // returns Infinity
> Double.parseDouble(".1E9223372036854775808"); // returns Infinity
> ```

The method [`parse(String, ParsePosition)`](https://docs.oracle.com/en/java/javase/22/docs/api/java.base/java/text/DecimalFormat.html#parse(java.lang.String,java.text.ParsePosition)) uses the [`ParsePosition`](https://docs.oracle.com/en/java/javase/22/docs/api/java.base/java/text/ParsePosition.html) object as an input and output parameter to determine at what position the parsing should start as well as to communicate up to which position the input string has been consumed during the parsing. (This can be very handy if you use different [`Format`](https://docs.oracle.com/en/java/javase/22/docs/api/java.base/java/text/Format.html)s to parse through a string.)

For example, if there is a method like this

static void parseNumber(String s) {
    NumberFormat numberFormat = NumberFormat.getInstance(Locale.US);
    ParsePosition parsePosition = new ParsePosition(0);
    Number parseResult = numberFormat.parse(s, parsePosition);
    System.out.println(STR."numberFormat.parse("{s}") -> {parseResult}; parsePosition: {parsePosition}");
}

`parseNumber("0.123E1XYZ")` will parse the provided string from the beginning to position 7, ignoring the letters at the end of the string. The resulting `Double` value is therefore 1.23 and `parsePosition.getIndex()` returns 7.

Having an exponent that exceeds `Long.MAX_VALUE`, for instance `parseNumber("0.123E9223372036854775808")`, the current implementation of `DecimalFormat` in JDK 22 does the following: Parse the provided string from the beginning to position 5, ignoring the exponent (because it is too long). The resulting `Double` is therefore 0.123 and `parsePosition.getIndex()` returns 5.

The solution implemented in this PR would produce a parsing result of `Double.POSITIVE_INFINITY`, however, `parsePosition.getIndex()` would still return 5. For me this would be confusing behaviour because `parsePosition.getIndex()` indicates that the input string has only been consumed up to index 5, however, the actual numeric parsing result indicates that the exponent was taken into account.

I think there are two intuitive, non-confusing ways to handle exponents that exceed `Long.MAX_VALUE`. Either go with the current behaviour of `DecimalFormat` for this kind of exponents or go with the way exponents are handled in this PR, but advance the parser position past the exponent even if it excceds `Long.MAX_VALUE`. 

The latter would mean that `parseNumber("0.123E9223372036854775807123")` would produce a parsing result of `Double.POSITIVE_INFINITY` and `parsePosition.getIndex()` would return 28. This would probably be the nicest, most intuitve solution.

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

PR Comment: https://git.openjdk.org/jdk/pull/19075#issuecomment-2094946378

From duke at openjdk.org  Sun May  5 23:33:02 2024
From: duke at openjdk.org (Nizar Benalla)
Date: Sun, 5 May 2024 23:33:02 GMT
Subject: RFR: 8330954: Fix remaining `@since` tags in `java.base`
Message-ID: <fBxLBbMa9El6L2aATjtKyrAjlFRIjh1J7vPx2CbNT5E=.b33e4450-c1dc-4f36-b59b-5d9acb2da2dc@github.com>

Please review this PR that aims to add all the remaining needed `@since` tags in `java.base`, and group them into a single fix.
This is related to #18934 and my work around the `@since` checker feature.
Explicit `@since` tags are needed for some overriding methods for the purpose of the checker.

I will only give the example with the `CompletableFuture` class but here is the before where the methods only appeared in "Methods declared in interface N"

<img width="1510" alt="Screenshot 2024-05-06 at 00 06 57" src="https://github.com/openjdk/jdk/assets/96922791/1749a355-133b-4a38-bffe-51ac415b2aac">



and after where the method has it's own javadoc, the main description is added and the `@since` tags are added as intended.

I don't have an account on `https://cr.openjdk.org/` but I could host the generated docs somewhere if that is needed.

<img width="1511" alt="Screenshot 2024-05-06 at 00 07 16" src="https://github.com/openjdk/jdk/assets/96922791/89b92288-9b5e-48ed-8fa1-9342ea43e043">

<img width="1505" alt="Screenshot 2024-05-06 at 00 08 06" src="https://github.com/openjdk/jdk/assets/96922791/9aef08ff-5030-4189-a996-582a7eef849b">

<img width="1050" alt="Screenshot 2024-05-06 at 00 09 03" src="https://github.com/openjdk/jdk/assets/96922791/fdd75a26-0396-4c5e-8f59-a3717b7d7ec8">


TIA

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

Commit messages:
 - remove couple extra lines
 - Pull request is now only about `@since` tags, might add an other commit
 - add one more `{inheritDoc}` to `CompletableFuture.state`
 - add `@throws` declarations to javadoc
 - add ``{@inheritDoc}`` to new javadoc comments
 - remove two extra spaces
 - add tags to elements from `java.base`

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

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

From liach at openjdk.org  Sun May  5 23:33:03 2024
From: liach at openjdk.org (Chen Liang)
Date: Sun, 5 May 2024 23:33:03 GMT
Subject: RFR: 8330954: Fix remaining `@since` tags in `java.base`
In-Reply-To: <fBxLBbMa9El6L2aATjtKyrAjlFRIjh1J7vPx2CbNT5E=.b33e4450-c1dc-4f36-b59b-5d9acb2da2dc@github.com>
References: <fBxLBbMa9El6L2aATjtKyrAjlFRIjh1J7vPx2CbNT5E=.b33e4450-c1dc-4f36-b59b-5d9acb2da2dc@github.com>
Message-ID: <LyigibtrSTgyNUKOHIn1W22nJdFo6mxVzWIot9BtYGQ=.22944a46-356e-467e-86b3-21a9566f35fb@github.com>

On Thu, 25 Apr 2024 14:29:27 GMT, Nizar Benalla <duke at openjdk.org> wrote:

> Please review this PR that aims to add all the remaining needed `@since` tags in `java.base`, and group them into a single fix.
> This is related to #18934 and my work around the `@since` checker feature.
> Explicit `@since` tags are needed for some overriding methods for the purpose of the checker.
> 
> I will only give the example with the `CompletableFuture` class but here is the before where the methods only appeared in "Methods declared in interface N"
> 
> <img width="1510" alt="Screenshot 2024-05-06 at 00 06 57" src="https://github.com/openjdk/jdk/assets/96922791/1749a355-133b-4a38-bffe-51ac415b2aac">
> 
> 
> 
> and after where the method has it's own javadoc, the main description is added and the `@since` tags are added as intended.
> 
> I don't have an account on `https://cr.openjdk.org/` but I could host the generated docs somewhere if that is needed.
> 
> <img width="1511" alt="Screenshot 2024-05-06 at 00 07 16" src="https://github.com/openjdk/jdk/assets/96922791/89b92288-9b5e-48ed-8fa1-9342ea43e043">
> 
> <img width="1505" alt="Screenshot 2024-05-06 at 00 08 06" src="https://github.com/openjdk/jdk/assets/96922791/9aef08ff-5030-4189-a996-582a7eef849b">
> 
> <img width="1050" alt="Screenshot 2024-05-06 at 00 09 03" src="https://github.com/openjdk/jdk/assets/96922791/fdd75a26-0396-4c5e-8f59-a3717b7d7ec8">
> 
> 
> TIA

Changes requested by liach (Author).

Marked as reviewed by liach (Author).

I think your changes mostly group in these categories:
1. New API methods provided in superclasses/superinterfaces, this class provides a more concrete implementation:
   Examples being `CompletableFuture`, `FileInputStream`, `DelayQueue`, `FutureTask`
   I don't think you should add since tags for these; without explicit javadoc, the methods inherit the superclass/superinterface docs, and appear in `Methods declared in class/interface Xxx` (supertype) section, which already have the correct since tags.
   There's one scenario where such addition may be meaningful, however: that's if the supertype's since version is newer than this class/interfaces's since version, so we might need to specify here.
   (On a side note, it would be great if we can mark the since version of an interface, notorious example being `ZipFile` retrofitted to implement `Closeable` in 1.7 and breaks compile target 1.6)
2. Remove unnecessary since tags for existing API methods with newer implementation
   Examples being `Reference`, `RsaPrivateKey`. These make sense.
3. API methods with different return types
   Examples being `ClassSignature`, `ClassDesc`. These make sense too, as older version may return different types. But problem here is should we count methods with only signature (but not descriptor) differences, like `ClassSignature::superinterfaceSignatures()`?

For case 1 I mentioned, the new since tags in `CompletableFuture`, `FileInputStream`, `DelayQueue`, `FutureTask` are not necessary: their docs are carried from the superclass/superinterfaces, and those superclass/superinterface methods already have the correct since tags.

Please consider this scenario where class A extends B, both from earlier versions, and there's `B::method` added in a new version X. Why are we adding a `@since` tag on the method `A::method` when it doesn't have its own doc and just refers to `B::method`, which already includes a `@since` tag?

For your convenience, I will reiterate with the javadoc output API specification instead of just the source code. These are most likely caused by bugs in your analyais tool:
1. `CompletableFuture::exceptionallyComposeAsync` `CompletableFuture::resultNow` etc. already have the correct `@since` tags inherited from superclass/superinterfaces javadocs. Notice if a method doesn't have javadoc, it carries the javadoc from its overridden method and it doesn't appear in this class's Method Summary section.
https://docs.oracle.com/en/java/javase/22/docs/api/java.base/java/util/concurrent/CompletableFuture.html#methods-inherited-from-class-java.util.concurrent.CompletionStage
Affected classes: `CompletableFuture`, `ForkJoinTask`, `FutureTask`, and `ChoiceFormat`.


2. `FileInputStream::readNBytes` is explicitly overridden in JDK 12 for a better implementation, but it is already a valid method since JDK 9 when `InputStream::readNBytes` was added. This `@since 12` does not make sense.
https://docs.oracle.com/en/java/javase/22/docs/api/java.base/java/io/FileInputStream.html#methods-inherited-from-class-java.io.InputStream
Affected classes: `FileInputStream`, `DelayQueue`.

All other changes look correct.

FYI you can generate the documentation with `make docs` and upload it to https://cr.openjdk.org and link it for review purposes. (You just need to include the changed classes and the stylesheet.css)

I don't want to reiterate again, but if a method is declared so:

/**
 * Class One.
 *
 * @since 42
 */
public class One {
    /**
     * Method.
     *
     * @since 48
     */
    public void method() {}
}

/**
 * Class Two.
 *
 * @since 42
 */
public class Two extends One {
    @Override
    public void method() {}
}


The generated docs for `Two` will list `method` only in "Method declared in class One" section instead of the "Method Summary" section, and the link in "Method declared in ..." section links to the method declaration in class One where there's a correct `@since` version.

What's wrong with you that you ask `Two::method` to have a redundant javadoc and since tag?

I'm sorry, you have always mentioned "match the javadoc rules" "javadoc doesn't look into supertype" "go against current behavior", but there is no problem with these `@since` tags in the current output documentation because those overriding methods without javadoc are treated as if they don't exist by javadoc tool.

> For overriding methods we don't look into the supertype

We indeed don't because we treat it as if it does not exist, and then the current docs are right. Please, just take a look at the javadoc output once and reach your own conclusion.

src/java.base/share/classes/java/lang/classfile/ClassSignature.java line 47:

> 45:      *
> 46:      * @since 23
> 47:      * */

Suggestion:

     */

src/java.base/share/classes/java/lang/constant/ClassDesc.java line 367:

> 365: 
> 366:     /**
> 367:      * @since 21

Suggestion:

     * {@inheritDoc}
     *
     * @since 21

src/java.base/share/classes/java/lang/constant/MethodHandleDesc.java line 209:

> 207: 
> 208:     /**
> 209:      * @since 21

Suggestion:

     * {@inheritDoc}
     *
     * @since 21

src/java.base/share/classes/java/lang/constant/MethodHandleDesc.java line 210:

> 208:     /**
> 209:      * @since 21
> 210:      * */

Suggestion:

     */

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

PR Review: https://git.openjdk.org/jdk/pull/18954#pullrequestreview-2023023198
PR Review: https://git.openjdk.org/jdk/pull/18954#pullrequestreview-2028193951
PR Comment: https://git.openjdk.org/jdk/pull/18954#issuecomment-2077725789
PR Comment: https://git.openjdk.org/jdk/pull/18954#issuecomment-2078313984
PR Comment: https://git.openjdk.org/jdk/pull/18954#issuecomment-2078545190
PR Comment: https://git.openjdk.org/jdk/pull/18954#issuecomment-2080002723
PR Comment: https://git.openjdk.org/jdk/pull/18954#issuecomment-2080529185
PR Review Comment: https://git.openjdk.org/jdk/pull/18954#discussion_r1579787419
PR Review Comment: https://git.openjdk.org/jdk/pull/18954#discussion_r1579821135
PR Review Comment: https://git.openjdk.org/jdk/pull/18954#discussion_r1579821029
PR Review Comment: https://git.openjdk.org/jdk/pull/18954#discussion_r1579820432

From duke at openjdk.org  Sun May  5 23:33:04 2024
From: duke at openjdk.org (Nizar Benalla)
Date: Sun, 5 May 2024 23:33:04 GMT
Subject: RFR: 8330954: Fix remaining `@since` tags in `java.base`
In-Reply-To: <LyigibtrSTgyNUKOHIn1W22nJdFo6mxVzWIot9BtYGQ=.22944a46-356e-467e-86b3-21a9566f35fb@github.com>
References: <fBxLBbMa9El6L2aATjtKyrAjlFRIjh1J7vPx2CbNT5E=.b33e4450-c1dc-4f36-b59b-5d9acb2da2dc@github.com>
 <LyigibtrSTgyNUKOHIn1W22nJdFo6mxVzWIot9BtYGQ=.22944a46-356e-467e-86b3-21a9566f35fb@github.com>
Message-ID: <0Uo0Dq2wbP5Yzd7tHOQI-13saOpOKCl9Spm6JnxvU04=.91e85721-41ee-40e1-8e32-4e86addf848f@github.com>

On Thu, 25 Apr 2024 16:43:50 GMT, Chen Liang <liach at openjdk.org> wrote:

> I think your changes mostly group in these categories:
> 
> 1. New API methods provided in superclasses/superinterfaces, this class provides a more concrete implementation:
>    Examples being `CompletableFuture`, `FileInputStream`, `DelayQueue`, `FutureTask`
>    I don't think you should add since tags for these; without explicit javadoc, the methods inherit the superclass/superinterface docs, and appear in `Methods declared in class/interface Xxx` (supertype) section, which already have the correct since tags.
>    There's one scenario where such addition may be meaningful, however: that's if the supertype's since version is newer than this class/interfaces's since version, so we might need to specify here.
>    (On a side note, it would be great if we can mark the since version of an interface, notorious example being `ZipFile` retrofitted to implement `Closeable` in 1.7 and breaks compile target 1.6)
> 2. Remove unnecessary since tags for existing API methods with newer implementation
>    Examples being `Reference`, `RsaPrivateKey`. These make sense.
> 3. API methods with different return types
>    Examples being `ClassSignature`, `ClassDesc`. These make sense too, as older version may return different types. But problem here is should we count methods with only signature (but not descriptor) differences, like `ClassSignature::superinterfaceSignatures()`?

@liach 
- I am only looking at code added in JDK 9-current and do not plan on checking old code for now (in case there are questions on why certain methods weren't affected)
- I want generify-ing methods to be fine, so I am leaving `ClassSignature::superinterfaceSignatures()`. It will be changed eventually once the class goes out of Preview

> src/java.base/share/classes/java/lang/classfile/ClassSignature.java line 47:
> 
>> 45:      *
>> 46:      * @since 23
>> 47:      * */
> 
> Suggestion:
> 
>      */

good catch - will reply to your other questions later

> src/java.base/share/classes/java/lang/constant/MethodHandleDesc.java line 209:
> 
>> 207: 
>> 208:     /**
>> 209:      * @since 21
> 
> Suggestion:
> 
>      * {@inheritDoc}
>      *
>      * @since 21

Will need to look more into what elements require `{@inheritDoc}`

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

PR Comment: https://git.openjdk.org/jdk/pull/18954#issuecomment-2077922679
PR Review Comment: https://git.openjdk.org/jdk/pull/18954#discussion_r1579841341
PR Review Comment: https://git.openjdk.org/jdk/pull/18954#discussion_r1579880986

From duke at openjdk.org  Sun May  5 23:33:04 2024
From: duke at openjdk.org (Nizar Benalla)
Date: Sun, 5 May 2024 23:33:04 GMT
Subject: RFR: 8330954: Fix remaining `@since` tags in `java.base`
In-Reply-To: <fBxLBbMa9El6L2aATjtKyrAjlFRIjh1J7vPx2CbNT5E=.b33e4450-c1dc-4f36-b59b-5d9acb2da2dc@github.com>
References: <fBxLBbMa9El6L2aATjtKyrAjlFRIjh1J7vPx2CbNT5E=.b33e4450-c1dc-4f36-b59b-5d9acb2da2dc@github.com>
Message-ID: <auTgon0IfSmbBUN8kms_npjZIkKIvsq0QYSlVb9rTXE=.9505b22d-e0ea-41a2-8422-f5f8b76c735e@github.com>

On Thu, 25 Apr 2024 14:29:27 GMT, Nizar Benalla <duke at openjdk.org> wrote:

> Please review this PR that aims to add all the remaining needed `@since` tags in `java.base`, and group them into a single fix.
> This is related to #18934 and my work around the `@since` checker feature.
> Explicit `@since` tags are needed for some overriding methods for the purpose of the checker.
> 
> I will only give the example with the `CompletableFuture` class but here is the before where the methods only appeared in "Methods declared in interface N"
> 
> <img width="1510" alt="Screenshot 2024-05-06 at 00 06 57" src="https://github.com/openjdk/jdk/assets/96922791/1749a355-133b-4a38-bffe-51ac415b2aac">
> 
> 
> 
> and after where the method has it's own javadoc, the main description is added and the `@since` tags are added as intended.
> 
> I don't have an account on `https://cr.openjdk.org/` but I could host the generated docs somewhere if that is needed.
> 
> <img width="1511" alt="Screenshot 2024-05-06 at 00 07 16" src="https://github.com/openjdk/jdk/assets/96922791/89b92288-9b5e-48ed-8fa1-9342ea43e043">
> 
> <img width="1505" alt="Screenshot 2024-05-06 at 00 08 06" src="https://github.com/openjdk/jdk/assets/96922791/9aef08ff-5030-4189-a996-582a7eef849b">
> 
> <img width="1050" alt="Screenshot 2024-05-06 at 00 09 03" src="https://github.com/openjdk/jdk/assets/96922791/fdd75a26-0396-4c5e-8f59-a3717b7d7ec8">
> 
> 
> TIA

Recent [offline] discussions have showed that dealing with `@since` in overriding methods is complicated.
The solution is to add an explicit `@since` to **some** overriding methods that do not have any javadoc as the only `@since` we can infer is that of the enclosing class.
The positive part is that these cases are **very rare**, and would help the checker have precise rules and match those of javadoc.

- We will effectively enforce javadoc comment for some method overrides with the checker (we want to match the rules for `javadoc` tool which doesn't have any special handing for `@since` tags in inherited methods), and for that we need to fix some of the existing tags. But turns out it's not too many as we are only checking JDK 9-current.
 
- Regarding `FileInputStream::readNBytes`, the method `int java.io.FileInputStream.readNBytes(byte[],int,int)` was available since `JDK 9`. 
The one I added an `@since 11` is a different method `byte[] java.io.FileInputStream.readNBytes(int)` with different return type and parameters.
 [Link to JDK 9 docs with the method](https://docs.oracle.com/javase%2F9%2Fdocs%2Fapi%2F%2F/java/io/InputStream.html#readNBytes-byte:A-int-int-)

When I said "For overriding methods we don't look into the supertype" I meant my checker tool doesn't do that.
> It seems you have some trouble understanding that overriding methods without explicit documentation are ignored by javadoc

This is still a **Draft** PR, I meant to add the `{@inheritDoc}` or other needed content to the javadoc and cleanup before opening. Should fix the issue you have with this change.

Others can join the discussion if they want, I'll let them know on monday but you might just get the same answer. For now the decision is that the every time an overload like the ones in this Draft PR is added, we would need to add explicit javadoc comment as we can't infer the `@since` from the overriden method.

I will run `make docs-jdk-api` before and after making changes, and compare the directories before opening. Might include the info in the PR body.

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

PR Comment: https://git.openjdk.org/jdk/pull/18954#issuecomment-2078409463
PR Comment: https://git.openjdk.org/jdk/pull/18954#issuecomment-2079003565
PR Comment: https://git.openjdk.org/jdk/pull/18954#issuecomment-2080962799
PR Comment: https://git.openjdk.org/jdk/pull/18954#issuecomment-2084988616

From liach at openjdk.org  Sun May  5 23:33:04 2024
From: liach at openjdk.org (Chen Liang)
Date: Sun, 5 May 2024 23:33:04 GMT
Subject: RFR: 8330954: Fix remaining `@since` tags in `java.base`
In-Reply-To: <auTgon0IfSmbBUN8kms_npjZIkKIvsq0QYSlVb9rTXE=.9505b22d-e0ea-41a2-8422-f5f8b76c735e@github.com>
References: <fBxLBbMa9El6L2aATjtKyrAjlFRIjh1J7vPx2CbNT5E=.b33e4450-c1dc-4f36-b59b-5d9acb2da2dc@github.com>
 <auTgon0IfSmbBUN8kms_npjZIkKIvsq0QYSlVb9rTXE=.9505b22d-e0ea-41a2-8422-f5f8b76c735e@github.com>
Message-ID: <aFxWfqFDJEZqUgQgx6pIdOKXLcVHUa6mX8RJB7CuRHM=.6dc329a0-947f-4ce2-972b-0501f19f9f1a@github.com>

On Fri, 26 Apr 2024 09:30:23 GMT, Nizar Benalla <duke at openjdk.org> wrote:

> We will effectively enforce javadoc comment for some method overrides with the checker

Those overriding methods don't even appear on the javadoc output. If you go to search for `CompletableFuture.resultNow` on https://docs.oracle.com/en/java/javase/22/docs/api/ you will find nothing. Why are we fixing "broken since tags" that don't even exist in the first place?

Also have you looked at the output documentation? Without the `@inheritDoc` tags the content will only have a since tag, which is definitely wrong.

> Recent [offline] discussions have showed that dealing with `@since` in overriding methods is complicated.
> The solution is to add an explicit `@since` to some overriding methods that do not have any javadoc as the only `@since` we can infer is that of the enclosing class.

If possible, I wish the others who joined the offline discussion can take part here. It seems you have some trouble understanding that overriding methods without explicit documentation are ignored by javadoc, and this ignorance makes the `@since` tags correct...

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

PR Comment: https://git.openjdk.org/jdk/pull/18954#issuecomment-2079550602
PR Comment: https://git.openjdk.org/jdk/pull/18954#issuecomment-2080532787

From duke at openjdk.org  Sun May  5 23:33:05 2024
From: duke at openjdk.org (Nizar Benalla)
Date: Sun, 5 May 2024 23:33:05 GMT
Subject: RFR: 8330954: Fix remaining `@since` tags in `java.base`
In-Reply-To: <aFxWfqFDJEZqUgQgx6pIdOKXLcVHUa6mX8RJB7CuRHM=.6dc329a0-947f-4ce2-972b-0501f19f9f1a@github.com>
References: <fBxLBbMa9El6L2aATjtKyrAjlFRIjh1J7vPx2CbNT5E=.b33e4450-c1dc-4f36-b59b-5d9acb2da2dc@github.com>
 <auTgon0IfSmbBUN8kms_npjZIkKIvsq0QYSlVb9rTXE=.9505b22d-e0ea-41a2-8422-f5f8b76c735e@github.com>
 <aFxWfqFDJEZqUgQgx6pIdOKXLcVHUa6mX8RJB7CuRHM=.6dc329a0-947f-4ce2-972b-0501f19f9f1a@github.com>
Message-ID: <lk2_OVO6SryPFePv8RGOugFlBL1UqbET9RzorSj9WJc=.ad6d7c19-870f-472f-b9b6-ab7e9101a1fa@github.com>

On Fri, 26 Apr 2024 14:52:08 GMT, Chen Liang <liach at openjdk.org> wrote:

> > We will effectively enforce javadoc comment for some method overrides with the checker
> 
> Those overriding methods don't even appear on the javadoc output. If you go to search for `CompletableFuture.resultNow` on https://docs.oracle.com/en/java/javase/22/docs/api/ you will find nothing. Why are we fixing "broken since tags" that don't even exist in the first place?
> 
> Also have you looked at the output documentation? Without the `@inheritDoc` tags the content will only have a since tag, which is definitely wrong.

For overriding methods we don't look into the supertype because that's what `javadoc` (the tool) is doing, `javadoc` doesn't look into the supertype and has no special handling or support for `@since` tags in inherited methods.
If `javadoc` changes how it deals with method overriding in the future we will match it's behavior and look into the supertype for overriding methods.
What is important is that we have to match the rules used in `javadoc`.
You can't have both, either you add explicit javadoc comments to these methods or use rules that go against the current behavior or `javadoc`

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

PR Comment: https://git.openjdk.org/jdk/pull/18954#issuecomment-2080445939

From prappo at openjdk.org  Sun May  5 23:33:05 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Sun, 5 May 2024 23:33:05 GMT
Subject: RFR: 8330954: Fix remaining `@since` tags in `java.base`
In-Reply-To: <lk2_OVO6SryPFePv8RGOugFlBL1UqbET9RzorSj9WJc=.ad6d7c19-870f-472f-b9b6-ab7e9101a1fa@github.com>
References: <fBxLBbMa9El6L2aATjtKyrAjlFRIjh1J7vPx2CbNT5E=.b33e4450-c1dc-4f36-b59b-5d9acb2da2dc@github.com>
 <auTgon0IfSmbBUN8kms_npjZIkKIvsq0QYSlVb9rTXE=.9505b22d-e0ea-41a2-8422-f5f8b76c735e@github.com>
 <aFxWfqFDJEZqUgQgx6pIdOKXLcVHUa6mX8RJB7CuRHM=.6dc329a0-947f-4ce2-972b-0501f19f9f1a@github.com>
 <lk2_OVO6SryPFePv8RGOugFlBL1UqbET9RzorSj9WJc=.ad6d7c19-870f-472f-b9b6-ab7e9101a1fa@github.com>
Message-ID: <uOO5Kl7Qx7-y_JAMd6q_KvhFZ4SyB0JAxvm8Vyxt-30=.8ec2bfea-acae-414a-816a-15357bfb0afd@github.com>

On Sat, 27 Apr 2024 10:33:42 GMT, Nizar Benalla <duke at openjdk.org> wrote:

> Also have you looked at the output documentation? Without the `@inheritDoc` tags the content will only have a since tag, which is definitely wrong.

This is not how I remember it. Unless written around, `{@inheritDoc}` in a main description is redundant. Let me clarify what I mean. Suppose we have a method:

    /** Foos. */
    foo()

and a couple of other methods that override that method:

    @Override
    foo()

    /**
     */
    @Override
    foo()

    /**
     * {@inheritDoc}
     */
    @Override
    foo()

Now, as far as the main description goes, the above three are equivalent, and the main description is inherited. While the third variant is arguably the most readable, its `{@inheritDoc}` is unnecessary. Explicit `{@inheritDoc}` is only necessary if we want to "write around" the inherited part. For example:

    /**
     * Foos with extra steps.
     * 
     * {@inheritDoc}
     * 
     * Also bars if baz is true.
     */
    @Override
    foo()

In this case, the generated documentation would be as follows:

    Foos with extra steps.
    Foos.
    Also bars if baz is true.

`@since` is a block tag. Block tags do not belong to the main description. So, if the goal is to only add a block tag, one does not need to implicitly `{@inheritDoc}` the main description. Does it make sense, Chen?

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

PR Comment: https://git.openjdk.org/jdk/pull/18954#issuecomment-2083562083

From liach at openjdk.org  Sun May  5 23:33:05 2024
From: liach at openjdk.org (Chen Liang)
Date: Sun, 5 May 2024 23:33:05 GMT
Subject: RFR: 8330954: Fix remaining `@since` tags in `java.base`
In-Reply-To: <uOO5Kl7Qx7-y_JAMd6q_KvhFZ4SyB0JAxvm8Vyxt-30=.8ec2bfea-acae-414a-816a-15357bfb0afd@github.com>
References: <fBxLBbMa9El6L2aATjtKyrAjlFRIjh1J7vPx2CbNT5E=.b33e4450-c1dc-4f36-b59b-5d9acb2da2dc@github.com>
 <auTgon0IfSmbBUN8kms_npjZIkKIvsq0QYSlVb9rTXE=.9505b22d-e0ea-41a2-8422-f5f8b76c735e@github.com>
 <aFxWfqFDJEZqUgQgx6pIdOKXLcVHUa6mX8RJB7CuRHM=.6dc329a0-947f-4ce2-972b-0501f19f9f1a@github.com>
 <lk2_OVO6SryPFePv8RGOugFlBL1UqbET9RzorSj9WJc=.ad6d7c19-870f-472f-b9b6-ab7e9101a1fa@github.com>
 <uOO5Kl7Qx7-y_JAMd6q_KvhFZ4SyB0JAxvm8Vyxt-30=.8ec2bfea-acae-414a-816a-15357bfb0afd@github.com>
Message-ID: <l6Wok4BqpJ_Ita3liKiMsPJALbXhW6ZsN8A6lU8Ps98=.0d1bcc2d-a6fa-4bf8-b127-2f16a4c4ef12@github.com>

On Mon, 29 Apr 2024 20:02:32 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>>> > We will effectively enforce javadoc comment for some method overrides with the checker
>>> 
>>> Those overriding methods don't even appear on the javadoc output. If you go to search for `CompletableFuture.resultNow` on https://docs.oracle.com/en/java/javase/22/docs/api/ you will find nothing. Why are we fixing "broken since tags" that don't even exist in the first place?
>>> 
>>> Also have you looked at the output documentation? Without the `@inheritDoc` tags the content will only have a since tag, which is definitely wrong.
>> 
>> For overriding methods we don't look into the supertype because that's what `javadoc` (the tool) is doing, `javadoc` doesn't look into the supertype and has no special handling or support for `@since` tags in inherited methods.
>> If `javadoc` changes how it deals with method overriding in the future we will match it's behavior and look into the supertype for overriding methods.
>> What is important is that we have to match the rules used in `javadoc`.
>> You can't have both, either you add explicit javadoc comments to these methods or use rules that go against the current behavior or `javadoc`
>
>> Also have you looked at the output documentation? Without the `@inheritDoc` tags the content will only have a since tag, which is definitely wrong.
> 
> This is not how I remember it. Unless written around, `{@inheritDoc}` in a main description is redundant. Let me clarify what I mean. Suppose we have a method:
> 
>     /** Foos. */
>     foo()
> 
> and a couple of other methods that override that method:
> 
>     @Override
>     foo()
> 
>     /**
>      */
>     @Override
>     foo()
> 
>     /**
>      * {@inheritDoc}
>      */
>     @Override
>     foo()
> 
> Now, as far as the main description goes, the above three are equivalent, and the main description is inherited. While the third variant is arguably the most readable, its `{@inheritDoc}` is unnecessary. Explicit `{@inheritDoc}` is only necessary if we want to "write around" the inherited part. For example:
> 
>     /**
>      * Foos with extra steps.
>      * 
>      * {@inheritDoc}
>      * 
>      * Also bars if baz is true.
>      */
>     @Override
>     foo()
> 
> In this case, the generated documentation would be as follows:
> 
>     Foos with extra steps.
>     Foos.
>     Also bars if baz is true.
> 
> `@since` is a block tag. Block tags do not belong to the main description. So, if the goal is to only add a block tag, one does not need to implicitly `{@inheritDoc}` the main description. Does it make sense, Chen?

Thanks for the explanation @pavelrappo. Also I recall inheritDoc has weird interactions with block tags like user-defined `@apiNote` in the JDK, would be nice if you can share more about these (also about the behaviors of inheriting `@throws` etc.

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

PR Comment: https://git.openjdk.org/jdk/pull/18954#issuecomment-2083822988

From prappo at openjdk.org  Sun May  5 23:33:05 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Sun, 5 May 2024 23:33:05 GMT
Subject: RFR: 8330954: Fix remaining `@since` tags in `java.base`
In-Reply-To: <l6Wok4BqpJ_Ita3liKiMsPJALbXhW6ZsN8A6lU8Ps98=.0d1bcc2d-a6fa-4bf8-b127-2f16a4c4ef12@github.com>
References: <fBxLBbMa9El6L2aATjtKyrAjlFRIjh1J7vPx2CbNT5E=.b33e4450-c1dc-4f36-b59b-5d9acb2da2dc@github.com>
 <auTgon0IfSmbBUN8kms_npjZIkKIvsq0QYSlVb9rTXE=.9505b22d-e0ea-41a2-8422-f5f8b76c735e@github.com>
 <aFxWfqFDJEZqUgQgx6pIdOKXLcVHUa6mX8RJB7CuRHM=.6dc329a0-947f-4ce2-972b-0501f19f9f1a@github.com>
 <lk2_OVO6SryPFePv8RGOugFlBL1UqbET9RzorSj9WJc=.ad6d7c19-870f-472f-b9b6-ab7e9101a1fa@github.com>
 <uOO5Kl7Qx7-y_JAMd6q_KvhFZ4SyB0JAxvm8Vyxt-30=.8ec2bfea-acae-414a-816a-15357bfb0afd@github.com>
 <l6Wok4BqpJ_Ita3liKiMsPJALbXhW6ZsN8A6lU8Ps98=.0d1bcc2d-a6fa-4bf8-b127-2f16a4c4ef12@github.com>
Message-ID: <kWAKH7gnEcRqL4kmVNm5h7XAWHTabyKq6bhiwvOFNHc=.61e18799-7f7e-4b1e-8ddb-2477889aa3fd@github.com>

On Mon, 29 Apr 2024 22:54:47 GMT, Chen Liang <liach at openjdk.org> wrote:

> would be nice if you can share more about these (also about the behaviors of inheriting `@throws` etc.

I hope this document explains it well; if it doesn't, we should fix it: https://docs.oracle.com/en/java/javase/22/docs/specs/javadoc/doc-comment-spec.html

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

PR Comment: https://git.openjdk.org/jdk/pull/18954#issuecomment-2084931915

From prappo at openjdk.org  Sun May  5 23:33:05 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Sun, 5 May 2024 23:33:05 GMT
Subject: RFR: 8330954: Fix remaining `@since` tags in `java.base`
In-Reply-To: <fBxLBbMa9El6L2aATjtKyrAjlFRIjh1J7vPx2CbNT5E=.b33e4450-c1dc-4f36-b59b-5d9acb2da2dc@github.com>
References: <fBxLBbMa9El6L2aATjtKyrAjlFRIjh1J7vPx2CbNT5E=.b33e4450-c1dc-4f36-b59b-5d9acb2da2dc@github.com>
Message-ID: <vRA01DEhQJrMhNKHObCQcbfK3txrr8ntdunTQrq7Zgc=.9277773b-247e-4ab7-be05-f31f41e82fb1@github.com>

On Thu, 25 Apr 2024 14:29:27 GMT, Nizar Benalla <duke at openjdk.org> wrote:

> Please review this PR that aims to add all the remaining needed `@since` tags in `java.base`, and group them into a single fix.
> This is related to #18934 and my work around the `@since` checker feature.
> Explicit `@since` tags are needed for some overriding methods for the purpose of the checker.
> 
> I will only give the example with the `CompletableFuture` class but here is the before where the methods only appeared in "Methods declared in interface N"
> 
> <img width="1510" alt="Screenshot 2024-05-06 at 00 06 57" src="https://github.com/openjdk/jdk/assets/96922791/1749a355-133b-4a38-bffe-51ac415b2aac">
> 
> 
> 
> and after where the method has it's own javadoc, the main description is added and the `@since` tags are added as intended.
> 
> I don't have an account on `https://cr.openjdk.org/` but I could host the generated docs somewhere if that is needed.
> 
> <img width="1511" alt="Screenshot 2024-05-06 at 00 07 16" src="https://github.com/openjdk/jdk/assets/96922791/89b92288-9b5e-48ed-8fa1-9342ea43e043">
> 
> <img width="1505" alt="Screenshot 2024-05-06 at 00 08 06" src="https://github.com/openjdk/jdk/assets/96922791/9aef08ff-5030-4189-a996-582a7eef849b">
> 
> <img width="1050" alt="Screenshot 2024-05-06 at 00 09 03" src="https://github.com/openjdk/jdk/assets/96922791/fdd75a26-0396-4c5e-8f59-a3717b7d7ec8">
> 
> 
> TIA

src/java.base/share/classes/java/io/FileInputStream.java line 345:

> 343:      * @throws    IllegalArgumentException {@inheritDoc}
> 344:      * @throws    IOException {@inheritDoc}
> 345:      * @throws    OutOfMemoryError {@inheritDoc}

Re: inheriting _unchecked_ exception documentation here and elsewhere in this PR

This PR's title suggests that the PR has nothing to do with exception documentation. If you feel that it should be addressed, please file a separate bug and move these changes there.

FWIW, I agree that `@throws ... {@inheritDoc}` for such exceptions are at least worth being considered. It's a common misconception that all exception documentation is inherited automatically.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18954#discussion_r1583347044

From liach at openjdk.org  Sun May  5 23:33:05 2024
From: liach at openjdk.org (Chen Liang)
Date: Sun, 5 May 2024 23:33:05 GMT
Subject: RFR: 8330954: Fix remaining `@since` tags in `java.base`
In-Reply-To: <vRA01DEhQJrMhNKHObCQcbfK3txrr8ntdunTQrq7Zgc=.9277773b-247e-4ab7-be05-f31f41e82fb1@github.com>
References: <fBxLBbMa9El6L2aATjtKyrAjlFRIjh1J7vPx2CbNT5E=.b33e4450-c1dc-4f36-b59b-5d9acb2da2dc@github.com>
 <vRA01DEhQJrMhNKHObCQcbfK3txrr8ntdunTQrq7Zgc=.9277773b-247e-4ab7-be05-f31f41e82fb1@github.com>
Message-ID: <g7DiPTbqUrIbd5BzlYe2PLRoPB7x9op5fv4nG7RDMiQ=.032eb20f-2766-493a-923c-7890d37d1a66@github.com>

On Mon, 29 Apr 2024 16:07:14 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Please review this PR that aims to add all the remaining needed `@since` tags in `java.base`, and group them into a single fix.
>> This is related to #18934 and my work around the `@since` checker feature.
>> Explicit `@since` tags are needed for some overriding methods for the purpose of the checker.
>> 
>> I will only give the example with the `CompletableFuture` class but here is the before where the methods only appeared in "Methods declared in interface N"
>> 
>> <img width="1510" alt="Screenshot 2024-05-06 at 00 06 57" src="https://github.com/openjdk/jdk/assets/96922791/1749a355-133b-4a38-bffe-51ac415b2aac">
>> 
>> 
>> 
>> and after where the method has it's own javadoc, the main description is added and the `@since` tags are added as intended.
>> 
>> I don't have an account on `https://cr.openjdk.org/` but I could host the generated docs somewhere if that is needed.
>> 
>> <img width="1511" alt="Screenshot 2024-05-06 at 00 07 16" src="https://github.com/openjdk/jdk/assets/96922791/89b92288-9b5e-48ed-8fa1-9342ea43e043">
>> 
>> <img width="1505" alt="Screenshot 2024-05-06 at 00 08 06" src="https://github.com/openjdk/jdk/assets/96922791/9aef08ff-5030-4189-a996-582a7eef849b">
>> 
>> <img width="1050" alt="Screenshot 2024-05-06 at 00 09 03" src="https://github.com/openjdk/jdk/assets/96922791/fdd75a26-0396-4c5e-8f59-a3717b7d7ec8">
>> 
>> 
>> TIA
>
> src/java.base/share/classes/java/io/FileInputStream.java line 345:
> 
>> 343:      * @throws    IllegalArgumentException {@inheritDoc}
>> 344:      * @throws    IOException {@inheritDoc}
>> 345:      * @throws    OutOfMemoryError {@inheritDoc}
> 
> Re: inheriting _unchecked_ exception documentation here and elsewhere in this PR
> 
> This PR's title suggests that the PR has nothing to do with exception documentation. If you feel that it should be addressed, please file a separate bug and move these changes there.
> 
> FWIW, I agree that `@throws ... {@inheritDoc}` for such exceptions are at least worth being considered. It's a common misconception that all exception documentation is inherited automatically.

This is because the tool from #18934 has no easy way to fetch the doc comment from a superclass/superinterface overridden method when this class only has a plain override. Javadoc handles this in complex logic in `VisibleMemberTable`; it's hard for other clients to try to emulate the behavior of doc finding, and the tool just incorrectly assumes such methods (what I have been talking about before) are reusing `@since` from the class docs.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18954#discussion_r1583449647

From duke at openjdk.org  Sun May  5 23:33:05 2024
From: duke at openjdk.org (Nizar Benalla)
Date: Sun, 5 May 2024 23:33:05 GMT
Subject: RFR: 8330954: Fix remaining `@since` tags in `java.base`
In-Reply-To: <g7DiPTbqUrIbd5BzlYe2PLRoPB7x9op5fv4nG7RDMiQ=.032eb20f-2766-493a-923c-7890d37d1a66@github.com>
References: <fBxLBbMa9El6L2aATjtKyrAjlFRIjh1J7vPx2CbNT5E=.b33e4450-c1dc-4f36-b59b-5d9acb2da2dc@github.com>
 <vRA01DEhQJrMhNKHObCQcbfK3txrr8ntdunTQrq7Zgc=.9277773b-247e-4ab7-be05-f31f41e82fb1@github.com>
 <g7DiPTbqUrIbd5BzlYe2PLRoPB7x9op5fv4nG7RDMiQ=.032eb20f-2766-493a-923c-7890d37d1a66@github.com>
Message-ID: <TB4RQcdNCyEO6GMRLku-z5b96CBwVrafCYy4ixs0ph4=.ede28460-3079-4367-a065-ce5ef959500e@github.com>

On Mon, 29 Apr 2024 17:26:53 GMT, Chen Liang <liach at openjdk.org> wrote:

>> src/java.base/share/classes/java/io/FileInputStream.java line 345:
>> 
>>> 343:      * @throws    IllegalArgumentException {@inheritDoc}
>>> 344:      * @throws    IOException {@inheritDoc}
>>> 345:      * @throws    OutOfMemoryError {@inheritDoc}
>> 
>> Re: inheriting _unchecked_ exception documentation here and elsewhere in this PR
>> 
>> This PR's title suggests that the PR has nothing to do with exception documentation. If you feel that it should be addressed, please file a separate bug and move these changes there.
>> 
>> FWIW, I agree that `@throws ... {@inheritDoc}` for such exceptions are at least worth being considered. It's a common misconception that all exception documentation is inherited automatically.
>
> This is because the tool from #18934 has no easy way to fetch the doc comment from a superclass/superinterface overridden method when this class only has a plain override. Javadoc handles this in complex logic in `VisibleMemberTable`; it's hard for other clients to try to emulate the behavior of doc finding, and the tool just incorrectly assumes such methods (what I have been talking about before) are reusing `@since` from the class docs.

Pavel, can I simply change the PR/issue title to be more descriptive? 
As I want to include the the inherit doc because of the unchecked exceptions, rather than clean this up in a different PR

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18954#discussion_r1583479753

From prappo at openjdk.org  Sun May  5 23:33:05 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Sun, 5 May 2024 23:33:05 GMT
Subject: RFR: 8330954: Fix remaining `@since` tags in `java.base`
In-Reply-To: <TB4RQcdNCyEO6GMRLku-z5b96CBwVrafCYy4ixs0ph4=.ede28460-3079-4367-a065-ce5ef959500e@github.com>
References: <fBxLBbMa9El6L2aATjtKyrAjlFRIjh1J7vPx2CbNT5E=.b33e4450-c1dc-4f36-b59b-5d9acb2da2dc@github.com>
 <vRA01DEhQJrMhNKHObCQcbfK3txrr8ntdunTQrq7Zgc=.9277773b-247e-4ab7-be05-f31f41e82fb1@github.com>
 <g7DiPTbqUrIbd5BzlYe2PLRoPB7x9op5fv4nG7RDMiQ=.032eb20f-2766-493a-923c-7890d37d1a66@github.com>
 <TB4RQcdNCyEO6GMRLku-z5b96CBwVrafCYy4ixs0ph4=.ede28460-3079-4367-a065-ce5ef959500e@github.com>
Message-ID: <lB0Dn_BunmYuLvChZrBJwTixaGygR-KjbH9ZSXrdCtg=.839003a6-66f1-48ad-abd9-c11bee3092f7@github.com>

On Mon, 29 Apr 2024 17:46:24 GMT, Nizar Benalla <duke at openjdk.org> wrote:

> Pavel, can I simply change the PR/issue title to be more descriptive? As I want to include the the inherit doc because of the unchecked exceptions, rather than clean this up in a different PR

I suggest dropping all the changes that are irrelevant to `@since` from this PR, unless you have PRs with similar mixed changes integrated. As far as I know, `@since` is not a normative part of documentation, whereas `@throws` is. So the latter is a bigger change and would require more scrutiny and more area experts during review.

In the future, we might want to have yet another aid/tool: a "`@throws` checker" that finds all overriding methods that do not declare some of the unchecked exceptions that the methods they override do.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18954#discussion_r1583618873

From liach at openjdk.org  Mon May  6 00:24:55 2024
From: liach at openjdk.org (Chen Liang)
Date: Mon, 6 May 2024 00:24:55 GMT
Subject: RFR: 8330954: Fix remaining `@since` tags in `java.base`
In-Reply-To: <fBxLBbMa9El6L2aATjtKyrAjlFRIjh1J7vPx2CbNT5E=.b33e4450-c1dc-4f36-b59b-5d9acb2da2dc@github.com>
References: <fBxLBbMa9El6L2aATjtKyrAjlFRIjh1J7vPx2CbNT5E=.b33e4450-c1dc-4f36-b59b-5d9acb2da2dc@github.com>
Message-ID: <7OoQkflbBtbnzsh4uSZXeyyNdJNWubP3uIt7tSUNDfY=.8fe81347-2182-47ee-997d-ca25559e84da@github.com>

On Thu, 25 Apr 2024 14:29:27 GMT, Nizar Benalla <duke at openjdk.org> wrote:

> Please review this PR that aims to add all the remaining needed `@since` tags in `java.base`, and group them into a single fix.
> This is related to #18934 and my work around the `@since` checker feature.
> Explicit `@since` tags are needed for some overriding methods for the purpose of the checker.
> 
> I will only give the example with the `CompletableFuture` class but here is the before where the methods only appeared in "Methods declared in interface N"
> 
> <img width="1510" alt="Screenshot 2024-05-06 at 00 06 57" src="https://github.com/openjdk/jdk/assets/96922791/1749a355-133b-4a38-bffe-51ac415b2aac">
> 
> 
> 
> and after where the method has it's own javadoc, the main description is added and the `@since` tags are added as intended.
> 
> I don't have an account on `https://cr.openjdk.org/` but I could host the generated docs somewhere if that is needed.
> 
> <img width="1511" alt="Screenshot 2024-05-06 at 00 07 16" src="https://github.com/openjdk/jdk/assets/96922791/89b92288-9b5e-48ed-8fa1-9342ea43e043">
> 
> <img width="1505" alt="Screenshot 2024-05-06 at 00 08 06" src="https://github.com/openjdk/jdk/assets/96922791/9aef08ff-5030-4189-a996-582a7eef849b">
> 
> <img width="1050" alt="Screenshot 2024-05-06 at 00 09 03" src="https://github.com/openjdk/jdk/assets/96922791/fdd75a26-0396-4c5e-8f59-a3717b7d7ec8">
> 
> 
> TIA

For account on cr.openjdk.org, just noticed that you aren't listed on the census https://openjdk.org/census yet. Once you have 2 patches integrated into the JDK, you should ask lead of JDK project Mark Reinhold to become an author (See https://openjdk.org/guide/#becoming-an-author and https://openjdk.org/projects/#project-author) and then you can use cr to host files for review.

Also, I am sorry for being too aggressive in the conversations with you before.

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

PR Comment: https://git.openjdk.org/jdk/pull/18954#issuecomment-2095015157

From jlahoda at openjdk.org  Mon May  6 05:52:06 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Mon, 6 May 2024 05:52:06 GMT
Subject: Integrated: 8328481: Implement JEP 476: Module Import Declarations
 (Preview)
In-Reply-To: <qyvysdjU6Gx6waBESJl8_UoLbZtYmIaALDWzTzmee80=.c60cc9a8-2061-4c68-886c-57823084a941@github.com>
References: <qyvysdjU6Gx6waBESJl8_UoLbZtYmIaALDWzTzmee80=.c60cc9a8-2061-4c68-886c-57823084a941@github.com>
Message-ID: <L6AP_Ej42zAwyq67lrOR90Fc7sPJ0d09K694ERkaqa4=.7e232a9b-887f-4d83-b10d-a98b0d38f75d@github.com>

On Thu, 4 Apr 2024 07:30:34 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> This is an implementation of JEP JDK-8315129: Module Import Declarations (Preview). Please see the JEP for details:
> https://bugs.openjdk.org/browse/JDK-8315129
> 
> It is mostly straightforward - the module imports are parsed, and then expanded to import-on-demand in `TypeEnter`.
> There is a few notable aspects, however:
> - the AST node for import (`JCImport`) is holding the imported element as a field access, because so far, the imported element always had to have a '.' (even for import-on-demand). But for module imports, it is permissible to import from a module whose name does not have a dot (`import module m;`). The use of field access for ordinary import seems very useful, so I preferred to keep that, and created a new internal-only AST node for module imports. There is still only one public API AST node/interface, so this is purely an implementation choice.
> - JShell now supports module imports as well; and the default, implicit, script is changed to use it to import all of `java.base` if preview is enabled. It is expected that the default would be changed if/when the module imports feature is finalized.

This pull request has now been integrated.

Changeset: f2c4a413
Author:    Jan Lahoda <jlahoda at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/f2c4a41304d4fe984b79792cb3be460d7026e812
Stats:     1343 lines in 31 files changed: 1268 ins; 17 del; 58 mod

8328481: Implement JEP 476: Module Import Declarations (Preview)

Co-authored-by: Jim Laskey <jlaskey at openjdk.org>
Reviewed-by: mcimadamore, vromero

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

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

From jlahoda at openjdk.org  Mon May  6 06:05:00 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Mon, 6 May 2024 06:05:00 GMT
Subject: Integrated: 8330998: System.console() writes to stderr when stdout is
 redirected
In-Reply-To: <A8XxdrFyHsuO_Kj27Y9eLMSgYnhvYW9ZKzs_sVJnTDM=.8a53eac4-2d84-4264-a591-8872071ecda1@github.com>
References: <A8XxdrFyHsuO_Kj27Y9eLMSgYnhvYW9ZKzs_sVJnTDM=.8a53eac4-2d84-4264-a591-8872071ecda1@github.com>
Message-ID: <5fVRZuuPOddKBol6s6EsI6iIzP6hRdZ69GC_Y-0ttaU=.500e4ed6-e550-42d7-b83e-53915ad360cc@github.com>

On Mon, 29 Apr 2024 11:44:50 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Consider code like:
> 
> public class ConsoleTest {
>     public static void main(String... args) {
>         System.console().printf("Hello!");
>     }
> }
> 
> 
> When run as:
> 
> $ java ConsoleTest.java >/dev/null
> 
> 
> it prints `Hello!` to stderr, instead of to stdout (where it would be redirected).
> 
> The proposed fix is to simply force the use of stdout. Sadly, this cannot be done solely using JLine configuration, we actually need to change the JLine's code for that.
> 
> The most tricky part is a test. There are two sub-tests, one effectively testing a case where all of stdin/out/err are redirected, the other is attempting to test the case where stdin is attached to a terminal, while stdout is redirected. The second sub-test using a native functions to create a pty and to attach to it, and should run in a separate VM, as it leaves the VM attached to the terminal.

This pull request has now been integrated.

Changeset: f1509e00
Author:    Jan Lahoda <jlahoda at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/f1509e007d1538acfb1749f7fafc56be2affd2e6
Stats:     183 lines in 3 files changed: 180 ins; 0 del; 3 mod

8330998: System.console() writes to stderr when stdout is redirected

Reviewed-by: naoto

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

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

From jlahoda at openjdk.org  Mon May  6 06:08:25 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Mon, 6 May 2024 06:08:25 GMT
Subject: RFR: 8331535: Incorrect prompt for Console.readLine [v2]
In-Reply-To: <IQvUAYG5zj0JqUbWiQiryAuBrtV6jrVCvy9useQZmlc=.a4dd8dfc-e835-4405-83f8-fd1bda8480f6@github.com>
References: <IQvUAYG5zj0JqUbWiQiryAuBrtV6jrVCvy9useQZmlc=.a4dd8dfc-e835-4405-83f8-fd1bda8480f6@github.com>
Message-ID: <n2hVZsDk5ut0paY93n_fssp8by37H3qBUotJuRBj69c=.040aa884-0cfe-4990-a32c-c83de9de8e42@github.com>

> When JLine reads a line, there may be a prompt provided. However, JLine will not interpret the prompt literally, it will handle `%` specially. As a consequence, doing:
> 
> System.console().readLine("%%s");
> 
> 
> will not print `%s`, as first `String.format` is used, which will convert `%%s` to `%s`, and then JLine will interpret the `%`. The proposed solution is to duplicate the `%`, so that JLine will print it.

Jan Lahoda 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.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/19081/files
  - new: https://git.openjdk.org/jdk/pull/19081/files/58cbd42e..58cbd42e

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

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

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

From duke at openjdk.org  Mon May  6 06:21:53 2024
From: duke at openjdk.org (Nizar Benalla)
Date: Mon, 6 May 2024 06:21:53 GMT
Subject: RFR: 8330954: Fix remaining `@since` tags in `java.base`
In-Reply-To: <fBxLBbMa9El6L2aATjtKyrAjlFRIjh1J7vPx2CbNT5E=.b33e4450-c1dc-4f36-b59b-5d9acb2da2dc@github.com>
References: <fBxLBbMa9El6L2aATjtKyrAjlFRIjh1J7vPx2CbNT5E=.b33e4450-c1dc-4f36-b59b-5d9acb2da2dc@github.com>
Message-ID: <aenBgJ08Y3d0DrZYq66vAeWiNaY4XbeBTZRN9qAtpJ8=.55ac09ba-8b19-4bc8-871a-e159706e32be@github.com>

On Thu, 25 Apr 2024 14:29:27 GMT, Nizar Benalla <duke at openjdk.org> wrote:

> Please review this PR that aims to add all the remaining needed `@since` tags in `java.base`, and group them into a single fix.
> This is related to #18934 and my work around the `@since` checker feature.
> Explicit `@since` tags are needed for some overriding methods for the purpose of the checker.
> 
> I will only give the example with the `CompletableFuture` class but here is the before where the methods only appeared in "Methods declared in interface N"
> 
> <img width="1510" alt="Screenshot 2024-05-06 at 00 06 57" src="https://github.com/openjdk/jdk/assets/96922791/1749a355-133b-4a38-bffe-51ac415b2aac">
> 
> 
> 
> and after where the method has it's own javadoc, the main description is added and the `@since` tags are added as intended.
> 
> I don't have an account on `https://cr.openjdk.org/` but I could host the generated docs somewhere if that is needed.
> 
> <img width="1511" alt="Screenshot 2024-05-06 at 00 07 16" src="https://github.com/openjdk/jdk/assets/96922791/89b92288-9b5e-48ed-8fa1-9342ea43e043">
> 
> <img width="1505" alt="Screenshot 2024-05-06 at 00 08 06" src="https://github.com/openjdk/jdk/assets/96922791/9aef08ff-5030-4189-a996-582a7eef849b">
> 
> <img width="1050" alt="Screenshot 2024-05-06 at 00 09 03" src="https://github.com/openjdk/jdk/assets/96922791/fdd75a26-0396-4c5e-8f59-a3717b7d7ec8">
> 
> 
> TIA

Thanks, I read those two links yesterday and was thinking of which project lead to mail to be added to the census. Will do so later.

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

PR Comment: https://git.openjdk.org/jdk/pull/18954#issuecomment-2095265790

From jlahoda at openjdk.org  Mon May  6 08:33:16 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Mon, 6 May 2024 08:33:16 GMT
Subject: RFR: 8331708: jdk/internal/jline/RedirectedStdOut.java times-out on
 macosx-aarch64
Message-ID: <VjtdRXHi93Bdht2-sFSO3pzV9YWDDi6fpvOWhjDN-VE=.5f4a873e-3fce-4642-a16e-58fd3c6c4591@github.com>

When integrating:
https://github.com/openjdk/jdk/pull/18996

I've forgot to push one last commit which was stabilizing the test of Mac OS/X. I am sorry for that.

The test will create a pseudo terminal, and change the current process stdin/stdout to write into the pty. But, there's nothing reading from the pty on the other side. This mostly works, OK, but the `ProcessTools` will write a debug log into `System.out` (which will write to stdout, which is the pty), and that blocks on Mac OS/X, presumably because there's nothing reading from the pty.

This patch changes the `System.out` for the main process to a scratch value, so no write to stdout/FD 1 is done, and no blocking should happen. (The process' stdout/FD 1 should remain attached to the pty.)

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

Commit messages:
 - 8331708: jdk/internal/jline/RedirectedStdOut.java times-out on macosx-aarch64

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

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

From asotona at openjdk.org  Mon May  6 08:38:52 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 6 May 2024 08:38:52 GMT
Subject: RFR: 8331708: jdk/internal/jline/RedirectedStdOut.java times-out
 on macosx-aarch64
In-Reply-To: <VjtdRXHi93Bdht2-sFSO3pzV9YWDDi6fpvOWhjDN-VE=.5f4a873e-3fce-4642-a16e-58fd3c6c4591@github.com>
References: <VjtdRXHi93Bdht2-sFSO3pzV9YWDDi6fpvOWhjDN-VE=.5f4a873e-3fce-4642-a16e-58fd3c6c4591@github.com>
Message-ID: <cvIufCVL3fPj6YKObjITW61LWzYyZfloGjLIQGa5Htk=.7db3db4a-b342-4629-ae38-765fb5f4cc8e@github.com>

On Mon, 6 May 2024 08:28:50 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> When integrating:
> https://github.com/openjdk/jdk/pull/18996
> 
> I've forgot to push one last commit which was stabilizing the test of Mac OS/X. I am sorry for that.
> 
> The test will create a pseudo terminal, and change the current process stdin/stdout to write into the pty. But, there's nothing reading from the pty on the other side. This mostly works, OK, but the `ProcessTools` will write a debug log into `System.out` (which will write to stdout, which is the pty), and that blocks on Mac OS/X, presumably because there's nothing reading from the pty.
> 
> This patch changes the `System.out` for the main process to a scratch value, so no write to stdout/FD 1 is done, and no blocking should happen. (The process' stdout/FD 1 should remain attached to the pty.)

It looks good, the test works on macosx-aarch64.

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

Marked as reviewed by asotona (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19097#pullrequestreview-2040267279

From jlahoda at openjdk.org  Mon May  6 08:51:56 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Mon, 6 May 2024 08:51:56 GMT
Subject: Integrated: 8331708: jdk/internal/jline/RedirectedStdOut.java
 times-out on macosx-aarch64
In-Reply-To: <VjtdRXHi93Bdht2-sFSO3pzV9YWDDi6fpvOWhjDN-VE=.5f4a873e-3fce-4642-a16e-58fd3c6c4591@github.com>
References: <VjtdRXHi93Bdht2-sFSO3pzV9YWDDi6fpvOWhjDN-VE=.5f4a873e-3fce-4642-a16e-58fd3c6c4591@github.com>
Message-ID: <VqztRMfZ_odK-njT41jHE99KXRERc3pFGloiTYsRbcA=.68fa6dc6-b5b7-4736-af6b-043edd4caf4a@github.com>

On Mon, 6 May 2024 08:28:50 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> When integrating:
> https://github.com/openjdk/jdk/pull/18996
> 
> I've forgot to push one last commit which was stabilizing the test of Mac OS/X. I am sorry for that.
> 
> The test will create a pseudo terminal, and change the current process stdin/stdout to write into the pty. But, there's nothing reading from the pty on the other side. This mostly works, OK, but the `ProcessTools` will write a debug log into `System.out` (which will write to stdout, which is the pty), and that blocks on Mac OS/X, presumably because there's nothing reading from the pty.
> 
> This patch changes the `System.out` for the main process to a scratch value, so no write to stdout/FD 1 is done, and no blocking should happen. (The process' stdout/FD 1 should remain attached to the pty.)

This pull request has now been integrated.

Changeset: 15862a2f
Author:    Jan Lahoda <jlahoda at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/15862a2f116331b7f439619c3aa1b5965e737044
Stats:     8 lines in 1 file changed: 6 ins; 1 del; 1 mod

8331708: jdk/internal/jline/RedirectedStdOut.java times-out on macosx-aarch64

Reviewed-by: asotona

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

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

From jpai at openjdk.org  Mon May  6 10:23:56 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 6 May 2024 10:23:56 GMT
Subject: RFR: 8329581: Java launcher no longer prints a stack trace
In-Reply-To: <yC-vO8l_RPw8Nz94rBeiKyyq44Fb8xnL0eF6ZHfxmD0=.12c4264c-5268-483d-8808-36f286efec76@github.com>
References: <Z0pDMIc_XvZhcZdeFsIQUlqI17q5ybj0BnQ9Kl3jwxg=.8f981c46-a8a3-4520-a6e3-79ee7fce0253@github.com>
 <61FmMvHyAQXcl_ZWYGEWwLDU7O8a-vdHTlu56rnKzqo=.cd118172-6497-4963-ad3b-b8f865009638@github.com>
 <Nvef5H6yg7TlYjDyCTYh1qTZoZB4B2nYvmV1d6BCnxs=.62b96873-a553-4c95-8a5a-eaf2fb6bc8a2@github.com>
 <JGexro9ukP8dyTCTNxYkhnde73SLC7def5rZBIFIuzg=.9ce10baf-a892-4b85-a570-f614978ef729@github.com>
 <yC-vO8l_RPw8Nz94rBeiKyyq44Fb8xnL0eF6ZHfxmD0=.12c4264c-5268-483d-8808-36f286efec76@github.com>
Message-ID: <VEFKhTxFBk7HkJSCliAagB1y8v4128BXKmbBjIJJnS0=.7b6addf8-e9b3-4cc6-be7a-b7b3d33549a9@github.com>

On Tue, 23 Apr 2024 18:21:30 GMT, Sonia Zaldana Calles <szaldana at openjdk.org> wrote:

>>> Just to clarify, this would still mean converting ?isStatic? and ?noArgs? from local variables to fields so I am able to read them on the C side of things. Did I understand this correctly?
>> 
>> I'm okay with adding static boolean fields and read by the native code and the name can be explicit like `isStaticMain` and `mainWithNoArg`.
>
> Hi @mlchung, thanks for the feedback! I?ve pushed the updates.
> 
> Just a question about ```NULL_CHECK0```. 
> 
> ```NULL_CHECK0``` reports the error message and then the exception is described in ```CHECK_EXCEPTION_LEAVE```. This results in a stack trace that looks like this: 
> 
> 
> Error: A JNI error has occurred, please check your installation and try again
> Exception in thread "main" java.lang.NoClassDefFoundError: DemoSonia$SomeDependency
> 	at DemoSonia.<clinit>(DemoSonia.java:3)
> Caused by: java.lang.ClassNotFoundException: DemoSonia$SomeDependency
> 	at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:641)
> 	at java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:188)
> 	at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:528)
> 	... 1 more
> 
> 
> 
> The JNI error message didn?t previously get reported before the regression was introduced, so I just wanted to make sure we were okay with this. 
> 
> Looking forward to your comments!

Hello @SoniaZaldana, I don't remember seeing the `java/lang/Thread/UncaughtExceptionsTest` fail before. It's failing in the current PR's GitHub actions job on several platforms. Could you take a look if it's related to the current changes?

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

PR Comment: https://git.openjdk.org/jdk/pull/18786#issuecomment-2095648483

From redestad at openjdk.org  Mon May  6 11:18:55 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Mon, 6 May 2024 11:18:55 GMT
Subject: RFR: 8331291: java.lang.classfile.Attributes class performs a lot
 of static initializations [v4]
In-Reply-To: <OQ_7GvZY9aR_wDxoXfR3ZpnVndRz3_Y4RnuZRKsg2Do=.acfbeec6-2e24-45db-b2b7-8b5aa250a873@github.com>
References: <SHIvjbwCWBPERKxlytEsY_O_kEiJbSeEmSusuDwjTIw=.ae8dd21e-a822-476e-9760-dd489532dbf1@github.com>
 <OQ_7GvZY9aR_wDxoXfR3ZpnVndRz3_Y4RnuZRKsg2Do=.acfbeec6-2e24-45db-b2b7-8b5aa250a873@github.com>
Message-ID: <mw-unnDYvbH9Ox6P9hMOH15jUmDkhKO2aizCRc6ulag=.5046d451-ba44-45fa-8c58-3bb9f522078a@github.com>

On Thu, 2 May 2024 11:08:16 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> Hi,
>> During performance optimization work on Class-File API as JDK lambda generator we found some static initialization killers.
>> One of them is `java.lang.classfile.Attributes` with tens of static fields initialized with individual attribute mappers, and common set of all mappers, and static map from attribute names to the mappers.
>> 
>> I propose to turn all the static fields into lazy-initialized static methods and remove `PREDEFINED_ATTRIBUTES` and `standardAttribute(Utf8Entry name)` static mapping method from the `Attributes` API class.
>>  
>> Please let me know your comments or objections and please review the [PR](https://github.com/openjdk/jdk/pull/19006) and [CSR](https://bugs.openjdk.org/browse/JDK-8331414), so we can make it into 23.
>> 
>> Thank you,
>> Adam
>
> Adam Sotona 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 seven additional commits since the last revision:
> 
>  - Merge branch 'master' into JDK-8331291-attributes
>  - changed order in allowed modules attributes check
>  - added bug number
>  - added impl comment
>  - removed list of predefined attributes
>    standard attributes mapping hard-coded and moved to BoundAttribute
>    added AttributesTest::testAttributesMapping
>  - move mappers implementations to AbstractAttributeMapper
>  - 8331291: java.lang.classfile.Attributes class performs a lot of static initializations

FWIW code changes looks good to me. There seems to be a number of tests that still need to be updated to use the new methods instead of the old constants.

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

Marked as reviewed by redestad (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19006#pullrequestreview-2040558054

From asotona at openjdk.org  Mon May  6 13:59:19 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 6 May 2024 13:59:19 GMT
Subject: RFR: 8331291: java.lang.classfile.Attributes class performs a lot
 of static initializations [v5]
In-Reply-To: <SHIvjbwCWBPERKxlytEsY_O_kEiJbSeEmSusuDwjTIw=.ae8dd21e-a822-476e-9760-dd489532dbf1@github.com>
References: <SHIvjbwCWBPERKxlytEsY_O_kEiJbSeEmSusuDwjTIw=.ae8dd21e-a822-476e-9760-dd489532dbf1@github.com>
Message-ID: <vSijoJG5NdQFzkqfPxUOgx_HA779iCsvEkCVZYnXVKw=.dfa019d9-b052-47c9-a755-c7b0f02b584a@github.com>

> Hi,
> During performance optimization work on Class-File API as JDK lambda generator we found some static initialization killers.
> One of them is `java.lang.classfile.Attributes` with tens of static fields initialized with individual attribute mappers, and common set of all mappers, and static map from attribute names to the mappers.
> 
> I propose to turn all the static fields into lazy-initialized static methods and remove `PREDEFINED_ATTRIBUTES` and `standardAttribute(Utf8Entry name)` static mapping method from the `Attributes` API class.
>  
> Please let me know your comments or objections and please review the [PR](https://github.com/openjdk/jdk/pull/19006) and [CSR](https://bugs.openjdk.org/browse/JDK-8331414), so we can make it into 23.
> 
> Thank you,
> Adam

Adam Sotona has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains ten commits:

 - updated LimitsTest
 - Merge branch 'master' into JDK-8331291-attributes
   
   # Conflicts:
   #	test/jdk/jdk/classfile/SignaturesTest.java
 - Merge branch 'master' into JDK-8331291-attributes
 - changed order in allowed modules attributes check
 - added bug number
 - added impl comment
 - removed list of predefined attributes
   standard attributes mapping hard-coded and moved to BoundAttribute
   added AttributesTest::testAttributesMapping
 - move mappers implementations to AbstractAttributeMapper
 - 8331291: java.lang.classfile.Attributes class performs a lot of static initializations

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

Changes: https://git.openjdk.org/jdk/pull/19006/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19006&range=04
  Stats: 2032 lines in 48 files changed: 905 ins; 619 del; 508 mod
  Patch: https://git.openjdk.org/jdk/pull/19006.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19006/head:pull/19006

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

From redestad at openjdk.org  Mon May  6 14:43:19 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Mon, 6 May 2024 14:43:19 GMT
Subject: RFR: 8331724: Refactor j.l.constant implementation to internal package
Message-ID: <_GPUF9d1E6eBKRxP6bEEqA3LSKRJe2GwCRTfVYbDwFU=.cb482785-e7c4-45f7-bd3a-cd32d466a2cb@github.com>

This PR suggests refactoring the implementation classes of java.lang.constant into a new package jdk.internal.constant to enable sharing some trusted static factory methods with users elsewhere in java.base, such as java.lang.invoke and java.lang.classfile. The refactoring also adds some "trusted" methods for use when input is pre-validated, and makes use of them where applicable in the current implementation. There are more changes in the pipeline which will be folded into #17108 or PR'ed once that is integrated. 

There are two optimizations mixed up here. One in `MethodTypeDesc.ofDescriptor`:

Name                                                             (descString) Cnt     Base     Error      Test   Error  Unit  Change
MethodTypeDescFactories.ofDescriptor  (Ljava/lang/Object;Ljava/lang/String;)I   6  138,371 ?   0,767   136,939 ? 1,126 ns/op   1,01x (p = 0,000*)
MethodTypeDescFactories.ofDescriptor                                      ()V   6   10,528 ?   2,495     4,110 ? 0,047 ns/op   2,56x (p = 0,000*)
MethodTypeDescFactories.ofDescriptor ([IJLjava/lang/String;Z)Ljava/util/List;   6  209,390 ?   4,583   196,175 ? 3,211 ns/op   1,07x (p = 0,000*)
MethodTypeDescFactories.ofDescriptor                    ()[Ljava/lang/String;   6   36,039 ?   8,684    20,794 ? 1,110 ns/op   1,73x (p = 0,000*)
MethodTypeDescFactories.ofDescriptor                                 (..IIJ)V   6  279,139 ?   6,248   187,934 ? 0,857 ns/op   1,49x (p = 0,000*)
MethodTypeDescFactories.ofDescriptor                 (.....................).   6 2174,387 ? 132,879  1150,652 ? 3,158 ns/op   1,89x (p = 0,000*)
  * = significant


The other in `ClassDesc::nested`, where to get rid of a simple static method in `ConstantUtils` I ended up speeding up and simplifying the public factory method:

Name                                      Cnt    Base     Error    Test   Error  Unit  Change
ClassDescFactories.ReferenceOnly.ofNested   6 209,853 ? 132,525  22,017 ? 0,573 ns/op   9,53x (p = 0,000*)
  * = significant


The optimizations could be split out and PRd independently, but I think they are simple enough to include in this refactoring.

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

Commit messages:
 - Fix and add sanity test for ClassDesc.ofDescriptor(V).arrayType()
 - 8331724: Refactor j.l.constant implementation to internal package

Changes: https://git.openjdk.org/jdk/pull/19105/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19105&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8331724
  Stats: 1366 lines in 25 files changed: 680 ins; 612 del; 74 mod
  Patch: https://git.openjdk.org/jdk/pull/19105.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19105/head:pull/19105

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

From liach at openjdk.org  Mon May  6 15:00:56 2024
From: liach at openjdk.org (Chen Liang)
Date: Mon, 6 May 2024 15:00:56 GMT
Subject: RFR: 8331724: Refactor j.l.constant implementation to internal
 package
In-Reply-To: <_GPUF9d1E6eBKRxP6bEEqA3LSKRJe2GwCRTfVYbDwFU=.cb482785-e7c4-45f7-bd3a-cd32d466a2cb@github.com>
References: <_GPUF9d1E6eBKRxP6bEEqA3LSKRJe2GwCRTfVYbDwFU=.cb482785-e7c4-45f7-bd3a-cd32d466a2cb@github.com>
Message-ID: <nAQ7IrGzu02gL7b7zzrsaiOOE_noLmvWk74xeyjFy9Q=.7dd9f135-44c0-4bd7-879b-180b70c39c44@github.com>

On Mon, 6 May 2024 14:39:08 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> This PR suggests refactoring the implementation classes of java.lang.constant into a new package jdk.internal.constant to enable sharing some trusted static factory methods with users elsewhere in java.base, such as java.lang.invoke and java.lang.classfile. The refactoring also adds some "trusted" methods for use when input is pre-validated, and makes use of them where applicable in the current implementation. There are more changes in the pipeline which will be folded into #17108 or PR'ed once that is integrated. 
> 
> There are two optimizations mixed up here. One in `MethodTypeDesc.ofDescriptor`:
> 
> Name                                                             (descString) Cnt     Base     Error      Test   Error  Unit  Change
> MethodTypeDescFactories.ofDescriptor  (Ljava/lang/Object;Ljava/lang/String;)I   6  138,371 ?   0,767   136,939 ? 1,126 ns/op   1,01x (p = 0,000*)
> MethodTypeDescFactories.ofDescriptor                                      ()V   6   10,528 ?   2,495     4,110 ? 0,047 ns/op   2,56x (p = 0,000*)
> MethodTypeDescFactories.ofDescriptor ([IJLjava/lang/String;Z)Ljava/util/List;   6  209,390 ?   4,583   196,175 ? 3,211 ns/op   1,07x (p = 0,000*)
> MethodTypeDescFactories.ofDescriptor                    ()[Ljava/lang/String;   6   36,039 ?   8,684    20,794 ? 1,110 ns/op   1,73x (p = 0,000*)
> MethodTypeDescFactories.ofDescriptor                                 (..IIJ)V   6  279,139 ?   6,248   187,934 ? 0,857 ns/op   1,49x (p = 0,000*)
> MethodTypeDescFactories.ofDescriptor                 (.....................).   6 2174,387 ? 132,879  1150,652 ? 3,158 ns/op   1,89x (p = 0,000*)
>   * = significant
> 
> 
> The other in `ClassDesc::nested`, where to get rid of a simple static method in `ConstantUtils` I ended up speeding up and simplifying the public factory method:
> 
> Name                                      Cnt    Base     Error    Test   Error  Unit  Change
> ClassDescFactories.ReferenceOnly.ofNested   6 209,853 ? 132,525  22,017 ? 0,573 ns/op   9,53x (p = 0,000*)
>   * = significant
> 
> 
> The optimizations could be split out and PRd independently, but I think they are simple enough to include in this refactoring.

src/java.base/share/classes/java/lang/constant/ClassDesc.java line 113:

> 111:     static ClassDesc ofInternalName(String name) {
> 112:         validateInternalClassName(requireNonNull(name));
> 113:         return ClassDesc.ofDescriptor("L" + name + ";");

We can use `ofTrusted` here and above if we validate the binary/internal names to have no trailing or consecutive slash/dots.

src/java.base/share/classes/java/lang/constant/ClassDesc.java line 131:

> 129:      */
> 130:     static ClassDesc of(String packageName, String className) {
> 131:         validateBinaryClassName(requireNonNull(packageName));

Suggestion:

        validateBinaryClassName(packageName);

the validate call already null-checks.

src/java.base/share/classes/java/lang/constant/ClassDesc.java line 222:

> 220:         }
> 221:         if (desc.length() == 1 && desc.charAt(0) == 'V') {
> 222:             throw new IllegalArgumentException(String.format("not a valid reference type descriptor: %sV", "[".repeat(rank)));

Suggestion:

            throw new IllegalArgumentException(String.format("not a valid reference type descriptor: %sV", "[".repeat(netRank)));

Or should we override this in `PrimitiveClassDescImpl`, which can bypass the rank sum computation?

src/java.base/share/classes/jdk/internal/constant/ConstantUtils.java line 80:

> 78:             char ch = name.charAt(i);
> 79:             if (ch == ';' || ch == '[' || ch == '.')
> 80:                 throw new IllegalArgumentException("Invalid class name: " + name);

We can check there's no consecutive `..` `//` or trailing `.` or `/` so we can just use the validated string to create a reference class desc.

src/java.base/share/classes/jdk/internal/constant/ReferenceClassDescImpl.java line 68:

> 66:      * @jvms 4.3.2 Field Descriptors
> 67:      */
> 68:     public static ReferenceClassDescImpl ofTrusted(String descriptor) {

If you named `ofTrusted` to be in parity with the MTDImpl factory, they are different as MTD one means array is trusted; this one means descriptor is already valid.

src/java.base/share/classes/module-info.java line 377:

> 375:     exports sun.util.resources to
> 376:         jdk.localedata;
> 377:     exports jdk.internal.constant;

This is probably unintentional, if you do export we probably want to only export to select modules.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19105#discussion_r1591126247
PR Review Comment: https://git.openjdk.org/jdk/pull/19105#discussion_r1591126687
PR Review Comment: https://git.openjdk.org/jdk/pull/19105#discussion_r1591140187
PR Review Comment: https://git.openjdk.org/jdk/pull/19105#discussion_r1591133504
PR Review Comment: https://git.openjdk.org/jdk/pull/19105#discussion_r1591130463
PR Review Comment: https://git.openjdk.org/jdk/pull/19105#discussion_r1591122920

From redestad at openjdk.org  Mon May  6 15:03:53 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Mon, 6 May 2024 15:03:53 GMT
Subject: RFR: 8331724: Refactor j.l.constant implementation to internal
 package
In-Reply-To: <nAQ7IrGzu02gL7b7zzrsaiOOE_noLmvWk74xeyjFy9Q=.7dd9f135-44c0-4bd7-879b-180b70c39c44@github.com>
References: <_GPUF9d1E6eBKRxP6bEEqA3LSKRJe2GwCRTfVYbDwFU=.cb482785-e7c4-45f7-bd3a-cd32d466a2cb@github.com>
 <nAQ7IrGzu02gL7b7zzrsaiOOE_noLmvWk74xeyjFy9Q=.7dd9f135-44c0-4bd7-879b-180b70c39c44@github.com>
Message-ID: <KUhJ0GZ_RRu3boHmIx5285zw-gn6P1zQuJTslEBO_hI=.102685c1-3e9f-44a3-91c6-d69ac972b493@github.com>

On Mon, 6 May 2024 14:46:09 GMT, Chen Liang <liach at openjdk.org> wrote:

>> This PR suggests refactoring the implementation classes of java.lang.constant into a new package jdk.internal.constant to enable sharing some trusted static factory methods with users elsewhere in java.base, such as java.lang.invoke and java.lang.classfile. The refactoring also adds some "trusted" methods for use when input is pre-validated, and makes use of them where applicable in the current implementation. There are more changes in the pipeline which will be folded into #17108 or PR'ed once that is integrated. 
>> 
>> There are two optimizations mixed up here. One in `MethodTypeDesc.ofDescriptor`:
>> 
>> Name                                                             (descString) Cnt     Base     Error      Test   Error  Unit  Change
>> MethodTypeDescFactories.ofDescriptor  (Ljava/lang/Object;Ljava/lang/String;)I   6  138,371 ?   0,767   136,939 ? 1,126 ns/op   1,01x (p = 0,000*)
>> MethodTypeDescFactories.ofDescriptor                                      ()V   6   10,528 ?   2,495     4,110 ? 0,047 ns/op   2,56x (p = 0,000*)
>> MethodTypeDescFactories.ofDescriptor ([IJLjava/lang/String;Z)Ljava/util/List;   6  209,390 ?   4,583   196,175 ? 3,211 ns/op   1,07x (p = 0,000*)
>> MethodTypeDescFactories.ofDescriptor                    ()[Ljava/lang/String;   6   36,039 ?   8,684    20,794 ? 1,110 ns/op   1,73x (p = 0,000*)
>> MethodTypeDescFactories.ofDescriptor                                 (..IIJ)V   6  279,139 ?   6,248   187,934 ? 0,857 ns/op   1,49x (p = 0,000*)
>> MethodTypeDescFactories.ofDescriptor                 (.....................).   6 2174,387 ? 132,879  1150,652 ? 3,158 ns/op   1,89x (p = 0,000*)
>>   * = significant
>> 
>> 
>> The other in `ClassDesc::nested`, where to get rid of a simple static method in `ConstantUtils` I ended up speeding up and simplifying the public factory method:
>> 
>> Name                                      Cnt    Base     Error    Test   Error  Unit  Change
>> ClassDescFactories.ReferenceOnly.ofNested   6 209,853 ? 132,525  22,017 ? 0,573 ns/op   9,53x (p = 0,000*)
>>   * = significant
>> 
>> 
>> The optimizations could be split out and PRd independently, but I think they are simple enough to include in this refactoring.
>
> src/java.base/share/classes/module-info.java line 377:
> 
>> 375:     exports sun.util.resources to
>> 376:         jdk.localedata;
>> 377:     exports jdk.internal.constant;
> 
> This is probably unintentional, if you do export we probably want to only export to select modules.

Yes, seems IDEA took some liberties on a move refactor. Removing.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19105#discussion_r1591145080

From redestad at openjdk.org  Mon May  6 15:06:53 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Mon, 6 May 2024 15:06:53 GMT
Subject: RFR: 8331724: Refactor j.l.constant implementation to internal
 package
In-Reply-To: <nAQ7IrGzu02gL7b7zzrsaiOOE_noLmvWk74xeyjFy9Q=.7dd9f135-44c0-4bd7-879b-180b70c39c44@github.com>
References: <_GPUF9d1E6eBKRxP6bEEqA3LSKRJe2GwCRTfVYbDwFU=.cb482785-e7c4-45f7-bd3a-cd32d466a2cb@github.com>
 <nAQ7IrGzu02gL7b7zzrsaiOOE_noLmvWk74xeyjFy9Q=.7dd9f135-44c0-4bd7-879b-180b70c39c44@github.com>
Message-ID: <QwnP1nbD8b_qEr415hhssgkaCFll5h4z7tXlCr5E0Uc=.56748c79-070c-40d7-81a1-b7b6dde92c74@github.com>

On Mon, 6 May 2024 14:51:17 GMT, Chen Liang <liach at openjdk.org> wrote:

>> This PR suggests refactoring the implementation classes of java.lang.constant into a new package jdk.internal.constant to enable sharing some trusted static factory methods with users elsewhere in java.base, such as java.lang.invoke and java.lang.classfile. The refactoring also adds some "trusted" methods for use when input is pre-validated, and makes use of them where applicable in the current implementation. There are more changes in the pipeline which will be folded into #17108 or PR'ed once that is integrated. 
>> 
>> There are two optimizations mixed up here. One in `MethodTypeDesc.ofDescriptor`:
>> 
>> Name                                                             (descString) Cnt     Base     Error      Test   Error  Unit  Change
>> MethodTypeDescFactories.ofDescriptor  (Ljava/lang/Object;Ljava/lang/String;)I   6  138,371 ?   0,767   136,939 ? 1,126 ns/op   1,01x (p = 0,000*)
>> MethodTypeDescFactories.ofDescriptor                                      ()V   6   10,528 ?   2,495     4,110 ? 0,047 ns/op   2,56x (p = 0,000*)
>> MethodTypeDescFactories.ofDescriptor ([IJLjava/lang/String;Z)Ljava/util/List;   6  209,390 ?   4,583   196,175 ? 3,211 ns/op   1,07x (p = 0,000*)
>> MethodTypeDescFactories.ofDescriptor                    ()[Ljava/lang/String;   6   36,039 ?   8,684    20,794 ? 1,110 ns/op   1,73x (p = 0,000*)
>> MethodTypeDescFactories.ofDescriptor                                 (..IIJ)V   6  279,139 ?   6,248   187,934 ? 0,857 ns/op   1,49x (p = 0,000*)
>> MethodTypeDescFactories.ofDescriptor                 (.....................).   6 2174,387 ? 132,879  1150,652 ? 3,158 ns/op   1,89x (p = 0,000*)
>>   * = significant
>> 
>> 
>> The other in `ClassDesc::nested`, where to get rid of a simple static method in `ConstantUtils` I ended up speeding up and simplifying the public factory method:
>> 
>> Name                                      Cnt    Base     Error    Test   Error  Unit  Change
>> ClassDescFactories.ReferenceOnly.ofNested   6 209,853 ? 132,525  22,017 ? 0,573 ns/op   9,53x (p = 0,000*)
>>   * = significant
>> 
>> 
>> The optimizations could be split out and PRd independently, but I think they are simple enough to include in this refactoring.
>
> src/java.base/share/classes/jdk/internal/constant/ReferenceClassDescImpl.java line 68:
> 
>> 66:      * @jvms 4.3.2 Field Descriptors
>> 67:      */
>> 68:     public static ReferenceClassDescImpl ofTrusted(String descriptor) {
> 
> If you named `ofTrusted` to be in parity with the MTDImpl factory, they are different as MTD one means array is trusted; this one means descriptor is already valid.

`ofValidated`?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19105#discussion_r1591147979

From redestad at openjdk.org  Mon May  6 15:12:20 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Mon, 6 May 2024 15:12:20 GMT
Subject: RFR: 8331724: Refactor j.l.constant implementation to internal
 package [v2]
In-Reply-To: <_GPUF9d1E6eBKRxP6bEEqA3LSKRJe2GwCRTfVYbDwFU=.cb482785-e7c4-45f7-bd3a-cd32d466a2cb@github.com>
References: <_GPUF9d1E6eBKRxP6bEEqA3LSKRJe2GwCRTfVYbDwFU=.cb482785-e7c4-45f7-bd3a-cd32d466a2cb@github.com>
Message-ID: <UdNSKRgw0h1_bxtYSXDGSDyPMAK6MDczMx6xR2KQPpI=.060f6b0e-75ed-4e4c-98c1-acf318f0a3a2@github.com>

> This PR suggests refactoring the implementation classes of java.lang.constant into a new package jdk.internal.constant to enable sharing some trusted static factory methods with users elsewhere in java.base, such as java.lang.invoke and java.lang.classfile. The refactoring also adds some "trusted" methods for use when input is pre-validated, and makes use of them where applicable in the current implementation. There are more changes in the pipeline which will be folded into #17108 or PR'ed once that is integrated. 
> 
> There are two optimizations mixed up here. One in `MethodTypeDesc.ofDescriptor`:
> 
> Name                                                             (descString) Cnt     Base     Error      Test   Error  Unit  Change
> MethodTypeDescFactories.ofDescriptor  (Ljava/lang/Object;Ljava/lang/String;)I   6  138,371 ?   0,767   136,939 ? 1,126 ns/op   1,01x (p = 0,000*)
> MethodTypeDescFactories.ofDescriptor                                      ()V   6   10,528 ?   2,495     4,110 ? 0,047 ns/op   2,56x (p = 0,000*)
> MethodTypeDescFactories.ofDescriptor ([IJLjava/lang/String;Z)Ljava/util/List;   6  209,390 ?   4,583   196,175 ? 3,211 ns/op   1,07x (p = 0,000*)
> MethodTypeDescFactories.ofDescriptor                    ()[Ljava/lang/String;   6   36,039 ?   8,684    20,794 ? 1,110 ns/op   1,73x (p = 0,000*)
> MethodTypeDescFactories.ofDescriptor                                 (..IIJ)V   6  279,139 ?   6,248   187,934 ? 0,857 ns/op   1,49x (p = 0,000*)
> MethodTypeDescFactories.ofDescriptor                 (.....................).   6 2174,387 ? 132,879  1150,652 ? 3,158 ns/op   1,89x (p = 0,000*)
>   * = significant
> 
> 
> The other in `ClassDesc::nested`, where to get rid of a simple static method in `ConstantUtils` I ended up speeding up and simplifying the public factory method:
> 
> Name                                      Cnt    Base     Error    Test   Error  Unit  Change
> ClassDescFactories.ReferenceOnly.ofNested   6 209,853 ? 132,525  22,017 ? 0,573 ns/op   9,53x (p = 0,000*)
>   * = significant
> 
> 
> The optimizations could be split out and PRd independently, but I think they are simple enough to include in this refactoring.

Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:

  Update src/java.base/share/classes/java/lang/constant/ClassDesc.java
  
  Co-authored-by: liach <7806504+liach at users.noreply.github.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/19105/files
  - new: https://git.openjdk.org/jdk/pull/19105/files/56631cac..f3112f8e

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

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

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

From liach at openjdk.org  Mon May  6 15:12:21 2024
From: liach at openjdk.org (Chen Liang)
Date: Mon, 6 May 2024 15:12:21 GMT
Subject: RFR: 8331724: Refactor j.l.constant implementation to internal
 package [v2]
In-Reply-To: <QwnP1nbD8b_qEr415hhssgkaCFll5h4z7tXlCr5E0Uc=.56748c79-070c-40d7-81a1-b7b6dde92c74@github.com>
References: <_GPUF9d1E6eBKRxP6bEEqA3LSKRJe2GwCRTfVYbDwFU=.cb482785-e7c4-45f7-bd3a-cd32d466a2cb@github.com>
 <nAQ7IrGzu02gL7b7zzrsaiOOE_noLmvWk74xeyjFy9Q=.7dd9f135-44c0-4bd7-879b-180b70c39c44@github.com>
 <QwnP1nbD8b_qEr415hhssgkaCFll5h4z7tXlCr5E0Uc=.56748c79-070c-40d7-81a1-b7b6dde92c74@github.com>
Message-ID: <r7E1qTyTTQBlxwI67IHHyBD4nhd7XXtCtrgYwS70OD4=.e9f2a663-540a-4976-9443-4f85a0bf51c3@github.com>

On Mon, 6 May 2024 15:03:53 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/constant/ReferenceClassDescImpl.java line 68:
>> 
>>> 66:      * @jvms 4.3.2 Field Descriptors
>>> 67:      */
>>> 68:     public static ReferenceClassDescImpl ofTrusted(String descriptor) {
>> 
>> If you named `ofTrusted` to be in parity with the MTDImpl factory, they are different as MTD one means array is trusted; this one means descriptor is already valid.
>
> `ofValidated`?

Sounds good to me, as long as the 2 factories take any different name combination so we don't think they both bypass everything

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19105#discussion_r1591152653

From redestad at openjdk.org  Mon May  6 15:15:36 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Mon, 6 May 2024 15:15:36 GMT
Subject: RFR: 8331724: Refactor j.l.constant implementation to internal
 package [v3]
In-Reply-To: <_GPUF9d1E6eBKRxP6bEEqA3LSKRJe2GwCRTfVYbDwFU=.cb482785-e7c4-45f7-bd3a-cd32d466a2cb@github.com>
References: <_GPUF9d1E6eBKRxP6bEEqA3LSKRJe2GwCRTfVYbDwFU=.cb482785-e7c4-45f7-bd3a-cd32d466a2cb@github.com>
Message-ID: <sCsGUwAF3RvCYkyKuE12w_YjQ3Weh0IcxrLbuCwyeFk=.29f8c6ef-4a9f-47b7-81e5-f61e555e049e@github.com>

> This PR suggests refactoring the implementation classes of java.lang.constant into a new package jdk.internal.constant to enable sharing some trusted static factory methods with users elsewhere in java.base, such as java.lang.invoke and java.lang.classfile. The refactoring also adds some "trusted" methods for use when input is pre-validated, and makes use of them where applicable in the current implementation. There are more changes in the pipeline which will be folded into #17108 or PR'ed once that is integrated. 
> 
> There are two optimizations mixed up here. One in `MethodTypeDesc.ofDescriptor`:
> 
> Name                                                             (descString) Cnt     Base     Error      Test   Error  Unit  Change
> MethodTypeDescFactories.ofDescriptor  (Ljava/lang/Object;Ljava/lang/String;)I   6  138,371 ?   0,767   136,939 ? 1,126 ns/op   1,01x (p = 0,000*)
> MethodTypeDescFactories.ofDescriptor                                      ()V   6   10,528 ?   2,495     4,110 ? 0,047 ns/op   2,56x (p = 0,000*)
> MethodTypeDescFactories.ofDescriptor ([IJLjava/lang/String;Z)Ljava/util/List;   6  209,390 ?   4,583   196,175 ? 3,211 ns/op   1,07x (p = 0,000*)
> MethodTypeDescFactories.ofDescriptor                    ()[Ljava/lang/String;   6   36,039 ?   8,684    20,794 ? 1,110 ns/op   1,73x (p = 0,000*)
> MethodTypeDescFactories.ofDescriptor                                 (..IIJ)V   6  279,139 ?   6,248   187,934 ? 0,857 ns/op   1,49x (p = 0,000*)
> MethodTypeDescFactories.ofDescriptor                 (.....................).   6 2174,387 ? 132,879  1150,652 ? 3,158 ns/op   1,89x (p = 0,000*)
>   * = significant
> 
> 
> The other in `ClassDesc::nested`, where to get rid of a simple static method in `ConstantUtils` I ended up speeding up and simplifying the public factory method:
> 
> Name                                      Cnt    Base     Error    Test   Error  Unit  Change
> ClassDescFactories.ReferenceOnly.ofNested   6 209,853 ? 132,525  22,017 ? 0,573 ns/op   9,53x (p = 0,000*)
>   * = significant
> 
> 
> The optimizations could be split out and PRd independently, but I think they are simple enough to include in this refactoring.

Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:

  Rename ofTrusted to ofValidated, remove accidental module-info exports

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/19105/files
  - new: https://git.openjdk.org/jdk/pull/19105/files/f3112f8e..f2f90193

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

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

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

From jlahoda at openjdk.org  Mon May  6 15:19:00 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Mon, 6 May 2024 15:19:00 GMT
Subject: RFR: 8329420: Java 22 (and 23) launcher calls default constructor
 although main() is static [v4]
In-Reply-To: <-2mCabXRtUPnuhrF3gxztTj-fpuROUnXjs2Dev9eLR4=.c32fae3e-edea-450f-9ce4-5f1f4ffb2f06@github.com>
References: <sbssZz9MyKADfaqvwTxavbOsdhKlVDnkr-z1pLkUFEk=.86809eb6-162c-49f0-993f-86f7ef28fd89@github.com>
 <-2mCabXRtUPnuhrF3gxztTj-fpuROUnXjs2Dev9eLR4=.c32fae3e-edea-450f-9ce4-5f1f4ffb2f06@github.com>
Message-ID: <NojwEtKbWTY1AHPUZ5LyET3bGSdAULn6bB_Df2bGtOc=.d0769a47-026f-490a-9f2c-0f79381f6dfd@github.com>

On Wed, 17 Apr 2024 09:20:24 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> Consider code like:
>> 
>> public class MainClass {
>>     public MainClass() {
>>         System.out.println("Constructor called!");
>>     }
>>     public static void main() {
>>         System.out.println("main called!");
>>     }
>> }
>> 
>> and compile and run it, with preview enabled, like:
>> 
>> $ javac /tmp/MainClass.java 
>> $ java --enable-preview -classpath /tmp MainClass
>> Constructor called!
>> main called!
>> 
>> 
>> That is wrong, as the `main` method is static, and there is no need to create a new instance of the class.
>> 
>> The reason is that as launcher attempts to invoke the main method, it goes in the following order: 1) static-main-with-args; 2) instance-main-with-args; 3) static-main-without-args; 4) instance-main-without-args. But, for the instance variants, the code first creates a new instance of the given class, and only then attempts to lookup the `main` method, and will pass to the next option when the `main` method lookup fails. So, when invoking static-main-without-args, the current class instance may be created for instance-main-with-args, which will then fail due to the missing `main(String[])` method.
>> 
>> The proposed solution to this problem is to simply first do a lookup for the `main` method (skipping to the next variant when the given main method does not exist, without instantiating the current class).
>> 
>> There is also a relatively closely related problem: what happens when the constructor throws an exception?
>> 
>> public class MainClass {
>>     public MainClass() {
>>         if (true) throw new RuntimeException();
>>     }
>>     public void main() {
>>         System.out.println("main called!");
>>     }
>> }
>> 
>> 
>> when compiled an run, this produces no output whatsoever:
>> 
>> $ javac /tmp/MainClass.java 
>> $ java --enable-preview -classpath /tmp MainClass
>> $
>> 
>> 
>> This is because any exceptions thrown from the constructor are effectively ignored, and the launcher will continue with the next variant. This seems wrong - the exception should be printed for the user, like:
>> 
>> $ java --enable-preview -classpath /tmp/ MainClass 
>> Exception in thread "main" java.lang.RuntimeException
>>         at MainClass.<init>(MainClass.java:3)
>> 
>> 
>> This patch proposes to do that by not consuming the exceptions thrown from the constructor, and stop the propagation to the next variant.
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixing typo (should not continue after an exception from a constructor).

Superseded by https://github.com/openjdk/jdk/pull/18786.

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

PR Comment: https://git.openjdk.org/jdk/pull/18753#issuecomment-2096278740

From jlahoda at openjdk.org  Mon May  6 15:19:00 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Mon, 6 May 2024 15:19:00 GMT
Subject: Withdrawn: 8329420: Java 22 (and 23) launcher calls default
 constructor although main() is static
In-Reply-To: <sbssZz9MyKADfaqvwTxavbOsdhKlVDnkr-z1pLkUFEk=.86809eb6-162c-49f0-993f-86f7ef28fd89@github.com>
References: <sbssZz9MyKADfaqvwTxavbOsdhKlVDnkr-z1pLkUFEk=.86809eb6-162c-49f0-993f-86f7ef28fd89@github.com>
Message-ID: <SRjHL9EiUuT4nN2_XTwwdiOpu0fSIf75rluv6vttO5o=.9ae75f7a-0cfd-42c4-a37f-5816e2512dd1@github.com>

On Fri, 12 Apr 2024 10:16:36 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Consider code like:
> 
> public class MainClass {
>     public MainClass() {
>         System.out.println("Constructor called!");
>     }
>     public static void main() {
>         System.out.println("main called!");
>     }
> }
> 
> and compile and run it, with preview enabled, like:
> 
> $ javac /tmp/MainClass.java 
> $ java --enable-preview -classpath /tmp MainClass
> Constructor called!
> main called!
> 
> 
> That is wrong, as the `main` method is static, and there is no need to create a new instance of the class.
> 
> The reason is that as launcher attempts to invoke the main method, it goes in the following order: 1) static-main-with-args; 2) instance-main-with-args; 3) static-main-without-args; 4) instance-main-without-args. But, for the instance variants, the code first creates a new instance of the given class, and only then attempts to lookup the `main` method, and will pass to the next option when the `main` method lookup fails. So, when invoking static-main-without-args, the current class instance may be created for instance-main-with-args, which will then fail due to the missing `main(String[])` method.
> 
> The proposed solution to this problem is to simply first do a lookup for the `main` method (skipping to the next variant when the given main method does not exist, without instantiating the current class).
> 
> There is also a relatively closely related problem: what happens when the constructor throws an exception?
> 
> public class MainClass {
>     public MainClass() {
>         if (true) throw new RuntimeException();
>     }
>     public void main() {
>         System.out.println("main called!");
>     }
> }
> 
> 
> when compiled an run, this produces no output whatsoever:
> 
> $ javac /tmp/MainClass.java 
> $ java --enable-preview -classpath /tmp MainClass
> $
> 
> 
> This is because any exceptions thrown from the constructor are effectively ignored, and the launcher will continue with the next variant. This seems wrong - the exception should be printed for the user, like:
> 
> $ java --enable-preview -classpath /tmp/ MainClass 
> Exception in thread "main" java.lang.RuntimeException
>         at MainClass.<init>(MainClass.java:3)
> 
> 
> This patch proposes to do that by not consuming the exceptions thrown from the constructor, and stop the propagation to the next variant.

This pull request has been closed without being integrated.

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

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

From duke at openjdk.org  Mon May  6 15:20:08 2024
From: duke at openjdk.org (Nizar Benalla)
Date: Mon, 6 May 2024 15:20:08 GMT
Subject: RFR: 8330954: Fix remaining `@since` tags in `java.base` [v2]
In-Reply-To: <fBxLBbMa9El6L2aATjtKyrAjlFRIjh1J7vPx2CbNT5E=.b33e4450-c1dc-4f36-b59b-5d9acb2da2dc@github.com>
References: <fBxLBbMa9El6L2aATjtKyrAjlFRIjh1J7vPx2CbNT5E=.b33e4450-c1dc-4f36-b59b-5d9acb2da2dc@github.com>
Message-ID: <xs0AUGw9Oyg3uQ6hn9e1IWjQ2t5ZjvxzB2ek_naAK84=.86e72dfa-a874-41c5-bcec-e8e941c27ca7@github.com>

> Please review this PR that aims to add all the remaining needed `@since` tags in `java.base`, and group them into a single fix.
> This is related to #18934 and my work around the `@since` checker feature.
> Explicit `@since` tags are needed for some overriding methods for the purpose of the checker.
> 
> I will only give the example with the `CompletableFuture` class but here is the before where the methods only appeared in "Methods declared in interface N"
> 
> <img width="1510" alt="Screenshot 2024-05-06 at 00 06 57" src="https://github.com/openjdk/jdk/assets/96922791/1749a355-133b-4a38-bffe-51ac415b2aac">
> 
> 
> 
> and after where the method has it's own javadoc, the main description is added and the `@since` tags are added as intended.
> 
> I don't have an account on `https://cr.openjdk.org/` but I could host the generated docs somewhere if that is needed.
> 
> <img width="1511" alt="Screenshot 2024-05-06 at 00 07 16" src="https://github.com/openjdk/jdk/assets/96922791/89b92288-9b5e-48ed-8fa1-9342ea43e043">
> 
> <img width="1505" alt="Screenshot 2024-05-06 at 00 08 06" src="https://github.com/openjdk/jdk/assets/96922791/9aef08ff-5030-4189-a996-582a7eef849b">
> 
> <img width="1050" alt="Screenshot 2024-05-06 at 00 09 03" src="https://github.com/openjdk/jdk/assets/96922791/fdd75a26-0396-4c5e-8f59-a3717b7d7ec8">
> 
> 
> TIA

Nizar Benalla has updated the pull request incrementally with one additional commit since the last revision:

  Move security classes changes to pr18373

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18954/files
  - new: https://git.openjdk.org/jdk/pull/18954/files/62e623fa..d38a1c7d

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

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

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

From redestad at openjdk.org  Mon May  6 15:21:55 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Mon, 6 May 2024 15:21:55 GMT
Subject: RFR: 8331724: Refactor j.l.constant implementation to internal
 package [v3]
In-Reply-To: <nAQ7IrGzu02gL7b7zzrsaiOOE_noLmvWk74xeyjFy9Q=.7dd9f135-44c0-4bd7-879b-180b70c39c44@github.com>
References: <_GPUF9d1E6eBKRxP6bEEqA3LSKRJe2GwCRTfVYbDwFU=.cb482785-e7c4-45f7-bd3a-cd32d466a2cb@github.com>
 <nAQ7IrGzu02gL7b7zzrsaiOOE_noLmvWk74xeyjFy9Q=.7dd9f135-44c0-4bd7-879b-180b70c39c44@github.com>
Message-ID: <hohcB4WlKVsViNIKgM4g-i92YBGOlX5jjAm1OvOzEZ0=.7834fb7b-89a2-44be-b177-a988966ae84a@github.com>

On Mon, 6 May 2024 14:58:02 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Rename ofTrusted to ofValidated, remove accidental module-info exports
>
> src/java.base/share/classes/java/lang/constant/ClassDesc.java line 222:
> 
>> 220:         }
>> 221:         if (desc.length() == 1 && desc.charAt(0) == 'V') {
>> 222:             throw new IllegalArgumentException(String.format("not a valid reference type descriptor: %sV", "[".repeat(rank)));
> 
> Suggestion:
> 
>             throw new IllegalArgumentException(String.format("not a valid reference type descriptor: %sV", "[".repeat(netRank)));
> 
> Or should we override this in `PrimitiveClassDescImpl`, which can bypass the rank sum computation?

`currentDepth` must be 0 in this case, so `rank` or `netRank` doesn't matter. Overriding in `PrimitiveClassDescImpl` sounds reasonable, but then perhaps default method should be removed, too, since it would look strange to have the default method be specialized for instance/array types. Sounds like a CSR might be needed(?), so let's do that in a follow up.

> src/java.base/share/classes/jdk/internal/constant/ConstantUtils.java line 80:
> 
>> 78:             char ch = name.charAt(i);
>> 79:             if (ch == ';' || ch == '[' || ch == '.')
>> 80:                 throw new IllegalArgumentException("Invalid class name: " + name);
> 
> We can check there's no consecutive `..` `//` or trailing `.` or `/` so we can just use the validated string to create a reference class desc.

Sounds reasonable, but I think I have already piled on too much into this PR. Ok to defer to a follow-up?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19105#discussion_r1591165979
PR Review Comment: https://git.openjdk.org/jdk/pull/19105#discussion_r1591167360

From liach at openjdk.org  Mon May  6 15:39:56 2024
From: liach at openjdk.org (Chen Liang)
Date: Mon, 6 May 2024 15:39:56 GMT
Subject: RFR: 8330954: Fix remaining `@since` tags in `java.base` [v2]
In-Reply-To: <xs0AUGw9Oyg3uQ6hn9e1IWjQ2t5ZjvxzB2ek_naAK84=.86e72dfa-a874-41c5-bcec-e8e941c27ca7@github.com>
References: <fBxLBbMa9El6L2aATjtKyrAjlFRIjh1J7vPx2CbNT5E=.b33e4450-c1dc-4f36-b59b-5d9acb2da2dc@github.com>
 <xs0AUGw9Oyg3uQ6hn9e1IWjQ2t5ZjvxzB2ek_naAK84=.86e72dfa-a874-41c5-bcec-e8e941c27ca7@github.com>
Message-ID: <JQNZ0EK-Ehoy7yVwZhZ8wzbM_5JfEy5cWTmFXxtLsoE=.e35267d1-b754-420d-bc90-081b37fcd3de@github.com>

On Mon, 6 May 2024 15:20:08 GMT, Nizar Benalla <duke at openjdk.org> wrote:

>> Please review this PR that aims to add all the remaining needed `@since` tags in `java.base`, and group them into a single fix.
>> This is related to #18934 and my work around the `@since` checker feature.
>> Explicit `@since` tags are needed for some overriding methods for the purpose of the checker.
>> 
>> I will only give the example with the `CompletableFuture` class but here is the before where the methods only appeared in "Methods declared in interface N"
>> 
>> <img width="1510" alt="Screenshot 2024-05-06 at 00 06 57" src="https://github.com/openjdk/jdk/assets/96922791/1749a355-133b-4a38-bffe-51ac415b2aac">
>> 
>> 
>> 
>> and after where the method has it's own javadoc, the main description is added and the `@since` tags are added as intended.
>> 
>> I don't have an account on `https://cr.openjdk.org/` but I could host the generated docs somewhere if that is needed.
>> 
>> <img width="1511" alt="Screenshot 2024-05-06 at 00 07 16" src="https://github.com/openjdk/jdk/assets/96922791/89b92288-9b5e-48ed-8fa1-9342ea43e043">
>> 
>> <img width="1505" alt="Screenshot 2024-05-06 at 00 08 06" src="https://github.com/openjdk/jdk/assets/96922791/9aef08ff-5030-4189-a996-582a7eef849b">
>> 
>> <img width="1050" alt="Screenshot 2024-05-06 at 00 09 03" src="https://github.com/openjdk/jdk/assets/96922791/fdd75a26-0396-4c5e-8f59-a3717b7d7ec8">
>> 
>> 
>> TIA
>
> Nizar Benalla has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Move security classes changes to pr18373

Just curious, what's the rationale for reverting the since tags on security default methods?

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

PR Comment: https://git.openjdk.org/jdk/pull/18954#issuecomment-2096318435

From duke at openjdk.org  Mon May  6 15:41:07 2024
From: duke at openjdk.org (serhiysachkov)
Date: Mon, 6 May 2024 15:41:07 GMT
Subject: RFR: JDK-8331646: Add specific regression leap year tests (Task - P4)
Message-ID: <cB-Q8ihe6DYQTm1WcRvVV3oW8YXtnWH5fmsS1zurwwY=.176d4137-bd3b-445e-a055-c738bd73744c@github.com>

Calendar.add() tests that describe its behavior.

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

Commit messages:
 - Merge remote-tracking branch 'origin/JDK-8331646' into JDK-8331646
 - JDK-8331646 adding tests to validate Calendar.add() for leap year
 - JDK-8331646 Add specific regression leap year tests

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

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

From liach at openjdk.org  Mon May  6 15:41:54 2024
From: liach at openjdk.org (Chen Liang)
Date: Mon, 6 May 2024 15:41:54 GMT
Subject: RFR: 8331724: Refactor j.l.constant implementation to internal
 package [v3]
In-Reply-To: <sCsGUwAF3RvCYkyKuE12w_YjQ3Weh0IcxrLbuCwyeFk=.29f8c6ef-4a9f-47b7-81e5-f61e555e049e@github.com>
References: <_GPUF9d1E6eBKRxP6bEEqA3LSKRJe2GwCRTfVYbDwFU=.cb482785-e7c4-45f7-bd3a-cd32d466a2cb@github.com>
 <sCsGUwAF3RvCYkyKuE12w_YjQ3Weh0IcxrLbuCwyeFk=.29f8c6ef-4a9f-47b7-81e5-f61e555e049e@github.com>
Message-ID: <0Lm3vUpgCJYknOROVZkkjw6HKPgXlPGOdNBv0hHyYng=.801ab18d-dbd7-4704-843c-36b752027606@github.com>

On Mon, 6 May 2024 15:15:36 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> This PR suggests refactoring the implementation classes of java.lang.constant into a new package jdk.internal.constant to enable sharing some trusted static factory methods with users elsewhere in java.base, such as java.lang.invoke and java.lang.classfile. The refactoring also adds some "trusted" methods for use when input is pre-validated, and makes use of them where applicable in the current implementation. There are more changes in the pipeline which will be folded into #17108 or PR'ed once that is integrated. 
>> 
>> There are two optimizations mixed up here. One in `MethodTypeDesc.ofDescriptor`:
>> 
>> Name                                                             (descString) Cnt     Base     Error      Test   Error  Unit  Change
>> MethodTypeDescFactories.ofDescriptor  (Ljava/lang/Object;Ljava/lang/String;)I   6  138,371 ?   0,767   136,939 ? 1,126 ns/op   1,01x (p = 0,000*)
>> MethodTypeDescFactories.ofDescriptor                                      ()V   6   10,528 ?   2,495     4,110 ? 0,047 ns/op   2,56x (p = 0,000*)
>> MethodTypeDescFactories.ofDescriptor ([IJLjava/lang/String;Z)Ljava/util/List;   6  209,390 ?   4,583   196,175 ? 3,211 ns/op   1,07x (p = 0,000*)
>> MethodTypeDescFactories.ofDescriptor                    ()[Ljava/lang/String;   6   36,039 ?   8,684    20,794 ? 1,110 ns/op   1,73x (p = 0,000*)
>> MethodTypeDescFactories.ofDescriptor                                 (..IIJ)V   6  279,139 ?   6,248   187,934 ? 0,857 ns/op   1,49x (p = 0,000*)
>> MethodTypeDescFactories.ofDescriptor                 (.....................).   6 2174,387 ? 132,879  1150,652 ? 3,158 ns/op   1,89x (p = 0,000*)
>>   * = significant
>> 
>> 
>> The other in `ClassDesc::nested`, where to get rid of a simple static method in `ConstantUtils` I ended up speeding up and simplifying the public factory method:
>> 
>> Name                                      Cnt    Base     Error    Test   Error  Unit  Change
>> ClassDescFactories.ReferenceOnly.ofNested   6 209,853 ? 132,525  22,017 ? 0,573 ns/op   9,53x (p = 0,000*)
>>   * = significant
>> 
>> 
>> The optimizations could be split out and PRd independently, but I think they are simple enough to include in this refactoring.
>
> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rename ofTrusted to ofValidated, remove accidental module-info exports

Agree with deferring other changes; those are improvements instead of bugs so no rush.

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

Marked as reviewed by liach (Author).

PR Review: https://git.openjdk.org/jdk/pull/19105#pullrequestreview-2041084654

From jlahoda at openjdk.org  Mon May  6 15:45:54 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Mon, 6 May 2024 15:45:54 GMT
Subject: RFR: 8331535: Incorrect prompt for Console.readLine [v2]
In-Reply-To: <3m2vXDnx0X_2f3aJxt61yStX_9jyuzIjjhhpgGBmm0Q=.9597c9c6-586a-4ad1-ad91-2a7fa779a427@github.com>
References: <IQvUAYG5zj0JqUbWiQiryAuBrtV6jrVCvy9useQZmlc=.a4dd8dfc-e835-4405-83f8-fd1bda8480f6@github.com>
 <3m2vXDnx0X_2f3aJxt61yStX_9jyuzIjjhhpgGBmm0Q=.9597c9c6-586a-4ad1-ad91-2a7fa779a427@github.com>
Message-ID: <iAaeLI0jUBs9VDdPufvV8lNXsrhWdXv7i-FNW60OqOc=.5703f0b4-54e7-4f72-8f44-0c79f21b3fbb@github.com>

On Fri, 3 May 2024 11:20:52 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Jan Lahoda 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.
>
> src/jdk.internal.le/share/classes/jdk/internal/org/jline/JdkConsoleProviderImpl.java line 101:
> 
>> 99:             try {
>> 100:                 initJLineIfNeeded();
>> 101:                 return jline.readLine(fmt.formatted(args).replace("%", "%%"));
> 
> I understand that [JLine interprets `%` in a prompt](https://github.com/openjdk/jdk/blob/4ed38f5ad5f822ab948257ed39717ea919fd32ed/src/jdk.internal.le/share/classes/jdk/internal/org/jline/reader/impl/LineReaderImpl.java#L4050), but are the interpretation rules documented on JLine GitHub page or elsewhere?

There's a description in the javadoc:
https://www.javadoc.io/doc/org.jline/jline/latest/org/jline/reader/LineReader.html

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19081#discussion_r1591196087

From asotona at openjdk.org  Mon May  6 15:59:08 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 6 May 2024 15:59:08 GMT
Subject: RFR: 8331291: java.lang.classfile.Attributes class performs a lot
 of static initializations [v6]
In-Reply-To: <SHIvjbwCWBPERKxlytEsY_O_kEiJbSeEmSusuDwjTIw=.ae8dd21e-a822-476e-9760-dd489532dbf1@github.com>
References: <SHIvjbwCWBPERKxlytEsY_O_kEiJbSeEmSusuDwjTIw=.ae8dd21e-a822-476e-9760-dd489532dbf1@github.com>
Message-ID: <8b638nkCvzhpf1xUCK-KGXVXqeYPwzFkVOJPOFDtyd4=.50d86a2b-a695-49d5-8de6-924b41f507f5@github.com>

> Hi,
> During performance optimization work on Class-File API as JDK lambda generator we found some static initialization killers.
> One of them is `java.lang.classfile.Attributes` with tens of static fields initialized with individual attribute mappers, and common set of all mappers, and static map from attribute names to the mappers.
> 
> I propose to turn all the static fields into lazy-initialized static methods and remove `PREDEFINED_ATTRIBUTES` and `standardAttribute(Utf8Entry name)` static mapping method from the `Attributes` API class.
>  
> Please let me know your comments or objections and please review the [PR](https://github.com/openjdk/jdk/pull/19006) and [CSR](https://bugs.openjdk.org/browse/JDK-8331414), so we can make it into 23.
> 
> Thank you,
> Adam

Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:

  fixed tests

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/19006/files
  - new: https://git.openjdk.org/jdk/pull/19006/files/497dd533..a1a55d71

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

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

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

From asotona at openjdk.org  Mon May  6 15:59:08 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 6 May 2024 15:59:08 GMT
Subject: RFR: 8331291: java.lang.classfile.Attributes class performs a lot
 of static initializations [v4]
In-Reply-To: <FoflkW6Ead7EClZw5ub9wXq1-Rrr392uqsVVSw4m_Wc=.4eb1899f-ce8c-443e-b19b-b9c1ceca99fa@github.com>
References: <SHIvjbwCWBPERKxlytEsY_O_kEiJbSeEmSusuDwjTIw=.ae8dd21e-a822-476e-9760-dd489532dbf1@github.com>
 <OQ_7GvZY9aR_wDxoXfR3ZpnVndRz3_Y4RnuZRKsg2Do=.acfbeec6-2e24-45db-b2b7-8b5aa250a873@github.com>
 <FoflkW6Ead7EClZw5ub9wXq1-Rrr392uqsVVSw4m_Wc=.4eb1899f-ce8c-443e-b19b-b9c1ceca99fa@github.com>
Message-ID: <5agtRoM-ozF1_jEnCOI4j9tvcEJEhul2FSDxHX8hEAE=.d2c1fe74-e84f-4007-9d39-57901b1788e2@github.com>

On Thu, 2 May 2024 14:40:16 GMT, Chen Liang <liach at openjdk.org> wrote:

> On a side note, will we update JEP 466 to include this patch?

I hope so, if we get it into 23 ;)

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

PR Comment: https://git.openjdk.org/jdk/pull/19006#issuecomment-2096378934

From asotona at openjdk.org  Mon May  6 15:59:08 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 6 May 2024 15:59:08 GMT
Subject: RFR: 8331291: java.lang.classfile.Attributes class performs a lot
 of static initializations [v4]
In-Reply-To: <mw-unnDYvbH9Ox6P9hMOH15jUmDkhKO2aizCRc6ulag=.5046d451-ba44-45fa-8c58-3bb9f522078a@github.com>
References: <SHIvjbwCWBPERKxlytEsY_O_kEiJbSeEmSusuDwjTIw=.ae8dd21e-a822-476e-9760-dd489532dbf1@github.com>
 <OQ_7GvZY9aR_wDxoXfR3ZpnVndRz3_Y4RnuZRKsg2Do=.acfbeec6-2e24-45db-b2b7-8b5aa250a873@github.com>
 <mw-unnDYvbH9Ox6P9hMOH15jUmDkhKO2aizCRc6ulag=.5046d451-ba44-45fa-8c58-3bb9f522078a@github.com>
Message-ID: <Z2YZ32knhvjJ7xrQkhfUs7QdjkNPpwNfwyWerQ8ELMA=.b79e63b6-241d-477b-84cb-366c188e8e67@github.com>

On Mon, 6 May 2024 11:16:16 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> FWIW code changes looks good to me. There seems to be a number of tests that still need to be updated to use the new methods instead of the old constants.

Thank you!
Yes, I'm cleaning the tests right now.

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

PR Comment: https://git.openjdk.org/jdk/pull/19006#issuecomment-2096380853

From asotona at openjdk.org  Mon May  6 16:07:26 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 6 May 2024 16:07:26 GMT
Subject: RFR: 8331291: java.lang.classfile.Attributes class performs a lot
 of static initializations [v7]
In-Reply-To: <SHIvjbwCWBPERKxlytEsY_O_kEiJbSeEmSusuDwjTIw=.ae8dd21e-a822-476e-9760-dd489532dbf1@github.com>
References: <SHIvjbwCWBPERKxlytEsY_O_kEiJbSeEmSusuDwjTIw=.ae8dd21e-a822-476e-9760-dd489532dbf1@github.com>
Message-ID: <_5Ike3ZDfok-lU5AItq7mDu80Gme4vvRrmvpovOOXHg=.763c4a63-7dff-49f5-b826-93d727e9f5b9@github.com>

> Hi,
> During performance optimization work on Class-File API as JDK lambda generator we found some static initialization killers.
> One of them is `java.lang.classfile.Attributes` with tens of static fields initialized with individual attribute mappers, and common set of all mappers, and static map from attribute names to the mappers.
> 
> I propose to turn all the static fields into lazy-initialized static methods and remove `PREDEFINED_ATTRIBUTES` and `standardAttribute(Utf8Entry name)` static mapping method from the `Attributes` API class.
>  
> Please let me know your comments or objections and please review the [PR](https://github.com/openjdk/jdk/pull/19006) and [CSR](https://bugs.openjdk.org/browse/JDK-8331414), so we can make it into 23.
> 
> Thank you,
> Adam

Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:

  fixed tests

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/19006/files
  - new: https://git.openjdk.org/jdk/pull/19006/files/a1a55d71..dcbaae85

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

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

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

From jlahoda at openjdk.org  Mon May  6 16:09:19 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Mon, 6 May 2024 16:09:19 GMT
Subject: RFR: 8331535: Incorrect prompt for Console.readLine [v3]
In-Reply-To: <IQvUAYG5zj0JqUbWiQiryAuBrtV6jrVCvy9useQZmlc=.a4dd8dfc-e835-4405-83f8-fd1bda8480f6@github.com>
References: <IQvUAYG5zj0JqUbWiQiryAuBrtV6jrVCvy9useQZmlc=.a4dd8dfc-e835-4405-83f8-fd1bda8480f6@github.com>
Message-ID: <ERRduhiHCZbzJHciDdzX27mVGZdvupV65b2rdFSI6U0=.e8ba81cb-9ff1-4d7e-b4af-00db8c2381de@github.com>

> When JLine reads a line, there may be a prompt provided. However, JLine will not interpret the prompt literally, it will handle `%` specially. As a consequence, doing:
> 
> System.console().readLine("%%s");
> 
> 
> will not print `%s`, as first `String.format` is used, which will convert `%%s` to `%s`, and then JLine will interpret the `%`. The proposed solution is to duplicate the `%`, so that JLine will print it.

Jan Lahoda has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits:

 - Adjusting test as suggested.
 - Merge branch 'master' into JDK-8331535
 - 8331535: Incorrect prompt for Console.readLine
 - Fixing test.
 - Attempting to stabilize the test.
 - Improving test to really test the redirect while stdin is connected to a terminal.
 - Fixing typo.
 - 8330998: System.console() writes to stderr when stdout is redirected

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

Changes: https://git.openjdk.org/jdk/pull/19081/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19081&range=02
  Stats: 210 lines in 3 files changed: 208 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/19081.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19081/head:pull/19081

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

From jlahoda at openjdk.org  Mon May  6 16:09:19 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Mon, 6 May 2024 16:09:19 GMT
Subject: RFR: 8331535: Incorrect prompt for Console.readLine [v2]
In-Reply-To: <01jKa1Vle6swIlyHyAGC9RLlkvKMABNV4gARTNkctb0=.db05c58c-cae1-4860-a41f-542d55b58671@github.com>
References: <IQvUAYG5zj0JqUbWiQiryAuBrtV6jrVCvy9useQZmlc=.a4dd8dfc-e835-4405-83f8-fd1bda8480f6@github.com>
 <3m2vXDnx0X_2f3aJxt61yStX_9jyuzIjjhhpgGBmm0Q=.9597c9c6-586a-4ad1-ad91-2a7fa779a427@github.com>
 <hAmrGczr1ChxLcKOeV62E5Gwa2nMiAW0NqMS9JyaADA=.a7d37721-9fd0-46cc-a8d5-2b5ac5b43c29@github.com>
 <ZyGQrhrrVBjBxbOaTmSMhIdtUm6AgvSE9U3Sg8tBGOM=.651480e9-34d1-4517-baab-a6ddefb16fe5@github.com>
 <-1kM8rbTDNczIqktUIsWDXpreQLTJvqSkEINSVdLJ6g=.3ab5d6c5-dde6-4204-aed2-c4d62b5024ef@github.com>
 <01jKa1Vle6swIlyHyAGC9RLlkvKMABNV4gARTNkctb0=.db05c58c-cae1-4860-a41f-542d55b58671@github.com>
Message-ID: <WY2eBTY7aMvu7EhYydvrXg32tOZBTbih14XsRiK7ydI=.1b7b087e-4879-462c-83b0-ee270b1f08b5@github.com>

On Fri, 3 May 2024 21:59:40 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>>> Ideally, we should have separate tests that make sure that jdk.internal.le is the default impl.
>> 
>> We have a test that checks if `System.console()` returns the correct Console (or null) from the expected module (`test/jdk/java/io/Console/ModuleSelectionTest.java`)
>> 
>>> We should also test this behaviour (i.e. % interpretation) on jdk.internal.io Console impl.
>> 
>> Yeah, that would be helpful.
>
>> We have a test that checks if `System.console()` returns the correct Console (or null) from the expected module (`test/jdk/java/io/Console/ModuleSelectionTest.java`)
>>
> 
> Good; then here we should indeed specify `-Djdk.console=jdk.internal.le`. Initially, I suggested an alternative wording (i.e. "default"), but that's inappropriate. After all, the test in question resides in `test/jdk/jdk/internal/jline`. So it only makes sense that it tests that concrete implementation. 
> 
>> Yeah, that would be helpful.
>>
> 
> I filed a bug: https://bugs.openjdk.org/browse/JDK-8331681

Thanks. I've added `-Djdk.console=jdk.internal.le`, and also added a test for the `java.base`'s console: `test/jdk/java/io/Console/ConsolePromptTest.java`. I can easily remove the latter if this is not a reasonable form. Or I can fix it as needed. Please let me know.

Thanks.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19081#discussion_r1591228737

From szaldana at openjdk.org  Mon May  6 16:30:11 2024
From: szaldana at openjdk.org (Sonia Zaldana Calles)
Date: Mon, 6 May 2024 16:30:11 GMT
Subject: RFR: 8329581: Java launcher no longer prints a stack trace [v8]
In-Reply-To: <Z0pDMIc_XvZhcZdeFsIQUlqI17q5ybj0BnQ9Kl3jwxg=.8f981c46-a8a3-4520-a6e3-79ee7fce0253@github.com>
References: <Z0pDMIc_XvZhcZdeFsIQUlqI17q5ybj0BnQ9Kl3jwxg=.8f981c46-a8a3-4520-a6e3-79ee7fce0253@github.com>
Message-ID: <BioTSJsIDviZzdpu9bC3Fuw_5hN5hP6rocJx_ONHiNI=.391d720b-2f02-469e-9a38-e742c31ad644@github.com>

> Hi folks, 
> 
> This PR aims to fix [JDK-8329581](https://bugs.openjdk.org/browse/JDK-8329581). 
> 
> I think the regression got introduced in [JDK-8315458](https://bugs.openjdk.org/browse/JDK-8315458). 
> 
> In the issue linked above, [LauncherHelper#getMainType](https://github.com/openjdk/jdk/pull/16461/files#diff-108a3a3e3c2d108c8c7f19ea498f641413b7c9239ecd2975a6c27d904c2ba226) got removed to simplify launcher code.
> 
> Previously, we used ```getMainType``` to do the appropriate main method invocation in ```JavaMain```. However, we currently attempt to do all types of main method invocations at the same time [here](https://github.com/openjdk/jdk/blob/master/src/java.base/share/native/libjli/java.c#L623). 
> 
> Note how all of these invocations clear the exception reported with [CHECK_EXCEPTION_FAIL](https://github.com/openjdk/jdk/blob/140f56718bbbfc31bb0c39255c68568fad285a1f/src/java.base/share/native/libjli/java.c#L390). 
> 
> Therefore, if a legitimate exception comes up during one of these invocations, it does not get reported. 
> 
> I propose reintroducing ```LauncherHelper#getMainType``` but I'm looking forward to your suggestions. 
> 
> Cheers, 
> Sonia

Sonia Zaldana Calles has updated the pull request incrementally with one additional commit since the last revision:

  Fixing broken uncaught exception mechanism

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18786/files
  - new: https://git.openjdk.org/jdk/pull/18786/files/ca03ead2..d918d995

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

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

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

From szaldana at openjdk.org  Mon May  6 16:30:11 2024
From: szaldana at openjdk.org (Sonia Zaldana Calles)
Date: Mon, 6 May 2024 16:30:11 GMT
Subject: RFR: 8329581: Java launcher no longer prints a stack trace
In-Reply-To: <VEFKhTxFBk7HkJSCliAagB1y8v4128BXKmbBjIJJnS0=.7b6addf8-e9b3-4cc6-be7a-b7b3d33549a9@github.com>
References: <Z0pDMIc_XvZhcZdeFsIQUlqI17q5ybj0BnQ9Kl3jwxg=.8f981c46-a8a3-4520-a6e3-79ee7fce0253@github.com>
 <61FmMvHyAQXcl_ZWYGEWwLDU7O8a-vdHTlu56rnKzqo=.cd118172-6497-4963-ad3b-b8f865009638@github.com>
 <Nvef5H6yg7TlYjDyCTYh1qTZoZB4B2nYvmV1d6BCnxs=.62b96873-a553-4c95-8a5a-eaf2fb6bc8a2@github.com>
 <JGexro9ukP8dyTCTNxYkhnde73SLC7def5rZBIFIuzg=.9ce10baf-a892-4b85-a570-f614978ef729@github.com>
 <yC-vO8l_RPw8Nz94rBeiKyyq44Fb8xnL0eF6ZHfxmD0=.12c4264c-5268-483d-8808-36f286efec76@github.com>
 <VEFKhTxFBk7HkJSCliAagB1y8v4128BXKmbBjIJJnS0=.7b6addf8-e9b3-4cc6-be7a-b7b3d33549a9@github.com>
Message-ID: <lFMUqvon4-rmacewlDU0HcjaXaGWd93TTCTZHWQnnO8=.a841221c-3fdb-4585-82e0-c7ab67fe2b73@github.com>

On Mon, 6 May 2024 10:21:12 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Hi @mlchung, thanks for the feedback! I?ve pushed the updates.
>> 
>> Just a question about ```NULL_CHECK0```. 
>> 
>> ```NULL_CHECK0``` reports the error message and then the exception is described in ```CHECK_EXCEPTION_LEAVE```. This results in a stack trace that looks like this: 
>> 
>> 
>> Error: A JNI error has occurred, please check your installation and try again
>> Exception in thread "main" java.lang.NoClassDefFoundError: DemoSonia$SomeDependency
>> 	at DemoSonia.<clinit>(DemoSonia.java:3)
>> Caused by: java.lang.ClassNotFoundException: DemoSonia$SomeDependency
>> 	at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:641)
>> 	at java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:188)
>> 	at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:528)
>> 	... 1 more
>> 
>> 
>> 
>> The JNI error message didn?t previously get reported before the regression was introduced, so I just wanted to make sure we were okay with this. 
>> 
>> Looking forward to your comments!
>
> Hello @SoniaZaldana, I don't remember seeing the `java/lang/Thread/UncaughtExceptionsTest` fail before. It's failing in the current PR's GitHub actions job on several platforms. Could you take a look if it's related to the current changes?

Hi @jaikiran, the failures were related to my change. I forgot to check the invocation failed and only trigger ```CHECK_EXCEPTION_LEAVE``` then. I have pushed an update that should fix the issue. Let's see how GHA turns out this time. 

Thanks!

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

PR Comment: https://git.openjdk.org/jdk/pull/18786#issuecomment-2096439688

From szaldana at openjdk.org  Mon May  6 16:38:55 2024
From: szaldana at openjdk.org (Sonia Zaldana Calles)
Date: Mon, 6 May 2024 16:38:55 GMT
Subject: RFR: 8329581: Java launcher no longer prints a stack trace [v8]
In-Reply-To: <BioTSJsIDviZzdpu9bC3Fuw_5hN5hP6rocJx_ONHiNI=.391d720b-2f02-469e-9a38-e742c31ad644@github.com>
References: <Z0pDMIc_XvZhcZdeFsIQUlqI17q5ybj0BnQ9Kl3jwxg=.8f981c46-a8a3-4520-a6e3-79ee7fce0253@github.com>
 <BioTSJsIDviZzdpu9bC3Fuw_5hN5hP6rocJx_ONHiNI=.391d720b-2f02-469e-9a38-e742c31ad644@github.com>
Message-ID: <IavTFEncsAJz41GeYYEGL6ybCjPDTfE4S9Ho-7avV84=.4e58f561-9ea6-4dc4-aa1b-c47d57f259d7@github.com>

On Mon, 6 May 2024 16:30:11 GMT, Sonia Zaldana Calles <szaldana at openjdk.org> wrote:

>> Hi folks, 
>> 
>> This PR aims to fix [JDK-8329581](https://bugs.openjdk.org/browse/JDK-8329581). 
>> 
>> I think the regression got introduced in [JDK-8315458](https://bugs.openjdk.org/browse/JDK-8315458). 
>> 
>> In the issue linked above, [LauncherHelper#getMainType](https://github.com/openjdk/jdk/pull/16461/files#diff-108a3a3e3c2d108c8c7f19ea498f641413b7c9239ecd2975a6c27d904c2ba226) got removed to simplify launcher code.
>> 
>> Previously, we used ```getMainType``` to do the appropriate main method invocation in ```JavaMain```. However, we currently attempt to do all types of main method invocations at the same time [here](https://github.com/openjdk/jdk/blob/master/src/java.base/share/native/libjli/java.c#L623). 
>> 
>> Note how all of these invocations clear the exception reported with [CHECK_EXCEPTION_FAIL](https://github.com/openjdk/jdk/blob/140f56718bbbfc31bb0c39255c68568fad285a1f/src/java.base/share/native/libjli/java.c#L390). 
>> 
>> Therefore, if a legitimate exception comes up during one of these invocations, it does not get reported. 
>> 
>> I propose reintroducing ```LauncherHelper#getMainType``` but I'm looking forward to your suggestions. 
>> 
>> Cheers, 
>> Sonia
>
> Sonia Zaldana Calles has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixing broken uncaught exception mechanism

FYI, I've also re-run all added test cases since making the latest changes and they pass.

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

PR Comment: https://git.openjdk.org/jdk/pull/18786#issuecomment-2096458546

From rriggs at openjdk.org  Mon May  6 16:49:53 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 6 May 2024 16:49:53 GMT
Subject: RFR: JDK-8331646: Add specific regression leap year tests (Task -
 P4)
In-Reply-To: <cB-Q8ihe6DYQTm1WcRvVV3oW8YXtnWH5fmsS1zurwwY=.176d4137-bd3b-445e-a055-c738bd73744c@github.com>
References: <cB-Q8ihe6DYQTm1WcRvVV3oW8YXtnWH5fmsS1zurwwY=.176d4137-bd3b-445e-a055-c738bd73744c@github.com>
Message-ID: <YDCG26Oy3LQrLhYSZRba4rQoyM-b1eqhiaIRfrh17oE=.728aa352-1c95-467a-ae50-2576af7dad64@github.com>

On Fri, 3 May 2024 10:31:14 GMT, serhiysachkov <duke at openjdk.org> wrote:

> Calendar.add() tests that describe its behavior.

The bug report and/or the PR description should describe the change in more detail.
What conditions of the Calendar spec are being tested.  Thanks

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

PR Comment: https://git.openjdk.org/jdk/pull/19082#issuecomment-2096482166

From naoto at openjdk.org  Mon May  6 17:02:56 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 6 May 2024 17:02:56 GMT
Subject: RFR: 8331535: Incorrect prompt for Console.readLine [v3]
In-Reply-To: <ERRduhiHCZbzJHciDdzX27mVGZdvupV65b2rdFSI6U0=.e8ba81cb-9ff1-4d7e-b4af-00db8c2381de@github.com>
References: <IQvUAYG5zj0JqUbWiQiryAuBrtV6jrVCvy9useQZmlc=.a4dd8dfc-e835-4405-83f8-fd1bda8480f6@github.com>
 <ERRduhiHCZbzJHciDdzX27mVGZdvupV65b2rdFSI6U0=.e8ba81cb-9ff1-4d7e-b4af-00db8c2381de@github.com>
Message-ID: <GpFSxVw4pzOmBtUS0m7Jqh6R5ZI2HkTw9Em9u83wRjo=.e80f387e-c9fb-4c22-bc83-5bf52acfff5d@github.com>

On Mon, 6 May 2024 16:09:19 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> When JLine reads a line, there may be a prompt provided. However, JLine will not interpret the prompt literally, it will handle `%` specially. As a consequence, doing:
>> 
>> System.console().readLine("%%s");
>> 
>> 
>> will not print `%s`, as first `String.format` is used, which will convert `%%s` to `%s`, and then JLine will interpret the `%`. The proposed solution is to duplicate the `%`, so that JLine will print it.
>
> Jan Lahoda has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits:
> 
>  - Adjusting test as suggested.
>  - Merge branch 'master' into JDK-8331535
>  - 8331535: Incorrect prompt for Console.readLine
>  - Fixing test.
>  - Attempting to stabilize the test.
>  - Improving test to really test the redirect while stdin is connected to a terminal.
>  - Fixing typo.
>  - 8330998: System.console() writes to stderr when stdout is redirected

Looks good

test/jdk/java/io/Console/ConsolePromptTest.java line 29:

> 27:  * @summary Verify the java.base's console provider handles the prompt correctly.
> 28:  * @library /test/lib
> 29:  * @run main/othervm --limit-modules java.base ConsolePromptTest

It would be helpful if we do another run with `-Djdk.console=java.base` too.

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

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19081#pullrequestreview-2041252866
PR Review Comment: https://git.openjdk.org/jdk/pull/19081#discussion_r1591300205

From naoto at openjdk.org  Mon May  6 17:02:57 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 6 May 2024 17:02:57 GMT
Subject: RFR: 8331535: Incorrect prompt for Console.readLine [v2]
In-Reply-To: <WY2eBTY7aMvu7EhYydvrXg32tOZBTbih14XsRiK7ydI=.1b7b087e-4879-462c-83b0-ee270b1f08b5@github.com>
References: <IQvUAYG5zj0JqUbWiQiryAuBrtV6jrVCvy9useQZmlc=.a4dd8dfc-e835-4405-83f8-fd1bda8480f6@github.com>
 <3m2vXDnx0X_2f3aJxt61yStX_9jyuzIjjhhpgGBmm0Q=.9597c9c6-586a-4ad1-ad91-2a7fa779a427@github.com>
 <hAmrGczr1ChxLcKOeV62E5Gwa2nMiAW0NqMS9JyaADA=.a7d37721-9fd0-46cc-a8d5-2b5ac5b43c29@github.com>
 <ZyGQrhrrVBjBxbOaTmSMhIdtUm6AgvSE9U3Sg8tBGOM=.651480e9-34d1-4517-baab-a6ddefb16fe5@github.com>
 <-1kM8rbTDNczIqktUIsWDXpreQLTJvqSkEINSVdLJ6g=.3ab5d6c5-dde6-4204-aed2-c4d62b5024ef@github.com>
 <01jKa1Vle6swIlyHyAGC9RLlkvKMABNV4gARTNkctb0=.db05c58c-cae1-4860-a41f-542d55b58671@github.com>
 <WY2eBTY7aMvu7EhYydvrXg32tOZBTbih14XsRiK7ydI=.1b7b087e-4879-462c-83b0-ee270b1f08b5@github.com>
Message-ID: <tQQpQMy6HcuNPLk-4ifOXV4XCZVkKHFbYdW8x45TDNQ=.9b0988a9-7670-4416-a008-2e5fc7bf5057@github.com>

On Mon, 6 May 2024 16:05:58 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>>> We have a test that checks if `System.console()` returns the correct Console (or null) from the expected module (`test/jdk/java/io/Console/ModuleSelectionTest.java`)
>>>
>> 
>> Good; then here we should indeed specify `-Djdk.console=jdk.internal.le`. Initially, I suggested an alternative wording (i.e. "default"), but that's inappropriate. After all, the test in question resides in `test/jdk/jdk/internal/jline`. So it only makes sense that it tests that concrete implementation. 
>> 
>>> Yeah, that would be helpful.
>>>
>> 
>> I filed a bug: https://bugs.openjdk.org/browse/JDK-8331681
>
> Thanks. I've added `-Djdk.console=jdk.internal.le`, and also added a test for the `java.base`'s console: `test/jdk/java/io/Console/ConsolePromptTest.java`. I can easily remove the latter if this is not a reasonable form. Or I can fix it as needed. Please let me know.
> 
> Thanks.

For the latter, since you are already at it, I just reassigned the bug to you ?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19081#discussion_r1591302360

From jonathan.gibbons at oracle.com  Mon May  6 17:32:08 2024
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Mon, 6 May 2024 10:32:08 -0700
Subject: RFR: 8330954: Fix remaining `@since` tags in `java.base`
In-Reply-To: <lB0Dn_BunmYuLvChZrBJwTixaGygR-KjbH9ZSXrdCtg=.839003a6-66f1-48ad-abd9-c11bee3092f7@github.com>
References: <fBxLBbMa9El6L2aATjtKyrAjlFRIjh1J7vPx2CbNT5E=.b33e4450-c1dc-4f36-b59b-5d9acb2da2dc@github.com>
 <vRA01DEhQJrMhNKHObCQcbfK3txrr8ntdunTQrq7Zgc=.9277773b-247e-4ab7-be05-f31f41e82fb1@github.com>
 <g7DiPTbqUrIbd5BzlYe2PLRoPB7x9op5fv4nG7RDMiQ=.032eb20f-2766-493a-923c-7890d37d1a66@github.com>
 <TB4RQcdNCyEO6GMRLku-z5b96CBwVrafCYy4ixs0ph4=.ede28460-3079-4367-a065-ce5ef959500e@github.com>
 <lB0Dn_BunmYuLvChZrBJwTixaGygR-KjbH9ZSXrdCtg=.839003a6-66f1-48ad-abd9-c11bee3092f7@github.com>
Message-ID: <28fde546-45e1-46ce-a304-3caf078b7da4@oracle.com>

While `@since` might not be considered a normative part of the 
specification, (it's effectively a cache of derived meta-data) it is 
part of the generated documentation, and as such deserves to be correct.

-- Jon

On 5/5/24 4:33 PM, Pavel Rappo wrote:
> On Mon, 29 Apr 2024 17:46:24 GMT, Nizar Benalla <duke at openjdk.org> wrote:
>
>> Pavel, can I simply change the PR/issue title to be more descriptive? As I want to include the the inherit doc because of the unchecked exceptions, rather than clean this up in a different PR
> I suggest dropping all the changes that are irrelevant to `@since` from this PR, unless you have PRs with similar mixed changes integrated. As far as I know, `@since` is not a normative part of documentation, whereas `@throws` is. So the latter is a bigger change and would require more scrutiny and more area experts during review.
>
> In the future, we might want to have yet another aid/tool: a "`@throws` checker" that finds all overriding methods that do not declare some of the unchecked exceptions that the methods they override do.
>
> -------------
>
> PR Review Comment: https://git.openjdk.org/jdk/pull/18954#discussion_r1583618873

From jlu at openjdk.org  Mon May  6 17:52:07 2024
From: jlu at openjdk.org (Justin Lu)
Date: Mon, 6 May 2024 17:52:07 GMT
Subject: RFR: 8331485: Odd Results when Parsing Scientific Notation with
 Large Exponent [v3]
In-Reply-To: <lTOZ4RbzZFMN0yLrQKGOcMihdTop24YbYJe2h36SodM=.0addc2ad-b0d1-4721-b860-a9395fa14977@github.com>
References: <lTOZ4RbzZFMN0yLrQKGOcMihdTop24YbYJe2h36SodM=.0addc2ad-b0d1-4721-b860-a9395fa14977@github.com>
Message-ID: <mQtNYvouB27yKO29zUb4rOp7ksGv3eWSuPDSzsrsMMo=.a19726b0-f3d8-407f-8505-fe37aec968fe@github.com>

> Please review this PR which corrects an edge case bug for java.text.DecimalFormat that causes incorrect parsing results for strings with very large exponent values.
> 
> When parsing values with large exponents, if the value of the exponent exceeds `Integer.MAX_VALUE`, the parsed value  is equal to 0. If the value of the exponent exceeds `Long.MAX_VALUE`, the parsed value is equal to the mantissa. Both results are confusing and incorrect.
> 
> For example,
> 
> 
> NumberFormat fmt = NumberFormat.getInstance(Locale.US);
> fmt.parse(".1E2147483648"); // returns 0.0
> fmt.parse(".1E9223372036854775808"); // returns 0.1
> // For comparison
> Double.parseDouble(".1E2147483648"); // returns Infinity
> Double.parseDouble(".1E9223372036854775808"); // returns Infinity
> 
> 
> After this change, both parse calls return `Double.POSITIVE_INFINITY` now.

Justin Lu has updated the pull request incrementally with one additional commit since the last revision:

  Address PP for exp > Long.MAX_VALUE + more exp test cases

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/19075/files
  - new: https://git.openjdk.org/jdk/pull/19075/files/bc391f96..25782781

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

  Stats: 41 lines in 4 files changed: 28 ins; 5 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/19075.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19075/head:pull/19075

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

From jlu at openjdk.org  Mon May  6 17:52:07 2024
From: jlu at openjdk.org (Justin Lu)
Date: Mon, 6 May 2024 17:52:07 GMT
Subject: RFR: 8331485: Odd Results when Parsing Scientific Notation with
 Large Exponent [v2]
In-Reply-To: <v4d-Q8WcpPc9a9Ou3IIeat_SZo1NJNE-oM-j5_lqSEA=.67fd6e12-3f1e-413f-a04b-b02814794487@github.com>
References: <lTOZ4RbzZFMN0yLrQKGOcMihdTop24YbYJe2h36SodM=.0addc2ad-b0d1-4721-b860-a9395fa14977@github.com>
 <RkWCGlAEl-DXGMCbPtB8d7YE3F1jo-nhUFBtTOVkw9A=.120e8d1d-c2b1-44d4-9f8a-085a70df254a@github.com>
 <v4d-Q8WcpPc9a9Ou3IIeat_SZo1NJNE-oM-j5_lqSEA=.67fd6e12-3f1e-413f-a04b-b02814794487@github.com>
Message-ID: <H-H2Mf2LPvkoLdTZx2p1i-uxYo9z0hGEuOqdrn2Pyls=.988a252b-dc6c-4ff2-b3cb-e5a8e58caaed@github.com>

On Sun, 5 May 2024 20:51:10 GMT, Axel Hauschulte <duke at openjdk.org> wrote:

>> Justin Lu has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - correct other test comment
>>  - reflect review
>
> Hello, I filed [JDK-8331485](https://bugs.openjdk.org/browse/JDK-8331485). Thank you for addressing this bug so quickly.
> 
> I have a thought/concern regarding the handling of exponents that exceed `Long.MAX_VALUE` in this PR:
> 
>> If the value of the exponent exceeds `Long.MAX_VALUE`, the parsed value is equal to the mantissa. Both results are confusing and incorrect.
>> 
>> For example,
>> 
>> ```
>> NumberFormat fmt = NumberFormat.getInstance(Locale.US);
>> fmt.parse(".1E2147483648"); // returns 0.0
>> fmt.parse(".1E9223372036854775808"); // returns 0.1
>> // For comparison
>> Double.parseDouble(".1E2147483648"); // returns Infinity
>> Double.parseDouble(".1E9223372036854775808"); // returns Infinity
>> ```
> 
> The method [`parse(String, ParsePosition)`](https://docs.oracle.com/en/java/javase/22/docs/api/java.base/java/text/DecimalFormat.html#parse(java.lang.String,java.text.ParsePosition)) uses the [`ParsePosition`](https://docs.oracle.com/en/java/javase/22/docs/api/java.base/java/text/ParsePosition.html) object as an input and output parameter to determine at what position the parsing should start as well as to communicate up to which position the input string has been consumed during the parsing. (This can be very handy if you use different [`Format`](https://docs.oracle.com/en/java/javase/22/docs/api/java.base/java/text/Format.html)s to parse through a string.)
> 
> For example, if there is a method like this
> 
> static void parseNumber(String s) {
>     NumberFormat numberFormat = NumberFormat.getInstance(Locale.US);
>     ParsePosition parsePosition = new ParsePosition(0);
>     Number parseResult = numberFormat.parse(s, parsePosition);
>     System.out.println(STR."numberFormat.parse("{s}") -> {parseResult}; parsePosition: {parsePosition}");
> }
> 
> `parseNumber("0.123E1XYZ")` will parse the provided string from the beginning to position 7, ignoring the letters at the end of the string. The resulting `Double` value is therefore 1.23 and `parsePosition.getIndex()` returns 7.
> 
> Having an exponent that exceeds `Long.MAX_VALUE`, for instance `parseNumber("0.123E9223372036854775808")`, the current implementation of `DecimalFormat` in JDK 22 does the following: Parse the provided string from the beginning to position 5, ignoring the exponent (because it is too long). The resulting `Double` is therefore 0.123 and `parsePosition.getIndex()` returns 5.
> 
> The solution implemented in this PR would produce a parsing result of `Double.POSITIVE_INFINITY`, however, `parsePosition.getIndex()` would sti...

Hi @ahauschulte, thanks for bringing up your concern, that's a good catch.

As you stated, I agree that the latter solution would be the ideal one here. The parse position index should reflect the actual exponent consumed, even if the exponent exceeds `Long.MAX_VALUE`.

In https://github.com/openjdk/jdk/pull/19075/commits/25782781394dc7a2e0c39605515ab14be41649b0, the behavior of parsing such an exponent value should now reflect this.

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

PR Comment: https://git.openjdk.org/jdk/pull/19075#issuecomment-2096592065

From naoto at openjdk.org  Mon May  6 18:00:21 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 6 May 2024 18:00:21 GMT
Subject: RFR: 8329691: Support `nonlikelyScript` parent locale inheritance
Message-ID: <VZl5HzmaaIHFzVj7FDB9gC9MLHZMlZOjObMwiKL7cMI=.fb806a5b-1414-4850-aa50-1da3c9835d16@github.com>

This PR is to implement the `nonlikelyScript` feature that went into CLDR version 45 for migration purposes. In its release note, it states (https://cldr.unicode.org/index/downloads/cldr-45):

Migration
Changes to parentLocales require upgrading implementations that use that element. In particular, they need to support the new nonlikelyScript value, and use the appropriate explicit inheritance for each type of inheritance. The v44 list of locales that inherit directly from root is retained for this release, but will disappear in the future. So implementations should move as quickly as possible to support the new value

For example in `Russian` locales fallback, its likely script is `Cyrl` (Cyrillic). Thus Russian locales with non-likely script, such as 'ru-Latn' (Russian in Latin script) should fallback directly to `root`, bypassing `ru` (Russian). CLDR has explicit parent locales for this nonlikely scripts, such as `zh-Hant` -> `root` already, but the release note suggests this will go away, and JDK needs to logically handle these non-likely script inheritance cases.

To implement this behavior, CLDRConverter build tool now generates the `LocaleDataMetaInfo` for java.base module with the new `likelyScriptMap`, which maps the script to its likely languages. Since the map is big, it is lazily initialized when needed. The map is used at runtime to determine the parent locale fallback based on implicit/explicit nonlikely Script inheritance.

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

Commit messages:
 - cleanup
 - added tests
 - static AVAILABLE_LOCALES
 - initial commit

Changes: https://git.openjdk.org/jdk/pull/19108/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19108&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8329691
  Stats: 287 lines in 5 files changed: 211 ins; 31 del; 45 mod
  Patch: https://git.openjdk.org/jdk/pull/19108.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19108/head:pull/19108

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

From asotona at openjdk.org  Mon May  6 18:24:25 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 6 May 2024 18:24:25 GMT
Subject: RFR: 8331291: java.lang.classfile.Attributes class performs a lot
 of static initializations [v8]
In-Reply-To: <SHIvjbwCWBPERKxlytEsY_O_kEiJbSeEmSusuDwjTIw=.ae8dd21e-a822-476e-9760-dd489532dbf1@github.com>
References: <SHIvjbwCWBPERKxlytEsY_O_kEiJbSeEmSusuDwjTIw=.ae8dd21e-a822-476e-9760-dd489532dbf1@github.com>
Message-ID: <UielWbqtQPeaoAfpuHYPMzn8N6ViEH0T0h6WXHscUrk=.e4d333d7-6ae3-447f-9b5f-d0a77d29c416@github.com>

> Hi,
> During performance optimization work on Class-File API as JDK lambda generator we found some static initialization killers.
> One of them is `java.lang.classfile.Attributes` with tens of static fields initialized with individual attribute mappers, and common set of all mappers, and static map from attribute names to the mappers.
> 
> I propose to turn all the static fields into lazy-initialized static methods and remove `PREDEFINED_ATTRIBUTES` and `standardAttribute(Utf8Entry name)` static mapping method from the `Attributes` API class.
>  
> Please let me know your comments or objections and please review the [PR](https://github.com/openjdk/jdk/pull/19006) and [CSR](https://bugs.openjdk.org/browse/JDK-8331414), so we can make it into 23.
> 
> Thank you,
> Adam

Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:

  fixed tests

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/19006/files
  - new: https://git.openjdk.org/jdk/pull/19006/files/dcbaae85..b4203cfd

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

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

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

From naoto at openjdk.org  Mon May  6 18:24:53 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 6 May 2024 18:24:53 GMT
Subject: RFR: JDK-8331646: Add specific regression leap year tests (Task -
 P4)
In-Reply-To: <cB-Q8ihe6DYQTm1WcRvVV3oW8YXtnWH5fmsS1zurwwY=.176d4137-bd3b-445e-a055-c738bd73744c@github.com>
References: <cB-Q8ihe6DYQTm1WcRvVV3oW8YXtnWH5fmsS1zurwwY=.176d4137-bd3b-445e-a055-c738bd73744c@github.com>
Message-ID: <HoZ2cDmZ90Rxi1oeF8h1OmqCKcktUdXh24kwJ5NJRrA=.10f78f41-c4fd-4fc6-a890-0576ff07fee9@github.com>

On Fri, 3 May 2024 10:31:14 GMT, serhiysachkov <duke at openjdk.org> wrote:

> Calendar.add() tests that describe its behavior.

I would prefer those test values are parametrized.

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

PR Review: https://git.openjdk.org/jdk/pull/19082#pullrequestreview-2041403213

From vromero at openjdk.org  Mon May  6 18:35:57 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Mon, 6 May 2024 18:35:57 GMT
Subject: RFR: 8331291: java.lang.classfile.Attributes class performs a lot
 of static initializations [v7]
In-Reply-To: <_5Ike3ZDfok-lU5AItq7mDu80Gme4vvRrmvpovOOXHg=.763c4a63-7dff-49f5-b826-93d727e9f5b9@github.com>
References: <SHIvjbwCWBPERKxlytEsY_O_kEiJbSeEmSusuDwjTIw=.ae8dd21e-a822-476e-9760-dd489532dbf1@github.com>
 <_5Ike3ZDfok-lU5AItq7mDu80Gme4vvRrmvpovOOXHg=.763c4a63-7dff-49f5-b826-93d727e9f5b9@github.com>
Message-ID: <HmW_Opxo8HWyQLHzH61A1hbov-A70OoegYj74XvBTzQ=.0fed9c34-acc1-4b70-980c-e2a4d7e25146@github.com>

On Mon, 6 May 2024 16:07:26 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> Hi,
>> During performance optimization work on Class-File API as JDK lambda generator we found some static initialization killers.
>> One of them is `java.lang.classfile.Attributes` with tens of static fields initialized with individual attribute mappers, and common set of all mappers, and static map from attribute names to the mappers.
>> 
>> I propose to turn all the static fields into lazy-initialized static methods and remove `PREDEFINED_ATTRIBUTES` and `standardAttribute(Utf8Entry name)` static mapping method from the `Attributes` API class.
>>  
>> Please let me know your comments or objections and please review the [PR](https://github.com/openjdk/jdk/pull/19006) and [CSR](https://bugs.openjdk.org/browse/JDK-8331414), so we can make it into 23.
>> 
>> Thank you,
>> Adam
>
> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fixed tests

lgtm

src/java.base/share/classes/java/lang/classfile/Attributes.java line 28:

> 26: 
> 27: import java.lang.classfile.attribute.*;
> 28: import jdk.internal.classfile.impl.AbstractAttributeMapper.*;

the second star import is probably unnecessary

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

Marked as reviewed by vromero (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19006#pullrequestreview-2041378994
PR Review Comment: https://git.openjdk.org/jdk/pull/19006#discussion_r1591377928

From naoto at openjdk.org  Mon May  6 18:37:54 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 6 May 2024 18:37:54 GMT
Subject: RFR: 8331485: Odd Results when Parsing Scientific Notation with
 Large Exponent [v3]
In-Reply-To: <mQtNYvouB27yKO29zUb4rOp7ksGv3eWSuPDSzsrsMMo=.a19726b0-f3d8-407f-8505-fe37aec968fe@github.com>
References: <lTOZ4RbzZFMN0yLrQKGOcMihdTop24YbYJe2h36SodM=.0addc2ad-b0d1-4721-b860-a9395fa14977@github.com>
 <mQtNYvouB27yKO29zUb4rOp7ksGv3eWSuPDSzsrsMMo=.a19726b0-f3d8-407f-8505-fe37aec968fe@github.com>
Message-ID: <KAvJSQbPSigxXkz3VevhOnIGGST7b4MM_RnoDncj6WE=.65993d86-4f12-4c13-9a20-646a5b1939e1@github.com>

On Mon, 6 May 2024 17:52:07 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please review this PR which corrects an edge case bug for java.text.DecimalFormat that causes incorrect parsing results for strings with very large exponent values.
>> 
>> When parsing values with large exponents, if the value of the exponent exceeds `Integer.MAX_VALUE`, the parsed value  is equal to 0. If the value of the exponent exceeds `Long.MAX_VALUE`, the parsed value is equal to the mantissa. Both results are confusing and incorrect.
>> 
>> For example,
>> 
>> 
>> NumberFormat fmt = NumberFormat.getInstance(Locale.US);
>> fmt.parse(".1E2147483648"); // returns 0.0
>> fmt.parse(".1E9223372036854775808"); // returns 0.1
>> // For comparison
>> Double.parseDouble(".1E2147483648"); // returns Infinity
>> Double.parseDouble(".1E9223372036854775808"); // returns Infinity
>> 
>> 
>> After this change, both parse calls return `Double.POSITIVE_INFINITY` now.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address PP for exp > Long.MAX_VALUE + more exp test cases

test/jdk/java/text/Format/DecimalFormat/LargeExponentsTest.java line 57:

> 55:     @ParameterizedTest
> 56:     @MethodSource({"largeExponentValues", "smallExponentValues", "bugReportValues", "edgeCases"})
> 57:     public void overflowTest(String parseString, Double expectedValue) {

Since this is a regression test, it may be better having both 1-arg parse() and 2-arg parse() tested separately, instead of replacing.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19075#discussion_r1591405570

From duke at openjdk.org  Mon May  6 18:38:56 2024
From: duke at openjdk.org (ExE Boss)
Date: Mon, 6 May 2024 18:38:56 GMT
Subject: RFR: 8329581: Java launcher no longer prints a stack trace [v8]
In-Reply-To: <BioTSJsIDviZzdpu9bC3Fuw_5hN5hP6rocJx_ONHiNI=.391d720b-2f02-469e-9a38-e742c31ad644@github.com>
References: <Z0pDMIc_XvZhcZdeFsIQUlqI17q5ybj0BnQ9Kl3jwxg=.8f981c46-a8a3-4520-a6e3-79ee7fce0253@github.com>
 <BioTSJsIDviZzdpu9bC3Fuw_5hN5hP6rocJx_ONHiNI=.391d720b-2f02-469e-9a38-e742c31ad644@github.com>
Message-ID: <Dke1wF0ofBuajRJYr57uQ9c2hQ0eYz28lNvx8ucDbGs=.75bb5657-5aa0-41c4-b6b9-84562b8b53ef@github.com>

On Mon, 6 May 2024 16:30:11 GMT, Sonia Zaldana Calles <szaldana at openjdk.org> wrote:

>> Hi folks, 
>> 
>> This PR aims to fix [JDK-8329581](https://bugs.openjdk.org/browse/JDK-8329581). 
>> 
>> I think the regression got introduced in [JDK-8315458](https://bugs.openjdk.org/browse/JDK-8315458). 
>> 
>> In the issue linked above, [LauncherHelper#getMainType](https://github.com/openjdk/jdk/pull/16461/files#diff-108a3a3e3c2d108c8c7f19ea498f641413b7c9239ecd2975a6c27d904c2ba226) got removed to simplify launcher code.
>> 
>> Previously, we used ```getMainType``` to do the appropriate main method invocation in ```JavaMain```. However, we currently attempt to do all types of main method invocations at the same time [here](https://github.com/openjdk/jdk/blob/master/src/java.base/share/native/libjli/java.c#L623). 
>> 
>> Note how all of these invocations clear the exception reported with [CHECK_EXCEPTION_FAIL](https://github.com/openjdk/jdk/blob/140f56718bbbfc31bb0c39255c68568fad285a1f/src/java.base/share/native/libjli/java.c#L390). 
>> 
>> Therefore, if a legitimate exception comes up during one of these invocations, it does not get reported. 
>> 
>> I propose reintroducing ```LauncherHelper#getMainType``` but I'm looking forward to your suggestions. 
>> 
>> Cheers, 
>> Sonia
>
> Sonia Zaldana Calles has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixing broken uncaught exception mechanism

src/java.base/share/native/libjli/java.c line 639:

> 637:        } else {
> 638:             ret = invokeInstanceMainWithArgs(env, mainClass, mainArgs);
> 639:        }

**Nit:** Wrong?indentation[^1]:
Suggestion:

        if (noArgMain) {
            ret = invokeInstanceMainWithoutArgs(env, mainClass);
        } else {
            ret = invokeInstanceMainWithArgs(env, mainClass, mainArgs);
        }


[^1]: (this?is?one of?the?reasons I?hate when?spaces are?used to?indent?things)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18786#discussion_r1591407476

From asotona at openjdk.org  Mon May  6 18:46:54 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 6 May 2024 18:46:54 GMT
Subject: RFR: 8331291: java.lang.classfile.Attributes class performs a lot
 of static initializations [v7]
In-Reply-To: <HmW_Opxo8HWyQLHzH61A1hbov-A70OoegYj74XvBTzQ=.0fed9c34-acc1-4b70-980c-e2a4d7e25146@github.com>
References: <SHIvjbwCWBPERKxlytEsY_O_kEiJbSeEmSusuDwjTIw=.ae8dd21e-a822-476e-9760-dd489532dbf1@github.com>
 <_5Ike3ZDfok-lU5AItq7mDu80Gme4vvRrmvpovOOXHg=.763c4a63-7dff-49f5-b826-93d727e9f5b9@github.com>
 <HmW_Opxo8HWyQLHzH61A1hbov-A70OoegYj74XvBTzQ=.0fed9c34-acc1-4b70-980c-e2a4d7e25146@github.com>
Message-ID: <2mvx1CG4RndVRqr8H_uypWn0S97bZ1qXXTWvVFsESz0=.23f7434a-d6ea-4208-9d49-d03f07c9e9b3@github.com>

On Mon, 6 May 2024 18:07:06 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fixed tests
>
> src/java.base/share/classes/java/lang/classfile/Attributes.java line 28:
> 
>> 26: 
>> 27: import java.lang.classfile.attribute.*;
>> 28: import jdk.internal.classfile.impl.AbstractAttributeMapper.*;
> 
> the second star import is probably unnecessary

Thank you for the review!
All the holders/mappers implementations are AbstractAttributeMapper inner classes.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19006#discussion_r1591416140

From prappo at openjdk.org  Mon May  6 18:53:52 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Mon, 6 May 2024 18:53:52 GMT
Subject: RFR: 8331535: Incorrect prompt for Console.readLine [v2]
In-Reply-To: <tQQpQMy6HcuNPLk-4ifOXV4XCZVkKHFbYdW8x45TDNQ=.9b0988a9-7670-4416-a008-2e5fc7bf5057@github.com>
References: <IQvUAYG5zj0JqUbWiQiryAuBrtV6jrVCvy9useQZmlc=.a4dd8dfc-e835-4405-83f8-fd1bda8480f6@github.com>
 <3m2vXDnx0X_2f3aJxt61yStX_9jyuzIjjhhpgGBmm0Q=.9597c9c6-586a-4ad1-ad91-2a7fa779a427@github.com>
 <hAmrGczr1ChxLcKOeV62E5Gwa2nMiAW0NqMS9JyaADA=.a7d37721-9fd0-46cc-a8d5-2b5ac5b43c29@github.com>
 <ZyGQrhrrVBjBxbOaTmSMhIdtUm6AgvSE9U3Sg8tBGOM=.651480e9-34d1-4517-baab-a6ddefb16fe5@github.com>
 <-1kM8rbTDNczIqktUIsWDXpreQLTJvqSkEINSVdLJ6g=.3ab5d6c5-dde6-4204-aed2-c4d62b5024ef@github.com>
 <01jKa1Vle6swIlyHyAGC9RLlkvKMABNV4gARTNkctb0=.db05c58c-cae1-4860-a41f-542d55b58671@github.com>
 <WY2eBTY7aMvu7EhYydvrXg32tOZBTbih14XsRiK7ydI=.1b7b087e-4879-462c-83b0-ee270b1f08b5@github.com>
 <tQQpQMy6HcuNPLk-4ifOXV4XCZVkKHFbYdW8x45TDNQ=.9b0988a9-7670-4416-a008-2e5fc7bf5057@github.com>
Message-ID: <R6pynt0VTor0C4QwhVvr-Fvw7MLsxD69ATMd3mXCjAw=.7dcb4e0a-f54d-4a06-a197-2fcb38bbfb8e@github.com>

On Mon, 6 May 2024 16:59:40 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> For the latter, since you are already at it, I just reassigned the bug to you ?

@lahodaj, since a test for 8331681 is added to this PR, I'd suggest you do this: `/issue add 8331681`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19081#discussion_r1591423527

From jlu at openjdk.org  Mon May  6 18:55:25 2024
From: jlu at openjdk.org (Justin Lu)
Date: Mon, 6 May 2024 18:55:25 GMT
Subject: RFR: 8331485: Odd Results when Parsing Scientific Notation with
 Large Exponent [v4]
In-Reply-To: <lTOZ4RbzZFMN0yLrQKGOcMihdTop24YbYJe2h36SodM=.0addc2ad-b0d1-4721-b860-a9395fa14977@github.com>
References: <lTOZ4RbzZFMN0yLrQKGOcMihdTop24YbYJe2h36SodM=.0addc2ad-b0d1-4721-b860-a9395fa14977@github.com>
Message-ID: <sa4s6HxjAPnjvfPhnzAQQp3Ia5_lXHcSIqtIm-0BNbA=.bf554e84-0019-46d6-b8ef-3ee8852ac11d@github.com>

> Please review this PR which corrects an edge case bug for java.text.DecimalFormat that causes incorrect parsing results for strings with very large exponent values.
> 
> When parsing values with large exponents, if the value of the exponent exceeds `Integer.MAX_VALUE`, the parsed value  is equal to 0. If the value of the exponent exceeds `Long.MAX_VALUE`, the parsed value is equal to the mantissa. Both results are confusing and incorrect.
> 
> For example,
> 
> 
> NumberFormat fmt = NumberFormat.getInstance(Locale.US);
> fmt.parse(".1E2147483648"); // returns 0.0
> fmt.parse(".1E9223372036854775808"); // returns 0.1
> // For comparison
> Double.parseDouble(".1E2147483648"); // returns Infinity
> Double.parseDouble(".1E9223372036854775808"); // returns Infinity
> 
> 
> After this change, both parse calls return `Double.POSITIVE_INFINITY` now.

Justin Lu has updated the pull request incrementally with one additional commit since the last revision:

  Check both parse methods

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/19075/files
  - new: https://git.openjdk.org/jdk/pull/19075/files/25782781..17a3b3aa

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

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

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

From asotona at openjdk.org  Mon May  6 18:56:59 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 6 May 2024 18:56:59 GMT
Subject: RFR: 8320396: Class-File API ClassModel::verify should include
 checks from hotspot/share/classfile/classFileParser.cpp [v4]
In-Reply-To: <qPSb3Xaw2eNwYqG7vbfWfKbvS0doeN1yG8Uvh1dkhCE=.366c0ba1-26c5-463e-9b26-f0d9428879ea@github.com>
References: <0a66asWcJ4_zBrjmReA18BZmsovN1ZeJRRSAPZDMZmo=.5bada03f-d88d-46cd-962d-c1e42c3048c1@github.com>
 <qPSb3Xaw2eNwYqG7vbfWfKbvS0doeN1yG8Uvh1dkhCE=.366c0ba1-26c5-463e-9b26-f0d9428879ea@github.com>
Message-ID: <EkwfNzoEpEY4UGgWR2XgiUiOQ0a8MdSO_8RWF0JwJLQ=.9cab58cd-c12b-407e-90c2-a17f2b3eaa7d@github.com>

On Thu, 2 May 2024 10:30:06 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> ClassFile API `jdk.internal.classfile.verifier.VerifierImpl` performed only bytecode-level class verification.
>> This patch adds `jdk.internal.classfile.verifier.ParserVerifier` with additional class checks inspired by `hotspot/share/classfile/classFileParser.cpp`.
>> 
>> Also new `VerifierSelfTest::testParserVerifier` has been added.
>> 
>> Please review.
>> 
>> Thanks,
>> Adam
>
> Adam Sotona has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 28 commits:
> 
>  - Merge branch 'master' into JDK-8320396-verifier-extension
>  - added references to jvms
>  - Merge remote-tracking branch 'openjdk/master' into JDK-8320396-verifier-extension
>  - work in progress
>  - work in progress
>  - work in progress
>  - work in progress
>  - work in progress
>  - removed string templates from test
>  - work in progress
>  - ... and 18 more: https://git.openjdk.org/jdk/compare/ae82405f...3ebc780a

The patch also includes a `ClassPrinterImpl` fix to support duplicate attributes.

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

PR Comment: https://git.openjdk.org/jdk/pull/16809#issuecomment-2096696963

From szaldana at openjdk.org  Mon May  6 19:06:10 2024
From: szaldana at openjdk.org (Sonia Zaldana Calles)
Date: Mon, 6 May 2024 19:06:10 GMT
Subject: RFR: 8329581: Java launcher no longer prints a stack trace [v9]
In-Reply-To: <Z0pDMIc_XvZhcZdeFsIQUlqI17q5ybj0BnQ9Kl3jwxg=.8f981c46-a8a3-4520-a6e3-79ee7fce0253@github.com>
References: <Z0pDMIc_XvZhcZdeFsIQUlqI17q5ybj0BnQ9Kl3jwxg=.8f981c46-a8a3-4520-a6e3-79ee7fce0253@github.com>
Message-ID: <krgANOmUJpt38cg16YhdXnUibxgX4shajEyWnMF79Hc=.e2dba0cc-8085-4efd-a300-d9c7f771510b@github.com>

> Hi folks, 
> 
> This PR aims to fix [JDK-8329581](https://bugs.openjdk.org/browse/JDK-8329581). 
> 
> I think the regression got introduced in [JDK-8315458](https://bugs.openjdk.org/browse/JDK-8315458). 
> 
> In the issue linked above, [LauncherHelper#getMainType](https://github.com/openjdk/jdk/pull/16461/files#diff-108a3a3e3c2d108c8c7f19ea498f641413b7c9239ecd2975a6c27d904c2ba226) got removed to simplify launcher code.
> 
> Previously, we used ```getMainType``` to do the appropriate main method invocation in ```JavaMain```. However, we currently attempt to do all types of main method invocations at the same time [here](https://github.com/openjdk/jdk/blob/master/src/java.base/share/native/libjli/java.c#L623). 
> 
> Note how all of these invocations clear the exception reported with [CHECK_EXCEPTION_FAIL](https://github.com/openjdk/jdk/blob/140f56718bbbfc31bb0c39255c68568fad285a1f/src/java.base/share/native/libjli/java.c#L390). 
> 
> Therefore, if a legitimate exception comes up during one of these invocations, it does not get reported. 
> 
> I propose reintroducing ```LauncherHelper#getMainType``` but I'm looking forward to your suggestions. 
> 
> Cheers, 
> Sonia

Sonia Zaldana Calles has updated the pull request incrementally with one additional commit since the last revision:

  Fixing indentation
  
  Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18786/files
  - new: https://git.openjdk.org/jdk/pull/18786/files/d918d995..9b67fd86

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

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

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

From pminborg at openjdk.org  Mon May  6 19:38:59 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 6 May 2024 19:38:59 GMT
Subject: RFR: 8316493: Remove the caching fields in AbstractMap [v11]
In-Reply-To: <4tW3v7m0W_M4bmmLcywMRC5Gm26VhCt6pb16Bg7idTA=.c85a1df3-2208-439a-ac82-e9d16c537196@github.com>
References: <DpNRZsCvDmDfEZ0X-xTKRnwpr3vhgmFTr9IWoveGFbs=.bf85bf6c-97eb-44af-977b-b9909956fa95@github.com>
 <4tW3v7m0W_M4bmmLcywMRC5Gm26VhCt6pb16Bg7idTA=.c85a1df3-2208-439a-ac82-e9d16c537196@github.com>
Message-ID: <PybRyTNQVdD6bYiAb6Thb6LTVBMNkH8SJnnGNjzGHBU=.c4496ffc-7588-4d77-b549-6f6966789661@github.com>

On Fri, 10 Nov 2023 08:17:22 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR outlines a solution for making immutable maps `@ValueBased` by removing cacheing of certain values in `AbstractMap`.
>> 
>> By removing these caching fields in `AbstractMap`, we can make the immutable maps `@ValueBased` and at the same time, performance is likely improved because the JVM is probably able to optimize away object creation anyway via escape analysis. Also, all maps will occupy less space as we get rid of a number of objects and references stored for each map.
>> 
>> We need to benchmark this solution to better understand its implications.
>
> Per Minborg has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 14 commits:
> 
>  - Merge branch 'master' into vb-map2
>  - Fix formatting
>  - Remove caching in TreeMap
>  - Remove caching from CHM and CSLM
>  - Move back clone to original position
>  - Reintroduce AbstractMap::clone
>  - Add 'fresh' to implSpec
>  - Remove AbstractMap::clone
>  - Merge master
>  - Merge branch 'master' into vb-map2
>  - ... and 4 more: https://git.openjdk.org/jdk/compare/9cce9fe0...b1bfcd17

Keep alive

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

PR Comment: https://git.openjdk.org/jdk/pull/15614#issuecomment-2096767172

From duke at openjdk.org  Mon May  6 19:50:55 2024
From: duke at openjdk.org (Axel Hauschulte)
Date: Mon, 6 May 2024 19:50:55 GMT
Subject: RFR: 8331485: Odd Results when Parsing Scientific Notation with
 Large Exponent [v4]
In-Reply-To: <sa4s6HxjAPnjvfPhnzAQQp3Ia5_lXHcSIqtIm-0BNbA=.bf554e84-0019-46d6-b8ef-3ee8852ac11d@github.com>
References: <lTOZ4RbzZFMN0yLrQKGOcMihdTop24YbYJe2h36SodM=.0addc2ad-b0d1-4721-b860-a9395fa14977@github.com>
 <sa4s6HxjAPnjvfPhnzAQQp3Ia5_lXHcSIqtIm-0BNbA=.bf554e84-0019-46d6-b8ef-3ee8852ac11d@github.com>
Message-ID: <EymS36r8IN-xgYl5Uz3DIza34wpnxlnnF3fsZA2bang=.6a0c933a-3688-4944-9dd3-229004e770b0@github.com>

On Mon, 6 May 2024 18:55:25 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please review this PR which corrects an edge case bug for java.text.DecimalFormat that causes incorrect parsing results for strings with very large exponent values.
>> 
>> When parsing values with large exponents, if the value of the exponent exceeds `Integer.MAX_VALUE`, the parsed value  is equal to 0. If the value of the exponent exceeds `Long.MAX_VALUE`, the parsed value is equal to the mantissa. Both results are confusing and incorrect.
>> 
>> For example,
>> 
>> 
>> NumberFormat fmt = NumberFormat.getInstance(Locale.US);
>> fmt.parse(".1E2147483648"); // returns 0.0
>> fmt.parse(".1E9223372036854775808"); // returns 0.1
>> // For comparison
>> Double.parseDouble(".1E2147483648"); // returns Infinity
>> Double.parseDouble(".1E9223372036854775808"); // returns Infinity
>> 
>> 
>> After this change, both parse calls return `Double.POSITIVE_INFINITY` now.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Check both parse methods

test/jdk/java/text/Format/DecimalFormat/LargeExponentsTest.java line 150:

> 148:                 // Long.MIN_VALUE
> 149:                 Arguments.of("1.23E-9223372036854775808", 0.0)
> 150:         );

I would suggest adding one more test case to the edge cases:

Arguments.of("0.0123E-2147483648", 0.0)

This will test the adjustment of the `digits.decimalAt` field for an exponent that is within the range of integer, but due to the mantissa not being in its standardized form an overflow will occure non the less.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19075#discussion_r1591480295

From naoto at openjdk.org  Mon May  6 20:01:14 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 6 May 2024 20:01:14 GMT
Subject: RFR: 8330276: Console methods with explicit Locale [v3]
In-Reply-To: <GT275XVwYlYL3PhYwOTQ_-HwKqp9QYUeIzEIeJKEwkQ=.9a7faf08-8637-45a3-97bd-fd58756a6711@github.com>
References: <GT275XVwYlYL3PhYwOTQ_-HwKqp9QYUeIzEIeJKEwkQ=.9a7faf08-8637-45a3-97bd-fd58756a6711@github.com>
Message-ID: <ayIrpchOReTkcPND-iRPjbSXtKlqHyamDsuEQGSbYnU=.66710878-eedd-435c-b2a4-42bdcad9ca39@github.com>

> Proposing new overloaded methods in `java.io.Console` class that explicitly take a `Locale` argument. Existing methods rely on the default locale, so the users won't be able to format their prompts/outputs in a certain locale explicitly.

Naoto Sato has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision:

 - Addresses a CSR review comment
 - Merge branch 'master' into JDK-8330276-Console-with-explicit-Locale
 - Addressed review comments
 - Not using System.err
 - spacing
 - initial commit

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18923/files
  - new: https://git.openjdk.org/jdk/pull/18923/files/7884cfe3..29ff6063

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

  Stats: 33162 lines in 1907 files changed: 14282 ins; 12249 del; 6631 mod
  Patch: https://git.openjdk.org/jdk/pull/18923.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18923/head:pull/18923

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

From liach at openjdk.org  Mon May  6 20:58:21 2024
From: liach at openjdk.org (Chen Liang)
Date: Mon, 6 May 2024 20:58:21 GMT
Subject: RFR: 8331744: java.lang.classfile.TypeKind improvements
Message-ID: <_x31CU5mODg3NGaRGzI5HdNdcjsKmqWb1TA7KZnZcFg=.43ce5ba3-71e7-42e5-a531-c3b609d0aafb@github.com>

A peek into TypeKind during the research for #19105 reveals that TypeKind has a few issues:
1. Name mismatch for `newarraycode` and `fromNewArrayCode`: Renamed both to use "newarray code"
2. `fromDescriptor` can throw IOOBE if the input string is empty: changed to throw IAE and added tests.
3. `from(Class)` can be slow due to descriptor computation: added benchmark, will share result in next comment (as it may change with code changes).

The first 2 changes involves API changes, and a CSR has been created. Requesting @asotona for a review.

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

Commit messages:
 - whitespace
 - 8331744: java.lang.classfile.TypeKind improvements

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

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

From liach at openjdk.org  Mon May  6 20:58:21 2024
From: liach at openjdk.org (Chen Liang)
Date: Mon, 6 May 2024 20:58:21 GMT
Subject: RFR: 8331744: java.lang.classfile.TypeKind improvements
In-Reply-To: <_x31CU5mODg3NGaRGzI5HdNdcjsKmqWb1TA7KZnZcFg=.43ce5ba3-71e7-42e5-a531-c3b609d0aafb@github.com>
References: <_x31CU5mODg3NGaRGzI5HdNdcjsKmqWb1TA7KZnZcFg=.43ce5ba3-71e7-42e5-a531-c3b609d0aafb@github.com>
Message-ID: <_5ACaNG0EFsUZqiaqaT_3Zc7Irh6RFfaRwvpXQEqGCI=.4f0419d6-68cc-4e33-9e3c-05d3af0be2ca@github.com>

On Mon, 6 May 2024 20:48:05 GMT, Chen Liang <liach at openjdk.org> wrote:

> A peek into TypeKind during the research for #19105 reveals that TypeKind has a few issues:
> 1. Name mismatch for `newarraycode` and `fromNewArrayCode`: Renamed both to use "newarray code"
> 2. `fromDescriptor` can throw IOOBE if the input string is empty: changed to throw IAE and added tests.
> 3. `from(Class)` can be slow due to descriptor computation: added benchmark, will share result in next comment (as it may change with code changes).
> 
> The first 2 changes involves API changes, and a CSR has been created. Requesting @asotona for a review.

The initial benchmark results:

Base:

Benchmark                        (type)  Mode  Cnt     Score    Error  Units
TypeKindBench.fromClassDescs  PRIMITIVE  avgt    6   124.948 ?  3.414  ns/op
TypeKindBench.fromClassDescs  REFERENCE  avgt    6    73.142 ?  1.405  ns/op
TypeKindBench.fromClasses     PRIMITIVE  avgt    6   228.539 ?  8.942  ns/op
TypeKindBench.fromClasses     REFERENCE  avgt    6  2104.329 ? 48.242  ns/op

Head:

Benchmark                        (type)  Mode  Cnt    Score   Error  Units
TypeKindBench.fromClassDescs  PRIMITIVE  avgt    6  128.039 ? 4.121  ns/op
TypeKindBench.fromClassDescs  REFERENCE  avgt    6   58.395 ? 1.197  ns/op
TypeKindBench.fromClasses     PRIMITIVE  avgt    6  228.113 ? 4.167  ns/op
TypeKindBench.fromClasses     REFERENCE  avgt    6   16.450 ? 0.315  ns/op


Visual: https://jmh.morethan.io/?gists=ceaeae3775585034817f54b9010a16e3,80570ce8b74ec5a2dffc48c116899aa6

Seems checking `isPrimitive` is always faster than checking the initial char of the descriptor string, so both ClassDesc and Class versions benefit from the `isPrimitive` fast path while the primitive paths don't see significant slowdowns. Of course the Class version benefits more as it avoids computing descriptor strings altogether.

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

PR Comment: https://git.openjdk.org/jdk/pull/19109#issuecomment-2096895115

From redestad at openjdk.org  Mon May  6 21:45:52 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Mon, 6 May 2024 21:45:52 GMT
Subject: RFR: 8331744: java.lang.classfile.TypeKind improvements
In-Reply-To: <_x31CU5mODg3NGaRGzI5HdNdcjsKmqWb1TA7KZnZcFg=.43ce5ba3-71e7-42e5-a531-c3b609d0aafb@github.com>
References: <_x31CU5mODg3NGaRGzI5HdNdcjsKmqWb1TA7KZnZcFg=.43ce5ba3-71e7-42e5-a531-c3b609d0aafb@github.com>
Message-ID: <TQ_wyCJZCuE9XmeEtGwMEu1GdkvJv0cgTmnapMnyg7Q=.29b47702-7441-413b-84fb-5527fa6945b9@github.com>

On Mon, 6 May 2024 20:48:05 GMT, Chen Liang <liach at openjdk.org> wrote:

> A peek into TypeKind during the research for #19105 reveals that TypeKind has a few issues:
> 1. Name mismatch for `newarraycode` and `fromNewArrayCode`: Renamed both to use "newarray code"
> 2. `fromDescriptor` can throw IOOBE if the input string is empty: changed to throw IAE and added tests.
> 3. `from(Class)` can be slow due to descriptor computation: added benchmark, will share result in next comment (as it may change with code changes).
> 
> The first 2 changes involves API changes, and a CSR has been created. Requesting @asotona for a review.

test/micro/org/openjdk/bench/java/lang/classfile/TypeKindBench.java line 52:

> 50: @Warmup(iterations = 3, time = 2)
> 51: @Measurement(iterations = 6, time = 1)
> 52: @Fork(1)

Suggestion:

@Fork(jvmArgsAppend = "--enable-preview", value = 1)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19109#discussion_r1591587643

From prappo at openjdk.org  Mon May  6 21:50:37 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Mon, 6 May 2024 21:50:37 GMT
Subject: RFR: 8305457: Implement java.io.IO
Message-ID: <w2msiw_qaMEIJS3s9D4bg8pFbz5WIF0KdP6Mm-XFjLI=.85b2020b-8c46-4bac-8a69-4975b068f2ff@github.com>

Please review this PR which introduces the `java.io.IO` top-level class and three methods to `java.io.Console` for [Implicitly Declared Classes and Instance Main Methods (Third Preview)].

This PR has been obtained as `git merge --squash` of a now obsolete [draft PR].

[Implicitly Declared Classes and Instance Main Methods (Third Preview)]: https://bugs.openjdk.org/browse/JDK-8323335
[draft PR]: https://github.com/openjdk/jdk/pull/18921

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

Commit messages:
 - Initial commit

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

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

From redestad at openjdk.org  Mon May  6 22:02:52 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Mon, 6 May 2024 22:02:52 GMT
Subject: RFR: 8331744: java.lang.classfile.TypeKind improvements
In-Reply-To: <_x31CU5mODg3NGaRGzI5HdNdcjsKmqWb1TA7KZnZcFg=.43ce5ba3-71e7-42e5-a531-c3b609d0aafb@github.com>
References: <_x31CU5mODg3NGaRGzI5HdNdcjsKmqWb1TA7KZnZcFg=.43ce5ba3-71e7-42e5-a531-c3b609d0aafb@github.com>
Message-ID: <qcjm8jbc4KR0BIXycBkVPSwGcODhcRBpbw40Wm8j86I=.13c85d1f-8fe8-46c7-ac1f-f88de65ef74a@github.com>

On Mon, 6 May 2024 20:48:05 GMT, Chen Liang <liach at openjdk.org> wrote:

> A peek into TypeKind during the research for #19105 reveals that TypeKind has a few issues:
> 1. Name mismatch for `newarraycode` and `fromNewArrayCode`: Renamed both to use "newarray code"
> 2. `fromDescriptor` can throw IOOBE if the input string is empty: changed to throw IAE and added tests.
> 3. `from(Class)` can be slow due to descriptor computation: added benchmark, will share result in next comment (as it may change with code changes).
> 
> The first 2 changes involves API changes, and a CSR has been created. Requesting @asotona for a review.

Leaning on `TypeDescriptor.OfField::isPrimitive` presents an opportunity: override `isPrimitive` in `PrimitiveClassDescImpl` and `ReferenceClassDescImpl` to return `true` and `false` respectively: 


Name                            (type) Cnt    Base    Error     Test    Error  Unit  Change
TypeKindBench.fromClassDescs PRIMITIVE   6 199,765 ?  3,370  205,531 ?  2,632 ns/op   0,97x (p = 0,000*)
TypeKindBench.fromClassDescs REFERENCE   6  75,018 ?  1,113   25,925 ?  1,145 ns/op   2,89x (p = 0,000*)
TypeKindBench.fromClasses    PRIMITIVE   6 344,477 ? 46,310  366,135 ? 54,955 ns/op   0,94x (p = 0,066 )
TypeKindBench.fromClasses    REFERENCE   6  23,338 ?  0,467   23,183 ?  1,357 ns/op   1,01x (p = 0,484 )
  * = significant


Interestingly this has a tiny regression for the primitive case - in this micro. Probably an effect of the default `descriptor.length() == 1` implementation acting as a sort of prefetch the value we'll switch on (`descriptor.charAt(0)`) down this path. Only overriding for `ReferenceClassDescImpl` is neutral, but maybe that's overfitting:


Name                            (type) Cnt    Base    Error     Test    Error  Unit  Change
TypeKindBench.fromClassDescs PRIMITIVE   6 199,765 ?  3,370  196,203 ?  2,469 ns/op   1,02x (p = 0,000*)
TypeKindBench.fromClassDescs REFERENCE   6  75,018 ?  1,113   25,311 ?  0,138 ns/op   2,96x (p = 0,000*)
TypeKindBench.fromClasses    PRIMITIVE   6 344,477 ? 46,310  325,336 ? 12,203 ns/op   1,06x (p = 0,035 )
TypeKindBench.fromClasses    REFERENCE   6  23,338 ?  0,467   23,462 ?  3,239 ns/op   0,99x (p = 0,805 )
  * = significant

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

PR Comment: https://git.openjdk.org/jdk/pull/19109#issuecomment-2096996186

From sviswanathan at openjdk.org  Mon May  6 22:43:57 2024
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Mon, 6 May 2024 22:43:57 GMT
Subject: RFR: 8320448: Accelerate IndexOf using AVX2 [v19]
In-Reply-To: <eQ4OBFrF8JlDJ1h9awTDOc0kfCc37IlL5vdqtuaqls0=.8f00616d-08e1-4f28-a7a5-5095116d2595@github.com>
References: <uWi4QxH31hL93771gkl_GgvP0m84IRSoR_1Yi8hD17E=.bc6ed458-7081-4c3f-9348-f59358fa05a4@github.com>
 <eQ4OBFrF8JlDJ1h9awTDOc0kfCc37IlL5vdqtuaqls0=.8f00616d-08e1-4f28-a7a5-5095116d2595@github.com>
Message-ID: <8Y-nIHc8vfB1X_hp3tpqqqgpCzu6dAt6BBIP_zc4Q70=.c9a48c68-8c14-4af9-8357-ab50e62a5fd3@github.com>

On Sat, 4 May 2024 19:35:21 GMT, Scott Gibbons <sgibbons at openjdk.org> wrote:

>> Re-write the IndexOf code without the use of the pcmpestri instruction, only using AVX2 instructions.  This change accelerates String.IndexOf on average 1.3x for AVX2.  The benchmark numbers:
>> 
>> 
>> Benchmark	                                               Score		Latest		
>> StringIndexOf.advancedWithMediumSub   343.573		317.934		0.925375393x
>> StringIndexOf.advancedWithShortSub1	  1039.081		1053.96		1.014319384x
>> StringIndexOf.advancedWithShortSub2	      55.828		110.541		1.980027943x
>> StringIndexOf.constantPattern	                9.361		11.906		1.271872663x
>> StringIndexOf.searchCharLongSuccess	        4.216		4.218		1.000474383x
>> StringIndexOf.searchCharMediumSuccess	3.133		3.216		1.02649218x
>> StringIndexOf.searchCharShortSuccess	3.76		        3.761		1.000265957x
>> StringIndexOf.success	                                9.186		9.713		1.057369911x
>> StringIndexOf.successBig	                      14.341		46.343		3.231504079x
>> StringIndexOfChar.latin1_AVX2_String	  6220.918		12154.52		1.953814533x
>> StringIndexOfChar.latin1_AVX2_char	  5503.556		5540.044		1.006629895x
>> StringIndexOfChar.latin1_SSE4_String	  6978.854		6818.689		0.977049957x
>> StringIndexOfChar.latin1_SSE4_char	  5657.499		5474.624		0.967675646x
>> StringIndexOfChar.latin1_Short_String	  7132.541		6863.359		0.962260014x
>> StringIndexOfChar.latin1_Short_char	16013.389	      16162.437		1.009307711x
>> StringIndexOfChar.latin1_mixed_String	  7386.123	      14771.622		1.999915517x
>> StringIndexOfChar.latin1_mixed_char	  9901.671		9782.245		0.987938803
>
> Scott Gibbons has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rearrange; add lambdas for clarity

src/hotspot/cpu/x86/macroAssembler_x86.cpp line 1174:

> 1172: // Alignment specifying the maximum number of allowed bytes to pad.
> 1173: // If padding > max, no padding is inserted.
> 1174: void MacroAssembler::p2align(int modulus, int maxbytes) {

We could pass offset() as an argument to p2align. Basically have three arguments to p2align(modulus, target, maxbytes). Also maybe rename p2align as align then?

src/hotspot/cpu/x86/stubGenerator_x86_64_string.cpp line 208:

> 206:   ////////////////////////////////////////////////////////////////////////////////////////
> 207:   ////////////////////////////////////////////////////////////////////////////////////////
> 208:   if (VM_Version::supports_avx2()) {  // AVX2 version

Instead of the if check here, it would be better to do an assert here:
assert (VM_Version::supports_avx2(), "Needs AVX2 support");

src/hotspot/cpu/x86/stubGenerator_x86_64_string.cpp line 233:

> 231:     ////////////////////////////////////////////////////////////////////////////////////////
> 232:     ////////////////////////////////////////////////////////////////////////////////////////
> 233: 

This comment can go right before the method start. Also good to add in the comment the native function parameters.

src/hotspot/cpu/x86/stubGenerator_x86_64_string.cpp line 238:

> 236:     const Register needle       = rdx;
> 237:     const Register needle_len   = rcx;
> 238: 

This is the calling convention on Linux. How is windows platform handled?

src/hotspot/cpu/x86/stubGenerator_x86_64_string.cpp line 260:

> 258:     // const XMMRegister save_rcx  = xmm11;
> 259:     // const XMMRegister save_r8   = xmm12;
> 260: 

This could be removed?

src/hotspot/cpu/x86/stubGenerator_x86_64_string.cpp line 279:

> 277:     fnptrs[isLL   ? StrIntrinsicNode::LL
> 278:            : isUU ? StrIntrinsicNode::UU
> 279:                   : StrIntrinsicNode::UL] = __ pc();

Could this not be simplified as:
 fnptrs[ae] = __ pc();

src/hotspot/share/opto/library_call.cpp line 1263:

> 1261:   if (result != nullptr) {
> 1262:     // The result is index relative to from_index if substring was found, -1 otherwise.
> 1263:     // Generate code which will fold into cmove.

Any reason to remove this comment?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1591547667
PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1591612417
PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1591613215
PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1591617528
PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1591607921
PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1591618222
PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1591554296

From duke at openjdk.org  Mon May  6 22:47:23 2024
From: duke at openjdk.org (Volodymyr Paprotski)
Date: Mon, 6 May 2024 22:47:23 GMT
Subject: RFR: 8329538: Accelerate P256 on x86_64 using Montgomery intrinsic
 [v6]
In-Reply-To: <hanRK4GzOkFV8kG1gZRy8Br53trw4-Tu6G6uO8nsFuk=.d5bf723a-f683-4759-ac9e-4a58cb430f03@github.com>
References: <hanRK4GzOkFV8kG1gZRy8Br53trw4-Tu6G6uO8nsFuk=.d5bf723a-f683-4759-ac9e-4a58cb430f03@github.com>
Message-ID: <Ed5ND7II8dfwGPnZri3_MV3C38LqTp94VRJqz0zWN7Y=.b99da9a1-30f4-4793-b777-d04ee7c25285@github.com>

> Performance. Before:
> 
> Benchmark                        (algorithm)  (dataSize)  (keyLength)  (provider)   Mode  Cnt     Score    Error  Units
> SignatureBench.ECDSA.sign    SHA256withECDSA        1024          256              thrpt    3  6443.934 ?  6.491  ops/s
> SignatureBench.ECDSA.sign    SHA256withECDSA       16384          256              thrpt    3  6152.979 ?  4.954  ops/s
> SignatureBench.ECDSA.verify  SHA256withECDSA        1024          256              thrpt    3  1895.410 ? 36.979  ops/s
> SignatureBench.ECDSA.verify  SHA256withECDSA       16384          256              thrpt    3  1878.955 ? 45.487  ops/s
> Benchmark                                            (algorithm)  (keyLength)  (kpgAlgorithm)  (provider)   Mode  Cnt     Score    Error  Units
> o.o.b.j.c.full.KeyAgreementBench.EC.generateSecret          ECDH          256              EC              thrpt    3  1357.810 ? 26.584  ops/s
> o.o.b.j.c.small.KeyAgreementBench.EC.generateSecret         ECDH          256              EC              thrpt    3  1352.119 ? 23.547  ops/s
> Benchmark                          (isMontBench)   Mode  Cnt     Score    Error  Units
> PolynomialP256Bench.benchMultiply          false  thrpt    3  1746.126 ? 10.970  ops/s
> 
> Performance, no intrinsic:
> 
> Benchmark                        (algorithm)  (dataSize)  (keyLength)  (provider)   Mode  Cnt     Score     Error  Units
> SignatureBench.ECDSA.sign    SHA256withECDSA        1024          256              thrpt    3  6529.839 ?  42.420  ops/s
> SignatureBench.ECDSA.sign    SHA256withECDSA       16384          256              thrpt    3  6199.747 ? 133.566  ops/s
> SignatureBench.ECDSA.verify  SHA256withECDSA        1024          256              thrpt    3  1973.676 ?  54.071  ops/s
> SignatureBench.ECDSA.verify  SHA256withECDSA       16384          256              thrpt    3  1932.127 ?  35.920  ops/s
> Benchmark                                            (algorithm)  (keyLength)  (kpgAlgorithm)  (provider)   Mode  Cnt     Score    Error  Units
> o.o.b.j.c.full.KeyAgreementBench.EC.generateSecret          ECDH          256              EC              thrpt    3  1355.788 ? 29.858  ops/s
> o.o.b.j.c.small.KeyAgreementBench.EC.generateSecret         ECDH          256              EC              thrpt    3  1346.523 ? 28.722  ops/s
> Benchmark                          (isMontBench)   Mode  Cnt     Score    Error  Units
> PolynomialP256Bench.benchMultiply           true  thrpt    3  1919.574 ? 10.591  ops/s
> 
> Performance, **with intrinsics*...

Volodymyr Paprotski has updated the pull request incrementally with one additional commit since the last revision:

  Use AffinePoint to exit Montgomery domain
  
  Style notes:
  Affine.equals()
      - Mismatched fields only appear to be used from testing, perhaps should be moved there instead
  Affine.getX(boolean)|getY(boolean)
      - "Passing flag is bad design" - cleanest/performant alternative to several instanceof checks
      - needed to convert Affine to Projective (need to stay in montgomery domain)
  ECOperations.PointMultiplier
     - changes could probably be restored to original (since ProjectivePoint handling no longer required)
     - consider these changes an improvement? (fewer nested classes)
     - was an inner-class but not using inner-class features (i.e. ecOps variable should be converted)

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18583/files
  - new: https://git.openjdk.org/jdk/pull/18583/files/a1984501..8ff243a2

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

  Stats: 268 lines in 7 files changed: 89 ins; 147 del; 32 mod
  Patch: https://git.openjdk.org/jdk/pull/18583.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18583/head:pull/18583

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

From sviswanathan at openjdk.org  Mon May  6 23:21:57 2024
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Mon, 6 May 2024 23:21:57 GMT
Subject: RFR: 8320448: Accelerate IndexOf using AVX2 [v19]
In-Reply-To: <eQ4OBFrF8JlDJ1h9awTDOc0kfCc37IlL5vdqtuaqls0=.8f00616d-08e1-4f28-a7a5-5095116d2595@github.com>
References: <uWi4QxH31hL93771gkl_GgvP0m84IRSoR_1Yi8hD17E=.bc6ed458-7081-4c3f-9348-f59358fa05a4@github.com>
 <eQ4OBFrF8JlDJ1h9awTDOc0kfCc37IlL5vdqtuaqls0=.8f00616d-08e1-4f28-a7a5-5095116d2595@github.com>
Message-ID: <JvETaWJA4KnaZjDzF5e_LX9oUOzHYqHGZtqcjx0NVb4=.db09b2ca-34a0-4997-a9f1-fd985181866c@github.com>

On Sat, 4 May 2024 19:35:21 GMT, Scott Gibbons <sgibbons at openjdk.org> wrote:

>> Re-write the IndexOf code without the use of the pcmpestri instruction, only using AVX2 instructions.  This change accelerates String.IndexOf on average 1.3x for AVX2.  The benchmark numbers:
>> 
>> 
>> Benchmark	                                               Score		Latest		
>> StringIndexOf.advancedWithMediumSub   343.573		317.934		0.925375393x
>> StringIndexOf.advancedWithShortSub1	  1039.081		1053.96		1.014319384x
>> StringIndexOf.advancedWithShortSub2	      55.828		110.541		1.980027943x
>> StringIndexOf.constantPattern	                9.361		11.906		1.271872663x
>> StringIndexOf.searchCharLongSuccess	        4.216		4.218		1.000474383x
>> StringIndexOf.searchCharMediumSuccess	3.133		3.216		1.02649218x
>> StringIndexOf.searchCharShortSuccess	3.76		        3.761		1.000265957x
>> StringIndexOf.success	                                9.186		9.713		1.057369911x
>> StringIndexOf.successBig	                      14.341		46.343		3.231504079x
>> StringIndexOfChar.latin1_AVX2_String	  6220.918		12154.52		1.953814533x
>> StringIndexOfChar.latin1_AVX2_char	  5503.556		5540.044		1.006629895x
>> StringIndexOfChar.latin1_SSE4_String	  6978.854		6818.689		0.977049957x
>> StringIndexOfChar.latin1_SSE4_char	  5657.499		5474.624		0.967675646x
>> StringIndexOfChar.latin1_Short_String	  7132.541		6863.359		0.962260014x
>> StringIndexOfChar.latin1_Short_char	16013.389	      16162.437		1.009307711x
>> StringIndexOfChar.latin1_mixed_String	  7386.123	      14771.622		1.999915517x
>> StringIndexOfChar.latin1_mixed_char	  9901.671		9782.245		0.987938803
>
> Scott Gibbons has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rearrange; add lambdas for clarity

src/hotspot/cpu/x86/stubGenerator_x86_64_string.cpp line 314:

> 312: 
> 313:     // needle_len is in elements, not bytes, for UTF-16
> 314:     __ cmpq(needle_len, isUU ? OPT_NEEDLE_SIZE_MAX / 2 : OPT_NEEDLE_SIZE_MAX);

OPT_NEEDLE_SIZE_MAX is an odd number (set to 5), should that have been an even number?

src/hotspot/cpu/x86/stubGenerator_x86_64_string.cpp line 329:

> 327:     ////////////////////////////////////////////////////////////////////////////////////////
> 328: 
> 329:     __ bind(L_begin);

So far we have handled haystack <= 32 and needle_size <= 5 (?) in bytes. A high level algorithm description here is needed in comments to follow the code below.  A description of what are the various paths in terms of haystack and needle sizes and how to reason the assembly code below and make sure that all the paths are taken care of. Also the abstraction level suddenly changes here to detailed code below instead of methods for the various paths.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1591640551
PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1591646095

From duke at openjdk.org  Mon May  6 23:30:00 2024
From: duke at openjdk.org (Srinivas Vamsi Parasa)
Date: Mon, 6 May 2024 23:30:00 GMT
Subject: RFR: 8266431: Dual-Pivot Quicksort improvements (Radix sort) [v11]
In-Reply-To: <z094CbYeWxVsMZ8s2_54mVC8fD_p67gSGyJxeiTZuVE=.78b39116-a5ad-4f03-ac15-7e3a09dc180e@github.com>
References: <918oCEfFu2JweXfV-afD1l_AGDDuc7dJwAxip-Ze6ZI=.8d5e9692-23db-47e4-9586-99e53b9cfbb6@github.com>
 <i1cu_VA2najjcZHepAbvkWGtVzuLMsdYFKssI5s-TFA=.be96a1ac-1eba-4b7f-bde9-1214082eb6c6@github.com>
 <Gb1pFf-YBbIZdSO-XvQ54xqE5SvNezsl9WSHikEOEJA=.90ccd95f-4a79-4a3e-91a0-23eb83107937@github.com>
 <e8rv_97mAYHGXeRhI8dirZDJsn9ecO2gM91t1LCxnWI=.21859a35-93b8-449c-b4f8-d9dfc0912a7e@github.com>
 <m_FlD1imWi57n0EqQXsrFue-FkO4D1hIbHUI2ph5d6o=.3fcdbf05-7147-4461-8d8e-6947f6f18d62@github.com>
 <C9cdmmBTW6uphtzkL9BdV4DboIuwNF6M-UMnC3xM8vg=.2aa0c11c-cb22-445f-86f6-281c6ab6368c@github.com>
 <-bYhysKjQVb_ZS0I0YutJZ7umfYwbs74rtK6-d2qL9U=.f9981e59-f0c4-48f3-ad7e-5627aad00919@github.com>
 <91Zv361kqKOjCSJPu20-yhKOb4lBIZVyVTm9f79dkcQ=.745c271d-3cb1-4ff3-9d71-5cad85ff4f14@github.com>
 <lAzKoJ7VajYG5E02nRkuqAHsREz3hz7plUFG3bjfwe0=.420af221-7969-4d8f-b9d2-16d2b4fa4cf9@github.com>
 <9q8Gg6DQnrf0HLW3oxwfpoUP9639drr1BIQMc1rxDFo=.eb4ea73c-b632-446a-8d50-b51838f67f69@github.com>
 <NC3E6wpsavqRXUqdgNHh3y26lFSIPXoA0yi
 KcV_2CyI=.391c9553-458a-417f-b86d-2c88dacf7df1@github.com>
 <Kc8tP6_hlFmF_NqcwSHEX6NF9atmoeglRsRFTrLaA5A=.bacb4a7d-26cb-4fdc-8f7b-f883587cd58c@github.com>
 <xrA2rqmjQ-gHGaZ23SQIYZCgda6sHslW2oHIqQxyM2Y=.f4ae4438-78b0-4eb1-b4aa-ed461c31ef1f@github.com>
 <0OkFUL1UCNcLRNh4P2ZdKvMENJgFy8Tz2BA5l2QgDXE=.77152fca-3c03-46a0-9855-bcf1c9b8d152@github.com>
 <hSP68W3vGCfGCOlUCf84DDw0qzt9Z7d-56LKLALocYo=.6c507f84-037d-449f-b4f6-f8c9771e6409@github.com>
 <JS57ADLXmF8NLa8Pn5HNclFkb0nHbOyCguMHquwd_bk=.b34c2b1c-43f5-491e-9965-6bf6f1cce3b0@github.com>
 <ib2mYavPszYymn_Q0H2Ur05M6MhSkpdwL_p6glKqSas=.411442cf-b0ee-4522-94e9-84be3b6ea292@github.com>
 <9_KKkAnzsXHFkj0038AWd5Jk3HTEXe2LQ4mVS88NzBw=.2753397a-5acc-45b6-ade9-e8799b3c6f28@github.com>
 <zbIMwqRuJNsei6zZPM05kn9XbbOm3ygyNmP5Q8_N180=.5a510e21-98fb-44f7-8f22-e93094d5b732@github.com>
 <0_F7PAs-rdVRnktd7oL65mvRxdmr_zBLNG5YVihi9Kg=.8f08c537-9d5b-4606-b9e9-b4bc1a717164@github.com>
 <z094CbYeWxVsMZ8s2_54mVC8fD_p67gSGyJxeiTZuVE=.78b39116-a5ad-4f03-ac15-7e3a09dc180e@
 github.com>
Message-ID: <jd32y3QbyVdNJ3WX995GiSj6RbrVjiK9mpk9SruJDfY=.40eb6b15-8b11-4387-8fab-d95c70fed1da@github.com>

On Tue, 30 Apr 2024 22:01:30 GMT, Vladimir Yaroslavskiy <duke at openjdk.org> wrote:

>> Hi Vladimir (@iaroslavski),
>> 
>> Please see the data below:
>> 
>> Thanks,
>> Vamsi
>> 
>> 
>> 
>> name | builder | size | mode | count | score
>> -- | -- | -- | -- | -- | --
>> b01 | RANDOM | 600 | avg | 325677 | 6.862
>> b01 | RANDOM | 3000 | avg | 52041 | 82.233
>> b01 | RANDOM | 90000 | avg | 1217 | 4456.51
>> b01 | RANDOM | 400000 | avg | 242 | 22923.28
>> b01 | RANDOM | 1000000 | avg | 90 | 60598.84
>> b01 | REPEATED | 600 | avg | 651354 | 1.933
>> b01 | REPEATED | 3000 | avg | 104083 | 13.753
>> b01 | REPEATED | 90000 | avg | 2435 | 723.039
>> b01 | REPEATED | 400000 | avg | 484 | 3084.416
>> b01 | REPEATED | 1000000 | avg | 180 | 8234.428
>> b01 | STAGGER | 600 | avg | 1954062 | 1.005
>> b01 | STAGGER | 3000 | avg | 312251 | 4.945
>> b01 | STAGGER | 90000 | avg | 7305 | 133.126
>> b01 | STAGGER | 400000 | avg | 1453 | 592.144
>> b01 | STAGGER | 1000000 | avg | 542 | 1493.876
>> b01 | SHUFFLE | 600 | avg | 325677 | 5.12
>> b01 | SHUFFLE | 3000 | avg | 52041 | 29.252
>> b01 | SHUFFLE | 90000 | avg | 1217 | 1396.664
>> b01 | SHUFFLE | 400000 | avg | 242 | 5743.489
>> b01 | SHUFFLE | 1000000 | avg | 90 | 15490.81
>> b01_ins | RANDOM | 600 | avg | 325677 | 7.594
>> b01_ins | RANDOM | 3000 | avg | 52041 | 78.631
>> b01_ins | RANDOM | 90000 | avg | 1217 | 4312.511
>> b01_ins | RANDOM | 400000 | avg | 242 | 22108.18
>> b01_ins | RANDOM | 1000000 | avg | 90 | 58467.16
>> b01_ins | REPEATED | 600 | avg | 651354 | 1.569
>> b01_ins | REPEATED | 3000 | avg | 104083 | 11.313
>> b01_ins | REPEATED | 90000 | avg | 2435 | 720.838
>> b01_ins | REPEATED | 400000 | avg | 484 | 3003.673
>> b01_ins | REPEATED | 1000000 | avg | 180 | 8144.944
>> b01_ins | STAGGER | 600 | avg | 1954062 | 0.98
>> b01_ins | STAGGER | 3000 | avg | 312251 | 4.948
>> b01_ins | STAGGER | 90000 | avg | 7305 | 132.909
>> b01_ins | STAGGER | 400000 | avg | 1453 | 592.572
>> b01_ins | STAGGER | 1000000 | avg | 542 | 1492.627
>> b01_ins | SHUFFLE | 600 | avg | 325677 | 4.092
>> b01_ins | SHUFFLE | 3000 | avg | 52041 | 27.138
>> b01_ins | SHUFFLE | 90000 | avg | 1217 | 1304.326
>> b01_ins | SHUFFLE | 400000 | avg | 242 | 5465.745
>> b01_ins | SHUFFLE | 1000000 | avg | 90 | 14585.08
>> b01_mrg | RANDOM | 600 | avg | 325677 | 7.139
>> b01_mrg | RANDOM | 3000 | avg | 52041 | 81.01
>> b01_mrg | RANDOM | 90000 | avg | 1217 | 4266.084
>> b01_mrg | RANDOM | 400000 | avg | 242 | 21937.77
>> b01_mrg | RANDOM | 1000000 | avg | 90 | 58177.72
>> b01_mrg | REPEATED | 600 | avg | 651354 | 1.36
>> b01_mrg | REPEATED | 3000 | avg | 104083 | 9.013
>> b01_mrg | REPEATED ...
>
> Hello Vamsi (@vamsi-parasa),
> 
> Could you please run the new benchmarking to detect the best case
> for Radix sort and parallel sorting?
> 
> What you need is to compile and run JavaBenchmarkHarness:
> 
> javac --patch-module java.base=. -d classes *.java
> java -XX:CompileThreshold=1 -XX:-TieredCompilation --patch-module java.base=classes -cp classes java.util.JavaBenchmarkHarness
> 
> Find the sources there:
> 
> https://github.com/iaroslavski/sorting/blob/master/radixsort/DualPivotQuicksort_b01.java
> https://github.com/iaroslavski/sorting/blob/master/radixsort/DualPivotQuicksort_r30.java
> https://github.com/iaroslavski/sorting/blob/master/radixsort/DualPivotQuicksort_r30_a.java
> https://github.com/iaroslavski/sorting/blob/master/radixsort/DualPivotQuicksort_r30_5.java
> https://github.com/iaroslavski/sorting/blob/master/radixsort/DualPivotQuicksort_r30_11.java
> https://github.com/iaroslavski/sorting/blob/master/radixsort/DualPivotQuicksort_r30_12.java
> https://github.com/iaroslavski/sorting/blob/master/radixsort/DualPivotQuicksort_r30_13.java
> https://github.com/iaroslavski/sorting/blob/master/radixsort/DualPivotQuicksort_r30_14.java
> https://github.com/iaroslavski/sorting/blob/master/radixsort/DualPivotQuicksort_r30_21.java
> https://github.com/iaroslavski/sorting/blob/master/radixsort/DualPivotQuicksort_r30_23.java
> https://github.com/iaroslavski/sorting/blob/master/radixsort/JavaBenchmarkHarness.java
> 
> Thank you,
> Vladimir

Hi Vladimir (@iaroslavski),

Please see the data below.

Thanks,
Vamsi

name | builder | size | mode | count | score
-- | -- | -- | -- | -- | --
b01 | RANDOM | 600 | avg | 325677 | 6.764
b01 | RANDOM | 3000 | avg | 52041 | 77.742
b01 | RANDOM | 90000 | avg | 1217 | 4449.668
b01 | RANDOM | 400000 | avg | 242 | 22764.05
b01 | RANDOM | 1000000 | avg | 90 | 60737.71
b01 | REPEATED | 600 | avg | 651354 | 1.723
b01 | REPEATED | 3000 | avg | 104083 | 12.383
b01 | REPEATED | 90000 | avg | 2435 | 714.451
b01 | REPEATED | 400000 | avg | 484 | 3039.447
b01 | REPEATED | 1000000 | avg | 180 | 8114.503
b01 | SAWTOOTH | 600 | avg | 1954062 | 1.009
b01 | SAWTOOTH | 3000 | avg | 312251 | 4.94
b01 | SAWTOOTH | 90000 | avg | 7305 | 133.192
b01 | SAWTOOTH | 400000 | avg | 1453 | 591.854
b01 | SAWTOOTH | 1000000 | avg | 542 | 1494.252
b01 | STAGGER | 600 | avg | 1954062 | 8.252
b01 | STAGGER | 3000 | avg | 312251 | 10.449
b01 | STAGGER | 90000 | avg | 7305 | 287.811
b01 | STAGGER | 400000 | avg | 1453 | 1288.92
b01 | STAGGER | 1000000 | avg | 542 | 3245.649
b01 | SHUFFLE | 600 | avg | 325677 | 5.199
b01 | SHUFFLE | 3000 | avg | 52041 | 29.734
b01 | SHUFFLE | 90000 | avg | 1217 | 1392.125
b01 | SHUFFLE | 400000 | avg | 242 | 5772.859
b01 | SHUFFLE | 1000000 | avg | 90 | 15483.65
r30 | RANDOM | 600 | avg | 325677 | 4.307
r30 | RANDOM | 3000 | avg | 52041 | 71.438
r30 | RANDOM | 90000 | avg | 1217 | 3971.947
r30 | RANDOM | 400000 | avg | 242 | 19924.32
r30 | RANDOM | 1000000 | avg | 90 | 53671.9
r30 | REPEATED | 600 | avg | 651354 | 1.36
r30 | REPEATED | 3000 | avg | 104083 | 6.415
r30 | REPEATED | 90000 | avg | 2435 | 578.708
r30 | REPEATED | 400000 | avg | 484 | 2488.414
r30 | REPEATED | 1000000 | avg | 180 | 6280.025
r30 | SAWTOOTH | 600 | avg | 1954062 | 0.488
r30 | SAWTOOTH | 3000 | avg | 312251 | 2.409
r30 | SAWTOOTH | 90000 | avg | 7305 | 71.98
r30 | SAWTOOTH | 400000 | avg | 1453 | 343.433
r30 | SAWTOOTH | 1000000 | avg | 542 | 954.287
r30 | STAGGER | 600 | avg | 1954062 | 1.064
r30 | STAGGER | 3000 | avg | 312251 | 4.559
r30 | STAGGER | 90000 | avg | 7305 | 135.383
r30 | STAGGER | 400000 | avg | 1453 | 626.657
r30 | STAGGER | 1000000 | avg | 542 | 1653.92
r30 | SHUFFLE | 600 | avg | 325677 | 2.924
r30 | SHUFFLE | 3000 | avg | 52041 | 18.819
r30 | SHUFFLE | 90000 | avg | 1217 | 1019.036
r30 | SHUFFLE | 400000 | avg | 242 | 4661.484
r30 | SHUFFLE | 1000000 | avg | 90 | 11333.52
r30_a | RANDOM | 600 | avg | 325677 | 4.024
r30_a | RANDOM | 3000 | avg | 52041 | 72.86
r30_a | RANDOM | 90000 | avg | 1217 | 3963.585
r30_a | RANDOM | 400000 | avg | 242 | 19878.02
r30_a | RANDOM | 1000000 | avg | 90 | 53599.07
r30_a | REPEATED | 600 | avg | 651354 | 1.119
r30_a | REPEATED | 3000 | avg | 104083 | 5.738
r30_a | REPEATED | 90000 | avg | 2435 | 605.571
r30_a | REPEATED | 400000 | avg | 484 | 2617.642
r30_a | REPEATED | 1000000 | avg | 180 | 6587.544
r30_a | SAWTOOTH | 600 | avg | 1954062 | 0.481
r30_a | SAWTOOTH | 3000 | avg | 312251 | 2.35
r30_a | SAWTOOTH | 90000 | avg | 7305 | 69.489
r30_a | SAWTOOTH | 400000 | avg | 1453 | 332.138
r30_a | SAWTOOTH | 1000000 | avg | 542 | 924.631
r30_a | STAGGER | 600 | avg | 1954062 | 1.066
r30_a | STAGGER | 3000 | avg | 312251 | 4.502
r30_a | STAGGER | 90000 | avg | 7305 | 133.113
r30_a | STAGGER | 400000 | avg | 1453 | 616.012
r30_a | STAGGER | 1000000 | avg | 542 | 1629.452
r30_a | SHUFFLE | 600 | avg | 325677 | 2.943
r30_a | SHUFFLE | 3000 | avg | 52041 | 18.785
r30_a | SHUFFLE | 90000 | avg | 1217 | 1016.28
r30_a | SHUFFLE | 400000 | avg | 242 | 4674.763
r30_a | SHUFFLE | 1000000 | avg | 90 | 11323.51
r30_5 | RANDOM | 600 | avg | 325677 | 4.079
r30_5 | RANDOM | 3000 | avg | 52041 | 61.894
r30_5 | RANDOM | 90000 | avg | 1217 | 3880.556
r30_5 | RANDOM | 400000 | avg | 242 | 19471.78
r30_5 | RANDOM | 1000000 | avg | 90 | 52061.85
r30_5 | REPEATED | 600 | avg | 651354 | 1.156
r30_5 | REPEATED | 3000 | avg | 104083 | 5.88
r30_5 | REPEATED | 90000 | avg | 2435 | 600.195
r30_5 | REPEATED | 400000 | avg | 484 | 2636.961
r30_5 | REPEATED | 1000000 | avg | 180 | 6630.523
r30_5 | SAWTOOTH | 600 | avg | 1954062 | 0.526
r30_5 | SAWTOOTH | 3000 | avg | 312251 | 2.577
r30_5 | SAWTOOTH | 90000 | avg | 7305 | 77.253
r30_5 | SAWTOOTH | 400000 | avg | 1453 | 365.896
r30_5 | SAWTOOTH | 1000000 | avg | 542 | 1010.129
r30_5 | STAGGER | 600 | avg | 1954062 | 1.109
r30_5 | STAGGER | 3000 | avg | 312251 | 4.72
r30_5 | STAGGER | 90000 | avg | 7305 | 140.695
r30_5 | STAGGER | 400000 | avg | 1453 | 649.93
r30_5 | STAGGER | 1000000 | avg | 542 | 1710.388
r30_5 | SHUFFLE | 600 | avg | 325677 | 2.916
r30_5 | SHUFFLE | 3000 | avg | 52041 | 17.57
r30_5 | SHUFFLE | 90000 | avg | 1217 | 999.372
r30_5 | SHUFFLE | 400000 | avg | 242 | 4632.94
r30_5 | SHUFFLE | 1000000 | avg | 90 | 11221.4
p_b01 | RANDOM | 600 | avg | 325677 | 7.311
p_b01 | RANDOM | 3000 | avg | 52041 | 81.881
p_b01 | RANDOM | 90000 | avg | 1217 | 651.777
p_b01 | RANDOM | 400000 | avg | 242 | 2686.92
p_b01 | RANDOM | 1000000 | avg | 90 | 6909.259
p_b01 | REPEATED | 600 | avg | 651354 | 1.115
p_b01 | REPEATED | 3000 | avg | 104083 | 8.601
p_b01 | REPEATED | 90000 | avg | 2435 | 253.17
p_b01 | REPEATED | 400000 | avg | 484 | 1013.256
p_b01 | REPEATED | 1000000 | avg | 180 | 2461.695
p_b01 | SAWTOOTH | 600 | avg | 1954062 | 1.111
p_b01 | SAWTOOTH | 3000 | avg | 312251 | 5.296
p_b01 | SAWTOOTH | 90000 | avg | 7305 | 65.937
p_b01 | SAWTOOTH | 400000 | avg | 1453 | 187.196
p_b01 | SAWTOOTH | 1000000 | avg | 542 | 496.051
p_b01 | STAGGER | 600 | avg | 1954062 | 8.965
p_b01 | STAGGER | 3000 | avg | 312251 | 10.49
p_b01 | STAGGER | 90000 | avg | 7305 | 117.15
p_b01 | STAGGER | 400000 | avg | 1453 | 390.489
p_b01 | STAGGER | 1000000 | avg | 542 | 918.804
p_b01 | SHUFFLE | 600 | avg | 325677 | 5.13
p_b01 | SHUFFLE | 3000 | avg | 52041 | 29.409
p_b01 | SHUFFLE | 90000 | avg | 1217 | 276.471
p_b01 | SHUFFLE | 400000 | avg | 242 | 904.745
p_b01 | SHUFFLE | 1000000 | avg | 90 | 2029.081
p_r30 | RANDOM | 600 | avg | 325677 | 4.302
p_r30 | RANDOM | 3000 | avg | 52041 | 73.18
p_r30 | RANDOM | 90000 | avg | 1217 | 327.108
p_r30 | RANDOM | 400000 | avg | 242 | 1240.55
p_r30 | RANDOM | 1000000 | avg | 90 | 3006.935
p_r30 | REPEATED | 600 | avg | 651354 | 1.174
p_r30 | REPEATED | 3000 | avg | 104083 | 5.825
p_r30 | REPEATED | 90000 | avg | 2435 | 247.699
p_r30 | REPEATED | 400000 | avg | 484 | 1037.895
p_r30 | REPEATED | 1000000 | avg | 180 | 2490.975
p_r30 | SAWTOOTH | 600 | avg | 1954062 | 0.516
p_r30 | SAWTOOTH | 3000 | avg | 312251 | 2.546
p_r30 | SAWTOOTH | 90000 | avg | 7305 | 57.041
p_r30 | SAWTOOTH | 400000 | avg | 1453 | 214.214
p_r30 | SAWTOOTH | 1000000 | avg | 542 | 452.047
p_r30 | STAGGER | 600 | avg | 1954062 | 1.16
p_r30 | STAGGER | 3000 | avg | 312251 | 5.1
p_r30 | STAGGER | 90000 | avg | 7305 | 83.434
p_r30 | STAGGER | 400000 | avg | 1453 | 234.202
p_r30 | STAGGER | 1000000 | avg | 542 | 598.642
p_r30 | SHUFFLE | 600 | avg | 325677 | 2.962
p_r30 | SHUFFLE | 3000 | avg | 52041 | 19.513
p_r30 | SHUFFLE | 90000 | avg | 1217 | 145.782
p_r30 | SHUFFLE | 400000 | avg | 242 | 762.491
p_r30 | SHUFFLE | 1000000 | avg | 90 | 1632.244
p_r30_a | RANDOM | 600 | avg | 325677 | 4.31
p_r30_a | RANDOM | 3000 | avg | 52041 | 72.917
p_r30_a | RANDOM | 90000 | avg | 1217 | 330.67
p_r30_a | RANDOM | 400000 | avg | 242 | 1240.887
p_r30_a | RANDOM | 1000000 | avg | 90 | 3026.496
p_r30_a | REPEATED | 600 | avg | 651354 | 1.055
p_r30_a | REPEATED | 3000 | avg | 104083 | 4.977
p_r30_a | REPEATED | 90000 | avg | 2435 | 245.71
p_r30_a | REPEATED | 400000 | avg | 484 | 1029.01
p_r30_a | REPEATED | 1000000 | avg | 180 | 2450.782
p_r30_a | SAWTOOTH | 600 | avg | 1954062 | 0.518
p_r30_a | SAWTOOTH | 3000 | avg | 312251 | 2.554
p_r30_a | SAWTOOTH | 90000 | avg | 7305 | 54.796
p_r30_a | SAWTOOTH | 400000 | avg | 1453 | 218.293
p_r30_a | SAWTOOTH | 1000000 | avg | 542 | 462.904
p_r30_a | STAGGER | 600 | avg | 1954062 | 1.165
p_r30_a | STAGGER | 3000 | avg | 312251 | 5.109
p_r30_a | STAGGER | 90000 | avg | 7305 | 84.191
p_r30_a | STAGGER | 400000 | avg | 1453 | 234.556
p_r30_a | STAGGER | 1000000 | avg | 542 | 599.561
p_r30_a | SHUFFLE | 600 | avg | 325677 | 2.931
p_r30_a | SHUFFLE | 3000 | avg | 52041 | 18.613
p_r30_a | SHUFFLE | 90000 | avg | 1217 | 143.293
p_r30_a | SHUFFLE | 400000 | avg | 242 | 756.034
p_r30_a | SHUFFLE | 1000000 | avg | 90 | 1665.63
p_r30_11 | RANDOM | 600 | avg | 325677 | 3.998
p_r30_11 | RANDOM | 3000 | avg | 52041 | 73.103
p_r30_11 | RANDOM | 90000 | avg | 1217 | 454.389
p_r30_11 | RANDOM | 400000 | avg | 242 | 1366.088
p_r30_11 | RANDOM | 1000000 | avg | 90 | 3157.081
p_r30_11 | REPEATED | 600 | avg | 651354 | 1.143
p_r30_11 | REPEATED | 3000 | avg | 104083 | 5.701
p_r30_11 | REPEATED | 90000 | avg | 2435 | 183.205
p_r30_11 | REPEATED | 400000 | avg | 484 | 551.786
p_r30_11 | REPEATED | 1000000 | avg | 180 | 1189.609
p_r30_11 | SAWTOOTH | 600 | avg | 1954062 | 0.616
p_r30_11 | SAWTOOTH | 3000 | avg | 312251 | 3.066
p_r30_11 | SAWTOOTH | 90000 | avg | 7305 | 87.311
p_r30_11 | SAWTOOTH | 400000 | avg | 1453 | 241.364
p_r30_11 | SAWTOOTH | 1000000 | avg | 542 | 526.347
p_r30_11 | STAGGER | 600 | avg | 1954062 | 1.425
p_r30_11 | STAGGER | 3000 | avg | 312251 | 6.505
p_r30_11 | STAGGER | 90000 | avg | 7305 | 90.483
p_r30_11 | STAGGER | 400000 | avg | 1453 | 256.743
p_r30_11 | STAGGER | 1000000 | avg | 542 | 594.534
p_r30_11 | SHUFFLE | 600 | avg | 325677 | 2.913
p_r30_11 | SHUFFLE | 3000 | avg | 52041 | 19.555
p_r30_11 | SHUFFLE | 90000 | avg | 1217 | 207.037
p_r30_11 | SHUFFLE | 400000 | avg | 242 | 503.478
p_r30_11 | SHUFFLE | 1000000 | avg | 90 | 996.047
p_r30_12 | RANDOM | 600 | avg | 325677 | 4
p_r30_12 | RANDOM | 3000 | avg | 52041 | 76.019
p_r30_12 | RANDOM | 90000 | avg | 1217 | 444.935
p_r30_12 | RANDOM | 400000 | avg | 242 | 1355.532
p_r30_12 | RANDOM | 1000000 | avg | 90 | 3130.203
p_r30_12 | REPEATED | 600 | avg | 651354 | 1.154
p_r30_12 | REPEATED | 3000 | avg | 104083 | 5.6
p_r30_12 | REPEATED | 90000 | avg | 2435 | 184.476
p_r30_12 | REPEATED | 400000 | avg | 484 | 538.166
p_r30_12 | REPEATED | 1000000 | avg | 180 | 1176.462
p_r30_12 | SAWTOOTH | 600 | avg | 1954062 | 0.616
p_r30_12 | SAWTOOTH | 3000 | avg | 312251 | 3.063
p_r30_12 | SAWTOOTH | 90000 | avg | 7305 | 86.103
p_r30_12 | SAWTOOTH | 400000 | avg | 1453 | 240.422
p_r30_12 | SAWTOOTH | 1000000 | avg | 542 | 539.458
p_r30_12 | STAGGER | 600 | avg | 1954062 | 1.425
p_r30_12 | STAGGER | 3000 | avg | 312251 | 6.517
p_r30_12 | STAGGER | 90000 | avg | 7305 | 89.936
p_r30_12 | STAGGER | 400000 | avg | 1453 | 256.393
p_r30_12 | STAGGER | 1000000 | avg | 542 | 596.727
p_r30_12 | SHUFFLE | 600 | avg | 325677 | 2.918
p_r30_12 | SHUFFLE | 3000 | avg | 52041 | 20.201
p_r30_12 | SHUFFLE | 90000 | avg | 1217 | 208.518
p_r30_12 | SHUFFLE | 400000 | avg | 242 | 504.957
p_r30_12 | SHUFFLE | 1000000 | avg | 90 | 1005.81
p_r30_13 | RANDOM | 600 | avg | 325677 | 4.106
p_r30_13 | RANDOM | 3000 | avg | 52041 | 73.26
p_r30_13 | RANDOM | 90000 | avg | 1217 | 447.057
p_r30_13 | RANDOM | 400000 | avg | 242 | 1377.538
p_r30_13 | RANDOM | 1000000 | avg | 90 | 3189.496
p_r30_13 | REPEATED | 600 | avg | 651354 | 1.274
p_r30_13 | REPEATED | 3000 | avg | 104083 | 6.386
p_r30_13 | REPEATED | 90000 | avg | 2435 | 183.082
p_r30_13 | REPEATED | 400000 | avg | 484 | 549.427
p_r30_13 | REPEATED | 1000000 | avg | 180 | 1191.464
p_r30_13 | SAWTOOTH | 600 | avg | 1954062 | 0.607
p_r30_13 | SAWTOOTH | 3000 | avg | 312251 | 3.013
p_r30_13 | SAWTOOTH | 90000 | avg | 7305 | 86.051
p_r30_13 | SAWTOOTH | 400000 | avg | 1453 | 241.828
p_r30_13 | SAWTOOTH | 1000000 | avg | 542 | 534.863
p_r30_13 | STAGGER | 600 | avg | 1954062 | 1.423
p_r30_13 | STAGGER | 3000 | avg | 312251 | 6.444
p_r30_13 | STAGGER | 90000 | avg | 7305 | 89.296
p_r30_13 | STAGGER | 400000 | avg | 1453 | 254.731
p_r30_13 | STAGGER | 1000000 | avg | 542 | 600.44
p_r30_13 | SHUFFLE | 600 | avg | 325677 | 2.915
p_r30_13 | SHUFFLE | 3000 | avg | 52041 | 21.365
p_r30_13 | SHUFFLE | 90000 | avg | 1217 | 208.764
p_r30_13 | SHUFFLE | 400000 | avg | 242 | 501.508
p_r30_13 | SHUFFLE | 1000000 | avg | 90 | 993.647
p_r30_14 | RANDOM | 600 | avg | 325677 | 4.307
p_r30_14 | RANDOM | 3000 | avg | 52041 | 66.12
p_r30_14 | RANDOM | 90000 | avg | 1217 | 444.795
p_r30_14 | RANDOM | 400000 | avg | 242 | 1360.347
p_r30_14 | RANDOM | 1000000 | avg | 90 | 3138.356
p_r30_14 | REPEATED | 600 | avg | 651354 | 1.153
p_r30_14 | REPEATED | 3000 | avg | 104083 | 5.577
p_r30_14 | REPEATED | 90000 | avg | 2435 | 182.293
p_r30_14 | REPEATED | 400000 | avg | 484 | 539.214
p_r30_14 | REPEATED | 1000000 | avg | 180 | 1198.966
p_r30_14 | SAWTOOTH | 600 | avg | 1954062 | 0.615
p_r30_14 | SAWTOOTH | 3000 | avg | 312251 | 3.069
p_r30_14 | SAWTOOTH | 90000 | avg | 7305 | 85.057
p_r30_14 | SAWTOOTH | 400000 | avg | 1453 | 238.674
p_r30_14 | SAWTOOTH | 1000000 | avg | 542 | 534.144
p_r30_14 | STAGGER | 600 | avg | 1954062 | 1.432
p_r30_14 | STAGGER | 3000 | avg | 312251 | 6.523
p_r30_14 | STAGGER | 90000 | avg | 7305 | 89.317
p_r30_14 | STAGGER | 400000 | avg | 1453 | 256.221
p_r30_14 | STAGGER | 1000000 | avg | 542 | 600.91
p_r30_14 | SHUFFLE | 600 | avg | 325677 | 2.875
p_r30_14 | SHUFFLE | 3000 | avg | 52041 | 19.098
p_r30_14 | SHUFFLE | 90000 | avg | 1217 | 205.568
p_r30_14 | SHUFFLE | 400000 | avg | 242 | 505.436
p_r30_14 | SHUFFLE | 1000000 | avg | 90 | 994.061
p_r30_21 | RANDOM | 600 | avg | 325677 | 4.282
p_r30_21 | RANDOM | 3000 | avg | 52041 | 65.659
p_r30_21 | RANDOM | 90000 | avg | 1217 | 325.945
p_r30_21 | RANDOM | 400000 | avg | 242 | 1209.189
p_r30_21 | RANDOM | 1000000 | avg | 90 | 2986.999
p_r30_21 | REPEATED | 600 | avg | 651354 | 1.217
p_r30_21 | REPEATED | 3000 | avg | 104083 | 5.732
p_r30_21 | REPEATED | 90000 | avg | 2435 | 247.546
p_r30_21 | REPEATED | 400000 | avg | 484 | 1044.165
p_r30_21 | REPEATED | 1000000 | avg | 180 | 2533.575
p_r30_21 | SAWTOOTH | 600 | avg | 1954062 | 0.72
p_r30_21 | SAWTOOTH | 3000 | avg | 312251 | 3.664
p_r30_21 | SAWTOOTH | 90000 | avg | 7305 | 60.42
p_r30_21 | SAWTOOTH | 400000 | avg | 1453 | 204.466
p_r30_21 | SAWTOOTH | 1000000 | avg | 542 | 507.866
p_r30_21 | STAGGER | 600 | avg | 1954062 | 1.636
p_r30_21 | STAGGER | 3000 | avg | 312251 | 7.798
p_r30_21 | STAGGER | 90000 | avg | 7305 | 84.77
p_r30_21 | STAGGER | 400000 | avg | 1453 | 243.515
p_r30_21 | STAGGER | 1000000 | avg | 542 | 629.321
p_r30_21 | SHUFFLE | 600 | avg | 325677 | 2.851
p_r30_21 | SHUFFLE | 3000 | avg | 52041 | 18.006
p_r30_21 | SHUFFLE | 90000 | avg | 1217 | 141.569
p_r30_21 | SHUFFLE | 400000 | avg | 242 | 755.243
p_r30_21 | SHUFFLE | 1000000 | avg | 90 | 1631.399
p_r30_23 | RANDOM | 600 | avg | 325677 | 4.102
p_r30_23 | RANDOM | 3000 | avg | 52041 | 73.462
p_r30_23 | RANDOM | 90000 | avg | 1217 | 322.398
p_r30_23 | RANDOM | 400000 | avg | 242 | 1233.117
p_r30_23 | RANDOM | 1000000 | avg | 90 | 3046.612
p_r30_23 | REPEATED | 600 | avg | 651354 | 1.171
p_r30_23 | REPEATED | 3000 | avg | 104083 | 5.649
p_r30_23 | REPEATED | 90000 | avg | 2435 | 245.933
p_r30_23 | REPEATED | 400000 | avg | 484 | 1038.058
p_r30_23 | REPEATED | 1000000 | avg | 180 | 2544.802
p_r30_23 | SAWTOOTH | 600 | avg | 1954062 | 0.523
p_r30_23 | SAWTOOTH | 3000 | avg | 312251 | 2.57
p_r30_23 | SAWTOOTH | 90000 | avg | 7305 | 55.17
p_r30_23 | SAWTOOTH | 400000 | avg | 1453 | 201.105
p_r30_23 | SAWTOOTH | 1000000 | avg | 542 | 451.383
p_r30_23 | STAGGER | 600 | avg | 1954062 | 1.185
p_r30_23 | STAGGER | 3000 | avg | 312251 | 5.138
p_r30_23 | STAGGER | 90000 | avg | 7305 | 79.963
p_r30_23 | STAGGER | 400000 | avg | 1453 | 228.974
p_r30_23 | STAGGER | 1000000 | avg | 542 | 603.877
p_r30_23 | SHUFFLE | 600 | avg | 325677 | 2.956
p_r30_23 | SHUFFLE | 3000 | avg | 52041 | 20.173
p_r30_23 | SHUFFLE | 90000 | avg | 1217 | 145.813
p_r30_23 | SHUFFLE | 400000 | avg | 242 | 758.349
p_r30_23 | SHUFFLE | 1000000 | avg | 90 | 1649.56



</body>

</html>

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

PR Comment: https://git.openjdk.org/jdk/pull/13568#issuecomment-2097089813

From liach at openjdk.org  Tue May  7 01:14:31 2024
From: liach at openjdk.org (Chen Liang)
Date: Tue, 7 May 2024 01:14:31 GMT
Subject: RFR: 8331744: java.lang.classfile.TypeKind improvements [v2]
In-Reply-To: <_x31CU5mODg3NGaRGzI5HdNdcjsKmqWb1TA7KZnZcFg=.43ce5ba3-71e7-42e5-a531-c3b609d0aafb@github.com>
References: <_x31CU5mODg3NGaRGzI5HdNdcjsKmqWb1TA7KZnZcFg=.43ce5ba3-71e7-42e5-a531-c3b609d0aafb@github.com>
Message-ID: <QitkonsiFBxND9n-lTcDvdlrMiX-4W9yy_9xafAr1uc=.0ffc33e7-2ea3-4358-8234-df50123fbf48@github.com>

> A peek into TypeKind during the research for #19105 reveals that TypeKind has a few issues:
> 1. Name mismatch for `newarraycode` and `fromNewArrayCode`: Renamed both to use "newarray code"
> 2. `fromDescriptor` can throw IOOBE if the input string is empty: changed to throw IAE and added tests.
> 3. `from(Class)` can be slow due to descriptor computation: added benchmark, will share result in next comment (as it may change with code changes).
> 
> The first 2 changes involves API changes, and a CSR has been created. Requesting @asotona for a review.

Chen Liang has updated the pull request incrementally with one additional commit since the last revision:

  Update test/micro/org/openjdk/bench/java/lang/classfile/TypeKindBench.java
  
  Co-authored-by: Claes Redestad <claes.redestad at oracle.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/19109/files
  - new: https://git.openjdk.org/jdk/pull/19109/files/82e46cdf..9338f901

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

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

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

From liach at openjdk.org  Tue May  7 01:28:59 2024
From: liach at openjdk.org (Chen Liang)
Date: Tue, 7 May 2024 01:28:59 GMT
Subject: RFR: 8305457: Implement java.io.IO
In-Reply-To: <w2msiw_qaMEIJS3s9D4bg8pFbz5WIF0KdP6Mm-XFjLI=.85b2020b-8c46-4bac-8a69-4975b068f2ff@github.com>
References: <w2msiw_qaMEIJS3s9D4bg8pFbz5WIF0KdP6Mm-XFjLI=.85b2020b-8c46-4bac-8a69-4975b068f2ff@github.com>
Message-ID: <-WNQ0gigYgjDdjH55OM-8aWzcDeHcA5ORdsK8MpSvj8=.8fe3c2ee-f30b-4dbd-a9a6-b0c8a4f0dbbc@github.com>

On Mon, 6 May 2024 21:45:12 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> Please review this PR which introduces the `java.io.IO` top-level class and three methods to `java.io.Console` for [Implicitly Declared Classes and Instance Main Methods (Third Preview)].
> 
> This PR has been obtained as `git merge --squash` of a now obsolete [draft PR].
> 
> [Implicitly Declared Classes and Instance Main Methods (Third Preview)]: https://bugs.openjdk.org/browse/JDK-8323335
> [draft PR]: https://github.com/openjdk/jdk/pull/18921

src/java.base/share/classes/java/io/IO.java line 41:

> 39:  */
> 40: @PreviewFeature(feature = PreviewFeature.Feature.IMPLICIT_CLASSES)
> 41: public class IO {

Should this be final?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19112#discussion_r1591707684

From liach at openjdk.org  Tue May  7 01:49:27 2024
From: liach at openjdk.org (Chen Liang)
Date: Tue, 7 May 2024 01:49:27 GMT
Subject: RFR: 8331744: java.lang.classfile.TypeKind improvements [v3]
In-Reply-To: <_x31CU5mODg3NGaRGzI5HdNdcjsKmqWb1TA7KZnZcFg=.43ce5ba3-71e7-42e5-a531-c3b609d0aafb@github.com>
References: <_x31CU5mODg3NGaRGzI5HdNdcjsKmqWb1TA7KZnZcFg=.43ce5ba3-71e7-42e5-a531-c3b609d0aafb@github.com>
Message-ID: <mPPY2XzOtaKHcjekme5LkQMFwyXSeyKGRPNQCjSAcb8=.bdb8b4d8-7a53-4142-9e13-9373086ddb88@github.com>

> A peek into TypeKind during the research for #19105 reveals that TypeKind has a few issues:
> 1. Name mismatch for `newarraycode` and `fromNewArrayCode`: Renamed both to use "newarray code"
> 2. `fromDescriptor` can throw IOOBE if the input string is empty: changed to throw IAE and added tests.
> 3. `from(Class)` can be slow due to descriptor computation: added benchmark, will share result in next comment (as it may change with code changes).
> 
> The first 2 changes involves API changes, and a CSR has been created. Requesting @asotona for a review.

Chen Liang has updated the pull request incrementally with one additional commit since the last revision:

  Add a mixed scenario

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/19109/files
  - new: https://git.openjdk.org/jdk/pull/19109/files/9338f901..adf1218c

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

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

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

From liach at openjdk.org  Tue May  7 02:13:55 2024
From: liach at openjdk.org (Chen Liang)
Date: Tue, 7 May 2024 02:13:55 GMT
Subject: RFR: 8331744: java.lang.classfile.TypeKind improvements
In-Reply-To: <qcjm8jbc4KR0BIXycBkVPSwGcODhcRBpbw40Wm8j86I=.13c85d1f-8fe8-46c7-ac1f-f88de65ef74a@github.com>
References: <_x31CU5mODg3NGaRGzI5HdNdcjsKmqWb1TA7KZnZcFg=.43ce5ba3-71e7-42e5-a531-c3b609d0aafb@github.com>
 <qcjm8jbc4KR0BIXycBkVPSwGcODhcRBpbw40Wm8j86I=.13c85d1f-8fe8-46c7-ac1f-f88de65ef74a@github.com>
Message-ID: <MOSdvwCK-XuR0_p1fiyoYhdlN34N6ovkcpBTCjPyKMM=.89fc12fb-9d67-4615-90b1-736ea911a201@github.com>

On Mon, 6 May 2024 22:00:24 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> A peek into TypeKind during the research for #19105 reveals that TypeKind has a few issues:
>> 1. Name mismatch for `newarraycode` and `fromNewArrayCode`: Renamed both to use "newarray code"
>> 2. `fromDescriptor` can throw IOOBE if the input string is empty: changed to throw IAE and added tests.
>> 3. `from(Class)` can be slow due to descriptor computation: added benchmark, will share result in next comment (as it may change with code changes).
>> 
>> The first 2 changes involves API changes, and a CSR has been created. Requesting @asotona for a review.
>
> Leaning on `TypeDescriptor.OfField::isPrimitive` presents an opportunity: override `isPrimitive` in `PrimitiveClassDescImpl` and `ReferenceClassDescImpl` to return `true` and `false` respectively: 
> 
> 
> Name                            (type) Cnt    Base    Error     Test    Error  Unit  Change
> TypeKindBench.fromClassDescs PRIMITIVE   6 199,765 ?  3,370  205,531 ?  2,632 ns/op   0,97x (p = 0,000*)
> TypeKindBench.fromClassDescs REFERENCE   6  75,018 ?  1,113   25,925 ?  1,145 ns/op   2,89x (p = 0,000*)
> TypeKindBench.fromClasses    PRIMITIVE   6 344,477 ? 46,310  366,135 ? 54,955 ns/op   0,94x (p = 0,066 )
> TypeKindBench.fromClasses    REFERENCE   6  23,338 ?  0,467   23,183 ?  1,357 ns/op   1,01x (p = 0,484 )
>   * = significant
> 
> 
> Interestingly this has a tiny regression for the primitive case - in this micro. Probably an effect of the default `descriptor.length() == 1` implementation acting as a sort of prefetch the value we'll switch on (`descriptor.charAt(0)`) down this path. Only overriding for `ReferenceClassDescImpl` is neutral, but maybe that's overfitting:
> 
> 
> Name                            (type) Cnt    Base    Error     Test    Error  Unit  Change
> TypeKindBench.fromClassDescs PRIMITIVE   6 199,765 ?  3,370  196,203 ?  2,469 ns/op   1,02x (p = 0,000*)
> TypeKindBench.fromClassDescs REFERENCE   6  75,018 ?  1,113   25,311 ?  0,138 ns/op   2,96x (p = 0,000*)
> TypeKindBench.fromClasses    PRIMITIVE   6 344,477 ? 46,310  325,336 ? 12,203 ns/op   1,06x (p = 0,035 )
> TypeKindBench.fromClasses    REFERENCE   6  23,338 ?  0,467   23,462 ?  3,239 ns/op   0,99x (p = 0,805 )
>   * = significant

@cl4es
I think the benchmark results might be biased due to JIT optimizing for all-primitive or all-reference scenarios, while in practice these are more likely to be mixed (still, I assume a user usually just pass all CD or Class into from, no polymorphism there). The new MIXED type provides more interesting insights and is likely closer to production usages.

I specialized `isPrimitive` https://gist.github.com/c16f30a657648531edbf98fcbedb41e7
And the results are quite distinct from yours, as in my scenario, all ClassDescs see a consistent performance increase: (The Class versions see a negligible decrease, which I believe is just noise)

Baseline:

Benchmark                        (type)  Mode  Cnt    Score   Error  Units
TypeKindBench.fromClassDescs  PRIMITIVE  avgt    6  121.749 ? 6.362  ns/op
TypeKindBench.fromClassDescs  REFERENCE  avgt    6   56.299 ? 2.032  ns/op
TypeKindBench.fromClassDescs      MIXED  avgt    6  138.690 ? 3.376  ns/op
TypeKindBench.fromClasses     PRIMITIVE  avgt    6  224.747 ? 3.721  ns/op
TypeKindBench.fromClasses     REFERENCE  avgt    6   15.850 ? 0.610  ns/op
TypeKindBench.fromClasses         MIXED  avgt    6  134.017 ? 1.014  ns/op


Override:

Benchmark                        (type)  Mode  Cnt    Score   Error  Units
TypeKindBench.fromClassDescs  PRIMITIVE  avgt    6  109.005 ? 2.947  ns/op
TypeKindBench.fromClassDescs  REFERENCE  avgt    6   16.917 ? 0.242  ns/op
TypeKindBench.fromClassDescs      MIXED  avgt    6   97.376 ? 2.235  ns/op
TypeKindBench.fromClasses     PRIMITIVE  avgt    6  227.644 ? 4.851  ns/op
TypeKindBench.fromClasses     REFERENCE  avgt    6   16.375 ? 0.233  ns/op
TypeKindBench.fromClasses         MIXED  avgt    6  146.652 ? 4.549  ns/op

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

PR Comment: https://git.openjdk.org/jdk/pull/19109#issuecomment-2097271752

From darcy at openjdk.org  Tue May  7 02:56:54 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 7 May 2024 02:56:54 GMT
Subject: RFR: 8305457: Implement java.io.IO
In-Reply-To: <-WNQ0gigYgjDdjH55OM-8aWzcDeHcA5ORdsK8MpSvj8=.8fe3c2ee-f30b-4dbd-a9a6-b0c8a4f0dbbc@github.com>
References: <w2msiw_qaMEIJS3s9D4bg8pFbz5WIF0KdP6Mm-XFjLI=.85b2020b-8c46-4bac-8a69-4975b068f2ff@github.com>
 <-WNQ0gigYgjDdjH55OM-8aWzcDeHcA5ORdsK8MpSvj8=.8fe3c2ee-f30b-4dbd-a9a6-b0c8a4f0dbbc@github.com>
Message-ID: <VeykkrIb_1RvBlQ3NYZJIvig16qeKByY6hcRtpyeruw=.833c60ab-f4a7-4161-a071-ef9ba3b57657@github.com>

On Tue, 7 May 2024 01:26:30 GMT, Chen Liang <liach at openjdk.org> wrote:

> Should this be final?

With only the private constructor, it doesn't matter too much in practice, but an explicit `final` would be good documentation if that is the intent.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19112#discussion_r1591751257

From duke at openjdk.org  Tue May  7 05:31:58 2024
From: duke at openjdk.org (Nizar Benalla)
Date: Tue, 7 May 2024 05:31:58 GMT
Subject: Integrated: 8326836: Incorrect `@since` tags for ClassSignature
 methods
In-Reply-To: <aetZ1rkGsFaWnL4eulF8is1VGHIIBrKZHPg-kA5vuPI=.28cb1ec0-8777-4102-844c-2a5684271264@github.com>
References: <aetZ1rkGsFaWnL4eulF8is1VGHIIBrKZHPg-kA5vuPI=.28cb1ec0-8777-4102-844c-2a5684271264@github.com>
Message-ID: <rQgiTSCxlm3EstmhhhBuKAHRqaZp6AhnBHIVlHAUM6Y=.98466ff1-2c6e-4366-96ae-50a004760f59@github.com>

On Tue, 27 Feb 2024 15:10:37 GMT, Nizar Benalla <duke at openjdk.org> wrote:

> # Issue
> - [JDK-8326836](https://bugs.openjdk.org/browse/JDK-8326836): changes were made to the method signatures but this modification isn't reflected in the @ since tags. The @ since tags need to be updated.
> 
> I changed the `@since` tags to better accurately show when the methods were introduced. This is similar to #18032 and #18373 
> 
> For context, I am writing tests to check for accurate use of `@since` tags in documentation comments in source code.
> We're following these rules for now:
> 
> ### Rule 1: Introduction of New Elements
> 
> - If an element is new in JDK N, with no equivalent in JDK N-1, it must include `@since N`.
>   - Exception: Member elements (fields, methods, nested classes) may omit `@since` if their version matches the value specified for the enclosing class or interface.
> 
> ### Rule 2: Existing Elements in Subsequent JDK Versions
> 
> - If an element exists in JDK N, with an equivalent in JDK N-1, it should not include `@since N`.
> 
> ### Rule 3: Handling Missing `@since` Tags in methods if there is no `@since`
> 
> - When inspecting methods, prioritize the `@since` annotation of the supertype's overridden method.
> - If unavailable or if the enclosing class's `@since` is newer, use the enclosing element's `@since`.
> 
>   I.e. if A extends B, and we add a method to B in JDK N, and add an override of the method to A in JDK M (M > N), we will use N as the effective `@since` for the method.

This pull request has now been integrated.

Changeset: 3b8227ba
Author:    Nizar Benalla <nizar.benalla at oracle.com>
Committer: Adam Sotona <asotona at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/3b8227ba24c7bc05a8ea23801e3816e8fc80de4e
Stats:     2 lines in 1 file changed: 2 ins; 0 del; 0 mod

8326836: Incorrect `@since` tags for ClassSignature methods

Reviewed-by: asotona

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

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

From asotona at openjdk.org  Tue May  7 05:44:03 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Tue, 7 May 2024 05:44:03 GMT
Subject: RFR: 8311175: Move BufWriter::asByteBuffer to BufWriterImpl
In-Reply-To: <sEKITMKa0yBPrV7RTKYa0_GGSOss8a9T7GaOQpLaEYk=.f7ad0b39-bc77-4589-a8de-ef5132387e6c@github.com>
References: <sEKITMKa0yBPrV7RTKYa0_GGSOss8a9T7GaOQpLaEYk=.f7ad0b39-bc77-4589-a8de-ef5132387e6c@github.com>
Message-ID: <oZRXoV3GuRfusUDnmOjK6yGHNT8vT-T8ZEghcdvf0xI=.9bc212c0-ac4f-423f-97f7-4732f6363139@github.com>

On Fri, 30 Jun 2023 14:43:36 GMT, Chen Liang <liach at openjdk.org> wrote:

> As discussed on the mailing list https://mail.openjdk.org/pipermail/classfile-api-dev/2023-June/000381.html, BufWriter::asByteBuffer has a behavior not suitable for API and is only used by internal StackMapGenerator/StackCounter, so it will be converted to an internal API.
> 
> Somehow the ByteBuffer needs to be sliced, or StackMapGenerator encounters IOOBE. Not sure what the exact cause was.

@liach Do you have any plans with this PR?

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

PR Comment: https://git.openjdk.org/jdk/pull/14736#issuecomment-2097490371

From forax at openjdk.org  Tue May  7 05:55:55 2024
From: forax at openjdk.org (=?UTF-8?B?UsOpbWk=?= Forax)
Date: Tue, 7 May 2024 05:55:55 GMT
Subject: RFR: 8305457: Implement java.io.IO
In-Reply-To: <w2msiw_qaMEIJS3s9D4bg8pFbz5WIF0KdP6Mm-XFjLI=.85b2020b-8c46-4bac-8a69-4975b068f2ff@github.com>
References: <w2msiw_qaMEIJS3s9D4bg8pFbz5WIF0KdP6Mm-XFjLI=.85b2020b-8c46-4bac-8a69-4975b068f2ff@github.com>
Message-ID: <hVlQ7frdWV-o3-F0NHmZu1dnQqu2ZZqC03IFbR-I-yE=.c611d97e-31a9-4d22-9f53-b1bdd71467c5@github.com>

On Mon, 6 May 2024 21:45:12 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> Please review this PR which introduces the `java.io.IO` top-level class and three methods to `java.io.Console` for [Implicitly Declared Classes and Instance Main Methods (Third Preview)].
> 
> This PR has been obtained as `git merge --squash` of a now obsolete [draft PR].
> 
> [Implicitly Declared Classes and Instance Main Methods (Third Preview)]: https://bugs.openjdk.org/browse/JDK-8323335
> [draft PR]: https://github.com/openjdk/jdk/pull/18921

Otherwise looks good.

src/java.base/share/classes/jdk/internal/io/JdkConsoleImpl.java line 74:

> 72: 
> 73:     @Override
> 74:     public String readln(String prompt) {

this code can be simplified using an early return (and the body of the try/catch can be reduced so it is more clear which statement can cause the IOException)

        synchronized (writeLock) {
            synchronized(readLock) {
                if (!prompt.isEmpty()) {
                    pw.print(prompt);
                    pw.flush(); // automatic flushing does not cover print
                }
               char[] array;
                try {
                    array = readline(false);
                } catch (IOException x) {
                    throw new IOError(x);
                }
                if (array != null) {
                    return new String(array);
                }
            }
        }
        return null;

src/jdk.internal.le/share/classes/jdk/internal/org/jline/JdkConsoleProviderImpl.java line 88:

> 86:         @Override
> 87:         public JdkConsole println(Object obj) {
> 88:             writer().println(obj);

the result of 'writer()' can be stored in a local variable (printing code are not JITed as often as the rest of the codes)

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

PR Comment: https://git.openjdk.org/jdk/pull/19112#issuecomment-2097502361
PR Review Comment: https://git.openjdk.org/jdk/pull/19112#discussion_r1591846059
PR Review Comment: https://git.openjdk.org/jdk/pull/19112#discussion_r1591847579

From joehw at openjdk.org  Tue May  7 06:21:52 2024
From: joehw at openjdk.org (Joe Wang)
Date: Tue, 7 May 2024 06:21:52 GMT
Subject: RFR: 8329691: Support `nonlikelyScript` parent locale inheritance
In-Reply-To: <VZl5HzmaaIHFzVj7FDB9gC9MLHZMlZOjObMwiKL7cMI=.fb806a5b-1414-4850-aa50-1da3c9835d16@github.com>
References: <VZl5HzmaaIHFzVj7FDB9gC9MLHZMlZOjObMwiKL7cMI=.fb806a5b-1414-4850-aa50-1da3c9835d16@github.com>
Message-ID: <0IjUIVsNfs48zZix0amvsAzbhVmzQ9cnf2TI8w9Z6Nk=.dbf51cf4-a69b-42dd-b0e0-27f86c18e37f@github.com>

On Mon, 6 May 2024 17:53:56 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> This PR is to implement the `nonlikelyScript` feature that went into CLDR version 45 for migration purposes. In its release note, it states (https://cldr.unicode.org/index/downloads/cldr-45):
> 
> Migration
> Changes to parentLocales require upgrading implementations that use that element. In particular, they need to support the new nonlikelyScript value, and use the appropriate explicit inheritance for each type of inheritance. The v44 list of locales that inherit directly from root is retained for this release, but will disappear in the future. So implementations should move as quickly as possible to support the new value
> 
> For example in `Russian` locales fallback, its likely script is `Cyrl` (Cyrillic). Thus Russian locales with non-likely script, such as 'ru-Latn' (Russian in Latin script) should fallback directly to `root`, bypassing `ru` (Russian). CLDR has explicit parent locales for this nonlikely scripts, such as `zh-Hant` -> `root` already, but the release note suggests this will go away, and JDK needs to logically handle these non-likely script inheritance cases.
> 
> To implement this behavior, CLDRConverter build tool now generates the `LocaleDataMetaInfo` for java.base module with the new `likelyScriptMap`, which maps the script to its likely languages. Since the map is big, it is lazily initialized when needed. The map is used at runtime to determine the parent locale fallback based on implicit/explicit nonlikely Script inheritance.

Marked as reviewed by joehw (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/19108#pullrequestreview-2042157221

From clanger at openjdk.org  Tue May  7 07:06:55 2024
From: clanger at openjdk.org (Christoph Langer)
Date: Tue, 7 May 2024 07:06:55 GMT
Subject: RFR: 8329653: JLILaunchTest fails on AIX after JDK-8329131 [v2]
In-Reply-To: <0Zk_GFIiqp21uI11y2ae6oRJbGYcxcuVrjf4YwQg4CI=.073efa87-9736-46ee-a1b0-bd8232196039@github.com>
References: <y9wItIb8Yr_ZrHfN_kV5lDCp-d-VtYam3MuHX1OxurU=.ce3378d2-90b3-4396-8951-4651439e4f90@github.com>
 <0Zk_GFIiqp21uI11y2ae6oRJbGYcxcuVrjf4YwQg4CI=.073efa87-9736-46ee-a1b0-bd8232196039@github.com>
Message-ID: <l2-8cgTRxdJeO-304m-FQTuhXY6KnIM2Sgo4IedX0ps=.de8afd96-e983-44ba-8011-1c60a24ba3a8@github.com>

On Fri, 3 May 2024 15:25:05 GMT, Joachim Kern <jkern at openjdk.org> wrote:

>> Since ~ end of March, after [JDK-8329131](https://bugs.openjdk.org/browse/JDK-8329131), tools/launcher/JliLaunchTest.java fails on AIX. Failure is :
>> 
>>  stdout: [];
>>  stderr: [Error: could not find libjava.so
>> Error: Could not find Java SE Runtime Environment.
>> ]
>>  exitValue = 2
>> 
>> java.lang.RuntimeException: Expected to get exit value of [0], exit value is: [2]
>> at jdk.test.lib.process.OutputAnalyzer.shouldHaveExitValue(OutputAnalyzer.java:521)
>> at JliLaunchTest.main(JliLaunchTest.java:58)
>> at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
>> at java.base/java.lang.reflect.Method.invoke(Method.java:580)
>> at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:333)
>> at java.base/java.lang.Thread.run(Thread.java:1575)
>> 
>> Maybe we need to do further adjustments to BUILD_JDK_JTREG_EXECUTABLES_LIBS_exeJliLaunchTest / BUILD_JDK_JTREG_EXECUTABLES_LDFLAGS_exeJliLaunchTest on AIX ?
>> Or somehow adjust the coding that attempts to find parts of "JRE" (libjava.so) ? The libjli.so is gone on AIX after [JDK-8329131](https://bugs.openjdk.org/browse/JDK-8329131), and with this also the image discovery based on GetApplicationHomeFromDll which uses libjli.so .
>> 
>> Without libjli.so we have to analyze the LD-LIBRARY_PATH / LIBPATH envvar. There is no other methos available on AIX, because it lacks the $ORIGIN feature of the rpath.
>
> Joachim Kern has updated the pull request incrementally with one additional commit since the last revision:
> 
>   only for AIX

Minor formatting suggestions

src/java.base/unix/native/libjli/java_md_common.c line 135:

> 133:  */
> 134: jboolean
> 135: GetApplicationHomeFromLibpath(char *buf, jint bufsize)

Suggestion:

GetApplicationHomeFromLibpath(char *buf, jint bufsize) {

src/java.base/unix/native/libjli/java_md_common.c line 136:

> 134: jboolean
> 135: GetApplicationHomeFromLibpath(char *buf, jint bufsize)
> 136: {

Suggestion:

src/java.base/unix/native/libjli/java_md_common.c line 139:

> 137:     char *env = getenv(LD_LIBRARY_PATH);
> 138:     char *tmp;
> 139:     char* save_ptr = NULL;

Suggestion:

    char *save_ptr = NULL;

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

PR Review: https://git.openjdk.org/jdk/pull/19000#pullrequestreview-2042227569
PR Review Comment: https://git.openjdk.org/jdk/pull/19000#discussion_r1591912792
PR Review Comment: https://git.openjdk.org/jdk/pull/19000#discussion_r1591912990
PR Review Comment: https://git.openjdk.org/jdk/pull/19000#discussion_r1591911912

From jlahoda at openjdk.org  Tue May  7 07:13:23 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Tue, 7 May 2024 07:13:23 GMT
Subject: RFR: 8331535: Incorrect prompt for Console.readLine [v4]
In-Reply-To: <IQvUAYG5zj0JqUbWiQiryAuBrtV6jrVCvy9useQZmlc=.a4dd8dfc-e835-4405-83f8-fd1bda8480f6@github.com>
References: <IQvUAYG5zj0JqUbWiQiryAuBrtV6jrVCvy9useQZmlc=.a4dd8dfc-e835-4405-83f8-fd1bda8480f6@github.com>
Message-ID: <odGBY-01VvMY90f3GM90D6SDIFkm4DQPE0C1_5SAJGk=.e2fba76c-9946-4abc-8c83-cd34d6045735@github.com>

> When JLine reads a line, there may be a prompt provided. However, JLine will not interpret the prompt literally, it will handle `%` specially. As a consequence, doing:
> 
> System.console().readLine("%%s");
> 
> 
> will not print `%s`, as first `String.format` is used, which will convert `%%s` to `%s`, and then JLine will interpret the `%`. The proposed solution is to duplicate the `%`, so that JLine will print it.

Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:

  Adding another test run with -Djdk.console=java.base, as suggested.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/19081/files
  - new: https://git.openjdk.org/jdk/pull/19081/files/05592871..a138981e

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

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

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

From jlu at openjdk.org  Tue May  7 07:46:22 2024
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 7 May 2024 07:46:22 GMT
Subject: RFR: 8331485: Odd Results when Parsing Scientific Notation with
 Large Exponent [v5]
In-Reply-To: <lTOZ4RbzZFMN0yLrQKGOcMihdTop24YbYJe2h36SodM=.0addc2ad-b0d1-4721-b860-a9395fa14977@github.com>
References: <lTOZ4RbzZFMN0yLrQKGOcMihdTop24YbYJe2h36SodM=.0addc2ad-b0d1-4721-b860-a9395fa14977@github.com>
Message-ID: <riPoN1c_9KUHtoXtu0grLU04DBXqN1c3M1U4ILn9P3s=.8f2b2913-8c75-4e65-9d89-cf03f0bc0c0e@github.com>

> Please review this PR which corrects an edge case bug for java.text.DecimalFormat that causes incorrect parsing results for strings with very large exponent values.
> 
> When parsing values with large exponents, if the value of the exponent exceeds `Integer.MAX_VALUE`, the parsed value  is equal to 0. If the value of the exponent exceeds `Long.MAX_VALUE`, the parsed value is equal to the mantissa. Both results are confusing and incorrect.
> 
> For example,
> 
> 
> NumberFormat fmt = NumberFormat.getInstance(Locale.US);
> fmt.parse(".1E2147483648"); // returns 0.0
> fmt.parse(".1E9223372036854775808"); // returns 0.1
> // For comparison
> Double.parseDouble(".1E2147483648"); // returns Infinity
> Double.parseDouble(".1E9223372036854775808"); // returns Infinity
> 
> 
> After this change, both parse calls return `Double.POSITIVE_INFINITY` now.

Justin Lu has updated the pull request incrementally with one additional commit since the last revision:

  correct behavior when underflow from adjustment + use MIN

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/19075/files
  - new: https://git.openjdk.org/jdk/pull/19075/files/17a3b3aa..2c167493

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

  Stats: 19 lines in 2 files changed: 9 ins; 4 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/19075.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19075/head:pull/19075

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

From jlu at openjdk.org  Tue May  7 07:52:56 2024
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 7 May 2024 07:52:56 GMT
Subject: RFR: 8331485: Odd Results when Parsing Scientific Notation with
 Large Exponent [v4]
In-Reply-To: <EymS36r8IN-xgYl5Uz3DIza34wpnxlnnF3fsZA2bang=.6a0c933a-3688-4944-9dd3-229004e770b0@github.com>
References: <lTOZ4RbzZFMN0yLrQKGOcMihdTop24YbYJe2h36SodM=.0addc2ad-b0d1-4721-b860-a9395fa14977@github.com>
 <sa4s6HxjAPnjvfPhnzAQQp3Ia5_lXHcSIqtIm-0BNbA=.bf554e84-0019-46d6-b8ef-3ee8852ac11d@github.com>
 <EymS36r8IN-xgYl5Uz3DIza34wpnxlnnF3fsZA2bang=.6a0c933a-3688-4944-9dd3-229004e770b0@github.com>
Message-ID: <TCy8Ypy1K6geJiSELpaZPqlovFP3Di_aT-zOqCxiVMI=.5e2c2587-e676-4a44-a005-0cb0723b5f74@github.com>

On Mon, 6 May 2024 19:47:48 GMT, Axel Hauschulte <duke at openjdk.org> wrote:

>> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Check both parse methods
>
> test/jdk/java/text/Format/DecimalFormat/LargeExponentsTest.java line 150:
> 
>> 148:                 // Long.MIN_VALUE
>> 149:                 Arguments.of("1.23E-9223372036854775808", 0.0)
>> 150:         );
> 
> I would suggest adding one more test case to the edge cases:
> 
> Arguments.of("0.0123E-2147483648", 0.0)
> 
> This will test the adjustment of the `digits.decimalAt` field for an exponent that is within the range of integer, but due to the mantissa not being in its standardized form an overflow will occure non the less.

Right, that's a good test case to have, (which exposed a needed update in the implementation).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19075#discussion_r1591971646

From jkern at openjdk.org  Tue May  7 08:08:05 2024
From: jkern at openjdk.org (Joachim Kern)
Date: Tue, 7 May 2024 08:08:05 GMT
Subject: RFR: 8329653: JLILaunchTest fails on AIX after JDK-8329131 [v3]
In-Reply-To: <y9wItIb8Yr_ZrHfN_kV5lDCp-d-VtYam3MuHX1OxurU=.ce3378d2-90b3-4396-8951-4651439e4f90@github.com>
References: <y9wItIb8Yr_ZrHfN_kV5lDCp-d-VtYam3MuHX1OxurU=.ce3378d2-90b3-4396-8951-4651439e4f90@github.com>
Message-ID: <D3ZEVmfJIpjMyN7u9tLewNo0N5xuIQWGeFiBgnvdxsM=.1859ec49-d2ef-4c45-8008-24f48313d231@github.com>

> Since ~ end of March, after [JDK-8329131](https://bugs.openjdk.org/browse/JDK-8329131), tools/launcher/JliLaunchTest.java fails on AIX. Failure is :
> 
>  stdout: [];
>  stderr: [Error: could not find libjava.so
> Error: Could not find Java SE Runtime Environment.
> ]
>  exitValue = 2
> 
> java.lang.RuntimeException: Expected to get exit value of [0], exit value is: [2]
> at jdk.test.lib.process.OutputAnalyzer.shouldHaveExitValue(OutputAnalyzer.java:521)
> at JliLaunchTest.main(JliLaunchTest.java:58)
> at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
> at java.base/java.lang.reflect.Method.invoke(Method.java:580)
> at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:333)
> at java.base/java.lang.Thread.run(Thread.java:1575)
> 
> Maybe we need to do further adjustments to BUILD_JDK_JTREG_EXECUTABLES_LIBS_exeJliLaunchTest / BUILD_JDK_JTREG_EXECUTABLES_LDFLAGS_exeJliLaunchTest on AIX ?
> Or somehow adjust the coding that attempts to find parts of "JRE" (libjava.so) ? The libjli.so is gone on AIX after [JDK-8329131](https://bugs.openjdk.org/browse/JDK-8329131), and with this also the image discovery based on GetApplicationHomeFromDll which uses libjli.so .
> 
> Without libjli.so we have to analyze the LD-LIBRARY_PATH / LIBPATH envvar. There is no other methos available on AIX, because it lacks the $ORIGIN feature of the rpath.

Joachim Kern has updated the pull request incrementally with one additional commit since the last revision:

  cosmetic changes

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/19000/files
  - new: https://git.openjdk.org/jdk/pull/19000/files/caf806b3..5890bca3

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

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

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

From duke at openjdk.org  Tue May  7 09:10:52 2024
From: duke at openjdk.org (serhiysachkov)
Date: Tue, 7 May 2024 09:10:52 GMT
Subject: RFR: JDK-8331646: Add specific regression leap year tests (Task -
 P4)
In-Reply-To: <cB-Q8ihe6DYQTm1WcRvVV3oW8YXtnWH5fmsS1zurwwY=.176d4137-bd3b-445e-a055-c738bd73744c@github.com>
References: <cB-Q8ihe6DYQTm1WcRvVV3oW8YXtnWH5fmsS1zurwwY=.176d4137-bd3b-445e-a055-c738bd73744c@github.com>
Message-ID: <m99KbDfDQqGpJaHXAk1tHZ86vysc-q4CS5HCcHok9tg=.dbdd965f-7d20-40f9-bd59-6831eaf116b7@github.com>

On Fri, 3 May 2024 10:31:14 GMT, serhiysachkov <duke at openjdk.org> wrote:

> Calendar.add() tests that describe its behavior.

This PR provides additional tests that clarify behavior of Calendar.add() method for leap year, specifically behavior that led to this ticket https://bugs.openjdk.org/browse/JDK-8327088.

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

PR Comment: https://git.openjdk.org/jdk/pull/19082#issuecomment-2097814095

From jkratochvil at openjdk.org  Tue May  7 09:39:05 2024
From: jkratochvil at openjdk.org (Jan Kratochvil)
Date: Tue, 7 May 2024 09:39:05 GMT
Subject: RFR: 8322420: [Linux] cgroup v2: Limits in parent nested control
 groups are not detected [v8]
In-Reply-To: <3Lhq8O6sPoV5PjC0kbqTW0O2DCMkmZOeERR5ZjvUicE=.6ed8507f-613d-4c2c-a641-05399d5faa1c@github.com>
References: <c6DtrskKpUb_gpAtfqMTy3HLPdk0TiVZGfU5wcNl4Eo=.52b62a49-421b-4853-ba58-a878b4d312c6@github.com>
 <3Lhq8O6sPoV5PjC0kbqTW0O2DCMkmZOeERR5ZjvUicE=.6ed8507f-613d-4c2c-a641-05399d5faa1c@github.com>
Message-ID: <_yH70h4lNh_9BvkLN83stmgsnKjMEehD3JRSMLPOEWs=.12b6fca9-b5b6-42f7-9dd7-7f18de426981@github.com>

On Sun, 10 Mar 2024 14:40:09 GMT, Jan Kratochvil <jkratochvil at openjdk.org> wrote:

>> The testcase requires root permissions.
>> 
>> Designed by  Severin Gehwolf, implemented by Jan Kratochvil.
>
> Jan Kratochvil has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 35 commits:
> 
>  - Fix whitespace
>  - Merge branch 'master' into master-cgroup
>    
>    Conflicts:
>    	test/hotspot/gtest/os/linux/test_cgroupSubsystem_linux.cpp
>  - Fix gtest
>  - Update the Java part
>  - Fix cgroup1 backward compatibility message
>  - Merge remote-tracking branch 'centos79/master-cgroup' into master-cgroup
>  - Disable cgroup.subtree_control testcase on cgroup1
>  - Fix gtest
>  - Merge branch 'master' into master-cgroup
>  - Merge remote-tracking branch 'f38crac/master-cgroup' into master-cgroup
>  - ... and 25 more: https://git.openjdk.org/jdk/compare/243cb098...39c90162

Should JDK still support `memory.use_hierarchy == 0`? That has been already removed from Linux kernel: https://github.com/torvalds/linux/commit/bef8620cd8e0a117c1a0719604052e424eb418f9
This patch is apparently present even in kernel-3.10.0-1160.118.1.el7.x86_64 (CentOS-7.9 updates)
It is not present in kernel-3.10.0-1160.el7.x86_64 (CentOS-7.9 release)
Still CentOS-7 is almost EOLed, is there any other distro for cgroup1?

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

PR Comment: https://git.openjdk.org/jdk/pull/17198#issuecomment-2097873090

From duke at openjdk.org  Tue May  7 09:44:09 2024
From: duke at openjdk.org (serhiysachkov)
Date: Tue, 7 May 2024 09:44:09 GMT
Subject: RFR: JDK-8331646: Add specific regression leap year tests (Task -
 P4) [v2]
In-Reply-To: <cB-Q8ihe6DYQTm1WcRvVV3oW8YXtnWH5fmsS1zurwwY=.176d4137-bd3b-445e-a055-c738bd73744c@github.com>
References: <cB-Q8ihe6DYQTm1WcRvVV3oW8YXtnWH5fmsS1zurwwY=.176d4137-bd3b-445e-a055-c738bd73744c@github.com>
Message-ID: <jVsUCuB16T9wnWispfbUcU7fCsN4ucmYlbzWKrD2638=.2aa43d44-3e8e-485d-a7e3-d196daf2aafd@github.com>

> Calendar.add() tests that describe its behavior.

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

  JDK-8331646 updating to ParameterizedTests according to review request

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/19082/files
  - new: https://git.openjdk.org/jdk/pull/19082/files/3d09d62c..bce324f3

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

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

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

From sgehwolf at openjdk.org  Tue May  7 09:48:57 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Tue, 7 May 2024 09:48:57 GMT
Subject: RFR: 8322420: [Linux] cgroup v2: Limits in parent nested control
 groups are not detected [v8]
In-Reply-To: <_yH70h4lNh_9BvkLN83stmgsnKjMEehD3JRSMLPOEWs=.12b6fca9-b5b6-42f7-9dd7-7f18de426981@github.com>
References: <c6DtrskKpUb_gpAtfqMTy3HLPdk0TiVZGfU5wcNl4Eo=.52b62a49-421b-4853-ba58-a878b4d312c6@github.com>
 <3Lhq8O6sPoV5PjC0kbqTW0O2DCMkmZOeERR5ZjvUicE=.6ed8507f-613d-4c2c-a641-05399d5faa1c@github.com>
 <_yH70h4lNh_9BvkLN83stmgsnKjMEehD3JRSMLPOEWs=.12b6fca9-b5b6-42f7-9dd7-7f18de426981@github.com>
Message-ID: <hO5iJNcddxHNbvh1ewrPut8xFmSnzUA1ZL2hRZvMIOQ=.c52208ad-7f9a-458f-bfb6-442e48e8a85b@github.com>

On Tue, 7 May 2024 09:36:10 GMT, Jan Kratochvil <jkratochvil at openjdk.org> wrote:

> Should JDK still support `memory.use_hierarchy == 0`?

IMO, no. Just get rid of it and assume hierarchical everywhere. We'd be walking the hierarchy for other (lower limits), which should cover this case on those legacy systems.

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

PR Comment: https://git.openjdk.org/jdk/pull/17198#issuecomment-2097892763

From redestad at openjdk.org  Tue May  7 10:50:00 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Tue, 7 May 2024 10:50:00 GMT
Subject: RFR: 8331744: java.lang.classfile.TypeKind improvements [v3]
In-Reply-To: <mPPY2XzOtaKHcjekme5LkQMFwyXSeyKGRPNQCjSAcb8=.bdb8b4d8-7a53-4142-9e13-9373086ddb88@github.com>
References: <_x31CU5mODg3NGaRGzI5HdNdcjsKmqWb1TA7KZnZcFg=.43ce5ba3-71e7-42e5-a531-c3b609d0aafb@github.com>
 <mPPY2XzOtaKHcjekme5LkQMFwyXSeyKGRPNQCjSAcb8=.bdb8b4d8-7a53-4142-9e13-9373086ddb88@github.com>
Message-ID: <Sam_OIBH0AkulGMqY3fsVFz7RCGlQSQGgdz8fuVdhl4=.3fb53910-de22-43cd-84fe-da806aa2ee60@github.com>

On Tue, 7 May 2024 01:49:27 GMT, Chen Liang <liach at openjdk.org> wrote:

>> A peek into TypeKind during the research for #19105 reveals that TypeKind has a few issues:
>> 1. Name mismatch for `newarraycode` and `fromNewArrayCode`: Renamed both to use "newarray code"
>> 2. `fromDescriptor` can throw IOOBE if the input string is empty: changed to throw IAE and added tests.
>> 3. `from(Class)` can be slow due to descriptor computation: added benchmark, will share result in next comment (as it may change with code changes).
>> 
>> The first 2 changes involves API changes, and a CSR has been created. Requesting @asotona for a review.
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add a mixed scenario

Nice improvement to the micro. It might be preferable to use random generation with a hardcoded or parameterized seed to reduce run-to-run variation, eg. `new Random(1)`.

Agree that call sites are unlikely to mix `CD` and `Class`, but we're likely to see the bimorphicness from passing Primitive and ReferenceCDs. This is typically a very small and constant call overhead.

The primitives path seem to be the weak link, and maybe we could take a cue from `sun.util.invoke.Wrapper` and set up a similar perfect hash table instead of a switch. This seem somewhat profitable:

 Name                            (type) Cnt    Base    Error     Test    Error  Unit  Change
TypeKindBench.fromClassDescs PRIMITIVE   6 196,203 ?  2,469  147,898 ?  8,786 ns/op   1,33x (p = 0,000*)
TypeKindBench.fromClasses    PRIMITIVE   6 325,336 ? 12,203  206,084 ?  2,180 ns/op   1,58x (p = 0,000*)


The `fromClasses PRIMITIVE` case is still a bit behind since getting the descriptorString takes a few extra (non-allocating) steps.

Patch:

diff --git a/src/java.base/share/classes/java/lang/classfile/TypeKind.java b/src/java.base/share/classes/java/lang/classfile/TypeKind.java
index 5ba566b3d06..dd0a06c63ea 100644
--- a/src/java.base/share/classes/java/lang/classfile/TypeKind.java
+++ b/src/java.base/share/classes/java/lang/classfile/TypeKind.java
@@ -58,6 +58,7 @@ public enum TypeKind {

     private final String name;
     private final String descriptor;
+    private final char basicTypeChar;
     private final int newarrayCode;

     /** {@return the human-readable name corresponding to this type} */
@@ -100,6 +101,7 @@ public TypeKind asLoadable() {
     TypeKind(String name, String descriptor, int newarrayCode) {
         this.name = name;
         this.descriptor = descriptor;
+        this.basicTypeChar = descriptor.charAt(0);
         this.newarrayCode = newarrayCode;
     }

@@ -154,7 +156,29 @@ public static TypeKind fromDescriptor(CharSequence s) {
      */
     public static TypeKind from(TypeDescriptor.OfField<?> descriptor) {
         return descriptor.isPrimitive() // implicit null check
-                ? fromDescriptor(descriptor.descriptorString())
+                ? ofPrimitive(descriptor.descriptorString())
                 : TypeKind.ReferenceType;
     }
+
+    // Perfect hashing for basic types, borrowed from sun.invoke.util.Wrapper
+    private static final TypeKind[] FROM_CHAR = new TypeKind[16];
+
+    static {
+        for (TypeKind w : values()) {
+            if (w == ReferenceType) {
+                continue;
+            }
+            char c = w.descriptor.charAt(0);
+            FROM_CHAR[(c + (c >> 1)) & 0xf] = w;
+        }
+    }
+
+    private static TypeKind ofPrimitive(String descriptor) {
+        char basicTypeChar = descriptor.charAt(0);
+        TypeKind tk = FROM_CHAR[(basicTypeChar + (basicTypeChar >> 1)) & 0xf];
+        if (tk == null || tk.basicTypeChar != basicTypeChar) {
+            throw new IllegalArgumentException("bad descriptor: " + descriptor);
+        }
+        return tk;
+    }
 }
 ```

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

PR Comment: https://git.openjdk.org/jdk/pull/19109#issuecomment-2098060815

From prappo at openjdk.org  Tue May  7 11:04:53 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Tue, 7 May 2024 11:04:53 GMT
Subject: RFR: 8305457: Implement java.io.IO
In-Reply-To: <hVlQ7frdWV-o3-F0NHmZu1dnQqu2ZZqC03IFbR-I-yE=.c611d97e-31a9-4d22-9f53-b1bdd71467c5@github.com>
References: <w2msiw_qaMEIJS3s9D4bg8pFbz5WIF0KdP6Mm-XFjLI=.85b2020b-8c46-4bac-8a69-4975b068f2ff@github.com>
 <hVlQ7frdWV-o3-F0NHmZu1dnQqu2ZZqC03IFbR-I-yE=.c611d97e-31a9-4d22-9f53-b1bdd71467c5@github.com>
Message-ID: <yQGqIb5RQtadQA_bu-8JdUJDUdi_UEySF8Sm1-Bb5-c=.03331a10-d436-4ae7-8c88-e8d7649e8ec5@github.com>

On Tue, 7 May 2024 05:49:58 GMT, R?mi Forax <forax at openjdk.org> wrote:

>> Please review this PR which introduces the `java.io.IO` top-level class and three methods to `java.io.Console` for [Implicitly Declared Classes and Instance Main Methods (Third Preview)].
>> 
>> This PR has been obtained as `git merge --squash` of a now obsolete [draft PR].
>> 
>> [Implicitly Declared Classes and Instance Main Methods (Third Preview)]: https://bugs.openjdk.org/browse/JDK-8323335
>> [draft PR]: https://github.com/openjdk/jdk/pull/18921
>
> src/java.base/share/classes/jdk/internal/io/JdkConsoleImpl.java line 74:
> 
>> 72: 
>> 73:     @Override
>> 74:     public String readln(String prompt) {
> 
> this code can be simplified using an early return (and the body of the try/catch can be reduced so it is more clear which statement can cause the IOException)
> 
>         synchronized (writeLock) {
>             synchronized(readLock) {
>                 if (!prompt.isEmpty()) {
>                     pw.print(prompt);
>                     pw.flush(); // automatic flushing does not cover print
>                 }
>                char[] array;
>                 try {
>                     array = readline(false);
>                 } catch (IOException x) {
>                     throw new IOError(x);
>                 }
>                 if (array != null) {
>                     return new String(array);
>                 }
>             }
>         }
>         return null;

This method started as a copy of `readLine`. In its current form, it's very evident how `readln` differs from `readLine`, and I would leave it this way for now. If the feature is standardised, we could refactor both methods together, as you suggested.

If the `java.io.IO` part of the feature or the feature itself is withdrawn, then we could consider refactoring the existing `readLine`. Does it make sense?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19112#discussion_r1592281687

From prappo at openjdk.org  Tue May  7 11:16:55 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Tue, 7 May 2024 11:16:55 GMT
Subject: RFR: 8305457: Implement java.io.IO
In-Reply-To: <hVlQ7frdWV-o3-F0NHmZu1dnQqu2ZZqC03IFbR-I-yE=.c611d97e-31a9-4d22-9f53-b1bdd71467c5@github.com>
References: <w2msiw_qaMEIJS3s9D4bg8pFbz5WIF0KdP6Mm-XFjLI=.85b2020b-8c46-4bac-8a69-4975b068f2ff@github.com>
 <hVlQ7frdWV-o3-F0NHmZu1dnQqu2ZZqC03IFbR-I-yE=.c611d97e-31a9-4d22-9f53-b1bdd71467c5@github.com>
Message-ID: <PzNNXeGJOjdKQeyuR32Ofp4RnYNhQdRbW5h_FI3bnY8=.1bbabf4c-aaa7-43ad-938b-9c1537ee47f6@github.com>

On Tue, 7 May 2024 05:52:12 GMT, R?mi Forax <forax at openjdk.org> wrote:

>> Please review this PR which introduces the `java.io.IO` top-level class and three methods to `java.io.Console` for [Implicitly Declared Classes and Instance Main Methods (Third Preview)].
>> 
>> This PR has been obtained as `git merge --squash` of a now obsolete [draft PR].
>> 
>> [Implicitly Declared Classes and Instance Main Methods (Third Preview)]: https://bugs.openjdk.org/browse/JDK-8323335
>> [draft PR]: https://github.com/openjdk/jdk/pull/18921
>
> src/jdk.internal.le/share/classes/jdk/internal/org/jline/JdkConsoleProviderImpl.java line 88:
> 
>> 86:         @Override
>> 87:         public JdkConsole println(Object obj) {
>> 88:             writer().println(obj);
> 
> the result of 'writer()' can be stored in a local variable (printing code are not JITed as often as the rest of the codes)

I assume it's about performance. If so, I would defer any performance-related tweaks until they are necessary. Interactive reading from console does not sound like something requiring that level of performance tweaking.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19112#discussion_r1592303463

From prappo at openjdk.org  Tue May  7 11:58:16 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Tue, 7 May 2024 11:58:16 GMT
Subject: RFR: 8330205: Initial troff manpage generation for JDK 24
Message-ID: <6tFYXJ753At7nUZTy8khVVeiQHYtZRBRYegXSTXViUY=.f3110151-9ea0-4b55-89f1-90039273fd34@github.com>

Please review this mechanical change to man pages. This PR should be integrated after https://github.com/openjdk/jdk/pull/18787.

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

Commit messages:
 - Initial commit

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

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

From prappo at openjdk.org  Tue May  7 12:05:52 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Tue, 7 May 2024 12:05:52 GMT
Subject: RFR: 8330205: Initial troff manpage generation for JDK 24
In-Reply-To: <6tFYXJ753At7nUZTy8khVVeiQHYtZRBRYegXSTXViUY=.f3110151-9ea0-4b55-89f1-90039273fd34@github.com>
References: <6tFYXJ753At7nUZTy8khVVeiQHYtZRBRYegXSTXViUY=.f3110151-9ea0-4b55-89f1-90039273fd34@github.com>
Message-ID: <rwFuWs_IIJsPhKj5T4_C-CwJaeB4dCDHCAVBiLxS_ik=.3c274157-f47a-4a9f-94e8-fbdf03cd265e@github.com>

On Tue, 7 May 2024 11:53:19 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> Please review this mechanical change to man pages. This PR should be integrated after https://github.com/openjdk/jdk/pull/18787.

This PR is standalone as opposed to dependent because the https://github.com/openjdk/jdk/pull/18787 dependency currently has a merge conflict, which complicates the required workflow.

This comment serves as a reminder to merge master into this PR once https://github.com/openjdk/jdk/pull/18787 has been integrated. If we don't do that, Skara will likely create a backport issue:

> (?? The fixVersion in this issue is [24] but the fixVersion in .jcheck/conf is 23, a new backport will be created when this pr is integrated.)

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

PR Comment: https://git.openjdk.org/jdk/pull/19119#issuecomment-2098246931

From forax at openjdk.org  Tue May  7 12:21:53 2024
From: forax at openjdk.org (=?UTF-8?B?UsOpbWk=?= Forax)
Date: Tue, 7 May 2024 12:21:53 GMT
Subject: RFR: 8305457: Implement java.io.IO
In-Reply-To: <yQGqIb5RQtadQA_bu-8JdUJDUdi_UEySF8Sm1-Bb5-c=.03331a10-d436-4ae7-8c88-e8d7649e8ec5@github.com>
References: <w2msiw_qaMEIJS3s9D4bg8pFbz5WIF0KdP6Mm-XFjLI=.85b2020b-8c46-4bac-8a69-4975b068f2ff@github.com>
 <hVlQ7frdWV-o3-F0NHmZu1dnQqu2ZZqC03IFbR-I-yE=.c611d97e-31a9-4d22-9f53-b1bdd71467c5@github.com>
 <yQGqIb5RQtadQA_bu-8JdUJDUdi_UEySF8Sm1-Bb5-c=.03331a10-d436-4ae7-8c88-e8d7649e8ec5@github.com>
Message-ID: <OOeWi7f89VKud_6Sp7Z9AMdzPXexJl6sb6N6k-T2xFs=.5c5af026-02da-4d9d-987c-d62eaaf54ff6@github.com>

On Tue, 7 May 2024 11:00:52 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/io/JdkConsoleImpl.java line 74:
>> 
>>> 72: 
>>> 73:     @Override
>>> 74:     public String readln(String prompt) {
>> 
>> this code can be simplified using an early return (and the body of the try/catch can be reduced so it is more clear which statement can cause the IOException)
>> 
>>         synchronized (writeLock) {
>>             synchronized(readLock) {
>>                 if (!prompt.isEmpty()) {
>>                     pw.print(prompt);
>>                     pw.flush(); // automatic flushing does not cover print
>>                 }
>>                char[] array;
>>                 try {
>>                     array = readline(false);
>>                 } catch (IOException x) {
>>                     throw new IOError(x);
>>                 }
>>                 if (array != null) {
>>                     return new String(array);
>>                 }
>>             }
>>         }
>>         return null;
>
> This method started as a copy of `readLine`. In its current form, it's very evident how `readln` differs from `readLine`, and I would leave it this way for now. If the feature is standardised, we could refactor both methods together, as you suggested.
> 
> If the `java.io.IO` part of the feature or the feature itself is withdrawn, then we could consider refactoring the existing `readLine`. Does it make sense?

I do not think the step to "standardise" a preview feature exists ? When a preview feature becomes a released feature, the code is very lightly edited, at least it this is my experience. 

You can change both readln and readLine and if `java.io.IO` is removed, at least the code of readLine() will be

>> src/jdk.internal.le/share/classes/jdk/internal/org/jline/JdkConsoleProviderImpl.java line 88:
>> 
>>> 86:         @Override
>>> 87:         public JdkConsole println(Object obj) {
>>> 88:             writer().println(obj);
>> 
>> the result of 'writer()' can be stored in a local variable (printing code are not JITed as often as the rest of the codes)
>
> I assume it's about performance. If so, I would defer any performance-related tweaks until they are necessary. Interactive reading from console does not sound like something requiring that level of performance tweaking.

yes, let see what @cl4es will say when he will test the time to print "hello world"

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19112#discussion_r1592385449
PR Review Comment: https://git.openjdk.org/jdk/pull/19112#discussion_r1592387034

From liach at openjdk.org  Tue May  7 12:45:58 2024
From: liach at openjdk.org (Chen Liang)
Date: Tue, 7 May 2024 12:45:58 GMT
Subject: RFR: 8311175: Move BufWriter::asByteBuffer to BufWriterImpl
In-Reply-To: <sEKITMKa0yBPrV7RTKYa0_GGSOss8a9T7GaOQpLaEYk=.f7ad0b39-bc77-4589-a8de-ef5132387e6c@github.com>
References: <sEKITMKa0yBPrV7RTKYa0_GGSOss8a9T7GaOQpLaEYk=.f7ad0b39-bc77-4589-a8de-ef5132387e6c@github.com>
Message-ID: <PG7J00fLF-93x1qCbtfC_ih-vfJg1hDZIqkbRQYhFPA=.129f9640-3ca7-44fc-b307-6829415c417e@github.com>

On Fri, 30 Jun 2023 14:43:36 GMT, Chen Liang <liach at openjdk.org> wrote:

> As discussed on the mailing list https://mail.openjdk.org/pipermail/classfile-api-dev/2023-June/000381.html, BufWriter::asByteBuffer has a behavior not suitable for API and is only used by internal StackMapGenerator/StackCounter, so it will be converted to an internal API.
> 
> Somehow the ByteBuffer needs to be sliced, or StackMapGenerator encounters IOOBE. Not sure what the exact cause was.

Indeed, I should revive this patch.

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

PR Comment: https://git.openjdk.org/jdk/pull/14736#issuecomment-2098319220

From redestad at openjdk.org  Tue May  7 12:59:53 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Tue, 7 May 2024 12:59:53 GMT
Subject: RFR: 8305457: Implement java.io.IO
In-Reply-To: <OOeWi7f89VKud_6Sp7Z9AMdzPXexJl6sb6N6k-T2xFs=.5c5af026-02da-4d9d-987c-d62eaaf54ff6@github.com>
References: <w2msiw_qaMEIJS3s9D4bg8pFbz5WIF0KdP6Mm-XFjLI=.85b2020b-8c46-4bac-8a69-4975b068f2ff@github.com>
 <hVlQ7frdWV-o3-F0NHmZu1dnQqu2ZZqC03IFbR-I-yE=.c611d97e-31a9-4d22-9f53-b1bdd71467c5@github.com>
 <yQGqIb5RQtadQA_bu-8JdUJDUdi_UEySF8Sm1-Bb5-c=.03331a10-d436-4ae7-8c88-e8d7649e8ec5@github.com>
 <OOeWi7f89VKud_6Sp7Z9AMdzPXexJl6sb6N6k-T2xFs=.5c5af026-02da-4d9d-987c-d62eaaf54ff6@github.com>
Message-ID: <YQx4Hcn2TLeImHoj3PAYbVJIONzV4hIOkxisLrST3Cg=.b405394d-d207-44d8-8d11-a3204aa54256@github.com>

On Tue, 7 May 2024 12:18:52 GMT, R?mi Forax <forax at openjdk.org> wrote:

>> I assume it's about performance. If so, I would defer any performance-related tweaks until they are necessary. Interactive reading from console does not sound like something requiring that level of performance tweaking.
>
> yes, let see what @cl4es will say when he will test the time to print "hello world"

@forax I don't think anything touched on here is used during bootstrap; perhaps there are apps we could cover that uses these APIs, but I think for line-based console IO a few calls in the interpreter is not going to make a noticeable difference.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19112#discussion_r1592438417

From epeter at openjdk.org  Tue May  7 13:46:56 2024
From: epeter at openjdk.org (Emanuel Peter)
Date: Tue, 7 May 2024 13:46:56 GMT
Subject: RFR: 8325438: Add exhaustive tests for Math.round intrinsics [v13]
In-Reply-To: <yTfpBfWBMtjLm8BNvtocgxlBhgAKEVzpblP5OkyuTAM=.559b4718-ce15-4162-9f34-feda1d4a6398@github.com>
References: <MeXDL6wupeFWkaG7n24umN_ylwTv8dL0Lt1Zt3RwcQ8=.ebc46c01-27c8-4268-b6c0-12a33a8d93fa@github.com>
 <yTfpBfWBMtjLm8BNvtocgxlBhgAKEVzpblP5OkyuTAM=.559b4718-ce15-4162-9f34-feda1d4a6398@github.com>
Message-ID: <G46ChUfl3G0l3Do4CG962uC5tdb3QqmjbJHz-tCbxVI=.240f3c06-32aa-4c49-bdcc-fe3e313dd542@github.com>

On Mon, 29 Apr 2024 11:38:27 GMT, Hamlin Li <mli at openjdk.org> wrote:

>> HI,
>> Can you have a look at this patch adding some tests for Math.round instrinsics?
>> Thanks!
>> 
>> ### FYI:
>> During the development of RoundVF/RoundF, we faced the issues which were only spotted by running test exhaustively against 32/64 bits range of int/long.
>> It's helpful to add these exhaustive tests in jdk for future possible usage, rather than build it everytime when needed.
>> Of course, we need to put it in `manual` mode, so it's not run when `-automatic` jtreg option is specified which I guess is the mode CI used, please correct me if I'm assume incorrectly.
>
> Hamlin Li has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix issues; modify vm options to make sure test the expected behaviors.

Thanks for the extra tests!

Can you measure how much time each test now takes on your machine?

I think we are getting there. Still a little worried about some random bugs in the whole number generation... But I'd prefer having these tests to not having them for sure ;)

test/hotspot/jtreg/compiler/floatingpoint/TestRoundFloatAll.java line 31:

> 29:  * @library /test/lib /
> 30:  * @modules java.base/jdk.internal.math
> 31:  * @run main/othervm -XX:-TieredCompilation -XX:CompileThresholdScaling=0.3 -XX:+PrintIdeal -XX:CompileCommand=compileonly,compiler.floatingpoint.TestRoundFloatAll::test* -XX:-UseSuperWord compiler.floatingpoint.TestRoundFloatAll

please break up the line for easier reading

test/hotspot/jtreg/compiler/floatingpoint/TestRoundFloatAll.java line 75:

> 73:         return (int) a;
> 74:     }
> 75:   }

At first, I was worried about the indentation, then realized the original code had the strange indentation.
Would there be a way to put this method in a shared file, so that you do not need to paste it everywhere?

test/hotspot/jtreg/compiler/vectorization/TestRoundVectorFloatAll.java line 34:

> 32:  * @run main/othervm -XX:+PrintIdeal -XX:-TieredCompilation -XX:CompileThresholdScaling=0.3 -XX:MaxVectorSize=8 -XX:+UseSuperWord -XX:CompileCommand=compileonly,compiler.vectorization.TestRoundVectorFloatAll::test* compiler.vectorization.TestRoundVectorFloatAll
> 33:  * @run main/othervm -XX:+PrintIdeal -XX:-TieredCompilation -XX:CompileThresholdScaling=0.3 -XX:MaxVectorSize=16 -XX:+UseSuperWord -XX:CompileCommand=compileonly,compiler.vectorization.TestRoundVectorFloatAll::test* compiler.vectorization.TestRoundVectorFloatAll
> 34:  * @run main/othervm -XX:+PrintIdeal -XX:-TieredCompilation -XX:CompileThresholdScaling=0.3 -XX:MaxVectorSize=32 -XX:+UseSuperWord -XX:CompileCommand=compileonly,compiler.vectorization.TestRoundVectorFloatAll::test* compiler.vectorization.TestRoundVectorFloatAll

Please check which flags you actually need here....

test/hotspot/jtreg/compiler/vectorization/TestRoundVectorFloatAll.java line 43:

> 41: public class TestRoundVectorFloatAll {
> 42:   private static final int ITERS  = 11000;
> 43:   private static final int ARRLEN = 997;

Could you randomize this value ever so slightly? That way, the boundaries of the array are at different places. I think also that the size should be a little larger, just to ensure that we get maximum vector lengths.

test/hotspot/jtreg/compiler/vectorization/TestRoundVectorFloatRandom.java line 202:

> 200:     }
> 201: 
> 202:     // test cases for NaN, Inf, subnormal, and so on

just for completeness: +0.0 and -0.0

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

PR Review: https://git.openjdk.org/jdk/pull/17753#pullrequestreview-2043182218
PR Review Comment: https://git.openjdk.org/jdk/pull/17753#discussion_r1592477207
PR Review Comment: https://git.openjdk.org/jdk/pull/17753#discussion_r1592487797
PR Review Comment: https://git.openjdk.org/jdk/pull/17753#discussion_r1592499343
PR Review Comment: https://git.openjdk.org/jdk/pull/17753#discussion_r1592508616
PR Review Comment: https://git.openjdk.org/jdk/pull/17753#discussion_r1592481581

From epeter at openjdk.org  Tue May  7 13:46:57 2024
From: epeter at openjdk.org (Emanuel Peter)
Date: Tue, 7 May 2024 13:46:57 GMT
Subject: RFR: 8325438: Add exhaustive tests for Math.round intrinsics [v13]
In-Reply-To: <G46ChUfl3G0l3Do4CG962uC5tdb3QqmjbJHz-tCbxVI=.240f3c06-32aa-4c49-bdcc-fe3e313dd542@github.com>
References: <MeXDL6wupeFWkaG7n24umN_ylwTv8dL0Lt1Zt3RwcQ8=.ebc46c01-27c8-4268-b6c0-12a33a8d93fa@github.com>
 <yTfpBfWBMtjLm8BNvtocgxlBhgAKEVzpblP5OkyuTAM=.559b4718-ce15-4162-9f34-feda1d4a6398@github.com>
 <G46ChUfl3G0l3Do4CG962uC5tdb3QqmjbJHz-tCbxVI=.240f3c06-32aa-4c49-bdcc-fe3e313dd542@github.com>
Message-ID: <HN6cg5NMQH0Agdn50gVnu9NMjAKvlD_YGSZceX5sWp0=.f418a75d-d409-4685-8968-2845661e7785@github.com>

On Tue, 7 May 2024 13:23:48 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

>> Hamlin Li has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fix issues; modify vm options to make sure test the expected behaviors.
>
> test/hotspot/jtreg/compiler/floatingpoint/TestRoundFloatAll.java line 31:
> 
>> 29:  * @library /test/lib /
>> 30:  * @modules java.base/jdk.internal.math
>> 31:  * @run main/othervm -XX:-TieredCompilation -XX:CompileThresholdScaling=0.3 -XX:+PrintIdeal -XX:CompileCommand=compileonly,compiler.floatingpoint.TestRoundFloatAll::test* -XX:-UseSuperWord compiler.floatingpoint.TestRoundFloatAll
> 
> please break up the line for easier reading

Why these flags:
`-XX:-TieredCompilation -XX:CompileThresholdScaling=0.3 -XX:+PrintIdeal -XX:-UseSuperWord` ?

I also suggest that you use `-Xbatch`, just to make sure we have compiled all relevant methods after the warmup. If things get too slow, then maybe you want to consider using explicit compile exclusion / forbidding inlining for the `test*` method, rather than the compileonly, which prevents everything else from compiling.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17753#discussion_r1592498081

From redestad at openjdk.org  Tue May  7 14:59:21 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Tue, 7 May 2024 14:59:21 GMT
Subject: RFR: 8331724: Refactor j.l.constant implementation to internal
 package [v4]
In-Reply-To: <_GPUF9d1E6eBKRxP6bEEqA3LSKRJe2GwCRTfVYbDwFU=.cb482785-e7c4-45f7-bd3a-cd32d466a2cb@github.com>
References: <_GPUF9d1E6eBKRxP6bEEqA3LSKRJe2GwCRTfVYbDwFU=.cb482785-e7c4-45f7-bd3a-cd32d466a2cb@github.com>
Message-ID: <ZM1X_nrg15YVV0cUqREZ1VClez1vALZ59lYMPWXT0R4=.c072f9ac-5322-4e75-81fe-36c661628089@github.com>

> This PR suggests refactoring the implementation classes of java.lang.constant into a new package jdk.internal.constant to enable sharing some trusted static factory methods with users elsewhere in java.base, such as java.lang.invoke and java.lang.classfile. The refactoring also adds some "trusted" methods for use when input is pre-validated, and makes use of them where applicable in the current implementation. There are more changes in the pipeline which will be folded into #17108 or PR'ed once that is integrated. 
> 
> There are two optimizations mixed up here. One in `MethodTypeDesc.ofDescriptor`:
> 
> Name                                                             (descString) Cnt     Base     Error      Test   Error  Unit  Change
> MethodTypeDescFactories.ofDescriptor  (Ljava/lang/Object;Ljava/lang/String;)I   6  138,371 ?   0,767   136,939 ? 1,126 ns/op   1,01x (p = 0,000*)
> MethodTypeDescFactories.ofDescriptor                                      ()V   6   10,528 ?   2,495     4,110 ? 0,047 ns/op   2,56x (p = 0,000*)
> MethodTypeDescFactories.ofDescriptor ([IJLjava/lang/String;Z)Ljava/util/List;   6  209,390 ?   4,583   196,175 ? 3,211 ns/op   1,07x (p = 0,000*)
> MethodTypeDescFactories.ofDescriptor                    ()[Ljava/lang/String;   6   36,039 ?   8,684    20,794 ? 1,110 ns/op   1,73x (p = 0,000*)
> MethodTypeDescFactories.ofDescriptor                                 (..IIJ)V   6  279,139 ?   6,248   187,934 ? 0,857 ns/op   1,49x (p = 0,000*)
> MethodTypeDescFactories.ofDescriptor                 (.....................).   6 2174,387 ? 132,879  1150,652 ? 3,158 ns/op   1,89x (p = 0,000*)
>   * = significant
> 
> 
> The other in `ClassDesc::nested`, where to get rid of a simple static method in `ConstantUtils` I ended up speeding up and simplifying the public factory method:
> 
> Name                                      Cnt    Base     Error    Test   Error  Unit  Change
> ClassDescFactories.ReferenceOnly.ofNested   6 209,853 ? 132,525  22,017 ? 0,573 ns/op   9,53x (p = 0,000*)
>   * = significant
> 
> 
> The optimizations could be split out and PRd independently, but I think they are simple enough to include in this refactoring.

Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:

  pre-validated

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/19105/files
  - new: https://git.openjdk.org/jdk/pull/19105/files/f2f90193..543d0709

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

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

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

From vklang at openjdk.org  Tue May  7 15:03:13 2024
From: vklang at openjdk.org (Viktor Klang)
Date: Tue, 7 May 2024 15:03:13 GMT
Subject: RFR: 8048691: Spliterator.SORTED characteristics gets cleared for
 BaseStream.spliterator
Message-ID: <UwfOCAxTUpaES0HVbw420ehOFe8O_66Vfqz38hQBjXs=.abf59c16-d1e0-413d-bea7-ac276cb46e50@github.com>

Removes SORTED if not also ORDERED for escape-hatch `Stream::spliterator()`

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

Commit messages:
 - Make sure that escape-hatch spliterator()s don't report SORTED if they aren't also ORDERED

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

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

From liach at openjdk.org  Tue May  7 15:23:10 2024
From: liach at openjdk.org (Chen Liang)
Date: Tue, 7 May 2024 15:23:10 GMT
Subject: RFR: 8331744: java.lang.classfile.TypeKind improvements [v4]
In-Reply-To: <_x31CU5mODg3NGaRGzI5HdNdcjsKmqWb1TA7KZnZcFg=.43ce5ba3-71e7-42e5-a531-c3b609d0aafb@github.com>
References: <_x31CU5mODg3NGaRGzI5HdNdcjsKmqWb1TA7KZnZcFg=.43ce5ba3-71e7-42e5-a531-c3b609d0aafb@github.com>
Message-ID: <-6l188kBfGFxic3KxI-qxyVpPWEbwt4Z5O1nJbfCHQQ=.e460344f-b23f-4dcd-95a3-a12f478687d7@github.com>

> A peek into TypeKind during the research for #19105 reveals that TypeKind has a few issues:
> 1. Name mismatch for `newarraycode` and `fromNewArrayCode`: Renamed both to use "newarray code"
> 2. `fromDescriptor` can throw IOOBE if the input string is empty: changed to throw IAE and added tests.
> 3. `from(Class)` can be slow due to descriptor computation: added benchmark, will share result in next comment (as it may change with code changes).
> 
> The first 2 changes involves API changes, and a CSR has been created. Requesting @asotona for a review.

Chen Liang has updated the pull request incrementally with one additional commit since the last revision:

  Hash table, use fixed random seed

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/19109/files
  - new: https://git.openjdk.org/jdk/pull/19109/files/adf1218c..9af30c65

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

  Stats: 68 lines in 3 files changed: 53 ins; 8 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/19109.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19109/head:pull/19109

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

From liach at openjdk.org  Tue May  7 15:28:52 2024
From: liach at openjdk.org (Chen Liang)
Date: Tue, 7 May 2024 15:28:52 GMT
Subject: RFR: 8331744: java.lang.classfile.TypeKind improvements [v3]
In-Reply-To: <Sam_OIBH0AkulGMqY3fsVFz7RCGlQSQGgdz8fuVdhl4=.3fb53910-de22-43cd-84fe-da806aa2ee60@github.com>
References: <_x31CU5mODg3NGaRGzI5HdNdcjsKmqWb1TA7KZnZcFg=.43ce5ba3-71e7-42e5-a531-c3b609d0aafb@github.com>
 <mPPY2XzOtaKHcjekme5LkQMFwyXSeyKGRPNQCjSAcb8=.bdb8b4d8-7a53-4142-9e13-9373086ddb88@github.com>
 <Sam_OIBH0AkulGMqY3fsVFz7RCGlQSQGgdz8fuVdhl4=.3fb53910-de22-43cd-84fe-da806aa2ee60@github.com>
Message-ID: <u3cPsTG7iigtr-oS8hUc30yuLHKamewVwlCfUAAP7tU=.48de77af-60e6-485a-a8ab-f5c86c5dd0f8@github.com>

On Tue, 7 May 2024 10:46:41 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add a mixed scenario
>
> Nice improvement to the micro. It might be preferable to use random generation with a hardcoded or parameterized seed to reduce run-to-run variation, eg. `new Random(1)`.
> 
> Agree that call sites are unlikely to mix `CD` and `Class`, but we're likely to see the bimorphicness from passing Primitive and ReferenceCDs. This is typically a very small and constant call overhead.
> 
> The primitives path seem to be the weak link, and maybe we could take a cue from `sun.util.invoke.Wrapper` and set up a similar perfect hash table instead of a switch. This seem somewhat profitable:
> 
>  Name                            (type) Cnt    Base    Error     Test    Error  Unit  Change
> TypeKindBench.fromClassDescs PRIMITIVE   6 196,203 ?  2,469  147,898 ?  8,786 ns/op   1,33x (p = 0,000*)
> TypeKindBench.fromClasses    PRIMITIVE   6 325,336 ? 12,203  206,084 ?  2,180 ns/op   1,58x (p = 0,000*)
> 
> 
> The `fromClasses PRIMITIVE` case is still a bit behind since getting the descriptorString takes a few extra (non-allocating) steps.
> 
> Patch:
> 
> diff --git a/src/java.base/share/classes/java/lang/classfile/TypeKind.java b/src/java.base/share/classes/java/lang/classfile/TypeKind.java
> index 5ba566b3d06..dd0a06c63ea 100644
> --- a/src/java.base/share/classes/java/lang/classfile/TypeKind.java
> +++ b/src/java.base/share/classes/java/lang/classfile/TypeKind.java
> @@ -58,6 +58,7 @@ public enum TypeKind {
> 
>      private final String name;
>      private final String descriptor;
> +    private final char basicTypeChar;
>      private final int newarrayCode;
> 
>      /** {@return the human-readable name corresponding to this type} */
> @@ -100,6 +101,7 @@ public TypeKind asLoadable() {
>      TypeKind(String name, String descriptor, int newarrayCode) {
>          this.name = name;
>          this.descriptor = descriptor;
> +        this.basicTypeChar = descriptor.charAt(0);
>          this.newarrayCode = newarrayCode;
>      }
> 
> @@ -154,7 +156,29 @@ public static TypeKind fromDescriptor(CharSequence s) {
>       */
>      public static TypeKind from(TypeDescriptor.OfField<?> descriptor) {
>          return descriptor.isPrimitive() // implicit null check
> -                ? fromDescriptor(descriptor.descriptorString())
> +                ? ofPrimitive(descriptor.descriptorString())
>                  : TypeKind.ReferenceType;
>      }
> +
> +    // Perfect hashing for basic types, borrowed from sun.invoke.util.Wrapper
> +    private static final TypeKind[] FROM_CHAR = new TypeKind[16];
> +
> +    static {
> +        for (TypeKind w : values()) {
> +            if...

@cl4es I have tried 3 scenarios with the fixed seed: baseline before your comment, hash table over only primitives (your proposal), hash table over all chars (my uploaded patch)

All of these are without the specialization of `isPrimitive()`.

I observe that hash for all chars boosts the mixed scenario; cannot explain why exactly, but I go for hashing all chars because it should benefit the general-purpose `fromDescriptor`, used by ClassFile API's implementations too.

What do you think?

No hash table:

Benchmark                        (type)  Mode  Cnt    Score   Error  Units
TypeKindBench.fromClassDescs  PRIMITIVE  avgt    6  121.863 ? 3.968  ns/op
TypeKindBench.fromClassDescs  REFERENCE  avgt    6   56.158 ? 1.469  ns/op
TypeKindBench.fromClassDescs      MIXED  avgt    6  141.508 ? 5.412  ns/op
TypeKindBench.fromClasses     PRIMITIVE  avgt    6  232.201 ? 3.988  ns/op
TypeKindBench.fromClasses     REFERENCE  avgt    6   15.663 ? 0.359  ns/op
TypeKindBench.fromClasses         MIXED  avgt    6  155.033 ? 1.927  ns/op


Primitive-only hash:

Benchmark                        (type)  Mode  Cnt    Score   Error  Units
TypeKindBench.fromClassDescs  PRIMITIVE  avgt    6  112.731 ? 1.985  ns/op
TypeKindBench.fromClassDescs  REFERENCE  avgt    6   57.339 ? 1.119  ns/op
TypeKindBench.fromClassDescs      MIXED  avgt    6  126.926 ? 3.432  ns/op
TypeKindBench.fromClasses     PRIMITIVE  avgt    6  154.779 ? 4.008  ns/op
TypeKindBench.fromClasses     REFERENCE  avgt    6   15.619 ? 0.343  ns/op
TypeKindBench.fromClasses         MIXED  avgt    6  132.254 ? 2.133  ns/op


Current hash:

Benchmark                        (type)  Mode  Cnt    Score   Error  Units
TypeKindBench.fromClassDescs  PRIMITIVE  avgt    6  116.446 ? 6.085  ns/op
TypeKindBench.fromClassDescs  REFERENCE  avgt    6   56.399 ? 1.145  ns/op
TypeKindBench.fromClassDescs      MIXED  avgt    6  121.087 ? 2.410  ns/op
TypeKindBench.fromClasses     PRIMITIVE  avgt    6  154.842 ? 4.600  ns/op
TypeKindBench.fromClasses     REFERENCE  avgt    6   15.897 ? 0.454  ns/op
TypeKindBench.fromClasses         MIXED  avgt    6  118.444 ? 3.616  ns/op

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

PR Comment: https://git.openjdk.org/jdk/pull/19109#issuecomment-2098712190

From liach at openjdk.org  Tue May  7 15:30:25 2024
From: liach at openjdk.org (Chen Liang)
Date: Tue, 7 May 2024 15:30:25 GMT
Subject: RFR: 8311175: Move BufWriter::asByteBuffer to BufWriterImpl [v2]
In-Reply-To: <sEKITMKa0yBPrV7RTKYa0_GGSOss8a9T7GaOQpLaEYk=.f7ad0b39-bc77-4589-a8de-ef5132387e6c@github.com>
References: <sEKITMKa0yBPrV7RTKYa0_GGSOss8a9T7GaOQpLaEYk=.f7ad0b39-bc77-4589-a8de-ef5132387e6c@github.com>
Message-ID: <WidMqWYS_MrCK8InUBA6eJBAgPDS864GiE58fV-UDgA=.f4be212d-450b-4e60-8b2e-09d596285313@github.com>

> As discussed on the mailing list https://mail.openjdk.org/pipermail/classfile-api-dev/2023-June/000381.html, BufWriter::asByteBuffer has a behavior not suitable for API and is only used by internal StackMapGenerator/StackCounter, so it will be converted to an internal API.
> 
> Somehow the ByteBuffer needs to be sliced, or StackMapGenerator encounters IOOBE. Not sure what the exact cause was.

Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:

 - Merge branch 'master' of https://github.com/openjdk/jdk into fix/asbb-internal
 - Convert asByteBuffer to an internal API

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14736/files
  - new: https://git.openjdk.org/jdk/pull/14736/files/5c25188c..d82789c3

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

  Stats: 1808836 lines in 17143 files changed: 485717 ins; 823338 del; 499781 mod
  Patch: https://git.openjdk.org/jdk/pull/14736.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14736/head:pull/14736

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

From liach at openjdk.org  Tue May  7 15:38:53 2024
From: liach at openjdk.org (Chen Liang)
Date: Tue, 7 May 2024 15:38:53 GMT
Subject: RFR: 8331724: Refactor j.l.constant implementation to internal
 package [v4]
In-Reply-To: <ZM1X_nrg15YVV0cUqREZ1VClez1vALZ59lYMPWXT0R4=.c072f9ac-5322-4e75-81fe-36c661628089@github.com>
References: <_GPUF9d1E6eBKRxP6bEEqA3LSKRJe2GwCRTfVYbDwFU=.cb482785-e7c4-45f7-bd3a-cd32d466a2cb@github.com>
 <ZM1X_nrg15YVV0cUqREZ1VClez1vALZ59lYMPWXT0R4=.c072f9ac-5322-4e75-81fe-36c661628089@github.com>
Message-ID: <a4111udcY7F6zS4HYvrDfiUzrI9W84mUlRpK3_eBovc=.bc858210-0e3e-4271-8dd9-d56712cfff47@github.com>

On Tue, 7 May 2024 14:59:21 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> This PR suggests refactoring the implementation classes of java.lang.constant into a new package jdk.internal.constant to enable sharing some trusted static factory methods with users elsewhere in java.base, such as java.lang.invoke and java.lang.classfile. The refactoring also adds some "trusted" methods for use when input is pre-validated, and makes use of them where applicable in the current implementation. There are more changes in the pipeline which will be folded into #17108 or PR'ed once that is integrated. 
>> 
>> There are two optimizations mixed up here. One in `MethodTypeDesc.ofDescriptor`:
>> 
>> Name                                                             (descString) Cnt     Base     Error      Test   Error  Unit  Change
>> MethodTypeDescFactories.ofDescriptor  (Ljava/lang/Object;Ljava/lang/String;)I   6  138,371 ?   0,767   136,939 ? 1,126 ns/op   1,01x (p = 0,000*)
>> MethodTypeDescFactories.ofDescriptor                                      ()V   6   10,528 ?   2,495     4,110 ? 0,047 ns/op   2,56x (p = 0,000*)
>> MethodTypeDescFactories.ofDescriptor ([IJLjava/lang/String;Z)Ljava/util/List;   6  209,390 ?   4,583   196,175 ? 3,211 ns/op   1,07x (p = 0,000*)
>> MethodTypeDescFactories.ofDescriptor                    ()[Ljava/lang/String;   6   36,039 ?   8,684    20,794 ? 1,110 ns/op   1,73x (p = 0,000*)
>> MethodTypeDescFactories.ofDescriptor                                 (..IIJ)V   6  279,139 ?   6,248   187,934 ? 0,857 ns/op   1,49x (p = 0,000*)
>> MethodTypeDescFactories.ofDescriptor                 (.....................).   6 2174,387 ? 132,879  1150,652 ? 3,158 ns/op   1,89x (p = 0,000*)
>>   * = significant
>> 
>> 
>> The other in `ClassDesc::nested`, where to get rid of a simple static method in `ConstantUtils` I ended up speeding up and simplifying the public factory method:
>> 
>> Name                                      Cnt    Base     Error    Test   Error  Unit  Change
>> ClassDescFactories.ReferenceOnly.ofNested   6 209,853 ? 132,525  22,017 ? 0,573 ns/op   9,53x (p = 0,000*)
>>   * = significant
>> 
>> 
>> The optimizations could be split out and PRd independently, but I think they are simple enough to include in this refactoring.
>
> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   pre-validated

Since you are removing the redundant validation for `MethodTypeDesc::ofDescriptor`, we can move the ClassDesc array scan to the `of(ClassDesc, ClassDesc...)` factory and the factories that insert parameter types/replace a parameter. This way, we can reduce a lot of validation as well, especially that we in fact do insert parameters a lot (for `ofCallsiteBootstrap` and `ofConstantBoostrap`)

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

PR Comment: https://git.openjdk.org/jdk/pull/19105#issuecomment-2098743577

From mcimadamore at openjdk.org  Tue May  7 15:49:01 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 7 May 2024 15:49:01 GMT
Subject: RFR: 8331734: Atomic MemorySegment VarHandle operations fails for
 element layouts
Message-ID: <_PQ4wP4lk_STKwnSddD-5GgfsCheLbT_MR9zIyQyE78=.4ae37fdc-cf6e-46ea-8dbe-afcd1e710666@github.com>

This PR fixes an issue that has crept into the FFM API implementation.

>From very early stages, the FFM API used to disable the alignment check on nested layout elements, in favor of an alignment check against the memory segment base address. The rationale was that the JIT had issue with eliminating redundant alignment checks, and accessing nested elements could never result in alignment issues, since the alignment of the container is provably bigger than that of the contained element. This means that, when creating a var handle for a nested layout element, we set the nested layout alignment to 1 (unaligned), derive its var handle, and then decorate the var handle with an alignment check for the container.

At some point in 22, we tweaked the API to throw `UnsupportedOperationException` when using an access mode incompatible with the alignment constraint of the accessed layout. That is, a volatile read on an `int` is only possible if the access occurs at an address that is at least 4-byte aligned. Otherwise an `UOE` is thrown.

Unfortunately this change broke the aforementioned optimization: creating a var handle for an unaligned layout works, but the resulting layout will *not* support any of the atomic access modes.

Since this optimization is not really required anymore (proper C2 support to hoist/eliminate alignment checks has been added since then), it is better to disable this implementation quirk, and leave optimizations to C2.

(If we really really wanted to optimize things a bit, we could remove the container alignment check in the case the accessed value is the first layout element nested in the container, but this PR doesn't go that far).

I've run relevant benchmarks before/after and found no differences. In part this is because `arrayElementVarHandle` is unaffected. But, even after tweaking the `LoopOverNonConstant` benchmark to add explicit tests for the code path affected, no significant difference was found, sign that C2 is indeed able to spot (and remove) the redundant alignment check. Note: if we know that `aligned_to_N(base)` holds, then it's easy to prove that `aligned_to_M(base + offset + index * scale)` holds, when `N >= M` and with `offset` and `scale` known (the latter a power of two).

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

Commit messages:
 - Drop JDK property
 - Initial pusg

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

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

From prappo at openjdk.org  Tue May  7 16:11:57 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Tue, 7 May 2024 16:11:57 GMT
Subject: RFR: 8305457: Implement java.io.IO
In-Reply-To: <OOeWi7f89VKud_6Sp7Z9AMdzPXexJl6sb6N6k-T2xFs=.5c5af026-02da-4d9d-987c-d62eaaf54ff6@github.com>
References: <w2msiw_qaMEIJS3s9D4bg8pFbz5WIF0KdP6Mm-XFjLI=.85b2020b-8c46-4bac-8a69-4975b068f2ff@github.com>
 <hVlQ7frdWV-o3-F0NHmZu1dnQqu2ZZqC03IFbR-I-yE=.c611d97e-31a9-4d22-9f53-b1bdd71467c5@github.com>
 <yQGqIb5RQtadQA_bu-8JdUJDUdi_UEySF8Sm1-Bb5-c=.03331a10-d436-4ae7-8c88-e8d7649e8ec5@github.com>
 <OOeWi7f89VKud_6Sp7Z9AMdzPXexJl6sb6N6k-T2xFs=.5c5af026-02da-4d9d-987c-d62eaaf54ff6@github.com>
Message-ID: <7n1hCAP6_sXuoIWhRSSjV9qcAMbQGU7jOrbl9YE3Gk8=.4cc275ad-a3f5-486f-80f1-3a1fb5fede41@github.com>

On Tue, 7 May 2024 12:17:36 GMT, R?mi Forax <forax at openjdk.org> wrote:

> I do not think the step to "standardise" a preview feature exists ? When a preview feature becomes a released feature, the code is very lightly edited, at least it this is my experience.

We may call it differently, but I think both you and I are referring to this part of [JEP 12](https://openjdk.org/jeps/12) (emphasis mine):

> Eventually, the JEP owner must decide the preview feature's fate. If the decision is to remove the preview feature, then the owner must file an issue in JBS to remove the feature in the next JDK feature release; no new JEP is needed. **On the other hand, if the decision is to finalize, then the owner must file a new JEP, noting refinements informed by developer feedback. The title of this JEP should be the feature's name, omitting the earlier suffix of (Preview) / (Second Preview), and without adding any new suffix such as (Standard) or (Final). This JEP will ultimately reach Targeted status for the next JDK feature release.**

> You can change both readln and readLine and if `java.io.IO` is removed, at least the code of readLine() will be

Sorry, R?mi, but no. As long as this feature is in preview, I'd optimise for easier removal (back out) of the feature rather than clean combined code.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19112#discussion_r1592740269

From pminborg at openjdk.org  Tue May  7 16:34:52 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 7 May 2024 16:34:52 GMT
Subject: RFR: 8331734: Atomic MemorySegment VarHandle operations fails for
 element layouts
In-Reply-To: <_PQ4wP4lk_STKwnSddD-5GgfsCheLbT_MR9zIyQyE78=.4ae37fdc-cf6e-46ea-8dbe-afcd1e710666@github.com>
References: <_PQ4wP4lk_STKwnSddD-5GgfsCheLbT_MR9zIyQyE78=.4ae37fdc-cf6e-46ea-8dbe-afcd1e710666@github.com>
Message-ID: <JcP1Z-GMVUsHRGEKgnexYl62CI-URv4lfrTS2y53cDM=.f9511f9c-4ef1-481a-8d22-256d156295c6@github.com>

On Tue, 7 May 2024 15:42:23 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> This PR fixes an issue that has crept into the FFM API implementation.
> 
> From very early stages, the FFM API used to disable the alignment check on nested layout elements, in favor of an alignment check against the memory segment base address. The rationale was that the JIT had issue with eliminating redundant alignment checks, and accessing nested elements could never result in alignment issues, since the alignment of the container is provably bigger than that of the contained element. This means that, when creating a var handle for a nested layout element, we set the nested layout alignment to 1 (unaligned), derive its var handle, and then decorate the var handle with an alignment check for the container.
> 
> At some point in 22, we tweaked the API to throw `UnsupportedOperationException` when using an access mode incompatible with the alignment constraint of the accessed layout. That is, a volatile read on an `int` is only possible if the access occurs at an address that is at least 4-byte aligned. Otherwise an `UOE` is thrown.
> 
> Unfortunately this change broke the aforementioned optimization: creating a var handle for an unaligned layout works, but the resulting layout will *not* support any of the atomic access modes.
> 
> Since this optimization is not really required anymore (proper C2 support to hoist/eliminate alignment checks has been added since then), it is better to disable this implementation quirk, and leave optimizations to C2.
> 
> (If we really really wanted to optimize things a bit, we could remove the container alignment check in the case the accessed value is the first layout element nested in the container, but this PR doesn't go that far).
> 
> I've run relevant benchmarks before/after and found no differences. In part this is because `arrayElementVarHandle` is unaffected. But, even after tweaking the `LoopOverNonConstant` benchmark to add explicit tests for the code path affected, no significant difference was found, sign that C2 is indeed able to spot (and remove) the redundant alignment check. Note: if we know that `aligned_to_N(base)` holds, then it's easy to prove that `aligned_to_M(base + offset + index * scale)` holds, when `N >= M` and with `offset` and `scale` known (the latter a power of two).

LGTM. As mentioned in the PR notes, additional optimizations could be made and this could be the objective of a future PR.

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

Marked as reviewed by pminborg (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19124#pullrequestreview-2043680093

From naoto at openjdk.org  Tue May  7 16:37:55 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 7 May 2024 16:37:55 GMT
Subject: RFR: 8305457: Implement java.io.IO
In-Reply-To: <w2msiw_qaMEIJS3s9D4bg8pFbz5WIF0KdP6Mm-XFjLI=.85b2020b-8c46-4bac-8a69-4975b068f2ff@github.com>
References: <w2msiw_qaMEIJS3s9D4bg8pFbz5WIF0KdP6Mm-XFjLI=.85b2020b-8c46-4bac-8a69-4975b068f2ff@github.com>
Message-ID: <oPnpS6oaWew4cUZCzwMCOG9AvMvSMLuIkRhcJAjEefU=.46da5ff7-f99f-498d-aa3f-99147dae0195@github.com>

On Mon, 6 May 2024 21:45:12 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> Please review this PR which introduces the `java.io.IO` top-level class and three methods to `java.io.Console` for [Implicitly Declared Classes and Instance Main Methods (Third Preview)].
> 
> This PR has been obtained as `git merge --squash` of a now obsolete [draft PR].
> 
> [Implicitly Declared Classes and Instance Main Methods (Third Preview)]: https://bugs.openjdk.org/browse/JDK-8323335
> [draft PR]: https://github.com/openjdk/jdk/pull/18921

Looks good overall. Left some minor comments.

src/java.base/share/classes/java/io/Console.java line 189:

> 187:     /**
> 188:      * Writes a prompt as if by calling {@code print}, then reads a single line
> 189:      * of text from this system console.

Nit: I would not add `system` here as `this console` is consistent with other locations.

src/java.base/share/classes/java/io/ProxyingConsole.java line 107:

> 105:      * {@inheritDoc}
> 106:      *
> 107:      * @throws IOError {@inheritDoc}

Probably I am missing something, but I see `Console` declares this throws clause. Do we need this inheritDoc here?

test/jdk/java/io/IO/IO.java line 99:

> 97:                 System.getProperty("test.jdk") + "/bin/java",
> 98:                 "--enable-preview",
> 99:                 "-Djdk.console=gibberish",

The test comment suggests this test is testing the default console implementation, but the invocation specifies `-Djdk.console=gibberish` which defaults to java.base. Is this what you intended?

test/jdk/java/io/IO/Input.java line 33:

> 31:         System.out.print(readln("?"));
> 32:     }
> 33: }

Needs a newline

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

PR Review: https://git.openjdk.org/jdk/pull/19112#pullrequestreview-2041904750
PR Review Comment: https://git.openjdk.org/jdk/pull/19112#discussion_r1591704961
PR Review Comment: https://git.openjdk.org/jdk/pull/19112#discussion_r1592764263
PR Review Comment: https://git.openjdk.org/jdk/pull/19112#discussion_r1592773917
PR Review Comment: https://git.openjdk.org/jdk/pull/19112#discussion_r1592776068

From naoto at openjdk.org  Tue May  7 16:45:53 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 7 May 2024 16:45:53 GMT
Subject: RFR: JDK-8331646: Add specific regression leap year tests (Task -
 P4) [v2]
In-Reply-To: <jVsUCuB16T9wnWispfbUcU7fCsN4ucmYlbzWKrD2638=.2aa43d44-3e8e-485d-a7e3-d196daf2aafd@github.com>
References: <cB-Q8ihe6DYQTm1WcRvVV3oW8YXtnWH5fmsS1zurwwY=.176d4137-bd3b-445e-a055-c738bd73744c@github.com>
 <jVsUCuB16T9wnWispfbUcU7fCsN4ucmYlbzWKrD2638=.2aa43d44-3e8e-485d-a7e3-d196daf2aafd@github.com>
Message-ID: <2UWQj4csbOaSZ8Y7-tVp7dBb4CZaPGk9VrF4fU_T2Bs=.7b1d6b60-7063-4c47-8b49-1da47177fcb6@github.com>

On Tue, 7 May 2024 09:44:09 GMT, serhiysachkov <duke at openjdk.org> wrote:

>> Calendar.add() tests that describe its behavior.
>
> serhiysachkov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   JDK-8331646 updating to ParameterizedTests according to review request

Sorry if I was unclear, but I meant to consolidate the test methods, as they are duplicates other than the calendar values. Those values should be parametrized and consolidate the test body into a single method.

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

PR Comment: https://git.openjdk.org/jdk/pull/19082#issuecomment-2098881008

From sgehwolf at openjdk.org  Tue May  7 16:52:12 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Tue, 7 May 2024 16:52:12 GMT
Subject: RFR: 8311302: Allow for jlinking a custom runtime without packaged
 modules being present [v26]
In-Reply-To: <Z0DJ87uKPbjS6mvJIE_oG5m-RWsbERXsytSgV8Bmhdo=.f8723513-0ac6-4e85-9131-3c3924860c61@github.com>
References: <Z0DJ87uKPbjS6mvJIE_oG5m-RWsbERXsytSgV8Bmhdo=.f8723513-0ac6-4e85-9131-3c3924860c61@github.com>
Message-ID: <RUr5xr-pzsccK28vRBO-GhY-8RltknEX2lyMgWpijnA=.980d0b9d-f219-4bc7-bf64-4e343f44ac7d@github.com>

> Please review this patch which adds a jlink mode to the JDK which doesn't need the packaged modules being present. A.k.a run-time image based jlink. Fundamentally this patch adds an option to use `jlink` even though your JDK install might not come with the packaged modules (directory `jmods`). This is particularly useful to further reduce the size of a jlinked runtime. After the removal of the concept of a JRE, a common distribution mechanism is still the full JDK with all modules and packaged modules. However, packaged modules can incur an additional size tax. For example in a container scenario it could be useful to have a base JDK container including all modules, but without also delivering the packaged modules. This comes at a size advantage of `~25%`. Such a base JDK container could then be used to `jlink` application specific runtimes, further reducing the size of the application runtime image (App + JDK runtime; as a single image *or* separate bundles, depending on the app b
 eing modularized).
> 
> The basic design of this approach is to add a jlink plugin for tracking non-class and non-resource files of a JDK install. I.e. files which aren't present in the jimage (`lib/modules`). This enables producing a `JRTArchive` class which has all the info of what constitutes the final jlinked runtime.
> 
> Basic usage example:
> 
> $ diff -u <(./bin/java --list-modules --limit-modules java.se) <(../linux-x86_64-server-release/images/jdk/bin/java --list-modules --limit-modules java.se)
> $ diff -u <(./bin/java --list-modules --limit-modules jdk.jlink) <(../linux-x86_64-server-release/images/jdk/bin/java --list-modules --limit-modules jdk.jlink)
> $ ls ../linux-x86_64-server-release/images/jdk/jmods
> java.base.jmod            java.net.http.jmod       java.sql.rowset.jmod      jdk.crypto.ec.jmod         jdk.internal.opt.jmod                     jdk.jdi.jmod         jdk.management.agent.jmod  jdk.security.auth.jmod
> java.compiler.jmod        java.prefs.jmod          java.transaction.xa.jmod  jdk.dynalink.jmod          jdk.internal.vm.ci.jmod                   jdk.jdwp.agent.jmod  jdk.management.jfr.jmod    jdk.security.jgss.jmod
> java.datatransfer.jmod    java.rmi.jmod            java.xml.crypto.jmod      jdk.editpad.jmod           jdk.internal.vm.compiler.jmod             jdk.jfr.jmod         jdk.management.jmod        jdk.unsupported.desktop.jmod
> java.desktop.jmod         java.scripting.jmod      java.xml.jmod             jdk.hotspot.agent.jmod     jdk.internal.vm.compiler.manage...

Severin Gehwolf has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 105 commits:

 - Generate the runtime image link diff at jlink time
   
   But only do that once the plugin-pipeline has run. The generation is
   enabled with the hidden option '--generate-linkable-runtime' and
   the resource pools available at jlink time are being used to generate
   the diff.
 - Merge branch 'master' into jdk-8311302-jmodless-link
 - Use shorter name for the build tool
 - Review feedback from Erik J.
 - Remove dependency on CDS which isn't needed anymore
 - Fix coment
 - Fix comment
 - Fix typo
 - Revert some now unneded build changes
 - Follow build tools naming convention
 - ... and 95 more: https://git.openjdk.org/jdk/compare/23a72a1f...67aea4ca

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

Changes: https://git.openjdk.org/jdk/pull/14787/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14787&range=25
  Stats: 3424 lines in 36 files changed: 3272 ins; 110 del; 42 mod
  Patch: https://git.openjdk.org/jdk/pull/14787.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14787/head:pull/14787

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

From duke at openjdk.org  Tue May  7 16:54:59 2024
From: duke at openjdk.org (ExE Boss)
Date: Tue, 7 May 2024 16:54:59 GMT
Subject: RFR: 8331724: Refactor j.l.constant implementation to internal
 package [v4]
In-Reply-To: <hohcB4WlKVsViNIKgM4g-i92YBGOlX5jjAm1OvOzEZ0=.7834fb7b-89a2-44be-b177-a988966ae84a@github.com>
References: <_GPUF9d1E6eBKRxP6bEEqA3LSKRJe2GwCRTfVYbDwFU=.cb482785-e7c4-45f7-bd3a-cd32d466a2cb@github.com>
 <nAQ7IrGzu02gL7b7zzrsaiOOE_noLmvWk74xeyjFy9Q=.7dd9f135-44c0-4bd7-879b-180b70c39c44@github.com>
 <hohcB4WlKVsViNIKgM4g-i92YBGOlX5jjAm1OvOzEZ0=.7834fb7b-89a2-44be-b177-a988966ae84a@github.com>
Message-ID: <rwBp49Vi9zwMRykEvwAYLd44-fnnRIKwQPL3utwQd_I=.4307e2fd-bc70-4e92-b2d3-7cbad9516565@github.com>

On Mon, 6 May 2024 15:18:17 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/constant/ClassDesc.java line 222:
>> 
>>> 220:         }
>>> 221:         if (desc.length() == 1 && desc.charAt(0) == 'V') {
>>> 222:             throw new IllegalArgumentException(String.format("not a valid reference type descriptor: %sV", "[".repeat(rank)));
>> 
>> Suggestion:
>> 
>>             throw new IllegalArgumentException(String.format("not a valid reference type descriptor: %sV", "[".repeat(netRank)));
>> 
>> Or should we override this in `PrimitiveClassDescImpl`, which can bypass the rank sum computation?
>
> `currentDepth` must be 0 in this case, so `rank` or `netRank` doesn't matter. Overriding in `PrimitiveClassDescImpl` sounds reasonable, but then perhaps default method should be removed, too, since it would look strange to have the default method be specialized for instance/array types. Sounds like a CSR might be needed(?), so let's do that in a follow up.

I?don?t?think a?**CSR** is?needed for?changing the?`default`ness of?JDK?sealed interface?methods, as?source and?binary?compatibility for?external?users is?unaffected.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19105#discussion_r1592783700

From sgehwolf at openjdk.org  Tue May  7 16:55:08 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Tue, 7 May 2024 16:55:08 GMT
Subject: RFR: 8311302: Allow for jlinking a custom runtime without packaged
 modules being present [v23]
In-Reply-To: <DpJV4x9Mnw0upmd3SR_ES2ytuLAo7PsI-ecHERPAOcY=.0a0c2f26-7a9f-4be6-8e71-0494d4673fe7@github.com>
References: <Z0DJ87uKPbjS6mvJIE_oG5m-RWsbERXsytSgV8Bmhdo=.f8723513-0ac6-4e85-9131-3c3924860c61@github.com>
 <Xkl8CJMCXm7iBI2ZnfH9JnoZx08wd5InSwIZHW_kMeQ=.49022322-cb0d-4f1a-947a-6eb37b7da963@github.com>
 <fvDpjxyhqnpaEhF6KhMIJBv_sG87AsuC0axsJYo1Tvw=.442f5a11-44f0-4a00-812a-2c26ec15e8e6@github.com>
 <_sbNFJXG7ghwsfNfxaGvvoDQ7-UtWpnhGnygKsFTsgQ=.623700db-7306-4b34-9e05-ca9059797e39@github.com>
 <DpJV4x9Mnw0upmd3SR_ES2ytuLAo7PsI-ecHERPAOcY=.0a0c2f26-7a9f-4be6-8e71-0494d4673fe7@github.com>
Message-ID: <wu0DJlTWvTBUOtZw6tFUI19BRRRnJzNxJ98cay1p6XE=.ec07fc99-996a-4b0d-9a59-213b5225a0b1@github.com>

On Tue, 16 Apr 2024 13:54:53 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>>> > @mlchung @AlanBateman Any thoughts on this latest version? Is this going into the direction you had envisioned? Any more blockers? The CSR should be up-to-date and is open for review as well. If no more blockers I'll go over this patch once more and clean it up to prepare for integration. Thanks!
>>> 
>>> Thanks for all the efforts on this.
>> 
>> Thanks for looking at this, Alan!
>> 
>>> I've looked through the latest version. I'm a little bit comfortable with LinkDeltaProducer. One reason it's build tool that is tied tied to code in the jdk.jlink module, and secondly is that it copies runtime-image-link.delta into the run-time image. Our long standing position is that the run-time image is created by jlink rather than a combination of jlink and extra stuff copied in by the build.
>>> 
>>> The part that I like with the current proposal is lib/runtime-image-link.delta as it's less complicated that previous iterations that added a resource into the jimage container.
>>> 
>>> What would you (and @mlchung) think of having jlink generate lib/runtime-image-link.delta as a step between the pipeline and image generation?
>> 
>> If I understand you correctly, this would be no longer a build-time only approach to produce the "linkable runtime"? It would be some-kind of jlink-option driven approach (as it would run some code that should only run when producing a linkable runtime is requested)? Other than that, it should be fine as the previous iteration basically did that but at a different phase. Also note that the previous iteration used a build-only jlink plugin so as to satisfy the build-time only approach, yet it ran as part of the plugin-pipeline which wasn't desired either. But it was something similar to what you seem to be describing now. Did I get something wrong?
>
>> If I understand you correctly, this would be no longer a build-time only approach to produce the "linkable runtime"? It would be some-kind of jlink-option driven approach (as it would run some code that should only run when producing a linkable runtime is requested)? Other than that, it should be fine as the previous iteration basically did that but at a different phase. Also note that the previous iteration used a build-only jlink plugin so as to satisfy the build-time only approach, yet it ran as part of the plugin-pipeline which wasn't desired either. But it was something similar to what you seem to be describing now. Did I get something wrong?
> 
> I think it continues to build time, it's just using some hidden jlink option. So yes, it similar to a previous iteration except that it doesn't run as a plugin the pipeline and the delta goes to the lib directory.
> 
> Let's see what @mlchung says. You've put a lot of work into this so let's see if we can converge to avoid too many more rounds.

@AlanBateman @mlchung The latest update now uses the `jlink` build time option `--generate-linkable-runtime` to add needed resources to the `jimage` when a runtime linkable JDK image is being asked for using the configure option. This now runs outside the plugin-pipeline. I think this is what you meant. Sorry it took longer to get back to this...

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

PR Comment: https://git.openjdk.org/jdk/pull/14787#issuecomment-2098895722

From prappo at openjdk.org  Tue May  7 17:01:53 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Tue, 7 May 2024 17:01:53 GMT
Subject: RFR: 8305457: Implement java.io.IO
In-Reply-To: <oPnpS6oaWew4cUZCzwMCOG9AvMvSMLuIkRhcJAjEefU=.46da5ff7-f99f-498d-aa3f-99147dae0195@github.com>
References: <w2msiw_qaMEIJS3s9D4bg8pFbz5WIF0KdP6Mm-XFjLI=.85b2020b-8c46-4bac-8a69-4975b068f2ff@github.com>
 <oPnpS6oaWew4cUZCzwMCOG9AvMvSMLuIkRhcJAjEefU=.46da5ff7-f99f-498d-aa3f-99147dae0195@github.com>
Message-ID: <HahWNODCYygUO446By-0_h5x_oQ_Oj4FjwP4l__votg=.2af250d7-e139-415f-bd3c-ea28a5dbb388@github.com>

On Tue, 7 May 2024 01:20:39 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Please review this PR which introduces the `java.io.IO` top-level class and three methods to `java.io.Console` for [Implicitly Declared Classes and Instance Main Methods (Third Preview)].
>> 
>> This PR has been obtained as `git merge --squash` of a now obsolete [draft PR].
>> 
>> [Implicitly Declared Classes and Instance Main Methods (Third Preview)]: https://bugs.openjdk.org/browse/JDK-8323335
>> [draft PR]: https://github.com/openjdk/jdk/pull/18921
>
> src/java.base/share/classes/java/io/Console.java line 189:
> 
>> 187:     /**
>> 188:      * Writes a prompt as if by calling {@code print}, then reads a single line
>> 189:      * of text from this system console.
> 
> Nit: I would not add `system` here as `this console` is consistent with other locations.

That is a typo; thanks!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19112#discussion_r1592805571

From liach at openjdk.org  Tue May  7 17:04:52 2024
From: liach at openjdk.org (Chen Liang)
Date: Tue, 7 May 2024 17:04:52 GMT
Subject: RFR: 8331724: Refactor j.l.constant implementation to internal
 package [v4]
In-Reply-To: <rwBp49Vi9zwMRykEvwAYLd44-fnnRIKwQPL3utwQd_I=.4307e2fd-bc70-4e92-b2d3-7cbad9516565@github.com>
References: <_GPUF9d1E6eBKRxP6bEEqA3LSKRJe2GwCRTfVYbDwFU=.cb482785-e7c4-45f7-bd3a-cd32d466a2cb@github.com>
 <nAQ7IrGzu02gL7b7zzrsaiOOE_noLmvWk74xeyjFy9Q=.7dd9f135-44c0-4bd7-879b-180b70c39c44@github.com>
 <hohcB4WlKVsViNIKgM4g-i92YBGOlX5jjAm1OvOzEZ0=.7834fb7b-89a2-44be-b177-a988966ae84a@github.com>
 <rwBp49Vi9zwMRykEvwAYLd44-fnnRIKwQPL3utwQd_I=.4307e2fd-bc70-4e92-b2d3-7cbad9516565@github.com>
Message-ID: <VAXTXRZ_1hN9moXmfGYXhdfPUk4oyR8J8LW6yZONWZY=.e0e74b3b-89f5-4bc3-8e52-613dd954f90f@github.com>

On Tue, 7 May 2024 16:40:08 GMT, ExE Boss <duke at openjdk.org> wrote:

>> `currentDepth` must be 0 in this case, so `rank` or `netRank` doesn't matter. Overriding in `PrimitiveClassDescImpl` sounds reasonable, but then perhaps default method should be removed, too, since it would look strange to have the default method be specialized for instance/array types. Sounds like a CSR might be needed(?), so let's do that in a follow up.
>
> I?don?t?think a?**CSR** is?needed for?changing the?`default`ness of?JDK?sealed interface?methods, as?source and?binary?compatibility for?external?users is?unaffected.

A CSR is required when defaultness is removed, as in https://bugs.openjdk.org/browse/JDK-8309755

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19105#discussion_r1592810075

From weijun at openjdk.org  Tue May  7 17:13:15 2024
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 7 May 2024 17:13:15 GMT
Subject: RFR: 8331864: Update Public Suffix List to 1cbd6e7
Message-ID: <eVDe7UeP7BMbCr0wS1jSxqss6prZwLGar-QY9Ms64tw=.68f20635-bf74-4003-b07b-bc8c3483d6d6@github.com>

Update PSL to the latest upstream version.

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

Commit messages:
 - the change

Changes: https://git.openjdk.org/jdk/pull/19127/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19127&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8331864
  Stats: 568 lines in 5 files changed: 408 ins; 104 del; 56 mod
  Patch: https://git.openjdk.org/jdk/pull/19127.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19127/head:pull/19127

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

From prappo at openjdk.org  Tue May  7 17:17:53 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Tue, 7 May 2024 17:17:53 GMT
Subject: RFR: 8305457: Implement java.io.IO
In-Reply-To: <oPnpS6oaWew4cUZCzwMCOG9AvMvSMLuIkRhcJAjEefU=.46da5ff7-f99f-498d-aa3f-99147dae0195@github.com>
References: <w2msiw_qaMEIJS3s9D4bg8pFbz5WIF0KdP6Mm-XFjLI=.85b2020b-8c46-4bac-8a69-4975b068f2ff@github.com>
 <oPnpS6oaWew4cUZCzwMCOG9AvMvSMLuIkRhcJAjEefU=.46da5ff7-f99f-498d-aa3f-99147dae0195@github.com>
Message-ID: <aIf4sgfHDBX_0iVghGYlcA4rGVwC1R0uOItaSI72Z1M=.004b8b95-8de7-40ee-a3e3-2b41c2d474f3@github.com>

On Tue, 7 May 2024 16:32:46 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Please review this PR which introduces the `java.io.IO` top-level class and three methods to `java.io.Console` for [Implicitly Declared Classes and Instance Main Methods (Third Preview)].
>> 
>> This PR has been obtained as `git merge --squash` of a now obsolete [draft PR].
>> 
>> [Implicitly Declared Classes and Instance Main Methods (Third Preview)]: https://bugs.openjdk.org/browse/JDK-8323335
>> [draft PR]: https://github.com/openjdk/jdk/pull/18921
>
> test/jdk/java/io/IO/IO.java line 99:
> 
>> 97:                 System.getProperty("test.jdk") + "/bin/java",
>> 98:                 "--enable-preview",
>> 99:                 "-Djdk.console=gibberish",
> 
> The test comment suggests this test is testing the default console implementation, but the invocation specifies `-Djdk.console=gibberish` which defaults to java.base. Is this what you intended?

That comment says that this test tests jdk.internal.io.JdkConsoleImpl, which belongs to java.base. But, if you read it the way you described, I should definitely rephrase it.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19112#discussion_r1592824491

From mli at openjdk.org  Tue May  7 17:32:19 2024
From: mli at openjdk.org (Hamlin Li)
Date: Tue, 7 May 2024 17:32:19 GMT
Subject: RFR: 8325438: Add exhaustive tests for Math.round intrinsics [v14]
In-Reply-To: <MeXDL6wupeFWkaG7n24umN_ylwTv8dL0Lt1Zt3RwcQ8=.ebc46c01-27c8-4268-b6c0-12a33a8d93fa@github.com>
References: <MeXDL6wupeFWkaG7n24umN_ylwTv8dL0Lt1Zt3RwcQ8=.ebc46c01-27c8-4268-b6c0-12a33a8d93fa@github.com>
Message-ID: <B1pO9tvwUUXm4l59_JgOxbeHj7530SpktXWDx6TflyY=.de8c90c6-0a64-4b0b-9433-4817e2bf9d7f@github.com>

> HI,
> Can you have a look at this patch adding some tests for Math.round instrinsics?
> Thanks!
> 
> ### FYI:
> During the development of RoundVF/RoundF, we faced the issues which were only spotted by running test exhaustively against 32/64 bits range of int/long.
> It's helpful to add these exhaustive tests in jdk for future possible usage, rather than build it everytime when needed.
> Of course, we need to put it in `manual` mode, so it's not run when `-automatic` jtreg option is specified which I guess is the mode CI used, please correct me if I'm assume incorrectly.

Hamlin Li has updated the pull request incrementally with one additional commit since the last revision:

  misc fixes

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17753/files
  - new: https://git.openjdk.org/jdk/pull/17753/files/b5207436..7c2ef4fb

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17753&range=13
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17753&range=12-13

  Stats: 251 lines in 5 files changed: 107 ins; 131 del; 13 mod
  Patch: https://git.openjdk.org/jdk/pull/17753.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17753/head:pull/17753

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

From mli at openjdk.org  Tue May  7 17:32:20 2024
From: mli at openjdk.org (Hamlin Li)
Date: Tue, 7 May 2024 17:32:20 GMT
Subject: RFR: 8325438: Add exhaustive tests for Math.round intrinsics [v13]
In-Reply-To: <HN6cg5NMQH0Agdn50gVnu9NMjAKvlD_YGSZceX5sWp0=.f418a75d-d409-4685-8968-2845661e7785@github.com>
References: <MeXDL6wupeFWkaG7n24umN_ylwTv8dL0Lt1Zt3RwcQ8=.ebc46c01-27c8-4268-b6c0-12a33a8d93fa@github.com>
 <yTfpBfWBMtjLm8BNvtocgxlBhgAKEVzpblP5OkyuTAM=.559b4718-ce15-4162-9f34-feda1d4a6398@github.com>
 <G46ChUfl3G0l3Do4CG962uC5tdb3QqmjbJHz-tCbxVI=.240f3c06-32aa-4c49-bdcc-fe3e313dd542@github.com>
 <HN6cg5NMQH0Agdn50gVnu9NMjAKvlD_YGSZceX5sWp0=.f418a75d-d409-4685-8968-2845661e7785@github.com>
Message-ID: <41rVYJ90K1TmX9w8v2eZxPcaxH0YL8D3wrzQiEd7mnU=.a1458bea-4570-40ae-b052-523c413d26bd@github.com>

On Tue, 7 May 2024 13:36:55 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

>> test/hotspot/jtreg/compiler/floatingpoint/TestRoundFloatAll.java line 31:
>> 
>>> 29:  * @library /test/lib /
>>> 30:  * @modules java.base/jdk.internal.math
>>> 31:  * @run main/othervm -XX:-TieredCompilation -XX:CompileThresholdScaling=0.3 -XX:+PrintIdeal -XX:CompileCommand=compileonly,compiler.floatingpoint.TestRoundFloatAll::test* -XX:-UseSuperWord compiler.floatingpoint.TestRoundFloatAll
>> 
>> please break up the line for easier reading
>
> Why these flags:
> `-XX:-TieredCompilation -XX:CompileThresholdScaling=0.3 -XX:+PrintIdeal -XX:-UseSuperWord` ?
> 
> I also suggest that you use `-Xbatch`, just to make sure we have compiled all relevant methods after the warmup. If things get too slow, then maybe you want to consider using explicit compile exclusion / forbidding inlining for the `test*` method, rather than the compileonly, which prevents everything else from compiling.

Thanks for suggestion, added `-Xbatch`.

removed `-XX:+PrintIdeal`.
keep `-XX:-UseSuperWord`, as we are testing scalar version intrinsic in this test.
`-XX:-TieredCompilation -XX:CompileThresholdScaling=0.3` are just from previous tests.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17753#discussion_r1592837993

From mli at openjdk.org  Tue May  7 17:32:21 2024
From: mli at openjdk.org (Hamlin Li)
Date: Tue, 7 May 2024 17:32:21 GMT
Subject: RFR: 8325438: Add exhaustive tests for Math.round intrinsics [v13]
In-Reply-To: <G46ChUfl3G0l3Do4CG962uC5tdb3QqmjbJHz-tCbxVI=.240f3c06-32aa-4c49-bdcc-fe3e313dd542@github.com>
References: <MeXDL6wupeFWkaG7n24umN_ylwTv8dL0Lt1Zt3RwcQ8=.ebc46c01-27c8-4268-b6c0-12a33a8d93fa@github.com>
 <yTfpBfWBMtjLm8BNvtocgxlBhgAKEVzpblP5OkyuTAM=.559b4718-ce15-4162-9f34-feda1d4a6398@github.com>
 <G46ChUfl3G0l3Do4CG962uC5tdb3QqmjbJHz-tCbxVI=.240f3c06-32aa-4c49-bdcc-fe3e313dd542@github.com>
Message-ID: <nkndbjadEtZYhHXN8_qG3n4QodyEC_Muza0yB6GJp4o=.60771d44-c427-46a7-8c96-a119951a4124@github.com>

On Tue, 7 May 2024 13:30:12 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

>> Hamlin Li has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fix issues; modify vm options to make sure test the expected behaviors.
>
> test/hotspot/jtreg/compiler/floatingpoint/TestRoundFloatAll.java line 75:
> 
>> 73:         return (int) a;
>> 74:     }
>> 75:   }
> 
> At first, I was worried about the indentation, then realized the original code had the strange indentation.
> Would there be a way to put this method in a shared file, so that you do not need to paste it everywhere?

moved to a shared lib file.

> test/hotspot/jtreg/compiler/vectorization/TestRoundVectorFloatAll.java line 34:
> 
>> 32:  * @run main/othervm -XX:+PrintIdeal -XX:-TieredCompilation -XX:CompileThresholdScaling=0.3 -XX:MaxVectorSize=8 -XX:+UseSuperWord -XX:CompileCommand=compileonly,compiler.vectorization.TestRoundVectorFloatAll::test* compiler.vectorization.TestRoundVectorFloatAll
>> 33:  * @run main/othervm -XX:+PrintIdeal -XX:-TieredCompilation -XX:CompileThresholdScaling=0.3 -XX:MaxVectorSize=16 -XX:+UseSuperWord -XX:CompileCommand=compileonly,compiler.vectorization.TestRoundVectorFloatAll::test* compiler.vectorization.TestRoundVectorFloatAll
>> 34:  * @run main/othervm -XX:+PrintIdeal -XX:-TieredCompilation -XX:CompileThresholdScaling=0.3 -XX:MaxVectorSize=32 -XX:+UseSuperWord -XX:CompileCommand=compileonly,compiler.vectorization.TestRoundVectorFloatAll::test* compiler.vectorization.TestRoundVectorFloatAll
> 
> Please check which flags you actually need here....

removed `-XX:+PrintIdeal`
others seems useful to me.

> test/hotspot/jtreg/compiler/vectorization/TestRoundVectorFloatAll.java line 43:
> 
>> 41: public class TestRoundVectorFloatAll {
>> 42:   private static final int ITERS  = 11000;
>> 43:   private static final int ARRLEN = 997;
> 
> Could you randomize this value ever so slightly? That way, the boundaries of the array are at different places. I think also that the size should be a little larger, just to ensure that we get maximum vector lengths.

Make sense, done.

> test/hotspot/jtreg/compiler/vectorization/TestRoundVectorFloatRandom.java line 202:
> 
>> 200:     }
>> 201: 
>> 202:     // test cases for NaN, Inf, subnormal, and so on
> 
> just for completeness: +0.0 and -0.0

added

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17753#discussion_r1592838750
PR Review Comment: https://git.openjdk.org/jdk/pull/17753#discussion_r1592838951
PR Review Comment: https://git.openjdk.org/jdk/pull/17753#discussion_r1592839461
PR Review Comment: https://git.openjdk.org/jdk/pull/17753#discussion_r1592838230

From naoto at openjdk.org  Tue May  7 17:33:55 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 7 May 2024 17:33:55 GMT
Subject: RFR: 8305457: Implement java.io.IO
In-Reply-To: <aIf4sgfHDBX_0iVghGYlcA4rGVwC1R0uOItaSI72Z1M=.004b8b95-8de7-40ee-a3e3-2b41c2d474f3@github.com>
References: <w2msiw_qaMEIJS3s9D4bg8pFbz5WIF0KdP6Mm-XFjLI=.85b2020b-8c46-4bac-8a69-4975b068f2ff@github.com>
 <oPnpS6oaWew4cUZCzwMCOG9AvMvSMLuIkRhcJAjEefU=.46da5ff7-f99f-498d-aa3f-99147dae0195@github.com>
 <aIf4sgfHDBX_0iVghGYlcA4rGVwC1R0uOItaSI72Z1M=.004b8b95-8de7-40ee-a3e3-2b41c2d474f3@github.com>
Message-ID: <6c1icHjQsD_oDj8OOoQCy0Vgw1h-HZJX0btKflAHTqQ=.b1dbda7c-89a4-4f3c-a7ae-14116729c8f0@github.com>

On Tue, 7 May 2024 17:15:43 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> test/jdk/java/io/IO/IO.java line 99:
>> 
>>> 97:                 System.getProperty("test.jdk") + "/bin/java",
>>> 98:                 "--enable-preview",
>>> 99:                 "-Djdk.console=gibberish",
>> 
>> The test comment suggests this test is testing the default console implementation, but the invocation specifies `-Djdk.console=gibberish` which defaults to java.base. Is this what you intended?
>
> That comment says that this test tests jdk.internal.io.JdkConsoleImpl, which belongs to java.base. But, if you read it the way you described, I should definitely rephrase it.

Sorry, I read it wrong. Your comment is clear so no need for rewording

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19112#discussion_r1592840539

From mli at openjdk.org  Tue May  7 17:36:57 2024
From: mli at openjdk.org (Hamlin Li)
Date: Tue, 7 May 2024 17:36:57 GMT
Subject: RFR: 8325438: Add exhaustive tests for Math.round intrinsics [v13]
In-Reply-To: <G46ChUfl3G0l3Do4CG962uC5tdb3QqmjbJHz-tCbxVI=.240f3c06-32aa-4c49-bdcc-fe3e313dd542@github.com>
References: <MeXDL6wupeFWkaG7n24umN_ylwTv8dL0Lt1Zt3RwcQ8=.ebc46c01-27c8-4268-b6c0-12a33a8d93fa@github.com>
 <yTfpBfWBMtjLm8BNvtocgxlBhgAKEVzpblP5OkyuTAM=.559b4718-ce15-4162-9f34-feda1d4a6398@github.com>
 <G46ChUfl3G0l3Do4CG962uC5tdb3QqmjbJHz-tCbxVI=.240f3c06-32aa-4c49-bdcc-fe3e313dd542@github.com>
Message-ID: <Zcqa4R7mPnX6rRptAmS-s3565LscxhO-aW2AxVOfBR0=.a017eb58-9806-41e9-b053-114d2419655d@github.com>

On Tue, 7 May 2024 13:44:06 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

> Thanks for the extra tests!
> 

Thanks for reviewing.

> Can you measure how much time each test now takes on your machine?
> 

Only TestRoundVectorFloatAll.java took longer, but still in one minute, others run rather quicker than it.

> I think we are getting there. Still a little worried about some random bugs in the whole number generation... But I'd prefer having these tests to not having them for sure ;)

Agree!

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

PR Comment: https://git.openjdk.org/jdk/pull/17753#issuecomment-2098965761

From prappo at openjdk.org  Tue May  7 17:40:52 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Tue, 7 May 2024 17:40:52 GMT
Subject: RFR: 8305457: Implement java.io.IO
In-Reply-To: <oPnpS6oaWew4cUZCzwMCOG9AvMvSMLuIkRhcJAjEefU=.46da5ff7-f99f-498d-aa3f-99147dae0195@github.com>
References: <w2msiw_qaMEIJS3s9D4bg8pFbz5WIF0KdP6Mm-XFjLI=.85b2020b-8c46-4bac-8a69-4975b068f2ff@github.com>
 <oPnpS6oaWew4cUZCzwMCOG9AvMvSMLuIkRhcJAjEefU=.46da5ff7-f99f-498d-aa3f-99147dae0195@github.com>
Message-ID: <xHN8m8uZd3to9lSqUC_KKMrzRj5yVM_SAUq7lZrLVhk=.5bf13ec9-a638-4e59-8d88-0bd15a918619@github.com>

On Tue, 7 May 2024 16:24:52 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Please review this PR which introduces the `java.io.IO` top-level class and three methods to `java.io.Console` for [Implicitly Declared Classes and Instance Main Methods (Third Preview)].
>> 
>> This PR has been obtained as `git merge --squash` of a now obsolete [draft PR].
>> 
>> [Implicitly Declared Classes and Instance Main Methods (Third Preview)]: https://bugs.openjdk.org/browse/JDK-8323335
>> [draft PR]: https://github.com/openjdk/jdk/pull/18921
>
> src/java.base/share/classes/java/io/ProxyingConsole.java line 107:
> 
>> 105:      * {@inheritDoc}
>> 106:      *
>> 107:      * @throws IOError {@inheritDoc}
> 
> Probably I am missing something, but I see `Console` declares this throws clause. Do we need this inheritDoc here?

Yes, we do. There's a common misconception that `{@inheritDoc}` inherits the complete doc comment. In reality, `{@inheritDoc}` inherits only the main description, which does not include any `@throws` tags.

A `@throws` tag is either inherited explicitly, such as in L107, or implicitly. Implicit inheritance occurs when an exception is listed in the `throws` clause.

Since it's uncommon for unchecked exceptions (errors included) to be listed in the `throws` clause, unless inherited explicitly, their documentation will be missing from the overriding method documentation. Assuming, of course, that your intention is to have them there.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19112#discussion_r1592848314

From prappo at openjdk.org  Tue May  7 17:43:52 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Tue, 7 May 2024 17:43:52 GMT
Subject: RFR: 8305457: Implement java.io.IO
In-Reply-To: <6c1icHjQsD_oDj8OOoQCy0Vgw1h-HZJX0btKflAHTqQ=.b1dbda7c-89a4-4f3c-a7ae-14116729c8f0@github.com>
References: <w2msiw_qaMEIJS3s9D4bg8pFbz5WIF0KdP6Mm-XFjLI=.85b2020b-8c46-4bac-8a69-4975b068f2ff@github.com>
 <oPnpS6oaWew4cUZCzwMCOG9AvMvSMLuIkRhcJAjEefU=.46da5ff7-f99f-498d-aa3f-99147dae0195@github.com>
 <aIf4sgfHDBX_0iVghGYlcA4rGVwC1R0uOItaSI72Z1M=.004b8b95-8de7-40ee-a3e3-2b41c2d474f3@github.com>
 <6c1icHjQsD_oDj8OOoQCy0Vgw1h-HZJX0btKflAHTqQ=.b1dbda7c-89a4-4f3c-a7ae-14116729c8f0@github.com>
Message-ID: <rdlVLy72Ge0jkoG6UYZ1n7mX6cqeakKD-PQ1DOAu_ps=.87f17715-aa23-488d-aa27-a9df3588740c@github.com>

On Tue, 7 May 2024 17:30:46 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Sorry, I read it wrong. Your comment is clear so no need for rewording

Still, I think that your misreading is a symptom of a problem with my wording. Let me try to rephrase it; let's see if you like it more.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19112#discussion_r1592852458

From prappo at openjdk.org  Tue May  7 17:47:20 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Tue, 7 May 2024 17:47:20 GMT
Subject: RFR: 8305457: Implement java.io.IO [v2]
In-Reply-To: <w2msiw_qaMEIJS3s9D4bg8pFbz5WIF0KdP6Mm-XFjLI=.85b2020b-8c46-4bac-8a69-4975b068f2ff@github.com>
References: <w2msiw_qaMEIJS3s9D4bg8pFbz5WIF0KdP6Mm-XFjLI=.85b2020b-8c46-4bac-8a69-4975b068f2ff@github.com>
Message-ID: <Dctq5oaa_NKxZ-qs70wv_DLa6qKMOE_yMaUzjU-nI_4=.07cf47b4-461a-477a-ba86-cd8f215ce1ce@github.com>

> Please review this PR which introduces the `java.io.IO` top-level class and three methods to `java.io.Console` for [Implicitly Declared Classes and Instance Main Methods (Third Preview)].
> 
> This PR has been obtained as `git merge --squash` of a now obsolete [draft PR].
> 
> [Implicitly Declared Classes and Instance Main Methods (Third Preview)]: https://bugs.openjdk.org/browse/JDK-8323335
> [draft PR]: https://github.com/openjdk/jdk/pull/18921

Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:

  Respond to feedback from @naotoj
  
    - typo
    - trailing newlines
    - better wording

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/19112/files
  - new: https://git.openjdk.org/jdk/pull/19112/files/ef888fd8..60050834

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

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

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

From liach at openjdk.org  Tue May  7 18:20:52 2024
From: liach at openjdk.org (Chen Liang)
Date: Tue, 7 May 2024 18:20:52 GMT
Subject: RFR: 8311175: Move BufWriter::asByteBuffer to BufWriterImpl
In-Reply-To: <oZRXoV3GuRfusUDnmOjK6yGHNT8vT-T8ZEghcdvf0xI=.9bc212c0-ac4f-423f-97f7-4732f6363139@github.com>
References: <sEKITMKa0yBPrV7RTKYa0_GGSOss8a9T7GaOQpLaEYk=.f7ad0b39-bc77-4589-a8de-ef5132387e6c@github.com>
 <oZRXoV3GuRfusUDnmOjK6yGHNT8vT-T8ZEghcdvf0xI=.9bc212c0-ac4f-423f-97f7-4732f6363139@github.com>
Message-ID: <3jormwY7piWsXS4aiB0Go1v11DL4oBW--HBjj7x6AV8=.85a76b81-546a-4d0e-b98e-6c5a1b23c718@github.com>

On Tue, 7 May 2024 05:41:27 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> As discussed on the mailing list https://mail.openjdk.org/pipermail/classfile-api-dev/2023-June/000381.html, BufWriter::asByteBuffer has a behavior not suitable for API and is only used by internal StackMapGenerator/StackCounter, so it will be converted to an internal API.
>> 
>> Somehow the ByteBuffer needs to be sliced, or StackMapGenerator encounters IOOBE. Not sure what the exact cause was.
>
> @liach Do you have any plans with this PR?

@asotona classfile tests pass, can you review this patch and its associated CSR?

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

PR Comment: https://git.openjdk.org/jdk/pull/14736#issuecomment-2099038162

From sviswanathan at openjdk.org  Tue May  7 18:24:03 2024
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Tue, 7 May 2024 18:24:03 GMT
Subject: RFR: 8320448: Accelerate IndexOf using AVX2 [v19]
In-Reply-To: <eQ4OBFrF8JlDJ1h9awTDOc0kfCc37IlL5vdqtuaqls0=.8f00616d-08e1-4f28-a7a5-5095116d2595@github.com>
References: <uWi4QxH31hL93771gkl_GgvP0m84IRSoR_1Yi8hD17E=.bc6ed458-7081-4c3f-9348-f59358fa05a4@github.com>
 <eQ4OBFrF8JlDJ1h9awTDOc0kfCc37IlL5vdqtuaqls0=.8f00616d-08e1-4f28-a7a5-5095116d2595@github.com>
Message-ID: <TXkZepujpDCaTca5qKKCTkTQgiwLQxSr204PzLPH3ro=.b9212682-de55-46c8-a2d2-a242bb84400d@github.com>

On Sat, 4 May 2024 19:35:21 GMT, Scott Gibbons <sgibbons at openjdk.org> wrote:

>> Re-write the IndexOf code without the use of the pcmpestri instruction, only using AVX2 instructions.  This change accelerates String.IndexOf on average 1.3x for AVX2.  The benchmark numbers:
>> 
>> 
>> Benchmark	                                               Score		Latest		
>> StringIndexOf.advancedWithMediumSub   343.573		317.934		0.925375393x
>> StringIndexOf.advancedWithShortSub1	  1039.081		1053.96		1.014319384x
>> StringIndexOf.advancedWithShortSub2	      55.828		110.541		1.980027943x
>> StringIndexOf.constantPattern	                9.361		11.906		1.271872663x
>> StringIndexOf.searchCharLongSuccess	        4.216		4.218		1.000474383x
>> StringIndexOf.searchCharMediumSuccess	3.133		3.216		1.02649218x
>> StringIndexOf.searchCharShortSuccess	3.76		        3.761		1.000265957x
>> StringIndexOf.success	                                9.186		9.713		1.057369911x
>> StringIndexOf.successBig	                      14.341		46.343		3.231504079x
>> StringIndexOfChar.latin1_AVX2_String	  6220.918		12154.52		1.953814533x
>> StringIndexOfChar.latin1_AVX2_char	  5503.556		5540.044		1.006629895x
>> StringIndexOfChar.latin1_SSE4_String	  6978.854		6818.689		0.977049957x
>> StringIndexOfChar.latin1_SSE4_char	  5657.499		5474.624		0.967675646x
>> StringIndexOfChar.latin1_Short_String	  7132.541		6863.359		0.962260014x
>> StringIndexOfChar.latin1_Short_char	16013.389	      16162.437		1.009307711x
>> StringIndexOfChar.latin1_mixed_String	  7386.123	      14771.622		1.999915517x
>> StringIndexOfChar.latin1_mixed_char	  9901.671		9782.245		0.987938803
>
> Scott Gibbons has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rearrange; add lambdas for clarity

src/hotspot/cpu/x86/stubGenerator_x86_64_string.cpp line 383:

> 381:     {
> 382:       Label L_short;
> 383: 

A comment here:
// Broadcast the beginning of needle into a vector register.

src/hotspot/cpu/x86/stubGenerator_x86_64_string.cpp line 390:

> 388:         __ vpbroadcastb(byte_0, Address(needle, 0), Assembler::AVX_256bit);
> 389:       }
> 390: 

A comment here:
// Broadcast the end of needle into a vector register. This step is not needed for single element needle.

src/hotspot/cpu/x86/stubGenerator_x86_64_string.cpp line 418:

> 416:       __ cmpq(haystack_len, 0x10);
> 417:       __ ja_b(L_moreThan16);
> 418: 

An assert here to check for header size >= 16 would be good. 
Also a comment here would he good, something like: 
// Copy 16 or 32 bytes prior to haystack end onto stack 
// This will possibly including some object header bytes when haystack length is less than 16 or 32 bytes // Set the new haystack address to beginning of copied haystack on stack adjusting for extra bytes copied

src/hotspot/cpu/x86/stubGenerator_x86_64_string.cpp line 498:

> 496: 
> 497:       // big_case_loop_helper will fall through to this point if one or more potential matches are found
> 498:       // The mask will have a bitmask indicating the position of the potential matches within the haystack

If no potential match, which label does the big_case_loop_helper jump to?

src/hotspot/cpu/x86/stubGenerator_x86_64_string.cpp line 517:

> 515:       __C2 arrays_equals(false, haystackStart, firstNeedleCompare, compLen, retval, rScratch, xmm_tmp3, xmm_tmp4,
> 516:                          false /* char */, knoreg);
> 517:       __ testl(retval, retval);

Since this is byte compare even for isU, the retval here could be a 64-bit quantity so the testl should be a testq.

src/hotspot/cpu/x86/stubGenerator_x86_64_string.cpp line 553:

> 551:     //  Haystack always copied to stack, so 32-byte reads OK
> 552:     //  Haystack length < 32
> 553:     //  10 < needle length < 32

The comment below may need update as we come here for needle_len > OPT_NEEDLE_SIZE_MAX which is currently set as 5:
// 10 < needle length < 32

src/hotspot/cpu/x86/stubGenerator_x86_64_string.cpp line 611:

> 609:       __C2 arrays_equals(false, rTmp, firstNeedleCompare, compLen, rTmp3, rTmp2, xmm_tmp3, xmm_tmp4, false /* char */,
> 610:                          knoreg);
> 611:       __ testl(rTmp3, rTmp3);

Since this is byte compare even for isU, the rtmp3  here could be a 64-bit quantity so the testl should be a testq.

src/hotspot/cpu/x86/stubGenerator_x86_64_string.cpp line 629:

> 627: 
> 628:     __ bind(L_returnError);
> 629:     __ movq(rbp, -1);

This could directly be rax instead of intermediate rbp and then moving from rbp to rax.

src/hotspot/cpu/x86/stubGenerator_x86_64_string.cpp line 633:

> 631: 
> 632:     __ bind(L_returnZero);
> 633:     __ xorl(rbp, rbp);

This could directly be rax instead of intermediate rbp and then moving from rbp to rax.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1592791718
PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1592792401
PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1592774634
PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1592866631
PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1592868501
PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1592880650
PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1592885514
PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1592892211
PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1592892329

From duke at openjdk.org  Tue May  7 18:25:56 2024
From: duke at openjdk.org (Axel Hauschulte)
Date: Tue, 7 May 2024 18:25:56 GMT
Subject: RFR: 8331485: Odd Results when Parsing Scientific Notation with
 Large Exponent [v5]
In-Reply-To: <riPoN1c_9KUHtoXtu0grLU04DBXqN1c3M1U4ILn9P3s=.8f2b2913-8c75-4e65-9d89-cf03f0bc0c0e@github.com>
References: <lTOZ4RbzZFMN0yLrQKGOcMihdTop24YbYJe2h36SodM=.0addc2ad-b0d1-4721-b860-a9395fa14977@github.com>
 <riPoN1c_9KUHtoXtu0grLU04DBXqN1c3M1U4ILn9P3s=.8f2b2913-8c75-4e65-9d89-cf03f0bc0c0e@github.com>
Message-ID: <yjJZ2GoOQxvNCaUwv0znI7DgMBtAfpFmc9XbTTyTBBA=.b94f6c88-1f27-4427-95e8-dbffc9ae6c46@github.com>

On Tue, 7 May 2024 07:46:22 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please review this PR which corrects an edge case bug for java.text.DecimalFormat that causes incorrect parsing results for strings with very large exponent values.
>> 
>> When parsing values with large exponents, if the value of the exponent exceeds `Integer.MAX_VALUE`, the parsed value  is equal to 0. If the value of the exponent exceeds `Long.MAX_VALUE`, the parsed value is equal to the mantissa. Both results are confusing and incorrect.
>> 
>> For example,
>> 
>> 
>> NumberFormat fmt = NumberFormat.getInstance(Locale.US);
>> fmt.parse(".1E2147483648"); // returns 0.0
>> fmt.parse(".1E9223372036854775808"); // returns 0.1
>> // For comparison
>> Double.parseDouble(".1E2147483648"); // returns Infinity
>> Double.parseDouble(".1E9223372036854775808"); // returns Infinity
>> 
>> 
>> After this change, both parse calls return `Double.POSITIVE_INFINITY` now.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   correct behavior when underflow from adjustment + use MIN

Implementation looks good to me now.

Thanks again for taking care of this.

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

Marked as reviewed by ahauschulte at github.com (no known OpenJDK username).

PR Review: https://git.openjdk.org/jdk/pull/19075#pullrequestreview-2043881285

From vklang at openjdk.org  Tue May  7 18:27:53 2024
From: vklang at openjdk.org (Viktor Klang)
Date: Tue, 7 May 2024 18:27:53 GMT
Subject: RFR: 8048691: Spliterator.SORTED characteristics gets cleared for
 BaseStream.spliterator
In-Reply-To: <UwfOCAxTUpaES0HVbw420ehOFe8O_66Vfqz38hQBjXs=.abf59c16-d1e0-413d-bea7-ac276cb46e50@github.com>
References: <UwfOCAxTUpaES0HVbw420ehOFe8O_66Vfqz38hQBjXs=.abf59c16-d1e0-413d-bea7-ac276cb46e50@github.com>
Message-ID: <29qMZHkWoTts653suFXk2TlsuF8ZZ4CO40kyP7n3cEg=.f74f6ea0-36fe-4cd1-a1a9-12d66d1bc4c4@github.com>

On Tue, 7 May 2024 14:58:00 GMT, Viktor Klang <vklang at openjdk.org> wrote:

> Removes SORTED if not also ORDERED for escape-hatch `Stream::spliterator()`

Tagging @PaulSandoz for review :)

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

PR Comment: https://git.openjdk.org/jdk/pull/19123#issuecomment-2099048586

From psandoz at openjdk.org  Tue May  7 18:32:53 2024
From: psandoz at openjdk.org (Paul Sandoz)
Date: Tue, 7 May 2024 18:32:53 GMT
Subject: RFR: 8048691: Spliterator.SORTED characteristics gets cleared for
 BaseStream.spliterator
In-Reply-To: <UwfOCAxTUpaES0HVbw420ehOFe8O_66Vfqz38hQBjXs=.abf59c16-d1e0-413d-bea7-ac276cb46e50@github.com>
References: <UwfOCAxTUpaES0HVbw420ehOFe8O_66Vfqz38hQBjXs=.abf59c16-d1e0-413d-bea7-ac276cb46e50@github.com>
Message-ID: <kEuPWavUEIQajgavTFtB6AV4SqQGRX6oWFe4q2FKylo=.8b5247f4-9158-4c58-8c65-c1a8551745e9@github.com>

On Tue, 7 May 2024 14:58:00 GMT, Viktor Klang <vklang at openjdk.org> wrote:

> Removes SORTED if not also ORDERED for escape-hatch `Stream::spliterator()`

Marked as reviewed by psandoz (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/19123#pullrequestreview-2043897612

From psandoz at openjdk.org  Tue May  7 18:39:51 2024
From: psandoz at openjdk.org (Paul Sandoz)
Date: Tue, 7 May 2024 18:39:51 GMT
Subject: RFR: 8331734: Atomic MemorySegment VarHandle operations fails for
 element layouts
In-Reply-To: <_PQ4wP4lk_STKwnSddD-5GgfsCheLbT_MR9zIyQyE78=.4ae37fdc-cf6e-46ea-8dbe-afcd1e710666@github.com>
References: <_PQ4wP4lk_STKwnSddD-5GgfsCheLbT_MR9zIyQyE78=.4ae37fdc-cf6e-46ea-8dbe-afcd1e710666@github.com>
Message-ID: <uBwvs4SJznJA5DnZ8nZOy9-eQCYnp-MNpBKZCRJ7nOg=.a61042fd-c18b-4aa9-b214-a07b0e1f49fb@github.com>

On Tue, 7 May 2024 15:42:23 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> This PR fixes an issue that has crept into the FFM API implementation.
> 
> From very early stages, the FFM API used to disable the alignment check on nested layout elements, in favor of an alignment check against the memory segment base address. The rationale was that the JIT had issue with eliminating redundant alignment checks, and accessing nested elements could never result in alignment issues, since the alignment of the container is provably bigger than that of the contained element. This means that, when creating a var handle for a nested layout element, we set the nested layout alignment to 1 (unaligned), derive its var handle, and then decorate the var handle with an alignment check for the container.
> 
> At some point in 22, we tweaked the API to throw `UnsupportedOperationException` when using an access mode incompatible with the alignment constraint of the accessed layout. That is, a volatile read on an `int` is only possible if the access occurs at an address that is at least 4-byte aligned. Otherwise an `UOE` is thrown.
> 
> Unfortunately this change broke the aforementioned optimization: creating a var handle for an unaligned layout works, but the resulting layout will *not* support any of the atomic access modes.
> 
> Since this optimization is not really required anymore (proper C2 support to hoist/eliminate alignment checks has been added since then), it is better to disable this implementation quirk, and leave optimizations to C2.
> 
> (If we really really wanted to optimize things a bit, we could remove the container alignment check in the case the accessed value is the first layout element nested in the container, but this PR doesn't go that far).
> 
> I've run relevant benchmarks before/after and found no differences. In part this is because `arrayElementVarHandle` is unaffected. But, even after tweaking the `LoopOverNonConstant` benchmark to add explicit tests for the code path affected, no significant difference was found, sign that C2 is indeed able to spot (and remove) the redundant alignment check. Note: if we know that `aligned_to_N(base)` holds, then it's easy to prove that `aligned_to_M(base + offset + index * scale)` holds, when `N >= M` and with `offset` and `scale` known (the latter a power of two).

Marked as reviewed by psandoz (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/19124#pullrequestreview-2043909050

From alanb at openjdk.org  Tue May  7 18:43:53 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 7 May 2024 18:43:53 GMT
Subject: RFR: 8048691: Spliterator.SORTED characteristics gets cleared for
 BaseStream.spliterator
In-Reply-To: <UwfOCAxTUpaES0HVbw420ehOFe8O_66Vfqz38hQBjXs=.abf59c16-d1e0-413d-bea7-ac276cb46e50@github.com>
References: <UwfOCAxTUpaES0HVbw420ehOFe8O_66Vfqz38hQBjXs=.abf59c16-d1e0-413d-bea7-ac276cb46e50@github.com>
Message-ID: <cC6qd3nh_E5tu0LubNZDid0A5yhGZ8SaqxE4KwIoRWQ=.bd28e1c0-0e51-423d-9924-2858728a442d@github.com>

On Tue, 7 May 2024 14:58:00 GMT, Viktor Klang <vklang at openjdk.org> wrote:

> Removes SORTED if not also ORDERED for escape-hatch `Stream::spliterator()`

Marked as reviewed by alanb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/19123#pullrequestreview-2043916265

From liach at openjdk.org  Tue May  7 18:54:59 2024
From: liach at openjdk.org (Chen Liang)
Date: Tue, 7 May 2024 18:54:59 GMT
Subject: RFR: 8320396: Class-File API ClassModel::verify should include
 checks from hotspot/share/classfile/classFileParser.cpp [v4]
In-Reply-To: <qPSb3Xaw2eNwYqG7vbfWfKbvS0doeN1yG8Uvh1dkhCE=.366c0ba1-26c5-463e-9b26-f0d9428879ea@github.com>
References: <0a66asWcJ4_zBrjmReA18BZmsovN1ZeJRRSAPZDMZmo=.5bada03f-d88d-46cd-962d-c1e42c3048c1@github.com>
 <qPSb3Xaw2eNwYqG7vbfWfKbvS0doeN1yG8Uvh1dkhCE=.366c0ba1-26c5-463e-9b26-f0d9428879ea@github.com>
Message-ID: <FqTY8dgxHxjg8Frj1cJlSUL8HsoByOiD6CwpAFJIIyw=.b4041717-5661-4eea-8f4c-7c36bdec3d90@github.com>

On Thu, 2 May 2024 10:30:06 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> ClassFile API `jdk.internal.classfile.verifier.VerifierImpl` performed only bytecode-level class verification.
>> This patch adds `jdk.internal.classfile.verifier.ParserVerifier` with additional class checks inspired by `hotspot/share/classfile/classFileParser.cpp`.
>> 
>> Also new `VerifierSelfTest::testParserVerifier` has been added.
>> 
>> Please review.
>> 
>> Thanks,
>> Adam
>
> Adam Sotona has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 28 commits:
> 
>  - Merge branch 'master' into JDK-8320396-verifier-extension
>  - added references to jvms
>  - Merge remote-tracking branch 'openjdk/master' into JDK-8320396-verifier-extension
>  - work in progress
>  - work in progress
>  - work in progress
>  - work in progress
>  - work in progress
>  - removed string templates from test
>  - work in progress
>  - ... and 18 more: https://git.openjdk.org/jdk/compare/ae82405f...3ebc780a

src/java.base/share/classes/jdk/internal/classfile/impl/verifier/ParserVerifier.java line 97:

> 95:                     check.accept(fre.owner()::asSymbol);
> 96:                     check.accept(fre::typeSymbol);
> 97:                     yield () -> verifyFieldName(fre.name().stringValue());

Nitpick, we should avoid capturing the check instance and just do something like:

                case FieldRefEntry fre -> () -> {
                    fre.owner().asSymbol();
                    fre.typeSymbol();
                    verifyFieldName(fre.name().stringValue());
                };

src/java.base/share/classes/jdk/internal/classfile/impl/verifier/ParserVerifier.java line 151:

> 149:         var fields = new HashSet<String>();
> 150:         for (var f : classModel.fields()) try {
> 151:             if (!fields.add(f.fieldName().stringValue() + f.fieldType().stringValue())) {

We should declare a local record, concat is not safe if we have fields like:

Loop foo;
oop fooL;

both will producce `fooLLoop;`

src/java.base/share/classes/jdk/internal/classfile/impl/verifier/ParserVerifier.java line 163:

> 161:         var methods = new HashSet<String>();
> 162:         for (var m : classModel.methods()) try {
> 163:             if (!methods.add(m.methodName().stringValue() + m.methodType().stringValue())) {

This one is safe as `(` is safe, but still preferable to use a local record as key

src/java.base/share/classes/jdk/internal/classfile/impl/verifier/ParserVerifier.java line 167:

> 165:             }
> 166:             if (m.methodName().equalsString(CLASS_INIT_NAME)
> 167:                     && !m.flags().has(AccessFlag.STATIC)) {

Do we verify it has void return and (since class file version JAVA 7) takes no args? The static requirement is since JAVA 7 too.

src/java.base/share/classes/jdk/internal/classfile/impl/verifier/ParserVerifier.java line 364:

> 362:                     className(),
> 363:                     m.methodName().stringValue(),
> 364:                     m.methodTypeSymbol().parameterList().stream().map(ClassDesc::displayName).collect(Collectors.joining(",")));

Suggestion:

                    m.methodTypeSymbol().displayDescriptor();

Can remove the parentheses above.

src/java.base/share/classes/jdk/internal/classfile/impl/verifier/VerificationWrapper.java line 134:

> 132:         }
> 133: 
> 134:         String parameters() {

We should just use the mtd's displayDescriptor, a class file can have bridge methods with covariant return types and the bridge may be broken while the concrete method is ok.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16809#discussion_r1592914387
PR Review Comment: https://git.openjdk.org/jdk/pull/16809#discussion_r1592917226
PR Review Comment: https://git.openjdk.org/jdk/pull/16809#discussion_r1592919450
PR Review Comment: https://git.openjdk.org/jdk/pull/16809#discussion_r1592922781
PR Review Comment: https://git.openjdk.org/jdk/pull/16809#discussion_r1592925732
PR Review Comment: https://git.openjdk.org/jdk/pull/16809#discussion_r1592926751

From vklang at openjdk.org  Tue May  7 19:08:58 2024
From: vklang at openjdk.org (Viktor Klang)
Date: Tue, 7 May 2024 19:08:58 GMT
Subject: Integrated: 8048691: Spliterator.SORTED characteristics gets cleared
 for BaseStream.spliterator
In-Reply-To: <UwfOCAxTUpaES0HVbw420ehOFe8O_66Vfqz38hQBjXs=.abf59c16-d1e0-413d-bea7-ac276cb46e50@github.com>
References: <UwfOCAxTUpaES0HVbw420ehOFe8O_66Vfqz38hQBjXs=.abf59c16-d1e0-413d-bea7-ac276cb46e50@github.com>
Message-ID: <cSMC2OohYmOee3cyi21h5skgKi7_dbnUmU6Okxgb748=.3d27eb41-98fc-4712-9525-c2cde83f9c9c@github.com>

On Tue, 7 May 2024 14:58:00 GMT, Viktor Klang <vklang at openjdk.org> wrote:

> Removes SORTED if not also ORDERED for escape-hatch `Stream::spliterator()`

This pull request has now been integrated.

Changeset: f12ed061
Author:    Viktor Klang <vklang at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/f12ed061ae3fa9d5620a7c6c7ea441f9f33bb745
Stats:     28 lines in 2 files changed: 26 ins; 0 del; 2 mod

8048691: Spliterator.SORTED characteristics gets cleared for BaseStream.spliterator

Reviewed-by: psandoz, alanb

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

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

From szaldana at openjdk.org  Tue May  7 19:14:55 2024
From: szaldana at openjdk.org (Sonia Zaldana Calles)
Date: Tue, 7 May 2024 19:14:55 GMT
Subject: RFR: 8329581: Java launcher no longer prints a stack trace [v9]
In-Reply-To: <krgANOmUJpt38cg16YhdXnUibxgX4shajEyWnMF79Hc=.e2dba0cc-8085-4efd-a300-d9c7f771510b@github.com>
References: <Z0pDMIc_XvZhcZdeFsIQUlqI17q5ybj0BnQ9Kl3jwxg=.8f981c46-a8a3-4520-a6e3-79ee7fce0253@github.com>
 <krgANOmUJpt38cg16YhdXnUibxgX4shajEyWnMF79Hc=.e2dba0cc-8085-4efd-a300-d9c7f771510b@github.com>
Message-ID: <ha9Jp8rt1I4K0hRrH5jcx4e2KEHr1_aUmYOurBCGHfY=.39c2d9d8-979f-440c-9476-f58b4f791f5f@github.com>

On Mon, 6 May 2024 19:06:10 GMT, Sonia Zaldana Calles <szaldana at openjdk.org> wrote:

>> Hi folks, 
>> 
>> This PR aims to fix [JDK-8329581](https://bugs.openjdk.org/browse/JDK-8329581). 
>> 
>> I think the regression got introduced in [JDK-8315458](https://bugs.openjdk.org/browse/JDK-8315458). 
>> 
>> In the issue linked above, [LauncherHelper#getMainType](https://github.com/openjdk/jdk/pull/16461/files#diff-108a3a3e3c2d108c8c7f19ea498f641413b7c9239ecd2975a6c27d904c2ba226) got removed to simplify launcher code.
>> 
>> Previously, we used ```getMainType``` to do the appropriate main method invocation in ```JavaMain```. However, we currently attempt to do all types of main method invocations at the same time [here](https://github.com/openjdk/jdk/blob/master/src/java.base/share/native/libjli/java.c#L623). 
>> 
>> Note how all of these invocations clear the exception reported with [CHECK_EXCEPTION_FAIL](https://github.com/openjdk/jdk/blob/140f56718bbbfc31bb0c39255c68568fad285a1f/src/java.base/share/native/libjli/java.c#L390). 
>> 
>> Therefore, if a legitimate exception comes up during one of these invocations, it does not get reported. 
>> 
>> I propose reintroducing ```LauncherHelper#getMainType``` but I'm looking forward to your suggestions. 
>> 
>> Cheers, 
>> Sonia
>
> Sonia Zaldana Calles has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixing indentation
>   
>   Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com>

Just noting, I don't think the GHA failures are related to my patch.

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

PR Comment: https://git.openjdk.org/jdk/pull/18786#issuecomment-2099126506

From prappo at openjdk.org  Tue May  7 19:46:18 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Tue, 7 May 2024 19:46:18 GMT
Subject: RFR: 8305457: Implement java.io.IO [v3]
In-Reply-To: <w2msiw_qaMEIJS3s9D4bg8pFbz5WIF0KdP6Mm-XFjLI=.85b2020b-8c46-4bac-8a69-4975b068f2ff@github.com>
References: <w2msiw_qaMEIJS3s9D4bg8pFbz5WIF0KdP6Mm-XFjLI=.85b2020b-8c46-4bac-8a69-4975b068f2ff@github.com>
Message-ID: <wpwFGOp8E00csxi2Xb9b-02ZlkqnIZEpo8AqaMsQ4AM=.90acb47b-effc-4838-ba80-28938d4dc3c0@github.com>

> Please review this PR which introduces the `java.io.IO` top-level class and three methods to `java.io.Console` for [Implicitly Declared Classes and Instance Main Methods (Third Preview)].
> 
> This PR has been obtained as `git merge --squash` of a now obsolete [draft PR].
> 
> [Implicitly Declared Classes and Instance Main Methods (Third Preview)]: https://bugs.openjdk.org/browse/JDK-8323335
> [draft PR]: https://github.com/openjdk/jdk/pull/18921

Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:

  Strengthen tests after 8330998
  
  https://github.com/openjdk/jdk/pull/18996 now allows us to test
  Console IO better.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/19112/files
  - new: https://git.openjdk.org/jdk/pull/19112/files/60050834..73a20a7c

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

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

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

From darcy at openjdk.org  Tue May  7 19:53:53 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 7 May 2024 19:53:53 GMT
Subject: RFR: 8305457: Implement java.io.IO [v3]
In-Reply-To: <xHN8m8uZd3to9lSqUC_KKMrzRj5yVM_SAUq7lZrLVhk=.5bf13ec9-a638-4e59-8d88-0bd15a918619@github.com>
References: <w2msiw_qaMEIJS3s9D4bg8pFbz5WIF0KdP6Mm-XFjLI=.85b2020b-8c46-4bac-8a69-4975b068f2ff@github.com>
 <oPnpS6oaWew4cUZCzwMCOG9AvMvSMLuIkRhcJAjEefU=.46da5ff7-f99f-498d-aa3f-99147dae0195@github.com>
 <xHN8m8uZd3to9lSqUC_KKMrzRj5yVM_SAUq7lZrLVhk=.5bf13ec9-a638-4e59-8d88-0bd15a918619@github.com>
Message-ID: <z1iWLVaePCJLF6p8A9FeZ6TYJglUgvMPC4XTzzuQ38k=.5ddf6e86-ad0a-4120-b7c2-88bb82c17f75@github.com>

On Tue, 7 May 2024 17:37:57 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> Yes, we do. There's a common misconception that `{@inheritDoc}` inherits the complete doc comment. In reality, `{@inheritDoc}` inherits only the main description, which does not include any `@throws` tags.
> 
> A `@throws` tag is either inherited explicitly, such as in L107, or implicitly. Implicit inheritance occurs when an exception is listed in the `throws` clause.
> 
> Since it's uncommon for unchecked exceptions (errors included) to be listed in the `throws` clause, unless inherited explicitly, their documentation will be missing from the overriding method documentation. Assuming, of course, that your intention is to have them there.

While it may be surprising that `{@inheritDoc}` doesn't inherit the complete doc, it is a feature rather than a bug since an overridden method is allowed to throw fewer exceptions than the method it overrides.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19112#discussion_r1592985138

From darcy at openjdk.org  Tue May  7 20:07:51 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 7 May 2024 20:07:51 GMT
Subject: RFR: 8330205: Initial troff manpage generation for JDK 24
In-Reply-To: <6tFYXJ753At7nUZTy8khVVeiQHYtZRBRYegXSTXViUY=.f3110151-9ea0-4b55-89f1-90039273fd34@github.com>
References: <6tFYXJ753At7nUZTy8khVVeiQHYtZRBRYegXSTXViUY=.f3110151-9ea0-4b55-89f1-90039273fd34@github.com>
Message-ID: <kmTopgOeZ_Yf6eiPc0Gh7oM0LZ6oHcVqOSN8SCzNCjI=.5eab6555-7e8b-4a52-a640-6cc161284a60@github.com>

On Tue, 7 May 2024 11:53:19 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> Please review this mechanical change to man pages. This PR should be integrated after https://github.com/openjdk/jdk/pull/18787.

Marked as reviewed by darcy (Reviewer).

> This PR is standalone as opposed to dependent because the #18787 dependency currently has a merge conflict, which complicates the required workflow.
> 
> This comment serves as a reminder to merge master into this PR once #18787 has been integrated. If we don't do that, Skara will likely create a backport issue:
> 
> > (?? The fixVersion in this issue is [24] but the fixVersion in .jcheck/conf is 23, a new backport will be created when this pr is integrated.)

Thanks @pavelrappo. For as a small risk-reduction exercise, the fixVersion on the bug could also be changed to tbd, but if it is integrated after the main start-of-release PR it should be fine.

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

PR Review: https://git.openjdk.org/jdk/pull/19119#pullrequestreview-2044060259
PR Comment: https://git.openjdk.org/jdk/pull/19119#issuecomment-2099210018

From forax at openjdk.org  Tue May  7 20:14:52 2024
From: forax at openjdk.org (=?UTF-8?B?UsOpbWk=?= Forax)
Date: Tue, 7 May 2024 20:14:52 GMT
Subject: RFR: 8305457: Implement java.io.IO [v3]
In-Reply-To: <7n1hCAP6_sXuoIWhRSSjV9qcAMbQGU7jOrbl9YE3Gk8=.4cc275ad-a3f5-486f-80f1-3a1fb5fede41@github.com>
References: <w2msiw_qaMEIJS3s9D4bg8pFbz5WIF0KdP6Mm-XFjLI=.85b2020b-8c46-4bac-8a69-4975b068f2ff@github.com>
 <hVlQ7frdWV-o3-F0NHmZu1dnQqu2ZZqC03IFbR-I-yE=.c611d97e-31a9-4d22-9f53-b1bdd71467c5@github.com>
 <yQGqIb5RQtadQA_bu-8JdUJDUdi_UEySF8Sm1-Bb5-c=.03331a10-d436-4ae7-8c88-e8d7649e8ec5@github.com>
 <OOeWi7f89VKud_6Sp7Z9AMdzPXexJl6sb6N6k-T2xFs=.5c5af026-02da-4d9d-987c-d62eaaf54ff6@github.com>
 <7n1hCAP6_sXuoIWhRSSjV9qcAMbQGU7jOrbl9YE3Gk8=.4cc275ad-a3f5-486f-80f1-3a1fb5fede41@github.com>
Message-ID: <kcmVvhW3-bOuiA1oXOXbRrVqvJphybsFZx_4HNOCWrc=.c2989151-0dd9-4299-aa27-99e758d13002@github.com>

On Tue, 7 May 2024 16:09:08 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> I do not think the step to "standardise" a preview feature exists ? When a preview feature becomes a released feature, the code is very lightly edited, at least it this is my experience. 
>> 
>> You can change both readln and readLine and if `java.io.IO` is removed, at least the code of readLine() will be
>
>> I do not think the step to "standardise" a preview feature exists ? When a preview feature becomes a released feature, the code is very lightly edited, at least it this is my experience.
> 
> We may call it differently, but I think both you and I are referring to this part of [JEP 12](https://openjdk.org/jeps/12) (emphasis mine):
> 
>> Eventually, the JEP owner must decide the preview feature's fate. If the decision is to remove the preview feature, then the owner must file an issue in JBS to remove the feature in the next JDK feature release; no new JEP is needed. **On the other hand, if the decision is to finalize, then the owner must file a new JEP, noting refinements informed by developer feedback. The title of this JEP should be the feature's name, omitting the earlier suffix of (Preview) / (Second Preview), and without adding any new suffix such as (Standard) or (Final). This JEP will ultimately reach Targeted status for the next JDK feature release.**
> 
>> You can change both readln and readLine and if `java.io.IO` is removed, at least the code of readLine() will be
> 
> Sorry, R?mi, but no. As long as this feature is in preview, I'd optimise for easier removal (back out) of the feature rather than clean combined code.

Okay

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19112#discussion_r1593013670

From prappo at openjdk.org  Tue May  7 20:26:52 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Tue, 7 May 2024 20:26:52 GMT
Subject: RFR: 8305457: Implement java.io.IO [v3]
In-Reply-To: <VeykkrIb_1RvBlQ3NYZJIvig16qeKByY6hcRtpyeruw=.833c60ab-f4a7-4161-a071-ef9ba3b57657@github.com>
References: <w2msiw_qaMEIJS3s9D4bg8pFbz5WIF0KdP6Mm-XFjLI=.85b2020b-8c46-4bac-8a69-4975b068f2ff@github.com>
 <-WNQ0gigYgjDdjH55OM-8aWzcDeHcA5ORdsK8MpSvj8=.8fe3c2ee-f30b-4dbd-a9a6-b0c8a4f0dbbc@github.com>
 <VeykkrIb_1RvBlQ3NYZJIvig16qeKByY6hcRtpyeruw=.833c60ab-f4a7-4161-a071-ef9ba3b57657@github.com>
Message-ID: <mmUl8dkLjrfAs1utQ0e5zn8Knz2ZV3UzM8x4KxB4wtc=.c95890ba-267d-4c0f-8351-4d78cee2f024@github.com>

On Tue, 7 May 2024 02:54:39 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> src/java.base/share/classes/java/io/IO.java line 41:
>> 
>>> 39:  */
>>> 40: @PreviewFeature(feature = PreviewFeature.Feature.IMPLICIT_CLASSES)
>>> 41: public class IO {
>> 
>> Should this be final?
>
>> Should this be final?
> 
> With only the private constructor, it doesn't matter too much in practice, but an explicit `final` would be good documentation if that is the intent.

If the sole constructor of a class is private, not only does it preclude the class from being instantiated, but it also precludes the class from being extended. Mind you, even with the sole private constructor, both instantiation and extension are still possible from inside the class or its nested classes. As long as we don't leak such instances to API clients, they won't seem to be able to observe any difference between "the private constructor" and "the private constructor of a final class".

I think that just having that constructor private but the class "non-final" makes bigger bang for the buck. We can defer the decision to make the class final.

If this helps, here are a few well-known similar classes:

  - java.util.Collections
  - java.util.concurrent.Executors

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19112#discussion_r1593033564

From sviswanathan at openjdk.org  Tue May  7 20:40:59 2024
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Tue, 7 May 2024 20:40:59 GMT
Subject: RFR: 8320448: Accelerate IndexOf using AVX2 [v19]
In-Reply-To: <eQ4OBFrF8JlDJ1h9awTDOc0kfCc37IlL5vdqtuaqls0=.8f00616d-08e1-4f28-a7a5-5095116d2595@github.com>
References: <uWi4QxH31hL93771gkl_GgvP0m84IRSoR_1Yi8hD17E=.bc6ed458-7081-4c3f-9348-f59358fa05a4@github.com>
 <eQ4OBFrF8JlDJ1h9awTDOc0kfCc37IlL5vdqtuaqls0=.8f00616d-08e1-4f28-a7a5-5095116d2595@github.com>
Message-ID: <q9pPOlQVtVZLACi-TMzlpZnvoLZ5xhnTAkjxFyM_77E=.8d377d2c-d370-4feb-890c-73503d086888@github.com>

On Sat, 4 May 2024 19:35:21 GMT, Scott Gibbons <sgibbons at openjdk.org> wrote:

>> Re-write the IndexOf code without the use of the pcmpestri instruction, only using AVX2 instructions.  This change accelerates String.IndexOf on average 1.3x for AVX2.  The benchmark numbers:
>> 
>> 
>> Benchmark	                                               Score		Latest		
>> StringIndexOf.advancedWithMediumSub   343.573		317.934		0.925375393x
>> StringIndexOf.advancedWithShortSub1	  1039.081		1053.96		1.014319384x
>> StringIndexOf.advancedWithShortSub2	      55.828		110.541		1.980027943x
>> StringIndexOf.constantPattern	                9.361		11.906		1.271872663x
>> StringIndexOf.searchCharLongSuccess	        4.216		4.218		1.000474383x
>> StringIndexOf.searchCharMediumSuccess	3.133		3.216		1.02649218x
>> StringIndexOf.searchCharShortSuccess	3.76		        3.761		1.000265957x
>> StringIndexOf.success	                                9.186		9.713		1.057369911x
>> StringIndexOf.successBig	                      14.341		46.343		3.231504079x
>> StringIndexOfChar.latin1_AVX2_String	  6220.918		12154.52		1.953814533x
>> StringIndexOfChar.latin1_AVX2_char	  5503.556		5540.044		1.006629895x
>> StringIndexOfChar.latin1_SSE4_String	  6978.854		6818.689		0.977049957x
>> StringIndexOfChar.latin1_SSE4_char	  5657.499		5474.624		0.967675646x
>> StringIndexOfChar.latin1_Short_String	  7132.541		6863.359		0.962260014x
>> StringIndexOfChar.latin1_Short_char	16013.389	      16162.437		1.009307711x
>> StringIndexOfChar.latin1_mixed_String	  7386.123	      14771.622		1.999915517x
>> StringIndexOfChar.latin1_mixed_char	  9901.671		9782.245		0.987938803
>
> Scott Gibbons has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rearrange; add lambdas for clarity

src/hotspot/cpu/x86/stubGenerator_x86_64_string.cpp line 576:

> 574:       broadcast_additional_needles(false, 0 /* unknown */, NUMBER_OF_NEEDLE_BYTES_TO_COMPARE, needle, needleLen, rTmp3,
> 575:                                    isUU, isUL, _masm);
> 576: 

Good to pass output xmm registers to this method.

src/hotspot/cpu/x86/stubGenerator_x86_64_string.cpp line 587:

> 585:       //  firstNeedleCompare has address of second element of needle
> 586:       //  compLen has length of comparison to do
> 587: 

This is not clear. firstNeedleCompare gets needle + NUMBER_OF_NEEDLE_BYTES_TO_COMPARE - 1 which is not necessarily the second element of needle. If it helps let us fix the NUMBER_OF_NEEDLE_BYTES_TO_COMPARE to 3 and have comments and code versus that only.

src/hotspot/cpu/x86/stubGenerator_x86_64_string.cpp line 590:

> 588:       compare_haystack_to_needle(false, 0, NUMBER_OF_NEEDLE_BYTES_TO_COMPARE, L_returnRBP, haystack, isU,
> 589:                                  DO_EARLY_BAILOUT, mask, needleLen, rTmp3, _masm);
> 590: 

It is better to pass the broadcasted xmm registers to compare_haystack_to_nedle. Basically pass input, output, and temps to all the methods.

src/hotspot/cpu/x86/stubGenerator_x86_64_string.cpp line 639:

> 637:     __ movl(rax, r8);
> 638:     __ subq(rcx, rbx);
> 639:     __ addq(rcx, rax);

This could be:
    __ subq(rcx, rbx);
    __ addq(rcx, r8);

src/hotspot/cpu/x86/stubGenerator_x86_64_string.cpp line 647:

> 645:     __ cmpq(r11, r10);
> 646:     __ movq(rbp, -1);
> 647:     __ cmovq(Assembler::belowEqual, rbp, r11);

This could be directly computed in rax:
    __ movq(rax, -1);
    __ cmovq(Assembler::belowEqual, rax, r11);
Also is it possible to not do cmov on some paths? It is an expensive operation.

src/hotspot/cpu/x86/stubGenerator_x86_64_string.cpp line 1010:

> 1008: static void broadcast_additional_needles(bool sizeKnown, int size, int bytesToCompare, Register needle,
> 1009:                                          Register needleLen, Register rTmp, bool isUU, bool isUL,
> 1010:                                          MacroAssembler *_masm) {

Good to add output XMM registers to the parameter list.

src/hotspot/cpu/x86/stubGenerator_x86_64_string.cpp line 1040:

> 1038:         __ vpbroadcastb(byte_1, Address(needle, 1), Assembler::AVX_256bit);
> 1039:       }
> 1040:     }

It will be good to have a function which broadcasts a needle element from a given offset into a vector register.
That function could take (needle address, offset, outout vector register, temps).
Such a function could then be called twice from here and from main function for offset 0.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1593046499
PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1593057834
PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1593045710
PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1592989197
PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1592992225
PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1593023349
PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1593006539

From egahlin at openjdk.org  Tue May  7 20:48:09 2024
From: egahlin at openjdk.org (Erik Gahlin)
Date: Tue, 7 May 2024 20:48:09 GMT
Subject: RFR: 8331876: JFR: Move file read and write events to java.base
Message-ID: <DDe0bKCC86AawVl7RylZ74uvvLBr2Zljpkcmxx1_WEU=.61cc10c6-b635-42dd-a850-b32ae1d68585@github.com>

Hi,

Could I have a review of a change that moves the jdk.FileRead and jdk.FileWrite events to java.base to remove the use of the ASM instrumentation.

Testing: jdk/jdk/jfr

Thanks
Erik

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

Commit messages:
 - Update comment
 - Initial

Changes: https://git.openjdk.org/jdk/pull/19129/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19129&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8331876
  Stats: 1241 lines in 19 files changed: 567 ins; 651 del; 23 mod
  Patch: https://git.openjdk.org/jdk/pull/19129.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19129/head:pull/19129

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

From smarks at openjdk.org  Tue May  7 21:24:53 2024
From: smarks at openjdk.org (Stuart Marks)
Date: Tue, 7 May 2024 21:24:53 GMT
Subject: RFR: 8305457: Implement java.io.IO [v3]
In-Reply-To: <wpwFGOp8E00csxi2Xb9b-02ZlkqnIZEpo8AqaMsQ4AM=.90acb47b-effc-4838-ba80-28938d4dc3c0@github.com>
References: <w2msiw_qaMEIJS3s9D4bg8pFbz5WIF0KdP6Mm-XFjLI=.85b2020b-8c46-4bac-8a69-4975b068f2ff@github.com>
 <wpwFGOp8E00csxi2Xb9b-02ZlkqnIZEpo8AqaMsQ4AM=.90acb47b-effc-4838-ba80-28938d4dc3c0@github.com>
Message-ID: <gKKAsZP1N9udDAXkoQC8yhVy8AFSp_tJxz5IwHLIkCc=.3cd32f19-2e4e-424f-9018-97f2015b9ae8@github.com>

On Tue, 7 May 2024 19:46:18 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Please review this PR which introduces the `java.io.IO` top-level class and three methods to `java.io.Console` for [Implicitly Declared Classes and Instance Main Methods (Third Preview)].
>> 
>> This PR has been obtained as `git merge --squash` of a now obsolete [draft PR].
>> 
>> [Implicitly Declared Classes and Instance Main Methods (Third Preview)]: https://bugs.openjdk.org/browse/JDK-8323335
>> [draft PR]: https://github.com/openjdk/jdk/pull/18921
>
> Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Strengthen tests after 8330998
>   
>   https://github.com/openjdk/jdk/pull/18996 now allows us to test
>   Console IO better.

src/java.base/share/classes/java/io/IO.java line 37:

> 35:  * is {@code null}; otherwise, the effect is as if a similarly-named method
> 36:  * had been called on that console.
> 37:  *

Add a note here on encoding (character set), something like


Output from methods in this class uses the character set of the system console as specified by {@link Console#charset}.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19112#discussion_r1593109243

From rotanolexandr842 at gmail.com  Tue May  7 21:29:38 2024
From: rotanolexandr842 at gmail.com (Olexandr Rotan)
Date: Wed, 8 May 2024 00:29:38 +0300
Subject: Enumerated streams
Message-ID: <CAL5bRt-QMgutbpi4uZZx=02WLc739dy3cgCiOooo6xM-EFr6Gg@mail.gmail.com>

I have created some drafts of the EnumeratedStream API. But firstly, I have
noticed that we have not formalized problems we are solving with them.
Moreover, during the implementation process, I have discovered that there
are possibly a much wider range of applications for those streams. Instead
of just enumerating streams, those streams could be adapted to supply any
kind of metadata along with the object itself, which would provide much
more opportunities and EnumeratedStreams could be just one of possible
implementations of this API. So let's point out problems solved by the new
API.

For enumerated streams specifically:
1. Data-oriented design. Data oriented  design  is a programming paradigm
that is applied when a system operates on large amounts of data. In this
paradigm objects are basically being split into "dimensions", which are
basically 1d collections of values List of collections of values together
represent a list of objects. You can think of this as a table where columns
are 1d collections (dimensions), and rows are objects. For this approach
stream enumeration is crucial to be able to access value from another
dimension "on the same row". It could seem that data-oriented programming
is fairly rare to be applied, but, actually, this is the main approach to
work with large amounts of data. For example, pandas in python, to the best
of my knowledge, implement a data-oriented approach.
2. Index lookup operations. While I still stand my ground that
List.findIndex is a preferred approach, enumerated streams could also be
used for things like "find all matching indexes in list".
3. Working with distances and hotspots. I am not really familiar
with this, but David Alayachew in a related thread has explained it like so
(quoting below):

2. Building jumps/skips -- Fetching the indexes at hotspots, and then using
them to create a skip-list-esque structure between the hotspots. Very
useful for realigning search strategies.
3. Calculating distance using index -- This is a sister concept to bullet
1. Let's say I built my skip list above, and have determined that my
desired target is not in the hotspots. I can make a better decision to go
parallel or sequential by seeing the distance between hotspots. That
distance would be taken by subtracting hotspot index by hotspot index.\

End of quote.

I am sure there is more to it, but for now, let's get over this section.

As for metadata-supplying streams in general:
1. Replacing visitor pattern, Not necessarily streams, but fluent API in
general are widely used to provide a better alternative for Visitor
pattern. Such metadata could include current path, node position etc.
2. Any complex custom data processing pipeline. Metadata could represent
some data that is evaluated based on a processed object. Such processing
pipelines could extend the hypothetical "MetadataPipeline", implement a
method that provides metadata based on an object that is processed and
enjoy all benefits of fluent data processing zipped with metadata for it.
3. Virtually any kind of metadata-aware operations. Timestamps, geospatial
data, tagging/classifying, possible stateful operations on data, source or
origin info, quality?confidence scores etc. I think there is application
for this in virtually every field.

Now that we described problems being solved. Let's move on to
implementation details. There were discussions on a gatherer-based vs
new-pipeline-type-based approach. I have implemented 6 operations (map,
flatMap, filter, peek, takeWhile, dropWhile) both ways and here are some of
my thoughts.

1. Complexity of implementation. Gatherers, without a doubt, were much
easier to implement. For now class-based streams don't even implement
parallel evaluation and it will be really hard to implement parallel
evaluation in a way that enumerates elements in order of their occurence,
2. Performance. Both approaches demonstrate fairly similar performance.
Gatherers outperform for 10-20% with findAny() terminal operation, while
for toList() terminal operation class-based approach is usually 10-20%
faster. Im sure my code could use A LOT of optimization, but this could
give initial understanding of performance of both approaches. As for
memory usage, the gatherer-based approach usually consumes up to 2 times
more memory. This is just initial lightweight benchmark results, more
comprehensive results with visualization will come in a few days after more
complex benchmarking completes.
3. Preserving indexes. Expectedly, gatherers do not preserve indexes for
further operations. Imo, this is what kills any benefits of this approach.
This just removes a major part of potential use cases. Things like "find
all matching indexes are still possible, but in an undesired (as I think)
way. Consider following:

With stream-based approach:
list,stream().filter((i, x) -> ...).map((i, _) -> i)

With gatherer-based:
list.stream().gather(Gathrers.mapMultiEnumerated((sink, i, x) -> { if
(predicate.test(i, x) sink.accept(i))

As you see, this first is clean and readable, while the second is merging a
few steps of processing into one which is clearly undesirable.

This is omittable using something like zipWithIndex() gather operation and
then using a stream of zipped objects, but unless there is a value classes,
this will introduce performance issues and (as i think) not the most
friendly and discoverable API.

4. Terminal operations. While gatherers could be "effectively terminal",
there are few issues with this. Not even considering the fact that
gatherers initially were designed for intermediate operations, and terminal
operations would be much suitable for collectors if they were able to short
circuit, for "effectively terminal" gatherers to be executed, terminal
operation still has to be called, and will require some resources anyway,
There is no terminal operation that just closes the stream as far as I
know. Therefore, operations like forEachEnumerated or reduceEnumerated
using gatherers will have some performance issues and not the most obvious
API for people that aren't familiar with how deferred evaluation works.

Would appreciate any thoughts on what I have written above.If someone is
willing to help me in development, here is a link to github repo`s branch:
https://github.com/Evemose/jdk/tree/enumerated-streams

Best regards.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240508/652e1975/attachment.htm>

From prappo at openjdk.org  Tue May  7 22:10:53 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Tue, 7 May 2024 22:10:53 GMT
Subject: RFR: 8330205: Initial troff manpage generation for JDK 24
In-Reply-To: <6tFYXJ753At7nUZTy8khVVeiQHYtZRBRYegXSTXViUY=.f3110151-9ea0-4b55-89f1-90039273fd34@github.com>
References: <6tFYXJ753At7nUZTy8khVVeiQHYtZRBRYegXSTXViUY=.f3110151-9ea0-4b55-89f1-90039273fd34@github.com>
Message-ID: <Ax3HA7Cn9cS7l4Sq6zx7hKROScWxfaxstyVbYYjwsjk=.2dbd81da-e52b-4fa6-96ad-806e6f8da96e@github.com>

On Tue, 7 May 2024 11:53:19 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> Please review this mechanical change to man pages. This PR should be integrated after https://github.com/openjdk/jdk/pull/18787.

Thanks for reviewing it Joe, I'm now delegating integration of this PR to @JesperIRL, you, or anyone who will be integrating https://github.com/openjdk/jdk/pull/18787.

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

PR Comment: https://git.openjdk.org/jdk/pull/19119#issuecomment-2099395990

From prappo at openjdk.org  Tue May  7 22:16:52 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Tue, 7 May 2024 22:16:52 GMT
Subject: RFR: 8305457: Implement java.io.IO [v3]
In-Reply-To: <gKKAsZP1N9udDAXkoQC8yhVy8AFSp_tJxz5IwHLIkCc=.3cd32f19-2e4e-424f-9018-97f2015b9ae8@github.com>
References: <w2msiw_qaMEIJS3s9D4bg8pFbz5WIF0KdP6Mm-XFjLI=.85b2020b-8c46-4bac-8a69-4975b068f2ff@github.com>
 <wpwFGOp8E00csxi2Xb9b-02ZlkqnIZEpo8AqaMsQ4AM=.90acb47b-effc-4838-ba80-28938d4dc3c0@github.com>
 <gKKAsZP1N9udDAXkoQC8yhVy8AFSp_tJxz5IwHLIkCc=.3cd32f19-2e4e-424f-9018-97f2015b9ae8@github.com>
Message-ID: <-rUItvjHKXhD8yc7EaIbPOHHdu15dbYID0QU2uNutlU=.877dcab0-a5c7-493b-b62b-e0adb0a2ce40@github.com>

On Tue, 7 May 2024 21:19:59 GMT, Stuart Marks <smarks at openjdk.org> wrote:

>> Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Strengthen tests after 8330998
>>   
>>   https://github.com/openjdk/jdk/pull/18996 now allows us to test
>>   Console IO better.
>
> src/java.base/share/classes/java/io/IO.java line 37:
> 
>> 35:  * is {@code null}; otherwise, the effect is as if a similarly-named method
>> 36:  * had been called on that console.
>> 37:  *
> 
> Add a note here on encoding (character set), something like
> 
> 
> Output from methods in this class uses the character set of the system console as specified by {@link Console#charset}.

Seems redundant since we express `IO` methods in therms of those of `Console` in the specification, no?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19112#discussion_r1593161920

From jjg at openjdk.org  Tue May  7 22:49:52 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Tue, 7 May 2024 22:49:52 GMT
Subject: RFR: 8330205: Initial troff manpage generation for JDK 24
In-Reply-To: <6tFYXJ753At7nUZTy8khVVeiQHYtZRBRYegXSTXViUY=.f3110151-9ea0-4b55-89f1-90039273fd34@github.com>
References: <6tFYXJ753At7nUZTy8khVVeiQHYtZRBRYegXSTXViUY=.f3110151-9ea0-4b55-89f1-90039273fd34@github.com>
Message-ID: <I2vdyKRyeXvT4eh5stuey2iikuERgf0FaTWcLH0zfkU=.e5752386-61d8-4479-a554-1be2192baa8b@github.com>

On Tue, 7 May 2024 11:53:19 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> Please review this mechanical change to man pages. This PR should be integrated after https://github.com/openjdk/jdk/pull/18787.

Marked as reviewed by jjg (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/19119#pullrequestreview-2044314419

From dl at openjdk.org  Tue May  7 22:54:13 2024
From: dl at openjdk.org (Doug Lea)
Date: Tue, 7 May 2024 22:54:13 GMT
Subject: RFR: 8322732: ForkJoinPool may underutilize cores in async mode
Message-ID: <xRyDMAsSZ7obqpr3Aoc5qrHqILeJMxFVCeiRdctMI3U=.d5d3cd56-32eb-4431-ac01-081822fc86c6@github.com>

This set of changes address causes of poor utilization with small numbers of cores due to overly aggressive contention avoidance. A number of further adjustments were needed to still avoid most contention effects in deployments with large numbers of cores

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

Commit messages:
 - Merge branch 'openjdk:master' into JDK-8322732
 - Repack some fields; adjust control flow
 - Merge branch 'openjdk:master' into JDK-8322732
 - Next version
 - Merge branch 'openjdk:master' into JDK-8322732
 - Reduce unneeded signals
 - Merge branch 'openjdk:master' into JDK-8322732
 - reduce memory contention
 - Merge branch 'openjdk:master' into JDK-8322732
 - re-integrate docs
 - ... and 23 more: https://git.openjdk.org/jdk/compare/f12ed061...7e64cdfc

Changes: https://git.openjdk.org/jdk/pull/19131/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19131&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8322732
  Stats: 593 lines in 1 file changed: 162 ins; 159 del; 272 mod
  Patch: https://git.openjdk.org/jdk/pull/19131.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19131/head:pull/19131

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

From sviswanathan at openjdk.org  Wed May  8 00:26:59 2024
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Wed, 8 May 2024 00:26:59 GMT
Subject: RFR: 8320448: Accelerate IndexOf using AVX2 [v19]
In-Reply-To: <eQ4OBFrF8JlDJ1h9awTDOc0kfCc37IlL5vdqtuaqls0=.8f00616d-08e1-4f28-a7a5-5095116d2595@github.com>
References: <uWi4QxH31hL93771gkl_GgvP0m84IRSoR_1Yi8hD17E=.bc6ed458-7081-4c3f-9348-f59358fa05a4@github.com>
 <eQ4OBFrF8JlDJ1h9awTDOc0kfCc37IlL5vdqtuaqls0=.8f00616d-08e1-4f28-a7a5-5095116d2595@github.com>
Message-ID: <L2bOw4xNG5-HrKGDgB6HhSqlAqFR-AU3XMC_IzSDY_w=.fb744803-3b6a-471e-947b-af79600befca@github.com>

On Sat, 4 May 2024 19:35:21 GMT, Scott Gibbons <sgibbons at openjdk.org> wrote:

>> Re-write the IndexOf code without the use of the pcmpestri instruction, only using AVX2 instructions.  This change accelerates String.IndexOf on average 1.3x for AVX2.  The benchmark numbers:
>> 
>> 
>> Benchmark	                                               Score		Latest		
>> StringIndexOf.advancedWithMediumSub   343.573		317.934		0.925375393x
>> StringIndexOf.advancedWithShortSub1	  1039.081		1053.96		1.014319384x
>> StringIndexOf.advancedWithShortSub2	      55.828		110.541		1.980027943x
>> StringIndexOf.constantPattern	                9.361		11.906		1.271872663x
>> StringIndexOf.searchCharLongSuccess	        4.216		4.218		1.000474383x
>> StringIndexOf.searchCharMediumSuccess	3.133		3.216		1.02649218x
>> StringIndexOf.searchCharShortSuccess	3.76		        3.761		1.000265957x
>> StringIndexOf.success	                                9.186		9.713		1.057369911x
>> StringIndexOf.successBig	                      14.341		46.343		3.231504079x
>> StringIndexOfChar.latin1_AVX2_String	  6220.918		12154.52		1.953814533x
>> StringIndexOfChar.latin1_AVX2_char	  5503.556		5540.044		1.006629895x
>> StringIndexOfChar.latin1_SSE4_String	  6978.854		6818.689		0.977049957x
>> StringIndexOfChar.latin1_SSE4_char	  5657.499		5474.624		0.967675646x
>> StringIndexOfChar.latin1_Short_String	  7132.541		6863.359		0.962260014x
>> StringIndexOfChar.latin1_Short_char	16013.389	      16162.437		1.009307711x
>> StringIndexOfChar.latin1_mixed_String	  7386.123	      14771.622		1.999915517x
>> StringIndexOfChar.latin1_mixed_char	  9901.671		9782.245		0.987938803
>
> Scott Gibbons has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rearrange; add lambdas for clarity

src/hotspot/cpu/x86/stubGenerator_x86_64_string.cpp line 1082:

> 1080: // noMatch - label bound outside to jump to if there is no match
> 1081: // haystack - the address of the first byte of the haystack
> 1082: // hsLen - the sizeof the haystack

Good to specify if the size  (size of needle) and hsLen (size of haystack) is in bytes or elements.

src/hotspot/cpu/x86/stubGenerator_x86_64_string.cpp line 1149:

> 1147: 
> 1148:   if (size == (isU ? 2 : 1)) {
> 1149:     __ vpmovmskb(eq_mask, cmp_0, Assembler::AVX_256bit);

vpmovmskb is being done twice if doEarlyBailout is set to 1 (the setting we have currently).
If it helps to simplify, we could assume that doEarlyBailout is always set to 1 and remove this configurability.

src/hotspot/cpu/x86/stubGenerator_x86_64_string.cpp line 1174:

> 1172: #define lastMask rTmp
> 1173:     __ vpmovmskb(lastMask, cmp_k, Assembler::AVX_256bit);
> 1174:     __ shrq(lastMask);

did you mean to shift the lastMask by shiftVal here?

src/hotspot/cpu/x86/stubGenerator_x86_64_string.cpp line 1185:

> 1183:       if (size > (isU ? 4 : 2)) {
> 1184:         if (doEarlyBailout) {
> 1185:           __ testl(eq_mask, eq_mask);

The masks are 32 bit as we are comparing max 32 byes (256 bits) at a time. So we could consistently do either andl, testl, shrl or andq, testq, shrq.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1593225178
PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1593225488
PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1593227487
PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1593229554

From smarks at openjdk.org  Wed May  8 01:10:55 2024
From: smarks at openjdk.org (Stuart Marks)
Date: Wed, 8 May 2024 01:10:55 GMT
Subject: RFR: 8305457: Implement java.io.IO [v3]
In-Reply-To: <-rUItvjHKXhD8yc7EaIbPOHHdu15dbYID0QU2uNutlU=.877dcab0-a5c7-493b-b62b-e0adb0a2ce40@github.com>
References: <w2msiw_qaMEIJS3s9D4bg8pFbz5WIF0KdP6Mm-XFjLI=.85b2020b-8c46-4bac-8a69-4975b068f2ff@github.com>
 <wpwFGOp8E00csxi2Xb9b-02ZlkqnIZEpo8AqaMsQ4AM=.90acb47b-effc-4838-ba80-28938d4dc3c0@github.com>
 <gKKAsZP1N9udDAXkoQC8yhVy8AFSp_tJxz5IwHLIkCc=.3cd32f19-2e4e-424f-9018-97f2015b9ae8@github.com>
 <-rUItvjHKXhD8yc7EaIbPOHHdu15dbYID0QU2uNutlU=.877dcab0-a5c7-493b-b62b-e0adb0a2ce40@github.com>
Message-ID: <FKuFd0k7gxnh7AIL-FyolcXlffAhCA6ER8M_6HMAXDQ=.a889a65b-6572-4f37-b735-39a590caa659@github.com>

On Tue, 7 May 2024 22:12:55 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> src/java.base/share/classes/java/io/IO.java line 37:
>> 
>>> 35:  * is {@code null}; otherwise, the effect is as if a similarly-named method
>>> 36:  * had been called on that console.
>>> 37:  *
>> 
>> Add a note here on encoding (character set), something like
>> 
>> 
>> Output from methods in this class uses the character set of the system console as specified by {@link Console#charset}.
>
> Seems redundant since we express `IO` methods in therms of those of `Console` in the specification, no?

It's strictly redundant in the sense that, if one reads all the specifications and applies reasoning using the right facts, one could already reach that conclusion. However, I think it's a useful clarification, because if you're looking at `java.io.IO` and you ask what charset it uses, you might not know that you need to look at the `Console.charset` method. You might go looking on Console to find the answer, and you might or might not find that method. (Arguably Console's specs should be improved too since the charset is a global property of the Console instance and this should be mentioned in the class specs.)

Anyway Joe asked about Locales in the comments on the CSR [JDK-8331610](https://bugs.openjdk.org/browse/JDK-8331610) and while Locale isn't relevant, charset is, so it seems reasonable to mention it explicitly here.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19112#discussion_r1593257656

From jkratochvil at openjdk.org  Wed May  8 02:56:10 2024
From: jkratochvil at openjdk.org (Jan Kratochvil)
Date: Wed, 8 May 2024 02:56:10 GMT
Subject: RFR: 8322420: [Linux] cgroup v2: Limits in parent nested control
 groups are not detected [v9]
In-Reply-To: <c6DtrskKpUb_gpAtfqMTy3HLPdk0TiVZGfU5wcNl4Eo=.52b62a49-421b-4853-ba58-a878b4d312c6@github.com>
References: <c6DtrskKpUb_gpAtfqMTy3HLPdk0TiVZGfU5wcNl4Eo=.52b62a49-421b-4853-ba58-a878b4d312c6@github.com>
Message-ID: <bNaVM9mDiYpJlKYHp5aD6VEBCGe0QTSbYwdTe85RBkw=.0ea6c2d6-d5b6-4661-8e08-59f053e20f97@github.com>

> The testcase requires root permissions.
> 
> Designed by  Severin Gehwolf, implemented by Jan Kratochvil.

Jan Kratochvil has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 49 commits:

 - centos7 compat
 - 64a5feb6: <no commit message found>
 - fixes
 - e514824f: <no commit message found>
 - ebb459e9: <no commit message found>
 - Merge branch 'jerboaarefactor-merge' into jerboaarefactor-merge-cgroup
 - Merge branch 'jerboaarefactor' into jerboaarefactor-merge
 - Merge remote-tracking branch 'origin/master' into jerboaarefactor
 - Merge remote-tracking branch 'origin/master' into jerboaarefactor-merge
 - Merge branch 'master-cgroup' into jerboaarefactor-merge-cgroup
 - ... and 39 more: https://git.openjdk.org/jdk/compare/9347bb7d...3da3a9e5

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

Changes: https://git.openjdk.org/jdk/pull/17198/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17198&range=08
  Stats: 2254 lines in 20 files changed: 1078 ins; 810 del; 366 mod
  Patch: https://git.openjdk.org/jdk/pull/17198.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17198/head:pull/17198

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

From jkratochvil at openjdk.org  Wed May  8 03:04:28 2024
From: jkratochvil at openjdk.org (Jan Kratochvil)
Date: Wed, 8 May 2024 03:04:28 GMT
Subject: RFR: 8322420: [Linux] cgroup v2: Limits in parent nested control
 groups are not detected [v10]
In-Reply-To: <c6DtrskKpUb_gpAtfqMTy3HLPdk0TiVZGfU5wcNl4Eo=.52b62a49-421b-4853-ba58-a878b4d312c6@github.com>
References: <c6DtrskKpUb_gpAtfqMTy3HLPdk0TiVZGfU5wcNl4Eo=.52b62a49-421b-4853-ba58-a878b4d312c6@github.com>
Message-ID: <eJd8SJypTRcP-Bc6GC48d6So5Y_Q5O4uvshxfcj4yfU=.21e72235-c8e4-4c39-8ae8-ff66f66fb752@github.com>

> The testcase requires root permissions.
> 
> Designed by  Severin Gehwolf, implemented by Jan Kratochvil.

Jan Kratochvil has updated the pull request incrementally with one additional commit since the last revision:

  whitespace fix

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17198/files
  - new: https://git.openjdk.org/jdk/pull/17198/files/3da3a9e5..efb83999

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

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

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

From jkratochvil at openjdk.org  Wed May  8 03:04:31 2024
From: jkratochvil at openjdk.org (Jan Kratochvil)
Date: Wed, 8 May 2024 03:04:31 GMT
Subject: RFR: 8322420: [Linux] cgroup v2: Limits in parent nested control
 groups are not detected [v9]
In-Reply-To: <bNaVM9mDiYpJlKYHp5aD6VEBCGe0QTSbYwdTe85RBkw=.0ea6c2d6-d5b6-4661-8e08-59f053e20f97@github.com>
References: <c6DtrskKpUb_gpAtfqMTy3HLPdk0TiVZGfU5wcNl4Eo=.52b62a49-421b-4853-ba58-a878b4d312c6@github.com>
 <bNaVM9mDiYpJlKYHp5aD6VEBCGe0QTSbYwdTe85RBkw=.0ea6c2d6-d5b6-4661-8e08-59f053e20f97@github.com>
Message-ID: <-SpzkAC5lqKUTFCx8RWd4H5YtruoJ4wi7tqXhVPe0w0=.0ceb0034-f89c-47b2-9153-8dcf25f947f7@github.com>

On Wed, 8 May 2024 02:56:10 GMT, Jan Kratochvil <jkratochvil at openjdk.org> wrote:

>> The testcase requires root permissions.
>> 
>> Designed by  Severin Gehwolf, implemented by Jan Kratochvil.
>
> Jan Kratochvil has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 49 commits:
> 
>  - centos7 compat
>  - 64a5feb6: <no commit message found>
>  - fixes
>  - e514824f: <no commit message found>
>  - ebb459e9: <no commit message found>
>  - Merge branch 'jerboaarefactor-merge' into jerboaarefactor-merge-cgroup
>  - Merge branch 'jerboaarefactor' into jerboaarefactor-merge
>  - Merge remote-tracking branch 'origin/master' into jerboaarefactor
>  - Merge remote-tracking branch 'origin/master' into jerboaarefactor-merge
>  - Merge branch 'master-cgroup' into jerboaarefactor-merge-cgroup
>  - ... and 39 more: https://git.openjdk.org/jdk/compare/9347bb7d...3da3a9e5

Your patch https://github.com/jerboaa/jdk/commit/92aaa6fd7e3ff8b64de064fecfcd725a157cb5bb#diff-1c49a6b40a810aef82b7da9bfea8f03e07a43062977ba65f75df63c4b7c5b149R89 contains a tab.

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

PR Comment: https://git.openjdk.org/jdk/pull/17198#issuecomment-2099650738

From jpai at openjdk.org  Wed May  8 05:31:55 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 8 May 2024 05:31:55 GMT
Subject: RFR: 8330005: RandomGeneratorFactory.getDefault() throws exception
 when the runtime image only has java.base module [v6]
In-Reply-To: <ZCknDWh6FaLWfXb9c9QFsnK9GrqdTXaHSVcG5jmZ6g8=.c1dd43f6-c571-46e8-880f-7f864fc56b62@github.com>
References: <FymnGzlEZUHwHgW6At_bqYIoF7wYsjD_vBhk60PrwFE=.1ef4072e-c3a4-4930-8d18-ba132fa90c56@github.com>
 <ZCknDWh6FaLWfXb9c9QFsnK9GrqdTXaHSVcG5jmZ6g8=.c1dd43f6-c571-46e8-880f-7f864fc56b62@github.com>
Message-ID: <c9eK7ZcrAvF7Ag65YvmbbTOMg7ClS5pkFY1vvFt285Q=.286b2b6f-27b9-4619-8a03-5532477c7e64@github.com>

On Sat, 4 May 2024 18:29:25 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> Move all random generators mandated in package `java.util.random` and currently implemented in module `jdk.random` to module `java.base`, and remove module `jdk.random`.
>
> Raffaello Giulietti 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 seven additional commits since the last revision:
> 
>  - Merge branch 'master' into 8330005
>  - Restrict RandomGenerator service providers to those loadable by the platform class loader.
>  - Typo.
>  - Added @uses javadoc tag for j.u.r.RandomGenerator in java.base.
>  - Terminology changes.
>  - Renamed package jdk.random to jdk.internal.random.
>  - 8330005: RandomGeneratorFactory.getDefault() throws exception when the runtime image only has java.base module

Hello Raffaello, the proposed changes look OK to me. Do you think we should add a jtreg test for this?

In general, the test coverage for these APIs appears to be missing. I think that can be addressed separately in some of the upcoming changes.

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

PR Review: https://git.openjdk.org/jdk/pull/18932#pullrequestreview-2044656083

From jpai at openjdk.org  Wed May  8 05:37:24 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 8 May 2024 05:37:24 GMT
Subject: RFR: 8173970: jar tool should have a way to extract to a directory
 [v5]
In-Reply-To: <MRlQpBJcCaZSMcnssPw88TaYd2cAwiJOkfI4k8hXM0E=.76718687-c714-4d12-a03b-fa0fdb51a9ff@github.com>
References: <MRlQpBJcCaZSMcnssPw88TaYd2cAwiJOkfI4k8hXM0E=.76718687-c714-4d12-a03b-fa0fdb51a9ff@github.com>
Message-ID: <APZvm76TDV-TwhV7PpsP9aTpdE9AmdcaU3zVCbHuv7U=.c53bf4f5-da9f-4c6a-8242-4e18c8551885@github.com>

> Can I please get a review for this patch which proposes to implement the enhancement request noted in https://bugs.openjdk.java.net/browse/JDK-8173970?
> 
> The commit in this PR introduces the `-o` and `--output-dir` option to the `jar` command. The option takes a path to a destination directory as a value and extracts the contents of the jar into that directory. This is an optional option and the changes in the commit continue to maintain backward compatibility where the jar is extracted into current directory, if no `-o` or `--output-dir` option has been specified.
> 
> As far as I know, there hasn't been any discussion on what the name of this new option should be. I was initially thinking of using `-d` but that is currently used by the `jar` command for a different purpose. So I decided to use `-o` and `--output-dir`. This is of course open for change depending on any suggestions in this PR.
> 
> The commit in this PR also updates the `jar.properties` file which contains the English version of the jar command's `--help` output. However, no changes have been done to the internationalization files corresponding to this one (for example: `jar_de.properties`), because I don't know what process needs to be followed to have those files updated (if at all they need to be updated).
> 
> The commit also includes a jtreg testcase which verifies the usage of this new option.

Jaikiran Pai has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 15 commits:

 - cleanup testExtractNoDestDirWithPFlag() test
 - merge latest from master branch
 - merge latest from master branch
 - convert the new test to junit
 - merge latest from master branch
 - Lance's review - include tests for --extract long form option
 - cleanup after each test
 - Adjust test for new error messages
 - Lance's review - add a code comment for xdestDir
 - Lance's review - updates to the help messages in jar.properties
 - ... and 5 more: https://git.openjdk.org/jdk/compare/3b8227ba...46fb5a8e

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

Changes: https://git.openjdk.org/jdk/pull/2752/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=2752&range=04
  Stats: 569 lines in 4 files changed: 558 ins; 0 del; 11 mod
  Patch: https://git.openjdk.org/jdk/pull/2752.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/2752/head:pull/2752

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

From jpai at openjdk.org  Wed May  8 05:44:54 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 8 May 2024 05:44:54 GMT
Subject: RFR: 8305457: Implement java.io.IO [v3]
In-Reply-To: <wpwFGOp8E00csxi2Xb9b-02ZlkqnIZEpo8AqaMsQ4AM=.90acb47b-effc-4838-ba80-28938d4dc3c0@github.com>
References: <w2msiw_qaMEIJS3s9D4bg8pFbz5WIF0KdP6Mm-XFjLI=.85b2020b-8c46-4bac-8a69-4975b068f2ff@github.com>
 <wpwFGOp8E00csxi2Xb9b-02ZlkqnIZEpo8AqaMsQ4AM=.90acb47b-effc-4838-ba80-28938d4dc3c0@github.com>
Message-ID: <C1Pvc8KO7vUGELLaqcXpepoK_MpvChaDcZqfroVICo0=.5ab8bef5-fa21-4618-a903-219d733045a0@github.com>

On Tue, 7 May 2024 19:46:18 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Please review this PR which introduces the `java.io.IO` top-level class and three methods to `java.io.Console` for [Implicitly Declared Classes and Instance Main Methods (Third Preview)].
>> 
>> This PR has been obtained as `git merge --squash` of a now obsolete [draft PR].
>> 
>> [Implicitly Declared Classes and Instance Main Methods (Third Preview)]: https://bugs.openjdk.org/browse/JDK-8323335
>> [draft PR]: https://github.com/openjdk/jdk/pull/18921
>
> Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Strengthen tests after 8330998
>   
>   https://github.com/openjdk/jdk/pull/18996 now allows us to test
>   Console IO better.

src/java.base/share/classes/java/io/Console.java line 188:

> 186: 
> 187:     /**
> 188:      * Writes a prompt as if by calling {@code print}, then reads a single line

Should `{@code print}` instead be `{@link Console#print() print()}`?

src/java.base/share/classes/java/io/Console.java line 192:

> 190:      *
> 191:      * @param  prompt
> 192:      *         A prompt string.

Hello Pavel, should this specify whether `prompt`  can be null?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19112#discussion_r1593411945
PR Review Comment: https://git.openjdk.org/jdk/pull/19112#discussion_r1593411393

From jpai at openjdk.org  Wed May  8 05:50:59 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 8 May 2024 05:50:59 GMT
Subject: RFR: 8305457: Implement java.io.IO [v3]
In-Reply-To: <wpwFGOp8E00csxi2Xb9b-02ZlkqnIZEpo8AqaMsQ4AM=.90acb47b-effc-4838-ba80-28938d4dc3c0@github.com>
References: <w2msiw_qaMEIJS3s9D4bg8pFbz5WIF0KdP6Mm-XFjLI=.85b2020b-8c46-4bac-8a69-4975b068f2ff@github.com>
 <wpwFGOp8E00csxi2Xb9b-02ZlkqnIZEpo8AqaMsQ4AM=.90acb47b-effc-4838-ba80-28938d4dc3c0@github.com>
Message-ID: <1dohhjiIFuH5FXBkA0YnD4rSmR-e0Bs5A1_zQTkVxDY=.c5fc9a18-83ca-4bb5-abfe-1ca3e8e4a024@github.com>

On Tue, 7 May 2024 19:46:18 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Please review this PR which introduces the `java.io.IO` top-level class and three methods to `java.io.Console` for [Implicitly Declared Classes and Instance Main Methods (Third Preview)].
>> 
>> This PR has been obtained as `git merge --squash` of a now obsolete [draft PR].
>> 
>> [Implicitly Declared Classes and Instance Main Methods (Third Preview)]: https://bugs.openjdk.org/browse/JDK-8323335
>> [draft PR]: https://github.com/openjdk/jdk/pull/18921
>
> Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Strengthen tests after 8330998
>   
>   https://github.com/openjdk/jdk/pull/18996 now allows us to test
>   Console IO better.

src/java.base/share/classes/java/io/Console.java line 194:

> 192:      *         A prompt string.
> 193:      *
> 194:      * @throws IOError

I'm guessing this specifies `IOError` instead of `IOException` so that the caller doesn't have to handle a checked exception? If so, would it be better to throw an `java.io.UncheckedIOException`, to avoid throwing `Error`s?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19112#discussion_r1593414616

From jpai at openjdk.org  Wed May  8 05:51:00 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 8 May 2024 05:51:00 GMT
Subject: RFR: 8305457: Implement java.io.IO [v3]
In-Reply-To: <1dohhjiIFuH5FXBkA0YnD4rSmR-e0Bs5A1_zQTkVxDY=.c5fc9a18-83ca-4bb5-abfe-1ca3e8e4a024@github.com>
References: <w2msiw_qaMEIJS3s9D4bg8pFbz5WIF0KdP6Mm-XFjLI=.85b2020b-8c46-4bac-8a69-4975b068f2ff@github.com>
 <wpwFGOp8E00csxi2Xb9b-02ZlkqnIZEpo8AqaMsQ4AM=.90acb47b-effc-4838-ba80-28938d4dc3c0@github.com>
 <1dohhjiIFuH5FXBkA0YnD4rSmR-e0Bs5A1_zQTkVxDY=.c5fc9a18-83ca-4bb5-abfe-1ca3e8e4a024@github.com>
Message-ID: <Wnx97Qh19TRpMUBxvInc_7b_gksS6-t_tKRAt0awG_o=.9c362e3d-cb68-4839-a1c2-310eebd28000@github.com>

On Wed, 8 May 2024 05:45:55 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Strengthen tests after 8330998
>>   
>>   https://github.com/openjdk/jdk/pull/18996 now allows us to test
>>   Console IO better.
>
> src/java.base/share/classes/java/io/Console.java line 194:
> 
>> 192:      *         A prompt string.
>> 193:      *
>> 194:      * @throws IOError
> 
> I'm guessing this specifies `IOError` instead of `IOException` so that the caller doesn't have to handle a checked exception? If so, would it be better to throw an `java.io.UncheckedIOException`, to avoid throwing `Error`s?

Actually, it appears that the existing APIs on `java.io.Console` are specified to throw a `java.io.IOError`. So this isn't something new that is being introduced. So please ignore that question.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19112#discussion_r1593416464

From jpai at openjdk.org  Wed May  8 05:55:52 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 8 May 2024 05:55:52 GMT
Subject: RFR: 8305457: Implement java.io.IO [v3]
In-Reply-To: <wpwFGOp8E00csxi2Xb9b-02ZlkqnIZEpo8AqaMsQ4AM=.90acb47b-effc-4838-ba80-28938d4dc3c0@github.com>
References: <w2msiw_qaMEIJS3s9D4bg8pFbz5WIF0KdP6Mm-XFjLI=.85b2020b-8c46-4bac-8a69-4975b068f2ff@github.com>
 <wpwFGOp8E00csxi2Xb9b-02ZlkqnIZEpo8AqaMsQ4AM=.90acb47b-effc-4838-ba80-28938d4dc3c0@github.com>
Message-ID: <Z-0pp39dfPkKEtHlkyKtwKBlTI5dW8lnVl-MtJfuYNw=.034ab167-99ed-4fde-84cf-daca6998726f@github.com>

On Tue, 7 May 2024 19:46:18 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Please review this PR which introduces the `java.io.IO` top-level class and three methods to `java.io.Console` for [Implicitly Declared Classes and Instance Main Methods (Third Preview)].
>> 
>> This PR has been obtained as `git merge --squash` of a now obsolete [draft PR].
>> 
>> [Implicitly Declared Classes and Instance Main Methods (Third Preview)]: https://bugs.openjdk.org/browse/JDK-8323335
>> [draft PR]: https://github.com/openjdk/jdk/pull/18921
>
> Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Strengthen tests after 8330998
>   
>   https://github.com/openjdk/jdk/pull/18996 now allows us to test
>   Console IO better.

src/java.base/share/classes/java/io/Console.java line 151:

> 149:     /**
> 150:      * Writes a string representation of the specified object to this console's
> 151:      * output stream, terminates the line and then flushes the console.

Should this specify if the line termination will be platform dependent character(s) or independent of the platform?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19112#discussion_r1593420018

From jpai at openjdk.org  Wed May  8 06:01:56 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 8 May 2024 06:01:56 GMT
Subject: RFR: 8305457: Implement java.io.IO [v3]
In-Reply-To: <wpwFGOp8E00csxi2Xb9b-02ZlkqnIZEpo8AqaMsQ4AM=.90acb47b-effc-4838-ba80-28938d4dc3c0@github.com>
References: <w2msiw_qaMEIJS3s9D4bg8pFbz5WIF0KdP6Mm-XFjLI=.85b2020b-8c46-4bac-8a69-4975b068f2ff@github.com>
 <wpwFGOp8E00csxi2Xb9b-02ZlkqnIZEpo8AqaMsQ4AM=.90acb47b-effc-4838-ba80-28938d4dc3c0@github.com>
Message-ID: <gDowRhUuCc_bTGTQbQXb7Q7CffLt2d-FDQ9S12ZhUtI=.2ae7ac74-4b78-4c4a-9a62-bb0f84ea0dd6@github.com>

On Tue, 7 May 2024 19:46:18 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Please review this PR which introduces the `java.io.IO` top-level class and three methods to `java.io.Console` for [Implicitly Declared Classes and Instance Main Methods (Third Preview)].
>> 
>> This PR has been obtained as `git merge --squash` of a now obsolete [draft PR].
>> 
>> [Implicitly Declared Classes and Instance Main Methods (Third Preview)]: https://bugs.openjdk.org/browse/JDK-8323335
>> [draft PR]: https://github.com/openjdk/jdk/pull/18921
>
> Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Strengthen tests after 8330998
>   
>   https://github.com/openjdk/jdk/pull/18996 now allows us to test
>   Console IO better.

src/java.base/share/classes/java/io/IO.java line 51:

> 49:      * console, terminates the line and then flushes that console.
> 50:      *
> 51:      * If {@code System.console()} returns {@code null}, throws {@code IOError}.

Unlike, `java.io.Console` whose existing methods already throw `IOError`, should these new methods on `java.io.IO` instead throw `java.io.UncheckedIOException` instead of throwing `Error`s?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19112#discussion_r1593424569

From alanb at openjdk.org  Wed May  8 06:11:57 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 8 May 2024 06:11:57 GMT
Subject: RFR: 8330005: RandomGeneratorFactory.getDefault() throws exception
 when the runtime image only has java.base module [v6]
In-Reply-To: <ZCknDWh6FaLWfXb9c9QFsnK9GrqdTXaHSVcG5jmZ6g8=.c1dd43f6-c571-46e8-880f-7f864fc56b62@github.com>
References: <FymnGzlEZUHwHgW6At_bqYIoF7wYsjD_vBhk60PrwFE=.1ef4072e-c3a4-4930-8d18-ba132fa90c56@github.com>
 <ZCknDWh6FaLWfXb9c9QFsnK9GrqdTXaHSVcG5jmZ6g8=.c1dd43f6-c571-46e8-880f-7f864fc56b62@github.com>
Message-ID: <dcD0eAD__JOmi0fpYQ7gkaOys6Tz6-l1gEI6ILO6fLA=.595e12d9-dbea-4a7b-982e-2d81da8a8724@github.com>

On Sat, 4 May 2024 18:29:25 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> Move all random generators mandated in package `java.util.random` and currently implemented in module `jdk.random` to module `java.base`, and remove module `jdk.random`.
>
> Raffaello Giulietti 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 seven additional commits since the last revision:
> 
>  - Merge branch 'master' into 8330005
>  - Restrict RandomGenerator service providers to those loadable by the platform class loader.
>  - Typo.
>  - Added @uses javadoc tag for j.u.r.RandomGenerator in java.base.
>  - Terminology changes.
>  - Renamed package jdk.random to jdk.internal.random.
>  - 8330005: RandomGeneratorFactory.getDefault() throws exception when the runtime image only has java.base module

Marked as reviewed by alanb (Reviewer).

src/java.base/share/classes/module-info.java line 426:

> 424:         java.util.Random,
> 425:         java.util.SplittableRandom,
> 426: 

Can you remove this blank files, otherwise the list of service types for this provide declaration are all together?

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

PR Review: https://git.openjdk.org/jdk/pull/18932#pullrequestreview-2044707607
PR Review Comment: https://git.openjdk.org/jdk/pull/18932#discussion_r1593435059

From alanb at openjdk.org  Wed May  8 06:14:52 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 8 May 2024 06:14:52 GMT
Subject: RFR: 8330005: RandomGeneratorFactory.getDefault() throws exception
 when the runtime image only has java.base module [v6]
In-Reply-To: <c9eK7ZcrAvF7Ag65YvmbbTOMg7ClS5pkFY1vvFt285Q=.286b2b6f-27b9-4619-8a03-5532477c7e64@github.com>
References: <FymnGzlEZUHwHgW6At_bqYIoF7wYsjD_vBhk60PrwFE=.1ef4072e-c3a4-4930-8d18-ba132fa90c56@github.com>
 <ZCknDWh6FaLWfXb9c9QFsnK9GrqdTXaHSVcG5jmZ6g8=.c1dd43f6-c571-46e8-880f-7f864fc56b62@github.com>
 <c9eK7ZcrAvF7Ag65YvmbbTOMg7ClS5pkFY1vvFt285Q=.286b2b6f-27b9-4619-8a03-5532477c7e64@github.com>
Message-ID: <D9qyttjiTa5vb2mksOB45uzJ68BNQvOpbRUwWVIq0Ng=.90ecfdbd-6d1e-4178-8b42-32db6216757e@github.com>

On Wed, 8 May 2024 05:29:03 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Hello Raffaello, the proposed changes look OK to me. Do you think we should add a jtreg test for this?
> 
> In general, the test coverage for these APIs appears to be missing. I think that can be addressed separately in some of the upcoming changes.

RandomTestCoverage should be testing these APIs but if there are gaps then it would be good to add more tests (separate PR of course).  There is a second update coming once this PR is integrated, that will change the implementation to maybe not use SL.

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

PR Comment: https://git.openjdk.org/jdk/pull/18932#issuecomment-2099815847

From jpai at openjdk.org  Wed May  8 06:33:00 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 8 May 2024 06:33:00 GMT
Subject: RFR: 8330005: RandomGeneratorFactory.getDefault() throws exception
 when the runtime image only has java.base module [v6]
In-Reply-To: <ZCknDWh6FaLWfXb9c9QFsnK9GrqdTXaHSVcG5jmZ6g8=.c1dd43f6-c571-46e8-880f-7f864fc56b62@github.com>
References: <FymnGzlEZUHwHgW6At_bqYIoF7wYsjD_vBhk60PrwFE=.1ef4072e-c3a4-4930-8d18-ba132fa90c56@github.com>
 <ZCknDWh6FaLWfXb9c9QFsnK9GrqdTXaHSVcG5jmZ6g8=.c1dd43f6-c571-46e8-880f-7f864fc56b62@github.com>
Message-ID: <QT76Go9XtWRNLiS-Ww7ULQiFW2OLiIYg0iYKnLeZRf4=.19bf3c7d-6ce7-4dd4-899e-904d81f1f493@github.com>

On Sat, 4 May 2024 18:29:25 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> Move all random generators mandated in package `java.util.random` and currently implemented in module `jdk.random` to module `java.base`, and remove module `jdk.random`.
>
> Raffaello Giulietti 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 seven additional commits since the last revision:
> 
>  - Merge branch 'master' into 8330005
>  - Restrict RandomGenerator service providers to those loadable by the platform class loader.
>  - Typo.
>  - Added @uses javadoc tag for j.u.r.RandomGenerator in java.base.
>  - Terminology changes.
>  - Renamed package jdk.random to jdk.internal.random.
>  - 8330005: RandomGeneratorFactory.getDefault() throws exception when the runtime image only has java.base module

Hello Alan,

> RandomTestCoverage should be testing these APIs but if there are gaps then it would be good to add more tests (separate PR of course)

I missed that test case. It does appear to cover most of these APIs on `RandomGeneratorFactory`. There's a method in that test which even calls `RandomGeneratorFactory.getDefault()` but that doesn't seem to be exercised.

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

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18932#pullrequestreview-2044738539

From alanb at openjdk.org  Wed May  8 06:35:53 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 8 May 2024 06:35:53 GMT
Subject: RFR: 8330542: Add two JAXP configuration files in preparation for
 a secure by default configuration [v6]
In-Reply-To: <EPpleChHksHT2g_WYiIpLkUd8P8bhrCQ8u1pMCGWiGA=.facdce75-f0c2-4376-b30e-587e05785899@github.com>
References: <v1bAYKgH9zfooXpvnBw4Vu2TIqHuKqqtSmgB0hiNp-Q=.31661a99-ecfc-4a05-8045-67b5f680db60@github.com>
 <EPpleChHksHT2g_WYiIpLkUd8P8bhrCQ8u1pMCGWiGA=.facdce75-f0c2-4376-b30e-587e05785899@github.com>
Message-ID: <5Xv9S1imQGNJf6FqU2PfPPSHbDotskoODMB39bGYNNE=.4c5c7f60-2676-4773-9ea5-ca568b27ec72@github.com>

On Wed, 1 May 2024 22:33:29 GMT, Joe Wang <joehw at openjdk.org> wrote:

>> Add two sample configuration files:
>> 
>>   jaxp-strict.properties: used to set strict configuration, stricter than jaxp.properties in previous versions such as JDK 22
>> 
>>   jaxp-compat.properties: used to regain compatibility from any more restricted configuration than previous versions such as JDK 22
>
> Joe Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add implNote to java.xml module summary; Update make file; Update the config files; Add test.

Adding jaxp-strict.properties make sense as it allows developers to identify issues that will arise in the future when XML processing is secure by default. If they deploy with -Djava.xml.config.file=jaxp-strict.properties, and jaxp-strict.properties is removed as part of moving to secure by default, then it should be okay too as the defaults will be strict.

I'm less sure about including jaxp-compat.properties in JDK 23. That's the config file to get temporary relief while you work through the issues with existing code or deployments that break when XML processing is secure by default. Adding in the JDK 23 sends the message that you can "prepare" your command line in advance, which I don't think should be a goal here.

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

PR Comment: https://git.openjdk.org/jdk/pull/18831#issuecomment-2099840683

From rgiulietti at openjdk.org  Wed May  8 08:30:39 2024
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Wed, 8 May 2024 08:30:39 GMT
Subject: RFR: 8330005: RandomGeneratorFactory.getDefault() throws exception
 when the runtime image only has java.base module [v7]
In-Reply-To: <FymnGzlEZUHwHgW6At_bqYIoF7wYsjD_vBhk60PrwFE=.1ef4072e-c3a4-4930-8d18-ba132fa90c56@github.com>
References: <FymnGzlEZUHwHgW6At_bqYIoF7wYsjD_vBhk60PrwFE=.1ef4072e-c3a4-4930-8d18-ba132fa90c56@github.com>
Message-ID: <QN5C-_MG63Ku6hMtJQICTli-RVC9RxS6CWdw1iX67FM=.70337c4c-f3f6-4724-aa8a-6fa9030bc972@github.com>

> Move all random generators mandated in package `java.util.random` and currently implemented in module `jdk.random` to module `java.base`, and remove module `jdk.random`.

Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:

  Removed empty line.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18932/files
  - new: https://git.openjdk.org/jdk/pull/18932/files/8a5598ea..d2bdf337

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

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

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

From rgiulietti at openjdk.org  Wed May  8 08:30:40 2024
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Wed, 8 May 2024 08:30:40 GMT
Subject: Integrated: 8330005: RandomGeneratorFactory.getDefault() throws
 exception when the runtime image only has java.base module
In-Reply-To: <FymnGzlEZUHwHgW6At_bqYIoF7wYsjD_vBhk60PrwFE=.1ef4072e-c3a4-4930-8d18-ba132fa90c56@github.com>
References: <FymnGzlEZUHwHgW6At_bqYIoF7wYsjD_vBhk60PrwFE=.1ef4072e-c3a4-4930-8d18-ba132fa90c56@github.com>
Message-ID: <AmeiOiIiMEx_KGftOIzggf3H-AVGtDOZXYSjgLX-kRM=.2dd83bbe-cb8c-4f6a-bde0-14ae76e9120e@github.com>

On Wed, 24 Apr 2024 13:50:56 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

> Move all random generators mandated in package `java.util.random` and currently implemented in module `jdk.random` to module `java.base`, and remove module `jdk.random`.

This pull request has now been integrated.

Changeset: 7f299043
Author:    Raffaello Giulietti <rgiulietti at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/7f299043a99406dbd666d4f7f30445d26f3eae82
Stats:     115 lines in 14 files changed: 11 ins; 77 del; 27 mod

8330005: RandomGeneratorFactory.getDefault() throws exception when the runtime image only has java.base module

Reviewed-by: jpai, alanb

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

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

From djelinski at openjdk.org  Wed May  8 08:32:22 2024
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Wed, 8 May 2024 08:32:22 GMT
Subject: RFR: 8331907: BigInteger and BigDecimal should use optimized division
Message-ID: <-U6_9J-If3E3P3j4y7kt2yTCdNLvKkTSPrK0FxhNM80=.07321109-402b-4d28-9788-ddd52f42467d@github.com>

Replace the custom unsigned divide / remainder functions with the compiler-optimized Long.divideUnsigned / remainderUnsigned.

No new tests. Existing tier1-3 tests continue to pass.

I added a new set of divide benchmarks. Results in thread.

I also removed the BigDecimal.toString benchmarks. They no longer serve their purpose - toString caches the returned value, so we were only benchmarking the cache access time.

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

Commit messages:
 - Fix whitespace
 - Remove useless toString benchmarks
 - Update copyright
 - Remove redundant benchmarks
 - Use unsigned ops in BigDecimal
 - Simplify logic
 - Use divide/remainderUnsigned
 - Add BigInteger.divide microbenchmark

Changes: https://git.openjdk.org/jdk/pull/19134/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19134&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8331907
  Stats: 212 lines in 4 files changed: 39 ins; 132 del; 41 mod
  Patch: https://git.openjdk.org/jdk/pull/19134.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19134/head:pull/19134

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

From djelinski at openjdk.org  Wed May  8 08:32:22 2024
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Wed, 8 May 2024 08:32:22 GMT
Subject: RFR: 8331907: BigInteger and BigDecimal should use optimized
 division
In-Reply-To: <-U6_9J-If3E3P3j4y7kt2yTCdNLvKkTSPrK0FxhNM80=.07321109-402b-4d28-9788-ddd52f42467d@github.com>
References: <-U6_9J-If3E3P3j4y7kt2yTCdNLvKkTSPrK0FxhNM80=.07321109-402b-4d28-9788-ddd52f42467d@github.com>
Message-ID: <5mFhYB7yGa1pgwtRiOwUEkuf_neG51cfZAhk-hRVAWM=.c0188fe1-45fb-4f7c-8c2e-ac0f416d8ee1@github.com>

On Wed, 8 May 2024 08:19:54 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> Replace the custom unsigned divide / remainder functions with the compiler-optimized Long.divideUnsigned / remainderUnsigned.
> 
> No new tests. Existing tier1-3 tests continue to pass.
> 
> I added a new set of divide benchmarks. Results in thread.
> 
> I also removed the BigDecimal.toString benchmarks. They no longer serve their purpose - toString caches the returned value, so we were only benchmarking the cache access time.

Results before:

Benchmark                                   Mode  Cnt    Score   Error  Units
BigDecimals.testHugeLargeDivide             avgt   15  115.176 ? 0.965  ns/op
BigDecimals.testHugeSmallDivide             avgt   15   82.652 ? 0.601  ns/op
BigDecimals.testLargeSmallDivide            avgt   15    6.601 ? 0.320  ns/op
BigIntegers.testHugeLargeDivide             avgt   15   53.905 ? 0.734  ns/op
BigIntegers.testHugeSmallDivide             avgt   15   52.762 ? 0.354  ns/op
BigIntegers.testLargeSmallDivide            avgt   15   22.990 ? 0.058  ns/op

after:

Benchmark                                   Mode  Cnt    Score   Error  Units
BigDecimals.testHugeLargeDivide             avgt   15  106.549 ? 0.695  ns/op
BigDecimals.testHugeSmallDivide             avgt   15   68.339 ? 0.172  ns/op
BigDecimals.testLargeSmallDivide            avgt   15    6.594 ? 0.328  ns/op
BigIntegers.testHugeLargeDivide             avgt   15   29.576 ? 0.411  ns/op
BigIntegers.testHugeSmallDivide             avgt   15   30.072 ? 0.242  ns/op
BigIntegers.testLargeSmallDivide            avgt   15    8.034 ? 0.078  ns/op

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

PR Comment: https://git.openjdk.org/jdk/pull/19134#issuecomment-2100030115

From alanb at openjdk.org  Wed May  8 08:37:59 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 8 May 2024 08:37:59 GMT
Subject: RFR: 8314480: Memory ordering spec updates in java.lang.ref [v10]
In-Reply-To: <hJ1gdvXaaead1N3EAECaT6SBY-XvRHEKM0S4XeWpfLY=.ad0c3816-b9a7-4bfe-bfa9-a811e5d18056@github.com>
References: <R74ontYwjYg6HeZY0cWrlo0amjl4E1YsFWeuh4pda14=.08ac62df-b2f8-4b4d-b338-07adb289601b@github.com>
 <hJ1gdvXaaead1N3EAECaT6SBY-XvRHEKM0S4XeWpfLY=.ad0c3816-b9a7-4bfe-bfa9-a811e5d18056@github.com>
Message-ID: <A1XrAasxRIaEJqy-nvQ-p0rjh_CJMdT1F1xk5U6KUBM=.432d92d9-5196-4c4b-b8ad-f8e839a1ae14@github.com>

On Fri, 23 Feb 2024 06:06:21 GMT, Brent Christian <bchristi at openjdk.org> wrote:

>> Classes in the `java.lang.ref` package would benefit from an update to bring the spec in line with how the VM already behaves. The changes would focus on _happens-before_ edges at some key points during reference processing.
>> 
>> A couple key things we want to be able to say are:
>> - `Reference.reachabilityFence(x)` _happens-before_ reference processing occurs for 'x'.
>> - `Cleaner.register()` _happens-before_ the Cleaner thread runs the registered cleaning action.
>> 
>> This will bring Cleaner in line (or close) with the memory visibility guarantees made for finalizers in [JLS 17.4.5](https://docs.oracle.com/javase/specs/jls/se18/html/jls-17.html#jls-17.4.5):
>> _"There is a happens-before edge from the end of a constructor of an object to the start of a finalizer (?12.6) for that object."_
>
> Brent Christian has updated the pull request incrementally with one additional commit since the last revision:
> 
>   VM -> virtual machine; also fix misspelling

src/java.base/share/classes/java/lang/ref/Cleaner.java line 218:

> 216:      * cautions about the behavior of cleaning actions.
> 217:      *
> 218:      * <p>The object being registered is kept strongly reachable (and therefore not eligible

I would be tempted to drop "being registered" from this sentence. The previous paragraph and the parameter descriptions use "the object". That would make it "The given object is  kept strongly reachable ..." which I think is a bit easier to read.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16644#discussion_r1500757065

From alanb at openjdk.org  Wed May  8 08:38:01 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 8 May 2024 08:38:01 GMT
Subject: RFR: 8314480: Memory ordering spec updates in java.lang.ref [v29]
In-Reply-To: <88uucCyrO2W6frWuhxgcWtRcffZChQ8zvGO5H7OOCEU=.ffbf7203-1cde-4232-960c-84bd5d95cfe0@github.com>
References: <R74ontYwjYg6HeZY0cWrlo0amjl4E1YsFWeuh4pda14=.08ac62df-b2f8-4b4d-b338-07adb289601b@github.com>
 <88uucCyrO2W6frWuhxgcWtRcffZChQ8zvGO5H7OOCEU=.ffbf7203-1cde-4232-960c-84bd5d95cfe0@github.com>
Message-ID: <LgPqtQ7ltUxg763QcN0mDJ3hCsykX0dSjl7TaJsKo84=.1eb81b77-4c90-4a6e-9b87-3b3002c8a0fa@github.com>

On Mon, 29 Apr 2024 21:17:24 GMT, Brent Christian <bchristi at openjdk.org> wrote:

>> Classes in the `java.lang.ref` package would benefit from an update to bring the spec in line with how the VM already behaves. The changes would focus on _happens-before_ edges at some key points during reference processing.
>> 
>> A couple key things we want to be able to say are:
>> - `Reference.reachabilityFence(x)` _happens-before_ reference processing occurs for 'x'.
>> - `Cleaner.register()` _happens-before_ the Cleaner thread runs the registered cleaning action.
>> 
>> This will bring Cleaner in line (or close) with the memory visibility guarantees made for finalizers in [JLS 17.4.5](https://docs.oracle.com/javase/specs/jls/se18/html/jls-17.html#jls-17.4.5):
>> _"There is a happens-before edge from the end of a constructor of an object to the start of a finalizer (?12.6) for that object."_
>
> Brent Christian has updated the pull request incrementally with one additional commit since the last revision:
> 
>   small grammar fixes

src/java.base/share/classes/java/lang/ref/Cleaner.java line 224:

> 222:      * Actions in a thread prior to calling {@code Cleaner.register()}
> 223:      * <a href="{@docRoot}/java.base/java/util/concurrent/package-summary.html#MemoryVisibility"><i>happen-before</i></a>
> 224:      * the cleaning action is run by the Cleaner's thread.

In passing, you could reduces the html refs to "package-summary.html#MemoryConsistency" and "package-summary.html#MemoryVisibility" as it's the same package/directory.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16644#discussion_r1593641111

From alanb at openjdk.org  Wed May  8 08:38:02 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 8 May 2024 08:38:02 GMT
Subject: RFR: 8314480: Memory ordering spec updates in java.lang.ref [v13]
In-Reply-To: <FVPuSm37omAgd6FwaSUkPBfMuPUd4fj41VEler9y81g=.fe3b5fec-b25d-46d3-9639-cd93c40e339a@github.com>
References: <R74ontYwjYg6HeZY0cWrlo0amjl4E1YsFWeuh4pda14=.08ac62df-b2f8-4b4d-b338-07adb289601b@github.com>
 <I4L7-Ak61dK3uo6Iptb0uHMbfTj2J4YFtc9J31NoKB0=.12da6fa4-3147-4174-bf33-f5df29e85bb5@github.com>
 <FVPuSm37omAgd6FwaSUkPBfMuPUd4fj41VEler9y81g=.fe3b5fec-b25d-46d3-9639-cd93c40e339a@github.com>
Message-ID: <utUkXxuDTUg0kRpLCAUSbU9Ki8jU3ZyaP52ipbsMd2Q=.03c3d50a-bf4b-405a-ad15-65a2d06302c7@github.com>

On Tue, 19 Mar 2024 00:40:02 GMT, Y. Srinivas Ramakrishna <ysr at openjdk.org> wrote:

>> Brent Christian has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   further tweaks to reachability
>
> src/java.base/share/classes/java/lang/ref/package-info.java line 137:
> 
>> 135:  *
>> 136:  * A <em>reachable</em> object is any object that can be accessed in any potential
>> 137:  * continuing computation from any live thread (as stated in {@jls 12.6.1}).
> 
> This seems like somewhat loose and sloppy wording to me. "Any potential continuing computation"? "Any live thread"? Could you share a pointer to JLS 12.6.1 being referenced here?

The phrase "live thread" is used in a number of places in the API docs to mean a Thread that has been started and not has not terminated. The `@jls` tag will create a link in the generated javadoc. If it helps, then it could also link to Thread::isAlive.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16644#discussion_r1529527453

From alanb at openjdk.org  Wed May  8 08:44:01 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 8 May 2024 08:44:01 GMT
Subject: RFR: 8314480: Memory ordering spec updates in java.lang.ref [v29]
In-Reply-To: <88uucCyrO2W6frWuhxgcWtRcffZChQ8zvGO5H7OOCEU=.ffbf7203-1cde-4232-960c-84bd5d95cfe0@github.com>
References: <R74ontYwjYg6HeZY0cWrlo0amjl4E1YsFWeuh4pda14=.08ac62df-b2f8-4b4d-b338-07adb289601b@github.com>
 <88uucCyrO2W6frWuhxgcWtRcffZChQ8zvGO5H7OOCEU=.ffbf7203-1cde-4232-960c-84bd5d95cfe0@github.com>
Message-ID: <fDDHt22nIdqeS4IjNPOMu3wjqJc5QTNgHvIgQ_QyZxc=.8994a35c-0130-49e2-92f6-81234a910d1a@github.com>

On Mon, 29 Apr 2024 21:17:24 GMT, Brent Christian <bchristi at openjdk.org> wrote:

>> Classes in the `java.lang.ref` package would benefit from an update to bring the spec in line with how the VM already behaves. The changes would focus on _happens-before_ edges at some key points during reference processing.
>> 
>> A couple key things we want to be able to say are:
>> - `Reference.reachabilityFence(x)` _happens-before_ reference processing occurs for 'x'.
>> - `Cleaner.register()` _happens-before_ the Cleaner thread runs the registered cleaning action.
>> 
>> This will bring Cleaner in line (or close) with the memory visibility guarantees made for finalizers in [JLS 17.4.5](https://docs.oracle.com/javase/specs/jls/se18/html/jls-17.html#jls-17.4.5):
>> _"There is a happens-before edge from the end of a constructor of an object to the start of a finalizer (?12.6) for that object."_
>
> Brent Christian has updated the pull request incrementally with one additional commit since the last revision:
> 
>   small grammar fixes

src/java.base/share/classes/java/lang/ref/Reference.java line 393:

> 391:      * Clears this reference object. Invoking this method does not enqueue this
> 392:      * object, and the garbage collector will no longer clear or enqueue this
> 393:      * object.

"will no longer clear" means that it won't do it again, if you see what I mean. I think this would be easier to read if changed to "will not clear ...".

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16644#discussion_r1593651535

From alanb at openjdk.org  Wed May  8 08:49:01 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 8 May 2024 08:49:01 GMT
Subject: RFR: 8314480: Memory ordering spec updates in java.lang.ref [v29]
In-Reply-To: <88uucCyrO2W6frWuhxgcWtRcffZChQ8zvGO5H7OOCEU=.ffbf7203-1cde-4232-960c-84bd5d95cfe0@github.com>
References: <R74ontYwjYg6HeZY0cWrlo0amjl4E1YsFWeuh4pda14=.08ac62df-b2f8-4b4d-b338-07adb289601b@github.com>
 <88uucCyrO2W6frWuhxgcWtRcffZChQ8zvGO5H7OOCEU=.ffbf7203-1cde-4232-960c-84bd5d95cfe0@github.com>
Message-ID: <7jzr99rCgIR1kL2PogELR9czDi7ZVcuubPcYEPH7W0o=.d269b515-2eab-461d-bfb2-7576436bca0d@github.com>

On Mon, 29 Apr 2024 21:17:24 GMT, Brent Christian <bchristi at openjdk.org> wrote:

>> Classes in the `java.lang.ref` package would benefit from an update to bring the spec in line with how the VM already behaves. The changes would focus on _happens-before_ edges at some key points during reference processing.
>> 
>> A couple key things we want to be able to say are:
>> - `Reference.reachabilityFence(x)` _happens-before_ reference processing occurs for 'x'.
>> - `Cleaner.register()` _happens-before_ the Cleaner thread runs the registered cleaning action.
>> 
>> This will bring Cleaner in line (or close) with the memory visibility guarantees made for finalizers in [JLS 17.4.5](https://docs.oracle.com/javase/specs/jls/se18/html/jls-17.html#jls-17.4.5):
>> _"There is a happens-before edge from the end of a constructor of an object to the start of a finalizer (?12.6) for that object."_
>
> Brent Christian has updated the pull request incrementally with one additional commit since the last revision:
> 
>   small grammar fixes

src/java.base/share/classes/java/lang/ref/ReferenceQueue.java line 39:

> 37:  *
> 38:  * <p><a href="{@docRoot}/java.base/java/lang/ref/package-summary.html#MemoryConsistency">Memory consistency effects</a>:
> 39:  * The enqueueing of a reference on a queue (by the garbage collector, or by a

In passing, I wonder if you're actually meant to say "on a queue" here.  Elsewhere the API docs speak of adding and removing, e.g. the enqueue method speaks of adding a reference "to" the queue.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16644#discussion_r1593659540

From prappo at openjdk.org  Wed May  8 09:03:54 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Wed, 8 May 2024 09:03:54 GMT
Subject: RFR: 8305457: Implement java.io.IO [v3]
In-Reply-To: <C1Pvc8KO7vUGELLaqcXpepoK_MpvChaDcZqfroVICo0=.5ab8bef5-fa21-4618-a903-219d733045a0@github.com>
References: <w2msiw_qaMEIJS3s9D4bg8pFbz5WIF0KdP6Mm-XFjLI=.85b2020b-8c46-4bac-8a69-4975b068f2ff@github.com>
 <wpwFGOp8E00csxi2Xb9b-02ZlkqnIZEpo8AqaMsQ4AM=.90acb47b-effc-4838-ba80-28938d4dc3c0@github.com>
 <C1Pvc8KO7vUGELLaqcXpepoK_MpvChaDcZqfroVICo0=.5ab8bef5-fa21-4618-a903-219d733045a0@github.com>
Message-ID: <jWOXcC9B_23P_Px2zulnzRc38zL7zkslJM9nRtauHlk=.55e2ed38-59b7-4df1-be13-5d9a74672e26@github.com>

On Wed, 8 May 2024 05:41:52 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Strengthen tests after 8330998
>>   
>>   https://github.com/openjdk/jdk/pull/18996 now allows us to test
>>   Console IO better.
>
> src/java.base/share/classes/java/io/Console.java line 188:
> 
>> 186: 
>> 187:     /**
>> 188:      * Writes a prompt as if by calling {@code print}, then reads a single line
> 
> Should `{@code print}` instead be `{@link Console#print() print()}`?

It could be done like that, but given that it's the same class (and the same HTML page), I'd skip it.

> src/java.base/share/classes/java/io/Console.java line 192:
> 
>> 190:      *
>> 191:      * @param  prompt
>> 192:      *         A prompt string.
> 
> Hello Pavel, should this specify whether `prompt`  can be null?

If we specify that, it would be very much unlike all other `Console` methods that are covered by this:

    * Unless otherwise specified, passing a {@code null} argument to any method
    * in this class will cause a {@link NullPointerException} to be thrown.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19112#discussion_r1593687355
PR Review Comment: https://git.openjdk.org/jdk/pull/19112#discussion_r1593684673

From prappo at openjdk.org  Wed May  8 09:18:56 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Wed, 8 May 2024 09:18:56 GMT
Subject: RFR: 8305457: Implement java.io.IO [v3]
In-Reply-To: <gDowRhUuCc_bTGTQbQXb7Q7CffLt2d-FDQ9S12ZhUtI=.2ae7ac74-4b78-4c4a-9a62-bb0f84ea0dd6@github.com>
References: <w2msiw_qaMEIJS3s9D4bg8pFbz5WIF0KdP6Mm-XFjLI=.85b2020b-8c46-4bac-8a69-4975b068f2ff@github.com>
 <wpwFGOp8E00csxi2Xb9b-02ZlkqnIZEpo8AqaMsQ4AM=.90acb47b-effc-4838-ba80-28938d4dc3c0@github.com>
 <gDowRhUuCc_bTGTQbQXb7Q7CffLt2d-FDQ9S12ZhUtI=.2ae7ac74-4b78-4c4a-9a62-bb0f84ea0dd6@github.com>
Message-ID: <8W3Rbf8KHYoe3Ny1UkmvLAiucRV6_SXMTa0aaxNwP9Y=.3e7982cb-bd18-4b7c-9ac2-21d3eec746c5@github.com>

On Wed, 8 May 2024 05:59:14 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Strengthen tests after 8330998
>>   
>>   https://github.com/openjdk/jdk/pull/18996 now allows us to test
>>   Console IO better.
>
> src/java.base/share/classes/java/io/IO.java line 51:
> 
>> 49:      * console, terminates the line and then flushes that console.
>> 50:      *
>> 51:      * If {@code System.console()} returns {@code null}, throws {@code IOError}.
> 
> Unlike, `java.io.Console` whose existing methods already throw `IOError`, should these new methods on `java.io.IO` instead throw `java.io.UncheckedIOException` instead of throwing `Error`s?

As a result of several offline discussions, it was decided to throw `IOError` to better align with `java.io.Console`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19112#discussion_r1593711476

From sgehwolf at openjdk.org  Wed May  8 09:32:05 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Wed, 8 May 2024 09:32:05 GMT
Subject: RFR: 8311302: Allow for jlinking a custom runtime without packaged
 modules being present [v26]
In-Reply-To: <RUr5xr-pzsccK28vRBO-GhY-8RltknEX2lyMgWpijnA=.980d0b9d-f219-4bc7-bf64-4e343f44ac7d@github.com>
References: <Z0DJ87uKPbjS6mvJIE_oG5m-RWsbERXsytSgV8Bmhdo=.f8723513-0ac6-4e85-9131-3c3924860c61@github.com>
 <RUr5xr-pzsccK28vRBO-GhY-8RltknEX2lyMgWpijnA=.980d0b9d-f219-4bc7-bf64-4e343f44ac7d@github.com>
Message-ID: <FEU8eTKbVVSfHaftF0bJy2CofSxHgvBkTSn1iLHpyUg=.e0e781af-194c-4db0-a016-cd06604fdae1@github.com>

On Tue, 7 May 2024 16:52:12 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> Please review this patch which adds a jlink mode to the JDK which doesn't need the packaged modules being present. A.k.a run-time image based jlink. Fundamentally this patch adds an option to use `jlink` even though your JDK install might not come with the packaged modules (directory `jmods`). This is particularly useful to further reduce the size of a jlinked runtime. After the removal of the concept of a JRE, a common distribution mechanism is still the full JDK with all modules and packaged modules. However, packaged modules can incur an additional size tax. For example in a container scenario it could be useful to have a base JDK container including all modules, but without also delivering the packaged modules. This comes at a size advantage of `~25%`. Such a base JDK container could then be used to `jlink` application specific runtimes, further reducing the size of the application runtime image (App + JDK runtime; as a single image *or* separate bundles, depending on the app 
 being modularized).
>> 
>> The basic design of this approach is to add a jlink plugin for tracking non-class and non-resource files of a JDK install. I.e. files which aren't present in the jimage (`lib/modules`). This enables producing a `JRTArchive` class which has all the info of what constitutes the final jlinked runtime.
>> 
>> Basic usage example:
>> 
>> $ diff -u <(./bin/java --list-modules --limit-modules java.se) <(../linux-x86_64-server-release/images/jdk/bin/java --list-modules --limit-modules java.se)
>> $ diff -u <(./bin/java --list-modules --limit-modules jdk.jlink) <(../linux-x86_64-server-release/images/jdk/bin/java --list-modules --limit-modules jdk.jlink)
>> $ ls ../linux-x86_64-server-release/images/jdk/jmods
>> java.base.jmod            java.net.http.jmod       java.sql.rowset.jmod      jdk.crypto.ec.jmod         jdk.internal.opt.jmod                     jdk.jdi.jmod         jdk.management.agent.jmod  jdk.security.auth.jmod
>> java.compiler.jmod        java.prefs.jmod          java.transaction.xa.jmod  jdk.dynalink.jmod          jdk.internal.vm.ci.jmod                   jdk.jdwp.agent.jmod  jdk.management.jfr.jmod    jdk.security.jgss.jmod
>> java.datatransfer.jmod    java.rmi.jmod            java.xml.crypto.jmod      jdk.editpad.jmod           jdk.internal.vm.compiler.jmod             jdk.jfr.jmod         jdk.management.jmod        jdk.unsupported.desktop.jmod
>> java.desktop.jmod         java.scripting.jmod      java.xml.jmod             jdk.hotspot.agent.jmod     jdk.i...
>
> Severin Gehwolf has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 105 commits:
> 
>  - Generate the runtime image link diff at jlink time
>    
>    But only do that once the plugin-pipeline has run. The generation is
>    enabled with the hidden option '--generate-linkable-runtime' and
>    the resource pools available at jlink time are being used to generate
>    the diff.
>  - Merge branch 'master' into jdk-8311302-jmodless-link
>  - Use shorter name for the build tool
>  - Review feedback from Erik J.
>  - Remove dependency on CDS which isn't needed anymore
>  - Fix coment
>  - Fix comment
>  - Fix typo
>  - Revert some now unneded build changes
>  - Follow build tools naming convention
>  - ... and 95 more: https://git.openjdk.org/jdk/compare/23a72a1f...67aea4ca

GHA test failures [gc/shenandoah/oom/TestThreadFailure](https://github.com/jerboaa/jdk/actions/runs/8989206765#user-content-gc_shenandoah_oom_testthreadfailure) on Mac x86_64 and [java/util/zip/ZipFile/ZipSourceCache](https://github.com/jerboaa/jdk/actions/runs/8989206765#user-content-java_util_zip_zipfile_zipsourcecache) on Windows x86_64 seem unrelated to this patch.

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

PR Comment: https://git.openjdk.org/jdk/pull/14787#issuecomment-2100159861

From alanb at openjdk.org  Wed May  8 09:38:56 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 8 May 2024 09:38:56 GMT
Subject: RFR: 8329653: JLILaunchTest fails on AIX after JDK-8329131 [v3]
In-Reply-To: <D3ZEVmfJIpjMyN7u9tLewNo0N5xuIQWGeFiBgnvdxsM=.1859ec49-d2ef-4c45-8008-24f48313d231@github.com>
References: <y9wItIb8Yr_ZrHfN_kV5lDCp-d-VtYam3MuHX1OxurU=.ce3378d2-90b3-4396-8951-4651439e4f90@github.com>
 <D3ZEVmfJIpjMyN7u9tLewNo0N5xuIQWGeFiBgnvdxsM=.1859ec49-d2ef-4c45-8008-24f48313d231@github.com>
Message-ID: <pPwaLQHlInMs4EsPKmQWGMSr3ebKuoJZK5c7Yq2aegU=.ba291ac5-01aa-4080-b8af-c5409e57b702@github.com>

On Tue, 7 May 2024 08:08:05 GMT, Joachim Kern <jkern at openjdk.org> wrote:

>> Since ~ end of March, after [JDK-8329131](https://bugs.openjdk.org/browse/JDK-8329131), tools/launcher/JliLaunchTest.java fails on AIX. Failure is :
>> 
>>  stdout: [];
>>  stderr: [Error: could not find libjava.so
>> Error: Could not find Java SE Runtime Environment.
>> ]
>>  exitValue = 2
>> 
>> java.lang.RuntimeException: Expected to get exit value of [0], exit value is: [2]
>> at jdk.test.lib.process.OutputAnalyzer.shouldHaveExitValue(OutputAnalyzer.java:521)
>> at JliLaunchTest.main(JliLaunchTest.java:58)
>> at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
>> at java.base/java.lang.reflect.Method.invoke(Method.java:580)
>> at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:333)
>> at java.base/java.lang.Thread.run(Thread.java:1575)
>> 
>> Maybe we need to do further adjustments to BUILD_JDK_JTREG_EXECUTABLES_LIBS_exeJliLaunchTest / BUILD_JDK_JTREG_EXECUTABLES_LDFLAGS_exeJliLaunchTest on AIX ?
>> Or somehow adjust the coding that attempts to find parts of "JRE" (libjava.so) ? The libjli.so is gone on AIX after [JDK-8329131](https://bugs.openjdk.org/browse/JDK-8329131), and with this also the image discovery based on GetApplicationHomeFromDll which uses libjli.so .
>> 
>> Without libjli.so we have to analyze the LD-LIBRARY_PATH / LIBPATH envvar. There is no other methos available on AIX, because it lacks the $ORIGIN feature of the rpath.
>
> Joachim Kern has updated the pull request incrementally with one additional commit since the last revision:
> 
>   cosmetic changes

Thanks for conditionally compiling this in with `#ifdef AIX ...`, that reduces the risk of changing behavior on other platforms. I don't have any other comments to add.

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

PR Comment: https://git.openjdk.org/jdk/pull/19000#issuecomment-2100171882

From stuefe at openjdk.org  Wed May  8 09:41:00 2024
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Wed, 8 May 2024 09:41:00 GMT
Subject: RFR: 8329581: Java launcher no longer prints a stack trace [v9]
In-Reply-To: <krgANOmUJpt38cg16YhdXnUibxgX4shajEyWnMF79Hc=.e2dba0cc-8085-4efd-a300-d9c7f771510b@github.com>
References: <Z0pDMIc_XvZhcZdeFsIQUlqI17q5ybj0BnQ9Kl3jwxg=.8f981c46-a8a3-4520-a6e3-79ee7fce0253@github.com>
 <krgANOmUJpt38cg16YhdXnUibxgX4shajEyWnMF79Hc=.e2dba0cc-8085-4efd-a300-d9c7f771510b@github.com>
Message-ID: <OSB-RYHDOcS3rbr3_rsRmDPO-GFps7FXT_LD_2M2PHM=.2c4dc9d2-f40f-45e1-98f8-3c0aa2fb9c67@github.com>

On Mon, 6 May 2024 19:06:10 GMT, Sonia Zaldana Calles <szaldana at openjdk.org> wrote:

>> Hi folks, 
>> 
>> This PR aims to fix [JDK-8329581](https://bugs.openjdk.org/browse/JDK-8329581). 
>> 
>> I think the regression got introduced in [JDK-8315458](https://bugs.openjdk.org/browse/JDK-8315458). 
>> 
>> In the issue linked above, [LauncherHelper#getMainType](https://github.com/openjdk/jdk/pull/16461/files#diff-108a3a3e3c2d108c8c7f19ea498f641413b7c9239ecd2975a6c27d904c2ba226) got removed to simplify launcher code.
>> 
>> Previously, we used ```getMainType``` to do the appropriate main method invocation in ```JavaMain```. However, we currently attempt to do all types of main method invocations at the same time [here](https://github.com/openjdk/jdk/blob/master/src/java.base/share/native/libjli/java.c#L623). 
>> 
>> Note how all of these invocations clear the exception reported with [CHECK_EXCEPTION_FAIL](https://github.com/openjdk/jdk/blob/140f56718bbbfc31bb0c39255c68568fad285a1f/src/java.base/share/native/libjli/java.c#L390). 
>> 
>> Therefore, if a legitimate exception comes up during one of these invocations, it does not get reported. 
>> 
>> I propose reintroducing ```LauncherHelper#getMainType``` but I'm looking forward to your suggestions. 
>> 
>> Cheers, 
>> Sonia
>
> Sonia Zaldana Calles has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixing indentation
>   
>   Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com>

Pre-existing: Man, I cannot grok the complex return code handling, tbh.

We have the local `ret` variable holding a return code. We also hand codes to CHECK_EXCEPTION_LEAVE as macro argument. But we don't hand codes to CHECK_EXCEPTION_NULL_LEAVE. LEAVE uses the locally defined `ret` instead of getting the return code as argument. CHECK_EXCEPTION_LEAVE modifies the local `ret`, but CHECK_EXCEPTION_NULL_LEAVE does not.

CHECK_EXCEPTION_NULL_LEAVE does not set `ret`. So, in case of an error, it would cause the launcher to return OK, but this does not happen because the local `ret` gets initialized to 1 before the first call to CHECK_EXCEPTION_NULL_LEAVE (line 566 resp. 560). Not sure if this was intentional, but it surely is very brittle. We rely on the content of `ret`, and that changes several times throughout JavaMain.

CHECK_EXCEPTION_NULL_LEAVE argument is named CENL_exception, which I don't understand.

To confuse matters more, the logic for internal error codes and the launcher return code is reversed: internally, 0 means error, and externally, 0 means success. And we only use numerical literals (`1`, `0`) instead of clearly named constants.

This may be food for another RFE, to keep this patch minimal. But a good solution, to me, would be like this:

- have the same logic for return codes (1 = error, 0 = success) to ease understanding
- have clearly named constants (e.g. "LAUNCHER_OK" 0, "LAUNCHER_ERR" = 1)
- have the LEAVE macro take the launcher return code as argument
- have all xxx_LEAVE macros pass in LAUNCHER_ERR to LEAVE
- call the final LEAVE with LAUNCHER_OK
- optionally, define something like "LEAVE_ERR" and "LEAVE_OK" that call LEAVE with either LAUNCHER_ERR or LAUNCHER_OK, for more concise coding.

For this patch, I think the return code logic is okay, but I would feel better if others double-checked.

src/java.base/share/native/libjli/java.c line 394:

> 392:         if ((*env)->ExceptionOccurred(env)) { \
> 393:             return 0; \
> 394:         } else if (obj == NULL) { \

Side note, I first wondered if this comparison is strictly correct, since we now pass in `jmethodID` as well as `jobject`, which are opaque types and not necessarily of the same size.

But seems that jmethodID==NULL is defined to mean "invalid" [1] by the spec. Requiring NULL instead of providing an opaque invalid constant feels like an odd choice in the original JNI spec, since it requires implementors to use a pointer type to implement jmethodID? Which we do, in OpenJDK [2].

[1] https://docs.oracle.com/en/java/javase/17/docs/specs/jni/functions.html#getstaticmethodid
[2] https://github.com/openjdk/jdk/blob/2baacfc16916220846743c6e49a99a6c41cac510/src/java.base/share/native/include/jni.h#L135-L136

src/java.base/share/native/libjli/java.c line 420:

> 418:     jmethodID mainID =
> 419:         (*env)->GetMethodID(env, mainClass, "main", "([Ljava/lang/String;)V");
> 420:     CHECK_EXCEPTION_NULL_FAIL(mainID);

Is there a particular reason why you moved this section up here, from line 432 before? If not, I'd restore it to its original position to keep the diff small.

src/java.base/share/native/libjli/java.c line 452:

> 450:     jobject mainObject = (*env)->NewObject(env, mainClass, constructor);
> 451:     CHECK_EXCEPTION_NULL_FAIL(mainObject);
> 452:     jmethodID mainID = (*env)->GetMethodID(env, mainClass, "main", "()V");

Unnecessary change. Please restore original linebreak to have a smaller diff.

src/java.base/share/native/libjli/java.c line 618:

> 616:      */
> 617: 
> 618: 

nit, please remove one line

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

PR Review: https://git.openjdk.org/jdk/pull/18786#pullrequestreview-2045014321
PR Review Comment: https://git.openjdk.org/jdk/pull/18786#discussion_r1593646409
PR Review Comment: https://git.openjdk.org/jdk/pull/18786#discussion_r1593649988
PR Review Comment: https://git.openjdk.org/jdk/pull/18786#discussion_r1593653226
PR Review Comment: https://git.openjdk.org/jdk/pull/18786#discussion_r1593653669

From prappo at openjdk.org  Wed May  8 09:41:58 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Wed, 8 May 2024 09:41:58 GMT
Subject: RFR: 8305457: Implement java.io.IO [v3]
In-Reply-To: <Z-0pp39dfPkKEtHlkyKtwKBlTI5dW8lnVl-MtJfuYNw=.034ab167-99ed-4fde-84cf-daca6998726f@github.com>
References: <w2msiw_qaMEIJS3s9D4bg8pFbz5WIF0KdP6Mm-XFjLI=.85b2020b-8c46-4bac-8a69-4975b068f2ff@github.com>
 <wpwFGOp8E00csxi2Xb9b-02ZlkqnIZEpo8AqaMsQ4AM=.90acb47b-effc-4838-ba80-28938d4dc3c0@github.com>
 <Z-0pp39dfPkKEtHlkyKtwKBlTI5dW8lnVl-MtJfuYNw=.034ab167-99ed-4fde-84cf-daca6998726f@github.com>
Message-ID: <3CquRSEBEyllynsP_PQ4oAPLYR_6itliFG5urQxgcNA=.a92842dc-9e1e-404c-9c65-894571609320@github.com>

On Wed, 8 May 2024 05:53:25 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Strengthen tests after 8330998
>>   
>>   https://github.com/openjdk/jdk/pull/18996 now allows us to test
>>   Console IO better.
>
> src/java.base/share/classes/java/io/Console.java line 151:
> 
>> 149:     /**
>> 150:      * Writes a string representation of the specified object to this console's
>> 151:      * output stream, terminates the line and then flushes the console.
> 
> Should this specify if the line termination will be platform dependent character(s) or independent of the platform?

That's a good question. I think it should. That `println` method is not specified in terms of `printf` or `format`. Thus, we cannot reduce `println` to, say, `printf("%s%n", obj)`, leaning on `Formatter`'s definition of `%n`:

    'n'	line separator	The result is the platform-specific line separator

@stuart-marks, any thoughts on wording? Mind you, if we add any such wording, we'll have to update CSR too.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19112#discussion_r1593742851

From jpai at openjdk.org  Wed May  8 10:34:53 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 8 May 2024 10:34:53 GMT
Subject: RFR: 8305457: Implement java.io.IO [v3]
In-Reply-To: <jWOXcC9B_23P_Px2zulnzRc38zL7zkslJM9nRtauHlk=.55e2ed38-59b7-4df1-be13-5d9a74672e26@github.com>
References: <w2msiw_qaMEIJS3s9D4bg8pFbz5WIF0KdP6Mm-XFjLI=.85b2020b-8c46-4bac-8a69-4975b068f2ff@github.com>
 <wpwFGOp8E00csxi2Xb9b-02ZlkqnIZEpo8AqaMsQ4AM=.90acb47b-effc-4838-ba80-28938d4dc3c0@github.com>
 <C1Pvc8KO7vUGELLaqcXpepoK_MpvChaDcZqfroVICo0=.5ab8bef5-fa21-4618-a903-219d733045a0@github.com>
 <jWOXcC9B_23P_Px2zulnzRc38zL7zkslJM9nRtauHlk=.55e2ed38-59b7-4df1-be13-5d9a74672e26@github.com>
Message-ID: <yZdbfOOkmceBWA5_ybn4g9cLTI-a40mvJ9eT6c_5YI4=.b5715149-8051-43bc-8556-1bc217bdfc39@github.com>

On Wed, 8 May 2024 08:59:18 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> src/java.base/share/classes/java/io/Console.java line 192:
>> 
>>> 190:      *
>>> 191:      * @param  prompt
>>> 192:      *         A prompt string.
>> 
>> Hello Pavel, should this specify whether `prompt`  can be null?
>
> If we specify that, it would be very much unlike all other `Console` methods that are covered by this:
> 
>     * Unless otherwise specified, passing a {@code null} argument to any method
>     * in this class will cause a {@link NullPointerException} to be thrown.

I haven't given it a try, but a brief look at the code suggests that if the console implementation backed by JLine gets used, then a `null` prompt may not generate a `NullPointerException` (since JLine appears to allow `null`) whereas if the internal JDK console implementation gets used then a `NullPointerException` will get thrown. If the expectation is to disallow a `null` prompt, then perhaps `Objects.requireNonNull(prompt)` before we hand off to the underlying console implementations might be required.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19112#discussion_r1593809280

From redestad at openjdk.org  Wed May  8 10:42:27 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Wed, 8 May 2024 10:42:27 GMT
Subject: RFR: 8331724: Refactor j.l.constant implementation to internal
 package [v5]
In-Reply-To: <_GPUF9d1E6eBKRxP6bEEqA3LSKRJe2GwCRTfVYbDwFU=.cb482785-e7c4-45f7-bd3a-cd32d466a2cb@github.com>
References: <_GPUF9d1E6eBKRxP6bEEqA3LSKRJe2GwCRTfVYbDwFU=.cb482785-e7c4-45f7-bd3a-cd32d466a2cb@github.com>
Message-ID: <8sn6v-wNyReo8y3huV8WQOC9QPf33IKTM0sXlEnif0Q=.ad224ff0-cb0f-44b1-9e02-d2fc275c3815@github.com>

> This PR suggests refactoring the implementation classes of java.lang.constant into a new package jdk.internal.constant to enable sharing some trusted static factory methods with users elsewhere in java.base, such as java.lang.invoke and java.lang.classfile. The refactoring also adds some "trusted" methods for use when input is pre-validated, and makes use of them where applicable in the current implementation. There are more changes in the pipeline which will be folded into #17108 or PR'ed once that is integrated. 
> 
> There are two optimizations mixed up here. One in `MethodTypeDesc.ofDescriptor`:
> 
> Name                                                             (descString) Cnt     Base     Error      Test   Error  Unit  Change
> MethodTypeDescFactories.ofDescriptor  (Ljava/lang/Object;Ljava/lang/String;)I   6  138,371 ?   0,767   136,939 ? 1,126 ns/op   1,01x (p = 0,000*)
> MethodTypeDescFactories.ofDescriptor                                      ()V   6   10,528 ?   2,495     4,110 ? 0,047 ns/op   2,56x (p = 0,000*)
> MethodTypeDescFactories.ofDescriptor ([IJLjava/lang/String;Z)Ljava/util/List;   6  209,390 ?   4,583   196,175 ? 3,211 ns/op   1,07x (p = 0,000*)
> MethodTypeDescFactories.ofDescriptor                    ()[Ljava/lang/String;   6   36,039 ?   8,684    20,794 ? 1,110 ns/op   1,73x (p = 0,000*)
> MethodTypeDescFactories.ofDescriptor                                 (..IIJ)V   6  279,139 ?   6,248   187,934 ? 0,857 ns/op   1,49x (p = 0,000*)
> MethodTypeDescFactories.ofDescriptor                 (.....................).   6 2174,387 ? 132,879  1150,652 ? 3,158 ns/op   1,89x (p = 0,000*)
>   * = significant
> 
> 
> The other in `ClassDesc::nested`, where to get rid of a simple static method in `ConstantUtils` I ended up speeding up and simplifying the public factory method:
> 
> Name                                      Cnt    Base     Error    Test   Error  Unit  Change
> ClassDescFactories.ReferenceOnly.ofNested   6 209,853 ? 132,525  22,017 ? 0,573 ns/op   9,53x (p = 0,000*)
>   * = significant
> 
> 
> The optimizations could be split out and PRd independently, but I think they are simple enough to include in this refactoring.

Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:

  Refactor to further avoid re-validating arguments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/19105/files
  - new: https://git.openjdk.org/jdk/pull/19105/files/543d0709..eb23cf51

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

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

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

From duke at openjdk.org  Wed May  8 11:36:07 2024
From: duke at openjdk.org (serhiysachkov)
Date: Wed, 8 May 2024 11:36:07 GMT
Subject: RFR: JDK-8331646: Add specific regression leap year tests (Task -
 P4) [v3]
In-Reply-To: <cB-Q8ihe6DYQTm1WcRvVV3oW8YXtnWH5fmsS1zurwwY=.176d4137-bd3b-445e-a055-c738bd73744c@github.com>
References: <cB-Q8ihe6DYQTm1WcRvVV3oW8YXtnWH5fmsS1zurwwY=.176d4137-bd3b-445e-a055-c738bd73744c@github.com>
Message-ID: <zHMK1g208lNjlj6NJUR_O9-ee0lnk_5dOlo3271RbPE=.8711e15c-4587-4513-ac7e-cd9a407191d6@github.com>

> Calendar.add() tests that describe its behavior.

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

  JDK-8331646 consolidating test methods into  ParameterizedTests

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/19082/files
  - new: https://git.openjdk.org/jdk/pull/19082/files/bce324f3..4bb425da

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

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

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

From duke at openjdk.org  Wed May  8 11:41:52 2024
From: duke at openjdk.org (serhiysachkov)
Date: Wed, 8 May 2024 11:41:52 GMT
Subject: RFR: JDK-8331646: Add specific regression leap year tests (Task -
 P4) [v2]
In-Reply-To: <2UWQj4csbOaSZ8Y7-tVp7dBb4CZaPGk9VrF4fU_T2Bs=.7b1d6b60-7063-4c47-8b49-1da47177fcb6@github.com>
References: <cB-Q8ihe6DYQTm1WcRvVV3oW8YXtnWH5fmsS1zurwwY=.176d4137-bd3b-445e-a055-c738bd73744c@github.com>
 <jVsUCuB16T9wnWispfbUcU7fCsN4ucmYlbzWKrD2638=.2aa43d44-3e8e-485d-a7e3-d196daf2aafd@github.com>
 <2UWQj4csbOaSZ8Y7-tVp7dBb4CZaPGk9VrF4fU_T2Bs=.7b1d6b60-7063-4c47-8b49-1da47177fcb6@github.com>
Message-ID: <81KAfemWGrhBzeg96vLBIi6y8jYRQHjdATj5RPb2Bqw=.6a600ded-be77-4faf-8e97-6aaf56f379bb@github.com>

On Tue, 7 May 2024 16:43:11 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Sorry if I was unclear, but I meant to consolidate the test methods, as they are duplicates other than the calendar values. Those values should be parametrized and consolidate the test body into a single method.

sorry for misunderstanding, I was trying to provide scenarios that are easy to follow and understand for devs, but you are right we don't need duplication there.

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

PR Comment: https://git.openjdk.org/jdk/pull/19082#issuecomment-2100383313

From mgronlun at openjdk.org  Wed May  8 12:07:54 2024
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Wed, 8 May 2024 12:07:54 GMT
Subject: RFR: 8331876: JFR: Move file read and write events to java.base
In-Reply-To: <DDe0bKCC86AawVl7RylZ74uvvLBr2Zljpkcmxx1_WEU=.61cc10c6-b635-42dd-a850-b32ae1d68585@github.com>
References: <DDe0bKCC86AawVl7RylZ74uvvLBr2Zljpkcmxx1_WEU=.61cc10c6-b635-42dd-a850-b32ae1d68585@github.com>
Message-ID: <p-TYkfBDQL3wiTeFcvWo1TqNdfya-Qv33O_s3JhnK10=.c4afc39d-a628-4657-8637-8bf88a028a52@github.com>

On Tue, 7 May 2024 19:32:57 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> Hi,
> 
> Could I have a review of a change that moves the jdk.FileRead and jdk.FileWrite events to java.base to remove the use of the ASM instrumentation.
> 
> Testing: jdk/jdk/jfr
> 
> Thanks
> Erik

Marked as reviewed by mgronlun (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/19129#pullrequestreview-2045472095

From prappo at openjdk.org  Wed May  8 13:15:52 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Wed, 8 May 2024 13:15:52 GMT
Subject: RFR: 8305457: Implement java.io.IO [v3]
In-Reply-To: <yZdbfOOkmceBWA5_ybn4g9cLTI-a40mvJ9eT6c_5YI4=.b5715149-8051-43bc-8556-1bc217bdfc39@github.com>
References: <w2msiw_qaMEIJS3s9D4bg8pFbz5WIF0KdP6Mm-XFjLI=.85b2020b-8c46-4bac-8a69-4975b068f2ff@github.com>
 <wpwFGOp8E00csxi2Xb9b-02ZlkqnIZEpo8AqaMsQ4AM=.90acb47b-effc-4838-ba80-28938d4dc3c0@github.com>
 <C1Pvc8KO7vUGELLaqcXpepoK_MpvChaDcZqfroVICo0=.5ab8bef5-fa21-4618-a903-219d733045a0@github.com>
 <jWOXcC9B_23P_Px2zulnzRc38zL7zkslJM9nRtauHlk=.55e2ed38-59b7-4df1-be13-5d9a74672e26@github.com>
 <yZdbfOOkmceBWA5_ybn4g9cLTI-a40mvJ9eT6c_5YI4=.b5715149-8051-43bc-8556-1bc217bdfc39@github.com>
Message-ID: <QOraUtvx4uq8mQagpLv6RQDsY-bD5YcvspNegJ9R9O4=.8b4a7dec-6445-4dc0-bbe3-a74385e00826@github.com>

On Wed, 8 May 2024 10:31:59 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> If we specify that, it would be very much unlike all other `Console` methods that are covered by this:
>> 
>>     * Unless otherwise specified, passing a {@code null} argument to any method
>>     * in this class will cause a {@link NullPointerException} to be thrown.
>
> I haven't given it a try, but a brief look at the code suggests that if the console implementation backed by JLine gets used, then a `null` prompt may not generate a `NullPointerException` (since JLine appears to allow `null`) whereas if the internal JDK console implementation gets used then a `NullPointerException` will get thrown. If the expectation is to disallow a `null` prompt, then perhaps `Objects.requireNonNull(prompt)` before we hand off to the underlying console implementations might be required.

Good catch! `jdk.internal.org.jline.JdkConsoleProviderImpl.JdkConsoleImpl.readln(null)` does not throw `NullPointerException` (NPE), which it must. I'll fix the bug and add a test.

Speaking of NPE. The newly added `Console.print` and `Console.println` methods do not throw NPE if passed null. While that's how it should be, they don't specify that, so the class-level NPE clause applies:

    * Unless otherwise specified, passing a {@code null} argument to any method
    * in this class will cause a {@link NullPointerException} to be thrown.
    ...
    public sealed class Console implements Flushable permits ProxyingConsole {

I'll fix that.

We should also specify NPE (or absence thereof) on methods of `IO`. Otherwise, this package clause applies:

    * Unless otherwise noted, passing a {@code null} argument to a constructor or
    * method in any class or interface in this package will cause a
    * {@code NullPointerException} to be thrown.
    ...
    package java.io;

@stuart-marks speaking of exceptions. Do we need to add explicit `@throws` tag to `IO` methods?

    @throws {@code IOError} if {@code System.console()} returns {@code null}

While it would make sense, it would also look superfluous: we already specify that error condition in the class comment and then in every method's main description. Do we need to add one more note on `IOError`?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19112#discussion_r1594013064

From rotanolexandr842 at gmail.com  Wed May  8 13:59:32 2024
From: rotanolexandr842 at gmail.com (Olexandr Rotan)
Date: Wed, 8 May 2024 16:59:32 +0300
Subject: RFR: 8305457: Implement java.io.IO [v3]
In-Reply-To: <QOraUtvx4uq8mQagpLv6RQDsY-bD5YcvspNegJ9R9O4=.8b4a7dec-6445-4dc0-bbe3-a74385e00826@github.com>
References: <w2msiw_qaMEIJS3s9D4bg8pFbz5WIF0KdP6Mm-XFjLI=.85b2020b-8c46-4bac-8a69-4975b068f2ff@github.com>
 <wpwFGOp8E00csxi2Xb9b-02ZlkqnIZEpo8AqaMsQ4AM=.90acb47b-effc-4838-ba80-28938d4dc3c0@github.com>
 <C1Pvc8KO7vUGELLaqcXpepoK_MpvChaDcZqfroVICo0=.5ab8bef5-fa21-4618-a903-219d733045a0@github.com>
 <jWOXcC9B_23P_Px2zulnzRc38zL7zkslJM9nRtauHlk=.55e2ed38-59b7-4df1-be13-5d9a74672e26@github.com>
 <yZdbfOOkmceBWA5_ybn4g9cLTI-a40mvJ9eT6c_5YI4=.b5715149-8051-43bc-8556-1bc217bdfc39@github.com>
 <QOraUtvx4uq8mQagpLv6RQDsY-bD5YcvspNegJ9R9O4=.8b4a7dec-6445-4dc0-bbe3-a74385e00826@github.com>
Message-ID: <CAL5bRt9qzLxh5+fWacXBbZvgfEtJgYvAwS+taSOQ=RFuZA9+RQ@mail.gmail.com>

Has it been considered to add a readKey() method to IO class? In my
experience, it is pretty commonly used by beginners when they write things
like console games (snake, catcher game etc.). I am aware there is
System.in.read() method, but since we decided to promote some methods to
separate methods in IO class, maybe readKey() or simple read() should also
be considered?

On Wed, May 8, 2024 at 4:16?PM Pavel Rappo <prappo at openjdk.org> wrote:

> On Wed, 8 May 2024 10:31:59 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:
>
> >> If we specify that, it would be very much unlike all other `Console`
> methods that are covered by this:
> >>
> >>     * Unless otherwise specified, passing a {@code null} argument to
> any method
> >>     * in this class will cause a {@link NullPointerException} to be
> thrown.
> >
> > I haven't given it a try, but a brief look at the code suggests that if
> the console implementation backed by JLine gets used, then a `null` prompt
> may not generate a `NullPointerException` (since JLine appears to allow
> `null`) whereas if the internal JDK console implementation gets used then a
> `NullPointerException` will get thrown. If the expectation is to disallow a
> `null` prompt, then perhaps `Objects.requireNonNull(prompt)` before we hand
> off to the underlying console implementations might be required.
>
> Good catch!
> `jdk.internal.org.jline.JdkConsoleProviderImpl.JdkConsoleImpl.readln(null)`
> does not throw `NullPointerException` (NPE), which it must. I'll fix the
> bug and add a test.
>
> Speaking of NPE. The newly added `Console.print` and `Console.println`
> methods do not throw NPE if passed null. While that's how it should be,
> they don't specify that, so the class-level NPE clause applies:
>
>     * Unless otherwise specified, passing a {@code null} argument to any
> method
>     * in this class will cause a {@link NullPointerException} to be thrown.
>     ...
>     public sealed class Console implements Flushable permits
> ProxyingConsole {
>
> I'll fix that.
>
> We should also specify NPE (or absence thereof) on methods of `IO`.
> Otherwise, this package clause applies:
>
>     * Unless otherwise noted, passing a {@code null} argument to a
> constructor or
>     * method in any class or interface in this package will cause a
>     * {@code NullPointerException} to be thrown.
>     ...
>     package java.io;
>
> @stuart-marks speaking of exceptions. Do we need to add explicit `@throws`
> tag to `IO` methods?
>
>     @throws {@code IOError} if {@code System.console()} returns {@code
> null}
>
> While it would make sense, it would also look superfluous: we already
> specify that error condition in the class comment and then in every
> method's main description. Do we need to add one more note on `IOError`?
>
> -------------
>
> PR Review Comment:
> https://git.openjdk.org/jdk/pull/19112#discussion_r1594013064
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240508/28c90cb6/attachment-0001.htm>

From redestad at openjdk.org  Wed May  8 14:59:06 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Wed, 8 May 2024 14:59:06 GMT
Subject: RFR: 8331932: Startup regressions in 23-b13
Message-ID: <LgTAOs1QA0kgTbAfVQ_U2BcWAV7AHpcFXNE7eYB1BI8=.e77b81c1-73d4-4ff0-806f-eeda86d5cb16@github.com>

A rather large startup regression was introduced in 23-b13 from [JDK-8309622](https://bugs.openjdk.org/browse/JDK-8309622). Some of that has been dealt with as enhancements such as [JDK-8330802](https://bugs.openjdk.org/browse/JDK-8330802), [JDK-8330595](https://bugs.openjdk.org/browse/JDK-8330595) and [JDK-8330681](https://bugs.openjdk.org/browse/JDK-8330681), which provide both point fixes and reduce initialization overhead of certain constructs more generally. The remaining issues stem from a set of lambdas added in code for `java.util.Locale` and `jdk.internal.util.BaseLocale` causing early bootstrapping of the lambda infrastructure and a bit of class generation.

While the remaining overheads are relatively small and borderline acceptable (< 2-3ms), I think it's still worth acting on them in this particular case since the amount of added bootstrapping overhead is dependent on which locale the system runs under, which complicates testing and comparisons due to relatively large differences in paths taken on different systems.

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

Commit messages:
 - 8331932: Startup regressions in 23-b13

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

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

From ihse at openjdk.org  Wed May  8 15:01:07 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 8 May 2024 15:01:07 GMT
Subject: RFR: 8311302: Allow for jlinking a custom runtime without packaged
 modules being present [v26]
In-Reply-To: <RUr5xr-pzsccK28vRBO-GhY-8RltknEX2lyMgWpijnA=.980d0b9d-f219-4bc7-bf64-4e343f44ac7d@github.com>
References: <Z0DJ87uKPbjS6mvJIE_oG5m-RWsbERXsytSgV8Bmhdo=.f8723513-0ac6-4e85-9131-3c3924860c61@github.com>
 <RUr5xr-pzsccK28vRBO-GhY-8RltknEX2lyMgWpijnA=.980d0b9d-f219-4bc7-bf64-4e343f44ac7d@github.com>
Message-ID: <NOt7chFa8Q21S6TH10LYUVMxD-5eeEhxYPfae0TTdp4=.f19ad502-dd99-406e-ab71-49caea209e7e@github.com>

On Tue, 7 May 2024 16:52:12 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> Please review this patch which adds a jlink mode to the JDK which doesn't need the packaged modules being present. A.k.a run-time image based jlink. Fundamentally this patch adds an option to use `jlink` even though your JDK install might not come with the packaged modules (directory `jmods`). This is particularly useful to further reduce the size of a jlinked runtime. After the removal of the concept of a JRE, a common distribution mechanism is still the full JDK with all modules and packaged modules. However, packaged modules can incur an additional size tax. For example in a container scenario it could be useful to have a base JDK container including all modules, but without also delivering the packaged modules. This comes at a size advantage of `~25%`. Such a base JDK container could then be used to `jlink` application specific runtimes, further reducing the size of the application runtime image (App + JDK runtime; as a single image *or* separate bundles, depending on the app 
 being modularized).
>> 
>> The basic design of this approach is to add a jlink plugin for tracking non-class and non-resource files of a JDK install. I.e. files which aren't present in the jimage (`lib/modules`). This enables producing a `JRTArchive` class which has all the info of what constitutes the final jlinked runtime.
>> 
>> Basic usage example:
>> 
>> $ diff -u <(./bin/java --list-modules --limit-modules java.se) <(../linux-x86_64-server-release/images/jdk/bin/java --list-modules --limit-modules java.se)
>> $ diff -u <(./bin/java --list-modules --limit-modules jdk.jlink) <(../linux-x86_64-server-release/images/jdk/bin/java --list-modules --limit-modules jdk.jlink)
>> $ ls ../linux-x86_64-server-release/images/jdk/jmods
>> java.base.jmod            java.net.http.jmod       java.sql.rowset.jmod      jdk.crypto.ec.jmod         jdk.internal.opt.jmod                     jdk.jdi.jmod         jdk.management.agent.jmod  jdk.security.auth.jmod
>> java.compiler.jmod        java.prefs.jmod          java.transaction.xa.jmod  jdk.dynalink.jmod          jdk.internal.vm.ci.jmod                   jdk.jdwp.agent.jmod  jdk.management.jfr.jmod    jdk.security.jgss.jmod
>> java.datatransfer.jmod    java.rmi.jmod            java.xml.crypto.jmod      jdk.editpad.jmod           jdk.internal.vm.compiler.jmod             jdk.jfr.jmod         jdk.management.jmod        jdk.unsupported.desktop.jmod
>> java.desktop.jmod         java.scripting.jmod      java.xml.jmod             jdk.hotspot.agent.jmod     jdk.i...
>
> Severin Gehwolf has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 105 commits:
> 
>  - Generate the runtime image link diff at jlink time
>    
>    But only do that once the plugin-pipeline has run. The generation is
>    enabled with the hidden option '--generate-linkable-runtime' and
>    the resource pools available at jlink time are being used to generate
>    the diff.
>  - Merge branch 'master' into jdk-8311302-jmodless-link
>  - Use shorter name for the build tool
>  - Review feedback from Erik J.
>  - Remove dependency on CDS which isn't needed anymore
>  - Fix coment
>  - Fix comment
>  - Fix typo
>  - Revert some now unneded build changes
>  - Follow build tools naming convention
>  - ... and 95 more: https://git.openjdk.org/jdk/compare/23a72a1f...67aea4ca

The new build changes look extremely trivial. From a pure build PoV, this is a much simpler solution.

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

Marked as reviewed by ihse (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14787#pullrequestreview-2045924409

From liach at openjdk.org  Wed May  8 15:11:58 2024
From: liach at openjdk.org (Chen Liang)
Date: Wed, 8 May 2024 15:11:58 GMT
Subject: RFR: 8331932: Startup regressions in 23-b13
In-Reply-To: <LgTAOs1QA0kgTbAfVQ_U2BcWAV7AHpcFXNE7eYB1BI8=.e77b81c1-73d4-4ff0-806f-eeda86d5cb16@github.com>
References: <LgTAOs1QA0kgTbAfVQ_U2BcWAV7AHpcFXNE7eYB1BI8=.e77b81c1-73d4-4ff0-806f-eeda86d5cb16@github.com>
Message-ID: <uaHIMSO8nukMgoXobzNd4gLHmgk2P64HIxlNd-LY4L0=.bef31095-2481-4cc6-bf59-0ec17a101431@github.com>

On Wed, 8 May 2024 14:53:05 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> A rather large startup regression was introduced in 23-b13 from [JDK-8309622](https://bugs.openjdk.org/browse/JDK-8309622). Some of that has been dealt with as enhancements such as [JDK-8330802](https://bugs.openjdk.org/browse/JDK-8330802), [JDK-8330595](https://bugs.openjdk.org/browse/JDK-8330595) and [JDK-8330681](https://bugs.openjdk.org/browse/JDK-8330681), which provide both point fixes and reduce initialization overhead of certain constructs more generally. The remaining issues stem from a set of lambdas added in code for `java.util.Locale` and `jdk.internal.util.BaseLocale` causing early bootstrapping of the lambda infrastructure and a bit of class generation.
> 
> While the remaining overheads are relatively small and borderline acceptable (< 2-3ms), I think it's still worth acting on them in this particular case since the amount of added bootstrapping overhead is dependent on which locale the system runs under, which complicates testing and comparisons due to relatively large differences in paths taken on different systems.

src/java.base/share/classes/java/util/Locale.java line 1001:

> 999:             = ReferencedKeyMap.create(true, ReferencedKeyMap.concurrentHashMapSupplier());
> 1000: 
> 1001:     private static final LocaleKey LOCALE_LOOKUP = new LocaleKey();

Reusing an existing class with a special instance for functional interface implementation is weird, I still wonder if we can do the local class + singleton (essentially same as non-capturing lambda) approach.

src/java.base/share/classes/sun/util/locale/BaseLocale.java line 168:

> 166:         return CACHE.intern(new BaseLocale(language, script, region, variant),
> 167:                 // Avoid lambdas since this may be on the bootstrap path in many locales
> 168:                 new UnaryOperator<BaseLocale>() {

Since this intern is called many times, can we convert this `new` to a local class in a static method and reuse its singleton?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19140#discussion_r1594201610
PR Review Comment: https://git.openjdk.org/jdk/pull/19140#discussion_r1594199711

From mcimadamore at openjdk.org  Wed May  8 15:36:18 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 8 May 2024 15:36:18 GMT
Subject: RFR: 8331734: Atomic MemorySegment VarHandle operations fails for
 element layouts [v2]
In-Reply-To: <_PQ4wP4lk_STKwnSddD-5GgfsCheLbT_MR9zIyQyE78=.4ae37fdc-cf6e-46ea-8dbe-afcd1e710666@github.com>
References: <_PQ4wP4lk_STKwnSddD-5GgfsCheLbT_MR9zIyQyE78=.4ae37fdc-cf6e-46ea-8dbe-afcd1e710666@github.com>
Message-ID: <HucoGPVvgkO1ytZ0YE6Oe5dGahLxRJjxM1ztwQSrQG4=.0ef42063-e5d3-49ee-ad5a-b6613a12538a@github.com>

> This PR fixes an issue that has crept into the FFM API implementation.
> 
> From very early stages, the FFM API used to disable the alignment check on nested layout elements, in favor of an alignment check against the memory segment base address. The rationale was that the JIT had issue with eliminating redundant alignment checks, and accessing nested elements could never result in alignment issues, since the alignment of the container is provably bigger than that of the contained element. This means that, when creating a var handle for a nested layout element, we set the nested layout alignment to 1 (unaligned), derive its var handle, and then decorate the var handle with an alignment check for the container.
> 
> At some point in 22, we tweaked the API to throw `UnsupportedOperationException` when using an access mode incompatible with the alignment constraint of the accessed layout. That is, a volatile read on an `int` is only possible if the access occurs at an address that is at least 4-byte aligned. Otherwise an `UOE` is thrown.
> 
> Unfortunately this change broke the aforementioned optimization: creating a var handle for an unaligned layout works, but the resulting layout will *not* support any of the atomic access modes.
> 
> Since this optimization is not really required anymore (proper C2 support to hoist/eliminate alignment checks has been added since then), it is better to disable this implementation quirk, and leave optimizations to C2.
> 
> (If we really really wanted to optimize things a bit, we could remove the container alignment check in the case the accessed value is the first layout element nested in the container, but this PR doesn't go that far).
> 
> I've run relevant benchmarks before/after and found no differences. In part this is because `arrayElementVarHandle` is unaffected. But, even after tweaking the `LoopOverNonConstant` benchmark to add explicit tests for the code path affected, no significant difference was found, sign that C2 is indeed able to spot (and remove) the redundant alignment check. Note: if we know that `aligned_to_N(base)` holds, then it's easy to prove that `aligned_to_M(base + offset + index * scale)` holds, when `N >= M` and with `offset` and `scale` known (the latter a power of two).

Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:

  Revert spurious change to test

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/19124/files
  - new: https://git.openjdk.org/jdk/pull/19124/files/aa5ed595..829c5e28

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

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

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

From mcimadamore at openjdk.org  Wed May  8 15:36:18 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 8 May 2024 15:36:18 GMT
Subject: RFR: 8331734: Atomic MemorySegment VarHandle operations fails for
 element layouts
In-Reply-To: <_PQ4wP4lk_STKwnSddD-5GgfsCheLbT_MR9zIyQyE78=.4ae37fdc-cf6e-46ea-8dbe-afcd1e710666@github.com>
References: <_PQ4wP4lk_STKwnSddD-5GgfsCheLbT_MR9zIyQyE78=.4ae37fdc-cf6e-46ea-8dbe-afcd1e710666@github.com>
Message-ID: <VAnyFRyCrqDIQiRcWdFweJOnOCgYh3MiFeoSDogEa7E=.fd6f6456-5969-46d9-8eeb-df267b8d295c@github.com>

On Tue, 7 May 2024 15:42:23 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> This PR fixes an issue that has crept into the FFM API implementation.
> 
> From very early stages, the FFM API used to disable the alignment check on nested layout elements, in favor of an alignment check against the memory segment base address. The rationale was that the JIT had issue with eliminating redundant alignment checks, and accessing nested elements could never result in alignment issues, since the alignment of the container is provably bigger than that of the contained element. This means that, when creating a var handle for a nested layout element, we set the nested layout alignment to 1 (unaligned), derive its var handle, and then decorate the var handle with an alignment check for the container.
> 
> At some point in 22, we tweaked the API to throw `UnsupportedOperationException` when using an access mode incompatible with the alignment constraint of the accessed layout. That is, a volatile read on an `int` is only possible if the access occurs at an address that is at least 4-byte aligned. Otherwise an `UOE` is thrown.
> 
> Unfortunately this change broke the aforementioned optimization: creating a var handle for an unaligned layout works, but the resulting layout will *not* support any of the atomic access modes.
> 
> Since this optimization is not really required anymore (proper C2 support to hoist/eliminate alignment checks has been added since then), it is better to disable this implementation quirk, and leave optimizations to C2.
> 
> (If we really really wanted to optimize things a bit, we could remove the container alignment check in the case the accessed value is the first layout element nested in the container, but this PR doesn't go that far).
> 
> I've run relevant benchmarks before/after and found no differences. In part this is because `arrayElementVarHandle` is unaffected. But, even after tweaking the `LoopOverNonConstant` benchmark to add explicit tests for the code path affected, no significant difference was found, sign that C2 is indeed able to spot (and remove) the redundant alignment check. Note: if we know that `aligned_to_N(base)` holds, then it's easy to prove that `aligned_to_M(base + offset + index * scale)` holds, when `N >= M` and with `offset` and `scale` known (the latter a power of two).

Overall, I'm not too sure about the alignment check on the root layout performed by a var handle pointing to a group layout member. We've got there honestly - e.g. make sure the accessed segment/offset is really compatible with root layout. But, if so, then why also not checking the segment size against the root layout size? E.g. say I have a layout for:


var POINT_LAYOUT = structLayout(JAVA_DOUBLE.withName("x"), JAVA_DOUBLE.withName("y"))

And I derive a var handle for `x`, like so:


VarHandle x_handle = POINT_LAYOUT.varHandle(PathElement.groupLayout("x"));


Say that I have a 8-byte segment, and I use that with the `x_handle` above:


MemorySegment halfPoint = Arena.ofAuto().allocate(8);
double x = (double)x_handle.get(halfPoint, 0);


Should this work? Currently it does, and one might claim that it does so "by accident" - e.g. it just so happen that the provided segment/offset combo was big enough to access `x`. But of course accessing `y` would fail.

There are of course two possible interpretations here, and both are valid:
* `x_handle` is just a regular memory access var handle for `JAVA_DOUBLE` - it just contains some extra logic to compute the correct offset from the start segment/offset combo, but that's it.
* `x_handle` is really meant to provide access to a memory segment modelling (at least) one struct with layout `POINT_LAYOUT`. As such, the initial segment/offset combo should (a) be adequately aligned (according to `POINT_LAYOUT.byteAlignment()`) and have sufficient size (according to `POINT_LAYOUT.byteSize()`)

The former favors performance, the latter favors safety, as it ensures that the initial segment/offset combo do indeed describe a segment whose characteristics are compatible with those of the selected layout.

This is also related to `MemoryLayout::arrayElementVarHandle`. Currently this method is specified as:


MethodHandles.collectCoordinates(varHandle(elements), 1, scaleHandle())


This means that the root layout checks performed by the obtained method handle will refer to the alignment (and size) of the current layout. For instance, if I write:


VarHandle xs_handle = POINT_LAYOUT.arrayElementVarHandle(PathElement.groupLayout("x"));


Assuming we picked the safer semantics described above, the resulting var handle will check that the initial segment/offset combo will point to a segment whose alignment (and size) are compatible with those of `POINT_LAYOUT`. I believe this is acceptable: this var handle is meant to capture unbounded sequence access - so the only thing we can meaningfully check is whether the segment is at least big enough to store one element (if not, then we know that all accesses are going to fail). But, on the other hand, an argument could be made that, given we don't know the size of the array statically, adding any kind of size check here feels too much and/or doesn't buy much.

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

PR Comment: https://git.openjdk.org/jdk/pull/19124#issuecomment-2100853634

From smarks at openjdk.org  Wed May  8 16:08:53 2024
From: smarks at openjdk.org (Stuart Marks)
Date: Wed, 8 May 2024 16:08:53 GMT
Subject: RFR: 8305457: Implement java.io.IO [v3]
In-Reply-To: <3CquRSEBEyllynsP_PQ4oAPLYR_6itliFG5urQxgcNA=.a92842dc-9e1e-404c-9c65-894571609320@github.com>
References: <w2msiw_qaMEIJS3s9D4bg8pFbz5WIF0KdP6Mm-XFjLI=.85b2020b-8c46-4bac-8a69-4975b068f2ff@github.com>
 <wpwFGOp8E00csxi2Xb9b-02ZlkqnIZEpo8AqaMsQ4AM=.90acb47b-effc-4838-ba80-28938d4dc3c0@github.com>
 <Z-0pp39dfPkKEtHlkyKtwKBlTI5dW8lnVl-MtJfuYNw=.034ab167-99ed-4fde-84cf-daca6998726f@github.com>
 <3CquRSEBEyllynsP_PQ4oAPLYR_6itliFG5urQxgcNA=.a92842dc-9e1e-404c-9c65-894571609320@github.com>
Message-ID: <hXdEZvBFHYhtw7vneAjpT-dM5FbF7fJEQdW1n_L0608=.6e2bc424-c734-4867-bf68-f442b5896bbf@github.com>

On Wed, 8 May 2024 09:39:13 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> src/java.base/share/classes/java/io/Console.java line 151:
>> 
>>> 149:     /**
>>> 150:      * Writes a string representation of the specified object to this console's
>>> 151:      * output stream, terminates the line and then flushes the console.
>> 
>> Should this specify if the line termination will be platform dependent character(s) or independent of the platform?
>
> That's a good question. I think it should. That `println` method is not specified in terms of `printf` or `format`. Thus, we cannot reduce `println` to, say, `printf("%s%n", obj)`, leaning on `Formatter`'s definition of `%n`:
> 
>     'n'	line separator	The result is the platform-specific line separator
> 
> @stuart-marks, any thoughts on wording? Mind you, if we add any such wording, we'll have to update CSR too.

Well `Formatter` defers to `System.lineSeparator()` so I think we should refer to that. Not sure that needs to be repeated in `java.io.IO`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19112#discussion_r1594281188

From smarks at openjdk.org  Wed May  8 16:08:54 2024
From: smarks at openjdk.org (Stuart Marks)
Date: Wed, 8 May 2024 16:08:54 GMT
Subject: RFR: 8305457: Implement java.io.IO [v3]
In-Reply-To: <QOraUtvx4uq8mQagpLv6RQDsY-bD5YcvspNegJ9R9O4=.8b4a7dec-6445-4dc0-bbe3-a74385e00826@github.com>
References: <w2msiw_qaMEIJS3s9D4bg8pFbz5WIF0KdP6Mm-XFjLI=.85b2020b-8c46-4bac-8a69-4975b068f2ff@github.com>
 <wpwFGOp8E00csxi2Xb9b-02ZlkqnIZEpo8AqaMsQ4AM=.90acb47b-effc-4838-ba80-28938d4dc3c0@github.com>
 <C1Pvc8KO7vUGELLaqcXpepoK_MpvChaDcZqfroVICo0=.5ab8bef5-fa21-4618-a903-219d733045a0@github.com>
 <jWOXcC9B_23P_Px2zulnzRc38zL7zkslJM9nRtauHlk=.55e2ed38-59b7-4df1-be13-5d9a74672e26@github.com>
 <yZdbfOOkmceBWA5_ybn4g9cLTI-a40mvJ9eT6c_5YI4=.b5715149-8051-43bc-8556-1bc217bdfc39@github.com>
 <QOraUtvx4uq8mQagpLv6RQDsY-bD5YcvspNegJ9R9O4=.8b4a7dec-6445-4dc0-bbe3-a74385e00826@github.com>
Message-ID: <kXr9EdR3dWGNLqQRenj1LcwWTChuqmc6gA7r04R9nAo=.76e57556-5210-45ae-8e13-755a604c0c49@github.com>

On Wed, 8 May 2024 13:13:33 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> I haven't given it a try, but a brief look at the code suggests that if the console implementation backed by JLine gets used, then a `null` prompt may not generate a `NullPointerException` (since JLine appears to allow `null`) whereas if the internal JDK console implementation gets used then a `NullPointerException` will get thrown. If the expectation is to disallow a `null` prompt, then perhaps `Objects.requireNonNull(prompt)` before we hand off to the underlying console implementations might be required.
>
> Good catch! `jdk.internal.org.jline.JdkConsoleProviderImpl.JdkConsoleImpl.readln(null)` does not throw `NullPointerException` (NPE), which it must. I'll fix the bug and add a test.
> 
> Speaking of NPE. The newly added `Console.print` and `Console.println` methods do not throw NPE if passed null. While that's how it should be, they don't specify that, so the class-level NPE clause applies:
> 
>     * Unless otherwise specified, passing a {@code null} argument to any method
>     * in this class will cause a {@link NullPointerException} to be thrown.
>     ...
>     public sealed class Console implements Flushable permits ProxyingConsole {
> 
> I'll fix that.
> 
> We should also specify NPE (or absence thereof) on methods of `IO`. Otherwise, this package clause applies:
> 
>     * Unless otherwise noted, passing a {@code null} argument to a constructor or
>     * method in any class or interface in this package will cause a
>     * {@code NullPointerException} to be thrown.
>     ...
>     package java.io;
> 
> @stuart-marks speaking of exceptions. Do we need to add explicit `@throws` tag to `IO` methods?
> 
>     @throws {@code IOError} if {@code System.console()} returns {@code null}
> 
> While it would make sense, it would also look superfluous: we already specify that error condition in the class comment and then in every method's main description. Do we need to add one more note on `IOError`?

Most of these are defined in terms of `String.valueOf(Object)` which if passed a null reference will return the String object containing `null`. So no, I don't think NPE should be thrown. It might be worth mentioning this explicitly somewhere though.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19112#discussion_r1594282580

From redestad at openjdk.org  Wed May  8 16:26:18 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Wed, 8 May 2024 16:26:18 GMT
Subject: RFR: 8331932: Startup regressions in 23-b13 [v2]
In-Reply-To: <LgTAOs1QA0kgTbAfVQ_U2BcWAV7AHpcFXNE7eYB1BI8=.e77b81c1-73d4-4ff0-806f-eeda86d5cb16@github.com>
References: <LgTAOs1QA0kgTbAfVQ_U2BcWAV7AHpcFXNE7eYB1BI8=.e77b81c1-73d4-4ff0-806f-eeda86d5cb16@github.com>
Message-ID: <adCz2VA2S1X9_421vNtduPnxPbX-kk9Jxl9F_sMzV9U=.80437588-9583-4145-bd28-adcb12cdc796@github.com>

> A rather large startup regression was introduced in 23-b13 from [JDK-8309622](https://bugs.openjdk.org/browse/JDK-8309622). Some of that has been dealt with as enhancements such as [JDK-8330802](https://bugs.openjdk.org/browse/JDK-8330802), [JDK-8330595](https://bugs.openjdk.org/browse/JDK-8330595) and [JDK-8330681](https://bugs.openjdk.org/browse/JDK-8330681), which provide both point fixes and reduce initialization overhead of certain constructs more generally. The remaining issues stem from a set of lambdas added in code for `java.util.Locale` and `jdk.internal.util.BaseLocale` causing early bootstrapping of the lambda infrastructure and a bit of class generation.
> 
> While the remaining overheads are relatively small and borderline acceptable (< 2-3ms), I think it's still worth acting on them in this particular case since the amount of added bootstrapping overhead is dependent on which locale the system runs under, which complicates testing and comparisons due to relatively large differences in paths taken on different systems.

Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:

  Singleton Locale creator

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/19140/files
  - new: https://git.openjdk.org/jdk/pull/19140/files/0520f953..73097159

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

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

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

From mcimadamore at openjdk.org  Wed May  8 16:39:16 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 8 May 2024 16:39:16 GMT
Subject: RFR: 8331734: Atomic MemorySegment VarHandle operations fails for
 element layouts [v3]
In-Reply-To: <_PQ4wP4lk_STKwnSddD-5GgfsCheLbT_MR9zIyQyE78=.4ae37fdc-cf6e-46ea-8dbe-afcd1e710666@github.com>
References: <_PQ4wP4lk_STKwnSddD-5GgfsCheLbT_MR9zIyQyE78=.4ae37fdc-cf6e-46ea-8dbe-afcd1e710666@github.com>
Message-ID: <H0JpXT64BN4DgCUyO7EWlpkUPlpAINy-uUoYJbXx2ic=.33265d43-6ffe-44d5-a456-52daeb68ea27@github.com>

> This PR fixes an issue that has crept into the FFM API implementation.
> 
> From very early stages, the FFM API used to disable the alignment check on nested layout elements, in favor of an alignment check against the memory segment base address. The rationale was that the JIT had issue with eliminating redundant alignment checks, and accessing nested elements could never result in alignment issues, since the alignment of the container is provably bigger than that of the contained element. This means that, when creating a var handle for a nested layout element, we set the nested layout alignment to 1 (unaligned), derive its var handle, and then decorate the var handle with an alignment check for the container.
> 
> At some point in 22, we tweaked the API to throw `UnsupportedOperationException` when using an access mode incompatible with the alignment constraint of the accessed layout. That is, a volatile read on an `int` is only possible if the access occurs at an address that is at least 4-byte aligned. Otherwise an `UOE` is thrown.
> 
> Unfortunately this change broke the aforementioned optimization: creating a var handle for an unaligned layout works, but the resulting layout will *not* support any of the atomic access modes.
> 
> Since this optimization is not really required anymore (proper C2 support to hoist/eliminate alignment checks has been added since then), it is better to disable this implementation quirk, and leave optimizations to C2.
> 
> (If we really really wanted to optimize things a bit, we could remove the container alignment check in the case the accessed value is the first layout element nested in the container, but this PR doesn't go that far).
> 
> I've run relevant benchmarks before/after and found no differences. In part this is because `arrayElementVarHandle` is unaffected. But, even after tweaking the `LoopOverNonConstant` benchmark to add explicit tests for the code path affected, no significant difference was found, sign that C2 is indeed able to spot (and remove) the redundant alignment check. Note: if we know that `aligned_to_N(base)` holds, then it's easy to prove that `aligned_to_M(base + offset + index * scale)` holds, when `N >= M` and with `offset` and `scale` known (the latter a power of two).

Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:

  Add benchmark anno

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/19124/files
  - new: https://git.openjdk.org/jdk/pull/19124/files/829c5e28..40ba693c

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

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

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

From mcimadamore at openjdk.org  Wed May  8 16:39:16 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 8 May 2024 16:39:16 GMT
Subject: RFR: 8331734: Atomic MemorySegment VarHandle operations fails for
 element layouts
In-Reply-To: <VAnyFRyCrqDIQiRcWdFweJOnOCgYh3MiFeoSDogEa7E=.fd6f6456-5969-46d9-8eeb-df267b8d295c@github.com>
References: <_PQ4wP4lk_STKwnSddD-5GgfsCheLbT_MR9zIyQyE78=.4ae37fdc-cf6e-46ea-8dbe-afcd1e710666@github.com>
 <VAnyFRyCrqDIQiRcWdFweJOnOCgYh3MiFeoSDogEa7E=.fd6f6456-5969-46d9-8eeb-df267b8d295c@github.com>
Message-ID: <gbZSyO_3whpWDyj05EntFpdSYe90fWo38SZN8AAasqw=.90dcbb88-e410-4b65-a914-bc0a16b55e02@github.com>

On Wed, 8 May 2024 15:32:27 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> * `x_handle` is really meant to provide access to a memory segment modelling (at least) one struct with layout `POINT_LAYOUT`. As such, the initial segment/offset combo should (a) be adequately aligned (according to `POINT_LAYOUT.byteAlignment()`) and have sufficient size (according to `POINT_LAYOUT.byteSize()`)

An example of this approach is attempted here:
https://github.com/openjdk/jdk/compare/master...mcimadamore:jdk:bad_align_segment_var_handle+size_checks?expand=1

Again, no significant performance regression is observed - the root layout checks dominate the value layout checks, and it seems like C2 is able to spot that.

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

PR Comment: https://git.openjdk.org/jdk/pull/19124#issuecomment-2100970680

From sgehwolf at openjdk.org  Wed May  8 16:55:02 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Wed, 8 May 2024 16:55:02 GMT
Subject: RFR: 8311302: Allow for jlinking a custom runtime without packaged
 modules being present [v25]
In-Reply-To: <EjF8YVHfHr9qm_5w3BLUSFhP-cQ_BR6Fcs_8-oKzpZo=.3cdf9de7-b75c-4848-93ed-173ac6060a3f@github.com>
References: <Z0DJ87uKPbjS6mvJIE_oG5m-RWsbERXsytSgV8Bmhdo=.f8723513-0ac6-4e85-9131-3c3924860c61@github.com>
 <2Hs5V_cOOhOtXxrKvM0ATWxJFO62xd3RtScyPEb5puI=.f16650ac-9812-40ed-a93c-a5dd4b396ad2@github.com>
 <EjF8YVHfHr9qm_5w3BLUSFhP-cQ_BR6Fcs_8-oKzpZo=.3cdf9de7-b75c-4848-93ed-173ac6060a3f@github.com>
Message-ID: <KTOkDEYVZI669nWUXytLJaT_3jfeEXnBtwe8O2wtCFE=.8105e0a0-a4f9-4924-b871-96189808ef93@github.com>

On Thu, 4 Apr 2024 20:56:55 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Severin Gehwolf has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - Use shorter name for the build tool
>>  - Review feedback from Erik J.
>>  - Remove dependency on CDS which isn't needed anymore
>
> Overall, I think the build system changes in the current revision of the patch look good, but please let me know for a deeper review when things have stabilized.

Thanks for the review, @magicus!

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

PR Comment: https://git.openjdk.org/jdk/pull/14787#issuecomment-2101006001

From redestad at openjdk.org  Wed May  8 17:01:05 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Wed, 8 May 2024 17:01:05 GMT
Subject: RFR: 8331932: Startup regressions in 23-b13 [v3]
In-Reply-To: <LgTAOs1QA0kgTbAfVQ_U2BcWAV7AHpcFXNE7eYB1BI8=.e77b81c1-73d4-4ff0-806f-eeda86d5cb16@github.com>
References: <LgTAOs1QA0kgTbAfVQ_U2BcWAV7AHpcFXNE7eYB1BI8=.e77b81c1-73d4-4ff0-806f-eeda86d5cb16@github.com>
Message-ID: <IZWN784obHXGnds2hBb8kMTEibMoOd1MzXX23jA3FAE=.38de61c7-083a-4d7b-a811-53592b6de366@github.com>

> A rather large startup regression was introduced in 23-b13 from [JDK-8309622](https://bugs.openjdk.org/browse/JDK-8309622). Some of that has been dealt with as enhancements such as [JDK-8330802](https://bugs.openjdk.org/browse/JDK-8330802), [JDK-8330595](https://bugs.openjdk.org/browse/JDK-8330595) and [JDK-8330681](https://bugs.openjdk.org/browse/JDK-8330681), which provide both point fixes and reduce initialization overhead of certain constructs more generally. The remaining issues stem from a set of lambdas added in code for `java.util.Locale` and `jdk.internal.util.BaseLocale` causing early bootstrapping of the lambda infrastructure and a bit of class generation.
> 
> While the remaining overheads are relatively small and borderline acceptable (< 2-3ms), I think it's still worth acting on them in this particular case since the amount of added bootstrapping overhead is dependent on which locale the system runs under, which complicates testing and comparisons due to relatively large differences in paths taken on different systems.

Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:

  Extract singleton for interning BaseLocale

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/19140/files
  - new: https://git.openjdk.org/jdk/pull/19140/files/73097159..d8594b31

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

  Stats: 21 lines in 1 file changed: 11 ins; 9 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/19140.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19140/head:pull/19140

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

From pavel.rappo at oracle.com  Wed May  8 17:04:09 2024
From: pavel.rappo at oracle.com (Pavel Rappo)
Date: Wed, 8 May 2024 17:04:09 +0000
Subject: RFR: 8305457: Implement java.io.IO [v3]
In-Reply-To: <CAL5bRt9qzLxh5+fWacXBbZvgfEtJgYvAwS+taSOQ=RFuZA9+RQ@mail.gmail.com>
References: <w2msiw_qaMEIJS3s9D4bg8pFbz5WIF0KdP6Mm-XFjLI=.85b2020b-8c46-4bac-8a69-4975b068f2ff@github.com>
 <wpwFGOp8E00csxi2Xb9b-02ZlkqnIZEpo8AqaMsQ4AM=.90acb47b-effc-4838-ba80-28938d4dc3c0@github.com>
 <C1Pvc8KO7vUGELLaqcXpepoK_MpvChaDcZqfroVICo0=.5ab8bef5-fa21-4618-a903-219d733045a0@github.com>
 <jWOXcC9B_23P_Px2zulnzRc38zL7zkslJM9nRtauHlk=.55e2ed38-59b7-4df1-be13-5d9a74672e26@github.com>
 <yZdbfOOkmceBWA5_ybn4g9cLTI-a40mvJ9eT6c_5YI4=.b5715149-8051-43bc-8556-1bc217bdfc39@github.com>
 <QOraUtvx4uq8mQagpLv6RQDsY-bD5YcvspNegJ9R9O4=.8b4a7dec-6445-4dc0-bbe3-a74385e00826@github.com>
 <CAL5bRt9qzLxh5+fWacXBbZvgfEtJgYvAwS+taSOQ=RFuZA9+RQ@mail.gmail.com>
Message-ID: <517973DA-99FE-455F-8F24-3C9C8F8707B3@oracle.com>

I don't remember it being considered, but I think it falls outside the scope of JEP 477 (emphasis mine):

> We achieve this effect by declaring a new top-level class in the java.io package named, simply, IO. It declares the above three static methods for **textual** I/O with the console, and nothing else.

java.io.IO is closely related to java.io.Console, which provides access to a terminal in a more or less canonical mode to read and write _strings_. While it might be useful for Console to separately provide access to a terminal in the raw mode, I'm not sure how often developers, let alone on-ramp developers, need it. In my experience, programming games, such as those you mentioned, is better introduced with GUI, where they have java.awt.event.KeyListener.

-Pavel

> On 8 May 2024, at 14:59, Olexandr Rotan <rotanolexandr842 at gmail.com> wrote:
> 
> Has it been considered to add a readKey() method to IO class? In my experience, it is pretty commonly used by beginners when they write things like console games (snake, catcher game etc.). I am aware there is System.in.read() method, but since we decided to promote some methods to separate methods in IO class, maybe readKey() or simple read() should also be considered?
> 
> On Wed, May 8, 2024 at 4:16?PM Pavel Rappo <prappo at openjdk.org> wrote:
> On Wed, 8 May 2024 10:31:59 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:
> 
> >> If we specify that, it would be very much unlike all other `Console` methods that are covered by this:
> >> 
> >>     * Unless otherwise specified, passing a {@code null} argument to any method
> >>     * in this class will cause a {@link NullPointerException} to be thrown.
> >
> > I haven't given it a try, but a brief look at the code suggests that if the console implementation backed by JLine gets used, then a `null` prompt may not generate a `NullPointerException` (since JLine appears to allow `null`) whereas if the internal JDK console implementation gets used then a `NullPointerException` will get thrown. If the expectation is to disallow a `null` prompt, then perhaps `Objects.requireNonNull(prompt)` before we hand off to the underlying console implementations might be required.
> 
> Good catch! `jdk.internal.org.jline.JdkConsoleProviderImpl.JdkConsoleImpl.readln(null)` does not throw `NullPointerException` (NPE), which it must. I'll fix the bug and add a test.
> 
> Speaking of NPE. The newly added `Console.print` and `Console.println` methods do not throw NPE if passed null. While that's how it should be, they don't specify that, so the class-level NPE clause applies:
> 
>     * Unless otherwise specified, passing a {@code null} argument to any method
>     * in this class will cause a {@link NullPointerException} to be thrown.
>     ...
>     public sealed class Console implements Flushable permits ProxyingConsole {
> 
> I'll fix that.
> 
> We should also specify NPE (or absence thereof) on methods of `IO`. Otherwise, this package clause applies:
> 
>     * Unless otherwise noted, passing a {@code null} argument to a constructor or
>     * method in any class or interface in this package will cause a
>     * {@code NullPointerException} to be thrown.
>     ...
>     package java.io;
> 
> @stuart-marks speaking of exceptions. Do we need to add explicit `@throws` tag to `IO` methods?
> 
>     @throws {@code IOError} if {@code System.console()} returns {@code null}
> 
> While it would make sense, it would also look superfluous: we already specify that error condition in the class comment and then in every method's main description. Do we need to add one more note on `IOError`?
> 
> -------------
> 
> PR Review Comment: https://git.openjdk.org/jdk/pull/19112#discussion_r1594013064


From naoto at openjdk.org  Wed May  8 17:07:07 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 8 May 2024 17:07:07 GMT
Subject: RFR: 8330276: Console methods with explicit Locale [v4]
In-Reply-To: <GT275XVwYlYL3PhYwOTQ_-HwKqp9QYUeIzEIeJKEwkQ=.9a7faf08-8637-45a3-97bd-fd58756a6711@github.com>
References: <GT275XVwYlYL3PhYwOTQ_-HwKqp9QYUeIzEIeJKEwkQ=.9a7faf08-8637-45a3-97bd-fd58756a6711@github.com>
Message-ID: <iQtfvg5kPN-UslgHMTJijnGHM09Be4DYgTyecp-KRqA=.bedab44c-7528-4b21-9c59-cd355cba10c1@github.com>

> Proposing new overloaded methods in `java.io.Console` class that explicitly take a `Locale` argument. Existing methods rely on the default locale, so the users won't be able to format their prompts/outputs in a certain locale explicitly.

Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:

  Removed JdkConsole.printf()

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18923/files
  - new: https://git.openjdk.org/jdk/pull/18923/files/29ff6063..2e83fc7b

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

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

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

From alanb at openjdk.org  Wed May  8 17:25:52 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 8 May 2024 17:25:52 GMT
Subject: RFR: 8331932: Startup regressions in 23-b13 [v3]
In-Reply-To: <IZWN784obHXGnds2hBb8kMTEibMoOd1MzXX23jA3FAE=.38de61c7-083a-4d7b-a811-53592b6de366@github.com>
References: <LgTAOs1QA0kgTbAfVQ_U2BcWAV7AHpcFXNE7eYB1BI8=.e77b81c1-73d4-4ff0-806f-eeda86d5cb16@github.com>
 <IZWN784obHXGnds2hBb8kMTEibMoOd1MzXX23jA3FAE=.38de61c7-083a-4d7b-a811-53592b6de366@github.com>
Message-ID: <HGaXXeRkid1pN9TysXNs15IIKlcXIJ13lM9qze1o1xE=.9229a483-0e00-48a1-a184-428786814f26@github.com>

On Wed, 8 May 2024 17:01:05 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> A rather large startup regression was introduced in 23-b13 from [JDK-8309622](https://bugs.openjdk.org/browse/JDK-8309622). Some of that has been dealt with as enhancements such as [JDK-8330802](https://bugs.openjdk.org/browse/JDK-8330802), [JDK-8330595](https://bugs.openjdk.org/browse/JDK-8330595) and [JDK-8330681](https://bugs.openjdk.org/browse/JDK-8330681), which provide both point fixes and reduce initialization overhead of certain constructs more generally. The remaining issues stem from a set of lambdas added in code for `java.util.Locale` and `jdk.internal.util.BaseLocale` causing early bootstrapping of the lambda infrastructure and a bit of class generation.
>> 
>> While the remaining overheads are relatively small and borderline acceptable (< 2-3ms), I think it's still worth acting on them in this particular case since the amount of added bootstrapping overhead is dependent on which locale the system runs under, which complicates testing and comparisons due to relatively large differences in paths taken on different systems.
>
> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Extract singleton for interning BaseLocale

src/java.base/share/classes/java/util/Locale.java line 1022:

> 1020:             exts = null;
> 1021:             hash = 0;
> 1022:         }

I don't think you need to add this constructor now.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19140#discussion_r1594376091

From redestad at openjdk.org  Wed May  8 17:30:22 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Wed, 8 May 2024 17:30:22 GMT
Subject: RFR: 8331932: Startup regressions in 23-b13 [v4]
In-Reply-To: <LgTAOs1QA0kgTbAfVQ_U2BcWAV7AHpcFXNE7eYB1BI8=.e77b81c1-73d4-4ff0-806f-eeda86d5cb16@github.com>
References: <LgTAOs1QA0kgTbAfVQ_U2BcWAV7AHpcFXNE7eYB1BI8=.e77b81c1-73d4-4ff0-806f-eeda86d5cb16@github.com>
Message-ID: <N_aub_OElJ5bLxaw6a-aYBWcMHTGS2vkdnKlTc_T46E=.300a895b-0d84-46d2-a8c6-351811a4cd49@github.com>

> A rather large startup regression was introduced in 23-b13 from [JDK-8309622](https://bugs.openjdk.org/browse/JDK-8309622). Some of that has been dealt with as enhancements such as [JDK-8330802](https://bugs.openjdk.org/browse/JDK-8330802), [JDK-8330595](https://bugs.openjdk.org/browse/JDK-8330595) and [JDK-8330681](https://bugs.openjdk.org/browse/JDK-8330681), which provide both point fixes and reduce initialization overhead of certain constructs more generally. The remaining issues stem from a set of lambdas added in code for `java.util.Locale` and `jdk.internal.util.BaseLocale` causing early bootstrapping of the lambda infrastructure and a bit of class generation.
> 
> While the remaining overheads are relatively small and borderline acceptable (< 2-3ms), I think it's still worth acting on them in this particular case since the amount of added bootstrapping overhead is dependent on which locale the system runs under, which complicates testing and comparisons due to relatively large differences in paths taken on different systems.

Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:

  Remove redundant constructor

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/19140/files
  - new: https://git.openjdk.org/jdk/pull/19140/files/d8594b31..819e3d47

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

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

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

From redestad at openjdk.org  Wed May  8 17:30:23 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Wed, 8 May 2024 17:30:23 GMT
Subject: RFR: 8331932: Startup regressions in 23-b13 [v3]
In-Reply-To: <HGaXXeRkid1pN9TysXNs15IIKlcXIJ13lM9qze1o1xE=.9229a483-0e00-48a1-a184-428786814f26@github.com>
References: <LgTAOs1QA0kgTbAfVQ_U2BcWAV7AHpcFXNE7eYB1BI8=.e77b81c1-73d4-4ff0-806f-eeda86d5cb16@github.com>
 <IZWN784obHXGnds2hBb8kMTEibMoOd1MzXX23jA3FAE=.38de61c7-083a-4d7b-a811-53592b6de366@github.com>
 <HGaXXeRkid1pN9TysXNs15IIKlcXIJ13lM9qze1o1xE=.9229a483-0e00-48a1-a184-428786814f26@github.com>
Message-ID: <7g2lCnqevcrvW5u6LD6DlpBdnry5d6EFgIPXCjpEsMs=.72dbd536-2128-44a6-ae86-cfdf15133f6f@github.com>

On Wed, 8 May 2024 17:23:25 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Extract singleton for interning BaseLocale
>
> src/java.base/share/classes/java/util/Locale.java line 1022:
> 
>> 1020:             exts = null;
>> 1021:             hash = 0;
>> 1022:         }
> 
> I don't think you need to add this constructor now.

Was certain I had removed it.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19140#discussion_r1594382318

From alanb at openjdk.org  Wed May  8 17:59:52 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 8 May 2024 17:59:52 GMT
Subject: RFR: 8331932: Startup regressions in 23-b13 [v4]
In-Reply-To: <N_aub_OElJ5bLxaw6a-aYBWcMHTGS2vkdnKlTc_T46E=.300a895b-0d84-46d2-a8c6-351811a4cd49@github.com>
References: <LgTAOs1QA0kgTbAfVQ_U2BcWAV7AHpcFXNE7eYB1BI8=.e77b81c1-73d4-4ff0-806f-eeda86d5cb16@github.com>
 <N_aub_OElJ5bLxaw6a-aYBWcMHTGS2vkdnKlTc_T46E=.300a895b-0d84-46d2-a8c6-351811a4cd49@github.com>
Message-ID: <Wad7aZ13XzfQG12NS1ZmuBGYIKiwHBArPrFsEfa3kzI=.53bf9b43-ebec-4e87-a657-45f4d4d53989@github.com>

On Wed, 8 May 2024 17:30:22 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> A rather large startup regression was introduced in 23-b13 from [JDK-8309622](https://bugs.openjdk.org/browse/JDK-8309622). Some of that has been dealt with as enhancements such as [JDK-8330802](https://bugs.openjdk.org/browse/JDK-8330802), [JDK-8330595](https://bugs.openjdk.org/browse/JDK-8330595) and [JDK-8330681](https://bugs.openjdk.org/browse/JDK-8330681), which provide both point fixes and reduce initialization overhead of certain constructs more generally. The remaining issues stem from a set of lambdas added in code for `java.util.Locale` and `jdk.internal.util.BaseLocale` causing early bootstrapping of the lambda infrastructure and a bit of class generation.
>> 
>> While the remaining overheads are relatively small and borderline acceptable (< 2-3ms), I think it's still worth acting on them in this particular case since the amount of added bootstrapping overhead is dependent on which locale the system runs under, which complicates testing and comparisons due to relatively large differences in paths taken on different systems.
>
> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove redundant constructor

Marked as reviewed by alanb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/19140#pullrequestreview-2046311563

From naoto at openjdk.org  Wed May  8 17:59:53 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 8 May 2024 17:59:53 GMT
Subject: RFR: 8331932: Startup regressions in 23-b13 [v4]
In-Reply-To: <N_aub_OElJ5bLxaw6a-aYBWcMHTGS2vkdnKlTc_T46E=.300a895b-0d84-46d2-a8c6-351811a4cd49@github.com>
References: <LgTAOs1QA0kgTbAfVQ_U2BcWAV7AHpcFXNE7eYB1BI8=.e77b81c1-73d4-4ff0-806f-eeda86d5cb16@github.com>
 <N_aub_OElJ5bLxaw6a-aYBWcMHTGS2vkdnKlTc_T46E=.300a895b-0d84-46d2-a8c6-351811a4cd49@github.com>
Message-ID: <aJQfrFkja-6ClWBVkcWV5VwT7_TRq2staAK1emmtk0Y=.5cdcb910-eb7e-4d26-bcbc-5732b3d5593e@github.com>

On Wed, 8 May 2024 17:30:22 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> A rather large startup regression was introduced in 23-b13 from [JDK-8309622](https://bugs.openjdk.org/browse/JDK-8309622). Some of that has been dealt with as enhancements such as [JDK-8330802](https://bugs.openjdk.org/browse/JDK-8330802), [JDK-8330595](https://bugs.openjdk.org/browse/JDK-8330595) and [JDK-8330681](https://bugs.openjdk.org/browse/JDK-8330681), which provide both point fixes and reduce initialization overhead of certain constructs more generally. The remaining issues stem from a set of lambdas added in code for `java.util.Locale` and `jdk.internal.util.BaseLocale` causing early bootstrapping of the lambda infrastructure and a bit of class generation.
>> 
>> While the remaining overheads are relatively small and borderline acceptable (< 2-3ms), I think it's still worth acting on them in this particular case since the amount of added bootstrapping overhead is dependent on which locale the system runs under, which complicates testing and comparisons due to relatively large differences in paths taken on different systems.
>
> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove redundant constructor

Thanks for fixing this!

src/java.base/share/classes/sun/util/locale/BaseLocale.java line 96:

> 94:     // Interned BaseLocale cache
> 95:     private static final ReferencedKeySet<BaseLocale> CACHE =
> 96:             ReferencedKeySet.create(true, ReferencedKeySet.concurrentHashMapSupplier());

Should this supplier be in `BaseLocale` class? Otherwise `ReferencedKeySet` may end up with static suppliers for each map type?

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

PR Review: https://git.openjdk.org/jdk/pull/19140#pullrequestreview-2046313019
PR Review Comment: https://git.openjdk.org/jdk/pull/19140#discussion_r1594429353

From redestad at openjdk.org  Wed May  8 18:10:53 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Wed, 8 May 2024 18:10:53 GMT
Subject: RFR: 8331932: Startup regressions in 23-b13 [v4]
In-Reply-To: <aJQfrFkja-6ClWBVkcWV5VwT7_TRq2staAK1emmtk0Y=.5cdcb910-eb7e-4d26-bcbc-5732b3d5593e@github.com>
References: <LgTAOs1QA0kgTbAfVQ_U2BcWAV7AHpcFXNE7eYB1BI8=.e77b81c1-73d4-4ff0-806f-eeda86d5cb16@github.com>
 <N_aub_OElJ5bLxaw6a-aYBWcMHTGS2vkdnKlTc_T46E=.300a895b-0d84-46d2-a8c6-351811a4cd49@github.com>
 <aJQfrFkja-6ClWBVkcWV5VwT7_TRq2staAK1emmtk0Y=.5cdcb910-eb7e-4d26-bcbc-5732b3d5593e@github.com>
Message-ID: <0UjysePhuY8CzhKExsO86xh5O8fv79RZzvzq_ebM15Q=.95e2140d-3273-4d1b-bc65-98393bd95944@github.com>

On Wed, 8 May 2024 17:57:22 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove redundant constructor
>
> src/java.base/share/classes/sun/util/locale/BaseLocale.java line 96:
> 
>> 94:     // Interned BaseLocale cache
>> 95:     private static final ReferencedKeySet<BaseLocale> CACHE =
>> 96:             ReferencedKeySet.create(true, ReferencedKeySet.concurrentHashMapSupplier());
> 
> Should this supplier be in `BaseLocale` class? Otherwise `ReferencedKeySet` may end up with static suppliers for each map type?

Maybe, though I think most potential uses of `ReferenceKeySet/-Map` will want to be using a plain `CHM` as the backing store, so keeping these next to their respective `create` methods will encourage sharing.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19140#discussion_r1594444407

From naoto at openjdk.org  Wed May  8 18:17:52 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 8 May 2024 18:17:52 GMT
Subject: RFR: 8331932: Startup regressions in 23-b13 [v4]
In-Reply-To: <N_aub_OElJ5bLxaw6a-aYBWcMHTGS2vkdnKlTc_T46E=.300a895b-0d84-46d2-a8c6-351811a4cd49@github.com>
References: <LgTAOs1QA0kgTbAfVQ_U2BcWAV7AHpcFXNE7eYB1BI8=.e77b81c1-73d4-4ff0-806f-eeda86d5cb16@github.com>
 <N_aub_OElJ5bLxaw6a-aYBWcMHTGS2vkdnKlTc_T46E=.300a895b-0d84-46d2-a8c6-351811a4cd49@github.com>
Message-ID: <PP8_KOXxC8cyARHYC7qxD8sfCAW4iT_BqWvOyUO3G2w=.a5bda3fc-161b-47e3-82a3-7b66c64dd3ac@github.com>

On Wed, 8 May 2024 17:30:22 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> A rather large startup regression was introduced in 23-b13 from [JDK-8309622](https://bugs.openjdk.org/browse/JDK-8309622). Some of that has been dealt with as enhancements such as [JDK-8330802](https://bugs.openjdk.org/browse/JDK-8330802), [JDK-8330595](https://bugs.openjdk.org/browse/JDK-8330595) and [JDK-8330681](https://bugs.openjdk.org/browse/JDK-8330681), which provide both point fixes and reduce initialization overhead of certain constructs more generally. The remaining issues stem from a set of lambdas added in code for `java.util.Locale` and `jdk.internal.util.BaseLocale` causing early bootstrapping of the lambda infrastructure and a bit of class generation.
>> 
>> While the remaining overheads are relatively small and borderline acceptable (< 2-3ms), I think it's still worth acting on them in this particular case since the amount of added bootstrapping overhead is dependent on which locale the system runs under, which complicates testing and comparisons due to relatively large differences in paths taken on different systems.
>
> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove redundant constructor

LGTM

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

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19140#pullrequestreview-2046346164

From prappo at openjdk.org  Wed May  8 18:28:52 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Wed, 8 May 2024 18:28:52 GMT
Subject: RFR: 8305457: Implement java.io.IO [v3]
In-Reply-To: <kXr9EdR3dWGNLqQRenj1LcwWTChuqmc6gA7r04R9nAo=.76e57556-5210-45ae-8e13-755a604c0c49@github.com>
References: <w2msiw_qaMEIJS3s9D4bg8pFbz5WIF0KdP6Mm-XFjLI=.85b2020b-8c46-4bac-8a69-4975b068f2ff@github.com>
 <wpwFGOp8E00csxi2Xb9b-02ZlkqnIZEpo8AqaMsQ4AM=.90acb47b-effc-4838-ba80-28938d4dc3c0@github.com>
 <C1Pvc8KO7vUGELLaqcXpepoK_MpvChaDcZqfroVICo0=.5ab8bef5-fa21-4618-a903-219d733045a0@github.com>
 <jWOXcC9B_23P_Px2zulnzRc38zL7zkslJM9nRtauHlk=.55e2ed38-59b7-4df1-be13-5d9a74672e26@github.com>
 <yZdbfOOkmceBWA5_ybn4g9cLTI-a40mvJ9eT6c_5YI4=.b5715149-8051-43bc-8556-1bc217bdfc39@github.com>
 <QOraUtvx4uq8mQagpLv6RQDsY-bD5YcvspNegJ9R9O4=.8b4a7dec-6445-4dc0-bbe3-a74385e00826@github.com>
 <kXr9EdR3dWGNLqQRenj1LcwWTChuqmc6gA7r04R9nAo=.76e57556-5210-45ae-8e13-755a604c0c49@github.com>
Message-ID: <IY4TieJPjmWSdKQaPXzSa-Ud4kjq1_fjjQBncwTsiGg=.fc991711-78da-45b6-bd4b-0bc8d8284eb7@github.com>

On Wed, 8 May 2024 16:06:29 GMT, Stuart Marks <smarks at openjdk.org> wrote:

> Most of these are defined in terms of `String.valueOf(Object)` which if passed a null reference will return the String object containing `null`. So no, I don't think NPE should be thrown. It might be worth mentioning this explicitly somewhere though.

Right, in our current model, `Console.readln(prompt)` can be reduced to `Console.print(prompt)` followed by actual reading. `Console.print(prompt)` can in turn be reduced to printing the result of `String.valueOf((Object) prompt)`, which is a string "null".

The above reduction means that `Console.readln(null)` will not throw NPE. Now, what I'm asking if that's what we really want.

With `Console.println(null)` and `Console.print(null)` not throwing NPE makes sense. However, with `Console.readln(null)` it might not. After all, we ask for a **`String`** prompt, not an `Object` prompt. All other methods of `Console` that accept `String`, throw NPE if that string is null.

One more consideration. Whatever the behaviour we choose for `Console.readln(null)`, we should choose the same behaviour for `IO.readln(null)`. Otherwise, it would be a constant source of unpleasantly surprising inconsistency.

Thoughts?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19112#discussion_r1594464589

From liach at openjdk.org  Wed May  8 18:34:52 2024
From: liach at openjdk.org (Chen Liang)
Date: Wed, 8 May 2024 18:34:52 GMT
Subject: RFR: 8331932: Startup regressions in 23-b13 [v4]
In-Reply-To: <N_aub_OElJ5bLxaw6a-aYBWcMHTGS2vkdnKlTc_T46E=.300a895b-0d84-46d2-a8c6-351811a4cd49@github.com>
References: <LgTAOs1QA0kgTbAfVQ_U2BcWAV7AHpcFXNE7eYB1BI8=.e77b81c1-73d4-4ff0-806f-eeda86d5cb16@github.com>
 <N_aub_OElJ5bLxaw6a-aYBWcMHTGS2vkdnKlTc_T46E=.300a895b-0d84-46d2-a8c6-351811a4cd49@github.com>
Message-ID: <s2juWO6qkHZkklzu7f67ZI38E5X8gxgNef0HamoaMTM=.fd346caf-0291-4d09-98dc-fe6165c2ea3e@github.com>

On Wed, 8 May 2024 17:30:22 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> A rather large startup regression was introduced in 23-b13 from [JDK-8309622](https://bugs.openjdk.org/browse/JDK-8309622). Some of that has been dealt with as enhancements such as [JDK-8330802](https://bugs.openjdk.org/browse/JDK-8330802), [JDK-8330595](https://bugs.openjdk.org/browse/JDK-8330595) and [JDK-8330681](https://bugs.openjdk.org/browse/JDK-8330681), which provide both point fixes and reduce initialization overhead of certain constructs more generally. The remaining issues stem from a set of lambdas added in code for `java.util.Locale` and `jdk.internal.util.BaseLocale` causing early bootstrapping of the lambda infrastructure and a bit of class generation.
>> 
>> While the remaining overheads are relatively small and borderline acceptable (< 2-3ms), I think it's still worth acting on them in this particular case since the amount of added bootstrapping overhead is dependent on which locale the system runs under, which complicates testing and comparisons due to relatively large differences in paths taken on different systems.
>
> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove redundant constructor

src/java.base/share/classes/jdk/internal/util/ReferencedKeySet.java line 84:

> 82:      */
> 83:     public static <E> Supplier<Map<ReferenceKey<E>, ReferenceKey<E>>> concurrentHashMapSupplier() {
> 84:         return new Supplier<>() {

Can this just `return ReferencedKeyMap.concurrentHashMapSupplier();`?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19140#discussion_r1594474286

From prappo at openjdk.org  Wed May  8 18:43:41 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Wed, 8 May 2024 18:43:41 GMT
Subject: RFR: 8305457: Implement java.io.IO [v4]
In-Reply-To: <w2msiw_qaMEIJS3s9D4bg8pFbz5WIF0KdP6Mm-XFjLI=.85b2020b-8c46-4bac-8a69-4975b068f2ff@github.com>
References: <w2msiw_qaMEIJS3s9D4bg8pFbz5WIF0KdP6Mm-XFjLI=.85b2020b-8c46-4bac-8a69-4975b068f2ff@github.com>
Message-ID: <wqdl7WD8hTx1IlgxXylCd053e_MrKw0zrHKC2fwUusM=.b5072cb6-85b7-46c8-9ebd-119a63ec029b@github.com>

> Please review this PR which introduces the `java.io.IO` top-level class and three methods to `java.io.Console` for [Implicitly Declared Classes and Instance Main Methods (Third Preview)].
> 
> This PR has been obtained as `git merge --squash` of a now obsolete [draft PR].
> 
> [Implicitly Declared Classes and Instance Main Methods (Third Preview)]: https://bugs.openjdk.org/browse/JDK-8323335
> [draft PR]: https://github.com/openjdk/jdk/pull/18921

Pavel Rappo has updated the pull request incrementally with two additional commits since the last revision:

 - Specify charset of java.io.IO
 - Use system-dependent line separator for Console.println

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/19112/files
  - new: https://git.openjdk.org/jdk/pull/19112/files/73a20a7c..80eacf8c

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

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

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

From duke at openjdk.org  Wed May  8 19:15:55 2024
From: duke at openjdk.org (ExE Boss)
Date: Wed, 8 May 2024 19:15:55 GMT
Subject: RFR: 8331724: Refactor j.l.constant implementation to internal
 package [v5]
In-Reply-To: <8sn6v-wNyReo8y3huV8WQOC9QPf33IKTM0sXlEnif0Q=.ad224ff0-cb0f-44b1-9e02-d2fc275c3815@github.com>
References: <_GPUF9d1E6eBKRxP6bEEqA3LSKRJe2GwCRTfVYbDwFU=.cb482785-e7c4-45f7-bd3a-cd32d466a2cb@github.com>
 <8sn6v-wNyReo8y3huV8WQOC9QPf33IKTM0sXlEnif0Q=.ad224ff0-cb0f-44b1-9e02-d2fc275c3815@github.com>
Message-ID: <sPp93hzSoFhhqt12VGb9u2f-7PLxZc41v1-2vCZZ0gA=.b59e9e3a-0b30-46e6-ac7a-13f6ba771fc8@github.com>

On Wed, 8 May 2024 10:42:27 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> This PR suggests refactoring the implementation classes of java.lang.constant into a new package jdk.internal.constant to enable sharing some trusted static factory methods with users elsewhere in java.base, such as java.lang.invoke and java.lang.classfile. The refactoring also adds some "trusted" methods for use when input is pre-validated, and makes use of them where applicable in the current implementation. There are more changes in the pipeline which will be folded into #17108 or PR'ed once that is integrated. 
>> 
>> There are two optimizations mixed up here. One in `MethodTypeDesc.ofDescriptor`:
>> 
>> Name                                                             (descString) Cnt     Base     Error      Test   Error  Unit  Change
>> MethodTypeDescFactories.ofDescriptor  (Ljava/lang/Object;Ljava/lang/String;)I   6  138,371 ?   0,767   136,939 ? 1,126 ns/op   1,01x (p = 0,000*)
>> MethodTypeDescFactories.ofDescriptor                                      ()V   6   10,528 ?   2,495     4,110 ? 0,047 ns/op   2,56x (p = 0,000*)
>> MethodTypeDescFactories.ofDescriptor ([IJLjava/lang/String;Z)Ljava/util/List;   6  209,390 ?   4,583   196,175 ? 3,211 ns/op   1,07x (p = 0,000*)
>> MethodTypeDescFactories.ofDescriptor                    ()[Ljava/lang/String;   6   36,039 ?   8,684    20,794 ? 1,110 ns/op   1,73x (p = 0,000*)
>> MethodTypeDescFactories.ofDescriptor                                 (..IIJ)V   6  279,139 ?   6,248   187,934 ? 0,857 ns/op   1,49x (p = 0,000*)
>> MethodTypeDescFactories.ofDescriptor                 (.....................).   6 2174,387 ? 132,879  1150,652 ? 3,158 ns/op   1,89x (p = 0,000*)
>>   * = significant
>> 
>> 
>> The other in `ClassDesc::nested`, where to get rid of a simple static method in `ConstantUtils` I ended up speeding up and simplifying the public factory method:
>> 
>> Name                                      Cnt    Base     Error    Test   Error  Unit  Change
>> ClassDescFactories.ReferenceOnly.ofNested   6 209,853 ? 132,525  22,017 ? 0,573 ns/op   9,53x (p = 0,000*)
>>   * = significant
>> 
>> 
>> The optimizations could be split out and PRd independently, but I think they are simple enough to include in this refactoring.
>
> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Refactor to further avoid re-validating arguments

src/java.base/share/classes/jdk/internal/constant/MethodTypeDescImpl.java line 179:

> 177: 
> 178:         for (ClassDesc param : paramTypes)
> 179:             validateArgument(param);

This?check should be?performed as?part of?copying `paramTypes` to?`newArgs` to?avoid TOC/TOU?issues, e.g.:

@Override
public MethodTypeDesc insertParameterTypes(int pos, ClassDesc... paramTypes) {
	if (pos < 0 || pos > argTypes.length)
		throw new IndexOutOfBoundsException(pos);

	ClassDesc[] newArgs = new ClassDesc[argTypes.length + paramTypes.length];
	if (pos > 0) {
		System.arraycopy(argTypes, 0, newArgs, 0, pos);
	}
	for (int i = 0; i < paramTypes.length; i++) {
		newArgs[pos + i] = validateArgument(paramTypes[i]);
	}
	if (pos < argTypes.length) {
		System.arraycopy(argTypes, pos, newArgs, pos + paramTypes.length, argTypes.length - pos);
	}
	return ofValidated(returnType, newArgs);
}


See?also:
https://github.com/openjdk/jdk/blob/230fac80f25e9608006c8928a8a7708bf13a818c/src/java.base/share/classes/java/util/ImmutableCollections.java#L186-L195

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19105#discussion_r1594510390

From smarks at openjdk.org  Wed May  8 19:42:52 2024
From: smarks at openjdk.org (Stuart Marks)
Date: Wed, 8 May 2024 19:42:52 GMT
Subject: RFR: 8305457: Implement java.io.IO [v3]
In-Reply-To: <IY4TieJPjmWSdKQaPXzSa-Ud4kjq1_fjjQBncwTsiGg=.fc991711-78da-45b6-bd4b-0bc8d8284eb7@github.com>
References: <w2msiw_qaMEIJS3s9D4bg8pFbz5WIF0KdP6Mm-XFjLI=.85b2020b-8c46-4bac-8a69-4975b068f2ff@github.com>
 <wpwFGOp8E00csxi2Xb9b-02ZlkqnIZEpo8AqaMsQ4AM=.90acb47b-effc-4838-ba80-28938d4dc3c0@github.com>
 <C1Pvc8KO7vUGELLaqcXpepoK_MpvChaDcZqfroVICo0=.5ab8bef5-fa21-4618-a903-219d733045a0@github.com>
 <jWOXcC9B_23P_Px2zulnzRc38zL7zkslJM9nRtauHlk=.55e2ed38-59b7-4df1-be13-5d9a74672e26@github.com>
 <yZdbfOOkmceBWA5_ybn4g9cLTI-a40mvJ9eT6c_5YI4=.b5715149-8051-43bc-8556-1bc217bdfc39@github.com>
 <QOraUtvx4uq8mQagpLv6RQDsY-bD5YcvspNegJ9R9O4=.8b4a7dec-6445-4dc0-bbe3-a74385e00826@github.com>
 <kXr9EdR3dWGNLqQRenj1LcwWTChuqmc6gA7r04R9nAo=.76e57556-5210-45ae-8e13-755a604c0c49@github.com>
 <IY4TieJPjmWSdKQaPXzSa-Ud4kjq1_fjjQBncwTsiGg=.fc991711-78da-45b6-bd4b-0bc8d8284eb7@github.com>
Message-ID: <bX9rOfeN_f5pV3Yv_uCCSDYoWnjzsdWhvas5MyUqx-A=.3e0697c9-278d-45ea-896e-6e4c89d8d839@github.com>

On Wed, 8 May 2024 18:25:50 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Most of these are defined in terms of `String.valueOf(Object)` which if passed a null reference will return the String object containing `null`. So no, I don't think NPE should be thrown. It might be worth mentioning this explicitly somewhere though.
>
>> Most of these are defined in terms of `String.valueOf(Object)` which if passed a null reference will return the String object containing `null`. So no, I don't think NPE should be thrown. It might be worth mentioning this explicitly somewhere though.
> 
> Right, in our current model, `Console.readln(prompt)` can be reduced to `Console.print(prompt)` followed by actual reading. `Console.print(prompt)` can in turn be reduced to printing the result of `String.valueOf((Object) prompt)`, which is a string "null".
> 
> The above reduction means that `Console.readln(null)` will not throw NPE. Now, what I'm asking if that's what we really want.
> 
> With `Console.println(null)` and `Console.print(null)` not throwing NPE makes sense. However, with `Console.readln(null)` it might not. After all, we ask for a **`String`** prompt, not an `Object` prompt. All other methods of `Console` that accept `String`, throw NPE if that string is null.
> 
> One more consideration. Whatever the behaviour we choose for `Console.readln(null)`, we should choose the same behaviour for `IO.readln(null)`. Otherwise, it would be a constant source of unpleasantly surprising inconsistency.
> 
> Thoughts?

A fair question, whether to treat `readln` differently because it takes a String argument instead of an Object.

I guess I'd like to see a scheme like the following:

    String s = cons.readln(prompt);

is effectively the same as

    cons.print(prompt);
    cons.flush();
    String s = cons.readLine(); // note no-arg readLine() method

In other words, define `readln` to behave "as if" the other methods were called. This would end up with a null prompt argument printing "null" and not throwing NPE.

This is internally consistent, at least. Beginning programmers will eventually learn that using null will lead to NPE. It might make things easier if NPEs were kept out of this little corner of the library. That's just my guess though.

Also, recall that `String.valueOf((Object) null)` and `String.valueOf((String) null)` both result in "null". But if one were to write `String.valueOf(null)` that throws NPE, because that selects the `valueOf(char[])` overload. That's kind of the outlier. Note further that the built-in `+` string concatenation operator will also convert null references to "null".

Personally I've always hated that string conversions of null in Java often result in "null" but it's baked into the system fairly deeply, so I think we should stick with it.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19112#discussion_r1594542505

From redestad at openjdk.org  Wed May  8 20:17:18 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Wed, 8 May 2024 20:17:18 GMT
Subject: RFR: 8331724: Refactor j.l.constant implementation to internal
 package [v6]
In-Reply-To: <_GPUF9d1E6eBKRxP6bEEqA3LSKRJe2GwCRTfVYbDwFU=.cb482785-e7c4-45f7-bd3a-cd32d466a2cb@github.com>
References: <_GPUF9d1E6eBKRxP6bEEqA3LSKRJe2GwCRTfVYbDwFU=.cb482785-e7c4-45f7-bd3a-cd32d466a2cb@github.com>
Message-ID: <-XO7o4O_fosLQ-I2ZH6WROkMtCJ_G978GPfEma9QFEU=.916fb3c0-6599-416a-bfb1-e3329f262928@github.com>

> This PR suggests refactoring the implementation classes of java.lang.constant into a new package jdk.internal.constant to enable sharing some trusted static factory methods with users elsewhere in java.base, such as java.lang.invoke and java.lang.classfile. The refactoring also adds some "trusted" methods for use when input is pre-validated, and makes use of them where applicable in the current implementation. There are more changes in the pipeline which will be folded into #17108 or PR'ed once that is integrated. 
> 
> There are two optimizations mixed up here. One in `MethodTypeDesc.ofDescriptor`:
> 
> Name                                                             (descString) Cnt     Base     Error      Test   Error  Unit  Change
> MethodTypeDescFactories.ofDescriptor  (Ljava/lang/Object;Ljava/lang/String;)I   6  138,371 ?   0,767   136,939 ? 1,126 ns/op   1,01x (p = 0,000*)
> MethodTypeDescFactories.ofDescriptor                                      ()V   6   10,528 ?   2,495     4,110 ? 0,047 ns/op   2,56x (p = 0,000*)
> MethodTypeDescFactories.ofDescriptor ([IJLjava/lang/String;Z)Ljava/util/List;   6  209,390 ?   4,583   196,175 ? 3,211 ns/op   1,07x (p = 0,000*)
> MethodTypeDescFactories.ofDescriptor                    ()[Ljava/lang/String;   6   36,039 ?   8,684    20,794 ? 1,110 ns/op   1,73x (p = 0,000*)
> MethodTypeDescFactories.ofDescriptor                                 (..IIJ)V   6  279,139 ?   6,248   187,934 ? 0,857 ns/op   1,49x (p = 0,000*)
> MethodTypeDescFactories.ofDescriptor                 (.....................).   6 2174,387 ? 132,879  1150,652 ? 3,158 ns/op   1,89x (p = 0,000*)
>   * = significant
> 
> 
> The other in `ClassDesc::nested`, where to get rid of a simple static method in `ConstantUtils` I ended up speeding up and simplifying the public factory method:
> 
> Name                                      Cnt    Base     Error    Test   Error  Unit  Change
> ClassDescFactories.ReferenceOnly.ofNested   6 209,853 ? 132,525  22,017 ? 0,573 ns/op   9,53x (p = 0,000*)
>   * = significant
> 
> 
> The optimizations could be split out and PRd independently, but I think they are simple enough to include in this refactoring.

Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:

  Validate after copying to avoid TOCTOU

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/19105/files
  - new: https://git.openjdk.org/jdk/pull/19105/files/eb23cf51..b21d3e60

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

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

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

From redestad at openjdk.org  Wed May  8 20:20:53 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Wed, 8 May 2024 20:20:53 GMT
Subject: RFR: 8331724: Refactor j.l.constant implementation to internal
 package [v5]
In-Reply-To: <sPp93hzSoFhhqt12VGb9u2f-7PLxZc41v1-2vCZZ0gA=.b59e9e3a-0b30-46e6-ac7a-13f6ba771fc8@github.com>
References: <_GPUF9d1E6eBKRxP6bEEqA3LSKRJe2GwCRTfVYbDwFU=.cb482785-e7c4-45f7-bd3a-cd32d466a2cb@github.com>
 <8sn6v-wNyReo8y3huV8WQOC9QPf33IKTM0sXlEnif0Q=.ad224ff0-cb0f-44b1-9e02-d2fc275c3815@github.com>
 <sPp93hzSoFhhqt12VGb9u2f-7PLxZc41v1-2vCZZ0gA=.b59e9e3a-0b30-46e6-ac7a-13f6ba771fc8@github.com>
Message-ID: <m0ftvvm5opNQ53WEqQINScryNTKcxX02P8u-9FSVifQ=.e2526bb4-080c-41fc-8eec-93f4b6c6fad3@github.com>

On Wed, 8 May 2024 19:06:35 GMT, ExE Boss <duke at openjdk.org> wrote:

>> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Refactor to further avoid re-validating arguments
>
> src/java.base/share/classes/jdk/internal/constant/MethodTypeDescImpl.java line 179:
> 
>> 177: 
>> 178:         for (ClassDesc param : paramTypes)
>> 179:             validateArgument(param);
> 
> This?check should be?performed as?part of?copying `paramTypes` to?`newArgs` to?avoid TOC/TOU?issues, e.g.:
> 
> @Override
> public MethodTypeDesc insertParameterTypes(int pos, ClassDesc... paramTypes) {
> 	if (pos < 0 || pos > argTypes.length)
> 		throw new IndexOutOfBoundsException(pos);
> 
> 	ClassDesc[] newArgs = new ClassDesc[argTypes.length + paramTypes.length];
> 	if (pos > 0) {
> 		System.arraycopy(argTypes, 0, newArgs, 0, pos);
> 	}
> 	for (int i = 0; i < paramTypes.length; i++) {
> 		newArgs[pos + i] = validateArgument(paramTypes[i]);
> 	}
> 	if (pos < argTypes.length) {
> 		System.arraycopy(argTypes, pos, newArgs, pos + paramTypes.length, argTypes.length - pos);
> 	}
> 	return ofValidated(returnType, newArgs);
> }
> 
> 
> See?also:
> https://github.com/openjdk/jdk/blob/230fac80f25e9608006c8928a8a7708bf13a818c/src/java.base/share/classes/java/util/ImmutableCollections.java#L186-L195

Nice catch! I conservatively just move the validation loop after to keep the arraycopying.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19105#discussion_r1594579344

From naoto at openjdk.org  Wed May  8 20:27:15 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 8 May 2024 20:27:15 GMT
Subject: RFR: 8331866: Add warnings for locale data dependence
Message-ID: <d1V8q3oaeh-cPvR_IE22WAHhoqrc1TXZMdEtIhxCLvM=.af6edbc8-49c1-4125-930d-42580dcb40c3@github.com>

In order to enlighten users to not depend on a particular version of the locale data, putting a note into the JDK vs. CLDR version chart would be appropriate.

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

Commit messages:
 - initial commit

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

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

From liach at openjdk.org  Wed May  8 20:28:00 2024
From: liach at openjdk.org (Chen Liang)
Date: Wed, 8 May 2024 20:28:00 GMT
Subject: RFR: 8331724: Refactor j.l.constant implementation to internal
 package [v6]
In-Reply-To: <-XO7o4O_fosLQ-I2ZH6WROkMtCJ_G978GPfEma9QFEU=.916fb3c0-6599-416a-bfb1-e3329f262928@github.com>
References: <_GPUF9d1E6eBKRxP6bEEqA3LSKRJe2GwCRTfVYbDwFU=.cb482785-e7c4-45f7-bd3a-cd32d466a2cb@github.com>
 <-XO7o4O_fosLQ-I2ZH6WROkMtCJ_G978GPfEma9QFEU=.916fb3c0-6599-416a-bfb1-e3329f262928@github.com>
Message-ID: <8C398cJEhdpAgSqDxAg_Fbtti0WZDbak3DeD3nmsv-w=.7c8b6aea-6a01-4a8b-832d-47b5a69bdbce@github.com>

On Wed, 8 May 2024 20:17:18 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> This PR suggests refactoring the implementation classes of java.lang.constant into a new package jdk.internal.constant to enable sharing some trusted static factory methods with users elsewhere in java.base, such as java.lang.invoke and java.lang.classfile. The refactoring also adds some "trusted" methods for use when input is pre-validated, and makes use of them where applicable in the current implementation. There are more changes in the pipeline which will be folded into #17108 or PR'ed once that is integrated. 
>> 
>> There are two optimizations mixed up here. One in `MethodTypeDesc.ofDescriptor`:
>> 
>> Name                                                             (descString) Cnt     Base     Error      Test   Error  Unit  Change
>> MethodTypeDescFactories.ofDescriptor  (Ljava/lang/Object;Ljava/lang/String;)I   6  138,371 ?   0,767   136,939 ? 1,126 ns/op   1,01x (p = 0,000*)
>> MethodTypeDescFactories.ofDescriptor                                      ()V   6   10,528 ?   2,495     4,110 ? 0,047 ns/op   2,56x (p = 0,000*)
>> MethodTypeDescFactories.ofDescriptor ([IJLjava/lang/String;Z)Ljava/util/List;   6  209,390 ?   4,583   196,175 ? 3,211 ns/op   1,07x (p = 0,000*)
>> MethodTypeDescFactories.ofDescriptor                    ()[Ljava/lang/String;   6   36,039 ?   8,684    20,794 ? 1,110 ns/op   1,73x (p = 0,000*)
>> MethodTypeDescFactories.ofDescriptor                                 (..IIJ)V   6  279,139 ?   6,248   187,934 ? 0,857 ns/op   1,49x (p = 0,000*)
>> MethodTypeDescFactories.ofDescriptor                 (.....................).   6 2174,387 ? 132,879  1150,652 ? 3,158 ns/op   1,89x (p = 0,000*)
>>   * = significant
>> 
>> 
>> The other in `ClassDesc::nested`, where to get rid of a simple static method in `ConstantUtils` I ended up speeding up and simplifying the public factory method:
>> 
>> Name                                      Cnt    Base     Error    Test   Error  Unit  Change
>> ClassDescFactories.ReferenceOnly.ofNested   6 209,853 ? 132,525  22,017 ? 0,573 ns/op   9,53x (p = 0,000*)
>>   * = significant
>> 
>> 
>> The optimizations could be split out and PRd independently, but I think they are simple enough to include in this refactoring.
>
> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Validate after copying to avoid TOCTOU

This patch allows us to merge parsing logic for invoke, constant, and classfile in the future, all in jdk.internal.

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

Marked as reviewed by liach (Author).

PR Review: https://git.openjdk.org/jdk/pull/19105#pullrequestreview-2046571446

From redestad at openjdk.org  Wed May  8 20:31:53 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Wed, 8 May 2024 20:31:53 GMT
Subject: RFR: 8331724: Refactor j.l.constant implementation to internal
 package [v6]
In-Reply-To: <8C398cJEhdpAgSqDxAg_Fbtti0WZDbak3DeD3nmsv-w=.7c8b6aea-6a01-4a8b-832d-47b5a69bdbce@github.com>
References: <_GPUF9d1E6eBKRxP6bEEqA3LSKRJe2GwCRTfVYbDwFU=.cb482785-e7c4-45f7-bd3a-cd32d466a2cb@github.com>
 <-XO7o4O_fosLQ-I2ZH6WROkMtCJ_G978GPfEma9QFEU=.916fb3c0-6599-416a-bfb1-e3329f262928@github.com>
 <8C398cJEhdpAgSqDxAg_Fbtti0WZDbak3DeD3nmsv-w=.7c8b6aea-6a01-4a8b-832d-47b5a69bdbce@github.com>
Message-ID: <-SgHfYzaT5YHJL_3nUOZtIGG3wAM1fUct0tZEYuu0f0=.5a6483ce-8bb2-4278-a879-575e79ddb9f8@github.com>

On Wed, 8 May 2024 20:24:52 GMT, Chen Liang <liach at openjdk.org> wrote:

> This patch allows us to merge parsing logic for invoke, constant, and classfile in the future, all in jdk.internal.

Thanks for reviewing! Yes, that's the idea.

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

PR Comment: https://git.openjdk.org/jdk/pull/19105#issuecomment-2101371721

From duke at openjdk.org  Wed May  8 20:40:00 2024
From: duke at openjdk.org (Vladimir Yaroslavskiy)
Date: Wed, 8 May 2024 20:40:00 GMT
Subject: RFR: 8266431: Dual-Pivot Quicksort improvements (Radix sort) [v11]
In-Reply-To: <jd32y3QbyVdNJ3WX995GiSj6RbrVjiK9mpk9SruJDfY=.40eb6b15-8b11-4387-8fab-d95c70fed1da@github.com>
References: <918oCEfFu2JweXfV-afD1l_AGDDuc7dJwAxip-Ze6ZI=.8d5e9692-23db-47e4-9586-99e53b9cfbb6@github.com>
 <i1cu_VA2najjcZHepAbvkWGtVzuLMsdYFKssI5s-TFA=.be96a1ac-1eba-4b7f-bde9-1214082eb6c6@github.com>
 <Gb1pFf-YBbIZdSO-XvQ54xqE5SvNezsl9WSHikEOEJA=.90ccd95f-4a79-4a3e-91a0-23eb83107937@github.com>
 <e8rv_97mAYHGXeRhI8dirZDJsn9ecO2gM91t1LCxnWI=.21859a35-93b8-449c-b4f8-d9dfc0912a7e@github.com>
 <m_FlD1imWi57n0EqQXsrFue-FkO4D1hIbHUI2ph5d6o=.3fcdbf05-7147-4461-8d8e-6947f6f18d62@github.com>
 <C9cdmmBTW6uphtzkL9BdV4DboIuwNF6M-UMnC3xM8vg=.2aa0c11c-cb22-445f-86f6-281c6ab6368c@github.com>
 <-bYhysKjQVb_ZS0I0YutJZ7umfYwbs74rtK6-d2qL9U=.f9981e59-f0c4-48f3-ad7e-5627aad00919@github.com>
 <91Zv361kqKOjCSJPu20-yhKOb4lBIZVyVTm9f79dkcQ=.745c271d-3cb1-4ff3-9d71-5cad85ff4f14@github.com>
 <lAzKoJ7VajYG5E02nRkuqAHsREz3hz7plUFG3bjfwe0=.420af221-7969-4d8f-b9d2-16d2b4fa4cf9@github.com>
 <9q8Gg6DQnrf0HLW3oxwfpoUP9639drr1BIQMc1rxDFo=.eb4ea73c-b632-446a-8d50-b51838f67f69@github.com>
 <NC3E6wpsavqRXUqdgNHh3y26lFSIPXoA0yi
 KcV_2CyI=.391c9553-458a-417f-b86d-2c88dacf7df1@github.com>
 <Kc8tP6_hlFmF_NqcwSHEX6NF9atmoeglRsRFTrLaA5A=.bacb4a7d-26cb-4fdc-8f7b-f883587cd58c@github.com>
 <xrA2rqmjQ-gHGaZ23SQIYZCgda6sHslW2oHIqQxyM2Y=.f4ae4438-78b0-4eb1-b4aa-ed461c31ef1f@github.com>
 <0OkFUL1UCNcLRNh4P2ZdKvMENJgFy8Tz2BA5l2QgDXE=.77152fca-3c03-46a0-9855-bcf1c9b8d152@github.com>
 <hSP68W3vGCfGCOlUCf84DDw0qzt9Z7d-56LKLALocYo=.6c507f84-037d-449f-b4f6-f8c9771e6409@github.com>
 <JS57ADLXmF8NLa8Pn5HNclFkb0nHbOyCguMHquwd_bk=.b34c2b1c-43f5-491e-9965-6bf6f1cce3b0@github.com>
 <ib2mYavPszYymn_Q0H2Ur05M6MhSkpdwL_p6glKqSas=.411442cf-b0ee-4522-94e9-84be3b6ea292@github.com>
 <9_KKkAnzsXHFkj0038AWd5Jk3HTEXe2LQ4mVS88NzBw=.2753397a-5acc-45b6-ade9-e8799b3c6f28@github.com>
 <zbIMwqRuJNsei6zZPM05kn9XbbOm3ygyNmP5Q8_N180=.5a510e21-98fb-44f7-8f22-e93094d5b732@github.com>
 <0_F7PAs-rdVRnktd7oL65mvRxdmr_zBLNG5YVihi9Kg=.8f08c537-9d5b-4606-b9e9-b4bc1a717164@github.com>
 <z094CbYeWxVsMZ8s2_54mVC8fD_p67gSGyJxeiTZuVE=.78b39116-a5ad-4f03-ac15-7e3a09dc180e@
 github.com>
 <jd32y3QbyVdNJ3WX995GiSj6RbrVjiK9mpk9SruJDfY=.40eb6b15-8b11-4387-8fab-d95c70fed1da@github.com>
Message-ID: <Gyn-uB7iXtaX4BK8wuLqzafphTfNbJLy2n5a41RShsI=.7f279eb8-fb29-4003-9f49-84061def1e3a@github.com>

On Mon, 6 May 2024 23:26:49 GMT, Srinivas Vamsi Parasa <duke at openjdk.org> wrote:

>> Hello Vamsi (@vamsi-parasa),
>> 
>> Could you please run the new benchmarking to detect the best case
>> for Radix sort and parallel sorting?
>> 
>> What you need is to compile and run JavaBenchmarkHarness:
>> 
>> javac --patch-module java.base=. -d classes *.java
>> java -XX:CompileThreshold=1 -XX:-TieredCompilation --patch-module java.base=classes -cp classes java.util.JavaBenchmarkHarness
>> 
>> Find the sources there:
>> 
>> https://github.com/iaroslavski/sorting/blob/master/radixsort/DualPivotQuicksort_b01.java
>> https://github.com/iaroslavski/sorting/blob/master/radixsort/DualPivotQuicksort_r30.java
>> https://github.com/iaroslavski/sorting/blob/master/radixsort/DualPivotQuicksort_r30_a.java
>> https://github.com/iaroslavski/sorting/blob/master/radixsort/DualPivotQuicksort_r30_5.java
>> https://github.com/iaroslavski/sorting/blob/master/radixsort/DualPivotQuicksort_r30_11.java
>> https://github.com/iaroslavski/sorting/blob/master/radixsort/DualPivotQuicksort_r30_12.java
>> https://github.com/iaroslavski/sorting/blob/master/radixsort/DualPivotQuicksort_r30_13.java
>> https://github.com/iaroslavski/sorting/blob/master/radixsort/DualPivotQuicksort_r30_14.java
>> https://github.com/iaroslavski/sorting/blob/master/radixsort/DualPivotQuicksort_r30_21.java
>> https://github.com/iaroslavski/sorting/blob/master/radixsort/DualPivotQuicksort_r30_23.java
>> https://github.com/iaroslavski/sorting/blob/master/radixsort/JavaBenchmarkHarness.java
>> 
>> Thank you,
>> Vladimir
>
> Hi Vladimir (@iaroslavski),
> 
> Please see the data below.
> 
> Thanks,
> Vamsi
> 
> name | builder | size | mode | count | score
> -- | -- | -- | -- | -- | --
> b01 | RANDOM | 600 | avg | 325677 | 6.764
> b01 | RANDOM | 3000 | avg | 52041 | 77.742
> b01 | RANDOM | 90000 | avg | 1217 | 4449.668
> b01 | RANDOM | 400000 | avg | 242 | 22764.05
> b01 | RANDOM | 1000000 | avg | 90 | 60737.71
> b01 | REPEATED | 600 | avg | 651354 | 1.723
> b01 | REPEATED | 3000 | avg | 104083 | 12.383
> b01 | REPEATED | 90000 | avg | 2435 | 714.451
> b01 | REPEATED | 400000 | avg | 484 | 3039.447
> b01 | REPEATED | 1000000 | avg | 180 | 8114.503
> b01 | SAWTOOTH | 600 | avg | 1954062 | 1.009
> b01 | SAWTOOTH | 3000 | avg | 312251 | 4.94
> b01 | SAWTOOTH | 90000 | avg | 7305 | 133.192
> b01 | SAWTOOTH | 400000 | avg | 1453 | 591.854
> b01 | SAWTOOTH | 1000000 | avg | 542 | 1494.252
> b01 | STAGGER | 600 | avg | 1954062 | 8.252
> b01 | STAGGER | 3000 | avg | 312251 | 10.449
> b01 | STAGGER | 90000 | avg | 7305 | 287.811
> b01 | STAGGER | 400000 | avg | 1453 | 1288.92
> b01 | STAGGER | 1000000 | avg | 542 | 3245.649
> b01 | SHUFFLE | 600 | avg | 325677 | 5.199
> b01 | SHUFFLE | 3000 | avg | 52041 | 29.734
> b01 | SHUFFLE | 90000 | avg | 1217 | 1392.125
> b01 | SHUFFLE | 400000 | avg | 242 | 5772.859
> b01 | SHUFFLE | 1000000 | avg | 90 | 15483.65
> r30 | RANDOM | 600 | avg | 325677 | 4.307
> r30 | RANDOM | 3000 | avg | 52041 | 71.438
> r30 | RANDOM | 90000 | avg | 1217 | 3971.947
> r30 | RANDOM | 400000 | avg | 242 | 19924.32
> r30 | RANDOM | 1000000 | avg | 90 | 53671.9
> r30 | REPEATED | 600 | avg | 651354 | 1.36
> r30 | REPEATED | 3000 | avg | 104083 | 6.415
> r30 | REPEATED | 90000 | avg | 2435 | 578.708
> r30 | REPEATED | 400000 | avg | 484 | 2488.414
> r30 | REPEATED | 1000000 | avg | 180 | 6280.025
> r30 | SAWTOOTH | 600 | avg | 1954062 | 0.488
> r30 | SAWTOOTH | 3000 | avg | 312251 | 2.409
> r30 | SAWTOOTH | 90000 | avg | 7305 | 71.98
> r30 | SAWTOOTH | 400000 | avg | 1453 | 343.433
> r30 | SAWTOOTH | 1000000 | avg | 542 | 954.287
> r30 | STAGGER | 600 | avg | 1954062 | 1.064
> r30 | STAGGER | 3000 | avg | 312251 | 4.559
> r30 | STAGGER | 90000 | avg | 7305 | 135.383
> r30 | STAGGER | 400000 | avg | 1453 | 626.657
> r30 | STAGGER | 1000000 | avg | 542 | 1653.92
> r30 | SHUFFLE | 600 | avg | 325677 | 2.924
> r30 | SHUFFLE | 3000 | avg | 52041 | 18.819
> r30 | SHUFFLE | 90000 | avg | 1217 | 1019.036
> r30 | SHUFFLE | 400000 | avg | 242 | 4661.484
> r30 | SHUFFLE | 1000000 | avg | 90 | 11333.52
> r30_a | RANDOM | 600 | avg | 325677 | 4.024
> r30_a | RANDOM | 3000 | avg | 52041 | 72.86
> r30_a | ...

Hello Vamsi (@vamsi-parasa),

Could you please run the new benchmarking to finalize the best version?
What you need is to compile and run JavaBenchmarkHarness:

javac --patch-module java.base=. -d classes *.java
java -XX:CompileThreshold=1 -XX:-TieredCompilation --patch-module java.base=classes -cp classes java.util.JavaBenchmarkHarness

Find the sources there:

https://github.com/iaroslavski/sorting/blob/master/radixsort/DualPivotQuicksort_b01.java
https://github.com/iaroslavski/sorting/blob/master/radixsort/DualPivotQuicksort_r31_11.java
https://github.com/iaroslavski/sorting/blob/master/radixsort/DualPivotQuicksort_r31_11a.java
https://github.com/iaroslavski/sorting/blob/master/radixsort/DualPivotQuicksort_r31_12.java
https://github.com/iaroslavski/sorting/blob/master/radixsort/DualPivotQuicksort_r31_12a.java
https://github.com/iaroslavski/sorting/blob/master/radixsort/JavaBenchmarkHarness.java

Thank you,
Vladimir

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

PR Comment: https://git.openjdk.org/jdk/pull/13568#issuecomment-2101386258

From jlu at openjdk.org  Wed May  8 20:52:52 2024
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 8 May 2024 20:52:52 GMT
Subject: RFR: 8331866: Add warnings for locale data dependence
In-Reply-To: <d1V8q3oaeh-cPvR_IE22WAHhoqrc1TXZMdEtIhxCLvM=.af6edbc8-49c1-4125-930d-42580dcb40c3@github.com>
References: <d1V8q3oaeh-cPvR_IE22WAHhoqrc1TXZMdEtIhxCLvM=.af6edbc8-49c1-4125-930d-42580dcb40c3@github.com>
Message-ID: <oOpbUlaBoKm2zBM3dbGgMEl-VdG0_LZoS8G1NwRaO1I=.dc94616b-43ed-4138-9948-bca81ece7b23@github.com>

On Wed, 8 May 2024 20:21:50 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> In order to enlighten users to not depend on a particular version of the locale data, putting a note into the JDK vs. CLDR version chart would be appropriate.

LGTM. Wording in the beginning of the class spec makes it clear that locale sensitive factory methods are dependent on the LSP. By now adding wording that the CLDR data changes, it should hopefully help to reduce the expectation from users of consistent data between releases for these locale sensitive methods.

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

Marked as reviewed by jlu (Committer).

PR Review: https://git.openjdk.org/jdk/pull/19145#pullrequestreview-2046636580

From redestad at openjdk.org  Wed May  8 21:19:53 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Wed, 8 May 2024 21:19:53 GMT
Subject: RFR: 8331932: Startup regressions in 23-b13 [v4]
In-Reply-To: <s2juWO6qkHZkklzu7f67ZI38E5X8gxgNef0HamoaMTM=.fd346caf-0291-4d09-98dc-fe6165c2ea3e@github.com>
References: <LgTAOs1QA0kgTbAfVQ_U2BcWAV7AHpcFXNE7eYB1BI8=.e77b81c1-73d4-4ff0-806f-eeda86d5cb16@github.com>
 <N_aub_OElJ5bLxaw6a-aYBWcMHTGS2vkdnKlTc_T46E=.300a895b-0d84-46d2-a8c6-351811a4cd49@github.com>
 <s2juWO6qkHZkklzu7f67ZI38E5X8gxgNef0HamoaMTM=.fd346caf-0291-4d09-98dc-fe6165c2ea3e@github.com>
Message-ID: <v44PuA_Q1WlkE3QRHvzbNQXhgmRdUhgNOO7NAtcPNlE=.ad47c399-dbf6-4a68-8e9c-727245d0f8c7@github.com>

On Wed, 8 May 2024 18:32:42 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove redundant constructor
>
> src/java.base/share/classes/jdk/internal/util/ReferencedKeySet.java line 84:
> 
>> 82:      */
>> 83:     public static <E> Supplier<Map<ReferenceKey<E>, ReferenceKey<E>>> concurrentHashMapSupplier() {
>> 84:         return new Supplier<>() {
> 
> Can this just `return ReferencedKeyMap.concurrentHashMapSupplier();`?

It compiles, so maybe. :-) Running some tests.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19140#discussion_r1594703469

From naoto at openjdk.org  Wed May  8 22:01:54 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 8 May 2024 22:01:54 GMT
Subject: RFR: JDK-8331646: Add specific regression leap year tests (Task -
 P4) [v3]
In-Reply-To: <zHMK1g208lNjlj6NJUR_O9-ee0lnk_5dOlo3271RbPE=.8711e15c-4587-4513-ac7e-cd9a407191d6@github.com>
References: <cB-Q8ihe6DYQTm1WcRvVV3oW8YXtnWH5fmsS1zurwwY=.176d4137-bd3b-445e-a055-c738bd73744c@github.com>
 <zHMK1g208lNjlj6NJUR_O9-ee0lnk_5dOlo3271RbPE=.8711e15c-4587-4513-ac7e-cd9a407191d6@github.com>
Message-ID: <yBV6GeFjtCzLMsRHSyyaPGP1Pua9UiYFk5OP2HfpwvU=.0e922d02-13f7-4386-818d-e0d8aa541a7f@github.com>

On Wed, 8 May 2024 11:36:07 GMT, serhiysachkov <duke at openjdk.org> wrote:

>> Calendar.add() tests that describe its behavior.
>
> serhiysachkov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   JDK-8331646 consolidating test methods into  ParameterizedTests

Thanks for the changes. Also, match this PR title to the JBS title (remove that `Task - P4`)

test/jdk/java/util/Calendar/CalendarLeapYearAddTest.java line 41:

> 39: 
> 40: import static java.util.Calendar.*;
> 41: import static java.util.Calendar.MONTH;

It's better to explicitly declare which fields are statically imported from `Calendar`.

test/jdk/java/util/Calendar/CalendarLeapYearAddTest.java line 54:

> 52:                                 int value, int calendarField, int expectedDate, int expectedMonth,
> 53:                                 int expectedYear) {
> 54:         Calendar calendar = Calendar.getInstance();

Instead of using a factory on `Calendar`, this should explicitly construct a `GregorianCalendar` instance which guarantees the leap-year behavior.

test/jdk/java/util/Calendar/CalendarLeapYearAddTest.java line 69:

> 67:     public void testMonthYearAddSubtractNonLeapYear() {
> 68:         Calendar calendar = Calendar.getInstance();
> 69:         calendar.set(2024, 1, 29, 15, 0, 0);

It's easier to understand using `FEBRUARY`, instead of the immediate value `1`.

test/jdk/java/util/Calendar/CalendarLeapYearAddTest.java line 72:

> 70:         calendar.add(Calendar.MONTH, 1);
> 71:         calendar.add(YEAR, -1);
> 72:         calendar.add(Calendar.MONTH, -1);

`Calendar.MONTH` -> `MONTH`

test/jdk/java/util/Calendar/CalendarLeapYearAddTest.java line 118:

> 116:                 Arguments.of("testMonthAddLeapYear", 29, 1, 2024, 1, MONTH, 29, MARCH, 2024),
> 117:                 Arguments.of("testOneMonthSubtractLeapYear", 31, 2, 2024, -1, MONTH, 29, FEBRUARY, 2024),
> 118:                 Arguments.of("testTwoMonthSubtractLeapYear", 30, 3, 2024, -2, MONTH, 29, FEBRUARY, 2024)

Please use those month fields in those arguments.

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

PR Review: https://git.openjdk.org/jdk/pull/19082#pullrequestreview-2046786753
PR Review Comment: https://git.openjdk.org/jdk/pull/19082#discussion_r1594729131
PR Review Comment: https://git.openjdk.org/jdk/pull/19082#discussion_r1594732962
PR Review Comment: https://git.openjdk.org/jdk/pull/19082#discussion_r1594730699
PR Review Comment: https://git.openjdk.org/jdk/pull/19082#discussion_r1594731131
PR Review Comment: https://git.openjdk.org/jdk/pull/19082#discussion_r1594742243

From bchristi at openjdk.org  Wed May  8 22:12:01 2024
From: bchristi at openjdk.org (Brent Christian)
Date: Wed, 8 May 2024 22:12:01 GMT
Subject: RFR: 8314480: Memory ordering spec updates in java.lang.ref [v10]
In-Reply-To: <A1XrAasxRIaEJqy-nvQ-p0rjh_CJMdT1F1xk5U6KUBM=.432d92d9-5196-4c4b-b8ad-f8e839a1ae14@github.com>
References: <R74ontYwjYg6HeZY0cWrlo0amjl4E1YsFWeuh4pda14=.08ac62df-b2f8-4b4d-b338-07adb289601b@github.com>
 <hJ1gdvXaaead1N3EAECaT6SBY-XvRHEKM0S4XeWpfLY=.ad0c3816-b9a7-4bfe-bfa9-a811e5d18056@github.com>
 <A1XrAasxRIaEJqy-nvQ-p0rjh_CJMdT1F1xk5U6KUBM=.432d92d9-5196-4c4b-b8ad-f8e839a1ae14@github.com>
Message-ID: <XwuasP5eGPoU79hjrHYLDAvoQ1S2T-_YBn4H8XZk7IM=.5351051b-d6c5-4c3a-9b41-fa60fa9ed9d2@github.com>

On Fri, 23 Feb 2024 14:37:20 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Brent Christian has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   VM -> virtual machine; also fix misspelling
>
> src/java.base/share/classes/java/lang/ref/Cleaner.java line 218:
> 
>> 216:      * cautions about the behavior of cleaning actions.
>> 217:      *
>> 218:      * <p>The object being registered is kept strongly reachable (and therefore not eligible
> 
> I would be tempted to drop "being registered" from this sentence. The previous paragraph and the parameter descriptions use "the object". That would make it "The given object is  kept strongly reachable ..." which I think is a bit easier to read.

If it's clear which object is meant, then yes, that reads better.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16644#discussion_r1594756233

From ihse at openjdk.org  Wed May  8 22:40:12 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 8 May 2024 22:40:12 GMT
Subject: RFR: 8311302: Allow for jlinking a custom runtime without packaged
 modules being present [v26]
In-Reply-To: <RUr5xr-pzsccK28vRBO-GhY-8RltknEX2lyMgWpijnA=.980d0b9d-f219-4bc7-bf64-4e343f44ac7d@github.com>
References: <Z0DJ87uKPbjS6mvJIE_oG5m-RWsbERXsytSgV8Bmhdo=.f8723513-0ac6-4e85-9131-3c3924860c61@github.com>
 <RUr5xr-pzsccK28vRBO-GhY-8RltknEX2lyMgWpijnA=.980d0b9d-f219-4bc7-bf64-4e343f44ac7d@github.com>
Message-ID: <7GEk4PVZYWDSKt8bWCVSHD4f8zFmmJNWwJojxrFgwC4=.10d95786-32d8-40e8-bb21-1647da3ee39c@github.com>

On Tue, 7 May 2024 16:52:12 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> Please review this patch which adds a jlink mode to the JDK which doesn't need the packaged modules being present. A.k.a run-time image based jlink. Fundamentally this patch adds an option to use `jlink` even though your JDK install might not come with the packaged modules (directory `jmods`). This is particularly useful to further reduce the size of a jlinked runtime. After the removal of the concept of a JRE, a common distribution mechanism is still the full JDK with all modules and packaged modules. However, packaged modules can incur an additional size tax. For example in a container scenario it could be useful to have a base JDK container including all modules, but without also delivering the packaged modules. This comes at a size advantage of `~25%`. Such a base JDK container could then be used to `jlink` application specific runtimes, further reducing the size of the application runtime image (App + JDK runtime; as a single image *or* separate bundles, depending on the app 
 being modularized).
>> 
>> The basic design of this approach is to add a jlink plugin for tracking non-class and non-resource files of a JDK install. I.e. files which aren't present in the jimage (`lib/modules`). This enables producing a `JRTArchive` class which has all the info of what constitutes the final jlinked runtime.
>> 
>> Basic usage example:
>> 
>> $ diff -u <(./bin/java --list-modules --limit-modules java.se) <(../linux-x86_64-server-release/images/jdk/bin/java --list-modules --limit-modules java.se)
>> $ diff -u <(./bin/java --list-modules --limit-modules jdk.jlink) <(../linux-x86_64-server-release/images/jdk/bin/java --list-modules --limit-modules jdk.jlink)
>> $ ls ../linux-x86_64-server-release/images/jdk/jmods
>> java.base.jmod            java.net.http.jmod       java.sql.rowset.jmod      jdk.crypto.ec.jmod         jdk.internal.opt.jmod                     jdk.jdi.jmod         jdk.management.agent.jmod  jdk.security.auth.jmod
>> java.compiler.jmod        java.prefs.jmod          java.transaction.xa.jmod  jdk.dynalink.jmod          jdk.internal.vm.ci.jmod                   jdk.jdwp.agent.jmod  jdk.management.jfr.jmod    jdk.security.jgss.jmod
>> java.datatransfer.jmod    java.rmi.jmod            java.xml.crypto.jmod      jdk.editpad.jmod           jdk.internal.vm.compiler.jmod             jdk.jfr.jmod         jdk.management.jmod        jdk.unsupported.desktop.jmod
>> java.desktop.jmod         java.scripting.jmod      java.xml.jmod             jdk.hotspot.agent.jmod     jdk.i...
>
> Severin Gehwolf has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 105 commits:
> 
>  - Generate the runtime image link diff at jlink time
>    
>    But only do that once the plugin-pipeline has run. The generation is
>    enabled with the hidden option '--generate-linkable-runtime' and
>    the resource pools available at jlink time are being used to generate
>    the diff.
>  - Merge branch 'master' into jdk-8311302-jmodless-link
>  - Use shorter name for the build tool
>  - Review feedback from Erik J.
>  - Remove dependency on CDS which isn't needed anymore
>  - Fix coment
>  - Fix comment
>  - Fix typo
>  - Revert some now unneded build changes
>  - Follow build tools naming convention
>  - ... and 95 more: https://git.openjdk.org/jdk/compare/23a72a1f...67aea4ca

make/Images.gmk line 100:

> 98: 
> 99: ifeq ($(JLINK_PRODUCE_RUNTIME_LINK_JDK), true)
> 100:   JLINK_JDK_EXTRA_OPTS := $(JLINK_JDK_EXTRA_OPTS) --generate-linkable-runtime

I just noticed this slight improvement:

Suggestion:

  JLINK_JDK_EXTRA_OPTS += --generate-linkable-runtime

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14787#discussion_r1594774220

From duke at openjdk.org  Wed May  8 22:45:59 2024
From: duke at openjdk.org (duke)
Date: Wed, 8 May 2024 22:45:59 GMT
Subject: Withdrawn: 8320699: Add parameter to skip progress logging of
 OutputAnalyzer
In-Reply-To: <nMSAMM8k9aiAM3qiRuj-jmyIVugoNOI95xu2N48B0e8=.64a80b3c-cc0d-44c2-ab61-29a8068d4f3d@github.com>
References: <nMSAMM8k9aiAM3qiRuj-jmyIVugoNOI95xu2N48B0e8=.64a80b3c-cc0d-44c2-ab61-29a8068d4f3d@github.com>
Message-ID: <ssbNZ6vI3VFfv0JFEn5kUhRFYd2Cf0IG3CfSDkOiU2o=.557a0695-35ab-44ac-b90c-dc911ec95cc9@github.com>

On Fri, 24 Nov 2023 10:34:02 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> Tests using ProcessTools.executeProcess gets the following output written to stdout:
> [2023-11-24T09:58:16.797540608Z] Gathering output for process 2517117
> [2023-11-24T09:58:23.070781345Z] Waiting for completion for process 2517117
> [2023-11-24T09:58:23.071045055Z] Waiting for completion finished for process 2517117
> 
> This might be good for some use cases and debugging, but some tests spawns a large number of processes and for those this output fills up the log files.
> 
> I propose that we add a way to turn of this output for tests where we find this output to be too noisy.

This pull request has been closed without being integrated.

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

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

From prappo at openjdk.org  Wed May  8 22:55:56 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Wed, 8 May 2024 22:55:56 GMT
Subject: RFR: 8305457: Implement java.io.IO [v3]
In-Reply-To: <bX9rOfeN_f5pV3Yv_uCCSDYoWnjzsdWhvas5MyUqx-A=.3e0697c9-278d-45ea-896e-6e4c89d8d839@github.com>
References: <w2msiw_qaMEIJS3s9D4bg8pFbz5WIF0KdP6Mm-XFjLI=.85b2020b-8c46-4bac-8a69-4975b068f2ff@github.com>
 <wpwFGOp8E00csxi2Xb9b-02ZlkqnIZEpo8AqaMsQ4AM=.90acb47b-effc-4838-ba80-28938d4dc3c0@github.com>
 <C1Pvc8KO7vUGELLaqcXpepoK_MpvChaDcZqfroVICo0=.5ab8bef5-fa21-4618-a903-219d733045a0@github.com>
 <jWOXcC9B_23P_Px2zulnzRc38zL7zkslJM9nRtauHlk=.55e2ed38-59b7-4df1-be13-5d9a74672e26@github.com>
 <yZdbfOOkmceBWA5_ybn4g9cLTI-a40mvJ9eT6c_5YI4=.b5715149-8051-43bc-8556-1bc217bdfc39@github.com>
 <QOraUtvx4uq8mQagpLv6RQDsY-bD5YcvspNegJ9R9O4=.8b4a7dec-6445-4dc0-bbe3-a74385e00826@github.com>
 <kXr9EdR3dWGNLqQRenj1LcwWTChuqmc6gA7r04R9nAo=.76e57556-5210-45ae-8e13-755a604c0c49@github.com>
 <IY4TieJPjmWSdKQaPXzSa-Ud4kjq1_fjjQBncwTsiGg=.fc991711-78da-45b6-bd4b-0bc8d8284eb7@github.com>
 <bX9rOfeN_f5pV3Yv_uCCSDYoWnjzsdWhvas5MyUqx-A=.3e0697c9-278d-45ea-896e-6e4c89d8d839@github.com>
Message-ID: <vg1basj8I5R8IC4I_jenDq3Ebuv1dmutpSRMZxt_9Y8=.42eef136-d696-45fd-8393-39ac30ce3c6d@github.com>

On Wed, 8 May 2024 19:40:44 GMT, Stuart Marks <smarks at openjdk.org> wrote:

>>> Most of these are defined in terms of `String.valueOf(Object)` which if passed a null reference will return the String object containing `null`. So no, I don't think NPE should be thrown. It might be worth mentioning this explicitly somewhere though.
>> 
>> Right, in our current model, `Console.readln(prompt)` can be reduced to `Console.print(prompt)` followed by actual reading. `Console.print(prompt)` can in turn be reduced to printing the result of `String.valueOf((Object) prompt)`, which is a string "null".
>> 
>> The above reduction means that `Console.readln(null)` will not throw NPE. Now, what I'm asking if that's what we really want.
>> 
>> With `Console.println(null)` and `Console.print(null)` not throwing NPE makes sense. However, with `Console.readln(null)` it might not. After all, we ask for a **`String`** prompt, not an `Object` prompt. All other methods of `Console` that accept `String`, throw NPE if that string is null.
>> 
>> One more consideration. Whatever the behaviour we choose for `Console.readln(null)`, we should choose the same behaviour for `IO.readln(null)`. Otherwise, it would be a constant source of unpleasantly surprising inconsistency.
>> 
>> Thoughts?
>
> A fair question, whether to treat `readln` differently because it takes a String argument instead of an Object.
> 
> I guess I'd like to see a scheme like the following:
> 
>     String s = cons.readln(prompt);
> 
> is effectively the same as
> 
>     cons.print(prompt);
>     cons.flush();
>     String s = cons.readLine(); // note no-arg readLine() method
> 
> In other words, define `readln` to behave "as if" the other methods were called. This would end up with a null prompt argument printing "null" and not throwing NPE.
> 
> This is internally consistent, at least. Beginning programmers will eventually learn that using null will lead to NPE. It might make things easier if NPEs were kept out of this little corner of the library. That's just my guess though.
> 
> Also, recall that `String.valueOf((Object) null)` and `String.valueOf((String) null)` both result in "null". But if one were to write `String.valueOf(null)` that throws NPE, because that selects the `valueOf(char[])` overload. That's kind of the outlier. Note further that the built-in `+` string concatenation operator will also convert null references to "null".
> 
> Personally I've always hated that string conversions of null in Java often result in "null" but it's baked into the system fairly deeply, so I think we should stick with it.

Okay, I'll push a commit soon.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19112#discussion_r1594784225

From bchristi at openjdk.org  Wed May  8 22:58:00 2024
From: bchristi at openjdk.org (Brent Christian)
Date: Wed, 8 May 2024 22:58:00 GMT
Subject: RFR: 8314480: Memory ordering spec updates in java.lang.ref [v29]
In-Reply-To: <LgPqtQ7ltUxg763QcN0mDJ3hCsykX0dSjl7TaJsKo84=.1eb81b77-4c90-4a6e-9b87-3b3002c8a0fa@github.com>
References: <R74ontYwjYg6HeZY0cWrlo0amjl4E1YsFWeuh4pda14=.08ac62df-b2f8-4b4d-b338-07adb289601b@github.com>
 <88uucCyrO2W6frWuhxgcWtRcffZChQ8zvGO5H7OOCEU=.ffbf7203-1cde-4232-960c-84bd5d95cfe0@github.com>
 <LgPqtQ7ltUxg763QcN0mDJ3hCsykX0dSjl7TaJsKo84=.1eb81b77-4c90-4a6e-9b87-3b3002c8a0fa@github.com>
Message-ID: <dsftLKhbKHjwjpbaSVHwOWUqlOrjBPW0tDjP7yrLcKE=.2c40c042-2707-4739-bb48-eef69d59629a@github.com>

On Wed, 8 May 2024 08:33:31 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Brent Christian has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   small grammar fixes
>
> src/java.base/share/classes/java/lang/ref/Cleaner.java line 224:
> 
>> 222:      * Actions in a thread prior to calling {@code Cleaner.register()}
>> 223:      * <a href="{@docRoot}/java.base/java/util/concurrent/package-summary.html#MemoryVisibility"><i>happen-before</i></a>
>> 224:      * the cleaning action is run by the Cleaner's thread.
> 
> In passing, you could reduces the html refs to "package-summary.html#MemoryConsistency" and "package-summary.html#MemoryVisibility" as it's the same package/directory.

MemoryVisibility is in java.util.concurrent ?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16644#discussion_r1594785182

From prappo at openjdk.org  Wed May  8 23:03:14 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Wed, 8 May 2024 23:03:14 GMT
Subject: RFR: 8311864: Add ArraysSupport.hashCode(int[] a, fromIndex,
 length, initialValue) [v6]
In-Reply-To: <xh6T_mvwyT2yxFZoK-6yg3eudfeRmTt3D_AxR_eScqE=.2c66d4d6-f0f0-4f24-8892-ea2aa5b56c2d@github.com>
References: <xh6T_mvwyT2yxFZoK-6yg3eudfeRmTt3D_AxR_eScqE=.2c66d4d6-f0f0-4f24-8892-ea2aa5b56c2d@github.com>
Message-ID: <nmpgDkv90vfDsO4yc1M1oEBj6Nly08QS2GTZpPj3y0Q=.e9470fd5-163a-42de-9040-b4786eec3706@github.com>

> This PR adds an internal method to calculate hash code from the provided integer array, offset and length into that array, and the initial hash code value.
> 
> Current options for calculating a hash code for int[] are inflexible. It's either ArraysSupport.vectorizedHashCode with an offset, length and initial value, or Arrays.hashCode with just an array.
> 
> For an arbitrary int[], unconditional vectorization might be unwarranted or puzzling. Unfortunately, it's the only hash code method that operates on an array subrange or accepts the initial hash code value.
> 
> A more convenient method could be added and then used, for example, here:
> 
> * https://github.com/openjdk/jdk/blob/0ef03f122866f010ebf50683097e9b92e41cdaad/src/java.base/share/classes/java/util/concurrent/CopyOnWriteArrayList.java#L1076-L1083
> 
> * https://github.com/openjdk/jdk/blob/0ef03f122866f010ebf50683097e9b92e41cdaad/src/java.base/share/classes/java/util/ArrayList.java#L669-L680
> 
> * https://github.com/openjdk/jdk/blob/0ef03f122866f010ebf50683097e9b92e41cdaad/src/java.base/share/classes/sun/security/pkcs10/PKCS10.java#L356-L362
> 
> This PR adds such a method and provides tests for it. Additionally, this PR adds tests for `null` passed to `java.util.Arrays.hashCode` overloads, behaviour which was specified but untested.

Pavel Rappo 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 seven additional commits since the last revision:

 - Merge branch 'master' into 8311864
 - Merge branch 'master' into 8311864
 - Merge branch 'master' into 8311864
 - Merge branch 'master' into 8311864
 - Merge remote-tracking branch 'jdk/master' into 8311864
 - Merge branch 'master' into 8311864
 - Initial commit

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14831/files
  - new: https://git.openjdk.org/jdk/pull/14831/files/2d06e03a..aa6d053c

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

  Stats: 119667 lines in 3101 files changed: 55211 ins; 48378 del; 16078 mod
  Patch: https://git.openjdk.org/jdk/pull/14831.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14831/head:pull/14831

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

From bchristi at openjdk.org  Thu May  9 00:14:20 2024
From: bchristi at openjdk.org (Brent Christian)
Date: Thu, 9 May 2024 00:14:20 GMT
Subject: RFR: 8314480: Memory ordering spec updates in java.lang.ref [v30]
In-Reply-To: <R74ontYwjYg6HeZY0cWrlo0amjl4E1YsFWeuh4pda14=.08ac62df-b2f8-4b4d-b338-07adb289601b@github.com>
References: <R74ontYwjYg6HeZY0cWrlo0amjl4E1YsFWeuh4pda14=.08ac62df-b2f8-4b4d-b338-07adb289601b@github.com>
Message-ID: <GPgfvSrUxu_Oc780-OxL4wV34dcWieD3ZPWERVTHisM=.24f6eb77-8fc0-4a0b-907e-945dca8d93b5@github.com>

> Classes in the `java.lang.ref` package would benefit from an update to bring the spec in line with how the VM already behaves. The changes would focus on _happens-before_ edges at some key points during reference processing.
> 
> A couple key things we want to be able to say are:
> - `Reference.reachabilityFence(x)` _happens-before_ reference processing occurs for 'x'.
> - `Cleaner.register()` _happens-before_ the Cleaner thread runs the registered cleaning action.
> 
> This will bring Cleaner in line (or close) with the memory visibility guarantees made for finalizers in [JLS 17.4.5](https://docs.oracle.com/javase/specs/jls/se18/html/jls-17.html#jls-17.4.5):
> _"There is a happens-before edge from the end of a constructor of an object to the start of a finalizer (?12.6) for that object."_

Brent Christian has updated the pull request incrementally with one additional commit since the last revision:

  small review tweaks; shorten MemoryConsistency links

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16644/files
  - new: https://git.openjdk.org/jdk/pull/16644/files/a41e6fc2..5db47889

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16644&range=29
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16644&range=28-29

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

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

From duke at openjdk.org  Thu May  9 00:54:31 2024
From: duke at openjdk.org (xiaotaonan)
Date: Thu, 9 May 2024 00:54:31 GMT
Subject: RFR: 8331957: Release Note: System Property for Java SE Specification
 Maintenance Version
Message-ID: <b0_uutHu72mHVmE6qQf0i9oS-5kUNFtJz_rS5aVeB18=.8ada78c9-490f-4603-a596-53c803a3a1d8@github.com>

?ersion

Release Note: System Property for Java SE Specification Maintenance Version

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

Commit messages:
 - Release Note: System Property for Java SE Specification Maintenance Version

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

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

From iris at openjdk.org  Thu May  9 01:55:51 2024
From: iris at openjdk.org (Iris Clark)
Date: Thu, 9 May 2024 01:55:51 GMT
Subject: RFR: 8331957: Release Note: System Property for Java SE
 Specification Maintenance Version
In-Reply-To: <b0_uutHu72mHVmE6qQf0i9oS-5kUNFtJz_rS5aVeB18=.8ada78c9-490f-4603-a596-53c803a3a1d8@github.com>
References: <b0_uutHu72mHVmE6qQf0i9oS-5kUNFtJz_rS5aVeB18=.8ada78c9-490f-4603-a596-53c803a3a1d8@github.com>
Message-ID: <9RHg_PRVgdJFpXU410XKJQ5xgEmCfKguigG9H6gltzA=.9a626f98-87c9-4fb1-b005-16aef55ab30d@github.com>

On Thu, 9 May 2024 00:49:43 GMT, xiaotaonan <duke at openjdk.org> wrote:

> ?ersion
> 
> Release Note: System Property for Java SE Specification Maintenance Version

This system property should not be set for a feature release.  It should only be set if there has been a JCP Maintenance Release.  Perhaps this PR should be against a different repo?

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

Changes requested by iris (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19149#pullrequestreview-2047019025

From duke at openjdk.org  Thu May  9 02:14:18 2024
From: duke at openjdk.org (xiaotaonan)
Date: Thu, 9 May 2024 02:14:18 GMT
Subject: RFR: 8331879: Clean up non-standard use of /// comments in `java.base`
Message-ID: <JKCovwpov4A3Uddzf6N0AnZSb3Znv-7MEfMGec6IhR4=.93e4ad8e-344b-4890-8f25-c2752287024c@github.com>

Clean up non-standard use of /// comments in `java.base`

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

Commit messages:
 - Clean up non-standard use of /// comments in

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

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

From duke at openjdk.org  Thu May  9 02:30:53 2024
From: duke at openjdk.org (ExE Boss)
Date: Thu, 9 May 2024 02:30:53 GMT
Subject: RFR: 8331724: Refactor j.l.constant implementation to internal
 package [v6]
In-Reply-To: <-XO7o4O_fosLQ-I2ZH6WROkMtCJ_G978GPfEma9QFEU=.916fb3c0-6599-416a-bfb1-e3329f262928@github.com>
References: <_GPUF9d1E6eBKRxP6bEEqA3LSKRJe2GwCRTfVYbDwFU=.cb482785-e7c4-45f7-bd3a-cd32d466a2cb@github.com>
 <-XO7o4O_fosLQ-I2ZH6WROkMtCJ_G978GPfEma9QFEU=.916fb3c0-6599-416a-bfb1-e3329f262928@github.com>
Message-ID: <9WHMhsSwQeR2N4pqfrTtdNktGBlEVPHwh4-92tY0dVM=.6b2a06af-817f-4f06-9cdf-1d215972b436@github.com>

On Wed, 8 May 2024 20:17:18 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> This PR suggests refactoring the implementation classes of java.lang.constant into a new package jdk.internal.constant to enable sharing some trusted static factory methods with users elsewhere in java.base, such as java.lang.invoke and java.lang.classfile. The refactoring also adds some "trusted" methods for use when input is pre-validated, and makes use of them where applicable in the current implementation. There are more changes in the pipeline which will be folded into #17108 or PR'ed once that is integrated. 
>> 
>> There are two optimizations mixed up here. One in `MethodTypeDesc.ofDescriptor`:
>> 
>> Name                                                             (descString) Cnt     Base     Error      Test   Error  Unit  Change
>> MethodTypeDescFactories.ofDescriptor  (Ljava/lang/Object;Ljava/lang/String;)I   6  138,371 ?   0,767   136,939 ? 1,126 ns/op   1,01x (p = 0,000*)
>> MethodTypeDescFactories.ofDescriptor                                      ()V   6   10,528 ?   2,495     4,110 ? 0,047 ns/op   2,56x (p = 0,000*)
>> MethodTypeDescFactories.ofDescriptor ([IJLjava/lang/String;Z)Ljava/util/List;   6  209,390 ?   4,583   196,175 ? 3,211 ns/op   1,07x (p = 0,000*)
>> MethodTypeDescFactories.ofDescriptor                    ()[Ljava/lang/String;   6   36,039 ?   8,684    20,794 ? 1,110 ns/op   1,73x (p = 0,000*)
>> MethodTypeDescFactories.ofDescriptor                                 (..IIJ)V   6  279,139 ?   6,248   187,934 ? 0,857 ns/op   1,49x (p = 0,000*)
>> MethodTypeDescFactories.ofDescriptor                 (.....................).   6 2174,387 ? 132,879  1150,652 ? 3,158 ns/op   1,89x (p = 0,000*)
>>   * = significant
>> 
>> 
>> The other in `ClassDesc::nested`, where to get rid of a simple static method in `ConstantUtils` I ended up speeding up and simplifying the public factory method:
>> 
>> Name                                      Cnt    Base     Error    Test   Error  Unit  Change
>> ClassDescFactories.ReferenceOnly.ofNested   6 209,853 ? 132,525  22,017 ? 0,573 ns/op   9,53x (p = 0,000*)
>>   * = significant
>> 
>> 
>> The optimizations could be split out and PRd independently, but I think they are simple enough to include in this refactoring.
>
> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Validate after copying to avoid TOCTOU

src/java.base/share/classes/jdk/internal/constant/MethodTypeDescImpl.java line 189:

> 187:         // Validate after copying to avoid TOCTOU
> 188:         for (int i = pos; i < destPos; i++) {
> 189:             validateArgument(argTypes[i]);

Suggestion:

            validateArgument(newArgs[i]);

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19105#discussion_r1594890009

From liach at openjdk.org  Thu May  9 02:44:58 2024
From: liach at openjdk.org (Chen Liang)
Date: Thu, 9 May 2024 02:44:58 GMT
Subject: RFR: 8331724: Refactor j.l.constant implementation to internal
 package [v6]
In-Reply-To: <9WHMhsSwQeR2N4pqfrTtdNktGBlEVPHwh4-92tY0dVM=.6b2a06af-817f-4f06-9cdf-1d215972b436@github.com>
References: <_GPUF9d1E6eBKRxP6bEEqA3LSKRJe2GwCRTfVYbDwFU=.cb482785-e7c4-45f7-bd3a-cd32d466a2cb@github.com>
 <-XO7o4O_fosLQ-I2ZH6WROkMtCJ_G978GPfEma9QFEU=.916fb3c0-6599-416a-bfb1-e3329f262928@github.com>
 <9WHMhsSwQeR2N4pqfrTtdNktGBlEVPHwh4-92tY0dVM=.6b2a06af-817f-4f06-9cdf-1d215972b436@github.com>
Message-ID: <9Oi3ig8yQ_OMFGotEdnU62j7TGuQoHh7v3GCGa_1las=.a4305204-5046-4da3-961b-c788ca767b66@github.com>

On Thu, 9 May 2024 02:28:16 GMT, ExE Boss <duke at openjdk.org> wrote:

>> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Validate after copying to avoid TOCTOU
>
> src/java.base/share/classes/jdk/internal/constant/MethodTypeDescImpl.java line 189:
> 
>> 187:         // Validate after copying to avoid TOCTOU
>> 188:         for (int i = pos; i < destPos; i++) {
>> 189:             validateArgument(argTypes[i]);
> 
> Suggestion:
> 
>             validateArgument(newArgs[i]);

Weird that this is not caught by MethodTypeDescTest.assertMethodType for no-arg method types.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19105#discussion_r1594896764

From liach at openjdk.org  Thu May  9 02:50:51 2024
From: liach at openjdk.org (Chen Liang)
Date: Thu, 9 May 2024 02:50:51 GMT
Subject: RFR: 8331879: Clean up non-standard use of /// comments in
 `java.base`
In-Reply-To: <JKCovwpov4A3Uddzf6N0AnZSb3Znv-7MEfMGec6IhR4=.93e4ad8e-344b-4890-8f25-c2752287024c@github.com>
References: <JKCovwpov4A3Uddzf6N0AnZSb3Znv-7MEfMGec6IhR4=.93e4ad8e-344b-4890-8f25-c2752287024c@github.com>
Message-ID: <_glS4D3sAUyLVpgE4VNYRE75EygU2H90l7wqUYIXRDU=.874b8779-fd36-44dc-bfe2-138dd7a3a7bd@github.com>

On Thu, 9 May 2024 02:09:50 GMT, xiaotaonan <duke at openjdk.org> wrote:

> Clean up non-standard use of /// comments in `java.base`

Related to #19130. Good catch, these were probably not detected because they were compiled at Java 8 language level and thus not detected by the new compiler warnings.

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

PR Comment: https://git.openjdk.org/jdk/pull/19151#issuecomment-2101834976

From liach at openjdk.org  Thu May  9 03:01:53 2024
From: liach at openjdk.org (Chen Liang)
Date: Thu, 9 May 2024 03:01:53 GMT
Subject: RFR: 8331957: Release Note: System Property for Java SE
 Specification Maintenance Version
In-Reply-To: <b0_uutHu72mHVmE6qQf0i9oS-5kUNFtJz_rS5aVeB18=.8ada78c9-490f-4603-a596-53c803a3a1d8@github.com>
References: <b0_uutHu72mHVmE6qQf0i9oS-5kUNFtJz_rS5aVeB18=.8ada78c9-490f-4603-a596-53c803a3a1d8@github.com>
Message-ID: <C86enqjQ8m6Fm5devM7KOhRsWptYJlTha7L5Z6gv7GM=.5961cc77-8d85-4ecf-b155-3f46acd3629b@github.com>

On Thu, 9 May 2024 00:49:43 GMT, xiaotaonan <duke at openjdk.org> wrote:

> ?ersion
> 
> Release Note: System Property for Java SE Specification Maintenance Version

@xiaotaonan For your information, "Release Note" issues are not bugs or features that require a pull request, but Java Bug System tasks that serve as a reminder for release notes for a new Java release like at https://www.oracle.com/java/technologies/javase/22-relnote-issues.html

And this uncommenting is only intended for maintenance releases in reference implementations (Such as https://github.com/openjdk/jdk11u-ri/commit/e5ac7a1b7e8df1e56a7e78bba6a2b9ed7fc297f1 and https://github.com/openjdk/jdk17u-ri/commit/c2c9e7fb8c857e40bc43b4053c2633825d4fb68e). See #8437 as well.

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

PR Comment: https://git.openjdk.org/jdk/pull/19149#issuecomment-2101845256

From duke at openjdk.org  Thu May  9 03:56:59 2024
From: duke at openjdk.org (duke)
Date: Thu, 9 May 2024 03:56:59 GMT
Subject: Withdrawn: 8324433: Introduce a way to determine if an expression is
 evaluated as a constant by the Jit compiler
In-Reply-To: <xz5-v3-LBZ6G8VWCW9MOoyFama7RsEYP8QeiHWFqPls=.6a6b9dfb-e6ed-455d-b6a1-c804abdc6ec0@github.com>
References: <xz5-v3-LBZ6G8VWCW9MOoyFama7RsEYP8QeiHWFqPls=.6a6b9dfb-e6ed-455d-b6a1-c804abdc6ec0@github.com>
Message-ID: <loyPKTAOcroJoifIZnYU5nuh1B7WhshDcvhGpaVTsdg=.d53e1a61-2145-468e-b74e-b30b83d7f234@github.com>

On Tue, 23 Jan 2024 08:10:54 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

> Hi,
> 
> This patch introduces `JitCompiler::isConstantExpression` which can be used to statically determine whether an expression has been constant-folded by the Jit compiler, leading to more constant-folding opportunities. For example, it can be used in `MemorySessionImpl::checkValidStateRaw` to eliminate the lifetime check on global sessions without imposing additional branches on other non-global sessions. This is similar to `__builtin_constant_p` in GCC and clang.
> 
> Please kindly give your opinion as well as your reviews, thanks very much.

This pull request has been closed without being integrated.

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

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

From duke at openjdk.org  Thu May  9 03:58:56 2024
From: duke at openjdk.org (Chris Hennick)
Date: Thu, 9 May 2024 03:58:56 GMT
Subject: RFR: 8326227: Rounding error that may distort computeNextGaussian
 results [v3]
In-Reply-To: <At-2-pCkpOZRRYsCcyet13TQ7p8RBY0jSiKi4MGiVME=.e512a201-eedb-4aa4-a5e3-da70622ab886@github.com>
References: <mG562d8Xt55WPLUaLOI7f0UcsgUSnOld4tlbJNVlnFI=.a6220bee-54e3-41e0-afde-2df71a91dfdc@github.com>
 <At-2-pCkpOZRRYsCcyet13TQ7p8RBY0jSiKi4MGiVME=.e512a201-eedb-4aa4-a5e3-da70622ab886@github.com>
Message-ID: <68EGloykZoxV6IUFMEdsIas6LqJG0W4wjzfU-PmyTyY=.5a48c97b-7858-4321-804d-8e23fb9f0383@github.com>

On Wed, 21 Feb 2024 02:18:08 GMT, Chris Hennick <duke at openjdk.org> wrote:

>> This provides a slightly more accurate bounding limit for `computeNextExponentialSoftCapped` when calling it from `computeNextGaussian`. This could cause the `while (computeNextExponentialSoftCapped(rng, limit) < limit)` check in `computeNextGaussian` on line 1402 to always be true, making the `nextGaussian` runtime unbounded in the worst case; but more likely, it would give a result that was truncated too close to zero.
>> 
>> This change is being tested prior to submission to OpenJDK by https://github.com/openjdk/jdk/pull/17703/commits/b8be051cbf40a6a05fafc6a2c76942e9e0b11fdf.
>
> Chris Hennick has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Bug fix: add-exports was for wrong package

Keep open. @JimLaskey it looks like you're the author of most of the surrounding code; can you please confirm that there's a rounding error in the existing implementation and that this PR will fix it?

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

PR Comment: https://git.openjdk.org/jdk/pull/17703#issuecomment-2101885931

From duke at openjdk.org  Thu May  9 04:03:10 2024
From: duke at openjdk.org (duke)
Date: Thu, 9 May 2024 04:03:10 GMT
Subject: Withdrawn: 8291027: Some of TimeZone methods marked 'synchronized'
 unnecessarily
In-Reply-To: <iEXWHDliZOeHKlAwqUuIRgVU2fXmx3QTJMkEpRdy4sE=.89004531-c9d0-434a-ab8f-d7e9e2a57281@github.com>
References: <iEXWHDliZOeHKlAwqUuIRgVU2fXmx3QTJMkEpRdy4sE=.89004531-c9d0-434a-ab8f-d7e9e2a57281@github.com>
Message-ID: <Im2Ggm_IJG3vskAkeFbyw1W5mCkgBhzOb7VQxMF4fFI=.75696e43-c9b9-428f-9b89-9f872b36f791@github.com>

On Tue, 16 Jan 2024 10:19:44 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> There are 3 methods in `java.util.TimeZone` which are `public static` and marked as `synchronized`:
> 1. getTimeZone(String)
> 2. getAvailableIDs(int)
> 3. getAvailableIDs()
> 
> This means it is a bottle neck for the whole VM.
> I've checked the implementation and concluded that `synchronized` is unnecessary.

This pull request has been closed without being integrated.

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

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

From duke at openjdk.org  Thu May  9 04:09:02 2024
From: duke at openjdk.org (duke)
Date: Thu, 9 May 2024 04:09:02 GMT
Subject: Withdrawn: 8323186: A faster algorithm for
 MutablebigInteger.divWord(long, int)
In-Reply-To: <KbavQbcdhWcYQRsj4NmGO8F7a853ZNLKPXkXGx_pfMU=.7679eb88-47a4-4013-80f9-b0b953d2b7fb@github.com>
References: <KbavQbcdhWcYQRsj4NmGO8F7a853ZNLKPXkXGx_pfMU=.7679eb88-47a4-4013-80f9-b0b953d2b7fb@github.com>
Message-ID: <pQmYL57KSNJjIygty_kMOO_UMqmmBwxAK42J0YyiSV0=.75351392-17fa-4cba-8f52-3f3013e09fb6@github.com>

On Sat, 6 Jan 2024 18:01:01 GMT, fabioromano1 <duke at openjdk.org> wrote:

> The method `MutableBigInteger.divWord(long, int)` can use the algorithm of Hacker's Delight (2nd ed), section 9.3, the same used in `Long.divideUnsigned(long, long)` and `Long.remainderUnsigned(long, long)`, to get the computation faster.

This pull request has been closed without being integrated.

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

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

From duke at openjdk.org  Thu May  9 04:13:07 2024
From: duke at openjdk.org (duke)
Date: Thu, 9 May 2024 04:13:07 GMT
Subject: Withdrawn: 8322292: Rearrange comparison of fields in Record.equals()
In-Reply-To: <eNySqrZ9HgZrjF61lHA_6YecuPT7RB9xxz82U3zIjog=.f8b68ce5-3fab-4cfa-8709-17e51d77a958@github.com>
References: <eNySqrZ9HgZrjF61lHA_6YecuPT7RB9xxz82U3zIjog=.f8b68ce5-3fab-4cfa-8709-17e51d77a958@github.com>
Message-ID: <NpwTZOu6G6astk--ktB5EFrGtAXMgbV0UC0F0fuhk2s=.ffaf4974-ae9a-4a92-9f32-898626cac029@github.com>

On Mon, 18 Dec 2023 13:42:35 GMT, Sergey Tsypanov <stsypanov at openjdk.org> wrote:

> Currently if we create a record it's fields are compared in their declaration order. This might be ineffective in cases when two objects have "heavy" fields equals to each other, but different "lightweight" fields (heavy and lightweight in terms of comparison) e.g. primitives, enums, nullable/non-nulls etc.
> 
> If we have declared a record like
> 
> public record MyRecord(String field1, int field2) {}
> 
> It's equals() looks like:
> 
>   public final equals(Ljava/lang/Object;)Z
>    L0
>     LINENUMBER 3 L0
>     ALOAD 0
>     ALOAD 1
>     INVOKEDYNAMIC equals(Lcom/caspianone/openbanking/productservice/controller/MyRecord;Ljava/lang/Object;)Z [
>       // handle kind 0x6 : INVOKESTATIC
>       java/lang/runtime/ObjectMethods.bootstrap(Ljava/lang/invoke/MethodHandles$Lookup;Ljava/lang/String;Ljava/lang/invoke/TypeDescriptor;Ljava/lang/Class;Ljava/lang/String;[Ljava/lang/invoke/MethodHandle;)Ljava/lang/Object;
>       // arguments:
>       com.caspianone.openbanking.productservice.controller.MyRecord.class,
>       "field1;field2",
>       // handle kind 0x1 : GETFIELD
>       com/caspianone/openbanking/productservice/controller/MyRecord.field1(Ljava/lang/String;),
>       // handle kind 0x1 : GETFIELD
>       com/caspianone/openbanking/productservice/controller/MyRecord.field2(I)
>     ]
>     IRETURN
>    L1
>     LOCALVARIABLE this Lcom/caspianone/openbanking/productservice/controller/MyRecord; L0 L1 0
>     LOCALVARIABLE o Ljava/lang/Object; L0 L1 1
>     MAXSTACK = 2
>     MAXLOCALS = 2
> 
> This can be improved by rearranging the comparison order of the fields moving enums and primitives upper, and collections/arrays lower.

This pull request has been closed without being integrated.

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

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

From duke at openjdk.org  Thu May  9 04:23:02 2024
From: duke at openjdk.org (duke)
Date: Thu, 9 May 2024 04:23:02 GMT
Subject: Withdrawn: 8320759: Creation of random BigIntegers can be made faster
In-Reply-To: <wIuR7gaQWIRdb8DtEN1VXi9dNkUMuKn8zv3Myc4V2gc=.3356e893-5322-4bb4-aa37-731fb6e9a4b0@github.com>
References: <wIuR7gaQWIRdb8DtEN1VXi9dNkUMuKn8zv3Myc4V2gc=.3356e893-5322-4bb4-aa37-731fb6e9a4b0@github.com>
Message-ID: <1XT1uCoGjU1K8VNH-vIY0AQ9yn-sJ8Ijgdgo2hzeTgM=.66071563-cf68-4764-83ef-981c28dad3c4@github.com>

On Sun, 26 Nov 2023 16:52:40 GMT, fabioromano1 <duke at openjdk.org> wrote:

> A faster and simpler way to generate random BigIntegers, avoiding eventually trimming of leading zeros in magnitude array.

This pull request has been closed without being integrated.

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

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

From asotona at openjdk.org  Thu May  9 07:08:59 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Thu, 9 May 2024 07:08:59 GMT
Subject: RFR: 8311175: Move BufWriter::asByteBuffer to BufWriterImpl [v2]
In-Reply-To: <WidMqWYS_MrCK8InUBA6eJBAgPDS864GiE58fV-UDgA=.f4be212d-450b-4e60-8b2e-09d596285313@github.com>
References: <sEKITMKa0yBPrV7RTKYa0_GGSOss8a9T7GaOQpLaEYk=.f7ad0b39-bc77-4589-a8de-ef5132387e6c@github.com>
 <WidMqWYS_MrCK8InUBA6eJBAgPDS864GiE58fV-UDgA=.f4be212d-450b-4e60-8b2e-09d596285313@github.com>
Message-ID: <IVqatphI33UgcrN9nDLqOfUsw0IiJWfLvIRZAjk9D7w=.2cbdd281-bd7b-4932-b7c3-f851abd70a22@github.com>

On Tue, 7 May 2024 15:30:25 GMT, Chen Liang <liach at openjdk.org> wrote:

>> As discussed on the mailing list https://mail.openjdk.org/pipermail/classfile-api-dev/2023-June/000381.html, BufWriter::asByteBuffer has a behavior not suitable for API and is only used by internal StackMapGenerator/StackCounter, so it will be converted to an internal API.
>> 
>> Somehow the ByteBuffer needs to be sliced, or StackMapGenerator encounters IOOBE. Not sure what the exact cause was.
>
> Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:
> 
>  - Merge branch 'master' of https://github.com/openjdk/jdk into fix/asbb-internal
>  - Convert asByteBuffer to an internal API

Looks good, thanks!

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

Marked as reviewed by asotona (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14736#pullrequestreview-2047286767

From alanb at openjdk.org  Thu May  9 07:23:56 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 9 May 2024 07:23:56 GMT
Subject: RFR: 8331876: JFR: Move file read and write events to java.base
In-Reply-To: <DDe0bKCC86AawVl7RylZ74uvvLBr2Zljpkcmxx1_WEU=.61cc10c6-b635-42dd-a850-b32ae1d68585@github.com>
References: <DDe0bKCC86AawVl7RylZ74uvvLBr2Zljpkcmxx1_WEU=.61cc10c6-b635-42dd-a850-b32ae1d68585@github.com>
Message-ID: <3jqGe0bFYpJEV4R8uk-IuJrpXtujcRlti7mZ2mC-K-Y=.028d74ad-858b-4744-8390-59a3b85a4eb8@github.com>

On Tue, 7 May 2024 19:32:57 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> Hi,
> 
> Could I have a review of a change that moves the jdk.FileRead and jdk.FileWrite events to java.base to remove the use of the ASM instrumentation.
> 
> Testing: jdk/jdk/jfr
> 
> Thanks
> Erik

src/java.base/share/classes/sun/nio/ch/FileChannelImpl.java line 78:

> 76: 
> 77:     // Flag that determines if file reads/writes should be traced by JFR
> 78:     private static boolean jfrTracing;

Should the force method be changed to test this flag too?

I'm also wondering about the transferXXX methods. We might want to think about these for a separate PR as they have more potential to be outliers than the read/write methods.

src/java.base/share/classes/sun/nio/ch/FileChannelImpl.java line 233:

> 231:     }
> 232: 
> 233:     private int readImpl(ByteBuffer dst) throws IOException {

Would you mind renaming these to implXXX rather than XXXImpl? The implXXX is the convention in this area (including in the API).

For placement, the read methods are grouped, and the write methods are grouped, only to avoid needing to jump around the file when touching this code. So I think easier if the methods that wraps implRead be located with the read methods.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19129#discussion_r1595068674
PR Review Comment: https://git.openjdk.org/jdk/pull/19129#discussion_r1595058030

From asotona at openjdk.org  Thu May  9 07:25:52 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Thu, 9 May 2024 07:25:52 GMT
Subject: RFR: 8331744: java.lang.classfile.TypeKind improvements [v4]
In-Reply-To: <-6l188kBfGFxic3KxI-qxyVpPWEbwt4Z5O1nJbfCHQQ=.e460344f-b23f-4dcd-95a3-a12f478687d7@github.com>
References: <_x31CU5mODg3NGaRGzI5HdNdcjsKmqWb1TA7KZnZcFg=.43ce5ba3-71e7-42e5-a531-c3b609d0aafb@github.com>
 <-6l188kBfGFxic3KxI-qxyVpPWEbwt4Z5O1nJbfCHQQ=.e460344f-b23f-4dcd-95a3-a12f478687d7@github.com>
Message-ID: <2ehu58tQasyDZc-dqUtnjUdazTfEXl9F_-4jimHTmHY=.37ab1963-092e-41d6-a751-7a33c05e66db@github.com>

On Tue, 7 May 2024 15:23:10 GMT, Chen Liang <liach at openjdk.org> wrote:

>> A peek into TypeKind during the research for #19105 reveals that TypeKind has a few issues:
>> 1. Name mismatch for `newarraycode` and `fromNewArrayCode`: Renamed both to use "newarray code"
>> 2. `fromDescriptor` can throw IOOBE if the input string is empty: changed to throw IAE and added tests.
>> 3. `from(Class)` can be slow due to descriptor computation: added benchmark, will share result in next comment (as it may change with code changes).
>> 
>> The first 2 changes involves API changes, and a CSR has been created. Requesting @asotona for a review.
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Hash table, use fixed random seed

src/java.base/share/classes/java/lang/classfile/TypeKind.java line 139:

> 137:             case 'V' -> TypeKind.VoidType;
> 138:             default -> throw new IllegalArgumentException("Bad type: " + s);
> 139:         };

This maps to a `tableswitch`, could you explain why a statically initialized array addressed with a custom hash code suppose to be faster?
Thanks.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19109#discussion_r1595070662

From egahlin at openjdk.org  Thu May  9 07:38:53 2024
From: egahlin at openjdk.org (Erik Gahlin)
Date: Thu, 9 May 2024 07:38:53 GMT
Subject: RFR: 8331876: JFR: Move file read and write events to java.base
In-Reply-To: <3jqGe0bFYpJEV4R8uk-IuJrpXtujcRlti7mZ2mC-K-Y=.028d74ad-858b-4744-8390-59a3b85a4eb8@github.com>
References: <DDe0bKCC86AawVl7RylZ74uvvLBr2Zljpkcmxx1_WEU=.61cc10c6-b635-42dd-a850-b32ae1d68585@github.com>
 <3jqGe0bFYpJEV4R8uk-IuJrpXtujcRlti7mZ2mC-K-Y=.028d74ad-858b-4744-8390-59a3b85a4eb8@github.com>
Message-ID: <67gSQFkt4YT6jJcAqpFemfrxCMls8YvlkwuPiplqco8=.fbf7550c-3297-4678-a8cd-648c71df79e0@github.com>

On Thu, 9 May 2024 07:20:55 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Hi,
>> 
>> Could I have a review of a change that moves the jdk.FileRead and jdk.FileWrite events to java.base to remove the use of the ASM instrumentation.
>> 
>> Testing: jdk/jdk/jfr
>> 
>> Thanks
>> Erik
>
> src/java.base/share/classes/sun/nio/ch/FileChannelImpl.java line 78:
> 
>> 76: 
>> 77:     // Flag that determines if file reads/writes should be traced by JFR
>> 78:     private static boolean jfrTracing;
> 
> Should the force method be changed to test this flag too?
> 
> I'm also wondering about the transferXXX methods. We might want to think about these for a separate PR as they have more potential to be outliers than the read/write methods.

I think it would be good to use the flag for all events, but I rather do it as separate PR so this is mostly a mechanical change to remove ASM. It makes it easier to track regressions or improvements.

I can file an enhancement for the transferXXX methods.

> src/java.base/share/classes/sun/nio/ch/FileChannelImpl.java line 233:
> 
>> 231:     }
>> 232: 
>> 233:     private int readImpl(ByteBuffer dst) throws IOException {
> 
> Would you mind renaming these to implXXX rather than XXXImpl? The implXXX is the convention in this area (including in the API).
> 
> For placement, the read methods are grouped, and the write methods are grouped, only to avoid needing to jump around the file when touching this code. So I think easier if the methods that wraps implRead be located with the read methods.

Will fix.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19129#discussion_r1595080275
PR Review Comment: https://git.openjdk.org/jdk/pull/19129#discussion_r1595080544

From jwaters at openjdk.org  Thu May  9 07:50:00 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Thu, 9 May 2024 07:50:00 GMT
Subject: RFR: 8330988: Implementation of 8288293: Windows/gcc Port for
 hsdis [v2]
In-Reply-To: <bXwOUFPBZUWDmidfDnVJLBKG4HkeS585IJqAOK8W1ys=.211183fe-b18e-498d-a557-6e6c4dfac27c@github.com>
References: <bXwOUFPBZUWDmidfDnVJLBKG4HkeS585IJqAOK8W1ys=.211183fe-b18e-498d-a557-6e6c4dfac27c@github.com>
Message-ID: <xvXZ9TddIGBdQqUJ0c_MccUw7lPjJqeTZzrPYJG-EyQ=.59e09c22-93b5-4271-9cc7-60b1d1f90a8e@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.

Julian Waters has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:

 - Add check for compiler in configure
 - 8330988: Implementation of 8288293: Windows/gcc Port for hsdis

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

Changes: https://git.openjdk.org/jdk/pull/18915/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18915&range=01
  Stats: 334 lines in 19 files changed: 154 ins; 25 del; 155 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 jwaters at openjdk.org  Thu May  9 07:50:01 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Thu, 9 May 2024 07:50:01 GMT
Subject: RFR: 8330988: Implementation of 8288293: Windows/gcc Port for
 hsdis
In-Reply-To: <usSjNoHaMLDK2yN1CVz7X91uSIbpQslnD0hBtTFtnsw=.e7b4dede-07bf-41af-bef1-02672ef4758d@github.com>
References: <bXwOUFPBZUWDmidfDnVJLBKG4HkeS585IJqAOK8W1ys=.211183fe-b18e-498d-a557-6e6c4dfac27c@github.com>
 <usSjNoHaMLDK2yN1CVz7X91uSIbpQslnD0hBtTFtnsw=.e7b4dede-07bf-41af-bef1-02672ef4758d@github.com>
Message-ID: <L6Nie71UyBRtKtOJsoSAtXLozRfoOnRb2xzJyG0hd1k=.f095eb19-64c2-49aa-9081-cdc08f4868b3@github.com>

On Wed, 24 Apr 2024 09:15:21 GMT, Magnus Ihse Bursie <ihse 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.

@magicus I think I might need some help here. Currently all the Cygwin stuff is gated behind ifeq ($(TOOLCHAIN_TYPE), microsoft) checks... should they be behind isBuildOsEnv cygwin checks instead? I don't know how to add support for Cygwin gcc for most of hsdis, since it is quite different from the more modern gcc distributions that are found in places like MSYS2 and MINGW64. But most of the existing logic seems to accomodate more for the Microsoft compiler than it is concerned about the OS environment being used, and for this reason I can't tell which of the 2 checks to use for the existing hack that switches from microsoft to gcc. Also, gcc doesn't require FIXPATH, but Microsoft does, but I don't want to check for microsoft inside TOOLCHAIN_FIND_COMPILER, what should I do instead to ensure gcc doesn't get FIXPATH while Microsoft does?

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

PR Comment: https://git.openjdk.org/jdk/pull/18915#issuecomment-2097196121

From jwaters at openjdk.org  Thu May  9 07:56:51 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Thu, 9 May 2024 07:56:51 GMT
Subject: RFR: 8330988: Implementation of 8288293: Windows/gcc Port for
 hsdis
In-Reply-To: <usSjNoHaMLDK2yN1CVz7X91uSIbpQslnD0hBtTFtnsw=.e7b4dede-07bf-41af-bef1-02672ef4758d@github.com>
References: <bXwOUFPBZUWDmidfDnVJLBKG4HkeS585IJqAOK8W1ys=.211183fe-b18e-498d-a557-6e6c4dfac27c@github.com>
 <usSjNoHaMLDK2yN1CVz7X91uSIbpQslnD0hBtTFtnsw=.e7b4dede-07bf-41af-bef1-02672ef4758d@github.com>
Message-ID: <77xRfJh_yNfE406Tl9KCpkdlOvGQGzayTUe3fuej-QQ=.3d33f404-3a20-4836-91aa-00469a46018f@github.com>

On Wed, 24 Apr 2024 09:15:21 GMT, Magnus Ihse Bursie <ihse 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.

Also @magicus, what is the typical path passed to --with-binutils like on Windows? Something like --with-binutils=/c/Users/vertig0/Downloads/binutils-2.42 doesn't work correctly, since the include path to dis-asm.h would then become
`#include "/c/Users/vertig0/Downloads/binutils-2.42/include/dis-asm.h"`
Which causes a configure check to fail on the compile stage since gcc cannot recognise the MINGW-esque /c/ as a drive, and then causes configure to erroneously report binutils as using the Old API when it's in fact using the New API. --with-binutils=C:/Users/vertig0/Downloads/binutils-2.42 on the other hand works as expected. Should there be a fixup for the path there so gcc can recognise it properly?

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

PR Comment: https://git.openjdk.org/jdk/pull/18915#issuecomment-2102146604

From dholmes at openjdk.org  Thu May  9 08:21:52 2024
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 9 May 2024 08:21:52 GMT
Subject: RFR: 8330205: Initial troff manpage generation for JDK 24
In-Reply-To: <6tFYXJ753At7nUZTy8khVVeiQHYtZRBRYegXSTXViUY=.f3110151-9ea0-4b55-89f1-90039273fd34@github.com>
References: <6tFYXJ753At7nUZTy8khVVeiQHYtZRBRYegXSTXViUY=.f3110151-9ea0-4b55-89f1-90039273fd34@github.com>
Message-ID: <6PQqK1kADFKALT6GNcnAiRvM1TykSgCTK5m84MRscIE=.538243ee-787b-45ae-8b0e-44cca343ebc9@github.com>

On Tue, 7 May 2024 11:53:19 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> Please review this mechanical change to man pages. This PR should be integrated after https://github.com/openjdk/jdk/pull/18787.

I think we may have to restore this to a standalone start-of-release change done after the other start-of-release changes. I had forgotten about the need to update the flags sections of java.1

src/java.base/share/man/java.1 line 3856:

> 3854: .SH REMOVED JAVA OPTIONS
> 3855: .PP
> 3856: These \f[V]java\f[R] options have been removed in JDK 24 and using them

This is incorrect. You can't just change 23 to 24 here as the actual set of flags listed below will be will be different.

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

Changes requested by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19119#pullrequestreview-2047411800
PR Review Comment: https://git.openjdk.org/jdk/pull/19119#discussion_r1595128505

From duke at openjdk.org  Thu May  9 09:10:20 2024
From: duke at openjdk.org (serhiysachkov)
Date: Thu, 9 May 2024 09:10:20 GMT
Subject: RFR: 8331646: Add specific regression leap year tests [v4]
In-Reply-To: <cB-Q8ihe6DYQTm1WcRvVV3oW8YXtnWH5fmsS1zurwwY=.176d4137-bd3b-445e-a055-c738bd73744c@github.com>
References: <cB-Q8ihe6DYQTm1WcRvVV3oW8YXtnWH5fmsS1zurwwY=.176d4137-bd3b-445e-a055-c738bd73744c@github.com>
Message-ID: <9VgLKRC2j_6DXZCeEcprn5sCYYWu_FDo1SHD7bAHVnQ=.1fb7a7a8-d8f4-4ae9-abfe-7aaa6cd4722f@github.com>

> Calendar.add() tests that describe its behavior.

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

  JDK-8331646 updating impl according to review requests

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/19082/files
  - new: https://git.openjdk.org/jdk/pull/19082/files/4bb425da..f6ba2e31

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

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

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

From asotona at openjdk.org  Thu May  9 09:20:59 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Thu, 9 May 2024 09:20:59 GMT
Subject: RFR: 8320396: Class-File API ClassModel::verify should include
 checks from hotspot/share/classfile/classFileParser.cpp [v4]
In-Reply-To: <FqTY8dgxHxjg8Frj1cJlSUL8HsoByOiD6CwpAFJIIyw=.b4041717-5661-4eea-8f4c-7c36bdec3d90@github.com>
References: <0a66asWcJ4_zBrjmReA18BZmsovN1ZeJRRSAPZDMZmo=.5bada03f-d88d-46cd-962d-c1e42c3048c1@github.com>
 <qPSb3Xaw2eNwYqG7vbfWfKbvS0doeN1yG8Uvh1dkhCE=.366c0ba1-26c5-463e-9b26-f0d9428879ea@github.com>
 <FqTY8dgxHxjg8Frj1cJlSUL8HsoByOiD6CwpAFJIIyw=.b4041717-5661-4eea-8f4c-7c36bdec3d90@github.com>
Message-ID: <6zG4RZnZRJkYU0k-FgF_jGgVNwR91Pwd6aNdr4AQJPA=.4017aa8d-975a-4d22-903e-05ca851590a3@github.com>

On Tue, 7 May 2024 18:39:40 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Adam Sotona has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 28 commits:
>> 
>>  - Merge branch 'master' into JDK-8320396-verifier-extension
>>  - added references to jvms
>>  - Merge remote-tracking branch 'openjdk/master' into JDK-8320396-verifier-extension
>>  - work in progress
>>  - work in progress
>>  - work in progress
>>  - work in progress
>>  - work in progress
>>  - removed string templates from test
>>  - work in progress
>>  - ... and 18 more: https://git.openjdk.org/jdk/compare/ae82405f...3ebc780a
>
> src/java.base/share/classes/jdk/internal/classfile/impl/verifier/ParserVerifier.java line 97:
> 
>> 95:                     check.accept(fre.owner()::asSymbol);
>> 96:                     check.accept(fre::typeSymbol);
>> 97:                     yield () -> verifyFieldName(fre.name().stringValue());
> 
> Nitpick, we should avoid capturing the check instance and just do something like:
> 
>                 case FieldRefEntry fre -> () -> {
>                     fre.owner().asSymbol();
>                     fre.typeSymbol();
>                     verifyFieldName(fre.name().stringValue());
>                 };

The above code logs all errors individually.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16809#discussion_r1595196242

From attila at openjdk.org  Thu May  9 09:37:56 2024
From: attila at openjdk.org (Attila Szegedi)
Date: Thu, 9 May 2024 09:37:56 GMT
Subject: RFR: 8325679: Optimize ArrayList subList sort [v4]
In-Reply-To: <sAXN5Z3tshLGru7GQLw7KAXqGvwwJQo8_K69VVL7luw=.f9055ab3-4316-4b52-897d-a6bde99400bd@github.com>
References: <DruTgFzQmTSLjZHTdyZFqLJ48CYFLYuhz-fpG0rQXnc=.de8bb8ac-eab4-4f05-8f73-5ca6a5c7b727@github.com>
 <sAXN5Z3tshLGru7GQLw7KAXqGvwwJQo8_K69VVL7luw=.f9055ab3-4316-4b52-897d-a6bde99400bd@github.com>
Message-ID: <bd0n9spBCpZhG9Q9IKPxvBkAsW_PyKv4PWhtaH_sgws=.cd5307aa-c745-409b-8ba6-49155c4c3ffc@github.com>

On Mon, 19 Feb 2024 10:05:24 GMT, Attila Szegedi <attila at openjdk.org> wrote:

>> Somewhat surprisingly, `ArrayList$Sublist.sort()` is not specialized and will thus fall back to slower default method of `List.sort()` instead of sorting a range of the array in-place in its backing root `ArrayList`. 
>> 
>> This doesn't change observable behavior, so haven't added tests, and `tier1` tests still all pass except for `test/jdk/java/util/Locale/LocaleProvidersFormat.java` which also currently fails on master too on the machine I tested on.
>
> Attila Szegedi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove test

Keep it open, please.

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

PR Comment: https://git.openjdk.org/jdk/pull/17818#issuecomment-2102305815

From asotona at openjdk.org  Thu May  9 09:38:00 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Thu, 9 May 2024 09:38:00 GMT
Subject: RFR: 8320396: Class-File API ClassModel::verify should include
 checks from hotspot/share/classfile/classFileParser.cpp [v4]
In-Reply-To: <FqTY8dgxHxjg8Frj1cJlSUL8HsoByOiD6CwpAFJIIyw=.b4041717-5661-4eea-8f4c-7c36bdec3d90@github.com>
References: <0a66asWcJ4_zBrjmReA18BZmsovN1ZeJRRSAPZDMZmo=.5bada03f-d88d-46cd-962d-c1e42c3048c1@github.com>
 <qPSb3Xaw2eNwYqG7vbfWfKbvS0doeN1yG8Uvh1dkhCE=.366c0ba1-26c5-463e-9b26-f0d9428879ea@github.com>
 <FqTY8dgxHxjg8Frj1cJlSUL8HsoByOiD6CwpAFJIIyw=.b4041717-5661-4eea-8f4c-7c36bdec3d90@github.com>
Message-ID: <e1GRFwL5Z1Fj43U1O9w_o87MhHVatqiQbarcKd2cIfY=.6ecd9a77-2828-4afa-99bc-4b3e911f3d05@github.com>

On Tue, 7 May 2024 18:42:24 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Adam Sotona has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 28 commits:
>> 
>>  - Merge branch 'master' into JDK-8320396-verifier-extension
>>  - added references to jvms
>>  - Merge remote-tracking branch 'openjdk/master' into JDK-8320396-verifier-extension
>>  - work in progress
>>  - work in progress
>>  - work in progress
>>  - work in progress
>>  - work in progress
>>  - removed string templates from test
>>  - work in progress
>>  - ... and 18 more: https://git.openjdk.org/jdk/compare/ae82405f...3ebc780a
>
> src/java.base/share/classes/jdk/internal/classfile/impl/verifier/ParserVerifier.java line 151:
> 
>> 149:         var fields = new HashSet<String>();
>> 150:         for (var f : classModel.fields()) try {
>> 151:             if (!fields.add(f.fieldName().stringValue() + f.fieldType().stringValue())) {
> 
> We should declare a local record, concat is not safe if we have fields like:
> 
> Loop foo;
> oop fooL;
> 
> both will producce `fooLLoop;`

Goo point, will fix it, thanks.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16809#discussion_r1595214650

From asotona at openjdk.org  Thu May  9 09:50:57 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Thu, 9 May 2024 09:50:57 GMT
Subject: RFR: 8320396: Class-File API ClassModel::verify should include
 checks from hotspot/share/classfile/classFileParser.cpp [v4]
In-Reply-To: <FqTY8dgxHxjg8Frj1cJlSUL8HsoByOiD6CwpAFJIIyw=.b4041717-5661-4eea-8f4c-7c36bdec3d90@github.com>
References: <0a66asWcJ4_zBrjmReA18BZmsovN1ZeJRRSAPZDMZmo=.5bada03f-d88d-46cd-962d-c1e42c3048c1@github.com>
 <qPSb3Xaw2eNwYqG7vbfWfKbvS0doeN1yG8Uvh1dkhCE=.366c0ba1-26c5-463e-9b26-f0d9428879ea@github.com>
 <FqTY8dgxHxjg8Frj1cJlSUL8HsoByOiD6CwpAFJIIyw=.b4041717-5661-4eea-8f4c-7c36bdec3d90@github.com>
Message-ID: <WDTKpNHSMZDxMa-quP1cZO87JeEpRMo-agStFvKVHsI=.4328b736-51bb-4201-be4c-c482a2b673a5@github.com>

On Tue, 7 May 2024 18:47:34 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Adam Sotona has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 28 commits:
>> 
>>  - Merge branch 'master' into JDK-8320396-verifier-extension
>>  - added references to jvms
>>  - Merge remote-tracking branch 'openjdk/master' into JDK-8320396-verifier-extension
>>  - work in progress
>>  - work in progress
>>  - work in progress
>>  - work in progress
>>  - work in progress
>>  - removed string templates from test
>>  - work in progress
>>  - ... and 18 more: https://git.openjdk.org/jdk/compare/ae82405f...3ebc780a
>
> src/java.base/share/classes/jdk/internal/classfile/impl/verifier/ParserVerifier.java line 167:
> 
>> 165:             }
>> 166:             if (m.methodName().equalsString(CLASS_INIT_NAME)
>> 167:                     && !m.flags().has(AccessFlag.STATIC)) {
> 
> Do we verify it has void return and (since class file version JAVA 7) takes no args? The static requirement is since JAVA 7 too.

This is a first round of transcription from `classFileParser.cpp` and I most probably missed many verifications applied there. Feel free to point to a specific verification code in the `classFileParser.cpp` I missed, however to avoid very complex synchronization I preferred to do not invent a custom list of verifications. Relevant parts are widely spread across the specifications and collecting and tracking them would be very complex task.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16809#discussion_r1595228471

From asotona at openjdk.org  Thu May  9 09:54:01 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Thu, 9 May 2024 09:54:01 GMT
Subject: RFR: 8320396: Class-File API ClassModel::verify should include
 checks from hotspot/share/classfile/classFileParser.cpp [v4]
In-Reply-To: <FqTY8dgxHxjg8Frj1cJlSUL8HsoByOiD6CwpAFJIIyw=.b4041717-5661-4eea-8f4c-7c36bdec3d90@github.com>
References: <0a66asWcJ4_zBrjmReA18BZmsovN1ZeJRRSAPZDMZmo=.5bada03f-d88d-46cd-962d-c1e42c3048c1@github.com>
 <qPSb3Xaw2eNwYqG7vbfWfKbvS0doeN1yG8Uvh1dkhCE=.366c0ba1-26c5-463e-9b26-f0d9428879ea@github.com>
 <FqTY8dgxHxjg8Frj1cJlSUL8HsoByOiD6CwpAFJIIyw=.b4041717-5661-4eea-8f4c-7c36bdec3d90@github.com>
Message-ID: <QsKbhMmBTzr_x4x3okgWhC767pD99_a-4VkIF3JY_YY=.38027b9d-a6d4-4963-888e-128e99a40614@github.com>

On Tue, 7 May 2024 18:50:28 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Adam Sotona has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 28 commits:
>> 
>>  - Merge branch 'master' into JDK-8320396-verifier-extension
>>  - added references to jvms
>>  - Merge remote-tracking branch 'openjdk/master' into JDK-8320396-verifier-extension
>>  - work in progress
>>  - work in progress
>>  - work in progress
>>  - work in progress
>>  - work in progress
>>  - removed string templates from test
>>  - work in progress
>>  - ... and 18 more: https://git.openjdk.org/jdk/compare/ae82405f...3ebc780a
>
> src/java.base/share/classes/jdk/internal/classfile/impl/verifier/ParserVerifier.java line 364:
> 
>> 362:                     className(),
>> 363:                     m.methodName().stringValue(),
>> 364:                     m.methodTypeSymbol().parameterList().stream().map(ClassDesc::displayName).collect(Collectors.joining(",")));
> 
> Suggestion:
> 
>                     m.methodTypeSymbol().displayDescriptor();
> 
> Can remove the parentheses above.

It intentionally prints only parameters and avoids return type.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16809#discussion_r1595232206

From asotona at openjdk.org  Thu May  9 10:06:56 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Thu, 9 May 2024 10:06:56 GMT
Subject: RFR: 8320396: Class-File API ClassModel::verify should include
 checks from hotspot/share/classfile/classFileParser.cpp [v4]
In-Reply-To: <FqTY8dgxHxjg8Frj1cJlSUL8HsoByOiD6CwpAFJIIyw=.b4041717-5661-4eea-8f4c-7c36bdec3d90@github.com>
References: <0a66asWcJ4_zBrjmReA18BZmsovN1ZeJRRSAPZDMZmo=.5bada03f-d88d-46cd-962d-c1e42c3048c1@github.com>
 <qPSb3Xaw2eNwYqG7vbfWfKbvS0doeN1yG8Uvh1dkhCE=.366c0ba1-26c5-463e-9b26-f0d9428879ea@github.com>
 <FqTY8dgxHxjg8Frj1cJlSUL8HsoByOiD6CwpAFJIIyw=.b4041717-5661-4eea-8f4c-7c36bdec3d90@github.com>
Message-ID: <IMSFNp3vWXf0PEPALbjSFejUyHERBZYiyIv9VXUfxEU=.3a8cda39-1e26-47a1-a41d-cf67226fa22d@github.com>

On Tue, 7 May 2024 18:51:28 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Adam Sotona has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 28 commits:
>> 
>>  - Merge branch 'master' into JDK-8320396-verifier-extension
>>  - added references to jvms
>>  - Merge remote-tracking branch 'openjdk/master' into JDK-8320396-verifier-extension
>>  - work in progress
>>  - work in progress
>>  - work in progress
>>  - work in progress
>>  - work in progress
>>  - removed string templates from test
>>  - work in progress
>>  - ... and 18 more: https://git.openjdk.org/jdk/compare/ae82405f...3ebc780a
>
> src/java.base/share/classes/jdk/internal/classfile/impl/verifier/VerificationWrapper.java line 134:
> 
>> 132:         }
>> 133: 
>> 134:         String parameters() {
> 
> We should just use the mtd's displayDescriptor, a class file can have bridge methods with covariant return types and the bridge may be broken while the concrete method is ok.

I preferred readability of the error messages over full information. 
Broken covariant is a corner case and exact method can be found even from the reduced info provided.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16809#discussion_r1595244945

From asotona at openjdk.org  Thu May  9 10:11:22 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Thu, 9 May 2024 10:11:22 GMT
Subject: RFR: 8320396: Class-File API ClassModel::verify should include
 checks from hotspot/share/classfile/classFileParser.cpp [v5]
In-Reply-To: <0a66asWcJ4_zBrjmReA18BZmsovN1ZeJRRSAPZDMZmo=.5bada03f-d88d-46cd-962d-c1e42c3048c1@github.com>
References: <0a66asWcJ4_zBrjmReA18BZmsovN1ZeJRRSAPZDMZmo=.5bada03f-d88d-46cd-962d-c1e42c3048c1@github.com>
Message-ID: <IXrF9AdBnUFrDOFKOrAsLZNJAOx05y4za-PoVzfIGpA=.80ed5ff3-d981-451e-90cc-ed65fa47f2b2@github.com>

> ClassFile API `jdk.internal.classfile.verifier.VerifierImpl` performed only bytecode-level class verification.
> This patch adds `jdk.internal.classfile.verifier.ParserVerifier` with additional class checks inspired by `hotspot/share/classfile/classFileParser.cpp`.
> 
> Also new `VerifierSelfTest::testParserVerifier` has been added.
> 
> Please review.
> 
> Thanks,
> Adam

Adam Sotona has updated the pull request incrementally with two additional commits since the last revision:

 - fixed error thrown by VerifierImpl
 - applied suggested changes

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16809/files
  - new: https://git.openjdk.org/jdk/pull/16809/files/3ebc780a..586fa4b3

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

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

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

From egahlin at openjdk.org  Thu May  9 10:11:39 2024
From: egahlin at openjdk.org (Erik Gahlin)
Date: Thu, 9 May 2024 10:11:39 GMT
Subject: RFR: 8331876: JFR: Move file read and write events to java.base
 [v2]
In-Reply-To: <DDe0bKCC86AawVl7RylZ74uvvLBr2Zljpkcmxx1_WEU=.61cc10c6-b635-42dd-a850-b32ae1d68585@github.com>
References: <DDe0bKCC86AawVl7RylZ74uvvLBr2Zljpkcmxx1_WEU=.61cc10c6-b635-42dd-a850-b32ae1d68585@github.com>
Message-ID: <EOq5JIM1QuHzL4TzhnftDlQSh21AR5ASvb49vjveJPg=.099fc26b-7958-4a08-be39-80d628b00fd4@github.com>

> Hi,
> 
> Could I have a review of a change that moves the jdk.FileRead and jdk.FileWrite events to java.base to remove the use of the ASM instrumentation.
> 
> Testing: jdk/jdk/jfr
> 
> Thanks
> Erik

Erik Gahlin has updated the pull request incrementally with one additional commit since the last revision:

  Rename methods

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/19129/files
  - new: https://git.openjdk.org/jdk/pull/19129/files/0802c684..9d02bf63

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

  Stats: 1251 lines in 16 files changed: 225 ins; 975 del; 51 mod
  Patch: https://git.openjdk.org/jdk/pull/19129.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19129/head:pull/19129

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

From prappo at openjdk.org  Thu May  9 11:15:53 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Thu, 9 May 2024 11:15:53 GMT
Subject: RFR: 8331535: Incorrect prompt for Console.readLine [v4]
In-Reply-To: <odGBY-01VvMY90f3GM90D6SDIFkm4DQPE0C1_5SAJGk=.e2fba76c-9946-4abc-8c83-cd34d6045735@github.com>
References: <IQvUAYG5zj0JqUbWiQiryAuBrtV6jrVCvy9useQZmlc=.a4dd8dfc-e835-4405-83f8-fd1bda8480f6@github.com>
 <odGBY-01VvMY90f3GM90D6SDIFkm4DQPE0C1_5SAJGk=.e2fba76c-9946-4abc-8c83-cd34d6045735@github.com>
Message-ID: <8wmaKKFSe9sRJviyzVlP_dK5N7NjM5wThurAXHSDLFk=.7dd6b418-e82c-4ed1-ab95-8737b99f997a@github.com>

On Tue, 7 May 2024 07:13:23 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> When JLine reads a line, there may be a prompt provided. However, JLine will not interpret the prompt literally, it will handle `%` specially. As a consequence, doing:
>> 
>> System.console().readLine("%%s");
>> 
>> 
>> will not print `%s`, as first `String.format` is used, which will convert `%%s` to `%s`, and then JLine will interpret the `%`. The proposed solution is to duplicate the `%`, so that JLine will print it.
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adding another test run with -Djdk.console=java.base, as suggested.

Jan, if you integrate it soon, I'll improve testing in https://github.com/openjdk/jdk/pull/19112. Thanks.

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

PR Comment: https://git.openjdk.org/jdk/pull/19081#issuecomment-2102463081

From egahlin at openjdk.org  Thu May  9 11:19:14 2024
From: egahlin at openjdk.org (Erik Gahlin)
Date: Thu, 9 May 2024 11:19:14 GMT
Subject: RFR: 8331876: JFR: Move file read and write events to java.base
 [v3]
In-Reply-To: <DDe0bKCC86AawVl7RylZ74uvvLBr2Zljpkcmxx1_WEU=.61cc10c6-b635-42dd-a850-b32ae1d68585@github.com>
References: <DDe0bKCC86AawVl7RylZ74uvvLBr2Zljpkcmxx1_WEU=.61cc10c6-b635-42dd-a850-b32ae1d68585@github.com>
Message-ID: <SejX7NAvWNjrhDEN8uDf4oikQDBRclWXDg1fN5FCpkc=.7de48c6f-0af2-4bf4-a743-6e173d950d52@github.com>

> Hi,
> 
> Could I have a review of a change that moves the jdk.FileRead and jdk.FileWrite events to java.base to remove the use of the ASM instrumentation.
> 
> Testing: jdk/jdk/jfr
> 
> Thanks
> Erik

Erik Gahlin has updated the pull request incrementally with one additional commit since the last revision:

  Move methods

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/19129/files
  - new: https://git.openjdk.org/jdk/pull/19129/files/9d02bf63..fc54e205

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

  Stats: 587 lines in 4 files changed: 293 ins; 294 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/19129.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19129/head:pull/19129

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

From eirbjo at openjdk.org  Thu May  9 11:39:56 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Thu, 9 May 2024 11:39:56 GMT
Subject: RFR: 8321274: Rename ZipEntry.extraAttributes to
 ZipEntry.externalFileAttributes [v4]
In-Reply-To: <58cWTca1j5r5WfGtN8281Vog-yABS7RF2oJOlBsoBVs=.f18b5ca1-e345-4c3b-a568-cff6c003e902@github.com>
References: <EcxkA01kaWJwev-16dqYXi7rODrgCBzWJRHL5A4rjA0=.7e65e59b-3086-463a-9558-04abfe1b0782@github.com>
 <58cWTca1j5r5WfGtN8281Vog-yABS7RF2oJOlBsoBVs=.f18b5ca1-e345-4c3b-a568-cff6c003e902@github.com>
Message-ID: <OO0eKLo4pbyX4VuXlOGhZ61B953_BB-eYw-sGHJAEcY=.23e7b7d6-3416-4f69-a0ed-b18bea822888@github.com>

On Fri, 8 Mar 2024 09:34:05 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

>> Please consider this PR which suggests we rename `ZipEntry.extraAttributes` to `ZipEntry.externalFileAttributes`.
>> 
>> This field was introduced in [JDK-8218021](https://bugs.openjdk.org/browse/JDK-8218021), originally under the name `ZipEntry.posixPerms`. [JDK-8250968](https://bugs.openjdk.org/browse/JDK-8250968) later renamed the field to `ZipEntry.extraAttributes` and extended its semantics to hold the full two-byte value of the `external file attributes` field, as defined by `APPNOTE.TXT`
>> 
>> The name `extraAttributes` is misleading. It has nothing to do with the `extra field` (an unrelated structure defined in `APPNOTE.TXT`), although the name indicates it does.
>> 
>> To prevent confusion and make life easier for future maintainers, I suggest we rename this field to `ZipEntry.externalFileAttributes` and update related methods, parameters and comments accordingly.
>> 
>> While this change is a straightforward renaming, reviewers should consider whether it carries its weight, especially considering it might complicate future backports. 
>> 
>> As a note to reviewers, this PR includes the following intended updates:
>> 
>> - Rename `ZipEntry.extraAttributes` and any references to this field to `ZipEntry.externalFileAttributes`
>> - Update `JavaUtilZipFileAccess` to similarly rename methods to `setExternalFileAttributes` and `getExternalFileAttributes` 
>> - Rename the field `JarSigner.extraAttrsDetected` to `JarSigner.externalFileAttrsDetected`
>> - Rename a local variable in `JarSigner.writeEntry` to `externalFileAttributes`
>> - Rename `s.s.t.jarsigner.Main.extraAttrsDetected` to `externalFileAttributesDetected`
>> - Rename resource string key names in `s.s.t.jarsigner.Resources` from `extra.attributes.detected` to `external.file.attributes.detected`
>> - Rename method `SymlinkTest.verifyExtraAttrs` to `verifyExternalFileAttributes`, also updated two references to 'extra attributes' in this method
>> - Updated copyright in all affected files
>> 
>> If the resource file changes should be dropped and instead handled via `msgdop` updates, let me know and I can revert the non-default files.
>> 
>> I did a search across the code base to find 'extraAttrs', 'extra.attr' after these updates, and found nothing related to zip/jar. The `zip` and `jar` tests run clean:
>> 
>> 
>> make test TEST="test/jdk/java/util/jar"
>> make test TEST="test/jdk/java/util/zip"
>
> Eirik Bj?rsn?s has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rename SymlinkTest.verifyExternalAttrs to verifyExternalFileAttributes

This PR was approved by Lance in March, but it seems I forgot to integrate.

I plan to integrate this in the next few days unless I hear objections.

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

PR Comment: https://git.openjdk.org/jdk/pull/16952#issuecomment-2102495979

From egahlin at openjdk.org  Thu May  9 12:01:53 2024
From: egahlin at openjdk.org (Erik Gahlin)
Date: Thu, 9 May 2024 12:01:53 GMT
Subject: RFR: 8331876: JFR: Move file read and write events to java.base
 [v3]
In-Reply-To: <67gSQFkt4YT6jJcAqpFemfrxCMls8YvlkwuPiplqco8=.fbf7550c-3297-4678-a8cd-648c71df79e0@github.com>
References: <DDe0bKCC86AawVl7RylZ74uvvLBr2Zljpkcmxx1_WEU=.61cc10c6-b635-42dd-a850-b32ae1d68585@github.com>
 <3jqGe0bFYpJEV4R8uk-IuJrpXtujcRlti7mZ2mC-K-Y=.028d74ad-858b-4744-8390-59a3b85a4eb8@github.com>
 <67gSQFkt4YT6jJcAqpFemfrxCMls8YvlkwuPiplqco8=.fbf7550c-3297-4678-a8cd-648c71df79e0@github.com>
Message-ID: <-wDZYFicDYgg8_Hmz92KtcYM1MHZNsVvA8p5wHc7Osc=.2904f7f8-6cda-49f7-adac-ab853a674a39@github.com>

On Thu, 9 May 2024 07:33:22 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

>> src/java.base/share/classes/sun/nio/ch/FileChannelImpl.java line 78:
>> 
>>> 76: 
>>> 77:     // Flag that determines if file reads/writes should be traced by JFR
>>> 78:     private static boolean jfrTracing;
>> 
>> Should the force method be changed to test this flag too?
>> 
>> I'm also wondering about the transferXXX methods. We might want to think about these for a separate PR as they have more potential to be outliers than the read/write methods.
>
> I think it would be good to use the flag for all events, but I rather do it as separate PR so this is mostly a mechanical change to remove ASM. It makes it easier to track regressions or improvements.
> 
> I can file an enhancement for the transferXXX methods.

"JFR: Add file event support for transfer methods"
https://bugs.openjdk.org/browse/JDK-8331995

"JFR: Add boolean check before loading event classes"
https://bugs.openjdk.org/browse/JDK-8331996

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19129#discussion_r1595353143

From liach at openjdk.org  Thu May  9 12:03:59 2024
From: liach at openjdk.org (Chen Liang)
Date: Thu, 9 May 2024 12:03:59 GMT
Subject: RFR: 8310837: Use ByteArrayLittleEndian in java.util.zip [v8]
In-Reply-To: <BDBRcZqwyUS6J94Cbv0QGri0FInHnTl7tv2vNMbUHxE=.5dec6a8f-859a-40cc-b643-021dc0fd7b42@github.com>
References: <MAhOKHlG0LsSo86kCDoaRwJvCF0bHDEElqRNrrY4lbE=.da7de5af-4660-4c3d-96fc-59abbb8398d8@github.com>
 <BDBRcZqwyUS6J94Cbv0QGri0FInHnTl7tv2vNMbUHxE=.5dec6a8f-859a-40cc-b643-021dc0fd7b42@github.com>
Message-ID: <M908umetfNAbgMNXmeuU962fCiHFIwpWauN3MgFECek=.14ef775c-595f-4106-854c-f432a94957cd@github.com>

On Wed, 28 Feb 2024 14:21:16 GMT, Glavo <duke at openjdk.org> wrote:

>> Using `ByteArrayLittleEndian` is simpler and faster.
>> 
>> `make test TEST="micro:java.util.zip.ZipFileOpen"`:
>> 
>> 
>>   Benchmark                     (size)  Mode  Cnt      Score      Error  Units
>> - ZipFileOpen.openCloseZipFile     512  avgt   15  39052.832 ?  107.496  ns/op
>> + ZipFileOpen.openCloseZipFile     512  avgt   15  36275.539 ?  663.193  ns/op
>> - ZipFileOpen.openCloseZipFile    1024  avgt   15  77106.494 ? 4159.300  ns/op
>> + ZipFileOpen.openCloseZipFile    1024  avgt   15  71955.013 ? 2296.050  ns/op
>
> Glavo has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains eight additional commits since the last revision:
> 
>  - Merge branch 'openjdk:master' into zip-utils
>  - Add tests
>  - Merge branch 'openjdk:master' into zip-utils
>  - Merge branch 'openjdk:master' into zip-utils
>  - Merge branch 'openjdk:master' into zip-utils
>  - Merge branch 'openjdk:master' into zip-utils
>  - Merge branch 'openjdk:master' into zip-utils
>  - use ByteArrayLittleEndian in ZipUtils

@cl4es Can you take a look at this performance improvement patch?

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

PR Comment: https://git.openjdk.org/jdk/pull/14632#issuecomment-2102527844

From jpai at openjdk.org  Thu May  9 12:03:56 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 9 May 2024 12:03:56 GMT
Subject: RFR: 8321274: Rename ZipEntry.extraAttributes to
 ZipEntry.externalFileAttributes [v4]
In-Reply-To: <58cWTca1j5r5WfGtN8281Vog-yABS7RF2oJOlBsoBVs=.f18b5ca1-e345-4c3b-a568-cff6c003e902@github.com>
References: <EcxkA01kaWJwev-16dqYXi7rODrgCBzWJRHL5A4rjA0=.7e65e59b-3086-463a-9558-04abfe1b0782@github.com>
 <58cWTca1j5r5WfGtN8281Vog-yABS7RF2oJOlBsoBVs=.f18b5ca1-e345-4c3b-a568-cff6c003e902@github.com>
Message-ID: <iF6bpMXAAU3joVhZJwGU3bTPx6dBEZnYAtHgY-sJCPE=.6ffacb24-ab34-48d2-8120-68dd93a60dba@github.com>

On Fri, 8 Mar 2024 09:34:05 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

>> Please consider this PR which suggests we rename `ZipEntry.extraAttributes` to `ZipEntry.externalFileAttributes`.
>> 
>> This field was introduced in [JDK-8218021](https://bugs.openjdk.org/browse/JDK-8218021), originally under the name `ZipEntry.posixPerms`. [JDK-8250968](https://bugs.openjdk.org/browse/JDK-8250968) later renamed the field to `ZipEntry.extraAttributes` and extended its semantics to hold the full two-byte value of the `external file attributes` field, as defined by `APPNOTE.TXT`
>> 
>> The name `extraAttributes` is misleading. It has nothing to do with the `extra field` (an unrelated structure defined in `APPNOTE.TXT`), although the name indicates it does.
>> 
>> To prevent confusion and make life easier for future maintainers, I suggest we rename this field to `ZipEntry.externalFileAttributes` and update related methods, parameters and comments accordingly.
>> 
>> While this change is a straightforward renaming, reviewers should consider whether it carries its weight, especially considering it might complicate future backports. 
>> 
>> As a note to reviewers, this PR includes the following intended updates:
>> 
>> - Rename `ZipEntry.extraAttributes` and any references to this field to `ZipEntry.externalFileAttributes`
>> - Update `JavaUtilZipFileAccess` to similarly rename methods to `setExternalFileAttributes` and `getExternalFileAttributes` 
>> - Rename the field `JarSigner.extraAttrsDetected` to `JarSigner.externalFileAttrsDetected`
>> - Rename a local variable in `JarSigner.writeEntry` to `externalFileAttributes`
>> - Rename `s.s.t.jarsigner.Main.extraAttrsDetected` to `externalFileAttributesDetected`
>> - Rename resource string key names in `s.s.t.jarsigner.Resources` from `extra.attributes.detected` to `external.file.attributes.detected`
>> - Rename method `SymlinkTest.verifyExtraAttrs` to `verifyExternalFileAttributes`, also updated two references to 'extra attributes' in this method
>> - Updated copyright in all affected files
>> 
>> If the resource file changes should be dropped and instead handled via `msgdop` updates, let me know and I can revert the non-default files.
>> 
>> I did a search across the code base to find 'extraAttrs', 'extra.attr' after these updates, and found nothing related to zip/jar. The `zip` and `jar` tests run clean:
>> 
>> 
>> make test TEST="test/jdk/java/util/jar"
>> make test TEST="test/jdk/java/util/zip"
>
> Eirik Bj?rsn?s has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rename SymlinkTest.verifyExternalAttrs to verifyExternalFileAttributes

Hello Eirik, it will be better to merge with the latest master branch and run the tier tests before integrating.

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

PR Comment: https://git.openjdk.org/jdk/pull/16952#issuecomment-2102527651

From liach at openjdk.org  Thu May  9 12:09:54 2024
From: liach at openjdk.org (Chen Liang)
Date: Thu, 9 May 2024 12:09:54 GMT
Subject: RFR: 8331744: java.lang.classfile.TypeKind improvements [v4]
In-Reply-To: <2ehu58tQasyDZc-dqUtnjUdazTfEXl9F_-4jimHTmHY=.37ab1963-092e-41d6-a751-7a33c05e66db@github.com>
References: <_x31CU5mODg3NGaRGzI5HdNdcjsKmqWb1TA7KZnZcFg=.43ce5ba3-71e7-42e5-a531-c3b609d0aafb@github.com>
 <-6l188kBfGFxic3KxI-qxyVpPWEbwt4Z5O1nJbfCHQQ=.e460344f-b23f-4dcd-95a3-a12f478687d7@github.com>
 <2ehu58tQasyDZc-dqUtnjUdazTfEXl9F_-4jimHTmHY=.37ab1963-092e-41d6-a751-7a33c05e66db@github.com>
Message-ID: <0Qn9e3pKNILgtBPABu9VtbjyRrsyeGcp_Fob0B2NroA=.1975072e-85bb-41b0-8d9b-df4170a7ea9c@github.com>

On Thu, 9 May 2024 07:23:16 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Hash table, use fixed random seed
>
> src/java.base/share/classes/java/lang/classfile/TypeKind.java line 139:
> 
>> 137:             case 'V' -> TypeKind.VoidType;
>> 138:             default -> throw new IllegalArgumentException("Bad type: " + s);
>> 139:         };
> 
> This maps to a `tableswitch`, could you explain why a statically initialized array addressed with a custom hash code suppose to be faster?
> Thanks.

I actually am not sure of the reason; it is indeed a tableswitch in bytecode. @cl4es might know it better?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19109#discussion_r1595360109

From asotona at openjdk.org  Thu May  9 12:31:54 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Thu, 9 May 2024 12:31:54 GMT
Subject: RFR: 8331744: java.lang.classfile.TypeKind improvements [v4]
In-Reply-To: <0Qn9e3pKNILgtBPABu9VtbjyRrsyeGcp_Fob0B2NroA=.1975072e-85bb-41b0-8d9b-df4170a7ea9c@github.com>
References: <_x31CU5mODg3NGaRGzI5HdNdcjsKmqWb1TA7KZnZcFg=.43ce5ba3-71e7-42e5-a531-c3b609d0aafb@github.com>
 <-6l188kBfGFxic3KxI-qxyVpPWEbwt4Z5O1nJbfCHQQ=.e460344f-b23f-4dcd-95a3-a12f478687d7@github.com>
 <2ehu58tQasyDZc-dqUtnjUdazTfEXl9F_-4jimHTmHY=.37ab1963-092e-41d6-a751-7a33c05e66db@github.com>
 <0Qn9e3pKNILgtBPABu9VtbjyRrsyeGcp_Fob0B2NroA=.1975072e-85bb-41b0-8d9b-df4170a7ea9c@github.com>
Message-ID: <a4JaRWnOJr5XaoPoEqvt3mAk0uxnwdkJTlsKXuMNmNw=.cf9d0b66-db85-47e9-9145-d6cdc60bd752@github.com>

On Thu, 9 May 2024 12:07:22 GMT, Chen Liang <liach at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/classfile/TypeKind.java line 139:
>> 
>>> 137:             case 'V' -> TypeKind.VoidType;
>>> 138:             default -> throw new IllegalArgumentException("Bad type: " + s);
>>> 139:         };
>> 
>> This maps to a `tableswitch`, could you explain why a statically initialized array addressed with a custom hash code suppose to be faster?
>> Thanks.
>
> I actually am not sure of the reason; it is indeed a tableswitch in bytecode. @cl4es might know it better?

Generally I agree with the API changes and with the `descriptor.isPrimitive()` test before requesting a descriptor string.
However I'm missing the point of the other changes, which only replace this single `tableswitch` with something way more complicated, without clear performance gain.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19109#discussion_r1595381124

From duke at openjdk.org  Thu May  9 12:40:59 2024
From: duke at openjdk.org (Glavo)
Date: Thu, 9 May 2024 12:40:59 GMT
Subject: RFR: 8310837: Use ByteArrayLittleEndian in java.util.zip [v8]
In-Reply-To: <BDBRcZqwyUS6J94Cbv0QGri0FInHnTl7tv2vNMbUHxE=.5dec6a8f-859a-40cc-b643-021dc0fd7b42@github.com>
References: <MAhOKHlG0LsSo86kCDoaRwJvCF0bHDEElqRNrrY4lbE=.da7de5af-4660-4c3d-96fc-59abbb8398d8@github.com>
 <BDBRcZqwyUS6J94Cbv0QGri0FInHnTl7tv2vNMbUHxE=.5dec6a8f-859a-40cc-b643-021dc0fd7b42@github.com>
Message-ID: <cOcITwL0NzriN-ycMYTW4KL-TVriJmW2WucJGpOND-U=.fc5aa8f2-fcbb-4f8e-9992-f1a735e514cf@github.com>

On Wed, 28 Feb 2024 14:21:16 GMT, Glavo <duke at openjdk.org> wrote:

>> Using `ByteArrayLittleEndian` is simpler and faster.
>> 
>> `make test TEST="micro:java.util.zip.ZipFileOpen"`:
>> 
>> 
>>   Benchmark                     (size)  Mode  Cnt      Score      Error  Units
>> - ZipFileOpen.openCloseZipFile     512  avgt   15  39052.832 ?  107.496  ns/op
>> + ZipFileOpen.openCloseZipFile     512  avgt   15  36275.539 ?  663.193  ns/op
>> - ZipFileOpen.openCloseZipFile    1024  avgt   15  77106.494 ? 4159.300  ns/op
>> + ZipFileOpen.openCloseZipFile    1024  avgt   15  71955.013 ? 2296.050  ns/op
>
> Glavo has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains eight additional commits since the last revision:
> 
>  - Merge branch 'openjdk:master' into zip-utils
>  - Add tests
>  - Merge branch 'openjdk:master' into zip-utils
>  - Merge branch 'openjdk:master' into zip-utils
>  - Merge branch 'openjdk:master' into zip-utils
>  - Merge branch 'openjdk:master' into zip-utils
>  - Merge branch 'openjdk:master' into zip-utils
>  - use ByteArrayLittleEndian in ZipUtils

I've been busy working on other projects lately, so I've put these PRs on hold. If anyone cares to take a look at them I'll be right back.

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

PR Comment: https://git.openjdk.org/jdk/pull/14632#issuecomment-2102583431

From redestad at openjdk.org  Thu May  9 13:34:16 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Thu, 9 May 2024 13:34:16 GMT
Subject: RFR: 8331932: Startup regressions in 23-b13 [v5]
In-Reply-To: <LgTAOs1QA0kgTbAfVQ_U2BcWAV7AHpcFXNE7eYB1BI8=.e77b81c1-73d4-4ff0-806f-eeda86d5cb16@github.com>
References: <LgTAOs1QA0kgTbAfVQ_U2BcWAV7AHpcFXNE7eYB1BI8=.e77b81c1-73d4-4ff0-806f-eeda86d5cb16@github.com>
Message-ID: <80F_O6CmUuhmcSwCdIGMQbw9zo_GSmyn9B99mWgflrk=.313222e4-b800-428e-88ea-a821684c3e9e@github.com>

> A rather large startup regression was introduced in 23-b13 from [JDK-8309622](https://bugs.openjdk.org/browse/JDK-8309622). Some of that has been dealt with as enhancements such as [JDK-8330802](https://bugs.openjdk.org/browse/JDK-8330802), [JDK-8330595](https://bugs.openjdk.org/browse/JDK-8330595) and [JDK-8330681](https://bugs.openjdk.org/browse/JDK-8330681), which provide both point fixes and reduce initialization overhead of certain constructs more generally. The remaining issues stem from a set of lambdas added in code for `java.util.Locale` and `jdk.internal.util.BaseLocale` causing early bootstrapping of the lambda infrastructure and a bit of class generation.
> 
> While the remaining overheads are relatively small and borderline acceptable (< 2-3ms), I think it's still worth acting on them in this particular case since the amount of added bootstrapping overhead is dependent on which locale the system runs under, which complicates testing and comparisons due to relatively large differences in paths taken on different systems.

Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:

  Reuse ReferenceKeyMap.concurrentHashMapSupplier

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/19140/files
  - new: https://git.openjdk.org/jdk/pull/19140/files/819e3d47..37968988

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

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

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

From liach at openjdk.org  Thu May  9 14:04:53 2024
From: liach at openjdk.org (Chen Liang)
Date: Thu, 9 May 2024 14:04:53 GMT
Subject: RFR: 8331932: Startup regressions in 23-b13 [v5]
In-Reply-To: <80F_O6CmUuhmcSwCdIGMQbw9zo_GSmyn9B99mWgflrk=.313222e4-b800-428e-88ea-a821684c3e9e@github.com>
References: <LgTAOs1QA0kgTbAfVQ_U2BcWAV7AHpcFXNE7eYB1BI8=.e77b81c1-73d4-4ff0-806f-eeda86d5cb16@github.com>
 <80F_O6CmUuhmcSwCdIGMQbw9zo_GSmyn9B99mWgflrk=.313222e4-b800-428e-88ea-a821684c3e9e@github.com>
Message-ID: <l4XRXxCL9Ir9U3fVkyPqzBUeC896le6FViLz6_GvXEI=.6c5cfa2e-f8e4-4cde-b40f-7fa9d52633c1@github.com>

On Thu, 9 May 2024 13:34:16 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> A rather large startup regression was introduced in 23-b13 from [JDK-8309622](https://bugs.openjdk.org/browse/JDK-8309622). Some of that has been dealt with as enhancements such as [JDK-8330802](https://bugs.openjdk.org/browse/JDK-8330802), [JDK-8330595](https://bugs.openjdk.org/browse/JDK-8330595) and [JDK-8330681](https://bugs.openjdk.org/browse/JDK-8330681), which provide both point fixes and reduce initialization overhead of certain constructs more generally. The remaining issues stem from a set of lambdas added in code for `java.util.Locale` and `jdk.internal.util.BaseLocale` causing early bootstrapping of the lambda infrastructure and a bit of class generation.
>> 
>> While the remaining overheads are relatively small and borderline acceptable (< 2-3ms), I think it's still worth acting on them in this particular case since the amount of added bootstrapping overhead is dependent on which locale the system runs under, which complicates testing and comparisons due to relatively large differences in paths taken on different systems.
>
> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reuse ReferenceKeyMap.concurrentHashMapSupplier

Marked as reviewed by liach (Author).

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

PR Review: https://git.openjdk.org/jdk/pull/19140#pullrequestreview-2048037650

From prappo at openjdk.org  Thu May  9 14:23:37 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Thu, 9 May 2024 14:23:37 GMT
Subject: RFR: 8305457: Implement java.io.IO [v5]
In-Reply-To: <w2msiw_qaMEIJS3s9D4bg8pFbz5WIF0KdP6Mm-XFjLI=.85b2020b-8c46-4bac-8a69-4975b068f2ff@github.com>
References: <w2msiw_qaMEIJS3s9D4bg8pFbz5WIF0KdP6Mm-XFjLI=.85b2020b-8c46-4bac-8a69-4975b068f2ff@github.com>
Message-ID: <Qw2fiJiRTaqkuevgw1OTRd75A8IByv5gQG-aMX7bp4c=.a9a521c6-0e33-4df8-bd59-dc33533cd29d@github.com>

> Please review this PR which introduces the `java.io.IO` top-level class and three methods to `java.io.Console` for [Implicitly Declared Classes and Instance Main Methods (Third Preview)].
> 
> This PR has been obtained as `git merge --squash` of a now obsolete [draft PR].
> 
> [Implicitly Declared Classes and Instance Main Methods (Third Preview)]: https://bugs.openjdk.org/browse/JDK-8323335
> [draft PR]: https://github.com/openjdk/jdk/pull/18921

Pavel Rappo has updated the pull request incrementally with five additional commits since the last revision:

 - Simplify output.exp
 - Cover null prompt in input tests
 - Make input test parametric
 - Specify behaviour in regard to null
 - Add explicit @throws IOError to IO methods

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/19112/files
  - new: https://git.openjdk.org/jdk/pull/19112/files/80eacf8c..401d8d25

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

  Stats: 70 lines in 8 files changed: 31 ins; 14 del; 25 mod
  Patch: https://git.openjdk.org/jdk/pull/19112.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19112/head:pull/19112

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

From jjg at openjdk.org  Thu May  9 14:43:55 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Thu, 9 May 2024 14:43:55 GMT
Subject: RFR: 8305457: Implement java.io.IO [v5]
In-Reply-To: <Qw2fiJiRTaqkuevgw1OTRd75A8IByv5gQG-aMX7bp4c=.a9a521c6-0e33-4df8-bd59-dc33533cd29d@github.com>
References: <w2msiw_qaMEIJS3s9D4bg8pFbz5WIF0KdP6Mm-XFjLI=.85b2020b-8c46-4bac-8a69-4975b068f2ff@github.com>
 <Qw2fiJiRTaqkuevgw1OTRd75A8IByv5gQG-aMX7bp4c=.a9a521c6-0e33-4df8-bd59-dc33533cd29d@github.com>
Message-ID: <Q0hJrILTcEkAmGsQuCHs3J5bBpOT0pcdcCGhG98Ah7I=.0431505f-d89d-4a35-8662-9bf3c083492e@github.com>

On Thu, 9 May 2024 14:23:37 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Please review this PR which introduces the `java.io.IO` top-level class and three methods to `java.io.Console` for [Implicitly Declared Classes and Instance Main Methods (Third Preview)].
>> 
>> This PR has been obtained as `git merge --squash` of a now obsolete [draft PR].
>> 
>> [Implicitly Declared Classes and Instance Main Methods (Third Preview)]: https://bugs.openjdk.org/browse/JDK-8323335
>> [draft PR]: https://github.com/openjdk/jdk/pull/18921
>
> Pavel Rappo has updated the pull request incrementally with five additional commits since the last revision:
> 
>  - Simplify output.exp
>  - Cover null prompt in input tests
>  - Make input test parametric
>  - Specify behaviour in regard to null
>  - Add explicit @throws IOError to IO methods

(Minor). at least within the context of this PR, tags like `@param` and `@throws` are stylistically inconsistent as to whether they begin with a capital letter and end with a period.  (I have not checked for local consistency within the affected files.)

test/jdk/java/io/IO/IO.java line 125:

> 123:      * To simulate a terminal, the test currently uses the EXPECT(1) Unix
> 124:      * command, which does not work for Windows. Later, a library like pty4j
> 125:      * or JPty might be used instead EXPECT, to cover both Unix and Windows.

Possible missing word `of`: `instead of EXPECT`

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

PR Review: https://git.openjdk.org/jdk/pull/19112#pullrequestreview-2048123137
PR Review Comment: https://git.openjdk.org/jdk/pull/19112#discussion_r1595543569

From dfuchs at openjdk.org  Thu May  9 14:43:56 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 9 May 2024 14:43:56 GMT
Subject: RFR: 8331876: JFR: Move file read and write events to java.base
 [v3]
In-Reply-To: <SejX7NAvWNjrhDEN8uDf4oikQDBRclWXDg1fN5FCpkc=.7de48c6f-0af2-4bf4-a743-6e173d950d52@github.com>
References: <DDe0bKCC86AawVl7RylZ74uvvLBr2Zljpkcmxx1_WEU=.61cc10c6-b635-42dd-a850-b32ae1d68585@github.com>
 <SejX7NAvWNjrhDEN8uDf4oikQDBRclWXDg1fN5FCpkc=.7de48c6f-0af2-4bf4-a743-6e173d950d52@github.com>
Message-ID: <DgjIOZTfztdSEeODuNZw5MmzsiohA82hhllWCceyPyU=.7bda36a1-e26d-4d7e-822a-e443d3cbc0df@github.com>

On Thu, 9 May 2024 11:19:14 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

>> Hi,
>> 
>> Could I have a review of a change that moves the jdk.FileRead and jdk.FileWrite events to java.base to remove the use of the ASM instrumentation.
>> 
>> Testing: jdk/jdk/jfr
>> 
>> Thanks
>> Erik
>
> Erik Gahlin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Move methods

src/java.base/share/classes/java/io/FileInputStream.java line 63:

> 61:     private static final int DEFAULT_BUFFER_SIZE = 8192;
> 62: 
> 63:     // Flag that determines if file reads should be traced by JFR

It could be good to also note what will modify this flag - here and in other classes.
I'm going to guess that the purpose of this flag is purely performance, to avoid even loading the event class, `FileReadEvent` here, during startup/bootstrap and when JFR is not enabled, as read and write methods are highly performance sensitive? Otherwise the flag could live in the event class itself? Is it substantially faster to check this flag compared to `FileReadEvent.enabled()`?

src/java.base/share/classes/jdk/internal/event/JFRTracing.java line 51:

> 49:       field.setAccessible(true);
> 50:       field.setBoolean(null, true);
> 51:   }

Using reflection with `Field` seems expedient - a more modern way could be to use `VarHandle` but I guess it would require more setup to obtain a `Lookup` with the proper capabilities?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19129#discussion_r1595525764
PR Review Comment: https://git.openjdk.org/jdk/pull/19129#discussion_r1595530833

From duke at openjdk.org  Thu May  9 14:51:05 2024
From: duke at openjdk.org (duke)
Date: Thu, 9 May 2024 14:51:05 GMT
Subject: Withdrawn: 8327786: Add fluent setAccessible()
In-Reply-To: <41qiesZ_n01HxaYiSENup-ZHPHmzakTbOe_SQkpe2U0=.6a2214d6-1d5f-4e76-b7fc-be9eca5be821@github.com>
References: <41qiesZ_n01HxaYiSENup-ZHPHmzakTbOe_SQkpe2U0=.6a2214d6-1d5f-4e76-b7fc-be9eca5be821@github.com>
Message-ID: <94wdQa89ARnSQIH9uzwU8RlzgJBZmLGFD5Wcv8fo0ms=.3c0f5428-19cf-436d-82cf-14e65b8a03ce@github.com>

On Thu, 25 Jan 2024 21:35:45 GMT, Sergey <duke at openjdk.org> wrote:

> The feature allows to extract a private field value in a single expression, like so:
> 
> object.getClass().getDeclaredField().setAccessible().get(object)

This pull request has been closed without being integrated.

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

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

From egahlin at openjdk.org  Thu May  9 15:01:56 2024
From: egahlin at openjdk.org (Erik Gahlin)
Date: Thu, 9 May 2024 15:01:56 GMT
Subject: RFR: 8331876: JFR: Move file read and write events to java.base
 [v3]
In-Reply-To: <DgjIOZTfztdSEeODuNZw5MmzsiohA82hhllWCceyPyU=.7bda36a1-e26d-4d7e-822a-e443d3cbc0df@github.com>
References: <DDe0bKCC86AawVl7RylZ74uvvLBr2Zljpkcmxx1_WEU=.61cc10c6-b635-42dd-a850-b32ae1d68585@github.com>
 <SejX7NAvWNjrhDEN8uDf4oikQDBRclWXDg1fN5FCpkc=.7de48c6f-0af2-4bf4-a743-6e173d950d52@github.com>
 <DgjIOZTfztdSEeODuNZw5MmzsiohA82hhllWCceyPyU=.7bda36a1-e26d-4d7e-822a-e443d3cbc0df@github.com>
Message-ID: <khrP38H7DBIyftQZtZt0CRXeH1ZkpOCjiRNvFTs3LSI=.fd62aba9-5153-4521-84e4-241b8a352720@github.com>

On Thu, 9 May 2024 14:25:27 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Erik Gahlin has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Move methods
>
> src/java.base/share/classes/java/io/FileInputStream.java line 63:
> 
>> 61:     private static final int DEFAULT_BUFFER_SIZE = 8192;
>> 62: 
>> 63:     // Flag that determines if file reads should be traced by JFR
> 
> It could be good to also note what will modify this flag - here and in other classes.
> I'm going to guess that the purpose of this flag is purely performance, to avoid even loading the event class, `FileReadEvent` here, during startup/bootstrap and when JFR is not enabled, as read and write methods are highly performance sensitive? Otherwise the flag could live in the event class itself? Is it substantially faster to check this flag compared to `FileReadEvent.enabled()`?

Its purpose is to avoid loading the FileReadEvent class. When the class is loaded, JFR will add fields and in some circumstances do other things. I don't think the cost is high, but it may add up if the number of events increases. Most Java applications don't run with JFR enabled, so this is to prevent them from seeing a negative impact.

I can update the text.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19129#discussion_r1595570427

From mcimadamore at openjdk.org  Thu May  9 15:05:00 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 9 May 2024 15:05:00 GMT
Subject: RFR: 8332003: Clarify javadoc for MemoryLayout::offsetHandle
Message-ID: <0uMhIaW3d_IBqbF_04WhHDKHiIXes04wawSuxc6dQxI=.7f5621f9-0d77-4433-bc00-1ff8624b65da@github.com>

Consider this layout:


MemoryLayout SEQ = MemoryLayout.sequenceLayout(5,
             MemoryLayout.sequenceLayout(10, JAVA_INT));


And the corresponding offset handle:


MethodHandle offsetHandle = SEQ.offsetHandle(PathElement.sequenceLayout(), PathElement.sequenceLayout());


The resulting method handle takes two additional `long` indices. The implementation checks that the dynamically provided indices conform to the bound available at construction: that is, the first index must be < 5, while the second must be < 10. If this is not true, an `IndexOutOfBoundException` is thrown.

However, the javadoc for `MemoryLayout::byteOffsetHandle` doesn't claim anything in this direction. There are only some vague claims in the javadoc for `PathElement::sequenceElement()` and `PathElement::sequenceElement(long, long, long)` which make some claims on which indices are actually allowed, but the text seems more in the tone of a discussion, rather than actual normative text.

I've tweaked the javadoc for `MemoryLayout::byteOffsetHandle` to actually state that the indices will be checked against the "size" of the corresponding open path element (this is a new concept that I also have defined in the javadoc).

I also added a test for `byteOffsetHandle` as I don't think we had a test for that specifically (although this method is tested indirectly, via `MemoryLayout::varHandle`).

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

Commit messages:
 - Initial push

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

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

From pminborg at openjdk.org  Thu May  9 15:42:54 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 9 May 2024 15:42:54 GMT
Subject: RFR: 8332003: Clarify javadoc for MemoryLayout::offsetHandle
In-Reply-To: <0uMhIaW3d_IBqbF_04WhHDKHiIXes04wawSuxc6dQxI=.7f5621f9-0d77-4433-bc00-1ff8624b65da@github.com>
References: <0uMhIaW3d_IBqbF_04WhHDKHiIXes04wawSuxc6dQxI=.7f5621f9-0d77-4433-bc00-1ff8624b65da@github.com>
Message-ID: <FjOPQgassnYNUCFaBWEzx8wB0hwO9OBlbsPIaWO3ymw=.b90034c6-2463-474c-a4e7-76c9d3567dc8@github.com>

On Thu, 9 May 2024 15:00:35 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> Consider this layout:
> 
> 
> MemoryLayout SEQ = MemoryLayout.sequenceLayout(5,
>              MemoryLayout.sequenceLayout(10, JAVA_INT));
> 
> 
> And the corresponding offset handle:
> 
> 
> MethodHandle offsetHandle = SEQ.offsetHandle(PathElement.sequenceLayout(), PathElement.sequenceLayout());
> 
> 
> The resulting method handle takes two additional `long` indices. The implementation checks that the dynamically provided indices conform to the bound available at construction: that is, the first index must be < 5, while the second must be < 10. If this is not true, an `IndexOutOfBoundException` is thrown.
> 
> However, the javadoc for `MemoryLayout::byteOffsetHandle` doesn't claim anything in this direction. There are only some vague claims in the javadoc for `PathElement::sequenceElement()` and `PathElement::sequenceElement(long, long, long)` which make some claims on which indices are actually allowed, but the text seems more in the tone of a discussion, rather than actual normative text.
> 
> I've tweaked the javadoc for `MemoryLayout::byteOffsetHandle` to actually state that the indices will be checked against the "size" of the corresponding open path element (this is a new concept that I also have defined in the javadoc).
> 
> I also added a test for `byteOffsetHandle` as I don't think we had a test for that specifically (although this method is tested indirectly, via `MemoryLayout::varHandle`).

src/java.base/share/classes/java/lang/foreign/MemoryLayout.java line 616:

> 614:      *
> 615:      * {@snippet lang = "java":
> 616:      * O = this.byteOffsetHandle(P).invokeExact(B, I1, I2, ... In);

Good catch

test/jdk/java/foreign/TestLayoutPaths.java line 36:

> 34: 
> 35: import java.lang.invoke.MethodHandle;
> 36: import java.lang.invoke.VarHandle;

Nit: Copyright year

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19158#discussion_r1595624831
PR Review Comment: https://git.openjdk.org/jdk/pull/19158#discussion_r1595624353

From egahlin at openjdk.org  Thu May  9 15:43:53 2024
From: egahlin at openjdk.org (Erik Gahlin)
Date: Thu, 9 May 2024 15:43:53 GMT
Subject: RFR: 8331876: JFR: Move file read and write events to java.base
 [v3]
In-Reply-To: <DgjIOZTfztdSEeODuNZw5MmzsiohA82hhllWCceyPyU=.7bda36a1-e26d-4d7e-822a-e443d3cbc0df@github.com>
References: <DDe0bKCC86AawVl7RylZ74uvvLBr2Zljpkcmxx1_WEU=.61cc10c6-b635-42dd-a850-b32ae1d68585@github.com>
 <SejX7NAvWNjrhDEN8uDf4oikQDBRclWXDg1fN5FCpkc=.7de48c6f-0af2-4bf4-a743-6e173d950d52@github.com>
 <DgjIOZTfztdSEeODuNZw5MmzsiohA82hhllWCceyPyU=.7bda36a1-e26d-4d7e-822a-e443d3cbc0df@github.com>
Message-ID: <GmFZAGqKhqSMlAuKsnunFahbx5zJgYvgDG2T5lS_rho=.b6f10942-0d40-4b46-a24d-16a841502c79@github.com>

On Thu, 9 May 2024 14:29:13 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Erik Gahlin has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Move methods
>
> src/java.base/share/classes/jdk/internal/event/JFRTracing.java line 51:
> 
>> 49:       field.setAccessible(true);
>> 50:       field.setBoolean(null, true);
>> 51:   }
> 
> Using reflection with `Field` seems expedient - a more modern way could be to use `VarHandle` but I guess it would require more setup to obtain a `Lookup` with the proper capabilities?

The field is only used once and a VarHandle implementation loads three additional classes during startup and in my measurements add about 0.6 ms to startup.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19129#discussion_r1595627039

From naoto at openjdk.org  Thu May  9 15:56:59 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 9 May 2024 15:56:59 GMT
Subject: Integrated: 8329691: Support `nonlikelyScript` parent locale
 inheritance
In-Reply-To: <VZl5HzmaaIHFzVj7FDB9gC9MLHZMlZOjObMwiKL7cMI=.fb806a5b-1414-4850-aa50-1da3c9835d16@github.com>
References: <VZl5HzmaaIHFzVj7FDB9gC9MLHZMlZOjObMwiKL7cMI=.fb806a5b-1414-4850-aa50-1da3c9835d16@github.com>
Message-ID: <gmlSlkTCfoDyjx0S_F8KNAyBtV_d9zPC3pdwmdwGrN4=.fa94f39f-5822-4dcf-84b0-2255403b9c16@github.com>

On Mon, 6 May 2024 17:53:56 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> This PR is to implement the `nonlikelyScript` feature that went into CLDR version 45 for migration purposes. In its release note, it states (https://cldr.unicode.org/index/downloads/cldr-45):
> 
> Migration
> Changes to parentLocales require upgrading implementations that use that element. In particular, they need to support the new nonlikelyScript value, and use the appropriate explicit inheritance for each type of inheritance. The v44 list of locales that inherit directly from root is retained for this release, but will disappear in the future. So implementations should move as quickly as possible to support the new value
> 
> For example in `Russian` locales fallback, its likely script is `Cyrl` (Cyrillic). Thus Russian locales with non-likely script, such as 'ru-Latn' (Russian in Latin script) should fallback directly to `root`, bypassing `ru` (Russian). CLDR has explicit parent locales for this nonlikely scripts, such as `zh-Hant` -> `root` already, but the release note suggests this will go away, and JDK needs to logically handle these non-likely script inheritance cases.
> 
> To implement this behavior, CLDRConverter build tool now generates the `LocaleDataMetaInfo` for java.base module with the new `likelyScriptMap`, which maps the script to its likely languages. Since the map is big, it is lazily initialized when needed. The map is used at runtime to determine the parent locale fallback based on implicit/explicit nonlikely Script inheritance.

This pull request has now been integrated.

Changeset: c7d98df2
Author:    Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/c7d98df2ac509ebc8f4e801a0874a9497c54c602
Stats:     287 lines in 5 files changed: 211 ins; 31 del; 45 mod

8329691: Support `nonlikelyScript` parent locale inheritance

Reviewed-by: joehw

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

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

From prappo at openjdk.org  Thu May  9 16:00:10 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Thu, 9 May 2024 16:00:10 GMT
Subject: RFR: 8305457: Implement java.io.IO [v5]
In-Reply-To: <Q0hJrILTcEkAmGsQuCHs3J5bBpOT0pcdcCGhG98Ah7I=.0431505f-d89d-4a35-8662-9bf3c083492e@github.com>
References: <w2msiw_qaMEIJS3s9D4bg8pFbz5WIF0KdP6Mm-XFjLI=.85b2020b-8c46-4bac-8a69-4975b068f2ff@github.com>
 <Qw2fiJiRTaqkuevgw1OTRd75A8IByv5gQG-aMX7bp4c=.a9a521c6-0e33-4df8-bd59-dc33533cd29d@github.com>
 <Q0hJrILTcEkAmGsQuCHs3J5bBpOT0pcdcCGhG98Ah7I=.0431505f-d89d-4a35-8662-9bf3c083492e@github.com>
Message-ID: <pW2RrXA1nsGMUY08ovcCQtaU7NSrs2N-1edD9qvMO5s=.2e8a6029-5d78-4ce7-93dc-630cc948c0bd@github.com>

On Thu, 9 May 2024 14:41:13 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> (Minor). at least within the context of this PR, tags like `@param` and `@throws` are stylistically inconsistent as to whether they begin with a capital letter and end with a period. (I have not checked for local consistency within the affected files.)

I know, thanks. That was on purpose to mimic the prevailing style of `Console`, just like you assumed in parentheses. Note, like-named methods in `IO` are styled differently.

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

PR Comment: https://git.openjdk.org/jdk/pull/19112#issuecomment-2102944256

From prappo at openjdk.org  Thu May  9 16:00:10 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Thu, 9 May 2024 16:00:10 GMT
Subject: RFR: 8305457: Implement java.io.IO [v6]
In-Reply-To: <w2msiw_qaMEIJS3s9D4bg8pFbz5WIF0KdP6Mm-XFjLI=.85b2020b-8c46-4bac-8a69-4975b068f2ff@github.com>
References: <w2msiw_qaMEIJS3s9D4bg8pFbz5WIF0KdP6Mm-XFjLI=.85b2020b-8c46-4bac-8a69-4975b068f2ff@github.com>
Message-ID: <MJ2tnXZIPclfljXMK8t9ql_-zzLyAXk0Z0Gj0RbrYqY=.f2493ee4-b85d-47b0-9e16-d3ab4fd6226f@github.com>

> Please review this PR which introduces the `java.io.IO` top-level class and three methods to `java.io.Console` for [Implicitly Declared Classes and Instance Main Methods (Third Preview)].
> 
> This PR has been obtained as `git merge --squash` of a now obsolete [draft PR].
> 
> [Implicitly Declared Classes and Instance Main Methods (Third Preview)]: https://bugs.openjdk.org/browse/JDK-8323335
> [draft PR]: https://github.com/openjdk/jdk/pull/18921

Pavel Rappo 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 12 additional commits since the last revision:

 - Fix typo
 - Merge branch 'master' into 8305457-Implement-java.io.IO
 - Simplify output.exp
 - Cover null prompt in input tests
 - Make input test parametric
 - Specify behaviour in regard to null
 - Add explicit @throws IOError to IO methods
 - Specify charset of java.io.IO
 - Use system-dependent line separator for Console.println
 - Strengthen tests after 8330998
   
   https://github.com/openjdk/jdk/pull/18996 now allows us to test
   Console IO better.
 - ... and 2 more: https://git.openjdk.org/jdk/compare/36cfe706...46a7af1f

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/19112/files
  - new: https://git.openjdk.org/jdk/pull/19112/files/401d8d25..46a7af1f

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

  Stats: 16584 lines in 272 files changed: 8281 ins; 5856 del; 2447 mod
  Patch: https://git.openjdk.org/jdk/pull/19112.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19112/head:pull/19112

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

From egahlin at openjdk.org  Thu May  9 16:12:54 2024
From: egahlin at openjdk.org (Erik Gahlin)
Date: Thu, 9 May 2024 16:12:54 GMT
Subject: RFR: 8331876: JFR: Move file read and write events to java.base
 [v3]
In-Reply-To: <GmFZAGqKhqSMlAuKsnunFahbx5zJgYvgDG2T5lS_rho=.b6f10942-0d40-4b46-a24d-16a841502c79@github.com>
References: <DDe0bKCC86AawVl7RylZ74uvvLBr2Zljpkcmxx1_WEU=.61cc10c6-b635-42dd-a850-b32ae1d68585@github.com>
 <SejX7NAvWNjrhDEN8uDf4oikQDBRclWXDg1fN5FCpkc=.7de48c6f-0af2-4bf4-a743-6e173d950d52@github.com>
 <DgjIOZTfztdSEeODuNZw5MmzsiohA82hhllWCceyPyU=.7bda36a1-e26d-4d7e-822a-e443d3cbc0df@github.com>
 <GmFZAGqKhqSMlAuKsnunFahbx5zJgYvgDG2T5lS_rho=.b6f10942-0d40-4b46-a24d-16a841502c79@github.com>
Message-ID: <Xpe1ryCbGrBs_N6mgTHYRhMEPLx729S6thLnL40181c=.0c323247-824e-4d2b-83e3-4012361e453d@github.com>

On Thu, 9 May 2024 15:41:42 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/event/JFRTracing.java line 51:
>> 
>>> 49:       field.setAccessible(true);
>>> 50:       field.setBoolean(null, true);
>>> 51:   }
>> 
>> Using reflection with `Field` seems expedient - a more modern way could be to use `VarHandle` but I guess it would require more setup to obtain a `Lookup` with the proper capabilities?
>
> The field is only used once and a VarHandle implementation loads three additional classes during startup and in my measurements add about 0.6 ms to startup.

A compromise between performance and readability is:

if (JFRTracing.isEnabled()) {
      ...
}

One additional class is loaded, but it's more clear where it comes from. I didn't want to do that for the ThrowableTracer class since it had a clinit.

This could potentially cause problems if JFRTracing is loaded early from Throwable or other class in the future. The static boolean flag is more safe, so probably better.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19129#discussion_r1595656857

From joehw at openjdk.org  Thu May  9 17:00:52 2024
From: joehw at openjdk.org (Joe Wang)
Date: Thu, 9 May 2024 17:00:52 GMT
Subject: RFR: 8331866: Add warnings for locale data dependence
In-Reply-To: <d1V8q3oaeh-cPvR_IE22WAHhoqrc1TXZMdEtIhxCLvM=.af6edbc8-49c1-4125-930d-42580dcb40c3@github.com>
References: <d1V8q3oaeh-cPvR_IE22WAHhoqrc1TXZMdEtIhxCLvM=.af6edbc8-49c1-4125-930d-42580dcb40c3@github.com>
Message-ID: <g8kdoSLG-eDywd2HipK3P0aEPVWxvhBD0SiBJYVv7x4=.1b40442c-da3f-4bbb-ad4a-8d4889383b68@github.com>

On Wed, 8 May 2024 20:21:50 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> In order to enlighten users to not depend on a particular version of the locale data, putting a note into the JDK vs. CLDR version chart would be appropriate.

src/java.base/share/classes/java/util/spi/LocaleServiceProvider.java line 157:

> 155:  * Note that the CLDR locale data are subject to change. Users should not assume
> 156:  * that the locale data remain the same across CLDR versions. Otherwise, unexpected
> 157:  * incompatible behaviors may occur, such as an exception on parsing a date.

For those wondering what has changed from one version to another or whether a particular change might have an impact after reading this note, I wonder if some kind of notes or links might be helpful. A column to the table below to add some notes? I'm sure they can always look at the CLDR release notes. Just wonder if there's anything specific worth noting or a link.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19145#discussion_r1595721855

From ecki at zusammenkunft.net  Thu May  9 17:40:13 2024
From: ecki at zusammenkunft.net (Bernd Eckenfels)
Date: Thu,  9 May 2024 19:40:13 +0200 (CEST)
Subject: Status of ZIP64 InputStream bug JDK-8298530?
Message-ID: <20240509174013.A459D6604A7@dd33810.kasserver.com>

An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240509/b1d45200/attachment.htm>

From naoto at openjdk.org  Thu May  9 17:58:21 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 9 May 2024 17:58:21 GMT
Subject: RFR: 8331866: Add warnings for locale data dependence [v2]
In-Reply-To: <d1V8q3oaeh-cPvR_IE22WAHhoqrc1TXZMdEtIhxCLvM=.af6edbc8-49c1-4125-930d-42580dcb40c3@github.com>
References: <d1V8q3oaeh-cPvR_IE22WAHhoqrc1TXZMdEtIhxCLvM=.af6edbc8-49c1-4125-930d-42580dcb40c3@github.com>
Message-ID: <NFhmWXSpQli0IegcWGzil-9u-jqMAg3xpjDsQJgRgw0=.2db0adb3-0315-489b-a93d-7f2b795a8144@github.com>

> In order to enlighten users to not depend on a particular version of the locale data, putting a note into the JDK vs. CLDR version chart would be appropriate.

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

 - Addresses review comment
 - Merge branch 'master' into JDK-8331866-localedata-dependence-warning
 - initial commit

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/19145/files
  - new: https://git.openjdk.org/jdk/pull/19145/files/f4a680c1..b33fe543

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

  Stats: 16883 lines in 280 files changed: 8496 ins; 5891 del; 2496 mod
  Patch: https://git.openjdk.org/jdk/pull/19145.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19145/head:pull/19145

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

From naoto at openjdk.org  Thu May  9 18:00:54 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 9 May 2024 18:00:54 GMT
Subject: RFR: 8331866: Add warnings for locale data dependence [v2]
In-Reply-To: <g8kdoSLG-eDywd2HipK3P0aEPVWxvhBD0SiBJYVv7x4=.1b40442c-da3f-4bbb-ad4a-8d4889383b68@github.com>
References: <d1V8q3oaeh-cPvR_IE22WAHhoqrc1TXZMdEtIhxCLvM=.af6edbc8-49c1-4125-930d-42580dcb40c3@github.com>
 <g8kdoSLG-eDywd2HipK3P0aEPVWxvhBD0SiBJYVv7x4=.1b40442c-da3f-4bbb-ad4a-8d4889383b68@github.com>
Message-ID: <Y02dF5XAfRUULVQAyP6igVuHamACZ_s3sItB_EJ0__w=.dc009930-1748-49d0-82c9-9aac42d1dc11@github.com>

On Thu, 9 May 2024 16:57:49 GMT, Joe Wang <joehw at openjdk.org> wrote:

>> Naoto Sato 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:
>> 
>>  - Addresses review comment
>>  - Merge branch 'master' into JDK-8331866-localedata-dependence-warning
>>  - initial commit
>
> src/java.base/share/classes/java/util/spi/LocaleServiceProvider.java line 157:
> 
>> 155:  * Note that the CLDR locale data are subject to change. Users should not assume
>> 156:  * that the locale data remain the same across CLDR versions. Otherwise, unexpected
>> 157:  * incompatible behaviors may occur, such as an exception on parsing a date.
> 
> For those wondering what has changed from one version to another or whether a particular change might have an impact after reading this note, I wonder if some kind of notes or links might be helpful. A column to the table below to add some notes? I'm sure they can always look at the CLDR release notes. Just wonder if there's anything specific worth noting or a link.

IMHO, adding an extra column to describe what has changed in CLDR would seem impractical as the significance of the changes depends on each reader. Instead, I added a sentence to navigate readers to CLDR's releases page for the deltas.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19145#discussion_r1595794498

From srl at openjdk.org  Thu May  9 18:05:53 2024
From: srl at openjdk.org (Steven Loomis)
Date: Thu, 9 May 2024 18:05:53 GMT
Subject: RFR: 8331866: Add warnings for locale data dependence [v2]
In-Reply-To: <NFhmWXSpQli0IegcWGzil-9u-jqMAg3xpjDsQJgRgw0=.2db0adb3-0315-489b-a93d-7f2b795a8144@github.com>
References: <d1V8q3oaeh-cPvR_IE22WAHhoqrc1TXZMdEtIhxCLvM=.af6edbc8-49c1-4125-930d-42580dcb40c3@github.com>
 <NFhmWXSpQli0IegcWGzil-9u-jqMAg3xpjDsQJgRgw0=.2db0adb3-0315-489b-a93d-7f2b795a8144@github.com>
Message-ID: <asLnMxunE4MxhlhGbwE1gZhA1iiHWB5QNu8mgwGN2Jg=.3d6da7f1-0634-44fe-a754-13e9710be66b@github.com>

On Thu, 9 May 2024 17:58:21 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> In order to enlighten users to not depend on a particular version of the locale data, putting a note into the JDK vs. CLDR version chart would be appropriate.
>
> Naoto Sato 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:
> 
>  - Addresses review comment
>  - Merge branch 'master' into JDK-8331866-localedata-dependence-warning
>  - initial commit

Marked as reviewed by srl (Committer).

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

PR Review: https://git.openjdk.org/jdk/pull/19145#pullrequestreview-2048529136

From srl at openjdk.org  Thu May  9 18:05:54 2024
From: srl at openjdk.org (Steven Loomis)
Date: Thu, 9 May 2024 18:05:54 GMT
Subject: RFR: 8331866: Add warnings for locale data dependence [v2]
In-Reply-To: <Y02dF5XAfRUULVQAyP6igVuHamACZ_s3sItB_EJ0__w=.dc009930-1748-49d0-82c9-9aac42d1dc11@github.com>
References: <d1V8q3oaeh-cPvR_IE22WAHhoqrc1TXZMdEtIhxCLvM=.af6edbc8-49c1-4125-930d-42580dcb40c3@github.com>
 <g8kdoSLG-eDywd2HipK3P0aEPVWxvhBD0SiBJYVv7x4=.1b40442c-da3f-4bbb-ad4a-8d4889383b68@github.com>
 <Y02dF5XAfRUULVQAyP6igVuHamACZ_s3sItB_EJ0__w=.dc009930-1748-49d0-82c9-9aac42d1dc11@github.com>
Message-ID: <E3PwDbhLhI-JEEskLFq2jCtg28AJmiERaejNb8_dqUw=.d3a173a7-7511-498d-8f8c-ab9fbc77fd6c@github.com>

On Thu, 9 May 2024 17:58:34 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> src/java.base/share/classes/java/util/spi/LocaleServiceProvider.java line 157:
>> 
>>> 155:  * Note that the CLDR locale data are subject to change. Users should not assume
>>> 156:  * that the locale data remain the same across CLDR versions. Otherwise, unexpected
>>> 157:  * incompatible behaviors may occur, such as an exception on parsing a date.
>> 
>> For those wondering what has changed from one version to another or whether a particular change might have an impact after reading this note, I wonder if some kind of notes or links might be helpful. A column to the table below to add some notes? I'm sure they can always look at the CLDR release notes. Just wonder if there's anything specific worth noting or a link.
>
> IMHO, adding an extra column to describe what has changed in CLDR would seem impractical as the significance of the changes depends on each reader. Instead, I added a sentence to navigate readers to CLDR's releases page for the deltas.

right.. there's never "no change".. and any change could potentially break users if they are expecting identical behavior.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19145#discussion_r1595799429

From archie.cobbs at gmail.com  Thu May  9 18:09:40 2024
From: archie.cobbs at gmail.com (Archie Cobbs)
Date: Thu, 9 May 2024 13:09:40 -0500
Subject: Status of ZIP64 InputStream bug JDK-8298530?
In-Reply-To: <20240509174013.A459D6604A7@dd33810.kasserver.com>
References: <20240509174013.A459D6604A7@dd33810.kasserver.com>
Message-ID: <CANSoFxtKc=w9zy5TUFJDWpX7FhEVmzVVj1w9yZvV17F2ZUJbKA@mail.gmail.com>

On Thu, May 9, 2024 at 12:43?PM Bernd Eckenfels <ecki at zusammenkunft.net>
wrote:

> But this one here is still open:
>
> * [JDK-8298530] ZipInputStream.readEnd fails for certain ZIP64 archives
> with small files - Java Bug System (openjdk.org)
> <https://bugs.openjdk.org/browse/JDK-8298530>
>
FWIW when I run the test case in that bug on the latest JDK 23
(jdk-23+21-110-g0a4eeeaa3c6), it does not report any exception.

So this bug may have gotten fixed by recent changes and just needs to be
closed... ?

-Archie

-- 
Archie L. Cobbs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240509/be1ef838/attachment.htm>

From joehw at openjdk.org  Thu May  9 18:10:52 2024
From: joehw at openjdk.org (Joe Wang)
Date: Thu, 9 May 2024 18:10:52 GMT
Subject: RFR: 8331866: Add warnings for locale data dependence [v2]
In-Reply-To: <NFhmWXSpQli0IegcWGzil-9u-jqMAg3xpjDsQJgRgw0=.2db0adb3-0315-489b-a93d-7f2b795a8144@github.com>
References: <d1V8q3oaeh-cPvR_IE22WAHhoqrc1TXZMdEtIhxCLvM=.af6edbc8-49c1-4125-930d-42580dcb40c3@github.com>
 <NFhmWXSpQli0IegcWGzil-9u-jqMAg3xpjDsQJgRgw0=.2db0adb3-0315-489b-a93d-7f2b795a8144@github.com>
Message-ID: <IcKzmL7xwrYk9o53AToz7T4a0xlLvtVlnZz-kUgpRtw=.157236fc-6872-407f-8d38-49fcca4a343e@github.com>

On Thu, 9 May 2024 17:58:21 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> In order to enlighten users to not depend on a particular version of the locale data, putting a note into the JDK vs. CLDR version chart would be appropriate.
>
> Naoto Sato 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:
> 
>  - Addresses review comment
>  - Merge branch 'master' into JDK-8331866-localedata-dependence-warning
>  - initial commit

That sounds good.

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

Marked as reviewed by joehw (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19145#pullrequestreview-2048538458

From mcimadamore at openjdk.org  Thu May  9 18:26:17 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 9 May 2024 18:26:17 GMT
Subject: RFR: 8332003: Clarify javadoc for MemoryLayout::offsetHandle [v2]
In-Reply-To: <0uMhIaW3d_IBqbF_04WhHDKHiIXes04wawSuxc6dQxI=.7f5621f9-0d77-4433-bc00-1ff8624b65da@github.com>
References: <0uMhIaW3d_IBqbF_04WhHDKHiIXes04wawSuxc6dQxI=.7f5621f9-0d77-4433-bc00-1ff8624b65da@github.com>
Message-ID: <5mulKTante5HCCqQRyRwj2OUQ17mTSXWyExbK78q4e0=.db34eba6-f3c9-4004-815f-70e44f596d95@github.com>

> Consider this layout:
> 
> 
> MemoryLayout SEQ = MemoryLayout.sequenceLayout(5,
>              MemoryLayout.sequenceLayout(10, JAVA_INT));
> 
> 
> And the corresponding offset handle:
> 
> 
> MethodHandle offsetHandle = SEQ.offsetHandle(PathElement.sequenceLayout(), PathElement.sequenceLayout());
> 
> 
> The resulting method handle takes two additional `long` indices. The implementation checks that the dynamically provided indices conform to the bound available at construction: that is, the first index must be < 5, while the second must be < 10. If this is not true, an `IndexOutOfBoundException` is thrown.
> 
> However, the javadoc for `MemoryLayout::byteOffsetHandle` doesn't claim anything in this direction. There are only some vague claims in the javadoc for `PathElement::sequenceElement()` and `PathElement::sequenceElement(long, long, long)` which make some claims on which indices are actually allowed, but the text seems more in the tone of a discussion, rather than actual normative text.
> 
> I've tweaked the javadoc for `MemoryLayout::byteOffsetHandle` to actually state that the indices will be checked against the "size" of the corresponding open path element (this is a new concept that I also have defined in the javadoc).
> 
> I also added a test for `byteOffsetHandle` as I don't think we had a test for that specifically (although this method is tested indirectly, via `MemoryLayout::varHandle`).

Maurizio Cimadamore has updated the pull request incrementally with two additional commits since the last revision:

 - Update copyright
 - Add javadoc to other MemoryLayout methods returning VarHandle/MethodHandle to describe which exception can be thrown by returned handle

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/19158/files
  - new: https://git.openjdk.org/jdk/pull/19158/files/7cfd222b..aa644d3d

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

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

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

From prappo at openjdk.org  Thu May  9 18:27:08 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Thu, 9 May 2024 18:27:08 GMT
Subject: RFR: 8305457: Implement java.io.IO [v7]
In-Reply-To: <w2msiw_qaMEIJS3s9D4bg8pFbz5WIF0KdP6Mm-XFjLI=.85b2020b-8c46-4bac-8a69-4975b068f2ff@github.com>
References: <w2msiw_qaMEIJS3s9D4bg8pFbz5WIF0KdP6Mm-XFjLI=.85b2020b-8c46-4bac-8a69-4975b068f2ff@github.com>
Message-ID: <554HmRIAD_1Hf8Hbq6_YRH9iTf8fBk_OZ1XrlmSsQAU=.90c8b148-029a-429f-9037-179d9d30f6ad@github.com>

> Please review this PR which introduces the `java.io.IO` top-level class and three methods to `java.io.Console` for [Implicitly Declared Classes and Instance Main Methods (Third Preview)].
> 
> This PR has been obtained as `git merge --squash` of a now obsolete [draft PR].
> 
> [Implicitly Declared Classes and Instance Main Methods (Third Preview)]: https://bugs.openjdk.org/browse/JDK-8323335
> [draft PR]: https://github.com/openjdk/jdk/pull/18921

Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:

  Fix System.console().readln(null) in jshell
  
  Without it, jshell hangs on me. Will think of a test.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/19112/files
  - new: https://git.openjdk.org/jdk/pull/19112/files/46a7af1f..1bf7a4cd

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

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

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

From mcimadamore at openjdk.org  Thu May  9 18:31:52 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 9 May 2024 18:31:52 GMT
Subject: RFR: 8332003: Clarify javadoc for MemoryLayout::offsetHandle [v2]
In-Reply-To: <5mulKTante5HCCqQRyRwj2OUQ17mTSXWyExbK78q4e0=.db34eba6-f3c9-4004-815f-70e44f596d95@github.com>
References: <0uMhIaW3d_IBqbF_04WhHDKHiIXes04wawSuxc6dQxI=.7f5621f9-0d77-4433-bc00-1ff8624b65da@github.com>
 <5mulKTante5HCCqQRyRwj2OUQ17mTSXWyExbK78q4e0=.db34eba6-f3c9-4004-815f-70e44f596d95@github.com>
Message-ID: <DoNutNYYx3qollLhqCc_lb-CoQevthz84z9ACikoUEU=.48ddcd5a-1fdb-4947-bd60-cdaff05fc0f9@github.com>

On Thu, 9 May 2024 18:26:17 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Consider this layout:
>> 
>> 
>> MemoryLayout SEQ = MemoryLayout.sequenceLayout(5,
>>              MemoryLayout.sequenceLayout(10, JAVA_INT));
>> 
>> 
>> And the corresponding offset handle:
>> 
>> 
>> MethodHandle offsetHandle = SEQ.offsetHandle(PathElement.sequenceLayout(), PathElement.sequenceLayout());
>> 
>> 
>> The resulting method handle takes two additional `long` indices. The implementation checks that the dynamically provided indices conform to the bound available at construction: that is, the first index must be < 5, while the second must be < 10. If this is not true, an `IndexOutOfBoundException` is thrown.
>> 
>> However, the javadoc for `MemoryLayout::byteOffsetHandle` doesn't claim anything in this direction. There are only some vague claims in the javadoc for `PathElement::sequenceElement()` and `PathElement::sequenceElement(long, long, long)` which make some claims on which indices are actually allowed, but the text seems more in the tone of a discussion, rather than actual normative text.
>> 
>> I've tweaked the javadoc for `MemoryLayout::byteOffsetHandle` to actually state that the indices will be checked against the "size" of the corresponding open path element (this is a new concept that I also have defined in the javadoc).
>> 
>> I also added a test for `byteOffsetHandle` as I don't think we had a test for that specifically (although this method is tested indirectly, via `MemoryLayout::varHandle`).
>
> Maurizio Cimadamore has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Update copyright
>  - Add javadoc to other MemoryLayout methods returning VarHandle/MethodHandle to describe which exception can be thrown by returned handle

In an offline discussion @minborg noted that other methods in the `MemoryLayout` class do not specify in full the set exception thrown by the returned method handle/var handle:

* MemoryLayout::varHandle
* MemoryLayout::sliceHandle
* MemoryLayout::arrayElementVarHandle

The first two are missing details re. checks against the upper bound of the index parameter/coordinates. I believe this omission was because these methods already say that if the accessed offset is bigger than the segment size, then a IIOBE occurs. But there's a subtle problem with it. In the impl, even if you have a big enough memory segment to allow access at index 42, but the layout says that the max index is 41, access fails with IIOBE anyway. So I think the javadoc should be updated to contain the new text about the index checks.

The last method in the list actually doesn't have any text when it comes to the exceptions thrown by the returned handle. This is because we say that this method can be obtained by calling `collectCoordinates` on `MemoryLayout::varHandle`. Nevertheless, I think it's worth repeating what exceptions can come up (especially as doing so reveals more clearly that there's no extra checks for the very first long coordinate of the returned handle - so now the existing `apiNote` makes even more sense, I think).

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

PR Comment: https://git.openjdk.org/jdk/pull/19158#issuecomment-2103200882

From psandoz at openjdk.org  Thu May  9 18:40:53 2024
From: psandoz at openjdk.org (Paul Sandoz)
Date: Thu, 9 May 2024 18:40:53 GMT
Subject: RFR: 8332003: Clarify javadoc for MemoryLayout::offsetHandle [v2]
In-Reply-To: <5mulKTante5HCCqQRyRwj2OUQ17mTSXWyExbK78q4e0=.db34eba6-f3c9-4004-815f-70e44f596d95@github.com>
References: <0uMhIaW3d_IBqbF_04WhHDKHiIXes04wawSuxc6dQxI=.7f5621f9-0d77-4433-bc00-1ff8624b65da@github.com>
 <5mulKTante5HCCqQRyRwj2OUQ17mTSXWyExbK78q4e0=.db34eba6-f3c9-4004-815f-70e44f596d95@github.com>
Message-ID: <BusBEXXTqhx4JepFQ887tSBMxuA-bMuYDZHNH5rySa4=.d7d56f70-d5dc-4bc2-9d37-c714670b92ce@github.com>

On Thu, 9 May 2024 18:26:17 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Consider this layout:
>> 
>> 
>> MemoryLayout SEQ = MemoryLayout.sequenceLayout(5,
>>              MemoryLayout.sequenceLayout(10, JAVA_INT));
>> 
>> 
>> And the corresponding offset handle:
>> 
>> 
>> MethodHandle offsetHandle = SEQ.offsetHandle(PathElement.sequenceLayout(), PathElement.sequenceLayout());
>> 
>> 
>> The resulting method handle takes two additional `long` indices. The implementation checks that the dynamically provided indices conform to the bound available at construction: that is, the first index must be < 5, while the second must be < 10. If this is not true, an `IndexOutOfBoundException` is thrown.
>> 
>> However, the javadoc for `MemoryLayout::byteOffsetHandle` doesn't claim anything in this direction. There are only some vague claims in the javadoc for `PathElement::sequenceElement()` and `PathElement::sequenceElement(long, long, long)` which make some claims on which indices are actually allowed, but the text seems more in the tone of a discussion, rather than actual normative text.
>> 
>> I've tweaked the javadoc for `MemoryLayout::byteOffsetHandle` to actually state that the indices will be checked against the "size" of the corresponding open path element (this is a new concept that I also have defined in the javadoc).
>> 
>> I also added a test for `byteOffsetHandle` as I don't think we had a test for that specifically (although this method is tested indirectly, via `MemoryLayout::varHandle`).
>
> Maurizio Cimadamore has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Update copyright
>  - Add javadoc to other MemoryLayout methods returning VarHandle/MethodHandle to describe which exception can be thrown by returned handle

src/java.base/share/classes/java/lang/foreign/MemoryLayout.java line 574:

> 572:      * {@code c_1}, {@code c_2}, ... {@code c_m} are other <em>static</em> offset
> 573:      * constants (such as field offsets) which are derived from the layout path.
> 574:      * <p>

Can we connected back to the prior paragraph? e.g., for any given dynamic argument `x_n`, the index into the sequence associated with the n'th open path element whose size is `size_n`,`x_n` must be `>= 0` or `< size_n`

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19158#discussion_r1595836040

From bchristi at openjdk.org  Thu May  9 18:44:10 2024
From: bchristi at openjdk.org (Brent Christian)
Date: Thu, 9 May 2024 18:44:10 GMT
Subject: RFR: 8314480: Memory ordering spec updates in java.lang.ref [v31]
In-Reply-To: <R74ontYwjYg6HeZY0cWrlo0amjl4E1YsFWeuh4pda14=.08ac62df-b2f8-4b4d-b338-07adb289601b@github.com>
References: <R74ontYwjYg6HeZY0cWrlo0amjl4E1YsFWeuh4pda14=.08ac62df-b2f8-4b4d-b338-07adb289601b@github.com>
Message-ID: <aUZHna4VBbB2ClvbJsoTwojkQfCE8-l2z9BDQaXHAIs=.8197a754-5559-4653-820f-ad9d92f72316@github.com>

> Classes in the `java.lang.ref` package would benefit from an update to bring the spec in line with how the VM already behaves. The changes would focus on _happens-before_ edges at some key points during reference processing.
> 
> A couple key things we want to be able to say are:
> - `Reference.reachabilityFence(x)` _happens-before_ reference processing occurs for 'x'.
> - `Cleaner.register()` _happens-before_ the Cleaner thread runs the registered cleaning action.
> 
> This will bring Cleaner in line (or close) with the memory visibility guarantees made for finalizers in [JLS 17.4.5](https://docs.oracle.com/javase/specs/jls/se18/html/jls-17.html#jls-17.4.5):
> _"There is a happens-before edge from the end of a constructor of an object to the start of a finalizer (?12.6) for that object."_

Brent Christian has updated the pull request incrementally with one additional commit since the last revision:

  add link to Thread.isAlive()

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16644/files
  - new: https://git.openjdk.org/jdk/pull/16644/files/5db47889..4efa5d18

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16644&range=30
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16644&range=29-30

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

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

From redestad at openjdk.org  Thu May  9 19:20:54 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Thu, 9 May 2024 19:20:54 GMT
Subject: RFR: 8331744: java.lang.classfile.TypeKind improvements [v4]
In-Reply-To: <a4JaRWnOJr5XaoPoEqvt3mAk0uxnwdkJTlsKXuMNmNw=.cf9d0b66-db85-47e9-9145-d6cdc60bd752@github.com>
References: <_x31CU5mODg3NGaRGzI5HdNdcjsKmqWb1TA7KZnZcFg=.43ce5ba3-71e7-42e5-a531-c3b609d0aafb@github.com>
 <-6l188kBfGFxic3KxI-qxyVpPWEbwt4Z5O1nJbfCHQQ=.e460344f-b23f-4dcd-95a3-a12f478687d7@github.com>
 <2ehu58tQasyDZc-dqUtnjUdazTfEXl9F_-4jimHTmHY=.37ab1963-092e-41d6-a751-7a33c05e66db@github.com>
 <0Qn9e3pKNILgtBPABu9VtbjyRrsyeGcp_Fob0B2NroA=.1975072e-85bb-41b0-8d9b-df4170a7ea9c@github.com>
 <a4JaRWnOJr5XaoPoEqvt3mAk0uxnwdkJTlsKXuMNmNw=.cf9d0b66-db85-47e9-9145-d6cdc60bd752@github.com>
Message-ID: <zkz37GbvlxuZDr4gADz1vg9jRQUTAX5oEJKD-wxOGx0=.f9103541-68f7-452d-993a-28904782616f@github.com>

On Thu, 9 May 2024 12:29:40 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> I actually am not sure of the reason; it is indeed a tableswitch in bytecode. @cl4es might know it better?
>
> Generally I agree with the API changes and with the `descriptor.isPrimitive()` test before requesting a descriptor string.
> However I'm missing the point of the other changes, which only replace this single `tableswitch` with something way more complicated, without clear performance gain.

The code I tested saw a decidedly larger speed-up, perhaps hinging on other optimizations such as being able to avoid the `s.isEmpty()` check (could maybe catch IIOBE) and not matching on `L` and `[` (the lookup table only needs to deal with primitives). As it looks here I agree the speed-up is negligible and not worth it, and since `TypeDescriptor.OfField` isn't a sealed hierarchy perhaps we need some redundant checks.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19109#discussion_r1595873311

From szaldana at openjdk.org  Thu May  9 19:52:12 2024
From: szaldana at openjdk.org (Sonia Zaldana Calles)
Date: Thu, 9 May 2024 19:52:12 GMT
Subject: RFR: 8329581: Java launcher no longer prints a stack trace [v9]
In-Reply-To: <OSB-RYHDOcS3rbr3_rsRmDPO-GFps7FXT_LD_2M2PHM=.2c4dc9d2-f40f-45e1-98f8-3c0aa2fb9c67@github.com>
References: <Z0pDMIc_XvZhcZdeFsIQUlqI17q5ybj0BnQ9Kl3jwxg=.8f981c46-a8a3-4520-a6e3-79ee7fce0253@github.com>
 <krgANOmUJpt38cg16YhdXnUibxgX4shajEyWnMF79Hc=.e2dba0cc-8085-4efd-a300-d9c7f771510b@github.com>
 <OSB-RYHDOcS3rbr3_rsRmDPO-GFps7FXT_LD_2M2PHM=.2c4dc9d2-f40f-45e1-98f8-3c0aa2fb9c67@github.com>
Message-ID: <DjXIQXr_CK3q3-W506Ms-62DW1hlpgGRtrJ_Av7HJL0=.9cc03a10-456e-4c5c-a78d-2f8821f3dca8@github.com>

On Wed, 8 May 2024 09:37:58 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> This may be food for another RFE, to keep this patch minimal. But a good solution, to me, would be like this:
> 
> * have the same logic for return codes (1 = error, 0 = success) to ease understanding
> * have clearly named constants (e.g. "LAUNCHER_OK" 0, "LAUNCHER_ERR" = 1)
> * have the LEAVE macro take the launcher return code as argument
> * have all xxx_LEAVE macros pass in LAUNCHER_ERR to LEAVE
> * call the final LEAVE with LAUNCHER_OK
> * optionally, define something like "LEAVE_ERR" and "LEAVE_OK" that call LEAVE with either LAUNCHER_ERR or LAUNCHER_OK, for more concise coding.
> 
> For this patch, I think the return code logic is okay, but I would feel better if others double-checked.

@tstuefe Agreed, I can look into opening another issue to track this after we fix the regression.

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

PR Comment: https://git.openjdk.org/jdk/pull/18786#issuecomment-2103312450

From szaldana at openjdk.org  Thu May  9 19:52:12 2024
From: szaldana at openjdk.org (Sonia Zaldana Calles)
Date: Thu, 9 May 2024 19:52:12 GMT
Subject: RFR: 8329581: Java launcher no longer prints a stack trace [v10]
In-Reply-To: <Z0pDMIc_XvZhcZdeFsIQUlqI17q5ybj0BnQ9Kl3jwxg=.8f981c46-a8a3-4520-a6e3-79ee7fce0253@github.com>
References: <Z0pDMIc_XvZhcZdeFsIQUlqI17q5ybj0BnQ9Kl3jwxg=.8f981c46-a8a3-4520-a6e3-79ee7fce0253@github.com>
Message-ID: <nFQS3JDegumTJOWSla6qGad04vc7PP7W3ZZ483XQuqs=.d28be017-00a0-44e0-9eee-bd70d56498e8@github.com>

> Hi folks, 
> 
> This PR aims to fix [JDK-8329581](https://bugs.openjdk.org/browse/JDK-8329581). 
> 
> I think the regression got introduced in [JDK-8315458](https://bugs.openjdk.org/browse/JDK-8315458). 
> 
> In the issue linked above, [LauncherHelper#getMainType](https://github.com/openjdk/jdk/pull/16461/files#diff-108a3a3e3c2d108c8c7f19ea498f641413b7c9239ecd2975a6c27d904c2ba226) got removed to simplify launcher code.
> 
> Previously, we used ```getMainType``` to do the appropriate main method invocation in ```JavaMain```. However, we currently attempt to do all types of main method invocations at the same time [here](https://github.com/openjdk/jdk/blob/master/src/java.base/share/native/libjli/java.c#L623). 
> 
> Note how all of these invocations clear the exception reported with [CHECK_EXCEPTION_FAIL](https://github.com/openjdk/jdk/blob/140f56718bbbfc31bb0c39255c68568fad285a1f/src/java.base/share/native/libjli/java.c#L390). 
> 
> Therefore, if a legitimate exception comes up during one of these invocations, it does not get reported. 
> 
> I propose reintroducing ```LauncherHelper#getMainType``` but I'm looking forward to your suggestions. 
> 
> Cheers, 
> Sonia

Sonia Zaldana Calles has updated the pull request incrementally with one additional commit since the last revision:

  Decreasing diff size addressing unnecessary changes

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18786/files
  - new: https://git.openjdk.org/jdk/pull/18786/files/9b67fd86..1a0c76f2

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

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

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

From liach at openjdk.org  Thu May  9 21:05:30 2024
From: liach at openjdk.org (Chen Liang)
Date: Thu, 9 May 2024 21:05:30 GMT
Subject: RFR: 8311175: Move BufWriter::asByteBuffer to BufWriterImpl [v3]
In-Reply-To: <sEKITMKa0yBPrV7RTKYa0_GGSOss8a9T7GaOQpLaEYk=.f7ad0b39-bc77-4589-a8de-ef5132387e6c@github.com>
References: <sEKITMKa0yBPrV7RTKYa0_GGSOss8a9T7GaOQpLaEYk=.f7ad0b39-bc77-4589-a8de-ef5132387e6c@github.com>
Message-ID: <1VAz8XnQj-itCdrsnaVC-2kJNgLgvmbTWoQ7BXt8ybk=.b97694d2-dd17-4bc0-9c05-7a120109711c@github.com>

> As discussed on the mailing list https://mail.openjdk.org/pipermail/classfile-api-dev/2023-June/000381.html, BufWriter::asByteBuffer has a behavior not suitable for API and is only used by internal StackMapGenerator/StackCounter, so it will be converted to an internal API.
> 
> Somehow the ByteBuffer needs to be sliced, or StackMapGenerator encounters IOOBE. Not sure what the exact cause was.

Chen Liang has updated the pull request incrementally with one additional commit since the last revision:

  Redundant import, copyright year

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14736/files
  - new: https://git.openjdk.org/jdk/pull/14736/files/d82789c3..8830ca25

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

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

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

From liach at openjdk.org  Thu May  9 21:15:31 2024
From: liach at openjdk.org (Chen Liang)
Date: Thu, 9 May 2024 21:15:31 GMT
Subject: RFR: 8331744: java.lang.classfile.TypeKind improvements [v5]
In-Reply-To: <_x31CU5mODg3NGaRGzI5HdNdcjsKmqWb1TA7KZnZcFg=.43ce5ba3-71e7-42e5-a531-c3b609d0aafb@github.com>
References: <_x31CU5mODg3NGaRGzI5HdNdcjsKmqWb1TA7KZnZcFg=.43ce5ba3-71e7-42e5-a531-c3b609d0aafb@github.com>
Message-ID: <jXeaNMrczPVr7MhMJRdA8VtoGT4J8F8jJi2CL3fJdsg=.82f94657-7cd4-42f6-a337-8adc9890e92e@github.com>

> A peek into TypeKind during the research for #19105 reveals that TypeKind has a few issues:
> 1. Name mismatch for `newarraycode` and `fromNewArrayCode`: Renamed both to use "newarray code"
> 2. `fromDescriptor` can throw IOOBE if the input string is empty: changed to throw IAE and added tests.
> 3. `from(Class)` can be slow due to descriptor computation: added benchmark, will share result in next comment (as it may change with code changes).
> 
> The first 2 changes involves API changes, and a CSR has been created. Requesting @asotona for a review.

Chen Liang has updated the pull request incrementally with two additional commits since the last revision:

 - Restore fixed seed
 - Revert "Hash table, use fixed random seed"
   
   This reverts commit 9af30c65d2c7be3535e4483e278151bc4473d63c.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/19109/files
  - new: https://git.openjdk.org/jdk/pull/19109/files/9af30c65..ae9e793e

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

  Stats: 64 lines in 2 files changed: 8 ins; 51 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/19109.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19109/head:pull/19109

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

From liach at openjdk.org  Thu May  9 21:19:09 2024
From: liach at openjdk.org (Chen Liang)
Date: Thu, 9 May 2024 21:19:09 GMT
Subject: RFR: 8331744: java.lang.classfile.TypeKind improvements [v5]
In-Reply-To: <jXeaNMrczPVr7MhMJRdA8VtoGT4J8F8jJi2CL3fJdsg=.82f94657-7cd4-42f6-a337-8adc9890e92e@github.com>
References: <_x31CU5mODg3NGaRGzI5HdNdcjsKmqWb1TA7KZnZcFg=.43ce5ba3-71e7-42e5-a531-c3b609d0aafb@github.com>
 <jXeaNMrczPVr7MhMJRdA8VtoGT4J8F8jJi2CL3fJdsg=.82f94657-7cd4-42f6-a337-8adc9890e92e@github.com>
Message-ID: <8ExVAXNqr-wHzCiwW6Mg7sQB-pnkS8XaNvkW01agGHY=.7433ded6-97ef-4640-804e-80e432f483d8@github.com>

On Thu, 9 May 2024 21:15:31 GMT, Chen Liang <liach at openjdk.org> wrote:

>> A peek into TypeKind during the research for #19105 reveals that TypeKind has a few issues:
>> 1. Name mismatch for `newarraycode` and `fromNewArrayCode`: Renamed both to use "newarray code"
>> 2. `fromDescriptor` can throw IOOBE if the input string is empty: changed to throw IAE and added tests.
>> 3. `from(Class)` can be slow due to descriptor computation: added benchmark, will share result in next comment (as it may change with code changes).
>> 
>> The first 2 changes involves API changes, and a CSR has been created. Requesting @asotona for a review.
>
> Chen Liang has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Restore fixed seed
>  - Revert "Hash table, use fixed random seed"
>    
>    This reverts commit 9af30c65d2c7be3535e4483e278151bc4473d63c.

I have reverted the hash table as discussed. Can you both review this version again?
`TypeKind.from` shouldn't be too much of a bottleneck in ClassFile building, as it's mostly just used for local variable loading; we can just stay with this proven optimization for non-primitives and revisit later if profiling reveals this is a bottleneck.

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

PR Comment: https://git.openjdk.org/jdk/pull/19109#issuecomment-2103432789

From duke at openjdk.org  Thu May  9 22:23:02 2024
From: duke at openjdk.org (Volodymyr Paprotski)
Date: Thu, 9 May 2024 22:23:02 GMT
Subject: RFR: 8329538: Accelerate P256 on x86_64 using Montgomery intrinsic
 [v7]
In-Reply-To: <hanRK4GzOkFV8kG1gZRy8Br53trw4-Tu6G6uO8nsFuk=.d5bf723a-f683-4759-ac9e-4a58cb430f03@github.com>
References: <hanRK4GzOkFV8kG1gZRy8Br53trw4-Tu6G6uO8nsFuk=.d5bf723a-f683-4759-ac9e-4a58cb430f03@github.com>
Message-ID: <m_OjbVv0b9xFwOjbTzFaSnw0KQqzVdZxh0C_a7QbwDQ=.8ec34a61-d57b-4243-a6f3-0c3721a6d93c@github.com>

> Performance. Before:
> 
> Benchmark                        (algorithm)  (dataSize)  (keyLength)  (provider)   Mode  Cnt     Score    Error  Units
> SignatureBench.ECDSA.sign    SHA256withECDSA        1024          256              thrpt    3  6443.934 ?  6.491  ops/s
> SignatureBench.ECDSA.sign    SHA256withECDSA       16384          256              thrpt    3  6152.979 ?  4.954  ops/s
> SignatureBench.ECDSA.verify  SHA256withECDSA        1024          256              thrpt    3  1895.410 ? 36.979  ops/s
> SignatureBench.ECDSA.verify  SHA256withECDSA       16384          256              thrpt    3  1878.955 ? 45.487  ops/s
> Benchmark                                            (algorithm)  (keyLength)  (kpgAlgorithm)  (provider)   Mode  Cnt     Score    Error  Units
> o.o.b.j.c.full.KeyAgreementBench.EC.generateSecret          ECDH          256              EC              thrpt    3  1357.810 ? 26.584  ops/s
> o.o.b.j.c.small.KeyAgreementBench.EC.generateSecret         ECDH          256              EC              thrpt    3  1352.119 ? 23.547  ops/s
> Benchmark                          (isMontBench)   Mode  Cnt     Score    Error  Units
> PolynomialP256Bench.benchMultiply          false  thrpt    3  1746.126 ? 10.970  ops/s
> 
> Performance, no intrinsic:
> 
> Benchmark                        (algorithm)  (dataSize)  (keyLength)  (provider)   Mode  Cnt     Score     Error  Units
> SignatureBench.ECDSA.sign    SHA256withECDSA        1024          256              thrpt    3  6529.839 ?  42.420  ops/s
> SignatureBench.ECDSA.sign    SHA256withECDSA       16384          256              thrpt    3  6199.747 ? 133.566  ops/s
> SignatureBench.ECDSA.verify  SHA256withECDSA        1024          256              thrpt    3  1973.676 ?  54.071  ops/s
> SignatureBench.ECDSA.verify  SHA256withECDSA       16384          256              thrpt    3  1932.127 ?  35.920  ops/s
> Benchmark                                            (algorithm)  (keyLength)  (kpgAlgorithm)  (provider)   Mode  Cnt     Score    Error  Units
> o.o.b.j.c.full.KeyAgreementBench.EC.generateSecret          ECDH          256              EC              thrpt    3  1355.788 ? 29.858  ops/s
> o.o.b.j.c.small.KeyAgreementBench.EC.generateSecret         ECDH          256              EC              thrpt    3  1346.523 ? 28.722  ops/s
> Benchmark                          (isMontBench)   Mode  Cnt     Score    Error  Units
> PolynomialP256Bench.benchMultiply           true  thrpt    3  1919.574 ? 10.591  ops/s
> 
> Performance, **with intrinsics*...

Volodymyr Paprotski has updated the pull request incrementally with one additional commit since the last revision:

  whitespace

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18583/files
  - new: https://git.openjdk.org/jdk/pull/18583/files/8ff243a2..1ecfdc44

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

  Stats: 753 lines in 9 files changed: 303 ins; 101 del; 349 mod
  Patch: https://git.openjdk.org/jdk/pull/18583.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18583/head:pull/18583

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

From naoto at openjdk.org  Thu May  9 22:40:03 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 9 May 2024 22:40:03 GMT
Subject: RFR: 8331646: Add specific regression leap year tests [v4]
In-Reply-To: <9VgLKRC2j_6DXZCeEcprn5sCYYWu_FDo1SHD7bAHVnQ=.1fb7a7a8-d8f4-4ae9-abfe-7aaa6cd4722f@github.com>
References: <cB-Q8ihe6DYQTm1WcRvVV3oW8YXtnWH5fmsS1zurwwY=.176d4137-bd3b-445e-a055-c738bd73744c@github.com>
 <9VgLKRC2j_6DXZCeEcprn5sCYYWu_FDo1SHD7bAHVnQ=.1fb7a7a8-d8f4-4ae9-abfe-7aaa6cd4722f@github.com>
Message-ID: <SCQ1dukmHDhwpmV1OKUBFN1tGteVxn6Ie5RDxw2UzPo=.7c110bc6-f3ca-4acc-a96f-f0ee668cb744@github.com>

On Thu, 9 May 2024 09:10:20 GMT, serhiysachkov <duke at openjdk.org> wrote:

>> Calendar.add() tests that describe its behavior.
>
> serhiysachkov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   JDK-8331646 updating impl according to review requests

LGTM. Please fix the typo before integrate

test/jdk/java/util/Calendar/CalendarLeapYearAddTest.java line 116:

> 114:                 Arguments.of("testDateAddSubtractLeapYear", 29, FEBRUARY, 2024, 365, -365, DATE, 29, FEBRUARY, 2024),
> 115:                 Arguments.of("testWeekOfYearAddSubtractLeapYear", 29, FEBRUARY, 2024, 52, -52, WEEK_OF_YEAR, 29, FEBRUARY, 2024),
> 116:                 Arguments.of("testDateOfMonthAddSubtractLeapYear", 29, FEBRUARY, 2024, 31, -31, DAY_OF_MONTH, 29, FEBRUARY, 2024),

"DateOfMonth" -> "DayOfMonth"

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

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19082#pullrequestreview-2048948832
PR Review Comment: https://git.openjdk.org/jdk/pull/19082#discussion_r1596061264

From ascarpino at openjdk.org  Thu May  9 23:39:06 2024
From: ascarpino at openjdk.org (Anthony Scarpino)
Date: Thu, 9 May 2024 23:39:06 GMT
Subject: RFR: 8329538: Accelerate P256 on x86_64 using Montgomery intrinsic
 [v7]
In-Reply-To: <m_OjbVv0b9xFwOjbTzFaSnw0KQqzVdZxh0C_a7QbwDQ=.8ec34a61-d57b-4243-a6f3-0c3721a6d93c@github.com>
References: <hanRK4GzOkFV8kG1gZRy8Br53trw4-Tu6G6uO8nsFuk=.d5bf723a-f683-4759-ac9e-4a58cb430f03@github.com>
 <m_OjbVv0b9xFwOjbTzFaSnw0KQqzVdZxh0C_a7QbwDQ=.8ec34a61-d57b-4243-a6f3-0c3721a6d93c@github.com>
Message-ID: <j9mOguQLRpKMzkqgxhAMHr1KX3X0dgpYpRL2XWSQHGk=.feb9e3c4-a264-4447-a733-b0ae54efd198@github.com>

On Thu, 9 May 2024 22:23:02 GMT, Volodymyr Paprotski <duke at openjdk.org> wrote:

>> Performance. Before:
>> 
>> Benchmark                        (algorithm)  (dataSize)  (keyLength)  (provider)   Mode  Cnt     Score    Error  Units
>> SignatureBench.ECDSA.sign    SHA256withECDSA        1024          256              thrpt    3  6443.934 ?  6.491  ops/s
>> SignatureBench.ECDSA.sign    SHA256withECDSA       16384          256              thrpt    3  6152.979 ?  4.954  ops/s
>> SignatureBench.ECDSA.verify  SHA256withECDSA        1024          256              thrpt    3  1895.410 ? 36.979  ops/s
>> SignatureBench.ECDSA.verify  SHA256withECDSA       16384          256              thrpt    3  1878.955 ? 45.487  ops/s
>> Benchmark                                            (algorithm)  (keyLength)  (kpgAlgorithm)  (provider)   Mode  Cnt     Score    Error  Units
>> o.o.b.j.c.full.KeyAgreementBench.EC.generateSecret          ECDH          256              EC              thrpt    3  1357.810 ? 26.584  ops/s
>> o.o.b.j.c.small.KeyAgreementBench.EC.generateSecret         ECDH          256              EC              thrpt    3  1352.119 ? 23.547  ops/s
>> Benchmark                          (isMontBench)   Mode  Cnt     Score    Error  Units
>> PolynomialP256Bench.benchMultiply          false  thrpt    3  1746.126 ? 10.970  ops/s
>> 
>> Performance, no intrinsic:
>> 
>> Benchmark                        (algorithm)  (dataSize)  (keyLength)  (provider)   Mode  Cnt     Score     Error  Units
>> SignatureBench.ECDSA.sign    SHA256withECDSA        1024          256              thrpt    3  6529.839 ?  42.420  ops/s
>> SignatureBench.ECDSA.sign    SHA256withECDSA       16384          256              thrpt    3  6199.747 ? 133.566  ops/s
>> SignatureBench.ECDSA.verify  SHA256withECDSA        1024          256              thrpt    3  1973.676 ?  54.071  ops/s
>> SignatureBench.ECDSA.verify  SHA256withECDSA       16384          256              thrpt    3  1932.127 ?  35.920  ops/s
>> Benchmark                                            (algorithm)  (keyLength)  (kpgAlgorithm)  (provider)   Mode  Cnt     Score    Error  Units
>> o.o.b.j.c.full.KeyAgreementBench.EC.generateSecret          ECDH          256              EC              thrpt    3  1355.788 ? 29.858  ops/s
>> o.o.b.j.c.small.KeyAgreementBench.EC.generateSecret         ECDH          256              EC              thrpt    3  1346.523 ? 28.722  ops/s
>> Benchmark                          (isMontBench)   Mode  Cnt     Score    Error  Units
>> PolynomialP256Bench.benchMultiply           true  thrpt    3  1919.57...
>
> Volodymyr Paprotski has updated the pull request incrementally with one additional commit since the last revision:
> 
>   whitespace

src/java.base/share/classes/sun/security/ec/ECOperations.java line 701:

> 699:                         if (!m.equals(v)) {
> 700:                             java.util.HexFormat hex = java.util.HexFormat.of();
> 701:                             throw new RuntimeException();

I think your cleanup went to far. You should have some message saying they are not equal and if you don't want to print hex, remove getting an instance.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18583#discussion_r1596099182

From duke at openjdk.org  Fri May 10 00:15:40 2024
From: duke at openjdk.org (Volodymyr Paprotski)
Date: Fri, 10 May 2024 00:15:40 GMT
Subject: RFR: 8329538: Accelerate P256 on x86_64 using Montgomery intrinsic
 [v8]
In-Reply-To: <hanRK4GzOkFV8kG1gZRy8Br53trw4-Tu6G6uO8nsFuk=.d5bf723a-f683-4759-ac9e-4a58cb430f03@github.com>
References: <hanRK4GzOkFV8kG1gZRy8Br53trw4-Tu6G6uO8nsFuk=.d5bf723a-f683-4759-ac9e-4a58cb430f03@github.com>
Message-ID: <p4V5t8t0qRgbqTBq4wb8QOR9_0ZE1cvUO_HE97xuKYw=.93bae693-7e83-4e5f-990b-bbb74a16d6e8@github.com>

> Performance. Before:
> 
> Benchmark                        (algorithm)  (dataSize)  (keyLength)  (provider)   Mode  Cnt     Score    Error  Units
> SignatureBench.ECDSA.sign    SHA256withECDSA        1024          256              thrpt    3  6443.934 ?  6.491  ops/s
> SignatureBench.ECDSA.sign    SHA256withECDSA       16384          256              thrpt    3  6152.979 ?  4.954  ops/s
> SignatureBench.ECDSA.verify  SHA256withECDSA        1024          256              thrpt    3  1895.410 ? 36.979  ops/s
> SignatureBench.ECDSA.verify  SHA256withECDSA       16384          256              thrpt    3  1878.955 ? 45.487  ops/s
> Benchmark                                            (algorithm)  (keyLength)  (kpgAlgorithm)  (provider)   Mode  Cnt     Score    Error  Units
> o.o.b.j.c.full.KeyAgreementBench.EC.generateSecret          ECDH          256              EC              thrpt    3  1357.810 ? 26.584  ops/s
> o.o.b.j.c.small.KeyAgreementBench.EC.generateSecret         ECDH          256              EC              thrpt    3  1352.119 ? 23.547  ops/s
> Benchmark                          (isMontBench)   Mode  Cnt     Score    Error  Units
> PolynomialP256Bench.benchMultiply          false  thrpt    3  1746.126 ? 10.970  ops/s
> 
> Performance, no intrinsic:
> 
> Benchmark                        (algorithm)  (dataSize)  (keyLength)  (provider)   Mode  Cnt     Score     Error  Units
> SignatureBench.ECDSA.sign    SHA256withECDSA        1024          256              thrpt    3  6529.839 ?  42.420  ops/s
> SignatureBench.ECDSA.sign    SHA256withECDSA       16384          256              thrpt    3  6199.747 ? 133.566  ops/s
> SignatureBench.ECDSA.verify  SHA256withECDSA        1024          256              thrpt    3  1973.676 ?  54.071  ops/s
> SignatureBench.ECDSA.verify  SHA256withECDSA       16384          256              thrpt    3  1932.127 ?  35.920  ops/s
> Benchmark                                            (algorithm)  (keyLength)  (kpgAlgorithm)  (provider)   Mode  Cnt     Score    Error  Units
> o.o.b.j.c.full.KeyAgreementBench.EC.generateSecret          ECDH          256              EC              thrpt    3  1355.788 ? 29.858  ops/s
> o.o.b.j.c.small.KeyAgreementBench.EC.generateSecret         ECDH          256              EC              thrpt    3  1346.523 ? 28.722  ops/s
> Benchmark                          (isMontBench)   Mode  Cnt     Score    Error  Units
> PolynomialP256Bench.benchMultiply           true  thrpt    3  1919.574 ? 10.591  ops/s
> 
> Performance, **with intrinsics*...

Volodymyr Paprotski has updated the pull request incrementally with one additional commit since the last revision:

  add message back

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18583/files
  - new: https://git.openjdk.org/jdk/pull/18583/files/1ecfdc44..83b21310

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

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

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

From duke at openjdk.org  Fri May 10 00:15:40 2024
From: duke at openjdk.org (Volodymyr Paprotski)
Date: Fri, 10 May 2024 00:15:40 GMT
Subject: RFR: 8329538: Accelerate P256 on x86_64 using Montgomery intrinsic
 [v7]
In-Reply-To: <j9mOguQLRpKMzkqgxhAMHr1KX3X0dgpYpRL2XWSQHGk=.feb9e3c4-a264-4447-a733-b0ae54efd198@github.com>
References: <hanRK4GzOkFV8kG1gZRy8Br53trw4-Tu6G6uO8nsFuk=.d5bf723a-f683-4759-ac9e-4a58cb430f03@github.com>
 <m_OjbVv0b9xFwOjbTzFaSnw0KQqzVdZxh0C_a7QbwDQ=.8ec34a61-d57b-4243-a6f3-0c3721a6d93c@github.com>
 <j9mOguQLRpKMzkqgxhAMHr1KX3X0dgpYpRL2XWSQHGk=.feb9e3c4-a264-4447-a733-b0ae54efd198@github.com>
Message-ID: <g27kFRtKkS_2CZIubJwOL1K2EvK8MjTMdIeI7Os2q30=.6d734663-50a4-4e81-bdb3-ff335a3709ca@github.com>

On Thu, 9 May 2024 23:36:03 GMT, Anthony Scarpino <ascarpino at openjdk.org> wrote:

>> Volodymyr Paprotski has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   whitespace
>
> src/java.base/share/classes/sun/security/ec/ECOperations.java line 701:
> 
>> 699:                         if (!m.equals(v)) {
>> 700:                             java.util.HexFormat hex = java.util.HexFormat.of();
>> 701:                             throw new RuntimeException();
> 
> I think your cleanup went to far. You should have some message saying they are not equal and if you don't want to print hex, remove getting an instance.

I put the message back.. I removed it 'half'-intentionally; Was comparing against the original version and it didn't have  any details, thought maybe should follow suit. But I did find this message helpful, so its back.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18583#discussion_r1596116606

From duke at openjdk.org  Fri May 10 00:19:32 2024
From: duke at openjdk.org (Volodymyr Paprotski)
Date: Fri, 10 May 2024 00:19:32 GMT
Subject: RFR: 8329538: Accelerate P256 on x86_64 using Montgomery intrinsic
 [v9]
In-Reply-To: <hanRK4GzOkFV8kG1gZRy8Br53trw4-Tu6G6uO8nsFuk=.d5bf723a-f683-4759-ac9e-4a58cb430f03@github.com>
References: <hanRK4GzOkFV8kG1gZRy8Br53trw4-Tu6G6uO8nsFuk=.d5bf723a-f683-4759-ac9e-4a58cb430f03@github.com>
Message-ID: <g3g_VMiSRzuhMJ2JIlmtES7TjMGbKWxBMkfFvsQfvOs=.e0dea05e-8adc-48f3-8d1c-81352311de9c@github.com>

> Performance. Before:
> 
> Benchmark                        (algorithm)  (dataSize)  (keyLength)  (provider)   Mode  Cnt     Score    Error  Units
> SignatureBench.ECDSA.sign    SHA256withECDSA        1024          256              thrpt    3  6443.934 ?  6.491  ops/s
> SignatureBench.ECDSA.sign    SHA256withECDSA       16384          256              thrpt    3  6152.979 ?  4.954  ops/s
> SignatureBench.ECDSA.verify  SHA256withECDSA        1024          256              thrpt    3  1895.410 ? 36.979  ops/s
> SignatureBench.ECDSA.verify  SHA256withECDSA       16384          256              thrpt    3  1878.955 ? 45.487  ops/s
> Benchmark                                            (algorithm)  (keyLength)  (kpgAlgorithm)  (provider)   Mode  Cnt     Score    Error  Units
> o.o.b.j.c.full.KeyAgreementBench.EC.generateSecret          ECDH          256              EC              thrpt    3  1357.810 ? 26.584  ops/s
> o.o.b.j.c.small.KeyAgreementBench.EC.generateSecret         ECDH          256              EC              thrpt    3  1352.119 ? 23.547  ops/s
> Benchmark                          (isMontBench)   Mode  Cnt     Score    Error  Units
> PolynomialP256Bench.benchMultiply          false  thrpt    3  1746.126 ? 10.970  ops/s
> 
> Performance, no intrinsic:
> 
> Benchmark                        (algorithm)  (dataSize)  (keyLength)  (provider)   Mode  Cnt     Score     Error  Units
> SignatureBench.ECDSA.sign    SHA256withECDSA        1024          256              thrpt    3  6529.839 ?  42.420  ops/s
> SignatureBench.ECDSA.sign    SHA256withECDSA       16384          256              thrpt    3  6199.747 ? 133.566  ops/s
> SignatureBench.ECDSA.verify  SHA256withECDSA        1024          256              thrpt    3  1973.676 ?  54.071  ops/s
> SignatureBench.ECDSA.verify  SHA256withECDSA       16384          256              thrpt    3  1932.127 ?  35.920  ops/s
> Benchmark                                            (algorithm)  (keyLength)  (kpgAlgorithm)  (provider)   Mode  Cnt     Score    Error  Units
> o.o.b.j.c.full.KeyAgreementBench.EC.generateSecret          ECDH          256              EC              thrpt    3  1355.788 ? 29.858  ops/s
> o.o.b.j.c.small.KeyAgreementBench.EC.generateSecret         ECDH          256              EC              thrpt    3  1346.523 ? 28.722  ops/s
> Benchmark                          (isMontBench)   Mode  Cnt     Score    Error  Units
> PolynomialP256Bench.benchMultiply           true  thrpt    3  1919.574 ? 10.591  ops/s
> 
> Performance, **with intrinsics*...

Volodymyr Paprotski has updated the pull request incrementally with one additional commit since the last revision:

  whitespace

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18583/files
  - new: https://git.openjdk.org/jdk/pull/18583/files/83b21310..8cd095dd

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

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

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

From darcy at openjdk.org  Fri May 10 00:43:10 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 10 May 2024 00:43:10 GMT
Subject: RFR: 8330182: Start of release updates for JDK 24 [v4]
In-Reply-To: <YKsEQWuI-vNTEDjOBInuEjf8AEcTL4QZ_F4JYUqoxwk=.5ed43782-6dec-4383-948d-d9966a85b3bf@github.com>
References: <YKsEQWuI-vNTEDjOBInuEjf8AEcTL4QZ_F4JYUqoxwk=.5ed43782-6dec-4383-948d-d9966a85b3bf@github.com>
Message-ID: <8RuPOykuynrke0HG-JuhOP296mQX8P5QGdcJfjgPsS4=.da676135-40ae-4a23-9a1b-3bc7e3d1fee7@github.com>

> Get JDK 24 underway.

Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains ten commits:

 - Adjust test for deprecated options.
 - Merge branch 'master' into JDK-8330188
 - Update deprecated options test.
 - Merge branch 'master' into JDK-8330188
 - Merge branch 'master' into JDK-8330188
 - Merge branch 'master' into JDK-8330188
 - Correct release date as observed in review feedback.
 - Improve javadoc of class file update.
 - JDK-8330182: Start of release updates for JDK 24
   JDK-8330183: Add SourceVersion.RELEASE_24
   JDK-8330184: Add source 24 and target 24 to javac

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

Changes: https://git.openjdk.org/jdk/pull/18787/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18787&range=03
  Stats: 107 lines in 37 files changed: 46 ins; 7 del; 54 mod
  Patch: https://git.openjdk.org/jdk/pull/18787.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18787/head:pull/18787

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

From smarks at openjdk.org  Fri May 10 00:46:12 2024
From: smarks at openjdk.org (Stuart Marks)
Date: Fri, 10 May 2024 00:46:12 GMT
Subject: RFR: 8331876: JFR: Move file read and write events to java.base
 [v3]
In-Reply-To: <khrP38H7DBIyftQZtZt0CRXeH1ZkpOCjiRNvFTs3LSI=.fd62aba9-5153-4521-84e4-241b8a352720@github.com>
References: <DDe0bKCC86AawVl7RylZ74uvvLBr2Zljpkcmxx1_WEU=.61cc10c6-b635-42dd-a850-b32ae1d68585@github.com>
 <SejX7NAvWNjrhDEN8uDf4oikQDBRclWXDg1fN5FCpkc=.7de48c6f-0af2-4bf4-a743-6e173d950d52@github.com>
 <DgjIOZTfztdSEeODuNZw5MmzsiohA82hhllWCceyPyU=.7bda36a1-e26d-4d7e-822a-e443d3cbc0df@github.com>
 <khrP38H7DBIyftQZtZt0CRXeH1ZkpOCjiRNvFTs3LSI=.fd62aba9-5153-4521-84e4-241b8a352720@github.com>
Message-ID: <zGenHEqjgT6f_P_VtwfKbmzBeQoArW8MHwfAa6uVGVY=.eb912b9b-3f02-4cac-8d96-e1bdbaaea2b8@github.com>

On Thu, 9 May 2024 14:59:34 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

>> src/java.base/share/classes/java/io/FileInputStream.java line 63:
>> 
>>> 61:     private static final int DEFAULT_BUFFER_SIZE = 8192;
>>> 62: 
>>> 63:     // Flag that determines if file reads should be traced by JFR
>> 
>> It could be good to also note what will modify this flag - here and in other classes.
>> I'm going to guess that the purpose of this flag is purely performance, to avoid even loading the event class, `FileReadEvent` here, during startup/bootstrap and when JFR is not enabled, as read and write methods are highly performance sensitive? Otherwise the flag could live in the event class itself? Is it substantially faster to check this flag compared to `FileReadEvent.enabled()`?
>
> Its purpose is to avoid loading the FileReadEvent class. When the class is loaded, JFR will add fields and in some circumstances do other things. I don't think the cost is high, but it may add up if the number of events increases. Most Java applications don't run with JFR enabled, so this is to prevent them from seeing a negative impact.
> 
> I can update the text.

Hm, I think this setup requires more discussion. The approach we had settled on was that at the call sites in the libraries, something like the following was done:

    public R operation(...) {
        if (SomeEvent.enabled()) {
            // perform operation0 with tracing
            // emit event if SomeEvent.shouldCommit(...) is true
        } else {
            return operation0(...); // perform operation without tracing
        }
    }

    private R operation0(...) { /* do the actual work */ }

Now it looks like there's this additional flag `jfrTracing` that's set reflectively, and this flag is checked in a new layer of intermediate method calls:

    public R operation(...) {
        if (jfrTracing) {
            return traceOperation0(...);
        } else {
            return operation0(...);
        }
    }

    private R traceOperation0(...) {
        // stuff moved from public operation(...) above
    }

That is, the former body of the public `operation(...)` method is moved into the new `traceOperation0(...)` method.

I understand this is intended to help optimize startup time, but it adds clutter at each call site, and I'm wondering if it actually helps anything. The first time the application calls the `operation()` method, it's going to load a bunch of classes; the loading of this additional class is amortized over the loading and initialization of all the other classes in this area of the library. In addition, in the non-JFR case, the `enabled()` method implementation is simply `return false;` which can be inlined and which facilitiates dead code elimination.

With `jfrTracing` added to the mix, it causes a load from a non-final boolean field that needs to be checked repeatedly. Maybe the JIT can optimize for the common case, but there's possibly an expense that needs to be paid here.

At some point we should measure startup overhead for each case. I guess this can occur before or after this PR is integrated, depending on the urgency of things, but we should keep an eye on this issue.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19129#discussion_r1596129912

From duke at openjdk.org  Fri May 10 00:48:08 2024
From: duke at openjdk.org (duke)
Date: Fri, 10 May 2024 00:48:08 GMT
Subject: Withdrawn: 8325576: java/lang/ProcessHandle/InfoTest.java fails on
 systems with coreutils with --enable-single-binary
In-Reply-To: <AlklRqIwub9HSpD-GCYtj-DjpgVBqm3T0hg1P61zM-w=.871103d5-7753-42c7-a1d6-e2698a5d0731@github.com>
References: <AlklRqIwub9HSpD-GCYtj-DjpgVBqm3T0hg1P61zM-w=.871103d5-7753-42c7-a1d6-e2698a5d0731@github.com>
Message-ID: <2y_l9UPVdKjJ5WAPYV-ttPooRzLZH0Ue4upmLS4OFq4=.5c8fdd6d-9b7d-4e88-8732-ce227d1ba856@github.com>

On Fri, 9 Feb 2024 23:40:00 GMT, Dan Lutker <dlutker at openjdk.org> wrote:

> Ran the test on AmazonLinux 2 which has multiple binaries from coreutils package and no coreutils executable as well as AmazonLinux 2023 that uses `--enable-single-binary`

This pull request has been closed without being integrated.

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

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

From liach at openjdk.org  Fri May 10 00:50:13 2024
From: liach at openjdk.org (Chen Liang)
Date: Fri, 10 May 2024 00:50:13 GMT
Subject: RFR: 8327499: MethodHandleStatics.traceLambdaForm includes methods
 that cannot be generated
Message-ID: <twyi1CnAbWs33Rd0KieD7bbXYRVL6lQgfZ4HqvAVrCQ=.003fcea0-799c-4ba7-a6a1-cf3d72c99cfb@github.com>

GenerateJLIClassesHelper has been making wrong assumptions about Invoker's LambdaForm method type parameters. Since they are distinct from those of Linkers, they are now tracked and generated separately. It seems that no proper invoker was ever generated before, except it happens that most invoker signatures can be taken as linker signature so we never detected it.

Requesting @iklam for a review; since I don't know how to deal with CDS, I have to relay to someone else to ensure this fixes the problem from the CDS side as well.

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

Commit messages:
 - No-arg case
 - Fix exception messages
 - Merge branch 'master' of https://github.com/openjdk/jdk into fix/generate-invoker
 - Fix invoker generation (invoker MH + called MH, 2 leading objs) and add test
 - Merge branch 'master' of https://github.com/openjdk/jdk into fix/generate-invoker
 - 8327499: MethodHandleStatics.traceLambdaForm includes methods that cannot be generated

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

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

From jai.forums2013 at gmail.com  Fri May 10 01:01:23 2024
From: jai.forums2013 at gmail.com (Jaikiran Pai)
Date: Fri, 10 May 2024 06:31:23 +0530
Subject: Status of ZIP64 InputStream bug JDK-8298530?
In-Reply-To: <CANSoFxtKc=w9zy5TUFJDWpX7FhEVmzVVj1w9yZvV17F2ZUJbKA@mail.gmail.com>
References: <20240509174013.A459D6604A7@dd33810.kasserver.com>
 <CANSoFxtKc=w9zy5TUFJDWpX7FhEVmzVVj1w9yZvV17F2ZUJbKA@mail.gmail.com>
Message-ID: <0224b528-9167-40c9-968d-e2c688769e44@gmail.com>

I think this might have been addressed in mainline through 
https://bugs.openjdk.org/browse/JDK-8303866

-Jaikiran

On 09/05/24 11:39 pm, Archie Cobbs wrote:
> On Thu, May 9, 2024 at 12:43?PM Bernd Eckenfels 
> <ecki at zusammenkunft.net> wrote:
>
>     But this one here is still open:
>
>     * [JDK-8298530] ZipInputStream.readEnd fails for certain ZIP64
>     archives with small files - Java Bug System (openjdk.org)
>     <https://bugs.openjdk.org/browse/JDK-8298530>
>
> FWIW when I run the test case in that bug on the latest JDK 23 
> (jdk-23+21-110-g0a4eeeaa3c6), it does not report any exception.
>
> So this bug may have gotten fixed by recent changes and just needs to 
> be closed... ?
>
> -Archie
>
> -- 
> Archie L. Cobbs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240510/d639dd1c/attachment.htm>

From jwaters at openjdk.org  Fri May 10 01:04:04 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Fri, 10 May 2024 01:04:04 GMT
Subject: RFR: 8331907: BigInteger and BigDecimal should use optimized
 division
In-Reply-To: <-U6_9J-If3E3P3j4y7kt2yTCdNLvKkTSPrK0FxhNM80=.07321109-402b-4d28-9788-ddd52f42467d@github.com>
References: <-U6_9J-If3E3P3j4y7kt2yTCdNLvKkTSPrK0FxhNM80=.07321109-402b-4d28-9788-ddd52f42467d@github.com>
Message-ID: <voO9lj7Mvln3zopQGxO-q3t8iGQR8XNrk_K5xeX5ZoE=.98be2467-7b59-44d4-b7b9-742efb244802@github.com>

On Wed, 8 May 2024 08:19:54 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> Replace the custom unsigned divide / remainder functions with the compiler-optimized Long.divideUnsigned / remainderUnsigned.
> 
> No new tests. Existing tier1-3 tests continue to pass.
> 
> I added a new set of divide benchmarks. Results in thread.
> 
> I also removed the BigDecimal.toString benchmarks. They no longer serve their purpose - toString caches the returned value, so we were only benchmarking the cache access time.

src/java.base/share/classes/java/math/BigDecimal.java line 5683:

> 5681:         tmp = (dividendHi << shift) | (dividendLo >>> 64 - shift);
> 5682:         long u2 = tmp & LONG_MASK;
> 5683:         long q1, r_tmp;

Nit: There doesn't seem to be a reason for splitting the q1 and r_tmp declarations from their assignments, why not the following instead? (Also applies to the cases below)

long q1 = Long.divideUnsigned(tmp, v1);
long r_tmp = Long.remainderUnsigned(tmp, v1);

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19134#discussion_r1596137061

From jwaters at openjdk.org  Fri May 10 01:04:04 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Fri, 10 May 2024 01:04:04 GMT
Subject: RFR: 8330988: Implementation of 8288293: Windows/gcc Port for
 hsdis
In-Reply-To: <usSjNoHaMLDK2yN1CVz7X91uSIbpQslnD0hBtTFtnsw=.e7b4dede-07bf-41af-bef1-02672ef4758d@github.com>
References: <bXwOUFPBZUWDmidfDnVJLBKG4HkeS585IJqAOK8W1ys=.211183fe-b18e-498d-a557-6e6c4dfac27c@github.com>
 <usSjNoHaMLDK2yN1CVz7X91uSIbpQslnD0hBtTFtnsw=.e7b4dede-07bf-41af-bef1-02672ef4758d@github.com>
Message-ID: <9cOTNRj5EgyWRkI0hRuNjxym6vY29_GzTJdh4f-JstI=.4c216b65-b596-41f1-9ec1-3720ddca5577@github.com>

On Wed, 24 Apr 2024 09:15:21 GMT, Magnus Ihse Bursie <ihse 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.

@magicus?

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

PR Comment: https://git.openjdk.org/jdk/pull/18915#issuecomment-2103667760

From liach at openjdk.org  Fri May 10 01:27:03 2024
From: liach at openjdk.org (Chen Liang)
Date: Fri, 10 May 2024 01:27:03 GMT
Subject: RFR: 8328821: Map.of().entrySet() mutators should throw
 UnsupportedOperationException
In-Reply-To: <np86XgOjE1gYESY--2_OXTPIvO1mvmJbD3UH-lIn9TY=.c4a288f1-0469-4cc6-a076-58bab04d24ad@github.com>
References: <np86XgOjE1gYESY--2_OXTPIvO1mvmJbD3UH-lIn9TY=.c4a288f1-0469-4cc6-a076-58bab04d24ad@github.com>
Message-ID: <T6SbSiN0o6V_gLR_4nCdDZa0ti55OWFqcKAfn1zWiGw=.ff1c750a-3b25-4336-b6c1-20db983a1708@github.com>

On Wed, 27 Mar 2024 17:36:28 GMT, Liam Miller-Cushon <cushon at openjdk.org> wrote:

> This change overrides mutator methods in the implementation returned by `Map.of().entrySet()` to throw `UnsupportedOperationException`.

@stuart-marks Can you take a look at this?

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

PR Comment: https://git.openjdk.org/jdk/pull/18522#issuecomment-2103684505

From duke at openjdk.org  Fri May 10 01:28:02 2024
From: duke at openjdk.org (xiaotaonan)
Date: Fri, 10 May 2024 01:28:02 GMT
Subject: RFR: 8331879: Clean up non-standard use of /// comments in
 `java.base`
In-Reply-To: <JKCovwpov4A3Uddzf6N0AnZSb3Znv-7MEfMGec6IhR4=.93e4ad8e-344b-4890-8f25-c2752287024c@github.com>
References: <JKCovwpov4A3Uddzf6N0AnZSb3Znv-7MEfMGec6IhR4=.93e4ad8e-344b-4890-8f25-c2752287024c@github.com>
Message-ID: <Lpd-uBwG8xZoG9WbPKfUawFKRfKrA1RfQ7XzKrY4qHQ=.e23104ab-d47a-4a55-b2bd-fb7b94e9a10f@github.com>

On Thu, 9 May 2024 02:09:50 GMT, xiaotaonan <duke at openjdk.org> wrote:

> Clean up non-standard use of /// comments in `java.base`

@mdinacci @hns  @landonf

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

PR Comment: https://git.openjdk.org/jdk/pull/19151#issuecomment-2103685769

From iklam at openjdk.org  Fri May 10 04:26:02 2024
From: iklam at openjdk.org (Ioi Lam)
Date: Fri, 10 May 2024 04:26:02 GMT
Subject: RFR: 8327499: MethodHandleStatics.traceLambdaForm includes methods
 that cannot be generated
In-Reply-To: <twyi1CnAbWs33Rd0KieD7bbXYRVL6lQgfZ4HqvAVrCQ=.003fcea0-799c-4ba7-a6a1-cf3d72c99cfb@github.com>
References: <twyi1CnAbWs33Rd0KieD7bbXYRVL6lQgfZ4HqvAVrCQ=.003fcea0-799c-4ba7-a6a1-cf3d72c99cfb@github.com>
Message-ID: <qj6hbn-JOC6Ni9xBuQVoIgGGLYpEU0pimYodU-cxuW8=.aa0fd0ea-6c89-4452-a77b-4860c804eac2@github.com>

On Fri, 10 May 2024 00:45:31 GMT, Chen Liang <liach at openjdk.org> wrote:

> GenerateJLIClassesHelper has been making wrong assumptions about Invoker's LambdaForm method type parameters. Since they are distinct from those of Linkers, they are now tracked and generated separately. It seems that no proper invoker was ever generated before, except it happens that most invoker signatures can be taken as linker signature so we never detected it.
> 
> Requesting @iklam for a review; since I don't know how to deal with CDS, I have to relay to someone else to ensure this fixes the problem from the CDS side as well.

pinging @cl4es 

@liach, could you add a jtreg test case? I think you can use https://github.com/openjdk/jdk/blob/master/test/hotspot/jtreg/runtime/cds/appcds/dynamicArchive/CDSLambdaInvoker.java

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

PR Comment: https://git.openjdk.org/jdk/pull/19164#issuecomment-2103835712

From smarks at openjdk.org  Fri May 10 04:54:04 2024
From: smarks at openjdk.org (Stuart Marks)
Date: Fri, 10 May 2024 04:54:04 GMT
Subject: RFR: 8305457: Implement java.io.IO [v7]
In-Reply-To: <554HmRIAD_1Hf8Hbq6_YRH9iTf8fBk_OZ1XrlmSsQAU=.90c8b148-029a-429f-9037-179d9d30f6ad@github.com>
References: <w2msiw_qaMEIJS3s9D4bg8pFbz5WIF0KdP6Mm-XFjLI=.85b2020b-8c46-4bac-8a69-4975b068f2ff@github.com>
 <554HmRIAD_1Hf8Hbq6_YRH9iTf8fBk_OZ1XrlmSsQAU=.90c8b148-029a-429f-9037-179d9d30f6ad@github.com>
Message-ID: <CNMJuNb-hHUTZbam6PVMXQH-eGKII4k_LohM7GhSg7k=.f9d687a6-1da1-46c3-a226-4e29665f9617@github.com>

On Thu, 9 May 2024 18:27:08 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Please review this PR which introduces the `java.io.IO` top-level class and three methods to `java.io.Console` for [Implicitly Declared Classes and Instance Main Methods (Third Preview)].
>> 
>> This PR has been obtained as `git merge --squash` of a now obsolete [draft PR].
>> 
>> [Implicitly Declared Classes and Instance Main Methods (Third Preview)]: https://bugs.openjdk.org/browse/JDK-8323335
>> [draft PR]: https://github.com/openjdk/jdk/pull/18921
>
> Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix System.console().readln(null) in jshell
>   
>   Without it, jshell hangs on me. Will think of a test.

Marked as reviewed by smarks (Reviewer).

Latest changes look good.

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

PR Review: https://git.openjdk.org/jdk/pull/19112#pullrequestreview-2049241670
PR Comment: https://git.openjdk.org/jdk/pull/19112#issuecomment-2103859341

From liach at openjdk.org  Fri May 10 04:55:21 2024
From: liach at openjdk.org (Chen Liang)
Date: Fri, 10 May 2024 04:55:21 GMT
Subject: RFR: 8327499: MethodHandleStatics.traceLambdaForm includes methods
 that cannot be generated [v2]
In-Reply-To: <twyi1CnAbWs33Rd0KieD7bbXYRVL6lQgfZ4HqvAVrCQ=.003fcea0-799c-4ba7-a6a1-cf3d72c99cfb@github.com>
References: <twyi1CnAbWs33Rd0KieD7bbXYRVL6lQgfZ4HqvAVrCQ=.003fcea0-799c-4ba7-a6a1-cf3d72c99cfb@github.com>
Message-ID: <9_0CEL0npofl2XsTW6q4wLhYYSHm6kH0cOqsFBGskSg=.371cc7a8-12db-4ca3-864c-1ae0efd6fc54@github.com>

> GenerateJLIClassesHelper has been making wrong assumptions about Invoker's LambdaForm method type parameters. Since they are distinct from those of Linkers, they are now tracked and generated separately. It seems that no proper invoker was ever generated before, except it happens that most invoker signatures can be taken as linker signature so we never detected it.
> 
> Requesting @iklam for a review; since I don't know how to deal with CDS, I have to relay to someone else to ensure this fixes the problem from the CDS side as well.

Chen Liang has updated the pull request incrementally with one additional commit since the last revision:

  Add CDS test case to ensure LF resolution success

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/19164/files
  - new: https://git.openjdk.org/jdk/pull/19164/files/b1787fc3..fc393dbc

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

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

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

From liach at openjdk.org  Fri May 10 04:55:21 2024
From: liach at openjdk.org (Chen Liang)
Date: Fri, 10 May 2024 04:55:21 GMT
Subject: RFR: 8327499: MethodHandleStatics.traceLambdaForm includes methods
 that cannot be generated
In-Reply-To: <qj6hbn-JOC6Ni9xBuQVoIgGGLYpEU0pimYodU-cxuW8=.aa0fd0ea-6c89-4452-a77b-4860c804eac2@github.com>
References: <twyi1CnAbWs33Rd0KieD7bbXYRVL6lQgfZ4HqvAVrCQ=.003fcea0-799c-4ba7-a6a1-cf3d72c99cfb@github.com>
 <qj6hbn-JOC6Ni9xBuQVoIgGGLYpEU0pimYodU-cxuW8=.aa0fd0ea-6c89-4452-a77b-4860c804eac2@github.com>
Message-ID: <euMltQMjGVlKvvw2sgWZOECTRsB-WVAyrpGo4wT9eS4=.a16fcdb2-5b5b-43d6-8417-f82d4a5c7fdd@github.com>

On Fri, 10 May 2024 04:23:35 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> GenerateJLIClassesHelper has been making wrong assumptions about Invoker's LambdaForm method type parameters. Since they are distinct from those of Linkers, they are now tracked and generated separately. It seems that no proper invoker was ever generated before, except it happens that most invoker signatures can be taken as linker signature so we never detected it.
>> 
>> Requesting @iklam for a review; since I don't know how to deal with CDS, I have to relay to someone else to ensure this fixes the problem from the CDS side as well.
>
> pinging @cl4es 
> 
> @liach, could you add a jtreg test case? I think you can use https://github.com/openjdk/jdk/blob/master/test/hotspot/jtreg/runtime/cds/appcds/dynamicArchive/CDSLambdaInvoker.java

@iklam I have expanded the given case and it passes on my device locally. Since CDS doesn't have an easy way to find out the methods archived in a class, I resorted to enabling invoke's logging and checking the resolution output instead. Does this approach look good?

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

PR Comment: https://git.openjdk.org/jdk/pull/19164#issuecomment-2103859269

From pminborg at openjdk.org  Fri May 10 07:26:04 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Fri, 10 May 2024 07:26:04 GMT
Subject: RFR: 8305457: Implement java.io.IO [v7]
In-Reply-To: <554HmRIAD_1Hf8Hbq6_YRH9iTf8fBk_OZ1XrlmSsQAU=.90c8b148-029a-429f-9037-179d9d30f6ad@github.com>
References: <w2msiw_qaMEIJS3s9D4bg8pFbz5WIF0KdP6Mm-XFjLI=.85b2020b-8c46-4bac-8a69-4975b068f2ff@github.com>
 <554HmRIAD_1Hf8Hbq6_YRH9iTf8fBk_OZ1XrlmSsQAU=.90c8b148-029a-429f-9037-179d9d30f6ad@github.com>
Message-ID: <h8rrzx8ViVaY0Ciu1J6ZLVsV1Irn2i1Ek7TZ2R66GWI=.e1583e64-a7ae-411b-9fb2-a976287cc355@github.com>

On Thu, 9 May 2024 18:27:08 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Please review this PR which introduces the `java.io.IO` top-level class and three methods to `java.io.Console` for [Implicitly Declared Classes and Instance Main Methods (Third Preview)].
>> 
>> This PR has been obtained as `git merge --squash` of a now obsolete [draft PR].
>> 
>> [Implicitly Declared Classes and Instance Main Methods (Third Preview)]: https://bugs.openjdk.org/browse/JDK-8323335
>> [draft PR]: https://github.com/openjdk/jdk/pull/18921
>
> Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix System.console().readln(null) in jshell
>   
>   Without it, jshell hangs on me. Will think of a test.

src/java.base/share/classes/java/io/IO.java line 47:

> 45: 
> 46:     private IO() {
> 47:         throw new Error("no instances");

Is this necessary?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19112#discussion_r1596370177

From jpai at openjdk.org  Fri May 10 07:35:06 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 10 May 2024 07:35:06 GMT
Subject: RFR: 8305457: Implement java.io.IO [v4]
In-Reply-To: <wqdl7WD8hTx1IlgxXylCd053e_MrKw0zrHKC2fwUusM=.b5072cb6-85b7-46c8-9ebd-119a63ec029b@github.com>
References: <w2msiw_qaMEIJS3s9D4bg8pFbz5WIF0KdP6Mm-XFjLI=.85b2020b-8c46-4bac-8a69-4975b068f2ff@github.com>
 <wqdl7WD8hTx1IlgxXylCd053e_MrKw0zrHKC2fwUusM=.b5072cb6-85b7-46c8-9ebd-119a63ec029b@github.com>
Message-ID: <u1adSAVgMNh12OxG22cCTxPZiKjpKu6JMkXVEk-Nc0g=.e16a4811-11bb-4e95-8886-e6ab1a4ff13b@github.com>

On Wed, 8 May 2024 18:43:41 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Please review this PR which introduces the `java.io.IO` top-level class and three methods to `java.io.Console` for [Implicitly Declared Classes and Instance Main Methods (Third Preview)].
>> 
>> This PR has been obtained as `git merge --squash` of a now obsolete [draft PR].
>> 
>> [Implicitly Declared Classes and Instance Main Methods (Third Preview)]: https://bugs.openjdk.org/browse/JDK-8323335
>> [draft PR]: https://github.com/openjdk/jdk/pull/18921
>
> Pavel Rappo has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Specify charset of java.io.IO
>  - Use system-dependent line separator for Console.println

src/java.base/share/classes/java/io/IO.java line 38:

> 36:  * had been called on that console.
> 37:  *
> 38:  * <p> Output from methods in this class uses the character set of the system

Hello Pavel, given that `java.io.IO` exposes both input and output methods and the Charset will be used by both input and output, I think we might have to reword this sentence to make a note of input too.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19112#discussion_r1596380347

From pminborg at openjdk.org  Fri May 10 07:35:06 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Fri, 10 May 2024 07:35:06 GMT
Subject: RFR: 8305457: Implement java.io.IO [v7]
In-Reply-To: <mmUl8dkLjrfAs1utQ0e5zn8Knz2ZV3UzM8x4KxB4wtc=.c95890ba-267d-4c0f-8351-4d78cee2f024@github.com>
References: <w2msiw_qaMEIJS3s9D4bg8pFbz5WIF0KdP6Mm-XFjLI=.85b2020b-8c46-4bac-8a69-4975b068f2ff@github.com>
 <-WNQ0gigYgjDdjH55OM-8aWzcDeHcA5ORdsK8MpSvj8=.8fe3c2ee-f30b-4dbd-a9a6-b0c8a4f0dbbc@github.com>
 <VeykkrIb_1RvBlQ3NYZJIvig16qeKByY6hcRtpyeruw=.833c60ab-f4a7-4161-a071-ef9ba3b57657@github.com>
 <mmUl8dkLjrfAs1utQ0e5zn8Knz2ZV3UzM8x4KxB4wtc=.c95890ba-267d-4c0f-8351-4d78cee2f024@github.com>
Message-ID: <k1XL9rhR00IEZIYFMOKXZYhLi0wh5yXLlRGBS9nppTo=.5d6fc4ee-f0cd-4a60-9825-2eefb17eabaf@github.com>

On Tue, 7 May 2024 20:23:11 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>>> Should this be final?
>> 
>> With only the private constructor, it doesn't matter too much in practice, but an explicit `final` would be good documentation if that is the intent.
>
> If the sole constructor of a class is private, not only does it preclude the class from being instantiated, but it also precludes the class from being extended. Mind you, even with the sole private constructor, both instantiation and extension are still possible from inside the class or its nested classes. As long as we don't leak such instances to API clients, they won't seem to be able to observe any difference between "the private constructor" and "the private constructor of a final class".
> 
> I think that just having that constructor private but the class "non-final" makes bigger bang for the buck. We can defer the decision to make the class final.
> 
> If this helps, here are a few well-known similar classes:
> 
>   - java.util.Collections
>   - java.util.concurrent.Executors

Although true (and also described in Item 4 in "Effective Java" 3rd ed by JB) I think it is better to also signal the intent by marking the class as `final`. See for example Arrays that we updated some time ago.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19112#discussion_r1596377720

From vklang at openjdk.org  Fri May 10 07:38:03 2024
From: vklang at openjdk.org (Viktor Klang)
Date: Fri, 10 May 2024 07:38:03 GMT
Subject: RFR: 8322732: ForkJoinPool may underutilize cores in async mode
In-Reply-To: <xRyDMAsSZ7obqpr3Aoc5qrHqILeJMxFVCeiRdctMI3U=.d5d3cd56-32eb-4431-ac01-081822fc86c6@github.com>
References: <xRyDMAsSZ7obqpr3Aoc5qrHqILeJMxFVCeiRdctMI3U=.d5d3cd56-32eb-4431-ac01-081822fc86c6@github.com>
Message-ID: <v-lLqE7QmMb0Mq6DW18Q1igG3WMHNZHLqKVO6AHigWU=.c8bf86d2-4c95-409d-8eac-a0ce7d660d9a@github.com>

On Tue, 7 May 2024 22:50:18 GMT, Doug Lea <dl at openjdk.org> wrote:

> This set of changes address causes of poor utilization with small numbers of cores due to overly aggressive contention avoidance. A number of further adjustments were needed to still avoid most contention effects in deployments with large numbers of cores

src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 978:

> 976:      * of two, at least 2. See above.
> 977:      */
> 978:     static final int INITIAL_QUEUE_CAPACITY = 1 << 7;

@DougLea Interesting change?what impact did you notice when doubling this?

src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 994:

> 992:     static final long SHUTDOWN        = 1L <<  1;   // terminate when quiescent
> 993:     static final long TERMINATED      = 1L <<  2;   // only set if STOP also set
> 994:     static final long RS_LOCK         = 1L <<  3;   // lowest seqlock bit

@DougLea I presume making these longs was to enable the int-field padding?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19131#discussion_r1596382962
PR Review Comment: https://git.openjdk.org/jdk/pull/19131#discussion_r1596383529

From jpai at openjdk.org  Fri May 10 07:48:04 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 10 May 2024 07:48:04 GMT
Subject: RFR: 8305457: Implement java.io.IO [v7]
In-Reply-To: <554HmRIAD_1Hf8Hbq6_YRH9iTf8fBk_OZ1XrlmSsQAU=.90c8b148-029a-429f-9037-179d9d30f6ad@github.com>
References: <w2msiw_qaMEIJS3s9D4bg8pFbz5WIF0KdP6Mm-XFjLI=.85b2020b-8c46-4bac-8a69-4975b068f2ff@github.com>
 <554HmRIAD_1Hf8Hbq6_YRH9iTf8fBk_OZ1XrlmSsQAU=.90c8b148-029a-429f-9037-179d9d30f6ad@github.com>
Message-ID: <qDUNtEpZzW7nx2tzrSvzxei_AbLxXwyKFGEMZk5OpxI=.1fcd778a-1d52-40e0-944b-8d1a26bd7c8e@github.com>

On Thu, 9 May 2024 18:27:08 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Please review this PR which introduces the `java.io.IO` top-level class and three methods to `java.io.Console` for [Implicitly Declared Classes and Instance Main Methods (Third Preview)].
>> 
>> This PR has been obtained as `git merge --squash` of a now obsolete [draft PR].
>> 
>> [Implicitly Declared Classes and Instance Main Methods (Third Preview)]: https://bugs.openjdk.org/browse/JDK-8323335
>> [draft PR]: https://github.com/openjdk/jdk/pull/18921
>
> Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix System.console().readln(null) in jshell
>   
>   Without it, jshell hangs on me. Will think of a test.

src/java.base/share/classes/jdk/internal/io/JdkConsoleImpl.java line 61:

> 59:     @Override
> 60:     public JdkConsole println(Object obj) {
> 61:         pw.println(obj);

Are these `println(...)` and `print(...)` methods intentionally not using a `writeLock` unlike the `readln(...)` and `readLine(...)` methods which do use (read and write) locks?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19112#discussion_r1596392802

From asotona at openjdk.org  Fri May 10 07:58:06 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Fri, 10 May 2024 07:58:06 GMT
Subject: RFR: 8331744: java.lang.classfile.TypeKind improvements [v5]
In-Reply-To: <jXeaNMrczPVr7MhMJRdA8VtoGT4J8F8jJi2CL3fJdsg=.82f94657-7cd4-42f6-a337-8adc9890e92e@github.com>
References: <_x31CU5mODg3NGaRGzI5HdNdcjsKmqWb1TA7KZnZcFg=.43ce5ba3-71e7-42e5-a531-c3b609d0aafb@github.com>
 <jXeaNMrczPVr7MhMJRdA8VtoGT4J8F8jJi2CL3fJdsg=.82f94657-7cd4-42f6-a337-8adc9890e92e@github.com>
Message-ID: <qWFaS_Ii9toCLsbqx59jjGICwQZPIflv6XJ45b44Xi8=.5623cbe3-4bc4-4829-8e5b-fe63c922fd15@github.com>

On Thu, 9 May 2024 21:15:31 GMT, Chen Liang <liach at openjdk.org> wrote:

>> A peek into TypeKind during the research for #19105 reveals that TypeKind has a few issues:
>> 1. Name mismatch for `newarraycode` and `fromNewArrayCode`: Renamed both to use "newarray code"
>> 2. `fromDescriptor` can throw IOOBE if the input string is empty: changed to throw IAE and added tests.
>> 3. `from(Class)` can be slow due to descriptor computation: added benchmark, will share result in next comment (as it may change with code changes).
>> 
>> The first 2 changes involves API changes, and a CSR has been created. Requesting @asotona for a review.
>
> Chen Liang has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Restore fixed seed
>  - Revert "Hash table, use fixed random seed"
>    
>    This reverts commit 9af30c65d2c7be3535e4483e278151bc4473d63c.

Looks good to me, thanks.

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

Marked as reviewed by asotona (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19109#pullrequestreview-2049496655

From redestad at openjdk.org  Fri May 10 08:05:09 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Fri, 10 May 2024 08:05:09 GMT
Subject: RFR: 8331744: java.lang.classfile.TypeKind improvements [v5]
In-Reply-To: <jXeaNMrczPVr7MhMJRdA8VtoGT4J8F8jJi2CL3fJdsg=.82f94657-7cd4-42f6-a337-8adc9890e92e@github.com>
References: <_x31CU5mODg3NGaRGzI5HdNdcjsKmqWb1TA7KZnZcFg=.43ce5ba3-71e7-42e5-a531-c3b609d0aafb@github.com>
 <jXeaNMrczPVr7MhMJRdA8VtoGT4J8F8jJi2CL3fJdsg=.82f94657-7cd4-42f6-a337-8adc9890e92e@github.com>
Message-ID: <aYGERKAApkxGPMJvU-dMjy_0cfD4yqdnGRz87SfgkVg=.b4aa84db-b7b5-4ff6-a944-f008ac51c088@github.com>

On Thu, 9 May 2024 21:15:31 GMT, Chen Liang <liach at openjdk.org> wrote:

>> A peek into TypeKind during the research for #19105 reveals that TypeKind has a few issues:
>> 1. Name mismatch for `newarraycode` and `fromNewArrayCode`: Renamed both to use "newarray code"
>> 2. `fromDescriptor` can throw IOOBE if the input string is empty: changed to throw IAE and added tests.
>> 3. `from(Class)` can be slow due to descriptor computation: added benchmark, will share result in next comment (as it may change with code changes).
>> 
>> The first 2 changes involves API changes, and a CSR has been created. Requesting @asotona for a review.
>
> Chen Liang has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Restore fixed seed
>  - Revert "Hash table, use fixed random seed"
>    
>    This reverts commit 9af30c65d2c7be3535e4483e278151bc4473d63c.

Marked as reviewed by redestad (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/19109#pullrequestreview-2049509533

From vklang at openjdk.org  Fri May 10 08:07:16 2024
From: vklang at openjdk.org (Viktor Klang)
Date: Fri, 10 May 2024 08:07:16 GMT
Subject: RFR: 8322732: ForkJoinPool may underutilize cores in async mode
In-Reply-To: <xRyDMAsSZ7obqpr3Aoc5qrHqILeJMxFVCeiRdctMI3U=.d5d3cd56-32eb-4431-ac01-081822fc86c6@github.com>
References: <xRyDMAsSZ7obqpr3Aoc5qrHqILeJMxFVCeiRdctMI3U=.d5d3cd56-32eb-4431-ac01-081822fc86c6@github.com>
Message-ID: <iUBNSU8KuzwD687df3qSjcpeFBGwDAU90om5Sts-fMk=.9112e43e-aae0-4b08-b7d2-59a756903491@github.com>

On Tue, 7 May 2024 22:50:18 GMT, Doug Lea <dl at openjdk.org> wrote:

> This set of changes address causes of poor utilization with small numbers of cores due to overly aggressive contention avoidance. A number of further adjustments were needed to still avoid most contention effects in deployments with large numbers of cores

src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 1405:

> 1403:                     U.loadFence();
> 1404:                     if (base != b)
> 1405:                         ;                              // inconsistent

@DougLea This seems like it could be a `continue;`, which might be easier to reason about?

src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 1412:

> 1410:                         if (stalled)
> 1411:                             Thread.onSpinWait();
> 1412:                         stalled = true;

@DougLea Performance-wise, does it make any difference to make the write to `stalled` in an `else-branch` to avoid writing it every time beyond the initial?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19131#discussion_r1596410561
PR Review Comment: https://git.openjdk.org/jdk/pull/19131#discussion_r1596413050

From vklang at openjdk.org  Fri May 10 08:11:27 2024
From: vklang at openjdk.org (Viktor Klang)
Date: Fri, 10 May 2024 08:11:27 GMT
Subject: RFR: 8322732: ForkJoinPool may underutilize cores in async mode
In-Reply-To: <xRyDMAsSZ7obqpr3Aoc5qrHqILeJMxFVCeiRdctMI3U=.d5d3cd56-32eb-4431-ac01-081822fc86c6@github.com>
References: <xRyDMAsSZ7obqpr3Aoc5qrHqILeJMxFVCeiRdctMI3U=.d5d3cd56-32eb-4431-ac01-081822fc86c6@github.com>
Message-ID: <bJZGmVa7J6QiZvPU2hnDUaEX2hlphLj0QjQE6-2fu50=.b5e2c301-3e1c-42b8-846f-35291d696bd9@github.com>

On Tue, 7 May 2024 22:50:18 GMT, Doug Lea <dl at openjdk.org> wrote:

> This set of changes address causes of poor utilization with small numbers of cores due to overly aggressive contention avoidance. A number of further adjustments were needed to still avoid most contention effects in deployments with large numbers of cores

src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 1432:

> 1430:         final void topLevelExec(ForkJoinTask<?> task, WorkQueue src,
> 1431:                                 int srcBase, int cfg) {
> 1432:             if (task != null && src != null) {

@DougLea Is this ever invoked with a null-task and a null-queue? ?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19131#discussion_r1596417799

From vklang at openjdk.org  Fri May 10 08:14:07 2024
From: vklang at openjdk.org (Viktor Klang)
Date: Fri, 10 May 2024 08:14:07 GMT
Subject: RFR: 8322732: ForkJoinPool may underutilize cores in async mode
In-Reply-To: <xRyDMAsSZ7obqpr3Aoc5qrHqILeJMxFVCeiRdctMI3U=.d5d3cd56-32eb-4431-ac01-081822fc86c6@github.com>
References: <xRyDMAsSZ7obqpr3Aoc5qrHqILeJMxFVCeiRdctMI3U=.d5d3cd56-32eb-4431-ac01-081822fc86c6@github.com>
Message-ID: <myyMGgboonDNVFi2ETHwJEJPtEVW_dFlP49cDZkRn-I=.bf4e5e5f-c49c-4fc1-8230-433cafab2be6@github.com>

On Tue, 7 May 2024 22:50:18 GMT, Doug Lea <dl at openjdk.org> wrote:

> This set of changes address causes of poor utilization with small numbers of cores due to overly aggressive contention avoidance. A number of further adjustments were needed to still avoid most contention effects in deployments with large numbers of cores

src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 1830:

> 1828:             phase = w.phase;
> 1829:             if ((src = w.source) != DROPPED) {
> 1830:                 w.source = DROPPED;        // else already dropped

@DougLea Would there be any gain in atomically swapping out `w.source` to `DROPPED`?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19131#discussion_r1596425162

From vklang at openjdk.org  Fri May 10 08:19:24 2024
From: vklang at openjdk.org (Viktor Klang)
Date: Fri, 10 May 2024 08:19:24 GMT
Subject: RFR: 8322732: ForkJoinPool may underutilize cores in async mode
In-Reply-To: <xRyDMAsSZ7obqpr3Aoc5qrHqILeJMxFVCeiRdctMI3U=.d5d3cd56-32eb-4431-ac01-081822fc86c6@github.com>
References: <xRyDMAsSZ7obqpr3Aoc5qrHqILeJMxFVCeiRdctMI3U=.d5d3cd56-32eb-4431-ac01-081822fc86c6@github.com>
Message-ID: <1Rh8n2h5T32Nky0-jfnk6iSKJJb-D_jBSANKYQHtIKg=.c72e7c53-36b4-4aeb-a2fe-31696472d60f@github.com>

On Tue, 7 May 2024 22:50:18 GMT, Doug Lea <dl at openjdk.org> wrote:

> This set of changes address causes of poor utilization with small numbers of cores due to overly aggressive contention avoidance. A number of further adjustments were needed to still avoid most contention effects in deployments with large numbers of cores

src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 1883:

> 1881:             if (qs == null)
> 1882:                 break;
> 1883:             if (qs.length <= i)

@DougLea Any particular reason why these are not or-branches of a single if?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19131#discussion_r1596429964

From redestad at openjdk.org  Fri May 10 08:25:16 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Fri, 10 May 2024 08:25:16 GMT
Subject: RFR: 8331932: Startup regressions in 23-b13 [v5]
In-Reply-To: <80F_O6CmUuhmcSwCdIGMQbw9zo_GSmyn9B99mWgflrk=.313222e4-b800-428e-88ea-a821684c3e9e@github.com>
References: <LgTAOs1QA0kgTbAfVQ_U2BcWAV7AHpcFXNE7eYB1BI8=.e77b81c1-73d4-4ff0-806f-eeda86d5cb16@github.com>
 <80F_O6CmUuhmcSwCdIGMQbw9zo_GSmyn9B99mWgflrk=.313222e4-b800-428e-88ea-a821684c3e9e@github.com>
Message-ID: <gCrpY3is309Tly8BVThkVZDPzPEkg3H42AHGbaSZhqE=.5ec118ae-e36f-46a1-a295-242867a4448f@github.com>

On Thu, 9 May 2024 13:34:16 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> A rather large startup regression was introduced in 23-b13 from [JDK-8309622](https://bugs.openjdk.org/browse/JDK-8309622). Some of that has been dealt with as enhancements such as [JDK-8330802](https://bugs.openjdk.org/browse/JDK-8330802), [JDK-8330595](https://bugs.openjdk.org/browse/JDK-8330595) and [JDK-8330681](https://bugs.openjdk.org/browse/JDK-8330681), which provide both point fixes and reduce initialization overhead of certain constructs more generally. The remaining issues stem from a set of lambdas added in code for `java.util.Locale` and `jdk.internal.util.BaseLocale` causing early bootstrapping of the lambda infrastructure and a bit of class generation.
>> 
>> While the remaining overheads are relatively small and borderline acceptable (< 2-3ms), I think it's still worth acting on them in this particular case since the amount of added bootstrapping overhead is dependent on which locale the system runs under, which complicates testing and comparisons due to relatively large differences in paths taken on different systems.
>
> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reuse ReferenceKeyMap.concurrentHashMapSupplier

Thanks for reviewing!

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

PR Comment: https://git.openjdk.org/jdk/pull/19140#issuecomment-2104166596

From redestad at openjdk.org  Fri May 10 08:25:17 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Fri, 10 May 2024 08:25:17 GMT
Subject: Integrated: 8331932: Startup regressions in 23-b13
In-Reply-To: <LgTAOs1QA0kgTbAfVQ_U2BcWAV7AHpcFXNE7eYB1BI8=.e77b81c1-73d4-4ff0-806f-eeda86d5cb16@github.com>
References: <LgTAOs1QA0kgTbAfVQ_U2BcWAV7AHpcFXNE7eYB1BI8=.e77b81c1-73d4-4ff0-806f-eeda86d5cb16@github.com>
Message-ID: <hKx26ctbiTiluJIt-l6vpvW-ZsJUhRFQ_TROYoVePkY=.45eca034-27ef-4963-84f3-38b08234b31c@github.com>

On Wed, 8 May 2024 14:53:05 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> A rather large startup regression was introduced in 23-b13 from [JDK-8309622](https://bugs.openjdk.org/browse/JDK-8309622). Some of that has been dealt with as enhancements such as [JDK-8330802](https://bugs.openjdk.org/browse/JDK-8330802), [JDK-8330595](https://bugs.openjdk.org/browse/JDK-8330595) and [JDK-8330681](https://bugs.openjdk.org/browse/JDK-8330681), which provide both point fixes and reduce initialization overhead of certain constructs more generally. The remaining issues stem from a set of lambdas added in code for `java.util.Locale` and `jdk.internal.util.BaseLocale` causing early bootstrapping of the lambda infrastructure and a bit of class generation.
> 
> While the remaining overheads are relatively small and borderline acceptable (< 2-3ms), I think it's still worth acting on them in this particular case since the amount of added bootstrapping overhead is dependent on which locale the system runs under, which complicates testing and comparisons due to relatively large differences in paths taken on different systems.

This pull request has now been integrated.

Changeset: d6541245
Author:    Claes Redestad <redestad at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/d65412450254992c05c851298323b6acd3b39bd3
Stats:     61 lines in 4 files changed: 45 ins; 5 del; 11 mod

8331932: Startup regressions in 23-b13

Reviewed-by: alanb, naoto, liach

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

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

From vklang at openjdk.org  Fri May 10 08:33:10 2024
From: vklang at openjdk.org (Viktor Klang)
Date: Fri, 10 May 2024 08:33:10 GMT
Subject: RFR: 8322732: ForkJoinPool may underutilize cores in async mode
In-Reply-To: <xRyDMAsSZ7obqpr3Aoc5qrHqILeJMxFVCeiRdctMI3U=.d5d3cd56-32eb-4431-ac01-081822fc86c6@github.com>
References: <xRyDMAsSZ7obqpr3Aoc5qrHqILeJMxFVCeiRdctMI3U=.d5d3cd56-32eb-4431-ac01-081822fc86c6@github.com>
Message-ID: <z0RoolyDKAWS8rkliT8nxELW7lH5dlhrtBI6GoStac8=.2b9e94d1-59fc-43ce-82f5-bdc40020cfba@github.com>

On Tue, 7 May 2024 22:50:18 GMT, Doug Lea <dl at openjdk.org> wrote:

> This set of changes address causes of poor utilization with small numbers of cores due to overly aggressive contention avoidance. A number of further adjustments were needed to still avoid most contention effects in deployments with large numbers of cores

src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 2167:

> 2165:             }
> 2166:         }
> 2167:         return stat;

@DougLea Since `stat` is a local, and is only written to once per branch it might make sense to just return from each of the branches?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19131#discussion_r1596448632

From stuefe at openjdk.org  Fri May 10 08:37:28 2024
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Fri, 10 May 2024 08:37:28 GMT
Subject: RFR: 8329581: Java launcher no longer prints a stack trace [v9]
In-Reply-To: <DjXIQXr_CK3q3-W506Ms-62DW1hlpgGRtrJ_Av7HJL0=.9cc03a10-456e-4c5c-a78d-2f8821f3dca8@github.com>
References: <Z0pDMIc_XvZhcZdeFsIQUlqI17q5ybj0BnQ9Kl3jwxg=.8f981c46-a8a3-4520-a6e3-79ee7fce0253@github.com>
 <krgANOmUJpt38cg16YhdXnUibxgX4shajEyWnMF79Hc=.e2dba0cc-8085-4efd-a300-d9c7f771510b@github.com>
 <OSB-RYHDOcS3rbr3_rsRmDPO-GFps7FXT_LD_2M2PHM=.2c4dc9d2-f40f-45e1-98f8-3c0aa2fb9c67@github.com>
 <DjXIQXr_CK3q3-W506Ms-62DW1hlpgGRtrJ_Av7HJL0=.9cc03a10-456e-4c5c-a78d-2f8821f3dca8@github.com>
Message-ID: <d5IpC374HVG9QeGrgg71vPRIpgwGWNsIc6ygMiIDJtI=.67ecb601-26fe-4dce-9208-7325fc6399a8@github.com>

On Thu, 9 May 2024 19:48:53 GMT, Sonia Zaldana Calles <szaldana at openjdk.org> wrote:

> > This may be food for another RFE, to keep this patch minimal. But a good solution, to me, would be like this:
> > 
> > * have the same logic for return codes (1 = error, 0 = success) to ease understanding
> > * have clearly named constants (e.g. "LAUNCHER_OK" 0, "LAUNCHER_ERR" = 1)
> > * have the LEAVE macro take the launcher return code as argument
> > * have all xxx_LEAVE macros pass in LAUNCHER_ERR to LEAVE
> > * call the final LEAVE with LAUNCHER_OK
> > * optionally, define something like "LEAVE_ERR" and "LEAVE_OK" that call LEAVE with either LAUNCHER_ERR or LAUNCHER_OK, for more concise coding.
> > 
> > For this patch, I think the return code logic is okay, but I would feel better if others double-checked.
> 
> @tstuefe Agreed, I can look into opening another issue to track this after we fix the regression.

Thank you. Please do. You can just copy-paste my rant into the bug description.

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

PR Comment: https://git.openjdk.org/jdk/pull/18786#issuecomment-2104186742

From stuefe at openjdk.org  Fri May 10 08:37:27 2024
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Fri, 10 May 2024 08:37:27 GMT
Subject: RFR: 8329581: Java launcher no longer prints a stack trace [v10]
In-Reply-To: <nFQS3JDegumTJOWSla6qGad04vc7PP7W3ZZ483XQuqs=.d28be017-00a0-44e0-9eee-bd70d56498e8@github.com>
References: <Z0pDMIc_XvZhcZdeFsIQUlqI17q5ybj0BnQ9Kl3jwxg=.8f981c46-a8a3-4520-a6e3-79ee7fce0253@github.com>
 <nFQS3JDegumTJOWSla6qGad04vc7PP7W3ZZ483XQuqs=.d28be017-00a0-44e0-9eee-bd70d56498e8@github.com>
Message-ID: <psbF1k36wLWt0vvwc-Al0PojjEevhClmD7NHGgjhUd0=.e3c2c691-745a-453a-a145-6638a96946e5@github.com>

On Thu, 9 May 2024 19:52:12 GMT, Sonia Zaldana Calles <szaldana at openjdk.org> wrote:

>> Hi folks, 
>> 
>> This PR aims to fix [JDK-8329581](https://bugs.openjdk.org/browse/JDK-8329581). 
>> 
>> I think the regression got introduced in [JDK-8315458](https://bugs.openjdk.org/browse/JDK-8315458). 
>> 
>> In the issue linked above, [LauncherHelper#getMainType](https://github.com/openjdk/jdk/pull/16461/files#diff-108a3a3e3c2d108c8c7f19ea498f641413b7c9239ecd2975a6c27d904c2ba226) got removed to simplify launcher code.
>> 
>> Previously, we used ```getMainType``` to do the appropriate main method invocation in ```JavaMain```. However, we currently attempt to do all types of main method invocations at the same time [here](https://github.com/openjdk/jdk/blob/master/src/java.base/share/native/libjli/java.c#L623). 
>> 
>> Note how all of these invocations clear the exception reported with [CHECK_EXCEPTION_FAIL](https://github.com/openjdk/jdk/blob/140f56718bbbfc31bb0c39255c68568fad285a1f/src/java.base/share/native/libjli/java.c#L390). 
>> 
>> Therefore, if a legitimate exception comes up during one of these invocations, it does not get reported. 
>> 
>> I propose reintroducing ```LauncherHelper#getMainType``` but I'm looking forward to your suggestions. 
>> 
>> Cheers, 
>> Sonia
>
> Sonia Zaldana Calles has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Decreasing diff size addressing unnecessary changes

My remarks have all been addressed. Thank you, @SoniaZaldana. From my side this is good to go.

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

Marked as reviewed by stuefe (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18786#pullrequestreview-2049599835

From djelinski at openjdk.org  Fri May 10 08:45:32 2024
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Fri, 10 May 2024 08:45:32 GMT
Subject: RFR: 8331907: BigInteger and BigDecimal should use optimized
 division [v2]
In-Reply-To: <-U6_9J-If3E3P3j4y7kt2yTCdNLvKkTSPrK0FxhNM80=.07321109-402b-4d28-9788-ddd52f42467d@github.com>
References: <-U6_9J-If3E3P3j4y7kt2yTCdNLvKkTSPrK0FxhNM80=.07321109-402b-4d28-9788-ddd52f42467d@github.com>
Message-ID: <ZZcPjDSWBmE-BqZKgNx49ZD2WnpYwSaPUQBS-gLi7RE=.e8d9cf95-be06-4e9d-9f27-919b84d3070e@github.com>

> Replace the custom unsigned divide / remainder functions with the compiler-optimized Long.divideUnsigned / remainderUnsigned.
> 
> No new tests. Existing tier1-3 tests continue to pass.
> 
> I added a new set of divide benchmarks. Results in thread.
> 
> I also removed the BigDecimal.toString benchmarks. They no longer serve their purpose - toString caches the returned value, so we were only benchmarking the cache access time.

Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision:

  Inline variable declaration

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/19134/files
  - new: https://git.openjdk.org/jdk/pull/19134/files/e565e1b6..a3fbc07d

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

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

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

From redestad at openjdk.org  Fri May 10 08:50:07 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Fri, 10 May 2024 08:50:07 GMT
Subject: RFR: 8331724: Refactor j.l.constant implementation to internal
 package [v7]
In-Reply-To: <_GPUF9d1E6eBKRxP6bEEqA3LSKRJe2GwCRTfVYbDwFU=.cb482785-e7c4-45f7-bd3a-cd32d466a2cb@github.com>
References: <_GPUF9d1E6eBKRxP6bEEqA3LSKRJe2GwCRTfVYbDwFU=.cb482785-e7c4-45f7-bd3a-cd32d466a2cb@github.com>
Message-ID: <-R0uRVBFsj_iZmqCMJTUL0weCsL6st9ezZdKnv7gFIU=.a0ed3258-7812-4ded-a1ee-e971bec8d4da@github.com>

> This PR suggests refactoring the implementation classes of java.lang.constant into a new package jdk.internal.constant to enable sharing some trusted static factory methods with users elsewhere in java.base, such as java.lang.invoke and java.lang.classfile. The refactoring also adds some "trusted" methods for use when input is pre-validated, and makes use of them where applicable in the current implementation. There are more changes in the pipeline which will be folded into #17108 or PR'ed once that is integrated. 
> 
> There are two optimizations mixed up here. One in `MethodTypeDesc.ofDescriptor`:
> 
> Name                                                             (descString) Cnt     Base     Error      Test   Error  Unit  Change
> MethodTypeDescFactories.ofDescriptor  (Ljava/lang/Object;Ljava/lang/String;)I   6  138,371 ?   0,767   136,939 ? 1,126 ns/op   1,01x (p = 0,000*)
> MethodTypeDescFactories.ofDescriptor                                      ()V   6   10,528 ?   2,495     4,110 ? 0,047 ns/op   2,56x (p = 0,000*)
> MethodTypeDescFactories.ofDescriptor ([IJLjava/lang/String;Z)Ljava/util/List;   6  209,390 ?   4,583   196,175 ? 3,211 ns/op   1,07x (p = 0,000*)
> MethodTypeDescFactories.ofDescriptor                    ()[Ljava/lang/String;   6   36,039 ?   8,684    20,794 ? 1,110 ns/op   1,73x (p = 0,000*)
> MethodTypeDescFactories.ofDescriptor                                 (..IIJ)V   6  279,139 ?   6,248   187,934 ? 0,857 ns/op   1,49x (p = 0,000*)
> MethodTypeDescFactories.ofDescriptor                 (.....................).   6 2174,387 ? 132,879  1150,652 ? 3,158 ns/op   1,89x (p = 0,000*)
>   * = significant
> 
> 
> The other in `ClassDesc::nested`, where to get rid of a simple static method in `ConstantUtils` I ended up speeding up and simplifying the public factory method:
> 
> Name                                      Cnt    Base     Error    Test   Error  Unit  Change
> ClassDescFactories.ReferenceOnly.ofNested   6 209,853 ? 132,525  22,017 ? 0,573 ns/op   9,53x (p = 0,000*)
>   * = significant
> 
> 
> The optimizations could be split out and PRd independently, but I think they are simple enough to include in this refactoring.

Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:

  Update src/java.base/share/classes/jdk/internal/constant/MethodTypeDescImpl.java
  
  Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/19105/files
  - new: https://git.openjdk.org/jdk/pull/19105/files/b21d3e60..5af9de09

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19105&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19105&range=05-06

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/19105.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19105/head:pull/19105

PR: https://git.openjdk.org/jdk/pull/19105

From alanb at openjdk.org  Fri May 10 08:55:31 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 10 May 2024 08:55:31 GMT
Subject: RFR: 8329581: Java launcher no longer prints a stack trace [v9]
In-Reply-To: <DjXIQXr_CK3q3-W506Ms-62DW1hlpgGRtrJ_Av7HJL0=.9cc03a10-456e-4c5c-a78d-2f8821f3dca8@github.com>
References: <Z0pDMIc_XvZhcZdeFsIQUlqI17q5ybj0BnQ9Kl3jwxg=.8f981c46-a8a3-4520-a6e3-79ee7fce0253@github.com>
 <krgANOmUJpt38cg16YhdXnUibxgX4shajEyWnMF79Hc=.e2dba0cc-8085-4efd-a300-d9c7f771510b@github.com>
 <OSB-RYHDOcS3rbr3_rsRmDPO-GFps7FXT_LD_2M2PHM=.2c4dc9d2-f40f-45e1-98f8-3c0aa2fb9c67@github.com>
 <DjXIQXr_CK3q3-W506Ms-62DW1hlpgGRtrJ_Av7HJL0=.9cc03a10-456e-4c5c-a78d-2f8821f3dca8@github.com>
Message-ID: <Ek9LV9Y5PYyF_zDJpxMzkWaYrT_iojHy6zjQdgHdVh4=.ce6c4998-6c2b-440c-915d-7877642751b2@github.com>

On Thu, 9 May 2024 19:48:53 GMT, Sonia Zaldana Calles <szaldana at openjdk.org> wrote:

>> Pre-existing: Man, I cannot grok the complex return code handling, tbh.
>> 
>> We have the local `ret` variable holding a return code. We also hand codes to CHECK_EXCEPTION_LEAVE as macro argument. But we don't hand codes to CHECK_EXCEPTION_NULL_LEAVE. LEAVE uses the locally defined `ret` instead of getting the return code as argument. CHECK_EXCEPTION_LEAVE modifies the local `ret`, but CHECK_EXCEPTION_NULL_LEAVE does not.
>> 
>> CHECK_EXCEPTION_NULL_LEAVE does not set `ret`. So, in case of an error, it would cause the launcher to return OK, but this does not happen because the local `ret` gets initialized to 1 before the first call to CHECK_EXCEPTION_NULL_LEAVE (line 566 resp. 560). Not sure if this was intentional, but it surely is very brittle. We rely on the content of `ret`, and that changes several times throughout JavaMain.
>> 
>> CHECK_EXCEPTION_NULL_LEAVE argument is named CENL_exception, which I don't understand.
>> 
>> To confuse matters more, the logic for internal error codes and the launcher return code is reversed: internally, 0 means error, and externally, 0 means success. And we only use numerical literals (`1`, `0`) instead of clearly named constants.
>> 
>> This may be food for another RFE, to keep this patch minimal. But a good solution, to me, would be like this:
>> 
>> - have the same logic for return codes (1 = error, 0 = success) to ease understanding
>> - have clearly named constants (e.g. "LAUNCHER_OK" 0, "LAUNCHER_ERR" = 1)
>> - have the LEAVE macro take the launcher return code as argument
>> - have all xxx_LEAVE macros pass in LAUNCHER_ERR to LEAVE
>> - call the final LEAVE with LAUNCHER_OK
>> - optionally, define something like "LEAVE_ERR" and "LEAVE_OK" that call LEAVE with either LAUNCHER_ERR or LAUNCHER_OK, for more concise coding.
>> 
>> For this patch, I think the return code logic is okay, but I would feel better if others double-checked.
>
>> This may be food for another RFE, to keep this patch minimal. But a good solution, to me, would be like this:
>> 
>> * have the same logic for return codes (1 = error, 0 = success) to ease understanding
>> * have clearly named constants (e.g. "LAUNCHER_OK" 0, "LAUNCHER_ERR" = 1)
>> * have the LEAVE macro take the launcher return code as argument
>> * have all xxx_LEAVE macros pass in LAUNCHER_ERR to LEAVE
>> * call the final LEAVE with LAUNCHER_OK
>> * optionally, define something like "LEAVE_ERR" and "LEAVE_OK" that call LEAVE with either LAUNCHER_ERR or LAUNCHER_OK, for more concise coding.
>> 
>> For this patch, I think the return code logic is okay, but I would feel better if others double-checked.
> 
> @tstuefe Agreed, I can look into opening another issue to track this after we fix the regression.

@SoniaZaldana I plan to review this shortly. It's an important issue that slipped through due to insufficient tests.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18786#issuecomment-2104216259

From duke at openjdk.org  Fri May 10 09:22:39 2024
From: duke at openjdk.org (serhiysachkov)
Date: Fri, 10 May 2024 09:22:39 GMT
Subject: RFR: 8331646: Add specific regression leap year tests [v5]
In-Reply-To: <cB-Q8ihe6DYQTm1WcRvVV3oW8YXtnWH5fmsS1zurwwY=.176d4137-bd3b-445e-a055-c738bd73744c@github.com>
References: <cB-Q8ihe6DYQTm1WcRvVV3oW8YXtnWH5fmsS1zurwwY=.176d4137-bd3b-445e-a055-c738bd73744c@github.com>
Message-ID: <jJs8KXZecYkvsiziGW2K2mm7jhnBZItqp_fq-VrWVB4=.e4a6beb0-133c-440b-a53f-11473a27003c@github.com>

> Calendar.add() tests that describe its behavior.

serhiysachkov has updated the pull request incrementally with one additional commit since the last revision:

  JDK-8331646 fixing typo

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19082/files
  - new: https://git.openjdk.org/jdk/pull/19082/files/f6ba2e31..8e070b4e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19082&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19082&range=03-04

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/19082.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19082/head:pull/19082

PR: https://git.openjdk.org/jdk/pull/19082

From prappo at openjdk.org  Fri May 10 10:25:05 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Fri, 10 May 2024 10:25:05 GMT
Subject: RFR: 8305457: Implement java.io.IO [v7]
In-Reply-To: <k1XL9rhR00IEZIYFMOKXZYhLi0wh5yXLlRGBS9nppTo=.5d6fc4ee-f0cd-4a60-9825-2eefb17eabaf@github.com>
References: <w2msiw_qaMEIJS3s9D4bg8pFbz5WIF0KdP6Mm-XFjLI=.85b2020b-8c46-4bac-8a69-4975b068f2ff@github.com>
 <-WNQ0gigYgjDdjH55OM-8aWzcDeHcA5ORdsK8MpSvj8=.8fe3c2ee-f30b-4dbd-a9a6-b0c8a4f0dbbc@github.com>
 <VeykkrIb_1RvBlQ3NYZJIvig16qeKByY6hcRtpyeruw=.833c60ab-f4a7-4161-a071-ef9ba3b57657@github.com>
 <mmUl8dkLjrfAs1utQ0e5zn8Knz2ZV3UzM8x4KxB4wtc=.c95890ba-267d-4c0f-8351-4d78cee2f024@github.com>
 <k1XL9rhR00IEZIYFMOKXZYhLi0wh5yXLlRGBS9nppTo=.5d6fc4ee-f0cd-4a60-9825-2eefb17eabaf@github.com>
Message-ID: <g7zBOUGHzFfWGH3gNZYZjg6AGIWY0EhKSK5SAsJ4ocM=.33801489-ae59-46ce-826e-57a122c9c065@github.com>

On Fri, 10 May 2024 07:29:42 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> If the sole constructor of a class is private, not only does it preclude the class from being instantiated, but it also precludes the class from being extended. Mind you, even with the sole private constructor, both instantiation and extension are still possible from inside the class or its nested classes. As long as we don't leak such instances to API clients, they won't seem to be able to observe any difference between "the private constructor" and "the private constructor of a final class".
>> 
>> I think that just having that constructor private but the class "non-final" makes bigger bang for the buck. We can defer the decision to make the class final.
>> 
>> If this helps, here are a few well-known similar classes:
>> 
>>   - java.util.Collections
>>   - java.util.concurrent.Executors
>
> Although true (and also described in Item 4 in "Effective Java" 3rd ed by JB) I think it is better to also signal the intent by marking the class as `final`. See for example Arrays that we updated some time ago.

It feels better to specify what the class is for than to "signal" all the things it is not for. In the first sentence of its documentation comment, `IO` says that it's a "collection of static convenience methods". I'm not sure how a class can signal its intent more clearly than that.

Like that of `Arrays`, `Collections`, `Collectors`, `Comparators`, `Executors`, `Files`, `Objects`, etc., an instance of `IO` or of its subclass is no more useful than an instance of `Object`. Even if `IO` isn't `final` and has a default constructor, it doesn't matter in practice.

Not too far ago, we started generating warnings on default constructors. To avoid those warnings, I had to provide an explicit constructor.

While unnecessary, I'll make `IO` `final`. Maybe it will help an IDE tell the programmer that they are doing something meaningless.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19112#discussion_r1596572570

From liach at openjdk.org  Fri May 10 10:29:20 2024
From: liach at openjdk.org (Chen Liang)
Date: Fri, 10 May 2024 10:29:20 GMT
Subject: RFR: 8331744: java.lang.classfile.TypeKind improvements [v5]
In-Reply-To: <jXeaNMrczPVr7MhMJRdA8VtoGT4J8F8jJi2CL3fJdsg=.82f94657-7cd4-42f6-a337-8adc9890e92e@github.com>
References: <_x31CU5mODg3NGaRGzI5HdNdcjsKmqWb1TA7KZnZcFg=.43ce5ba3-71e7-42e5-a531-c3b609d0aafb@github.com>
 <jXeaNMrczPVr7MhMJRdA8VtoGT4J8F8jJi2CL3fJdsg=.82f94657-7cd4-42f6-a337-8adc9890e92e@github.com>
Message-ID: <WJ6uxnVOkwi8qAYi-GlE2WtDhDy7lHZ4M9GnWBHVAxM=.8cdd8821-ff1c-4bae-8aea-e37b69fa98b6@github.com>

On Thu, 9 May 2024 21:15:31 GMT, Chen Liang <liach at openjdk.org> wrote:

>> A peek into TypeKind during the research for #19105 reveals that TypeKind has a few issues:
>> 1. Name mismatch for `newarraycode` and `fromNewArrayCode`: Renamed both to use "newarray code"
>> 2. `fromDescriptor` can throw IOOBE if the input string is empty: changed to throw IAE and added tests.
>> 3. `from(Class)` can be slow due to descriptor computation: added benchmark, will share result in next comment (as it may change with code changes).
>> 
>> The first 2 changes involves API changes, and a CSR has been created. Requesting @asotona for a review.
>
> Chen Liang has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Restore fixed seed
>  - Revert "Hash table, use fixed random seed"
>    
>    This reverts commit 9af30c65d2c7be3535e4483e278151bc4473d63c.

Thanks for reviewing!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19109#issuecomment-2104360716

From prappo at openjdk.org  Fri May 10 10:43:18 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Fri, 10 May 2024 10:43:18 GMT
Subject: RFR: 8305457: Implement java.io.IO [v8]
In-Reply-To: <w2msiw_qaMEIJS3s9D4bg8pFbz5WIF0KdP6Mm-XFjLI=.85b2020b-8c46-4bac-8a69-4975b068f2ff@github.com>
References: <w2msiw_qaMEIJS3s9D4bg8pFbz5WIF0KdP6Mm-XFjLI=.85b2020b-8c46-4bac-8a69-4975b068f2ff@github.com>
Message-ID: <GSIOu487zMzbT5rkqhgqPctxxKsS-uj3CWfbmlwdbPs=.b4a2010f-a519-4a0d-8272-31bfd4eb5a6b@github.com>

> Please review this PR which introduces the `java.io.IO` top-level class and three methods to `java.io.Console` for [Implicitly Declared Classes and Instance Main Methods (Third Preview)].
> 
> This PR has been obtained as `git merge --squash` of a now obsolete [draft PR].
> 
> [Implicitly Declared Classes and Instance Main Methods (Third Preview)]: https://bugs.openjdk.org/browse/JDK-8323335
> [draft PR]: https://github.com/openjdk/jdk/pull/18921

Pavel Rappo has updated the pull request incrementally with two additional commits since the last revision:

 - Clarify input charset
 - Make IO final

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19112/files
  - new: https://git.openjdk.org/jdk/pull/19112/files/1bf7a4cd..43a95732

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19112&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19112&range=06-07

  Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/19112.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19112/head:pull/19112

PR: https://git.openjdk.org/jdk/pull/19112

From liach at openjdk.org  Fri May 10 10:53:25 2024
From: liach at openjdk.org (Chen Liang)
Date: Fri, 10 May 2024 10:53:25 GMT
Subject: Integrated: 8331744: java.lang.classfile.TypeKind improvements
In-Reply-To: <_x31CU5mODg3NGaRGzI5HdNdcjsKmqWb1TA7KZnZcFg=.43ce5ba3-71e7-42e5-a531-c3b609d0aafb@github.com>
References: <_x31CU5mODg3NGaRGzI5HdNdcjsKmqWb1TA7KZnZcFg=.43ce5ba3-71e7-42e5-a531-c3b609d0aafb@github.com>
Message-ID: <sVjYfxlgT6XLtmE2BhaBiljDx6yqhiqAVQg8v2TEwTU=.51d44c09-aad6-41de-b64e-b9381e46e199@github.com>

On Mon, 6 May 2024 20:48:05 GMT, Chen Liang <liach at openjdk.org> wrote:

> A peek into TypeKind during the research for #19105 reveals that TypeKind has a few issues:
> 1. Name mismatch for `newarraycode` and `fromNewArrayCode`: Renamed both to use "newarray code"
> 2. `fromDescriptor` can throw IOOBE if the input string is empty: changed to throw IAE and added tests.
> 3. `from(Class)` can be slow due to descriptor computation: added benchmark, will share result in next comment (as it may change with code changes).
> 
> The first 2 changes involves API changes, and a CSR has been created. Requesting @asotona for a review.

This pull request has now been integrated.

Changeset: 784b8fce
Author:    Chen Liang <liach at openjdk.org>
Committer: Claes Redestad <redestad at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/784b8fce7a1b05209a8db168c8d2f86484a1a817
Stats:     183 lines in 5 files changed: 167 ins; 0 del; 16 mod

8331744: java.lang.classfile.TypeKind improvements

Reviewed-by: asotona, redestad

-------------

PR: https://git.openjdk.org/jdk/pull/19109

From jlahoda at openjdk.org  Fri May 10 11:00:55 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Fri, 10 May 2024 11:00:55 GMT
Subject: RFR: 8331535: Incorrect prompt for Console.readLine [v5]
In-Reply-To: <IQvUAYG5zj0JqUbWiQiryAuBrtV6jrVCvy9useQZmlc=.a4dd8dfc-e835-4405-83f8-fd1bda8480f6@github.com>
References: <IQvUAYG5zj0JqUbWiQiryAuBrtV6jrVCvy9useQZmlc=.a4dd8dfc-e835-4405-83f8-fd1bda8480f6@github.com>
Message-ID: <WreObvEAFqvbblyLSjrc77L5PA3_TafnEQ4PfjmxbAM=.f73858dc-1502-4edc-8a89-7b7e91149b2f@github.com>

> When JLine reads a line, there may be a prompt provided. However, JLine will not interpret the prompt literally, it will handle `%` specially. As a consequence, doing:
> 
> System.console().readLine("%%s");
> 
> 
> will not print `%s`, as first `String.format` is used, which will convert `%%s` to `%s`, and then JLine will interpret the `%`. The proposed solution is to duplicate the `%`, so that JLine will print it.

Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:

  Fixing the '%' prompt problem for JShell tools' console.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19081/files
  - new: https://git.openjdk.org/jdk/pull/19081/files/a138981e..da84810f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19081&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19081&range=03-04

  Stats: 85 lines in 3 files changed: 82 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/19081.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19081/head:pull/19081

PR: https://git.openjdk.org/jdk/pull/19081

From prappo at openjdk.org  Fri May 10 11:05:06 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Fri, 10 May 2024 11:05:06 GMT
Subject: RFR: 8305457: Implement java.io.IO [v7]
In-Reply-To: <h8rrzx8ViVaY0Ciu1J6ZLVsV1Irn2i1Ek7TZ2R66GWI=.e1583e64-a7ae-411b-9fb2-a976287cc355@github.com>
References: <w2msiw_qaMEIJS3s9D4bg8pFbz5WIF0KdP6Mm-XFjLI=.85b2020b-8c46-4bac-8a69-4975b068f2ff@github.com>
 <554HmRIAD_1Hf8Hbq6_YRH9iTf8fBk_OZ1XrlmSsQAU=.90c8b148-029a-429f-9037-179d9d30f6ad@github.com>
 <h8rrzx8ViVaY0Ciu1J6ZLVsV1Irn2i1Ek7TZ2R66GWI=.e1583e64-a7ae-411b-9fb2-a976287cc355@github.com>
Message-ID: <lBelQPBR4BCjACmgeZF4hrAnjH9aRmOyeXTqE_9AcPU=.0d7510e0-e0c4-4e56-9c5d-4307469336bb@github.com>

On Fri, 10 May 2024 07:23:38 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix System.console().readln(null) in jshell
>>   
>>   Without it, jshell hangs on me. Will think of a test.
>
> src/java.base/share/classes/java/io/IO.java line 47:
> 
>> 45: 
>> 46:     private IO() {
>> 47:         throw new Error("no instances");
> 
> Is this necessary?

No, it's not necessary.

My guess is that throwing an unconditional error (usually with a snarky message) from the inside the sole private constructor is a historical idiom to deter deep reflectors with their `setAccessible` and what not. Maybe that idiom is outdated with modules and recent efforts on cranking up the [integrity](https://openjdk.org/jeps/8305968), that I don't know.

FWIW, here's a snippet[^*] from "Item 4: Enforce noninstantiability with a private constructor" you referred to in your earlier comment:

> A default constructor is generated only if a class contains no explicit constructors, so a class can be made noninstantiable by including a private constructor:
>
>        // Noninstantiable utility class
>        public class UtilityClass {
>            // Suppress default constructor for noninstantiability
>            private UtilityClass() {
>                throw new AssertionError();
>            }
>            ...  // Remainder omitted
>        }
>
> Because the explicit constructor is private, it is inaccessible outside of the class. The `AssertionError` isn?t strictly required, but it provides insurance in case the constructor is accidentally invoked from within the class. It guarantees the class will never be instantiated under any circumstances.

[^*]: I created that snippet from the second edition, whose page 19 is conveniently publicly available here: https://www.google.ie/books/edition/Effective_Java/ka2VUBqHiWkC?hl=en&gbpv=1&dq=Item+4:+Enforce+noninstantiability+with+a+private+constructor&pg=PA19&printsec=frontcover

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19112#discussion_r1596615677

From dl at openjdk.org  Fri May 10 11:37:03 2024
From: dl at openjdk.org (Doug Lea)
Date: Fri, 10 May 2024 11:37:03 GMT
Subject: RFR: 8322732: ForkJoinPool may underutilize cores in async mode
In-Reply-To: <v-lLqE7QmMb0Mq6DW18Q1igG3WMHNZHLqKVO6AHigWU=.c8bf86d2-4c95-409d-8eac-a0ce7d660d9a@github.com>
References: <xRyDMAsSZ7obqpr3Aoc5qrHqILeJMxFVCeiRdctMI3U=.d5d3cd56-32eb-4431-ac01-081822fc86c6@github.com>
 <v-lLqE7QmMb0Mq6DW18Q1igG3WMHNZHLqKVO6AHigWU=.c8bf86d2-4c95-409d-8eac-a0ce7d660d9a@github.com>
Message-ID: <zI9QdQzOVIKDJbVMxX-mFczSOli5U7ZDS4PlWMuRIGc=.36b57bb1-e706-4476-be78-2b691da35004@github.com>

On Fri, 10 May 2024 07:35:17 GMT, Viktor Klang <vklang at openjdk.org> wrote:

>> This set of changes address causes of poor utilization with small numbers of cores due to overly aggressive contention avoidance. A number of further adjustments were needed to still avoid most contention effects in deployments with large numbers of cores
>
> src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 994:
> 
>> 992:     static final long SHUTDOWN        = 1L <<  1;   // terminate when quiescent
>> 993:     static final long TERMINATED      = 1L <<  2;   // only set if STOP also set
>> 994:     static final long RS_LOCK         = 1L <<  3;   // lowest seqlock bit
> 
> @DougLea I presume making these longs was to enable the int-field padding?

The net impact is to place runState field nearer queues ref, which on average reduces cacheline accesses since the are almost always accessed together. (The main focus of this update is to reduce memory contention that would otherwise accompany greater utilization. Most of the adjustments are small, but add up.)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19131#discussion_r1596643643

From dl at openjdk.org  Fri May 10 11:42:18 2024
From: dl at openjdk.org (Doug Lea)
Date: Fri, 10 May 2024 11:42:18 GMT
Subject: RFR: 8322732: ForkJoinPool may underutilize cores in async mode
In-Reply-To: <iUBNSU8KuzwD687df3qSjcpeFBGwDAU90om5Sts-fMk=.9112e43e-aae0-4b08-b7d2-59a756903491@github.com>
References: <xRyDMAsSZ7obqpr3Aoc5qrHqILeJMxFVCeiRdctMI3U=.d5d3cd56-32eb-4431-ac01-081822fc86c6@github.com>
 <iUBNSU8KuzwD687df3qSjcpeFBGwDAU90om5Sts-fMk=.9112e43e-aae0-4b08-b7d2-59a756903491@github.com>
Message-ID: <gRn8QPXE6CY4EskVLkWXQJMp82SfFaIbAecvSAPSk0M=.90f831ed-8925-4962-99ca-6ccbfa219ae4@github.com>

On Fri, 10 May 2024 08:02:23 GMT, Viktor Klang <vklang at openjdk.org> wrote:

>> This set of changes address causes of poor utilization with small numbers of cores due to overly aggressive contention avoidance. A number of further adjustments were needed to still avoid most contention effects in deployments with large numbers of cores
>
> src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 1405:
> 
>> 1403:                     U.loadFence();
>> 1404:                     if (base != b)
>> 1405:                         ;                              // inconsistent
> 
> @DougLea This seems like it could be a `continue;`, which might be easier to reason about?

You'd think these would be equivalent, but not always so, because of impact on safepoints. More compiler-whispering. But it can be a little more readable by converting to nested if with same effect. Will do.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19131#discussion_r1596647755

From dl at openjdk.org  Fri May 10 11:47:06 2024
From: dl at openjdk.org (Doug Lea)
Date: Fri, 10 May 2024 11:47:06 GMT
Subject: RFR: 8322732: ForkJoinPool may underutilize cores in async mode
In-Reply-To: <iUBNSU8KuzwD687df3qSjcpeFBGwDAU90om5Sts-fMk=.9112e43e-aae0-4b08-b7d2-59a756903491@github.com>
References: <xRyDMAsSZ7obqpr3Aoc5qrHqILeJMxFVCeiRdctMI3U=.d5d3cd56-32eb-4431-ac01-081822fc86c6@github.com>
 <iUBNSU8KuzwD687df3qSjcpeFBGwDAU90om5Sts-fMk=.9112e43e-aae0-4b08-b7d2-59a756903491@github.com>
Message-ID: <2xvOptvQzV6L5nutyvAUXyuJQftX52Fd8_vmyMIzs68=.4443c95a-5353-49f2-a55a-4b059ce9cb9e@github.com>

On Fri, 10 May 2024 08:04:27 GMT, Viktor Klang <vklang at openjdk.org> wrote:

>> This set of changes address causes of poor utilization with small numbers of cores due to overly aggressive contention avoidance. A number of further adjustments were needed to still avoid most contention effects in deployments with large numbers of cores
>
> src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 1412:
> 
>> 1410:                         if (stalled)
>> 1411:                             Thread.onSpinWait();
>> 1412:                         stalled = true;
> 
> @DougLea Performance-wise, does it make any difference to make the write to `stalled` in an `else-branch` to avoid writing it every time beyond the initial?

This doesn't matter performance-wise but I agree that it looks unnecessarily odd so will change.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19131#discussion_r1596652131

From dl at openjdk.org  Fri May 10 11:51:51 2024
From: dl at openjdk.org (Doug Lea)
Date: Fri, 10 May 2024 11:51:51 GMT
Subject: RFR: 8322732: ForkJoinPool may underutilize cores in async mode
In-Reply-To: <bJZGmVa7J6QiZvPU2hnDUaEX2hlphLj0QjQE6-2fu50=.b5e2c301-3e1c-42b8-846f-35291d696bd9@github.com>
References: <xRyDMAsSZ7obqpr3Aoc5qrHqILeJMxFVCeiRdctMI3U=.d5d3cd56-32eb-4431-ac01-081822fc86c6@github.com>
 <bJZGmVa7J6QiZvPU2hnDUaEX2hlphLj0QjQE6-2fu50=.b5e2c301-3e1c-42b8-846f-35291d696bd9@github.com>
Message-ID: <rpS5e9xC7BSWLtPF8zfayemrT6o5FmpgZEAINSTM5hY=.051dad40-be3c-4b39-b56e-99d563249328@github.com>

On Fri, 10 May 2024 08:08:05 GMT, Viktor Klang <vklang at openjdk.org> wrote:

>> This set of changes address causes of poor utilization with small numbers of cores due to overly aggressive contention avoidance. A number of further adjustments were needed to still avoid most contention effects in deployments with large numbers of cores
>
> src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 1432:
> 
>> 1430:         final void topLevelExec(ForkJoinTask<?> task, WorkQueue src,
>> 1431:                                 int srcBase, int cfg) {
>> 1432:             if (task != null && src != null) {
> 
> @DougLea Is this ever invoked with a null-task and a null-queue? ?

No. This is one of many hoisted null checks that help compilers avoid throwing null pointer exceptions where we don't want them.  Usually I mark these with " // always true", which I'll add here.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19131#discussion_r1596655269

From dl at openjdk.org  Fri May 10 11:57:13 2024
From: dl at openjdk.org (Doug Lea)
Date: Fri, 10 May 2024 11:57:13 GMT
Subject: RFR: 8322732: ForkJoinPool may underutilize cores in async mode
In-Reply-To: <myyMGgboonDNVFi2ETHwJEJPtEVW_dFlP49cDZkRn-I=.bf4e5e5f-c49c-4fc1-8230-433cafab2be6@github.com>
References: <xRyDMAsSZ7obqpr3Aoc5qrHqILeJMxFVCeiRdctMI3U=.d5d3cd56-32eb-4431-ac01-081822fc86c6@github.com>
 <myyMGgboonDNVFi2ETHwJEJPtEVW_dFlP49cDZkRn-I=.bf4e5e5f-c49c-4fc1-8230-433cafab2be6@github.com>
Message-ID: <silooJPA4_SWQlrEY3vGo-eGBk2IYrVHdTIpAp_b-Hg=.f2b33aa6-6b8f-4a6c-a843-3e23f58fd77a@github.com>

On Fri, 10 May 2024 08:11:52 GMT, Viktor Klang <vklang at openjdk.org> wrote:

>> This set of changes address causes of poor utilization with small numbers of cores due to overly aggressive contention avoidance. A number of further adjustments were needed to still avoid most contention effects in deployments with large numbers of cores
>
> src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 1830:
> 
>> 1828:             phase = w.phase;
>> 1829:             if ((src = w.source) != DROPPED) {
>> 1830:                 w.source = DROPPED;        // else already dropped
> 
> @DougLea Would there be any gain in atomically swapping out `w.source` to `DROPPED`?

No the source field is only written by owner. (With one harmless exception -- cascading idle timeouts, where an invalid value is set to check that no tasks were taken by successor.) I should note this somewhere.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19131#discussion_r1596661400

From dl at openjdk.org  Fri May 10 12:08:17 2024
From: dl at openjdk.org (Doug Lea)
Date: Fri, 10 May 2024 12:08:17 GMT
Subject: RFR: 8322732: ForkJoinPool may underutilize cores in async mode
In-Reply-To: <1Rh8n2h5T32Nky0-jfnk6iSKJJb-D_jBSANKYQHtIKg=.c72e7c53-36b4-4aeb-a2fe-31696472d60f@github.com>
References: <xRyDMAsSZ7obqpr3Aoc5qrHqILeJMxFVCeiRdctMI3U=.d5d3cd56-32eb-4431-ac01-081822fc86c6@github.com>
 <1Rh8n2h5T32Nky0-jfnk6iSKJJb-D_jBSANKYQHtIKg=.c72e7c53-36b4-4aeb-a2fe-31696472d60f@github.com>
Message-ID: <sbWrDIeEcy-RrkhB1iiYxhyalQjnXEQmrXahH1grUv8=.09f6c04f-78b4-4bc3-9207-91548822a78f@github.com>

On Fri, 10 May 2024 08:15:59 GMT, Viktor Klang <vklang at openjdk.org> wrote:

>> This set of changes address causes of poor utilization with small numbers of cores due to overly aggressive contention avoidance. A number of further adjustments were needed to still avoid most contention effects in deployments with large numbers of cores
>
> src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 1883:
> 
>> 1881:             if (qs == null)
>> 1882:                 break;
>> 1883:             if (qs.length <= i)
> 
> @DougLea Any particular reason why these are not or-branches of a single if?

An old trick to save bytecode branches, reducing code size. I haven't checked lately whether this is still true though.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19131#discussion_r1596670378

From dl at openjdk.org  Fri May 10 12:12:31 2024
From: dl at openjdk.org (Doug Lea)
Date: Fri, 10 May 2024 12:12:31 GMT
Subject: RFR: 8322732: ForkJoinPool may underutilize cores in async mode
In-Reply-To: <z0RoolyDKAWS8rkliT8nxELW7lH5dlhrtBI6GoStac8=.2b9e94d1-59fc-43ce-82f5-bdc40020cfba@github.com>
References: <xRyDMAsSZ7obqpr3Aoc5qrHqILeJMxFVCeiRdctMI3U=.d5d3cd56-32eb-4431-ac01-081822fc86c6@github.com>
 <z0RoolyDKAWS8rkliT8nxELW7lH5dlhrtBI6GoStac8=.2b9e94d1-59fc-43ce-82f5-bdc40020cfba@github.com>
Message-ID: <k3ahbTg5YfHJ110cSxFYyXt2BR7KqyzUTP3hwq8B7rI=.75a678ed-e5d3-4960-994c-8795cf0089a2@github.com>

On Fri, 10 May 2024 08:30:24 GMT, Viktor Klang <vklang at openjdk.org> wrote:

>> This set of changes address causes of poor utilization with small numbers of cores due to overly aggressive contention avoidance. A number of further adjustments were needed to still avoid most contention effects in deployments with large numbers of cores
>
> src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 2167:
> 
>> 2165:             }
>> 2166:         }
>> 2167:         return stat;
> 
> @DougLea Since `stat` is a local, and is only written to once per branch it might make sense to just return from each of the branches?

A similar answer as above: using a single return avoids compiler generating branches to its own synthetic single return. Worthwhile only when whole method is of this form (I did check this one.)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19131#discussion_r1596674193

From dl at openjdk.org  Fri May 10 12:23:13 2024
From: dl at openjdk.org (Doug Lea)
Date: Fri, 10 May 2024 12:23:13 GMT
Subject: RFR: 8322732: ForkJoinPool may underutilize cores in async mode
In-Reply-To: <v-lLqE7QmMb0Mq6DW18Q1igG3WMHNZHLqKVO6AHigWU=.c8bf86d2-4c95-409d-8eac-a0ce7d660d9a@github.com>
References: <xRyDMAsSZ7obqpr3Aoc5qrHqILeJMxFVCeiRdctMI3U=.d5d3cd56-32eb-4431-ac01-081822fc86c6@github.com>
 <v-lLqE7QmMb0Mq6DW18Q1igG3WMHNZHLqKVO6AHigWU=.c8bf86d2-4c95-409d-8eac-a0ce7d660d9a@github.com>
Message-ID: <JUtCpfYxYkzw0CutHCbSfbFKNU0xadqFQMJx6x7meS4=.0517145f-be05-41f2-9d85-03d022d103a0@github.com>

On Fri, 10 May 2024 07:34:40 GMT, Viktor Klang <vklang at openjdk.org> wrote:

>> This set of changes address causes of poor utilization with small numbers of cores due to overly aggressive contention avoidance. A number of further adjustments were needed to still avoid most contention effects in deployments with large numbers of cores
>
> src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 978:
> 
>> 976:      * of two, at least 2. See above.
>> 977:      */
>> 978:     static final int INITIAL_QUEUE_CAPACITY = 1 << 7;
> 
> @DougLea Interesting change?what impact did you notice when doubling this?

The goal is to reduce the worst form of contention: when queue arrays are laid out adjacently in memory. Increasing sizes has some impact but with diminishing returns. Thanks for the comment as a reminder that I haven't rechecked this lately in light of other layout changes. Will do.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19131#discussion_r1596684587

From vklang at openjdk.org  Fri May 10 12:45:32 2024
From: vklang at openjdk.org (Viktor Klang)
Date: Fri, 10 May 2024 12:45:32 GMT
Subject: RFR: 8322732: ForkJoinPool may underutilize cores in async mode
In-Reply-To: <k3ahbTg5YfHJ110cSxFYyXt2BR7KqyzUTP3hwq8B7rI=.75a678ed-e5d3-4960-994c-8795cf0089a2@github.com>
References: <xRyDMAsSZ7obqpr3Aoc5qrHqILeJMxFVCeiRdctMI3U=.d5d3cd56-32eb-4431-ac01-081822fc86c6@github.com>
 <z0RoolyDKAWS8rkliT8nxELW7lH5dlhrtBI6GoStac8=.2b9e94d1-59fc-43ce-82f5-bdc40020cfba@github.com>
 <k3ahbTg5YfHJ110cSxFYyXt2BR7KqyzUTP3hwq8B7rI=.75a678ed-e5d3-4960-994c-8795cf0089a2@github.com>
Message-ID: <Tlp7jILcbqwTqnr3QQgPnpRZYz0S-WZ0yIsrmbByg5I=.87f67e6e-4195-4ae3-bffa-0bcb915c080a@github.com>

On Fri, 10 May 2024 12:09:20 GMT, Doug Lea <dl at openjdk.org> wrote:

>> src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 2167:
>> 
>>> 2165:             }
>>> 2166:         }
>>> 2167:         return stat;
>> 
>> @DougLea Since `stat` is a local, and is only written to once per branch it might make sense to just return from each of the branches?
>
> A similar answer as above: using a single return avoids compiler generating branches to its own synthetic single return. Worthwhile only when whole method is of this form (I did check this one.)

I prefer having methods with a single return, placed on the last line of the method, but I wanted to make sure I wasn't missing any underlying reason. :)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19131#discussion_r1596706172

From rgiulietti at openjdk.org  Fri May 10 13:17:49 2024
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Fri, 10 May 2024 13:17:49 GMT
Subject: RFR: 8331907: BigInteger and BigDecimal should use optimized
 division [v2]
In-Reply-To: <ZZcPjDSWBmE-BqZKgNx49ZD2WnpYwSaPUQBS-gLi7RE=.e8d9cf95-be06-4e9d-9f27-919b84d3070e@github.com>
References: <-U6_9J-If3E3P3j4y7kt2yTCdNLvKkTSPrK0FxhNM80=.07321109-402b-4d28-9788-ddd52f42467d@github.com>
 <ZZcPjDSWBmE-BqZKgNx49ZD2WnpYwSaPUQBS-gLi7RE=.e8d9cf95-be06-4e9d-9f27-919b84d3070e@github.com>
Message-ID: <OulPIFYX-diAV4yfE-fiw7n3spWX1wbgz4BOiMwN9fk=.0164a89b-43ff-4d4f-b2a5-0d660fec8f45@github.com>

On Fri, 10 May 2024 08:45:32 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> Replace the custom unsigned divide / remainder functions with the compiler-optimized Long.divideUnsigned / remainderUnsigned.
>> 
>> No new tests. Existing tier1-3 tests continue to pass.
>> 
>> I added a new set of divide benchmarks. Results in thread.
>> 
>> I also removed the BigDecimal.toString benchmarks. They no longer serve their purpose - toString caches the returned value, so we were only benchmarking the cache access time.
>
> Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Inline variable declaration

src/java.base/share/classes/java/math/MutableBigInteger.java line 1117:

> 1115:             rem = (int) Long.remainderUnsigned(dividendEstimate, divisorLong);
> 1116:             quotient.value[intLen - xlen] = q;
> 1117:             remLong = rem & LONG_MASK;

What about removing one of the `int rem`, renaming `remLong` to `rem` and using it as follows?


        long rem = 0;
        for (int xlen = intLen; xlen > 0; xlen--) {
            long dividendEstimate = (rem << 32) |
                    (value[offset + intLen - xlen] & LONG_MASK);
            int q = (int) Long.divideUnsigned(dividendEstimate, divisorLong);
            rem = Long.remainderUnsigned(dividendEstimate, divisorLong);
            quotient.value[intLen - xlen] = q;
        }

        quotient.normalize();
        return (int) rem;

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19134#discussion_r1596734060

From alanb at openjdk.org  Fri May 10 13:21:08 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 10 May 2024 13:21:08 GMT
Subject: RFR: 8332029: Provide access to initial value of stderr via
 JavaLangAccess
Message-ID: <kPZZ3bMLJ-gEnr9NMQ0TaybDkcM15gP0YUDFCdWYxbA=.558291dd-740b-4807-bf63-e7f6d706d0e8@github.com>

In preparation for JEP 471 and JEP 472, provide access to the initial value of System.err from JavaLangAccess. The initial value of System.in is already exposed to code in java.base with this shared secret.

-------------

Commit messages:
 - Initial commit

Changes: https://git.openjdk.org/jdk/pull/19171/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19171&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8332029
  Stats: 30 lines in 3 files changed: 20 ins; 5 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/19171.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19171/head:pull/19171

PR: https://git.openjdk.org/jdk/pull/19171

From alanb at openjdk.org  Fri May 10 13:31:37 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 10 May 2024 13:31:37 GMT
Subject: RFR: 8332064: Implementation of Structured Concurrency (Third Preview)
Message-ID: <YKVRqYuGwAB4cPvyVacCBrrMlS-m5K1fJSGpe7hQ744=.da388230-47ff-4097-9f9c-7d590bddcb8b@github.com>

There are any API or implementations changes in third preview but the JEP number/title needs to be bumped for the javadoc page.

-------------

Commit messages:
 - Initial commit

Changes: https://git.openjdk.org/jdk/pull/19175/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19175&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8332064
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/19175.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19175/head:pull/19175

PR: https://git.openjdk.org/jdk/pull/19175

From djelinski at openjdk.org  Fri May 10 13:39:42 2024
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Fri, 10 May 2024 13:39:42 GMT
Subject: RFR: 8331907: BigInteger and BigDecimal should use optimized
 division [v3]
In-Reply-To: <-U6_9J-If3E3P3j4y7kt2yTCdNLvKkTSPrK0FxhNM80=.07321109-402b-4d28-9788-ddd52f42467d@github.com>
References: <-U6_9J-If3E3P3j4y7kt2yTCdNLvKkTSPrK0FxhNM80=.07321109-402b-4d28-9788-ddd52f42467d@github.com>
Message-ID: <NcnOU2dTp15o_P-wTr6f7heU42sDOglOeCaUcD1Ac_Y=.1628637d-a83b-414b-a7c3-41ed621a3ca4@github.com>

> Replace the custom unsigned divide / remainder functions with the compiler-optimized Long.divideUnsigned / remainderUnsigned.
> 
> No new tests. Existing tier1-3 tests continue to pass.
> 
> I added a new set of divide benchmarks. Results in thread.
> 
> I also removed the BigDecimal.toString benchmarks. They no longer serve their purpose - toString caches the returned value, so we were only benchmarking the cache access time.

Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision:

  Remove duplicate variable

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19134/files
  - new: https://git.openjdk.org/jdk/pull/19134/files/a3fbc07d..83a9959a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19134&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19134&range=01-02

  Stats: 6 lines in 1 file changed: 0 ins; 2 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/19134.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19134/head:pull/19134

PR: https://git.openjdk.org/jdk/pull/19134

From dl at openjdk.org  Fri May 10 13:48:02 2024
From: dl at openjdk.org (Doug Lea)
Date: Fri, 10 May 2024 13:48:02 GMT
Subject: RFR: 8322732: ForkJoinPool may underutilize cores in async mode
In-Reply-To: <2xvOptvQzV6L5nutyvAUXyuJQftX52Fd8_vmyMIzs68=.4443c95a-5353-49f2-a55a-4b059ce9cb9e@github.com>
References: <xRyDMAsSZ7obqpr3Aoc5qrHqILeJMxFVCeiRdctMI3U=.d5d3cd56-32eb-4431-ac01-081822fc86c6@github.com>
 <iUBNSU8KuzwD687df3qSjcpeFBGwDAU90om5Sts-fMk=.9112e43e-aae0-4b08-b7d2-59a756903491@github.com>
 <2xvOptvQzV6L5nutyvAUXyuJQftX52Fd8_vmyMIzs68=.4443c95a-5353-49f2-a55a-4b059ce9cb9e@github.com>
Message-ID: <FyjUyTED4RVj4u9VeHrs6EpK1VkGx7lcDv9wQhrqjGI=.eb47d395-897e-4ba4-850b-971376a44122@github.com>

On Fri, 10 May 2024 11:44:14 GMT, Doug Lea <dl at openjdk.org> wrote:

>> src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 1412:
>> 
>>> 1410:                         if (stalled)
>>> 1411:                             Thread.onSpinWait();
>>> 1412:                         stalled = true;
>> 
>> @DougLea Performance-wise, does it make any difference to make the write to `stalled` in an `else-branch` to avoid writing it every time beyond the initial?
>
> This doesn't matter performance-wise but I agree that it looks unnecessarily odd so will change.

Or better (wrt this and previous comment): make the code-shape of poll() the same as inner loop of scan(). Done.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19131#discussion_r1596772902

From rgiulietti at openjdk.org  Fri May 10 13:49:04 2024
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Fri, 10 May 2024 13:49:04 GMT
Subject: RFR: 8331907: BigInteger and BigDecimal should use optimized
 division [v3]
In-Reply-To: <NcnOU2dTp15o_P-wTr6f7heU42sDOglOeCaUcD1Ac_Y=.1628637d-a83b-414b-a7c3-41ed621a3ca4@github.com>
References: <-U6_9J-If3E3P3j4y7kt2yTCdNLvKkTSPrK0FxhNM80=.07321109-402b-4d28-9788-ddd52f42467d@github.com>
 <NcnOU2dTp15o_P-wTr6f7heU42sDOglOeCaUcD1Ac_Y=.1628637d-a83b-414b-a7c3-41ed621a3ca4@github.com>
Message-ID: <nG7hoAO54cMyK_kPLaHmSHu97GXqbDOq0ihc4r-SdvQ=.01a85d62-cb17-4a15-b048-029136207f6a@github.com>

On Fri, 10 May 2024 13:39:42 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> Replace the custom unsigned divide / remainder functions with the compiler-optimized Long.divideUnsigned / remainderUnsigned.
>> 
>> No new tests. Existing tier1-3 tests continue to pass.
>> 
>> I added a new set of divide benchmarks. Results in thread.
>> 
>> I also removed the BigDecimal.toString benchmarks. They no longer serve their purpose - toString caches the returned value, so we were only benchmarking the cache access time.
>
> Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove duplicate variable

There's another spot for replacement at L.1096-1097 in `MutableBigInteger`. Did you see that one?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19134#issuecomment-2104640404

From djelinski at openjdk.org  Fri May 10 13:55:22 2024
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Fri, 10 May 2024 13:55:22 GMT
Subject: RFR: 8331907: BigInteger and BigDecimal should use optimized
 division [v3]
In-Reply-To: <NcnOU2dTp15o_P-wTr6f7heU42sDOglOeCaUcD1Ac_Y=.1628637d-a83b-414b-a7c3-41ed621a3ca4@github.com>
References: <-U6_9J-If3E3P3j4y7kt2yTCdNLvKkTSPrK0FxhNM80=.07321109-402b-4d28-9788-ddd52f42467d@github.com>
 <NcnOU2dTp15o_P-wTr6f7heU42sDOglOeCaUcD1Ac_Y=.1628637d-a83b-414b-a7c3-41ed621a3ca4@github.com>
Message-ID: <-JFUvzodcB3zLGogAYzx4-z3KV_bATfYcY0tYXD4Xnw=.b818479d-113b-47b7-8497-4ea9ce2421c9@github.com>

On Fri, 10 May 2024 13:39:42 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> Replace the custom unsigned divide / remainder functions with the compiler-optimized Long.divideUnsigned / remainderUnsigned.
>> 
>> No new tests. Existing tier1-3 tests continue to pass.
>> 
>> I added a new set of divide benchmarks. Results in thread.
>> 
>> I also removed the BigDecimal.toString benchmarks. They no longer serve their purpose - toString caches the returned value, so we were only benchmarking the cache access time.
>
> Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove duplicate variable

L.1096-1097 is a 32-bit by 32-bit division; I guess I could change it to use Integer.unsignedDivide. Let me look into it...

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19134#issuecomment-2104651245

From ecki at zusammenkunft.net  Fri May 10 14:13:08 2024
From: ecki at zusammenkunft.net (Bernd Eckenfels)
Date: Fri, 10 May 2024 16:13:08 +0200 (CEST)
Subject: Status of ZIP64 InputStream bug JDK-8298530?
In-Reply-To: <CANSoFxtKc=w9zy5TUFJDWpX7FhEVmzVVj1w9yZvV17F2ZUJbKA@mail.gmail.com>
References: <20240509174013.A459D6604A7@dd33810.kasserver.com><CANSoFxtKc=w9zy5TUFJDWpX7FhEVmzVVj1w9yZvV17F2ZUJbKA@mail.gmail.com>
Message-ID: <20240510141308.7009A663E11@dd33810.kasserver.com>

An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240510/315056b0/attachment.htm>

From jpai at openjdk.org  Fri May 10 14:13:29 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 10 May 2024 14:13:29 GMT
Subject: RFR: 8332064: Implementation of Structured Concurrency (Third
 Preview)
In-Reply-To: <YKVRqYuGwAB4cPvyVacCBrrMlS-m5K1fJSGpe7hQ744=.da388230-47ff-4097-9f9c-7d590bddcb8b@github.com>
References: <YKVRqYuGwAB4cPvyVacCBrrMlS-m5K1fJSGpe7hQ744=.da388230-47ff-4097-9f9c-7d590bddcb8b@github.com>
Message-ID: <rYjBNyDti43i7t21J8jQUcc2czEvlvPAwA7jr1cdHSg=.4c39d3cc-d949-4f4d-94df-a787af294470@github.com>

On Fri, 10 May 2024 10:58:42 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> There aren't any API or implementations changes in third preview but the JEP number/title needs to be bumped for the javadoc page.

Marked as reviewed by jpai (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/19175#pullrequestreview-2050165151

From jpai at openjdk.org  Fri May 10 14:22:05 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 10 May 2024 14:22:05 GMT
Subject: RFR: 8332029: Provide access to initial value of stderr via
 JavaLangAccess
In-Reply-To: <kPZZ3bMLJ-gEnr9NMQ0TaybDkcM15gP0YUDFCdWYxbA=.558291dd-740b-4807-bf63-e7f6d706d0e8@github.com>
References: <kPZZ3bMLJ-gEnr9NMQ0TaybDkcM15gP0YUDFCdWYxbA=.558291dd-740b-4807-bf63-e7f6d706d0e8@github.com>
Message-ID: <GnQxh1ZeIp6InRo39EdVStoZf_6cz6vtsKnRnKvBzuA=.7d259574-4c6c-454f-8e18-e47c4fd71fa6@github.com>

On Fri, 10 May 2024 07:57:40 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> In preparation for JEP 471 and JEP 472, provide access to the initial value of System.err from JavaLangAccess. The initial value of System.in is already exposed to code in java.base with this shared secret.

The change looks OK to me.

-------------

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19171#pullrequestreview-2050182792

From vklang at openjdk.org  Fri May 10 14:42:14 2024
From: vklang at openjdk.org (Viktor Klang)
Date: Fri, 10 May 2024 14:42:14 GMT
Subject: RFR: 8278255: Add more warning text in ReentrantLock and
 ReentrantReadWriteLock [v2]
In-Reply-To: <1YLryRpwC2JhbJQqVYfQ-dn2TMm42U3nV3Ad6p52Hr0=.b6659fe2-37ec-46fb-afeb-b06b611070d6@github.com>
References: <nb-F4YENhZMQth9RCQsvTAiiMEVnW-MKKJbe3NWWSgg=.86a1c9ab-c13b-4d37-8ef2-b495df14fa17@github.com>
 <ZjrjlUeRM-AtyH49lJMQPJkfad_MmEtWtS0n1gVPnkQ=.70f799bb-acb0-45ac-95c0-9001517128cd@github.com>
 <FbeaxqsS5SF9koVG-pHExVNRoWir-4kmJgu6VaOEt1g=.3ff0eff0-a80d-44b3-b955-63fcf3693912@github.com>
 <1YLryRpwC2JhbJQqVYfQ-dn2TMm42U3nV3Ad6p52Hr0=.b6659fe2-37ec-46fb-afeb-b06b611070d6@github.com>
Message-ID: <jO7peIVefiQGbhh_998u1kUFnq4i1Kn58cgYeRinOiM=.e9ec473c-3f58-4cf5-b2ca-a9a0a024fadc@github.com>

On Wed, 1 May 2024 10:03:25 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> The grammar rules prefer "that" because it is a restrictive clause, even though "which" might sound better.  See for example: https://owl.purdue.edu/owl/general_writing/grammar/that_vs_which.html
>
>> The grammar rules prefer "that" because it is a restrictive clause, even though "which" might sound better. See for example: https://owl.purdue.edu/owl/general_writing/grammar/that_vs_which.html
> 
> Thanks for that link, Doug.
> 
> I understand that two "that"s that are that close to each other might sound a bit weird. (Obviously, I exaggerated the issue in that preceding sentence.) Can we maybe rephrase it then?
> 
> 
>  *     // If code could throw, make sure that it is executed inside try block

@pavelrappo Ok to integrate? ?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18974#issuecomment-2104730094

From vklang at openjdk.org  Fri May 10 14:42:23 2024
From: vklang at openjdk.org (Viktor Klang)
Date: Fri, 10 May 2024 14:42:23 GMT
Subject: RFR: 8312436: CompletableFuture never completes when
 'Throwable.toString()' method throws Exception
Message-ID: <BoZpCFbXi3qywnwUABBY426CQFolXZOv4Ny8diWY3a8=.357b8dfa-2373-4317-bbcc-a6036201451d@github.com>

Primarily offering this PR for discussion, as Throwables throwing exceptions on toString(), getLocalizedMessage(), or getMessage() seems like a rather unreasonable thing to do.

Nevertheless, there is some things we can do, as witnessed in this PR.

-------------

Commit messages:
 - CompletableFuture should be more resilient against misbehaving exceptions

Changes: https://git.openjdk.org/jdk/pull/18988/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18988&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8312436
  Stats: 63 lines in 2 files changed: 52 ins; 2 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/18988.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18988/head:pull/18988

PR: https://git.openjdk.org/jdk/pull/18988

From liach at openjdk.org  Fri May 10 14:42:23 2024
From: liach at openjdk.org (Chen Liang)
Date: Fri, 10 May 2024 14:42:23 GMT
Subject: RFR: 8312436: CompletableFuture never completes when
 'Throwable.toString()' method throws Exception
In-Reply-To: <BoZpCFbXi3qywnwUABBY426CQFolXZOv4Ny8diWY3a8=.357b8dfa-2373-4317-bbcc-a6036201451d@github.com>
References: <BoZpCFbXi3qywnwUABBY426CQFolXZOv4Ny8diWY3a8=.357b8dfa-2373-4317-bbcc-a6036201451d@github.com>
Message-ID: <R-nxFnqBsblgkg9-fy_tjoWaZwBzkF1JEFMLbr4xteo=.d2f13bc0-e762-4df4-bcdd-e4bfb0a5fd97@github.com>

On Sun, 28 Apr 2024 09:54:34 GMT, Viktor Klang <vklang at openjdk.org> wrote:

> Primarily offering this PR for discussion, as Throwables throwing exceptions on toString(), getLocalizedMessage(), or getMessage() seems like a rather unreasonable thing to do.
> 
> Nevertheless, there is some things we can do, as witnessed in this PR.

src/java.base/share/classes/java/util/concurrent/CompletableFuture.java line 310:

> 308: 
> 309:     static CompletionException wrapInCompletionException(Throwable t) {
> 310:         if (t == null)

Is there any preexisting code path that ever passes a null? If not I don't think this check is necessary.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18988#discussion_r1582947192

From vklang at openjdk.org  Fri May 10 14:42:23 2024
From: vklang at openjdk.org (Viktor Klang)
Date: Fri, 10 May 2024 14:42:23 GMT
Subject: RFR: 8312436: CompletableFuture never completes when
 'Throwable.toString()' method throws Exception
In-Reply-To: <R-nxFnqBsblgkg9-fy_tjoWaZwBzkF1JEFMLbr4xteo=.d2f13bc0-e762-4df4-bcdd-e4bfb0a5fd97@github.com>
References: <BoZpCFbXi3qywnwUABBY426CQFolXZOv4Ny8diWY3a8=.357b8dfa-2373-4317-bbcc-a6036201451d@github.com>
 <R-nxFnqBsblgkg9-fy_tjoWaZwBzkF1JEFMLbr4xteo=.d2f13bc0-e762-4df4-bcdd-e4bfb0a5fd97@github.com>
Message-ID: <B8sd6t_gWNm9lkNsniobq6SAhbw5QlaNAy8o318soVs=.bcb906ec-a770-4281-aa85-4baa5fa2a9d3@github.com>

On Mon, 29 Apr 2024 11:48:08 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Primarily offering this PR for discussion, as Throwables throwing exceptions on toString(), getLocalizedMessage(), or getMessage() seems like a rather unreasonable thing to do.
>> 
>> Nevertheless, there is some things we can do, as witnessed in this PR.
>
> src/java.base/share/classes/java/util/concurrent/CompletableFuture.java line 310:
> 
>> 308: 
>> 309:     static CompletionException wrapInCompletionException(Throwable t) {
>> 310:         if (t == null)
> 
> Is there any preexisting code path that ever passes a null? If not I don't think this check is necessary.

I opted to be more safe than sorry. Since this is on the failure-path it isn't performance critical so I think affording a null-check is fine.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18988#discussion_r1583299298

From vklang at openjdk.org  Fri May 10 14:42:23 2024
From: vklang at openjdk.org (Viktor Klang)
Date: Fri, 10 May 2024 14:42:23 GMT
Subject: RFR: 8312436: CompletableFuture never completes when
 'Throwable.toString()' method throws Exception
In-Reply-To: <BoZpCFbXi3qywnwUABBY426CQFolXZOv4Ny8diWY3a8=.357b8dfa-2373-4317-bbcc-a6036201451d@github.com>
References: <BoZpCFbXi3qywnwUABBY426CQFolXZOv4Ny8diWY3a8=.357b8dfa-2373-4317-bbcc-a6036201451d@github.com>
Message-ID: <NGG_2CpEOYb04ADSuBEEtjaVKwcY6TeGmj6wRB6W-ao=.67259362-9f6e-4c26-bcf2-3fe81833cd3f@github.com>

On Sun, 28 Apr 2024 09:54:34 GMT, Viktor Klang <vklang at openjdk.org> wrote:

> Primarily offering this PR for discussion, as Throwables throwing exceptions on toString(), getLocalizedMessage(), or getMessage() seems like a rather unreasonable thing to do.
> 
> Nevertheless, there is some things we can do, as witnessed in this PR.

src/java.base/share/classes/java/util/concurrent/CompletableFuture.java line 352:

> 350:         return wrapping;
> 351:     }
> 352: 

This is the main thing?and the big question is if this approach is the best path or not.

src/java.base/share/classes/java/util/concurrent/CompletableFuture.java line 2653:

> 2651:      * its completion state.  The state, in brackets, contains the
> 2652:      * String {@code "Completed normally"} or the String {@code
> 2653:      * "Completed exceptionally"}, or the String {@code "Not

These two looks like a discrepancy between spec and implementation, and it seemed safer to amend the spec rather than the implementation, as code might be relying on *actual behavior* rather than the spec:ed one.

@DougLea You might have some thoughts to offer on this :)

src/java.base/share/classes/java/util/concurrent/CompletableFuture.java line 2670:

> 2668:                 : "[Not completed, " + count + " dependents]")
> 2669:              : (((r instanceof AltResult) && ((AltResult)r).ex != null)
> 2670:                 ? "[Completed exceptionally: " + ((AltResult)r).ex.getClass().getName() + "]"

@DougLea @AlanBateman It seemed safer to switch to outputting the cause FQCN rather than wrapping in a try-catch and trying to come up with a fallback text.

The reason for amending this is for things like JShell, results are toString():ed which would mean that the current session would break if toString():ing the result throws (also further signalling that throwing on toString() seems unreasonable in general).

test/jdk/java/util/concurrent/tck/CompletableFutureTest.java line 87:

> 85:         // even if thrown exceptions end up throwing exceptions from their String
> 86:         // representations.
> 87:         @Override public String getMessage() {

I decided to do this to make sure that *all pre-existing test cases* would still work even if the exception used has a misbehaving toString() (toString() transitively calls getLocalizedMessage() which in turn calls getMessage())

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18988#discussion_r1582075756
PR Review Comment: https://git.openjdk.org/jdk/pull/18988#discussion_r1582075209
PR Review Comment: https://git.openjdk.org/jdk/pull/18988#discussion_r1582075561
PR Review Comment: https://git.openjdk.org/jdk/pull/18988#discussion_r1582075630

From mcimadamore at openjdk.org  Fri May 10 14:45:34 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 10 May 2024 14:45:34 GMT
Subject: RFR: 8332003: Clarify javadoc for MemoryLayout::offsetHandle [v3]
In-Reply-To: <0uMhIaW3d_IBqbF_04WhHDKHiIXes04wawSuxc6dQxI=.7f5621f9-0d77-4433-bc00-1ff8624b65da@github.com>
References: <0uMhIaW3d_IBqbF_04WhHDKHiIXes04wawSuxc6dQxI=.7f5621f9-0d77-4433-bc00-1ff8624b65da@github.com>
Message-ID: <CcC6IRxVPrPhHKdcP-zqWfMSZhQWpF-B6_NLVdTEdbw=.3a6241ef-ce7e-4c93-a0b7-91996c1555f5@github.com>

> Consider this layout:
> 
> 
> MemoryLayout SEQ = MemoryLayout.sequenceLayout(5,
>              MemoryLayout.sequenceLayout(10, JAVA_INT));
> 
> 
> And the corresponding offset handle:
> 
> 
> MethodHandle offsetHandle = SEQ.offsetHandle(PathElement.sequenceLayout(), PathElement.sequenceLayout());
> 
> 
> The resulting method handle takes two additional `long` indices. The implementation checks that the dynamically provided indices conform to the bound available at construction: that is, the first index must be < 5, while the second must be < 10. If this is not true, an `IndexOutOfBoundException` is thrown.
> 
> However, the javadoc for `MemoryLayout::byteOffsetHandle` doesn't claim anything in this direction. There are only some vague claims in the javadoc for `PathElement::sequenceElement()` and `PathElement::sequenceElement(long, long, long)` which make some claims on which indices are actually allowed, but the text seems more in the tone of a discussion, rather than actual normative text.
> 
> I've tweaked the javadoc for `MemoryLayout::byteOffsetHandle` to actually state that the indices will be checked against the "size" of the corresponding open path element (this is a new concept that I also have defined in the javadoc).
> 
> I also added a test for `byteOffsetHandle` as I don't think we had a test for that specifically (although this method is tested indirectly, via `MemoryLayout::varHandle`).

Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:

  Address review comments

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19158/files
  - new: https://git.openjdk.org/jdk/pull/19158/files/aa644d3d..aa77995c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19158&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19158&range=01-02

  Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/19158.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19158/head:pull/19158

PR: https://git.openjdk.org/jdk/pull/19158

From archie.cobbs at gmail.com  Fri May 10 14:57:19 2024
From: archie.cobbs at gmail.com (Archie Cobbs)
Date: Fri, 10 May 2024 09:57:19 -0500
Subject: Status of ZIP64 InputStream bug JDK-8298530?
In-Reply-To: <0224b528-9167-40c9-968d-e2c688769e44@gmail.com>
References: <20240509174013.A459D6604A7@dd33810.kasserver.com>
 <CANSoFxtKc=w9zy5TUFJDWpX7FhEVmzVVj1w9yZvV17F2ZUJbKA@mail.gmail.com>
 <0224b528-9167-40c9-968d-e2c688769e44@gmail.com>
Message-ID: <CANSoFxv+LaoHJ4Ra84fbp6t_jMx8Sn4MsFib1oFt3+9bcYiU9g@mail.gmail.com>

 Thanks for that reference.

I verified that when the fix in JDK-8303866 is reverted, this bug is
reproducible again.

So I've resolved JDK-8298530 as a duplicate of JDK-8303866.

-Archie

On Thu, May 9, 2024 at 9:51?PM Jaikiran Pai <jai.forums2013 at gmail.com>
wrote:

> I think this might have been addressed in mainline through
> https://bugs.openjdk.org/browse/JDK-8303866
>
> -Jaikiran
> On 09/05/24 11:39 pm, Archie Cobbs wrote:
>
> On Thu, May 9, 2024 at 12:43?PM Bernd Eckenfels <ecki at zusammenkunft.net>
> wrote:
>
>> But this one here is still open:
>>
>> * [JDK-8298530] ZipInputStream.readEnd fails for certain ZIP64 archives
>> with small files - Java Bug System (openjdk.org)
>> <https://bugs.openjdk.org/browse/JDK-8298530>
>>
> FWIW when I run the test case in that bug on the latest JDK 23
> (jdk-23+21-110-g0a4eeeaa3c6), it does not report any exception.
>
> So this bug may have gotten fixed by recent changes and just needs to be
> closed... ?
>
> -Archie
>
> --
> Archie L. Cobbs
>
>

-- 
Archie L. Cobbs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240510/52f915c9/attachment.htm>

From prappo at openjdk.org  Fri May 10 14:57:15 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Fri, 10 May 2024 14:57:15 GMT
Subject: RFR: 8305457: Implement java.io.IO [v7]
In-Reply-To: <qDUNtEpZzW7nx2tzrSvzxei_AbLxXwyKFGEMZk5OpxI=.1fcd778a-1d52-40e0-944b-8d1a26bd7c8e@github.com>
References: <w2msiw_qaMEIJS3s9D4bg8pFbz5WIF0KdP6Mm-XFjLI=.85b2020b-8c46-4bac-8a69-4975b068f2ff@github.com>
 <554HmRIAD_1Hf8Hbq6_YRH9iTf8fBk_OZ1XrlmSsQAU=.90c8b148-029a-429f-9037-179d9d30f6ad@github.com>
 <qDUNtEpZzW7nx2tzrSvzxei_AbLxXwyKFGEMZk5OpxI=.1fcd778a-1d52-40e0-944b-8d1a26bd7c8e@github.com>
Message-ID: <6ztBTdtAQJwnROJ5Q_B2Qrx8GflN4shNjcXTfpg0w_Y=.fbba516c-bc36-4b2b-8ae7-7ee3d4219674@github.com>

On Fri, 10 May 2024 07:45:02 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix System.console().readln(null) in jshell
>>   
>>   Without it, jshell hangs on me. Will think of a test.
>
> src/java.base/share/classes/jdk/internal/io/JdkConsoleImpl.java line 61:
> 
>> 59:     @Override
>> 60:     public JdkConsole println(Object obj) {
>> 61:         pw.println(obj);
> 
> Are these `println(...)` and `print(...)` methods intentionally not using a `writeLock` unlike the `readln(...)` and `readLine(...)` methods which do use (read and write) locks?

When implementing, I asked myself if I must use any of those monitors and decided that I don't have to. My reasoning is below.

`readLock`:

- is used inside the object that `Reader reader` is initialised with, and

- it also guards fields such as `char[] rcb`, `boolean restoreEcho` and `boolean shutdownHookInstalled`.

Since `println` and `print` don't call methods on `reader` or access the above fields, they don't require `readLock`.

`writeLock`:

- is used inside objects that `Writer out` and `PrintWriter pw` are initialised with, and
- also in compound operations that first write and then immediately read. (I assume, it's so that no concurrent write could sneak in between writing and reading parts of such a compound.)

`println` or `print` don't call methods on `out` and certainly don't do any write-read compounds. That said, they call methods on `pw`. But `pw` uses `writeLock` internally. So in that sense we're covered. 

One potential concern is a write-write compound in `print`:


    @Override
    public JdkConsole print(Object obj) {
        pw.print(obj);
        pw.flush(); // automatic flushing does not cover print
        return this;
    }


I'm saying write-_write_, not write-_flush_, because as far as synchronisation is concerned,  `pw.flush()` should behave the same as `pw.print("")`.

While not using `writeLock` is not strictly correct, I believe the potential execution interleavings with other writes are benign. What's the worst that could happen? You flush more than you expected? Big deal!

Since we exhausted all the reasons to use `writeLock`, I don't think we need one.



Naoto has already reviewed this PR with only minor comments. While that increases my confidence in that the implementation is correct, it doesn't hurt to request re-review of this specific part: @naotoj, do you think I should use any of those monitors?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19112#discussion_r1596861708

From prappo at openjdk.org  Fri May 10 15:00:32 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Fri, 10 May 2024 15:00:32 GMT
Subject: RFR: 8278255: Add more warning text in ReentrantLock and
 ReentrantReadWriteLock [v2]
In-Reply-To: <1YLryRpwC2JhbJQqVYfQ-dn2TMm42U3nV3Ad6p52Hr0=.b6659fe2-37ec-46fb-afeb-b06b611070d6@github.com>
References: <nb-F4YENhZMQth9RCQsvTAiiMEVnW-MKKJbe3NWWSgg=.86a1c9ab-c13b-4d37-8ef2-b495df14fa17@github.com>
 <ZjrjlUeRM-AtyH49lJMQPJkfad_MmEtWtS0n1gVPnkQ=.70f799bb-acb0-45ac-95c0-9001517128cd@github.com>
 <FbeaxqsS5SF9koVG-pHExVNRoWir-4kmJgu6VaOEt1g=.3ff0eff0-a80d-44b3-b955-63fcf3693912@github.com>
 <1YLryRpwC2JhbJQqVYfQ-dn2TMm42U3nV3Ad6p52Hr0=.b6659fe2-37ec-46fb-afeb-b06b611070d6@github.com>
Message-ID: <2pmCQPrMHH973XyQN6O14brIb6vhpYElrxBxVXZ7y3s=.66c649c3-b4de-4bf4-90f4-91f03766af66@github.com>

On Wed, 1 May 2024 10:03:25 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> The grammar rules prefer "that" because it is a restrictive clause, even though "which" might sound better.  See for example: https://owl.purdue.edu/owl/general_writing/grammar/that_vs_which.html
>
>> The grammar rules prefer "that" because it is a restrictive clause, even though "which" might sound better. See for example: https://owl.purdue.edu/owl/general_writing/grammar/that_vs_which.html
> 
> Thanks for that link, Doug.
> 
> I understand that two "that"s that are that close to each other might sound a bit weird. (Obviously, I exaggerated the issue in that preceding sentence.) Can we maybe rephrase it then?
> 
> 
>  *     // If code could throw, make sure that it is executed inside try block

> @pavelrappo Ok to integrate? ?

Oh, you shouldn't have waited for me. I think it's fine. Thanks!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18974#issuecomment-2104760009

From duke at openjdk.org  Fri May 10 15:03:12 2024
From: duke at openjdk.org (serhiysachkov)
Date: Fri, 10 May 2024 15:03:12 GMT
Subject: Integrated: 8331646: Add specific regression leap year tests
In-Reply-To: <cB-Q8ihe6DYQTm1WcRvVV3oW8YXtnWH5fmsS1zurwwY=.176d4137-bd3b-445e-a055-c738bd73744c@github.com>
References: <cB-Q8ihe6DYQTm1WcRvVV3oW8YXtnWH5fmsS1zurwwY=.176d4137-bd3b-445e-a055-c738bd73744c@github.com>
Message-ID: <BJiT1WcJzjUjTRslOnkuR5a3OPXksGWx5XS4CfU2jfo=.471541ad-91b2-4af7-bc7b-453fff02b1f1@github.com>

On Fri, 3 May 2024 10:31:14 GMT, serhiysachkov <duke at openjdk.org> wrote:

> Calendar.add() tests that describe its behavior.

This pull request has now been integrated.

Changeset: d11e70ad
Author:    Serhiy Sachkov <serhiy.sachkov at oracle.com>
Committer: Mahendra Chhipa <mchhipa at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/d11e70ade3e9094c8bef0074c736215d48d47a2a
Stats:     129 lines in 1 file changed: 129 ins; 0 del; 0 mod

8331646: Add specific regression leap year tests

Reviewed-by: naoto

-------------

PR: https://git.openjdk.org/jdk/pull/19082

From asotona at openjdk.org  Fri May 10 15:09:11 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Fri, 10 May 2024 15:09:11 GMT
Subject: RFR: 8331535: Incorrect prompt for Console.readLine [v5]
In-Reply-To: <WreObvEAFqvbblyLSjrc77L5PA3_TafnEQ4PfjmxbAM=.f73858dc-1502-4edc-8a89-7b7e91149b2f@github.com>
References: <IQvUAYG5zj0JqUbWiQiryAuBrtV6jrVCvy9useQZmlc=.a4dd8dfc-e835-4405-83f8-fd1bda8480f6@github.com>
 <WreObvEAFqvbblyLSjrc77L5PA3_TafnEQ4PfjmxbAM=.f73858dc-1502-4edc-8a89-7b7e91149b2f@github.com>
Message-ID: <gjOcQPKUvaSHVPF1aO732h5XXFC4X_tNod1RWJjDH-E=.57ae7f64-58c3-48a9-af1a-194d770f9ba6@github.com>

On Fri, 10 May 2024 11:00:55 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> When JLine reads a line, there may be a prompt provided. However, JLine will not interpret the prompt literally, it will handle `%` specially. As a consequence, doing:
>> 
>> System.console().readLine("%%s");
>> 
>> 
>> will not print `%s`, as first `String.format` is used, which will convert `%%s` to `%s`, and then JLine will interpret the `%`. The proposed solution is to duplicate the `%`, so that JLine will print it.
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixing the '%' prompt problem for JShell tools' console.

test/jdk/java/io/Console/ConsolePromptTest.java line 30:

> 28:  * @library /test/lib
> 29:  * @run main/othervm --limit-modules java.base ConsolePromptTest
> 30:  * @run main/othervm -Djdk.console=java.base java.base ConsolePromptTest

Suggestion:

 * @run main/othervm -Djdk.console=java.base ConsolePromptTest

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19081#discussion_r1596875588

From redestad at openjdk.org  Fri May 10 15:09:11 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Fri, 10 May 2024 15:09:11 GMT
Subject: RFR: 8327499: MethodHandleStatics.traceLambdaForm includes methods
 that cannot be generated [v2]
In-Reply-To: <9_0CEL0npofl2XsTW6q4wLhYYSHm6kH0cOqsFBGskSg=.371cc7a8-12db-4ca3-864c-1ae0efd6fc54@github.com>
References: <twyi1CnAbWs33Rd0KieD7bbXYRVL6lQgfZ4HqvAVrCQ=.003fcea0-799c-4ba7-a6a1-cf3d72c99cfb@github.com>
 <9_0CEL0npofl2XsTW6q4wLhYYSHm6kH0cOqsFBGskSg=.371cc7a8-12db-4ca3-864c-1ae0efd6fc54@github.com>
Message-ID: <_BEqWs4Iy2fB8bngQSjDbGa0giVNGYgVo5hXbOWnl4Y=.8cd481d5-9d35-4504-a09a-e16b66c7ac89@github.com>

On Fri, 10 May 2024 04:55:21 GMT, Chen Liang <liach at openjdk.org> wrote:

>> GenerateJLIClassesHelper has been making wrong assumptions about Invoker's LambdaForm method type parameters. Since they are distinct from those of Linkers, they are now tracked and generated separately. It seems that no proper invoker was ever generated before, except it happens that most invoker signatures can be taken as linker signature so we never detected it.
>> 
>> Requesting @iklam for a review; since I don't know how to deal with CDS, I have to relay to someone else to ensure this fixes the problem from the CDS side as well.
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add CDS test case to ensure LF resolution success

Code changes and jdk tests looks good to me.

-------------

Marked as reviewed by redestad (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19164#pullrequestreview-2050282503

From mcimadamore at openjdk.org  Fri May 10 15:23:32 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 10 May 2024 15:23:32 GMT
Subject: RFR: 8332003: Clarify javadoc for MemoryLayout::offsetHandle [v4]
In-Reply-To: <0uMhIaW3d_IBqbF_04WhHDKHiIXes04wawSuxc6dQxI=.7f5621f9-0d77-4433-bc00-1ff8624b65da@github.com>
References: <0uMhIaW3d_IBqbF_04WhHDKHiIXes04wawSuxc6dQxI=.7f5621f9-0d77-4433-bc00-1ff8624b65da@github.com>
Message-ID: <sEPTLF5aD4xAdI2B31qYJOCK5Gh7Jy4VrywarESakHE=.b012a962-e0c6-4d6a-a587-bd85d1be5122@github.com>

> Consider this layout:
> 
> 
> MemoryLayout SEQ = MemoryLayout.sequenceLayout(5,
>              MemoryLayout.sequenceLayout(10, JAVA_INT));
> 
> 
> And the corresponding offset handle:
> 
> 
> MethodHandle offsetHandle = SEQ.offsetHandle(PathElement.sequenceLayout(), PathElement.sequenceLayout());
> 
> 
> The resulting method handle takes two additional `long` indices. The implementation checks that the dynamically provided indices conform to the bound available at construction: that is, the first index must be < 5, while the second must be < 10. If this is not true, an `IndexOutOfBoundException` is thrown.
> 
> However, the javadoc for `MemoryLayout::byteOffsetHandle` doesn't claim anything in this direction. There are only some vague claims in the javadoc for `PathElement::sequenceElement()` and `PathElement::sequenceElement(long, long, long)` which make some claims on which indices are actually allowed, but the text seems more in the tone of a discussion, rather than actual normative text.
> 
> I've tweaked the javadoc for `MemoryLayout::byteOffsetHandle` to actually state that the indices will be checked against the "size" of the corresponding open path element (this is a new concept that I also have defined in the javadoc).
> 
> I also added a test for `byteOffsetHandle` as I don't think we had a test for that specifically (although this method is tested indirectly, via `MemoryLayout::varHandle`).

Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:

  Replace > 0 with >= 0

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19158/files
  - new: https://git.openjdk.org/jdk/pull/19158/files/aa77995c..d46387a7

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19158&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19158&range=02-03

  Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/19158.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19158/head:pull/19158

PR: https://git.openjdk.org/jdk/pull/19158

From rriggs at openjdk.org  Fri May 10 15:26:19 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 10 May 2024 15:26:19 GMT
Subject: RFR: 8331646: Add specific regression leap year tests [v5]
In-Reply-To: <jJs8KXZecYkvsiziGW2K2mm7jhnBZItqp_fq-VrWVB4=.e4a6beb0-133c-440b-a53f-11473a27003c@github.com>
References: <cB-Q8ihe6DYQTm1WcRvVV3oW8YXtnWH5fmsS1zurwwY=.176d4137-bd3b-445e-a055-c738bd73744c@github.com>
 <jJs8KXZecYkvsiziGW2K2mm7jhnBZItqp_fq-VrWVB4=.e4a6beb0-133c-440b-a53f-11473a27003c@github.com>
Message-ID: <cbrYaKyIIx5kUCY9z5JK5a658BXXCZedI2HCO6ge_3c=.a7f43162-c2f7-43bb-8ec7-bc00cf4c79fc@github.com>

On Fri, 10 May 2024 09:22:39 GMT, serhiysachkov <duke at openjdk.org> wrote:

>> Calendar.add() tests that describe its behavior.
>
> serhiysachkov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   JDK-8331646 fixing typo

A bit late but the descriptions of the problem should not be focused on leap years. 
Every add/subtract that involves indefinite month lengths has the same behavior when the result is clamped to the length of the month.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19082#issuecomment-2104799803

From jlahoda at openjdk.org  Fri May 10 15:34:27 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Fri, 10 May 2024 15:34:27 GMT
Subject: RFR: 8331535: Incorrect prompt for Console.readLine [v6]
In-Reply-To: <IQvUAYG5zj0JqUbWiQiryAuBrtV6jrVCvy9useQZmlc=.a4dd8dfc-e835-4405-83f8-fd1bda8480f6@github.com>
References: <IQvUAYG5zj0JqUbWiQiryAuBrtV6jrVCvy9useQZmlc=.a4dd8dfc-e835-4405-83f8-fd1bda8480f6@github.com>
Message-ID: <SM5z0EXCWQaQUP4ug3zg6piECoA9He1YTMxgnNBVLTk=.278a876f-b9eb-4eea-b89d-e53d3ca718ea@github.com>

> When JLine reads a line, there may be a prompt provided. However, JLine will not interpret the prompt literally, it will handle `%` specially. As a consequence, doing:
> 
> System.console().readLine("%%s");
> 
> 
> will not print `%s`, as first `String.format` is used, which will convert `%%s` to `%s`, and then JLine will interpret the `%`. The proposed solution is to duplicate the `%`, so that JLine will print it.

Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:

  Update test/jdk/java/io/Console/ConsolePromptTest.java
  
  Co-authored-by: Adam Sotona <10807609+asotona at users.noreply.github.com>

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19081/files
  - new: https://git.openjdk.org/jdk/pull/19081/files/da84810f..441bdad8

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19081&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19081&range=04-05

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/19081.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19081/head:pull/19081

PR: https://git.openjdk.org/jdk/pull/19081

From asotona at openjdk.org  Fri May 10 15:34:27 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Fri, 10 May 2024 15:34:27 GMT
Subject: RFR: 8331535: Incorrect prompt for Console.readLine [v6]
In-Reply-To: <SM5z0EXCWQaQUP4ug3zg6piECoA9He1YTMxgnNBVLTk=.278a876f-b9eb-4eea-b89d-e53d3ca718ea@github.com>
References: <IQvUAYG5zj0JqUbWiQiryAuBrtV6jrVCvy9useQZmlc=.a4dd8dfc-e835-4405-83f8-fd1bda8480f6@github.com>
 <SM5z0EXCWQaQUP4ug3zg6piECoA9He1YTMxgnNBVLTk=.278a876f-b9eb-4eea-b89d-e53d3ca718ea@github.com>
Message-ID: <qH1jZckpU9hXkUvYW5doTmDlgQuq3nG5u2EMDReuhqk=.f2ac2d33-abd2-48ef-9213-4d5399e08149@github.com>

On Fri, 10 May 2024 15:32:07 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> When JLine reads a line, there may be a prompt provided. However, JLine will not interpret the prompt literally, it will handle `%` specially. As a consequence, doing:
>> 
>> System.console().readLine("%%s");
>> 
>> 
>> will not print `%s`, as first `String.format` is used, which will convert `%%s` to `%s`, and then JLine will interpret the `%`. The proposed solution is to duplicate the `%`, so that JLine will print it.
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update test/jdk/java/io/Console/ConsolePromptTest.java
>   
>   Co-authored-by: Adam Sotona <10807609+asotona at users.noreply.github.com>

Looks good to me.

-------------

Marked as reviewed by asotona (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19081#pullrequestreview-2050327444

From jjg at openjdk.org  Fri May 10 15:52:03 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Fri, 10 May 2024 15:52:03 GMT
Subject: RFR: 8331879: Clean up non-standard use of /// comments in
 `java.base`
In-Reply-To: <JKCovwpov4A3Uddzf6N0AnZSb3Znv-7MEfMGec6IhR4=.93e4ad8e-344b-4890-8f25-c2752287024c@github.com>
References: <JKCovwpov4A3Uddzf6N0AnZSb3Znv-7MEfMGec6IhR4=.93e4ad8e-344b-4890-8f25-c2752287024c@github.com>
Message-ID: <2XFqovH5heRab6H6eAxp-GSxBKq6LlIZ3w2MlD5-LEw=.28c84943-b484-41c5-bfa6-fa7dd7244732@github.com>

On Thu, 9 May 2024 02:09:50 GMT, xiaotaonan <duke at openjdk.org> wrote:

> Clean up non-standard use of /// comments in `java.base`

This PR is premature.
Until JEP 467 is integrated, there is nothing special about `///` comments, and the compiler does not report on non-standard use.

There is a Draft PR for this issue ready to go once JEP 467 has been integrated, that addresses all necessary comments in `java.base`.
https://github.com/openjdk/jdk/pull/19130

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19151#issuecomment-2104836545

From prappo at openjdk.org  Fri May 10 15:58:16 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Fri, 10 May 2024 15:58:16 GMT
Subject: RFR: 8278255: Add more warning text in ReentrantLock and
 ReentrantReadWriteLock [v2]
In-Reply-To: <ZjrjlUeRM-AtyH49lJMQPJkfad_MmEtWtS0n1gVPnkQ=.70f799bb-acb0-45ac-95c0-9001517128cd@github.com>
References: <nb-F4YENhZMQth9RCQsvTAiiMEVnW-MKKJbe3NWWSgg=.86a1c9ab-c13b-4d37-8ef2-b495df14fa17@github.com>
 <ZjrjlUeRM-AtyH49lJMQPJkfad_MmEtWtS0n1gVPnkQ=.70f799bb-acb0-45ac-95c0-9001517128cd@github.com>
Message-ID: <v9TSmO3m6CU8aLHbOBVhL7HmKov547IZIuvh-0D2O-s=.09a73628-e4ee-42b2-8bf4-e140f1801151@github.com>

On Sat, 27 Apr 2024 11:52:18 GMT, Viktor Klang <vklang at openjdk.org> wrote:

>> This is an attempt to be more clear about recommendations on Lock usage.
>
> Viktor Klang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update src/java.base/share/classes/java/util/concurrent/locks/ReentrantReadWriteLock.java
>   
>   Co-authored-by: Pavel Rappo <32523691+pavelrappo at users.noreply.github.com>

Marked as reviewed by prappo (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/18974#pullrequestreview-2050367663

From mcimadamore at openjdk.org  Fri May 10 16:10:29 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 10 May 2024 16:10:29 GMT
Subject: RFR: 8332003: Clarify javadoc for MemoryLayout::offsetHandle [v5]
In-Reply-To: <0uMhIaW3d_IBqbF_04WhHDKHiIXes04wawSuxc6dQxI=.7f5621f9-0d77-4433-bc00-1ff8624b65da@github.com>
References: <0uMhIaW3d_IBqbF_04WhHDKHiIXes04wawSuxc6dQxI=.7f5621f9-0d77-4433-bc00-1ff8624b65da@github.com>
Message-ID: <L0oTIMzvY-1mTlF88iA3AiB-ToeyFVmH1CEPDApit0Q=.159a1db2-3abc-4615-a01d-3401fe5ac57e@github.com>

> Consider this layout:
> 
> 
> MemoryLayout SEQ = MemoryLayout.sequenceLayout(5,
>              MemoryLayout.sequenceLayout(10, JAVA_INT));
> 
> 
> And the corresponding offset handle:
> 
> 
> MethodHandle offsetHandle = SEQ.offsetHandle(PathElement.sequenceLayout(), PathElement.sequenceLayout());
> 
> 
> The resulting method handle takes two additional `long` indices. The implementation checks that the dynamically provided indices conform to the bound available at construction: that is, the first index must be < 5, while the second must be < 10. If this is not true, an `IndexOutOfBoundException` is thrown.
> 
> However, the javadoc for `MemoryLayout::byteOffsetHandle` doesn't claim anything in this direction. There are only some vague claims in the javadoc for `PathElement::sequenceElement()` and `PathElement::sequenceElement(long, long, long)` which make some claims on which indices are actually allowed, but the text seems more in the tone of a discussion, rather than actual normative text.
> 
> I've tweaked the javadoc for `MemoryLayout::byteOffsetHandle` to actually state that the indices will be checked against the "size" of the corresponding open path element (this is a new concept that I also have defined in the javadoc).
> 
> I also added a test for `byteOffsetHandle` as I don't think we had a test for that specifically (although this method is tested indirectly, via `MemoryLayout::varHandle`).

Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:

  Fix another index check

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19158/files
  - new: https://git.openjdk.org/jdk/pull/19158/files/d46387a7..629000d1

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19158&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19158&range=03-04

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/19158.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19158/head:pull/19158

PR: https://git.openjdk.org/jdk/pull/19158

From naoto at openjdk.org  Fri May 10 16:13:14 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 10 May 2024 16:13:14 GMT
Subject: Integrated: 8331866: Add warnings for locale data dependence
In-Reply-To: <d1V8q3oaeh-cPvR_IE22WAHhoqrc1TXZMdEtIhxCLvM=.af6edbc8-49c1-4125-930d-42580dcb40c3@github.com>
References: <d1V8q3oaeh-cPvR_IE22WAHhoqrc1TXZMdEtIhxCLvM=.af6edbc8-49c1-4125-930d-42580dcb40c3@github.com>
Message-ID: <uZJvK0ZnWQpWQEWeBuzLk8EDxxTbcHRD4qfFzqI0Dt4=.401fdcf3-09c4-4633-ac27-ee397145e16a@github.com>

On Wed, 8 May 2024 20:21:50 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> In order to enlighten users to not depend on a particular version of the locale data, putting a note into the JDK vs. CLDR version chart would be appropriate.

This pull request has now been integrated.

Changeset: 65abf24f
Author:    Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/65abf24fde6432fb386a616bbadc5689975c3bf4
Stats:     6 lines in 1 file changed: 5 ins; 0 del; 1 mod

8331866: Add warnings for locale data dependence

Reviewed-by: jlu, srl, joehw

-------------

PR: https://git.openjdk.org/jdk/pull/19145

From djelinski at openjdk.org  Fri May 10 16:16:18 2024
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Fri, 10 May 2024 16:16:18 GMT
Subject: RFR: 8331907: BigInteger and BigDecimal should use optimized
 division [v4]
In-Reply-To: <-U6_9J-If3E3P3j4y7kt2yTCdNLvKkTSPrK0FxhNM80=.07321109-402b-4d28-9788-ddd52f42467d@github.com>
References: <-U6_9J-If3E3P3j4y7kt2yTCdNLvKkTSPrK0FxhNM80=.07321109-402b-4d28-9788-ddd52f42467d@github.com>
Message-ID: <m4XJ3ObwoIyBx0oeuRUGPqEjs54Gkq1ApUAGbmnFt8A=.f5c15f1a-4bdd-4904-ac2d-48dbefbb85a8@github.com>

> Replace the custom unsigned divide / remainder functions with the compiler-optimized Long.divideUnsigned / remainderUnsigned.
> 
> No new tests. Existing tier1-3 tests continue to pass.
> 
> I added a new set of divide benchmarks. Results in thread.
> 
> I also removed the BigDecimal.toString benchmarks. They no longer serve their purpose - toString caches the returned value, so we were only benchmarking the cache access time.

Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision:

  Integer divide

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19134/files
  - new: https://git.openjdk.org/jdk/pull/19134/files/83a9959a..ec680946

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19134&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19134&range=02-03

  Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/19134.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19134/head:pull/19134

PR: https://git.openjdk.org/jdk/pull/19134

From mcimadamore at openjdk.org  Fri May 10 16:20:07 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 10 May 2024 16:20:07 GMT
Subject: RFR: 8331734: Atomic MemorySegment VarHandle operations fails for
 element layouts [v3]
In-Reply-To: <H0JpXT64BN4DgCUyO7EWlpkUPlpAINy-uUoYJbXx2ic=.33265d43-6ffe-44d5-a456-52daeb68ea27@github.com>
References: <_PQ4wP4lk_STKwnSddD-5GgfsCheLbT_MR9zIyQyE78=.4ae37fdc-cf6e-46ea-8dbe-afcd1e710666@github.com>
 <H0JpXT64BN4DgCUyO7EWlpkUPlpAINy-uUoYJbXx2ic=.33265d43-6ffe-44d5-a456-52daeb68ea27@github.com>
Message-ID: <cxS2l7j5elJQku94RNYWly7yILaXp5hjgoLKtGStF8A=.4da4c35a-1503-44d0-8c58-8ec01d888b5f@github.com>

On Wed, 8 May 2024 16:39:16 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This PR fixes an issue that has crept into the FFM API implementation.
>> 
>> From very early stages, the FFM API used to disable the alignment check on nested layout elements, in favor of an alignment check against the memory segment base address. The rationale was that the JIT had issue with eliminating redundant alignment checks, and accessing nested elements could never result in alignment issues, since the alignment of the container is provably bigger than that of the contained element. This means that, when creating a var handle for a nested layout element, we set the nested layout alignment to 1 (unaligned), derive its var handle, and then decorate the var handle with an alignment check for the container.
>> 
>> At some point in 22, we tweaked the API to throw `UnsupportedOperationException` when using an access mode incompatible with the alignment constraint of the accessed layout. That is, a volatile read on an `int` is only possible if the access occurs at an address that is at least 4-byte aligned. Otherwise an `UOE` is thrown.
>> 
>> Unfortunately this change broke the aforementioned optimization: creating a var handle for an unaligned layout works, but the resulting layout will *not* support any of the atomic access modes.
>> 
>> Since this optimization is not really required anymore (proper C2 support to hoist/eliminate alignment checks has been added since then), it is better to disable this implementation quirk, and leave optimizations to C2.
>> 
>> (If we really really wanted to optimize things a bit, we could remove the container alignment check in the case the accessed value is the first layout element nested in the container, but this PR doesn't go that far).
>> 
>> I've run relevant benchmarks before/after and found no differences. In part this is because `arrayElementVarHandle` is unaffected. But, even after tweaking the `LoopOverNonConstant` benchmark to add explicit tests for the code path affected, no significant difference was found, sign that C2 is indeed able to spot (and remove) the redundant alignment check. Note: if we know that `aligned_to_N(base)` holds, then it's easy to prove that `aligned_to_M(base + offset + index * scale)` holds, when `N >= M` and with `offset` and `scale` known (the latter a power of two).
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add benchmark anno

I've decided to integrate this for now, as the fix in this PR restores correctness of the implementation.
I will investigate follow up improvements and enhancements separately:
https://bugs.openjdk.org/browse/JDK-8331865

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19124#issuecomment-2104879150

From bpb at openjdk.org  Fri May 10 16:23:03 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 10 May 2024 16:23:03 GMT
Subject: RFR: 8332064: Implementation of Structured Concurrency (Third
 Preview)
In-Reply-To: <YKVRqYuGwAB4cPvyVacCBrrMlS-m5K1fJSGpe7hQ744=.da388230-47ff-4097-9f9c-7d590bddcb8b@github.com>
References: <YKVRqYuGwAB4cPvyVacCBrrMlS-m5K1fJSGpe7hQ744=.da388230-47ff-4097-9f9c-7d590bddcb8b@github.com>
Message-ID: <pOXd4UAJNTbRxfK9w-6Rh9LUl-HXldwQ4fi97ea39wE=.88cf64ef-11b4-411f-a2d0-4cd259dcc368@github.com>

On Fri, 10 May 2024 10:58:42 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> There aren't any API or implementations changes in third preview but the JEP number/title needs to be bumped for the javadoc page.

Marked as reviewed by bpb (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/19175#pullrequestreview-2050415510

From mcimadamore at openjdk.org  Fri May 10 16:25:11 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 10 May 2024 16:25:11 GMT
Subject: Integrated: 8331734: Atomic MemorySegment VarHandle operations fails
 for element layouts
In-Reply-To: <_PQ4wP4lk_STKwnSddD-5GgfsCheLbT_MR9zIyQyE78=.4ae37fdc-cf6e-46ea-8dbe-afcd1e710666@github.com>
References: <_PQ4wP4lk_STKwnSddD-5GgfsCheLbT_MR9zIyQyE78=.4ae37fdc-cf6e-46ea-8dbe-afcd1e710666@github.com>
Message-ID: <hHkOu--_aB7xYeIxkLCkFvBZ8Waw5ni0SjmCuw9CTCc=.802c603c-c325-4819-b00c-9f0ddbbd5977@github.com>

On Tue, 7 May 2024 15:42:23 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> This PR fixes an issue that has crept into the FFM API implementation.
> 
> From very early stages, the FFM API used to disable the alignment check on nested layout elements, in favor of an alignment check against the memory segment base address. The rationale was that the JIT had issue with eliminating redundant alignment checks, and accessing nested elements could never result in alignment issues, since the alignment of the container is provably bigger than that of the contained element. This means that, when creating a var handle for a nested layout element, we set the nested layout alignment to 1 (unaligned), derive its var handle, and then decorate the var handle with an alignment check for the container.
> 
> At some point in 22, we tweaked the API to throw `UnsupportedOperationException` when using an access mode incompatible with the alignment constraint of the accessed layout. That is, a volatile read on an `int` is only possible if the access occurs at an address that is at least 4-byte aligned. Otherwise an `UOE` is thrown.
> 
> Unfortunately this change broke the aforementioned optimization: creating a var handle for an unaligned layout works, but the resulting layout will *not* support any of the atomic access modes.
> 
> Since this optimization is not really required anymore (proper C2 support to hoist/eliminate alignment checks has been added since then), it is better to disable this implementation quirk, and leave optimizations to C2.
> 
> (If we really really wanted to optimize things a bit, we could remove the container alignment check in the case the accessed value is the first layout element nested in the container, but this PR doesn't go that far).
> 
> I've run relevant benchmarks before/after and found no differences. In part this is because `arrayElementVarHandle` is unaffected. But, even after tweaking the `LoopOverNonConstant` benchmark to add explicit tests for the code path affected, no significant difference was found, sign that C2 is indeed able to spot (and remove) the redundant alignment check. Note: if we know that `aligned_to_N(base)` holds, then it's easy to prove that `aligned_to_M(base + offset + index * scale)` holds, when `N >= M` and with `offset` and `scale` known (the latter a power of two).

This pull request has now been integrated.

Changeset: 1c5f1501
Author:    Maurizio Cimadamore <mcimadamore at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/1c5f1501ac4ef55ca6ffaaa0576de9b0e1dd8d06
Stats:     56 lines in 3 files changed: 41 ins; 7 del; 8 mod

8331734: Atomic MemorySegment VarHandle operations fails for element layouts

Reviewed-by: pminborg, psandoz

-------------

PR: https://git.openjdk.org/jdk/pull/19124

From bpb at openjdk.org  Fri May 10 16:27:03 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 10 May 2024 16:27:03 GMT
Subject: RFR: 8332029: Provide access to initial value of stderr via
 JavaLangAccess
In-Reply-To: <kPZZ3bMLJ-gEnr9NMQ0TaybDkcM15gP0YUDFCdWYxbA=.558291dd-740b-4807-bf63-e7f6d706d0e8@github.com>
References: <kPZZ3bMLJ-gEnr9NMQ0TaybDkcM15gP0YUDFCdWYxbA=.558291dd-740b-4807-bf63-e7f6d706d0e8@github.com>
Message-ID: <WhQCBOJTiGiGprJkO3cWDPYGPxfBxW6YOcWvAs-UD8M=.ec8bdd04-8c03-403d-b630-65237df4c7c4@github.com>

On Fri, 10 May 2024 07:57:40 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> In preparation for JEP 471 and JEP 472, provide access to the initial value of System.err from JavaLangAccess. The initial value of System.in is already exposed to code in java.base with this shared secret.

+1

-------------

Marked as reviewed by bpb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19171#pullrequestreview-2050422897

From naoto at openjdk.org  Fri May 10 16:44:12 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 10 May 2024 16:44:12 GMT
Subject: RFR: 8305457: Implement java.io.IO [v7]
In-Reply-To: <6ztBTdtAQJwnROJ5Q_B2Qrx8GflN4shNjcXTfpg0w_Y=.fbba516c-bc36-4b2b-8ae7-7ee3d4219674@github.com>
References: <w2msiw_qaMEIJS3s9D4bg8pFbz5WIF0KdP6Mm-XFjLI=.85b2020b-8c46-4bac-8a69-4975b068f2ff@github.com>
 <554HmRIAD_1Hf8Hbq6_YRH9iTf8fBk_OZ1XrlmSsQAU=.90c8b148-029a-429f-9037-179d9d30f6ad@github.com>
 <qDUNtEpZzW7nx2tzrSvzxei_AbLxXwyKFGEMZk5OpxI=.1fcd778a-1d52-40e0-944b-8d1a26bd7c8e@github.com>
 <6ztBTdtAQJwnROJ5Q_B2Qrx8GflN4shNjcXTfpg0w_Y=.fbba516c-bc36-4b2b-8ae7-7ee3d4219674@github.com>
Message-ID: <t25BDNnhk-6FuZwRF_6j3xNfkNGdNMeAcZdhGbaTW_k=.630978f0-9f05-462d-a97c-dbb57d26c936@github.com>

On Fri, 10 May 2024 14:54:10 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/io/JdkConsoleImpl.java line 61:
>> 
>>> 59:     @Override
>>> 60:     public JdkConsole println(Object obj) {
>>> 61:         pw.println(obj);
>> 
>> Are these `println(...)` and `print(...)` methods intentionally not using a `writeLock` unlike the `readln(...)` and `readLine(...)` methods which do use (read and write) locks?
>
> When implementing, I asked myself if I must use any of those monitors and decided that I don't have to. My reasoning is below.
> 
> `readLock`:
> 
> - is used inside the object that `Reader reader` is initialised with, and
> 
> - it also guards fields such as `char[] rcb`, `boolean restoreEcho` and `boolean shutdownHookInstalled`.
> 
> Since `println` and `print` don't call methods on `reader` or access the above fields, they don't require `readLock`.
> 
> `writeLock`:
> 
> - is used inside objects that `Writer out` and `PrintWriter pw` are initialised with, and
> - also in compound operations that first write and then immediately read. (I assume, it's so that no concurrent write could sneak in between writing and reading parts of such a compound.)
> 
> `println` or `print` don't call methods on `out` and certainly don't do any write-read compounds. That said, they call methods on `pw`. But `pw` uses `writeLock` internally. So in that sense we're covered. 
> 
> One potential concern is a write-write compound in `print`:
> 
> 
>     @Override
>     public JdkConsole print(Object obj) {
>         pw.print(obj);
>         pw.flush(); // automatic flushing does not cover print
>         return this;
>     }
> 
> 
> I'm saying write-_write_, not write-_flush_, because as far as synchronisation is concerned,  `pw.flush()` should behave the same as `pw.print("")`.
> 
> While not using `writeLock` is not strictly correct, I believe the potential execution interleavings with other writes are benign. What's the worst that could happen? You flush more than you expected? Big deal!
> 
> Since we exhausted all the reasons to use `writeLock`, I don't think we need one.
> 
> 
> 
> Naoto has already reviewed this PR with only minor comments. While that increases my confidence in that the implementation is correct, it doesn't hurt to request re-review of this specific part: @naotoj, do you think I should use any of those monitors?

I think your investigation is correct. As to the write-write case, there already is the same pattern in (`formatter` basically utilizes `pw` underneath) 

    public JdkConsole format(String fmt, Object ... args) {
        formatter.format(fmt, args).flush();
        return this;
    }

So I think it is acceptable.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19112#discussion_r1596976499

From rgiulietti at openjdk.org  Fri May 10 16:47:04 2024
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Fri, 10 May 2024 16:47:04 GMT
Subject: RFR: 8331907: BigInteger and BigDecimal should use optimized
 division [v4]
In-Reply-To: <m4XJ3ObwoIyBx0oeuRUGPqEjs54Gkq1ApUAGbmnFt8A=.f5c15f1a-4bdd-4904-ac2d-48dbefbb85a8@github.com>
References: <-U6_9J-If3E3P3j4y7kt2yTCdNLvKkTSPrK0FxhNM80=.07321109-402b-4d28-9788-ddd52f42467d@github.com>
 <m4XJ3ObwoIyBx0oeuRUGPqEjs54Gkq1ApUAGbmnFt8A=.f5c15f1a-4bdd-4904-ac2d-48dbefbb85a8@github.com>
Message-ID: <q1PKjqeeGv7ArX1wZgFiQeL96OK8WY5UFseW8OPHHew=.ff9f5dfc-4772-4289-9790-877701b25e49@github.com>

On Fri, 10 May 2024 16:16:18 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> Replace the custom unsigned divide / remainder functions with the compiler-optimized Long.divideUnsigned / remainderUnsigned.
>> 
>> No new tests. Existing tier1-3 tests continue to pass.
>> 
>> I added a new set of divide benchmarks. Results in thread.
>> 
>> I also removed the BigDecimal.toString benchmarks. They no longer serve their purpose - toString caches the returned value, so we were only benchmarking the cache access time.
>
> Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Integer divide

LGTM

-------------

Marked as reviewed by rgiulietti (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19134#pullrequestreview-2050461848

From mcimadamore at openjdk.org  Fri May 10 17:03:06 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 10 May 2024 17:03:06 GMT
Subject: RFR: 8332064: Implementation of Structured Concurrency (Third
 Preview)
In-Reply-To: <YKVRqYuGwAB4cPvyVacCBrrMlS-m5K1fJSGpe7hQ744=.da388230-47ff-4097-9f9c-7d590bddcb8b@github.com>
References: <YKVRqYuGwAB4cPvyVacCBrrMlS-m5K1fJSGpe7hQ744=.da388230-47ff-4097-9f9c-7d590bddcb8b@github.com>
Message-ID: <WQLM3bcyJX4WsR5CjQWkp1buZbVtREybkHtd25wpQzc=.b73152cd-8e41-471f-9055-3acc2553e521@github.com>

On Fri, 10 May 2024 10:58:42 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> There aren't any API or implementations changes in third preview but the JEP number/title needs to be bumped for the javadoc page.

Marked as reviewed by mcimadamore (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/19175#pullrequestreview-2050495714

From mcimadamore at openjdk.org  Fri May 10 17:04:06 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 10 May 2024 17:04:06 GMT
Subject: RFR: 8332029: Provide access to initial value of stderr via
 JavaLangAccess
In-Reply-To: <kPZZ3bMLJ-gEnr9NMQ0TaybDkcM15gP0YUDFCdWYxbA=.558291dd-740b-4807-bf63-e7f6d706d0e8@github.com>
References: <kPZZ3bMLJ-gEnr9NMQ0TaybDkcM15gP0YUDFCdWYxbA=.558291dd-740b-4807-bf63-e7f6d706d0e8@github.com>
Message-ID: <mOKGGQjqZLElkAIsFmxWEYF5dg7yQCgyORKpuRwZIpo=.af0ad170-0357-476d-a11e-fdca6dd7a025@github.com>

On Fri, 10 May 2024 07:57:40 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> In preparation for JEP 471 and JEP 472, provide access to the initial value of System.err from JavaLangAccess. The initial value of System.in is already exposed to code in java.base with this shared secret.

Marked as reviewed by mcimadamore (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/19171#pullrequestreview-2050499139

From hboehm at google.com  Fri May 10 17:54:40 2024
From: hboehm at google.com (Hans Boehm)
Date: Fri, 10 May 2024 10:54:40 -0700
Subject: RFR: 8314480: Memory ordering spec updates in java.lang.ref [v31]
In-Reply-To: <aUZHna4VBbB2ClvbJsoTwojkQfCE8-l2z9BDQaXHAIs=.8197a754-5559-4653-820f-ad9d92f72316@github.com>
References: <R74ontYwjYg6HeZY0cWrlo0amjl4E1YsFWeuh4pda14=.08ac62df-b2f8-4b4d-b338-07adb289601b@github.com>
 <aUZHna4VBbB2ClvbJsoTwojkQfCE8-l2z9BDQaXHAIs=.8197a754-5559-4653-820f-ad9d92f72316@github.com>
Message-ID: <CAMOCf+ikSQcqWjibB-==73qNZ_y_a8CZ7HWhifjqbN8ENOEu6w@mail.gmail.com>

I'm not convinced this helps.

The isAlive() spec says:

"A thread is alive if it has been started and has not yet terminated."

Clearly an object is reachable if it can be accessed by a thread that will
be started in the future. Is that part of a "potential continuing
computation from any live thread"?

I think the JLS wording is a bit sloppy about what "live thread" means
here. And that sloppiness is probably better than pointing at a precise
definition that I'm not sure really applies. "in any potential continuing
computation from any live thread" really seems to mean something like "in
any continuing computation in which no finalizers are run"?

Even if the object is later accessed from an existing "live" thread, it
should not be considered reachable if that happens only after a finalizer
later makes it reachable again. So I don't see why the thread from which
the access happens matters at all.

Hans

On Thu, May 9, 2024 at 11:44?AM Brent Christian <bchristi at openjdk.org>
wrote:

> > Classes in the `java.lang.ref` package would benefit from an update to
> bring the spec in line with how the VM already behaves. The changes would
> focus on _happens-before_ edges at some key points during reference
> processing.
> >
> > A couple key things we want to be able to say are:
> > - `Reference.reachabilityFence(x)` _happens-before_ reference processing
> occurs for 'x'.
> > - `Cleaner.register()` _happens-before_ the Cleaner thread runs the
> registered cleaning action.
> >
> > This will bring Cleaner in line (or close) with the memory visibility
> guarantees made for finalizers in [JLS 17.4.5](
> https://docs.oracle.com/javase/specs/jls/se18/html/jls-17.html#jls-17.4.5
> ):
> > _"There is a happens-before edge from the end of a constructor of an
> object to the start of a finalizer (?12.6) for that object."_
>
> Brent Christian has updated the pull request incrementally with one
> additional commit since the last revision:
>
>   add link to Thread.isAlive()
>
> -------------
>
> Changes:
>   - all: https://git.openjdk.org/jdk/pull/16644/files
>   - new: https://git.openjdk.org/jdk/pull/16644/files/5db47889..4efa5d18
>
> Webrevs:
>  - full: https://webrevs.openjdk.org/?repo=jdk&pr=16644&range=30
>  - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16644&range=29-30
>
>   Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod
>   Patch: https://git.openjdk.org/jdk/pull/16644.diff
>   Fetch: git fetch https://git.openjdk.org/jdk.git
> pull/16644/head:pull/16644
>
> PR: https://git.openjdk.org/jdk/pull/16644
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240510/59fbaa88/attachment.htm>

From psandoz at openjdk.org  Fri May 10 19:55:03 2024
From: psandoz at openjdk.org (Paul Sandoz)
Date: Fri, 10 May 2024 19:55:03 GMT
Subject: RFR: 8332003: Clarify javadoc for MemoryLayout::offsetHandle [v5]
In-Reply-To: <L0oTIMzvY-1mTlF88iA3AiB-ToeyFVmH1CEPDApit0Q=.159a1db2-3abc-4615-a01d-3401fe5ac57e@github.com>
References: <0uMhIaW3d_IBqbF_04WhHDKHiIXes04wawSuxc6dQxI=.7f5621f9-0d77-4433-bc00-1ff8624b65da@github.com>
 <L0oTIMzvY-1mTlF88iA3AiB-ToeyFVmH1CEPDApit0Q=.159a1db2-3abc-4615-a01d-3401fe5ac57e@github.com>
Message-ID: <AhBeqyujZDWcnZABZIcBpMLEDUS2jOPAow09kHglRek=.1e600790-fa81-41b9-a484-588688f0eb8d@github.com>

On Fri, 10 May 2024 16:10:29 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Consider this layout:
>> 
>> 
>> MemoryLayout SEQ = MemoryLayout.sequenceLayout(5,
>>              MemoryLayout.sequenceLayout(10, JAVA_INT));
>> 
>> 
>> And the corresponding offset handle:
>> 
>> 
>> MethodHandle offsetHandle = SEQ.offsetHandle(PathElement.sequenceLayout(), PathElement.sequenceLayout());
>> 
>> 
>> The resulting method handle takes two additional `long` indices. The implementation checks that the dynamically provided indices conform to the bound available at construction: that is, the first index must be < 5, while the second must be < 10. If this is not true, an `IndexOutOfBoundException` is thrown.
>> 
>> However, the javadoc for `MemoryLayout::byteOffsetHandle` doesn't claim anything in this direction. There are only some vague claims in the javadoc for `PathElement::sequenceElement()` and `PathElement::sequenceElement(long, long, long)` which make some claims on which indices are actually allowed, but the text seems more in the tone of a discussion, rather than actual normative text.
>> 
>> I've tweaked the javadoc for `MemoryLayout::byteOffsetHandle` to actually state that the indices will be checked against the "size" of the corresponding open path element (this is a new concept that I also have defined in the javadoc).
>> 
>> I also added a test for `byteOffsetHandle` as I don't think we had a test for that specifically (although this method is tested indirectly, via `MemoryLayout::varHandle`).
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix another index check

Marked as reviewed by psandoz (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/19158#pullrequestreview-2050771038

From iklam at openjdk.org  Fri May 10 20:05:16 2024
From: iklam at openjdk.org (Ioi Lam)
Date: Fri, 10 May 2024 20:05:16 GMT
Subject: RFR: 8327499: MethodHandleStatics.traceLambdaForm includes methods
 that cannot be generated [v2]
In-Reply-To: <9_0CEL0npofl2XsTW6q4wLhYYSHm6kH0cOqsFBGskSg=.371cc7a8-12db-4ca3-864c-1ae0efd6fc54@github.com>
References: <twyi1CnAbWs33Rd0KieD7bbXYRVL6lQgfZ4HqvAVrCQ=.003fcea0-799c-4ba7-a6a1-cf3d72c99cfb@github.com>
 <9_0CEL0npofl2XsTW6q4wLhYYSHm6kH0cOqsFBGskSg=.371cc7a8-12db-4ca3-864c-1ae0efd6fc54@github.com>
Message-ID: <SBEZZevIYEqM8SZ0KEiaNzKx7HFrEPELXoyyymtrKMc=.0add447b-f368-40a7-a895-209cf6673f42@github.com>

On Fri, 10 May 2024 04:55:21 GMT, Chen Liang <liach at openjdk.org> wrote:

>> GenerateJLIClassesHelper has been making wrong assumptions about Invoker's LambdaForm method type parameters. Since they are distinct from those of Linkers, they are now tracked and generated separately. It seems that no proper invoker was ever generated before, except it happens that most invoker signatures can be taken as linker signature so we never detected it.
>> 
>> Requesting @iklam for a review; since I don't know how to deal with CDS, I have to relay to someone else to ensure this fixes the problem from the CDS side as well.
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add CDS test case to ensure LF resolution success

Looks good to me. Thanks for adding the CDS test.

-------------

Marked as reviewed by iklam (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19164#pullrequestreview-2050787955

From vromero at openjdk.org  Fri May 10 20:39:23 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 10 May 2024 20:39:23 GMT
Subject: RFR: 8320575: generic type information lost on mandated parameters
 of record's compact constructors [v20]
In-Reply-To: <20VdLsPE7Md_hxgniEhF0WPmdo_WXqbBswWdn2Az9N4=.0821e94c-4745-41e9-95a4-147f98657718@github.com>
References: <20VdLsPE7Md_hxgniEhF0WPmdo_WXqbBswWdn2Az9N4=.0821e94c-4745-41e9-95a4-147f98657718@github.com>
Message-ID: <UaxVZzX_u2z28VLMwm0Mx9FSichZurI2of3pEd5fc8o=.8f702d14-dfe2-4cc0-bc2f-bc9c806bf44f@github.com>

> Reflection is not retrieving generic type information for mandated parameters. This is a known issue which has been explicitly stated in the API of some reflection methods. Fix for [JDK-8292275](https://bugs.openjdk.org/browse/JDK-8292275) made the parameters of compact constructors of record classes `mandated` as specified in the spec. But this implied that users that previous to this change could retrieve the generic type of parameters of compact constructors now they can't anymore. The proposed fix is to try to retrieve generic type information for mandated parameters if available plus changing the spec of the related reflection methods.
> 
> TIA

Vicente Romero 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 21 additional commits since the last revision:

 - addressing review comments
 - Merge branch 'master' into JDK-8320575
 - minor refactoring
 - Merge branch 'master' into JDK-8320575
 - code refactoring
 - additional tests
 - special case the new code for records only
 - adding more tests
 - Update test/jdk/java/lang/reflect/records/RecordReflectionTest.java
   
   Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>
 - making the javadoc less general
 - ... and 11 more: https://git.openjdk.org/jdk/compare/95e6dde9...37010e19

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17070/files
  - new: https://git.openjdk.org/jdk/pull/17070/files/234f78d6..37010e19

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17070&range=19
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17070&range=18-19

  Stats: 27981 lines in 712 files changed: 14981 ins; 7947 del; 5053 mod
  Patch: https://git.openjdk.org/jdk/pull/17070.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17070/head:pull/17070

PR: https://git.openjdk.org/jdk/pull/17070

From vromero at openjdk.org  Fri May 10 20:51:04 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 10 May 2024 20:51:04 GMT
Subject: RFR: 8320575: generic type information lost on mandated parameters
 of record's compact constructors [v19]
In-Reply-To: <2sdYjjzSsRyImFY55rHCeqOPehPJk3md9nC445_W7q0=.d8c8dd2d-b001-4cad-a7f9-fe877260ba07@github.com>
References: <20VdLsPE7Md_hxgniEhF0WPmdo_WXqbBswWdn2Az9N4=.0821e94c-4745-41e9-95a4-147f98657718@github.com>
 <TTQWn-Mw-IZSJL2FPJ9jq5gVGdjEA7RLfe5FRf2jn2k=.8611bc23-3663-4e7a-a298-502d103f97ee@github.com>
 <2sdYjjzSsRyImFY55rHCeqOPehPJk3md9nC445_W7q0=.d8c8dd2d-b001-4cad-a7f9-fe877260ba07@github.com>
Message-ID: <i65XZMdj_5agRZlCNDwPKp7o_Uu6DV2E2aReXnFi_CE=.67c2d478-9ff5-4d9b-a3ad-de83c3b3273c@github.com>

On Mon, 29 Apr 2024 20:17:29 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   minor refactoring
>
> test/jdk/java/lang/reflect/records/R10.jcod line 1:
> 
>> 1: class R10 {
> 
> Please add some comments in the jcod file saying what it does/why it is being used.

done

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17070#discussion_r1597217598

From vromero at openjdk.org  Fri May 10 21:11:18 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 10 May 2024 21:11:18 GMT
Subject: RFR: 8320575: generic type information lost on mandated parameters
 of record's compact constructors [v7]
In-Reply-To: <8kc1FcJ-ilYErhHEJRu9S_64FWwg8lI5kZfTPDEeHYA=.7b75a759-2927-4434-8ec6-24f127f01a7e@github.com>
References: <20VdLsPE7Md_hxgniEhF0WPmdo_WXqbBswWdn2Az9N4=.0821e94c-4745-41e9-95a4-147f98657718@github.com>
 <UHA4xz5Ute6D_dTNMO4Ki4Jw7I3U7i6D5idwqPiuQ_w=.d44fe606-37f4-4451-9674-a0b1fa823647@github.com>
 <8kc1FcJ-ilYErhHEJRu9S_64FWwg8lI5kZfTPDEeHYA=.7b75a759-2927-4434-8ec6-24f127f01a7e@github.com>
Message-ID: <bCnoz4fGqSk4tcwn0rcIitmuEoRwAhd4xutzKtC64Sk=.0706cb8f-6a43-4893-8039-3514f9ab248d@github.com>

On Tue, 12 Dec 2023 22:21:29 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fixing comment
>
> As the core reflection code will encounter record classes compiled before and after the javac code generation change, if the old behavior can be triggered in javac using `--release $OLD`/`--source $OLD`, that would be helpful to include as part of the testing.

@jddarcy I have uploaded a new commit addressing your comments, thanks

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17070#issuecomment-2105271376

From naoto at openjdk.org  Fri May 10 22:00:23 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 10 May 2024 22:00:23 GMT
Subject: RFR: 8332084: Ensure JdkConsoleImpl.restoreEcho visibility in a
 shutdown hook
Message-ID: <9JTWc3FRpfbILlSHlmIU_dL5IE69RTxnSIAOdIte15I=.5854a48f-21d7-42c9-adb7-5e3ed40d1211@github.com>

Making sure `restoreEcho` correctly reflects the state in the shutdown thread, which differs from the application's thread that issues the `readPassword()` method.

-------------

Commit messages:
 - initial commit

Changes: https://git.openjdk.org/jdk/pull/19184/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19184&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8332084
  Stats: 7 lines in 1 file changed: 2 ins; 0 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/19184.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19184/head:pull/19184

PR: https://git.openjdk.org/jdk/pull/19184

From duke at openjdk.org  Fri May 10 22:11:16 2024
From: duke at openjdk.org (Srinivas Vamsi Parasa)
Date: Fri, 10 May 2024 22:11:16 GMT
Subject: RFR: 8266431: Dual-Pivot Quicksort improvements (Radix sort) [v11]
In-Reply-To: <Gyn-uB7iXtaX4BK8wuLqzafphTfNbJLy2n5a41RShsI=.7f279eb8-fb29-4003-9f49-84061def1e3a@github.com>
References: <918oCEfFu2JweXfV-afD1l_AGDDuc7dJwAxip-Ze6ZI=.8d5e9692-23db-47e4-9586-99e53b9cfbb6@github.com>
 <i1cu_VA2najjcZHepAbvkWGtVzuLMsdYFKssI5s-TFA=.be96a1ac-1eba-4b7f-bde9-1214082eb6c6@github.com>
 <Gb1pFf-YBbIZdSO-XvQ54xqE5SvNezsl9WSHikEOEJA=.90ccd95f-4a79-4a3e-91a0-23eb83107937@github.com>
 <e8rv_97mAYHGXeRhI8dirZDJsn9ecO2gM91t1LCxnWI=.21859a35-93b8-449c-b4f8-d9dfc0912a7e@github.com>
 <m_FlD1imWi57n0EqQXsrFue-FkO4D1hIbHUI2ph5d6o=.3fcdbf05-7147-4461-8d8e-6947f6f18d62@github.com>
 <C9cdmmBTW6uphtzkL9BdV4DboIuwNF6M-UMnC3xM8vg=.2aa0c11c-cb22-445f-86f6-281c6ab6368c@github.com>
 <-bYhysKjQVb_ZS0I0YutJZ7umfYwbs74rtK6-d2qL9U=.f9981e59-f0c4-48f3-ad7e-5627aad00919@github.com>
 <91Zv361kqKOjCSJPu20-yhKOb4lBIZVyVTm9f79dkcQ=.745c271d-3cb1-4ff3-9d71-5cad85ff4f14@github.com>
 <lAzKoJ7VajYG5E02nRkuqAHsREz3hz7plUFG3bjfwe0=.420af221-7969-4d8f-b9d2-16d2b4fa4cf9@github.com>
 <9q8Gg6DQnrf0HLW3oxwfpoUP9639drr1BIQMc1rxDFo=.eb4ea73c-b632-446a-8d50-b51838f67f69@github.com>
 <NC3E6wpsavqRXUqdgNHh3y26lFSIPXoA0yi
 KcV_2CyI=.391c9553-458a-417f-b86d-2c88dacf7df1@github.com>
 <Kc8tP6_hlFmF_NqcwSHEX6NF9atmoeglRsRFTrLaA5A=.bacb4a7d-26cb-4fdc-8f7b-f883587cd58c@github.com>
 <xrA2rqmjQ-gHGaZ23SQIYZCgda6sHslW2oHIqQxyM2Y=.f4ae4438-78b0-4eb1-b4aa-ed461c31ef1f@github.com>
 <0OkFUL1UCNcLRNh4P2ZdKvMENJgFy8Tz2BA5l2QgDXE=.77152fca-3c03-46a0-9855-bcf1c9b8d152@github.com>
 <hSP68W3vGCfGCOlUCf84DDw0qzt9Z7d-56LKLALocYo=.6c507f84-037d-449f-b4f6-f8c9771e6409@github.com>
 <JS57ADLXmF8NLa8Pn5HNclFkb0nHbOyCguMHquwd_bk=.b34c2b1c-43f5-491e-9965-6bf6f1cce3b0@github.com>
 <ib2mYavPszYymn_Q0H2Ur05M6MhSkpdwL_p6glKqSas=.411442cf-b0ee-4522-94e9-84be3b6ea292@github.com>
 <9_KKkAnzsXHFkj0038AWd5Jk3HTEXe2LQ4mVS88NzBw=.2753397a-5acc-45b6-ade9-e8799b3c6f28@github.com>
 <zbIMwqRuJNsei6zZPM05kn9XbbOm3ygyNmP5Q8_N180=.5a510e21-98fb-44f7-8f22-e93094d5b732@github.com>
 <0_F7PAs-rdVRnktd7oL65mvRxdmr_zBLNG5YVihi9Kg=.8f08c537-9d5b-4606-b9e9-b4bc1a717164@github.com>
 <z094CbYeWxVsMZ8s2_54mVC8fD_p67gSGyJxeiTZuVE=.78b39116-a5ad-4f03-ac15-7e3a09dc180e@
 github.com>
 <jd32y3QbyVdNJ3WX995GiSj6RbrVjiK9mpk9SruJDfY=.40eb6b15-8b11-4387-8fab-d95c70fed1da@github.com>
 <Gyn-uB7iXtaX4BK8wuLqzafphTfNbJLy2n5a41RShsI=.7f279eb8-fb29-4003-9f49-84061def1e3a@github.com>
Message-ID: <IiA39tOcrS-pay9AhFx6jpowc6GKB8Xng6nfF9Da_js=.c7e8aea4-70b6-46cc-8e26-8bd2c33f7a2a@github.com>

On Wed, 8 May 2024 20:37:28 GMT, Vladimir Yaroslavskiy <duke at openjdk.org> wrote:

>> Hi Vladimir (@iaroslavski),
>> 
>> Please see the data below.
>> 
>> Thanks,
>> Vamsi
>> 
>> name | builder | size | mode | count | score
>> -- | -- | -- | -- | -- | --
>> b01 | RANDOM | 600 | avg | 325677 | 6.764
>> b01 | RANDOM | 3000 | avg | 52041 | 77.742
>> b01 | RANDOM | 90000 | avg | 1217 | 4449.668
>> b01 | RANDOM | 400000 | avg | 242 | 22764.05
>> b01 | RANDOM | 1000000 | avg | 90 | 60737.71
>> b01 | REPEATED | 600 | avg | 651354 | 1.723
>> b01 | REPEATED | 3000 | avg | 104083 | 12.383
>> b01 | REPEATED | 90000 | avg | 2435 | 714.451
>> b01 | REPEATED | 400000 | avg | 484 | 3039.447
>> b01 | REPEATED | 1000000 | avg | 180 | 8114.503
>> b01 | SAWTOOTH | 600 | avg | 1954062 | 1.009
>> b01 | SAWTOOTH | 3000 | avg | 312251 | 4.94
>> b01 | SAWTOOTH | 90000 | avg | 7305 | 133.192
>> b01 | SAWTOOTH | 400000 | avg | 1453 | 591.854
>> b01 | SAWTOOTH | 1000000 | avg | 542 | 1494.252
>> b01 | STAGGER | 600 | avg | 1954062 | 8.252
>> b01 | STAGGER | 3000 | avg | 312251 | 10.449
>> b01 | STAGGER | 90000 | avg | 7305 | 287.811
>> b01 | STAGGER | 400000 | avg | 1453 | 1288.92
>> b01 | STAGGER | 1000000 | avg | 542 | 3245.649
>> b01 | SHUFFLE | 600 | avg | 325677 | 5.199
>> b01 | SHUFFLE | 3000 | avg | 52041 | 29.734
>> b01 | SHUFFLE | 90000 | avg | 1217 | 1392.125
>> b01 | SHUFFLE | 400000 | avg | 242 | 5772.859
>> b01 | SHUFFLE | 1000000 | avg | 90 | 15483.65
>> r30 | RANDOM | 600 | avg | 325677 | 4.307
>> r30 | RANDOM | 3000 | avg | 52041 | 71.438
>> r30 | RANDOM | 90000 | avg | 1217 | 3971.947
>> r30 | RANDOM | 400000 | avg | 242 | 19924.32
>> r30 | RANDOM | 1000000 | avg | 90 | 53671.9
>> r30 | REPEATED | 600 | avg | 651354 | 1.36
>> r30 | REPEATED | 3000 | avg | 104083 | 6.415
>> r30 | REPEATED | 90000 | avg | 2435 | 578.708
>> r30 | REPEATED | 400000 | avg | 484 | 2488.414
>> r30 | REPEATED | 1000000 | avg | 180 | 6280.025
>> r30 | SAWTOOTH | 600 | avg | 1954062 | 0.488
>> r30 | SAWTOOTH | 3000 | avg | 312251 | 2.409
>> r30 | SAWTOOTH | 90000 | avg | 7305 | 71.98
>> r30 | SAWTOOTH | 400000 | avg | 1453 | 343.433
>> r30 | SAWTOOTH | 1000000 | avg | 542 | 954.287
>> r30 | STAGGER | 600 | avg | 1954062 | 1.064
>> r30 | STAGGER | 3000 | avg | 312251 | 4.559
>> r30 | STAGGER | 90000 | avg | 7305 | 135.383
>> r30 | STAGGER | 400000 | avg | 1453 | 626.657
>> r30 | STAGGER | 1000000 | avg | 542 | 1653.92
>> r30 | SHUFFLE | 600 | avg | 325677 | 2.924
>> r30 | SHUFFLE | 3000 | avg | 52041 | 18.819
>> r30 | SHUFFLE | 90000 | avg | 1217 | 1019.036
>> r30 | SHUFFLE | 400000 | avg | 242 | 4661.484
>> r30 | SHUFFLE | 1000000 ...
>
> Hello Vamsi (@vamsi-parasa),
> 
> Could you please run the new benchmarking to finalize the best version?
> What you need is to compile and run JavaBenchmarkHarness:
> 
> javac --patch-module java.base=. -d classes *.java
> java -XX:CompileThreshold=1 -XX:-TieredCompilation --patch-module java.base=classes -cp classes java.util.JavaBenchmarkHarness
> 
> Find the sources there:
> 
> https://github.com/iaroslavski/sorting/blob/master/radixsort/DualPivotQuicksort_b01.java
> https://github.com/iaroslavski/sorting/blob/master/radixsort/DualPivotQuicksort_r31_11.java
> https://github.com/iaroslavski/sorting/blob/master/radixsort/DualPivotQuicksort_r31_11a.java
> https://github.com/iaroslavski/sorting/blob/master/radixsort/DualPivotQuicksort_r31_12.java
> https://github.com/iaroslavski/sorting/blob/master/radixsort/DualPivotQuicksort_r31_12a.java
> https://github.com/iaroslavski/sorting/blob/master/radixsort/JavaBenchmarkHarness.java
> 
> Thank you,
> Vladimir

Hi Vladimir (@iaroslavski),

Please see the data below.

Thanks,
Vamsi


name | builder | size | mode | count | score
-- | -- | -- | -- | -- | --
b01 | RANDOM | 600 | avg | 325677 | 6.861
b01 | RANDOM | 3000 | avg | 52041 | 77.313
b01 | RANDOM | 90000 | avg | 1217 | 4315.41
b01 | RANDOM | 400000 | avg | 242 | 22110.95
b01 | RANDOM | 1000000 | avg | 90 | 58613.45
b01 | REPEATED | 600 | avg | 651354 | 1.993
b01 | REPEATED | 3000 | avg | 104083 | 13.026
b01 | REPEATED | 90000 | avg | 2435 | 741.97
b01 | REPEATED | 400000 | avg | 484 | 3161.073
b01 | REPEATED | 1000000 | avg | 180 | 8363.671
b01 | STAGGER | 600 | avg | 1954062 | 9.124
b01 | STAGGER | 3000 | avg | 312251 | 10.026
b01 | STAGGER | 90000 | avg | 7305 | 286.313
b01 | STAGGER | 400000 | avg | 1453 | 1278.758
b01 | STAGGER | 1000000 | avg | 542 | 3242.849
b01 | SHUFFLE | 600 | avg | 325677 | 5.113
b01 | SHUFFLE | 3000 | avg | 52041 | 28.85
b01 | SHUFFLE | 90000 | avg | 1217 | 1368.91
b01 | SHUFFLE | 400000 | avg | 242 | 5718.052
b01 | SHUFFLE | 1000000 | avg | 90 | 15376.1
r31_11 | RANDOM | 600 | avg | 325677 | 4.305
r31_11 | RANDOM | 3000 | avg | 52041 | 73.399
r31_11 | RANDOM | 90000 | avg | 1217 | 3963.515
r31_11 | RANDOM | 400000 | avg | 242 | 19841.07
r31_11 | RANDOM | 1000000 | avg | 90 | 53372.63
r31_11 | REPEATED | 600 | avg | 651354 | 1.208
r31_11 | REPEATED | 3000 | avg | 104083 | 6.206
r31_11 | REPEATED | 90000 | avg | 2435 | 614.159
r31_11 | REPEATED | 400000 | avg | 484 | 2615.923
r31_11 | REPEATED | 1000000 | avg | 180 | 6553.801
r31_11 | STAGGER | 600 | avg | 1954062 | 1.023
r31_11 | STAGGER | 3000 | avg | 312251 | 4.406
r31_11 | STAGGER | 90000 | avg | 7305 | 129.76
r31_11 | STAGGER | 400000 | avg | 1453 | 600.581
r31_11 | STAGGER | 1000000 | avg | 542 | 1588.827
r31_11 | SHUFFLE | 600 | avg | 325677 | 2.887
r31_11 | SHUFFLE | 3000 | avg | 52041 | 17.901
r31_11 | SHUFFLE | 90000 | avg | 1217 | 1033.808
r31_11 | SHUFFLE | 400000 | avg | 242 | 4686.188
r31_11 | SHUFFLE | 1000000 | avg | 90 | 11589.67
r31_11a | RANDOM | 600 | avg | 325677 | 4.277
r31_11a | RANDOM | 3000 | avg | 52041 | 70.578
r31_11a | RANDOM | 90000 | avg | 1217 | 3963.836
r31_11a | RANDOM | 400000 | avg | 242 | 19771.67
r31_11a | RANDOM | 1000000 | avg | 90 | 53417.95
r31_11a | REPEATED | 600 | avg | 651354 | 1.112
r31_11a | REPEATED | 3000 | avg | 104083 | 5.662
r31_11a | REPEATED | 90000 | avg | 2435 | 596.963
r31_11a | REPEATED | 400000 | avg | 484 | 2618.076
r31_11a | REPEATED | 1000000 | avg | 180 | 6597.833
r31_11a | STAGGER | 600 | avg | 1954062 | 1.057
r31_11a | STAGGER | 3000 | avg | 312251 | 4.553
r31_11a | STAGGER | 90000 | avg | 7305 | 135.565
r31_11a | STAGGER | 400000 | avg | 1453 | 626.229
r31_11a | STAGGER | 1000000 | avg | 542 | 1652.539
r31_11a | SHUFFLE | 600 | avg | 325677 | 2.954
r31_11a | SHUFFLE | 3000 | avg | 52041 | 18.11
r31_11a | SHUFFLE | 90000 | avg | 1217 | 1010.687
r31_11a | SHUFFLE | 400000 | avg | 242 | 4648.926
r31_11a | SHUFFLE | 1000000 | avg | 90 | 11347.66
r31_12 | RANDOM | 600 | avg | 325677 | 4.023
r31_12 | RANDOM | 3000 | avg | 52041 | 73.204
r31_12 | RANDOM | 90000 | avg | 1217 | 3962.877
r31_12 | RANDOM | 400000 | avg | 242 | 19873.07
r31_12 | RANDOM | 1000000 | avg | 90 | 53445.79
r31_12 | REPEATED | 600 | avg | 651354 | 1.131
r31_12 | REPEATED | 3000 | avg | 104083 | 5.698
r31_12 | REPEATED | 90000 | avg | 2435 | 589.667
r31_12 | REPEATED | 400000 | avg | 484 | 2515.161
r31_12 | REPEATED | 1000000 | avg | 180 | 6306.065
r31_12 | STAGGER | 600 | avg | 1954062 | 1.022
r31_12 | STAGGER | 3000 | avg | 312251 | 4.391
r31_12 | STAGGER | 90000 | avg | 7305 | 129.646
r31_12 | STAGGER | 400000 | avg | 1453 | 600.297
r31_12 | STAGGER | 1000000 | avg | 542 | 1593.17
r31_12 | SHUFFLE | 600 | avg | 325677 | 2.91
r31_12 | SHUFFLE | 3000 | avg | 52041 | 18.026
r31_12 | SHUFFLE | 90000 | avg | 1217 | 1015.677
r31_12 | SHUFFLE | 400000 | avg | 242 | 4672.741
r31_12 | SHUFFLE | 1000000 | avg | 90 | 11353.6
r31_12a | RANDOM | 600 | avg | 325677 | 4.164
r31_12a | RANDOM | 3000 | avg | 52041 | 72.885
r31_12a | RANDOM | 90000 | avg | 1217 | 3959.741
r31_12a | RANDOM | 400000 | avg | 242 | 19820.85
r31_12a | RANDOM | 1000000 | avg | 90 | 53533.65
r31_12a | REPEATED | 600 | avg | 651354 | 1.248
r31_12a | REPEATED | 3000 | avg | 104083 | 6.238
r31_12a | REPEATED | 90000 | avg | 2435 | 601.415
r31_12a | REPEATED | 400000 | avg | 484 | 2672.975
r31_12a | REPEATED | 1000000 | avg | 180 | 6648.703
r31_12a | STAGGER | 600 | avg | 1954062 | 1.019
r31_12a | STAGGER | 3000 | avg | 312251 | 4.384
r31_12a | STAGGER | 90000 | avg | 7305 | 129.528
r31_12a | STAGGER | 400000 | avg | 1453 | 599.98
r31_12a | STAGGER | 1000000 | avg | 542 | 1588.87
r31_12a | SHUFFLE | 600 | avg | 325677 | 2.908
r31_12a | SHUFFLE | 3000 | avg | 52041 | 17.628
r31_12a | SHUFFLE | 90000 | avg | 1217 | 1015.16
r31_12a | SHUFFLE | 400000 | avg | 242 | 4659.382
r31_12a | SHUFFLE | 1000000 | avg | 90 | 11308.85
p_b01 | RANDOM | 600 | avg | 325677 | 7.271
p_b01 | RANDOM | 3000 | avg | 52041 | 74.478
p_b01 | RANDOM | 90000 | avg | 1217 | 627.657
p_b01 | RANDOM | 400000 | avg | 242 | 2573.436
p_b01 | RANDOM | 1000000 | avg | 90 | 6655.45
p_b01 | REPEATED | 600 | avg | 651354 | 1.326
p_b01 | REPEATED | 3000 | avg | 104083 | 10.312
p_b01 | REPEATED | 90000 | avg | 2435 | 246.139
p_b01 | REPEATED | 400000 | avg | 484 | 982.991
p_b01 | REPEATED | 1000000 | avg | 180 | 2404.307
p_b01 | STAGGER | 600 | avg | 1954062 | 8.228
p_b01 | STAGGER | 3000 | avg | 312251 | 9.95
p_b01 | STAGGER | 90000 | avg | 7305 | 116.508
p_b01 | STAGGER | 400000 | avg | 1453 | 386.686
p_b01 | STAGGER | 1000000 | avg | 542 | 928.404
p_b01 | SHUFFLE | 600 | avg | 325677 | 5.129
p_b01 | SHUFFLE | 3000 | avg | 52041 | 28.858
p_b01 | SHUFFLE | 90000 | avg | 1217 | 269.849
p_b01 | SHUFFLE | 400000 | avg | 242 | 894.039
p_b01 | SHUFFLE | 1000000 | avg | 90 | 2007.142
p_r31_11 | RANDOM | 600 | avg | 325677 | 4.249
p_r31_11 | RANDOM | 3000 | avg | 52041 | 72.002
p_r31_11 | RANDOM | 90000 | avg | 1217 | 459.225
p_r31_11 | RANDOM | 400000 | avg | 242 | 1432.624
p_r31_11 | RANDOM | 1000000 | avg | 90 | 3272.922
p_r31_11 | REPEATED | 600 | avg | 651354 | 1.149
p_r31_11 | REPEATED | 3000 | avg | 104083 | 5.87
p_r31_11 | REPEATED | 90000 | avg | 2435 | 188.272
p_r31_11 | REPEATED | 400000 | avg | 484 | 542.539
p_r31_11 | REPEATED | 1000000 | avg | 180 | 1173.866
p_r31_11 | STAGGER | 600 | avg | 1954062 | 1.413
p_r31_11 | STAGGER | 3000 | avg | 312251 | 6.42
p_r31_11 | STAGGER | 90000 | avg | 7305 | 89.017
p_r31_11 | STAGGER | 400000 | avg | 1453 | 253.295
p_r31_11 | STAGGER | 1000000 | avg | 542 | 596.151
p_r31_11 | SHUFFLE | 600 | avg | 325677 | 2.973
p_r31_11 | SHUFFLE | 3000 | avg | 52041 | 18.938
p_r31_11 | SHUFFLE | 90000 | avg | 1217 | 210.296
p_r31_11 | SHUFFLE | 400000 | avg | 242 | 500.305
p_r31_11 | SHUFFLE | 1000000 | avg | 90 | 995.793
p_r31_11a | RANDOM | 600 | avg | 325677 | 4.231
p_r31_11a | RANDOM | 3000 | avg | 52041 | 70.57
p_r31_11a | RANDOM | 90000 | avg | 1217 | 451.12
p_r31_11a | RANDOM | 400000 | avg | 242 | 1384.183
p_r31_11a | RANDOM | 1000000 | avg | 90 | 3195.761
p_r31_11a | REPEATED | 600 | avg | 651354 | 1.068
p_r31_11a | REPEATED | 3000 | avg | 104083 | 5.167
p_r31_11a | REPEATED | 90000 | avg | 2435 | 179.442
p_r31_11a | REPEATED | 400000 | avg | 484 | 528.168
p_r31_11a | REPEATED | 1000000 | avg | 180 | 1100.789
p_r31_11a | STAGGER | 600 | avg | 1954062 | 1.408
p_r31_11a | STAGGER | 3000 | avg | 312251 | 6.49
p_r31_11a | STAGGER | 90000 | avg | 7305 | 88.544
p_r31_11a | STAGGER | 400000 | avg | 1453 | 249.879
p_r31_11a | STAGGER | 1000000 | avg | 542 | 607.729
p_r31_11a | SHUFFLE | 600 | avg | 325677 | 2.955
p_r31_11a | SHUFFLE | 3000 | avg | 52041 | 17.828
p_r31_11a | SHUFFLE | 90000 | avg | 1217 | 207.078
p_r31_11a | SHUFFLE | 400000 | avg | 242 | 504.072
p_r31_11a | SHUFFLE | 1000000 | avg | 90 | 1013.957
p_r31_12 | RANDOM | 600 | avg | 325677 | 4.293
p_r31_12 | RANDOM | 3000 | avg | 52041 | 74.024
p_r31_12 | RANDOM | 90000 | avg | 1217 | 454.094
p_r31_12 | RANDOM | 400000 | avg | 242 | 1387.878
p_r31_12 | RANDOM | 1000000 | avg | 90 | 3233.883
p_r31_12 | REPEATED | 600 | avg | 651354 | 1.142
p_r31_12 | REPEATED | 3000 | avg | 104083 | 5.909
p_r31_12 | REPEATED | 90000 | avg | 2435 | 182.153
p_r31_12 | REPEATED | 400000 | avg | 484 | 540.245
p_r31_12 | REPEATED | 1000000 | avg | 180 | 1173.479
p_r31_12 | STAGGER | 600 | avg | 1954062 | 1.41
p_r31_12 | STAGGER | 3000 | avg | 312251 | 6.495
p_r31_12 | STAGGER | 90000 | avg | 7305 | 89.694
p_r31_12 | STAGGER | 400000 | avg | 1453 | 254.454
p_r31_12 | STAGGER | 1000000 | avg | 542 | 598.785
p_r31_12 | SHUFFLE | 600 | avg | 325677 | 2.929
p_r31_12 | SHUFFLE | 3000 | avg | 52041 | 22.026
p_r31_12 | SHUFFLE | 90000 | avg | 1217 | 209.91
p_r31_12 | SHUFFLE | 400000 | avg | 242 | 503.762
p_r31_12 | SHUFFLE | 1000000 | avg | 90 | 1009.454
p_r31_12a | RANDOM | 600 | avg | 325677 | 4.224
p_r31_12a | RANDOM | 3000 | avg | 52041 | 72.837
p_r31_12a | RANDOM | 90000 | avg | 1217 | 446.043
p_r31_12a | RANDOM | 400000 | avg | 242 | 1371.889
p_r31_12a | RANDOM | 1000000 | avg | 90 | 3180.349
p_r31_12a | REPEATED | 600 | avg | 651354 | 1.084
p_r31_12a | REPEATED | 3000 | avg | 104083 | 5.398
p_r31_12a | REPEATED | 90000 | avg | 2435 | 178.514
p_r31_12a | REPEATED | 400000 | avg | 484 | 526.991
p_r31_12a | REPEATED | 1000000 | avg | 180 | 1115.39
p_r31_12a | STAGGER | 600 | avg | 1954062 | 1.406
p_r31_12a | STAGGER | 3000 | avg | 312251 | 6.492
p_r31_12a | STAGGER | 90000 | avg | 7305 | 89.306
p_r31_12a | STAGGER | 400000 | avg | 1453 | 256.566
p_r31_12a | STAGGER | 1000000 | avg | 542 | 601.113
p_r31_12a | SHUFFLE | 600 | avg | 325677 | 2.942
p_r31_12a | SHUFFLE | 3000 | avg | 52041 | 21.799
p_r31_12a | SHUFFLE | 90000 | avg | 1217 | 209.605
p_r31_12a | SHUFFLE | 400000 | avg | 242 | 512.308
p_r31_12a | SHUFFLE | 1000000 | avg | 90 | 1015.947



</body>

</html>

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13568#issuecomment-2105327942

From duke at openjdk.org  Sat May 11 00:37:25 2024
From: duke at openjdk.org (xiaotaonan)
Date: Sat, 11 May 2024 00:37:25 GMT
Subject: Withdrawn: 8331957: Release Note: System Property for Java SE
 Specification Maintenance Version
In-Reply-To: <b0_uutHu72mHVmE6qQf0i9oS-5kUNFtJz_rS5aVeB18=.8ada78c9-490f-4603-a596-53c803a3a1d8@github.com>
References: <b0_uutHu72mHVmE6qQf0i9oS-5kUNFtJz_rS5aVeB18=.8ada78c9-490f-4603-a596-53c803a3a1d8@github.com>
Message-ID: <gXeVtlH3H6DegCv_M7fKnwMmozgbgQIQiBNW0MHo9a0=.36dbf8f8-2983-4754-bfc9-d66309a10bcd@github.com>

On Thu, 9 May 2024 00:49:43 GMT, xiaotaonan <duke at openjdk.org> wrote:

> ?ersion
> 
> Release Note: System Property for Java SE Specification Maintenance Version

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/19149

From liach at openjdk.org  Sat May 11 03:15:03 2024
From: liach at openjdk.org (Chen Liang)
Date: Sat, 11 May 2024 03:15:03 GMT
Subject: RFR: 8327499: MethodHandleStatics.traceLambdaForm includes methods
 that cannot be generated [v2]
In-Reply-To: <9_0CEL0npofl2XsTW6q4wLhYYSHm6kH0cOqsFBGskSg=.371cc7a8-12db-4ca3-864c-1ae0efd6fc54@github.com>
References: <twyi1CnAbWs33Rd0KieD7bbXYRVL6lQgfZ4HqvAVrCQ=.003fcea0-799c-4ba7-a6a1-cf3d72c99cfb@github.com>
 <9_0CEL0npofl2XsTW6q4wLhYYSHm6kH0cOqsFBGskSg=.371cc7a8-12db-4ca3-864c-1ae0efd6fc54@github.com>
Message-ID: <d1f0wAI_KqjMWf07NE83R_HUWoo41dS9YDDCbtz6U2E=.899218c8-6661-4115-b1b4-8ebd98b2c6f9@github.com>

On Fri, 10 May 2024 04:55:21 GMT, Chen Liang <liach at openjdk.org> wrote:

>> GenerateJLIClassesHelper has been making wrong assumptions about Invoker's LambdaForm method type parameters. Since they are distinct from those of Linkers, they are now tracked and generated separately. It seems that no proper invoker was ever generated before, except it happens that most invoker signatures can be taken as linker signature so we never detected it.
>> 
>> Requesting @iklam for a review; since I don't know how to deal with CDS, I have to relay to someone else to ensure this fixes the problem from the CDS side as well.
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add CDS test case to ensure LF resolution success

Thanks for the reviews!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19164#issuecomment-2105504472

From jpai at openjdk.org  Sat May 11 05:04:06 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Sat, 11 May 2024 05:04:06 GMT
Subject: RFR: 8331879: Clean up non-standard use of /// comments in
 `java.base`
In-Reply-To: <Lpd-uBwG8xZoG9WbPKfUawFKRfKrA1RfQ7XzKrY4qHQ=.e23104ab-d47a-4a55-b2bd-fb7b94e9a10f@github.com>
References: <JKCovwpov4A3Uddzf6N0AnZSb3Znv-7MEfMGec6IhR4=.93e4ad8e-344b-4890-8f25-c2752287024c@github.com>
 <Lpd-uBwG8xZoG9WbPKfUawFKRfKrA1RfQ7XzKrY4qHQ=.e23104ab-d47a-4a55-b2bd-fb7b94e9a10f@github.com>
Message-ID: <iVZfS86gx45ZhkVfmglGpZaLbvBcXibA3xcm1mylw7Y=.f4acf73f-37c7-4a37-a6e5-2ce0a0f9d95b@github.com>

On Fri, 10 May 2024 01:25:45 GMT, xiaotaonan <duke at openjdk.org> wrote:

>> Clean up non-standard use of /// comments in `java.base`
>
> @mdinacci @hns  @landonf

Hello @xiaotaonan, I see that you have several PRs of similar nature that have been opened in the past day or two. I would recommend taking a look at the OpenJDK developer's guide https://openjdk.org/guide/ (if you haven't already) to get familiar with the contribution guidelines. Additionally, if an issue has been assigned to someone, it's recommended that you ask the person if you can take over the issue before starting any work on it.
Finally, although not applicable to this specific PR, some of the other PRs you have open involve code changes that require jtreg test cases to be included and also making sure existing tests are run and continue to pass. The testing guidelines are available in the same guide https://openjdk.org/guide/#testing-the-jdk.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19151#issuecomment-2105551862

From duke at openjdk.org  Sat May 11 06:35:02 2024
From: duke at openjdk.org (ExE Boss)
Date: Sat, 11 May 2024 06:35:02 GMT
Subject: RFR: 8332084: Ensure JdkConsoleImpl.restoreEcho visibility in a
 shutdown hook
In-Reply-To: <9JTWc3FRpfbILlSHlmIU_dL5IE69RTxnSIAOdIte15I=.5854a48f-21d7-42c9-adb7-5e3ed40d1211@github.com>
References: <9JTWc3FRpfbILlSHlmIU_dL5IE69RTxnSIAOdIte15I=.5854a48f-21d7-42c9-adb7-5e3ed40d1211@github.com>
Message-ID: <r3Lm759Q0QJwRPRs7X-5HvUXFPcjbBOF-fW4LovxZmw=.7d5b05ec-640d-44a1-b394-b14328742f7d@github.com>

On Fri, 10 May 2024 21:55:26 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Making sure `restoreEcho` correctly reflects the state in the shutdown thread, which differs from the application's thread that issues the `readPassword()` method.

src/java.base/share/classes/jdk/internal/io/JdkConsoleImpl.java line 160:

> 158:                                 }
> 159:                             });
> 160:         } catch (IllegalStateException e) {

For?consistency, this?can also?use?`_`:
Suggestion:

        } catch (IllegalStateException _) {

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19184#discussion_r1597369939

From alanb at openjdk.org  Sat May 11 07:40:10 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Sat, 11 May 2024 07:40:10 GMT
Subject: Integrated: 8332029: Provide access to initial value of stderr via
 JavaLangAccess
In-Reply-To: <kPZZ3bMLJ-gEnr9NMQ0TaybDkcM15gP0YUDFCdWYxbA=.558291dd-740b-4807-bf63-e7f6d706d0e8@github.com>
References: <kPZZ3bMLJ-gEnr9NMQ0TaybDkcM15gP0YUDFCdWYxbA=.558291dd-740b-4807-bf63-e7f6d706d0e8@github.com>
Message-ID: <26Si7FUdOaoHBgA0CM7n-EA7oXKDsGegm72sOco___U=.dea3bca0-fbf4-451f-89df-a9bb6fffe540@github.com>

On Fri, 10 May 2024 07:57:40 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> In preparation for JEP 471 and JEP 472, provide access to the initial value of System.err from JavaLangAccess. The initial value of System.in is already exposed to code in java.base with this shared secret.

This pull request has now been integrated.

Changeset: 32c7681c
Author:    Alan Bateman <alanb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/32c7681cf310c87669c502c4a8b62a7fecc93360
Stats:     30 lines in 3 files changed: 20 ins; 5 del; 5 mod

8332029: Provide access to initial value of stderr via JavaLangAccess

Reviewed-by: jpai, bpb, mcimadamore

-------------

PR: https://git.openjdk.org/jdk/pull/19171

From alanb at openjdk.org  Sat May 11 15:05:12 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Sat, 11 May 2024 15:05:12 GMT
Subject: RFR: 8331876: JFR: Move file read and write events to java.base
 [v3]
In-Reply-To: <Xpe1ryCbGrBs_N6mgTHYRhMEPLx729S6thLnL40181c=.0c323247-824e-4d2b-83e3-4012361e453d@github.com>
References: <DDe0bKCC86AawVl7RylZ74uvvLBr2Zljpkcmxx1_WEU=.61cc10c6-b635-42dd-a850-b32ae1d68585@github.com>
 <SejX7NAvWNjrhDEN8uDf4oikQDBRclWXDg1fN5FCpkc=.7de48c6f-0af2-4bf4-a743-6e173d950d52@github.com>
 <DgjIOZTfztdSEeODuNZw5MmzsiohA82hhllWCceyPyU=.7bda36a1-e26d-4d7e-822a-e443d3cbc0df@github.com>
 <GmFZAGqKhqSMlAuKsnunFahbx5zJgYvgDG2T5lS_rho=.b6f10942-0d40-4b46-a24d-16a841502c79@github.com>
 <Xpe1ryCbGrBs_N6mgTHYRhMEPLx729S6thLnL40181c=.0c323247-824e-4d2b-83e3-4012361e453d@github.com>
Message-ID: <2r0EnbX6acRXslQdX0Use8YHoXPVrTnOf40o7e55pI8=.b6c40814-ef1b-4582-a2ea-716c3e90f182@github.com>

On Thu, 9 May 2024 16:02:02 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

>> The field is only used once and a VarHandle implementation loads three additional classes during startup and in my measurements add about 0.6 ms to startup.
>
> A compromise between performance and readability is:
> 
> if (JFRTracing.isEnabled()) {
>       ...
> }
> 
> One additional class is loaded, but it's more clear where it comes from. I didn't want to do that for the ThrowableTracer class since it had a clinit.
> 
> This could potentially cause problems if JFRTracing is loaded early from Throwable or other class in the future. The static boolean flag is more safe, so probably better.

One thing that isn't clear (to me anyway) is how it works with the memory model. It's plain read at the use sites, looks like the set when recording is turned on is also a plain write. Would it be possible to summarise what else happens when recording is turned on?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19129#discussion_r1597461416

From alanb at openjdk.org  Sat May 11 15:05:13 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Sat, 11 May 2024 15:05:13 GMT
Subject: RFR: 8331876: JFR: Move file read and write events to java.base
 [v3]
In-Reply-To: <SejX7NAvWNjrhDEN8uDf4oikQDBRclWXDg1fN5FCpkc=.7de48c6f-0af2-4bf4-a743-6e173d950d52@github.com>
References: <DDe0bKCC86AawVl7RylZ74uvvLBr2Zljpkcmxx1_WEU=.61cc10c6-b635-42dd-a850-b32ae1d68585@github.com>
 <SejX7NAvWNjrhDEN8uDf4oikQDBRclWXDg1fN5FCpkc=.7de48c6f-0af2-4bf4-a743-6e173d950d52@github.com>
Message-ID: <71FCu5gUhEqO1aJ6kL6daBWinoU9Bu4daiAtMqN3Nao=.163d8cc0-aaa1-4b77-b6c3-c1dbdcea2714@github.com>

On Thu, 9 May 2024 11:19:14 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

>> Hi,
>> 
>> Could I have a review of a change that moves the jdk.FileRead and jdk.FileWrite events to java.base to remove the use of the ASM instrumentation.
>> 
>> Testing: jdk/jdk/jfr
>> 
>> Thanks
>> Erik
>
> Erik Gahlin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Move methods

src/java.base/share/classes/sun/nio/ch/FileChannelImpl.java line 419:

> 417: 
> 418:     private long implWrite(ByteBuffer[] srcs, int offset, int length) throws IOException
> 419:     {

Style nit here, the "{" can move to the end of L418.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19129#discussion_r1597461653

From alanb at openjdk.org  Sat May 11 15:08:06 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Sat, 11 May 2024 15:08:06 GMT
Subject: RFR: 8278255: Add more warning text in ReentrantLock and
 ReentrantReadWriteLock [v2]
In-Reply-To: <ZjrjlUeRM-AtyH49lJMQPJkfad_MmEtWtS0n1gVPnkQ=.70f799bb-acb0-45ac-95c0-9001517128cd@github.com>
References: <nb-F4YENhZMQth9RCQsvTAiiMEVnW-MKKJbe3NWWSgg=.86a1c9ab-c13b-4d37-8ef2-b495df14fa17@github.com>
 <ZjrjlUeRM-AtyH49lJMQPJkfad_MmEtWtS0n1gVPnkQ=.70f799bb-acb0-45ac-95c0-9001517128cd@github.com>
Message-ID: <gakT6lkXKVBu6H_vvhyqjKmqUI6D9j8y9ltluZxvytE=.27d0973c-1534-4ecc-bec9-c797fa00ad76@github.com>

On Sat, 27 Apr 2024 11:52:18 GMT, Viktor Klang <vklang at openjdk.org> wrote:

>> This is an attempt to be more clear about recommendations on Lock usage.
>
> Viktor Klang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update src/java.base/share/classes/java/util/concurrent/locks/ReentrantReadWriteLock.java
>   
>   Co-authored-by: Pavel Rappo <32523691+pavelrappo at users.noreply.github.com>

Marked as reviewed by alanb (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/18974#pullrequestreview-2051219304

From vklang at openjdk.org  Sat May 11 18:41:08 2024
From: vklang at openjdk.org (Viktor Klang)
Date: Sat, 11 May 2024 18:41:08 GMT
Subject: Integrated: 8278255: Add more warning text in ReentrantLock and
 ReentrantReadWriteLock
In-Reply-To: <nb-F4YENhZMQth9RCQsvTAiiMEVnW-MKKJbe3NWWSgg=.86a1c9ab-c13b-4d37-8ef2-b495df14fa17@github.com>
References: <nb-F4YENhZMQth9RCQsvTAiiMEVnW-MKKJbe3NWWSgg=.86a1c9ab-c13b-4d37-8ef2-b495df14fa17@github.com>
Message-ID: <URfwg3gdZOEIs4uwj_iFBL8243DqXKskS5uoB687fRQ=.7c445a9d-4e11-4b03-84b1-342d2d009d88@github.com>

On Fri, 26 Apr 2024 11:43:06 GMT, Viktor Klang <vklang at openjdk.org> wrote:

> This is an attempt to be more clear about recommendations on Lock usage.

This pull request has now been integrated.

Changeset: 5053b70a
Author:    Viktor Klang <vklang at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/5053b70a7fc67ce9b73dbeecbdd88fbc34d45e04
Stats:     9 lines in 3 files changed: 2 ins; 0 del; 7 mod

8278255: Add more warning text in ReentrantLock and ReentrantReadWriteLock

Reviewed-by: prappo, alanb

-------------

PR: https://git.openjdk.org/jdk/pull/18974

From egahlin at openjdk.org  Sat May 11 19:37:10 2024
From: egahlin at openjdk.org (Erik Gahlin)
Date: Sat, 11 May 2024 19:37:10 GMT
Subject: RFR: 8331876: JFR: Move file read and write events to java.base
 [v3]
In-Reply-To: <zGenHEqjgT6f_P_VtwfKbmzBeQoArW8MHwfAa6uVGVY=.eb912b9b-3f02-4cac-8d96-e1bdbaaea2b8@github.com>
References: <DDe0bKCC86AawVl7RylZ74uvvLBr2Zljpkcmxx1_WEU=.61cc10c6-b635-42dd-a850-b32ae1d68585@github.com>
 <SejX7NAvWNjrhDEN8uDf4oikQDBRclWXDg1fN5FCpkc=.7de48c6f-0af2-4bf4-a743-6e173d950d52@github.com>
 <DgjIOZTfztdSEeODuNZw5MmzsiohA82hhllWCceyPyU=.7bda36a1-e26d-4d7e-822a-e443d3cbc0df@github.com>
 <khrP38H7DBIyftQZtZt0CRXeH1ZkpOCjiRNvFTs3LSI=.fd62aba9-5153-4521-84e4-241b8a352720@github.com>
 <zGenHEqjgT6f_P_VtwfKbmzBeQoArW8MHwfAa6uVGVY=.eb912b9b-3f02-4cac-8d96-e1bdbaaea2b8@github.com>
Message-ID: <wluFwF2Nhgjz-yspRYtEXIJ6jEiWm9imPd6CZlwYt6Y=.991f1032-1f5a-4762-8e5b-edc74d513e88@github.com>

On Fri, 10 May 2024 00:43:32 GMT, Stuart Marks <smarks at openjdk.org> wrote:

>> Its purpose is to avoid loading the FileReadEvent class. When the class is loaded, JFR will add fields and in some circumstances do other things. I don't think the cost is high, but it may add up if the number of events increases. Most Java applications don't run with JFR enabled, so this is to prevent them from seeing a negative impact.
>> 
>> I can update the text.
>
> Hm, I think this setup requires more discussion. The approach we had settled on was that at the call sites in the libraries, something like the following was done:
> 
>     public R operation(...) {
>         if (SomeEvent.enabled()) {
>             // perform operation0 with tracing
>             // emit event if SomeEvent.shouldCommit(...) is true
>         } else {
>             return operation0(...); // perform operation without tracing
>         }
>     }
> 
>     private R operation0(...) { /* do the actual work */ }
> 
> Now it looks like there's this additional flag `jfrTracing` that's set reflectively, and this flag is checked in a new layer of intermediate method calls:
> 
>     public R operation(...) {
>         if (jfrTracing) {
>             return traceOperation0(...);
>         } else {
>             return operation0(...);
>         }
>     }
> 
>     private R traceOperation0(...) {
>         // stuff moved from public operation(...) above
>     }
> 
> That is, the former body of the public `operation(...)` method is moved into the new `traceOperation0(...)` method.
> 
> I understand this is intended to help optimize startup time, but it adds clutter at each call site, and I'm wondering if it actually helps anything. The first time the application calls the `operation()` method, it's going to load a bunch of classes; the loading of this additional class is amortized over the loading and initialization of all the other classes in this area of the library. In addition, in the non-JFR case, the `enabled()` method implementation is simply `return false;` which can be inlined and which facilitiates dead code elimination.
> 
> With `jfrTracing` added to the mix, it causes a load from a non-final boolean field that needs to be checked repeatedly. Maybe the JIT can optimize for the common case, but there's possibly an expense that needs to be paid here.
> 
> At some point we should measure startup overhead for each case. I guess this can occur before or after this PR is integrated, depending on the urgency of things, but we should keep an eye on this issue.

If an event class is loaded before JFR is started, the event class needs to be retransformed, but if it is loaded later, we can add instrumentation on class load and avoid the retransformation. More happens when an event class is loaded compared to ordinary class load, for example, a startTime field is added.

I did a JMH run and the difference between Event::enabled() and a boolean flag was a fraction of nanosecond.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19129#discussion_r1597496811

From liach at openjdk.org  Sat May 11 19:44:49 2024
From: liach at openjdk.org (Chen Liang)
Date: Sat, 11 May 2024 19:44:49 GMT
Subject: RFR: 8331855: Convert jdk.jdeps jdeprscan and jdeps to use the
 Classfile API
Message-ID: <q2IKpwi6HEvLcKtNgKEzkD456bopyXRTliaRIU67C-4=.b77f917c-cb50-4d87-b187-65934954d622@github.com>

Summary of the changes:
 - Moved `com.sun.tools.classfile.Dependency` and `Dependencies` to jdeps; they are exclusively used by jdeps in sources, and they are not used in any tests too. This will ease the removal of `com.sun.tools.classfile` later.
 - A few visitor patterns have been rewritten with pattern matching, notably in:
   - `CPEntries`/`CPSelector` (removed)
   - `Dependencies.BasicDependencyFinder.Visitor` has been rewritten to use pattern matching to capture dependencies.
 - `MethodSig` and its tests have been removed in favor of `MethodTypeDesc`.
 - Otherwise, the changes are mostly mechanical replacements.

All tests in `test/langtools/tools/jdeprscan` and `test/langtools/tools/jdeps` pass.

-------------

Commit messages:
 - 8331855: Convert jdk.jdeps jdeprscan and jdeps to use the Classfile API

Changes: https://git.openjdk.org/jdk/pull/19193/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19193&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8331855
  Stats: 2143 lines in 18 files changed: 740 ins; 1197 del; 206 mod
  Patch: https://git.openjdk.org/jdk/pull/19193.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19193/head:pull/19193

PR: https://git.openjdk.org/jdk/pull/19193

From vklang at openjdk.org  Sat May 11 23:26:07 2024
From: vklang at openjdk.org (Viktor Klang)
Date: Sat, 11 May 2024 23:26:07 GMT
Subject: RFR: 8322732: ForkJoinPool may underutilize cores in async mode
In-Reply-To: <xRyDMAsSZ7obqpr3Aoc5qrHqILeJMxFVCeiRdctMI3U=.d5d3cd56-32eb-4431-ac01-081822fc86c6@github.com>
References: <xRyDMAsSZ7obqpr3Aoc5qrHqILeJMxFVCeiRdctMI3U=.d5d3cd56-32eb-4431-ac01-081822fc86c6@github.com>
Message-ID: <DEeHQv2nLHatTrU9_Qui13nt2otzvxKhZDEjZhZo60g=.cd772e86-e0d1-4429-adbc-3f6cd1e2ad92@github.com>

On Tue, 7 May 2024 22:50:18 GMT, Doug Lea <dl at openjdk.org> wrote:

> This set of changes address causes of poor utilization with small numbers of cores due to overly aggressive contention avoidance. A number of further adjustments were needed to still avoid most contention effects in deployments with large numbers of cores

src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 599:

> 597:      * Deactivation. When method scan indicates (twice) that no tasks
> 598:      * are found by a worker, it tries to deactivate()), giving up
> 599:      * (and rescanning) on ctl contention. To avoid missed signals

Suggestion:

     * (and rescanning) on "ctl" contention. To avoid missed signals

src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 880:

> 878:      * updated by owners from those most commonly read by stealers or
> 879:      * other management.  For class WorkQueue, an embedded padded
> 880:      * region segregates fields (all decalred as "int") most heavily

Suggestion:

     * region segregates fields (all declared as "int") most heavily

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19131#discussion_r1597520813
PR Review Comment: https://git.openjdk.org/jdk/pull/19131#discussion_r1597520717

From vklang at openjdk.org  Sat May 11 23:33:03 2024
From: vklang at openjdk.org (Viktor Klang)
Date: Sat, 11 May 2024 23:33:03 GMT
Subject: RFR: 8322732: ForkJoinPool may underutilize cores in async mode
In-Reply-To: <xRyDMAsSZ7obqpr3Aoc5qrHqILeJMxFVCeiRdctMI3U=.d5d3cd56-32eb-4431-ac01-081822fc86c6@github.com>
References: <xRyDMAsSZ7obqpr3Aoc5qrHqILeJMxFVCeiRdctMI3U=.d5d3cd56-32eb-4431-ac01-081822fc86c6@github.com>
Message-ID: <tkn2kvqo9IedXajQoECnLGEyWMXBPYxBHjciRLLBeYQ=.5bc59125-8db4-4321-94d1-dab95f9d5820@github.com>

On Tue, 7 May 2024 22:50:18 GMT, Doug Lea <dl at openjdk.org> wrote:

> This set of changes address causes of poor utilization with small numbers of cores due to overly aggressive contention avoidance. A number of further adjustments were needed to still avoid most contention effects in deployments with large numbers of cores

src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 1833:

> 1831:                 if (phase != 0) {          // else failed to start
> 1832:                     replaceable = true;
> 1833:                     if (w.top - w.base > 0) {

@DougLea Is this check sufficiently cheaper than trying to poll blind?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19131#discussion_r1597521380

From vklang at openjdk.org  Sat May 11 23:42:06 2024
From: vklang at openjdk.org (Viktor Klang)
Date: Sat, 11 May 2024 23:42:06 GMT
Subject: RFR: 8322732: ForkJoinPool may underutilize cores in async mode
In-Reply-To: <xRyDMAsSZ7obqpr3Aoc5qrHqILeJMxFVCeiRdctMI3U=.d5d3cd56-32eb-4431-ac01-081822fc86c6@github.com>
References: <xRyDMAsSZ7obqpr3Aoc5qrHqILeJMxFVCeiRdctMI3U=.d5d3cd56-32eb-4431-ac01-081822fc86c6@github.com>
Message-ID: <xfq05LH58dMqGPXQTK_u04lWQGEEWBMBwFlPs0Vvkb8=.982c7625-1235-441f-96f4-24efe706fbfd@github.com>

On Tue, 7 May 2024 22:50:18 GMT, Doug Lea <dl at openjdk.org> wrote:

> This set of changes address causes of poor utilization with small numbers of cores due to overly aggressive contention avoidance. A number of further adjustments were needed to still avoid most contention effects in deployments with large numbers of cores

src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 962:

> 960:      * minimum allowed timeout value.
> 961:      */
> 962:     static final long TIMEOUT_SLOP = 20L;

Might be worth spelling out the temporal unit used here.

src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 2101:

> 2099:      * Awaits signal or termination.
> 2100:      *
> 2101:      * @param w the worker

Suggestion:

     * @param w the work queue

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19131#discussion_r1597522226
PR Review Comment: https://git.openjdk.org/jdk/pull/19131#discussion_r1597522098

From vklang at openjdk.org  Sat May 11 23:49:03 2024
From: vklang at openjdk.org (Viktor Klang)
Date: Sat, 11 May 2024 23:49:03 GMT
Subject: RFR: 8322732: ForkJoinPool may underutilize cores in async mode
In-Reply-To: <xRyDMAsSZ7obqpr3Aoc5qrHqILeJMxFVCeiRdctMI3U=.d5d3cd56-32eb-4431-ac01-081822fc86c6@github.com>
References: <xRyDMAsSZ7obqpr3Aoc5qrHqILeJMxFVCeiRdctMI3U=.d5d3cd56-32eb-4431-ac01-081822fc86c6@github.com>
Message-ID: <awGWR9ZJaovwwnzbYu6S8y1UvUX2XxNHjB0W-DlYCUI=.ba153470-31de-4ab9-a21a-dd064ac7a899@github.com>

On Tue, 7 May 2024 22:50:18 GMT, Doug Lea <dl at openjdk.org> wrote:

> This set of changes address causes of poor utilization with small numbers of cores due to overly aggressive contention avoidance. A number of further adjustments were needed to still avoid most contention effects in deployments with large numbers of cores

src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 1916:

> 1914:      */
> 1915:     private long releaseAll() {
> 1916:         long c = ctl;

`ctl` is not re-read inside the endless loop, is there any risk for a stale `ctl` to make `releaseAll()` never terminate?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19131#discussion_r1597522945

From vklang at openjdk.org  Sat May 11 23:57:03 2024
From: vklang at openjdk.org (Viktor Klang)
Date: Sat, 11 May 2024 23:57:03 GMT
Subject: RFR: 8322732: ForkJoinPool may underutilize cores in async mode
In-Reply-To: <xRyDMAsSZ7obqpr3Aoc5qrHqILeJMxFVCeiRdctMI3U=.d5d3cd56-32eb-4431-ac01-081822fc86c6@github.com>
References: <xRyDMAsSZ7obqpr3Aoc5qrHqILeJMxFVCeiRdctMI3U=.d5d3cd56-32eb-4431-ac01-081822fc86c6@github.com>
Message-ID: <BYGQUSFJb23ySJXZiZyteP-Tb-9NhGaqYgQuCwo6p6s=.df313b7b-bea3-4c2b-ae0a-7a57ff7c86bd@github.com>

On Tue, 7 May 2024 22:50:18 GMT, Doug Lea <dl at openjdk.org> wrote:

> This set of changes address causes of poor utilization with small numbers of cores due to overly aggressive contention avoidance. A number of further adjustments were needed to still avoid most contention effects in deployments with large numbers of cores

src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 2074:

> 2072:                 WorkQueue[] qs;
> 2073:                 int spins = ac + ((short)(qc >>> TC_SHIFT) << 1) + SPIN_WAITS;
> 2074:                 while (((p = w.phase) & IDLE) != 0 && --spins != 0)

Might be worth checking `--spins >= 0` to avoid some pathological case where SPIN_WAITS is set to 0?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19131#discussion_r1597523616

From duke at openjdk.org  Sun May 12 02:25:30 2024
From: duke at openjdk.org (xiaotaonan)
Date: Sun, 12 May 2024 02:25:30 GMT
Subject: RFR: 8322332: Add API to access ZipEntry.extraAttributes
Message-ID: <Z-4fOM9zylN8dhtYzMSuvTAZcUVsLde4vSYgL0LHajc=.fa5f2fa3-84d4-4762-aec7-c33d3300d8eb@github.com>

Add API to access ZipEntry.extraAttributes

-------------

Commit messages:
 - Add API to access ZipEntry.extraAttributes

Changes: https://git.openjdk.org/jdk/pull/19202/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19202&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8322332
  Stats: 16 lines in 1 file changed: 16 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/19202.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19202/head:pull/19202

PR: https://git.openjdk.org/jdk/pull/19202

From duke at openjdk.org  Sun May 12 02:30:11 2024
From: duke at openjdk.org (xiaotaonan)
Date: Sun, 12 May 2024 02:30:11 GMT
Subject: Withdrawn: 8322332: Add API to access ZipEntry.extraAttributes
In-Reply-To: <Z-4fOM9zylN8dhtYzMSuvTAZcUVsLde4vSYgL0LHajc=.fa5f2fa3-84d4-4762-aec7-c33d3300d8eb@github.com>
References: <Z-4fOM9zylN8dhtYzMSuvTAZcUVsLde4vSYgL0LHajc=.fa5f2fa3-84d4-4762-aec7-c33d3300d8eb@github.com>
Message-ID: <NT96abJICYzEElQkxgh-nvF93qIVI2lGhYclz-qOFrg=.25b2aade-397e-4acb-87f8-d45c5e43e724@github.com>

On Sun, 12 May 2024 02:21:55 GMT, xiaotaonan <duke at openjdk.org> wrote:

> Add API to access ZipEntry.extraAttributes

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/19202

From liach at openjdk.org  Sun May 12 02:42:32 2024
From: liach at openjdk.org (Chen Liang)
Date: Sun, 12 May 2024 02:42:32 GMT
Subject: RFR: 8331855: Convert jdk.jdeps jdeprscan and jdeps to use the
 Classfile API [v2]
In-Reply-To: <q2IKpwi6HEvLcKtNgKEzkD456bopyXRTliaRIU67C-4=.b77f917c-cb50-4d87-b187-65934954d622@github.com>
References: <q2IKpwi6HEvLcKtNgKEzkD456bopyXRTliaRIU67C-4=.b77f917c-cb50-4d87-b187-65934954d622@github.com>
Message-ID: <-_-sdtKTXy0Heh10jg3IqVT64tVT_2OEvL-l2TmO024=.7a8efbc8-dedb-45c4-b944-cef9ec9dadfb@github.com>

> Summary of the changes:
>  - Moved `com.sun.tools.classfile.Dependency` and `Dependencies` to jdeps; they are exclusively used by jdeps in sources, and they are not used in any tests too. This will ease the removal of `com.sun.tools.classfile` later.
>  - A few visitor patterns have been rewritten with pattern matching, notably in:
>    - `CPEntries`/`CPSelector` (removed)
>    - `Dependencies.BasicDependencyFinder.Visitor` has been rewritten to use pattern matching to capture dependencies.
>  - `MethodSig` and its tests have been removed in favor of `MethodTypeDesc`.
>  - Otherwise, the changes are mostly mechanical replacements.
> 
> All tests in `test/langtools/tools/jdeprscan` and `test/langtools/tools/jdeps` pass.

Chen Liang has updated the pull request incrementally with one additional commit since the last revision:

  Migrate omitted getdeps test in langtools

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19193/files
  - new: https://git.openjdk.org/jdk/pull/19193/files/23268d37..be8c25b1

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19193&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19193&range=00-01

  Stats: 13 lines in 2 files changed: 4 ins; 0 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/19193.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19193/head:pull/19193

PR: https://git.openjdk.org/jdk/pull/19193

From duke at openjdk.org  Sun May 12 02:53:33 2024
From: duke at openjdk.org (xiaotaonan)
Date: Sun, 12 May 2024 02:53:33 GMT
Subject: RFR: 8322332: Add API to access ZipEntry.extraAttributes
Message-ID: <gEx3mkdcX4M-B_tEwPrgcZZRUIV9z1yrMQg_XQrWPpU=.274f2648-f152-49dd-a658-7bb255a0cdc4@github.com>

Add API to access ZipEntry.extraAttributes

-------------

Commit messages:
 - Add API to access ZipEntry.extraAttributes

Changes: https://git.openjdk.org/jdk/pull/19204/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19204&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8322332
  Stats: 17 lines in 1 file changed: 17 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/19204.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19204/head:pull/19204

PR: https://git.openjdk.org/jdk/pull/19204

From alanb at openjdk.org  Sun May 12 06:45:03 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Sun, 12 May 2024 06:45:03 GMT
Subject: RFR: 8322332: Add API to access ZipEntry.extraAttributes
In-Reply-To: <gEx3mkdcX4M-B_tEwPrgcZZRUIV9z1yrMQg_XQrWPpU=.274f2648-f152-49dd-a658-7bb255a0cdc4@github.com>
References: <gEx3mkdcX4M-B_tEwPrgcZZRUIV9z1yrMQg_XQrWPpU=.274f2648-f152-49dd-a658-7bb255a0cdc4@github.com>
Message-ID: <GukpD5Mvv5Tt8QBeJozoGxXSKxVw9cRlsD944zMAv8g=.26176384-8be1-430c-a967-e6644b1803f9@github.com>

On Sun, 12 May 2024 02:48:31 GMT, xiaotaonan <duke at openjdk.org> wrote:

> Add API to access ZipEntry.extraAttributes

I think this will require discussion on core libs before proposing APIs in this area. I think a starting point would be explain how you might use this, esp. with file permissions and sym links. Due to potential mis-use, I think, as before, have to be very cautious about introducing an API that provides access to the raw bits.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19204#issuecomment-2106139645

From alanb at openjdk.org  Sun May 12 07:30:07 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Sun, 12 May 2024 07:30:07 GMT
Subject: RFR: 8331876: JFR: Move file read and write events to java.base
 [v3]
In-Reply-To: <wluFwF2Nhgjz-yspRYtEXIJ6jEiWm9imPd6CZlwYt6Y=.991f1032-1f5a-4762-8e5b-edc74d513e88@github.com>
References: <DDe0bKCC86AawVl7RylZ74uvvLBr2Zljpkcmxx1_WEU=.61cc10c6-b635-42dd-a850-b32ae1d68585@github.com>
 <SejX7NAvWNjrhDEN8uDf4oikQDBRclWXDg1fN5FCpkc=.7de48c6f-0af2-4bf4-a743-6e173d950d52@github.com>
 <DgjIOZTfztdSEeODuNZw5MmzsiohA82hhllWCceyPyU=.7bda36a1-e26d-4d7e-822a-e443d3cbc0df@github.com>
 <khrP38H7DBIyftQZtZt0CRXeH1ZkpOCjiRNvFTs3LSI=.fd62aba9-5153-4521-84e4-241b8a352720@github.com>
 <zGenHEqjgT6f_P_VtwfKbmzBeQoArW8MHwfAa6uVGVY=.eb912b9b-3f02-4cac-8d96-e1bdbaaea2b8@github.com>
 <wluFwF2Nhgjz-yspRYtEXIJ6jEiWm9imPd6CZlwYt6Y=.991f1032-1f5a-4762-8e5b-edc74d513e88@github.com>
Message-ID: <UBAcBKmhmCkeevxrteAThIEvD8YNBWFrUa_qffEng14=.c50dbe19-3465-4385-9fe4-8c284a0b116e@github.com>

On Sat, 11 May 2024 19:31:34 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> If an event class is loaded before JFR is started, the event class needs to be retransformed, but if it is loaded later, we can add instrumentation on class load and avoid the retransformation. More happens when an event class is loaded compared to ordinary class load, for example, a startTime field is added.
> 
> I did a JMH run and the difference between Event::enabled() and a boolean flag was a fraction of nanosecond.

There are instances of FIS/FOS created in initPhase1 for the standard streams so loading as few classes and executing as minimal as possible is good. RAF will typically be used early too as the zip code opens zip files with a RAF. So doing as little as possible is good.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19129#discussion_r1597570831

From liach at openjdk.org  Sun May 12 08:43:24 2024
From: liach at openjdk.org (Chen Liang)
Date: Sun, 12 May 2024 08:43:24 GMT
Subject: RFR: 8332109: Convert remaining tests using com.sun.tools.classfile to
 ClassFile API
Message-ID: <argrcg0iKCFTZJz-mOA_OXkVPbyy0Z5Qb4L2g0Qc4gw=.637a0870-77b0-49da-9aee-ffa39ba68c5f@github.com>

Some tests are not migrated to the ClassFile API in previous migrations.

 - Some are simple oversights that didn't remove usages of com.sun.tools.classfile;
 - The CallerSensitive ones used an old utility, replaced by CF API-based new code;
 - many in javac are because the files are compiled with older source compatibility. Those patches are converted to have the source code stored in text blocks and compiled within tests using `ToolBox#writeJavaFiles` and `CompilerUtils.compile`;
 - As described in the JBS issue, there are a few other tests not covered; one is in #19193 while the others are blocked by CreateSymbols migration or bugs.

Testing: all modified tests pass.

-------------

Commit messages:
 - Missing copyright years
 - 8332109: Convert remaining tests using com.sun.tools.classfile to ClassFile API

Changes: https://git.openjdk.org/jdk/pull/19206/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19206&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8332109
  Stats: 1539 lines in 19 files changed: 224 ins; 1098 del; 217 mod
  Patch: https://git.openjdk.org/jdk/pull/19206.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19206/head:pull/19206

PR: https://git.openjdk.org/jdk/pull/19206

From duke at openjdk.org  Sun May 12 09:51:11 2024
From: duke at openjdk.org (xiaotaonan)
Date: Sun, 12 May 2024 09:51:11 GMT
Subject: RFR: 8322332: Add API to access ZipEntry.extraAttributes
In-Reply-To: <gEx3mkdcX4M-B_tEwPrgcZZRUIV9z1yrMQg_XQrWPpU=.274f2648-f152-49dd-a658-7bb255a0cdc4@github.com>
References: <gEx3mkdcX4M-B_tEwPrgcZZRUIV9z1yrMQg_XQrWPpU=.274f2648-f152-49dd-a658-7bb255a0cdc4@github.com>
Message-ID: <OsZZ0AgHgACKCSL-OWkp9Ug7_w63ltXP8RxFmDaxgcA=.51b59142-e881-4fbf-92a5-e86c80b5468a@github.com>

On Sun, 12 May 2024 02:48:31 GMT, xiaotaonan <duke at openjdk.org> wrote:

> Add API to access ZipEntry.extraAttributes

> /csr
@AlanBateman 

This issue was reported by a person named Alan Snyder, I don't have his or her contact information, how to create a CSR in this situation.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19204#issuecomment-2106188354

From liach at openjdk.org  Sun May 12 12:54:02 2024
From: liach at openjdk.org (Chen Liang)
Date: Sun, 12 May 2024 12:54:02 GMT
Subject: RFR: 8322332: Add API to access ZipEntry.extraAttributes
In-Reply-To: <OsZZ0AgHgACKCSL-OWkp9Ug7_w63ltXP8RxFmDaxgcA=.51b59142-e881-4fbf-92a5-e86c80b5468a@github.com>
References: <gEx3mkdcX4M-B_tEwPrgcZZRUIV9z1yrMQg_XQrWPpU=.274f2648-f152-49dd-a658-7bb255a0cdc4@github.com>
 <OsZZ0AgHgACKCSL-OWkp9Ug7_w63ltXP8RxFmDaxgcA=.51b59142-e881-4fbf-92a5-e86c80b5468a@github.com>
Message-ID: <RbdFfWaU0e7xMAll2rB_QyIYHZLNsE8a3GCIL0KHQpw=.15b44b90-e3de-4ef9-989a-f77e2b7e103f@github.com>

On Sun, 12 May 2024 09:48:42 GMT, xiaotaonan <duke at openjdk.org> wrote:

>> Add API to access ZipEntry.extraAttributes
>
>> /csr
> @AlanBateman 
> 
> This issue was reported by a person named Alan Snyder, I don't have his or her contact information, how to create a CSR in this situation.

@xiaotaonan Since you appear confused, "discussion on core libs" means discussion on core-libs-dev at openjdk.org mailing list https://mail.openjdk.org/mailman/listinfo/core-libs-dev where we can agree on what is a safe and future-proof way to expose the extraAttributes.

The csr command is just routinely issued for any patch that changes the Java APIs to protect against accidentally changing the public API. You shouldn't submit your CSR until you are sure the API surface (including method signatures + API Documentation/Javadoc) are settled down. If anything changes, you must re-draft your CSR to go through the CSR review process again.

Also, if you want to update a pull request, you can just push more commits; you don't have to force-push or delete your branch. When a pull request is integrated, openjdk bot will automatically squash and rename the squashed commit to your bug title, so please don't spam pull requests whenever you push a code update.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19204#issuecomment-2106237028

From dl at openjdk.org  Sun May 12 13:08:14 2024
From: dl at openjdk.org (Doug Lea)
Date: Sun, 12 May 2024 13:08:14 GMT
Subject: RFR: 8322732: ForkJoinPool may underutilize cores in async mode
In-Reply-To: <xfq05LH58dMqGPXQTK_u04lWQGEEWBMBwFlPs0Vvkb8=.982c7625-1235-441f-96f4-24efe706fbfd@github.com>
References: <xRyDMAsSZ7obqpr3Aoc5qrHqILeJMxFVCeiRdctMI3U=.d5d3cd56-32eb-4431-ac01-081822fc86c6@github.com>
 <xfq05LH58dMqGPXQTK_u04lWQGEEWBMBwFlPs0Vvkb8=.982c7625-1235-441f-96f4-24efe706fbfd@github.com>
Message-ID: <zWF31y3DOwRXDXu9s1B3YjtSvITz_5GJivH_b5UuFwU=.099e2cbf-d5ba-441d-8079-e9ada22b190c@github.com>

On Sat, 11 May 2024 23:39:04 GMT, Viktor Klang <vklang at openjdk.org> wrote:

>> This set of changes address causes of poor utilization with small numbers of cores due to overly aggressive contention avoidance. A number of further adjustments were needed to still avoid most contention effects in deployments with large numbers of cores
>
> src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 962:
> 
>> 960:      * minimum allowed timeout value.
>> 961:      */
>> 962:     static final long TIMEOUT_SLOP = 20L;
> 
> Might be worth spelling out the temporal unit used here.

done.

> src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 1833:
> 
>> 1831:                 if (phase != 0) {          // else failed to start
>> 1832:                     replaceable = true;
>> 1833:                     if (w.top - w.base > 0) {
> 
> @DougLea Is this check sufficiently cheaper than trying to poll blind?

Done.

> src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 1916:
> 
>> 1914:      */
>> 1915:     private long releaseAll() {
>> 1916:         long c = ctl;
> 
> `ctl` is not re-read inside the endless loop, is there any risk for a stale `ctl` to make `releaseAll()` never terminate?

It is implicitly read via the compareAndExchangeCtl

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19131#discussion_r1597633326
PR Review Comment: https://git.openjdk.org/jdk/pull/19131#discussion_r1597633209
PR Review Comment: https://git.openjdk.org/jdk/pull/19131#discussion_r1597633649

From dl at openjdk.org  Sun May 12 13:08:14 2024
From: dl at openjdk.org (Doug Lea)
Date: Sun, 12 May 2024 13:08:14 GMT
Subject: RFR: 8322732: ForkJoinPool may underutilize cores in async mode
In-Reply-To: <JUtCpfYxYkzw0CutHCbSfbFKNU0xadqFQMJx6x7meS4=.0517145f-be05-41f2-9d85-03d022d103a0@github.com>
References: <xRyDMAsSZ7obqpr3Aoc5qrHqILeJMxFVCeiRdctMI3U=.d5d3cd56-32eb-4431-ac01-081822fc86c6@github.com>
 <v-lLqE7QmMb0Mq6DW18Q1igG3WMHNZHLqKVO6AHigWU=.c8bf86d2-4c95-409d-8eac-a0ce7d660d9a@github.com>
 <JUtCpfYxYkzw0CutHCbSfbFKNU0xadqFQMJx6x7meS4=.0517145f-be05-41f2-9d85-03d022d103a0@github.com>
Message-ID: <pvOc4bvTkPBH-Jvx3HA_K_orae2BqY3t6cuMNef_ni4=.742eea6e-0a49-4420-adc2-832a077b8542@github.com>

On Fri, 10 May 2024 12:20:27 GMT, Doug Lea <dl at openjdk.org> wrote:

>> src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 978:
>> 
>>> 976:      * of two, at least 2. See above.
>>> 977:      */
>>> 978:     static final int INITIAL_QUEUE_CAPACITY = 1 << 7;
>> 
>> @DougLea Interesting change?what impact did you notice when doubling this?
>
> The goal is to reduce the worst form of contention: when queue arrays are laid out adjacently in memory. Increasing sizes has some impact but with diminishing returns. Thanks for the comment as a reminder that I haven't rechecked this lately in light of other layout changes. Will do.

After recheckiing, the best policy is to leave internal queues the same, but initialize external queues larger.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19131#discussion_r1597634199

From dl at openjdk.org  Sun May 12 13:12:24 2024
From: dl at openjdk.org (Doug Lea)
Date: Sun, 12 May 2024 13:12:24 GMT
Subject: RFR: 8322732: ForkJoinPool may underutilize cores in async mode
 [v2]
In-Reply-To: <xRyDMAsSZ7obqpr3Aoc5qrHqILeJMxFVCeiRdctMI3U=.d5d3cd56-32eb-4431-ac01-081822fc86c6@github.com>
References: <xRyDMAsSZ7obqpr3Aoc5qrHqILeJMxFVCeiRdctMI3U=.d5d3cd56-32eb-4431-ac01-081822fc86c6@github.com>
Message-ID: <1h7ssJJnGUbpqORLsdM_Udcl2dqYsrjuXP6ZPTH_bVo=.ce5a42ba-4eae-4430-9f7d-b6036a45ef9b@github.com>

> This set of changes address causes of poor utilization with small numbers of cores due to overly aggressive contention avoidance. A number of further adjustments were needed to still avoid most contention effects in deployments with large numbers of cores

Doug Lea has updated the pull request incrementally with one additional commit since the last revision:

  Address review comments

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19131/files
  - new: https://git.openjdk.org/jdk/pull/19131/files/7e64cdfc..8689ac12

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19131&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19131&range=00-01

  Stats: 111 lines in 1 file changed: 29 ins; 13 del; 69 mod
  Patch: https://git.openjdk.org/jdk/pull/19131.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19131/head:pull/19131

PR: https://git.openjdk.org/jdk/pull/19131

From egahlin at openjdk.org  Sun May 12 13:38:03 2024
From: egahlin at openjdk.org (Erik Gahlin)
Date: Sun, 12 May 2024 13:38:03 GMT
Subject: RFR: 8331876: JFR: Move file read and write events to java.base
 [v3]
In-Reply-To: <2r0EnbX6acRXslQdX0Use8YHoXPVrTnOf40o7e55pI8=.b6c40814-ef1b-4582-a2ea-716c3e90f182@github.com>
References: <DDe0bKCC86AawVl7RylZ74uvvLBr2Zljpkcmxx1_WEU=.61cc10c6-b635-42dd-a850-b32ae1d68585@github.com>
 <SejX7NAvWNjrhDEN8uDf4oikQDBRclWXDg1fN5FCpkc=.7de48c6f-0af2-4bf4-a743-6e173d950d52@github.com>
 <DgjIOZTfztdSEeODuNZw5MmzsiohA82hhllWCceyPyU=.7bda36a1-e26d-4d7e-822a-e443d3cbc0df@github.com>
 <GmFZAGqKhqSMlAuKsnunFahbx5zJgYvgDG2T5lS_rho=.b6f10942-0d40-4b46-a24d-16a841502c79@github.com>
 <Xpe1ryCbGrBs_N6mgTHYRhMEPLx729S6thLnL40181c=.0c323247-824e-4d2b-83e3-4012361e453d@github.com>
 <2r0EnbX6acRXslQdX0Use8YHoXPVrTnOf40o7e55pI8=.b6c40814-ef1b-4582-a2ea-716c3e90f182@github.com>
Message-ID: <CCtyHkShwKmJTnwnNox5m5ltqXe7P-q8y8aCC4x9T0Q=.6d6a3f12-4cd1-4ac1-a148-dca708bf9084@github.com>

On Sat, 11 May 2024 15:00:09 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> A compromise between performance and readability is:
>> 
>> if (JFRTracing.isEnabled()) {
>>       ...
>> }
>> 
>> One additional class is loaded, but it's more clear where it comes from. I didn't want to do that for the ThrowableTracer class since it had a clinit.
>> 
>> This could potentially cause problems if JFRTracing is loaded early from Throwable or other class in the future. The static boolean flag is more safe, so probably better.
>
> One thing that isn't clear (to me anyway) is how it works with the memory model. It's plain read at the use sites, looks like the set when recording is turned on is also a plain write. Would it be possible to summarise what else happens when recording is turned on?

During JFR initialization, jfrTracing flag is set to true by the JFRTracing class. Then, when the recording starts, a safepoint occurs, and all Java threads are stopped at a poll site. When they wake up and eventually read the memory of the jfrTracing field, it will be true because of memory fences related to the safepoint.

I guess it's not 100% safe if the JIT decides to store the read value elsewhere over several event checks, but it seems unlikely. Event settings checks (i.e., Event::isEnabled()) have always used plain reads, so it is not more unreliable than any other event.

I'm fine with using a volatile too. I used it for the exception events, but I now think a plain write/read of jfrTracing is safe for all practical purposes.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19129#discussion_r1597639174

From liach at openjdk.org  Sun May 12 13:45:02 2024
From: liach at openjdk.org (Chen Liang)
Date: Sun, 12 May 2024 13:45:02 GMT
Subject: RFR: 8322332: Add API to access ZipEntry.extraAttributes
In-Reply-To: <gEx3mkdcX4M-B_tEwPrgcZZRUIV9z1yrMQg_XQrWPpU=.274f2648-f152-49dd-a658-7bb255a0cdc4@github.com>
References: <gEx3mkdcX4M-B_tEwPrgcZZRUIV9z1yrMQg_XQrWPpU=.274f2648-f152-49dd-a658-7bb255a0cdc4@github.com>
Message-ID: <ceB0IDHG0QJzLxJmzpBSWdonjZJ0LxynpzYhxzqoWhc=.85c8e24c-0953-4772-982e-403eb7edd881@github.com>

On Sun, 12 May 2024 02:48:31 GMT, xiaotaonan <duke at openjdk.org> wrote:

> Add API to access ZipEntry.extraAttributes

For example, with a quick check, you can find that this field itself is not a good candidate for direct setter exposure:
1. For context, this is part of [the central directory file header](https://en.wikipedia.org/wiki/ZIP_(file_format)#Central_directory_file_header) for each Zip entry.
2. This is read from bytes 40-41 (most significant 2 bytes of "External file attributes") if the byte 5 is 3 (most significant byte of "Version made by"); it's stored in the same way.
3. Besides valid unsigned short values, this field also has a value of `-1` (or all negative values) indicating this field is absent.

Thus, a direct setter doesn't indicate the restriction that the field is 2-byte and is optional.

A getter might be fine, but given there are other ZIP fields that we don't expose (such as bytes 36-37, 38-41) it's dubious whether such exposure would be needed at all. After all, we should continue the discussion on core-libs-dev at openjdk.org.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19204#issuecomment-2106251411

From alanb at openjdk.org  Sun May 12 14:16:14 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Sun, 12 May 2024 14:16:14 GMT
Subject: RFR: 8322332: Add API to access ZipEntry.extraAttributes
In-Reply-To: <OsZZ0AgHgACKCSL-OWkp9Ug7_w63ltXP8RxFmDaxgcA=.51b59142-e881-4fbf-92a5-e86c80b5468a@github.com>
References: <gEx3mkdcX4M-B_tEwPrgcZZRUIV9z1yrMQg_XQrWPpU=.274f2648-f152-49dd-a658-7bb255a0cdc4@github.com>
 <OsZZ0AgHgACKCSL-OWkp9Ug7_w63ltXP8RxFmDaxgcA=.51b59142-e881-4fbf-92a5-e86c80b5468a@github.com>
Message-ID: <uvxRS6R6CiE9PvIPUrhWzYdiJNKmH_HcHzNUYGsdxZE=.5129aacb-423e-4906-b193-128b385d325a@github.com>

On Sun, 12 May 2024 09:48:42 GMT, xiaotaonan <duke at openjdk.org> wrote:

> This issue was reported by a person named Alan Snyder, I don't have his or her contact information, how to create a CSR in this situation.

He came to core-libs-dev in Dec 2023 [1] to discuss this. The context at the time was symbolic links. It might be interesting to explore that in the context of the zip file system provider, less sure about the java.util.zip APIs. I assume he created JDK-8322332 after that discussion to at least have something in JBS.

[1] https://mail.openjdk.org/pipermail/core-libs-dev/2023-December/116723.html

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19204#issuecomment-2106260883

From liach at openjdk.org  Sun May 12 14:32:12 2024
From: liach at openjdk.org (Chen Liang)
Date: Sun, 12 May 2024 14:32:12 GMT
Subject: RFR: 8322332: Add API to access ZipEntry.extraAttributes
In-Reply-To: <gEx3mkdcX4M-B_tEwPrgcZZRUIV9z1yrMQg_XQrWPpU=.274f2648-f152-49dd-a658-7bb255a0cdc4@github.com>
References: <gEx3mkdcX4M-B_tEwPrgcZZRUIV9z1yrMQg_XQrWPpU=.274f2648-f152-49dd-a658-7bb255a0cdc4@github.com>
Message-ID: <Cv3DbgTqH71X2LY-mZnC1o29l3xpeFCEPx0uP0xqle4=.96cf1a23-cece-43d3-a8c4-2f37e24f00f4@github.com>

On Sun, 12 May 2024 02:48:31 GMT, xiaotaonan <duke at openjdk.org> wrote:

> Add API to access ZipEntry.extraAttributes

Also see #16952, another patch that renames this field, which is planning for an integration soon; this PR will be out-of-date when that one is integrated.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19204#issuecomment-2106265843

From liach at openjdk.org  Sun May 12 14:40:14 2024
From: liach at openjdk.org (Chen Liang)
Date: Sun, 12 May 2024 14:40:14 GMT
Subject: RFR: 8321274: Rename ZipEntry.extraAttributes to
 ZipEntry.externalFileAttributes [v4]
In-Reply-To: <58cWTca1j5r5WfGtN8281Vog-yABS7RF2oJOlBsoBVs=.f18b5ca1-e345-4c3b-a568-cff6c003e902@github.com>
References: <EcxkA01kaWJwev-16dqYXi7rODrgCBzWJRHL5A4rjA0=.7e65e59b-3086-463a-9558-04abfe1b0782@github.com>
 <58cWTca1j5r5WfGtN8281Vog-yABS7RF2oJOlBsoBVs=.f18b5ca1-e345-4c3b-a568-cff6c003e902@github.com>
Message-ID: <9mdtCM7usK43fFPhH1w4Et3xYPtlqwwBYq6OWPfVa9A=.fb4d8f4e-250d-4dc6-a1ce-446f09bb00f5@github.com>

On Fri, 8 Mar 2024 09:34:05 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

>> Please consider this PR which suggests we rename `ZipEntry.extraAttributes` to `ZipEntry.externalFileAttributes`.
>> 
>> This field was introduced in [JDK-8218021](https://bugs.openjdk.org/browse/JDK-8218021), originally under the name `ZipEntry.posixPerms`. [JDK-8250968](https://bugs.openjdk.org/browse/JDK-8250968) later renamed the field to `ZipEntry.extraAttributes` and extended its semantics to hold the full two-byte value of the `external file attributes` field, as defined by `APPNOTE.TXT`
>> 
>> The name `extraAttributes` is misleading. It has nothing to do with the `extra field` (an unrelated structure defined in `APPNOTE.TXT`), although the name indicates it does.
>> 
>> To prevent confusion and make life easier for future maintainers, I suggest we rename this field to `ZipEntry.externalFileAttributes` and update related methods, parameters and comments accordingly.
>> 
>> While this change is a straightforward renaming, reviewers should consider whether it carries its weight, especially considering it might complicate future backports. 
>> 
>> As a note to reviewers, this PR includes the following intended updates:
>> 
>> - Rename `ZipEntry.extraAttributes` and any references to this field to `ZipEntry.externalFileAttributes`
>> - Update `JavaUtilZipFileAccess` to similarly rename methods to `setExternalFileAttributes` and `getExternalFileAttributes` 
>> - Rename the field `JarSigner.extraAttrsDetected` to `JarSigner.externalFileAttrsDetected`
>> - Rename a local variable in `JarSigner.writeEntry` to `externalFileAttributes`
>> - Rename `s.s.t.jarsigner.Main.extraAttrsDetected` to `externalFileAttributesDetected`
>> - Rename resource string key names in `s.s.t.jarsigner.Resources` from `extra.attributes.detected` to `external.file.attributes.detected`
>> - Rename method `SymlinkTest.verifyExtraAttrs` to `verifyExternalFileAttributes`, also updated two references to 'extra attributes' in this method
>> - Updated copyright in all affected files
>> 
>> If the resource file changes should be dropped and instead handled via `msgdop` updates, let me know and I can revert the non-default files.
>> 
>> I did a search across the code base to find 'extraAttrs', 'extra.attr' after these updates, and found nothing related to zip/jar. The `zip` and `jar` tests run clean:
>> 
>> 
>> make test TEST="test/jdk/java/util/jar"
>> make test TEST="test/jdk/java/util/zip"
>
> Eirik Bj?rsn?s has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rename SymlinkTest.verifyExternalAttrs to verifyExternalFileAttributes

I believe this field only captures the 2 bytes at higher indices of External File Attribute; it's not the complete 4-byte external file attributes and this value is not captured unless "Version made by" field's larger index byte (byte 5) is 3. So this name may still be imperfect.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/16952#issuecomment-2106268166

From liach at openjdk.org  Sun May 12 15:14:04 2024
From: liach at openjdk.org (Chen Liang)
Date: Sun, 12 May 2024 15:14:04 GMT
Subject: RFR: 8331291: java.lang.classfile.Attributes class performs a lot
 of static initializations [v8]
In-Reply-To: <UielWbqtQPeaoAfpuHYPMzn8N6ViEH0T0h6WXHscUrk=.e4d333d7-6ae3-447f-9b5f-d0a77d29c416@github.com>
References: <SHIvjbwCWBPERKxlytEsY_O_kEiJbSeEmSusuDwjTIw=.ae8dd21e-a822-476e-9760-dd489532dbf1@github.com>
 <UielWbqtQPeaoAfpuHYPMzn8N6ViEH0T0h6WXHscUrk=.e4d333d7-6ae3-447f-9b5f-d0a77d29c416@github.com>
Message-ID: <3eERzqYdCd4f9qn4KpzBA9ealaUTzC67wIhzB18ETTE=.f9d17a6f-1ca5-477f-8344-40c20abe7d7e@github.com>

On Mon, 6 May 2024 18:24:25 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> Hi,
>> During performance optimization work on Class-File API as JDK lambda generator we found some static initialization killers.
>> One of them is `java.lang.classfile.Attributes` with tens of static fields initialized with individual attribute mappers, and common set of all mappers, and static map from attribute names to the mappers.
>> 
>> I propose to turn all the static fields into lazy-initialized static methods and remove `PREDEFINED_ATTRIBUTES` and `standardAttribute(Utf8Entry name)` static mapping method from the `Attributes` API class.
>>  
>> Please let me know your comments or objections and please review the [PR](https://github.com/openjdk/jdk/pull/19006) and [CSR](https://bugs.openjdk.org/browse/JDK-8331414), so we can make it into 23.
>> 
>> Thank you,
>> Adam
>
> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fixed tests

src/java.base/share/classes/java/lang/classfile/Attributes.java line 153:

> 151: 
> 152:     /**
> 153:      * {@return Attribute mapper for the {@code AnnotationDefault} attribute}

Just wondering, can we change `{@code AnnotationDefault}` to `{@value #NAME_ANNOTATION_DEFAULT}`, etc? This way, the names are still rendered as code in Javadoc HTML, but they are generated with links to the constants, and programmers will see these constants and prefer them over hardcoded values.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19006#discussion_r1597655934

From alanb at openjdk.org  Sun May 12 18:55:12 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Sun, 12 May 2024 18:55:12 GMT
Subject: RFR: 8329581: Java launcher no longer prints a stack trace [v10]
In-Reply-To: <nFQS3JDegumTJOWSla6qGad04vc7PP7W3ZZ483XQuqs=.d28be017-00a0-44e0-9eee-bd70d56498e8@github.com>
References: <Z0pDMIc_XvZhcZdeFsIQUlqI17q5ybj0BnQ9Kl3jwxg=.8f981c46-a8a3-4520-a6e3-79ee7fce0253@github.com>
 <nFQS3JDegumTJOWSla6qGad04vc7PP7W3ZZ483XQuqs=.d28be017-00a0-44e0-9eee-bd70d56498e8@github.com>
Message-ID: <nuC0ykeUPUGGaWUitqcQdw_N7ueOLFnFzm2JdtXSqbo=.6d3cdcd9-8ae1-406c-8a72-1dc25e1ed869@github.com>

On Thu, 9 May 2024 19:52:12 GMT, Sonia Zaldana Calles <szaldana at openjdk.org> wrote:

>> Hi folks, 
>> 
>> This PR aims to fix [JDK-8329581](https://bugs.openjdk.org/browse/JDK-8329581). 
>> 
>> I think the regression got introduced in [JDK-8315458](https://bugs.openjdk.org/browse/JDK-8315458). 
>> 
>> In the issue linked above, [LauncherHelper#getMainType](https://github.com/openjdk/jdk/pull/16461/files#diff-108a3a3e3c2d108c8c7f19ea498f641413b7c9239ecd2975a6c27d904c2ba226) got removed to simplify launcher code.
>> 
>> Previously, we used ```getMainType``` to do the appropriate main method invocation in ```JavaMain```. However, we currently attempt to do all types of main method invocations at the same time [here](https://github.com/openjdk/jdk/blob/master/src/java.base/share/native/libjli/java.c#L623). 
>> 
>> Note how all of these invocations clear the exception reported with [CHECK_EXCEPTION_FAIL](https://github.com/openjdk/jdk/blob/140f56718bbbfc31bb0c39255c68568fad285a1f/src/java.base/share/native/libjli/java.c#L390). 
>> 
>> Therefore, if a legitimate exception comes up during one of these invocations, it does not get reported. 
>> 
>> I propose reintroducing ```LauncherHelper#getMainType``` but I'm looking forward to your suggestions. 
>> 
>> Cheers, 
>> Sonia
>
> Sonia Zaldana Calles has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Decreasing diff size addressing unnecessary changes

This mostly looks good. I'm just puzzled CHECK_EXCEPTION_NULL_FAIL. The JNI functions GetStaticMethodID, GetMethodID and NewObject return NULL with a pending exception when they fail. So I would expect CHECK_EXCEPTION_NULL_FAIL to just check if obj is NULL rather check for an exception first. It's not wrong to check for an exception, just curious when looking at this macro.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18786#issuecomment-2106343194

From duke at openjdk.org  Sun May 12 18:58:29 2024
From: duke at openjdk.org (Nizar Benalla)
Date: Sun, 12 May 2024 18:58:29 GMT
Subject: RFR: 8332101: Add an `@since` to `StandardOperation:REMOVE` in
 `jdk.dynalink`
Message-ID: <_rgUeIEaYmFmB8IcPGHq-B-ZPAx1ulW9cXsuV8EabZU=.0321aff4-91ff-42b3-aa82-bc61c7d42fe9@github.com>

Code cleanup, please review this simple change.
To help with the review, this was added back in https://bugs.openjdk.org/browse/JDK-8191905
TIA

-------------

Commit messages:
 - add an `@since` and modify Copyright header

Changes: https://git.openjdk.org/jdk/pull/19189/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19189&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8332101
  Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/19189.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19189/head:pull/19189

PR: https://git.openjdk.org/jdk/pull/19189

From duke at openjdk.org  Sun May 12 18:58:29 2024
From: duke at openjdk.org (Nizar Benalla)
Date: Sun, 12 May 2024 18:58:29 GMT
Subject: RFR: 8332101: Add an `@since` to `StandardOperation:REMOVE` in
 `jdk.dynalink`
In-Reply-To: <_rgUeIEaYmFmB8IcPGHq-B-ZPAx1ulW9cXsuV8EabZU=.0321aff4-91ff-42b3-aa82-bc61c7d42fe9@github.com>
References: <_rgUeIEaYmFmB8IcPGHq-B-ZPAx1ulW9cXsuV8EabZU=.0321aff4-91ff-42b3-aa82-bc61c7d42fe9@github.com>
Message-ID: <tNbc82-EJ-f4xSYFnfvkKV2qT9aRqThUg2yIsjq3F1w=.92443efc-dd03-4c97-ad70-f10f4db71bb8@github.com>

On Sat, 11 May 2024 15:39:04 GMT, Nizar Benalla <duke at openjdk.org> wrote:

> Code cleanup, please review this simple change.
> To help with the review, this was added back in https://bugs.openjdk.org/browse/JDK-8191905
> TIA

I believe `jdk.nashorn` is under core-libs

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19189#issuecomment-2105941152

From javalists at cbfiddle.com  Sun May 12 19:17:03 2024
From: javalists at cbfiddle.com (Alan Snyder)
Date: Sun, 12 May 2024 12:17:03 -0700
Subject: RFR: 8322332: Add API to access ZipEntry.extraAttributes
In-Reply-To: <Cv3DbgTqH71X2LY-mZnC1o29l3xpeFCEPx0uP0xqle4=.96cf1a23-cece-43d3-a8c4-2f37e24f00f4@github.com>
References: <gEx3mkdcX4M-B_tEwPrgcZZRUIV9z1yrMQg_XQrWPpU=.274f2648-f152-49dd-a658-7bb255a0cdc4@github.com>
 <Cv3DbgTqH71X2LY-mZnC1o29l3xpeFCEPx0uP0xqle4=.96cf1a23-cece-43d3-a8c4-2f37e24f00f4@github.com>
Message-ID: <CA7E2A98-E9F0-4E4E-A064-31647CA3F4EB@cbfiddle.com>

> It might be interesting to explore that in the context of the zip file system provider, less sure about the java.util.zip APIs. 

I was not using the Zip file system. I was processing a Zip file.

  Alan





> On May 12, 2024, at 7:32?AM, Chen Liang <liach at openjdk.org> wrote:
> 
> On Sun, 12 May 2024 02:48:31 GMT, xiaotaonan <duke at openjdk.org> wrote:
> 
>> Add API to access ZipEntry.extraAttributes
> 
> Also see #16952, another patch that renames this field, which is planning for an integration soon; this PR will be out-of-date when that one is integrated.
> 
> -------------
> 
> PR Comment: https://git.openjdk.org/jdk/pull/19204#issuecomment-2106265843
> 


From vklang at openjdk.org  Sun May 12 19:50:04 2024
From: vklang at openjdk.org (Viktor Klang)
Date: Sun, 12 May 2024 19:50:04 GMT
Subject: RFR: 8322732: ForkJoinPool may underutilize cores in async mode
 [v2]
In-Reply-To: <1h7ssJJnGUbpqORLsdM_Udcl2dqYsrjuXP6ZPTH_bVo=.ce5a42ba-4eae-4430-9f7d-b6036a45ef9b@github.com>
References: <xRyDMAsSZ7obqpr3Aoc5qrHqILeJMxFVCeiRdctMI3U=.d5d3cd56-32eb-4431-ac01-081822fc86c6@github.com>
 <1h7ssJJnGUbpqORLsdM_Udcl2dqYsrjuXP6ZPTH_bVo=.ce5a42ba-4eae-4430-9f7d-b6036a45ef9b@github.com>
Message-ID: <3TCc62ocrg1M4I6RlxofEJcyrEG-GQ5hijQnvh2iS-0=.307e277d-6960-40f4-8349-12f3ae016f2a@github.com>

On Sun, 12 May 2024 13:12:24 GMT, Doug Lea <dl at openjdk.org> wrote:

>> This set of changes address causes of poor utilization with small numbers of cores due to overly aggressive contention avoidance. A number of further adjustments were needed to still avoid most contention effects in deployments with large numbers of cores
>
> Doug Lea has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address review comments

src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 992:

> 990:      */
> 991:     static final int INITIAL_EXTERNAL_QUEUE_CAPACITY = 1 << 9;
> 992:     //        INITIAL_QUEUE_CAPACITY << 2;

Leftover?

src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 1238:

> 1236:         WorkQueue(ForkJoinWorkerThread owner, int id, int cfg,
> 1237:                   boolean clearThreadLocals) {
> 1238:             array = new ForkJoinTask<?>[owner == null ?

I like this change?initializing the array itself in the WorkQueue constructor makes a lot of sense.

src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 1242:

> 1240:                                         INITIAL_QUEUE_CAPACITY];
> 1241:             this.owner = owner;
> 1242:             //            top = base = 1;

Leftover?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19131#discussion_r1597703111
PR Review Comment: https://git.openjdk.org/jdk/pull/19131#discussion_r1597703016
PR Review Comment: https://git.openjdk.org/jdk/pull/19131#discussion_r1597703079

From liangchenblue at gmail.com  Sun May 12 20:56:03 2024
From: liangchenblue at gmail.com (-)
Date: Sun, 12 May 2024 15:56:03 -0500
Subject: RFR: 8322332: Add API to access ZipEntry.extraAttributes
In-Reply-To: <CA7E2A98-E9F0-4E4E-A064-31647CA3F4EB@cbfiddle.com>
References: <gEx3mkdcX4M-B_tEwPrgcZZRUIV9z1yrMQg_XQrWPpU=.274f2648-f152-49dd-a658-7bb255a0cdc4@github.com>
 <Cv3DbgTqH71X2LY-mZnC1o29l3xpeFCEPx0uP0xqle4=.96cf1a23-cece-43d3-a8c4-2f37e24f00f4@github.com>
 <CA7E2A98-E9F0-4E4E-A064-31647CA3F4EB@cbfiddle.com>
Message-ID: <CABe8uE1eOE-8RCC5CCynCT-RxuYZ-Qdc1C0xhEmOC0+ASvoT8g@mail.gmail.com>

Hi Alan Snyder,
Currently, JDK ZipEntry populates that extraAttributes (proposed to rename
to externalFileAttributes in JDK-8321274, PR #16952) only if the high byte
of the "version made by" field is 3 (indicating Linux compatibility) and
only records the most significant 2 bytes for the copied ZipEntry.
Since this is not the "external file attributes" field from the ZIP format,
do you still think this field should be exposed, or should we create a new
field to properly model the external file attributes? Also worth noting is
the support for adjusting the "version made by" field, the "external file
attributes" field might be misinterpreted without it.

P.S. Seems the Skara bridge is not propagating emails to GitHub comments.

On Sun, May 12, 2024 at 2:17?PM Alan Snyder <javalists at cbfiddle.com> wrote:

> > It might be interesting to explore that in the context of the zip file
> system provider, less sure about the java.util.zip APIs.
>
> I was not using the Zip file system. I was processing a Zip file.
>
>   Alan
>
>
>
>
>
> > On May 12, 2024, at 7:32?AM, Chen Liang <liach at openjdk.org> wrote:
> >
> > On Sun, 12 May 2024 02:48:31 GMT, xiaotaonan <duke at openjdk.org> wrote:
> >
> >> Add API to access ZipEntry.extraAttributes
> >
> > Also see #16952, another patch that renames this field, which is
> planning for an integration soon; this PR will be out-of-date when that one
> is integrated.
> >
> > -------------
> >
> > PR Comment:
> https://git.openjdk.org/jdk/pull/19204#issuecomment-2106265843
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240512/7384290b/attachment.htm>

From alautiero at gmail.com  Sun May 12 21:58:27 2024
From: alautiero at gmail.com (Alessandro Autiero)
Date: Sun, 12 May 2024 23:58:27 +0200
Subject: Enhance proxy support in java.net core libraries
Message-ID: <CAM0RScncCo+J2PMpEA71Ug8RXXL9QMP+KN86Y+h1x9kn_qm2AA@mail.gmail.com>

Hello, my name is Alessandro Autiero and I'd like to propose three
enhancements for the java core libraries to better support proxies in
network components of the JDK.

There are three classes in the java.net package that have proxy support:

   - java.net.Socket
   Introduced in Java 1.0, supports HTTP(S)/SOCKS proxies modelled by
   java.net.Proxy through the java.net.Socket(java.net.Proxy) constructor
   - java.net.HttpURLConnection
   Introduced in Java 1.1, supports HTTP(S)/SOCKS proxies modelled by
   java.net.Proxy through the java.net.URL#openConnection(java.net.Proxy)
   public method
   - java.net.HttpClient (Introduced in Java 11)
   Introduced in Java 11, supports HTTP(S) proxies modelled by
   java.net.ProxySelector through the public proxy(java.net.ProxySelector)
   method in its builder or the default java.net.ProxySelector, which can be
   set by calling java.net.ProxySelector#setDefault(java.net.ProxySelector)

While most proxies provide support for both the HTTP and SOCKS scheme,
considering that the older HTTP client API had support for both, developers
might choose to use the older api, or to use an external one, if they need
or want to provide support for this feature. A quick Google search for a
recommendation on which Http Client to use on a modern Java version yields
many results that list SOCKS support as a feature to keep in mind when
making a choice. While this is not necessarily indicative of the average
Java developer sentiment about the feature, I think that it should be
considered, alongside a couple of issues that were opened on StackOverFlow
<https://stackoverflow.com/questions/70011046/how-to-use-a-socks-proxy-with-java-jdk-httpclient>
asking about support for this feature. Accordingly, I propose adding
support for SOCKS proxies in java.net.HttpClient. If the change is allowed,
consider that the default java.net.ProxySelector is an instance of
sun.net.spi.DefaultProxySelector, which supports SOCKS proxies, but this
implementation cannot be initialized by the user as it's not exposed by the
module system. Starting from Java 9, ProxySelector#of(InetSocketAddress)
was introduced, which returns an instance of
java.net.ProxySelector$StaticProxySelector
<https://github.com/openjdk/jdk/blob/5053b70a7fc67ce9b73dbeecbdd88fbc34d45e04/src/java.base/share/classes/java/net/ProxySelector.java#L194>,
a static inner class of ProxySelector introduced in Java 9 which only
implements support for HTTP(S) proxies. StaticProxySelector's constructor
could be modified from StaticProxySelector(java.net.InetSocketAddress) to
StaticProxySelector(java.net.Proxy$Type, java.net.InetSocketAddress) to
initialize the java.net.Proxy instance with a specified proxy type instead
of hard coding HTTP. Then we could overload the method
ProxySelector#of(InetSocketAddress) with
ProxySelector#of(java.net.Proxy$Type, InetSocketAddress) method which would
invoke the constructor we defined earlier. This change would not be
breaking as StaticProxySelector is package private, no public methods would
be deleted and the default scheme would still be HTTP.
jdk.internal.net.http.HttpRequestImpl uses the ProxySelector in its
retrieveProxy method, but checks if the proxy is an HTTP proxy: this would
need to be changed as well. Finally, considering that unlike
HttpURLConnection, HttpClient doesn't delegate the underlying connection to
java.net.Socket, the java.net.http module would need to be enhanced to
support SOCKS authentication, which could take more effort.

Another observation that I've made is about authentication. If a proxy
requires basic authentication, that is authentication through a username
and optionally a password, a developer can implement the
java.net.Authenticator class and override the getPasswordAuthentication
method. While basic authentication is still the norm for most proxies, it's
disabled by default in the JDK since Java 8. Though, it's possible to
enable it by overriding the net properties
jdk.http.auth.proxying.disabledSchemes and
jdk.http.auth.tunneling.disabledSchemes using System.setProperty. I
couldn't find an explanation about why this change was implemented, so I
can only speculate that it was done to incentivize Java developers to use
an IP whitelist instead of basic auth to improve security, assuming that
the connection isn't secure(HTTP). The problem though is that the net
properties that need to be changed to allow basic proxy authentication are
only read only one time in the static initializer of
sun.net.www.protocol.http.HttpURLConnection class, the underlying
implementation of java.net.HttpURLConnection. So, if for example a library
loads this class before the developer calls System.setProperty, the change
will have no effect and the authentication will subsequently fail. This may
seem like an edge case, but for example in a Spring Boot environment, this
exact issue will arise if the property isn't set before calling
SpringApplication.run. I think that the best solution would be to remove
the disabledTunnelingSchemes and disabledProxyingSchemes static fields from
sun.net.www.protocol.http.HttpURLConnection and read the net properties
when they are used instead of caching them. This solution is not a breaking
change and should be very easy to implement as both fields are only
referenced when initializing a AuthenticationHeader in the same class.
Additionally, if we can agree on the fact that basic authentication is
still the predominant way to provide authentication capabilities for a
proxy and/or that disabling it doesn't provide a direct security benefit, I
propose to also set jdk.http.auth.proxying.disabledSchemes and
jdk.http.auth.tunneling.disabledSchemes to an empty String so no schemes
are disabled by default. This change could be breaking for Applications
developed starting from Java 8 that expect basic authentication to be
disabled, but I think that the scope of the impact would be much smaller,
if there would be any at all, than when these flags were introduced
breaking basic authentication for existing applications upgrading to Java 8.

The last issue I've noticed is also about authentication. If a developer
wants to set an instance of Authenticator instead of relying on the default
one, which can be set using Authenticator.setAuthenticator, this may not be
possible depending on the implementation:

   - java.net.Socket
   Not supported
   - java.net.HttpURLConnection
   Supported through the setAuthenticator(Authenticator) method introduced
   in Java 9
   - java.net.HttpClient
   Supported through the authenticator(Authenticator) method in its builder

The reason why a developer might want to provide an instance of
Authenticator instead of relying on the default one is that, for example,
in a concurrent environment where multiple sockets exist, each using a
different proxy, if the proxy host and port are the same, but each Socket
instance is expected to use a different pair of username and passwords, the
default Authenticator cannot determine which pair of credentials should be
assigned to a given authentication request as it lacks the scope to make
this decision. This change is not breaking as the default authenticator of
a Socket would still be the default authenticator, which is the current
behaviour. If the change is allowed, a possible solution would be to add a
private field named authenticator and a public method
setAuthenticator(Authenticator) to java.net.Socket. Then
HttpConnectSocketImpl, the socket implementation for a socket using an
http(s) proxy, would need to use the authenticator of its delegating socket
instead of the default one in the doTunnel method: this is a one line of
code change as HttpURLConnection already has support for setAuthenticator
from Java 9. Finally, SocksSocketImpl, the socket implementation for a
socket using a socks4/5 proxy, would need to use the authenticator of the
delegating socket in the authenticate method. instead of calling
Authenticator.requestPasswordAuthentication, which uses the default
authenticator.

I am happy to work on all, if any, of the enhancements that are considered
feasible.
I'm also looking forward to any possible criticism and feedback.
Thanks in advance.

I
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240512/f96cfba3/attachment-0001.htm>

From javalists at cbfiddle.com  Sun May 12 23:20:07 2024
From: javalists at cbfiddle.com (Alan Snyder)
Date: Sun, 12 May 2024 16:20:07 -0700
Subject: Fwd: RFR: 8322332: Add API to access ZipEntry.extraAttributes
References: <FF5E799B-241E-4988-B7FB-0A9DE2171425@cbfiddle.com>
Message-ID: <900B6DDB-C21D-48CE-9E87-00C4D9003F88@cbfiddle.com>


> 
> I?m not an expert on ZIp files, but from your description it would seem best to create a new field.
> 
> I agree that the version made by field is also needed.
> 
> 
>> On May 12, 2024, at 1:56?PM, - <liangchenblue at gmail.com> wrote:
>> 
>> Hi Alan Snyder,
>> Currently, JDK ZipEntry populates that extraAttributes (proposed to rename to externalFileAttributes in JDK-8321274, PR #16952) only if the high byte of the "version made by" field is 3 (indicating Linux compatibility) and only records the most significant 2 bytes for the copied ZipEntry. Since this is not the "external file attributes" field from the ZIP format, do you still think this field should be exposed, or should we create a new field to properly model the external file attributes? Also worth noting is the support for adjusting the "version made by" field, the "external file attributes" field might be misinterpreted without it.
>> 
>> P.S. Seems the Skara bridge is not propagating emails to GitHub comments.
>> 
>> On Sun, May 12, 2024 at 2:17?PM Alan Snyder <javalists at cbfiddle.com <mailto:javalists at cbfiddle.com>> wrote:
>>> > It might be interesting to explore that in the context of the zip file system provider, less sure about the java.util.zip APIs. 
>>> 
>>> I was not using the Zip file system. I was processing a Zip file.
>>> 
>>>   Alan
>>> 
>>> 
>>> 
>>> 
>>> 
>>> > On May 12, 2024, at 7:32?AM, Chen Liang <liach at openjdk.org <mailto:liach at openjdk.org>> wrote:
>>> > 
>>> > On Sun, 12 May 2024 02:48:31 GMT, xiaotaonan <duke at openjdk.org <mailto:duke at openjdk.org>> wrote:
>>> > 
>>> >> Add API to access ZipEntry.extraAttributes
>>> > 
>>> > Also see #16952, another patch that renames this field, which is planning for an integration soon; this PR will be out-of-date when that one is integrated.
>>> > 
>>> > -------------
>>> > 
>>> > PR Comment: https://git.openjdk.org/jdk/pull/19204#issuecomment-2106265843
>>> > 
>>> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240512/1dda0548/attachment.htm>

From liangchenblue at gmail.com  Mon May 13 02:32:27 2024
From: liangchenblue at gmail.com (-)
Date: Sun, 12 May 2024 21:32:27 -0500
Subject: RFR: 8322332: Add API to access ZipEntry.extraAttributes
In-Reply-To: <473FE79F-A401-46C2-BCF0-FA82CFE98041@gmail.com>
References: <gEx3mkdcX4M-B_tEwPrgcZZRUIV9z1yrMQg_XQrWPpU=.274f2648-f152-49dd-a658-7bb255a0cdc4@github.com>
 <Cv3DbgTqH71X2LY-mZnC1o29l3xpeFCEPx0uP0xqle4=.96cf1a23-cece-43d3-a8c4-2f37e24f00f4@github.com>
 <CA7E2A98-E9F0-4E4E-A064-31647CA3F4EB@cbfiddle.com>
 <CABe8uE1eOE-8RCC5CCynCT-RxuYZ-Qdc1C0xhEmOC0+ASvoT8g@mail.gmail.com>
 <473FE79F-A401-46C2-BCF0-FA82CFE98041@gmail.com>
Message-ID: <CABe8uE1JUjbU90cnCcCbj8SDww6rU5XN9Q7q_oFr8OPBSpH+Zg@mail.gmail.com>

Hi Mike,
I think this particular field has been renamed a few times; and ZipEntry
only exposes part of the ZIP format's fields. So most likely there isn't
sufficient information for most 3rd-party ZIP processing libraries. I
personally don't really use ZipFile so am not quite sure of the recent API
changes either.

On Sun, May 12, 2024 at 6:10?PM Michael Hall <mik3hall at gmail.com> wrote:

> I haven?t looked at any of this for sometime. But as I recall there was a
> possibility that other 3rd party applications might also be making use of
> these fields? IIRC there was some support for chaining multiple uses? Or
> the api may of changed and these aren?t the same fields or for some other
> reason what I remember is out of date.
>
> Mike
>
> On May 12, 2024, at 3:56?PM, - <liangchenblue at gmail.com> wrote:
>
> Hi Alan Snyder,
> Currently, JDK ZipEntry populates that extraAttributes (proposed to rename
> to externalFileAttributes in JDK-8321274, PR #16952) only if the high byte
> of the "version made by" field is 3 (indicating Linux compatibility) and
> only records the most significant 2 bytes for the copied ZipEntry.
> Since this is not the "external file attributes" field from the ZIP format,
> do you still think this field should be exposed, or should we create a new
> field to properly model the external file attributes? Also worth noting is
> the support for adjusting the "version made by" field, the "external file
> attributes" field might be misinterpreted without it.
>
> P.S. Seems the Skara bridge is not propagating emails to GitHub comments.
>
> On Sun, May 12, 2024 at 2:17?PM Alan Snyder <javalists at cbfiddle.com>
> wrote:
>
>> > It might be interesting to explore that in the context of the zip file
>> system provider, less sure about the java.util.zip APIs.
>>
>> I was not using the Zip file system. I was processing a Zip file.
>>
>>   Alan
>>
>>
>>
>>
>>
>> > On May 12, 2024, at 7:32?AM, Chen Liang <liach at openjdk.org> wrote:
>> >
>> > On Sun, 12 May 2024 02:48:31 GMT, xiaotaonan <duke at openjdk.org> wrote:
>> >
>> >> Add API to access ZipEntry.extraAttributes
>> >
>> > Also see #16952, another patch that renames this field, which is
>> planning for an integration soon; this PR will be out-of-date when that one
>> is integrated.
>> >
>> > -------------
>> >
>> > PR Comment:
>> https://git.openjdk.org/jdk/pull/19204#issuecomment-2106265843
>> >
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240512/bff0cd46/attachment.htm>

From jwaters at openjdk.org  Mon May 13 04:26:02 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Mon, 13 May 2024 04:26:02 GMT
Subject: RFR: 8330988: Implementation of 8288293: Windows/gcc Port for
 hsdis
In-Reply-To: <usSjNoHaMLDK2yN1CVz7X91uSIbpQslnD0hBtTFtnsw=.e7b4dede-07bf-41af-bef1-02672ef4758d@github.com>
References: <bXwOUFPBZUWDmidfDnVJLBKG4HkeS585IJqAOK8W1ys=.211183fe-b18e-498d-a557-6e6c4dfac27c@github.com>
 <usSjNoHaMLDK2yN1CVz7X91uSIbpQslnD0hBtTFtnsw=.e7b4dede-07bf-41af-bef1-02672ef4758d@github.com>
Message-ID: <0TRavDTT-tP_CWDMxGtcwZawPjWA_Ee5Uxcay8NXbao=.99b25023-3008-4172-b537-d8a78ccbe71b@github.com>

On Wed, 24 Apr 2024 09:15:21 GMT, Magnus Ihse Bursie <ihse 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.

@magicus?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18915#issuecomment-2106619396

From jai.forums2013 at gmail.com  Mon May 13 01:24:54 2024
From: jai.forums2013 at gmail.com (Jaikiran Pai)
Date: Mon, 13 May 2024 06:54:54 +0530
Subject: Enhance proxy support in java.net core libraries
In-Reply-To: <CAM0RScncCo+J2PMpEA71Ug8RXXL9QMP+KN86Y+h1x9kn_qm2AA@mail.gmail.com>
References: <CAM0RScncCo+J2PMpEA71Ug8RXXL9QMP+KN86Y+h1x9kn_qm2AA@mail.gmail.com>
Message-ID: <81b6026b-42b0-4220-9ceb-09d2549ad258@gmail.com>

Hello Alessandro,

I've moved this discussion to net-dev mailing list which is more 
relevant for this discussion (and Bcced core-libs-dev). If you haven't 
already subscribed to net-dev, then you can do it here 
https://mail.openjdk.org/mailman/listinfo/net-dev.

-Jaikiran

On 13/05/24 3:28 am, Alessandro Autiero wrote:
> Hello, my name is Alessandro Autiero and I'd like to propose three 
> enhancements for the java core libraries to better support proxies in 
> network components of the JDK.
>
> There are three classes in the java.net <http://java.net> package that 
> have proxy support:
>
>   * java.net.Socket
>     Introduced in Java 1.0, supports HTTP(S)/SOCKS proxies modelled by
>     java.net.Proxy through the java.net.Socket(java.net.Proxy) constructor
>   * java.net.HttpURLConnection
>     Introduced in Java 1.1, supports HTTP(S)/SOCKS proxies modelled by
>     java.net.Proxy through the
>     java.net.URL#openConnection(java.net.Proxy) public method
>   * java.net.HttpClient (Introduced in Java 11)
>     Introduced in Java 11, supports HTTP(S) proxies modelled by
>     java.net.ProxySelector through the public
>     proxy(java.net.ProxySelector) method in its builder or the default
>     java.net.ProxySelector, which can be set by calling
>     java.net.ProxySelector#setDefault(java.net.ProxySelector)
>
> While most proxies provide support for both the HTTP and SOCKS scheme, 
> considering that the older HTTP client API had support for both, 
> developers might choose to use the older api, or to use an external 
> one, if they need or want to provide support for this feature. A quick 
> Google search for a recommendation on which Http Client to use on a 
> modern Java version yields many results that list SOCKS support as a 
> feature to keep in mind when making a choice. While this is not 
> necessarily indicative of the average Java developer sentiment about 
> the feature, I think that it should be considered, alongside a couple 
> of issues that were opened on StackOverFlow 
> <https://stackoverflow.com/questions/70011046/how-to-use-a-socks-proxy-with-java-jdk-httpclient> 
> asking about support for this feature. Accordingly, I propose adding 
> support for SOCKS proxies in java.net.HttpClient. If the change is 
> allowed, consider that the default java.net.ProxySelector is an 
> instance of sun.net.spi.DefaultProxySelector, which supports SOCKS 
> proxies, but this implementation cannot be initialized by the user as 
> it's not exposed by the module system. Starting from Java 9, 
> ProxySelector#of(InetSocketAddress) was introduced, which returns an 
> instance of java.net.ProxySelector$StaticProxySelector 
> <https://github.com/openjdk/jdk/blob/5053b70a7fc67ce9b73dbeecbdd88fbc34d45e04/src/java.base/share/classes/java/net/ProxySelector.java#L194>, 
> a static inner class of ProxySelector introduced in Java 9 which only 
> implements support for HTTP(S) proxies. StaticProxySelector's 
> constructor could be modified from 
> StaticProxySelector(java.net.InetSocketAddress) to 
> StaticProxySelector(java.net.Proxy$Type, java.net.InetSocketAddress) 
> to initialize the java.net.Proxy instance with a specified proxy type 
> instead of hard coding HTTP. Then we could overload the method 
> ProxySelector#of(InetSocketAddress) with 
> ProxySelector#of(java.net.Proxy$Type, InetSocketAddress) method which 
> would invoke the constructor we defined earlier. This change would not 
> be breaking as StaticProxySelector is package private, no public 
> methods would be deleted and the default scheme would still be HTTP. 
> jdk.internal.net.http.HttpRequestImpl uses the ProxySelector in its 
> retrieveProxy method, but checks if the proxy is an HTTP proxy: this 
> would need to be changed as well. Finally, considering that unlike 
> HttpURLConnection, HttpClient doesn't delegate the underlying 
> connection to java.net.Socket, the java.net.http module would need to 
> be enhanced to support SOCKS authentication, which could take more effort.
>
> Another observation that I've made is about authentication. If a proxy 
> requires basic authentication, that is authentication through a 
> username and optionally a password, a developer can implement the 
> java.net.Authenticator class and override the 
> getPasswordAuthentication method. While basic authentication is still 
> the norm for most proxies, it's disabled by default in the JDK since 
> Java 8. Though, it's possible to enable it by overriding the net 
> properties jdk.http.auth.proxying.disabledSchemes and 
> jdk.http.auth.tunneling.disabledSchemes using System.setProperty. I 
> couldn't find an explanation about why this change was implemented, so 
> I can only speculate that it was done to incentivize Java developers 
> to use an IP whitelist instead of basic auth to improve security, 
> assuming that the connection isn't secure(HTTP). The problem though is 
> that the net properties that need to be changed to allow basic proxy 
> authentication are only read only one time in the static initializer 
> of sun.net.www.protocol.http.HttpURLConnection class, the underlying 
> implementation of java.net.HttpURLConnection. So, if for example a 
> library loads this class before the developer calls 
> System.setProperty, the change will have no effect and the 
> authentication will subsequently fail. This may seem like an edge 
> case, but for example in a Spring Boot environment, this exact issue 
> will arise if the property isn't set before calling 
> SpringApplication.run. I think that the best solution would be to 
> remove the disabledTunnelingSchemes and disabledProxyingSchemes static 
> fields from sun.net.www.protocol.http.HttpURLConnection and read the 
> net properties when they are used instead of caching them. This 
> solution is not a breaking change and should be very easy to implement 
> as both fields are only referenced when initializing a 
> AuthenticationHeader in the same class. Additionally, if we can agree 
> on the fact that basic authentication is still the predominant way to 
> provide authentication capabilities for a proxy and/or that disabling 
> it doesn't provide a direct security benefit, I propose to also set 
> jdk.http.auth.proxying.disabledSchemes and 
> jdk.http.auth.tunneling.disabledSchemes to an empty String so no 
> schemes are disabled by default. This change could be breaking for 
> Applications developed starting from Java 8 that expect basic 
> authentication to be disabled, but I think that the scope of the 
> impact would be much smaller, if there would be any at all, than when 
> these flags were introduced breaking basic authentication for existing 
> applications upgrading to Java 8.
>
> The last issue I've noticed is also about authentication. If a 
> developer wants to set an instance of Authenticator instead of relying 
> on the default one, which can be set using 
> Authenticator.setAuthenticator, this may not be possible depending on 
> the implementation:
>
>   * java.net.Socket
>     Not supported
>   * java.net.HttpURLConnection
>     Supported through the setAuthenticator(Authenticator) method
>     introduced in Java 9
>   * java.net.HttpClient
>     Supported through the authenticator(Authenticator) method in its
>     builder
>
> The reason why a developer might want to provide an instance of 
> Authenticator instead of relying on the default one is that, for 
> example, in a concurrent environment where multiple sockets exist, 
> each using a different proxy, if the proxy host and port are the same, 
> but each Socket instance is expected to use a different pair of 
> username and passwords, the default Authenticator cannot determine 
> which pair of credentials should be assigned to a given authentication 
> request as it lacks the scope to make this decision. This change is 
> not breaking as the default authenticator of a Socket would still be 
> the default authenticator, which is the current behaviour. If the 
> change is allowed, a possible solution would be to add a private field 
> named authenticator and a public method 
> setAuthenticator(Authenticator) to java.net.Socket. Then 
> HttpConnectSocketImpl, the socket implementation for a socket using an 
> http(s) proxy, would need to use the authenticator of its delegating 
> socket instead of the default one in the doTunnel method: this is a 
> one line of code change as HttpURLConnection already has support for 
> setAuthenticator from Java 9. Finally, SocksSocketImpl, the socket 
> implementation for a socket using a socks4/5 proxy, would need to use 
> the authenticator of the delegating socket in the authenticate method. 
> instead of calling Authenticator.requestPasswordAuthentication, which 
> uses the default authenticator.
>
> I am happy to work on all, if any, of the enhancements that are 
> considered feasible.
> I'm also looking forward to any possible criticism and feedback.
> Thanks in advance.
>
> I
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240513/d8636596/attachment.htm>

From duke at openjdk.org  Mon May 13 06:30:15 2024
From: duke at openjdk.org (Korov)
Date: Mon, 13 May 2024 06:30:15 GMT
Subject: RFR: 8292955: Collections.checkedMap Map.merge does not properly
 check key and value [v3]
In-Reply-To: <KQYW7IawS6gwsNsRrwaPkvWLfuapu-CJK6Sey-nIsNk=.4d0eeacd-5484-430f-ae99-8d5e124d4e8f@github.com>
References: <uYx7ZckdmpZfQzBBlp-i5gZXe1Y6lKaZ3WfynZJbdeU=.0b7fd470-f97e-40b6-989a-5fd0e5e4e179@github.com>
 <KQYW7IawS6gwsNsRrwaPkvWLfuapu-CJK6Sey-nIsNk=.4d0eeacd-5484-430f-ae99-8d5e124d4e8f@github.com>
Message-ID: <K1X_gWksycSLYTyxwbU9Gnv1-1TNsLHtEcFKWYIOM00=.569ab74a-08e0-40bb-ae30-34fd925294d3@github.com>

On Thu, 7 Mar 2024 05:33:16 GMT, Korov <duke at openjdk.org> wrote:

>> When the specified key did not associated with a value, should check the `key` and `value` type.
>
> Korov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use testNG builtin functionalities and modify the test function name

Hi @stuart-marks , Can you take a moment to review my PR? thank you very much for your help!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18141#issuecomment-2106749421

From alanb at openjdk.org  Mon May 13 06:44:30 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 13 May 2024 06:44:30 GMT
Subject: RFR: 8331670: Deprecate the Memory-Access Methods in sun.misc.Unsafe
 for Removal
Message-ID: <9FyO4QpCtH2CNkUEE78_Jjd9xs3bv3WJo16jyowHOvY=.e7131b91-37bb-4624-a60e-72a427a24c92@github.com>

This is the implementation changes for JEP 471.

The methods in sun.misc.Unsafe for on-heap and off-heap access are deprecated for removal. This means a removal warning at compile time. No methods have been removed. A deprecated message is added to each of the methods but unlikely to be seen as the JDK does not generate or publish the API docs for this class.

A new command line option --sun-misc-unsafe-memory-access=$value is introduced to allow or deny access to these methods. The default proposed for JDK 23 is "allow" so no change in behavior compared to JDK 22 or previous releases.

A new test is added to test the command line option settings. The existing micros for FFM that use Unsafe are updated to suppress the removal warning at compile time. A new micro is introduced with a small sample of methods to ensure the changes doesn't cause any perf regressions.

For now, the changes include the update to the man page for the "java" command. It might be that this has to be separated out so that it goes with other updates in the release.

-------------

Commit messages:
 - Update man page
 - Fix comment
 - Merge
 - Merge
 - Whitespace
 - Initial commit

Changes: https://git.openjdk.org/jdk/pull/19174/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19174&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8331670
  Stats: 1251 lines in 26 files changed: 1152 ins; 5 del; 94 mod
  Patch: https://git.openjdk.org/jdk/pull/19174.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19174/head:pull/19174

PR: https://git.openjdk.org/jdk/pull/19174

From liach at openjdk.org  Mon May 13 06:44:30 2024
From: liach at openjdk.org (Chen Liang)
Date: Mon, 13 May 2024 06:44:30 GMT
Subject: RFR: 8331670: Deprecate the Memory-Access Methods in
 sun.misc.Unsafe for Removal
In-Reply-To: <9FyO4QpCtH2CNkUEE78_Jjd9xs3bv3WJo16jyowHOvY=.e7131b91-37bb-4624-a60e-72a427a24c92@github.com>
References: <9FyO4QpCtH2CNkUEE78_Jjd9xs3bv3WJo16jyowHOvY=.e7131b91-37bb-4624-a60e-72a427a24c92@github.com>
Message-ID: <_axx_goUOAkzSFHrdbCQM5Q28TMKO8Liiv74vIcuooM=.9a44d077-06e1-4445-8287-77bd89fd36cd@github.com>

On Fri, 10 May 2024 10:06:55 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> This is the implementation changes for JEP 471.
> 
> The methods in sun.misc.Unsafe for on-heap and off-heap access are deprecated for removal. This means a removal warning at compile time. No methods have been removed. A deprecated message is added to each of the methods but unlikely to be seen as the JDK does not generate or publish the API docs for this class.
> 
> A new command line option --sun-misc-unsafe-memory-access=$value is introduced to allow or deny access to these methods. The default proposed for JDK 23 is "allow" so no change in behavior compared to JDK 22 or previous releases.
> 
> A new test is added to test the command line option settings. The existing micros for FFM that use Unsafe are updated to suppress the removal warning at compile time. A new micro is introduced with a small sample of methods to ensure the changes doesn't cause any perf regressions.
> 
> For now, the changes include the update to the man page for the "java" command. It might be that this has to be separated out so that it goes with other updates in the release.

Should `Unsafe.pageSize` be deprecated for removal too?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19174#issuecomment-2104606294

From duke at openjdk.org  Mon May 13 06:44:30 2024
From: duke at openjdk.org (ExE Boss)
Date: Mon, 13 May 2024 06:44:30 GMT
Subject: RFR: 8331670: Deprecate the Memory-Access Methods in
 sun.misc.Unsafe for Removal
In-Reply-To: <_axx_goUOAkzSFHrdbCQM5Q28TMKO8Liiv74vIcuooM=.9a44d077-06e1-4445-8287-77bd89fd36cd@github.com>
References: <9FyO4QpCtH2CNkUEE78_Jjd9xs3bv3WJo16jyowHOvY=.e7131b91-37bb-4624-a60e-72a427a24c92@github.com>
 <_axx_goUOAkzSFHrdbCQM5Q28TMKO8Liiv74vIcuooM=.9a44d077-06e1-4445-8287-77bd89fd36cd@github.com>
Message-ID: <PpdODLYLnCgBa4mCijVxOgN59crG9zqVJA4sP_IerMY=.826453e2-8b1f-4349-a9bf-40537b16d51c@github.com>

On Fri, 10 May 2024 13:24:53 GMT, Chen Liang <liach at openjdk.org> wrote:

>> This is the implementation changes for JEP 471.
>> 
>> The methods in sun.misc.Unsafe for on-heap and off-heap access are deprecated for removal. This means a removal warning at compile time. No methods have been removed. A deprecated message is added to each of the methods but unlikely to be seen as the JDK does not generate or publish the API docs for this class.
>> 
>> A new command line option --sun-misc-unsafe-memory-access=$value is introduced to allow or deny access to these methods. The default proposed for JDK 23 is "allow" so no change in behavior compared to JDK 22 or previous releases.
>> 
>> A new test is added to test the command line option settings. The existing micros for FFM that use Unsafe are updated to suppress the removal warning at compile time. A new micro is introduced with a small sample of methods to ensure the changes doesn't cause any perf regressions.
>> 
>> For now, the changes include the update to the man page for the "java" command. It might be that this has to be separated out so that it goes with other updates in the release.
>
> Should `Unsafe.pageSize` be deprecated for removal too?

@liach
> Should `Unsafe.pageSize` be deprecated for removal too?

The?three remaining?methods `Unsafe?::pageSize()`, `Unsafe?::throwException?(Throwable)`, and?`Unsafe?::allocateInstance?(Class)` are?left for?future?JEPs:
- https://openjdk.org/jeps/471#Future-Work

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19174#issuecomment-2105400547

From alanb at openjdk.org  Mon May 13 06:50:04 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 13 May 2024 06:50:04 GMT
Subject: RFR: 8322332: Add API to access ZipEntry.extraAttributes
In-Reply-To: <CA7E2A98-E9F0-4E4E-A064-31647CA3F4EB@cbfiddle.com>
References: <gEx3mkdcX4M-B_tEwPrgcZZRUIV9z1yrMQg_XQrWPpU=.274f2648-f152-49dd-a658-7bb255a0cdc4@github.com>
 <CA7E2A98-E9F0-4E4E-A064-31647CA3F4EB@cbfiddle.com>
Message-ID: <invLSU17gYqxJgjm7p4jRm7VI7vmmBZXNQZKn6UhbIs=.68f79c34-2dc8-47bd-82ef-9dcdde34a130@github.com>

On Sun, 12 May 2024 21:44:56 GMT, Alan Snyder <javalists at cbfiddle.com> wrote:

> I was not using the Zip file system. I was processing a Zip file.

They are equivalent, the suggestion to look at the sym link support in the zip file system provider is that it's a much better fit for this extension. It already has optional support for POSIX file permissions and the APIs for dealing with sym links.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19204#issuecomment-2106776812

From pminborg at openjdk.org  Mon May 13 07:02:01 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 13 May 2024 07:02:01 GMT
Subject: RFR: 8331670: Deprecate the Memory-Access Methods in
 sun.misc.Unsafe for Removal
In-Reply-To: <9FyO4QpCtH2CNkUEE78_Jjd9xs3bv3WJo16jyowHOvY=.e7131b91-37bb-4624-a60e-72a427a24c92@github.com>
References: <9FyO4QpCtH2CNkUEE78_Jjd9xs3bv3WJo16jyowHOvY=.e7131b91-37bb-4624-a60e-72a427a24c92@github.com>
Message-ID: <a1w0_TRzZdeEqHVmEZmVHWHxd-ggOywPsy1CmV_6a7c=.360a7902-c2bb-46ab-b148-b12d1a73fbe2@github.com>

On Fri, 10 May 2024 10:06:55 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> This is the implementation changes for JEP 471.
> 
> The methods in sun.misc.Unsafe for on-heap and off-heap access are deprecated for removal. This means a removal warning at compile time. No methods have been removed. A deprecated message is added to each of the methods but unlikely to be seen as the JDK does not generate or publish the API docs for this class.
> 
> A new command line option --sun-misc-unsafe-memory-access=$value is introduced to allow or deny access to these methods. The default proposed for JDK 23 is "allow" so no change in behavior compared to JDK 22 or previous releases.
> 
> A new test is added to test the command line option settings. The existing micros for FFM that use Unsafe are updated to suppress the removal warning at compile time. A new micro is introduced with a small sample of methods to ensure the changes doesn't cause any perf regressions.
> 
> For now, the changes include the update to the man page for the "java" command. It might be that this has to be separated out so that it goes with other updates in the release.

Would it make sense to add some verbiage in the JavaDocs for `sun.misc.Unsafe` that indicates the planned direction for said class and the use of the new command line options?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19174#issuecomment-2106795327

From egahlin at openjdk.org  Mon May 13 07:27:02 2024
From: egahlin at openjdk.org (Erik Gahlin)
Date: Mon, 13 May 2024 07:27:02 GMT
Subject: RFR: 8331876: JFR: Move file read and write events to java.base
 [v4]
In-Reply-To: <DDe0bKCC86AawVl7RylZ74uvvLBr2Zljpkcmxx1_WEU=.61cc10c6-b635-42dd-a850-b32ae1d68585@github.com>
References: <DDe0bKCC86AawVl7RylZ74uvvLBr2Zljpkcmxx1_WEU=.61cc10c6-b635-42dd-a850-b32ae1d68585@github.com>
Message-ID: <orxiCLyv-5n8SPBJsB-OCeNxhdq9eb9FwS6VwO0Fd3o=.9ce278cc-912a-4d63-83f0-feb9826c0d8c@github.com>

> Hi,
> 
> Could I have a review of a change that moves the jdk.FileRead and jdk.FileWrite events to java.base to remove the use of the ASM instrumentation.
> 
> Testing: jdk/jdk/jfr
> 
> Thanks
> Erik

Erik Gahlin has updated the pull request incrementally with three additional commits since the last revision:

 - Revert accidental push
 - Improve comments. Fix nit
 - Revert accidental push of removal JI* classes. Will be handled seperately

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19129/files
  - new: https://git.openjdk.org/jdk/pull/19129/files/fc54e205..f2439ac3

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19129&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19129&range=02-03

  Stats: 1223 lines in 19 files changed: 986 ins; 226 del; 11 mod
  Patch: https://git.openjdk.org/jdk/pull/19129.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19129/head:pull/19129

PR: https://git.openjdk.org/jdk/pull/19129

From alanb at openjdk.org  Mon May 13 07:42:05 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 13 May 2024 07:42:05 GMT
Subject: RFR: 8331670: Deprecate the Memory-Access Methods in
 sun.misc.Unsafe for Removal
In-Reply-To: <a1w0_TRzZdeEqHVmEZmVHWHxd-ggOywPsy1CmV_6a7c=.360a7902-c2bb-46ab-b148-b12d1a73fbe2@github.com>
References: <9FyO4QpCtH2CNkUEE78_Jjd9xs3bv3WJo16jyowHOvY=.e7131b91-37bb-4624-a60e-72a427a24c92@github.com>
 <a1w0_TRzZdeEqHVmEZmVHWHxd-ggOywPsy1CmV_6a7c=.360a7902-c2bb-46ab-b148-b12d1a73fbe2@github.com>
Message-ID: <sXRd6CRlngU5MqevERrL9F896OrW0HqZMbnqfCOiPXU=.67afb6c4-8f6f-4ddf-8725-bc74c8f8f52d@github.com>

On Mon, 13 May 2024 06:58:42 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> Would it make sense to add some verbiage in the JavaDocs for `sun.misc.Unsafe` that indicates the planned direction for said class and the use of the new command line options?

There is an API note to say that the class predates VarHandle and the FFM APIs and that the API shouldn't be used fr new code.  We could add more and a link to the JEP might help. That said,  JDK doesn't generate or publish the API docs for this class, it will only be read if someone looks at the source file.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19174#issuecomment-2106862649

From asotona at openjdk.org  Mon May 13 07:54:09 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 13 May 2024 07:54:09 GMT
Subject: RFR: 8331291: java.lang.classfile.Attributes class performs a lot
 of static initializations [v8]
In-Reply-To: <3eERzqYdCd4f9qn4KpzBA9ealaUTzC67wIhzB18ETTE=.f9d17a6f-1ca5-477f-8344-40c20abe7d7e@github.com>
References: <SHIvjbwCWBPERKxlytEsY_O_kEiJbSeEmSusuDwjTIw=.ae8dd21e-a822-476e-9760-dd489532dbf1@github.com>
 <UielWbqtQPeaoAfpuHYPMzn8N6ViEH0T0h6WXHscUrk=.e4d333d7-6ae3-447f-9b5f-d0a77d29c416@github.com>
 <3eERzqYdCd4f9qn4KpzBA9ealaUTzC67wIhzB18ETTE=.f9d17a6f-1ca5-477f-8344-40c20abe7d7e@github.com>
Message-ID: <8bkIrXCl7OsuLoMQi43faVELq0d1R-P60pSCGkxpwpU=.fe207403-8288-4f2d-ab7d-96fec5ba212e@github.com>

On Sun, 12 May 2024 15:11:17 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fixed tests
>
> src/java.base/share/classes/java/lang/classfile/Attributes.java line 153:
> 
>> 151: 
>> 152:     /**
>> 153:      * {@return Attribute mapper for the {@code AnnotationDefault} attribute}
> 
> Just wondering, can we change `{@code AnnotationDefault}` to `{@value #NAME_ANNOTATION_DEFAULT}`, etc? This way, the names are still rendered as code in Javadoc HTML, but they are generated with links to the constants, and programmers will see these constants and prefer them over hardcoded values.

On the other side it is questionable if the attribute names should be exposed in the API. We provide corresponding mappers and attribute models. I don't see a case where user would need to use the attribute names directly.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19006#discussion_r1598026518

From jlahoda at openjdk.org  Mon May 13 08:19:16 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Mon, 13 May 2024 08:19:16 GMT
Subject: Integrated: 8331535: Incorrect prompt for Console.readLine
In-Reply-To: <IQvUAYG5zj0JqUbWiQiryAuBrtV6jrVCvy9useQZmlc=.a4dd8dfc-e835-4405-83f8-fd1bda8480f6@github.com>
References: <IQvUAYG5zj0JqUbWiQiryAuBrtV6jrVCvy9useQZmlc=.a4dd8dfc-e835-4405-83f8-fd1bda8480f6@github.com>
Message-ID: <QNbMvTXgnwCWrjAtSFJEDSQeQGjvhb8QU_DiTSJNSwo=.e90590b6-aacb-4bae-bfa9-fdf6a2eda631@github.com>

On Fri, 3 May 2024 10:11:02 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> When JLine reads a line, there may be a prompt provided. However, JLine will not interpret the prompt literally, it will handle `%` specially. As a consequence, doing:
> 
> System.console().readLine("%%s");
> 
> 
> will not print `%s`, as first `String.format` is used, which will convert `%%s` to `%s`, and then JLine will interpret the `%`. The proposed solution is to duplicate the `%`, so that JLine will print it.

This pull request has now been integrated.

Changeset: 5a8df410
Author:    Jan Lahoda <jlahoda at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/5a8df4106ac5386eb72e874dcadf2b18defe27d8
Stats:     296 lines in 6 files changed: 291 ins; 0 del; 5 mod

8331535: Incorrect prompt for Console.readLine
8331681: Test that jdk.internal.io.JdkConsole does not interpret prompts

Reviewed-by: naoto, asotona

-------------

PR: https://git.openjdk.org/jdk/pull/19081

From Alan.Bateman at oracle.com  Mon May 13 08:24:40 2024
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Mon, 13 May 2024 09:24:40 +0100
Subject: Enhance proxy support in java.net core libraries
In-Reply-To: <CAM0RScncCo+J2PMpEA71Ug8RXXL9QMP+KN86Y+h1x9kn_qm2AA@mail.gmail.com>
References: <CAM0RScncCo+J2PMpEA71Ug8RXXL9QMP+KN86Y+h1x9kn_qm2AA@mail.gmail.com>
Message-ID: <7155fdaf-5969-4691-ae3a-3c50c902611a@oracle.com>


The OpenJDK net-dev mailing list is the best place to bring this. There 
was discussion about SOCKS when the HTTP client was developed, I thought 
JEP 321 had a summary on this but it seems not. I'm sure others on 
net-dev can say more on this.

-Alan


On 12/05/2024 22:58, Alessandro Autiero wrote:
> Hello, my name is Alessandro Autiero and I'd like to propose three 
> enhancements for the java core libraries to better support proxies in 
> network components of the JDK.
>
> There are three classes in the java.net <http://java.net> package that 
> have proxy support:
>
>   * java.net.Socket
>     Introduced in Java 1.0, supports HTTP(S)/SOCKS proxies modelled by
>     java.net.Proxy through the java.net.Socket(java.net.Proxy) constructor
>   * java.net.HttpURLConnection
>     Introduced in Java 1.1, supports HTTP(S)/SOCKS proxies modelled by
>     java.net.Proxy through the
>     java.net.URL#openConnection(java.net.Proxy) public method
>   * java.net.HttpClient (Introduced in Java 11)
>     Introduced in Java 11, supports HTTP(S) proxies modelled by
>     java.net.ProxySelector through the public
>     proxy(java.net.ProxySelector) method in its builder or the default
>     java.net.ProxySelector, which can be set by calling
>     java.net.ProxySelector#setDefault(java.net.ProxySelector)
>
> While most proxies provide support for both the HTTP and SOCKS scheme, 
> considering that the older HTTP client API had support for both, 
> developers might choose to use the older api, or to use an external 
> one, if they need or want to provide support for this feature. A quick 
> Google search for a recommendation on which Http Client to use on a 
> modern Java version yields many results that list SOCKS support as a 
> feature to keep in mind when making a choice. While this is not 
> necessarily indicative of the average Java developer sentiment about 
> the feature, I think that it should be considered, alongside a couple 
> of issues that were opened on StackOverFlow 
> <https://stackoverflow.com/questions/70011046/how-to-use-a-socks-proxy-with-java-jdk-httpclient> 
> asking about support for this feature. Accordingly, I propose adding 
> support for SOCKS proxies in java.net.HttpClient. If the change is 
> allowed, consider that the default java.net.ProxySelector is an 
> instance of sun.net.spi.DefaultProxySelector, which supports SOCKS 
> proxies, but this implementation cannot be initialized by the user as 
> it's not exposed by the module system. Starting from Java 9, 
> ProxySelector#of(InetSocketAddress) was introduced, which returns an 
> instance of java.net.ProxySelector$StaticProxySelector 
> <https://github.com/openjdk/jdk/blob/5053b70a7fc67ce9b73dbeecbdd88fbc34d45e04/src/java.base/share/classes/java/net/ProxySelector.java#L194>, 
> a static inner class of ProxySelector introduced in Java 9 which only 
> implements support for HTTP(S) proxies. StaticProxySelector's 
> constructor could be modified from 
> StaticProxySelector(java.net.InetSocketAddress) to 
> StaticProxySelector(java.net.Proxy$Type, java.net.InetSocketAddress) 
> to initialize the java.net.Proxy instance with a specified proxy type 
> instead of hard coding HTTP. Then we could overload the method 
> ProxySelector#of(InetSocketAddress) with 
> ProxySelector#of(java.net.Proxy$Type, InetSocketAddress) method which 
> would invoke the constructor we defined earlier. This change would not 
> be breaking as StaticProxySelector is package private, no public 
> methods would be deleted and the default scheme would still be HTTP. 
> jdk.internal.net.http.HttpRequestImpl uses the ProxySelector in its 
> retrieveProxy method, but checks if the proxy is an HTTP proxy: this 
> would need to be changed as well. Finally, considering that unlike 
> HttpURLConnection, HttpClient doesn't delegate the underlying 
> connection to java.net.Socket, the java.net.http module would need to 
> be enhanced to support SOCKS authentication, which could take more effort.
>
> Another observation that I've made is about authentication. If a proxy 
> requires basic authentication, that is authentication through a 
> username and optionally a password, a developer can implement the 
> java.net.Authenticator class and override the 
> getPasswordAuthentication method. While basic authentication is still 
> the norm for most proxies, it's disabled by default in the JDK since 
> Java 8. Though, it's possible to enable it by overriding the net 
> properties jdk.http.auth.proxying.disabledSchemes and 
> jdk.http.auth.tunneling.disabledSchemes using System.setProperty. I 
> couldn't find an explanation about why this change was implemented, so 
> I can only speculate that it was done to incentivize Java developers 
> to use an IP whitelist instead of basic auth to improve security, 
> assuming that the connection isn't secure(HTTP). The problem though is 
> that the net properties that need to be changed to allow basic proxy 
> authentication are only read only one time in the static initializer 
> of sun.net.www.protocol.http.HttpURLConnection class, the underlying 
> implementation of java.net.HttpURLConnection. So, if for example a 
> library loads this class before the developer calls 
> System.setProperty, the change will have no effect and the 
> authentication will subsequently fail. This may seem like an edge 
> case, but for example in a Spring Boot environment, this exact issue 
> will arise if the property isn't set before calling 
> SpringApplication.run. I think that the best solution would be to 
> remove the disabledTunnelingSchemes and disabledProxyingSchemes static 
> fields from sun.net.www.protocol.http.HttpURLConnection and read the 
> net properties when they are used instead of caching them. This 
> solution is not a breaking change and should be very easy to implement 
> as both fields are only referenced when initializing a 
> AuthenticationHeader in the same class. Additionally, if we can agree 
> on the fact that basic authentication is still the predominant way to 
> provide authentication capabilities for a proxy and/or that disabling 
> it doesn't provide a direct security benefit, I propose to also set 
> jdk.http.auth.proxying.disabledSchemes and 
> jdk.http.auth.tunneling.disabledSchemes to an empty String so no 
> schemes are disabled by default. This change could be breaking for 
> Applications developed starting from Java 8 that expect basic 
> authentication to be disabled, but I think that the scope of the 
> impact would be much smaller, if there would be any at all, than when 
> these flags were introduced breaking basic authentication for existing 
> applications upgrading to Java 8.
>
> The last issue I've noticed is also about authentication. If a 
> developer wants to set an instance of Authenticator instead of relying 
> on the default one, which can be set using 
> Authenticator.setAuthenticator, this may not be possible depending on 
> the implementation:
>
>   * java.net.Socket
>     Not supported
>   * java.net.HttpURLConnection
>     Supported through the setAuthenticator(Authenticator) method
>     introduced in Java 9
>   * java.net.HttpClient
>     Supported through the authenticator(Authenticator) method in its
>     builder
>
> The reason why a developer might want to provide an instance of 
> Authenticator instead of relying on the default one is that, for 
> example, in a concurrent environment where multiple sockets exist, 
> each using a different proxy, if the proxy host and port are the same, 
> but each Socket instance is expected to use a different pair of 
> username and passwords, the default Authenticator cannot determine 
> which pair of credentials should be assigned to a given authentication 
> request as it lacks the scope to make this decision. This change is 
> not breaking as the default authenticator of a Socket would still be 
> the default authenticator, which is the current behaviour. If the 
> change is allowed, a possible solution would be to add a private field 
> named authenticator and a public method 
> setAuthenticator(Authenticator) to java.net.Socket. Then 
> HttpConnectSocketImpl, the socket implementation for a socket using an 
> http(s) proxy, would need to use the authenticator of its delegating 
> socket instead of the default one in the doTunnel method: this is a 
> one line of code change as HttpURLConnection already has support for 
> setAuthenticator from Java 9. Finally, SocksSocketImpl, the socket 
> implementation for a socket using a socks4/5 proxy, would need to use 
> the authenticator of the delegating socket in the authenticate method. 
> instead of calling Authenticator.requestPasswordAuthentication, which 
> uses the default authenticator.
>
> I am happy to work on all, if any, of the enhancements that are 
> considered feasible.
> I'm also looking forward to any possible criticism and feedback.
> Thanks in advance.
>
> I
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240513/f37b80aa/attachment-0001.htm>

From mik3hall at gmail.com  Mon May 13 08:38:26 2024
From: mik3hall at gmail.com (Michael Hall)
Date: Mon, 13 May 2024 03:38:26 -0500
Subject: RFR: 8322332: Add API to access ZipEntry.extraAttributes
In-Reply-To: <CABe8uE1JUjbU90cnCcCbj8SDww6rU5XN9Q7q_oFr8OPBSpH+Zg@mail.gmail.com>
References: <gEx3mkdcX4M-B_tEwPrgcZZRUIV9z1yrMQg_XQrWPpU=.274f2648-f152-49dd-a658-7bb255a0cdc4@github.com>
 <Cv3DbgTqH71X2LY-mZnC1o29l3xpeFCEPx0uP0xqle4=.96cf1a23-cece-43d3-a8c4-2f37e24f00f4@github.com>
 <CA7E2A98-E9F0-4E4E-A064-31647CA3F4EB@cbfiddle.com>
 <CABe8uE1eOE-8RCC5CCynCT-RxuYZ-Qdc1C0xhEmOC0+ASvoT8g@mail.gmail.com>
 <473FE79F-A401-46C2-BCF0-FA82CFE98041@gmail.com>
 <CABe8uE1JUjbU90cnCcCbj8SDww6rU5XN9Q7q_oFr8OPBSpH+Zg@mail.gmail.com>
Message-ID: <A7EB7B09-380C-418F-A5EE-5BFBA695C0AC@gmail.com>

I was thinking of zip api?s other than java?s. The field needs to be at a fixed place in the file format whatever the name? Unless a significant api change has been made.

A couple of links from googling on ?zip extra field chaining"

https://libzip.org/specifications/extrafld.txt
https://www.hackerfactor.com/blog/index.php?/archives/405-Keeping-Zip.html

If this were strictly jar files I would be less concerned but zip is widely used outside of java so more chances for conflict where java doesn?t have anything like ownership.
At the time I looked at it the provision for ?user? additions was very limited again making conflict more likely.

> On May 12, 2024, at 9:32?PM, - <liangchenblue at gmail.com> wrote:
> 
> Hi Mike,
> I think this particular field has been renamed a few times; and ZipEntry only exposes part of the ZIP format's fields. So most likely there isn't sufficient information for most 3rd-party ZIP processing libraries. I personally don't really use ZipFile so am not quite sure of the recent API changes either.
> 
> On Sun, May 12, 2024 at 6:10?PM Michael Hall <mik3hall at gmail.com <mailto:mik3hall at gmail.com>> wrote:
>> I haven?t looked at any of this for sometime. But as I recall there was a possibility that other 3rd party applications might also be making use of these fields? IIRC there was some support for chaining multiple uses? Or the api may of changed and these aren?t the same fields or for some other reason what I remember is out of date. 
>> 
>> Mike
>> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240513/d4d768df/attachment.htm>

From rgiulietti at openjdk.org  Mon May 13 08:52:22 2024
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Mon, 13 May 2024 08:52:22 GMT
Subject: RFR: 8332086: Remove the usage of ServiceLoader in
 j.u.r.RandomGeneratorFactory
Message-ID: <hfB86NksORc-aC6zVxHel_QQd_9aB629SfQjXvl6q5U=.e31daa4b-5cf6-4f3f-a757-79e818a18978@github.com>

All random number generator algorithms are implemented in module `java.base`. The usage of `ServiceLoader` in `j.u.r.RandomGeneratorFactory` is no longer needed.

-------------

Commit messages:
 - 8332086: Remove the usage of ServiceLoader in j.u.r.RandomGeneratorFactory

Changes: https://git.openjdk.org/jdk/pull/19212/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19212&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8332086
  Stats: 204 lines in 4 files changed: 51 ins; 45 del; 108 mod
  Patch: https://git.openjdk.org/jdk/pull/19212.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19212/head:pull/19212

PR: https://git.openjdk.org/jdk/pull/19212

From rgiulietti at openjdk.org  Mon May 13 09:07:11 2024
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Mon, 13 May 2024 09:07:11 GMT
Subject: RFR: 8332086: Remove the usage of ServiceLoader in
 j.u.r.RandomGeneratorFactory
In-Reply-To: <hfB86NksORc-aC6zVxHel_QQd_9aB629SfQjXvl6q5U=.e31daa4b-5cf6-4f3f-a757-79e818a18978@github.com>
References: <hfB86NksORc-aC6zVxHel_QQd_9aB629SfQjXvl6q5U=.e31daa4b-5cf6-4f3f-a757-79e818a18978@github.com>
Message-ID: <iZAFJi7fMkq31Xec0Fv26jLDlnpX_ssPWkwKJYcnwXU=.fd43c22b-cd35-414a-a52d-bc15c4142b5c@github.com>

On Mon, 13 May 2024 08:47:50 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

> All random number generator algorithms are implemented in module `java.base`. The usage of `ServiceLoader` in `j.u.r.RandomGeneratorFactory` is no longer needed.

This is a followup of [18932](https://github.com/openjdk/jdk/pull/18932) in which all random number generator algorithms have been moved to module `java.base` and module `jdk.random` has been removed.

Reliance on `ServiceLoader` in `j.u.r.RandomGeneratorFactory` is no longer needed and has been replaced by a (lazily populated) map from algorithm names to classes.

Moreover, methods `RandomGeneratorFactory.create(long)` and `create(byte[])` now throw an `UnsupportedOperationException` rather than silently falling back to the no-arg `create()` in case the underlying algorithm does not support a `long` resp. `byte[]` seed.

Tests in tier1-tier3 pass after adaptations on the existing `RandomTestCoverage`.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19212#issuecomment-2107034744

From liach at openjdk.org  Mon May 13 09:14:14 2024
From: liach at openjdk.org (Chen Liang)
Date: Mon, 13 May 2024 09:14:14 GMT
Subject: Integrated: 8327499: MethodHandleStatics.traceLambdaForm includes
 methods that cannot be generated
In-Reply-To: <twyi1CnAbWs33Rd0KieD7bbXYRVL6lQgfZ4HqvAVrCQ=.003fcea0-799c-4ba7-a6a1-cf3d72c99cfb@github.com>
References: <twyi1CnAbWs33Rd0KieD7bbXYRVL6lQgfZ4HqvAVrCQ=.003fcea0-799c-4ba7-a6a1-cf3d72c99cfb@github.com>
Message-ID: <yuIm6N6Ce5DWWTT6YNbZqBKsyEgLEHYH75KQdTW7DG4=.95ec636d-293d-4e0e-a3b0-5472d01ddbda@github.com>

On Fri, 10 May 2024 00:45:31 GMT, Chen Liang <liach at openjdk.org> wrote:

> GenerateJLIClassesHelper has been making wrong assumptions about Invoker's LambdaForm method type parameters. Since they are distinct from those of Linkers, they are now tracked and generated separately. It seems that no proper invoker was ever generated before, except it happens that most invoker signatures can be taken as linker signature so we never detected it.
> 
> Requesting @iklam for a review; since I don't know how to deal with CDS, I have to relay to someone else to ensure this fixes the problem from the CDS side as well.

This pull request has now been integrated.

Changeset: adaa509b
Author:    Chen Liang <liach at openjdk.org>
Committer: Claes Redestad <redestad at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/adaa509b6ed3d12569b8e5f2ec802cef22ab53c7
Stats:     151 lines in 5 files changed: 117 ins; 11 del; 23 mod

8327499: MethodHandleStatics.traceLambdaForm includes methods that cannot be generated

Reviewed-by: redestad, iklam

-------------

PR: https://git.openjdk.org/jdk/pull/19164

From prappo at openjdk.org  Mon May 13 09:56:35 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Mon, 13 May 2024 09:56:35 GMT
Subject: RFR: 8305457: Implement java.io.IO [v9]
In-Reply-To: <w2msiw_qaMEIJS3s9D4bg8pFbz5WIF0KdP6Mm-XFjLI=.85b2020b-8c46-4bac-8a69-4975b068f2ff@github.com>
References: <w2msiw_qaMEIJS3s9D4bg8pFbz5WIF0KdP6Mm-XFjLI=.85b2020b-8c46-4bac-8a69-4975b068f2ff@github.com>
Message-ID: <PIg24sny09iDwNT6W--TkoqtY8V2tXWCjrUL4MO-CRg=.67519d97-15b9-4b72-9bdc-ecbcc3dbfd5c@github.com>

> Please review this PR which introduces the `java.io.IO` top-level class and three methods to `java.io.Console` for [Implicitly Declared Classes and Instance Main Methods (Third Preview)].
> 
> This PR has been obtained as `git merge --squash` of a now obsolete [draft PR].
> 
> [Implicitly Declared Classes and Instance Main Methods (Third Preview)]: https://bugs.openjdk.org/browse/JDK-8323335
> [draft PR]: https://github.com/openjdk/jdk/pull/18921

Pavel Rappo has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 17 additional commits since the last revision:

 - Escape prompt
 - Merge branch 'master' into 8305457-Implement-java.io.IO
 - Clarify input charset
 - Make IO final
 - Fix System.console().readln(null) in jshell
   
   Without it, jshell hangs on me. Will think of a test.
 - Fix typo
 - Merge branch 'master' into 8305457-Implement-java.io.IO
 - Simplify output.exp
 - Cover null prompt in input tests
 - Make input test parametric
 - ... and 7 more: https://git.openjdk.org/jdk/compare/5ac71ae9...17100ab8

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19112/files
  - new: https://git.openjdk.org/jdk/pull/19112/files/43a95732..17100ab8

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19112&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19112&range=07-08

  Stats: 3238 lines in 113 files changed: 2069 ins; 612 del; 557 mod
  Patch: https://git.openjdk.org/jdk/pull/19112.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19112/head:pull/19112

PR: https://git.openjdk.org/jdk/pull/19112

From alanb at openjdk.org  Mon May 13 10:06:17 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 13 May 2024 10:06:17 GMT
Subject: RFR: 8314480: Memory ordering spec updates in java.lang.ref [v31]
In-Reply-To: <aUZHna4VBbB2ClvbJsoTwojkQfCE8-l2z9BDQaXHAIs=.8197a754-5559-4653-820f-ad9d92f72316@github.com>
References: <R74ontYwjYg6HeZY0cWrlo0amjl4E1YsFWeuh4pda14=.08ac62df-b2f8-4b4d-b338-07adb289601b@github.com>
 <aUZHna4VBbB2ClvbJsoTwojkQfCE8-l2z9BDQaXHAIs=.8197a754-5559-4653-820f-ad9d92f72316@github.com>
Message-ID: <ufZ1AXkEQIGA2clflsy6higNjS_OgikBtOrQwssBNHc=.5480f106-88b5-424d-aa1a-996fadbc7d91@github.com>

On Thu, 9 May 2024 18:44:10 GMT, Brent Christian <bchristi at openjdk.org> wrote:

>> Classes in the `java.lang.ref` package would benefit from an update to bring the spec in line with how the VM already behaves. The changes would focus on _happens-before_ edges at some key points during reference processing.
>> 
>> A couple key things we want to be able to say are:
>> - `Reference.reachabilityFence(x)` _happens-before_ reference processing occurs for 'x'.
>> - `Cleaner.register()` _happens-before_ the Cleaner thread runs the registered cleaning action.
>> 
>> This will bring Cleaner in line (or close) with the memory visibility guarantees made for finalizers in [JLS 17.4.5](https://docs.oracle.com/javase/specs/jls/se18/html/jls-17.html#jls-17.4.5):
>> _"There is a happens-before edge from the end of a constructor of an object to the start of a finalizer (?12.6) for that object."_
>
> Brent Christian has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add link to Thread.isAlive()

You've addressed my comments, I don't have anything else.

-------------

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/16644#pullrequestreview-2052249974

From liach at openjdk.org  Mon May 13 10:14:07 2024
From: liach at openjdk.org (Chen Liang)
Date: Mon, 13 May 2024 10:14:07 GMT
Subject: RFR: 8331855: Convert jdk.jdeps jdeprscan and jdeps to use the
 Classfile API [v2]
In-Reply-To: <-_-sdtKTXy0Heh10jg3IqVT64tVT_2OEvL-l2TmO024=.7a8efbc8-dedb-45c4-b944-cef9ec9dadfb@github.com>
References: <q2IKpwi6HEvLcKtNgKEzkD456bopyXRTliaRIU67C-4=.b77f917c-cb50-4d87-b187-65934954d622@github.com>
 <-_-sdtKTXy0Heh10jg3IqVT64tVT_2OEvL-l2TmO024=.7a8efbc8-dedb-45c4-b944-cef9ec9dadfb@github.com>
Message-ID: <ycoyPJD3BJTU81CTR7TOak8q2ditKl-8Y6jrvET8V14=.7c025dce-5018-49d5-a99a-c8c8d726b81b@github.com>

On Sun, 12 May 2024 02:42:32 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Summary of the changes:
>>  - Moved `com.sun.tools.classfile.Dependency` and `Dependencies` to jdeps; they are exclusively used by jdeps in sources, and they are not used in any tests too. This will ease the removal of `com.sun.tools.classfile` later.
>>  - A few visitor patterns have been rewritten with pattern matching, notably in:
>>    - `CPEntries`/`CPSelector` (removed)
>>    - `Dependencies.BasicDependencyFinder.Visitor` has been rewritten to use pattern matching to capture dependencies.
>>  - `MethodSig` and its tests have been removed in favor of `MethodTypeDesc`.
>>  - Otherwise, the changes are mostly mechanical replacements.
>> 
>> All tests in `test/langtools/tools/jdeprscan` and `test/langtools/tools/jdeps` pass.
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Migrate omitted getdeps test in langtools

@asotona Requesting your review for this and the other test migration patch.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19193#issuecomment-2107175526

From pminborg at openjdk.org  Mon May 13 10:34:05 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 13 May 2024 10:34:05 GMT
Subject: RFR: 8331670: Deprecate the Memory-Access Methods in
 sun.misc.Unsafe for Removal
In-Reply-To: <9FyO4QpCtH2CNkUEE78_Jjd9xs3bv3WJo16jyowHOvY=.e7131b91-37bb-4624-a60e-72a427a24c92@github.com>
References: <9FyO4QpCtH2CNkUEE78_Jjd9xs3bv3WJo16jyowHOvY=.e7131b91-37bb-4624-a60e-72a427a24c92@github.com>
Message-ID: <KcCmKdhCRkijJw7TjqO7t6gPm6ILS2CKUwNX4SwRJNc=.595b0253-cc23-4f48-b5d5-0d5ba435c787@github.com>

On Fri, 10 May 2024 10:06:55 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> This is the implementation changes for JEP 471.
> 
> The methods in sun.misc.Unsafe for on-heap and off-heap access are deprecated for removal. This means a removal warning at compile time. No methods have been removed. A deprecated message is added to each of the methods but unlikely to be seen as the JDK does not generate or publish the API docs for this class.
> 
> A new command line option --sun-misc-unsafe-memory-access=$value is introduced to allow or deny access to these methods. The default proposed for JDK 23 is "allow" so no change in behavior compared to JDK 22 or previous releases.
> 
> A new test is added to test the command line option settings. The existing micros for FFM that use Unsafe are updated to suppress the removal warning at compile time. A new micro is introduced with a small sample of methods to ensure the changes doesn't cause any perf regressions.
> 
> For now, the changes include the update to the man page for the "java" command. It might be that this has to be separated out so that it goes with other updates in the release.

Some of the deprecated methods are very likely to be run in hot loops (e.g. read/store operations). Unless we set `--sun-misc-unsafe-memory-access=allow`, what would be the performance impact on various platforms for these operations?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19174#issuecomment-2107216975

From jpai at openjdk.org  Mon May 13 10:52:18 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 13 May 2024 10:52:18 GMT
Subject: RFR: 8305457: Implement java.io.IO [v9]
In-Reply-To: <PIg24sny09iDwNT6W--TkoqtY8V2tXWCjrUL4MO-CRg=.67519d97-15b9-4b72-9bdc-ecbcc3dbfd5c@github.com>
References: <w2msiw_qaMEIJS3s9D4bg8pFbz5WIF0KdP6Mm-XFjLI=.85b2020b-8c46-4bac-8a69-4975b068f2ff@github.com>
 <PIg24sny09iDwNT6W--TkoqtY8V2tXWCjrUL4MO-CRg=.67519d97-15b9-4b72-9bdc-ecbcc3dbfd5c@github.com>
Message-ID: <FToruFbQiqKRPKZRsaSau6GAb7tH7_5sCUm7xa-_l5s=.eb4bdb9c-e3eb-4709-bf13-66f1bc6c4801@github.com>

On Mon, 13 May 2024 09:56:35 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Please review this PR which introduces the `java.io.IO` top-level class and three methods to `java.io.Console` for [Implicitly Declared Classes and Instance Main Methods (Third Preview)].
>> 
>> This PR has been obtained as `git merge --squash` of a now obsolete [draft PR].
>> 
>> [Implicitly Declared Classes and Instance Main Methods (Third Preview)]: https://bugs.openjdk.org/browse/JDK-8323335
>> [draft PR]: https://github.com/openjdk/jdk/pull/18921
>
> Pavel Rappo has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 17 additional commits since the last revision:
> 
>  - Escape prompt
>  - Merge branch 'master' into 8305457-Implement-java.io.IO
>  - Clarify input charset
>  - Make IO final
>  - Fix System.console().readln(null) in jshell
>    
>    Without it, jshell hangs on me. Will think of a test.
>  - Fix typo
>  - Merge branch 'master' into 8305457-Implement-java.io.IO
>  - Simplify output.exp
>  - Cover null prompt in input tests
>  - Make input test parametric
>  - ... and 7 more: https://git.openjdk.org/jdk/compare/ea3ed865...17100ab8

The latest updated state of this PR looks good to me.

-------------

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19112#pullrequestreview-2052345767

From jpai at openjdk.org  Mon May 13 10:52:18 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 13 May 2024 10:52:18 GMT
Subject: RFR: 8305457: Implement java.io.IO [v7]
In-Reply-To: <t25BDNnhk-6FuZwRF_6j3xNfkNGdNMeAcZdhGbaTW_k=.630978f0-9f05-462d-a97c-dbb57d26c936@github.com>
References: <w2msiw_qaMEIJS3s9D4bg8pFbz5WIF0KdP6Mm-XFjLI=.85b2020b-8c46-4bac-8a69-4975b068f2ff@github.com>
 <554HmRIAD_1Hf8Hbq6_YRH9iTf8fBk_OZ1XrlmSsQAU=.90c8b148-029a-429f-9037-179d9d30f6ad@github.com>
 <qDUNtEpZzW7nx2tzrSvzxei_AbLxXwyKFGEMZk5OpxI=.1fcd778a-1d52-40e0-944b-8d1a26bd7c8e@github.com>
 <6ztBTdtAQJwnROJ5Q_B2Qrx8GflN4shNjcXTfpg0w_Y=.fbba516c-bc36-4b2b-8ae7-7ee3d4219674@github.com>
 <t25BDNnhk-6FuZwRF_6j3xNfkNGdNMeAcZdhGbaTW_k=.630978f0-9f05-462d-a97c-dbb57d26c936@github.com>
Message-ID: <O9wqX8jU_OAAWbqskb3IQogIsZ0D-LC-FuMeniRm7Go=.186b07b3-3da7-4474-b17c-0237111e076c@github.com>

On Fri, 10 May 2024 16:41:28 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> When implementing, I asked myself if I must use any of those monitors and decided that I don't have to. My reasoning is below.
>> 
>> `readLock`:
>> 
>> - is used inside the object that `Reader reader` is initialised with, and
>> 
>> - it also guards fields such as `char[] rcb`, `boolean restoreEcho` and `boolean shutdownHookInstalled`.
>> 
>> Since `println` and `print` don't call methods on `reader` or access the above fields, they don't require `readLock`.
>> 
>> `writeLock`:
>> 
>> - is used inside objects that `Writer out` and `PrintWriter pw` are initialised with, and
>> - also in compound operations that first write and then immediately read. (I assume, it's so that no concurrent write could sneak in between writing and reading parts of such a compound.)
>> 
>> `println` or `print` don't call methods on `out` and certainly don't do any write-read compounds. That said, they call methods on `pw`. But `pw` uses `writeLock` internally. So in that sense we're covered. 
>> 
>> One potential concern is a write-write compound in `print`:
>> 
>> 
>>     @Override
>>     public JdkConsole print(Object obj) {
>>         pw.print(obj);
>>         pw.flush(); // automatic flushing does not cover print
>>         return this;
>>     }
>> 
>> 
>> I'm saying write-_write_, not write-_flush_, because as far as synchronisation is concerned,  `pw.flush()` should behave the same as `pw.print("")`.
>> 
>> While not using `writeLock` is not strictly correct, I believe the potential execution interleavings with other writes are benign. What's the worst that could happen? You flush more than you expected? Big deal!
>> 
>> Since we exhausted all the reasons to use `writeLock`, I don't think we need one.
>> 
>> 
>> 
>> Naoto has already reviewed this PR with only minor comments. While that increases my confidence in that the implementation is correct, it doesn't hurt to request re-review of this specific part: @naotoj, do you think I should use any of those monitors?
>
> I think your investigation is correct. As to the write-write case, there already is the same pattern in (`formatter` basically utilizes `pw` underneath) 
> 
>     public JdkConsole format(String fmt, Object ... args) {
>         formatter.format(fmt, args).flush();
>         return this;
>     }
> 
> So I think it is acceptable.

Thank you for that explanation, Pavel. I think the crucial detail happens to be:

> But pw uses writeLock internally. So in that sense we're covered.

As you note, the same instance of `writeLock` will get used internally by the `PrintWriter`, so I think the current version of this code is good and won't require additionally locking in the outer code.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19112#discussion_r1598268588

From prappo at openjdk.org  Mon May 13 10:54:04 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Mon, 13 May 2024 10:54:04 GMT
Subject: RFR: 8332084: Ensure JdkConsoleImpl.restoreEcho visibility in a
 shutdown hook
In-Reply-To: <9JTWc3FRpfbILlSHlmIU_dL5IE69RTxnSIAOdIte15I=.5854a48f-21d7-42c9-adb7-5e3ed40d1211@github.com>
References: <9JTWc3FRpfbILlSHlmIU_dL5IE69RTxnSIAOdIte15I=.5854a48f-21d7-42c9-adb7-5e3ed40d1211@github.com>
Message-ID: <WnShr34HGo6pMbUkOevoMzPe6Pg2ip_CIDyzTIDTDlQ=.f88f5cf2-917a-4ea8-b90c-859bf2528d74@github.com>

On Fri, 10 May 2024 21:55:26 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Making sure `restoreEcho` correctly reflects the state in the shutdown thread, which differs from the application's thread that issues the `readPassword()` method.

Generally looks good.

It's hard to imagine that this shutdown hook might be reading `restoreEcho` concurrently with some other thread writing to it. So, our primary goal here is to ensure that whatever writes have been done to `restoreEcho` before the hook starts are seen by the hook.

While it's hard to test this change (hence the `noreg-hard` label), the `restoreEcho` functionality does not seem to be tested at all. Should we add a straightforward test for it, perhaps separately?

-------------

PR Review: https://git.openjdk.org/jdk/pull/19184#pullrequestreview-2052349894

From alanb at openjdk.org  Mon May 13 11:06:04 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 13 May 2024 11:06:04 GMT
Subject: RFR: 8331670: Deprecate the Memory-Access Methods in
 sun.misc.Unsafe for Removal
In-Reply-To: <KcCmKdhCRkijJw7TjqO7t6gPm6ILS2CKUwNX4SwRJNc=.595b0253-cc23-4f48-b5d5-0d5ba435c787@github.com>
References: <9FyO4QpCtH2CNkUEE78_Jjd9xs3bv3WJo16jyowHOvY=.e7131b91-37bb-4624-a60e-72a427a24c92@github.com>
 <KcCmKdhCRkijJw7TjqO7t6gPm6ILS2CKUwNX4SwRJNc=.595b0253-cc23-4f48-b5d5-0d5ba435c787@github.com>
Message-ID: <z70YDuszzAaA7zUMdWNICozDCe_Yavef9lPHdOvr4xo=.48d69b6f-aafc-4e87-a9ab-a704c69d75b7@github.com>

On Mon, 13 May 2024 10:30:43 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> Some of the deprecated methods are very likely to be run in hot loops (e.g. read/store operations). Unless we set `--sun-misc-unsafe-memory-access=allow`, what would be the performance impact on various platforms for these operations?

The intention is that there isn't any impact for the initial default ("allow"), and in the future "warn" after the first waning. If the "debug" value is used then there is a stack trace printed but that's not something for production use.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19174#issuecomment-2107279163

From mcimadamore at openjdk.org  Mon May 13 11:08:51 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 13 May 2024 11:08:51 GMT
Subject: RFR: 8331671: Implement JEP 472: Prepare to Restrict the Use of JNI
Message-ID: <CZGbki5iFdCGPPagE-ya-_L8Nkgf7OunywApOsxC548=.2cee82fa-a5d2-4165-b012-30982a85030a@github.com>

This PR implements [JEP 472](https://openjdk.org/jeps/472), by restricting the use of JNI in the following ways:

* `System::load` and `System::loadLibrary` are now restricted methods
* `Runtime::load` and `Runtime::loadLibrary` are now restricted methods
* binding a JNI `native` method declaration to a native implementation is now considered a restricted operation

This PR slightly changes the way in which the JDK deals with restricted methods, even for FFM API calls. In Java 22, the single `--enable-native-access` was used both to specify a set of modules for which native access should be allowed *and* to specify whether illegal native access (that is, native access occurring from a module not specified by `--enable-native-access`) should be treated as an error or a warning. More specifically, an error is only issued if the `--enable-native-access flag` is used at least once.

Here, a new flag is introduced, namely `illegal-native-access=allow/warn/deny`, which is used to specify what should happen when access to a restricted method and/or functionality is found outside the set of modules specified with `--enable-native-access`. The default policy is `warn`, but users can select `allow` to suppress the warnings, or `deny` to cause `IllegalCallerException` to be thrown. This aligns the treatment of restricted methods with other mechanisms, such as `--illegal-access` and the more recent `--sun-misc-unsafe-memory-access`.

Some changes were required in the package-info javadoc for `java.lang.foreign`, to reflect the changes in the command line flags described above.

-------------

Commit messages:
 - Initial push

Changes: https://git.openjdk.org/jdk/pull/19213/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19213&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8331671
  Stats: 466 lines in 99 files changed: 301 ins; 53 del; 112 mod
  Patch: https://git.openjdk.org/jdk/pull/19213.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19213/head:pull/19213

PR: https://git.openjdk.org/jdk/pull/19213

From mcimadamore at openjdk.org  Mon May 13 11:08:51 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 13 May 2024 11:08:51 GMT
Subject: RFR: 8331671: Implement JEP 472: Prepare to Restrict the Use of
 JNI
In-Reply-To: <CZGbki5iFdCGPPagE-ya-_L8Nkgf7OunywApOsxC548=.2cee82fa-a5d2-4165-b012-30982a85030a@github.com>
References: <CZGbki5iFdCGPPagE-ya-_L8Nkgf7OunywApOsxC548=.2cee82fa-a5d2-4165-b012-30982a85030a@github.com>
Message-ID: <vtwexqsEt4uFH-ObgWjYt9JgicYmXDGw0YaaOFcvkVM=.2a854073-e034-4c7e-b5f9-8ffa5f97d320@github.com>

On Mon, 13 May 2024 10:42:26 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> This PR implements [JEP 472](https://openjdk.org/jeps/472), by restricting the use of JNI in the following ways:
> 
> * `System::load` and `System::loadLibrary` are now restricted methods
> * `Runtime::load` and `Runtime::loadLibrary` are now restricted methods
> * binding a JNI `native` method declaration to a native implementation is now considered a restricted operation
> 
> This PR slightly changes the way in which the JDK deals with restricted methods, even for FFM API calls. In Java 22, the single `--enable-native-access` was used both to specify a set of modules for which native access should be allowed *and* to specify whether illegal native access (that is, native access occurring from a module not specified by `--enable-native-access`) should be treated as an error or a warning. More specifically, an error is only issued if the `--enable-native-access flag` is used at least once.
> 
> Here, a new flag is introduced, namely `illegal-native-access=allow/warn/deny`, which is used to specify what should happen when access to a restricted method and/or functionality is found outside the set of modules specified with `--enable-native-access`. The default policy is `warn`, but users can select `allow` to suppress the warnings, or `deny` to cause `IllegalCallerException` to be thrown. This aligns the treatment of restricted methods with other mechanisms, such as `--illegal-access` and the more recent `--sun-misc-unsafe-memory-access`.
> 
> Some changes were required in the package-info javadoc for `java.lang.foreign`, to reflect the changes in the command line flags described above.

Javadoc: https://cr.openjdk.org/~mcimadamore/jdk/8331671/v1/javadoc/api/index.html
Specdiff: https://cr.openjdk.org/~mcimadamore/jdk/8331671/v1/specdiff_out/overview-summary.html

make/conf/module-loader-map.conf line 105:

> 103:     java.smartcardio \
> 104:     jdk.accessibility \
> 105:     jdk.attach \

The list of allowed modules has been rewritten from scratch, by looking at the set of modules containing at least one `native` method declaration.

src/hotspot/share/prims/nativeLookup.cpp line 277:

> 275: 
> 276:   Klass*   klass = vmClasses::ClassLoader_klass();
> 277:   Handle jni_class(THREAD, method->method_holder()->java_mirror());

This is the biggest change in this PR. That is, we need to pass enough arguments to `ClassLoader::findNative` so that the method can start a restricted check accordingly.

src/java.base/share/classes/java/lang/Module.java line 311:

> 309:         Module target = moduleForNativeAccess();
> 310:         ModuleBootstrap.IllegalNativeAccess illegalNativeAccess = ModuleBootstrap.illegalNativeAccess();
> 311:         if (illegalNativeAccess != ModuleBootstrap.IllegalNativeAccess.ALLOW &&

There are some changes in this code:
* this code is no-op if `--illegal-native-access` is set to `allow`
* we also attach the location of the problematic class to the warning message, using `CodeSource`
* we use the "initial error stream" to emit the warning, similarly to what is done for other runtime warnings

src/java.base/share/classes/jdk/internal/reflect/Reflection.java line 115:

> 113:     @ForceInline
> 114:     public static void ensureNativeAccess(Class<?> currentClass, Class<?> owner, String methodName) {
> 115:         if (VM.isModuleSystemInited()) {

If we call this code too early, we can see cases where `module` is `null`.

src/java.desktop/macosx/classes/com/apple/eio/FileManager.java line 61:

> 59:     }
> 60: 
> 61:     @SuppressWarnings({"removal", "restricted"})

There are several of these changes. One option might have been to just disable restricted warnings when building. But on a deeper look, I realized that in all these places we already disabled deprecation warnings for the use of security manager, so I also added a new suppression instead.

test/jdk/java/foreign/enablenativeaccess/panama_jni_load_module/module-info.java line 24:

> 22:  */
> 23: 
> 24: module panama_jni_load_module {

This module setup is a bit convoluted, but I wanted to make sure that we got separate warnings for `System.loadLibrary` and binding of the `native` method, and that warning on the _use_ of the native method was not generated (typically, all three operations occur in the same module).

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19213#issuecomment-2107272261
PR Review Comment: https://git.openjdk.org/jdk/pull/19213#discussion_r1598269825
PR Review Comment: https://git.openjdk.org/jdk/pull/19213#discussion_r1598271285
PR Review Comment: https://git.openjdk.org/jdk/pull/19213#discussion_r1598274987
PR Review Comment: https://git.openjdk.org/jdk/pull/19213#discussion_r1598276455
PR Review Comment: https://git.openjdk.org/jdk/pull/19213#discussion_r1598277853
PR Review Comment: https://git.openjdk.org/jdk/pull/19213#discussion_r1598279827

From dl at openjdk.org  Mon May 13 11:20:14 2024
From: dl at openjdk.org (Doug Lea)
Date: Mon, 13 May 2024 11:20:14 GMT
Subject: RFR: 8322732: ForkJoinPool may underutilize cores in async mode
 [v2]
In-Reply-To: <3TCc62ocrg1M4I6RlxofEJcyrEG-GQ5hijQnvh2iS-0=.307e277d-6960-40f4-8349-12f3ae016f2a@github.com>
References: <xRyDMAsSZ7obqpr3Aoc5qrHqILeJMxFVCeiRdctMI3U=.d5d3cd56-32eb-4431-ac01-081822fc86c6@github.com>
 <1h7ssJJnGUbpqORLsdM_Udcl2dqYsrjuXP6ZPTH_bVo=.ce5a42ba-4eae-4430-9f7d-b6036a45ef9b@github.com>
 <3TCc62ocrg1M4I6RlxofEJcyrEG-GQ5hijQnvh2iS-0=.307e277d-6960-40f4-8349-12f3ae016f2a@github.com>
Message-ID: <N23tRtMzZKyC60i2whlZXSueRYJrsa4dGAvKRdPx1Qw=.9e8115d5-f8c1-4327-aeef-c9cf27ca60ed@github.com>

On Sun, 12 May 2024 19:46:42 GMT, Viktor Klang <vklang at openjdk.org> wrote:

>> Doug Lea has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Address review comments
>
> src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 1242:
> 
>> 1240:                                         INITIAL_QUEUE_CAPACITY];
>> 1241:             this.owner = owner;
>> 1242:             //            top = base = 1;
> 
> Leftover?

Yes, sorry for mis-committing incomplete-undo that needs another compensating change to avoid small performance glitch. Will fix.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19131#discussion_r1598301076

From mcimadamore at openjdk.org  Mon May 13 11:42:04 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 13 May 2024 11:42:04 GMT
Subject: RFR: 8331671: Implement JEP 472: Prepare to Restrict the Use of
 JNI [v2]
In-Reply-To: <CZGbki5iFdCGPPagE-ya-_L8Nkgf7OunywApOsxC548=.2cee82fa-a5d2-4165-b012-30982a85030a@github.com>
References: <CZGbki5iFdCGPPagE-ya-_L8Nkgf7OunywApOsxC548=.2cee82fa-a5d2-4165-b012-30982a85030a@github.com>
Message-ID: <jYXEbzucmgIWtQsi3ayKu-MXRf1VRQlr3VENyrjtDVY=.5b569826-d582-4c94-96da-930927e7d4b3@github.com>

> This PR implements [JEP 472](https://openjdk.org/jeps/472), by restricting the use of JNI in the following ways:
> 
> * `System::load` and `System::loadLibrary` are now restricted methods
> * `Runtime::load` and `Runtime::loadLibrary` are now restricted methods
> * binding a JNI `native` method declaration to a native implementation is now considered a restricted operation
> 
> This PR slightly changes the way in which the JDK deals with restricted methods, even for FFM API calls. In Java 22, the single `--enable-native-access` was used both to specify a set of modules for which native access should be allowed *and* to specify whether illegal native access (that is, native access occurring from a module not specified by `--enable-native-access`) should be treated as an error or a warning. More specifically, an error is only issued if the `--enable-native-access flag` is used at least once.
> 
> Here, a new flag is introduced, namely `illegal-native-access=allow/warn/deny`, which is used to specify what should happen when access to a restricted method and/or functionality is found outside the set of modules specified with `--enable-native-access`. The default policy is `warn`, but users can select `allow` to suppress the warnings, or `deny` to cause `IllegalCallerException` to be thrown. This aligns the treatment of restricted methods with other mechanisms, such as `--illegal-access` and the more recent `--sun-misc-unsafe-memory-access`.
> 
> Some changes were required in the package-info javadoc for `java.lang.foreign`, to reflect the changes in the command line flags described above.

Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:

  Avoid call to VM::isModuleSystemInited
  Use initial error stream

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19213/files
  - new: https://git.openjdk.org/jdk/pull/19213/files/d9fe9a71..c4938dc7

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19213&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19213&range=00-01

  Stats: 11 lines in 2 files changed: 3 ins; 0 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/19213.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19213/head:pull/19213

PR: https://git.openjdk.org/jdk/pull/19213

From mcimadamore at openjdk.org  Mon May 13 11:42:04 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 13 May 2024 11:42:04 GMT
Subject: RFR: 8331671: Implement JEP 472: Prepare to Restrict the Use of
 JNI [v2]
In-Reply-To: <jYXEbzucmgIWtQsi3ayKu-MXRf1VRQlr3VENyrjtDVY=.5b569826-d582-4c94-96da-930927e7d4b3@github.com>
References: <CZGbki5iFdCGPPagE-ya-_L8Nkgf7OunywApOsxC548=.2cee82fa-a5d2-4165-b012-30982a85030a@github.com>
 <jYXEbzucmgIWtQsi3ayKu-MXRf1VRQlr3VENyrjtDVY=.5b569826-d582-4c94-96da-930927e7d4b3@github.com>
Message-ID: <I64gRu7YBocAbIcJtlBlzXf9kdrDhS8Qu93w-dKXlOY=.ce21de82-c7e0-4a51-b36a-ae8fc88a8ec1@github.com>

On Mon, 13 May 2024 11:38:40 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This PR implements [JEP 472](https://openjdk.org/jeps/472), by restricting the use of JNI in the following ways:
>> 
>> * `System::load` and `System::loadLibrary` are now restricted methods
>> * `Runtime::load` and `Runtime::loadLibrary` are now restricted methods
>> * binding a JNI `native` method declaration to a native implementation is now considered a restricted operation
>> 
>> This PR slightly changes the way in which the JDK deals with restricted methods, even for FFM API calls. In Java 22, the single `--enable-native-access` was used both to specify a set of modules for which native access should be allowed *and* to specify whether illegal native access (that is, native access occurring from a module not specified by `--enable-native-access`) should be treated as an error or a warning. More specifically, an error is only issued if the `--enable-native-access flag` is used at least once.
>> 
>> Here, a new flag is introduced, namely `illegal-native-access=allow/warn/deny`, which is used to specify what should happen when access to a restricted method and/or functionality is found outside the set of modules specified with `--enable-native-access`. The default policy is `warn`, but users can select `allow` to suppress the warnings, or `deny` to cause `IllegalCallerException` to be thrown. This aligns the treatment of restricted methods with other mechanisms, such as `--illegal-access` and the more recent `--sun-misc-unsafe-memory-access`.
>> 
>> Some changes were required in the package-info javadoc for `java.lang.foreign`, to reflect the changes in the command line flags described above.
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Avoid call to VM::isModuleSystemInited
>   Use initial error stream

src/java.base/share/classes/jdk/internal/reflect/Reflection.java line 124:

> 122:         if (module != null) {
> 123:             // not in init phase
> 124:             Holder.JLA.ensureNativeAccess(module, owner, methodName, currentClass);

In an earlier iteration I had a call to `VM::isModuleSystemInited`, but I discovered that caused a performance regression, since that method involves a volatile access. Perhaps we should rethink that part of the init code to use stable fields, but it's probably better done separately.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19213#discussion_r1598328283

From mcimadamore at openjdk.org  Mon May 13 11:47:38 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 13 May 2024 11:47:38 GMT
Subject: RFR: 8331671: Implement JEP 472: Prepare to Restrict the Use of
 JNI [v3]
In-Reply-To: <CZGbki5iFdCGPPagE-ya-_L8Nkgf7OunywApOsxC548=.2cee82fa-a5d2-4165-b012-30982a85030a@github.com>
References: <CZGbki5iFdCGPPagE-ya-_L8Nkgf7OunywApOsxC548=.2cee82fa-a5d2-4165-b012-30982a85030a@github.com>
Message-ID: <jUWaDowOZsL42UtliIOoCe7WfowooCW1zvcVKyFnL7g=.4b20b555-3651-4fca-9ede-1652dec95e9c@github.com>

> This PR implements [JEP 472](https://openjdk.org/jeps/472), by restricting the use of JNI in the following ways:
> 
> * `System::load` and `System::loadLibrary` are now restricted methods
> * `Runtime::load` and `Runtime::loadLibrary` are now restricted methods
> * binding a JNI `native` method declaration to a native implementation is now considered a restricted operation
> 
> This PR slightly changes the way in which the JDK deals with restricted methods, even for FFM API calls. In Java 22, the single `--enable-native-access` was used both to specify a set of modules for which native access should be allowed *and* to specify whether illegal native access (that is, native access occurring from a module not specified by `--enable-native-access`) should be treated as an error or a warning. More specifically, an error is only issued if the `--enable-native-access flag` is used at least once.
> 
> Here, a new flag is introduced, namely `illegal-native-access=allow/warn/deny`, which is used to specify what should happen when access to a restricted method and/or functionality is found outside the set of modules specified with `--enable-native-access`. The default policy is `warn`, but users can select `allow` to suppress the warnings, or `deny` to cause `IllegalCallerException` to be thrown. This aligns the treatment of restricted methods with other mechanisms, such as `--illegal-access` and the more recent `--sun-misc-unsafe-memory-access`.
> 
> Some changes were required in the package-info javadoc for `java.lang.foreign`, to reflect the changes in the command line flags described above.

Maurizio Cimadamore has updated the pull request incrementally with three additional commits since the last revision:

 - Fix another typo
 - Fix typo
 - Add more comments

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19213/files
  - new: https://git.openjdk.org/jdk/pull/19213/files/c4938dc7..bad10942

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19213&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19213&range=01-02

  Stats: 5 lines in 1 file changed: 4 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/19213.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19213/head:pull/19213

PR: https://git.openjdk.org/jdk/pull/19213

From mcimadamore at openjdk.org  Mon May 13 12:07:38 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 13 May 2024 12:07:38 GMT
Subject: RFR: 8332003: Clarify javadoc for MemoryLayout::offsetHandle [v6]
In-Reply-To: <0uMhIaW3d_IBqbF_04WhHDKHiIXes04wawSuxc6dQxI=.7f5621f9-0d77-4433-bc00-1ff8624b65da@github.com>
References: <0uMhIaW3d_IBqbF_04WhHDKHiIXes04wawSuxc6dQxI=.7f5621f9-0d77-4433-bc00-1ff8624b65da@github.com>
Message-ID: <ktpcIDj1WEocC0UMjmU1Ta4zYfp3xgJkEBoJtgyH1_8=.850d9324-3296-4ef6-ac9e-c5e7700b5da3@github.com>

> Consider this layout:
> 
> 
> MemoryLayout SEQ = MemoryLayout.sequenceLayout(5,
>              MemoryLayout.sequenceLayout(10, JAVA_INT));
> 
> 
> And the corresponding offset handle:
> 
> 
> MethodHandle offsetHandle = SEQ.offsetHandle(PathElement.sequenceLayout(), PathElement.sequenceLayout());
> 
> 
> The resulting method handle takes two additional `long` indices. The implementation checks that the dynamically provided indices conform to the bound available at construction: that is, the first index must be < 5, while the second must be < 10. If this is not true, an `IndexOutOfBoundException` is thrown.
> 
> However, the javadoc for `MemoryLayout::byteOffsetHandle` doesn't claim anything in this direction. There are only some vague claims in the javadoc for `PathElement::sequenceElement()` and `PathElement::sequenceElement(long, long, long)` which make some claims on which indices are actually allowed, but the text seems more in the tone of a discussion, rather than actual normative text.
> 
> I've tweaked the javadoc for `MemoryLayout::byteOffsetHandle` to actually state that the indices will be checked against the "size" of the corresponding open path element (this is a new concept that I also have defined in the javadoc).
> 
> I also added a test for `byteOffsetHandle` as I don't think we had a test for that specifically (although this method is tested indirectly, via `MemoryLayout::varHandle`).

Maurizio Cimadamore 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 seven additional commits since the last revision:

 - Merge branch 'master' into layout_docs_fixes
 - Fix another index check
 - Replace > 0 with >= 0
 - Address review comments
 - Update copyright
 - Add javadoc to other MemoryLayout methods returning VarHandle/MethodHandle to describe which exception can be thrown by returned handle
 - Initial push

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19158/files
  - new: https://git.openjdk.org/jdk/pull/19158/files/629000d1..38a9924f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19158&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19158&range=04-05

  Stats: 19721 lines in 372 files changed: 10283 ins; 6458 del; 2980 mod
  Patch: https://git.openjdk.org/jdk/pull/19158.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19158/head:pull/19158

PR: https://git.openjdk.org/jdk/pull/19158

From liach at openjdk.org  Mon May 13 12:15:10 2024
From: liach at openjdk.org (Chen Liang)
Date: Mon, 13 May 2024 12:15:10 GMT
Subject: RFR: 8331291: java.lang.classfile.Attributes class performs a lot
 of static initializations [v8]
In-Reply-To: <8bkIrXCl7OsuLoMQi43faVELq0d1R-P60pSCGkxpwpU=.fe207403-8288-4f2d-ab7d-96fec5ba212e@github.com>
References: <SHIvjbwCWBPERKxlytEsY_O_kEiJbSeEmSusuDwjTIw=.ae8dd21e-a822-476e-9760-dd489532dbf1@github.com>
 <UielWbqtQPeaoAfpuHYPMzn8N6ViEH0T0h6WXHscUrk=.e4d333d7-6ae3-447f-9b5f-d0a77d29c416@github.com>
 <3eERzqYdCd4f9qn4KpzBA9ealaUTzC67wIhzB18ETTE=.f9d17a6f-1ca5-477f-8344-40c20abe7d7e@github.com>
 <8bkIrXCl7OsuLoMQi43faVELq0d1R-P60pSCGkxpwpU=.fe207403-8288-4f2d-ab7d-96fec5ba212e@github.com>
Message-ID: <KwVdqMvTDY1Zs3cYtNqExwhjiupCBucnfW4nWOC75o0=.6ef25afc-050f-41ef-80e1-a3da9d615052@github.com>

On Mon, 13 May 2024 07:51:19 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/classfile/Attributes.java line 153:
>> 
>>> 151: 
>>> 152:     /**
>>> 153:      * {@return Attribute mapper for the {@code AnnotationDefault} attribute}
>> 
>> Just wondering, can we change `{@code AnnotationDefault}` to `{@value #NAME_ANNOTATION_DEFAULT}`, etc? This way, the names are still rendered as code in Javadoc HTML, but they are generated with links to the constants, and programmers will see these constants and prefer them over hardcoded values.
>
> On the other side it is questionable if the attribute names should be exposed in the API. We provide corresponding mappers and attribute models. I don't see a case where user would need to use the attribute names directly.

Makes sense, we can always add these literals back if we do need them.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19006#discussion_r1598368707

From jpai at openjdk.org  Mon May 13 12:50:07 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 13 May 2024 12:50:07 GMT
Subject: RFR: 8332086: Remove the usage of ServiceLoader in
 j.u.r.RandomGeneratorFactory
In-Reply-To: <hfB86NksORc-aC6zVxHel_QQd_9aB629SfQjXvl6q5U=.e31daa4b-5cf6-4f3f-a757-79e818a18978@github.com>
References: <hfB86NksORc-aC6zVxHel_QQd_9aB629SfQjXvl6q5U=.e31daa4b-5cf6-4f3f-a757-79e818a18978@github.com>
Message-ID: <mH_LU2mwBmn13nuF039baoqq2ibSbmqct0WFxhVv1vg=.b904990f-e389-4c81-9d19-2b9d8ca35e99@github.com>

On Mon, 13 May 2024 08:47:50 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

> All random number generator algorithms are implemented in module `java.base`. The usage of `ServiceLoader` in `j.u.r.RandomGeneratorFactory` is no longer needed.

src/java.base/share/classes/java/util/random/RandomGeneratorFactory.java line 190:

> 188:                 if (properties == null) {  // double-checking idiom
> 189:                     RandomGeneratorProperties props = rgClass.getDeclaredAnnotation(RandomGeneratorProperties.class);
> 190:                     Objects.requireNonNull(props, rgClass + " missing annotation");

Hello Raffaello, with the `RandomGenerator` implementations now all residing within the java.base module, I think an additional advantage of that is that, it will now allow us to remove this internal `RandomGeneratorProperties` annotation and thus this reflection code.

I think one way to do that would be something like this within this `RandomGeneratorFactory` class itself: 


private record RandomGenEntry(Class<?> randomGenClass, int i, int j,
                              int k, int equiDistribution, boolean stochastic,
                              boolean hardware) {

}

private static final Map<String, RandomGenEntry> FACTORY_MAP = ... // construct the map


where the `FACTORY_MAP` will be keyed to the alogrithm and the value will be a record which holds these additional details about the `RandomGenerator`. 
This current PR is about getting rid of ServiceLoader usage. So if you want to remove the usage of this annotation and reflection is a separate PR that's fine with me. Furthermore, although I don't see the necessity of an annotation for what we are doing here, if you think that the removal of the annotation and reflection isn't worth doing, that is OK too.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19212#discussion_r1598417990

From prappo at openjdk.org  Mon May 13 12:59:08 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Mon, 13 May 2024 12:59:08 GMT
Subject: RFR: 8330205: Initial troff manpage generation for JDK 24
In-Reply-To: <6PQqK1kADFKALT6GNcnAiRvM1TykSgCTK5m84MRscIE=.538243ee-787b-45ae-8b0e-44cca343ebc9@github.com>
References: <6tFYXJ753At7nUZTy8khVVeiQHYtZRBRYegXSTXViUY=.f3110151-9ea0-4b55-89f1-90039273fd34@github.com>
 <6PQqK1kADFKALT6GNcnAiRvM1TykSgCTK5m84MRscIE=.538243ee-787b-45ae-8b0e-44cca343ebc9@github.com>
Message-ID: <Bs24lao4Q9KgrEy0OT7WG_Y_79LTVcLSXYZ7Xz27xi8=.6c24caf8-9ff3-43ab-ad9c-1694dd624caf@github.com>

On Thu, 9 May 2024 08:18:41 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Please review this mechanical change to man pages. This PR should be integrated after https://github.com/openjdk/jdk/pull/18787.
>
> src/java.base/share/man/java.1 line 3856:
> 
>> 3854: .SH REMOVED JAVA OPTIONS
>> 3855: .PP
>> 3856: These \f[V]java\f[R] options have been removed in JDK 24 and using them
> 
> This is incorrect. You can't just change 23 to 24 here as the actual set of flags listed below will be will be different.

David, my understanding is that you agree that this is okay (per our out-of-band, follow-up discussion).

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19119#discussion_r1598432769

From jpai at openjdk.org  Mon May 13 13:10:04 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 13 May 2024 13:10:04 GMT
Subject: RFR: 8332086: Remove the usage of ServiceLoader in
 j.u.r.RandomGeneratorFactory
In-Reply-To: <mH_LU2mwBmn13nuF039baoqq2ibSbmqct0WFxhVv1vg=.b904990f-e389-4c81-9d19-2b9d8ca35e99@github.com>
References: <hfB86NksORc-aC6zVxHel_QQd_9aB629SfQjXvl6q5U=.e31daa4b-5cf6-4f3f-a757-79e818a18978@github.com>
 <mH_LU2mwBmn13nuF039baoqq2ibSbmqct0WFxhVv1vg=.b904990f-e389-4c81-9d19-2b9d8ca35e99@github.com>
Message-ID: <Qi40QQbVUG444KUJxqWVjKaHj5-X53SiFmXPhI99Iho=.a0f56e95-41bf-4d54-9e76-951f1535b698@github.com>

On Mon, 13 May 2024 12:45:59 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> All random number generator algorithms are implemented in module `java.base`. The usage of `ServiceLoader` in `j.u.r.RandomGeneratorFactory` is no longer needed.
>
> src/java.base/share/classes/java/util/random/RandomGeneratorFactory.java line 190:
> 
>> 188:                 if (properties == null) {  // double-checking idiom
>> 189:                     RandomGeneratorProperties props = rgClass.getDeclaredAnnotation(RandomGeneratorProperties.class);
>> 190:                     Objects.requireNonNull(props, rgClass + " missing annotation");
> 
> Hello Raffaello, with the `RandomGenerator` implementations now all residing within the java.base module, I think an additional advantage of that is that, it will now allow us to remove this internal `RandomGeneratorProperties` annotation and thus this reflection code.
> 
> I think one way to do that would be something like this within this `RandomGeneratorFactory` class itself: 
> 
> 
> private record RandomGenEntry(Class<?> randomGenClass, int i, int j,
>                               int k, int equiDistribution, boolean stochastic,
>                               boolean hardware) {
> 
> }
> 
> private static final Map<String, RandomGenEntry> FACTORY_MAP = ... // construct the map
> 
> 
> where the `FACTORY_MAP` will be keyed to the alogrithm and the value will be a record which holds these additional details about the `RandomGenerator`. 
> This current PR is about getting rid of ServiceLoader usage. So if you want to remove the usage of this annotation and reflection is a separate PR that's fine with me. Furthermore, although I don't see the necessity of an annotation for what we are doing here, if you think that the removal of the annotation and reflection isn't worth doing, that is OK too.

Thinking a bit more, I think we can even get rid of the reflection used in `create()` methods implementation, if we wanted to, by doing something like this:


private record RandomGenEntry(Class<? extends RandomGenerator> randomGenClass, int i, int j,
                                  int k, int equiDistribution, boolean stochastic,
                                  boolean hardware) {

        RandomGenerator create() {
            String algo = randomGenClass.getSimpleName();
            return switch (algo) {
                case "Random" -> new Random();
                case "L128X1024MixRandom" -> new L128X1024MixRandom();
                case "Xoshiro256PlusPlus" -> new Xoshiro256PlusPlus();
                // ... so on for the rest
                default -> throw new InternalError("should not happen");
            };
        }

        RandomGenerator create(long seed) {
            String algo = randomGenClass.getSimpleName();
            return switch (algo) {
                case "Random", "SplittableRandom", "SecureRandom" -> {
                    throw new UnsupportedOperationException("cannot construct with a long seed");
                }
                case "L128X1024MixRandom" -> new L128X1024MixRandom(seed);
                case "Xoshiro256PlusPlus" -> new Xoshiro256PlusPlus(seed);
                // ... so on for the rest
                default -> throw new InternalError("should not happen");
            };
        }

        RandomGenerator create(byte[] seed) {
            String algo = randomGenClass.getSimpleName();
            return switch (algo) {
                case "Random", "SplittableRandom", "SecureRandom" -> {
                    throw new UnsupportedOperationException("cannot construct with a byte[] seed");
                }
                case "L128X1024MixRandom" -> new L128X1024MixRandom(seed);
                case "Xoshiro256PlusPlus" -> new Xoshiro256PlusPlus(seed);
                // ... so on for the rest
                default -> throw new InternalError("should not happen");
            };
        }
    }

    
    private static final Map<String, RandomGenEntry> FACTORY_MAP = ... // construct the map

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19212#discussion_r1598446741

From rgiulietti at openjdk.org  Mon May 13 13:18:06 2024
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Mon, 13 May 2024 13:18:06 GMT
Subject: RFR: 8332086: Remove the usage of ServiceLoader in
 j.u.r.RandomGeneratorFactory
In-Reply-To: <Qi40QQbVUG444KUJxqWVjKaHj5-X53SiFmXPhI99Iho=.a0f56e95-41bf-4d54-9e76-951f1535b698@github.com>
References: <hfB86NksORc-aC6zVxHel_QQd_9aB629SfQjXvl6q5U=.e31daa4b-5cf6-4f3f-a757-79e818a18978@github.com>
 <mH_LU2mwBmn13nuF039baoqq2ibSbmqct0WFxhVv1vg=.b904990f-e389-4c81-9d19-2b9d8ca35e99@github.com>
 <Qi40QQbVUG444KUJxqWVjKaHj5-X53SiFmXPhI99Iho=.a0f56e95-41bf-4d54-9e76-951f1535b698@github.com>
Message-ID: <DfnK-PUg49spHSshZ_W_LHPX4tDnW3xHpm_LHT-WPcc=.c591d07c-481a-4f58-b9f8-aeff4399b25b@github.com>

On Mon, 13 May 2024 13:06:04 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> src/java.base/share/classes/java/util/random/RandomGeneratorFactory.java line 190:
>> 
>>> 188:                 if (properties == null) {  // double-checking idiom
>>> 189:                     RandomGeneratorProperties props = rgClass.getDeclaredAnnotation(RandomGeneratorProperties.class);
>>> 190:                     Objects.requireNonNull(props, rgClass + " missing annotation");
>> 
>> Hello Raffaello, with the `RandomGenerator` implementations now all residing within the java.base module, I think an additional advantage of that is that, it will now allow us to remove this internal `RandomGeneratorProperties` annotation and thus this reflection code.
>> 
>> I think one way to do that would be something like this within this `RandomGeneratorFactory` class itself: 
>> 
>> 
>> private record RandomGenEntry(Class<?> randomGenClass, int i, int j,
>>                               int k, int equiDistribution, boolean stochastic,
>>                               boolean hardware) {
>> 
>> }
>> 
>> private static final Map<String, RandomGenEntry> FACTORY_MAP = ... // construct the map
>> 
>> 
>> where the `FACTORY_MAP` will be keyed to the alogrithm and the value will be a record which holds these additional details about the `RandomGenerator`. 
>> This current PR is about getting rid of ServiceLoader usage. So if you want to remove the usage of this annotation and reflection is a separate PR that's fine with me. Furthermore, although I don't see the necessity of an annotation for what we are doing here, if you think that the removal of the annotation and reflection isn't worth doing, that is OK too.
>
> Thinking a bit more, I think we can even get rid of the reflection used in `create()` methods implementation, if we wanted to, by doing something like this:
> 
> 
> private record RandomGenEntry(Class<? extends RandomGenerator> randomGenClass, int i, int j,
>                                   int k, int equiDistribution, boolean stochastic,
>                                   boolean hardware) {
> 
>         RandomGenerator create() {
>             String algo = randomGenClass.getSimpleName();
>             return switch (algo) {
>                 case "Random" -> new Random();
>                 case "L128X1024MixRandom" -> new L128X1024MixRandom();
>                 case "Xoshiro256PlusPlus" -> new Xoshiro256PlusPlus();
>                 // ... so on for the rest
>                 default -> throw new InternalError("should not happen");
>             };
>         }
> 
>         RandomGenerator create(long seed) {
>             String algo = randomGenClass.getSimpleName();
>             return switch (algo) {
>                 case "Random", "SplittableRandom", "SecureRandom" -> {
>                     throw new UnsupportedOperationException("cannot construct with a long seed");
>                 }
>                 case "L128X1024MixRandom" -> new L128X1024MixRandom(seed);
>                 case "Xoshiro256PlusPlus" -> new Xoshiro256PlusPlus(seed);
>                 // ... so on for the rest
>                 default -> throw new InternalError("should not happen");
>             };
>         }
> 
>         RandomGenerator create(byte[] seed) {
>             String algo = randomGenClass.getSimpleName();
>             return switch (algo) {
>                 case "Random", "SplittableRandom", "SecureRandom" -> {
>                     throw new UnsupportedOperationException("cannot construct with a byte[] seed");
>                 }
>                 case "L128X1024MixRandom" -> new L128X1024MixRandom(seed);
>                 case "Xoshiro256PlusPlus" -> new Xoshiro256PlusPlus(seed);
>                 // ... so on for the rest
>                 default -> throw new InternalError("should not happen");
>             };
>         }
>     }
> 
>     
>     private static final Map<String, RandomGenEntry> FACTORY_MAP = ... // construct the map

@jaikiran I agree that we can simplify even more. I just wanted to change as little as possible in this PR to facilitate reviews.
Shall I push your proposed changes in this PR or is a followup PR preferable?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19212#discussion_r1598459168

From jpai at openjdk.org  Mon May 13 13:21:06 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 13 May 2024 13:21:06 GMT
Subject: RFR: 8332086: Remove the usage of ServiceLoader in
 j.u.r.RandomGeneratorFactory
In-Reply-To: <DfnK-PUg49spHSshZ_W_LHPX4tDnW3xHpm_LHT-WPcc=.c591d07c-481a-4f58-b9f8-aeff4399b25b@github.com>
References: <hfB86NksORc-aC6zVxHel_QQd_9aB629SfQjXvl6q5U=.e31daa4b-5cf6-4f3f-a757-79e818a18978@github.com>
 <mH_LU2mwBmn13nuF039baoqq2ibSbmqct0WFxhVv1vg=.b904990f-e389-4c81-9d19-2b9d8ca35e99@github.com>
 <Qi40QQbVUG444KUJxqWVjKaHj5-X53SiFmXPhI99Iho=.a0f56e95-41bf-4d54-9e76-951f1535b698@github.com>
 <DfnK-PUg49spHSshZ_W_LHPX4tDnW3xHpm_LHT-WPcc=.c591d07c-481a-4f58-b9f8-aeff4399b25b@github.com>
Message-ID: <sHUoeBI2PVWqN20vm9bwn4jSA9YoBgrv3Mizp6ahB2A=.922696a0-9322-4359-984b-72872b3b2fec@github.com>

On Mon, 13 May 2024 13:14:57 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> Thinking a bit more, I think we can even get rid of the reflection used in `create()` methods implementation, if we wanted to, by doing something like this:
>> 
>> 
>> private record RandomGenEntry(Class<? extends RandomGenerator> randomGenClass, int i, int j,
>>                                   int k, int equiDistribution, boolean stochastic,
>>                                   boolean hardware) {
>> 
>>         RandomGenerator create() {
>>             String algo = randomGenClass.getSimpleName();
>>             return switch (algo) {
>>                 case "Random" -> new Random();
>>                 case "L128X1024MixRandom" -> new L128X1024MixRandom();
>>                 case "Xoshiro256PlusPlus" -> new Xoshiro256PlusPlus();
>>                 // ... so on for the rest
>>                 default -> throw new InternalError("should not happen");
>>             };
>>         }
>> 
>>         RandomGenerator create(long seed) {
>>             String algo = randomGenClass.getSimpleName();
>>             return switch (algo) {
>>                 case "Random", "SplittableRandom", "SecureRandom" -> {
>>                     throw new UnsupportedOperationException("cannot construct with a long seed");
>>                 }
>>                 case "L128X1024MixRandom" -> new L128X1024MixRandom(seed);
>>                 case "Xoshiro256PlusPlus" -> new Xoshiro256PlusPlus(seed);
>>                 // ... so on for the rest
>>                 default -> throw new InternalError("should not happen");
>>             };
>>         }
>> 
>>         RandomGenerator create(byte[] seed) {
>>             String algo = randomGenClass.getSimpleName();
>>             return switch (algo) {
>>                 case "Random", "SplittableRandom", "SecureRandom" -> {
>>                     throw new UnsupportedOperationException("cannot construct with a byte[] seed");
>>                 }
>>                 case "L128X1024MixRandom" -> new L128X1024MixRandom(seed);
>>                 case "Xoshiro256PlusPlus" -> new Xoshiro256PlusPlus(seed);
>>                 // ... so on for the rest
>>                 default -> throw new InternalError("should not happen");
>>             };
>>         }
>>     }
>> 
>>     
>>     private static final Map<String, RandomGenEntry> FACTORY_MAP = ... // construct the map
>
> @jaikiran I agree that we can simplify even more. I just wanted to change as little as possible in this PR to facilitate reviews.
> Shall I push your proposed changes in this PR or is a followup PR preferable?

A followup PR is fine. I think once this PR which addresses the API aspects (like removal of ServiceLoader and then updates to the create() method javadoc) is integrated, then the subsequent PR can just be all internal implementation changes like the proposed removal of reflection.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19212#discussion_r1598464086

From erikj at openjdk.org  Mon May 13 13:23:11 2024
From: erikj at openjdk.org (Erik Joelsson)
Date: Mon, 13 May 2024 13:23:11 GMT
Subject: RFR: 8331671: Implement JEP 472: Prepare to Restrict the Use of
 JNI [v3]
In-Reply-To: <jUWaDowOZsL42UtliIOoCe7WfowooCW1zvcVKyFnL7g=.4b20b555-3651-4fca-9ede-1652dec95e9c@github.com>
References: <CZGbki5iFdCGPPagE-ya-_L8Nkgf7OunywApOsxC548=.2cee82fa-a5d2-4165-b012-30982a85030a@github.com>
 <jUWaDowOZsL42UtliIOoCe7WfowooCW1zvcVKyFnL7g=.4b20b555-3651-4fca-9ede-1652dec95e9c@github.com>
Message-ID: <SWx03p48zvHP1Ij-QdX_jp8Asy7CJKXNeN22LE20H9Q=.f966cc14-6d7d-48b0-96f9-6f04efa105b2@github.com>

On Mon, 13 May 2024 11:47:38 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This PR implements [JEP 472](https://openjdk.org/jeps/472), by restricting the use of JNI in the following ways:
>> 
>> * `System::load` and `System::loadLibrary` are now restricted methods
>> * `Runtime::load` and `Runtime::loadLibrary` are now restricted methods
>> * binding a JNI `native` method declaration to a native implementation is now considered a restricted operation
>> 
>> This PR slightly changes the way in which the JDK deals with restricted methods, even for FFM API calls. In Java 22, the single `--enable-native-access` was used both to specify a set of modules for which native access should be allowed *and* to specify whether illegal native access (that is, native access occurring from a module not specified by `--enable-native-access`) should be treated as an error or a warning. More specifically, an error is only issued if the `--enable-native-access flag` is used at least once.
>> 
>> Here, a new flag is introduced, namely `illegal-native-access=allow/warn/deny`, which is used to specify what should happen when access to a restricted method and/or functionality is found outside the set of modules specified with `--enable-native-access`. The default policy is `warn`, but users can select `allow` to suppress the warnings, or `deny` to cause `IllegalCallerException` to be thrown. This aligns the treatment of restricted methods with other mechanisms, such as `--illegal-access` and the more recent `--sun-misc-unsafe-memory-access`.
>> 
>> Some changes were required in the package-info javadoc for `java.lang.foreign`, to reflect the changes in the command line flags described above.
>
> Maurizio Cimadamore has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Fix another typo
>  - Fix typo
>  - Add more comments

Build changes look good.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19213#issuecomment-2107563120

From rgiulietti at openjdk.org  Mon May 13 13:24:17 2024
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Mon, 13 May 2024 13:24:17 GMT
Subject: RFR: 8332086: Remove the usage of ServiceLoader in
 j.u.r.RandomGeneratorFactory
In-Reply-To: <sHUoeBI2PVWqN20vm9bwn4jSA9YoBgrv3Mizp6ahB2A=.922696a0-9322-4359-984b-72872b3b2fec@github.com>
References: <hfB86NksORc-aC6zVxHel_QQd_9aB629SfQjXvl6q5U=.e31daa4b-5cf6-4f3f-a757-79e818a18978@github.com>
 <mH_LU2mwBmn13nuF039baoqq2ibSbmqct0WFxhVv1vg=.b904990f-e389-4c81-9d19-2b9d8ca35e99@github.com>
 <Qi40QQbVUG444KUJxqWVjKaHj5-X53SiFmXPhI99Iho=.a0f56e95-41bf-4d54-9e76-951f1535b698@github.com>
 <DfnK-PUg49spHSshZ_W_LHPX4tDnW3xHpm_LHT-WPcc=.c591d07c-481a-4f58-b9f8-aeff4399b25b@github.com>
 <sHUoeBI2PVWqN20vm9bwn4jSA9YoBgrv3Mizp6ahB2A=.922696a0-9322-4359-984b-72872b3b2fec@github.com>
Message-ID: <WTK_r-lXJnTZBOBYqYogrrDrvwh78Jtf_scpcCj29Bs=.f38f8fd6-9bfb-4a80-81f8-2a807fab5a63@github.com>

On Mon, 13 May 2024 13:18:24 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> @jaikiran I agree that we can simplify even more. I just wanted to change as little as possible in this PR to facilitate reviews.
>> Shall I push your proposed changes in this PR or is a followup PR preferable?
>
> A followup PR is fine. I think once this PR which addresses the API aspects (like removal of ServiceLoader and then updates to the create() method javadoc) is integrated, then the subsequent PR can just be all internal implementation changes like the proposed removal of reflection.

Fine with me.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19212#discussion_r1598468638

From jpai at openjdk.org  Mon May 13 13:34:03 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 13 May 2024 13:34:03 GMT
Subject: RFR: 8332086: Remove the usage of ServiceLoader in
 j.u.r.RandomGeneratorFactory
In-Reply-To: <hfB86NksORc-aC6zVxHel_QQd_9aB629SfQjXvl6q5U=.e31daa4b-5cf6-4f3f-a757-79e818a18978@github.com>
References: <hfB86NksORc-aC6zVxHel_QQd_9aB629SfQjXvl6q5U=.e31daa4b-5cf6-4f3f-a757-79e818a18978@github.com>
Message-ID: <sH7HDHphCZgeVo_fSIKBwcDHH-l3pZZPnc4m_8HZFLs=.e9676a9e-c8b5-48ec-9e5f-4225b9c5b318@github.com>

On Mon, 13 May 2024 08:47:50 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

> All random number generator algorithms are implemented in module `java.base`. The usage of `ServiceLoader` in `j.u.r.RandomGeneratorFactory` is no longer needed.

src/java.base/share/classes/java/util/random/RandomGeneratorFactory.java line 187:

> 185:      private RandomGeneratorProperties getProperties() {
> 186:         if (properties == null) {  // volatile load
> 187:             synchronized (rgClass) {

The synchronization on `rgClass` to intialize an instance field `properties` appears odd here. I think this should be synchronized on `this`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19212#discussion_r1598485190

From jpai at openjdk.org  Mon May 13 13:44:14 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 13 May 2024 13:44:14 GMT
Subject: RFR: 8332086: Remove the usage of ServiceLoader in
 j.u.r.RandomGeneratorFactory
In-Reply-To: <hfB86NksORc-aC6zVxHel_QQd_9aB629SfQjXvl6q5U=.e31daa4b-5cf6-4f3f-a757-79e818a18978@github.com>
References: <hfB86NksORc-aC6zVxHel_QQd_9aB629SfQjXvl6q5U=.e31daa4b-5cf6-4f3f-a757-79e818a18978@github.com>
Message-ID: <Ci07x-EpJQAZE_fFvDkdFLxFpu3MPsrUIEpskZ6_6io=.acc53609-3a86-448d-80e1-86f263e6054f@github.com>

On Mon, 13 May 2024 08:47:50 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

> All random number generator algorithms are implemented in module `java.base`. The usage of `ServiceLoader` in `j.u.r.RandomGeneratorFactory` is no longer needed.

src/java.base/share/classes/java/util/random/RandomGeneratorFactory.java line 299:

> 297:     private void ensureConstructors() {
> 298:         if (ctor == null) {  // volatile load
> 299:             synchronized (rgClass) {

Here too I think we should synchronize on `this` - we would want to allow multiple different instances of a `RandomGeneratorFactory` for the same `RandomGenerator` class type to be able to concurrently instantiate their individual instance fields (like the `ctor`(s) and `properties`).

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19212#discussion_r1598500425

From weijun at openjdk.org  Mon May 13 13:48:23 2024
From: weijun at openjdk.org (Weijun Wang)
Date: Mon, 13 May 2024 13:48:23 GMT
Subject: RFR: 8331671: Implement JEP 472: Prepare to Restrict the Use of
 JNI [v3]
In-Reply-To: <jUWaDowOZsL42UtliIOoCe7WfowooCW1zvcVKyFnL7g=.4b20b555-3651-4fca-9ede-1652dec95e9c@github.com>
References: <CZGbki5iFdCGPPagE-ya-_L8Nkgf7OunywApOsxC548=.2cee82fa-a5d2-4165-b012-30982a85030a@github.com>
 <jUWaDowOZsL42UtliIOoCe7WfowooCW1zvcVKyFnL7g=.4b20b555-3651-4fca-9ede-1652dec95e9c@github.com>
Message-ID: <aWi7nGuAWfgfr8Zav9c827Na7XNHhgqJyW30njaf3IU=.435796f8-6007-4d00-ac3e-afc3a07e1d3c@github.com>

On Mon, 13 May 2024 11:47:38 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This PR implements [JEP 472](https://openjdk.org/jeps/472), by restricting the use of JNI in the following ways:
>> 
>> * `System::load` and `System::loadLibrary` are now restricted methods
>> * `Runtime::load` and `Runtime::loadLibrary` are now restricted methods
>> * binding a JNI `native` method declaration to a native implementation is now considered a restricted operation
>> 
>> This PR slightly changes the way in which the JDK deals with restricted methods, even for FFM API calls. In Java 22, the single `--enable-native-access` was used both to specify a set of modules for which native access should be allowed *and* to specify whether illegal native access (that is, native access occurring from a module not specified by `--enable-native-access`) should be treated as an error or a warning. More specifically, an error is only issued if the `--enable-native-access flag` is used at least once.
>> 
>> Here, a new flag is introduced, namely `illegal-native-access=allow/warn/deny`, which is used to specify what should happen when access to a restricted method and/or functionality is found outside the set of modules specified with `--enable-native-access`. The default policy is `warn`, but users can select `allow` to suppress the warnings, or `deny` to cause `IllegalCallerException` to be thrown. This aligns the treatment of restricted methods with other mechanisms, such as `--illegal-access` and the more recent `--sun-misc-unsafe-memory-access`.
>> 
>> Some changes were required in the package-info javadoc for `java.lang.foreign`, to reflect the changes in the command line flags described above.
>
> Maurizio Cimadamore has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Fix another typo
>  - Fix typo
>  - Add more comments

security changes (`java.security.jgss`, `jdk.crypto.cryptoki`, `jdk.crypto.mscapi`, and `jdk.security.auth`) look good.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19213#issuecomment-2107621474

From rgiulietti at openjdk.org  Mon May 13 13:58:03 2024
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Mon, 13 May 2024 13:58:03 GMT
Subject: RFR: 8332086: Remove the usage of ServiceLoader in
 j.u.r.RandomGeneratorFactory
In-Reply-To: <Ci07x-EpJQAZE_fFvDkdFLxFpu3MPsrUIEpskZ6_6io=.acc53609-3a86-448d-80e1-86f263e6054f@github.com>
References: <hfB86NksORc-aC6zVxHel_QQd_9aB629SfQjXvl6q5U=.e31daa4b-5cf6-4f3f-a757-79e818a18978@github.com>
 <Ci07x-EpJQAZE_fFvDkdFLxFpu3MPsrUIEpskZ6_6io=.acc53609-3a86-448d-80e1-86f263e6054f@github.com>
Message-ID: <dE86Jh9gjuZRA5ahKBccF1_QIy_OvCtvfXVkJiTscHY=.f4a1316e-05de-4bf7-8e9a-7e3de25b7534@github.com>

On Mon, 13 May 2024 13:41:50 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> All random number generator algorithms are implemented in module `java.base`. The usage of `ServiceLoader` in `j.u.r.RandomGeneratorFactory` is no longer needed.
>
> src/java.base/share/classes/java/util/random/RandomGeneratorFactory.java line 299:
> 
>> 297:     private void ensureConstructors() {
>> 298:         if (ctor == null) {  // volatile load
>> 299:             synchronized (rgClass) {
> 
> Here too I think we should synchronize on `this` - we would want to allow multiple different instances of a `RandomGeneratorFactory` for the same `RandomGenerator` class type to be able to concurrently instantiate their individual instance fields (like the `ctor`(s) and `properties`).

Then I would even remove the double-checking idiom, the `volatile` on `ctor` and `properties`, and declare methods `getProperties()` and `ensureConstructors()` as `synchronized`.
I'm not sure that the double-checking optimization brings much value on contemporary JVMs.

But I feel that the followup PR discussed before wouldn't need `synchronized` at all.

WDYT?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19212#discussion_r1598520001

From jpai at openjdk.org  Mon May 13 14:11:06 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 13 May 2024 14:11:06 GMT
Subject: RFR: 8332086: Remove the usage of ServiceLoader in
 j.u.r.RandomGeneratorFactory
In-Reply-To: <dE86Jh9gjuZRA5ahKBccF1_QIy_OvCtvfXVkJiTscHY=.f4a1316e-05de-4bf7-8e9a-7e3de25b7534@github.com>
References: <hfB86NksORc-aC6zVxHel_QQd_9aB629SfQjXvl6q5U=.e31daa4b-5cf6-4f3f-a757-79e818a18978@github.com>
 <Ci07x-EpJQAZE_fFvDkdFLxFpu3MPsrUIEpskZ6_6io=.acc53609-3a86-448d-80e1-86f263e6054f@github.com>
 <dE86Jh9gjuZRA5ahKBccF1_QIy_OvCtvfXVkJiTscHY=.f4a1316e-05de-4bf7-8e9a-7e3de25b7534@github.com>
Message-ID: <AnAgiRrCwGoznaP_UYRnok6FtpJYZsgk2uWtSb79w2g=.50559a1b-8ed2-41bc-acde-90abe3ede336@github.com>

On Mon, 13 May 2024 13:54:18 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

> Then I would even remove the double-checking idiom, the volatile on ctor and properties, and declare methods getProperties() and ensureConstructors() as synchronized.
> I'm not sure that the double-checking optimization brings much value on contemporary JVMs.

Making the methods synchronized would bring in a penalty that there will always be a monitor entry at every call site, even after the `properites` and `ctor`(s) are initialized. Ideally, we should just do all of this intialization in the constructor of the `RandomGeneratorFactory`, the one which takes the `Class<>` type of the `RandomGenerator`. We can then make the `properties` and the `ctor`(s) all `final` and not have to worry about any synchronization or volatile semantics. You would of course have to rework the ensureConstructors to not throw an exception at that time.

> But I feel that the followup PR discussed before wouldn't need synchronized at all.

Correct. The more I think about it, I think cleaning up all this in this PR itself might make both reviewing and the implementation a bit more simpler. What's your thoughts?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19212#discussion_r1598540564

From rgiulietti at openjdk.org  Mon May 13 14:16:17 2024
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Mon, 13 May 2024 14:16:17 GMT
Subject: RFR: 8332086: Remove the usage of ServiceLoader in
 j.u.r.RandomGeneratorFactory
In-Reply-To: <AnAgiRrCwGoznaP_UYRnok6FtpJYZsgk2uWtSb79w2g=.50559a1b-8ed2-41bc-acde-90abe3ede336@github.com>
References: <hfB86NksORc-aC6zVxHel_QQd_9aB629SfQjXvl6q5U=.e31daa4b-5cf6-4f3f-a757-79e818a18978@github.com>
 <Ci07x-EpJQAZE_fFvDkdFLxFpu3MPsrUIEpskZ6_6io=.acc53609-3a86-448d-80e1-86f263e6054f@github.com>
 <dE86Jh9gjuZRA5ahKBccF1_QIy_OvCtvfXVkJiTscHY=.f4a1316e-05de-4bf7-8e9a-7e3de25b7534@github.com>
 <AnAgiRrCwGoznaP_UYRnok6FtpJYZsgk2uWtSb79w2g=.50559a1b-8ed2-41bc-acde-90abe3ede336@github.com>
Message-ID: <P-aEvEwC7qTVJMWr1bCJx5Bt77QN8Xu_9ry6h9AcqsI=.fd5b142a-ef08-430e-93b1-6ed86ce5fc47@github.com>

On Mon, 13 May 2024 14:08:01 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Then I would even remove the double-checking idiom, the `volatile` on `ctor` and `properties`, and declare methods `getProperties()` and `ensureConstructors()` as `synchronized`.
>> I'm not sure that the double-checking optimization brings much value on contemporary JVMs.
>> 
>> But I feel that the followup PR discussed before wouldn't need `synchronized` at all.
>> 
>> WDYT?
>
>> Then I would even remove the double-checking idiom, the volatile on ctor and properties, and declare methods getProperties() and ensureConstructors() as synchronized.
>> I'm not sure that the double-checking optimization brings much value on contemporary JVMs.
> 
> Making the methods synchronized would bring in a penalty that there will always be a monitor entry at every call site, even after the `properites` and `ctor`(s) are initialized. Ideally, we should just do all of this intialization in the constructor of the `RandomGeneratorFactory`, the one which takes the `Class<>` type of the `RandomGenerator`. We can then make the `properties` and the `ctor`(s) all `final` and not have to worry about any synchronization or volatile semantics. You would of course have to rework the ensureConstructors to not throw an exception at that time.
> 
>> But I feel that the followup PR discussed before wouldn't need synchronized at all.
> 
> Correct. The more I think about it, I think cleaning up all this in this PR itself might make both reviewing and the implementation a bit more simpler. What's your thoughts?

OK, will do all the work in this PR.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19212#discussion_r1598548744

From dfuchs at openjdk.org  Mon May 13 14:18:11 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 13 May 2024 14:18:11 GMT
Subject: RFR: 8331671: Implement JEP 472: Prepare to Restrict the Use of
 JNI [v3]
In-Reply-To: <jUWaDowOZsL42UtliIOoCe7WfowooCW1zvcVKyFnL7g=.4b20b555-3651-4fca-9ede-1652dec95e9c@github.com>
References: <CZGbki5iFdCGPPagE-ya-_L8Nkgf7OunywApOsxC548=.2cee82fa-a5d2-4165-b012-30982a85030a@github.com>
 <jUWaDowOZsL42UtliIOoCe7WfowooCW1zvcVKyFnL7g=.4b20b555-3651-4fca-9ede-1652dec95e9c@github.com>
Message-ID: <YAZUq9RulpAueG36Dq_BhXOH2xeUZVgZCK59PdoR4fQ=.b40434ab-ee39-4e7c-90ec-49655dfa54a2@github.com>

On Mon, 13 May 2024 11:47:38 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This PR implements [JEP 472](https://openjdk.org/jeps/472), by restricting the use of JNI in the following ways:
>> 
>> * `System::load` and `System::loadLibrary` are now restricted methods
>> * `Runtime::load` and `Runtime::loadLibrary` are now restricted methods
>> * binding a JNI `native` method declaration to a native implementation is now considered a restricted operation
>> 
>> This PR slightly changes the way in which the JDK deals with restricted methods, even for FFM API calls. In Java 22, the single `--enable-native-access` was used both to specify a set of modules for which native access should be allowed *and* to specify whether illegal native access (that is, native access occurring from a module not specified by `--enable-native-access`) should be treated as an error or a warning. More specifically, an error is only issued if the `--enable-native-access flag` is used at least once.
>> 
>> Here, a new flag is introduced, namely `illegal-native-access=allow/warn/deny`, which is used to specify what should happen when access to a restricted method and/or functionality is found outside the set of modules specified with `--enable-native-access`. The default policy is `warn`, but users can select `allow` to suppress the warnings, or `deny` to cause `IllegalCallerException` to be thrown. This aligns the treatment of restricted methods with other mechanisms, such as `--illegal-access` and the more recent `--sun-misc-unsafe-memory-access`.
>> 
>> Some changes were required in the package-info javadoc for `java.lang.foreign`, to reflect the changes in the command line flags described above.
>
> Maurizio Cimadamore has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Fix another typo
>  - Fix typo
>  - Add more comments

Changes to jdk.net and jdk.sctp look ok.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19213#issuecomment-2107695217

From dfuchs at openjdk.org  Mon May 13 14:55:08 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 13 May 2024 14:55:08 GMT
Subject: RFR: 8332086: Remove the usage of ServiceLoader in
 j.u.r.RandomGeneratorFactory
In-Reply-To: <WTK_r-lXJnTZBOBYqYogrrDrvwh78Jtf_scpcCj29Bs=.f38f8fd6-9bfb-4a80-81f8-2a807fab5a63@github.com>
References: <hfB86NksORc-aC6zVxHel_QQd_9aB629SfQjXvl6q5U=.e31daa4b-5cf6-4f3f-a757-79e818a18978@github.com>
 <mH_LU2mwBmn13nuF039baoqq2ibSbmqct0WFxhVv1vg=.b904990f-e389-4c81-9d19-2b9d8ca35e99@github.com>
 <Qi40QQbVUG444KUJxqWVjKaHj5-X53SiFmXPhI99Iho=.a0f56e95-41bf-4d54-9e76-951f1535b698@github.com>
 <DfnK-PUg49spHSshZ_W_LHPX4tDnW3xHpm_LHT-WPcc=.c591d07c-481a-4f58-b9f8-aeff4399b25b@github.com>
 <sHUoeBI2PVWqN20vm9bwn4jSA9YoBgrv3Mizp6ahB2A=.922696a0-9322-4359-984b-72872b3b2fec@github.com>
 <WTK_r-lXJnTZBOBYqYogrrDrvwh78Jtf_scpcCj29Bs=.f38f8fd6-9bfb-4a80-81f8-2a807fab5a63@github.com>
Message-ID: <bW7PoG7haLsVgI4aavzO94m5JEWI7_JWR3T_2GrC71Q=.ea2b6e57-5822-452c-9ac2-e15fd6dd8854@github.com>

On Mon, 13 May 2024 13:21:23 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> A followup PR is fine. I think once this PR which addresses the API aspects (like removal of ServiceLoader and then updates to the create() method javadoc) is integrated, then the subsequent PR can just be all internal implementation changes like the proposed removal of reflection.
>
> Fine with me.

Not sure if that's an issue - but if you wanted/needed to delay the loading of those random generator classes that will not be used until something actually wants to use them, you could consider using a `Supplier<Class<? extends RandomGenerator>>` or a `Supplier<RandomGenEntry>` for the `FACTORY_MAP` values?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19212#discussion_r1598616209

From duke at openjdk.org  Mon May 13 15:15:18 2024
From: duke at openjdk.org (Marco N.)
Date: Mon, 13 May 2024 15:15:18 GMT
Subject: RFR: 8314891: Additional Zip64 extra header validation [v8]
In-Reply-To: <w8mjSJsV9P08BBRm_9m2f2Hjrhoq3iM_A_GO5FOWnyk=.e21bb2ea-2172-4f81-b310-9277e178a002@github.com>
References: <YkC5qi-66NinohgTcDC6O4xj-AlDVFoZ4tFB1SC3ILU=.9b2fe35a-98b3-4b3d-b949-099aa7b4a133@github.com>
 <HxOc6Z5N0Jqgggzf9U50vJpUN6YYh6MRCcjqUcV5nIY=.3ab63812-0f96-461d-a7a2-db670966b6fe@github.com>
 <PYbfeZbQcW4ZkQgkdJzB5Jkvx5xdEUrzraoJZRBtins=.f096e39b-ea1d-460e-911a-2f9a7b92dd3f@github.com>
 <w8mjSJsV9P08BBRm_9m2f2Hjrhoq3iM_A_GO5FOWnyk=.e21bb2ea-2172-4f81-b310-9277e178a002@github.com>
Message-ID: <2xBEUXP70E70gP3UcGjVeP8-QRqiKpmnxx_UL7Gl1VE=.7aef69cd-73be-4411-ad89-71c6b754912e@github.com>

On Wed, 8 Nov 2023 17:27:19 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> @LanceAndersen 
>> 
>> I noticed that this PR did not update `ZipInputStream.readLOC` to perform consistency validation between expected and actual extra field size and values. Any particular reason why processing of LOC headers was not made consistent with CEN?
>
>> @LanceAndersen
>> 
>> I noticed that this PR did not update `ZipInputStream.readLOC` to perform consistency validation between expected and actual extra field size and values. Any particular reason why processing of LOC headers was not made consistent with CEN?
> 
> Intentional, as this was a follow on to the updates which were done previously to the CEN work in August, this is follow on cleanup.
> 
> Updates to ZipInputStream would be done separately under a separate PR or  could be done via your work on 8303866

Hey @LanceAndersen,

It was a common practice in obfuscation, to create zips with invalid headers. This change leads to a behavioral change that affects existing work processes.  Would it be possible to add an system property to restore the old behavior?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15650#issuecomment-2107932136

From alanb at openjdk.org  Mon May 13 15:35:08 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 13 May 2024 15:35:08 GMT
Subject: RFR: 8331671: Implement JEP 472: Prepare to Restrict the Use of
 JNI [v3]
In-Reply-To: <jUWaDowOZsL42UtliIOoCe7WfowooCW1zvcVKyFnL7g=.4b20b555-3651-4fca-9ede-1652dec95e9c@github.com>
References: <CZGbki5iFdCGPPagE-ya-_L8Nkgf7OunywApOsxC548=.2cee82fa-a5d2-4165-b012-30982a85030a@github.com>
 <jUWaDowOZsL42UtliIOoCe7WfowooCW1zvcVKyFnL7g=.4b20b555-3651-4fca-9ede-1652dec95e9c@github.com>
Message-ID: <l7dLX25UBFdbxrTmukfFGZjEXu3hZVEnWkDLIkoAu90=.c8a7fbd7-4e37-46d5-b950-211189279ca2@github.com>

On Mon, 13 May 2024 11:47:38 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This PR implements [JEP 472](https://openjdk.org/jeps/472), by restricting the use of JNI in the following ways:
>> 
>> * `System::load` and `System::loadLibrary` are now restricted methods
>> * `Runtime::load` and `Runtime::loadLibrary` are now restricted methods
>> * binding a JNI `native` method declaration to a native implementation is now considered a restricted operation
>> 
>> This PR slightly changes the way in which the JDK deals with restricted methods, even for FFM API calls. In Java 22, the single `--enable-native-access` was used both to specify a set of modules for which native access should be allowed *and* to specify whether illegal native access (that is, native access occurring from a module not specified by `--enable-native-access`) should be treated as an error or a warning. More specifically, an error is only issued if the `--enable-native-access flag` is used at least once.
>> 
>> Here, a new flag is introduced, namely `illegal-native-access=allow/warn/deny`, which is used to specify what should happen when access to a restricted method and/or functionality is found outside the set of modules specified with `--enable-native-access`. The default policy is `warn`, but users can select `allow` to suppress the warnings, or `deny` to cause `IllegalCallerException` to be thrown. This aligns the treatment of restricted methods with other mechanisms, such as `--illegal-access` and the more recent `--sun-misc-unsafe-memory-access`.
>> 
>> Some changes were required in the package-info javadoc for `java.lang.foreign`, to reflect the changes in the command line flags described above.
>
> Maurizio Cimadamore has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Fix another typo
>  - Fix typo
>  - Add more comments

src/hotspot/share/runtime/arguments.cpp line 2271:

> 2269:     } else if (match_option(option, "--illegal-native-access=", &tail)) {
> 2270:       if (!create_module_property("jdk.module.illegal.native.access", tail, InternalProperty)) {
> 2271:         return JNI_ENOMEM;

I think it would be helpful to get guidance on if this is the right way to add this system property, only because this one not a "module property". The configuration (WriteableProperty + InternalProperty) look right.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19213#discussion_r1598673962

From kevinw at openjdk.org  Mon May 13 15:54:07 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Mon, 13 May 2024 15:54:07 GMT
Subject: RFR: 8330755: ProblemList files have entries referring to
 non-existent tests [v2]
In-Reply-To: <vI3xkUAHKmVbuRrCBuSbUuJYlCHfKH-f9hPY1E0dhmc=.c9ac9fea-bea5-4bd1-ac98-020a0893bf25@github.com>
References: <5vZvc83Zn4IhI5s_IdYqRqw4zjWF93TcQUzl2cD5JLU=.12464c13-9ccc-47d8-851e-883f3fea4a04@github.com>
 <vI3xkUAHKmVbuRrCBuSbUuJYlCHfKH-f9hPY1E0dhmc=.c9ac9fea-bea5-4bd1-ac98-020a0893bf25@github.com>
Message-ID: <eCB7rt6W24EC5z57SOuOcZTOJhqf8N93a6wSfiS4ZrQ=.d25ca267-efef-4f6a-83a4-a505089a46a0@github.com>

On Wed, 24 Apr 2024 10:50:44 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

>> This PR adds a check for the format of ProblemList files and ensures they only have entries referring to existing tests.
>> 
>> The cleanups in the second commit of this PR were done based on the output of `CheckProblemLists`:
>> 
>>> make test TEST=build/problemLists/CheckProblemLists.java
>> ...
>> STDOUT:
>> Checking /Users/dnsimon/dev/jdk-jdk/open/test/hotspot/jtreg/ProblemList-Virtual.txt
>> Checking /Users/dnsimon/dev/jdk-jdk/open/test/hotspot/jtreg/ProblemList-Xcomp.txt
>> Checking /Users/dnsimon/dev/jdk-jdk/open/test/hotspot/jtreg/ProblemList-generational-zgc.txt
>> Checking /Users/dnsimon/dev/jdk-jdk/open/test/hotspot/jtreg/ProblemList-zgc.txt
>> Checking /Users/dnsimon/dev/jdk-jdk/open/test/hotspot/jtreg/ProblemList.txt
>> Checking /Users/dnsimon/dev/jdk-jdk/open/test/jaxp/ProblemList.txt
>> Checking /Users/dnsimon/dev/jdk-jdk/open/test/jdk/ProblemList-Virtual.txt
>> Checking /Users/dnsimon/dev/jdk-jdk/open/test/jdk/ProblemList-Xcomp.txt
>> Checking /Users/dnsimon/dev/jdk-jdk/open/test/jdk/ProblemList-generational-zgc.txt
>> Checking /Users/dnsimon/dev/jdk-jdk/open/test/jdk/ProblemList-zgc.txt
>> Checking /Users/dnsimon/dev/jdk-jdk/open/test/jdk/ProblemList.txt
>> Checking /Users/dnsimon/dev/jdk-jdk/open/test/langtools/ProblemList.txt
>> Checking /Users/dnsimon/dev/jdk-jdk/open/test/lib-test/ProblemList.txt
>> Checked 13 problem list files
>> Test roots:
>>   /Users/dnsimon/dev/jdk-jdk/open/test/jdk
>>   /Users/dnsimon/dev/jdk-jdk/open/test/lib-test
>>   /Users/dnsimon/dev/jdk-jdk/open/test/failure_handler/test
>>   /Users/dnsimon/dev/jdk-jdk/open/test/jaxp
>>   /Users/dnsimon/dev/jdk-jdk/open/test/langtools
>>   /Users/dnsimon/dev/jdk-jdk/open/test/hotspot/jtreg
>> Following errors found:
>> /Users/dnsimon/dev/jdk-jdk/open/test/hotspot/jtreg/ProblemList.txt:174: vmTestbase/gc/lock/jni/jnilock002/TestDescription.java does not exist under any test root
>> vmTestbase/gc/lock/jni/jnilock002/TestDescription.java 8192647 generic-all
>> 
>> /Users/dnsimon/dev/jdk-jdk/open/test/jdk/ProblemList-Virtual.txt:77: TestAndIssue[test=java/util/Properties/StoreReproducibilityTest.java, issueId=0000000] duplicates /Users/dnsimon/dev/jdk-jdk/open/test/jdk/ProblemList-Virtual.txt:76
>> java/util/Properties/StoreReproducibilityTest.java 0000000 generic-all
>> 
>> /Users/dnsimon/dev/jdk-jdk/open/test/jdk/ProblemList.txt:516: java/lang/management/MemoryMXBean/PendingAllGC.sh does not exist under any test root
>> java/lang/management/MemoryMXBean/PendingAllGC.sh               8158837 generic-all
>> 
>> ...
>
> Doug Simon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   removed CheckProblemLists.java

The tidyup looks good!

I don't understand that this is titled as JDK-8330755 but that's already integrated.  So this needs to be done in a separate JBS entry and if the suggested CheckProblemLists.java is not going to be in it, we remove that from the description.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18879#issuecomment-2108075635

From ascarpino at openjdk.org  Mon May 13 16:22:09 2024
From: ascarpino at openjdk.org (Anthony Scarpino)
Date: Mon, 13 May 2024 16:22:09 GMT
Subject: RFR: 8329538: Accelerate P256 on x86_64 using Montgomery intrinsic
 [v9]
In-Reply-To: <g3g_VMiSRzuhMJ2JIlmtES7TjMGbKWxBMkfFvsQfvOs=.e0dea05e-8adc-48f3-8d1c-81352311de9c@github.com>
References: <hanRK4GzOkFV8kG1gZRy8Br53trw4-Tu6G6uO8nsFuk=.d5bf723a-f683-4759-ac9e-4a58cb430f03@github.com>
 <g3g_VMiSRzuhMJ2JIlmtES7TjMGbKWxBMkfFvsQfvOs=.e0dea05e-8adc-48f3-8d1c-81352311de9c@github.com>
Message-ID: <lp7pfkPAMxXhAalMRhBiuGdxVKRH8OAtIJ9RErzJBfg=.eb978052-f938-4b24-b993-35c8488292a1@github.com>

On Fri, 10 May 2024 00:19:32 GMT, Volodymyr Paprotski <duke at openjdk.org> wrote:

>> Performance. Before:
>> 
>> Benchmark                        (algorithm)  (dataSize)  (keyLength)  (provider)   Mode  Cnt     Score    Error  Units
>> SignatureBench.ECDSA.sign    SHA256withECDSA        1024          256              thrpt    3  6443.934 ?  6.491  ops/s
>> SignatureBench.ECDSA.sign    SHA256withECDSA       16384          256              thrpt    3  6152.979 ?  4.954  ops/s
>> SignatureBench.ECDSA.verify  SHA256withECDSA        1024          256              thrpt    3  1895.410 ? 36.979  ops/s
>> SignatureBench.ECDSA.verify  SHA256withECDSA       16384          256              thrpt    3  1878.955 ? 45.487  ops/s
>> Benchmark                                            (algorithm)  (keyLength)  (kpgAlgorithm)  (provider)   Mode  Cnt     Score    Error  Units
>> o.o.b.j.c.full.KeyAgreementBench.EC.generateSecret          ECDH          256              EC              thrpt    3  1357.810 ? 26.584  ops/s
>> o.o.b.j.c.small.KeyAgreementBench.EC.generateSecret         ECDH          256              EC              thrpt    3  1352.119 ? 23.547  ops/s
>> Benchmark                          (isMontBench)   Mode  Cnt     Score    Error  Units
>> PolynomialP256Bench.benchMultiply          false  thrpt    3  1746.126 ? 10.970  ops/s
>> 
>> Performance, no intrinsic:
>> 
>> Benchmark                        (algorithm)  (dataSize)  (keyLength)  (provider)   Mode  Cnt     Score     Error  Units
>> SignatureBench.ECDSA.sign    SHA256withECDSA        1024          256              thrpt    3  6529.839 ?  42.420  ops/s
>> SignatureBench.ECDSA.sign    SHA256withECDSA       16384          256              thrpt    3  6199.747 ? 133.566  ops/s
>> SignatureBench.ECDSA.verify  SHA256withECDSA        1024          256              thrpt    3  1973.676 ?  54.071  ops/s
>> SignatureBench.ECDSA.verify  SHA256withECDSA       16384          256              thrpt    3  1932.127 ?  35.920  ops/s
>> Benchmark                                            (algorithm)  (keyLength)  (kpgAlgorithm)  (provider)   Mode  Cnt     Score    Error  Units
>> o.o.b.j.c.full.KeyAgreementBench.EC.generateSecret          ECDH          256              EC              thrpt    3  1355.788 ? 29.858  ops/s
>> o.o.b.j.c.small.KeyAgreementBench.EC.generateSecret         ECDH          256              EC              thrpt    3  1346.523 ? 28.722  ops/s
>> Benchmark                          (isMontBench)   Mode  Cnt     Score    Error  Units
>> PolynomialP256Bench.benchMultiply           true  thrpt    3  1919.57...
>
> Volodymyr Paprotski has updated the pull request incrementally with one additional commit since the last revision:
> 
>   whitespace

The changes look good and have passed testing

-------------

Marked as reviewed by ascarpino (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18583#pullrequestreview-2053158639

From vklang at openjdk.org  Mon May 13 16:50:17 2024
From: vklang at openjdk.org (Viktor Klang)
Date: Mon, 13 May 2024 16:50:17 GMT
Subject: RFR: 8331987: Enhance stacktrace clarity for CompletableFuture
 CancellationException
Message-ID: <JI-ghId-imtBqmNm850oQMNp-9p79tGMjfTRDdXz6D0=.fc134f86-914c-4484-9236-af162de3b99e@github.com>

This change adds wrapping of the CancellationException produced by CompletableFuture::get() and CompletableFuture::join() to add more diagnostic information and align better with FutureTask.

Running the sample code from the JBS issue in JShell will produce the following:


jshell> java.util.concurrent.CancellationException: 
	at java.base/java.util.concurrent.CompletableFuture.reportGet(CompletableFuture.java:392)
	at java.base/java.util.concurrent.CompletableFuture.get(CompletableFuture.java:2073)
	at REPL.$JShell$18.m2($JShell$18.java:10)
	at REPL.$JShell$17.m1($JShell$17.java:8)
	at REPL.$JShell$16B.lambda$main$0($JShell$16B.java:8)
	at java.base/java.lang.Thread.run(Thread.java:1575)
Caused by: java.util.concurrent.CancellationException
	at java.base/java.util.concurrent.CompletableFuture.cancel(CompletableFuture.java:2510)
	at REPL.$JShell$16B.lambda$main$1($JShell$16B.java:11)
	... 1 more

-------------

Commit messages:
 - Make it possible to customize the message when wrapping a CancellationException
 - Adding wrapping of CompletableFuture CancellationExceptions from get() and join() to add diagnostic information

Changes: https://git.openjdk.org/jdk/pull/19219/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19219&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8331987
  Stats: 29 lines in 3 files changed: 25 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/19219.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19219/head:pull/19219

PR: https://git.openjdk.org/jdk/pull/19219

From vklang at openjdk.org  Mon May 13 16:50:17 2024
From: vklang at openjdk.org (Viktor Klang)
Date: Mon, 13 May 2024 16:50:17 GMT
Subject: RFR: 8331987: Enhance stacktrace clarity for CompletableFuture
 CancellationException
In-Reply-To: <JI-ghId-imtBqmNm850oQMNp-9p79tGMjfTRDdXz6D0=.fc134f86-914c-4484-9236-af162de3b99e@github.com>
References: <JI-ghId-imtBqmNm850oQMNp-9p79tGMjfTRDdXz6D0=.fc134f86-914c-4484-9236-af162de3b99e@github.com>
Message-ID: <YTzt2Siq8dmERS0HWJN6zPUW0d3KNzAd3VPJeJv8__4=.b9e1450f-e66a-46f3-bb40-e53c32360393@github.com>

On Mon, 13 May 2024 16:41:37 GMT, Viktor Klang <vklang at openjdk.org> wrote:

> This change adds wrapping of the CancellationException produced by CompletableFuture::get() and CompletableFuture::join() to add more diagnostic information and align better with FutureTask.
> 
> Running the sample code from the JBS issue in JShell will produce the following:
> 
> 
> jshell> java.util.concurrent.CancellationException: 
> 	at java.base/java.util.concurrent.CompletableFuture.reportGet(CompletableFuture.java:392)
> 	at java.base/java.util.concurrent.CompletableFuture.get(CompletableFuture.java:2073)
> 	at REPL.$JShell$18.m2($JShell$18.java:10)
> 	at REPL.$JShell$17.m1($JShell$17.java:8)
> 	at REPL.$JShell$16B.lambda$main$0($JShell$16B.java:8)
> 	at java.base/java.lang.Thread.run(Thread.java:1575)
> Caused by: java.util.concurrent.CancellationException
> 	at java.base/java.util.concurrent.CompletableFuture.cancel(CompletableFuture.java:2510)
> 	at REPL.$JShell$16B.lambda$main$1($JShell$16B.java:11)
> 	... 1 more

@DougLea @AlanBateman Submitting this for review as we discussed.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19219#issuecomment-2108177405

From naoto at openjdk.org  Mon May 13 16:52:36 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 13 May 2024 16:52:36 GMT
Subject: RFR: 8332084: Ensure JdkConsoleImpl.restoreEcho visibility in a
 shutdown hook [v2]
In-Reply-To: <9JTWc3FRpfbILlSHlmIU_dL5IE69RTxnSIAOdIte15I=.5854a48f-21d7-42c9-adb7-5e3ed40d1211@github.com>
References: <9JTWc3FRpfbILlSHlmIU_dL5IE69RTxnSIAOdIte15I=.5854a48f-21d7-42c9-adb7-5e3ed40d1211@github.com>
Message-ID: <b-7Sx-vMwizHSk7QCWGjrRBDFdWdBGkjeXYg4xUKYiw=.79cfa170-7a0c-4e48-b863-7f333c84c3b7@github.com>

> Making sure `restoreEcho` correctly reflects the state in the shutdown thread, which differs from the application's thread that issues the `readPassword()` method.

Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:

  Update src/java.base/share/classes/jdk/internal/io/JdkConsoleImpl.java
  
  Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com>

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19184/files
  - new: https://git.openjdk.org/jdk/pull/19184/files/43f555e4..9daf6997

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19184&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19184&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/19184.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19184/head:pull/19184

PR: https://git.openjdk.org/jdk/pull/19184

From liach at openjdk.org  Mon May 13 17:04:18 2024
From: liach at openjdk.org (Chen Liang)
Date: Mon, 13 May 2024 17:04:18 GMT
Subject: RFR: 8292955: Collections.checkedMap Map.merge does not properly
 check key and value [v3]
In-Reply-To: <-vP2LBiOyFHeCcqOM-GB6kKMaWlgc4mj7tvFaobBTLk=.1b3673cc-faf7-4c61-9dd2-736665f4c986@github.com>
References: <uYx7ZckdmpZfQzBBlp-i5gZXe1Y6lKaZ3WfynZJbdeU=.0b7fd470-f97e-40b6-989a-5fd0e5e4e179@github.com>
 <KQYW7IawS6gwsNsRrwaPkvWLfuapu-CJK6Sey-nIsNk=.4d0eeacd-5484-430f-ae99-8d5e124d4e8f@github.com>
 <QKAQFYZG6wZbXTyzF3bnWNGEanKisOODjhLBzAcdevo=.aff77ee9-3df0-4b5c-998c-8caa80cf42da@github.com>
 <-vP2LBiOyFHeCcqOM-GB6kKMaWlgc4mj7tvFaobBTLk=.1b3673cc-faf7-4c61-9dd2-736665f4c986@github.com>
Message-ID: <kYbGJrYlXoA3LzsKPxBh6etOrmngNH3FfIMxGszczU4=.2ab54dcb-c879-4d2f-9695-a9b345809d5f@github.com>

On Fri, 12 Apr 2024 08:55:01 GMT, Viktor Klang <vklang at openjdk.org> wrote:

>> Keep-alive, maybe people like @viktorklang-ora might look at this simple fix too
>
> @liach I'm not a Reviewer (yet) so I'll defer to someone like @stuart-marks :)

@viktorklang-ora Can you just leave an approval as a collections engineer to ensure this patch isn't "accidentally integrated"?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18141#issuecomment-2108242584

From naoto at openjdk.org  Mon May 13 17:06:32 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 13 May 2024 17:06:32 GMT
Subject: RFR: 8332084: Ensure JdkConsoleImpl.restoreEcho visibility in a
 shutdown hook [v3]
In-Reply-To: <9JTWc3FRpfbILlSHlmIU_dL5IE69RTxnSIAOdIte15I=.5854a48f-21d7-42c9-adb7-5e3ed40d1211@github.com>
References: <9JTWc3FRpfbILlSHlmIU_dL5IE69RTxnSIAOdIte15I=.5854a48f-21d7-42c9-adb7-5e3ed40d1211@github.com>
Message-ID: <lLPvzpLD8otrOuchognaYtSQQu75txoPpHGlZVJ7qhY=.6c8f9c14-e22a-496e-a55a-f40676b95a9a@github.com>

> Making sure `restoreEcho` correctly reflects the state in the shutdown thread, which differs from the application's thread that issues the `readPassword()` method.

Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:

  Replaced another unused exception with _

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19184/files
  - new: https://git.openjdk.org/jdk/pull/19184/files/9daf6997..3e7d2e0c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19184&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19184&range=01-02

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/19184.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19184/head:pull/19184

PR: https://git.openjdk.org/jdk/pull/19184

From liach at openjdk.org  Mon May 13 17:10:05 2024
From: liach at openjdk.org (Chen Liang)
Date: Mon, 13 May 2024 17:10:05 GMT
Subject: RFR: 8331987: Enhance stacktrace clarity for CompletableFuture
 CancellationException
In-Reply-To: <JI-ghId-imtBqmNm850oQMNp-9p79tGMjfTRDdXz6D0=.fc134f86-914c-4484-9236-af162de3b99e@github.com>
References: <JI-ghId-imtBqmNm850oQMNp-9p79tGMjfTRDdXz6D0=.fc134f86-914c-4484-9236-af162de3b99e@github.com>
Message-ID: <FFK9diT0iSN5AlgugnlbgmIgvpn-ZfV-Zd8AOtCFGUQ=.745fd473-db3c-4f2f-9da0-ffbfca10c935@github.com>

On Mon, 13 May 2024 16:41:37 GMT, Viktor Klang <vklang at openjdk.org> wrote:

> This change adds wrapping of the CancellationException produced by CompletableFuture::get() and CompletableFuture::join() to add more diagnostic information and align better with FutureTask.
> 
> Running the sample code from the JBS issue in JShell will produce the following:
> 
> 
> jshell> java.util.concurrent.CancellationException: 
> 	at java.base/java.util.concurrent.CompletableFuture.reportGet(CompletableFuture.java:392)
> 	at java.base/java.util.concurrent.CompletableFuture.get(CompletableFuture.java:2073)
> 	at REPL.$JShell$18.m2($JShell$18.java:10)
> 	at REPL.$JShell$17.m1($JShell$17.java:8)
> 	at REPL.$JShell$16B.lambda$main$0($JShell$16B.java:8)
> 	at java.base/java.lang.Thread.run(Thread.java:1575)
> Caused by: java.util.concurrent.CancellationException
> 	at java.base/java.util.concurrent.CompletableFuture.cancel(CompletableFuture.java:2510)
> 	at REPL.$JShell$16B.lambda$main$1($JShell$16B.java:11)
> 	... 1 more

src/java.base/share/classes/java/util/concurrent/CancellationException.java line 72:

> 70:      * @param cause the underlying cancellation exception
> 71:      */
> 72:     CancellationException(String message, CancellationException cause) {

Can we remove the message argument, which is always empty?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19219#discussion_r1598786142

From vklang at openjdk.org  Mon May 13 17:10:05 2024
From: vklang at openjdk.org (Viktor Klang)
Date: Mon, 13 May 2024 17:10:05 GMT
Subject: RFR: 8331987: Enhance stacktrace clarity for CompletableFuture
 CancellationException
In-Reply-To: <FFK9diT0iSN5AlgugnlbgmIgvpn-ZfV-Zd8AOtCFGUQ=.745fd473-db3c-4f2f-9da0-ffbfca10c935@github.com>
References: <JI-ghId-imtBqmNm850oQMNp-9p79tGMjfTRDdXz6D0=.fc134f86-914c-4484-9236-af162de3b99e@github.com>
 <FFK9diT0iSN5AlgugnlbgmIgvpn-ZfV-Zd8AOtCFGUQ=.745fd473-db3c-4f2f-9da0-ffbfca10c935@github.com>
Message-ID: <lDarxIQ9EDGmVWEjxgkrRebIIMrc8dIafmaFsad2gYQ=.997e18e0-84d3-4479-8756-6b608fb46e07@github.com>

On Mon, 13 May 2024 17:03:00 GMT, Chen Liang <liach at openjdk.org> wrote:

>> This change adds wrapping of the CancellationException produced by CompletableFuture::get() and CompletableFuture::join() to add more diagnostic information and align better with FutureTask.
>> 
>> Running the sample code from the JBS issue in JShell will produce the following:
>> 
>> 
>> jshell> java.util.concurrent.CancellationException: 
>> 	at java.base/java.util.concurrent.CompletableFuture.reportGet(CompletableFuture.java:392)
>> 	at java.base/java.util.concurrent.CompletableFuture.get(CompletableFuture.java:2073)
>> 	at REPL.$JShell$18.m2($JShell$18.java:10)
>> 	at REPL.$JShell$17.m1($JShell$17.java:8)
>> 	at REPL.$JShell$16B.lambda$main$0($JShell$16B.java:8)
>> 	at java.base/java.lang.Thread.run(Thread.java:1575)
>> Caused by: java.util.concurrent.CancellationException
>> 	at java.base/java.util.concurrent.CompletableFuture.cancel(CompletableFuture.java:2510)
>> 	at REPL.$JShell$16B.lambda$main$1($JShell$16B.java:11)
>> 	... 1 more
>
> src/java.base/share/classes/java/util/concurrent/CancellationException.java line 72:
> 
>> 70:      * @param cause the underlying cancellation exception
>> 71:      */
>> 72:     CancellationException(String message, CancellationException cause) {
> 
> Can we remove the message argument, which is always empty?

Good question. So what I did was to initially omit it, but then the message becomes the type of the cause, which didn't look right. Then I passed in the empty-string in the constructor, but that seemed too restrictive, since the overload is for in-package use only, I opted for some flexibility in case we want to customize the message on `get` vs `join`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19219#discussion_r1598788602

From vklang at openjdk.org  Mon May 13 17:10:06 2024
From: vklang at openjdk.org (Viktor Klang)
Date: Mon, 13 May 2024 17:10:06 GMT
Subject: RFR: 8331987: Enhance stacktrace clarity for CompletableFuture
 CancellationException
In-Reply-To: <JI-ghId-imtBqmNm850oQMNp-9p79tGMjfTRDdXz6D0=.fc134f86-914c-4484-9236-af162de3b99e@github.com>
References: <JI-ghId-imtBqmNm850oQMNp-9p79tGMjfTRDdXz6D0=.fc134f86-914c-4484-9236-af162de3b99e@github.com>
Message-ID: <680cm1Ox8RH-vgI7V6RzTDV6zDfC3_mamIv3WHfLkIc=.c90f13f8-66ab-4b27-a03b-0f9278dfa535@github.com>

On Mon, 13 May 2024 16:41:37 GMT, Viktor Klang <vklang at openjdk.org> wrote:

> This change adds wrapping of the CancellationException produced by CompletableFuture::get() and CompletableFuture::join() to add more diagnostic information and align better with FutureTask.
> 
> Running the sample code from the JBS issue in JShell will produce the following:
> 
> 
> jshell> java.util.concurrent.CancellationException: 
> 	at java.base/java.util.concurrent.CompletableFuture.reportGet(CompletableFuture.java:392)
> 	at java.base/java.util.concurrent.CompletableFuture.get(CompletableFuture.java:2073)
> 	at REPL.$JShell$18.m2($JShell$18.java:10)
> 	at REPL.$JShell$17.m1($JShell$17.java:8)
> 	at REPL.$JShell$16B.lambda$main$0($JShell$16B.java:8)
> 	at java.base/java.lang.Thread.run(Thread.java:1575)
> Caused by: java.util.concurrent.CancellationException
> 	at java.base/java.util.concurrent.CompletableFuture.cancel(CompletableFuture.java:2510)
> 	at REPL.$JShell$16B.lambda$main$1($JShell$16B.java:11)
> 	... 1 more

src/java.base/share/classes/java/util/concurrent/CompletableFuture.java line 392:

> 390:                 return null;
> 391:             if (x instanceof CancellationException)
> 392:                 throw new CancellationException("", (CancellationException)x);

One option here would be to put "CompletableFuture.get()" or "get()" as a message.

src/java.base/share/classes/java/util/concurrent/CompletableFuture.java line 410:

> 408:                 return null;
> 409:             if (x instanceof CancellationException)
> 410:                 throw new CancellationException("", (CancellationException)x);

One option here would be to put "CompletableFuture.join()" or "join()" as a message.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19219#discussion_r1598789543
PR Review Comment: https://git.openjdk.org/jdk/pull/19219#discussion_r1598789698

From naoto at openjdk.org  Mon May 13 17:15:10 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 13 May 2024 17:15:10 GMT
Subject: RFR: 8332084: Ensure JdkConsoleImpl.restoreEcho visibility in a
 shutdown hook [v3]
In-Reply-To: <lLPvzpLD8otrOuchognaYtSQQu75txoPpHGlZVJ7qhY=.6c8f9c14-e22a-496e-a55a-f40676b95a9a@github.com>
References: <9JTWc3FRpfbILlSHlmIU_dL5IE69RTxnSIAOdIte15I=.5854a48f-21d7-42c9-adb7-5e3ed40d1211@github.com>
 <lLPvzpLD8otrOuchognaYtSQQu75txoPpHGlZVJ7qhY=.6c8f9c14-e22a-496e-a55a-f40676b95a9a@github.com>
Message-ID: <xMclqKwXd7x_MDjTlvLcxtLcSbPckHGc0ZKQFWEkAD0=.7eea947a-648f-41cf-a8ee-aa847e441ca1@github.com>

On Mon, 13 May 2024 17:06:32 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Making sure `restoreEcho` correctly reflects the state in the shutdown thread, which differs from the application's thread that issues the `readPassword()` method.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Replaced another unused exception with _

Thanks, Pavel.

> While it's hard to test this change (hence the `noreg-hard` label), the `restoreEcho` functionality does not seem to be tested at all. Should we add a straightforward test for it, perhaps separately?

Filed: https://bugs.openjdk.org/browse/JDK-8332161

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19184#issuecomment-2108282547

From rgiulietti at openjdk.org  Mon May 13 17:15:11 2024
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Mon, 13 May 2024 17:15:11 GMT
Subject: RFR: 8332086: Remove the usage of ServiceLoader in
 j.u.r.RandomGeneratorFactory
In-Reply-To: <bW7PoG7haLsVgI4aavzO94m5JEWI7_JWR3T_2GrC71Q=.ea2b6e57-5822-452c-9ac2-e15fd6dd8854@github.com>
References: <hfB86NksORc-aC6zVxHel_QQd_9aB629SfQjXvl6q5U=.e31daa4b-5cf6-4f3f-a757-79e818a18978@github.com>
 <mH_LU2mwBmn13nuF039baoqq2ibSbmqct0WFxhVv1vg=.b904990f-e389-4c81-9d19-2b9d8ca35e99@github.com>
 <Qi40QQbVUG444KUJxqWVjKaHj5-X53SiFmXPhI99Iho=.a0f56e95-41bf-4d54-9e76-951f1535b698@github.com>
 <DfnK-PUg49spHSshZ_W_LHPX4tDnW3xHpm_LHT-WPcc=.c591d07c-481a-4f58-b9f8-aeff4399b25b@github.com>
 <sHUoeBI2PVWqN20vm9bwn4jSA9YoBgrv3Mizp6ahB2A=.922696a0-9322-4359-984b-72872b3b2fec@github.com>
 <WTK_r-lXJnTZBOBYqYogrrDrvwh78Jtf_scpcCj29Bs=.f38f8fd6-9bfb-4a80-81f8-2a807fab5a63@github.com>
 <bW7PoG7haLsVgI4aavzO94m5JEWI7_JWR3T_2GrC71Q=.ea2b6e57-5822-452c-9ac2-e15fd6dd8854@github.com>
Message-ID: <7AgEgplJ6-4H2jbXSdIWoNCk_90A_oA86sKoPhbVx1g=.8aaa1e39-04db-4731-a8be-9a53ff994102@github.com>

On Mon, 13 May 2024 14:52:45 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Fine with me.
>
> Not sure if that's an issue - but if you wanted/needed to delay the loading of those random generator classes that will not be used until something actually wants to use them, you could consider using a `Supplier<Class<? extends RandomGenerator>>` or a `Supplier<RandomGenEntry>` for the `FACTORY_MAP` values?

@dfuch You mean not loading the whole batch but only individual classes, as need arises?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19212#discussion_r1598796844

From prappo at openjdk.org  Mon May 13 17:18:07 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Mon, 13 May 2024 17:18:07 GMT
Subject: RFR: 8332084: Ensure JdkConsoleImpl.restoreEcho visibility in a
 shutdown hook [v3]
In-Reply-To: <lLPvzpLD8otrOuchognaYtSQQu75txoPpHGlZVJ7qhY=.6c8f9c14-e22a-496e-a55a-f40676b95a9a@github.com>
References: <9JTWc3FRpfbILlSHlmIU_dL5IE69RTxnSIAOdIte15I=.5854a48f-21d7-42c9-adb7-5e3ed40d1211@github.com>
 <lLPvzpLD8otrOuchognaYtSQQu75txoPpHGlZVJ7qhY=.6c8f9c14-e22a-496e-a55a-f40676b95a9a@github.com>
Message-ID: <wNu2SHy_7xPztaGca18E9LKPfy4sqkWot_2Ak3xe4gA=.9f857143-1d5c-4aed-8b51-01b69eaaa21c@github.com>

On Mon, 13 May 2024 17:06:32 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Making sure `restoreEcho` correctly reflects the state in the shutdown thread, which differs from the application's thread that issues the `readPassword()` method.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Replaced another unused exception with _

Marked as reviewed by prappo (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/19184#pullrequestreview-2053274453

From mcimadamore at openjdk.org  Mon May 13 17:27:10 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 13 May 2024 17:27:10 GMT
Subject: RFR: 8320396: Class-File API ClassModel::verify should include
 checks from hotspot/share/classfile/classFileParser.cpp [v5]
In-Reply-To: <IXrF9AdBnUFrDOFKOrAsLZNJAOx05y4za-PoVzfIGpA=.80ed5ff3-d981-451e-90cc-ed65fa47f2b2@github.com>
References: <0a66asWcJ4_zBrjmReA18BZmsovN1ZeJRRSAPZDMZmo=.5bada03f-d88d-46cd-962d-c1e42c3048c1@github.com>
 <IXrF9AdBnUFrDOFKOrAsLZNJAOx05y4za-PoVzfIGpA=.80ed5ff3-d981-451e-90cc-ed65fa47f2b2@github.com>
Message-ID: <xBWx767QKgWj2lrBApcqdsF-6w0_tjGq_7xdOIHTVts=.580047e5-aa12-40da-924b-284523cde17b@github.com>

On Thu, 9 May 2024 10:11:22 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> ClassFile API `jdk.internal.classfile.verifier.VerifierImpl` performed only bytecode-level class verification.
>> This patch adds `jdk.internal.classfile.verifier.ParserVerifier` with additional class checks inspired by `hotspot/share/classfile/classFileParser.cpp`.
>> 
>> Also new `VerifierSelfTest::testParserVerifier` has been added.
>> 
>> Please review.
>> 
>> Thanks,
>> Adam
>
> Adam Sotona has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - fixed error thrown by VerifierImpl
>  - applied suggested changes

src/java.base/share/classes/jdk/internal/classfile/impl/verifier/ParserVerifier.java line 205:

> 203:     private void verifyAttribute(AttributedElement ae, Attribute<?> a, List<VerifyError> errors) {
> 204:         int payLoad = ((BoundAttribute)a).payloadLen();
> 205:         if (payLoad != switch (a) {

Please break this up - e.g. with an intermediate `foundPayload` variable - having a multi-line switch nested as an if condition looks very jarring!

src/java.base/share/classes/jdk/internal/classfile/impl/verifier/ParserVerifier.java line 246:

> 244:             }
> 245:             case DeprecatedAttribute da -> 0;
> 246:             case EnclosingMethodAttribute ema -> 4;

See 4.7.7:
> Otherwise, the value of the method_index item must be a valid index into the constant_pool table. The constant_pool entry at that index must be a CONSTANT_NameAndType_info structure ([?4.4.6](https://docs.oracle.com/javase/specs/jvms/se22/html/jvms-4.html#jvms-4.4.6)) representing the name and type of a method in the class referenced by the class_index attribute above.

src/java.base/share/classes/jdk/internal/classfile/impl/verifier/ParserVerifier.java line 247:

> 245:             case DeprecatedAttribute da -> 0;
> 246:             case EnclosingMethodAttribute ema -> 4;
> 247:             case ExceptionsAttribute ea -> 2 + 2 * ea.exceptions().size();

See 4.7.5:
> Each value in the exception_index_table array must be a valid index into the constant_pool table. The constant_pool entry at that index must be a CONSTANT_Class_info structure ([?4.4.1](https://docs.oracle.com/javase/specs/jvms/se22/html/jvms-4.html#jvms-4.4.1)) representing a class type that this method is declared to throw.

src/java.base/share/classes/jdk/internal/classfile/impl/verifier/ParserVerifier.java line 283:

> 281:                 yield l;
> 282:             }
> 283:             case RuntimeVisibleAnnotationsAttribute aa -> {

I wonder if these 4 cases can be consolidated a bit. They all require an annotation accessor, and then something that keeps computes the size of all the annotations. E.g.


int annotationSize(List<Annotation> annos) {
                long size = 0;
                for (var an : annos) {
                    size += annotationSize(an);
                }
                return l;
}

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16809#discussion_r1598800394
PR Review Comment: https://git.openjdk.org/jdk/pull/16809#discussion_r1598806362
PR Review Comment: https://git.openjdk.org/jdk/pull/16809#discussion_r1598807397
PR Review Comment: https://git.openjdk.org/jdk/pull/16809#discussion_r1598803054

From mcimadamore at openjdk.org  Mon May 13 17:27:10 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 13 May 2024 17:27:10 GMT
Subject: RFR: 8320396: Class-File API ClassModel::verify should include
 checks from hotspot/share/classfile/classFileParser.cpp [v5]
In-Reply-To: <xBWx767QKgWj2lrBApcqdsF-6w0_tjGq_7xdOIHTVts=.580047e5-aa12-40da-924b-284523cde17b@github.com>
References: <0a66asWcJ4_zBrjmReA18BZmsovN1ZeJRRSAPZDMZmo=.5bada03f-d88d-46cd-962d-c1e42c3048c1@github.com>
 <IXrF9AdBnUFrDOFKOrAsLZNJAOx05y4za-PoVzfIGpA=.80ed5ff3-d981-451e-90cc-ed65fa47f2b2@github.com>
 <xBWx767QKgWj2lrBApcqdsF-6w0_tjGq_7xdOIHTVts=.580047e5-aa12-40da-924b-284523cde17b@github.com>
Message-ID: <KJEykNYhsRlrN11gIVpaVsJY-8rOYmFGhjDiwggBljc=.88396297-16cd-4899-88e2-0ed99e0b3d3f@github.com>

On Mon, 13 May 2024 17:15:15 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Adam Sotona has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - fixed error thrown by VerifierImpl
>>  - applied suggested changes
>
> src/java.base/share/classes/jdk/internal/classfile/impl/verifier/ParserVerifier.java line 205:
> 
>> 203:     private void verifyAttribute(AttributedElement ae, Attribute<?> a, List<VerifyError> errors) {
>> 204:         int payLoad = ((BoundAttribute)a).payloadLen();
>> 205:         if (payLoad != switch (a) {
> 
> Please break this up - e.g. with an intermediate `foundPayload` variable - having a multi-line switch nested as an if condition looks very jarring!

Is this method only supposed to check the attribute size? It would be nice perhaps to enhance this to enforce more structural constraints - I added a couple of comments in that direction, but there's many more (e.g. for instance make sure that any entry that morally points to a class/method is of the right kind)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16809#discussion_r1598810642

From naoto.sato at oracle.com  Mon May 13 17:38:09 2024
From: naoto.sato at oracle.com (Naoto Sato)
Date: Mon, 13 May 2024 10:38:09 -0700
Subject: In support of Instant.minus(Instant)
In-Reply-To: <156760df-b775-48a9-a20d-cc900d9df6e4@oracle.com>
References: <CAB3z6AiAvi2q12dB761fYTx8a6qV9syu6HGUq=vkR-dcYZyv=Q@mail.gmail.com>
 <CACzrW9CgGc=qNhmhyTNKponBSP1g37t1tNFkpeGj7oqGtn7ihA@mail.gmail.com>
 <81a8ee1c-807e-4a0b-8320-ff892fca76c0@oracle.com>
 <CAB3z6Aj9cev+JvCSGFRpOW6UEKmNQJsACzR-BnBxZpZP+3YJvg@mail.gmail.com>
 <CACzrW9AWCDYJdM7Y0rxpf8EeOohKLVnxwpKOa_KGWaVoZK2nvQ@mail.gmail.com>
 <CAGB9EW8fST6o4q7yqZxGO7OTkU52LYGSheHz+G0+R2OyA40uTQ@mail.gmail.com>
 <CAChqX892D+f+xkoFJ4E=FcdZbeSaEuYzy5Z0JVP7U0Rohg+uOA@mail.gmail.com>
 <0ac5b3f0-a35f-41cc-bd48-a10035233226@oracle.com>
 <156760df-b775-48a9-a20d-cc900d9df6e4@oracle.com>
Message-ID: <ad789d5c-395d-4675-8815-791fd498fae4@oracle.com>

Hi,

With Stephen/Roger's comments, as well as Kevin's observation that 
until(end) has a good argument ordering that is easy to understand, I'd 
still propose `until()`. Please post if you have further comments.

Naoto

On 5/3/24 6:39 AM, Roger Riggs wrote:
> Hi,
> 
> I would also reinforce Stephen's early observation that the pattern for 
> "until" methods in java.time includes those of the XXXDate classes, with 
> a single Temporal parameter.? Period and Duration are similar values 
> holding relative TemporalAmounts.
> 
>  ? ? public Period until(ChronoLocalDate endDateExclusive)
> 
> In addition to Instant, the LocalTime class might also benefit from adding:
> 
>      public Duration until(LocalTime endExclusive)`
> 
> The API design of java.time included an emphasis on consistent naming 
> across the packages.
> 
> Regards, Roger
> 
> 
> On 5/2/24 4:01 PM, Naoto Sato wrote:
>> `Temporal` interface is clear that its `minus` methods return objects 
>> of the same `Temporal` type, and `until` calculates the amount of time 
>> until another `Temporal` type. Introducing `Instant.minus` that 
>> returns `Duration` would be confusing to me.
>>
>> Naoto
>>
>> On 5/2/24 10:41 AM, ?amonn McManus wrote:
>>> I'd say too that this makes intuitive sense based on algebra. If we 
>>> have:
>>> /instant1/?+ /duration/ = /instant2/
>>> then we can subtract /duration/?from both sides:
>>> /instant1 = instant2 - duration/
>>> or we can subtract /instant1/?from both sides:
>>> /duration = instant2 - instant1/
>>>
>>> There's no manipulation we can do that would cause us to try to add 
>>> instants together, and it's a bit surprising for the API to allow the 
>>> first subtraction but not the second.
>>> I also think that if I see instant2.minus(instant1) it's immediately 
>>> obvious to me what that means, while instant1.until(instant2) seems 
>>> both less discoverable and less obvious.
>>>
>>> On Thu, 2 May 2024 at 10:29, Louis Wasserman <lowasser at google.com 
>>> <mailto:lowasser at google.com>> wrote:
>>>
>>> ??? That doesn't?follow for me at all.
>>>
>>> ??? The structure formed by Instants and Durations is an affine space
>>> <https://en.wikipedia.org/wiki/Affine_space#Definition>, with
>>> ??? instants the points and durations the vectors.? (An affine space is
>>> ??? a vector space without a distinguished origin, which of course
>>> ??? Instants don't have.)? It is 100% standard to use the minus sign for
>>> ??? the operation "point - point = vector," even when "point?+ point" is
>>> ??? not defined, and to use all the other standard idioms for
>>> ??? subtraction; the Wikipedia article uses "subtraction" and
>>> ??? "difference" ubiquitously.
>>>
>>> ??? Personally, I'd be willing to live with a different name for the
>>> ??? operation, but consider?"users keep getting it wrong" a strong
>>> ??? enough argument all by itself for a version with the swapped
>>> ??? argument order; it's not obvious to me that another API with the
>>> ??? same argument order adds enough value over Duration.between to
>>> ??? bother with.
>>>
>>> ??? On Thu, May 2, 2024 at 10:04?AM Stephen Colebourne
>>> ??? <scolebourne at joda.org <mailto:scolebourne at joda.org>> wrote:
>>>
>>> ??????? On Thu, 2 May 2024 at 15:58, Kurt Alfred Kluever <kak at google.com
>>> <mailto:kak at google.com>> wrote:
>>> ???????? > instant ? instant = duration // what we're discussing
>>> ???????? > instant + duration = instant // satisfied by
>>> ??????? instant.plus(duration)
>>> ???????? > instant - duration = instant // satisfied by
>>> ??????? instant.minus(duration)
>>> ???????? > duration + duration = duration // satisfied by
>>> ??????? duration.plus(duration)
>>> ???????? > duration - duration = duration // satisfied by
>>> ??????? duration.minus(duration)
>>> ???????? > duration ? real number = duration // satisfied by
>>> ??????? duration.multipliedBy(long)
>>> ???????? > duration ? real number = duration // satisfied by
>>> ??????? duration.dividedBy(long)
>>> ???????? >
>>> ???????? > All but the first operation have very clear translations from
>>> ??????? conceptual model to code. I'm hoping we can achieve the same
>>> ??????? clarity for instant - instant by using the obvious name:
>>> ??????? instant.minus(instant)
>>>
>>> ??????? But you can't have
>>> ???????? ?instant + instant = ???
>>> ??????? It doesn't make sense.
>>>
>>> ??????? This is at the heart of why minus isn't right in this case.
>>> ??????? Stephen
>>>
>>>
>>>
>>> ??? -- ??? Louis Wasserman (he/they)
>>>
> 

From liach at openjdk.org  Mon May 13 17:38:08 2024
From: liach at openjdk.org (Chen Liang)
Date: Mon, 13 May 2024 17:38:08 GMT
Subject: RFR: 8320396: Class-File API ClassModel::verify should include
 checks from hotspot/share/classfile/classFileParser.cpp [v5]
In-Reply-To: <KJEykNYhsRlrN11gIVpaVsJY-8rOYmFGhjDiwggBljc=.88396297-16cd-4899-88e2-0ed99e0b3d3f@github.com>
References: <0a66asWcJ4_zBrjmReA18BZmsovN1ZeJRRSAPZDMZmo=.5bada03f-d88d-46cd-962d-c1e42c3048c1@github.com>
 <IXrF9AdBnUFrDOFKOrAsLZNJAOx05y4za-PoVzfIGpA=.80ed5ff3-d981-451e-90cc-ed65fa47f2b2@github.com>
 <xBWx767QKgWj2lrBApcqdsF-6w0_tjGq_7xdOIHTVts=.580047e5-aa12-40da-924b-284523cde17b@github.com>
 <KJEykNYhsRlrN11gIVpaVsJY-8rOYmFGhjDiwggBljc=.88396297-16cd-4899-88e2-0ed99e0b3d3f@github.com>
Message-ID: <DluFxuY08Xn3cCsQQbpU5Vf6nPNG_INI-YijaLoCWMo=.379392c4-c25f-423b-a2bf-bdbc49057bca@github.com>

On Mon, 13 May 2024 17:24:39 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/classfile/impl/verifier/ParserVerifier.java line 205:
>> 
>>> 203:     private void verifyAttribute(AttributedElement ae, Attribute<?> a, List<VerifyError> errors) {
>>> 204:         int payLoad = ((BoundAttribute)a).payloadLen();
>>> 205:         if (payLoad != switch (a) {
>> 
>> Please break this up - e.g. with an intermediate `foundPayload` variable - having a multi-line switch nested as an if condition looks very jarring!
>
> Is this method only supposed to check the attribute size? It would be nice perhaps to enhance this to enforce more structural constraints - I added a couple of comments in that direction, but there's many more (e.g. for instance make sure that any entry that morally points to a class/method is of the right kind)

Some of the checks don't verify the attributes point to valid cp entries; since CF API is lazy, those entries much be expanded by calling the accessors on Bound attributes.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16809#discussion_r1598822622

From liach at openjdk.org  Mon May 13 17:38:11 2024
From: liach at openjdk.org (Chen Liang)
Date: Mon, 13 May 2024 17:38:11 GMT
Subject: RFR: 8320396: Class-File API ClassModel::verify should include
 checks from hotspot/share/classfile/classFileParser.cpp [v5]
In-Reply-To: <IXrF9AdBnUFrDOFKOrAsLZNJAOx05y4za-PoVzfIGpA=.80ed5ff3-d981-451e-90cc-ed65fa47f2b2@github.com>
References: <0a66asWcJ4_zBrjmReA18BZmsovN1ZeJRRSAPZDMZmo=.5bada03f-d88d-46cd-962d-c1e42c3048c1@github.com>
 <IXrF9AdBnUFrDOFKOrAsLZNJAOx05y4za-PoVzfIGpA=.80ed5ff3-d981-451e-90cc-ed65fa47f2b2@github.com>
Message-ID: <ICUFXY8P2RSJ7wh2KtPB1J2ARulmYGcbGyo6OALX9w8=.6df6d413-5722-4f28-a2d8-1f165a34d485@github.com>

On Thu, 9 May 2024 10:11:22 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> ClassFile API `jdk.internal.classfile.verifier.VerifierImpl` performed only bytecode-level class verification.
>> This patch adds `jdk.internal.classfile.verifier.ParserVerifier` with additional class checks inspired by `hotspot/share/classfile/classFileParser.cpp`.
>> 
>> Also new `VerifierSelfTest::testParserVerifier` has been added.
>> 
>> Please review.
>> 
>> Thanks,
>> Adam
>
> Adam Sotona has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - fixed error thrown by VerifierImpl
>  - applied suggested changes

src/java.base/share/classes/jdk/internal/classfile/impl/verifier/ParserVerifier.java line 233:

> 231:                 ClassDesc type = ((FieldModel)ae).fieldTypeSymbol();
> 232:                 ConstantValueEntry cve = cva.constant();
> 233:                 if (!switch (TypeKind.from(type)) {

Weird-looking switch

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16809#discussion_r1598817747

From duke at openjdk.org  Mon May 13 17:44:52 2024
From: duke at openjdk.org (Nizar Benalla)
Date: Mon, 13 May 2024 17:44:52 GMT
Subject: RFR: 8330954: Fix remaining `@since` tags in `java.base` [v3]
In-Reply-To: <fBxLBbMa9El6L2aATjtKyrAjlFRIjh1J7vPx2CbNT5E=.b33e4450-c1dc-4f36-b59b-5d9acb2da2dc@github.com>
References: <fBxLBbMa9El6L2aATjtKyrAjlFRIjh1J7vPx2CbNT5E=.b33e4450-c1dc-4f36-b59b-5d9acb2da2dc@github.com>
Message-ID: <OIT0BUzBvGNWdLWbuAx_ma85p1KEZ21Xr0A84mO0lvo=.55c05f1e-f925-4f30-89dc-fb052c70eb7f@github.com>

> Please review this PR that aims to add all the remaining needed `@since` tags in `java.base`, and group them into a single fix.
> This is related to #18934 and my work around the `@since` checker feature.
> Explicit `@since` tags are needed for some overriding methods for the purpose of the checker.
> 
> I will only give the example with the `CompletableFuture` class but here is the before where the methods only appeared in "Methods declared in interface N"
> 
> <img width="1510" alt="Screenshot 2024-05-06 at 00 06 57" src="https://github.com/openjdk/jdk/assets/96922791/1749a355-133b-4a38-bffe-51ac415b2aac">
> 
> 
> 
> and after where the method has it's own javadoc, the main description is added and the `@since` tags are added as intended.
> 
> I don't have an account on `https://cr.openjdk.org/` but I could host the generated docs somewhere if that is needed.
> 
> <img width="1511" alt="Screenshot 2024-05-06 at 00 07 16" src="https://github.com/openjdk/jdk/assets/96922791/89b92288-9b5e-48ed-8fa1-9342ea43e043">
> 
> <img width="1505" alt="Screenshot 2024-05-06 at 00 08 06" src="https://github.com/openjdk/jdk/assets/96922791/9aef08ff-5030-4189-a996-582a7eef849b">
> 
> <img width="1050" alt="Screenshot 2024-05-06 at 00 09 03" src="https://github.com/openjdk/jdk/assets/96922791/fdd75a26-0396-4c5e-8f59-a3717b7d7ec8">
> 
> 
> TIA

Nizar Benalla has updated the pull request incrementally with two additional commits since the last revision:

 - (C)
 - (C)

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/18954/files
  - new: https://git.openjdk.org/jdk/pull/18954/files/d38a1c7d..be91ab80

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18954&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18954&range=01-02

  Stats: 7 lines in 7 files changed: 0 ins; 0 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/18954.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18954/head:pull/18954

PR: https://git.openjdk.org/jdk/pull/18954

From liach at openjdk.org  Mon May 13 17:55:09 2024
From: liach at openjdk.org (Chen Liang)
Date: Mon, 13 May 2024 17:55:09 GMT
Subject: RFR: 8330954: Fix remaining `@since` tags in `java.base` [v3]
In-Reply-To: <OIT0BUzBvGNWdLWbuAx_ma85p1KEZ21Xr0A84mO0lvo=.55c05f1e-f925-4f30-89dc-fb052c70eb7f@github.com>
References: <fBxLBbMa9El6L2aATjtKyrAjlFRIjh1J7vPx2CbNT5E=.b33e4450-c1dc-4f36-b59b-5d9acb2da2dc@github.com>
 <OIT0BUzBvGNWdLWbuAx_ma85p1KEZ21Xr0A84mO0lvo=.55c05f1e-f925-4f30-89dc-fb052c70eb7f@github.com>
Message-ID: <CYge-WR-X3aCzaE8WFIO53a7pkTsTqWRxFA-whPUWTg=.a91ae2b0-08ea-40bb-b5f9-330735c71e9c@github.com>

On Mon, 13 May 2024 17:44:52 GMT, Nizar Benalla <duke at openjdk.org> wrote:

>> Please review this PR that aims to add all the remaining needed `@since` tags in `java.base`, and group them into a single fix.
>> This is related to #18934 and my work around the `@since` checker feature.
>> Explicit `@since` tags are needed for some overriding methods for the purpose of the checker.
>> 
>> I will only give the example with the `CompletableFuture` class but here is the before where the methods only appeared in "Methods declared in interface N"
>> 
>> <img width="1510" alt="Screenshot 2024-05-06 at 00 06 57" src="https://github.com/openjdk/jdk/assets/96922791/1749a355-133b-4a38-bffe-51ac415b2aac">
>> 
>> 
>> 
>> and after where the method has it's own javadoc, the main description is added and the `@since` tags are added as intended.
>> 
>> I don't have an account on `https://cr.openjdk.org/` but I could host the generated docs somewhere if that is needed.
>> 
>> <img width="1511" alt="Screenshot 2024-05-06 at 00 07 16" src="https://github.com/openjdk/jdk/assets/96922791/89b92288-9b5e-48ed-8fa1-9342ea43e043">
>> 
>> <img width="1505" alt="Screenshot 2024-05-06 at 00 08 06" src="https://github.com/openjdk/jdk/assets/96922791/9aef08ff-5030-4189-a996-582a7eef849b">
>> 
>> <img width="1050" alt="Screenshot 2024-05-06 at 00 09 03" src="https://github.com/openjdk/jdk/assets/96922791/fdd75a26-0396-4c5e-8f59-a3717b7d7ec8">
>> 
>> 
>> TIA
>
> Nizar Benalla has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - (C)
>  - (C)

src/java.base/share/classes/java/security/interfaces/RSAPrivateKey.java line 2:

> 1: /*
> 2:  * Copyright (c) 1998, 2023, Oracle and/or its affiliates. All rights reserved.

This diff is redundant but no-op. You should merge openjdk/jdk's master branch to your PR branch, so the diff displayed by GitHub is up-to-date and this will go away.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18954#discussion_r1598841666

From duke at openjdk.org  Mon May 13 18:00:20 2024
From: duke at openjdk.org (Nizar Benalla)
Date: Mon, 13 May 2024 18:00:20 GMT
Subject: RFR: 8330954: Fix remaining `@since` tags in `java.base` [v3]
In-Reply-To: <CYge-WR-X3aCzaE8WFIO53a7pkTsTqWRxFA-whPUWTg=.a91ae2b0-08ea-40bb-b5f9-330735c71e9c@github.com>
References: <fBxLBbMa9El6L2aATjtKyrAjlFRIjh1J7vPx2CbNT5E=.b33e4450-c1dc-4f36-b59b-5d9acb2da2dc@github.com>
 <OIT0BUzBvGNWdLWbuAx_ma85p1KEZ21Xr0A84mO0lvo=.55c05f1e-f925-4f30-89dc-fb052c70eb7f@github.com>
 <CYge-WR-X3aCzaE8WFIO53a7pkTsTqWRxFA-whPUWTg=.a91ae2b0-08ea-40bb-b5f9-330735c71e9c@github.com>
Message-ID: <9M6lzztq-HQ-VALM_ToaZdNHoIybFtGM8UNWSnX1Wuc=.b6b6458b-d940-40c5-a5e5-d9ad702fb8ec@github.com>

On Mon, 13 May 2024 17:52:23 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Nizar Benalla has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - (C)
>>  - (C)
>
> src/java.base/share/classes/java/security/interfaces/RSAPrivateKey.java line 2:
> 
>> 1: /*
>> 2:  * Copyright (c) 1998, 2023, Oracle and/or its affiliates. All rights reserved.
> 
> This diff is redundant but no-op. You should merge openjdk/jdk's master branch to your PR branch, so the diff displayed by GitHub is up-to-date and this will go away.

I don't want to merge or rebase on an active PR. It should get fixed once this is integrated.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18954#discussion_r1598847527

From liach at openjdk.org  Mon May 13 18:03:16 2024
From: liach at openjdk.org (Chen Liang)
Date: Mon, 13 May 2024 18:03:16 GMT
Subject: RFR: 8330954: Fix remaining `@since` tags in `java.base` [v3]
In-Reply-To: <9M6lzztq-HQ-VALM_ToaZdNHoIybFtGM8UNWSnX1Wuc=.b6b6458b-d940-40c5-a5e5-d9ad702fb8ec@github.com>
References: <fBxLBbMa9El6L2aATjtKyrAjlFRIjh1J7vPx2CbNT5E=.b33e4450-c1dc-4f36-b59b-5d9acb2da2dc@github.com>
 <OIT0BUzBvGNWdLWbuAx_ma85p1KEZ21Xr0A84mO0lvo=.55c05f1e-f925-4f30-89dc-fb052c70eb7f@github.com>
 <CYge-WR-X3aCzaE8WFIO53a7pkTsTqWRxFA-whPUWTg=.a91ae2b0-08ea-40bb-b5f9-330735c71e9c@github.com>
 <9M6lzztq-HQ-VALM_ToaZdNHoIybFtGM8UNWSnX1Wuc=.b6b6458b-d940-40c5-a5e5-d9ad702fb8ec@github.com>
Message-ID: <594HmITo49i3riKFS8pzenNrA9tJcONpFnQKD52jF9k=.ae495a73-4cce-4f1a-a065-a45d6aa25b54@github.com>

On Mon, 13 May 2024 17:57:42 GMT, Nizar Benalla <duke at openjdk.org> wrote:

>> src/java.base/share/classes/java/security/interfaces/RSAPrivateKey.java line 2:
>> 
>>> 1: /*
>>> 2:  * Copyright (c) 1998, 2023, Oracle and/or its affiliates. All rights reserved.
>> 
>> This diff is redundant but no-op. You should merge openjdk/jdk's master branch to your PR branch, so the diff displayed by GitHub is up-to-date and this will go away.
>
> I don't want to merge or rebase on an active PR. It should get fixed once this is integrated.

Sure, this comment serves as a note to reviewers that these 2 header changes have been committed in other changes and thus can be safely ignored.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18954#discussion_r1598850816

From szaldana at openjdk.org  Mon May 13 18:04:18 2024
From: szaldana at openjdk.org (Sonia Zaldana Calles)
Date: Mon, 13 May 2024 18:04:18 GMT
Subject: RFR: 8329581: Java launcher no longer prints a stack trace [v10]
In-Reply-To: <nuC0ykeUPUGGaWUitqcQdw_N7ueOLFnFzm2JdtXSqbo=.6d3cdcd9-8ae1-406c-8a72-1dc25e1ed869@github.com>
References: <Z0pDMIc_XvZhcZdeFsIQUlqI17q5ybj0BnQ9Kl3jwxg=.8f981c46-a8a3-4520-a6e3-79ee7fce0253@github.com>
 <nFQS3JDegumTJOWSla6qGad04vc7PP7W3ZZ483XQuqs=.d28be017-00a0-44e0-9eee-bd70d56498e8@github.com>
 <nuC0ykeUPUGGaWUitqcQdw_N7ueOLFnFzm2JdtXSqbo=.6d3cdcd9-8ae1-406c-8a72-1dc25e1ed869@github.com>
Message-ID: <p1F-ic25cDHHveR547PzgWXLMlWBxtIzENjJfdi1b5M=.c2bd587f-c2f4-4375-9de7-e0bbebda6f9f@github.com>

On Sun, 12 May 2024 18:52:30 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> This mostly looks good. I'm just puzzled CHECK_EXCEPTION_NULL_FAIL. The JNI functions GetStaticMethodID, GetMethodID and NewObject return NULL with a pending exception when they fail. So I would expect CHECK_EXCEPTION_NULL_FAIL to just check if obj is NULL rather check for an exception first. It's not wrong to check for an exception, just curious when looking at this macro.

Hi @AlanBateman, thanks for taking a look. That's a good point - would it be worthwhile to delete the exception check in this case?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18786#issuecomment-2108464274

From joehw at openjdk.org  Mon May 13 18:12:15 2024
From: joehw at openjdk.org (Joe Wang)
Date: Mon, 13 May 2024 18:12:15 GMT
Subject: RFR: 8332084: Ensure JdkConsoleImpl.restoreEcho visibility in a
 shutdown hook [v3]
In-Reply-To: <lLPvzpLD8otrOuchognaYtSQQu75txoPpHGlZVJ7qhY=.6c8f9c14-e22a-496e-a55a-f40676b95a9a@github.com>
References: <9JTWc3FRpfbILlSHlmIU_dL5IE69RTxnSIAOdIte15I=.5854a48f-21d7-42c9-adb7-5e3ed40d1211@github.com>
 <lLPvzpLD8otrOuchognaYtSQQu75txoPpHGlZVJ7qhY=.6c8f9c14-e22a-496e-a55a-f40676b95a9a@github.com>
Message-ID: <buntPOCERuYlHURGtYJSusKYDgUBJnVz_RtUn8_oHkU=.94dbdd9d-8100-4e7a-8263-dff31c2df2d2@github.com>

On Mon, 13 May 2024 17:06:32 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Making sure `restoreEcho` correctly reflects the state in the shutdown thread, which differs from the application's thread that issues the `readPassword()` method.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Replaced another unused exception with _

Marked as reviewed by joehw (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/19184#pullrequestreview-2053385714

From dl at openjdk.org  Mon May 13 18:19:20 2024
From: dl at openjdk.org (Doug Lea)
Date: Mon, 13 May 2024 18:19:20 GMT
Subject: RFR: 8331987: Enhance stacktrace clarity for CompletableFuture
 CancellationException
In-Reply-To: <680cm1Ox8RH-vgI7V6RzTDV6zDfC3_mamIv3WHfLkIc=.c90f13f8-66ab-4b27-a03b-0f9278dfa535@github.com>
References: <JI-ghId-imtBqmNm850oQMNp-9p79tGMjfTRDdXz6D0=.fc134f86-914c-4484-9236-af162de3b99e@github.com>
 <680cm1Ox8RH-vgI7V6RzTDV6zDfC3_mamIv3WHfLkIc=.c90f13f8-66ab-4b27-a03b-0f9278dfa535@github.com>
Message-ID: <wma6KHEBFVLOwlnzxguE5L8BvROGAA1TWuj0MYCxrkg=.7faf0176-565a-4555-8571-bd43b8f9cc58@github.com>

On Mon, 13 May 2024 17:06:10 GMT, Viktor Klang <vklang at openjdk.org> wrote:

>> This change adds wrapping of the CancellationException produced by CompletableFuture::get() and CompletableFuture::join() to add more diagnostic information and align better with FutureTask.
>> 
>> Running the sample code from the JBS issue in JShell will produce the following:
>> 
>> 
>> jshell> java.util.concurrent.CancellationException: 
>> 	at java.base/java.util.concurrent.CompletableFuture.reportGet(CompletableFuture.java:392)
>> 	at java.base/java.util.concurrent.CompletableFuture.get(CompletableFuture.java:2073)
>> 	at REPL.$JShell$18.m2($JShell$18.java:10)
>> 	at REPL.$JShell$17.m1($JShell$17.java:8)
>> 	at REPL.$JShell$16B.lambda$main$0($JShell$16B.java:8)
>> 	at java.base/java.lang.Thread.run(Thread.java:1575)
>> Caused by: java.util.concurrent.CancellationException
>> 	at java.base/java.util.concurrent.CompletableFuture.cancel(CompletableFuture.java:2510)
>> 	at REPL.$JShell$16B.lambda$main$1($JShell$16B.java:11)
>> 	... 1 more
>
> src/java.base/share/classes/java/util/concurrent/CompletableFuture.java line 392:
> 
>> 390:                 return null;
>> 391:             if (x instanceof CancellationException)
>> 392:                 throw new CancellationException("", (CancellationException)x);
> 
> One option here would be to put "CompletableFuture.get()" or "get()" as a message.

Given the serviceability motivation, the overkill of adding "get" and "join" strings seems reasonable.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19219#discussion_r1598868469

From kcr at openjdk.org  Mon May 13 18:47:15 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 13 May 2024 18:47:15 GMT
Subject: RFR: 8330954: Fix remaining `@since` tags in `java.base` [v3]
In-Reply-To: <594HmITo49i3riKFS8pzenNrA9tJcONpFnQKD52jF9k=.ae495a73-4cce-4f1a-a065-a45d6aa25b54@github.com>
References: <fBxLBbMa9El6L2aATjtKyrAjlFRIjh1J7vPx2CbNT5E=.b33e4450-c1dc-4f36-b59b-5d9acb2da2dc@github.com>
 <OIT0BUzBvGNWdLWbuAx_ma85p1KEZ21Xr0A84mO0lvo=.55c05f1e-f925-4f30-89dc-fb052c70eb7f@github.com>
 <CYge-WR-X3aCzaE8WFIO53a7pkTsTqWRxFA-whPUWTg=.a91ae2b0-08ea-40bb-b5f9-330735c71e9c@github.com>
 <9M6lzztq-HQ-VALM_ToaZdNHoIybFtGM8UNWSnX1Wuc=.b6b6458b-d940-40c5-a5e5-d9ad702fb8ec@github.com>
 <594HmITo49i3riKFS8pzenNrA9tJcONpFnQKD52jF9k=.ae495a73-4cce-4f1a-a065-a45d6aa25b54@github.com>
Message-ID: <rqq5VQfQJyWFCr1hXCudMk37Fz9QH2A4d0HCtCVPR84=.a11b7244-6618-4dd2-a536-b888062ac7b7@github.com>

On Mon, 13 May 2024 18:00:27 GMT, Chen Liang <liach at openjdk.org> wrote:

>> I don't want to merge or rebase on an active PR. It should get fixed once this is integrated.
>
> Sure, this comment serves as a note to reviewers that these 2 header changes have been committed in other changes and thus can be safely ignored.

There is no harm in merging the upstream master, using `git merge`, to bring your branch more up-to-date. And it can be helpful in cases like this where it might help reviewers avoid extraneous information. It is also recommended in other cases (e.g., a long-running PR where there is a lot of drift between the PR source branch and the upstream target branch).

Skara will squash all commits anyway when integrating so the results will be identical.

Btw, one thing you should _not_ do is rebase a source branch of an active PR.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18954#discussion_r1598896706

From brent.christian at oracle.com  Mon May 13 19:16:18 2024
From: brent.christian at oracle.com (Brent Christian)
Date: Mon, 13 May 2024 12:16:18 -0700
Subject: RFR: 8314480: Memory ordering spec updates in java.lang.ref [v31]
In-Reply-To: <CAMOCf+ikSQcqWjibB-==73qNZ_y_a8CZ7HWhifjqbN8ENOEu6w@mail.gmail.com>
References: <R74ontYwjYg6HeZY0cWrlo0amjl4E1YsFWeuh4pda14=.08ac62df-b2f8-4b4d-b338-07adb289601b@github.com>
 <aUZHna4VBbB2ClvbJsoTwojkQfCE8-l2z9BDQaXHAIs=.8197a754-5559-4653-820f-ad9d92f72316@github.com>
 <CAMOCf+ikSQcqWjibB-==73qNZ_y_a8CZ7HWhifjqbN8ENOEu6w@mail.gmail.com>
Message-ID: <47f03522-3545-4413-b52f-f0dd59a1a177@oracle.com>

On 5/10/24 10:54 AM, Hans Boehm wrote:
> I'm not convinced this helps.
> 
> The isAlive() spec says:
> 
> "A thread is alive if it has been started and has not yet terminated."
> 
> Clearly an object is reachable if it can be accessed by a thread that will be started in the 
> future. Is that part of a "potential continuing computation from any live thread"?

I would think; one "computation" a live thread can perform is to start another thread, which in
turn might access the object.

> I think the JLS wording is a bit sloppy about what "live thread" means here. And that sloppiness 
> is probably better than pointing at a precise definition that I'm not sure really applies.
> 
> "in any potential continuing computation from any live thread" really seems to mean something 
> like "in any continuing computation in which no finalizers are run"?

Once an object becomes finalizer-reachable, it can only be reached via a running finalizer. (JLS
12.6.1: "A finalizer-reachable object can be reached from some finalizable object through some chain
of references, but not from any live thread.")

So maybe finalizer threads should not be considered "live" threads.

> Even if the object is later accessed from an existing "live" thread, it should not be considered
>  reachable if that happens only after a finalizer later makes it reachable again.

Agreed - if an object can (*and only can*) be accessed again after a finalizer resurrects it, that
doesn't count as "reachable". In fact, at that point, the object must have transitioned from 
reachable to finalizer-reachable.

If an object gets resurrected by a finalizer, it does become reachable again and can again be 
accessed by the program. (And of course if the object's own finalizer ran, it won't run again if the 
object again stops being reachable.)

> So I don't see why the thread from which the access happens matters at all.

I think it would only matter for accesses from a finalizer thread.

-Brent

From dnsimon at openjdk.org  Mon May 13 19:40:22 2024
From: dnsimon at openjdk.org (Doug Simon)
Date: Mon, 13 May 2024 19:40:22 GMT
Subject: RFR: 8330755: ProblemList files have entries referring to
 non-existent tests [v2]
In-Reply-To: <vI3xkUAHKmVbuRrCBuSbUuJYlCHfKH-f9hPY1E0dhmc=.c9ac9fea-bea5-4bd1-ac98-020a0893bf25@github.com>
References: <5vZvc83Zn4IhI5s_IdYqRqw4zjWF93TcQUzl2cD5JLU=.12464c13-9ccc-47d8-851e-883f3fea4a04@github.com>
 <vI3xkUAHKmVbuRrCBuSbUuJYlCHfKH-f9hPY1E0dhmc=.c9ac9fea-bea5-4bd1-ac98-020a0893bf25@github.com>
Message-ID: <asWf4t9ujp4rWOOpuvz9Jv1KERG98UDKUR7EWlF8X3Q=.ad099d30-b1ca-43ca-b1ae-b34764f51424@github.com>

On Wed, 24 Apr 2024 10:50:44 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

>> This PR adds a check for the format of ProblemList files and ensures they only have entries referring to existing tests.
>> 
>> The cleanups in the second commit of this PR were done based on the output of `CheckProblemLists`:
>> 
>>> make test TEST=build/problemLists/CheckProblemLists.java
>> ...
>> STDOUT:
>> Checking /Users/dnsimon/dev/jdk-jdk/open/test/hotspot/jtreg/ProblemList-Virtual.txt
>> Checking /Users/dnsimon/dev/jdk-jdk/open/test/hotspot/jtreg/ProblemList-Xcomp.txt
>> Checking /Users/dnsimon/dev/jdk-jdk/open/test/hotspot/jtreg/ProblemList-generational-zgc.txt
>> Checking /Users/dnsimon/dev/jdk-jdk/open/test/hotspot/jtreg/ProblemList-zgc.txt
>> Checking /Users/dnsimon/dev/jdk-jdk/open/test/hotspot/jtreg/ProblemList.txt
>> Checking /Users/dnsimon/dev/jdk-jdk/open/test/jaxp/ProblemList.txt
>> Checking /Users/dnsimon/dev/jdk-jdk/open/test/jdk/ProblemList-Virtual.txt
>> Checking /Users/dnsimon/dev/jdk-jdk/open/test/jdk/ProblemList-Xcomp.txt
>> Checking /Users/dnsimon/dev/jdk-jdk/open/test/jdk/ProblemList-generational-zgc.txt
>> Checking /Users/dnsimon/dev/jdk-jdk/open/test/jdk/ProblemList-zgc.txt
>> Checking /Users/dnsimon/dev/jdk-jdk/open/test/jdk/ProblemList.txt
>> Checking /Users/dnsimon/dev/jdk-jdk/open/test/langtools/ProblemList.txt
>> Checking /Users/dnsimon/dev/jdk-jdk/open/test/lib-test/ProblemList.txt
>> Checked 13 problem list files
>> Test roots:
>>   /Users/dnsimon/dev/jdk-jdk/open/test/jdk
>>   /Users/dnsimon/dev/jdk-jdk/open/test/lib-test
>>   /Users/dnsimon/dev/jdk-jdk/open/test/failure_handler/test
>>   /Users/dnsimon/dev/jdk-jdk/open/test/jaxp
>>   /Users/dnsimon/dev/jdk-jdk/open/test/langtools
>>   /Users/dnsimon/dev/jdk-jdk/open/test/hotspot/jtreg
>> Following errors found:
>> /Users/dnsimon/dev/jdk-jdk/open/test/hotspot/jtreg/ProblemList.txt:174: vmTestbase/gc/lock/jni/jnilock002/TestDescription.java does not exist under any test root
>> vmTestbase/gc/lock/jni/jnilock002/TestDescription.java 8192647 generic-all
>> 
>> /Users/dnsimon/dev/jdk-jdk/open/test/jdk/ProblemList-Virtual.txt:77: TestAndIssue[test=java/util/Properties/StoreReproducibilityTest.java, issueId=0000000] duplicates /Users/dnsimon/dev/jdk-jdk/open/test/jdk/ProblemList-Virtual.txt:76
>> java/util/Properties/StoreReproducibilityTest.java 0000000 generic-all
>> 
>> /Users/dnsimon/dev/jdk-jdk/open/test/jdk/ProblemList.txt:516: java/lang/management/MemoryMXBean/PendingAllGC.sh does not exist under any test root
>> java/lang/management/MemoryMXBean/PendingAllGC.sh               8158837 generic-all
>> 
>> ...
>
> Doug Simon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   removed CheckProblemLists.java

The issue was resolved when I merged the PR to clean up the closed problem lists.

I'll just close this PR and leave it as documentation for future open ProblemList cleanup if someone wants to take it on.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18879#issuecomment-2108657466

From dnsimon at openjdk.org  Mon May 13 19:40:22 2024
From: dnsimon at openjdk.org (Doug Simon)
Date: Mon, 13 May 2024 19:40:22 GMT
Subject: Withdrawn: 8330755: ProblemList files have entries referring to
 non-existent tests
In-Reply-To: <5vZvc83Zn4IhI5s_IdYqRqw4zjWF93TcQUzl2cD5JLU=.12464c13-9ccc-47d8-851e-883f3fea4a04@github.com>
References: <5vZvc83Zn4IhI5s_IdYqRqw4zjWF93TcQUzl2cD5JLU=.12464c13-9ccc-47d8-851e-883f3fea4a04@github.com>
Message-ID: <RYQBXFof6sTn7MBHDZVlqMaenp0qf3EsXglTD8qGJ6k=.e4eb775c-32da-411a-88d4-598264ed7227@github.com>

On Sun, 21 Apr 2024 22:00:52 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

> This PR adds a check for the format of ProblemList files and ensures they only have entries referring to existing tests.
> 
> The cleanups in the second commit of this PR were done based on the output of `CheckProblemLists`:
> 
>> make test TEST=build/problemLists/CheckProblemLists.java
> ...
> STDOUT:
> Checking /Users/dnsimon/dev/jdk-jdk/open/test/hotspot/jtreg/ProblemList-Virtual.txt
> Checking /Users/dnsimon/dev/jdk-jdk/open/test/hotspot/jtreg/ProblemList-Xcomp.txt
> Checking /Users/dnsimon/dev/jdk-jdk/open/test/hotspot/jtreg/ProblemList-generational-zgc.txt
> Checking /Users/dnsimon/dev/jdk-jdk/open/test/hotspot/jtreg/ProblemList-zgc.txt
> Checking /Users/dnsimon/dev/jdk-jdk/open/test/hotspot/jtreg/ProblemList.txt
> Checking /Users/dnsimon/dev/jdk-jdk/open/test/jaxp/ProblemList.txt
> Checking /Users/dnsimon/dev/jdk-jdk/open/test/jdk/ProblemList-Virtual.txt
> Checking /Users/dnsimon/dev/jdk-jdk/open/test/jdk/ProblemList-Xcomp.txt
> Checking /Users/dnsimon/dev/jdk-jdk/open/test/jdk/ProblemList-generational-zgc.txt
> Checking /Users/dnsimon/dev/jdk-jdk/open/test/jdk/ProblemList-zgc.txt
> Checking /Users/dnsimon/dev/jdk-jdk/open/test/jdk/ProblemList.txt
> Checking /Users/dnsimon/dev/jdk-jdk/open/test/langtools/ProblemList.txt
> Checking /Users/dnsimon/dev/jdk-jdk/open/test/lib-test/ProblemList.txt
> Checked 13 problem list files
> Test roots:
>   /Users/dnsimon/dev/jdk-jdk/open/test/jdk
>   /Users/dnsimon/dev/jdk-jdk/open/test/lib-test
>   /Users/dnsimon/dev/jdk-jdk/open/test/failure_handler/test
>   /Users/dnsimon/dev/jdk-jdk/open/test/jaxp
>   /Users/dnsimon/dev/jdk-jdk/open/test/langtools
>   /Users/dnsimon/dev/jdk-jdk/open/test/hotspot/jtreg
> Following errors found:
> /Users/dnsimon/dev/jdk-jdk/open/test/hotspot/jtreg/ProblemList.txt:174: vmTestbase/gc/lock/jni/jnilock002/TestDescription.java does not exist under any test root
> vmTestbase/gc/lock/jni/jnilock002/TestDescription.java 8192647 generic-all
> 
> /Users/dnsimon/dev/jdk-jdk/open/test/jdk/ProblemList-Virtual.txt:77: TestAndIssue[test=java/util/Properties/StoreReproducibilityTest.java, issueId=0000000] duplicates /Users/dnsimon/dev/jdk-jdk/open/test/jdk/ProblemList-Virtual.txt:76
> java/util/Properties/StoreReproducibilityTest.java 0000000 generic-all
> 
> /Users/dnsimon/dev/jdk-jdk/open/test/jdk/ProblemList.txt:516: java/lang/management/MemoryMXBean/PendingAllGC.sh does not exist under any test root
> java/lang/management/MemoryMXBean/PendingAllGC.sh               8158837 generic-all
> 
> /Users/dnsimon/dev/jdk-jdk/open/test/jdk/ProblemList.txt:667: javax/swing/JFi...

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/18879

From hboehm at google.com  Mon May 13 20:14:18 2024
From: hboehm at google.com (Hans Boehm)
Date: Mon, 13 May 2024 13:14:18 -0700
Subject: RFR: 8314480: Memory ordering spec updates in java.lang.ref [v31]
In-Reply-To: <47f03522-3545-4413-b52f-f0dd59a1a177@oracle.com>
References: <R74ontYwjYg6HeZY0cWrlo0amjl4E1YsFWeuh4pda14=.08ac62df-b2f8-4b4d-b338-07adb289601b@github.com>
 <aUZHna4VBbB2ClvbJsoTwojkQfCE8-l2z9BDQaXHAIs=.8197a754-5559-4653-820f-ad9d92f72316@github.com>
 <CAMOCf+ikSQcqWjibB-==73qNZ_y_a8CZ7HWhifjqbN8ENOEu6w@mail.gmail.com>
 <47f03522-3545-4413-b52f-f0dd59a1a177@oracle.com>
Message-ID: <CAMOCf+gMYh0=sokfvdG+QK-O845FwLXcFMrsPdu8HStaZUO4DQ@mail.gmail.com>

On Mon, May 13, 2024 at 12:16?PM Brent Christian <brent.christian at oracle.com>
wrote:

> On 5/10/24 10:54 AM, Hans Boehm wrote:
> > I'm not convinced this helps.
> >
> > The isAlive() spec says:
> >
> > "A thread is alive if it has been started and has not yet terminated."
> >
> > Clearly an object is reachable if it can be accessed by a thread that
> will be started in the
> > future. Is that part of a "potential continuing computation from any
> live thread"?
>
> I would think; one "computation" a live thread can perform is to start
> another thread, which in
> turn might access the object.
>
> > I think the JLS wording is a bit sloppy about what "live thread" means
> here. And that sloppiness
> > is probably better than pointing at a precise definition that I'm not
> sure really applies.
> >
> > "in any potential continuing computation from any live thread" really
> seems to mean something
> > like "in any continuing computation in which no finalizers are run"?
>
> Once an object becomes finalizer-reachable, it can only be reached via a
> running finalizer. (JLS
> 12.6.1: "A finalizer-reachable object can be reached from some finalizable
> object through some chain
> of references, but not from any live thread.")
>
> So maybe finalizer threads should not be considered "live" threads.
>
> > Even if the object is later accessed from an existing "live" thread, it
> should not be considered
> >  reachable if that happens only after a finalizer later makes it
> reachable again.
>
> Agreed - if an object can (*and only can*) be accessed again after a
> finalizer resurrects it, that
> doesn't count as "reachable". In fact, at that point, the object must have
> transitioned from
> reachable to finalizer-reachable.
>
> If an object gets resurrected by a finalizer, it does become reachable
> again and can again be
> accessed by the program. (And of course if the object's own finalizer ran,
> it won't run again if the
> object again stops being reachable.)
>
> > So I don't see why the thread from which the access happens matters at
> all.
>
> I think it would only matter for accesses from a finalizer thread.
>
I'm arguing that even that doesn't matter.  Let's say B is reachable from
A, and A has a finalizer. Whether B is accessed directly by the finalizer
from the finalizer thread, or the finalizer invokes some parallel algorithm
on A, so that B is accessed by a helper "live thread" shouldn't matter.
What does matter is that neither A nor B are reachable before the finalizer
runs, because they can only be accessed as the result of a finalizer
running.

I now wonder whether "A <em>reachable</em> object is any object that can be
accessed in any potential continuing computation before any additional
finalizers are started." wouldn't actually be a much better way to state
this. (Officially, this wording is presumably nearly obsolete, since I
don't think Cleaners or References have this particular issue. OTOH, that
would also make it much clearer that this is so, and post finalizers, there
is no issue here.)

Hans

>
> -Brent
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240513/874c0d98/attachment.htm>

From duke at openjdk.org  Mon May 13 20:14:38 2024
From: duke at openjdk.org (Nizar Benalla)
Date: Mon, 13 May 2024 20:14:38 GMT
Subject: RFR: 8330954: Fix remaining `@since` tags in `java.base` [v4]
In-Reply-To: <fBxLBbMa9El6L2aATjtKyrAjlFRIjh1J7vPx2CbNT5E=.b33e4450-c1dc-4f36-b59b-5d9acb2da2dc@github.com>
References: <fBxLBbMa9El6L2aATjtKyrAjlFRIjh1J7vPx2CbNT5E=.b33e4450-c1dc-4f36-b59b-5d9acb2da2dc@github.com>
Message-ID: <vYbBnYVwb_7RfofV18_HtMmqPQGIwYYHJiTc0Q5u254=.b06b61ae-9130-4bae-b4b7-d1233c746858@github.com>

> Please review this PR that aims to add all the remaining needed `@since` tags in `java.base`, and group them into a single fix.
> This is related to #18934 and my work around the `@since` checker feature.
> Explicit `@since` tags are needed for some overriding methods for the purpose of the checker.
> 
> I will only give the example with the `CompletableFuture` class but here is the before where the methods only appeared in "Methods declared in interface N"
> 
> <img width="1510" alt="Screenshot 2024-05-06 at 00 06 57" src="https://github.com/openjdk/jdk/assets/96922791/1749a355-133b-4a38-bffe-51ac415b2aac">
> 
> 
> 
> and after where the method has it's own javadoc, the main description is added and the `@since` tags are added as intended.
> 
> I don't have an account on `https://cr.openjdk.org/` but I could host the generated docs somewhere if that is needed.
> 
> <img width="1511" alt="Screenshot 2024-05-06 at 00 07 16" src="https://github.com/openjdk/jdk/assets/96922791/89b92288-9b5e-48ed-8fa1-9342ea43e043">
> 
> <img width="1505" alt="Screenshot 2024-05-06 at 00 08 06" src="https://github.com/openjdk/jdk/assets/96922791/9aef08ff-5030-4189-a996-582a7eef849b">
> 
> <img width="1050" alt="Screenshot 2024-05-06 at 00 09 03" src="https://github.com/openjdk/jdk/assets/96922791/fdd75a26-0396-4c5e-8f59-a3717b7d7ec8">
> 
> 
> TIA

Nizar Benalla 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 11 additional commits since the last revision:

 - Merge remote-tracking branch 'upstream/master' into 8330954
 - (C)
 - (C)
 - Move security classes changes to pr18373
 - remove couple extra lines
 - Pull request is now only about `@since` tags, might add an other commit
 - add one more `{inheritDoc}` to `CompletableFuture.state`
 - add `@throws` declarations to javadoc
 - add ``{@inheritDoc}`` to new javadoc comments
 - remove two extra spaces
 - ... and 1 more: https://git.openjdk.org/jdk/compare/14267b99...b3574b97

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/18954/files
  - new: https://git.openjdk.org/jdk/pull/18954/files/be91ab80..b3574b97

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18954&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18954&range=02-03

  Stats: 52850 lines in 2204 files changed: 24705 ins; 18722 del; 9423 mod
  Patch: https://git.openjdk.org/jdk/pull/18954.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18954/head:pull/18954

PR: https://git.openjdk.org/jdk/pull/18954

From duke at openjdk.org  Mon May 13 20:24:58 2024
From: duke at openjdk.org (Nizar Benalla)
Date: Mon, 13 May 2024 20:24:58 GMT
Subject: RFR: 8326951: Missing `@since` tags [v8]
In-Reply-To: <_iA0CxGgaa8nA5AlNfT1IfG3Y6Wx7tcdiv3oJQNYCjQ=.5fb84060-0490-4b18-8995-cc534e1c22f5@github.com>
References: <_iA0CxGgaa8nA5AlNfT1IfG3Y6Wx7tcdiv3oJQNYCjQ=.5fb84060-0490-4b18-8995-cc534e1c22f5@github.com>
Message-ID: <hyegDt-KNrROnbAeJcdzNefWYn-ra_yfOoICIzZ4Mfg=.1223f11f-ab6c-49f5-85a5-69ac872200fd@github.com>

> I added `@since` tags for methods/constructors that do not match the `@since` of the enclosing class.
> 
> The `write` method already existed in `PrintStream` in earlier versions and instances of it could always call this method, since it extends `FilterOutputStream` [which has the method](https://github.com/openjdk/jdk6/blob/3e49aa876353eaa215cde71eb21acc9b7f9872a0/jdk/src/share/classes/java/io/FilterOutputStream.java#L96).
> 
> for `MappedByteBuffer slice()` and `MappedByteBuffer slice(int index, int length)`, the return type changed from `ByteBuffer ` to `MappedByteBuffer`. And the checker tool differentiates between them because of that.
> 
> This is similar to #18032 and #18373 
> 
> For context, I am writing tests to check for accurate use of `@since` tags in documentation comments in source code.
> We're following these rules for now:
> 
> ### Rule 1: Introduction of New Elements
> 
> - If an element is new in JDK N, with no equivalent in JDK N-1, it must include `@since N`.
>   - Exception: Member elements (fields, methods, nested classes) may omit `@since` if their version matches the value specified for the enclosing class or interface.
> 
> ### Rule 2: Existing Elements in Subsequent JDK Versions
> 
> - If an element exists in JDK N, with an equivalent in JDK N-1, it should not include `@since N`.
> 
> ### Rule 3: Handling Missing `@since` Tags in methods if there is no `@since`
> 
> - When inspecting methods, prioritize the `@since` annotation of the supertype's overridden method.
> - If unavailable or if the enclosing class's `@since` is newer, use the enclosing element's `@since`.
> 
>   I.e. if A extends B, and we add a method to B in JDK N, and add an override of the method to A in JDK M (M > N), we will use N as the effective `@since` for the method.

Nizar Benalla 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 15 additional commits since the last revision:

 - Merge remote-tracking branch 'upstream/master' into add-missing-since-tags
 - deal with methods with different return types - added some spaces for readability
 - removed change
 - Update full name
 - update the copyright year to 2024
 - Revert "update the copyright year to 2024"
   
   This reverts commit 9ddd230dcf88bedade76a8e2804db6e120a200f8.
 - update the copyright year to 2024
 - added since tag
 - Revert "fix rest of private/public since tags"
   
   This reverts commit 2c04a9d8e773616b7b6239335d4e5eb955944ad1.
 - Revert "removed unnecessary @ since tags"
   
   This reverts commit 5da3f0d83d19393eeb3a9da68aac40dd999de660.
 - ... and 5 more: https://git.openjdk.org/jdk/compare/893cd607...d3b8e64c

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/18055/files
  - new: https://git.openjdk.org/jdk/pull/18055/files/670acaec..d3b8e64c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18055&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18055&range=06-07

  Stats: 592766 lines in 7064 files changed: 99933 ins; 147099 del; 345734 mod
  Patch: https://git.openjdk.org/jdk/pull/18055.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18055/head:pull/18055

PR: https://git.openjdk.org/jdk/pull/18055

From duke at openjdk.org  Mon May 13 20:39:14 2024
From: duke at openjdk.org (Nizar Benalla)
Date: Mon, 13 May 2024 20:39:14 GMT
Subject: RFR: 8326951: Missing `@since` tags [v9]
In-Reply-To: <_iA0CxGgaa8nA5AlNfT1IfG3Y6Wx7tcdiv3oJQNYCjQ=.5fb84060-0490-4b18-8995-cc534e1c22f5@github.com>
References: <_iA0CxGgaa8nA5AlNfT1IfG3Y6Wx7tcdiv3oJQNYCjQ=.5fb84060-0490-4b18-8995-cc534e1c22f5@github.com>
Message-ID: <pLPZraQyDKDMrceODyPdO4-sT4a9_SuZzGoSQGvOglU=.07ae024b-34ae-4f33-8752-8cf83543ed07@github.com>

> I added `@since` tags for methods/constructors that do not match the `@since` of the enclosing class.
> 
> The `write` method already existed in `PrintStream` in earlier versions and instances of it could always call this method, since it extends `FilterOutputStream` [which has the method](https://github.com/openjdk/jdk6/blob/3e49aa876353eaa215cde71eb21acc9b7f9872a0/jdk/src/share/classes/java/io/FilterOutputStream.java#L96).
> 
> for `MappedByteBuffer slice()` and `MappedByteBuffer slice(int index, int length)`, the return type changed from `ByteBuffer ` to `MappedByteBuffer`. And the checker tool differentiates between them because of that.
> 
> This is similar to #18032 and #18373 
> 
> For context, I am writing tests to check for accurate use of `@since` tags in documentation comments in source code.
> We're following these rules for now:
> 
> ### Rule 1: Introduction of New Elements
> 
> - If an element is new in JDK N, with no equivalent in JDK N-1, it must include `@since N`.
>   - Exception: Member elements (fields, methods, nested classes) may omit `@since` if their version matches the value specified for the enclosing class or interface.
> 
> ### Rule 2: Existing Elements in Subsequent JDK Versions
> 
> - If an element exists in JDK N, with an equivalent in JDK N-1, it should not include `@since N`.
> 
> ### Rule 3: Handling Missing `@since` Tags in methods if there is no `@since`
> 
> - When inspecting methods, prioritize the `@since` annotation of the supertype's overridden method.
> - If unavailable or if the enclosing class's `@since` is newer, use the enclosing element's `@since`.
> 
>   I.e. if A extends B, and we add a method to B in JDK N, and add an override of the method to A in JDK M (M > N), we will use N as the effective `@since` for the method.

Nizar Benalla has updated the pull request incrementally with one additional commit since the last revision:

  empty commit and merge

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/18055/files
  - new: https://git.openjdk.org/jdk/pull/18055/files/d3b8e64c..e66fbf5a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18055&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18055&range=07-08

  Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/18055.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18055/head:pull/18055

PR: https://git.openjdk.org/jdk/pull/18055

From smarks at openjdk.org  Mon May 13 21:03:04 2024
From: smarks at openjdk.org (Stuart Marks)
Date: Mon, 13 May 2024 21:03:04 GMT
Subject: RFR: 8331876: JFR: Move file read and write events to java.base
 [v3]
In-Reply-To: <UBAcBKmhmCkeevxrteAThIEvD8YNBWFrUa_qffEng14=.c50dbe19-3465-4385-9fe4-8c284a0b116e@github.com>
References: <DDe0bKCC86AawVl7RylZ74uvvLBr2Zljpkcmxx1_WEU=.61cc10c6-b635-42dd-a850-b32ae1d68585@github.com>
 <SejX7NAvWNjrhDEN8uDf4oikQDBRclWXDg1fN5FCpkc=.7de48c6f-0af2-4bf4-a743-6e173d950d52@github.com>
 <DgjIOZTfztdSEeODuNZw5MmzsiohA82hhllWCceyPyU=.7bda36a1-e26d-4d7e-822a-e443d3cbc0df@github.com>
 <khrP38H7DBIyftQZtZt0CRXeH1ZkpOCjiRNvFTs3LSI=.fd62aba9-5153-4521-84e4-241b8a352720@github.com>
 <zGenHEqjgT6f_P_VtwfKbmzBeQoArW8MHwfAa6uVGVY=.eb912b9b-3f02-4cac-8d96-e1bdbaaea2b8@github.com>
 <wluFwF2Nhgjz-yspRYtEXIJ6jEiWm9imPd6CZlwYt6Y=.991f1032-1f5a-4762-8e5b-edc74d513e88@github.com>
 <UBAcBKmhmCkeevxrteAThIEvD8YNBWFrUa_qffEng14=.c50dbe19-3465-4385-9fe4-8c284a0b116e@github.com>
Message-ID: <hCLpZtC0PzTKDqSFbBympxsb4A3Sta3G3N2Ec8JfsSs=.2c57b9ff-e81d-42a0-8384-3663b14192ca@github.com>

On Sun, 12 May 2024 07:27:26 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> If an event class is loaded before JFR is started, the event class needs to be retransformed, but if it is loaded later, we can add instrumentation on class load and avoid the retransformation. More happens when an event class is loaded compared to ordinary class load, for example, a startTime field is added.
>> 
>> I did a JMH run and the difference between Event::enabled() and a boolean flag was a fraction of nanosecond.
>
>> If an event class is loaded before JFR is started, the event class needs to be retransformed, but if it is loaded later, we can add instrumentation on class load and avoid the retransformation. More happens when an event class is loaded compared to ordinary class load, for example, a startTime field is added.
>> 
>> I did a JMH run and the difference between Event::enabled() and a boolean flag was a fraction of nanosecond.
> 
> There are instances of FIS/FOS created in initPhase1 for the standard streams so loading as few classes and executing as minimal as possible is good. RAF will typically be used early too as the zip code opens zip files with a RAF. So doing as little as possible is good.

My main concern here is the addition of clutter (checking two flags, and creating two levels of nested "impl" methods) at every call site. We may need to rearrange our internal API for JFR (jdk.internal.events) in order to clean up the call sites without loading additional classes unnecessarily.

I think the main performance comparison to make is the impact on startup time of loading the additional FileReadEvent class. That is, to compare the startup time of the baseline with code that loads the FileReadEvent class, with JFR disabled in both cases. I don't know how to do this. Anyway, if loading of additional classes imposes unacceptable overhead, then that justifies doing more work to avoid it. That's separate from whether adding the `jfrTracing` flag as done in this PR is an effective way to do it.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19129#discussion_r1599077056

From smarks at openjdk.org  Mon May 13 21:17:01 2024
From: smarks at openjdk.org (Stuart Marks)
Date: Mon, 13 May 2024 21:17:01 GMT
Subject: RFR: 8332084: Ensure JdkConsoleImpl.restoreEcho visibility in a
 shutdown hook [v3]
In-Reply-To: <lLPvzpLD8otrOuchognaYtSQQu75txoPpHGlZVJ7qhY=.6c8f9c14-e22a-496e-a55a-f40676b95a9a@github.com>
References: <9JTWc3FRpfbILlSHlmIU_dL5IE69RTxnSIAOdIte15I=.5854a48f-21d7-42c9-adb7-5e3ed40d1211@github.com>
 <lLPvzpLD8otrOuchognaYtSQQu75txoPpHGlZVJ7qhY=.6c8f9c14-e22a-496e-a55a-f40676b95a9a@github.com>
Message-ID: <rMn4swvTo6iF-603_7a_kteWOX-wmSR0fNhlpqtNw88=.17a91580-c3ed-4c95-b314-2b82f792b60c@github.com>

On Mon, 13 May 2024 17:06:32 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Making sure `restoreEcho` correctly reflects the state in the shutdown thread, which differs from the application's thread that issues the `readPassword()` method.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Replaced another unused exception with _

Hm, I don't think we want to add any synchronized blocks within a shutdown hook. If a thread is blocked reading from the console, it will hold readLock; if the JVM is then shut down using a signal, it will run shutdown hooks, and this hook will block awaiting readLock. This can deadlock the shutdown completely.

To ensure proper memory visibility, maybe consider making `restoreEcho` be volatile.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19184#issuecomment-2108811013

From naoto at openjdk.org  Mon May 13 21:32:18 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 13 May 2024 21:32:18 GMT
Subject: RFR: 8332084: Ensure JdkConsoleImpl.restoreEcho visibility in a
 shutdown hook [v4]
In-Reply-To: <9JTWc3FRpfbILlSHlmIU_dL5IE69RTxnSIAOdIte15I=.5854a48f-21d7-42c9-adb7-5e3ed40d1211@github.com>
References: <9JTWc3FRpfbILlSHlmIU_dL5IE69RTxnSIAOdIte15I=.5854a48f-21d7-42c9-adb7-5e3ed40d1211@github.com>
Message-ID: <3Ljww4SBrsr6wmjoBGFLvYJ-cG6jNGdblfb2B7bZuB0=.97e3da61-c10d-4da2-b27a-2bd45dfc544f@github.com>

> Making sure `restoreEcho` correctly reflects the state in the shutdown thread, which differs from the application's thread that issues the `readPassword()` method.

Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:

  Addresses a review comment

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19184/files
  - new: https://git.openjdk.org/jdk/pull/19184/files/3e7d2e0c..fb5beb11

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19184&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19184&range=02-03

  Stats: 8 lines in 1 file changed: 0 ins; 2 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/19184.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19184/head:pull/19184

PR: https://git.openjdk.org/jdk/pull/19184

From naoto at openjdk.org  Mon May 13 21:32:19 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 13 May 2024 21:32:19 GMT
Subject: RFR: 8332084: Ensure JdkConsoleImpl.restoreEcho visibility in a
 shutdown hook [v3]
In-Reply-To: <lLPvzpLD8otrOuchognaYtSQQu75txoPpHGlZVJ7qhY=.6c8f9c14-e22a-496e-a55a-f40676b95a9a@github.com>
References: <9JTWc3FRpfbILlSHlmIU_dL5IE69RTxnSIAOdIte15I=.5854a48f-21d7-42c9-adb7-5e3ed40d1211@github.com>
 <lLPvzpLD8otrOuchognaYtSQQu75txoPpHGlZVJ7qhY=.6c8f9c14-e22a-496e-a55a-f40676b95a9a@github.com>
Message-ID: <g5D4AbGjY65xNIgDg7wZ0_yYCviuSVIOiFGPXIXX8Yc=.741e2686-1670-46ec-8006-90499e932c89@github.com>

On Mon, 13 May 2024 17:06:32 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Making sure `restoreEcho` correctly reflects the state in the shutdown thread, which differs from the application's thread that issues the `readPassword()` method.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Replaced another unused exception with _

Right, making the field volatile is a much safer solution.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19184#issuecomment-2108832766

From liangchenblue at gmail.com  Mon May 13 22:50:39 2024
From: liangchenblue at gmail.com (-)
Date: Mon, 13 May 2024 17:50:39 -0500
Subject: Moving core reflection's Signature parsing to Class-File API
Message-ID: <CABe8uE1VbBC_u=oao+H5JSP9CeLw8puPQ=nF82UQmOs1Svb2FA@mail.gmail.com>

Hello,
Class-File API has a convenient Signature model API, which can replace the
Generic Tree internal API in the current core reflection implementation.
The old internal Tree API + visitor pattern was bloated with a lot of
unnecessary classes, which can be removed with the new CF API.

A working implementation with all tier 1 tests passing is available at
https://github.com/openjdk/jdk/compare/master...liachmodded:jdk:feature/new-generic-info?expand=1
.

In my implementation:
 - reflectiveObjects (classes directly implementing ParameterizedType,
etc.) remain; they are exported, and their implementation is sufficient
as-is.
 - all other old generic classes are removed
 - few existing usages of old generic code moved to BytecodeDescriptor, use
sites converted to throw GenericSignatureFormatError (preexisting behavior)
instead of IllegalArgumentException
 - Just 5 new classes are added to replaced all removed old classes.

Given the size of this patch, I decide to start a discussion on the mailing
lists on this proposal. Is there any shortcomings with this patch, or is
there anything that I should be cautious of for this patch?

Best regards,
Chen Liang
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240513/35b12e4b/attachment.htm>

From sviswanathan at openjdk.org  Mon May 13 23:15:07 2024
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Mon, 13 May 2024 23:15:07 GMT
Subject: RFR: 8320448: Accelerate IndexOf using AVX2 [v19]
In-Reply-To: <eQ4OBFrF8JlDJ1h9awTDOc0kfCc37IlL5vdqtuaqls0=.8f00616d-08e1-4f28-a7a5-5095116d2595@github.com>
References: <uWi4QxH31hL93771gkl_GgvP0m84IRSoR_1Yi8hD17E=.bc6ed458-7081-4c3f-9348-f59358fa05a4@github.com>
 <eQ4OBFrF8JlDJ1h9awTDOc0kfCc37IlL5vdqtuaqls0=.8f00616d-08e1-4f28-a7a5-5095116d2595@github.com>
Message-ID: <bIJdJ-8i1jOFCV80cT1JdSz1K2reM6-X5jKJzxlyoZY=.d6de3009-b528-4f4d-a1b1-04d132288715@github.com>

On Sat, 4 May 2024 19:35:21 GMT, Scott Gibbons <sgibbons at openjdk.org> wrote:

>> Re-write the IndexOf code without the use of the pcmpestri instruction, only using AVX2 instructions.  This change accelerates String.IndexOf on average 1.3x for AVX2.  The benchmark numbers:
>> 
>> 
>> Benchmark	                                               Score		Latest		
>> StringIndexOf.advancedWithMediumSub   343.573		317.934		0.925375393x
>> StringIndexOf.advancedWithShortSub1	  1039.081		1053.96		1.014319384x
>> StringIndexOf.advancedWithShortSub2	      55.828		110.541		1.980027943x
>> StringIndexOf.constantPattern	                9.361		11.906		1.271872663x
>> StringIndexOf.searchCharLongSuccess	        4.216		4.218		1.000474383x
>> StringIndexOf.searchCharMediumSuccess	3.133		3.216		1.02649218x
>> StringIndexOf.searchCharShortSuccess	3.76		        3.761		1.000265957x
>> StringIndexOf.success	                                9.186		9.713		1.057369911x
>> StringIndexOf.successBig	                      14.341		46.343		3.231504079x
>> StringIndexOfChar.latin1_AVX2_String	  6220.918		12154.52		1.953814533x
>> StringIndexOfChar.latin1_AVX2_char	  5503.556		5540.044		1.006629895x
>> StringIndexOfChar.latin1_SSE4_String	  6978.854		6818.689		0.977049957x
>> StringIndexOfChar.latin1_SSE4_char	  5657.499		5474.624		0.967675646x
>> StringIndexOfChar.latin1_Short_String	  7132.541		6863.359		0.962260014x
>> StringIndexOfChar.latin1_Short_char	16013.389	      16162.437		1.009307711x
>> StringIndexOfChar.latin1_mixed_String	  7386.123	      14771.622		1.999915517x
>> StringIndexOfChar.latin1_mixed_char	  9901.671		9782.245		0.987938803
>
> Scott Gibbons has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rearrange; add lambdas for clarity

src/hotspot/cpu/x86/stubGenerator_x86_64_string.cpp line 1054:

> 1052:         } else if (isUL) {
> 1053:           __ movzbl(rTmp, Address(needle, 2));
> 1054:           __ movdl(byte_1, rTmp);

Should be: __ movdl(byte_2, rTmp);

src/hotspot/cpu/x86/stubGenerator_x86_64_string.cpp line 1056:

> 1054:           __ movdl(byte_1, rTmp);
> 1055:           // 1st byte of needle in words
> 1056:           __ vpbroadcastw(byte_1, byte_1, Assembler::AVX_256bit);

Should be:
__ vpbroadcastw(byte_2, byte_2, Assembler::AVX_256bit);

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1599194092
PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1599194375

From duke at openjdk.org  Mon May 13 23:54:09 2024
From: duke at openjdk.org (Volodymyr Paprotski)
Date: Mon, 13 May 2024 23:54:09 GMT
Subject: RFR: 8320448: Accelerate IndexOf using AVX2 [v19]
In-Reply-To: <eQ4OBFrF8JlDJ1h9awTDOc0kfCc37IlL5vdqtuaqls0=.8f00616d-08e1-4f28-a7a5-5095116d2595@github.com>
References: <uWi4QxH31hL93771gkl_GgvP0m84IRSoR_1Yi8hD17E=.bc6ed458-7081-4c3f-9348-f59358fa05a4@github.com>
 <eQ4OBFrF8JlDJ1h9awTDOc0kfCc37IlL5vdqtuaqls0=.8f00616d-08e1-4f28-a7a5-5095116d2595@github.com>
Message-ID: <kQqTVjddCtPg3veW8bu_W1ae-xYxXxdhIj9-wkpax6c=.f2b341b9-794a-4355-a2a0-e481e3691eb8@github.com>

On Sat, 4 May 2024 19:35:21 GMT, Scott Gibbons <sgibbons at openjdk.org> wrote:

>> Re-write the IndexOf code without the use of the pcmpestri instruction, only using AVX2 instructions.  This change accelerates String.IndexOf on average 1.3x for AVX2.  The benchmark numbers:
>> 
>> 
>> Benchmark	                                               Score		Latest		
>> StringIndexOf.advancedWithMediumSub   343.573		317.934		0.925375393x
>> StringIndexOf.advancedWithShortSub1	  1039.081		1053.96		1.014319384x
>> StringIndexOf.advancedWithShortSub2	      55.828		110.541		1.980027943x
>> StringIndexOf.constantPattern	                9.361		11.906		1.271872663x
>> StringIndexOf.searchCharLongSuccess	        4.216		4.218		1.000474383x
>> StringIndexOf.searchCharMediumSuccess	3.133		3.216		1.02649218x
>> StringIndexOf.searchCharShortSuccess	3.76		        3.761		1.000265957x
>> StringIndexOf.success	                                9.186		9.713		1.057369911x
>> StringIndexOf.successBig	                      14.341		46.343		3.231504079x
>> StringIndexOfChar.latin1_AVX2_String	  6220.918		12154.52		1.953814533x
>> StringIndexOfChar.latin1_AVX2_char	  5503.556		5540.044		1.006629895x
>> StringIndexOfChar.latin1_SSE4_String	  6978.854		6818.689		0.977049957x
>> StringIndexOfChar.latin1_SSE4_char	  5657.499		5474.624		0.967675646x
>> StringIndexOfChar.latin1_Short_String	  7132.541		6863.359		0.962260014x
>> StringIndexOfChar.latin1_Short_char	16013.389	      16162.437		1.009307711x
>> StringIndexOfChar.latin1_mixed_String	  7386.123	      14771.622		1.999915517x
>> StringIndexOfChar.latin1_mixed_char	  9901.671		9782.245		0.987938803
>
> Scott Gibbons has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rearrange; add lambdas for clarity

src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 4492:

> 4490: 
> 4491: // Compare char[] or byte[] arrays aligned to 4 bytes or substrings.
> 4492: void C2_MacroAssembler::arrays_equals(bool is_array_equ, Register ary1,

I liked the old style better, fewer longer lines.. same for rest of the changes in this file.

src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 4594:

> 4592: #endif //_LP64
> 4593:     bind(COMPARE_WIDE_VECTORS);
> 4594:     vmovdqu(vec1, Address(ary1, limit,

create a local scale variable instead of ternary operators. Used several times.

src/hotspot/cpu/x86/stubGenerator_x86_64.cpp line 4250:

> 4248:   generate_chacha_stubs();
> 4249: 
> 4250:   if ((UseAVX == 2) && EnableX86ECoreOpts && VM_Version::supports_avx2()) {

Just `if (EnableX86ECoreOpts)`?

src/hotspot/cpu/x86/stubGenerator_x86_64_string.cpp line 391:

> 389:       }
> 390: 
> 391:       __ cmpq(needle_len, isU ? 2 : 1);

Can we remove this comparison? i.e.
- broadcast first and last character unconditionally (same character). Or
- move broadcasts 'down' into individual cases..
There is already specialized code to handle needle of size 1.. This adds extra pathlength. (Will we actually call this intrinsic for needle_size==1? Assume length>=2?)

src/hotspot/cpu/x86/stubGenerator_x86_64_string.cpp line 1365:

> 1363:   // Compare first byte of needle to haystack
> 1364:      vpcmpeq(cmp_0, byte_0, Address(haystack, 0), Assembler::AVX_256bit);
> 1365:   if (size != (isU ? 2 : 1)) {

`if (size != scale)`

Though in this case, `elem_size` might hold more meaning.

src/hotspot/cpu/x86/stubGenerator_x86_64_string.cpp line 1372:

> 1370: 
> 1371:     if (bytesToCompare > 2) {
> 1372:       if (size > (isU ? 4 : 2)) {

`if (size > 2*scale)`?

src/hotspot/cpu/x86/stubGenerator_x86_64_string.cpp line 1373:

> 1371:     if (bytesToCompare > 2) {
> 1372:       if (size > (isU ? 4 : 2)) {
> 1373:         if (doEarlyBailout) {

Is there a big perf difference when `doEarlyBailout` is enabled? And/or just for this function?

(i.e. removing `doEarlyBailout` in this function will mean less pathlength. Feels like a few extra vpands should be cheap enough.)

src/hotspot/cpu/x86/stubGenerator_x86_64_string.cpp line 1469:

> 1467: 
> 1468:   if (isU && (size & 1)) {
> 1469:     __ emit_int8(0xcc);

This should also be an `assert()` to catch this at compile-time.

src/hotspot/cpu/x86/stubGenerator_x86_64_string.cpp line 1633:

> 1631:   if (isU) {
> 1632:     if ((size & 1) != 0) {
> 1633:       __ emit_int8(0xcc);

Compile-time assert to ensure this code is never called instead?

src/hotspot/cpu/x86/stubGenerator_x86_64_string.cpp line 1889:

> 1887:     //  r13 = (needle length - 1)
> 1888:     //  r14 = &needle
> 1889:     //  r15 = unused

There is quite a bit of redundancy in register usage. Its not incorrect, but looks odd. Not clear if this duplication can easily be removed (or if/why needed). 

    //  rbx = &haystack
    //  rdi = &haystack
    //  rdx = &needle
    //  r14 = &needle
    //  rcx = haystack length
    //  rsi = haystack length
    //  r12 = needle length
    //  r13 = (needle length - 1)
    //  r10 = hs_len - needle len
    //  rbp = -1
    
    //  rax = unused
    //  r11 = unused
    //  r8  = unused
    //  r9  = unused
    //  r15 = unused


(Could this comment be out-of-sync with the code? Looks like only rbx, r14 and temps out of unused registers are used few lines down)

src/hotspot/cpu/x86/stubGenerator_x86_64_string.cpp line 1950:

> 1948:     //  r13 = (needle length - 1)
> 1949:     //  r14 = &needle
> 1950:     //  r15 = unused

Same as for the small case

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1592834449
PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1592838385
PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1592831339
PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1599131482
PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1599146451
PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1599144855
PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1599143784
PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1599151000
PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1599204083
PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1599209564
PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1599213635

From vklang at openjdk.org  Mon May 13 23:59:17 2024
From: vklang at openjdk.org (Viktor Klang)
Date: Mon, 13 May 2024 23:59:17 GMT
Subject: RFR: 8331987: Enhance stacktrace clarity for CompletableFuture
 CancellationException [v2]
In-Reply-To: <JI-ghId-imtBqmNm850oQMNp-9p79tGMjfTRDdXz6D0=.fc134f86-914c-4484-9236-af162de3b99e@github.com>
References: <JI-ghId-imtBqmNm850oQMNp-9p79tGMjfTRDdXz6D0=.fc134f86-914c-4484-9236-af162de3b99e@github.com>
Message-ID: <RwiMTpthY-AzuKJz7IESDRvEpp_yAA_HSsxMMHM42xM=.86290ec9-c841-4698-839c-eda03fa3fb03@github.com>

> This change adds wrapping of the CancellationException produced by CompletableFuture::get() and CompletableFuture::join() to add more diagnostic information and align better with FutureTask.
> 
> Running the sample code from the JBS issue in JShell will produce the following:
> 
> 
> jshell> java.util.concurrent.CancellationException: 
> 	at java.base/java.util.concurrent.CompletableFuture.reportGet(CompletableFuture.java:392)
> 	at java.base/java.util.concurrent.CompletableFuture.get(CompletableFuture.java:2073)
> 	at REPL.$JShell$18.m2($JShell$18.java:10)
> 	at REPL.$JShell$17.m1($JShell$17.java:8)
> 	at REPL.$JShell$16B.lambda$main$0($JShell$16B.java:8)
> 	at java.base/java.lang.Thread.run(Thread.java:1575)
> Caused by: java.util.concurrent.CancellationException
> 	at java.base/java.util.concurrent.CompletableFuture.cancel(CompletableFuture.java:2510)
> 	at REPL.$JShell$16B.lambda$main$1($JShell$16B.java:11)
> 	... 1 more

Viktor Klang has updated the pull request incrementally with one additional commit since the last revision:

  Adding CancellationException detail message to CompletableFuture

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19219/files
  - new: https://git.openjdk.org/jdk/pull/19219/files/641bbfe3..078930ab

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19219&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19219&range=00-01

  Stats: 14 lines in 2 files changed: 0 ins; 0 del; 14 mod
  Patch: https://git.openjdk.org/jdk/pull/19219.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19219/head:pull/19219

PR: https://git.openjdk.org/jdk/pull/19219

From vklang at openjdk.org  Mon May 13 23:59:17 2024
From: vklang at openjdk.org (Viktor Klang)
Date: Mon, 13 May 2024 23:59:17 GMT
Subject: RFR: 8331987: Enhance stacktrace clarity for CompletableFuture
 CancellationException [v2]
In-Reply-To: <wma6KHEBFVLOwlnzxguE5L8BvROGAA1TWuj0MYCxrkg=.7faf0176-565a-4555-8571-bd43b8f9cc58@github.com>
References: <JI-ghId-imtBqmNm850oQMNp-9p79tGMjfTRDdXz6D0=.fc134f86-914c-4484-9236-af162de3b99e@github.com>
 <680cm1Ox8RH-vgI7V6RzTDV6zDfC3_mamIv3WHfLkIc=.c90f13f8-66ab-4b27-a03b-0f9278dfa535@github.com>
 <wma6KHEBFVLOwlnzxguE5L8BvROGAA1TWuj0MYCxrkg=.7faf0176-565a-4555-8571-bd43b8f9cc58@github.com>
Message-ID: <8B5TzsmgqPXJ4r06T5q5rt1Rkd5hySMYu9T_-dJc-Jc=.c1198e93-5b80-43ce-a13e-ae80b81193b9@github.com>

On Mon, 13 May 2024 18:16:55 GMT, Doug Lea <dl at openjdk.org> wrote:

>> src/java.base/share/classes/java/util/concurrent/CompletableFuture.java line 392:
>> 
>>> 390:                 return null;
>>> 391:             if (x instanceof CancellationException)
>>> 392:                 throw new CancellationException("", (CancellationException)x);
>> 
>> One option here would be to put "CompletableFuture.get()" or "get()" as a message.
>
> Given the serviceability motivation, the overkill of adding "get" and "join" strings seems reasonable.

@DougLea Yeah, I think that's fair enough. I pushed a commit which allows for customization of the details message.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19219#discussion_r1599221161

From jwaters at openjdk.org  Tue May 14 00:28:05 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Tue, 14 May 2024 00:28:05 GMT
Subject: RFR: 8330988: Implementation of 8288293: Windows/gcc Port for
 hsdis [v2]
In-Reply-To: <xvXZ9TddIGBdQqUJ0c_MccUw7lPjJqeTZzrPYJG-EyQ=.59e09c22-93b5-4271-9cc7-60b1d1f90a8e@github.com>
References: <bXwOUFPBZUWDmidfDnVJLBKG4HkeS585IJqAOK8W1ys=.211183fe-b18e-498d-a557-6e6c4dfac27c@github.com>
 <xvXZ9TddIGBdQqUJ0c_MccUw7lPjJqeTZzrPYJG-EyQ=.59e09c22-93b5-4271-9cc7-60b1d1f90a8e@github.com>
Message-ID: <d2qbMOw9E6lt7crXs3DHWdMx22NI7a8MKnSiIpUY7DI=.e68b0ed9-7f35-4e07-b08b-2fe7337c23cc@github.com>

On Thu, 9 May 2024 07:50:00 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.
>
> Julian Waters has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:
> 
>  - Add check for compiler in configure
>  - 8330988: Implementation of 8288293: Windows/gcc Port for hsdis

Hmm, it seems Magnus isn't available at the moment. @erikj79 might you be able to answer my questions regarding hsdis?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18915#issuecomment-2109049333

From sviswanathan at openjdk.org  Tue May 14 00:51:08 2024
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Tue, 14 May 2024 00:51:08 GMT
Subject: RFR: 8320448: Accelerate IndexOf using AVX2 [v19]
In-Reply-To: <eQ4OBFrF8JlDJ1h9awTDOc0kfCc37IlL5vdqtuaqls0=.8f00616d-08e1-4f28-a7a5-5095116d2595@github.com>
References: <uWi4QxH31hL93771gkl_GgvP0m84IRSoR_1Yi8hD17E=.bc6ed458-7081-4c3f-9348-f59358fa05a4@github.com>
 <eQ4OBFrF8JlDJ1h9awTDOc0kfCc37IlL5vdqtuaqls0=.8f00616d-08e1-4f28-a7a5-5095116d2595@github.com>
Message-ID: <nltV33bCbp2YSk4oIRnJNPnL1eP6SmMjuw1V38yzVks=.0ddb70b7-6607-4067-9321-9653c17b2507@github.com>

On Sat, 4 May 2024 19:35:21 GMT, Scott Gibbons <sgibbons at openjdk.org> wrote:

>> Re-write the IndexOf code without the use of the pcmpestri instruction, only using AVX2 instructions.  This change accelerates String.IndexOf on average 1.3x for AVX2.  The benchmark numbers:
>> 
>> 
>> Benchmark	                                               Score		Latest		
>> StringIndexOf.advancedWithMediumSub   343.573		317.934		0.925375393x
>> StringIndexOf.advancedWithShortSub1	  1039.081		1053.96		1.014319384x
>> StringIndexOf.advancedWithShortSub2	      55.828		110.541		1.980027943x
>> StringIndexOf.constantPattern	                9.361		11.906		1.271872663x
>> StringIndexOf.searchCharLongSuccess	        4.216		4.218		1.000474383x
>> StringIndexOf.searchCharMediumSuccess	3.133		3.216		1.02649218x
>> StringIndexOf.searchCharShortSuccess	3.76		        3.761		1.000265957x
>> StringIndexOf.success	                                9.186		9.713		1.057369911x
>> StringIndexOf.successBig	                      14.341		46.343		3.231504079x
>> StringIndexOfChar.latin1_AVX2_String	  6220.918		12154.52		1.953814533x
>> StringIndexOfChar.latin1_AVX2_char	  5503.556		5540.044		1.006629895x
>> StringIndexOfChar.latin1_SSE4_String	  6978.854		6818.689		0.977049957x
>> StringIndexOfChar.latin1_SSE4_char	  5657.499		5474.624		0.967675646x
>> StringIndexOfChar.latin1_Short_String	  7132.541		6863.359		0.962260014x
>> StringIndexOfChar.latin1_Short_char	16013.389	      16162.437		1.009307711x
>> StringIndexOfChar.latin1_mixed_String	  7386.123	      14771.622		1.999915517x
>> StringIndexOfChar.latin1_mixed_char	  9901.671		9782.245		0.987938803
>
> Scott Gibbons has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rearrange; add lambdas for clarity

src/hotspot/cpu/x86/stubGenerator_x86_64_string.cpp line 1083:

> 1081: // haystack - the address of the first byte of the haystack
> 1082: // hsLen - the sizeof the haystack
> 1083: // isU - true if argument encoding is either UU or UL

We need to list needleLen here as well?

src/hotspot/cpu/x86/stubGenerator_x86_64_string.cpp line 1096:

> 1094:                                            MacroAssembler *_masm) {
> 1095: 
> 1096:   assert_different_registers(eq_mask, haystack, needleLen, rTmp, hsLen, r10);

r10 kind of stands out here. You could say nMinusK in this assert.
The assert following to this one is checking for nMinusK==r10 so that should suffice.
BTW, didn't see anything in the code below that needs nMinuxK to be r10.

src/hotspot/cpu/x86/stubGenerator_x86_64_string.cpp line 1120:

> 1118: #define cmp_0 XMM_TMP3
> 1119: #undef cmp_k
> 1120: #define cmp_k XMM_TMP4

XMM_TMP4 is not reused so cmp_k could be declared as const. In general limiting undef/define pair only to reused registers would make the review easier.

src/hotspot/cpu/x86/stubGenerator_x86_64_string.cpp line 1125:

> 1123: #undef lastMask
> 1124: 
> 1125:   int sizeIncr = isU ? 2 : 1;

sizeIncr and scale seems to be same, we could just use one of them in this function.

src/hotspot/cpu/x86/stubGenerator_x86_64_string.cpp line 1178:

> 1176:     __ andq(eq_mask, lastMask);
> 1177:     if (needToSaveRCX) {
> 1178:       __ movdq(rcx, saveRCX);

movdq is an expensive instruction (about 3 cycle). If we have another gpr temporary available here for shiftVal, then we dont need to do save/restore rcx.

src/hotspot/cpu/x86/stubGenerator_x86_64_string.cpp line 1183:

> 1181: 
> 1182:     if (bytesToCompare > 2) {
> 1183:       if (size > (isU ? 4 : 2)) {

this and other usages could be simplified to: size > 2 * scale

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1599201163
PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1599203881
PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1599211645
PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1599202848
PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1599242323
PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1599228299

From bpb at openjdk.org  Tue May 14 01:00:01 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 14 May 2024 01:00:01 GMT
Subject: RFR: 8331907: BigInteger and BigDecimal should use optimized
 division [v4]
In-Reply-To: <m4XJ3ObwoIyBx0oeuRUGPqEjs54Gkq1ApUAGbmnFt8A=.f5c15f1a-4bdd-4904-ac2d-48dbefbb85a8@github.com>
References: <-U6_9J-If3E3P3j4y7kt2yTCdNLvKkTSPrK0FxhNM80=.07321109-402b-4d28-9788-ddd52f42467d@github.com>
 <m4XJ3ObwoIyBx0oeuRUGPqEjs54Gkq1ApUAGbmnFt8A=.f5c15f1a-4bdd-4904-ac2d-48dbefbb85a8@github.com>
Message-ID: <nJB7YIpAZjhR5uDwTSJS19L6sBv2rBAGZkvDlJJujEo=.971bfa1a-5023-4e90-8ef8-737b1f49cf6a@github.com>

On Fri, 10 May 2024 16:16:18 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> Replace the custom unsigned divide / remainder functions with the compiler-optimized Long.divideUnsigned / remainderUnsigned.
>> 
>> No new tests. Existing tier1-3 tests continue to pass.
>> 
>> I added a new set of divide benchmarks. Results in thread.
>> 
>> I also removed the BigDecimal.toString benchmarks. They no longer serve their purpose - toString caches the returned value, so we were only benchmarking the cache access time.
>
> Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Integer divide

I have nothing to add to the comments already resolved. +1

-------------

Marked as reviewed by bpb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19134#pullrequestreview-2054040985

From duke at openjdk.org  Tue May 14 01:03:09 2024
From: duke at openjdk.org (ExE Boss)
Date: Tue, 14 May 2024 01:03:09 GMT
Subject: RFR: 8331671: Implement JEP 472: Prepare to Restrict the Use of
 JNI [v3]
In-Reply-To: <jUWaDowOZsL42UtliIOoCe7WfowooCW1zvcVKyFnL7g=.4b20b555-3651-4fca-9ede-1652dec95e9c@github.com>
References: <CZGbki5iFdCGPPagE-ya-_L8Nkgf7OunywApOsxC548=.2cee82fa-a5d2-4165-b012-30982a85030a@github.com>
 <jUWaDowOZsL42UtliIOoCe7WfowooCW1zvcVKyFnL7g=.4b20b555-3651-4fca-9ede-1652dec95e9c@github.com>
Message-ID: <wH9oXMHtE8zC39h51asmc0gpIjJVuYF6uah2-m5Nf2k=.db1cd4c5-8933-4ae2-ab50-d022636ba24b@github.com>

On Mon, 13 May 2024 11:47:38 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This PR implements [JEP 472](https://openjdk.org/jeps/472), by restricting the use of JNI in the following ways:
>> 
>> * `System::load` and `System::loadLibrary` are now restricted methods
>> * `Runtime::load` and `Runtime::loadLibrary` are now restricted methods
>> * binding a JNI `native` method declaration to a native implementation is now considered a restricted operation
>> 
>> This PR slightly changes the way in which the JDK deals with restricted methods, even for FFM API calls. In Java 22, the single `--enable-native-access` was used both to specify a set of modules for which native access should be allowed *and* to specify whether illegal native access (that is, native access occurring from a module not specified by `--enable-native-access`) should be treated as an error or a warning. More specifically, an error is only issued if the `--enable-native-access flag` is used at least once.
>> 
>> Here, a new flag is introduced, namely `illegal-native-access=allow/warn/deny`, which is used to specify what should happen when access to a restricted method and/or functionality is found outside the set of modules specified with `--enable-native-access`. The default policy is `warn`, but users can select `allow` to suppress the warnings, or `deny` to cause `IllegalCallerException` to be thrown. This aligns the treatment of restricted methods with other mechanisms, such as `--illegal-access` and the more recent `--sun-misc-unsafe-memory-access`.
>> 
>> Some changes were required in the package-info javadoc for `java.lang.foreign`, to reflect the changes in the command line flags described above.
>
> Maurizio Cimadamore has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Fix another typo
>  - Fix typo
>  - Add more comments

src/hotspot/share/prims/nativeLookup.cpp line 275:

> 273: 
> 274:   // Otherwise call static method findNative in ClassLoader
> 275: 

Suggestion:

src/hotspot/share/prims/nativeLookup.cpp line 419:

> 417:   if (entry != nullptr) return entry;
> 418: 
> 419: 

Suggestion:

src/hotspot/share/prims/nativeLookup.cpp line 426:

> 424:       return nullptr;
> 425:     }
> 426:   }

Suggestion:

  }

src/java.base/share/classes/java/lang/Module.java line 331:

> 329:                 String modflag = isNamed() ? getName() : "ALL-UNNAMED";
> 330:                 String caller = currentClass != null ? currentClass.getName() : "code";
> 331:                 System.err.printf("""

This?message should?probably be?different when?linking native?methods, since otherwise it?ll be:

WARNING: A restricted method in foo has been called
WARNING: bar has been called by Baz in Baz
WARNING: Use --enable-native-access=foo to avoid a warning for callers in this module
WARNING: Restricted methods will be blocked in a future release unless native access is enabled


when?it?should really?be something?like:

WARNING: A JNI native method in foo has been linked
WARNING: bar has been linked in Baz
WARNING: Use --enable-native-access=foo to avoid a warning for native methods in this module
WARNING: Native methods will be blocked in a future release unless native access is enabled

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19213#discussion_r1599248442
PR Review Comment: https://git.openjdk.org/jdk/pull/19213#discussion_r1599248501
PR Review Comment: https://git.openjdk.org/jdk/pull/19213#discussion_r1599248577
PR Review Comment: https://git.openjdk.org/jdk/pull/19213#discussion_r1599253428

From smarks at openjdk.org  Tue May 14 01:04:02 2024
From: smarks at openjdk.org (Stuart Marks)
Date: Tue, 14 May 2024 01:04:02 GMT
Subject: RFR: 8332084: Ensure JdkConsoleImpl.restoreEcho visibility in a
 shutdown hook [v4]
In-Reply-To: <3Ljww4SBrsr6wmjoBGFLvYJ-cG6jNGdblfb2B7bZuB0=.97e3da61-c10d-4da2-b27a-2bd45dfc544f@github.com>
References: <9JTWc3FRpfbILlSHlmIU_dL5IE69RTxnSIAOdIte15I=.5854a48f-21d7-42c9-adb7-5e3ed40d1211@github.com>
 <3Ljww4SBrsr6wmjoBGFLvYJ-cG6jNGdblfb2B7bZuB0=.97e3da61-c10d-4da2-b27a-2bd45dfc544f@github.com>
Message-ID: <Y_5BgiHHEdBBh79b9PDvMEjIacnZyVAHOrctH_n2Tp8=.4dd0b88e-6cb4-4ad0-adc5-3eb1a1cc2b7b@github.com>

On Mon, 13 May 2024 21:32:18 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Making sure `restoreEcho` correctly reflects the state in the shutdown thread, which differs from the application's thread that issues the `readPassword()` method.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Addresses a review comment

Marked as reviewed by smarks (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/19184#pullrequestreview-2054044199

From smarks at openjdk.org  Tue May 14 01:18:09 2024
From: smarks at openjdk.org (Stuart Marks)
Date: Tue, 14 May 2024 01:18:09 GMT
Subject: RFR: 8305457: Implement java.io.IO [v9]
In-Reply-To: <PIg24sny09iDwNT6W--TkoqtY8V2tXWCjrUL4MO-CRg=.67519d97-15b9-4b72-9bdc-ecbcc3dbfd5c@github.com>
References: <w2msiw_qaMEIJS3s9D4bg8pFbz5WIF0KdP6Mm-XFjLI=.85b2020b-8c46-4bac-8a69-4975b068f2ff@github.com>
 <PIg24sny09iDwNT6W--TkoqtY8V2tXWCjrUL4MO-CRg=.67519d97-15b9-4b72-9bdc-ecbcc3dbfd5c@github.com>
Message-ID: <ZOkaZFGimKmYSgRQOmzQfCXRWkUp2FJqGv8JC-e6UGY=.16ccd575-f387-4085-999e-16bdd7bd2864@github.com>

On Mon, 13 May 2024 09:56:35 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Please review this PR which introduces the `java.io.IO` top-level class and three methods to `java.io.Console` for [Implicitly Declared Classes and Instance Main Methods (Third Preview)].
>> 
>> This PR has been obtained as `git merge --squash` of a now obsolete [draft PR].
>> 
>> [Implicitly Declared Classes and Instance Main Methods (Third Preview)]: https://bugs.openjdk.org/browse/JDK-8323335
>> [draft PR]: https://github.com/openjdk/jdk/pull/18921
>
> Pavel Rappo has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 17 additional commits since the last revision:
> 
>  - Escape prompt
>  - Merge branch 'master' into 8305457-Implement-java.io.IO
>  - Clarify input charset
>  - Make IO final
>  - Fix System.console().readln(null) in jshell
>    
>    Without it, jshell hangs on me. Will think of a test.
>  - Fix typo
>  - Merge branch 'master' into 8305457-Implement-java.io.IO
>  - Simplify output.exp
>  - Cover null prompt in input tests
>  - Make input test parametric
>  - ... and 7 more: https://git.openjdk.org/jdk/compare/8b9c719f...17100ab8

Marked as reviewed by smarks (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/19112#pullrequestreview-2054056729

From djelinski at openjdk.org  Tue May 14 05:04:05 2024
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Tue, 14 May 2024 05:04:05 GMT
Subject: RFR: 8331907: BigInteger and BigDecimal should use optimized
 division [v4]
In-Reply-To: <m4XJ3ObwoIyBx0oeuRUGPqEjs54Gkq1ApUAGbmnFt8A=.f5c15f1a-4bdd-4904-ac2d-48dbefbb85a8@github.com>
References: <-U6_9J-If3E3P3j4y7kt2yTCdNLvKkTSPrK0FxhNM80=.07321109-402b-4d28-9788-ddd52f42467d@github.com>
 <m4XJ3ObwoIyBx0oeuRUGPqEjs54Gkq1ApUAGbmnFt8A=.f5c15f1a-4bdd-4904-ac2d-48dbefbb85a8@github.com>
Message-ID: <O0bFeGyML6e6Qj0wD5gfmZBq_7aOU5lfPrNZONttSv8=.70868baa-fefd-4d95-a6f0-b11c54e485ae@github.com>

On Fri, 10 May 2024 16:16:18 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> Replace the custom unsigned divide / remainder functions with the compiler-optimized Long.divideUnsigned / remainderUnsigned.
>> 
>> No new tests. Existing tier1-3 tests continue to pass.
>> 
>> I added a new set of divide benchmarks. Results in thread.
>> 
>> I also removed the BigDecimal.toString benchmarks. They no longer serve their purpose - toString caches the returned value, so we were only benchmarking the cache access time.
>
> Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Integer divide

Thanks for the reviews!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19134#issuecomment-2109287761

From djelinski at openjdk.org  Tue May 14 05:04:06 2024
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Tue, 14 May 2024 05:04:06 GMT
Subject: Integrated: 8331907: BigInteger and BigDecimal should use optimized
 division
In-Reply-To: <-U6_9J-If3E3P3j4y7kt2yTCdNLvKkTSPrK0FxhNM80=.07321109-402b-4d28-9788-ddd52f42467d@github.com>
References: <-U6_9J-If3E3P3j4y7kt2yTCdNLvKkTSPrK0FxhNM80=.07321109-402b-4d28-9788-ddd52f42467d@github.com>
Message-ID: <7np9quLVVEj2ST-zUbgdNZ6y30rd10bdz_BwPPrfVvQ=.2b306c76-4e74-42f0-b662-bfd70e51cded@github.com>

On Wed, 8 May 2024 08:19:54 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> Replace the custom unsigned divide / remainder functions with the compiler-optimized Long.divideUnsigned / remainderUnsigned.
> 
> No new tests. Existing tier1-3 tests continue to pass.
> 
> I added a new set of divide benchmarks. Results in thread.
> 
> I also removed the BigDecimal.toString benchmarks. They no longer serve their purpose - toString caches the returned value, so we were only benchmarking the cache access time.

This pull request has now been integrated.

Changeset: beea5305
Author:    Daniel Jeli?ski <djelinski at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/beea5305b071820e2b128a55c5ca384caf470fdd
Stats:     219 lines in 4 files changed: 39 ins; 136 del; 44 mod

8331907: BigInteger and BigDecimal should use optimized division

Reviewed-by: rgiulietti, bpb

-------------

PR: https://git.openjdk.org/jdk/pull/19134

From stuefe at openjdk.org  Tue May 14 07:17:06 2024
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Tue, 14 May 2024 07:17:06 GMT
Subject: RFR: 8329581: Java launcher no longer prints a stack trace [v10]
In-Reply-To: <p1F-ic25cDHHveR547PzgWXLMlWBxtIzENjJfdi1b5M=.c2bd587f-c2f4-4375-9de7-e0bbebda6f9f@github.com>
References: <Z0pDMIc_XvZhcZdeFsIQUlqI17q5ybj0BnQ9Kl3jwxg=.8f981c46-a8a3-4520-a6e3-79ee7fce0253@github.com>
 <nFQS3JDegumTJOWSla6qGad04vc7PP7W3ZZ483XQuqs=.d28be017-00a0-44e0-9eee-bd70d56498e8@github.com>
 <nuC0ykeUPUGGaWUitqcQdw_N7ueOLFnFzm2JdtXSqbo=.6d3cdcd9-8ae1-406c-8a72-1dc25e1ed869@github.com>
 <p1F-ic25cDHHveR547PzgWXLMlWBxtIzENjJfdi1b5M=.c2bd587f-c2f4-4375-9de7-e0bbebda6f9f@github.com>
Message-ID: <cNAFlQ_sdO-dHlIScF0m2nTsGrUplOtmqg2KyG59fTQ=.738029f1-45e0-4118-b020-6e116c6c7c0a@github.com>

On Mon, 13 May 2024 18:01:25 GMT, Sonia Zaldana Calles <szaldana at openjdk.org> wrote:

> > This mostly looks good. I'm just puzzled CHECK_EXCEPTION_NULL_FAIL. The JNI functions GetStaticMethodID, GetMethodID and NewObject return NULL with a pending exception when they fail. So I would expect CHECK_EXCEPTION_NULL_FAIL to just check if obj is NULL rather check for an exception first. It's not wrong to check for an exception, just curious when looking at this macro.
> 
> Hi @AlanBateman, thanks for taking a look. That's a good point - would it be worthwhile to delete the exception check in this case?

Well, its not wrong, and arguably more defensive.

Doc for GetStaticMethodID states:


RETURNS:
Returns a method ID, or NULL if the operation fails.

THROWS:
NoSuchMethodError: if the specified static method cannot be found.
ExceptionInInitializerError: if the class initializer fails due to an exception.
OutOfMemoryError: if the system runs out of memory.


but it does not state explicitly that an exception is thrown on every error, or whether there are cases where the API can return NULL but not throw an exception, or vice versa.

So, I'd check for both. Or, if we think that both should not happen or happen together, assert that. (we can use the standard C assert in the JDK libraries, no?)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18786#issuecomment-2109450146

From alanb at openjdk.org  Tue May 14 07:43:03 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 14 May 2024 07:43:03 GMT
Subject: RFR: 8329581: Java launcher no longer prints a stack trace [v10]
In-Reply-To: <cNAFlQ_sdO-dHlIScF0m2nTsGrUplOtmqg2KyG59fTQ=.738029f1-45e0-4118-b020-6e116c6c7c0a@github.com>
References: <Z0pDMIc_XvZhcZdeFsIQUlqI17q5ybj0BnQ9Kl3jwxg=.8f981c46-a8a3-4520-a6e3-79ee7fce0253@github.com>
 <nFQS3JDegumTJOWSla6qGad04vc7PP7W3ZZ483XQuqs=.d28be017-00a0-44e0-9eee-bd70d56498e8@github.com>
 <nuC0ykeUPUGGaWUitqcQdw_N7ueOLFnFzm2JdtXSqbo=.6d3cdcd9-8ae1-406c-8a72-1dc25e1ed869@github.com>
 <p1F-ic25cDHHveR547PzgWXLMlWBxtIzENjJfdi1b5M=.c2bd587f-c2f4-4375-9de7-e0bbebda6f9f@github.com>
 <cNAFlQ_sdO-dHlIScF0m2nTsGrUplOtmqg2KyG59fTQ=.738029f1-45e0-4118-b020-6e116c6c7c0a@github.com>
Message-ID: <5THlJEgAxGYgOJkilK7GLzo79oqYf_rBS1iecPmDBmw=.ec1687c5-8a26-40cc-b899-908966a6e2ec@github.com>

On Tue, 14 May 2024 07:14:09 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> but it does not state explicitly that an exception is thrown on every error, or whether there are cases where the API can return NULL but not throw an exception, or vice versa.
> 
> So, I'd check for both. Or, if we think that both should not happen or happen together, assert that. (we can use the standard C assert in the JDK libraries, no?)

This same issue comes up periodically and maybe the JNI spec needs improvement to make it clearer that returning NULL means there is a pending exception/error. JNI would be very broken if it were to return a jclass or ID and also raise an exception, or return NULL rather than a jclass or ID when it succeeds.

As you say, it's not wrong to check both, just a bit strange as they can be just checks for NULL. At some point I think we need to do a round of cleanup here as these macros can mask other issues.



It's not wrong to first check for a first exception, just a bit strange and not immediately clear what issues they may be masking.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18786#issuecomment-2109495552

From alanb at openjdk.org  Tue May 14 07:44:02 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 14 May 2024 07:44:02 GMT
Subject: RFR: 8331987: Enhance stacktrace clarity for CompletableFuture
 CancellationException [v2]
In-Reply-To: <RwiMTpthY-AzuKJz7IESDRvEpp_yAA_HSsxMMHM42xM=.86290ec9-c841-4698-839c-eda03fa3fb03@github.com>
References: <JI-ghId-imtBqmNm850oQMNp-9p79tGMjfTRDdXz6D0=.fc134f86-914c-4484-9236-af162de3b99e@github.com>
 <RwiMTpthY-AzuKJz7IESDRvEpp_yAA_HSsxMMHM42xM=.86290ec9-c841-4698-839c-eda03fa3fb03@github.com>
Message-ID: <Q9SKKIIyUcGF_Z75-eq5MVeaJ0XVU4GWGeS9k9yxhnA=.e95e45b1-0cc9-40ce-8857-d09243b61ce9@github.com>

On Mon, 13 May 2024 23:59:17 GMT, Viktor Klang <vklang at openjdk.org> wrote:

>> This change adds wrapping of the CancellationException produced by CompletableFuture::get() and CompletableFuture::join() to add more diagnostic information and align better with FutureTask.
>> 
>> Running the sample code from the JBS issue in JShell will produce the following:
>> 
>> 
>> jshell> java.util.concurrent.CancellationException: 
>> 	at java.base/java.util.concurrent.CompletableFuture.reportGet(CompletableFuture.java:392)
>> 	at java.base/java.util.concurrent.CompletableFuture.get(CompletableFuture.java:2073)
>> 	at REPL.$JShell$18.m2($JShell$18.java:10)
>> 	at REPL.$JShell$17.m1($JShell$17.java:8)
>> 	at REPL.$JShell$16B.lambda$main$0($JShell$16B.java:8)
>> 	at java.base/java.lang.Thread.run(Thread.java:1575)
>> Caused by: java.util.concurrent.CancellationException
>> 	at java.base/java.util.concurrent.CompletableFuture.cancel(CompletableFuture.java:2510)
>> 	at REPL.$JShell$16B.lambda$main$1($JShell$16B.java:11)
>> 	... 1 more
>
> Viktor Klang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adding CancellationException detail message to CompletableFuture

Marked as reviewed by alanb (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/19219#pullrequestreview-2054530263

From asotona at openjdk.org  Tue May 14 08:25:05 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Tue, 14 May 2024 08:25:05 GMT
Subject: RFR: 8320396: Class-File API ClassModel::verify should include
 checks from hotspot/share/classfile/classFileParser.cpp [v5]
In-Reply-To: <DluFxuY08Xn3cCsQQbpU5Vf6nPNG_INI-YijaLoCWMo=.379392c4-c25f-423b-a2bf-bdbc49057bca@github.com>
References: <0a66asWcJ4_zBrjmReA18BZmsovN1ZeJRRSAPZDMZmo=.5bada03f-d88d-46cd-962d-c1e42c3048c1@github.com>
 <IXrF9AdBnUFrDOFKOrAsLZNJAOx05y4za-PoVzfIGpA=.80ed5ff3-d981-451e-90cc-ed65fa47f2b2@github.com>
 <xBWx767QKgWj2lrBApcqdsF-6w0_tjGq_7xdOIHTVts=.580047e5-aa12-40da-924b-284523cde17b@github.com>
 <KJEykNYhsRlrN11gIVpaVsJY-8rOYmFGhjDiwggBljc=.88396297-16cd-4899-88e2-0ed99e0b3d3f@github.com>
 <DluFxuY08Xn3cCsQQbpU5Vf6nPNG_INI-YijaLoCWMo=.379392c4-c25f-423b-a2bf-bdbc49057bca@github.com>
Message-ID: <Gs1IBwOVuSvsJa4ODQBenj6RjeOg2D8g6VnRqu-2te8=.b6a5c994-cfcc-49e3-9915-b1d5d54f1eb8@github.com>

On Mon, 13 May 2024 17:35:39 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Is this method only supposed to check the attribute size? It would be nice perhaps to enhance this to enforce more structural constraints - I added a couple of comments in that direction, but there's many more (e.g. for instance make sure that any entry that morally points to a class/method is of the right kind)
>
> Some of the checks don't verify the attributes point to valid cp entries; since CF API is lazy, those entries much be expanded by calling the accessors on Bound attributes.

Good point.
Constant pool consistency verification is already covered, however pointing to the right entries is not.
Touching all the attribute values will do the job.
Thanks!

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16809#discussion_r1599592698

From redestad at openjdk.org  Tue May 14 08:26:05 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Tue, 14 May 2024 08:26:05 GMT
Subject: RFR: 8331291: java.lang.classfile.Attributes class performs a lot
 of static initializations [v8]
In-Reply-To: <UielWbqtQPeaoAfpuHYPMzn8N6ViEH0T0h6WXHscUrk=.e4d333d7-6ae3-447f-9b5f-d0a77d29c416@github.com>
References: <SHIvjbwCWBPERKxlytEsY_O_kEiJbSeEmSusuDwjTIw=.ae8dd21e-a822-476e-9760-dd489532dbf1@github.com>
 <UielWbqtQPeaoAfpuHYPMzn8N6ViEH0T0h6WXHscUrk=.e4d333d7-6ae3-447f-9b5f-d0a77d29c416@github.com>
Message-ID: <L7Wg46wRNI3kv9XELZ-8XNC1YlRZRwU1Vdr5vwxOaM0=.c634a5dd-a801-488e-b020-3cf0335d62ed@github.com>

On Mon, 6 May 2024 18:24:25 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> Hi,
>> During performance optimization work on Class-File API as JDK lambda generator we found some static initialization killers.
>> One of them is `java.lang.classfile.Attributes` with tens of static fields initialized with individual attribute mappers, and common set of all mappers, and static map from attribute names to the mappers.
>> 
>> I propose to turn all the static fields into lazy-initialized static methods and remove `PREDEFINED_ATTRIBUTES` and `standardAttribute(Utf8Entry name)` static mapping method from the `Attributes` API class.
>>  
>> Please let me know your comments or objections and please review the [PR](https://github.com/openjdk/jdk/pull/19006) and [CSR](https://bugs.openjdk.org/browse/JDK-8331414), so we can make it into 23.
>> 
>> Thank you,
>> Adam
>
> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fixed tests

Thank you for this!

-------------

Marked as reviewed by redestad (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19006#pullrequestreview-2054638558

From abimpoudis at openjdk.org  Tue May 14 08:34:04 2024
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Tue, 14 May 2024 08:34:04 GMT
Subject: RFR: 8320396: Class-File API ClassModel::verify should include
 checks from hotspot/share/classfile/classFileParser.cpp [v5]
In-Reply-To: <IXrF9AdBnUFrDOFKOrAsLZNJAOx05y4za-PoVzfIGpA=.80ed5ff3-d981-451e-90cc-ed65fa47f2b2@github.com>
References: <0a66asWcJ4_zBrjmReA18BZmsovN1ZeJRRSAPZDMZmo=.5bada03f-d88d-46cd-962d-c1e42c3048c1@github.com>
 <IXrF9AdBnUFrDOFKOrAsLZNJAOx05y4za-PoVzfIGpA=.80ed5ff3-d981-451e-90cc-ed65fa47f2b2@github.com>
Message-ID: <KCZcgNF-a6bolQDFv3kH4Z14mhVdeN_8Ni9qlsJMHRk=.26033834-0604-4fda-a2a6-d0361e4ffe13@github.com>

On Thu, 9 May 2024 10:11:22 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> ClassFile API `jdk.internal.classfile.verifier.VerifierImpl` performed only bytecode-level class verification.
>> This patch adds `jdk.internal.classfile.verifier.ParserVerifier` with additional class checks inspired by `hotspot/share/classfile/classFileParser.cpp`.
>> 
>> Also new `VerifierSelfTest::testParserVerifier` has been added.
>> 
>> Please review.
>> 
>> Thanks,
>> Adam
>
> Adam Sotona has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - fixed error thrown by VerifierImpl
>  - applied suggested changes

src/java.base/share/classes/jdk/internal/classfile/impl/verifier/ParserVerifier.java line 223:

> 221:                     errors.add(new VerifyError("Arguments can't fit into locals in %s".formatted(toString(ae))));
> 222:                 }
> 223:                 int l = 12 + ca.codeLength() + 8 * ca.exceptionHandlers().size();

nit (or not): it would be amazing if all these constants have a name. They are almost intuitive, I admit, but it would improve readability a lot.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16809#discussion_r1599604770

From redestad at openjdk.org  Tue May 14 08:51:02 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Tue, 14 May 2024 08:51:02 GMT
Subject: RFR: 8331724: Refactor j.l.constant implementation to internal
 package [v7]
In-Reply-To: <-R0uRVBFsj_iZmqCMJTUL0weCsL6st9ezZdKnv7gFIU=.a0ed3258-7812-4ded-a1ee-e971bec8d4da@github.com>
References: <_GPUF9d1E6eBKRxP6bEEqA3LSKRJe2GwCRTfVYbDwFU=.cb482785-e7c4-45f7-bd3a-cd32d466a2cb@github.com>
 <-R0uRVBFsj_iZmqCMJTUL0weCsL6st9ezZdKnv7gFIU=.a0ed3258-7812-4ded-a1ee-e971bec8d4da@github.com>
Message-ID: <_j3ao7ZY5lHtPd_ktt1D83axzmrmkiKIYHB7bepNh14=.704bf581-51c0-4d97-941f-b2982ffe3429@github.com>

On Fri, 10 May 2024 08:50:07 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> This PR suggests refactoring the implementation classes of java.lang.constant into a new package jdk.internal.constant to enable sharing some trusted static factory methods with users elsewhere in java.base, such as java.lang.invoke and java.lang.classfile. The refactoring also adds some "trusted" methods for use when input is pre-validated, and makes use of them where applicable in the current implementation. There are more changes in the pipeline which will be folded into #17108 or PR'ed once that is integrated. 
>> 
>> There are two optimizations mixed up here. One in `MethodTypeDesc.ofDescriptor`:
>> 
>> Name                                                             (descString) Cnt     Base     Error      Test   Error  Unit  Change
>> MethodTypeDescFactories.ofDescriptor  (Ljava/lang/Object;Ljava/lang/String;)I   6  138,371 ?   0,767   136,939 ? 1,126 ns/op   1,01x (p = 0,000*)
>> MethodTypeDescFactories.ofDescriptor                                      ()V   6   10,528 ?   2,495     4,110 ? 0,047 ns/op   2,56x (p = 0,000*)
>> MethodTypeDescFactories.ofDescriptor ([IJLjava/lang/String;Z)Ljava/util/List;   6  209,390 ?   4,583   196,175 ? 3,211 ns/op   1,07x (p = 0,000*)
>> MethodTypeDescFactories.ofDescriptor                    ()[Ljava/lang/String;   6   36,039 ?   8,684    20,794 ? 1,110 ns/op   1,73x (p = 0,000*)
>> MethodTypeDescFactories.ofDescriptor                                 (..IIJ)V   6  279,139 ?   6,248   187,934 ? 0,857 ns/op   1,49x (p = 0,000*)
>> MethodTypeDescFactories.ofDescriptor                 (.....................).   6 2174,387 ? 132,879  1150,652 ? 3,158 ns/op   1,89x (p = 0,000*)
>>   * = significant
>> 
>> 
>> The other in `ClassDesc::nested`, where to get rid of a simple static method in `ConstantUtils` I ended up speeding up and simplifying the public factory method:
>> 
>> Name                                      Cnt    Base     Error    Test   Error  Unit  Change
>> ClassDescFactories.ReferenceOnly.ofNested   6 209,853 ? 132,525  22,017 ? 0,573 ns/op   9,53x (p = 0,000*)
>>   * = significant
>> 
>> 
>> The optimizations could be split out and PRd independently, but I think they are simple enough to include in this refactoring.
>
> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update src/java.base/share/classes/jdk/internal/constant/MethodTypeDescImpl.java
>   
>   Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com>

Gentle reminder that this needs a Reviewer.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19105#issuecomment-2109626820

From abimpoudis at openjdk.org  Tue May 14 08:55:04 2024
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Tue, 14 May 2024 08:55:04 GMT
Subject: RFR: 8320396: Class-File API ClassModel::verify should include
 checks from hotspot/share/classfile/classFileParser.cpp [v5]
In-Reply-To: <IXrF9AdBnUFrDOFKOrAsLZNJAOx05y4za-PoVzfIGpA=.80ed5ff3-d981-451e-90cc-ed65fa47f2b2@github.com>
References: <0a66asWcJ4_zBrjmReA18BZmsovN1ZeJRRSAPZDMZmo=.5bada03f-d88d-46cd-962d-c1e42c3048c1@github.com>
 <IXrF9AdBnUFrDOFKOrAsLZNJAOx05y4za-PoVzfIGpA=.80ed5ff3-d981-451e-90cc-ed65fa47f2b2@github.com>
Message-ID: <uFtuSu8G_8hP1g07IBy5BUz-VUQh_afKagwthLmN-PE=.dfaad4d5-6601-4656-8b9f-bf66488da290@github.com>

On Thu, 9 May 2024 10:11:22 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> ClassFile API `jdk.internal.classfile.verifier.VerifierImpl` performed only bytecode-level class verification.
>> This patch adds `jdk.internal.classfile.verifier.ParserVerifier` with additional class checks inspired by `hotspot/share/classfile/classFileParser.cpp`.
>> 
>> Also new `VerifierSelfTest::testParserVerifier` has been added.
>> 
>> Please review.
>> 
>> Thanks,
>> Adam
>
> Adam Sotona has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - fixed error thrown by VerifierImpl
>  - applied suggested changes

src/java.base/share/classes/jdk/internal/classfile/impl/verifier/ParserVerifier.java line 251:

> 249:                 for (var ici : ica.classes()) {
> 250:                     if (ici.outerClass().isPresent() && ici.outerClass().get().equals(ici.innerClass())) {
> 251:                         errors.add(new VerifyError("Class is both outer and inner class in %s".formatted(toString(ae))));

nit: in `classFileParser` the string includes "class file" after "in". I was just wondering if "class file" is generated by `toString`. I see only `default -> "class " + className();` in the implementation of `toString`. Ignore if the actual message is not important.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16809#discussion_r1599635651

From asotona at openjdk.org  Tue May 14 09:11:04 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Tue, 14 May 2024 09:11:04 GMT
Subject: RFR: 8320396: Class-File API ClassModel::verify should include
 checks from hotspot/share/classfile/classFileParser.cpp [v5]
In-Reply-To: <KCZcgNF-a6bolQDFv3kH4Z14mhVdeN_8Ni9qlsJMHRk=.26033834-0604-4fda-a2a6-d0361e4ffe13@github.com>
References: <0a66asWcJ4_zBrjmReA18BZmsovN1ZeJRRSAPZDMZmo=.5bada03f-d88d-46cd-962d-c1e42c3048c1@github.com>
 <IXrF9AdBnUFrDOFKOrAsLZNJAOx05y4za-PoVzfIGpA=.80ed5ff3-d981-451e-90cc-ed65fa47f2b2@github.com>
 <KCZcgNF-a6bolQDFv3kH4Z14mhVdeN_8Ni9qlsJMHRk=.26033834-0604-4fda-a2a6-d0361e4ffe13@github.com>
Message-ID: <pG9m1QOtFPOwjyJ2zcEbDAn_7FLw66z6Al1Mj69GnSE=.08d2485f-4843-40cf-b5b4-63cd73b83776@github.com>

On Tue, 14 May 2024 08:30:56 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

>> Adam Sotona has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - fixed error thrown by VerifierImpl
>>  - applied suggested changes
>
> src/java.base/share/classes/jdk/internal/classfile/impl/verifier/ParserVerifier.java line 223:
> 
>> 221:                     errors.add(new VerifyError("Arguments can't fit into locals in %s".formatted(toString(ae))));
>> 222:                 }
>> 223:                 int l = 12 + ca.codeLength() + 8 * ca.exceptionHandlers().size();
> 
> nit (or not): it would be amazing if all these constants have a name. They are almost intuitive, I admit, but it would improve readability a lot.

I think about the readability exactly opposite. When deciding between:

static final int CODE_ATTRIBUTE_HEADER_SIZE = 12;
static final int CODE_ATTRIBUTE_EXCEPTION_HANDLER_ENTRY_SIZE = 8;

...

int l = CODE_ATTRIBUTE_HEADER_SIZE + ca.codeLength() + CODE_ATTRIBUTE_EXCEPTION_HANDLER_ENTRY_SIZE * ca.exceptionHandlers().size();

or

int l = 12 + ca.codeLength() + 8 * ca.exceptionHandlers().size();

For this specific case ( implementation transcription of `classFileParser.cpp`) I prefer the shorter.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16809#discussion_r1599666623

From asotona at openjdk.org  Tue May 14 09:18:03 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Tue, 14 May 2024 09:18:03 GMT
Subject: RFR: 8320396: Class-File API ClassModel::verify should include
 checks from hotspot/share/classfile/classFileParser.cpp [v5]
In-Reply-To: <uFtuSu8G_8hP1g07IBy5BUz-VUQh_afKagwthLmN-PE=.dfaad4d5-6601-4656-8b9f-bf66488da290@github.com>
References: <0a66asWcJ4_zBrjmReA18BZmsovN1ZeJRRSAPZDMZmo=.5bada03f-d88d-46cd-962d-c1e42c3048c1@github.com>
 <IXrF9AdBnUFrDOFKOrAsLZNJAOx05y4za-PoVzfIGpA=.80ed5ff3-d981-451e-90cc-ed65fa47f2b2@github.com>
 <uFtuSu8G_8hP1g07IBy5BUz-VUQh_afKagwthLmN-PE=.dfaad4d5-6601-4656-8b9f-bf66488da290@github.com>
Message-ID: <qsch4Zn7pmCEbr20kMGQOjJsG-bTfIaFCEDSMokxcbc=.f08eac1f-fcd1-4a3c-be3b-c1266f1fad74@github.com>

On Tue, 14 May 2024 08:51:57 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

>> Adam Sotona has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - fixed error thrown by VerifierImpl
>>  - applied suggested changes
>
> src/java.base/share/classes/jdk/internal/classfile/impl/verifier/ParserVerifier.java line 251:
> 
>> 249:                 for (var ici : ica.classes()) {
>> 250:                     if (ici.outerClass().isPresent() && ici.outerClass().get().equals(ici.innerClass())) {
>> 251:                         errors.add(new VerifyError("Class is both outer and inner class in %s".formatted(toString(ae))));
> 
> nit: in `classFileParser` the string includes "class file" after "in". I was just wondering if "class file" is generated by `toString`. I see only `default -> "class " + className();` in the implementation of `toString`. Ignore if the actual message is not important.

The `AttributedElement` argument only adds specific info about the enclosing element, so for the class-level attribute errors it falls to the default. Your can se examples of this formatting  in the test:
https://github.com/openjdk/jdk/blob/586fa4b3241a0fc9a2aeddc41d79a74f2259ae52/test/jdk/jdk/classfile/VerifierSelfTest.java#L177

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16809#discussion_r1599676802

From asotona at openjdk.org  Tue May 14 09:22:04 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Tue, 14 May 2024 09:22:04 GMT
Subject: RFR: 8320396: Class-File API ClassModel::verify should include
 checks from hotspot/share/classfile/classFileParser.cpp [v5]
In-Reply-To: <xBWx767QKgWj2lrBApcqdsF-6w0_tjGq_7xdOIHTVts=.580047e5-aa12-40da-924b-284523cde17b@github.com>
References: <0a66asWcJ4_zBrjmReA18BZmsovN1ZeJRRSAPZDMZmo=.5bada03f-d88d-46cd-962d-c1e42c3048c1@github.com>
 <IXrF9AdBnUFrDOFKOrAsLZNJAOx05y4za-PoVzfIGpA=.80ed5ff3-d981-451e-90cc-ed65fa47f2b2@github.com>
 <xBWx767QKgWj2lrBApcqdsF-6w0_tjGq_7xdOIHTVts=.580047e5-aa12-40da-924b-284523cde17b@github.com>
Message-ID: <PGqKi8HmTDzORzqzBOb-PyzPiq0ZQ02ZtTIS4mnmRJs=.6f3a39b9-a309-49b2-97dc-38d7d2e11e3a@github.com>

On Mon, 13 May 2024 17:17:40 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Adam Sotona has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - fixed error thrown by VerifierImpl
>>  - applied suggested changes
>
> src/java.base/share/classes/jdk/internal/classfile/impl/verifier/ParserVerifier.java line 283:
> 
>> 281:                 yield l;
>> 282:             }
>> 283:             case RuntimeVisibleAnnotationsAttribute aa -> {
> 
> I wonder if these 4 cases can be consolidated a bit. They all require an annotation accessor, and then something that keeps computes the size of all the annotations. E.g.
> 
> 
> int annotationSize(List<Annotation> annos) {
>                 long size = 0;
>                 for (var an : annos) {
>                     size += annotationSize(an);
>                 }
>                 return l;
> }

Yes, I'll join them to a common method.
Thanks.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16809#discussion_r1599681157

From prappo at openjdk.org  Tue May 14 10:01:02 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Tue, 14 May 2024 10:01:02 GMT
Subject: RFR: 8332084: Ensure JdkConsoleImpl.restoreEcho visibility in a
 shutdown hook [v3]
In-Reply-To: <rMn4swvTo6iF-603_7a_kteWOX-wmSR0fNhlpqtNw88=.17a91580-c3ed-4c95-b314-2b82f792b60c@github.com>
References: <9JTWc3FRpfbILlSHlmIU_dL5IE69RTxnSIAOdIte15I=.5854a48f-21d7-42c9-adb7-5e3ed40d1211@github.com>
 <lLPvzpLD8otrOuchognaYtSQQu75txoPpHGlZVJ7qhY=.6c8f9c14-e22a-496e-a55a-f40676b95a9a@github.com>
 <rMn4swvTo6iF-603_7a_kteWOX-wmSR0fNhlpqtNw88=.17a91580-c3ed-4c95-b314-2b82f792b60c@github.com>
Message-ID: <YH3C2pATUg6wsBnlrqNjxA-rxnOn77KqgVdRCCo3SgI=.266a4036-5d46-4165-9cc4-792e0529329d@github.com>

On Mon, 13 May 2024 21:14:26 GMT, Stuart Marks <smarks at openjdk.org> wrote:

> Hm, I don't think we want to add any synchronized blocks within a shutdown hook. If a thread is blocked reading from the console, it will hold readLock; if the JVM is then shut down using a signal, it will run shutdown hooks, and this hook will block awaiting readLock. This can deadlock the shutdown completely.
> 
> To ensure proper memory visibility, maybe consider making `restoreEcho` be volatile.

It turns out it's not that hard to imagine. Thanks for helping me imagine it, Stuart.

I think that we should add the most straightforward test to demonstrate that the `restoreEcho` logic (or the lack of it) has an observable effect. If we fail to do that, it might mean that the `restoreEcho` logic is not needed and that the rest of this message is probably irrelevant.

The test should be added not in a separate PR for [8332161] -- a bug which Naoto has just filed -- but in this PR, and then we should `/issue add 8332161`. 

Since we now have established that [concurrency] is possible, we should find an adequate concurrent solution. I can imagine that the proposed `volatile`-based solution may fall short in the following scenario.

Thread 1 reaches the line marked by `*`. Let's assume that immediately before executing that line `restoreEcho` is `false` and echo is on:


public char[] readPassword(String fmt, Object ... args) {
    char[] passwd = null;
    synchronized (writeLock) {
        synchronized(readLock) {
            installShutdownHook();
            try {
                restoreEcho = echo(false); // *
            } catch (IOException x) {
                throw new IOError(x);
            }
            IOError ioe = null;
            try {
                if (!fmt.isEmpty())
                    pw.format(fmt, args);
                passwd = readline(true);
            } catch (IOException x) {
                ioe = new IOError(x);
            } finally {
                try {
                    if (restoreEcho) // **
                        restoreEcho = echo(true);
                } catch (IOException x) {
            ...


Thread 1 executes `echo(false)`, which returns `true`. `true` is not yet written into `restoreEcho`.

Meanwhile, thread 2 (the hook thread) is about to execute the line marked by `***`:


public void run() {
    try {
        if (restoreEcho) { // ***
            echo(true);
        }
    } catch (IOException x) { }
}


Thread 2 sees `restoreEcho` is `false` and skips `echo(true)`. If thread 1 then ceases to exist (remember, we're shutting down) before it reaches the line marked by `**`in the `finally` block, the console echo will remain off.

[8332161]: https://bugs.openjdk.org/browse/JDK-8332161
[concurrency]: https://docs.oracle.com/en/java/javase/22/docs/api/java.base/java/lang/Runtime.html#shutdown

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19184#issuecomment-2109779741

From asotona at openjdk.org  Tue May 14 11:11:03 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Tue, 14 May 2024 11:11:03 GMT
Subject: RFR: 8320396: Class-File API ClassModel::verify should include
 checks from hotspot/share/classfile/classFileParser.cpp [v5]
In-Reply-To: <xBWx767QKgWj2lrBApcqdsF-6w0_tjGq_7xdOIHTVts=.580047e5-aa12-40da-924b-284523cde17b@github.com>
References: <0a66asWcJ4_zBrjmReA18BZmsovN1ZeJRRSAPZDMZmo=.5bada03f-d88d-46cd-962d-c1e42c3048c1@github.com>
 <IXrF9AdBnUFrDOFKOrAsLZNJAOx05y4za-PoVzfIGpA=.80ed5ff3-d981-451e-90cc-ed65fa47f2b2@github.com>
 <xBWx767QKgWj2lrBApcqdsF-6w0_tjGq_7xdOIHTVts=.580047e5-aa12-40da-924b-284523cde17b@github.com>
Message-ID: <pRBqZDbcCnoEZOBKWWhM3Hgsv2NSiYUZGGGAM6A0fx8=.d71561f5-e1eb-4ef2-90dc-165deff15854@github.com>

On Mon, 13 May 2024 17:21:03 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Adam Sotona has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - fixed error thrown by VerifierImpl
>>  - applied suggested changes
>
> src/java.base/share/classes/jdk/internal/classfile/impl/verifier/ParserVerifier.java line 246:
> 
>> 244:             }
>> 245:             case DeprecatedAttribute da -> 0;
>> 246:             case EnclosingMethodAttribute ema -> 4;
> 
> See 4.7.7:
>> Otherwise, the value of the method_index item must be a valid index into the constant_pool table. The constant_pool entry at that index must be a CONSTANT_NameAndType_info structure ([?4.4.6](https://docs.oracle.com/javase/specs/jvms/se22/html/jvms-4.html#jvms-4.4.6)) representing the name and type of a method in the class referenced by the class_index attribute above.

Yes, I'll inflate CP entries referenced from the attributes, that will do the verification.
Thanks.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16809#discussion_r1599828385

From asotona at openjdk.org  Tue May 14 11:14:04 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Tue, 14 May 2024 11:14:04 GMT
Subject: RFR: 8320396: Class-File API ClassModel::verify should include
 checks from hotspot/share/classfile/classFileParser.cpp [v5]
In-Reply-To: <xBWx767QKgWj2lrBApcqdsF-6w0_tjGq_7xdOIHTVts=.580047e5-aa12-40da-924b-284523cde17b@github.com>
References: <0a66asWcJ4_zBrjmReA18BZmsovN1ZeJRRSAPZDMZmo=.5bada03f-d88d-46cd-962d-c1e42c3048c1@github.com>
 <IXrF9AdBnUFrDOFKOrAsLZNJAOx05y4za-PoVzfIGpA=.80ed5ff3-d981-451e-90cc-ed65fa47f2b2@github.com>
 <xBWx767QKgWj2lrBApcqdsF-6w0_tjGq_7xdOIHTVts=.580047e5-aa12-40da-924b-284523cde17b@github.com>
Message-ID: <bofqMNQMBbVBJS1YssBP1zermm8GIHdJ4RfNhowPF2A=.d09c885b-ac2c-43ab-b651-7bf1bcf1e1c7@github.com>

On Mon, 13 May 2024 17:22:07 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Adam Sotona has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - fixed error thrown by VerifierImpl
>>  - applied suggested changes
>
> src/java.base/share/classes/jdk/internal/classfile/impl/verifier/ParserVerifier.java line 247:
> 
>> 245:             case DeprecatedAttribute da -> 0;
>> 246:             case EnclosingMethodAttribute ema -> 4;
>> 247:             case ExceptionsAttribute ea -> 2 + 2 * ea.exceptions().size();
> 
> See 4.7.5:
>> Each value in the exception_index_table array must be a valid index into the constant_pool table. The constant_pool entry at that index must be a CONSTANT_Class_info structure ([?4.4.1](https://docs.oracle.com/javase/specs/jvms/se22/html/jvms-4.html#jvms-4.4.1)) representing a class type that this method is declared to throw.

CP entries are verified by inflation in the `ea.exceptions()` call.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16809#discussion_r1599832116

From asotona at openjdk.org  Tue May 14 11:17:03 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Tue, 14 May 2024 11:17:03 GMT
Subject: RFR: 8320396: Class-File API ClassModel::verify should include
 checks from hotspot/share/classfile/classFileParser.cpp [v5]
In-Reply-To: <ICUFXY8P2RSJ7wh2KtPB1J2ARulmYGcbGyo6OALX9w8=.6df6d413-5722-4f28-a2d8-1f165a34d485@github.com>
References: <0a66asWcJ4_zBrjmReA18BZmsovN1ZeJRRSAPZDMZmo=.5bada03f-d88d-46cd-962d-c1e42c3048c1@github.com>
 <IXrF9AdBnUFrDOFKOrAsLZNJAOx05y4za-PoVzfIGpA=.80ed5ff3-d981-451e-90cc-ed65fa47f2b2@github.com>
 <ICUFXY8P2RSJ7wh2KtPB1J2ARulmYGcbGyo6OALX9w8=.6df6d413-5722-4f28-a2d8-1f165a34d485@github.com>
Message-ID: <lUn7Zqp6PovRpNmwbS9s4wsXXhzzlmbY4e-NtZ52we4=.5de02902-c25f-4643-b413-d47b777924e0@github.com>

On Mon, 13 May 2024 17:31:25 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Adam Sotona has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - fixed error thrown by VerifierImpl
>>  - applied suggested changes
>
> src/java.base/share/classes/jdk/internal/classfile/impl/verifier/ParserVerifier.java line 233:
> 
>> 231:                 ClassDesc type = ((FieldModel)ae).fieldTypeSymbol();
>> 232:                 ConstantValueEntry cve = cva.constant();
>> 233:                 if (!switch (TypeKind.from(type)) {
> 
> Weird-looking switch

It may be (and actually was) composed into a single boolean expression, however effectivity and readability was worse. Boolean switch expression across Enum seems to me effective and clear to read.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16809#discussion_r1599842678

From dfuchs at openjdk.org  Tue May 14 11:22:04 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 14 May 2024 11:22:04 GMT
Subject: RFR: 8332086: Remove the usage of ServiceLoader in
 j.u.r.RandomGeneratorFactory
In-Reply-To: <7AgEgplJ6-4H2jbXSdIWoNCk_90A_oA86sKoPhbVx1g=.8aaa1e39-04db-4731-a8be-9a53ff994102@github.com>
References: <hfB86NksORc-aC6zVxHel_QQd_9aB629SfQjXvl6q5U=.e31daa4b-5cf6-4f3f-a757-79e818a18978@github.com>
 <mH_LU2mwBmn13nuF039baoqq2ibSbmqct0WFxhVv1vg=.b904990f-e389-4c81-9d19-2b9d8ca35e99@github.com>
 <Qi40QQbVUG444KUJxqWVjKaHj5-X53SiFmXPhI99Iho=.a0f56e95-41bf-4d54-9e76-951f1535b698@github.com>
 <DfnK-PUg49spHSshZ_W_LHPX4tDnW3xHpm_LHT-WPcc=.c591d07c-481a-4f58-b9f8-aeff4399b25b@github.com>
 <sHUoeBI2PVWqN20vm9bwn4jSA9YoBgrv3Mizp6ahB2A=.922696a0-9322-4359-984b-72872b3b2fec@github.com>
 <WTK_r-lXJnTZBOBYqYogrrDrvwh78Jtf_scpcCj29Bs=.f38f8fd6-9bfb-4a80-81f8-2a807fab5a63@github.com>
 <bW7PoG7haLsVgI4aavzO94m5JEWI7_JWR3T_2GrC71Q=.ea2b6e57-5822-452c-9ac2-e15fd6dd8854@github.com>
 <7AgEgplJ6-4H2jbXSdIWoNCk_90A_oA86sKoPhbVx1g=.8aaa1e39-04db-4731-a8be-9a53ff994102@github.com>
Message-ID: <_yMsYvaTgVcioCl-sOkuy_Jwc9_WwnSTOov1DNklzJg=.b9870a7a-0998-4518-b456-3f07b6ad5783@github.com>

On Mon, 13 May 2024 17:12:33 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> Not sure if that's an issue - but if you wanted/needed to delay the loading of those random generator classes that will not be used until something actually wants to use them, you could consider using a `Supplier<Class<? extends RandomGenerator>>` or a `Supplier<RandomGenEntry>` for the `FACTORY_MAP` values?
>
> @dfuch You mean not loading the whole batch but only individual classes, as need arises?

yes - I do not know if loading all the classes in one batch could be an issue at startup (I'd expect Random to be loaded early) - but if it proves to be, then using a Supplier to load them on demand might do the trick. If creating Random or SecureRandom does not trigger this code - and if those classes are not loaded at startup - then maybe that's a non issue and you can just ignore my comment.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19212#discussion_r1599847940

From asotona at openjdk.org  Tue May 14 11:42:19 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Tue, 14 May 2024 11:42:19 GMT
Subject: RFR: 8320396: Class-File API ClassModel::verify should include
 checks from hotspot/share/classfile/classFileParser.cpp [v6]
In-Reply-To: <0a66asWcJ4_zBrjmReA18BZmsovN1ZeJRRSAPZDMZmo=.5bada03f-d88d-46cd-962d-c1e42c3048c1@github.com>
References: <0a66asWcJ4_zBrjmReA18BZmsovN1ZeJRRSAPZDMZmo=.5bada03f-d88d-46cd-962d-c1e42c3048c1@github.com>
Message-ID: <HCwLBI-iyD3eCNWhKURiBboVhDwlpyBxPUL3Mur7UJc=.09225151-1960-4e45-80f9-977006b18a3d@github.com>

> ClassFile API `jdk.internal.classfile.verifier.VerifierImpl` performed only bytecode-level class verification.
> This patch adds `jdk.internal.classfile.verifier.ParserVerifier` with additional class checks inspired by `hotspot/share/classfile/classFileParser.cpp`.
> 
> Also new `VerifierSelfTest::testParserVerifier` has been added.
> 
> Please review.
> 
> Thanks,
> Adam

Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:

  applied the suggested changes

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/16809/files
  - new: https://git.openjdk.org/jdk/pull/16809/files/586fa4b3..9257b7ea

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16809&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16809&range=04-05

  Stats: 109 lines in 1 file changed: 49 ins; 31 del; 29 mod
  Patch: https://git.openjdk.org/jdk/pull/16809.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16809/head:pull/16809

PR: https://git.openjdk.org/jdk/pull/16809

From rgiulietti at openjdk.org  Tue May 14 12:08:03 2024
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Tue, 14 May 2024 12:08:03 GMT
Subject: RFR: 8332086: Remove the usage of ServiceLoader in
 j.u.r.RandomGeneratorFactory
In-Reply-To: <_yMsYvaTgVcioCl-sOkuy_Jwc9_WwnSTOov1DNklzJg=.b9870a7a-0998-4518-b456-3f07b6ad5783@github.com>
References: <hfB86NksORc-aC6zVxHel_QQd_9aB629SfQjXvl6q5U=.e31daa4b-5cf6-4f3f-a757-79e818a18978@github.com>
 <mH_LU2mwBmn13nuF039baoqq2ibSbmqct0WFxhVv1vg=.b904990f-e389-4c81-9d19-2b9d8ca35e99@github.com>
 <Qi40QQbVUG444KUJxqWVjKaHj5-X53SiFmXPhI99Iho=.a0f56e95-41bf-4d54-9e76-951f1535b698@github.com>
 <DfnK-PUg49spHSshZ_W_LHPX4tDnW3xHpm_LHT-WPcc=.c591d07c-481a-4f58-b9f8-aeff4399b25b@github.com>
 <sHUoeBI2PVWqN20vm9bwn4jSA9YoBgrv3Mizp6ahB2A=.922696a0-9322-4359-984b-72872b3b2fec@github.com>
 <WTK_r-lXJnTZBOBYqYogrrDrvwh78Jtf_scpcCj29Bs=.f38f8fd6-9bfb-4a80-81f8-2a807fab5a63@github.com>
 <bW7PoG7haLsVgI4aavzO94m5JEWI7_JWR3T_2GrC71Q=.ea2b6e57-5822-452c-9ac2-e15fd6dd8854@github.com>
 <7AgEgplJ6-4H2jbXSdIWoNCk_90A_oA86sKoPhbVx1g=.8aaa1e39-04db-4731-a8be-9a53ff994102@github.com>
 <_yMsYvaTgVcioCl-sOkuy_Jwc9_WwnSTOov1DNklzJg=.b9870a7a-0998-4518-b456-3f07b6ad5783@github.com>
Message-ID: <lLrV3JaaQmi-TSkLKZntwU2QW1ab-rCBydpdKLNF0O8=.7563043b-6efb-4ddb-a0f0-73959de2b7b3@github.com>

On Tue, 14 May 2024 11:19:36 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> @dfuch You mean not loading the whole batch but only individual classes, as need arises?
>
> yes - I do not know if loading all the classes in one batch could be an issue at startup (I'd expect Random to be loaded early) - but if it proves to be, then using a Supplier to load them on demand might do the trick. If creating Random or SecureRandom does not trigger this code - and if those classes are not loaded at startup - then maybe that's a non issue and you can just ignore my comment.

Loading of `Random`, `SecureRandom`, `SplittableRandom`, or `ThreadLocalRandom` does not trigger the loading of `RandomGeneratorFactory`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19212#discussion_r1599904324

From redestad at openjdk.org  Tue May 14 12:09:45 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Tue, 14 May 2024 12:09:45 GMT
Subject: RFR: 8331724: Refactor j.l.constant implementation to internal
 package [v8]
In-Reply-To: <_GPUF9d1E6eBKRxP6bEEqA3LSKRJe2GwCRTfVYbDwFU=.cb482785-e7c4-45f7-bd3a-cd32d466a2cb@github.com>
References: <_GPUF9d1E6eBKRxP6bEEqA3LSKRJe2GwCRTfVYbDwFU=.cb482785-e7c4-45f7-bd3a-cd32d466a2cb@github.com>
Message-ID: <R_QQxz28RxPXLN_f9v5kKYhdwS-xYpbfYhY5nSLSk5g=.4317a534-b381-45b9-afbe-607143e6b2b8@github.com>

> This PR suggests refactoring the implementation classes of java.lang.constant into a new package jdk.internal.constant to enable sharing some trusted static factory methods with users elsewhere in java.base, such as java.lang.invoke and java.lang.classfile. The refactoring also adds some "trusted" methods for use when input is pre-validated, and makes use of them where applicable in the current implementation. There are more changes in the pipeline which will be folded into #17108 or PR'ed once that is integrated. 
> 
> There are two optimizations mixed up here. One in `MethodTypeDesc.ofDescriptor`:
> 
> Name                                                             (descString) Cnt     Base     Error      Test   Error  Unit  Change
> MethodTypeDescFactories.ofDescriptor  (Ljava/lang/Object;Ljava/lang/String;)I   6  138,371 ?   0,767   136,939 ? 1,126 ns/op   1,01x (p = 0,000*)
> MethodTypeDescFactories.ofDescriptor                                      ()V   6   10,528 ?   2,495     4,110 ? 0,047 ns/op   2,56x (p = 0,000*)
> MethodTypeDescFactories.ofDescriptor ([IJLjava/lang/String;Z)Ljava/util/List;   6  209,390 ?   4,583   196,175 ? 3,211 ns/op   1,07x (p = 0,000*)
> MethodTypeDescFactories.ofDescriptor                    ()[Ljava/lang/String;   6   36,039 ?   8,684    20,794 ? 1,110 ns/op   1,73x (p = 0,000*)
> MethodTypeDescFactories.ofDescriptor                                 (..IIJ)V   6  279,139 ?   6,248   187,934 ? 0,857 ns/op   1,49x (p = 0,000*)
> MethodTypeDescFactories.ofDescriptor                 (.....................).   6 2174,387 ? 132,879  1150,652 ? 3,158 ns/op   1,89x (p = 0,000*)
>   * = significant
> 
> 
> The other in `ClassDesc::nested`, where to get rid of a simple static method in `ConstantUtils` I ended up speeding up and simplifying the public factory method:
> 
> Name                                      Cnt    Base     Error    Test   Error  Unit  Change
> ClassDescFactories.ReferenceOnly.ofNested   6 209,853 ? 132,525  22,017 ? 0,573 ns/op   9,53x (p = 0,000*)
>   * = significant
> 
> 
> The optimizations could be split out and PRd independently, but I think they are simple enough to include in this refactoring.

Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:

  Weed out redundant null-checks, clarify javadoc of internal static utilities

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19105/files
  - new: https://git.openjdk.org/jdk/pull/19105/files/5af9de09..e2d7b59d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19105&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19105&range=06-07

  Stats: 8 lines in 2 files changed: 3 ins; 1 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/19105.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19105/head:pull/19105

PR: https://git.openjdk.org/jdk/pull/19105

From rgiulietti at openjdk.org  Tue May 14 13:00:28 2024
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Tue, 14 May 2024 13:00:28 GMT
Subject: RFR: 8332086: Remove the usage of ServiceLoader in
 j.u.r.RandomGeneratorFactory [v2]
In-Reply-To: <hfB86NksORc-aC6zVxHel_QQd_9aB629SfQjXvl6q5U=.e31daa4b-5cf6-4f3f-a757-79e818a18978@github.com>
References: <hfB86NksORc-aC6zVxHel_QQd_9aB629SfQjXvl6q5U=.e31daa4b-5cf6-4f3f-a757-79e818a18978@github.com>
Message-ID: <9-A8RMM10A_Q-tzFYWLOjXqEpsrmovOn9uFrgSm9HpA=.a175b5e0-8389-48f2-a855-b96e26e87daf@github.com>

> All random number generator algorithms are implemented in module `java.base`. The usage of `ServiceLoader` in `j.u.r.RandomGeneratorFactory` is no longer needed.

Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:

  Replaced RandomGeneratorProperties annotation with inner record.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19212/files
  - new: https://git.openjdk.org/jdk/pull/19212/files/09450c09..6179b5e8

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19212&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19212&range=00-01

  Stats: 466 lines in 16 files changed: 141 ins; 240 del; 85 mod
  Patch: https://git.openjdk.org/jdk/pull/19212.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19212/head:pull/19212

PR: https://git.openjdk.org/jdk/pull/19212

From asotona at openjdk.org  Tue May 14 13:25:05 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Tue, 14 May 2024 13:25:05 GMT
Subject: RFR: 8331940: ClassFile API ArrayIndexOutOfBoundsException with
 certain class files
Message-ID: <wWNlHWtc5H1nl9YHXQHGJBdJt-uo3p89E8MeGsRjsKY=.10b28a54-3530-42dc-8b24-5a4da8b81f9a@github.com>

Class file with `LineNumberTable` attribute element pointing behind the bytecode array throws `ArrayIndexOutOfBoundsException`.
This patch performs the check and throws  expected `IllegalArgumentException` instead.
Relevant test is added.

Please review.

Thanks,
Adam

-------------

Commit messages:
 - 8331940: ClassFile API ArrayIndexOutOfBoundsException with certain class files

Changes: https://git.openjdk.org/jdk/pull/19230/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19230&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8331940
  Stats: 20 lines in 2 files changed: 18 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/19230.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19230/head:pull/19230

PR: https://git.openjdk.org/jdk/pull/19230

From naoto at openjdk.org  Tue May 14 13:35:02 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 14 May 2024 13:35:02 GMT
Subject: RFR: 8332084: Ensure JdkConsoleImpl.restoreEcho visibility in a
 shutdown hook [v4]
In-Reply-To: <3Ljww4SBrsr6wmjoBGFLvYJ-cG6jNGdblfb2B7bZuB0=.97e3da61-c10d-4da2-b27a-2bd45dfc544f@github.com>
References: <9JTWc3FRpfbILlSHlmIU_dL5IE69RTxnSIAOdIte15I=.5854a48f-21d7-42c9-adb7-5e3ed40d1211@github.com>
 <3Ljww4SBrsr6wmjoBGFLvYJ-cG6jNGdblfb2B7bZuB0=.97e3da61-c10d-4da2-b27a-2bd45dfc544f@github.com>
Message-ID: <XE8AUEMLyaoGgACSv_qVRADKL4izZXRdfuvF-FnAEuY=.b0c008e2-b583-4d4e-a345-7d58485a7aa0@github.com>

On Mon, 13 May 2024 21:32:18 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Making sure `restoreEcho` correctly reflects the state in the shutdown thread, which differs from the application's thread that issues the `readPassword()` method.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Addresses a review comment

I thought of the same scenario that is certainly possible. Now I am tempted to avoid this race condition altogether by removing checking restoreEcho and always issue echo(true). What do you guys think?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19184#issuecomment-2110258850

From rgiulietti at openjdk.org  Tue May 14 13:47:33 2024
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Tue, 14 May 2024 13:47:33 GMT
Subject: RFR: 8332086: Remove the usage of ServiceLoader in
 j.u.r.RandomGeneratorFactory [v3]
In-Reply-To: <hfB86NksORc-aC6zVxHel_QQd_9aB629SfQjXvl6q5U=.e31daa4b-5cf6-4f3f-a757-79e818a18978@github.com>
References: <hfB86NksORc-aC6zVxHel_QQd_9aB629SfQjXvl6q5U=.e31daa4b-5cf6-4f3f-a757-79e818a18978@github.com>
Message-ID: <RHMQAfrujeQPhrMCaSV7fAvVtQyRIy8NaWFq_Q72dd4=.f11f4b74-2619-41b9-8692-7085d855745b@github.com>

> All random number generator algorithms are implemented in module `java.base`. The usage of `ServiceLoader` in `j.u.r.RandomGeneratorFactory` is no longer needed.

Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:

  Move mathematical logic to record RandomGeneratorProperties.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19212/files
  - new: https://git.openjdk.org/jdk/pull/19212/files/6179b5e8..e8432cc6

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19212&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19212&range=01-02

  Stats: 28 lines in 1 file changed: 14 ins; 9 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/19212.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19212/head:pull/19212

PR: https://git.openjdk.org/jdk/pull/19212

From prappo at openjdk.org  Tue May 14 14:08:03 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Tue, 14 May 2024 14:08:03 GMT
Subject: RFR: 8332084: Ensure JdkConsoleImpl.restoreEcho visibility in a
 shutdown hook [v4]
In-Reply-To: <XE8AUEMLyaoGgACSv_qVRADKL4izZXRdfuvF-FnAEuY=.b0c008e2-b583-4d4e-a345-7d58485a7aa0@github.com>
References: <9JTWc3FRpfbILlSHlmIU_dL5IE69RTxnSIAOdIte15I=.5854a48f-21d7-42c9-adb7-5e3ed40d1211@github.com>
 <3Ljww4SBrsr6wmjoBGFLvYJ-cG6jNGdblfb2B7bZuB0=.97e3da61-c10d-4da2-b27a-2bd45dfc544f@github.com>
 <XE8AUEMLyaoGgACSv_qVRADKL4izZXRdfuvF-FnAEuY=.b0c008e2-b583-4d4e-a345-7d58485a7aa0@github.com>
Message-ID: <pQcZh9mmIwAx4mS_6l3hMsr5OizYsXL2nz_NHeW2dlY=.1e1c892a-c775-470b-ac30-51c5564601b5@github.com>

On Tue, 14 May 2024 13:32:39 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> I thought of the same scenario that is certainly possible. Now I am tempted to avoid this race condition altogether by removing checking restoreEcho and always issue echo(true). What do you guys think?

It should be possible to provide something adequate based on atomic primitives. However, it would complicate code. So, let's first clarify the problem that `restoreEcho` is trying to solve: why is it important to restore the echo state upon JVM exit? What would happen if we fail to do that? Can it be demonstrated?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19184#issuecomment-2110336034

From pminborg at openjdk.org  Tue May 14 14:14:17 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 14 May 2024 14:14:17 GMT
Subject: RFR: 8330465: Stable Values and Collections (Internal)
Message-ID: <-KSimQo5kkmCzzMShqGe5QZ9yCSzpWL98gN13v4wP0k=.11dd8d06-18a6-4577-8342-66632cea0b6e@github.com>

# Stable Values & Collections (Internal)

## Summary
This PR proposes to introduce an internal _Stable Values & Collections_ API, which provides immutable value holders where elements are initialized _at most once_. Stable Values & Collections offer the performance and safety benefits of final fields while offering greater flexibility as to the timing of initialization.

## Goals
 * Provide an easy and intuitive API to describe value holders that can change at most once.
 * Decouple declaration from initialization without significant footprint or performance penalties.
 * Reduce the amount of static initializer and/or field initialization code.
 * Uphold integrity and consistency, even in a multi-threaded environment.
 
For more details, see the draft JEP: https://openjdk.org/jeps/8312611

## Performance 
Performance compared to instance variables using an `AtomicReference` and one protected by double-checked locking under concurrent access by 8 threads:


Benchmark                       Mode  Cnt  Score   Error  Units
StableBenchmark.instanceAtomic  avgt   10  1.576 ? 0.052  ns/op
StableBenchmark.instanceDCL     avgt   10  1.608 ? 0.059  ns/op
StableBenchmark.instanceStable  avgt   10  0.979 ? 0.023  ns/op <- StableValue (~40% faster than DCL)


Performance compared to static variables protected by `AtomicReference`, class-holder idiom holder, and double-checked locking (8 threads):


Benchmark                       Mode  Cnt  Score   Error  Units
StableBenchmark.staticAtomic    avgt   10  1.335 ? 0.056  ns/op
StableBenchmark.staticCHI       avgt   10  0.623 ? 0.086  ns/op
StableBenchmark.staticDCL       avgt   10  1.418 ? 0.171  ns/op
StableBenchmark.staticList      avgt   10  0.617 ? 0.024  ns/op
StableBenchmark.staticStable    avgt   10  0.604 ? 0.022  ns/op <- StableValue ( > 2x faster than `AtomicInteger` and DCL)


Performance for stable lists in both instance and static contexts whereby the sum of random contents is calculated for stable lists (which are thread-safe) compared to `ArrayList` instances (which are not thread-safe) (under single thread access):


Benchmark                                     Mode  Cnt  Score   Error  Units
StableListSumBenchmark.instanceArrayList      avgt   10  0.356 ? 0.005  ns/op
StableListSumBenchmark.instanceList           avgt   10  0.373 ? 0.017  ns/op <- Stable list
StableListSumBenchmark.staticArrayList        avgt   10  0.352 ? 0.002  ns/op
StableListSumBenchmark.staticList             avgt   10  0.356 ? 0.003  ns/op <- Stable list


Performance for stable maps in a static context compared to a `ConcurrentHashMap` (under single thread access):


Benchmark                                     Mode  Cnt  Score   Error  Units
StablePropertiesBenchmark.chmRaw              avgt   10  3.416 ? 0.031  ns/op
StablePropertiesBenchmark.mapRaw              avgt   10  2.105 ? 0.012  ns/op <- Stable map (~40% faster)


All figures above are from local tests on a Mac M1 laptop and should only be constructed as indicative figures.

## Implementation details

There are some noteworthy implementation details in this PR:

 * A field is _trusted_ if it is _declared_ as a `final StableValue`. Previously, the determination of trustworthiness was connected to the _class in which it was declared_ (e.g. is it a `record` or a hidden class). In order to grant such trust, there are extra restrictions imposed on reflection and `sun.misc.Unsafe` usage for such declared `StableValue` fields. This is similar to how `record` classes are handled.
 * In order to allow plain memory semantics for read operations across threads (rather than `volatile` semantics which is slower and which is normally required for double-checked-locking access), we perform a _freeze_ operation before an object becomes visible to other threads. This will prevent store-store reordering and hence, we are able to guarantee complete objects are always seen even under plain memory semantics.
 * In collections with `StableValue` elements/values, a transient `StableValue` view backed by internal arrays is created upon read operations. This improves initialization time, reduces storage requirements, and improves access performance as these transient objects are eliminated by the C2 compiler.

-------------

Commit messages:
 - Merge branch 'master' into stable-value
 - Rework the creation of StableEnumMaps
 - Update sun.misc.Unsafe
 - Fix error in hash code
 - Add methods to create generic arrays
 - Change class types
 - Add a marker interface TrustedFieldType
 - Improve array test
 - Clean up tests
 - Add tests
 - ... and 162 more: https://git.openjdk.org/jdk/compare/4ba74475...5d5dcced

Changes: https://git.openjdk.org/jdk/pull/18794/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18794&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8330465
  Stats: 5733 lines in 39 files changed: 5708 ins; 13 del; 12 mod
  Patch: https://git.openjdk.org/jdk/pull/18794.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18794/head:pull/18794

PR: https://git.openjdk.org/jdk/pull/18794

From liach at openjdk.org  Tue May 14 14:14:21 2024
From: liach at openjdk.org (Chen Liang)
Date: Tue, 14 May 2024 14:14:21 GMT
Subject: RFR: 8330465: Stable Values and Collections (Internal)
In-Reply-To: <-KSimQo5kkmCzzMShqGe5QZ9yCSzpWL98gN13v4wP0k=.11dd8d06-18a6-4577-8342-66632cea0b6e@github.com>
References: <-KSimQo5kkmCzzMShqGe5QZ9yCSzpWL98gN13v4wP0k=.11dd8d06-18a6-4577-8342-66632cea0b6e@github.com>
Message-ID: <Seu0-m1vs1QrM_C5sZgDSp5aGWRwgW5hTguQPTBI02I=.aaabcfc9-204e-4bd2-830e-dc8d39715a83@github.com>

On Tue, 16 Apr 2024 11:47:23 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> # Stable Values & Collections (Internal)
> 
> ## Summary
> This PR proposes to introduce an internal _Stable Values & Collections_ API, which provides immutable value holders where elements are initialized _at most once_. Stable Values & Collections offer the performance and safety benefits of final fields while offering greater flexibility as to the timing of initialization.
> 
> ## Goals
>  * Provide an easy and intuitive API to describe value holders that can change at most once.
>  * Decouple declaration from initialization without significant footprint or performance penalties.
>  * Reduce the amount of static initializer and/or field initialization code.
>  * Uphold integrity and consistency, even in a multi-threaded environment.
>  
> For more details, see the draft JEP: https://openjdk.org/jeps/8312611
> 
> ## Performance 
> Performance compared to instance variables using an `AtomicReference` and one protected by double-checked locking under concurrent access by 8 threads:
> 
> 
> Benchmark                       Mode  Cnt  Score   Error  Units
> StableBenchmark.instanceAtomic  avgt   10  1.576 ? 0.052  ns/op
> StableBenchmark.instanceDCL     avgt   10  1.608 ? 0.059  ns/op
> StableBenchmark.instanceStable  avgt   10  0.979 ? 0.023  ns/op <- StableValue (~40% faster than DCL)
> 
> 
> Performance compared to static variables protected by `AtomicReference`, class-holder idiom holder, and double-checked locking (8 threads):
> 
> 
> Benchmark                       Mode  Cnt  Score   Error  Units
> StableBenchmark.staticAtomic    avgt   10  1.335 ? 0.056  ns/op
> StableBenchmark.staticCHI       avgt   10  0.623 ? 0.086  ns/op
> StableBenchmark.staticDCL       avgt   10  1.418 ? 0.171  ns/op
> StableBenchmark.staticList      avgt   10  0.617 ? 0.024  ns/op
> StableBenchmark.staticStable    avgt   10  0.604 ? 0.022  ns/op <- StableValue ( > 2x faster than `AtomicInteger` and DCL)
> 
> 
> Performance for stable lists in both instance and static contexts whereby the sum of random contents is calculated for stable lists (which are thread-safe) compared to `ArrayList` instances (which are not thread-safe) (under single thread access):
> 
> 
> Benchmark                                     Mode  Cnt  Score   Error  Units
> StableListSumBenchmark.instanceArrayList      avgt   10  0.356 ? 0.005  ns/op
> StableListSumBenchmark.instanceList           avgt   10  0.373 ? 0.017  ns/op <- Stable list
> StableListSumBenchmark.staticArrayList        avgt   10  0.352 ? 0.002  ns/op
> StableListSumBenchmark.staticList             avgt   10  0.356 ? 0.00...

Glad to see this! Some API design remarks.

Also, I want to mention a few important differences between `@Stable` and Stable Values:

Patterns:
1. Benign race (does not exist in StableValue API): multiple threads can create an instance and upload, any non-null instance is functionally equivalent so race is ok (seen in most of JDK)
2. compareAndSet (setIfUnset): multiple threads can create instance, only one will succeed in uploading; usually for when the instance computation is cheap but we want single witness.
3. atomic computation (computeIfUnset): only one thread can create instance which will be witnessed by other threads; this pattern ensures correctness and prevents wasteful computation by other threads at the cost of locking and lambda creation.

Allocation in objects: `@Stable` field is local to an object but `StableValue` is another object; thus sharing strategy may differ, as stable fields are copied over but StableValue uses a shared cache (which is even better for avoiding redundant computation)

Question:
1. Will we ever try to expose the stable benign race model to users?
2. Will we ever try to inline the stable values in object layout like a stable field?

Just curious, can you test other samples, like `StableValue<List<Object>>` where the contained `List` is an immutable list from `List.of` factories? I think that would be a meaningful case too.

Also on a side note, I just realized there's no equivalent of `@Stable int[]` etc. stable primitive arrays exposed, yet immutable arrays will be useful. Is the Frozen Arrays JEP still active, or will this Stable Values consider expose stable primitive arrays?

src/java.base/share/classes/java/lang/reflect/Field.java line 179:

> 177:         AccessibleObject.checkPermission();
> 178:         // Always check if the field is a final StableValue
> 179:         if (StableValue.class.isAssignableFrom(type) && Modifier.isFinal(modifiers)) {

This doesn't protect the Stable Collections.

src/java.base/share/classes/java/util/ImmutableCollections.java line 173:

> 171:                             .map(Objects::requireNonNull)
> 172:                             .toArray();
> 173:                     return keys instanceof EnumSet

We can move this instanceof check before the stream call.

src/java.base/share/classes/java/util/ImmutableCollections.java line 1457:

> 1455:         private final V[] elements;
> 1456:         @Stable
> 1457:         private final AuxiliaryArrays aux;

Is java.util not trusted package so we need `@Stable`?

src/java.base/share/classes/java/util/ImmutableCollections.java line 1519:

> 1517:     // Internal interface used to indicate the presence of
> 1518:     // the computeIfUnset method that is unique to StableMap and StableEnumMap
> 1519:     interface HasComputeIfUnset<K, V> {

Suggestion:

    interface HasComputeIfUnset<K, V> extends Map<K, StableValue<V>> {


So maybe we can use pattern matching like:

Map<K, StableValue<V>> map = ...
if (map instanceof HasComputeIfUnset<K, V> hciu) {
    // stuff
}

src/java.base/share/classes/java/util/ImmutableCollections.java line 1668:

> 1666:         @Override
> 1667:         public Set<Map.Entry<K, StableValue<V>>> entrySet() {
> 1668:             return new AbstractSet<>() {

Maybe we want to do `AbstractImmutableSet` like in #18522.

src/java.base/share/classes/java/util/ImmutableCollections.java line 1677:

> 1675:     static final class StableEnumMap<K extends Enum<K>, V>
> 1676:             extends AbstractImmutableMap<K, StableValue<V>>
> 1677:             implements Map<K, StableValue<V>>, HasComputeIfUnset<K, V> {

Note that this might be a navigable map, as enums are comparable.

src/java.base/share/classes/java/util/ImmutableCollections.java line 1855:

> 1853:                 @Override
> 1854:                 public boolean equals(Object o) {
> 1855:                     return o == this;

These implementations are violations to the Set contracts; Set's hash code should be its elements' sum (thus an entry set's hash code is equivalent to its map's hash) and equals should check if all elements are present. This also makes two entry sets from two `entrySet()` calls not equal (at least before valhalla)

src/java.base/share/classes/jdk/internal/lang/StableValue.java line 223:

> 221:     /**
> 222:      * {@return an unmodifiable, shallowly immutable, thread-safe, value-stable,
> 223:      * {@linkplain Map } where the {@linkplain java.util.Map#keySet() keys}

Suggestion:

     * {@linkplain Map} where the {@linkplain java.util.Map#keySet() keys}

src/java.base/share/classes/jdk/internal/lang/StableValue.java line 279:

> 277:     static <V> V computeIfUnset(List<StableValue<V>> list,
> 278:                                 int index,
> 279:                                 IntFunction<? extends V> mapper) {

Hmm, these APIs seem unintuitive and error-prone to users. Have you studied the use case where for one stable list/map, there are distinct initialization logics for different indices/keys so that they support different mappers for the same list/map? I cannot recall on top of my head. 

If we drop said ability and restrict mappers to the list/map creation, the whole thing will be much cleaner, and it's a better way to avoid capturing lambdas as well. Users can still go to individual stable values and use functional creation if they really, really want that functionality.

src/java.base/share/classes/jdk/internal/lang/stable/StableUtil.java line 90:

> 88:         // to provide protection against store/store reordering.
> 89:         // See VarHandle::releaseFence
> 90:         UNSAFE.storeFence();

Can we use a storeStoreFence like in #18505?

-------------

PR Review: https://git.openjdk.org/jdk/pull/18794#pullrequestreview-2004581002
PR Comment: https://git.openjdk.org/jdk/pull/18794#issuecomment-2061350087
PR Comment: https://git.openjdk.org/jdk/pull/18794#issuecomment-2075216073
PR Review Comment: https://git.openjdk.org/jdk/pull/18794#discussion_r1581828312
PR Review Comment: https://git.openjdk.org/jdk/pull/18794#discussion_r1581828721
PR Review Comment: https://git.openjdk.org/jdk/pull/18794#discussion_r1598676330
PR Review Comment: https://git.openjdk.org/jdk/pull/18794#discussion_r1581829255
PR Review Comment: https://git.openjdk.org/jdk/pull/18794#discussion_r1581829489
PR Review Comment: https://git.openjdk.org/jdk/pull/18794#discussion_r1567930612
PR Review Comment: https://git.openjdk.org/jdk/pull/18794#discussion_r1599908641
PR Review Comment: https://git.openjdk.org/jdk/pull/18794#discussion_r1581830287
PR Review Comment: https://git.openjdk.org/jdk/pull/18794#discussion_r1567944454
PR Review Comment: https://git.openjdk.org/jdk/pull/18794#discussion_r1581830884

From duke at openjdk.org  Tue May 14 14:14:23 2024
From: duke at openjdk.org (ExE Boss)
Date: Tue, 14 May 2024 14:14:23 GMT
Subject: RFR: 8330465: Stable Values and Collections (Internal)
In-Reply-To: <-KSimQo5kkmCzzMShqGe5QZ9yCSzpWL98gN13v4wP0k=.11dd8d06-18a6-4577-8342-66632cea0b6e@github.com>
References: <-KSimQo5kkmCzzMShqGe5QZ9yCSzpWL98gN13v4wP0k=.11dd8d06-18a6-4577-8342-66632cea0b6e@github.com>
Message-ID: <eGwmCLM96Az7spnY1PDro2Uwckkb460i-IH7ZZWOtbw=.a12c2133-76c6-4fff-93e4-c7957d586669@github.com>

On Tue, 16 Apr 2024 11:47:23 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> # Stable Values & Collections (Internal)
> 
> ## Summary
> This PR proposes to introduce an internal _Stable Values & Collections_ API, which provides immutable value holders where elements are initialized _at most once_. Stable Values & Collections offer the performance and safety benefits of final fields while offering greater flexibility as to the timing of initialization.
> 
> ## Goals
>  * Provide an easy and intuitive API to describe value holders that can change at most once.
>  * Decouple declaration from initialization without significant footprint or performance penalties.
>  * Reduce the amount of static initializer and/or field initialization code.
>  * Uphold integrity and consistency, even in a multi-threaded environment.
>  
> For more details, see the draft JEP: https://openjdk.org/jeps/8312611
> 
> ## Performance 
> Performance compared to instance variables using an `AtomicReference` and one protected by double-checked locking under concurrent access by 8 threads:
> 
> 
> Benchmark                       Mode  Cnt  Score   Error  Units
> StableBenchmark.instanceAtomic  avgt   10  1.576 ? 0.052  ns/op
> StableBenchmark.instanceDCL     avgt   10  1.608 ? 0.059  ns/op
> StableBenchmark.instanceStable  avgt   10  0.979 ? 0.023  ns/op <- StableValue (~40% faster than DCL)
> 
> 
> Performance compared to static variables protected by `AtomicReference`, class-holder idiom holder, and double-checked locking (8 threads):
> 
> 
> Benchmark                       Mode  Cnt  Score   Error  Units
> StableBenchmark.staticAtomic    avgt   10  1.335 ? 0.056  ns/op
> StableBenchmark.staticCHI       avgt   10  0.623 ? 0.086  ns/op
> StableBenchmark.staticDCL       avgt   10  1.418 ? 0.171  ns/op
> StableBenchmark.staticList      avgt   10  0.617 ? 0.024  ns/op
> StableBenchmark.staticStable    avgt   10  0.604 ? 0.022  ns/op <- StableValue ( > 2x faster than `AtomicInteger` and DCL)
> 
> 
> Performance for stable lists in both instance and static contexts whereby the sum of random contents is calculated for stable lists (which are thread-safe) compared to `ArrayList` instances (which are not thread-safe) (under single thread access):
> 
> 
> Benchmark                                     Mode  Cnt  Score   Error  Units
> StableListSumBenchmark.instanceArrayList      avgt   10  0.356 ? 0.005  ns/op
> StableListSumBenchmark.instanceList           avgt   10  0.373 ? 0.017  ns/op <- Stable list
> StableListSumBenchmark.staticArrayList        avgt   10  0.352 ? 0.002  ns/op
> StableListSumBenchmark.staticList             avgt   10  0.356 ? 0.00...

**Nit:** Inconsistent?whitespace:

src/java.base/share/classes/java/lang/reflect/AccessibleObject.java line 393:

> 391:     }
> 392: 
> 393:     InaccessibleObjectException newInaccessibleObjectException(String msg) {

This?internal helper?method can?be?`static`:
Suggestion:

    static InaccessibleObjectException newInaccessibleObjectException(String msg) {

src/java.base/share/classes/jdk/internal/lang/stable/StableValueElement.java line 57:

> 55:         return switch (stateVolatile()) {
> 56:             case UNSET    -> throw new NoSuchElementException(); // No value was set
> 57:             case NON_NULL -> orThrowVolatile(); // Race: another thread has set a value

It?should be?safe to?avoid self?recursion?here:
Suggestion:

            case NON_NULL -> elements[index]; // Race: another thread has set a value

or:
Suggestion:

            case NON_NULL -> {
                v = elements[index]; // Race: another thread has set a value
                if (v != null) {
                    yield v;
                }
                throw shouldNotReachHere();
            }

src/java.base/share/classes/jdk/internal/lang/stable/StableValueElement.java line 63:

> 61:         // more compact byte code.
> 62:         switch (stateVolatile()) {
> 63:             case UNSET:    { throw StableUtil.notSet();}

Suggestion:

            case UNSET:    { throw StableUtil.notSet(); }

src/java.base/share/classes/jdk/internal/lang/stable/StableValueElement.java line 116:

> 114:     public V computeIfUnset(Supplier<? extends V> supplier) {
> 115:         // Todo: This creates a lambda
> 116:         return computeIfUnsetShared(supplier, Supplier::get);

Suggestion:

        return computeIfUnsetShared(supplier, supplierExtractor());

src/java.base/share/classes/jdk/internal/lang/stable/StableValueElement.java line 144:

> 142:         // more compact byte code.
> 143:         switch (stateVolatile()) {
> 144:             case UNSET:    { return computeIfUnsetVolatile0(provider, key);}

Suggestion:

            case UNSET:    { return computeIfUnsetVolatile0(provider, key); }

src/java.base/share/classes/jdk/internal/lang/stable/StableValueImpl.java line 116:

> 114:         // more compact byte code.
> 115:         switch (stateVolatile()) {
> 116:             case UNSET:    { throw StableUtil.notSet();}

Suggestion:

            case UNSET:    { throw StableUtil.notSet(); }

src/java.base/share/classes/jdk/internal/lang/stable/StableValueImpl.java line 181:

> 179:         // more compact byte code.
> 180:         switch (stateVolatile()) {
> 181:             case UNSET:    { return computeIfUnsetVolatile0(supplier);}

Suggestion:

            case UNSET:    { return computeIfUnsetVolatile0(supplier); }

-------------

PR Review: https://git.openjdk.org/jdk/pull/18794#pullrequestreview-2029063641
PR Review Comment: https://git.openjdk.org/jdk/pull/18794#discussion_r1570620018
PR Review Comment: https://git.openjdk.org/jdk/pull/18794#discussion_r1580882515
PR Review Comment: https://git.openjdk.org/jdk/pull/18794#discussion_r1583418107
PR Review Comment: https://git.openjdk.org/jdk/pull/18794#discussion_r1572101643
PR Review Comment: https://git.openjdk.org/jdk/pull/18794#discussion_r1583418492
PR Review Comment: https://git.openjdk.org/jdk/pull/18794#discussion_r1583419719
PR Review Comment: https://git.openjdk.org/jdk/pull/18794#discussion_r1583420000

From pminborg at openjdk.org  Tue May 14 14:14:23 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 14 May 2024 14:14:23 GMT
Subject: RFR: 8330465: Stable Values and Collections (Internal)
In-Reply-To: <Seu0-m1vs1QrM_C5sZgDSp5aGWRwgW5hTguQPTBI02I=.aaabcfc9-204e-4bd2-830e-dc8d39715a83@github.com>
References: <-KSimQo5kkmCzzMShqGe5QZ9yCSzpWL98gN13v4wP0k=.11dd8d06-18a6-4577-8342-66632cea0b6e@github.com>
 <Seu0-m1vs1QrM_C5sZgDSp5aGWRwgW5hTguQPTBI02I=.aaabcfc9-204e-4bd2-830e-dc8d39715a83@github.com>
Message-ID: <_mwOb-4riQczNG6UoDy6S4ti7I68dYvcLAY3dzLNZaQ=.71a67ede-0f64-452e-bfec-4db95b25338b@github.com>

On Wed, 17 Apr 2024 14:07:05 GMT, Chen Liang <liach at openjdk.org> wrote:

> Question:
> 
> 1. Will we ever try to expose the stable benign race model to users?
> 2. Will we ever try to inline the stable values in object layout like a stable field?

1. I think there is little or no upside in exposing the benign race. It would also be difficult to assert the invariant, competing objects are functionally equivalent. So, I think no.

2. In a static context, the stable value will be inlined (or rather constant-folded). So we are partly already there. For pure instance contexts, I have some ideas about this but it is non-trivial.

> Just curious, can you test other samples, like `StableValue<List<Object>>` where the contained `List` is an immutable list from `List.of` factories? I think that would be a meaningful case too.

Good suggestion. I've added such a test. It turns out the performance is great there too.

> Also on a side note, I just realized there's no equivalent of `@Stable int[]` etc. stable primitive arrays exposed, yet immutable arrays will be useful. Is the Frozen Arrays JEP still active, or will this Stable Values consider expose stable primitive arrays?

Good question. In one of the previous prototypes, we accepted a class literal that would enable the use of primitive arrays. We now think that we can achieve the same thing once Valhalla is integrated. This will allow not just `StableValue` to use primitive flattened arrays but also a large number of other constructs like `ArrayList`.

One thing we are considering is adding support for stable multi-dimensional reference arrays. For an overwhelming majority of the use cases, we would be able to eliminate the second layer of indirection that is there for arrays of rank > 1.

> src/java.base/share/classes/java/lang/reflect/Field.java line 179:
> 
>> 177:         AccessibleObject.checkPermission();
>> 178:         // Always check if the field is a final StableValue
>> 179:         if (StableValue.class.isAssignableFrom(type) && Modifier.isFinal(modifiers)) {
> 
> This doesn't protect the Stable Collections.

I will take a look at having an interface that signals this.

> src/java.base/share/classes/java/util/ImmutableCollections.java line 173:
> 
>> 171:                             .map(Objects::requireNonNull)
>> 172:                             .toArray();
>> 173:                     return keys instanceof EnumSet
> 
> We can move this instanceof check before the stream call.

As we need the array in both cases, how would such a solution look like without duplicating code?

> src/java.base/share/classes/java/util/ImmutableCollections.java line 1457:
> 
>> 1455:         private final V[] elements;
>> 1456:         @Stable
>> 1457:         private final AuxiliaryArrays aux;
> 
> Is java.util not trusted package so we need `@Stable`?

That is correct. Hence, there are many @Stable annotations already in this class.

> src/java.base/share/classes/java/util/ImmutableCollections.java line 1677:
> 
>> 1675:     static final class StableEnumMap<K extends Enum<K>, V>
>> 1676:             extends AbstractImmutableMap<K, StableValue<V>>
>> 1677:             implements Map<K, StableValue<V>>, HasComputeIfUnset<K, V> {
> 
> Note that this might be a navigable map, as enums are comparable.

While that is true, no other immutable collection implements a navigable map. The way the API is currently wired, it always returns a `Map`. If we go down this route, it would incidentally return a `NaviableMap` if presented with an `EnumMap` or, we could have a separate factory for enums that states it returns a `NavigableMap`. I think creating all the required views would increase complexity significantly and I am not sure it would be used that much. That said, let us keep this open for the future.

> src/java.base/share/classes/java/util/ImmutableCollections.java line 1855:
> 
>> 1853:                 @Override
>> 1854:                 public boolean equals(Object o) {
>> 1855:                     return o == this;
> 
> These implementations are violations to the Set contracts; Set's hash code should be its elements' sum (thus an entry set's hash code is equivalent to its map's hash) and equals should check if all elements are present. This also makes two entry sets from two `entrySet()` calls not equal (at least before valhalla)

Good catch. Thank you for finding this!

> src/java.base/share/classes/jdk/internal/lang/StableValue.java line 279:
> 
>> 277:     static <V> V computeIfUnset(List<StableValue<V>> list,
>> 278:                                 int index,
>> 279:                                 IntFunction<? extends V> mapper) {
> 
> Hmm, these APIs seem unintuitive and error-prone to users. Have you studied the use case where for one stable list/map, there are distinct initialization logics for different indices/keys so that they support different mappers for the same list/map? I cannot recall on top of my head. 
> 
> If we drop said ability and restrict mappers to the list/map creation, the whole thing will be much cleaner, and it's a better way to avoid capturing lambdas as well. Users can still go to individual stable values and use functional creation if they really, really want that functionality.

I see what you mean with distinct initialization logic. This is not the intended use though. 

The reason these methods exist is to avoid lambda capturing. Let's say we have a `Function<K, V>` we want to apply to a `Map<K, StableValue<V>>`. Then, retrieving a `stable = StableValue<V>` and applying `stable.computeIfUnset(() -> function.apply(key))` would capture a new `Supplier`. Another alternative would be to write imperative code similar to what is already in these methods.

What we could do is provide factories for memorized functions (the latter described in the draft JEP at the end (https://openjdk.org/jeps/8312611) ) even though these are easy to write.

I think what you are proposing is something like this?


Map<K, StableValue<V>> map = StableValue.ofMap(keys, k -> createV(k));


or perhaps even:


Map<K, V> map = StableValue.ofMap(keys, k -> createV(k));

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18794#issuecomment-2061521478
PR Comment: https://git.openjdk.org/jdk/pull/18794#issuecomment-2076524102
PR Comment: https://git.openjdk.org/jdk/pull/18794#issuecomment-2076528648
PR Review Comment: https://git.openjdk.org/jdk/pull/18794#discussion_r1591463541
PR Review Comment: https://git.openjdk.org/jdk/pull/18794#discussion_r1598111344
PR Review Comment: https://git.openjdk.org/jdk/pull/18794#discussion_r1599938827
PR Review Comment: https://git.openjdk.org/jdk/pull/18794#discussion_r1568366235
PR Review Comment: https://git.openjdk.org/jdk/pull/18794#discussion_r1599960795
PR Review Comment: https://git.openjdk.org/jdk/pull/18794#discussion_r1568387185

From liach at openjdk.org  Tue May 14 14:14:23 2024
From: liach at openjdk.org (Chen Liang)
Date: Tue, 14 May 2024 14:14:23 GMT
Subject: RFR: 8330465: Stable Values and Collections (Internal)
In-Reply-To: <_mwOb-4riQczNG6UoDy6S4ti7I68dYvcLAY3dzLNZaQ=.71a67ede-0f64-452e-bfec-4db95b25338b@github.com>
References: <-KSimQo5kkmCzzMShqGe5QZ9yCSzpWL98gN13v4wP0k=.11dd8d06-18a6-4577-8342-66632cea0b6e@github.com>
 <Seu0-m1vs1QrM_C5sZgDSp5aGWRwgW5hTguQPTBI02I=.aaabcfc9-204e-4bd2-830e-dc8d39715a83@github.com>
 <_mwOb-4riQczNG6UoDy6S4ti7I68dYvcLAY3dzLNZaQ=.71a67ede-0f64-452e-bfec-4db95b25338b@github.com>
Message-ID: <NocbzqVlFju0c_kxXvHuc7_vl63fPOESb0iBRIqoq7o=.048a578e-dd3f-497e-9280-bd9d7ad272c3@github.com>

On Wed, 17 Apr 2024 15:17:52 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> Also, I want to mention a few important differences between `@Stable` and Stable Values:
>> 
>> Patterns:
>> 1. Benign race (does not exist in StableValue API): multiple threads can create an instance and upload, any non-null instance is functionally equivalent so race is ok (seen in most of JDK)
>> 2. compareAndSet (setIfUnset): multiple threads can create instance, only one will succeed in uploading; usually for when the instance computation is cheap but we want single witness.
>> 3. atomic computation (computeIfUnset): only one thread can create instance which will be witnessed by other threads; this pattern ensures correctness and prevents wasteful computation by other threads at the cost of locking and lambda creation.
>> 
>> Allocation in objects: `@Stable` field is local to an object but `StableValue` is another object; thus sharing strategy may differ, as stable fields are copied over but StableValue uses a shared cache (which is even better for avoiding redundant computation)
>> 
>> Question:
>> 1. Will we ever try to expose the stable benign race model to users?
>> 2. Will we ever try to inline the stable values in object layout like a stable field?
>
>> Question:
>> 
>> 1. Will we ever try to expose the stable benign race model to users?
>> 2. Will we ever try to inline the stable values in object layout like a stable field?
> 
> 1. I think there is little or no upside in exposing the benign race. It would also be difficult to assert the invariant, competing objects are functionally equivalent. So, I think no.
> 
> 2. In a static context, the stable value will be inlined (or rather constant-folded). So we are partly already there. For pure instance contexts, I have some ideas about this but it is non-trivial.

@minborg Just curious, why are you adding holder-in-holder benchmark cases?

>> src/java.base/share/classes/java/util/ImmutableCollections.java line 173:
>> 
>>> 171:                             .map(Objects::requireNonNull)
>>> 172:                             .toArray();
>>> 173:                     return keys instanceof EnumSet
>> 
>> We can move this instanceof check before the stream call.
>
> As we need the array in both cases, how would such a solution look like without duplicating code?

I was thinking about changing the StableEnumMap factory to directly take an EnumSet/BitSet indicating the indices without conversions to full objects and arrays.

>> src/java.base/share/classes/java/util/ImmutableCollections.java line 1677:
>> 
>>> 1675:     static final class StableEnumMap<K extends Enum<K>, V>
>>> 1676:             extends AbstractImmutableMap<K, StableValue<V>>
>>> 1677:             implements Map<K, StableValue<V>>, HasComputeIfUnset<K, V> {
>> 
>> Note that this might be a navigable map, as enums are comparable.
>
> While that is true, no other immutable collection implements a navigable map. The way the API is currently wired, it always returns a `Map`. If we go down this route, it would incidentally return a `NaviableMap` if presented with an `EnumMap` or, we could have a separate factory for enums that states it returns a `NavigableMap`. I think creating all the required views would increase complexity significantly and I am not sure it would be used that much. That said, let us keep this open for the future.

Fair enough, `Collections` APIs like `unmodifiableSortedMap` explicitly avoid implementing too many interfaces.

>> src/java.base/share/classes/jdk/internal/lang/StableValue.java line 279:
>> 
>>> 277:     static <V> V computeIfUnset(List<StableValue<V>> list,
>>> 278:                                 int index,
>>> 279:                                 IntFunction<? extends V> mapper) {
>> 
>> Hmm, these APIs seem unintuitive and error-prone to users. Have you studied the use case where for one stable list/map, there are distinct initialization logics for different indices/keys so that they support different mappers for the same list/map? I cannot recall on top of my head. 
>> 
>> If we drop said ability and restrict mappers to the list/map creation, the whole thing will be much cleaner, and it's a better way to avoid capturing lambdas as well. Users can still go to individual stable values and use functional creation if they really, really want that functionality.
>
> I see what you mean with distinct initialization logic. This is not the intended use though. 
> 
> The reason these methods exist is to avoid lambda capturing. Let's say we have a `Function<K, V>` we want to apply to a `Map<K, StableValue<V>>`. Then, retrieving a `stable = StableValue<V>` and applying `stable.computeIfUnset(() -> function.apply(key))` would capture a new `Supplier`. Another alternative would be to write imperative code similar to what is already in these methods.
> 
> What we could do is provide factories for memorized functions (the latter described in the draft JEP at the end (https://openjdk.org/jeps/8312611) ) even though these are easy to write.
> 
> I think what you are proposing is something like this?
> 
> 
> Map<K, StableValue<V>> map = StableValue.ofMap(keys, k -> createV(k));
> 
> 
> or perhaps even:
> 
> 
> Map<K, V> map = StableValue.ofMap(keys, k -> createV(k));

Yes, consider the 3 capture scenarios:
| API | Capture frequency | Capture Impact | Code Convenience | Flexibility |
|-----|-------------------|----------------|------------------|-------------|
| `StableValue.ofMap(map, k -> ...)` | By accident | single capture is reused | OK | One generator for all keys |
| `StableValue.computeIfUnset(map, key, k -> ...)` | By accident | capture happens for all access sites | somewhat ugly | Different generator for different keys |
| `map.get(k).computeIfUnset(() -> ...)` | Always | capture happens for all access sites | OK | Different generator for different keys |

Notice the `ofMap` factory is the most tolerant to faulty captures: even if it captures, the single capturing lambda is reused for all map stables, avoiding capture overheads at access sites. Given Java compiler doesn't tell user anything about captures during compilation, I think `ofMap` is a better factory to avoid accidentally writing capturing lambdas.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18794#issuecomment-2075071225
PR Review Comment: https://git.openjdk.org/jdk/pull/18794#discussion_r1598376355
PR Review Comment: https://git.openjdk.org/jdk/pull/18794#discussion_r1568472583
PR Review Comment: https://git.openjdk.org/jdk/pull/18794#discussion_r1568491254

From pminborg at openjdk.org  Tue May 14 14:14:23 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 14 May 2024 14:14:23 GMT
Subject: RFR: 8330465: Stable Values and Collections (Internal)
In-Reply-To: <_mwOb-4riQczNG6UoDy6S4ti7I68dYvcLAY3dzLNZaQ=.71a67ede-0f64-452e-bfec-4db95b25338b@github.com>
References: <-KSimQo5kkmCzzMShqGe5QZ9yCSzpWL98gN13v4wP0k=.11dd8d06-18a6-4577-8342-66632cea0b6e@github.com>
 <Seu0-m1vs1QrM_C5sZgDSp5aGWRwgW5hTguQPTBI02I=.aaabcfc9-204e-4bd2-830e-dc8d39715a83@github.com>
 <_mwOb-4riQczNG6UoDy6S4ti7I68dYvcLAY3dzLNZaQ=.71a67ede-0f64-452e-bfec-4db95b25338b@github.com>
Message-ID: <jAf2hOsOYih7D8DoK0L4_Y-r_1QJQK6bDAeK8bFeZ3g=.c1872859-e409-4298-81c8-c3eb13cf7db9@github.com>

On Wed, 17 Apr 2024 15:17:52 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> Also, I want to mention a few important differences between `@Stable` and Stable Values:
>> 
>> Patterns:
>> 1. Benign race (does not exist in StableValue API): multiple threads can create an instance and upload, any non-null instance is functionally equivalent so race is ok (seen in most of JDK)
>> 2. compareAndSet (setIfUnset): multiple threads can create instance, only one will succeed in uploading; usually for when the instance computation is cheap but we want single witness.
>> 3. atomic computation (computeIfUnset): only one thread can create instance which will be witnessed by other threads; this pattern ensures correctness and prevents wasteful computation by other threads at the cost of locking and lambda creation.
>> 
>> Allocation in objects: `@Stable` field is local to an object but `StableValue` is another object; thus sharing strategy may differ, as stable fields are copied over but StableValue uses a shared cache (which is even better for avoiding redundant computation)
>> 
>> Question:
>> 1. Will we ever try to expose the stable benign race model to users?
>> 2. Will we ever try to inline the stable values in object layout like a stable field?
>
>> Question:
>> 
>> 1. Will we ever try to expose the stable benign race model to users?
>> 2. Will we ever try to inline the stable values in object layout like a stable field?
> 
> 1. I think there is little or no upside in exposing the benign race. It would also be difficult to assert the invariant, competing objects are functionally equivalent. So, I think no.
> 
> 2. In a static context, the stable value will be inlined (or rather constant-folded). So we are partly already there. For pure instance contexts, I have some ideas about this but it is non-trivial.

> @minborg Just curious, why are you adding holder-in-holder benchmark cases?

I'd like to test the transitive constant folding capabilities.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18794#issuecomment-2075119450

From pminborg at openjdk.org  Tue May 14 14:14:23 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 14 May 2024 14:14:23 GMT
Subject: RFR: 8330465: Stable Values and Collections (Internal)
In-Reply-To: <-KSimQo5kkmCzzMShqGe5QZ9yCSzpWL98gN13v4wP0k=.11dd8d06-18a6-4577-8342-66632cea0b6e@github.com>
References: <-KSimQo5kkmCzzMShqGe5QZ9yCSzpWL98gN13v4wP0k=.11dd8d06-18a6-4577-8342-66632cea0b6e@github.com>
Message-ID: <v7kdbf2PaVnlgq1m7tKNqXCJU4RxdYWiUPq2hGS-nng=.8c438c20-d6bb-4163-8425-30930853d11e@github.com>

On Tue, 16 Apr 2024 11:47:23 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> # Stable Values & Collections (Internal)
> 
> ## Summary
> This PR proposes to introduce an internal _Stable Values & Collections_ API, which provides immutable value holders where elements are initialized _at most once_. Stable Values & Collections offer the performance and safety benefits of final fields while offering greater flexibility as to the timing of initialization.
> 
> ## Goals
>  * Provide an easy and intuitive API to describe value holders that can change at most once.
>  * Decouple declaration from initialization without significant footprint or performance penalties.
>  * Reduce the amount of static initializer and/or field initialization code.
>  * Uphold integrity and consistency, even in a multi-threaded environment.
>  
> For more details, see the draft JEP: https://openjdk.org/jeps/8312611
> 
> ## Performance 
> Performance compared to instance variables using an `AtomicReference` and one protected by double-checked locking under concurrent access by 8 threads:
> 
> 
> Benchmark                       Mode  Cnt  Score   Error  Units
> StableBenchmark.instanceAtomic  avgt   10  1.576 ? 0.052  ns/op
> StableBenchmark.instanceDCL     avgt   10  1.608 ? 0.059  ns/op
> StableBenchmark.instanceStable  avgt   10  0.979 ? 0.023  ns/op <- StableValue (~40% faster than DCL)
> 
> 
> Performance compared to static variables protected by `AtomicReference`, class-holder idiom holder, and double-checked locking (8 threads):
> 
> 
> Benchmark                       Mode  Cnt  Score   Error  Units
> StableBenchmark.staticAtomic    avgt   10  1.335 ? 0.056  ns/op
> StableBenchmark.staticCHI       avgt   10  0.623 ? 0.086  ns/op
> StableBenchmark.staticDCL       avgt   10  1.418 ? 0.171  ns/op
> StableBenchmark.staticList      avgt   10  0.617 ? 0.024  ns/op
> StableBenchmark.staticStable    avgt   10  0.604 ? 0.022  ns/op <- StableValue ( > 2x faster than `AtomicInteger` and DCL)
> 
> 
> Performance for stable lists in both instance and static contexts whereby the sum of random contents is calculated for stable lists (which are thread-safe) compared to `ArrayList` instances (which are not thread-safe) (under single thread access):
> 
> 
> Benchmark                                     Mode  Cnt  Score   Error  Units
> StableListSumBenchmark.instanceArrayList      avgt   10  0.356 ? 0.005  ns/op
> StableListSumBenchmark.instanceList           avgt   10  0.373 ? 0.017  ns/op <- Stable list
> StableListSumBenchmark.staticArrayList        avgt   10  0.352 ? 0.002  ns/op
> StableListSumBenchmark.staticList             avgt   10  0.356 ? 0.00...

I've run some benchmarks on various platforms for static fields (higher is better):

<img width="895" alt="image" src="https://github.com/openjdk/jdk/assets/7457876/074f45f5-e577-4da0-97ab-2e7023cc6550">

Here are some figures for various platforms where we compare `AtomicReference`, double-checked locking holder, and `StableValue` using instance variables and where we iterate and sum 20 values from said constructs:

<img width="900" alt="image" src="https://github.com/openjdk/jdk/assets/7457876/6554233c-8238-483f-8a1b-e51f832243a3">

Note: The figures should be taken with a grain of salt pending a deeper analysis.

src/hotspot/share/ci/ciField.cpp line 262:

> 260: const char* stable_array3d_klass_name = "jdk/internal/lang/StableArray3D";
> 261: 
> 262: static bool trust_final_non_static_fields_of_type(Symbol* signature) {

Is there a better way of doing this?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18794#issuecomment-2075121059
PR Comment: https://git.openjdk.org/jdk/pull/18794#issuecomment-2076586960
PR Review Comment: https://git.openjdk.org/jdk/pull/18794#discussion_r1599826991

From pminborg at openjdk.org  Tue May 14 14:14:23 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 14 May 2024 14:14:23 GMT
Subject: RFR: 8330465: Stable Values and Collections (Internal)
In-Reply-To: <v7kdbf2PaVnlgq1m7tKNqXCJU4RxdYWiUPq2hGS-nng=.8c438c20-d6bb-4163-8425-30930853d11e@github.com>
References: <-KSimQo5kkmCzzMShqGe5QZ9yCSzpWL98gN13v4wP0k=.11dd8d06-18a6-4577-8342-66632cea0b6e@github.com>
 <v7kdbf2PaVnlgq1m7tKNqXCJU4RxdYWiUPq2hGS-nng=.8c438c20-d6bb-4163-8425-30930853d11e@github.com>
Message-ID: <oTxcjqMHPwCLOVX4b1M0lJVOpB8Ymlb5HdYAgyscccs=.9eb93f56-8b77-480f-9f02-e25ab0fb5267@github.com>

On Tue, 14 May 2024 11:07:00 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> # Stable Values & Collections (Internal)
>> 
>> ## Summary
>> This PR proposes to introduce an internal _Stable Values & Collections_ API, which provides immutable value holders where elements are initialized _at most once_. Stable Values & Collections offer the performance and safety benefits of final fields while offering greater flexibility as to the timing of initialization.
>> 
>> ## Goals
>>  * Provide an easy and intuitive API to describe value holders that can change at most once.
>>  * Decouple declaration from initialization without significant footprint or performance penalties.
>>  * Reduce the amount of static initializer and/or field initialization code.
>>  * Uphold integrity and consistency, even in a multi-threaded environment.
>>  
>> For more details, see the draft JEP: https://openjdk.org/jeps/8312611
>> 
>> ## Performance 
>> Performance compared to instance variables using an `AtomicReference` and one protected by double-checked locking under concurrent access by 8 threads:
>> 
>> 
>> Benchmark                       Mode  Cnt  Score   Error  Units
>> StableBenchmark.instanceAtomic  avgt   10  1.576 ? 0.052  ns/op
>> StableBenchmark.instanceDCL     avgt   10  1.608 ? 0.059  ns/op
>> StableBenchmark.instanceStable  avgt   10  0.979 ? 0.023  ns/op <- StableValue (~40% faster than DCL)
>> 
>> 
>> Performance compared to static variables protected by `AtomicReference`, class-holder idiom holder, and double-checked locking (8 threads):
>> 
>> 
>> Benchmark                       Mode  Cnt  Score   Error  Units
>> StableBenchmark.staticAtomic    avgt   10  1.335 ? 0.056  ns/op
>> StableBenchmark.staticCHI       avgt   10  0.623 ? 0.086  ns/op
>> StableBenchmark.staticDCL       avgt   10  1.418 ? 0.171  ns/op
>> StableBenchmark.staticList      avgt   10  0.617 ? 0.024  ns/op
>> StableBenchmark.staticStable    avgt   10  0.604 ? 0.022  ns/op <- StableValue ( > 2x faster than `AtomicInteger` and DCL)
>> 
>> 
>> Performance for stable lists in both instance and static contexts whereby the sum of random contents is calculated for stable lists (which are thread-safe) compared to `ArrayList` instances (which are not thread-safe) (under single thread access):
>> 
>> 
>> Benchmark                                     Mode  Cnt  Score   Error  Units
>> StableListSumBenchmark.instanceArrayList      avgt   10  0.356 ? 0.005  ns/op
>> StableListSumBenchmark.instanceList           avgt   10  0.373 ? 0.017  ns/op <- Stable list
>> StableListSumBenchmark.staticArrayList        avgt   10  0.352 ? ...
>
> src/hotspot/share/ci/ciField.cpp line 262:
> 
>> 260: const char* stable_array3d_klass_name = "jdk/internal/lang/StableArray3D";
>> 261: 
>> 262: static bool trust_final_non_static_fields_of_type(Symbol* signature) {
> 
> Is there a better way of doing this?

How do we check if the type implements `TrustedFieldType` in C?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18794#discussion_r1599836419

From heidinga at openjdk.org  Tue May 14 14:14:24 2024
From: heidinga at openjdk.org (Dan Heidinga)
Date: Tue, 14 May 2024 14:14:24 GMT
Subject: RFR: 8330465: Stable Values and Collections (Internal)
In-Reply-To: <-KSimQo5kkmCzzMShqGe5QZ9yCSzpWL98gN13v4wP0k=.11dd8d06-18a6-4577-8342-66632cea0b6e@github.com>
References: <-KSimQo5kkmCzzMShqGe5QZ9yCSzpWL98gN13v4wP0k=.11dd8d06-18a6-4577-8342-66632cea0b6e@github.com>
Message-ID: <u_EKRoeEG2ER_hkDC4UVHxVt79hDOnTr9r9-lKeFWQY=.4e855a49-48d1-4a86-bd41-5a2d4122433f@github.com>

On Tue, 16 Apr 2024 11:47:23 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> # Stable Values & Collections (Internal)
> 
> ## Summary
> This PR proposes to introduce an internal _Stable Values & Collections_ API, which provides immutable value holders where elements are initialized _at most once_. Stable Values & Collections offer the performance and safety benefits of final fields while offering greater flexibility as to the timing of initialization.
> 
> ## Goals
>  * Provide an easy and intuitive API to describe value holders that can change at most once.
>  * Decouple declaration from initialization without significant footprint or performance penalties.
>  * Reduce the amount of static initializer and/or field initialization code.
>  * Uphold integrity and consistency, even in a multi-threaded environment.
>  
> For more details, see the draft JEP: https://openjdk.org/jeps/8312611
> 
> ## Performance 
> Performance compared to instance variables using an `AtomicReference` and one protected by double-checked locking under concurrent access by 8 threads:
> 
> 
> Benchmark                       Mode  Cnt  Score   Error  Units
> StableBenchmark.instanceAtomic  avgt   10  1.576 ? 0.052  ns/op
> StableBenchmark.instanceDCL     avgt   10  1.608 ? 0.059  ns/op
> StableBenchmark.instanceStable  avgt   10  0.979 ? 0.023  ns/op <- StableValue (~40% faster than DCL)
> 
> 
> Performance compared to static variables protected by `AtomicReference`, class-holder idiom holder, and double-checked locking (8 threads):
> 
> 
> Benchmark                       Mode  Cnt  Score   Error  Units
> StableBenchmark.staticAtomic    avgt   10  1.335 ? 0.056  ns/op
> StableBenchmark.staticCHI       avgt   10  0.623 ? 0.086  ns/op
> StableBenchmark.staticDCL       avgt   10  1.418 ? 0.171  ns/op
> StableBenchmark.staticList      avgt   10  0.617 ? 0.024  ns/op
> StableBenchmark.staticStable    avgt   10  0.604 ? 0.022  ns/op <- StableValue ( > 2x faster than `AtomicInteger` and DCL)
> 
> 
> Performance for stable lists in both instance and static contexts whereby the sum of random contents is calculated for stable lists (which are thread-safe) compared to `ArrayList` instances (which are not thread-safe) (under single thread access):
> 
> 
> Benchmark                                     Mode  Cnt  Score   Error  Units
> StableListSumBenchmark.instanceArrayList      avgt   10  0.356 ? 0.005  ns/op
> StableListSumBenchmark.instanceList           avgt   10  0.373 ? 0.017  ns/op <- Stable list
> StableListSumBenchmark.staticArrayList        avgt   10  0.352 ? 0.002  ns/op
> StableListSumBenchmark.staticList             avgt   10  0.356 ? 0.00...

src/java.base/share/classes/java/lang/reflect/AccessibleObject.java line 193:

> 191:      * <li>final fields declared in a {@linkplain Class#isHidden() hidden class}</li>
> 192:      * <li>final fields declared in a {@linkplain Class#isRecord() record}</li>
> 193:      * <li>final fields of type {@linkplain StableValue StableValue}</li>

In Valhalla, we've been looking at adding "strict" final fields to support value classes (which must be strongly immutable) which are fields that are unmodifiable.  Most of the existing unmodifiable field cases can be covered by "strict" fields.  This one can't though so I'm a little saddened to see this list grow.

src/java.base/share/classes/java/lang/reflect/Field.java line 179:

> 177:         AccessibleObject.checkPermission();
> 178:         if (flag) {
> 179:             if (StableValue.class.isAssignableFrom(type) && Modifier.isFinal(modifiers)) {

Should this check be done regardless of the value of "flag"?  If it failed always when calling ::setAccessible on a StableValue, we'd make it easier to find bugs and the contract for users would be clearer

src/java.base/share/classes/java/lang/reflect/Field.java line 181:

> 179:             if (StableValue.class.isAssignableFrom(type) && Modifier.isFinal(modifiers)) {
> 180:                 throw newInaccessibleObjectException(
> 181:                         "Unable to make field " + this + " accessable: " +

Suggestion:

                        "Unable to make field " + this + " accessible: " +

src/java.base/share/classes/java/util/ImmutableCollections.java line 183:

> 181:                                                K key,
> 182:                                                Function<? super K, ? extends V> mapper) {
> 183:                     if (map instanceof HasComputeIfUnset) {

Can we use pattern matching instanceof here?

if (map instance HasComputeIfUnset uc) {

src/java.base/share/classes/jdk/internal/lang/StableArray.java line 25:

> 23:  * @since 23
> 24:  */
> 25: public sealed interface StableArray<V>

Do we have a use case for StableArray beyond those of StableList?

src/java.base/share/classes/jdk/internal/lang/StableValue.java line 47:

> 45:  * An atomic, thread-safe, stable value holder for which the value can be set at most once.
> 46:  * <p>
> 47:  * Stable values are eligible for constant folding and other optimizations by the JVM.

Other values are also eligible for constant folding.  Trying to spec in terms of the optimizations that the JVM may do is usually an unstable state.  Better to spec in terms of what the user observable behaviour is and leave it at something like "unlocks further JVM optimizations".

src/java.base/share/classes/jdk/internal/lang/StableValue.java line 130:

> 128:      * } else {
> 129:      *     V newValue = supplier.get();
> 130:      *     stable.setOrThrow(newValue);

If ::computeIfUnset allows racy sets, then it isn't equivalent to this code as ::setOrThrow will throw on a race, correct?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18794#discussion_r1575048707
PR Review Comment: https://git.openjdk.org/jdk/pull/18794#discussion_r1575005661
PR Review Comment: https://git.openjdk.org/jdk/pull/18794#discussion_r1574997174
PR Review Comment: https://git.openjdk.org/jdk/pull/18794#discussion_r1575014234
PR Review Comment: https://git.openjdk.org/jdk/pull/18794#discussion_r1584931870
PR Review Comment: https://git.openjdk.org/jdk/pull/18794#discussion_r1575025174
PR Review Comment: https://git.openjdk.org/jdk/pull/18794#discussion_r1575030995

From pminborg at openjdk.org  Tue May 14 14:14:24 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 14 May 2024 14:14:24 GMT
Subject: RFR: 8330465: Stable Values and Collections (Internal)
In-Reply-To: <u_EKRoeEG2ER_hkDC4UVHxVt79hDOnTr9r9-lKeFWQY=.4e855a49-48d1-4a86-bd41-5a2d4122433f@github.com>
References: <-KSimQo5kkmCzzMShqGe5QZ9yCSzpWL98gN13v4wP0k=.11dd8d06-18a6-4577-8342-66632cea0b6e@github.com>
 <u_EKRoeEG2ER_hkDC4UVHxVt79hDOnTr9r9-lKeFWQY=.4e855a49-48d1-4a86-bd41-5a2d4122433f@github.com>
Message-ID: <KNJR16zdUgDJopccv2xKV8c9F67NK73sa0AnTLaZVHA=.b690ded3-8509-492d-8cfe-63bd5fb3209c@github.com>

On Mon, 22 Apr 2024 16:31:15 GMT, Dan Heidinga <heidinga at openjdk.org> wrote:

>> # Stable Values & Collections (Internal)
>> 
>> ## Summary
>> This PR proposes to introduce an internal _Stable Values & Collections_ API, which provides immutable value holders where elements are initialized _at most once_. Stable Values & Collections offer the performance and safety benefits of final fields while offering greater flexibility as to the timing of initialization.
>> 
>> ## Goals
>>  * Provide an easy and intuitive API to describe value holders that can change at most once.
>>  * Decouple declaration from initialization without significant footprint or performance penalties.
>>  * Reduce the amount of static initializer and/or field initialization code.
>>  * Uphold integrity and consistency, even in a multi-threaded environment.
>>  
>> For more details, see the draft JEP: https://openjdk.org/jeps/8312611
>> 
>> ## Performance 
>> Performance compared to instance variables using an `AtomicReference` and one protected by double-checked locking under concurrent access by 8 threads:
>> 
>> 
>> Benchmark                       Mode  Cnt  Score   Error  Units
>> StableBenchmark.instanceAtomic  avgt   10  1.576 ? 0.052  ns/op
>> StableBenchmark.instanceDCL     avgt   10  1.608 ? 0.059  ns/op
>> StableBenchmark.instanceStable  avgt   10  0.979 ? 0.023  ns/op <- StableValue (~40% faster than DCL)
>> 
>> 
>> Performance compared to static variables protected by `AtomicReference`, class-holder idiom holder, and double-checked locking (8 threads):
>> 
>> 
>> Benchmark                       Mode  Cnt  Score   Error  Units
>> StableBenchmark.staticAtomic    avgt   10  1.335 ? 0.056  ns/op
>> StableBenchmark.staticCHI       avgt   10  0.623 ? 0.086  ns/op
>> StableBenchmark.staticDCL       avgt   10  1.418 ? 0.171  ns/op
>> StableBenchmark.staticList      avgt   10  0.617 ? 0.024  ns/op
>> StableBenchmark.staticStable    avgt   10  0.604 ? 0.022  ns/op <- StableValue ( > 2x faster than `AtomicInteger` and DCL)
>> 
>> 
>> Performance for stable lists in both instance and static contexts whereby the sum of random contents is calculated for stable lists (which are thread-safe) compared to `ArrayList` instances (which are not thread-safe) (under single thread access):
>> 
>> 
>> Benchmark                                     Mode  Cnt  Score   Error  Units
>> StableListSumBenchmark.instanceArrayList      avgt   10  0.356 ? 0.005  ns/op
>> StableListSumBenchmark.instanceList           avgt   10  0.373 ? 0.017  ns/op <- Stable list
>> StableListSumBenchmark.staticArrayList        avgt   10  0.352 ? ...
>
> src/java.base/share/classes/java/lang/reflect/AccessibleObject.java line 193:
> 
>> 191:      * <li>final fields declared in a {@linkplain Class#isHidden() hidden class}</li>
>> 192:      * <li>final fields declared in a {@linkplain Class#isRecord() record}</li>
>> 193:      * <li>final fields of type {@linkplain StableValue StableValue}</li>
> 
> In Valhalla, we've been looking at adding "strict" final fields to support value classes (which must be strongly immutable) which are fields that are unmodifiable.  Most of the existing unmodifiable field cases can be covered by "strict" fields.  This one can't though so I'm a little saddened to see this list grow.

Maybe we could introduce a special marker interface (e.g. `TrustedFieldType`) that signals this behavior. This might only take effect if loaded via the boot loader.

> src/java.base/share/classes/java/util/ImmutableCollections.java line 183:
> 
>> 181:                                                K key,
>> 182:                                                Function<? super K, ? extends V> mapper) {
>> 183:                     if (map instanceof HasComputeIfUnset) {
> 
> Can we use pattern matching instanceof here?
> 
> if (map instance HasComputeIfUnset uc) {

Good idea.

> src/java.base/share/classes/jdk/internal/lang/StableArray.java line 25:
> 
>> 23:  * @since 23
>> 24:  */
>> 25: public sealed interface StableArray<V>
> 
> Do we have a use case for StableArray beyond those of StableList?

I am trying to model multi-dimensional arrays that also provide flattening. Let's see if it becomes useful.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18794#discussion_r1576158929
PR Review Comment: https://git.openjdk.org/jdk/pull/18794#discussion_r1575929756
PR Review Comment: https://git.openjdk.org/jdk/pull/18794#discussion_r1591465182

From heidinga at openjdk.org  Tue May 14 14:14:24 2024
From: heidinga at openjdk.org (Dan Heidinga)
Date: Tue, 14 May 2024 14:14:24 GMT
Subject: RFR: 8330465: Stable Values and Collections (Internal)
In-Reply-To: <KNJR16zdUgDJopccv2xKV8c9F67NK73sa0AnTLaZVHA=.b690ded3-8509-492d-8cfe-63bd5fb3209c@github.com>
References: <-KSimQo5kkmCzzMShqGe5QZ9yCSzpWL98gN13v4wP0k=.11dd8d06-18a6-4577-8342-66632cea0b6e@github.com>
 <u_EKRoeEG2ER_hkDC4UVHxVt79hDOnTr9r9-lKeFWQY=.4e855a49-48d1-4a86-bd41-5a2d4122433f@github.com>
 <KNJR16zdUgDJopccv2xKV8c9F67NK73sa0AnTLaZVHA=.b690ded3-8509-492d-8cfe-63bd5fb3209c@github.com>
Message-ID: <xWKYbtCoV8sVwvZt_KFxaaX7x6vL2iYwdtt1_ZCRO-U=.14f4b212-a708-40e6-9e77-a12977eaa61e@github.com>

On Tue, 23 Apr 2024 12:22:25 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/reflect/AccessibleObject.java line 193:
>> 
>>> 191:      * <li>final fields declared in a {@linkplain Class#isHidden() hidden class}</li>
>>> 192:      * <li>final fields declared in a {@linkplain Class#isRecord() record}</li>
>>> 193:      * <li>final fields of type {@linkplain StableValue StableValue}</li>
>> 
>> In Valhalla, we've been looking at adding "strict" final fields to support value classes (which must be strongly immutable) which are fields that are unmodifiable.  Most of the existing unmodifiable field cases can be covered by "strict" fields.  This one can't though so I'm a little saddened to see this list grow.
>
> Maybe we could introduce a special marker interface (e.g. `TrustedFieldType`) that signals this behavior. This might only take effect if loaded via the boot loader.

Thinking on this more, hidden classes & records & value classes can all be dealt with by the introduction of strict fields.  Adding a new type - TrustedFieldType - when we'll eventually only have 1 type here - StableValue - seems like an unnecessary tradeoff.

If we ever have to add a second type here, then it's probably worth revisiting this idea.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18794#discussion_r1584921294

From pminborg at openjdk.org  Tue May 14 14:14:24 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 14 May 2024 14:14:24 GMT
Subject: RFR: 8330465: Stable Values and Collections (Internal)
In-Reply-To: <NocbzqVlFju0c_kxXvHuc7_vl63fPOESb0iBRIqoq7o=.048a578e-dd3f-497e-9280-bd9d7ad272c3@github.com>
References: <-KSimQo5kkmCzzMShqGe5QZ9yCSzpWL98gN13v4wP0k=.11dd8d06-18a6-4577-8342-66632cea0b6e@github.com>
 <Seu0-m1vs1QrM_C5sZgDSp5aGWRwgW5hTguQPTBI02I=.aaabcfc9-204e-4bd2-830e-dc8d39715a83@github.com>
 <_mwOb-4riQczNG6UoDy6S4ti7I68dYvcLAY3dzLNZaQ=.71a67ede-0f64-452e-bfec-4db95b25338b@github.com>
 <NocbzqVlFju0c_kxXvHuc7_vl63fPOESb0iBRIqoq7o=.048a578e-dd3f-497e-9280-bd9d7ad272c3@github.com>
Message-ID: <taTnj4XfBOSuBnxN9urOLUtXWooaeAfgJYOee4OtQ1U=.030da31d-4f53-4bf0-a122-b9b41a9b3144@github.com>

On Mon, 13 May 2024 12:18:28 GMT, Chen Liang <liach at openjdk.org> wrote:

>> As we need the array in both cases, how would such a solution look like without duplicating code?
>
> I was thinking about changing the StableEnumMap factory to directly take an EnumSet/BitSet indicating the indices without conversions to full objects and arrays.

Sounds like a good idea. I will fix this.

>> I see what you mean with distinct initialization logic. This is not the intended use though. 
>> 
>> The reason these methods exist is to avoid lambda capturing. Let's say we have a `Function<K, V>` we want to apply to a `Map<K, StableValue<V>>`. Then, retrieving a `stable = StableValue<V>` and applying `stable.computeIfUnset(() -> function.apply(key))` would capture a new `Supplier`. Another alternative would be to write imperative code similar to what is already in these methods.
>> 
>> What we could do is provide factories for memorized functions (the latter described in the draft JEP at the end (https://openjdk.org/jeps/8312611) ) even though these are easy to write.
>> 
>> I think what you are proposing is something like this?
>> 
>> 
>> Map<K, StableValue<V>> map = StableValue.ofMap(keys, k -> createV(k));
>> 
>> 
>> or perhaps even:
>> 
>> 
>> Map<K, V> map = StableValue.ofMap(keys, k -> createV(k));
>
> Yes, consider the 3 capture scenarios:
> | API | Capture frequency | Capture Impact | Code Convenience | Flexibility |
> |-----|-------------------|----------------|------------------|-------------|
> | `StableValue.ofMap(map, k -> ...)` | By accident | single capture is reused | OK | One generator for all keys |
> | `StableValue.computeIfUnset(map, key, k -> ...)` | By accident | capture happens for all access sites | somewhat ugly | Different generator for different keys |
> | `map.get(k).computeIfUnset(() -> ...)` | Always | capture happens for all access sites | OK | Different generator for different keys |
> 
> Notice the `ofMap` factory is the most tolerant to faulty captures: even if it captures, the single capturing lambda is reused for all map stables, avoiding capture overheads at access sites. Given Java compiler doesn't tell user anything about captures during compilation, I think `ofMap` is a better factory to avoid accidentally writing capturing lambdas.

I see what you mean. Initially, I thought it would be easy to create memorized functions but it turned out, that was not the case if one wants to retain easy debugability etc. So, I have added a couple of factory methods including this:


    /**
     * {@return a new <em>memoized</em> {@linkplain Function } backed by an internal
     * stable map with the provided {@code inputs} keys where the provided
     * {@code original} Function will only be invoked at most once per distinct input}
     *
     * @param original the original Function to convert to a memoized Function
     * @param inputs   the potential input values to the Function
     * @param <T>      the type of input values
     * @param <R>      the return type of the function
     */
    static <T, R> Function<T, R> ofFunction(Set<? extends T> inputs,
                                            Function<? super T, ? extends R> original) {
        Objects.requireNonNull(inputs);
        Objects.requireNonNull(original);
        ...
    }

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18794#discussion_r1600035236
PR Review Comment: https://git.openjdk.org/jdk/pull/18794#discussion_r1568671241

From pminborg at openjdk.org  Tue May 14 14:14:25 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 14 May 2024 14:14:25 GMT
Subject: RFR: 8330465: Stable Values and Collections (Internal)
In-Reply-To: <KNJR16zdUgDJopccv2xKV8c9F67NK73sa0AnTLaZVHA=.b690ded3-8509-492d-8cfe-63bd5fb3209c@github.com>
References: <-KSimQo5kkmCzzMShqGe5QZ9yCSzpWL98gN13v4wP0k=.11dd8d06-18a6-4577-8342-66632cea0b6e@github.com>
 <u_EKRoeEG2ER_hkDC4UVHxVt79hDOnTr9r9-lKeFWQY=.4e855a49-48d1-4a86-bd41-5a2d4122433f@github.com>
 <KNJR16zdUgDJopccv2xKV8c9F67NK73sa0AnTLaZVHA=.b690ded3-8509-492d-8cfe-63bd5fb3209c@github.com>
Message-ID: <e5qPvuiub0okpjtfqSmHqnrfPjJ-ZmXoNwDjfSSRntQ=.0ab53c98-72ca-4d60-9dae-440c75113d9b@github.com>

On Tue, 23 Apr 2024 09:17:29 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> src/java.base/share/classes/java/util/ImmutableCollections.java line 183:
>> 
>>> 181:                                                K key,
>>> 182:                                                Function<? super K, ? extends V> mapper) {
>>> 183:                     if (map instanceof HasComputeIfUnset) {
>> 
>> Can we use pattern matching instanceof here?
>> 
>> if (map instance HasComputeIfUnset uc) {
>
> Good idea.

Ahh. I thought you meant pattern matching in another place (which actually turned out to be a really good idea). Here, however, we also need to get the type parameters correct:

<img width="926" alt="image" src="https://github.com/openjdk/jdk/assets/7457876/b2a66033-4c74-42bc-a9de-a976c441ca61">

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18794#discussion_r1576154547

From liach at openjdk.org  Tue May 14 14:14:25 2024
From: liach at openjdk.org (Chen Liang)
Date: Tue, 14 May 2024 14:14:25 GMT
Subject: RFR: 8330465: Stable Values and Collections (Internal)
In-Reply-To: <e5qPvuiub0okpjtfqSmHqnrfPjJ-ZmXoNwDjfSSRntQ=.0ab53c98-72ca-4d60-9dae-440c75113d9b@github.com>
References: <-KSimQo5kkmCzzMShqGe5QZ9yCSzpWL98gN13v4wP0k=.11dd8d06-18a6-4577-8342-66632cea0b6e@github.com>
 <u_EKRoeEG2ER_hkDC4UVHxVt79hDOnTr9r9-lKeFWQY=.4e855a49-48d1-4a86-bd41-5a2d4122433f@github.com>
 <KNJR16zdUgDJopccv2xKV8c9F67NK73sa0AnTLaZVHA=.b690ded3-8509-492d-8cfe-63bd5fb3209c@github.com>
 <e5qPvuiub0okpjtfqSmHqnrfPjJ-ZmXoNwDjfSSRntQ=.0ab53c98-72ca-4d60-9dae-440c75113d9b@github.com>
Message-ID: <eVtSNT6vi4mrhti_wyokgbm6wAkxCsPWR0QktV-5Kbc=.ca792c4b-2f3d-4e72-9015-4c4b7dc9415a@github.com>

On Tue, 23 Apr 2024 12:18:53 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> Good idea.
>
> Ahh. I thought you meant pattern matching in another place (which actually turned out to be a really good idea). Here, however, we also need to get the type parameters correct:
> 
> <img width="926" alt="image" src="https://github.com/openjdk/jdk/assets/7457876/b2a66033-4c74-42bc-a9de-a976c441ca61">

Would you still need a cast if you declare `HasComputeIfUnset` with `extends Map<K, StableValue<V>>`?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18794#discussion_r1581828542

From mcimadamore at openjdk.org  Tue May 14 14:14:25 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 14 May 2024 14:14:25 GMT
Subject: RFR: 8330465: Stable Values and Collections (Internal)
In-Reply-To: <-KSimQo5kkmCzzMShqGe5QZ9yCSzpWL98gN13v4wP0k=.11dd8d06-18a6-4577-8342-66632cea0b6e@github.com>
References: <-KSimQo5kkmCzzMShqGe5QZ9yCSzpWL98gN13v4wP0k=.11dd8d06-18a6-4577-8342-66632cea0b6e@github.com>
Message-ID: <KVx50rRkCfA4HYux3rJmvOl-sL4oba6Z_pJprgsPKUE=.e4fe588d-6f27-4b0b-b772-bb95f119c7a4@github.com>

On Tue, 16 Apr 2024 11:47:23 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> # Stable Values & Collections (Internal)
> 
> ## Summary
> This PR proposes to introduce an internal _Stable Values & Collections_ API, which provides immutable value holders where elements are initialized _at most once_. Stable Values & Collections offer the performance and safety benefits of final fields while offering greater flexibility as to the timing of initialization.
> 
> ## Goals
>  * Provide an easy and intuitive API to describe value holders that can change at most once.
>  * Decouple declaration from initialization without significant footprint or performance penalties.
>  * Reduce the amount of static initializer and/or field initialization code.
>  * Uphold integrity and consistency, even in a multi-threaded environment.
>  
> For more details, see the draft JEP: https://openjdk.org/jeps/8312611
> 
> ## Performance 
> Performance compared to instance variables using an `AtomicReference` and one protected by double-checked locking under concurrent access by 8 threads:
> 
> 
> Benchmark                       Mode  Cnt  Score   Error  Units
> StableBenchmark.instanceAtomic  avgt   10  1.576 ? 0.052  ns/op
> StableBenchmark.instanceDCL     avgt   10  1.608 ? 0.059  ns/op
> StableBenchmark.instanceStable  avgt   10  0.979 ? 0.023  ns/op <- StableValue (~40% faster than DCL)
> 
> 
> Performance compared to static variables protected by `AtomicReference`, class-holder idiom holder, and double-checked locking (8 threads):
> 
> 
> Benchmark                       Mode  Cnt  Score   Error  Units
> StableBenchmark.staticAtomic    avgt   10  1.335 ? 0.056  ns/op
> StableBenchmark.staticCHI       avgt   10  0.623 ? 0.086  ns/op
> StableBenchmark.staticDCL       avgt   10  1.418 ? 0.171  ns/op
> StableBenchmark.staticList      avgt   10  0.617 ? 0.024  ns/op
> StableBenchmark.staticStable    avgt   10  0.604 ? 0.022  ns/op <- StableValue ( > 2x faster than `AtomicInteger` and DCL)
> 
> 
> Performance for stable lists in both instance and static contexts whereby the sum of random contents is calculated for stable lists (which are thread-safe) compared to `ArrayList` instances (which are not thread-safe) (under single thread access):
> 
> 
> Benchmark                                     Mode  Cnt  Score   Error  Units
> StableListSumBenchmark.instanceArrayList      avgt   10  0.356 ? 0.005  ns/op
> StableListSumBenchmark.instanceList           avgt   10  0.373 ? 0.017  ns/op <- Stable list
> StableListSumBenchmark.staticArrayList        avgt   10  0.352 ? 0.002  ns/op
> StableListSumBenchmark.staticList             avgt   10  0.356 ? 0.00...

src/java.base/share/classes/java/util/ImmutableCollections.java line 1505:

> 1503:     }
> 1504: 
> 1505:     static final class StableMap<K, V>

Question: can stable maps be implemented in terms of stable lists? After all, you need a stable backing array - and then you need to have a way to go from a key to an index in the stable array. The logic that does key->index conversion belongs to Map, but after that we should be able to just "delegate" to StableList?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18794#discussion_r1568940281

From pminborg at openjdk.org  Tue May 14 14:14:25 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 14 May 2024 14:14:25 GMT
Subject: RFR: 8330465: Stable Values and Collections (Internal)
In-Reply-To: <KVx50rRkCfA4HYux3rJmvOl-sL4oba6Z_pJprgsPKUE=.e4fe588d-6f27-4b0b-b772-bb95f119c7a4@github.com>
References: <-KSimQo5kkmCzzMShqGe5QZ9yCSzpWL98gN13v4wP0k=.11dd8d06-18a6-4577-8342-66632cea0b6e@github.com>
 <KVx50rRkCfA4HYux3rJmvOl-sL4oba6Z_pJprgsPKUE=.e4fe588d-6f27-4b0b-b772-bb95f119c7a4@github.com>
Message-ID: <2AUE4xXjgoZVxHkOGorI8NtSE4jQOXsWZc4zxheDGp0=.559a1456-bee2-41e5-bcdc-9ee7056be848@github.com>

On Wed, 17 Apr 2024 14:24:59 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> # Stable Values & Collections (Internal)
>> 
>> ## Summary
>> This PR proposes to introduce an internal _Stable Values & Collections_ API, which provides immutable value holders where elements are initialized _at most once_. Stable Values & Collections offer the performance and safety benefits of final fields while offering greater flexibility as to the timing of initialization.
>> 
>> ## Goals
>>  * Provide an easy and intuitive API to describe value holders that can change at most once.
>>  * Decouple declaration from initialization without significant footprint or performance penalties.
>>  * Reduce the amount of static initializer and/or field initialization code.
>>  * Uphold integrity and consistency, even in a multi-threaded environment.
>>  
>> For more details, see the draft JEP: https://openjdk.org/jeps/8312611
>> 
>> ## Performance 
>> Performance compared to instance variables using an `AtomicReference` and one protected by double-checked locking under concurrent access by 8 threads:
>> 
>> 
>> Benchmark                       Mode  Cnt  Score   Error  Units
>> StableBenchmark.instanceAtomic  avgt   10  1.576 ? 0.052  ns/op
>> StableBenchmark.instanceDCL     avgt   10  1.608 ? 0.059  ns/op
>> StableBenchmark.instanceStable  avgt   10  0.979 ? 0.023  ns/op <- StableValue (~40% faster than DCL)
>> 
>> 
>> Performance compared to static variables protected by `AtomicReference`, class-holder idiom holder, and double-checked locking (8 threads):
>> 
>> 
>> Benchmark                       Mode  Cnt  Score   Error  Units
>> StableBenchmark.staticAtomic    avgt   10  1.335 ? 0.056  ns/op
>> StableBenchmark.staticCHI       avgt   10  0.623 ? 0.086  ns/op
>> StableBenchmark.staticDCL       avgt   10  1.418 ? 0.171  ns/op
>> StableBenchmark.staticList      avgt   10  0.617 ? 0.024  ns/op
>> StableBenchmark.staticStable    avgt   10  0.604 ? 0.022  ns/op <- StableValue ( > 2x faster than `AtomicInteger` and DCL)
>> 
>> 
>> Performance for stable lists in both instance and static contexts whereby the sum of random contents is calculated for stable lists (which are thread-safe) compared to `ArrayList` instances (which are not thread-safe) (under single thread access):
>> 
>> 
>> Benchmark                                     Mode  Cnt  Score   Error  Units
>> StableListSumBenchmark.instanceArrayList      avgt   10  0.356 ? 0.005  ns/op
>> StableListSumBenchmark.instanceList           avgt   10  0.373 ? 0.017  ns/op <- Stable list
>> StableListSumBenchmark.staticArrayList        avgt   10  0.352 ? ...
>
> src/java.base/share/classes/java/util/ImmutableCollections.java line 1505:
> 
>> 1503:     }
>> 1504: 
>> 1505:     static final class StableMap<K, V>
> 
> Question: can stable maps be implemented in terms of stable lists? After all, you need a stable backing array - and then you need to have a way to go from a key to an index in the stable array. The logic that does key->index conversion belongs to Map, but after that we should be able to just "delegate" to StableList?

This is partially done but we could pull more on this string and unify the implementations.

Incidentally, it is also possible to unify the two implementation classes of `StableValue` so it becomes monomorphic.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18794#discussion_r1570837425

From liach at openjdk.org  Tue May 14 14:14:25 2024
From: liach at openjdk.org (Chen Liang)
Date: Tue, 14 May 2024 14:14:25 GMT
Subject: RFR: 8330465: Stable Values and Collections (Internal)
In-Reply-To: <u_EKRoeEG2ER_hkDC4UVHxVt79hDOnTr9r9-lKeFWQY=.4e855a49-48d1-4a86-bd41-5a2d4122433f@github.com>
References: <-KSimQo5kkmCzzMShqGe5QZ9yCSzpWL98gN13v4wP0k=.11dd8d06-18a6-4577-8342-66632cea0b6e@github.com>
 <u_EKRoeEG2ER_hkDC4UVHxVt79hDOnTr9r9-lKeFWQY=.4e855a49-48d1-4a86-bd41-5a2d4122433f@github.com>
Message-ID: <6Ut30fvUqvy-ld6OsJCsWj8T4ImaRq_bPJrmxSbkD6U=.394965a6-d328-4af3-a07b-8088acc7e88b@github.com>

On Mon, 22 Apr 2024 16:16:39 GMT, Dan Heidinga <heidinga at openjdk.org> wrote:

>> # Stable Values & Collections (Internal)
>> 
>> ## Summary
>> This PR proposes to introduce an internal _Stable Values & Collections_ API, which provides immutable value holders where elements are initialized _at most once_. Stable Values & Collections offer the performance and safety benefits of final fields while offering greater flexibility as to the timing of initialization.
>> 
>> ## Goals
>>  * Provide an easy and intuitive API to describe value holders that can change at most once.
>>  * Decouple declaration from initialization without significant footprint or performance penalties.
>>  * Reduce the amount of static initializer and/or field initialization code.
>>  * Uphold integrity and consistency, even in a multi-threaded environment.
>>  
>> For more details, see the draft JEP: https://openjdk.org/jeps/8312611
>> 
>> ## Performance 
>> Performance compared to instance variables using an `AtomicReference` and one protected by double-checked locking under concurrent access by 8 threads:
>> 
>> 
>> Benchmark                       Mode  Cnt  Score   Error  Units
>> StableBenchmark.instanceAtomic  avgt   10  1.576 ? 0.052  ns/op
>> StableBenchmark.instanceDCL     avgt   10  1.608 ? 0.059  ns/op
>> StableBenchmark.instanceStable  avgt   10  0.979 ? 0.023  ns/op <- StableValue (~40% faster than DCL)
>> 
>> 
>> Performance compared to static variables protected by `AtomicReference`, class-holder idiom holder, and double-checked locking (8 threads):
>> 
>> 
>> Benchmark                       Mode  Cnt  Score   Error  Units
>> StableBenchmark.staticAtomic    avgt   10  1.335 ? 0.056  ns/op
>> StableBenchmark.staticCHI       avgt   10  0.623 ? 0.086  ns/op
>> StableBenchmark.staticDCL       avgt   10  1.418 ? 0.171  ns/op
>> StableBenchmark.staticList      avgt   10  0.617 ? 0.024  ns/op
>> StableBenchmark.staticStable    avgt   10  0.604 ? 0.022  ns/op <- StableValue ( > 2x faster than `AtomicInteger` and DCL)
>> 
>> 
>> Performance for stable lists in both instance and static contexts whereby the sum of random contents is calculated for stable lists (which are thread-safe) compared to `ArrayList` instances (which are not thread-safe) (under single thread access):
>> 
>> 
>> Benchmark                                     Mode  Cnt  Score   Error  Units
>> StableListSumBenchmark.instanceArrayList      avgt   10  0.356 ? 0.005  ns/op
>> StableListSumBenchmark.instanceList           avgt   10  0.373 ? 0.017  ns/op <- Stable list
>> StableListSumBenchmark.staticArrayList        avgt   10  0.352 ? ...
>
> src/java.base/share/classes/jdk/internal/lang/StableValue.java line 130:
> 
>> 128:      * } else {
>> 129:      *     V newValue = supplier.get();
>> 130:      *     stable.setOrThrow(newValue);
> 
> If ::computeIfUnset allows racy sets, then it isn't equivalent to this code as ::setOrThrow will throw on a race, correct?

Indeed, this if-else should be guarded by a synchronized block, except the lock is on the internal mutex which is not publicly exposed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18794#discussion_r1575101750

From pminborg at openjdk.org  Tue May 14 14:14:25 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 14 May 2024 14:14:25 GMT
Subject: RFR: 8330465: Stable Values and Collections (Internal)
In-Reply-To: <6Ut30fvUqvy-ld6OsJCsWj8T4ImaRq_bPJrmxSbkD6U=.394965a6-d328-4af3-a07b-8088acc7e88b@github.com>
References: <-KSimQo5kkmCzzMShqGe5QZ9yCSzpWL98gN13v4wP0k=.11dd8d06-18a6-4577-8342-66632cea0b6e@github.com>
 <u_EKRoeEG2ER_hkDC4UVHxVt79hDOnTr9r9-lKeFWQY=.4e855a49-48d1-4a86-bd41-5a2d4122433f@github.com>
 <6Ut30fvUqvy-ld6OsJCsWj8T4ImaRq_bPJrmxSbkD6U=.394965a6-d328-4af3-a07b-8088acc7e88b@github.com>
Message-ID: <F4cHoKDmVuZAAcMn4r1uC3clZNjHeDptsRrwPZ4fD9c=.12392588-464d-4fee-9a50-d16f9e98a38a@github.com>

On Mon, 22 Apr 2024 17:09:39 GMT, Chen Liang <liach at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/lang/StableValue.java line 130:
>> 
>>> 128:      * } else {
>>> 129:      *     V newValue = supplier.get();
>>> 130:      *     stable.setOrThrow(newValue);
>> 
>> If ::computeIfUnset allows racy sets, then it isn't equivalent to this code as ::setOrThrow will throw on a race, correct?
>
> Indeed, this if-else should be guarded by a synchronized block, except the lock is on the internal mutex which is not publicly exposed.

`computeIfUnset()` is indeed guarded by a synchronized block, only it sits on the method declaration of `computeIfUnsetVolatile0`. I think we should have an internal mutex. This will also correspond to the stable collections which have internal mutexes for each index/key.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18794#discussion_r1575972396

From mcimadamore at openjdk.org  Tue May 14 14:14:25 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 14 May 2024 14:14:25 GMT
Subject: RFR: 8330465: Stable Values and Collections (Internal)
In-Reply-To: <taTnj4XfBOSuBnxN9urOLUtXWooaeAfgJYOee4OtQ1U=.030da31d-4f53-4bf0-a122-b9b41a9b3144@github.com>
References: <-KSimQo5kkmCzzMShqGe5QZ9yCSzpWL98gN13v4wP0k=.11dd8d06-18a6-4577-8342-66632cea0b6e@github.com>
 <Seu0-m1vs1QrM_C5sZgDSp5aGWRwgW5hTguQPTBI02I=.aaabcfc9-204e-4bd2-830e-dc8d39715a83@github.com>
 <_mwOb-4riQczNG6UoDy6S4ti7I68dYvcLAY3dzLNZaQ=.71a67ede-0f64-452e-bfec-4db95b25338b@github.com>
 <NocbzqVlFju0c_kxXvHuc7_vl63fPOESb0iBRIqoq7o=.048a578e-dd3f-497e-9280-bd9d7ad272c3@github.com>
 <taTnj4XfBOSuBnxN9urOLUtXWooaeAfgJYOee4OtQ1U=.030da31d-4f53-4bf0-a122-b9b41a9b3144@github.com>
Message-ID: <5GDZ3F_c8E4afPEjL9CFdgt9ms5zndr5lTq17yGdFkY=.6cddeb24-3a10-493e-b8d7-9854c0e08f39@github.com>

On Wed, 17 Apr 2024 11:12:37 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> Yes, consider the 3 capture scenarios:
>> | API | Capture frequency | Capture Impact | Code Convenience | Flexibility |
>> |-----|-------------------|----------------|------------------|-------------|
>> | `StableValue.ofMap(map, k -> ...)` | By accident | single capture is reused | OK | One generator for all keys |
>> | `StableValue.computeIfUnset(map, key, k -> ...)` | By accident | capture happens for all access sites | somewhat ugly | Different generator for different keys |
>> | `map.get(k).computeIfUnset(() -> ...)` | Always | capture happens for all access sites | OK | Different generator for different keys |
>> 
>> Notice the `ofMap` factory is the most tolerant to faulty captures: even if it captures, the single capturing lambda is reused for all map stables, avoiding capture overheads at access sites. Given Java compiler doesn't tell user anything about captures during compilation, I think `ofMap` is a better factory to avoid accidentally writing capturing lambdas.
>
> I see what you mean. Initially, I thought it would be easy to create memorized functions but it turned out, that was not the case if one wants to retain easy debugability etc. So, I have added a couple of factory methods including this:
> 
> 
>     /**
>      * {@return a new <em>memoized</em> {@linkplain Function } backed by an internal
>      * stable map with the provided {@code inputs} keys where the provided
>      * {@code original} Function will only be invoked at most once per distinct input}
>      *
>      * @param original the original Function to convert to a memoized Function
>      * @param inputs   the potential input values to the Function
>      * @param <T>      the type of input values
>      * @param <R>      the return type of the function
>      */
>     static <T, R> Function<T, R> ofFunction(Set<? extends T> inputs,
>                                             Function<? super T, ? extends R> original) {
>         Objects.requireNonNull(inputs);
>         Objects.requireNonNull(original);
>         ...
>     }

I agree that these method appear to be confusing. We have:


StableValue::of()
StableValue::ofList(int)
StableValue::ofMap(Set)


These methods are clearly primitives, because they are used to create a wrapper around a stable value/array. (Actually, if you squint, the primitive is really the `ofMap` factory, since that one can be used to derive the other two as well, but that's mostly a sophism).

Everything else falls in the "helper" bucket. That is, we could have:


StableValue::ofList(IntFunction) -> List<V> // similar to StableValue::ofList(int)
StableValue::ofMap(Function) -> Map<K, V> // similar to StableValue::ofMap(Set)


Or, we could have:


StableValue::ofSupplier(Supplier) -> Supplier<V> // similar to StableValue::of()
StableValue::ofIntFunction(IntFunction) -> IntFunction<V> // similar to StableValue::ofList(int)
StableValue::ofFunction(Function) -> Function<K, V> // similar to StableValue::ofMap(Set)


IMHO, having both sets feel slightly redundant. That is, if you have a Map<K, V>, you also have a function from K, V - namely, map::get. And, conversely, if a client wants a List<V> of fixed size, which is populated lazily, using a memoized IntFunction is, effectively, the same thing.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18794#discussion_r1568840269

From liach at openjdk.org  Tue May 14 14:14:25 2024
From: liach at openjdk.org (Chen Liang)
Date: Tue, 14 May 2024 14:14:25 GMT
Subject: RFR: 8330465: Stable Values and Collections (Internal)
In-Reply-To: <5GDZ3F_c8E4afPEjL9CFdgt9ms5zndr5lTq17yGdFkY=.6cddeb24-3a10-493e-b8d7-9854c0e08f39@github.com>
References: <-KSimQo5kkmCzzMShqGe5QZ9yCSzpWL98gN13v4wP0k=.11dd8d06-18a6-4577-8342-66632cea0b6e@github.com>
 <Seu0-m1vs1QrM_C5sZgDSp5aGWRwgW5hTguQPTBI02I=.aaabcfc9-204e-4bd2-830e-dc8d39715a83@github.com>
 <_mwOb-4riQczNG6UoDy6S4ti7I68dYvcLAY3dzLNZaQ=.71a67ede-0f64-452e-bfec-4db95b25338b@github.com>
 <NocbzqVlFju0c_kxXvHuc7_vl63fPOESb0iBRIqoq7o=.048a578e-dd3f-497e-9280-bd9d7ad272c3@github.com>
 <taTnj4XfBOSuBnxN9urOLUtXWooaeAfgJYOee4OtQ1U=.030da31d-4f53-4bf0-a122-b9b41a9b3144@github.com>
 <5GDZ3F_c8E4afPEjL9CFdgt9ms5zndr5lTq17yGdFkY=.6cddeb24-3a10-493e-b8d7-9854c0e08f39@github.com>
Message-ID: <fNhYMW9CdhhW8ruZ4T552XkX3TUEX0PS2FoJmQLtucs=.21cf4f63-6a64-470d-bebf-3714399af661@github.com>

On Wed, 17 Apr 2024 13:23:53 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> I see what you mean. Initially, I thought it would be easy to create memorized functions but it turned out, that was not the case if one wants to retain easy debugability etc. So, I have added a couple of factory methods including this:
>> 
>> 
>>     /**
>>      * {@return a new <em>memoized</em> {@linkplain Function } backed by an internal
>>      * stable map with the provided {@code inputs} keys where the provided
>>      * {@code original} Function will only be invoked at most once per distinct input}
>>      *
>>      * @param original the original Function to convert to a memoized Function
>>      * @param inputs   the potential input values to the Function
>>      * @param <T>      the type of input values
>>      * @param <R>      the return type of the function
>>      */
>>     static <T, R> Function<T, R> ofFunction(Set<? extends T> inputs,
>>                                             Function<? super T, ? extends R> original) {
>>         Objects.requireNonNull(inputs);
>>         Objects.requireNonNull(original);
>>         ...
>>     }
>
> I agree that these method appear to be confusing. We have:
> 
> 
> StableValue::of()
> StableValue::ofList(int)
> StableValue::ofMap(Set)
> 
> 
> These methods are clearly primitives, because they are used to create a wrapper around a stable value/array. (Actually, if you squint, the primitive is really the `ofMap` factory, since that one can be used to derive the other two as well, but that's mostly a sophism).
> 
> Everything else falls in the "helper" bucket. That is, we could have:
> 
> 
> StableValue::ofList(IntFunction) -> List<V> // similar to StableValue::ofList(int)
> StableValue::ofMap(Function) -> Map<K, V> // similar to StableValue::ofMap(Set)
> 
> 
> Or, we could have:
> 
> 
> StableValue::ofSupplier(Supplier) -> Supplier<V> // similar to StableValue::of()
> StableValue::ofIntFunction(IntFunction) -> IntFunction<V> // similar to StableValue::ofList(int)
> StableValue::ofFunction(Function) -> Function<K, V> // similar to StableValue::ofMap(Set)
> 
> 
> IMHO, having both sets feel slightly redundant. That is, if you have a Map<K, V>, you also have a function from K, V - namely, map::get. And, conversely, if a client wants a List<V> of fixed size, which is populated lazily, using a memoized IntFunction is, effectively, the same thing.

I prefer these:

StableValue::ofSupplier(Supplier<V>) -> StableValue<V>
StableValue::ofIntFunction(keys, IntFunction<V>) -> IntFunction<StableValue<V>>
StableValue::ofFunction(keys, Function<K, V>) -> Function<K, StableValue<V>>

These still expose StableValue so users can set the values if they need. In addition, the List/Map functionalites are mostly useless so a getter/function suffices for the most part.

These APIs are less error-prone to accidental context capture compared to the individual use-site ones, as use-site leaks means each access involves an allocation, but the allocation for construction site is shared.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18794#discussion_r1568895552

From pminborg at openjdk.org  Tue May 14 14:14:25 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 14 May 2024 14:14:25 GMT
Subject: RFR: 8330465: Stable Values and Collections (Internal)
In-Reply-To: <eGwmCLM96Az7spnY1PDro2Uwckkb460i-IH7ZZWOtbw=.a12c2133-76c6-4fff-93e4-c7957d586669@github.com>
References: <-KSimQo5kkmCzzMShqGe5QZ9yCSzpWL98gN13v4wP0k=.11dd8d06-18a6-4577-8342-66632cea0b6e@github.com>
 <eGwmCLM96Az7spnY1PDro2Uwckkb460i-IH7ZZWOtbw=.a12c2133-76c6-4fff-93e4-c7957d586669@github.com>
Message-ID: <b-tcNHTV1NmpDMcjiaqHcXX1EKXYBICzp3Ay4uN78UA=.ebe1c951-5b55-488a-942b-2662eb5de019@github.com>

On Fri, 19 Apr 2024 09:32:56 GMT, ExE Boss <duke at openjdk.org> wrote:

>> # Stable Values & Collections (Internal)
>> 
>> ## Summary
>> This PR proposes to introduce an internal _Stable Values & Collections_ API, which provides immutable value holders where elements are initialized _at most once_. Stable Values & Collections offer the performance and safety benefits of final fields while offering greater flexibility as to the timing of initialization.
>> 
>> ## Goals
>>  * Provide an easy and intuitive API to describe value holders that can change at most once.
>>  * Decouple declaration from initialization without significant footprint or performance penalties.
>>  * Reduce the amount of static initializer and/or field initialization code.
>>  * Uphold integrity and consistency, even in a multi-threaded environment.
>>  
>> For more details, see the draft JEP: https://openjdk.org/jeps/8312611
>> 
>> ## Performance 
>> Performance compared to instance variables using an `AtomicReference` and one protected by double-checked locking under concurrent access by 8 threads:
>> 
>> 
>> Benchmark                       Mode  Cnt  Score   Error  Units
>> StableBenchmark.instanceAtomic  avgt   10  1.576 ? 0.052  ns/op
>> StableBenchmark.instanceDCL     avgt   10  1.608 ? 0.059  ns/op
>> StableBenchmark.instanceStable  avgt   10  0.979 ? 0.023  ns/op <- StableValue (~40% faster than DCL)
>> 
>> 
>> Performance compared to static variables protected by `AtomicReference`, class-holder idiom holder, and double-checked locking (8 threads):
>> 
>> 
>> Benchmark                       Mode  Cnt  Score   Error  Units
>> StableBenchmark.staticAtomic    avgt   10  1.335 ? 0.056  ns/op
>> StableBenchmark.staticCHI       avgt   10  0.623 ? 0.086  ns/op
>> StableBenchmark.staticDCL       avgt   10  1.418 ? 0.171  ns/op
>> StableBenchmark.staticList      avgt   10  0.617 ? 0.024  ns/op
>> StableBenchmark.staticStable    avgt   10  0.604 ? 0.022  ns/op <- StableValue ( > 2x faster than `AtomicInteger` and DCL)
>> 
>> 
>> Performance for stable lists in both instance and static contexts whereby the sum of random contents is calculated for stable lists (which are thread-safe) compared to `ArrayList` instances (which are not thread-safe) (under single thread access):
>> 
>> 
>> Benchmark                                     Mode  Cnt  Score   Error  Units
>> StableListSumBenchmark.instanceArrayList      avgt   10  0.356 ? 0.005  ns/op
>> StableListSumBenchmark.instanceList           avgt   10  0.373 ? 0.017  ns/op <- Stable list
>> StableListSumBenchmark.staticArrayList        avgt   10  0.352 ? ...
>
> src/java.base/share/classes/jdk/internal/lang/stable/StableValueElement.java line 116:
> 
>> 114:     public V computeIfUnset(Supplier<? extends V> supplier) {
>> 115:         // Todo: This creates a lambda
>> 116:         return computeIfUnsetShared(supplier, Supplier::get);
> 
> Suggestion:
> 
>         return computeIfUnsetShared(supplier, supplierExtractor());

Yes. This is a work in progress. I will explore using a `BiFunction` instead.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18794#discussion_r1574446126

From pminborg at openjdk.org  Tue May 14 14:14:25 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 14 May 2024 14:14:25 GMT
Subject: RFR: 8330465: Stable Values and Collections (Internal)
In-Reply-To: <b-tcNHTV1NmpDMcjiaqHcXX1EKXYBICzp3Ay4uN78UA=.ebe1c951-5b55-488a-942b-2662eb5de019@github.com>
References: <-KSimQo5kkmCzzMShqGe5QZ9yCSzpWL98gN13v4wP0k=.11dd8d06-18a6-4577-8342-66632cea0b6e@github.com>
 <eGwmCLM96Az7spnY1PDro2Uwckkb460i-IH7ZZWOtbw=.a12c2133-76c6-4fff-93e4-c7957d586669@github.com>
 <b-tcNHTV1NmpDMcjiaqHcXX1EKXYBICzp3Ay4uN78UA=.ebe1c951-5b55-488a-942b-2662eb5de019@github.com>
Message-ID: <Ebrw3spsZUkBfLSo-clZP5QVuGMwUTRaswI1CcUxAcw=.ca63e579-2925-448f-acf9-10e8111881f2@github.com>

On Mon, 22 Apr 2024 09:34:39 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/lang/stable/StableValueElement.java line 116:
>> 
>>> 114:     public V computeIfUnset(Supplier<? extends V> supplier) {
>>> 115:         // Todo: This creates a lambda
>>> 116:         return computeIfUnsetShared(supplier, Supplier::get);
>> 
>> Suggestion:
>> 
>>         return computeIfUnsetShared(supplier, supplierExtractor());
>
> Yes. This is a work in progress. I will explore using a `BiFunction` instead.

I've converted to pattern matching instead.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18794#discussion_r1576155645

From alanb at openjdk.org  Tue May 14 14:22:07 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 14 May 2024 14:22:07 GMT
Subject: RFR: 8330465: Stable Values and Collections (Internal)
In-Reply-To: <-KSimQo5kkmCzzMShqGe5QZ9yCSzpWL98gN13v4wP0k=.11dd8d06-18a6-4577-8342-66632cea0b6e@github.com>
References: <-KSimQo5kkmCzzMShqGe5QZ9yCSzpWL98gN13v4wP0k=.11dd8d06-18a6-4577-8342-66632cea0b6e@github.com>
Message-ID: <z7KTwCoVfWrZvMwUicEl4V97brfKRzgzVB2oP7VEILo=.e62db5da-6ca4-4be5-ba99-63cf54ffd06b@github.com>

On Tue, 16 Apr 2024 11:47:23 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> # Stable Values & Collections (Internal)
> 
> ## Summary
> This PR proposes to introduce an internal _Stable Values & Collections_ API, which provides immutable value holders where elements are initialized _at most once_. Stable Values & Collections offer the performance and safety benefits of final fields while offering greater flexibility as to the timing of initialization.
> 
> ## Goals
>  * Provide an easy and intuitive API to describe value holders that can change at most once.
>  * Decouple declaration from initialization without significant footprint or performance penalties.
>  * Reduce the amount of static initializer and/or field initialization code.
>  * Uphold integrity and consistency, even in a multi-threaded environment.
>  
> For more details, see the draft JEP: https://openjdk.org/jeps/8312611
> 
> ## Performance 
> Performance compared to instance variables using an `AtomicReference` and one protected by double-checked locking under concurrent access by 8 threads:
> 
> 
> Benchmark                       Mode  Cnt  Score   Error  Units
> StableBenchmark.instanceAtomic  avgt   10  1.576 ? 0.052  ns/op
> StableBenchmark.instanceDCL     avgt   10  1.608 ? 0.059  ns/op
> StableBenchmark.instanceStable  avgt   10  0.979 ? 0.023  ns/op <- StableValue (~40% faster than DCL)
> 
> 
> Performance compared to static variables protected by `AtomicReference`, class-holder idiom holder, and double-checked locking (8 threads):
> 
> 
> Benchmark                       Mode  Cnt  Score   Error  Units
> StableBenchmark.staticAtomic    avgt   10  1.335 ? 0.056  ns/op
> StableBenchmark.staticCHI       avgt   10  0.623 ? 0.086  ns/op
> StableBenchmark.staticDCL       avgt   10  1.418 ? 0.171  ns/op
> StableBenchmark.staticList      avgt   10  0.617 ? 0.024  ns/op
> StableBenchmark.staticStable    avgt   10  0.604 ? 0.022  ns/op <- StableValue ( > 2x faster than `AtomicInteger` and DCL)
> 
> 
> Performance for stable lists in both instance and static contexts whereby the sum of random contents is calculated for stable lists (which are thread-safe) compared to `ArrayList` instances (which are not thread-safe) (under single thread access):
> 
> 
> Benchmark                                     Mode  Cnt  Score   Error  Units
> StableListSumBenchmark.instanceArrayList      avgt   10  0.356 ? 0.005  ns/op
> StableListSumBenchmark.instanceList           avgt   10  0.373 ? 0.017  ns/op <- Stable list
> StableListSumBenchmark.staticArrayList        avgt   10  0.352 ? 0.002  ns/op
> StableListSumBenchmark.staticList             avgt   10  0.356 ? 0.00...

src/java.base/share/classes/java/lang/reflect/AccessibleObject.java line 195:

> 193:      * <li>final fields of a type that implements
> 194:      * {@linkplain jdk.internal.lang.stable.TrustedFieldType}
> 195:      * (e.g {@linkplain StableValue StableValue})</li>

The API docs for a standard method can't reference a JDK internal annotation. It would be possible for the API docs to admit to an implementation specific way to do this but I think we should try to avoid this for now.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18794#discussion_r1600132293

From pminborg at openjdk.org  Tue May 14 14:30:05 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 14 May 2024 14:30:05 GMT
Subject: RFR: 8305457: Implement java.io.IO [v9]
In-Reply-To: <PIg24sny09iDwNT6W--TkoqtY8V2tXWCjrUL4MO-CRg=.67519d97-15b9-4b72-9bdc-ecbcc3dbfd5c@github.com>
References: <w2msiw_qaMEIJS3s9D4bg8pFbz5WIF0KdP6Mm-XFjLI=.85b2020b-8c46-4bac-8a69-4975b068f2ff@github.com>
 <PIg24sny09iDwNT6W--TkoqtY8V2tXWCjrUL4MO-CRg=.67519d97-15b9-4b72-9bdc-ecbcc3dbfd5c@github.com>
Message-ID: <kavKbw2Sl0yLDl8CD8AZBMAdYgtyfmHrQIoWNRs7FCk=.330c7414-67b0-4b34-90e9-d9d7a9df2743@github.com>

On Mon, 13 May 2024 09:56:35 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Please review this PR which introduces the `java.io.IO` top-level class and three methods to `java.io.Console` for [Implicitly Declared Classes and Instance Main Methods (Third Preview)].
>> 
>> This PR has been obtained as `git merge --squash` of a now obsolete [draft PR].
>> 
>> [Implicitly Declared Classes and Instance Main Methods (Third Preview)]: https://bugs.openjdk.org/browse/JDK-8323335
>> [draft PR]: https://github.com/openjdk/jdk/pull/18921
>
> Pavel Rappo has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 17 additional commits since the last revision:
> 
>  - Escape prompt
>  - Merge branch 'master' into 8305457-Implement-java.io.IO
>  - Clarify input charset
>  - Make IO final
>  - Fix System.console().readln(null) in jshell
>    
>    Without it, jshell hangs on me. Will think of a test.
>  - Fix typo
>  - Merge branch 'master' into 8305457-Implement-java.io.IO
>  - Simplify output.exp
>  - Cover null prompt in input tests
>  - Make input test parametric
>  - ... and 7 more: https://git.openjdk.org/jdk/compare/2f44ac18...17100ab8

src/java.base/share/classes/java/io/IO.java line 98:

> 96:      *                 or if an I/O error occurs
> 97:      */
> 98:     public static String readln(String prompt) {

Did we consider Optional<String> here? Maybe that is to complicated for an onramp?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19112#discussion_r1600145844

From prappo at openjdk.org  Tue May 14 14:34:05 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Tue, 14 May 2024 14:34:05 GMT
Subject: RFR: 8305457: Implement java.io.IO [v9]
In-Reply-To: <kavKbw2Sl0yLDl8CD8AZBMAdYgtyfmHrQIoWNRs7FCk=.330c7414-67b0-4b34-90e9-d9d7a9df2743@github.com>
References: <w2msiw_qaMEIJS3s9D4bg8pFbz5WIF0KdP6Mm-XFjLI=.85b2020b-8c46-4bac-8a69-4975b068f2ff@github.com>
 <PIg24sny09iDwNT6W--TkoqtY8V2tXWCjrUL4MO-CRg=.67519d97-15b9-4b72-9bdc-ecbcc3dbfd5c@github.com>
 <kavKbw2Sl0yLDl8CD8AZBMAdYgtyfmHrQIoWNRs7FCk=.330c7414-67b0-4b34-90e9-d9d7a9df2743@github.com>
Message-ID: <CfFNZGzpYR425wA4ORYI7Xi2onIZjiBUw5L97w2KkUc=.532cdbec-1cc1-456c-ae35-15052f62c97f@github.com>

On Tue, 14 May 2024 14:27:35 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> Pavel Rappo has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 17 additional commits since the last revision:
>> 
>>  - Escape prompt
>>  - Merge branch 'master' into 8305457-Implement-java.io.IO
>>  - Clarify input charset
>>  - Make IO final
>>  - Fix System.console().readln(null) in jshell
>>    
>>    Without it, jshell hangs on me. Will think of a test.
>>  - Fix typo
>>  - Merge branch 'master' into 8305457-Implement-java.io.IO
>>  - Simplify output.exp
>>  - Cover null prompt in input tests
>>  - Make input test parametric
>>  - ... and 7 more: https://git.openjdk.org/jdk/compare/63e13e69...17100ab8
>
> src/java.base/share/classes/java/io/IO.java line 98:
> 
>> 96:      *                 or if an I/O error occurs
>> 97:      */
>> 98:     public static String readln(String prompt) {
> 
> Did we consider Optional<String> here? Maybe that is to complicated for an onramp?

Have we considered it? Yes, momentarily. Will we implement it here? No, certainly.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19112#discussion_r1600152722

From pminborg at openjdk.org  Tue May 14 14:51:20 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 14 May 2024 14:51:20 GMT
Subject: RFR: 8330465: Stable Values and Collections (Internal) [v2]
In-Reply-To: <-KSimQo5kkmCzzMShqGe5QZ9yCSzpWL98gN13v4wP0k=.11dd8d06-18a6-4577-8342-66632cea0b6e@github.com>
References: <-KSimQo5kkmCzzMShqGe5QZ9yCSzpWL98gN13v4wP0k=.11dd8d06-18a6-4577-8342-66632cea0b6e@github.com>
Message-ID: <k6l7lLUl6k8QcxvwWIIj3OgWofFtZkSku7EtuLH6COk=.7e2af9f8-5e64-41c9-a778-78f39360a618@github.com>

> # Stable Values & Collections (Internal)
> 
> ## Summary
> This PR proposes to introduce an internal _Stable Values & Collections_ API, which provides immutable value holders where elements are initialized _at most once_. Stable Values & Collections offer the performance and safety benefits of final fields while offering greater flexibility as to the timing of initialization.
> 
> ## Goals
>  * Provide an easy and intuitive API to describe value holders that can change at most once.
>  * Decouple declaration from initialization without significant footprint or performance penalties.
>  * Reduce the amount of static initializer and/or field initialization code.
>  * Uphold integrity and consistency, even in a multi-threaded environment.
>  
> For more details, see the draft JEP: https://openjdk.org/jeps/8312611
> 
> ## Performance 
> Performance compared to instance variables using an `AtomicReference` and one protected by double-checked locking under concurrent access by 8 threads:
> 
> 
> Benchmark                       Mode  Cnt  Score   Error  Units
> StableBenchmark.instanceAtomic  avgt   10  1.576 ? 0.052  ns/op
> StableBenchmark.instanceDCL     avgt   10  1.608 ? 0.059  ns/op
> StableBenchmark.instanceStable  avgt   10  0.979 ? 0.023  ns/op <- StableValue (~40% faster than DCL)
> 
> 
> Performance compared to static variables protected by `AtomicReference`, class-holder idiom holder, and double-checked locking (8 threads):
> 
> 
> Benchmark                       Mode  Cnt  Score   Error  Units
> StableBenchmark.staticAtomic    avgt   10  1.335 ? 0.056  ns/op
> StableBenchmark.staticCHI       avgt   10  0.623 ? 0.086  ns/op
> StableBenchmark.staticDCL       avgt   10  1.418 ? 0.171  ns/op
> StableBenchmark.staticList      avgt   10  0.617 ? 0.024  ns/op
> StableBenchmark.staticStable    avgt   10  0.604 ? 0.022  ns/op <- StableValue ( > 2x faster than `AtomicInteger` and DCL)
> 
> 
> Performance for stable lists in both instance and static contexts whereby the sum of random contents is calculated for stable lists (which are thread-safe) compared to `ArrayList` instances (which are not thread-safe) (under single thread access):
> 
> 
> Benchmark                                     Mode  Cnt  Score   Error  Units
> StableListSumBenchmark.instanceArrayList      avgt   10  0.356 ? 0.005  ns/op
> StableListSumBenchmark.instanceList           avgt   10  0.373 ? 0.017  ns/op <- Stable list
> StableListSumBenchmark.staticArrayList        avgt   10  0.352 ? 0.002  ns/op
> StableListSumBenchmark.staticList             avgt   10  0.356 ? 0.00...

Per Minborg has updated the pull request incrementally with one additional commit since the last revision:

  Remove text in public class that references an internal class

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/18794/files
  - new: https://git.openjdk.org/jdk/pull/18794/files/5d5dcced..d7c31585

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18794&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18794&range=00-01

  Stats: 3 lines in 1 file changed: 0 ins; 3 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/18794.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18794/head:pull/18794

PR: https://git.openjdk.org/jdk/pull/18794

From pminborg at openjdk.org  Tue May 14 14:51:20 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 14 May 2024 14:51:20 GMT
Subject: RFR: 8330465: Stable Values and Collections (Internal) [v2]
In-Reply-To: <z7KTwCoVfWrZvMwUicEl4V97brfKRzgzVB2oP7VEILo=.e62db5da-6ca4-4be5-ba99-63cf54ffd06b@github.com>
References: <-KSimQo5kkmCzzMShqGe5QZ9yCSzpWL98gN13v4wP0k=.11dd8d06-18a6-4577-8342-66632cea0b6e@github.com>
 <z7KTwCoVfWrZvMwUicEl4V97brfKRzgzVB2oP7VEILo=.e62db5da-6ca4-4be5-ba99-63cf54ffd06b@github.com>
Message-ID: <Mj79eNPUqk6tAQl7uf6lu6fIxVhPkveklQMJT9TlLTk=.7fb338b8-bb67-4aec-865e-228400d6854c@github.com>

On Tue, 14 May 2024 14:19:44 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove text in public class that references an internal class
>
> src/java.base/share/classes/java/lang/reflect/AccessibleObject.java line 195:
> 
>> 193:      * <li>final fields of a type that implements
>> 194:      * {@linkplain jdk.internal.lang.stable.TrustedFieldType}
>> 195:      * (e.g {@linkplain StableValue StableValue})</li>
> 
> The API docs for a standard method can't reference a JDK internal annotation. It would be possible for the API docs to admit to an implementation specific way to do this but I think we should try to avoid this for now.

I will remove it. Once some of the classes are public, we could add back a message of this type.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18794#discussion_r1600179776

From david.lloyd at redhat.com  Tue May 14 15:01:15 2024
From: david.lloyd at redhat.com (David Lloyd)
Date: Tue, 14 May 2024 10:01:15 -0500
Subject: [External] : Re: New candidate JEP: 471: Deprecate the
 Memory-Access Methods in sun.misc.Unsafe for Removal
In-Reply-To: <835bfb2c-3318-4869-b8ff-6b1d3c1b70ad@oracle.com>
References: <20240503151140.68BE06C9AEE@eggemoggin.niobe.net>
 <CANghgrTUU+eWburseC1cReTgzh1LR96aDCGrCJhVyLwPzxxF9A@mail.gmail.com>
 <990521CB-66E1-45E6-8019-79E2C0BF7FEE@oracle.com>
 <CANghgrRA8B5Bn7gyUs=g3bgVyA1Hjn7dOSiUOZbG7Ad3LCo9dA@mail.gmail.com>
 <835bfb2c-3318-4869-b8ff-6b1d3c1b70ad@oracle.com>
Message-ID: <CANghgrThn3gdTBr3W0jzVaA9=g-MudpKyR7WN_cbpgqZ0w2+eQ@mail.gmail.com>

(Moving to core-libs-dev)

On Tue, May 14, 2024 at 9:40?AM Alan Bateman <Alan.Bateman at oracle.com>
wrote:

> On 14/05/2024 14:42, David Lloyd wrote:
>
> ReflectionFactory allows access to serialization facilities without any
> access checking (other than the defunct SecurityManager checks). Perhaps
> this class could gain some more methods, like this:
>
> * `newGetterForSerialization(Field field)` - includes ability to access
> `objectStreamFields` and `serialVersionUID`, or these could be separate
> methods
> * `newSetterForSerialziation(Field field)`
>
> Does this seem workable?
>
> The intention with ReflectionFactory is that serialization libraries go
> through the readObject/writeObject and other magic methods, to avoid field
> access.
>
> Probably best to being this to core-libs-dev for further discussion.
>

This doesn't match my recollection. The `readObject` and `writeObject`
methods are optional private methods which serializable classes *may*
provide when they want a bespoke serialization strategy (and the other
methods that are accessed via this special class are similar in this
regard). They are not in any way magical in that they do not provide the
means to perform this part of the serialization process, and thus they are
not a substitute for field access in serialization. According to
JDK-8164908, these methods were added because at the time, Unsafe was still
state of the art for custom serialization and IIOP to access fields (with
libraries using Field actively moving to Unsafe instead). However Unsafe
did not and does not provide access to methods, so in order to avoid the
aforementioned `add-opens` explosion, these methods were added as a
compromise. Now that Unsafe is being deprecated, it is my opinion that this
does need to be revisited because at the time, Unsafe was the recommended
approach.

[1] https://bugs.openjdk.org/browse/JDK-8164908

-- 
- DML ? he/him
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240514/c211fe1e/attachment-0001.htm>

From duke at openjdk.org  Tue May 14 15:44:04 2024
From: duke at openjdk.org (ExE Boss)
Date: Tue, 14 May 2024 15:44:04 GMT
Subject: RFR: 8332086: Remove the usage of ServiceLoader in
 j.u.r.RandomGeneratorFactory [v3]
In-Reply-To: <RHMQAfrujeQPhrMCaSV7fAvVtQyRIy8NaWFq_Q72dd4=.f11f4b74-2619-41b9-8692-7085d855745b@github.com>
References: <hfB86NksORc-aC6zVxHel_QQd_9aB629SfQjXvl6q5U=.e31daa4b-5cf6-4f3f-a757-79e818a18978@github.com>
 <RHMQAfrujeQPhrMCaSV7fAvVtQyRIy8NaWFq_Q72dd4=.f11f4b74-2619-41b9-8692-7085d855745b@github.com>
Message-ID: <FWYQ-hAfp5JX0rXGrG1eEaWsq5DNy5EM_MmAa6jOrFI=.f4e9ed0e-5bfb-4a2d-8e6e-2372c6b98117@github.com>

On Tue, 14 May 2024 13:47:33 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> All random number generator algorithms are implemented in module `java.base`. The usage of `ServiceLoader` in `j.u.r.RandomGeneratorFactory` is no longer needed.
>
> Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Move mathematical logic to record RandomGeneratorProperties.

src/java.base/share/classes/java/util/random/RandomGeneratorFactory.java line 202:

> 200:                 int i, int j, int k, int equidistribution,
> 201:                 int flags) {
> 202:             return new SimpleImmutableEntry<>(name,

This?should use?[`Map?.Entry?<?>`] as?the?return?type, which in turn allows using [`Map?::entry?(K,?V)`] as the implementation, as?neither the?`name`?key, nor?the?value is?ever?`null`:
Suggestion:

        private static Map.Entry<String, RandomGeneratorProperties>
        entry(Class<? extends RandomGenerator> rgClass, String name, String group,
                int i, int j, int k, int equidistribution,
                int flags) {
            return Map.entry(name,


[`Map?.Entry?<?>`]: https://docs.oracle.com/en/java/javase/22/docs/api/java.base/java/util/Map.Entry.html
[`Map?::entry?(K,?V)`]: https://docs.oracle.com/en/java/javase/22/docs/api/java.base/java/util/Map.html#entry(K,V)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19212#discussion_r1600264879

From psandoz at openjdk.org  Tue May 14 16:02:02 2024
From: psandoz at openjdk.org (Paul Sandoz)
Date: Tue, 14 May 2024 16:02:02 GMT
Subject: RFR: 8331940: ClassFile API ArrayIndexOutOfBoundsException with
 certain class files
In-Reply-To: <wWNlHWtc5H1nl9YHXQHGJBdJt-uo3p89E8MeGsRjsKY=.10b28a54-3530-42dc-8b24-5a4da8b81f9a@github.com>
References: <wWNlHWtc5H1nl9YHXQHGJBdJt-uo3p89E8MeGsRjsKY=.10b28a54-3530-42dc-8b24-5a4da8b81f9a@github.com>
Message-ID: <YbR5vW3TX1b2dTRlXmvWufVe_sbui3elsa_RI8trg0k=.169877b0-bd8f-402b-a559-9f0493746616@github.com>

On Tue, 14 May 2024 13:18:51 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> Class file with `LineNumberTable` attribute element pointing behind the bytecode array throws `ArrayIndexOutOfBoundsException`.
> This patch performs the check and throws  expected `IllegalArgumentException` instead.
> Relevant test is added.
> 
> Please review.
> 
> Thanks,
> Adam

src/java.base/share/classes/jdk/internal/classfile/impl/CodeImpl.java line 241:

> 239:                     int startPc = classReader.readU2(p);
> 240:                     if (startPc > codeLength) {
> 241:                         throw new IllegalArgumentException(String.format("Line number out of range; start_pc=%d, codeLength=%d",

It's the byte code index that is out of range, not the line number associated with it.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19230#discussion_r1600292689

From vklang at openjdk.org  Tue May 14 16:06:09 2024
From: vklang at openjdk.org (Viktor Klang)
Date: Tue, 14 May 2024 16:06:09 GMT
Subject: RFR: 8330465: Stable Values and Collections (Internal) [v2]
In-Reply-To: <k6l7lLUl6k8QcxvwWIIj3OgWofFtZkSku7EtuLH6COk=.7e2af9f8-5e64-41c9-a778-78f39360a618@github.com>
References: <-KSimQo5kkmCzzMShqGe5QZ9yCSzpWL98gN13v4wP0k=.11dd8d06-18a6-4577-8342-66632cea0b6e@github.com>
 <k6l7lLUl6k8QcxvwWIIj3OgWofFtZkSku7EtuLH6COk=.7e2af9f8-5e64-41c9-a778-78f39360a618@github.com>
Message-ID: <1BnXIoSgu8PhvzHlCE5aaxAUtjBrayd935yQSnqZZbc=.18384687-9678-4b84-9cff-95c51f51d528@github.com>

On Tue, 14 May 2024 14:51:20 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> # Stable Values & Collections (Internal)
>> 
>> ## Summary
>> This PR proposes to introduce an internal _Stable Values & Collections_ API, which provides immutable value holders where elements are initialized _at most once_. Stable Values & Collections offer the performance and safety benefits of final fields while offering greater flexibility as to the timing of initialization.
>> 
>> ## Goals
>>  * Provide an easy and intuitive API to describe value holders that can change at most once.
>>  * Decouple declaration from initialization without significant footprint or performance penalties.
>>  * Reduce the amount of static initializer and/or field initialization code.
>>  * Uphold integrity and consistency, even in a multi-threaded environment.
>>  
>> For more details, see the draft JEP: https://openjdk.org/jeps/8312611
>> 
>> ## Performance 
>> Performance compared to instance variables using an `AtomicReference` and one protected by double-checked locking under concurrent access by 8 threads:
>> 
>> 
>> Benchmark                       Mode  Cnt  Score   Error  Units
>> StableBenchmark.instanceAtomic  avgt   10  1.576 ? 0.052  ns/op
>> StableBenchmark.instanceDCL     avgt   10  1.608 ? 0.059  ns/op
>> StableBenchmark.instanceStable  avgt   10  0.979 ? 0.023  ns/op <- StableValue (~40% faster than DCL)
>> 
>> 
>> Performance compared to static variables protected by `AtomicReference`, class-holder idiom holder, and double-checked locking (8 threads):
>> 
>> 
>> Benchmark                       Mode  Cnt  Score   Error  Units
>> StableBenchmark.staticAtomic    avgt   10  1.335 ? 0.056  ns/op
>> StableBenchmark.staticCHI       avgt   10  0.623 ? 0.086  ns/op
>> StableBenchmark.staticDCL       avgt   10  1.418 ? 0.171  ns/op
>> StableBenchmark.staticList      avgt   10  0.617 ? 0.024  ns/op
>> StableBenchmark.staticStable    avgt   10  0.604 ? 0.022  ns/op <- StableValue ( > 2x faster than `AtomicInteger` and DCL)
>> 
>> 
>> Performance for stable lists in both instance and static contexts whereby the sum of random contents is calculated for stable lists (which are thread-safe) compared to `ArrayList` instances (which are not thread-safe) (under single thread access):
>> 
>> 
>> Benchmark                                     Mode  Cnt  Score   Error  Units
>> StableListSumBenchmark.instanceArrayList      avgt   10  0.356 ? 0.005  ns/op
>> StableListSumBenchmark.instanceList           avgt   10  0.373 ? 0.017  ns/op <- Stable list
>> StableListSumBenchmark.staticArrayList        avgt   10  0.352 ? ...
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove text in public class that references an internal class

src/java.base/share/classes/jdk/internal/lang/StableValue.java line 171:

> 169:     /**
> 170:      * {@return a fresh stable value with an unset value where the returned stable's
> 171:      * value is computed in a separate background thread (created via the provided

Suggestion:

     * {@return a fresh stable value with an unset value where the returned stable
     * value is computed in a separate background thread (created via the provided

src/java.base/share/classes/jdk/internal/lang/StableValue.java line 175:

> 173:      * <p>
> 174:      * If the supplier throws an (unchecked) exception, the exception is ignored, and no
> 175:      * value is set.

Is it likely that users will want to be made aware of failures? If so, perhaps it would make sense to make sure that the Exception hits the UncaughtExceptionHandler? ?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18794#discussion_r1600296959
PR Review Comment: https://git.openjdk.org/jdk/pull/18794#discussion_r1600298211

From rgiulietti at openjdk.org  Tue May 14 16:08:22 2024
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Tue, 14 May 2024 16:08:22 GMT
Subject: RFR: 8332086: Remove the usage of ServiceLoader in
 j.u.r.RandomGeneratorFactory [v4]
In-Reply-To: <hfB86NksORc-aC6zVxHel_QQd_9aB629SfQjXvl6q5U=.e31daa4b-5cf6-4f3f-a757-79e818a18978@github.com>
References: <hfB86NksORc-aC6zVxHel_QQd_9aB629SfQjXvl6q5U=.e31daa4b-5cf6-4f3f-a757-79e818a18978@github.com>
Message-ID: <hcgzniWvdSy3pM3nsaeUjEM-Aqtyib8t_foGyRDel7s=.84651106-ae19-4f5d-8e3f-54bcd2bcf590@github.com>

> All random number generator algorithms are implemented in module `java.base`. The usage of `ServiceLoader` in `j.u.r.RandomGeneratorFactory` is no longer needed.

Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:

  Replace SimpleImmutableEntry constructor with Map.entry() factory method.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19212/files
  - new: https://git.openjdk.org/jdk/pull/19212/files/e8432cc6..4bc5bf95

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19212&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19212&range=02-03

  Stats: 5 lines in 1 file changed: 0 ins; 1 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/19212.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19212/head:pull/19212

PR: https://git.openjdk.org/jdk/pull/19212

From rgiulietti at openjdk.org  Tue May 14 16:10:03 2024
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Tue, 14 May 2024 16:10:03 GMT
Subject: RFR: 8332086: Remove the usage of ServiceLoader in
 j.u.r.RandomGeneratorFactory [v3]
In-Reply-To: <FWYQ-hAfp5JX0rXGrG1eEaWsq5DNy5EM_MmAa6jOrFI=.f4e9ed0e-5bfb-4a2d-8e6e-2372c6b98117@github.com>
References: <hfB86NksORc-aC6zVxHel_QQd_9aB629SfQjXvl6q5U=.e31daa4b-5cf6-4f3f-a757-79e818a18978@github.com>
 <RHMQAfrujeQPhrMCaSV7fAvVtQyRIy8NaWFq_Q72dd4=.f11f4b74-2619-41b9-8692-7085d855745b@github.com>
 <FWYQ-hAfp5JX0rXGrG1eEaWsq5DNy5EM_MmAa6jOrFI=.f4e9ed0e-5bfb-4a2d-8e6e-2372c6b98117@github.com>
Message-ID: <rmvFAcEaHWG7Fr-4sAuDL-qNkvPNRJbRrN08rE8fwQU=.7797ef22-cbc6-4027-9a21-c99b95c69288@github.com>

On Tue, 14 May 2024 15:40:24 GMT, ExE Boss <duke at openjdk.org> wrote:

>> Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Move mathematical logic to record RandomGeneratorProperties.
>
> src/java.base/share/classes/java/util/random/RandomGeneratorFactory.java line 202:
> 
>> 200:                 int i, int j, int k, int equidistribution,
>> 201:                 int flags) {
>> 202:             return new SimpleImmutableEntry<>(name,
> 
> This?should use?[`Map?.Entry?<?>`] as?the?return?type, which in turn allows using [`Map?::entry?(K,?V)`] as the implementation, as?neither the?`name`?key, nor?the?value is?ever?`null`:
> Suggestion:
> 
>         private static Map.Entry<String, RandomGeneratorProperties>
>         entry(Class<? extends RandomGenerator> rgClass, String name, String group,
>                 int i, int j, int k, int equidistribution,
>                 int flags) {
>             return Map.entry(name,
> 
> 
> [`Map?.Entry?<?>`]: https://docs.oracle.com/en/java/javase/22/docs/api/java.base/java/util/Map.Entry.html
> [`Map?::entry?(K,?V)`]: https://docs.oracle.com/en/java/javase/22/docs/api/java.base/java/util/Map.html#entry(K,V)

@ExE-Boss Thanks for the suggestion.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19212#discussion_r1600303960

From vklang at openjdk.org  Tue May 14 16:18:09 2024
From: vklang at openjdk.org (Viktor Klang)
Date: Tue, 14 May 2024 16:18:09 GMT
Subject: RFR: 8330465: Stable Values and Collections (Internal) [v2]
In-Reply-To: <k6l7lLUl6k8QcxvwWIIj3OgWofFtZkSku7EtuLH6COk=.7e2af9f8-5e64-41c9-a778-78f39360a618@github.com>
References: <-KSimQo5kkmCzzMShqGe5QZ9yCSzpWL98gN13v4wP0k=.11dd8d06-18a6-4577-8342-66632cea0b6e@github.com>
 <k6l7lLUl6k8QcxvwWIIj3OgWofFtZkSku7EtuLH6COk=.7e2af9f8-5e64-41c9-a778-78f39360a618@github.com>
Message-ID: <v-x56sAYouvgmFXTwPlP7juVX3jIuGbTZ_tNoyPyU6c=.9e585890-2953-43e4-8253-5af9789e5001@github.com>

On Tue, 14 May 2024 14:51:20 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> # Stable Values & Collections (Internal)
>> 
>> ## Summary
>> This PR proposes to introduce an internal _Stable Values & Collections_ API, which provides immutable value holders where elements are initialized _at most once_. Stable Values & Collections offer the performance and safety benefits of final fields while offering greater flexibility as to the timing of initialization.
>> 
>> ## Goals
>>  * Provide an easy and intuitive API to describe value holders that can change at most once.
>>  * Decouple declaration from initialization without significant footprint or performance penalties.
>>  * Reduce the amount of static initializer and/or field initialization code.
>>  * Uphold integrity and consistency, even in a multi-threaded environment.
>>  
>> For more details, see the draft JEP: https://openjdk.org/jeps/8312611
>> 
>> ## Performance 
>> Performance compared to instance variables using an `AtomicReference` and one protected by double-checked locking under concurrent access by 8 threads:
>> 
>> 
>> Benchmark                       Mode  Cnt  Score   Error  Units
>> StableBenchmark.instanceAtomic  avgt   10  1.576 ? 0.052  ns/op
>> StableBenchmark.instanceDCL     avgt   10  1.608 ? 0.059  ns/op
>> StableBenchmark.instanceStable  avgt   10  0.979 ? 0.023  ns/op <- StableValue (~40% faster than DCL)
>> 
>> 
>> Performance compared to static variables protected by `AtomicReference`, class-holder idiom holder, and double-checked locking (8 threads):
>> 
>> 
>> Benchmark                       Mode  Cnt  Score   Error  Units
>> StableBenchmark.staticAtomic    avgt   10  1.335 ? 0.056  ns/op
>> StableBenchmark.staticCHI       avgt   10  0.623 ? 0.086  ns/op
>> StableBenchmark.staticDCL       avgt   10  1.418 ? 0.171  ns/op
>> StableBenchmark.staticList      avgt   10  0.617 ? 0.024  ns/op
>> StableBenchmark.staticStable    avgt   10  0.604 ? 0.022  ns/op <- StableValue ( > 2x faster than `AtomicInteger` and DCL)
>> 
>> 
>> Performance for stable lists in both instance and static contexts whereby the sum of random contents is calculated for stable lists (which are thread-safe) compared to `ArrayList` instances (which are not thread-safe) (under single thread access):
>> 
>> 
>> Benchmark                                     Mode  Cnt  Score   Error  Units
>> StableListSumBenchmark.instanceArrayList      avgt   10  0.356 ? 0.005  ns/op
>> StableListSumBenchmark.instanceList           avgt   10  0.373 ? 0.017  ns/op <- Stable list
>> StableListSumBenchmark.staticArrayList        avgt   10  0.352 ? ...
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove text in public class that references an internal class

src/java.base/share/classes/jdk/internal/lang/stable/StableArray3DImpl.java line 33:

> 31:         Objects.checkIndex(i1, dim1);
> 32:         Objects.checkIndex(i2, dim2);
> 33:         final int index = i0 * dim1 * dim2 + i1 * dim2 + i2;

Might be worth doing some overflow checking here?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18794#discussion_r1600313603

From naoto at openjdk.org  Tue May 14 16:26:06 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 14 May 2024 16:26:06 GMT
Subject: RFR: 8332084: Ensure JdkConsoleImpl.restoreEcho visibility in a
 shutdown hook [v4]
In-Reply-To: <3Ljww4SBrsr6wmjoBGFLvYJ-cG6jNGdblfb2B7bZuB0=.97e3da61-c10d-4da2-b27a-2bd45dfc544f@github.com>
References: <9JTWc3FRpfbILlSHlmIU_dL5IE69RTxnSIAOdIte15I=.5854a48f-21d7-42c9-adb7-5e3ed40d1211@github.com>
 <3Ljww4SBrsr6wmjoBGFLvYJ-cG6jNGdblfb2B7bZuB0=.97e3da61-c10d-4da2-b27a-2bd45dfc544f@github.com>
Message-ID: <1Mh8SXwjjJgT6IZ0x_BJjXX_z9Y4crERo17xWUixarI=.5a9eb344-83dc-44b8-8830-04fec48a793e@github.com>

On Mon, 13 May 2024 21:32:18 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Making sure `restoreEcho` correctly reflects the state in the shutdown thread, which differs from the application's thread that issues the `readPassword()` method.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Addresses a review comment

OK, I realized removing checking `restoreEcho` does not work, here is why.

> It should be possible to provide something adequate based on atomic primitives. However, it would complicate code. So, let's first clarify the problem that `restoreEcho` is trying to solve: why is it important to restore the echo state upon JVM exit? What would happen if we fail to do that? Can it be demonstrated?

`restoreEcho`, as I understand it, does what it stands, ie., restore the platform console's echo status. Since `java.base`'s Console implementation relies on the platform's echo function, JVM needs to restore the original echo state after JVM quits. So in an unlike situation where the echo is off when the JVM starts, my proposal won't work. We'll still have restoreEcho check in the shutdown thread.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19184#issuecomment-2110644430

From naoto at openjdk.org  Tue May 14 16:29:29 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 14 May 2024 16:29:29 GMT
Subject: RFR: 8330276: Console methods with explicit Locale [v5]
In-Reply-To: <GT275XVwYlYL3PhYwOTQ_-HwKqp9QYUeIzEIeJKEwkQ=.9a7faf08-8637-45a3-97bd-fd58756a6711@github.com>
References: <GT275XVwYlYL3PhYwOTQ_-HwKqp9QYUeIzEIeJKEwkQ=.9a7faf08-8637-45a3-97bd-fd58756a6711@github.com>
Message-ID: <C-orD4cxIFTkMl5NE1bSaXM8ohmMQmu3D29hwk3MHKg=.39632137-be83-4804-820b-b191ecbbfc9d@github.com>

> Proposing new overloaded methods in `java.io.Console` class that explicitly take a `Locale` argument. Existing methods rely on the default locale, so the users won't be able to format their prompts/outputs in a certain locale explicitly.

Naoto Sato 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 branch 'master' into JDK-8330276-Console-with-explicit-Locale
 - Removed JdkConsole.printf()
 - Addresses a CSR review comment
 - Merge branch 'master' into JDK-8330276-Console-with-explicit-Locale
 - Addressed review comments
 - Not using System.err
 - spacing
 - initial commit

-------------

Changes: https://git.openjdk.org/jdk/pull/18923/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18923&range=04
  Stats: 438 lines in 7 files changed: 335 ins; 24 del; 79 mod
  Patch: https://git.openjdk.org/jdk/pull/18923.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18923/head:pull/18923

PR: https://git.openjdk.org/jdk/pull/18923

From jjg at openjdk.org  Tue May 14 17:20:01 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Tue, 14 May 2024 17:20:01 GMT
Subject: RFR: 8332109: Convert remaining tests using
 com.sun.tools.classfile to ClassFile API
In-Reply-To: <argrcg0iKCFTZJz-mOA_OXkVPbyy0Z5Qb4L2g0Qc4gw=.637a0870-77b0-49da-9aee-ffa39ba68c5f@github.com>
References: <argrcg0iKCFTZJz-mOA_OXkVPbyy0Z5Qb4L2g0Qc4gw=.637a0870-77b0-49da-9aee-ffa39ba68c5f@github.com>
Message-ID: <5z-nOUmrg0piCxGgqDtyeByovb44DWUFUQFnywO8LlM=.816ebf10-6c3f-4197-833b-ef223107aaa9@github.com>

On Sun, 12 May 2024 08:36:44 GMT, Chen Liang <liach at openjdk.org> wrote:

> Some tests are not migrated to the ClassFile API in previous migrations.
> 
>  - Some are simple oversights that didn't remove usages of com.sun.tools.classfile;
>  - The CallerSensitive ones used an old utility, replaced by CF API-based new code;
>  - many in javac are because the files are compiled with older source compatibility. Those patches are converted to have the source code stored in text blocks and compiled within tests using `ToolBox#writeJavaFiles` and `CompilerUtils.compile`;
>  - As described in the JBS issue, there are a few other tests not covered; one is in #19193 while the others are blocked by CreateSymbols migration or bugs.
> 
> Testing: all modified tests pass.

javadoc test change looks OK.

-------------

PR Review: https://git.openjdk.org/jdk/pull/19206#pullrequestreview-2055992753

From redestad at openjdk.org  Tue May 14 17:25:37 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Tue, 14 May 2024 17:25:37 GMT
Subject: RFR: 8331724: Refactor j.l.constant implementation to internal
 package [v9]
In-Reply-To: <_GPUF9d1E6eBKRxP6bEEqA3LSKRJe2GwCRTfVYbDwFU=.cb482785-e7c4-45f7-bd3a-cd32d466a2cb@github.com>
References: <_GPUF9d1E6eBKRxP6bEEqA3LSKRJe2GwCRTfVYbDwFU=.cb482785-e7c4-45f7-bd3a-cd32d466a2cb@github.com>
Message-ID: <_ZuDS5DbpEUnhV64qoXok-S0o8l7dof98Vl8BwCdBuM=.bcccdef0-a5c2-4e59-9517-c3b4980225a4@github.com>

> This PR suggests refactoring the implementation classes of java.lang.constant into a new package jdk.internal.constant to enable sharing some trusted static factory methods with users elsewhere in java.base, such as java.lang.invoke and java.lang.classfile. The refactoring also adds some "trusted" methods for use when input is pre-validated, and makes use of them where applicable in the current implementation. There are more changes in the pipeline which will be folded into #17108 or PR'ed once that is integrated. 
> 
> There are two optimizations mixed up here. One in `MethodTypeDesc.ofDescriptor`:
> 
> Name                                                             (descString) Cnt     Base     Error      Test   Error  Unit  Change
> MethodTypeDescFactories.ofDescriptor  (Ljava/lang/Object;Ljava/lang/String;)I   6  138,371 ?   0,767   136,939 ? 1,126 ns/op   1,01x (p = 0,000*)
> MethodTypeDescFactories.ofDescriptor                                      ()V   6   10,528 ?   2,495     4,110 ? 0,047 ns/op   2,56x (p = 0,000*)
> MethodTypeDescFactories.ofDescriptor ([IJLjava/lang/String;Z)Ljava/util/List;   6  209,390 ?   4,583   196,175 ? 3,211 ns/op   1,07x (p = 0,000*)
> MethodTypeDescFactories.ofDescriptor                    ()[Ljava/lang/String;   6   36,039 ?   8,684    20,794 ? 1,110 ns/op   1,73x (p = 0,000*)
> MethodTypeDescFactories.ofDescriptor                                 (..IIJ)V   6  279,139 ?   6,248   187,934 ? 0,857 ns/op   1,49x (p = 0,000*)
> MethodTypeDescFactories.ofDescriptor                 (.....................).   6 2174,387 ? 132,879  1150,652 ? 3,158 ns/op   1,89x (p = 0,000*)
>   * = significant
> 
> 
> The other in `ClassDesc::nested`, where to get rid of a simple static method in `ConstantUtils` I ended up speeding up and simplifying the public factory method:
> 
> Name                                      Cnt    Base     Error    Test   Error  Unit  Change
> ClassDescFactories.ReferenceOnly.ofNested   6 209,853 ? 132,525  22,017 ? 0,573 ns/op   9,53x (p = 0,000*)
>   * = significant
> 
> 
> The optimizations could be split out and PRd independently, but I think they are simple enough to include in this refactoring.

Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:

  Add microbenchmark for ClassDesc methods + a few optimizations

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19105/files
  - new: https://git.openjdk.org/jdk/pull/19105/files/e2d7b59d..6d5df18e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19105&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19105&range=07-08

  Stats: 108 lines in 2 files changed: 87 ins; 0 del; 21 mod
  Patch: https://git.openjdk.org/jdk/pull/19105.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19105/head:pull/19105

PR: https://git.openjdk.org/jdk/pull/19105

From redestad at openjdk.org  Tue May 14 17:34:12 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Tue, 14 May 2024 17:34:12 GMT
Subject: RFR: 8331724: Refactor j.l.constant implementation to internal
 package [v9]
In-Reply-To: <_ZuDS5DbpEUnhV64qoXok-S0o8l7dof98Vl8BwCdBuM=.bcccdef0-a5c2-4e59-9517-c3b4980225a4@github.com>
References: <_GPUF9d1E6eBKRxP6bEEqA3LSKRJe2GwCRTfVYbDwFU=.cb482785-e7c4-45f7-bd3a-cd32d466a2cb@github.com>
 <_ZuDS5DbpEUnhV64qoXok-S0o8l7dof98Vl8BwCdBuM=.bcccdef0-a5c2-4e59-9517-c3b4980225a4@github.com>
Message-ID: <H0IWg1EyYvs5HtjUmITjHBOYxH5VKnOZy9jsNaKlHLM=.ece344df-fd42-4bbd-b7f0-3c6387b65e91@github.com>

On Tue, 14 May 2024 17:25:37 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> This PR suggests refactoring the implementation classes of java.lang.constant into a new package jdk.internal.constant to enable sharing some trusted static factory methods with users elsewhere in java.base, such as java.lang.invoke and java.lang.classfile. The refactoring also adds some "trusted" methods for use when input is pre-validated, and makes use of them where applicable in the current implementation. There are more changes in the pipeline which will be folded into #17108 or PR'ed once that is integrated. 
>> 
>> There are two optimizations mixed up here. One in `MethodTypeDesc.ofDescriptor`:
>> 
>> Name                                                             (descString) Cnt     Base     Error      Test   Error  Unit  Change
>> MethodTypeDescFactories.ofDescriptor  (Ljava/lang/Object;Ljava/lang/String;)I   6  138,371 ?   0,767   136,939 ? 1,126 ns/op   1,01x (p = 0,000*)
>> MethodTypeDescFactories.ofDescriptor                                      ()V   6   10,528 ?   2,495     4,110 ? 0,047 ns/op   2,56x (p = 0,000*)
>> MethodTypeDescFactories.ofDescriptor ([IJLjava/lang/String;Z)Ljava/util/List;   6  209,390 ?   4,583   196,175 ? 3,211 ns/op   1,07x (p = 0,000*)
>> MethodTypeDescFactories.ofDescriptor                    ()[Ljava/lang/String;   6   36,039 ?   8,684    20,794 ? 1,110 ns/op   1,73x (p = 0,000*)
>> MethodTypeDescFactories.ofDescriptor                                 (..IIJ)V   6  279,139 ?   6,248   187,934 ? 0,857 ns/op   1,49x (p = 0,000*)
>> MethodTypeDescFactories.ofDescriptor                 (.....................).   6 2174,387 ? 132,879  1150,652 ? 3,158 ns/op   1,89x (p = 0,000*)
>>   * = significant
>> 
>> 
>> The other in `ClassDesc::nested`, where to get rid of a simple static method in `ConstantUtils` I ended up speeding up and simplifying the public factory method:
>> 
>> Name                                      Cnt    Base     Error    Test   Error  Unit  Change
>> ClassDescFactories.ReferenceOnly.ofNested   6 209,853 ? 132,525  22,017 ? 0,573 ns/op   9,53x (p = 0,000*)
>>   * = significant
>> 
>> 
>> The optimizations could be split out and PRd independently, but I think they are simple enough to include in this refactoring.
>
> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add microbenchmark for ClassDesc methods + a few optimizations

Added a few microbenchmarks, and a couple of optimizations: 


Name                         Cnt     Base     Error      Test      Error   Unit  Change
ClassDescMethods.arrayType    15   49,922 ?   0,616    14,546 ?    0,524  ns/op   3,43x (p = 0,000*)
   :gc.alloc.rate.norm            312,000 ?   0,000   144,000 ?    0,000   B/op   0,46x (p = 0,000*)
ClassDescMethods.arrayType1   15   37,764 ?   0,625    14,441 ?    0,272  ns/op   2,62x (p = 0,000*)
   :gc.alloc.rate.norm            312,000 ?   0,000   144,000 ?    0,000   B/op   0,46x (p = 0,000*)
ClassDescMethods.arrayType2   15   48,663 ?   0,168    35,223 ?    6,517  ns/op   1,38x (p = 0,000*)
   :gc.alloc.rate.norm            360,000 ?   0,000   256,000 ?    0,000   B/op   0,71x (p = 0,000*)
ClassDescMethods.displayName  15    9,663 ?   0,326     9,285 ?    0,334  ns/op   1,04x (p = 0,002*)
   :gc.alloc.rate.norm             48,000 ?   0,000    48,000 ?    0,000   B/op   1,00x (p = 0,002 )
ClassDescMethods.packageName  15   39,387 ?   1,134    31,242 ?    5,554  ns/op   1,26x (p = 0,000*)
   :gc.alloc.rate.norm            168,000 ?   0,000    96,000 ?    0,000   B/op   0,57x (p = 0,000*)
  * = significant


This can be broken out to a follow-up PR, naturally.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19105#issuecomment-2110768382

From smarks at openjdk.org  Tue May 14 17:44:03 2024
From: smarks at openjdk.org (Stuart Marks)
Date: Tue, 14 May 2024 17:44:03 GMT
Subject: RFR: 8332084: Ensure JdkConsoleImpl.restoreEcho visibility in a
 shutdown hook [v4]
In-Reply-To: <3Ljww4SBrsr6wmjoBGFLvYJ-cG6jNGdblfb2B7bZuB0=.97e3da61-c10d-4da2-b27a-2bd45dfc544f@github.com>
References: <9JTWc3FRpfbILlSHlmIU_dL5IE69RTxnSIAOdIte15I=.5854a48f-21d7-42c9-adb7-5e3ed40d1211@github.com>
 <3Ljww4SBrsr6wmjoBGFLvYJ-cG6jNGdblfb2B7bZuB0=.97e3da61-c10d-4da2-b27a-2bd45dfc544f@github.com>
Message-ID: <a6bpeNeea3SfmXMPqY9I1kXdVcGX3DCnxjTV_qYzJx8=.2238be2b-c778-4fb1-b5e6-acf172fba787@github.com>

On Mon, 13 May 2024 21:32:18 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Making sure `restoreEcho` correctly reflects the state in the shutdown thread, which differs from the application's thread that issues the `readPassword()` method.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Addresses a review comment

I think we're assuming here that it's good practice for the Console to snapshot the initial tty state and to restore that state on exit. That's probably right.

If we're really supporting that, though, it means that the Console needs to be prepared to deal with whatever state the tty is in. In particular, if echo is off when the JVM starts, then we'll also need to make sure that ordinary reads turn echo on before actually reading.

And JLine probably also needs to do things like disable canonical input processing (stty -icanon, or "raw" mode, in Unix parlance). Will these be restored on exit? Hm... I just went and looked a bit through JLine, and it installs its own shutdown hooks! I didn't dig further to see exactly what they do though. Probably they're solving a similar problem though.

Unfortunately, shutdown hooks are unordered, so it's possible to that the shutdown hook added at this level will run either before or after JLine's and maybe they'll conflict. So maybe the SPI needs to have tty-save-state and tty-restore-state functions added to it, or something like that, so the responsibility for handling tty stated is pushed down to the provider. But I don't know if JLine could support that. The java.base provider might be able to do something reasonable though.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19184#issuecomment-2110784011

From mcimadamore at openjdk.org  Tue May 14 18:10:28 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 14 May 2024 18:10:28 GMT
Subject: RFR: 8331671: Implement JEP 472: Prepare to Restrict the Use of
 JNI [v4]
In-Reply-To: <CZGbki5iFdCGPPagE-ya-_L8Nkgf7OunywApOsxC548=.2cee82fa-a5d2-4165-b012-30982a85030a@github.com>
References: <CZGbki5iFdCGPPagE-ya-_L8Nkgf7OunywApOsxC548=.2cee82fa-a5d2-4165-b012-30982a85030a@github.com>
Message-ID: <sxwnadwC7gqIP9jLa6QyaV-wSYTH0FwuJf3HA-hfW6g=.292d839e-1480-43b4-9949-2dd7074f4cbe@github.com>

> This PR implements [JEP 472](https://openjdk.org/jeps/472), by restricting the use of JNI in the following ways:
> 
> * `System::load` and `System::loadLibrary` are now restricted methods
> * `Runtime::load` and `Runtime::loadLibrary` are now restricted methods
> * binding a JNI `native` method declaration to a native implementation is now considered a restricted operation
> 
> This PR slightly changes the way in which the JDK deals with restricted methods, even for FFM API calls. In Java 22, the single `--enable-native-access` was used both to specify a set of modules for which native access should be allowed *and* to specify whether illegal native access (that is, native access occurring from a module not specified by `--enable-native-access`) should be treated as an error or a warning. More specifically, an error is only issued if the `--enable-native-access flag` is used at least once.
> 
> Here, a new flag is introduced, namely `illegal-native-access=allow/warn/deny`, which is used to specify what should happen when access to a restricted method and/or functionality is found outside the set of modules specified with `--enable-native-access`. The default policy is `warn`, but users can select `allow` to suppress the warnings, or `deny` to cause `IllegalCallerException` to be thrown. This aligns the treatment of restricted methods with other mechanisms, such as `--illegal-access` and the more recent `--sun-misc-unsafe-memory-access`.
> 
> Some changes were required in the package-info javadoc for `java.lang.foreign`, to reflect the changes in the command line flags described above.

Maurizio Cimadamore has updated the pull request incrementally with two additional commits since the last revision:

 - Address review comments
   Improve warning for JNI methods, similar to what's described in JEP 472
   Beef up tests
 - Address review comments

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19213/files
  - new: https://git.openjdk.org/jdk/pull/19213/files/bad10942..0d21bf99

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19213&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19213&range=02-03

  Stats: 84 lines in 15 files changed: 42 ins; 14 del; 28 mod
  Patch: https://git.openjdk.org/jdk/pull/19213.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19213/head:pull/19213

PR: https://git.openjdk.org/jdk/pull/19213

From naoto at openjdk.org  Tue May 14 18:34:06 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 14 May 2024 18:34:06 GMT
Subject: RFR: 8332084: Ensure JdkConsoleImpl.restoreEcho visibility in a
 shutdown hook [v4]
In-Reply-To: <3Ljww4SBrsr6wmjoBGFLvYJ-cG6jNGdblfb2B7bZuB0=.97e3da61-c10d-4da2-b27a-2bd45dfc544f@github.com>
References: <9JTWc3FRpfbILlSHlmIU_dL5IE69RTxnSIAOdIte15I=.5854a48f-21d7-42c9-adb7-5e3ed40d1211@github.com>
 <3Ljww4SBrsr6wmjoBGFLvYJ-cG6jNGdblfb2B7bZuB0=.97e3da61-c10d-4da2-b27a-2bd45dfc544f@github.com>
Message-ID: <s62x_h6F0h3ic0Ag3Jn1Rvk-rjWJi9WH_diJbIa7xp4=.dfd95da3-dd00-4343-ae74-1a8a751f004d@github.com>

On Mon, 13 May 2024 21:32:18 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Making sure `restoreEcho` correctly reflects the state in the shutdown thread, which differs from the application's thread that issues the `readPassword()` method.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Addresses a review comment

Thanks, Stuart.
The shutdown hook in question is in the `java.base`'s JdkConsole implementation, so the save/restore responsibility is already pushed down to each provider. Thinking that `java.base`'s implementation is now non-default, and the possibility of the race condition is quite low, I now think making `restoreEcho` as volatile (the current PR) is the most practical solution, unless we could find a reasonably simple way to resolve the contention.
BTW, the `java.base`'s shutdown hook has the special slot `0`, which is guaranteed to be called first: https://github.com/openjdk/jdk/blob/e91492ab4333c61f39b50eb428fa932131a5b908/src/java.base/share/classes/java/lang/Shutdown.java#L47

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19184#issuecomment-2110862963

From smarks at openjdk.org  Tue May 14 18:57:14 2024
From: smarks at openjdk.org (Stuart Marks)
Date: Tue, 14 May 2024 18:57:14 GMT
Subject: RFR: 8332084: Ensure JdkConsoleImpl.restoreEcho visibility in a
 shutdown hook [v4]
In-Reply-To: <3Ljww4SBrsr6wmjoBGFLvYJ-cG6jNGdblfb2B7bZuB0=.97e3da61-c10d-4da2-b27a-2bd45dfc544f@github.com>
References: <9JTWc3FRpfbILlSHlmIU_dL5IE69RTxnSIAOdIte15I=.5854a48f-21d7-42c9-adb7-5e3ed40d1211@github.com>
 <3Ljww4SBrsr6wmjoBGFLvYJ-cG6jNGdblfb2B7bZuB0=.97e3da61-c10d-4da2-b27a-2bd45dfc544f@github.com>
Message-ID: <mKrMQcTfq7b6dyg35tIMjuKMt5ASlS7sdnpxxf6rFjw=.80e9a3eb-ea50-4c76-a167-e14bd71f683a@github.com>

On Mon, 13 May 2024 21:32:18 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Making sure `restoreEcho` correctly reflects the state in the shutdown thread, which differs from the application's thread that issues the `readPassword()` method.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Addresses a review comment

Ah, ok, so each provider has its own shutdown hook, so it's never the case that both hooks are installed at the same time and can conflict with each other. The `java.base` console provider tracking and restoring echo status on its own is probably fine.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19184#issuecomment-2110926249

From liach at openjdk.org  Tue May 14 20:24:04 2024
From: liach at openjdk.org (Chen Liang)
Date: Tue, 14 May 2024 20:24:04 GMT
Subject: RFR: 8331724: Refactor j.l.constant implementation to internal
 package [v9]
In-Reply-To: <_ZuDS5DbpEUnhV64qoXok-S0o8l7dof98Vl8BwCdBuM=.bcccdef0-a5c2-4e59-9517-c3b4980225a4@github.com>
References: <_GPUF9d1E6eBKRxP6bEEqA3LSKRJe2GwCRTfVYbDwFU=.cb482785-e7c4-45f7-bd3a-cd32d466a2cb@github.com>
 <_ZuDS5DbpEUnhV64qoXok-S0o8l7dof98Vl8BwCdBuM=.bcccdef0-a5c2-4e59-9517-c3b4980225a4@github.com>
Message-ID: <W78MmrX44sVhytHBQj4JUE-wNK1RtrxUS6h0PdXewhc=.91e60f61-2d95-4e2b-89bc-b47f343f2e50@github.com>

On Tue, 14 May 2024 17:25:37 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> This PR suggests refactoring the implementation classes of java.lang.constant into a new package jdk.internal.constant to enable sharing some trusted static factory methods with users elsewhere in java.base, such as java.lang.invoke and java.lang.classfile. The refactoring also adds some "trusted" methods for use when input is pre-validated, and makes use of them where applicable in the current implementation. There are more changes in the pipeline which will be folded into #17108 or PR'ed once that is integrated. 
>> 
>> There are two optimizations mixed up here. One in `MethodTypeDesc.ofDescriptor`:
>> 
>> Name                                                             (descString) Cnt     Base     Error      Test   Error  Unit  Change
>> MethodTypeDescFactories.ofDescriptor  (Ljava/lang/Object;Ljava/lang/String;)I   6  138,371 ?   0,767   136,939 ? 1,126 ns/op   1,01x (p = 0,000*)
>> MethodTypeDescFactories.ofDescriptor                                      ()V   6   10,528 ?   2,495     4,110 ? 0,047 ns/op   2,56x (p = 0,000*)
>> MethodTypeDescFactories.ofDescriptor ([IJLjava/lang/String;Z)Ljava/util/List;   6  209,390 ?   4,583   196,175 ? 3,211 ns/op   1,07x (p = 0,000*)
>> MethodTypeDescFactories.ofDescriptor                    ()[Ljava/lang/String;   6   36,039 ?   8,684    20,794 ? 1,110 ns/op   1,73x (p = 0,000*)
>> MethodTypeDescFactories.ofDescriptor                                 (..IIJ)V   6  279,139 ?   6,248   187,934 ? 0,857 ns/op   1,49x (p = 0,000*)
>> MethodTypeDescFactories.ofDescriptor                 (.....................).   6 2174,387 ? 132,879  1150,652 ? 3,158 ns/op   1,89x (p = 0,000*)
>>   * = significant
>> 
>> 
>> The other in `ClassDesc::nested`, where to get rid of a simple static method in `ConstantUtils` I ended up speeding up and simplifying the public factory method:
>> 
>> Name                                      Cnt    Base     Error    Test   Error  Unit  Change
>> ClassDescFactories.ReferenceOnly.ofNested   6 209,853 ? 132,525  22,017 ? 0,573 ns/op   9,53x (p = 0,000*)
>>   * = significant
>> 
>> 
>> The optimizations could be split out and PRd independently, but I think they are simple enough to include in this refactoring.
>
> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add microbenchmark for ClassDesc methods + a few optimizations

src/java.base/share/classes/java/lang/constant/ClassDesc.java line 226:

> 224:         for (int i = 0; i < rank; i++) {
> 225:             sb.append('[');
> 226:         }

Would `sb.repeat("[", rank);` be better here?

Also for parity with `arrayType()` I recommend moving this building code to after the void check.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19105#discussion_r1600598008

From naoto at openjdk.org  Tue May 14 21:30:16 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 14 May 2024 21:30:16 GMT
Subject: RFR: 8332084: Ensure JdkConsoleImpl.restoreEcho visibility in a
 shutdown hook [v5]
In-Reply-To: <9JTWc3FRpfbILlSHlmIU_dL5IE69RTxnSIAOdIte15I=.5854a48f-21d7-42c9-adb7-5e3ed40d1211@github.com>
References: <9JTWc3FRpfbILlSHlmIU_dL5IE69RTxnSIAOdIte15I=.5854a48f-21d7-42c9-adb7-5e3ed40d1211@github.com>
Message-ID: <Zr22anFGU9yMJKAfqUXBeQ82jHQ2KMG_GnhmQgQNeK8=.3621aa1f-dc9c-4000-941d-a1614c959d15@github.com>

> Making sure `restoreEcho` correctly reflects the state in the shutdown thread, which differs from the application's thread that issues the `readPassword()` method.

Naoto Sato has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision:

 - Merge branch 'master' into JDK-8332084-restoreEcho-readLock
 - get/setEcho()
 - Addresses a review comment
 - Replaced another unused exception with _
 - Update src/java.base/share/classes/jdk/internal/io/JdkConsoleImpl.java
   
   Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com>
 - initial commit

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19184/files
  - new: https://git.openjdk.org/jdk/pull/19184/files/fb5beb11..e178f0de

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19184&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19184&range=03-04

  Stats: 4029 lines in 159 files changed: 2537 ins; 817 del; 675 mod
  Patch: https://git.openjdk.org/jdk/pull/19184.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19184/head:pull/19184

PR: https://git.openjdk.org/jdk/pull/19184

From prappo at openjdk.org  Tue May 14 21:41:13 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Tue, 14 May 2024 21:41:13 GMT
Subject: RFR: 8330205: Initial troff manpage generation for JDK 24
In-Reply-To: <6tFYXJ753At7nUZTy8khVVeiQHYtZRBRYegXSTXViUY=.f3110151-9ea0-4b55-89f1-90039273fd34@github.com>
References: <6tFYXJ753At7nUZTy8khVVeiQHYtZRBRYegXSTXViUY=.f3110151-9ea0-4b55-89f1-90039273fd34@github.com>
Message-ID: <dyGsHe50-9tsvxAgjvkSEgeMxpWfBIcxbHry9HXI3MI=.3bf65598-5584-4794-a502-3e0925fe1710@github.com>

On Tue, 7 May 2024 11:53:19 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> Please review this mechanical change to man pages. This PR should be integrated after https://github.com/openjdk/jdk/pull/18787.

Withdrawing this, as a different approach is required.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19119#issuecomment-2111182078

From prappo at openjdk.org  Tue May 14 21:41:13 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Tue, 14 May 2024 21:41:13 GMT
Subject: Withdrawn: 8330205: Initial troff manpage generation for JDK 24
In-Reply-To: <6tFYXJ753At7nUZTy8khVVeiQHYtZRBRYegXSTXViUY=.f3110151-9ea0-4b55-89f1-90039273fd34@github.com>
References: <6tFYXJ753At7nUZTy8khVVeiQHYtZRBRYegXSTXViUY=.f3110151-9ea0-4b55-89f1-90039273fd34@github.com>
Message-ID: <3IfStE5WvNR62yu4s0sbkQWZ9TWw3UIrXILYhrHdlc4=.dcfd1934-f44f-4f79-9fb6-4b87bd6679ea@github.com>

On Tue, 7 May 2024 11:53:19 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> Please review this mechanical change to man pages. This PR should be integrated after https://github.com/openjdk/jdk/pull/18787.

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/19119

From prappo at openjdk.org  Tue May 14 22:01:04 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Tue, 14 May 2024 22:01:04 GMT
Subject: RFR: 8332084: Ensure JdkConsoleImpl.restoreEcho visibility in a
 shutdown hook [v5]
In-Reply-To: <Zr22anFGU9yMJKAfqUXBeQ82jHQ2KMG_GnhmQgQNeK8=.3621aa1f-dc9c-4000-941d-a1614c959d15@github.com>
References: <9JTWc3FRpfbILlSHlmIU_dL5IE69RTxnSIAOdIte15I=.5854a48f-21d7-42c9-adb7-5e3ed40d1211@github.com>
 <Zr22anFGU9yMJKAfqUXBeQ82jHQ2KMG_GnhmQgQNeK8=.3621aa1f-dc9c-4000-941d-a1614c959d15@github.com>
Message-ID: <oTSH09n8ZdEssAX4TGhXhdgzRYe-xQQvgnyEfNadBF0=.4d4b337c-e910-4306-adc3-30fffcffc6b4@github.com>

On Tue, 14 May 2024 21:30:16 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Making sure `restoreEcho` correctly reflects the state in the shutdown thread, which differs from the application's thread that issues the `readPassword()` method.
>
> Naoto Sato has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision:
> 
>  - Merge branch 'master' into JDK-8332084-restoreEcho-readLock
>  - get/setEcho()
>  - Addresses a review comment
>  - Replaced another unused exception with _
>  - Update src/java.base/share/classes/jdk/internal/io/JdkConsoleImpl.java
>    
>    Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com>
>  - initial commit

[898c609] looks robust. Separating fused `echo(boolean)` into `setEcho(boolean)` and `getEcho()` allows us to safely publish `final boolean restoreEcho` and use it as many times as we'd like without further synchronisation.

Even though that race between a thread that executes `readPassword` and the shutdown hook is still possible, it is now benign: the worst that could happen is that we `setEcho(true)` twice. The important thing is that we'll never do a wrong thing.

A general test to show that `restoreEcho` works would be good though. Thanks.

[898c609]: https://github.com/openjdk/jdk/pull/19184/commits/898c60938ff51fc6d6613ff54626f19e1392ab0b

-------------

Marked as reviewed by prappo (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19184#pullrequestreview-2056530026

From naoto at openjdk.org  Tue May 14 22:13:14 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 14 May 2024 22:13:14 GMT
Subject: RFR: 8332084: Ensure JdkConsoleImpl.restoreEcho visibility in a
 shutdown hook [v6]
In-Reply-To: <9JTWc3FRpfbILlSHlmIU_dL5IE69RTxnSIAOdIte15I=.5854a48f-21d7-42c9-adb7-5e3ed40d1211@github.com>
References: <9JTWc3FRpfbILlSHlmIU_dL5IE69RTxnSIAOdIte15I=.5854a48f-21d7-42c9-adb7-5e3ed40d1211@github.com>
Message-ID: <XXznhv81tU0mwu2Gr5-LnChdQ0we8cazSQjjnfrXHNs=.ff73ac55-a155-4de7-a0e7-dafc880a0972@github.com>

> Making sure `restoreEcho` correctly reflects the state in the shutdown thread, which differs from the application's thread that issues the `readPassword()` method.

Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:

  copyright year

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19184/files
  - new: https://git.openjdk.org/jdk/pull/19184/files/e178f0de..82d30b3b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19184&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19184&range=04-05

  Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/19184.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19184/head:pull/19184

PR: https://git.openjdk.org/jdk/pull/19184

From naoto at openjdk.org  Tue May 14 22:40:05 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 14 May 2024 22:40:05 GMT
Subject: RFR: 8305457: Implement java.io.IO [v9]
In-Reply-To: <PIg24sny09iDwNT6W--TkoqtY8V2tXWCjrUL4MO-CRg=.67519d97-15b9-4b72-9bdc-ecbcc3dbfd5c@github.com>
References: <w2msiw_qaMEIJS3s9D4bg8pFbz5WIF0KdP6Mm-XFjLI=.85b2020b-8c46-4bac-8a69-4975b068f2ff@github.com>
 <PIg24sny09iDwNT6W--TkoqtY8V2tXWCjrUL4MO-CRg=.67519d97-15b9-4b72-9bdc-ecbcc3dbfd5c@github.com>
Message-ID: <I485KtM4-m_jFq9CZ0UMBawk_V547GaFQBi7cSw7HGg=.c9034bb2-a954-4f03-9751-0e8e7d667daa@github.com>

On Mon, 13 May 2024 09:56:35 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Please review this PR which introduces the `java.io.IO` top-level class and three methods to `java.io.Console` for [Implicitly Declared Classes and Instance Main Methods (Third Preview)].
>> 
>> This PR has been obtained as `git merge --squash` of a now obsolete [draft PR].
>> 
>> [Implicitly Declared Classes and Instance Main Methods (Third Preview)]: https://bugs.openjdk.org/browse/JDK-8323335
>> [draft PR]: https://github.com/openjdk/jdk/pull/18921
>
> Pavel Rappo has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 17 additional commits since the last revision:
> 
>  - Escape prompt
>  - Merge branch 'master' into 8305457-Implement-java.io.IO
>  - Clarify input charset
>  - Make IO final
>  - Fix System.console().readln(null) in jshell
>    
>    Without it, jshell hangs on me. Will think of a test.
>  - Fix typo
>  - Merge branch 'master' into 8305457-Implement-java.io.IO
>  - Simplify output.exp
>  - Cover null prompt in input tests
>  - Make input test parametric
>  - ... and 7 more: https://git.openjdk.org/jdk/compare/42e6a104...17100ab8

LGTM

-------------

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19112#pullrequestreview-2056583806

From sviswanathan at openjdk.org  Tue May 14 23:54:10 2024
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Tue, 14 May 2024 23:54:10 GMT
Subject: RFR: 8320448: Accelerate IndexOf using AVX2 [v19]
In-Reply-To: <eQ4OBFrF8JlDJ1h9awTDOc0kfCc37IlL5vdqtuaqls0=.8f00616d-08e1-4f28-a7a5-5095116d2595@github.com>
References: <uWi4QxH31hL93771gkl_GgvP0m84IRSoR_1Yi8hD17E=.bc6ed458-7081-4c3f-9348-f59358fa05a4@github.com>
 <eQ4OBFrF8JlDJ1h9awTDOc0kfCc37IlL5vdqtuaqls0=.8f00616d-08e1-4f28-a7a5-5095116d2595@github.com>
Message-ID: <b_a8wi88dvCkofFPkN93FTN-IEnqB36Z1InXjGhVcLI=.023c0009-bbcb-4110-8b28-1189546e49d2@github.com>

On Sat, 4 May 2024 19:35:21 GMT, Scott Gibbons <sgibbons at openjdk.org> wrote:

>> Re-write the IndexOf code without the use of the pcmpestri instruction, only using AVX2 instructions.  This change accelerates String.IndexOf on average 1.3x for AVX2.  The benchmark numbers:
>> 
>> 
>> Benchmark	                                               Score		Latest		
>> StringIndexOf.advancedWithMediumSub   343.573		317.934		0.925375393x
>> StringIndexOf.advancedWithShortSub1	  1039.081		1053.96		1.014319384x
>> StringIndexOf.advancedWithShortSub2	      55.828		110.541		1.980027943x
>> StringIndexOf.constantPattern	                9.361		11.906		1.271872663x
>> StringIndexOf.searchCharLongSuccess	        4.216		4.218		1.000474383x
>> StringIndexOf.searchCharMediumSuccess	3.133		3.216		1.02649218x
>> StringIndexOf.searchCharShortSuccess	3.76		        3.761		1.000265957x
>> StringIndexOf.success	                                9.186		9.713		1.057369911x
>> StringIndexOf.successBig	                      14.341		46.343		3.231504079x
>> StringIndexOfChar.latin1_AVX2_String	  6220.918		12154.52		1.953814533x
>> StringIndexOfChar.latin1_AVX2_char	  5503.556		5540.044		1.006629895x
>> StringIndexOfChar.latin1_SSE4_String	  6978.854		6818.689		0.977049957x
>> StringIndexOfChar.latin1_SSE4_char	  5657.499		5474.624		0.967675646x
>> StringIndexOfChar.latin1_Short_String	  7132.541		6863.359		0.962260014x
>> StringIndexOfChar.latin1_Short_char	16013.389	      16162.437		1.009307711x
>> StringIndexOfChar.latin1_mixed_String	  7386.123	      14771.622		1.999915517x
>> StringIndexOfChar.latin1_mixed_char	  9901.671		9782.245		0.987938803
>
> Scott Gibbons has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rearrange; add lambdas for clarity

src/hotspot/cpu/x86/stubGenerator_x86_64_string.cpp line 1589:

> 1587:     case 3:
> 1588:     case 4:
> 1589:       __ movl(needleVal, Address(needle, offsetOfFirstByteToCompare));

If the size of the needle is 7 and it is an LL case with NUMBER_OF_NEEDLE_BYTES_TO_COMPARE set as 3:
  bytesLeftToCompare = 4 (i.e. 7-3);
  offsetOfFirstByteToCompare = 2 (i.e. 3-1);
  the movl will be loading bytes 2,3,4,5
So we seem to be missing loading the last byte of the needle. Is that correct?

src/hotspot/cpu/x86/stubGenerator_x86_64_string.cpp line 1735:

> 1733: // generated with 32 - (n - k + 1) bits set that ensures matches past the end of the original
> 1734: // haystack do not get considered during compares.
> 1735: //

Mask is generated below with (n-k+1) bits set and not 32- (n-k+1) bits set. Also it will be helpful if we specify what is n and k.

src/hotspot/cpu/x86/stubGenerator_x86_64_string.cpp line 1784:

> 1782:       __ subq(tmp, haystack_len);
> 1783:     }
> 1784:     __ leaq(haystack, Address(rsp, tmp, Address::times_1));

This whole code is repeated in two places. Could be made into a function and used at both places.

src/hotspot/cpu/x86/stubGenerator_x86_64_string.cpp line 1838:

> 1836:     __ shrq(rax, 1);
> 1837:   }
> 1838: 

We need to be consistent either use tzcntl, shrl, testl or tzcntq, shrq, testq.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1600787103
PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1600760538
PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1600489229
PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1600765277

From smarks at openjdk.org  Wed May 15 00:05:04 2024
From: smarks at openjdk.org (Stuart Marks)
Date: Wed, 15 May 2024 00:05:04 GMT
Subject: RFR: 8305457: Implement java.io.IO [v9]
In-Reply-To: <CfFNZGzpYR425wA4ORYI7Xi2onIZjiBUw5L97w2KkUc=.532cdbec-1cc1-456c-ae35-15052f62c97f@github.com>
References: <w2msiw_qaMEIJS3s9D4bg8pFbz5WIF0KdP6Mm-XFjLI=.85b2020b-8c46-4bac-8a69-4975b068f2ff@github.com>
 <PIg24sny09iDwNT6W--TkoqtY8V2tXWCjrUL4MO-CRg=.67519d97-15b9-4b72-9bdc-ecbcc3dbfd5c@github.com>
 <kavKbw2Sl0yLDl8CD8AZBMAdYgtyfmHrQIoWNRs7FCk=.330c7414-67b0-4b34-90e9-d9d7a9df2743@github.com>
 <CfFNZGzpYR425wA4ORYI7Xi2onIZjiBUw5L97w2KkUc=.532cdbec-1cc1-456c-ae35-15052f62c97f@github.com>
Message-ID: <cwk4-rcAd-hvQ4e6Rzo3-puG_b4RQc1FZyJsUedRKTw=.45441623-6f70-4850-9bae-7fc4662fa50c@github.com>

On Tue, 14 May 2024 14:31:52 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> src/java.base/share/classes/java/io/IO.java line 98:
>> 
>>> 96:      *                 or if an I/O error occurs
>>> 97:      */
>>> 98:     public static String readln(String prompt) {
>> 
>> Did we consider Optional<String> here? Maybe that is to complicated for an onramp?
>
> Have we considered it? Yes, momentarily. Will we implement it here? No, certainly.

The precedent to return `null` from something that reads a line has already been set by `BufferedReader.readLine()` and `Console.readLine()`.

`Optional` is indeed intended for return values but it probably works better for things that are totally new, such as various streams operation (for which `Optional` was introduced), modules, the Classfile API, HTTP client, etc. And to use `Optional` effectively one needs to know how to use lambdas, the teaching of which is probably at odds with the on-ramp story.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19112#discussion_r1600793369

From dholmes at openjdk.org  Wed May 15 01:04:01 2024
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 15 May 2024 01:04:01 GMT
Subject: RFR: 8331671: Implement JEP 472: Prepare to Restrict the Use of
 JNI [v4]
In-Reply-To: <sxwnadwC7gqIP9jLa6QyaV-wSYTH0FwuJf3HA-hfW6g=.292d839e-1480-43b4-9949-2dd7074f4cbe@github.com>
References: <CZGbki5iFdCGPPagE-ya-_L8Nkgf7OunywApOsxC548=.2cee82fa-a5d2-4165-b012-30982a85030a@github.com>
 <sxwnadwC7gqIP9jLa6QyaV-wSYTH0FwuJf3HA-hfW6g=.292d839e-1480-43b4-9949-2dd7074f4cbe@github.com>
Message-ID: <Nug6-9W3vYrLZVsbSccwpBqVwwzzWuThfLrA-JOjh5Y=.6dc93c53-8683-4b56-a550-cdf6a7928bf2@github.com>

On Tue, 14 May 2024 18:10:28 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This PR implements [JEP 472](https://openjdk.org/jeps/472), by restricting the use of JNI in the following ways:
>> 
>> * `System::load` and `System::loadLibrary` are now restricted methods
>> * `Runtime::load` and `Runtime::loadLibrary` are now restricted methods
>> * binding a JNI `native` method declaration to a native implementation is now considered a restricted operation
>> 
>> This PR slightly changes the way in which the JDK deals with restricted methods, even for FFM API calls. In Java 22, the single `--enable-native-access` was used both to specify a set of modules for which native access should be allowed *and* to specify whether illegal native access (that is, native access occurring from a module not specified by `--enable-native-access`) should be treated as an error or a warning. More specifically, an error is only issued if the `--enable-native-access flag` is used at least once.
>> 
>> Here, a new flag is introduced, namely `illegal-native-access=allow/warn/deny`, which is used to specify what should happen when access to a restricted method and/or functionality is found outside the set of modules specified with `--enable-native-access`. The default policy is `warn`, but users can select `allow` to suppress the warnings, or `deny` to cause `IllegalCallerException` to be thrown. This aligns the treatment of restricted methods with other mechanisms, such as `--illegal-access` and the more recent `--sun-misc-unsafe-memory-access`.
>> 
>> Some changes were required in the package-info javadoc for `java.lang.foreign`, to reflect the changes in the command line flags described above.
>
> Maurizio Cimadamore has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Address review comments
>    Improve warning for JNI methods, similar to what's described in JEP 472
>    Beef up tests
>  - Address review comments

Hotspot changes look good - notwithstanding discussion about properlty namespace placement. Manpage changes also look good.

-------------

PR Review: https://git.openjdk.org/jdk/pull/19213#pullrequestreview-2056696636

From dholmes at openjdk.org  Wed May 15 01:04:02 2024
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 15 May 2024 01:04:02 GMT
Subject: RFR: 8331671: Implement JEP 472: Prepare to Restrict the Use of
 JNI [v3]
In-Reply-To: <l7dLX25UBFdbxrTmukfFGZjEXu3hZVEnWkDLIkoAu90=.c8a7fbd7-4e37-46d5-b950-211189279ca2@github.com>
References: <CZGbki5iFdCGPPagE-ya-_L8Nkgf7OunywApOsxC548=.2cee82fa-a5d2-4165-b012-30982a85030a@github.com>
 <jUWaDowOZsL42UtliIOoCe7WfowooCW1zvcVKyFnL7g=.4b20b555-3651-4fca-9ede-1652dec95e9c@github.com>
 <l7dLX25UBFdbxrTmukfFGZjEXu3hZVEnWkDLIkoAu90=.c8a7fbd7-4e37-46d5-b950-211189279ca2@github.com>
Message-ID: <fG9oopqgoIWQCaJcq3gE1N6p4QRdrXuUGLr9G_cZiuY=.fa484873-046f-4d18-a02a-18f17d42764a@github.com>

On Mon, 13 May 2024 15:32:27 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Maurizio Cimadamore has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - Fix another typo
>>  - Fix typo
>>  - Add more comments
>
> src/hotspot/share/runtime/arguments.cpp line 2271:
> 
>> 2269:     } else if (match_option(option, "--illegal-native-access=", &tail)) {
>> 2270:       if (!create_module_property("jdk.module.illegal.native.access", tail, InternalProperty)) {
>> 2271:         return JNI_ENOMEM;
> 
> I think it would be helpful to get guidance on if this is the right way to add this system property, only because this one not a "module property". The configuration (WriteableProperty + InternalProperty) look right.

So my recollection/understanding is that we use this mechanism to convert module-related `--` flags passed to the VM into system properties that the Java code can then read, but we set them up such that you are not allowed to specify them directly via `-D`. Is the question here whether this new property should be in the `jdk.module` namespace?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19213#discussion_r1600819327

From syan at openjdk.org  Wed May 15 03:34:23 2024
From: syan at openjdk.org (SendaoYan)
Date: Wed, 15 May 2024 03:34:23 GMT
Subject: RFR: 8332260: Mark tools/jlink/JLinkReproducibleTest.java as
 intermittent failure
Message-ID: <_EKj7ciDe4nTMdJn8X_OPuuyzA2UCMP9wiJYltCh98k=.78db452f-6950-48f2-9e08-7684b9432a4b@github.com>

Hi all,
  The `tools/jlink/JLinkReproducibleTest.java` intermittent fails on linux aarch64. Should we mark this testcase as `@key intermittent`. No risk.

Thanks.
-sendao

-------------

Commit messages:
 - 8332260: mark tools/jlink/JLinkReproducibleTest.java as intermittent failure
 - 8332260: mark tools/jlink/JLinkReproducibleTest.java as intermittent failure

Changes: https://git.openjdk.org/jdk/pull/19241/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19241&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8332260
  Stats: 3 lines in 1 file changed: 1 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/19241.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19241/head:pull/19241

PR: https://git.openjdk.org/jdk/pull/19241

From jpai at openjdk.org  Wed May 15 03:44:05 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 15 May 2024 03:44:05 GMT
Subject: RFR: 8332260: Mark tools/jlink/JLinkReproducibleTest.java as
 intermittent failure
In-Reply-To: <_EKj7ciDe4nTMdJn8X_OPuuyzA2UCMP9wiJYltCh98k=.78db452f-6950-48f2-9e08-7684b9432a4b@github.com>
References: <_EKj7ciDe4nTMdJn8X_OPuuyzA2UCMP9wiJYltCh98k=.78db452f-6950-48f2-9e08-7684b9432a4b@github.com>
Message-ID: <l-nlUFLz__Vqw_0dTy_a2QTUMEcNdCK_x7Gx1ob3rY8=.20a12646-c321-40eb-b846-0d4adcc39282@github.com>

On Wed, 15 May 2024 03:28:29 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
>   The `tools/jlink/JLinkReproducibleTest.java` intermittent fails on linux aarch64. Should we mark this testcase as `@key intermittent`. No risk.
> 
> Thanks.
> -sendao

Hello @sendaoYan, the linked issue https://bugs.openjdk.org/browse/JDK-8327181 which talks about a JVM crash looks very generic and not specific to this test. Before updating this test, I think that issue needs to investigated and addressed or at least we need to ascertain that this test is somehow the only test causing it.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19241#issuecomment-2111522183

From syan at openjdk.org  Wed May 15 03:49:08 2024
From: syan at openjdk.org (SendaoYan)
Date: Wed, 15 May 2024 03:49:08 GMT
Subject: RFR: 8332260: Mark tools/jlink/JLinkReproducibleTest.java as
 intermittent failure
In-Reply-To: <l-nlUFLz__Vqw_0dTy_a2QTUMEcNdCK_x7Gx1ob3rY8=.20a12646-c321-40eb-b846-0d4adcc39282@github.com>
References: <_EKj7ciDe4nTMdJn8X_OPuuyzA2UCMP9wiJYltCh98k=.78db452f-6950-48f2-9e08-7684b9432a4b@github.com>
 <l-nlUFLz__Vqw_0dTy_a2QTUMEcNdCK_x7Gx1ob3rY8=.20a12646-c321-40eb-b846-0d4adcc39282@github.com>
Message-ID: <cyYzBr4USKQ8RuJPFWF8xPc7gpdY5MXXXdSaCC3vkW0=.6db55b24-55fb-40c8-ae05-b97c8db7abc1@github.com>

On Wed, 15 May 2024 03:41:02 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Hello @sendaoYan, the linked issue https://bugs.openjdk.org/browse/JDK-8327181 which talks about a JVM crash looks very generic and not specific to this test. Before updating this test, I think that issue needs to investigated and addressed or at least we need to ascertain that this test is somehow the only test causing it.

OK, maybe we shoule close this PR before that issue has been investigated.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19241#issuecomment-2111526227

From syan at openjdk.org  Wed May 15 03:49:08 2024
From: syan at openjdk.org (SendaoYan)
Date: Wed, 15 May 2024 03:49:08 GMT
Subject: Withdrawn: 8332260: Mark tools/jlink/JLinkReproducibleTest.java as
 intermittent failure
In-Reply-To: <_EKj7ciDe4nTMdJn8X_OPuuyzA2UCMP9wiJYltCh98k=.78db452f-6950-48f2-9e08-7684b9432a4b@github.com>
References: <_EKj7ciDe4nTMdJn8X_OPuuyzA2UCMP9wiJYltCh98k=.78db452f-6950-48f2-9e08-7684b9432a4b@github.com>
Message-ID: <GTS1smnObQTYvQVDOuC7C1GHAGNnFgLDpGGzenCeikU=.416258a0-5c72-4d42-85c8-e8f5315fda03@github.com>

On Wed, 15 May 2024 03:28:29 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
>   The `tools/jlink/JLinkReproducibleTest.java` intermittent fails on linux aarch64. Should we mark this testcase as `@key intermittent`. No risk.
> 
> Thanks.
> -sendao

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/19241

From alanb at openjdk.org  Wed May 15 06:18:02 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 15 May 2024 06:18:02 GMT
Subject: RFR: 8331671: Implement JEP 472: Prepare to Restrict the Use of
 JNI [v3]
In-Reply-To: <fG9oopqgoIWQCaJcq3gE1N6p4QRdrXuUGLr9G_cZiuY=.fa484873-046f-4d18-a02a-18f17d42764a@github.com>
References: <CZGbki5iFdCGPPagE-ya-_L8Nkgf7OunywApOsxC548=.2cee82fa-a5d2-4165-b012-30982a85030a@github.com>
 <jUWaDowOZsL42UtliIOoCe7WfowooCW1zvcVKyFnL7g=.4b20b555-3651-4fca-9ede-1652dec95e9c@github.com>
 <l7dLX25UBFdbxrTmukfFGZjEXu3hZVEnWkDLIkoAu90=.c8a7fbd7-4e37-46d5-b950-211189279ca2@github.com>
 <fG9oopqgoIWQCaJcq3gE1N6p4QRdrXuUGLr9G_cZiuY=.fa484873-046f-4d18-a02a-18f17d42764a@github.com>
Message-ID: <-gTDhrDCjlq9pEoBxG4Qneo9dEf7ErWmvnyOZKGx4mM=.8772d4dd-aa5e-412c-8131-75687cddad5b@github.com>

On Wed, 15 May 2024 00:54:43 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> src/hotspot/share/runtime/arguments.cpp line 2271:
>> 
>>> 2269:     } else if (match_option(option, "--illegal-native-access=", &tail)) {
>>> 2270:       if (!create_module_property("jdk.module.illegal.native.access", tail, InternalProperty)) {
>>> 2271:         return JNI_ENOMEM;
>> 
>> I think it would be helpful to get guidance on if this is the right way to add this system property, only because this one not a "module property". The configuration (WriteableProperty + InternalProperty) look right.
>
> So my recollection/understanding is that we use this mechanism to convert module-related `--` flags passed to the VM into system properties that the Java code can then read, but we set them up such that you are not allowed to specify them directly via `-D`. Is the question here whether this new property should be in the `jdk.module` namespace?

That's my recollection too. The usage here isn' related to modules which makes me wonder if this function should be renamed (not by this PR of course) of if we should be using PropertyList_unique_add (with AddProperty, WriteableProperty, InternalProperty) instead. There will be further GNU style options coming that will likely need to map to an internal system property in the same way.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19213#discussion_r1601002132

From jpai at openjdk.org  Wed May 15 06:33:02 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 15 May 2024 06:33:02 GMT
Subject: RFR: 8332086: Remove the usage of ServiceLoader in
 j.u.r.RandomGeneratorFactory [v4]
In-Reply-To: <hcgzniWvdSy3pM3nsaeUjEM-Aqtyib8t_foGyRDel7s=.84651106-ae19-4f5d-8e3f-54bcd2bcf590@github.com>
References: <hfB86NksORc-aC6zVxHel_QQd_9aB629SfQjXvl6q5U=.e31daa4b-5cf6-4f3f-a757-79e818a18978@github.com>
 <hcgzniWvdSy3pM3nsaeUjEM-Aqtyib8t_foGyRDel7s=.84651106-ae19-4f5d-8e3f-54bcd2bcf590@github.com>
Message-ID: <N404ZVyQcMoJIVas4bcc23iYt0b77V91LhMioDSiKHU=.677f56eb-b461-4d3a-8a0f-f3751516c4ed@github.com>

On Tue, 14 May 2024 16:08:22 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> All random number generator algorithms are implemented in module `java.base`. The usage of `ServiceLoader` in `j.u.r.RandomGeneratorFactory` is no longer needed.
>
> Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Replace SimpleImmutableEntry constructor with Map.entry() factory method.

Thank you for these updates Raffaello. I think the implementation is looking much more simpler and cleaner now. I've a few documentation related review comments which I've added inline. I haven't reviewed the test change yet.

src/java.base/share/classes/java/util/random/package-info.java line 85:

> 83:  * Then one can choose a specific implementation by giving the name of a generator
> 84:  * algorithm to the static method {@link RandomGenerator#of}, in which case no
> 85:  * seed is specified by the caller:

Perhaps reword this to:


> ... in which case a {@code RandomGenerator} is constructed without any seed value:

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19212#issuecomment-2111679665
PR Review Comment: https://git.openjdk.org/jdk/pull/19212#discussion_r1601015731

From jpai at openjdk.org  Wed May 15 06:40:02 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 15 May 2024 06:40:02 GMT
Subject: RFR: 8332086: Remove the usage of ServiceLoader in
 j.u.r.RandomGeneratorFactory [v4]
In-Reply-To: <N404ZVyQcMoJIVas4bcc23iYt0b77V91LhMioDSiKHU=.677f56eb-b461-4d3a-8a0f-f3751516c4ed@github.com>
References: <hfB86NksORc-aC6zVxHel_QQd_9aB629SfQjXvl6q5U=.e31daa4b-5cf6-4f3f-a757-79e818a18978@github.com>
 <hcgzniWvdSy3pM3nsaeUjEM-Aqtyib8t_foGyRDel7s=.84651106-ae19-4f5d-8e3f-54bcd2bcf590@github.com>
 <N404ZVyQcMoJIVas4bcc23iYt0b77V91LhMioDSiKHU=.677f56eb-b461-4d3a-8a0f-f3751516c4ed@github.com>
Message-ID: <ZLoiUT3yEpY5VSekvIUG7BnGmQehFkr3ntS-ROC-fBc=.137784b0-ca87-4f2b-be8e-80b84851041e@github.com>

On Wed, 15 May 2024 06:30:35 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Replace SimpleImmutableEntry constructor with Map.entry() factory method.
>
> src/java.base/share/classes/java/util/random/package-info.java line 85:
> 
>> 83:  * Then one can choose a specific implementation by giving the name of a generator
>> 84:  * algorithm to the static method {@link RandomGenerator#of}, in which case no
>> 85:  * seed is specified by the caller:
> 
> Perhaps reword this to:
> 
> 
>> ... in which case a {@code RandomGenerator} is constructed without any seed value:

An already existing issue in the specification in this file is that, a few lines below, we note that:

> <p> There are three groups of random number generator algorithm provided in Java: the Legacy group, the LXM group, and the Xoroshiro/Xoshiro group.

The "three" groups is misleading I think, since both later in the table as well as the `group()` method implementation on `RandomGeneratorFactory`, we return four distinct values "Legacy", "LXM", "Xoroshiro" and "Xoshiro". Should we reword this part of the documentation to remove the mention of "three"?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19212#discussion_r1601022606

From jpai at openjdk.org  Wed May 15 06:46:06 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 15 May 2024 06:46:06 GMT
Subject: RFR: 8332086: Remove the usage of ServiceLoader in
 j.u.r.RandomGeneratorFactory [v4]
In-Reply-To: <hcgzniWvdSy3pM3nsaeUjEM-Aqtyib8t_foGyRDel7s=.84651106-ae19-4f5d-8e3f-54bcd2bcf590@github.com>
References: <hfB86NksORc-aC6zVxHel_QQd_9aB629SfQjXvl6q5U=.e31daa4b-5cf6-4f3f-a757-79e818a18978@github.com>
 <hcgzniWvdSy3pM3nsaeUjEM-Aqtyib8t_foGyRDel7s=.84651106-ae19-4f5d-8e3f-54bcd2bcf590@github.com>
Message-ID: <h4KsQGu7DqYS6Gjtzn3rptqiqxxO4-FSrOdDQsJjrjw=.1ff34c85-ad1f-4b26-9c32-b6860adcc341@github.com>

On Tue, 14 May 2024 16:08:22 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> All random number generator algorithms are implemented in module `java.base`. The usage of `ServiceLoader` in `j.u.r.RandomGeneratorFactory` is no longer needed.
>
> Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Replace SimpleImmutableEntry constructor with Map.entry() factory method.

src/java.base/share/classes/java/util/random/RandomGeneratorFactory.java line 626:

> 624:      * and providing a starting long seed.
> 625:      * If a long seed is not supported by the algorithm,
> 626:      * an {@link UnsupportedOperationException} is thrown.

Perhaps reword this and the other `create(byte[])` method to something like:


* Create an instance of {@link RandomGenerator} based on the
* <a href="package-summary.html#algorithms">algorithm</a> chosen,
* and the provided {@code seed}.
* If the {@code RandomGenerator} doesn't support instantiation through
* a {@code seed} of type {@code long} then this method throws an
* an {@link UnsupportedOperationException}.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19212#discussion_r1601030273

From pminborg at openjdk.org  Wed May 15 06:49:07 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 15 May 2024 06:49:07 GMT
Subject: RFR: 8330465: Stable Values and Collections (Internal) [v2]
In-Reply-To: <1BnXIoSgu8PhvzHlCE5aaxAUtjBrayd935yQSnqZZbc=.18384687-9678-4b84-9cff-95c51f51d528@github.com>
References: <-KSimQo5kkmCzzMShqGe5QZ9yCSzpWL98gN13v4wP0k=.11dd8d06-18a6-4577-8342-66632cea0b6e@github.com>
 <k6l7lLUl6k8QcxvwWIIj3OgWofFtZkSku7EtuLH6COk=.7e2af9f8-5e64-41c9-a778-78f39360a618@github.com>
 <1BnXIoSgu8PhvzHlCE5aaxAUtjBrayd935yQSnqZZbc=.18384687-9678-4b84-9cff-95c51f51d528@github.com>
Message-ID: <hoG1pFX8JIebpVL2pUJb5VDG4C-d4IbZd4uvx2RaINw=.0188e6ff-6ae1-4534-b08c-1c4b77a24cc6@github.com>

On Tue, 14 May 2024 16:02:41 GMT, Viktor Klang <vklang at openjdk.org> wrote:

>> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove text in public class that references an internal class
>
> src/java.base/share/classes/jdk/internal/lang/StableValue.java line 171:
> 
>> 169:     /**
>> 170:      * {@return a fresh stable value with an unset value where the returned stable's
>> 171:      * value is computed in a separate background thread (created via the provided
> 
> Suggestion:
> 
>      * {@return a fresh stable value with an unset value where the returned stable
>      * value is computed in a separate background thread (created via the provided

It is a bit confusing with "stable value" and the "stable value's value".  Maybe something like:


     * {@return a fresh stable value with an unset value where its
     * value is computed in a separate background thread (created via the provided ...


?

> src/java.base/share/classes/jdk/internal/lang/StableValue.java line 175:
> 
>> 173:      * <p>
>> 174:      * If the supplier throws an (unchecked) exception, the exception is ignored, and no
>> 175:      * value is set.
> 
> Is it likely that users will want to be made aware of failures? If so, perhaps it would make sense to make sure that the Exception hits the UncaughtExceptionHandler? ?

Good suggestion. An alternative would be to provide an exception listener getting invoked upon hitting an exception.

> src/java.base/share/classes/jdk/internal/lang/stable/StableArray3DImpl.java line 33:
> 
>> 31:         Objects.checkIndex(i1, dim1);
>> 32:         Objects.checkIndex(i2, dim2);
>> 33:         final int index = i0 * dim1 * dim2 + i1 * dim2 + i2;
> 
> Might be worth doing some overflow checking here?

At construction, we assert the invariant; the product of `dim0, dim1, and dim2` can be fit in an `int`:


private StableArray3DImpl(int dim0, int dim1, int dim2) {
        this(dim0, dim1, dim2, Math.multiplyExact(Math.multiplyExact(dim0, dim1), dim2));
    }

The three `checkIndex(iN, dimN)` ensures each iN is greater than zero and less than dimN. This means, by induction, that the operation `final int index = i0 * dim1 * dim2 + i1 * dim2 + i2;` will never overflow.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18794#discussion_r1601035645
PR Review Comment: https://git.openjdk.org/jdk/pull/18794#discussion_r1601028336
PR Review Comment: https://git.openjdk.org/jdk/pull/18794#discussion_r1601025953

From redestad at openjdk.org  Wed May 15 07:20:37 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Wed, 15 May 2024 07:20:37 GMT
Subject: RFR: 8331724: Refactor j.l.constant implementation to internal
 package [v10]
In-Reply-To: <_GPUF9d1E6eBKRxP6bEEqA3LSKRJe2GwCRTfVYbDwFU=.cb482785-e7c4-45f7-bd3a-cd32d466a2cb@github.com>
References: <_GPUF9d1E6eBKRxP6bEEqA3LSKRJe2GwCRTfVYbDwFU=.cb482785-e7c4-45f7-bd3a-cd32d466a2cb@github.com>
Message-ID: <y_5pS2j4Hp_umMsdQ4CSLMlf9zmDfx4w4iXh61M9C4c=.c66691f0-659b-41ef-94e9-e0749d932cf4@github.com>

> This PR suggests refactoring the implementation classes of java.lang.constant into a new package jdk.internal.constant to enable sharing some trusted static factory methods with users elsewhere in java.base, such as java.lang.invoke and java.lang.classfile. The refactoring also adds some "trusted" methods for use when input is pre-validated, and makes use of them where applicable in the current implementation. There are more changes in the pipeline which will be folded into #17108 or PR'ed once that is integrated. 
> 
> There are two optimizations mixed up here. One in `MethodTypeDesc.ofDescriptor`:
> 
> Name                                                             (descString) Cnt     Base     Error      Test   Error  Unit  Change
> MethodTypeDescFactories.ofDescriptor  (Ljava/lang/Object;Ljava/lang/String;)I   6  138,371 ?   0,767   136,939 ? 1,126 ns/op   1,01x (p = 0,000*)
> MethodTypeDescFactories.ofDescriptor                                      ()V   6   10,528 ?   2,495     4,110 ? 0,047 ns/op   2,56x (p = 0,000*)
> MethodTypeDescFactories.ofDescriptor ([IJLjava/lang/String;Z)Ljava/util/List;   6  209,390 ?   4,583   196,175 ? 3,211 ns/op   1,07x (p = 0,000*)
> MethodTypeDescFactories.ofDescriptor                    ()[Ljava/lang/String;   6   36,039 ?   8,684    20,794 ? 1,110 ns/op   1,73x (p = 0,000*)
> MethodTypeDescFactories.ofDescriptor                                 (..IIJ)V   6  279,139 ?   6,248   187,934 ? 0,857 ns/op   1,49x (p = 0,000*)
> MethodTypeDescFactories.ofDescriptor                 (.....................).   6 2174,387 ? 132,879  1150,652 ? 3,158 ns/op   1,89x (p = 0,000*)
>   * = significant
> 
> 
> The other in `ClassDesc::nested`, where to get rid of a simple static method in `ConstantUtils` I ended up speeding up and simplifying the public factory method:
> 
> Name                                      Cnt    Base     Error    Test   Error  Unit  Change
> ClassDescFactories.ReferenceOnly.ofNested   6 209,853 ? 132,525  22,017 ? 0,573 ns/op   9,53x (p = 0,000*)
>   * = significant
> 
> 
> The optimizations could be split out and PRd independently, but I think they are simple enough to include in this refactoring.

Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:

  Use sb.repeat, consolidate

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19105/files
  - new: https://git.openjdk.org/jdk/pull/19105/files/6d5df18e..b0aca160

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19105&range=09
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19105&range=08-09

  Stats: 8 lines in 1 file changed: 1 ins; 5 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/19105.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19105/head:pull/19105

PR: https://git.openjdk.org/jdk/pull/19105

From redestad at openjdk.org  Wed May 15 07:20:37 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Wed, 15 May 2024 07:20:37 GMT
Subject: RFR: 8331724: Refactor j.l.constant implementation to internal
 package [v9]
In-Reply-To: <W78MmrX44sVhytHBQj4JUE-wNK1RtrxUS6h0PdXewhc=.91e60f61-2d95-4e2b-89bc-b47f343f2e50@github.com>
References: <_GPUF9d1E6eBKRxP6bEEqA3LSKRJe2GwCRTfVYbDwFU=.cb482785-e7c4-45f7-bd3a-cd32d466a2cb@github.com>
 <_ZuDS5DbpEUnhV64qoXok-S0o8l7dof98Vl8BwCdBuM=.bcccdef0-a5c2-4e59-9517-c3b4980225a4@github.com>
 <W78MmrX44sVhytHBQj4JUE-wNK1RtrxUS6h0PdXewhc=.91e60f61-2d95-4e2b-89bc-b47f343f2e50@github.com>
Message-ID: <1wZbAw87Y08xQaSexmblXR7j9U4JxVrLG6mEQiVrOTk=.07b112c4-237c-4316-9478-e4fd57c6c232@github.com>

On Tue, 14 May 2024 20:20:59 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add microbenchmark for ClassDesc methods + a few optimizations
>
> src/java.base/share/classes/java/lang/constant/ClassDesc.java line 226:
> 
>> 224:         for (int i = 0; i < rank; i++) {
>> 225:             sb.append('[');
>> 226:         }
> 
> Would `sb.repeat("[", rank);` be better here?
> 
> Also for parity with `arrayType()` I recommend moving this building code to after the void check.

Oh, that's new (in 21). I was comparing against `append("[".repeat(rank))` which had a cost here. `sb.repeat('[', rank)` is in the same ballpark and simpler. Fixing.


Benchmark                                       Mode  Cnt     Score     Error   Units
ClassDescMethods.arrayType2                     avgt   15    31,568 ?   2,108   ns/op
ClassDescMethods.arrayType2:gc.alloc.rate       avgt   15  7758,056 ? 474,378  MB/sec
ClassDescMethods.arrayType2:gc.alloc.rate.norm  avgt   15   256,000 ?   0,001    B/op


I'll align the code to construct `newDesc` before the void check in both methods.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19105#discussion_r1601088246

From pminborg at openjdk.org  Wed May 15 07:39:25 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 15 May 2024 07:39:25 GMT
Subject: RFR: 8330465: Stable Values and Collections (Internal) [v3]
In-Reply-To: <-KSimQo5kkmCzzMShqGe5QZ9yCSzpWL98gN13v4wP0k=.11dd8d06-18a6-4577-8342-66632cea0b6e@github.com>
References: <-KSimQo5kkmCzzMShqGe5QZ9yCSzpWL98gN13v4wP0k=.11dd8d06-18a6-4577-8342-66632cea0b6e@github.com>
Message-ID: <d8ZFcGRfyTRNlcLu5k1r_c4ABoJP85r-4qBwK51Rxas=.8d53e2e1-5ed2-414f-9554-f5113d613161@github.com>

> # Stable Values & Collections (Internal)
> 
> ## Summary
> This PR proposes to introduce an internal _Stable Values & Collections_ API, which provides immutable value holders where elements are initialized _at most once_. Stable Values & Collections offer the performance and safety benefits of final fields while offering greater flexibility as to the timing of initialization.
> 
> ## Goals
>  * Provide an easy and intuitive API to describe value holders that can change at most once.
>  * Decouple declaration from initialization without significant footprint or performance penalties.
>  * Reduce the amount of static initializer and/or field initialization code.
>  * Uphold integrity and consistency, even in a multi-threaded environment.
>  
> For more details, see the draft JEP: https://openjdk.org/jeps/8312611
> 
> ## Performance 
> Performance compared to instance variables using an `AtomicReference` and one protected by double-checked locking under concurrent access by 8 threads:
> 
> 
> Benchmark                       Mode  Cnt  Score   Error  Units
> StableBenchmark.instanceAtomic  avgt   10  1.576 ? 0.052  ns/op
> StableBenchmark.instanceDCL     avgt   10  1.608 ? 0.059  ns/op
> StableBenchmark.instanceStable  avgt   10  0.979 ? 0.023  ns/op <- StableValue (~40% faster than DCL)
> 
> 
> Performance compared to static variables protected by `AtomicReference`, class-holder idiom holder, and double-checked locking (8 threads):
> 
> 
> Benchmark                       Mode  Cnt  Score   Error  Units
> StableBenchmark.staticAtomic    avgt   10  1.335 ? 0.056  ns/op
> StableBenchmark.staticCHI       avgt   10  0.623 ? 0.086  ns/op
> StableBenchmark.staticDCL       avgt   10  1.418 ? 0.171  ns/op
> StableBenchmark.staticList      avgt   10  0.617 ? 0.024  ns/op
> StableBenchmark.staticStable    avgt   10  0.604 ? 0.022  ns/op <- StableValue ( > 2x faster than `AtomicInteger` and DCL)
> 
> 
> Performance for stable lists in both instance and static contexts whereby the sum of random contents is calculated for stable lists (which are thread-safe) compared to `ArrayList` instances (which are not thread-safe) (under single thread access):
> 
> 
> Benchmark                                     Mode  Cnt  Score   Error  Units
> StableListSumBenchmark.instanceArrayList      avgt   10  0.356 ? 0.005  ns/op
> StableListSumBenchmark.instanceList           avgt   10  0.373 ? 0.017  ns/op <- Stable list
> StableListSumBenchmark.staticArrayList        avgt   10  0.352 ? 0.002  ns/op
> StableListSumBenchmark.staticList             avgt   10  0.356 ? 0.00...

Per Minborg has updated the pull request incrementally with one additional commit since the last revision:

  Add delegation to the thread's exception handler

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/18794/files
  - new: https://git.openjdk.org/jdk/pull/18794/files/d7c31585..7db1101c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18794&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18794&range=01-02

  Stats: 70 lines in 3 files changed: 62 ins; 0 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/18794.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18794/head:pull/18794

PR: https://git.openjdk.org/jdk/pull/18794

From pminborg at openjdk.org  Wed May 15 07:48:42 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 15 May 2024 07:48:42 GMT
Subject: RFR: 8330465: Stable Values and Collections (Internal) [v4]
In-Reply-To: <-KSimQo5kkmCzzMShqGe5QZ9yCSzpWL98gN13v4wP0k=.11dd8d06-18a6-4577-8342-66632cea0b6e@github.com>
References: <-KSimQo5kkmCzzMShqGe5QZ9yCSzpWL98gN13v4wP0k=.11dd8d06-18a6-4577-8342-66632cea0b6e@github.com>
Message-ID: <Aoeah2Qx-yd_WnZV4YKBJrU-N_Ht2U2FBymgFK5B_jg=.caf754c8-4f71-4dda-b093-7f3ef050d1c0@github.com>

> # Stable Values & Collections (Internal)
> 
> ## Summary
> This PR proposes to introduce an internal _Stable Values & Collections_ API, which provides immutable value holders where elements are initialized _at most once_. Stable Values & Collections offer the performance and safety benefits of final fields while offering greater flexibility as to the timing of initialization.
> 
> ## Goals
>  * Provide an easy and intuitive API to describe value holders that can change at most once.
>  * Decouple declaration from initialization without significant footprint or performance penalties.
>  * Reduce the amount of static initializer and/or field initialization code.
>  * Uphold integrity and consistency, even in a multi-threaded environment.
>  
> For more details, see the draft JEP: https://openjdk.org/jeps/8312611
> 
> ## Performance 
> Performance compared to instance variables using an `AtomicReference` and one protected by double-checked locking under concurrent access by 8 threads:
> 
> 
> Benchmark                       Mode  Cnt  Score   Error  Units
> StableBenchmark.instanceAtomic  avgt   10  1.576 ? 0.052  ns/op
> StableBenchmark.instanceDCL     avgt   10  1.608 ? 0.059  ns/op
> StableBenchmark.instanceStable  avgt   10  0.979 ? 0.023  ns/op <- StableValue (~40% faster than DCL)
> 
> 
> Performance compared to static variables protected by `AtomicReference`, class-holder idiom holder, and double-checked locking (8 threads):
> 
> 
> Benchmark                       Mode  Cnt  Score   Error  Units
> StableBenchmark.staticAtomic    avgt   10  1.335 ? 0.056  ns/op
> StableBenchmark.staticCHI       avgt   10  0.623 ? 0.086  ns/op
> StableBenchmark.staticDCL       avgt   10  1.418 ? 0.171  ns/op
> StableBenchmark.staticList      avgt   10  0.617 ? 0.024  ns/op
> StableBenchmark.staticStable    avgt   10  0.604 ? 0.022  ns/op <- StableValue ( > 2x faster than `AtomicInteger` and DCL)
> 
> 
> Performance for stable lists in both instance and static contexts whereby the sum of random contents is calculated for stable lists (which are thread-safe) compared to `ArrayList` instances (which are not thread-safe) (under single thread access):
> 
> 
> Benchmark                                     Mode  Cnt  Score   Error  Units
> StableListSumBenchmark.instanceArrayList      avgt   10  0.356 ? 0.005  ns/op
> StableListSumBenchmark.instanceList           avgt   10  0.373 ? 0.017  ns/op <- Stable list
> StableListSumBenchmark.staticArrayList        avgt   10  0.352 ? 0.002  ns/op
> StableListSumBenchmark.staticList             avgt   10  0.356 ? 0.00...

Per Minborg has updated the pull request incrementally with one additional commit since the last revision:

  Revise docs for ofBackground()

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/18794/files
  - new: https://git.openjdk.org/jdk/pull/18794/files/7db1101c..c92b16c4

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18794&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18794&range=02-03

  Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/18794.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18794/head:pull/18794

PR: https://git.openjdk.org/jdk/pull/18794

From asotona at openjdk.org  Wed May 15 07:51:33 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Wed, 15 May 2024 07:51:33 GMT
Subject: RFR: 8331940: ClassFile API ArrayIndexOutOfBoundsException with
 certain class files [v2]
In-Reply-To: <wWNlHWtc5H1nl9YHXQHGJBdJt-uo3p89E8MeGsRjsKY=.10b28a54-3530-42dc-8b24-5a4da8b81f9a@github.com>
References: <wWNlHWtc5H1nl9YHXQHGJBdJt-uo3p89E8MeGsRjsKY=.10b28a54-3530-42dc-8b24-5a4da8b81f9a@github.com>
Message-ID: <1XmBInBynHASRbJqzNvfriDMuz5xQmczMv1nXsSWSYo=.a5146cc9-2d11-4514-bc47-83884276d253@github.com>

> Class file with `LineNumberTable` attribute element pointing behind the bytecode array throws `ArrayIndexOutOfBoundsException`.
> This patch performs the check and throws  expected `IllegalArgumentException` instead.
> Relevant test is added.
> 
> Please review.
> 
> Thanks,
> Adam

Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:

  fixed exception message

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19230/files
  - new: https://git.openjdk.org/jdk/pull/19230/files/f2a8d981..df6ecdc2

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19230&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19230&range=00-01

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/19230.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19230/head:pull/19230

PR: https://git.openjdk.org/jdk/pull/19230

From asotona at openjdk.org  Wed May 15 07:51:33 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Wed, 15 May 2024 07:51:33 GMT
Subject: RFR: 8331940: ClassFile API ArrayIndexOutOfBoundsException with
 certain class files [v2]
In-Reply-To: <YbR5vW3TX1b2dTRlXmvWufVe_sbui3elsa_RI8trg0k=.169877b0-bd8f-402b-a559-9f0493746616@github.com>
References: <wWNlHWtc5H1nl9YHXQHGJBdJt-uo3p89E8MeGsRjsKY=.10b28a54-3530-42dc-8b24-5a4da8b81f9a@github.com>
 <YbR5vW3TX1b2dTRlXmvWufVe_sbui3elsa_RI8trg0k=.169877b0-bd8f-402b-a559-9f0493746616@github.com>
Message-ID: <gQD9CngRW17tN8_bUKLkqP-ip-j_HAVd9rxQPC-zeec=.4166a6e2-72ec-4c40-bcfc-ea3d6041c64f@github.com>

On Tue, 14 May 2024 15:59:33 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fixed exception message
>
> src/java.base/share/classes/jdk/internal/classfile/impl/CodeImpl.java line 241:
> 
>> 239:                     int startPc = classReader.readU2(p);
>> 240:                     if (startPc > codeLength) {
>> 241:                         throw new IllegalArgumentException(String.format("Line number out of range; start_pc=%d, codeLength=%d",
> 
> It's the byte code index that is out of range, not the line number associated with it.

Right, fixed the message, thanks!

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19230#discussion_r1601131607

From duke at openjdk.org  Wed May 15 07:59:04 2024
From: duke at openjdk.org (ExE Boss)
Date: Wed, 15 May 2024 07:59:04 GMT
Subject: RFR: 8331671: Implement JEP 472: Prepare to Restrict the Use of
 JNI [v4]
In-Reply-To: <sxwnadwC7gqIP9jLa6QyaV-wSYTH0FwuJf3HA-hfW6g=.292d839e-1480-43b4-9949-2dd7074f4cbe@github.com>
References: <CZGbki5iFdCGPPagE-ya-_L8Nkgf7OunywApOsxC548=.2cee82fa-a5d2-4165-b012-30982a85030a@github.com>
 <sxwnadwC7gqIP9jLa6QyaV-wSYTH0FwuJf3HA-hfW6g=.292d839e-1480-43b4-9949-2dd7074f4cbe@github.com>
Message-ID: <FaT2ocY-kpnuV6QHTbSp0JZSDqPSLOK9TJaNxJ4HJhE=.22667c74-0cc5-44e1-8ad8-e48ec65dce29@github.com>

On Tue, 14 May 2024 18:10:28 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This PR implements [JEP 472](https://openjdk.org/jeps/472), by restricting the use of JNI in the following ways:
>> 
>> * `System::load` and `System::loadLibrary` are now restricted methods
>> * `Runtime::load` and `Runtime::loadLibrary` are now restricted methods
>> * binding a JNI `native` method declaration to a native implementation is now considered a restricted operation
>> 
>> This PR slightly changes the way in which the JDK deals with restricted methods, even for FFM API calls. In Java 22, the single `--enable-native-access` was used both to specify a set of modules for which native access should be allowed *and* to specify whether illegal native access (that is, native access occurring from a module not specified by `--enable-native-access`) should be treated as an error or a warning. More specifically, an error is only issued if the `--enable-native-access flag` is used at least once.
>> 
>> Here, a new flag is introduced, namely `illegal-native-access=allow/warn/deny`, which is used to specify what should happen when access to a restricted method and/or functionality is found outside the set of modules specified with `--enable-native-access`. The default policy is `warn`, but users can select `allow` to suppress the warnings, or `deny` to cause `IllegalCallerException` to be thrown. This aligns the treatment of restricted methods with other mechanisms, such as `--illegal-access` and the more recent `--sun-misc-unsafe-memory-access`.
>> 
>> Some changes were required in the package-info javadoc for `java.lang.foreign`, to reflect the changes in the command line flags described above.
>
> Maurizio Cimadamore has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Address review comments
>    Improve warning for JNI methods, similar to what's described in JEP 472
>    Beef up tests
>  - Address review comments

src/java.base/share/classes/java/lang/Module.java line 334:

> 332:                     System.err.printf("""
> 333:                             WARNING: A native method in %s has been bound
> 334:                             WARNING: %s has been called by %s in %s

Note that this line is still not entirely correct, as for code like:

// in module a:
package a;

import b.Foo;

public class Foo {
	public static void main(String... args) {
		System.load("JNI library implementing Java_b_Bar_nativeMethod");

		Bar.nativeMethod();
	}
}


// in module b:
package b;

public class Bar {
	public static native void nativeMethod();
}


It?ll?show?`Bar` as?the?caller of?`Bar::nativeMethod()`, even?though the?caller is?`Foo` in?this?case, which?is?why I?initially?suggested just?omitting the?caller from?**JNI** linkage?warnings.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19213#discussion_r1601140578

From duke at openjdk.org  Wed May 15 08:59:14 2024
From: duke at openjdk.org (ExE Boss)
Date: Wed, 15 May 2024 08:59:14 GMT
Subject: RFR: 8330465: Stable Values and Collections (Internal) [v4]
In-Reply-To: <Aoeah2Qx-yd_WnZV4YKBJrU-N_Ht2U2FBymgFK5B_jg=.caf754c8-4f71-4dda-b093-7f3ef050d1c0@github.com>
References: <-KSimQo5kkmCzzMShqGe5QZ9yCSzpWL98gN13v4wP0k=.11dd8d06-18a6-4577-8342-66632cea0b6e@github.com>
 <Aoeah2Qx-yd_WnZV4YKBJrU-N_Ht2U2FBymgFK5B_jg=.caf754c8-4f71-4dda-b093-7f3ef050d1c0@github.com>
Message-ID: <WTvK6htLFImBbqJaegAYhe66v-7Ukg1Rbr_SBPAAUw4=.0339bae0-9215-4786-9847-b54428d6e1fa@github.com>

On Wed, 15 May 2024 07:48:42 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> # Stable Values & Collections (Internal)
>> 
>> ## Summary
>> This PR proposes to introduce an internal _Stable Values & Collections_ API, which provides immutable value holders where elements are initialized _at most once_. Stable Values & Collections offer the performance and safety benefits of final fields while offering greater flexibility as to the timing of initialization.
>> 
>> ## Goals
>>  * Provide an easy and intuitive API to describe value holders that can change at most once.
>>  * Decouple declaration from initialization without significant footprint or performance penalties.
>>  * Reduce the amount of static initializer and/or field initialization code.
>>  * Uphold integrity and consistency, even in a multi-threaded environment.
>>  
>> For more details, see the draft JEP: https://openjdk.org/jeps/8312611
>> 
>> ## Performance 
>> Performance compared to instance variables using an `AtomicReference` and one protected by double-checked locking under concurrent access by 8 threads:
>> 
>> 
>> Benchmark                       Mode  Cnt  Score   Error  Units
>> StableBenchmark.instanceAtomic  avgt   10  1.576 ? 0.052  ns/op
>> StableBenchmark.instanceDCL     avgt   10  1.608 ? 0.059  ns/op
>> StableBenchmark.instanceStable  avgt   10  0.979 ? 0.023  ns/op <- StableValue (~40% faster than DCL)
>> 
>> 
>> Performance compared to static variables protected by `AtomicReference`, class-holder idiom holder, and double-checked locking (8 threads):
>> 
>> 
>> Benchmark                       Mode  Cnt  Score   Error  Units
>> StableBenchmark.staticAtomic    avgt   10  1.335 ? 0.056  ns/op
>> StableBenchmark.staticCHI       avgt   10  0.623 ? 0.086  ns/op
>> StableBenchmark.staticDCL       avgt   10  1.418 ? 0.171  ns/op
>> StableBenchmark.staticList      avgt   10  0.617 ? 0.024  ns/op
>> StableBenchmark.staticStable    avgt   10  0.604 ? 0.022  ns/op <- StableValue ( > 2x faster than `AtomicInteger` and DCL)
>> 
>> 
>> Performance for stable lists in both instance and static contexts whereby the sum of random contents is calculated for stable lists (which are thread-safe) compared to `ArrayList` instances (which are not thread-safe) (under single thread access):
>> 
>> 
>> Benchmark                                     Mode  Cnt  Score   Error  Units
>> StableListSumBenchmark.instanceArrayList      avgt   10  0.356 ? 0.005  ns/op
>> StableListSumBenchmark.instanceList           avgt   10  0.373 ? 0.017  ns/op <- Stable list
>> StableListSumBenchmark.staticArrayList        avgt   10  0.352 ? ...
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revise docs for ofBackground()

src/java.base/share/classes/jdk/internal/lang/StableValue.java line 1:

> 1: /*

Maybe also add `StableValue?::?<T>ofLazy?(Supplier<??extends?T>)` which?behaves more?like the?original **Computed?Constants** JEP?draft?

src/java.base/share/classes/jdk/internal/lang/stable/TrustedFieldType.java line 14:

> 12:  * operations.
> 13:  */
> 14: public sealed interface TrustedFieldType

Maybe?export this?interface to?`jdk.unsupported`?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18794#discussion_r1601229245
PR Review Comment: https://git.openjdk.org/jdk/pull/18794#discussion_r1601223866

From mdoerr at openjdk.org  Wed May 15 09:34:11 2024
From: mdoerr at openjdk.org (Martin Doerr)
Date: Wed, 15 May 2024 09:34:11 GMT
Subject: RFR: 8329653: JLILaunchTest fails on AIX after JDK-8329131 [v3]
In-Reply-To: <D3ZEVmfJIpjMyN7u9tLewNo0N5xuIQWGeFiBgnvdxsM=.1859ec49-d2ef-4c45-8008-24f48313d231@github.com>
References: <y9wItIb8Yr_ZrHfN_kV5lDCp-d-VtYam3MuHX1OxurU=.ce3378d2-90b3-4396-8951-4651439e4f90@github.com>
 <D3ZEVmfJIpjMyN7u9tLewNo0N5xuIQWGeFiBgnvdxsM=.1859ec49-d2ef-4c45-8008-24f48313d231@github.com>
Message-ID: <3tNxvjoLSIbYLCas2dijmaBTK_kPGXFxd9XdJ2BBS1A=.4db3b6a2-c25d-419d-874a-06ce6d7c3c0f@github.com>

On Tue, 7 May 2024 08:08:05 GMT, Joachim Kern <jkern at openjdk.org> wrote:

>> Since ~ end of March, after [JDK-8329131](https://bugs.openjdk.org/browse/JDK-8329131), tools/launcher/JliLaunchTest.java fails on AIX. Failure is :
>> 
>>  stdout: [];
>>  stderr: [Error: could not find libjava.so
>> Error: Could not find Java SE Runtime Environment.
>> ]
>>  exitValue = 2
>> 
>> java.lang.RuntimeException: Expected to get exit value of [0], exit value is: [2]
>> at jdk.test.lib.process.OutputAnalyzer.shouldHaveExitValue(OutputAnalyzer.java:521)
>> at JliLaunchTest.main(JliLaunchTest.java:58)
>> at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
>> at java.base/java.lang.reflect.Method.invoke(Method.java:580)
>> at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:333)
>> at java.base/java.lang.Thread.run(Thread.java:1575)
>> 
>> Maybe we need to do further adjustments to BUILD_JDK_JTREG_EXECUTABLES_LIBS_exeJliLaunchTest / BUILD_JDK_JTREG_EXECUTABLES_LDFLAGS_exeJliLaunchTest on AIX ?
>> Or somehow adjust the coding that attempts to find parts of "JRE" (libjava.so) ? The libjli.so is gone on AIX after [JDK-8329131](https://bugs.openjdk.org/browse/JDK-8329131), and with this also the image discovery based on GetApplicationHomeFromDll which uses libjli.so .
>> 
>> Without libjli.so we have to analyze the LD-LIBRARY_PATH / LIBPATH envvar. There is no other methos available on AIX, because it lacks the $ORIGIN feature of the rpath.
>
> Joachim Kern has updated the pull request incrementally with one additional commit since the last revision:
> 
>   cosmetic changes

LGTM.

-------------

Marked as reviewed by mdoerr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19000#pullrequestreview-2057450094

From duke at openjdk.org  Wed May 15 09:44:15 2024
From: duke at openjdk.org (serhiysachkov)
Date: Wed, 15 May 2024 09:44:15 GMT
Subject: RFR: 8331851: Add specific regression leap year tests for
 Calendar.roll()
Message-ID: <kB-PMNTKDCXUa_0GFeslsF_8iTU_P5fpgPzdpp2NmTQ=.b41869f1-5ffb-46a9-a499-6fdca3e98e69@github.com>

Add specific regression tests for Calendar.roll() method to explicitly various leap year test scenarios. This is inspired by the ambiguity which occurred in leap year unaware test creation as in case with Calendar.add() in swing component test case as detailed in (https://bugs.openjdk.org/browse/JDK-8327088).

-------------

Commit messages:
 - JDK-8331851 Add specific regression leap year tests for Calendar.roll()

Changes: https://git.openjdk.org/jdk/pull/19247/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19247&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8331851
  Stats: 190 lines in 1 file changed: 190 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/19247.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19247/head:pull/19247

PR: https://git.openjdk.org/jdk/pull/19247

From mcimadamore at openjdk.org  Wed May 15 09:48:17 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 15 May 2024 09:48:17 GMT
Subject: RFR: 8320396: Class-File API ClassModel::verify should include
 checks from hotspot/share/classfile/classFileParser.cpp [v6]
In-Reply-To: <HCwLBI-iyD3eCNWhKURiBboVhDwlpyBxPUL3Mur7UJc=.09225151-1960-4e45-80f9-977006b18a3d@github.com>
References: <0a66asWcJ4_zBrjmReA18BZmsovN1ZeJRRSAPZDMZmo=.5bada03f-d88d-46cd-962d-c1e42c3048c1@github.com>
 <HCwLBI-iyD3eCNWhKURiBboVhDwlpyBxPUL3Mur7UJc=.09225151-1960-4e45-80f9-977006b18a3d@github.com>
Message-ID: <R9qzyd6zhRtXJzrslNATmgRZ3jIEA8XfYRh6kNLd-O8=.6be73dbb-58e8-4619-8a89-3f90b14649ed@github.com>

On Tue, 14 May 2024 11:42:19 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> ClassFile API `jdk.internal.classfile.verifier.VerifierImpl` performed only bytecode-level class verification.
>> This patch adds `jdk.internal.classfile.verifier.ParserVerifier` with additional class checks inspired by `hotspot/share/classfile/classFileParser.cpp`.
>> 
>> Also new `VerifierSelfTest::testParserVerifier` has been added.
>> 
>> Please review.
>> 
>> Thanks,
>> Adam
>
> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
> 
>   applied the suggested changes

src/java.base/share/classes/jdk/internal/classfile/impl/verifier/ParserVerifier.java line 205:

> 203:     private void verifyAttribute(AttributedElement ae, Attribute<?> a, List<VerifyError> errors) {
> 204:         int size = -1;
> 205:         switch (a) {

Maybe use a switch expression to set `size` where `default` yields -1?

src/java.base/share/classes/jdk/internal/classfile/impl/verifier/ParserVerifier.java line 306:

> 304:                 size = 1;
> 305:                 for (var ans : aa.parameterAnnotations()) {
> 306:                     size += annotationsSize(ans);

Shouldn't we call the new method here (passing `parameterAnnotations`) ?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16809#discussion_r1601317434
PR Review Comment: https://git.openjdk.org/jdk/pull/16809#discussion_r1601320492

From dfuchs at openjdk.org  Wed May 15 09:50:14 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 15 May 2024 09:50:14 GMT
Subject: RFR: 8331987: Enhance stacktrace clarity for CompletableFuture
 CancellationException [v2]
In-Reply-To: <RwiMTpthY-AzuKJz7IESDRvEpp_yAA_HSsxMMHM42xM=.86290ec9-c841-4698-839c-eda03fa3fb03@github.com>
References: <JI-ghId-imtBqmNm850oQMNp-9p79tGMjfTRDdXz6D0=.fc134f86-914c-4484-9236-af162de3b99e@github.com>
 <RwiMTpthY-AzuKJz7IESDRvEpp_yAA_HSsxMMHM42xM=.86290ec9-c841-4698-839c-eda03fa3fb03@github.com>
Message-ID: <zSbbt6A82G2pmBeP5GOK-OzVyR9-DsTUeMFThYgRdz0=.c43fd5f0-02e4-47a1-b81b-fe3fd1e797af@github.com>

On Mon, 13 May 2024 23:59:17 GMT, Viktor Klang <vklang at openjdk.org> wrote:

>> This change adds wrapping of the CancellationException produced by CompletableFuture::get() and CompletableFuture::join() to add more diagnostic information and align better with FutureTask.
>> 
>> Running the sample code from the JBS issue in JShell will produce the following:
>> 
>> 
>> jshell> java.util.concurrent.CancellationException: get
>> 	at java.base/java.util.concurrent.CompletableFuture.reportGet(CompletableFuture.java:392)
>> 	at java.base/java.util.concurrent.CompletableFuture.get(CompletableFuture.java:2073)
>> 	at REPL.$JShell$18.m2($JShell$18.java:10)
>> 	at REPL.$JShell$17.m1($JShell$17.java:8)
>> 	at REPL.$JShell$16B.lambda$main$0($JShell$16B.java:8)
>> 	at java.base/java.lang.Thread.run(Thread.java:1575)
>> Caused by: java.util.concurrent.CancellationException
>> 	at java.base/java.util.concurrent.CompletableFuture.cancel(CompletableFuture.java:2510)
>> 	at REPL.$JShell$16B.lambda$main$1($JShell$16B.java:11)
>> 	... 1 more
>
> Viktor Klang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adding CancellationException detail message to CompletableFuture

LGTM

-------------

Marked as reviewed by dfuchs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19219#pullrequestreview-2057484574

From sgehwolf at openjdk.org  Wed May 15 09:50:32 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Wed, 15 May 2024 09:50:32 GMT
Subject: RFR: 8311302: Allow for jlinking a custom runtime without packaged
 modules being present [v27]
In-Reply-To: <Z0DJ87uKPbjS6mvJIE_oG5m-RWsbERXsytSgV8Bmhdo=.f8723513-0ac6-4e85-9131-3c3924860c61@github.com>
References: <Z0DJ87uKPbjS6mvJIE_oG5m-RWsbERXsytSgV8Bmhdo=.f8723513-0ac6-4e85-9131-3c3924860c61@github.com>
Message-ID: <UdT2bAK6NfJbUFW-xbKTT9xPP79b_ue0bwdsxR1pHyw=.5e98785f-646e-42aa-bf47-888dc52593e0@github.com>

> Please review this patch which adds a jlink mode to the JDK which doesn't need the packaged modules being present. A.k.a run-time image based jlink. Fundamentally this patch adds an option to use `jlink` even though your JDK install might not come with the packaged modules (directory `jmods`). This is particularly useful to further reduce the size of a jlinked runtime. After the removal of the concept of a JRE, a common distribution mechanism is still the full JDK with all modules and packaged modules. However, packaged modules can incur an additional size tax. For example in a container scenario it could be useful to have a base JDK container including all modules, but without also delivering the packaged modules. This comes at a size advantage of `~25%`. Such a base JDK container could then be used to `jlink` application specific runtimes, further reducing the size of the application runtime image (App + JDK runtime; as a single image *or* separate bundles, depending on the app b
 eing modularized).
> 
> The basic design of this approach is to add a jlink plugin for tracking non-class and non-resource files of a JDK install. I.e. files which aren't present in the jimage (`lib/modules`). This enables producing a `JRTArchive` class which has all the info of what constitutes the final jlinked runtime.
> 
> Basic usage example:
> 
> $ diff -u <(./bin/java --list-modules --limit-modules java.se) <(../linux-x86_64-server-release/images/jdk/bin/java --list-modules --limit-modules java.se)
> $ diff -u <(./bin/java --list-modules --limit-modules jdk.jlink) <(../linux-x86_64-server-release/images/jdk/bin/java --list-modules --limit-modules jdk.jlink)
> $ ls ../linux-x86_64-server-release/images/jdk/jmods
> java.base.jmod            java.net.http.jmod       java.sql.rowset.jmod      jdk.crypto.ec.jmod         jdk.internal.opt.jmod                     jdk.jdi.jmod         jdk.management.agent.jmod  jdk.security.auth.jmod
> java.compiler.jmod        java.prefs.jmod          java.transaction.xa.jmod  jdk.dynalink.jmod          jdk.internal.vm.ci.jmod                   jdk.jdwp.agent.jmod  jdk.management.jfr.jmod    jdk.security.jgss.jmod
> java.datatransfer.jmod    java.rmi.jmod            java.xml.crypto.jmod      jdk.editpad.jmod           jdk.internal.vm.compiler.jmod             jdk.jfr.jmod         jdk.management.jmod        jdk.unsupported.desktop.jmod
> java.desktop.jmod         java.scripting.jmod      java.xml.jmod             jdk.hotspot.agent.jmod     jdk.internal.vm.compiler.manage...

Severin Gehwolf has updated the pull request incrementally with two additional commits since the last revision:

 - Simplify JLINK_JDK_EXTRA_OPTS var handling
 - Only add runtime track files for linkable runtimes

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14787/files
  - new: https://git.openjdk.org/jdk/pull/14787/files/67aea4ca..be30a182

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14787&range=26
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14787&range=25-26

  Stats: 11 lines in 2 files changed: 5 ins; 5 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/14787.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14787/head:pull/14787

PR: https://git.openjdk.org/jdk/pull/14787

From sgehwolf at openjdk.org  Wed May 15 09:50:35 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Wed, 15 May 2024 09:50:35 GMT
Subject: RFR: 8311302: Allow for jlinking a custom runtime without packaged
 modules being present [v26]
In-Reply-To: <7GEk4PVZYWDSKt8bWCVSHD4f8zFmmJNWwJojxrFgwC4=.10d95786-32d8-40e8-bb21-1647da3ee39c@github.com>
References: <Z0DJ87uKPbjS6mvJIE_oG5m-RWsbERXsytSgV8Bmhdo=.f8723513-0ac6-4e85-9131-3c3924860c61@github.com>
 <RUr5xr-pzsccK28vRBO-GhY-8RltknEX2lyMgWpijnA=.980d0b9d-f219-4bc7-bf64-4e343f44ac7d@github.com>
 <7GEk4PVZYWDSKt8bWCVSHD4f8zFmmJNWwJojxrFgwC4=.10d95786-32d8-40e8-bb21-1647da3ee39c@github.com>
Message-ID: <Fhquw_glamRLkd_m1Tu-xHR88AxOjryaiwbQ7PA4UeE=.c681a4a9-1d98-4606-bb07-1b1170ca9673@github.com>

On Wed, 8 May 2024 22:36:51 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Severin Gehwolf has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 105 commits:
>> 
>>  - Generate the runtime image link diff at jlink time
>>    
>>    But only do that once the plugin-pipeline has run. The generation is
>>    enabled with the hidden option '--generate-linkable-runtime' and
>>    the resource pools available at jlink time are being used to generate
>>    the diff.
>>  - Merge branch 'master' into jdk-8311302-jmodless-link
>>  - Use shorter name for the build tool
>>  - Review feedback from Erik J.
>>  - Remove dependency on CDS which isn't needed anymore
>>  - Fix coment
>>  - Fix comment
>>  - Fix typo
>>  - Revert some now unneded build changes
>>  - Follow build tools naming convention
>>  - ... and 95 more: https://git.openjdk.org/jdk/compare/23a72a1f...67aea4ca
>
> make/Images.gmk line 100:
> 
>> 98: 
>> 99: ifeq ($(JLINK_PRODUCE_RUNTIME_LINK_JDK), true)
>> 100:   JLINK_JDK_EXTRA_OPTS := $(JLINK_JDK_EXTRA_OPTS) --generate-linkable-runtime
> 
> I just noticed this slight improvement:
> 
> Suggestion:
> 
>   JLINK_JDK_EXTRA_OPTS += --generate-linkable-runtime

Thanks, fixed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14787#discussion_r1601322116

From rgiulietti at openjdk.org  Wed May 15 09:51:23 2024
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Wed, 15 May 2024 09:51:23 GMT
Subject: RFR: 8332086: Remove the usage of ServiceLoader in
 j.u.r.RandomGeneratorFactory [v5]
In-Reply-To: <hfB86NksORc-aC6zVxHel_QQd_9aB629SfQjXvl6q5U=.e31daa4b-5cf6-4f3f-a757-79e818a18978@github.com>
References: <hfB86NksORc-aC6zVxHel_QQd_9aB629SfQjXvl6q5U=.e31daa4b-5cf6-4f3f-a757-79e818a18978@github.com>
Message-ID: <ZasWP14ViFxaPqk_x3rmDgVFocTX9_aAP1W_kplDjbE=.b5fa3a6a-c303-4fe7-afbe-01700d4a7e85@github.com>

> All random number generator algorithms are implemented in module `java.base`. The usage of `ServiceLoader` in `j.u.r.RandomGeneratorFactory` is no longer needed.

Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:

  Small documentation changes.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19212/files
  - new: https://git.openjdk.org/jdk/pull/19212/files/4bc5bf95..920655a5

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19212&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19212&range=03-04

  Stats: 23 lines in 2 files changed: 6 ins; 1 del; 16 mod
  Patch: https://git.openjdk.org/jdk/pull/19212.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19212/head:pull/19212

PR: https://git.openjdk.org/jdk/pull/19212

From asotona at openjdk.org  Wed May 15 09:55:05 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Wed, 15 May 2024 09:55:05 GMT
Subject: RFR: 8331724: Refactor j.l.constant implementation to internal
 package [v10]
In-Reply-To: <y_5pS2j4Hp_umMsdQ4CSLMlf9zmDfx4w4iXh61M9C4c=.c66691f0-659b-41ef-94e9-e0749d932cf4@github.com>
References: <_GPUF9d1E6eBKRxP6bEEqA3LSKRJe2GwCRTfVYbDwFU=.cb482785-e7c4-45f7-bd3a-cd32d466a2cb@github.com>
 <y_5pS2j4Hp_umMsdQ4CSLMlf9zmDfx4w4iXh61M9C4c=.c66691f0-659b-41ef-94e9-e0749d932cf4@github.com>
Message-ID: <h8CYXclAa5KmODobs7HUTPuFOHkeGjFFyAvUTIohkEs=.c306cbf6-5e4e-47ac-8f15-282cf69cfd06@github.com>

On Wed, 15 May 2024 07:20:37 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> This PR suggests refactoring the implementation classes of java.lang.constant into a new package jdk.internal.constant to enable sharing some trusted static factory methods with users elsewhere in java.base, such as java.lang.invoke and java.lang.classfile. The refactoring also adds some "trusted" methods for use when input is pre-validated, and makes use of them where applicable in the current implementation. There are more changes in the pipeline which will be folded into #17108 or PR'ed once that is integrated. 
>> 
>> There are two optimizations mixed up here. One in `MethodTypeDesc.ofDescriptor`:
>> 
>> Name                                                             (descString) Cnt     Base     Error      Test   Error  Unit  Change
>> MethodTypeDescFactories.ofDescriptor  (Ljava/lang/Object;Ljava/lang/String;)I   6  138,371 ?   0,767   136,939 ? 1,126 ns/op   1,01x (p = 0,000*)
>> MethodTypeDescFactories.ofDescriptor                                      ()V   6   10,528 ?   2,495     4,110 ? 0,047 ns/op   2,56x (p = 0,000*)
>> MethodTypeDescFactories.ofDescriptor ([IJLjava/lang/String;Z)Ljava/util/List;   6  209,390 ?   4,583   196,175 ? 3,211 ns/op   1,07x (p = 0,000*)
>> MethodTypeDescFactories.ofDescriptor                    ()[Ljava/lang/String;   6   36,039 ?   8,684    20,794 ? 1,110 ns/op   1,73x (p = 0,000*)
>> MethodTypeDescFactories.ofDescriptor                                 (..IIJ)V   6  279,139 ?   6,248   187,934 ? 0,857 ns/op   1,49x (p = 0,000*)
>> MethodTypeDescFactories.ofDescriptor                 (.....................).   6 2174,387 ? 132,879  1150,652 ? 3,158 ns/op   1,89x (p = 0,000*)
>>   * = significant
>> 
>> 
>> The other in `ClassDesc::nested`, where to get rid of a simple static method in `ConstantUtils` I ended up speeding up and simplifying the public factory method:
>> 
>> Name                                      Cnt    Base     Error    Test   Error  Unit  Change
>> ClassDescFactories.ReferenceOnly.ofNested   6 209,853 ? 132,525  22,017 ? 0,573 ns/op   9,53x (p = 0,000*)
>>   * = significant
>> 
>> 
>> The optimizations could be split out and PRd independently, but I think they are simple enough to include in this refactoring.
>
> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use sb.repeat, consolidate

src/java.base/share/classes/java/lang/constant/ClassDesc.java line 341:

> 339:         String desc = descriptorString();
> 340:         int index = desc.lastIndexOf('/');
> 341:         return (index == -1) ? "" : internalToBinary(desc.substring(1, index - 1));

Here it cuts the package name, for example `ConstantDescs.CD_Integer.packageName()` returns `java.lan`

Suggestion:

        return (index == -1) ? "" : internalToBinary(desc.substring(1, index));

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19105#discussion_r1601328026

From mcimadamore at openjdk.org  Wed May 15 09:59:05 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 15 May 2024 09:59:05 GMT
Subject: RFR: 8331671: Implement JEP 472: Prepare to Restrict the Use of
 JNI [v4]
In-Reply-To: <FaT2ocY-kpnuV6QHTbSp0JZSDqPSLOK9TJaNxJ4HJhE=.22667c74-0cc5-44e1-8ad8-e48ec65dce29@github.com>
References: <CZGbki5iFdCGPPagE-ya-_L8Nkgf7OunywApOsxC548=.2cee82fa-a5d2-4165-b012-30982a85030a@github.com>
 <sxwnadwC7gqIP9jLa6QyaV-wSYTH0FwuJf3HA-hfW6g=.292d839e-1480-43b4-9949-2dd7074f4cbe@github.com>
 <FaT2ocY-kpnuV6QHTbSp0JZSDqPSLOK9TJaNxJ4HJhE=.22667c74-0cc5-44e1-8ad8-e48ec65dce29@github.com>
Message-ID: <_MDZPWLFa7qcrmsqMsXDJx6Y5lqfI3E4d6Z6-VKv79g=.ad216d38-b066-47d2-bfcd-31a64052015d@github.com>

On Wed, 15 May 2024 07:55:27 GMT, ExE Boss <duke at openjdk.org> wrote:

> Note that this line is still not entirely correct, as for code like:

You are correct - the message is however consistent with what written in JEP 472. I'll discuss with @pron

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19213#discussion_r1601335120

From asotona at openjdk.org  Wed May 15 10:09:19 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Wed, 15 May 2024 10:09:19 GMT
Subject: RFR: 8320396: Class-File API ClassModel::verify should include
 checks from hotspot/share/classfile/classFileParser.cpp [v6]
In-Reply-To: <R9qzyd6zhRtXJzrslNATmgRZ3jIEA8XfYRh6kNLd-O8=.6be73dbb-58e8-4619-8a89-3f90b14649ed@github.com>
References: <0a66asWcJ4_zBrjmReA18BZmsovN1ZeJRRSAPZDMZmo=.5bada03f-d88d-46cd-962d-c1e42c3048c1@github.com>
 <HCwLBI-iyD3eCNWhKURiBboVhDwlpyBxPUL3Mur7UJc=.09225151-1960-4e45-80f9-977006b18a3d@github.com>
 <R9qzyd6zhRtXJzrslNATmgRZ3jIEA8XfYRh6kNLd-O8=.6be73dbb-58e8-4619-8a89-3f90b14649ed@github.com>
Message-ID: <MODM_RKe7EfoE2pr8IZYuYbnVeLU6nfOjB0FVEJTSVA=.c3f122c3-eac8-4996-8cfd-fb5c83cfe584@github.com>

On Wed, 15 May 2024 09:43:04 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   applied the suggested changes
>
> src/java.base/share/classes/jdk/internal/classfile/impl/verifier/ParserVerifier.java line 205:
> 
>> 203:     private void verifyAttribute(AttributedElement ae, Attribute<?> a, List<VerifyError> errors) {
>> 204:         int size = -1;
>> 205:         switch (a) {
> 
> Maybe use a switch expression to set `size` where `default` yields -1?

For better readability I've recently turned it from switch expression (yielding values pre-calculated in temporary locals) into explicit assignments to the `size` variable.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16809#discussion_r1601349377

From mcimadamore at openjdk.org  Wed May 15 10:21:13 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 15 May 2024 10:21:13 GMT
Subject: RFR: 8331670: Deprecate the Memory-Access Methods in
 sun.misc.Unsafe for Removal
In-Reply-To: <9FyO4QpCtH2CNkUEE78_Jjd9xs3bv3WJo16jyowHOvY=.e7131b91-37bb-4624-a60e-72a427a24c92@github.com>
References: <9FyO4QpCtH2CNkUEE78_Jjd9xs3bv3WJo16jyowHOvY=.e7131b91-37bb-4624-a60e-72a427a24c92@github.com>
Message-ID: <541F_cSF64RGRc_OmbcCufmAK_xPZdOSFlwx1ePbgyk=.11db8c10-a778-49be-9cd3-df30c2797ae0@github.com>

On Fri, 10 May 2024 10:06:55 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> This is the implementation changes for JEP 471.
> 
> The methods in sun.misc.Unsafe for on-heap and off-heap access are deprecated for removal. This means a removal warning at compile time. No methods have been removed. A deprecated message is added to each of the methods but unlikely to be seen as the JDK does not generate or publish the API docs for this class.
> 
> A new command line option --sun-misc-unsafe-memory-access=$value is introduced to allow or deny access to these methods. The default proposed for JDK 23 is "allow" so no change in behavior compared to JDK 22 or previous releases.
> 
> A new test is added to test the command line option settings. The existing micros for FFM that use Unsafe are updated to suppress the removal warning at compile time. A new micro is introduced with a small sample of methods to ensure the changes doesn't cause any perf regressions.
> 
> For now, the changes include the update to the man page for the "java" command. It might be that this has to be separated out so that it goes with other updates in the release.

src/jdk.unsupported/share/classes/sun/misc/Unsafe.java line 1764:

> 1762:     }
> 1763:     // set to true by first usage of memory-access method
> 1764:     private static @Stable boolean memoryAccessWarned;

Very nice code. The fact that you only need to report first use (and not first use per module, like in FFM) simplify things a bit (and, most importantly, avoids the need to make all unsafe methods caller sensitive!).

src/jdk.unsupported/share/classes/sun/misc/Unsafe.java line 1869:

> 1867:                     default -> {
> 1868:                         // emit warning
> 1869:                         log("--sun-misc-unsafe-memory-access ignored, value '" + value +

The FFM code throws if an unknown value is passed. Here we log. Should we try to be more consistent?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19174#discussion_r1601362348
PR Review Comment: https://git.openjdk.org/jdk/pull/19174#discussion_r1601364811

From mcimadamore at openjdk.org  Wed May 15 10:27:03 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 15 May 2024 10:27:03 GMT
Subject: RFR: 8331670: Deprecate the Memory-Access Methods in
 sun.misc.Unsafe for Removal
In-Reply-To: <9FyO4QpCtH2CNkUEE78_Jjd9xs3bv3WJo16jyowHOvY=.e7131b91-37bb-4624-a60e-72a427a24c92@github.com>
References: <9FyO4QpCtH2CNkUEE78_Jjd9xs3bv3WJo16jyowHOvY=.e7131b91-37bb-4624-a60e-72a427a24c92@github.com>
Message-ID: <-mPdzltEqxQ8lLBaLgRE7MlGmXe6owd1eYSOOJ4OP_U=.16eddcfd-6d70-438a-9bae-467162514348@github.com>

On Fri, 10 May 2024 10:06:55 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> This is the implementation changes for JEP 471.
> 
> The methods in sun.misc.Unsafe for on-heap and off-heap access are deprecated for removal. This means a removal warning at compile time. No methods have been removed. A deprecated message is added to each of the methods but unlikely to be seen as the JDK does not generate or publish the API docs for this class.
> 
> A new command line option --sun-misc-unsafe-memory-access=$value is introduced to allow or deny access to these methods. The default proposed for JDK 23 is "allow" so no change in behavior compared to JDK 22 or previous releases.
> 
> A new test is added to test the command line option settings. The existing micros for FFM that use Unsafe are updated to suppress the removal warning at compile time. A new micro is introduced with a small sample of methods to ensure the changes doesn't cause any perf regressions.
> 
> For now, the changes include the update to the man page for the "java" command. It might be that this has to be separated out so that it goes with other updates in the release.

Looks good. I've left some optional comments.

test/micro/org/openjdk/bench/java/lang/foreign/AllocFromTest.java line 167:

> 165: 
> 166:         @Override
> 167:         @SuppressWarnings("removal")

I believe we already disable a bunch of warnings from the command line when compiling these benchmarks. Perhaps we can just tweak the build script in a similar way and avoid the changes to the sources? E.g.


DISABLED_WARNINGS := restricted this-escape processing rawtypes cast \


Should we add `removal` there?

-------------

Marked as reviewed by mcimadamore (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19174#pullrequestreview-2057562462
PR Review Comment: https://git.openjdk.org/jdk/pull/19174#discussion_r1601368794

From clanger at openjdk.org  Wed May 15 10:27:03 2024
From: clanger at openjdk.org (Christoph Langer)
Date: Wed, 15 May 2024 10:27:03 GMT
Subject: RFR: 8329653: JLILaunchTest fails on AIX after JDK-8329131 [v3]
In-Reply-To: <D3ZEVmfJIpjMyN7u9tLewNo0N5xuIQWGeFiBgnvdxsM=.1859ec49-d2ef-4c45-8008-24f48313d231@github.com>
References: <y9wItIb8Yr_ZrHfN_kV5lDCp-d-VtYam3MuHX1OxurU=.ce3378d2-90b3-4396-8951-4651439e4f90@github.com>
 <D3ZEVmfJIpjMyN7u9tLewNo0N5xuIQWGeFiBgnvdxsM=.1859ec49-d2ef-4c45-8008-24f48313d231@github.com>
Message-ID: <P5FqaoZl5WwgLnu1quRDRSxJjBO5JBN-r9lTsvbaDho=.e973d98f-89cd-4e16-98bc-5fa6b3fca6a8@github.com>

On Tue, 7 May 2024 08:08:05 GMT, Joachim Kern <jkern at openjdk.org> wrote:

>> Since ~ end of March, after [JDK-8329131](https://bugs.openjdk.org/browse/JDK-8329131), tools/launcher/JliLaunchTest.java fails on AIX. Failure is :
>> 
>>  stdout: [];
>>  stderr: [Error: could not find libjava.so
>> Error: Could not find Java SE Runtime Environment.
>> ]
>>  exitValue = 2
>> 
>> java.lang.RuntimeException: Expected to get exit value of [0], exit value is: [2]
>> at jdk.test.lib.process.OutputAnalyzer.shouldHaveExitValue(OutputAnalyzer.java:521)
>> at JliLaunchTest.main(JliLaunchTest.java:58)
>> at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
>> at java.base/java.lang.reflect.Method.invoke(Method.java:580)
>> at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:333)
>> at java.base/java.lang.Thread.run(Thread.java:1575)
>> 
>> Maybe we need to do further adjustments to BUILD_JDK_JTREG_EXECUTABLES_LIBS_exeJliLaunchTest / BUILD_JDK_JTREG_EXECUTABLES_LDFLAGS_exeJliLaunchTest on AIX ?
>> Or somehow adjust the coding that attempts to find parts of "JRE" (libjava.so) ? The libjli.so is gone on AIX after [JDK-8329131](https://bugs.openjdk.org/browse/JDK-8329131), and with this also the image discovery based on GetApplicationHomeFromDll which uses libjli.so .
>> 
>> Without libjli.so we have to analyze the LD-LIBRARY_PATH / LIBPATH envvar. There is no other methos available on AIX, because it lacks the $ORIGIN feature of the rpath.
>
> Joachim Kern has updated the pull request incrementally with one additional commit since the last revision:
> 
>   cosmetic changes

Marked as reviewed by clanger (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/19000#pullrequestreview-2057562812

From redestad at openjdk.org  Wed May 15 10:35:37 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Wed, 15 May 2024 10:35:37 GMT
Subject: RFR: 8331724: Refactor j.l.constant implementation to internal
 package [v11]
In-Reply-To: <_GPUF9d1E6eBKRxP6bEEqA3LSKRJe2GwCRTfVYbDwFU=.cb482785-e7c4-45f7-bd3a-cd32d466a2cb@github.com>
References: <_GPUF9d1E6eBKRxP6bEEqA3LSKRJe2GwCRTfVYbDwFU=.cb482785-e7c4-45f7-bd3a-cd32d466a2cb@github.com>
Message-ID: <76a-jrPzqVYjIhqsYPFrCMHCHFO0V7BRZe-eckVC4WQ=.b15cb714-af14-45a6-8805-ce0e6eedcf4e@github.com>

> This PR suggests refactoring the implementation classes of java.lang.constant into a new package jdk.internal.constant to enable sharing some trusted static factory methods with users elsewhere in java.base, such as java.lang.invoke and java.lang.classfile. The refactoring also adds some "trusted" methods for use when input is pre-validated, and makes use of them where applicable in the current implementation. There are more changes in the pipeline which will be folded into #17108 or PR'ed once that is integrated. 
> 
> There are two optimizations mixed up here. One in `MethodTypeDesc.ofDescriptor`:
> 
> Name                                                             (descString) Cnt     Base     Error      Test   Error  Unit  Change
> MethodTypeDescFactories.ofDescriptor  (Ljava/lang/Object;Ljava/lang/String;)I   6  138,371 ?   0,767   136,939 ? 1,126 ns/op   1,01x (p = 0,000*)
> MethodTypeDescFactories.ofDescriptor                                      ()V   6   10,528 ?   2,495     4,110 ? 0,047 ns/op   2,56x (p = 0,000*)
> MethodTypeDescFactories.ofDescriptor ([IJLjava/lang/String;Z)Ljava/util/List;   6  209,390 ?   4,583   196,175 ? 3,211 ns/op   1,07x (p = 0,000*)
> MethodTypeDescFactories.ofDescriptor                    ()[Ljava/lang/String;   6   36,039 ?   8,684    20,794 ? 1,110 ns/op   1,73x (p = 0,000*)
> MethodTypeDescFactories.ofDescriptor                                 (..IIJ)V   6  279,139 ?   6,248   187,934 ? 0,857 ns/op   1,49x (p = 0,000*)
> MethodTypeDescFactories.ofDescriptor                 (.....................).   6 2174,387 ? 132,879  1150,652 ? 3,158 ns/op   1,89x (p = 0,000*)
>   * = significant
> 
> 
> The other in `ClassDesc::nested`, where to get rid of a simple static method in `ConstantUtils` I ended up speeding up and simplifying the public factory method:
> 
> Name                                      Cnt    Base     Error    Test   Error  Unit  Change
> ClassDescFactories.ReferenceOnly.ofNested   6 209,853 ? 132,525  22,017 ? 0,573 ns/op   9,53x (p = 0,000*)
>   * = significant
> 
> 
> The optimizations could be split out and PRd independently, but I think they are simple enough to include in this refactoring.

Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:

  Update src/java.base/share/classes/java/lang/constant/ClassDesc.java
  
  Co-authored-by: Adam Sotona <10807609+asotona at users.noreply.github.com>

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19105/files
  - new: https://git.openjdk.org/jdk/pull/19105/files/b0aca160..4e78b1b1

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19105&range=10
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19105&range=09-10

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/19105.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19105/head:pull/19105

PR: https://git.openjdk.org/jdk/pull/19105

From redestad at openjdk.org  Wed May 15 10:35:37 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Wed, 15 May 2024 10:35:37 GMT
Subject: RFR: 8331724: Refactor j.l.constant implementation to internal
 package [v10]
In-Reply-To: <h8CYXclAa5KmODobs7HUTPuFOHkeGjFFyAvUTIohkEs=.c306cbf6-5e4e-47ac-8f15-282cf69cfd06@github.com>
References: <_GPUF9d1E6eBKRxP6bEEqA3LSKRJe2GwCRTfVYbDwFU=.cb482785-e7c4-45f7-bd3a-cd32d466a2cb@github.com>
 <y_5pS2j4Hp_umMsdQ4CSLMlf9zmDfx4w4iXh61M9C4c=.c66691f0-659b-41ef-94e9-e0749d932cf4@github.com>
 <h8CYXclAa5KmODobs7HUTPuFOHkeGjFFyAvUTIohkEs=.c306cbf6-5e4e-47ac-8f15-282cf69cfd06@github.com>
Message-ID: <0By5HTXEUY5jBG9r89LSlU70koZ4qUhmKOfyXqAo0fs=.4c466311-5da8-4a81-af3a-0023984889cf@github.com>

On Wed, 15 May 2024 09:51:13 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Use sb.repeat, consolidate
>
> src/java.base/share/classes/java/lang/constant/ClassDesc.java line 341:
> 
>> 339:         String desc = descriptorString();
>> 340:         int index = desc.lastIndexOf('/');
>> 341:         return (index == -1) ? "" : internalToBinary(desc.substring(1, index - 1));
> 
> Here it cuts the package name, for example `ConstantDescs.CD_Integer.packageName()` returns `java.lan`
> 
> Suggestion:
> 
>         return (index == -1) ? "" : internalToBinary(desc.substring(1, index));

Thanks! Verified there were tests covering this.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19105#discussion_r1601383209

From mcimadamore at openjdk.org  Wed May 15 10:37:24 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 15 May 2024 10:37:24 GMT
Subject: RFR: 8331671: Implement JEP 472: Prepare to Restrict the Use of
 JNI [v3]
In-Reply-To: <-gTDhrDCjlq9pEoBxG4Qneo9dEf7ErWmvnyOZKGx4mM=.8772d4dd-aa5e-412c-8131-75687cddad5b@github.com>
References: <CZGbki5iFdCGPPagE-ya-_L8Nkgf7OunywApOsxC548=.2cee82fa-a5d2-4165-b012-30982a85030a@github.com>
 <jUWaDowOZsL42UtliIOoCe7WfowooCW1zvcVKyFnL7g=.4b20b555-3651-4fca-9ede-1652dec95e9c@github.com>
 <l7dLX25UBFdbxrTmukfFGZjEXu3hZVEnWkDLIkoAu90=.c8a7fbd7-4e37-46d5-b950-211189279ca2@github.com>
 <fG9oopqgoIWQCaJcq3gE1N6p4QRdrXuUGLr9G_cZiuY=.fa484873-046f-4d18-a02a-18f17d42764a@github.com>
 <-gTDhrDCjlq9pEoBxG4Qneo9dEf7ErWmvnyOZKGx4mM=.8772d4dd-aa5e-412c-8131-75687cddad5b@github.com>
Message-ID: <3w0X9MH3A4P3lX6oIuONx-daTSVe3kWm8z2YWDbHNvg=.9a19ac2b-f46b-4d64-9cdd-f3e70dc3da20@github.com>

On Wed, 15 May 2024 06:15:35 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> So my recollection/understanding is that we use this mechanism to convert module-related `--` flags passed to the VM into system properties that the Java code can then read, but we set them up such that you are not allowed to specify them directly via `-D`. Is the question here whether this new property should be in the `jdk.module` namespace?
>
> That's my recollection too. The usage here isn' related to modules which makes me wonder if this function should be renamed (not by this PR of course) of if we should be using PropertyList_unique_add (with AddProperty, WriteableProperty, InternalProperty) instead. There will be further GNU style options coming that will likely need to map to an internal system property in the same way.

I don't fully agree that this option is not module related (which is why I gave it that name). The very definition of illegal native access is related to native access occurring from a module that is outside a specific set. So I think it's 50/50 as to whether this option is module-related or not. Of course I can fix the code if there's something clearly better.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19213#discussion_r1601386336

From mcimadamore at openjdk.org  Wed May 15 10:40:34 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 15 May 2024 10:40:34 GMT
Subject: RFR: 8331671: Implement JEP 472: Prepare to Restrict the Use of
 JNI [v5]
In-Reply-To: <CZGbki5iFdCGPPagE-ya-_L8Nkgf7OunywApOsxC548=.2cee82fa-a5d2-4165-b012-30982a85030a@github.com>
References: <CZGbki5iFdCGPPagE-ya-_L8Nkgf7OunywApOsxC548=.2cee82fa-a5d2-4165-b012-30982a85030a@github.com>
Message-ID: <gO_v02GJYOMjjlq_93fIQfki_iuSNwVv1tiNmp4Qe4o=.47df90f1-d348-4f26-ab88-7a80af6a3d91@github.com>

> This PR implements [JEP 472](https://openjdk.org/jeps/472), by restricting the use of JNI in the following ways:
> 
> * `System::load` and `System::loadLibrary` are now restricted methods
> * `Runtime::load` and `Runtime::loadLibrary` are now restricted methods
> * binding a JNI `native` method declaration to a native implementation is now considered a restricted operation
> 
> This PR slightly changes the way in which the JDK deals with restricted methods, even for FFM API calls. In Java 22, the single `--enable-native-access` was used both to specify a set of modules for which native access should be allowed *and* to specify whether illegal native access (that is, native access occurring from a module not specified by `--enable-native-access`) should be treated as an error or a warning. More specifically, an error is only issued if the `--enable-native-access flag` is used at least once.
> 
> Here, a new flag is introduced, namely `illegal-native-access=allow/warn/deny`, which is used to specify what should happen when access to a restricted method and/or functionality is found outside the set of modules specified with `--enable-native-access`. The default policy is `warn`, but users can select `allow` to suppress the warnings, or `deny` to cause `IllegalCallerException` to be thrown. This aligns the treatment of restricted methods with other mechanisms, such as `--illegal-access` and the more recent `--sun-misc-unsafe-memory-access`.
> 
> Some changes were required in the package-info javadoc for `java.lang.foreign`, to reflect the changes in the command line flags described above.

Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:

  Refine warning text for JNI method binding

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19213/files
  - new: https://git.openjdk.org/jdk/pull/19213/files/0d21bf99..daf729f4

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19213&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19213&range=03-04

  Stats: 4 lines in 2 files changed: 0 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/19213.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19213/head:pull/19213

PR: https://git.openjdk.org/jdk/pull/19213

From alanb at openjdk.org  Wed May 15 10:47:13 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 15 May 2024 10:47:13 GMT
Subject: RFR: 8330465: Stable Values and Collections (Internal) [v4]
In-Reply-To: <WTvK6htLFImBbqJaegAYhe66v-7Ukg1Rbr_SBPAAUw4=.0339bae0-9215-4786-9847-b54428d6e1fa@github.com>
References: <-KSimQo5kkmCzzMShqGe5QZ9yCSzpWL98gN13v4wP0k=.11dd8d06-18a6-4577-8342-66632cea0b6e@github.com>
 <Aoeah2Qx-yd_WnZV4YKBJrU-N_Ht2U2FBymgFK5B_jg=.caf754c8-4f71-4dda-b093-7f3ef050d1c0@github.com>
 <WTvK6htLFImBbqJaegAYhe66v-7Ukg1Rbr_SBPAAUw4=.0339bae0-9215-4786-9847-b54428d6e1fa@github.com>
Message-ID: <lashsCFY4UdB4ssgwteonzsOO8uqHAlEehoRy1iI1p8=.d4fca59b-1733-497f-9ff3-d134843a4d9c@github.com>

On Wed, 15 May 2024 08:49:46 GMT, ExE Boss <duke at openjdk.org> wrote:

> Maybe?export this?interface to?`jdk.unsupported`?

I don't we should do that. In general, we need jdk.unsupported to go away in the long term. Also integrity of the platform depends on java.base being very stingy and not exporting internal packages to other modules.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18794#discussion_r1601399452

From asotona at openjdk.org  Wed May 15 10:47:23 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Wed, 15 May 2024 10:47:23 GMT
Subject: RFR: 8320396: Class-File API ClassModel::verify should include
 checks from hotspot/share/classfile/classFileParser.cpp [v7]
In-Reply-To: <0a66asWcJ4_zBrjmReA18BZmsovN1ZeJRRSAPZDMZmo=.5bada03f-d88d-46cd-962d-c1e42c3048c1@github.com>
References: <0a66asWcJ4_zBrjmReA18BZmsovN1ZeJRRSAPZDMZmo=.5bada03f-d88d-46cd-962d-c1e42c3048c1@github.com>
Message-ID: <djFxpWMkSwFyS2AOLnX9Jx4sG0_RqxEeA-qBtWjvO9U=.55c71ff2-0597-488a-83f0-f47fe96e79bf@github.com>

> ClassFile API `jdk.internal.classfile.verifier.VerifierImpl` performed only bytecode-level class verification.
> This patch adds `jdk.internal.classfile.verifier.ParserVerifier` with additional class checks inspired by `hotspot/share/classfile/classFileParser.cpp`.
> 
> Also new `VerifierSelfTest::testParserVerifier` has been added.
> 
> Please review.
> 
> Thanks,
> Adam

Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:

  applied the suggested changes

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/16809/files
  - new: https://git.openjdk.org/jdk/pull/16809/files/9257b7ea..6f12b3bd

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16809&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16809&range=05-06

  Stats: 92 lines in 1 file changed: 29 ins; 29 del; 34 mod
  Patch: https://git.openjdk.org/jdk/pull/16809.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16809/head:pull/16809

PR: https://git.openjdk.org/jdk/pull/16809

From asotona at openjdk.org  Wed May 15 10:47:24 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Wed, 15 May 2024 10:47:24 GMT
Subject: RFR: 8320396: Class-File API ClassModel::verify should include
 checks from hotspot/share/classfile/classFileParser.cpp [v6]
In-Reply-To: <MODM_RKe7EfoE2pr8IZYuYbnVeLU6nfOjB0FVEJTSVA=.c3f122c3-eac8-4996-8cfd-fb5c83cfe584@github.com>
References: <0a66asWcJ4_zBrjmReA18BZmsovN1ZeJRRSAPZDMZmo=.5bada03f-d88d-46cd-962d-c1e42c3048c1@github.com>
 <HCwLBI-iyD3eCNWhKURiBboVhDwlpyBxPUL3Mur7UJc=.09225151-1960-4e45-80f9-977006b18a3d@github.com>
 <R9qzyd6zhRtXJzrslNATmgRZ3jIEA8XfYRh6kNLd-O8=.6be73dbb-58e8-4619-8a89-3f90b14649ed@github.com>
 <MODM_RKe7EfoE2pr8IZYuYbnVeLU6nfOjB0FVEJTSVA=.c3f122c3-eac8-4996-8cfd-fb5c83cfe584@github.com>
Message-ID: <jt1wJa4fjGVhLw_xkGXw-p_AVuXIIrbTD8oLmmCccAs=.37c9114b-29f3-436a-ae9a-8a582f6004cb@github.com>

On Wed, 15 May 2024 10:06:42 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/classfile/impl/verifier/ParserVerifier.java line 205:
>> 
>>> 203:     private void verifyAttribute(AttributedElement ae, Attribute<?> a, List<VerifyError> errors) {
>>> 204:         int size = -1;
>>> 205:         switch (a) {
>> 
>> Maybe use a switch expression to set `size` where `default` yields -1?
>
> For better readability I've recently turned it from switch expression (yielding values pre-calculated in temporary locals) into explicit assignments to the `size` variable.

I've turned it back to switch expression and compacted it a bit more.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16809#discussion_r1601399982

From asotona at openjdk.org  Wed May 15 10:47:24 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Wed, 15 May 2024 10:47:24 GMT
Subject: RFR: 8320396: Class-File API ClassModel::verify should include
 checks from hotspot/share/classfile/classFileParser.cpp [v6]
In-Reply-To: <R9qzyd6zhRtXJzrslNATmgRZ3jIEA8XfYRh6kNLd-O8=.6be73dbb-58e8-4619-8a89-3f90b14649ed@github.com>
References: <0a66asWcJ4_zBrjmReA18BZmsovN1ZeJRRSAPZDMZmo=.5bada03f-d88d-46cd-962d-c1e42c3048c1@github.com>
 <HCwLBI-iyD3eCNWhKURiBboVhDwlpyBxPUL3Mur7UJc=.09225151-1960-4e45-80f9-977006b18a3d@github.com>
 <R9qzyd6zhRtXJzrslNATmgRZ3jIEA8XfYRh6kNLd-O8=.6be73dbb-58e8-4619-8a89-3f90b14649ed@github.com>
Message-ID: <2DUIvyb00Bqzef8PZj9LGX21mV-3YgY3dH2lcC-pqZM=.3d242020-d941-4262-9cba-4192d574f558@github.com>

On Wed, 15 May 2024 09:45:24 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   applied the suggested changes
>
> src/java.base/share/classes/jdk/internal/classfile/impl/verifier/ParserVerifier.java line 306:
> 
>> 304:                 size = 1;
>> 305:                 for (var ans : aa.parameterAnnotations()) {
>> 306:                     size += annotationsSize(ans);
> 
> Shouldn't we call the new method here (passing `parameterAnnotations`) ?

Yes, I've compacted it a bit more, thanks.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16809#discussion_r1601399335

From redestad at openjdk.org  Wed May 15 10:55:31 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Wed, 15 May 2024 10:55:31 GMT
Subject: RFR: 8331724: Refactor j.l.constant implementation to internal
 package [v12]
In-Reply-To: <_GPUF9d1E6eBKRxP6bEEqA3LSKRJe2GwCRTfVYbDwFU=.cb482785-e7c4-45f7-bd3a-cd32d466a2cb@github.com>
References: <_GPUF9d1E6eBKRxP6bEEqA3LSKRJe2GwCRTfVYbDwFU=.cb482785-e7c4-45f7-bd3a-cd32d466a2cb@github.com>
Message-ID: <SfNCjvOP2cSPkJaG-4F0i7qQLAbEF2snLQpR2oa8fwo=.0837269e-34cd-4e89-a427-043b96c77402@github.com>

> This PR suggests refactoring the implementation classes of java.lang.constant into a new package jdk.internal.constant to enable sharing some trusted static factory methods with users elsewhere in java.base, such as java.lang.invoke and java.lang.classfile. The refactoring also adds some "trusted" methods for use when input is pre-validated, and makes use of them where applicable in the current implementation. There are more changes in the pipeline which will be folded into #17108 or PR'ed once that is integrated. 
> 
> There are two optimizations mixed up here. One in `MethodTypeDesc.ofDescriptor`:
> 
> Name                                                             (descString) Cnt     Base     Error      Test   Error  Unit  Change
> MethodTypeDescFactories.ofDescriptor  (Ljava/lang/Object;Ljava/lang/String;)I   6  138,371 ?   0,767   136,939 ? 1,126 ns/op   1,01x (p = 0,000*)
> MethodTypeDescFactories.ofDescriptor                                      ()V   6   10,528 ?   2,495     4,110 ? 0,047 ns/op   2,56x (p = 0,000*)
> MethodTypeDescFactories.ofDescriptor ([IJLjava/lang/String;Z)Ljava/util/List;   6  209,390 ?   4,583   196,175 ? 3,211 ns/op   1,07x (p = 0,000*)
> MethodTypeDescFactories.ofDescriptor                    ()[Ljava/lang/String;   6   36,039 ?   8,684    20,794 ? 1,110 ns/op   1,73x (p = 0,000*)
> MethodTypeDescFactories.ofDescriptor                                 (..IIJ)V   6  279,139 ?   6,248   187,934 ? 0,857 ns/op   1,49x (p = 0,000*)
> MethodTypeDescFactories.ofDescriptor                 (.....................).   6 2174,387 ? 132,879  1150,652 ? 3,158 ns/op   1,89x (p = 0,000*)
>   * = significant
> 
> 
> The other in `ClassDesc::nested`, where to get rid of a simple static method in `ConstantUtils` I ended up speeding up and simplifying the public factory method:
> 
> Name                                      Cnt    Base     Error    Test   Error  Unit  Change
> ClassDescFactories.ReferenceOnly.ofNested   6 209,853 ? 132,525  22,017 ? 0,573 ns/op   9,53x (p = 0,000*)
>   * = significant
> 
> 
> The optimizations could be split out and PRd independently, but I think they are simple enough to include in this refactoring.

Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:

  Can't call arrayType() from arrayType(int) due different exception types

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19105/files
  - new: https://git.openjdk.org/jdk/pull/19105/files/4e78b1b1..2a1b9ac9

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19105&range=11
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19105&range=10-11

  Stats: 3 lines in 1 file changed: 0 ins; 3 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/19105.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19105/head:pull/19105

PR: https://git.openjdk.org/jdk/pull/19105

From alanb at openjdk.org  Wed May 15 11:05:14 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 15 May 2024 11:05:14 GMT
Subject: RFR: 8331671: Implement JEP 472: Prepare to Restrict the Use of
 JNI [v3]
In-Reply-To: <3w0X9MH3A4P3lX6oIuONx-daTSVe3kWm8z2YWDbHNvg=.9a19ac2b-f46b-4d64-9cdd-f3e70dc3da20@github.com>
References: <CZGbki5iFdCGPPagE-ya-_L8Nkgf7OunywApOsxC548=.2cee82fa-a5d2-4165-b012-30982a85030a@github.com>
 <jUWaDowOZsL42UtliIOoCe7WfowooCW1zvcVKyFnL7g=.4b20b555-3651-4fca-9ede-1652dec95e9c@github.com>
 <l7dLX25UBFdbxrTmukfFGZjEXu3hZVEnWkDLIkoAu90=.c8a7fbd7-4e37-46d5-b950-211189279ca2@github.com>
 <fG9oopqgoIWQCaJcq3gE1N6p4QRdrXuUGLr9G_cZiuY=.fa484873-046f-4d18-a02a-18f17d42764a@github.com>
 <-gTDhrDCjlq9pEoBxG4Qneo9dEf7ErWmvnyOZKGx4mM=.8772d4dd-aa5e-412c-8131-75687cddad5b@github.com>
 <3w0X9MH3A4P3lX6oIuONx-daTSVe3kWm8z2YWDbHNvg=.9a19ac2b-f46b-4d64-9cdd-f3e70dc3da20@github.com>
Message-ID: <DLv_q_jPw8OfE2JXGhq-Fk_y3HAET55Fl8as0LvO7zo=.ee2d56a3-aee4-45e7-8bc3-b8ef89778480@github.com>

On Wed, 15 May 2024 10:34:01 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> I don't fully agree that this option is not module related (which is why I gave it that name). The very definition of illegal native access is related to native access occurring from a module that is outside a specific set. So I think it's 50/50 as to whether this option is module-related or not. Of course I can fix the code if there's something clearly better.

It maps here to a jdk.module.* property so I suppose it's okay. The functions were introduced to create jdk.module.* properties where the values were a set module names or a module path. Maybe these functions should be renamed at some point (not here) as they are more widely useful now.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19213#discussion_r1601421535

From duke at openjdk.org  Wed May 15 11:11:09 2024
From: duke at openjdk.org (ExE Boss)
Date: Wed, 15 May 2024 11:11:09 GMT
Subject: RFR: 8331724: Refactor j.l.constant implementation to internal
 package [v10]
In-Reply-To: <y_5pS2j4Hp_umMsdQ4CSLMlf9zmDfx4w4iXh61M9C4c=.c66691f0-659b-41ef-94e9-e0749d932cf4@github.com>
References: <_GPUF9d1E6eBKRxP6bEEqA3LSKRJe2GwCRTfVYbDwFU=.cb482785-e7c4-45f7-bd3a-cd32d466a2cb@github.com>
 <y_5pS2j4Hp_umMsdQ4CSLMlf9zmDfx4w4iXh61M9C4c=.c66691f0-659b-41ef-94e9-e0749d932cf4@github.com>
Message-ID: <B_afAJAnY8YMALlqcCQo7HIJQJnFkf6MxXeAsX_rAvQ=.5a8b85b1-f09f-4c79-9576-62168369ec6c@github.com>

On Wed, 15 May 2024 07:20:37 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> This PR suggests refactoring the implementation classes of java.lang.constant into a new package jdk.internal.constant to enable sharing some trusted static factory methods with users elsewhere in java.base, such as java.lang.invoke and java.lang.classfile. The refactoring also adds some "trusted" methods for use when input is pre-validated, and makes use of them where applicable in the current implementation. There are more changes in the pipeline which will be folded into #17108 or PR'ed once that is integrated. 
>> 
>> There are two optimizations mixed up here. One in `MethodTypeDesc.ofDescriptor`:
>> 
>> Name                                                             (descString) Cnt     Base     Error      Test   Error  Unit  Change
>> MethodTypeDescFactories.ofDescriptor  (Ljava/lang/Object;Ljava/lang/String;)I   6  138,371 ?   0,767   136,939 ? 1,126 ns/op   1,01x (p = 0,000*)
>> MethodTypeDescFactories.ofDescriptor                                      ()V   6   10,528 ?   2,495     4,110 ? 0,047 ns/op   2,56x (p = 0,000*)
>> MethodTypeDescFactories.ofDescriptor ([IJLjava/lang/String;Z)Ljava/util/List;   6  209,390 ?   4,583   196,175 ? 3,211 ns/op   1,07x (p = 0,000*)
>> MethodTypeDescFactories.ofDescriptor                    ()[Ljava/lang/String;   6   36,039 ?   8,684    20,794 ? 1,110 ns/op   1,73x (p = 0,000*)
>> MethodTypeDescFactories.ofDescriptor                                 (..IIJ)V   6  279,139 ?   6,248   187,934 ? 0,857 ns/op   1,49x (p = 0,000*)
>> MethodTypeDescFactories.ofDescriptor                 (.....................).   6 2174,387 ? 132,879  1150,652 ? 3,158 ns/op   1,89x (p = 0,000*)
>>   * = significant
>> 
>> 
>> The other in `ClassDesc::nested`, where to get rid of a simple static method in `ConstantUtils` I ended up speeding up and simplifying the public factory method:
>> 
>> Name                                      Cnt    Base     Error    Test   Error  Unit  Change
>> ClassDescFactories.ReferenceOnly.ofNested   6 209,853 ? 132,525  22,017 ? 0,573 ns/op   9,53x (p = 0,000*)
>>   * = significant
>> 
>> 
>> The optimizations could be split out and PRd independently, but I think they are simple enough to include in this refactoring.
>
> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use sb.repeat, consolidate

src/java.base/share/classes/java/lang/constant/ClassDesc.java line 190:

> 188:                     MAX_ARRAY_TYPE_DESC_DIMENSIONS + " dimensions");
> 189:         }
> 190:         String newDesc = new StringBuilder(desc.length() + 1).append('[').append(desc).toString();

This?could use?[`String?::concat?(String)`], which?uses the?same underlying code?path as?the?`invokedynamic`?based `String`?concatenation:
Suggestion:

        String newDesc = "[".concat(desc);


[`String?::concat?(String)`]: https://docs.oracle.com/en/java/javase/22/docs/api/java.base/java/lang/String.html#concat(java.lang.String)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19105#discussion_r1601423761

From duke at openjdk.org  Wed May 15 11:11:10 2024
From: duke at openjdk.org (ExE Boss)
Date: Wed, 15 May 2024 11:11:10 GMT
Subject: RFR: 8331724: Refactor j.l.constant implementation to internal
 package [v12]
In-Reply-To: <SfNCjvOP2cSPkJaG-4F0i7qQLAbEF2snLQpR2oa8fwo=.0837269e-34cd-4e89-a427-043b96c77402@github.com>
References: <_GPUF9d1E6eBKRxP6bEEqA3LSKRJe2GwCRTfVYbDwFU=.cb482785-e7c4-45f7-bd3a-cd32d466a2cb@github.com>
 <SfNCjvOP2cSPkJaG-4F0i7qQLAbEF2snLQpR2oa8fwo=.0837269e-34cd-4e89-a427-043b96c77402@github.com>
Message-ID: <142OCseYB0f9JpvnmMEinKHOpQk6ontTyOQ0cxUi2E8=.9ecc4e09-f302-4129-859a-a1600bc03296@github.com>

On Wed, 15 May 2024 10:55:31 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> This PR suggests refactoring the implementation classes of java.lang.constant into a new package jdk.internal.constant to enable sharing some trusted static factory methods with users elsewhere in java.base, such as java.lang.invoke and java.lang.classfile. The refactoring also adds some "trusted" methods for use when input is pre-validated, and makes use of them where applicable in the current implementation. There are more changes in the pipeline which will be folded into #17108 or PR'ed once that is integrated. 
>> 
>> There are two optimizations mixed up here. One in `MethodTypeDesc.ofDescriptor`:
>> 
>> Name                                                             (descString) Cnt     Base     Error      Test   Error  Unit  Change
>> MethodTypeDescFactories.ofDescriptor  (Ljava/lang/Object;Ljava/lang/String;)I   6  138,371 ?   0,767   136,939 ? 1,126 ns/op   1,01x (p = 0,000*)
>> MethodTypeDescFactories.ofDescriptor                                      ()V   6   10,528 ?   2,495     4,110 ? 0,047 ns/op   2,56x (p = 0,000*)
>> MethodTypeDescFactories.ofDescriptor ([IJLjava/lang/String;Z)Ljava/util/List;   6  209,390 ?   4,583   196,175 ? 3,211 ns/op   1,07x (p = 0,000*)
>> MethodTypeDescFactories.ofDescriptor                    ()[Ljava/lang/String;   6   36,039 ?   8,684    20,794 ? 1,110 ns/op   1,73x (p = 0,000*)
>> MethodTypeDescFactories.ofDescriptor                                 (..IIJ)V   6  279,139 ?   6,248   187,934 ? 0,857 ns/op   1,49x (p = 0,000*)
>> MethodTypeDescFactories.ofDescriptor                 (.....................).   6 2174,387 ? 132,879  1150,652 ? 3,158 ns/op   1,89x (p = 0,000*)
>>   * = significant
>> 
>> 
>> The other in `ClassDesc::nested`, where to get rid of a simple static method in `ConstantUtils` I ended up speeding up and simplifying the public factory method:
>> 
>> Name                                      Cnt    Base     Error    Test   Error  Unit  Change
>> ClassDescFactories.ReferenceOnly.ofNested   6 209,853 ? 132,525  22,017 ? 0,573 ns/op   9,53x (p = 0,000*)
>>   * = significant
>> 
>> 
>> The optimizations could be split out and PRd independently, but I think they are simple enough to include in this refactoring.
>
> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Can't call arrayType() from arrayType(int) due different exception types

src/java.base/share/classes/java/lang/constant/ClassDesc.java line 209:

> 207:      */
> 208:     default ClassDesc arrayType(int rank) {
> 209:         if (rank <= 1) {

Suggestion:

        if (rank <= 0) {

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19105#discussion_r1601429229

From redestad at openjdk.org  Wed May 15 11:17:42 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Wed, 15 May 2024 11:17:42 GMT
Subject: RFR: 8331724: Refactor j.l.constant implementation to internal
 package [v13]
In-Reply-To: <_GPUF9d1E6eBKRxP6bEEqA3LSKRJe2GwCRTfVYbDwFU=.cb482785-e7c4-45f7-bd3a-cd32d466a2cb@github.com>
References: <_GPUF9d1E6eBKRxP6bEEqA3LSKRJe2GwCRTfVYbDwFU=.cb482785-e7c4-45f7-bd3a-cd32d466a2cb@github.com>
Message-ID: <zuoNJZww8C8zmDH9ik0h6Vr9SvjxwKdgw8bp5pKcxD4=.f07a6409-9298-4690-a339-39d3ff001c02@github.com>

> This PR suggests refactoring the implementation classes of java.lang.constant into a new package jdk.internal.constant to enable sharing some trusted static factory methods with users elsewhere in java.base, such as java.lang.invoke and java.lang.classfile. The refactoring also adds some "trusted" methods for use when input is pre-validated, and makes use of them where applicable in the current implementation. There are more changes in the pipeline which will be folded into #17108 or PR'ed once that is integrated. 
> 
> There are two optimizations mixed up here. One in `MethodTypeDesc.ofDescriptor`:
> 
> Name                                                             (descString) Cnt     Base     Error      Test   Error  Unit  Change
> MethodTypeDescFactories.ofDescriptor  (Ljava/lang/Object;Ljava/lang/String;)I   6  138,371 ?   0,767   136,939 ? 1,126 ns/op   1,01x (p = 0,000*)
> MethodTypeDescFactories.ofDescriptor                                      ()V   6   10,528 ?   2,495     4,110 ? 0,047 ns/op   2,56x (p = 0,000*)
> MethodTypeDescFactories.ofDescriptor ([IJLjava/lang/String;Z)Ljava/util/List;   6  209,390 ?   4,583   196,175 ? 3,211 ns/op   1,07x (p = 0,000*)
> MethodTypeDescFactories.ofDescriptor                    ()[Ljava/lang/String;   6   36,039 ?   8,684    20,794 ? 1,110 ns/op   1,73x (p = 0,000*)
> MethodTypeDescFactories.ofDescriptor                                 (..IIJ)V   6  279,139 ?   6,248   187,934 ? 0,857 ns/op   1,49x (p = 0,000*)
> MethodTypeDescFactories.ofDescriptor                 (.....................).   6 2174,387 ? 132,879  1150,652 ? 3,158 ns/op   1,89x (p = 0,000*)
>   * = significant
> 
> 
> The other in `ClassDesc::nested`, where to get rid of a simple static method in `ConstantUtils` I ended up speeding up and simplifying the public factory method:
> 
> Name                                      Cnt    Base     Error    Test   Error  Unit  Change
> ClassDescFactories.ReferenceOnly.ofNested   6 209,853 ? 132,525  22,017 ? 0,573 ns/op   9,53x (p = 0,000*)
>   * = significant
> 
> 
> The optimizations could be split out and PRd independently, but I think they are simple enough to include in this refactoring.

Claes Redestad has updated the pull request incrementally with two additional commits since the last revision:

 - Update src/java.base/share/classes/java/lang/constant/ClassDesc.java
   
   Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com>
 - Update src/java.base/share/classes/java/lang/constant/ClassDesc.java
   
   Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com>

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19105/files
  - new: https://git.openjdk.org/jdk/pull/19105/files/2a1b9ac9..273bcecc

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19105&range=12
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19105&range=11-12

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/19105.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19105/head:pull/19105

PR: https://git.openjdk.org/jdk/pull/19105

From liach at openjdk.org  Wed May 15 11:31:03 2024
From: liach at openjdk.org (Chen Liang)
Date: Wed, 15 May 2024 11:31:03 GMT
Subject: RFR: 8331940: ClassFile API ArrayIndexOutOfBoundsException with
 certain class files [v2]
In-Reply-To: <1XmBInBynHASRbJqzNvfriDMuz5xQmczMv1nXsSWSYo=.a5146cc9-2d11-4514-bc47-83884276d253@github.com>
References: <wWNlHWtc5H1nl9YHXQHGJBdJt-uo3p89E8MeGsRjsKY=.10b28a54-3530-42dc-8b24-5a4da8b81f9a@github.com>
 <1XmBInBynHASRbJqzNvfriDMuz5xQmczMv1nXsSWSYo=.a5146cc9-2d11-4514-bc47-83884276d253@github.com>
Message-ID: <-36M9J6I04oiObejuyoCgo-LRlepObnsktCknIAFqXw=.929c02c7-80c2-48c8-94e8-cca6ac8adfbf@github.com>

On Wed, 15 May 2024 07:51:33 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> Class file with `LineNumberTable` attribute element pointing behind the bytecode array throws `ArrayIndexOutOfBoundsException`.
>> This patch performs the check and throws  expected `IllegalArgumentException` instead.
>> Relevant test is added.
>> 
>> Please review.
>> 
>> Thanks,
>> Adam
>
> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fixed exception message

Marked as reviewed by liach (Author).

-------------

PR Review: https://git.openjdk.org/jdk/pull/19230#pullrequestreview-2057703566

From duke at openjdk.org  Wed May 15 11:31:10 2024
From: duke at openjdk.org (ExE Boss)
Date: Wed, 15 May 2024 11:31:10 GMT
Subject: RFR: 8330465: Stable Values and Collections (Internal) [v4]
In-Reply-To: <lashsCFY4UdB4ssgwteonzsOO8uqHAlEehoRy1iI1p8=.d4fca59b-1733-497f-9ff3-d134843a4d9c@github.com>
References: <-KSimQo5kkmCzzMShqGe5QZ9yCSzpWL98gN13v4wP0k=.11dd8d06-18a6-4577-8342-66632cea0b6e@github.com>
 <Aoeah2Qx-yd_WnZV4YKBJrU-N_Ht2U2FBymgFK5B_jg=.caf754c8-4f71-4dda-b093-7f3ef050d1c0@github.com>
 <WTvK6htLFImBbqJaegAYhe66v-7Ukg1Rbr_SBPAAUw4=.0339bae0-9215-4786-9847-b54428d6e1fa@github.com>
 <lashsCFY4UdB4ssgwteonzsOO8uqHAlEehoRy1iI1p8=.d4fca59b-1733-497f-9ff3-d134843a4d9c@github.com>
Message-ID: <K90SVl2BCEkM_lc37eC9NPdtq5uMxse62LZ9xsxDbyI=.03ad5520-18ce-4c78-bc51-45aa496bc503@github.com>

On Wed, 15 May 2024 10:43:52 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/lang/stable/TrustedFieldType.java line 14:
>> 
>>> 12:  * operations.
>>> 13:  */
>>> 14: public sealed interface TrustedFieldType
>> 
>> Maybe?export this?interface to?`jdk.unsupported`?
>
>> Maybe?export this?interface to?`jdk.unsupported`?
> 
> I don't we should do that. In general, we need jdk.unsupported to go away in the long term. Also integrity of the platform depends on java.base being very stingy and not exporting internal packages to other modules.

Given that `TrustedFieldType` is?more?generic than?stable?values, it?could be?moved to?`jdk.internal.misc` or?`jdk.internal.reflect`, then?`jdk.unsupported` could?use?it without?exporting new?packages to?`jdk.unsupported`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18794#discussion_r1601455889

From liach at openjdk.org  Wed May 15 11:39:06 2024
From: liach at openjdk.org (Chen Liang)
Date: Wed, 15 May 2024 11:39:06 GMT
Subject: RFR: 8320396: Class-File API ClassModel::verify should include
 checks from hotspot/share/classfile/classFileParser.cpp [v7]
In-Reply-To: <djFxpWMkSwFyS2AOLnX9Jx4sG0_RqxEeA-qBtWjvO9U=.55c71ff2-0597-488a-83f0-f47fe96e79bf@github.com>
References: <0a66asWcJ4_zBrjmReA18BZmsovN1ZeJRRSAPZDMZmo=.5bada03f-d88d-46cd-962d-c1e42c3048c1@github.com>
 <djFxpWMkSwFyS2AOLnX9Jx4sG0_RqxEeA-qBtWjvO9U=.55c71ff2-0597-488a-83f0-f47fe96e79bf@github.com>
Message-ID: <_691j41TGzd_pv4q8ZqS_XPsbLIb_O-AVxOfPH8YY9A=.1107a250-7e32-42aa-ad1a-9a6fa8e6e3cc@github.com>

On Wed, 15 May 2024 10:47:23 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> ClassFile API `jdk.internal.classfile.verifier.VerifierImpl` performed only bytecode-level class verification.
>> This patch adds `jdk.internal.classfile.verifier.ParserVerifier` with additional class checks inspired by `hotspot/share/classfile/classFileParser.cpp`.
>> 
>> Also new `VerifierSelfTest::testParserVerifier` has been added.
>> 
>> Please review.
>> 
>> Thanks,
>> Adam
>
> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
> 
>   applied the suggested changes

src/java.base/share/classes/jdk/internal/classfile/impl/verifier/ParserVerifier.java line 308:

> 306:                 0;
> 307:             default ->
> 308:                 -1;

I recommend we explicitly return -1 to skip verification only for UnknownAttribute and CustomAttribute; then our tests can catch missing verification for new attribute additions.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16809#discussion_r1601464598

From jkern at openjdk.org  Wed May 15 11:40:38 2024
From: jkern at openjdk.org (Joachim Kern)
Date: Wed, 15 May 2024 11:40:38 GMT
Subject: RFR: 8329653: JLILaunchTest fails on AIX after JDK-8329131 [v4]
In-Reply-To: <y9wItIb8Yr_ZrHfN_kV5lDCp-d-VtYam3MuHX1OxurU=.ce3378d2-90b3-4396-8951-4651439e4f90@github.com>
References: <y9wItIb8Yr_ZrHfN_kV5lDCp-d-VtYam3MuHX1OxurU=.ce3378d2-90b3-4396-8951-4651439e4f90@github.com>
Message-ID: <B4fnEUhaQA3-OrvcqKeu-fnqrHw88Wl91BijRP7ZMQo=.b20706a4-5634-41f1-8c4a-5b9775280c3b@github.com>

> Since ~ end of March, after [JDK-8329131](https://bugs.openjdk.org/browse/JDK-8329131), tools/launcher/JliLaunchTest.java fails on AIX. Failure is :
> 
>  stdout: [];
>  stderr: [Error: could not find libjava.so
> Error: Could not find Java SE Runtime Environment.
> ]
>  exitValue = 2
> 
> java.lang.RuntimeException: Expected to get exit value of [0], exit value is: [2]
> at jdk.test.lib.process.OutputAnalyzer.shouldHaveExitValue(OutputAnalyzer.java:521)
> at JliLaunchTest.main(JliLaunchTest.java:58)
> at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
> at java.base/java.lang.reflect.Method.invoke(Method.java:580)
> at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:333)
> at java.base/java.lang.Thread.run(Thread.java:1575)
> 
> Maybe we need to do further adjustments to BUILD_JDK_JTREG_EXECUTABLES_LIBS_exeJliLaunchTest / BUILD_JDK_JTREG_EXECUTABLES_LDFLAGS_exeJliLaunchTest on AIX ?
> Or somehow adjust the coding that attempts to find parts of "JRE" (libjava.so) ? The libjli.so is gone on AIX after [JDK-8329131](https://bugs.openjdk.org/browse/JDK-8329131), and with this also the image discovery based on GetApplicationHomeFromDll which uses libjli.so .
> 
> Without libjli.so we have to analyze the LD-LIBRARY_PATH / LIBPATH envvar. There is no other methos available on AIX, because it lacks the $ORIGIN feature of the rpath.

Joachim Kern has updated the pull request incrementally with one additional commit since the last revision:

  cosmetic changes

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19000/files
  - new: https://git.openjdk.org/jdk/pull/19000/files/5890bca3..ba3abf02

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19000&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19000&range=02-03

  Stats: 7 lines in 1 file changed: 0 ins; 5 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/19000.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19000/head:pull/19000

PR: https://git.openjdk.org/jdk/pull/19000

From liach at openjdk.org  Wed May 15 11:45:24 2024
From: liach at openjdk.org (Chen Liang)
Date: Wed, 15 May 2024 11:45:24 GMT
Subject: RFR: 8331724: Refactor j.l.constant implementation to internal
 package [v9]
In-Reply-To: <1wZbAw87Y08xQaSexmblXR7j9U4JxVrLG6mEQiVrOTk=.07b112c4-237c-4316-9478-e4fd57c6c232@github.com>
References: <_GPUF9d1E6eBKRxP6bEEqA3LSKRJe2GwCRTfVYbDwFU=.cb482785-e7c4-45f7-bd3a-cd32d466a2cb@github.com>
 <_ZuDS5DbpEUnhV64qoXok-S0o8l7dof98Vl8BwCdBuM=.bcccdef0-a5c2-4e59-9517-c3b4980225a4@github.com>
 <W78MmrX44sVhytHBQj4JUE-wNK1RtrxUS6h0PdXewhc=.91e60f61-2d95-4e2b-89bc-b47f343f2e50@github.com>
 <1wZbAw87Y08xQaSexmblXR7j9U4JxVrLG6mEQiVrOTk=.07b112c4-237c-4316-9478-e4fd57c6c232@github.com>
Message-ID: <MPSRQYX9R66L0XgnfrWCOejbIe--tW18-kEsjCxB56E=.802a7453-e80c-43cc-9b98-37cf02f3d9e3@github.com>

On Wed, 15 May 2024 07:16:37 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/constant/ClassDesc.java line 226:
>> 
>>> 224:         for (int i = 0; i < rank; i++) {
>>> 225:             sb.append('[');
>>> 226:         }
>> 
>> Would `sb.repeat("[", rank);` be better here?
>> 
>> Also for parity with `arrayType()` I recommend moving this building code to after the void check.
>
> Oh, that's new (in 21). I was comparing against `append("[".repeat(rank))` which had a cost here. `sb.repeat('[', rank)` is in the same ballpark and simpler. Fixing.
> 
> 
> Benchmark                                       Mode  Cnt     Score     Error   Units
> ClassDescMethods.arrayType2                     avgt   15    31,568 ?   2,108   ns/op
> ClassDescMethods.arrayType2:gc.alloc.rate.norm  avgt   15   256,000 ?   0,001    B/op
> 
> 
> I'll align the code to construct `newDesc` before the void check in both methods.

Didn't realize the char version actually takes an int codepoint ? so I suggested the String one.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19105#discussion_r1601477998

From clanger at openjdk.org  Wed May 15 11:53:16 2024
From: clanger at openjdk.org (Christoph Langer)
Date: Wed, 15 May 2024 11:53:16 GMT
Subject: RFR: 8329653: JLILaunchTest fails on AIX after JDK-8329131 [v4]
In-Reply-To: <B4fnEUhaQA3-OrvcqKeu-fnqrHw88Wl91BijRP7ZMQo=.b20706a4-5634-41f1-8c4a-5b9775280c3b@github.com>
References: <y9wItIb8Yr_ZrHfN_kV5lDCp-d-VtYam3MuHX1OxurU=.ce3378d2-90b3-4396-8951-4651439e4f90@github.com>
 <B4fnEUhaQA3-OrvcqKeu-fnqrHw88Wl91BijRP7ZMQo=.b20706a4-5634-41f1-8c4a-5b9775280c3b@github.com>
Message-ID: <_vPqSrlgxNBdcNuZFTFeqzVpVblSLhLUisKjHdVVwws=.9c41b205-2ecb-4cb7-9e9b-94174f9cfecc@github.com>

On Wed, 15 May 2024 11:40:38 GMT, Joachim Kern <jkern at openjdk.org> wrote:

>> Since ~ end of March, after [JDK-8329131](https://bugs.openjdk.org/browse/JDK-8329131), tools/launcher/JliLaunchTest.java fails on AIX. Failure is :
>> 
>>  stdout: [];
>>  stderr: [Error: could not find libjava.so
>> Error: Could not find Java SE Runtime Environment.
>> ]
>>  exitValue = 2
>> 
>> java.lang.RuntimeException: Expected to get exit value of [0], exit value is: [2]
>> at jdk.test.lib.process.OutputAnalyzer.shouldHaveExitValue(OutputAnalyzer.java:521)
>> at JliLaunchTest.main(JliLaunchTest.java:58)
>> at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
>> at java.base/java.lang.reflect.Method.invoke(Method.java:580)
>> at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:333)
>> at java.base/java.lang.Thread.run(Thread.java:1575)
>> 
>> Maybe we need to do further adjustments to BUILD_JDK_JTREG_EXECUTABLES_LIBS_exeJliLaunchTest / BUILD_JDK_JTREG_EXECUTABLES_LDFLAGS_exeJliLaunchTest on AIX ?
>> Or somehow adjust the coding that attempts to find parts of "JRE" (libjava.so) ? The libjli.so is gone on AIX after [JDK-8329131](https://bugs.openjdk.org/browse/JDK-8329131), and with this also the image discovery based on GetApplicationHomeFromDll which uses libjli.so .
>> 
>> Without libjli.so we have to analyze the LD-LIBRARY_PATH / LIBPATH envvar. There is no other methos available on AIX, because it lacks the $ORIGIN feature of the rpath.
>
> Joachim Kern has updated the pull request incrementally with one additional commit since the last revision:
> 
>   cosmetic changes

src/java.base/unix/native/libjli/java_md_common.c line 128:

> 126: /*
> 127:  * Retrieves the path to the JRE home by locating libjava.so in
> 128:  * one of the LIBPATH and then truncating the path to it.

Suggestion:

 * LIBPATH and then truncating the path to it.


Another small comment suggestion

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19000#discussion_r1601491722

From sgehwolf at openjdk.org  Wed May 15 11:55:39 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Wed, 15 May 2024 11:55:39 GMT
Subject: RFR: 8311302: Allow for jlinking a custom runtime without packaged
 modules being present [v28]
In-Reply-To: <Z0DJ87uKPbjS6mvJIE_oG5m-RWsbERXsytSgV8Bmhdo=.f8723513-0ac6-4e85-9131-3c3924860c61@github.com>
References: <Z0DJ87uKPbjS6mvJIE_oG5m-RWsbERXsytSgV8Bmhdo=.f8723513-0ac6-4e85-9131-3c3924860c61@github.com>
Message-ID: <HO9oahxAcg-AnDbjKb7A7IIz7RtBEdDOx0gWhDKfF28=.2ea93020-4f40-43d6-917f-e445364c10b4@github.com>

> Please review this patch which adds a jlink mode to the JDK which doesn't need the packaged modules being present. A.k.a run-time image based jlink. Fundamentally this patch adds an option to use `jlink` even though your JDK install might not come with the packaged modules (directory `jmods`). This is particularly useful to further reduce the size of a jlinked runtime. After the removal of the concept of a JRE, a common distribution mechanism is still the full JDK with all modules and packaged modules. However, packaged modules can incur an additional size tax. For example in a container scenario it could be useful to have a base JDK container including all modules, but without also delivering the packaged modules. This comes at a size advantage of `~25%`. Such a base JDK container could then be used to `jlink` application specific runtimes, further reducing the size of the application runtime image (App + JDK runtime; as a single image *or* separate bundles, depending on the app b
 eing modularized).
> 
> The basic design of this approach is to add a jlink plugin for tracking non-class and non-resource files of a JDK install. I.e. files which aren't present in the jimage (`lib/modules`). This enables producing a `JRTArchive` class which has all the info of what constitutes the final jlinked runtime.
> 
> Basic usage example:
> 
> $ diff -u <(./bin/java --list-modules --limit-modules java.se) <(../linux-x86_64-server-release/images/jdk/bin/java --list-modules --limit-modules java.se)
> $ diff -u <(./bin/java --list-modules --limit-modules jdk.jlink) <(../linux-x86_64-server-release/images/jdk/bin/java --list-modules --limit-modules jdk.jlink)
> $ ls ../linux-x86_64-server-release/images/jdk/jmods
> java.base.jmod            java.net.http.jmod       java.sql.rowset.jmod      jdk.crypto.ec.jmod         jdk.internal.opt.jmod                     jdk.jdi.jmod         jdk.management.agent.jmod  jdk.security.auth.jmod
> java.compiler.jmod        java.prefs.jmod          java.transaction.xa.jmod  jdk.dynalink.jmod          jdk.internal.vm.ci.jmod                   jdk.jdwp.agent.jmod  jdk.management.jfr.jmod    jdk.security.jgss.jmod
> java.datatransfer.jmod    java.rmi.jmod            java.xml.crypto.jmod      jdk.editpad.jmod           jdk.internal.vm.compiler.jmod             jdk.jfr.jmod         jdk.management.jmod        jdk.unsupported.desktop.jmod
> java.desktop.jmod         java.scripting.jmod      java.xml.jmod             jdk.hotspot.agent.jmod     jdk.internal.vm.compiler.manage...

Severin Gehwolf has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 108 commits:

 - Merge branch 'master' into jdk-8311302-jmodless-link
 - Simplify JLINK_JDK_EXTRA_OPTS var handling
 - Only add runtime track files for linkable runtimes
 - Generate the runtime image link diff at jlink time
   
   But only do that once the plugin-pipeline has run. The generation is
   enabled with the hidden option '--generate-linkable-runtime' and
   the resource pools available at jlink time are being used to generate
   the diff.
 - Merge branch 'master' into jdk-8311302-jmodless-link
 - Use shorter name for the build tool
 - Review feedback from Erik J.
 - Remove dependency on CDS which isn't needed anymore
 - Fix coment
 - Fix comment
 - ... and 98 more: https://git.openjdk.org/jdk/compare/957eb611...8cca277e

-------------

Changes: https://git.openjdk.org/jdk/pull/14787/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14787&range=27
  Stats: 3424 lines in 36 files changed: 3272 ins; 110 del; 42 mod
  Patch: https://git.openjdk.org/jdk/pull/14787.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14787/head:pull/14787

PR: https://git.openjdk.org/jdk/pull/14787

From jkern at openjdk.org  Wed May 15 12:00:18 2024
From: jkern at openjdk.org (Joachim Kern)
Date: Wed, 15 May 2024 12:00:18 GMT
Subject: RFR: 8329653: JLILaunchTest fails on AIX after JDK-8329131 [v5]
In-Reply-To: <y9wItIb8Yr_ZrHfN_kV5lDCp-d-VtYam3MuHX1OxurU=.ce3378d2-90b3-4396-8951-4651439e4f90@github.com>
References: <y9wItIb8Yr_ZrHfN_kV5lDCp-d-VtYam3MuHX1OxurU=.ce3378d2-90b3-4396-8951-4651439e4f90@github.com>
Message-ID: <-1mfgVTRYGYZPtDp0r5T8Ly4MccJWkgTevrn06vug3s=.6482f991-f563-46c1-ab8a-12949c5f3282@github.com>

> Since ~ end of March, after [JDK-8329131](https://bugs.openjdk.org/browse/JDK-8329131), tools/launcher/JliLaunchTest.java fails on AIX. Failure is :
> 
>  stdout: [];
>  stderr: [Error: could not find libjava.so
> Error: Could not find Java SE Runtime Environment.
> ]
>  exitValue = 2
> 
> java.lang.RuntimeException: Expected to get exit value of [0], exit value is: [2]
> at jdk.test.lib.process.OutputAnalyzer.shouldHaveExitValue(OutputAnalyzer.java:521)
> at JliLaunchTest.main(JliLaunchTest.java:58)
> at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
> at java.base/java.lang.reflect.Method.invoke(Method.java:580)
> at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:333)
> at java.base/java.lang.Thread.run(Thread.java:1575)
> 
> Maybe we need to do further adjustments to BUILD_JDK_JTREG_EXECUTABLES_LIBS_exeJliLaunchTest / BUILD_JDK_JTREG_EXECUTABLES_LDFLAGS_exeJliLaunchTest on AIX ?
> Or somehow adjust the coding that attempts to find parts of "JRE" (libjava.so) ? The libjli.so is gone on AIX after [JDK-8329131](https://bugs.openjdk.org/browse/JDK-8329131), and with this also the image discovery based on GetApplicationHomeFromDll which uses libjli.so .
> 
> Without libjli.so we have to analyze the LD-LIBRARY_PATH / LIBPATH envvar. There is no other methos available on AIX, because it lacks the $ORIGIN feature of the rpath.

Joachim Kern has updated the pull request incrementally with one additional commit since the last revision:

  cosmetic changes

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19000/files
  - new: https://git.openjdk.org/jdk/pull/19000/files/ba3abf02..0c8c22ce

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19000&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19000&range=03-04

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/19000.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19000/head:pull/19000

PR: https://git.openjdk.org/jdk/pull/19000

From forax at openjdk.org  Wed May 15 12:29:18 2024
From: forax at openjdk.org (=?UTF-8?B?UsOpbWk=?= Forax)
Date: Wed, 15 May 2024 12:29:18 GMT
Subject: RFR: 8330465: Stable Values and Collections (Internal) [v4]
In-Reply-To: <K90SVl2BCEkM_lc37eC9NPdtq5uMxse62LZ9xsxDbyI=.03ad5520-18ce-4c78-bc51-45aa496bc503@github.com>
References: <-KSimQo5kkmCzzMShqGe5QZ9yCSzpWL98gN13v4wP0k=.11dd8d06-18a6-4577-8342-66632cea0b6e@github.com>
 <Aoeah2Qx-yd_WnZV4YKBJrU-N_Ht2U2FBymgFK5B_jg=.caf754c8-4f71-4dda-b093-7f3ef050d1c0@github.com>
 <WTvK6htLFImBbqJaegAYhe66v-7Ukg1Rbr_SBPAAUw4=.0339bae0-9215-4786-9847-b54428d6e1fa@github.com>
 <lashsCFY4UdB4ssgwteonzsOO8uqHAlEehoRy1iI1p8=.d4fca59b-1733-497f-9ff3-d134843a4d9c@github.com>
 <K90SVl2BCEkM_lc37eC9NPdtq5uMxse62LZ9xsxDbyI=.03ad5520-18ce-4c78-bc51-45aa496bc503@github.com>
Message-ID: <aqMzmR7809faNQYdPkvTm39j9ENwc9efTGfIqVPT7HI=.4ec72ad9-878d-41ea-923d-3b4b3b04389e@github.com>

On Wed, 15 May 2024 11:27:04 GMT, ExE Boss <duke at openjdk.org> wrote:

>>> Maybe?export this?interface to?`jdk.unsupported`?
>> 
>> I don't we should do that. In general, we need jdk.unsupported to go away in the long term. Also integrity of the platform depends on java.base being very stingy and not exporting internal packages to other modules.
>
> Given that `TrustedFieldType` is?more?generic than?stable?values, it?could be?moved to?`jdk.internal.misc` or?`jdk.internal.reflect`, then?`jdk.unsupported` could?use?it without?exporting new?packages to?`jdk.unsupported`.

At some point in the future, 'jdk.unsupported' will be removed

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18794#discussion_r1601548492

From alanb at openjdk.org  Wed May 15 12:50:04 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 15 May 2024 12:50:04 GMT
Subject: RFR: 8331670: Deprecate the Memory-Access Methods in
 sun.misc.Unsafe for Removal
In-Reply-To: <541F_cSF64RGRc_OmbcCufmAK_xPZdOSFlwx1ePbgyk=.11db8c10-a778-49be-9cd3-df30c2797ae0@github.com>
References: <9FyO4QpCtH2CNkUEE78_Jjd9xs3bv3WJo16jyowHOvY=.e7131b91-37bb-4624-a60e-72a427a24c92@github.com>
 <541F_cSF64RGRc_OmbcCufmAK_xPZdOSFlwx1ePbgyk=.11db8c10-a778-49be-9cd3-df30c2797ae0@github.com>
Message-ID: <zSb-840lqMbAMvyTZ9Y-ieen1Mjsx_ptF6HguyUk4W4=.9653865c-49f5-4439-9704-919d7ceadaed@github.com>

On Wed, 15 May 2024 10:18:11 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> The FFM code throws if an unknown value is passed. Here we log. Should we try to be more consistent?

I don't have a strong opinion on this. The value of --illegal-native-access is examined during startup so startup can fail if a bad value is specified. Here it is mid-flight when Unsafe initialises. The coin toss landed on printing a warning but it could equally fail. I jus didn't want code executing during startup to check configuration for something faraway in the jdk.unsupported module.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19174#discussion_r1601582672

From jwaters at openjdk.org  Wed May 15 13:08:14 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Wed, 15 May 2024 13:08:14 GMT
Subject: RFR: 8330988: Implementation of 8288293: Windows/gcc Port for
 hsdis [v2]
In-Reply-To: <xvXZ9TddIGBdQqUJ0c_MccUw7lPjJqeTZzrPYJG-EyQ=.59e09c22-93b5-4271-9cc7-60b1d1f90a8e@github.com>
References: <bXwOUFPBZUWDmidfDnVJLBKG4HkeS585IJqAOK8W1ys=.211183fe-b18e-498d-a557-6e6c4dfac27c@github.com>
 <xvXZ9TddIGBdQqUJ0c_MccUw7lPjJqeTZzrPYJG-EyQ=.59e09c22-93b5-4271-9cc7-60b1d1f90a8e@github.com>
Message-ID: <G-d5bIKoJ6s9_HLHlFrrKGMACGf8m643U6V_dhPcAiE=.967a2ec8-da86-4aea-b10f-0fa4b1762536@github.com>

On Thu, 9 May 2024 07:50:00 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.
>
> Julian Waters has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:
> 
>  - Add check for compiler in configure
>  - 8330988: Implementation of 8288293: Windows/gcc Port for hsdis

Magnus? Erik? You guys there? :(

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18915#issuecomment-2112465392

From ihse at openjdk.org  Wed May 15 13:17:25 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 15 May 2024 13:17:25 GMT
Subject: RFR: 8311302: Allow for jlinking a custom runtime without packaged
 modules being present [v28]
In-Reply-To: <HO9oahxAcg-AnDbjKb7A7IIz7RtBEdDOx0gWhDKfF28=.2ea93020-4f40-43d6-917f-e445364c10b4@github.com>
References: <Z0DJ87uKPbjS6mvJIE_oG5m-RWsbERXsytSgV8Bmhdo=.f8723513-0ac6-4e85-9131-3c3924860c61@github.com>
 <HO9oahxAcg-AnDbjKb7A7IIz7RtBEdDOx0gWhDKfF28=.2ea93020-4f40-43d6-917f-e445364c10b4@github.com>
Message-ID: <S-fHpU2AX-P3WaqBwdJwGDTM4uboUuj3HwErDr9Unuk=.ed842ddf-b45f-4d0b-b7ba-800c5e6baf97@github.com>

On Wed, 15 May 2024 11:55:39 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> Please review this patch which adds a jlink mode to the JDK which doesn't need the packaged modules being present. A.k.a run-time image based jlink. Fundamentally this patch adds an option to use `jlink` even though your JDK install might not come with the packaged modules (directory `jmods`). This is particularly useful to further reduce the size of a jlinked runtime. After the removal of the concept of a JRE, a common distribution mechanism is still the full JDK with all modules and packaged modules. However, packaged modules can incur an additional size tax. For example in a container scenario it could be useful to have a base JDK container including all modules, but without also delivering the packaged modules. This comes at a size advantage of `~25%`. Such a base JDK container could then be used to `jlink` application specific runtimes, further reducing the size of the application runtime image (App + JDK runtime; as a single image *or* separate bundles, depending on the app 
 being modularized).
>> 
>> The basic design of this approach is to add a jlink plugin for tracking non-class and non-resource files of a JDK install. I.e. files which aren't present in the jimage (`lib/modules`). This enables producing a `JRTArchive` class which has all the info of what constitutes the final jlinked runtime.
>> 
>> Basic usage example:
>> 
>> $ diff -u <(./bin/java --list-modules --limit-modules java.se) <(../linux-x86_64-server-release/images/jdk/bin/java --list-modules --limit-modules java.se)
>> $ diff -u <(./bin/java --list-modules --limit-modules jdk.jlink) <(../linux-x86_64-server-release/images/jdk/bin/java --list-modules --limit-modules jdk.jlink)
>> $ ls ../linux-x86_64-server-release/images/jdk/jmods
>> java.base.jmod            java.net.http.jmod       java.sql.rowset.jmod      jdk.crypto.ec.jmod         jdk.internal.opt.jmod                     jdk.jdi.jmod         jdk.management.agent.jmod  jdk.security.auth.jmod
>> java.compiler.jmod        java.prefs.jmod          java.transaction.xa.jmod  jdk.dynalink.jmod          jdk.internal.vm.ci.jmod                   jdk.jdwp.agent.jmod  jdk.management.jfr.jmod    jdk.security.jgss.jmod
>> java.datatransfer.jmod    java.rmi.jmod            java.xml.crypto.jmod      jdk.editpad.jmod           jdk.internal.vm.compiler.jmod             jdk.jfr.jmod         jdk.management.jmod        jdk.unsupported.desktop.jmod
>> java.desktop.jmod         java.scripting.jmod      java.xml.jmod             jdk.hotspot.agent.jmod     jdk.i...
>
> Severin Gehwolf has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 108 commits:
> 
>  - Merge branch 'master' into jdk-8311302-jmodless-link
>  - Simplify JLINK_JDK_EXTRA_OPTS var handling
>  - Only add runtime track files for linkable runtimes
>  - Generate the runtime image link diff at jlink time
>    
>    But only do that once the plugin-pipeline has run. The generation is
>    enabled with the hidden option '--generate-linkable-runtime' and
>    the resource pools available at jlink time are being used to generate
>    the diff.
>  - Merge branch 'master' into jdk-8311302-jmodless-link
>  - Use shorter name for the build tool
>  - Review feedback from Erik J.
>  - Remove dependency on CDS which isn't needed anymore
>  - Fix coment
>  - Fix comment
>  - ... and 98 more: https://git.openjdk.org/jdk/compare/957eb611...8cca277e

Thanks! Now I am 100% happy with the build changes. :)

-------------

Marked as reviewed by ihse (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14787#pullrequestreview-2057984229

From ihse at openjdk.org  Wed May 15 13:35:05 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 15 May 2024 13:35:05 GMT
Subject: RFR: 8330988: Implementation of 8288293: Windows/gcc Port for
 hsdis [v2]
In-Reply-To: <xvXZ9TddIGBdQqUJ0c_MccUw7lPjJqeTZzrPYJG-EyQ=.59e09c22-93b5-4271-9cc7-60b1d1f90a8e@github.com>
References: <bXwOUFPBZUWDmidfDnVJLBKG4HkeS585IJqAOK8W1ys=.211183fe-b18e-498d-a557-6e6c4dfac27c@github.com>
 <xvXZ9TddIGBdQqUJ0c_MccUw7lPjJqeTZzrPYJG-EyQ=.59e09c22-93b5-4271-9cc7-60b1d1f90a8e@github.com>
Message-ID: <uDQsb80PEdGh5z4AWPX3AxJZXhc-1V1XjwdhKo2Pylc=.63b6303a-dcb9-4cfc-acc6-e512a73b7496@github.com>

On Thu, 9 May 2024 07:50:00 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.
>
> Julian Waters has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:
> 
>  - Add check for compiler in configure
>  - 8330988: Implementation of 8288293: Windows/gcc Port for hsdis

Hi Julian, sorry for not getting back to you.

The problem from my PoV is that this is a very large and intrusive patch in the build of the actual product, for a claimed problem in the tangential hsdis library. I have not understood a pressing business need to get a Windows/gcc port for hsdis, which means I can't really prioritize trying to understand this patch.

As you know, the build system does not currently really separate between "the OS is Windows" and "the toolchain is Microsoft". I understand that you want to fix that, and in theory I support it. However, you must also realize that making a complete fix of this requires a lot of work, for something that there is no clearly defined need. (After all, cl.exe works fine to create the build, has no apparent issues, and is as far as an "official" compiler for Windows as you can get.) That makes it fall squarely in the WIBNIs bucked ("wouldn't it be nice if...").

If you can fix just the hsdis build without changing anything outside the hsdis Makefiles, that would be a different story. Such a change would be limited in scope, easy to say it will not affect the product proper, and be easier to review.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18915#issuecomment-2112546029

From redestad at openjdk.org  Wed May 15 14:15:05 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Wed, 15 May 2024 14:15:05 GMT
Subject: RFR: 8331724: Refactor j.l.constant implementation to internal
 package [v13]
In-Reply-To: <zuoNJZww8C8zmDH9ik0h6Vr9SvjxwKdgw8bp5pKcxD4=.f07a6409-9298-4690-a339-39d3ff001c02@github.com>
References: <_GPUF9d1E6eBKRxP6bEEqA3LSKRJe2GwCRTfVYbDwFU=.cb482785-e7c4-45f7-bd3a-cd32d466a2cb@github.com>
 <zuoNJZww8C8zmDH9ik0h6Vr9SvjxwKdgw8bp5pKcxD4=.f07a6409-9298-4690-a339-39d3ff001c02@github.com>
Message-ID: <jOGPqhSaMCq9HTHmjOIkICFmU2ngJ26UI9zIRqYA72E=.ffce0378-433b-4cfb-8b70-12e12f6cdd75@github.com>

On Wed, 15 May 2024 11:17:42 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> This PR suggests refactoring the implementation classes of java.lang.constant into a new package jdk.internal.constant to enable sharing some trusted static factory methods with users elsewhere in java.base, such as java.lang.invoke and java.lang.classfile. The refactoring also adds some "trusted" methods for use when input is pre-validated, and makes use of them where applicable in the current implementation. There are more changes in the pipeline which will be folded into #17108 or PR'ed once that is integrated. 
>> 
>> There are two optimizations mixed up here. One in `MethodTypeDesc.ofDescriptor`:
>> 
>> Name                                                             (descString) Cnt     Base     Error      Test   Error  Unit  Change
>> MethodTypeDescFactories.ofDescriptor  (Ljava/lang/Object;Ljava/lang/String;)I   6  138,371 ?   0,767   136,939 ? 1,126 ns/op   1,01x (p = 0,000*)
>> MethodTypeDescFactories.ofDescriptor                                      ()V   6   10,528 ?   2,495     4,110 ? 0,047 ns/op   2,56x (p = 0,000*)
>> MethodTypeDescFactories.ofDescriptor ([IJLjava/lang/String;Z)Ljava/util/List;   6  209,390 ?   4,583   196,175 ? 3,211 ns/op   1,07x (p = 0,000*)
>> MethodTypeDescFactories.ofDescriptor                    ()[Ljava/lang/String;   6   36,039 ?   8,684    20,794 ? 1,110 ns/op   1,73x (p = 0,000*)
>> MethodTypeDescFactories.ofDescriptor                                 (..IIJ)V   6  279,139 ?   6,248   187,934 ? 0,857 ns/op   1,49x (p = 0,000*)
>> MethodTypeDescFactories.ofDescriptor                 (.....................).   6 2174,387 ? 132,879  1150,652 ? 3,158 ns/op   1,89x (p = 0,000*)
>>   * = significant
>> 
>> 
>> The other in `ClassDesc::nested`, where to get rid of a simple static method in `ConstantUtils` I ended up speeding up and simplifying the public factory method:
>> 
>> Name                                      Cnt    Base     Error    Test   Error  Unit  Change
>> ClassDescFactories.ReferenceOnly.ofNested   6 209,853 ? 132,525  22,017 ? 0,573 ns/op   9,53x (p = 0,000*)
>>   * = significant
>> 
>> 
>> The optimizations could be split out and PRd independently, but I think they are simple enough to include in this refactoring.
>
> Claes Redestad has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Update src/java.base/share/classes/java/lang/constant/ClassDesc.java
>    
>    Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com>
>  - Update src/java.base/share/classes/java/lang/constant/ClassDesc.java
>    
>    Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com>

FTR I had to back out a change that would delegate to the now simplified and optimized `arrayType()` from `arrayType(int rank)` when `rank` equals `1` since the methods actually throw different exceptions, `IllegalStateException` vs `IllegalArgumentException`. This was caught by a later test. 

Unfortunate that `java.lang.constant` has chosen to use these two in particular since it's easy to miss due to the similarity of the exception names. There are also some unspecified exceptional behavior. For example on `arrayType()` only `IllegalStateException` is specified to be thrown, but calling `ClassDesc.ofDescriptor("V").arrayType()` throws an `IllegalArgumentException`. This behavior is not changed by this PR.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19105#issuecomment-2112663111

From mcimadamore at openjdk.org  Wed May 15 14:43:07 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 15 May 2024 14:43:07 GMT
Subject: Integrated: 8332003: Clarify javadoc for MemoryLayout::offsetHandle
In-Reply-To: <0uMhIaW3d_IBqbF_04WhHDKHiIXes04wawSuxc6dQxI=.7f5621f9-0d77-4433-bc00-1ff8624b65da@github.com>
References: <0uMhIaW3d_IBqbF_04WhHDKHiIXes04wawSuxc6dQxI=.7f5621f9-0d77-4433-bc00-1ff8624b65da@github.com>
Message-ID: <jCNocBoBDfp4k9ln-NVW-ot86ggCi-t4dZ5US_Ng3Ag=.ba2249d3-5656-4c46-9f36-9c57fde0da18@github.com>

On Thu, 9 May 2024 15:00:35 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> Consider this layout:
> 
> 
> MemoryLayout SEQ = MemoryLayout.sequenceLayout(5,
>              MemoryLayout.sequenceLayout(10, JAVA_INT));
> 
> 
> And the corresponding offset handle:
> 
> 
> MethodHandle offsetHandle = SEQ.offsetHandle(PathElement.sequenceLayout(), PathElement.sequenceLayout());
> 
> 
> The resulting method handle takes two additional `long` indices. The implementation checks that the dynamically provided indices conform to the bound available at construction: that is, the first index must be < 5, while the second must be < 10. If this is not true, an `IndexOutOfBoundException` is thrown.
> 
> However, the javadoc for `MemoryLayout::byteOffsetHandle` doesn't claim anything in this direction. There are only some vague claims in the javadoc for `PathElement::sequenceElement()` and `PathElement::sequenceElement(long, long, long)` which make some claims on which indices are actually allowed, but the text seems more in the tone of a discussion, rather than actual normative text.
> 
> I've tweaked the javadoc for `MemoryLayout::byteOffsetHandle` to actually state that the indices will be checked against the "size" of the corresponding open path element (this is a new concept that I also have defined in the javadoc).
> 
> I also added a test for `byteOffsetHandle` as I don't think we had a test for that specifically (although this method is tested indirectly, via `MemoryLayout::varHandle`).

This pull request has now been integrated.

Changeset: 30bb066b
Author:    Maurizio Cimadamore <mcimadamore at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/30bb066b1982c5318d54bfe74115306c602e2974
Stats:     67 lines in 2 files changed: 61 ins; 0 del; 6 mod

8332003: Clarify javadoc for MemoryLayout::offsetHandle

Reviewed-by: psandoz

-------------

PR: https://git.openjdk.org/jdk/pull/19158

From pminborg at openjdk.org  Wed May 15 15:27:34 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 15 May 2024 15:27:34 GMT
Subject: RFR: 8330465: Stable Values and Collections (Internal) [v5]
In-Reply-To: <-KSimQo5kkmCzzMShqGe5QZ9yCSzpWL98gN13v4wP0k=.11dd8d06-18a6-4577-8342-66632cea0b6e@github.com>
References: <-KSimQo5kkmCzzMShqGe5QZ9yCSzpWL98gN13v4wP0k=.11dd8d06-18a6-4577-8342-66632cea0b6e@github.com>
Message-ID: <VGuyX6AyE1gAq2nsCLIyOxnHbYbAAW8YvKk8mAjKnos=.c5ea169b-dfba-4ac8-8e91-7d897708ea5d@github.com>

> # Stable Values & Collections (Internal)
> 
> ## Summary
> This PR proposes to introduce an internal _Stable Values & Collections_ API, which provides immutable value holders where elements are initialized _at most once_. Stable Values & Collections offer the performance and safety benefits of final fields while offering greater flexibility as to the timing of initialization.
> 
> ## Goals
>  * Provide an easy and intuitive API to describe value holders that can change at most once.
>  * Decouple declaration from initialization without significant footprint or performance penalties.
>  * Reduce the amount of static initializer and/or field initialization code.
>  * Uphold integrity and consistency, even in a multi-threaded environment.
>  
> For more details, see the draft JEP: https://openjdk.org/jeps/8312611
> 
> ## Performance 
> Performance compared to instance variables using an `AtomicReference` and one protected by double-checked locking under concurrent access by 8 threads:
> 
> 
> Benchmark                       Mode  Cnt  Score   Error  Units
> StableBenchmark.instanceAtomic  avgt   10  1.576 ? 0.052  ns/op
> StableBenchmark.instanceDCL     avgt   10  1.608 ? 0.059  ns/op
> StableBenchmark.instanceStable  avgt   10  0.979 ? 0.023  ns/op <- StableValue (~40% faster than DCL)
> 
> 
> Performance compared to static variables protected by `AtomicReference`, class-holder idiom holder, and double-checked locking (8 threads):
> 
> 
> Benchmark                       Mode  Cnt  Score   Error  Units
> StableBenchmark.staticAtomic    avgt   10  1.335 ? 0.056  ns/op
> StableBenchmark.staticCHI       avgt   10  0.623 ? 0.086  ns/op
> StableBenchmark.staticDCL       avgt   10  1.418 ? 0.171  ns/op
> StableBenchmark.staticList      avgt   10  0.617 ? 0.024  ns/op
> StableBenchmark.staticStable    avgt   10  0.604 ? 0.022  ns/op <- StableValue ( > 2x faster than `AtomicInteger` and DCL)
> 
> 
> Performance for stable lists in both instance and static contexts whereby the sum of random contents is calculated for stable lists (which are thread-safe) compared to `ArrayList` instances (which are not thread-safe) (under single thread access):
> 
> 
> Benchmark                                     Mode  Cnt  Score   Error  Units
> StableListSumBenchmark.instanceArrayList      avgt   10  0.356 ? 0.005  ns/op
> StableListSumBenchmark.instanceList           avgt   10  0.373 ? 0.017  ns/op <- Stable list
> StableListSumBenchmark.staticArrayList        avgt   10  0.352 ? 0.002  ns/op
> StableListSumBenchmark.staticList             avgt   10  0.356 ? 0.00...

Per Minborg has updated the pull request incrementally with one additional commit since the last revision:

  Switch to monomorphic StableValue and use lazy arrays

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/18794/files
  - new: https://git.openjdk.org/jdk/pull/18794/files/c92b16c4..2b840e06

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18794&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18794&range=03-04

  Stats: 471 lines in 9 files changed: 126 ins; 306 del; 39 mod
  Patch: https://git.openjdk.org/jdk/pull/18794.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18794/head:pull/18794

PR: https://git.openjdk.org/jdk/pull/18794

From pminborg at openjdk.org  Wed May 15 15:27:34 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 15 May 2024 15:27:34 GMT
Subject: RFR: 8330465: Stable Values and Collections (Internal) [v4]
In-Reply-To: <WTvK6htLFImBbqJaegAYhe66v-7Ukg1Rbr_SBPAAUw4=.0339bae0-9215-4786-9847-b54428d6e1fa@github.com>
References: <-KSimQo5kkmCzzMShqGe5QZ9yCSzpWL98gN13v4wP0k=.11dd8d06-18a6-4577-8342-66632cea0b6e@github.com>
 <Aoeah2Qx-yd_WnZV4YKBJrU-N_Ht2U2FBymgFK5B_jg=.caf754c8-4f71-4dda-b093-7f3ef050d1c0@github.com>
 <WTvK6htLFImBbqJaegAYhe66v-7Ukg1Rbr_SBPAAUw4=.0339bae0-9215-4786-9847-b54428d6e1fa@github.com>
Message-ID: <mQnJpjOe_X8FKUx_xtSS9aWHl7lv72UErBbN66xUznQ=.1f6db2b9-d186-4113-80e1-bb6f75940e1b@github.com>

On Wed, 15 May 2024 08:53:32 GMT, ExE Boss <duke at openjdk.org> wrote:

>> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Revise docs for ofBackground()
>
> src/java.base/share/classes/jdk/internal/lang/StableValue.java line 1:
> 
>> 1: /*
> 
> Maybe also add `StableValue?::?<T>ofLazy?(Supplier<??extends?T>)` which?behaves more?like the?original **Computed?Constants** JEP?draft?

There is a method `StableValue::asSupplier` that is similar to the former ComputedConstant behavior.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18794#discussion_r1601840547

From pminborg at openjdk.org  Wed May 15 15:27:35 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 15 May 2024 15:27:35 GMT
Subject: RFR: 8330465: Stable Values and Collections (Internal) [v4]
In-Reply-To: <aqMzmR7809faNQYdPkvTm39j9ENwc9efTGfIqVPT7HI=.4ec72ad9-878d-41ea-923d-3b4b3b04389e@github.com>
References: <-KSimQo5kkmCzzMShqGe5QZ9yCSzpWL98gN13v4wP0k=.11dd8d06-18a6-4577-8342-66632cea0b6e@github.com>
 <Aoeah2Qx-yd_WnZV4YKBJrU-N_Ht2U2FBymgFK5B_jg=.caf754c8-4f71-4dda-b093-7f3ef050d1c0@github.com>
 <WTvK6htLFImBbqJaegAYhe66v-7Ukg1Rbr_SBPAAUw4=.0339bae0-9215-4786-9847-b54428d6e1fa@github.com>
 <lashsCFY4UdB4ssgwteonzsOO8uqHAlEehoRy1iI1p8=.d4fca59b-1733-497f-9ff3-d134843a4d9c@github.com>
 <K90SVl2BCEkM_lc37eC9NPdtq5uMxse62LZ9xsxDbyI=.03ad5520-18ce-4c78-bc51-45aa496bc503@github.com>
 <aqMzmR7809faNQYdPkvTm39j9ENwc9efTGfIqVPT7HI=.4ec72ad9-878d-41ea-923d-3b4b3b04389e@github.com>
Message-ID: <EyDO7FCncOfB4vhoQ5uG1_IoDHt_kBKfi_QAH59NW3o=.5a4369b9-cb6c-4625-9e88-7c5a54a56d8b@github.com>

On Wed, 15 May 2024 12:26:34 GMT, R?mi Forax <forax at openjdk.org> wrote:

>> Given that `TrustedFieldType` is?more?generic than?stable?values, it?could be?moved to?`jdk.internal.misc` or?`jdk.internal.reflect`, then?`jdk.unsupported` could?use?it without?exporting new?packages to?`jdk.unsupported`.
>
> At some point in the future, 'jdk.unsupported' will be removed

Maybe there is a better home for this?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18794#discussion_r1601843499

From pminborg at openjdk.org  Wed May 15 15:44:20 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 15 May 2024 15:44:20 GMT
Subject: RFR: 8330465: Stable Values and Collections (Internal) [v5]
In-Reply-To: <VGuyX6AyE1gAq2nsCLIyOxnHbYbAAW8YvKk8mAjKnos=.c5ea169b-dfba-4ac8-8e91-7d897708ea5d@github.com>
References: <-KSimQo5kkmCzzMShqGe5QZ9yCSzpWL98gN13v4wP0k=.11dd8d06-18a6-4577-8342-66632cea0b6e@github.com>
 <VGuyX6AyE1gAq2nsCLIyOxnHbYbAAW8YvKk8mAjKnos=.c5ea169b-dfba-4ac8-8e91-7d897708ea5d@github.com>
Message-ID: <xEJ5nn0dTNoJemIhsb1rpw28Q8-QXlU10-iH6KAHBS4=.f23705a3-0c7c-43b2-a00a-36ea2ef6fcf1@github.com>

On Wed, 15 May 2024 15:27:34 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> # Stable Values & Collections (Internal)
>> 
>> ## Summary
>> This PR proposes to introduce an internal _Stable Values & Collections_ API, which provides immutable value holders where elements are initialized _at most once_. Stable Values & Collections offer the performance and safety benefits of final fields while offering greater flexibility as to the timing of initialization.
>> 
>> ## Goals
>>  * Provide an easy and intuitive API to describe value holders that can change at most once.
>>  * Decouple declaration from initialization without significant footprint or performance penalties.
>>  * Reduce the amount of static initializer and/or field initialization code.
>>  * Uphold integrity and consistency, even in a multi-threaded environment.
>>  
>> For more details, see the draft JEP: https://openjdk.org/jeps/8312611
>> 
>> ## Performance 
>> Performance compared to instance variables using two `AtomicReference` and two protected by double-checked locking under concurrent access by all threads:
>> 
>> 
>> Benchmark                                      Mode  Cnt      Score      Error   Units
>> StableBenchmark.atomic                        thrpt   10    259.478 ?   36.809  ops/us
>> StableBenchmark.dcl                           thrpt   10    225.710 ?   26.638  ops/us
>> StableBenchmark.stable                        thrpt   10   4382.478 ? 1151.472  ops/us <- StableValue significantly faster
>> 
>> 
>> Performance compared to static variables protected by `AtomicReference`, class-holder idiom holder, and double-checked locking (all threads):
>> 
>> 
>> Benchmark                                      Mode  Cnt      Score      Error   Units
>> StableStaticBenchmark.atomic                  thrpt   10   6487.835 ?  385.639  ops/us
>> StableStaticBenchmark.dcl                     thrpt   10   6605.239 ?  210.610  ops/us
>> StableStaticBenchmark.stable                  thrpt   10  14338.239 ? 1426.874  ops/us
>> StableStaticBenchmark.staticCHI               thrpt   10  13780.341 ? 1839.651  ops/us
>> 
>> 
>> Performance for stable lists (thread safe) in both instance and static contexts whereby we access a single value compared to `ArrayList` instances (which are not thread-safe) (all threads):
>> 
>> 
>> Benchmark                                      Mode  Cnt      Score      Error   Units
>> StableListElementBenchmark.instanceArrayList  thrpt   10   5812.992 ? 1169.730  ops/us
>> StableListElementBenchmark.instanceList       thrpt   10   4818.643 ?  704.893  ops/us
>> StableListElementBenchmark...
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Switch to monomorphic StableValue and use lazy arrays

I have reworked the stable collections so that we create StableValues on demand and store them in a lazily populated backing array. This improved performance significantly as well as gave us improved startup times (only one array needs to be created upfront). Also, StableValue is now monomorphic. On the flip side is the fact that slightly more memory is needed.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18794#issuecomment-2112886060

From liach at openjdk.org  Wed May 15 15:44:21 2024
From: liach at openjdk.org (Chen Liang)
Date: Wed, 15 May 2024 15:44:21 GMT
Subject: RFR: 8330465: Stable Values and Collections (Internal) [v5]
In-Reply-To: <oTxcjqMHPwCLOVX4b1M0lJVOpB8Ymlb5HdYAgyscccs=.9eb93f56-8b77-480f-9f02-e25ab0fb5267@github.com>
References: <-KSimQo5kkmCzzMShqGe5QZ9yCSzpWL98gN13v4wP0k=.11dd8d06-18a6-4577-8342-66632cea0b6e@github.com>
 <v7kdbf2PaVnlgq1m7tKNqXCJU4RxdYWiUPq2hGS-nng=.8c438c20-d6bb-4163-8425-30930853d11e@github.com>
 <oTxcjqMHPwCLOVX4b1M0lJVOpB8Ymlb5HdYAgyscccs=.9eb93f56-8b77-480f-9f02-e25ab0fb5267@github.com>
Message-ID: <OuXbaSU_uWLaQoAwM7BYA_aN92ofuFzYG6lr_Nwmhhs=.9ca289fc-1814-4d92-88f2-1636a5dded4b@github.com>

On Tue, 14 May 2024 11:12:39 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> src/hotspot/share/ci/ciField.cpp line 262:
>> 
>>> 260: const char* stable_array3d_klass_name = "jdk/internal/lang/StableArray3D";
>>> 261: 
>>> 262: static bool trust_final_non_static_fields_of_type(Symbol* signature) {
>> 
>> Is there a better way of doing this?
>
> How do we check if the type implements `TrustedFieldType` in C?

Is it possible for us to just look at strict fields from valhalla, so we can reliably constant-fold those strict final fields? https://cr.openjdk.org/~jrose/jls/constructive-classes.html

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18794#discussion_r1601876058

From liach at openjdk.org  Wed May 15 15:52:14 2024
From: liach at openjdk.org (Chen Liang)
Date: Wed, 15 May 2024 15:52:14 GMT
Subject: RFR: 8330465: Stable Values and Collections (Internal) [v4]
In-Reply-To: <EyDO7FCncOfB4vhoQ5uG1_IoDHt_kBKfi_QAH59NW3o=.5a4369b9-cb6c-4625-9e88-7c5a54a56d8b@github.com>
References: <-KSimQo5kkmCzzMShqGe5QZ9yCSzpWL98gN13v4wP0k=.11dd8d06-18a6-4577-8342-66632cea0b6e@github.com>
 <Aoeah2Qx-yd_WnZV4YKBJrU-N_Ht2U2FBymgFK5B_jg=.caf754c8-4f71-4dda-b093-7f3ef050d1c0@github.com>
 <WTvK6htLFImBbqJaegAYhe66v-7Ukg1Rbr_SBPAAUw4=.0339bae0-9215-4786-9847-b54428d6e1fa@github.com>
 <lashsCFY4UdB4ssgwteonzsOO8uqHAlEehoRy1iI1p8=.d4fca59b-1733-497f-9ff3-d134843a4d9c@github.com>
 <K90SVl2BCEkM_lc37eC9NPdtq5uMxse62LZ9xsxDbyI=.03ad5520-18ce-4c78-bc51-45aa496bc503@github.com>
 <aqMzmR7809faNQYdPkvTm39j9ENwc9efTGfIqVPT7HI=.4ec72ad9-878d-41ea-923d-3b4b3b04389e@github.com>
 <EyDO7FCncOfB4vhoQ5uG1_IoDHt_kBKfi_QAH59NW3o=.5a4369b9-cb6c-4625-9e88-7c5a54a56d8b@github.com>
Message-ID: <8QkAH25MWgY2qvCQgPPID71ye9gL3cX5MqhHs1Fapy0=.293fae67-c17f-42c7-af84-79408c1ed3e1@github.com>

On Wed, 15 May 2024 15:20:58 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> At some point in the future, 'jdk.unsupported' will be removed
>
> Maybe there is a better home for this?

I don't think we should publish this API; this will soon be phased out by strict final fields (written only before super constructor calls) introduced by Valhalla, as strict final fields are never modifiable and can be safely trusted.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18794#discussion_r1601887921

From alanb at openjdk.org  Wed May 15 15:59:14 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 15 May 2024 15:59:14 GMT
Subject: RFR: 8331671: Implement JEP 472: Prepare to Restrict the Use of
 JNI [v5]
In-Reply-To: <gO_v02GJYOMjjlq_93fIQfki_iuSNwVv1tiNmp4Qe4o=.47df90f1-d348-4f26-ab88-7a80af6a3d91@github.com>
References: <CZGbki5iFdCGPPagE-ya-_L8Nkgf7OunywApOsxC548=.2cee82fa-a5d2-4165-b012-30982a85030a@github.com>
 <gO_v02GJYOMjjlq_93fIQfki_iuSNwVv1tiNmp4Qe4o=.47df90f1-d348-4f26-ab88-7a80af6a3d91@github.com>
Message-ID: <suc3iBvDYlNQN67NthCn7mNhES7uotnhpwD94oLIWys=.13442394-d2c1-4118-893b-db62656c6708@github.com>

On Wed, 15 May 2024 10:40:34 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This PR implements [JEP 472](https://openjdk.org/jeps/472), by restricting the use of JNI in the following ways:
>> 
>> * `System::load` and `System::loadLibrary` are now restricted methods
>> * `Runtime::load` and `Runtime::loadLibrary` are now restricted methods
>> * binding a JNI `native` method declaration to a native implementation is now considered a restricted operation
>> 
>> This PR slightly changes the way in which the JDK deals with restricted methods, even for FFM API calls. In Java 22, the single `--enable-native-access` was used both to specify a set of modules for which native access should be allowed *and* to specify whether illegal native access (that is, native access occurring from a module not specified by `--enable-native-access`) should be treated as an error or a warning. More specifically, an error is only issued if the `--enable-native-access flag` is used at least once.
>> 
>> Here, a new flag is introduced, namely `illegal-native-access=allow/warn/deny`, which is used to specify what should happen when access to a restricted method and/or functionality is found outside the set of modules specified with `--enable-native-access`. The default policy is `warn`, but users can select `allow` to suppress the warnings, or `deny` to cause `IllegalCallerException` to be thrown. This aligns the treatment of restricted methods with other mechanisms, such as `--illegal-access` and the more recent `--sun-misc-unsafe-memory-access`.
>> 
>> Some changes were required in the package-info javadoc for `java.lang.foreign`, to reflect the changes in the command line flags described above.
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Refine warning text for JNI method binding

src/java.base/share/classes/jdk/internal/module/ModuleBootstrap.java line 871:

> 869:             return IllegalNativeAccess.WARN;
> 870:         } else {
> 871:             fail("Value specified to --illegal-access not recognized:"

Typo in the message, should be --illegal-native-access.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19213#discussion_r1601898238

From psandoz at openjdk.org  Wed May 15 15:59:12 2024
From: psandoz at openjdk.org (Paul Sandoz)
Date: Wed, 15 May 2024 15:59:12 GMT
Subject: RFR: 8331940: ClassFile API ArrayIndexOutOfBoundsException with
 certain class files [v2]
In-Reply-To: <1XmBInBynHASRbJqzNvfriDMuz5xQmczMv1nXsSWSYo=.a5146cc9-2d11-4514-bc47-83884276d253@github.com>
References: <wWNlHWtc5H1nl9YHXQHGJBdJt-uo3p89E8MeGsRjsKY=.10b28a54-3530-42dc-8b24-5a4da8b81f9a@github.com>
 <1XmBInBynHASRbJqzNvfriDMuz5xQmczMv1nXsSWSYo=.a5146cc9-2d11-4514-bc47-83884276d253@github.com>
Message-ID: <fr0vamJwMpJgj3UlmN4vAblREv6VBf4MnDNKx9_tni4=.ffa44b87-3c1e-463c-88a3-c365414c4d34@github.com>

On Wed, 15 May 2024 07:51:33 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> Class file with `LineNumberTable` attribute element pointing behind the bytecode array throws `ArrayIndexOutOfBoundsException`.
>> This patch performs the check and throws  expected `IllegalArgumentException` instead.
>> Relevant test is added.
>> 
>> Please review.
>> 
>> Thanks,
>> Adam
>
> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fixed exception message

Marked as reviewed by psandoz (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/19230#pullrequestreview-2058434044

From mcimadamore at openjdk.org  Wed May 15 16:08:17 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 15 May 2024 16:08:17 GMT
Subject: RFR: 8331671: Implement JEP 472: Prepare to Restrict the Use of
 JNI [v6]
In-Reply-To: <CZGbki5iFdCGPPagE-ya-_L8Nkgf7OunywApOsxC548=.2cee82fa-a5d2-4165-b012-30982a85030a@github.com>
References: <CZGbki5iFdCGPPagE-ya-_L8Nkgf7OunywApOsxC548=.2cee82fa-a5d2-4165-b012-30982a85030a@github.com>
Message-ID: <SsNupEwmUHHR0JoGU-Tj_QF50Qv4qEyCXZeYLCX0Vkk=.fcb54e9d-4635-4e37-a13e-87d787e676c0@github.com>

> This PR implements [JEP 472](https://openjdk.org/jeps/472), by restricting the use of JNI in the following ways:
> 
> * `System::load` and `System::loadLibrary` are now restricted methods
> * `Runtime::load` and `Runtime::loadLibrary` are now restricted methods
> * binding a JNI `native` method declaration to a native implementation is now considered a restricted operation
> 
> This PR slightly changes the way in which the JDK deals with restricted methods, even for FFM API calls. In Java 22, the single `--enable-native-access` was used both to specify a set of modules for which native access should be allowed *and* to specify whether illegal native access (that is, native access occurring from a module not specified by `--enable-native-access`) should be treated as an error or a warning. More specifically, an error is only issued if the `--enable-native-access flag` is used at least once.
> 
> Here, a new flag is introduced, namely `illegal-native-access=allow/warn/deny`, which is used to specify what should happen when access to a restricted method and/or functionality is found outside the set of modules specified with `--enable-native-access`. The default policy is `warn`, but users can select `allow` to suppress the warnings, or `deny` to cause `IllegalCallerException` to be thrown. This aligns the treatment of restricted methods with other mechanisms, such as `--illegal-access` and the more recent `--sun-misc-unsafe-memory-access`.
> 
> Some changes were required in the package-info javadoc for `java.lang.foreign`, to reflect the changes in the command line flags described above.

Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:

  Address review comment

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19213/files
  - new: https://git.openjdk.org/jdk/pull/19213/files/daf729f4..1c45e5d5

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19213&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19213&range=04-05

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/19213.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19213/head:pull/19213

PR: https://git.openjdk.org/jdk/pull/19213

From naoto at openjdk.org  Wed May 15 16:12:33 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 15 May 2024 16:12:33 GMT
Subject: RFR: 8330276: Console methods with explicit Locale [v6]
In-Reply-To: <GT275XVwYlYL3PhYwOTQ_-HwKqp9QYUeIzEIeJKEwkQ=.9a7faf08-8637-45a3-97bd-fd58756a6711@github.com>
References: <GT275XVwYlYL3PhYwOTQ_-HwKqp9QYUeIzEIeJKEwkQ=.9a7faf08-8637-45a3-97bd-fd58756a6711@github.com>
Message-ID: <wJdAqgZa5QX1hZqIP1wEdFRU4Jijfguf98Jr0OXwjTg=.8c639ea5-4aa6-4b4b-af6d-66b6b9ba8a53@github.com>

> Proposing new overloaded methods in `java.io.Console` class that explicitly take a `Locale` argument. Existing methods rely on the default locale, so the users won't be able to format their prompts/outputs in a certain locale explicitly.

Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:

  Adding workaround to the test due to JLine's questionable behavior

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/18923/files
  - new: https://git.openjdk.org/jdk/pull/18923/files/6fd17574..cace6171

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18923&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18923&range=04-05

  Stats: 6 lines in 1 file changed: 5 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/18923.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18923/head:pull/18923

PR: https://git.openjdk.org/jdk/pull/18923

From asotona at openjdk.org  Wed May 15 16:17:19 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Wed, 15 May 2024 16:17:19 GMT
Subject: Integrated: 8331940: ClassFile API ArrayIndexOutOfBoundsException with
 certain class files
In-Reply-To: <wWNlHWtc5H1nl9YHXQHGJBdJt-uo3p89E8MeGsRjsKY=.10b28a54-3530-42dc-8b24-5a4da8b81f9a@github.com>
References: <wWNlHWtc5H1nl9YHXQHGJBdJt-uo3p89E8MeGsRjsKY=.10b28a54-3530-42dc-8b24-5a4da8b81f9a@github.com>
Message-ID: <TYi_jvmy9BPoMnJY-7d88xLIuEVtA7QK-3ylI297gpU=.6c7be459-e5a6-4854-8fa3-ef03543fe96e@github.com>

On Tue, 14 May 2024 13:18:51 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> Class file with `LineNumberTable` attribute element pointing behind the bytecode array throws `ArrayIndexOutOfBoundsException`.
> This patch performs the check and throws  expected `IllegalArgumentException` instead.
> Relevant test is added.
> 
> Please review.
> 
> Thanks,
> Adam

This pull request has now been integrated.

Changeset: 42ccb743
Author:    Adam Sotona <asotona at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/42ccb74399113a3d59ce016483518f033dd6e010
Stats:     20 lines in 2 files changed: 18 ins; 0 del; 2 mod

8331940: ClassFile API ArrayIndexOutOfBoundsException with certain class files

Reviewed-by: liach, psandoz

-------------

PR: https://git.openjdk.org/jdk/pull/19230

From liach at openjdk.org  Wed May 15 16:36:07 2024
From: liach at openjdk.org (Chen Liang)
Date: Wed, 15 May 2024 16:36:07 GMT
Subject: RFR: 8330465: Stable Values and Collections (Internal) [v5]
In-Reply-To: <KNJR16zdUgDJopccv2xKV8c9F67NK73sa0AnTLaZVHA=.b690ded3-8509-492d-8cfe-63bd5fb3209c@github.com>
References: <-KSimQo5kkmCzzMShqGe5QZ9yCSzpWL98gN13v4wP0k=.11dd8d06-18a6-4577-8342-66632cea0b6e@github.com>
 <u_EKRoeEG2ER_hkDC4UVHxVt79hDOnTr9r9-lKeFWQY=.4e855a49-48d1-4a86-bd41-5a2d4122433f@github.com>
 <KNJR16zdUgDJopccv2xKV8c9F67NK73sa0AnTLaZVHA=.b690ded3-8509-492d-8cfe-63bd5fb3209c@github.com>
Message-ID: <3TJiHIc0qhHxrztP3GxRfIBAhgsVHkD5KBQ2uKUfB8g=.fbb9881f-6752-4353-bc90-cfe6f99fc5eb@github.com>

On Mon, 6 May 2024 19:31:43 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/lang/StableArray.java line 25:
>> 
>>> 23:  * @since 23
>>> 24:  */
>>> 25: public sealed interface StableArray<V>
>> 
>> Do we have a use case for StableArray beyond those of StableList?
>
> I am trying to model multi-dimensional arrays that also provide flattening. Let's see if it becomes useful.

I think this StableArray can be used as an explicit field type to block reflection modifications and enforce constant-folding; the List interface cannot. Though in long term I still believe strict final fields are better.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18794#discussion_r1601931752

From liach at openjdk.org  Wed May 15 16:36:10 2024
From: liach at openjdk.org (Chen Liang)
Date: Wed, 15 May 2024 16:36:10 GMT
Subject: RFR: 8330465: Stable Values and Collections (Internal) [v5]
In-Reply-To: <VGuyX6AyE1gAq2nsCLIyOxnHbYbAAW8YvKk8mAjKnos=.c5ea169b-dfba-4ac8-8e91-7d897708ea5d@github.com>
References: <-KSimQo5kkmCzzMShqGe5QZ9yCSzpWL98gN13v4wP0k=.11dd8d06-18a6-4577-8342-66632cea0b6e@github.com>
 <VGuyX6AyE1gAq2nsCLIyOxnHbYbAAW8YvKk8mAjKnos=.c5ea169b-dfba-4ac8-8e91-7d897708ea5d@github.com>
Message-ID: <sWc2qReuqEhBnu0fHIg75bC8WJkp56HSO9x807NgZoA=.2041706f-383d-44d0-93c6-2eda82329869@github.com>

On Wed, 15 May 2024 15:27:34 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> # Stable Values & Collections (Internal)
>> 
>> ## Summary
>> This PR proposes to introduce an internal _Stable Values & Collections_ API, which provides immutable value holders where elements are initialized _at most once_. Stable Values & Collections offer the performance and safety benefits of final fields while offering greater flexibility as to the timing of initialization.
>> 
>> ## Goals
>>  * Provide an easy and intuitive API to describe value holders that can change at most once.
>>  * Decouple declaration from initialization without significant footprint or performance penalties.
>>  * Reduce the amount of static initializer and/or field initialization code.
>>  * Uphold integrity and consistency, even in a multi-threaded environment.
>>  
>> For more details, see the draft JEP: https://openjdk.org/jeps/8312611
>> 
>> ## Performance 
>> Performance compared to instance variables using two `AtomicReference` and two protected by double-checked locking under concurrent access by all threads:
>> 
>> 
>> Benchmark                                      Mode  Cnt      Score      Error   Units
>> StableBenchmark.atomic                        thrpt   10    259.478 ?   36.809  ops/us
>> StableBenchmark.dcl                           thrpt   10    225.710 ?   26.638  ops/us
>> StableBenchmark.stable                        thrpt   10   4382.478 ? 1151.472  ops/us <- StableValue significantly faster
>> 
>> 
>> Performance compared to static variables protected by `AtomicReference`, class-holder idiom holder, and double-checked locking (all threads):
>> 
>> 
>> Benchmark                                      Mode  Cnt      Score      Error   Units
>> StableStaticBenchmark.atomic                  thrpt   10   6487.835 ?  385.639  ops/us
>> StableStaticBenchmark.dcl                     thrpt   10   6605.239 ?  210.610  ops/us
>> StableStaticBenchmark.stable                  thrpt   10  14338.239 ? 1426.874  ops/us
>> StableStaticBenchmark.staticCHI               thrpt   10  13780.341 ? 1839.651  ops/us
>> 
>> 
>> Performance for stable lists (thread safe) in both instance and static contexts whereby we access a single value compared to `ArrayList` instances (which are not thread-safe) (all threads):
>> 
>> 
>> Benchmark                                      Mode  Cnt      Score      Error   Units
>> StableListElementBenchmark.instanceArrayList  thrpt   10   5812.992 ? 1169.730  ops/us
>> StableListElementBenchmark.instanceList       thrpt   10   4818.643 ?  704.893  ops/us
>> StableListElementBenchmark...
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Switch to monomorphic StableValue and use lazy arrays

src/java.base/share/classes/jdk/internal/lang/StableValue.java line 384:

> 382:      * @param <T>      the memoized type
> 383:      */
> 384:     static <T> Supplier<T> ofSupplier(Supplier<? extends T> original) {

`ofSupplier` sounds like this method returns a `StableValue` from a `Supplier`. I recommend another name, such as `stableSupplier`, `wrapSupplier`, or `memoize`, to better associate with the method's types.

src/java.base/share/classes/jdk/internal/lang/stable/StableValueImpl.java line 75:

> 73:      */
> 74:     @Stable
> 75:     private int state;

Can we change this to be a byte, so state and supplying fields can be packed together in 4 bytes in some layouts?

src/java.base/share/classes/jdk/internal/lang/stable/StableValueImpl.java line 104:

> 102:         // Optimistically try plain semantics first
> 103:         final V v = value;
> 104:         if (v != null) {

If `value == null && state == NULL`, can the path still be constant folded? I doubt it because `value` in this case may not be promoted to constant.

src/java.base/share/classes/jdk/internal/lang/stable/StableValueImpl.java line 139:

> 137:             case NON_NULL: { return valueVolatile(); }
> 138:             case ERROR:    { throw StableUtil.error(this); }
> 139:             case DUMMY:    { throw shouldNotReachHere(); }

Redundant branch?

src/java.base/share/classes/jdk/internal/lang/stable/StableValueImpl.java line 236:

> 234:                 } catch (Throwable t) {
> 235:                     putState(ERROR);
> 236:                     putMutex(t.getClass());

Should we cache the exception instance so we can rethrow it in future ERROR state `orThrow` calls?

src/java.base/share/classes/jdk/internal/lang/stable/StableValueImpl.java line 240:

> 238:                 }
> 239:             } finally {
> 240:                 supplying = false;

Resetting a stable field is a bad idea. I recommend renaming this to `supplierCalled` or `supplied` so we never transition this false -> true

src/java.base/share/classes/jdk/internal/lang/stable/StableValueImpl.java line 256:

> 254: 
> 255:     @ForceInline
> 256:     private <K> V computeIfUnsetShared(Object provider, K key) {

Can we let suppliers share this path too, with a null key? I see this path supports suppliers but supplier code path doesn't call this path.

src/java.base/share/classes/jdk/internal/lang/stable/StableValueImpl.java line 403:

> 401:                     stable.computeIfUnset(supplier);
> 402:                 } catch (Throwable throwable) {
> 403:                     final Thread.UncaughtExceptionHandler uncaughtExceptionHandler =

Does this exception handling differ from the default one for threads? If not, I think we can safely remove this catch block, as all exceptions are just propagated and computeIfUnset doesn't declare any checked exception.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18794#discussion_r1601935261
PR Review Comment: https://git.openjdk.org/jdk/pull/18794#discussion_r1601937748
PR Review Comment: https://git.openjdk.org/jdk/pull/18794#discussion_r1601916538
PR Review Comment: https://git.openjdk.org/jdk/pull/18794#discussion_r1601918911
PR Review Comment: https://git.openjdk.org/jdk/pull/18794#discussion_r1601940341
PR Review Comment: https://git.openjdk.org/jdk/pull/18794#discussion_r1601941518
PR Review Comment: https://git.openjdk.org/jdk/pull/18794#discussion_r1601942956
PR Review Comment: https://git.openjdk.org/jdk/pull/18794#discussion_r1601927751

From naoto at openjdk.org  Wed May 15 17:05:17 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 15 May 2024 17:05:17 GMT
Subject: RFR: 8330276: Console methods with explicit Locale [v7]
In-Reply-To: <GT275XVwYlYL3PhYwOTQ_-HwKqp9QYUeIzEIeJKEwkQ=.9a7faf08-8637-45a3-97bd-fd58756a6711@github.com>
References: <GT275XVwYlYL3PhYwOTQ_-HwKqp9QYUeIzEIeJKEwkQ=.9a7faf08-8637-45a3-97bd-fd58756a6711@github.com>
Message-ID: <obT5NKXsV-mvpwqSJxGBtbiGfelyoPuqeGM_SyuFXLc=.aa4fecaf-6788-4d67-a973-86408830c435@github.com>

> Proposing new overloaded methods in `java.io.Console` class that explicitly take a `Locale` argument. Existing methods rely on the default locale, so the users won't be able to format their prompts/outputs in a certain locale explicitly.

Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:

  Reverted test workaround. Fixed JLine (backing out a questionable change)

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/18923/files
  - new: https://git.openjdk.org/jdk/pull/18923/files/cace6171..7833da36

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18923&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18923&range=05-06

  Stats: 9 lines in 2 files changed: 2 ins; 5 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/18923.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18923/head:pull/18923

PR: https://git.openjdk.org/jdk/pull/18923

From jlahoda at openjdk.org  Wed May 15 17:35:07 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Wed, 15 May 2024 17:35:07 GMT
Subject: RFR: 8330276: Console methods with explicit Locale [v7]
In-Reply-To: <obT5NKXsV-mvpwqSJxGBtbiGfelyoPuqeGM_SyuFXLc=.aa4fecaf-6788-4d67-a973-86408830c435@github.com>
References: <GT275XVwYlYL3PhYwOTQ_-HwKqp9QYUeIzEIeJKEwkQ=.9a7faf08-8637-45a3-97bd-fd58756a6711@github.com>
 <obT5NKXsV-mvpwqSJxGBtbiGfelyoPuqeGM_SyuFXLc=.aa4fecaf-6788-4d67-a973-86408830c435@github.com>
Message-ID: <0StF1k17neSewK67rcoBy9eufUUAMuIzgxNsGtun9ns=.bb9e0c81-2411-4575-bf6d-66397bbe10b6@github.com>

On Wed, 15 May 2024 17:05:17 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Proposing new overloaded methods in `java.io.Console` class that explicitly take a `Locale` argument. Existing methods rely on the default locale, so the users won't be able to format their prompts/outputs in a certain locale explicitly.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reverted test workaround. Fixed JLine (backing out a questionable change)

Looks good to me.

-------------

Marked as reviewed by jlahoda (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18923#pullrequestreview-2058627699

From vklang at openjdk.org  Wed May 15 18:38:07 2024
From: vklang at openjdk.org (Viktor Klang)
Date: Wed, 15 May 2024 18:38:07 GMT
Subject: Integrated: 8331987: Enhance stacktrace clarity for CompletableFuture
 CancellationException
In-Reply-To: <JI-ghId-imtBqmNm850oQMNp-9p79tGMjfTRDdXz6D0=.fc134f86-914c-4484-9236-af162de3b99e@github.com>
References: <JI-ghId-imtBqmNm850oQMNp-9p79tGMjfTRDdXz6D0=.fc134f86-914c-4484-9236-af162de3b99e@github.com>
Message-ID: <D9HaAbTCa0rnmrzBY1oduLUk6_7dEitrcK5ZSHIuc6E=.08fbb178-e8b1-4128-aa9b-4af5de65865b@github.com>

On Mon, 13 May 2024 16:41:37 GMT, Viktor Klang <vklang at openjdk.org> wrote:

> This change adds wrapping of the CancellationException produced by CompletableFuture::get() and CompletableFuture::join() to add more diagnostic information and align better with FutureTask.
> 
> Running the sample code from the JBS issue in JShell will produce the following:
> 
> 
> jshell> java.util.concurrent.CancellationException: get
> 	at java.base/java.util.concurrent.CompletableFuture.reportGet(CompletableFuture.java:392)
> 	at java.base/java.util.concurrent.CompletableFuture.get(CompletableFuture.java:2073)
> 	at REPL.$JShell$18.m2($JShell$18.java:10)
> 	at REPL.$JShell$17.m1($JShell$17.java:8)
> 	at REPL.$JShell$16B.lambda$main$0($JShell$16B.java:8)
> 	at java.base/java.lang.Thread.run(Thread.java:1575)
> Caused by: java.util.concurrent.CancellationException
> 	at java.base/java.util.concurrent.CompletableFuture.cancel(CompletableFuture.java:2510)
> 	at REPL.$JShell$16B.lambda$main$1($JShell$16B.java:11)
> 	... 1 more

This pull request has now been integrated.

Changeset: 8a4315f8
Author:    Viktor Klang <vklang at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/8a4315f833f3700075d65fae6bc566011c837c07
Stats:     35 lines in 3 files changed: 25 ins; 0 del; 10 mod

8331987: Enhance stacktrace clarity for CompletableFuture CancellationException

Reviewed-by: alanb, dfuchs

-------------

PR: https://git.openjdk.org/jdk/pull/19219

From duke at openjdk.org  Wed May 15 18:44:09 2024
From: duke at openjdk.org (ExE Boss)
Date: Wed, 15 May 2024 18:44:09 GMT
Subject: RFR: 8330465: Stable Values and Collections (Internal) [v5]
In-Reply-To: <VGuyX6AyE1gAq2nsCLIyOxnHbYbAAW8YvKk8mAjKnos=.c5ea169b-dfba-4ac8-8e91-7d897708ea5d@github.com>
References: <-KSimQo5kkmCzzMShqGe5QZ9yCSzpWL98gN13v4wP0k=.11dd8d06-18a6-4577-8342-66632cea0b6e@github.com>
 <VGuyX6AyE1gAq2nsCLIyOxnHbYbAAW8YvKk8mAjKnos=.c5ea169b-dfba-4ac8-8e91-7d897708ea5d@github.com>
Message-ID: <uISY4GqP1-KDajCPrdUOFvluwr1E-1ZQ9Gai-RLREnU=.07bf19c1-4ab5-45d4-ace6-8d07f3e0fbc6@github.com>

On Wed, 15 May 2024 15:27:34 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> # Stable Values & Collections (Internal)
>> 
>> ## Summary
>> This PR proposes to introduce an internal _Stable Values & Collections_ API, which provides immutable value holders where elements are initialized _at most once_. Stable Values & Collections offer the performance and safety benefits of final fields while offering greater flexibility as to the timing of initialization.
>> 
>> ## Goals
>>  * Provide an easy and intuitive API to describe value holders that can change at most once.
>>  * Decouple declaration from initialization without significant footprint or performance penalties.
>>  * Reduce the amount of static initializer and/or field initialization code.
>>  * Uphold integrity and consistency, even in a multi-threaded environment.
>>  
>> For more details, see the draft JEP: https://openjdk.org/jeps/8312611
>> 
>> ## Performance 
>> Performance compared to instance variables using two `AtomicReference` and two protected by double-checked locking under concurrent access by all threads:
>> 
>> 
>> Benchmark                                      Mode  Cnt      Score      Error   Units
>> StableBenchmark.atomic                        thrpt   10    259.478 ?   36.809  ops/us
>> StableBenchmark.dcl                           thrpt   10    225.710 ?   26.638  ops/us
>> StableBenchmark.stable                        thrpt   10   4382.478 ? 1151.472  ops/us <- StableValue significantly faster
>> 
>> 
>> Performance compared to static variables protected by `AtomicReference`, class-holder idiom holder, and double-checked locking (all threads):
>> 
>> 
>> Benchmark                                      Mode  Cnt      Score      Error   Units
>> StableStaticBenchmark.atomic                  thrpt   10   6487.835 ?  385.639  ops/us
>> StableStaticBenchmark.dcl                     thrpt   10   6605.239 ?  210.610  ops/us
>> StableStaticBenchmark.stable                  thrpt   10  14338.239 ? 1426.874  ops/us
>> StableStaticBenchmark.staticCHI               thrpt   10  13780.341 ? 1839.651  ops/us
>> 
>> 
>> Performance for stable lists (thread safe) in both instance and static contexts whereby we access a single value compared to `ArrayList` instances (which are not thread-safe) (all threads):
>> 
>> 
>> Benchmark                                      Mode  Cnt      Score      Error   Units
>> StableListElementBenchmark.instanceArrayList  thrpt   10   5812.992 ? 1169.730  ops/us
>> StableListElementBenchmark.instanceList       thrpt   10   4818.643 ?  704.893  ops/us
>> StableListElementBenchmark...
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Switch to monomorphic StableValue and use lazy arrays

src/java.base/share/classes/jdk/internal/lang/stable/StableUtil.java line 152:

> 150:             StableValueImpl<V> witness = (StableValueImpl<V>)
> 151:                     Holder.UNSAFE.compareAndExchangeReference(elements, offset, null, stable);
> 152:             return witness == null ? stable: witness;

Suggestion:

            return witness == null ? stable : witness;

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18794#discussion_r1602094801

From duke at openjdk.org  Wed May 15 18:55:09 2024
From: duke at openjdk.org (ExE Boss)
Date: Wed, 15 May 2024 18:55:09 GMT
Subject: RFR: 8330465: Stable Values and Collections (Internal) [v5]
In-Reply-To: <sWc2qReuqEhBnu0fHIg75bC8WJkp56HSO9x807NgZoA=.2041706f-383d-44d0-93c6-2eda82329869@github.com>
References: <-KSimQo5kkmCzzMShqGe5QZ9yCSzpWL98gN13v4wP0k=.11dd8d06-18a6-4577-8342-66632cea0b6e@github.com>
 <VGuyX6AyE1gAq2nsCLIyOxnHbYbAAW8YvKk8mAjKnos=.c5ea169b-dfba-4ac8-8e91-7d897708ea5d@github.com>
 <sWc2qReuqEhBnu0fHIg75bC8WJkp56HSO9x807NgZoA=.2041706f-383d-44d0-93c6-2eda82329869@github.com>
Message-ID: <hfCAtNQs4eEApF71b4FKsHWQwl20eYeURk_AljjT-q0=.6753684c-6275-4db5-99ca-b1190fbe5b95@github.com>

On Wed, 15 May 2024 16:10:06 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Switch to monomorphic StableValue and use lazy arrays
>
> src/java.base/share/classes/jdk/internal/lang/stable/StableValueImpl.java line 104:
> 
>> 102:         // Optimistically try plain semantics first
>> 103:         final V v = value;
>> 104:         if (v != null) {
> 
> If `value == null && state == NULL`, can the path still be constant folded? I doubt it because `value` in this case may not be promoted to constant.

Maybe the?`state?==?NULL` check should?be?moved before?`v?!=?null`, as?the?**JIT** doesn?t?constant?fold `null`?[`@Stable`]?values:
https://github.com/openjdk/jdk/blob/8a4315f833f3700075d65fae6bc566011c837c07/src/java.base/share/classes/jdk/internal/vm/annotation/Stable.java#L41-L44
https://github.com/openjdk/jdk/blob/8a4315f833f3700075d65fae6bc566011c837c07/src/java.base/share/classes/jdk/internal/vm/annotation/Stable.java#L64-L71

[`@Stable`]: https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/jdk/internal/vm/annotation/Stable.java

> src/java.base/share/classes/jdk/internal/lang/stable/StableValueImpl.java line 240:
> 
>> 238:                 }
>> 239:             } finally {
>> 240:                 supplying = false;
> 
> Resetting a stable field is a bad idea. I recommend renaming this to `supplierCalled` or `supplied` so we never transition this false -> true

Yes, according to?the?`@Stable` annotation?s?JavaDoc, this?is?UB:
https://github.com/openjdk/jdk/blob/8a4315f833f3700075d65fae6bc566011c837c07/src/java.base/share/classes/jdk/internal/vm/annotation/Stable.java#L74-L80

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18794#discussion_r1602101301
PR Review Comment: https://git.openjdk.org/jdk/pull/18794#discussion_r1602106099

From liach at openjdk.org  Wed May 15 19:10:13 2024
From: liach at openjdk.org (Chen Liang)
Date: Wed, 15 May 2024 19:10:13 GMT
Subject: RFR: 8330465: Stable Values and Collections (Internal) [v5]
In-Reply-To: <hfCAtNQs4eEApF71b4FKsHWQwl20eYeURk_AljjT-q0=.6753684c-6275-4db5-99ca-b1190fbe5b95@github.com>
References: <-KSimQo5kkmCzzMShqGe5QZ9yCSzpWL98gN13v4wP0k=.11dd8d06-18a6-4577-8342-66632cea0b6e@github.com>
 <VGuyX6AyE1gAq2nsCLIyOxnHbYbAAW8YvKk8mAjKnos=.c5ea169b-dfba-4ac8-8e91-7d897708ea5d@github.com>
 <sWc2qReuqEhBnu0fHIg75bC8WJkp56HSO9x807NgZoA=.2041706f-383d-44d0-93c6-2eda82329869@github.com>
 <hfCAtNQs4eEApF71b4FKsHWQwl20eYeURk_AljjT-q0=.6753684c-6275-4db5-99ca-b1190fbe5b95@github.com>
Message-ID: <T5Wni3IAdExwxz0RvyvViUIoLTDIgC4ACAqhT5YGMm4=.48d0bc7d-a0a1-45bf-8d28-5fa6361049cb@github.com>

On Wed, 15 May 2024 18:49:49 GMT, ExE Boss <duke at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/lang/stable/StableValueImpl.java line 240:
>> 
>>> 238:                 }
>>> 239:             } finally {
>>> 240:                 supplying = false;
>> 
>> Resetting a stable field is a bad idea. I recommend renaming this to `supplierCalled` or `supplied` so we never transition this false -> true
>
> Yes, according to?the?`@Stable` annotation?s?JavaDoc, this?is?UB:
> https://github.com/openjdk/jdk/blob/8a4315f833f3700075d65fae6bc566011c837c07/src/java.base/share/classes/jdk/internal/vm/annotation/Stable.java#L74-L80

Fyi what usually happens is that if a stable field or similarly constant-folded field is promoted to constant, the constant promotion can happen to any of the previous valid values written.

MethodHandle optimisitically sets a trusted final field this way:
https://github.com/openjdk/jdk/blob/8a4315f833f3700075d65fae6bc566011c837c07/src/java.base/share/classes/java/lang/invoke/MethodHandle.java#L1868-L1870

Also a similar example in user code targeting older Java releases, before JDK 16's strong encapsulation so that enums could have been added by reflection:
https://github.com/MinecraftForge/MinecraftForge/issues/3885#issuecomment-355602542

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18794#discussion_r1602125255

From naoto at openjdk.org  Wed May 15 19:31:07 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 15 May 2024 19:31:07 GMT
Subject: Integrated: 8330276: Console methods with explicit Locale
In-Reply-To: <GT275XVwYlYL3PhYwOTQ_-HwKqp9QYUeIzEIeJKEwkQ=.9a7faf08-8637-45a3-97bd-fd58756a6711@github.com>
References: <GT275XVwYlYL3PhYwOTQ_-HwKqp9QYUeIzEIeJKEwkQ=.9a7faf08-8637-45a3-97bd-fd58756a6711@github.com>
Message-ID: <Wcem1WS5qxBJglpfmOzKiVEl-HVMHOHZmQnb1RKnKBE=.1b0568d8-0e91-452b-b039-3edace08e399@github.com>

On Tue, 23 Apr 2024 20:35:43 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Proposing new overloaded methods in `java.io.Console` class that explicitly take a `Locale` argument. Existing methods rely on the default locale, so the users won't be able to format their prompts/outputs in a certain locale explicitly.

This pull request has now been integrated.

Changeset: 7cff04fc
Author:    Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/7cff04fc8a8114a297437aa526b18b6185831eac
Stats:     441 lines in 8 files changed: 337 ins; 24 del; 80 mod

8330276: Console methods with explicit Locale

Reviewed-by: joehw, rriggs, jlahoda

-------------

PR: https://git.openjdk.org/jdk/pull/18923

From duke at openjdk.org  Wed May 15 20:26:17 2024
From: duke at openjdk.org (Volodymyr Paprotski)
Date: Wed, 15 May 2024 20:26:17 GMT
Subject: RFR: 8320448: Accelerate IndexOf using AVX2 [v19]
In-Reply-To: <eQ4OBFrF8JlDJ1h9awTDOc0kfCc37IlL5vdqtuaqls0=.8f00616d-08e1-4f28-a7a5-5095116d2595@github.com>
References: <uWi4QxH31hL93771gkl_GgvP0m84IRSoR_1Yi8hD17E=.bc6ed458-7081-4c3f-9348-f59358fa05a4@github.com>
 <eQ4OBFrF8JlDJ1h9awTDOc0kfCc37IlL5vdqtuaqls0=.8f00616d-08e1-4f28-a7a5-5095116d2595@github.com>
Message-ID: <aTbnceYj7mQGE4hpCoeUqv5r-W8iHSI_EqVncR0iU_s=.6a63f8c5-eafb-48d5-a871-4cc475e0f63f@github.com>

On Sat, 4 May 2024 19:35:21 GMT, Scott Gibbons <sgibbons at openjdk.org> wrote:

>> Re-write the IndexOf code without the use of the pcmpestri instruction, only using AVX2 instructions.  This change accelerates String.IndexOf on average 1.3x for AVX2.  The benchmark numbers:
>> 
>> 
>> Benchmark	                                               Score		Latest		
>> StringIndexOf.advancedWithMediumSub   343.573		317.934		0.925375393x
>> StringIndexOf.advancedWithShortSub1	  1039.081		1053.96		1.014319384x
>> StringIndexOf.advancedWithShortSub2	      55.828		110.541		1.980027943x
>> StringIndexOf.constantPattern	                9.361		11.906		1.271872663x
>> StringIndexOf.searchCharLongSuccess	        4.216		4.218		1.000474383x
>> StringIndexOf.searchCharMediumSuccess	3.133		3.216		1.02649218x
>> StringIndexOf.searchCharShortSuccess	3.76		        3.761		1.000265957x
>> StringIndexOf.success	                                9.186		9.713		1.057369911x
>> StringIndexOf.successBig	                      14.341		46.343		3.231504079x
>> StringIndexOfChar.latin1_AVX2_String	  6220.918		12154.52		1.953814533x
>> StringIndexOfChar.latin1_AVX2_char	  5503.556		5540.044		1.006629895x
>> StringIndexOfChar.latin1_SSE4_String	  6978.854		6818.689		0.977049957x
>> StringIndexOfChar.latin1_SSE4_char	  5657.499		5474.624		0.967675646x
>> StringIndexOfChar.latin1_Short_String	  7132.541		6863.359		0.962260014x
>> StringIndexOfChar.latin1_Short_char	16013.389	      16162.437		1.009307711x
>> StringIndexOfChar.latin1_mixed_String	  7386.123	      14771.622		1.999915517x
>> StringIndexOfChar.latin1_mixed_char	  9901.671		9782.245		0.987938803
>
> Scott Gibbons has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rearrange; add lambdas for clarity

First pass at StringIndexOfHuge.java and IndexOf.java

test/jdk/java/lang/StringBuffer/IndexOf.java line 40:

> 38:   private static boolean failure = false;
> 39:   public static void main(String[] args) throws Exception {
> 40:     String testName = "IndexOf";

intentation

test/jdk/java/lang/StringBuffer/IndexOf.java line 47:

> 45:   char[] haystack_16 = new char[128];
> 46: 
> 47:   for (int i = 0; i < 128; i++) {

you can use `char` instead of `int` as iterator

test/jdk/java/lang/StringBuffer/IndexOf.java line 54:

> 52:   // for (int i = 1; i < 128; i++) {
> 53:   //   haystack_16[i] = (char) (i);
> 54:   // }

dead code

test/jdk/java/lang/StringBuffer/IndexOf.java line 64:

> 62:   Charset hs_charset = StandardCharsets.UTF_16;
> 63:   Charset needleCharset = StandardCharsets.ISO_8859_1;
> 64:   // Charset needleCharset = StandardCharsets.UTF_16;

Move from main() into a function that takes `needleCharset` as a parameter, then call that function twice.

test/jdk/java/lang/StringBuffer/IndexOf.java line 81:

> 79:                 sourceBuffer = new StringBuffer(sourceString);
> 80:                 targetString = generateTestString(10, 11);
> 81:             } while (sourceString.indexOf(targetString) != -1);

Should really keep the original test unmodified and add new tests as needed

test/jdk/java/lang/StringBuffer/IndexOf.java line 83:

> 81:   shs = "$&),,18+-!'8)+";
> 82:   endNeedle = "8)-";
> 83:   l_offset = 9;

dead code

test/jdk/java/lang/StringBuffer/IndexOf.java line 89:

> 87:   StringBuffer bshs = new StringBuffer(shs);
> 88: 
> 89:   // printStringBytes(shs.getBytes(hs_charset));

dead code (and next two comments)

test/jdk/java/lang/StringBuffer/IndexOf.java line 90:

> 88: 
> 89:   // printStringBytes(shs.getBytes(hs_charset));
> 90:   for (int i = 0; i < 200000; i++) {

This wont be a deterministic way to reach the intrinsic. I would suggest copying the idea from test/jdk/com/sun/crypto/provider/Cipher/ChaCha20/unittest/Poly1305UnitTestDriver.java

i.e. Have two `@run main` invocations at the top of this file, one with default parameters, one with  `-Xcomp -XX:-TieredCompilation`. You dont need a 'driver' program, that was to handle something else.


/*
 * @test
 * @modules java.base/com.sun.crypto.provider
 * @run main java.base/com.sun.crypto.provider.Poly1305KAT
 * @summary Unit test for com.sun.crypto.provider.Poly1305.
 */

/*
 * @test
 * @modules java.base/com.sun.crypto.provider
 * @summary Unit test for IntrinsicCandidate in com.sun.crypto.provider.Poly1305.
 * @run main/othervm -Xcomp -XX:-TieredCompilation -XX:+UnlockDiagnosticVMOptions -XX:+ForceUnreachable java.base/com.sun.crypto.provider.Poly1305KAT
 */

test/jdk/java/lang/StringBuffer/IndexOf.java line 126:

> 124:     int aNewLength = getRandomIndex(min, max);
> 125:     for (int y = 0; y < aNewLength; y++) {
> 126:       int achar = generator.nextInt(30) + 30;

This will only ever generate LL cases, i.e. chars from [30,60]. Could be parametrized to also produce utf16 if instead of 30, offset was in the unicode range

test/jdk/java/lang/StringBuffer/IndexOf.java line 199:

> 197:                 System.out.println("Source="+sourceString.substring(hsBegin, hsBegin + haystackLen));
> 198:                 System.out.println("Target="+targetString.substring(nBegin, nBegin + needleLen));
> 199:                 System.out.println("haystackLen="+haystackLen+" neeldeLen="+needleLen+" hsBegin="+hsBegin+" nBegin="+nBegin+

This looks like 'development scaffolding' (i.e. printf debugging) that was meant to be removed

test/jdk/java/lang/StringBuffer/IndexOf.java line 237:

> 235:             + sourceBuffer.toString() + " len Buffer = " + sourceBuffer.toString().length());
> 236:         System.err.println("  naive = " + naiveFind(sourceBuffer.toString(), targetString, 0) + ", IndexOf = "
> 237:             + sourceBuffer.indexOf(targetString));

More tracing left behind here and rest of this function (original just recorded failure and moved along)

test/jdk/java/lang/StringBuffer/IndexOf.java line 284:

> 282: 
> 283:   // Note: it is possible although highly improbable that failCount will
> 284:   // be > 0 even if everthing is working ok

This sounds like either a bug or a testcase bug? Same as line 301, `extremely remote possibility of > 1 match`?

test/jdk/java/lang/StringBuffer/IndexOf.java line 295:

> 293:         sourceString = generateTestString(99, 100);
> 294:         sourceBuffer = new StringBuffer(sourceString);
> 295:         targetString = generateTestString(10, 11);

Generate a random int [0,1,2] for LL, UU, UL, pass that as parameter to generateTestString() to test the other paths. Same for other tests in this file using this pattern.

This test is specific to haystacklen=100, needlelen=10..  what about other haystack/needle sizes to exercise all the paths in the intrinsic assembler (i.e. haystack >=, <=32, needlelen ={1,2,3,4,5..32..}). Elsewhere already?

test/jdk/java/lang/StringBuffer/IndexOf.java line 360:

> 358:         System.err.println("  sAnswer = " + sAnswer + ", sbAnswer = " + sbAnswer);
> 359:         System.err.println("  testString = '" + testString + "'");
> 360:         System.err.println("  testBuffer = '" + testBuffer + "'");

tracing left here and further down

test/micro/org/openjdk/bench/java/lang/StringIndexOfHuge.java line 2:

> 1: /*
> 2:  * Copyright (c) 2014, 2024, Oracle and/or its affiliates. All rights reserved.

New file, just 2024

test/micro/org/openjdk/bench/java/lang/StringIndexOfHuge.java line 81:

> 79:     lateMatchString16 = dataStringHuge16.substring(dataStringHuge16.length() - 31);
> 80: 
> 81:     searchString = "oscar";

Would had liked to see a few more small needles (i.e. to test/verify individual switch statement cases)

test/micro/org/openjdk/bench/java/lang/StringIndexOfHuge.java line 94:

> 92: 
> 93: 
> 94:   /** IndexOf Micros */

Would really had preferred @Param{"LL", "UU", "UL"}; would be easier to spot if there are any copy/paste errors..

test/micro/org/openjdk/bench/java/lang/StringIndexOfHuge.java line 132:

> 130:   @Benchmark
> 131:   public int searchHugeLargeSubstring() {
> 132:       return dataStringHuge.indexOf("B".repeat(30) + "X" + "A".repeat(30), 74);

.repeat() call and string concatenation shouldn't be part of the benchmark (here and several other @Benchmark functions in this file) since it will detract from the measurement.

(String concatenation gets converted (by javac) into StringBuilder().append().append()....append().toString())

test/micro/org/openjdk/bench/java/lang/StringIndexOfHuge.java line 242:

> 240:   @Benchmark
> 241:   public int search16HugeLargeSubstring16() {
> 242:     return dataStringHuge16.indexOf("B".repeat(30) + "X" + "A".repeat(30), 74);

`search16HugeLargeSubstring16` implies UU, but with `"B".repeat(30) + "X" + "A".repeat(30)` is UL

-------------

PR Review: https://git.openjdk.org/jdk/pull/16753#pullrequestreview-2058681000
PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1602136400
PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1602140456
PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1602137044
PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1602158011
PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1602160330
PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1602144091
PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1602147967
PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1602153043
PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1602181943
PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1602162587
PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1602167728
PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1602184697
PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1602198158
PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1602171418
PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1602200123
PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1602133525
PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1602130679
PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1602047091
PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1602115797

From duke at openjdk.org  Wed May 15 20:26:17 2024
From: duke at openjdk.org (Volodymyr Paprotski)
Date: Wed, 15 May 2024 20:26:17 GMT
Subject: RFR: 8320448: Accelerate IndexOf using AVX2 [v19]
In-Reply-To: <aTbnceYj7mQGE4hpCoeUqv5r-W8iHSI_EqVncR0iU_s=.6a63f8c5-eafb-48d5-a871-4cc475e0f63f@github.com>
References: <uWi4QxH31hL93771gkl_GgvP0m84IRSoR_1Yi8hD17E=.bc6ed458-7081-4c3f-9348-f59358fa05a4@github.com>
 <eQ4OBFrF8JlDJ1h9awTDOc0kfCc37IlL5vdqtuaqls0=.8f00616d-08e1-4f28-a7a5-5095116d2595@github.com>
 <aTbnceYj7mQGE4hpCoeUqv5r-W8iHSI_EqVncR0iU_s=.6a63f8c5-eafb-48d5-a871-4cc475e0f63f@github.com>
Message-ID: <Hdnt9LpLSX06Z5-5EnwA0wk-0LsuaNWuzeIkHClsbno=.f7279c56-e175-4b60-b6e2-180f52b245b9@github.com>

On Wed, 15 May 2024 19:21:37 GMT, Volodymyr Paprotski <duke at openjdk.org> wrote:

>> Scott Gibbons has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Rearrange; add lambdas for clarity
>
> test/jdk/java/lang/StringBuffer/IndexOf.java line 47:
> 
>> 45:   char[] haystack_16 = new char[128];
>> 46: 
>> 47:   for (int i = 0; i < 128; i++) {
> 
> you can use `char` instead of `int` as iterator

combine into single loop
haystack[i] = (char) i;
haystack_16[i] = (char) (i + 256);

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1602141543

From david.lloyd at redhat.com  Wed May 15 20:26:11 2024
From: david.lloyd at redhat.com (David Lloyd)
Date: Wed, 15 May 2024 15:26:11 -0500
Subject: [External] : Re: New candidate JEP: 471: Deprecate the
 Memory-Access Methods in sun.misc.Unsafe for Removal
In-Reply-To: <CANghgrThn3gdTBr3W0jzVaA9=g-MudpKyR7WN_cbpgqZ0w2+eQ@mail.gmail.com>
References: <20240503151140.68BE06C9AEE@eggemoggin.niobe.net>
 <CANghgrTUU+eWburseC1cReTgzh1LR96aDCGrCJhVyLwPzxxF9A@mail.gmail.com>
 <990521CB-66E1-45E6-8019-79E2C0BF7FEE@oracle.com>
 <CANghgrRA8B5Bn7gyUs=g3bgVyA1Hjn7dOSiUOZbG7Ad3LCo9dA@mail.gmail.com>
 <835bfb2c-3318-4869-b8ff-6b1d3c1b70ad@oracle.com>
 <CANghgrThn3gdTBr3W0jzVaA9=g-MudpKyR7WN_cbpgqZ0w2+eQ@mail.gmail.com>
Message-ID: <CANghgrSs9h+SALTNgLm=M=kyDMYiZWT9Yn7DVPDhT2UHQKJ3WQ@mail.gmail.com>

On Tue, May 14, 2024 at 10:01?AM David Lloyd <david.lloyd at redhat.com> wrote:

> (Moving to core-libs-dev)
>
> On Tue, May 14, 2024 at 9:40?AM Alan Bateman <Alan.Bateman at oracle.com>
> wrote:
>
>> On 14/05/2024 14:42, David Lloyd wrote:
>>
>> ReflectionFactory allows access to serialization facilities without any
>> access checking (other than the defunct SecurityManager checks). Perhaps
>> this class could gain some more methods, like this:
>>
>> * `newGetterForSerialization(Field field)` - includes ability to access
>> `objectStreamFields` and `serialVersionUID`, or these could be separate
>> methods
>> * `newSetterForSerialziation(Field field)`
>>
>> Does this seem workable?
>>
>> The intention with ReflectionFactory is that serialization libraries go
>> through the readObject/writeObject and other magic methods, to avoid field
>> access.
>>
>> Probably best to being this to core-libs-dev for further discussion.
>>
>
> This doesn't match my recollection. The `readObject` and `writeObject`
> methods are optional private methods which serializable classes *may*
> provide when they want a bespoke serialization strategy (and the other
> methods that are accessed via this special class are similar in this
> regard). They are not in any way magical in that they do not provide the
> means to perform this part of the serialization process, and thus they are
> not a substitute for field access in serialization. According to
> JDK-8164908, these methods were added because at the time, Unsafe was still
> state of the art for custom serialization and IIOP to access fields (with
> libraries using Field actively moving to Unsafe instead). However Unsafe
> did not and does not provide access to methods, so in order to avoid the
> aforementioned `add-opens` explosion, these methods were added as a
> compromise. Now that Unsafe is being deprecated, it is my opinion that this
> does need to be revisited because at the time, Unsafe was the recommended
> approach.
>
> [1] https://bugs.openjdk.org/browse/JDK-8164908
>
It seems to me that it might be a good idea (as part of 8305968 (Integrity
by default)) to put the `ReflectionFactory` API behind a restricted method
call somehow, even considered separately from the changes suggested above.
Maybe in conjunction with a non-standard switch that works similarly to
`--enable-native-access`, e.g.
`--enable-serialization=org.serial.framework`? That would also somewhat
mitigate the security risk of adding the aforementioned methods or
something like them to this class.

Should I open a bug for either (or both) of these suggestions? Or perhaps
there is a better way to proceed?

-- 
- DML ? he/him
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240515/2550ae94/attachment.htm>

From sviswanathan at openjdk.org  Wed May 15 21:13:13 2024
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Wed, 15 May 2024 21:13:13 GMT
Subject: RFR: 8320448: Accelerate IndexOf using AVX2 [v19]
In-Reply-To: <eQ4OBFrF8JlDJ1h9awTDOc0kfCc37IlL5vdqtuaqls0=.8f00616d-08e1-4f28-a7a5-5095116d2595@github.com>
References: <uWi4QxH31hL93771gkl_GgvP0m84IRSoR_1Yi8hD17E=.bc6ed458-7081-4c3f-9348-f59358fa05a4@github.com>
 <eQ4OBFrF8JlDJ1h9awTDOc0kfCc37IlL5vdqtuaqls0=.8f00616d-08e1-4f28-a7a5-5095116d2595@github.com>
Message-ID: <q_TqQXOtq10l5YQ4ifLqf6Vd4f5xb02ALFfSdcZXlDU=.ed7a3a46-952b-47d2-a7fe-97933bc174e9@github.com>

On Sat, 4 May 2024 19:35:21 GMT, Scott Gibbons <sgibbons at openjdk.org> wrote:

>> Re-write the IndexOf code without the use of the pcmpestri instruction, only using AVX2 instructions.  This change accelerates String.IndexOf on average 1.3x for AVX2.  The benchmark numbers:
>> 
>> 
>> Benchmark	                                               Score		Latest		
>> StringIndexOf.advancedWithMediumSub   343.573		317.934		0.925375393x
>> StringIndexOf.advancedWithShortSub1	  1039.081		1053.96		1.014319384x
>> StringIndexOf.advancedWithShortSub2	      55.828		110.541		1.980027943x
>> StringIndexOf.constantPattern	                9.361		11.906		1.271872663x
>> StringIndexOf.searchCharLongSuccess	        4.216		4.218		1.000474383x
>> StringIndexOf.searchCharMediumSuccess	3.133		3.216		1.02649218x
>> StringIndexOf.searchCharShortSuccess	3.76		        3.761		1.000265957x
>> StringIndexOf.success	                                9.186		9.713		1.057369911x
>> StringIndexOf.successBig	                      14.341		46.343		3.231504079x
>> StringIndexOfChar.latin1_AVX2_String	  6220.918		12154.52		1.953814533x
>> StringIndexOfChar.latin1_AVX2_char	  5503.556		5540.044		1.006629895x
>> StringIndexOfChar.latin1_SSE4_String	  6978.854		6818.689		0.977049957x
>> StringIndexOfChar.latin1_SSE4_char	  5657.499		5474.624		0.967675646x
>> StringIndexOfChar.latin1_Short_String	  7132.541		6863.359		0.962260014x
>> StringIndexOfChar.latin1_Short_char	16013.389	      16162.437		1.009307711x
>> StringIndexOfChar.latin1_mixed_String	  7386.123	      14771.622		1.999915517x
>> StringIndexOfChar.latin1_mixed_char	  9901.671		9782.245		0.987938803
>
> Scott Gibbons has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rearrange; add lambdas for clarity

src/hotspot/cpu/x86/stubGenerator_x86_64_string.cpp line 1476:

> 1474:                                _masm);
> 1475: 
> 1476:   __ movq(r11, -1);

There doesn't seem to be a use of r11 below in this function.

src/hotspot/cpu/x86/stubGenerator_x86_64_string.cpp line 1493:

> 1491:   // Assume r10 is n - k
> 1492:   __ leaq(last, Address(haystack, r10, Address::times_1, isU ? -30 : -31));
> 1493:   __ jmpb(temp);

Need to pass r10 as parameter. Also temp label could be given a better name.

src/hotspot/cpu/x86/stubGenerator_x86_64_string.cpp line 1502:

> 1500: 
> 1501:   __ cmpq(hsPtrRet, last);
> 1502:   __ cmovq(Assembler::aboveEqual, hsPtrRet, last);

cmovq is expensive, better sequence would be:

__ cmpq(hsPtrRet, last);
__ jb_b(temp);
__ movq(hsPtrRet, last);

src/hotspot/cpu/x86/stubGenerator_x86_64_string.cpp line 1510:

> 1508:   compare_big_haystack_to_needle(sizeKnown, size, NUMBER_OF_NEEDLE_BYTES_TO_COMPARE, loop_top, hsPtrRet, hsLength,
> 1509:                                  needleLen, isU, DO_EARLY_BAILOUT, eq_mask, temp2, r10, _masm);
> 1510: 

At this point hsLength is not the remaining length from hsPtrRet, would that cause a problem? If not, all the special paths in compare_big_haystack_to_needle need not be generated on this call.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1602016421
PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1601943761
PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1602251994
PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1602010926

From romanowski.mateusz at gmail.com  Wed May 15 22:19:41 2024
From: romanowski.mateusz at gmail.com (Mateusz Romanowski)
Date: Thu, 16 May 2024 00:19:41 +0200
Subject: Generalizing binary search
In-Reply-To: <0B6F859C-1B4C-4FCD-87CA-82B2A5072C99@oracle.com>
References: <CANghgrR9d524yo7pPKNmvG_LU0hzxrFhQZZPdC1TF7Y_Q_rMeA@mail.gmail.com>
 <0B6F859C-1B4C-4FCD-87CA-82B2A5072C99@oracle.com>
Message-ID: <CAL-BTSqMmDvnQA7EUuFj-Ob8tmTuSs9yM=5c=rWt+3qj1N0XFw@mail.gmail.com>

Hi,
I would say it is not worth any effort.

One can easily write an ad-hoc *local* adapter extending
`java.util.AbstractList`..
.. and immediately invoke existing `java.util.Collections::binarySearch`
method.

Cheers,
MR

On Thu, Apr 25, 2024 at 9:09?PM Pavel Rappo <pavel.rappo at oracle.com> wrote:

>
>
> > On 25 Apr 2024, at 19:41, David Lloyd <david.lloyd at redhat.com> wrote:
> >
> > The JDK contains a few collection- and array-oriented implementations of
> binary search. For the most part, they all work the same way: search the
> target "thing" by index using the obvious bisection strategy, returning
> either /index/ or /-index-1/ depending on whether it was found at the end
> of the search.
> >
> > However, if you're doing a binary search on a thing that is not a list
> or an array, you have two choices: try to make the thing you're searching
> on implement List (often infeasible) or write your own binary search.
> >
> > I'm really tired of writing my own binary search. I've probably done it
> 50 times by now, each one using a slightly different access and/or compare
> strategy, and every time is a new chance to typo something or get something
> backwards, leading to irritating debugging sessions and higher dentist
> bills.
>
> Can we safely say that it sets your teeth on edge?
>
> > It got me to thinking that it wouldn't be too hard to make a "general"
> binary search which can search on anything, so that's what I did. I was
> thinking that it might be interesting to try adding this into the JDK
> somehow.
> >
> > This implementation is more or less what I now copy & paste to different
> projects at the moment:
> >
> >     public static <C, T> int binarySearch(C collection, int start, int
> end, T key, Comparator<? super T> cmp, IntGetter<C, T> getter) {
> >         int low = start;
> >         int high = end - 1;
> >         while (low <= high) {
> >             int mid = low + high >>> 1;
> >             int res = cmp.compare(getter.get(collection, mid), key);
> >             if (res < 0) {
> >                 low = mid + 1;
> >             } else if (res > 0) {
> >                 high = mid - 1;
> >             } else {
> >                 return mid;
> >             }
> >         }
> >         return -low - 1;
> >     }
> >     // (Plus variations for `Comparable` keys and long indices)
> >
> > A key problem with this approach is that in the JDK, there is no
> `ObjIntFunction<T, R>` or `ObjLongFunction<T, R>` which would be necessary
> to implement the "getter" portion of the algorithm (despite the existence
> of the analogous `ObjIntConsumer<T>` and `ObjLongConsumer<T>`). So, I also
> have to copy/paste a `IntGetter<T, R>`/`LongGetter<T, R>` as well, which is
> annoying.
> >
> > A slightly less-good approach is for the general `binarySearch` method
> to accept a `IntFunction<T>`/`LongFunction<T>`, and drop the `C collection`
> parameter, like this:
> >
> >     public static <T> int binarySearch(int start, int end, T key,
> Comparator<? super T> cmp, IntFunction<T> getter) { ... }
> >
> > In this case, we can use the function types that the JDK already
> provides, but we would very likely have to also create a capturing lambda
> (e.g. `myList::get` instead of `List::get`). Maybe this isn't that bad of a
> compromise.
> >
> > It would be possible to replace the existing `binarySearch`
> implementations with delegating calls to a generalized implementation. For
> `Collections`, the indexed version uses `List::get` and the iterator
> version uses a helper lambda to move the iterator and get the result. For
> arrays, a lambda would be provided which gets the corresponding array
> element. If the non-capturing variant is used, then (on paper at least)
> this version should perform similarly to the existing implementations, with
> less code needed overall. However, if a capturing lambda is required (due
> to the aforementioned lack of `ObjXFunction`), then this could be slightly
> worse-performing than the existing implementation due to the construction
> (and maybe dispatch) overhead of the lambda. Some real-world benchmarks
> would have to be written with various-sized data sets.
> >
> > It would also be possible to produce primitive variations which operate
> on int, float, long, and double values, using existing functions if
> capturing is deemed "OK". It is also possible to produce a variation which
> uses a `long` for the index, for huge data sets (for example, very large
> mapped files using `MemorySegment`).
> >
> > Also unclear is: where would it live? `Collections`? Somewhere else?
> >
> > Any thoughts/opinions would be appreciated (even if they are along the
> lines of "it's not worth the effort"). Particularly, any insight would be
> appreciated as to whether or not this kind of hypothetical enhancement
> would warrant a JEP (I wouldn't think so, but I'm no expert at such
> assessments).
> >
> > --
> > - DML ? he/him
>
> Have a look at this recently filed issue:
> https://bugs.openjdk.org/browse/JDK-8326330
>
> -Pavel
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240516/2d39b3ea/attachment-0001.htm>

From lowasser at google.com  Wed May 15 22:27:43 2024
From: lowasser at google.com (Louis Wasserman)
Date: Wed, 15 May 2024 15:27:43 -0700
Subject: Generalizing binary search
In-Reply-To: <CAL-BTSqMmDvnQA7EUuFj-Ob8tmTuSs9yM=5c=rWt+3qj1N0XFw@mail.gmail.com>
References: <CANghgrR9d524yo7pPKNmvG_LU0hzxrFhQZZPdC1TF7Y_Q_rMeA@mail.gmail.com>
 <0B6F859C-1B4C-4FCD-87CA-82B2A5072C99@oracle.com>
 <CAL-BTSqMmDvnQA7EUuFj-Ob8tmTuSs9yM=5c=rWt+3qj1N0XFw@mail.gmail.com>
Message-ID: <CAGB9EW8t3i6kFc=OeLr7oRrjVezW7q_fWuYgA4cP0VYT5ffhfg@mail.gmail.com>

If you forget to implement RandomAccess, you'll get a very subtle
performance bug.

Just because it's easy if you know how to do it doesn't make it easy for a
random developer to do correctly.

On Wed, May 15, 2024 at 3:21?PM Mateusz Romanowski <
romanowski.mateusz at gmail.com> wrote:

> Hi,
> I would say it is not worth any effort.
>
> One can easily write an ad-hoc *local* adapter extending
> `java.util.AbstractList`..
> .. and immediately invoke existing `java.util.Collections::binarySearch`
> method.
>
> Cheers,
> MR
>
> On Thu, Apr 25, 2024 at 9:09?PM Pavel Rappo <pavel.rappo at oracle.com>
> wrote:
>
>>
>>
>> > On 25 Apr 2024, at 19:41, David Lloyd <david.lloyd at redhat.com> wrote:
>> >
>> > The JDK contains a few collection- and array-oriented implementations
>> of binary search. For the most part, they all work the same way: search the
>> target "thing" by index using the obvious bisection strategy, returning
>> either /index/ or /-index-1/ depending on whether it was found at the end
>> of the search.
>> >
>> > However, if you're doing a binary search on a thing that is not a list
>> or an array, you have two choices: try to make the thing you're searching
>> on implement List (often infeasible) or write your own binary search.
>> >
>> > I'm really tired of writing my own binary search. I've probably done it
>> 50 times by now, each one using a slightly different access and/or compare
>> strategy, and every time is a new chance to typo something or get something
>> backwards, leading to irritating debugging sessions and higher dentist
>> bills.
>>
>> Can we safely say that it sets your teeth on edge?
>>
>> > It got me to thinking that it wouldn't be too hard to make a "general"
>> binary search which can search on anything, so that's what I did. I was
>> thinking that it might be interesting to try adding this into the JDK
>> somehow.
>> >
>> > This implementation is more or less what I now copy & paste to
>> different projects at the moment:
>> >
>> >     public static <C, T> int binarySearch(C collection, int start, int
>> end, T key, Comparator<? super T> cmp, IntGetter<C, T> getter) {
>> >         int low = start;
>> >         int high = end - 1;
>> >         while (low <= high) {
>> >             int mid = low + high >>> 1;
>> >             int res = cmp.compare(getter.get(collection, mid), key);
>> >             if (res < 0) {
>> >                 low = mid + 1;
>> >             } else if (res > 0) {
>> >                 high = mid - 1;
>> >             } else {
>> >                 return mid;
>> >             }
>> >         }
>> >         return -low - 1;
>> >     }
>> >     // (Plus variations for `Comparable` keys and long indices)
>> >
>> > A key problem with this approach is that in the JDK, there is no
>> `ObjIntFunction<T, R>` or `ObjLongFunction<T, R>` which would be necessary
>> to implement the "getter" portion of the algorithm (despite the existence
>> of the analogous `ObjIntConsumer<T>` and `ObjLongConsumer<T>`). So, I also
>> have to copy/paste a `IntGetter<T, R>`/`LongGetter<T, R>` as well, which is
>> annoying.
>> >
>> > A slightly less-good approach is for the general `binarySearch` method
>> to accept a `IntFunction<T>`/`LongFunction<T>`, and drop the `C collection`
>> parameter, like this:
>> >
>> >     public static <T> int binarySearch(int start, int end, T key,
>> Comparator<? super T> cmp, IntFunction<T> getter) { ... }
>> >
>> > In this case, we can use the function types that the JDK already
>> provides, but we would very likely have to also create a capturing lambda
>> (e.g. `myList::get` instead of `List::get`). Maybe this isn't that bad of a
>> compromise.
>> >
>> > It would be possible to replace the existing `binarySearch`
>> implementations with delegating calls to a generalized implementation. For
>> `Collections`, the indexed version uses `List::get` and the iterator
>> version uses a helper lambda to move the iterator and get the result. For
>> arrays, a lambda would be provided which gets the corresponding array
>> element. If the non-capturing variant is used, then (on paper at least)
>> this version should perform similarly to the existing implementations, with
>> less code needed overall. However, if a capturing lambda is required (due
>> to the aforementioned lack of `ObjXFunction`), then this could be slightly
>> worse-performing than the existing implementation due to the construction
>> (and maybe dispatch) overhead of the lambda. Some real-world benchmarks
>> would have to be written with various-sized data sets.
>> >
>> > It would also be possible to produce primitive variations which operate
>> on int, float, long, and double values, using existing functions if
>> capturing is deemed "OK". It is also possible to produce a variation which
>> uses a `long` for the index, for huge data sets (for example, very large
>> mapped files using `MemorySegment`).
>> >
>> > Also unclear is: where would it live? `Collections`? Somewhere else?
>> >
>> > Any thoughts/opinions would be appreciated (even if they are along the
>> lines of "it's not worth the effort"). Particularly, any insight would be
>> appreciated as to whether or not this kind of hypothetical enhancement
>> would warrant a JEP (I wouldn't think so, but I'm no expert at such
>> assessments).
>> >
>> > --
>> > - DML ? he/him
>>
>> Have a look at this recently filed issue:
>> https://bugs.openjdk.org/browse/JDK-8326330
>>
>> -Pavel
>>
>>
>>

-- 
Louis Wasserman (he/they)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240515/cedf0731/attachment.htm>

From jpai at openjdk.org  Thu May 16 01:21:12 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 16 May 2024 01:21:12 GMT
Subject: RFR: 8331879: Clean up non-standard use of /// comments in
 `java.base`
In-Reply-To: <Lpd-uBwG8xZoG9WbPKfUawFKRfKrA1RfQ7XzKrY4qHQ=.e23104ab-d47a-4a55-b2bd-fb7b94e9a10f@github.com>
References: <JKCovwpov4A3Uddzf6N0AnZSb3Znv-7MEfMGec6IhR4=.93e4ad8e-344b-4890-8f25-c2752287024c@github.com>
 <Lpd-uBwG8xZoG9WbPKfUawFKRfKrA1RfQ7XzKrY4qHQ=.e23104ab-d47a-4a55-b2bd-fb7b94e9a10f@github.com>
Message-ID: <GfFsB48XevdlJBSIFX8CK_M8OgKKxx_kVego59I_Bbo=.00239e99-8e9f-41c4-b7db-78e3e11c56db@github.com>

On Fri, 10 May 2024 01:25:45 GMT, xiaotaonan <duke at openjdk.org> wrote:

>> Clean up non-standard use of /// comments in `java.base`
>
> @mdinacci @hns  @landonf

Hello @xiaotaonan, like Jon noted in his comment, there's already another PR addressing this change. So I think this current PR can be closed.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19151#issuecomment-2113730374

From liangchenblue at gmail.com  Thu May 16 02:00:11 2024
From: liangchenblue at gmail.com (-)
Date: Wed, 15 May 2024 21:00:11 -0500
Subject: [External] : Re: New candidate JEP: 471: Deprecate the
 Memory-Access Methods in sun.misc.Unsafe for Removal
In-Reply-To: <CANghgrSs9h+SALTNgLm=M=kyDMYiZWT9Yn7DVPDhT2UHQKJ3WQ@mail.gmail.com>
References: <20240503151140.68BE06C9AEE@eggemoggin.niobe.net>
 <CANghgrTUU+eWburseC1cReTgzh1LR96aDCGrCJhVyLwPzxxF9A@mail.gmail.com>
 <990521CB-66E1-45E6-8019-79E2C0BF7FEE@oracle.com>
 <CANghgrRA8B5Bn7gyUs=g3bgVyA1Hjn7dOSiUOZbG7Ad3LCo9dA@mail.gmail.com>
 <835bfb2c-3318-4869-b8ff-6b1d3c1b70ad@oracle.com>
 <CANghgrThn3gdTBr3W0jzVaA9=g-MudpKyR7WN_cbpgqZ0w2+eQ@mail.gmail.com>
 <CANghgrSs9h+SALTNgLm=M=kyDMYiZWT9Yn7DVPDhT2UHQKJ3WQ@mail.gmail.com>
Message-ID: <CABe8uE30tPcp9nTjN+ZAwaQ5Pyj_6eizaa2RPJw-c7rNf9WfVw@mail.gmail.com>

Indeed, ReflectionFactory. newConstructorForSerialization can be used to
access otherwise-private constructors. Before JDK-8315810, it could even
allocate one class and call the constructor of another class.

I strongly support your proposal to restrict ReflectionFactory.

Regards, Chen

On Wed, May 15, 2024 at 6:23?PM David Lloyd <david.lloyd at redhat.com> wrote:

>
>
> On Tue, May 14, 2024 at 10:01?AM David Lloyd <david.lloyd at redhat.com>
> wrote:
>
>> (Moving to core-libs-dev)
>>
>> On Tue, May 14, 2024 at 9:40?AM Alan Bateman <Alan.Bateman at oracle.com>
>> wrote:
>>
>>> On 14/05/2024 14:42, David Lloyd wrote:
>>>
>>> ReflectionFactory allows access to serialization facilities without any
>>> access checking (other than the defunct SecurityManager checks). Perhaps
>>> this class could gain some more methods, like this:
>>>
>>> * `newGetterForSerialization(Field field)` - includes ability to access
>>> `objectStreamFields` and `serialVersionUID`, or these could be separate
>>> methods
>>> * `newSetterForSerialziation(Field field)`
>>>
>>> Does this seem workable?
>>>
>>> The intention with ReflectionFactory is that serialization libraries go
>>> through the readObject/writeObject and other magic methods, to avoid field
>>> access.
>>>
>>> Probably best to being this to core-libs-dev for further discussion.
>>>
>>
>> This doesn't match my recollection. The `readObject` and `writeObject`
>> methods are optional private methods which serializable classes *may*
>> provide when they want a bespoke serialization strategy (and the other
>> methods that are accessed via this special class are similar in this
>> regard). They are not in any way magical in that they do not provide the
>> means to perform this part of the serialization process, and thus they are
>> not a substitute for field access in serialization. According to
>> JDK-8164908, these methods were added because at the time, Unsafe was still
>> state of the art for custom serialization and IIOP to access fields (with
>> libraries using Field actively moving to Unsafe instead). However Unsafe
>> did not and does not provide access to methods, so in order to avoid the
>> aforementioned `add-opens` explosion, these methods were added as a
>> compromise. Now that Unsafe is being deprecated, it is my opinion that this
>> does need to be revisited because at the time, Unsafe was the recommended
>> approach.
>>
>> [1] https://bugs.openjdk.org/browse/JDK-8164908
>>
> It seems to me that it might be a good idea (as part of 8305968 (Integrity
> by default)) to put the `ReflectionFactory` API behind a restricted method
> call somehow, even considered separately from the changes suggested above.
> Maybe in conjunction with a non-standard switch that works similarly to
> `--enable-native-access`, e.g.
> `--enable-serialization=org.serial.framework`? That would also somewhat
> mitigate the security risk of adding the aforementioned methods or
> something like them to this class.
>
> Should I open a bug for either (or both) of these suggestions? Or perhaps
> there is a better way to proceed?
>
> --
> - DML ? he/him
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240515/5d86221d/attachment-0001.htm>

From iklam at openjdk.org  Thu May 16 02:42:35 2024
From: iklam at openjdk.org (Ioi Lam)
Date: Thu, 16 May 2024 02:42:35 GMT
Subject: RFR: 8332340: Add JavacBench as a test case for CDS
Message-ID: <xqD4PeVZfIAKzywbLnjGZMFh36YSqXNolZkTgh1Vk6E=.44db7c57-64c1-4912-96e1-e61848312ccb@github.com>

JavacBench is a test program that compiles 90 Java source files. It uses a fair amount of invokedynamic callsites, so it's good for testing CDS support for indy and lambda expressions.

This test was first integrated into the [leyden](https://github.com/openjdk/leyden/tree/premain) repo. Hence some of the files have copyrights in 2023.

-------------

Commit messages:
 - 8332340: Add JavacBench as a test case for CDS

Changes: https://git.openjdk.org/jdk/pull/19256/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19256&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8332340
  Stats: 592 lines in 4 files changed: 592 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/19256.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19256/head:pull/19256

PR: https://git.openjdk.org/jdk/pull/19256

From liach at openjdk.org  Thu May 16 03:35:05 2024
From: liach at openjdk.org (Chen Liang)
Date: Thu, 16 May 2024 03:35:05 GMT
Subject: RFR: 8332340: Add JavacBench as a test case for CDS
In-Reply-To: <xqD4PeVZfIAKzywbLnjGZMFh36YSqXNolZkTgh1Vk6E=.44db7c57-64c1-4912-96e1-e61848312ccb@github.com>
References: <xqD4PeVZfIAKzywbLnjGZMFh36YSqXNolZkTgh1Vk6E=.44db7c57-64c1-4912-96e1-e61848312ccb@github.com>
Message-ID: <Gt9UtQuINe4KgXoXvmJNxq8M_EMXTeQxd1kENvfO3Io=.26ac30de-513f-4ff6-974c-79a49f4f00a4@github.com>

On Thu, 16 May 2024 02:37:02 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> JavacBench is a test program that compiles 90 Java source files. It uses a fair amount of invokedynamic callsites, so it's good for testing CDS support for indy and lambda expressions.
> 
> This test was first integrated into the [leyden](https://github.com/openjdk/leyden/tree/premain) repo. Hence some of the files have copyrights in 2023.

test/lib/jdk/test/lib/StringArrayUtils.java line 33:

> 31:     }
> 32: 
> 33:     public static String[] concat(String prefix[], String... extra) {

Suggestion:

    public static String[] concat(String[] prefix, String... extra) {

test/lib/jdk/test/lib/StringArrayUtils.java line 42:

> 40:         }
> 41: 
> 42:         return list.toArray(new String[list.size()]);

I thought we have been preferring ot use `new String[0]` for toArray calls. Also for simplicity, we can change the implementation to:

var list = new ArrayList<>(Arrays.asList(prefix));
Collections.addAll(list, extra);
return list.toArray(new String[0]);

or for performance:

String[] ret = new String[prefix.length + extra.length];
System.arraycopy(prefix, 0, ret, 0, prefix.length);
System.arraycopy(extra, 0, ret, prefix.length, extra.length);
return ret;

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19256#discussion_r1602560570
PR Review Comment: https://git.openjdk.org/jdk/pull/19256#discussion_r1602561754

From liangchenblue at gmail.com  Thu May 16 03:52:03 2024
From: liangchenblue at gmail.com (-)
Date: Wed, 15 May 2024 22:52:03 -0500
Subject: Deterministic naming of subclasses of `java/lang/reflect/Proxy`
In-Reply-To: <bf26eb2f74874e02876b3868311922a9@kth.se>
References: <bf26eb2f74874e02876b3868311922a9@kth.se>
Message-ID: <CABe8uE0fk71Xy_PYHikSw9OtXE_i+M9zMbayPEXuTxLWLoy2ag@mail.gmail.com>

Hi Aman,
I think you meant CVE-2021-42392 instead of 2022.

For your approach of an "allowlist" for Java runtime, project Leyden is
looking to generate a static image [1], that
> At run time it cannot load classes from outside the image, nor can it
create classes dynamically.
Leyden mainly avoids this unstable generation by performing a training run
to collect classes loaded and even object graphs; I am not familiar with
the details unfortunately.

Otherwise, the Proxy discussion belongs better to core-libs-dev, as
java.lang.reflect.Proxy is part of Java's core libraries. I am replying
this thread to core-libs-dev.

For your perceived problem that classes don't have unique names, your
description sounds dubious: GeneratedConstructorAccessor is already retired
by JEP 416 [2] in Java 18, and there are many other cases in which JDK
generates classes without stable names, notoriously LambdaMetafactory
(Gradle wished for cacheable Lambdas); the same applies for the generated
classes for MethodHandle's LambdaForms (which carries implementation code
for LambdaForm). How are you checking the classes? It seems you are not
checking hidden classes. Proxy and Lambda classes are defined by the
caller's class loader, while LambdaForms are under JDK's system class
loader I think. We need to ensure you are correctly finding all unstable
classes before we can proceed.

[1]: https://openjdk.org/projects/leyden/notes/01-beginnings
[2]: https://openjdk.org/jeps/416

On Wed, May 15, 2024 at 7:00?PM Aman Sharma <amansha at kth.se> wrote:

> Hi,
>
>
> My name is Aman and I am a PhD student at KTH Royal Institute of
> Technology, Stockholm, Sweden. I research as part of CHAINS
> <https://chains.proj.kth.se/> project to strengthen the software supply
> chain of multiple ecosystem. I particularly focus on runtime integrity in
> Java. In this email, I want to write about an issue I have discovered with *dynamic
> generation of `java.lang.reflect.Proxy`classes*. I will propose a
> solution and would love to hear the feedback from the community. Let me
> know if this is the correct mailing-list for such discussions. It seemed
> the most relevant from this list
> <https://mail.openjdk.org/mailman/listinfo>.
>
>
> *My research*
>
>
> Java has features to load class on the fly - it can either download or
> generate a class at runtime. These features are useful for inner workings
> of JDK. For example, implementing annotations, reflective access, etc.
> However, these features have also contributed to critical vulnerabilities
> in the past - CVE-2021-44228  (log4shell), CVE-2022-33980, CVE-2022-42392.
> All of these vulnerabilities have one thing in common - *a class that was
> not known during build time was downloaded/generated at runtime and loaded
> into JVM.*
>
>
> To defend against such vulnerabilities, we propose a solution to *allowlist
> classes for runtime*. This allowlist will contain an exhaustive list of
> classes that can be loaded by the JVM and it will be enforced at runtime.
> We build this allowlist from three sources:
>
>    1. All classes of all modules provided by the Java Standard Library.
>    We use ClassGraph <https://github.com/classgraph/classgraph> to scan
>    the JDK.
>    2. We can take the source code and all dependencies of an application.
>    We use a software bill of materials to get all the data.
>    3. Finally, we use run the test suite to include any runtime
>    downloaded/generated classes.
>
> Such a list is able to prevent the above 3 CVEs because it does not let
> the "unknown" bytecode to be loaded.
>
> *Problem with generating such an allowlist*
>
> The first two parts of the allowlist are easy to get. The problem is with
> the third step where we want to allowlist all the classes that could be
> downloaded or generated. Upon running the test suite and hooking to the
> classes it loads, we observer that the list consists of classes that are
> called "com/sun/proxy/$Proxy2", "
> jdk/internal/reflect/GeneratedConstructorAccessor3" among many more. The
> purpose of these classes can be identifed. The proxy class is created for
> to implement an annotation. The accessor gives access to constructor of a
> class to the JVM.
>
> When enforcing this allowlist at runtime, we see that the bytecode content
> for "com/sun/proxy/$Proxy2" differs in the allowlist and at runtime. In
> our case, we we are experimenting with pdfbox
> <https://github.com/apache/pdfbox> so we created the allowlist using its
> test suite. Then we enforced this allowlist while running some of its
> subcommands. However, there was some other proxy class say "com/sun/proxy/$Proxy5"
> at runtime that implemented the same interfaces and had the same methods as
> "com/sun/proxy/$Proxy2" in the allowlist. They only differed in the name
> of the class, order of fields, and types for fields references. This could
> happen because the order of the loading of class is workload dependent, but
> it causes problem to generate such an allowlist.
>
>
> *Solution *
>
>
> We propose that naming of subclasses of "java/lang/reflect/Proxy" should
> not be dependent upon the order of loading. In order to do so, two issues
> can be fixed:
>
>    1. The naming of the class should not be based on AtomicLong
>    <https://github.com/openjdk/jdk/blob/b687aa550837830b38f0f0faa69c353b1e85219c/src/java.base/share/classes/java/lang/reflect/Proxy.java#L531>
>    <https://github.com/openjdk/jdk/blob/4083255440cfbf39b9683ea88a433d71ec6111e7/src/java.base/share/classes/java/lang/reflect/Proxy.java#L531>.
>    Rather it could be named based on the interfaces it implements. I also
>    wonder why AtomicLong is chosen in the first place.
>    2. Methods of the interfaces must be in a particular order. Right now, they
>    are not sorted in any particular order
>    <https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/lang/Class.java#L2178>
>    .
>
>
> These fixes will make proxy class generation deterministic with respect to
> order of loading and won't be flagged at runtime since the test suite would
> already detect them.
>
> I would love to hear from the community about these ideas. If in
> agreement, I would be happy to produce a patch. I have discovered this
> issue with subclasses of GeneratedConstructorAccessor
> <https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/jdk/internal/reflect/ConstructorAccessor.java>
> as well and I imagine it will also apply to some other runtime generated
> classes. If you disagree, please let me know also. It helps with my
> research.
>
> I also have PoCs for the above CVEs
> <https://github.com/chains-project/exploits-for-sbom.exe> and a proof
> concept tool is being developed under the name sbom.exe
> <https://github.com/chains-project/sbom.exe> in case any one wonders
> about the implementation. I would also be happy to explain more.
>
> Regards,
> Aman Sharma
>
> PhD Student
> KTH Royal Institute of Technology
> School of Electrical Engineering and Computer Science (EECS)
> Department of Theoretical Computer Science (TCS)
> <http://www.kth.se> <https://www.kth.se/profile/amansha>
> <https://www.kth.se/profile/amansha>
> <https://www.kth.se/profile/amansha>https://algomaster99.github.io/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240515/08e6930b/attachment-0001.htm>

From asotona at openjdk.org  Thu May 16 06:49:23 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Thu, 16 May 2024 06:49:23 GMT
Subject: RFR: 8321622: ClassFile.verify(byte[] bytes) throws unexpected
 ConstantPoolException, IAE
Message-ID: <Z4hjpgfy3d2G-sXcN3hnIJnvY5mUdKkT0ipYwcnyIs0=.c43fe071-ace7-4d56-a25f-badc45dc24eb@github.com>

Class-File API `VerifierImpl` contains debugging stack trace print causing unexpected output and confusion in specific verification cases.

This patch removes the stack trace print.

Please review.

Thanks,
Adam

-------------

Commit messages:
 - 8321622: ClassFile.verify(byte[] bytes) throws unexpected ConstantPoolException, IAE

Changes: https://git.openjdk.org/jdk/pull/19258/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19258&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8321622
  Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/19258.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19258/head:pull/19258

PR: https://git.openjdk.org/jdk/pull/19258

From pminborg at openjdk.org  Thu May 16 06:58:06 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 16 May 2024 06:58:06 GMT
Subject: RFR: 8330465: Stable Values and Collections (Internal) [v5]
In-Reply-To: <hfCAtNQs4eEApF71b4FKsHWQwl20eYeURk_AljjT-q0=.6753684c-6275-4db5-99ca-b1190fbe5b95@github.com>
References: <-KSimQo5kkmCzzMShqGe5QZ9yCSzpWL98gN13v4wP0k=.11dd8d06-18a6-4577-8342-66632cea0b6e@github.com>
 <VGuyX6AyE1gAq2nsCLIyOxnHbYbAAW8YvKk8mAjKnos=.c5ea169b-dfba-4ac8-8e91-7d897708ea5d@github.com>
 <sWc2qReuqEhBnu0fHIg75bC8WJkp56HSO9x807NgZoA=.2041706f-383d-44d0-93c6-2eda82329869@github.com>
 <hfCAtNQs4eEApF71b4FKsHWQwl20eYeURk_AljjT-q0=.6753684c-6275-4db5-99ca-b1190fbe5b95@github.com>
Message-ID: <_G7nE_OAMl9WSkAz21UDYHAlCRVeHN2ZmM0FR7Bmxtw=.ea94e982-3e9a-4c0e-8523-11372474d497@github.com>

On Wed, 15 May 2024 18:45:16 GMT, ExE Boss <duke at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/lang/stable/StableValueImpl.java line 104:
>> 
>>> 102:         // Optimistically try plain semantics first
>>> 103:         final V v = value;
>>> 104:         if (v != null) {
>> 
>> If `value == null && state == NULL`, can the path still be constant folded? I doubt it because `value` in this case may not be promoted to constant.
>
> Maybe the?`state?==?NULL` check should?be?moved before?`v?!=?null`, as?the?**JIT** doesn?t?constant?fold `null`?[`@Stable`]?values:
> https://github.com/openjdk/jdk/blob/8a4315f833f3700075d65fae6bc566011c837c07/src/java.base/share/classes/jdk/internal/vm/annotation/Stable.java#L41-L44  https://github.com/openjdk/jdk/blob/8a4315f833f3700075d65fae6bc566011c837c07/src/java.base/share/classes/jdk/internal/vm/annotation/Stable.java#L64-L71
> 
> [`@Stable`]: https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/jdk/internal/vm/annotation/Stable.java

It seems reasonable to assume `null` values are not constant-folded. For straight-out-of-the-box usage, there is no apparent significant difference as indicated by a new benchmark I just added:


Benchmark                                  Mode  Cnt      Score      Error   Units
StableStaticBenchmark.atomic              thrpt   10   5729.683 ?  502.023  ops/us
StableStaticBenchmark.dcl                 thrpt   10   6069.222 ?  951.784  ops/us
StableStaticBenchmark.dclHolder           thrpt   10   5502.102 ? 1630.627  ops/us
StableStaticBenchmark.stable              thrpt   10  12737.158 ? 1746.456  ops/us <- Non-null benchmark
StableStaticBenchmark.stableHolder        thrpt   10  12053.978 ? 1421.527  ops/us
StableStaticBenchmark.stableList          thrpt   10  12443.870 ? 2084.607  ops/us
StableStaticBenchmark.stableNull          thrpt   10  13164.232 ?  591.284  ops/us <- Added null benchmark
StableStaticBenchmark.stableRecordHolder  thrpt   10  13638.893 ? 1250.895  ops/us
StableStaticBenchmark.staticCHI           thrpt   10  13639.220 ? 1190.922  ops/us


If the `null` value participates in a much larger constant-folding tree, there might be a significant difference. I was afraid moving the order would have detrimental effects on instance performance but that does not seem to be the case:

Checking value first:


Benchmark                           Mode  Cnt     Score      Error   Units
StableBenchmark.atomic             thrpt   10   246.460 ?   75.417  ops/us
StableBenchmark.dcl                thrpt   10   243.481 ?   35.021  ops/us
StableBenchmark.stable             thrpt   10  4977.693 ?  675.926  ops/us  <- Non-null
StableBenchmark.stableHoldingList  thrpt   10  3614.460 ?  275.140  ops/us
StableBenchmark.stableList         thrpt   10  3328.155 ?  898.202  ops/us
StableBenchmark.stableListStored   thrpt   10  3842.174 ?  535.902  ops/us
StableBenchmark.stableNull         thrpt   10  6217.737 ?  840.376  ops/us <- null
StableBenchmark.supplier           thrpt   10  9369.934 ? 1449.182  ops/us


Checking null first:


Benchmark                           Mode  Cnt     Score      Error   Units
StableBenchmark.atomic             thrpt   10   275.952 ?   39.480  ops/us
StableBenchmark.dcl                thrpt   10   252.697 ?   18.645  ops/us
StableBenchmark.stable             thrpt   10  5211.552 ?  315.307  ops/us <- Non-null
StableBenchmark.stableHoldingList  thrpt   10  3764.202 ?  224.325  ops/us
StableBenchmark.stableList         thrpt   10  3689.870 ?  419.858  ops/us
StableBenchmark.stableListStored   thrpt   10  3676.182 ?  938.485  ops/us
StableBenchmark.stableNull         thrpt   10  6046.935 ? 1512.391  ops/us <- null
StableBenchmark.supplier           thrpt   10  9202.202 ? 1479.950  ops/us


So, swapping order seems to be the right move.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18794#discussion_r1602719002

From jpai at openjdk.org  Thu May 16 07:08:03 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 16 May 2024 07:08:03 GMT
Subject: RFR: 8321622: ClassFile.verify(byte[] bytes) throws unexpected
 ConstantPoolException, IAE
In-Reply-To: <Z4hjpgfy3d2G-sXcN3hnIJnvY5mUdKkT0ipYwcnyIs0=.c43fe071-ace7-4d56-a25f-badc45dc24eb@github.com>
References: <Z4hjpgfy3d2G-sXcN3hnIJnvY5mUdKkT0ipYwcnyIs0=.c43fe071-ace7-4d56-a25f-badc45dc24eb@github.com>
Message-ID: <c0gyTunqwoeKH72k3UiMR_KoHXU6VzSXijLrGYBt2PU=.15e094ae-dfe7-4cf1-8eaf-4628c0325945@github.com>

On Thu, 16 May 2024 06:44:29 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> Class-File API `VerifierImpl` contains debugging stack trace print causing unexpected output and confusion in specific verification cases.
> 
> This patch removes the stack trace print.
> 
> Please review.
> 
> Thanks,
> Adam

Hello Adam, the change looks OK to me. The file needs a copyright year update before integrating.

On an unrelated note, the class level javadoc has some `@see` usages which use URLs pointing to `https://raw.githubusercontent.com/openjdk/jdk...`. Are those intentional? Of course, this is an internal class so the javadoc won't be published.

-------------

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19258#pullrequestreview-2059775369

From pminborg at openjdk.org  Thu May 16 07:14:17 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 16 May 2024 07:14:17 GMT
Subject: RFR: 8330465: Stable Values and Collections (Internal) [v5]
In-Reply-To: <sWc2qReuqEhBnu0fHIg75bC8WJkp56HSO9x807NgZoA=.2041706f-383d-44d0-93c6-2eda82329869@github.com>
References: <-KSimQo5kkmCzzMShqGe5QZ9yCSzpWL98gN13v4wP0k=.11dd8d06-18a6-4577-8342-66632cea0b6e@github.com>
 <VGuyX6AyE1gAq2nsCLIyOxnHbYbAAW8YvKk8mAjKnos=.c5ea169b-dfba-4ac8-8e91-7d897708ea5d@github.com>
 <sWc2qReuqEhBnu0fHIg75bC8WJkp56HSO9x807NgZoA=.2041706f-383d-44d0-93c6-2eda82329869@github.com>
Message-ID: <5zoKgO17_hUh9-UveP-yo82Sh2Jrk2Z_3K8rsarDk10=.03e40aaa-cac7-4ef6-b9ca-131fd338a0a8@github.com>

On Wed, 15 May 2024 16:11:56 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Switch to monomorphic StableValue and use lazy arrays
>
> src/java.base/share/classes/jdk/internal/lang/stable/StableValueImpl.java line 139:
> 
>> 137:             case NON_NULL: { return valueVolatile(); }
>> 138:             case ERROR:    { throw StableUtil.error(this); }
>> 139:             case DUMMY:    { throw shouldNotReachHere(); }
> 
> Redundant branch?

The idea here is to have the most likely value in the middle... Not sure if that motivates the added complexity though.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18794#discussion_r1602739126

From alanb at openjdk.org  Thu May 16 07:14:53 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 16 May 2024 07:14:53 GMT
Subject: RFR: 8331670: Deprecate the Memory-Access Methods in
 sun.misc.Unsafe for Removal [v2]
In-Reply-To: <9FyO4QpCtH2CNkUEE78_Jjd9xs3bv3WJo16jyowHOvY=.e7131b91-37bb-4624-a60e-72a427a24c92@github.com>
References: <9FyO4QpCtH2CNkUEE78_Jjd9xs3bv3WJo16jyowHOvY=.e7131b91-37bb-4624-a60e-72a427a24c92@github.com>
Message-ID: <9RTITm_9xLiCNK3PuMoYhhNHoWAix5HMOz7bvEVfPQc=.1c8e7421-b107-47c8-b7fc-f7435eb243d9@github.com>

> This is the implementation changes for JEP 471.
> 
> The methods in sun.misc.Unsafe for on-heap and off-heap access are deprecated for removal. This means a removal warning at compile time. No methods have been removed. A deprecated message is added to each of the methods but unlikely to be seen as the JDK does not generate or publish the API docs for this class.
> 
> A new command line option --sun-misc-unsafe-memory-access=$value is introduced to allow or deny access to these methods. The default proposed for JDK 23 is "allow" so no change in behavior compared to JDK 22 or previous releases.
> 
> A new test is added to test the command line option settings. The existing micros for FFM that use Unsafe are updated to suppress the removal warning at compile time. A new micro is introduced with a small sample of methods to ensure the changes doesn't cause any perf regressions.
> 
> For now, the changes include the update to the man page for the "java" command. It might be that this has to be separated out so that it goes with other updates in the release.

Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains ten additional commits since the last revision:

 - Add removal to DISABLED_WARNINGS
   Fail at startup if bad value specified to option
 - Merge
 - Update man page
 - Update man page
 - Fix comment
 - Merge
 - Merge
 - Whitespace
 - Initial commit

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19174/files
  - new: https://git.openjdk.org/jdk/pull/19174/files/5d3ca0aa..bd74a21d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19174&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19174&range=00-01

  Stats: 4378 lines in 194 files changed: 2791 ins; 962 del; 625 mod
  Patch: https://git.openjdk.org/jdk/pull/19174.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19174/head:pull/19174

PR: https://git.openjdk.org/jdk/pull/19174

From alanb at openjdk.org  Thu May 16 07:14:53 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 16 May 2024 07:14:53 GMT
Subject: RFR: 8331670: Deprecate the Memory-Access Methods in
 sun.misc.Unsafe for Removal [v2]
In-Reply-To: <-mPdzltEqxQ8lLBaLgRE7MlGmXe6owd1eYSOOJ4OP_U=.16eddcfd-6d70-438a-9bae-467162514348@github.com>
References: <9FyO4QpCtH2CNkUEE78_Jjd9xs3bv3WJo16jyowHOvY=.e7131b91-37bb-4624-a60e-72a427a24c92@github.com>
 <-mPdzltEqxQ8lLBaLgRE7MlGmXe6owd1eYSOOJ4OP_U=.16eddcfd-6d70-438a-9bae-467162514348@github.com>
Message-ID: <nW2N_h_cSWMGdJ3hJMPREnYAegiMouLYLW5b4ecGU1M=.56204f0e-35de-414b-804d-1c38f05f3ce5@github.com>

On Wed, 15 May 2024 10:21:14 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> I believe we already disable a bunch of warnings from the command line when compiling these benchmarks. Perhaps we can just tweak the build script in a similar way and avoid the changes to the sources? E.g.
> 
> ```
> DISABLED_WARNINGS := restricted this-escape processing rawtypes cast \
> ```
> 
> Should we add `removal` there?

That might be better, I assumed the micros were being compiled an empty DISABLED_WARNINGS list. It means that the FFM micros won't need to be updated.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19174#discussion_r1602737982

From pminborg at openjdk.org  Thu May 16 07:18:09 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 16 May 2024 07:18:09 GMT
Subject: RFR: 8330465: Stable Values and Collections (Internal) [v5]
In-Reply-To: <sWc2qReuqEhBnu0fHIg75bC8WJkp56HSO9x807NgZoA=.2041706f-383d-44d0-93c6-2eda82329869@github.com>
References: <-KSimQo5kkmCzzMShqGe5QZ9yCSzpWL98gN13v4wP0k=.11dd8d06-18a6-4577-8342-66632cea0b6e@github.com>
 <VGuyX6AyE1gAq2nsCLIyOxnHbYbAAW8YvKk8mAjKnos=.c5ea169b-dfba-4ac8-8e91-7d897708ea5d@github.com>
 <sWc2qReuqEhBnu0fHIg75bC8WJkp56HSO9x807NgZoA=.2041706f-383d-44d0-93c6-2eda82329869@github.com>
Message-ID: <Vot4_J9BwM_g_hMHfKSMqqCM01GugJPUn2JfV9g_9uM=.77b9835e-7ba1-4d62-8522-59ca393575b6@github.com>

On Wed, 15 May 2024 16:19:05 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Switch to monomorphic StableValue and use lazy arrays
>
> src/java.base/share/classes/jdk/internal/lang/stable/StableValueImpl.java line 403:
> 
>> 401:                     stable.computeIfUnset(supplier);
>> 402:                 } catch (Throwable throwable) {
>> 403:                     final Thread.UncaughtExceptionHandler uncaughtExceptionHandler =
> 
> Does this exception handling differ from the default one for threads? If not, I think we can safely remove this catch block, as all exceptions are just propagated and computeIfUnset doesn't declare any checked exception.

Nice catch. This will reduce complexity:


            @Override
            public void run() {
                stable.computeIfUnset(supplier);
                // Exceptions are implicitly captured by the tread's
                // uncaught exception handler.
            }

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18794#discussion_r1602743924

From pminborg at openjdk.org  Thu May 16 07:22:07 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 16 May 2024 07:22:07 GMT
Subject: RFR: 8330465: Stable Values and Collections (Internal) [v5]
In-Reply-To: <sWc2qReuqEhBnu0fHIg75bC8WJkp56HSO9x807NgZoA=.2041706f-383d-44d0-93c6-2eda82329869@github.com>
References: <-KSimQo5kkmCzzMShqGe5QZ9yCSzpWL98gN13v4wP0k=.11dd8d06-18a6-4577-8342-66632cea0b6e@github.com>
 <VGuyX6AyE1gAq2nsCLIyOxnHbYbAAW8YvKk8mAjKnos=.c5ea169b-dfba-4ac8-8e91-7d897708ea5d@github.com>
 <sWc2qReuqEhBnu0fHIg75bC8WJkp56HSO9x807NgZoA=.2041706f-383d-44d0-93c6-2eda82329869@github.com>
Message-ID: <xA58p3q2N-Gfwxpt3zPWXCi2imgLPF_ZPjLYJrtdFvs=.8d8d3dba-0c2d-43fe-92b5-28286bdda43b@github.com>

On Wed, 15 May 2024 16:25:04 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Switch to monomorphic StableValue and use lazy arrays
>
> src/java.base/share/classes/jdk/internal/lang/StableValue.java line 384:
> 
>> 382:      * @param <T>      the memoized type
>> 383:      */
>> 384:     static <T> Supplier<T> ofSupplier(Supplier<? extends T> original) {
> 
> `ofSupplier` sounds like this method returns a `StableValue` from a `Supplier`. I recommend another name, such as `stableSupplier`, `wrapSupplier`, or `memoize`, to better associate with the method's types.

One alternative would be to expose the types `StableList` and `StableMap`. This would allow detection of these types if declared. This would also allow us to expose the methods `computeIfUnset` as instance methods and remove the somewhat strange static counterparts. I agree strict finals are better in the long run.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18794#discussion_r1602749467

From pminborg at openjdk.org  Thu May 16 07:26:15 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 16 May 2024 07:26:15 GMT
Subject: RFR: 8330465: Stable Values and Collections (Internal) [v5]
In-Reply-To: <xA58p3q2N-Gfwxpt3zPWXCi2imgLPF_ZPjLYJrtdFvs=.8d8d3dba-0c2d-43fe-92b5-28286bdda43b@github.com>
References: <-KSimQo5kkmCzzMShqGe5QZ9yCSzpWL98gN13v4wP0k=.11dd8d06-18a6-4577-8342-66632cea0b6e@github.com>
 <VGuyX6AyE1gAq2nsCLIyOxnHbYbAAW8YvKk8mAjKnos=.c5ea169b-dfba-4ac8-8e91-7d897708ea5d@github.com>
 <sWc2qReuqEhBnu0fHIg75bC8WJkp56HSO9x807NgZoA=.2041706f-383d-44d0-93c6-2eda82329869@github.com>
 <xA58p3q2N-Gfwxpt3zPWXCi2imgLPF_ZPjLYJrtdFvs=.8d8d3dba-0c2d-43fe-92b5-28286bdda43b@github.com>
Message-ID: <AiTYYD5fMW56r_2OAeduPpEJVoOGfR0JQfyYvlHUKNo=.aca76ea1-911e-4dba-8e05-5aedf215e4ec@github.com>

On Thu, 16 May 2024 07:19:54 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/lang/StableValue.java line 384:
>> 
>>> 382:      * @param <T>      the memoized type
>>> 383:      */
>>> 384:     static <T> Supplier<T> ofSupplier(Supplier<? extends T> original) {
>> 
>> `ofSupplier` sounds like this method returns a `StableValue` from a `Supplier`. I recommend another name, such as `stableSupplier`, `wrapSupplier`, or `memoize`, to better associate with the method's types.
>
> One alternative would be to expose the types `StableList` and `StableMap`. This would allow detection of these types if declared. This would also allow us to expose the methods `computeIfUnset` as instance methods and remove the somewhat strange static counterparts. I agree strict finals are better in the long run.

We had other names for the memoized factories before but some people did not like names like `asMemoized`. 

Maybe `ofSupplier` -> `memoizedSupplier` etc. ?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18794#discussion_r1602754675

From asotona at openjdk.org  Thu May 16 07:28:20 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Thu, 16 May 2024 07:28:20 GMT
Subject: RFR: 8321622: ClassFile.verify(byte[] bytes) throws unexpected
 ConstantPoolException, IAE [v2]
In-Reply-To: <Z4hjpgfy3d2G-sXcN3hnIJnvY5mUdKkT0ipYwcnyIs0=.c43fe071-ace7-4d56-a25f-badc45dc24eb@github.com>
References: <Z4hjpgfy3d2G-sXcN3hnIJnvY5mUdKkT0ipYwcnyIs0=.c43fe071-ace7-4d56-a25f-badc45dc24eb@github.com>
Message-ID: <0GpX3S7EVL1uu5i0BtmrKoJkV0DrIoLE_xYkruByBrY=.32fabde5-a1e6-4b49-975f-1abdd0dabd45@github.com>

> Class-File API `VerifierImpl` contains debugging stack trace print causing unexpected output and confusion in specific verification cases.
> 
> This patch removes the stack trace print.
> 
> Please review.
> 
> Thanks,
> Adam

Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:

  updated copyright year

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19258/files
  - new: https://git.openjdk.org/jdk/pull/19258/files/235875ca..950493a3

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19258&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19258&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/19258.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19258/head:pull/19258

PR: https://git.openjdk.org/jdk/pull/19258

From pminborg at openjdk.org  Thu May 16 07:29:21 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 16 May 2024 07:29:21 GMT
Subject: RFR: 8330465: Stable Values and Collections (Internal) [v6]
In-Reply-To: <-KSimQo5kkmCzzMShqGe5QZ9yCSzpWL98gN13v4wP0k=.11dd8d06-18a6-4577-8342-66632cea0b6e@github.com>
References: <-KSimQo5kkmCzzMShqGe5QZ9yCSzpWL98gN13v4wP0k=.11dd8d06-18a6-4577-8342-66632cea0b6e@github.com>
Message-ID: <53bNF9v46bu-RgX1vJOwtdFKIzP3vwieCOENWtg2ra8=.c3f4dca8-6b1f-4c35-8e2c-f142c05dfe9b@github.com>

> # Stable Values & Collections (Internal)
> 
> ## Summary
> This PR proposes to introduce an internal _Stable Values & Collections_ API, which provides immutable value holders where elements are initialized _at most once_. Stable Values & Collections offer the performance and safety benefits of final fields while offering greater flexibility as to the timing of initialization.
> 
> ## Goals
>  * Provide an easy and intuitive API to describe value holders that can change at most once.
>  * Decouple declaration from initialization without significant footprint or performance penalties.
>  * Reduce the amount of static initializer and/or field initialization code.
>  * Uphold integrity and consistency, even in a multi-threaded environment.
>  
> For more details, see the draft JEP: https://openjdk.org/jeps/8312611
> 
> ## Performance 
> Performance compared to instance variables using two `AtomicReference` and two protected by double-checked locking under concurrent access by all threads:
> 
> 
> Benchmark                                      Mode  Cnt      Score      Error   Units
> StableBenchmark.atomic                        thrpt   10    259.478 ?   36.809  ops/us
> StableBenchmark.dcl                           thrpt   10    225.710 ?   26.638  ops/us
> StableBenchmark.stable                        thrpt   10   4382.478 ? 1151.472  ops/us <- StableValue significantly faster
> 
> 
> Performance compared to static variables protected by `AtomicReference`, class-holder idiom holder, and double-checked locking (all threads):
> 
> 
> Benchmark                                      Mode  Cnt      Score      Error   Units
> StableStaticBenchmark.atomic                  thrpt   10   6487.835 ?  385.639  ops/us
> StableStaticBenchmark.dcl                     thrpt   10   6605.239 ?  210.610  ops/us
> StableStaticBenchmark.stable                  thrpt   10  14338.239 ? 1426.874  ops/us
> StableStaticBenchmark.staticCHI               thrpt   10  13780.341 ? 1839.651  ops/us
> 
> 
> Performance for stable lists (thread safe) in both instance and static contexts whereby we access a single value compared to `ArrayList` instances (which are not thread-safe) (all threads):
> 
> 
> Benchmark                                      Mode  Cnt      Score      Error   Units
> StableListElementBenchmark.instanceArrayList  thrpt   10   5812.992 ? 1169.730  ops/us
> StableListElementBenchmark.instanceList       thrpt   10   4818.643 ?  704.893  ops/us
> StableListElementBenchmark.staticArrayList    thrpt   10   7614.741 ?  564.777  ops/us
> StableListElementBe...

Per Minborg has updated the pull request incrementally with one additional commit since the last revision:

  Simplify exception handling and add benchmarks

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/18794/files
  - new: https://git.openjdk.org/jdk/pull/18794/files/2b840e06..befb2751

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18794&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18794&range=04-05

  Stats: 30 lines in 3 files changed: 19 ins; 6 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/18794.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18794/head:pull/18794

PR: https://git.openjdk.org/jdk/pull/18794

From asotona at openjdk.org  Thu May 16 07:32:01 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Thu, 16 May 2024 07:32:01 GMT
Subject: RFR: 8321622: ClassFile.verify(byte[] bytes) throws unexpected
 ConstantPoolException, IAE [v2]
In-Reply-To: <0GpX3S7EVL1uu5i0BtmrKoJkV0DrIoLE_xYkruByBrY=.32fabde5-a1e6-4b49-975f-1abdd0dabd45@github.com>
References: <Z4hjpgfy3d2G-sXcN3hnIJnvY5mUdKkT0ipYwcnyIs0=.c43fe071-ace7-4d56-a25f-badc45dc24eb@github.com>
 <0GpX3S7EVL1uu5i0BtmrKoJkV0DrIoLE_xYkruByBrY=.32fabde5-a1e6-4b49-975f-1abdd0dabd45@github.com>
Message-ID: <8y5V7liKHuRnKFI_v8SM4C99zZ8crgDGr2mNfmumufE=.b3958769-d99c-4c9f-baa4-0fc56223739a@github.com>

On Thu, 16 May 2024 07:28:20 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> Class-File API `VerifierImpl` contains debugging stack trace print causing unexpected output and confusion in specific verification cases.
>> 
>> This patch removes the stack trace print.
>> 
>> Please review.
>> 
>> Thanks,
>> Adam
>
> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
> 
>   updated copyright year

Thank you for the review.

Yes, the `@see` links to the C++ sources in the verifier implementation help a lot and are intentional.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19258#issuecomment-2114271187

From asotona at openjdk.org  Thu May 16 07:35:11 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Thu, 16 May 2024 07:35:11 GMT
Subject: Integrated: 8321622: ClassFile.verify(byte[] bytes) throws unexpected
 ConstantPoolException, IAE
In-Reply-To: <Z4hjpgfy3d2G-sXcN3hnIJnvY5mUdKkT0ipYwcnyIs0=.c43fe071-ace7-4d56-a25f-badc45dc24eb@github.com>
References: <Z4hjpgfy3d2G-sXcN3hnIJnvY5mUdKkT0ipYwcnyIs0=.c43fe071-ace7-4d56-a25f-badc45dc24eb@github.com>
Message-ID: <nhZ-36ybB7TvTgQ5_k68hdN3mYqFTmnMiH9kc2Qf1IU=.0ed23872-4d98-4f1e-9d74-ed8056b1ca05@github.com>

On Thu, 16 May 2024 06:44:29 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> Class-File API `VerifierImpl` contains debugging stack trace print causing unexpected output and confusion in specific verification cases.
> 
> This patch removes the stack trace print.
> 
> Please review.
> 
> Thanks,
> Adam

This pull request has now been integrated.

Changeset: ee4a9d34
Author:    Adam Sotona <asotona at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/ee4a9d34827166ff9ac04e2375058fdc08e43194
Stats:     2 lines in 1 file changed: 0 ins; 1 del; 1 mod

8321622: ClassFile.verify(byte[] bytes) throws unexpected ConstantPoolException, IAE

Reviewed-by: jpai

-------------

PR: https://git.openjdk.org/jdk/pull/19258

From pminborg at openjdk.org  Thu May 16 07:37:20 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 16 May 2024 07:37:20 GMT
Subject: RFR: 8330465: Stable Values and Collections (Internal) [v7]
In-Reply-To: <-KSimQo5kkmCzzMShqGe5QZ9yCSzpWL98gN13v4wP0k=.11dd8d06-18a6-4577-8342-66632cea0b6e@github.com>
References: <-KSimQo5kkmCzzMShqGe5QZ9yCSzpWL98gN13v4wP0k=.11dd8d06-18a6-4577-8342-66632cea0b6e@github.com>
Message-ID: <nIszy_mGUltKfau7uBW9IGuW4voRFowVOE32yM2LfoU=.130521c4-a0db-4574-b44f-025df7405c41@github.com>

> # Stable Values & Collections (Internal)
> 
> ## Summary
> This PR proposes to introduce an internal _Stable Values & Collections_ API, which provides immutable value holders where elements are initialized _at most once_. Stable Values & Collections offer the performance and safety benefits of final fields while offering greater flexibility as to the timing of initialization.
> 
> ## Goals
>  * Provide an easy and intuitive API to describe value holders that can change at most once.
>  * Decouple declaration from initialization without significant footprint or performance penalties.
>  * Reduce the amount of static initializer and/or field initialization code.
>  * Uphold integrity and consistency, even in a multi-threaded environment.
>  
> For more details, see the draft JEP: https://openjdk.org/jeps/8312611
> 
> ## Performance 
> Performance compared to instance variables using two `AtomicReference` and two protected by double-checked locking under concurrent access by all threads:
> 
> 
> Benchmark                                      Mode  Cnt      Score      Error   Units
> StableBenchmark.atomic                        thrpt   10    259.478 ?   36.809  ops/us
> StableBenchmark.dcl                           thrpt   10    225.710 ?   26.638  ops/us
> StableBenchmark.stable                        thrpt   10   4382.478 ? 1151.472  ops/us <- StableValue significantly faster
> 
> 
> Performance compared to static variables protected by `AtomicReference`, class-holder idiom holder, and double-checked locking (all threads):
> 
> 
> Benchmark                                      Mode  Cnt      Score      Error   Units
> StableStaticBenchmark.atomic                  thrpt   10   6487.835 ?  385.639  ops/us
> StableStaticBenchmark.dcl                     thrpt   10   6605.239 ?  210.610  ops/us
> StableStaticBenchmark.stable                  thrpt   10  14338.239 ? 1426.874  ops/us
> StableStaticBenchmark.staticCHI               thrpt   10  13780.341 ? 1839.651  ops/us
> 
> 
> Performance for stable lists (thread safe) in both instance and static contexts whereby we access a single value compared to `ArrayList` instances (which are not thread-safe) (all threads):
> 
> 
> Benchmark                                      Mode  Cnt      Score      Error   Units
> StableListElementBenchmark.instanceArrayList  thrpt   10   5812.992 ? 1169.730  ops/us
> StableListElementBenchmark.instanceList       thrpt   10   4818.643 ?  704.893  ops/us
> StableListElementBenchmark.staticArrayList    thrpt   10   7614.741 ?  564.777  ops/us
> StableListElementBe...

Per Minborg has updated the pull request incrementally with one additional commit since the last revision:

  Rename memoized factories

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/18794/files
  - new: https://git.openjdk.org/jdk/pull/18794/files/befb2751..b845c589

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18794&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18794&range=05-06

  Stats: 13 lines in 5 files changed: 0 ins; 0 del; 13 mod
  Patch: https://git.openjdk.org/jdk/pull/18794.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18794/head:pull/18794

PR: https://git.openjdk.org/jdk/pull/18794

From pminborg at openjdk.org  Thu May 16 07:44:08 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 16 May 2024 07:44:08 GMT
Subject: RFR: 8330465: Stable Values and Collections (Internal) [v5]
In-Reply-To: <T5Wni3IAdExwxz0RvyvViUIoLTDIgC4ACAqhT5YGMm4=.48d0bc7d-a0a1-45bf-8d28-5fa6361049cb@github.com>
References: <-KSimQo5kkmCzzMShqGe5QZ9yCSzpWL98gN13v4wP0k=.11dd8d06-18a6-4577-8342-66632cea0b6e@github.com>
 <VGuyX6AyE1gAq2nsCLIyOxnHbYbAAW8YvKk8mAjKnos=.c5ea169b-dfba-4ac8-8e91-7d897708ea5d@github.com>
 <sWc2qReuqEhBnu0fHIg75bC8WJkp56HSO9x807NgZoA=.2041706f-383d-44d0-93c6-2eda82329869@github.com>
 <hfCAtNQs4eEApF71b4FKsHWQwl20eYeURk_AljjT-q0=.6753684c-6275-4db5-99ca-b1190fbe5b95@github.com>
 <T5Wni3IAdExwxz0RvyvViUIoLTDIgC4ACAqhT5YGMm4=.48d0bc7d-a0a1-45bf-8d28-5fa6361049cb@github.com>
Message-ID: <9E5b14zDF-FxZBdff6Ih83L55BlcBFt6sjK_aA7zLKc=.99cff2c0-68c1-4efd-a50b-79ca14b16e49@github.com>

On Wed, 15 May 2024 19:07:26 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Yes, according to?the?`@Stable` annotation?s?JavaDoc, this?is?UB:
>> https://github.com/openjdk/jdk/blob/8a4315f833f3700075d65fae6bc566011c837c07/src/java.base/share/classes/jdk/internal/vm/annotation/Stable.java#L74-L80
>
> Fyi what usually happens is that if a stable field or similarly constant-folded field is promoted to constant, the constant promotion can happen to any of the previous valid values written.
> 
> MethodHandle optimisitically sets a trusted final field this way:
> https://github.com/openjdk/jdk/blob/8a4315f833f3700075d65fae6bc566011c837c07/src/java.base/share/classes/java/lang/invoke/MethodHandle.java#L1868-L1870
> 
> Also a similar example in user code targeting older Java releases, before JDK 16's strong encapsulation so that enums could have been added by reflection:
> https://github.com/MinecraftForge/MinecraftForge/issues/3885#issuecomment-355602542

Somehow the `@Stable` annotation sneaked into the `supplying` field. But actually keeping it that way and just set the value once would be better.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18794#discussion_r1602781188

From pminborg at openjdk.org  Thu May 16 07:49:37 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 16 May 2024 07:49:37 GMT
Subject: RFR: 8330465: Stable Values and Collections (Internal) [v8]
In-Reply-To: <-KSimQo5kkmCzzMShqGe5QZ9yCSzpWL98gN13v4wP0k=.11dd8d06-18a6-4577-8342-66632cea0b6e@github.com>
References: <-KSimQo5kkmCzzMShqGe5QZ9yCSzpWL98gN13v4wP0k=.11dd8d06-18a6-4577-8342-66632cea0b6e@github.com>
Message-ID: <Zb7Wz_5HDSyTAbxrIiPBqcblkfXTTsQT9Up5-m-G__k=.847349d2-2327-41f0-85ab-13a8c4696772@github.com>

> # Stable Values & Collections (Internal)
> 
> ## Summary
> This PR proposes to introduce an internal _Stable Values & Collections_ API, which provides immutable value holders where elements are initialized _at most once_. Stable Values & Collections offer the performance and safety benefits of final fields while offering greater flexibility as to the timing of initialization.
> 
> ## Goals
>  * Provide an easy and intuitive API to describe value holders that can change at most once.
>  * Decouple declaration from initialization without significant footprint or performance penalties.
>  * Reduce the amount of static initializer and/or field initialization code.
>  * Uphold integrity and consistency, even in a multi-threaded environment.
>  
> For more details, see the draft JEP: https://openjdk.org/jeps/8312611
> 
> ## Performance 
> Performance compared to instance variables using two `AtomicReference` and two protected by double-checked locking under concurrent access by all threads:
> 
> 
> Benchmark                                      Mode  Cnt      Score      Error   Units
> StableBenchmark.atomic                        thrpt   10    259.478 ?   36.809  ops/us
> StableBenchmark.dcl                           thrpt   10    225.710 ?   26.638  ops/us
> StableBenchmark.stable                        thrpt   10   4382.478 ? 1151.472  ops/us <- StableValue significantly faster
> 
> 
> Performance compared to static variables protected by `AtomicReference`, class-holder idiom holder, and double-checked locking (all threads):
> 
> 
> Benchmark                                      Mode  Cnt      Score      Error   Units
> StableStaticBenchmark.atomic                  thrpt   10   6487.835 ?  385.639  ops/us
> StableStaticBenchmark.dcl                     thrpt   10   6605.239 ?  210.610  ops/us
> StableStaticBenchmark.stable                  thrpt   10  14338.239 ? 1426.874  ops/us
> StableStaticBenchmark.staticCHI               thrpt   10  13780.341 ? 1839.651  ops/us
> 
> 
> Performance for stable lists (thread safe) in both instance and static contexts whereby we access a single value compared to `ArrayList` instances (which are not thread-safe) (all threads):
> 
> 
> Benchmark                                      Mode  Cnt      Score      Error   Units
> StableListElementBenchmark.instanceArrayList  thrpt   10   5812.992 ? 1169.730  ops/us
> StableListElementBenchmark.instanceList       thrpt   10   4818.643 ?  704.893  ops/us
> StableListElementBenchmark.staticArrayList    thrpt   10   7614.741 ?  564.777  ops/us
> StableListElementBe...

Per Minborg has updated the pull request incrementally with one additional commit since the last revision:

  Rework the way compute invocation is recorded

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/18794/files
  - new: https://git.openjdk.org/jdk/pull/18794/files/b845c589..d8875db7

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18794&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18794&range=06-07

  Stats: 40 lines in 1 file changed: 3 ins; 12 del; 25 mod
  Patch: https://git.openjdk.org/jdk/pull/18794.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18794/head:pull/18794

PR: https://git.openjdk.org/jdk/pull/18794

From pminborg at openjdk.org  Thu May 16 07:49:37 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 16 May 2024 07:49:37 GMT
Subject: RFR: 8330465: Stable Values and Collections (Internal) [v5]
In-Reply-To: <sWc2qReuqEhBnu0fHIg75bC8WJkp56HSO9x807NgZoA=.2041706f-383d-44d0-93c6-2eda82329869@github.com>
References: <-KSimQo5kkmCzzMShqGe5QZ9yCSzpWL98gN13v4wP0k=.11dd8d06-18a6-4577-8342-66632cea0b6e@github.com>
 <VGuyX6AyE1gAq2nsCLIyOxnHbYbAAW8YvKk8mAjKnos=.c5ea169b-dfba-4ac8-8e91-7d897708ea5d@github.com>
 <sWc2qReuqEhBnu0fHIg75bC8WJkp56HSO9x807NgZoA=.2041706f-383d-44d0-93c6-2eda82329869@github.com>
Message-ID: <APhaRMULgBF6pmQa9eZjkQh34ETvVXmzeBc1SjnktMQ=.eb2b32a5-2e2d-43ee-8135-1825a568b67c@github.com>

On Wed, 15 May 2024 16:31:15 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Switch to monomorphic StableValue and use lazy arrays
>
> src/java.base/share/classes/jdk/internal/lang/stable/StableValueImpl.java line 256:
> 
>> 254: 
>> 255:     @ForceInline
>> 256:     private <K> V computeIfUnsetShared(Object provider, K key) {
> 
> Can we let suppliers share this path too, with a null key? I see this path supports suppliers but supplier code path doesn't call this path.

Good suggestion!

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18794#discussion_r1602787248

From jpai at openjdk.org  Thu May 16 07:51:14 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 16 May 2024 07:51:14 GMT
Subject: RFR: 8331670: Deprecate the Memory-Access Methods in
 sun.misc.Unsafe for Removal [v2]
In-Reply-To: <9RTITm_9xLiCNK3PuMoYhhNHoWAix5HMOz7bvEVfPQc=.1c8e7421-b107-47c8-b7fc-f7435eb243d9@github.com>
References: <9FyO4QpCtH2CNkUEE78_Jjd9xs3bv3WJo16jyowHOvY=.e7131b91-37bb-4624-a60e-72a427a24c92@github.com>
 <9RTITm_9xLiCNK3PuMoYhhNHoWAix5HMOz7bvEVfPQc=.1c8e7421-b107-47c8-b7fc-f7435eb243d9@github.com>
Message-ID: <m8l0fEOe67CsGjetIgeR7xDiBZfJ4KuzpACrGliA5io=.eefddee8-95d2-46e0-bfc1-0544085e65ed@github.com>

On Thu, 16 May 2024 07:14:53 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> This is the implementation changes for JEP 471.
>> 
>> The methods in sun.misc.Unsafe for on-heap and off-heap access are deprecated for removal. This means a removal warning at compile time. No methods have been removed. A deprecated message is added to each of the methods but unlikely to be seen as the JDK does not generate or publish the API docs for this class.
>> 
>> A new command line option --sun-misc-unsafe-memory-access=$value is introduced to allow or deny access to these methods. The default proposed for JDK 23 is "allow" so no change in behavior compared to JDK 22 or previous releases.
>> 
>> A new test is added to test the command line option settings. The existing micros for FFM that use Unsafe are updated to suppress the removal warning at compile time. A new micro is introduced with a small sample of methods to ensure the changes doesn't cause any perf regressions.
>> 
>> For now, the changes include the update to the man page for the "java" command. It might be that this has to be separated out so that it goes with other updates in the release.
>
> Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains ten additional commits since the last revision:
> 
>  - Add removal to DISABLED_WARNINGS
>    Fail at startup if bad value specified to option
>  - Merge
>  - Update man page
>  - Update man page
>  - Fix comment
>  - Merge
>  - Merge
>  - Whitespace
>  - Initial commit

The changes in `bd74a21d` look good to me. I haven't paid close attention to the new benchmark.

-------------

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19174#pullrequestreview-2059867530

From pminborg at openjdk.org  Thu May 16 07:55:39 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 16 May 2024 07:55:39 GMT
Subject: RFR: 8330465: Stable Values and Collections (Internal) [v9]
In-Reply-To: <-KSimQo5kkmCzzMShqGe5QZ9yCSzpWL98gN13v4wP0k=.11dd8d06-18a6-4577-8342-66632cea0b6e@github.com>
References: <-KSimQo5kkmCzzMShqGe5QZ9yCSzpWL98gN13v4wP0k=.11dd8d06-18a6-4577-8342-66632cea0b6e@github.com>
Message-ID: <aoYtplKA0l8IpObg7gaye8h_DjxzlH6CP8z69eJn9bg=.fa6c6608-6b2e-482e-9ff5-a614ffd98b91@github.com>

> # Stable Values & Collections (Internal)
> 
> ## Summary
> This PR proposes to introduce an internal _Stable Values & Collections_ API, which provides immutable value holders where elements are initialized _at most once_. Stable Values & Collections offer the performance and safety benefits of final fields while offering greater flexibility as to the timing of initialization.
> 
> ## Goals
>  * Provide an easy and intuitive API to describe value holders that can change at most once.
>  * Decouple declaration from initialization without significant footprint or performance penalties.
>  * Reduce the amount of static initializer and/or field initialization code.
>  * Uphold integrity and consistency, even in a multi-threaded environment.
>  
> For more details, see the draft JEP: https://openjdk.org/jeps/8312611
> 
> ## Performance 
> Performance compared to instance variables using two `AtomicReference` and two protected by double-checked locking under concurrent access by all threads:
> 
> 
> Benchmark                                      Mode  Cnt      Score      Error   Units
> StableBenchmark.atomic                        thrpt   10    259.478 ?   36.809  ops/us
> StableBenchmark.dcl                           thrpt   10    225.710 ?   26.638  ops/us
> StableBenchmark.stable                        thrpt   10   4382.478 ? 1151.472  ops/us <- StableValue significantly faster
> 
> 
> Performance compared to static variables protected by `AtomicReference`, class-holder idiom holder, and double-checked locking (all threads):
> 
> 
> Benchmark                                      Mode  Cnt      Score      Error   Units
> StableStaticBenchmark.atomic                  thrpt   10   6487.835 ?  385.639  ops/us
> StableStaticBenchmark.dcl                     thrpt   10   6605.239 ?  210.610  ops/us
> StableStaticBenchmark.stable                  thrpt   10  14338.239 ? 1426.874  ops/us
> StableStaticBenchmark.staticCHI               thrpt   10  13780.341 ? 1839.651  ops/us
> 
> 
> Performance for stable lists (thread safe) in both instance and static contexts whereby we access a single value compared to `ArrayList` instances (which are not thread-safe) (all threads):
> 
> 
> Benchmark                                      Mode  Cnt      Score      Error   Units
> StableListElementBenchmark.instanceArrayList  thrpt   10   5812.992 ? 1169.730  ops/us
> StableListElementBenchmark.instanceList       thrpt   10   4818.643 ?  704.893  ops/us
> StableListElementBenchmark.staticArrayList    thrpt   10   7614.741 ?  564.777  ops/us
> StableListElementBe...

Per Minborg has updated the pull request incrementally with two additional commits since the last revision:

 - Add comment on security precaution
 - Share code paths

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/18794/files
  - new: https://git.openjdk.org/jdk/pull/18794/files/d8875db7..058cfddf

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18794&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18794&range=07-08

  Stats: 55 lines in 1 file changed: 1 ins; 53 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/18794.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18794/head:pull/18794

PR: https://git.openjdk.org/jdk/pull/18794

From pminborg at openjdk.org  Thu May 16 07:55:40 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 16 May 2024 07:55:40 GMT
Subject: RFR: 8330465: Stable Values and Collections (Internal) [v5]
In-Reply-To: <sWc2qReuqEhBnu0fHIg75bC8WJkp56HSO9x807NgZoA=.2041706f-383d-44d0-93c6-2eda82329869@github.com>
References: <-KSimQo5kkmCzzMShqGe5QZ9yCSzpWL98gN13v4wP0k=.11dd8d06-18a6-4577-8342-66632cea0b6e@github.com>
 <VGuyX6AyE1gAq2nsCLIyOxnHbYbAAW8YvKk8mAjKnos=.c5ea169b-dfba-4ac8-8e91-7d897708ea5d@github.com>
 <sWc2qReuqEhBnu0fHIg75bC8WJkp56HSO9x807NgZoA=.2041706f-383d-44d0-93c6-2eda82329869@github.com>
Message-ID: <O4vmF95DEN5VPh0BMBi4IgOxxakEZeEto2iURVMq7sw=.cc31060d-09a0-4065-a39e-2dea8c08d067@github.com>

On Wed, 15 May 2024 16:29:08 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Switch to monomorphic StableValue and use lazy arrays
>
> src/java.base/share/classes/jdk/internal/lang/stable/StableValueImpl.java line 236:
> 
>> 234:                 } catch (Throwable t) {
>> 235:                     putState(ERROR);
>> 236:                     putMutex(t.getClass());
> 
> Should we cache the exception instance so we can rethrow it in future ERROR state `orThrow` calls?

We considered recording the entire exception instance but for security reasons, we ended up just recording the type of exception. I will add a comment explaining this in the code.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18794#discussion_r1602793832

From pminborg at openjdk.org  Thu May 16 07:58:11 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 16 May 2024 07:58:11 GMT
Subject: RFR: 8330465: Stable Values and Collections (Internal) [v5]
In-Reply-To: <sWc2qReuqEhBnu0fHIg75bC8WJkp56HSO9x807NgZoA=.2041706f-383d-44d0-93c6-2eda82329869@github.com>
References: <-KSimQo5kkmCzzMShqGe5QZ9yCSzpWL98gN13v4wP0k=.11dd8d06-18a6-4577-8342-66632cea0b6e@github.com>
 <VGuyX6AyE1gAq2nsCLIyOxnHbYbAAW8YvKk8mAjKnos=.c5ea169b-dfba-4ac8-8e91-7d897708ea5d@github.com>
 <sWc2qReuqEhBnu0fHIg75bC8WJkp56HSO9x807NgZoA=.2041706f-383d-44d0-93c6-2eda82329869@github.com>
Message-ID: <_mILA1l3vosqmxf8OKbgUr0_IYxfReWuvXKpxphC61E=.95b36c90-3ce7-4033-9c93-b014cbc5ee0d@github.com>

On Wed, 15 May 2024 16:26:57 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Switch to monomorphic StableValue and use lazy arrays
>
> src/java.base/share/classes/jdk/internal/lang/stable/StableValueImpl.java line 75:
> 
>> 73:      */
>> 74:     @Stable
>> 75:     private int state;
> 
> Can we change this to be a byte, so state and supplying fields can be packed together in 4 bytes in some layouts?

We had `byte` before but converted to `int` as the `byte` will get promoted to an `int` anyhow in the code logic. However, one idea would be to go back to using a `byte` again and also use a `byte` for the flag of computation invocation. This would reduce the footprint for these two fields from 8 bytes to 2 bytes.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18794#discussion_r1602800304

From jwaters at openjdk.org  Thu May 16 07:59:07 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Thu, 16 May 2024 07:59:07 GMT
Subject: RFR: 8330988: Implementation of 8288293: Windows/gcc Port for
 hsdis [v2]
In-Reply-To: <uDQsb80PEdGh5z4AWPX3AxJZXhc-1V1XjwdhKo2Pylc=.63b6303a-dcb9-4cfc-acc6-e512a73b7496@github.com>
References: <bXwOUFPBZUWDmidfDnVJLBKG4HkeS585IJqAOK8W1ys=.211183fe-b18e-498d-a557-6e6c4dfac27c@github.com>
 <xvXZ9TddIGBdQqUJ0c_MccUw7lPjJqeTZzrPYJG-EyQ=.59e09c22-93b5-4271-9cc7-60b1d1f90a8e@github.com>
 <uDQsb80PEdGh5z4AWPX3AxJZXhc-1V1XjwdhKo2Pylc=.63b6303a-dcb9-4cfc-acc6-e512a73b7496@github.com>
Message-ID: <4QTrXORVLmXOdBxVAdYyAE9M7HTfxOjcW0NVtitY-og=.aef997d7-96d6-4992-b308-d951046c920f@github.com>

On Wed, 15 May 2024 13:32:38 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Hi Julian, sorry for not getting back to you.
> 
> The problem from my PoV is that this is a very large and intrusive patch in the build of the actual product, for a claimed problem in the tangential hsdis library. I have not understood a pressing business need to get a Windows/gcc port for hsdis, which means I can't really prioritize trying to understand this patch.
> 
> As you know, the build system does not currently really separate between "the OS is Windows" and "the toolchain is Microsoft". I understand that you want to fix that, and in theory I support it. However, you must also realize that making a complete fix of this requires a lot of work, for something that there is no clearly defined need. (After all, cl.exe works fine to create the build, has no apparent issues, and is as far as an "official" compiler for Windows as you can get.) That makes it fall squarely in the WIBNIs bucked ("wouldn't it be nice if...").
> 
> If you can fix just the hsdis build without changing anything outside the hsdis Makefiles, that would be a different story. Such a change would be limited in scope, easy to say it will not affect the product proper, and be easier to review.

Oh, no worries. Sorry for sounding a little impatient.

The problem is that there are areas in the build system that will need changing to support hsdis compilation, not just the hsdis Makefile and autoconf file itself. I can try to work on minimizing the amount of changes to non-hsdis files (I was hoping the current changes were small enough, but it seems they are not), but I believe it's impossible to achieve this by only touching the hsdis Makefile and lib-hsdis.m4. That is, there will necessarily be changes, no matter how minimal, to non-hsdis files.

As for why do this at all, I was mainly driven by seeing the hack in place for the binutils backend on Windows. It only supports Cygwin, of which the gcc installation is subpar compared to the newer gcc provided by some MSYS2 subsystems (MINGW64 gcc is primarily battle tested on MSYS2, on Cygwin it doesn't get as much attention and misses out further fixes and enhancements from the MSYS2 team, for instance it even links to the obsolete msvcrt library), and the hack itself has several flaws that don't seem apparent at first (For instance, -lpthread will link to libwinpthread.dll and result in an invisible dependency on that dll depending on the Windows platform, which will cause loading hsdis to silently fail depending on how it's loaded for seemingly random reasons!). I wanted to replace that (or I guess provide a better alternative) by adding semi proper support to the hsdis build for the more modern and better battle tested gcc that some MSYS2 subsystems provide, to streamline comp
 iling the binutils hsdis on Windows. So this is mainly about hsdis-binutils on Windows. hsdis-capstone I also decided to support because it's small and relatively easy to pile on top of the existing work, and MSYS2 also provides Capstone as well. The same unfortunately could not be said for hsdis-llvm, which was significantly more complex than Capstone is

I'm not sure where to go from here. I could support gcc for hsdis binutils by extending the hack that exists for Cygwin, but I _really_ don't want to do that. I could enhance the build system to semi properly support gcc for hsdis only, as I've done, but the changes will necessarily touch non hsdis files as well, no matter how minimal they are. I'll return this to draft for the time being I suppose, I'd be interested in hearing which way forward you prefer though

But while I work on making this change even smaller and easier to review, could I ask the above questions again? (Well, except for the FIXPATH one, you can ignore that)



> @magicus I think I might need some help here. Currently all the Cygwin stuff is gated behind ifeq ($(TOOLCHAIN_TYPE), microsoft) checks... should they be behind isBuildOsEnv cygwin checks instead? I don't know how to add support for Cygwin gcc for most of hsdis, since it is quite different from the more modern gcc distributions that are found in places like MSYS2 and MINGW64. But most of the existing logic seems to accomodate more for the Microsoft compiler than it is concerned about the OS environment being used, and for this reason I can't tell which of the 2 checks to use for the existing hack that switches from microsoft to gcc. Also, gcc doesn't require FIXPATH, but Microsoft does, but I don't want to check for microsoft inside TOOLCHAIN_FIND_COMPILER, what should I do instead to ensure gcc doesn't get FIXPATH while Microsoft does?



> Also @magicus, what is the typical path passed to --with-binutils like on Windows? Something like --with-binutils=/c/Users/vertig0/Downloads/binutils-2.42 doesn't work correctly, since the include path to dis-asm.h would then become `#include "/c/Users/vertig0/Downloads/binutils-2.42/include/dis-asm.h"` Which causes a configure check to fail on the compile stage since gcc cannot recognise the MINGW-esque /c/ as a drive, and then causes configure to erroneously report binutils as using the Old API when it's in fact using the New API. --with-binutils=C:/Users/vertig0/Downloads/binutils-2.42 on the other hand works as expected. Should there be a fixup for the path there so gcc can recognise it properly?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18915#issuecomment-2114331612

From pminborg at openjdk.org  Thu May 16 08:01:11 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 16 May 2024 08:01:11 GMT
Subject: RFR: 8330465: Stable Values and Collections (Internal) [v4]
In-Reply-To: <8QkAH25MWgY2qvCQgPPID71ye9gL3cX5MqhHs1Fapy0=.293fae67-c17f-42c7-af84-79408c1ed3e1@github.com>
References: <-KSimQo5kkmCzzMShqGe5QZ9yCSzpWL98gN13v4wP0k=.11dd8d06-18a6-4577-8342-66632cea0b6e@github.com>
 <Aoeah2Qx-yd_WnZV4YKBJrU-N_Ht2U2FBymgFK5B_jg=.caf754c8-4f71-4dda-b093-7f3ef050d1c0@github.com>
 <WTvK6htLFImBbqJaegAYhe66v-7Ukg1Rbr_SBPAAUw4=.0339bae0-9215-4786-9847-b54428d6e1fa@github.com>
 <lashsCFY4UdB4ssgwteonzsOO8uqHAlEehoRy1iI1p8=.d4fca59b-1733-497f-9ff3-d134843a4d9c@github.com>
 <K90SVl2BCEkM_lc37eC9NPdtq5uMxse62LZ9xsxDbyI=.03ad5520-18ce-4c78-bc51-45aa496bc503@github.com>
 <aqMzmR7809faNQYdPkvTm39j9ENwc9efTGfIqVPT7HI=.4ec72ad9-878d-41ea-923d-3b4b3b04389e@github.com>
 <EyDO7FCncOfB4vhoQ5uG1_IoDHt_kBKfi_QAH59NW3o=.5a4369b9-cb6c-4625-9e88-7c5a54a56d8b@github.com>
 <8QkAH25MWgY2qvCQgPPID71ye9gL3cX5MqhHs1Fapy0=.293fae67-c17f-42c7-af84-79408c1ed3e1@github.com>
Message-ID: <ujGTcWYfkNIo9sTr-ZNXS148N9YlIXjjs5plyHz1x6Q=.ef119387-488a-468c-bc4a-062801584233@github.com>

On Wed, 15 May 2024 15:49:22 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Maybe there is a better home for this?
>
> I don't think we should publish this API; this will soon be phased out by strict final fields (written only before super constructor calls) introduced by Valhalla, as strict final fields are never modifiable and can be safely trusted.

Let's keep it internal.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18794#discussion_r1602804071

From mcimadamore at openjdk.org  Thu May 16 08:55:17 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 16 May 2024 08:55:17 GMT
Subject: RFR: 8331670: Deprecate the Memory-Access Methods in
 sun.misc.Unsafe for Removal [v2]
In-Reply-To: <9RTITm_9xLiCNK3PuMoYhhNHoWAix5HMOz7bvEVfPQc=.1c8e7421-b107-47c8-b7fc-f7435eb243d9@github.com>
References: <9FyO4QpCtH2CNkUEE78_Jjd9xs3bv3WJo16jyowHOvY=.e7131b91-37bb-4624-a60e-72a427a24c92@github.com>
 <9RTITm_9xLiCNK3PuMoYhhNHoWAix5HMOz7bvEVfPQc=.1c8e7421-b107-47c8-b7fc-f7435eb243d9@github.com>
Message-ID: <1aefFPmydc53opGfwJdofoaEBaDtaXUC7V3Lt5ltArU=.8428daee-e478-4a02-9a2f-7190d57ad9fc@github.com>

On Thu, 16 May 2024 07:14:53 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> This is the implementation changes for JEP 471.
>> 
>> The methods in sun.misc.Unsafe for on-heap and off-heap access are deprecated for removal. This means a removal warning at compile time. No methods have been removed. A deprecated message is added to each of the methods but unlikely to be seen as the JDK does not generate or publish the API docs for this class.
>> 
>> A new command line option --sun-misc-unsafe-memory-access=$value is introduced to allow or deny access to these methods. The default proposed for JDK 23 is "allow" so no change in behavior compared to JDK 22 or previous releases.
>> 
>> A new test is added to test the command line option settings. The existing micros for FFM that use Unsafe are updated to suppress the removal warning at compile time. A new micro is introduced with a small sample of methods to ensure the changes doesn't cause any perf regressions.
>> 
>> For now, the changes include the update to the man page for the "java" command. It might be that this has to be separated out so that it goes with other updates in the release.
>
> Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains ten additional commits since the last revision:
> 
>  - Add removal to DISABLED_WARNINGS
>    Fail at startup if bad value specified to option
>  - Merge
>  - Update man page
>  - Update man page
>  - Fix comment
>  - Merge
>  - Merge
>  - Whitespace
>  - Initial commit

Marked as reviewed by mcimadamore (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/19174#pullrequestreview-2060041163

From pminborg at openjdk.org  Thu May 16 09:01:22 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 16 May 2024 09:01:22 GMT
Subject: RFR: 8330465: Stable Values and Collections (Internal) [v10]
In-Reply-To: <-KSimQo5kkmCzzMShqGe5QZ9yCSzpWL98gN13v4wP0k=.11dd8d06-18a6-4577-8342-66632cea0b6e@github.com>
References: <-KSimQo5kkmCzzMShqGe5QZ9yCSzpWL98gN13v4wP0k=.11dd8d06-18a6-4577-8342-66632cea0b6e@github.com>
Message-ID: <fdsQ-1OvkyT9GAqkCuJ9s6fHAv77ozdDSzMtNz9OZnI=.e0a9d230-95b1-4230-a9bc-175227e7e776@github.com>

> # Stable Values & Collections (Internal)
> 
> ## Summary
> This PR proposes to introduce an internal _Stable Values & Collections_ API, which provides immutable value holders where elements are initialized _at most once_. Stable Values & Collections offer the performance and safety benefits of final fields while offering greater flexibility as to the timing of initialization.
> 
> ## Goals
>  * Provide an easy and intuitive API to describe value holders that can change at most once.
>  * Decouple declaration from initialization without significant footprint or performance penalties.
>  * Reduce the amount of static initializer and/or field initialization code.
>  * Uphold integrity and consistency, even in a multi-threaded environment.
>  
> For more details, see the draft JEP: https://openjdk.org/jeps/8312611
> 
> ## Performance 
> Performance compared to instance variables using two `AtomicReference` and two protected by double-checked locking under concurrent access by all threads:
> 
> 
> Benchmark                                      Mode  Cnt      Score      Error   Units
> StableBenchmark.atomic                        thrpt   10    259.478 ?   36.809  ops/us
> StableBenchmark.dcl                           thrpt   10    225.710 ?   26.638  ops/us
> StableBenchmark.stable                        thrpt   10   4382.478 ? 1151.472  ops/us <- StableValue significantly faster
> 
> 
> Performance compared to static variables protected by `AtomicReference`, class-holder idiom holder, and double-checked locking (all threads):
> 
> 
> Benchmark                                      Mode  Cnt      Score      Error   Units
> StableStaticBenchmark.atomic                  thrpt   10   6487.835 ?  385.639  ops/us
> StableStaticBenchmark.dcl                     thrpt   10   6605.239 ?  210.610  ops/us
> StableStaticBenchmark.stable                  thrpt   10  14338.239 ? 1426.874  ops/us
> StableStaticBenchmark.staticCHI               thrpt   10  13780.341 ? 1839.651  ops/us
> 
> 
> Performance for stable lists (thread safe) in both instance and static contexts whereby we access a single value compared to `ArrayList` instances (which are not thread-safe) (all threads):
> 
> 
> Benchmark                                      Mode  Cnt      Score      Error   Units
> StableListElementBenchmark.instanceArrayList  thrpt   10   5812.992 ? 1169.730  ops/us
> StableListElementBenchmark.instanceList       thrpt   10   4818.643 ?  704.893  ops/us
> StableListElementBenchmark.staticArrayList    thrpt   10   7614.741 ?  564.777  ops/us
> StableListElementBe...

Per Minborg has updated the pull request incrementally with one additional commit since the last revision:

  Use byte for storing state and compute flags

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/18794/files
  - new: https://git.openjdk.org/jdk/pull/18794/files/058cfddf..80b7e081

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18794&range=09
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18794&range=08-09

  Stats: 42 lines in 2 files changed: 11 ins; 17 del; 14 mod
  Patch: https://git.openjdk.org/jdk/pull/18794.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18794/head:pull/18794

PR: https://git.openjdk.org/jdk/pull/18794

From pavel.rappo at oracle.com  Thu May 16 10:08:18 2024
From: pavel.rappo at oracle.com (Pavel Rappo)
Date: Thu, 16 May 2024 10:08:18 +0000
Subject: [External] : Re: Generalizing binary search
In-Reply-To: <CAL-BTSqMmDvnQA7EUuFj-Ob8tmTuSs9yM=5c=rWt+3qj1N0XFw@mail.gmail.com>
References: <CANghgrR9d524yo7pPKNmvG_LU0hzxrFhQZZPdC1TF7Y_Q_rMeA@mail.gmail.com>
 <0B6F859C-1B4C-4FCD-87CA-82B2A5072C99@oracle.com>
 <CAL-BTSqMmDvnQA7EUuFj-Ob8tmTuSs9yM=5c=rWt+3qj1N0XFw@mail.gmail.com>
Message-ID: <C223AA95-B229-4DC7-A578-3297F9169882@oracle.com>

Since you replied to my message rather than to David's, I assume you had seen the [issue] I linked.

Masquerading an arbitrary binary search as a binary search on a list -- a random access list, as Louis noted correctly -- can do something for you:

        class Element implements Comparable<Element> { /* ... */ }

        class MyList extends AbstractList<Element>
                implements java.util.RandomAccess {

            @Override
            public int size() {
                return Integer.MAX_VALUE;
            }

            @Override
            public Element get(int index) {
                return /* arbitrary computation */
            }
        }

        int idx = Collections.binarySearch(new MyList().subList(0, 1024),
                new Element( /* ... */ ));

But it's a trick which can do only so much; for instance:

  - it cannot help you find a lower or an upper bound (i.e. the left-most or right-most occurrence of a non-unique key),
  - it is hard-to-read and error-prone in its own way

[issue]: https://bugs.openjdk.org/browse/JDK-8326330

> On 15 May 2024, at 23:19, Mateusz Romanowski <romanowski.mateusz at gmail.com> wrote:
> 
> Hi,
> I would say it is not worth any effort.
> 
> One can easily write an ad-hoc *local* adapter extending `java.util.AbstractList`..
> .. and immediately invoke existing `java.util.Collections::binarySearch` method.
> 
> Cheers,
> MR
> 
> On Thu, Apr 25, 2024 at 9:09?PM Pavel Rappo <pavel.rappo at oracle.com> wrote:
> 
> 
> > On 25 Apr 2024, at 19:41, David Lloyd <david.lloyd at redhat.com> wrote:
> > 
> > The JDK contains a few collection- and array-oriented implementations of binary search. For the most part, they all work the same way: search the target "thing" by index using the obvious bisection strategy, returning either /index/ or /-index-1/ depending on whether it was found at the end of the search.
> > 
> > However, if you're doing a binary search on a thing that is not a list or an array, you have two choices: try to make the thing you're searching on implement List (often infeasible) or write your own binary search.
> > 
> > I'm really tired of writing my own binary search. I've probably done it 50 times by now, each one using a slightly different access and/or compare strategy, and every time is a new chance to typo something or get something backwards, leading to irritating debugging sessions and higher dentist bills.
> 
> Can we safely say that it sets your teeth on edge?
> 
> > It got me to thinking that it wouldn't be too hard to make a "general" binary search which can search on anything, so that's what I did. I was thinking that it might be interesting to try adding this into the JDK somehow.
> > 
> > This implementation is more or less what I now copy & paste to different projects at the moment:
> > 
> >     public static <C, T> int binarySearch(C collection, int start, int end, T key, Comparator<? super T> cmp, IntGetter<C, T> getter) {
> >         int low = start;
> >         int high = end - 1;
> >         while (low <= high) {
> >             int mid = low + high >>> 1;
> >             int res = cmp.compare(getter.get(collection, mid), key);
> >             if (res < 0) {
> >                 low = mid + 1;
> >             } else if (res > 0) {
> >                 high = mid - 1;
> >             } else {
> >                 return mid;
> >             }
> >         }
> >         return -low - 1;
> >     }
> >     // (Plus variations for `Comparable` keys and long indices)
> > 
> > A key problem with this approach is that in the JDK, there is no `ObjIntFunction<T, R>` or `ObjLongFunction<T, R>` which would be necessary to implement the "getter" portion of the algorithm (despite the existence of the analogous `ObjIntConsumer<T>` and `ObjLongConsumer<T>`). So, I also have to copy/paste a `IntGetter<T, R>`/`LongGetter<T, R>` as well, which is annoying.
> > 
> > A slightly less-good approach is for the general `binarySearch` method to accept a `IntFunction<T>`/`LongFunction<T>`, and drop the `C collection` parameter, like this:
> > 
> >     public static <T> int binarySearch(int start, int end, T key, Comparator<? super T> cmp, IntFunction<T> getter) { ... }
> > 
> > In this case, we can use the function types that the JDK already provides, but we would very likely have to also create a capturing lambda (e.g. `myList::get` instead of `List::get`). Maybe this isn't that bad of a compromise.
> > 
> > It would be possible to replace the existing `binarySearch` implementations with delegating calls to a generalized implementation. For `Collections`, the indexed version uses `List::get` and the iterator version uses a helper lambda to move the iterator and get the result. For arrays, a lambda would be provided which gets the corresponding array element. If the non-capturing variant is used, then (on paper at least) this version should perform similarly to the existing implementations, with less code needed overall. However, if a capturing lambda is required (due to the aforementioned lack of `ObjXFunction`), then this could be slightly worse-performing than the existing implementation due to the construction (and maybe dispatch) overhead of the lambda. Some real-world benchmarks would have to be written with various-sized data sets.
> > 
> > It would also be possible to produce primitive variations which operate on int, float, long, and double values, using existing functions if capturing is deemed "OK". It is also possible to produce a variation which uses a `long` for the index, for huge data sets (for example, very large mapped files using `MemorySegment`).
> > 
> > Also unclear is: where would it live? `Collections`? Somewhere else?
> > 
> > Any thoughts/opinions would be appreciated (even if they are along the lines of "it's not worth the effort"). Particularly, any insight would be appreciated as to whether or not this kind of hypothetical enhancement would warrant a JEP (I wouldn't think so, but I'm no expert at such assessments).
> > 
> > --
> > - DML ? he/him
> 
> Have a look at this recently filed issue: https://bugs.openjdk.org/browse/JDK-8326330
> 
> -Pavel
> 
> 


From jpai at openjdk.org  Thu May 16 10:24:03 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 16 May 2024 10:24:03 GMT
Subject: RFR: 8332101: Add an `@since` to `StandardOperation:REMOVE` in
 `jdk.dynalink`
In-Reply-To: <_rgUeIEaYmFmB8IcPGHq-B-ZPAx1ulW9cXsuV8EabZU=.0321aff4-91ff-42b3-aa82-bc61c7d42fe9@github.com>
References: <_rgUeIEaYmFmB8IcPGHq-B-ZPAx1ulW9cXsuV8EabZU=.0321aff4-91ff-42b3-aa82-bc61c7d42fe9@github.com>
Message-ID: <4o32JcROwo0vnuNGti85MR3qrOQ8nZIbua5d1G1KbTQ=.34081db5-cb26-4347-ba52-6c1e1febb59c@github.com>

On Sat, 11 May 2024 15:39:04 GMT, Nizar Benalla <duke at openjdk.org> wrote:

> Code cleanup, please review this simple change. I split my changes into 1 PR per module to make reviewing simpler.
> To help with the review, this was added back in https://bugs.openjdk.org/browse/JDK-8191905
> TIA

The change looks good to me. `StandardOperation.REMOVE` was introduced through https://bugs.openjdk.org/browse/JDK-8191905 which was a JDK 10 change, so matches with the proposed change in this PR.

-------------

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19189#pullrequestreview-2060312959

From duke at openjdk.org  Thu May 16 10:32:06 2024
From: duke at openjdk.org (Sunmisc Unsafe)
Date: Thu, 16 May 2024 10:32:06 GMT
Subject: RFR: 8322732: ForkJoinPool may underutilize cores in async mode
 [v2]
In-Reply-To: <1h7ssJJnGUbpqORLsdM_Udcl2dqYsrjuXP6ZPTH_bVo=.ce5a42ba-4eae-4430-9f7d-b6036a45ef9b@github.com>
References: <xRyDMAsSZ7obqpr3Aoc5qrHqILeJMxFVCeiRdctMI3U=.d5d3cd56-32eb-4431-ac01-081822fc86c6@github.com>
 <1h7ssJJnGUbpqORLsdM_Udcl2dqYsrjuXP6ZPTH_bVo=.ce5a42ba-4eae-4430-9f7d-b6036a45ef9b@github.com>
Message-ID: <t2Yzp7nujqzRe7bo3xKjoJqR5_9CdQgHhsBNbuBkBdM=.4dbcc790-7134-4421-b798-4bc589c41d32@github.com>

On Sun, 12 May 2024 13:12:24 GMT, Doug Lea <dl at openjdk.org> wrote:

>> This set of changes address causes of poor utilization with small numbers of cores due to overly aggressive contention avoidance. A number of further adjustments were needed to still avoid most contention effects in deployments with large numbers of cores
>
> Doug Lea has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address review comments

Maybe I don't quite understand, or I don't have proof, But wouldn't it be better if invokeAll in FIFO mode (asyncMode) traverses the Future list as a FIFO (currently it traverses in LIFO order)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19131#issuecomment-2114836374

From jpai at openjdk.org  Thu May 16 10:37:05 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 16 May 2024 10:37:05 GMT
Subject: RFR: 8332086: Remove the usage of ServiceLoader in
 j.u.r.RandomGeneratorFactory [v5]
In-Reply-To: <ZasWP14ViFxaPqk_x3rmDgVFocTX9_aAP1W_kplDjbE=.b5fa3a6a-c303-4fe7-afbe-01700d4a7e85@github.com>
References: <hfB86NksORc-aC6zVxHel_QQd_9aB629SfQjXvl6q5U=.e31daa4b-5cf6-4f3f-a757-79e818a18978@github.com>
 <ZasWP14ViFxaPqk_x3rmDgVFocTX9_aAP1W_kplDjbE=.b5fa3a6a-c303-4fe7-afbe-01700d4a7e85@github.com>
Message-ID: <2Tv7yoSkIoEuQX2GZuyBnAdGHSpTKCGXV0_K0_UPiks=.dff4cf04-3a5d-4afc-8057-9cebb9b61ddd@github.com>

On Wed, 15 May 2024 09:51:23 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> All random number generator algorithms are implemented in module `java.base`. The usage of `ServiceLoader` in `j.u.r.RandomGeneratorFactory` is no longer needed.
>
> Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Small documentation changes.

src/java.base/share/classes/java/util/random/RandomGeneratorFactory.java line 204:

> 202:                     new RandomGeneratorProperties(rgClass, name, group,
> 203:                             i, j, k, equidistribution,
> 204:                             flags | (rgClass.isAnnotationPresent(Deprecated.class) ? DEPRECATED : 0)));

Hello Raffaello, this is the final remaining reflection usage and even this I think isn't required now that all the random generator implementations reside within java.base as an implementation detail.

I think we should just skip this annotation check here and set `DEPRECATED` bit on the `flags` to `0` for all implementations. When/if we do deprecate any of the random generators, we can just come here and switch that bit to on for the specific random generator when instantiating this `RandomGeneratorProperties` record. I had a brief look at the code and the documentation in `package-info.java` of `java/util/random` and we don't mention that we rely on the `@Deprecated`  annotation to determine whether an algorithm is deprecated. I think that's a good thing.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19212#discussion_r1603101449

From duke at openjdk.org  Thu May 16 10:39:09 2024
From: duke at openjdk.org (ExE Boss)
Date: Thu, 16 May 2024 10:39:09 GMT
Subject: RFR: 8330465: Stable Values and Collections (Internal) [v10]
In-Reply-To: <fdsQ-1OvkyT9GAqkCuJ9s6fHAv77ozdDSzMtNz9OZnI=.e0a9d230-95b1-4230-a9bc-175227e7e776@github.com>
References: <-KSimQo5kkmCzzMShqGe5QZ9yCSzpWL98gN13v4wP0k=.11dd8d06-18a6-4577-8342-66632cea0b6e@github.com>
 <fdsQ-1OvkyT9GAqkCuJ9s6fHAv77ozdDSzMtNz9OZnI=.e0a9d230-95b1-4230-a9bc-175227e7e776@github.com>
Message-ID: <6imEhvO6pddKDrwPo8m6X1vyClmUHgDU8NNvWllwmS8=.893489ed-9270-4b57-a3e3-5c81ac4f4c03@github.com>

On Thu, 16 May 2024 09:01:22 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> # Stable Values & Collections (Internal)
>> 
>> ## Summary
>> This PR proposes to introduce an internal _Stable Values & Collections_ API, which provides immutable value holders where elements are initialized _at most once_. Stable Values & Collections offer the performance and safety benefits of final fields while offering greater flexibility as to the timing of initialization.
>> 
>> ## Goals
>>  * Provide an easy and intuitive API to describe value holders that can change at most once.
>>  * Decouple declaration from initialization without significant footprint or performance penalties.
>>  * Reduce the amount of static initializer and/or field initialization code.
>>  * Uphold integrity and consistency, even in a multi-threaded environment.
>>  
>> For more details, see the draft JEP: https://openjdk.org/jeps/8312611
>> 
>> ## Performance 
>> Performance compared to instance variables using two `AtomicReference` and two protected by double-checked locking under concurrent access by all threads:
>> 
>> 
>> Benchmark                                      Mode  Cnt      Score      Error   Units
>> StableBenchmark.atomic                        thrpt   10    259.478 ?   36.809  ops/us
>> StableBenchmark.dcl                           thrpt   10    225.710 ?   26.638  ops/us
>> StableBenchmark.stable                        thrpt   10   4382.478 ? 1151.472  ops/us <- StableValue significantly faster
>> 
>> 
>> Performance compared to static variables protected by `AtomicReference`, class-holder idiom holder, and double-checked locking (all threads):
>> 
>> 
>> Benchmark                                      Mode  Cnt      Score      Error   Units
>> StableStaticBenchmark.atomic                  thrpt   10   6487.835 ?  385.639  ops/us
>> StableStaticBenchmark.dcl                     thrpt   10   6605.239 ?  210.610  ops/us
>> StableStaticBenchmark.stable                  thrpt   10  14338.239 ? 1426.874  ops/us
>> StableStaticBenchmark.staticCHI               thrpt   10  13780.341 ? 1839.651  ops/us
>> 
>> 
>> Performance for stable lists (thread safe) in both instance and static contexts whereby we access a single value compared to `ArrayList` instances (which are not thread-safe) (all threads):
>> 
>> 
>> Benchmark                                      Mode  Cnt      Score      Error   Units
>> StableListElementBenchmark.instanceArrayList  thrpt   10   5812.992 ? 1169.730  ops/us
>> StableListElementBenchmark.instanceList       thrpt   10   4818.643 ?  704.893  ops/us
>> StableListElementBenchmark...
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use byte for storing state and compute flags

src/java.base/share/classes/jdk/internal/lang/stable/StableAccess.java line 63:

> 61:                                                    Function<? super T, ? extends R> original) {
> 62:         return new MemoizedFunction<>(stableMap, original);
> 63:     }

Maybe?also rename?these?
Suggestion:

    public static <T> Supplier<T> memoizedSupplier(StableValue<T> stable,
                                                   Supplier<? extends T> original) {
        return new MemoizedSupplier<>(stable, original);
    }

    public static <R> IntFunction<R> memoizedIntFunction(List<StableValue<R>> stableList,
                                                         IntFunction<? extends R> original) {
        return new MemoizedIntFunction<>(stableList, original);
    }

    public static <T, R> Function<T, R> memoizedFunction(Map<T, StableValue<R>> stableMap,
                                                         Function<? super T, ? extends R> original) {
        return new MemoizedFunction<>(stableMap, original);
    }

src/jdk.unsupported/share/classes/sun/misc/Unsafe.java line 729:

> 727:                 }
> 728:             }
> 729:         }

Given?that the?[`Class?::forName?(String, boolean, ClassLoader)`] method doesn?t?care about?whether the?requested?class is?actually exported to?the?caller, it?s?possible to?do the?following:
Suggestion:

        final class Holder {
            static final Class<?> TRUSTED_FIELD_TYPE;
            static {
                PrivilegedAction<ClassLoader> getPlatformClassLoader = ClassLoader::getPlatformClassLoader;
                @SuppressWarnings("removal")
                ClassLoader platformClassLoader = AccessController.doPrivileged(getPlatformClassLoader);
                
                try {
                    TRUSTED_FIELD_TYPE = Class.forName("jdk.internal.lang.stable.TrustedFieldType",
                        false, platformClassLoader);
                } catch (ClassNotFoundException e) {
                    throw new AssertionError(e);
                }
            }
        }

        Class<?> declaringClass = f.getDeclaringClass();
        if (declaringClass.isHidden()) {
            throw new UnsupportedOperationException("can't get base address on a hidden class: " + f);
        }
        if (declaringClass.isRecord()) {
            throw new UnsupportedOperationException("can't get base address on a record class: " + f);
        }
        Class<?> fieldType = f.getType();
        if (Holder.TRUSTED_FIELD_TYPE.isAssignableFrom(fieldType)) {
            throw new UnsupportedOperationException("can't get field offset for a field of type " + fieldType.getName() + ": " + f);
        }


[`Class?::forName?(String, boolean, ClassLoader)`]: https://docs.oracle.com/en/java/javase/22/docs/api/java.base/java/lang/Class.html#forName(java.lang.String,boolean,java.lang.ClassLoader)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18794#discussion_r1603032451
PR Review Comment: https://git.openjdk.org/jdk/pull/18794#discussion_r1603089512

From duke at openjdk.org  Thu May 16 10:40:07 2024
From: duke at openjdk.org (Nizar Benalla)
Date: Thu, 16 May 2024 10:40:07 GMT
Subject: Integrated: 8332101: Add an `@since` to `StandardOperation:REMOVE` in
 `jdk.dynalink`
In-Reply-To: <_rgUeIEaYmFmB8IcPGHq-B-ZPAx1ulW9cXsuV8EabZU=.0321aff4-91ff-42b3-aa82-bc61c7d42fe9@github.com>
References: <_rgUeIEaYmFmB8IcPGHq-B-ZPAx1ulW9cXsuV8EabZU=.0321aff4-91ff-42b3-aa82-bc61c7d42fe9@github.com>
Message-ID: <AT-wbT-_66KhadUVAcqLeKKzVedxay_5c14j4mQHYRk=.eb1b5f04-88e8-420b-b212-8ce9a0e706cc@github.com>

On Sat, 11 May 2024 15:39:04 GMT, Nizar Benalla <duke at openjdk.org> wrote:

> Code cleanup, please review this simple change. I split my changes into 1 PR per module to make reviewing simpler.
> To help with the review, this was added back in https://bugs.openjdk.org/browse/JDK-8191905
> TIA

This pull request has now been integrated.

Changeset: f9f8d0b4
Author:    Nizar Benalla <nizar.benalla at oracle.com>
Committer: Jaikiran Pai <jpai at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/f9f8d0b48057a02923e36c8e11286b57cc72279e
Stats:     3 lines in 1 file changed: 2 ins; 0 del; 1 mod

8332101: Add an `@since` to `StandardOperation:REMOVE` in `jdk.dynalink`

Reviewed-by: jpai

-------------

PR: https://git.openjdk.org/jdk/pull/19189

From jpai at openjdk.org  Thu May 16 10:54:04 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 16 May 2024 10:54:04 GMT
Subject: RFR: 8332086: Remove the usage of ServiceLoader in
 j.u.r.RandomGeneratorFactory [v5]
In-Reply-To: <ZasWP14ViFxaPqk_x3rmDgVFocTX9_aAP1W_kplDjbE=.b5fa3a6a-c303-4fe7-afbe-01700d4a7e85@github.com>
References: <hfB86NksORc-aC6zVxHel_QQd_9aB629SfQjXvl6q5U=.e31daa4b-5cf6-4f3f-a757-79e818a18978@github.com>
 <ZasWP14ViFxaPqk_x3rmDgVFocTX9_aAP1W_kplDjbE=.b5fa3a6a-c303-4fe7-afbe-01700d4a7e85@github.com>
Message-ID: <4jBupSTpW5j9Ye4i8sV08c5yauOhELbJNHnN2oGFC9Q=.6d42ba3d-a7dd-4a4b-a6ee-5f5c7cf8b1c9@github.com>

On Wed, 15 May 2024 09:51:23 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> All random number generator algorithms are implemented in module `java.base`. The usage of `ServiceLoader` in `j.u.r.RandomGeneratorFactory` is no longer needed.
>
> Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Small documentation changes.

test/jdk/java/util/Random/RandomTestCoverage.java line 179:

> 177:         try {
> 178:             rng = factory.create(12345L);
> 179:         } catch (UnsupportedOperationException ignore) {

I think now that we know for sure which algorithm instances don't support which type of seed value and since throwing `UnsupportedOperationException` is now a specification of the `create(...)` methods, we should probably do something like this:


diff --git a/test/jdk/java/util/Random/RandomTestCoverage.java b/test/jdk/java/util/Random/RandomTestCoverage.java
index be12d188198..6e5c36e13c3 100644
--- a/test/jdk/java/util/Random/RandomTestCoverage.java
+++ b/test/jdk/java/util/Random/RandomTestCoverage.java
@@ -171,8 +171,37 @@ static void coverFactory(RandomGeneratorFactory factory) {
         boolean isSplittable = factory.isSplittable();
 
         coverRandomGenerator(factory.create());
-        coverRandomGenerator(factory.create(12345L));
-        coverRandomGenerator(factory.create(new byte[] {1, 2, 3, 4, 5, 6, 7, 8}));
+
+        String algo = factory.name();
+        // test create(long)
+        switch (algo) {
+            // SecureRandom doesn't have long constructors so we expect
+            // UnsupportedOperationException
+            case "SecureRandom" -> {
+                try {
+                    factory.create(12345L);
+                    throw new AssertionError("RandomGeneratorFactory.create(long) was expected" +
+                            "to throw UnsupportedOperationException for " + algo + " but didn't");
+                } catch (UnsupportedOperationException uoe) {
+                    // expected
+                }
+            }
+            default -> coverRandomGenerator(factory.create(12345L));
+        }
+        // test create(byte[])
+        switch (algo) {
+            // these don't have byte[] constructors so we expect UnsupportedOperationException
+            case "Random", "SplittableRandom" -> {
+                try {
+                    factory.create(new byte[] {1, 2, 3, 4, 5, 6, 7, 8});
+                    throw new AssertionError("RandomGeneratorFactory.create(byte[]) was expected" +
+                            "to throw UnsupportedOperationException for " + algo + " but didn't");
+                } catch (UnsupportedOperationException uoe) {
+                    // expected
+                }
+            }
+            default -> coverRandomGenerator(factory.create(new byte[] {1, 2, 3, 4, 5, 6, 7, 8}));
+        }
     }

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19212#discussion_r1603123836

From jpai at openjdk.org  Thu May 16 11:00:05 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 16 May 2024 11:00:05 GMT
Subject: RFR: 8332086: Remove the usage of ServiceLoader in
 j.u.r.RandomGeneratorFactory [v5]
In-Reply-To: <ZasWP14ViFxaPqk_x3rmDgVFocTX9_aAP1W_kplDjbE=.b5fa3a6a-c303-4fe7-afbe-01700d4a7e85@github.com>
References: <hfB86NksORc-aC6zVxHel_QQd_9aB629SfQjXvl6q5U=.e31daa4b-5cf6-4f3f-a757-79e818a18978@github.com>
 <ZasWP14ViFxaPqk_x3rmDgVFocTX9_aAP1W_kplDjbE=.b5fa3a6a-c303-4fe7-afbe-01700d4a7e85@github.com>
Message-ID: <C2IPYhLezZvbbClOXfTZW1GVqIeB-JhAmLTzojVGMu0=.66b4f9ab-1eb0-41e7-a17b-48157d126a84@github.com>

On Wed, 15 May 2024 09:51:23 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> All random number generator algorithms are implemented in module `java.base`. The usage of `ServiceLoader` in `j.u.r.RandomGeneratorFactory` is no longer needed.
>
> Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Small documentation changes.

test/jdk/java/util/Random/RandomTestCoverage.java line 195:

> 193:     }
> 194: 
> 195:     static void coverDefaults() {

This test method appears to test the calls to `getDefault()` methods on `RandomGeneratorFactory` and `RandomGenerator` classes, but it isn't being called in the test. We should call this method from `main()` to have test coverage for those methods.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19212#discussion_r1603131062

From pminborg at openjdk.org  Thu May 16 11:00:38 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 16 May 2024 11:00:38 GMT
Subject: RFR: 8330465: Stable Values and Collections (Internal) [v11]
In-Reply-To: <-KSimQo5kkmCzzMShqGe5QZ9yCSzpWL98gN13v4wP0k=.11dd8d06-18a6-4577-8342-66632cea0b6e@github.com>
References: <-KSimQo5kkmCzzMShqGe5QZ9yCSzpWL98gN13v4wP0k=.11dd8d06-18a6-4577-8342-66632cea0b6e@github.com>
Message-ID: <5nBuqaRQH0BuxaPOWhrfxaizJLcM8fEDAkoI6sDwzNg=.ee090add-1c7e-4349-b9e3-114acd98a663@github.com>

> # Stable Values & Collections (Internal)
> 
> ## Summary
> This PR proposes to introduce an internal _Stable Values & Collections_ API, which provides immutable value holders where elements are initialized _at most once_. Stable Values & Collections offer the performance and safety benefits of final fields while offering greater flexibility as to the timing of initialization.
> 
> ## Goals
>  * Provide an easy and intuitive API to describe value holders that can change at most once.
>  * Decouple declaration from initialization without significant footprint or performance penalties.
>  * Reduce the amount of static initializer and/or field initialization code.
>  * Uphold integrity and consistency, even in a multi-threaded environment.
>  
> For more details, see the draft JEP: https://openjdk.org/jeps/8312611
> 
> ## Performance 
> Performance compared to instance variables using two `AtomicReference` and two protected by double-checked locking under concurrent access by all threads:
> 
> 
> Benchmark                                      Mode  Cnt      Score      Error   Units
> StableBenchmark.atomic                        thrpt   10    259.478 ?   36.809  ops/us
> StableBenchmark.dcl                           thrpt   10    225.710 ?   26.638  ops/us
> StableBenchmark.stable                        thrpt   10   4382.478 ? 1151.472  ops/us <- StableValue significantly faster
> 
> 
> Performance compared to static variables protected by `AtomicReference`, class-holder idiom holder, and double-checked locking (all threads):
> 
> 
> Benchmark                                      Mode  Cnt      Score      Error   Units
> StableStaticBenchmark.atomic                  thrpt   10   6487.835 ?  385.639  ops/us
> StableStaticBenchmark.dcl                     thrpt   10   6605.239 ?  210.610  ops/us
> StableStaticBenchmark.stable                  thrpt   10  14338.239 ? 1426.874  ops/us
> StableStaticBenchmark.staticCHI               thrpt   10  13780.341 ? 1839.651  ops/us
> 
> 
> Performance for stable lists (thread safe) in both instance and static contexts whereby we access a single value compared to `ArrayList` instances (which are not thread-safe) (all threads):
> 
> 
> Benchmark                                      Mode  Cnt      Score      Error   Units
> StableListElementBenchmark.instanceArrayList  thrpt   10   5812.992 ? 1169.730  ops/us
> StableListElementBenchmark.instanceList       thrpt   10   4818.643 ?  704.893  ops/us
> StableListElementBenchmark.staticArrayList    thrpt   10   7614.741 ?  564.777  ops/us
> StableListElementBe...

Per Minborg has updated the pull request incrementally with one additional commit since the last revision:

  Update src/java.base/share/classes/jdk/internal/lang/stable/StableAccess.java
  
  Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com>

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/18794/files
  - new: https://git.openjdk.org/jdk/pull/18794/files/80b7e081..923e1877

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18794&range=10
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18794&range=09-10

  Stats: 6 lines in 1 file changed: 0 ins; 0 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/18794.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18794/head:pull/18794

PR: https://git.openjdk.org/jdk/pull/18794

From mcimadamore at openjdk.org  Thu May 16 11:03:30 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 16 May 2024 11:03:30 GMT
Subject: RFR: 8331865: Consolidate size and alignment checks in LayoutPath
Message-ID: <CvKkdESp5-uHiuZtQvGortWnzOMV89pfjaCHNBIV4B4=.51ad0f01-2371-48af-b3c6-8a9b80518cdb@github.com>

When creating a nested memory access var handle, we ensure that the segment is accessed at the correct alignment for the root layout being accessed. But we do not ensure that the segment has at least the size of the accessed root layout. Example:


MemoryLayout LAYOUT = sequenceLayout(2, structLayout(JAVA_INT.withName("x"), JAVA_INT.withName("y")));
VarHandle X_HANDLE = LAYOUT.varHandle(PathElement.sequenceElement(), PathElement.groupElement("x"));


If I have a memory segment whose size is 12, I can successfully call X_HANDLE on it with index 1, like so:


MemorySegment segment = Arena.ofAuto().allocate(12);
int x = (int)X_HANDLE.get(segment, 0, 1);


This seems incorrect: after all, the provided segment doesn't have enough space to fit _two_ elements of the nested structs. 

This PR adds checks to detect this kind of scenario earlier, thus improving usability. To achieve this we could, in principle, just tweak `LayoutPath::checkEnclosingLayout` and add the required size check.

But doing so will add yet another redundant check on top of the other already added by [pull/19124](https://git.openjdk.org/jdk/pull/19124). Instead, this PR rethinks how memory segment var handles are created, in order to eliminate redundant checks.

The main observation is that size and alignment checks depend on an _enclosing_ layout. This layout *might* be the very same value layout being accessed (this is the case when e.g. using `JAVA_INT.varHandle()`). But, in the general case, the accessed value layout and the enclosing layout might differ (e.g. think about accessing a struct field).

Furthermore, the enclosing layout check depends on the _base_ offset at which the segment is accessed, _prior_ to any index computation that occurs if the accessed layout path has any open elements. It is important to notice that this base offset is only available when looking at the var handle that is returned to the user. For instance, an indexed var handle with coordinates:


(MemorySegment, long /* base */, long /* index 1 */, long /* index 2 */, long /* index 3 */)


Is obtained through adaptation, by taking a more basic var handle of the form:


(MemorySegment, long /* offset */)


And then injecting the result of the index multiplication into `offset`. As such, we can't add an enclosing layout check inside the var handle returned by `VarHandles::memorySegmentViewHandle`, as doing so will end up seeing the *wrong* offset (e.g. an offset in which the index part has already been mixed in).

The only possibility then, is to remove size and alignment checks from the *raw* var handles returned by `VarHandles::memorySegmentViewHandle`, and perform such checks outside (e.g. in `LayoutPath::dereferenceHandle`). The only checks left in the raw var handles are:

* an alignment check to make sure that the access mode selected by the client is really available - this alignment check is against the alignment of the value layout being selected, and not the enclosing layout alignment (which might be stricter)
* a read-only check, to make sure that write access modes are blocked if the accessed segment is read-only
* liveness/confinement checks, as mandated by ScopedMemoryAccess

Since these check depends on the particular access mode selected by the client, we can't move these checks away from the raw var handle.

These changes come with some consequences:

* Now it is always necessary to adapt a raw var handle, and to insert appropriate size and alignment checks (otherwise OOB access might be possible). As such, `ValueLayouts` also need to call the path layout variant of `MemoryLayout::varHandle`, to make sure that the raw var handle is adapted accordingly, before it is cached in its stable field.
* The var handle cache has been moved from `Utils` to `ValueLayouts::varHandle`. The cache is used (a) to reduce the number of var handle instances created and (b) to make sure that the cached var handle in the `ValueLayout` has stable identity. With respect to (a), while it makes sense to cache "toplevel" var handles (e.g. `JAVA_INT.varHandle()`) the cost/benefit ratio for caching nested var handles seem more unfavourable, as the same var handle can be reused with different enclosing layouts, leading to different checks. Ultimately, all nested var handles will require some kind of adaptation, so it doesn't seem too crucial to have a deeper level of caching here.
* The order in which exceptions are thrown might be slightly different. This is because the size/alignment checks now take place _before_ the raw var handle is even called. This caused a bunch of small updates in code and tests.
* It used to be possible to create a sequence layout with maximal size, like `MemoryLayout.sequenceLayout(Long.MAX_VALUE, JAVA_LONG)`, and derive an indexed var handle from that layout. Since there used to be no enclosing layout size check, access to the sequence element was allowed, as long as the index computation did not result in an offset outside the boundary of the accessed memory segment. This is now no longer the case: when selecting an element from the above layout, the implementation will make sure that the accessed segment indeed has the size of that sequence layout (which will probably lead to a `IndexOutOfBoundException`). To do indexed access on an unbounded sequence, the `MemoryLayout::arrayElementVarHandle` should be used instead (but this is the norm anyway for such cases).

-------------

Commit messages:
 - Revert commented lines in test
 - Simplify var handle code
 - Revert test changes
 - Cleanup spurious changes
 - Only use nested var handles
 - Add tests for nested layout size check
 - Drop spurious changes
 - cleanup javadoc
 - Fix benchmark
 - Cache both nested and toplevel var handles
 - ... and 7 more: https://git.openjdk.org/jdk/compare/61aff6db...236007c3

Changes: https://git.openjdk.org/jdk/pull/19251/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19251&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8331865
  Stats: 199 lines in 12 files changed: 73 ins; 37 del; 89 mod
  Patch: https://git.openjdk.org/jdk/pull/19251.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19251/head:pull/19251

PR: https://git.openjdk.org/jdk/pull/19251

From mcimadamore at openjdk.org  Thu May 16 11:03:31 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 16 May 2024 11:03:31 GMT
Subject: RFR: 8331865: Consolidate size and alignment checks in LayoutPath
In-Reply-To: <CvKkdESp5-uHiuZtQvGortWnzOMV89pfjaCHNBIV4B4=.51ad0f01-2371-48af-b3c6-8a9b80518cdb@github.com>
References: <CvKkdESp5-uHiuZtQvGortWnzOMV89pfjaCHNBIV4B4=.51ad0f01-2371-48af-b3c6-8a9b80518cdb@github.com>
Message-ID: <Q_IQrw-ps1dW9pjCs7HuAGU8Mcn8mfMO2jb0AAcsroE=.b81b0105-2c22-4f75-abe1-e2ee91186dec@github.com>

On Wed, 15 May 2024 15:43:45 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> When creating a nested memory access var handle, we ensure that the segment is accessed at the correct alignment for the root layout being accessed. But we do not ensure that the segment has at least the size of the accessed root layout. Example:
> 
> 
> MemoryLayout LAYOUT = sequenceLayout(2, structLayout(JAVA_INT.withName("x"), JAVA_INT.withName("y")));
> VarHandle X_HANDLE = LAYOUT.varHandle(PathElement.sequenceElement(), PathElement.groupElement("x"));
> 
> 
> If I have a memory segment whose size is 12, I can successfully call X_HANDLE on it with index 1, like so:
> 
> 
> MemorySegment segment = Arena.ofAuto().allocate(12);
> int x = (int)X_HANDLE.get(segment, 0, 1);
> 
> 
> This seems incorrect: after all, the provided segment doesn't have enough space to fit _two_ elements of the nested structs. 
> 
> This PR adds checks to detect this kind of scenario earlier, thus improving usability. To achieve this we could, in principle, just tweak `LayoutPath::checkEnclosingLayout` and add the required size check.
> 
> But doing so will add yet another redundant check on top of the other already added by [pull/19124](https://git.openjdk.org/jdk/pull/19124). Instead, this PR rethinks how memory segment var handles are created, in order to eliminate redundant checks.
> 
> The main observation is that size and alignment checks depend on an _enclosing_ layout. This layout *might* be the very same value layout being accessed (this is the case when e.g. using `JAVA_INT.varHandle()`). But, in the general case, the accessed value layout and the enclosing layout might differ (e.g. think about accessing a struct field).
> 
> Furthermore, the enclosing layout check depends on the _base_ offset at which the segment is accessed, _prior_ to any index computation that occurs if the accessed layout path has any open elements. It is important to notice that this base offset is only available when looking at the var handle that is returned to the user. For instance, an indexed var handle with coordinates:
> 
> 
> (MemorySegment, long /* base */, long /* index 1 */, long /* index 2 */, long /* index 3 */)
> 
> 
> Is obtained through adaptation, by taking a more basic var handle of the form:
> 
> 
> (MemorySegment, long /* offset */)
> 
> 
> And then injecting the result of the index multiplication into `offset`. As such, we can't add an enclosing layout check inside the var handle returned by `VarHandles::memorySegmentViewHandle`, as doing so will end up seeing the *wrong* offset (e.g. an offset in which the index part has already been mixed in)...

src/java.base/share/classes/java/lang/invoke/X-VarHandleSegmentView.java.template line 100:

> 98: 
> 99:     @ForceInline
> 100:     static AbstractMemorySegmentImpl checkReadOnly(Object obb, boolean ro) {

This and the following methods are the bulk of the changes in this template. That is, we no longer check size and alignment of the accessed segment. Every other change in this template is needed to get rid of fields and parameters that are no longer used.

src/java.base/share/classes/jdk/internal/foreign/AbstractMemorySegmentImpl.java line 831:

> 829:     @Override
> 830:     public void set(AddressLayout layout, long offset, MemorySegment value) {
> 831:         Objects.requireNonNull(value);

This has been added, otherwise it would be possible to pass a `null` as the value of `value`, and not get an NPE, in case e.g. the alignment of the segment is incorrect (because we now check that before we even try to perform the memory access).

test/jdk/java/foreign/TestAccessModes.java line 62:

> 60:         } catch (IllegalArgumentException ex) {
> 61:             // access is unaligned
> 62:             assertTrue(segment.maxByteAlignment() < layout.byteAlignment());

Note: this change is required because, before this PR, we used to issue UOE for a bad access mode regardless of the alignment with which we accessed the segment (well, only for toplevel var handles). Now we uniformly check alignment _before_ access mode, for both toplevel and nested var handles, so this assertion needed to be tweaked.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19251#discussion_r1603127240
PR Review Comment: https://git.openjdk.org/jdk/pull/19251#discussion_r1603120915
PR Review Comment: https://git.openjdk.org/jdk/pull/19251#discussion_r1603124981

From mcimadamore at openjdk.org  Thu May 16 11:11:02 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 16 May 2024 11:11:02 GMT
Subject: RFR: 8331865: Consolidate size and alignment checks in LayoutPath
In-Reply-To: <Q_IQrw-ps1dW9pjCs7HuAGU8Mcn8mfMO2jb0AAcsroE=.b81b0105-2c22-4f75-abe1-e2ee91186dec@github.com>
References: <CvKkdESp5-uHiuZtQvGortWnzOMV89pfjaCHNBIV4B4=.51ad0f01-2371-48af-b3c6-8a9b80518cdb@github.com>
 <Q_IQrw-ps1dW9pjCs7HuAGU8Mcn8mfMO2jb0AAcsroE=.b81b0105-2c22-4f75-abe1-e2ee91186dec@github.com>
Message-ID: <Y_3YBlXV97_Vizlifsd6ysI9zldn6fyXnw08__2UGds=.a6f0991e-7fce-4846-a5df-c2c6d29b4948@github.com>

On Thu, 16 May 2024 10:54:15 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> When creating a nested memory access var handle, we ensure that the segment is accessed at the correct alignment for the root layout being accessed. But we do not ensure that the segment has at least the size of the accessed root layout. Example:
>> 
>> 
>> MemoryLayout LAYOUT = sequenceLayout(2, structLayout(JAVA_INT.withName("x"), JAVA_INT.withName("y")));
>> VarHandle X_HANDLE = LAYOUT.varHandle(PathElement.sequenceElement(), PathElement.groupElement("x"));
>> 
>> 
>> If I have a memory segment whose size is 12, I can successfully call X_HANDLE on it with index 1, like so:
>> 
>> 
>> MemorySegment segment = Arena.ofAuto().allocate(12);
>> int x = (int)X_HANDLE.get(segment, 0, 1);
>> 
>> 
>> This seems incorrect: after all, the provided segment doesn't have enough space to fit _two_ elements of the nested structs. 
>> 
>> This PR adds checks to detect this kind of scenario earlier, thus improving usability. To achieve this we could, in principle, just tweak `LayoutPath::checkEnclosingLayout` and add the required size check.
>> 
>> But doing so will add yet another redundant check on top of the other already added by [pull/19124](https://git.openjdk.org/jdk/pull/19124). Instead, this PR rethinks how memory segment var handles are created, in order to eliminate redundant checks.
>> 
>> The main observation is that size and alignment checks depend on an _enclosing_ layout. This layout *might* be the very same value layout being accessed (this is the case when e.g. using `JAVA_INT.varHandle()`). But, in the general case, the accessed value layout and the enclosing layout might differ (e.g. think about accessing a struct field).
>> 
>> Furthermore, the enclosing layout check depends on the _base_ offset at which the segment is accessed, _prior_ to any index computation that occurs if the accessed layout path has any open elements. It is important to notice that this base offset is only available when looking at the var handle that is returned to the user. For instance, an indexed var handle with coordinates:
>> 
>> 
>> (MemorySegment, long /* base */, long /* index 1 */, long /* index 2 */, long /* index 3 */)
>> 
>> 
>> Is obtained through adaptation, by taking a more basic var handle of the form:
>> 
>> 
>> (MemorySegment, long /* offset */)
>> 
>> 
>> And then injecting the result of the index multiplication into `offset`. As such, we can't add an enclosing layout check inside the var handle returned by `VarHandles::memorySegmentViewHandle`, as doing so will end up seeing the *wrong* off...
>
> src/java.base/share/classes/java/lang/invoke/X-VarHandleSegmentView.java.template line 100:
> 
>> 98: 
>> 99:     @ForceInline
>> 100:     static AbstractMemorySegmentImpl checkReadOnly(Object obb, boolean ro) {
> 
> This and the following methods are the bulk of the changes in this template. That is, we no longer check size and alignment of the accessed segment. Every other change in this template is needed to get rid of fields and parameters that are no longer used.

Note: we don't even check for overflows, e.g. `offset < 0`. The reasoning here is that all layouts check for overflow on construction, so it's never possible to construct a layout whose size is greater than `Long.MAX_VALUE`. This constraint also affects computation for indexed var handles, since all the `long` indices corresponding to open path elements are checked against their bounds (and their bounds must be small enough so that the enclosing layout has a size smaller than `Long.MAX_VALUE`).

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19251#discussion_r1603142096

From liach at openjdk.org  Thu May 16 11:18:10 2024
From: liach at openjdk.org (Chen Liang)
Date: Thu, 16 May 2024 11:18:10 GMT
Subject: RFR: 8330465: Stable Values and Collections (Internal) [v5]
In-Reply-To: <5zoKgO17_hUh9-UveP-yo82Sh2Jrk2Z_3K8rsarDk10=.03e40aaa-cac7-4ef6-b9ca-131fd338a0a8@github.com>
References: <-KSimQo5kkmCzzMShqGe5QZ9yCSzpWL98gN13v4wP0k=.11dd8d06-18a6-4577-8342-66632cea0b6e@github.com>
 <VGuyX6AyE1gAq2nsCLIyOxnHbYbAAW8YvKk8mAjKnos=.c5ea169b-dfba-4ac8-8e91-7d897708ea5d@github.com>
 <sWc2qReuqEhBnu0fHIg75bC8WJkp56HSO9x807NgZoA=.2041706f-383d-44d0-93c6-2eda82329869@github.com>
 <5zoKgO17_hUh9-UveP-yo82Sh2Jrk2Z_3K8rsarDk10=.03e40aaa-cac7-4ef6-b9ca-131fd338a0a8@github.com>
Message-ID: <RfYvs1cjpROShsbMvXNsqqazCLawHMmgyGqDu0WWyG0=.93faddd9-a1a1-438e-b81d-dcdc87f491ed@github.com>

On Thu, 16 May 2024 07:11:20 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/lang/stable/StableValueImpl.java line 139:
>> 
>>> 137:             case NON_NULL: { return valueVolatile(); }
>>> 138:             case ERROR:    { throw StableUtil.error(this); }
>>> 139:             case DUMMY:    { throw shouldNotReachHere(); }
>> 
>> Redundant branch?
>
> The idea here is to have the most likely value in the middle... Not sure if that motivates the added complexity though.

Is there any refernce on how/why the middle entry in a tableswitch instruction is the fastest?

>> src/java.base/share/classes/jdk/internal/lang/stable/StableValueImpl.java line 236:
>> 
>>> 234:                 } catch (Throwable t) {
>>> 235:                     putState(ERROR);
>>> 236:                     putMutex(t.getClass());
>> 
>> Should we cache the exception instance so we can rethrow it in future ERROR state `orThrow` calls?
>
> We considered recording the entire exception instance but for security reasons, we ended up just recording the type of exception. I will add a comment explaining this in the code.

Thanks for this clarification. Makes sense.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18794#discussion_r1603149806
PR Review Comment: https://git.openjdk.org/jdk/pull/18794#discussion_r1603150592

From liach at openjdk.org  Thu May 16 11:18:08 2024
From: liach at openjdk.org (Chen Liang)
Date: Thu, 16 May 2024 11:18:08 GMT
Subject: RFR: 8330465: Stable Values and Collections (Internal) [v5]
In-Reply-To: <_G7nE_OAMl9WSkAz21UDYHAlCRVeHN2ZmM0FR7Bmxtw=.ea94e982-3e9a-4c0e-8523-11372474d497@github.com>
References: <-KSimQo5kkmCzzMShqGe5QZ9yCSzpWL98gN13v4wP0k=.11dd8d06-18a6-4577-8342-66632cea0b6e@github.com>
 <VGuyX6AyE1gAq2nsCLIyOxnHbYbAAW8YvKk8mAjKnos=.c5ea169b-dfba-4ac8-8e91-7d897708ea5d@github.com>
 <sWc2qReuqEhBnu0fHIg75bC8WJkp56HSO9x807NgZoA=.2041706f-383d-44d0-93c6-2eda82329869@github.com>
 <hfCAtNQs4eEApF71b4FKsHWQwl20eYeURk_AljjT-q0=.6753684c-6275-4db5-99ca-b1190fbe5b95@github.com>
 <_G7nE_OAMl9WSkAz21UDYHAlCRVeHN2ZmM0FR7Bmxtw=.ea94e982-3e9a-4c0e-8523-11372474d497@github.com>
Message-ID: <_I8ZxFiUZ3bygkA-iDH29xEmkqoy0Dm-_g0iAVRkoro=.680467aa-a061-4f17-8fcd-a60a829afa59@github.com>

On Thu, 16 May 2024 06:54:26 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> Maybe the?`state?==?NULL` check should?be?moved before?`v?!=?null`, as?the?**JIT** doesn?t?constant?fold `null`?[`@Stable`]?values:
>> https://github.com/openjdk/jdk/blob/8a4315f833f3700075d65fae6bc566011c837c07/src/java.base/share/classes/jdk/internal/vm/annotation/Stable.java#L41-L44  https://github.com/openjdk/jdk/blob/8a4315f833f3700075d65fae6bc566011c837c07/src/java.base/share/classes/jdk/internal/vm/annotation/Stable.java#L64-L71
>> 
>> [`@Stable`]: https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/jdk/internal/vm/annotation/Stable.java
>
> It seems reasonable to assume `null` values are not constant-folded. For straight-out-of-the-box usage, there is no apparent significant difference as indicated by a new benchmark I just added:
> 
> 
> Benchmark                                  Mode  Cnt      Score      Error   Units
> StableStaticBenchmark.atomic              thrpt   10   5729.683 ?  502.023  ops/us
> StableStaticBenchmark.dcl                 thrpt   10   6069.222 ?  951.784  ops/us
> StableStaticBenchmark.dclHolder           thrpt   10   5502.102 ? 1630.627  ops/us
> StableStaticBenchmark.stable              thrpt   10  12737.158 ? 1746.456  ops/us <- Non-null benchmark
> StableStaticBenchmark.stableHolder        thrpt   10  12053.978 ? 1421.527  ops/us
> StableStaticBenchmark.stableList          thrpt   10  12443.870 ? 2084.607  ops/us
> StableStaticBenchmark.stableNull          thrpt   10  13164.232 ?  591.284  ops/us <- Added null benchmark
> StableStaticBenchmark.stableRecordHolder  thrpt   10  13638.893 ? 1250.895  ops/us
> StableStaticBenchmark.staticCHI           thrpt   10  13639.220 ? 1190.922  ops/us
> 
> 
> If the `null` value participates in a much larger constant-folding tree, there might be a significant difference. I am afraid moving the order would have detrimental effects on instance performance:
> 
> Checking value first:
> 
> 
> Benchmark                           Mode  Cnt     Score      Error   Units
> StableBenchmark.atomic             thrpt   10   246.460 ?   75.417  ops/us
> StableBenchmark.dcl                thrpt   10   243.481 ?   35.021  ops/us
> StableBenchmark.stable             thrpt   10  4977.693 ?  675.926  ops/us  <- Non-null
> StableBenchmark.stableHoldingList  thrpt   10  3614.460 ?  275.140  ops/us
> StableBenchmark.stableList         thrpt   10  3328.155 ?  898.202  ops/us
> StableBenchmark.stableListStored   thrpt   10  3842.174 ?  535.902  ops/us
> StableBenchmark.stableNull         thrpt   10  6217.737 ?  840.376  ops/us <- null
> StableBenchmark.supplier           thrpt   10  9369.934 ? 1449.182  ops/us
> 
> 
> Checking null first:
> 
> 
> Benchmark                           Mode  Cnt     Score      Error   Units
> StableBenchmark.atomic             thrpt   10   287.640 ?   17.858  ops/us
> StableBenchmark.dcl                thrpt   10   250.398 ?   20.874  ops/us
> StableBenchmark.stable             thrpt   10  3745.885 ? 1040.534  ops/us <- Non-null
> StableBenchmark.stableHoldingList  thrpt   10  2982.129 ?  503.492  ops/us
> StableBenchmark.stableList         thrpt   10  3125.045 ?  416.792  ops/us
> StableBenchmark.sta...

I think the result would be more convincing if the stable case is changed to `sum += (stable.orThrow() == null ? 0 : 1) + (stable2.orThrow() == null ? 0 : 1);` as adding by 1 might be somewhat better optimized by JIT.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18794#discussion_r1603148915

From pminborg at openjdk.org  Thu May 16 11:23:04 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 16 May 2024 11:23:04 GMT
Subject: RFR: 8331865: Consolidate size and alignment checks in LayoutPath
In-Reply-To: <CvKkdESp5-uHiuZtQvGortWnzOMV89pfjaCHNBIV4B4=.51ad0f01-2371-48af-b3c6-8a9b80518cdb@github.com>
References: <CvKkdESp5-uHiuZtQvGortWnzOMV89pfjaCHNBIV4B4=.51ad0f01-2371-48af-b3c6-8a9b80518cdb@github.com>
Message-ID: <YP62xs9MjNijSMC6gTf62GRswUyTAKNimgQGZ-PQnKY=.4edbc89a-1a01-4fdb-9880-096cab35af8a@github.com>

On Wed, 15 May 2024 15:43:45 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> When creating a nested memory access var handle, we ensure that the segment is accessed at the correct alignment for the root layout being accessed. But we do not ensure that the segment has at least the size of the accessed root layout. Example:
> 
> 
> MemoryLayout LAYOUT = sequenceLayout(2, structLayout(JAVA_INT.withName("x"), JAVA_INT.withName("y")));
> VarHandle X_HANDLE = LAYOUT.varHandle(PathElement.sequenceElement(), PathElement.groupElement("x"));
> 
> 
> If I have a memory segment whose size is 12, I can successfully call X_HANDLE on it with index 1, like so:
> 
> 
> MemorySegment segment = Arena.ofAuto().allocate(12);
> int x = (int)X_HANDLE.get(segment, 0, 1);
> 
> 
> This seems incorrect: after all, the provided segment doesn't have enough space to fit _two_ elements of the nested structs. 
> 
> This PR adds checks to detect this kind of scenario earlier, thus improving usability. To achieve this we could, in principle, just tweak `LayoutPath::checkEnclosingLayout` and add the required size check.
> 
> But doing so will add yet another redundant check on top of the other already added by [pull/19124](https://git.openjdk.org/jdk/pull/19124). Instead, this PR rethinks how memory segment var handles are created, in order to eliminate redundant checks.
> 
> The main observation is that size and alignment checks depend on an _enclosing_ layout. This layout *might* be the very same value layout being accessed (this is the case when e.g. using `JAVA_INT.varHandle()`). But, in the general case, the accessed value layout and the enclosing layout might differ (e.g. think about accessing a struct field).
> 
> Furthermore, the enclosing layout check depends on the _base_ offset at which the segment is accessed, _prior_ to any index computation that occurs if the accessed layout path has any open elements. It is important to notice that this base offset is only available when looking at the var handle that is returned to the user. For instance, an indexed var handle with coordinates:
> 
> 
> (MemorySegment, long /* base */, long /* index 1 */, long /* index 2 */, long /* index 3 */)
> 
> 
> Is obtained through adaptation, by taking a more basic var handle of the form:
> 
> 
> (MemorySegment, long /* offset */)
> 
> 
> And then injecting the result of the index multiplication into `offset`. As such, we can't add an enclosing layout check inside the var handle returned by `VarHandles::memorySegmentViewHandle`, as doing so will end up seeing the *wrong* offset (e.g. an offset in which the index part has already been mixed in)...

Do we have any performance tests available to see if there are any potential impacts?

src/java.base/share/classes/java/lang/invoke/VarHandleSegmentViewBase.java line 48:

> 46:     final long alignmentMask;
> 47: 
> 48:     VarHandleSegmentViewBase(VarForm form, boolean be, long alignmentMask, boolean exact) {

Nit: Copyright year. This also applies to some other files in this PR.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19251#issuecomment-2114955648
PR Review Comment: https://git.openjdk.org/jdk/pull/19251#discussion_r1603156019

From jpai at openjdk.org  Thu May 16 11:24:10 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 16 May 2024 11:24:10 GMT
Subject: RFR: 8331671: Implement JEP 472: Prepare to Restrict the Use of
 JNI [v6]
In-Reply-To: <SsNupEwmUHHR0JoGU-Tj_QF50Qv4qEyCXZeYLCX0Vkk=.fcb54e9d-4635-4e37-a13e-87d787e676c0@github.com>
References: <CZGbki5iFdCGPPagE-ya-_L8Nkgf7OunywApOsxC548=.2cee82fa-a5d2-4165-b012-30982a85030a@github.com>
 <SsNupEwmUHHR0JoGU-Tj_QF50Qv4qEyCXZeYLCX0Vkk=.fcb54e9d-4635-4e37-a13e-87d787e676c0@github.com>
Message-ID: <RUCP0y-ucqEWVGtNsxZ_c5l2t0sddT8sl247K_JYUls=.35b6b052-336b-462e-a19f-84150c738763@github.com>

On Wed, 15 May 2024 16:08:17 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This PR implements [JEP 472](https://openjdk.org/jeps/472), by restricting the use of JNI in the following ways:
>> 
>> * `System::load` and `System::loadLibrary` are now restricted methods
>> * `Runtime::load` and `Runtime::loadLibrary` are now restricted methods
>> * binding a JNI `native` method declaration to a native implementation is now considered a restricted operation
>> 
>> This PR slightly changes the way in which the JDK deals with restricted methods, even for FFM API calls. In Java 22, the single `--enable-native-access` was used both to specify a set of modules for which native access should be allowed *and* to specify whether illegal native access (that is, native access occurring from a module not specified by `--enable-native-access`) should be treated as an error or a warning. More specifically, an error is only issued if the `--enable-native-access flag` is used at least once.
>> 
>> Here, a new flag is introduced, namely `illegal-native-access=allow/warn/deny`, which is used to specify what should happen when access to a restricted method and/or functionality is found outside the set of modules specified with `--enable-native-access`. The default policy is `warn`, but users can select `allow` to suppress the warnings, or `deny` to cause `IllegalCallerException` to be thrown. This aligns the treatment of restricted methods with other mechanisms, such as `--illegal-access` and the more recent `--sun-misc-unsafe-memory-access`.
>> 
>> Some changes were required in the package-info javadoc for `java.lang.foreign`, to reflect the changes in the command line flags described above.
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address review comment

src/java.base/share/classes/sun/launcher/resources/launcher.properties line 72:

> 70: \                  by code in modules for which native access is not explicitly enabled.\n\
> 71: \                  <value> is one of "deny", "warn" or "allow".\n\
> 72: \                  This option will be removed in a future release.\n\

Should this specify the current default value for this option if it isn't set?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19213#discussion_r1603157916

From jpai at openjdk.org  Thu May 16 11:45:06 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 16 May 2024 11:45:06 GMT
Subject: RFR: 8331671: Implement JEP 472: Prepare to Restrict the Use of
 JNI [v6]
In-Reply-To: <SsNupEwmUHHR0JoGU-Tj_QF50Qv4qEyCXZeYLCX0Vkk=.fcb54e9d-4635-4e37-a13e-87d787e676c0@github.com>
References: <CZGbki5iFdCGPPagE-ya-_L8Nkgf7OunywApOsxC548=.2cee82fa-a5d2-4165-b012-30982a85030a@github.com>
 <SsNupEwmUHHR0JoGU-Tj_QF50Qv4qEyCXZeYLCX0Vkk=.fcb54e9d-4635-4e37-a13e-87d787e676c0@github.com>
Message-ID: <lbFOJOVUhVcVD8Z2XyvYm98g2kD8qvSbF0UH-GMxXfM=.f2ae908c-e3a5-4bc0-857d-726bde525cde@github.com>

On Wed, 15 May 2024 16:08:17 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This PR implements [JEP 472](https://openjdk.org/jeps/472), by restricting the use of JNI in the following ways:
>> 
>> * `System::load` and `System::loadLibrary` are now restricted methods
>> * `Runtime::load` and `Runtime::loadLibrary` are now restricted methods
>> * binding a JNI `native` method declaration to a native implementation is now considered a restricted operation
>> 
>> This PR slightly changes the way in which the JDK deals with restricted methods, even for FFM API calls. In Java 22, the single `--enable-native-access` was used both to specify a set of modules for which native access should be allowed *and* to specify whether illegal native access (that is, native access occurring from a module not specified by `--enable-native-access`) should be treated as an error or a warning. More specifically, an error is only issued if the `--enable-native-access flag` is used at least once.
>> 
>> Here, a new flag is introduced, namely `illegal-native-access=allow/warn/deny`, which is used to specify what should happen when access to a restricted method and/or functionality is found outside the set of modules specified with `--enable-native-access`. The default policy is `warn`, but users can select `allow` to suppress the warnings, or `deny` to cause `IllegalCallerException` to be thrown. This aligns the treatment of restricted methods with other mechanisms, such as `--illegal-access` and the more recent `--sun-misc-unsafe-memory-access`.
>> 
>> Some changes were required in the package-info javadoc for `java.lang.foreign`, to reflect the changes in the command line flags described above.
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address review comment

Hello Maurizio, in the current mainline, we have code in `LauncherHelper` https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/sun/launcher/LauncherHelper.java#L636 where we enable native access to all unnamed modules if an executable jar with `Enable-Native-Access: ALL-UNNAMED` manifest is being launched. For such executable jars, what is the expected semantics when the launch also explicitly has a `--enable-native-access=M1,M2` option. Something like:


java --enable-native-access=M1,M2 -jar foo.jar

where `foo.jar` has `Enable-Native-Access: ALL-UNNAMED` in its manifest.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19213#issuecomment-2115005638

From pminborg at openjdk.org  Thu May 16 11:49:38 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 16 May 2024 11:49:38 GMT
Subject: RFR: 8330465: Stable Values and Collections (Internal) [v12]
In-Reply-To: <-KSimQo5kkmCzzMShqGe5QZ9yCSzpWL98gN13v4wP0k=.11dd8d06-18a6-4577-8342-66632cea0b6e@github.com>
References: <-KSimQo5kkmCzzMShqGe5QZ9yCSzpWL98gN13v4wP0k=.11dd8d06-18a6-4577-8342-66632cea0b6e@github.com>
Message-ID: <8fJZzyeDlqp-WbZbpBmY40bCGbDj5j31IXaeHgK4FHA=.f648fde3-2819-4cc4-9e11-cbf02520d100@github.com>

> # Stable Values & Collections (Internal)
> 
> ## Summary
> This PR proposes to introduce an internal _Stable Values & Collections_ API, which provides immutable value holders where elements are initialized _at most once_. Stable Values & Collections offer the performance and safety benefits of final fields while offering greater flexibility as to the timing of initialization.
> 
> ## Goals
>  * Provide an easy and intuitive API to describe value holders that can change at most once.
>  * Decouple declaration from initialization without significant footprint or performance penalties.
>  * Reduce the amount of static initializer and/or field initialization code.
>  * Uphold integrity and consistency, even in a multi-threaded environment.
>  
> For more details, see the draft JEP: https://openjdk.org/jeps/8312611
> 
> ## Performance 
> Performance compared to instance variables using two `AtomicReference` and two protected by double-checked locking under concurrent access by all threads:
> 
> 
> Benchmark                                      Mode  Cnt      Score      Error   Units
> StableBenchmark.atomic                        thrpt   10    259.478 ?   36.809  ops/us
> StableBenchmark.dcl                           thrpt   10    225.710 ?   26.638  ops/us
> StableBenchmark.stable                        thrpt   10   4382.478 ? 1151.472  ops/us <- StableValue significantly faster
> 
> 
> Performance compared to static variables protected by `AtomicReference`, class-holder idiom holder, and double-checked locking (all threads):
> 
> 
> Benchmark                                      Mode  Cnt      Score      Error   Units
> StableStaticBenchmark.atomic                  thrpt   10   6487.835 ?  385.639  ops/us
> StableStaticBenchmark.dcl                     thrpt   10   6605.239 ?  210.610  ops/us
> StableStaticBenchmark.stable                  thrpt   10  14338.239 ? 1426.874  ops/us
> StableStaticBenchmark.staticCHI               thrpt   10  13780.341 ? 1839.651  ops/us
> 
> 
> Performance for stable lists (thread safe) in both instance and static contexts whereby we access a single value compared to `ArrayList` instances (which are not thread-safe) (all threads):
> 
> 
> Benchmark                                      Mode  Cnt      Score      Error   Units
> StableListElementBenchmark.instanceArrayList  thrpt   10   5812.992 ? 1169.730  ops/us
> StableListElementBenchmark.instanceList       thrpt   10   4818.643 ?  704.893  ops/us
> StableListElementBenchmark.staticArrayList    thrpt   10   7614.741 ?  564.777  ops/us
> StableListElementBe...

Per Minborg has updated the pull request incrementally with one additional commit since the last revision:

  Clean up

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/18794/files
  - new: https://git.openjdk.org/jdk/pull/18794/files/923e1877..b40ebfad

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18794&range=11
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18794&range=10-11

  Stats: 64 lines in 3 files changed: 14 ins; 21 del; 29 mod
  Patch: https://git.openjdk.org/jdk/pull/18794.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18794/head:pull/18794

PR: https://git.openjdk.org/jdk/pull/18794

From mcimadamore at openjdk.org  Thu May 16 11:50:05 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 16 May 2024 11:50:05 GMT
Subject: RFR: 8331671: Implement JEP 472: Prepare to Restrict the Use of
 JNI [v6]
In-Reply-To: <lbFOJOVUhVcVD8Z2XyvYm98g2kD8qvSbF0UH-GMxXfM=.f2ae908c-e3a5-4bc0-857d-726bde525cde@github.com>
References: <CZGbki5iFdCGPPagE-ya-_L8Nkgf7OunywApOsxC548=.2cee82fa-a5d2-4165-b012-30982a85030a@github.com>
 <SsNupEwmUHHR0JoGU-Tj_QF50Qv4qEyCXZeYLCX0Vkk=.fcb54e9d-4635-4e37-a13e-87d787e676c0@github.com>
 <lbFOJOVUhVcVD8Z2XyvYm98g2kD8qvSbF0UH-GMxXfM=.f2ae908c-e3a5-4bc0-857d-726bde525cde@github.com>
Message-ID: <LfHuMr3CMHlhVgifRYD8sUF4OrIsBzlSFRcoUkR9RT4=.66c0186b-244d-4043-a85d-dd6e3e184ae3@github.com>

On Thu, 16 May 2024 11:42:48 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Hello Maurizio, in the current mainline, we have code in `LauncherHelper` https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/sun/launcher/LauncherHelper.java#L636 where we enable native access to all unnamed modules if an executable jar with `Enable-Native-Access: ALL-UNNAMED` manifest is being launched. For such executable jars, what is the expected semantics when the launch also explicitly has a `--enable-native-access=M1,M2` option. Something like:
> 
> ```
> java --enable-native-access=M1,M2 -jar foo.jar
> ```
> 
> where `foo.jar` has `Enable-Native-Access: ALL-UNNAMED` in its manifest.

The options are additive - e.g. the enable-native-access in the manifest will add up to the enable-native-access in the command line, so effectively it will be as if you were running with --enable-native-access=M1,M2,ALL-UNNAMED

> src/java.base/share/classes/sun/launcher/resources/launcher.properties line 72:
> 
>> 70: \                  by code in modules for which native access is not explicitly enabled.\n\
>> 71: \                  <value> is one of "deny", "warn" or "allow".\n\
>> 72: \                  This option will be removed in a future release.\n\
> 
> Should this specify the current default value for this option if it isn't set?

We already do, see
https://github.com/openjdk/jdk/pull/19213/files/1c45e5d56c429205ab8185481bc1044a86ab3bc6#diff-d05029afe6aed86f860a10901114402f1f6af4fe1e4b46d883141ab1d2a527b8R582

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19213#issuecomment-2115012361
PR Review Comment: https://git.openjdk.org/jdk/pull/19213#discussion_r1603195671

From liach at openjdk.org  Thu May 16 11:58:13 2024
From: liach at openjdk.org (Chen Liang)
Date: Thu, 16 May 2024 11:58:13 GMT
Subject: RFR: 8330465: Stable Values and Collections (Internal) [v6]
In-Reply-To: <53bNF9v46bu-RgX1vJOwtdFKIzP3vwieCOENWtg2ra8=.c3f4dca8-6b1f-4c35-8e2c-f142c05dfe9b@github.com>
References: <-KSimQo5kkmCzzMShqGe5QZ9yCSzpWL98gN13v4wP0k=.11dd8d06-18a6-4577-8342-66632cea0b6e@github.com>
 <53bNF9v46bu-RgX1vJOwtdFKIzP3vwieCOENWtg2ra8=.c3f4dca8-6b1f-4c35-8e2c-f142c05dfe9b@github.com>
Message-ID: <xOufuxR8ZXSE26oEQzodWM7n4VM8ycAbmQVbaYITeJw=.a1bc303a-bc5c-442d-927d-885330442948@github.com>

On Thu, 16 May 2024 07:29:21 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> # Stable Values & Collections (Internal)
>> 
>> ## Summary
>> This PR proposes to introduce an internal _Stable Values & Collections_ API, which provides immutable value holders where elements are initialized _at most once_. Stable Values & Collections offer the performance and safety benefits of final fields while offering greater flexibility as to the timing of initialization.
>> 
>> ## Goals
>>  * Provide an easy and intuitive API to describe value holders that can change at most once.
>>  * Decouple declaration from initialization without significant footprint or performance penalties.
>>  * Reduce the amount of static initializer and/or field initialization code.
>>  * Uphold integrity and consistency, even in a multi-threaded environment.
>>  
>> For more details, see the draft JEP: https://openjdk.org/jeps/8312611
>> 
>> ## Performance 
>> Performance compared to instance variables using two `AtomicReference` and two protected by double-checked locking under concurrent access by all threads:
>> 
>> 
>> Benchmark                                      Mode  Cnt      Score      Error   Units
>> StableBenchmark.atomic                        thrpt   10    259.478 ?   36.809  ops/us
>> StableBenchmark.dcl                           thrpt   10    225.710 ?   26.638  ops/us
>> StableBenchmark.stable                        thrpt   10   4382.478 ? 1151.472  ops/us <- StableValue significantly faster
>> 
>> 
>> Performance compared to static variables protected by `AtomicReference`, class-holder idiom holder, and double-checked locking (all threads):
>> 
>> 
>> Benchmark                                      Mode  Cnt      Score      Error   Units
>> StableStaticBenchmark.atomic                  thrpt   10   6487.835 ?  385.639  ops/us
>> StableStaticBenchmark.dcl                     thrpt   10   6605.239 ?  210.610  ops/us
>> StableStaticBenchmark.stable                  thrpt   10  14338.239 ? 1426.874  ops/us
>> StableStaticBenchmark.staticCHI               thrpt   10  13780.341 ? 1839.651  ops/us
>> 
>> 
>> Performance for stable lists (thread safe) in both instance and static contexts whereby we access a single value compared to `ArrayList` instances (which are not thread-safe) (all threads):
>> 
>> 
>> Benchmark                                      Mode  Cnt      Score      Error   Units
>> StableListElementBenchmark.instanceArrayList  thrpt   10   5812.992 ? 1169.730  ops/us
>> StableListElementBenchmark.instanceList       thrpt   10   4818.643 ?  704.893  ops/us
>> StableListElementBenchmark...
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Simplify exception handling and add benchmarks

src/java.base/share/classes/jdk/internal/lang/stable/StableValueImpl.java line 400:

> 398:             @Override
> 399:             public void run() {
> 400:                 stable.computeIfUnset(supplier);

We can just declare this runnable as a capturing lambda (or an anonymous class if you fear initialization issues) and leave this comment there. The thread field can be removed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18794#discussion_r1603177748

From jpai at openjdk.org  Thu May 16 11:58:06 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 16 May 2024 11:58:06 GMT
Subject: RFR: 8331671: Implement JEP 472: Prepare to Restrict the Use of
 JNI [v6]
In-Reply-To: <LfHuMr3CMHlhVgifRYD8sUF4OrIsBzlSFRcoUkR9RT4=.66c0186b-244d-4043-a85d-dd6e3e184ae3@github.com>
References: <CZGbki5iFdCGPPagE-ya-_L8Nkgf7OunywApOsxC548=.2cee82fa-a5d2-4165-b012-30982a85030a@github.com>
 <SsNupEwmUHHR0JoGU-Tj_QF50Qv4qEyCXZeYLCX0Vkk=.fcb54e9d-4635-4e37-a13e-87d787e676c0@github.com>
 <lbFOJOVUhVcVD8Z2XyvYm98g2kD8qvSbF0UH-GMxXfM=.f2ae908c-e3a5-4bc0-857d-726bde525cde@github.com>
 <LfHuMr3CMHlhVgifRYD8sUF4OrIsBzlSFRcoUkR9RT4=.66c0186b-244d-4043-a85d-dd6e3e184ae3@github.com>
Message-ID: <6OAF_6PrZCouzDuhvwc8J6TSIUmBEc4HEi9Z-155BJ8=.4968dd9f-3939-4a49-9f29-57a901a7d12a@github.com>

On Thu, 16 May 2024 11:47:13 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> src/java.base/share/classes/sun/launcher/resources/launcher.properties line 72:
>> 
>>> 70: \                  by code in modules for which native access is not explicitly enabled.\n\
>>> 71: \                  <value> is one of "deny", "warn" or "allow".\n\
>>> 72: \                  This option will be removed in a future release.\n\
>> 
>> Should this specify the current default value for this option if it isn't set?
>
> We already do, see
> https://github.com/openjdk/jdk/pull/19213/files/1c45e5d56c429205ab8185481bc1044a86ab3bc6#diff-d05029afe6aed86f860a10901114402f1f6af4fe1e4b46d883141ab1d2a527b8R582

This is slightly different from what we do in the other PR for unsafe memory access where we specify the default in the launcher's help text too https://github.com/openjdk/jdk/pull/19174/files#diff-799093930b698e97b23ead98c6496261af1e2e33ec7aa9261584870cbee8a5eaR219.

I don't have a strong opinion on this, I think either one is fine.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19213#discussion_r1603205279

From pminborg at openjdk.org  Thu May 16 11:58:11 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 16 May 2024 11:58:11 GMT
Subject: RFR: 8330465: Stable Values and Collections (Internal) [v5]
In-Reply-To: <_I8ZxFiUZ3bygkA-iDH29xEmkqoy0Dm-_g0iAVRkoro=.680467aa-a061-4f17-8fcd-a60a829afa59@github.com>
References: <-KSimQo5kkmCzzMShqGe5QZ9yCSzpWL98gN13v4wP0k=.11dd8d06-18a6-4577-8342-66632cea0b6e@github.com>
 <VGuyX6AyE1gAq2nsCLIyOxnHbYbAAW8YvKk8mAjKnos=.c5ea169b-dfba-4ac8-8e91-7d897708ea5d@github.com>
 <sWc2qReuqEhBnu0fHIg75bC8WJkp56HSO9x807NgZoA=.2041706f-383d-44d0-93c6-2eda82329869@github.com>
 <hfCAtNQs4eEApF71b4FKsHWQwl20eYeURk_AljjT-q0=.6753684c-6275-4db5-99ca-b1190fbe5b95@github.com>
 <_G7nE_OAMl9WSkAz21UDYHAlCRVeHN2ZmM0FR7Bmxtw=.ea94e982-3e9a-4c0e-8523-11372474d497@github.com>
 <_I8ZxFiUZ3bygkA-iDH29xEmkqoy0Dm-_g0iAVRkoro=.680467aa-a061-4f17-8fcd-a60a829afa59@github.com>
Message-ID: <N_M549yqrR06wJjkDzHki1Yn_gumJ2QMsd5f6KpIvCI=.8a732d66-470c-42d9-94c5-b3af139b7123@github.com>

On Thu, 16 May 2024 11:13:24 GMT, Chen Liang <liach at openjdk.org> wrote:

>> It seems reasonable to assume `null` values are not constant-folded. For straight-out-of-the-box usage, there is no apparent significant difference as indicated by a new benchmark I just added:
>> 
>> 
>> Benchmark                                  Mode  Cnt      Score      Error   Units
>> StableStaticBenchmark.atomic              thrpt   10   5729.683 ?  502.023  ops/us
>> StableStaticBenchmark.dcl                 thrpt   10   6069.222 ?  951.784  ops/us
>> StableStaticBenchmark.dclHolder           thrpt   10   5502.102 ? 1630.627  ops/us
>> StableStaticBenchmark.stable              thrpt   10  12737.158 ? 1746.456  ops/us <- Non-null benchmark
>> StableStaticBenchmark.stableHolder        thrpt   10  12053.978 ? 1421.527  ops/us
>> StableStaticBenchmark.stableList          thrpt   10  12443.870 ? 2084.607  ops/us
>> StableStaticBenchmark.stableNull          thrpt   10  13164.232 ?  591.284  ops/us <- Added null benchmark
>> StableStaticBenchmark.stableRecordHolder  thrpt   10  13638.893 ? 1250.895  ops/us
>> StableStaticBenchmark.staticCHI           thrpt   10  13639.220 ? 1190.922  ops/us
>> 
>> 
>> If the `null` value participates in a much larger constant-folding tree, there might be a significant difference. I am afraid moving the order would have detrimental effects on instance performance:
>> 
>> Checking value first:
>> 
>> 
>> Benchmark                           Mode  Cnt     Score      Error   Units
>> StableBenchmark.atomic             thrpt   10   246.460 ?   75.417  ops/us
>> StableBenchmark.dcl                thrpt   10   243.481 ?   35.021  ops/us
>> StableBenchmark.stable             thrpt   10  4977.693 ?  675.926  ops/us  <- Non-null
>> StableBenchmark.stableHoldingList  thrpt   10  3614.460 ?  275.140  ops/us
>> StableBenchmark.stableList         thrpt   10  3328.155 ?  898.202  ops/us
>> StableBenchmark.stableListStored   thrpt   10  3842.174 ?  535.902  ops/us
>> StableBenchmark.stableNull         thrpt   10  6217.737 ?  840.376  ops/us <- null
>> StableBenchmark.supplier           thrpt   10  9369.934 ? 1449.182  ops/us
>> 
>> 
>> Checking null first:
>> 
>> 
>> Benchmark                           Mode  Cnt     Score      Error   Units
>> StableBenchmark.atomic             thrpt   10   287.640 ?   17.858  ops/us
>> StableBenchmark.dcl                thrpt   10   250.398 ?   20.874  ops/us
>> StableBenchmark.stable             thrpt   10  3745.885 ? 1040.534  ops/us <- Non-null
>> StableBenchmark.stableHoldingList  thrpt   10  2982.129 ?  503.492  ops/us
>> StableBenchmar...
>
> I think the result would be more convincing if the stable case is changed to `sum += (stable.orThrow() == null ? 0 : 1) + (stable2.orThrow() == null ? 0 : 1);` as adding by 1 might be somewhat better optimized by JIT.

I have instead changed parts of the `stableNull()` body to:


sum += (stableNull.orThrow() == null ? VALUE : VALUE2) + (stableNull2.orThrow() == null ? VALUE : VALUE2);

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18794#discussion_r1603205135

From pminborg at openjdk.org  Thu May 16 12:06:08 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 16 May 2024 12:06:08 GMT
Subject: RFR: 8330465: Stable Values and Collections (Internal) [v5]
In-Reply-To: <RfYvs1cjpROShsbMvXNsqqazCLawHMmgyGqDu0WWyG0=.93faddd9-a1a1-438e-b81d-dcdc87f491ed@github.com>
References: <-KSimQo5kkmCzzMShqGe5QZ9yCSzpWL98gN13v4wP0k=.11dd8d06-18a6-4577-8342-66632cea0b6e@github.com>
 <VGuyX6AyE1gAq2nsCLIyOxnHbYbAAW8YvKk8mAjKnos=.c5ea169b-dfba-4ac8-8e91-7d897708ea5d@github.com>
 <sWc2qReuqEhBnu0fHIg75bC8WJkp56HSO9x807NgZoA=.2041706f-383d-44d0-93c6-2eda82329869@github.com>
 <5zoKgO17_hUh9-UveP-yo82Sh2Jrk2Z_3K8rsarDk10=.03e40aaa-cac7-4ef6-b9ca-131fd338a0a8@github.com>
 <RfYvs1cjpROShsbMvXNsqqazCLawHMmgyGqDu0WWyG0=.93faddd9-a1a1-438e-b81d-dcdc87f491ed@github.com>
Message-ID: <ab1vNvxDiTVyjtvPZRGhW6rt_WC-hwDIAeyEDFfn73I=.7ff76541-1804-4f46-afbb-8932da074624@github.com>

On Thu, 16 May 2024 11:14:16 GMT, Chen Liang <liach at openjdk.org> wrote:

>> The idea here is to have the most likely value in the middle... Not sure if that motivates the added complexity though.
>
> Is there any refernce on how/why the middle entry in a tableswitch instruction is the fastest?

It is only in a _lookupswitch_ that this becomes relevant. The above code will generate a *tableswitch* so I think it is safe to simplify the code and remove the DUMMY.


  private V orThrowVolatile();
    descriptor: ()Ljava/lang/Object;
    flags: (0x0002) ACC_PRIVATE
    Code:
      stack=1, locals=1, args_size=1
         0: aload_0
         1: invokevirtual #15                 // Method stateVolatile:()I
         4: tableswitch   { // 0 to 4
                       0: 40
                       1: 44
                       2: 46
                       3: 51
                       4: 56
                 default: 60
            }
            ...

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18794#discussion_r1603214742

From egahlin at openjdk.org  Thu May 16 12:10:46 2024
From: egahlin at openjdk.org (Erik Gahlin)
Date: Thu, 16 May 2024 12:10:46 GMT
Subject: RFR: 8331876: JFR: Move file read and write events to java.base
 [v5]
In-Reply-To: <DDe0bKCC86AawVl7RylZ74uvvLBr2Zljpkcmxx1_WEU=.61cc10c6-b635-42dd-a850-b32ae1d68585@github.com>
References: <DDe0bKCC86AawVl7RylZ74uvvLBr2Zljpkcmxx1_WEU=.61cc10c6-b635-42dd-a850-b32ae1d68585@github.com>
Message-ID: <0665H6piGNaGJNd0t8bhhQGgrunmvhe3vjfpZ7Bc6gw=.d2ba3ac1-c458-43b5-93f8-6e2df16afd68@github.com>

> Hi,
> 
> Could I have a review of a change that moves the jdk.FileRead and jdk.FileWrite events to java.base to remove the use of the ASM instrumentation.
> 
> Testing: jdk/jdk/jfr
> 
> Thanks
> Erik

Erik Gahlin has updated the pull request incrementally with one additional commit since the last revision:

  Remove dependency on JFR for retransformation

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19129/files
  - new: https://git.openjdk.org/jdk/pull/19129/files/f2439ac3..c4c64774

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19129&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19129&range=03-04

  Stats: 233 lines in 2 files changed: 122 ins; 111 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/19129.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19129/head:pull/19129

PR: https://git.openjdk.org/jdk/pull/19129

From pminborg at openjdk.org  Thu May 16 12:11:50 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 16 May 2024 12:11:50 GMT
Subject: RFR: 8330465: Stable Values and Collections (Internal) [v13]
In-Reply-To: <-KSimQo5kkmCzzMShqGe5QZ9yCSzpWL98gN13v4wP0k=.11dd8d06-18a6-4577-8342-66632cea0b6e@github.com>
References: <-KSimQo5kkmCzzMShqGe5QZ9yCSzpWL98gN13v4wP0k=.11dd8d06-18a6-4577-8342-66632cea0b6e@github.com>
Message-ID: <lamJ4gPkdT6TYiiD1kt3xDY0yU-tKZ_GdTFVFmaWoZA=.abb6c2fd-c1e1-4c19-bb91-cd5e399ec665@github.com>

> # Stable Values & Collections (Internal)
> 
> ## Summary
> This PR proposes to introduce an internal _Stable Values & Collections_ API, which provides immutable value holders where elements are initialized _at most once_. Stable Values & Collections offer the performance and safety benefits of final fields while offering greater flexibility as to the timing of initialization.
> 
> ## Goals
>  * Provide an easy and intuitive API to describe value holders that can change at most once.
>  * Decouple declaration from initialization without significant footprint or performance penalties.
>  * Reduce the amount of static initializer and/or field initialization code.
>  * Uphold integrity and consistency, even in a multi-threaded environment.
>  
> For more details, see the draft JEP: https://openjdk.org/jeps/8312611
> 
> ## Performance 
> Performance compared to instance variables using two `AtomicReference` and two protected by double-checked locking under concurrent access by all threads:
> 
> 
> Benchmark                                      Mode  Cnt      Score      Error   Units
> StableBenchmark.atomic                        thrpt   10    259.478 ?   36.809  ops/us
> StableBenchmark.dcl                           thrpt   10    225.710 ?   26.638  ops/us
> StableBenchmark.stable                        thrpt   10   4382.478 ? 1151.472  ops/us <- StableValue significantly faster
> 
> 
> Performance compared to static variables protected by `AtomicReference`, class-holder idiom holder, and double-checked locking (all threads):
> 
> 
> Benchmark                                      Mode  Cnt      Score      Error   Units
> StableStaticBenchmark.atomic                  thrpt   10   6487.835 ?  385.639  ops/us
> StableStaticBenchmark.dcl                     thrpt   10   6605.239 ?  210.610  ops/us
> StableStaticBenchmark.stable                  thrpt   10  14338.239 ? 1426.874  ops/us
> StableStaticBenchmark.staticCHI               thrpt   10  13780.341 ? 1839.651  ops/us
> 
> 
> Performance for stable lists (thread safe) in both instance and static contexts whereby we access a single value compared to `ArrayList` instances (which are not thread-safe) (all threads):
> 
> 
> Benchmark                                      Mode  Cnt      Score      Error   Units
> StableListElementBenchmark.instanceArrayList  thrpt   10   5812.992 ? 1169.730  ops/us
> StableListElementBenchmark.instanceList       thrpt   10   4818.643 ?  704.893  ops/us
> StableListElementBenchmark.staticArrayList    thrpt   10   7614.741 ?  564.777  ops/us
> StableListElementBe...

Per Minborg has updated the pull request incrementally with two additional commits since the last revision:

 - Cleanup switch rakes
 - Update null benchmarks

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/18794/files
  - new: https://git.openjdk.org/jdk/pull/18794/files/b40ebfad..dbbefea5

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18794&range=12
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18794&range=11-12

  Stats: 19 lines in 4 files changed: 3 ins; 6 del; 10 mod
  Patch: https://git.openjdk.org/jdk/pull/18794.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18794/head:pull/18794

PR: https://git.openjdk.org/jdk/pull/18794

From amansha at kth.se  Thu May 16 12:11:59 2024
From: amansha at kth.se (Aman Sharma)
Date: Thu, 16 May 2024 12:11:59 +0000
Subject: Deterministic naming of subclasses of
 `java/lang/reflect/Proxy`
In-Reply-To: <CABe8uE0fk71Xy_PYHikSw9OtXE_i+M9zMbayPEXuTxLWLoy2ag@mail.gmail.com>
References: <bf26eb2f74874e02876b3868311922a9@kth.se>,
 <CABe8uE0fk71Xy_PYHikSw9OtXE_i+M9zMbayPEXuTxLWLoy2ag@mail.gmail.com>
Message-ID: <50405ca9c0a64372bace175b932f9ef7@kth.se>

Hi,


Thanks for your response, Liang!


> I think you meant CVE-2021-42392 instead of 2022.


Sorry of the error. I indeed meant CVE-2021-42392<https://nvd.nist.gov/vuln/detail/cve-2021-42392>.


> Leyden mainly avoids this unstable generation by performing a training run to collect classes loaded


Would love to know the details of Project Leyden and how they worked so far to focus on this goal. In our case, the training run is the test suite.


> GeneratedConstructorAccessor is already retired by JEP 416 [2] in Java 18


I did see them not appearing in my allowlist when I ran my study subject (Apache PDFBox) with Java 21. Thanks for letting me know about this JEP. I see they are re-implemented with method handles.


> How are you checking the classes?


To detect runtime generated code, we have javaagent that is hooked statically to the test suite execution. It gives us all classes that that is loaded post the JVM and the javaagent are loaded. So we only check the classes loaded for the purpose of running the application. This is also why we did not choose -agentlib as it would give classes for the setting up JVM and javaagent and we the user of our tool must the classes they load.


Next, we have a `ClassFileTransformer` hook in the agent where we produce the checksum using the bytecode. And we compare the checksum with the one existing in the allowlist. The checksum computation algorithm is same for both steps. Let me describe how I compute the checksum.


  1.  I get the CONSTANT_Class_info<https://docs.oracle.com/javase/specs/jvms/se11/html/jvms-4.html#jvms-4.4.1> entry corresponding to `this_class` and rewrite the CONSTANT_Utf8_info<https://docs.oracle.com/javase/specs/jvms/se11/html/jvms-4.html#jvms-4.4.7> corresponding to a fix String constant, say "foo".
  2.  Since, the name of the class is used to refer to its types members (fields/method), I get all CONSTANT_Fieldref_info<https://docs.oracle.com/javase/specs/jvms/se11/html/jvms-4.html#jvms-4.4.2> and if its `class_index` corresponds to the old `this_class`, we rewrite the UTF8 value of class_index to the same constant "foo".
  3.  Next, since the naming of the fields, in Proxy classes, are also suffixed by numbers, for example, `private static Method m4`, we rewrite the UTF8 value of name in the CONSTANT_NameAndType_info<https://docs.oracle.com/javase/specs/jvms/se11/html/jvms-4.html#jvms-4.4.6>.
  4.  These fields can also have a random order so we simply sort the entire byte code using `Arrays.sort(byte[])` to eliminate any differences due to ordering of fields/methods.
  5.  Simply sorting the byte array still had minute differences. I could not understand why they existed even though values in constant pool of the bytecode in allowlist and at runtime were exactly the same after rewriting. The differences existed in the bytes of the Code attribute of methods. I concluded that the bytes stored some position information. To avoid this, I created a subarray where I considered the bytes corresponding to `CONSTANT_Utf8_info.bytes` only. Computing a checksum for it resulted in the same checksums for both classfiles.

Let's understand the whole approach with an example of Proxy class.

`

public final class $Proxy42 extends Proxy implements org.apache.logging.log4j.core.config.plugins.Plugin {

`

The will go in the allowlist as "Proxy_Plugin: <SHA256 checksum>".

When the same class is intercepted at runtime, say "$Proxy10", we look for "Proxy_Plugin" in the allowlist and since the checksum algorithm is same in both cases, we get a match and let the class load.

This approach has seemed to work well for Proxy classes, Generated Constructor Accessor (which is removed as you said). I also looked at the species generated by method handles. I did not notice any modification in them. Their name generation seemed okay to me. If some new Species are generated, it is of course detected since it is not in the allowlist.

I have not looked into LambdaMetafactory because I did not encounter it as a problem so far, but I am aware its name generation is also unstable. I have run my approach only a few projects only. And for hidden classes, I assume the the agent won't be able to intercept them so detecting them would be really hard.


Regards,
Aman Sharma

PhD Student
KTH Royal Institute of Technology
School of Electrical Engineering and Computer Science (EECS)
Department of Theoretical Computer Science (TCS)
<http://www.kth.se><https://www.kth.se/profile/amansha><https://www.kth.se/profile/amansha>
<https://www.kth.se/profile/amansha>https://algomaster99.github.io/
________________________________
From: liangchenblue at gmail.com <liangchenblue at gmail.com>
Sent: Thursday, May 16, 2024 5:52:03 AM
To: Aman Sharma; core-libs-dev
Cc: Martin Monperrus
Subject: Re: Deterministic naming of subclasses of `java/lang/reflect/Proxy`

Hi Aman,
I think you meant CVE-2021-42392 instead of 2022.

For your approach of an "allowlist" for Java runtime, project Leyden is looking to generate a static image [1], that
> At run time it cannot load classes from outside the image, nor can it create classes dynamically.
Leyden mainly avoids this unstable generation by performing a training run to collect classes loaded and even object graphs; I am not familiar with the details unfortunately.

Otherwise, the Proxy discussion belongs better to core-libs-dev, as java.lang.reflect.Proxy is part of Java's core libraries. I am replying this thread to core-libs-dev.

For your perceived problem that classes don't have unique names, your description sounds dubious: GeneratedConstructorAccessor is already retired by JEP 416 [2] in Java 18, and there are many other cases in which JDK generates classes without stable names, notoriously LambdaMetafactory (Gradle wished for cacheable Lambdas); the same applies for the generated classes for MethodHandle's LambdaForms (which carries implementation code for LambdaForm). How are you checking the classes? It seems you are not checking hidden classes. Proxy and Lambda classes are defined by the caller's class loader, while LambdaForms are under JDK's system class loader I think. We need to ensure you are correctly finding all unstable classes before we can proceed.

[1]: https://openjdk.org/projects/leyden/notes/01-beginnings
[2]: https://openjdk.org/jeps/416

On Wed, May 15, 2024 at 7:00?PM Aman Sharma <amansha at kth.se<mailto:amansha at kth.se>> wrote:

Hi,


My name is Aman and I am a PhD student at KTH Royal Institute of Technology, Stockholm, Sweden. I research as part of CHAINS<https://chains.proj.kth.se/> project to strengthen the software supply chain of multiple ecosystem. I particularly focus on runtime integrity in Java. In this email, I want to write about an issue I have discovered with dynamic generation of `java.lang.reflect.Proxy`classes. I will propose a solution and would love to hear the feedback from the community. Let me know if this is the correct mailing-list for such discussions. It seemed the most relevant from this list<https://mail.openjdk.org/mailman/listinfo>.


My research


Java has features to load class on the fly - it can either download or generate a class at runtime. These features are useful for inner workings of JDK. For example, implementing annotations, reflective access, etc. However, these features have also contributed to critical vulnerabilities in the past - CVE-2021-44228  (log4shell), CVE-2022-33980, CVE-2022-42392. All of these vulnerabilities have one thing in common - a class that was not known during build time was downloaded/generated at runtime and loaded into JVM.


To defend against such vulnerabilities, we propose a solution to allowlist classes for runtime. This allowlist will contain an exhaustive list of classes that can be loaded by the JVM and it will be enforced at runtime. We build this allowlist from three sources:

  1.  All classes of all modules provided by the Java Standard Library. We use ClassGraph<https://github.com/classgraph/classgraph> to scan the JDK.
  2.  We can take the source code and all dependencies of an application. We use a software bill of materials to get all the data.
  3.  Finally, we use run the test suite to include any runtime downloaded/generated classes.

Such a list is able to prevent the above 3 CVEs because it does not let the "unknown" bytecode to be loaded.

Problem with generating such an allowlist

The first two parts of the allowlist are easy to get. The problem is with the third step where we want to allowlist all the classes that could be downloaded or generated. Upon running the test suite and hooking to the classes it loads, we observer that the list consists of classes that are called "com/sun/proxy/$Proxy2", "jdk/internal/reflect/GeneratedConstructorAccessor3" among many more. The purpose of these classes can be identifed. The proxy class is created for to implement an annotation. The accessor gives access to constructor of a class to the JVM.

When enforcing this allowlist at runtime, we see that the bytecode content for "com/sun/proxy/$Proxy2" differs in the allowlist and at runtime. In our case, we we are experimenting with pdfbox<https://github.com/apache/pdfbox> so we created the allowlist using its test suite. Then we enforced this allowlist while running some of its subcommands. However, there was some other proxy class say "com/sun/proxy/$Proxy5" at runtime that implemented the same interfaces and had the same methods as "com/sun/proxy/$Proxy2" in the allowlist. They only differed in the name of the class, order of fields, and types for fields references. This could happen because the order of the loading of class is workload dependent, but it causes problem to generate such an allowlist.

Solution

We propose that naming of subclasses of "java/lang/reflect/Proxy" should not be dependent upon the order of loading. In order to do so, two issues can be fixed:

  1.  The naming of the class should not be based on AtomicLong<https://github.com/openjdk/jdk/blob/b687aa550837830b38f0f0faa69c353b1e85219c/src/java.base/share/classes/java/lang/reflect/Proxy.java#L531><https://github.com/openjdk/jdk/blob/4083255440cfbf39b9683ea88a433d71ec6111e7/src/java.base/share/classes/java/lang/reflect/Proxy.java#L531>. Rather it could be named based on the interfaces it implements. I also wonder why AtomicLong is chosen in the first place.
  2.  Methods of the interfaces must be in a particular order. Right now, they are not sorted in any particular order<https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/lang/Class.java#L2178>.


These fixes will make proxy class generation deterministic with respect to order of loading and won't be flagged at runtime since the test suite would already detect them.

I would love to hear from the community about these ideas. If in agreement, I would be happy to produce a patch. I have discovered this issue with subclasses of GeneratedConstructorAccessor<https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/jdk/internal/reflect/ConstructorAccessor.java> as well and I imagine it will also apply to some other runtime generated classes. If you disagree, please let me know also. It helps with my research.

I also have PoCs for the above CVEs<https://github.com/chains-project/exploits-for-sbom.exe> and a proof concept tool is being developed under the name sbom.exe<https://github.com/chains-project/sbom.exe> in case any one wonders about the implementation. I would also be happy to explain more.

Regards,
Aman Sharma

PhD Student
KTH Royal Institute of Technology
School of Electrical Engineering and Computer Science (EECS)
Department of Theoretical Computer Science (TCS)
<http://www.kth.se><https://www.kth.se/profile/amansha><https://www.kth.se/profile/amansha>
<https://www.kth.se/profile/amansha>https://algomaster99.github.io/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240516/dbe36780/attachment-0001.htm>

From mcimadamore at openjdk.org  Thu May 16 12:20:05 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 16 May 2024 12:20:05 GMT
Subject: RFR: 8331671: Implement JEP 472: Prepare to Restrict the Use of
 JNI [v6]
In-Reply-To: <6OAF_6PrZCouzDuhvwc8J6TSIUmBEc4HEi9Z-155BJ8=.4968dd9f-3939-4a49-9f29-57a901a7d12a@github.com>
References: <CZGbki5iFdCGPPagE-ya-_L8Nkgf7OunywApOsxC548=.2cee82fa-a5d2-4165-b012-30982a85030a@github.com>
 <SsNupEwmUHHR0JoGU-Tj_QF50Qv4qEyCXZeYLCX0Vkk=.fcb54e9d-4635-4e37-a13e-87d787e676c0@github.com>
 <lbFOJOVUhVcVD8Z2XyvYm98g2kD8qvSbF0UH-GMxXfM=.f2ae908c-e3a5-4bc0-857d-726bde525cde@github.com>
 <LfHuMr3CMHlhVgifRYD8sUF4OrIsBzlSFRcoUkR9RT4=.66c0186b-244d-4043-a85d-dd6e3e184ae3@github.com>
 <6OAF_6PrZCouzDuhvwc8J6TSIUmBEc4HEi9Z-155BJ8=.4968dd9f-3939-4a49-9f29-57a901a7d12a@github.com>
Message-ID: <qpY76_mtbXFOYTvN5L7CXAZ7ZrsaLRFCjhoRB9WzzEk=.f53b98b1-6ad5-4499-98a0-aa8080b49cf0@github.com>

On Thu, 16 May 2024 11:55:35 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> We already do, see
>> https://github.com/openjdk/jdk/pull/19213/files/1c45e5d56c429205ab8185481bc1044a86ab3bc6#diff-d05029afe6aed86f860a10901114402f1f6af4fe1e4b46d883141ab1d2a527b8R582
>
> This is slightly different from what we do in the other PR for unsafe memory access where we specify the default in the launcher's help text too https://github.com/openjdk/jdk/pull/19174/files#diff-799093930b698e97b23ead98c6496261af1e2e33ec7aa9261584870cbee8a5eaR219.
> 
> I don't have a strong opinion on this, I think either one is fine.

Ah, apologies, I was looking in the wrong place. I agree that we should specify default in the launcher, as well as in the man pages.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19213#discussion_r1603233038

From mcimadamore at openjdk.org  Thu May 16 12:23:44 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 16 May 2024 12:23:44 GMT
Subject: RFR: 8331671: Implement JEP 472: Prepare to Restrict the Use of
 JNI [v7]
In-Reply-To: <CZGbki5iFdCGPPagE-ya-_L8Nkgf7OunywApOsxC548=.2cee82fa-a5d2-4165-b012-30982a85030a@github.com>
References: <CZGbki5iFdCGPPagE-ya-_L8Nkgf7OunywApOsxC548=.2cee82fa-a5d2-4165-b012-30982a85030a@github.com>
Message-ID: <kAq153qNH4hG6IDWoTMrBv9pCPMEZl1pI7-wJQgsI7A=.6588b41b-eb33-49a6-a49d-cca79aaaf180@github.com>

> This PR implements [JEP 472](https://openjdk.org/jeps/472), by restricting the use of JNI in the following ways:
> 
> * `System::load` and `System::loadLibrary` are now restricted methods
> * `Runtime::load` and `Runtime::loadLibrary` are now restricted methods
> * binding a JNI `native` method declaration to a native implementation is now considered a restricted operation
> 
> This PR slightly changes the way in which the JDK deals with restricted methods, even for FFM API calls. In Java 22, the single `--enable-native-access` was used both to specify a set of modules for which native access should be allowed *and* to specify whether illegal native access (that is, native access occurring from a module not specified by `--enable-native-access`) should be treated as an error or a warning. More specifically, an error is only issued if the `--enable-native-access flag` is used at least once.
> 
> Here, a new flag is introduced, namely `illegal-native-access=allow/warn/deny`, which is used to specify what should happen when access to a restricted method and/or functionality is found outside the set of modules specified with `--enable-native-access`. The default policy is `warn`, but users can select `allow` to suppress the warnings, or `deny` to cause `IllegalCallerException` to be thrown. This aligns the treatment of restricted methods with other mechanisms, such as `--illegal-access` and the more recent `--sun-misc-unsafe-memory-access`.
> 
> Some changes were required in the package-info javadoc for `java.lang.foreign`, to reflect the changes in the command line flags described above.

Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:

  Add note on --illegal-native-access default value in the launcher help

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19213/files
  - new: https://git.openjdk.org/jdk/pull/19213/files/1c45e5d5..3a0db276

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19213&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19213&range=05-06

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/19213.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19213/head:pull/19213

PR: https://git.openjdk.org/jdk/pull/19213

From pminborg at openjdk.org  Thu May 16 12:28:44 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 16 May 2024 12:28:44 GMT
Subject: RFR: 8330465: Stable Values and Collections (Internal) [v14]
In-Reply-To: <-KSimQo5kkmCzzMShqGe5QZ9yCSzpWL98gN13v4wP0k=.11dd8d06-18a6-4577-8342-66632cea0b6e@github.com>
References: <-KSimQo5kkmCzzMShqGe5QZ9yCSzpWL98gN13v4wP0k=.11dd8d06-18a6-4577-8342-66632cea0b6e@github.com>
Message-ID: <Ktnzo3qtH3HgngOBnf2EPM8ZWmQGXhdAL1eGXwsC5hc=.88bdb383-fa51-41d8-b1f6-5ac7a62212f9@github.com>

> # Stable Values & Collections (Internal)
> 
> ## Summary
> This PR proposes to introduce an internal _Stable Values & Collections_ API, which provides immutable value holders where elements are initialized _at most once_. Stable Values & Collections offer the performance and safety benefits of final fields while offering greater flexibility as to the timing of initialization.
> 
> ## Goals
>  * Provide an easy and intuitive API to describe value holders that can change at most once.
>  * Decouple declaration from initialization without significant footprint or performance penalties.
>  * Reduce the amount of static initializer and/or field initialization code.
>  * Uphold integrity and consistency, even in a multi-threaded environment.
>  
> For more details, see the draft JEP: https://openjdk.org/jeps/8312611
> 
> ## Performance 
> Performance compared to instance variables using two `AtomicReference` and two protected by double-checked locking under concurrent access by all threads:
> 
> 
> Benchmark                                      Mode  Cnt      Score      Error   Units
> StableBenchmark.atomic                        thrpt   10    259.478 ?   36.809  ops/us
> StableBenchmark.dcl                           thrpt   10    225.710 ?   26.638  ops/us
> StableBenchmark.stable                        thrpt   10   4382.478 ? 1151.472  ops/us <- StableValue significantly faster
> 
> 
> Performance compared to static variables protected by `AtomicReference`, class-holder idiom holder, and double-checked locking (all threads):
> 
> 
> Benchmark                                      Mode  Cnt      Score      Error   Units
> StableStaticBenchmark.atomic                  thrpt   10   6487.835 ?  385.639  ops/us
> StableStaticBenchmark.dcl                     thrpt   10   6605.239 ?  210.610  ops/us
> StableStaticBenchmark.stable                  thrpt   10  14338.239 ? 1426.874  ops/us
> StableStaticBenchmark.staticCHI               thrpt   10  13780.341 ? 1839.651  ops/us
> 
> 
> Performance for stable lists (thread safe) in both instance and static contexts whereby we access a single value compared to `ArrayList` instances (which are not thread-safe) (all threads):
> 
> 
> Benchmark                                      Mode  Cnt      Score      Error   Units
> StableListElementBenchmark.instanceArrayList  thrpt   10   5812.992 ? 1169.730  ops/us
> StableListElementBenchmark.instanceList       thrpt   10   4818.643 ?  704.893  ops/us
> StableListElementBenchmark.staticArrayList    thrpt   10   7614.741 ?  564.777  ops/us
> StableListElementBe...

Per Minborg has updated the pull request incrementally with one additional commit since the last revision:

  Improve toString and simplify offset calculations

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/18794/files
  - new: https://git.openjdk.org/jdk/pull/18794/files/dbbefea5..3e1ab5e9

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18794&range=13
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18794&range=12-13

  Stats: 51 lines in 2 files changed: 18 ins; 27 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/18794.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18794/head:pull/18794

PR: https://git.openjdk.org/jdk/pull/18794

From pminborg at openjdk.org  Thu May 16 12:34:46 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 16 May 2024 12:34:46 GMT
Subject: RFR: 8330465: Stable Values and Collections (Internal) [v15]
In-Reply-To: <-KSimQo5kkmCzzMShqGe5QZ9yCSzpWL98gN13v4wP0k=.11dd8d06-18a6-4577-8342-66632cea0b6e@github.com>
References: <-KSimQo5kkmCzzMShqGe5QZ9yCSzpWL98gN13v4wP0k=.11dd8d06-18a6-4577-8342-66632cea0b6e@github.com>
Message-ID: <SGrZWZjlMk6ODI5e9xRED_sRU-0921W2lHah47WBZbg=.de5fd46f-6db2-4d65-976e-41266a725fa4@github.com>

> # Stable Values & Collections (Internal)
> 
> ## Summary
> This PR proposes to introduce an internal _Stable Values & Collections_ API, which provides immutable value holders where elements are initialized _at most once_. Stable Values & Collections offer the performance and safety benefits of final fields while offering greater flexibility as to the timing of initialization.
> 
> ## Goals
>  * Provide an easy and intuitive API to describe value holders that can change at most once.
>  * Decouple declaration from initialization without significant footprint or performance penalties.
>  * Reduce the amount of static initializer and/or field initialization code.
>  * Uphold integrity and consistency, even in a multi-threaded environment.
>  
> For more details, see the draft JEP: https://openjdk.org/jeps/8312611
> 
> ## Performance 
> Performance compared to instance variables using two `AtomicReference` and two protected by double-checked locking under concurrent access by all threads:
> 
> 
> Benchmark                                      Mode  Cnt      Score      Error   Units
> StableBenchmark.atomic                        thrpt   10    259.478 ?   36.809  ops/us
> StableBenchmark.dcl                           thrpt   10    225.710 ?   26.638  ops/us
> StableBenchmark.stable                        thrpt   10   4382.478 ? 1151.472  ops/us <- StableValue significantly faster
> 
> 
> Performance compared to static variables protected by `AtomicReference`, class-holder idiom holder, and double-checked locking (all threads):
> 
> 
> Benchmark                                      Mode  Cnt      Score      Error   Units
> StableStaticBenchmark.atomic                  thrpt   10   6487.835 ?  385.639  ops/us
> StableStaticBenchmark.dcl                     thrpt   10   6605.239 ?  210.610  ops/us
> StableStaticBenchmark.stable                  thrpt   10  14338.239 ? 1426.874  ops/us
> StableStaticBenchmark.staticCHI               thrpt   10  13780.341 ? 1839.651  ops/us
> 
> 
> Performance for stable lists (thread safe) in both instance and static contexts whereby we access a single value compared to `ArrayList` instances (which are not thread-safe) (all threads):
> 
> 
> Benchmark                                      Mode  Cnt      Score      Error   Units
> StableListElementBenchmark.instanceArrayList  thrpt   10   5812.992 ? 1169.730  ops/us
> StableListElementBenchmark.instanceList       thrpt   10   4818.643 ?  704.893  ops/us
> StableListElementBenchmark.staticArrayList    thrpt   10   7614.741 ?  564.777  ops/us
> StableListElementBe...

Per Minborg has updated the pull request incrementally with one additional commit since the last revision:

  Simplify background thread handling

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/18794/files
  - new: https://git.openjdk.org/jdk/pull/18794/files/3e1ab5e9..2af0168e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18794&range=14
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18794&range=13-14

  Stats: 7 lines in 1 file changed: 0 ins; 4 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/18794.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18794/head:pull/18794

PR: https://git.openjdk.org/jdk/pull/18794

From rgiulietti at openjdk.org  Thu May 16 12:38:08 2024
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Thu, 16 May 2024 12:38:08 GMT
Subject: RFR: 8332086: Remove the usage of ServiceLoader in
 j.u.r.RandomGeneratorFactory [v5]
In-Reply-To: <2Tv7yoSkIoEuQX2GZuyBnAdGHSpTKCGXV0_K0_UPiks=.dff4cf04-3a5d-4afc-8057-9cebb9b61ddd@github.com>
References: <hfB86NksORc-aC6zVxHel_QQd_9aB629SfQjXvl6q5U=.e31daa4b-5cf6-4f3f-a757-79e818a18978@github.com>
 <ZasWP14ViFxaPqk_x3rmDgVFocTX9_aAP1W_kplDjbE=.b5fa3a6a-c303-4fe7-afbe-01700d4a7e85@github.com>
 <2Tv7yoSkIoEuQX2GZuyBnAdGHSpTKCGXV0_K0_UPiks=.dff4cf04-3a5d-4afc-8057-9cebb9b61ddd@github.com>
Message-ID: <8d6Um0qog6MPlI-wjflKoo2CKf_-uZP7N6pg63Iwl9U=.8e69aeb7-9672-4ff8-bb40-a8754d16427a@github.com>

On Thu, 16 May 2024 10:33:55 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Small documentation changes.
>
> src/java.base/share/classes/java/util/random/RandomGeneratorFactory.java line 204:
> 
>> 202:                     new RandomGeneratorProperties(rgClass, name, group,
>> 203:                             i, j, k, equidistribution,
>> 204:                             flags | (rgClass.isAnnotationPresent(Deprecated.class) ? DEPRECATED : 0)));
> 
> Hello Raffaello, this is the final remaining reflection usage and even this I think isn't required now that all the random generator implementations reside within java.base as an implementation detail.
> 
> I think we should just skip this annotation check here and set `DEPRECATED` bit on the `flags` to `0` for all implementations. When/if we do deprecate any of the random generators, we can just come here and switch that bit to on for the specific random generator when instantiating this `RandomGeneratorProperties` record. I had a brief look at the code and the documentation in `package-info.java` of `java/util/random` and we don't mention that we rely on the `@Deprecated`  annotation to determine whether an algorithm is deprecated. I think that's a good thing.

Yes, I thought about this the other day but decided for a bit more conservative approach, relying on the annotation.

But I agree that, since the meta-information now resides in `RandomGeneratorProperties`, we might "migrate" the deprecation status here as well.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19212#discussion_r1603264183

From rgiulietti at openjdk.org  Thu May 16 12:47:15 2024
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Thu, 16 May 2024 12:47:15 GMT
Subject: RFR: 8332086: Remove the usage of ServiceLoader in
 j.u.r.RandomGeneratorFactory [v5]
In-Reply-To: <4jBupSTpW5j9Ye4i8sV08c5yauOhELbJNHnN2oGFC9Q=.6d42ba3d-a7dd-4a4b-a6ee-5f5c7cf8b1c9@github.com>
References: <hfB86NksORc-aC6zVxHel_QQd_9aB629SfQjXvl6q5U=.e31daa4b-5cf6-4f3f-a757-79e818a18978@github.com>
 <ZasWP14ViFxaPqk_x3rmDgVFocTX9_aAP1W_kplDjbE=.b5fa3a6a-c303-4fe7-afbe-01700d4a7e85@github.com>
 <4jBupSTpW5j9Ye4i8sV08c5yauOhELbJNHnN2oGFC9Q=.6d42ba3d-a7dd-4a4b-a6ee-5f5c7cf8b1c9@github.com>
Message-ID: <rHT7YEOKWHz1dQc1-X-5cXJPGi5seiAlyRCSRKBBpjI=.e13e5185-675f-469e-8b40-61a228170989@github.com>

On Thu, 16 May 2024 10:51:14 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Small documentation changes.
>
> test/jdk/java/util/Random/RandomTestCoverage.java line 179:
> 
>> 177:         try {
>> 178:             rng = factory.create(12345L);
>> 179:         } catch (UnsupportedOperationException ignore) {
> 
> I think now that we know for sure which algorithm instances don't support which type of seed value and since throwing `UnsupportedOperationException` is now a specification of the `create(...)` methods, we should probably do something like this:
> 
> 
> diff --git a/test/jdk/java/util/Random/RandomTestCoverage.java b/test/jdk/java/util/Random/RandomTestCoverage.java
> index be12d188198..6e5c36e13c3 100644
> --- a/test/jdk/java/util/Random/RandomTestCoverage.java
> +++ b/test/jdk/java/util/Random/RandomTestCoverage.java
> @@ -171,8 +171,37 @@ static void coverFactory(RandomGeneratorFactory factory) {
>          boolean isSplittable = factory.isSplittable();
>  
>          coverRandomGenerator(factory.create());
> -        coverRandomGenerator(factory.create(12345L));
> -        coverRandomGenerator(factory.create(new byte[] {1, 2, 3, 4, 5, 6, 7, 8}));
> +
> +        String algo = factory.name();
> +        // test create(long)
> +        switch (algo) {
> +            // SecureRandom doesn't have long constructors so we expect
> +            // UnsupportedOperationException
> +            case "SecureRandom" -> {
> +                try {
> +                    factory.create(12345L);
> +                    throw new AssertionError("RandomGeneratorFactory.create(long) was expected" +
> +                            "to throw UnsupportedOperationException for " + algo + " but didn't");
> +                } catch (UnsupportedOperationException uoe) {
> +                    // expected
> +                }
> +            }
> +            default -> coverRandomGenerator(factory.create(12345L));
> +        }
> +        // test create(byte[])
> +        switch (algo) {
> +            // these don't have byte[] constructors so we expect UnsupportedOperationException
> +            case "Random", "SplittableRandom" -> {
> +                try {
> +                    factory.create(new byte[] {1, 2, 3, 4, 5, 6, 7, 8});
> +                    throw new AssertionError("RandomGeneratorFactory.create(byte[]) was expected" +
> +                            "to throw UnsupportedOperationException for " + algo + " but didn't");
> +                } catch (UnsupportedOperationException uoe) {
> +                    // expected
> +                }
> +            }
> +            default -> coverRandomGenerator(factory.create(new byte[] {1, 2, 3, 4, 5, 6, 7, 8}));
> + ...

So you want to be very specific. OK.

> test/jdk/java/util/Random/RandomTestCoverage.java line 195:
> 
>> 193:     }
>> 194: 
>> 195:     static void coverDefaults() {
> 
> This test method appears to test the calls to `getDefault()` methods on `RandomGeneratorFactory` and `RandomGenerator` classes, but it isn't being called in the test. We should call this method from `main()` to have test coverage for those methods.

Right

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19212#discussion_r1603274191
PR Review Comment: https://git.openjdk.org/jdk/pull/19212#discussion_r1603277648

From pminborg at openjdk.org  Thu May 16 12:48:24 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 16 May 2024 12:48:24 GMT
Subject: RFR: 8330465: Stable Values and Collections (Internal) [v16]
In-Reply-To: <-KSimQo5kkmCzzMShqGe5QZ9yCSzpWL98gN13v4wP0k=.11dd8d06-18a6-4577-8342-66632cea0b6e@github.com>
References: <-KSimQo5kkmCzzMShqGe5QZ9yCSzpWL98gN13v4wP0k=.11dd8d06-18a6-4577-8342-66632cea0b6e@github.com>
Message-ID: <JSjxsb9D75KaK_bMcAUi-CWOT5rAnR1m0x79nTRfO8U=.351b3c08-541a-4333-9b1b-f6a447c43511@github.com>

> # Stable Values & Collections (Internal)
> 
> ## Summary
> This PR proposes to introduce an internal _Stable Values & Collections_ API, which provides immutable value holders where elements are initialized _at most once_. Stable Values & Collections offer the performance and safety benefits of final fields while offering greater flexibility as to the timing of initialization.
> 
> ## Goals
>  * Provide an easy and intuitive API to describe value holders that can change at most once.
>  * Decouple declaration from initialization without significant footprint or performance penalties.
>  * Reduce the amount of static initializer and/or field initialization code.
>  * Uphold integrity and consistency, even in a multi-threaded environment.
>  
> For more details, see the draft JEP: https://openjdk.org/jeps/8312611
> 
> ## Performance 
> Performance compared to instance variables using two `AtomicReference` and two protected by double-checked locking under concurrent access by all threads:
> 
> 
> Benchmark                                      Mode  Cnt      Score      Error   Units
> StableBenchmark.atomic                        thrpt   10    259.478 ?   36.809  ops/us
> StableBenchmark.dcl                           thrpt   10    225.710 ?   26.638  ops/us
> StableBenchmark.stable                        thrpt   10   4382.478 ? 1151.472  ops/us <- StableValue significantly faster
> 
> 
> Performance compared to static variables protected by `AtomicReference`, class-holder idiom holder, and double-checked locking (all threads):
> 
> 
> Benchmark                                      Mode  Cnt      Score      Error   Units
> StableStaticBenchmark.atomic                  thrpt   10   6487.835 ?  385.639  ops/us
> StableStaticBenchmark.dcl                     thrpt   10   6605.239 ?  210.610  ops/us
> StableStaticBenchmark.stable                  thrpt   10  14338.239 ? 1426.874  ops/us
> StableStaticBenchmark.staticCHI               thrpt   10  13780.341 ? 1839.651  ops/us
> 
> 
> Performance for stable lists (thread safe) in both instance and static contexts whereby we access a single value compared to `ArrayList` instances (which are not thread-safe) (all threads):
> 
> 
> Benchmark                                      Mode  Cnt      Score      Error   Units
> StableListElementBenchmark.instanceArrayList  thrpt   10   5812.992 ? 1169.730  ops/us
> StableListElementBenchmark.instanceList       thrpt   10   4818.643 ?  704.893  ops/us
> StableListElementBenchmark.staticArrayList    thrpt   10   7614.741 ?  564.777  ops/us
> StableListElementBe...

Per Minborg has updated the pull request incrementally with one additional commit since the last revision:

  Fix copyringht issues

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/18794/files
  - new: https://git.openjdk.org/jdk/pull/18794/files/2af0168e..ec7c92cd

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18794&range=15
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18794&range=14-15

  Stats: 206 lines in 13 files changed: 200 ins; 1 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/18794.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18794/head:pull/18794

PR: https://git.openjdk.org/jdk/pull/18794

From pminborg at openjdk.org  Thu May 16 13:15:06 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 16 May 2024 13:15:06 GMT
Subject: RFR: 8331670: Deprecate the Memory-Access Methods in
 sun.misc.Unsafe for Removal [v2]
In-Reply-To: <9RTITm_9xLiCNK3PuMoYhhNHoWAix5HMOz7bvEVfPQc=.1c8e7421-b107-47c8-b7fc-f7435eb243d9@github.com>
References: <9FyO4QpCtH2CNkUEE78_Jjd9xs3bv3WJo16jyowHOvY=.e7131b91-37bb-4624-a60e-72a427a24c92@github.com>
 <9RTITm_9xLiCNK3PuMoYhhNHoWAix5HMOz7bvEVfPQc=.1c8e7421-b107-47c8-b7fc-f7435eb243d9@github.com>
Message-ID: <qiaxu2DvEBGByMMMdQycO7U39iRa6qGadkSOAcDOpbs=.fb3c487e-d3be-43a6-a1cb-5cc07c3b2254@github.com>

On Thu, 16 May 2024 07:14:53 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> This is the implementation changes for JEP 471.
>> 
>> The methods in sun.misc.Unsafe for on-heap and off-heap access are deprecated for removal. This means a removal warning at compile time. No methods have been removed. A deprecated message is added to each of the methods but unlikely to be seen as the JDK does not generate or publish the API docs for this class.
>> 
>> A new command line option --sun-misc-unsafe-memory-access=$value is introduced to allow or deny access to these methods. The default proposed for JDK 23 is "allow" so no change in behavior compared to JDK 22 or previous releases.
>> 
>> A new test is added to test the command line option settings. The existing micros for FFM that use Unsafe are updated to suppress the removal warning at compile time. A new micro is introduced with a small sample of methods to ensure the changes doesn't cause any perf regressions.
>> 
>> For now, the changes include the update to the man page for the "java" command. It might be that this has to be separated out so that it goes with other updates in the release.
>
> Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains ten additional commits since the last revision:
> 
>  - Add removal to DISABLED_WARNINGS
>    Fail at startup if bad value specified to option
>  - Merge
>  - Update man page
>  - Update man page
>  - Fix comment
>  - Merge
>  - Merge
>  - Whitespace
>  - Initial commit

Looks good. It appears the JVM will be able to constant-fold away the `beforeMemoryAcess()` checks but, it would be nice to see the output of the new benchmark for; before PR, `MemoryAccessOption.ALLOW` and `MemoryAccessOption.WARN`.

-------------

Marked as reviewed by pminborg (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19174#pullrequestreview-2060709939

From rgiulietti at openjdk.org  Thu May 16 13:26:29 2024
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Thu, 16 May 2024 13:26:29 GMT
Subject: RFR: 8332086: Remove the usage of ServiceLoader in
 j.u.r.RandomGeneratorFactory [v6]
In-Reply-To: <hfB86NksORc-aC6zVxHel_QQd_9aB629SfQjXvl6q5U=.e31daa4b-5cf6-4f3f-a757-79e818a18978@github.com>
References: <hfB86NksORc-aC6zVxHel_QQd_9aB629SfQjXvl6q5U=.e31daa4b-5cf6-4f3f-a757-79e818a18978@github.com>
Message-ID: <D2uA0UPo6k5BKNihbZkOeZJoY_DKmmZPn0oewgJ6tvI=.594333fd-0deb-4ffc-89b2-57e0611fd46e@github.com>

> All random number generator algorithms are implemented in module `java.base`. The usage of `ServiceLoader` in `j.u.r.RandomGeneratorFactory` is no longer needed.

Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:

  Rely on Deprecated annotation only for legacy generators.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19212/files
  - new: https://git.openjdk.org/jdk/pull/19212/files/920655a5..a77146f5

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19212&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19212&range=04-05

  Stats: 49 lines in 2 files changed: 18 ins; 1 del; 30 mod
  Patch: https://git.openjdk.org/jdk/pull/19212.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19212/head:pull/19212

PR: https://git.openjdk.org/jdk/pull/19212

From rgiulietti at openjdk.org  Thu May 16 13:26:29 2024
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Thu, 16 May 2024 13:26:29 GMT
Subject: RFR: 8332086: Remove the usage of ServiceLoader in
 j.u.r.RandomGeneratorFactory [v5]
In-Reply-To: <8d6Um0qog6MPlI-wjflKoo2CKf_-uZP7N6pg63Iwl9U=.8e69aeb7-9672-4ff8-bb40-a8754d16427a@github.com>
References: <hfB86NksORc-aC6zVxHel_QQd_9aB629SfQjXvl6q5U=.e31daa4b-5cf6-4f3f-a757-79e818a18978@github.com>
 <ZasWP14ViFxaPqk_x3rmDgVFocTX9_aAP1W_kplDjbE=.b5fa3a6a-c303-4fe7-afbe-01700d4a7e85@github.com>
 <2Tv7yoSkIoEuQX2GZuyBnAdGHSpTKCGXV0_K0_UPiks=.dff4cf04-3a5d-4afc-8057-9cebb9b61ddd@github.com>
 <8d6Um0qog6MPlI-wjflKoo2CKf_-uZP7N6pg63Iwl9U=.8e69aeb7-9672-4ff8-bb40-a8754d16427a@github.com>
Message-ID: <YIjnTmRDdxPwHEenjhZTUPKifSA615_2gbPmT-m76BU=.69590d70-7ca7-4b13-bdcb-5b8aa2e2ab40@github.com>

On Thu, 16 May 2024 12:35:22 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> src/java.base/share/classes/java/util/random/RandomGeneratorFactory.java line 204:
>> 
>>> 202:                     new RandomGeneratorProperties(rgClass, name, group,
>>> 203:                             i, j, k, equidistribution,
>>> 204:                             flags | (rgClass.isAnnotationPresent(Deprecated.class) ? DEPRECATED : 0)));
>> 
>> Hello Raffaello, this is the final remaining reflection usage and even this I think isn't required now that all the random generator implementations reside within java.base as an implementation detail.
>> 
>> I think we should just skip this annotation check here and set `DEPRECATED` bit on the `flags` to `0` for all implementations. When/if we do deprecate any of the random generators, we can just come here and switch that bit to on for the specific random generator when instantiating this `RandomGeneratorProperties` record. I had a brief look at the code and the documentation in `package-info.java` of `java/util/random` and we don't mention that we rely on the `@Deprecated`  annotation to determine whether an algorithm is deprecated. I think that's a good thing.
>
> Yes, I thought about this the other day but decided for a bit more conservative approach, relying on the annotation.
> 
> But I agree that, since the meta-information now resides in `RandomGeneratorProperties`, we might "migrate" the deprecation status here as well.

Since the legacy generators are public classes, they can be publicly deprecated, so in the last commit the `DEPRECATED` bit for them still relies on the annotation, which IMO is the authoritative "source of truth".

For the 10 other algorithms, which are accessible only via `RandomFactoryGenerator`, we can rely on the info in `RandomProperties`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19212#discussion_r1603336696

From alanb at openjdk.org  Thu May 16 13:50:14 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 16 May 2024 13:50:14 GMT
Subject: RFR: 8311302: Allow for jlinking a custom runtime without packaged
 modules being present [v23]
In-Reply-To: <DpJV4x9Mnw0upmd3SR_ES2ytuLAo7PsI-ecHERPAOcY=.0a0c2f26-7a9f-4be6-8e71-0494d4673fe7@github.com>
References: <Z0DJ87uKPbjS6mvJIE_oG5m-RWsbERXsytSgV8Bmhdo=.f8723513-0ac6-4e85-9131-3c3924860c61@github.com>
 <Xkl8CJMCXm7iBI2ZnfH9JnoZx08wd5InSwIZHW_kMeQ=.49022322-cb0d-4f1a-947a-6eb37b7da963@github.com>
 <fvDpjxyhqnpaEhF6KhMIJBv_sG87AsuC0axsJYo1Tvw=.442f5a11-44f0-4a00-812a-2c26ec15e8e6@github.com>
 <_sbNFJXG7ghwsfNfxaGvvoDQ7-UtWpnhGnygKsFTsgQ=.623700db-7306-4b34-9e05-ca9059797e39@github.com>
 <DpJV4x9Mnw0upmd3SR_ES2ytuLAo7PsI-ecHERPAOcY=.0a0c2f26-7a9f-4be6-8e71-0494d4673fe7@github.com>
Message-ID: <jVDOxyjqQW4VQy-JvAzdBe1IN2U1oqWsSvFZ1I3psUg=.c1d71ba8-f5b8-4dd8-bad0-369ecb166966@github.com>

On Tue, 16 Apr 2024 13:54:53 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>>> > @mlchung @AlanBateman Any thoughts on this latest version? Is this going into the direction you had envisioned? Any more blockers? The CSR should be up-to-date and is open for review as well. If no more blockers I'll go over this patch once more and clean it up to prepare for integration. Thanks!
>>> 
>>> Thanks for all the efforts on this.
>> 
>> Thanks for looking at this, Alan!
>> 
>>> I've looked through the latest version. I'm a little bit comfortable with LinkDeltaProducer. One reason it's build tool that is tied tied to code in the jdk.jlink module, and secondly is that it copies runtime-image-link.delta into the run-time image. Our long standing position is that the run-time image is created by jlink rather than a combination of jlink and extra stuff copied in by the build.
>>> 
>>> The part that I like with the current proposal is lib/runtime-image-link.delta as it's less complicated that previous iterations that added a resource into the jimage container.
>>> 
>>> What would you (and @mlchung) think of having jlink generate lib/runtime-image-link.delta as a step between the pipeline and image generation?
>> 
>> If I understand you correctly, this would be no longer a build-time only approach to produce the "linkable runtime"? It would be some-kind of jlink-option driven approach (as it would run some code that should only run when producing a linkable runtime is requested)? Other than that, it should be fine as the previous iteration basically did that but at a different phase. Also note that the previous iteration used a build-only jlink plugin so as to satisfy the build-time only approach, yet it ran as part of the plugin-pipeline which wasn't desired either. But it was something similar to what you seem to be describing now. Did I get something wrong?
>
>> If I understand you correctly, this would be no longer a build-time only approach to produce the "linkable runtime"? It would be some-kind of jlink-option driven approach (as it would run some code that should only run when producing a linkable runtime is requested)? Other than that, it should be fine as the previous iteration basically did that but at a different phase. Also note that the previous iteration used a build-only jlink plugin so as to satisfy the build-time only approach, yet it ran as part of the plugin-pipeline which wasn't desired either. But it was something similar to what you seem to be describing now. Did I get something wrong?
> 
> I think it continues to build time, it's just using some hidden jlink option. So yes, it similar to a previous iteration except that it doesn't run as a plugin the pipeline and the delta goes to the lib directory.
> 
> Let's see what @mlchung says. You've put a lot of work into this so let's see if we can converge to avoid too many more rounds.

> @AlanBateman @mlchung The latest update now uses the `jlink` build time option `--generate-linkable-runtime` to add needed resources to the `jimage` when a runtime linkable JDK image is being asked for using the configure option. This now runs outside the plugin-pipeline. I think this is what you meant. Sorry it took longer to get back to this...

I think you've got this to a good place and I think the overall solution is good. It may be that JDK should move to this by default in the future, and at the same time re-visit the restriction on generating an image containing jdk.jlink, but let's see if any issues come up.

I've added myself as Reviewer to the CSR and I'm working through the code changes.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14787#issuecomment-2115298661

From mcimadamore at openjdk.org  Thu May 16 13:58:04 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 16 May 2024 13:58:04 GMT
Subject: RFR: 8331865: Consolidate size and alignment checks in LayoutPath
In-Reply-To: <YP62xs9MjNijSMC6gTf62GRswUyTAKNimgQGZ-PQnKY=.4edbc89a-1a01-4fdb-9880-096cab35af8a@github.com>
References: <CvKkdESp5-uHiuZtQvGortWnzOMV89pfjaCHNBIV4B4=.51ad0f01-2371-48af-b3c6-8a9b80518cdb@github.com>
 <YP62xs9MjNijSMC6gTf62GRswUyTAKNimgQGZ-PQnKY=.4edbc89a-1a01-4fdb-9880-096cab35af8a@github.com>
Message-ID: <eTKhBQscqkgwLn6_x9fqwYHt2W_ECqPqkkzIoLCiKRk=.24c4319b-0877-4c17-aa90-6139fd4dc0fd@github.com>

On Thu, 16 May 2024 11:18:18 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> Do we have any performance tests available to see if there are any potential impacts?

I've run all micro benchmarks whose name match `LoopOver*`. No regression was found. Few benchmarks seems a tad faster, but the percentages are so tiny that I'm sure it has nothing to do with the patch. I compared results before/after using [JMH visualizer](https://jmh.morethan.io/).

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19251#issuecomment-2115321357

From pminborg at openjdk.org  Thu May 16 14:07:09 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 16 May 2024 14:07:09 GMT
Subject: RFR: 8330465: Stable Values and Collections (Internal) [v16]
In-Reply-To: <JSjxsb9D75KaK_bMcAUi-CWOT5rAnR1m0x79nTRfO8U=.351b3c08-541a-4333-9b1b-f6a447c43511@github.com>
References: <-KSimQo5kkmCzzMShqGe5QZ9yCSzpWL98gN13v4wP0k=.11dd8d06-18a6-4577-8342-66632cea0b6e@github.com>
 <JSjxsb9D75KaK_bMcAUi-CWOT5rAnR1m0x79nTRfO8U=.351b3c08-541a-4333-9b1b-f6a447c43511@github.com>
Message-ID: <2EAy6RJqZenabnmy5aywucjDykt5ZK6IvDxlnXwl98E=.98c8bf93-f11e-40cc-931f-7113f0e9cfda@github.com>

On Thu, 16 May 2024 12:48:24 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> # Stable Values & Collections (Internal)
>> 
>> ## Summary
>> This PR proposes to introduce an internal _Stable Values & Collections_ API, which provides immutable value holders where elements are initialized _at most once_. Stable Values & Collections offer the performance and safety benefits of final fields while offering greater flexibility as to the timing of initialization.
>> 
>> ## Goals
>>  * Provide an easy and intuitive API to describe value holders that can change at most once.
>>  * Decouple declaration from initialization without significant footprint or performance penalties.
>>  * Reduce the amount of static initializer and/or field initialization code.
>>  * Uphold integrity and consistency, even in a multi-threaded environment.
>>  
>> For more details, see the draft JEP: https://openjdk.org/jeps/8312611
>> 
>> ## Performance 
>> Performance compared to instance variables using two `AtomicReference` and two protected by double-checked locking under concurrent access by all threads:
>> 
>> 
>> Benchmark                                      Mode  Cnt      Score      Error   Units
>> StableBenchmark.atomic                        thrpt   10    259.478 ?   36.809  ops/us
>> StableBenchmark.dcl                           thrpt   10    225.710 ?   26.638  ops/us
>> StableBenchmark.stable                        thrpt   10   4382.478 ? 1151.472  ops/us <- StableValue significantly faster
>> 
>> 
>> Performance compared to static variables protected by `AtomicReference`, class-holder idiom holder, and double-checked locking (all threads):
>> 
>> 
>> Benchmark                                      Mode  Cnt      Score      Error   Units
>> StableStaticBenchmark.atomic                  thrpt   10   6487.835 ?  385.639  ops/us
>> StableStaticBenchmark.dcl                     thrpt   10   6605.239 ?  210.610  ops/us
>> StableStaticBenchmark.stable                  thrpt   10  14338.239 ? 1426.874  ops/us
>> StableStaticBenchmark.staticCHI               thrpt   10  13780.341 ? 1839.651  ops/us
>> 
>> 
>> Performance for stable lists (thread safe) in both instance and static contexts whereby we access a single value compared to `ArrayList` instances (which are not thread-safe) (all threads):
>> 
>> 
>> Benchmark                                      Mode  Cnt      Score      Error   Units
>> StableListElementBenchmark.instanceArrayList  thrpt   10   5812.992 ? 1169.730  ops/us
>> StableListElementBenchmark.instanceList       thrpt   10   4818.643 ?  704.893  ops/us
>> StableListElementBenchmark...
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix copyringht issues

Here are some updated benchmark graphs where we sum two instance variables of different sorts (higher is better):

![image](https://github.com/openjdk/jdk/assets/7457876/d82561d6-e803-4345-b6d2-6b0402e60211)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18794#issuecomment-2115343828

From mcimadamore at openjdk.org  Thu May 16 14:14:12 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 16 May 2024 14:14:12 GMT
Subject: RFR: 8331865: Consolidate size and alignment checks in LayoutPath
In-Reply-To: <eTKhBQscqkgwLn6_x9fqwYHt2W_ECqPqkkzIoLCiKRk=.24c4319b-0877-4c17-aa90-6139fd4dc0fd@github.com>
References: <CvKkdESp5-uHiuZtQvGortWnzOMV89pfjaCHNBIV4B4=.51ad0f01-2371-48af-b3c6-8a9b80518cdb@github.com>
 <YP62xs9MjNijSMC6gTf62GRswUyTAKNimgQGZ-PQnKY=.4edbc89a-1a01-4fdb-9880-096cab35af8a@github.com>
 <eTKhBQscqkgwLn6_x9fqwYHt2W_ECqPqkkzIoLCiKRk=.24c4319b-0877-4c17-aa90-6139fd4dc0fd@github.com>
Message-ID: <UmdCxnGlDjVJ98TCRxhGz0hIdQexIanpEUFPyd6jemM=.8a9fc62d-63a9-47d0-bd9d-48fb081053c4@github.com>

On Thu, 16 May 2024 13:55:15 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> > Do we have any performance tests available to see if there are any potential impacts?
> 
> I've run all micro benchmarks whose name match `LoopOver*`. No regression was found. Few benchmarks seems a tad faster, but the percentages are so tiny that I'm sure it has nothing to do with the patch. I compared results before/after using [JMH visualizer](https://jmh.morethan.io/).

Results here: https://cr.openjdk.org/~mcimadamore/jdk/8331865/
Unfortunately I can't seem to be able to upload the results in the visualizer (which would be handy, so I could share a link to the results). Not sure if it's an issue in the visualizer, or in the cr server itself. But, it is possible to at least download the above results locally, and then upload them to the visualizer tool.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19251#issuecomment-2115361171

From mcimadamore at openjdk.org  Thu May 16 14:37:15 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 16 May 2024 14:37:15 GMT
Subject: RFR: 8331865: Consolidate size and alignment checks in LayoutPath
 [v2]
In-Reply-To: <CvKkdESp5-uHiuZtQvGortWnzOMV89pfjaCHNBIV4B4=.51ad0f01-2371-48af-b3c6-8a9b80518cdb@github.com>
References: <CvKkdESp5-uHiuZtQvGortWnzOMV89pfjaCHNBIV4B4=.51ad0f01-2371-48af-b3c6-8a9b80518cdb@github.com>
Message-ID: <sbhzMEtBjBJuxpO_JdNI4tCiTZwCG8WNBXR5_G2TVXo=.1726357f-4f88-46dc-aaa6-b773df9292df@github.com>

> When creating a nested memory access var handle, we ensure that the segment is accessed at the correct alignment for the root layout being accessed. But we do not ensure that the segment has at least the size of the accessed root layout. Example:
> 
> 
> MemoryLayout LAYOUT = sequenceLayout(2, structLayout(JAVA_INT.withName("x"), JAVA_INT.withName("y")));
> VarHandle X_HANDLE = LAYOUT.varHandle(PathElement.sequenceElement(), PathElement.groupElement("x"));
> 
> 
> If I have a memory segment whose size is 12, I can successfully call X_HANDLE on it with index 1, like so:
> 
> 
> MemorySegment segment = Arena.ofAuto().allocate(12);
> int x = (int)X_HANDLE.get(segment, 0, 1);
> 
> 
> This seems incorrect: after all, the provided segment doesn't have enough space to fit _two_ elements of the nested structs. 
> 
> This PR adds checks to detect this kind of scenario earlier, thus improving usability. To achieve this we could, in principle, just tweak `LayoutPath::checkEnclosingLayout` and add the required size check.
> 
> But doing so will add yet another redundant check on top of the other already added by [pull/19124](https://git.openjdk.org/jdk/pull/19124). Instead, this PR rethinks how memory segment var handles are created, in order to eliminate redundant checks.
> 
> The main observation is that size and alignment checks depend on an _enclosing_ layout. This layout *might* be the very same value layout being accessed (this is the case when e.g. using `JAVA_INT.varHandle()`). But, in the general case, the accessed value layout and the enclosing layout might differ (e.g. think about accessing a struct field).
> 
> Furthermore, the enclosing layout check depends on the _base_ offset at which the segment is accessed, _prior_ to any index computation that occurs if the accessed layout path has any open elements. It is important to notice that this base offset is only available when looking at the var handle that is returned to the user. For instance, an indexed var handle with coordinates:
> 
> 
> (MemorySegment, long /* base */, long /* index 1 */, long /* index 2 */, long /* index 3 */)
> 
> 
> Is obtained through adaptation, by taking a more basic var handle of the form:
> 
> 
> (MemorySegment, long /* offset */)
> 
> 
> And then injecting the result of the index multiplication into `offset`. As such, we can't add an enclosing layout check inside the var handle returned by `VarHandles::memorySegmentViewHandle`, as doing so will end up seeing the *wrong* offset (e.g. an offset in which the index part has already been mixed in)...

Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:

  Fix copyrights

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19251/files
  - new: https://git.openjdk.org/jdk/pull/19251/files/236007c3..a7b09d9d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19251&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19251&range=00-01

  Stats: 8 lines in 5 files changed: 0 ins; 3 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/19251.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19251/head:pull/19251

PR: https://git.openjdk.org/jdk/pull/19251

From mcimadamore at openjdk.org  Thu May 16 14:37:16 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 16 May 2024 14:37:16 GMT
Subject: RFR: 8331865: Consolidate size and alignment checks in LayoutPath
 [v2]
In-Reply-To: <sbhzMEtBjBJuxpO_JdNI4tCiTZwCG8WNBXR5_G2TVXo=.1726357f-4f88-46dc-aaa6-b773df9292df@github.com>
References: <CvKkdESp5-uHiuZtQvGortWnzOMV89pfjaCHNBIV4B4=.51ad0f01-2371-48af-b3c6-8a9b80518cdb@github.com>
 <sbhzMEtBjBJuxpO_JdNI4tCiTZwCG8WNBXR5_G2TVXo=.1726357f-4f88-46dc-aaa6-b773df9292df@github.com>
Message-ID: <l9bZBYIXm-7FJfJE9pwUKnBtdGG-ao-1I471Rwpdopk=.6204904a-344a-4be1-ac84-b1b8371ca72f@github.com>

On Thu, 16 May 2024 14:34:41 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> When creating a nested memory access var handle, we ensure that the segment is accessed at the correct alignment for the root layout being accessed. But we do not ensure that the segment has at least the size of the accessed root layout. Example:
>> 
>> 
>> MemoryLayout LAYOUT = sequenceLayout(2, structLayout(JAVA_INT.withName("x"), JAVA_INT.withName("y")));
>> VarHandle X_HANDLE = LAYOUT.varHandle(PathElement.sequenceElement(), PathElement.groupElement("x"));
>> 
>> 
>> If I have a memory segment whose size is 12, I can successfully call X_HANDLE on it with index 1, like so:
>> 
>> 
>> MemorySegment segment = Arena.ofAuto().allocate(12);
>> int x = (int)X_HANDLE.get(segment, 0, 1);
>> 
>> 
>> This seems incorrect: after all, the provided segment doesn't have enough space to fit _two_ elements of the nested structs. 
>> 
>> This PR adds checks to detect this kind of scenario earlier, thus improving usability. To achieve this we could, in principle, just tweak `LayoutPath::checkEnclosingLayout` and add the required size check.
>> 
>> But doing so will add yet another redundant check on top of the other already added by [pull/19124](https://git.openjdk.org/jdk/pull/19124). Instead, this PR rethinks how memory segment var handles are created, in order to eliminate redundant checks.
>> 
>> The main observation is that size and alignment checks depend on an _enclosing_ layout. This layout *might* be the very same value layout being accessed (this is the case when e.g. using `JAVA_INT.varHandle()`). But, in the general case, the accessed value layout and the enclosing layout might differ (e.g. think about accessing a struct field).
>> 
>> Furthermore, the enclosing layout check depends on the _base_ offset at which the segment is accessed, _prior_ to any index computation that occurs if the accessed layout path has any open elements. It is important to notice that this base offset is only available when looking at the var handle that is returned to the user. For instance, an indexed var handle with coordinates:
>> 
>> 
>> (MemorySegment, long /* base */, long /* index 1 */, long /* index 2 */, long /* index 3 */)
>> 
>> 
>> Is obtained through adaptation, by taking a more basic var handle of the form:
>> 
>> 
>> (MemorySegment, long /* offset */)
>> 
>> 
>> And then injecting the result of the index multiplication into `offset`. As such, we can't add an enclosing layout check inside the var handle returned by `VarHandles::memorySegmentViewHandle`, as doing so will end up seeing the *wrong* off...
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix copyrights

test/jdk/java/foreign/TestHeapAlignment.java line 48:

> 46:         assertAligned(align, layout, () -> layout.varHandle().get(segment, 0L));
> 47:         assertAligned(align, layout, () -> layout.varHandle().set(segment, 0L, val));
> 48:         MemoryLayout seq = MemoryLayout.sequenceLayout(1, layout);

This change was an actual issue in the test, which was made manifest by the new checks

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19251#discussion_r1603496914

From vklang at openjdk.org  Thu May 16 14:59:23 2024
From: vklang at openjdk.org (Viktor Klang)
Date: Thu, 16 May 2024 14:59:23 GMT
Subject: RFR: 8332154: Memory leak in SynchronousQueue
Message-ID: <Fj3W5LlneHODz3PcBD0Ypu2f34UYvxw1iLLKz5pba-I=.0f419338-0a23-4834-8404-55aeab4b813f@github.com>

Local testing seems to indicate that this fix (which mirrors what's done in the FIFO mode) addresses the problem.

But with that said, I haven't come up with a decent way of adding some form of regression test. Suggestions are most welcome. /cc @DougLea

-------------

Commit messages:
 - Memory leak in unfair mode of SynchronousQueue addressed

Changes: https://git.openjdk.org/jdk/pull/19271/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19271&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8332154
  Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/19271.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19271/head:pull/19271

PR: https://git.openjdk.org/jdk/pull/19271

From vklang at openjdk.org  Thu May 16 15:09:01 2024
From: vklang at openjdk.org (Viktor Klang)
Date: Thu, 16 May 2024 15:09:01 GMT
Subject: RFR: 8332154: Memory leak in SynchronousQueue
In-Reply-To: <Fj3W5LlneHODz3PcBD0Ypu2f34UYvxw1iLLKz5pba-I=.0f419338-0a23-4834-8404-55aeab4b813f@github.com>
References: <Fj3W5LlneHODz3PcBD0Ypu2f34UYvxw1iLLKz5pba-I=.0f419338-0a23-4834-8404-55aeab4b813f@github.com>
Message-ID: <bTv3Bc8P355m7kNSPOd1_ybXXewKB6lvqOwzKtO58cE=.cb6dc72f-ef56-46ca-a5b4-7d821327e6ec@github.com>

On Thu, 16 May 2024 14:54:52 GMT, Viktor Klang <vklang at openjdk.org> wrote:

> Local testing seems to indicate that this fix (which mirrors what's done in the FIFO mode) addresses the problem.
> 
> But with that said, I haven't come up with a decent way of adding some form of regression test. Suggestions are most welcome. /cc @DougLea

@AlanBateman @DougLea Reviews are most welcome :)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19271#issuecomment-2115505240

From amansha at kth.se  Thu May 16 15:15:51 2024
From: amansha at kth.se (Aman Sharma)
Date: Thu, 16 May 2024 15:15:51 +0000
Subject: Deterministic naming of subclasses of
 `java/lang/reflect/Proxy`
In-Reply-To: <50405ca9c0a64372bace175b932f9ef7@kth.se>
References: <bf26eb2f74874e02876b3868311922a9@kth.se>,
 <CABe8uE0fk71Xy_PYHikSw9OtXE_i+M9zMbayPEXuTxLWLoy2ag@mail.gmail.com>,
 <50405ca9c0a64372bace175b932f9ef7@kth.se>
Message-ID: <fc0764e922af49e096d812284faea412@kth.se>

Hi,


> have not looked into LambdaMetafactory because I did not encounter it as a problem so far


It is possible that java agents are unable to intercept it. `-verbose:class` logs classes such as "org.apache.pdfbox.cos.COSDocument$$Lambda/0x00007a80631a0d08".


Regards,
Aman Sharma

PhD Student
KTH Royal Institute of Technology
School of Electrical Engineering and Computer Science (EECS)
Department of Theoretical Computer Science (TCS)
<http://www.kth.se><https://www.kth.se/profile/amansha><https://www.kth.se/profile/amansha>
<https://www.kth.se/profile/amansha>https://algomaster99.github.io/
________________________________
From: Aman Sharma
Sent: Thursday, May 16, 2024 2:11:59 PM
To: liangchenblue at gmail.com; core-libs-dev
Cc: Martin Monperrus
Subject: Re: Re: Deterministic naming of subclasses of `java/lang/reflect/Proxy`


Hi,


Thanks for your response, Liang!


> I think you meant CVE-2021-42392 instead of 2022.


Sorry of the error. I indeed meant CVE-2021-42392<https://nvd.nist.gov/vuln/detail/cve-2021-42392>.


> Leyden mainly avoids this unstable generation by performing a training run to collect classes loaded


Would love to know the details of Project Leyden and how they worked so far to focus on this goal. In our case, the training run is the test suite.


> GeneratedConstructorAccessor is already retired by JEP 416 [2] in Java 18


I did see them not appearing in my allowlist when I ran my study subject (Apache PDFBox) with Java 21. Thanks for letting me know about this JEP. I see they are re-implemented with method handles.


> How are you checking the classes?


To detect runtime generated code, we have javaagent that is hooked statically to the test suite execution. It gives us all classes that that is loaded post the JVM and the javaagent are loaded. So we only check the classes loaded for the purpose of running the application. This is also why we did not choose -agentlib as it would give classes for the setting up JVM and javaagent and we the user of our tool must the classes they load.


Next, we have a `ClassFileTransformer` hook in the agent where we produce the checksum using the bytecode. And we compare the checksum with the one existing in the allowlist. The checksum computation algorithm is same for both steps. Let me describe how I compute the checksum.


  1.  I get the CONSTANT_Class_info<https://docs.oracle.com/javase/specs/jvms/se11/html/jvms-4.html#jvms-4.4.1> entry corresponding to `this_class` and rewrite the CONSTANT_Utf8_info<https://docs.oracle.com/javase/specs/jvms/se11/html/jvms-4.html#jvms-4.4.7> corresponding to a fix String constant, say "foo".
  2.  Since, the name of the class is used to refer to its types members (fields/method), I get all CONSTANT_Fieldref_info<https://docs.oracle.com/javase/specs/jvms/se11/html/jvms-4.html#jvms-4.4.2> and if its `class_index` corresponds to the old `this_class`, we rewrite the UTF8 value of class_index to the same constant "foo".
  3.  Next, since the naming of the fields, in Proxy classes, are also suffixed by numbers, for example, `private static Method m4`, we rewrite the UTF8 value of name in the CONSTANT_NameAndType_info<https://docs.oracle.com/javase/specs/jvms/se11/html/jvms-4.html#jvms-4.4.6>.
  4.  These fields can also have a random order so we simply sort the entire byte code using `Arrays.sort(byte[])` to eliminate any differences due to ordering of fields/methods.
  5.  Simply sorting the byte array still had minute differences. I could not understand why they existed even though values in constant pool of the bytecode in allowlist and at runtime were exactly the same after rewriting. The differences existed in the bytes of the Code attribute of methods. I concluded that the bytes stored some position information. To avoid this, I created a subarray where I considered the bytes corresponding to `CONSTANT_Utf8_info.bytes` only. Computing a checksum for it resulted in the same checksums for both classfiles.

Let's understand the whole approach with an example of Proxy class.

`

public final class $Proxy42 extends Proxy implements org.apache.logging.log4j.core.config.plugins.Plugin {

`

The will go in the allowlist as "Proxy_Plugin: <SHA256 checksum>".

When the same class is intercepted at runtime, say "$Proxy10", we look for "Proxy_Plugin" in the allowlist and since the checksum algorithm is same in both cases, we get a match and let the class load.

This approach has seemed to work well for Proxy classes, Generated Constructor Accessor (which is removed as you said). I also looked at the species generated by method handles. I did not notice any modification in them. Their name generation seemed okay to me. If some new Species are generated, it is of course detected since it is not in the allowlist.

I have not looked into LambdaMetafactory because I did not encounter it as a problem so far, but I am aware its name generation is also unstable. I have run my approach only a few projects only. And for hidden classes, I assume the the agent won't be able to intercept them so detecting them would be really hard.


Regards,
Aman Sharma

PhD Student
KTH Royal Institute of Technology
School of Electrical Engineering and Computer Science (EECS)
Department of Theoretical Computer Science (TCS)
<http://www.kth.se><https://www.kth.se/profile/amansha><https://www.kth.se/profile/amansha>
<https://www.kth.se/profile/amansha>https://algomaster99.github.io/
________________________________
From: liangchenblue at gmail.com <liangchenblue at gmail.com>
Sent: Thursday, May 16, 2024 5:52:03 AM
To: Aman Sharma; core-libs-dev
Cc: Martin Monperrus
Subject: Re: Deterministic naming of subclasses of `java/lang/reflect/Proxy`

Hi Aman,
I think you meant CVE-2021-42392 instead of 2022.

For your approach of an "allowlist" for Java runtime, project Leyden is looking to generate a static image [1], that
> At run time it cannot load classes from outside the image, nor can it create classes dynamically.
Leyden mainly avoids this unstable generation by performing a training run to collect classes loaded and even object graphs; I am not familiar with the details unfortunately.

Otherwise, the Proxy discussion belongs better to core-libs-dev, as java.lang.reflect.Proxy is part of Java's core libraries. I am replying this thread to core-libs-dev.

For your perceived problem that classes don't have unique names, your description sounds dubious: GeneratedConstructorAccessor is already retired by JEP 416 [2] in Java 18, and there are many other cases in which JDK generates classes without stable names, notoriously LambdaMetafactory (Gradle wished for cacheable Lambdas); the same applies for the generated classes for MethodHandle's LambdaForms (which carries implementation code for LambdaForm). How are you checking the classes? It seems you are not checking hidden classes. Proxy and Lambda classes are defined by the caller's class loader, while LambdaForms are under JDK's system class loader I think. We need to ensure you are correctly finding all unstable classes before we can proceed.

[1]: https://openjdk.org/projects/leyden/notes/01-beginnings
[2]: https://openjdk.org/jeps/416

On Wed, May 15, 2024 at 7:00?PM Aman Sharma <amansha at kth.se<mailto:amansha at kth.se>> wrote:

Hi,


My name is Aman and I am a PhD student at KTH Royal Institute of Technology, Stockholm, Sweden. I research as part of CHAINS<https://chains.proj.kth.se/> project to strengthen the software supply chain of multiple ecosystem. I particularly focus on runtime integrity in Java. In this email, I want to write about an issue I have discovered with dynamic generation of `java.lang.reflect.Proxy`classes. I will propose a solution and would love to hear the feedback from the community. Let me know if this is the correct mailing-list for such discussions. It seemed the most relevant from this list<https://mail.openjdk.org/mailman/listinfo>.


My research


Java has features to load class on the fly - it can either download or generate a class at runtime. These features are useful for inner workings of JDK. For example, implementing annotations, reflective access, etc. However, these features have also contributed to critical vulnerabilities in the past - CVE-2021-44228  (log4shell), CVE-2022-33980, CVE-2022-42392. All of these vulnerabilities have one thing in common - a class that was not known during build time was downloaded/generated at runtime and loaded into JVM.


To defend against such vulnerabilities, we propose a solution to allowlist classes for runtime. This allowlist will contain an exhaustive list of classes that can be loaded by the JVM and it will be enforced at runtime. We build this allowlist from three sources:

  1.  All classes of all modules provided by the Java Standard Library. We use ClassGraph<https://github.com/classgraph/classgraph> to scan the JDK.
  2.  We can take the source code and all dependencies of an application. We use a software bill of materials to get all the data.
  3.  Finally, we use run the test suite to include any runtime downloaded/generated classes.

Such a list is able to prevent the above 3 CVEs because it does not let the "unknown" bytecode to be loaded.

Problem with generating such an allowlist

The first two parts of the allowlist are easy to get. The problem is with the third step where we want to allowlist all the classes that could be downloaded or generated. Upon running the test suite and hooking to the classes it loads, we observer that the list consists of classes that are called "com/sun/proxy/$Proxy2", "jdk/internal/reflect/GeneratedConstructorAccessor3" among many more. The purpose of these classes can be identifed. The proxy class is created for to implement an annotation. The accessor gives access to constructor of a class to the JVM.

When enforcing this allowlist at runtime, we see that the bytecode content for "com/sun/proxy/$Proxy2" differs in the allowlist and at runtime. In our case, we we are experimenting with pdfbox<https://github.com/apache/pdfbox> so we created the allowlist using its test suite. Then we enforced this allowlist while running some of its subcommands. However, there was some other proxy class say "com/sun/proxy/$Proxy5" at runtime that implemented the same interfaces and had the same methods as "com/sun/proxy/$Proxy2" in the allowlist. They only differed in the name of the class, order of fields, and types for fields references. This could happen because the order of the loading of class is workload dependent, but it causes problem to generate such an allowlist.

Solution

We propose that naming of subclasses of "java/lang/reflect/Proxy" should not be dependent upon the order of loading. In order to do so, two issues can be fixed:

  1.  The naming of the class should not be based on AtomicLong<https://github.com/openjdk/jdk/blob/b687aa550837830b38f0f0faa69c353b1e85219c/src/java.base/share/classes/java/lang/reflect/Proxy.java#L531><https://github.com/openjdk/jdk/blob/4083255440cfbf39b9683ea88a433d71ec6111e7/src/java.base/share/classes/java/lang/reflect/Proxy.java#L531>. Rather it could be named based on the interfaces it implements. I also wonder why AtomicLong is chosen in the first place.
  2.  Methods of the interfaces must be in a particular order. Right now, they are not sorted in any particular order<https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/lang/Class.java#L2178>.


These fixes will make proxy class generation deterministic with respect to order of loading and won't be flagged at runtime since the test suite would already detect them.

I would love to hear from the community about these ideas. If in agreement, I would be happy to produce a patch. I have discovered this issue with subclasses of GeneratedConstructorAccessor<https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/jdk/internal/reflect/ConstructorAccessor.java> as well and I imagine it will also apply to some other runtime generated classes. If you disagree, please let me know also. It helps with my research.

I also have PoCs for the above CVEs<https://github.com/chains-project/exploits-for-sbom.exe> and a proof concept tool is being developed under the name sbom.exe<https://github.com/chains-project/sbom.exe> in case any one wonders about the implementation. I would also be happy to explain more.

Regards,
Aman Sharma

PhD Student
KTH Royal Institute of Technology
School of Electrical Engineering and Computer Science (EECS)
Department of Theoretical Computer Science (TCS)
<http://www.kth.se><https://www.kth.se/profile/amansha><https://www.kth.se/profile/amansha>
<https://www.kth.se/profile/amansha>https://algomaster99.github.io/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240516/0f9d0c9d/attachment-0001.htm>

From rotanolexandr842 at gmail.com  Thu May 16 15:28:02 2024
From: rotanolexandr842 at gmail.com (Olexandr Rotan)
Date: Thu, 16 May 2024 18:28:02 +0300
Subject: RFR: 8330465: Stable Values and Collections (Internal) [v16]
In-Reply-To: <2EAy6RJqZenabnmy5aywucjDykt5ZK6IvDxlnXwl98E=.98c8bf93-f11e-40cc-931f-7113f0e9cfda@github.com>
References: <-KSimQo5kkmCzzMShqGe5QZ9yCSzpWL98gN13v4wP0k=.11dd8d06-18a6-4577-8342-66632cea0b6e@github.com>
 <JSjxsb9D75KaK_bMcAUi-CWOT5rAnR1m0x79nTRfO8U=.351b3c08-541a-4333-9b1b-f6a447c43511@github.com>
 <2EAy6RJqZenabnmy5aywucjDykt5ZK6IvDxlnXwl98E=.98c8bf93-f11e-40cc-931f-7113f0e9cfda@github.com>
Message-ID: <CAL5bRt9SEF2ZiRydnvChDuJy8Mi3dsCHJMmx-uZ3yQDYfagmqw@mail.gmail.com>

Is it possible to make stable values and collections Serializable? I see
various applications for this feature in entity classes as a way to
preserve immutability of entity fields and at the same time not break
current JPA specifications. It is a *very* common task in commercial
development. Current workarounds lack either thread safety or performance,
and this looks like a really good solution for both of those problems.
However, unless StableValue is serializable, it is really unlikely that JPA
will adopt them (we have precedent with Optional).

On Thu, May 16, 2024 at 5:07?PM Per Minborg <pminborg at openjdk.org> wrote:

> On Thu, 16 May 2024 12:48:24 GMT, Per Minborg <pminborg at openjdk.org>
> wrote:
>
> >> # Stable Values & Collections (Internal)
> >>
> >> ## Summary
> >> This PR proposes to introduce an internal _Stable Values & Collections_
> API, which provides immutable value holders where elements are initialized
> _at most once_. Stable Values & Collections offer the performance and
> safety benefits of final fields while offering greater flexibility as to
> the timing of initialization.
> >>
> >> ## Goals
> >>  * Provide an easy and intuitive API to describe value holders that can
> change at most once.
> >>  * Decouple declaration from initialization without significant
> footprint or performance penalties.
> >>  * Reduce the amount of static initializer and/or field initialization
> code.
> >>  * Uphold integrity and consistency, even in a multi-threaded
> environment.
> >>
> >> For more details, see the draft JEP: https://openjdk.org/jeps/8312611
> >>
> >> ## Performance
> >> Performance compared to instance variables using two `AtomicReference`
> and two protected by double-checked locking under concurrent access by all
> threads:
> >>
> >>
> >> Benchmark                                      Mode  Cnt      Score
>   Error   Units
> >> StableBenchmark.atomic                        thrpt   10    259.478 ?
>  36.809  ops/us
> >> StableBenchmark.dcl                           thrpt   10    225.710 ?
>  26.638  ops/us
> >> StableBenchmark.stable                        thrpt   10   4382.478 ?
> 1151.472  ops/us <- StableValue significantly faster
> >>
> >>
> >> Performance compared to static variables protected by
> `AtomicReference`, class-holder idiom holder, and double-checked locking
> (all threads):
> >>
> >>
> >> Benchmark                                      Mode  Cnt      Score
>   Error   Units
> >> StableStaticBenchmark.atomic                  thrpt   10   6487.835 ?
> 385.639  ops/us
> >> StableStaticBenchmark.dcl                     thrpt   10   6605.239 ?
> 210.610  ops/us
> >> StableStaticBenchmark.stable                  thrpt   10  14338.239 ?
> 1426.874  ops/us
> >> StableStaticBenchmark.staticCHI               thrpt   10  13780.341 ?
> 1839.651  ops/us
> >>
> >>
> >> Performance for stable lists (thread safe) in both instance and static
> contexts whereby we access a single value compared to `ArrayList` instances
> (which are not thread-safe) (all threads):
> >>
> >>
> >> Benchmark                                      Mode  Cnt      Score
>   Error   Units
> >> StableListElementBenchmark.instanceArrayList  thrpt   10   5812.992 ?
> 1169.730  ops/us
> >> StableListElementBenchmark.instanceList       thrpt   10   4818.643 ?
> 704.893  ops/us
> >> StableListElementBenchmark...
> >
> > Per Minborg has updated the pull request incrementally with one
> additional commit since the last revision:
> >
> >   Fix copyringht issues
>
> Here are some updated benchmark graphs where we sum two instance variables
> of different sorts (higher is better):
>
> ![image](
> https://github.com/openjdk/jdk/assets/7457876/d82561d6-e803-4345-b6d2-6b0402e60211
> )
>
> -------------
>
> PR Comment: https://git.openjdk.org/jdk/pull/18794#issuecomment-2115343828
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240516/7fa869a5/attachment.htm>

From naoto at openjdk.org  Thu May 16 16:16:06 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 16 May 2024 16:16:06 GMT
Subject: RFR: 8331202: Support for Duration until another Instant [v3]
In-Reply-To: <XB3CH0FfzXRlqRuGgU8ErfR4IkT1sb8rfGTIbQSKR1s=.40ad8e30-f2f9-4d14-b8b0-84f7799f688a@github.com>
References: <QgXldf9AnNqL8Vix38fsGGS0WnMTSbEO1Zo5ndd3Tdw=.5587eb0f-645d-4b9c-a6ef-87eaf8d7badf@github.com>
 <XB3CH0FfzXRlqRuGgU8ErfR4IkT1sb8rfGTIbQSKR1s=.40ad8e30-f2f9-4d14-b8b0-84f7799f688a@github.com>
Message-ID: <E0GFlb4Z0vkMpCzidU0Kg4tuCYMR6NqCH05Qi6rsotM=.e57aa324-9bc7-49f2-80fc-4d335f1ecfa9@github.com>

On Wed, 1 May 2024 17:21:20 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> A new method on Instant to return the duration `until` another Instant is suggested per the following discussion thread:
>> 
>> https://mail.openjdk.org/pipermail/core-libs-dev/2024-April/122131.html
>> 
>> A CSR has also been drafted.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Addressing CSR reviews

Hearing no further comments, integrating this PR.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19007#issuecomment-2115651450

From naoto at openjdk.org  Thu May 16 16:16:07 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 16 May 2024 16:16:07 GMT
Subject: Integrated: 8331202: Support for Duration until another Instant
In-Reply-To: <QgXldf9AnNqL8Vix38fsGGS0WnMTSbEO1Zo5ndd3Tdw=.5587eb0f-645d-4b9c-a6ef-87eaf8d7badf@github.com>
References: <QgXldf9AnNqL8Vix38fsGGS0WnMTSbEO1Zo5ndd3Tdw=.5587eb0f-645d-4b9c-a6ef-87eaf8d7badf@github.com>
Message-ID: <WUTEuG6zgNL1D69tkxk5dcASSXEVH7dSZfiZtkwk_6Y=.f364ee87-c13b-4bb4-baf4-80df23a4c446@github.com>

On Mon, 29 Apr 2024 19:40:31 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> A new method on Instant to return the duration `until` another Instant is suggested per the following discussion thread:
> 
> https://mail.openjdk.org/pipermail/core-libs-dev/2024-April/122131.html
> 
> A CSR has also been drafted.

This pull request has now been integrated.

Changeset: 25991516
Author:    Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/259915168d6656b1b8ddad03c377082d6a5224e5
Stats:     58 lines in 2 files changed: 55 ins; 0 del; 3 mod

8331202: Support for Duration until another Instant

Reviewed-by: joehw, scolebourne, rriggs

-------------

PR: https://git.openjdk.org/jdk/pull/19007

From naoto at openjdk.org  Thu May 16 16:30:08 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 16 May 2024 16:30:08 GMT
Subject: RFR: 8330276: Console methods with explicit Locale [v7]
In-Reply-To: <obT5NKXsV-mvpwqSJxGBtbiGfelyoPuqeGM_SyuFXLc=.aa4fecaf-6788-4d67-a973-86408830c435@github.com>
References: <GT275XVwYlYL3PhYwOTQ_-HwKqp9QYUeIzEIeJKEwkQ=.9a7faf08-8637-45a3-97bd-fd58756a6711@github.com>
 <obT5NKXsV-mvpwqSJxGBtbiGfelyoPuqeGM_SyuFXLc=.aa4fecaf-6788-4d67-a973-86408830c435@github.com>
Message-ID: <IS5XsEslBpuXkKuHaB99K_JrITF6gJwFtGSpyI2K_6c=.408cc252-8091-4e95-9b92-4fc19b6171a8@github.com>

On Wed, 15 May 2024 17:05:17 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Proposing new overloaded methods in `java.io.Console` class that explicitly take a `Locale` argument. Existing methods rely on the default locale, so the users won't be able to format their prompts/outputs in a certain locale explicitly.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reverted test workaround. Fixed JLine (backing out a questionable change)

The changeset included a workaround patch to the upstream JLine. An issue for it was created by Jan: https://github.com/jline/jline3/issues/982

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18923#issuecomment-2115684085

From kak at google.com  Thu May 16 16:49:59 2024
From: kak at google.com (Kurt Alfred Kluever)
Date: Thu, 16 May 2024 12:49:59 -0400
Subject: In support of Instant.minus(Instant)
In-Reply-To: <ad789d5c-395d-4675-8815-791fd498fae4@oracle.com>
References: <CAB3z6AiAvi2q12dB761fYTx8a6qV9syu6HGUq=vkR-dcYZyv=Q@mail.gmail.com>
 <CACzrW9CgGc=qNhmhyTNKponBSP1g37t1tNFkpeGj7oqGtn7ihA@mail.gmail.com>
 <81a8ee1c-807e-4a0b-8320-ff892fca76c0@oracle.com>
 <CAB3z6Aj9cev+JvCSGFRpOW6UEKmNQJsACzR-BnBxZpZP+3YJvg@mail.gmail.com>
 <CACzrW9AWCDYJdM7Y0rxpf8EeOohKLVnxwpKOa_KGWaVoZK2nvQ@mail.gmail.com>
 <CAGB9EW8fST6o4q7yqZxGO7OTkU52LYGSheHz+G0+R2OyA40uTQ@mail.gmail.com>
 <CAChqX892D+f+xkoFJ4E=FcdZbeSaEuYzy5Z0JVP7U0Rohg+uOA@mail.gmail.com>
 <0ac5b3f0-a35f-41cc-bd48-a10035233226@oracle.com>
 <156760df-b775-48a9-a20d-cc900d9df6e4@oracle.com>
 <ad789d5c-395d-4675-8815-791fd498fae4@oracle.com>
Message-ID: <CAB3z6Ajzp0XC=tgpahuF3URHq+n70pkxzHSS0xDN5t605DvxZw@mail.gmail.com>

Hi all,

Sorry for the delay here. I took a quick look at other popular date/time
libraries and there seems to be a fairly strong preference for minus
(JS/TS's Temporal library is the only other date/time library that I found
which uses until for this concept):


   -

   Abseil's Time (C++) overloads the - (minus) operator
   <https://github.com/abseil/abseil-cpp/blob/master/absl/time/time.h#L880-L882>
   to allow for end - start
   -

   NodaTime (.NET) defines
   <https://nodatime.org/3.1.x/api/NodaTime.Instant.html#NodaTime_Instant_Minus_NodaTime_Instant_>
   end.minus(start) (which also allows end - start)
   -

   Kotlinx.datetime defines
   <https://kotlinlang.org/api/kotlinx-datetime/kotlinx-datetime/kotlinx.datetime/-instant/>
   end.minus(start) (which also allows end - start)
   -

   Python's date/time API allows
   <https://docs.python.org/3/library/datetime.html#datetime.datetime> end
   - start
   -

   Temporal (JS/TS) defines
   <https://tc39.es/proposal-temporal/docs/instant.html#until>
   start.until(end)


The first 4 APIs support both instant - instant = duration and instant -
duration = instant ? I find this quite natural.

Additionally, "until" seems to imply it will return a positive duration.
This is fine if you're certain that "end" is after "start". However, it
becomes very confusing otherwise. E.g., if you ask: "how long from when you
were married until now?". If you were married 4 years ago, that makes
sense. But if your wedding is in 3 months, then the result is a negative
duration (which often cause confusion). If you ask the question the other
way around ("how long from now until your wedding day?"), that works if
your wedding is in the future, but not so much if you were married 4 years
ago (again, you'll get a negative duration).

Additionally, the word "until" seems to imply a range with defined
start/end points; e.g., "I'm out from Tuesday until next Thursday" ---
that's more of a Range<Instant> (or an Interval which java.time doesn't
have ? but of course JodaTime did), not just a span of time (a Duration).

Does that sway anybody's opinion?

Thanks,

-kak


On Mon, May 13, 2024 at 1:38?PM Naoto Sato <naoto.sato at oracle.com> wrote:

> Hi,
>
> With Stephen/Roger's comments, as well as Kevin's observation that
> until(end) has a good argument ordering that is easy to understand, I'd
> still propose `until()`. Please post if you have further comments.
>
> Naoto
>
> On 5/3/24 6:39 AM, Roger Riggs wrote:
> > Hi,
> >
> > I would also reinforce Stephen's early observation that the pattern for
> > "until" methods in java.time includes those of the XXXDate classes, with
> > a single Temporal parameter.  Period and Duration are similar values
> > holding relative TemporalAmounts.
> >
> >      public Period until(ChronoLocalDate endDateExclusive)
> >
> > In addition to Instant, the LocalTime class might also benefit from
> adding:
> >
> >      public Duration until(LocalTime endExclusive)`
> >
> > The API design of java.time included an emphasis on consistent naming
> > across the packages.
> >
> > Regards, Roger
> >
> >
> > On 5/2/24 4:01 PM, Naoto Sato wrote:
> >> `Temporal` interface is clear that its `minus` methods return objects
> >> of the same `Temporal` type, and `until` calculates the amount of time
> >> until another `Temporal` type. Introducing `Instant.minus` that
> >> returns `Duration` would be confusing to me.
> >>
> >> Naoto
> >>
> >> On 5/2/24 10:41 AM, ?amonn McManus wrote:
> >>> I'd say too that this makes intuitive sense based on algebra. If we
> >>> have:
> >>> /instant1/ + /duration/ = /instant2/
> >>> then we can subtract /duration/ from both sides:
> >>> /instant1 = instant2 - duration/
> >>> or we can subtract /instant1/ from both sides:
> >>> /duration = instant2 - instant1/
> >>>
> >>> There's no manipulation we can do that would cause us to try to add
> >>> instants together, and it's a bit surprising for the API to allow the
> >>> first subtraction but not the second.
> >>> I also think that if I see instant2.minus(instant1) it's immediately
> >>> obvious to me what that means, while instant1.until(instant2) seems
> >>> both less discoverable and less obvious.
> >>>
> >>> On Thu, 2 May 2024 at 10:29, Louis Wasserman <lowasser at google.com
> >>> <mailto:lowasser at google.com>> wrote:
> >>>
> >>>     That doesn't follow for me at all.
> >>>
> >>>     The structure formed by Instants and Durations is an affine space
> >>> <https://en.wikipedia.org/wiki/Affine_space#Definition>, with
> >>>     instants the points and durations the vectors.  (An affine space is
> >>>     a vector space without a distinguished origin, which of course
> >>>     Instants don't have.)  It is 100% standard to use the minus sign
> for
> >>>     the operation "point - point = vector," even when "point + point"
> is
> >>>     not defined, and to use all the other standard idioms for
> >>>     subtraction; the Wikipedia article uses "subtraction" and
> >>>     "difference" ubiquitously.
> >>>
> >>>     Personally, I'd be willing to live with a different name for the
> >>>     operation, but consider "users keep getting it wrong" a strong
> >>>     enough argument all by itself for a version with the swapped
> >>>     argument order; it's not obvious to me that another API with the
> >>>     same argument order adds enough value over Duration.between to
> >>>     bother with.
> >>>
> >>>     On Thu, May 2, 2024 at 10:04?AM Stephen Colebourne
> >>>     <scolebourne at joda.org <mailto:scolebourne at joda.org>> wrote:
> >>>
> >>>         On Thu, 2 May 2024 at 15:58, Kurt Alfred Kluever <
> kak at google.com
> >>> <mailto:kak at google.com>> wrote:
> >>>          > instant ? instant = duration // what we're discussing
> >>>          > instant + duration = instant // satisfied by
> >>>         instant.plus(duration)
> >>>          > instant - duration = instant // satisfied by
> >>>         instant.minus(duration)
> >>>          > duration + duration = duration // satisfied by
> >>>         duration.plus(duration)
> >>>          > duration - duration = duration // satisfied by
> >>>         duration.minus(duration)
> >>>          > duration ? real number = duration // satisfied by
> >>>         duration.multipliedBy(long)
> >>>          > duration ? real number = duration // satisfied by
> >>>         duration.dividedBy(long)
> >>>          >
> >>>          > All but the first operation have very clear translations
> from
> >>>         conceptual model to code. I'm hoping we can achieve the same
> >>>         clarity for instant - instant by using the obvious name:
> >>>         instant.minus(instant)
> >>>
> >>>         But you can't have
> >>>           instant + instant = ???
> >>>         It doesn't make sense.
> >>>
> >>>         This is at the heart of why minus isn't right in this case.
> >>>         Stephen
> >>>
> >>>
> >>>
> >>>     --     Louis Wasserman (he/they)
> >>>
> >
>


-- 
kak
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240516/50c788d4/attachment-0001.htm>

From iklam at openjdk.org  Thu May 16 17:44:22 2024
From: iklam at openjdk.org (Ioi Lam)
Date: Thu, 16 May 2024 17:44:22 GMT
Subject: RFR: 8332340: Add JavacBench as a test case for CDS [v2]
In-Reply-To: <xqD4PeVZfIAKzywbLnjGZMFh36YSqXNolZkTgh1Vk6E=.44db7c57-64c1-4912-96e1-e61848312ccb@github.com>
References: <xqD4PeVZfIAKzywbLnjGZMFh36YSqXNolZkTgh1Vk6E=.44db7c57-64c1-4912-96e1-e61848312ccb@github.com>
Message-ID: <kynGbPSKJOGvy0iND0ZEL42700j2gKku8A8IM1pAfwQ=.5dc84470-1b24-4568-8cd8-328221103e59@github.com>

> JavacBench is a test program that compiles 90 Java source files. It uses a fair amount of invokedynamic callsites, so it's good for testing CDS support for indy and lambda expressions.
> 
> This test was first integrated into the [leyden](https://github.com/openjdk/leyden/tree/premain) repo. Hence some of the files have copyrights in 2023.

Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:

  (1) comments from @liach; (2) added javadoc; (3) Use createTestJavaProcessBuilder() instead of createLimitedTestJavaProcessBuilder()

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19256/files
  - new: https://git.openjdk.org/jdk/pull/19256/files/10cf69d1..354665a3

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19256&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19256&range=00-01

  Stats: 38 lines in 2 files changed: 17 ins; 8 del; 13 mod
  Patch: https://git.openjdk.org/jdk/pull/19256.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19256/head:pull/19256

PR: https://git.openjdk.org/jdk/pull/19256

From iklam at openjdk.org  Thu May 16 17:44:22 2024
From: iklam at openjdk.org (Ioi Lam)
Date: Thu, 16 May 2024 17:44:22 GMT
Subject: RFR: 8332340: Add JavacBench as a test case for CDS [v2]
In-Reply-To: <Gt9UtQuINe4KgXoXvmJNxq8M_EMXTeQxd1kENvfO3Io=.26ac30de-513f-4ff6-974c-79a49f4f00a4@github.com>
References: <xqD4PeVZfIAKzywbLnjGZMFh36YSqXNolZkTgh1Vk6E=.44db7c57-64c1-4912-96e1-e61848312ccb@github.com>
 <Gt9UtQuINe4KgXoXvmJNxq8M_EMXTeQxd1kENvfO3Io=.26ac30de-513f-4ff6-974c-79a49f4f00a4@github.com>
Message-ID: <z3q9DUaqKx6u9BgwYrVX7RGjjH9iUykteF0nFNhMavo=.7c1edb0c-f5d8-472c-aae5-3059c8acb3d5@github.com>

On Thu, 16 May 2024 03:31:05 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   (1) comments from @liach; (2) added javadoc; (3) Use createTestJavaProcessBuilder() instead of createLimitedTestJavaProcessBuilder()
>
> test/lib/jdk/test/lib/StringArrayUtils.java line 42:
> 
>> 40:         }
>> 41: 
>> 42:         return list.toArray(new String[list.size()]);
> 
> I thought we have been preferring ot use `new String[0]` for toArray calls. Also for simplicity, we can change the implementation to:
> 
> var list = new ArrayList<>(Arrays.asList(prefix));
> Collections.addAll(list, extra);
> return list.toArray(new String[0]);
> 
> or for performance:
> 
> String[] ret = new String[prefix.length + extra.length];
> System.arraycopy(prefix, 0, ret, 0, prefix.length);
> System.arraycopy(extra, 0, ret, prefix.length, extra.length);
> return ret;

Thanks for the suggestion. I used your `arraycopy` version. I also added some javadocs about the intended use of these `concat()` methods.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19256#discussion_r1603781994

From alanb at openjdk.org  Thu May 16 18:43:06 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 16 May 2024 18:43:06 GMT
Subject: RFR: 8331671: Implement JEP 472: Prepare to Restrict the Use of
 JNI [v7]
In-Reply-To: <kAq153qNH4hG6IDWoTMrBv9pCPMEZl1pI7-wJQgsI7A=.6588b41b-eb33-49a6-a49d-cca79aaaf180@github.com>
References: <CZGbki5iFdCGPPagE-ya-_L8Nkgf7OunywApOsxC548=.2cee82fa-a5d2-4165-b012-30982a85030a@github.com>
 <kAq153qNH4hG6IDWoTMrBv9pCPMEZl1pI7-wJQgsI7A=.6588b41b-eb33-49a6-a49d-cca79aaaf180@github.com>
Message-ID: <TLlZCZnwecI8yT_xAKpqXFPZss7e0kUgozRZRlKYhFo=.4ed29ae7-0f90-4312-9dc7-b23104ad70f5@github.com>

On Thu, 16 May 2024 12:23:44 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This PR implements [JEP 472](https://openjdk.org/jeps/472), by restricting the use of JNI in the following ways:
>> 
>> * `System::load` and `System::loadLibrary` are now restricted methods
>> * `Runtime::load` and `Runtime::loadLibrary` are now restricted methods
>> * binding a JNI `native` method declaration to a native implementation is now considered a restricted operation
>> 
>> This PR slightly changes the way in which the JDK deals with restricted methods, even for FFM API calls. In Java 22, the single `--enable-native-access` was used both to specify a set of modules for which native access should be allowed *and* to specify whether illegal native access (that is, native access occurring from a module not specified by `--enable-native-access`) should be treated as an error or a warning. More specifically, an error is only issued if the `--enable-native-access flag` is used at least once.
>> 
>> Here, a new flag is introduced, namely `illegal-native-access=allow/warn/deny`, which is used to specify what should happen when access to a restricted method and/or functionality is found outside the set of modules specified with `--enable-native-access`. The default policy is `warn`, but users can select `allow` to suppress the warnings, or `deny` to cause `IllegalCallerException` to be thrown. This aligns the treatment of restricted methods with other mechanisms, such as `--illegal-access` and the more recent `--sun-misc-unsafe-memory-access`.
>> 
>> Some changes were required in the package-info javadoc for `java.lang.foreign`, to reflect the changes in the command line flags described above.
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add note on --illegal-native-access default value in the launcher help

src/java.base/share/classes/java/lang/System.java line 2023:

> 2021:      * @throws     NullPointerException if {@code filename} is {@code null}
> 2022:      * @throws     IllegalCallerException If the caller is in a module that
> 2023:      *             does not have native access enabled.

The exception description is fine, just noticed the other exception descriptions start with a lowercase "if", this one is different.

src/java.base/share/man/java.1 line 587:

> 585: \f[V]deny\f[R]: This mode disables all illegal native access except for
> 586: those modules enabled by the \f[V]--enable-native-access\f[R]
> 587: command-line option.

"This mode disable all illegal native access except for those modules enabled the --enable-native-access command-line option". 

This can be read to mean that modules granted native access with the command line option is also illegal native access An alternative is to make the second part of the sentence a new sentence, something like "Only modules enabled by the --enable-native-access command line option may perform native access.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19213#discussion_r1603878829
PR Review Comment: https://git.openjdk.org/jdk/pull/19213#discussion_r1603875920

From joehw at openjdk.org  Thu May 16 18:53:40 2024
From: joehw at openjdk.org (Joe Wang)
Date: Thu, 16 May 2024 18:53:40 GMT
Subject: RFR: 8330542: Add jaxp-strict.properties in preparation for a
 secure by default configuration [v7]
In-Reply-To: <v1bAYKgH9zfooXpvnBw4Vu2TIqHuKqqtSmgB0hiNp-Q=.31661a99-ecfc-4a05-8045-67b5f680db60@github.com>
References: <v1bAYKgH9zfooXpvnBw4Vu2TIqHuKqqtSmgB0hiNp-Q=.31661a99-ecfc-4a05-8045-67b5f680db60@github.com>
Message-ID: <J19DcssTmKojtk5iiYQu2p2NFOIb6WnIzZQECw6cRrA=.64b3fe47-704e-44da-afa5-9e362a0b09f1@github.com>

> Add two sample configuration files:
> 
>   jaxp-strict.properties: used to set strict configuration, stricter than jaxp.properties in previous versions such as JDK 22
> 
>   jaxp-compat.properties: used to regain compatibility from any more restricted configuration than previous versions such as JDK 22

Joe Wang has updated the pull request incrementally with one additional commit since the last revision:

  The JDK provides two configuration files instead of three. Updated jaxp-strict.properties to reflect the change. Removed jaxp-compat. Updated jaxp.properties with properties the same as in jaxp-strict, setting to default values.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/18831/files
  - new: https://git.openjdk.org/jdk/pull/18831/files/af351a4d..f3af4ae9

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18831&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18831&range=05-06

  Stats: 191 lines in 6 files changed: 8 ins; 157 del; 26 mod
  Patch: https://git.openjdk.org/jdk/pull/18831.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18831/head:pull/18831

PR: https://git.openjdk.org/jdk/pull/18831

From lancea at openjdk.org  Thu May 16 19:09:03 2024
From: lancea at openjdk.org (Lance Andersen)
Date: Thu, 16 May 2024 19:09:03 GMT
Subject: RFR: 8330542: Add jaxp-strict.properties in preparation for a
 secure by default configuration [v7]
In-Reply-To: <J19DcssTmKojtk5iiYQu2p2NFOIb6WnIzZQECw6cRrA=.64b3fe47-704e-44da-afa5-9e362a0b09f1@github.com>
References: <v1bAYKgH9zfooXpvnBw4Vu2TIqHuKqqtSmgB0hiNp-Q=.31661a99-ecfc-4a05-8045-67b5f680db60@github.com>
 <J19DcssTmKojtk5iiYQu2p2NFOIb6WnIzZQECw6cRrA=.64b3fe47-704e-44da-afa5-9e362a0b09f1@github.com>
Message-ID: <IQGJ3TTe14grLJUubzotOsPy7Puiy3JKHK1Yll7UD2M=.ffb31af2-8467-4970-b307-b31678e0b6ec@github.com>

On Thu, 16 May 2024 18:53:40 GMT, Joe Wang <joehw at openjdk.org> wrote:

>> Add two sample configuration files:
>> 
>>   jaxp-strict.properties: used to set strict configuration, stricter than jaxp.properties in previous versions such as JDK 22
>> 
>>>   jaxp-compat.properties: used to regain compatibility from any more restricted configuration than previous versions such as JDK 22
>> 
>> Updated 5/16/2024
>> 
>> Design change:
>> The design is changed to include in the JDK two configuration files that are the default jaxp.properties and jaxp-strict.properties, instead of three, dropping jaxp-compat.properties.
>
> Joe Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   The JDK provides two configuration files instead of three. Updated jaxp-strict.properties to reflect the change. Removed jaxp-compat. Updated jaxp.properties with properties the same as in jaxp-strict, setting to default values.

src/java.xml/share/classes/module-info.java line 409:

> 407:  *      <li><a href="#IN_CF_DEFAULT">{@code jaxp.properties}</a></li>
> 408:  *      <li><a href="#IN_CF_STRICT">{@code jaxp-strict.properties}</a></li>
> 409:  *      <li><a href="#IN_CF_COMPAT">{@code jaxp-compat.properties}</a></li>

This line should be removed

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18831#discussion_r1603907393

From scolebourne at joda.org  Thu May 16 20:14:29 2024
From: scolebourne at joda.org (Stephen Colebourne)
Date: Thu, 16 May 2024 21:14:29 +0100
Subject: In support of Instant.minus(Instant)
In-Reply-To: <CAB3z6Ajzp0XC=tgpahuF3URHq+n70pkxzHSS0xDN5t605DvxZw@mail.gmail.com>
References: <CAB3z6AiAvi2q12dB761fYTx8a6qV9syu6HGUq=vkR-dcYZyv=Q@mail.gmail.com>
 <CACzrW9CgGc=qNhmhyTNKponBSP1g37t1tNFkpeGj7oqGtn7ihA@mail.gmail.com>
 <81a8ee1c-807e-4a0b-8320-ff892fca76c0@oracle.com>
 <CAB3z6Aj9cev+JvCSGFRpOW6UEKmNQJsACzR-BnBxZpZP+3YJvg@mail.gmail.com>
 <CACzrW9AWCDYJdM7Y0rxpf8EeOohKLVnxwpKOa_KGWaVoZK2nvQ@mail.gmail.com>
 <CAGB9EW8fST6o4q7yqZxGO7OTkU52LYGSheHz+G0+R2OyA40uTQ@mail.gmail.com>
 <CAChqX892D+f+xkoFJ4E=FcdZbeSaEuYzy5Z0JVP7U0Rohg+uOA@mail.gmail.com>
 <0ac5b3f0-a35f-41cc-bd48-a10035233226@oracle.com>
 <156760df-b775-48a9-a20d-cc900d9df6e4@oracle.com>
 <ad789d5c-395d-4675-8815-791fd498fae4@oracle.com>
 <CAB3z6Ajzp0XC=tgpahuF3URHq+n70pkxzHSS0xDN5t605DvxZw@mail.gmail.com>
Message-ID: <CACzrW9ASCnBmDQrGV66RBftGhfwB0UuRpYgjmuTHqa_eiN2PXA@mail.gmail.com>

I remain happy to see until() go into the JDK. Potentially on more
classes than the recent PR.

*If* Java gets operator overloading, and *if* it is based on a mapping
to method names, then *perhaps* there is a case to consider adding
minus(). But I don't feel now is the time.

Stephen


On Thu, 16 May 2024 at 17:50, Kurt Alfred Kluever <kak at google.com> wrote:
>
> Hi all,
>
>
> Sorry for the delay here. I took a quick look at other popular date/time libraries and there seems to be a fairly strong preference for minus (JS/TS's Temporal library is the only other date/time library that I found which uses until for this concept):
>
>
> Abseil's Time (C++) overloads the - (minus) operator to allow for end - start
>
> NodaTime (.NET) defines end.minus(start) (which also allows end - start)
>
> Kotlinx.datetime defines end.minus(start) (which also allows end - start)
>
> Python's date/time API allows end - start
>
> Temporal (JS/TS) defines start.until(end)
>
>
> The first 4 APIs support both instant - instant = duration and instant - duration = instant ? I find this quite natural.
>
>
> Additionally, "until" seems to imply it will return a positive duration. This is fine if you're certain that "end" is after "start". However, it becomes very confusing otherwise. E.g., if you ask: "how long from when you were married until now?". If you were married 4 years ago, that makes sense. But if your wedding is in 3 months, then the result is a negative duration (which often cause confusion). If you ask the question the other way around ("how long from now until your wedding day?"), that works if your wedding is in the future, but not so much if you were married 4 years ago (again, you'll get a negative duration).
>
>
> Additionally, the word "until" seems to imply a range with defined start/end points; e.g., "I'm out from Tuesday until next Thursday" --- that's more of a Range<Instant> (or an Interval which java.time doesn't have ? but of course JodaTime did), not just a span of time (a Duration).
>
>
> Does that sway anybody's opinion?
>
>
> Thanks,
>
> -kak
>
>
>
> On Mon, May 13, 2024 at 1:38?PM Naoto Sato <naoto.sato at oracle.com> wrote:
>>
>> Hi,
>>
>> With Stephen/Roger's comments, as well as Kevin's observation that
>> until(end) has a good argument ordering that is easy to understand, I'd
>> still propose `until()`. Please post if you have further comments.
>>
>> Naoto
>>
>> On 5/3/24 6:39 AM, Roger Riggs wrote:
>> > Hi,
>> >
>> > I would also reinforce Stephen's early observation that the pattern for
>> > "until" methods in java.time includes those of the XXXDate classes, with
>> > a single Temporal parameter.  Period and Duration are similar values
>> > holding relative TemporalAmounts.
>> >
>> >      public Period until(ChronoLocalDate endDateExclusive)
>> >
>> > In addition to Instant, the LocalTime class might also benefit from adding:
>> >
>> >      public Duration until(LocalTime endExclusive)`
>> >
>> > The API design of java.time included an emphasis on consistent naming
>> > across the packages.
>> >
>> > Regards, Roger
>> >
>> >
>> > On 5/2/24 4:01 PM, Naoto Sato wrote:
>> >> `Temporal` interface is clear that its `minus` methods return objects
>> >> of the same `Temporal` type, and `until` calculates the amount of time
>> >> until another `Temporal` type. Introducing `Instant.minus` that
>> >> returns `Duration` would be confusing to me.
>> >>
>> >> Naoto
>> >>
>> >> On 5/2/24 10:41 AM, ?amonn McManus wrote:
>> >>> I'd say too that this makes intuitive sense based on algebra. If we
>> >>> have:
>> >>> /instant1/ + /duration/ = /instant2/
>> >>> then we can subtract /duration/ from both sides:
>> >>> /instant1 = instant2 - duration/
>> >>> or we can subtract /instant1/ from both sides:
>> >>> /duration = instant2 - instant1/
>> >>>
>> >>> There's no manipulation we can do that would cause us to try to add
>> >>> instants together, and it's a bit surprising for the API to allow the
>> >>> first subtraction but not the second.
>> >>> I also think that if I see instant2.minus(instant1) it's immediately
>> >>> obvious to me what that means, while instant1.until(instant2) seems
>> >>> both less discoverable and less obvious.
>> >>>
>> >>> On Thu, 2 May 2024 at 10:29, Louis Wasserman <lowasser at google.com
>> >>> <mailto:lowasser at google.com>> wrote:
>> >>>
>> >>>     That doesn't follow for me at all.
>> >>>
>> >>>     The structure formed by Instants and Durations is an affine space
>> >>> <https://en.wikipedia.org/wiki/Affine_space#Definition>, with
>> >>>     instants the points and durations the vectors.  (An affine space is
>> >>>     a vector space without a distinguished origin, which of course
>> >>>     Instants don't have.)  It is 100% standard to use the minus sign for
>> >>>     the operation "point - point = vector," even when "point + point" is
>> >>>     not defined, and to use all the other standard idioms for
>> >>>     subtraction; the Wikipedia article uses "subtraction" and
>> >>>     "difference" ubiquitously.
>> >>>
>> >>>     Personally, I'd be willing to live with a different name for the
>> >>>     operation, but consider "users keep getting it wrong" a strong
>> >>>     enough argument all by itself for a version with the swapped
>> >>>     argument order; it's not obvious to me that another API with the
>> >>>     same argument order adds enough value over Duration.between to
>> >>>     bother with.
>> >>>
>> >>>     On Thu, May 2, 2024 at 10:04?AM Stephen Colebourne
>> >>>     <scolebourne at joda.org <mailto:scolebourne at joda.org>> wrote:
>> >>>
>> >>>         On Thu, 2 May 2024 at 15:58, Kurt Alfred Kluever <kak at google.com
>> >>> <mailto:kak at google.com>> wrote:
>> >>>          > instant ? instant = duration // what we're discussing
>> >>>          > instant + duration = instant // satisfied by
>> >>>         instant.plus(duration)
>> >>>          > instant - duration = instant // satisfied by
>> >>>         instant.minus(duration)
>> >>>          > duration + duration = duration // satisfied by
>> >>>         duration.plus(duration)
>> >>>          > duration - duration = duration // satisfied by
>> >>>         duration.minus(duration)
>> >>>          > duration ? real number = duration // satisfied by
>> >>>         duration.multipliedBy(long)
>> >>>          > duration ? real number = duration // satisfied by
>> >>>         duration.dividedBy(long)
>> >>>          >
>> >>>          > All but the first operation have very clear translations from
>> >>>         conceptual model to code. I'm hoping we can achieve the same
>> >>>         clarity for instant - instant by using the obvious name:
>> >>>         instant.minus(instant)
>> >>>
>> >>>         But you can't have
>> >>>           instant + instant = ???
>> >>>         It doesn't make sense.
>> >>>
>> >>>         This is at the heart of why minus isn't right in this case.
>> >>>         Stephen
>> >>>
>> >>>
>> >>>
>> >>>     --     Louis Wasserman (he/they)
>> >>>
>> >
>
>
>
> --
> kak

From sgibbons at openjdk.org  Thu May 16 20:57:12 2024
From: sgibbons at openjdk.org (Scott Gibbons)
Date: Thu, 16 May 2024 20:57:12 GMT
Subject: RFR: 8320448: Accelerate IndexOf using AVX2 [v19]
In-Reply-To: <kQqTVjddCtPg3veW8bu_W1ae-xYxXxdhIj9-wkpax6c=.f2b341b9-794a-4355-a2a0-e481e3691eb8@github.com>
References: <uWi4QxH31hL93771gkl_GgvP0m84IRSoR_1Yi8hD17E=.bc6ed458-7081-4c3f-9348-f59358fa05a4@github.com>
 <eQ4OBFrF8JlDJ1h9awTDOc0kfCc37IlL5vdqtuaqls0=.8f00616d-08e1-4f28-a7a5-5095116d2595@github.com>
 <kQqTVjddCtPg3veW8bu_W1ae-xYxXxdhIj9-wkpax6c=.f2b341b9-794a-4355-a2a0-e481e3691eb8@github.com>
Message-ID: <LYBvgiOqxSslp4N8r6315DpfX3El5owxCdHSmp68uH4=.bab40dd5-13a9-4339-bb66-037ed96c5a6d@github.com>

On Tue, 7 May 2024 17:25:04 GMT, Volodymyr Paprotski <duke at openjdk.org> wrote:

>> Scott Gibbons has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Rearrange; add lambdas for clarity
>
> src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 4492:
> 
>> 4490: 
>> 4491: // Compare char[] or byte[] arrays aligned to 4 bytes or substrings.
>> 4492: void C2_MacroAssembler::arrays_equals(bool is_array_equ, Register ary1,
> 
> I liked the old style better, fewer longer lines.. same for rest of the changes in this file.

Done.

> src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 4594:
> 
>> 4592: #endif //_LP64
>> 4593:     bind(COMPARE_WIDE_VECTORS);
>> 4594:     vmovdqu(vec1, Address(ary1, limit,
> 
> create a local scale variable instead of ternary operators. Used several times.

Done

> src/hotspot/cpu/x86/stubGenerator_x86_64.cpp line 4250:
> 
>> 4248:   generate_chacha_stubs();
>> 4249: 
>> 4250:   if ((UseAVX == 2) && EnableX86ECoreOpts && VM_Version::supports_avx2()) {
> 
> Just `if (EnableX86ECoreOpts)`?

I think all 3 should be specified, even if `EnableX86ECoreOpts` checks.  This is for clarity of intent.

> src/hotspot/cpu/x86/stubGenerator_x86_64_string.cpp line 391:
> 
>> 389:       }
>> 390: 
>> 391:       __ cmpq(needle_len, isU ? 2 : 1);
> 
> Can we remove this comparison? i.e.
> - broadcast first and last character unconditionally (same character). Or
> - move broadcasts 'down' into individual cases..
> There is already specialized code to handle needle of size 1.. This adds extra pathlength. (Will we actually call this intrinsic for needle_size==1? Assume length>=2?)

At this point in the code it is entirely possible for needle size to be == 1, but only in the case where haystack size is > 32 bytes.  Moving the broadcasts 'down' into individual cases increases code size by 14 broadcast instructions.

Seems like the best option is to just remove the compare and branch, broadcasting the first needle element twice.

> src/hotspot/cpu/x86/stubGenerator_x86_64_string.cpp line 1365:
> 
>> 1363:   // Compare first byte of needle to haystack
>> 1364:      vpcmpeq(cmp_0, byte_0, Address(haystack, 0), Assembler::AVX_256bit);
>> 1365:   if (size != (isU ? 2 : 1)) {
> 
> `if (size != scale)`
> 
> Though in this case, `elem_size` might hold more meaning.

Done

> src/hotspot/cpu/x86/stubGenerator_x86_64_string.cpp line 1372:
> 
>> 1370: 
>> 1371:     if (bytesToCompare > 2) {
>> 1372:       if (size > (isU ? 4 : 2)) {
> 
> `if (size > 2*scale)`?

Done

> src/hotspot/cpu/x86/stubGenerator_x86_64_string.cpp line 1373:
> 
>> 1371:     if (bytesToCompare > 2) {
>> 1372:       if (size > (isU ? 4 : 2)) {
>> 1373:         if (doEarlyBailout) {
> 
> Is there a big perf difference when `doEarlyBailout` is enabled? And/or just for this function?
> 
> (i.e. removing `doEarlyBailout` in this function will mean less pathlength. Feels like a few extra vpands should be cheap enough.)

I removed the macro DO_EARLY_BAILOUT and assumed it to be true.  There's not much difference (if any) in performance, so we maybe ought to consider not bailing out early.  I'll consider not bailing out and let you know how performance is impacted.

> src/hotspot/cpu/x86/stubGenerator_x86_64_string.cpp line 1469:
> 
>> 1467: 
>> 1468:   if (isU && (size & 1)) {
>> 1469:     __ emit_int8(0xcc);
> 
> This should also be an `assert()` to catch this at compile-time.

Although assert is technically runtime (;-)) I'll change these.  They were put in to double-check while debugging.

> src/hotspot/cpu/x86/stubGenerator_x86_64_string.cpp line 1633:
> 
>> 1631:   if (isU) {
>> 1632:     if ((size & 1) != 0) {
>> 1633:       __ emit_int8(0xcc);
> 
> Compile-time assert to ensure this code is never called instead?

Done

> src/hotspot/cpu/x86/stubGenerator_x86_64_string.cpp line 1889:
> 
>> 1887:     //  r13 = (needle length - 1)
>> 1888:     //  r14 = &needle
>> 1889:     //  r15 = unused
> 
> There is quite a bit of redundancy in register usage. Its not incorrect, but looks odd. Not clear if this duplication can easily be removed (or if/why needed). 
> 
>     //  rbx = &haystack
>     //  rdi = &haystack
>     //  rdx = &needle
>     //  r14 = &needle
>     //  rcx = haystack length
>     //  rsi = haystack length
>     //  r12 = needle length
>     //  r13 = (needle length - 1)
>     //  r10 = hs_len - needle len
>     //  rbp = -1
>     
>     //  rax = unused
>     //  r11 = unused
>     //  r8  = unused
>     //  r9  = unused
>     //  r15 = unused
> 
> 
> (Could this comment be out-of-sync with the code? Looks like only rbx, r14 and temps out of unused registers are used few lines down)

This comment provides the full register state upon entry to each of the cases of the switch.  The duplication is an artifact of the decisions made in setup code (like checking ranges, etc.).  Each case can depend on the values of the registers to be as documented on entry.  It can use either rcx or rsi to get the haystack length, for example.

> src/hotspot/cpu/x86/stubGenerator_x86_64_string.cpp line 1950:
> 
>> 1948:     //  r13 = (needle length - 1)
>> 1949:     //  r14 = &needle
>> 1950:     //  r15 = unused
> 
> Same as for the small case

Yes, same as for the small case.

> test/micro/org/openjdk/bench/java/lang/StringIndexOfHuge.java line 2:
> 
>> 1: /*
>> 2:  * Copyright (c) 2014, 2024, Oracle and/or its affiliates. All rights reserved.
> 
> New file, just 2024

Done

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1603734868
PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1603735274
PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1603737342
PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1603806354
PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1603953047
PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1603985462
PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1603955117
PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1603956554
PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1603989550
PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1604006660
PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1604006994
PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1604024770

From sgibbons at openjdk.org  Thu May 16 20:57:20 2024
From: sgibbons at openjdk.org (Scott Gibbons)
Date: Thu, 16 May 2024 20:57:20 GMT
Subject: RFR: 8320448: Accelerate IndexOf using AVX2 [v19]
In-Reply-To: <8Y-nIHc8vfB1X_hp3tpqqqgpCzu6dAt6BBIP_zc4Q70=.c9a48c68-8c14-4af9-8357-ab50e62a5fd3@github.com>
References: <uWi4QxH31hL93771gkl_GgvP0m84IRSoR_1Yi8hD17E=.bc6ed458-7081-4c3f-9348-f59358fa05a4@github.com>
 <eQ4OBFrF8JlDJ1h9awTDOc0kfCc37IlL5vdqtuaqls0=.8f00616d-08e1-4f28-a7a5-5095116d2595@github.com>
 <8Y-nIHc8vfB1X_hp3tpqqqgpCzu6dAt6BBIP_zc4Q70=.c9a48c68-8c14-4af9-8357-ab50e62a5fd3@github.com>
Message-ID: <qqhUK6_L8rqutc-MtL_BzjZbBy88a-TDws9NuLIWC9g=.d97368e7-4b28-439d-959e-fee2ec13d2c9@github.com>

On Mon, 6 May 2024 20:56:36 GMT, Sandhya Viswanathan <sviswanathan at openjdk.org> wrote:

>> Scott Gibbons has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Rearrange; add lambdas for clarity
>
> src/hotspot/cpu/x86/macroAssembler_x86.cpp line 1174:
> 
>> 1172: // Alignment specifying the maximum number of allowed bytes to pad.
>> 1173: // If padding > max, no padding is inserted.
>> 1174: void MacroAssembler::p2align(int modulus, int maxbytes) {
> 
> We could pass offset() as an argument to p2align. Basically have three arguments to p2align(modulus, target, maxbytes). Also maybe rename p2align as align then?

Removed p2align().  Was never used and was a remnant of prior implementation attempt.

> src/hotspot/cpu/x86/stubGenerator_x86_64_string.cpp line 208:
> 
>> 206:   ////////////////////////////////////////////////////////////////////////////////////////
>> 207:   ////////////////////////////////////////////////////////////////////////////////////////
>> 208:   if (VM_Version::supports_avx2()) {  // AVX2 version
> 
> Instead of the if check here, it would be better to do an assert here:
> assert (VM_Version::supports_avx2(), "Needs AVX2 support");

Done

> src/hotspot/cpu/x86/stubGenerator_x86_64_string.cpp line 238:
> 
>> 236:     const Register needle       = rdx;
>> 237:     const Register needle_len   = rcx;
>> 238: 
> 
> This is the calling convention on Linux. How is windows platform handled?

The entry code switches Windows calling convention into Linux calling convention by moving/saving registers, which are properly restored on function exit.  This makes register tracking easier.

> src/hotspot/cpu/x86/stubGenerator_x86_64_string.cpp line 260:
> 
>> 258:     // const XMMRegister save_rcx  = xmm11;
>> 259:     // const XMMRegister save_r8   = xmm12;
>> 260: 
> 
> This could be removed?

Done

> src/hotspot/cpu/x86/stubGenerator_x86_64_string.cpp line 279:
> 
>> 277:     fnptrs[isLL   ? StrIntrinsicNode::LL
>> 278:            : isUU ? StrIntrinsicNode::UU
>> 279:                   : StrIntrinsicNode::UL] = __ pc();
> 
> Could this not be simplified as:
>  fnptrs[ae] = __ pc();

Done

> src/hotspot/cpu/x86/stubGenerator_x86_64_string.cpp line 314:
> 
>> 312: 
>> 313:     // needle_len is in elements, not bytes, for UTF-16
>> 314:     __ cmpq(needle_len, isUU ? OPT_NEEDLE_SIZE_MAX / 2 : OPT_NEEDLE_SIZE_MAX);
> 
> OPT_NEEDLE_SIZE_MAX is an odd number (set to 5), should that have been an even number?

Removed OPT_NEEDLE_SIZE_MAX and replaced with constant == 6.

> src/hotspot/cpu/x86/stubGenerator_x86_64_string.cpp line 383:
> 
>> 381:     {
>> 382:       Label L_short;
>> 383: 
> 
> A comment here:
> // Broadcast the beginning of needle into a vector register.

Done

> src/hotspot/cpu/x86/stubGenerator_x86_64_string.cpp line 390:
> 
>> 388:         __ vpbroadcastb(byte_0, Address(needle, 0), Assembler::AVX_256bit);
>> 389:       }
>> 390: 
> 
> A comment here:
> // Broadcast the end of needle into a vector register. This step is not needed for single element needle.

Done

> src/hotspot/cpu/x86/stubGenerator_x86_64_string.cpp line 418:
> 
>> 416:       __ cmpq(haystack_len, 0x10);
>> 417:       __ ja_b(L_moreThan16);
>> 418: 
> 
> An assert here to check for header size >= 16 would be good. 
> Also a comment here would he good, something like: 
> // Copy 16 or 32 bytes prior to haystack end onto stack 
> // This will possibly including some object header bytes when haystack length is less than 16 or 32 bytes // Set the new haystack address to beginning of copied haystack on stack adjusting for extra bytes copied

I don't know how to assert header size >= 16 bytes, so I'll add a comment stating such.  If you can tell me how to assert, I'll add that code in place of the comment.

> src/hotspot/cpu/x86/stubGenerator_x86_64_string.cpp line 498:
> 
>> 496: 
>> 497:       // big_case_loop_helper will fall through to this point if one or more potential matches are found
>> 498:       // The mask will have a bitmask indicating the position of the potential matches within the haystack
> 
> If no potential match, which label does the big_case_loop_helper jump to?

Added comment

> src/hotspot/cpu/x86/stubGenerator_x86_64_string.cpp line 517:
> 
>> 515:       __C2 arrays_equals(false, haystackStart, firstNeedleCompare, compLen, retval, rScratch, xmm_tmp3, xmm_tmp4,
>> 516:                          false /* char */, knoreg);
>> 517:       __ testl(retval, retval);
> 
> Since this is byte compare even for isU, the retval here could be a 64-bit quantity so the testl should be a testq.

`arrays_equals` returns a boolean value of `0` for not found and `1` for found using `movl(result, 0/1)` so testl is appropriate here.

> src/hotspot/cpu/x86/stubGenerator_x86_64_string.cpp line 553:
> 
>> 551:     //  Haystack always copied to stack, so 32-byte reads OK
>> 552:     //  Haystack length < 32
>> 553:     //  10 < needle length < 32
> 
> The comment below may need update as we come here for needle_len > OPT_NEEDLE_SIZE_MAX which is currently set as 5:
> // 10 < needle length < 32

No.  The jump is based on NUMBER_OF_CASES which is == 10.  See line 147.

> src/hotspot/cpu/x86/stubGenerator_x86_64_string.cpp line 576:
> 
>> 574:       broadcast_additional_needles(false, 0 /* unknown */, NUMBER_OF_NEEDLE_BYTES_TO_COMPARE, needle, needleLen, rTmp3,
>> 575:                                    isUU, isUL, _masm);
>> 576: 
> 
> Good to pass output xmm registers to this method.

Done

> src/hotspot/cpu/x86/stubGenerator_x86_64_string.cpp line 587:
> 
>> 585:       //  firstNeedleCompare has address of second element of needle
>> 586:       //  compLen has length of comparison to do
>> 587: 
> 
> This is not clear. firstNeedleCompare gets needle + NUMBER_OF_NEEDLE_BYTES_TO_COMPARE - 1 which is not necessarily the second element of needle. If it helps let us fix the NUMBER_OF_NEEDLE_BYTES_TO_COMPARE to 3 and have comments and code versus that only.

Replaced NUMBER_OF_NEEDLE_BYTES_TO_COMPARE with constant `3`

> src/hotspot/cpu/x86/stubGenerator_x86_64_string.cpp line 611:
> 
>> 609:       __C2 arrays_equals(false, rTmp, firstNeedleCompare, compLen, rTmp3, rTmp2, xmm_tmp3, xmm_tmp4, false /* char */,
>> 610:                          knoreg);
>> 611:       __ testl(rTmp3, rTmp3);
> 
> Since this is byte compare even for isU, the rtmp3  here could be a 64-bit quantity so the testl should be a testq.

`arrays_equals` returns boolean via `movl(retval, 0/1)` so testl is appropriate here.

> src/hotspot/cpu/x86/stubGenerator_x86_64_string.cpp line 629:
> 
>> 627: 
>> 628:     __ bind(L_returnError);
>> 629:     __ movq(rbp, -1);
> 
> This could directly be rax instead of intermediate rbp and then moving from rbp to rax.

Done

> src/hotspot/cpu/x86/stubGenerator_x86_64_string.cpp line 633:
> 
>> 631: 
>> 632:     __ bind(L_returnZero);
>> 633:     __ xorl(rbp, rbp);
> 
> This could directly be rax instead of intermediate rbp and then moving from rbp to rax.

Removed block - never jumped to.

> src/hotspot/cpu/x86/stubGenerator_x86_64_string.cpp line 639:
> 
>> 637:     __ movl(rax, r8);
>> 638:     __ subq(rcx, rbx);
>> 639:     __ addq(rcx, rax);
> 
> This could be:
>     __ subq(rcx, rbx);
>     __ addq(rcx, r8);

Done

> src/hotspot/cpu/x86/stubGenerator_x86_64_string.cpp line 647:
> 
>> 645:     __ cmpq(r11, r10);
>> 646:     __ movq(rbp, -1);
>> 647:     __ cmovq(Assembler::belowEqual, rbp, r11);
> 
> This could be directly computed in rax:
>     __ movq(rax, -1);
>     __ cmovq(Assembler::belowEqual, rax, r11);
> Also is it possible to not do cmov on some paths? It is an expensive operation.

OK

> src/hotspot/cpu/x86/stubGenerator_x86_64_string.cpp line 1010:
> 
>> 1008: static void broadcast_additional_needles(bool sizeKnown, int size, int bytesToCompare, Register needle,
>> 1009:                                          Register needleLen, Register rTmp, bool isUU, bool isUL,
>> 1010:                                          MacroAssembler *_masm) {
> 
> Good to add output XMM registers to the parameter list.

Done

> src/hotspot/cpu/x86/stubGenerator_x86_64_string.cpp line 1040:
> 
>> 1038:         __ vpbroadcastb(byte_1, Address(needle, 1), Assembler::AVX_256bit);
>> 1039:       }
>> 1040:     }
> 
> It will be good to have a function which broadcasts a needle element from a given offset into a vector register.
> That function could take (needle address, offset, outout vector register, temps).
> Such a function could then be called twice from here and from main function for offset 0.

No longer relevant - always comparing 3 needle bytes only, so the second broadcast is gone.

> src/hotspot/cpu/x86/stubGenerator_x86_64_string.cpp line 1054:
> 
>> 1052:         } else if (isUL) {
>> 1053:           __ movzbl(rTmp, Address(needle, 2));
>> 1054:           __ movdl(byte_1, rTmp);
> 
> Should be: __ movdl(byte_2, rTmp);

Removed byte_2 - always comparing 3 bytes.

> src/hotspot/cpu/x86/stubGenerator_x86_64_string.cpp line 1056:
> 
>> 1054:           __ movdl(byte_1, rTmp);
>> 1055:           // 1st byte of needle in words
>> 1056:           __ vpbroadcastw(byte_1, byte_1, Assembler::AVX_256bit);
> 
> Should be:
> __ vpbroadcastw(byte_2, byte_2, Assembler::AVX_256bit);

Removed byte_2 - always comparing 3 bytes.

> src/hotspot/cpu/x86/stubGenerator_x86_64_string.cpp line 1082:
> 
>> 1080: // noMatch - label bound outside to jump to if there is no match
>> 1081: // haystack - the address of the first byte of the haystack
>> 1082: // hsLen - the sizeof the haystack
> 
> Good to specify if the size  (size of needle) and hsLen (size of haystack) is in bytes or elements.

In bytes.  added

> src/hotspot/cpu/x86/stubGenerator_x86_64_string.cpp line 1083:
> 
>> 1081: // haystack - the address of the first byte of the haystack
>> 1082: // hsLen - the sizeof the haystack
>> 1083: // isU - true if argument encoding is either UU or UL
> 
> We need to list needleLen here as well?

Done

> src/hotspot/cpu/x86/stubGenerator_x86_64_string.cpp line 1096:
> 
>> 1094:                                            MacroAssembler *_masm) {
>> 1095: 
>> 1096:   assert_different_registers(eq_mask, haystack, needleLen, rTmp, hsLen, r10);
> 
> r10 kind of stands out here. You could say nMinusK in this assert.
> The assert following to this one is checking for nMinusK==r10 so that should suffice.
> BTW, didn't see anything in the code below that needs nMinuxK to be r10.

r10 holds the value `(n - k)` always, which is used to ensure the returned index is not past the end of the haystack.

I will annotate this register as global in comments.  I also reserve xmm0, xmm1, and xmm12 to hold the broadcasted needle bytes globally.  I'll try to make this as obvious as possible.

> src/hotspot/cpu/x86/stubGenerator_x86_64_string.cpp line 1120:
> 
>> 1118: #define cmp_0 XMM_TMP3
>> 1119: #undef cmp_k
>> 1120: #define cmp_k XMM_TMP4
> 
> XMM_TMP4 is not reused so cmp_k could be declared as const. In general limiting undef/define pair only to reused registers would make the review easier.

OK.  I'll handle this as a last pass over the code for register allocation.

> src/hotspot/cpu/x86/stubGenerator_x86_64_string.cpp line 1125:
> 
>> 1123: #undef lastMask
>> 1124: 
>> 1125:   int sizeIncr = isU ? 2 : 1;
> 
> sizeIncr and scale seems to be same, we could just use one of them in this function.

Done

> src/hotspot/cpu/x86/stubGenerator_x86_64_string.cpp line 1149:
> 
>> 1147: 
>> 1148:   if (size == (isU ? 2 : 1)) {
>> 1149:     __ vpmovmskb(eq_mask, cmp_0, Assembler::AVX_256bit);
> 
> vpmovmskb is being done twice if doEarlyBailout is set to 1 (the setting we have currently).
> If it helps to simplify, we could assume that doEarlyBailout is always set to 1 and remove this configurability.

Fixed with removal of DO_EARLY_BAILOUT

> src/hotspot/cpu/x86/stubGenerator_x86_64_string.cpp line 1174:
> 
>> 1172: #define lastMask rTmp
>> 1173:     __ vpmovmskb(lastMask, cmp_k, Assembler::AVX_256bit);
>> 1174:     __ shrq(lastMask);
> 
> did you mean to shift the lastMask by shiftVal here?

The whole machination around saving/restoring rcx here was to shift by cl.  The code emitted by this instruction is:
`0x00007fffe463d048:  48 d3 ea        shr    rdx,cl`
which is what is desired.

> src/hotspot/cpu/x86/stubGenerator_x86_64_string.cpp line 1183:
> 
>> 1181: 
>> 1182:     if (bytesToCompare > 2) {
>> 1183:       if (size > (isU ? 4 : 2)) {
> 
> this and other usages could be simplified to: size > 2 * scale

Done

> src/hotspot/cpu/x86/stubGenerator_x86_64_string.cpp line 1185:
> 
>> 1183:       if (size > (isU ? 4 : 2)) {
>> 1184:         if (doEarlyBailout) {
>> 1185:           __ testl(eq_mask, eq_mask);
> 
> The masks are 32 bit as we are comparing max 32 byes (256 bits) at a time. So we could consistently do either andl, testl, shrl or andq, testq, shrq.

Changed to `l` variant

> src/hotspot/cpu/x86/stubGenerator_x86_64_string.cpp line 1476:
> 
>> 1474:                                _masm);
>> 1475: 
>> 1476:   __ movq(r11, -1);
> 
> There doesn't seem to be a use of r11 below in this function.

r11 is used in exit code as the pointer to the haystack byte that matches.  Setting to `-1` will always be past the end of any haystack and return an error.  The helper after this call makes that assumption.  This is another of the "pseudo-global" registers.

> src/hotspot/cpu/x86/stubGenerator_x86_64_string.cpp line 1493:
> 
>> 1491:   // Assume r10 is n - k
>> 1492:   __ leaq(last, Address(haystack, r10, Address::times_1, isU ? -30 : -31));
>> 1493:   __ jmpb(temp);
> 
> Need to pass r10 as parameter. Also temp label could be given a better name.

Done

> src/hotspot/cpu/x86/stubGenerator_x86_64_string.cpp line 1502:
> 
>> 1500: 
>> 1501:   __ cmpq(hsPtrRet, last);
>> 1502:   __ cmovq(Assembler::aboveEqual, hsPtrRet, last);
> 
> cmovq is expensive, better sequence would be:
> 
> __ cmpq(hsPtrRet, last);
> __ jb_b(temp);
> __ movq(hsPtrRet, last);

Done

> src/hotspot/cpu/x86/stubGenerator_x86_64_string.cpp line 1510:
> 
>> 1508:   compare_big_haystack_to_needle(sizeKnown, size, NUMBER_OF_NEEDLE_BYTES_TO_COMPARE, loop_top, hsPtrRet, hsLength,
>> 1509:                                  needleLen, isU, DO_EARLY_BAILOUT, eq_mask, temp2, r10, _masm);
>> 1510: 
> 
> At this point hsLength is not the remaining length from hsPtrRet, would that cause a problem? If not, all the special paths in compare_big_haystack_to_needle need not be generated on this call.

Not sure what you mean here.  I *think* you mean that hsLength is not the length of the remaining bytes in the haystack, but the actual length.  There may be an issue if that is correct, right?  I'll investigate.

> src/hotspot/cpu/x86/stubGenerator_x86_64_string.cpp line 1589:
> 
>> 1587:     case 3:
>> 1588:     case 4:
>> 1589:       __ movl(needleVal, Address(needle, offsetOfFirstByteToCompare));
> 
> If the size of the needle is 7 and it is an LL case with NUMBER_OF_NEEDLE_BYTES_TO_COMPARE set as 3:
>   bytesLeftToCompare = 4 (i.e. 7-3);
>   offsetOfFirstByteToCompare = 2 (i.e. 3-1);
>   the movl will be loading bytes 2,3,4,5
> So we seem to be missing loading the last byte of the needle. Is that correct?

Bytes 0, 1, and 6 have already compared equal before getting to this code, so it is correct functionally.

> src/hotspot/cpu/x86/stubGenerator_x86_64_string.cpp line 1735:
> 
>> 1733: // generated with 32 - (n - k + 1) bits set that ensures matches past the end of the original
>> 1734: // haystack do not get considered during compares.
>> 1735: //
> 
> Mask is generated below with (n-k+1) bits set and not 32- (n-k+1) bits set. Also it will be helpful if we specify what is n and k.

Thanks.  Fixed.

> src/hotspot/cpu/x86/stubGenerator_x86_64_string.cpp line 1838:
> 
>> 1836:     __ shrq(rax, 1);
>> 1837:   }
>> 1838: 
> 
> We need to be consistent either use tzcntl, shrl, testl or tzcntq, shrq, testq.

I'll search through the code making them all consistent.

> src/hotspot/share/opto/library_call.cpp line 1263:
> 
>> 1261:   if (result != nullptr) {
>> 1262:     // The result is index relative to from_index if substring was found, -1 otherwise.
>> 1263:     // Generate code which will fold into cmove.
> 
> Any reason to remove this comment?

No reason - cut/paste error.  Thanks.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1603736399
PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1603740677
PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1603743601
PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1603752052
PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1603752276
PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1603752936
PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1603780784
PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1603780997
PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1603816022
PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1603833467
PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1603846748
PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1603855986
PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1603864665
PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1603865621
PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1603866807
PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1603868917
PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1603869305
PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1603884368
PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1603889410
PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1603895505
PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1603896809
PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1603897475
PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1603897759
PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1603903738
PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1603906289
PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1603914822
PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1603917518
PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1603922652
PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1603924998
PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1603939571
PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1603949004
PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1603951974
PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1603966864
PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1603974757
PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1603969211
PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1603985006
PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1603989357
PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1603990826
PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1603999938
PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1604012121

From sgibbons at openjdk.org  Thu May 16 20:57:25 2024
From: sgibbons at openjdk.org (Scott Gibbons)
Date: Thu, 16 May 2024 20:57:25 GMT
Subject: RFR: 8320448: Accelerate IndexOf using AVX2 [v7]
In-Reply-To: <nt4SRGQg7xCi2b0B0Beeobfce594QZxkYBUV8vJ4pcM=.9183d4a7-485f-40c6-ae1d-51977e629abb@github.com>
References: <uWi4QxH31hL93771gkl_GgvP0m84IRSoR_1Yi8hD17E=.bc6ed458-7081-4c3f-9348-f59358fa05a4@github.com>
 <y6CvVY726SvrGFUAMqKCLcREj1ucQUYEiTg0E8y_6VQ=.a4dd5890-42a4-4c46-8321-9369d875ca43@github.com>
 <nt4SRGQg7xCi2b0B0Beeobfce594QZxkYBUV8vJ4pcM=.9183d4a7-485f-40c6-ae1d-51977e629abb@github.com>
Message-ID: <sCWaSWrRXcihQrslFe2kqcWX1iw77q--3VQuFLK18GE=.f64832c9-a509-4d20-a07d-f8fc77647c3c@github.com>

On Tue, 16 Jan 2024 12:09:11 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Scott Gibbons has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 22 commits:
>> 
>>  - Merge branch 'openjdk:master' into indexof
>>  - Merge branch 'openjdk:master' into indexof
>>  - Addressing review comments.
>>  - Fix for JDK-8321599
>>  - Support UU IndexOf
>>  - Only use optimization when EnableX86ECoreOpts is true
>>  - Fix whitespace
>>  - Merge branch 'openjdk:master' into indexof
>>  - Comments; added exhaustive-ish test
>>  - Subtracting 0x10 twice.
>>  - ... and 12 more: https://git.openjdk.org/jdk/compare/8e12053e...3e58d0c2
>
> src/hotspot/share/opto/library_call.cpp line 1229:
> 
>> 1227:   } else {
>> 1228:     result = make_indexOf_node(src_start, src_count, tgt_start, tgt_count,
>> 1229:                                result_rgn, result_phi, ae);
> 
> Existing routines emits IR to handle following special cases.
> 
> tgt_cnt > src_cnt return -1
> tgt_cnt == 0 return 0.
> 
> Should we not be preserving those check before calling stub ?
> 
> As of now these checks are part of stub and doing them in JIT code will save call overhead.

Working on this.  Trying to develop my IR chops.  However, this is optimizing for a very small percentage of calls, so there will be unnoticable effect on overall performance.  There will only be savings for calls that have needle length == 0 (probably zero calls do this) or haystack length < needle length (maybe, but highly unlikely).

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1604010493

From smarks at openjdk.org  Thu May 16 21:21:02 2024
From: smarks at openjdk.org (Stuart Marks)
Date: Thu, 16 May 2024 21:21:02 GMT
Subject: RFR: 8331224: ClassCastException in ObjectInputStream hides
 ClassNotFoundException
In-Reply-To: <WwGt00cM9kdSmRkkh5Vs27AanKC0I4DwCBoWhai7itI=.3dde8683-9701-4d87-bf5f-0d0d501bd037@github.com>
References: <WwGt00cM9kdSmRkkh5Vs27AanKC0I4DwCBoWhai7itI=.3dde8683-9701-4d87-bf5f-0d0d501bd037@github.com>
Message-ID: <6hKSsT_O-scMHv85LuYVhMj075Tiscp--5W_EFOdSRw=.e1d12da9-3eba-44f0-b5a2-cc14deb86983@github.com>

On Wed, 1 May 2024 18:43:21 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> The issue reported a ClassCastException "cannot assign instance of java.util.CollSer to field of type java.util.Map"
> while deserializing an object referring to an immutable Map that contained a reference to a class that was not available.
> Immutable Collections such as Map utilize a serialization proxy in their serialized form.
> During deserialization the serialization proxy (a private implementation class) was attempted to be set in a field resulting in the ClassCastException. The ClassCastException and bug hid the ClassCastException that should have been thrown.
> 
> When reading record fields or fields of a class, the results of deserialization of individual fields are recorded as dependencies of the object being constructed.
> The apparent bug is that the summary of those dependencies is not checked between reading the fields and invoking the constructor to create the record or assigning the fields to an object being constructed.

src/java.base/share/classes/java/io/ObjectInputStream.java line 2376:

> 2374:         if (handles.lookupException(passHandle) != null) {
> 2375:             return null;     // slot marked with exception, don't create record
> 2376:         }

It's proper to avoid creating a record instance in this case. However, returning null is new behavior; this initially seemed a bit odd. The calling method `readOrdinaryObject()` does allow a null return if the class couldn't be resolved, and the body of `readOrdinaryObject()` does allow `obj` to be null throughout. So, returning `null` from here is correct, though it took me a while to puzzle out. :-)

I'd suggest adding some docs to `readRecord()` to indicate that it returns the record instance if it could be created successfully, null if the record class couldn't be resolved, or throws an error or other exception if one occurred when instantiation was attempted.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19043#discussion_r1604052829

From joehw at openjdk.org  Thu May 16 22:20:39 2024
From: joehw at openjdk.org (Joe Wang)
Date: Thu, 16 May 2024 22:20:39 GMT
Subject: RFR: 8330542: Add jaxp-strict.properties in preparation for a
 secure by default configuration [v8]
In-Reply-To: <v1bAYKgH9zfooXpvnBw4Vu2TIqHuKqqtSmgB0hiNp-Q=.31661a99-ecfc-4a05-8045-67b5f680db60@github.com>
References: <v1bAYKgH9zfooXpvnBw4Vu2TIqHuKqqtSmgB0hiNp-Q=.31661a99-ecfc-4a05-8045-67b5f680db60@github.com>
Message-ID: <WaojCmjwxI30LQExFov5KlAMiJVqJC7RqZLMtmAOCFc=.2cbfbcc6-6015-43aa-bcc7-5e1bba4b75dd@github.com>

> Add two sample configuration files:
> 
>   jaxp-strict.properties: used to set strict configuration, stricter than jaxp.properties in previous versions such as JDK 22
> 
>>   jaxp-compat.properties: used to regain compatibility from any more restricted configuration than previous versions such as JDK 22
> 
> Updated 5/16/2024
> 
> Design change:
> The design is changed to include in the JDK two configuration files that are the default jaxp.properties and jaxp-strict.properties, instead of three, dropping jaxp-compat.properties.

Joe Wang has updated the pull request incrementally with one additional commit since the last revision:

  remove jaxp-compat.properties from the list

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/18831/files
  - new: https://git.openjdk.org/jdk/pull/18831/files/f3af4ae9..cf4df792

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18831&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18831&range=06-07

  Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/18831.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18831/head:pull/18831

PR: https://git.openjdk.org/jdk/pull/18831

From duke at openjdk.org  Thu May 16 23:30:01 2024
From: duke at openjdk.org (Konstantin Nisht)
Date: Thu, 16 May 2024 23:30:01 GMT
Subject: RFR: 8332154: Memory leak in SynchronousQueue
In-Reply-To: <bTv3Bc8P355m7kNSPOd1_ybXXewKB6lvqOwzKtO58cE=.cb6dc72f-ef56-46ca-a5b4-7d821327e6ec@github.com>
References: <Fj3W5LlneHODz3PcBD0Ypu2f34UYvxw1iLLKz5pba-I=.0f419338-0a23-4834-8404-55aeab4b813f@github.com>
 <bTv3Bc8P355m7kNSPOd1_ybXXewKB6lvqOwzKtO58cE=.cb6dc72f-ef56-46ca-a5b4-7d821327e6ec@github.com>
Message-ID: <Ie2RBQsHbdlFbZFM_RVLEX6_eMDIJXpyeXxrofPkjLY=.2a2cb32d-28a8-4c49-a0a5-05642d16cc3d@github.com>

On Thu, 16 May 2024 15:06:45 GMT, Viktor Klang <vklang at openjdk.org> wrote:

>> Local testing seems to indicate that this fix (which mirrors what's done in the FIFO mode) addresses the problem.
>> 
>> But with that said, I haven't come up with a decent way of adding some form of regression test. Suggestions are most welcome. /cc @DougLea
>
> @AlanBateman @DougLea Reviews are most welcome :)

@viktorklang-ora We managed to reproduce it quite reliably by running the test from the bug report multiple times (in our case, it was 100). I understand this does not make a 100% stable regression reproducer, but in case of multiple runs the probability of false positive in quite low.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19271#issuecomment-2116230751

From sviswanathan at openjdk.org  Thu May 16 23:38:08 2024
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Thu, 16 May 2024 23:38:08 GMT
Subject: RFR: 8329538: Accelerate P256 on x86_64 using Montgomery intrinsic
 [v9]
In-Reply-To: <g3g_VMiSRzuhMJ2JIlmtES7TjMGbKWxBMkfFvsQfvOs=.e0dea05e-8adc-48f3-8d1c-81352311de9c@github.com>
References: <hanRK4GzOkFV8kG1gZRy8Br53trw4-Tu6G6uO8nsFuk=.d5bf723a-f683-4759-ac9e-4a58cb430f03@github.com>
 <g3g_VMiSRzuhMJ2JIlmtES7TjMGbKWxBMkfFvsQfvOs=.e0dea05e-8adc-48f3-8d1c-81352311de9c@github.com>
Message-ID: <9aJy6ON5gSI5ihwK-WkvnyrtHjJTPN5IAFymf1Jpp9M=.32b8ee27-465d-47d8-9099-22cb846cff9a@github.com>

On Fri, 10 May 2024 00:19:32 GMT, Volodymyr Paprotski <duke at openjdk.org> wrote:

>> Performance. Before:
>> 
>> Benchmark                        (algorithm)  (dataSize)  (keyLength)  (provider)   Mode  Cnt     Score    Error  Units
>> SignatureBench.ECDSA.sign    SHA256withECDSA        1024          256              thrpt    3  6443.934 ?  6.491  ops/s
>> SignatureBench.ECDSA.sign    SHA256withECDSA       16384          256              thrpt    3  6152.979 ?  4.954  ops/s
>> SignatureBench.ECDSA.verify  SHA256withECDSA        1024          256              thrpt    3  1895.410 ? 36.979  ops/s
>> SignatureBench.ECDSA.verify  SHA256withECDSA       16384          256              thrpt    3  1878.955 ? 45.487  ops/s
>> Benchmark                                            (algorithm)  (keyLength)  (kpgAlgorithm)  (provider)   Mode  Cnt     Score    Error  Units
>> o.o.b.j.c.full.KeyAgreementBench.EC.generateSecret          ECDH          256              EC              thrpt    3  1357.810 ? 26.584  ops/s
>> o.o.b.j.c.small.KeyAgreementBench.EC.generateSecret         ECDH          256              EC              thrpt    3  1352.119 ? 23.547  ops/s
>> Benchmark                          (isMontBench)   Mode  Cnt     Score    Error  Units
>> PolynomialP256Bench.benchMultiply          false  thrpt    3  1746.126 ? 10.970  ops/s
>> 
>> Performance, no intrinsic:
>> 
>> Benchmark                        (algorithm)  (dataSize)  (keyLength)  (provider)   Mode  Cnt     Score     Error  Units
>> SignatureBench.ECDSA.sign    SHA256withECDSA        1024          256              thrpt    3  6529.839 ?  42.420  ops/s
>> SignatureBench.ECDSA.sign    SHA256withECDSA       16384          256              thrpt    3  6199.747 ? 133.566  ops/s
>> SignatureBench.ECDSA.verify  SHA256withECDSA        1024          256              thrpt    3  1973.676 ?  54.071  ops/s
>> SignatureBench.ECDSA.verify  SHA256withECDSA       16384          256              thrpt    3  1932.127 ?  35.920  ops/s
>> Benchmark                                            (algorithm)  (keyLength)  (kpgAlgorithm)  (provider)   Mode  Cnt     Score    Error  Units
>> o.o.b.j.c.full.KeyAgreementBench.EC.generateSecret          ECDH          256              EC              thrpt    3  1355.788 ? 29.858  ops/s
>> o.o.b.j.c.small.KeyAgreementBench.EC.generateSecret         ECDH          256              EC              thrpt    3  1346.523 ? 28.722  ops/s
>> Benchmark                          (isMontBench)   Mode  Cnt     Score    Error  Units
>> PolynomialP256Bench.benchMultiply           true  thrpt    3  1919.57...
>
> Volodymyr Paprotski has updated the pull request incrementally with one additional commit since the last revision:
> 
>   whitespace

src/hotspot/cpu/x86/stubGenerator_x86_64_poly_mont.cpp line 168:

> 166:   XMMRegister broadcast5 = xmm24;
> 167:   KRegister limb0 = k1;
> 168:   KRegister limb5 = k2;

limb5 and select are not being used anymore.

src/hotspot/cpu/x86/stubGenerator_x86_64_poly_mont.cpp line 185:

> 183:   __ evmovdquq(modulus, allLimbs, ExternalAddress(modulus_p256()), false, Assembler::AVX_512bit, rscratch);
> 184: 
> 185:   // A = load(*aLimbs)

A little bit more description in comments on what the load step involves would be helpful. e.g. Load upper 4 limbs, shift left by 1 limb using perm, or in the lowest limb.

src/hotspot/cpu/x86/stubGenerator_x86_64_poly_mont.cpp line 270:

> 268:   __ push(r14);
> 269:   __ push(r15);
> 270: 

No need to save/restore  rbx, r12, r14, r15.  Only r13 is used as temp in montgomeryMultiply(aLimbs, bLimbs, rLimbs). That too could be easily changed to r8.

src/hotspot/cpu/x86/stubGenerator_x86_64_poly_mont.cpp line 286:

> 284:   __ mov(aLimbs, c_rarg0);
> 285:   __ mov(bLimbs, c_rarg1);
> 286:   __ mov(rLimbs, c_rarg2);

We could directly call montgomeryMultiply(c_rarg0, c_rarg1, c_rarg2) then these moves are not necessary.

src/hotspot/cpu/x86/vm_version_x86.cpp line 1370:

> 1368: 
> 1369: #ifdef _LP64
> 1370:   if (supports_avx512ifma() && supports_avx512vlbw() && MaxVectorSize >= 64) {

No need to tie the intrinsic to MaxVectorSize setting.

src/hotspot/share/opto/library_call.cpp line 7564:

> 7562: 
> 7563:   if (!stubAddr) return false;
> 7564:   if (stopped())  return true;

Line 7564 seems redundant here as there is no range check or anything like that  before this.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18583#discussion_r1604169603
PR Review Comment: https://git.openjdk.org/jdk/pull/18583#discussion_r1604141586
PR Review Comment: https://git.openjdk.org/jdk/pull/18583#discussion_r1604174141
PR Review Comment: https://git.openjdk.org/jdk/pull/18583#discussion_r1604175443
PR Review Comment: https://git.openjdk.org/jdk/pull/18583#discussion_r1603792252
PR Review Comment: https://git.openjdk.org/jdk/pull/18583#discussion_r1603865712

From smarks at openjdk.org  Fri May 17 01:26:12 2024
From: smarks at openjdk.org (Stuart Marks)
Date: Fri, 17 May 2024 01:26:12 GMT
Subject: RFR: 8331224: ClassCastException in ObjectInputStream hides
 ClassNotFoundException
In-Reply-To: <WwGt00cM9kdSmRkkh5Vs27AanKC0I4DwCBoWhai7itI=.3dde8683-9701-4d87-bf5f-0d0d501bd037@github.com>
References: <WwGt00cM9kdSmRkkh5Vs27AanKC0I4DwCBoWhai7itI=.3dde8683-9701-4d87-bf5f-0d0d501bd037@github.com>
Message-ID: <6SPQ-QbbOEclKpYPilyi_zPGjc4lHC7PcFvgFV25uVU=.173a3d50-5b15-476a-8397-60b01b18caa1@github.com>

On Wed, 1 May 2024 18:43:21 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> The issue reported a ClassCastException "cannot assign instance of java.util.CollSer to field of type java.util.Map"
> while deserializing an object referring to an immutable Map that contained a reference to a class that was not available.
> Immutable Collections such as Map utilize a serialization proxy in their serialized form.
> During deserialization the serialization proxy (a private implementation class) was attempted to be set in a field resulting in the ClassCastException. The ClassCastException and bug hid the ClassCastException that should have been thrown.
> 
> When reading record fields or fields of a class, the results of deserialization of individual fields are recorded as dependencies of the object being constructed.
> The apparent bug is that the summary of those dependencies is not checked between reading the fields and invoking the constructor to create the record or assigning the fields to an object being constructed.

OK, I finally went through the changes. First, it's correct to assign the field values only when passHandle is not marked with an exception. It's fairly subtle but if passHandle is marked with an exception, the exception will be thrown by one of the methods farther up the call stack. Second, the test looks pretty comprehensive.

The main difficulty I had is not with the changes here but that the code in this area is handling rather too many cases, including: record/ordinary-class, has vs no special read method, read data into an object vs skipping data, and probably a few other cases. I'm not sure what, if anything, should be done about this. But in any case this should be a subject of a separate conversation.

-------------

Marked as reviewed by smarks (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19043#pullrequestreview-2062163253

From roger.riggs at oracle.com  Fri May 17 02:57:46 2024
From: roger.riggs at oracle.com (Roger Riggs)
Date: Thu, 16 May 2024 22:57:46 -0400
Subject: Deterministic naming of subclasses of `java/lang/reflect/Proxy`
In-Reply-To: <50405ca9c0a64372bace175b932f9ef7@kth.se>
References: <bf26eb2f74874e02876b3868311922a9@kth.se>
 <CABe8uE0fk71Xy_PYHikSw9OtXE_i+M9zMbayPEXuTxLWLoy2ag@mail.gmail.com>
 <50405ca9c0a64372bace175b932f9ef7@kth.se>
Message-ID: <61fbe3d9-9536-4113-adde-6cfc671ba1ee@oracle.com>

Hi Aman,

You may also run into hidden classes (JEP 371: Hidden Classes) that 
allow classes to be defined, at runtime, without names.
It has been proposed to use them for generated proxies but that hasn't 
been implemented yet.
There are benefits to having nameless classes, because they can't be 
referenced by name, only as a capability, they can be better encapsulated.

fyi, Roger Riggs


On 5/16/24 8:11 AM, Aman Sharma wrote:
>
> Hi,
>
>
> Thanks for your response, Liang!
>
>
> > I think you meant CVE-2021-42392 instead of 2022.
>
>
> Sorry of the error. I indeed meant CVE-2021-42392 
> <https://nvd.nist.gov/vuln/detail/cve-2021-42392>.
>
>
> > Leyden mainly avoids this unstable generation by performing a 
> training run to collect classes loaded
>
>
> Would love to know the details of Project Leyden and how they worked 
> so far to focus on this goal. In our case, the training run is the 
> test suite.
>
>
> > GeneratedConstructorAccessor is already retired by JEP 416 [2] in 
> Java 18
>
>
> I did see them not appearing in my allowlist when I ran my study 
> subject (Apache PDFBox) with Java 21. Thanks for letting me know about 
> this JEP. I see they are re-implemented with method handles.
>
>
> > How are you checking the classes?
>
>
> To detect runtime generated code, we have javaagent that is hooked 
> statically to the test suite execution. It gives us all classes that 
> that is loaded post the JVM and the javaagent are loaded. So we only 
> check the classes loaded for the purpose of running the application. 
> This is also why we did not choose -agentlib as it would give classes 
> for the setting up JVM and javaagent and we the user of our tool must 
> the classes they load.
>
>
> Next, we have a `ClassFileTransformer` hook in the agent where we 
> produce the checksum using the bytecode. And we compare the checksum 
> with the one existing in the allowlist. The checksum computation 
> algorithm is same for both steps. Let me describe how I compute the 
> checksum.
>
>
>  1. I get the CONSTANT_Class_info
>     <https://docs.oracle.com/javase/specs/jvms/se11/html/jvms-4.html#jvms-4.4.1>
>     entry corresponding to `this_class` and rewrite the
>     CONSTANT_Utf8_info
>     <https://docs.oracle.com/javase/specs/jvms/se11/html/jvms-4.html#jvms-4.4.7>
>     corresponding to a fix String constant, say "foo".
>  2. Since, the name of the class is used to refer to its types members
>     (fields/method), I get all CONSTANT_Fieldref_info
>     <https://docs.oracle.com/javase/specs/jvms/se11/html/jvms-4.html#jvms-4.4.2>
>     and if its `class_index` corresponds to the old `this_class`, we
>     rewrite the UTF8 value of class_index to the same constant "foo".
>  3. Next, since the naming of the fields, in Proxy classes, are also
>     suffixed by numbers, for example, `private static Method m4`, we
>     rewrite the UTF8 value of name in the CONSTANT_NameAndType_info
>     <https://docs.oracle.com/javase/specs/jvms/se11/html/jvms-4.html#jvms-4.4.6>.
>  4. These fields can also have a random order so we simply sort the
>     entire byte code using `Arrays.sort(byte[])` to eliminate any
>     differences due to ordering of fields/methods.
>  5. Simply sorting the byte array still had minute differences. I
>     could not understand why they existed even though values in
>     constant pool of the bytecode in allowlist and at runtime were
>     exactly the same after rewriting. The differences existed in the
>     bytes of the Code attribute of methods. I concluded that the bytes
>     stored some position information. To avoid this, I created a
>     subarray where I considered the bytes corresponding to
>     `CONSTANT_Utf8_info.bytes` only. Computing a checksum for it
>     resulted in the same checksums for both classfiles.
>
>
> Let's understand the whole approach with an example of Proxy class.
>
> `
> public  final  class  $Proxy42  extends  Proxy  implements  org.apache.logging.log4j.core.config.plugins.Plugin  {
> `
>
> The will go in the allowlist as "Proxy_Plugin: <SHA256 checksum>".
>
> When the same class is intercepted at runtime, say "$Proxy10", we look 
> for "Proxy_Plugin" in the allowlist and since the checksum algorithm 
> is same in both cases, we get a match and let the class load.
>
> This approach has seemed to work well for Proxy classes, Generated 
> Constructor Accessor (which is removed as you said). I also looked at 
> the species generated by method handles. I did not notice any 
> modification in them. Their name generation seemed okay to me. If some 
> new Species are generated, it is of course detected since it is not in 
> the allowlist.
>
> I have not looked into LambdaMetafactory because I did not encounter 
> it as a problem so far, but I am aware its name generation is also 
> unstable. I have run my approach only a few projects only. And for 
> hidden classes, I assume the the agent won't be able to intercept them 
> so detecting them would be really hard.
>
>
> Regards,
> Aman Sharma
>
> PhD Student
> KTH Royal Institute of Technology
> School of Electrical Engineering and Computer Science (EECS)
> Department of Theoretical Computer Science (TCS)
> <https://www.kth.se/profile/amansha>https://algomaster99.github.io/ 
> <https://algomaster99.github.io/>
> ------------------------------------------------------------------------
> *From:* liangchenblue at gmail.com <liangchenblue at gmail.com>
> *Sent:* Thursday, May 16, 2024 5:52:03 AM
> *To:* Aman Sharma; core-libs-dev
> *Cc:* Martin Monperrus
> *Subject:* Re: Deterministic naming of subclasses of 
> `java/lang/reflect/Proxy`
> Hi Aman,
> I think you meant CVE-2021-42392 instead of 2022.
>
> For your approach of an "allowlist" for Java runtime, project Leyden 
> is looking to generate a static image [1], that
> >?At run time it cannot load classes from outside the image, nor can 
> it create classes dynamically.
> Leyden mainly avoids this unstable generation by performing a training 
> run to collect classes loaded and even object graphs; I am not 
> familiar with the details unfortunately.
>
> Otherwise, the Proxy discussion belongs better to core-libs-dev, as 
> java.lang.reflect.Proxy is part of Java's core libraries. I am 
> replying this thread to core-libs-dev.
>
> For your perceived problem that classes don't have unique names, your 
> description sounds dubious: GeneratedConstructorAccessor is already 
> retired by JEP 416 [2] in Java 18, and there are many other cases in 
> which JDK generates classes without stable names, notoriously 
> LambdaMetafactory (Gradle wished for cacheable Lambdas); the same 
> applies for the generated classes for MethodHandle's?LambdaForms 
> (which carries implementation code for LambdaForm). How are you 
> checking the classes? It seems you are not checking hidden classes. 
> Proxy and Lambda classes are defined by the caller's class loader, 
> while LambdaForms are under JDK's system class loader I think. We need 
> to ensure you are correctly finding all unstable classes before we can 
> proceed.
>
> [1]: https://openjdk.org/projects/leyden/notes/01-beginnings
> [2]: https://openjdk.org/jeps/416
>
> On Wed, May 15, 2024 at 7:00?PM Aman Sharma <amansha at kth.se> wrote:
>
>     Hi,
>
>
>     My name is Aman and I am a PhD student at KTH Royal Institute of
>     Technology, Stockholm, Sweden. I research as part of CHAINS
>     <https://chains.proj.kth.se/> project to strengthen the software
>     supply chain of multiple ecosystem. I particularly focus on
>     runtime integrity in Java. In this email, I want to write about an
>     issue I have discovered with /dynamic generation of
>     `java.lang.reflect.Proxy`classes/. I will propose a solution and
>     would love to hear the feedback from the community. Let me know if
>     this is the correct mailing-list for such discussions. It seemed
>     the most relevant from this list
>     <https://mail.openjdk.org/mailman/listinfo>.
>
>
>     *My research*
>
>     *
>     *
>
>     Java has features to load class on the fly - it can either
>     download or generate a class at runtime. These features are useful
>     for inner workings of JDK. For example, implementing annotations,
>     reflective access, etc. However, these features have also
>     contributed to critical vulnerabilities in the past
>     -?CVE-2021-44228 (log4shell), CVE-2022-33980, CVE-2022-42392. All
>     of these vulnerabilities have one thing in common - /a class that
>     was not known during build time was downloaded/generated at
>     runtime and loaded into JVM./
>
>
>     To defend against such vulnerabilities, we propose a solution to
>     /allowlist classes for runtime/. This allowlist will contain an
>     exhaustive list of classes that can be loaded by the JVM and it
>     will be enforced at runtime. We build this allowlist from three
>     sources:
>
>      1. All classes of all modules provided by the Java Standard
>         Library. We use ClassGraph
>         <https://github.com/classgraph/classgraph> to scan the JDK.
>      2. We can take the source code and all dependencies of an
>         application. We use a software bill of materials to get all
>         the data.
>      3. Finally, we use run the test suite to include any runtime
>         downloaded/generated classes.
>
>     Such a list is able to prevent the above 3 CVEs because it does
>     not let the "unknown" bytecode to be loaded.
>
>     *Problem with generating such an allowlist*
>     *
>     *
>     The first two parts of the allowlist are easy to get. The problem
>     is with the third step where we want to allowlist all the classes
>     that could be downloaded or generated. Upon running the test suite
>     and hooking to the classes it loads, we observer that the list
>     consists of classes that are called "com/sun/proxy/$Proxy2",
>     "jdk/internal/reflect/GeneratedConstructorAccessor3" among many
>     more. The purpose of these classes can be identifed. The proxy
>     class is created for to implement an annotation. The accessor
>     gives access to constructor of a class to the JVM.
>
>     When enforcing this allowlist at runtime, we see that the bytecode
>     content for "com/sun/proxy/$Proxy2" differs in the allowlist and
>     at runtime. In our case, we we are experimenting with pdfbox
>     <https://github.com/apache/pdfbox> so we created the allowlist
>     using its test suite. Then we enforced this allowlist while
>     running some of its subcommands. However, there was some other
>     proxy class say "com/sun/proxy/$Proxy5" at runtime that
>     implemented the same interfaces and had the same methods as
>     "com/sun/proxy/$Proxy2" in the allowlist. They only differed in
>     the name of the class, order of fields, and types for fields
>     references. This could happen because the order of the loading of
>     class is workload dependent, but it causes problem to generate
>     such an allowlist.
>
>     *Solution
>     *
>
>
>     We propose that naming of subclasses of "java/lang/reflect/Proxy"
>     should not be dependent upon the order of loading. In order to do
>     so, two issues can be fixed:
>
>      1. The naming of the class should not be based on AtomicLong
>         <https://github.com/openjdk/jdk/blob/b687aa550837830b38f0f0faa69c353b1e85219c/src/java.base/share/classes/java/lang/reflect/Proxy.java#L531>.
>         Rather it could be named based on the interfaces it
>         implements. I also wonder why AtomicLong is chosen in the
>         first place.
>      2. Methods of the interfaces must be in a particular order. Right
>         now, they are not sorted in any particular order
>         <https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/lang/Class.java#L2178>.
>
>
>     These fixes will make proxy class generation deterministic with
>     respect to order of loading and won't be flagged at runtime since
>     the test suite would already detect them.
>
>     I would love to hear from the community about these ideas. If in
>     agreement, I would be happy to produce a patch. I have discovered
>     this issue with subclasses of GeneratedConstructorAccessor
>     <https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/jdk/internal/reflect/ConstructorAccessor.java>
>     as well and I imagine it will also apply to some other runtime
>     generated classes. If you disagree, please let me know also. It
>     helps with my research.
>
>     I also have PoCs for the above CVEs
>     <https://github.com/chains-project/exploits-for-sbom.exe> and a
>     proof concept tool is being developed under the name sbom.exe
>     <https://github.com/chains-project/sbom.exe> in case any one
>     wonders about the implementation. I would also be happy to explain
>     more.
>
>     Regards,
>     Aman Sharma
>
>     PhD Student
>     KTH Royal Institute of Technology
>     School of Electrical Engineering and Computer Science (EECS)
>     Department of Theoretical Computer Science (TCS)
>     <https://www.kth.se/profile/amansha>https://algomaster99.github.io/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240516/9715830f/attachment-0001.htm>

From alanb at openjdk.org  Fri May 17 05:54:03 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 17 May 2024 05:54:03 GMT
Subject: RFR: 8330542: Add jaxp-strict.properties in preparation for a
 secure by default configuration [v8]
In-Reply-To: <WaojCmjwxI30LQExFov5KlAMiJVqJC7RqZLMtmAOCFc=.2cbfbcc6-6015-43aa-bcc7-5e1bba4b75dd@github.com>
References: <v1bAYKgH9zfooXpvnBw4Vu2TIqHuKqqtSmgB0hiNp-Q=.31661a99-ecfc-4a05-8045-67b5f680db60@github.com>
 <WaojCmjwxI30LQExFov5KlAMiJVqJC7RqZLMtmAOCFc=.2cbfbcc6-6015-43aa-bcc7-5e1bba4b75dd@github.com>
Message-ID: <LBD-47vDvjpMdi3UXb0ohMpqLEegT4ceIV7RKY8T3EA=.1bd16214-be8b-43df-add2-d76939db21de@github.com>

On Thu, 16 May 2024 22:20:39 GMT, Joe Wang <joehw at openjdk.org> wrote:

>> Add two sample configuration files:
>> 
>>   jaxp-strict.properties: used to set strict configuration, stricter than jaxp.properties in previous versions such as JDK 22
>> 
>>>   jaxp-compat.properties: used to regain compatibility from any more restricted configuration than previous versions such as JDK 22
>> 
>> Updated 5/16/2024
>> 
>> Design change:
>> The design is changed to include in the JDK two configuration files that are the default jaxp.properties and jaxp-strict.properties, instead of three, dropping jaxp-compat.properties.
>
> Joe Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove jaxp-compat.properties from the list

make/modules/java.xml/Copy.gmk line 37:

> 35: JAXPPROPFILE_TARGET_FILES := $(subst $(JAXPPROPFILE_SRC_DIR),$(CONF_DST_DIR),$(JAXPPROPFILE_SRCS))
> 36: 
> 37: $(CONF_DST_DIR)/%: $(JAXPPROPFILE_SRC_DIR)/%

The make file changes to copy the properties files look okay but I'm curious about why the naming changes from "XML" to "JAXPPROFILE".

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18831#discussion_r1604383246

From jpai at openjdk.org  Fri May 17 05:59:15 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 17 May 2024 05:59:15 GMT
Subject: RFR: 8173970: jar tool should have a way to extract to a directory
 [v5]
In-Reply-To: <APZvm76TDV-TwhV7PpsP9aTpdE9AmdcaU3zVCbHuv7U=.c53bf4f5-da9f-4c6a-8242-4e18c8551885@github.com>
References: <MRlQpBJcCaZSMcnssPw88TaYd2cAwiJOkfI4k8hXM0E=.76718687-c714-4d12-a03b-fa0fdb51a9ff@github.com>
 <APZvm76TDV-TwhV7PpsP9aTpdE9AmdcaU3zVCbHuv7U=.c53bf4f5-da9f-4c6a-8242-4e18c8551885@github.com>
Message-ID: <JnE3FalNdv0_Se3l2SIulLyJNd0FtCotGMf0DUXM4H8=.47f81e7a-38a3-4dfd-bb27-6013a4250bae@github.com>

On Wed, 8 May 2024 05:37:24 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review for this patch which proposes to implement the enhancement request noted in https://bugs.openjdk.java.net/browse/JDK-8173970?
>> 
>> The commit in this PR introduces the `-o` and `--output-dir` option to the `jar` command. The option takes a path to a destination directory as a value and extracts the contents of the jar into that directory. This is an optional option and the changes in the commit continue to maintain backward compatibility where the jar is extracted into current directory, if no `-o` or `--output-dir` option has been specified.
>> 
>> As far as I know, there hasn't been any discussion on what the name of this new option should be. I was initially thinking of using `-d` but that is currently used by the `jar` command for a different purpose. So I decided to use `-o` and `--output-dir`. This is of course open for change depending on any suggestions in this PR.
>> 
>> The commit in this PR also updates the `jar.properties` file which contains the English version of the jar command's `--help` output. However, no changes have been done to the internationalization files corresponding to this one (for example: `jar_de.properties`), because I don't know what process needs to be followed to have those files updated (if at all they need to be updated).
>> 
>> The commit also includes a jtreg testcase which verifies the usage of this new option.
>
> Jaikiran Pai has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 15 commits:
> 
>  - cleanup testExtractNoDestDirWithPFlag() test
>  - merge latest from master branch
>  - merge latest from master branch
>  - convert the new test to junit
>  - merge latest from master branch
>  - Lance's review - include tests for --extract long form option
>  - cleanup after each test
>  - Adjust test for new error messages
>  - Lance's review - add a code comment for xdestDir
>  - Lance's review - updates to the help messages in jar.properties
>  - ... and 5 more: https://git.openjdk.org/jdk/compare/3b8227ba...46fb5a8e

Hello everyone, this was a PR that I had opened some years back to introduce an option for the `jar` command to extract the contents to a directory of choice. After evaluating the option name (discussion within this PR), we had settled on `--dir` as the option. For some reason (I don't recollect) I never took this PR to completion. I've now reopened this PR and merged with the latest master branch and run all the tests including the new ones introduced in this PR. I would like to take this to completion, so I request reviews on this.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/2752#issuecomment-2116762815

From asotona at openjdk.org  Fri May 17 06:06:01 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Fri, 17 May 2024 06:06:01 GMT
Subject: RFR: 8332109: Convert remaining tests using
 com.sun.tools.classfile to ClassFile API
In-Reply-To: <argrcg0iKCFTZJz-mOA_OXkVPbyy0Z5Qb4L2g0Qc4gw=.637a0870-77b0-49da-9aee-ffa39ba68c5f@github.com>
References: <argrcg0iKCFTZJz-mOA_OXkVPbyy0Z5Qb4L2g0Qc4gw=.637a0870-77b0-49da-9aee-ffa39ba68c5f@github.com>
Message-ID: <HkgGsgbB-bNXIYrREDFqpA6NGapnqca6d0ZnSZCQh9w=.1b45aeba-81d8-4e53-9531-1225ec2acc1c@github.com>

On Sun, 12 May 2024 08:36:44 GMT, Chen Liang <liach at openjdk.org> wrote:

> Some tests are not migrated to the ClassFile API in previous migrations.
> 
>  - Some are simple oversights that didn't remove usages of com.sun.tools.classfile;
>  - The CallerSensitive ones used an old utility, replaced by CF API-based new code;
>  - many in javac are because the files are compiled with older source compatibility. Those patches are converted to have the source code stored in text blocks and compiled within tests using `ToolBox#writeJavaFiles` and `CompilerUtils.compile`;
>  - As described in the JBS issue, there are a few other tests not covered; one is in #19193 while the others are blocked by CreateSymbols migration or bugs.
> 
> Testing: all modified tests pass.

test/jdk/jdk/internal/reflect/CallerSensitive/CheckCSMs.java line 151:

> 149: 
> 150:             boolean needsCsm = false;
> 151:             for (var element : code) {

Scanning the instructions is a bit different approach than in the original test.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19206#discussion_r1604390936

From asotona at openjdk.org  Fri May 17 06:10:03 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Fri, 17 May 2024 06:10:03 GMT
Subject: RFR: 8332109: Convert remaining tests using
 com.sun.tools.classfile to ClassFile API
In-Reply-To: <argrcg0iKCFTZJz-mOA_OXkVPbyy0Z5Qb4L2g0Qc4gw=.637a0870-77b0-49da-9aee-ffa39ba68c5f@github.com>
References: <argrcg0iKCFTZJz-mOA_OXkVPbyy0Z5Qb4L2g0Qc4gw=.637a0870-77b0-49da-9aee-ffa39ba68c5f@github.com>
Message-ID: <d454dZdWIcrJgDideSOYyGfePt3MP4olG_WFaGtu5Lk=.d256ba2c-fddc-4b1c-bde5-ceda80f87175@github.com>

On Sun, 12 May 2024 08:36:44 GMT, Chen Liang <liach at openjdk.org> wrote:

> Some tests are not migrated to the ClassFile API in previous migrations.
> 
>  - Some are simple oversights that didn't remove usages of com.sun.tools.classfile;
>  - The CallerSensitive ones used an old utility, replaced by CF API-based new code;
>  - many in javac are because the files are compiled with older source compatibility. Those patches are converted to have the source code stored in text blocks and compiled within tests using `ToolBox#writeJavaFiles` and `CompilerUtils.compile`;
>  - As described in the JBS issue, there are a few other tests not covered; one is in #19193 while the others are blocked by CreateSymbols migration or bugs.
> 
> Testing: all modified tests pass.

test/jdk/jdk/internal/reflect/CallerSensitive/CallerSensitiveFinder.java line 125:

> 123:                         && invoke.method() instanceof MethodRefEntry ref
> 124:                         && ref.owner().name().equalsString(className)
> 125:                         && ref.name().equalsString(methodName)) {

Is this additional test necessary, I don't see it in the original test.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19206#discussion_r1604394473

From asotona at openjdk.org  Fri May 17 06:17:01 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Fri, 17 May 2024 06:17:01 GMT
Subject: RFR: 8332109: Convert remaining tests using
 com.sun.tools.classfile to ClassFile API
In-Reply-To: <argrcg0iKCFTZJz-mOA_OXkVPbyy0Z5Qb4L2g0Qc4gw=.637a0870-77b0-49da-9aee-ffa39ba68c5f@github.com>
References: <argrcg0iKCFTZJz-mOA_OXkVPbyy0Z5Qb4L2g0Qc4gw=.637a0870-77b0-49da-9aee-ffa39ba68c5f@github.com>
Message-ID: <--saIYmEctI2zS7Aqc6GfpsrgAVYR9qn1xRza95QI98=.dd5403de-3d5f-49e4-ae46-258b054fd645@github.com>

On Sun, 12 May 2024 08:36:44 GMT, Chen Liang <liach at openjdk.org> wrote:

> Some tests are not migrated to the ClassFile API in previous migrations.
> 
>  - Some are simple oversights that didn't remove usages of com.sun.tools.classfile;
>  - The CallerSensitive ones used an old utility, replaced by CF API-based new code;
>  - many in javac are because the files are compiled with older source compatibility. Those patches are converted to have the source code stored in text blocks and compiled within tests using `ToolBox#writeJavaFiles` and `CompilerUtils.compile`;
>  - As described in the JBS issue, there are a few other tests not covered; one is in #19193 while the others are blocked by CreateSymbols migration or bugs.
> 
> Testing: all modified tests pass.

test/langtools/tools/javac/7166455/CheckACC_STRICTFlagOnclinitTest.java line 81:

> 79:         ToolBox toolBox = new ToolBox();
> 80:         toolBox.writeJavaFiles(in, SOURCE);
> 81:         CompilerUtils.compile(in, out, "--release", "16");

Smart move ?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19206#discussion_r1604399988

From liach at openjdk.org  Fri May 17 06:21:01 2024
From: liach at openjdk.org (Chen Liang)
Date: Fri, 17 May 2024 06:21:01 GMT
Subject: RFR: 8332109: Convert remaining tests using
 com.sun.tools.classfile to ClassFile API
In-Reply-To: <d454dZdWIcrJgDideSOYyGfePt3MP4olG_WFaGtu5Lk=.d256ba2c-fddc-4b1c-bde5-ceda80f87175@github.com>
References: <argrcg0iKCFTZJz-mOA_OXkVPbyy0Z5Qb4L2g0Qc4gw=.637a0870-77b0-49da-9aee-ffa39ba68c5f@github.com>
 <d454dZdWIcrJgDideSOYyGfePt3MP4olG_WFaGtu5Lk=.d256ba2c-fddc-4b1c-bde5-ceda80f87175@github.com>
Message-ID: <1_os7tMNpV8dN81M_TSJW1iRI3J7vYpmINEtaqZH9yE=.515bf952-a673-47b9-a4ab-b96051f004d9@github.com>

On Fri, 17 May 2024 06:07:47 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> Some tests are not migrated to the ClassFile API in previous migrations.
>> 
>>  - Some are simple oversights that didn't remove usages of com.sun.tools.classfile;
>>  - The CallerSensitive ones used an old utility, replaced by CF API-based new code;
>>  - many in javac are because the files are compiled with older source compatibility. Those patches are converted to have the source code stored in text blocks and compiled within tests using `ToolBox#writeJavaFiles` and `CompilerUtils.compile`;
>>  - As described in the JBS issue, there are a few other tests not covered; one is in #19193 while the others are blocked by CreateSymbols migration or bugs.
>> 
>> Testing: all modified tests pass.
>
> test/jdk/jdk/internal/reflect/CallerSensitive/CallerSensitiveFinder.java line 125:
> 
>> 123:                         && invoke.method() instanceof MethodRefEntry ref
>> 124:                         && ref.owner().name().equalsString(className)
>> 125:                         && ref.name().equalsString(methodName)) {
> 
> Is this additional test necessary, I don't see it in the original test.

This was part of the now-removed ReferenceFinder logic; it scans cp as a fast path and then does instruction scan for all methods to find relevant methods to pass to visitor.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19206#discussion_r1604402631

From liach at openjdk.org  Fri May 17 06:24:03 2024
From: liach at openjdk.org (Chen Liang)
Date: Fri, 17 May 2024 06:24:03 GMT
Subject: RFR: 8332109: Convert remaining tests using
 com.sun.tools.classfile to ClassFile API
In-Reply-To: <HkgGsgbB-bNXIYrREDFqpA6NGapnqca6d0ZnSZCQh9w=.1b45aeba-81d8-4e53-9531-1225ec2acc1c@github.com>
References: <argrcg0iKCFTZJz-mOA_OXkVPbyy0Z5Qb4L2g0Qc4gw=.637a0870-77b0-49da-9aee-ffa39ba68c5f@github.com>
 <HkgGsgbB-bNXIYrREDFqpA6NGapnqca6d0ZnSZCQh9w=.1b45aeba-81d8-4e53-9531-1225ec2acc1c@github.com>
Message-ID: <oJ8ZbB59Z--ruPwJtXsJ2VgghfohxL88TLZ-ONZDWh4=.cc8e145d-fc49-4f2c-b532-4a1552cfe4bb@github.com>

On Fri, 17 May 2024 06:03:00 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> Some tests are not migrated to the ClassFile API in previous migrations.
>> 
>>  - Some are simple oversights that didn't remove usages of com.sun.tools.classfile;
>>  - The CallerSensitive ones used an old utility, replaced by CF API-based new code;
>>  - many in javac are because the files are compiled with older source compatibility. Those patches are converted to have the source code stored in text blocks and compiled within tests using `ToolBox#writeJavaFiles` and `CompilerUtils.compile`;
>>  - As described in the JBS issue, there are a few other tests not covered; one is in #19193 while the others are blocked by CreateSymbols migration or bugs.
>> 
>> Testing: all modified tests pass.
>
> test/jdk/jdk/internal/reflect/CallerSensitive/CheckCSMs.java line 151:
> 
>> 149: 
>> 150:             boolean needsCsm = false;
>> 151:             for (var element : code) {
> 
> Scanning the instructions is a bit different approach than in the original test.

Same as the other method name check, it was manually extracted ReferenceFinder logic, we should retire ReferenceFinder with the old class file library.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19206#discussion_r1604405594

From alanb at openjdk.org  Fri May 17 06:24:07 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 17 May 2024 06:24:07 GMT
Subject: RFR: 8330542: Add jaxp-strict.properties in preparation for a
 secure by default configuration [v8]
In-Reply-To: <WaojCmjwxI30LQExFov5KlAMiJVqJC7RqZLMtmAOCFc=.2cbfbcc6-6015-43aa-bcc7-5e1bba4b75dd@github.com>
References: <v1bAYKgH9zfooXpvnBw4Vu2TIqHuKqqtSmgB0hiNp-Q=.31661a99-ecfc-4a05-8045-67b5f680db60@github.com>
 <WaojCmjwxI30LQExFov5KlAMiJVqJC7RqZLMtmAOCFc=.2cbfbcc6-6015-43aa-bcc7-5e1bba4b75dd@github.com>
Message-ID: <AXkSTp1eOOCrq4s9xf80zZl9VK9fz_RuxfLBlSK4wRU=.46eebf93-6a96-4ad3-ae2a-fff47078f7ca@github.com>

On Thu, 16 May 2024 22:20:39 GMT, Joe Wang <joehw at openjdk.org> wrote:

>> Add two sample configuration files:
>> 
>>   jaxp-strict.properties: used to set strict configuration, stricter than jaxp.properties in previous versions such as JDK 22
>> 
>>>   jaxp-compat.properties: used to regain compatibility from any more restricted configuration than previous versions such as JDK 22
>> 
>> Updated 5/16/2024
>> 
>> Design change:
>> The design is changed to include in the JDK two configuration files that are the default jaxp.properties and jaxp-strict.properties, instead of three, dropping jaxp-compat.properties.
>
> Joe Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove jaxp-compat.properties from the list

src/java.xml/share/conf/jaxp-strict.properties line 9:

> 7: # test the more secure/strict behavior, identify issues such as a processor
> 8: # unknowingly makes outbound network connections to fetch DTD, or processes XML
> 9: # that relies on extension functions.

There isn't a JEP to propose that XML processing be secure by default on the technical roadmap right now so I think this paragraph will need to be tweaked to avoid making any assumptions. I think just say that the file provides the settings for more secure XML processing and drop the text about testing (and "and create your own configuration file for the experiment" from the paragraph below).

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18831#discussion_r1604405287

From jpai at openjdk.org  Fri May 17 06:26:12 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 17 May 2024 06:26:12 GMT
Subject: RFR: 8173970: jar tool should have a way to extract to a directory
 [v5]
In-Reply-To: <APZvm76TDV-TwhV7PpsP9aTpdE9AmdcaU3zVCbHuv7U=.c53bf4f5-da9f-4c6a-8242-4e18c8551885@github.com>
References: <MRlQpBJcCaZSMcnssPw88TaYd2cAwiJOkfI4k8hXM0E=.76718687-c714-4d12-a03b-fa0fdb51a9ff@github.com>
 <APZvm76TDV-TwhV7PpsP9aTpdE9AmdcaU3zVCbHuv7U=.c53bf4f5-da9f-4c6a-8242-4e18c8551885@github.com>
Message-ID: <KJYBab6BvGbfcOl-gfnkDNEsr-0z8qYXBLv_0oYcoj0=.bff2a08f-84d5-40c8-8199-e10a46a87a03@github.com>

On Wed, 8 May 2024 05:37:24 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review for this patch which proposes to implement the enhancement request noted in https://bugs.openjdk.java.net/browse/JDK-8173970?
>> 
>> The commit in this PR introduces the `-o` and `--output-dir` option to the `jar` command. The option takes a path to a destination directory as a value and extracts the contents of the jar into that directory. This is an optional option and the changes in the commit continue to maintain backward compatibility where the jar is extracted into current directory, if no `-o` or `--output-dir` option has been specified.
>> 
>> As far as I know, there hasn't been any discussion on what the name of this new option should be. I was initially thinking of using `-d` but that is currently used by the `jar` command for a different purpose. So I decided to use `-o` and `--output-dir`. This is of course open for change depending on any suggestions in this PR.
>> 
>> The commit in this PR also updates the `jar.properties` file which contains the English version of the jar command's `--help` output. However, no changes have been done to the internationalization files corresponding to this one (for example: `jar_de.properties`), because I don't know what process needs to be followed to have those files updated (if at all they need to be updated).
>> 
>> The commit also includes a jtreg testcase which verifies the usage of this new option.
>
> Jaikiran Pai has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 15 commits:
> 
>  - cleanup testExtractNoDestDirWithPFlag() test
>  - merge latest from master branch
>  - merge latest from master branch
>  - convert the new test to junit
>  - merge latest from master branch
>  - Lance's review - include tests for --extract long form option
>  - cleanup after each test
>  - Adjust test for new error messages
>  - Lance's review - add a code comment for xdestDir
>  - Lance's review - updates to the help messages in jar.properties
>  - ... and 5 more: https://git.openjdk.org/jdk/compare/3b8227ba...46fb5a8e

I've also updated the CSR https://bugs.openjdk.org/browse/JDK-8264510 for review. That CSR would be the best place to get up to speed with this proposed enhancement and the semantics of the new option.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/2752#issuecomment-2116836829

From pminborg at openjdk.org  Fri May 17 06:27:11 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Fri, 17 May 2024 06:27:11 GMT
Subject: RFR: 8330465: Stable Values and Collections (Internal) [v16]
In-Reply-To: <JSjxsb9D75KaK_bMcAUi-CWOT5rAnR1m0x79nTRfO8U=.351b3c08-541a-4333-9b1b-f6a447c43511@github.com>
References: <-KSimQo5kkmCzzMShqGe5QZ9yCSzpWL98gN13v4wP0k=.11dd8d06-18a6-4577-8342-66632cea0b6e@github.com>
 <JSjxsb9D75KaK_bMcAUi-CWOT5rAnR1m0x79nTRfO8U=.351b3c08-541a-4333-9b1b-f6a447c43511@github.com>
Message-ID: <79iymLHD3Dl6-yQhDTt9LTHMz0AwZWPy43HZLGk2KA0=.34a3901e-0db4-4421-9c8b-090dafa18abd@github.com>

On Thu, 16 May 2024 12:48:24 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> # Stable Values & Collections (Internal)
>> 
>> ## Summary
>> This PR proposes to introduce an internal _Stable Values & Collections_ API, which provides immutable value holders where elements are initialized _at most once_. Stable Values & Collections offer the performance and safety benefits of final fields while offering greater flexibility as to the timing of initialization.
>> 
>> ## Goals
>>  * Provide an easy and intuitive API to describe value holders that can change at most once.
>>  * Decouple declaration from initialization without significant footprint or performance penalties.
>>  * Reduce the amount of static initializer and/or field initialization code.
>>  * Uphold integrity and consistency, even in a multi-threaded environment.
>>  
>> For more details, see the draft JEP: https://openjdk.org/jeps/8312611
>> 
>> ## Performance 
>> Performance compared to instance variables using two `AtomicReference` and two protected by double-checked locking under concurrent access by all threads:
>> 
>> 
>> Benchmark                                      Mode  Cnt      Score      Error   Units
>> StableBenchmark.atomic                        thrpt   10    259.478 ?   36.809  ops/us
>> StableBenchmark.dcl                           thrpt   10    225.710 ?   26.638  ops/us
>> StableBenchmark.stable                        thrpt   10   4382.478 ? 1151.472  ops/us <- StableValue significantly faster
>> 
>> 
>> Performance compared to static variables protected by `AtomicReference`, class-holder idiom holder, and double-checked locking (all threads):
>> 
>> 
>> Benchmark                                      Mode  Cnt      Score      Error   Units
>> StableStaticBenchmark.atomic                  thrpt   10   6487.835 ?  385.639  ops/us
>> StableStaticBenchmark.dcl                     thrpt   10   6605.239 ?  210.610  ops/us
>> StableStaticBenchmark.stable                  thrpt   10  14338.239 ? 1426.874  ops/us
>> StableStaticBenchmark.staticCHI               thrpt   10  13780.341 ? 1839.651  ops/us
>> 
>> 
>> Performance for stable lists (thread safe) in both instance and static contexts whereby we access a single value compared to `ArrayList` instances (which are not thread-safe) (all threads):
>> 
>> 
>> Benchmark                                      Mode  Cnt      Score      Error   Units
>> StableListElementBenchmark.instanceArrayList  thrpt   10   5812.992 ? 1169.730  ops/us
>> StableListElementBenchmark.instanceList       thrpt   10   4818.643 ?  704.893  ops/us
>> StableListElementBenchmark...
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix copyringht issues

> _Mailing list message from [Olexandr Rotan](mailto:rotanolexandr842 at gmail.com) on [compiler-dev](mailto:compiler-dev at mail.openjdk.org):_
> 
> Is it possible to make stable values and collections Serializable? I see various applications for this feature in entity classes as a way to preserve immutability of entity fields and at the same time not break current JPA specifications. It is a *very* common task in commercial development. Current workarounds lack either thread safety or performance, and this looks like a really good solution for both of those problems. However, unless StableValue is serializable, it is really unlikely that JPA will adopt them (we have precedent with Optional).
> 
> On Thu, May 16, 2024 at 5:07?PM Per Minborg <pminborg at openjdk.org> wrote:
> 
> -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20240516/7fa869a5/attachment-0001.htm>

`Serializable` is on the list to explore.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18794#issuecomment-2116840097

From jpai at openjdk.org  Fri May 17 06:29:31 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 17 May 2024 06:29:31 GMT
Subject: RFR: 8173970: jar tool should have a way to extract to a directory
 [v6]
In-Reply-To: <MRlQpBJcCaZSMcnssPw88TaYd2cAwiJOkfI4k8hXM0E=.76718687-c714-4d12-a03b-fa0fdb51a9ff@github.com>
References: <MRlQpBJcCaZSMcnssPw88TaYd2cAwiJOkfI4k8hXM0E=.76718687-c714-4d12-a03b-fa0fdb51a9ff@github.com>
Message-ID: <ykZxCVzhO_p6iWiZfiKQbryvaJ2HBjlMwFhPDUHfX_I=.a6a228c4-0d39-4639-af91-ab798c036768@github.com>

> Can I please get a review for this patch which proposes to implement the enhancement request noted in https://bugs.openjdk.java.net/browse/JDK-8173970?
> 
> The commit in this PR introduces the `-o` and `--output-dir` option to the `jar` command. The option takes a path to a destination directory as a value and extracts the contents of the jar into that directory. This is an optional option and the changes in the commit continue to maintain backward compatibility where the jar is extracted into current directory, if no `-o` or `--output-dir` option has been specified.
> 
> As far as I know, there hasn't been any discussion on what the name of this new option should be. I was initially thinking of using `-d` but that is currently used by the `jar` command for a different purpose. So I decided to use `-o` and `--output-dir`. This is of course open for change depending on any suggestions in this PR.
> 
> The commit in this PR also updates the `jar.properties` file which contains the English version of the jar command's `--help` output. However, no changes have been done to the internationalization files corresponding to this one (for example: `jar_de.properties`), because I don't know what process needs to be followed to have those files updated (if at all they need to be updated).
> 
> The commit also includes a jtreg testcase which verifies the usage of this new option.

Jaikiran Pai has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 16 commits:

 - merge latest from master branch
 - cleanup testExtractNoDestDirWithPFlag() test
 - merge latest from master branch
 - merge latest from master branch
 - convert the new test to junit
 - merge latest from master branch
 - Lance's review - include tests for --extract long form option
 - cleanup after each test
 - Adjust test for new error messages
 - Lance's review - add a code comment for xdestDir
 - ... and 6 more: https://git.openjdk.org/jdk/compare/9160ef8b...a8aeff60

-------------

Changes: https://git.openjdk.org/jdk/pull/2752/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=2752&range=05
  Stats: 569 lines in 4 files changed: 558 ins; 0 del; 11 mod
  Patch: https://git.openjdk.org/jdk/pull/2752.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/2752/head:pull/2752

PR: https://git.openjdk.org/jdk/pull/2752

From asotona at openjdk.org  Fri May 17 06:30:03 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Fri, 17 May 2024 06:30:03 GMT
Subject: RFR: 8332109: Convert remaining tests using
 com.sun.tools.classfile to ClassFile API
In-Reply-To: <argrcg0iKCFTZJz-mOA_OXkVPbyy0Z5Qb4L2g0Qc4gw=.637a0870-77b0-49da-9aee-ffa39ba68c5f@github.com>
References: <argrcg0iKCFTZJz-mOA_OXkVPbyy0Z5Qb4L2g0Qc4gw=.637a0870-77b0-49da-9aee-ffa39ba68c5f@github.com>
Message-ID: <DsDfWfe6RV91JPPLY3P9Y2ellN8OTqPZzpIwWw8kJOg=.c50fc41c-aa59-4e56-b1e5-d0acc02ec06f@github.com>

On Sun, 12 May 2024 08:36:44 GMT, Chen Liang <liach at openjdk.org> wrote:

> Some tests are not migrated to the ClassFile API in previous migrations.
> 
>  - Some are simple oversights that didn't remove usages of com.sun.tools.classfile;
>  - The CallerSensitive ones used an old utility, replaced by CF API-based new code;
>  - many in javac are because the files are compiled with older source compatibility. Those patches are converted to have the source code stored in text blocks and compiled within tests using `ToolBox#writeJavaFiles` and `CompilerUtils.compile`;
>  - As described in the JBS issue, there are a few other tests not covered; one is in #19193 while the others are blocked by CreateSymbols migration or bugs.
> 
> Testing: all modified tests pass.

Looks good to me, great job, thanks!

-------------

Marked as reviewed by asotona (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19206#pullrequestreview-2062430122

From alanb at openjdk.org  Fri May 17 06:40:03 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 17 May 2024 06:40:03 GMT
Subject: RFR: 8330542: Add jaxp-strict.properties in preparation for a
 secure by default configuration [v8]
In-Reply-To: <WaojCmjwxI30LQExFov5KlAMiJVqJC7RqZLMtmAOCFc=.2cbfbcc6-6015-43aa-bcc7-5e1bba4b75dd@github.com>
References: <v1bAYKgH9zfooXpvnBw4Vu2TIqHuKqqtSmgB0hiNp-Q=.31661a99-ecfc-4a05-8045-67b5f680db60@github.com>
 <WaojCmjwxI30LQExFov5KlAMiJVqJC7RqZLMtmAOCFc=.2cbfbcc6-6015-43aa-bcc7-5e1bba4b75dd@github.com>
Message-ID: <IimdlMVLK8_t5UCysc23pcCkpC9k66vz-0dfXyWDtn4=.a775c0b6-41d5-4adf-b303-4733f17a823d@github.com>

On Thu, 16 May 2024 22:20:39 GMT, Joe Wang <joehw at openjdk.org> wrote:

>> Add two sample configuration files:
>> 
>>   jaxp-strict.properties: used to set strict configuration, stricter than jaxp.properties in previous versions such as JDK 22
>> 
>>>   jaxp-compat.properties: used to regain compatibility from any more restricted configuration than previous versions such as JDK 22
>> 
>> Updated 5/16/2024
>> 
>> Design change:
>> The design is changed to include in the JDK two configuration files that are the default jaxp.properties and jaxp-strict.properties, instead of three, dropping jaxp-compat.properties.
>
> Joe Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove jaxp-compat.properties from the list

src/java.xml/share/classes/module-info.java line 443:

> 441:  *     </ul>
> 442:  *
> 443:  * This file allows deployments to test the more secure/strict behavior,

I think it might be better to reduce this paragraph down to just say something like "Deploying with this configuation prevents processors from unknowingly making outbound network connections to fetch DTDs, or process XML that makes use of extension functions."

We could say that a future JDK release may use a strict configuration by default but that opens the door to questions as to whether the system property is needed, whether jaxp.propeteries is going away, so maybe better to leave that out for now.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18831#discussion_r1604418621

From pminborg at openjdk.org  Fri May 17 06:41:37 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Fri, 17 May 2024 06:41:37 GMT
Subject: RFR: 8330465: Stable Values and Collections (Internal) [v17]
In-Reply-To: <-KSimQo5kkmCzzMShqGe5QZ9yCSzpWL98gN13v4wP0k=.11dd8d06-18a6-4577-8342-66632cea0b6e@github.com>
References: <-KSimQo5kkmCzzMShqGe5QZ9yCSzpWL98gN13v4wP0k=.11dd8d06-18a6-4577-8342-66632cea0b6e@github.com>
Message-ID: <fZBCwpOYX1cTE6LiC4QX3fHcdQa42pPEx2OUxSCFJ1k=.ddead76a-0e25-40d8-bf83-33b1c35f7c46@github.com>

> # Stable Values & Collections (Internal)
> 
> ## Summary
> This PR proposes to introduce an internal _Stable Values & Collections_ API, which provides immutable value holders where elements are initialized _at most once_. Stable Values & Collections offer the performance and safety benefits of final fields while offering greater flexibility as to the timing of initialization.
> 
> ## Goals
>  * Provide an easy and intuitive API to describe value holders that can change at most once.
>  * Decouple declaration from initialization without significant footprint or performance penalties.
>  * Reduce the amount of static initializer and/or field initialization code.
>  * Uphold integrity and consistency, even in a multi-threaded environment.
>  
> For more details, see the draft JEP: https://openjdk.org/jeps/8312611
> 
> ## Performance 
> Performance compared to instance variables using two `AtomicReference` and two protected by double-checked locking under concurrent access by all threads:
> 
> 
> Benchmark                                      Mode  Cnt      Score      Error   Units
> StableBenchmark.atomic                        thrpt   10    259.478 ?   36.809  ops/us
> StableBenchmark.dcl                           thrpt   10    225.710 ?   26.638  ops/us
> StableBenchmark.stable                        thrpt   10   4382.478 ? 1151.472  ops/us <- StableValue significantly faster
> 
> 
> Performance compared to static variables protected by `AtomicReference`, class-holder idiom holder, and double-checked locking (all threads):
> 
> 
> Benchmark                                      Mode  Cnt      Score      Error   Units
> StableStaticBenchmark.atomic                  thrpt   10   6487.835 ?  385.639  ops/us
> StableStaticBenchmark.dcl                     thrpt   10   6605.239 ?  210.610  ops/us
> StableStaticBenchmark.stable                  thrpt   10  14338.239 ? 1426.874  ops/us
> StableStaticBenchmark.staticCHI               thrpt   10  13780.341 ? 1839.651  ops/us
> 
> 
> Performance for stable lists (thread safe) in both instance and static contexts whereby we access a single value compared to `ArrayList` instances (which are not thread-safe) (all threads):
> 
> 
> Benchmark                                      Mode  Cnt      Score      Error   Units
> StableListElementBenchmark.instanceArrayList  thrpt   10   5812.992 ? 1169.730  ops/us
> StableListElementBenchmark.instanceList       thrpt   10   4818.643 ?  704.893  ops/us
> StableListElementBenchmark.staticArrayList    thrpt   10   7614.741 ?  564.777  ops/us
> StableListElementBe...

Per Minborg has updated the pull request incrementally with one additional commit since the last revision:

  Declare field final

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/18794/files
  - new: https://git.openjdk.org/jdk/pull/18794/files/ec7c92cd..35c9252d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18794&range=16
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18794&range=15-16

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/18794.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18794/head:pull/18794

PR: https://git.openjdk.org/jdk/pull/18794

From asotona at openjdk.org  Fri May 17 07:29:12 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Fri, 17 May 2024 07:29:12 GMT
Subject: RFR: 8331855: Convert jdk.jdeps jdeprscan and jdeps to use the
 Classfile API [v2]
In-Reply-To: <-_-sdtKTXy0Heh10jg3IqVT64tVT_2OEvL-l2TmO024=.7a8efbc8-dedb-45c4-b944-cef9ec9dadfb@github.com>
References: <q2IKpwi6HEvLcKtNgKEzkD456bopyXRTliaRIU67C-4=.b77f917c-cb50-4d87-b187-65934954d622@github.com>
 <-_-sdtKTXy0Heh10jg3IqVT64tVT_2OEvL-l2TmO024=.7a8efbc8-dedb-45c4-b944-cef9ec9dadfb@github.com>
Message-ID: <0Hl7UWeUab3H3H7Db6eBC1o29cbepc1o5Q1DPWJROGA=.aa2bf331-ce12-490b-95b2-bb6d8e9a1c20@github.com>

On Sun, 12 May 2024 02:42:32 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Summary of the changes:
>>  - Moved `com.sun.tools.classfile.Dependency` and `Dependencies` to jdeps; they are exclusively used by jdeps in sources, and they are not used in any tests too. This will ease the removal of `com.sun.tools.classfile` later.
>>  - A few visitor patterns have been rewritten with pattern matching, notably in:
>>    - `CPEntries`/`CPSelector` (removed)
>>    - `Dependencies.BasicDependencyFinder.Visitor` has been rewritten to use pattern matching to capture dependencies.
>>  - `MethodSig` and its tests have been removed in favor of `MethodTypeDesc`.
>>  - Otherwise, the changes are mostly mechanical replacements.
>> 
>> All tests in `test/langtools/tools/jdeprscan` and `test/langtools/tools/jdeps` pass.
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Migrate omitted getdeps test in langtools

Looks good to me, thanks!

-------------

Marked as reviewed by asotona (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19193#pullrequestreview-2062523424

From pminborg at openjdk.org  Fri May 17 07:31:39 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Fri, 17 May 2024 07:31:39 GMT
Subject: RFR: 8330465: Stable Values and Collections (Internal) [v18]
In-Reply-To: <-KSimQo5kkmCzzMShqGe5QZ9yCSzpWL98gN13v4wP0k=.11dd8d06-18a6-4577-8342-66632cea0b6e@github.com>
References: <-KSimQo5kkmCzzMShqGe5QZ9yCSzpWL98gN13v4wP0k=.11dd8d06-18a6-4577-8342-66632cea0b6e@github.com>
Message-ID: <F6UhC_BTY17u33BA9H-hWoPDRCRk3Pz1cENlt-_vqQw=.6bde7823-63ac-46da-a418-b72f432bce78@github.com>

> # Stable Values & Collections (Internal)
> 
> ## Summary
> This PR proposes to introduce an internal _Stable Values & Collections_ API, which provides immutable value holders where elements are initialized _at most once_. Stable Values & Collections offer the performance and safety benefits of final fields while offering greater flexibility as to the timing of initialization.
> 
> ## Goals
>  * Provide an easy and intuitive API to describe value holders that can change at most once.
>  * Decouple declaration from initialization without significant footprint or performance penalties.
>  * Reduce the amount of static initializer and/or field initialization code.
>  * Uphold integrity and consistency, even in a multi-threaded environment.
>  
> For more details, see the draft JEP: https://openjdk.org/jeps/8312611
> 
> ## Performance 
> Performance compared to instance variables using two `AtomicReference` and two protected by double-checked locking under concurrent access by all threads:
> 
> 
> Benchmark                                      Mode  Cnt      Score      Error   Units
> StableBenchmark.atomic                        thrpt   10    259.478 ?   36.809  ops/us
> StableBenchmark.dcl                           thrpt   10    225.710 ?   26.638  ops/us
> StableBenchmark.stable                        thrpt   10   4382.478 ? 1151.472  ops/us <- StableValue significantly faster
> 
> 
> Performance compared to static variables protected by `AtomicReference`, class-holder idiom holder, and double-checked locking (all threads):
> 
> 
> Benchmark                                      Mode  Cnt      Score      Error   Units
> StableStaticBenchmark.atomic                  thrpt   10   6487.835 ?  385.639  ops/us
> StableStaticBenchmark.dcl                     thrpt   10   6605.239 ?  210.610  ops/us
> StableStaticBenchmark.stable                  thrpt   10  14338.239 ? 1426.874  ops/us
> StableStaticBenchmark.staticCHI               thrpt   10  13780.341 ? 1839.651  ops/us
> 
> 
> Performance for stable lists (thread safe) in both instance and static contexts whereby we access a single value compared to `ArrayList` instances (which are not thread-safe) (all threads):
> 
> 
> Benchmark                                      Mode  Cnt      Score      Error   Units
> StableListElementBenchmark.instanceArrayList  thrpt   10   5812.992 ? 1169.730  ops/us
> StableListElementBenchmark.instanceList       thrpt   10   4818.643 ?  704.893  ops/us
> StableListElementBenchmark.staticArrayList    thrpt   10   7614.741 ?  564.777  ops/us
> StableListElementBe...

Per Minborg has updated the pull request incrementally with one additional commit since the last revision:

  Simplify StableList

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/18794/files
  - new: https://git.openjdk.org/jdk/pull/18794/files/35c9252d..0f798a70

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18794&range=17
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18794&range=16-17

  Stats: 8 lines in 1 file changed: 0 ins; 4 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/18794.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18794/head:pull/18794

PR: https://git.openjdk.org/jdk/pull/18794

From asotona at openjdk.org  Fri May 17 08:02:07 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Fri, 17 May 2024 08:02:07 GMT
Subject: RFR: 8331724: Refactor j.l.constant implementation to internal
 package [v13]
In-Reply-To: <zuoNJZww8C8zmDH9ik0h6Vr9SvjxwKdgw8bp5pKcxD4=.f07a6409-9298-4690-a339-39d3ff001c02@github.com>
References: <_GPUF9d1E6eBKRxP6bEEqA3LSKRJe2GwCRTfVYbDwFU=.cb482785-e7c4-45f7-bd3a-cd32d466a2cb@github.com>
 <zuoNJZww8C8zmDH9ik0h6Vr9SvjxwKdgw8bp5pKcxD4=.f07a6409-9298-4690-a339-39d3ff001c02@github.com>
Message-ID: <z540O16BeRYRmvidiZ0HTPxu56kEQkFt_O3LI4QitQM=.bc12db22-5bad-46ca-a31f-d73ec7fc1253@github.com>

On Wed, 15 May 2024 11:17:42 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> This PR suggests refactoring the implementation classes of java.lang.constant into a new package jdk.internal.constant to enable sharing some trusted static factory methods with users elsewhere in java.base, such as java.lang.invoke and java.lang.classfile. The refactoring also adds some "trusted" methods for use when input is pre-validated, and makes use of them where applicable in the current implementation. There are more changes in the pipeline which will be folded into #17108 or PR'ed once that is integrated. 
>> 
>> There are two optimizations mixed up here. One in `MethodTypeDesc.ofDescriptor`:
>> 
>> Name                                                             (descString) Cnt     Base     Error      Test   Error  Unit  Change
>> MethodTypeDescFactories.ofDescriptor  (Ljava/lang/Object;Ljava/lang/String;)I   6  138,371 ?   0,767   136,939 ? 1,126 ns/op   1,01x (p = 0,000*)
>> MethodTypeDescFactories.ofDescriptor                                      ()V   6   10,528 ?   2,495     4,110 ? 0,047 ns/op   2,56x (p = 0,000*)
>> MethodTypeDescFactories.ofDescriptor ([IJLjava/lang/String;Z)Ljava/util/List;   6  209,390 ?   4,583   196,175 ? 3,211 ns/op   1,07x (p = 0,000*)
>> MethodTypeDescFactories.ofDescriptor                    ()[Ljava/lang/String;   6   36,039 ?   8,684    20,794 ? 1,110 ns/op   1,73x (p = 0,000*)
>> MethodTypeDescFactories.ofDescriptor                                 (..IIJ)V   6  279,139 ?   6,248   187,934 ? 0,857 ns/op   1,49x (p = 0,000*)
>> MethodTypeDescFactories.ofDescriptor                 (.....................).   6 2174,387 ? 132,879  1150,652 ? 3,158 ns/op   1,89x (p = 0,000*)
>>   * = significant
>> 
>> 
>> The other in `ClassDesc::nested`, where to get rid of a simple static method in `ConstantUtils` I ended up speeding up and simplifying the public factory method:
>> 
>> Name                                      Cnt    Base     Error    Test   Error  Unit  Change
>> ClassDescFactories.ReferenceOnly.ofNested   6 209,853 ? 132,525  22,017 ? 0,573 ns/op   9,53x (p = 0,000*)
>>   * = significant
>> 
>> 
>> The optimizations could be split out and PRd independently, but I think they are simple enough to include in this refactoring.
>
> Claes Redestad has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Update src/java.base/share/classes/java/lang/constant/ClassDesc.java
>    
>    Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com>
>  - Update src/java.base/share/classes/java/lang/constant/ClassDesc.java
>    
>    Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com>

It looks good to me.

-------------

Marked as reviewed by asotona (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19105#pullrequestreview-2062597153

From pminborg at openjdk.org  Fri May 17 08:13:34 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Fri, 17 May 2024 08:13:34 GMT
Subject: RFR: 8330465: Stable Values and Collections (Internal) [v19]
In-Reply-To: <-KSimQo5kkmCzzMShqGe5QZ9yCSzpWL98gN13v4wP0k=.11dd8d06-18a6-4577-8342-66632cea0b6e@github.com>
References: <-KSimQo5kkmCzzMShqGe5QZ9yCSzpWL98gN13v4wP0k=.11dd8d06-18a6-4577-8342-66632cea0b6e@github.com>
Message-ID: <ryfsN88sO2wuoHSY5NFsz0ZjAietfH6XYZ0a39Zv69I=.11d7d994-9c43-4b41-8f7e-641f24f78bb5@github.com>

> # Stable Values & Collections (Internal)
> 
> ## Summary
> This PR proposes to introduce an internal _Stable Values & Collections_ API, which provides immutable value holders where elements are initialized _at most once_. Stable Values & Collections offer the performance and safety benefits of final fields while offering greater flexibility as to the timing of initialization.
> 
> ## Goals
>  * Provide an easy and intuitive API to describe value holders that can change at most once.
>  * Decouple declaration from initialization without significant footprint or performance penalties.
>  * Reduce the amount of static initializer and/or field initialization code.
>  * Uphold integrity and consistency, even in a multi-threaded environment.
>  
> For more details, see the draft JEP: https://openjdk.org/jeps/8312611
> 
> ## Performance 
> Performance compared to instance variables using two `AtomicReference` and two protected by double-checked locking under concurrent access by all threads:
> 
> 
> Benchmark                                      Mode  Cnt      Score      Error   Units
> StableBenchmark.atomic                        thrpt   10    259.478 ?   36.809  ops/us
> StableBenchmark.dcl                           thrpt   10    225.710 ?   26.638  ops/us
> StableBenchmark.stable                        thrpt   10   4382.478 ? 1151.472  ops/us <- StableValue significantly faster
> 
> 
> Performance compared to static variables protected by `AtomicReference`, class-holder idiom holder, and double-checked locking (all threads):
> 
> 
> Benchmark                                      Mode  Cnt      Score      Error   Units
> StableStaticBenchmark.atomic                  thrpt   10   6487.835 ?  385.639  ops/us
> StableStaticBenchmark.dcl                     thrpt   10   6605.239 ?  210.610  ops/us
> StableStaticBenchmark.stable                  thrpt   10  14338.239 ? 1426.874  ops/us
> StableStaticBenchmark.staticCHI               thrpt   10  13780.341 ? 1839.651  ops/us
> 
> 
> Performance for stable lists (thread safe) in both instance and static contexts whereby we access a single value compared to `ArrayList` instances (which are not thread-safe) (all threads):
> 
> 
> Benchmark                                      Mode  Cnt      Score      Error   Units
> StableListElementBenchmark.instanceArrayList  thrpt   10   5812.992 ? 1169.730  ops/us
> StableListElementBenchmark.instanceList       thrpt   10   4818.643 ?  704.893  ops/us
> StableListElementBenchmark.staticArrayList    thrpt   10   7614.741 ?  564.777  ops/us
> StableListElementBe...

Per Minborg has updated the pull request incrementally with one additional commit since the last revision:

  Update ofList and ofMap docs

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/18794/files
  - new: https://git.openjdk.org/jdk/pull/18794/files/0f798a70..dd0ceaf0

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18794&range=18
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18794&range=17-18

  Stats: 12 lines in 1 file changed: 0 ins; 2 del; 10 mod
  Patch: https://git.openjdk.org/jdk/pull/18794.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18794/head:pull/18794

PR: https://git.openjdk.org/jdk/pull/18794

From rgiulietti at openjdk.org  Fri May 17 08:28:15 2024
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Fri, 17 May 2024 08:28:15 GMT
Subject: RFR: 8332086: Remove the usage of ServiceLoader in
 j.u.r.RandomGeneratorFactory [v7]
In-Reply-To: <hfB86NksORc-aC6zVxHel_QQd_9aB629SfQjXvl6q5U=.e31daa4b-5cf6-4f3f-a757-79e818a18978@github.com>
References: <hfB86NksORc-aC6zVxHel_QQd_9aB629SfQjXvl6q5U=.e31daa4b-5cf6-4f3f-a757-79e818a18978@github.com>
Message-ID: <VO_1lN8_gkntTBcwjxAzdXdGJgtdQWWmuVjZG7wfbsI=.1a2f6ff4-b00e-4193-a268-e5744c3d77f0@github.com>

> All random number generator algorithms are implemented in module `java.base`. The usage of `ServiceLoader` in `j.u.r.RandomGeneratorFactory` is no longer needed.

Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:

  SecureRandom added to the table in package documentation.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19212/files
  - new: https://git.openjdk.org/jdk/pull/19212/files/a77146f5..880138d7

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19212&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19212&range=05-06

  Stats: 7 lines in 1 file changed: 7 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/19212.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19212/head:pull/19212

PR: https://git.openjdk.org/jdk/pull/19212

From asotona at openjdk.org  Fri May 17 08:31:06 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Fri, 17 May 2024 08:31:06 GMT
Subject: RFR: 8320396: Class-File API ClassModel::verify should include
 checks from hotspot/share/classfile/classFileParser.cpp [v7]
In-Reply-To: <_691j41TGzd_pv4q8ZqS_XPsbLIb_O-AVxOfPH8YY9A=.1107a250-7e32-42aa-ad1a-9a6fa8e6e3cc@github.com>
References: <0a66asWcJ4_zBrjmReA18BZmsovN1ZeJRRSAPZDMZmo=.5bada03f-d88d-46cd-962d-c1e42c3048c1@github.com>
 <djFxpWMkSwFyS2AOLnX9Jx4sG0_RqxEeA-qBtWjvO9U=.55c71ff2-0597-488a-83f0-f47fe96e79bf@github.com>
 <_691j41TGzd_pv4q8ZqS_XPsbLIb_O-AVxOfPH8YY9A=.1107a250-7e32-42aa-ad1a-9a6fa8e6e3cc@github.com>
Message-ID: <I-u3YvLUbIrdpHhe3NPy06V7LkXph1dPFggAxOr2_-U=.dcdd28c6-8aca-4eaf-b589-573eea8837d2@github.com>

On Wed, 15 May 2024 11:34:37 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   applied the suggested changes
>
> src/java.base/share/classes/jdk/internal/classfile/impl/verifier/ParserVerifier.java line 308:
> 
>> 306:                 0;
>> 307:             default ->
>> 308:                 -1;
> 
> I recommend we explicitly return -1 to skip verification only for UnknownAttribute and CustomAttribute; then our tests can catch missing verification for new attribute additions.

There are still many attributes missing here (yet). However it is a nice goal.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16809#discussion_r1604550145

From jkern at openjdk.org  Fri May 17 08:34:05 2024
From: jkern at openjdk.org (Joachim Kern)
Date: Fri, 17 May 2024 08:34:05 GMT
Subject: Integrated: 8329653: JLILaunchTest fails on AIX after JDK-8329131
In-Reply-To: <y9wItIb8Yr_ZrHfN_kV5lDCp-d-VtYam3MuHX1OxurU=.ce3378d2-90b3-4396-8951-4651439e4f90@github.com>
References: <y9wItIb8Yr_ZrHfN_kV5lDCp-d-VtYam3MuHX1OxurU=.ce3378d2-90b3-4396-8951-4651439e4f90@github.com>
Message-ID: <G6T2hqhanF9GTokDwYk81IrBAtDZmMlsENZysY_3Apc=.3bb5f463-8ca9-461b-a7b0-e9754085444c@github.com>

On Mon, 29 Apr 2024 14:45:07 GMT, Joachim Kern <jkern at openjdk.org> wrote:

> Since ~ end of March, after [JDK-8329131](https://bugs.openjdk.org/browse/JDK-8329131), tools/launcher/JliLaunchTest.java fails on AIX. Failure is :
> 
>  stdout: [];
>  stderr: [Error: could not find libjava.so
> Error: Could not find Java SE Runtime Environment.
> ]
>  exitValue = 2
> 
> java.lang.RuntimeException: Expected to get exit value of [0], exit value is: [2]
> at jdk.test.lib.process.OutputAnalyzer.shouldHaveExitValue(OutputAnalyzer.java:521)
> at JliLaunchTest.main(JliLaunchTest.java:58)
> at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
> at java.base/java.lang.reflect.Method.invoke(Method.java:580)
> at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:333)
> at java.base/java.lang.Thread.run(Thread.java:1575)
> 
> Maybe we need to do further adjustments to BUILD_JDK_JTREG_EXECUTABLES_LIBS_exeJliLaunchTest / BUILD_JDK_JTREG_EXECUTABLES_LDFLAGS_exeJliLaunchTest on AIX ?
> Or somehow adjust the coding that attempts to find parts of "JRE" (libjava.so) ? The libjli.so is gone on AIX after [JDK-8329131](https://bugs.openjdk.org/browse/JDK-8329131), and with this also the image discovery based on GetApplicationHomeFromDll which uses libjli.so .
> 
> Without libjli.so we have to analyze the LD-LIBRARY_PATH / LIBPATH envvar. There is no other methos available on AIX, because it lacks the $ORIGIN feature of the rpath.

This pull request has now been integrated.

Changeset: 14198f50
Author:    Joachim Kern <jkern at openjdk.org>
Committer: Christoph Langer <clanger at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/14198f502f0a721e479adc754a2c7d94b665fbe6
Stats:     55 lines in 3 files changed: 55 ins; 0 del; 0 mod

8329653: JLILaunchTest fails on AIX after JDK-8329131

Reviewed-by: clanger, mdoerr

-------------

PR: https://git.openjdk.org/jdk/pull/19000

From duke at openjdk.org  Fri May 17 08:35:03 2024
From: duke at openjdk.org (Vitaly Provodin)
Date: Fri, 17 May 2024 08:35:03 GMT
Subject: RFR: 8332154: Memory leak in SynchronousQueue
In-Reply-To: <bTv3Bc8P355m7kNSPOd1_ybXXewKB6lvqOwzKtO58cE=.cb6dc72f-ef56-46ca-a5b4-7d821327e6ec@github.com>
References: <Fj3W5LlneHODz3PcBD0Ypu2f34UYvxw1iLLKz5pba-I=.0f419338-0a23-4834-8404-55aeab4b813f@github.com>
 <bTv3Bc8P355m7kNSPOd1_ybXXewKB6lvqOwzKtO58cE=.cb6dc72f-ef56-46ca-a5b4-7d821327e6ec@github.com>
Message-ID: <xNuMSt36GSzcGUpP38jac2ZxKoWeAJDNegBPqdq-PNI=.efd415d8-6d6b-4a76-ba1d-a65723fd7703@github.com>

On Thu, 16 May 2024 15:06:45 GMT, Viktor Klang <vklang at openjdk.org> wrote:

>> Local testing seems to indicate that this fix (which mirrors what's done in the FIFO mode) addresses the problem.
>> 
>> But with that said, I haven't come up with a decent way of adding some form of regression test. Suggestions are most welcome. /cc @DougLea
>
> @AlanBateman @DougLea Reviews are most welcome :)

Hi @viktorklang-ora
The changes was verified as follows
1. Create the script launching the test (from bug description) in a loop and calculating the number of failures. 

cat <<EOF >runme.sh
#!/bin/bash -x

__test_jdk=$1
__test=$2
__count=${3:-20}

i=0
failures=0
while true; do

  ((i=i+1))
  echo i: $i

  $__test_jdk/bin/java \
      --add-opens=java.base/java.util.concurrent=ALL-UNNAMED \
      --add-opens=java.base/java.lang=ALL-UNNAMED \
      $__test || break

  if [ "$i" -ge "$__count" ]; then
    break
  fi
done
EOF


2. Launch the test as follows

bash runme.sh ${test_jdk_home} Main 100

When the test is launched 100 times it is guaranteed to fail in at least one iteration. With this fix no failures were detected in 1000 runs.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19271#issuecomment-2116560270

From alanb at openjdk.org  Fri May 17 09:24:03 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 17 May 2024 09:24:03 GMT
Subject: RFR: 8331876: JFR: Move file read and write events to java.base
 [v5]
In-Reply-To: <0665H6piGNaGJNd0t8bhhQGgrunmvhe3vjfpZ7Bc6gw=.d2ba3ac1-c458-43b5-93f8-6e2df16afd68@github.com>
References: <DDe0bKCC86AawVl7RylZ74uvvLBr2Zljpkcmxx1_WEU=.61cc10c6-b635-42dd-a850-b32ae1d68585@github.com>
 <0665H6piGNaGJNd0t8bhhQGgrunmvhe3vjfpZ7Bc6gw=.d2ba3ac1-c458-43b5-93f8-6e2df16afd68@github.com>
Message-ID: <yfPXmCMdXmdBLbvnI96-wMBr2kLkQAWAUgaakH-VL2Y=.f8bb2e60-35c3-451a-a4f3-8538d77c5e8b@github.com>

On Thu, 16 May 2024 12:10:46 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

>> Hi,
>> 
>> Could I have a review of a change that moves the jdk.FileRead and jdk.FileWrite events to java.base to remove the use of the ASM instrumentation.
>> 
>> Testing: jdk/jdk/jfr
>> 
>> Thanks
>> Erik
>
> Erik Gahlin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove dependency on JFR for retransformation

src/java.base/share/classes/java/io/FileInputStream.java line 65:

> 63:     /**
> 64:      * Flag set by jdk.internal.event.JFRTracing to determines if
> 65:      * file reads should be traced by JFR.

s/determines if/indicate if/

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19129#discussion_r1604617070

From alanb at openjdk.org  Fri May 17 09:24:03 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 17 May 2024 09:24:03 GMT
Subject: RFR: 8331876: JFR: Move file read and write events to java.base
 [v3]
In-Reply-To: <CCtyHkShwKmJTnwnNox5m5ltqXe7P-q8y8aCC4x9T0Q=.6d6a3f12-4cd1-4ac1-a148-dca708bf9084@github.com>
References: <DDe0bKCC86AawVl7RylZ74uvvLBr2Zljpkcmxx1_WEU=.61cc10c6-b635-42dd-a850-b32ae1d68585@github.com>
 <SejX7NAvWNjrhDEN8uDf4oikQDBRclWXDg1fN5FCpkc=.7de48c6f-0af2-4bf4-a743-6e173d950d52@github.com>
 <DgjIOZTfztdSEeODuNZw5MmzsiohA82hhllWCceyPyU=.7bda36a1-e26d-4d7e-822a-e443d3cbc0df@github.com>
 <GmFZAGqKhqSMlAuKsnunFahbx5zJgYvgDG2T5lS_rho=.b6f10942-0d40-4b46-a24d-16a841502c79@github.com>
 <Xpe1ryCbGrBs_N6mgTHYRhMEPLx729S6thLnL40181c=.0c323247-824e-4d2b-83e3-4012361e453d@github.com>
 <2r0EnbX6acRXslQdX0Use8YHoXPVrTnOf40o7e55pI8=.b6c40814-ef1b-4582-a2ea-716c3e90f182@github.com>
 <CCtyHkShwKmJTnwnNox5m5ltqXe7P-q8y8aCC4x9T0Q=.6d6a3f12-4cd1-4ac1-a148-dca708bf9084@github.com>
Message-ID: <PpE9IX8gNBWb39MSuos5c9YcdNdMX4cwnzaJITPXgJQ=.cf8516a0-8279-4c27-8583-c39ea9ea6988@github.com>

On Sun, 12 May 2024 13:35:42 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> I guess it's not 100% safe if the JIT decides to store the read value elsewhere over several event checks, but it seems unlikely. Event settings checks (i.e., Event::isEnabled()) have always used plain reads, so it is not more unreliable than any other event.
> 
> I'm fine with using a volatile too. I used it for the exception events, but I now think a plain write/read of jfrTracing is safe for all practical purposes.

I'd prefer not introduce another volatile read into all these call paths. As you say, the issue has always been there so maybe it's okay for now and it can be examined later.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19129#discussion_r1604619014

From alanb at openjdk.org  Fri May 17 09:29:16 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 17 May 2024 09:29:16 GMT
Subject: RFR: 8331876: JFR: Move file read and write events to java.base
 [v3]
In-Reply-To: <hCLpZtC0PzTKDqSFbBympxsb4A3Sta3G3N2Ec8JfsSs=.2c57b9ff-e81d-42a0-8384-3663b14192ca@github.com>
References: <DDe0bKCC86AawVl7RylZ74uvvLBr2Zljpkcmxx1_WEU=.61cc10c6-b635-42dd-a850-b32ae1d68585@github.com>
 <SejX7NAvWNjrhDEN8uDf4oikQDBRclWXDg1fN5FCpkc=.7de48c6f-0af2-4bf4-a743-6e173d950d52@github.com>
 <DgjIOZTfztdSEeODuNZw5MmzsiohA82hhllWCceyPyU=.7bda36a1-e26d-4d7e-822a-e443d3cbc0df@github.com>
 <khrP38H7DBIyftQZtZt0CRXeH1ZkpOCjiRNvFTs3LSI=.fd62aba9-5153-4521-84e4-241b8a352720@github.com>
 <zGenHEqjgT6f_P_VtwfKbmzBeQoArW8MHwfAa6uVGVY=.eb912b9b-3f02-4cac-8d96-e1bdbaaea2b8@github.com>
 <wluFwF2Nhgjz-yspRYtEXIJ6jEiWm9imPd6CZlwYt6Y=.991f1032-1f5a-4762-8e5b-edc74d513e88@github.com>
 <UBAcBKmhmCkeevxrteAThIEvD8YNBWFrUa_qffEng14=.c50dbe19-3465-4385-9fe4-8c284a0b116e@github.com>
 <hCLpZtC0PzTKDqSFbBympxsb4A3Sta3G3N2Ec8JfsSs=.2c57b9ff-e81d-42a0-8384-3663b14192ca@github.com>
Message-ID: <6jsW4CF22T2JlhtRKmS04_KXxr-aJxIiMyFwzWlM-pU=.b27ed11e-bd19-4823-a795-7f578b812d56@github.com>

On Mon, 13 May 2024 21:00:10 GMT, Stuart Marks <smarks at openjdk.org> wrote:

>>> If an event class is loaded before JFR is started, the event class needs to be retransformed, but if it is loaded later, we can add instrumentation on class load and avoid the retransformation. More happens when an event class is loaded compared to ordinary class load, for example, a startTime field is added.
>>> 
>>> I did a JMH run and the difference between Event::enabled() and a boolean flag was a fraction of nanosecond.
>> 
>> There are instances of FIS/FOS created in initPhase1 for the standard streams so loading as few classes and executing as minimal as possible is good. RAF will typically be used early too as the zip code opens zip files with a RAF. So doing as little as possible is good.
>
> My main concern here is the addition of clutter (checking two flags, and creating two levels of nested "impl" methods) at every call site. We may need to rearrange our internal API for JFR (jdk.internal.events) in order to clean up the call sites without loading additional classes unnecessarily.
> 
> I think the main performance comparison to make is the impact on startup time of loading the additional FileReadEvent class. That is, to compare the startup time of the baseline with code that loads the FileReadEvent class, with JFR disabled in both cases. I don't know how to do this. Anyway, if loading of additional classes imposes unacceptable overhead, then that justifies doing more work to avoid it. That's separate from whether adding the `jfrTracing` flag as done in this PR is an effective way to do it.

I think `if (jfrTracing && FileReadEvent.enabled())` would be more readable as it would avoid calling going through the traceXXX methods when the flag is enabled but the specific event is not enabled.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19129#discussion_r1604627812

From pminborg at openjdk.org  Fri May 17 09:31:33 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Fri, 17 May 2024 09:31:33 GMT
Subject: RFR: 8330465: Stable Values and Collections (Internal) [v20]
In-Reply-To: <-KSimQo5kkmCzzMShqGe5QZ9yCSzpWL98gN13v4wP0k=.11dd8d06-18a6-4577-8342-66632cea0b6e@github.com>
References: <-KSimQo5kkmCzzMShqGe5QZ9yCSzpWL98gN13v4wP0k=.11dd8d06-18a6-4577-8342-66632cea0b6e@github.com>
Message-ID: <kLBsOOVO524jwGiSeA_8W5EwK1uXz0Cp6b_uIbrt_VY=.ee3fbae5-6f6c-45f4-8b62-b9f92a015730@github.com>

> # Stable Values & Collections (Internal)
> 
> ## Summary
> This PR proposes to introduce an internal _Stable Values & Collections_ API, which provides immutable value holders where elements are initialized _at most once_. Stable Values & Collections offer the performance and safety benefits of final fields while offering greater flexibility as to the timing of initialization.
> 
> ## Goals
>  * Provide an easy and intuitive API to describe value holders that can change at most once.
>  * Decouple declaration from initialization without significant footprint or performance penalties.
>  * Reduce the amount of static initializer and/or field initialization code.
>  * Uphold integrity and consistency, even in a multi-threaded environment.
>  
> For more details, see the draft JEP: https://openjdk.org/jeps/8312611
> 
> ## Performance 
> Performance compared to instance variables using two `AtomicReference` and two protected by double-checked locking under concurrent access by all threads:
> 
> 
> Benchmark                                      Mode  Cnt      Score      Error   Units
> StableBenchmark.atomic                        thrpt   10    259.478 ?   36.809  ops/us
> StableBenchmark.dcl                           thrpt   10    225.710 ?   26.638  ops/us
> StableBenchmark.stable                        thrpt   10   4382.478 ? 1151.472  ops/us <- StableValue significantly faster
> 
> 
> Performance compared to static variables protected by `AtomicReference`, class-holder idiom holder, and double-checked locking (all threads):
> 
> 
> Benchmark                                      Mode  Cnt      Score      Error   Units
> StableStaticBenchmark.atomic                  thrpt   10   6487.835 ?  385.639  ops/us
> StableStaticBenchmark.dcl                     thrpt   10   6605.239 ?  210.610  ops/us
> StableStaticBenchmark.stable                  thrpt   10  14338.239 ? 1426.874  ops/us
> StableStaticBenchmark.staticCHI               thrpt   10  13780.341 ? 1839.651  ops/us
> 
> 
> Performance for stable lists (thread safe) in both instance and static contexts whereby we access a single value compared to `ArrayList` instances (which are not thread-safe) (all threads):
> 
> 
> Benchmark                                      Mode  Cnt      Score      Error   Units
> StableListElementBenchmark.instanceArrayList  thrpt   10   5812.992 ? 1169.730  ops/us
> StableListElementBenchmark.instanceList       thrpt   10   4818.643 ?  704.893  ops/us
> StableListElementBenchmark.staticArrayList    thrpt   10   7614.741 ?  564.777  ops/us
> StableListElementBe...

Per Minborg has updated the pull request incrementally with two additional commits since the last revision:

 - Add benchmarks for memoized IntFunction and Function
 - Add benchmark for memoized supplier

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/18794/files
  - new: https://git.openjdk.org/jdk/pull/18794/files/dd0ceaf0..7beab36a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18794&range=19
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18794&range=18-19

  Stats: 356 lines in 3 files changed: 356 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/18794.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18794/head:pull/18794

PR: https://git.openjdk.org/jdk/pull/18794

From alanb at openjdk.org  Fri May 17 09:34:11 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 17 May 2024 09:34:11 GMT
Subject: RFR: 8331671: Implement JEP 472: Prepare to Restrict the Use of
 JNI [v7]
In-Reply-To: <kAq153qNH4hG6IDWoTMrBv9pCPMEZl1pI7-wJQgsI7A=.6588b41b-eb33-49a6-a49d-cca79aaaf180@github.com>
References: <CZGbki5iFdCGPPagE-ya-_L8Nkgf7OunywApOsxC548=.2cee82fa-a5d2-4165-b012-30982a85030a@github.com>
 <kAq153qNH4hG6IDWoTMrBv9pCPMEZl1pI7-wJQgsI7A=.6588b41b-eb33-49a6-a49d-cca79aaaf180@github.com>
Message-ID: <9oh0XZoux2OKBke0T-hr6CS9OsuDD6Wk1HdQdPu2YyY=.1d9a2a75-cb80-498c-86f9-da457669e3e8@github.com>

On Thu, 16 May 2024 12:23:44 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This PR implements [JEP 472](https://openjdk.org/jeps/472), by restricting the use of JNI in the following ways:
>> 
>> * `System::load` and `System::loadLibrary` are now restricted methods
>> * `Runtime::load` and `Runtime::loadLibrary` are now restricted methods
>> * binding a JNI `native` method declaration to a native implementation is now considered a restricted operation
>> 
>> This PR slightly changes the way in which the JDK deals with restricted methods, even for FFM API calls. In Java 22, the single `--enable-native-access` was used both to specify a set of modules for which native access should be allowed *and* to specify whether illegal native access (that is, native access occurring from a module not specified by `--enable-native-access`) should be treated as an error or a warning. More specifically, an error is only issued if the `--enable-native-access flag` is used at least once.
>> 
>> Here, a new flag is introduced, namely `illegal-native-access=allow/warn/deny`, which is used to specify what should happen when access to a restricted method and/or functionality is found outside the set of modules specified with `--enable-native-access`. The default policy is `warn`, but users can select `allow` to suppress the warnings, or `deny` to cause `IllegalCallerException` to be thrown. This aligns the treatment of restricted methods with other mechanisms, such as `--illegal-access` and the more recent `--sun-misc-unsafe-memory-access`.
>> 
>> Some changes were required in the package-info javadoc for `java.lang.foreign`, to reflect the changes in the command line flags described above.
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add note on --illegal-native-access default value in the launcher help

src/java.base/share/classes/java/lang/foreign/package-info.java line 170:

> 168:  * the special value {@code ALL-UNNAMED} can be used). Access to restricted methods
> 169:  * from modules not listed by that option is deemed <em>illegal</em>. Clients can
> 170:  * control how illegal access to restricted method is handled, using the command line

I assume this should be "to a restricted method is handled" or "to restricted methods are handled", either would work here.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19213#discussion_r1604637950

From pminborg at openjdk.org  Fri May 17 09:37:09 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Fri, 17 May 2024 09:37:09 GMT
Subject: RFR: 8330465: Stable Values and Collections (Internal) [v20]
In-Reply-To: <kLBsOOVO524jwGiSeA_8W5EwK1uXz0Cp6b_uIbrt_VY=.ee3fbae5-6f6c-45f4-8b62-b9f92a015730@github.com>
References: <-KSimQo5kkmCzzMShqGe5QZ9yCSzpWL98gN13v4wP0k=.11dd8d06-18a6-4577-8342-66632cea0b6e@github.com>
 <kLBsOOVO524jwGiSeA_8W5EwK1uXz0Cp6b_uIbrt_VY=.ee3fbae5-6f6c-45f4-8b62-b9f92a015730@github.com>
Message-ID: <uN5pZ_2iacuofe2mNQvEI_IY-HZjxvKFTsfa-yxIfI4=.ddfd42db-09c9-4581-8b51-3a6542670acd@github.com>

On Fri, 17 May 2024 09:31:33 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> # Stable Values & Collections (Internal)
>> 
>> ## Summary
>> This PR proposes to introduce an internal _Stable Values & Collections_ API, which provides immutable value holders where elements are initialized _at most once_. Stable Values & Collections offer the performance and safety benefits of final fields while offering greater flexibility as to the timing of initialization.
>> 
>> ## Goals
>>  * Provide an easy and intuitive API to describe value holders that can change at most once.
>>  * Decouple declaration from initialization without significant footprint or performance penalties.
>>  * Reduce the amount of static initializer and/or field initialization code.
>>  * Uphold integrity and consistency, even in a multi-threaded environment.
>>  
>> For more details, see the draft JEP: https://openjdk.org/jeps/8312611
>> 
>> ## Performance 
>> Performance compared to instance variables using two `AtomicReference` and two protected by double-checked locking under concurrent access by all threads:
>> 
>> 
>> Benchmark                                      Mode  Cnt      Score      Error   Units
>> StableBenchmark.atomic                        thrpt   10    259.478 ?   36.809  ops/us
>> StableBenchmark.dcl                           thrpt   10    225.710 ?   26.638  ops/us
>> StableBenchmark.stable                        thrpt   10   4382.478 ? 1151.472  ops/us <- StableValue significantly faster
>> 
>> 
>> Performance compared to static variables protected by `AtomicReference`, class-holder idiom holder, and double-checked locking (all threads):
>> 
>> 
>> Benchmark                                      Mode  Cnt      Score      Error   Units
>> StableStaticBenchmark.atomic                  thrpt   10   6487.835 ?  385.639  ops/us
>> StableStaticBenchmark.dcl                     thrpt   10   6605.239 ?  210.610  ops/us
>> StableStaticBenchmark.stable                  thrpt   10  14338.239 ? 1426.874  ops/us
>> StableStaticBenchmark.staticCHI               thrpt   10  13780.341 ? 1839.651  ops/us
>> 
>> 
>> Performance for stable lists (thread safe) in both instance and static contexts whereby we access a single value compared to `ArrayList` instances (which are not thread-safe) (all threads):
>> 
>> 
>> Benchmark                                      Mode  Cnt      Score      Error   Units
>> StableListElementBenchmark.instanceArrayList  thrpt   10   5812.992 ? 1169.730  ops/us
>> StableListElementBenchmark.instanceList       thrpt   10   4818.643 ?  704.893  ops/us
>> StableListElementBenchmark...
>
> Per Minborg has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Add benchmarks for memoized IntFunction and Function
>  - Add benchmark for memoized supplier

Here are some results of a recently added benchmark that uses a memorized function (with 0 and 1 as input values):

![image](https://github.com/openjdk/jdk/assets/7457876/f2fd5b5a-ac89-483b-acb5-bc5de215417a)

See [test/micro/org/openjdk/bench/java/lang/stable/MemoizedFunctionBenchmark.java for details](https://github.com/minborg/jdk/blob/stable-value/test/micro/org/openjdk/bench/java/lang/stable/MemoizedFunctionBenchmark.java)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18794#issuecomment-2117143526

From amansha at kth.se  Fri May 17 09:40:01 2024
From: amansha at kth.se (Aman Sharma)
Date: Fri, 17 May 2024 09:40:01 +0000
Subject: Deterministic naming of subclasses of `java/lang/reflect/Proxy`
In-Reply-To: <61fbe3d9-9536-4113-adde-6cfc671ba1ee@oracle.com>
References: <bf26eb2f74874e02876b3868311922a9@kth.se>
 <CABe8uE0fk71Xy_PYHikSw9OtXE_i+M9zMbayPEXuTxLWLoy2ag@mail.gmail.com>
 <50405ca9c0a64372bace175b932f9ef7@kth.se>,
 <61fbe3d9-9536-4113-adde-6cfc671ba1ee@oracle.com>
Message-ID: <a860be44e06243799593aa8d67c048cd@kth.se>

Hi Roger,


Do you have ideas on how to intercept them? My javaagent is not able to nor a JVMTI agent passed using `agentpath` option. It also does not seem to show up in logs when I pass `-verbose:class`.


Also, what do you think of renaming the proxy classes as suggested below?


Regards,
Aman Sharma

PhD Student
KTH Royal Institute of Technology
School of Electrical Engineering and Computer Science (EECS)
Department of Theoretical Computer Science (TCS)
<http://www.kth.se><https://www.kth.se/profile/amansha><https://www.kth.se/profile/amansha>
<https://www.kth.se/profile/amansha>https://algomaster99.github.io/
________________________________
From: core-libs-dev <core-libs-dev-retn at openjdk.org> on behalf of Roger Riggs <roger.riggs at oracle.com>
Sent: Friday, May 17, 2024 4:57:46 AM
To: core-libs-dev at openjdk.org
Subject: Re: Deterministic naming of subclasses of `java/lang/reflect/Proxy`

Hi Aman,

You may also run into hidden classes (JEP 371: Hidden Classes) that allow classes to be defined, at runtime, without names.
It has been proposed to use them for generated proxies but that hasn't been implemented yet.
There are benefits to having nameless classes, because they can't be referenced by name, only as a capability, they can be better encapsulated.

fyi, Roger Riggs


On 5/16/24 8:11 AM, Aman Sharma wrote:

Hi,


Thanks for your response, Liang!


> I think you meant CVE-2021-42392 instead of 2022.


Sorry of the error. I indeed meant CVE-2021-42392<https://nvd.nist.gov/vuln/detail/cve-2021-42392>.


> Leyden mainly avoids this unstable generation by performing a training run to collect classes loaded


Would love to know the details of Project Leyden and how they worked so far to focus on this goal. In our case, the training run is the test suite.


> GeneratedConstructorAccessor is already retired by JEP 416 [2] in Java 18


I did see them not appearing in my allowlist when I ran my study subject (Apache PDFBox) with Java 21. Thanks for letting me know about this JEP. I see they are re-implemented with method handles.


> How are you checking the classes?


To detect runtime generated code, we have javaagent that is hooked statically to the test suite execution. It gives us all classes that that is loaded post the JVM and the javaagent are loaded. So we only check the classes loaded for the purpose of running the application. This is also why we did not choose -agentlib as it would give classes for the setting up JVM and javaagent and we the user of our tool must the classes they load.


Next, we have a `ClassFileTransformer` hook in the agent where we produce the checksum using the bytecode. And we compare the checksum with the one existing in the allowlist. The checksum computation algorithm is same for both steps. Let me describe how I compute the checksum.


  1.  I get the CONSTANT_Class_info<https://docs.oracle.com/javase/specs/jvms/se11/html/jvms-4.html#jvms-4.4.1> entry corresponding to `this_class` and rewrite the CONSTANT_Utf8_info<https://docs.oracle.com/javase/specs/jvms/se11/html/jvms-4.html#jvms-4.4.7> corresponding to a fix String constant, say "foo".
  2.  Since, the name of the class is used to refer to its types members (fields/method), I get all CONSTANT_Fieldref_info<https://docs.oracle.com/javase/specs/jvms/se11/html/jvms-4.html#jvms-4.4.2> and if its `class_index` corresponds to the old `this_class`, we rewrite the UTF8 value of class_index to the same constant "foo".
  3.  Next, since the naming of the fields, in Proxy classes, are also suffixed by numbers, for example, `private static Method m4`, we rewrite the UTF8 value of name in the CONSTANT_NameAndType_info<https://docs.oracle.com/javase/specs/jvms/se11/html/jvms-4.html#jvms-4.4.6>.
  4.  These fields can also have a random order so we simply sort the entire byte code using `Arrays.sort(byte[])` to eliminate any differences due to ordering of fields/methods.
  5.  Simply sorting the byte array still had minute differences. I could not understand why they existed even though values in constant pool of the bytecode in allowlist and at runtime were exactly the same after rewriting. The differences existed in the bytes of the Code attribute of methods. I concluded that the bytes stored some position information. To avoid this, I created a subarray where I considered the bytes corresponding to `CONSTANT_Utf8_info.bytes` only. Computing a checksum for it resulted in the same checksums for both classfiles.

Let's understand the whole approach with an example of Proxy class.

`

public final class $Proxy42 extends Proxy implements org.apache.logging.log4j.core.config.plugins.Plugin {

`

The will go in the allowlist as "Proxy_Plugin: <SHA256 checksum>".

When the same class is intercepted at runtime, say "$Proxy10", we look for "Proxy_Plugin" in the allowlist and since the checksum algorithm is same in both cases, we get a match and let the class load.

This approach has seemed to work well for Proxy classes, Generated Constructor Accessor (which is removed as you said). I also looked at the species generated by method handles. I did not notice any modification in them. Their name generation seemed okay to me. If some new Species are generated, it is of course detected since it is not in the allowlist.

I have not looked into LambdaMetafactory because I did not encounter it as a problem so far, but I am aware its name generation is also unstable. I have run my approach only a few projects only. And for hidden classes, I assume the the agent won't be able to intercept them so detecting them would be really hard.


Regards,
Aman Sharma

PhD Student
KTH Royal Institute of Technology
School of Electrical Engineering and Computer Science (EECS)
Department of Theoretical Computer Science (TCS)
<https://www.kth.se/profile/amansha>https://algomaster99.github.io/
________________________________
From: liangchenblue at gmail.com<mailto:liangchenblue at gmail.com> <liangchenblue at gmail.com><mailto:liangchenblue at gmail.com>
Sent: Thursday, May 16, 2024 5:52:03 AM
To: Aman Sharma; core-libs-dev
Cc: Martin Monperrus
Subject: Re: Deterministic naming of subclasses of `java/lang/reflect/Proxy`

Hi Aman,
I think you meant CVE-2021-42392 instead of 2022.

For your approach of an "allowlist" for Java runtime, project Leyden is looking to generate a static image [1], that
> At run time it cannot load classes from outside the image, nor can it create classes dynamically.
Leyden mainly avoids this unstable generation by performing a training run to collect classes loaded and even object graphs; I am not familiar with the details unfortunately.

Otherwise, the Proxy discussion belongs better to core-libs-dev, as java.lang.reflect.Proxy is part of Java's core libraries. I am replying this thread to core-libs-dev.

For your perceived problem that classes don't have unique names, your description sounds dubious: GeneratedConstructorAccessor is already retired by JEP 416 [2] in Java 18, and there are many other cases in which JDK generates classes without stable names, notoriously LambdaMetafactory (Gradle wished for cacheable Lambdas); the same applies for the generated classes for MethodHandle's LambdaForms (which carries implementation code for LambdaForm). How are you checking the classes? It seems you are not checking hidden classes. Proxy and Lambda classes are defined by the caller's class loader, while LambdaForms are under JDK's system class loader I think. We need to ensure you are correctly finding all unstable classes before we can proceed.

[1]: https://openjdk.org/projects/leyden/notes/01-beginnings
[2]: https://openjdk.org/jeps/416

On Wed, May 15, 2024 at 7:00?PM Aman Sharma <amansha at kth.se<mailto:amansha at kth.se>> wrote:

Hi,


My name is Aman and I am a PhD student at KTH Royal Institute of Technology, Stockholm, Sweden. I research as part of CHAINS<https://chains.proj.kth.se/> project to strengthen the software supply chain of multiple ecosystem. I particularly focus on runtime integrity in Java. In this email, I want to write about an issue I have discovered with dynamic generation of `java.lang.reflect.Proxy`classes. I will propose a solution and would love to hear the feedback from the community. Let me know if this is the correct mailing-list for such discussions. It seemed the most relevant from this list<https://mail.openjdk.org/mailman/listinfo>.


My research


Java has features to load class on the fly - it can either download or generate a class at runtime. These features are useful for inner workings of JDK. For example, implementing annotations, reflective access, etc. However, these features have also contributed to critical vulnerabilities in the past - CVE-2021-44228  (log4shell), CVE-2022-33980, CVE-2022-42392. All of these vulnerabilities have one thing in common - a class that was not known during build time was downloaded/generated at runtime and loaded into JVM.


To defend against such vulnerabilities, we propose a solution to allowlist classes for runtime. This allowlist will contain an exhaustive list of classes that can be loaded by the JVM and it will be enforced at runtime. We build this allowlist from three sources:

  1.  All classes of all modules provided by the Java Standard Library. We use ClassGraph<https://github.com/classgraph/classgraph> to scan the JDK.
  2.  We can take the source code and all dependencies of an application. We use a software bill of materials to get all the data.
  3.  Finally, we use run the test suite to include any runtime downloaded/generated classes.

Such a list is able to prevent the above 3 CVEs because it does not let the "unknown" bytecode to be loaded.

Problem with generating such an allowlist

The first two parts of the allowlist are easy to get. The problem is with the third step where we want to allowlist all the classes that could be downloaded or generated. Upon running the test suite and hooking to the classes it loads, we observer that the list consists of classes that are called "com/sun/proxy/$Proxy2", "jdk/internal/reflect/GeneratedConstructorAccessor3" among many more. The purpose of these classes can be identifed. The proxy class is created for to implement an annotation. The accessor gives access to constructor of a class to the JVM.

When enforcing this allowlist at runtime, we see that the bytecode content for "com/sun/proxy/$Proxy2" differs in the allowlist and at runtime. In our case, we we are experimenting with pdfbox<https://github.com/apache/pdfbox> so we created the allowlist using its test suite. Then we enforced this allowlist while running some of its subcommands. However, there was some other proxy class say "com/sun/proxy/$Proxy5" at runtime that implemented the same interfaces and had the same methods as "com/sun/proxy/$Proxy2" in the allowlist. They only differed in the name of the class, order of fields, and types for fields references. This could happen because the order of the loading of class is workload dependent, but it causes problem to generate such an allowlist.

Solution

We propose that naming of subclasses of "java/lang/reflect/Proxy" should not be dependent upon the order of loading. In order to do so, two issues can be fixed:

  1.  The naming of the class should not be based on AtomicLong<https://github.com/openjdk/jdk/blob/b687aa550837830b38f0f0faa69c353b1e85219c/src/java.base/share/classes/java/lang/reflect/Proxy.java#L531>. Rather it could be named based on the interfaces it implements. I also wonder why AtomicLong is chosen in the first place.
  2.  Methods of the interfaces must be in a particular order. Right now, they are not sorted in any particular order<https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/lang/Class.java#L2178>.


These fixes will make proxy class generation deterministic with respect to order of loading and won't be flagged at runtime since the test suite would already detect them.

I would love to hear from the community about these ideas. If in agreement, I would be happy to produce a patch. I have discovered this issue with subclasses of GeneratedConstructorAccessor<https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/jdk/internal/reflect/ConstructorAccessor.java> as well and I imagine it will also apply to some other runtime generated classes. If you disagree, please let me know also. It helps with my research.

I also have PoCs for the above CVEs<https://github.com/chains-project/exploits-for-sbom.exe> and a proof concept tool is being developed under the name sbom.exe<https://github.com/chains-project/sbom.exe> in case any one wonders about the implementation. I would also be happy to explain more.

Regards,
Aman Sharma

PhD Student
KTH Royal Institute of Technology
School of Electrical Engineering and Computer Science (EECS)
Department of Theoretical Computer Science (TCS)
<https://www.kth.se/profile/amansha>https://algomaster99.github.io/

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240517/fd99be2e/attachment-0001.htm>

From alanb at openjdk.org  Fri May 17 09:40:21 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 17 May 2024 09:40:21 GMT
Subject: RFR: 8331671: Implement JEP 472: Prepare to Restrict the Use of
 JNI [v7]
In-Reply-To: <kAq153qNH4hG6IDWoTMrBv9pCPMEZl1pI7-wJQgsI7A=.6588b41b-eb33-49a6-a49d-cca79aaaf180@github.com>
References: <CZGbki5iFdCGPPagE-ya-_L8Nkgf7OunywApOsxC548=.2cee82fa-a5d2-4165-b012-30982a85030a@github.com>
 <kAq153qNH4hG6IDWoTMrBv9pCPMEZl1pI7-wJQgsI7A=.6588b41b-eb33-49a6-a49d-cca79aaaf180@github.com>
Message-ID: <W-o6qMpByBf7fBVE1h-_fFwlI6bTAsGw-4R24hQbBeE=.0a4838db-f222-4155-8bfb-2f8cf52b4eef@github.com>

On Thu, 16 May 2024 12:23:44 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This PR implements [JEP 472](https://openjdk.org/jeps/472), by restricting the use of JNI in the following ways:
>> 
>> * `System::load` and `System::loadLibrary` are now restricted methods
>> * `Runtime::load` and `Runtime::loadLibrary` are now restricted methods
>> * binding a JNI `native` method declaration to a native implementation is now considered a restricted operation
>> 
>> This PR slightly changes the way in which the JDK deals with restricted methods, even for FFM API calls. In Java 22, the single `--enable-native-access` was used both to specify a set of modules for which native access should be allowed *and* to specify whether illegal native access (that is, native access occurring from a module not specified by `--enable-native-access`) should be treated as an error or a warning. More specifically, an error is only issued if the `--enable-native-access flag` is used at least once.
>> 
>> Here, a new flag is introduced, namely `illegal-native-access=allow/warn/deny`, which is used to specify what should happen when access to a restricted method and/or functionality is found outside the set of modules specified with `--enable-native-access`. The default policy is `warn`, but users can select `allow` to suppress the warnings, or `deny` to cause `IllegalCallerException` to be thrown. This aligns the treatment of restricted methods with other mechanisms, such as `--illegal-access` and the more recent `--sun-misc-unsafe-memory-access`.
>> 
>> Some changes were required in the package-info javadoc for `java.lang.foreign`, to reflect the changes in the command line flags described above.
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add note on --illegal-native-access default value in the launcher help

src/java.base/share/classes/jdk/internal/access/JavaLangAccess.java line 288:

> 286:      * throw exception depending on the configuration.
> 287:      */
> 288:     void ensureNativeAccess(Module m, Class<?> owner, String methodName, Class<?> currentClass, boolean jni);

It might be helpful to future maintainers if we put `@param` descriptions for these parameters. I had to re-read Module.enableNativeAccess to remember the difference between the owner class and the current class.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19213#discussion_r1604644767

From alanb at openjdk.org  Fri May 17 09:44:05 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 17 May 2024 09:44:05 GMT
Subject: RFR: 8331671: Implement JEP 472: Prepare to Restrict the Use of
 JNI [v7]
In-Reply-To: <kAq153qNH4hG6IDWoTMrBv9pCPMEZl1pI7-wJQgsI7A=.6588b41b-eb33-49a6-a49d-cca79aaaf180@github.com>
References: <CZGbki5iFdCGPPagE-ya-_L8Nkgf7OunywApOsxC548=.2cee82fa-a5d2-4165-b012-30982a85030a@github.com>
 <kAq153qNH4hG6IDWoTMrBv9pCPMEZl1pI7-wJQgsI7A=.6588b41b-eb33-49a6-a49d-cca79aaaf180@github.com>
Message-ID: <K-ddELjw1PrhIpxriH8mimHSS4zSSzpt-IAoh7D5f3A=.e9b76a6b-b6cb-4e63-93cc-5b06f6aee862@github.com>

On Thu, 16 May 2024 12:23:44 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This PR implements [JEP 472](https://openjdk.org/jeps/472), by restricting the use of JNI in the following ways:
>> 
>> * `System::load` and `System::loadLibrary` are now restricted methods
>> * `Runtime::load` and `Runtime::loadLibrary` are now restricted methods
>> * binding a JNI `native` method declaration to a native implementation is now considered a restricted operation
>> 
>> This PR slightly changes the way in which the JDK deals with restricted methods, even for FFM API calls. In Java 22, the single `--enable-native-access` was used both to specify a set of modules for which native access should be allowed *and* to specify whether illegal native access (that is, native access occurring from a module not specified by `--enable-native-access`) should be treated as an error or a warning. More specifically, an error is only issued if the `--enable-native-access flag` is used at least once.
>> 
>> Here, a new flag is introduced, namely `illegal-native-access=allow/warn/deny`, which is used to specify what should happen when access to a restricted method and/or functionality is found outside the set of modules specified with `--enable-native-access`. The default policy is `warn`, but users can select `allow` to suppress the warnings, or `deny` to cause `IllegalCallerException` to be thrown. This aligns the treatment of restricted methods with other mechanisms, such as `--illegal-access` and the more recent `--sun-misc-unsafe-memory-access`.
>> 
>> Some changes were required in the package-info javadoc for `java.lang.foreign`, to reflect the changes in the command line flags described above.
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add note on --illegal-native-access default value in the launcher help

src/java.base/share/classes/java/lang/ClassLoader.java line 2448:

> 2446:      * Invoked in the VM class linking code.
> 2447:      */
> 2448:     static long findNative(ClassLoader loader, Class<?> clazz, String entryName, String javaName) {

I think this is another place where `@param` descriptions would help as it's not immediately clear that "javaName" is a method name.

src/java.base/share/classes/java/lang/Runtime.java line 39:

> 37: 
> 38: import jdk.internal.access.SharedSecrets;
> 39: import jdk.internal.javac.Restricted;

Runtime has been touched for a while so you'll need to bump the copyright year.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19213#discussion_r1604648529
PR Review Comment: https://git.openjdk.org/jdk/pull/19213#discussion_r1604650293

From alanb at openjdk.org  Fri May 17 09:48:13 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 17 May 2024 09:48:13 GMT
Subject: RFR: 8331671: Implement JEP 472: Prepare to Restrict the Use of
 JNI [v7]
In-Reply-To: <kAq153qNH4hG6IDWoTMrBv9pCPMEZl1pI7-wJQgsI7A=.6588b41b-eb33-49a6-a49d-cca79aaaf180@github.com>
References: <CZGbki5iFdCGPPagE-ya-_L8Nkgf7OunywApOsxC548=.2cee82fa-a5d2-4165-b012-30982a85030a@github.com>
 <kAq153qNH4hG6IDWoTMrBv9pCPMEZl1pI7-wJQgsI7A=.6588b41b-eb33-49a6-a49d-cca79aaaf180@github.com>
Message-ID: <xjxqMo73h5zMqu-HCClmiqySodIWBCGCWfjMa_Y5pa0=.0d5904a7-f027-49b1-bd33-e49ab547551a@github.com>

On Thu, 16 May 2024 12:23:44 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This PR implements [JEP 472](https://openjdk.org/jeps/472), by restricting the use of JNI in the following ways:
>> 
>> * `System::load` and `System::loadLibrary` are now restricted methods
>> * `Runtime::load` and `Runtime::loadLibrary` are now restricted methods
>> * binding a JNI `native` method declaration to a native implementation is now considered a restricted operation
>> 
>> This PR slightly changes the way in which the JDK deals with restricted methods, even for FFM API calls. In Java 22, the single `--enable-native-access` was used both to specify a set of modules for which native access should be allowed *and* to specify whether illegal native access (that is, native access occurring from a module not specified by `--enable-native-access`) should be treated as an error or a warning. More specifically, an error is only issued if the `--enable-native-access flag` is used at least once.
>> 
>> Here, a new flag is introduced, namely `illegal-native-access=allow/warn/deny`, which is used to specify what should happen when access to a restricted method and/or functionality is found outside the set of modules specified with `--enable-native-access`. The default policy is `warn`, but users can select `allow` to suppress the warnings, or `deny` to cause `IllegalCallerException` to be thrown. This aligns the treatment of restricted methods with other mechanisms, such as `--illegal-access` and the more recent `--sun-misc-unsafe-memory-access`.
>> 
>> Some changes were required in the package-info javadoc for `java.lang.foreign`, to reflect the changes in the command line flags described above.
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add note on --illegal-native-access default value in the launcher help

This looks good. Just a few minor comments where future maintainers might appreciate comments that describe parameters.

src/java.base/share/classes/java/lang/Module.java line 332:

> 330:                 String caller = currentClass != null ? currentClass.getName() : "code";
> 331:                 if (jni) {
> 332:                     System.err.printf("""

System.err may change in a running VM. It may be that we will need to change this at some point to use its initial setting. Not suggesting we changing it now but we might have to re-visit this.

-------------

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19213#pullrequestreview-2062832385
PR Review Comment: https://git.openjdk.org/jdk/pull/19213#discussion_r1604653749

From redestad at openjdk.org  Fri May 17 09:52:10 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Fri, 17 May 2024 09:52:10 GMT
Subject: RFR: 8331724: Refactor j.l.constant implementation to internal
 package [v13]
In-Reply-To: <zuoNJZww8C8zmDH9ik0h6Vr9SvjxwKdgw8bp5pKcxD4=.f07a6409-9298-4690-a339-39d3ff001c02@github.com>
References: <_GPUF9d1E6eBKRxP6bEEqA3LSKRJe2GwCRTfVYbDwFU=.cb482785-e7c4-45f7-bd3a-cd32d466a2cb@github.com>
 <zuoNJZww8C8zmDH9ik0h6Vr9SvjxwKdgw8bp5pKcxD4=.f07a6409-9298-4690-a339-39d3ff001c02@github.com>
Message-ID: <vQuRXnk6VLE_0OKcoaOn0MW5PaoxidVfV3LY2x4MMas=.1c374fd1-ab24-4906-843f-195c765203ce@github.com>

On Wed, 15 May 2024 11:17:42 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> This PR suggests refactoring the implementation classes of java.lang.constant into a new package jdk.internal.constant to enable sharing some trusted static factory methods with users elsewhere in java.base, such as java.lang.invoke and java.lang.classfile. The refactoring also adds some "trusted" methods for use when input is pre-validated, and makes use of them where applicable in the current implementation. There are more changes in the pipeline which will be folded into #17108 or PR'ed once that is integrated. 
>> 
>> There are two optimizations mixed up here. One in `MethodTypeDesc.ofDescriptor`:
>> 
>> Name                                                             (descString) Cnt     Base     Error      Test   Error  Unit  Change
>> MethodTypeDescFactories.ofDescriptor  (Ljava/lang/Object;Ljava/lang/String;)I   6  138,371 ?   0,767   136,939 ? 1,126 ns/op   1,01x (p = 0,000*)
>> MethodTypeDescFactories.ofDescriptor                                      ()V   6   10,528 ?   2,495     4,110 ? 0,047 ns/op   2,56x (p = 0,000*)
>> MethodTypeDescFactories.ofDescriptor ([IJLjava/lang/String;Z)Ljava/util/List;   6  209,390 ?   4,583   196,175 ? 3,211 ns/op   1,07x (p = 0,000*)
>> MethodTypeDescFactories.ofDescriptor                    ()[Ljava/lang/String;   6   36,039 ?   8,684    20,794 ? 1,110 ns/op   1,73x (p = 0,000*)
>> MethodTypeDescFactories.ofDescriptor                                 (..IIJ)V   6  279,139 ?   6,248   187,934 ? 0,857 ns/op   1,49x (p = 0,000*)
>> MethodTypeDescFactories.ofDescriptor                 (.....................).   6 2174,387 ? 132,879  1150,652 ? 3,158 ns/op   1,89x (p = 0,000*)
>>   * = significant
>> 
>> 
>> The other in `ClassDesc::nested`, where to get rid of a simple static method in `ConstantUtils` I ended up speeding up and simplifying the public factory method:
>> 
>> Name                                      Cnt    Base     Error    Test   Error  Unit  Change
>> ClassDescFactories.ReferenceOnly.ofNested   6 209,853 ? 132,525  22,017 ? 0,573 ns/op   9,53x (p = 0,000*)
>>   * = significant
>> 
>> 
>> The optimizations could be split out and PRd independently, but I think they are simple enough to include in this refactoring.
>
> Claes Redestad has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Update src/java.base/share/classes/java/lang/constant/ClassDesc.java
>    
>    Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com>
>  - Update src/java.base/share/classes/java/lang/constant/ClassDesc.java
>    
>    Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com>

Thanks!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19105#issuecomment-2117171356

From redestad at openjdk.org  Fri May 17 09:52:12 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Fri, 17 May 2024 09:52:12 GMT
Subject: Integrated: 8331724: Refactor j.l.constant implementation to internal
 package
In-Reply-To: <_GPUF9d1E6eBKRxP6bEEqA3LSKRJe2GwCRTfVYbDwFU=.cb482785-e7c4-45f7-bd3a-cd32d466a2cb@github.com>
References: <_GPUF9d1E6eBKRxP6bEEqA3LSKRJe2GwCRTfVYbDwFU=.cb482785-e7c4-45f7-bd3a-cd32d466a2cb@github.com>
Message-ID: <BRpVS_nl9HIUnUcAM6pcSXCPLqR5BUaxwne-up-5G1o=.9da52da8-aec7-43a1-afd4-290399cec63b@github.com>

On Mon, 6 May 2024 14:39:08 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> This PR suggests refactoring the implementation classes of java.lang.constant into a new package jdk.internal.constant to enable sharing some trusted static factory methods with users elsewhere in java.base, such as java.lang.invoke and java.lang.classfile. The refactoring also adds some "trusted" methods for use when input is pre-validated, and makes use of them where applicable in the current implementation. There are more changes in the pipeline which will be folded into #17108 or PR'ed once that is integrated. 
> 
> There are two optimizations mixed up here. One in `MethodTypeDesc.ofDescriptor`:
> 
> Name                                                             (descString) Cnt     Base     Error      Test   Error  Unit  Change
> MethodTypeDescFactories.ofDescriptor  (Ljava/lang/Object;Ljava/lang/String;)I   6  138,371 ?   0,767   136,939 ? 1,126 ns/op   1,01x (p = 0,000*)
> MethodTypeDescFactories.ofDescriptor                                      ()V   6   10,528 ?   2,495     4,110 ? 0,047 ns/op   2,56x (p = 0,000*)
> MethodTypeDescFactories.ofDescriptor ([IJLjava/lang/String;Z)Ljava/util/List;   6  209,390 ?   4,583   196,175 ? 3,211 ns/op   1,07x (p = 0,000*)
> MethodTypeDescFactories.ofDescriptor                    ()[Ljava/lang/String;   6   36,039 ?   8,684    20,794 ? 1,110 ns/op   1,73x (p = 0,000*)
> MethodTypeDescFactories.ofDescriptor                                 (..IIJ)V   6  279,139 ?   6,248   187,934 ? 0,857 ns/op   1,49x (p = 0,000*)
> MethodTypeDescFactories.ofDescriptor                 (.....................).   6 2174,387 ? 132,879  1150,652 ? 3,158 ns/op   1,89x (p = 0,000*)
>   * = significant
> 
> 
> The other in `ClassDesc::nested`, where to get rid of a simple static method in `ConstantUtils` I ended up speeding up and simplifying the public factory method:
> 
> Name                                      Cnt    Base     Error    Test   Error  Unit  Change
> ClassDescFactories.ReferenceOnly.ofNested   6 209,853 ? 132,525  22,017 ? 0,573 ns/op   9,53x (p = 0,000*)
>   * = significant
> 
> 
> The optimizations could be split out and PRd independently, but I think they are simple enough to include in this refactoring.

This pull request has now been integrated.

Changeset: 0b0445be
Author:    Claes Redestad <redestad at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/0b0445be2833286b4eace698b91a658de3e7608b
Stats:     1969 lines in 26 files changed: 1028 ins; 856 del; 85 mod

8331724: Refactor j.l.constant implementation to internal package

Reviewed-by: liach, asotona

-------------

PR: https://git.openjdk.org/jdk/pull/19105

From liangchenblue at gmail.com  Fri May 17 11:23:43 2024
From: liangchenblue at gmail.com (-)
Date: Fri, 17 May 2024 06:23:43 -0500
Subject: Deterministic naming of subclasses of `java/lang/reflect/Proxy`
In-Reply-To: <a860be44e06243799593aa8d67c048cd@kth.se>
References: <bf26eb2f74874e02876b3868311922a9@kth.se>
 <CABe8uE0fk71Xy_PYHikSw9OtXE_i+M9zMbayPEXuTxLWLoy2ag@mail.gmail.com>
 <50405ca9c0a64372bace175b932f9ef7@kth.se>
 <61fbe3d9-9536-4113-adde-6cfc671ba1ee@oracle.com>
 <a860be44e06243799593aa8d67c048cd@kth.se>
Message-ID: <CABe8uE115=DzYCdnvNazqFuuxtJoZnv9wRUkFA4-PS7g41QLMw@mail.gmail.com>

Hi Aman,
For `-verbose:class`, it's a JVM argument instead of a program argument; so
when you run a java program like `java Main`, you should call it as `java
-verbose:class Main`.
When done correctly, you should see hidden class outputs like:
[0.032s][info][class,load]
java.lang.invoke.LambdaForm$MH/0x00000200cc000400 source:
__JVM_LookupDefineClass__
The loading of java.lang.invoke hidden classes requires your program to use
MethodHandle features, like a lambda.

I think the problem you are exploring, that to avoid dynamic class loading
and effectively turn Java Platform closed for security, is also being
accomplished by project Leyden (as I've shared initially); Thus, I am
forwarding this to leyden-dev instead, so you can see what approach Leyden
uses to accomplish the same goal as yours.

Regards, Chen Liang

On Fri, May 17, 2024 at 4:40?AM Aman Sharma <amansha at kth.se> wrote:

> Hi Roger,
>
>
> Do you have ideas on how to intercept them? My javaagent is not able to
> nor a JVMTI agent passed using `agentpath` option. It also does not seem to
> show up in logs when I pass `-verbose:class`.
>
>
> Also, what do you think of renaming the proxy classes as suggested below?
>
>
> Regards,
> Aman Sharma
>
> PhD Student
> KTH Royal Institute of Technology
> School of Electrical Engineering and Computer Science (EECS)
> Department of Theoretical Computer Science (TCS)
> <http://www.kth.se> <https://www.kth.se/profile/amansha>
> <https://www.kth.se/profile/amansha>
> <https://www.kth.se/profile/amansha>https://algomaster99.github.io/
> ------------------------------
> *From:* core-libs-dev <core-libs-dev-retn at openjdk.org> on behalf of Roger
> Riggs <roger.riggs at oracle.com>
> *Sent:* Friday, May 17, 2024 4:57:46 AM
> *To:* core-libs-dev at openjdk.org
> *Subject:* Re: Deterministic naming of subclasses of
> `java/lang/reflect/Proxy`
>
> Hi Aman,
>
> You may also run into hidden classes (JEP 371: Hidden Classes) that allow
> classes to be defined, at runtime, without names.
> It has been proposed to use them for generated proxies but that hasn't
> been implemented yet.
> There are benefits to having nameless classes, because they can't be
> referenced by name, only as a capability, they can be better encapsulated.
>
> fyi, Roger Riggs
>
>
> On 5/16/24 8:11 AM, Aman Sharma wrote:
>
> Hi,
>
>
> Thanks for your response, Liang!
>
>
> > I think you meant CVE-2021-42392 instead of 2022.
>
>
> Sorry of the error. I indeed meant CVE-2021-42392
> <https://nvd.nist.gov/vuln/detail/cve-2021-42392>.
>
>
> > Leyden mainly avoids this unstable generation by performing a training
> run to collect classes loaded
>
>
> Would love to know the details of Project Leyden and how they worked so
> far to focus on this goal. In our case, the training run is the test suite.
>
>
> > GeneratedConstructorAccessor is already retired by JEP 416 [2] in Java
> 18
>
>
> I did see them not appearing in my allowlist when I ran my study subject
> (Apache PDFBox) with Java 21. Thanks for letting me know about this JEP. I
> see they are re-implemented with method handles.
>
>
> > How are you checking the classes?
>
>
> To detect runtime generated code, we have javaagent that is hooked
> statically to the test suite execution. It gives us all classes that that
> is loaded post the JVM and the javaagent are loaded. So we only check the
> classes loaded for the purpose of running the application. This is also why
> we did not choose -agentlib as it would give classes for the setting up JVM
> and javaagent and we the user of our tool must the classes they load.
>
>
> Next, we have a `ClassFileTransformer` hook in the agent where we produce
> the checksum using the bytecode. And we compare the checksum with the one
> existing in the allowlist. The checksum computation algorithm is same for
> both steps. Let me describe how I compute the checksum.
>
>
>
>    1. I get the CONSTANT_Class_info
>    <https://docs.oracle.com/javase/specs/jvms/se11/html/jvms-4.html#jvms-4.4.1>
>    entry corresponding to `this_class` and rewrite the CONSTANT_Utf8_info
>    <https://docs.oracle.com/javase/specs/jvms/se11/html/jvms-4.html#jvms-4.4.7>
>    corresponding to a fix String constant, say "foo".
>    2. Since, the name of the class is used to refer to its types members
>    (fields/method), I get all CONSTANT_Fieldref_info
>    <https://docs.oracle.com/javase/specs/jvms/se11/html/jvms-4.html#jvms-4.4.2>
>    and if its `class_index` corresponds to the old `this_class`, we rewrite
>    the UTF8 value of class_index to the same constant "foo".
>    3. Next, since the naming of the fields, in Proxy classes, are also
>    suffixed by numbers, for example, `private static Method m4`, we rewrite
>    the UTF8 value of name in the CONSTANT_NameAndType_info
>    <https://docs.oracle.com/javase/specs/jvms/se11/html/jvms-4.html#jvms-4.4.6>.
>
>    4. These fields can also have a random order so we simply sort the
>    entire byte code using `Arrays.sort(byte[])` to eliminate any differences
>    due to ordering of fields/methods.
>    5. Simply sorting the byte array still had minute differences. I could
>    not understand why they existed even though values in constant pool of the
>    bytecode in allowlist and at runtime were exactly the same after rewriting.
>    The differences existed in the bytes of the Code attribute of methods. I
>    concluded that the bytes stored some position information. To avoid this, I
>    created a subarray where I considered the bytes corresponding to `
>    CONSTANT_Utf8_info.bytes` only. Computing a checksum for it resulted
>    in the same checksums for both classfiles.
>
>
> Let's understand the whole approach with an example of Proxy class.
>
> `
>
> public final class $Proxy42 extends Proxy implements org.apache.logging.log4j.core.config.plugins.Plugin {
>
> `
>
> The will go in the allowlist as "Proxy_Plugin: <SHA256 checksum>".
>
> When the same class is intercepted at runtime, say "$Proxy10", we look for
> "Proxy_Plugin" in the allowlist and since the checksum algorithm is same in
> both cases, we get a match and let the class load.
>
> This approach has seemed to work well for Proxy classes, Generated
> Constructor Accessor (which is removed as you said). I also looked at the
> species generated by method handles. I did not notice any modification in
> them. Their name generation seemed okay to me. If some new Species are
> generated, it is of course detected since it is not in the allowlist.
>
> I have not looked into LambdaMetafactory because I did not encounter it as
> a problem so far, but I am aware its name generation is also unstable. I
> have run my approach only a few projects only. And for hidden classes, I
> assume the the agent won't be able to intercept them so detecting them
> would be really hard.
>
>
> Regards,
> Aman Sharma
>
> PhD Student
> KTH Royal Institute of Technology
> School of Electrical Engineering and Computer Science (EECS)
> Department of Theoretical Computer Science (TCS)
> <https://www.kth.se/profile/amansha>https://algomaster99.github.io/
> ------------------------------
> *From:* liangchenblue at gmail.com <liangchenblue at gmail.com>
> <liangchenblue at gmail.com>
> *Sent:* Thursday, May 16, 2024 5:52:03 AM
> *To:* Aman Sharma; core-libs-dev
> *Cc:* Martin Monperrus
> *Subject:* Re: Deterministic naming of subclasses of
> `java/lang/reflect/Proxy`
>
> Hi Aman,
> I think you meant CVE-2021-42392 instead of 2022.
>
> For your approach of an "allowlist" for Java runtime, project Leyden is
> looking to generate a static image [1], that
> > At run time it cannot load classes from outside the image, nor can it
> create classes dynamically.
> Leyden mainly avoids this unstable generation by performing a training run
> to collect classes loaded and even object graphs; I am not familiar with
> the details unfortunately.
>
> Otherwise, the Proxy discussion belongs better to core-libs-dev, as
> java.lang.reflect.Proxy is part of Java's core libraries. I am replying
> this thread to core-libs-dev.
>
> For your perceived problem that classes don't have unique names, your
> description sounds dubious: GeneratedConstructorAccessor is already retired
> by JEP 416 [2] in Java 18, and there are many other cases in which JDK
> generates classes without stable names, notoriously LambdaMetafactory
> (Gradle wished for cacheable Lambdas); the same applies for the generated
> classes for MethodHandle's LambdaForms (which carries implementation code
> for LambdaForm). How are you checking the classes? It seems you are not
> checking hidden classes. Proxy and Lambda classes are defined by the
> caller's class loader, while LambdaForms are under JDK's system class
> loader I think. We need to ensure you are correctly finding all unstable
> classes before we can proceed.
>
> [1]: https://openjdk.org/projects/leyden/notes/01-beginnings
> [2]: https://openjdk.org/jeps/416
>
> On Wed, May 15, 2024 at 7:00?PM Aman Sharma <amansha at kth.se> wrote:
>
>> Hi,
>>
>>
>> My name is Aman and I am a PhD student at KTH Royal Institute of
>> Technology, Stockholm, Sweden. I research as part of CHAINS
>> <https://chains.proj.kth.se/> project to strengthen the software supply
>> chain of multiple ecosystem. I particularly focus on runtime integrity in
>> Java. In this email, I want to write about an issue I have discovered with *dynamic
>> generation of `java.lang.reflect.Proxy`classes*. I will propose a
>> solution and would love to hear the feedback from the community. Let me
>> know if this is the correct mailing-list for such discussions. It seemed
>> the most relevant from this list
>> <https://mail.openjdk.org/mailman/listinfo>.
>>
>>
>> *My research*
>>
>>
>> Java has features to load class on the fly - it can either download or
>> generate a class at runtime. These features are useful for inner workings
>> of JDK. For example, implementing annotations, reflective access, etc.
>> However, these features have also contributed to critical vulnerabilities
>> in the past - CVE-2021-44228  (log4shell), CVE-2022-33980, CVE-2022-42392.
>> All of these vulnerabilities have one thing in common - *a class that
>> was not known during build time was downloaded/generated at runtime and
>> loaded into JVM.*
>>
>>
>> To defend against such vulnerabilities, we propose a solution to *allowlist
>> classes for runtime*. This allowlist will contain an exhaustive list of
>> classes that can be loaded by the JVM and it will be enforced at runtime.
>> We build this allowlist from three sources:
>>
>>    1. All classes of all modules provided by the Java Standard Library.
>>    We use ClassGraph <https://github.com/classgraph/classgraph> to scan
>>    the JDK.
>>    2. We can take the source code and all dependencies of an
>>    application. We use a software bill of materials to get all the data.
>>    3. Finally, we use run the test suite to include any runtime
>>    downloaded/generated classes.
>>
>> Such a list is able to prevent the above 3 CVEs because it does not let
>> the "unknown" bytecode to be loaded.
>>
>> *Problem with generating such an allowlist*
>>
>> The first two parts of the allowlist are easy to get. The problem is with
>> the third step where we want to allowlist all the classes that could be
>> downloaded or generated. Upon running the test suite and hooking to the
>> classes it loads, we observer that the list consists of classes that are
>> called "com/sun/proxy/$Proxy2", "
>> jdk/internal/reflect/GeneratedConstructorAccessor3" among many more. The
>> purpose of these classes can be identifed. The proxy class is created for
>> to implement an annotation. The accessor gives access to constructor of a
>> class to the JVM.
>>
>> When enforcing this allowlist at runtime, we see that the bytecode
>> content for "com/sun/proxy/$Proxy2" differs in the allowlist and at
>> runtime. In our case, we we are experimenting with pdfbox
>> <https://github.com/apache/pdfbox> so we created the allowlist using its
>> test suite. Then we enforced this allowlist while running some of its
>> subcommands. However, there was some other proxy class say "com/sun/proxy/$Proxy5"
>> at runtime that implemented the same interfaces and had the same methods as
>> "com/sun/proxy/$Proxy2" in the allowlist. They only differed in the name
>> of the class, order of fields, and types for fields references. This could
>> happen because the order of the loading of class is workload dependent, but
>> it causes problem to generate such an allowlist.
>>
>>
>> *Solution *
>>
>>
>> We propose that naming of subclasses of "java/lang/reflect/Proxy" should
>> not be dependent upon the order of loading. In order to do so, two issues
>> can be fixed:
>>
>>    1. The naming of the class should not be based on AtomicLong
>>    <https://github.com/openjdk/jdk/blob/b687aa550837830b38f0f0faa69c353b1e85219c/src/java.base/share/classes/java/lang/reflect/Proxy.java#L531>.
>>    Rather it could be named based on the interfaces it implements. I also
>>    wonder why AtomicLong is chosen in the first place.
>>    2. Methods of the interfaces must be in a particular order. Right
>>    now, they are not sorted in any particular order
>>    <https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/lang/Class.java#L2178>
>>    .
>>
>>
>> These fixes will make proxy class generation deterministic with respect
>> to order of loading and won't be flagged at runtime since the test suite
>> would already detect them.
>>
>> I would love to hear from the community about these ideas. If in
>> agreement, I would be happy to produce a patch. I have discovered this
>> issue with subclasses of GeneratedConstructorAccessor
>> <https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/jdk/internal/reflect/ConstructorAccessor.java>
>> as well and I imagine it will also apply to some other runtime generated
>> classes. If you disagree, please let me know also. It helps with my
>> research.
>>
>> I also have PoCs for the above CVEs
>> <https://github.com/chains-project/exploits-for-sbom.exe> and a proof
>> concept tool is being developed under the name sbom.exe
>> <https://github.com/chains-project/sbom.exe> in case any one wonders
>> about the implementation. I would also be happy to explain more.
>>
>> Regards,
>> Aman Sharma
>>
>> PhD Student
>> KTH Royal Institute of Technology
>> School of Electrical Engineering and Computer Science (EECS)
>> Department of Theoretical Computer Science (TCS)
>> <https://www.kth.se/profile/amansha>https://algomaster99.github.io/
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240517/a934a9ee/attachment-0001.htm>

From liach at openjdk.org  Fri May 17 11:29:05 2024
From: liach at openjdk.org (Chen Liang)
Date: Fri, 17 May 2024 11:29:05 GMT
Subject: RFR: 8332109: Convert remaining tests using
 com.sun.tools.classfile to ClassFile API
In-Reply-To: <argrcg0iKCFTZJz-mOA_OXkVPbyy0Z5Qb4L2g0Qc4gw=.637a0870-77b0-49da-9aee-ffa39ba68c5f@github.com>
References: <argrcg0iKCFTZJz-mOA_OXkVPbyy0Z5Qb4L2g0Qc4gw=.637a0870-77b0-49da-9aee-ffa39ba68c5f@github.com>
Message-ID: <734Gj7AQYhL4n_CpCm6U2Y_kpBlvqxoxyHLeZMMhla8=.82619ff5-dea4-48a5-81c5-3e43182be508@github.com>

On Sun, 12 May 2024 08:36:44 GMT, Chen Liang <liach at openjdk.org> wrote:

> Some tests are not migrated to the ClassFile API in previous migrations.
> 
>  - Some are simple oversights that didn't remove usages of com.sun.tools.classfile;
>  - The CallerSensitive ones used an old utility, replaced by CF API-based new code;
>  - many in javac are because the files are compiled with older source compatibility. Those patches are converted to have the source code stored in text blocks and compiled within tests using `ToolBox#writeJavaFiles` and `CompilerUtils.compile`;
>  - As described in the JBS issue, there are a few other tests not covered; one is in #19193 while the others are blocked by CreateSymbols migration or bugs.
> 
> Testing: all modified tests pass.

Thanks for the review!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19206#issuecomment-2117380960

From liach at openjdk.org  Fri May 17 11:29:06 2024
From: liach at openjdk.org (Chen Liang)
Date: Fri, 17 May 2024 11:29:06 GMT
Subject: RFR: 8331855: Convert jdk.jdeps jdeprscan and jdeps to use the
 Classfile API [v2]
In-Reply-To: <-_-sdtKTXy0Heh10jg3IqVT64tVT_2OEvL-l2TmO024=.7a8efbc8-dedb-45c4-b944-cef9ec9dadfb@github.com>
References: <q2IKpwi6HEvLcKtNgKEzkD456bopyXRTliaRIU67C-4=.b77f917c-cb50-4d87-b187-65934954d622@github.com>
 <-_-sdtKTXy0Heh10jg3IqVT64tVT_2OEvL-l2TmO024=.7a8efbc8-dedb-45c4-b944-cef9ec9dadfb@github.com>
Message-ID: <HSgem4hOOwJ9cNB3wSwdlNWrFvfhWAAnASFPugikMKE=.125fd947-8bf1-43f2-baf5-120d825af07f@github.com>

On Sun, 12 May 2024 02:42:32 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Summary of the changes:
>>  - Moved `com.sun.tools.classfile.Dependency` and `Dependencies` to jdeps; they are exclusively used by jdeps in sources, and they are not used in any tests too. This will ease the removal of `com.sun.tools.classfile` later.
>>  - A few visitor patterns have been rewritten with pattern matching, notably in:
>>    - `CPEntries`/`CPSelector` (removed)
>>    - `Dependencies.BasicDependencyFinder.Visitor` has been rewritten to use pattern matching to capture dependencies.
>>  - `MethodSig` and its tests have been removed in favor of `MethodTypeDesc`.
>>  - Otherwise, the changes are mostly mechanical replacements.
>> 
>> All tests in `test/langtools/tools/jdeprscan` and `test/langtools/tools/jdeps` pass.
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Migrate omitted getdeps test in langtools

Thanks for the review!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19193#issuecomment-2117379307

From vklang at openjdk.org  Fri May 17 11:39:32 2024
From: vklang at openjdk.org (Viktor Klang)
Date: Fri, 17 May 2024 11:39:32 GMT
Subject: RFR: 8332154: Memory leak in SynchronousQueue [v2]
In-Reply-To: <Fj3W5LlneHODz3PcBD0Ypu2f34UYvxw1iLLKz5pba-I=.0f419338-0a23-4834-8404-55aeab4b813f@github.com>
References: <Fj3W5LlneHODz3PcBD0Ypu2f34UYvxw1iLLKz5pba-I=.0f419338-0a23-4834-8404-55aeab4b813f@github.com>
Message-ID: <U63_Nqkfx7gQJTHRCvAcQMgcF-4BeevMfHY77tIYppg=.d88425c8-ce13-4f9a-97dc-84bc47c33aff@github.com>

> Local testing seems to indicate that this fix (which mirrors what's done in the FIFO mode) addresses the problem.
> 
> But with that said, I haven't come up with a decent way of adding some form of regression test. Suggestions are most welcome. /cc @DougLea

Viktor Klang has updated the pull request incrementally with one additional commit since the last revision:

  Adding a leak detection test for SynchronousQueue

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19271/files
  - new: https://git.openjdk.org/jdk/pull/19271/files/dfab08e8..f365c5f0

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19271&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19271&range=00-01

  Stats: 64 lines in 1 file changed: 64 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/19271.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19271/head:pull/19271

PR: https://git.openjdk.org/jdk/pull/19271

From vklang at openjdk.org  Fri May 17 11:39:32 2024
From: vklang at openjdk.org (Viktor Klang)
Date: Fri, 17 May 2024 11:39:32 GMT
Subject: RFR: 8332154: Memory leak in SynchronousQueue [v2]
In-Reply-To: <U63_Nqkfx7gQJTHRCvAcQMgcF-4BeevMfHY77tIYppg=.d88425c8-ce13-4f9a-97dc-84bc47c33aff@github.com>
References: <Fj3W5LlneHODz3PcBD0Ypu2f34UYvxw1iLLKz5pba-I=.0f419338-0a23-4834-8404-55aeab4b813f@github.com>
 <U63_Nqkfx7gQJTHRCvAcQMgcF-4BeevMfHY77tIYppg=.d88425c8-ce13-4f9a-97dc-84bc47c33aff@github.com>
Message-ID: <ntsD0-m646inDw7v-eHw2ATBvib7xDp-IZCWDiw3zLU=.d30e4e61-e881-4881-bb8a-26bbe817968f@github.com>

On Fri, 17 May 2024 11:35:55 GMT, Viktor Klang <vklang at openjdk.org> wrote:

>> Local testing seems to indicate that this fix (which mirrors what's done in the FIFO mode) addresses the problem.
>> 
>> But with that said, I haven't come up with a decent way of adding some form of regression test. Suggestions are most welcome. /cc @DougLea
>
> Viktor Klang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adding a leak detection test for SynchronousQueue

test/jdk/java/util/concurrent/tck/SynchronousQueueTest.java line 668:

> 666:     }
> 667: 
> 668:     private void assertDoesntLeak(SynchronousQueue<Object> queue) throws InterruptedException {

@DougLea @AlanBateman Decided to create a memory leak detection test for SynchronousQueue. Of course, it will likely take some time to tune the parameters of it, but if it completes successfully there was no leak of queue items tho...

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19271#discussion_r1604833973

From amansha at kth.se  Fri May 17 11:43:26 2024
From: amansha at kth.se (Aman Sharma)
Date: Fri, 17 May 2024 11:43:26 +0000
Subject: Deterministic naming of subclasses of `java/lang/reflect/Proxy`
In-Reply-To: <CABe8uE115=DzYCdnvNazqFuuxtJoZnv9wRUkFA4-PS7g41QLMw@mail.gmail.com>
References: <bf26eb2f74874e02876b3868311922a9@kth.se>
 <CABe8uE0fk71Xy_PYHikSw9OtXE_i+M9zMbayPEXuTxLWLoy2ag@mail.gmail.com>
 <50405ca9c0a64372bace175b932f9ef7@kth.se>
 <61fbe3d9-9536-4113-adde-6cfc671ba1ee@oracle.com>
 <a860be44e06243799593aa8d67c048cd@kth.se>,
 <CABe8uE115=DzYCdnvNazqFuuxtJoZnv9wRUkFA4-PS7g41QLMw@mail.gmail.com>
Message-ID: <DB7PR02MB35938DCC3A392536B924164AFBEE2@DB7PR02MB3593.eurprd02.prod.outlook.com>

Hi Chen,

> java.lang.invoke.LambdaForm$MH/0x00000200cc000400

I do see this as output when I pass -verbose:class. However, based on my experiments, I have seen that neither an agent passed via 'javaagent' nor an agent passed via 'agentpath' is able to intercept this hidden class.

Also, I was a bit confused since I saw somewhere that the names of hidden classes are null. But thanks for clarifying here.

> avoid dynamic class loading

I don't see dynamic class loading as a problem. I only mind some unstable generation aspects of them which make it hard to verify them based on an allowlist.

For example, if this hidden class is generated with the exact same name and the exact same bytecode during runtime as well, it would be easy to verify it. However, I do see the names are based on some sort of memory address so and I don't know what bytecode it has so I don't have suggestions to make them stable as of now. For Proxy classes, I feel it can be addressed unless you disagree or some involved in Project Leyden does. :) Thank you for forwarding my mail there.

Regards,
Aman Sharma

PhD Student
KTH Royal Institute of Technology
https://algomaster99.github.io/

________________________________
From: liangchenblue at gmail.com <liangchenblue at gmail.com>
Sent: Friday, May 17, 2024 1:23:58 pm
To: Aman Sharma <amansha at kth.se>
Cc: core-libs-dev at openjdk.org <core-libs-dev at openjdk.org>; leyden-dev at openjdk.org <leyden-dev at openjdk.org>
Subject: Re: Deterministic naming of subclasses of `java/lang/reflect/Proxy`

Hi Aman,
For `-verbose:class`, it's a JVM argument instead of a program argument; so when you run a java program like `java Main`, you should call it as `java -verbose:class Main`.
When done correctly, you should see hidden class outputs like:
[0.032s][info][class,load] java.lang.invoke.LambdaForm$MH/0x00000200cc000400 source: __JVM_LookupDefineClass__
The loading of java.lang.invoke hidden classes requires your program to use MethodHandle features, like a lambda.

I think the problem you are exploring, that to avoid dynamic class loading and effectively turn Java Platform closed for security, is also being accomplished by project Leyden (as I've shared initially); Thus, I am forwarding this to leyden-dev instead, so you can see what approach Leyden uses to accomplish the same goal as yours.

Regards, Chen Liang

On Fri, May 17, 2024 at 4:40?AM Aman Sharma <amansha at kth.se<mailto:amansha at kth.se>> wrote:

Hi Roger,


Do you have ideas on how to intercept them? My javaagent is not able to nor a JVMTI agent passed using `agentpath` option. It also does not seem to show up in logs when I pass `-verbose:class`.


Also, what do you think of renaming the proxy classes as suggested below?


Regards,
Aman Sharma

PhD Student
KTH Royal Institute of Technology
School of Electrical Engineering and Computer Science (EECS)
Department of Theoretical Computer Science (TCS)
<http://www.kth.se><https://www.kth.se/profile/amansha><https://www.kth.se/profile/amansha>
<https://www.kth.se/profile/amansha>https://algomaster99.github.io/
________________________________
From: core-libs-dev <core-libs-dev-retn at openjdk.org<mailto:core-libs-dev-retn at openjdk.org>> on behalf of Roger Riggs <roger.riggs at oracle.com<mailto:roger.riggs at oracle.com>>
Sent: Friday, May 17, 2024 4:57:46 AM
To: core-libs-dev at openjdk.org<mailto:core-libs-dev at openjdk.org>
Subject: Re: Deterministic naming of subclasses of `java/lang/reflect/Proxy`

Hi Aman,

You may also run into hidden classes (JEP 371: Hidden Classes) that allow classes to be defined, at runtime, without names.
It has been proposed to use them for generated proxies but that hasn't been implemented yet.
There are benefits to having nameless classes, because they can't be referenced by name, only as a capability, they can be better encapsulated.

fyi, Roger Riggs


On 5/16/24 8:11 AM, Aman Sharma wrote:

Hi,


Thanks for your response, Liang!


> I think you meant CVE-2021-42392 instead of 2022.


Sorry of the error. I indeed meant CVE-2021-42392<https://nvd.nist.gov/vuln/detail/cve-2021-42392>.


> Leyden mainly avoids this unstable generation by performing a training run to collect classes loaded


Would love to know the details of Project Leyden and how they worked so far to focus on this goal. In our case, the training run is the test suite.


> GeneratedConstructorAccessor is already retired by JEP 416 [2] in Java 18


I did see them not appearing in my allowlist when I ran my study subject (Apache PDFBox) with Java 21. Thanks for letting me know about this JEP. I see they are re-implemented with method handles.


> How are you checking the classes?


To detect runtime generated code, we have javaagent that is hooked statically to the test suite execution. It gives us all classes that that is loaded post the JVM and the javaagent are loaded. So we only check the classes loaded for the purpose of running the application. This is also why we did not choose -agentlib as it would give classes for the setting up JVM and javaagent and we the user of our tool must the classes they load.


Next, we have a `ClassFileTransformer` hook in the agent where we produce the checksum using the bytecode. And we compare the checksum with the one existing in the allowlist. The checksum computation algorithm is same for both steps. Let me describe how I compute the checksum.


  1.  I get the CONSTANT_Class_info<https://docs.oracle.com/javase/specs/jvms/se11/html/jvms-4.html#jvms-4.4.1> entry corresponding to `this_class` and rewrite the CONSTANT_Utf8_info<https://docs.oracle.com/javase/specs/jvms/se11/html/jvms-4.html#jvms-4.4.7> corresponding to a fix String constant, say "foo".
  2.  Since, the name of the class is used to refer to its types members (fields/method), I get all CONSTANT_Fieldref_info<https://docs.oracle.com/javase/specs/jvms/se11/html/jvms-4.html#jvms-4.4.2> and if its `class_index` corresponds to the old `this_class`, we rewrite the UTF8 value of class_index to the same constant "foo".
  3.  Next, since the naming of the fields, in Proxy classes, are also suffixed by numbers, for example, `private static Method m4`, we rewrite the UTF8 value of name in the CONSTANT_NameAndType_info<https://docs.oracle.com/javase/specs/jvms/se11/html/jvms-4.html#jvms-4.4.6>.
  4.  These fields can also have a random order so we simply sort the entire byte code using `Arrays.sort(byte[])` to eliminate any differences due to ordering of fields/methods.
  5.  Simply sorting the byte array still had minute differences. I could not understand why they existed even though values in constant pool of the bytecode in allowlist and at runtime were exactly the same after rewriting. The differences existed in the bytes of the Code attribute of methods. I concluded that the bytes stored some position information. To avoid this, I created a subarray where I considered the bytes corresponding to `CONSTANT_Utf8_info.bytes` only. Computing a checksum for it resulted in the same checksums for both classfiles.

Let's understand the whole approach with an example of Proxy class.

`

public final class $Proxy42 extends Proxy implements org.apache.logging.log4j.core.config.plugins.Plugin {

`

The will go in the allowlist as "Proxy_Plugin: <SHA256 checksum>".

When the same class is intercepted at runtime, say "$Proxy10", we look for "Proxy_Plugin" in the allowlist and since the checksum algorithm is same in both cases, we get a match and let the class load.

This approach has seemed to work well for Proxy classes, Generated Constructor Accessor (which is removed as you said). I also looked at the species generated by method handles. I did not notice any modification in them. Their name generation seemed okay to me. If some new Species are generated, it is of course detected since it is not in the allowlist.

I have not looked into LambdaMetafactory because I did not encounter it as a problem so far, but I am aware its name generation is also unstable. I have run my approach only a few projects only. And for hidden classes, I assume the the agent won't be able to intercept them so detecting them would be really hard.


Regards,
Aman Sharma

PhD Student
KTH Royal Institute of Technology
School of Electrical Engineering and Computer Science (EECS)
Department of Theoretical Computer Science (TCS)
<https://www.kth.se/profile/amansha>https://algomaster99.github.io/
________________________________
From: liangchenblue at gmail.com<mailto:liangchenblue at gmail.com> <liangchenblue at gmail.com><mailto:liangchenblue at gmail.com>
Sent: Thursday, May 16, 2024 5:52:03 AM
To: Aman Sharma; core-libs-dev
Cc: Martin Monperrus
Subject: Re: Deterministic naming of subclasses of `java/lang/reflect/Proxy`

Hi Aman,
I think you meant CVE-2021-42392 instead of 2022.

For your approach of an "allowlist" for Java runtime, project Leyden is looking to generate a static image [1], that
> At run time it cannot load classes from outside the image, nor can it create classes dynamically.
Leyden mainly avoids this unstable generation by performing a training run to collect classes loaded and even object graphs; I am not familiar with the details unfortunately.

Otherwise, the Proxy discussion belongs better to core-libs-dev, as java.lang.reflect.Proxy is part of Java's core libraries. I am replying this thread to core-libs-dev.

For your perceived problem that classes don't have unique names, your description sounds dubious: GeneratedConstructorAccessor is already retired by JEP 416 [2] in Java 18, and there are many other cases in which JDK generates classes without stable names, notoriously LambdaMetafactory (Gradle wished for cacheable Lambdas); the same applies for the generated classes for MethodHandle's LambdaForms (which carries implementation code for LambdaForm). How are you checking the classes? It seems you are not checking hidden classes. Proxy and Lambda classes are defined by the caller's class loader, while LambdaForms are under JDK's system class loader I think. We need to ensure you are correctly finding all unstable classes before we can proceed.

[1]: https://openjdk.org/projects/leyden/notes/01-beginnings
[2]: https://openjdk.org/jeps/416

On Wed, May 15, 2024 at 7:00?PM Aman Sharma <amansha at kth.se<mailto:amansha at kth.se>> wrote:

Hi,


My name is Aman and I am a PhD student at KTH Royal Institute of Technology, Stockholm, Sweden. I research as part of CHAINS<https://chains.proj.kth.se/> project to strengthen the software supply chain of multiple ecosystem. I particularly focus on runtime integrity in Java. In this email, I want to write about an issue I have discovered with dynamic generation of `java.lang.reflect.Proxy`classes. I will propose a solution and would love to hear the feedback from the community. Let me know if this is the correct mailing-list for such discussions. It seemed the most relevant from this list<https://mail.openjdk.org/mailman/listinfo>.


My research


Java has features to load class on the fly - it can either download or generate a class at runtime. These features are useful for inner workings of JDK. For example, implementing annotations, reflective access, etc. However, these features have also contributed to critical vulnerabilities in the past - CVE-2021-44228  (log4shell), CVE-2022-33980, CVE-2022-42392. All of these vulnerabilities have one thing in common - a class that was not known during build time was downloaded/generated at runtime and loaded into JVM.


To defend against such vulnerabilities, we propose a solution to allowlist classes for runtime. This allowlist will contain an exhaustive list of classes that can be loaded by the JVM and it will be enforced at runtime. We build this allowlist from three sources:

  1.  All classes of all modules provided by the Java Standard Library. We use ClassGraph<https://github.com/classgraph/classgraph> to scan the JDK.
  2.  We can take the source code and all dependencies of an application. We use a software bill of materials to get all the data.
  3.  Finally, we use run the test suite to include any runtime downloaded/generated classes.

Such a list is able to prevent the above 3 CVEs because it does not let the "unknown" bytecode to be loaded.

Problem with generating such an allowlist

The first two parts of the allowlist are easy to get. The problem is with the third step where we want to allowlist all the classes that could be downloaded or generated. Upon running the test suite and hooking to the classes it loads, we observer that the list consists of classes that are called "com/sun/proxy/$Proxy2", "jdk/internal/reflect/GeneratedConstructorAccessor3" among many more. The purpose of these classes can be identifed. The proxy class is created for to implement an annotation. The accessor gives access to constructor of a class to the JVM.

When enforcing this allowlist at runtime, we see that the bytecode content for "com/sun/proxy/$Proxy2" differs in the allowlist and at runtime. In our case, we we are experimenting with pdfbox<https://github.com/apache/pdfbox> so we created the allowlist using its test suite. Then we enforced this allowlist while running some of its subcommands. However, there was some other proxy class say "com/sun/proxy/$Proxy5" at runtime that implemented the same interfaces and had the same methods as "com/sun/proxy/$Proxy2" in the allowlist. They only differed in the name of the class, order of fields, and types for fields references. This could happen because the order of the loading of class is workload dependent, but it causes problem to generate such an allowlist.

Solution

We propose that naming of subclasses of "java/lang/reflect/Proxy" should not be dependent upon the order of loading. In order to do so, two issues can be fixed:

  1.  The naming of the class should not be based on AtomicLong<https://github.com/openjdk/jdk/blob/b687aa550837830b38f0f0faa69c353b1e85219c/src/java.base/share/classes/java/lang/reflect/Proxy.java#L531>. Rather it could be named based on the interfaces it implements. I also wonder why AtomicLong is chosen in the first place.
  2.  Methods of the interfaces must be in a particular order. Right now, they are not sorted in any particular order<https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/lang/Class.java#L2178>.


These fixes will make proxy class generation deterministic with respect to order of loading and won't be flagged at runtime since the test suite would already detect them.

I would love to hear from the community about these ideas. If in agreement, I would be happy to produce a patch. I have discovered this issue with subclasses of GeneratedConstructorAccessor<https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/jdk/internal/reflect/ConstructorAccessor.java> as well and I imagine it will also apply to some other runtime generated classes. If you disagree, please let me know also. It helps with my research.

I also have PoCs for the above CVEs<https://github.com/chains-project/exploits-for-sbom.exe> and a proof concept tool is being developed under the name sbom.exe<https://github.com/chains-project/sbom.exe> in case any one wonders about the implementation. I would also be happy to explain more.

Regards,
Aman Sharma

PhD Student
KTH Royal Institute of Technology
School of Electrical Engineering and Computer Science (EECS)
Department of Theoretical Computer Science (TCS)
<https://www.kth.se/profile/amansha>https://algomaster99.github.io/


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240517/17d5faf9/attachment-0001.htm>

From dl at openjdk.org  Fri May 17 11:55:07 2024
From: dl at openjdk.org (Doug Lea)
Date: Fri, 17 May 2024 11:55:07 GMT
Subject: RFR: 8332154: Memory leak in SynchronousQueue [v2]
In-Reply-To: <U63_Nqkfx7gQJTHRCvAcQMgcF-4BeevMfHY77tIYppg=.d88425c8-ce13-4f9a-97dc-84bc47c33aff@github.com>
References: <Fj3W5LlneHODz3PcBD0Ypu2f34UYvxw1iLLKz5pba-I=.0f419338-0a23-4834-8404-55aeab4b813f@github.com>
 <U63_Nqkfx7gQJTHRCvAcQMgcF-4BeevMfHY77tIYppg=.d88425c8-ce13-4f9a-97dc-84bc47c33aff@github.com>
Message-ID: <AmHGXhdlqJLPfnRPfHeOCKHMYU1LY7lzrpKFpPWe0l8=.ea4d7b72-808a-4ce7-b10f-f428c50fed6e@github.com>

On Fri, 17 May 2024 11:39:32 GMT, Viktor Klang <vklang at openjdk.org> wrote:

>> Local testing seems to indicate that this fix (which mirrors what's done in the FIFO mode) addresses the problem.
>> 
>> But with that said, I haven't come up with a decent way of adding some form of regression test. Suggestions are most welcome. /cc @DougLea
>
> Viktor Klang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adding a leak detection test for SynchronousQueue

Looks good; thanks. I don't know why I left out this check in a case that is otherwise identical to LTQ.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19271#issuecomment-2117428982

From liach at openjdk.org  Fri May 17 12:27:13 2024
From: liach at openjdk.org (Chen Liang)
Date: Fri, 17 May 2024 12:27:13 GMT
Subject: Integrated: 8332109: Convert remaining tests using
 com.sun.tools.classfile to ClassFile API
In-Reply-To: <argrcg0iKCFTZJz-mOA_OXkVPbyy0Z5Qb4L2g0Qc4gw=.637a0870-77b0-49da-9aee-ffa39ba68c5f@github.com>
References: <argrcg0iKCFTZJz-mOA_OXkVPbyy0Z5Qb4L2g0Qc4gw=.637a0870-77b0-49da-9aee-ffa39ba68c5f@github.com>
Message-ID: <hEn__8mG1O4dmJhLfMjrT-a0jT-Vmnl0PuwPhdgQTd4=.584adc8d-6cc7-4940-9059-a95efc61d959@github.com>

On Sun, 12 May 2024 08:36:44 GMT, Chen Liang <liach at openjdk.org> wrote:

> Some tests are not migrated to the ClassFile API in previous migrations.
> 
>  - Some are simple oversights that didn't remove usages of com.sun.tools.classfile;
>  - The CallerSensitive ones used an old utility, replaced by CF API-based new code;
>  - many in javac are because the files are compiled with older source compatibility. Those patches are converted to have the source code stored in text blocks and compiled within tests using `ToolBox#writeJavaFiles` and `CompilerUtils.compile`;
>  - As described in the JBS issue, there are a few other tests not covered; one is in #19193 while the others are blocked by CreateSymbols migration or bugs.
> 
> Testing: all modified tests pass.

This pull request has now been integrated.

Changeset: beeffd46
Author:    Chen Liang <liach at openjdk.org>
Committer: Adam Sotona <asotona at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/beeffd4671649e5d8f9c96f0455ac90a82917234
Stats:     1539 lines in 19 files changed: 224 ins; 1098 del; 217 mod

8332109: Convert remaining tests using com.sun.tools.classfile to ClassFile API

Reviewed-by: asotona

-------------

PR: https://git.openjdk.org/jdk/pull/19206

From liach at openjdk.org  Fri May 17 12:29:09 2024
From: liach at openjdk.org (Chen Liang)
Date: Fri, 17 May 2024 12:29:09 GMT
Subject: Integrated: 8331855: Convert jdk.jdeps jdeprscan and jdeps to use the
 Classfile API
In-Reply-To: <q2IKpwi6HEvLcKtNgKEzkD456bopyXRTliaRIU67C-4=.b77f917c-cb50-4d87-b187-65934954d622@github.com>
References: <q2IKpwi6HEvLcKtNgKEzkD456bopyXRTliaRIU67C-4=.b77f917c-cb50-4d87-b187-65934954d622@github.com>
Message-ID: <8uStGBlHnQ59A_nUq6cqwR47kJKUMohwb20xFd0ClvY=.c5708adf-e602-4476-add3-590e3023e9df@github.com>

On Sat, 11 May 2024 19:35:33 GMT, Chen Liang <liach at openjdk.org> wrote:

> Summary of the changes:
>  - Moved `com.sun.tools.classfile.Dependency` and `Dependencies` to jdeps; they are exclusively used by jdeps in sources, and they are not used in any tests too. This will ease the removal of `com.sun.tools.classfile` later.
>  - A few visitor patterns have been rewritten with pattern matching, notably in:
>    - `CPEntries`/`CPSelector` (removed)
>    - `Dependencies.BasicDependencyFinder.Visitor` has been rewritten to use pattern matching to capture dependencies.
>  - `MethodSig` and its tests have been removed in favor of `MethodTypeDesc`.
>  - Otherwise, the changes are mostly mechanical replacements.
> 
> All tests in `test/langtools/tools/jdeprscan` and `test/langtools/tools/jdeps` pass.

This pull request has now been integrated.

Changeset: d4c2edf2
Author:    Chen Liang <liach at openjdk.org>
Committer: Adam Sotona <asotona at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/d4c2edf2c91a790874c80f1a7bea5bfd4f438bde
Stats:     2156 lines in 20 files changed: 744 ins; 1197 del; 215 mod

8331855: Convert jdk.jdeps jdeprscan and jdeps to use the Classfile API

Reviewed-by: asotona

-------------

PR: https://git.openjdk.org/jdk/pull/19193

From asotona at openjdk.org  Fri May 17 13:07:32 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Fri, 17 May 2024 13:07:32 GMT
Subject: RFR: 8320396: Class-File API ClassModel::verify should include
 checks from hotspot/share/classfile/classFileParser.cpp [v8]
In-Reply-To: <0a66asWcJ4_zBrjmReA18BZmsovN1ZeJRRSAPZDMZmo=.5bada03f-d88d-46cd-962d-c1e42c3048c1@github.com>
References: <0a66asWcJ4_zBrjmReA18BZmsovN1ZeJRRSAPZDMZmo=.5bada03f-d88d-46cd-962d-c1e42c3048c1@github.com>
Message-ID: <h4jLoflbj6Cpe5NeUWcH-uBn5L_VbwH6C5tuv9W1KuI=.32386a00-bd55-4a9c-825e-018b4389d755@github.com>

> ClassFile API `jdk.internal.classfile.verifier.VerifierImpl` performed only bytecode-level class verification.
> This patch adds `jdk.internal.classfile.verifier.ParserVerifier` with additional class checks inspired by `hotspot/share/classfile/classFileParser.cpp`.
> 
> Also new `VerifierSelfTest::testParserVerifier` has been added.
> 
> Please review.
> 
> Thanks,
> Adam

Adam Sotona has updated the pull request incrementally with three additional commits since the last revision:

 - added verification of TypeAnnotation attributes
 - added verification of SMT attribute
 - added verification of module-related attributes

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/16809/files
  - new: https://git.openjdk.org/jdk/pull/16809/files/6f12b3bd..71818488

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16809&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16809&range=06-07

  Stats: 139 lines in 2 files changed: 136 ins; 1 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/16809.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16809/head:pull/16809

PR: https://git.openjdk.org/jdk/pull/16809

From asotona at openjdk.org  Fri May 17 13:07:32 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Fri, 17 May 2024 13:07:32 GMT
Subject: RFR: 8320396: Class-File API ClassModel::verify should include
 checks from hotspot/share/classfile/classFileParser.cpp [v7]
In-Reply-To: <I-u3YvLUbIrdpHhe3NPy06V7LkXph1dPFggAxOr2_-U=.dcdd28c6-8aca-4eaf-b589-573eea8837d2@github.com>
References: <0a66asWcJ4_zBrjmReA18BZmsovN1ZeJRRSAPZDMZmo=.5bada03f-d88d-46cd-962d-c1e42c3048c1@github.com>
 <djFxpWMkSwFyS2AOLnX9Jx4sG0_RqxEeA-qBtWjvO9U=.55c71ff2-0597-488a-83f0-f47fe96e79bf@github.com>
 <_691j41TGzd_pv4q8ZqS_XPsbLIb_O-AVxOfPH8YY9A=.1107a250-7e32-42aa-ad1a-9a6fa8e6e3cc@github.com>
 <I-u3YvLUbIrdpHhe3NPy06V7LkXph1dPFggAxOr2_-U=.dcdd28c6-8aca-4eaf-b589-573eea8837d2@github.com>
Message-ID: <W_4oF4-5324s2XeNmq5YpBPfMzQp9GAi3kiuWeDTVio=.903755f5-6ca6-4c57-8019-8db1748c3bdd@github.com>

On Fri, 17 May 2024 08:28:51 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/classfile/impl/verifier/ParserVerifier.java line 308:
>> 
>>> 306:                 0;
>>> 307:             default ->
>>> 308:                 -1;
>> 
>> I recommend we explicitly return -1 to skip verification only for UnknownAttribute and CustomAttribute; then our tests can catch missing verification for new attribute additions.
>
> There are still many attributes missing here (yet). However it is a nice goal.

OK, I've added the missing attributes to the verification.
Now it will throw an AssertionError if we forget to verify newly added attribute.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16809#discussion_r1604971946

From erikj at openjdk.org  Fri May 17 13:15:05 2024
From: erikj at openjdk.org (Erik Joelsson)
Date: Fri, 17 May 2024 13:15:05 GMT
Subject: RFR: 8330542: Add jaxp-strict.properties in preparation for a
 secure by default configuration [v8]
In-Reply-To: <WaojCmjwxI30LQExFov5KlAMiJVqJC7RqZLMtmAOCFc=.2cbfbcc6-6015-43aa-bcc7-5e1bba4b75dd@github.com>
References: <v1bAYKgH9zfooXpvnBw4Vu2TIqHuKqqtSmgB0hiNp-Q=.31661a99-ecfc-4a05-8045-67b5f680db60@github.com>
 <WaojCmjwxI30LQExFov5KlAMiJVqJC7RqZLMtmAOCFc=.2cbfbcc6-6015-43aa-bcc7-5e1bba4b75dd@github.com>
Message-ID: <9ItSoz7uGqjAXpvgoBoqNzVHqji5rlox0OtPbIoJbq4=.c7a0d8ea-527c-4d7b-a8ab-e01c3a88924d@github.com>

On Thu, 16 May 2024 22:20:39 GMT, Joe Wang <joehw at openjdk.org> wrote:

>> Add two sample configuration files:
>> 
>>   jaxp-strict.properties: used to set strict configuration, stricter than jaxp.properties in previous versions such as JDK 22
>> 
>>>   jaxp-compat.properties: used to regain compatibility from any more restricted configuration than previous versions such as JDK 22
>> 
>> Updated 5/16/2024
>> 
>> Design change:
>> The design is changed to include in the JDK two configuration files that are the default jaxp.properties and jaxp-strict.properties, instead of three, dropping jaxp-compat.properties.
>
> Joe Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove jaxp-compat.properties from the list

make/modules/java.xml/Copy.gmk line 31:

> 29: ################################################################################
> 30: #
> 31: # Copy property files from share/conf to CONF_DST_DIR LIB_DST_DIR

There is no copying to LIB_DST_DIR, so no need to mention it.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18831#discussion_r1604983457

From erikj at openjdk.org  Fri May 17 13:15:05 2024
From: erikj at openjdk.org (Erik Joelsson)
Date: Fri, 17 May 2024 13:15:05 GMT
Subject: RFR: 8330542: Add jaxp-strict.properties in preparation for a
 secure by default configuration [v8]
In-Reply-To: <LBD-47vDvjpMdi3UXb0ohMpqLEegT4ceIV7RKY8T3EA=.1bd16214-be8b-43df-add2-d76939db21de@github.com>
References: <v1bAYKgH9zfooXpvnBw4Vu2TIqHuKqqtSmgB0hiNp-Q=.31661a99-ecfc-4a05-8045-67b5f680db60@github.com>
 <WaojCmjwxI30LQExFov5KlAMiJVqJC7RqZLMtmAOCFc=.2cbfbcc6-6015-43aa-bcc7-5e1bba4b75dd@github.com>
 <LBD-47vDvjpMdi3UXb0ohMpqLEegT4ceIV7RKY8T3EA=.1bd16214-be8b-43df-add2-d76939db21de@github.com>
Message-ID: <ffv7LwhhLNtARXGkKjefgnc7QTDiBTy2qMKql9l3PE0=.769badeb-88c6-4351-9524-496b2514c806@github.com>

On Fri, 17 May 2024 05:51:31 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Joe Wang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   remove jaxp-compat.properties from the list
>
> make/modules/java.xml/Copy.gmk line 37:
> 
>> 35: JAXPPROPFILE_TARGET_FILES := $(subst $(JAXPPROPFILE_SRC_DIR),$(CONF_DST_DIR),$(JAXPPROPFILE_SRCS))
>> 36: 
>> 37: $(CONF_DST_DIR)/%: $(JAXPPROPFILE_SRC_DIR)/%
> 
> The make file changes to copy the properties files look okay but I'm curious about why the naming changes from "XML" to "JAXPPROFILE".

If we are changing this file, we should modernize it.


$(eval $(call SetupCopyFiles, COPY_XML_MODULE_CONF, \
    DEST := $(CONF_DST_DIR), \
    FILES := $(wildcard $(TOPDIR)/src/java.xml/share/conf/jaxp*.properties*), \
))

TARGETS += $(COPY_XML_MODULE_CONF)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18831#discussion_r1604981949

From vklang at openjdk.org  Fri May 17 13:19:19 2024
From: vklang at openjdk.org (Viktor Klang)
Date: Fri, 17 May 2024 13:19:19 GMT
Subject: RFR: 8332154: Memory leak in SynchronousQueue [v3]
In-Reply-To: <Fj3W5LlneHODz3PcBD0Ypu2f34UYvxw1iLLKz5pba-I=.0f419338-0a23-4834-8404-55aeab4b813f@github.com>
References: <Fj3W5LlneHODz3PcBD0Ypu2f34UYvxw1iLLKz5pba-I=.0f419338-0a23-4834-8404-55aeab4b813f@github.com>
Message-ID: <iMAdASClqlen1dLO4nK3q_RTGtHgMxKeMImJ2J2lGUA=.2de28d45-7faa-4718-ab36-e7201cee0e36@github.com>

> Local testing seems to indicate that this fix (which mirrors what's done in the FIFO mode) addresses the problem.
> 
> But with that said, I haven't come up with a decent way of adding some form of regression test. Suggestions are most welcome. /cc @DougLea

Viktor Klang has updated the pull request incrementally with one additional commit since the last revision:

  Moving the memory leak test for SynchronousQueue into its own test and runs only for JDK20+, using VirtualThreads

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19271/files
  - new: https://git.openjdk.org/jdk/pull/19271/files/f365c5f0..cc0a2014

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19271&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19271&range=01-02

  Stats: 181 lines in 3 files changed: 116 ins; 65 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/19271.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19271/head:pull/19271

PR: https://git.openjdk.org/jdk/pull/19271

From vklang at openjdk.org  Fri May 17 13:19:19 2024
From: vklang at openjdk.org (Viktor Klang)
Date: Fri, 17 May 2024 13:19:19 GMT
Subject: RFR: 8332154: Memory leak in SynchronousQueue [v2]
In-Reply-To: <AmHGXhdlqJLPfnRPfHeOCKHMYU1LY7lzrpKFpPWe0l8=.ea4d7b72-808a-4ce7-b10f-f428c50fed6e@github.com>
References: <Fj3W5LlneHODz3PcBD0Ypu2f34UYvxw1iLLKz5pba-I=.0f419338-0a23-4834-8404-55aeab4b813f@github.com>
 <U63_Nqkfx7gQJTHRCvAcQMgcF-4BeevMfHY77tIYppg=.d88425c8-ce13-4f9a-97dc-84bc47c33aff@github.com>
 <AmHGXhdlqJLPfnRPfHeOCKHMYU1LY7lzrpKFpPWe0l8=.ea4d7b72-808a-4ce7-b10f-f428c50fed6e@github.com>
Message-ID: <_bwMajYI1chgjDXCswWlIzPiWg1AHTtlbs4fGzjQl_4=.8f4dafdd-1f38-4c8c-ac69-9c419a3a5ddf@github.com>

On Fri, 17 May 2024 11:52:12 GMT, Doug Lea <dl at openjdk.org> wrote:

>> Viktor Klang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Adding a leak detection test for SynchronousQueue
>
> Looks good; thanks. I don't know why I left out this check in a case that is otherwise identical to LTQ.

@DougLea I decided to move to using VirtualThreads and therefor pulling the memory leak test out into its own class which only runs for JDK20+.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19271#issuecomment-2117584999

From mcimadamore at openjdk.org  Fri May 17 13:23:06 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 17 May 2024 13:23:06 GMT
Subject: RFR: 8331671: Implement JEP 472: Prepare to Restrict the Use of
 JNI [v7]
In-Reply-To: <TLlZCZnwecI8yT_xAKpqXFPZss7e0kUgozRZRlKYhFo=.4ed29ae7-0f90-4312-9dc7-b23104ad70f5@github.com>
References: <CZGbki5iFdCGPPagE-ya-_L8Nkgf7OunywApOsxC548=.2cee82fa-a5d2-4165-b012-30982a85030a@github.com>
 <kAq153qNH4hG6IDWoTMrBv9pCPMEZl1pI7-wJQgsI7A=.6588b41b-eb33-49a6-a49d-cca79aaaf180@github.com>
 <TLlZCZnwecI8yT_xAKpqXFPZss7e0kUgozRZRlKYhFo=.4ed29ae7-0f90-4312-9dc7-b23104ad70f5@github.com>
Message-ID: <GLNx0ptAp6dY9BORWHEv6XnKqoRWn_QejEmKQ6iY540=.4a5fe98e-b069-4250-b9d2-bbc8f9b89841@github.com>

On Thu, 16 May 2024 18:39:57 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add note on --illegal-native-access default value in the launcher help
>
> src/java.base/share/classes/java/lang/System.java line 2023:
> 
>> 2021:      * @throws     NullPointerException if {@code filename} is {@code null}
>> 2022:      * @throws     IllegalCallerException If the caller is in a module that
>> 2023:      *             does not have native access enabled.
> 
> The exception description is fine, just noticed the other exception descriptions start with a lowercase "if", this one is different.

I'll fix this. Note that in `ModuleLayer.Controller`, all `@throws` start with capital letter, which is probably where I copied/pasted this from. I'll fix all, except for `ModuleLayer` where, for consistency, I think upper case is better.

> src/java.base/share/man/java.1 line 587:
> 
>> 585: \f[V]deny\f[R]: This mode disables all illegal native access except for
>> 586: those modules enabled by the \f[V]--enable-native-access\f[R]
>> 587: command-line option.
> 
> "This mode disable all illegal native access except for those modules enabled the --enable-native-access command-line option". 
> 
> This can be read to mean that modules granted native access with the command line option is also illegal native access An alternative is to make the second part of the sentence a new sentence, something like "Only modules enabled by the --enable-native-access command line option may perform native access.

I've simplified the text to:


This mode disables illegal native access. That is, any illegal native access causes an `IllegalCallerException`.
This mode will become the default in a future release.


I think it's not necessary to state again the dependency on `--enable-native-access` as we already defined what "illegal native access" means.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19213#discussion_r1604994928
PR Review Comment: https://git.openjdk.org/jdk/pull/19213#discussion_r1604993505

From mcimadamore at openjdk.org  Fri May 17 13:38:25 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 17 May 2024 13:38:25 GMT
Subject: RFR: 8331671: Implement JEP 472: Prepare to Restrict the Use of
 JNI [v8]
In-Reply-To: <CZGbki5iFdCGPPagE-ya-_L8Nkgf7OunywApOsxC548=.2cee82fa-a5d2-4165-b012-30982a85030a@github.com>
References: <CZGbki5iFdCGPPagE-ya-_L8Nkgf7OunywApOsxC548=.2cee82fa-a5d2-4165-b012-30982a85030a@github.com>
Message-ID: <vWr2PdgTv6vEllxW8820KO3aZ3tR3xvMhCxD2k7QpS0=.8bfd6c47-6c93-4fc3-aced-7079889aa6a2@github.com>

> This PR implements [JEP 472](https://openjdk.org/jeps/472), by restricting the use of JNI in the following ways:
> 
> * `System::load` and `System::loadLibrary` are now restricted methods
> * `Runtime::load` and `Runtime::loadLibrary` are now restricted methods
> * binding a JNI `native` method declaration to a native implementation is now considered a restricted operation
> 
> This PR slightly changes the way in which the JDK deals with restricted methods, even for FFM API calls. In Java 22, the single `--enable-native-access` was used both to specify a set of modules for which native access should be allowed *and* to specify whether illegal native access (that is, native access occurring from a module not specified by `--enable-native-access`) should be treated as an error or a warning. More specifically, an error is only issued if the `--enable-native-access flag` is used at least once.
> 
> Here, a new flag is introduced, namely `illegal-native-access=allow/warn/deny`, which is used to specify what should happen when access to a restricted method and/or functionality is found outside the set of modules specified with `--enable-native-access`. The default policy is `warn`, but users can select `allow` to suppress the warnings, or `deny` to cause `IllegalCallerException` to be thrown. This aligns the treatment of restricted methods with other mechanisms, such as `--illegal-access` and the more recent `--sun-misc-unsafe-memory-access`.
> 
> Some changes were required in the package-info javadoc for `java.lang.foreign`, to reflect the changes in the command line flags described above.

Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:

  Address review comments

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19213/files
  - new: https://git.openjdk.org/jdk/pull/19213/files/3a0db276..789bdf48

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19213&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19213&range=06-07

  Stats: 28 lines in 10 files changed: 8 ins; 2 del; 18 mod
  Patch: https://git.openjdk.org/jdk/pull/19213.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19213/head:pull/19213

PR: https://git.openjdk.org/jdk/pull/19213

From dl at openjdk.org  Fri May 17 13:52:03 2024
From: dl at openjdk.org (Doug Lea)
Date: Fri, 17 May 2024 13:52:03 GMT
Subject: RFR: 8332154: Memory leak in SynchronousQueue [v3]
In-Reply-To: <iMAdASClqlen1dLO4nK3q_RTGtHgMxKeMImJ2J2lGUA=.2de28d45-7faa-4718-ab36-e7201cee0e36@github.com>
References: <Fj3W5LlneHODz3PcBD0Ypu2f34UYvxw1iLLKz5pba-I=.0f419338-0a23-4834-8404-55aeab4b813f@github.com>
 <iMAdASClqlen1dLO4nK3q_RTGtHgMxKeMImJ2J2lGUA=.2de28d45-7faa-4718-ab36-e7201cee0e36@github.com>
Message-ID: <SWniN2qSuJq2wU42X1zp7E2ML2PoUxmVF99aRzQU7mE=.778f7892-29d8-4d78-bf4c-e5cd19c151d9@github.com>

On Fri, 17 May 2024 13:19:19 GMT, Viktor Klang <vklang at openjdk.org> wrote:

>> Local testing seems to indicate that this fix (which mirrors what's done in the FIFO mode) addresses the problem.
>> 
>> But with that said, I haven't come up with a decent way of adding some form of regression test. Suggestions are most welcome. /cc @DougLea
>
> Viktor Klang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Moving the memory leak test for SynchronousQueue into its own test and runs only for JDK20+, using VirtualThreads

Sure. Seems reasonable.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19271#issuecomment-2117653564

From jpai at openjdk.org  Fri May 17 14:05:07 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 17 May 2024 14:05:07 GMT
Subject: RFR: 8332086: Remove the usage of ServiceLoader in
 j.u.r.RandomGeneratorFactory [v7]
In-Reply-To: <VO_1lN8_gkntTBcwjxAzdXdGJgtdQWWmuVjZG7wfbsI=.1a2f6ff4-b00e-4193-a268-e5744c3d77f0@github.com>
References: <hfB86NksORc-aC6zVxHel_QQd_9aB629SfQjXvl6q5U=.e31daa4b-5cf6-4f3f-a757-79e818a18978@github.com>
 <VO_1lN8_gkntTBcwjxAzdXdGJgtdQWWmuVjZG7wfbsI=.1a2f6ff4-b00e-4193-a268-e5744c3d77f0@github.com>
Message-ID: <hkgju6LV12fCflMQ5b3DWAhW-utLeGRxuNJMnYwQ7vk=.ed1260a4-3a0d-49ca-9b73-1083e61c4a7b@github.com>

On Fri, 17 May 2024 08:28:15 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> All random number generator algorithms are implemented in module `java.base`. The usage of `ServiceLoader` in `j.u.r.RandomGeneratorFactory` is no longer needed.
>
> Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:
> 
>   SecureRandom added to the table in package documentation.

Thank you Raffaello for fixing this as well as considering the review suggestions. The latest state of this PR in `880138d7` looks good to me. I've also reviewed the linked CSR and that too looks fine to me.

-------------

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19212#pullrequestreview-2063525156

From jpai at openjdk.org  Fri May 17 14:05:07 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 17 May 2024 14:05:07 GMT
Subject: RFR: 8332086: Remove the usage of ServiceLoader in
 j.u.r.RandomGeneratorFactory [v5]
In-Reply-To: <YIjnTmRDdxPwHEenjhZTUPKifSA615_2gbPmT-m76BU=.69590d70-7ca7-4b13-bdcb-5b8aa2e2ab40@github.com>
References: <hfB86NksORc-aC6zVxHel_QQd_9aB629SfQjXvl6q5U=.e31daa4b-5cf6-4f3f-a757-79e818a18978@github.com>
 <ZasWP14ViFxaPqk_x3rmDgVFocTX9_aAP1W_kplDjbE=.b5fa3a6a-c303-4fe7-afbe-01700d4a7e85@github.com>
 <2Tv7yoSkIoEuQX2GZuyBnAdGHSpTKCGXV0_K0_UPiks=.dff4cf04-3a5d-4afc-8057-9cebb9b61ddd@github.com>
 <8d6Um0qog6MPlI-wjflKoo2CKf_-uZP7N6pg63Iwl9U=.8e69aeb7-9672-4ff8-bb40-a8754d16427a@github.com>
 <YIjnTmRDdxPwHEenjhZTUPKifSA615_2gbPmT-m76BU=.69590d70-7ca7-4b13-bdcb-5b8aa2e2ab40@github.com>
Message-ID: <wX5td0LSurd2ajT-IsKu6-TDPxCU0EUPVplwZkaTfCk=.84c8cb83-4d6d-467e-8b55-ed27a608f902@github.com>

On Thu, 16 May 2024 13:23:14 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> Yes, I thought about this the other day but decided for a bit more conservative approach, relying on the annotation.
>> 
>> But I agree that, since the meta-information now resides in `RandomGeneratorProperties`, we might "migrate" the deprecation status here as well.
>
> Since the legacy generators are public classes, they can be publicly deprecated, so in the last commit the `DEPRECATED` bit for them still relies on the annotation, which IMO is the authoritative "source of truth".
> 
> For the 10 other algorithms, which are accessible only via `RandomFactoryGenerator`, we can rely on the info in `RandomProperties`.

The deprecation process of algorithms is unclear - whether it should be tied with the `@Deprecation` of a class that provides that algorithm. We will have more clarity if/when we do deprecate these algorithms. The specification in its current form doesn't tie it to the `@Deprecation` annotation, which is a good thing. So your proposed change in this PR looks fine to me, since it will still allow us to move away from the `@Deprecated` annotation check if we wanted to, in a subsequent release/change.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19212#discussion_r1605058285

From jlahoda at openjdk.org  Fri May 17 15:06:05 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Fri, 17 May 2024 15:06:05 GMT
Subject: RFR: 8331051: Add an `@since` checker test for `java.base` module
 [v5]
In-Reply-To: <PlsvKjixjw77eZxhBvJzNJe-PUHhcgrJW20-4LMJdAA=.c743c945-d71a-4a5c-865d-e1b0da2476b3@github.com>
References: <NRZmbFYvDwXPuizcmCilJx5Yb6HjZ-2fJa-YILxYUl8=.a79f79e4-77d5-4910-b3df-5e78bb7e402b@github.com>
 <PlsvKjixjw77eZxhBvJzNJe-PUHhcgrJW20-4LMJdAA=.c743c945-d71a-4a5c-865d-e1b0da2476b3@github.com>
Message-ID: <_PQwl4FscLiS1bgx11f6eCygo3ukz5hQJKAKVgJ2ufs=.0f9f3c30-85da-4dcf-b2de-d01ba60f1c17@github.com>

On Sun, 5 May 2024 15:22:15 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

>> This checker checks the values of the `@since` tag found in the documentation comment for an element against the release in which the element first appeared.
>> 
>> Real since value of an API element is computed as the oldest release in which the given API element was introduced. That is:
>> - for modules, classes and interfaces, the release in which the element with the given qualified name was introduced
>> - for constructors, the release in which the constructor with the given VM descriptor was introduced
>> - for methods and fields, the release in which the given method or field with the given VM descriptor became a member of its enclosing class or interface, whether direct or inherited
>> 
>> Effective since value of an API element is computed as follows:
>> - if the given element has a `@since` tag in its javadoc, it is used
>> - in all other cases, return the effective since value of the enclosing element
>> 
>> The since checker verifies that for every API element, the real since value and the effective since value are the same, and reports an error if they are not.
>> 
>> Preview method are handled as per JEP 12, if `@PreviewFeature` is used consistently going forward then the checker doesn't need to be updated with every release. The checker has explicit knowledge of preview elements that came before `JDK 14` because they weren't marked in a machine understandable way and preview elements that came before `JDK 17` that didn't have `@PreviewFeature`.
>> 
>> Important note : We only check code written since `JDK 9` as the releases used to determine the expected value of `@since` tags are taken from the historical data built into `javac` which only goes back that far
>> 
>> The intial comment at the beginning of `SinceChecker.java` holds more information into the program.
>> 
>> I already have filed issues and fixed some wrong tags like in #18640, #18032, #18030, #18055, #18373, #18954, #18972.
>
> Nizar Benalla has updated the pull request incrementally with one additional commit since the last revision:
> 
>   - Not checking elements enclosed within a record, I doubt a record class will change after being created
>   - Added a null check as `toString` can return an exception

Overall seems pretty good, great job!

A few comments inline, to make the code cleaner.

Thanks for working on this!

test/jdk/tools/sincechecker/SinceChecker.java line 224:

> 222:         }
> 223: 
> 224:         return LEGACY_PREVIEW_METHODS.containsKey(currentVersion)

Nit: could probably be `LEGACY_PREVIEW_METHODS.getOrDefault(currentVersion, Map.of()).contains(uniqueId)`

test/jdk/tools/sincechecker/SinceChecker.java line 309:

> 307:                 error("module-info.java not found or couldn't be opened AND this module has no unqualified exports");
> 308:             } catch (NullPointerException e) {
> 309:                 error("module-info.java does not contain an `@since`");

Catching a NPE like this feels like a code smell to me. I assume it may happen when `extractSinceVersionFromText(moduleInfoContent)` returns `null` - so just store that in a variable, and check for `null` there.

test/jdk/tools/sincechecker/SinceChecker.java line 331:

> 329:                 error(ed.getPackage().getQualifiedName() + ": package-info.java not found or couldn't be opened");
> 330:             } catch (NullPointerException e) {
> 331:                 error(ed.getPackage().getQualifiedName() + ": package-info.java  does not contain an `@since`");

Please see the comment on NPE catching in `getModuleVersionFromFile`.

test/jdk/tools/sincechecker/SinceChecker.java line 352:

> 350:         }
> 351:         checkElement(te.getEnclosingElement(), te, types, javadocHelper, version, elementUtils);
> 352:         if( te.getKind() == ElementKind.RECORD){

This seems a bit too broad. Ignoring all members of a record type may lead to missed members. `Elements.getOrigin` may be unusable here, but I wonder what exactly is the problem which this condition is trying to solve?

-------------

PR Review: https://git.openjdk.org/jdk/pull/18934#pullrequestreview-2063646309
PR Review Comment: https://git.openjdk.org/jdk/pull/18934#discussion_r1605134919
PR Review Comment: https://git.openjdk.org/jdk/pull/18934#discussion_r1605140507
PR Review Comment: https://git.openjdk.org/jdk/pull/18934#discussion_r1605143505
PR Review Comment: https://git.openjdk.org/jdk/pull/18934#discussion_r1605150261

From psandoz at openjdk.org  Fri May 17 15:57:02 2024
From: psandoz at openjdk.org (Paul Sandoz)
Date: Fri, 17 May 2024 15:57:02 GMT
Subject: RFR: 8331865: Consolidate size and alignment checks in LayoutPath
 [v2]
In-Reply-To: <sbhzMEtBjBJuxpO_JdNI4tCiTZwCG8WNBXR5_G2TVXo=.1726357f-4f88-46dc-aaa6-b773df9292df@github.com>
References: <CvKkdESp5-uHiuZtQvGortWnzOMV89pfjaCHNBIV4B4=.51ad0f01-2371-48af-b3c6-8a9b80518cdb@github.com>
 <sbhzMEtBjBJuxpO_JdNI4tCiTZwCG8WNBXR5_G2TVXo=.1726357f-4f88-46dc-aaa6-b773df9292df@github.com>
Message-ID: <m8kU9pL_CHrdNq22K1_GrK3KFnd1KMrwwvny-6Bxk-Q=.fed48fb0-3c38-40c7-b6d4-b92f20e86864@github.com>

On Thu, 16 May 2024 14:37:15 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> When creating a nested memory access var handle, we ensure that the segment is accessed at the correct alignment for the root layout being accessed. But we do not ensure that the segment has at least the size of the accessed root layout. Example:
>> 
>> 
>> MemoryLayout LAYOUT = sequenceLayout(2, structLayout(JAVA_INT.withName("x"), JAVA_INT.withName("y")));
>> VarHandle X_HANDLE = LAYOUT.varHandle(PathElement.sequenceElement(), PathElement.groupElement("x"));
>> 
>> 
>> If I have a memory segment whose size is 12, I can successfully call X_HANDLE on it with index 1, like so:
>> 
>> 
>> MemorySegment segment = Arena.ofAuto().allocate(12);
>> int x = (int)X_HANDLE.get(segment, 0, 1);
>> 
>> 
>> This seems incorrect: after all, the provided segment doesn't have enough space to fit _two_ elements of the nested structs. 
>> 
>> This PR adds checks to detect this kind of scenario earlier, thus improving usability. To achieve this we could, in principle, just tweak `LayoutPath::checkEnclosingLayout` and add the required size check.
>> 
>> But doing so will add yet another redundant check on top of the other already added by [pull/19124](https://git.openjdk.org/jdk/pull/19124). Instead, this PR rethinks how memory segment var handles are created, in order to eliminate redundant checks.
>> 
>> The main observation is that size and alignment checks depend on an _enclosing_ layout. This layout *might* be the very same value layout being accessed (this is the case when e.g. using `JAVA_INT.varHandle()`). But, in the general case, the accessed value layout and the enclosing layout might differ (e.g. think about accessing a struct field).
>> 
>> Furthermore, the enclosing layout check depends on the _base_ offset at which the segment is accessed, _prior_ to any index computation that occurs if the accessed layout path has any open elements. It is important to notice that this base offset is only available when looking at the var handle that is returned to the user. For instance, an indexed var handle with coordinates:
>> 
>> 
>> (MemorySegment, long /* base */, long /* index 1 */, long /* index 2 */, long /* index 3 */)
>> 
>> 
>> Is obtained through adaptation, by taking a more basic var handle of the form:
>> 
>> 
>> (MemorySegment, long /* offset */)
>> 
>> 
>> And then injecting the result of the index multiplication into `offset`. As such, we can't add an enclosing layout check inside the var handle returned by `VarHandles::memorySegmentViewHandle`, as doing so will end up seeing the *wrong* off...
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix copyrights

src/java.base/share/classes/java/lang/foreign/MemoryLayout.java line 630:

> 628:      *     <li>The access operation must fall inside the spatial bounds of the accessed
> 629:      *     memory segment, or an {@link IndexOutOfBoundsException} is thrown. This is the case
> 630:      *     when {@code B + A <= S}, where {@code O} is the base offset (defined above),

Do you mean `{@code O + A <= S}`?
(Still working my way through the changes...)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19251#discussion_r1605231757

From mcimadamore at openjdk.org  Fri May 17 16:02:06 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 17 May 2024 16:02:06 GMT
Subject: RFR: 8331865: Consolidate size and alignment checks in LayoutPath
 [v2]
In-Reply-To: <m8kU9pL_CHrdNq22K1_GrK3KFnd1KMrwwvny-6Bxk-Q=.fed48fb0-3c38-40c7-b6d4-b92f20e86864@github.com>
References: <CvKkdESp5-uHiuZtQvGortWnzOMV89pfjaCHNBIV4B4=.51ad0f01-2371-48af-b3c6-8a9b80518cdb@github.com>
 <sbhzMEtBjBJuxpO_JdNI4tCiTZwCG8WNBXR5_G2TVXo=.1726357f-4f88-46dc-aaa6-b773df9292df@github.com>
 <m8kU9pL_CHrdNq22K1_GrK3KFnd1KMrwwvny-6Bxk-Q=.fed48fb0-3c38-40c7-b6d4-b92f20e86864@github.com>
Message-ID: <xZ7kNx_qWYbw4b-MI8TXLQ95ARq_FOeKzfjtz-GqyXU=.a70f526b-31c6-4c1c-8ea7-47849b9b0695@github.com>

On Fri, 17 May 2024 15:54:04 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix copyrights
>
> src/java.base/share/classes/java/lang/foreign/MemoryLayout.java line 630:
> 
>> 628:      *     <li>The access operation must fall inside the spatial bounds of the accessed
>> 629:      *     memory segment, or an {@link IndexOutOfBoundsException} is thrown. This is the case
>> 630:      *     when {@code B + A <= S}, where {@code O} is the base offset (defined above),
> 
> Do you mean `{@code O + A <= S}`?
> (Still working my way through the changes...)

Yes, apologies

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19251#discussion_r1605237785

From duke at openjdk.org  Fri May 17 17:10:06 2024
From: duke at openjdk.org (Volodymyr Paprotski)
Date: Fri, 17 May 2024 17:10:06 GMT
Subject: RFR: 8329538: Accelerate P256 on x86_64 using Montgomery intrinsic
 [v10]
In-Reply-To: <hanRK4GzOkFV8kG1gZRy8Br53trw4-Tu6G6uO8nsFuk=.d5bf723a-f683-4759-ac9e-4a58cb430f03@github.com>
References: <hanRK4GzOkFV8kG1gZRy8Br53trw4-Tu6G6uO8nsFuk=.d5bf723a-f683-4759-ac9e-4a58cb430f03@github.com>
Message-ID: <GLCjaOSwPE1O0QcK5UpdQasQbWF9DXR_fqVwK6bR2XA=.2f8b96a1-16ec-49dd-996e-c8520884904f@github.com>

> Performance. Before:
> 
> Benchmark                        (algorithm)  (dataSize)  (keyLength)  (provider)   Mode  Cnt     Score    Error  Units
> SignatureBench.ECDSA.sign    SHA256withECDSA        1024          256              thrpt    3  6443.934 ?  6.491  ops/s
> SignatureBench.ECDSA.sign    SHA256withECDSA       16384          256              thrpt    3  6152.979 ?  4.954  ops/s
> SignatureBench.ECDSA.verify  SHA256withECDSA        1024          256              thrpt    3  1895.410 ? 36.979  ops/s
> SignatureBench.ECDSA.verify  SHA256withECDSA       16384          256              thrpt    3  1878.955 ? 45.487  ops/s
> Benchmark                                            (algorithm)  (keyLength)  (kpgAlgorithm)  (provider)   Mode  Cnt     Score    Error  Units
> o.o.b.j.c.full.KeyAgreementBench.EC.generateSecret          ECDH          256              EC              thrpt    3  1357.810 ? 26.584  ops/s
> o.o.b.j.c.small.KeyAgreementBench.EC.generateSecret         ECDH          256              EC              thrpt    3  1352.119 ? 23.547  ops/s
> Benchmark                          (isMontBench)   Mode  Cnt     Score    Error  Units
> PolynomialP256Bench.benchMultiply          false  thrpt    3  1746.126 ? 10.970  ops/s
> 
> Performance, no intrinsic:
> 
> Benchmark                        (algorithm)  (dataSize)  (keyLength)  (provider)   Mode  Cnt     Score     Error  Units
> SignatureBench.ECDSA.sign    SHA256withECDSA        1024          256              thrpt    3  6529.839 ?  42.420  ops/s
> SignatureBench.ECDSA.sign    SHA256withECDSA       16384          256              thrpt    3  6199.747 ? 133.566  ops/s
> SignatureBench.ECDSA.verify  SHA256withECDSA        1024          256              thrpt    3  1973.676 ?  54.071  ops/s
> SignatureBench.ECDSA.verify  SHA256withECDSA       16384          256              thrpt    3  1932.127 ?  35.920  ops/s
> Benchmark                                            (algorithm)  (keyLength)  (kpgAlgorithm)  (provider)   Mode  Cnt     Score    Error  Units
> o.o.b.j.c.full.KeyAgreementBench.EC.generateSecret          ECDH          256              EC              thrpt    3  1355.788 ? 29.858  ops/s
> o.o.b.j.c.small.KeyAgreementBench.EC.generateSecret         ECDH          256              EC              thrpt    3  1346.523 ? 28.722  ops/s
> Benchmark                          (isMontBench)   Mode  Cnt     Score    Error  Units
> PolynomialP256Bench.benchMultiply           true  thrpt    3  1919.574 ? 10.591  ops/s
> 
> Performance, **with intrinsics*...

Volodymyr Paprotski has updated the pull request incrementally with one additional commit since the last revision:

  comments from Sandhya

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/18583/files
  - new: https://git.openjdk.org/jdk/pull/18583/files/8cd095dd..5c360e35

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18583&range=09
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18583&range=08-09

  Stats: 82 lines in 4 files changed: 1 ins; 59 del; 22 mod
  Patch: https://git.openjdk.org/jdk/pull/18583.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18583/head:pull/18583

PR: https://git.openjdk.org/jdk/pull/18583

From duke at openjdk.org  Fri May 17 17:10:09 2024
From: duke at openjdk.org (Volodymyr Paprotski)
Date: Fri, 17 May 2024 17:10:09 GMT
Subject: RFR: 8329538: Accelerate P256 on x86_64 using Montgomery intrinsic
 [v9]
In-Reply-To: <9aJy6ON5gSI5ihwK-WkvnyrtHjJTPN5IAFymf1Jpp9M=.32b8ee27-465d-47d8-9099-22cb846cff9a@github.com>
References: <hanRK4GzOkFV8kG1gZRy8Br53trw4-Tu6G6uO8nsFuk=.d5bf723a-f683-4759-ac9e-4a58cb430f03@github.com>
 <g3g_VMiSRzuhMJ2JIlmtES7TjMGbKWxBMkfFvsQfvOs=.e0dea05e-8adc-48f3-8d1c-81352311de9c@github.com>
 <9aJy6ON5gSI5ihwK-WkvnyrtHjJTPN5IAFymf1Jpp9M=.32b8ee27-465d-47d8-9099-22cb846cff9a@github.com>
Message-ID: <4xhuUYOdlWYYc55JwT3nlFeXj6E5gjrYfauN_RF3DB0=.73d9f401-3dda-4450-94bf-fa4a99cf31e4@github.com>

On Thu, 16 May 2024 23:21:36 GMT, Sandhya Viswanathan <sviswanathan at openjdk.org> wrote:

>> Volodymyr Paprotski has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   whitespace
>
> src/hotspot/cpu/x86/stubGenerator_x86_64_poly_mont.cpp line 168:
> 
>> 166:   XMMRegister broadcast5 = xmm24;
>> 167:   KRegister limb0 = k1;
>> 168:   KRegister limb5 = k2;
> 
> limb5 and select are not being used anymore.

Thanks, fixed (and also broadcast5)

> src/hotspot/cpu/x86/stubGenerator_x86_64_poly_mont.cpp line 185:
> 
>> 183:   __ evmovdquq(modulus, allLimbs, ExternalAddress(modulus_p256()), false, Assembler::AVX_512bit, rscratch);
>> 184: 
>> 185:   // A = load(*aLimbs)
> 
> A little bit more description in comments on what the load step involves would be helpful. e.g. Load upper 4 limbs, shift left by 1 limb using perm, or in the lowest limb.

Done

> src/hotspot/cpu/x86/stubGenerator_x86_64_poly_mont.cpp line 270:
> 
>> 268:   __ push(r14);
>> 269:   __ push(r15);
>> 270: 
> 
> No need to save/restore  rbx, r12, r14, r15.  Only r13 is used as temp in montgomeryMultiply(aLimbs, bLimbs, rLimbs). That too could be easily changed to r8.

Seems I forgot to completely cleanup, thanks! (Originally copied from poly1305 stub)

> src/hotspot/cpu/x86/stubGenerator_x86_64_poly_mont.cpp line 286:
> 
>> 284:   __ mov(aLimbs, c_rarg0);
>> 285:   __ mov(bLimbs, c_rarg1);
>> 286:   __ mov(rLimbs, c_rarg2);
> 
> We could directly call montgomeryMultiply(c_rarg0, c_rarg1, c_rarg2) then these moves are not necessary.

Gave them symbolic names and passed the gpr temp and parameter. vector register map still in the montgomeryMultiply function, but gprs explicitly passed in. 'close enough'?

> src/hotspot/cpu/x86/vm_version_x86.cpp line 1370:
> 
>> 1368: 
>> 1369: #ifdef _LP64
>> 1370:   if (supports_avx512ifma() && supports_avx512vlbw() && MaxVectorSize >= 64) {
> 
> No need to tie the intrinsic to MaxVectorSize setting.

Done

> src/hotspot/share/opto/library_call.cpp line 7564:
> 
>> 7562: 
>> 7563:   if (!stubAddr) return false;
>> 7564:   if (stopped())  return true;
> 
> Line 7564 seems redundant here as there is no range check or anything like that  before this.

Oh. That is what that is for...  I thought it was some soft of 'VM quitting' short-circuit. Removed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18583#discussion_r1605328906
PR Review Comment: https://git.openjdk.org/jdk/pull/18583#discussion_r1605328960
PR Review Comment: https://git.openjdk.org/jdk/pull/18583#discussion_r1605328859
PR Review Comment: https://git.openjdk.org/jdk/pull/18583#discussion_r1605328829
PR Review Comment: https://git.openjdk.org/jdk/pull/18583#discussion_r1605329040
PR Review Comment: https://git.openjdk.org/jdk/pull/18583#discussion_r1605328995

From vklang at openjdk.org  Fri May 17 17:28:02 2024
From: vklang at openjdk.org (Viktor Klang)
Date: Fri, 17 May 2024 17:28:02 GMT
Subject: RFR: 8332154: Memory leak in SynchronousQueue [v3]
In-Reply-To: <SWniN2qSuJq2wU42X1zp7E2ML2PoUxmVF99aRzQU7mE=.778f7892-29d8-4d78-bf4c-e5cd19c151d9@github.com>
References: <Fj3W5LlneHODz3PcBD0Ypu2f34UYvxw1iLLKz5pba-I=.0f419338-0a23-4834-8404-55aeab4b813f@github.com>
 <iMAdASClqlen1dLO4nK3q_RTGtHgMxKeMImJ2J2lGUA=.2de28d45-7faa-4718-ab36-e7201cee0e36@github.com>
 <SWniN2qSuJq2wU42X1zp7E2ML2PoUxmVF99aRzQU7mE=.778f7892-29d8-4d78-bf4c-e5cd19c151d9@github.com>
Message-ID: <4uy6cpANUwyV91gV7Y9XYgFLGcnkq15rLMruR4Zpb8E=.bc209dbc-ab53-4dac-86f1-5b3e97146817@github.com>

On Fri, 17 May 2024 13:49:44 GMT, Doug Lea <dl at openjdk.org> wrote:

>> Viktor Klang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Moving the memory leak test for SynchronousQueue into its own test and runs only for JDK20+, using VirtualThreads
>
> Sure. Seems reasonable.

@DougLea Perfect, thanks for reviewing! ?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19271#issuecomment-2118065006

From rriggs at openjdk.org  Fri May 17 17:29:05 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 17 May 2024 17:29:05 GMT
Subject: RFR: 8331224: ClassCastException in ObjectInputStream hides
 ClassNotFoundException
In-Reply-To: <WwGt00cM9kdSmRkkh5Vs27AanKC0I4DwCBoWhai7itI=.3dde8683-9701-4d87-bf5f-0d0d501bd037@github.com>
References: <WwGt00cM9kdSmRkkh5Vs27AanKC0I4DwCBoWhai7itI=.3dde8683-9701-4d87-bf5f-0d0d501bd037@github.com>
Message-ID: <T6vNQvVW1BSk2oMGssP_zxfTdO6ZlZf_CjXVx24AYBU=.ce123990-7cf1-493b-8833-26523d01d723@github.com>

On Wed, 1 May 2024 18:43:21 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> The issue reported a ClassCastException "cannot assign instance of java.util.CollSer to field of type java.util.Map"
> while deserializing an object referring to an immutable Map that contained a reference to a class that was not available.
> Immutable Collections such as Map utilize a serialization proxy in their serialized form.
> During deserialization the serialization proxy (a private implementation class) was attempted to be set in a field resulting in the ClassCastException. The ClassCastException and bug hid the ClassCastException that should have been thrown.
> 
> When reading record fields or fields of a class, the results of deserialization of individual fields are recorded as dependencies of the object being constructed.
> The apparent bug is that the summary of those dependencies is not checked between reading the fields and invoking the constructor to create the record or assigning the fields to an object being constructed.

Thanks for the review.
I have some ideas to refactor readOrdinaryObject to split out the various subcases and be able to simplify each one.
That's a separate (future) PR.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19043#issuecomment-2118070421

From rriggs at openjdk.org  Fri May 17 17:29:06 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 17 May 2024 17:29:06 GMT
Subject: RFR: 8331224: ClassCastException in ObjectInputStream hides
 ClassNotFoundException
In-Reply-To: <6hKSsT_O-scMHv85LuYVhMj075Tiscp--5W_EFOdSRw=.e1d12da9-3eba-44f0-b5a2-cc14deb86983@github.com>
References: <WwGt00cM9kdSmRkkh5Vs27AanKC0I4DwCBoWhai7itI=.3dde8683-9701-4d87-bf5f-0d0d501bd037@github.com>
 <6hKSsT_O-scMHv85LuYVhMj075Tiscp--5W_EFOdSRw=.e1d12da9-3eba-44f0-b5a2-cc14deb86983@github.com>
Message-ID: <-eBVo9vMgE0Q3amOWMBk0XFixJ_Y4GBeLvkRjYGHXYc=.12ef1f22-5bad-4318-94cc-d42fb7064fd4@github.com>

On Thu, 16 May 2024 21:18:04 GMT, Stuart Marks <smarks at openjdk.org> wrote:

>> The issue reported a ClassCastException "cannot assign instance of java.util.CollSer to field of type java.util.Map"
>> while deserializing an object referring to an immutable Map that contained a reference to a class that was not available.
>> Immutable Collections such as Map utilize a serialization proxy in their serialized form.
>> During deserialization the serialization proxy (a private implementation class) was attempted to be set in a field resulting in the ClassCastException. The ClassCastException and bug hid the ClassCastException that should have been thrown.
>> 
>> When reading record fields or fields of a class, the results of deserialization of individual fields are recorded as dependencies of the object being constructed.
>> The apparent bug is that the summary of those dependencies is not checked between reading the fields and invoking the constructor to create the record or assigning the fields to an object being constructed.
>
> src/java.base/share/classes/java/io/ObjectInputStream.java line 2376:
> 
>> 2374:         if (handles.lookupException(passHandle) != null) {
>> 2375:             return null;     // slot marked with exception, don't create record
>> 2376:         }
> 
> It's proper to avoid creating a record instance in this case. However, returning null is new behavior; this initially seemed a bit odd. The calling method `readOrdinaryObject()` does allow a null return if the class couldn't be resolved, and the body of `readOrdinaryObject()` does allow `obj` to be null throughout. So, returning `null` from here is correct, though it took me a while to puzzle out. :-)
> 
> I'd suggest adding some docs to `readRecord()` to indicate that it returns the record instance if it could be created successfully, null if the record class couldn't be resolved, or throws an error or other exception if one occurred when instantiation was attempted.

As you discovered, though it returns null at this point, the return from readObject checks for the exception and throws ClassNotFoundException.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19043#discussion_r1605347591

From jlu at openjdk.org  Fri May 17 18:08:10 2024
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 17 May 2024 18:08:10 GMT
Subject: RFR: 8332424: Update IANA Language Subtag Registry to Version
 2024-05-16
Message-ID: <EiHinNf2U1SQ2iKSeACo7c_hyftoKjJPQeei-fSdJSY=.b4fdfe97-c866-4bec-932b-c5ae0ecbd24a@github.com>

Please review this PR which is a trivial update to the IANA sub tag registry to version 2024-05-16. Locale tests pass as expected after update.

Associated announcement -> https://mm.icann.org/pipermail/ietf-languages-announcements/2024-May/000091.html

-------------

Commit messages:
 - init

Changes: https://git.openjdk.org/jdk/pull/19286/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19286&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8332424
  Stats: 9 lines in 2 files changed: 6 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/19286.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19286/head:pull/19286

PR: https://git.openjdk.org/jdk/pull/19286

From rriggs at openjdk.org  Fri May 17 18:09:18 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 17 May 2024 18:09:18 GMT
Subject: RFR: 8331224: ClassCastException in ObjectInputStream hides
 ClassNotFoundException [v2]
In-Reply-To: <WwGt00cM9kdSmRkkh5Vs27AanKC0I4DwCBoWhai7itI=.3dde8683-9701-4d87-bf5f-0d0d501bd037@github.com>
References: <WwGt00cM9kdSmRkkh5Vs27AanKC0I4DwCBoWhai7itI=.3dde8683-9701-4d87-bf5f-0d0d501bd037@github.com>
Message-ID: <UINsjDKFSoPStSL9ODLTI5fH5tGzb2ICpCeMxN8a6rQ=.155d68a6-bbe2-40e9-83c7-ac0208549680@github.com>

> The issue reported a ClassCastException "cannot assign instance of java.util.CollSer to field of type java.util.Map"
> while deserializing an object referring to an immutable Map that contained a reference to a class that was not available.
> Immutable Collections such as Map utilize a serialization proxy in their serialized form.
> During deserialization the serialization proxy (a private implementation class) was attempted to be set in a field resulting in the ClassCastException. The ClassCastException and bug hid the ClassCastException that should have been thrown.
> 
> When reading record fields or fields of a class, the results of deserialization of individual fields are recorded as dependencies of the object being constructed.
> The apparent bug is that the summary of those dependencies is not checked between reading the fields and invoking the constructor to create the record or assigning the fields to an object being constructed.

Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:

  Add description of exception behavior when reading components in readRecord()

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19043/files
  - new: https://git.openjdk.org/jdk/pull/19043/files/cb9cad62..d2f1db96

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19043&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19043&range=00-01

  Stats: 7 lines in 1 file changed: 6 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/19043.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19043/head:pull/19043

PR: https://git.openjdk.org/jdk/pull/19043

From naoto at openjdk.org  Fri May 17 19:23:01 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 17 May 2024 19:23:01 GMT
Subject: RFR: 8332424: Update IANA Language Subtag Registry to Version
 2024-05-16
In-Reply-To: <EiHinNf2U1SQ2iKSeACo7c_hyftoKjJPQeei-fSdJSY=.b4fdfe97-c866-4bec-932b-c5ae0ecbd24a@github.com>
References: <EiHinNf2U1SQ2iKSeACo7c_hyftoKjJPQeei-fSdJSY=.b4fdfe97-c866-4bec-932b-c5ae0ecbd24a@github.com>
Message-ID: <7cIKWz15qMwRenStB-nEF9K0T3yq_teVcWZU6JVt_Bo=.4a0c2ba2-f513-4ed8-a1f9-d3bd3ffaaa40@github.com>

On Fri, 17 May 2024 18:04:02 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which is a trivial update to the IANA sub tag registry to version 2024-05-16. Locale tests pass as expected after update.
> 
> Associated announcement -> https://mm.icann.org/pipermail/ietf-languages-announcements/2024-May/000091.html

LGTM

-------------

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19286#pullrequestreview-2064215561

From ccheung at openjdk.org  Fri May 17 19:48:03 2024
From: ccheung at openjdk.org (Calvin Cheung)
Date: Fri, 17 May 2024 19:48:03 GMT
Subject: RFR: 8332340: Add JavacBench as a test case for CDS [v2]
In-Reply-To: <kynGbPSKJOGvy0iND0ZEL42700j2gKku8A8IM1pAfwQ=.5dc84470-1b24-4568-8cd8-328221103e59@github.com>
References: <xqD4PeVZfIAKzywbLnjGZMFh36YSqXNolZkTgh1Vk6E=.44db7c57-64c1-4912-96e1-e61848312ccb@github.com>
 <kynGbPSKJOGvy0iND0ZEL42700j2gKku8A8IM1pAfwQ=.5dc84470-1b24-4568-8cd8-328221103e59@github.com>
Message-ID: <uHz0meNJLwDh09AJIl2LjOw_1OxU3h6Fk2sQCGXMmIE=.6c16cc02-4cac-4701-9b74-90301f9281a2@github.com>

On Thu, 16 May 2024 17:44:22 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> JavacBench is a test program that compiles 90 Java source files. It uses a fair amount of invokedynamic callsites, so it's good for testing CDS support for indy and lambda expressions.
>> 
>> This test was first integrated into the [leyden](https://github.com/openjdk/leyden/tree/premain) repo. Hence some of the files have copyrights in 2023.
>
> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
> 
>   (1) comments from @liach; (2) added javadoc; (3) Use createTestJavaProcessBuilder() instead of createLimitedTestJavaProcessBuilder()

A few minor comments.

test/hotspot/jtreg/runtime/cds/appcds/applications/JavacBench.java line 2:

> 1: /*
> 2:  * Copyright (c) 2023, 2024, Oracle and/or its affiliates. All rights reserved.

Since this is a new file, should the copyright year be only 2024?
(same for other files)

test/hotspot/jtreg/runtime/cds/appcds/applications/JavacBench.java line 43:

> 41: import jdk.test.lib.cds.CDSAppTester;
> 42: import jdk.test.lib.helpers.ClassFileInstaller;
> 43: import jdk.test.lib.process.OutputAnalyzer;

Is this import needed?

test/hotspot/jtreg/runtime/cds/appcds/applications/JavacBenchApp.java line 222:

> 220:         }
> 221:         long elapsed = System.currentTimeMillis() - started;
> 222:         if (System.getProperty("JavacBenchApp.silent") == null) {

Should line 221 be inside the 'if' block?

test/lib/jdk/test/lib/cds/CDSAppTester.java line 218:

> 216:         }
> 217: 
> 218:         throw new RuntimeException("Must have exactly one command line argument: STATIC or DYNAMIC");

Why not check the number of args at the beginning of the method?

-------------

PR Review: https://git.openjdk.org/jdk/pull/19256#pullrequestreview-2064242660
PR Review Comment: https://git.openjdk.org/jdk/pull/19256#discussion_r1605479322
PR Review Comment: https://git.openjdk.org/jdk/pull/19256#discussion_r1605468705
PR Review Comment: https://git.openjdk.org/jdk/pull/19256#discussion_r1605474939
PR Review Comment: https://git.openjdk.org/jdk/pull/19256#discussion_r1605477874

From jjg at openjdk.org  Fri May 17 20:17:24 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Fri, 17 May 2024 20:17:24 GMT
Subject: RFR: 8331879: Clean up non-standard use of /// comments in `java.base`
Message-ID: <BiSTG8MtjyRt2txRK2DIxsmbPPq6Pvp7QQzOnHXbH6w=.b01b4872-dc8b-4e4f-bae6-bdc501da33a6@github.com>

With the advent of JEP 467, `///` comments may be treated as documentation comments, and may be subject to the recently new `javac` warning about "dangling doc comments" in unexpected places.

In keeping with the policy to keep the `java.base` module free of all `javac` warnings, this patch proposes edits to existing uses of `///`.

There are two dominant policies in the proposed changes. 
1. A long horizontal line of `/////` is replaced by `//-----`
2. A long vertical series of lines beginning `///` is replaced by lines beginning `//|`.

As with all style changes, I have also tried to honor local usage, for consistency.

In one place, a pair of comments appeared to contain directives (`CLOVER:ON`, `CLOVER:OFF`).  I investigated the use of such comments to determine that the exact form of the comment prefix was not significant. (Phew!)


(This PR is informally blocked by JEP 467).

-------------

Commit messages:
 - incorporate review comments
 - Merge remote-tracking branch 'upstream/master' into 8330177.dangling-java.base
 - JDK-8331879: Clean up non-standard use of /// comments in `java.base`

Changes: https://git.openjdk.org/jdk/pull/19130/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19130&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8331879
  Stats: 117 lines in 25 files changed: 0 ins; 0 del; 117 mod
  Patch: https://git.openjdk.org/jdk/pull/19130.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19130/head:pull/19130

PR: https://git.openjdk.org/jdk/pull/19130

From duke at openjdk.org  Fri May 17 20:17:25 2024
From: duke at openjdk.org (ExE Boss)
Date: Fri, 17 May 2024 20:17:25 GMT
Subject: RFR: 8331879: Clean up non-standard use of /// comments in
 `java.base`
In-Reply-To: <BiSTG8MtjyRt2txRK2DIxsmbPPq6Pvp7QQzOnHXbH6w=.b01b4872-dc8b-4e4f-bae6-bdc501da33a6@github.com>
References: <BiSTG8MtjyRt2txRK2DIxsmbPPq6Pvp7QQzOnHXbH6w=.b01b4872-dc8b-4e4f-bae6-bdc501da33a6@github.com>
Message-ID: <zNwleFgBrnjwEku8UNdCJg04chsb_tFQmAdV6xDrGEo=.f239c4fe-87f2-4064-9368-095580bb6b5f@github.com>

On Tue, 7 May 2024 22:23:48 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> With the advent of JEP 467, `///` comments may be treated as documentation comments, and may be subject to the recently new `javac` warning about "dangling doc comments" in unexpected places.
> 
> In keeping with the policy to keep the `java.base` module free of all `javac` warnings, this patch proposes edits to existing uses of `///`.
> 
> There are two dominant policies in the proposed changes. 
> 1. A long horizontal line of `/////` is replaced by `//-----`
> 2. A long vertical series of lines beginning `///` is replaced by lines beginning `//|`.
> 
> As with all style changes, I have also tried to honor local usage, for consistency.
> 
> In one place, a pair of comments appeared to contain directives (`CLOVER:ON`, `CLOVER:OFF`).  I investigated the use of such comments to determine that the exact form of the comment prefix was not significant. (Phew!)
> 
> 
> (This PR is informally blocked by JEP 467).

src/java.base/share/classes/jdk/internal/reflect/ClassFileAssembler.java line 206:

> 204:     //-------------
> 205:     // Constants //
> 206:     //-------------

Suggestion:

    //-----------//
    // Constants //
    //-----------//

src/java.base/share/classes/jdk/internal/reflect/ClassFileAssembler.java line 227:

> 225:     //-----------------------------------
> 226:     // Local variable loads and stores //
> 227:     //-----------------------------------

Suggestion:

    //---------------------------------//
    // Local variable loads and stores //
    //---------------------------------//

src/java.base/share/classes/jdk/internal/reflect/ClassFileAssembler.java line 411:

> 409:     //-----------------------------
> 410:     // Widening conversions only //
> 411:     //-----------------------------

Suggestion:

    //---------------------------//
    // Widening conversions only //
    //---------------------------//

src/java.base/share/classes/jdk/internal/reflect/ClassFileAssembler.java line 439:

> 437:     //----------------
> 438:     // Control flow //
> 439:     //----------------

Suggestion:

    //--------------//
    // Control flow //
    //--------------//

src/java.base/share/classes/jdk/internal/reflect/ClassFileAssembler.java line 519:

> 517:     //-----------------------
> 518:     // Return instructions //
> 519:     //-----------------------

Suggestion:

    //---------------------//
    // Return instructions //
    //---------------------//

src/java.base/share/classes/jdk/internal/reflect/ClassFileAssembler.java line 553:

> 551:     //--------------------
> 552:     // Field operations //
> 553:     //--------------------

Suggestion:

    //------------------//
    // Field operations //
    //------------------//

src/java.base/share/classes/jdk/internal/reflect/ClassFileAssembler.java line 581:

> 579:     //----------------------
> 580:     // Method invocations //
> 581:     //----------------------

Suggestion:

    //--------------------//
    // Method invocations //
    //--------------------//

src/java.base/share/classes/jdk/internal/reflect/ClassFileAssembler.java line 632:

> 630:     //----------------
> 631:     // Array length //
> 632:     //----------------

Suggestion:

    //--------------//
    // Array length //
    //--------------//

src/java.base/share/classes/jdk/internal/reflect/ClassFileAssembler.java line 640:

> 638:     //-------
> 639:     // New //
> 640:     //-------

Suggestion:

    //-----//
    // New //
    //-----//

src/java.base/share/classes/jdk/internal/reflect/ClassFileAssembler.java line 650:

> 648:     //----------
> 649:     // Athrow //
> 650:     //----------

Suggestion:

    //--------//
    // Athrow //
    //--------//

src/java.base/share/classes/jdk/internal/reflect/ClassFileAssembler.java line 659:

> 657:     //----------------------------
> 658:     // Checkcast and instanceof //
> 659:     //----------------------------

Suggestion:

    //--------------------------//
    // Checkcast and instanceof //
    //--------------------------//

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19130#discussion_r1593971885
PR Review Comment: https://git.openjdk.org/jdk/pull/19130#discussion_r1593972168
PR Review Comment: https://git.openjdk.org/jdk/pull/19130#discussion_r1593972556
PR Review Comment: https://git.openjdk.org/jdk/pull/19130#discussion_r1593972931
PR Review Comment: https://git.openjdk.org/jdk/pull/19130#discussion_r1593973196
PR Review Comment: https://git.openjdk.org/jdk/pull/19130#discussion_r1593973651
PR Review Comment: https://git.openjdk.org/jdk/pull/19130#discussion_r1593974149
PR Review Comment: https://git.openjdk.org/jdk/pull/19130#discussion_r1593974540
PR Review Comment: https://git.openjdk.org/jdk/pull/19130#discussion_r1593974850
PR Review Comment: https://git.openjdk.org/jdk/pull/19130#discussion_r1593975284
PR Review Comment: https://git.openjdk.org/jdk/pull/19130#discussion_r1593975816

From naoto at openjdk.org  Fri May 17 20:25:03 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 17 May 2024 20:25:03 GMT
Subject: RFR: 8331851: Add specific regression leap year tests for
 Calendar.roll()
In-Reply-To: <kB-PMNTKDCXUa_0GFeslsF_8iTU_P5fpgPzdpp2NmTQ=.b41869f1-5ffb-46a9-a499-6fdca3e98e69@github.com>
References: <kB-PMNTKDCXUa_0GFeslsF_8iTU_P5fpgPzdpp2NmTQ=.b41869f1-5ffb-46a9-a499-6fdca3e98e69@github.com>
Message-ID: <Zx8h8JOdH1qAS2xIPsmCp649c1vDyEiRShtKgMV_C1s=.efc4cda5-176d-4029-a9a3-8ae98aa7d847@github.com>

On Wed, 15 May 2024 09:39:16 GMT, serhiysachkov <duke at openjdk.org> wrote:

> Add specific regression tests for Calendar.roll() method to explicitly various leap year test scenarios. This is inspired by the ambiguity which occurred in leap year unaware test creation as in case with Calendar.add() in swing component test case as detailed in (https://bugs.openjdk.org/browse/JDK-8327088).

LGTM. I might want to remove those test case names as they are apparent from the parameters, but it's OK.

-------------

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19247#pullrequestreview-2064330497

From liach at openjdk.org  Fri May 17 20:26:08 2024
From: liach at openjdk.org (Chen Liang)
Date: Fri, 17 May 2024 20:26:08 GMT
Subject: RFR: 8331879: Clean up non-standard use of /// comments in
 `java.base`
In-Reply-To: <BiSTG8MtjyRt2txRK2DIxsmbPPq6Pvp7QQzOnHXbH6w=.b01b4872-dc8b-4e4f-bae6-bdc501da33a6@github.com>
References: <BiSTG8MtjyRt2txRK2DIxsmbPPq6Pvp7QQzOnHXbH6w=.b01b4872-dc8b-4e4f-bae6-bdc501da33a6@github.com>
Message-ID: <WuF8f74K-h2B3UruUfOvLd-2lQQWbao1NxNfnYbWImA=.32bc2757-d12b-4bf0-aa33-94500ab7e73c@github.com>

On Tue, 7 May 2024 22:23:48 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> With the advent of JEP 467, `///` comments may be treated as documentation comments, and may be subject to the recently new `javac` warning about "dangling doc comments" in unexpected places.
> 
> In keeping with the policy to keep the `java.base` module free of all `javac` warnings, this patch proposes edits to existing uses of `///`.
> 
> There are two dominant policies in the proposed changes. 
> 1. A long horizontal line of `/////` is replaced by `//-----`
> 2. A long vertical series of lines beginning `///` is replaced by lines beginning `//|`.
> 
> As with all style changes, I have also tried to honor local usage, for consistency.
> 
> In one place, a pair of comments appeared to contain directives (`CLOVER:ON`, `CLOVER:OFF`).  I investigated the use of such comments to determine that the exact form of the comment prefix was not significant. (Phew!)
> 
> 
> (This PR is informally blocked by JEP 467).

Will we incorporate the changes for JDK-8 target code as in #19151?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19130#issuecomment-2118330326

From iris at openjdk.org  Fri May 17 20:44:02 2024
From: iris at openjdk.org (Iris Clark)
Date: Fri, 17 May 2024 20:44:02 GMT
Subject: RFR: 8332424: Update IANA Language Subtag Registry to Version
 2024-05-16
In-Reply-To: <EiHinNf2U1SQ2iKSeACo7c_hyftoKjJPQeei-fSdJSY=.b4fdfe97-c866-4bec-932b-c5ae0ecbd24a@github.com>
References: <EiHinNf2U1SQ2iKSeACo7c_hyftoKjJPQeei-fSdJSY=.b4fdfe97-c866-4bec-932b-c5ae0ecbd24a@github.com>
Message-ID: <OUKRASTRnoHPigLqmQF4Z0TrC2gZlqGWUKkCztzjcKc=.a3a3ab6c-c661-451b-8ac4-c091635abdb6@github.com>

On Fri, 17 May 2024 18:04:02 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which is a trivial update to the IANA sub tag registry to version 2024-05-16. Locale tests pass as expected after update.
> 
> Associated announcement -> https://mm.icann.org/pipermail/ietf-languages-announcements/2024-May/000091.html

Marked as reviewed by iris (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/19286#pullrequestreview-2064365331

From duke at openjdk.org  Fri May 17 21:16:47 2024
From: duke at openjdk.org (Volodymyr Paprotski)
Date: Fri, 17 May 2024 21:16:47 GMT
Subject: RFR: 8329538: Accelerate P256 on x86_64 using Montgomery intrinsic
 [v11]
In-Reply-To: <hanRK4GzOkFV8kG1gZRy8Br53trw4-Tu6G6uO8nsFuk=.d5bf723a-f683-4759-ac9e-4a58cb430f03@github.com>
References: <hanRK4GzOkFV8kG1gZRy8Br53trw4-Tu6G6uO8nsFuk=.d5bf723a-f683-4759-ac9e-4a58cb430f03@github.com>
Message-ID: <fGBbKw3Tgk10AKNGXpAXYq3_UJwHj6o-CQ1qoIeEwnA=.bedef41f-cd93-4ed3-89b5-a516787c65d3@github.com>

> Performance. Before:
> 
> Benchmark                        (algorithm)  (dataSize)  (keyLength)  (provider)   Mode  Cnt     Score    Error  Units
> SignatureBench.ECDSA.sign    SHA256withECDSA        1024          256              thrpt    3  6443.934 ?  6.491  ops/s
> SignatureBench.ECDSA.sign    SHA256withECDSA       16384          256              thrpt    3  6152.979 ?  4.954  ops/s
> SignatureBench.ECDSA.verify  SHA256withECDSA        1024          256              thrpt    3  1895.410 ? 36.979  ops/s
> SignatureBench.ECDSA.verify  SHA256withECDSA       16384          256              thrpt    3  1878.955 ? 45.487  ops/s
> Benchmark                                            (algorithm)  (keyLength)  (kpgAlgorithm)  (provider)   Mode  Cnt     Score    Error  Units
> o.o.b.j.c.full.KeyAgreementBench.EC.generateSecret          ECDH          256              EC              thrpt    3  1357.810 ? 26.584  ops/s
> o.o.b.j.c.small.KeyAgreementBench.EC.generateSecret         ECDH          256              EC              thrpt    3  1352.119 ? 23.547  ops/s
> Benchmark                          (isMontBench)   Mode  Cnt     Score    Error  Units
> PolynomialP256Bench.benchMultiply          false  thrpt    3  1746.126 ? 10.970  ops/s
> 
> Performance, no intrinsic:
> 
> Benchmark                        (algorithm)  (dataSize)  (keyLength)  (provider)   Mode  Cnt     Score     Error  Units
> SignatureBench.ECDSA.sign    SHA256withECDSA        1024          256              thrpt    3  6529.839 ?  42.420  ops/s
> SignatureBench.ECDSA.sign    SHA256withECDSA       16384          256              thrpt    3  6199.747 ? 133.566  ops/s
> SignatureBench.ECDSA.verify  SHA256withECDSA        1024          256              thrpt    3  1973.676 ?  54.071  ops/s
> SignatureBench.ECDSA.verify  SHA256withECDSA       16384          256              thrpt    3  1932.127 ?  35.920  ops/s
> Benchmark                                            (algorithm)  (keyLength)  (kpgAlgorithm)  (provider)   Mode  Cnt     Score    Error  Units
> o.o.b.j.c.full.KeyAgreementBench.EC.generateSecret          ECDH          256              EC              thrpt    3  1355.788 ? 29.858  ops/s
> o.o.b.j.c.small.KeyAgreementBench.EC.generateSecret         ECDH          256              EC              thrpt    3  1346.523 ? 28.722  ops/s
> Benchmark                          (isMontBench)   Mode  Cnt     Score    Error  Units
> PolynomialP256Bench.benchMultiply           true  thrpt    3  1919.574 ? 10.591  ops/s
> 
> Performance, **with intrinsics*...

Volodymyr Paprotski has updated the pull request incrementally with one additional commit since the last revision:

  shenandoah verifier

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/18583/files
  - new: https://git.openjdk.org/jdk/pull/18583/files/5c360e35..df4fe6fa

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18583&range=10
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18583&range=09-10

  Stats: 7 lines in 2 files changed: 6 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/18583.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18583/head:pull/18583

PR: https://git.openjdk.org/jdk/pull/18583

From joehw at openjdk.org  Fri May 17 21:57:00 2024
From: joehw at openjdk.org (Joe Wang)
Date: Fri, 17 May 2024 21:57:00 GMT
Subject: RFR: 8330542: Add jaxp-strict.properties in preparation for a
 secure by default configuration [v9]
In-Reply-To: <v1bAYKgH9zfooXpvnBw4Vu2TIqHuKqqtSmgB0hiNp-Q=.31661a99-ecfc-4a05-8045-67b5f680db60@github.com>
References: <v1bAYKgH9zfooXpvnBw4Vu2TIqHuKqqtSmgB0hiNp-Q=.31661a99-ecfc-4a05-8045-67b5f680db60@github.com>
Message-ID: <Ix0ONdjwwypm-CGXnSVefjP2fKRUq6DIiNYrH00tUgY=.6ed08c9e-e6fd-4676-a3f9-63b4eca8eb68@github.com>

> Add two sample configuration files:
> 
>   jaxp-strict.properties: used to set strict configuration, stricter than jaxp.properties in previous versions such as JDK 22
> 
>>   jaxp-compat.properties: used to regain compatibility from any more restricted configuration than previous versions such as JDK 22
> 
> Updated 5/16/2024
> 
> Design change:
> The design is changed to include in the JDK two configuration files that are the default jaxp.properties and jaxp-strict.properties, instead of three, dropping jaxp-compat.properties.

Joe Wang has updated the pull request incrementally with one additional commit since the last revision:

  modernize make copy; update module summary and jaxp-strict.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/18831/files
  - new: https://git.openjdk.org/jdk/pull/18831/files/cf4df792..2ee2c7ca

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18831&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18831&range=07-08

  Stats: 24 lines in 3 files changed: 1 ins; 12 del; 11 mod
  Patch: https://git.openjdk.org/jdk/pull/18831.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18831/head:pull/18831

PR: https://git.openjdk.org/jdk/pull/18831

From joehw at openjdk.org  Fri May 17 21:57:01 2024
From: joehw at openjdk.org (Joe Wang)
Date: Fri, 17 May 2024 21:57:01 GMT
Subject: RFR: 8330542: Add jaxp-strict.properties in preparation for a
 secure by default configuration [v8]
In-Reply-To: <WaojCmjwxI30LQExFov5KlAMiJVqJC7RqZLMtmAOCFc=.2cbfbcc6-6015-43aa-bcc7-5e1bba4b75dd@github.com>
References: <v1bAYKgH9zfooXpvnBw4Vu2TIqHuKqqtSmgB0hiNp-Q=.31661a99-ecfc-4a05-8045-67b5f680db60@github.com>
 <WaojCmjwxI30LQExFov5KlAMiJVqJC7RqZLMtmAOCFc=.2cbfbcc6-6015-43aa-bcc7-5e1bba4b75dd@github.com>
Message-ID: <XdxYDGQuMwX42FIJIVFGiL9BcRdEb-BbzeW9yqwutZE=.ce7fcdf5-1a2d-4f7c-8807-ee1a0c529e2f@github.com>

On Thu, 16 May 2024 22:20:39 GMT, Joe Wang <joehw at openjdk.org> wrote:

>> Add two sample configuration files:
>> 
>>   jaxp-strict.properties: used to set strict configuration, stricter than jaxp.properties in previous versions such as JDK 22
>> 
>>>   jaxp-compat.properties: used to regain compatibility from any more restricted configuration than previous versions such as JDK 22
>> 
>> Updated 5/16/2024
>> 
>> Design change:
>> The design is changed to include in the JDK two configuration files that are the default jaxp.properties and jaxp-strict.properties, instead of three, dropping jaxp-compat.properties.
>
> Joe Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove jaxp-compat.properties from the list

Thanks Alan, Erik! Updated accordingly.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18831#issuecomment-2118424649

From sviswanathan at openjdk.org  Fri May 17 21:58:14 2024
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Fri, 17 May 2024 21:58:14 GMT
Subject: RFR: 8329538: Accelerate P256 on x86_64 using Montgomery intrinsic
 [v11]
In-Reply-To: <fGBbKw3Tgk10AKNGXpAXYq3_UJwHj6o-CQ1qoIeEwnA=.bedef41f-cd93-4ed3-89b5-a516787c65d3@github.com>
References: <hanRK4GzOkFV8kG1gZRy8Br53trw4-Tu6G6uO8nsFuk=.d5bf723a-f683-4759-ac9e-4a58cb430f03@github.com>
 <fGBbKw3Tgk10AKNGXpAXYq3_UJwHj6o-CQ1qoIeEwnA=.bedef41f-cd93-4ed3-89b5-a516787c65d3@github.com>
Message-ID: <GlUfBzCMp1PT7fYsi3sg6r2heCrKN0sCyzye5uM8noA=.f716e4d0-35be-490d-9095-238395fe813f@github.com>

On Fri, 17 May 2024 21:16:47 GMT, Volodymyr Paprotski <duke at openjdk.org> wrote:

>> Performance. Before:
>> 
>> Benchmark                        (algorithm)  (dataSize)  (keyLength)  (provider)   Mode  Cnt     Score    Error  Units
>> SignatureBench.ECDSA.sign    SHA256withECDSA        1024          256              thrpt    3  6443.934 ?  6.491  ops/s
>> SignatureBench.ECDSA.sign    SHA256withECDSA       16384          256              thrpt    3  6152.979 ?  4.954  ops/s
>> SignatureBench.ECDSA.verify  SHA256withECDSA        1024          256              thrpt    3  1895.410 ? 36.979  ops/s
>> SignatureBench.ECDSA.verify  SHA256withECDSA       16384          256              thrpt    3  1878.955 ? 45.487  ops/s
>> Benchmark                                            (algorithm)  (keyLength)  (kpgAlgorithm)  (provider)   Mode  Cnt     Score    Error  Units
>> o.o.b.j.c.full.KeyAgreementBench.EC.generateSecret          ECDH          256              EC              thrpt    3  1357.810 ? 26.584  ops/s
>> o.o.b.j.c.small.KeyAgreementBench.EC.generateSecret         ECDH          256              EC              thrpt    3  1352.119 ? 23.547  ops/s
>> Benchmark                          (isMontBench)   Mode  Cnt     Score    Error  Units
>> PolynomialP256Bench.benchMultiply          false  thrpt    3  1746.126 ? 10.970  ops/s
>> 
>> Performance, no intrinsic:
>> 
>> Benchmark                        (algorithm)  (dataSize)  (keyLength)  (provider)   Mode  Cnt     Score     Error  Units
>> SignatureBench.ECDSA.sign    SHA256withECDSA        1024          256              thrpt    3  6529.839 ?  42.420  ops/s
>> SignatureBench.ECDSA.sign    SHA256withECDSA       16384          256              thrpt    3  6199.747 ? 133.566  ops/s
>> SignatureBench.ECDSA.verify  SHA256withECDSA        1024          256              thrpt    3  1973.676 ?  54.071  ops/s
>> SignatureBench.ECDSA.verify  SHA256withECDSA       16384          256              thrpt    3  1932.127 ?  35.920  ops/s
>> Benchmark                                            (algorithm)  (keyLength)  (kpgAlgorithm)  (provider)   Mode  Cnt     Score    Error  Units
>> o.o.b.j.c.full.KeyAgreementBench.EC.generateSecret          ECDH          256              EC              thrpt    3  1355.788 ? 29.858  ops/s
>> o.o.b.j.c.small.KeyAgreementBench.EC.generateSecret         ECDH          256              EC              thrpt    3  1346.523 ? 28.722  ops/s
>> Benchmark                          (isMontBench)   Mode  Cnt     Score    Error  Units
>> PolynomialP256Bench.benchMultiply           true  thrpt    3  1919.57...
>
> Volodymyr Paprotski has updated the pull request incrementally with one additional commit since the last revision:
> 
>   shenandoah verifier

Marked as reviewed by sviswanathan (Reviewer).

The intrinsics and the C2 changes look good to me.

-------------

PR Review: https://git.openjdk.org/jdk/pull/18583#pullrequestreview-2064439617
PR Comment: https://git.openjdk.org/jdk/pull/18583#issuecomment-2118426661

From jlu at openjdk.org  Fri May 17 21:59:38 2024
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 17 May 2024 21:59:38 GMT
Subject: RFR: 8331485: Odd Results when Parsing Scientific Notation with
 Large Exponent [v6]
In-Reply-To: <lTOZ4RbzZFMN0yLrQKGOcMihdTop24YbYJe2h36SodM=.0addc2ad-b0d1-4721-b860-a9395fa14977@github.com>
References: <lTOZ4RbzZFMN0yLrQKGOcMihdTop24YbYJe2h36SodM=.0addc2ad-b0d1-4721-b860-a9395fa14977@github.com>
Message-ID: <L9rX71_vg7z_ZAbDZE6u-Gbe_KuDPu3C9gq_xc035B4=.6fc97e3a-0bb6-41fd-8975-4877c7588407@github.com>

> Please review this PR which corrects an edge case bug for java.text.DecimalFormat that causes incorrect parsing results for strings with very large exponent values.
> 
> When parsing values with large exponents, if the value of the exponent exceeds `Integer.MAX_VALUE`, the parsed value  is equal to 0. If the value of the exponent exceeds `Long.MAX_VALUE`, the parsed value is equal to the mantissa. Both results are confusing and incorrect.
> 
> For example,
> 
> 
> NumberFormat fmt = NumberFormat.getInstance(Locale.US);
> fmt.parse(".1E2147483648"); // returns 0.0
> fmt.parse(".1E9223372036854775808"); // returns 0.1
> // For comparison
> Double.parseDouble(".1E2147483648"); // returns Infinity
> Double.parseDouble(".1E9223372036854775808"); // returns Infinity
> 
> 
> After this change, both parse calls return `Double.POSITIVE_INFINITY` now.

Justin Lu has updated the pull request incrementally with two additional commits since the last revision:

 - change impl to support whitebox test
 - adjust impl to increase accuracy when decimalAt/exponent value are both around Integer.MAX/MIN

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19075/files
  - new: https://git.openjdk.org/jdk/pull/19075/files/2c167493..7fe44600

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19075&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19075&range=04-05

  Stats: 90 lines in 2 files changed: 65 ins; 12 del; 13 mod
  Patch: https://git.openjdk.org/jdk/pull/19075.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19075/head:pull/19075

PR: https://git.openjdk.org/jdk/pull/19075

From duke at openjdk.org  Fri May 17 22:20:08 2024
From: duke at openjdk.org (Volodymyr Paprotski)
Date: Fri, 17 May 2024 22:20:08 GMT
Subject: RFR: 8329538: Accelerate P256 on x86_64 using Montgomery intrinsic
 [v11]
In-Reply-To: <fGBbKw3Tgk10AKNGXpAXYq3_UJwHj6o-CQ1qoIeEwnA=.bedef41f-cd93-4ed3-89b5-a516787c65d3@github.com>
References: <hanRK4GzOkFV8kG1gZRy8Br53trw4-Tu6G6uO8nsFuk=.d5bf723a-f683-4759-ac9e-4a58cb430f03@github.com>
 <fGBbKw3Tgk10AKNGXpAXYq3_UJwHj6o-CQ1qoIeEwnA=.bedef41f-cd93-4ed3-89b5-a516787c65d3@github.com>
Message-ID: <cL1atpGn49IEGRkdTnrTaSBbN3MWNLh4asnc-lsA01E=.0bb6ba44-52d6-4932-9e5a-6266c82faeef@github.com>

On Fri, 17 May 2024 21:16:47 GMT, Volodymyr Paprotski <duke at openjdk.org> wrote:

>> Performance. Before:
>> 
>> Benchmark                        (algorithm)  (dataSize)  (keyLength)  (provider)   Mode  Cnt     Score    Error  Units
>> SignatureBench.ECDSA.sign    SHA256withECDSA        1024          256              thrpt    3  6443.934 ?  6.491  ops/s
>> SignatureBench.ECDSA.sign    SHA256withECDSA       16384          256              thrpt    3  6152.979 ?  4.954  ops/s
>> SignatureBench.ECDSA.verify  SHA256withECDSA        1024          256              thrpt    3  1895.410 ? 36.979  ops/s
>> SignatureBench.ECDSA.verify  SHA256withECDSA       16384          256              thrpt    3  1878.955 ? 45.487  ops/s
>> Benchmark                                            (algorithm)  (keyLength)  (kpgAlgorithm)  (provider)   Mode  Cnt     Score    Error  Units
>> o.o.b.j.c.full.KeyAgreementBench.EC.generateSecret          ECDH          256              EC              thrpt    3  1357.810 ? 26.584  ops/s
>> o.o.b.j.c.small.KeyAgreementBench.EC.generateSecret         ECDH          256              EC              thrpt    3  1352.119 ? 23.547  ops/s
>> Benchmark                          (isMontBench)   Mode  Cnt     Score    Error  Units
>> PolynomialP256Bench.benchMultiply          false  thrpt    3  1746.126 ? 10.970  ops/s
>> 
>> Performance, no intrinsic:
>> 
>> Benchmark                        (algorithm)  (dataSize)  (keyLength)  (provider)   Mode  Cnt     Score     Error  Units
>> SignatureBench.ECDSA.sign    SHA256withECDSA        1024          256              thrpt    3  6529.839 ?  42.420  ops/s
>> SignatureBench.ECDSA.sign    SHA256withECDSA       16384          256              thrpt    3  6199.747 ? 133.566  ops/s
>> SignatureBench.ECDSA.verify  SHA256withECDSA        1024          256              thrpt    3  1973.676 ?  54.071  ops/s
>> SignatureBench.ECDSA.verify  SHA256withECDSA       16384          256              thrpt    3  1932.127 ?  35.920  ops/s
>> Benchmark                                            (algorithm)  (keyLength)  (kpgAlgorithm)  (provider)   Mode  Cnt     Score    Error  Units
>> o.o.b.j.c.full.KeyAgreementBench.EC.generateSecret          ECDH          256              EC              thrpt    3  1355.788 ? 29.858  ops/s
>> o.o.b.j.c.small.KeyAgreementBench.EC.generateSecret         ECDH          256              EC              thrpt    3  1346.523 ? 28.722  ops/s
>> Benchmark                          (isMontBench)   Mode  Cnt     Score    Error  Units
>> PolynomialP256Bench.benchMultiply           true  thrpt    3  1919.57...
>
> Volodymyr Paprotski has updated the pull request incrementally with one additional commit since the last revision:
> 
>   shenandoah verifier

Thanks Sandhya!

Now that I have @ascarpino approval as well, I plan to integrate next Tuesday.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18583#issuecomment-2118443577

From sviswanathan at openjdk.org  Fri May 17 22:40:15 2024
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Fri, 17 May 2024 22:40:15 GMT
Subject: RFR: 8320448: Accelerate IndexOf using AVX2 [v19]
In-Reply-To: <qqhUK6_L8rqutc-MtL_BzjZbBy88a-TDws9NuLIWC9g=.d97368e7-4b28-439d-959e-fee2ec13d2c9@github.com>
References: <uWi4QxH31hL93771gkl_GgvP0m84IRSoR_1Yi8hD17E=.bc6ed458-7081-4c3f-9348-f59358fa05a4@github.com>
 <eQ4OBFrF8JlDJ1h9awTDOc0kfCc37IlL5vdqtuaqls0=.8f00616d-08e1-4f28-a7a5-5095116d2595@github.com>
 <8Y-nIHc8vfB1X_hp3tpqqqgpCzu6dAt6BBIP_zc4Q70=.c9a48c68-8c14-4af9-8357-ab50e62a5fd3@github.com>
 <qqhUK6_L8rqutc-MtL_BzjZbBy88a-TDws9NuLIWC9g=.d97368e7-4b28-439d-959e-fee2ec13d2c9@github.com>
Message-ID: <rKfqfzL6HnWnqLzEr2TXblb-e3p2k6UwdDVZppmaJ1A=.c23bc708-1211-49aa-9c57-6c2d14515334@github.com>

On Thu, 16 May 2024 20:22:40 GMT, Scott Gibbons <sgibbons at openjdk.org> wrote:

>> src/hotspot/cpu/x86/stubGenerator_x86_64_string.cpp line 1510:
>> 
>>> 1508:   compare_big_haystack_to_needle(sizeKnown, size, NUMBER_OF_NEEDLE_BYTES_TO_COMPARE, loop_top, hsPtrRet, hsLength,
>>> 1509:                                  needleLen, isU, DO_EARLY_BAILOUT, eq_mask, temp2, r10, _masm);
>>> 1510: 
>> 
>> At this point hsLength is not the remaining length from hsPtrRet, would that cause a problem? If not, all the special paths in compare_big_haystack_to_needle need not be generated on this call.
>
> Not sure what you mean here.  I *think* you mean that hsLength is not the length of the remaining bytes in the haystack, but the actual length.  There may be an issue if that is correct, right?  I'll investigate.

Yes, that is what I meant. Thanks for investigating.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1605594796

From sviswanathan at openjdk.org  Fri May 17 22:43:05 2024
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Fri, 17 May 2024 22:43:05 GMT
Subject: RFR: 8320448: Accelerate IndexOf using AVX2 [v19]
In-Reply-To: <qqhUK6_L8rqutc-MtL_BzjZbBy88a-TDws9NuLIWC9g=.d97368e7-4b28-439d-959e-fee2ec13d2c9@github.com>
References: <uWi4QxH31hL93771gkl_GgvP0m84IRSoR_1Yi8hD17E=.bc6ed458-7081-4c3f-9348-f59358fa05a4@github.com>
 <eQ4OBFrF8JlDJ1h9awTDOc0kfCc37IlL5vdqtuaqls0=.8f00616d-08e1-4f28-a7a5-5095116d2595@github.com>
 <8Y-nIHc8vfB1X_hp3tpqqqgpCzu6dAt6BBIP_zc4Q70=.c9a48c68-8c14-4af9-8357-ab50e62a5fd3@github.com>
 <qqhUK6_L8rqutc-MtL_BzjZbBy88a-TDws9NuLIWC9g=.d97368e7-4b28-439d-959e-fee2ec13d2c9@github.com>
Message-ID: <5DbhciTOeJf2n_vsG_R2r35-vFFp3QH3mmOX9hrqC3g=.9117cc86-a514-4e9b-a5d4-7108e72170ae@github.com>

On Thu, 16 May 2024 17:08:21 GMT, Scott Gibbons <sgibbons at openjdk.org> wrote:

>> src/hotspot/cpu/x86/stubGenerator_x86_64_string.cpp line 238:
>> 
>>> 236:     const Register needle       = rdx;
>>> 237:     const Register needle_len   = rcx;
>>> 238: 
>> 
>> This is the calling convention on Linux. How is windows platform handled?
>
> The entry code switches Windows calling convention into Linux calling convention by moving/saving registers, which are properly restored on function exit.  This makes register tracking easier.

I don't see the place where the switch is happening before this initial piece of code.  You also have windows tests failing in the GHA. Could you please double check?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1605596148

From erikj at openjdk.org  Fri May 17 23:06:03 2024
From: erikj at openjdk.org (Erik Joelsson)
Date: Fri, 17 May 2024 23:06:03 GMT
Subject: RFR: 8330542: Add jaxp-strict.properties in preparation for a
 secure by default configuration [v9]
In-Reply-To: <Ix0ONdjwwypm-CGXnSVefjP2fKRUq6DIiNYrH00tUgY=.6ed08c9e-e6fd-4676-a3f9-63b4eca8eb68@github.com>
References: <v1bAYKgH9zfooXpvnBw4Vu2TIqHuKqqtSmgB0hiNp-Q=.31661a99-ecfc-4a05-8045-67b5f680db60@github.com>
 <Ix0ONdjwwypm-CGXnSVefjP2fKRUq6DIiNYrH00tUgY=.6ed08c9e-e6fd-4676-a3f9-63b4eca8eb68@github.com>
Message-ID: <sp8TB3qqRTtA4Uti0M7y-zbyEfBnWtzxraB66sbvFyk=.37fffa5b-e2c4-40cc-9ff5-f727ad4a979d@github.com>

On Fri, 17 May 2024 21:57:00 GMT, Joe Wang <joehw at openjdk.org> wrote:

>> Add two sample configuration files:
>> 
>>   jaxp-strict.properties: used to set strict configuration, stricter than jaxp.properties in previous versions such as JDK 22
>> 
>>>   jaxp-compat.properties: used to regain compatibility from any more restricted configuration than previous versions such as JDK 22
>> 
>> Updated 5/16/2024
>> 
>> Design change:
>> The design is changed to include in the JDK two configuration files that are the default jaxp.properties and jaxp-strict.properties, instead of three, dropping jaxp-compat.properties.
>
> Joe Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   modernize make copy; update module summary and jaxp-strict.

Build change looks good.

-------------

Marked as reviewed by erikj (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18831#pullrequestreview-2064478337

From psandoz at openjdk.org  Fri May 17 23:45:13 2024
From: psandoz at openjdk.org (Paul Sandoz)
Date: Fri, 17 May 2024 23:45:13 GMT
Subject: RFR: 8331865: Consolidate size and alignment checks in LayoutPath
 [v2]
In-Reply-To: <sbhzMEtBjBJuxpO_JdNI4tCiTZwCG8WNBXR5_G2TVXo=.1726357f-4f88-46dc-aaa6-b773df9292df@github.com>
References: <CvKkdESp5-uHiuZtQvGortWnzOMV89pfjaCHNBIV4B4=.51ad0f01-2371-48af-b3c6-8a9b80518cdb@github.com>
 <sbhzMEtBjBJuxpO_JdNI4tCiTZwCG8WNBXR5_G2TVXo=.1726357f-4f88-46dc-aaa6-b773df9292df@github.com>
Message-ID: <ye_axgXODi_M-1C14h-O3Ez0ICuenTZyprTuJ1quZaM=.992dd1fd-4526-4d31-a4b3-f06e18c9cca0@github.com>

On Thu, 16 May 2024 14:37:15 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> When creating a nested memory access var handle, we ensure that the segment is accessed at the correct alignment for the root layout being accessed. But we do not ensure that the segment has at least the size of the accessed root layout. Example:
>> 
>> 
>> MemoryLayout LAYOUT = sequenceLayout(2, structLayout(JAVA_INT.withName("x"), JAVA_INT.withName("y")));
>> VarHandle X_HANDLE = LAYOUT.varHandle(PathElement.sequenceElement(), PathElement.groupElement("x"));
>> 
>> 
>> If I have a memory segment whose size is 12, I can successfully call X_HANDLE on it with index 1, like so:
>> 
>> 
>> MemorySegment segment = Arena.ofAuto().allocate(12);
>> int x = (int)X_HANDLE.get(segment, 0, 1);
>> 
>> 
>> This seems incorrect: after all, the provided segment doesn't have enough space to fit _two_ elements of the nested structs. 
>> 
>> This PR adds checks to detect this kind of scenario earlier, thus improving usability. To achieve this we could, in principle, just tweak `LayoutPath::checkEnclosingLayout` and add the required size check.
>> 
>> But doing so will add yet another redundant check on top of the other already added by [pull/19124](https://git.openjdk.org/jdk/pull/19124). Instead, this PR rethinks how memory segment var handles are created, in order to eliminate redundant checks.
>> 
>> The main observation is that size and alignment checks depend on an _enclosing_ layout. This layout *might* be the very same value layout being accessed (this is the case when e.g. using `JAVA_INT.varHandle()`). But, in the general case, the accessed value layout and the enclosing layout might differ (e.g. think about accessing a struct field).
>> 
>> Furthermore, the enclosing layout check depends on the _base_ offset at which the segment is accessed, _prior_ to any index computation that occurs if the accessed layout path has any open elements. It is important to notice that this base offset is only available when looking at the var handle that is returned to the user. For instance, an indexed var handle with coordinates:
>> 
>> 
>> (MemorySegment, long /* base */, long /* index 1 */, long /* index 2 */, long /* index 3 */)
>> 
>> 
>> Is obtained through adaptation, by taking a more basic var handle of the form:
>> 
>> 
>> (MemorySegment, long /* offset */)
>> 
>> 
>> And then injecting the result of the index multiplication into `offset`. As such, we can't add an enclosing layout check inside the var handle returned by `VarHandles::memorySegmentViewHandle`, as doing so will end up seeing the *wrong* off...
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix copyrights

Took me a few passes to work it all out. Looks good. All the bounds checking action now consistently passes through the call to `checkEnclosingLayout` in adaption of the raw (and unsafe) segment accessing VarHandle.

Separately, we might be missing a few long argument accepting guard methods for simpler cases as I suspect they are still focused more on int index types.

-------------

PR Review: https://git.openjdk.org/jdk/pull/19251#pullrequestreview-2064493620

From sgibbons at openjdk.org  Fri May 17 23:47:45 2024
From: sgibbons at openjdk.org (Scott Gibbons)
Date: Fri, 17 May 2024 23:47:45 GMT
Subject: RFR: 8320448: Accelerate IndexOf using AVX2 [v20]
In-Reply-To: <uWi4QxH31hL93771gkl_GgvP0m84IRSoR_1Yi8hD17E=.bc6ed458-7081-4c3f-9348-f59358fa05a4@github.com>
References: <uWi4QxH31hL93771gkl_GgvP0m84IRSoR_1Yi8hD17E=.bc6ed458-7081-4c3f-9348-f59358fa05a4@github.com>
Message-ID: <zveo9CR_AqXFJWd23RU784fOfMEHg13VDMrD-KDtVWw=.e3036047-55dd-4584-bd9a-6de1e79c1bbd@github.com>

> Re-write the IndexOf code without the use of the pcmpestri instruction, only using AVX2 instructions.  This change accelerates String.IndexOf on average 1.3x for AVX2.  The benchmark numbers:
> 
> 
> Benchmark	                                               Score		Latest		
> StringIndexOf.advancedWithMediumSub   343.573		317.934		0.925375393x
> StringIndexOf.advancedWithShortSub1	  1039.081		1053.96		1.014319384x
> StringIndexOf.advancedWithShortSub2	      55.828		110.541		1.980027943x
> StringIndexOf.constantPattern	                9.361		11.906		1.271872663x
> StringIndexOf.searchCharLongSuccess	        4.216		4.218		1.000474383x
> StringIndexOf.searchCharMediumSuccess	3.133		3.216		1.02649218x
> StringIndexOf.searchCharShortSuccess	3.76		        3.761		1.000265957x
> StringIndexOf.success	                                9.186		9.713		1.057369911x
> StringIndexOf.successBig	                      14.341		46.343		3.231504079x
> StringIndexOfChar.latin1_AVX2_String	  6220.918		12154.52		1.953814533x
> StringIndexOfChar.latin1_AVX2_char	  5503.556		5540.044		1.006629895x
> StringIndexOfChar.latin1_SSE4_String	  6978.854		6818.689		0.977049957x
> StringIndexOfChar.latin1_SSE4_char	  5657.499		5474.624		0.967675646x
> StringIndexOfChar.latin1_Short_String	  7132.541		6863.359		0.962260014x
> StringIndexOfChar.latin1_Short_char	16013.389	      16162.437		1.009307711x
> StringIndexOfChar.latin1_mixed_String	  7386.123	      14771.622		1.999915517x
> StringIndexOfChar.latin1_mixed_char	  9901.671		9782.245		0.987938803

Scott Gibbons has updated the pull request incrementally with one additional commit since the last revision:

  Addressing lots of comments.  Interim commit.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/16753/files
  - new: https://git.openjdk.org/jdk/pull/16753/files/fb4da92a..9a861979

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16753&range=19
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16753&range=18-19

  Stats: 1639 lines in 9 files changed: 429 ins; 683 del; 527 mod
  Patch: https://git.openjdk.org/jdk/pull/16753.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16753/head:pull/16753

PR: https://git.openjdk.org/jdk/pull/16753

From sgibbons at openjdk.org  Fri May 17 23:56:07 2024
From: sgibbons at openjdk.org (Scott Gibbons)
Date: Fri, 17 May 2024 23:56:07 GMT
Subject: RFR: 8320448: Accelerate IndexOf using AVX2 [v19]
In-Reply-To: <5DbhciTOeJf2n_vsG_R2r35-vFFp3QH3mmOX9hrqC3g=.9117cc86-a514-4e9b-a5d4-7108e72170ae@github.com>
References: <uWi4QxH31hL93771gkl_GgvP0m84IRSoR_1Yi8hD17E=.bc6ed458-7081-4c3f-9348-f59358fa05a4@github.com>
 <eQ4OBFrF8JlDJ1h9awTDOc0kfCc37IlL5vdqtuaqls0=.8f00616d-08e1-4f28-a7a5-5095116d2595@github.com>
 <8Y-nIHc8vfB1X_hp3tpqqqgpCzu6dAt6BBIP_zc4Q70=.c9a48c68-8c14-4af9-8357-ab50e62a5fd3@github.com>
 <qqhUK6_L8rqutc-MtL_BzjZbBy88a-TDws9NuLIWC9g=.d97368e7-4b28-439d-959e-fee2ec13d2c9@github.com>
 <5DbhciTOeJf2n_vsG_R2r35-vFFp3QH3mmOX9hrqC3g=.9117cc86-a514-4e9b-a5d4-7108e72170ae@github.com>
Message-ID: <TUr7U4cqY4M_B1VzG28-liLSFH8V5eYtmyc6PQpdcIk=.94c9114d-f03c-4821-b11a-11333179692c@github.com>

On Fri, 17 May 2024 22:40:50 GMT, Sandhya Viswanathan <sviswanathan at openjdk.org> wrote:

>> The entry code switches Windows calling convention into Linux calling convention by moving/saving registers, which are properly restored on function exit.  This makes register tracking easier.
>
> I don't see the place where the switch is happening before this initial piece of code.  You also have windows tests failing in the GHA. Could you please double check?

Fixed to use c_rargX

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1605618391

From sgibbons at openjdk.org  Fri May 17 23:56:08 2024
From: sgibbons at openjdk.org (Scott Gibbons)
Date: Fri, 17 May 2024 23:56:08 GMT
Subject: RFR: 8320448: Accelerate IndexOf using AVX2 [v19]
In-Reply-To: <b_a8wi88dvCkofFPkN93FTN-IEnqB36Z1InXjGhVcLI=.023c0009-bbcb-4110-8b28-1189546e49d2@github.com>
References: <uWi4QxH31hL93771gkl_GgvP0m84IRSoR_1Yi8hD17E=.bc6ed458-7081-4c3f-9348-f59358fa05a4@github.com>
 <eQ4OBFrF8JlDJ1h9awTDOc0kfCc37IlL5vdqtuaqls0=.8f00616d-08e1-4f28-a7a5-5095116d2595@github.com>
 <b_a8wi88dvCkofFPkN93FTN-IEnqB36Z1InXjGhVcLI=.023c0009-bbcb-4110-8b28-1189546e49d2@github.com>
Message-ID: <8-W2sMyDMG71FBi7q_BLwiRoUj5Drr_J2IHiJPAtXd8=.a92b0aa8-402b-4d3e-9eb5-60e5d125920a@github.com>

On Tue, 14 May 2024 18:38:38 GMT, Sandhya Viswanathan <sviswanathan at openjdk.org> wrote:

>> Scott Gibbons has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Rearrange; add lambdas for clarity
>
> src/hotspot/cpu/x86/stubGenerator_x86_64_string.cpp line 1784:
> 
>> 1782:       __ subq(tmp, haystack_len);
>> 1783:     }
>> 1784:     __ leaq(haystack, Address(rsp, tmp, Address::times_1));
> 
> This whole code is repeated in two places. Could be made into a function and used at both places.

This is the only place now.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1605617739

From sgibbons at openjdk.org  Sat May 18 00:02:17 2024
From: sgibbons at openjdk.org (Scott Gibbons)
Date: Sat, 18 May 2024 00:02:17 GMT
Subject: RFR: 8320448: Accelerate IndexOf using AVX2 [v19]
In-Reply-To: <nltV33bCbp2YSk4oIRnJNPnL1eP6SmMjuw1V38yzVks=.0ddb70b7-6607-4067-9321-9653c17b2507@github.com>
References: <uWi4QxH31hL93771gkl_GgvP0m84IRSoR_1Yi8hD17E=.bc6ed458-7081-4c3f-9348-f59358fa05a4@github.com>
 <eQ4OBFrF8JlDJ1h9awTDOc0kfCc37IlL5vdqtuaqls0=.8f00616d-08e1-4f28-a7a5-5095116d2595@github.com>
 <nltV33bCbp2YSk4oIRnJNPnL1eP6SmMjuw1V38yzVks=.0ddb70b7-6607-4067-9321-9653c17b2507@github.com>
Message-ID: <gcQmag_0ZYPmcwE352WgSz9ME2oKppTC5lOqtoFKYR8=.c0e2cfce-5615-4b63-8169-d4386313fe1e@github.com>

On Tue, 14 May 2024 00:38:30 GMT, Sandhya Viswanathan <sviswanathan at openjdk.org> wrote:

>> Scott Gibbons has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Rearrange; add lambdas for clarity
>
> src/hotspot/cpu/x86/stubGenerator_x86_64_string.cpp line 1178:
> 
>> 1176:     __ andq(eq_mask, lastMask);
>> 1177:     if (needToSaveRCX) {
>> 1178:       __ movdq(rcx, saveRCX);
> 
> movdq is an expensive instruction (about 3 cycle). If we have another gpr temporary available here for shiftVal, then we dont need to do save/restore rcx.

No longer need to use rcx.  Refactored.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1605619614

From sgibbons at openjdk.org  Sat May 18 00:02:17 2024
From: sgibbons at openjdk.org (Scott Gibbons)
Date: Sat, 18 May 2024 00:02:17 GMT
Subject: RFR: 8320448: Accelerate IndexOf using AVX2 [v19]
In-Reply-To: <aTbnceYj7mQGE4hpCoeUqv5r-W8iHSI_EqVncR0iU_s=.6a63f8c5-eafb-48d5-a871-4cc475e0f63f@github.com>
References: <uWi4QxH31hL93771gkl_GgvP0m84IRSoR_1Yi8hD17E=.bc6ed458-7081-4c3f-9348-f59358fa05a4@github.com>
 <eQ4OBFrF8JlDJ1h9awTDOc0kfCc37IlL5vdqtuaqls0=.8f00616d-08e1-4f28-a7a5-5095116d2595@github.com>
 <aTbnceYj7mQGE4hpCoeUqv5r-W8iHSI_EqVncR0iU_s=.6a63f8c5-eafb-48d5-a871-4cc475e0f63f@github.com>
Message-ID: <VO8cxJFwYuRGtF7af2NsAAIC2cmWQVSPb0_pkN-wm-E=.738560f5-0763-49d6-87fa-83c0b717ce4a@github.com>

On Wed, 15 May 2024 19:18:02 GMT, Volodymyr Paprotski <duke at openjdk.org> wrote:

>> Scott Gibbons has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Rearrange; add lambdas for clarity
>
> test/jdk/java/lang/StringBuffer/IndexOf.java line 40:
> 
>> 38:   private static boolean failure = false;
>> 39:   public static void main(String[] args) throws Exception {
>> 40:     String testName = "IndexOf";
> 
> intentation

Fixed

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1605619940

From liach at openjdk.org  Sat May 18 01:24:04 2024
From: liach at openjdk.org (Chen Liang)
Date: Sat, 18 May 2024 01:24:04 GMT
Subject: RFR: 8319386: Migrate Class::getEnclosingMethod/Constructor away
 from old generic utilities
In-Reply-To: <m_3JWl2xIxOyUfVZcw81KFstod7aixVqaQAZOunqvtM=.2b08b168-30e8-4e23-8fa2-79189fc1c888@github.com>
References: <m_3JWl2xIxOyUfVZcw81KFstod7aixVqaQAZOunqvtM=.2b08b168-30e8-4e23-8fa2-79189fc1c888@github.com>
Message-ID: <72D_G2xfqTdLRLt4bB2xmMMYeDXIIBlSfjIlWim4xzI=.4f0ff348-82e5-4da8-84d4-4add959d6dac@github.com>

On Fri, 3 Nov 2023 14:03:02 GMT, Chen Liang <liach at openjdk.org> wrote:

> Please review a patch that migrates `Class::getEnclosingMethod` and `Class::getEnclosingConstructor`'s descriptor parsing from old generic utilities to more simple utilities from java.lang.invoke implementation. This will help migrate away from the old generic repositories in the future.
> 
> The `getClassLoader()` call plus https://github.com/openjdk/jdk/blob/1a21c1a783d64ca0930c358c06a43975f96ffac6/src/java.base/share/classes/sun/invoke/util/BytecodeDescriptor.java#L93
> should be functionally equivalent to the previous `getDeclsLoader()`
> https://github.com/openjdk/jdk/blob/1a21c1a783d64ca0930c358c06a43975f96ffac6/src/java.base/share/classes/sun/reflect/generics/factory/CoreReflectionFactory.java#L60-L68
> plus
> https://github.com/openjdk/jdk/blob/1a21c1a783d64ca0930c358c06a43975f96ffac6/src/java.base/share/classes/sun/reflect/generics/factory/CoreReflectionFactory.java#L113-L114

Superseded by #19281

-------------

PR Comment: https://git.openjdk.org/jdk/pull/16496#issuecomment-2118545901

From jpai at openjdk.org  Sat May 18 11:43:02 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Sat, 18 May 2024 11:43:02 GMT
Subject: RFR: 8331671: Implement JEP 472: Prepare to Restrict the Use of
 JNI [v8]
In-Reply-To: <vWr2PdgTv6vEllxW8820KO3aZ3tR3xvMhCxD2k7QpS0=.8bfd6c47-6c93-4fc3-aced-7079889aa6a2@github.com>
References: <CZGbki5iFdCGPPagE-ya-_L8Nkgf7OunywApOsxC548=.2cee82fa-a5d2-4165-b012-30982a85030a@github.com>
 <vWr2PdgTv6vEllxW8820KO3aZ3tR3xvMhCxD2k7QpS0=.8bfd6c47-6c93-4fc3-aced-7079889aa6a2@github.com>
Message-ID: <_4CgX7Ojzb5QH2sJ4k2fDgfz_zba03l_4feYaVyzhl0=.a6128ce8-56c3-4b71-a0e3-cf48c9b68c3e@github.com>

On Fri, 17 May 2024 13:38:25 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This PR implements [JEP 472](https://openjdk.org/jeps/472), by restricting the use of JNI in the following ways:
>> 
>> * `System::load` and `System::loadLibrary` are now restricted methods
>> * `Runtime::load` and `Runtime::loadLibrary` are now restricted methods
>> * binding a JNI `native` method declaration to a native implementation is now considered a restricted operation
>> 
>> This PR slightly changes the way in which the JDK deals with restricted methods, even for FFM API calls. In Java 22, the single `--enable-native-access` was used both to specify a set of modules for which native access should be allowed *and* to specify whether illegal native access (that is, native access occurring from a module not specified by `--enable-native-access`) should be treated as an error or a warning. More specifically, an error is only issued if the `--enable-native-access flag` is used at least once.
>> 
>> Here, a new flag is introduced, namely `illegal-native-access=allow/warn/deny`, which is used to specify what should happen when access to a restricted method and/or functionality is found outside the set of modules specified with `--enable-native-access`. The default policy is `warn`, but users can select `allow` to suppress the warnings, or `deny` to cause `IllegalCallerException` to be thrown. This aligns the treatment of restricted methods with other mechanisms, such as `--illegal-access` and the more recent `--sun-misc-unsafe-memory-access`.
>> 
>> Some changes were required in the package-info javadoc for `java.lang.foreign`, to reflect the changes in the command line flags described above.
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address review comments

Marked as reviewed by jpai (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/19213#pullrequestreview-2064736036

From nbenalla at openjdk.org  Sat May 18 21:26:27 2024
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Sat, 18 May 2024 21:26:27 GMT
Subject: RFR: 8331051: Add an `@since` checker test for `java.base` module
 [v6]
In-Reply-To: <NRZmbFYvDwXPuizcmCilJx5Yb6HjZ-2fJa-YILxYUl8=.a79f79e4-77d5-4910-b3df-5e78bb7e402b@github.com>
References: <NRZmbFYvDwXPuizcmCilJx5Yb6HjZ-2fJa-YILxYUl8=.a79f79e4-77d5-4910-b3df-5e78bb7e402b@github.com>
Message-ID: <m29qqpi7aIeOW6ond7_Q5rqvADeS-b7mmnFJ0tXbbKk=.9a1d002b-f5f2-4db1-87c0-e9dad4808379@github.com>

> This checker checks the values of the `@since` tag found in the documentation comment for an element against the release in which the element first appeared.
> 
> Real since value of an API element is computed as the oldest release in which the given API element was introduced. That is:
> - for modules, classes and interfaces, the release in which the element with the given qualified name was introduced
> - for constructors, the release in which the constructor with the given VM descriptor was introduced
> - for methods and fields, the release in which the given method or field with the given VM descriptor became a member of its enclosing class or interface, whether direct or inherited
> 
> Effective since value of an API element is computed as follows:
> - if the given element has a `@since` tag in its javadoc, it is used
> - in all other cases, return the effective since value of the enclosing element
> 
> The since checker verifies that for every API element, the real since value and the effective since value are the same, and reports an error if they are not.
> 
> Preview method are handled as per JEP 12, if `@PreviewFeature` is used consistently going forward then the checker doesn't need to be updated with every release. The checker has explicit knowledge of preview elements that came before `JDK 14` because they weren't marked in a machine understandable way and preview elements that came before `JDK 17` that didn't have `@PreviewFeature`.
> 
> Important note : We only check code written since `JDK 9` as the releases used to determine the expected value of `@since` tags are taken from the historical data built into `javac` which only goes back that far
> 
> The intial comment at the beginning of `SinceChecker.java` holds more information into the program.
> 
> I already have filed issues and fixed some wrong tags like in #18640, #18032, #18030, #18055, #18373, #18954, #18972.

Nizar Benalla 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 13 additional commits since the last revision:

 - checking for null values directly rather than catching NPE
 - Merge remote-tracking branch 'upstream/master' into source-based-since-checker
 - Now only skipping the common methods that every record class will have, and will never need a new `@since`
 - - Not checking elements enclosed within a record, I doubt a record class will change after being created
   - Added a null check as `toString` can return an exception
 - - Added some legacy modules that existed long before preview features (they were incubating)
   - Not checking elements enclosed withing a record
   - Only check if the file is readable using `Files.isReadable`
   - Dropped the use of `Files.exists` and `Files.isDirectory`
   - Use `--add-modules` option now to resolve certain modules
 - mention packages in initial comment
 - -Wrap lines at 80-100
   -Changes `e.getMessages` to `e`
   -`File.separator` to be platform indepedant
   -Added a newline character at the end of files
   -Rename `persistElement` to `processElement`
   -Now throwing IllegalArgumentException instead of SkippedException
 - trivial change - extra parentheses
 - General improvements:
   - added more detail to the initial comment
   - ordered imports correctly
   - renamed methods to be more consistent
   - added predicate methods and 'isDocumented' 'isMember'
   - added doc comments describing purpose of 'EffectiveSourceSinceHelper'
 - Add more details to the initial comment
 - ... and 3 more: https://git.openjdk.org/jdk/compare/aed682c5...e82dfbf0

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/18934/files
  - new: https://git.openjdk.org/jdk/pull/18934/files/48c87814..e82dfbf0

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18934&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18934&range=04-05

  Stats: 77304 lines in 2370 files changed: 38057 ins; 29029 del; 10218 mod
  Patch: https://git.openjdk.org/jdk/pull/18934.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18934/head:pull/18934

PR: https://git.openjdk.org/jdk/pull/18934

From nbenalla at openjdk.org  Sat May 18 21:26:27 2024
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Sat, 18 May 2024 21:26:27 GMT
Subject: RFR: 8331051: Add an `@since` checker test for `java.base` module
 [v5]
In-Reply-To: <_PQwl4FscLiS1bgx11f6eCygo3ukz5hQJKAKVgJ2ufs=.0f9f3c30-85da-4dcf-b2de-d01ba60f1c17@github.com>
References: <NRZmbFYvDwXPuizcmCilJx5Yb6HjZ-2fJa-YILxYUl8=.a79f79e4-77d5-4910-b3df-5e78bb7e402b@github.com>
 <PlsvKjixjw77eZxhBvJzNJe-PUHhcgrJW20-4LMJdAA=.c743c945-d71a-4a5c-865d-e1b0da2476b3@github.com>
 <_PQwl4FscLiS1bgx11f6eCygo3ukz5hQJKAKVgJ2ufs=.0f9f3c30-85da-4dcf-b2de-d01ba60f1c17@github.com>
Message-ID: <4PjkhpXc_kEvl9YWQLKAxGblNx6CHFXggQ_ZEqs_ui0=.5534ab65-04a2-4f94-920c-097ffe7850a3@github.com>

On Fri, 17 May 2024 14:49:46 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> Nizar Benalla has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   - Not checking elements enclosed within a record, I doubt a record class will change after being created
>>   - Added a null check as `toString` can return an exception
>
> test/jdk/tools/sincechecker/SinceChecker.java line 224:
> 
>> 222:         }
>> 223: 
>> 224:         return LEGACY_PREVIEW_METHODS.containsKey(currentVersion)
> 
> Nit: could probably be `LEGACY_PREVIEW_METHODS.getOrDefault(currentVersion, Map.of()).contains(uniqueId)`

Fixed, thanks.

> test/jdk/tools/sincechecker/SinceChecker.java line 309:
> 
>> 307:                 error("module-info.java not found or couldn't be opened AND this module has no unqualified exports");
>> 308:             } catch (NullPointerException e) {
>> 309:                 error("module-info.java does not contain an `@since`");
> 
> Catching a NPE like this feels like a code smell to me. I assume it may happen when `extractSinceVersionFromText(moduleInfoContent)` returns `null` - so just store that in a variable, and check for `null` there.

Fixed in [e82dfbf](https://github.com/openjdk/jdk/pull/18934/commits/e82dfbf0f3df1dfcb1e482aac09fb34e39af9be0), I tried not catching NPE before but found the extra checks a bit ugly.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18934#discussion_r1605898860
PR Review Comment: https://git.openjdk.org/jdk/pull/18934#discussion_r1605898785

From nbenalla at openjdk.org  Sat May 18 21:32:03 2024
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Sat, 18 May 2024 21:32:03 GMT
Subject: RFR: 8331051: Add an `@since` checker test for `java.base` module
 [v5]
In-Reply-To: <_PQwl4FscLiS1bgx11f6eCygo3ukz5hQJKAKVgJ2ufs=.0f9f3c30-85da-4dcf-b2de-d01ba60f1c17@github.com>
References: <NRZmbFYvDwXPuizcmCilJx5Yb6HjZ-2fJa-YILxYUl8=.a79f79e4-77d5-4910-b3df-5e78bb7e402b@github.com>
 <PlsvKjixjw77eZxhBvJzNJe-PUHhcgrJW20-4LMJdAA=.c743c945-d71a-4a5c-865d-e1b0da2476b3@github.com>
 <_PQwl4FscLiS1bgx11f6eCygo3ukz5hQJKAKVgJ2ufs=.0f9f3c30-85da-4dcf-b2de-d01ba60f1c17@github.com>
Message-ID: <lTJ21ebx0H5hY0TzqRIHrN7CqZGH6iIrQjJPuOG-3j8=.2f74ee52-6802-4650-806a-a9f5c54a753b@github.com>

On Fri, 17 May 2024 15:00:39 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> Nizar Benalla has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   - Not checking elements enclosed within a record, I doubt a record class will change after being created
>>   - Added a null check as `toString` can return an exception
>
> test/jdk/tools/sincechecker/SinceChecker.java line 352:
> 
>> 350:         }
>> 351:         checkElement(te.getEnclosingElement(), te, types, javadocHelper, version, elementUtils);
>> 352:         if( te.getKind() == ElementKind.RECORD){
> 
> This seems a bit too broad. Ignoring all members of a record type may lead to missed members. `Elements.getOrigin` may be unusable here, but I wonder what exactly is the problem which this condition is trying to solve?

I changed my approach in [ac4df85](https://github.com/openjdk/jdk/pull/18934/commits/ac4df85615557306da606a712ee02e7155e5412f). I beleieve it is a bit clearer now. I am only skipping some very common methods (`toString`, `equals` and `hashCode`)

Previously, I failed to get the effective `@since` of some common methods eclosed within a record.
I will use this as an example
https://github.com/openjdk/jdk/blob/b92bd671835c37cff58e2cdcecd0fe4277557d7f/src/jdk.jshell/share/classes/jdk/jshell/execution/JdiDefaultExecutionControl.java#L346

`te.getEnclosedElements()` on this record returns the following (I truncated `jdk.jshell.execution.JdiDefaultExecutionControl.JdiStarter.TargetDescription` into `TargetDescription`)

method: void TargetDescription.<init>(com.sun.jdi.VirtualMachine,java.lang.Process) 
method: void TargetDescription.wait(long,int) 
method: java.lang.Process TargetDescription.process() 
method: com.sun.jdi.VirtualMachine TargetDescription.vm() 
method: java.lang.String TargetDescription.toString() 
method: int TargetDescription.hashCode() 
method: java.lang.Object TargetDescription.clone() 
method: java.lang.Class TargetDescription.getClass() 
method: void TargetDescription.finalize() 
method: void TargetDescription.notify() 
method: void TargetDescription.wait(long) 
method: boolean TargetDescription.equals(java.lang.Object) 
method: void TargetDescription.notifyAll() 
method: void TargetDescription.wait() 


Getting the effective `@since` for these 5 methods in particular would fail

method: java.lang.String TargetDescription.toString():
method: int TargetDescription.hashCode(): 
method: boolean TargetDescription.equals(java.lang.Object):
method: com.sun.jdi.VirtualMachine TargetDescription.vm(): 
method: java.lang.Process TargetDescription.process():

It seemed to me that these methods would be added in the same version as the record, so I skipped them all.
I didn't think of a user adding a static variable in a later release and that it was too broad, my bad.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18934#discussion_r1605899531

From joehw at openjdk.org  Sun May 19 05:01:32 2024
From: joehw at openjdk.org (Joe Wang)
Date: Sun, 19 May 2024 05:01:32 GMT
Subject: RFR: 8330542: Add jaxp-strict.properties in preparation for a
 secure by default configuration [v10]
In-Reply-To: <v1bAYKgH9zfooXpvnBw4Vu2TIqHuKqqtSmgB0hiNp-Q=.31661a99-ecfc-4a05-8045-67b5f680db60@github.com>
References: <v1bAYKgH9zfooXpvnBw4Vu2TIqHuKqqtSmgB0hiNp-Q=.31661a99-ecfc-4a05-8045-67b5f680db60@github.com>
Message-ID: <Jc4tdJwAUMokA_Zm15xcJDE6FLlmWI4JTCcW3uo8gPU=.a4ffc7d1-0e3e-408a-bb65-976e5095a831@github.com>

> Add two sample configuration files:
> 
>   jaxp-strict.properties: used to set strict configuration, stricter than jaxp.properties in previous versions such as JDK 22
> 
>>   jaxp-compat.properties: used to regain compatibility from any more restricted configuration than previous versions such as JDK 22
> 
> Updated 5/16/2024
> 
> Design change:
> The design is changed to include in the JDK two configuration files that are the default jaxp.properties and jaxp-strict.properties, instead of three, dropping jaxp-compat.properties.

Joe Wang has updated the pull request incrementally with one additional commit since the last revision:

  withdraw changes to jaxp.properties. The configuration process has not changed, changing the default configuration would result in many failures that test the process.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/18831/files
  - new: https://git.openjdk.org/jdk/pull/18831/files/2ee2c7ca..dfc965c6

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18831&range=09
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18831&range=08-09

  Stats: 10 lines in 2 files changed: 0 ins; 0 del; 10 mod
  Patch: https://git.openjdk.org/jdk/pull/18831.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18831/head:pull/18831

PR: https://git.openjdk.org/jdk/pull/18831

From duke at openjdk.org  Mon May 20 00:09:10 2024
From: duke at openjdk.org (Oussama Louati)
Date: Mon, 20 May 2024 00:09:10 GMT
Subject: RFR: 8307818: Convert Indify tool to Classfile API
Message-ID: <tCFk9yrCtcoBnzvNIgceY0eOaXg9ZiN9nkCuhHIyMyw=.9cc5f994-8d35-411a-bb39-7c3f2ac34dda@github.com>

An indify tool in j.l.i tests (also in vmTestBase) convert some source-code private static methods with MT_ MH_, and INDY_ prefixes into MethodHandle, MethodType, and CallSite constants.
It currently uses ad-hoc code to process class files and intends to migrate to ASM; but since we have the Classfile API, we can migrate to Classfile API instead.

-------------

Commit messages:
 - chore: apply review suggestion
 - chore: apply review suggestion
 - fix: fix test
 - fix: Return access modifiers to their original state
 - fix: Return access modifiers to their original state
 - fix: fixed code
 - fix: fix code
 - remove: remove old implementation of Indify
 - add: add full indify implementation using the CP API
 - fix: got rid of the Bytecode inner class
 - ... and 35 more: https://git.openjdk.org/jdk/compare/4b55fe57...0763be4d

Changes: https://git.openjdk.org/jdk/pull/18841/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18841&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8307818
  Stats: 1760 lines in 5 files changed: 415 ins; 795 del; 550 mod
  Patch: https://git.openjdk.org/jdk/pull/18841.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18841/head:pull/18841

PR: https://git.openjdk.org/jdk/pull/18841

From liach at openjdk.org  Mon May 20 00:09:11 2024
From: liach at openjdk.org (Chen Liang)
Date: Mon, 20 May 2024 00:09:11 GMT
Subject: RFR: 8307818: Convert Indify tool to Classfile API
In-Reply-To: <tCFk9yrCtcoBnzvNIgceY0eOaXg9ZiN9nkCuhHIyMyw=.9cc5f994-8d35-411a-bb39-7c3f2ac34dda@github.com>
References: <tCFk9yrCtcoBnzvNIgceY0eOaXg9ZiN9nkCuhHIyMyw=.9cc5f994-8d35-411a-bb39-7c3f2ac34dda@github.com>
Message-ID: <cUM9iyakIxL3Taxj6D3z9YMIlgUXTUEr_WvUESUb4SA=.af943244-2cdd-42cb-9406-bf3ecb58b967@github.com>

On Thu, 18 Apr 2024 13:53:34 GMT, Oussama Louati <duke at openjdk.org> wrote:

> An indify tool in j.l.i tests (also in vmTestBase) convert some source-code private static methods with MT_ MH_, and INDY_ prefixes into MethodHandle, MethodType, and CallSite constants.
> It currently uses ad-hoc code to process class files and intends to migrate to ASM; but since we have the Classfile API, we can migrate to Classfile API instead.

This is going to be a difficult task because of the sheer size of indify tool; to migrate you really need in-depth understanding of both indify and CF API. Good luck!

test/jdk/java/lang/invoke/indify/Indify.java line 45:

> 43:  * must be stereotyped generators of MethodHandle and MethodType
> 44:  * constants.  All calls to them are transformed to {@code CONSTANT_MethodHandle}
> 45:  * and {@code CONSTANT_MethodType} "ldc" instructions.

Don't need to rename these, as they are from the JVMS 
https://docs.oracle.com/javase/specs/jvms/se22/html/jvms-4.html#jvms-4.4-210

test/jdk/java/lang/invoke/indify/Indify.java line 1247:

> 1245:     }
> 1246: 
> 1247:     public class Bytecode {

You don't really need this class; you should be able to get whatever you need from ClassModel.

-------------

PR Review: https://git.openjdk.org/jdk/pull/18841#pullrequestreview-2009032065
PR Review Comment: https://git.openjdk.org/jdk/pull/18841#discussion_r1570850951
PR Review Comment: https://git.openjdk.org/jdk/pull/18841#discussion_r1591707139

From duke at openjdk.org  Mon May 20 00:09:11 2024
From: duke at openjdk.org (Oussama Louati)
Date: Mon, 20 May 2024 00:09:11 GMT
Subject: RFR: 8307818: Convert Indify tool to Classfile API
In-Reply-To: <cUM9iyakIxL3Taxj6D3z9YMIlgUXTUEr_WvUESUb4SA=.af943244-2cdd-42cb-9406-bf3ecb58b967@github.com>
References: <tCFk9yrCtcoBnzvNIgceY0eOaXg9ZiN9nkCuhHIyMyw=.9cc5f994-8d35-411a-bb39-7c3f2ac34dda@github.com>
 <cUM9iyakIxL3Taxj6D3z9YMIlgUXTUEr_WvUESUb4SA=.af943244-2cdd-42cb-9406-bf3ecb58b967@github.com>
Message-ID: <3HRwafs6xxHo1PKYctxmr-SPx9gxMMj44LHk6kw4fYI=.7033dd14-22d9-4d00-b79f-3a51f044659f@github.com>

On Thu, 18 Apr 2024 14:15:12 GMT, Chen Liang <liach at openjdk.org> wrote:

> This is going to be a difficult task because of the sheer size of indify tool; to migrate you really need in-depth understanding of both indify and CF API. Good luck!

Thank you

> test/jdk/java/lang/invoke/indify/Indify.java line 1247:
> 
>> 1245:     }
>> 1246: 
>> 1247:     public class Bytecode {
> 
> You don't really need this class; you should be able to get whatever you need from ClassModel.

I agree, this is just a temporary thing and it will be removed after, just to put everything together first and determine what exactly I will need from the classModel for the tool and then it will all be moved to the Indify class

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18841#issuecomment-2063997862
PR Review Comment: https://git.openjdk.org/jdk/pull/18841#discussion_r1591914977

From duke at openjdk.org  Mon May 20 00:09:12 2024
From: duke at openjdk.org (ExE Boss)
Date: Mon, 20 May 2024 00:09:12 GMT
Subject: RFR: 8307818: Convert Indify tool to Classfile API
In-Reply-To: <tCFk9yrCtcoBnzvNIgceY0eOaXg9ZiN9nkCuhHIyMyw=.9cc5f994-8d35-411a-bb39-7c3f2ac34dda@github.com>
References: <tCFk9yrCtcoBnzvNIgceY0eOaXg9ZiN9nkCuhHIyMyw=.9cc5f994-8d35-411a-bb39-7c3f2ac34dda@github.com>
Message-ID: <GD2i-QzlBoHBPJwNf85tzpH0wI4EdtKfDtAdmgtwaVA=.fd15267f-db32-4329-8caa-e6e67dd36e07@github.com>

On Thu, 18 Apr 2024 13:53:34 GMT, Oussama Louati <duke at openjdk.org> wrote:

> An indify tool in j.l.i tests (also in vmTestBase) convert some source-code private static methods with MT_ MH_, and INDY_ prefixes into MethodHandle, MethodType, and CallSite constants.
> It currently uses ad-hoc code to process class files and intends to migrate to ASM; but since we have the Classfile API, we can migrate to Classfile API instead.

test/jdk/java/lang/invoke/indify/Indify.java line 197:

> 195:                 if (err == null) {
> 196:                     err = ex;
> 197:                 }

Maybe?use [Throwable?::addSuppressed?(Throwable)]:
Suggestion:

                } else if (ex != err) {
                    err.addSuppressed(ex);
                }


[Throwable?::addSuppressed?(Throwable)]: https://docs.oracle.com/en/java/javase/22/docs/api/java.base/java/lang/Throwable.html#addSuppressed(java.lang.Throwable)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18841#discussion_r1606111439

From duke at openjdk.org  Mon May 20 00:09:12 2024
From: duke at openjdk.org (Oussama Louati)
Date: Mon, 20 May 2024 00:09:12 GMT
Subject: RFR: 8307818: Convert Indify tool to Classfile API
In-Reply-To: <tCFk9yrCtcoBnzvNIgceY0eOaXg9ZiN9nkCuhHIyMyw=.9cc5f994-8d35-411a-bb39-7c3f2ac34dda@github.com>
References: <tCFk9yrCtcoBnzvNIgceY0eOaXg9ZiN9nkCuhHIyMyw=.9cc5f994-8d35-411a-bb39-7c3f2ac34dda@github.com>
Message-ID: <dfyTv-ykOAqzW1ldzJytbjBmGSVnbbeIo6Xun4NUS9o=.736c98c1-2a1e-45f7-8731-459ad9b77bfb@github.com>

On Thu, 18 Apr 2024 13:53:34 GMT, Oussama Louati <duke at openjdk.org> wrote:

> An indify tool in j.l.i tests (also in vmTestBase) convert some source-code private static methods with MT_ MH_, and INDY_ prefixes into MethodHandle, MethodType, and CallSite constants.
> It currently uses ad-hoc code to process class files and intends to migrate to ASM; but since we have the Classfile API, we can migrate to Classfile API instead.

test/jdk/java/lang/invoke/indify/Indify.java line 715:

> 713:             }
> 714:         }
> 715:         //New implementation using the CP API

This is a similar implementation of the old methods using the ClassFile API. will be merged once fully tested and implemented

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18841#discussion_r1600735259

From duke at openjdk.org  Mon May 20 00:19:21 2024
From: duke at openjdk.org (Oussama Louati)
Date: Mon, 20 May 2024 00:19:21 GMT
Subject: RFR: 8307818: Convert Indify tool to Classfile API [v2]
In-Reply-To: <tCFk9yrCtcoBnzvNIgceY0eOaXg9ZiN9nkCuhHIyMyw=.9cc5f994-8d35-411a-bb39-7c3f2ac34dda@github.com>
References: <tCFk9yrCtcoBnzvNIgceY0eOaXg9ZiN9nkCuhHIyMyw=.9cc5f994-8d35-411a-bb39-7c3f2ac34dda@github.com>
Message-ID: <93H0UARiGvc_L6ERlFUpl-l4nQ_Z4v_ttImM6xokiYc=.5da22419-10ac-40d2-a90d-fc829f5f331d@github.com>

> An indify tool in j.l.i tests (also in vmTestBase) convert some source-code private static methods with MT_ MH_, and INDY_ prefixes into MethodHandle, MethodType, and CallSite constants.
> It currently uses ad-hoc code to process class files and intends to migrate to ASM; but since we have the Classfile API, we can migrate to Classfile API instead.

Oussama Louati has updated the pull request incrementally with one additional commit since the last revision:

  fix: enhance code

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/18841/files
  - new: https://git.openjdk.org/jdk/pull/18841/files/0763be4d..96e6920a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18841&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18841&range=00-01

  Stats: 34 lines in 1 file changed: 3 ins; 0 del; 31 mod
  Patch: https://git.openjdk.org/jdk/pull/18841.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18841/head:pull/18841

PR: https://git.openjdk.org/jdk/pull/18841

From david.holmes at oracle.com  Mon May 20 00:59:17 2024
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 20 May 2024 10:59:17 +1000
Subject: Deterministic naming of subclasses of `java/lang/reflect/Proxy`
In-Reply-To: <DB7PR02MB35938DCC3A392536B924164AFBEE2@DB7PR02MB3593.eurprd02.prod.outlook.com>
References: <bf26eb2f74874e02876b3868311922a9@kth.se>
 <CABe8uE0fk71Xy_PYHikSw9OtXE_i+M9zMbayPEXuTxLWLoy2ag@mail.gmail.com>
 <50405ca9c0a64372bace175b932f9ef7@kth.se>
 <61fbe3d9-9536-4113-adde-6cfc671ba1ee@oracle.com>
 <a860be44e06243799593aa8d67c048cd@kth.se>
 <CABe8uE115=DzYCdnvNazqFuuxtJoZnv9wRUkFA4-PS7g41QLMw@mail.gmail.com>
 <DB7PR02MB35938DCC3A392536B924164AFBEE2@DB7PR02MB3593.eurprd02.prod.outlook.com>
Message-ID: <a0330ee0-5f45-4ef2-8500-e5fcdb696c52@oracle.com>

On 17/05/2024 9:43 pm, Aman Sharma wrote:
> Hi Chen,
> 
>  > java.lang.invoke.LambdaForm$MH/0x00000200cc000400
> 
> I do see this as output when I pass -verbose:class. However, based on my 
> experiments, I have seen that neither an agent passed via 'javaagent' 
> nor an agent passed via 'agentpath' is able to intercept this hidden class.

How did you try to intercept them? Hidden classes are not "loaded" in 
the normal sense so won't trigger class load events.

> Also, I was a bit confused since I saw somewhere that the names of 
> hidden classes are null. But thanks for clarifying here.

The JEP clearly defines the name format for hidden classes - though the 
final component is VM specific (and typically a hashcode).

https://openjdk.org/jeps/371

Cheers,
David
-----

>  > avoid dynamic class loading
> 
> I don't see dynamic class loading as a problem. I only mind some 
> unstable generation aspects of them which make it hard to verify them 
> based on an allowlist.
> 
> For example, if this hidden class is generated with the exact same name 
> and the exact same bytecode during runtime as well, it would be easy to 
> verify it. However, I do see the names are based on some sort of memory 
> address so and I don't know what bytecode it has so I don't have 
> suggestions to make them stable as of now. For Proxy classes, I feel it 
> can be addressed unless you disagree or some involved in Project Leyden 
> does. :) Thank you for forwarding my mail there.
> 
> Regards,
> Aman Sharma
> 
> PhD Student
> KTH Royal Institute of Technology
> https://algomaster99.github.io/ <https://algomaster99.github.io/>
> 
> ------------------------------------------------------------------------
> *From:* liangchenblue at gmail.com <liangchenblue at gmail.com>
> *Sent:* Friday, May 17, 2024 1:23:58 pm
> *To:* Aman Sharma <amansha at kth.se>
> *Cc:* core-libs-dev at openjdk.org <core-libs-dev at openjdk.org>; 
> leyden-dev at openjdk.org <leyden-dev at openjdk.org>
> *Subject:* Re: Deterministic naming of subclasses of 
> `java/lang/reflect/Proxy`
> 
> Hi Aman,
> For `-verbose:class`, it's a JVM argument instead of a program argument; 
> so when you run a java program like `java Main`, you should call it as 
> `java -verbose:class Main`.
> When done correctly, you should see hidden class outputs like:
> [0.032s][info][class,load] 
> java.lang.invoke.LambdaForm$MH/0x00000200cc000400 source: 
> __JVM_LookupDefineClass__
> The?loading of java.lang.invoke hidden classes requires your program to 
> use MethodHandle features, like a lambda.
> 
> I think the problem you are exploring, that to avoid dynamic class 
> loading and effectively turn Java Platform closed for security, is also 
> being accomplished by project Leyden (as I've shared initially); Thus, I 
> am forwarding this to leyden-dev instead, so you can see what approach 
> Leyden uses to accomplish the same goal as yours.
> 
> Regards, Chen Liang
> 
> On Fri, May 17, 2024 at 4:40?AM Aman Sharma <amansha at kth.se 
> <mailto:amansha at kth.se>> wrote:
> 
>     __
> 
>     Hi Roger,
> 
> 
>     Do you have ideas on how to intercept them? My javaagent is not able
>     to nor a JVMTI agent passed using `agentpath` option. It also does
>     not seem to show up in logs when I pass `-verbose:class`.
> 
> 
>     Also, what do you think of renaming the proxy classes as suggested
>     below?
> 
> 
>     Regards,
>     Aman Sharma
> 
>     PhD Student
>     KTH Royal Institute of Technology
>     School of Electrical Engineering and Computer Science (EECS)
>     Department of Theoretical Computer Science (TCS)
>     <http://www.kth.se><https://www.kth.se/profile/amansha><https://www.kth.se/profile/amansha>
>     <https://www.kth.se/profile/amansha>https://algomaster99.github.io/
>     <https://algomaster99.github.io/>
>     ------------------------------------------------------------------------
>     *From:* core-libs-dev <core-libs-dev-retn at openjdk.org
>     <mailto:core-libs-dev-retn at openjdk.org>> on behalf of Roger Riggs
>     <roger.riggs at oracle.com <mailto:roger.riggs at oracle.com>>
>     *Sent:* Friday, May 17, 2024 4:57:46 AM
>     *To:* core-libs-dev at openjdk.org <mailto:core-libs-dev at openjdk.org>
>     *Subject:* Re: Deterministic naming of subclasses of
>     `java/lang/reflect/Proxy`
>     Hi Aman,
> 
>     You may also run into hidden classes (JEP 371: Hidden Classes) that
>     allow classes to be defined, at runtime, without names.
>     It has been proposed to use them for generated proxies but that
>     hasn't been implemented yet.
>     There are benefits to having nameless classes, because they can't be
>     referenced by name, only as a capability, they can be better
>     encapsulated.
> 
>     fyi, Roger Riggs
> 
> 
>     On 5/16/24 8:11 AM, Aman Sharma wrote:
>>
>>     Hi,
>>
>>
>>     Thanks for your response, Liang!
>>
>>
>>     > I think you meant CVE-2021-42392 instead of 2022.
>>
>>
>>     Sorry of the error. I indeed meant CVE-2021-42392
>>     <https://nvd.nist.gov/vuln/detail/cve-2021-42392>.
>>
>>
>>     > Leyden mainly avoids this unstable generation by performing a
>>     training run to collect classes loaded
>>
>>
>>     Would love to know the details of Project Leyden and how they
>>     worked so far to focus on this goal. In our case, the training run
>>     is the test suite.
>>
>>
>>     > GeneratedConstructorAccessor is already retired by JEP 416 [2]
>>     in Java 18
>>
>>
>>     I did see them not appearing in my allowlist when I ran my study
>>     subject (Apache PDFBox) with Java 21. Thanks for letting me know
>>     about this JEP. I see they are re-implemented with method handles.
>>
>>
>>     > How are you checking the classes?
>>
>>
>>     To detect runtime generated code, we have javaagent that is hooked
>>     statically to the test suite execution. It gives us all classes
>>     that that is loaded post the JVM and the javaagent are loaded. So
>>     we only check the classes loaded for the purpose of running the
>>     application. This is also why we did not choose -agentlib as it
>>     would give classes for the setting up JVM and javaagent and we the
>>     user of our tool must the classes they load.
>>
>>
>>     Next, we have a `ClassFileTransformer` hook in the agent where we
>>     produce the checksum using the bytecode. And we compare the
>>     checksum with the one existing in the allowlist. The checksum
>>     computation algorithm is same for both steps. Let me describe how
>>     I compute the checksum.
>>
>>
>>      1. I get the CONSTANT_Class_info
>>         <https://docs.oracle.com/javase/specs/jvms/se11/html/jvms-4.html#jvms-4.4.1> entry corresponding to `this_class` and rewrite the CONSTANT_Utf8_info <https://docs.oracle.com/javase/specs/jvms/se11/html/jvms-4.html#jvms-4.4.7> corresponding to a fix String constant, say "foo".
>>      2. Since, the name of the class is used to refer to its types
>>         members (fields/method), I get all CONSTANT_Fieldref_info
>>         <https://docs.oracle.com/javase/specs/jvms/se11/html/jvms-4.html#jvms-4.4.2> and if its `class_index` corresponds to the old `this_class`, we rewrite the UTF8 value of class_index to the same constant "foo".
>>      3. Next, since the naming of the fields, in Proxy classes, are
>>         also suffixed by numbers, for example, `private static Method
>>         m4`, we rewrite the UTF8 value of name in the
>>         CONSTANT_NameAndType_info
>>         <https://docs.oracle.com/javase/specs/jvms/se11/html/jvms-4.html#jvms-4.4.6>.
>>      4. These fields can also have a random order so we simply sort
>>         the entire byte code using `Arrays.sort(byte[])` to eliminate
>>         any differences due to ordering of fields/methods.
>>      5. Simply sorting the byte array still had minute differences. I
>>         could not understand why they existed even though values in
>>         constant pool of the bytecode in allowlist and at runtime were
>>         exactly the same after rewriting. The differences existed in
>>         the bytes of the Code attribute of methods. I concluded that
>>         the bytes stored some position information. To avoid this, I
>>         created a subarray where I considered the bytes corresponding
>>         to `CONSTANT_Utf8_info.bytes` only. Computing a checksum for
>>         it resulted in the same checksums for both classfiles. 
>>
>>
>>     Let's understand the whole approach with an example of Proxy class.
>>
>>     `
>>     public  final  class  $Proxy42  extends  Proxy  implements  org.apache.logging.log4j.core.config.plugins.Plugin  {
>>     `
>>
>>     The will go in the allowlist as "Proxy_Plugin: <SHA256 checksum>".
>>
>>     When the same class is intercepted at runtime, say "$Proxy10", we
>>     look for "Proxy_Plugin" in the allowlist and since the checksum
>>     algorithm is same in both cases, we get a match and let the class
>>     load.
>>
>>     This approach has seemed to work well for Proxy classes, Generated
>>     Constructor Accessor (which is removed as you said). I also looked
>>     at the species generated by method handles. I did not notice any
>>     modification in them. Their name generation seemed okay to me. If
>>     some new Species are generated, it is of course detected since it
>>     is not in the allowlist.
>>
>>     I have not looked into LambdaMetafactory because I did not
>>     encounter it as a problem so far, but I am aware its name
>>     generation is also unstable. I have run my approach only a few
>>     projects only. And for hidden classes, I assume the the agent
>>     won't be able to intercept them so detecting them would be really
>>     hard.
>>
>>
>>     Regards,
>>     Aman Sharma
>>
>>     PhD Student
>>     KTH Royal Institute of Technology
>>     School of Electrical Engineering and Computer Science (EECS)
>>     Department of Theoretical Computer Science (TCS)
>>     <https://www.kth.se/profile/amansha>https://algomaster99.github.io/ <https://algomaster99.github.io/>
>>     ------------------------------------------------------------------------
>>     *From:* liangchenblue at gmail.com <mailto:liangchenblue at gmail.com>
>>     <liangchenblue at gmail.com> <mailto:liangchenblue at gmail.com>
>>     *Sent:* Thursday, May 16, 2024 5:52:03 AM
>>     *To:* Aman Sharma; core-libs-dev
>>     *Cc:* Martin Monperrus
>>     *Subject:* Re: Deterministic naming of subclasses of
>>     `java/lang/reflect/Proxy`
>>     Hi Aman,
>>     I think you meant CVE-2021-42392 instead of 2022.
>>
>>     For your approach of an "allowlist" for Java runtime, project
>>     Leyden is looking to generate a static image [1], that
>>     >?At run time it cannot load classes from outside the image, nor
>>     can it create classes dynamically.
>>     Leyden mainly avoids this unstable generation by performing a
>>     training run to collect classes loaded and even object graphs; I
>>     am not familiar with the details unfortunately.
>>
>>     Otherwise, the Proxy discussion belongs better to core-libs-dev,
>>     as java.lang.reflect.Proxy is part of Java's core libraries. I am
>>     replying this thread to core-libs-dev.
>>
>>     For your perceived problem that classes don't have unique names,
>>     your description sounds dubious: GeneratedConstructorAccessor is
>>     already retired by JEP 416 [2] in Java 18, and there are many
>>     other cases in which JDK generates classes without stable names,
>>     notoriously LambdaMetafactory (Gradle wished for cacheable
>>     Lambdas); the same applies for the generated classes for
>>     MethodHandle's?LambdaForms (which carries implementation code for
>>     LambdaForm). How are you checking the classes? It seems you are
>>     not checking hidden classes. Proxy and Lambda classes are defined
>>     by the caller's class loader, while LambdaForms are under JDK's
>>     system class loader I think. We need to ensure you are correctly
>>     finding all unstable classes before we can proceed.
>>
>>     [1]: https://openjdk.org/projects/leyden/notes/01-beginnings
>>     <https://openjdk.org/projects/leyden/notes/01-beginnings>
>>     [2]: https://openjdk.org/jeps/416 <https://openjdk.org/jeps/416>
>>
>>     On Wed, May 15, 2024 at 7:00?PM Aman Sharma <amansha at kth.se
>>     <mailto:amansha at kth.se>> wrote:
>>
>>         Hi,
>>
>>
>>         My name is Aman and I am a PhD student at KTH Royal Institute
>>         of Technology, Stockholm, Sweden. I research as part of CHAINS
>>         <https://chains.proj.kth.se/> project to strengthen the
>>         software supply chain of multiple ecosystem. I particularly
>>         focus on runtime integrity in Java. In this email, I want to
>>         write about an issue I have discovered with /dynamic
>>         generation of `java.lang.reflect.Proxy`classes/. I will
>>         propose a solution and would love to hear the feedback from
>>         the community. Let me know if this is the correct mailing-list
>>         for such discussions. It seemed the most relevant from this
>>         list <https://mail.openjdk.org/mailman/listinfo>.
>>
>>
>>         *My research*
>>
>>         *
>>         *
>>
>>         Java has features to load class on the fly - it can either
>>         download or generate a class at runtime. These features are
>>         useful for inner workings of JDK. For example, implementing
>>         annotations, reflective access, etc. However, these features
>>         have also contributed to critical vulnerabilities in the past
>>         -?CVE-2021-44228? (log4shell), CVE-2022-33980, CVE-2022-42392.
>>         All of these vulnerabilities have one thing in common - /a
>>         class that was not known during build time was
>>         downloaded/generated at runtime and loaded into JVM./
>>
>>
>>         To defend against such vulnerabilities, we propose a solution
>>         to /allowlist classes for runtime/. This allowlist will
>>         contain an exhaustive list of classes that can be loaded by
>>         the JVM and it will be enforced at runtime. We build this
>>         allowlist from three sources:
>>
>>          1. All classes of all modules provided by the Java Standard
>>             Library. We use ClassGraph
>>             <https://github.com/classgraph/classgraph> to scan the JDK.
>>          2. We can take the source code and all dependencies of an
>>             application. We use a software bill of materials to get
>>             all the data.
>>          3. Finally, we use run the test suite to include any runtime
>>             downloaded/generated classes. 
>>
>>         Such a list is able to prevent the above 3 CVEs because it
>>         does not let the "unknown" bytecode to be loaded.
>>
>>         *Problem with generating such an allowlist*
>>         *
>>         *
>>         The first two parts of the allowlist are easy to get. The
>>         problem is with the third step where we want to allowlist all
>>         the classes that could be downloaded or generated. Upon
>>         running the test suite and hooking to the classes it loads, we
>>         observer that the list consists of classes that are called
>>         "com/sun/proxy/$Proxy2",
>>         "jdk/internal/reflect/GeneratedConstructorAccessor3" among
>>         many more. The purpose of these classes can be identifed. The
>>         proxy class is created for to implement an annotation. The
>>         accessor gives access to constructor of a class to the JVM.
>>
>>         When enforcing this allowlist at runtime, we see that the
>>         bytecode content for "com/sun/proxy/$Proxy2" differs in the
>>         allowlist and at runtime. In our case, we we are experimenting
>>         with pdfbox <https://github.com/apache/pdfbox> so we created
>>         the allowlist using its test suite. Then we enforced this
>>         allowlist while running some of its subcommands. However,
>>         there was some other proxy class say "com/sun/proxy/$Proxy5"
>>         at runtime that implemented the same interfaces and had the
>>         same methods as "com/sun/proxy/$Proxy2" in the allowlist. They
>>         only differed in the name of the class, order of fields, and
>>         types for fields references. This could happen because the
>>         order of the loading of class is workload dependent, but it
>>         causes problem to generate such an allowlist.
>>
>>         *Solution
>>         *
>>
>>
>>         We propose that naming of subclasses of
>>         "java/lang/reflect/Proxy" should not be dependent upon the
>>         order of loading. In order to do so, two issues can be fixed:
>>
>>          1. The naming of the class should not be based on AtomicLong
>>             <https://github.com/openjdk/jdk/blob/b687aa550837830b38f0f0faa69c353b1e85219c/src/java.base/share/classes/java/lang/reflect/Proxy.java#L531>. Rather it could be named based on the interfaces it implements. I also wonder why AtomicLong is chosen in the first place.
>>          2. Methods of the interfaces must be in a particular order.
>>             Right now, they are not sorted in any particular order
>>             <https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/lang/Class.java#L2178>.
>>
>>
>>         These fixes will make proxy class generation deterministic
>>         with respect to order of loading and won't be flagged at
>>         runtime since the test suite would already detect them.
>>
>>         I would love to hear from the community about these ideas. If
>>         in agreement, I would be happy to produce a patch. I have
>>         discovered this issue with subclasses of
>>         GeneratedConstructorAccessor
>>         <https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/jdk/internal/reflect/ConstructorAccessor.java> as well and I imagine it will also apply to some other runtime generated classes. If you disagree, please let me know also. It helps with my research.
>>
>>         I also have PoCs for the above CVEs
>>         <https://github.com/chains-project/exploits-for-sbom.exe> and
>>         a proof concept tool is being developed under the name
>>         sbom.exe <https://github.com/chains-project/sbom.exe> in case
>>         any one wonders about the implementation. I would also be
>>         happy to explain more.
>>
>>         Regards,
>>         Aman Sharma
>>
>>         PhD Student
>>         KTH Royal Institute of Technology
>>         School of Electrical Engineering and Computer Science (EECS)
>>         Department of Theoretical Computer Science (TCS)
>>         <https://www.kth.se/profile/amansha>https://algomaster99.github.io/ <https://algomaster99.github.io/>
>>
> 
> 

From aboldtch at openjdk.org  Mon May 20 06:46:15 2024
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Mon, 20 May 2024 06:46:15 GMT
Subject: RFR: 8332494: java/util/zip/EntryCount64k.java failing with
 java.lang.RuntimeException: '\\A\\Z' missing from stderr
Message-ID: <P4iFhm88NN9LnctlMK3ZypWEDt33jZ7MUzMhP0C0-sM=.bd4e86ad-41c5-4bb1-be78-5e2b3f4a771b@github.com>

Improve `java/util/zip/EntryCount64k.java` stderr parsing by ignoring deprecated warnings. Testing non-generational ZGC requires the use of a deprecated option.

-------------

Commit messages:
 - 8332494: java/util/zip/EntryCount64k.java failing with java.lang.RuntimeException: '\\A\\Z' missing from stderr

Changes: https://git.openjdk.org/jdk/pull/19297/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19297&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8332494
  Stats: 20 lines in 2 files changed: 18 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/19297.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19297/head:pull/19297

PR: https://git.openjdk.org/jdk/pull/19297

From aboldtch at openjdk.org  Mon May 20 06:46:27 2024
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Mon, 20 May 2024 06:46:27 GMT
Subject: RFR: 8332495: java/util/logging/LoggingDeadlock2.java fails with
 AssertionError: Some tests failed
Message-ID: <Fvr-WcK1ssQZvGGgefk_FrC4NX7v3QV6g1I-Zdy71eU=.bcf9e38d-e8f9-46d7-b349-d174d88d9d17@github.com>

Improve ` java/util/logging/LoggingDeadlock2.java` stderr parsing by ignoring deprecated warnings. Testing non-generational ZGC requires the use of a deprecated option.

-------------

Commit messages:
 - 8332495: java/util/logging/LoggingDeadlock2.java fails with AssertionError: Some tests failed

Changes: https://git.openjdk.org/jdk/pull/19298/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19298&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8332495
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/19298.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19298/head:pull/19298

PR: https://git.openjdk.org/jdk/pull/19298

From jpai at openjdk.org  Mon May 20 07:08:01 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 20 May 2024 07:08:01 GMT
Subject: RFR: 8332495: java/util/logging/LoggingDeadlock2.java fails with
 AssertionError: Some tests failed
In-Reply-To: <Fvr-WcK1ssQZvGGgefk_FrC4NX7v3QV6g1I-Zdy71eU=.bcf9e38d-e8f9-46d7-b349-d174d88d9d17@github.com>
References: <Fvr-WcK1ssQZvGGgefk_FrC4NX7v3QV6g1I-Zdy71eU=.bcf9e38d-e8f9-46d7-b349-d174d88d9d17@github.com>
Message-ID: <dt1sJdirAgHv6MqHBE33WumAKEBu4aIBOYRo-xAzDAI=.21136bc2-95e0-4e85-9ebe-06aac545290a@github.com>

On Mon, 20 May 2024 06:42:19 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

> Improve ` java/util/logging/LoggingDeadlock2.java` stderr parsing by ignoring deprecated warnings. Testing non-generational ZGC requires the use of a deprecated option.

The change looks OK to me. The copyright year on the file will need an update.

-------------

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19298#pullrequestreview-2065506460

From jpai at openjdk.org  Mon May 20 07:15:01 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 20 May 2024 07:15:01 GMT
Subject: RFR: 8332494: java/util/zip/EntryCount64k.java failing with
 java.lang.RuntimeException: '\\A\\Z' missing from stderr
In-Reply-To: <P4iFhm88NN9LnctlMK3ZypWEDt33jZ7MUzMhP0C0-sM=.bd4e86ad-41c5-4bb1-be78-5e2b3f4a771b@github.com>
References: <P4iFhm88NN9LnctlMK3ZypWEDt33jZ7MUzMhP0C0-sM=.bd4e86ad-41c5-4bb1-be78-5e2b3f4a771b@github.com>
Message-ID: <TY0NW67Xj_WAg6NhupWyhw6p450fuqw3NkRQCGrDeRE=.6efd8a13-a16e-4da1-a57c-823804b88f7e@github.com>

On Mon, 20 May 2024 06:41:45 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

> Improve `java/util/zip/EntryCount64k.java` stderr parsing by ignoring deprecated warnings. Testing non-generational ZGC requires the use of a deprecated option.

Hello Axel, the change looks OK to me. I was going to suggest `stderrShouldMatch(pattern, boolean ignoreDeprecatedWarning)` as the new method instead of `stderrShouldMatchIgnoreDeprecatedWarnings`, but then I see that there are also methods with names like this in `OutputAnalyzer`. So this change is consistent with those.

`OutputAnalyzer.java` will need a copyright year update before integrating.

-------------

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19297#pullrequestreview-2065518056

From alanb at openjdk.org  Mon May 20 07:16:04 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 20 May 2024 07:16:04 GMT
Subject: RFR: 8330542: Add jaxp-strict.properties in preparation for a
 secure by default configuration [v10]
In-Reply-To: <Jc4tdJwAUMokA_Zm15xcJDE6FLlmWI4JTCcW3uo8gPU=.a4ffc7d1-0e3e-408a-bb65-976e5095a831@github.com>
References: <v1bAYKgH9zfooXpvnBw4Vu2TIqHuKqqtSmgB0hiNp-Q=.31661a99-ecfc-4a05-8045-67b5f680db60@github.com>
 <Jc4tdJwAUMokA_Zm15xcJDE6FLlmWI4JTCcW3uo8gPU=.a4ffc7d1-0e3e-408a-bb65-976e5095a831@github.com>
Message-ID: <zVKhkvewdkqCdBkhTDtbkTidBBYcEKVF39mMNLts1YU=.24acc158-8f6d-4591-872f-850dd8571c6c@github.com>

On Sun, 19 May 2024 05:01:32 GMT, Joe Wang <joehw at openjdk.org> wrote:

>> Add two sample configuration files:
>> 
>>   jaxp-strict.properties: used to set strict configuration, stricter than jaxp.properties in previous versions such as JDK 22
>> 
>>>   jaxp-compat.properties: used to regain compatibility from any more restricted configuration than previous versions such as JDK 22
>> 
>> Updated on 5/16/2024
>> 
>> Design change:
>> The design is changed to include in the JDK two configuration files that are the default jaxp.properties and jaxp-strict.properties, instead of three, dropping jaxp-compat.properties.
>> 
>> Updated on 5/18/2024
>> 
>> Withdraw changes to jaxp.properties. The original idea was to match jaxp-strict.properties with regard to the properties. However, that change impact the configuration process, resulting in tests that verify the process to fail.
>
> Joe Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   withdraw changes to jaxp.properties. The configuration process has not changed, changing the default configuration would result in many failures that test the process.

Looks good, just one comment on on the jaxp-strict.properties file text.

src/java.xml/share/conf/jaxp-strict.properties line 17:

> 15: #     java -Djava.xml.config.file=$JAVA_HOME/conf/jaxp-strict.properties
> 16: #
> 17: # The pathname to the configuration file must be valid. If it is not absolute,

I think it would be better to drop this paragraph or else just replace it with a sentence to say that the java.xml module description specifies the system property.

-------------

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18831#pullrequestreview-2065520089
PR Review Comment: https://git.openjdk.org/jdk/pull/18831#discussion_r1606350445

From aboldtch at openjdk.org  Mon May 20 07:25:12 2024
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Mon, 20 May 2024 07:25:12 GMT
Subject: RFR: 8332495: java/util/logging/LoggingDeadlock2.java fails with
 AssertionError: Some tests failed [v2]
In-Reply-To: <Fvr-WcK1ssQZvGGgefk_FrC4NX7v3QV6g1I-Zdy71eU=.bcf9e38d-e8f9-46d7-b349-d174d88d9d17@github.com>
References: <Fvr-WcK1ssQZvGGgefk_FrC4NX7v3QV6g1I-Zdy71eU=.bcf9e38d-e8f9-46d7-b349-d174d88d9d17@github.com>
Message-ID: <jViDZdflinFxS_Nt2P36eAoq24qe5j2093MQ5cwSMXw=.b7cdad59-5b65-450d-8a32-533dfe490d0f@github.com>

> Improve ` java/util/logging/LoggingDeadlock2.java` stderr parsing by ignoring deprecated warnings. Testing non-generational ZGC requires the use of a deprecated option.

Axel Boldt-Christmas has updated the pull request incrementally with one additional commit since the last revision:

  Update copyright year

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19298/files
  - new: https://git.openjdk.org/jdk/pull/19298/files/003028de..5205a53c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19298&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19298&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/19298.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19298/head:pull/19298

PR: https://git.openjdk.org/jdk/pull/19298

From stefank at openjdk.org  Mon May 20 07:25:12 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Mon, 20 May 2024 07:25:12 GMT
Subject: RFR: 8332495: java/util/logging/LoggingDeadlock2.java fails with
 AssertionError: Some tests failed [v2]
In-Reply-To: <jViDZdflinFxS_Nt2P36eAoq24qe5j2093MQ5cwSMXw=.b7cdad59-5b65-450d-8a32-533dfe490d0f@github.com>
References: <Fvr-WcK1ssQZvGGgefk_FrC4NX7v3QV6g1I-Zdy71eU=.bcf9e38d-e8f9-46d7-b349-d174d88d9d17@github.com>
 <jViDZdflinFxS_Nt2P36eAoq24qe5j2093MQ5cwSMXw=.b7cdad59-5b65-450d-8a32-533dfe490d0f@github.com>
Message-ID: <Tqlerm9WxY5_4jzx93C2K8_iN1Ok8wJ8okIjVSPQGGg=.f9c9408f-8bb4-411d-84b2-5a08ca4c58e7@github.com>

On Mon, 20 May 2024 07:22:49 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

>> Improve ` java/util/logging/LoggingDeadlock2.java` stderr parsing by ignoring deprecated warnings. Testing non-generational ZGC requires the use of a deprecated option.
>
> Axel Boldt-Christmas has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update copyright year

Marked as reviewed by stefank (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/19298#pullrequestreview-2065533348

From aboldtch at openjdk.org  Mon May 20 07:27:19 2024
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Mon, 20 May 2024 07:27:19 GMT
Subject: RFR: 8332494: java/util/zip/EntryCount64k.java failing with
 java.lang.RuntimeException: '\\A\\Z' missing from stderr [v2]
In-Reply-To: <P4iFhm88NN9LnctlMK3ZypWEDt33jZ7MUzMhP0C0-sM=.bd4e86ad-41c5-4bb1-be78-5e2b3f4a771b@github.com>
References: <P4iFhm88NN9LnctlMK3ZypWEDt33jZ7MUzMhP0C0-sM=.bd4e86ad-41c5-4bb1-be78-5e2b3f4a771b@github.com>
Message-ID: <0zogMuGHeb9VVpAWwNLM6PJFJQR4yYdlMxqE9bYfOHg=.c914e3c3-eb99-45a9-8d13-010f9d7c133c@github.com>

> Improve `java/util/zip/EntryCount64k.java` stderr parsing by ignoring deprecated warnings. Testing non-generational ZGC requires the use of a deprecated option.

Axel Boldt-Christmas has updated the pull request incrementally with one additional commit since the last revision:

  Update copyright year

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19297/files
  - new: https://git.openjdk.org/jdk/pull/19297/files/d25cde7c..77c85160

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19297&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19297&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/19297.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19297/head:pull/19297

PR: https://git.openjdk.org/jdk/pull/19297

From stefank at openjdk.org  Mon May 20 07:27:19 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Mon, 20 May 2024 07:27:19 GMT
Subject: RFR: 8332494: java/util/zip/EntryCount64k.java failing with
 java.lang.RuntimeException: '\\A\\Z' missing from stderr [v2]
In-Reply-To: <0zogMuGHeb9VVpAWwNLM6PJFJQR4yYdlMxqE9bYfOHg=.c914e3c3-eb99-45a9-8d13-010f9d7c133c@github.com>
References: <P4iFhm88NN9LnctlMK3ZypWEDt33jZ7MUzMhP0C0-sM=.bd4e86ad-41c5-4bb1-be78-5e2b3f4a771b@github.com>
 <0zogMuGHeb9VVpAWwNLM6PJFJQR4yYdlMxqE9bYfOHg=.c914e3c3-eb99-45a9-8d13-010f9d7c133c@github.com>
Message-ID: <lyYGvd8SQcHR6oUWPGdVMbfUGVT5G2Tve7kH3T6C_2w=.62c87691-8bc6-4e56-98d9-2cc28d7b212c@github.com>

On Mon, 20 May 2024 07:24:16 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

>> Improve `java/util/zip/EntryCount64k.java` stderr parsing by ignoring deprecated warnings. Testing non-generational ZGC requires the use of a deprecated option.
>
> Axel Boldt-Christmas has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update copyright year

Marked as reviewed by stefank (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/19297#pullrequestreview-2065538663

From jpai at openjdk.org  Mon May 20 07:31:02 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 20 May 2024 07:31:02 GMT
Subject: RFR: 8332494: java/util/zip/EntryCount64k.java failing with
 java.lang.RuntimeException: '\\A\\Z' missing from stderr [v2]
In-Reply-To: <0zogMuGHeb9VVpAWwNLM6PJFJQR4yYdlMxqE9bYfOHg=.c914e3c3-eb99-45a9-8d13-010f9d7c133c@github.com>
References: <P4iFhm88NN9LnctlMK3ZypWEDt33jZ7MUzMhP0C0-sM=.bd4e86ad-41c5-4bb1-be78-5e2b3f4a771b@github.com>
 <0zogMuGHeb9VVpAWwNLM6PJFJQR4yYdlMxqE9bYfOHg=.c914e3c3-eb99-45a9-8d13-010f9d7c133c@github.com>
Message-ID: <Nb9AkxBchlCw_icju4134sPWJEuzOcMt8uL8UhN58ek=.b50a717c-1392-4c75-a817-202f29b14b56@github.com>

On Mon, 20 May 2024 07:27:19 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

>> Improve `java/util/zip/EntryCount64k.java` stderr parsing by ignoring deprecated warnings. Testing non-generational ZGC requires the use of a deprecated option.
>
> Axel Boldt-Christmas has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update copyright year

Marked as reviewed by jpai (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/19297#pullrequestreview-2065548780

From jpai at openjdk.org  Mon May 20 07:34:01 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 20 May 2024 07:34:01 GMT
Subject: RFR: 8332495: java/util/logging/LoggingDeadlock2.java fails with
 AssertionError: Some tests failed [v2]
In-Reply-To: <jViDZdflinFxS_Nt2P36eAoq24qe5j2093MQ5cwSMXw=.b7cdad59-5b65-450d-8a32-533dfe490d0f@github.com>
References: <Fvr-WcK1ssQZvGGgefk_FrC4NX7v3QV6g1I-Zdy71eU=.bcf9e38d-e8f9-46d7-b349-d174d88d9d17@github.com>
 <jViDZdflinFxS_Nt2P36eAoq24qe5j2093MQ5cwSMXw=.b7cdad59-5b65-450d-8a32-533dfe490d0f@github.com>
Message-ID: <RNR4COB74OyzMzWTE_kIGQ9awhvOgL4yOJ-XCU8R8Fo=.515d4cfc-5c13-4463-8e90-13b11e314078@github.com>

On Mon, 20 May 2024 07:25:12 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

>> Improve ` java/util/logging/LoggingDeadlock2.java` stderr parsing by ignoring deprecated warnings. Testing non-generational ZGC requires the use of a deprecated option.
>
> Axel Boldt-Christmas has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update copyright year

Marked as reviewed by jpai (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/19298#pullrequestreview-2065553921

From asotona at openjdk.org  Mon May 20 08:09:24 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 20 May 2024 08:09:24 GMT
Subject: RFR: 8332505: JEP 457: ClassRemapper forgets to remap bootstrap method
 references
Message-ID: <Y0fO03Ed3zbniIMZPeMK4mIVjmqCXfSYdkYtsPbXqyk=.8bd9cdde-57ca-4da8-b8f3-6fe2e1854b38@github.com>

Class-File API `ClassRemapper` component suppose to remap all classes referenced in a class file.
Actual implementation missed remapping of bootstrap methods referenced from `invokedynamic` instructions.
This patch fixes the remapping and adds relevant test.

Please review.

Thanks,
Adam

-------------

Commit messages:
 - 8332505: JEP 457: ClassRemapper forgets to remap bootstrap method references

Changes: https://git.openjdk.org/jdk/pull/19299/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19299&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8332505
  Stats: 9 lines in 2 files changed: 4 ins; 0 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/19299.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19299/head:pull/19299

PR: https://git.openjdk.org/jdk/pull/19299

From luhenry at openjdk.org  Mon May 20 08:39:01 2024
From: luhenry at openjdk.org (Ludovic Henry)
Date: Mon, 20 May 2024 08:39:01 GMT
Subject: RFR: 8331196: vector api: Remove unnecessary index check in
 Byte/ShortVector.fromArray/fromArray0Template
In-Reply-To: <YLwvFU3XpoutOZCBehEbDwlkkucrAbHv1mF8K9zzDH0=.b49d1661-adac-4a96-b013-84f1b4dd7fcf@github.com>
References: <YLwvFU3XpoutOZCBehEbDwlkkucrAbHv1mF8K9zzDH0=.b49d1661-adac-4a96-b013-84f1b4dd7fcf@github.com>
Message-ID: <XAHCe1X80cFcm-L3uDDvzcbjbHH6tZWvVA4H3pVk-00=.1b38a98c-5dbb-4c9d-ae59-18154f66daa1@github.com>

On Fri, 26 Apr 2024 14:06:02 GMT, Hamlin Li <mli at openjdk.org> wrote:

> Hi,
> Can you help to review this simple patch?
> Some index check in Byte/ShortVector.fromArray/fromArray0Template seems not necessary, could be removed.
> Thanks

@PaulSandoz who would be a good person to give a review on this one? It's not architecture specific. Thanks!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18977#issuecomment-2119954616

From asotona at openjdk.org  Mon May 20 08:42:09 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 20 May 2024 08:42:09 GMT
Subject: RFR: 8332486: ClassFile API ArrayIndexOutOfBoundsException with label
 metadata
Message-ID: <AnO18xDHzgdxAcLcsQLVdNUdMKyqEs2jQl-2YQGbnWA=.ae8dc1dd-a6c2-4223-be09-b823c92c9b87@github.com>

Parsing of a specifically corrupted class file cause unexpected `ArrayIndexOutOfBoundsException` during label inflation.
This patch checks the valid range and throws expected `IllegalArgumentException` instead.
Relevant test is added.

Please review.

Thanks,
Adam

-------------

Commit messages:
 - 8332486: ClassFile API ArrayIndexOutOfBoundsException with label metadata

Changes: https://git.openjdk.org/jdk/pull/19304/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19304&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8332486
  Stats: 19 lines in 2 files changed: 18 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/19304.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19304/head:pull/19304

PR: https://git.openjdk.org/jdk/pull/19304

From duke at openjdk.org  Mon May 20 09:26:09 2024
From: duke at openjdk.org (serhiysachkov)
Date: Mon, 20 May 2024 09:26:09 GMT
Subject: Integrated: 8331851: Add specific regression leap year tests for
 Calendar.roll()
In-Reply-To: <kB-PMNTKDCXUa_0GFeslsF_8iTU_P5fpgPzdpp2NmTQ=.b41869f1-5ffb-46a9-a499-6fdca3e98e69@github.com>
References: <kB-PMNTKDCXUa_0GFeslsF_8iTU_P5fpgPzdpp2NmTQ=.b41869f1-5ffb-46a9-a499-6fdca3e98e69@github.com>
Message-ID: <S9O5uQonKnKGPJdi39yidUoTm9WonsxaDAlj1Y-KO9Q=.5692f7d9-8c23-44bf-8b78-a58f88f79432@github.com>

On Wed, 15 May 2024 09:39:16 GMT, serhiysachkov <duke at openjdk.org> wrote:

> Add specific regression tests for Calendar.roll() method to explicitly various leap year test scenarios. This is inspired by the ambiguity which occurred in leap year unaware test creation as in case with Calendar.add() in swing component test case as detailed in (https://bugs.openjdk.org/browse/JDK-8327088).

This pull request has now been integrated.

Changeset: d6b7f9b1
Author:    Serhiy Sachkov <serhiy.sachkov at oracle.com>
Committer: Mahendra Chhipa <mchhipa at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/d6b7f9b170b6ce4f7275cc7595b71b9a3e93c133
Stats:     190 lines in 1 file changed: 190 ins; 0 del; 0 mod

8331851: Add specific regression leap year tests for Calendar.roll()

Reviewed-by: naoto

-------------

PR: https://git.openjdk.org/jdk/pull/19247

From mcimadamore at openjdk.org  Mon May 20 09:48:02 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 20 May 2024 09:48:02 GMT
Subject: RFR: 8331865: Consolidate size and alignment checks in LayoutPath
 [v2]
In-Reply-To: <ye_axgXODi_M-1C14h-O3Ez0ICuenTZyprTuJ1quZaM=.992dd1fd-4526-4d31-a4b3-f06e18c9cca0@github.com>
References: <CvKkdESp5-uHiuZtQvGortWnzOMV89pfjaCHNBIV4B4=.51ad0f01-2371-48af-b3c6-8a9b80518cdb@github.com>
 <sbhzMEtBjBJuxpO_JdNI4tCiTZwCG8WNBXR5_G2TVXo=.1726357f-4f88-46dc-aaa6-b773df9292df@github.com>
 <ye_axgXODi_M-1C14h-O3Ez0ICuenTZyprTuJ1quZaM=.992dd1fd-4526-4d31-a4b3-f06e18c9cca0@github.com>
Message-ID: <aZm4_-jMAJf-KVRewoMk9f3YHyRJhsJI5SG4PaIRzts=.9f1c56d3-3efe-4f41-8e7a-1a84b3c85cf2@github.com>

On Fri, 17 May 2024 23:42:17 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

> Separately, we might be missing a few long argument accepting guard methods for simpler cases as I suspect they are still focused more on int index types.

Not sure I understand what guard methods you are referring to here?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19251#issuecomment-2120083825

From duke at openjdk.org  Mon May 20 09:53:08 2024
From: duke at openjdk.org (Jens Lidestrom)
Date: Mon, 20 May 2024 09:53:08 GMT
Subject: RFR: 8330465: Stable Values and Collections (Internal) [v20]
In-Reply-To: <kLBsOOVO524jwGiSeA_8W5EwK1uXz0Cp6b_uIbrt_VY=.ee3fbae5-6f6c-45f4-8b62-b9f92a015730@github.com>
References: <-KSimQo5kkmCzzMShqGe5QZ9yCSzpWL98gN13v4wP0k=.11dd8d06-18a6-4577-8342-66632cea0b6e@github.com>
 <kLBsOOVO524jwGiSeA_8W5EwK1uXz0Cp6b_uIbrt_VY=.ee3fbae5-6f6c-45f4-8b62-b9f92a015730@github.com>
Message-ID: <dR2TE0MFZK0n50BI1IQM6xA1bYqDxy5jeUwVHeHX0c8=.cf8dbb13-f479-4d38-83cc-e6f09377e318@github.com>

On Fri, 17 May 2024 09:31:33 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> # Stable Values & Collections (Internal)
>> 
>> <img src="https://github.com/openjdk/jdk/assets/7457876/db4b22a1-af87-4914-adac-b05a87e7cb42" width=20% height=20%>
>> 
>> ## Summary
>> This PR proposes to introduce an internal _Stable Values & Collections_ API, which provides immutable value holders where elements are initialized _at most once_. Stable Values & Collections offer the performance and safety benefits of final fields while offering greater flexibility as to the timing of initialization.
>> 
>> ## Goals
>>  * Provide an easy and intuitive API to describe value holders that can change at most once.
>>  * Decouple declaration from initialization without significant footprint or performance penalties.
>>  * Reduce the amount of static initializer and/or field initialization code.
>>  * Uphold integrity and consistency, even in a multi-threaded environment.
>>  
>> For more details, see the draft JEP: https://openjdk.org/jeps/8312611
>> 
>> ## Performance 
>> Performance compared to instance variables using two `AtomicReference` and two protected by double-checked locking under concurrent access by all threads:
>> 
>> 
>> Benchmark                                      Mode  Cnt      Score      Error   Units
>> StableBenchmark.atomic                        thrpt   10    259.478 ?   36.809  ops/us
>> StableBenchmark.dcl                           thrpt   10    225.710 ?   26.638  ops/us
>> StableBenchmark.stable                        thrpt   10   4382.478 ? 1151.472  ops/us <- StableValue significantly faster
>> 
>> 
>> Performance compared to static variables protected by `AtomicReference`, class-holder idiom holder, and double-checked locking (all threads):
>> 
>> 
>> Benchmark                                      Mode  Cnt      Score      Error   Units
>> StableStaticBenchmark.atomic                  thrpt   10   6487.835 ?  385.639  ops/us
>> StableStaticBenchmark.dcl                     thrpt   10   6605.239 ?  210.610  ops/us
>> StableStaticBenchmark.stable                  thrpt   10  14338.239 ? 1426.874  ops/us
>> StableStaticBenchmark.staticCHI               thrpt   10  13780.341 ? 1839.651  ops/us
>> 
>> 
>> Performance for stable lists (thread safe) in both instance and static contexts whereby we access a single value compared to `ArrayList` instances (which are not thread-safe) (all threads):
>> 
>> 
>> Benchmark                                      Mode  Cnt      Score      Error   Units
>> StableListElementBenchmark.instanceArrayList  thrpt   10   5812.992 ? 1169.730  ops...
>
> Per Minborg has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Add benchmarks for memoized IntFunction and Function
>  - Add benchmark for memoized supplier

src/java.base/share/classes/jdk/internal/lang/StableArray.java line 66:

> 64:      * @throws IllegalArgumentException if the provided {@code length} is {@code < 0}
> 65:      */
> 66:     static <V> StableArray<V> of(int length) {

I interpret the method name `of` as a method that creates an object that contains the argument as some kind of member, in the way that `List.of` and friends work.

My intuitive interpretation of `StableArray.of(10)` is that it returns an array with the single element 10.

I think a method like this should be named `empty`, or `emptyOfLength` or something like that.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18794#discussion_r1606529054

From dholmes at openjdk.org  Mon May 20 10:17:38 2024
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 20 May 2024 10:17:38 GMT
Subject: RFR: 8332494: java/util/zip/EntryCount64k.java failing with
 java.lang.RuntimeException: '\\A\\Z' missing from stderr [v2]
In-Reply-To: <0zogMuGHeb9VVpAWwNLM6PJFJQR4yYdlMxqE9bYfOHg=.c914e3c3-eb99-45a9-8d13-010f9d7c133c@github.com>
References: <P4iFhm88NN9LnctlMK3ZypWEDt33jZ7MUzMhP0C0-sM=.bd4e86ad-41c5-4bb1-be78-5e2b3f4a771b@github.com>
 <0zogMuGHeb9VVpAWwNLM6PJFJQR4yYdlMxqE9bYfOHg=.c914e3c3-eb99-45a9-8d13-010f9d7c133c@github.com>
Message-ID: <yjbbk6sTmri50DpqjWkZajHPoiClh8hOq-eB6dMIhAk=.f4d3ff77-735d-4640-9eb8-51c253d382ad@github.com>

On Mon, 20 May 2024 07:27:19 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

>> Improve `java/util/zip/EntryCount64k.java` stderr parsing by ignoring deprecated warnings. Testing non-generational ZGC requires the use of a deprecated option.
>
> Axel Boldt-Christmas has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update copyright year

I'm undecided whether it is really worth adding a new utility function to just ignore deprecated warnings, or whether we should just use the existing function to ignore all warnings.

If we special case for deprecated warnings then we may want to also add a special version of `asLinesWithoutVMWarnings`

test/lib/jdk/test/lib/process/OutputAnalyzer.java line 691:

> 689:      * @throws RuntimeException If the pattern was not found
> 690:      */
> 691:     public OutputAnalyzer stderrShouldMatchIgnoreDeprecatedWarnings(String pattern) {

Given we have `...IgnoreVMWarnings` this special case should really be called `...IgnoreDeprecatedVMWarnings`.

-------------

PR Review: https://git.openjdk.org/jdk/pull/19297#pullrequestreview-2065863128
PR Review Comment: https://git.openjdk.org/jdk/pull/19297#discussion_r1606551444

From bkilambi at openjdk.org  Mon May 20 10:44:05 2024
From: bkilambi at openjdk.org (Bhavana Kilambi)
Date: Mon, 20 May 2024 10:44:05 GMT
Subject: RFR: 8327964: Simplify BigInteger.implMultiplyToLen intrinsic [v3]
In-Reply-To: <pJ7EHSw1QUoVy60dGjR81GdoPzlibyDv-kZ-FmfRvt4=.9bdab17c-0e27-4ba7-a68b-9a2307641244@github.com>
References: <Z5U-3OSq9_rd0t6DHNRhjF3LHtc9b6orz-mcQ4Uqzl8=.c4f0a0b8-9e10-4505-82f7-7d3a82929d22@github.com>
 <zMKT2cOKMHo76IFkz5uh8NOa07lp1NhleOJFKDi_v8c=.b5605b07-077e-4cf8-9014-f9a169b0af46@github.com>
 <IEbiW8OAUyzLJ9NWnSZEI_iOYBfJrsIy-wc8KF-R92I=.72f6c6e6-af4f-495e-8612-f1bb6318ec67@github.com>
 <pJ7EHSw1QUoVy60dGjR81GdoPzlibyDv-kZ-FmfRvt4=.9bdab17c-0e27-4ba7-a68b-9a2307641244@github.com>
Message-ID: <msXjYZiGIRrXhgws7k4vKA3QbZdse1uqj_tszjCortA=.cdd2b95d-6101-47cb-a4b6-6c8bf466c689@github.com>

On Wed, 17 Apr 2024 12:37:01 GMT, Yudi Zheng <yzheng at openjdk.org> wrote:

>> `multiply_to_len` seems to be used by `generate_squareToLen` as well for aarch64 and riscv but `zlen` is still passed in a register.
>> 
>> https://github.com/openjdk/jdk/blob/870a6127cf54264c691f7322d775b202705c3bfa/src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp#L4710
>> https://github.com/openjdk/jdk/blob/870a6127cf54264c691f7322d775b202705c3bfa/src/hotspot/cpu/riscv/stubGenerator_riscv.cpp#L2881
>> 
>> I think it might work anyway but it might be better to adapt them if only for completeness.
>
> @dafedafe @dean-long please take a look and let me know if there are further issues, thanks!

Hi @mur47x111, do you happen to have any performance results with this patch?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18226#issuecomment-2120179701

From aboldtch at openjdk.org  Mon May 20 11:44:02 2024
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Mon, 20 May 2024 11:44:02 GMT
Subject: RFR: 8332494: java/util/zip/EntryCount64k.java failing with
 java.lang.RuntimeException: '\\A\\Z' missing from stderr [v2]
In-Reply-To: <yjbbk6sTmri50DpqjWkZajHPoiClh8hOq-eB6dMIhAk=.f4d3ff77-735d-4640-9eb8-51c253d382ad@github.com>
References: <P4iFhm88NN9LnctlMK3ZypWEDt33jZ7MUzMhP0C0-sM=.bd4e86ad-41c5-4bb1-be78-5e2b3f4a771b@github.com>
 <0zogMuGHeb9VVpAWwNLM6PJFJQR4yYdlMxqE9bYfOHg=.c914e3c3-eb99-45a9-8d13-010f9d7c133c@github.com>
 <yjbbk6sTmri50DpqjWkZajHPoiClh8hOq-eB6dMIhAk=.f4d3ff77-735d-4640-9eb8-51c253d382ad@github.com>
Message-ID: <BpaFh2N7wc0SgaY_KNkCTOQI5vsSWWhKD50jFPIZR90=.f5447750-018d-4511-86b3-0ee353c99edd@github.com>

On Mon, 20 May 2024 10:11:26 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Axel Boldt-Christmas has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update copyright year
>
> test/lib/jdk/test/lib/process/OutputAnalyzer.java line 691:
> 
>> 689:      * @throws RuntimeException If the pattern was not found
>> 690:      */
>> 691:     public OutputAnalyzer stderrShouldMatchIgnoreDeprecatedWarnings(String pattern) {
> 
> Given we have `...IgnoreVMWarnings` this special case should really be called `...IgnoreDeprecatedVMWarnings`.

The name was chosen based on: https://github.com/openjdk/jdk/blob/77c8516085225a04bd5a954197fc5ef7e5c5ee61/test/lib/jdk/test/lib/process/OutputAnalyzer.java#L184

Should I still change it?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19297#discussion_r1606671332

From amansha at kth.se  Mon May 20 12:12:47 2024
From: amansha at kth.se (Aman Sharma)
Date: Mon, 20 May 2024 12:12:47 +0000
Subject: Deterministic naming of subclasses of `java/lang/reflect/Proxy`
In-Reply-To: <a0330ee0-5f45-4ef2-8500-e5fcdb696c52@oracle.com>
References: <bf26eb2f74874e02876b3868311922a9@kth.se>
 <CABe8uE0fk71Xy_PYHikSw9OtXE_i+M9zMbayPEXuTxLWLoy2ag@mail.gmail.com>
 <50405ca9c0a64372bace175b932f9ef7@kth.se>
 <61fbe3d9-9536-4113-adde-6cfc671ba1ee@oracle.com>
 <a860be44e06243799593aa8d67c048cd@kth.se>
 <CABe8uE115=DzYCdnvNazqFuuxtJoZnv9wRUkFA4-PS7g41QLMw@mail.gmail.com>
 <DB7PR02MB35938DCC3A392536B924164AFBEE2@DB7PR02MB3593.eurprd02.prod.outlook.com>,
 <a0330ee0-5f45-4ef2-8500-e5fcdb696c52@oracle.com>
Message-ID: <b214cc1a13fe4885a437e16b420e5483@kth.se>

Hi David,


> How did you try to intercept them? Hidden classes are not "loaded" in
the normal sense so won't trigger class load events.


I could not intercept them. I only see them when I pass `-verbose:class` in the Java CLI.


I also couldn't intercept them using JVMTI Class File Load Hook<https://docs.oracle.com/en/java/javase/21/docs/specs/jvmti.html#ClassFileLoadHook> event. However JEP 371 suggests that it should be possible to intercept them using JVMTI Class Load<https://docs.oracle.com/en/java/javase/21/docs/specs/jvmti.html#ClassLoad> event, but I won't have the bytecode at this stage. So is there no way to get its bytecode before it is linked and initialized in the JVM?


Regards,
Aman Sharma

PhD Student
KTH Royal Institute of Technology
School of Electrical Engineering and Computer Science (EECS)
Department of Theoretical Computer Science (TCS)
<http://www.kth.se><https://www.kth.se/profile/amansha><https://www.kth.se/profile/amansha>
<https://www.kth.se/profile/amansha>https://algomaster99.github.io/
________________________________
From: David Holmes <david.holmes at oracle.com>
Sent: Monday, May 20, 2024 2:59:17 AM
To: Aman Sharma; liangchenblue at gmail.com
Cc: core-libs-dev at openjdk.org; leyden-dev at openjdk.org
Subject: Re: Deterministic naming of subclasses of `java/lang/reflect/Proxy`

On 17/05/2024 9:43 pm, Aman Sharma wrote:
> Hi Chen,
>
>  > java.lang.invoke.LambdaForm$MH/0x00000200cc000400
>
> I do see this as output when I pass -verbose:class. However, based on my
> experiments, I have seen that neither an agent passed via 'javaagent'
> nor an agent passed via 'agentpath' is able to intercept this hidden class.

How did you try to intercept them? Hidden classes are not "loaded" in
the normal sense so won't trigger class load events.

> Also, I was a bit confused since I saw somewhere that the names of
> hidden classes are null. But thanks for clarifying here.

The JEP clearly defines the name format for hidden classes - though the
final component is VM specific (and typically a hashcode).

https://openjdk.org/jeps/371

Cheers,
David
-----

>  > avoid dynamic class loading
>
> I don't see dynamic class loading as a problem. I only mind some
> unstable generation aspects of them which make it hard to verify them
> based on an allowlist.
>
> For example, if this hidden class is generated with the exact same name
> and the exact same bytecode during runtime as well, it would be easy to
> verify it. However, I do see the names are based on some sort of memory
> address so and I don't know what bytecode it has so I don't have
> suggestions to make them stable as of now. For Proxy classes, I feel it
> can be addressed unless you disagree or some involved in Project Leyden
> does. :) Thank you for forwarding my mail there.
>
> Regards,
> Aman Sharma
>
> PhD Student
> KTH Royal Institute of Technology
> https://algomaster99.github.io/ <https://algomaster99.github.io/>
>
> ------------------------------------------------------------------------
> *From:* liangchenblue at gmail.com <liangchenblue at gmail.com>
> *Sent:* Friday, May 17, 2024 1:23:58 pm
> *To:* Aman Sharma <amansha at kth.se>
> *Cc:* core-libs-dev at openjdk.org <core-libs-dev at openjdk.org>;
> leyden-dev at openjdk.org <leyden-dev at openjdk.org>
> *Subject:* Re: Deterministic naming of subclasses of
> `java/lang/reflect/Proxy`
>
> Hi Aman,
> For `-verbose:class`, it's a JVM argument instead of a program argument;
> so when you run a java program like `java Main`, you should call it as
> `java -verbose:class Main`.
> When done correctly, you should see hidden class outputs like:
> [0.032s][info][class,load]
> java.lang.invoke.LambdaForm$MH/0x00000200cc000400 source:
> __JVM_LookupDefineClass__
> The loading of java.lang.invoke hidden classes requires your program to
> use MethodHandle features, like a lambda.
>
> I think the problem you are exploring, that to avoid dynamic class
> loading and effectively turn Java Platform closed for security, is also
> being accomplished by project Leyden (as I've shared initially); Thus, I
> am forwarding this to leyden-dev instead, so you can see what approach
> Leyden uses to accomplish the same goal as yours.
>
> Regards, Chen Liang
>
> On Fri, May 17, 2024 at 4:40?AM Aman Sharma <amansha at kth.se
> <mailto:amansha at kth.se>> wrote:
>
>     __
>
>     Hi Roger,
>
>
>     Do you have ideas on how to intercept them? My javaagent is not able
>     to nor a JVMTI agent passed using `agentpath` option. It also does
>     not seem to show up in logs when I pass `-verbose:class`.
>
>
>     Also, what do you think of renaming the proxy classes as suggested
>     below?
>
>
>     Regards,
>     Aman Sharma
>
>     PhD Student
>     KTH Royal Institute of Technology
>     School of Electrical Engineering and Computer Science (EECS)
>     Department of Theoretical Computer Science (TCS)
>     <http://www.kth.se><https://www.kth.se/profile/amansha><https://www.kth.se/profile/amansha>
>     <https://www.kth.se/profile/amansha>https://algomaster99.github.io/
>     <https://algomaster99.github.io/>
>     ------------------------------------------------------------------------
>     *From:* core-libs-dev <core-libs-dev-retn at openjdk.org
>     <mailto:core-libs-dev-retn at openjdk.org>> on behalf of Roger Riggs
>     <roger.riggs at oracle.com <mailto:roger.riggs at oracle.com>>
>     *Sent:* Friday, May 17, 2024 4:57:46 AM
>     *To:* core-libs-dev at openjdk.org <mailto:core-libs-dev at openjdk.org>
>     *Subject:* Re: Deterministic naming of subclasses of
>     `java/lang/reflect/Proxy`
>     Hi Aman,
>
>     You may also run into hidden classes (JEP 371: Hidden Classes) that
>     allow classes to be defined, at runtime, without names.
>     It has been proposed to use them for generated proxies but that
>     hasn't been implemented yet.
>     There are benefits to having nameless classes, because they can't be
>     referenced by name, only as a capability, they can be better
>     encapsulated.
>
>     fyi, Roger Riggs
>
>
>     On 5/16/24 8:11 AM, Aman Sharma wrote:
>>
>>     Hi,
>>
>>
>>     Thanks for your response, Liang!
>>
>>
>>     > I think you meant CVE-2021-42392 instead of 2022.
>>
>>
>>     Sorry of the error. I indeed meant CVE-2021-42392
>>     <https://nvd.nist.gov/vuln/detail/cve-2021-42392>.
>>
>>
>>     > Leyden mainly avoids this unstable generation by performing a
>>     training run to collect classes loaded
>>
>>
>>     Would love to know the details of Project Leyden and how they
>>     worked so far to focus on this goal. In our case, the training run
>>     is the test suite.
>>
>>
>>     > GeneratedConstructorAccessor is already retired by JEP 416 [2]
>>     in Java 18
>>
>>
>>     I did see them not appearing in my allowlist when I ran my study
>>     subject (Apache PDFBox) with Java 21. Thanks for letting me know
>>     about this JEP. I see they are re-implemented with method handles.
>>
>>
>>     > How are you checking the classes?
>>
>>
>>     To detect runtime generated code, we have javaagent that is hooked
>>     statically to the test suite execution. It gives us all classes
>>     that that is loaded post the JVM and the javaagent are loaded. So
>>     we only check the classes loaded for the purpose of running the
>>     application. This is also why we did not choose -agentlib as it
>>     would give classes for the setting up JVM and javaagent and we the
>>     user of our tool must the classes they load.
>>
>>
>>     Next, we have a `ClassFileTransformer` hook in the agent where we
>>     produce the checksum using the bytecode. And we compare the
>>     checksum with the one existing in the allowlist. The checksum
>>     computation algorithm is same for both steps. Let me describe how
>>     I compute the checksum.
>>
>>
>>      1. I get the CONSTANT_Class_info
>>         <https://docs.oracle.com/javase/specs/jvms/se11/html/jvms-4.html#jvms-4.4.1> entry corresponding to `this_class` and rewrite the CONSTANT_Utf8_info <https://docs.oracle.com/javase/specs/jvms/se11/html/jvms-4.html#jvms-4.4.7> corresponding to a fix String constant, say "foo".
>>      2. Since, the name of the class is used to refer to its types
>>         members (fields/method), I get all CONSTANT_Fieldref_info
>>         <https://docs.oracle.com/javase/specs/jvms/se11/html/jvms-4.html#jvms-4.4.2> and if its `class_index` corresponds to the old `this_class`, we rewrite the UTF8 value of class_index to the same constant "foo".
>>      3. Next, since the naming of the fields, in Proxy classes, are
>>         also suffixed by numbers, for example, `private static Method
>>         m4`, we rewrite the UTF8 value of name in the
>>         CONSTANT_NameAndType_info
>>         <https://docs.oracle.com/javase/specs/jvms/se11/html/jvms-4.html#jvms-4.4.6>.
>>      4. These fields can also have a random order so we simply sort
>>         the entire byte code using `Arrays.sort(byte[])` to eliminate
>>         any differences due to ordering of fields/methods.
>>      5. Simply sorting the byte array still had minute differences. I
>>         could not understand why they existed even though values in
>>         constant pool of the bytecode in allowlist and at runtime were
>>         exactly the same after rewriting. The differences existed in
>>         the bytes of the Code attribute of methods. I concluded that
>>         the bytes stored some position information. To avoid this, I
>>         created a subarray where I considered the bytes corresponding
>>         to `CONSTANT_Utf8_info.bytes` only. Computing a checksum for
>>         it resulted in the same checksums for both classfiles.
>>
>>
>>     Let's understand the whole approach with an example of Proxy class.
>>
>>     `
>>     public  final  class  $Proxy42  extends  Proxy  implements  org.apache.logging.log4j.core.config.plugins.Plugin  {
>>     `
>>
>>     The will go in the allowlist as "Proxy_Plugin: <SHA256 checksum>".
>>
>>     When the same class is intercepted at runtime, say "$Proxy10", we
>>     look for "Proxy_Plugin" in the allowlist and since the checksum
>>     algorithm is same in both cases, we get a match and let the class
>>     load.
>>
>>     This approach has seemed to work well for Proxy classes, Generated
>>     Constructor Accessor (which is removed as you said). I also looked
>>     at the species generated by method handles. I did not notice any
>>     modification in them. Their name generation seemed okay to me. If
>>     some new Species are generated, it is of course detected since it
>>     is not in the allowlist.
>>
>>     I have not looked into LambdaMetafactory because I did not
>>     encounter it as a problem so far, but I am aware its name
>>     generation is also unstable. I have run my approach only a few
>>     projects only. And for hidden classes, I assume the the agent
>>     won't be able to intercept them so detecting them would be really
>>     hard.
>>
>>
>>     Regards,
>>     Aman Sharma
>>
>>     PhD Student
>>     KTH Royal Institute of Technology
>>     School of Electrical Engineering and Computer Science (EECS)
>>     Department of Theoretical Computer Science (TCS)
>>     <https://www.kth.se/profile/amansha>https://algomaster99.github.io/ <https://algomaster99.github.io/>
>>     ------------------------------------------------------------------------
>>     *From:* liangchenblue at gmail.com <mailto:liangchenblue at gmail.com>
>>     <liangchenblue at gmail.com> <mailto:liangchenblue at gmail.com>
>>     *Sent:* Thursday, May 16, 2024 5:52:03 AM
>>     *To:* Aman Sharma; core-libs-dev
>>     *Cc:* Martin Monperrus
>>     *Subject:* Re: Deterministic naming of subclasses of
>>     `java/lang/reflect/Proxy`
>>     Hi Aman,
>>     I think you meant CVE-2021-42392 instead of 2022.
>>
>>     For your approach of an "allowlist" for Java runtime, project
>>     Leyden is looking to generate a static image [1], that
>>     > At run time it cannot load classes from outside the image, nor
>>     can it create classes dynamically.
>>     Leyden mainly avoids this unstable generation by performing a
>>     training run to collect classes loaded and even object graphs; I
>>     am not familiar with the details unfortunately.
>>
>>     Otherwise, the Proxy discussion belongs better to core-libs-dev,
>>     as java.lang.reflect.Proxy is part of Java's core libraries. I am
>>     replying this thread to core-libs-dev.
>>
>>     For your perceived problem that classes don't have unique names,
>>     your description sounds dubious: GeneratedConstructorAccessor is
>>     already retired by JEP 416 [2] in Java 18, and there are many
>>     other cases in which JDK generates classes without stable names,
>>     notoriously LambdaMetafactory (Gradle wished for cacheable
>>     Lambdas); the same applies for the generated classes for
>>     MethodHandle's LambdaForms (which carries implementation code for
>>     LambdaForm). How are you checking the classes? It seems you are
>>     not checking hidden classes. Proxy and Lambda classes are defined
>>     by the caller's class loader, while LambdaForms are under JDK's
>>     system class loader I think. We need to ensure you are correctly
>>     finding all unstable classes before we can proceed.
>>
>>     [1]: https://openjdk.org/projects/leyden/notes/01-beginnings
>>     <https://openjdk.org/projects/leyden/notes/01-beginnings>
>>     [2]: https://openjdk.org/jeps/416 <https://openjdk.org/jeps/416>
>>
>>     On Wed, May 15, 2024 at 7:00?PM Aman Sharma <amansha at kth.se
>>     <mailto:amansha at kth.se>> wrote:
>>
>>         Hi,
>>
>>
>>         My name is Aman and I am a PhD student at KTH Royal Institute
>>         of Technology, Stockholm, Sweden. I research as part of CHAINS
>>         <https://chains.proj.kth.se/> project to strengthen the
>>         software supply chain of multiple ecosystem. I particularly
>>         focus on runtime integrity in Java. In this email, I want to
>>         write about an issue I have discovered with /dynamic
>>         generation of `java.lang.reflect.Proxy`classes/. I will
>>         propose a solution and would love to hear the feedback from
>>         the community. Let me know if this is the correct mailing-list
>>         for such discussions. It seemed the most relevant from this
>>         list <https://mail.openjdk.org/mailman/listinfo>.
>>
>>
>>         *My research*
>>
>>         *
>>         *
>>
>>         Java has features to load class on the fly - it can either
>>         download or generate a class at runtime. These features are
>>         useful for inner workings of JDK. For example, implementing
>>         annotations, reflective access, etc. However, these features
>>         have also contributed to critical vulnerabilities in the past
>>         - CVE-2021-44228  (log4shell), CVE-2022-33980, CVE-2022-42392.
>>         All of these vulnerabilities have one thing in common - /a
>>         class that was not known during build time was
>>         downloaded/generated at runtime and loaded into JVM./
>>
>>
>>         To defend against such vulnerabilities, we propose a solution
>>         to /allowlist classes for runtime/. This allowlist will
>>         contain an exhaustive list of classes that can be loaded by
>>         the JVM and it will be enforced at runtime. We build this
>>         allowlist from three sources:
>>
>>          1. All classes of all modules provided by the Java Standard
>>             Library. We use ClassGraph
>>             <https://github.com/classgraph/classgraph> to scan the JDK.
>>          2. We can take the source code and all dependencies of an
>>             application. We use a software bill of materials to get
>>             all the data.
>>          3. Finally, we use run the test suite to include any runtime
>>             downloaded/generated classes.
>>
>>         Such a list is able to prevent the above 3 CVEs because it
>>         does not let the "unknown" bytecode to be loaded.
>>
>>         *Problem with generating such an allowlist*
>>         *
>>         *
>>         The first two parts of the allowlist are easy to get. The
>>         problem is with the third step where we want to allowlist all
>>         the classes that could be downloaded or generated. Upon
>>         running the test suite and hooking to the classes it loads, we
>>         observer that the list consists of classes that are called
>>         "com/sun/proxy/$Proxy2",
>>         "jdk/internal/reflect/GeneratedConstructorAccessor3" among
>>         many more. The purpose of these classes can be identifed. The
>>         proxy class is created for to implement an annotation. The
>>         accessor gives access to constructor of a class to the JVM.
>>
>>         When enforcing this allowlist at runtime, we see that the
>>         bytecode content for "com/sun/proxy/$Proxy2" differs in the
>>         allowlist and at runtime. In our case, we we are experimenting
>>         with pdfbox <https://github.com/apache/pdfbox> so we created
>>         the allowlist using its test suite. Then we enforced this
>>         allowlist while running some of its subcommands. However,
>>         there was some other proxy class say "com/sun/proxy/$Proxy5"
>>         at runtime that implemented the same interfaces and had the
>>         same methods as "com/sun/proxy/$Proxy2" in the allowlist. They
>>         only differed in the name of the class, order of fields, and
>>         types for fields references. This could happen because the
>>         order of the loading of class is workload dependent, but it
>>         causes problem to generate such an allowlist.
>>
>>         *Solution
>>         *
>>
>>
>>         We propose that naming of subclasses of
>>         "java/lang/reflect/Proxy" should not be dependent upon the
>>         order of loading. In order to do so, two issues can be fixed:
>>
>>          1. The naming of the class should not be based on AtomicLong
>>             <https://github.com/openjdk/jdk/blob/b687aa550837830b38f0f0faa69c353b1e85219c/src/java.base/share/classes/java/lang/reflect/Proxy.java#L531>. Rather it could be named based on the interfaces it implements. I also wonder why AtomicLong is chosen in the first place.
>>          2. Methods of the interfaces must be in a particular order.
>>             Right now, they are not sorted in any particular order
>>             <https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/lang/Class.java#L2178>.
>>
>>
>>         These fixes will make proxy class generation deterministic
>>         with respect to order of loading and won't be flagged at
>>         runtime since the test suite would already detect them.
>>
>>         I would love to hear from the community about these ideas. If
>>         in agreement, I would be happy to produce a patch. I have
>>         discovered this issue with subclasses of
>>         GeneratedConstructorAccessor
>>         <https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/jdk/internal/reflect/ConstructorAccessor.java> as well and I imagine it will also apply to some other runtime generated classes. If you disagree, please let me know also. It helps with my research.
>>
>>         I also have PoCs for the above CVEs
>>         <https://github.com/chains-project/exploits-for-sbom.exe> and
>>         a proof concept tool is being developed under the name
>>         sbom.exe <https://github.com/chains-project/sbom.exe> in case
>>         any one wonders about the implementation. I would also be
>>         happy to explain more.
>>
>>         Regards,
>>         Aman Sharma
>>
>>         PhD Student
>>         KTH Royal Institute of Technology
>>         School of Electrical Engineering and Computer Science (EECS)
>>         Department of Theoretical Computer Science (TCS)
>>         <https://www.kth.se/profile/amansha>https://algomaster99.github.io/ <https://algomaster99.github.io/>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240520/a4150a8d/attachment-0001.htm>

From liach at openjdk.org  Mon May 20 12:24:09 2024
From: liach at openjdk.org (Chen Liang)
Date: Mon, 20 May 2024 12:24:09 GMT
Subject: RFR: 8330465: Stable Values and Collections (Internal) [v20]
In-Reply-To: <dR2TE0MFZK0n50BI1IQM6xA1bYqDxy5jeUwVHeHX0c8=.cf8dbb13-f479-4d38-83cc-e6f09377e318@github.com>
References: <-KSimQo5kkmCzzMShqGe5QZ9yCSzpWL98gN13v4wP0k=.11dd8d06-18a6-4577-8342-66632cea0b6e@github.com>
 <kLBsOOVO524jwGiSeA_8W5EwK1uXz0Cp6b_uIbrt_VY=.ee3fbae5-6f6c-45f4-8b62-b9f92a015730@github.com>
 <dR2TE0MFZK0n50BI1IQM6xA1bYqDxy5jeUwVHeHX0c8=.cf8dbb13-f479-4d38-83cc-e6f09377e318@github.com>
Message-ID: <AeQ4VCpoKBkzJGwGsVll3x1-ZqJkCC5cb_PJhgZpenU=.2eb5368e-9506-4a79-9b97-0e1c865cad67@github.com>

On Mon, 20 May 2024 09:50:17 GMT, Jens Lidestrom <duke at openjdk.org> wrote:

>> Per Minborg has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Add benchmarks for memoized IntFunction and Function
>>  - Add benchmark for memoized supplier
>
> src/java.base/share/classes/jdk/internal/lang/StableArray.java line 66:
> 
>> 64:      * @throws IllegalArgumentException if the provided {@code length} is {@code < 0}
>> 65:      */
>> 66:     static <V> StableArray<V> of(int length) {
> 
> I interpret the method name `of` as a method that creates an object that contains the argument as some kind of member, in the way that `List.of` and friends work.
> 
> My intuitive interpretation of `StableArray.of(10)` is that it returns an array with the single element 10.
> 
> I think a method like this should be named `empty`, or `emptyOfLength` or something like that.

Stable arrays aren't supposed to be initialized with values, so I think your point is moot.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18794#discussion_r1606708916

From david.holmes at oracle.com  Mon May 20 12:30:37 2024
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 20 May 2024 22:30:37 +1000
Subject: Deterministic naming of subclasses of `java/lang/reflect/Proxy`
In-Reply-To: <b214cc1a13fe4885a437e16b420e5483@kth.se>
References: <bf26eb2f74874e02876b3868311922a9@kth.se>
 <CABe8uE0fk71Xy_PYHikSw9OtXE_i+M9zMbayPEXuTxLWLoy2ag@mail.gmail.com>
 <50405ca9c0a64372bace175b932f9ef7@kth.se>
 <61fbe3d9-9536-4113-adde-6cfc671ba1ee@oracle.com>
 <a860be44e06243799593aa8d67c048cd@kth.se>
 <CABe8uE115=DzYCdnvNazqFuuxtJoZnv9wRUkFA4-PS7g41QLMw@mail.gmail.com>
 <DB7PR02MB35938DCC3A392536B924164AFBEE2@DB7PR02MB3593.eurprd02.prod.outlook.com>
 <a0330ee0-5f45-4ef2-8500-e5fcdb696c52@oracle.com>
 <b214cc1a13fe4885a437e16b420e5483@kth.se>
Message-ID: <ac2ebe5c-db49-4a2d-a5cd-10440a77aa16@oracle.com>

On 20/05/2024 10:12 pm, Aman Sharma wrote:
> Hi David,
> 
> 
>  > How did you try to intercept them? Hidden classes are not "loaded" in
> the normal sense so won't trigger class load events.
> 
> 
> I could not intercept them. I only see them when I pass `-verbose:class` 
> in the Java CLI.

Yes that is why I asked how you tried to intercept them.

> 
> I also couldn't intercept them using JVMTI Class File Load Hook 
> <https://docs.oracle.com/en/java/javase/21/docs/specs/jvmti.html#ClassFileLoadHook> event. However JEP 371 suggests that it should be possible to intercept them using JVMTI Class Load <https://docs.oracle.com/en/java/javase/21/docs/specs/jvmti.html#ClassLoad> event, but I won't have the bytecode at this stage. So is there no way to get its bytecode before it is linked and initialized in the JVM?

Hidden classes are not loaded so I would not expect any class load 
events. However the exact nature of the JVMTI class load event is 
unclear as it talks about "class or interface creation" which is neither 
loading or defining per se. But a class prepare event sounds like it 
should be issued. However neither give you access to the bytecode of the 
class AFAICS.

David
-----


> 
> Regards,
> Aman Sharma
> 
> PhD Student
> KTH Royal Institute of Technology
> School of Electrical Engineering and Computer Science (EECS)
> Department of Theoretical Computer Science (TCS)
> <http://www.kth.se><https://www.kth.se/profile/amansha><https://www.kth.se/profile/amansha>
> <https://www.kth.se/profile/amansha>https://algomaster99.github.io/ 
> <https://algomaster99.github.io/>
> ------------------------------------------------------------------------
> *From:* David Holmes <david.holmes at oracle.com>
> *Sent:* Monday, May 20, 2024 2:59:17 AM
> *To:* Aman Sharma; liangchenblue at gmail.com
> *Cc:* core-libs-dev at openjdk.org; leyden-dev at openjdk.org
> *Subject:* Re: Deterministic naming of subclasses of 
> `java/lang/reflect/Proxy`
> On 17/05/2024 9:43 pm, Aman Sharma wrote:
>> Hi Chen,
>> 
>>? > java.lang.invoke.LambdaForm$MH/0x00000200cc000400
>> 
>> I do see this as output when I pass -verbose:class. However, based on my 
>> experiments, I have seen that neither an agent passed via 'javaagent' 
>> nor an agent passed via 'agentpath' is able to intercept this hidden class.
> 
> How did you try to intercept them? Hidden classes are not "loaded" in
> the normal sense so won't trigger class load events.
> 
>> Also, I was a bit confused since I saw somewhere that the names of 
>> hidden classes are null. But thanks for clarifying here.
> 
> The JEP clearly defines the name format for hidden classes - though the
> final component is VM specific (and typically a hashcode).
> 
> https://openjdk.org/jeps/371 <https://openjdk.org/jeps/371>
> 
> Cheers,
> David
> -----
> 
>>? > avoid dynamic class loading
>> 
>> I don't see dynamic class loading as a problem. I only mind some 
>> unstable generation aspects of them which make it hard to verify them 
>> based on an allowlist.
>> 
>> For example, if this hidden class is generated with the exact same name 
>> and the exact same bytecode during runtime as well, it would be easy to 
>> verify it. However, I do see the names are based on some sort of memory 
>> address so and I don't know what bytecode it has so I don't have 
>> suggestions to make them stable as of now. For Proxy classes, I feel it 
>> can be addressed unless you disagree or some involved in Project Leyden 
>> does. :) Thank you for forwarding my mail there.
>> 
>> Regards,
>> Aman Sharma
>> 
>> PhD Student
>> KTH Royal Institute of Technology
>> https://algomaster99.github.io/ <https://algomaster99.github.io/> 
> <https://algomaster99.github.io/ <https://algomaster99.github.io/>>
>> 
>> ------------------------------------------------------------------------
>> *From:* liangchenblue at gmail.com <liangchenblue at gmail.com>
>> *Sent:* Friday, May 17, 2024 1:23:58 pm
>> *To:* Aman Sharma <amansha at kth.se>
>> *Cc:* core-libs-dev at openjdk.org <core-libs-dev at openjdk.org>; 
>> leyden-dev at openjdk.org <leyden-dev at openjdk.org>
>> *Subject:* Re: Deterministic naming of subclasses of 
>> `java/lang/reflect/Proxy`
>> 
>> Hi Aman,
>> For `-verbose:class`, it's a JVM argument instead of a program argument; 
>> so when you run a java program like `java Main`, you should call it as 
>> `java -verbose:class Main`.
>> When done correctly, you should see hidden class outputs like:
>> [0.032s][info][class,load] 
>> java.lang.invoke.LambdaForm$MH/0x00000200cc000400 source: 
>> __JVM_LookupDefineClass__
>> The?loading of java.lang.invoke hidden classes requires your program to 
>> use MethodHandle features, like a lambda.
>> 
>> I think the problem you are exploring, that to avoid dynamic class 
>> loading and effectively turn Java Platform closed for security, is also 
>> being accomplished by project Leyden (as I've shared initially); Thus, I 
>> am forwarding this to leyden-dev instead, so you can see what approach 
>> Leyden uses to accomplish the same goal as yours.
>> 
>> Regards, Chen Liang
>> 
>> On Fri, May 17, 2024 at 4:40?AM Aman Sharma <amansha at kth.se 
>> <mailto:amansha at kth.se <mailto:amansha at kth.se>>> wrote:
>> 
>>???? __
>> 
>>???? Hi Roger,
>> 
>> 
>>???? Do you have ideas on how to intercept them? My javaagent is not able
>>???? to nor a JVMTI agent passed using `agentpath` option. It also does
>>???? not seem to show up in logs when I pass `-verbose:class`.
>> 
>> 
>>???? Also, what do you think of renaming the proxy classes as suggested
>>???? below?
>> 
>> 
>>???? Regards,
>>???? Aman Sharma
>> 
>>???? PhD Student
>>???? KTH Royal Institute of Technology
>>???? School of Electrical Engineering and Computer Science (EECS)
>>???? Department of Theoretical Computer Science (TCS)
>>???? <http://www.kth.se><https://www.kth.se/profile/amansha><https://www.kth.se/profile/amansha <http://www.kth.se><https://www.kth.se/profile/amansha><https://www.kth.se/profile/amansha>>
>>???? <https://www.kth.se/profile/amansha 
> <https://www.kth.se/profile/amansha>>https://algomaster99.github.io/
>>???? <https://algomaster99.github.io/ <https://algomaster99.github.io/>>
>>???? ------------------------------------------------------------------------
>>???? *From:* core-libs-dev <core-libs-dev-retn at openjdk.org
>>???? <mailto:core-libs-dev-retn at openjdk.org 
> <mailto:core-libs-dev-retn at openjdk.org>>> on behalf of Roger Riggs
>>???? <roger.riggs at oracle.com <mailto:roger.riggs at oracle.com <mailto:roger.riggs at oracle.com>>>
>>???? *Sent:* Friday, May 17, 2024 4:57:46 AM
>>???? *To:* core-libs-dev at openjdk.org <mailto:core-libs-dev at openjdk.org <mailto:core-libs-dev at openjdk.org>>
>>???? *Subject:* Re: Deterministic naming of subclasses of
>>???? `java/lang/reflect/Proxy`
>>???? Hi Aman,
>> 
>>???? You may also run into hidden classes (JEP 371: Hidden Classes) that
>>???? allow classes to be defined, at runtime, without names.
>>???? It has been proposed to use them for generated proxies but that
>>???? hasn't been implemented yet.
>>???? There are benefits to having nameless classes, because they can't be
>>???? referenced by name, only as a capability, they can be better
>>???? encapsulated.
>> 
>>???? fyi, Roger Riggs
>> 
>> 
>>???? On 5/16/24 8:11 AM, Aman Sharma wrote:
>>>
>>>???? Hi,
>>>
>>>
>>>???? Thanks for your response, Liang!
>>>
>>>
>>>???? > I think you meant CVE-2021-42392 instead of 2022.
>>>
>>>
>>>???? Sorry of the error. I indeed meant CVE-2021-42392
>>>???? <https://nvd.nist.gov/vuln/detail/cve-2021-42392 
> <https://nvd.nist.gov/vuln/detail/cve-2021-42392>>.
>>>
>>>
>>>???? > Leyden mainly avoids this unstable generation by performing a
>>>???? training run to collect classes loaded
>>>
>>>
>>>???? Would love to know the details of Project Leyden and how they
>>>???? worked so far to focus on this goal. In our case, the training run
>>>???? is the test suite.
>>>
>>>
>>>???? > GeneratedConstructorAccessor is already retired by JEP 416 [2]
>>>???? in Java 18
>>>
>>>
>>>???? I did see them not appearing in my allowlist when I ran my study
>>>???? subject (Apache PDFBox) with Java 21. Thanks for letting me know
>>>???? about this JEP. I see they are re-implemented with method handles.
>>>
>>>
>>>???? > How are you checking the classes?
>>>
>>>
>>>???? To detect runtime generated code, we have javaagent that is hooked
>>>???? statically to the test suite execution. It gives us all classes
>>>???? that that is loaded post the JVM and the javaagent are loaded. So
>>>???? we only check the classes loaded for the purpose of running the
>>>???? application. This is also why we did not choose -agentlib as it
>>>???? would give classes for the setting up JVM and javaagent and we the
>>>???? user of our tool must the classes they load.
>>>
>>>
>>>???? Next, we have a `ClassFileTransformer` hook in the agent where we
>>>???? produce the checksum using the bytecode. And we compare the
>>>???? checksum with the one existing in the allowlist. The checksum
>>>???? computation algorithm is same for both steps. Let me describe how
>>>???? I compute the checksum.
>>>
>>>
>>>????? 1. I get the CONSTANT_Class_info
>>>???????? <https://docs.oracle.com/javase/specs/jvms/se11/html/jvms-4.html#jvms-4.4.1 <https://docs.oracle.com/javase/specs/jvms/se11/html/jvms-4.html#jvms-4.4.1>> entry corresponding to `this_class` and rewrite the CONSTANT_Utf8_info <https://docs.oracle.com/javase/specs/jvms/se11/html/jvms-4.html#jvms-4.4.7 <https://docs.oracle.com/javase/specs/jvms/se11/html/jvms-4.html#jvms-4.4.7>> corresponding to a fix String constant, say "foo".
>>>????? 2. Since, the name of the class is used to refer to its types
>>>???????? members (fields/method), I get all CONSTANT_Fieldref_info
>>>???????? <https://docs.oracle.com/javase/specs/jvms/se11/html/jvms-4.html#jvms-4.4.2 <https://docs.oracle.com/javase/specs/jvms/se11/html/jvms-4.html#jvms-4.4.2>> and if its `class_index` corresponds to the old `this_class`, we rewrite the UTF8 value of class_index to the same constant "foo".
>>>????? 3. Next, since the naming of the fields, in Proxy classes, are
>>>???????? also suffixed by numbers, for example, `private static Method
>>>???????? m4`, we rewrite the UTF8 value of name in the
>>>???????? CONSTANT_NameAndType_info
>>>???????? <https://docs.oracle.com/javase/specs/jvms/se11/html/jvms-4.html#jvms-4.4.6 <https://docs.oracle.com/javase/specs/jvms/se11/html/jvms-4.html#jvms-4.4.6>>.
>>>????? 4. These fields can also have a random order so we simply sort
>>>???????? the entire byte code using `Arrays.sort(byte[])` to eliminate
>>>???????? any differences due to ordering of fields/methods.
>>>????? 5. Simply sorting the byte array still had minute differences. I
>>>???????? could not understand why they existed even though values in
>>>???????? constant pool of the bytecode in allowlist and at runtime were
>>>???????? exactly the same after rewriting. The differences existed in
>>>???????? the bytes of the Code attribute of methods. I concluded that
>>>???????? the bytes stored some position information. To avoid this, I
>>>???????? created a subarray where I considered the bytes corresponding
>>>???????? to `CONSTANT_Utf8_info.bytes` only. Computing a checksum for
>>>???????? it resulted in the same checksums for both classfiles. 
>>>
>>>
>>>???? Let's understand the whole approach with an example of Proxy class.
>>>
>>>???? `
>>>???? public? final? class? $Proxy42? extends? Proxy? implements? org.apache.logging.log4j.core.config.plugins.Plugin? {
>>>???? `
>>>
>>>???? The will go in the allowlist as "Proxy_Plugin: <SHA256 checksum>".
>>>
>>>???? When the same class is intercepted at runtime, say "$Proxy10", we
>>>???? look for "Proxy_Plugin" in the allowlist and since the checksum
>>>???? algorithm is same in both cases, we get a match and let the class
>>>???? load.
>>>
>>>???? This approach has seemed to work well for Proxy classes, Generated
>>>???? Constructor Accessor (which is removed as you said). I also looked
>>>???? at the species generated by method handles. I did not notice any
>>>???? modification in them. Their name generation seemed okay to me. If
>>>???? some new Species are generated, it is of course detected since it
>>>???? is not in the allowlist.
>>>
>>>???? I have not looked into LambdaMetafactory because I did not
>>>???? encounter it as a problem so far, but I am aware its name
>>>???? generation is also unstable. I have run my approach only a few
>>>???? projects only. And for hidden classes, I assume the the agent
>>>???? won't be able to intercept them so detecting them would be really
>>>???? hard.
>>>
>>>
>>>???? Regards,
>>>???? Aman Sharma
>>>
>>>???? PhD Student
>>>???? KTH Royal Institute of Technology
>>>???? School of Electrical Engineering and Computer Science (EECS)
>>>???? Department of Theoretical Computer Science (TCS)
>>>???? <https://www.kth.se/profile/amansha 
> <https://www.kth.se/profile/amansha>>https://algomaster99.github.io/ 
> <https://algomaster99.github.io/ <https://algomaster99.github.io/>>
>>>???? ------------------------------------------------------------------------
>>>???? *From:* liangchenblue at gmail.com <mailto:liangchenblue at gmail.com <mailto:liangchenblue at gmail.com>>
>>>???? <liangchenblue at gmail.com> <mailto:liangchenblue at gmail.com <mailto:liangchenblue at gmail.com>>
>>>???? *Sent:* Thursday, May 16, 2024 5:52:03 AM
>>>???? *To:* Aman Sharma; core-libs-dev
>>>???? *Cc:* Martin Monperrus
>>>???? *Subject:* Re: Deterministic naming of subclasses of
>>>???? `java/lang/reflect/Proxy`
>>>???? Hi Aman,
>>>???? I think you meant CVE-2021-42392 instead of 2022.
>>>
>>>???? For your approach of an "allowlist" for Java runtime, project
>>>???? Leyden is looking to generate a static image [1], that
>>>???? >?At run time it cannot load classes from outside the image, nor
>>>???? can it create classes dynamically.
>>>???? Leyden mainly avoids this unstable generation by performing a
>>>???? training run to collect classes loaded and even object graphs; I
>>>???? am not familiar with the details unfortunately.
>>>
>>>???? Otherwise, the Proxy discussion belongs better to core-libs-dev,
>>>???? as java.lang.reflect.Proxy is part of Java's core libraries. I am
>>>???? replying this thread to core-libs-dev.
>>>
>>>???? For your perceived problem that classes don't have unique names,
>>>???? your description sounds dubious: GeneratedConstructorAccessor is
>>>???? already retired by JEP 416 [2] in Java 18, and there are many
>>>???? other cases in which JDK generates classes without stable names,
>>>???? notoriously LambdaMetafactory (Gradle wished for cacheable
>>>???? Lambdas); the same applies for the generated classes for
>>>???? MethodHandle's?LambdaForms (which carries implementation code for
>>>???? LambdaForm). How are you checking the classes? It seems you are
>>>???? not checking hidden classes. Proxy and Lambda classes are defined
>>>???? by the caller's class loader, while LambdaForms are under JDK's
>>>???? system class loader I think. We need to ensure you are correctly
>>>???? finding all unstable classes before we can proceed.
>>>
>>>???? [1]: https://openjdk.org/projects/leyden/notes/01-beginnings 
> <https://openjdk.org/projects/leyden/notes/01-beginnings>
>>>???? <https://openjdk.org/projects/leyden/notes/01-beginnings 
> <https://openjdk.org/projects/leyden/notes/01-beginnings>>
>>>???? [2]: https://openjdk.org/jeps/416 <https://openjdk.org/jeps/416> 
> <https://openjdk.org/jeps/416 <https://openjdk.org/jeps/416>>
>>>
>>>???? On Wed, May 15, 2024 at 7:00?PM Aman Sharma <amansha at kth.se
>>>???? <mailto:amansha at kth.se <mailto:amansha at kth.se>>> wrote:
>>>
>>>???????? Hi,
>>>
>>>
>>>???????? My name is Aman and I am a PhD student at KTH Royal Institute
>>>???????? of Technology, Stockholm, Sweden. I research as part of CHAINS
>>>???????? <https://chains.proj.kth.se/ <https://chains.proj.kth.se/>> project to 
> strengthen the
>>>???????? software supply chain of multiple ecosystem. I particularly
>>>???????? focus on runtime integrity in Java. In this email, I want to
>>>???????? write about an issue I have discovered with /dynamic
>>>???????? generation of `java.lang.reflect.Proxy`classes/. I will
>>>???????? propose a solution and would love to hear the feedback from
>>>???????? the community. Let me know if this is the correct mailing-list
>>>???????? for such discussions. It seemed the most relevant from this
>>>???????? list <https://mail.openjdk.org/mailman/listinfo 
> <https://mail.openjdk.org/mailman/listinfo>>.
>>>
>>>
>>>???????? *My research*
>>>
>>>???????? *
>>>???????? *
>>>
>>>???????? Java has features to load class on the fly - it can either
>>>???????? download or generate a class at runtime. These features are
>>>???????? useful for inner workings of JDK. For example, implementing
>>>???????? annotations, reflective access, etc. However, these features
>>>???????? have also contributed to critical vulnerabilities in the past
>>>???????? -?CVE-2021-44228? (log4shell), CVE-2022-33980, CVE-2022-42392.
>>>???????? All of these vulnerabilities have one thing in common - /a
>>>???????? class that was not known during build time was
>>>???????? downloaded/generated at runtime and loaded into JVM./
>>>
>>>
>>>???????? To defend against such vulnerabilities, we propose a solution
>>>???????? to /allowlist classes for runtime/. This allowlist will
>>>???????? contain an exhaustive list of classes that can be loaded by
>>>???????? the JVM and it will be enforced at runtime. We build this
>>>???????? allowlist from three sources:
>>>
>>>????????? 1. All classes of all modules provided by the Java Standard
>>>???????????? Library. We use ClassGraph
>>>???????????? <https://github.com/classgraph/classgraph 
> <https://github.com/classgraph/classgraph>> to scan the JDK.
>>>????????? 2. We can take the source code and all dependencies of an
>>>???????????? application. We use a software bill of materials to get
>>>???????????? all the data.
>>>????????? 3. Finally, we use run the test suite to include any runtime
>>>???????????? downloaded/generated classes. 
>>>
>>>???????? Such a list is able to prevent the above 3 CVEs because it
>>>???????? does not let the "unknown" bytecode to be loaded.
>>>
>>>???????? *Problem with generating such an allowlist*
>>>???????? *
>>>???????? *
>>>???????? The first two parts of the allowlist are easy to get. The
>>>???????? problem is with the third step where we want to allowlist all
>>>???????? the classes that could be downloaded or generated. Upon
>>>???????? running the test suite and hooking to the classes it loads, we
>>>???????? observer that the list consists of classes that are called
>>>???????? "com/sun/proxy/$Proxy2",
>>>???????? "jdk/internal/reflect/GeneratedConstructorAccessor3" among
>>>???????? many more. The purpose of these classes can be identifed. The
>>>???????? proxy class is created for to implement an annotation. The
>>>???????? accessor gives access to constructor of a class to the JVM.
>>>
>>>???????? When enforcing this allowlist at runtime, we see that the
>>>???????? bytecode content for "com/sun/proxy/$Proxy2" differs in the
>>>???????? allowlist and at runtime. In our case, we we are experimenting
>>>???????? with pdfbox <https://github.com/apache/pdfbox <https://github.com/apache/pdfbox>> so 
> we created
>>>???????? the allowlist using its test suite. Then we enforced this
>>>???????? allowlist while running some of its subcommands. However,
>>>???????? there was some other proxy class say "com/sun/proxy/$Proxy5"
>>>???????? at runtime that implemented the same interfaces and had the
>>>???????? same methods as "com/sun/proxy/$Proxy2" in the allowlist. They
>>>???????? only differed in the name of the class, order of fields, and
>>>???????? types for fields references. This could happen because the
>>>???????? order of the loading of class is workload dependent, but it
>>>???????? causes problem to generate such an allowlist.
>>>
>>>???????? *Solution
>>>???????? *
>>>
>>>
>>>???????? We propose that naming of subclasses of
>>>???????? "java/lang/reflect/Proxy" should not be dependent upon the
>>>???????? order of loading. In order to do so, two issues can be fixed:
>>>
>>>????????? 1. The naming of the class should not be based on AtomicLong
>>>???????????? <https://github.com/openjdk/jdk/blob/b687aa550837830b38f0f0faa69c353b1e85219c/src/java.base/share/classes/java/lang/reflect/Proxy.java#L531 <https://github.com/openjdk/jdk/blob/b687aa550837830b38f0f0faa69c353b1e85219c/src/java.base/share/classes/java/lang/reflect/Proxy.java#L531>>. Rather it could be named based on the interfaces it implements. I also wonder why AtomicLong is chosen in the first place.
>>>????????? 2. Methods of the interfaces must be in a particular order.
>>>???????????? Right now, they are not sorted in any particular order
>>>???????????? <https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/lang/Class.java#L2178 <https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/lang/Class.java#L2178>>.
>>>
>>>
>>>???????? These fixes will make proxy class generation deterministic
>>>???????? with respect to order of loading and won't be flagged at
>>>???????? runtime since the test suite would already detect them.
>>>
>>>???????? I would love to hear from the community about these ideas. If
>>>???????? in agreement, I would be happy to produce a patch. I have
>>>???????? discovered this issue with subclasses of
>>>???????? GeneratedConstructorAccessor
>>>???????? <https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/jdk/internal/reflect/ConstructorAccessor.java <https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/jdk/internal/reflect/ConstructorAccessor.java>> as well and I imagine it will also apply to some other runtime generated classes. If you disagree, please let me know also. It helps with my research.
>>>
>>>???????? I also have PoCs for the above CVEs
>>>???????? <https://github.com/chains-project/exploits-for-sbom.exe 
> <https://github.com/chains-project/exploits-for-sbom.exe>> and
>>>???????? a proof concept tool is being developed under the name
>>>???????? sbom.exe <https://github.com/chains-project/sbom.exe 
> <https://github.com/chains-project/sbom.exe>> in case
>>>???????? any one wonders about the implementation. I would also be
>>>???????? happy to explain more.
>>>
>>>???????? Regards,
>>>???????? Aman Sharma
>>>
>>>???????? PhD Student
>>>???????? KTH Royal Institute of Technology
>>>???????? School of Electrical Engineering and Computer Science (EECS)
>>>???????? Department of Theoretical Computer Science (TCS)
>>>???????? <https://www.kth.se/profile/amansha 
> <https://www.kth.se/profile/amansha>>https://algomaster99.github.io/ 
> <https://algomaster99.github.io/ <https://algomaster99.github.io/>>
>>>
>> 
>> 

From mullan at openjdk.org  Mon May 20 12:51:04 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Mon, 20 May 2024 12:51:04 GMT
Subject: RFR: 8330542: Add jaxp-strict.properties in preparation for a
 secure by default configuration [v10]
In-Reply-To: <Jc4tdJwAUMokA_Zm15xcJDE6FLlmWI4JTCcW3uo8gPU=.a4ffc7d1-0e3e-408a-bb65-976e5095a831@github.com>
References: <v1bAYKgH9zfooXpvnBw4Vu2TIqHuKqqtSmgB0hiNp-Q=.31661a99-ecfc-4a05-8045-67b5f680db60@github.com>
 <Jc4tdJwAUMokA_Zm15xcJDE6FLlmWI4JTCcW3uo8gPU=.a4ffc7d1-0e3e-408a-bb65-976e5095a831@github.com>
Message-ID: <gXFnZ3UfC7XxCj4WcpCs0c8GVbWGR5xYTASbKNOpAxw=.ca8e2b83-2ef5-44b2-8c1d-965cfe0cfe71@github.com>

On Sun, 19 May 2024 05:01:32 GMT, Joe Wang <joehw at openjdk.org> wrote:

>> Add two sample configuration files:
>> 
>>   jaxp-strict.properties: used to set strict configuration, stricter than jaxp.properties in previous versions such as JDK 22
>> 
>>>   jaxp-compat.properties: used to regain compatibility from any more restricted configuration than previous versions such as JDK 22
>> 
>> Updated on 5/16/2024
>> 
>> Design change:
>> The design is changed to include in the JDK two configuration files that are the default jaxp.properties and jaxp-strict.properties, instead of three, dropping jaxp-compat.properties.
>> 
>> Updated on 5/18/2024
>> 
>> Withdraw changes to jaxp.properties. The original idea was to match jaxp-strict.properties with regard to the properties. However, that change impact the configuration process, resulting in tests that verify the process to fail.
>
> Joe Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   withdraw changes to jaxp.properties. The configuration process has not changed, changing the default configuration would result in many failures that test the process.

src/java.xml/share/classes/module-info.java line 444:

> 442:  *
> 443:  * Deploying with this configuration prevents processors from unknowingly making
> 444:  * outbound network connections to fetch DTDs, or process XML that makes use of

s/process/processing/

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18831#discussion_r1606737006

From amansha at kth.se  Mon May 20 12:56:30 2024
From: amansha at kth.se (Aman Sharma)
Date: Mon, 20 May 2024 12:56:30 +0000
Subject: Deterministic naming of subclasses of `java/lang/reflect/Proxy`
In-Reply-To: <ac2ebe5c-db49-4a2d-a5cd-10440a77aa16@oracle.com>
References: <bf26eb2f74874e02876b3868311922a9@kth.se>
 <CABe8uE0fk71Xy_PYHikSw9OtXE_i+M9zMbayPEXuTxLWLoy2ag@mail.gmail.com>
 <50405ca9c0a64372bace175b932f9ef7@kth.se>
 <61fbe3d9-9536-4113-adde-6cfc671ba1ee@oracle.com>
 <a860be44e06243799593aa8d67c048cd@kth.se>
 <CABe8uE115=DzYCdnvNazqFuuxtJoZnv9wRUkFA4-PS7g41QLMw@mail.gmail.com>
 <DB7PR02MB35938DCC3A392536B924164AFBEE2@DB7PR02MB3593.eurprd02.prod.outlook.com>
 <a0330ee0-5f45-4ef2-8500-e5fcdb696c52@oracle.com>
 <b214cc1a13fe4885a437e16b420e5483@kth.se>,
 <ac2ebe5c-db49-4a2d-a5cd-10440a77aa16@oracle.com>
Message-ID: <580b3aacd8df48fcaae3399718e229ab@kth.se>

Hi David,


> I would not expect any class load
events.


I understand. I also haven't tried to intercept them but I see only one approach right now to include them in an allowlist - 1) statically look for invocations of "Lookup::defineHiddenClass". 2) Instrument them so that its first argument "bytes" can be looked into upon. I haven't looked into it much because I did not have much idea about it. And they are hidden so it made it worse. ? Thanks for sharing the JEP!


>

java.lang.reflect.Proxy could define hidden classes to act as the proxy classes which implement proxy interfaces; from JEP 317


It says that Proxy classes will also become hidden classes. Is it underway? Right now one can intercept, transform them, and include them in an allowlist. What do you think of naming them independent of AtomicLong so that a proxy class generated at runtime is easy to lookup in the allowlist?



Regards,
Aman Sharma

PhD Student
KTH Royal Institute of Technology
School of Electrical Engineering and Computer Science (EECS)
Department of Theoretical Computer Science (TCS)
<http://www.kth.se><https://www.kth.se/profile/amansha><https://www.kth.se/profile/amansha>
<https://www.kth.se/profile/amansha>https://algomaster99.github.io/
________________________________
From: David Holmes <david.holmes at oracle.com>
Sent: Monday, May 20, 2024 2:30:37 PM
To: Aman Sharma; liangchenblue at gmail.com
Cc: core-libs-dev at openjdk.org; leyden-dev at openjdk.org
Subject: Re: Deterministic naming of subclasses of `java/lang/reflect/Proxy`

On 20/05/2024 10:12 pm, Aman Sharma wrote:
> Hi David,
>
>
>  > How did you try to intercept them? Hidden classes are not "loaded" in
> the normal sense so won't trigger class load events.
>
>
> I could not intercept them. I only see them when I pass `-verbose:class`
> in the Java CLI.

Yes that is why I asked how you tried to intercept them.

>
> I also couldn't intercept them using JVMTI Class File Load Hook
> <https://docs.oracle.com/en/java/javase/21/docs/specs/jvmti.html#ClassFileLoadHook> event. However JEP 371 suggests that it should be possible to intercept them using JVMTI Class Load <https://docs.oracle.com/en/java/javase/21/docs/specs/jvmti.html#ClassLoad> event, but I won't have the bytecode at this stage. So is there no way to get its bytecode before it is linked and initialized in the JVM?

Hidden classes are not loaded so I would not expect any class load
events. However the exact nature of the JVMTI class load event is
unclear as it talks about "class or interface creation" which is neither
loading or defining per se. But a class prepare event sounds like it
should be issued. However neither give you access to the bytecode of the
class AFAICS.

David
-----


>
> Regards,
> Aman Sharma
>
> PhD Student
> KTH Royal Institute of Technology
> School of Electrical Engineering and Computer Science (EECS)
> Department of Theoretical Computer Science (TCS)
> <http://www.kth.se><https://www.kth.se/profile/amansha><https://www.kth.se/profile/amansha>
> <https://www.kth.se/profile/amansha>https://algomaster99.github.io/
> <https://algomaster99.github.io/>
> ------------------------------------------------------------------------
> *From:* David Holmes <david.holmes at oracle.com>
> *Sent:* Monday, May 20, 2024 2:59:17 AM
> *To:* Aman Sharma; liangchenblue at gmail.com
> *Cc:* core-libs-dev at openjdk.org; leyden-dev at openjdk.org
> *Subject:* Re: Deterministic naming of subclasses of
> `java/lang/reflect/Proxy`
> On 17/05/2024 9:43 pm, Aman Sharma wrote:
>> Hi Chen,
>>
>>  > java.lang.invoke.LambdaForm$MH/0x00000200cc000400
>>
>> I do see this as output when I pass -verbose:class. However, based on my
>> experiments, I have seen that neither an agent passed via 'javaagent'
>> nor an agent passed via 'agentpath' is able to intercept this hidden class.
>
> How did you try to intercept them? Hidden classes are not "loaded" in
> the normal sense so won't trigger class load events.
>
>> Also, I was a bit confused since I saw somewhere that the names of
>> hidden classes are null. But thanks for clarifying here.
>
> The JEP clearly defines the name format for hidden classes - though the
> final component is VM specific (and typically a hashcode).
>
> https://openjdk.org/jeps/371 <https://openjdk.org/jeps/371>
>
> Cheers,
> David
> -----
>
>>  > avoid dynamic class loading
>>
>> I don't see dynamic class loading as a problem. I only mind some
>> unstable generation aspects of them which make it hard to verify them
>> based on an allowlist.
>>
>> For example, if this hidden class is generated with the exact same name
>> and the exact same bytecode during runtime as well, it would be easy to
>> verify it. However, I do see the names are based on some sort of memory
>> address so and I don't know what bytecode it has so I don't have
>> suggestions to make them stable as of now. For Proxy classes, I feel it
>> can be addressed unless you disagree or some involved in Project Leyden
>> does. :) Thank you for forwarding my mail there.
>>
>> Regards,
>> Aman Sharma
>>
>> PhD Student
>> KTH Royal Institute of Technology
>> https://algomaster99.github.io/ <https://algomaster99.github.io/>
> <https://algomaster99.github.io/ <https://algomaster99.github.io/>>
>>
>> ------------------------------------------------------------------------
>> *From:* liangchenblue at gmail.com <liangchenblue at gmail.com>
>> *Sent:* Friday, May 17, 2024 1:23:58 pm
>> *To:* Aman Sharma <amansha at kth.se>
>> *Cc:* core-libs-dev at openjdk.org <core-libs-dev at openjdk.org>;
>> leyden-dev at openjdk.org <leyden-dev at openjdk.org>
>> *Subject:* Re: Deterministic naming of subclasses of
>> `java/lang/reflect/Proxy`
>>
>> Hi Aman,
>> For `-verbose:class`, it's a JVM argument instead of a program argument;
>> so when you run a java program like `java Main`, you should call it as
>> `java -verbose:class Main`.
>> When done correctly, you should see hidden class outputs like:
>> [0.032s][info][class,load]
>> java.lang.invoke.LambdaForm$MH/0x00000200cc000400 source:
>> __JVM_LookupDefineClass__
>> The loading of java.lang.invoke hidden classes requires your program to
>> use MethodHandle features, like a lambda.
>>
>> I think the problem you are exploring, that to avoid dynamic class
>> loading and effectively turn Java Platform closed for security, is also
>> being accomplished by project Leyden (as I've shared initially); Thus, I
>> am forwarding this to leyden-dev instead, so you can see what approach
>> Leyden uses to accomplish the same goal as yours.
>>
>> Regards, Chen Liang
>>
>> On Fri, May 17, 2024 at 4:40?AM Aman Sharma <amansha at kth.se
>> <mailto:amansha at kth.se <mailto:amansha at kth.se>>> wrote:
>>
>>     __
>>
>>     Hi Roger,
>>
>>
>>     Do you have ideas on how to intercept them? My javaagent is not able
>>     to nor a JVMTI agent passed using `agentpath` option. It also does
>>     not seem to show up in logs when I pass `-verbose:class`.
>>
>>
>>     Also, what do you think of renaming the proxy classes as suggested
>>     below?
>>
>>
>>     Regards,
>>     Aman Sharma
>>
>>     PhD Student
>>     KTH Royal Institute of Technology
>>     School of Electrical Engineering and Computer Science (EECS)
>>     Department of Theoretical Computer Science (TCS)
>>     <http://www.kth.se><https://www.kth.se/profile/amansha><https://www.kth.se/profile/amansha <http://www.kth.se><https://www.kth.se/profile/amansha><https://www.kth.se/profile/amansha>>
>>     <https://www.kth.se/profile/amansha
> <https://www.kth.se/profile/amansha>>https://algomaster99.github.io/
>>     <https://algomaster99.github.io/ <https://algomaster99.github.io/>>
>>     ------------------------------------------------------------------------
>>     *From:* core-libs-dev <core-libs-dev-retn at openjdk.org
>>     <mailto:core-libs-dev-retn at openjdk.org
> <mailto:core-libs-dev-retn at openjdk.org>>> on behalf of Roger Riggs
>>     <roger.riggs at oracle.com <mailto:roger.riggs at oracle.com <mailto:roger.riggs at oracle.com>>>
>>     *Sent:* Friday, May 17, 2024 4:57:46 AM
>>     *To:* core-libs-dev at openjdk.org <mailto:core-libs-dev at openjdk.org <mailto:core-libs-dev at openjdk.org>>
>>     *Subject:* Re: Deterministic naming of subclasses of
>>     `java/lang/reflect/Proxy`
>>     Hi Aman,
>>
>>     You may also run into hidden classes (JEP 371: Hidden Classes) that
>>     allow classes to be defined, at runtime, without names.
>>     It has been proposed to use them for generated proxies but that
>>     hasn't been implemented yet.
>>     There are benefits to having nameless classes, because they can't be
>>     referenced by name, only as a capability, they can be better
>>     encapsulated.
>>
>>     fyi, Roger Riggs
>>
>>
>>     On 5/16/24 8:11 AM, Aman Sharma wrote:
>>>
>>>     Hi,
>>>
>>>
>>>     Thanks for your response, Liang!
>>>
>>>
>>>     > I think you meant CVE-2021-42392 instead of 2022.
>>>
>>>
>>>     Sorry of the error. I indeed meant CVE-2021-42392
>>>     <https://nvd.nist.gov/vuln/detail/cve-2021-42392
> <https://nvd.nist.gov/vuln/detail/cve-2021-42392>>.
>>>
>>>
>>>     > Leyden mainly avoids this unstable generation by performing a
>>>     training run to collect classes loaded
>>>
>>>
>>>     Would love to know the details of Project Leyden and how they
>>>     worked so far to focus on this goal. In our case, the training run
>>>     is the test suite.
>>>
>>>
>>>     > GeneratedConstructorAccessor is already retired by JEP 416 [2]
>>>     in Java 18
>>>
>>>
>>>     I did see them not appearing in my allowlist when I ran my study
>>>     subject (Apache PDFBox) with Java 21. Thanks for letting me know
>>>     about this JEP. I see they are re-implemented with method handles.
>>>
>>>
>>>     > How are you checking the classes?
>>>
>>>
>>>     To detect runtime generated code, we have javaagent that is hooked
>>>     statically to the test suite execution. It gives us all classes
>>>     that that is loaded post the JVM and the javaagent are loaded. So
>>>     we only check the classes loaded for the purpose of running the
>>>     application. This is also why we did not choose -agentlib as it
>>>     would give classes for the setting up JVM and javaagent and we the
>>>     user of our tool must the classes they load.
>>>
>>>
>>>     Next, we have a `ClassFileTransformer` hook in the agent where we
>>>     produce the checksum using the bytecode. And we compare the
>>>     checksum with the one existing in the allowlist. The checksum
>>>     computation algorithm is same for both steps. Let me describe how
>>>     I compute the checksum.
>>>
>>>
>>>      1. I get the CONSTANT_Class_info
>>>         <https://docs.oracle.com/javase/specs/jvms/se11/html/jvms-4.html#jvms-4.4.1 <https://docs.oracle.com/javase/specs/jvms/se11/html/jvms-4.html#jvms-4.4.1>> entry corresponding to `this_class` and rewrite the CONSTANT_Utf8_info <https://docs.oracle.com/javase/specs/jvms/se11/html/jvms-4.html#jvms-4.4.7 <https://docs.oracle.com/javase/specs/jvms/se11/html/jvms-4.html#jvms-4.4.7>> corresponding to a fix String constant, say "foo".
>>>      2. Since, the name of the class is used to refer to its types
>>>         members (fields/method), I get all CONSTANT_Fieldref_info
>>>         <https://docs.oracle.com/javase/specs/jvms/se11/html/jvms-4.html#jvms-4.4.2 <https://docs.oracle.com/javase/specs/jvms/se11/html/jvms-4.html#jvms-4.4.2>> and if its `class_index` corresponds to the old `this_class`, we rewrite the UTF8 value of class_index to the same constant "foo".
>>>      3. Next, since the naming of the fields, in Proxy classes, are
>>>         also suffixed by numbers, for example, `private static Method
>>>         m4`, we rewrite the UTF8 value of name in the
>>>         CONSTANT_NameAndType_info
>>>         <https://docs.oracle.com/javase/specs/jvms/se11/html/jvms-4.html#jvms-4.4.6 <https://docs.oracle.com/javase/specs/jvms/se11/html/jvms-4.html#jvms-4.4.6>>.
>>>      4. These fields can also have a random order so we simply sort
>>>         the entire byte code using `Arrays.sort(byte[])` to eliminate
>>>         any differences due to ordering of fields/methods.
>>>      5. Simply sorting the byte array still had minute differences. I
>>>         could not understand why they existed even though values in
>>>         constant pool of the bytecode in allowlist and at runtime were
>>>         exactly the same after rewriting. The differences existed in
>>>         the bytes of the Code attribute of methods. I concluded that
>>>         the bytes stored some position information. To avoid this, I
>>>         created a subarray where I considered the bytes corresponding
>>>         to `CONSTANT_Utf8_info.bytes` only. Computing a checksum for
>>>         it resulted in the same checksums for both classfiles.
>>>
>>>
>>>     Let's understand the whole approach with an example of Proxy class.
>>>
>>>     `
>>>     public  final  class  $Proxy42  extends  Proxy  implements  org.apache.logging.log4j.core.config.plugins.Plugin  {
>>>     `
>>>
>>>     The will go in the allowlist as "Proxy_Plugin: <SHA256 checksum>".
>>>
>>>     When the same class is intercepted at runtime, say "$Proxy10", we
>>>     look for "Proxy_Plugin" in the allowlist and since the checksum
>>>     algorithm is same in both cases, we get a match and let the class
>>>     load.
>>>
>>>     This approach has seemed to work well for Proxy classes, Generated
>>>     Constructor Accessor (which is removed as you said). I also looked
>>>     at the species generated by method handles. I did not notice any
>>>     modification in them. Their name generation seemed okay to me. If
>>>     some new Species are generated, it is of course detected since it
>>>     is not in the allowlist.
>>>
>>>     I have not looked into LambdaMetafactory because I did not
>>>     encounter it as a problem so far, but I am aware its name
>>>     generation is also unstable. I have run my approach only a few
>>>     projects only. And for hidden classes, I assume the the agent
>>>     won't be able to intercept them so detecting them would be really
>>>     hard.
>>>
>>>
>>>     Regards,
>>>     Aman Sharma
>>>
>>>     PhD Student
>>>     KTH Royal Institute of Technology
>>>     School of Electrical Engineering and Computer Science (EECS)
>>>     Department of Theoretical Computer Science (TCS)
>>>     <https://www.kth.se/profile/amansha
> <https://www.kth.se/profile/amansha>>https://algomaster99.github.io/
> <https://algomaster99.github.io/ <https://algomaster99.github.io/>>
>>>     ------------------------------------------------------------------------
>>>     *From:* liangchenblue at gmail.com <mailto:liangchenblue at gmail.com <mailto:liangchenblue at gmail.com>>
>>>     <liangchenblue at gmail.com> <mailto:liangchenblue at gmail.com <mailto:liangchenblue at gmail.com>>
>>>     *Sent:* Thursday, May 16, 2024 5:52:03 AM
>>>     *To:* Aman Sharma; core-libs-dev
>>>     *Cc:* Martin Monperrus
>>>     *Subject:* Re: Deterministic naming of subclasses of
>>>     `java/lang/reflect/Proxy`
>>>     Hi Aman,
>>>     I think you meant CVE-2021-42392 instead of 2022.
>>>
>>>     For your approach of an "allowlist" for Java runtime, project
>>>     Leyden is looking to generate a static image [1], that
>>>     > At run time it cannot load classes from outside the image, nor
>>>     can it create classes dynamically.
>>>     Leyden mainly avoids this unstable generation by performing a
>>>     training run to collect classes loaded and even object graphs; I
>>>     am not familiar with the details unfortunately.
>>>
>>>     Otherwise, the Proxy discussion belongs better to core-libs-dev,
>>>     as java.lang.reflect.Proxy is part of Java's core libraries. I am
>>>     replying this thread to core-libs-dev.
>>>
>>>     For your perceived problem that classes don't have unique names,
>>>     your description sounds dubious: GeneratedConstructorAccessor is
>>>     already retired by JEP 416 [2] in Java 18, and there are many
>>>     other cases in which JDK generates classes without stable names,
>>>     notoriously LambdaMetafactory (Gradle wished for cacheable
>>>     Lambdas); the same applies for the generated classes for
>>>     MethodHandle's LambdaForms (which carries implementation code for
>>>     LambdaForm). How are you checking the classes? It seems you are
>>>     not checking hidden classes. Proxy and Lambda classes are defined
>>>     by the caller's class loader, while LambdaForms are under JDK's
>>>     system class loader I think. We need to ensure you are correctly
>>>     finding all unstable classes before we can proceed.
>>>
>>>     [1]: https://openjdk.org/projects/leyden/notes/01-beginnings
> <https://openjdk.org/projects/leyden/notes/01-beginnings>
>>>     <https://openjdk.org/projects/leyden/notes/01-beginnings
> <https://openjdk.org/projects/leyden/notes/01-beginnings>>
>>>     [2]: https://openjdk.org/jeps/416 <https://openjdk.org/jeps/416>
> <https://openjdk.org/jeps/416 <https://openjdk.org/jeps/416>>
>>>
>>>     On Wed, May 15, 2024 at 7:00?PM Aman Sharma <amansha at kth.se
>>>     <mailto:amansha at kth.se <mailto:amansha at kth.se>>> wrote:
>>>
>>>         Hi,
>>>
>>>
>>>         My name is Aman and I am a PhD student at KTH Royal Institute
>>>         of Technology, Stockholm, Sweden. I research as part of CHAINS
>>>         <https://chains.proj.kth.se/ <https://chains.proj.kth.se/>> project to
> strengthen the
>>>         software supply chain of multiple ecosystem. I particularly
>>>         focus on runtime integrity in Java. In this email, I want to
>>>         write about an issue I have discovered with /dynamic
>>>         generation of `java.lang.reflect.Proxy`classes/. I will
>>>         propose a solution and would love to hear the feedback from
>>>         the community. Let me know if this is the correct mailing-list
>>>         for such discussions. It seemed the most relevant from this
>>>         list <https://mail.openjdk.org/mailman/listinfo
> <https://mail.openjdk.org/mailman/listinfo>>.
>>>
>>>
>>>         *My research*
>>>
>>>         *
>>>         *
>>>
>>>         Java has features to load class on the fly - it can either
>>>         download or generate a class at runtime. These features are
>>>         useful for inner workings of JDK. For example, implementing
>>>         annotations, reflective access, etc. However, these features
>>>         have also contributed to critical vulnerabilities in the past
>>>         - CVE-2021-44228  (log4shell), CVE-2022-33980, CVE-2022-42392.
>>>         All of these vulnerabilities have one thing in common - /a
>>>         class that was not known during build time was
>>>         downloaded/generated at runtime and loaded into JVM./
>>>
>>>
>>>         To defend against such vulnerabilities, we propose a solution
>>>         to /allowlist classes for runtime/. This allowlist will
>>>         contain an exhaustive list of classes that can be loaded by
>>>         the JVM and it will be enforced at runtime. We build this
>>>         allowlist from three sources:
>>>
>>>          1. All classes of all modules provided by the Java Standard
>>>             Library. We use ClassGraph
>>>             <https://github.com/classgraph/classgraph
> <https://github.com/classgraph/classgraph>> to scan the JDK.
>>>          2. We can take the source code and all dependencies of an
>>>             application. We use a software bill of materials to get
>>>             all the data.
>>>          3. Finally, we use run the test suite to include any runtime
>>>             downloaded/generated classes.
>>>
>>>         Such a list is able to prevent the above 3 CVEs because it
>>>         does not let the "unknown" bytecode to be loaded.
>>>
>>>         *Problem with generating such an allowlist*
>>>         *
>>>         *
>>>         The first two parts of the allowlist are easy to get. The
>>>         problem is with the third step where we want to allowlist all
>>>         the classes that could be downloaded or generated. Upon
>>>         running the test suite and hooking to the classes it loads, we
>>>         observer that the list consists of classes that are called
>>>         "com/sun/proxy/$Proxy2",
>>>         "jdk/internal/reflect/GeneratedConstructorAccessor3" among
>>>         many more. The purpose of these classes can be identifed. The
>>>         proxy class is created for to implement an annotation. The
>>>         accessor gives access to constructor of a class to the JVM.
>>>
>>>         When enforcing this allowlist at runtime, we see that the
>>>         bytecode content for "com/sun/proxy/$Proxy2" differs in the
>>>         allowlist and at runtime. In our case, we we are experimenting
>>>         with pdfbox <https://github.com/apache/pdfbox <https://github.com/apache/pdfbox>> so
> we created
>>>         the allowlist using its test suite. Then we enforced this
>>>         allowlist while running some of its subcommands. However,
>>>         there was some other proxy class say "com/sun/proxy/$Proxy5"
>>>         at runtime that implemented the same interfaces and had the
>>>         same methods as "com/sun/proxy/$Proxy2" in the allowlist. They
>>>         only differed in the name of the class, order of fields, and
>>>         types for fields references. This could happen because the
>>>         order of the loading of class is workload dependent, but it
>>>         causes problem to generate such an allowlist.
>>>
>>>         *Solution
>>>         *
>>>
>>>
>>>         We propose that naming of subclasses of
>>>         "java/lang/reflect/Proxy" should not be dependent upon the
>>>         order of loading. In order to do so, two issues can be fixed:
>>>
>>>          1. The naming of the class should not be based on AtomicLong
>>>             <https://github.com/openjdk/jdk/blob/b687aa550837830b38f0f0faa69c353b1e85219c/src/java.base/share/classes/java/lang/reflect/Proxy.java#L531 <https://github.com/openjdk/jdk/blob/b687aa550837830b38f0f0faa69c353b1e85219c/src/java.base/share/classes/java/lang/reflect/Proxy.java#L531>>. Rather it could be named based on the interfaces it implements. I also wonder why AtomicLong is chosen in the first place.
>>>          2. Methods of the interfaces must be in a particular order.
>>>             Right now, they are not sorted in any particular order
>>>             <https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/lang/Class.java#L2178 <https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/lang/Class.java#L2178>>.
>>>
>>>
>>>         These fixes will make proxy class generation deterministic
>>>         with respect to order of loading and won't be flagged at
>>>         runtime since the test suite would already detect them.
>>>
>>>         I would love to hear from the community about these ideas. If
>>>         in agreement, I would be happy to produce a patch. I have
>>>         discovered this issue with subclasses of
>>>         GeneratedConstructorAccessor
>>>         <https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/jdk/internal/reflect/ConstructorAccessor.java <https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/jdk/internal/reflect/ConstructorAccessor.java>> as well and I imagine it will also apply to some other runtime generated classes. If you disagree, please let me know also. It helps with my research.
>>>
>>>         I also have PoCs for the above CVEs
>>>         <https://github.com/chains-project/exploits-for-sbom.exe
> <https://github.com/chains-project/exploits-for-sbom.exe>> and
>>>         a proof concept tool is being developed under the name
>>>         sbom.exe <https://github.com/chains-project/sbom.exe
> <https://github.com/chains-project/sbom.exe>> in case
>>>         any one wonders about the implementation. I would also be
>>>         happy to explain more.
>>>
>>>         Regards,
>>>         Aman Sharma
>>>
>>>         PhD Student
>>>         KTH Royal Institute of Technology
>>>         School of Electrical Engineering and Computer Science (EECS)
>>>         Department of Theoretical Computer Science (TCS)
>>>         <https://www.kth.se/profile/amansha
> <https://www.kth.se/profile/amansha>>https://algomaster99.github.io/
> <https://algomaster99.github.io/ <https://algomaster99.github.io/>>
>>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240520/9d46e891/attachment-0001.htm>

From alanb at openjdk.org  Mon May 20 12:58:04 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 20 May 2024 12:58:04 GMT
Subject: RFR: 8330542: Add jaxp-strict.properties in preparation for a
 secure by default configuration [v10]
In-Reply-To: <gXFnZ3UfC7XxCj4WcpCs0c8GVbWGR5xYTASbKNOpAxw=.ca8e2b83-2ef5-44b2-8c1d-965cfe0cfe71@github.com>
References: <v1bAYKgH9zfooXpvnBw4Vu2TIqHuKqqtSmgB0hiNp-Q=.31661a99-ecfc-4a05-8045-67b5f680db60@github.com>
 <Jc4tdJwAUMokA_Zm15xcJDE6FLlmWI4JTCcW3uo8gPU=.a4ffc7d1-0e3e-408a-bb65-976e5095a831@github.com>
 <gXFnZ3UfC7XxCj4WcpCs0c8GVbWGR5xYTASbKNOpAxw=.ca8e2b83-2ef5-44b2-8c1d-965cfe0cfe71@github.com>
Message-ID: <QwaxkRpxaO0xfYHM8hEG3F_cL-X5z2IZYdVkQ40S66M=.a9d88d20-a8b9-487c-8d67-57db41a2a973@github.com>

On Mon, 20 May 2024 12:48:01 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Joe Wang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   withdraw changes to jaxp.properties. The configuration process has not changed, changing the default configuration would result in many failures that test the process.
>
> src/java.xml/share/classes/module-info.java line 444:
> 
>> 442:  *
>> 443:  * Deploying with this configuration prevents processors from unknowingly making
>> 444:  * outbound network connections to fetch DTDs, or process XML that makes use of
> 
> s/process/processing/

In XML parlance, a "processor" is an aggregation of parsers, serializers, and other things that contribute to the processing. So I think it could be either here, but you have a point and if it stays as "processor" then it should link #FacPro where the term is defined.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18831#discussion_r1606745477

From mullan at openjdk.org  Mon May 20 13:06:04 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Mon, 20 May 2024 13:06:04 GMT
Subject: RFR: 8330542: Add jaxp-strict.properties in preparation for a
 secure by default configuration [v10]
In-Reply-To: <QwaxkRpxaO0xfYHM8hEG3F_cL-X5z2IZYdVkQ40S66M=.a9d88d20-a8b9-487c-8d67-57db41a2a973@github.com>
References: <v1bAYKgH9zfooXpvnBw4Vu2TIqHuKqqtSmgB0hiNp-Q=.31661a99-ecfc-4a05-8045-67b5f680db60@github.com>
 <Jc4tdJwAUMokA_Zm15xcJDE6FLlmWI4JTCcW3uo8gPU=.a4ffc7d1-0e3e-408a-bb65-976e5095a831@github.com>
 <gXFnZ3UfC7XxCj4WcpCs0c8GVbWGR5xYTASbKNOpAxw=.ca8e2b83-2ef5-44b2-8c1d-965cfe0cfe71@github.com>
 <QwaxkRpxaO0xfYHM8hEG3F_cL-X5z2IZYdVkQ40S66M=.a9d88d20-a8b9-487c-8d67-57db41a2a973@github.com>
Message-ID: <2mJ-7JL_PjE-BMboEkzX_Eb_hvccSdjiKyS42wM0E_A=.96b2b620-9c30-4c14-b367-f53ba929eed5@github.com>

On Mon, 20 May 2024 12:55:24 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> src/java.xml/share/classes/module-info.java line 444:
>> 
>>> 442:  *
>>> 443:  * Deploying with this configuration prevents processors from unknowingly making
>>> 444:  * outbound network connections to fetch DTDs, or process XML that makes use of
>> 
>> s/process/processing/
>
> In XML parlance, a "processor" is an aggregation of parsers, serializers, and other things that contribute to the processing. So I think it could be either here, but you have a point and if it stays as "processor" then it should link #FacPro where the term is defined.

It's the wording that doesn't sound right, before this you have "making" which doesn't sound right with "process". Maybe it needs two sentences.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18831#discussion_r1606754542

From duke at openjdk.org  Mon May 20 13:20:17 2024
From: duke at openjdk.org (Oussama Louati)
Date: Mon, 20 May 2024 13:20:17 GMT
Subject: RFR: 8307818: Convert Indify tool to Classfile API [v3]
In-Reply-To: <tCFk9yrCtcoBnzvNIgceY0eOaXg9ZiN9nkCuhHIyMyw=.9cc5f994-8d35-411a-bb39-7c3f2ac34dda@github.com>
References: <tCFk9yrCtcoBnzvNIgceY0eOaXg9ZiN9nkCuhHIyMyw=.9cc5f994-8d35-411a-bb39-7c3f2ac34dda@github.com>
Message-ID: <nOFrusZUnT1HOpyWUtG0nKCRIawlhX3NW40-WBrMm8Y=.5e31ce42-350b-478d-af8a-9c65ae091b2e@github.com>

> An indify tool in j.l.i tests (also in vmTestBase) convert some source-code private static methods with MT_ MH_, and INDY_ prefixes into MethodHandle, MethodType, and CallSite constants.
> It currently uses ad-hoc code to process class files and intends to migrate to ASM; but since we have the Classfile API, we can migrate to Classfile API instead.

Oussama Louati has updated the pull request incrementally with one additional commit since the last revision:

  remove: remove unnecessary ClassModel fields

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/18841/files
  - new: https://git.openjdk.org/jdk/pull/18841/files/96e6920a..040e925b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18841&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18841&range=01-02

  Stats: 3 lines in 1 file changed: 0 ins; 2 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/18841.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18841/head:pull/18841

PR: https://git.openjdk.org/jdk/pull/18841

From alanb at openjdk.org  Mon May 20 14:52:02 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 20 May 2024 14:52:02 GMT
Subject: RFR: 8332154: Memory leak in SynchronousQueue [v3]
In-Reply-To: <iMAdASClqlen1dLO4nK3q_RTGtHgMxKeMImJ2J2lGUA=.2de28d45-7faa-4718-ab36-e7201cee0e36@github.com>
References: <Fj3W5LlneHODz3PcBD0Ypu2f34UYvxw1iLLKz5pba-I=.0f419338-0a23-4834-8404-55aeab4b813f@github.com>
 <iMAdASClqlen1dLO4nK3q_RTGtHgMxKeMImJ2J2lGUA=.2de28d45-7faa-4718-ab36-e7201cee0e36@github.com>
Message-ID: <9100v9cHxhsyE8rG4wKd3yH3459ErRLNw_97VrNPHAU=.57966820-02f4-411b-8c60-f581288940c9@github.com>

On Fri, 17 May 2024 13:19:19 GMT, Viktor Klang <vklang at openjdk.org> wrote:

>> Local testing seems to indicate that this fix (which mirrors what's done in the FIFO mode) addresses the problem. Regression test added for JDK20+
>
> Viktor Klang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Moving the memory leak test for SynchronousQueue into its own test and runs only for JDK20+, using VirtualThreads

Looks okay, I just wonder how reliable assertDoesntLeak will concurrent agents, debug builds, and VM options such as a Xcomp that will challenge the await(10s).  Minimally the timed awaits should be untimed. Another idea is try an ES like this:

        try (var executor = Executors.newVirtualThreadPerTaskExecutor()) {
            for (int i = 0; i < NUMBER_OF_ITEMS; i++) {
                executor.submit( .. producer .. );
                executor.submit(.. consumer ..);
            }
        }

No need for the count down latches or the need to retry on InterruptedException. The close method waits for the 400 virtual threads to finish so you can assert that the queue is empty.

The loop that waits for survivors to empty can be unbounded too. If there is a leak then the test will timeout.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19271#issuecomment-2120616967

From vklang at openjdk.org  Mon May 20 15:17:17 2024
From: vklang at openjdk.org (Viktor Klang)
Date: Mon, 20 May 2024 15:17:17 GMT
Subject: RFR: 8332154: Memory leak in SynchronousQueue [v4]
In-Reply-To: <Fj3W5LlneHODz3PcBD0Ypu2f34UYvxw1iLLKz5pba-I=.0f419338-0a23-4834-8404-55aeab4b813f@github.com>
References: <Fj3W5LlneHODz3PcBD0Ypu2f34UYvxw1iLLKz5pba-I=.0f419338-0a23-4834-8404-55aeab4b813f@github.com>
Message-ID: <Qy-TRTE6MkMh7i3mVatgmkCdxDC5N3sxTS2qok2X--A=.eb4e310f-f961-499a-8f29-6e06564941ee@github.com>

> Local testing seems to indicate that this fix (which mirrors what's done in the FIFO mode) addresses the problem. Regression test added for JDK20+

Viktor Klang has updated the pull request incrementally with one additional commit since the last revision:

  Addressing review feedback

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19271/files
  - new: https://git.openjdk.org/jdk/pull/19271/files/cc0a2014..f32e9ea4

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19271&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19271&range=02-03

  Stats: 37 lines in 1 file changed: 2 ins; 10 del; 25 mod
  Patch: https://git.openjdk.org/jdk/pull/19271.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19271/head:pull/19271

PR: https://git.openjdk.org/jdk/pull/19271

From vklang at openjdk.org  Mon May 20 15:17:17 2024
From: vklang at openjdk.org (Viktor Klang)
Date: Mon, 20 May 2024 15:17:17 GMT
Subject: RFR: 8332154: Memory leak in SynchronousQueue [v3]
In-Reply-To: <9100v9cHxhsyE8rG4wKd3yH3459ErRLNw_97VrNPHAU=.57966820-02f4-411b-8c60-f581288940c9@github.com>
References: <Fj3W5LlneHODz3PcBD0Ypu2f34UYvxw1iLLKz5pba-I=.0f419338-0a23-4834-8404-55aeab4b813f@github.com>
 <iMAdASClqlen1dLO4nK3q_RTGtHgMxKeMImJ2J2lGUA=.2de28d45-7faa-4718-ab36-e7201cee0e36@github.com>
 <9100v9cHxhsyE8rG4wKd3yH3459ErRLNw_97VrNPHAU=.57966820-02f4-411b-8c60-f581288940c9@github.com>
Message-ID: <zMtCA40GJiEerSVKA2DQKs0KdORUm7v8QZFFsu85Mpc=.ab2c7473-b125-43f3-ae96-5cb0f40e9397@github.com>

On Mon, 20 May 2024 14:49:13 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Viktor Klang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Moving the memory leak test for SynchronousQueue into its own test and runs only for JDK20+, using VirtualThreads
>
> Looks okay, I just wonder how reliable assertDoesntLeak with concurrent agents, debug builds, and VM options such as a Xcomp that will challenge the await(10s).  Minimally the timed awaits should be untimed. Another idea is try an ES like this:
> 
>         try (var executor = Executors.newVirtualThreadPerTaskExecutor()) {
>             for (int i = 0; i < NUMBER_OF_ITEMS; i++) {
>                 executor.submit( .. producer .. );
>                 executor.submit(.. consumer ..);
>             }
>         }
> 
> No need for the count down latches or the need to retry on InterruptedException. The close method waits for the 400 virtual threads to finish so you can assert that the queue is empty.
> 
> The loop that waits for survivors to empty can be unbounded too. If there is a leak then the test will timeout.

@AlanBateman Great suggestions, Alan. I've updated the PR to reflect your improvements.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19271#issuecomment-2120665477

From vklang at openjdk.org  Mon May 20 15:23:36 2024
From: vklang at openjdk.org (Viktor Klang)
Date: Mon, 20 May 2024 15:23:36 GMT
Subject: RFR: 8332154: Memory leak in SynchronousQueue [v5]
In-Reply-To: <Fj3W5LlneHODz3PcBD0Ypu2f34UYvxw1iLLKz5pba-I=.0f419338-0a23-4834-8404-55aeab4b813f@github.com>
References: <Fj3W5LlneHODz3PcBD0Ypu2f34UYvxw1iLLKz5pba-I=.0f419338-0a23-4834-8404-55aeab4b813f@github.com>
Message-ID: <9x5DTnqnneHqJS58AaX06qonw4Iv_WNNV0niQnXErXc=.6c274261-72e5-417d-b0d7-58dd7e879dd5@github.com>

> Local testing seems to indicate that this fix (which mirrors what's done in the FIFO mode) addresses the problem. Regression test added for JDK20+

Viktor Klang has updated the pull request incrementally with one additional commit since the last revision:

  Turn the Runnables into callables to avoid having to catch any InterruptedException

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19271/files
  - new: https://git.openjdk.org/jdk/pull/19271/files/f32e9ea4..e0b2eb89

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19271&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19271&range=03-04

  Stats: 16 lines in 1 file changed: 0 ins; 12 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/19271.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19271/head:pull/19271

PR: https://git.openjdk.org/jdk/pull/19271

From alanb at openjdk.org  Mon May 20 15:29:03 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 20 May 2024 15:29:03 GMT
Subject: RFR: 8332154: Memory leak in SynchronousQueue [v5]
In-Reply-To: <9x5DTnqnneHqJS58AaX06qonw4Iv_WNNV0niQnXErXc=.6c274261-72e5-417d-b0d7-58dd7e879dd5@github.com>
References: <Fj3W5LlneHODz3PcBD0Ypu2f34UYvxw1iLLKz5pba-I=.0f419338-0a23-4834-8404-55aeab4b813f@github.com>
 <9x5DTnqnneHqJS58AaX06qonw4Iv_WNNV0niQnXErXc=.6c274261-72e5-417d-b0d7-58dd7e879dd5@github.com>
Message-ID: <qnnWFNk2Rv62Q8cFiWFs0N6d_BAsyS6O3OTOkIDD1KI=.548d11e2-420f-435c-8f1e-5e9204841c7c@github.com>

On Mon, 20 May 2024 15:23:36 GMT, Viktor Klang <vklang at openjdk.org> wrote:

>> Local testing seems to indicate that this fix (which mirrors what's done in the FIFO mode) addresses the problem. Regression test added for JDK20+
>
> Viktor Klang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Turn the Runnables into callables to avoid having to catch any InterruptedException

Marked as reviewed by alanb (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/19271#pullrequestreview-2066466910

From duke at openjdk.org  Mon May 20 15:34:28 2024
From: duke at openjdk.org (Glavo)
Date: Mon, 20 May 2024 15:34:28 GMT
Subject: RFR: 8307818: Convert Indify tool to Classfile API [v3]
In-Reply-To: <nOFrusZUnT1HOpyWUtG0nKCRIawlhX3NW40-WBrMm8Y=.5e31ce42-350b-478d-af8a-9c65ae091b2e@github.com>
References: <tCFk9yrCtcoBnzvNIgceY0eOaXg9ZiN9nkCuhHIyMyw=.9cc5f994-8d35-411a-bb39-7c3f2ac34dda@github.com>
 <nOFrusZUnT1HOpyWUtG0nKCRIawlhX3NW40-WBrMm8Y=.5e31ce42-350b-478d-af8a-9c65ae091b2e@github.com>
Message-ID: <bSqYJOyrVuB1C_-NAelBNXxpi9ep3uMQRWObnUjJeNA=.04a90363-da68-4844-bd75-35e9d80c2e42@github.com>

On Mon, 20 May 2024 13:20:17 GMT, Oussama Louati <duke at openjdk.org> wrote:

>> An indify tool in j.l.i tests (also in vmTestBase) convert some source-code private static methods with MT_ MH_, and INDY_ prefixes into MethodHandle, MethodType, and CallSite constants.
>> It currently uses ad-hoc code to process class files and intends to migrate to ASM; but since we have the Classfile API, we can migrate to Classfile API instead.
>
> Oussama Louati has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove: remove unnecessary ClassModel fields

test/jdk/java/lang/invoke/indify/Indify.java line 352:

> 350:     }
> 351: 
> 352:     public void indifyJar(File f, Object dest){

Suggestion:

    public void indifyJar(File f, Object dest) {

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18841#discussion_r1606931520

From duke at openjdk.org  Mon May 20 15:34:28 2024
From: duke at openjdk.org (Oussama Louati)
Date: Mon, 20 May 2024 15:34:28 GMT
Subject: RFR: 8307818: Convert Indify tool to Classfile API [v4]
In-Reply-To: <tCFk9yrCtcoBnzvNIgceY0eOaXg9ZiN9nkCuhHIyMyw=.9cc5f994-8d35-411a-bb39-7c3f2ac34dda@github.com>
References: <tCFk9yrCtcoBnzvNIgceY0eOaXg9ZiN9nkCuhHIyMyw=.9cc5f994-8d35-411a-bb39-7c3f2ac34dda@github.com>
Message-ID: <awdqStTqymofU42EuyEiPbqwJ79s789e_9B8ZOFD_jM=.aa611480-5eb5-42e4-96db-c9a1155b6c04@github.com>

> An indify tool in j.l.i tests (also in vmTestBase) convert some source-code private static methods with MT_ MH_, and INDY_ prefixes into MethodHandle, MethodType, and CallSite constants.
> It currently uses ad-hoc code to process class files and intends to migrate to ASM; but since we have the Classfile API, we can migrate to Classfile API instead.

Oussama Louati has updated the pull request incrementally with one additional commit since the last revision:

  Update test/jdk/java/lang/invoke/indify/Indify.java
  
  Co-authored-by: Glavo <zjx001202 at gmail.com>

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/18841/files
  - new: https://git.openjdk.org/jdk/pull/18841/files/040e925b..992c9773

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18841&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18841&range=02-03

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/18841.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18841/head:pull/18841

PR: https://git.openjdk.org/jdk/pull/18841

From liach at openjdk.org  Mon May 20 15:41:05 2024
From: liach at openjdk.org (Chen Liang)
Date: Mon, 20 May 2024 15:41:05 GMT
Subject: RFR: 8307818: Convert Indify tool to Classfile API [v4]
In-Reply-To: <awdqStTqymofU42EuyEiPbqwJ79s789e_9B8ZOFD_jM=.aa611480-5eb5-42e4-96db-c9a1155b6c04@github.com>
References: <tCFk9yrCtcoBnzvNIgceY0eOaXg9ZiN9nkCuhHIyMyw=.9cc5f994-8d35-411a-bb39-7c3f2ac34dda@github.com>
 <awdqStTqymofU42EuyEiPbqwJ79s789e_9B8ZOFD_jM=.aa611480-5eb5-42e4-96db-c9a1155b6c04@github.com>
Message-ID: <XvbEluoXf1p8rAVNISaz5h9ZPN7FX1mxFFuAibtZ_jw=.25449e8c-3659-4eb2-8fa3-e835ccba9bc3@github.com>

On Mon, 20 May 2024 15:34:28 GMT, Oussama Louati <duke at openjdk.org> wrote:

>> An indify tool in j.l.i tests (also in vmTestBase) convert some source-code private static methods with MT_ MH_, and INDY_ prefixes into MethodHandle, MethodType, and CallSite constants.
>> It currently uses ad-hoc code to process class files and intends to migrate to ASM; but since we have the Classfile API, we can migrate to Classfile API instead.
>
> Oussama Louati has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update test/jdk/java/lang/invoke/indify/Indify.java
>   
>   Co-authored-by: Glavo <zjx001202 at gmail.com>

test/jdk/java/lang/invoke/indify/Indify.java line 201:

> 199:                 } else if (ex != err) {
> 200:                 err.addSuppressed(ex);
> 201:             }

Suggestion:

                    err.addSuppressed(ex);
                }

test/jdk/java/lang/invoke/indify/Indify.java line 445:

> 443:         final char[] poolMarks;
> 444:         final Map<MethodModel, PoolEntry> Constants = new HashMap<>();
> 445:         final Map<MethodModel, String> IndySignatures = new HashMap<>();

Please use lowerCamelCase field names.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18841#discussion_r1606938989
PR Review Comment: https://git.openjdk.org/jdk/pull/18841#discussion_r1606941104

From duke at openjdk.org  Mon May 20 15:47:23 2024
From: duke at openjdk.org (Oussama Louati)
Date: Mon, 20 May 2024 15:47:23 GMT
Subject: RFR: 8307818: Convert Indify tool to Classfile API [v5]
In-Reply-To: <tCFk9yrCtcoBnzvNIgceY0eOaXg9ZiN9nkCuhHIyMyw=.9cc5f994-8d35-411a-bb39-7c3f2ac34dda@github.com>
References: <tCFk9yrCtcoBnzvNIgceY0eOaXg9ZiN9nkCuhHIyMyw=.9cc5f994-8d35-411a-bb39-7c3f2ac34dda@github.com>
Message-ID: <eIvMptnS6WR-AIOCeOQ5HRBovC85hgChpzGfZB--11s=.997fbf50-185c-4e53-bcab-c2b5e1db88ac@github.com>

> An indify tool in j.l.i tests (also in vmTestBase) convert some source-code private static methods with MT_ MH_, and INDY_ prefixes into MethodHandle, MethodType, and CallSite constants.
> It currently uses ad-hoc code to process class files and intends to migrate to ASM; but since we have the Classfile API, we can migrate to Classfile API instead.

Oussama Louati has updated the pull request incrementally with one additional commit since the last revision:

  Update test/jdk/java/lang/invoke/indify/Indify.java
  
  Co-authored-by: liach <7806504+liach at users.noreply.github.com>

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/18841/files
  - new: https://git.openjdk.org/jdk/pull/18841/files/992c9773..f6c5bf0f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18841&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18841&range=03-04

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/18841.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18841/head:pull/18841

PR: https://git.openjdk.org/jdk/pull/18841

From liach at openjdk.org  Mon May 20 15:47:23 2024
From: liach at openjdk.org (Chen Liang)
Date: Mon, 20 May 2024 15:47:23 GMT
Subject: RFR: 8307818: Convert Indify tool to Classfile API [v4]
In-Reply-To: <awdqStTqymofU42EuyEiPbqwJ79s789e_9B8ZOFD_jM=.aa611480-5eb5-42e4-96db-c9a1155b6c04@github.com>
References: <tCFk9yrCtcoBnzvNIgceY0eOaXg9ZiN9nkCuhHIyMyw=.9cc5f994-8d35-411a-bb39-7c3f2ac34dda@github.com>
 <awdqStTqymofU42EuyEiPbqwJ79s789e_9B8ZOFD_jM=.aa611480-5eb5-42e4-96db-c9a1155b6c04@github.com>
Message-ID: <tA2Ccs3-1rx9EiCn5HJZQCe6mPrrqxw6g_OLNCe9pfs=.23c46794-c251-4b40-920a-cd0a95c6d62a@github.com>

On Mon, 20 May 2024 15:34:28 GMT, Oussama Louati <duke at openjdk.org> wrote:

>> An indify tool in j.l.i tests (also in vmTestBase) convert some source-code private static methods with MT_ MH_, and INDY_ prefixes into MethodHandle, MethodType, and CallSite constants.
>> It currently uses ad-hoc code to process class files and intends to migrate to ASM; but since we have the Classfile API, we can migrate to Classfile API instead.
>
> Oussama Louati has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update test/jdk/java/lang/invoke/indify/Indify.java
>   
>   Co-authored-by: Glavo <zjx001202 at gmail.com>

test/jdk/java/lang/invoke/indify/Indify.java line 1362:

> 1360:                 List<LoadableConstantEntry> bsmArgs = new ArrayList<>();
> 1361:                 for (LoadableConstantEntry lce : classModel.constantPool().bootstrapMethodEntry(i).arguments()){
> 1362:                     bsmArgs.add(lce);

Suggestion:

                List<LoadableConstantEntry> bsmArgs = new ArrayList<>(classModel.constantPool().bootstrapMethodEntry(i).arguments());

Also remove the closing brace in next line.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18841#discussion_r1606944693

From duke at openjdk.org  Mon May 20 15:49:15 2024
From: duke at openjdk.org (duke)
Date: Mon, 20 May 2024 15:49:15 GMT
Subject: Withdrawn: 8323552: AbstractMemorySegmentImpl#mismatch returns -1 when
 comparing distinct areas of the same instance of MemorySegment
In-Reply-To: <Fy54JWTtw8GmLVAR10ks8TohjAnUOtOKP40jasGKsJc=.2724a824-5ca0-40a6-aea7-31507abd2a27@github.com>
References: <Fy54JWTtw8GmLVAR10ks8TohjAnUOtOKP40jasGKsJc=.2724a824-5ca0-40a6-aea7-31507abd2a27@github.com>
Message-ID: <lUeEiFJyOF7YDSlFIq_ebgvSLRBAorlQ-9smHOKMBM0=.688d2759-c861-4d96-889d-2c49546594c8@github.com>

On Wed, 10 Jan 2024 20:54:20 GMT, Peter Levart <plevart at openjdk.org> wrote:

> I belive there is a bug in `AbstractMemorySegmentImpl#mismatch` method. It returns `-1` (meaning that regions are equal) when passing the same instance of MemorySegment as both `srcSegment` and `dstSegment` parameters regardless of whether `srcFromOffset` and `dstFromOffset` as well as `srcToOffset` and `dstToOffset` are also equal.
> 
> Am I right?

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/17354

From duke at openjdk.org  Mon May 20 15:51:29 2024
From: duke at openjdk.org (Oussama Louati)
Date: Mon, 20 May 2024 15:51:29 GMT
Subject: RFR: 8307818: Convert Indify tool to Classfile API [v6]
In-Reply-To: <tCFk9yrCtcoBnzvNIgceY0eOaXg9ZiN9nkCuhHIyMyw=.9cc5f994-8d35-411a-bb39-7c3f2ac34dda@github.com>
References: <tCFk9yrCtcoBnzvNIgceY0eOaXg9ZiN9nkCuhHIyMyw=.9cc5f994-8d35-411a-bb39-7c3f2ac34dda@github.com>
Message-ID: <A5bl5qdBPmNr62sBeDhLMb9amNiPt0D5bx-kmH5EqaM=.5e9d0f15-649a-4357-8f4b-890cbe9f709c@github.com>

> An indify tool in j.l.i tests (also in vmTestBase) convert some source-code private static methods with MT_ MH_, and INDY_ prefixes into MethodHandle, MethodType, and CallSite constants.
> It currently uses ad-hoc code to process class files and intends to migrate to ASM; but since we have the Classfile API, we can migrate to Classfile API instead.

Oussama Louati has updated the pull request incrementally with one additional commit since the last revision:

  update: updates indify

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/18841/files
  - new: https://git.openjdk.org/jdk/pull/18841/files/f6c5bf0f..3f41a98f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18841&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18841&range=04-05

  Stats: 16 lines in 1 file changed: 0 ins; 4 del; 12 mod
  Patch: https://git.openjdk.org/jdk/pull/18841.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18841/head:pull/18841

PR: https://git.openjdk.org/jdk/pull/18841

From duke at openjdk.org  Mon May 20 16:08:28 2024
From: duke at openjdk.org (Oussama Louati)
Date: Mon, 20 May 2024 16:08:28 GMT
Subject: RFR: 8307818: Convert Indify tool to Classfile API [v7]
In-Reply-To: <tCFk9yrCtcoBnzvNIgceY0eOaXg9ZiN9nkCuhHIyMyw=.9cc5f994-8d35-411a-bb39-7c3f2ac34dda@github.com>
References: <tCFk9yrCtcoBnzvNIgceY0eOaXg9ZiN9nkCuhHIyMyw=.9cc5f994-8d35-411a-bb39-7c3f2ac34dda@github.com>
Message-ID: <kUxToQwIHKlYeoyocfXJx14GdxNZeYzhO4xFgux_Pl8=.977d60ef-e85c-43a1-8fcc-5ea4634c33e2@github.com>

> An indify tool in j.l.i tests (also in vmTestBase) convert some source-code private static methods with MT_ MH_, and INDY_ prefixes into MethodHandle, MethodType, and CallSite constants.
> It currently uses ad-hoc code to process class files and intends to migrate to ASM; but since we have the Classfile API, we can migrate to Classfile API instead.

Oussama Louati has updated the pull request incrementally with one additional commit since the last revision:

  update: updates indify

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/18841/files
  - new: https://git.openjdk.org/jdk/pull/18841/files/3f41a98f..91dbb74c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18841&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18841&range=05-06

  Stats: 80 lines in 1 file changed: 2 ins; 21 del; 57 mod
  Patch: https://git.openjdk.org/jdk/pull/18841.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18841/head:pull/18841

PR: https://git.openjdk.org/jdk/pull/18841

From joehw at openjdk.org  Mon May 20 16:29:36 2024
From: joehw at openjdk.org (Joe Wang)
Date: Mon, 20 May 2024 16:29:36 GMT
Subject: RFR: 8330542: Add jaxp-strict.properties in preparation for a
 secure by default configuration [v11]
In-Reply-To: <v1bAYKgH9zfooXpvnBw4Vu2TIqHuKqqtSmgB0hiNp-Q=.31661a99-ecfc-4a05-8045-67b5f680db60@github.com>
References: <v1bAYKgH9zfooXpvnBw4Vu2TIqHuKqqtSmgB0hiNp-Q=.31661a99-ecfc-4a05-8045-67b5f680db60@github.com>
Message-ID: <4tfHaJ1FaeY04rnf4G8Px8hZltyQxTJ_F_FYkJNuwPQ=.fbfd4253-ce53-4464-8e67-60afa018085d@github.com>

> Add two sample configuration files:
> 
>   jaxp-strict.properties: used to set strict configuration, stricter than jaxp.properties in previous versions such as JDK 22
> 
>>   jaxp-compat.properties: used to regain compatibility from any more restricted configuration than previous versions such as JDK 22
> 
> Updated on 5/16/2024
> 
> Design change:
> The design is changed to include in the JDK two configuration files that are the default jaxp.properties and jaxp-strict.properties, instead of three, dropping jaxp-compat.properties.
> 
> Updated on 5/18/2024
> 
> Withdraw changes to jaxp.properties. The original idea was to match jaxp-strict.properties with regard to the properties. However, that change impact the configuration process, resulting in tests that verify the process to fail.

Joe Wang has updated the pull request incrementally with one additional commit since the last revision:

  updated jaxp-strict; fixed typo in module-info.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/18831/files
  - new: https://git.openjdk.org/jdk/pull/18831/files/dfc965c6..55a86db3

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18831&range=10
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18831&range=09-10

  Stats: 5 lines in 2 files changed: 0 ins; 2 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/18831.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18831/head:pull/18831

PR: https://git.openjdk.org/jdk/pull/18831

From joehw at openjdk.org  Mon May 20 16:29:36 2024
From: joehw at openjdk.org (Joe Wang)
Date: Mon, 20 May 2024 16:29:36 GMT
Subject: RFR: 8330542: Add jaxp-strict.properties in preparation for a
 secure by default configuration [v10]
In-Reply-To: <zVKhkvewdkqCdBkhTDtbkTidBBYcEKVF39mMNLts1YU=.24acc158-8f6d-4591-872f-850dd8571c6c@github.com>
References: <v1bAYKgH9zfooXpvnBw4Vu2TIqHuKqqtSmgB0hiNp-Q=.31661a99-ecfc-4a05-8045-67b5f680db60@github.com>
 <Jc4tdJwAUMokA_Zm15xcJDE6FLlmWI4JTCcW3uo8gPU=.a4ffc7d1-0e3e-408a-bb65-976e5095a831@github.com>
 <zVKhkvewdkqCdBkhTDtbkTidBBYcEKVF39mMNLts1YU=.24acc158-8f6d-4591-872f-850dd8571c6c@github.com>
Message-ID: <iO37p360Jj1T-36g3ECEuep7M3Q7AkNy1klX1DqzNQo=.effd0bbf-8363-4923-9468-2f3825d3ceea@github.com>

On Mon, 20 May 2024 07:13:02 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Joe Wang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   withdraw changes to jaxp.properties. The configuration process has not changed, changing the default configuration would result in many failures that test the process.
>
> src/java.xml/share/conf/jaxp-strict.properties line 17:
> 
>> 15: #     java -Djava.xml.config.file=$JAVA_HOME/conf/jaxp-strict.properties
>> 16: #
>> 17: # The pathname to the configuration file must be valid. If it is not absolute,
> 
> I think it would be better to drop this paragraph or else just replace it with a sentence to say that the java.xml module description specifies the system property.

Thanks Alan. Replaced the paragraph with a reference to the module description.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18831#discussion_r1606993156

From joehw at openjdk.org  Mon May 20 16:32:04 2024
From: joehw at openjdk.org (Joe Wang)
Date: Mon, 20 May 2024 16:32:04 GMT
Subject: RFR: 8330542: Add jaxp-strict.properties in preparation for a
 secure by default configuration [v10]
In-Reply-To: <2mJ-7JL_PjE-BMboEkzX_Eb_hvccSdjiKyS42wM0E_A=.96b2b620-9c30-4c14-b367-f53ba929eed5@github.com>
References: <v1bAYKgH9zfooXpvnBw4Vu2TIqHuKqqtSmgB0hiNp-Q=.31661a99-ecfc-4a05-8045-67b5f680db60@github.com>
 <Jc4tdJwAUMokA_Zm15xcJDE6FLlmWI4JTCcW3uo8gPU=.a4ffc7d1-0e3e-408a-bb65-976e5095a831@github.com>
 <gXFnZ3UfC7XxCj4WcpCs0c8GVbWGR5xYTASbKNOpAxw=.ca8e2b83-2ef5-44b2-8c1d-965cfe0cfe71@github.com>
 <QwaxkRpxaO0xfYHM8hEG3F_cL-X5z2IZYdVkQ40S66M=.a9d88d20-a8b9-487c-8d67-57db41a2a973@github.com>
 <2mJ-7JL_PjE-BMboEkzX_Eb_hvccSdjiKyS42wM0E_A=.96b2b620-9c30-4c14-b367-f53ba929eed5@github.com>
Message-ID: <HyL8K_uBRPQow1xDZ1Z2MkciDaOiNgvC9ME5HuobJ8A=.af3aa4d6-496d-49c5-8853-eab05c4c1b68@github.com>

On Mon, 20 May 2024 13:03:36 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> In XML parlance, a "processor" is an aggregation of parsers, serializers, and other things that contribute to the processing. So I think it could be either here, but you have a point and if it stays as "processor" then it should link #FacPro where the term is defined.
>
> It's the wording that doesn't sound right, before this you have "making" which doesn't sound right with "process". Maybe it needs two sentences.

Thanks! Same as Alan, I thought you were talking about "processor" as well on the first glance, then realized you're referring to the parallel statements :-)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18831#discussion_r1606995925

From mcimadamore at openjdk.org  Mon May 20 16:34:02 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 20 May 2024 16:34:02 GMT
Subject: RFR: 8331865: Consolidate size and alignment checks in LayoutPath
 [v2]
In-Reply-To: <aZm4_-jMAJf-KVRewoMk9f3YHyRJhsJI5SG4PaIRzts=.9f1c56d3-3efe-4f41-8e7a-1a84b3c85cf2@github.com>
References: <CvKkdESp5-uHiuZtQvGortWnzOMV89pfjaCHNBIV4B4=.51ad0f01-2371-48af-b3c6-8a9b80518cdb@github.com>
 <sbhzMEtBjBJuxpO_JdNI4tCiTZwCG8WNBXR5_G2TVXo=.1726357f-4f88-46dc-aaa6-b773df9292df@github.com>
 <ye_axgXODi_M-1C14h-O3Ez0ICuenTZyprTuJ1quZaM=.992dd1fd-4526-4d31-a4b3-f06e18c9cca0@github.com>
 <aZm4_-jMAJf-KVRewoMk9f3YHyRJhsJI5SG4PaIRzts=.9f1c56d3-3efe-4f41-8e7a-1a84b3c85cf2@github.com>
Message-ID: <lc1pXuirhs0JSmK0xR4DiRSRPs7FnevHrvvNE6x6lsM=.7a71b741-36c3-4331-bad9-f53d9eb7ea91@github.com>

On Mon, 20 May 2024 09:45:31 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> > Separately, we might be missing a few long argument accepting guard methods for simpler cases as I suspect they are still focused more on int index types.
> 
> Not sure I understand what guard methods you are referring to here?

Ah, got it. You mean more support in VarHandleGuards. Yes, I have a separate patch for that (actually had that for quite a while), but we're not super sure how to evaluate what impact it has :-)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19251#issuecomment-2120796446

From psandoz at openjdk.org  Mon May 20 16:45:02 2024
From: psandoz at openjdk.org (Paul Sandoz)
Date: Mon, 20 May 2024 16:45:02 GMT
Subject: RFR: 8331865: Consolidate size and alignment checks in LayoutPath
 [v2]
In-Reply-To: <lc1pXuirhs0JSmK0xR4DiRSRPs7FnevHrvvNE6x6lsM=.7a71b741-36c3-4331-bad9-f53d9eb7ea91@github.com>
References: <CvKkdESp5-uHiuZtQvGortWnzOMV89pfjaCHNBIV4B4=.51ad0f01-2371-48af-b3c6-8a9b80518cdb@github.com>
 <sbhzMEtBjBJuxpO_JdNI4tCiTZwCG8WNBXR5_G2TVXo=.1726357f-4f88-46dc-aaa6-b773df9292df@github.com>
 <ye_axgXODi_M-1C14h-O3Ez0ICuenTZyprTuJ1quZaM=.992dd1fd-4526-4d31-a4b3-f06e18c9cca0@github.com>
 <aZm4_-jMAJf-KVRewoMk9f3YHyRJhsJI5SG4PaIRzts=.9f1c56d3-3efe-4f41-8e7a-1a84b3c85cf2@github.com>
 <lc1pXuirhs0JSmK0xR4DiRSRPs7FnevHrvvNE6x6lsM=.7a71b741-36c3-4331-bad9-f53d9eb7ea91@github.com>
Message-ID: <JIHrCu4KuGr-wbGt26xx-GAKQir_7jYpTLii8IZe-74=.750a4a3a-5217-4296-82e6-1fc85aeda7aa@github.com>

On Mon, 20 May 2024 16:31:18 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> 
> Ah, got it. You mean more support in VarHandleGuards. Yes, I have a separate patch for that (actually had that for quite a while), but we're not super sure how to evaluate what impact it has :-)

Ah, i did not realize that. Yes its tricky, it was designed for VHs to fields/arrays, to really minimize their overhead. With segments there is already some additional overhead e.g.,

        if (derefAdapters.length == 0) {
            // insert align check for the root layout on the initial MS + offset
            List<Class<?>> coordinateTypes = handle.coordinateTypes();
            MethodHandle alignCheck = MethodHandles.insertArguments(MH_CHECK_ENCL_LAYOUT, 2, rootLayout());
            handle = MethodHandles.collectCoordinates(handle, 0, alignCheck);
            int[] reorder = IntStream.concat(IntStream.of(0, 1), IntStream.range(0, coordinateTypes.size())).toArray();
            handle = MethodHandles.permuteCoordinates(handle, coordinateTypes, reorder);
        }

So perhaps it does not make much difference.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19251#issuecomment-2120813942

From iklam at openjdk.org  Mon May 20 17:24:22 2024
From: iklam at openjdk.org (Ioi Lam)
Date: Mon, 20 May 2024 17:24:22 GMT
Subject: RFR: 8332340: Add JavacBench as a test case for CDS [v3]
In-Reply-To: <xqD4PeVZfIAKzywbLnjGZMFh36YSqXNolZkTgh1Vk6E=.44db7c57-64c1-4912-96e1-e61848312ccb@github.com>
References: <xqD4PeVZfIAKzywbLnjGZMFh36YSqXNolZkTgh1Vk6E=.44db7c57-64c1-4912-96e1-e61848312ccb@github.com>
Message-ID: <JyXZjtHrBwxBbYTgyKfne732jbC7gCNzwgPDKWHAxAQ=.3b8e48bb-3bfa-4b85-88d4-65cee20a5cec@github.com>

> JavacBench is a test program that compiles 90 Java source files. It uses a fair amount of invokedynamic callsites, so it's good for testing CDS support for indy and lambda expressions.
> 
> This test was first integrated into the [leyden](https://github.com/openjdk/leyden/tree/premain) repo. Hence some of the files have copyrights in 2023.

Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:

  @calvinccheung comments

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19256/files
  - new: https://git.openjdk.org/jdk/pull/19256/files/354665a3..ad97efa1

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19256&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19256&range=01-02

  Stats: 14 lines in 3 files changed: 5 ins; 6 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/19256.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19256/head:pull/19256

PR: https://git.openjdk.org/jdk/pull/19256

From iklam at openjdk.org  Mon May 20 17:24:22 2024
From: iklam at openjdk.org (Ioi Lam)
Date: Mon, 20 May 2024 17:24:22 GMT
Subject: RFR: 8332340: Add JavacBench as a test case for CDS [v2]
In-Reply-To: <uHz0meNJLwDh09AJIl2LjOw_1OxU3h6Fk2sQCGXMmIE=.6c16cc02-4cac-4701-9b74-90301f9281a2@github.com>
References: <xqD4PeVZfIAKzywbLnjGZMFh36YSqXNolZkTgh1Vk6E=.44db7c57-64c1-4912-96e1-e61848312ccb@github.com>
 <kynGbPSKJOGvy0iND0ZEL42700j2gKku8A8IM1pAfwQ=.5dc84470-1b24-4568-8cd8-328221103e59@github.com>
 <uHz0meNJLwDh09AJIl2LjOw_1OxU3h6Fk2sQCGXMmIE=.6c16cc02-4cac-4701-9b74-90301f9281a2@github.com>
Message-ID: <duv2JAI5XaYkpjSFfG-_yvsCzf0SkqISv7w88i7YZM8=.6697ea17-94e4-4a49-8101-cdf219683e86@github.com>

On Fri, 17 May 2024 19:45:00 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:

>> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   (1) comments from @liach; (2) added javadoc; (3) Use createTestJavaProcessBuilder() instead of createLimitedTestJavaProcessBuilder()
>
> test/hotspot/jtreg/runtime/cds/appcds/applications/JavacBench.java line 2:
> 
>> 1: /*
>> 2:  * Copyright (c) 2023, 2024, Oracle and/or its affiliates. All rights reserved.
> 
> Since this is a new file, should the copyright year be only 2024?
> (same for other files)

The file was first added in the Leyden repo in 2023, so I think we should use that as the initial copyright year.

> test/hotspot/jtreg/runtime/cds/appcds/applications/JavacBench.java line 43:
> 
>> 41: import jdk.test.lib.cds.CDSAppTester;
>> 42: import jdk.test.lib.helpers.ClassFileInstaller;
>> 43: import jdk.test.lib.process.OutputAnalyzer;
> 
> Is this import needed?

Removed.

> test/hotspot/jtreg/runtime/cds/appcds/applications/JavacBenchApp.java line 222:
> 
>> 220:         }
>> 221:         long elapsed = System.currentTimeMillis() - started;
>> 222:         if (System.getProperty("JavacBenchApp.silent") == null) {
> 
> Should line 221 be inside the 'if' block?

I moved it inside the 'if' block.

> test/lib/jdk/test/lib/cds/CDSAppTester.java line 218:
> 
>> 216:         }
>> 217: 
>> 218:         throw new RuntimeException("Must have exactly one command line argument: STATIC or DYNAMIC");
> 
> Why not check the number of args at the beginning of the method?

Fixed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19256#discussion_r1607047769
PR Review Comment: https://git.openjdk.org/jdk/pull/19256#discussion_r1607047882
PR Review Comment: https://git.openjdk.org/jdk/pull/19256#discussion_r1607047859
PR Review Comment: https://git.openjdk.org/jdk/pull/19256#discussion_r1607047805

From naoto at openjdk.org  Mon May 20 17:49:29 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 20 May 2024 17:49:29 GMT
Subject: RFR: 8332084: Ensure JdkConsoleImpl.restoreEcho visibility in a
 shutdown hook [v7]
In-Reply-To: <9JTWc3FRpfbILlSHlmIU_dL5IE69RTxnSIAOdIte15I=.5854a48f-21d7-42c9-adb7-5e3ed40d1211@github.com>
References: <9JTWc3FRpfbILlSHlmIU_dL5IE69RTxnSIAOdIte15I=.5854a48f-21d7-42c9-adb7-5e3ed40d1211@github.com>
Message-ID: <SUFrRXJbSbs5MQHMcU0QJmGLI2fmNW0GkjpqzzTJoXo=.01323fc3-02ac-4a44-b4eb-d4697c5e336c@github.com>

> Making sure `restoreEcho` correctly reflects the state in the shutdown thread, which differs from the application's thread that issues the `readPassword()` method.

Naoto Sato 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-8332084-restoreEcho-readLock
 - Merge branch 'master' into JDK-8332084-restoreEcho-readLock
 - copyright year
 - Merge branch 'master' into JDK-8332084-restoreEcho-readLock
 - get/setEcho()
 - Addresses a review comment
 - Replaced another unused exception with _
 - Update src/java.base/share/classes/jdk/internal/io/JdkConsoleImpl.java
   
   Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com>
 - initial commit

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19184/files
  - new: https://git.openjdk.org/jdk/pull/19184/files/82d30b3b..e58fbdcd

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19184&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19184&range=05-06

  Stats: 41521 lines in 532 files changed: 34514 ins; 5047 del; 1960 mod
  Patch: https://git.openjdk.org/jdk/pull/19184.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19184/head:pull/19184

PR: https://git.openjdk.org/jdk/pull/19184

From naoto at openjdk.org  Mon May 20 18:13:17 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 20 May 2024 18:13:17 GMT
Subject: RFR: 8332161: Need a test for restoring echo in the Console
 implementation (java.base)
Message-ID: <aSxuvnY7ghWwuDuegcWKJKlL_3KUCdIS_jHgTsn43ow=.b4d2e8d9-ffea-4318-9004-27b18298436e@github.com>

This test intends to verify the behavior of JdkConsole for the java.base module, wrt restoring the echo. The test assumes the internal methods that sets/gets the echo status of the platform.

-------------

Depends on: https://git.openjdk.org/jdk/pull/19184

Commit messages:
 - initial commit

Changes: https://git.openjdk.org/jdk/pull/19315/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19315&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8332161
  Stats: 196 lines in 2 files changed: 196 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/19315.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19315/head:pull/19315

PR: https://git.openjdk.org/jdk/pull/19315

From mcimadamore at openjdk.org  Mon May 20 18:29:02 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 20 May 2024 18:29:02 GMT
Subject: RFR: 8331865: Consolidate size and alignment checks in LayoutPath
 [v2]
In-Reply-To: <JIHrCu4KuGr-wbGt26xx-GAKQir_7jYpTLii8IZe-74=.750a4a3a-5217-4296-82e6-1fc85aeda7aa@github.com>
References: <CvKkdESp5-uHiuZtQvGortWnzOMV89pfjaCHNBIV4B4=.51ad0f01-2371-48af-b3c6-8a9b80518cdb@github.com>
 <sbhzMEtBjBJuxpO_JdNI4tCiTZwCG8WNBXR5_G2TVXo=.1726357f-4f88-46dc-aaa6-b773df9292df@github.com>
 <ye_axgXODi_M-1C14h-O3Ez0ICuenTZyprTuJ1quZaM=.992dd1fd-4526-4d31-a4b3-f06e18c9cca0@github.com>
 <aZm4_-jMAJf-KVRewoMk9f3YHyRJhsJI5SG4PaIRzts=.9f1c56d3-3efe-4f41-8e7a-1a84b3c85cf2@github.com>
 <lc1pXuirhs0JSmK0xR4DiRSRPs7FnevHrvvNE6x6lsM=.7a71b741-36c3-4331-bad9-f53d9eb7ea91@github.com>
 <JIHrCu4KuGr-wbGt26xx-GAKQir_7jYpTLii8IZe-74=.750a4a3a-5217-4296-82e6-1fc85aeda7aa@github.com>
Message-ID: <Ea23JDGRZ0aU3fpyhNJqEj84Go4bZ3tk1ZsT3StgE4o=.7441c077-ce8c-4ed2-a9e4-06c50576d427@github.com>

On Mon, 20 May 2024 16:42:19 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

> some additional overhead e.g.,
> 
> ```
>         if (derefAdapters.length == 0) {
>             // insert align check for the root layout on the initial MS + offset
>             List<Class<?>> coordinateTypes = handle.coordinateTypes();
>             MethodHandle alignCheck = MethodHandles.insertArguments(MH_CHECK_ENCL_LAYOUT, 2, rootLayout());
>             handle = MethodHandles.collectCoordinates(handle, 0, alignCheck);
>             int[] reorder = IntStream.concat(IntStream.of(0, 1), IntStream.range(0, coordinateTypes.size())).toArray();
>             handle = MethodHandles.permuteCoordinates(handle, coordinateTypes, reorder);
>         }
> ```

True, the chain for segment var handle is quite long (and that is not a result of this patch, it has always been more or less like that). Funnily, I was staring at this piece of code the other day, and I think this can be dealt with morally with a `foldArguments`, but we don't have the equivalent of that in the VH/coordinates world. Maybe we should add that (or at least implement internally) as that would simplify the adaptation, avoiding the permute step (which is typically rather heavy).

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19251#issuecomment-2120979087

From prr at openjdk.org  Mon May 20 18:50:06 2024
From: prr at openjdk.org (Phil Race)
Date: Mon, 20 May 2024 18:50:06 GMT
Subject: RFR: 8331671: Implement JEP 472: Prepare to Restrict the Use of
 JNI [v8]
In-Reply-To: <vtwexqsEt4uFH-ObgWjYt9JgicYmXDGw0YaaOFcvkVM=.2a854073-e034-4c7e-b5f9-8ffa5f97d320@github.com>
References: <CZGbki5iFdCGPPagE-ya-_L8Nkgf7OunywApOsxC548=.2cee82fa-a5d2-4165-b012-30982a85030a@github.com>
 <vtwexqsEt4uFH-ObgWjYt9JgicYmXDGw0YaaOFcvkVM=.2a854073-e034-4c7e-b5f9-8ffa5f97d320@github.com>
Message-ID: <-eahuR7pahX1Zuu-n4btdItPet2ZOE8fX1qYl6sn2s4=.c37ac0ad-bf97-4778-8c8b-c137390c7e14@github.com>

On Mon, 13 May 2024 10:49:30 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Address review comments
>
> make/conf/module-loader-map.conf line 105:
> 
>> 103:     java.smartcardio \
>> 104:     jdk.accessibility \
>> 105:     jdk.attach \
> 
> The list of allowed modules has been rewritten from scratch, by looking at the set of modules containing at least one `native` method declaration.

Should I understand this list to be the set of modules exempt from needing to specific that native access is allowed ?
ie they always have native access without any warnings, and further that any attempt to enable warnings, or to disable native access for these modules is ignored ?

> src/java.desktop/macosx/classes/com/apple/eio/FileManager.java line 61:
> 
>> 59:     }
>> 60: 
>> 61:     @SuppressWarnings({"removal", "restricted"})
> 
> There are several of these changes. One option might have been to just disable restricted warnings when building. But on a deeper look, I realized that in all these places we already disabled deprecation warnings for the use of security manager, so I also added a new suppression instead.

Sounds reasonable.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19213#discussion_r1607136237
PR Review Comment: https://git.openjdk.org/jdk/pull/19213#discussion_r1607136808

From prr at openjdk.org  Mon May 20 18:50:04 2024
From: prr at openjdk.org (Phil Race)
Date: Mon, 20 May 2024 18:50:04 GMT
Subject: RFR: 8331671: Implement JEP 472: Prepare to Restrict the Use of
 JNI [v8]
In-Reply-To: <vWr2PdgTv6vEllxW8820KO3aZ3tR3xvMhCxD2k7QpS0=.8bfd6c47-6c93-4fc3-aced-7079889aa6a2@github.com>
References: <CZGbki5iFdCGPPagE-ya-_L8Nkgf7OunywApOsxC548=.2cee82fa-a5d2-4165-b012-30982a85030a@github.com>
 <vWr2PdgTv6vEllxW8820KO3aZ3tR3xvMhCxD2k7QpS0=.8bfd6c47-6c93-4fc3-aced-7079889aa6a2@github.com>
Message-ID: <GP3trJu5GXEMpyixYDMatIGiwQ6V3L-d8UI6wRgmutQ=.3a3c2d44-bd4d-4ab3-a41d-08a4254c6c21@github.com>

On Fri, 17 May 2024 13:38:25 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This PR implements [JEP 472](https://openjdk.org/jeps/472), by restricting the use of JNI in the following ways:
>> 
>> * `System::load` and `System::loadLibrary` are now restricted methods
>> * `Runtime::load` and `Runtime::loadLibrary` are now restricted methods
>> * binding a JNI `native` method declaration to a native implementation is now considered a restricted operation
>> 
>> This PR slightly changes the way in which the JDK deals with restricted methods, even for FFM API calls. In Java 22, the single `--enable-native-access` was used both to specify a set of modules for which native access should be allowed *and* to specify whether illegal native access (that is, native access occurring from a module not specified by `--enable-native-access`) should be treated as an error or a warning. More specifically, an error is only issued if the `--enable-native-access flag` is used at least once.
>> 
>> Here, a new flag is introduced, namely `illegal-native-access=allow/warn/deny`, which is used to specify what should happen when access to a restricted method and/or functionality is found outside the set of modules specified with `--enable-native-access`. The default policy is `warn`, but users can select `allow` to suppress the warnings, or `deny` to cause `IllegalCallerException` to be thrown. This aligns the treatment of restricted methods with other mechanisms, such as `--illegal-access` and the more recent `--sun-misc-unsafe-memory-access`.
>> 
>> Some changes were required in the package-info javadoc for `java.lang.foreign`, to reflect the changes in the command line flags described above.
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address review comments

Have you looked into / thought about how this will work for jpackaged apps ?
I suspect that both the existing FFM usage and this will be options the application packager will need to supply when building the jpackaged app - the end user cannot pass in command line VM options.
Seems there should be some testing of this as some kind of native access could be a common case for jpackaged apps.

-------------

PR Review: https://git.openjdk.org/jdk/pull/19213#pullrequestreview-2066794950

From alanb at openjdk.org  Mon May 20 18:54:05 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 20 May 2024 18:54:05 GMT
Subject: RFR: 8331671: Implement JEP 472: Prepare to Restrict the Use of
 JNI [v8]
In-Reply-To: <-eahuR7pahX1Zuu-n4btdItPet2ZOE8fX1qYl6sn2s4=.c37ac0ad-bf97-4778-8c8b-c137390c7e14@github.com>
References: <CZGbki5iFdCGPPagE-ya-_L8Nkgf7OunywApOsxC548=.2cee82fa-a5d2-4165-b012-30982a85030a@github.com>
 <vtwexqsEt4uFH-ObgWjYt9JgicYmXDGw0YaaOFcvkVM=.2a854073-e034-4c7e-b5f9-8ffa5f97d320@github.com>
 <-eahuR7pahX1Zuu-n4btdItPet2ZOE8fX1qYl6sn2s4=.c37ac0ad-bf97-4778-8c8b-c137390c7e14@github.com>
Message-ID: <nFi5XR2qKdd2WstJE4gWSS3UGpk7uOvK4Gn7x0wArIs=.8e22fd11-0e2d-4328-81eb-81bf129ea65d@github.com>

On Mon, 20 May 2024 18:39:31 GMT, Phil Race <prr at openjdk.org> wrote:

>> make/conf/module-loader-map.conf line 105:
>> 
>>> 103:     java.smartcardio \
>>> 104:     jdk.accessibility \
>>> 105:     jdk.attach \
>> 
>> The list of allowed modules has been rewritten from scratch, by looking at the set of modules containing at least one `native` method declaration.
>
> Should I understand this list to be the set of modules exempt from needing to specific that native access is allowed ?
> ie they always have native access without any warnings, and further that any attempt to enable warnings, or to disable native access for these modules is ignored ?

Yes, this was added via JDK-8327218. The changes in this PR are just trimming down the list to only the modules that have native code.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19213#discussion_r1607147983

From vklang at openjdk.org  Mon May 20 18:55:08 2024
From: vklang at openjdk.org (Viktor Klang)
Date: Mon, 20 May 2024 18:55:08 GMT
Subject: Integrated: 8332154: Memory leak in SynchronousQueue
In-Reply-To: <Fj3W5LlneHODz3PcBD0Ypu2f34UYvxw1iLLKz5pba-I=.0f419338-0a23-4834-8404-55aeab4b813f@github.com>
References: <Fj3W5LlneHODz3PcBD0Ypu2f34UYvxw1iLLKz5pba-I=.0f419338-0a23-4834-8404-55aeab4b813f@github.com>
Message-ID: <ryQ2FdtvVaNXg6opwzKT0rJGzehoez-dwUJa-pn5WyY=.6f9ce9a8-4bea-45a9-9d9c-83441da005ec@github.com>

On Thu, 16 May 2024 14:54:52 GMT, Viktor Klang <vklang at openjdk.org> wrote:

> Local testing seems to indicate that this fix (which mirrors what's done in the FIFO mode) addresses the problem. Regression test added for JDK20+

This pull request has now been integrated.

Changeset: b78613b6
Author:    Viktor Klang <vklang at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/b78613b6813a85662fb2af2004d0b68002fe471d
Stats:     99 lines in 4 files changed: 98 ins; 1 del; 0 mod

8332154: Memory leak in SynchronousQueue

Reviewed-by: alanb

-------------

PR: https://git.openjdk.org/jdk/pull/19271

From psandoz at openjdk.org  Mon May 20 19:13:01 2024
From: psandoz at openjdk.org (Paul Sandoz)
Date: Mon, 20 May 2024 19:13:01 GMT
Subject: RFR: 8332486: ClassFile API ArrayIndexOutOfBoundsException with
 label metadata
In-Reply-To: <AnO18xDHzgdxAcLcsQLVdNUdMKyqEs2jQl-2YQGbnWA=.ae8dc1dd-a6c2-4223-be09-b823c92c9b87@github.com>
References: <AnO18xDHzgdxAcLcsQLVdNUdMKyqEs2jQl-2YQGbnWA=.ae8dc1dd-a6c2-4223-be09-b823c92c9b87@github.com>
Message-ID: <85sehySKixgLHVLk_k_kJ1TV_MiKEAbAPBD1gzczhT0=.888a5803-91f0-4687-a202-9844c6f05785@github.com>

On Mon, 20 May 2024 08:37:49 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> Parsing of a specifically corrupted class file cause unexpected `ArrayIndexOutOfBoundsException` during label inflation.
> This patch checks the valid range and throws expected `IllegalArgumentException` instead.
> Relevant test is added.
> 
> Please review.
> 
> Thanks,
> Adam

Marked as reviewed by psandoz (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/19304#pullrequestreview-2066846853

From psandoz at openjdk.org  Mon May 20 19:24:00 2024
From: psandoz at openjdk.org (Paul Sandoz)
Date: Mon, 20 May 2024 19:24:00 GMT
Subject: RFR: 8331196: vector api: Remove unnecessary index check in
 Byte/ShortVector.fromArray/fromArray0Template
In-Reply-To: <YLwvFU3XpoutOZCBehEbDwlkkucrAbHv1mF8K9zzDH0=.b49d1661-adac-4a96-b013-84f1b4dd7fcf@github.com>
References: <YLwvFU3XpoutOZCBehEbDwlkkucrAbHv1mF8K9zzDH0=.b49d1661-adac-4a96-b013-84f1b4dd7fcf@github.com>
Message-ID: <NpbcAc45Uw1LVGtv_LxGR5UIQ0DjL_Smvc3a99bonf8=.6814098e-bb3b-4381-9bc6-11838dae2eba@github.com>

On Fri, 26 Apr 2024 14:06:02 GMT, Hamlin Li <mli at openjdk.org> wrote:

> Hi,
> Can you help to review this simple patch?
> Some index check in Byte/ShortVector.fromArray/fromArray0Template seems not necessary, could be removed.
> Thanks

That does not look correct and will only check a prefix indexes. A `ByteVector` with a shape of 256 bits has 32 lanes, whereas an `IntVector` of the same shape has 8 lanes. The `mapOffset` array will hold 32 indexes that need checking, so we need to loop through `mapOffset` array four times.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18977#issuecomment-2121057883

From redestad at openjdk.org  Mon May 20 20:55:30 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Mon, 20 May 2024 20:55:30 GMT
Subject: RFR: 8332528: Generate code in SwitchBootstraps.generateTypeSwitch
 that require fewer adaptations
Message-ID: <wHUtsMWzEaVwNwDuQJAyrUJrpDkcQpXxb6i5KA7J_Bw=.17b2f7d2-2c8c-42e7-9c90-2bf9f5901f26@github.com>

We can fold the call to `Objects.checkIndex` into the code generated in generateTypeSwitchSkeleton instead of doing so by filtering the MH argument. This loads 9 less classes (of which 8 generated LFs and Species classes) on a minimal test, while being neutral on a throughput sanity test:


Name                   Cnt  Base   Error   Test   Error  Unit  Change
SwitchSanity.switchSum  15 8,162 ? 0,117  8,152 ? 0,131 ns/op   1,00x (p = 0,800 )
  * = significant
  ```

A few additional optimizations includes generating the switch method using the precise type (to avoid the need for an explicitCast adaptation), and moving some seldom used `findStatic` calls to a holder. All in all this means a reduction by 33-34M cycles to bootstrap a trivial switch expression on my M1.

-------------

Commit messages:
 - Remove explicitCastArguments and refactor
 - Move rarely used findStatics to Holder class
 - Drive-by desugaring
 - Move Objects.checkIndex call to code generated by generateTypeSwitch

Changes: https://git.openjdk.org/jdk/pull/19307/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19307&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8332528
  Stats: 157 lines in 4 files changed: 113 ins; 18 del; 26 mod
  Patch: https://git.openjdk.org/jdk/pull/19307.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19307/head:pull/19307

PR: https://git.openjdk.org/jdk/pull/19307

From redestad at openjdk.org  Mon May 20 20:55:30 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Mon, 20 May 2024 20:55:30 GMT
Subject: RFR: 8332528: Generate code in SwitchBootstraps.generateTypeSwitch
 that require fewer adaptations
In-Reply-To: <wHUtsMWzEaVwNwDuQJAyrUJrpDkcQpXxb6i5KA7J_Bw=.17b2f7d2-2c8c-42e7-9c90-2bf9f5901f26@github.com>
References: <wHUtsMWzEaVwNwDuQJAyrUJrpDkcQpXxb6i5KA7J_Bw=.17b2f7d2-2c8c-42e7-9c90-2bf9f5901f26@github.com>
Message-ID: <hB7ZStbILwDaM4vRmc8lRiPRoAjHtCRQYdKSpxTczBQ=.e06703b2-e0d4-4420-b7f7-01d4f7a3cd03@github.com>

On Mon, 20 May 2024 10:52:27 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> We can fold the call to `Objects.checkIndex` into the code generated in generateTypeSwitchSkeleton instead of doing so by filtering the MH argument. This loads 9 less classes (of which 8 generated LFs and Species classes) on a minimal test, while being neutral on a throughput sanity test:
> 
> 
> Name                   Cnt  Base   Error   Test   Error  Unit  Change
> SwitchSanity.switchSum  15 8,162 ? 0,117  8,152 ? 0,131 ns/op   1,00x (p = 0,800 )
>   * = significant
>   ```
> 
> A few additional optimizations includes generating the switch method using the precise type (to avoid the need for an explicitCast adaptation), and moving some seldom used `findStatic` calls to a holder. All in all this means a reduction by 33-34M cycles to bootstrap a trivial switch expression on my M1.

To help evaluate and diagnose the startup overheads I added a `main` method to the provided `SwitchSanity` micro. This only runs a single invocation and is easy to run using your startup benchmarking script/tool of choice:


Name             Cnt          Base         Error           Test         Error         Unit  Change
Perfstartup-JMH   20        75,000 ?       4,455         62,000 ?       6,042        ms/op   1,21x (p = 0,000*)
  :.cycles           277393501,850 ? 4422757,249  253819501,350 ? 5482340,325       cycles   0,92x (p = 0,000*)
  :.instructions     701618995,500 ? 3774721,992  622929549,250 ? 3634060,803 instructions   0,89x (p = 0,000*)
  :.taskclock               82,000 ?       3,564         74,000 ?       4,365           ms   0,90x (p = 0,000*)
  * = significant

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19307#issuecomment-2121179185

From liach at openjdk.org  Mon May 20 20:55:31 2024
From: liach at openjdk.org (Chen Liang)
Date: Mon, 20 May 2024 20:55:31 GMT
Subject: RFR: 8332528: Generate code in SwitchBootstraps.generateTypeSwitch
 that require fewer adaptations
In-Reply-To: <wHUtsMWzEaVwNwDuQJAyrUJrpDkcQpXxb6i5KA7J_Bw=.17b2f7d2-2c8c-42e7-9c90-2bf9f5901f26@github.com>
References: <wHUtsMWzEaVwNwDuQJAyrUJrpDkcQpXxb6i5KA7J_Bw=.17b2f7d2-2c8c-42e7-9c90-2bf9f5901f26@github.com>
Message-ID: <APFd-p8KM0rySjWTw2GmTv5oTs2OECy5UawmOTxzofc=.e96ee439-dde6-45fe-9ab4-c25a552b725b@github.com>

On Mon, 20 May 2024 10:52:27 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> We can fold the call to `Objects.checkIndex` into the code generated in generateTypeSwitchSkeleton instead of doing so by filtering the MH argument. This loads 9 less classes (of which 8 generated LFs and Species classes) on a minimal test, while being neutral on a throughput sanity test:
> 
> 
> Name                   Cnt  Base   Error   Test   Error  Unit  Change
> SwitchSanity.switchSum  15 8,162 ? 0,117  8,152 ? 0,131 ns/op   1,00x (p = 0,800 )
>   * = significant
>   ```
> 
> A few additional optimizations includes generating the switch method using the precise type (to avoid the need for an explicitCast adaptation), and moving some seldom used `findStatic` calls to a holder. All in all this means a reduction by 33-34M cycles to bootstrap a trivial switch expression on my M1.

src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java line 406:

> 404:             cb.iload(RESTART_IDX);
> 405:             cb.loadConstant(labelConstants.length + 1);
> 406:             cb.invokestatic(CD_Objects, "checkIndex", MethodTypeDesc.of(ConstantDescs.CD_int, ConstantDescs.CD_int, ConstantDescs.CD_int));

We should cache this MethodTypeDesc too.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19307#discussion_r1607097291

From duke at openjdk.org  Mon May 20 20:56:18 2024
From: duke at openjdk.org (Oussama Louati)
Date: Mon, 20 May 2024 20:56:18 GMT
Subject: RFR: 8307818: Convert Indify tool to Classfile API [v8]
In-Reply-To: <tCFk9yrCtcoBnzvNIgceY0eOaXg9ZiN9nkCuhHIyMyw=.9cc5f994-8d35-411a-bb39-7c3f2ac34dda@github.com>
References: <tCFk9yrCtcoBnzvNIgceY0eOaXg9ZiN9nkCuhHIyMyw=.9cc5f994-8d35-411a-bb39-7c3f2ac34dda@github.com>
Message-ID: <NkLMH9NX2o1zUUPbEdp_jGq-E8V3inBRBnadM9Z-_qU=.cf443418-a3a6-41fc-acfc-8a3de241c747@github.com>

> An indify tool in j.l.i tests (also in vmTestBase) convert some source-code private static methods with MT_ MH_, and INDY_ prefixes into MethodHandle, MethodType, and CallSite constants.
> It currently uses ad-hoc code to process class files and intends to migrate to ASM; but since we have the Classfile API, we can migrate to Classfile API instead.

Oussama Louati has updated the pull request incrementally with one additional commit since the last revision:

  update: Added javadoc documentation

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/18841/files
  - new: https://git.openjdk.org/jdk/pull/18841/files/91dbb74c..781c951d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18841&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18841&range=06-07

  Stats: 27 lines in 1 file changed: 26 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/18841.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18841/head:pull/18841

PR: https://git.openjdk.org/jdk/pull/18841

From redestad at openjdk.org  Mon May 20 20:55:31 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Mon, 20 May 2024 20:55:31 GMT
Subject: RFR: 8332528: Generate code in SwitchBootstraps.generateTypeSwitch
 that require fewer adaptations
In-Reply-To: <APFd-p8KM0rySjWTw2GmTv5oTs2OECy5UawmOTxzofc=.e96ee439-dde6-45fe-9ab4-c25a552b725b@github.com>
References: <wHUtsMWzEaVwNwDuQJAyrUJrpDkcQpXxb6i5KA7J_Bw=.17b2f7d2-2c8c-42e7-9c90-2bf9f5901f26@github.com>
 <APFd-p8KM0rySjWTw2GmTv5oTs2OECy5UawmOTxzofc=.e96ee439-dde6-45fe-9ab4-c25a552b725b@github.com>
Message-ID: <qGBAuEpFF3EDSZfwgshNnnKO0e1hNWMQwa78GhZGmXk=.b8f9ea63-10ca-45de-b1b3-94926e4c8158@github.com>

On Mon, 20 May 2024 18:06:32 GMT, Chen Liang <liach at openjdk.org> wrote:

>> We can fold the call to `Objects.checkIndex` into the code generated in generateTypeSwitchSkeleton instead of doing so by filtering the MH argument. This loads 9 less classes (of which 8 generated LFs and Species classes) on a minimal test, while being neutral on a throughput sanity test:
>> 
>> 
>> Name                   Cnt  Base   Error   Test   Error  Unit  Change
>> SwitchSanity.switchSum  15 8,162 ? 0,117  8,152 ? 0,131 ns/op   1,00x (p = 0,800 )
>>   * = significant
>>   ```
>> 
>> A few additional optimizations includes generating the switch method using the precise type (to avoid the need for an explicitCast adaptation), and moving some seldom used `findStatic` calls to a holder. All in all this means a reduction by 33-34M cycles to bootstrap a trivial switch expression on my M1.
>
> src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java line 406:
> 
>> 404:             cb.iload(RESTART_IDX);
>> 405:             cb.loadConstant(labelConstants.length + 1);
>> 406:             cb.invokestatic(CD_Objects, "checkIndex", MethodTypeDesc.of(ConstantDescs.CD_int, ConstantDescs.CD_int, ConstantDescs.CD_int));
> 
> We should cache this MethodTypeDesc too.

`MethodTypeDesc.of` is actually quite cheap when inputs are `ClassDesc`s. Besides I think the main focus in these bootstraps should be improving the overhead of the first few calls - reduce dependencies, reduce runtime code generation - not treat this code as something that will be run many times over in a hot loop.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19307#discussion_r1607207823

From vlivanov at openjdk.org  Mon May 20 22:00:26 2024
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Mon, 20 May 2024 22:00:26 GMT
Subject: RFR: 8332547: Unloaded signature classes in DirectMethodHandles
Message-ID: <LAJeY7XRSMrz6Sg6TeIOkqZm1uRJbIxhP_PcZdI13JQ=.5790e229-84fd-4282-9769-6613dbb3254a@github.com>

JVM routinely installs loader constraints for unloaded signature classes when method resolution takes place. MethodHandle resolution took a different route and eagerly resolves signature classes instead (see `java.lang.invoke.MemberName$Factory::resolve` and `sun.invoke.util.VerifyAccess::isTypeVisible` for details). 

There's a micro-optimization which bypasses eager resolution for `java.*` classes. The downside is that `java.*` signature classes can show up as unloaded. It manifests as inlining failures during JIT-compilation and may cause severe performance issues.

Proposed fix removes the aforementioned special case logic during `MethodHandle` resolution. 

In some cases it may slow down `MethodHandle` construction a bit (e.g., when repeatedly constructing `DirectMethodHandle`s with lots of arguments), but `MethodHandle` construction step is not performance critical.  

Testing: hs-tier1 - hs-tier4

-------------

Commit messages:
 - Fix
 - Test

Changes: https://git.openjdk.org/jdk/pull/19319/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19319&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8332547
  Stats: 74 lines in 2 files changed: 68 ins; 0 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/19319.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19319/head:pull/19319

PR: https://git.openjdk.org/jdk/pull/19319

From darcy at openjdk.org  Mon May 20 22:42:20 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Mon, 20 May 2024 22:42:20 GMT
Subject: RFR: 8330182: Start of release updates for JDK 24 [v5]
In-Reply-To: <YKsEQWuI-vNTEDjOBInuEjf8AEcTL4QZ_F4JYUqoxwk=.5ed43782-6dec-4383-948d-d9966a85b3bf@github.com>
References: <YKsEQWuI-vNTEDjOBInuEjf8AEcTL4QZ_F4JYUqoxwk=.5ed43782-6dec-4383-948d-d9966a85b3bf@github.com>
Message-ID: <YiULppeKgO2y0ANcaUNoqLC_ErnFEoMeBjuLtaHb0iM=.aa9a9262-06ec-48e0-9e2c-ce5533f5d546@github.com>

> Get JDK 24 underway.

Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 11 commits:

 - Fix-up test.
 - Merge branch 'master' into JDK-8330188
 - Adjust test for deprecated options.
 - Merge branch 'master' into JDK-8330188
 - Update deprecated options test.
 - Merge branch 'master' into JDK-8330188
 - Merge branch 'master' into JDK-8330188
 - Merge branch 'master' into JDK-8330188
 - Correct release date as observed in review feedback.
 - Improve javadoc of class file update.
 - ... and 1 more: https://git.openjdk.org/jdk/compare/d6b7f9b1...128f53a3

-------------

Changes: https://git.openjdk.org/jdk/pull/18787/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18787&range=04
  Stats: 107 lines in 37 files changed: 46 ins; 7 del; 54 mod
  Patch: https://git.openjdk.org/jdk/pull/18787.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18787/head:pull/18787

PR: https://git.openjdk.org/jdk/pull/18787

From liach at openjdk.org  Tue May 21 00:19:01 2024
From: liach at openjdk.org (Chen Liang)
Date: Tue, 21 May 2024 00:19:01 GMT
Subject: RFR: 8332528: Generate code in SwitchBootstraps.generateTypeSwitch
 that require fewer adaptations
In-Reply-To: <wHUtsMWzEaVwNwDuQJAyrUJrpDkcQpXxb6i5KA7J_Bw=.17b2f7d2-2c8c-42e7-9c90-2bf9f5901f26@github.com>
References: <wHUtsMWzEaVwNwDuQJAyrUJrpDkcQpXxb6i5KA7J_Bw=.17b2f7d2-2c8c-42e7-9c90-2bf9f5901f26@github.com>
Message-ID: <nc_tvQce_-qd9s6nKiqwelbQRu3qJa-E95P1smOPuKI=.65dfde27-633a-47ae-b117-8055be5a1121@github.com>

On Mon, 20 May 2024 10:52:27 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> We can fold the call to `Objects.checkIndex` into the code generated in generateTypeSwitchSkeleton instead of doing so by filtering the MH argument. This loads 9 less classes (of which 8 generated LFs and Species classes) on a minimal test, while being neutral on a throughput sanity test:
> 
> 
> Name                   Cnt  Base   Error   Test   Error  Unit  Change
> SwitchSanity.switchSum  15 8,162 ? 0,117  8,152 ? 0,131 ns/op   1,00x (p = 0,800 )
>   * = significant
>   ```
> 
> A few additional optimizations includes generating the switch method using the precise type (to avoid the need for an explicitCast adaptation), and moving some seldom used `findStatic` calls to a holder. All in all this means a reduction by 33-34M cycles to bootstrap a trivial switch expression on my M1.

Changes requested by liach (Author).

src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java line 630:

> 628:                        .withMethodBody("typeSwitch",
> 629:                                        MethodTypeDescImpl.ofValidated(ConstantDescs.CD_int,
> 630:                                             ClassDesc.ofDescriptor(selectorType.descriptorString()),

`selectorType` can be primitive, therefore verification errors arise at `aload` in the generated code. This is why tests fail on GitHub actions.

-------------

PR Review: https://git.openjdk.org/jdk/pull/19307#pullrequestreview-2067245226
PR Review Comment: https://git.openjdk.org/jdk/pull/19307#discussion_r1607425026

From liach at openjdk.org  Tue May 21 00:22:01 2024
From: liach at openjdk.org (Chen Liang)
Date: Tue, 21 May 2024 00:22:01 GMT
Subject: RFR: 8332547: Unloaded signature classes in DirectMethodHandles
In-Reply-To: <LAJeY7XRSMrz6Sg6TeIOkqZm1uRJbIxhP_PcZdI13JQ=.5790e229-84fd-4282-9769-6613dbb3254a@github.com>
References: <LAJeY7XRSMrz6Sg6TeIOkqZm1uRJbIxhP_PcZdI13JQ=.5790e229-84fd-4282-9769-6613dbb3254a@github.com>
Message-ID: <YiWI28gOYfihW2g9jH2i1AxKA1KI64AFfeYi2Vt3ZI0=.7fbd5b5b-1132-4e9e-a3e7-d735436e4790@github.com>

On Mon, 20 May 2024 21:29:20 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

> JVM routinely installs loader constraints for unloaded signature classes when method resolution takes place. MethodHandle resolution took a different route and eagerly resolves signature classes instead (see `java.lang.invoke.MemberName$Factory::resolve` and `sun.invoke.util.VerifyAccess::isTypeVisible` for details). 
> 
> There's a micro-optimization which bypasses eager resolution for `java.*` classes. The downside is that `java.*` signature classes can show up as unloaded. It manifests as inlining failures during JIT-compilation and may cause severe performance issues.
> 
> Proposed fix removes the aforementioned special case logic during `MethodHandle` resolution. 
> 
> In some cases it may slow down `MethodHandle` construction a bit (e.g., when repeatedly constructing `DirectMethodHandle`s with lots of arguments), but `MethodHandle` construction step is not performance critical.  
> 
> Testing: hs-tier1 - hs-tier4

src/java.base/share/classes/sun/invoke/util/VerifyAccess.java line 291:

> 289:         // guarantees that classes with names beginning "java." cannot be aliased,
> 290:         // because class loaders cannot load them directly. However, it is beneficial
> 291:         // for JIT-compilers to ensure all signature classes are loaded.

Since we anticipate this method to perform side effects, can we rename all of these non-pure `isTypeVisible` to `seeType`/`accessType` to indicate this desired side effect?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19319#discussion_r1607426203

From dholmes at openjdk.org  Tue May 21 01:11:05 2024
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 21 May 2024 01:11:05 GMT
Subject: RFR: 8332494: java/util/zip/EntryCount64k.java failing with
 java.lang.RuntimeException: '\\A\\Z' missing from stderr [v2]
In-Reply-To: <0zogMuGHeb9VVpAWwNLM6PJFJQR4yYdlMxqE9bYfOHg=.c914e3c3-eb99-45a9-8d13-010f9d7c133c@github.com>
References: <P4iFhm88NN9LnctlMK3ZypWEDt33jZ7MUzMhP0C0-sM=.bd4e86ad-41c5-4bb1-be78-5e2b3f4a771b@github.com>
 <0zogMuGHeb9VVpAWwNLM6PJFJQR4yYdlMxqE9bYfOHg=.c914e3c3-eb99-45a9-8d13-010f9d7c133c@github.com>
Message-ID: <v_YqJ6kkxiO6no5FWiQCi8ASPEGwV3K7EFXXFrBo0kA=.2b96e461-363b-41de-b991-18455ce0d632@github.com>

On Mon, 20 May 2024 07:27:19 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

>> Improve `java/util/zip/EntryCount64k.java` stderr parsing by ignoring deprecated warnings. Testing non-generational ZGC requires the use of a deprecated option.
>
> Axel Boldt-Christmas has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update copyright year

looks good. Thanks

-------------

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19297#pullrequestreview-2067288156

From dholmes at openjdk.org  Tue May 21 01:11:06 2024
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 21 May 2024 01:11:06 GMT
Subject: RFR: 8332494: java/util/zip/EntryCount64k.java failing with
 java.lang.RuntimeException: '\\A\\Z' missing from stderr [v2]
In-Reply-To: <BpaFh2N7wc0SgaY_KNkCTOQI5vsSWWhKD50jFPIZR90=.f5447750-018d-4511-86b3-0ee353c99edd@github.com>
References: <P4iFhm88NN9LnctlMK3ZypWEDt33jZ7MUzMhP0C0-sM=.bd4e86ad-41c5-4bb1-be78-5e2b3f4a771b@github.com>
 <0zogMuGHeb9VVpAWwNLM6PJFJQR4yYdlMxqE9bYfOHg=.c914e3c3-eb99-45a9-8d13-010f9d7c133c@github.com>
 <yjbbk6sTmri50DpqjWkZajHPoiClh8hOq-eB6dMIhAk=.f4d3ff77-735d-4640-9eb8-51c253d382ad@github.com>
 <BpaFh2N7wc0SgaY_KNkCTOQI5vsSWWhKD50jFPIZR90=.f5447750-018d-4511-86b3-0ee353c99edd@github.com>
Message-ID: <VHZAwoKW9Ovn9-doNoCI5oe0lrvU6wxDYNvE41D3ueg=.86452ce7-b861-441b-834c-37d9e11b6b51@github.com>

On Mon, 20 May 2024 11:41:48 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

>> test/lib/jdk/test/lib/process/OutputAnalyzer.java line 691:
>> 
>>> 689:      * @throws RuntimeException If the pattern was not found
>>> 690:      */
>>> 691:     public OutputAnalyzer stderrShouldMatchIgnoreDeprecatedWarnings(String pattern) {
>> 
>> Given we have `...IgnoreVMWarnings` this special case should really be called `...IgnoreDeprecatedVMWarnings`.
>
> The name was chosen based on: https://github.com/openjdk/jdk/blob/77c8516085225a04bd5a954197fc5ef7e5c5ee61/test/lib/jdk/test/lib/process/OutputAnalyzer.java#L184
> 
> Should I still change it?

No. Sorry I missed the fact the inconsistency had already been introduced. And given that function exists we may as well add the new one too.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19297#discussion_r1607458481

From darcy at openjdk.org  Tue May 21 01:40:06 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 21 May 2024 01:40:06 GMT
Subject: RFR: 8332086: Remove the usage of ServiceLoader in
 j.u.r.RandomGeneratorFactory [v7]
In-Reply-To: <VO_1lN8_gkntTBcwjxAzdXdGJgtdQWWmuVjZG7wfbsI=.1a2f6ff4-b00e-4193-a268-e5744c3d77f0@github.com>
References: <hfB86NksORc-aC6zVxHel_QQd_9aB629SfQjXvl6q5U=.e31daa4b-5cf6-4f3f-a757-79e818a18978@github.com>
 <VO_1lN8_gkntTBcwjxAzdXdGJgtdQWWmuVjZG7wfbsI=.1a2f6ff4-b00e-4193-a268-e5744c3d77f0@github.com>
Message-ID: <Vna2Y-qyyUa95dD_vTgglyGncXgvLWi1OCgGsENf-No=.d1363416-e680-4f39-80de-4ba4255ed565@github.com>

On Fri, 17 May 2024 08:28:15 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> All random number generator algorithms are implemented in module `java.base`. The usage of `ServiceLoader` in `j.u.r.RandomGeneratorFactory` is no longer needed.
>
> Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:
> 
>   SecureRandom added to the table in package documentation.

src/java.base/share/classes/java/util/random/package-info.java line 129:

> 127:  *
> 128:  * <p> Random number generator algorithms are organized in groups,
> 129:  * as described <a href="package-summary.html#algorithms">below</a>.

FYI, it is possible to link to an anchor in a package-info file using syntax like

`{@linkplain java.util.random##algorithms below}`

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19212#discussion_r1607475198

From iris at openjdk.org  Tue May 21 03:16:09 2024
From: iris at openjdk.org (Iris Clark)
Date: Tue, 21 May 2024 03:16:09 GMT
Subject: RFR: 8330182: Start of release updates for JDK 24 [v5]
In-Reply-To: <YiULppeKgO2y0ANcaUNoqLC_ErnFEoMeBjuLtaHb0iM=.aa9a9262-06ec-48e0-9e2c-ce5533f5d546@github.com>
References: <YKsEQWuI-vNTEDjOBInuEjf8AEcTL4QZ_F4JYUqoxwk=.5ed43782-6dec-4383-948d-d9966a85b3bf@github.com>
 <YiULppeKgO2y0ANcaUNoqLC_ErnFEoMeBjuLtaHb0iM=.aa9a9262-06ec-48e0-9e2c-ce5533f5d546@github.com>
Message-ID: <0Zzab1jdMT4rriv9IrGmO080pZmZRidn3riJprruulg=.cc6c60a0-aeec-49b6-987b-8540dded850a@github.com>

On Mon, 20 May 2024 22:42:20 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Get JDK 24 underway.
>
> Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 11 commits:
> 
>  - Fix-up test.
>  - Merge branch 'master' into JDK-8330188
>  - Adjust test for deprecated options.
>  - Merge branch 'master' into JDK-8330188
>  - Update deprecated options test.
>  - Merge branch 'master' into JDK-8330188
>  - Merge branch 'master' into JDK-8330188
>  - Merge branch 'master' into JDK-8330188
>  - Correct release date as observed in review feedback.
>  - Improve javadoc of class file update.
>  - ... and 1 more: https://git.openjdk.org/jdk/compare/d6b7f9b1...128f53a3

Still looks good.

-------------

Marked as reviewed by iris (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18787#pullrequestreview-2067401131

From aboldtch at openjdk.org  Tue May 21 06:17:08 2024
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Tue, 21 May 2024 06:17:08 GMT
Subject: RFR: 8332495: java/util/logging/LoggingDeadlock2.java fails with
 AssertionError: Some tests failed [v2]
In-Reply-To: <jViDZdflinFxS_Nt2P36eAoq24qe5j2093MQ5cwSMXw=.b7cdad59-5b65-450d-8a32-533dfe490d0f@github.com>
References: <Fvr-WcK1ssQZvGGgefk_FrC4NX7v3QV6g1I-Zdy71eU=.bcf9e38d-e8f9-46d7-b349-d174d88d9d17@github.com>
 <jViDZdflinFxS_Nt2P36eAoq24qe5j2093MQ5cwSMXw=.b7cdad59-5b65-450d-8a32-533dfe490d0f@github.com>
Message-ID: <1Bqt0Ss3nMMj9duTqKIs7h6XBJKbQVJioZJydx6f7mE=.5a972b92-2335-4a26-98c7-027acedc8fc7@github.com>

On Mon, 20 May 2024 07:25:12 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

>> Improve ` java/util/logging/LoggingDeadlock2.java` stderr parsing by ignoring deprecated warnings. Testing non-generational ZGC requires the use of a deprecated option.
>
> Axel Boldt-Christmas has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update copyright year

Thanks for the reviews.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19298#issuecomment-2121825778

From aboldtch at openjdk.org  Tue May 21 06:17:09 2024
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Tue, 21 May 2024 06:17:09 GMT
Subject: RFR: 8332494: java/util/zip/EntryCount64k.java failing with
 java.lang.RuntimeException: '\\A\\Z' missing from stderr [v2]
In-Reply-To: <0zogMuGHeb9VVpAWwNLM6PJFJQR4yYdlMxqE9bYfOHg=.c914e3c3-eb99-45a9-8d13-010f9d7c133c@github.com>
References: <P4iFhm88NN9LnctlMK3ZypWEDt33jZ7MUzMhP0C0-sM=.bd4e86ad-41c5-4bb1-be78-5e2b3f4a771b@github.com>
 <0zogMuGHeb9VVpAWwNLM6PJFJQR4yYdlMxqE9bYfOHg=.c914e3c3-eb99-45a9-8d13-010f9d7c133c@github.com>
Message-ID: <Yss9GabBlBFuNX3vc_rdL5ha94Ssqw1_dzAjJpI-ORM=.4900c3e3-adc1-4f35-ad23-a410587b10c0@github.com>

On Mon, 20 May 2024 07:27:19 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

>> Improve `java/util/zip/EntryCount64k.java` stderr parsing by ignoring deprecated warnings. Testing non-generational ZGC requires the use of a deprecated option.
>
> Axel Boldt-Christmas has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update copyright year

Thanks for the reviews.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19297#issuecomment-2121826396

From aboldtch at openjdk.org  Tue May 21 06:17:08 2024
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Tue, 21 May 2024 06:17:08 GMT
Subject: Integrated: 8332495: java/util/logging/LoggingDeadlock2.java fails
 with AssertionError: Some tests failed
In-Reply-To: <Fvr-WcK1ssQZvGGgefk_FrC4NX7v3QV6g1I-Zdy71eU=.bcf9e38d-e8f9-46d7-b349-d174d88d9d17@github.com>
References: <Fvr-WcK1ssQZvGGgefk_FrC4NX7v3QV6g1I-Zdy71eU=.bcf9e38d-e8f9-46d7-b349-d174d88d9d17@github.com>
Message-ID: <qRVVgJBF1WOKRxG0bVrOyFyThcpUNA6VK6ky6zJWKRQ=.6d696031-fe5d-47fa-afbc-5b0777236f6a@github.com>

On Mon, 20 May 2024 06:42:19 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

> Improve ` java/util/logging/LoggingDeadlock2.java` stderr parsing by ignoring deprecated warnings. Testing non-generational ZGC requires the use of a deprecated option.

This pull request has now been integrated.

Changeset: 9f777930
Author:    Axel Boldt-Christmas <aboldtch at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/9f7779305c4ccbb86bb0e6d0ed8bc92a4b8f3b9d
Stats:     2 lines in 1 file changed: 0 ins; 0 del; 2 mod

8332495: java/util/logging/LoggingDeadlock2.java fails with AssertionError: Some tests failed

Reviewed-by: jpai, stefank

-------------

PR: https://git.openjdk.org/jdk/pull/19298

From aboldtch at openjdk.org  Tue May 21 06:17:09 2024
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Tue, 21 May 2024 06:17:09 GMT
Subject: Integrated: 8332494: java/util/zip/EntryCount64k.java failing with
 java.lang.RuntimeException: '\\A\\Z' missing from stderr
In-Reply-To: <P4iFhm88NN9LnctlMK3ZypWEDt33jZ7MUzMhP0C0-sM=.bd4e86ad-41c5-4bb1-be78-5e2b3f4a771b@github.com>
References: <P4iFhm88NN9LnctlMK3ZypWEDt33jZ7MUzMhP0C0-sM=.bd4e86ad-41c5-4bb1-be78-5e2b3f4a771b@github.com>
Message-ID: <GKihmdwDik_Ol0ubzbzbyEFgUd6xLzJz3xsVP0AX_zw=.02497b5f-9eb9-4bda-8ce7-e626219428e3@github.com>

On Mon, 20 May 2024 06:41:45 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

> Improve `java/util/zip/EntryCount64k.java` stderr parsing by ignoring deprecated warnings. Testing non-generational ZGC requires the use of a deprecated option.

This pull request has now been integrated.

Changeset: f5ab7dff
Author:    Axel Boldt-Christmas <aboldtch at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/f5ab7dff402a3152f5d5736cc6521b4be617eccf
Stats:     21 lines in 2 files changed: 18 ins; 0 del; 3 mod

8332494: java/util/zip/EntryCount64k.java failing with java.lang.RuntimeException: '\\A\\Z' missing from stderr

Reviewed-by: jpai, stefank, dholmes

-------------

PR: https://git.openjdk.org/jdk/pull/19297

From thartmann at openjdk.org  Tue May 21 07:14:10 2024
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Tue, 21 May 2024 07:14:10 GMT
Subject: RFR: 8329538: Accelerate P256 on x86_64 using Montgomery intrinsic
 [v11]
In-Reply-To: <fGBbKw3Tgk10AKNGXpAXYq3_UJwHj6o-CQ1qoIeEwnA=.bedef41f-cd93-4ed3-89b5-a516787c65d3@github.com>
References: <hanRK4GzOkFV8kG1gZRy8Br53trw4-Tu6G6uO8nsFuk=.d5bf723a-f683-4759-ac9e-4a58cb430f03@github.com>
 <fGBbKw3Tgk10AKNGXpAXYq3_UJwHj6o-CQ1qoIeEwnA=.bedef41f-cd93-4ed3-89b5-a516787c65d3@github.com>
Message-ID: <e6hE2NNxJZYrpV-vRvJ0UotEYBAZ-A5xZQBFeLHodLA=.a70bc0c9-fa12-4ab8-952a-580b9cfb7b54@github.com>

On Fri, 17 May 2024 21:16:47 GMT, Volodymyr Paprotski <duke at openjdk.org> wrote:

>> Performance. Before:
>> 
>> Benchmark                        (algorithm)  (dataSize)  (keyLength)  (provider)   Mode  Cnt     Score    Error  Units
>> SignatureBench.ECDSA.sign    SHA256withECDSA        1024          256              thrpt    3  6443.934 ?  6.491  ops/s
>> SignatureBench.ECDSA.sign    SHA256withECDSA       16384          256              thrpt    3  6152.979 ?  4.954  ops/s
>> SignatureBench.ECDSA.verify  SHA256withECDSA        1024          256              thrpt    3  1895.410 ? 36.979  ops/s
>> SignatureBench.ECDSA.verify  SHA256withECDSA       16384          256              thrpt    3  1878.955 ? 45.487  ops/s
>> Benchmark                                            (algorithm)  (keyLength)  (kpgAlgorithm)  (provider)   Mode  Cnt     Score    Error  Units
>> o.o.b.j.c.full.KeyAgreementBench.EC.generateSecret          ECDH          256              EC              thrpt    3  1357.810 ? 26.584  ops/s
>> o.o.b.j.c.small.KeyAgreementBench.EC.generateSecret         ECDH          256              EC              thrpt    3  1352.119 ? 23.547  ops/s
>> Benchmark                          (isMontBench)   Mode  Cnt     Score    Error  Units
>> PolynomialP256Bench.benchMultiply          false  thrpt    3  1746.126 ? 10.970  ops/s
>> 
>> Performance, no intrinsic:
>> 
>> Benchmark                        (algorithm)  (dataSize)  (keyLength)  (provider)   Mode  Cnt     Score     Error  Units
>> SignatureBench.ECDSA.sign    SHA256withECDSA        1024          256              thrpt    3  6529.839 ?  42.420  ops/s
>> SignatureBench.ECDSA.sign    SHA256withECDSA       16384          256              thrpt    3  6199.747 ? 133.566  ops/s
>> SignatureBench.ECDSA.verify  SHA256withECDSA        1024          256              thrpt    3  1973.676 ?  54.071  ops/s
>> SignatureBench.ECDSA.verify  SHA256withECDSA       16384          256              thrpt    3  1932.127 ?  35.920  ops/s
>> Benchmark                                            (algorithm)  (keyLength)  (kpgAlgorithm)  (provider)   Mode  Cnt     Score    Error  Units
>> o.o.b.j.c.full.KeyAgreementBench.EC.generateSecret          ECDH          256              EC              thrpt    3  1355.788 ? 29.858  ops/s
>> o.o.b.j.c.small.KeyAgreementBench.EC.generateSecret         ECDH          256              EC              thrpt    3  1346.523 ? 28.722  ops/s
>> Benchmark                          (isMontBench)   Mode  Cnt     Score    Error  Units
>> PolynomialP256Bench.benchMultiply           true  thrpt    3  1919.57...
>
> Volodymyr Paprotski has updated the pull request incrementally with one additional commit since the last revision:
> 
>   shenandoah verifier

I'll send this through our testing and will report back once it passed.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18583#issuecomment-2121914071

From alanb at openjdk.org  Tue May 21 07:23:07 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 21 May 2024 07:23:07 GMT
Subject: RFR: 8331671: Implement JEP 472: Prepare to Restrict the Use of
 JNI [v8]
In-Reply-To: <GP3trJu5GXEMpyixYDMatIGiwQ6V3L-d8UI6wRgmutQ=.3a3c2d44-bd4d-4ab3-a41d-08a4254c6c21@github.com>
References: <CZGbki5iFdCGPPagE-ya-_L8Nkgf7OunywApOsxC548=.2cee82fa-a5d2-4165-b012-30982a85030a@github.com>
 <vWr2PdgTv6vEllxW8820KO3aZ3tR3xvMhCxD2k7QpS0=.8bfd6c47-6c93-4fc3-aced-7079889aa6a2@github.com>
 <GP3trJu5GXEMpyixYDMatIGiwQ6V3L-d8UI6wRgmutQ=.3a3c2d44-bd4d-4ab3-a41d-08a4254c6c21@github.com>
Message-ID: <zkRt1wjThqbBu80P_ADwwSVkrJVUVxhThYcDKHTUKoA=.fe66b166-dac2-4412-aa35-2d01244e1ad1@github.com>

On Mon, 20 May 2024 18:47:35 GMT, Phil Race <prr at openjdk.org> wrote:

> Have you looked into / thought about how this will work for jpackaged apps ? I suspect that both the existing FFM usage and this will be options the application packager will need to supply when building the jpackaged app - the end user cannot pass in command line VM options. Seems there should be some testing of this as some kind of native access could be a common case for jpackaged apps.

I don't see any tests in test/jdk/tools/jpackage that creates an application that uses JNI code. Seems like a good idea to add this via another PR and it specify --java-options so that the application launcher enables native access. It could test jpackage using jlink too.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19213#issuecomment-2121927727

From thartmann at openjdk.org  Tue May 21 07:24:03 2024
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Tue, 21 May 2024 07:24:03 GMT
Subject: RFR: 8329538: Accelerate P256 on x86_64 using Montgomery intrinsic
 [v11]
In-Reply-To: <fGBbKw3Tgk10AKNGXpAXYq3_UJwHj6o-CQ1qoIeEwnA=.bedef41f-cd93-4ed3-89b5-a516787c65d3@github.com>
References: <hanRK4GzOkFV8kG1gZRy8Br53trw4-Tu6G6uO8nsFuk=.d5bf723a-f683-4759-ac9e-4a58cb430f03@github.com>
 <fGBbKw3Tgk10AKNGXpAXYq3_UJwHj6o-CQ1qoIeEwnA=.bedef41f-cd93-4ed3-89b5-a516787c65d3@github.com>
Message-ID: <NGy5UzfPBZbLLUfy248fGo7Vs20TZbyQAdSxmdApWVk=.71453ebb-30fa-434f-b190-dcffe276d9db@github.com>

On Fri, 17 May 2024 21:16:47 GMT, Volodymyr Paprotski <duke at openjdk.org> wrote:

>> Performance. Before:
>> 
>> Benchmark                        (algorithm)  (dataSize)  (keyLength)  (provider)   Mode  Cnt     Score    Error  Units
>> SignatureBench.ECDSA.sign    SHA256withECDSA        1024          256              thrpt    3  6443.934 ?  6.491  ops/s
>> SignatureBench.ECDSA.sign    SHA256withECDSA       16384          256              thrpt    3  6152.979 ?  4.954  ops/s
>> SignatureBench.ECDSA.verify  SHA256withECDSA        1024          256              thrpt    3  1895.410 ? 36.979  ops/s
>> SignatureBench.ECDSA.verify  SHA256withECDSA       16384          256              thrpt    3  1878.955 ? 45.487  ops/s
>> Benchmark                                            (algorithm)  (keyLength)  (kpgAlgorithm)  (provider)   Mode  Cnt     Score    Error  Units
>> o.o.b.j.c.full.KeyAgreementBench.EC.generateSecret          ECDH          256              EC              thrpt    3  1357.810 ? 26.584  ops/s
>> o.o.b.j.c.small.KeyAgreementBench.EC.generateSecret         ECDH          256              EC              thrpt    3  1352.119 ? 23.547  ops/s
>> Benchmark                          (isMontBench)   Mode  Cnt     Score    Error  Units
>> PolynomialP256Bench.benchMultiply          false  thrpt    3  1746.126 ? 10.970  ops/s
>> 
>> Performance, no intrinsic:
>> 
>> Benchmark                        (algorithm)  (dataSize)  (keyLength)  (provider)   Mode  Cnt     Score     Error  Units
>> SignatureBench.ECDSA.sign    SHA256withECDSA        1024          256              thrpt    3  6529.839 ?  42.420  ops/s
>> SignatureBench.ECDSA.sign    SHA256withECDSA       16384          256              thrpt    3  6199.747 ? 133.566  ops/s
>> SignatureBench.ECDSA.verify  SHA256withECDSA        1024          256              thrpt    3  1973.676 ?  54.071  ops/s
>> SignatureBench.ECDSA.verify  SHA256withECDSA       16384          256              thrpt    3  1932.127 ?  35.920  ops/s
>> Benchmark                                            (algorithm)  (keyLength)  (kpgAlgorithm)  (provider)   Mode  Cnt     Score    Error  Units
>> o.o.b.j.c.full.KeyAgreementBench.EC.generateSecret          ECDH          256              EC              thrpt    3  1355.788 ? 29.858  ops/s
>> o.o.b.j.c.small.KeyAgreementBench.EC.generateSecret         ECDH          256              EC              thrpt    3  1346.523 ? 28.722  ops/s
>> Benchmark                          (isMontBench)   Mode  Cnt     Score    Error  Units
>> PolynomialP256Bench.benchMultiply           true  thrpt    3  1919.57...
>
> Volodymyr Paprotski has updated the pull request incrementally with one additional commit since the last revision:
> 
>   shenandoah verifier

I'm getting some conflicts when trying to apply this to master. Could you please merge the PR?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18583#issuecomment-2121929550

From alanb at openjdk.org  Tue May 21 07:26:17 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 21 May 2024 07:26:17 GMT
Subject: RFR: 8331670: Deprecate the Memory-Access Methods in
 sun.misc.Unsafe for Removal [v3]
In-Reply-To: <9FyO4QpCtH2CNkUEE78_Jjd9xs3bv3WJo16jyowHOvY=.e7131b91-37bb-4624-a60e-72a427a24c92@github.com>
References: <9FyO4QpCtH2CNkUEE78_Jjd9xs3bv3WJo16jyowHOvY=.e7131b91-37bb-4624-a60e-72a427a24c92@github.com>
Message-ID: <ENm9bBCzUHGfXN_heTLJXeoiCjCMAciOlbxOnlFM59s=.496c5cc9-5335-497e-9f9f-448acb302c14@github.com>

> This is the implementation changes for JEP 471.
> 
> The methods in sun.misc.Unsafe for on-heap and off-heap access are deprecated for removal. This means a removal warning at compile time. No methods have been removed. A deprecated message is added to each of the methods but unlikely to be seen as the JDK does not generate or publish the API docs for this class.
> 
> A new command line option --sun-misc-unsafe-memory-access=$value is introduced to allow or deny access to these methods. The default proposed for JDK 23 is "allow" so no change in behavior compared to JDK 22 or previous releases.
> 
> A new test is added to test the command line option settings. The existing micros for FFM that use Unsafe are updated to suppress the removal warning at compile time. A new micro is introduced with a small sample of methods to ensure the changes doesn't cause any perf regressions ([sample results](https://cr.openjdk.org/~alanb/8331670-results.txt)).
> 
> For now, the changes include the update to the man page for the "java" command. It might be that this has to be separated out so that it goes with other updates in the release.

Alan Bateman 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
 - Add removal to DISABLED_WARNINGS
   Fail at startup if bad value specified to option
 - Merge
 - Update man page
 - Update man page
 - Fix comment
 - Merge
 - Merge
 - Whitespace
 - Initial commit

-------------

Changes: https://git.openjdk.org/jdk/pull/19174/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19174&range=02
  Stats: 1234 lines in 8 files changed: 1150 ins; 5 del; 79 mod
  Patch: https://git.openjdk.org/jdk/pull/19174.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19174/head:pull/19174

PR: https://git.openjdk.org/jdk/pull/19174

From asotona at openjdk.org  Tue May 21 08:02:08 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Tue, 21 May 2024 08:02:08 GMT
Subject: Integrated: 8332486: ClassFile API ArrayIndexOutOfBoundsException with
 label metadata
In-Reply-To: <AnO18xDHzgdxAcLcsQLVdNUdMKyqEs2jQl-2YQGbnWA=.ae8dc1dd-a6c2-4223-be09-b823c92c9b87@github.com>
References: <AnO18xDHzgdxAcLcsQLVdNUdMKyqEs2jQl-2YQGbnWA=.ae8dc1dd-a6c2-4223-be09-b823c92c9b87@github.com>
Message-ID: <iN9wBRcZKw33fWLrQ6FbA49oAqZ_I_mdGT-u-oY4hO8=.be246e34-58fd-4b4d-8989-73e49b95f6cf@github.com>

On Mon, 20 May 2024 08:37:49 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> Parsing of a specifically corrupted class file cause unexpected `ArrayIndexOutOfBoundsException` during label inflation.
> This patch checks the valid range and throws expected `IllegalArgumentException` instead.
> Relevant test is added.
> 
> Please review.
> 
> Thanks,
> Adam

This pull request has now been integrated.

Changeset: 451cc239
Author:    Adam Sotona <asotona at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/451cc239050f097060be927171fe0e46962f3356
Stats:     19 lines in 2 files changed: 18 ins; 0 del; 1 mod

8332486: ClassFile API ArrayIndexOutOfBoundsException with label metadata

Reviewed-by: psandoz

-------------

PR: https://git.openjdk.org/jdk/pull/19304

From liach at openjdk.org  Tue May 21 08:05:08 2024
From: liach at openjdk.org (Chen Liang)
Date: Tue, 21 May 2024 08:05:08 GMT
Subject: Integrated: 8311175: Move BufWriter::asByteBuffer to BufWriterImpl
In-Reply-To: <sEKITMKa0yBPrV7RTKYa0_GGSOss8a9T7GaOQpLaEYk=.f7ad0b39-bc77-4589-a8de-ef5132387e6c@github.com>
References: <sEKITMKa0yBPrV7RTKYa0_GGSOss8a9T7GaOQpLaEYk=.f7ad0b39-bc77-4589-a8de-ef5132387e6c@github.com>
Message-ID: <-6THMkB1-gOM8M3ZISzXQIxxIhWBKMqjUkGKFDRXhr0=.729eb1d9-a4dc-4473-82d5-ac63578119d1@github.com>

On Fri, 30 Jun 2023 14:43:36 GMT, Chen Liang <liach at openjdk.org> wrote:

> As discussed on the mailing list https://mail.openjdk.org/pipermail/classfile-api-dev/2023-June/000381.html, BufWriter::asByteBuffer has a behavior not suitable for API and is only used by internal StackMapGenerator/StackCounter, so it will be converted to an internal API.
> 
> Somehow the ByteBuffer needs to be sliced, or StackMapGenerator encounters IOOBE. Not sure what the exact cause was.

This pull request has now been integrated.

Changeset: 414a7fdc
Author:    Chen Liang <liach at openjdk.org>
Committer: Adam Sotona <asotona at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/414a7fdc5e4aae4cec25b0847bb7c163f271b4e0
Stats:     11 lines in 4 files changed: 0 ins; 7 del; 4 mod

8311175: Move BufWriter::asByteBuffer to BufWriterImpl

Reviewed-by: asotona

-------------

PR: https://git.openjdk.org/jdk/pull/14736

From redestad at openjdk.org  Tue May 21 08:30:09 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Tue, 21 May 2024 08:30:09 GMT
Subject: RFR: 8332528: Generate code in SwitchBootstraps.generateTypeSwitch
 that require fewer adaptations
In-Reply-To: <nc_tvQce_-qd9s6nKiqwelbQRu3qJa-E95P1smOPuKI=.65dfde27-633a-47ae-b117-8055be5a1121@github.com>
References: <wHUtsMWzEaVwNwDuQJAyrUJrpDkcQpXxb6i5KA7J_Bw=.17b2f7d2-2c8c-42e7-9c90-2bf9f5901f26@github.com>
 <nc_tvQce_-qd9s6nKiqwelbQRu3qJa-E95P1smOPuKI=.65dfde27-633a-47ae-b117-8055be5a1121@github.com>
Message-ID: <zqHG5yes55VHtHcqHxnDWkLYX0D9F37fujHC1d-XrkE=.f33908a0-1659-4361-89d6-a563b94f2971@github.com>

On Tue, 21 May 2024 00:16:51 GMT, Chen Liang <liach at openjdk.org> wrote:

>> We can fold the call to `Objects.checkIndex` into the code generated in generateTypeSwitchSkeleton instead of doing so by filtering the MH argument. This loads 9 less classes (of which 8 generated LFs and Species classes) on a minimal test, while being neutral on a throughput sanity test:
>> 
>> 
>> Name                   Cnt  Base   Error   Test   Error  Unit  Change
>> SwitchSanity.switchSum  15 8,162 ? 0,117  8,152 ? 0,131 ns/op   1,00x (p = 0,800 )
>>   * = significant
>>   ```
>> 
>> A few additional optimizations includes generating the switch method using the precise type (to avoid the need for an explicitCast adaptation), and moving some seldom used `findStatic` calls to a holder. All in all this means a reduction by 33-34M cycles to bootstrap a trivial switch expression on my M1.
>
> src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java line 630:
> 
>> 628:                        .withMethodBody("typeSwitch",
>> 629:                                        MethodTypeDescImpl.ofValidated(ConstantDescs.CD_int,
>> 630:                                             ClassDesc.ofDescriptor(selectorType.descriptorString()),
> 
> `selectorType` can be primitive, therefore verification errors arise at `aload` in the generated code. This is why tests fail on GitHub actions.

Dang. I had focused on making the `java/lang/runtime` tests pass locally, thinking that'd be sufficient. Luckily bf68b1d had only a minor benefit. Backing it out and tidying up a bit gives me these numbers:

Wall clock:    65.0 ms/op
.taskclock:    75.0 ms/op
.cycles:       255323158 average cycles elapsed
.instructions: 626086160 average instructions retired

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19307#discussion_r1607874407

From alanb at openjdk.org  Tue May 21 08:31:10 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 21 May 2024 08:31:10 GMT
Subject: RFR: 8331189: Implementation of Scoped Values (Third Preview)
Message-ID: <kFWNL6QScozy3Z7CHuifpZgaobVm5ypn8dhNWiBebt4=.c47076f2-8a76-4bf1-b17d-5b50a0c9bb2f@github.com>

JEP 481 proposes Scoped Values to continue to preview in JDK 23 with one change. The type of the operation parameter of the callWhere method is changed to a new functional interface to avoid having the API throw Exception. With that change, the getWhere (and the corresponding method on Carrier) are no longer needed. The functional interface is not proposed for j.u.function at this time.

-------------

Commit messages:
 - Merge
 - Merge
 - Set JEP number
 - Sync up from loom repo
 - Merge
 - Initial commit

Changes: https://git.openjdk.org/jdk/pull/19136/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19136&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8331189
  Stats: 298 lines in 7 files changed: 31 ins; 203 del; 64 mod
  Patch: https://git.openjdk.org/jdk/pull/19136.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19136/head:pull/19136

PR: https://git.openjdk.org/jdk/pull/19136

From aph at openjdk.org  Tue May 21 08:31:11 2024
From: aph at openjdk.org (Andrew Haley)
Date: Tue, 21 May 2024 08:31:11 GMT
Subject: RFR: 8331189: Implementation of Scoped Values (Third Preview)
In-Reply-To: <kFWNL6QScozy3Z7CHuifpZgaobVm5ypn8dhNWiBebt4=.c47076f2-8a76-4bf1-b17d-5b50a0c9bb2f@github.com>
References: <kFWNL6QScozy3Z7CHuifpZgaobVm5ypn8dhNWiBebt4=.c47076f2-8a76-4bf1-b17d-5b50a0c9bb2f@github.com>
Message-ID: <FM727sYio2zGTnvJUCtVKLzmw4DLCd00N2wYE78wW_Y=.be33cf10-2eb6-4bef-8b82-7a9df7b5acde@github.com>

On Wed, 8 May 2024 09:40:38 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> JEP 481 proposes Scoped Values to continue to preview in JDK 23 with one change. The type of the operation parameter of the callWhere method is changed to a new functional interface to avoid having the API throw Exception. With that change, the getWhere (and the corresponding method on Carrier) are no longer needed. The functional interface is not proposed for j.u.function at this time.

Thanks. That all looks reasonable enough, and gets us to the status quo ante + `ScopedValue.CallableOp`,  which is way better than what we have right now.

-------------

Marked as reviewed by aph (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19136#pullrequestreview-2066514531

From duke at openjdk.org  Tue May 21 08:31:11 2024
From: duke at openjdk.org (ExE Boss)
Date: Tue, 21 May 2024 08:31:11 GMT
Subject: RFR: 8331189: Implementation of Scoped Values (Third Preview)
In-Reply-To: <kFWNL6QScozy3Z7CHuifpZgaobVm5ypn8dhNWiBebt4=.c47076f2-8a76-4bf1-b17d-5b50a0c9bb2f@github.com>
References: <kFWNL6QScozy3Z7CHuifpZgaobVm5ypn8dhNWiBebt4=.c47076f2-8a76-4bf1-b17d-5b50a0c9bb2f@github.com>
Message-ID: <9wDT2zc7aFeTYGu7QaSNfPfqAlzWtsd7lVcmzcA8b9E=.17e0f41c-d237-4ec3-b8ee-e3229477c84e@github.com>

On Wed, 8 May 2024 09:40:38 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> JEP 481 proposes Scoped Values to continue to preview in JDK 23 with one change. The type of the operation parameter of the callWhere method is changed to a new functional interface to avoid having the API throw Exception. With that change, the getWhere (and the corresponding method on Carrier) are no longer needed. The functional interface is not proposed for j.u.function at this time.

src/java.base/share/classes/java/lang/ScopedValue.java line 500:

> 498:     @PreviewFeature(feature = PreviewFeature.Feature.SCOPED_VALUES)
> 499:     @FunctionalInterface
> 500:     public interface CallableOp<T, X extends Throwable> {

I?feel like that a?functional interface such as?this?one should be?promoted to?a?top?level?type in?some common?package by?the?time this?feature exits?preview.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19136#discussion_r1596041552

From redestad at openjdk.org  Tue May 21 08:35:42 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Tue, 21 May 2024 08:35:42 GMT
Subject: RFR: 8332528: Generate code in SwitchBootstraps.generateTypeSwitch
 that require fewer adaptations [v2]
In-Reply-To: <wHUtsMWzEaVwNwDuQJAyrUJrpDkcQpXxb6i5KA7J_Bw=.17b2f7d2-2c8c-42e7-9c90-2bf9f5901f26@github.com>
References: <wHUtsMWzEaVwNwDuQJAyrUJrpDkcQpXxb6i5KA7J_Bw=.17b2f7d2-2c8c-42e7-9c90-2bf9f5901f26@github.com>
Message-ID: <-oJ-966KXAKWZOu3Efbp2U9CU49BAJNAcyx-X9rG9e4=.35e5aaa1-b6f1-4c18-9296-592ebbe1abd8@github.com>

> We can fold the call to `Objects.checkIndex` into the code generated in generateTypeSwitchSkeleton instead of doing so by filtering the MH argument. This loads 9 less classes (of which 8 generated LFs and Species classes) on a minimal test, while being neutral on a throughput sanity test:
> 
> 
> Name                   Cnt  Base   Error   Test   Error  Unit  Change
> SwitchSanity.switchSum  15 8,162 ? 0,117  8,152 ? 0,131 ns/op   1,00x (p = 0,800 )
>   * = significant
>   ```
> 
> A few additional optimizations includes moving some seldom used `findStatic` calls to a holder. All in all this means a reduction by 22M cycles to bootstrap a trivial switch expression on my M1.

Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:

  Revert bf68b1d, tidy up

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19307/files
  - new: https://git.openjdk.org/jdk/pull/19307/files/bf68b1d2..c212a3d5

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19307&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19307&range=00-01

  Stats: 27 lines in 1 file changed: 15 ins; 9 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/19307.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19307/head:pull/19307

PR: https://git.openjdk.org/jdk/pull/19307

From jvernee at openjdk.org  Tue May 21 08:39:03 2024
From: jvernee at openjdk.org (Jorn Vernee)
Date: Tue, 21 May 2024 08:39:03 GMT
Subject: RFR: 8332547: Unloaded signature classes in DirectMethodHandles
In-Reply-To: <LAJeY7XRSMrz6Sg6TeIOkqZm1uRJbIxhP_PcZdI13JQ=.5790e229-84fd-4282-9769-6613dbb3254a@github.com>
References: <LAJeY7XRSMrz6Sg6TeIOkqZm1uRJbIxhP_PcZdI13JQ=.5790e229-84fd-4282-9769-6613dbb3254a@github.com>
Message-ID: <CMXIayT8weYU2Xr1kHdWwkxKDvuD4l7Ly3MrAGSMzOE=.51f38e24-5e21-4294-b8f1-fd65a60cd9d5@github.com>

On Mon, 20 May 2024 21:29:20 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

> JVM routinely installs loader constraints for unloaded signature classes when method resolution takes place. MethodHandle resolution took a different route and eagerly resolves signature classes instead (see `java.lang.invoke.MemberName$Factory::resolve` and `sun.invoke.util.VerifyAccess::isTypeVisible` for details). 
> 
> There's a micro-optimization which bypasses eager resolution for `java.*` classes. The downside is that `java.*` signature classes can show up as unloaded. It manifests as inlining failures during JIT-compilation and may cause severe performance issues.
> 
> Proposed fix removes the aforementioned special case logic during `MethodHandle` resolution. 
> 
> In some cases it may slow down `MethodHandle` construction a bit (e.g., when repeatedly constructing `DirectMethodHandle`s with lots of arguments), but `MethodHandle` construction step is not performance critical.  
> 
> Testing: hs-tier1 - hs-tier4

Loading classes seems like a side-effect of `isTypeVisible`. I suggest adding a separate pass that explicitly loads all the signature classes in `MemberName$Factory::resolve`. I think that would make the intent clearer.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19319#issuecomment-2122077296

From mcimadamore at openjdk.org  Tue May 21 08:47:05 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 21 May 2024 08:47:05 GMT
Subject: RFR: 8331671: Implement JEP 472: Prepare to Restrict the Use of
 JNI [v8]
In-Reply-To: <zkRt1wjThqbBu80P_ADwwSVkrJVUVxhThYcDKHTUKoA=.fe66b166-dac2-4412-aa35-2d01244e1ad1@github.com>
References: <CZGbki5iFdCGPPagE-ya-_L8Nkgf7OunywApOsxC548=.2cee82fa-a5d2-4165-b012-30982a85030a@github.com>
 <vWr2PdgTv6vEllxW8820KO3aZ3tR3xvMhCxD2k7QpS0=.8bfd6c47-6c93-4fc3-aced-7079889aa6a2@github.com>
 <GP3trJu5GXEMpyixYDMatIGiwQ6V3L-d8UI6wRgmutQ=.3a3c2d44-bd4d-4ab3-a41d-08a4254c6c21@github.com>
 <zkRt1wjThqbBu80P_ADwwSVkrJVUVxhThYcDKHTUKoA=.fe66b166-dac2-4412-aa35-2d01244e1ad1@github.com>
Message-ID: <m0KMnBpijsGzxC25YvfTb5KjkyHVd3FfELAUxDyIrwI=.31403cb8-74e5-45c5-8177-a0c7f9b9dd31@github.com>

On Tue, 21 May 2024 07:20:05 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> > Have you looked into / thought about how this will work for jpackaged apps ? I suspect that both the existing FFM usage and this will be options the application packager will need to supply when building the jpackaged app - the end user cannot pass in command line VM options. Seems there should be some testing of this as some kind of native access could be a common case for jpackaged apps.
> 
> I don't see any tests in test/jdk/tools/jpackage that creates an application that uses JNI code. Seems like a good idea to add this via another PR and it specify --java-options so that the application launcher enables native access. It could test jpackage using jlink too.

These are all good suggestions. I have not looked into jpackage, but yes, I would expect that the jpackage user would need to provide extra options when packaging the application. The same is true for creating JDK image jlink (which we use in the jextract build) - although, in that case the end user also has the possibility to pass options on the command line.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19213#issuecomment-2122095444

From redestad at openjdk.org  Tue May 21 09:01:32 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Tue, 21 May 2024 09:01:32 GMT
Subject: RFR: 8332528: Generate code in SwitchBootstraps.generateTypeSwitch
 that require fewer adaptations [v3]
In-Reply-To: <wHUtsMWzEaVwNwDuQJAyrUJrpDkcQpXxb6i5KA7J_Bw=.17b2f7d2-2c8c-42e7-9c90-2bf9f5901f26@github.com>
References: <wHUtsMWzEaVwNwDuQJAyrUJrpDkcQpXxb6i5KA7J_Bw=.17b2f7d2-2c8c-42e7-9c90-2bf9f5901f26@github.com>
Message-ID: <obAr25A-jgVCp3uPrBeQJi-D5Oko0ML2lp4VevG8AoQ=.6438ef57-e47f-4f97-8c7e-d15d1b999848@github.com>

> We can fold the call to `Objects.checkIndex` into the code generated in generateTypeSwitchSkeleton instead of doing so by filtering the MH argument. This loads 9 less classes (of which 8 generated LFs and Species classes) on a minimal test, while being neutral on a throughput sanity test:
> 
> 
> Name                   Cnt  Base   Error   Test   Error  Unit  Change
> SwitchSanity.switchSum  15 8,162 ? 0,117  8,152 ? 0,131 ns/op   1,00x (p = 0,800 )
>   * = significant
>   ```
> 
> A few additional optimizations includes moving some seldom used `findStatic` calls to a holder. All in all this means a reduction by 22M cycles to bootstrap a trivial switch expression on my M1.

Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:

  Add type switch to HelloClasslist

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19307/files
  - new: https://git.openjdk.org/jdk/pull/19307/files/c212a3d5..f04d78ea

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19307&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19307&range=01-02

  Stats: 11 lines in 1 file changed: 11 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/19307.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19307/head:pull/19307

PR: https://git.openjdk.org/jdk/pull/19307

From rgiulietti at openjdk.org  Tue May 21 09:06:16 2024
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Tue, 21 May 2024 09:06:16 GMT
Subject: RFR: 8332086: Remove the usage of ServiceLoader in
 j.u.r.RandomGeneratorFactory [v8]
In-Reply-To: <hfB86NksORc-aC6zVxHel_QQd_9aB629SfQjXvl6q5U=.e31daa4b-5cf6-4f3f-a757-79e818a18978@github.com>
References: <hfB86NksORc-aC6zVxHel_QQd_9aB629SfQjXvl6q5U=.e31daa4b-5cf6-4f3f-a757-79e818a18978@github.com>
Message-ID: <8xQ5b35qEeQqzW6987mFb3UXz-bkL9mEEDNgcy0DwtI=.56315206-a018-44c5-bc63-55e6c64b69a7@github.com>

> All random number generator algorithms are implemented in module `java.base`. The usage of `ServiceLoader` in `j.u.r.RandomGeneratorFactory` is no longer needed.

Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:

  Prefer 'linkplain' to 'a href'.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19212/files
  - new: https://git.openjdk.org/jdk/pull/19212/files/880138d7..87813996

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19212&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19212&range=06-07

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/19212.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19212/head:pull/19212

PR: https://git.openjdk.org/jdk/pull/19212

From redestad at openjdk.org  Tue May 21 09:07:04 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Tue, 21 May 2024 09:07:04 GMT
Subject: RFR: 8332528: Generate code in SwitchBootstraps.generateTypeSwitch
 that require fewer adaptations [v3]
In-Reply-To: <obAr25A-jgVCp3uPrBeQJi-D5Oko0ML2lp4VevG8AoQ=.6438ef57-e47f-4f97-8c7e-d15d1b999848@github.com>
References: <wHUtsMWzEaVwNwDuQJAyrUJrpDkcQpXxb6i5KA7J_Bw=.17b2f7d2-2c8c-42e7-9c90-2bf9f5901f26@github.com>
 <obAr25A-jgVCp3uPrBeQJi-D5Oko0ML2lp4VevG8AoQ=.6438ef57-e47f-4f97-8c7e-d15d1b999848@github.com>
Message-ID: <MfxkNBL0g2W0le7Vo3Ay-P3SvYvpQX53b-x7onKwnrM=.d16ebe00-fea1-427b-9616-f18c64e78fa5@github.com>

On Tue, 21 May 2024 09:01:32 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> We can fold the call to `Objects.checkIndex` into the code generated in generateTypeSwitchSkeleton instead of doing so by filtering the MH argument. This loads 9 less classes (of which 8 generated LFs and Species classes) on a minimal test, while being neutral on a throughput sanity test:
>> 
>> 
>> Name                   Cnt  Base   Error   Test   Error  Unit  Change
>> SwitchSanity.switchSum  15 8,162 ? 0,117  8,152 ? 0,131 ns/op   1,00x (p = 0,800 )
>>   * = significant
>>   ```
>> 
>> A few additional optimizations includes moving some seldom used `findStatic` calls to a holder. All in all this means a reduction by 22M cycles to bootstrap a trivial switch expression on my M1.
>
> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add type switch to HelloClasslist

By adding a trivial type switch to `HelloClasslist` we archive a set of classes and avoid some runtime class generation. This grows the default CDS archive by approximately 1.2Mb by pulling in a large number of Classfile API classes, which is bound to happen soon anyway. 

On the SwitchSanity test, bootstrap cost drops by another 35M cycles:

Wall clock:    51.0 ms/op
.taskclock:    63.5 ms/op
.cycles:       220064872 average cycles elapsed
.instructions: 544981276 average instructions retired

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19307#issuecomment-2122136668

From asotona at openjdk.org  Tue May 21 09:25:08 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Tue, 21 May 2024 09:25:08 GMT
Subject: RFR: 8332597: Remove redundant methods from j.l.classfile.ClassReader
 API
Message-ID: <UWBl0HMJIC4_22TkWuBhE9kd2F_l0eiPmpIx8rexFlU=.4f905822-ed5e-41be-b9d4-601af6a55eed@github.com>

j.l.classfile.ClassReader instance is exposed in the Class-File API through j.l.classfile.AttributeMapper::readAttribute method only.
ClassReader only purpose is to serve as a tool for reading content of a custom attribute in a user-provided AttribtueMapper.
It contains useful set of low-level class reading methods for user to implement a custom attribute content parser.

However methods ClassReader::thisClassPos and ClassReader::skipAttributeHolder are not necessary for a custom attribute content parsing and so redundant in the API.
Class-File API implementation internally use these methods, however they should not be exposed in the API.

This patch removes the methods from the API.

Please review.

Thanks,
Adam

-------------

Commit messages:
 - 8332597: Remove redundant methods from j.l.classfile.ClassReader API

Changes: https://git.openjdk.org/jdk/pull/19323/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19323&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8332597
  Stats: 26 lines in 5 files changed: 0 ins; 21 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/19323.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19323/head:pull/19323

PR: https://git.openjdk.org/jdk/pull/19323

From jpai at openjdk.org  Tue May 21 09:43:03 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 21 May 2024 09:43:03 GMT
Subject: RFR: 8332086: Remove the usage of ServiceLoader in
 j.u.r.RandomGeneratorFactory [v8]
In-Reply-To: <8xQ5b35qEeQqzW6987mFb3UXz-bkL9mEEDNgcy0DwtI=.56315206-a018-44c5-bc63-55e6c64b69a7@github.com>
References: <hfB86NksORc-aC6zVxHel_QQd_9aB629SfQjXvl6q5U=.e31daa4b-5cf6-4f3f-a757-79e818a18978@github.com>
 <8xQ5b35qEeQqzW6987mFb3UXz-bkL9mEEDNgcy0DwtI=.56315206-a018-44c5-bc63-55e6c64b69a7@github.com>
Message-ID: <K3wfzDNXQuSztugHheJ5PKm7T4cT8uGpIuMs9mEiSE4=.cf232c81-cef6-47e0-ba75-9113ce37cda4@github.com>

On Tue, 21 May 2024 09:06:16 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> All random number generator algorithms are implemented in module `java.base`. The usage of `ServiceLoader` in `j.u.r.RandomGeneratorFactory` is no longer needed.
>
> Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Prefer 'linkplain' to 'a href'.

Marked as reviewed by jpai (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/19212#pullrequestreview-2068098589

From mli at openjdk.org  Tue May 21 09:59:03 2024
From: mli at openjdk.org (Hamlin Li)
Date: Tue, 21 May 2024 09:59:03 GMT
Subject: RFR: 8331196: vector api: Remove unnecessary index check in
 Byte/ShortVector.fromArray/fromArray0Template
In-Reply-To: <NpbcAc45Uw1LVGtv_LxGR5UIQ0DjL_Smvc3a99bonf8=.6814098e-bb3b-4381-9bc6-11838dae2eba@github.com>
References: <YLwvFU3XpoutOZCBehEbDwlkkucrAbHv1mF8K9zzDH0=.b49d1661-adac-4a96-b013-84f1b4dd7fcf@github.com>
 <NpbcAc45Uw1LVGtv_LxGR5UIQ0DjL_Smvc3a99bonf8=.6814098e-bb3b-4381-9bc6-11838dae2eba@github.com>
Message-ID: <X1ngihSxAJufJxg4Bon_EK_kT9n5vAOenpDl2MgATZI=.d27ab020-f633-4bd1-b769-0b6acd60659d@github.com>

On Mon, 20 May 2024 19:21:44 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>> Hi,
>> Can you help to review this simple patch?
>> Some index check in Byte/ShortVector.fromArray/fromArray0Template seems not necessary, could be removed.
>> Thanks
>
> That does not look correct and will only check a prefix indexes. A `ByteVector` with a shape of 256 bits has 32 lanes, whereas an `IntVector` of the same shape has 8 lanes. The `mapOffset` array will hold 32 indexes that need checking, so we need to loop through `mapOffset` array four times.

Thanks @PaulSandoz for comment.
I just re-ran the vector api tests with this patch on x64 and riscv64, but seems no failures triggered. Let me check further, either I missed something or maybe there is some gap in test to be filled.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18977#issuecomment-2122240453

From mcimadamore at openjdk.org  Tue May 21 10:20:27 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 21 May 2024 10:20:27 GMT
Subject: RFR: 8331865: Consolidate size and alignment checks in LayoutPath
 [v3]
In-Reply-To: <CvKkdESp5-uHiuZtQvGortWnzOMV89pfjaCHNBIV4B4=.51ad0f01-2371-48af-b3c6-8a9b80518cdb@github.com>
References: <CvKkdESp5-uHiuZtQvGortWnzOMV89pfjaCHNBIV4B4=.51ad0f01-2371-48af-b3c6-8a9b80518cdb@github.com>
Message-ID: <206PC955P0Z45jL6ZYWY-gRNyuyw0t2eeJBBE8-yRsY=.5c98c55d-0192-4d79-ba27-0c1a44e69b89@github.com>

> When creating a nested memory access var handle, we ensure that the segment is accessed at the correct alignment for the root layout being accessed. But we do not ensure that the segment has at least the size of the accessed root layout. Example:
> 
> 
> MemoryLayout LAYOUT = sequenceLayout(2, structLayout(JAVA_INT.withName("x"), JAVA_INT.withName("y")));
> VarHandle X_HANDLE = LAYOUT.varHandle(PathElement.sequenceElement(), PathElement.groupElement("x"));
> 
> 
> If I have a memory segment whose size is 12, I can successfully call X_HANDLE on it with index 1, like so:
> 
> 
> MemorySegment segment = Arena.ofAuto().allocate(12);
> int x = (int)X_HANDLE.get(segment, 0, 1);
> 
> 
> This seems incorrect: after all, the provided segment doesn't have enough space to fit _two_ elements of the nested structs. 
> 
> This PR adds checks to detect this kind of scenario earlier, thus improving usability. To achieve this we could, in principle, just tweak `LayoutPath::checkEnclosingLayout` and add the required size check.
> 
> But doing so will add yet another redundant check on top of the other already added by [pull/19124](https://git.openjdk.org/jdk/pull/19124). Instead, this PR rethinks how memory segment var handles are created, in order to eliminate redundant checks.
> 
> The main observation is that size and alignment checks depend on an _enclosing_ layout. This layout *might* be the very same value layout being accessed (this is the case when e.g. using `JAVA_INT.varHandle()`). But, in the general case, the accessed value layout and the enclosing layout might differ (e.g. think about accessing a struct field).
> 
> Furthermore, the enclosing layout check depends on the _base_ offset at which the segment is accessed, _prior_ to any index computation that occurs if the accessed layout path has any open elements. It is important to notice that this base offset is only available when looking at the var handle that is returned to the user. For instance, an indexed var handle with coordinates:
> 
> 
> (MemorySegment, long /* base */, long /* index 1 */, long /* index 2 */, long /* index 3 */)
> 
> 
> Is obtained through adaptation, by taking a more basic var handle of the form:
> 
> 
> (MemorySegment, long /* offset */)
> 
> 
> And then injecting the result of the index multiplication into `offset`. As such, we can't add an enclosing layout check inside the var handle returned by `VarHandles::memorySegmentViewHandle`, as doing so will end up seeing the *wrong* offset (e.g. an offset in which the index part has already been mixed in)...

Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:

  Fix typo in javadoc

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19251/files
  - new: https://git.openjdk.org/jdk/pull/19251/files/a7b09d9d..14f0b8b3

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19251&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19251&range=01-02

  Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/19251.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19251/head:pull/19251

PR: https://git.openjdk.org/jdk/pull/19251

From asotona at openjdk.org  Tue May 21 11:40:03 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Tue, 21 May 2024 11:40:03 GMT
Subject: RFR: 8307818: Convert Indify tool to Classfile API [v8]
In-Reply-To: <NkLMH9NX2o1zUUPbEdp_jGq-E8V3inBRBnadM9Z-_qU=.cf443418-a3a6-41fc-acfc-8a3de241c747@github.com>
References: <tCFk9yrCtcoBnzvNIgceY0eOaXg9ZiN9nkCuhHIyMyw=.9cc5f994-8d35-411a-bb39-7c3f2ac34dda@github.com>
 <NkLMH9NX2o1zUUPbEdp_jGq-E8V3inBRBnadM9Z-_qU=.cf443418-a3a6-41fc-acfc-8a3de241c747@github.com>
Message-ID: <2Ca4OTxbNasLB29gPwNK0-Qi6_vg-2peHWjN4nKQmLU=.3fea78d0-b4fb-4235-a34e-772d3380331f@github.com>

On Mon, 20 May 2024 20:56:18 GMT, Oussama Louati <duke at openjdk.org> wrote:

>> An indify tool in j.l.i tests (also in vmTestBase) convert some source-code private static methods with MT_ MH_, and INDY_ prefixes into MethodHandle, MethodType, and CallSite constants.
>> It currently uses ad-hoc code to process class files and intends to migrate to ASM; but since we have the Classfile API, we can migrate to Classfile API instead.
>
> Oussama Louati has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update: Added javadoc documentation

The pull request is not buildable in the current state and I suggest to return it to draft.

Minimal change to enable preview for build and run of the Indify tool is drafted here:
https://github.com/openjdk/jdk/commit/7c2344b275da1dff99ade284192488eaa8ffba02

Indify invocation on Microbenchmarks as a part of the JDK build (after application of the above patch) still fails with:

Failure on /Applications/XcodeJIB.app/dev/github/jdk/build/macosx-aarch64/support/test/micro/classes
Exception in thread "main" java.lang.NullPointerException: Cannot invoke "java.lang.classfile.ClassModel.thisClass()" because "model" is null
	at java.base/java.lang.classfile.ClassFile.transform(ClassFile.java:445)
	at indify.Indify.transformToBytes(Indify.java:369)
	at indify.Indify.writeNewClassFile(Indify.java:360)
	at indify.Indify.indifyFile(Indify.java:356)
	at indify.Indify.indifyTree(Indify.java:391)
	at indify.Indify.indifyTree(Indify.java:393)
	at indify.Indify.indifyTree(Indify.java:393)
	at indify.Indify.indifyTree(Indify.java:393)
	at indify.Indify.indifyTree(Indify.java:393)
	at indify.Indify.indifyTree(Indify.java:393)
	at indify.Indify.indifyTree(Indify.java:393)
	at indify.Indify.indify(Indify.java:339)
	at indify.Indify.run(Indify.java:191)
	at indify.Indify.main(Indify.java:101)

-------------

Changes requested by asotona (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18841#pullrequestreview-2068375431
PR Comment: https://git.openjdk.org/jdk/pull/18841#issuecomment-2122432164
PR Comment: https://git.openjdk.org/jdk/pull/18841#issuecomment-2122435605

From liach at openjdk.org  Tue May 21 11:41:02 2024
From: liach at openjdk.org (Chen Liang)
Date: Tue, 21 May 2024 11:41:02 GMT
Subject: RFR: 8332597: Remove redundant methods from
 j.l.classfile.ClassReader API
In-Reply-To: <UWBl0HMJIC4_22TkWuBhE9kd2F_l0eiPmpIx8rexFlU=.4f905822-ed5e-41be-b9d4-601af6a55eed@github.com>
References: <UWBl0HMJIC4_22TkWuBhE9kd2F_l0eiPmpIx8rexFlU=.4f905822-ed5e-41be-b9d4-601af6a55eed@github.com>
Message-ID: <gksyj-RShBeN-Ekta2ihBhnzuIXNRZXurCSOGsrZRVg=.a3ce584c-25e9-4f85-9f50-5d82a860b9ec@github.com>

On Tue, 21 May 2024 09:20:36 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> j.l.classfile.ClassReader instance is exposed in the Class-File API through j.l.classfile.AttributeMapper::readAttribute method only.
> ClassReader only purpose is to serve as a tool for reading content of a custom attribute in a user-provided AttribtueMapper.
> It contains useful set of low-level class reading methods for user to implement a custom attribute content parser.
> 
> However methods ClassReader::thisClassPos and ClassReader::skipAttributeHolder are not necessary for a custom attribute content parsing and so redundant in the API.
> Class-File API implementation internally use these methods, however they should not be exposed in the API.
> 
> This patch removes the methods from the API.
> 
> Please review.
> 
> Thanks,
> Adam

Marked as reviewed by liach (Author).

-------------

PR Review: https://git.openjdk.org/jdk/pull/19323#pullrequestreview-2068383252

From vklang at openjdk.org  Tue May 21 11:48:10 2024
From: vklang at openjdk.org (Viktor Klang)
Date: Tue, 21 May 2024 11:48:10 GMT
Subject: RFR: 8332154: Memory leak in SynchronousQueue
In-Reply-To: <Ie2RBQsHbdlFbZFM_RVLEX6_eMDIJXpyeXxrofPkjLY=.2a2cb32d-28a8-4c49-a0a5-05642d16cc3d@github.com>
References: <Fj3W5LlneHODz3PcBD0Ypu2f34UYvxw1iLLKz5pba-I=.0f419338-0a23-4834-8404-55aeab4b813f@github.com>
 <bTv3Bc8P355m7kNSPOd1_ybXXewKB6lvqOwzKtO58cE=.cb6dc72f-ef56-46ca-a5b4-7d821327e6ec@github.com>
 <Ie2RBQsHbdlFbZFM_RVLEX6_eMDIJXpyeXxrofPkjLY=.2a2cb32d-28a8-4c49-a0a5-05642d16cc3d@github.com>
Message-ID: <3E6wxZZ1qJfzcYGz_A3Obyxpld_bxFv2iSXHdHTWsA8=.d74d80e5-395f-4c5e-b6e4-5f63528a5fe4@github.com>

On Thu, 16 May 2024 21:36:03 GMT, Konstantin Nisht <duke at openjdk.org> wrote:

>> @AlanBateman @DougLea Reviews are most welcome :)
>
> @viktorklang-ora We managed to reproduce it quite reliably by running the test from the bug report multiple times (in our case, it was 100). I understand this does not make a 100% stable regression reproducer, but in case of multiple runs the probability of false positive in quite low.

@knisht @vprovodin Thanks for the thoughts, I decided to go for a blackbox test to make sure that this test does not rely on any internal impl details of SynchronousQueue.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19271#issuecomment-2122448833

From vklang at openjdk.org  Tue May 21 11:56:10 2024
From: vklang at openjdk.org (Viktor Klang)
Date: Tue, 21 May 2024 11:56:10 GMT
Subject: RFR: 8314480: Memory ordering spec updates in java.lang.ref [v22]
In-Reply-To: <fa0Mqk6azF75mkiKAwMZHmtC5Lsw4KqcTAMZb3bIJWo=.16abf539-e6c6-4ab5-a937-a0505522d802@github.com>
References: <R74ontYwjYg6HeZY0cWrlo0amjl4E1YsFWeuh4pda14=.08ac62df-b2f8-4b4d-b338-07adb289601b@github.com>
 <iSAFZXJw0U2itwjjNTLOuChx4kx9K1J6odAc4IyngK8=.67614a1a-833f-4079-8bfa-f204083a3cee@github.com>
 <fa0Mqk6azF75mkiKAwMZHmtC5Lsw4KqcTAMZb3bIJWo=.16abf539-e6c6-4ab5-a937-a0505522d802@github.com>
Message-ID: <nOkaM5MmODiCH1eir1AjdoFuiGWtSWjV5Z2xhMew1IU=.ce323d48-20d5-4c1f-bf23-f2f17e2fb92b@github.com>

On Wed, 17 Apr 2024 17:12:28 GMT, Brent Christian <bchristi at openjdk.org> wrote:

>> Brent Christian has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Another update to reachabilityFence() @apiNote
>
> AFAICT, all review feedback on this change has been addressed. I would love to have some reviewers take another look. Thanks!

@bchristi-git Just checking in?we're waiting for CSR-approval here before integrating? ?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/16644#issuecomment-2122461878

From redestad at openjdk.org  Tue May 21 12:28:02 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Tue, 21 May 2024 12:28:02 GMT
Subject: RFR: 8332528: Generate code in SwitchBootstraps.generateTypeSwitch
 that require fewer adaptations [v3]
In-Reply-To: <obAr25A-jgVCp3uPrBeQJi-D5Oko0ML2lp4VevG8AoQ=.6438ef57-e47f-4f97-8c7e-d15d1b999848@github.com>
References: <wHUtsMWzEaVwNwDuQJAyrUJrpDkcQpXxb6i5KA7J_Bw=.17b2f7d2-2c8c-42e7-9c90-2bf9f5901f26@github.com>
 <obAr25A-jgVCp3uPrBeQJi-D5Oko0ML2lp4VevG8AoQ=.6438ef57-e47f-4f97-8c7e-d15d1b999848@github.com>
Message-ID: <p0BjlyV3Cs1WWCQZUoQdveHhewYD42RlDxlmbGtr8-c=.b0255bc7-7623-45f6-9668-44ce62f5a55f@github.com>

On Tue, 21 May 2024 09:01:32 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> We can fold the call to `Objects.checkIndex` into the code generated in generateTypeSwitchSkeleton instead of doing so by filtering the MH argument. This loads 9 less classes (of which 8 generated LFs and Species classes) on a minimal test, while being neutral on a throughput sanity test:
>> 
>> 
>> Name                   Cnt  Base   Error   Test   Error  Unit  Change
>> SwitchSanity.switchSum  15 8,162 ? 0,117  8,152 ? 0,131 ns/op   1,00x (p = 0,800 )
>>   * = significant
>>   ```
>> 
>> A few additional optimizations includes moving some seldom used `findStatic` calls to a holder. All in all this means a reduction by 22M cycles to bootstrap a trivial switch expression on my M1.
>
> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add type switch to HelloClasslist

[f04d78e](https://github.com/openjdk/jdk/pull/19307/commits/f04d78ea53ed0074026311f82eb0d4eafee3438d) passed tier1-3 testing

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19307#issuecomment-2122519106

From rgiulietti at openjdk.org  Tue May 21 12:56:11 2024
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Tue, 21 May 2024 12:56:11 GMT
Subject: Integrated: 8332086: Remove the usage of ServiceLoader in
 j.u.r.RandomGeneratorFactory
In-Reply-To: <hfB86NksORc-aC6zVxHel_QQd_9aB629SfQjXvl6q5U=.e31daa4b-5cf6-4f3f-a757-79e818a18978@github.com>
References: <hfB86NksORc-aC6zVxHel_QQd_9aB629SfQjXvl6q5U=.e31daa4b-5cf6-4f3f-a757-79e818a18978@github.com>
Message-ID: <T9YmCRG1fCqtqB7Yj5V-Uu-0HgmwyP3mjFb0nb5W7Sg=.94a8bc17-1e63-4cf3-bce6-ef379bb326fe@github.com>

On Mon, 13 May 2024 08:47:50 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

> All random number generator algorithms are implemented in module `java.base`. The usage of `ServiceLoader` in `j.u.r.RandomGeneratorFactory` is no longer needed.

This pull request has now been integrated.

Changeset: 42e3c842
Author:    Raffaello Giulietti <rgiulietti at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/42e3c842ae2684265c794868fc76eb0ff2dea3d9
Stats:     610 lines in 19 files changed: 215 ins; 275 del; 120 mod

8332086: Remove the usage of ServiceLoader in j.u.r.RandomGeneratorFactory
8332476: j.u.r.RandomGeneratorFactor.create(long|byte[]) should throw rather than silently fallback to no-arg create()

Reviewed-by: jpai

-------------

PR: https://git.openjdk.org/jdk/pull/19212

From pminborg at openjdk.org  Tue May 21 12:56:12 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 21 May 2024 12:56:12 GMT
Subject: RFR: 8330465: Stable Values and Collections (Internal) [v20]
In-Reply-To: <kLBsOOVO524jwGiSeA_8W5EwK1uXz0Cp6b_uIbrt_VY=.ee3fbae5-6f6c-45f4-8b62-b9f92a015730@github.com>
References: <-KSimQo5kkmCzzMShqGe5QZ9yCSzpWL98gN13v4wP0k=.11dd8d06-18a6-4577-8342-66632cea0b6e@github.com>
 <kLBsOOVO524jwGiSeA_8W5EwK1uXz0Cp6b_uIbrt_VY=.ee3fbae5-6f6c-45f4-8b62-b9f92a015730@github.com>
Message-ID: <UsGq_5cxROVkrA84Q7Bo6lz1yDNMh4ijmHnlxDwqM2E=.b7d7ed5c-74a0-4089-b27d-383cfd63c164@github.com>

On Fri, 17 May 2024 09:31:33 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> # Stable Values & Collections (Internal)
>> 
>> ## Summary
>> This PR proposes to introduce an internal _Stable Values & Collections_ API, which provides immutable value holders where elements are initialized _at most once_. Stable Values & Collections offer the performance and safety benefits of final fields while offering greater flexibility as to the timing of initialization.
>> 
>> ## Goals
>>  * Provide an easy and intuitive API to describe value holders that can change at most once.
>>  * Decouple declaration from initialization without significant footprint or performance penalties.
>>  * Reduce the amount of static initializer and/or field initialization code.
>>  * Uphold integrity and consistency, even in a multi-threaded environment.
>>  
>> For more details, see the draft JEP: https://openjdk.org/jeps/8312611
>> 
>> ## Performance 
>> Performance compared to instance variables using two `AtomicReference` and two protected by double-checked locking under concurrent access by all threads:
>> 
>> 
>> Benchmark                                      Mode  Cnt      Score      Error   Units
>> StableBenchmark.atomic                        thrpt   10    259.478 ?   36.809  ops/us
>> StableBenchmark.dcl                           thrpt   10    225.710 ?   26.638  ops/us
>> StableBenchmark.stable                        thrpt   10   4382.478 ? 1151.472  ops/us <- StableValue significantly faster
>> 
>> 
>> Performance compared to static variables protected by `AtomicReference`, class-holder idiom holder, and double-checked locking (all threads):
>> 
>> 
>> Benchmark                                      Mode  Cnt      Score      Error   Units
>> StableStaticBenchmark.atomic                  thrpt   10   6487.835 ?  385.639  ops/us
>> StableStaticBenchmark.dcl                     thrpt   10   6605.239 ?  210.610  ops/us
>> StableStaticBenchmark.stable                  thrpt   10  14338.239 ? 1426.874  ops/us
>> StableStaticBenchmark.staticCHI               thrpt   10  13780.341 ? 1839.651  ops/us
>> 
>> 
>> Performance for stable lists (thread safe) in both instance and static contexts whereby we access a single value compared to `ArrayList` instances (which are not thread-safe) (all threads):
>> 
>> 
>> Benchmark                                      Mode  Cnt      Score      Error   Units
>> StableListElementBenchmark.instanceArrayList  thrpt   10   5812.992 ? 1169.730  ops/us
>> StableListElementBenchmark.instanceList       thrpt   10   4818.643 ?  704.893  ops/us
>> StableListElementBenchmark...
>
> Per Minborg has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Add benchmarks for memoized IntFunction and Function
>  - Add benchmark for memoized supplier

We are considering another implementation with less complexity. So, for now, thank you for all the feedback so far. We will try to make sure to carry over them to a new PR.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18794#issuecomment-2122569580

From liach at openjdk.org  Tue May 21 13:35:03 2024
From: liach at openjdk.org (Chen Liang)
Date: Tue, 21 May 2024 13:35:03 GMT
Subject: RFR: 8332528: Generate code in SwitchBootstraps.generateTypeSwitch
 that require fewer adaptations [v3]
In-Reply-To: <obAr25A-jgVCp3uPrBeQJi-D5Oko0ML2lp4VevG8AoQ=.6438ef57-e47f-4f97-8c7e-d15d1b999848@github.com>
References: <wHUtsMWzEaVwNwDuQJAyrUJrpDkcQpXxb6i5KA7J_Bw=.17b2f7d2-2c8c-42e7-9c90-2bf9f5901f26@github.com>
 <obAr25A-jgVCp3uPrBeQJi-D5Oko0ML2lp4VevG8AoQ=.6438ef57-e47f-4f97-8c7e-d15d1b999848@github.com>
Message-ID: <wvq5e9wyHagjbCj5ATkDY1OPOis1XMxnOQ6NhyYu8l0=.5d904cd4-da2a-40b9-b54d-132f1587f2c1@github.com>

On Tue, 21 May 2024 09:01:32 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> We can fold the call to `Objects.checkIndex` into the code generated in generateTypeSwitchSkeleton instead of doing so by filtering the MH argument. This loads 9 less classes (of which 8 generated LFs and Species classes) on a minimal test, while being neutral on a throughput sanity test:
>> 
>> 
>> Name                   Cnt  Base   Error   Test   Error  Unit  Change
>> SwitchSanity.switchSum  15 8,162 ? 0,117  8,152 ? 0,131 ns/op   1,00x (p = 0,800 )
>>   * = significant
>>   ```
>> 
>> A few additional optimizations includes moving some seldom used `findStatic` calls to a holder. All in all this means a reduction by 22M cycles to bootstrap a trivial switch expression on my M1.
>
> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add type switch to HelloClasslist

Marked as reviewed by liach (Author).

-------------

PR Review: https://git.openjdk.org/jdk/pull/19307#pullrequestreview-2068663088

From liach at openjdk.org  Tue May 21 14:06:11 2024
From: liach at openjdk.org (Chen Liang)
Date: Tue, 21 May 2024 14:06:11 GMT
Subject: RFR: 8330465: Stable Values and Collections (Internal) [v20]
In-Reply-To: <kLBsOOVO524jwGiSeA_8W5EwK1uXz0Cp6b_uIbrt_VY=.ee3fbae5-6f6c-45f4-8b62-b9f92a015730@github.com>
References: <-KSimQo5kkmCzzMShqGe5QZ9yCSzpWL98gN13v4wP0k=.11dd8d06-18a6-4577-8342-66632cea0b6e@github.com>
 <kLBsOOVO524jwGiSeA_8W5EwK1uXz0Cp6b_uIbrt_VY=.ee3fbae5-6f6c-45f4-8b62-b9f92a015730@github.com>
Message-ID: <RcuBpZiczVKlDBxh417-2Gn9ulQpRz9xwnmuvc36vEo=.dafa471b-a8e7-455c-b589-dad78ea46b0c@github.com>

On Fri, 17 May 2024 09:31:33 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> # Stable Values & Collections (Internal)
>> 
>> ## Summary
>> This PR proposes to introduce an internal _Stable Values & Collections_ API, which provides immutable value holders where elements are initialized _at most once_. Stable Values & Collections offer the performance and safety benefits of final fields while offering greater flexibility as to the timing of initialization.
>> 
>> ## Goals
>>  * Provide an easy and intuitive API to describe value holders that can change at most once.
>>  * Decouple declaration from initialization without significant footprint or performance penalties.
>>  * Reduce the amount of static initializer and/or field initialization code.
>>  * Uphold integrity and consistency, even in a multi-threaded environment.
>>  
>> For more details, see the draft JEP: https://openjdk.org/jeps/8312611
>> 
>> ## Performance 
>> Performance compared to instance variables using two `AtomicReference` and two protected by double-checked locking under concurrent access by all threads:
>> 
>> 
>> Benchmark                                      Mode  Cnt      Score      Error   Units
>> StableBenchmark.atomic                        thrpt   10    259.478 ?   36.809  ops/us
>> StableBenchmark.dcl                           thrpt   10    225.710 ?   26.638  ops/us
>> StableBenchmark.stable                        thrpt   10   4382.478 ? 1151.472  ops/us <- StableValue significantly faster
>> 
>> 
>> Performance compared to static variables protected by `AtomicReference`, class-holder idiom holder, and double-checked locking (all threads):
>> 
>> 
>> Benchmark                                      Mode  Cnt      Score      Error   Units
>> StableStaticBenchmark.atomic                  thrpt   10   6487.835 ?  385.639  ops/us
>> StableStaticBenchmark.dcl                     thrpt   10   6605.239 ?  210.610  ops/us
>> StableStaticBenchmark.stable                  thrpt   10  14338.239 ? 1426.874  ops/us
>> StableStaticBenchmark.staticCHI               thrpt   10  13780.341 ? 1839.651  ops/us
>> 
>> 
>> Performance for stable lists (thread safe) in both instance and static contexts whereby we access a single value compared to `ArrayList` instances (which are not thread-safe) (all threads):
>> 
>> 
>> Benchmark                                      Mode  Cnt      Score      Error   Units
>> StableListElementBenchmark.instanceArrayList  thrpt   10   5812.992 ? 1169.730  ops/us
>> StableListElementBenchmark.instanceList       thrpt   10   4818.643 ?  704.893  ops/us
>> StableListElementBenchmark...
>
> Per Minborg has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Add benchmarks for memoized IntFunction and Function
>  - Add benchmark for memoized supplier

Thanks for the insights. Also, I wonder what is a good amount of metadata you are considering, as original stable values only take one possible representation out of all to indicate a mutable state, much lighter in weight compared to the current implementation, which takes many bits; this might disencourage StableValue use.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18794#issuecomment-2122714875

From rriggs at openjdk.org  Tue May 21 14:14:09 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 21 May 2024 14:14:09 GMT
Subject: Integrated: 8331224: ClassCastException in ObjectInputStream hides
 ClassNotFoundException
In-Reply-To: <WwGt00cM9kdSmRkkh5Vs27AanKC0I4DwCBoWhai7itI=.3dde8683-9701-4d87-bf5f-0d0d501bd037@github.com>
References: <WwGt00cM9kdSmRkkh5Vs27AanKC0I4DwCBoWhai7itI=.3dde8683-9701-4d87-bf5f-0d0d501bd037@github.com>
Message-ID: <ZxiAbDmxDpKJsyGu7OflHEVwMmoNfCQPfsESdMc7tL8=.f54d5f1e-51f6-46ae-8580-55650d51ca2f@github.com>

On Wed, 1 May 2024 18:43:21 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> The issue reported a ClassCastException "cannot assign instance of java.util.CollSer to field of type java.util.Map"
> while deserializing an object referring to an immutable Map that contained a reference to a class that was not available.
> Immutable Collections such as Map utilize a serialization proxy in their serialized form.
> During deserialization the serialization proxy (a private implementation class) was attempted to be set in a field resulting in the ClassCastException. The ClassCastException and bug hid the ClassCastException that should have been thrown.
> 
> When reading record fields or fields of a class, the results of deserialization of individual fields are recorded as dependencies of the object being constructed.
> The apparent bug is that the summary of those dependencies is not checked between reading the fields and invoking the constructor to create the record or assigning the fields to an object being constructed.

This pull request has now been integrated.

Changeset: 8291c94b
Author:    Roger Riggs <rriggs at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/8291c94bcdbb01beddc94f290f2749841404cc0c
Stats:     199 lines in 2 files changed: 195 ins; 0 del; 4 mod

8331224: ClassCastException in ObjectInputStream hides ClassNotFoundException

Reviewed-by: smarks

-------------

PR: https://git.openjdk.org/jdk/pull/19043

From mbaesken at openjdk.org  Tue May 21 14:34:24 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 21 May 2024 14:34:24 GMT
Subject: RFR: 8332589: ubsan: unix/native/libjava/ProcessImpl_md.c:562:5:
 runtime error: null pointer passed as argument 2,
 which is declared to never be null
Message-ID: <AwlmAiTOhqSaoJ2Jh5YYrBpxakc0Pt9lYP9nvcBjXBo=.813efddf-3f87-4bbf-9cc5-cd769eabd2f7@github.com>

When building with ubsan enabled (--enable-uban) on Linux x86_64 and doing jtreg tests afterwards I run into this error :

/jdk/src/java.base/unix/native/libjava/ProcessImpl_md.c:562:5: runtime error: null pointer passed as argument 2, which is declared to never be null
    #0 0x7fd95bec78d8 in spawnChild /jdk/src/java.base/unix/native/libjava/ProcessImpl_md.c:562
    #1 0x7fd95bec78d8 in startChild /jdk/src/java.base/unix/native/libjava/ProcessImpl_md.c:612
    #2 0x7fd95bec78d8 in Java_java_lang_ProcessImpl_forkAndExec /jdk/src/java.base/unix/native/libjava/ProcessImpl_md.c:712
    #3 0x7fd93797a06d (<unknown module>)

this is the memcpy call getting an unexpected null pointer :
    memcpy(buf+offset, c->pdir, sp.dirlen); gets a second parameter null.
Something similar was discussed and fixed here https://bugs.python.org/issue27570 for Python .

Similar issue in OpenJDK _ 
https://bugs.openjdk.org/browse/JDK-8332473
8332473: ubsan: growableArray.hpp:290:10: runtime error: null pointer passed as argument 1, which is declared to never be null

-------------

Commit messages:
 - JDK-8332589

Changes: https://git.openjdk.org/jdk/pull/19329/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19329&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8332589
  Stats: 4 lines in 1 file changed: 2 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/19329.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19329/head:pull/19329

PR: https://git.openjdk.org/jdk/pull/19329

From liach at openjdk.org  Tue May 21 14:38:08 2024
From: liach at openjdk.org (Chen Liang)
Date: Tue, 21 May 2024 14:38:08 GMT
Subject: RFR: 8332614: Type-checked ConstantPool.entryByIndex and
 ClassReader.readEntryOrNull
Message-ID: <UP8XpBov1w74UcUrAkD08x3vQGy_zRQ8NFRXuMU8us4=.3cce8ca0-742b-43f2-a282-894c7f61c969@github.com>

I propose to add type-checked ConstantPool.entryByIndex and ClassReader.readEntryOrNull taking an extra Class parameter, which throws ConstantPoolException instead of ClassCastException on type mismatch, which can happen to malformed ClassFiles.

Requesting a review from @asotona. Thanks!

Proposal on mailing list: https://mail.openjdk.org/pipermail/classfile-api-dev/2024-May/000512.html

-------------

Commit messages:
 - 8332614: Type-checked ConstantPool.entryByIndex and ClassReader.readEntryOrNull

Changes: https://git.openjdk.org/jdk/pull/19330/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19330&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8332614
  Stats: 183 lines in 14 files changed: 103 ins; 30 del; 50 mod
  Patch: https://git.openjdk.org/jdk/pull/19330.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19330/head:pull/19330

PR: https://git.openjdk.org/jdk/pull/19330

From jpai at openjdk.org  Tue May 21 15:18:02 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 21 May 2024 15:18:02 GMT
Subject: RFR: 8331189: Implementation of Scoped Values (Third Preview)
In-Reply-To: <kFWNL6QScozy3Z7CHuifpZgaobVm5ypn8dhNWiBebt4=.c47076f2-8a76-4bf1-b17d-5b50a0c9bb2f@github.com>
References: <kFWNL6QScozy3Z7CHuifpZgaobVm5ypn8dhNWiBebt4=.c47076f2-8a76-4bf1-b17d-5b50a0c9bb2f@github.com>
Message-ID: <dwQnebDOn3GeiO0VE05dAcJGpXSU5lXJZnuuHc97lsw=.dc45f6a7-9248-4ba8-a692-f6d3480b22c4@github.com>

On Wed, 8 May 2024 09:40:38 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> JEP 481 proposes Scoped Values to continue to preview in JDK 23 with one change. The type of the operation parameter of the callWhere method is changed to a new functional interface to avoid having the API throw Exception. With that change, the getWhere (and the corresponding method on Carrier) are no longer needed. The functional interface is not proposed for j.u.function at this time.

src/java.base/share/classes/java/lang/ScopedValue.java line 494:

> 492: 
> 493:     /**
> 494:      * An operation that returns a result and may throw an exception.

Nit - should it be "or may throw an exception"?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19136#discussion_r1608511614

From jpai at openjdk.org  Tue May 21 15:23:05 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 21 May 2024 15:23:05 GMT
Subject: RFR: 8331189: Implementation of Scoped Values (Third Preview)
In-Reply-To: <kFWNL6QScozy3Z7CHuifpZgaobVm5ypn8dhNWiBebt4=.c47076f2-8a76-4bf1-b17d-5b50a0c9bb2f@github.com>
References: <kFWNL6QScozy3Z7CHuifpZgaobVm5ypn8dhNWiBebt4=.c47076f2-8a76-4bf1-b17d-5b50a0c9bb2f@github.com>
Message-ID: <9w-sAquOO5zvhtJysLdS5Z1pSQab9-QdKGJ2Mh7xH7g=.11390fa8-0772-4cdc-a793-e698ec0705fa@github.com>

On Wed, 8 May 2024 09:40:38 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> JEP 481 proposes Scoped Values to continue to preview in JDK 23 with one change. The type of the operation parameter of the callWhere method is changed to a new functional interface to avoid having the API throw Exception. With that change, the getWhere (and the corresponding method on Carrier) are no longer needed. The functional interface is not proposed for j.u.function at this time.

The changes look OK to me.

-------------

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19136#pullrequestreview-2068941921

From psandoz at openjdk.org  Tue May 21 15:44:04 2024
From: psandoz at openjdk.org (Paul Sandoz)
Date: Tue, 21 May 2024 15:44:04 GMT
Subject: RFR: 8331196: vector api: Remove unnecessary index check in
 Byte/ShortVector.fromArray/fromArray0Template
In-Reply-To: <NpbcAc45Uw1LVGtv_LxGR5UIQ0DjL_Smvc3a99bonf8=.6814098e-bb3b-4381-9bc6-11838dae2eba@github.com>
References: <YLwvFU3XpoutOZCBehEbDwlkkucrAbHv1mF8K9zzDH0=.b49d1661-adac-4a96-b013-84f1b4dd7fcf@github.com>
 <NpbcAc45Uw1LVGtv_LxGR5UIQ0DjL_Smvc3a99bonf8=.6814098e-bb3b-4381-9bc6-11838dae2eba@github.com>
Message-ID: <Z_RcxCe1XI0y1Mnv72KBSuxq4B9mgpsypIzEzIbc76c=.b2564ddb-a057-4b33-90b6-dbd2b01e4ccf@github.com>

On Mon, 20 May 2024 19:21:44 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>> Hi,
>> Can you help to review this simple patch?
>> Some index check in Byte/ShortVector.fromArray/fromArray0Template seems not necessary, could be removed.
>> Thanks
>
> That does not look correct and will only check a prefix indexes. A `ByteVector` with a shape of 256 bits has 32 lanes, whereas an `IntVector` of the same shape has 8 lanes. The `mapOffset` array will hold 32 indexes that need checking, so we need to loop through `mapOffset` array four times.

> Thanks @PaulSandoz for comment. I just re-ran the vector api tests with this patch on x64 and riscv64, but seems no failures triggered. Let me check further, either I missed something or maybe there is some gap in test to be filled.

More likely a gap in the tests, not sufficiently checking for out of bounds access across the range in the mapOffset array.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18977#issuecomment-2122917109

From prappo at openjdk.org  Tue May 21 15:44:18 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Tue, 21 May 2024 15:44:18 GMT
Subject: RFR: 8305457: Implement java.io.IO [v10]
In-Reply-To: <w2msiw_qaMEIJS3s9D4bg8pFbz5WIF0KdP6Mm-XFjLI=.85b2020b-8c46-4bac-8a69-4975b068f2ff@github.com>
References: <w2msiw_qaMEIJS3s9D4bg8pFbz5WIF0KdP6Mm-XFjLI=.85b2020b-8c46-4bac-8a69-4975b068f2ff@github.com>
Message-ID: <5di7ye6tSNpauiTtHGwGI7kFG-iWeKpbWGEOXRK88ag=.fcfb14fd-53d3-4c4c-b774-3660cf6495bb@github.com>

> Please review this PR which introduces the `java.io.IO` top-level class and three methods to `java.io.Console` for [Implicitly Declared Classes and Instance Main Methods (Third Preview)].
> 
> This PR has been obtained as `git merge --squash` of a now obsolete [draft PR].
> 
> [Implicitly Declared Classes and Instance Main Methods (Third Preview)]: https://bugs.openjdk.org/browse/JDK-8323335
> [draft PR]: https://github.com/openjdk/jdk/pull/18921

Pavel Rappo has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 20 commits:

 - Add diagnostic output
 - Use "expect" that was found
 - Merge branch 'master' into 8305457-Implement-java.io.IO
   
   # Conflicts:
   #	src/java.base/share/classes/java/io/ProxyingConsole.java
   #	src/java.base/share/classes/jdk/internal/io/JdkConsole.java
   #	src/java.base/share/classes/jdk/internal/io/JdkConsoleImpl.java
   #	src/jdk.internal.le/share/classes/jdk/internal/org/jline/JdkConsoleProviderImpl.java
   #	src/jdk.jshell/share/classes/jdk/jshell/execution/impl/ConsoleImpl.java
 - Escape prompt
 - Merge branch 'master' into 8305457-Implement-java.io.IO
 - Clarify input charset
 - Make IO final
 - Fix System.console().readln(null) in jshell
   
   Without it, jshell hangs on me. Will think of a test.
 - Fix typo
 - Merge branch 'master' into 8305457-Implement-java.io.IO
 - ... and 10 more: https://git.openjdk.org/jdk/compare/b92bd671...809e98e0

-------------

Changes: https://git.openjdk.org/jdk/pull/19112/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19112&range=09
  Stats: 692 lines in 13 files changed: 692 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/19112.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19112/head:pull/19112

PR: https://git.openjdk.org/jdk/pull/19112

From psandoz at openjdk.org  Tue May 21 15:47:03 2024
From: psandoz at openjdk.org (Paul Sandoz)
Date: Tue, 21 May 2024 15:47:03 GMT
Subject: RFR: 8331865: Consolidate size and alignment checks in LayoutPath
 [v3]
In-Reply-To: <206PC955P0Z45jL6ZYWY-gRNyuyw0t2eeJBBE8-yRsY=.5c98c55d-0192-4d79-ba27-0c1a44e69b89@github.com>
References: <CvKkdESp5-uHiuZtQvGortWnzOMV89pfjaCHNBIV4B4=.51ad0f01-2371-48af-b3c6-8a9b80518cdb@github.com>
 <206PC955P0Z45jL6ZYWY-gRNyuyw0t2eeJBBE8-yRsY=.5c98c55d-0192-4d79-ba27-0c1a44e69b89@github.com>
Message-ID: <xhZkuzQwUWCdX3lkY-b3n1e4NZEQZq56cF72m3vmGKM=.3f4697ef-f50d-418c-88e7-1e4a955b1493@github.com>

On Tue, 21 May 2024 10:20:27 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> When creating a nested memory access var handle, we ensure that the segment is accessed at the correct alignment for the root layout being accessed. But we do not ensure that the segment has at least the size of the accessed root layout. Example:
>> 
>> 
>> MemoryLayout LAYOUT = sequenceLayout(2, structLayout(JAVA_INT.withName("x"), JAVA_INT.withName("y")));
>> VarHandle X_HANDLE = LAYOUT.varHandle(PathElement.sequenceElement(), PathElement.groupElement("x"));
>> 
>> 
>> If I have a memory segment whose size is 12, I can successfully call X_HANDLE on it with index 1, like so:
>> 
>> 
>> MemorySegment segment = Arena.ofAuto().allocate(12);
>> int x = (int)X_HANDLE.get(segment, 0, 1);
>> 
>> 
>> This seems incorrect: after all, the provided segment doesn't have enough space to fit _two_ elements of the nested structs. 
>> 
>> This PR adds checks to detect this kind of scenario earlier, thus improving usability. To achieve this we could, in principle, just tweak `LayoutPath::checkEnclosingLayout` and add the required size check.
>> 
>> But doing so will add yet another redundant check on top of the other already added by [pull/19124](https://git.openjdk.org/jdk/pull/19124). Instead, this PR rethinks how memory segment var handles are created, in order to eliminate redundant checks.
>> 
>> The main observation is that size and alignment checks depend on an _enclosing_ layout. This layout *might* be the very same value layout being accessed (this is the case when e.g. using `JAVA_INT.varHandle()`). But, in the general case, the accessed value layout and the enclosing layout might differ (e.g. think about accessing a struct field).
>> 
>> Furthermore, the enclosing layout check depends on the _base_ offset at which the segment is accessed, _prior_ to any index computation that occurs if the accessed layout path has any open elements. It is important to notice that this base offset is only available when looking at the var handle that is returned to the user. For instance, an indexed var handle with coordinates:
>> 
>> 
>> (MemorySegment, long /* base */, long /* index 1 */, long /* index 2 */, long /* index 3 */)
>> 
>> 
>> Is obtained through adaptation, by taking a more basic var handle of the form:
>> 
>> 
>> (MemorySegment, long /* offset */)
>> 
>> 
>> And then injecting the result of the index multiplication into `offset`. As such, we can't add an enclosing layout check inside the var handle returned by `VarHandles::memorySegmentViewHandle`, as doing so will end up seeing the *wrong* off...
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix typo in javadoc

Marked as reviewed by psandoz (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/19251#pullrequestreview-2068996279

From asemenyuk at openjdk.org  Tue May 21 15:57:06 2024
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Tue, 21 May 2024 15:57:06 GMT
Subject: RFR: 8331671: Implement JEP 472: Prepare to Restrict the Use of
 JNI [v8]
In-Reply-To: <vWr2PdgTv6vEllxW8820KO3aZ3tR3xvMhCxD2k7QpS0=.8bfd6c47-6c93-4fc3-aced-7079889aa6a2@github.com>
References: <CZGbki5iFdCGPPagE-ya-_L8Nkgf7OunywApOsxC548=.2cee82fa-a5d2-4165-b012-30982a85030a@github.com>
 <vWr2PdgTv6vEllxW8820KO3aZ3tR3xvMhCxD2k7QpS0=.8bfd6c47-6c93-4fc3-aced-7079889aa6a2@github.com>
Message-ID: <Z4v5RDWq81-UKvhkRVYPggJwn6H10GkMrmtTXhfmfkU=.5644db12-51a7-4b98-8923-04e5912d15cf@github.com>

On Fri, 17 May 2024 13:38:25 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This PR implements [JEP 472](https://openjdk.org/jeps/472), by restricting the use of JNI in the following ways:
>> 
>> * `System::load` and `System::loadLibrary` are now restricted methods
>> * `Runtime::load` and `Runtime::loadLibrary` are now restricted methods
>> * binding a JNI `native` method declaration to a native implementation is now considered a restricted operation
>> 
>> This PR slightly changes the way in which the JDK deals with restricted methods, even for FFM API calls. In Java 22, the single `--enable-native-access` was used both to specify a set of modules for which native access should be allowed *and* to specify whether illegal native access (that is, native access occurring from a module not specified by `--enable-native-access`) should be treated as an error or a warning. More specifically, an error is only issued if the `--enable-native-access flag` is used at least once.
>> 
>> Here, a new flag is introduced, namely `illegal-native-access=allow/warn/deny`, which is used to specify what should happen when access to a restricted method and/or functionality is found outside the set of modules specified with `--enable-native-access`. The default policy is `warn`, but users can select `allow` to suppress the warnings, or `deny` to cause `IllegalCallerException` to be thrown. This aligns the treatment of restricted methods with other mechanisms, such as `--illegal-access` and the more recent `--sun-misc-unsafe-memory-access`.
>> 
>> Some changes were required in the package-info javadoc for `java.lang.foreign`, to reflect the changes in the command line flags described above.
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address review comments

`jdk.jpackage` changes look good

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19213#issuecomment-2122942586

From ccheung at openjdk.org  Tue May 21 16:15:04 2024
From: ccheung at openjdk.org (Calvin Cheung)
Date: Tue, 21 May 2024 16:15:04 GMT
Subject: RFR: 8332340: Add JavacBench as a test case for CDS [v3]
In-Reply-To: <JyXZjtHrBwxBbYTgyKfne732jbC7gCNzwgPDKWHAxAQ=.3b8e48bb-3bfa-4b85-88d4-65cee20a5cec@github.com>
References: <xqD4PeVZfIAKzywbLnjGZMFh36YSqXNolZkTgh1Vk6E=.44db7c57-64c1-4912-96e1-e61848312ccb@github.com>
 <JyXZjtHrBwxBbYTgyKfne732jbC7gCNzwgPDKWHAxAQ=.3b8e48bb-3bfa-4b85-88d4-65cee20a5cec@github.com>
Message-ID: <SBRg_W2YmoYm6eVZZoOkZIP3iJgLqbFXJBKlXIvrb6w=.d3b8f3b9-b813-49f6-b731-76642ff8dad0@github.com>

On Mon, 20 May 2024 17:24:22 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> JavacBench is a test program that compiles 90 Java source files. It uses a fair amount of invokedynamic callsites, so it's good for testing CDS support for indy and lambda expressions.
>> 
>> This test was first integrated into the [leyden](https://github.com/openjdk/leyden/tree/premain) repo. Hence some of the files have copyrights in 2023.
>
> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
> 
>   @calvinccheung comments

Updates look good. Thanks!

-------------

Marked as reviewed by ccheung (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19256#pullrequestreview-2069075764

From prr at openjdk.org  Tue May 21 16:45:06 2024
From: prr at openjdk.org (Phil Race)
Date: Tue, 21 May 2024 16:45:06 GMT
Subject: RFR: 8331671: Implement JEP 472: Prepare to Restrict the Use of
 JNI [v8]
In-Reply-To: <vWr2PdgTv6vEllxW8820KO3aZ3tR3xvMhCxD2k7QpS0=.8bfd6c47-6c93-4fc3-aced-7079889aa6a2@github.com>
References: <CZGbki5iFdCGPPagE-ya-_L8Nkgf7OunywApOsxC548=.2cee82fa-a5d2-4165-b012-30982a85030a@github.com>
 <vWr2PdgTv6vEllxW8820KO3aZ3tR3xvMhCxD2k7QpS0=.8bfd6c47-6c93-4fc3-aced-7079889aa6a2@github.com>
Message-ID: <2sHuToXAXHYrqtE31r7-wDvJ3JM0nQYujuLFAtqWQQI=.3c61631b-ecb1-4073-9b5f-6a379ab614cf@github.com>

On Fri, 17 May 2024 13:38:25 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This PR implements [JEP 472](https://openjdk.org/jeps/472), by restricting the use of JNI in the following ways:
>> 
>> * `System::load` and `System::loadLibrary` are now restricted methods
>> * `Runtime::load` and `Runtime::loadLibrary` are now restricted methods
>> * binding a JNI `native` method declaration to a native implementation is now considered a restricted operation
>> 
>> This PR slightly changes the way in which the JDK deals with restricted methods, even for FFM API calls. In Java 22, the single `--enable-native-access` was used both to specify a set of modules for which native access should be allowed *and* to specify whether illegal native access (that is, native access occurring from a module not specified by `--enable-native-access`) should be treated as an error or a warning. More specifically, an error is only issued if the `--enable-native-access flag` is used at least once.
>> 
>> Here, a new flag is introduced, namely `illegal-native-access=allow/warn/deny`, which is used to specify what should happen when access to a restricted method and/or functionality is found outside the set of modules specified with `--enable-native-access`. The default policy is `warn`, but users can select `allow` to suppress the warnings, or `deny` to cause `IllegalCallerException` to be thrown. This aligns the treatment of restricted methods with other mechanisms, such as `--illegal-access` and the more recent `--sun-misc-unsafe-memory-access`.
>> 
>> Some changes were required in the package-info javadoc for `java.lang.foreign`, to reflect the changes in the command line flags described above.
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address review comments

client parts look fine.

-------------

Marked as reviewed by prr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19213#pullrequestreview-2069134455

From asemenyuk at openjdk.org  Tue May 21 16:59:04 2024
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Tue, 21 May 2024 16:59:04 GMT
Subject: RFR: 8331671: Implement JEP 472: Prepare to Restrict the Use of
 JNI [v8]
In-Reply-To: <m0KMnBpijsGzxC25YvfTb5KjkyHVd3FfELAUxDyIrwI=.31403cb8-74e5-45c5-8177-a0c7f9b9dd31@github.com>
References: <CZGbki5iFdCGPPagE-ya-_L8Nkgf7OunywApOsxC548=.2cee82fa-a5d2-4165-b012-30982a85030a@github.com>
 <vWr2PdgTv6vEllxW8820KO3aZ3tR3xvMhCxD2k7QpS0=.8bfd6c47-6c93-4fc3-aced-7079889aa6a2@github.com>
 <GP3trJu5GXEMpyixYDMatIGiwQ6V3L-d8UI6wRgmutQ=.3a3c2d44-bd4d-4ab3-a41d-08a4254c6c21@github.com>
 <zkRt1wjThqbBu80P_ADwwSVkrJVUVxhThYcDKHTUKoA=.fe66b166-dac2-4412-aa35-2d01244e1ad1@github.com>
 <m0KMnBpijsGzxC25YvfTb5KjkyHVd3FfELAUxDyIrwI=.31403cb8-74e5-45c5-8177-a0c7f9b9dd31@github.com>
Message-ID: <xZ1AEmH_qkn4fErnw7SyycG07-_XN0Sr0OdvCPGEaQQ=.358a6210-b5a3-4b3e-a15f-bd89aa212f42@github.com>

On Tue, 21 May 2024 08:44:47 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> These are all good suggestions. I have not looked into jpackage, but yes, I would expect that the jpackage user would need to provide extra options when packaging the application.

It would be good to document how jpackage users packaging apps with native access will be affected by this change. Primarily that they need to pass `--illegal-native-access` parameter to affected jpackage app launchers.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19213#issuecomment-2123054154

From bchristi at openjdk.org  Tue May 21 17:02:13 2024
From: bchristi at openjdk.org (Brent Christian)
Date: Tue, 21 May 2024 17:02:13 GMT
Subject: RFR: 8314480: Memory ordering spec updates in java.lang.ref [v22]
In-Reply-To: <fa0Mqk6azF75mkiKAwMZHmtC5Lsw4KqcTAMZb3bIJWo=.16abf539-e6c6-4ab5-a937-a0505522d802@github.com>
References: <R74ontYwjYg6HeZY0cWrlo0amjl4E1YsFWeuh4pda14=.08ac62df-b2f8-4b4d-b338-07adb289601b@github.com>
 <iSAFZXJw0U2itwjjNTLOuChx4kx9K1J6odAc4IyngK8=.67614a1a-833f-4079-8bfa-f204083a3cee@github.com>
 <fa0Mqk6azF75mkiKAwMZHmtC5Lsw4KqcTAMZb3bIJWo=.16abf539-e6c6-4ab5-a937-a0505522d802@github.com>
Message-ID: <vgHrkAj_5vBtWEy1C8966ZzsP7eUUdW4PQkTs96WD-U=.b488ae70-a7ce-4074-9489-c2a39496c6b6@github.com>

On Wed, 17 Apr 2024 17:12:28 GMT, Brent Christian <bchristi at openjdk.org> wrote:

>> Brent Christian has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Another update to reachabilityFence() @apiNote
>
> AFAICT, all review feedback on this change has been addressed. I would love to have some reviewers take another look. Thanks!

> @bchristi-git Just checking in?we're waiting for CSR-approval here before integrating? ?

Indeed - can't move forward without a CSR. Also wouldn't mind more reviewer ??s. ?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/16644#issuecomment-2123059255

From duke at openjdk.org  Tue May 21 17:41:46 2024
From: duke at openjdk.org (Volodymyr Paprotski)
Date: Tue, 21 May 2024 17:41:46 GMT
Subject: RFR: 8329538: Accelerate P256 on x86_64 using Montgomery intrinsic
 [v12]
In-Reply-To: <hanRK4GzOkFV8kG1gZRy8Br53trw4-Tu6G6uO8nsFuk=.d5bf723a-f683-4759-ac9e-4a58cb430f03@github.com>
References: <hanRK4GzOkFV8kG1gZRy8Br53trw4-Tu6G6uO8nsFuk=.d5bf723a-f683-4759-ac9e-4a58cb430f03@github.com>
Message-ID: <kuMyLYSd4dOC7qBbk9G7ZtvntC1U3FR5V35jLP1qHtQ=.e1459498-2ab5-48b1-8490-25dc94d49b1d@github.com>

> Performance. Before:
> 
> Benchmark                        (algorithm)  (dataSize)  (keyLength)  (provider)   Mode  Cnt     Score    Error  Units
> SignatureBench.ECDSA.sign    SHA256withECDSA        1024          256              thrpt    3  6443.934 ?  6.491  ops/s
> SignatureBench.ECDSA.sign    SHA256withECDSA       16384          256              thrpt    3  6152.979 ?  4.954  ops/s
> SignatureBench.ECDSA.verify  SHA256withECDSA        1024          256              thrpt    3  1895.410 ? 36.979  ops/s
> SignatureBench.ECDSA.verify  SHA256withECDSA       16384          256              thrpt    3  1878.955 ? 45.487  ops/s
> Benchmark                                            (algorithm)  (keyLength)  (kpgAlgorithm)  (provider)   Mode  Cnt     Score    Error  Units
> o.o.b.j.c.full.KeyAgreementBench.EC.generateSecret          ECDH          256              EC              thrpt    3  1357.810 ? 26.584  ops/s
> o.o.b.j.c.small.KeyAgreementBench.EC.generateSecret         ECDH          256              EC              thrpt    3  1352.119 ? 23.547  ops/s
> Benchmark                          (isMontBench)   Mode  Cnt     Score    Error  Units
> PolynomialP256Bench.benchMultiply          false  thrpt    3  1746.126 ? 10.970  ops/s
> 
> Performance, no intrinsic:
> 
> Benchmark                        (algorithm)  (dataSize)  (keyLength)  (provider)   Mode  Cnt     Score     Error  Units
> SignatureBench.ECDSA.sign    SHA256withECDSA        1024          256              thrpt    3  6529.839 ?  42.420  ops/s
> SignatureBench.ECDSA.sign    SHA256withECDSA       16384          256              thrpt    3  6199.747 ? 133.566  ops/s
> SignatureBench.ECDSA.verify  SHA256withECDSA        1024          256              thrpt    3  1973.676 ?  54.071  ops/s
> SignatureBench.ECDSA.verify  SHA256withECDSA       16384          256              thrpt    3  1932.127 ?  35.920  ops/s
> Benchmark                                            (algorithm)  (keyLength)  (kpgAlgorithm)  (provider)   Mode  Cnt     Score    Error  Units
> o.o.b.j.c.full.KeyAgreementBench.EC.generateSecret          ECDH          256              EC              thrpt    3  1355.788 ? 29.858  ops/s
> o.o.b.j.c.small.KeyAgreementBench.EC.generateSecret         ECDH          256              EC              thrpt    3  1346.523 ? 28.722  ops/s
> Benchmark                          (isMontBench)   Mode  Cnt     Score    Error  Units
> PolynomialP256Bench.benchMultiply           true  thrpt    3  1919.574 ? 10.591  ops/s
> 
> Performance, **with intrinsics*...

Volodymyr Paprotski has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 17 additional commits since the last revision:

 - Merge remote-tracking branch 'origin/master' into ecc-montgomery
 - shenandoah verifier
 - comments from Sandhya
 - whitespace
 - add message back
 - whitespace
 - Use AffinePoint to exit Montgomery domain
   
   Style notes:
   Affine.equals()
       - Mismatched fields only appear to be used from testing, perhaps should be moved there instead
   Affine.getX(boolean)|getY(boolean)
       - "Passing flag is bad design" - cleanest/performant alternative to several instanceof checks
       - needed to convert Affine to Projective (need to stay in montgomery domain)
   ECOperations.PointMultiplier
      - changes could probably be restored to original (since ProjectivePoint handling no longer required)
      - consider these changes an improvement? (fewer nested classes)
      - was an inner-class but not using inner-class features (i.e. ecOps variable should be converted)
 - whitespace
 - Comments from Tony and Jatin
 - Comments from Jatin and Tony
 - ... and 7 more: https://git.openjdk.org/jdk/compare/12e8009b...b1a33004

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/18583/files
  - new: https://git.openjdk.org/jdk/pull/18583/files/df4fe6fa..b1a33004

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18583&range=11
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18583&range=10-11

  Stats: 190975 lines in 3949 files changed: 105304 ins; 64688 del; 20983 mod
  Patch: https://git.openjdk.org/jdk/pull/18583.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18583/head:pull/18583

PR: https://git.openjdk.org/jdk/pull/18583

From duke at openjdk.org  Tue May 21 17:41:46 2024
From: duke at openjdk.org (Volodymyr Paprotski)
Date: Tue, 21 May 2024 17:41:46 GMT
Subject: RFR: 8329538: Accelerate P256 on x86_64 using Montgomery intrinsic
 [v11]
In-Reply-To: <NGy5UzfPBZbLLUfy248fGo7Vs20TZbyQAdSxmdApWVk=.71453ebb-30fa-434f-b190-dcffe276d9db@github.com>
References: <hanRK4GzOkFV8kG1gZRy8Br53trw4-Tu6G6uO8nsFuk=.d5bf723a-f683-4759-ac9e-4a58cb430f03@github.com>
 <fGBbKw3Tgk10AKNGXpAXYq3_UJwHj6o-CQ1qoIeEwnA=.bedef41f-cd93-4ed3-89b5-a516787c65d3@github.com>
 <NGy5UzfPBZbLLUfy248fGo7Vs20TZbyQAdSxmdApWVk=.71453ebb-30fa-434f-b190-dcffe276d9db@github.com>
Message-ID: <havoPnSn-HW5UH74R4GoFjA0rkGVW9VRetGZqo4vAOE=.d3c755cf-e82d-47ee-908e-0de98087516f@github.com>

On Tue, 21 May 2024 07:21:14 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

>> Volodymyr Paprotski has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   shenandoah verifier
>
> I'm getting some conflicts when trying to apply this to master. Could you please merge the PR?

Hi @TobiHartmann , merged with no issues for me. Could you please run the tests again? (I think Tony did run them, but can't hurt verifying again). Thanks!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18583#issuecomment-2123122468

From vlivanov at openjdk.org  Tue May 21 18:05:04 2024
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Tue, 21 May 2024 18:05:04 GMT
Subject: RFR: 8332547: Unloaded signature classes in DirectMethodHandles
In-Reply-To: <LAJeY7XRSMrz6Sg6TeIOkqZm1uRJbIxhP_PcZdI13JQ=.5790e229-84fd-4282-9769-6613dbb3254a@github.com>
References: <LAJeY7XRSMrz6Sg6TeIOkqZm1uRJbIxhP_PcZdI13JQ=.5790e229-84fd-4282-9769-6613dbb3254a@github.com>
Message-ID: <QNXNxP3DEo9d4wqp3Af93Rg5D_zTbdtWDbPQ6dC3p2k=.cffa3736-0c7d-421d-b7b1-cbb0b7aa24e7@github.com>

On Mon, 20 May 2024 21:29:20 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

> JVM routinely installs loader constraints for unloaded signature classes when method resolution takes place. MethodHandle resolution took a different route and eagerly resolves signature classes instead (see `java.lang.invoke.MemberName$Factory::resolve` and `sun.invoke.util.VerifyAccess::isTypeVisible` for details). 
> 
> There's a micro-optimization which bypasses eager resolution for `java.*` classes. The downside is that `java.*` signature classes can show up as unloaded. It manifests as inlining failures during JIT-compilation and may cause severe performance issues.
> 
> Proposed fix removes the aforementioned special case logic during `MethodHandle` resolution. 
> 
> In some cases it may slow down `MethodHandle` construction a bit (e.g., when repeatedly constructing `DirectMethodHandle`s with lots of arguments), but `MethodHandle` construction step is not performance critical.  
> 
> Testing: hs-tier1 - hs-tier4

Class loading triggered by `Class.forName()` call is at the core of `isTypeVisible`. (The rest is fast path checks.) It's what makes `isTypeVisible` query idempotent. 

I can definitely name it differently (e.g, `ensureTypeVisible`), but making a separate class loading pass across signature classes doesn't make much sense.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19319#issuecomment-2123160245

From sviswanathan at openjdk.org  Tue May 21 18:41:11 2024
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Tue, 21 May 2024 18:41:11 GMT
Subject: RFR: 8320448: Accelerate IndexOf using AVX2 [v20]
In-Reply-To: <zveo9CR_AqXFJWd23RU784fOfMEHg13VDMrD-KDtVWw=.e3036047-55dd-4584-bd9a-6de1e79c1bbd@github.com>
References: <uWi4QxH31hL93771gkl_GgvP0m84IRSoR_1Yi8hD17E=.bc6ed458-7081-4c3f-9348-f59358fa05a4@github.com>
 <zveo9CR_AqXFJWd23RU784fOfMEHg13VDMrD-KDtVWw=.e3036047-55dd-4584-bd9a-6de1e79c1bbd@github.com>
Message-ID: <2y8TuEb98PH5hxKQAxPdnPfuqqkDmGDmHxS6byTZoas=.7c1f9bc9-75c6-4057-8b74-35cb1a086509@github.com>

On Fri, 17 May 2024 23:47:45 GMT, Scott Gibbons <sgibbons at openjdk.org> wrote:

>> Re-write the IndexOf code without the use of the pcmpestri instruction, only using AVX2 instructions.  This change accelerates String.IndexOf on average 1.3x for AVX2.  The benchmark numbers:
>> 
>> 
>> Benchmark	                                               Score		Latest		
>> StringIndexOf.advancedWithMediumSub   343.573		317.934		0.925375393x
>> StringIndexOf.advancedWithShortSub1	  1039.081		1053.96		1.014319384x
>> StringIndexOf.advancedWithShortSub2	      55.828		110.541		1.980027943x
>> StringIndexOf.constantPattern	                9.361		11.906		1.271872663x
>> StringIndexOf.searchCharLongSuccess	        4.216		4.218		1.000474383x
>> StringIndexOf.searchCharMediumSuccess	3.133		3.216		1.02649218x
>> StringIndexOf.searchCharShortSuccess	3.76		        3.761		1.000265957x
>> StringIndexOf.success	                                9.186		9.713		1.057369911x
>> StringIndexOf.successBig	                      14.341		46.343		3.231504079x
>> StringIndexOfChar.latin1_AVX2_String	  6220.918		12154.52		1.953814533x
>> StringIndexOfChar.latin1_AVX2_char	  5503.556		5540.044		1.006629895x
>> StringIndexOfChar.latin1_SSE4_String	  6978.854		6818.689		0.977049957x
>> StringIndexOfChar.latin1_SSE4_char	  5657.499		5474.624		0.967675646x
>> StringIndexOfChar.latin1_Short_String	  7132.541		6863.359		0.962260014x
>> StringIndexOfChar.latin1_Short_char	16013.389	      16162.437		1.009307711x
>> StringIndexOfChar.latin1_mixed_String	  7386.123	      14771.622		1.999915517x
>> StringIndexOfChar.latin1_mixed_char	  9901.671		9782.245		0.987938803
>
> Scott Gibbons has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Addressing lots of comments.  Interim commit.

src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 4648:

> 4646:     vpxor(vec1, vec2);
> 4647: 
> 4648:     vptest(vec1, vec1);

These should be only 128 bit:
   pxor(vec1, vec2);
   ptest(vec1, vec1);

src/hotspot/cpu/x86/stubGenerator_x86_64_string.cpp line 1351:

> 1349:   assert_different_registers(needle, needleVal);
> 1350: 
> 1351:   bool isLL = (ae == StrIntrinsicNode::LL);

isLL not used in this function.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1608732591
PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1605624430

From aturbanov at openjdk.org  Tue May 21 19:58:05 2024
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Tue, 21 May 2024 19:58:05 GMT
Subject: RFR: 8305457: Implement java.io.IO [v10]
In-Reply-To: <5di7ye6tSNpauiTtHGwGI7kFG-iWeKpbWGEOXRK88ag=.fcfb14fd-53d3-4c4c-b774-3660cf6495bb@github.com>
References: <w2msiw_qaMEIJS3s9D4bg8pFbz5WIF0KdP6Mm-XFjLI=.85b2020b-8c46-4bac-8a69-4975b068f2ff@github.com>
 <5di7ye6tSNpauiTtHGwGI7kFG-iWeKpbWGEOXRK88ag=.fcfb14fd-53d3-4c4c-b774-3660cf6495bb@github.com>
Message-ID: <d4jnrspQ7DJha26nUJw-aKFQkD0cq8Jj4VJI8LKLC-k=.5c34b3c9-7c4c-4bcf-9223-986c39bafcaa@github.com>

On Tue, 21 May 2024 15:44:18 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Please review this PR which introduces the `java.io.IO` top-level class and three methods to `java.io.Console` for [Implicitly Declared Classes and Instance Main Methods (Third Preview)].
>> 
>> This PR has been obtained as `git merge --squash` of a now obsolete [draft PR].
>> 
>> [Implicitly Declared Classes and Instance Main Methods (Third Preview)]: https://bugs.openjdk.org/browse/JDK-8323335
>> [draft PR]: https://github.com/openjdk/jdk/pull/18921
>
> Pavel Rappo has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 20 commits:
> 
>  - Add diagnostic output
>  - Use "expect" that was found
>  - Merge branch 'master' into 8305457-Implement-java.io.IO
>    
>    # Conflicts:
>    #	src/java.base/share/classes/java/io/ProxyingConsole.java
>    #	src/java.base/share/classes/jdk/internal/io/JdkConsole.java
>    #	src/java.base/share/classes/jdk/internal/io/JdkConsoleImpl.java
>    #	src/jdk.internal.le/share/classes/jdk/internal/org/jline/JdkConsoleProviderImpl.java
>    #	src/jdk.jshell/share/classes/jdk/jshell/execution/impl/ConsoleImpl.java
>  - Escape prompt
>  - Merge branch 'master' into 8305457-Implement-java.io.IO
>  - Clarify input charset
>  - Make IO final
>  - Fix System.console().readln(null) in jshell
>    
>    Without it, jshell hangs on me. Will think of a test.
>  - Fix typo
>  - Merge branch 'master' into 8305457-Implement-java.io.IO
>  - ... and 10 more: https://git.openjdk.org/jdk/compare/b92bd671...809e98e0

src/java.base/share/classes/jdk/internal/io/JdkConsoleImpl.java line 78:

> 76:         String line = null;
> 77:         synchronized (writeLock) {
> 78:             synchronized(readLock) {

Suggestion:

            synchronized (readLock) {

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19112#discussion_r1608882590

From jvernee at openjdk.org  Tue May 21 20:17:02 2024
From: jvernee at openjdk.org (Jorn Vernee)
Date: Tue, 21 May 2024 20:17:02 GMT
Subject: RFR: 8332547: Unloaded signature classes in DirectMethodHandles
In-Reply-To: <QNXNxP3DEo9d4wqp3Af93Rg5D_zTbdtWDbPQ6dC3p2k=.cffa3736-0c7d-421d-b7b1-cbb0b7aa24e7@github.com>
References: <LAJeY7XRSMrz6Sg6TeIOkqZm1uRJbIxhP_PcZdI13JQ=.5790e229-84fd-4282-9769-6613dbb3254a@github.com>
 <QNXNxP3DEo9d4wqp3Af93Rg5D_zTbdtWDbPQ6dC3p2k=.cffa3736-0c7d-421d-b7b1-cbb0b7aa24e7@github.com>
Message-ID: <vmW1VnaMfGWrfxuQfOpDjbYBExhlEq-WNkV2SX6ggXc=.870503d8-8b8d-40a7-9a14-430e7ab2521f@github.com>

On Tue, 21 May 2024 18:02:45 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

> I can definitely name it differently (e.g, ensureTypeVisible), but making a separate class loading pass across signature classes doesn't make much sense.

Ok, in that case I suggest also renaming `MemberName::checkForTypeAlias`, maybe to `ensureTypeVisible` as well.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19319#issuecomment-2123368855

From joehw at openjdk.org  Tue May 21 20:28:37 2024
From: joehw at openjdk.org (Joe Wang)
Date: Tue, 21 May 2024 20:28:37 GMT
Subject: RFR: 8330542: Add jaxp-strict.properties in preparation for a
 stricter default configuration [v12]
In-Reply-To: <v1bAYKgH9zfooXpvnBw4Vu2TIqHuKqqtSmgB0hiNp-Q=.31661a99-ecfc-4a05-8045-67b5f680db60@github.com>
References: <v1bAYKgH9zfooXpvnBw4Vu2TIqHuKqqtSmgB0hiNp-Q=.31661a99-ecfc-4a05-8045-67b5f680db60@github.com>
Message-ID: <Xhrtr31Mwi_NwgwShsUonMQBkOITdwllZAmedF_k1Og=.26242046-84a7-4da7-ae88-901b794df2dc@github.com>

> Add two sample configuration files:
> 
>   jaxp-strict.properties: used to set strict configuration, stricter than jaxp.properties in previous versions such as JDK 22
> 
>>   jaxp-compat.properties: used to regain compatibility from any more restricted configuration than previous versions such as JDK 22
> 
> Updated on 5/16/2024
> 
> Design change:
> The design is changed to include in the JDK two configuration files that are the default jaxp.properties and jaxp-strict.properties, instead of three, dropping jaxp-compat.properties.
> 
> Updated on 5/18/2024
> 
> Withdraw changes to jaxp.properties. The original idea was to match jaxp-strict.properties with regard to the properties. However, that change impact the configuration process, resulting in tests that verify the process to fail.

Joe Wang has updated the pull request incrementally with one additional commit since the last revision:

  add a note to module-info

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/18831/files
  - new: https://git.openjdk.org/jdk/pull/18831/files/55a86db3..dd7f6239

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18831&range=11
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18831&range=10-11

  Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/18831.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18831/head:pull/18831

PR: https://git.openjdk.org/jdk/pull/18831

From smarks at openjdk.org  Tue May 21 20:29:06 2024
From: smarks at openjdk.org (Stuart Marks)
Date: Tue, 21 May 2024 20:29:06 GMT
Subject: RFR: 8332084: Ensure JdkConsoleImpl.restoreEcho visibility in a
 shutdown hook [v7]
In-Reply-To: <SUFrRXJbSbs5MQHMcU0QJmGLI2fmNW0GkjpqzzTJoXo=.01323fc3-02ac-4a44-b4eb-d4697c5e336c@github.com>
References: <9JTWc3FRpfbILlSHlmIU_dL5IE69RTxnSIAOdIte15I=.5854a48f-21d7-42c9-adb7-5e3ed40d1211@github.com>
 <SUFrRXJbSbs5MQHMcU0QJmGLI2fmNW0GkjpqzzTJoXo=.01323fc3-02ac-4a44-b4eb-d4697c5e336c@github.com>
Message-ID: <FEvl-X_s789xHTTh2SVSi0IFdzducr5hVkx7_nnVj9w=.63bb4d02-f286-4058-8595-64c5385cbf97@github.com>

On Mon, 20 May 2024 17:49:29 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Making sure `restoreEcho` correctly reflects the state in the shutdown thread, which differs from the application's thread that issues the `readPassword()` method.
>
> Naoto Sato 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-8332084-restoreEcho-readLock
>  - Merge branch 'master' into JDK-8332084-restoreEcho-readLock
>  - copyright year
>  - Merge branch 'master' into JDK-8332084-restoreEcho-readLock
>  - get/setEcho()
>  - Addresses a review comment
>  - Replaced another unused exception with _
>  - Update src/java.base/share/classes/jdk/internal/io/JdkConsoleImpl.java
>    
>    Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com>
>  - initial commit

OK, I went over all this again, and it looks pretty good, though there's a potential risk.

In the old code, the `restoreEcho` variable was usually false, and it was only true while `readPassword` was running, which then set it back to false. The shutdown hook would therefore almost always see a value of false and decide to do nothing.

In the new code, the `restoreEcho` variable stores the initial state of the echo status, which is usually true. We don't keep track of whether readPassword() has set the echo status, since that leads to mutable state and race conditions etc. as discussed previously. The only time the shutdown hook doesn't set the echo status is if the initial echo status of the terminal is false, which probably almost never occurs. Thus, the shutdown hook almost always sets the echo status to true regardless of whether it's necessary to do so.

I'm not concerned about the amount of work the shutdown hook is doing. I'm wondering if there's a possibility that setting the terminal modes almost every time on exit is the right thing. It might block, potentially hanging the VM shutdown. ... Reading further, the case I was concerned about was if somebody runs a Java program from a shell and then puts it into the background. Then the JVM shuts down and the shutdown hook tries to enable echo. Does this work, or does it cause the process to be stopped with SIGTTIN or something? And if it works, would it restore echo immediately, even if say a foreground process were reading a password?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19184#issuecomment-2123385605

From matsaave at openjdk.org  Tue May 21 21:12:10 2024
From: matsaave at openjdk.org (Matias Saavedra Silva)
Date: Tue, 21 May 2024 21:12:10 GMT
Subject: RFR: 8332340: Add JavacBench as a test case for CDS [v3]
In-Reply-To: <JyXZjtHrBwxBbYTgyKfne732jbC7gCNzwgPDKWHAxAQ=.3b8e48bb-3bfa-4b85-88d4-65cee20a5cec@github.com>
References: <xqD4PeVZfIAKzywbLnjGZMFh36YSqXNolZkTgh1Vk6E=.44db7c57-64c1-4912-96e1-e61848312ccb@github.com>
 <JyXZjtHrBwxBbYTgyKfne732jbC7gCNzwgPDKWHAxAQ=.3b8e48bb-3bfa-4b85-88d4-65cee20a5cec@github.com>
Message-ID: <9-7g3_XzveiMKyADlDCbZKOAH1m4cx6v3Qdz1Ob-XgY=.8aef78ae-af2b-460a-9edb-dc06318547a9@github.com>

On Mon, 20 May 2024 17:24:22 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> JavacBench is a test program that compiles 90 Java source files. It uses a fair amount of invokedynamic callsites, so it's good for testing CDS support for indy and lambda expressions.
>> 
>> This test was first integrated into the [leyden](https://github.com/openjdk/leyden/tree/premain) repo. Hence some of the files have copyrights in 2023.
>
> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
> 
>   @calvinccheung comments

LGTM, and thanks for the new utilities! That should make writing CDS tests a lot easier. I have a few style considerations but you can take them or leave them.

test/lib/jdk/test/lib/cds/CDSAppTester.java line 98:

> 96:     }
> 97: 
> 98:     private final String name;

Could these fields and the constructor be moved to the top of the class?

test/lib/jdk/test/lib/cds/CDSAppTester.java line 147:

> 145:     }
> 146: 
> 147:     private OutputAnalyzer dumpStaticArchive() throws Exception {

The code from 156 to 162 is repeated 3 times here, is it worth making another function for this?

-------------

Marked as reviewed by matsaave (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19256#pullrequestreview-2069620296
PR Review Comment: https://git.openjdk.org/jdk/pull/19256#discussion_r1608953801
PR Review Comment: https://git.openjdk.org/jdk/pull/19256#discussion_r1608949352

From prappo at openjdk.org  Tue May 21 21:19:05 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Tue, 21 May 2024 21:19:05 GMT
Subject: RFR: 8305457: Implement java.io.IO [v10]
In-Reply-To: <d4jnrspQ7DJha26nUJw-aKFQkD0cq8Jj4VJI8LKLC-k=.5c34b3c9-7c4c-4bcf-9223-986c39bafcaa@github.com>
References: <w2msiw_qaMEIJS3s9D4bg8pFbz5WIF0KdP6Mm-XFjLI=.85b2020b-8c46-4bac-8a69-4975b068f2ff@github.com>
 <5di7ye6tSNpauiTtHGwGI7kFG-iWeKpbWGEOXRK88ag=.fcfb14fd-53d3-4c4c-b774-3660cf6495bb@github.com>
 <d4jnrspQ7DJha26nUJw-aKFQkD0cq8Jj4VJI8LKLC-k=.5c34b3c9-7c4c-4bcf-9223-986c39bafcaa@github.com>
Message-ID: <W-zrQzJFDXvKseP4RA74LCtJY51UYJDYQaL3DhNKuBo=.46966752-e50a-41a8-9bd5-21eec2f759fb@github.com>

On Tue, 21 May 2024 19:55:22 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

>> Pavel Rappo has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 20 commits:
>> 
>>  - Add diagnostic output
>>  - Use "expect" that was found
>>  - Merge branch 'master' into 8305457-Implement-java.io.IO
>>    
>>    # Conflicts:
>>    #	src/java.base/share/classes/java/io/ProxyingConsole.java
>>    #	src/java.base/share/classes/jdk/internal/io/JdkConsole.java
>>    #	src/java.base/share/classes/jdk/internal/io/JdkConsoleImpl.java
>>    #	src/jdk.internal.le/share/classes/jdk/internal/org/jline/JdkConsoleProviderImpl.java
>>    #	src/jdk.jshell/share/classes/jdk/jshell/execution/impl/ConsoleImpl.java
>>  - Escape prompt
>>  - Merge branch 'master' into 8305457-Implement-java.io.IO
>>  - Clarify input charset
>>  - Make IO final
>>  - Fix System.console().readln(null) in jshell
>>    
>>    Without it, jshell hangs on me. Will think of a test.
>>  - Fix typo
>>  - Merge branch 'master' into 8305457-Implement-java.io.IO
>>  - ... and 10 more: https://git.openjdk.org/jdk/compare/b92bd671...809e98e0
>
> src/java.base/share/classes/jdk/internal/io/JdkConsoleImpl.java line 78:
> 
>> 76:         String line = null;
>> 77:         synchronized (writeLock) {
>> 78:             synchronized(readLock) {
> 
> Suggestion:
> 
>             synchronized (readLock) {

Sorry, but no. It would be inconsistent with the rest of the file, which for whatever reason (copy-paste?) does not use whitespace between `synchronized` and `(readLock)`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19112#discussion_r1608962852

From mark.yagnatinsky at barclays.com  Tue May 21 22:27:28 2024
From: mark.yagnatinsky at barclays.com (mark.yagnatinsky at barclays.com)
Date: Tue, 21 May 2024 22:27:28 +0000
Subject: do I need to subscribe to this list in order to post?
Message-ID: <CH3PR12MB761911EA48C60FD146CAC4D0F9EA2@CH3PR12MB7619.namprd12.prod.outlook.com>



This message is for information purposes only. It is not a recommendation, advice, offer or solicitation to buy or sell a product or service, nor an official confirmation of any transaction. It is directed at persons who are professionals and is intended for the recipient(s) only. It is not directed at retail customers. This message is subject to the terms at: https://www.ib.barclays/disclosures/web-and-email-disclaimer.html. 

For important disclosures, please see: https://www.ib.barclays/disclosures/sales-and-trading-disclaimer.html regarding marketing commentary from Barclays Sales and/or Trading desks, who are active market participants; https://www.ib.barclays/disclosures/barclays-global-markets-disclosures.html regarding our standard terms for Barclays Investment Bank where we trade with you in principal-to-principal wholesale markets transactions; and in respect to Barclays Research, including disclosures relating to specific issuers, see: http://publicresearch.barclays.com.
__________________________________________________________________________________ 
If you are incorporated or operating in Australia, read these important disclosures: https://www.ib.barclays/disclosures/important-disclosures-asia-pacific.html.
__________________________________________________________________________________
For more details about how we use personal information, see our privacy notice: https://www.ib.barclays/disclosures/personal-information-use.html. 
__________________________________________________________________________________
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240521/2fd2c73f/attachment-0001.htm>

From smarks at openjdk.org  Tue May 21 22:44:02 2024
From: smarks at openjdk.org (Stuart Marks)
Date: Tue, 21 May 2024 22:44:02 GMT
Subject: RFR: 8331876: JFR: Move file read and write events to java.base
 [v3]
In-Reply-To: <6jsW4CF22T2JlhtRKmS04_KXxr-aJxIiMyFwzWlM-pU=.b27ed11e-bd19-4823-a795-7f578b812d56@github.com>
References: <DDe0bKCC86AawVl7RylZ74uvvLBr2Zljpkcmxx1_WEU=.61cc10c6-b635-42dd-a850-b32ae1d68585@github.com>
 <SejX7NAvWNjrhDEN8uDf4oikQDBRclWXDg1fN5FCpkc=.7de48c6f-0af2-4bf4-a743-6e173d950d52@github.com>
 <DgjIOZTfztdSEeODuNZw5MmzsiohA82hhllWCceyPyU=.7bda36a1-e26d-4d7e-822a-e443d3cbc0df@github.com>
 <khrP38H7DBIyftQZtZt0CRXeH1ZkpOCjiRNvFTs3LSI=.fd62aba9-5153-4521-84e4-241b8a352720@github.com>
 <zGenHEqjgT6f_P_VtwfKbmzBeQoArW8MHwfAa6uVGVY=.eb912b9b-3f02-4cac-8d96-e1bdbaaea2b8@github.com>
 <wluFwF2Nhgjz-yspRYtEXIJ6jEiWm9imPd6CZlwYt6Y=.991f1032-1f5a-4762-8e5b-edc74d513e88@github.com>
 <UBAcBKmhmCkeevxrteAThIEvD8YNBWFrUa_qffEng14=.c50dbe19-3465-4385-9fe4-8c284a0b116e@github.com>
 <hCLpZtC0PzTKDqSFbBympxsb4A3Sta3G3N2Ec8JfsSs=.2c57b9ff-e81d-42a0-8384-3663b14192ca@github.com>
 <6jsW4CF22T2JlhtRKmS04_KXxr-aJxIiMyFwzWlM-pU=.b27ed11e-bd19-4823-a795-7f578b812d56@github.com>
Message-ID: <HFfB0s4iYLwcSMYeKcsJvszuA0pTj1uQ-duKsmfHX4I=.a021f0d1-0e33-4a2d-a7b4-327143611a29@github.com>

On Fri, 17 May 2024 09:26:03 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> My main concern here is the addition of clutter (checking two flags, and creating two levels of nested "impl" methods) at every call site. We may need to rearrange our internal API for JFR (jdk.internal.events) in order to clean up the call sites without loading additional classes unnecessarily.
>> 
>> I think the main performance comparison to make is the impact on startup time of loading the additional FileReadEvent class. That is, to compare the startup time of the baseline with code that loads the FileReadEvent class, with JFR disabled in both cases. I don't know how to do this. Anyway, if loading of additional classes imposes unacceptable overhead, then that justifies doing more work to avoid it. That's separate from whether adding the `jfrTracing` flag as done in this PR is an effective way to do it.
>
> I think `if (jfrTracing && FileReadEvent.enabled())` would be more readable as it would avoid calling going through the traceXXX methods when the flag is enabled but the specific event is not enabled.

Collapsing the extra layer of methods and combining the test into

    if (jfrTracing && FileReadEvent.enabled())

would indeed keep things a little neater.

I'm still questioning the need for `jfrTracing` at all. There's the matter of how this boolean gets set and unset, and whether this is done in a way that comports with the memory model. Setting this aside, is the only benefit that it avoids loading an extra class at JVM startup time (without JFR)? In this case that would be the `FileReadEvent` class, which is the stub class in `jdk.internal.event`. Wouldn't this class be in the CDS archive, making it not worth the effort of bringing up this new `jfrTracing` mechanism simply to avoid loading it unnecessarily?

I observe that in JDK 22 some (but not all) of the event classes in `jdk.internal.event` seem to be present in the CDS archive. These include various virtual thread events.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19129#discussion_r1609024695

From naoto at openjdk.org  Tue May 21 22:51:14 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 21 May 2024 22:51:14 GMT
Subject: RFR: 8332084: Ensure JdkConsoleImpl.restoreEcho visibility in a
 shutdown hook [v8]
In-Reply-To: <9JTWc3FRpfbILlSHlmIU_dL5IE69RTxnSIAOdIte15I=.5854a48f-21d7-42c9-adb7-5e3ed40d1211@github.com>
References: <9JTWc3FRpfbILlSHlmIU_dL5IE69RTxnSIAOdIte15I=.5854a48f-21d7-42c9-adb7-5e3ed40d1211@github.com>
Message-ID: <s5UWj1VnzkiOOPZk8YMuJrbyAoMx-pVeV14Cx5UDZeE=.495ed70f-3dd5-4c4d-a616-0f20fcb92907@github.com>

> Making sure `restoreEcho` correctly reflects the state in the shutdown thread, which differs from the application's thread that issues the `readPassword()` method.

Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:

  Used a dedicate lock for restoreEcho

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19184/files
  - new: https://git.openjdk.org/jdk/pull/19184/files/e58fbdcd..f69f747a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19184&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19184&range=06-07

  Stats: 66 lines in 3 files changed: 15 ins; 35 del; 16 mod
  Patch: https://git.openjdk.org/jdk/pull/19184.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19184/head:pull/19184

PR: https://git.openjdk.org/jdk/pull/19184

From naoto at openjdk.org  Tue May 21 22:58:02 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 21 May 2024 22:58:02 GMT
Subject: RFR: 8332084: Ensure JdkConsoleImpl.restoreEcho visibility in a
 shutdown hook [v8]
In-Reply-To: <s5UWj1VnzkiOOPZk8YMuJrbyAoMx-pVeV14Cx5UDZeE=.495ed70f-3dd5-4c4d-a616-0f20fcb92907@github.com>
References: <9JTWc3FRpfbILlSHlmIU_dL5IE69RTxnSIAOdIte15I=.5854a48f-21d7-42c9-adb7-5e3ed40d1211@github.com>
 <s5UWj1VnzkiOOPZk8YMuJrbyAoMx-pVeV14Cx5UDZeE=.495ed70f-3dd5-4c4d-a616-0f20fcb92907@github.com>
Message-ID: <d3USQPxKmY5tDy01k9LsZYZZSTv-SYFcXVFz7FOoNGk=.a638cf74-b9a9-4b84-9321-2eb58e010341@github.com>

On Tue, 21 May 2024 22:51:14 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Making sure `restoreEcho` correctly reflects the state in the shutdown thread, which differs from the application's thread that issues the `readPassword()` method.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Used a dedicate lock for restoreEcho

Based on an internal discussion regarding Stuart's above comment, I changed the `restoreEcho` field back to the original. Instead of making it volatile, synchronizing it with a dedicated lock would ensure visibility and atomic status updates (no races).

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19184#issuecomment-2123561717

From jlu at openjdk.org  Tue May 21 23:01:24 2024
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 21 May 2024 23:01:24 GMT
Subject: RFR: 8331342: Convert Base64 tests to JUnit
Message-ID: <9b7rZt1fLHoDtfpK78fcKL2EVEh_HocxFC4j5_tSXx4=.00a33121-882b-4198-9415-271eac5f9c51@github.com>

Please review this test-only clean up PR which converts the java.util.Base64 tests to run under JUnit.

In general, this allows for the tests to run independently, separates the data providers from the tests, as well being able to utilize the built in JUnit utility test methods to reduce boilerplate testing code.

-------------

Commit messages:
 - Additional clarifying comments
 - convert TestBase64.java
 - convert TestBase64Golden.java
 - convert Base64GetEncoderTest.java

Changes: https://git.openjdk.org/jdk/pull/19337/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19337&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8331342
  Stats: 823 lines in 3 files changed: 257 ins; 336 del; 230 mod
  Patch: https://git.openjdk.org/jdk/pull/19337.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19337/head:pull/19337

PR: https://git.openjdk.org/jdk/pull/19337

From naoto at openjdk.org  Tue May 21 23:13:16 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 21 May 2024 23:13:16 GMT
Subject: RFR: 8332161: Test restoring echo in the Console implementation
 (java.base) [v2]
In-Reply-To: <aSxuvnY7ghWwuDuegcWKJKlL_3KUCdIS_jHgTsn43ow=.b4d2e8d9-ffea-4318-9004-27b18298436e@github.com>
References: <aSxuvnY7ghWwuDuegcWKJKlL_3KUCdIS_jHgTsn43ow=.b4d2e8d9-ffea-4318-9004-27b18298436e@github.com>
Message-ID: <q7ybgILf1fVc4OogtLpFxvV1o9ozSxpfH0ORHfS42r0=.5e57104c-1df8-4742-9362-4baf013205e1@github.com>

> This test intends to verify the behavior of JdkConsole for the java.base module, wrt restoring the echo. The test assumes the internal methods that sets/gets the echo status of the platform.

Naoto Sato 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:

 - leftover typo
 - get/setEcho() -> echo()
 - Merge branch 'JDK-8332084-restoreEcho-readLock' into JDK-8332161-restoreEcho-Test
 - Merge branch 'JDK-8332084-restoreEcho-readLock' into JDK-8332161-restoreEcho-Test
 - initial commit

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19315/files
  - new: https://git.openjdk.org/jdk/pull/19315/files/58151807..ad4a4e47

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19315&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19315&range=00-01

  Stats: 34602 lines in 391 files changed: 29274 ins; 4096 del; 1232 mod
  Patch: https://git.openjdk.org/jdk/pull/19315.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19315/head:pull/19315

PR: https://git.openjdk.org/jdk/pull/19315

From sgibbons at openjdk.org  Wed May 22 02:07:36 2024
From: sgibbons at openjdk.org (Scott Gibbons)
Date: Wed, 22 May 2024 02:07:36 GMT
Subject: RFR: 8320448: Accelerate IndexOf using AVX2 [v21]
In-Reply-To: <uWi4QxH31hL93771gkl_GgvP0m84IRSoR_1Yi8hD17E=.bc6ed458-7081-4c3f-9348-f59358fa05a4@github.com>
References: <uWi4QxH31hL93771gkl_GgvP0m84IRSoR_1Yi8hD17E=.bc6ed458-7081-4c3f-9348-f59358fa05a4@github.com>
Message-ID: <xHMj1UG7xkoGfZs6yPKaAKJ099gpVQCaP5JHWt6t92M=.42cf9597-ff30-4c84-81b5-73dec3c42a78@github.com>

> Re-write the IndexOf code without the use of the pcmpestri instruction, only using AVX2 instructions.  This change accelerates String.IndexOf on average 1.3x for AVX2.  The benchmark numbers:
> 
> 
> Benchmark	                                               Score		Latest		
> StringIndexOf.advancedWithMediumSub   343.573		317.934		0.925375393x
> StringIndexOf.advancedWithShortSub1	  1039.081		1053.96		1.014319384x
> StringIndexOf.advancedWithShortSub2	      55.828		110.541		1.980027943x
> StringIndexOf.constantPattern	                9.361		11.906		1.271872663x
> StringIndexOf.searchCharLongSuccess	        4.216		4.218		1.000474383x
> StringIndexOf.searchCharMediumSuccess	3.133		3.216		1.02649218x
> StringIndexOf.searchCharShortSuccess	3.76		        3.761		1.000265957x
> StringIndexOf.success	                                9.186		9.713		1.057369911x
> StringIndexOf.successBig	                      14.341		46.343		3.231504079x
> StringIndexOfChar.latin1_AVX2_String	  6220.918		12154.52		1.953814533x
> StringIndexOfChar.latin1_AVX2_char	  5503.556		5540.044		1.006629895x
> StringIndexOfChar.latin1_SSE4_String	  6978.854		6818.689		0.977049957x
> StringIndexOfChar.latin1_SSE4_char	  5657.499		5474.624		0.967675646x
> StringIndexOfChar.latin1_Short_String	  7132.541		6863.359		0.962260014x
> StringIndexOfChar.latin1_Short_char	16013.389	      16162.437		1.009307711x
> StringIndexOfChar.latin1_mixed_String	  7386.123	      14771.622		1.999915517x
> StringIndexOfChar.latin1_mixed_char	  9901.671		9782.245		0.987938803

Scott Gibbons has updated the pull request incrementally with one additional commit since the last revision:

  Fixed CI compiles; re-factor UL processing

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/16753/files
  - new: https://git.openjdk.org/jdk/pull/16753/files/9a861979..38868a35

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16753&range=20
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16753&range=19-20

  Stats: 570 lines in 2 files changed: 327 ins; 158 del; 85 mod
  Patch: https://git.openjdk.org/jdk/pull/16753.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16753/head:pull/16753

PR: https://git.openjdk.org/jdk/pull/16753

From sgibbons at openjdk.org  Wed May 22 02:07:36 2024
From: sgibbons at openjdk.org (Scott Gibbons)
Date: Wed, 22 May 2024 02:07:36 GMT
Subject: RFR: 8320448: Accelerate IndexOf using AVX2 [v20]
In-Reply-To: <zveo9CR_AqXFJWd23RU784fOfMEHg13VDMrD-KDtVWw=.e3036047-55dd-4584-bd9a-6de1e79c1bbd@github.com>
References: <uWi4QxH31hL93771gkl_GgvP0m84IRSoR_1Yi8hD17E=.bc6ed458-7081-4c3f-9348-f59358fa05a4@github.com>
 <zveo9CR_AqXFJWd23RU784fOfMEHg13VDMrD-KDtVWw=.e3036047-55dd-4584-bd9a-6de1e79c1bbd@github.com>
Message-ID: <2K6GTqVka0-FS4NQcZ6z6izsDZVC1DuN1GuzzpkLlZk=.3853f424-d8fc-4c65-827d-a7abb321f38e@github.com>

On Fri, 17 May 2024 23:47:45 GMT, Scott Gibbons <sgibbons at openjdk.org> wrote:

>> Re-write the IndexOf code without the use of the pcmpestri instruction, only using AVX2 instructions.  This change accelerates String.IndexOf on average 1.3x for AVX2.  The benchmark numbers:
>> 
>> 
>> Benchmark	                                               Score		Latest		
>> StringIndexOf.advancedWithMediumSub   343.573		317.934		0.925375393x
>> StringIndexOf.advancedWithShortSub1	  1039.081		1053.96		1.014319384x
>> StringIndexOf.advancedWithShortSub2	      55.828		110.541		1.980027943x
>> StringIndexOf.constantPattern	                9.361		11.906		1.271872663x
>> StringIndexOf.searchCharLongSuccess	        4.216		4.218		1.000474383x
>> StringIndexOf.searchCharMediumSuccess	3.133		3.216		1.02649218x
>> StringIndexOf.searchCharShortSuccess	3.76		        3.761		1.000265957x
>> StringIndexOf.success	                                9.186		9.713		1.057369911x
>> StringIndexOf.successBig	                      14.341		46.343		3.231504079x
>> StringIndexOfChar.latin1_AVX2_String	  6220.918		12154.52		1.953814533x
>> StringIndexOfChar.latin1_AVX2_char	  5503.556		5540.044		1.006629895x
>> StringIndexOfChar.latin1_SSE4_String	  6978.854		6818.689		0.977049957x
>> StringIndexOfChar.latin1_SSE4_char	  5657.499		5474.624		0.967675646x
>> StringIndexOfChar.latin1_Short_String	  7132.541		6863.359		0.962260014x
>> StringIndexOfChar.latin1_Short_char	16013.389	      16162.437		1.009307711x
>> StringIndexOfChar.latin1_mixed_String	  7386.123	      14771.622		1.999915517x
>> StringIndexOfChar.latin1_mixed_char	  9901.671		9782.245		0.987938803
>
> Scott Gibbons has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Addressing lots of comments.  Interim commit.

Comment on behalf of @sviswa7 : Unclear whether `size` in `byte_compare_helper` is intended to be in bytes or in elements.  Please check its consistency.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/16753#issuecomment-2123736900

From sgibbons at openjdk.org  Wed May 22 02:07:36 2024
From: sgibbons at openjdk.org (Scott Gibbons)
Date: Wed, 22 May 2024 02:07:36 GMT
Subject: RFR: 8320448: Accelerate IndexOf using AVX2 [v20]
In-Reply-To: <2y8TuEb98PH5hxKQAxPdnPfuqqkDmGDmHxS6byTZoas=.7c1f9bc9-75c6-4057-8b74-35cb1a086509@github.com>
References: <uWi4QxH31hL93771gkl_GgvP0m84IRSoR_1Yi8hD17E=.bc6ed458-7081-4c3f-9348-f59358fa05a4@github.com>
 <zveo9CR_AqXFJWd23RU784fOfMEHg13VDMrD-KDtVWw=.e3036047-55dd-4584-bd9a-6de1e79c1bbd@github.com>
 <2y8TuEb98PH5hxKQAxPdnPfuqqkDmGDmHxS6byTZoas=.7c1f9bc9-75c6-4057-8b74-35cb1a086509@github.com>
Message-ID: <JiENMQH5wAnD55EzGz0k7WOBOIiB38xlqJIpqI66_Z4=.9f7e2e82-eaab-4c25-8fbe-fe3cb3093cdd@github.com>

On Tue, 21 May 2024 18:03:41 GMT, Sandhya Viswanathan <sviswanathan at openjdk.org> wrote:

>> Scott Gibbons has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Addressing lots of comments.  Interim commit.
>
> src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 4648:
> 
>> 4646:     vpxor(vec1, vec2);
>> 4647: 
>> 4648:     vptest(vec1, vec1);
> 
> These should be only 128 bit:
>    pxor(vec1, vec2);
>    ptest(vec1, vec1);

Fixed

> src/hotspot/cpu/x86/stubGenerator_x86_64_string.cpp line 1351:
> 
>> 1349:   assert_different_registers(needle, needleVal);
>> 1350: 
>> 1351:   bool isLL = (ae == StrIntrinsicNode::LL);
> 
> isLL not used in this function.

Fixed

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1609164643
PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1609164578

From mark.yagnatinsky at barclays.com  Wed May 22 03:46:22 2024
From: mark.yagnatinsky at barclays.com (mark.yagnatinsky at barclays.com)
Date: Wed, 22 May 2024 03:46:22 +0000
Subject: stack overflow in regex engine
Message-ID: <CH3PR12MB76197D4ECC54728844CE705CF9EB2@CH3PR12MB7619.namprd12.prod.outlook.com>

(Sorry about my previous "do I need to subscribe?" email; in retrospect that was needless noise.)
The purpose of this email is twofold: first, inquire about the status of ticket filed a few years ago, and second to point out some non-obvious reasons why it might be slightly more serious than it seems.
The ticket is this one https://bugs.openjdk.org/browse/JDK-8260866 (stack overflow in regex matching quantified alternation)
The priority is listed as P4, which I guess means something like "medium" (more important than p5, but less than p3)
It also has a specific person assigned, which seems vaguely encouraging, but no updates at all in the years since it's been created, which seems less encouraging.
It was seemingly never once discussed on this mailing list, not even when it was first filed.
As an outsider, I'm not quite sure how to interpret all these various omens and turn them into guesses about its eventual fate.
Will it remain unfixed for another decade or two?  Will it be fixed in a few months, but then never backported to old versions?  Something else?  No one knows?

That concludes the status inquiry.  Now on to the advocacy.  Some bugs are annoying, but once you hit them, you can work around them by changing your code so it does not trigger the bug.
Note the phrase "your code" above.  This is much more awkward to do if the bug triggered by third-party code you got from maven central or something.
At that point your options are to either ask the third party library to work around it, or else fork the dependency (which is not well supported by mainstream build tools (or maybe I'm just using them wrong)).
In this case, regular expressions are so ubiquitous that the bug is quite plausibly more likely to be triggered by some third party dependency than by code you own.
That was the case for me today: after spending hours trying to track down a stack overflow error I found the offending regex in a third party library.
The good news is that for the kinds of inputs we need to handle, it is indeed easy to substitute a much simpler regex that would avoid the issue.
The bad news is that it's not my code, so I can't.  I could petition the maintainers of the library, but this is not great because:
First, maybe the version I'm on is not longer even supported, and newer versions are not compatible,
Second, it may take them a while to fix it, and third, it is wasteful (and inelegant) to have workarounds slowly percolate throughout the Java ecosystem instead of fixing the problem at the root.

The other annoying thing here is that even when you have "enough" stack space to avoid crashing, using it may not be quite "free".
For instance, project loom's foundational premise seems to be that "most threads have oversized stacks; we can have more threads if we start off with small stacks and grow them only when needed".
This would be false when the thread in question uses a regex with quantified alternation.
(Since many Loom threads will be based on the same Runnable, it's a pretty safe bet that if one of them uses this feature, many will, so you can't assume it will "average out".)
There are other reasons besides loom to be low on stack space; maybe you're using some crazy framework(s) that like(s) to have call stacks that are crazy deep.
Or maybe you're running with -Xss set pretty low.  Or you passed a small value for stack space to the Thread constructor.
Or maybe none of these things are true, but in most operating systems a thread stack costs "real" memory in proportion to its high-watermark, so even a SINGLE heavy regex in the lifetime of a thread is tantamount to a memory leak of hundreds of kilobytes.

Practicalities aside, I don't like it when code consumes "surprising" types of resources, or surprising amounts of them.
For instance, you wouldn't expect a sorting function to spawn threads behind your back, unless it was called "parallel sort" or something like that.
You wouldn't expect it to allocate multi-gigabyte arrays, nor to perform I/O.
Similarly, most functions need only O(1) stack space, so this tends to be the default assumption unless the docs explicitly call out "this thing might throw stack overflows at you so make sure you have plenty of stack space"
Some need a bit more... for instance, I would not be surprised if a regex need stack space in proportion to the depth of the parse tree of the regex.
But stack space in proportion to the length of the string being matched is the kind of thing that I'd hope gets called out in those @implNotes thingies, or better yet fixed.

Even people who know that regex matching can sometimes take exponential time may naively assume that regex matching would not consume O(n) stack space, where n is the input length.
What's worse, not only does it indeed consume stack space linear in the length of the input, but the constant hidden by the O() notation is itself pretty scary.
For instance, consider the regex that caused my troubles today:
https://github.com/apache/camel/blob/main/core/camel-support/src/main/java/org/apache/camel/support/ObjectHelper.java#L63
After getting rid of extra escaping and also double-escaping caused by java not having "raw" strings, we're left with this:
,(?!(?:[^(,]|[^)],[^)])+\))
(I find the above hard to read; the regex I would have replaced it with, if it had been "our" code is simply a single comma.)
Anyway, I tried creating a Scanner with the delimiter above and looping through all the tokens in the string that originally caused the crash.
I thought that perhaps it would work, since I had a simple example that does everything in main, but it also crashed.
Then I decided to play an alternating game where I trimmed the string until it stopped crashing, then lowered Xss by 64k and repeated.
Eventually, I got it crashing with a call stack well over 500 calls deep on a string less than a 128 characters long.
(The string was not hand-crafted; it was simply a prefix of the original string that caused the first crash I tracked down.)
The string in question had a mere five tokens, which is to say that it had just four commas.
It had no open or close parenthesis, so the entire negative lookahead assertion served as a giant no-op, at least when it wasn't crashing.
(Technically, the stack usage is linear in the length of the input AFTER the first comma, but the first comma was pretty early.)

Sorry if this email is poorly organized; I've already spent way too many hours on it (not even counting the debugging that prompted it) and I need to get some sleep now.

If anyone actually reads all or most of this, thank you.
Mark.

P.S. if anyone actually responds, thank you even more.

This message is for information purposes only. It is not a recommendation, advice, offer or solicitation to buy or sell a product or service, nor an official confirmation of any transaction. It is directed at persons who are professionals and is intended for the recipient(s) only. It is not directed at retail customers. This message is subject to the terms at: https://www.ib.barclays/disclosures/web-and-email-disclaimer.html. 

For important disclosures, please see: https://www.ib.barclays/disclosures/sales-and-trading-disclaimer.html regarding marketing commentary from Barclays Sales and/or Trading desks, who are active market participants; https://www.ib.barclays/disclosures/barclays-global-markets-disclosures.html regarding our standard terms for Barclays Investment Bank where we trade with you in principal-to-principal wholesale markets transactions; and in respect to Barclays Research, including disclosures relating to specific issuers, see: http://publicresearch.barclays.com.
__________________________________________________________________________________ 
If you are incorporated or operating in Australia, read these important disclosures: https://www.ib.barclays/disclosures/important-disclosures-asia-pacific.html.
__________________________________________________________________________________
For more details about how we use personal information, see our privacy notice: https://www.ib.barclays/disclosures/personal-information-use.html. 
__________________________________________________________________________________
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240522/625b0e2e/attachment-0001.htm>

From thartmann at openjdk.org  Wed May 22 05:03:15 2024
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Wed, 22 May 2024 05:03:15 GMT
Subject: RFR: 8329538: Accelerate P256 on x86_64 using Montgomery intrinsic
 [v12]
In-Reply-To: <kuMyLYSd4dOC7qBbk9G7ZtvntC1U3FR5V35jLP1qHtQ=.e1459498-2ab5-48b1-8490-25dc94d49b1d@github.com>
References: <hanRK4GzOkFV8kG1gZRy8Br53trw4-Tu6G6uO8nsFuk=.d5bf723a-f683-4759-ac9e-4a58cb430f03@github.com>
 <kuMyLYSd4dOC7qBbk9G7ZtvntC1U3FR5V35jLP1qHtQ=.e1459498-2ab5-48b1-8490-25dc94d49b1d@github.com>
Message-ID: <lY7vMCPrX-Mtk1_NGcc2sDh05tuKtafmgLpGwq6iRs0=.e98249d2-c313-4a6b-9ad2-f5546f59743a@github.com>

On Tue, 21 May 2024 17:41:46 GMT, Volodymyr Paprotski <duke at openjdk.org> wrote:

>> Performance. Before:
>> 
>> Benchmark                        (algorithm)  (dataSize)  (keyLength)  (provider)   Mode  Cnt     Score    Error  Units
>> SignatureBench.ECDSA.sign    SHA256withECDSA        1024          256              thrpt    3  6443.934 ?  6.491  ops/s
>> SignatureBench.ECDSA.sign    SHA256withECDSA       16384          256              thrpt    3  6152.979 ?  4.954  ops/s
>> SignatureBench.ECDSA.verify  SHA256withECDSA        1024          256              thrpt    3  1895.410 ? 36.979  ops/s
>> SignatureBench.ECDSA.verify  SHA256withECDSA       16384          256              thrpt    3  1878.955 ? 45.487  ops/s
>> Benchmark                                            (algorithm)  (keyLength)  (kpgAlgorithm)  (provider)   Mode  Cnt     Score    Error  Units
>> o.o.b.j.c.full.KeyAgreementBench.EC.generateSecret          ECDH          256              EC              thrpt    3  1357.810 ? 26.584  ops/s
>> o.o.b.j.c.small.KeyAgreementBench.EC.generateSecret         ECDH          256              EC              thrpt    3  1352.119 ? 23.547  ops/s
>> Benchmark                          (isMontBench)   Mode  Cnt     Score    Error  Units
>> PolynomialP256Bench.benchMultiply          false  thrpt    3  1746.126 ? 10.970  ops/s
>> 
>> Performance, no intrinsic:
>> 
>> Benchmark                        (algorithm)  (dataSize)  (keyLength)  (provider)   Mode  Cnt     Score     Error  Units
>> SignatureBench.ECDSA.sign    SHA256withECDSA        1024          256              thrpt    3  6529.839 ?  42.420  ops/s
>> SignatureBench.ECDSA.sign    SHA256withECDSA       16384          256              thrpt    3  6199.747 ? 133.566  ops/s
>> SignatureBench.ECDSA.verify  SHA256withECDSA        1024          256              thrpt    3  1973.676 ?  54.071  ops/s
>> SignatureBench.ECDSA.verify  SHA256withECDSA       16384          256              thrpt    3  1932.127 ?  35.920  ops/s
>> Benchmark                                            (algorithm)  (keyLength)  (kpgAlgorithm)  (provider)   Mode  Cnt     Score    Error  Units
>> o.o.b.j.c.full.KeyAgreementBench.EC.generateSecret          ECDH          256              EC              thrpt    3  1355.788 ? 29.858  ops/s
>> o.o.b.j.c.small.KeyAgreementBench.EC.generateSecret         ECDH          256              EC              thrpt    3  1346.523 ? 28.722  ops/s
>> Benchmark                          (isMontBench)   Mode  Cnt     Score    Error  Units
>> PolynomialP256Bench.benchMultiply           true  thrpt    3  1919.57...
>
> Volodymyr Paprotski has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 17 additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'origin/master' into ecc-montgomery
>  - shenandoah verifier
>  - comments from Sandhya
>  - whitespace
>  - add message back
>  - whitespace
>  - Use AffinePoint to exit Montgomery domain
>    
>    Style notes:
>    Affine.equals()
>        - Mismatched fields only appear to be used from testing, perhaps should be moved there instead
>    Affine.getX(boolean)|getY(boolean)
>        - "Passing flag is bad design" - cleanest/performant alternative to several instanceof checks
>        - needed to convert Affine to Projective (need to stay in montgomery domain)
>    ECOperations.PointMultiplier
>       - changes could probably be restored to original (since ProjectivePoint handling no longer required)
>       - consider these changes an improvement? (fewer nested classes)
>       - was an inner-class but not using inner-class features (i.e. ecOps variable should be converted)
>  - whitespace
>  - Comments from Tony and Jatin
>  - Comments from Jatin and Tony
>  - ... and 7 more: https://git.openjdk.org/jdk/compare/9ee91a9f...b1a33004

Thanks! I submitted testing and will report back once it passed.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18583#issuecomment-2123869579

From jpai at openjdk.org  Wed May 22 05:21:18 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 22 May 2024 05:21:18 GMT
Subject: RFR: 8332490: JMH
 org.openjdk.bench.java.util.zip.InflaterInputStreams.inflaterInputStreamRead
 OOM
Message-ID: <nisubUXku9Aki5ZnEyRq7_l1TGWUpIIaEKpqZMo2DQw=.a01dd330-cfbb-4a6e-85b1-62378b963419@github.com>

Can I please get a review of this test-only change for addressing https://bugs.openjdk.org/browse/JDK-8332490?

The jmh test opens a `InflaterInputStream`, reads the stream contents, but then doesn't close the stream. This can lead to resource leak which can then cause OOM as noted in that JBS issue.

The commit in this PR closes the `InflaterInputStream` when the reads complete.


make test TEST=micro:org.openjdk.bench.java.util.zip.InflaterInputStreams

and


./build/macosx-aarch64/images/jdk/bin/java -jar ./build/macosx-aarch64/images/test/micro/benchmarks.jar org.openjdk.bench.java.util.zip.InflaterInputStreams.inflaterInputStreamRead -t max -f 1 -wi 2 -foe true

pass after this change.

-------------

Commit messages:
 - 8332490: JMH org.openjdk.bench.java.util.zip.InflaterInputStreams.inflaterInputStreamRead OOM

Changes: https://git.openjdk.org/jdk/pull/19340/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19340&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8332490
  Stats: 3 lines in 1 file changed: 1 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/19340.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19340/head:pull/19340

PR: https://git.openjdk.org/jdk/pull/19340

From aturbanov at openjdk.org  Wed May 22 05:42:04 2024
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Wed, 22 May 2024 05:42:04 GMT
Subject: RFR: 8305457: Implement java.io.IO [v10]
In-Reply-To: <W-zrQzJFDXvKseP4RA74LCtJY51UYJDYQaL3DhNKuBo=.46966752-e50a-41a8-9bd5-21eec2f759fb@github.com>
References: <w2msiw_qaMEIJS3s9D4bg8pFbz5WIF0KdP6Mm-XFjLI=.85b2020b-8c46-4bac-8a69-4975b068f2ff@github.com>
 <5di7ye6tSNpauiTtHGwGI7kFG-iWeKpbWGEOXRK88ag=.fcfb14fd-53d3-4c4c-b774-3660cf6495bb@github.com>
 <d4jnrspQ7DJha26nUJw-aKFQkD0cq8Jj4VJI8LKLC-k=.5c34b3c9-7c4c-4bcf-9223-986c39bafcaa@github.com>
 <W-zrQzJFDXvKseP4RA74LCtJY51UYJDYQaL3DhNKuBo=.46966752-e50a-41a8-9bd5-21eec2f759fb@github.com>
Message-ID: <SfOW1jkuRRmH9NhgxOdDKSkUqAHMbHPplVTaY-h4e1s=.0a1897a5-5b19-42a2-82fa-c1ca231da82a@github.com>

On Tue, 21 May 2024 21:16:52 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/io/JdkConsoleImpl.java line 78:
>> 
>>> 76:         String line = null;
>>> 77:         synchronized (writeLock) {
>>> 78:             synchronized(readLock) {
>> 
>> Suggestion:
>> 
>>             synchronized (readLock) {
>
> Sorry, but no. It would be inconsistent with the rest of the file, which for whatever reason (copy-paste?) does not use whitespace between `synchronized` and `(readLock)`.

It looks strange to have space in one case, and don't have it in another. I would'nt call it consistent.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19112#discussion_r1609287823

From aturbanov at openjdk.org  Wed May 22 06:45:01 2024
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Wed, 22 May 2024 06:45:01 GMT
Subject: RFR: 8332490: JMH
 org.openjdk.bench.java.util.zip.InflaterInputStreams.inflaterInputStreamRead
 OOM
In-Reply-To: <nisubUXku9Aki5ZnEyRq7_l1TGWUpIIaEKpqZMo2DQw=.a01dd330-cfbb-4a6e-85b1-62378b963419@github.com>
References: <nisubUXku9Aki5ZnEyRq7_l1TGWUpIIaEKpqZMo2DQw=.a01dd330-cfbb-4a6e-85b1-62378b963419@github.com>
Message-ID: <IqCaXDYVkPTkM4R9Yz8DnAOuRSRwqZU23ztm2bT_IpU=.7ca32291-1bb8-4e0e-9cc0-4a56d3564892@github.com>

On Wed, 22 May 2024 05:16:42 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this test-only change for addressing https://bugs.openjdk.org/browse/JDK-8332490?
> 
> The jmh test opens a `InflaterInputStream`, reads the stream contents, but then doesn't close the stream. This can lead to resource leak which can then cause OOM as noted in that JBS issue.
> 
> The commit in this PR closes the `InflaterInputStream` when the reads complete.
> 
> 
> make test TEST=micro:org.openjdk.bench.java.util.zip.InflaterInputStreams
> 
> and
> 
> 
> ./build/macosx-aarch64/images/jdk/bin/java -jar ./build/macosx-aarch64/images/test/micro/benchmarks.jar org.openjdk.bench.java.util.zip.InflaterInputStreams.inflaterInputStreamRead -t max -f 1 -wi 2 -foe true
> 
> pass after this change.

Marked as reviewed by aturbanov (Committer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/19340#pullrequestreview-2070259473

From duke at openjdk.org  Wed May 22 07:02:13 2024
From: duke at openjdk.org (duke)
Date: Wed, 22 May 2024 07:02:13 GMT
Subject: Withdrawn: 8323760: clarify specification of Map::putIfAbsent return
 value
In-Reply-To: <rYYoDd81cCAd-FEOLRFnt1NlO7N4wHmpCIFn5V8tIEo=.72e58ea9-7899-4d26-bf30-740ef27fb717@github.com>
References: <rYYoDd81cCAd-FEOLRFnt1NlO7N4wHmpCIFn5V8tIEo=.72e58ea9-7899-4d26-bf30-740ef27fb717@github.com>
Message-ID: <hSBMETDR96j7mpo-3RwLqMeFKcZ37MaJSYr60GqfoBg=.4b75e17d-ae98-4baa-9d65-d44b02182210@github.com>

On Tue, 16 Jan 2024 07:40:44 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

> Update the documentation for `@return` tag of `putIfAbsent` to match the main description. `putIfAbsent` uses the same wording as `put` for its `@return` tag, but that is incorrect.  `putIfAbsent` never returns the **previous** value, as the whole point of the method is not the replace the value if it was present.  As such, if it returns a value, it is the **current** value, and in all other cases it will return `null`.

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/17438

From alanb at openjdk.org  Wed May 22 07:23:02 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 22 May 2024 07:23:02 GMT
Subject: RFR: 8332490: JMH
 org.openjdk.bench.java.util.zip.InflaterInputStreams.inflaterInputStreamRead
 OOM
In-Reply-To: <nisubUXku9Aki5ZnEyRq7_l1TGWUpIIaEKpqZMo2DQw=.a01dd330-cfbb-4a6e-85b1-62378b963419@github.com>
References: <nisubUXku9Aki5ZnEyRq7_l1TGWUpIIaEKpqZMo2DQw=.a01dd330-cfbb-4a6e-85b1-62378b963419@github.com>
Message-ID: <f_uu4_hgiCUMyOduAjZqY3xDujgrZriH4v7J7Nz_3tY=.60597994-b067-47ee-8f37-3ae489f2c619@github.com>

On Wed, 22 May 2024 05:16:42 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this test-only change for addressing https://bugs.openjdk.org/browse/JDK-8332490?
> 
> The jmh test opens a `InflaterInputStream`, reads the stream contents, but then doesn't close the stream. This can lead to resource leak which can then cause OOM as noted in that JBS issue.
> 
> The commit in this PR closes the `InflaterInputStream` when the reads complete.
> 
> 
> make test TEST=micro:org.openjdk.bench.java.util.zip.InflaterInputStreams
> 
> and
> 
> 
> ./build/macosx-aarch64/images/jdk/bin/java -jar ./build/macosx-aarch64/images/test/micro/benchmarks.jar org.openjdk.bench.java.util.zip.InflaterInputStreams.inflaterInputStreamRead -t max -f 1 -wi 2 -foe true
> 
> pass after this change.

test/micro/org/openjdk/bench/java/util/zip/InflaterInputStreams.java line 113:

> 111:         try (InflaterInputStream iis = new InflaterInputStream(deflated)) {
> 112:             while (iis.read(inflated, 0, inflated.length) != -1);
> 113:         }

Presumably this only works because closing the underlying stream (a BAOS in this case) is a no-op.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19340#discussion_r1609427551

From redestad at openjdk.org  Wed May 22 07:31:08 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Wed, 22 May 2024 07:31:08 GMT
Subject: RFR: 8332490: JMH
 org.openjdk.bench.java.util.zip.InflaterInputStreams.inflaterInputStreamRead
 OOM
In-Reply-To: <nisubUXku9Aki5ZnEyRq7_l1TGWUpIIaEKpqZMo2DQw=.a01dd330-cfbb-4a6e-85b1-62378b963419@github.com>
References: <nisubUXku9Aki5ZnEyRq7_l1TGWUpIIaEKpqZMo2DQw=.a01dd330-cfbb-4a6e-85b1-62378b963419@github.com>
Message-ID: <q150BYP0DHapEXu0S1txz9A2zfC4oCKbt5-SFXGvzk0=.714d0fe0-0c71-4e95-8460-c553beaa711e@github.com>

On Wed, 22 May 2024 05:16:42 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this test-only change for addressing https://bugs.openjdk.org/browse/JDK-8332490?
> 
> The jmh test opens a `InflaterInputStream`, reads the stream contents, but then doesn't close the stream. This can lead to resource leak which can then cause OOM as noted in that JBS issue.
> 
> The commit in this PR closes the `InflaterInputStream` when the reads complete.
> 
> 
> make test TEST=micro:org.openjdk.bench.java.util.zip.InflaterInputStreams
> 
> and
> 
> 
> ./build/macosx-aarch64/images/jdk/bin/java -jar ./build/macosx-aarch64/images/test/micro/benchmarks.jar org.openjdk.bench.java.util.zip.InflaterInputStreams.inflaterInputStreamRead -t max -f 1 -wi 2 -foe true
> 
> pass after this change.

LGTM - feel free to add a comment that closing the `InflaterInputStream` has no effect on the underlying stream `deflated`.

-------------

PR Review: https://git.openjdk.org/jdk/pull/19340#pullrequestreview-2070357036

From redestad at openjdk.org  Wed May 22 07:31:09 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Wed, 22 May 2024 07:31:09 GMT
Subject: RFR: 8332490: JMH
 org.openjdk.bench.java.util.zip.InflaterInputStreams.inflaterInputStreamRead
 OOM
In-Reply-To: <f_uu4_hgiCUMyOduAjZqY3xDujgrZriH4v7J7Nz_3tY=.60597994-b067-47ee-8f37-3ae489f2c619@github.com>
References: <nisubUXku9Aki5ZnEyRq7_l1TGWUpIIaEKpqZMo2DQw=.a01dd330-cfbb-4a6e-85b1-62378b963419@github.com>
 <f_uu4_hgiCUMyOduAjZqY3xDujgrZriH4v7J7Nz_3tY=.60597994-b067-47ee-8f37-3ae489f2c619@github.com>
Message-ID: <hwMOhVDteSr3PPvCg_5YkJK1XJwnInyjE1wF7pabV3Q=.bd043d33-30c0-4ea4-b187-1cb34ffeb845@github.com>

On Wed, 22 May 2024 07:20:04 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Can I please get a review of this test-only change for addressing https://bugs.openjdk.org/browse/JDK-8332490?
>> 
>> The jmh test opens a `InflaterInputStream`, reads the stream contents, but then doesn't close the stream. This can lead to resource leak which can then cause OOM as noted in that JBS issue.
>> 
>> The commit in this PR closes the `InflaterInputStream` when the reads complete.
>> 
>> 
>> make test TEST=micro:org.openjdk.bench.java.util.zip.InflaterInputStreams
>> 
>> and
>> 
>> 
>> ./build/macosx-aarch64/images/jdk/bin/java -jar ./build/macosx-aarch64/images/test/micro/benchmarks.jar org.openjdk.bench.java.util.zip.InflaterInputStreams.inflaterInputStreamRead -t max -f 1 -wi 2 -foe true
>> 
>> pass after this change.
>
> test/micro/org/openjdk/bench/java/util/zip/InflaterInputStreams.java line 113:
> 
>> 111:         try (InflaterInputStream iis = new InflaterInputStream(deflated)) {
>> 112:             while (iis.read(inflated, 0, inflated.length) != -1);
>> 113:         }
> 
> Presumably this only works because closing the underlying stream (a BAOS in this case) is a no-op.

Yes, the underlying BAIS can be repeatedly closed without affecting the benchmark.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19340#discussion_r1609436837

From ihse at openjdk.org  Wed May 22 07:41:02 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 22 May 2024 07:41:02 GMT
Subject: RFR: 8332589: ubsan: unix/native/libjava/ProcessImpl_md.c:562:5:
 runtime error: null pointer passed as argument 2,
 which is declared to never be null
In-Reply-To: <AwlmAiTOhqSaoJ2Jh5YYrBpxakc0Pt9lYP9nvcBjXBo=.813efddf-3f87-4bbf-9cc5-cd769eabd2f7@github.com>
References: <AwlmAiTOhqSaoJ2Jh5YYrBpxakc0Pt9lYP9nvcBjXBo=.813efddf-3f87-4bbf-9cc5-cd769eabd2f7@github.com>
Message-ID: <DeL3jZr3PPV7yPfbgm5XfuwlHuPDEOnqJhC5f7c8PgY=.c6009e01-e6dc-49fe-98e8-3aeac0caa814@github.com>

On Tue, 21 May 2024 14:28:38 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> When building with ubsan enabled (--enable-uban) on Linux x86_64 and doing jtreg tests afterwards I run into this error :
> 
> /jdk/src/java.base/unix/native/libjava/ProcessImpl_md.c:562:5: runtime error: null pointer passed as argument 2, which is declared to never be null
>     #0 0x7fd95bec78d8 in spawnChild /jdk/src/java.base/unix/native/libjava/ProcessImpl_md.c:562
>     #1 0x7fd95bec78d8 in startChild /jdk/src/java.base/unix/native/libjava/ProcessImpl_md.c:612
>     #2 0x7fd95bec78d8 in Java_java_lang_ProcessImpl_forkAndExec /jdk/src/java.base/unix/native/libjava/ProcessImpl_md.c:712
>     #3 0x7fd93797a06d (<unknown module>)
> 
> this is the memcpy call getting an unexpected null pointer :
>     memcpy(buf+offset, c->pdir, sp.dirlen); gets a second parameter null.
> Something similar was discussed and fixed here https://bugs.python.org/issue27570 for Python .
> 
> Similar issue in OpenJDK _ 
> https://bugs.openjdk.org/browse/JDK-8332473
> 8332473: ubsan: growableArray.hpp:290:10: runtime error: null pointer passed as argument 1, which is declared to never be null

How come `c->pdir` can be null? Is it if `sp.dirlen` is 0?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19329#issuecomment-2124082247

From ihse at openjdk.org  Wed May 22 07:47:15 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 22 May 2024 07:47:15 GMT
Subject: RFR: 8311302: Allow for jlinking a custom runtime without packaged
 modules being present [v25]
In-Reply-To: <EjF8YVHfHr9qm_5w3BLUSFhP-cQ_BR6Fcs_8-oKzpZo=.3cdf9de7-b75c-4848-93ed-173ac6060a3f@github.com>
References: <Z0DJ87uKPbjS6mvJIE_oG5m-RWsbERXsytSgV8Bmhdo=.f8723513-0ac6-4e85-9131-3c3924860c61@github.com>
 <2Hs5V_cOOhOtXxrKvM0ATWxJFO62xd3RtScyPEb5puI=.f16650ac-9812-40ed-a93c-a5dd4b396ad2@github.com>
 <EjF8YVHfHr9qm_5w3BLUSFhP-cQ_BR6Fcs_8-oKzpZo=.3cdf9de7-b75c-4848-93ed-173ac6060a3f@github.com>
Message-ID: <BXZ-wDhkakio3dYE5xnHxEuIdyEuKSzD_Fl4HqLNh-o=.c381306e-f528-4da0-b913-ef730648969e@github.com>

On Thu, 4 Apr 2024 20:52:59 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Severin Gehwolf has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - Use shorter name for the build tool
>>  - Review feedback from Erik J.
>>  - Remove dependency on CDS which isn't needed anymore
>
> src/jdk.jlink/share/classes/jdk/tools/jlink/resources/jlink.properties line 165:
> 
>> 163: 
>> 164: runtime.link.info=Linking based on the current run-time image.
>> 165: runtime.link.jprt.path.extra=(run-time image)
> 
> Missing newline at last line.

... still missing...

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14787#discussion_r1609457478

From ihse at openjdk.org  Wed May 22 07:47:16 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 22 May 2024 07:47:16 GMT
Subject: RFR: 8311302: Allow for jlinking a custom runtime without packaged
 modules being present [v25]
In-Reply-To: <BXZ-wDhkakio3dYE5xnHxEuIdyEuKSzD_Fl4HqLNh-o=.c381306e-f528-4da0-b913-ef730648969e@github.com>
References: <Z0DJ87uKPbjS6mvJIE_oG5m-RWsbERXsytSgV8Bmhdo=.f8723513-0ac6-4e85-9131-3c3924860c61@github.com>
 <2Hs5V_cOOhOtXxrKvM0ATWxJFO62xd3RtScyPEb5puI=.f16650ac-9812-40ed-a93c-a5dd4b396ad2@github.com>
 <EjF8YVHfHr9qm_5w3BLUSFhP-cQ_BR6Fcs_8-oKzpZo=.3cdf9de7-b75c-4848-93ed-173ac6060a3f@github.com>
 <BXZ-wDhkakio3dYE5xnHxEuIdyEuKSzD_Fl4HqLNh-o=.c381306e-f528-4da0-b913-ef730648969e@github.com>
Message-ID: <GEm6vSB1NxlJO9d9hmql8LEHGeoRPTzq_o_paTUmxdI=.588f70ee-4e99-43f9-a586-b94f2c6bb104@github.com>

On Wed, 22 May 2024 07:42:39 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> src/jdk.jlink/share/classes/jdk/tools/jlink/resources/jlink.properties line 165:
>> 
>>> 163: 
>>> 164: runtime.link.info=Linking based on the current run-time image.
>>> 165: runtime.link.jprt.path.extra=(run-time image)
>> 
>> Missing newline at last line.
>
> ... still missing...

Actually, this is a bit strange. I thought jcheck would look for missing newline at EOF, and that properties files were included in the check nowadays. I'll need to check this out.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14787#discussion_r1609459326

From jpai at openjdk.org  Wed May 22 07:49:27 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 22 May 2024 07:49:27 GMT
Subject: RFR: 8332490: JMH
 org.openjdk.bench.java.util.zip.InflaterInputStreams.inflaterInputStreamRead
 OOM [v2]
In-Reply-To: <nisubUXku9Aki5ZnEyRq7_l1TGWUpIIaEKpqZMo2DQw=.a01dd330-cfbb-4a6e-85b1-62378b963419@github.com>
References: <nisubUXku9Aki5ZnEyRq7_l1TGWUpIIaEKpqZMo2DQw=.a01dd330-cfbb-4a6e-85b1-62378b963419@github.com>
Message-ID: <a9-gLlH5AgmhKJoJM5e7j5gZD-W3oEFl8SpX64WTHUA=.879a2374-aadf-4b5b-921a-3444c3de3797@github.com>

> Can I please get a review of this test-only change for addressing https://bugs.openjdk.org/browse/JDK-8332490?
> 
> The jmh test opens a `InflaterInputStream`, reads the stream contents, but then doesn't close the stream. This can lead to resource leak which can then cause OOM as noted in that JBS issue.
> 
> The commit in this PR closes the `InflaterInputStream` when the reads complete.
> 
> 
> make test TEST=micro:org.openjdk.bench.java.util.zip.InflaterInputStreams
> 
> and
> 
> 
> ./build/macosx-aarch64/images/jdk/bin/java -jar ./build/macosx-aarch64/images/test/micro/benchmarks.jar org.openjdk.bench.java.util.zip.InflaterInputStreams.inflaterInputStreamRead -t max -f 1 -wi 2 -foe true
> 
> pass after this change.

Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:

  add a comment

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19340/files
  - new: https://git.openjdk.org/jdk/pull/19340/files/f8687c3f..42a2d32a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19340&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19340&range=00-01

  Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/19340.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19340/head:pull/19340

PR: https://git.openjdk.org/jdk/pull/19340

From jpai at openjdk.org  Wed May 22 07:49:27 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 22 May 2024 07:49:27 GMT
Subject: RFR: 8332490: JMH
 org.openjdk.bench.java.util.zip.InflaterInputStreams.inflaterInputStreamRead
 OOM [v2]
In-Reply-To: <q150BYP0DHapEXu0S1txz9A2zfC4oCKbt5-SFXGvzk0=.714d0fe0-0c71-4e95-8460-c553beaa711e@github.com>
References: <nisubUXku9Aki5ZnEyRq7_l1TGWUpIIaEKpqZMo2DQw=.a01dd330-cfbb-4a6e-85b1-62378b963419@github.com>
 <q150BYP0DHapEXu0S1txz9A2zfC4oCKbt5-SFXGvzk0=.714d0fe0-0c71-4e95-8460-c553beaa711e@github.com>
Message-ID: <da6CVzOzwrgcg_XPntDTRczu9FGMTl1rgRPLKMjTYDU=.c99d4ae7-ba71-4302-8fe3-4bd732c5b1b7@github.com>

On Wed, 22 May 2024 07:28:04 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> LGTM - feel free to add a comment that closing the InflaterInputStream has no effect on the underlying stream deflated.

Hello Claes, I've updated the PR to include a comment.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19340#issuecomment-2124098078

From jpai at openjdk.org  Wed May 22 07:49:28 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 22 May 2024 07:49:28 GMT
Subject: RFR: 8332490: JMH
 org.openjdk.bench.java.util.zip.InflaterInputStreams.inflaterInputStreamRead
 OOM [v2]
In-Reply-To: <hwMOhVDteSr3PPvCg_5YkJK1XJwnInyjE1wF7pabV3Q=.bd043d33-30c0-4ea4-b187-1cb34ffeb845@github.com>
References: <nisubUXku9Aki5ZnEyRq7_l1TGWUpIIaEKpqZMo2DQw=.a01dd330-cfbb-4a6e-85b1-62378b963419@github.com>
 <f_uu4_hgiCUMyOduAjZqY3xDujgrZriH4v7J7Nz_3tY=.60597994-b067-47ee-8f37-3ae489f2c619@github.com>
 <hwMOhVDteSr3PPvCg_5YkJK1XJwnInyjE1wF7pabV3Q=.bd043d33-30c0-4ea4-b187-1cb34ffeb845@github.com>
Message-ID: <x6wiMNAPDCf6JuTGP03OB-X_ABvR0RaPxKEgriFILx0=.2ec33e14-b9e3-4bd9-b5d5-097564d7c05c@github.com>

On Wed, 22 May 2024 07:27:14 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> test/micro/org/openjdk/bench/java/util/zip/InflaterInputStreams.java line 113:
>> 
>>> 111:         try (InflaterInputStream iis = new InflaterInputStream(deflated)) {
>>> 112:             while (iis.read(inflated, 0, inflated.length) != -1);
>>> 113:         }
>> 
>> Presumably this only works because closing the underlying stream (a BAIS in this case) is a no-op.
>
> Yes, the underlying BAIS can be repeatedly closed without affecting the benchmark.

Hello Alan, before this change, the memory gets occupied by too many of these:


   1:      10871820      521847360  jdk.internal.ref.CleanerImpl$PhantomCleanableRef (java.base at 23-internal)
   2:      10871758      260922192  java.util.zip.Inflater$InflaterZStreamRef (java.base at 23-internal)



Closing the `InflaterInputStream` releases those underlying `InflaterZStreamRef`s.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19340#discussion_r1609461029

From alanb at openjdk.org  Wed May 22 07:59:09 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 22 May 2024 07:59:09 GMT
Subject: RFR: 8314480: Memory ordering spec updates in java.lang.ref [v22]
In-Reply-To: <vgHrkAj_5vBtWEy1C8966ZzsP7eUUdW4PQkTs96WD-U=.b488ae70-a7ce-4074-9489-c2a39496c6b6@github.com>
References: <R74ontYwjYg6HeZY0cWrlo0amjl4E1YsFWeuh4pda14=.08ac62df-b2f8-4b4d-b338-07adb289601b@github.com>
 <iSAFZXJw0U2itwjjNTLOuChx4kx9K1J6odAc4IyngK8=.67614a1a-833f-4079-8bfa-f204083a3cee@github.com>
 <fa0Mqk6azF75mkiKAwMZHmtC5Lsw4KqcTAMZb3bIJWo=.16abf539-e6c6-4ab5-a937-a0505522d802@github.com>
 <vgHrkAj_5vBtWEy1C8966ZzsP7eUUdW4PQkTs96WD-U=.b488ae70-a7ce-4074-9489-c2a39496c6b6@github.com>
Message-ID: <FfwbHK6PeIQuZprgt9UkHRmZENLUg6iQ-abe9q15XRU=.92b2a9b9-78aa-4145-bb52-461e60eec277@github.com>

On Tue, 21 May 2024 16:59:38 GMT, Brent Christian <bchristi at openjdk.org> wrote:

> Indeed - can't move forward without a CSR. Also wouldn't mind more reviewer ??s. ?

I can do that.  One other thing to do is to rebase the changes, it looks like this branch is 6 months behind main line.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/16644#issuecomment-2124116145

From ihse at openjdk.org  Wed May 22 08:11:14 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 22 May 2024 08:11:14 GMT
Subject: RFR: 8311302: Allow for jlinking a custom runtime without packaged
 modules being present [v25]
In-Reply-To: <GEm6vSB1NxlJO9d9hmql8LEHGeoRPTzq_o_paTUmxdI=.588f70ee-4e99-43f9-a586-b94f2c6bb104@github.com>
References: <Z0DJ87uKPbjS6mvJIE_oG5m-RWsbERXsytSgV8Bmhdo=.f8723513-0ac6-4e85-9131-3c3924860c61@github.com>
 <2Hs5V_cOOhOtXxrKvM0ATWxJFO62xd3RtScyPEb5puI=.f16650ac-9812-40ed-a93c-a5dd4b396ad2@github.com>
 <EjF8YVHfHr9qm_5w3BLUSFhP-cQ_BR6Fcs_8-oKzpZo=.3cdf9de7-b75c-4848-93ed-173ac6060a3f@github.com>
 <BXZ-wDhkakio3dYE5xnHxEuIdyEuKSzD_Fl4HqLNh-o=.c381306e-f528-4da0-b913-ef730648969e@github.com>
 <GEm6vSB1NxlJO9d9hmql8LEHGeoRPTzq_o_paTUmxdI=.588f70ee-4e99-43f9-a586-b94f2c6bb104@github.com>
Message-ID: <T2CisOVBsFa0zK5HXXOkvh54HHQFRU1xJpAxhZ_Yfe4=.f7b0b3e0-e109-4e95-a513-9100ee08b598@github.com>

On Wed, 22 May 2024 07:44:08 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> ... still missing...
>
> Actually, this is a bit strange. I thought jcheck would look for missing newline at EOF, and that properties files were included in the check nowadays. I'll need to check this out.

I did some testing and it turns out that this is indeed not checked. I believe this is a miss in the Skara reimplementation of jcheck. I've opened https://bugs.openjdk.org/browse/SKARA-2265 to track this.

Nevertheless, it would be good if you could fix this. :)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14787#discussion_r1609491669

From ihse at openjdk.org  Wed May 22 08:55:05 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 22 May 2024 08:55:05 GMT
Subject: RFR: 8330542: Add jaxp-strict.properties in preparation for a
 stricter default configuration [v12]
In-Reply-To: <Xhrtr31Mwi_NwgwShsUonMQBkOITdwllZAmedF_k1Og=.26242046-84a7-4da7-ae88-901b794df2dc@github.com>
References: <v1bAYKgH9zfooXpvnBw4Vu2TIqHuKqqtSmgB0hiNp-Q=.31661a99-ecfc-4a05-8045-67b5f680db60@github.com>
 <Xhrtr31Mwi_NwgwShsUonMQBkOITdwllZAmedF_k1Og=.26242046-84a7-4da7-ae88-901b794df2dc@github.com>
Message-ID: <8A-Z8Q-bmxb3P2_x64siGd3gN07jzf-nHxXiiV64G0A=.65e5be8d-1975-4840-b876-4038320dcf18@github.com>

On Tue, 21 May 2024 20:28:37 GMT, Joe Wang <joehw at openjdk.org> wrote:

>> Add two sample configuration files:
>> 
>>   jaxp-strict.properties: used to set strict configuration, stricter than jaxp.properties in previous versions such as JDK 22
>> 
>>>   jaxp-compat.properties: used to regain compatibility from any more restricted configuration than previous versions such as JDK 22
>> 
>> Updated on 5/16/2024
>> 
>> Design change:
>> The design is changed to include in the JDK two configuration files that are the default jaxp.properties and jaxp-strict.properties, instead of three, dropping jaxp-compat.properties.
>> 
>> Updated on 5/18/2024
>> 
>> Withdraw changes to jaxp.properties. The original idea was to match jaxp-strict.properties with regard to the properties. However, that change impact the configuration process, resulting in tests that verify the process to fail.
>
> Joe Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add a note to module-info

make/modules/java.xml/Copy.gmk line 35:

> 33: $(eval $(call SetupCopyFiles, COPY_XML_MODULE_CONF, \
> 34:     DEST := $(CONF_DST_DIR), \
> 35:     FILES := $(wildcard $(TOPDIR)/src/java.xml/share/conf/jaxp*.properties*), \

I don't think you need, nor should have, the asterisk after the extension. You are only copying `.properties` files.

Suggestion:

    FILES := $(wildcard $(TOPDIR)/src/java.xml/share/conf/jaxp*.properties), \

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18831#discussion_r1609565653

From ihse at openjdk.org  Wed May 22 08:59:03 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 22 May 2024 08:59:03 GMT
Subject: RFR: 8331671: Implement JEP 472: Prepare to Restrict the Use of
 JNI [v8]
In-Reply-To: <vWr2PdgTv6vEllxW8820KO3aZ3tR3xvMhCxD2k7QpS0=.8bfd6c47-6c93-4fc3-aced-7079889aa6a2@github.com>
References: <CZGbki5iFdCGPPagE-ya-_L8Nkgf7OunywApOsxC548=.2cee82fa-a5d2-4165-b012-30982a85030a@github.com>
 <vWr2PdgTv6vEllxW8820KO3aZ3tR3xvMhCxD2k7QpS0=.8bfd6c47-6c93-4fc3-aced-7079889aa6a2@github.com>
Message-ID: <y3fQHNtP45EGmJmrVWNT1SMBgNP6GgYvHGM4v0Hz2h0=.ba07a68b-ea4b-4620-9e0f-70a413d0b002@github.com>

On Fri, 17 May 2024 13:38:25 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This PR implements [JEP 472](https://openjdk.org/jeps/472), by restricting the use of JNI in the following ways:
>> 
>> * `System::load` and `System::loadLibrary` are now restricted methods
>> * `Runtime::load` and `Runtime::loadLibrary` are now restricted methods
>> * binding a JNI `native` method declaration to a native implementation is now considered a restricted operation
>> 
>> This PR slightly changes the way in which the JDK deals with restricted methods, even for FFM API calls. In Java 22, the single `--enable-native-access` was used both to specify a set of modules for which native access should be allowed *and* to specify whether illegal native access (that is, native access occurring from a module not specified by `--enable-native-access`) should be treated as an error or a warning. More specifically, an error is only issued if the `--enable-native-access flag` is used at least once.
>> 
>> Here, a new flag is introduced, namely `illegal-native-access=allow/warn/deny`, which is used to specify what should happen when access to a restricted method and/or functionality is found outside the set of modules specified with `--enable-native-access`. The default policy is `warn`, but users can select `allow` to suppress the warnings, or `deny` to cause `IllegalCallerException` to be thrown. This aligns the treatment of restricted methods with other mechanisms, such as `--illegal-access` and the more recent `--sun-misc-unsafe-memory-access`.
>> 
>> Some changes were required in the package-info javadoc for `java.lang.foreign`, to reflect the changes in the command line flags described above.
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address review comments

Build changes look good. Thanks for trimming down NATIVE_ACCESS_MODULES.

-------------

Marked as reviewed by ihse (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19213#pullrequestreview-2070573791

From mbaesken at openjdk.org  Wed May 22 09:16:01 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 22 May 2024 09:16:01 GMT
Subject: RFR: 8332589: ubsan: unix/native/libjava/ProcessImpl_md.c:562:5:
 runtime error: null pointer passed as argument 2,
 which is declared to never be null
In-Reply-To: <DeL3jZr3PPV7yPfbgm5XfuwlHuPDEOnqJhC5f7c8PgY=.c6009e01-e6dc-49fe-98e8-3aeac0caa814@github.com>
References: <AwlmAiTOhqSaoJ2Jh5YYrBpxakc0Pt9lYP9nvcBjXBo=.813efddf-3f87-4bbf-9cc5-cd769eabd2f7@github.com>
 <DeL3jZr3PPV7yPfbgm5XfuwlHuPDEOnqJhC5f7c8PgY=.c6009e01-e6dc-49fe-98e8-3aeac0caa814@github.com>
Message-ID: <DopDlLKNub1J7YJI1Bh98BaxzirOL8rclN2UWm74oj0=.2cabc182-4c49-4789-9038-3dd1badd9eca@github.com>

On Wed, 22 May 2024 07:38:07 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> How come `c->pdir` can be null? Is it if `sp.dirlen` is 0?

I added a bit of tracing output and get 
**** Attention c->pdir is null; sp.dirlen is 0 
So yes sp.dirlen is also 0 .

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19329#issuecomment-2124271807

From liangchenblue at gmail.com  Wed May 22 11:35:46 2024
From: liangchenblue at gmail.com (Chen Liang)
Date: Wed, 22 May 2024 06:35:46 -0500
Subject: Deterministic naming of subclasses of `java/lang/reflect/Proxy`
In-Reply-To: <580b3aacd8df48fcaae3399718e229ab@kth.se>
References: <bf26eb2f74874e02876b3868311922a9@kth.se>
 <CABe8uE0fk71Xy_PYHikSw9OtXE_i+M9zMbayPEXuTxLWLoy2ag@mail.gmail.com>
 <50405ca9c0a64372bace175b932f9ef7@kth.se>
 <61fbe3d9-9536-4113-adde-6cfc671ba1ee@oracle.com>
 <a860be44e06243799593aa8d67c048cd@kth.se>
 <CABe8uE115=DzYCdnvNazqFuuxtJoZnv9wRUkFA4-PS7g41QLMw@mail.gmail.com>
 <DB7PR02MB35938DCC3A392536B924164AFBEE2@DB7PR02MB3593.eurprd02.prod.outlook.com>
 <a0330ee0-5f45-4ef2-8500-e5fcdb696c52@oracle.com>
 <b214cc1a13fe4885a437e16b420e5483@kth.se>
 <ac2ebe5c-db49-4a2d-a5cd-10440a77aa16@oracle.com>
 <580b3aacd8df48fcaae3399718e229ab@kth.se>
Message-ID: <CABe8uE065Q3+0yNjtyDF-eJM4LN-MbY9kfC44CnSQ-KM4p862g@mail.gmail.com>

Hi Aman,
We have tried defining Proxy as hidden classes; a previous attempt was on
hold because of issues with serialization. Otherwise, Proxies work great as
hidden classes.

Chen

On Mon, May 20, 2024 at 7:56?AM Aman Sharma <amansha at kth.se> wrote:

> Hi David,
>
>
> > I would not expect any class load
> events.
>
>
> I understand. I also haven't tried to intercept them but I see only one
> approach right now to include them in an allowlist - 1) statically look for
> invocations of "Lookup::defineHiddenClass". 2) Instrument them so that
> its first argument "bytes" can be looked into upon. I haven't looked into
> it much because I did not have much idea about it. And they are hidden so
> it made it worse. ? Thanks for sharing the JEP!
>
>
> >
> java.lang.reflect.Proxy could define hidden classes to act as the proxy
> classes which implement proxy interfaces; from JEP 317
>
>
> It says that Proxy classes will also become hidden classes. Is it
> underway? Right now one can intercept, transform them, and include them in
> an allowlist. What do you think of naming them independent of AtomicLong so
> that a proxy class generated at runtime is easy to lookup in the allowlist?
>
>
>
> Regards,
> Aman Sharma
>
> PhD Student
> KTH Royal Institute of Technology
> School of Electrical Engineering and Computer Science (EECS)
> Department of Theoretical Computer Science (TCS)
> <http://www.kth.se> <https://www.kth.se/profile/amansha>
> <https://www.kth.se/profile/amansha>
> <https://www.kth.se/profile/amansha>https://algomaster99.github.io/
> ------------------------------
> *From:* David Holmes <david.holmes at oracle.com>
> *Sent:* Monday, May 20, 2024 2:30:37 PM
> *To:* Aman Sharma; liangchenblue at gmail.com
> *Cc:* core-libs-dev at openjdk.org; leyden-dev at openjdk.org
> *Subject:* Re: Deterministic naming of subclasses of
> `java/lang/reflect/Proxy`
>
> On 20/05/2024 10:12 pm, Aman Sharma wrote:
> > Hi David,
> >
> >
> >  > How did you try to intercept them? Hidden classes are not "loaded" in
> > the normal sense so won't trigger class load events.
> >
> >
> > I could not intercept them. I only see them when I pass `-verbose:class`
> > in the Java CLI.
>
> Yes that is why I asked how you tried to intercept them.
>
> >
> > I also couldn't intercept them using JVMTI Class File Load Hook
> > <
> https://docs.oracle.com/en/java/javase/21/docs/specs/jvmti.html#ClassFileLoadHook>
> event. However JEP 371 suggests that it should be possible to intercept
> them using JVMTI Class Load <
> https://docs.oracle.com/en/java/javase/21/docs/specs/jvmti.html#ClassLoad>
> event, but I won't have the bytecode at this stage. So is there no way to
> get its bytecode before it is linked and initialized in the JVM?
>
> Hidden classes are not loaded so I would not expect any class load
> events. However the exact nature of the JVMTI class load event is
> unclear as it talks about "class or interface creation" which is neither
> loading or defining per se. But a class prepare event sounds like it
> should be issued. However neither give you access to the bytecode of the
> class AFAICS.
>
> David
> -----
>
>
> >
> > Regards,
> > Aman Sharma
> >
> > PhD Student
> > KTH Royal Institute of Technology
> > School of Electrical Engineering and Computer Science (EECS)
> > Department of Theoretical Computer Science (TCS)
> > <
> http://www.kth.se><https://www.kth.se/profile/amansha><https://www.kth.se/profile/amansha
> >
> > <https://www.kth.se/profile/amansha>https://algomaster99.github.io/
> > <https://algomaster99.github.io/>
> > ------------------------------------------------------------------------
> > *From:* David Holmes <david.holmes at oracle.com>
> > *Sent:* Monday, May 20, 2024 2:59:17 AM
> > *To:* Aman Sharma; liangchenblue at gmail.com
> > *Cc:* core-libs-dev at openjdk.org; leyden-dev at openjdk.org
> > *Subject:* Re: Deterministic naming of subclasses of
> > `java/lang/reflect/Proxy`
> > On 17/05/2024 9:43 pm, Aman Sharma wrote:
> >> Hi Chen,
> >>
> >>  > java.lang.invoke.LambdaForm$MH/0x00000200cc000400
> >>
> >> I do see this as output when I pass -verbose:class. However, based on
> my
> >> experiments, I have seen that neither an agent passed via 'javaagent'
> >> nor an agent passed via 'agentpath' is able to intercept this hidden
> class.
> >
> > How did you try to intercept them? Hidden classes are not "loaded" in
> > the normal sense so won't trigger class load events.
> >
> >> Also, I was a bit confused since I saw somewhere that the names of
> >> hidden classes are null. But thanks for clarifying here.
> >
> > The JEP clearly defines the name format for hidden classes - though the
> > final component is VM specific (and typically a hashcode).
> >
> > https://openjdk.org/jeps/371 <https://openjdk.org/jeps/371>
> >
> > Cheers,
> > David
> > -----
> >
> >>  > avoid dynamic class loading
> >>
> >> I don't see dynamic class loading as a problem. I only mind some
> >> unstable generation aspects of them which make it hard to verify them
> >> based on an allowlist.
> >>
> >> For example, if this hidden class is generated with the exact same name
> >> and the exact same bytecode during runtime as well, it would be easy to
> >> verify it. However, I do see the names are based on some sort of memory
> >> address so and I don't know what bytecode it has so I don't have
> >> suggestions to make them stable as of now. For Proxy classes, I feel it
> >> can be addressed unless you disagree or some involved in Project Leyden
> >> does. :) Thank you for forwarding my mail there.
> >>
> >> Regards,
> >> Aman Sharma
> >>
> >> PhD Student
> >> KTH Royal Institute of Technology
> >> https://algomaster99.github.io/ <https://algomaster99.github.io/>
> > <https://algomaster99.github.io/ <https://algomaster99.github.io/>>
> >>
> >> ------------------------------------------------------------------------
> >> *From:* liangchenblue at gmail.com <liangchenblue at gmail.com>
> >> *Sent:* Friday, May 17, 2024 1:23:58 pm
> >> *To:* Aman Sharma <amansha at kth.se>
> >> *Cc:* core-libs-dev at openjdk.org <core-libs-dev at openjdk.org>;
> >> leyden-dev at openjdk.org <leyden-dev at openjdk.org>
> >> *Subject:* Re: Deterministic naming of subclasses of
> >> `java/lang/reflect/Proxy`
> >>
> >> Hi Aman,
> >> For `-verbose:class`, it's a JVM argument instead of a program
> argument;
> >> so when you run a java program like `java Main`, you should call it as
> >> `java -verbose:class Main`.
> >> When done correctly, you should see hidden class outputs like:
> >> [0.032s][info][class,load]
> >> java.lang.invoke.LambdaForm$MH/0x00000200cc000400 source:
> >> __JVM_LookupDefineClass__
> >> The loading of java.lang.invoke hidden classes requires your program to
> >> use MethodHandle features, like a lambda.
> >>
> >> I think the problem you are exploring, that to avoid dynamic class
> >> loading and effectively turn Java Platform closed for security, is also
> >> being accomplished by project Leyden (as I've shared initially); Thus,
> I
> >> am forwarding this to leyden-dev instead, so you can see what approach
> >> Leyden uses to accomplish the same goal as yours.
> >>
> >> Regards, Chen Liang
> >>
> >> On Fri, May 17, 2024 at 4:40?AM Aman Sharma <amansha at kth.se
> >> <mailto:amansha at kth.se <mailto:amansha at kth.se <amansha at kth.se>>>>
> wrote:
> >>
> >>     __
> >>
> >>     Hi Roger,
> >>
> >>
> >>     Do you have ideas on how to intercept them? My javaagent is not able
> >>     to nor a JVMTI agent passed using `agentpath` option. It also does
> >>     not seem to show up in logs when I pass `-verbose:class`.
> >>
> >>
> >>     Also, what do you think of renaming the proxy classes as suggested
> >>     below?
> >>
> >>
> >>     Regards,
> >>     Aman Sharma
> >>
> >>     PhD Student
> >>     KTH Royal Institute of Technology
> >>     School of Electrical Engineering and Computer Science (EECS)
> >>     Department of Theoretical Computer Science (TCS)
> >>     <http://www.kth.se><https://www.kth.se/profile/amansha><
> https://www.kth.se/profile/amansha <
> http://www.kth.se><https://www.kth.se/profile/amansha><https://www.kth.se/profile/amansha
> >>
> >>     <https://www.kth.se/profile/amansha
> > <https://www.kth.se/profile/amansha>>https://algomaster99.github.io/
> >>     <https://algomaster99.github.io/ <https://algomaster99.github.io/>>
> >>
> ------------------------------------------------------------------------
> >>     *From:* core-libs-dev <core-libs-dev-retn at openjdk.org
> >>     <mailto:core-libs-dev-retn at openjdk.org
> > <mailto:core-libs-dev-retn at openjdk.org <core-libs-dev-retn at openjdk.org>>>>
> on behalf of Roger Riggs
> >>     <roger.riggs at oracle.com <mailto:roger.riggs at oracle.com <
> mailto:roger.riggs at oracle.com <roger.riggs at oracle.com>>>>
> >>     *Sent:* Friday, May 17, 2024 4:57:46 AM
> >>     *To:* core-libs-dev at openjdk.org <mailto:core-libs-dev at openjdk.org <
> mailto:core-libs-dev at openjdk.org <core-libs-dev at openjdk.org>>>
> >>     *Subject:* Re: Deterministic naming of subclasses of
> >>     `java/lang/reflect/Proxy`
> >>     Hi Aman,
> >>
> >>     You may also run into hidden classes (JEP 371: Hidden Classes) that
> >>     allow classes to be defined, at runtime, without names.
> >>     It has been proposed to use them for generated proxies but that
> >>     hasn't been implemented yet.
> >>     There are benefits to having nameless classes, because they can't be
> >>     referenced by name, only as a capability, they can be better
> >>     encapsulated.
> >>
> >>     fyi, Roger Riggs
> >>
> >>
> >>     On 5/16/24 8:11 AM, Aman Sharma wrote:
> >>>
> >>>     Hi,
> >>>
> >>>
> >>>     Thanks for your response, Liang!
> >>>
> >>>
> >>>     > I think you meant CVE-2021-42392 instead of 2022.
> >>>
> >>>
> >>>     Sorry of the error. I indeed meant CVE-2021-42392
> >>>     <https://nvd.nist.gov/vuln/detail/cve-2021-42392
> > <https://nvd.nist.gov/vuln/detail/cve-2021-42392>>.
> >>>
> >>>
> >>>     > Leyden mainly avoids this unstable generation by performing a
> >>>     training run to collect classes loaded
> >>>
> >>>
> >>>     Would love to know the details of Project Leyden and how they
> >>>     worked so far to focus on this goal. In our case, the training run
> >>>     is the test suite.
> >>>
> >>>
> >>>     > GeneratedConstructorAccessor is already retired by JEP 416 [2]
> >>>     in Java 18
> >>>
> >>>
> >>>     I did see them not appearing in my allowlist when I ran my study
> >>>     subject (Apache PDFBox) with Java 21. Thanks for letting me know
> >>>     about this JEP. I see they are re-implemented with method handles.
> >>>
> >>>
> >>>     > How are you checking the classes?
> >>>
> >>>
> >>>     To detect runtime generated code, we have javaagent that is hooked
> >>>     statically to the test suite execution. It gives us all classes
> >>>     that that is loaded post the JVM and the javaagent are loaded. So
> >>>     we only check the classes loaded for the purpose of running the
> >>>     application. This is also why we did not choose -agentlib as it
> >>>     would give classes for the setting up JVM and javaagent and we the
> >>>     user of our tool must the classes they load.
> >>>
> >>>
> >>>     Next, we have a `ClassFileTransformer` hook in the agent where we
> >>>     produce the checksum using the bytecode. And we compare the
> >>>     checksum with the one existing in the allowlist. The checksum
> >>>     computation algorithm is same for both steps. Let me describe how
> >>>     I compute the checksum.
> >>>
> >>>
> >>>      1. I get the CONSTANT_Class_info
> >>>         <
> https://docs.oracle.com/javase/specs/jvms/se11/html/jvms-4.html#jvms-4.4.1
> <
> https://docs.oracle.com/javase/specs/jvms/se11/html/jvms-4.html#jvms-4.4.1>>
> entry corresponding to `this_class` and rewrite the CONSTANT_Utf8_info <
> https://docs.oracle.com/javase/specs/jvms/se11/html/jvms-4.html#jvms-4.4.7
> <
> https://docs.oracle.com/javase/specs/jvms/se11/html/jvms-4.html#jvms-4.4.7>>
> corresponding to a fix String constant, say "foo".
> >>>      2. Since, the name of the class is used to refer to its types
> >>>         members (fields/method), I get all CONSTANT_Fieldref_info
> >>>         <
> https://docs.oracle.com/javase/specs/jvms/se11/html/jvms-4.html#jvms-4.4.2
> <
> https://docs.oracle.com/javase/specs/jvms/se11/html/jvms-4.html#jvms-4.4.2>>
> and if its `class_index` corresponds to the old `this_class`, we rewrite
> the UTF8 value of class_index to the same constant "foo".
> >>>      3. Next, since the naming of the fields, in Proxy classes, are
> >>>         also suffixed by numbers, for example, `private static Method
> >>>         m4`, we rewrite the UTF8 value of name in the
> >>>         CONSTANT_NameAndType_info
> >>>         <
> https://docs.oracle.com/javase/specs/jvms/se11/html/jvms-4.html#jvms-4.4.6
> <
> https://docs.oracle.com/javase/specs/jvms/se11/html/jvms-4.html#jvms-4.4.6
> >>.
> >>>      4. These fields can also have a random order so we simply sort
> >>>         the entire byte code using `Arrays.sort(byte[])` to eliminate
> >>>         any differences due to ordering of fields/methods.
> >>>      5. Simply sorting the byte array still had minute differences. I
> >>>         could not understand why they existed even though values in
> >>>         constant pool of the bytecode in allowlist and at runtime were
> >>>         exactly the same after rewriting. The differences existed in
> >>>         the bytes of the Code attribute of methods. I concluded that
> >>>         the bytes stored some position information. To avoid this, I
> >>>         created a subarray where I considered the bytes corresponding
> >>>         to `CONSTANT_Utf8_info.bytes` only. Computing a checksum for
> >>>         it resulted in the same checksums for both classfiles.
> >>>
> >>>
> >>>     Let's understand the whole approach with an example of Proxy class.
> >>>
> >>>     `
> >>>     public  final  class  $Proxy42  extends  Proxy  implements
> org.apache.logging.log4j.core.config.plugins.Plugin  {
> >>>     `
> >>>
> >>>     The will go in the allowlist as "Proxy_Plugin: <SHA256 checksum>".
> >>>
> >>>     When the same class is intercepted at runtime, say "$Proxy10", we
> >>>     look for "Proxy_Plugin" in the allowlist and since the checksum
> >>>     algorithm is same in both cases, we get a match and let the class
> >>>     load.
> >>>
> >>>     This approach has seemed to work well for Proxy classes, Generated
> >>>     Constructor Accessor (which is removed as you said). I also looked
> >>>     at the species generated by method handles. I did not notice any
> >>>     modification in them. Their name generation seemed okay to me. If
> >>>     some new Species are generated, it is of course detected since it
> >>>     is not in the allowlist.
> >>>
> >>>     I have not looked into LambdaMetafactory because I did not
> >>>     encounter it as a problem so far, but I am aware its name
> >>>     generation is also unstable. I have run my approach only a few
> >>>     projects only. And for hidden classes, I assume the the agent
> >>>     won't be able to intercept them so detecting them would be really
> >>>     hard.
> >>>
> >>>
> >>>     Regards,
> >>>     Aman Sharma
> >>>
> >>>     PhD Student
> >>>     KTH Royal Institute of Technology
> >>>     School of Electrical Engineering and Computer Science (EECS)
> >>>     Department of Theoretical Computer Science (TCS)
> >>>     <https://www.kth.se/profile/amansha
> > <https://www.kth.se/profile/amansha>>https://algomaster99.github.io/
> > <https://algomaster99.github.io/ <https://algomaster99.github.io/>>
> >>>
> ------------------------------------------------------------------------
> >>>     *From:* liangchenblue at gmail.com <mailto:liangchenblue at gmail.com <
> mailto:liangchenblue at gmail.com <liangchenblue at gmail.com>>>
> >>>     <liangchenblue at gmail.com> <mailto:liangchenblue at gmail.com <
> mailto:liangchenblue at gmail.com <liangchenblue at gmail.com>>>
> >>>     *Sent:* Thursday, May 16, 2024 5:52:03 AM
> >>>     *To:* Aman Sharma; core-libs-dev
> >>>     *Cc:* Martin Monperrus
> >>>     *Subject:* Re: Deterministic naming of subclasses of
> >>>     `java/lang/reflect/Proxy`
> >>>     Hi Aman,
> >>>     I think you meant CVE-2021-42392 instead of 2022.
> >>>
> >>>     For your approach of an "allowlist" for Java runtime, project
> >>>     Leyden is looking to generate a static image [1], that
> >>>     > At run time it cannot load classes from outside the image, nor
> >>>     can it create classes dynamically.
> >>>     Leyden mainly avoids this unstable generation by performing a
> >>>     training run to collect classes loaded and even object graphs; I
> >>>     am not familiar with the details unfortunately.
> >>>
> >>>     Otherwise, the Proxy discussion belongs better to core-libs-dev,
> >>>     as java.lang.reflect.Proxy is part of Java's core libraries. I am
> >>>     replying this thread to core-libs-dev.
> >>>
> >>>     For your perceived problem that classes don't have unique names,
> >>>     your description sounds dubious: GeneratedConstructorAccessor is
> >>>     already retired by JEP 416 [2] in Java 18, and there are many
> >>>     other cases in which JDK generates classes without stable names,
> >>>     notoriously LambdaMetafactory (Gradle wished for cacheable
> >>>     Lambdas); the same applies for the generated classes for
> >>>     MethodHandle's LambdaForms (which carries implementation code for
> >>>     LambdaForm). How are you checking the classes? It seems you are
> >>>     not checking hidden classes. Proxy and Lambda classes are defined
> >>>     by the caller's class loader, while LambdaForms are under JDK's
> >>>     system class loader I think. We need to ensure you are correctly
> >>>     finding all unstable classes before we can proceed.
> >>>
> >>>     [1]: https://openjdk.org/projects/leyden/notes/01-beginnings
> > <https://openjdk.org/projects/leyden/notes/01-beginnings>
> >>>     <https://openjdk.org/projects/leyden/notes/01-beginnings
> > <https://openjdk.org/projects/leyden/notes/01-beginnings>>
> >>>     [2]: https://openjdk.org/jeps/416 <https://openjdk.org/jeps/416>
> > <https://openjdk.org/jeps/416 <https://openjdk.org/jeps/416>>
> >>>
> >>>     On Wed, May 15, 2024 at 7:00?PM Aman Sharma <amansha at kth.se
> >>>     <mailto:amansha at kth.se <mailto:amansha at kth.se <amansha at kth.se>>>>
> wrote:
> >>>
> >>>         Hi,
> >>>
> >>>
> >>>         My name is Aman and I am a PhD student at KTH Royal Institute
> >>>         of Technology, Stockholm, Sweden. I research as part of CHAINS
> >>>         <https://chains.proj.kth.se/ <https://chains.proj.kth.se/>>
> project to
> > strengthen the
> >>>         software supply chain of multiple ecosystem. I particularly
> >>>         focus on runtime integrity in Java. In this email, I want to
> >>>         write about an issue I have discovered with /dynamic
> >>>         generation of `java.lang.reflect.Proxy`classes/. I will
> >>>         propose a solution and would love to hear the feedback from
> >>>         the community. Let me know if this is the correct mailing-list
> >>>         for such discussions. It seemed the most relevant from this
> >>>         list <https://mail.openjdk.org/mailman/listinfo
> > <https://mail.openjdk.org/mailman/listinfo>>.
> >>>
> >>>
> >>>         *My research*
> >>>
> >>>         *
> >>>         *
> >>>
> >>>         Java has features to load class on the fly - it can either
> >>>         download or generate a class at runtime. These features are
> >>>         useful for inner workings of JDK. For example, implementing
> >>>         annotations, reflective access, etc. However, these features
> >>>         have also contributed to critical vulnerabilities in the past
> >>>         - CVE-2021-44228  (log4shell), CVE-2022-33980, CVE-2022-42392.
> >>>         All of these vulnerabilities have one thing in common - /a
> >>>         class that was not known during build time was
> >>>         downloaded/generated at runtime and loaded into JVM./
> >>>
> >>>
> >>>         To defend against such vulnerabilities, we propose a solution
> >>>         to /allowlist classes for runtime/. This allowlist will
> >>>         contain an exhaustive list of classes that can be loaded by
> >>>         the JVM and it will be enforced at runtime. We build this
> >>>         allowlist from three sources:
> >>>
> >>>          1. All classes of all modules provided by the Java Standard
> >>>             Library. We use ClassGraph
> >>>             <https://github.com/classgraph/classgraph
> > <https://github.com/classgraph/classgraph>> to scan the JDK.
> >>>          2. We can take the source code and all dependencies of an
> >>>             application. We use a software bill of materials to get
> >>>             all the data.
> >>>          3. Finally, we use run the test suite to include any runtime
> >>>             downloaded/generated classes.
> >>>
> >>>         Such a list is able to prevent the above 3 CVEs because it
> >>>         does not let the "unknown" bytecode to be loaded.
> >>>
> >>>         *Problem with generating such an allowlist*
> >>>         *
> >>>         *
> >>>         The first two parts of the allowlist are easy to get. The
> >>>         problem is with the third step where we want to allowlist all
> >>>         the classes that could be downloaded or generated. Upon
> >>>         running the test suite and hooking to the classes it loads, we
> >>>         observer that the list consists of classes that are called
> >>>         "com/sun/proxy/$Proxy2",
> >>>         "jdk/internal/reflect/GeneratedConstructorAccessor3" among
> >>>         many more. The purpose of these classes can be identifed. The
> >>>         proxy class is created for to implement an annotation. The
> >>>         accessor gives access to constructor of a class to the JVM.
> >>>
> >>>         When enforcing this allowlist at runtime, we see that the
> >>>         bytecode content for "com/sun/proxy/$Proxy2" differs in the
> >>>         allowlist and at runtime. In our case, we we are experimenting
> >>>         with pdfbox <https://github.com/apache/pdfbox <
> https://github.com/apache/pdfbox>> so
> > we created
> >>>         the allowlist using its test suite. Then we enforced this
> >>>         allowlist while running some of its subcommands. However,
> >>>         there was some other proxy class say "com/sun/proxy/$Proxy5"
> >>>         at runtime that implemented the same interfaces and had the
> >>>         same methods as "com/sun/proxy/$Proxy2" in the allowlist. They
> >>>         only differed in the name of the class, order of fields, and
> >>>         types for fields references. This could happen because the
> >>>         order of the loading of class is workload dependent, but it
> >>>         causes problem to generate such an allowlist.
> >>>
> >>>         *Solution
> >>>         *
> >>>
> >>>
> >>>         We propose that naming of subclasses of
> >>>         "java/lang/reflect/Proxy" should not be dependent upon the
> >>>         order of loading. In order to do so, two issues can be fixed:
> >>>
> >>>          1. The naming of the class should not be based on AtomicLong
> >>>             <
> https://github.com/openjdk/jdk/blob/b687aa550837830b38f0f0faa69c353b1e85219c/src/java.base/share/classes/java/lang/reflect/Proxy.java#L531
> <
> https://github.com/openjdk/jdk/blob/b687aa550837830b38f0f0faa69c353b1e85219c/src/java.base/share/classes/java/lang/reflect/Proxy.java#L531>>.
> Rather it could be named based on the interfaces it implements. I also
> wonder why AtomicLong is chosen in the first place.
> >>>          2. Methods of the interfaces must be in a particular order.
> >>>             Right now, they are not sorted in any particular order
> >>>             <
> https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/lang/Class.java#L2178
> <
> https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/lang/Class.java#L2178
> >>.
> >>>
> >>>
> >>>         These fixes will make proxy class generation deterministic
> >>>         with respect to order of loading and won't be flagged at
> >>>         runtime since the test suite would already detect them.
> >>>
> >>>         I would love to hear from the community about these ideas. If
> >>>         in agreement, I would be happy to produce a patch. I have
> >>>         discovered this issue with subclasses of
> >>>         GeneratedConstructorAccessor
> >>>         <
> https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/jdk/internal/reflect/ConstructorAccessor.java
> <
> https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/jdk/internal/reflect/ConstructorAccessor.java>>
> as well and I imagine it will also apply to some other runtime generated
> classes. If you disagree, please let me know also. It helps with my
> research.
> >>>
> >>>         I also have PoCs for the above CVEs
> >>>         <https://github.com/chains-project/exploits-for-sbom.exe
> > <https://github.com/chains-project/exploits-for-sbom.exe>> and
> >>>         a proof concept tool is being developed under the name
> >>>         sbom.exe <https://github.com/chains-project/sbom.exe
> > <https://github.com/chains-project/sbom.exe>> in case
> >>>         any one wonders about the implementation. I would also be
> >>>         happy to explain more.
> >>>
> >>>         Regards,
> >>>         Aman Sharma
> >>>
> >>>         PhD Student
> >>>         KTH Royal Institute of Technology
> >>>         School of Electrical Engineering and Computer Science (EECS)
> >>>         Department of Theoretical Computer Science (TCS)
> >>>         <https://www.kth.se/profile/amansha
> > <https://www.kth.se/profile/amansha>>https://algomaster99.github.io/
> > <https://algomaster99.github.io/ <https://algomaster99.github.io/>>
> >>>
> >>
> >>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240522/2dd4a473/attachment-0001.htm>

From lorris.creantor at gmail.com  Wed May 22 12:15:45 2024
From: lorris.creantor at gmail.com (Lorris)
Date: Wed, 22 May 2024 14:15:45 +0200
Subject: GC triggered before VM initialization completed
Message-ID: <130E153F-409A-4B11-AD81-A01D5E24F870@gmail.com>

Hello,
I get an error when I try to run the java or javac commands on any file. The exact message is the following:

Error occurred during initialization of VM
GC triggered before VM initialization completed. Try increasing NewSize, current value 1331K.

I tried to increase the size up to 6G but it did not solve the problem. I am using a modified version of the opendjdk-22.0.1 (3 commits behind the master branch as I write this email). This version generates extra fields and methods to propagate parameterised types information. I am totally aware that the problem comes deep down from the version that I am using, but as the error does not provide any other information, I cannot figure out the origin of the problem. I also added at the end of this email the verbose trace of the java command (it always blocks at the same point, regardless of the allocated size), if it can be useful in any way.

Lorris Creantor

[0.013s][info][class,load] path: /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base
[0.013s][info][class,load] path: /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base
[0.014s][info][class,load] java.lang.Object source: /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base
[0.014s][info][class,load] java.io.Serializable source: /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base
[0.015s][info][class,load] java.lang.Comparable source: /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base
[0.015s][info][class,load] java.lang.CharSequence source: /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base
[0.015s][info][class,load] java.lang.constant.Constable source: /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base
[0.015s][info][class,load] java.lang.constant.ConstantDesc source: /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base
[0.015s][info][class,load] java.lang.String source: /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base
[0.016s][info][class,load] java.lang.reflect.AnnotatedElement source: /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base
[0.016s][info][class,load] java.lang.reflect.GenericDeclaration source: /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base
[0.016s][info][class,load] java.lang.reflect.Type source: /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base
[0.017s][info][class,load] java.lang.invoke.TypeDescriptor source: /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base
[0.017s][info][class,load] java.lang.invoke.TypeDescriptor$OfField source: /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base
[0.017s][info][class,load] java.lang.Class source: /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base
[0.017s][info][class,load] java.lang.Cloneable source: /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base
[0.018s][info][class,load] java.lang.ClassLoader source: /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base
[0.018s][info][class,load] java.lang.System source: /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base
[0.018s][info][class,load] java.lang.Throwable source: /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base
[0.018s][info][class,load] java.lang.Error source: /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base
[0.019s][info][class,load] java.lang.Exception source: /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base
[0.019s][info][class,load] java.lang.RuntimeException source: /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base
[0.019s][info][class,load] java.lang.SecurityManager source: /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base
[0.019s][info][class,load] java.security.ProtectionDomain source: /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base
[0.020s][info][class,load] java.security.AccessControlContext source: /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base
[0.020s][info][class,load] java.security.AccessController source: /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base
[0.020s][info][class,load] java.security.SecureClassLoader source: /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base
[0.020s][info][class,load] java.lang.ReflectiveOperationException source: /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base
[0.020s][info][class,load] java.lang.ClassNotFoundException source: /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base
[0.021s][info][class,load] java.lang.Record source: /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base
[0.021s][info][class,load] java.lang.LinkageError source: /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base
[0.021s][info][class,load] java.lang.NoClassDefFoundError source: /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base
[0.021s][info][class,load] java.lang.ClassCastException source: /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base
[0.021s][info][class,load] java.lang.ArrayStoreException source: /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base
[0.022s][info][class,load] java.lang.VirtualMachineError source: /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base
[0.022s][info][class,load] java.lang.InternalError source: /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base
[0.022s][info][class,load] java.lang.OutOfMemoryError source: /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base
[0.022s][info][class,load] java.lang.StackOverflowError source: /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base
[0.022s][info][class,load] java.lang.IllegalMonitorStateException source: /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base
[0.022s][info][class,load] java.lang.ref.Reference source: /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base
[0.023s][info][class,load] java.lang.ref.SoftReference source: /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base
[0.023s][info][class,load] java.lang.ref.WeakReference source: /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base
[0.023s][info][class,load] java.lang.ref.FinalReference source: /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base
[0.023s][info][class,load] java.lang.ref.PhantomReference source: /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base
[0.023s][info][class,load] java.lang.ref.Finalizer source: /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base
[0.024s][info][class,load] java.lang.Runnable source: /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base
[0.024s][info][class,load] java.lang.Thread source: /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base
[0.024s][info][class,load] java.lang.Thread$FieldHolder source: /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base
[0.024s][info][class,load] java.lang.Thread$Constants source: /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base
[0.025s][info][class,load] java.lang.Thread$UncaughtExceptionHandler source: /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base
[0.025s][info][class,load] java.lang.ThreadGroup source: /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base
[0.025s][info][class,load] java.lang.BaseVirtualThread source: /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base
[0.025s][info][class,load] java.lang.VirtualThread source: /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base
[0.025s][info][class,load] java.lang.ThreadBuilders$BoundVirtualThread source: /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base
[0.026s][info][class,load] java.util.Map source: /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base
[0.027s][info][class,load] java.util.Dictionary source: /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base
[0.027s][info][class,load] java.util.Hashtable source: /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base
[0.027s][info][class,load] java.util.Properties source: /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base
[0.027s][info][class,load] java.lang.Module source: /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base
[0.027s][info][class,load] java.lang.reflect.AccessibleObject source: /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base
[0.028s][info][class,load] java.lang.reflect.Member source: /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base
[0.028s][info][class,load] java.lang.reflect.Field source: /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base
[0.028s][info][class,load] java.lang.reflect.Parameter source: /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base
[0.028s][info][class,load] java.lang.reflect.Executable source: /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base
[0.028s][info][class,load] java.lang.reflect.Method source: /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base
[0.029s][info][class,load] java.lang.reflect.Constructor source: /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base
[0.029s][info][class,load] jdk.internal.vm.ContinuationScope source: /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base
[0.029s][info][class,load] jdk.internal.vm.Continuation source: /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base
[0.029s][info][class,load] jdk.internal.vm.StackChunk source: /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base
[0.029s][info][class,load] jdk.internal.reflect.MethodAccessor source: /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base
[0.030s][info][class,load] jdk.internal.reflect.MagicAccessorImpl source: /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base
[0.030s][info][class,load] jdk.internal.reflect.MethodAccessorImpl source: /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base
[0.030s][info][class,load] jdk.internal.reflect.DelegatingClassLoader source: /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base
[0.030s][info][class,load] jdk.internal.reflect.ConstantPool source: /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base
[0.031s][info][class,load] java.lang.annotation.Annotation source: /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base
[0.031s][info][class,load] jdk.internal.reflect.CallerSensitive source: /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base
[0.031s][info][class,load] jdk.internal.reflect.ConstructorAccessor source: /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base
[0.031s][info][class,load] jdk.internal.reflect.ConstructorAccessorImpl source: /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base
[0.031s][info][class,load] jdk.internal.reflect.DirectConstructorHandleAccessor$NativeAccessor source: /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base
[0.032s][info][class,load] jdk.internal.reflect.SerializationConstructorAccessorImpl source: /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base
[0.032s][info][class,load] java.lang.invoke.MethodHandle source: /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base
[0.032s][info][class,load] java.lang.invoke.DirectMethodHandle source: /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base
[0.033s][info][class,load] java.lang.invoke.VarHandle source: /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base
[0.033s][info][class,load] java.lang.invoke.MemberName source: /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base
[0.033s][info][class,load] java.lang.invoke.ResolvedMethodName source: /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base
[0.033s][info][class,load] java.lang.invoke.MethodHandleNatives source: /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base
[0.034s][info][class,load] java.lang.invoke.LambdaForm source: /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base
[0.034s][info][class,load] java.lang.invoke.TypeDescriptor$OfMethod source: /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base
[0.034s][info][class,load] java.lang.invoke.MethodType source: /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base
[0.034s][info][class,load] java.lang.BootstrapMethodError source: /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base
[0.034s][info][class,load] java.lang.invoke.CallSite source: /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base
[0.035s][info][class,load] jdk.internal.foreign.abi.NativeEntryPoint source: /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base
[0.035s][info][class,load] jdk.internal.foreign.abi.ABIDescriptor source: /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base
[0.036s][info][class,load] jdk.internal.foreign.abi.VMStorage source: /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base
[0.037s][info][class,load] jdk.internal.foreign.abi.UpcallLinker$CallRegs source: /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base
[0.037s][info][class,load] java.lang.invoke.MethodHandleNatives$CallSiteContext source: /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base
[0.037s][info][class,load] java.lang.invoke.ConstantCallSite source: /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base
[0.037s][info][class,load] java.lang.invoke.MutableCallSite source: /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base
[0.037s][info][class,load] java.lang.invoke.VolatileCallSite source: /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base
[0.038s][info][class,load] java.lang.AssertionStatusDirectives source: /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base
[0.038s][info][class,load] java.lang.Appendable source: /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base
[0.039s][info][class,load] java.lang.AbstractStringBuilder source: /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base
[0.039s][info][class,load] java.lang.StringBuffer source: /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base
[0.039s][info][class,load] java.lang.StringBuilder source: /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base
[0.039s][info][class,load] jdk.internal.misc.UnsafeConstants source: /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base
[0.040s][info][class,load] jdk.internal.misc.Unsafe source: /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base
[0.040s][info][class,load] jdk.internal.module.Modules source: /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base
[0.041s][info][class,load] java.lang.AutoCloseable source: /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base
[0.041s][info][class,load] java.io.Closeable source: /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base
[0.041s][info][class,load] java.io.InputStream source: /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base
[0.041s][info][class,load] java.io.ByteArrayInputStream source: /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base
[0.041s][info][class,load] java.net.URL source: /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base
[0.042s][info][class,load] java.net.URLClassLoader source: /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base
[0.042s][info][class,load] java.lang.Enum source: /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base
[0.042s][info][class,load] java.util.jar.Manifest source: /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base
[0.043s][info][class,load] jdk.internal.loader.BuiltinClassLoader source: /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base
[0.043s][info][class,load] jdk.internal.loader.ClassLoaders source: /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base
[0.043s][info][class,load] jdk.internal.loader.ClassLoaders$AppClassLoader source: /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base
[0.044s][info][class,load] jdk.internal.loader.ClassLoaders$PlatformClassLoader source: /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base
[0.044s][info][class,load] java.security.CodeSource source: /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base
[0.045s][info][class,load] java.util.concurrent.ConcurrentMap source: /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base
[0.045s][info][class,load] java.util.AbstractMap source: /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base
[0.045s][info][class,load] java.util.concurrent.ConcurrentHashMap source: /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base
[0.046s][info][class,load] java.lang.Iterable source: /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base
[0.046s][info][class,load] java.util.Collection source: /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base
[0.046s][info][class,load] java.util.SequencedCollection source: /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base
[0.046s][info][class,load] java.util.List source: /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base
[0.046s][info][class,load] java.util.RandomAccess source: /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base
[0.046s][info][class,load] java.util.AbstractCollection source: /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base
[0.046s][info][class,load] java.util.AbstractList source: /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base
[0.047s][info][class,load] java.util.ArrayList source: /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base
[0.047s][info][class,load] java.lang.StackTraceElement source: /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base
[0.047s][info][class,load] java.nio.Buffer source: /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base
[0.047s][info][class,load] java.lang.StackWalker source: /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base
[0.047s][info][class,load] java.lang.StackStreamFactory$AbstractStackWalker source: /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base
[0.048s][info][class,load] java.lang.StackWalker$StackFrame source: /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base
[0.048s][info][class,load] java.lang.ClassFrameInfo source: /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base
[0.048s][info][class,load] java.lang.StackFrameInfo source: /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base
[0.048s][info][class,load] java.lang.LiveStackFrame source: /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base
[0.048s][info][class,load] java.lang.LiveStackFrameInfo source: /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base
[0.049s][info][class,load] java.util.concurrent.locks.AbstractOwnableSynchronizer source: /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base
[0.049s][info][class,load] java.lang.Boolean source: /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base
[0.049s][info][class,load] java.lang.Character source: /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base
[0.050s][info][class,load] java.lang.Number source: /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base
[0.050s][info][class,load] java.lang.Float source: /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base
[0.050s][info][class,load] java.lang.Double source: /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base
[0.050s][info][class,load] java.lang.Byte source: /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base
[0.050s][info][class,load] java.lang.Short source: /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base
[0.050s][info][class,load] java.lang.Integer source: /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base
[0.051s][info][class,load] java.lang.Long source: /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base
[0.051s][info][class,load] java.util.Iterator source: /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base
[0.051s][info][class,load] java.lang.reflect.RecordComponent source: /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base
[0.052s][info][class,load] jdk.internal.vm.vector.VectorSupport source: /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base
[0.052s][info][class,load] jdk.internal.vm.vector.VectorSupport$VectorPayload source: /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base
[0.052s][info][class,load] jdk.internal.vm.vector.VectorSupport$Vector source: /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base
[0.052s][info][class,load] jdk.internal.vm.vector.VectorSupport$VectorMask source: /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base
[0.052s][info][class,load] jdk.internal.vm.vector.VectorSupport$VectorShuffle source: /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base
[0.053s][info][class,load] jdk.internal.vm.FillerObject source: /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base
[0.054s][info][class,load] java.lang.NullPointerException source: /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base
[0.054s][info][class,load] java.lang.ArithmeticException source: /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base
[0.055s][info][class,load] java.io.ObjectStreamField source: /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base
[0.056s][info][class,load] java.util.Comparator source: /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base
[0.056s][info][class,load] java.lang.String$CaseInsensitiveComparator source: /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base
[0.056s][info][class,load] jdk.internal.misc.VM source: /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base
[0.057s][info][class,load] java.lang.Module$ArchivedData source: /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base
[0.057s][info][class,load] jdk.internal.misc.CDS source: /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base
[0.058s][info][class,load] java.util.ptype.Arg source: /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base
[0.058s][info][class,load] java.util.ptype.ClassType source: /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base
[0.058s][info][class,load] java.util.ptype.Utils source: /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base
[0.058s][info][class,load] java.util.ptype.ClassType$1 source: /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base
[0.059s][info][class,load] java.util.ptype.MethodTypeArgs source: /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base
[0.059s][info][class,load] java.util.ptype.ArgList source: /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base
[0.059s][info][class,load] java.util.ptype.MethodTypeArgs$1 source: /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base
[0.059s][info][class,load] java.util.Set source: /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base
[0.059s][info][class,load] java.util.Objects source: /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base
[0.060s][info][class,load] jdk.internal.util.Preconditions source: /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base
[0.060s][info][class,load] java.lang.IndexOutOfBoundsException source: /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base
[0.060s][info][class,load] java.lang.StringIndexOutOfBoundsException source: /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base
[0.060s][info][class,load] java.util.function.Function source: /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base
[0.060s][info][class,load] jdk.internal.util.Preconditions$1 source: /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base
[0.061s][info][class,load] java.util.function.BiFunction source: /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base
[0.061s][info][class,load] java.util.ptype.ParameterizedType source: /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base
[0.061s][info][class,load] java.util.ptype.ParameterizedType$1 source: /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base
[0.061s][info][class,load] java.util.ptype.RawType source: /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base
[0.061s][info][class,load] java.util.ptype.RawType$1 source: /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base
[0.061s][info][class,load] java.util.ptype.TypeOperations source: /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base
[0.061s][info][class,load] jdk.internal.util.Preconditions$4 source: /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base
[0.062s][info][class,load] java.lang.ArrayIndexOutOfBoundsException source: /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base
[0.062s][info][class,load] jdk.internal.util.Preconditions$2 source: /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base
[0.062s][info][class,load] jdk.internal.util.Preconditions$3 source: /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base
[0.063s][info][class,load] java.util.ImmutableCollections$AbstractImmutableCollection source: /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base
[0.063s][info][class,load] java.util.ImmutableCollections$AbstractImmutableSet source: /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base
[0.063s][info][class,load] java.util.ImmutableCollections$Set12 source: /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base
[0.063s][info][class,load] java.util.ptype.TypeArgUtils source: /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base
[0.064s][info][class,load] java.lang.runtime.SwitchBootstraps source: /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base
[0.064s][info][class,load] java.lang.invoke.MethodHandles$Lookup source: /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base
[0.064s][info][class,load] java.util.ptype.Wildcard source: /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base
[0.064s][info][class,load] java.util.ptype.Wildcard$1 source: /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base
[0.064s][info][class,load] java.util.ptype.ArrayType source: /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base
[0.065s][info][class,load] java.util.ptype.ArrayType$1 source: /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base
[0.065s][info][class,load] jdk.internal.util.ReferenceKey source: /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base
[0.065s][info][class,load] java.util.function.Supplier source: /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base
[0.065s][info][class,load] java.lang.invoke.MethodType$1 source: /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base
[0.066s][info][class,load] java.util.AbstractSet source: /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base
[0.066s][info][class,load] jdk.internal.util.ReferencedKeySet source: /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base
[0.066s][info][class,load] java.lang.IllegalArgumentException source: /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base
[0.067s][info][class,load] java.util.Collections source: /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base
[0.067s][info][class,load] java.util.Collections$EmptySet source: /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base
[0.068s][info][class,load] jdk.internal.util.ArraysSupport source: /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base
[0.068s][info][class,load] jdk.internal.access.SharedSecrets source: /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base
[0.069s][info][class,load] java.lang.Math source: /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base
[0.069s][info][class,load] java.util.Arrays source: /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base
[0.070s][info][class,load] java.lang.ExceptionInInitializerError source: /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base
[0.071s][info][class,load] java.lang.IllegalStateException source: /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base
Error occurred during initialization of VM
GC triggered before VM initialization completed. Try increasing NewSize, current value 1331K.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240522/8a3a41e0/attachment-0001.htm>

From liangchenblue at gmail.com  Wed May 22 12:25:03 2024
From: liangchenblue at gmail.com (Chen Liang)
Date: Wed, 22 May 2024 07:25:03 -0500
Subject: GC triggered before VM initialization completed
In-Reply-To: <130E153F-409A-4B11-AD81-A01D5E24F870@gmail.com>
References: <130E153F-409A-4B11-AD81-A01D5E24F870@gmail.com>
Message-ID: <CABe8uE07nVCb40hy-QB+z9YspkUJ2wMTtvUezSJM_euiLV8f1w@mail.gmail.com>

Hi Lorris,
This mailing list is for Java's core libraries' development. Your issue is
a support request and is not related to Java's core libraries in any way,
thus I recommend you look for tech support or create/find an issue at
bugs.java.com.

Regards, Chen

On Wed, May 22, 2024 at 7:16?AM Lorris <lorris.creantor at gmail.com> wrote:

> Hello,
> I get an error when I try to run the java or javac commands on any file.
> The exact message is the following:
>
> *Error occurred during initialization of VM*
> *GC triggered before VM initialization completed. Try increasing NewSize,
> current value 1331K.*
>
> I tried to increase the size up to 6G but it did not solve the problem. I
> am using a modified version of the opendjdk-22.0.1 (3 commits behind the
> master branch as I write this email). This version generates extra fields
> and methods to propagate parameterised types information. I am totally
> aware that the problem comes deep down from the version that I am using,
> but as the error does not provide any other information, I cannot figure
> out the origin of the problem. I also added at the end of this email the
> verbose trace of the java command (it always blocks at the same point,
> regardless of the allocated size), if it can be useful in any way.
>
> Lorris Creantor
>
> *[0.013s][info][class,load] path:
> /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base*
> *[0.013s][info][class,load] path:
> /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base*
> *[0.014s][info][class,load] java.lang.Object source:
> /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base*
> *[0.014s][info][class,load] java.io.Serializable source:
> /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base*
> *[0.015s][info][class,load] java.lang.Comparable source:
> /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base*
> *[0.015s][info][class,load] java.lang.CharSequence source:
> /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base*
> *[0.015s][info][class,load] java.lang.constant.Constable source:
> /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base*
> *[0.015s][info][class,load] java.lang.constant.ConstantDesc source:
> /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base*
> *[0.015s][info][class,load] java.lang.String source:
> /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base*
> *[0.016s][info][class,load] java.lang.reflect.AnnotatedElement source:
> /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base*
> *[0.016s][info][class,load] java.lang.reflect.GenericDeclaration source:
> /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base*
> *[0.016s][info][class,load] java.lang.reflect.Type source:
> /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base*
> *[0.017s][info][class,load] java.lang.invoke.TypeDescriptor source:
> /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base*
> *[0.017s][info][class,load] java.lang.invoke.TypeDescriptor$OfField
> source:
> /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base*
> *[0.017s][info][class,load] java.lang.Class source:
> /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base*
> *[0.017s][info][class,load] java.lang.Cloneable source:
> /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base*
> *[0.018s][info][class,load] java.lang.ClassLoader source:
> /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base*
> *[0.018s][info][class,load] java.lang.System source:
> /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base*
> *[0.018s][info][class,load] java.lang.Throwable source:
> /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base*
> *[0.018s][info][class,load] java.lang.Error source:
> /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base*
> *[0.019s][info][class,load] java.lang.Exception source:
> /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base*
> *[0.019s][info][class,load] java.lang.RuntimeException source:
> /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base*
> *[0.019s][info][class,load] java.lang.SecurityManager source:
> /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base*
> *[0.019s][info][class,load] java.security.ProtectionDomain source:
> /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base*
> *[0.020s][info][class,load] java.security.AccessControlContext source:
> /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base*
> *[0.020s][info][class,load] java.security.AccessController source:
> /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base*
> *[0.020s][info][class,load] java.security.SecureClassLoader source:
> /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base*
> *[0.020s][info][class,load] java.lang.ReflectiveOperationException source:
> /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base*
> *[0.020s][info][class,load] java.lang.ClassNotFoundException source:
> /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base*
> *[0.021s][info][class,load] java.lang.Record source:
> /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base*
> *[0.021s][info][class,load] java.lang.LinkageError source:
> /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base*
> *[0.021s][info][class,load] java.lang.NoClassDefFoundError source:
> /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base*
> *[0.021s][info][class,load] java.lang.ClassCastException source:
> /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base*
> *[0.021s][info][class,load] java.lang.ArrayStoreException source:
> /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base*
> *[0.022s][info][class,load] java.lang.VirtualMachineError source:
> /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base*
> *[0.022s][info][class,load] java.lang.InternalError source:
> /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base*
> *[0.022s][info][class,load] java.lang.OutOfMemoryError source:
> /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base*
> *[0.022s][info][class,load] java.lang.StackOverflowError source:
> /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base*
> *[0.022s][info][class,load] java.lang.IllegalMonitorStateException source:
> /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base*
> *[0.022s][info][class,load] java.lang.ref.Reference source:
> /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base*
> *[0.023s][info][class,load] java.lang.ref.SoftReference source:
> /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base*
> *[0.023s][info][class,load] java.lang.ref.WeakReference source:
> /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base*
> *[0.023s][info][class,load] java.lang.ref.FinalReference source:
> /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base*
> *[0.023s][info][class,load] java.lang.ref.PhantomReference source:
> /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base*
> *[0.023s][info][class,load] java.lang.ref.Finalizer source:
> /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base*
> *[0.024s][info][class,load] java.lang.Runnable source:
> /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base*
> *[0.024s][info][class,load] java.lang.Thread source:
> /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base*
> *[0.024s][info][class,load] java.lang.Thread$FieldHolder source:
> /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base*
> *[0.024s][info][class,load] java.lang.Thread$Constants source:
> /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base*
> *[0.025s][info][class,load] java.lang.Thread$UncaughtExceptionHandler
> source:
> /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base*
> *[0.025s][info][class,load] java.lang.ThreadGroup source:
> /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base*
> *[0.025s][info][class,load] java.lang.BaseVirtualThread source:
> /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base*
> *[0.025s][info][class,load] java.lang.VirtualThread source:
> /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base*
> *[0.025s][info][class,load] java.lang.ThreadBuilders$BoundVirtualThread
> source:
> /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base*
> *[0.026s][info][class,load] java.util.Map source:
> /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base*
> *[0.027s][info][class,load] java.util.Dictionary source:
> /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base*
> *[0.027s][info][class,load] java.util.Hashtable source:
> /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base*
> *[0.027s][info][class,load] java.util.Properties source:
> /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base*
> *[0.027s][info][class,load] java.lang.Module source:
> /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base*
> *[0.027s][info][class,load] java.lang.reflect.AccessibleObject source:
> /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base*
> *[0.028s][info][class,load] java.lang.reflect.Member source:
> /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base*
> *[0.028s][info][class,load] java.lang.reflect.Field source:
> /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base*
> *[0.028s][info][class,load] java.lang.reflect.Parameter source:
> /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base*
> *[0.028s][info][class,load] java.lang.reflect.Executable source:
> /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base*
> *[0.028s][info][class,load] java.lang.reflect.Method source:
> /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base*
> *[0.029s][info][class,load] java.lang.reflect.Constructor source:
> /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base*
> *[0.029s][info][class,load] jdk.internal.vm.ContinuationScope source:
> /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base*
> *[0.029s][info][class,load] jdk.internal.vm.Continuation source:
> /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base*
> *[0.029s][info][class,load] jdk.internal.vm.StackChunk source:
> /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base*
> *[0.029s][info][class,load] jdk.internal.reflect.MethodAccessor source:
> /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base*
> *[0.030s][info][class,load] jdk.internal.reflect.MagicAccessorImpl source:
> /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base*
> *[0.030s][info][class,load] jdk.internal.reflect.MethodAccessorImpl
> source:
> /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base*
> *[0.030s][info][class,load] jdk.internal.reflect.DelegatingClassLoader
> source:
> /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base*
> *[0.030s][info][class,load] jdk.internal.reflect.ConstantPool source:
> /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base*
> *[0.031s][info][class,load] java.lang.annotation.Annotation source:
> /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base*
> *[0.031s][info][class,load] jdk.internal.reflect.CallerSensitive source:
> /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base*
> *[0.031s][info][class,load] jdk.internal.reflect.ConstructorAccessor
> source:
> /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base*
> *[0.031s][info][class,load] jdk.internal.reflect.ConstructorAccessorImpl
> source:
> /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base*
> *[0.031s][info][class,load]
> jdk.internal.reflect.DirectConstructorHandleAccessor$NativeAccessor source:
> /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base*
> *[0.032s][info][class,load]
> jdk.internal.reflect.SerializationConstructorAccessorImpl source:
> /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base*
> *[0.032s][info][class,load] java.lang.invoke.MethodHandle source:
> /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base*
> *[0.032s][info][class,load] java.lang.invoke.DirectMethodHandle source:
> /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base*
> *[0.033s][info][class,load] java.lang.invoke.VarHandle source:
> /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base*
> *[0.033s][info][class,load] java.lang.invoke.MemberName source:
> /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base*
> *[0.033s][info][class,load] java.lang.invoke.ResolvedMethodName source:
> /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base*
> *[0.033s][info][class,load] java.lang.invoke.MethodHandleNatives source:
> /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base*
> *[0.034s][info][class,load] java.lang.invoke.LambdaForm source:
> /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base*
> *[0.034s][info][class,load] java.lang.invoke.TypeDescriptor$OfMethod
> source:
> /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base*
> *[0.034s][info][class,load] java.lang.invoke.MethodType source:
> /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base*
> *[0.034s][info][class,load] java.lang.BootstrapMethodError source:
> /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base*
> *[0.034s][info][class,load] java.lang.invoke.CallSite source:
> /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base*
> *[0.035s][info][class,load] jdk.internal.foreign.abi.NativeEntryPoint
> source:
> /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base*
> *[0.035s][info][class,load] jdk.internal.foreign.abi.ABIDescriptor source:
> /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base*
> *[0.036s][info][class,load] jdk.internal.foreign.abi.VMStorage source:
> /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base*
> *[0.037s][info][class,load] jdk.internal.foreign.abi.UpcallLinker$CallRegs
> source:
> /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base*
> *[0.037s][info][class,load]
> java.lang.invoke.MethodHandleNatives$CallSiteContext source:
> /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base*
> *[0.037s][info][class,load] java.lang.invoke.ConstantCallSite source:
> /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base*
> *[0.037s][info][class,load] java.lang.invoke.MutableCallSite source:
> /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base*
> *[0.037s][info][class,load] java.lang.invoke.VolatileCallSite source:
> /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base*
> *[0.038s][info][class,load] java.lang.AssertionStatusDirectives source:
> /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base*
> *[0.038s][info][class,load] java.lang.Appendable source:
> /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base*
> *[0.039s][info][class,load] java.lang.AbstractStringBuilder source:
> /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base*
> *[0.039s][info][class,load] java.lang.StringBuffer source:
> /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base*
> *[0.039s][info][class,load] java.lang.StringBuilder source:
> /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base*
> *[0.039s][info][class,load] jdk.internal.misc.UnsafeConstants source:
> /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base*
> *[0.040s][info][class,load] jdk.internal.misc.Unsafe source:
> /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base*
> *[0.040s][info][class,load] jdk.internal.module.Modules source:
> /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base*
> *[0.041s][info][class,load] java.lang.AutoCloseable source:
> /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base*
> *[0.041s][info][class,load] java.io.Closeable source:
> /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base*
> *[0.041s][info][class,load] java.io.InputStream source:
> /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base*
> *[0.041s][info][class,load] java.io.ByteArrayInputStream source:
> /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base*
> *[0.041s][info][class,load] java.net.URL source:
> /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base*
> *[0.042s][info][class,load] java.net.URLClassLoader source:
> /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base*
> *[0.042s][info][class,load] java.lang.Enum source:
> /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base*
> *[0.042s][info][class,load] java.util.jar.Manifest source:
> /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base*
> *[0.043s][info][class,load] jdk.internal.loader.BuiltinClassLoader source:
> /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base*
> *[0.043s][info][class,load] jdk.internal.loader.ClassLoaders source:
> /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base*
> *[0.043s][info][class,load]
> jdk.internal.loader.ClassLoaders$AppClassLoader source:
> /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base*
> *[0.044s][info][class,load]
> jdk.internal.loader.ClassLoaders$PlatformClassLoader source:
> /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base*
> *[0.044s][info][class,load] java.security.CodeSource source:
> /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base*
> *[0.045s][info][class,load] java.util.concurrent.ConcurrentMap source:
> /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base*
> *[0.045s][info][class,load] java.util.AbstractMap source:
> /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base*
> *[0.045s][info][class,load] java.util.concurrent.ConcurrentHashMap source:
> /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base*
> *[0.046s][info][class,load] java.lang.Iterable source:
> /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base*
> *[0.046s][info][class,load] java.util.Collection source:
> /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base*
> *[0.046s][info][class,load] java.util.SequencedCollection source:
> /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base*
> *[0.046s][info][class,load] java.util.List source:
> /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base*
> *[0.046s][info][class,load] java.util.RandomAccess source:
> /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base*
> *[0.046s][info][class,load] java.util.AbstractCollection source:
> /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base*
> *[0.046s][info][class,load] java.util.AbstractList source:
> /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base*
> *[0.047s][info][class,load] java.util.ArrayList source:
> /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base*
> *[0.047s][info][class,load] java.lang.StackTraceElement source:
> /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base*
> *[0.047s][info][class,load] java.nio.Buffer source:
> /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base*
> *[0.047s][info][class,load] java.lang.StackWalker source:
> /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base*
> *[0.047s][info][class,load]
> java.lang.StackStreamFactory$AbstractStackWalker source:
> /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base*
> *[0.048s][info][class,load] java.lang.StackWalker$StackFrame source:
> /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base*
> *[0.048s][info][class,load] java.lang.ClassFrameInfo source:
> /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base*
> *[0.048s][info][class,load] java.lang.StackFrameInfo source:
> /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base*
> *[0.048s][info][class,load] java.lang.LiveStackFrame source:
> /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base*
> *[0.048s][info][class,load] java.lang.LiveStackFrameInfo source:
> /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base*
> *[0.049s][info][class,load]
> java.util.concurrent.locks.AbstractOwnableSynchronizer source:
> /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base*
> *[0.049s][info][class,load] java.lang.Boolean source:
> /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base*
> *[0.049s][info][class,load] java.lang.Character source:
> /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base*
> *[0.050s][info][class,load] java.lang.Number source:
> /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base*
> *[0.050s][info][class,load] java.lang.Float source:
> /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base*
> *[0.050s][info][class,load] java.lang.Double source:
> /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base*
> *[0.050s][info][class,load] java.lang.Byte source:
> /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base*
> *[0.050s][info][class,load] java.lang.Short source:
> /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base*
> *[0.050s][info][class,load] java.lang.Integer source:
> /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base*
> *[0.051s][info][class,load] java.lang.Long source:
> /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base*
> *[0.051s][info][class,load] java.util.Iterator source:
> /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base*
> *[0.051s][info][class,load] java.lang.reflect.RecordComponent source:
> /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base*
> *[0.052s][info][class,load] jdk.internal.vm.vector.VectorSupport source:
> /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base*
> *[0.052s][info][class,load]
> jdk.internal.vm.vector.VectorSupport$VectorPayload source:
> /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base*
> *[0.052s][info][class,load] jdk.internal.vm.vector.VectorSupport$Vector
> source:
> /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base*
> *[0.052s][info][class,load]
> jdk.internal.vm.vector.VectorSupport$VectorMask source:
> /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base*
> *[0.052s][info][class,load]
> jdk.internal.vm.vector.VectorSupport$VectorShuffle source:
> /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base*
> *[0.053s][info][class,load] jdk.internal.vm.FillerObject source:
> /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base*
> *[0.054s][info][class,load] java.lang.NullPointerException source:
> /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base*
> *[0.054s][info][class,load] java.lang.ArithmeticException source:
> /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base*
> *[0.055s][info][class,load] java.io.ObjectStreamField source:
> /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base*
> *[0.056s][info][class,load] java.util.Comparator source:
> /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base*
> *[0.056s][info][class,load] java.lang.String$CaseInsensitiveComparator
> source:
> /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base*
> *[0.056s][info][class,load] jdk.internal.misc.VM source:
> /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base*
> *[0.057s][info][class,load] java.lang.Module$ArchivedData source:
> /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base*
> *[0.057s][info][class,load] jdk.internal.misc.CDS source:
> /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base*
> *[0.058s][info][class,load] java.util.ptype.Arg source:
> /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base*
> *[0.058s][info][class,load] java.util.ptype.ClassType source:
> /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base*
> *[0.058s][info][class,load] java.util.ptype.Utils source:
> /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base*
> *[0.058s][info][class,load] java.util.ptype.ClassType$1 source:
> /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base*
> *[0.059s][info][class,load] java.util.ptype.MethodTypeArgs source:
> /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base*
> *[0.059s][info][class,load] java.util.ptype.ArgList source:
> /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base*
> *[0.059s][info][class,load] java.util.ptype.MethodTypeArgs$1 source:
> /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base*
> *[0.059s][info][class,load] java.util.Set source:
> /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base*
> *[0.059s][info][class,load] java.util.Objects source:
> /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base*
> *[0.060s][info][class,load] jdk.internal.util.Preconditions source:
> /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base*
> *[0.060s][info][class,load] java.lang.IndexOutOfBoundsException source:
> /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base*
> *[0.060s][info][class,load] java.lang.StringIndexOutOfBoundsException
> source:
> /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base*
> *[0.060s][info][class,load] java.util.function.Function source:
> /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base*
> *[0.060s][info][class,load] jdk.internal.util.Preconditions$1 source:
> /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base*
> *[0.061s][info][class,load] java.util.function.BiFunction source:
> /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base*
> *[0.061s][info][class,load] java.util.ptype.ParameterizedType source:
> /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base*
> *[0.061s][info][class,load] java.util.ptype.ParameterizedType$1 source:
> /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base*
> *[0.061s][info][class,load] java.util.ptype.RawType source:
> /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base*
> *[0.061s][info][class,load] java.util.ptype.RawType$1 source:
> /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base*
> *[0.061s][info][class,load] java.util.ptype.TypeOperations source:
> /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base*
> *[0.061s][info][class,load] jdk.internal.util.Preconditions$4 source:
> /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base*
> *[0.062s][info][class,load] java.lang.ArrayIndexOutOfBoundsException
> source:
> /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base*
> *[0.062s][info][class,load] jdk.internal.util.Preconditions$2 source:
> /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base*
> *[0.062s][info][class,load] jdk.internal.util.Preconditions$3 source:
> /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base*
> *[0.063s][info][class,load]
> java.util.ImmutableCollections$AbstractImmutableCollection source:
> /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base*
> *[0.063s][info][class,load]
> java.util.ImmutableCollections$AbstractImmutableSet source:
> /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base*
> *[0.063s][info][class,load] java.util.ImmutableCollections$Set12 source:
> /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base*
> *[0.063s][info][class,load] java.util.ptype.TypeArgUtils source:
> /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base*
> *[0.064s][info][class,load] java.lang.runtime.SwitchBootstraps source:
> /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base*
> *[0.064s][info][class,load] java.lang.invoke.MethodHandles$Lookup source:
> /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base*
> *[0.064s][info][class,load] java.util.ptype.Wildcard source:
> /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base*
> *[0.064s][info][class,load] java.util.ptype.Wildcard$1 source:
> /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base*
> *[0.064s][info][class,load] java.util.ptype.ArrayType source:
> /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base*
> *[0.065s][info][class,load] java.util.ptype.ArrayType$1 source:
> /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base*
> *[0.065s][info][class,load] jdk.internal.util.ReferenceKey source:
> /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base*
> *[0.065s][info][class,load] java.util.function.Supplier source:
> /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base*
> *[0.065s][info][class,load] java.lang.invoke.MethodType$1 source:
> /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base*
> *[0.066s][info][class,load] java.util.AbstractSet source:
> /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base*
> *[0.066s][info][class,load] jdk.internal.util.ReferencedKeySet source:
> /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base*
> *[0.066s][info][class,load] java.lang.IllegalArgumentException source:
> /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base*
> *[0.067s][info][class,load] java.util.Collections source:
> /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base*
> *[0.067s][info][class,load] java.util.Collections$EmptySet source:
> /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base*
> *[0.068s][info][class,load] jdk.internal.util.ArraysSupport source:
> /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base*
> *[0.068s][info][class,load] jdk.internal.access.SharedSecrets source:
> /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base*
> *[0.069s][info][class,load] java.lang.Math source:
> /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base*
> *[0.069s][info][class,load] java.util.Arrays source:
> /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base*
> *[0.070s][info][class,load] java.lang.ExceptionInInitializerError source:
> /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base*
> *[0.071s][info][class,load] java.lang.IllegalStateException source:
> /Users/lorris/IdeaProjects/jdk/build/macosx-aarch64-server-release/jdk/modules/java.base*
> *Error occurred during initialization of VM*
> *GC triggered before VM initialization completed. Try increasing NewSize,
> current value 1331K.*
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240522/1ba0940c/attachment-0001.htm>

From sgehwolf at openjdk.org  Wed May 22 12:28:15 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Wed, 22 May 2024 12:28:15 GMT
Subject: RFR: 8311302: Allow for jlinking a custom runtime without packaged
 modules being present [v25]
In-Reply-To: <T2CisOVBsFa0zK5HXXOkvh54HHQFRU1xJpAxhZ_Yfe4=.f7b0b3e0-e109-4e95-a513-9100ee08b598@github.com>
References: <Z0DJ87uKPbjS6mvJIE_oG5m-RWsbERXsytSgV8Bmhdo=.f8723513-0ac6-4e85-9131-3c3924860c61@github.com>
 <2Hs5V_cOOhOtXxrKvM0ATWxJFO62xd3RtScyPEb5puI=.f16650ac-9812-40ed-a93c-a5dd4b396ad2@github.com>
 <EjF8YVHfHr9qm_5w3BLUSFhP-cQ_BR6Fcs_8-oKzpZo=.3cdf9de7-b75c-4848-93ed-173ac6060a3f@github.com>
 <BXZ-wDhkakio3dYE5xnHxEuIdyEuKSzD_Fl4HqLNh-o=.c381306e-f528-4da0-b913-ef730648969e@github.com>
 <GEm6vSB1NxlJO9d9hmql8LEHGeoRPTzq_o_paTUmxdI=.588f70ee-4e99-43f9-a586-b94f2c6bb104@github.com>
 <T2CisOVBsFa0zK5HXXOkvh54HHQFRU1xJpAxhZ_Yfe4=.f7b0b3e0-e109-4e95-a513-9100ee08b598@github.com>
Message-ID: <5sg6x5ksWId6kCGjU2K_2DqiXwKp7oNeUlSIpN1uwvY=.65635c9f-705a-4571-9047-5748d57dfeb0@github.com>

On Wed, 22 May 2024 08:07:59 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Actually, this is a bit strange. I thought jcheck would look for missing newline at EOF, and that properties files were included in the check nowadays. I'll need to check this out.
>
> I did some testing and it turns out that this is indeed not checked. I believe this is a miss in the Skara reimplementation of jcheck. I've opened https://bugs.openjdk.org/browse/SKARA-2265 to track this.
> 
> Nevertheless, it would be good if you could fix this. :)

Sure.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14787#discussion_r1609856505

From prappo at openjdk.org  Wed May 22 12:45:21 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Wed, 22 May 2024 12:45:21 GMT
Subject: RFR: 8305457: Implement java.io.IO [v11]
In-Reply-To: <w2msiw_qaMEIJS3s9D4bg8pFbz5WIF0KdP6Mm-XFjLI=.85b2020b-8c46-4bac-8a69-4975b068f2ff@github.com>
References: <w2msiw_qaMEIJS3s9D4bg8pFbz5WIF0KdP6Mm-XFjLI=.85b2020b-8c46-4bac-8a69-4975b068f2ff@github.com>
Message-ID: <BWldQ320VyWK4nVUSCZIsNx7M_WSpw5LNNMYkBfV4WY=.58c8df02-9bd3-41e6-8ccb-4d0bd15026d7@github.com>

> Please review this PR which introduces the `java.io.IO` top-level class and three methods to `java.io.Console` for [Implicitly Declared Classes and Instance Main Methods (Third Preview)].
> 
> This PR has been obtained as `git merge --squash` of a now obsolete [draft PR].
> 
> [Implicitly Declared Classes and Instance Main Methods (Third Preview)]: https://bugs.openjdk.org/browse/JDK-8323335
> [draft PR]: https://github.com/openjdk/jdk/pull/18921

Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:

  Restructure the test

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19112/files
  - new: https://git.openjdk.org/jdk/pull/19112/files/809e98e0..719560f6

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19112&range=10
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19112&range=09-10

  Stats: 177 lines in 1 file changed: 87 ins; 84 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/19112.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19112/head:pull/19112

PR: https://git.openjdk.org/jdk/pull/19112

From davidalayachew at gmail.com  Wed May 22 12:53:46 2024
From: davidalayachew at gmail.com (David Alayachew)
Date: Wed, 22 May 2024 08:53:46 -0400
Subject: do I need to subscribe to this list in order to post?
In-Reply-To: <CH3PR12MB761911EA48C60FD146CAC4D0F9EA2@CH3PR12MB7619.namprd12.prod.outlook.com>
References: <CH3PR12MB761911EA48C60FD146CAC4D0F9EA2@CH3PR12MB7619.namprd12.prod.outlook.com>
Message-ID: <CAA9v-_N_VsdNw8MZLOpAmHxh4dor6GpWXNLCbYeEgNxsFtHePA@mail.gmail.com>

Nope. We can see your message. You only subscribe if you want to follow
along with the general discussions that you are not explicitly invited to.

On Tue, May 21, 2024 at 7:14?PM <mark.yagnatinsky at barclays.com> wrote:

>
>
> This message is for information purposes only. It is not a recommendation,
> advice, offer or solicitation to buy or sell a product or service, nor an
> official confirmation of any transaction. It is directed at persons who are
> professionals and is intended for the recipient(s) only. It is not directed
> at retail customers. This message is subject to the terms at:
> https://www.ib.barclays/disclosures/web-and-email-disclaimer.html.
>
> For important disclosures, please see:
> https://www.ib.barclays/disclosures/sales-and-trading-disclaimer.html
> regarding marketing commentary from Barclays Sales and/or Trading desks,
> who are active market participants;
> https://www.ib.barclays/disclosures/barclays-global-markets-disclosures.html
> regarding our standard terms for Barclays Investment Bank where we trade
> with you in principal-to-principal wholesale markets transactions; and in
> respect to Barclays Research, including disclosures relating to specific
> issuers, see: http://publicresearch.barclays.com.
> __________________________________________________________________________________
>
> If you are incorporated or operating in Australia, read these important
> disclosures:
> https://www.ib.barclays/disclosures/important-disclosures-asia-pacific.html
> .
>
> __________________________________________________________________________________
> For more details about how we use personal information, see our privacy
> notice: https://www.ib.barclays/disclosures/personal-information-use.html.
>
>
> __________________________________________________________________________________
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240522/e8b08974/attachment.htm>

From mark.yagnatinsky at barclays.com  Wed May 22 12:55:52 2024
From: mark.yagnatinsky at barclays.com (mark.yagnatinsky at barclays.com)
Date: Wed, 22 May 2024 12:55:52 +0000
Subject: do I need to subscribe to this list in order to post?
In-Reply-To: <CAA9v-_N_VsdNw8MZLOpAmHxh4dor6GpWXNLCbYeEgNxsFtHePA@mail.gmail.com>
References: <CH3PR12MB761911EA48C60FD146CAC4D0F9EA2@CH3PR12MB7619.namprd12.prod.outlook.com>
 <CAA9v-_N_VsdNw8MZLOpAmHxh4dor6GpWXNLCbYeEgNxsFtHePA@mail.gmail.com>
Message-ID: <CH3PR12MB761939642482E3A6C3101B6AF9EB2@CH3PR12MB7619.namprd12.prod.outlook.com>

Thanks!!

From: David Alayachew <davidalayachew at gmail.com>
Sent: Wednesday, May 22, 2024 8:54 AM
To: Yagnatinsky, Mark : IT (NYK) <mark.yagnatinsky at barclays.com>
Cc: core-libs-dev at openjdk.org
Subject: Re: do I need to subscribe to this list in order to post?


CAUTION: This email originated from outside our organisation - davidalayachew at gmail.com<mailto:davidalayachew at gmail.com> Do not click on links, open attachments, or respond unless you recognize the sender and can validate the content is safe.
Nope. We can see your message. You only subscribe if you want to follow along with the general discussions that you are not explicitly invited to.

On Tue, May 21, 2024 at 7:14?PM <mark.yagnatinsky at barclays.com<mailto:mark.yagnatinsky at barclays.com>> wrote:


This message is for information purposes only. It is not a recommendation, advice, offer or solicitation to buy or sell a product or service, nor an official confirmation of any transaction. It is directed at persons who are professionals and is intended for the recipient(s) only. It is not directed at retail customers. This message is subject to the terms at: https://www.ib.barclays/disclosures/web-and-email-disclaimer.html<https://clicktime.symantec.com/15sMLdc53iyHjpvvBK2RU?h=I-qsCGEq1I0a6o18kFcGtMtYnRhIf-AMdA-E4B7Jxic=&u=https://www.ib.barclays/disclosures/web-and-email-disclaimer.html>.

For important disclosures, please see: https://www.ib.barclays/disclosures/sales-and-trading-disclaimer.html<https://clicktime.symantec.com/15sMFoQnb7HhKt6zdkdGr?h=0wRFwjfRrA1kunHR6rv84i46CC6PKXh0zrfceOxxd0M=&u=https://www.ib.barclays/disclosures/sales-and-trading-disclaimer.html> regarding marketing commentary from Barclays Sales and/or Trading desks, who are active market participants; https://www.ib.barclays/disclosures/barclays-global-markets-disclosures.html<https://clicktime.symantec.com/15sM1JpwDGEv63dE15Rpz?h=qX1Msn1Rwjm6bHAi5y-q-a42dnb_emjlaifj7E_nOM4=&u=https://www.ib.barclays/disclosures/barclays-global-markets-disclosures.html> regarding our standard terms for Barclays Investment Bank where we trade with you in principal-to-principal wholesale markets transactions; and in respect to Barclays Research, including disclosures relating to specific issuers, see: http://publicresearch.barclays.com<https://clicktime.symantec.com/15sLvUdekeZKg6oJTX2gN?h=e2KrNIP_LsCfi2AEk4QA5FMcXJjDk3njfMrJOnyPops=&u=http://publicresearch.barclays.com>.
__________________________________________________________________________________
If you are incorporated or operating in Australia, read these important disclosures: https://www.ib.barclays/disclosures/important-disclosures-asia-pacific.html<https://clicktime.symantec.com/15sM692DfsvWVzT9Ydpyc?h=9d9GR4CZ5G3DH0iyzro1yWFzatTyg10qR3RcgP2v-YU=&u=https://www.ib.barclays/disclosures/important-disclosures-asia-pacific.html>.
__________________________________________________________________________________
For more details about how we use personal information, see our privacy notice: https://www.ib.barclays/disclosures/personal-information-use.html<https://clicktime.symantec.com/15sMAyDW8Vc6uwH56CE8E?h=2yTXAM1bwiklsaqqIGWlKdPFVN86imsAo_QQ_gEHays=&u=https://www.ib.barclays/disclosures/personal-information-use.html>.
__________________________________________________________________________________

This message is for information purposes only. It is not a recommendation, advice, offer or solicitation to buy or sell a product or service, nor an official confirmation of any transaction. It is directed at persons who are professionals and is intended for the recipient(s) only. It is not directed at retail customers. This message is subject to the terms at: https://www.ib.barclays/disclosures/web-and-email-disclaimer.html. 

For important disclosures, please see: https://www.ib.barclays/disclosures/sales-and-trading-disclaimer.html regarding marketing commentary from Barclays Sales and/or Trading desks, who are active market participants; https://www.ib.barclays/disclosures/barclays-global-markets-disclosures.html regarding our standard terms for Barclays Investment Bank where we trade with you in principal-to-principal wholesale markets transactions; and in respect to Barclays Research, including disclosures relating to specific issuers, see: http://publicresearch.barclays.com.
__________________________________________________________________________________ 
If you are incorporated or operating in Australia, read these important disclosures: https://www.ib.barclays/disclosures/important-disclosures-asia-pacific.html.
__________________________________________________________________________________
For more details about how we use personal information, see our privacy notice: https://www.ib.barclays/disclosures/personal-information-use.html. 
__________________________________________________________________________________
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240522/4f0966cd/attachment-0001.htm>

From sgehwolf at openjdk.org  Wed May 22 13:23:25 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Wed, 22 May 2024 13:23:25 GMT
Subject: RFR: 8311302: Allow for jlinking a custom runtime without packaged
 modules being present [v29]
In-Reply-To: <Z0DJ87uKPbjS6mvJIE_oG5m-RWsbERXsytSgV8Bmhdo=.f8723513-0ac6-4e85-9131-3c3924860c61@github.com>
References: <Z0DJ87uKPbjS6mvJIE_oG5m-RWsbERXsytSgV8Bmhdo=.f8723513-0ac6-4e85-9131-3c3924860c61@github.com>
Message-ID: <gvC8mkf0o7JGc-K6xJhW5bCYmza1AizAawFML2-HLrs=.fce19d5b-457d-4fdd-8e19-1336de44cbe1@github.com>

> Please review this patch which adds a jlink mode to the JDK which doesn't need the packaged modules being present. A.k.a run-time image based jlink. Fundamentally this patch adds an option to use `jlink` even though your JDK install might not come with the packaged modules (directory `jmods`). This is particularly useful to further reduce the size of a jlinked runtime. After the removal of the concept of a JRE, a common distribution mechanism is still the full JDK with all modules and packaged modules. However, packaged modules can incur an additional size tax. For example in a container scenario it could be useful to have a base JDK container including all modules, but without also delivering the packaged modules. This comes at a size advantage of `~25%`. Such a base JDK container could then be used to `jlink` application specific runtimes, further reducing the size of the application runtime image (App + JDK runtime; as a single image *or* separate bundles, depending on the app b
 eing modularized).
> 
> The basic design of this approach is to add a jlink plugin for tracking non-class and non-resource files of a JDK install. I.e. files which aren't present in the jimage (`lib/modules`). This enables producing a `JRTArchive` class which has all the info of what constitutes the final jlinked runtime.
> 
> Basic usage example:
> 
> $ diff -u <(./bin/java --list-modules --limit-modules java.se) <(../linux-x86_64-server-release/images/jdk/bin/java --list-modules --limit-modules java.se)
> $ diff -u <(./bin/java --list-modules --limit-modules jdk.jlink) <(../linux-x86_64-server-release/images/jdk/bin/java --list-modules --limit-modules jdk.jlink)
> $ ls ../linux-x86_64-server-release/images/jdk/jmods
> java.base.jmod            java.net.http.jmod       java.sql.rowset.jmod      jdk.crypto.ec.jmod         jdk.internal.opt.jmod                     jdk.jdi.jmod         jdk.management.agent.jmod  jdk.security.auth.jmod
> java.compiler.jmod        java.prefs.jmod          java.transaction.xa.jmod  jdk.dynalink.jmod          jdk.internal.vm.ci.jmod                   jdk.jdwp.agent.jmod  jdk.management.jfr.jmod    jdk.security.jgss.jmod
> java.datatransfer.jmod    java.rmi.jmod            java.xml.crypto.jmod      jdk.editpad.jmod           jdk.internal.vm.compiler.jmod             jdk.jfr.jmod         jdk.management.jmod        jdk.unsupported.desktop.jmod
> java.desktop.jmod         java.scripting.jmod      java.xml.jmod             jdk.hotspot.agent.jmod     jdk.internal.vm.compiler.manage...

Severin Gehwolf has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 110 commits:

 - Merge branch 'master' into jdk-8311302-jmodless-link
 - Fix new line in jlink.properties
 - Merge branch 'master' into jdk-8311302-jmodless-link
 - Simplify JLINK_JDK_EXTRA_OPTS var handling
 - Only add runtime track files for linkable runtimes
 - Generate the runtime image link diff at jlink time
   
   But only do that once the plugin-pipeline has run. The generation is
   enabled with the hidden option '--generate-linkable-runtime' and
   the resource pools available at jlink time are being used to generate
   the diff.
 - Merge branch 'master' into jdk-8311302-jmodless-link
 - Use shorter name for the build tool
 - Review feedback from Erik J.
 - Remove dependency on CDS which isn't needed anymore
 - ... and 100 more: https://git.openjdk.org/jdk/compare/4f1a10f8...e1e3f02f

-------------

Changes: https://git.openjdk.org/jdk/pull/14787/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14787&range=28
  Stats: 3424 lines in 36 files changed: 3272 ins; 110 del; 42 mod
  Patch: https://git.openjdk.org/jdk/pull/14787.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14787/head:pull/14787

PR: https://git.openjdk.org/jdk/pull/14787

From sgehwolf at openjdk.org  Wed May 22 13:23:25 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Wed, 22 May 2024 13:23:25 GMT
Subject: RFR: 8311302: Allow for jlinking a custom runtime without packaged
 modules being present [v25]
In-Reply-To: <5sg6x5ksWId6kCGjU2K_2DqiXwKp7oNeUlSIpN1uwvY=.65635c9f-705a-4571-9047-5748d57dfeb0@github.com>
References: <Z0DJ87uKPbjS6mvJIE_oG5m-RWsbERXsytSgV8Bmhdo=.f8723513-0ac6-4e85-9131-3c3924860c61@github.com>
 <2Hs5V_cOOhOtXxrKvM0ATWxJFO62xd3RtScyPEb5puI=.f16650ac-9812-40ed-a93c-a5dd4b396ad2@github.com>
 <EjF8YVHfHr9qm_5w3BLUSFhP-cQ_BR6Fcs_8-oKzpZo=.3cdf9de7-b75c-4848-93ed-173ac6060a3f@github.com>
 <BXZ-wDhkakio3dYE5xnHxEuIdyEuKSzD_Fl4HqLNh-o=.c381306e-f528-4da0-b913-ef730648969e@github.com>
 <GEm6vSB1NxlJO9d9hmql8LEHGeoRPTzq_o_paTUmxdI=.588f70ee-4e99-43f9-a586-b94f2c6bb104@github.com>
 <T2CisOVBsFa0zK5HXXOkvh54HHQFRU1xJpAxhZ_Yfe4=.f7b0b3e0-e109-4e95-a513-9100ee08b598@github.com>
 <5sg6x5ksWId6kCGjU2K_2DqiXwKp7oNeUlSIpN1uwvY=.65635c9f-705a-4571-9047-5748d57dfeb0@github.com>
Message-ID: <X_cpdHzJQTvW-Qnh_O8La7gRwHJcGR-D6ZARvdxj9rY=.e8f902e3-0744-48e9-965c-75622f93cc84@github.com>

On Wed, 22 May 2024 12:25:09 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> I did some testing and it turns out that this is indeed not checked. I believe this is a miss in the Skara reimplementation of jcheck. I've opened https://bugs.openjdk.org/browse/SKARA-2265 to track this.
>> 
>> Nevertheless, it would be good if you could fix this. :)
>
> Sure.

Should be fixed now.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14787#discussion_r1609943363

From liach at openjdk.org  Wed May 22 13:32:16 2024
From: liach at openjdk.org (Chen Liang)
Date: Wed, 22 May 2024 13:32:16 GMT
Subject: RFR: 8332614: Type-checked ConstantPool.entryByIndex and
 ClassReader.readEntryOrNull [v2]
In-Reply-To: <UP8XpBov1w74UcUrAkD08x3vQGy_zRQ8NFRXuMU8us4=.3cce8ca0-742b-43f2-a282-894c7f61c969@github.com>
References: <UP8XpBov1w74UcUrAkD08x3vQGy_zRQ8NFRXuMU8us4=.3cce8ca0-742b-43f2-a282-894c7f61c969@github.com>
Message-ID: <OZSivIQZi308nv2L3vfF3ZAUQbyP2RQYpp1vJWesx3c=.758c2b68-e51c-4019-83b0-504391cb6593@github.com>

> I propose to add type-checked ConstantPool.entryByIndex and ClassReader.readEntryOrNull taking an extra Class parameter, which throws ConstantPoolException instead of ClassCastException on type mismatch, which can happen to malformed ClassFiles.
> 
> Requesting a review from @asotona. Thanks!
> 
> Proposal on mailing list: https://mail.openjdk.org/pipermail/classfile-api-dev/2024-May/000512.html

Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:

 - Merge branch 'master' of https://github.com/openjdk/jdk into feature/entry-by-type
 - Use constants, beautify code
 - 8332614: Type-checked ConstantPool.entryByIndex and ClassReader.readEntryOrNull

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19330/files
  - new: https://git.openjdk.org/jdk/pull/19330/files/5a45e511..c9f6fc18

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19330&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19330&range=00-01

  Stats: 1517 lines in 58 files changed: 777 ins; 404 del; 336 mod
  Patch: https://git.openjdk.org/jdk/pull/19330.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19330/head:pull/19330

PR: https://git.openjdk.org/jdk/pull/19330

From nbenalla at openjdk.org  Wed May 22 13:58:21 2024
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Wed, 22 May 2024 13:58:21 GMT
Subject: RFR: 8331051: Add an `@since` checker test for `java.base` module
 [v7]
In-Reply-To: <NRZmbFYvDwXPuizcmCilJx5Yb6HjZ-2fJa-YILxYUl8=.a79f79e4-77d5-4910-b3df-5e78bb7e402b@github.com>
References: <NRZmbFYvDwXPuizcmCilJx5Yb6HjZ-2fJa-YILxYUl8=.a79f79e4-77d5-4910-b3df-5e78bb7e402b@github.com>
Message-ID: <fO1l01qTJQy4l47E5P23YC2kSsPVkZdSpr6fe9GFnxQ=.b4c38763-86aa-410f-8f6e-769e65bf5b53@github.com>

> This checker checks the values of the `@since` tag found in the documentation comment for an element against the release in which the element first appeared.
> 
> Real since value of an API element is computed as the oldest release in which the given API element was introduced. That is:
> - for modules, classes and interfaces, the release in which the element with the given qualified name was introduced
> - for constructors, the release in which the constructor with the given VM descriptor was introduced
> - for methods and fields, the release in which the given method or field with the given VM descriptor became a member of its enclosing class or interface, whether direct or inherited
> 
> Effective since value of an API element is computed as follows:
> - if the given element has a `@since` tag in its javadoc, it is used
> - in all other cases, return the effective since value of the enclosing element
> 
> The since checker verifies that for every API element, the real since value and the effective since value are the same, and reports an error if they are not.
> 
> Preview method are handled as per JEP 12, if `@PreviewFeature` is used consistently going forward then the checker doesn't need to be updated with every release. The checker has explicit knowledge of preview elements that came before `JDK 14` because they weren't marked in a machine understandable way and preview elements that came before `JDK 17` that didn't have `@PreviewFeature`.
> 
> Important note : We only check code written since `JDK 9` as the releases used to determine the expected value of `@since` tags are taken from the historical data built into `javac` which only goes back that far
> 
> The intial comment at the beginning of `SinceChecker.java` holds more information into the program.
> 
> I already have filed issues and fixed some wrong tags like in #18640, #18032, #18030, #18055, #18373, #18954, #18972.

Nizar Benalla has updated the pull request incrementally with one additional commit since the last revision:

  Add a few more legacy methods, needed a few more after changes to the checker

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/18934/files
  - new: https://git.openjdk.org/jdk/pull/18934/files/e82dfbf0..fc10107a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18934&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18934&range=05-06

  Stats: 16 lines in 1 file changed: 10 ins; 4 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/18934.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18934/head:pull/18934

PR: https://git.openjdk.org/jdk/pull/18934

From thartmann at openjdk.org  Wed May 22 14:10:14 2024
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Wed, 22 May 2024 14:10:14 GMT
Subject: RFR: 8329538: Accelerate P256 on x86_64 using Montgomery intrinsic
 [v12]
In-Reply-To: <kuMyLYSd4dOC7qBbk9G7ZtvntC1U3FR5V35jLP1qHtQ=.e1459498-2ab5-48b1-8490-25dc94d49b1d@github.com>
References: <hanRK4GzOkFV8kG1gZRy8Br53trw4-Tu6G6uO8nsFuk=.d5bf723a-f683-4759-ac9e-4a58cb430f03@github.com>
 <kuMyLYSd4dOC7qBbk9G7ZtvntC1U3FR5V35jLP1qHtQ=.e1459498-2ab5-48b1-8490-25dc94d49b1d@github.com>
Message-ID: <V0i7vCg7NdYkgIssqjkt9cI4wZKtpHdHJShYQHDtYMA=.ec8ea2b0-f32b-4397-9702-6c96892abb74@github.com>

On Tue, 21 May 2024 17:41:46 GMT, Volodymyr Paprotski <duke at openjdk.org> wrote:

>> Performance. Before:
>> 
>> Benchmark                        (algorithm)  (dataSize)  (keyLength)  (provider)   Mode  Cnt     Score    Error  Units
>> SignatureBench.ECDSA.sign    SHA256withECDSA        1024          256              thrpt    3  6443.934 ?  6.491  ops/s
>> SignatureBench.ECDSA.sign    SHA256withECDSA       16384          256              thrpt    3  6152.979 ?  4.954  ops/s
>> SignatureBench.ECDSA.verify  SHA256withECDSA        1024          256              thrpt    3  1895.410 ? 36.979  ops/s
>> SignatureBench.ECDSA.verify  SHA256withECDSA       16384          256              thrpt    3  1878.955 ? 45.487  ops/s
>> Benchmark                                            (algorithm)  (keyLength)  (kpgAlgorithm)  (provider)   Mode  Cnt     Score    Error  Units
>> o.o.b.j.c.full.KeyAgreementBench.EC.generateSecret          ECDH          256              EC              thrpt    3  1357.810 ? 26.584  ops/s
>> o.o.b.j.c.small.KeyAgreementBench.EC.generateSecret         ECDH          256              EC              thrpt    3  1352.119 ? 23.547  ops/s
>> Benchmark                          (isMontBench)   Mode  Cnt     Score    Error  Units
>> PolynomialP256Bench.benchMultiply          false  thrpt    3  1746.126 ? 10.970  ops/s
>> 
>> Performance, no intrinsic:
>> 
>> Benchmark                        (algorithm)  (dataSize)  (keyLength)  (provider)   Mode  Cnt     Score     Error  Units
>> SignatureBench.ECDSA.sign    SHA256withECDSA        1024          256              thrpt    3  6529.839 ?  42.420  ops/s
>> SignatureBench.ECDSA.sign    SHA256withECDSA       16384          256              thrpt    3  6199.747 ? 133.566  ops/s
>> SignatureBench.ECDSA.verify  SHA256withECDSA        1024          256              thrpt    3  1973.676 ?  54.071  ops/s
>> SignatureBench.ECDSA.verify  SHA256withECDSA       16384          256              thrpt    3  1932.127 ?  35.920  ops/s
>> Benchmark                                            (algorithm)  (keyLength)  (kpgAlgorithm)  (provider)   Mode  Cnt     Score    Error  Units
>> o.o.b.j.c.full.KeyAgreementBench.EC.generateSecret          ECDH          256              EC              thrpt    3  1355.788 ? 29.858  ops/s
>> o.o.b.j.c.small.KeyAgreementBench.EC.generateSecret         ECDH          256              EC              thrpt    3  1346.523 ? 28.722  ops/s
>> Benchmark                          (isMontBench)   Mode  Cnt     Score    Error  Units
>> PolynomialP256Bench.benchMultiply           true  thrpt    3  1919.57...
>
> Volodymyr Paprotski has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 17 additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'origin/master' into ecc-montgomery
>  - shenandoah verifier
>  - comments from Sandhya
>  - whitespace
>  - add message back
>  - whitespace
>  - Use AffinePoint to exit Montgomery domain
>    
>    Style notes:
>    Affine.equals()
>        - Mismatched fields only appear to be used from testing, perhaps should be moved there instead
>    Affine.getX(boolean)|getY(boolean)
>        - "Passing flag is bad design" - cleanest/performant alternative to several instanceof checks
>        - needed to convert Affine to Projective (need to stay in montgomery domain)
>    ECOperations.PointMultiplier
>       - changes could probably be restored to original (since ProjectivePoint handling no longer required)
>       - consider these changes an improvement? (fewer nested classes)
>       - was an inner-class but not using inner-class features (i.e. ecOps variable should be converted)
>  - whitespace
>  - Comments from Tony and Jatin
>  - Comments from Jatin and Tony
>  - ... and 7 more: https://git.openjdk.org/jdk/compare/45457761...b1a33004

All tests passed.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18583#issuecomment-2124892444

From amansha at kth.se  Wed May 22 14:12:19 2024
From: amansha at kth.se (Aman Sharma)
Date: Wed, 22 May 2024 14:12:19 +0000
Subject: Deterministic naming of subclasses of `java/lang/reflect/Proxy`
In-Reply-To: <CABe8uE065Q3+0yNjtyDF-eJM4LN-MbY9kfC44CnSQ-KM4p862g@mail.gmail.com>
References: <bf26eb2f74874e02876b3868311922a9@kth.se>
 <CABe8uE0fk71Xy_PYHikSw9OtXE_i+M9zMbayPEXuTxLWLoy2ag@mail.gmail.com>
 <50405ca9c0a64372bace175b932f9ef7@kth.se>
 <61fbe3d9-9536-4113-adde-6cfc671ba1ee@oracle.com>
 <a860be44e06243799593aa8d67c048cd@kth.se>
 <CABe8uE115=DzYCdnvNazqFuuxtJoZnv9wRUkFA4-PS7g41QLMw@mail.gmail.com>
 <DB7PR02MB35938DCC3A392536B924164AFBEE2@DB7PR02MB3593.eurprd02.prod.outlook.com>
 <a0330ee0-5f45-4ef2-8500-e5fcdb696c52@oracle.com>
 <b214cc1a13fe4885a437e16b420e5483@kth.se>
 <ac2ebe5c-db49-4a2d-a5cd-10440a77aa16@oracle.com>
 <580b3aacd8df48fcaae3399718e229ab@kth.se>,
 <CABe8uE065Q3+0yNjtyDF-eJM4LN-MbY9kfC44CnSQ-KM4p862g@mail.gmail.com>
Message-ID: <b64077d6cf0045e98b630cf888785182@kth.se>

Hi Chen,


That's clear. Thanks for letting me know. I guess then Project Leyden is working on naming the hidden classes deterministically to achieve their goals<https://openjdk.org/projects/leyden/notes/01-beginnings>.


Regards,
Aman Sharma

PhD Student
KTH Royal Institute of Technology
School of Electrical Engineering and Computer Science (EECS)
Department of Theoretical Computer Science (TCS)
<http://www.kth.se><https://www.kth.se/profile/amansha><https://www.kth.se/profile/amansha>
<https://www.kth.se/profile/amansha>https://algomaster99.github.io/
________________________________
From: Chen Liang <liangchenblue at gmail.com>
Sent: Wednesday, May 22, 2024 1:35:46 PM
To: Aman Sharma
Cc: David Holmes; core-libs-dev at openjdk.org; leyden-dev at openjdk.org
Subject: Re: Deterministic naming of subclasses of `java/lang/reflect/Proxy`

Hi Aman,
We have tried defining Proxy as hidden classes; a previous attempt was on hold because of issues with serialization. Otherwise, Proxies work great as hidden classes.

Chen

On Mon, May 20, 2024 at 7:56?AM Aman Sharma <amansha at kth.se<mailto:amansha at kth.se>> wrote:

Hi David,


> I would not expect any class load
events.


I understand. I also haven't tried to intercept them but I see only one approach right now to include them in an allowlist - 1) statically look for invocations of "Lookup::defineHiddenClass". 2) Instrument them so that its first argument "bytes" can be looked into upon. I haven't looked into it much because I did not have much idea about it. And they are hidden so it made it worse. ? Thanks for sharing the JEP!


>

java.lang.reflect.Proxy could define hidden classes to act as the proxy classes which implement proxy interfaces; from JEP 317


It says that Proxy classes will also become hidden classes. Is it underway? Right now one can intercept, transform them, and include them in an allowlist. What do you think of naming them independent of AtomicLong so that a proxy class generated at runtime is easy to lookup in the allowlist?



Regards,
Aman Sharma

PhD Student
KTH Royal Institute of Technology
School of Electrical Engineering and Computer Science (EECS)
Department of Theoretical Computer Science (TCS)
<http://www.kth.se><https://www.kth.se/profile/amansha><https://www.kth.se/profile/amansha>
<https://www.kth.se/profile/amansha>https://algomaster99.github.io/
________________________________
From: David Holmes <david.holmes at oracle.com<mailto:david.holmes at oracle.com>>
Sent: Monday, May 20, 2024 2:30:37 PM
To: Aman Sharma; liangchenblue at gmail.com<mailto:liangchenblue at gmail.com>
Cc: core-libs-dev at openjdk.org<mailto:core-libs-dev at openjdk.org>; leyden-dev at openjdk.org<mailto:leyden-dev at openjdk.org>
Subject: Re: Deterministic naming of subclasses of `java/lang/reflect/Proxy`

On 20/05/2024 10:12 pm, Aman Sharma wrote:
> Hi David,
>
>
>  > How did you try to intercept them? Hidden classes are not "loaded" in
> the normal sense so won't trigger class load events.
>
>
> I could not intercept them. I only see them when I pass `-verbose:class`
> in the Java CLI.

Yes that is why I asked how you tried to intercept them.

>
> I also couldn't intercept them using JVMTI Class File Load Hook
> <https://docs.oracle.com/en/java/javase/21/docs/specs/jvmti.html#ClassFileLoadHook> event. However JEP 371 suggests that it should be possible to intercept them using JVMTI Class Load <https://docs.oracle.com/en/java/javase/21/docs/specs/jvmti.html#ClassLoad> event, but I won't have the bytecode at this stage. So is there no way to get its bytecode before it is linked and initialized in the JVM?

Hidden classes are not loaded so I would not expect any class load
events. However the exact nature of the JVMTI class load event is
unclear as it talks about "class or interface creation" which is neither
loading or defining per se. But a class prepare event sounds like it
should be issued. However neither give you access to the bytecode of the
class AFAICS.

David
-----


>
> Regards,
> Aman Sharma
>
> PhD Student
> KTH Royal Institute of Technology
> School of Electrical Engineering and Computer Science (EECS)
> Department of Theoretical Computer Science (TCS)
> <http://www.kth.se><https://www.kth.se/profile/amansha><https://www.kth.se/profile/amansha>
> <https://www.kth.se/profile/amansha>https://algomaster99.github.io/
> <https://algomaster99.github.io/>
> ------------------------------------------------------------------------
> *From:* David Holmes <david.holmes at oracle.com<mailto:david.holmes at oracle.com>>
> *Sent:* Monday, May 20, 2024 2:59:17 AM
> *To:* Aman Sharma; liangchenblue at gmail.com<mailto:liangchenblue at gmail.com>
> *Cc:* core-libs-dev at openjdk.org<mailto:core-libs-dev at openjdk.org>; leyden-dev at openjdk.org<mailto:leyden-dev at openjdk.org>
> *Subject:* Re: Deterministic naming of subclasses of
> `java/lang/reflect/Proxy`
> On 17/05/2024 9:43 pm, Aman Sharma wrote:
>> Hi Chen,
>>
>>  > java.lang.invoke.LambdaForm$MH/0x00000200cc000400
>>
>> I do see this as output when I pass -verbose:class. However, based on my
>> experiments, I have seen that neither an agent passed via 'javaagent'
>> nor an agent passed via 'agentpath' is able to intercept this hidden class.
>
> How did you try to intercept them? Hidden classes are not "loaded" in
> the normal sense so won't trigger class load events.
>
>> Also, I was a bit confused since I saw somewhere that the names of
>> hidden classes are null. But thanks for clarifying here.
>
> The JEP clearly defines the name format for hidden classes - though the
> final component is VM specific (and typically a hashcode).
>
> https://openjdk.org/jeps/371 <https://openjdk.org/jeps/371>
>
> Cheers,
> David
> -----
>
>>  > avoid dynamic class loading
>>
>> I don't see dynamic class loading as a problem. I only mind some
>> unstable generation aspects of them which make it hard to verify them
>> based on an allowlist.
>>
>> For example, if this hidden class is generated with the exact same name
>> and the exact same bytecode during runtime as well, it would be easy to
>> verify it. However, I do see the names are based on some sort of memory
>> address so and I don't know what bytecode it has so I don't have
>> suggestions to make them stable as of now. For Proxy classes, I feel it
>> can be addressed unless you disagree or some involved in Project Leyden
>> does. :) Thank you for forwarding my mail there.
>>
>> Regards,
>> Aman Sharma
>>
>> PhD Student
>> KTH Royal Institute of Technology
>> https://algomaster99.github.io/ <https://algomaster99.github.io/>
> <https://algomaster99.github.io/ <https://algomaster99.github.io/>>
>>
>> ------------------------------------------------------------------------
>> *From:* liangchenblue at gmail.com<mailto:liangchenblue at gmail.com> <liangchenblue at gmail.com<mailto:liangchenblue at gmail.com>>
>> *Sent:* Friday, May 17, 2024 1:23:58 pm
>> *To:* Aman Sharma <amansha at kth.se<mailto:amansha at kth.se>>
>> *Cc:* core-libs-dev at openjdk.org<mailto:core-libs-dev at openjdk.org> <core-libs-dev at openjdk.org<mailto:core-libs-dev at openjdk.org>>;
>> leyden-dev at openjdk.org<mailto:leyden-dev at openjdk.org> <leyden-dev at openjdk.org<mailto:leyden-dev at openjdk.org>>
>> *Subject:* Re: Deterministic naming of subclasses of
>> `java/lang/reflect/Proxy`
>>
>> Hi Aman,
>> For `-verbose:class`, it's a JVM argument instead of a program argument;
>> so when you run a java program like `java Main`, you should call it as
>> `java -verbose:class Main`.
>> When done correctly, you should see hidden class outputs like:
>> [0.032s][info][class,load]
>> java.lang.invoke.LambdaForm$MH/0x00000200cc000400 source:
>> __JVM_LookupDefineClass__
>> The loading of java.lang.invoke hidden classes requires your program to
>> use MethodHandle features, like a lambda.
>>
>> I think the problem you are exploring, that to avoid dynamic class
>> loading and effectively turn Java Platform closed for security, is also
>> being accomplished by project Leyden (as I've shared initially); Thus, I
>> am forwarding this to leyden-dev instead, so you can see what approach
>> Leyden uses to accomplish the same goal as yours.
>>
>> Regards, Chen Liang
>>
>> On Fri, May 17, 2024 at 4:40?AM Aman Sharma <amansha at kth.se<mailto:amansha at kth.se>
>> <mailto:amansha at kth.se<mailto:amansha at kth.se> <mailto:amansha at kth.se>>> wrote:
>>
>>     __
>>
>>     Hi Roger,
>>
>>
>>     Do you have ideas on how to intercept them? My javaagent is not able
>>     to nor a JVMTI agent passed using `agentpath` option. It also does
>>     not seem to show up in logs when I pass `-verbose:class`.
>>
>>
>>     Also, what do you think of renaming the proxy classes as suggested
>>     below?
>>
>>
>>     Regards,
>>     Aman Sharma
>>
>>     PhD Student
>>     KTH Royal Institute of Technology
>>     School of Electrical Engineering and Computer Science (EECS)
>>     Department of Theoretical Computer Science (TCS)
>>     <http://www.kth.se><https://www.kth.se/profile/amansha><https://www.kth.se/profile/amansha <http://www.kth.se><https://www.kth.se/profile/amansha><https://www.kth.se/profile/amansha>>
>>     <https://www.kth.se/profile/amansha
> <https://www.kth.se/profile/amansha>>https://algomaster99.github.io/
>>     <https://algomaster99.github.io/ <https://algomaster99.github.io/>>
>>     ------------------------------------------------------------------------
>>     *From:* core-libs-dev <core-libs-dev-retn at openjdk.org<mailto:core-libs-dev-retn at openjdk.org>
>>     <mailto:core-libs-dev-retn at openjdk.org<mailto:core-libs-dev-retn at openjdk.org>
> <mailto:core-libs-dev-retn at openjdk.org>>> on behalf of Roger Riggs
>>     <roger.riggs at oracle.com<mailto:roger.riggs at oracle.com> <mailto:roger.riggs at oracle.com<mailto:roger.riggs at oracle.com> <mailto:roger.riggs at oracle.com>>>
>>     *Sent:* Friday, May 17, 2024 4:57:46 AM
>>     *To:* core-libs-dev at openjdk.org<mailto:core-libs-dev at openjdk.org> <mailto:core-libs-dev at openjdk.org<mailto:core-libs-dev at openjdk.org> <mailto:core-libs-dev at openjdk.org>>
>>     *Subject:* Re: Deterministic naming of subclasses of
>>     `java/lang/reflect/Proxy`
>>     Hi Aman,
>>
>>     You may also run into hidden classes (JEP 371: Hidden Classes) that
>>     allow classes to be defined, at runtime, without names.
>>     It has been proposed to use them for generated proxies but that
>>     hasn't been implemented yet.
>>     There are benefits to having nameless classes, because they can't be
>>     referenced by name, only as a capability, they can be better
>>     encapsulated.
>>
>>     fyi, Roger Riggs
>>
>>
>>     On 5/16/24 8:11 AM, Aman Sharma wrote:
>>>
>>>     Hi,
>>>
>>>
>>>     Thanks for your response, Liang!
>>>
>>>
>>>     > I think you meant CVE-2021-42392 instead of 2022.
>>>
>>>
>>>     Sorry of the error. I indeed meant CVE-2021-42392
>>>     <https://nvd.nist.gov/vuln/detail/cve-2021-42392
> <https://nvd.nist.gov/vuln/detail/cve-2021-42392>>.
>>>
>>>
>>>     > Leyden mainly avoids this unstable generation by performing a
>>>     training run to collect classes loaded
>>>
>>>
>>>     Would love to know the details of Project Leyden and how they
>>>     worked so far to focus on this goal. In our case, the training run
>>>     is the test suite.
>>>
>>>
>>>     > GeneratedConstructorAccessor is already retired by JEP 416 [2]
>>>     in Java 18
>>>
>>>
>>>     I did see them not appearing in my allowlist when I ran my study
>>>     subject (Apache PDFBox) with Java 21. Thanks for letting me know
>>>     about this JEP. I see they are re-implemented with method handles.
>>>
>>>
>>>     > How are you checking the classes?
>>>
>>>
>>>     To detect runtime generated code, we have javaagent that is hooked
>>>     statically to the test suite execution. It gives us all classes
>>>     that that is loaded post the JVM and the javaagent are loaded. So
>>>     we only check the classes loaded for the purpose of running the
>>>     application. This is also why we did not choose -agentlib as it
>>>     would give classes for the setting up JVM and javaagent and we the
>>>     user of our tool must the classes they load.
>>>
>>>
>>>     Next, we have a `ClassFileTransformer` hook in the agent where we
>>>     produce the checksum using the bytecode. And we compare the
>>>     checksum with the one existing in the allowlist. The checksum
>>>     computation algorithm is same for both steps. Let me describe how
>>>     I compute the checksum.
>>>
>>>
>>>      1. I get the CONSTANT_Class_info
>>>         <https://docs.oracle.com/javase/specs/jvms/se11/html/jvms-4.html#jvms-4.4.1 <https://docs.oracle.com/javase/specs/jvms/se11/html/jvms-4.html#jvms-4.4.1>> entry corresponding to `this_class` and rewrite the CONSTANT_Utf8_info <https://docs.oracle.com/javase/specs/jvms/se11/html/jvms-4.html#jvms-4.4.7 <https://docs.oracle.com/javase/specs/jvms/se11/html/jvms-4.html#jvms-4.4.7>> corresponding to a fix String constant, say "foo".
>>>      2. Since, the name of the class is used to refer to its types
>>>         members (fields/method), I get all CONSTANT_Fieldref_info
>>>         <https://docs.oracle.com/javase/specs/jvms/se11/html/jvms-4.html#jvms-4.4.2 <https://docs.oracle.com/javase/specs/jvms/se11/html/jvms-4.html#jvms-4.4.2>> and if its `class_index` corresponds to the old `this_class`, we rewrite the UTF8 value of class_index to the same constant "foo".
>>>      3. Next, since the naming of the fields, in Proxy classes, are
>>>         also suffixed by numbers, for example, `private static Method
>>>         m4`, we rewrite the UTF8 value of name in the
>>>         CONSTANT_NameAndType_info
>>>         <https://docs.oracle.com/javase/specs/jvms/se11/html/jvms-4.html#jvms-4.4.6 <https://docs.oracle.com/javase/specs/jvms/se11/html/jvms-4.html#jvms-4.4.6>>.
>>>      4. These fields can also have a random order so we simply sort
>>>         the entire byte code using `Arrays.sort(byte[])` to eliminate
>>>         any differences due to ordering of fields/methods.
>>>      5. Simply sorting the byte array still had minute differences. I
>>>         could not understand why they existed even though values in
>>>         constant pool of the bytecode in allowlist and at runtime were
>>>         exactly the same after rewriting. The differences existed in
>>>         the bytes of the Code attribute of methods. I concluded that
>>>         the bytes stored some position information. To avoid this, I
>>>         created a subarray where I considered the bytes corresponding
>>>         to `CONSTANT_Utf8_info.bytes` only. Computing a checksum for
>>>         it resulted in the same checksums for both classfiles.
>>>
>>>
>>>     Let's understand the whole approach with an example of Proxy class.
>>>
>>>     `
>>>     public  final  class  $Proxy42  extends  Proxy  implements  org.apache.logging.log4j.core.config.plugins.Plugin  {
>>>     `
>>>
>>>     The will go in the allowlist as "Proxy_Plugin: <SHA256 checksum>".
>>>
>>>     When the same class is intercepted at runtime, say "$Proxy10", we
>>>     look for "Proxy_Plugin" in the allowlist and since the checksum
>>>     algorithm is same in both cases, we get a match and let the class
>>>     load.
>>>
>>>     This approach has seemed to work well for Proxy classes, Generated
>>>     Constructor Accessor (which is removed as you said). I also looked
>>>     at the species generated by method handles. I did not notice any
>>>     modification in them. Their name generation seemed okay to me. If
>>>     some new Species are generated, it is of course detected since it
>>>     is not in the allowlist.
>>>
>>>     I have not looked into LambdaMetafactory because I did not
>>>     encounter it as a problem so far, but I am aware its name
>>>     generation is also unstable. I have run my approach only a few
>>>     projects only. And for hidden classes, I assume the the agent
>>>     won't be able to intercept them so detecting them would be really
>>>     hard.
>>>
>>>
>>>     Regards,
>>>     Aman Sharma
>>>
>>>     PhD Student
>>>     KTH Royal Institute of Technology
>>>     School of Electrical Engineering and Computer Science (EECS)
>>>     Department of Theoretical Computer Science (TCS)
>>>     <https://www.kth.se/profile/amansha
> <https://www.kth.se/profile/amansha>>https://algomaster99.github.io/
> <https://algomaster99.github.io/ <https://algomaster99.github.io/>>
>>>     ------------------------------------------------------------------------
>>>     *From:* liangchenblue at gmail.com<mailto:liangchenblue at gmail.com> <mailto:liangchenblue at gmail.com<mailto:liangchenblue at gmail.com> <mailto:liangchenblue at gmail.com>>
>>>     <liangchenblue at gmail.com<mailto:liangchenblue at gmail.com>> <mailto:liangchenblue at gmail.com<mailto:liangchenblue at gmail.com> <mailto:liangchenblue at gmail.com>>
>>>     *Sent:* Thursday, May 16, 2024 5:52:03 AM
>>>     *To:* Aman Sharma; core-libs-dev
>>>     *Cc:* Martin Monperrus
>>>     *Subject:* Re: Deterministic naming of subclasses of
>>>     `java/lang/reflect/Proxy`
>>>     Hi Aman,
>>>     I think you meant CVE-2021-42392 instead of 2022.
>>>
>>>     For your approach of an "allowlist" for Java runtime, project
>>>     Leyden is looking to generate a static image [1], that
>>>     > At run time it cannot load classes from outside the image, nor
>>>     can it create classes dynamically.
>>>     Leyden mainly avoids this unstable generation by performing a
>>>     training run to collect classes loaded and even object graphs; I
>>>     am not familiar with the details unfortunately.
>>>
>>>     Otherwise, the Proxy discussion belongs better to core-libs-dev,
>>>     as java.lang.reflect.Proxy is part of Java's core libraries. I am
>>>     replying this thread to core-libs-dev.
>>>
>>>     For your perceived problem that classes don't have unique names,
>>>     your description sounds dubious: GeneratedConstructorAccessor is
>>>     already retired by JEP 416 [2] in Java 18, and there are many
>>>     other cases in which JDK generates classes without stable names,
>>>     notoriously LambdaMetafactory (Gradle wished for cacheable
>>>     Lambdas); the same applies for the generated classes for
>>>     MethodHandle's LambdaForms (which carries implementation code for
>>>     LambdaForm). How are you checking the classes? It seems you are
>>>     not checking hidden classes. Proxy and Lambda classes are defined
>>>     by the caller's class loader, while LambdaForms are under JDK's
>>>     system class loader I think. We need to ensure you are correctly
>>>     finding all unstable classes before we can proceed.
>>>
>>>     [1]: https://openjdk.org/projects/leyden/notes/01-beginnings
> <https://openjdk.org/projects/leyden/notes/01-beginnings>
>>>     <https://openjdk.org/projects/leyden/notes/01-beginnings
> <https://openjdk.org/projects/leyden/notes/01-beginnings>>
>>>     [2]: https://openjdk.org/jeps/416 <https://openjdk.org/jeps/416>
> <https://openjdk.org/jeps/416 <https://openjdk.org/jeps/416>>
>>>
>>>     On Wed, May 15, 2024 at 7:00?PM Aman Sharma <amansha at kth.se<mailto:amansha at kth.se>
>>>     <mailto:amansha at kth.se<mailto:amansha at kth.se> <mailto:amansha at kth.se>>> wrote:
>>>
>>>         Hi,
>>>
>>>
>>>         My name is Aman and I am a PhD student at KTH Royal Institute
>>>         of Technology, Stockholm, Sweden. I research as part of CHAINS
>>>         <https://chains.proj.kth.se/ <https://chains.proj.kth.se/>> project to
> strengthen the
>>>         software supply chain of multiple ecosystem. I particularly
>>>         focus on runtime integrity in Java. In this email, I want to
>>>         write about an issue I have discovered with /dynamic
>>>         generation of `java.lang.reflect.Proxy`classes/. I will
>>>         propose a solution and would love to hear the feedback from
>>>         the community. Let me know if this is the correct mailing-list
>>>         for such discussions. It seemed the most relevant from this
>>>         list <https://mail.openjdk.org/mailman/listinfo
> <https://mail.openjdk.org/mailman/listinfo>>.
>>>
>>>
>>>         *My research*
>>>
>>>         *
>>>         *
>>>
>>>         Java has features to load class on the fly - it can either
>>>         download or generate a class at runtime. These features are
>>>         useful for inner workings of JDK. For example, implementing
>>>         annotations, reflective access, etc. However, these features
>>>         have also contributed to critical vulnerabilities in the past
>>>         - CVE-2021-44228  (log4shell), CVE-2022-33980, CVE-2022-42392.
>>>         All of these vulnerabilities have one thing in common - /a
>>>         class that was not known during build time was
>>>         downloaded/generated at runtime and loaded into JVM./
>>>
>>>
>>>         To defend against such vulnerabilities, we propose a solution
>>>         to /allowlist classes for runtime/. This allowlist will
>>>         contain an exhaustive list of classes that can be loaded by
>>>         the JVM and it will be enforced at runtime. We build this
>>>         allowlist from three sources:
>>>
>>>          1. All classes of all modules provided by the Java Standard
>>>             Library. We use ClassGraph
>>>             <https://github.com/classgraph/classgraph
> <https://github.com/classgraph/classgraph>> to scan the JDK.
>>>          2. We can take the source code and all dependencies of an
>>>             application. We use a software bill of materials to get
>>>             all the data.
>>>          3. Finally, we use run the test suite to include any runtime
>>>             downloaded/generated classes.
>>>
>>>         Such a list is able to prevent the above 3 CVEs because it
>>>         does not let the "unknown" bytecode to be loaded.
>>>
>>>         *Problem with generating such an allowlist*
>>>         *
>>>         *
>>>         The first two parts of the allowlist are easy to get. The
>>>         problem is with the third step where we want to allowlist all
>>>         the classes that could be downloaded or generated. Upon
>>>         running the test suite and hooking to the classes it loads, we
>>>         observer that the list consists of classes that are called
>>>         "com/sun/proxy/$Proxy2",
>>>         "jdk/internal/reflect/GeneratedConstructorAccessor3" among
>>>         many more. The purpose of these classes can be identifed. The
>>>         proxy class is created for to implement an annotation. The
>>>         accessor gives access to constructor of a class to the JVM.
>>>
>>>         When enforcing this allowlist at runtime, we see that the
>>>         bytecode content for "com/sun/proxy/$Proxy2" differs in the
>>>         allowlist and at runtime. In our case, we we are experimenting
>>>         with pdfbox <https://github.com/apache/pdfbox <https://github.com/apache/pdfbox>> so
> we created
>>>         the allowlist using its test suite. Then we enforced this
>>>         allowlist while running some of its subcommands. However,
>>>         there was some other proxy class say "com/sun/proxy/$Proxy5"
>>>         at runtime that implemented the same interfaces and had the
>>>         same methods as "com/sun/proxy/$Proxy2" in the allowlist. They
>>>         only differed in the name of the class, order of fields, and
>>>         types for fields references. This could happen because the
>>>         order of the loading of class is workload dependent, but it
>>>         causes problem to generate such an allowlist.
>>>
>>>         *Solution
>>>         *
>>>
>>>
>>>         We propose that naming of subclasses of
>>>         "java/lang/reflect/Proxy" should not be dependent upon the
>>>         order of loading. In order to do so, two issues can be fixed:
>>>
>>>          1. The naming of the class should not be based on AtomicLong
>>>             <https://github.com/openjdk/jdk/blob/b687aa550837830b38f0f0faa69c353b1e85219c/src/java.base/share/classes/java/lang/reflect/Proxy.java#L531 <https://github.com/openjdk/jdk/blob/b687aa550837830b38f0f0faa69c353b1e85219c/src/java.base/share/classes/java/lang/reflect/Proxy.java#L531>>. Rather it could be named based on the interfaces it implements. I also wonder why AtomicLong is chosen in the first place.
>>>          2. Methods of the interfaces must be in a particular order.
>>>             Right now, they are not sorted in any particular order
>>>             <https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/lang/Class.java#L2178 <https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/lang/Class.java#L2178>>.
>>>
>>>
>>>         These fixes will make proxy class generation deterministic
>>>         with respect to order of loading and won't be flagged at
>>>         runtime since the test suite would already detect them.
>>>
>>>         I would love to hear from the community about these ideas. If
>>>         in agreement, I would be happy to produce a patch. I have
>>>         discovered this issue with subclasses of
>>>         GeneratedConstructorAccessor
>>>         <https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/jdk/internal/reflect/ConstructorAccessor.java <https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/jdk/internal/reflect/ConstructorAccessor.java>> as well and I imagine it will also apply to some other runtime generated classes. If you disagree, please let me know also. It helps with my research.
>>>
>>>         I also have PoCs for the above CVEs
>>>         <https://github.com/chains-project/exploits-for-sbom.exe
> <https://github.com/chains-project/exploits-for-sbom.exe>> and
>>>         a proof concept tool is being developed under the name
>>>         sbom.exe <https://github.com/chains-project/sbom.exe
> <https://github.com/chains-project/sbom.exe>> in case
>>>         any one wonders about the implementation. I would also be
>>>         happy to explain more.
>>>
>>>         Regards,
>>>         Aman Sharma
>>>
>>>         PhD Student
>>>         KTH Royal Institute of Technology
>>>         School of Electrical Engineering and Computer Science (EECS)
>>>         Department of Theoretical Computer Science (TCS)
>>>         <https://www.kth.se/profile/amansha
> <https://www.kth.se/profile/amansha>>https://algomaster99.github.io/
> <https://algomaster99.github.io/ <https://algomaster99.github.io/>>
>>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240522/678ec047/attachment-0001.htm>

From prappo at openjdk.org  Wed May 22 14:16:41 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Wed, 22 May 2024 14:16:41 GMT
Subject: RFR: 8305457: Implement java.io.IO [v12]
In-Reply-To: <w2msiw_qaMEIJS3s9D4bg8pFbz5WIF0KdP6Mm-XFjLI=.85b2020b-8c46-4bac-8a69-4975b068f2ff@github.com>
References: <w2msiw_qaMEIJS3s9D4bg8pFbz5WIF0KdP6Mm-XFjLI=.85b2020b-8c46-4bac-8a69-4975b068f2ff@github.com>
Message-ID: <eKVj-jrfX6Lg2hLfJN_gcBSVu5dvAFRpPUBOXQkNIXE=.0e858744-918a-41d5-96d5-0f504817462b@github.com>

> Please review this PR which introduces the `java.io.IO` top-level class and three methods to `java.io.Console` for [Implicitly Declared Classes and Instance Main Methods (Third Preview)].
> 
> This PR has been obtained as `git merge --squash` of a now obsolete [draft PR].
> 
> [Implicitly Declared Classes and Instance Main Methods (Third Preview)]: https://bugs.openjdk.org/browse/JDK-8323335
> [draft PR]: https://github.com/openjdk/jdk/pull/18921

Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:

  Force reasonable terminal size
  
  JLine outputs unexpected stuff if the terminal isn't dumb and small,
  such as that of our CI machines:
  
      if (newLines.size() > displaySize && !isTerminalDumb()) {
          StringBuilder sb = new StringBuilder(">....");
  
  This causes the IO test to fail with timeout, because the expected
  prompt is never matched. To avoid that, we reasonably size the
  terminal.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19112/files
  - new: https://git.openjdk.org/jdk/pull/19112/files/719560f6..e252c5d8

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19112&range=11
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19112&range=10-11

  Stats: 8 lines in 2 files changed: 1 ins; 6 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/19112.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19112/head:pull/19112

PR: https://git.openjdk.org/jdk/pull/19112

From duke at openjdk.org  Wed May 22 14:22:16 2024
From: duke at openjdk.org (Volodymyr Paprotski)
Date: Wed, 22 May 2024 14:22:16 GMT
Subject: RFR: 8329538: Accelerate P256 on x86_64 using Montgomery intrinsic
 [v12]
In-Reply-To: <kuMyLYSd4dOC7qBbk9G7ZtvntC1U3FR5V35jLP1qHtQ=.e1459498-2ab5-48b1-8490-25dc94d49b1d@github.com>
References: <hanRK4GzOkFV8kG1gZRy8Br53trw4-Tu6G6uO8nsFuk=.d5bf723a-f683-4759-ac9e-4a58cb430f03@github.com>
 <kuMyLYSd4dOC7qBbk9G7ZtvntC1U3FR5V35jLP1qHtQ=.e1459498-2ab5-48b1-8490-25dc94d49b1d@github.com>
Message-ID: <2HF_LGpK7B6i1UcgJ8g9JgzGF27gVAHZkGnVQk-Fo4w=.98339735-cd89-4059-a449-6a4911e9af41@github.com>

On Tue, 21 May 2024 17:41:46 GMT, Volodymyr Paprotski <duke at openjdk.org> wrote:

>> Performance. Before:
>> 
>> Benchmark                        (algorithm)  (dataSize)  (keyLength)  (provider)   Mode  Cnt     Score    Error  Units
>> SignatureBench.ECDSA.sign    SHA256withECDSA        1024          256              thrpt    3  6443.934 ?  6.491  ops/s
>> SignatureBench.ECDSA.sign    SHA256withECDSA       16384          256              thrpt    3  6152.979 ?  4.954  ops/s
>> SignatureBench.ECDSA.verify  SHA256withECDSA        1024          256              thrpt    3  1895.410 ? 36.979  ops/s
>> SignatureBench.ECDSA.verify  SHA256withECDSA       16384          256              thrpt    3  1878.955 ? 45.487  ops/s
>> Benchmark                                            (algorithm)  (keyLength)  (kpgAlgorithm)  (provider)   Mode  Cnt     Score    Error  Units
>> o.o.b.j.c.full.KeyAgreementBench.EC.generateSecret          ECDH          256              EC              thrpt    3  1357.810 ? 26.584  ops/s
>> o.o.b.j.c.small.KeyAgreementBench.EC.generateSecret         ECDH          256              EC              thrpt    3  1352.119 ? 23.547  ops/s
>> Benchmark                          (isMontBench)   Mode  Cnt     Score    Error  Units
>> PolynomialP256Bench.benchMultiply          false  thrpt    3  1746.126 ? 10.970  ops/s
>> 
>> Performance, no intrinsic:
>> 
>> Benchmark                        (algorithm)  (dataSize)  (keyLength)  (provider)   Mode  Cnt     Score     Error  Units
>> SignatureBench.ECDSA.sign    SHA256withECDSA        1024          256              thrpt    3  6529.839 ?  42.420  ops/s
>> SignatureBench.ECDSA.sign    SHA256withECDSA       16384          256              thrpt    3  6199.747 ? 133.566  ops/s
>> SignatureBench.ECDSA.verify  SHA256withECDSA        1024          256              thrpt    3  1973.676 ?  54.071  ops/s
>> SignatureBench.ECDSA.verify  SHA256withECDSA       16384          256              thrpt    3  1932.127 ?  35.920  ops/s
>> Benchmark                                            (algorithm)  (keyLength)  (kpgAlgorithm)  (provider)   Mode  Cnt     Score    Error  Units
>> o.o.b.j.c.full.KeyAgreementBench.EC.generateSecret          ECDH          256              EC              thrpt    3  1355.788 ? 29.858  ops/s
>> o.o.b.j.c.small.KeyAgreementBench.EC.generateSecret         ECDH          256              EC              thrpt    3  1346.523 ? 28.722  ops/s
>> Benchmark                          (isMontBench)   Mode  Cnt     Score    Error  Units
>> PolynomialP256Bench.benchMultiply           true  thrpt    3  1919.57...
>
> Volodymyr Paprotski has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 17 additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'origin/master' into ecc-montgomery
>  - shenandoah verifier
>  - comments from Sandhya
>  - whitespace
>  - add message back
>  - whitespace
>  - Use AffinePoint to exit Montgomery domain
>    
>    Style notes:
>    Affine.equals()
>        - Mismatched fields only appear to be used from testing, perhaps should be moved there instead
>    Affine.getX(boolean)|getY(boolean)
>        - "Passing flag is bad design" - cleanest/performant alternative to several instanceof checks
>        - needed to convert Affine to Projective (need to stay in montgomery domain)
>    ECOperations.PointMultiplier
>       - changes could probably be restored to original (since ProjectivePoint handling no longer required)
>       - consider these changes an improvement? (fewer nested classes)
>       - was an inner-class but not using inner-class features (i.e. ecOps variable should be converted)
>  - whitespace
>  - Comments from Tony and Jatin
>  - Comments from Jatin and Tony
>  - ... and 7 more: https://git.openjdk.org/jdk/compare/c0032e2c...b1a33004

Thanks Tobi!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18583#issuecomment-2124924526

From sgibbons at openjdk.org  Wed May 22 14:26:18 2024
From: sgibbons at openjdk.org (Scott Gibbons)
Date: Wed, 22 May 2024 14:26:18 GMT
Subject: RFR: 8320448: Accelerate IndexOf using AVX2 [v6]
In-Reply-To: <U3PQa9RYF_exiJ9GDtbpfr5olJR1p9NUdWq35jLYUYk=.ece7a995-c3b7-4eeb-b72f-8e078fa69706@github.com>
References: <uWi4QxH31hL93771gkl_GgvP0m84IRSoR_1Yi8hD17E=.bc6ed458-7081-4c3f-9348-f59358fa05a4@github.com>
 <AvEu_RbJzfwgeNtt1nqHcyybha-iHuCXMoWXPWL3TFQ=.13823da6-b1b6-49b6-ba3f-56ef03dbc097@github.com>
 <U3PQa9RYF_exiJ9GDtbpfr5olJR1p9NUdWq35jLYUYk=.ece7a995-c3b7-4eeb-b72f-8e078fa69706@github.com>
Message-ID: <-IZk0dL-Bd2Gp5zsI3DSsHzNl6-6lB_8HRd4KkBUALw=.0ee706a8-9281-40f8-a0ba-d53385edcdcf@github.com>

On Tue, 9 Jan 2024 15:06:10 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

>> Scott Gibbons has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 21 commits:
>> 
>>  - Merge branch 'openjdk:master' into indexof
>>  - Addressing review comments.
>>  - Fix for JDK-8321599
>>  - Support UU IndexOf
>>  - Only use optimization when EnableX86ECoreOpts is true
>>  - Fix whitespace
>>  - Merge branch 'openjdk:master' into indexof
>>  - Comments; added exhaustive-ish test
>>  - Subtracting 0x10 twice.
>>  - Stomped on r13 in switch branch calculation
>>  - ... and 11 more: https://git.openjdk.org/jdk/compare/8a4dc79e...600377b0
>
> src/hotspot/cpu/x86/stubGenerator_x86_64_string.cpp line 1608:
> 
>> 1606:     //   vector compares when size is 2 * VEC_SIZE or less. 38    8. Use 4
>> 1607:     //   vector compares when size is 4 * VEC_SIZE or less. 39    9. Use 8
>> 1608:     //   vector compares when size is 8 * VEC_SIZE or less.  */
> 
> Is this formatting intended?

Fixed

> src/hotspot/cpu/x86/stubGenerator_x86_64_string.cpp line 1672:
> 
>> 1670: 
>> 1671:     // 98              VPCMPEQ VEC_SIZE(%rdi), %ymm2, %ymm2
>> 1672:     // 99              vpmovmskb %ymm2, %eax
> 
> It seems that here the comments and code is strangely interleaved / shifted. What is this all for?

All this has been remedied

> src/hotspot/cpu/x86/stubGenerator_x86_64_string.cpp line 2301:
> 
>> 2299:     // 388             setg    %dl
>> 2300:     // 389             leal    -1(%rdx, %rdx), %eax
>> 2301:     __ movzbl(rcx, Address(rsi, rax, Address::times_1, -0x20));
> 
> Down here it is even worse

All this has been remedied

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1610074501
PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1610076284
PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1610076661

From yzheng at openjdk.org  Wed May 22 14:31:16 2024
From: yzheng at openjdk.org (Yudi Zheng)
Date: Wed, 22 May 2024 14:31:16 GMT
Subject: RFR: 8327964: Simplify BigInteger.implMultiplyToLen intrinsic [v5]
In-Reply-To: <EYByM73-dAJnDr1feKyeIBHK8ydoHh24wgn1opwTX0s=.c6e64958-7cf3-47de-a5a8-ec4a18c21ad0@github.com>
References: <Z5U-3OSq9_rd0t6DHNRhjF3LHtc9b6orz-mcQ4Uqzl8=.c4f0a0b8-9e10-4505-82f7-7d3a82929d22@github.com>
 <mPGL9bhNOXF_0OStOh5bbG8PtunR_adftSmWy0Jr4NQ=.a8bb895a-25e1-4d60-988e-d306c63cf7e8@github.com>
 <EYByM73-dAJnDr1feKyeIBHK8ydoHh24wgn1opwTX0s=.c6e64958-7cf3-47de-a5a8-ec4a18c21ad0@github.com>
Message-ID: <1nU6OzVHKjN_v9tJD4vTnoQa6hTn5CgDF15PQsyr5YE=.ed74dc2b-33f8-4828-a730-43f03a9aa4ab@github.com>

On Wed, 17 Apr 2024 19:33:01 GMT, Dean Long <dlong at openjdk.org> wrote:

>> Yudi Zheng has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   address comment.
>
> src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 4670:
> 
>> 4668:     const Register tmp5  = r15;
>> 4669:     const Register tmp6  = r16;
>> 4670:     const Register tmp7  = r17;
> 
> Why not minimize changes and continue to use r5 for tmp0?  I see no need for r17 or to reassign all the other tmp registers.

Was attempting to align the suffixes. Will revert.

> src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 4693:
> 
>> 4691:     const Register xlen  = r1;
>> 4692:     const Register z     = r2;
>> 4693:     const Register zlen  = r3;
> 
> LibraryCallKit::inline_squareToLen() is still computing zlen and passing it as the 4th arg, even though the value is unused.

ppc x86 are not using `multiply_to_len` for `generate_squareToLen`. I think we still need to pass zlen for these platforms.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18226#discussion_r1610083476
PR Review Comment: https://git.openjdk.org/jdk/pull/18226#discussion_r1610088021

From yzheng at openjdk.org  Wed May 22 14:47:43 2024
From: yzheng at openjdk.org (Yudi Zheng)
Date: Wed, 22 May 2024 14:47:43 GMT
Subject: RFR: 8327964: Simplify BigInteger.implMultiplyToLen intrinsic [v3]
In-Reply-To: <msXjYZiGIRrXhgws7k4vKA3QbZdse1uqj_tszjCortA=.cdd2b95d-6101-47cb-a4b6-6c8bf466c689@github.com>
References: <Z5U-3OSq9_rd0t6DHNRhjF3LHtc9b6orz-mcQ4Uqzl8=.c4f0a0b8-9e10-4505-82f7-7d3a82929d22@github.com>
 <zMKT2cOKMHo76IFkz5uh8NOa07lp1NhleOJFKDi_v8c=.b5605b07-077e-4cf8-9014-f9a169b0af46@github.com>
 <IEbiW8OAUyzLJ9NWnSZEI_iOYBfJrsIy-wc8KF-R92I=.72f6c6e6-af4f-495e-8612-f1bb6318ec67@github.com>
 <pJ7EHSw1QUoVy60dGjR81GdoPzlibyDv-kZ-FmfRvt4=.9bdab17c-0e27-4ba7-a68b-9a2307641244@github.com>
 <msXjYZiGIRrXhgws7k4vKA3QbZdse1uqj_tszjCortA=.cdd2b95d-6101-47cb-a4b6-6c8bf466c689@github.com>
Message-ID: <m1aSAk-ZQrU8T2X8CH8WnI8fQUbumfWeIjVpytKhMNU=.cb7dc810-db00-4267-a299-daa0a7483f22@github.com>

On Mon, 20 May 2024 10:41:36 GMT, Bhavana Kilambi <bkilambi at openjdk.org> wrote:

>> @dafedafe @dean-long please take a look and let me know if there are further issues, thanks!
>
> Hi @mur47x111, do you happen to have any performance results with this patch?

@Bhavana-Kilambi the performance result for x86 is at https://github.com/openjdk/jdk/pull/18226#issuecomment-2007922439 . It is expected to be negligible.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18226#issuecomment-2124984579

From yzheng at openjdk.org  Wed May 22 14:47:43 2024
From: yzheng at openjdk.org (Yudi Zheng)
Date: Wed, 22 May 2024 14:47:43 GMT
Subject: RFR: 8327964: Simplify BigInteger.implMultiplyToLen intrinsic [v6]
In-Reply-To: <Z5U-3OSq9_rd0t6DHNRhjF3LHtc9b6orz-mcQ4Uqzl8=.c4f0a0b8-9e10-4505-82f7-7d3a82929d22@github.com>
References: <Z5U-3OSq9_rd0t6DHNRhjF3LHtc9b6orz-mcQ4Uqzl8=.c4f0a0b8-9e10-4505-82f7-7d3a82929d22@github.com>
Message-ID: <GkTIvOKs4GDKUOPjaw893H4fAoeBDuzQn4kKnQqG2dA=.7762f50b-40b1-4763-940b-7e0c8a66d466@github.com>

> Moving array construction within BigInteger.implMultiplyToLen intrinsic candidate to its caller simplifies the intrinsic implementation in JIT compiler.

Yudi Zheng has updated the pull request incrementally with one additional commit since the last revision:

  address comments.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/18226/files
  - new: https://git.openjdk.org/jdk/pull/18226/files/72ba58ce..7c6023f8

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18226&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18226&range=04-05

  Stats: 24 lines in 2 files changed: 0 ins; 0 del; 24 mod
  Patch: https://git.openjdk.org/jdk/pull/18226.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18226/head:pull/18226

PR: https://git.openjdk.org/jdk/pull/18226

From yzheng at openjdk.org  Wed May 22 14:47:43 2024
From: yzheng at openjdk.org (Yudi Zheng)
Date: Wed, 22 May 2024 14:47:43 GMT
Subject: RFR: 8327964: Simplify BigInteger.implMultiplyToLen intrinsic [v5]
In-Reply-To: <HhvLM3UiMNXYqVgcFf0qPe8R3Fx6X1gdJEgtbf_p7h8=.38a8fa93-de8a-4478-82de-ab939e537927@github.com>
References: <Z5U-3OSq9_rd0t6DHNRhjF3LHtc9b6orz-mcQ4Uqzl8=.c4f0a0b8-9e10-4505-82f7-7d3a82929d22@github.com>
 <mPGL9bhNOXF_0OStOh5bbG8PtunR_adftSmWy0Jr4NQ=.a8bb895a-25e1-4d60-988e-d306c63cf7e8@github.com>
 <HhvLM3UiMNXYqVgcFf0qPe8R3Fx6X1gdJEgtbf_p7h8=.38a8fa93-de8a-4478-82de-ab939e537927@github.com>
Message-ID: <uqzF8ulUYBd6rDsHB1Dl6adYEdyPdNm700Dw6jBHhpg=.cfb32f57-58db-4a60-a848-f846c8fe7843@github.com>

On Wed, 17 Apr 2024 20:04:44 GMT, Dean Long <dlong at openjdk.org> wrote:

>> Yudi Zheng has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   address comment.
>
> src/hotspot/cpu/x86/macroAssembler_x86.cpp line 6662:
> 
>> 6660:   push(tmp5);
>> 6661: 
>> 6662:   push(xlen);
> 
> There may be an opportunity here (separate RFE?) to get rid of the save/restore for these.  I don't think it's necessary if this is called as part of a C2 stub.

In the Graal port we did get rid of these save/restore.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18226#discussion_r1610126799

From sgibbons at openjdk.org  Wed May 22 14:53:16 2024
From: sgibbons at openjdk.org (Scott Gibbons)
Date: Wed, 22 May 2024 14:53:16 GMT
Subject: RFR: 8320448: Accelerate IndexOf using AVX2 [v13]
In-Reply-To: <oRt7NAJM09gHPJjvjfsIso3kemxAusH7mhNePnsGVbI=.e27e2420-4a20-436a-b33e-d95f15f09dd8@github.com>
References: <uWi4QxH31hL93771gkl_GgvP0m84IRSoR_1Yi8hD17E=.bc6ed458-7081-4c3f-9348-f59358fa05a4@github.com>
 <MZj_08eJiTVFJyis-u7V8SBGal_cJ-6tIYr0oFseVpY=.329ca24b-48e3-4c3d-80ec-a395d9d8a4d5@github.com>
 <oRt7NAJM09gHPJjvjfsIso3kemxAusH7mhNePnsGVbI=.e27e2420-4a20-436a-b33e-d95f15f09dd8@github.com>
Message-ID: <XhEGOun3UCOHrZ_jwl0GDvQbdPZyM2WRXOFTMO_lEDY=.2c6d815b-ba29-40c9-a7e9-55868887f6b2@github.com>

On Mon, 26 Feb 2024 14:50:30 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Scott Gibbons has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Addressed some review coments; replaced hard-coded registers with descriptive names.
>
> src/hotspot/cpu/x86/stubGenerator_x86_64_string.cpp line 303:
> 
>> 301:       __ subq(rdi, rax);
>> 302:       __ movq(rdx, rdi);
>> 303:       __ andq(rdx, -16);
> 
> Hi @asgibbons , may I request you to please use meaningful names instead of directly using actual GPR names to ease the review process.

Done.

> src/hotspot/cpu/x86/stubGenerator_x86_64_string.cpp line 777:
> 
>> 775:       __ movq(rax, rbx);
>> 776:       __ movq(rbx, r14);
>> 777:       __ leaq(r15, Address(r12, -0x2));
> 
> Kindly use semantically meaningful names instead of direct GPR names.

Done.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1610121347
PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1610121724

From sgibbons at openjdk.org  Wed May 22 14:53:17 2024
From: sgibbons at openjdk.org (Scott Gibbons)
Date: Wed, 22 May 2024 14:53:17 GMT
Subject: RFR: 8320448: Accelerate IndexOf using AVX2 [v19]
In-Reply-To: <JvETaWJA4KnaZjDzF5e_LX9oUOzHYqHGZtqcjx0NVb4=.db09b2ca-34a0-4997-a9f1-fd985181866c@github.com>
References: <uWi4QxH31hL93771gkl_GgvP0m84IRSoR_1Yi8hD17E=.bc6ed458-7081-4c3f-9348-f59358fa05a4@github.com>
 <eQ4OBFrF8JlDJ1h9awTDOc0kfCc37IlL5vdqtuaqls0=.8f00616d-08e1-4f28-a7a5-5095116d2595@github.com>
 <JvETaWJA4KnaZjDzF5e_LX9oUOzHYqHGZtqcjx0NVb4=.db09b2ca-34a0-4997-a9f1-fd985181866c@github.com>
Message-ID: <8ifsYHB0SLuD1ZbWhMWmBZn_UjW-iNpXrmsIkZFUczg=.ce670add-3afb-48be-8c81-2fd462d19bbd@github.com>

On Mon, 6 May 2024 23:19:07 GMT, Sandhya Viswanathan <sviswanathan at openjdk.org> wrote:

>> Scott Gibbons has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Rearrange; add lambdas for clarity
>
> src/hotspot/cpu/x86/stubGenerator_x86_64_string.cpp line 329:
> 
>> 327:     ////////////////////////////////////////////////////////////////////////////////////////
>> 328: 
>> 329:     __ bind(L_begin);
> 
> So far we have handled haystack <= 32 and needle_size <= 5 (?) in bytes. A high level algorithm description here is needed in comments to follow the code below.  A description of what are the various paths in terms of haystack and needle sizes and how to reason the assembly code below and make sure that all the paths are taken care of. Also the abstraction level suddenly changes here to detailed code below instead of methods for the various paths.

I added a description.  Can you please check to ensure it meets your objective?  Thanks.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1610124233

From sgibbons at openjdk.org  Wed May 22 14:53:26 2024
From: sgibbons at openjdk.org (Scott Gibbons)
Date: Wed, 22 May 2024 14:53:26 GMT
Subject: RFR: 8320448: Accelerate IndexOf using AVX2 [v7]
In-Reply-To: <0XxCusssrDiiKzXBfdsY1XHkv9T6mJwJe7dwFz5Uy-I=.3325e496-5bf1-4a79-8969-e28e018b77db@github.com>
References: <uWi4QxH31hL93771gkl_GgvP0m84IRSoR_1Yi8hD17E=.bc6ed458-7081-4c3f-9348-f59358fa05a4@github.com>
 <y6CvVY726SvrGFUAMqKCLcREj1ucQUYEiTg0E8y_6VQ=.a4dd5890-42a4-4c46-8321-9369d875ca43@github.com>
 <0XxCusssrDiiKzXBfdsY1XHkv9T6mJwJe7dwFz5Uy-I=.3325e496-5bf1-4a79-8969-e28e018b77db@github.com>
Message-ID: <dpnt56clrzd2jzVbowGlxWIwgm0cty0_we1zoHAakYI=.ffd16e17-96e2-4c7a-a83b-b734b24f903b@github.com>

On Tue, 16 Jan 2024 13:26:15 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Scott Gibbons has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 22 commits:
>> 
>>  - Merge branch 'openjdk:master' into indexof
>>  - Merge branch 'openjdk:master' into indexof
>>  - Addressing review comments.
>>  - Fix for JDK-8321599
>>  - Support UU IndexOf
>>  - Only use optimization when EnableX86ECoreOpts is true
>>  - Fix whitespace
>>  - Merge branch 'openjdk:master' into indexof
>>  - Comments; added exhaustive-ish test
>>  - Subtracting 0x10 twice.
>>  - ... and 12 more: https://git.openjdk.org/jdk/compare/8e12053e...3e58d0c2
>
> src/hotspot/cpu/x86/stubGenerator_x86_64_string.cpp line 417:
> 
>> 415:     __ cmpl(Address(rbx, r15, Address::times_1, -0x14), rax);
>> 416:     __ jne(L_top_loop_1);
>> 417:     __ jmp(L_0x406019);
> 
> For cases which are multiple of 4 bytes we can use VMASKMOVPS (conditional moves) and VPTEST.

Not sure what you mean here.  Could you elaborate (although it may be moot after all the changes)?

> src/hotspot/cpu/x86/stubGenerator_x86_64_string.cpp line 1526:
> 
>> 1524:     __ movq(rdx, r8);
>> 1525:     __ movq(rcx, r9);
>> 1526: #endif
> 
> Can we spill them into XXMs, to save costly stack operations.

Changed.

> src/hotspot/cpu/x86/stubGenerator_x86_64_string.cpp line 1545:
> 
>> 1543:     //   return 0;
>> 1544:     // }
>> 1545:     __ movq(r12, rcx);
> 
> Check for K == 0 should use rsi.

k is needle length, which is rcx.

> src/hotspot/cpu/x86/stubGenerator_x86_64_string.cpp line 1545:
> 
>> 1543:     //   return 0;
>> 1544:     // }
>> 1545:     __ movq(r12, rcx);
> 
> Kindly use meaningful variable and label names. It will ease the review process and maintenance.

Done.

> src/hotspot/cpu/x86/stubGenerator_x86_64_string.cpp line 1551:
> 
>> 1549:     __ movq(r15, rsi);
>> 1550:     __ movq(r11, rdi);
>> 1551:     __ cmpq(rsi, 0x20);
> 
> Comparisons with 32 bit integer length can use cmpl instead of cmpq, this may save emitting REX encoding prefix if index is allocated a GPR from lower register bank (no need for setting REX.W).

I fixed as many as I could find.  Thanks.

> src/hotspot/cpu/x86/stubGenerator_x86_64_string.cpp line 1552:
> 
>> 1550:     __ movq(r11, rdi);
>> 1551:     __ cmpq(rsi, 0x20);
>> 1552:     __ jb(L_small_string);
> 
> All the comparisons against needle length are signed integer comparisons, so jb should be replaced by jl

I'm treating everything as unsigned except where intentional negative values are used.  It never makes sense for needle length to be negative.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1610118449
PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1610110754
PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1610105405
PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1610111320
PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1610113343
PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1610116033

From sgibbons at openjdk.org  Wed May 22 14:53:27 2024
From: sgibbons at openjdk.org (Scott Gibbons)
Date: Wed, 22 May 2024 14:53:27 GMT
Subject: RFR: 8320448: Accelerate IndexOf using AVX2 [v7]
In-Reply-To: <UynYzpbWaDK6yKJz0BnjHT90NiW6DbRGM3O5NeZfovQ=.4fec6216-656a-49fe-a806-b738daed5b89@github.com>
References: <uWi4QxH31hL93771gkl_GgvP0m84IRSoR_1Yi8hD17E=.bc6ed458-7081-4c3f-9348-f59358fa05a4@github.com>
 <y6CvVY726SvrGFUAMqKCLcREj1ucQUYEiTg0E8y_6VQ=.a4dd5890-42a4-4c46-8321-9369d875ca43@github.com>
 <Xb-U-_Ct_L7a8Liky0c4TCbhoFUfcnPIsn-xZ6RZdQA=.034ae95a-54e7-4497-a570-4d7a48676bd1@github.com>
 <UynYzpbWaDK6yKJz0BnjHT90NiW6DbRGM3O5NeZfovQ=.4fec6216-656a-49fe-a806-b738daed5b89@github.com>
Message-ID: <MZFU29sWhpKvmRXciGWtHW5bx8eOK3-aovLvlHPmCN0=.986bccb4-4e57-4df9-89ee-f5826a1feb39@github.com>

On Mon, 22 Jan 2024 07:08:31 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> src/hotspot/cpu/x86/stubGenerator_x86_64_string.cpp line 505:
>> 
>>> 503:     __ cmpb(Address(rbx, r15, Address::times_1, -0xa), rax);
>>> 504:     __ jne(L_top_loop_1);
>>> 505:     __ jmp(L_0x406019);
>> 
>> Instead of having special handling for each tail size (3 - 31 bytes), can we directly use 32 bytes VMASKMOVPS with appropriate mask for different tail sizes and only residual part (0 - 3 bytes) can fall over to scalar tail.
>
> Basically tail size can be rounded to nearest multiple of doubleword.

I have since changed the algorithm due to request from @sviswa7

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1610120366

From sgibbons at openjdk.org  Wed May 22 14:53:28 2024
From: sgibbons at openjdk.org (Scott Gibbons)
Date: Wed, 22 May 2024 14:53:28 GMT
Subject: RFR: 8320448: Accelerate IndexOf using AVX2 [v5]
In-Reply-To: <iYTxZYOoyZwslkBPlDmrHtWt17M3Br0YYJswEcooeqw=.ad03b10a-0cb4-4e58-a26e-4d2ff56729f6@github.com>
References: <uWi4QxH31hL93771gkl_GgvP0m84IRSoR_1Yi8hD17E=.bc6ed458-7081-4c3f-9348-f59358fa05a4@github.com>
 <jjgXujKNdw7Bt5KopUrv05_onDaqVqRU1auhh5kNqbA=.a9218000-d912-4395-85fd-59d67128d40d@github.com>
 <iYTxZYOoyZwslkBPlDmrHtWt17M3Br0YYJswEcooeqw=.ad03b10a-0cb4-4e58-a26e-4d2ff56729f6@github.com>
Message-ID: <8FGB4fvnPGhSSdLgY5POXyGajpA-b-Ir31ee1WrG660=.0afedbf4-b717-4d1a-a3f0-c36b5e02a4d8@github.com>

On Mon, 8 Jan 2024 10:32:51 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Scott Gibbons has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Addressing review comments.
>
> src/hotspot/share/opto/library_call.cpp line 1273:
> 
>> 1271:   Node* result = nullptr;
>> 1272: 
>> 1273:   if ((StubRoutines::string_indexof() != nullptr) && (ae == StrIntrinsicNode::LL)) {
> 
> Why are we not calling stub for StrIntrinsicNode::UU

Stub being called for LL, UL, and UU now.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1610089409

From sgibbons at openjdk.org  Wed May 22 14:53:30 2024
From: sgibbons at openjdk.org (Scott Gibbons)
Date: Wed, 22 May 2024 14:53:30 GMT
Subject: RFR: 8320448: Accelerate IndexOf using AVX2 [v6]
In-Reply-To: <U3PQa9RYF_exiJ9GDtbpfr5olJR1p9NUdWq35jLYUYk=.ece7a995-c3b7-4eeb-b72f-8e078fa69706@github.com>
References: <uWi4QxH31hL93771gkl_GgvP0m84IRSoR_1Yi8hD17E=.bc6ed458-7081-4c3f-9348-f59358fa05a4@github.com>
 <AvEu_RbJzfwgeNtt1nqHcyybha-iHuCXMoWXPWL3TFQ=.13823da6-b1b6-49b6-ba3f-56ef03dbc097@github.com>
 <U3PQa9RYF_exiJ9GDtbpfr5olJR1p9NUdWq35jLYUYk=.ece7a995-c3b7-4eeb-b72f-8e078fa69706@github.com>
Message-ID: <AvLpKIqj-EHimI7hUD89V6WamHSbXM4dYLPP-EH0evU=.071369c7-62a1-420d-a283-ba3fa4f226e2@github.com>

On Tue, 9 Jan 2024 15:14:41 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

>> Scott Gibbons has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 21 commits:
>> 
>>  - Merge branch 'openjdk:master' into indexof
>>  - Addressing review comments.
>>  - Fix for JDK-8321599
>>  - Support UU IndexOf
>>  - Only use optimization when EnableX86ECoreOpts is true
>>  - Fix whitespace
>>  - Merge branch 'openjdk:master' into indexof
>>  - Comments; added exhaustive-ish test
>>  - Subtracting 0x10 twice.
>>  - Stomped on r13 in switch branch calculation
>>  - ... and 11 more: https://git.openjdk.org/jdk/compare/8a4dc79e...600377b0
>
> test/jdk/java/lang/StringBuffer/IndexOf.java line 34:
> 
>> 32: public class IndexOf {
>> 33: 
>> 34:   static Random generator = new Random(1999);
> 
> Would it be an alternative to use the this:
> 
> import jdk.test.lib.Utils;
> ...
> Random random = Utils.getRandomInstance();
> 
> This has a random seed, but it is always printed in the output and can be set via a test-flag.

Changed.

> test/jdk/java/lang/StringBuffer/IndexOf.java line 44:
> 
>> 42:     }
>> 43:     System.out.println("");
>> 44:     generator.setSeed(1999);
> 
> Is there a good reason for a fixed seed?

Nope :-). Needed consistency during testing.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1610087089
PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1610088114

From sgibbons at openjdk.org  Wed May 22 14:53:31 2024
From: sgibbons at openjdk.org (Scott Gibbons)
Date: Wed, 22 May 2024 14:53:31 GMT
Subject: RFR: 8320448: Accelerate IndexOf using AVX2 [v19]
In-Reply-To: <aTbnceYj7mQGE4hpCoeUqv5r-W8iHSI_EqVncR0iU_s=.6a63f8c5-eafb-48d5-a871-4cc475e0f63f@github.com>
References: <uWi4QxH31hL93771gkl_GgvP0m84IRSoR_1Yi8hD17E=.bc6ed458-7081-4c3f-9348-f59358fa05a4@github.com>
 <eQ4OBFrF8JlDJ1h9awTDOc0kfCc37IlL5vdqtuaqls0=.8f00616d-08e1-4f28-a7a5-5095116d2595@github.com>
 <aTbnceYj7mQGE4hpCoeUqv5r-W8iHSI_EqVncR0iU_s=.6a63f8c5-eafb-48d5-a871-4cc475e0f63f@github.com>
Message-ID: <xwgol0oMgfd10mFw593hgE0wgaTsjCxA1ETGX3ZQLM0=.5a0bab49-7c5b-49ba-9a2c-4bee3a04ccd7@github.com>

On Wed, 15 May 2024 19:18:27 GMT, Volodymyr Paprotski <duke at openjdk.org> wrote:

>> Scott Gibbons has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Rearrange; add lambdas for clarity
>
> test/jdk/java/lang/StringBuffer/IndexOf.java line 54:
> 
>> 52:   // for (int i = 1; i < 128; i++) {
>> 53:   //   haystack_16[i] = (char) (i);
>> 54:   // }
> 
> dead code

Removed.

> test/jdk/java/lang/StringBuffer/IndexOf.java line 83:
> 
>> 81:   shs = "$&),,18+-!'8)+";
>> 82:   endNeedle = "8)-";
>> 83:   l_offset = 9;
> 
> dead code

Fixed.

> test/jdk/java/lang/StringBuffer/IndexOf.java line 237:
> 
>> 235:             + sourceBuffer.toString() + " len Buffer = " + sourceBuffer.toString().length());
>> 236:         System.err.println("  naive = " + naiveFind(sourceBuffer.toString(), targetString, 0) + ", IndexOf = "
>> 237:             + sourceBuffer.indexOf(targetString));
> 
> More tracing left behind here and rest of this function (original just recorded failure and moved along)

I think it's more valuable for a test to print out what it can when a failure occurs rather than just saying "failed".

> test/jdk/java/lang/StringBuffer/IndexOf.java line 284:
> 
>> 282: 
>> 283:   // Note: it is possible although highly improbable that failCount will
>> 284:   // be > 0 even if everthing is working ok
> 
> This sounds like either a bug or a testcase bug? Same as line 301, `extremely remote possibility of > 1 match`?

This was there from the original author.  I think they were trying to infer that a match could occur in the rare case that the same random string was produced.  They're random after all, and there's no reason the same sequence could be generated.

> test/micro/org/openjdk/bench/java/lang/StringIndexOfHuge.java line 81:
> 
>> 79:     lateMatchString16 = dataStringHuge16.substring(dataStringHuge16.length() - 31);
>> 80: 
>> 81:     searchString = "oscar";
> 
> Would had liked to see a few more small needles (i.e. to test/verify individual switch statement cases)

I'm hoping we can incorporate your test to cover more cases :-).

> test/micro/org/openjdk/bench/java/lang/StringIndexOfHuge.java line 132:
> 
>> 130:   @Benchmark
>> 131:   public int searchHugeLargeSubstring() {
>> 132:       return dataStringHuge.indexOf("B".repeat(30) + "X" + "A".repeat(30), 74);
> 
> .repeat() call and string concatenation shouldn't be part of the benchmark (here and several other @Benchmark functions in this file) since it will detract from the measurement.
> 
> (String concatenation gets converted (by javac) into StringBuilder().append().append()....append().toString())

Since we're only concerned with the delta of performance, does this really matter?  Can you suggest an alternative?

> test/micro/org/openjdk/bench/java/lang/StringIndexOfHuge.java line 242:
> 
>> 240:   @Benchmark
>> 241:   public int search16HugeLargeSubstring16() {
>> 242:     return dataStringHuge16.indexOf("B".repeat(30) + "X" + "A".repeat(30), 74);
> 
> `search16HugeLargeSubstring16` implies UU, but with `"B".repeat(30) + "X" + "A".repeat(30)` is UL

Fixed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1610131285
PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1610134566
PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1610138116
PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1610142104
PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1610130140
PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1610126743
PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1610128630

From sgibbons at openjdk.org  Wed May 22 14:53:31 2024
From: sgibbons at openjdk.org (Scott Gibbons)
Date: Wed, 22 May 2024 14:53:31 GMT
Subject: RFR: 8320448: Accelerate IndexOf using AVX2 [v7]
In-Reply-To: <3m2_CQE-NHOCN20Z4LbosqwihcUCVopTgycXADInLEI=.25f797e8-e620-4f10-9da0-245a890c41de@github.com>
References: <uWi4QxH31hL93771gkl_GgvP0m84IRSoR_1Yi8hD17E=.bc6ed458-7081-4c3f-9348-f59358fa05a4@github.com>
 <y6CvVY726SvrGFUAMqKCLcREj1ucQUYEiTg0E8y_6VQ=.a4dd5890-42a4-4c46-8321-9369d875ca43@github.com>
 <3m2_CQE-NHOCN20Z4LbosqwihcUCVopTgycXADInLEI=.25f797e8-e620-4f10-9da0-245a890c41de@github.com>
Message-ID: <WWCB0MEO-4_KLeDhImyv5vx0gYYBLsGaVyZ1L8g9XRM=.76d47d6d-3ba1-4337-bd4c-7523af24926e@github.com>

On Mon, 15 Jan 2024 13:30:42 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

>> Scott Gibbons has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 22 commits:
>> 
>>  - Merge branch 'openjdk:master' into indexof
>>  - Merge branch 'openjdk:master' into indexof
>>  - Addressing review comments.
>>  - Fix for JDK-8321599
>>  - Support UU IndexOf
>>  - Only use optimization when EnableX86ECoreOpts is true
>>  - Fix whitespace
>>  - Merge branch 'openjdk:master' into indexof
>>  - Comments; added exhaustive-ish test
>>  - Subtracting 0x10 twice.
>>  - ... and 12 more: https://git.openjdk.org/jdk/compare/8e12053e...3e58d0c2
>
> test/jdk/java/lang/StringBuffer/IndexOf.java line 220:
> 
>> 218: 
>> 219:     for (int x = 0; x < 1000000; x++) {
>> 220:     if(make_new) {
> 
> Suggestion:
> 
>     if (make_new) {

Fixed.

> test/jdk/java/lang/StringBuffer/IndexOf.java line 262:
> 
>> 260:       }
>> 261: 
>> 262:     if(make_new)
> 
> Suggestion:
> 
>     if (make_new)

Fixed.

> test/jdk/java/lang/StringBuffer/IndexOf.java line 295:
> 
>> 293:       }
>> 294: 
>> 295:       if(make_new) testIndex = getRandomIndex(-100, 100);
> 
> Suggestion:
> 
>       if (make_new) testIndex = getRandomIndex(-100, 100);

Fixed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1610093771
PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1610094790
PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1610097958

From jkratochvil at openjdk.org  Wed May 22 15:02:18 2024
From: jkratochvil at openjdk.org (Jan Kratochvil)
Date: Wed, 22 May 2024 15:02:18 GMT
Subject: RFR: 8322420: [Linux] cgroup v2: Limits in parent nested control
 groups are not detected [v11]
In-Reply-To: <c6DtrskKpUb_gpAtfqMTy3HLPdk0TiVZGfU5wcNl4Eo=.52b62a49-421b-4853-ba58-a878b4d312c6@github.com>
References: <c6DtrskKpUb_gpAtfqMTy3HLPdk0TiVZGfU5wcNl4Eo=.52b62a49-421b-4853-ba58-a878b4d312c6@github.com>
Message-ID: <ulK8y4gzGQO2lQ48R44-Z6mNu94p5LOx6Y0NLEnCfa8=.5f8693c8-e29b-410a-94d8-38d55e88e4a8@github.com>

> The testcase requires root permissions.
> 
> Designed by  Severin Gehwolf, implemented by Jan Kratochvil.

Jan Kratochvil has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 74 commits:

 - .
 - .
 - Merge branch 'jdk-8331560-cgroup-controller-delegation-merge-diamond' into jdk-8331560-cgroup-controller-delegation-merge-cgroup
 - diamond
 - Merge branch 'jerboaarefactor-merge-cgroup' into jdk-8331560-cgroup-controller-delegation-merge-cgroup
 - Merge branch 'jerboaarefactor-merge' into jerboaarefactor-merge-cgroup
 - Merge branch 'master' into jerboaarefactor-merge
 - whitespace fix
 - centos7 compat
 - 64a5feb6: <no commit message found>
 - ... and 64 more: https://git.openjdk.org/jdk/compare/3d511ff6...25c0287d

-------------

Changes: https://git.openjdk.org/jdk/pull/17198/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17198&range=10
  Stats: 2721 lines in 22 files changed: 1298 ins; 1081 del; 342 mod
  Patch: https://git.openjdk.org/jdk/pull/17198.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17198/head:pull/17198

PR: https://git.openjdk.org/jdk/pull/17198

From sgibbons at openjdk.org  Wed May 22 15:05:11 2024
From: sgibbons at openjdk.org (Scott Gibbons)
Date: Wed, 22 May 2024 15:05:11 GMT
Subject: RFR: 8320448: Accelerate IndexOf using AVX2 [v19]
In-Reply-To: <rKfqfzL6HnWnqLzEr2TXblb-e3p2k6UwdDVZppmaJ1A=.c23bc708-1211-49aa-9c57-6c2d14515334@github.com>
References: <uWi4QxH31hL93771gkl_GgvP0m84IRSoR_1Yi8hD17E=.bc6ed458-7081-4c3f-9348-f59358fa05a4@github.com>
 <eQ4OBFrF8JlDJ1h9awTDOc0kfCc37IlL5vdqtuaqls0=.8f00616d-08e1-4f28-a7a5-5095116d2595@github.com>
 <8Y-nIHc8vfB1X_hp3tpqqqgpCzu6dAt6BBIP_zc4Q70=.c9a48c68-8c14-4af9-8357-ab50e62a5fd3@github.com>
 <qqhUK6_L8rqutc-MtL_BzjZbBy88a-TDws9NuLIWC9g=.d97368e7-4b28-439d-959e-fee2ec13d2c9@github.com>
 <rKfqfzL6HnWnqLzEr2TXblb-e3p2k6UwdDVZppmaJ1A=.c23bc708-1211-49aa-9c57-6c2d14515334@github.com>
Message-ID: <JAyR9MRqxU5eB0AkNJs52i61BRHeDJHXTveyrjigp-Y=.3b3abb74-4cbe-4780-b6a6-5567c7e2838b@github.com>

On Fri, 17 May 2024 22:37:13 GMT, Sandhya Viswanathan <sviswanathan at openjdk.org> wrote:

>> Not sure what you mean here.  I *think* you mean that hsLength is not the length of the remaining bytes in the haystack, but the actual length.  There may be an issue if that is correct, right?  I'll investigate.
>
> Yes, that is what I meant. Thanks for investigating.

I've moved the code checking for (n-k)<32 to `big_case_loop_helper`, so there's no need for this in here any longer.  Removing unneeded parameters from `compare_big_haystack_to_needle`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1610166656

From rriggs at openjdk.org  Wed May 22 15:08:02 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 22 May 2024 15:08:02 GMT
Subject: RFR: 8332589: ubsan: unix/native/libjava/ProcessImpl_md.c:562:5:
 runtime error: null pointer passed as argument 2,
 which is declared to never be null
In-Reply-To: <AwlmAiTOhqSaoJ2Jh5YYrBpxakc0Pt9lYP9nvcBjXBo=.813efddf-3f87-4bbf-9cc5-cd769eabd2f7@github.com>
References: <AwlmAiTOhqSaoJ2Jh5YYrBpxakc0Pt9lYP9nvcBjXBo=.813efddf-3f87-4bbf-9cc5-cd769eabd2f7@github.com>
Message-ID: <P9IsUoPfJ-0Hj_WlOQO7Bb8KcnW_OA-InItTNn5vwKk=.57291e34-27a9-4c43-af69-90d3b77e412d@github.com>

On Tue, 21 May 2024 14:28:38 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> When building with ubsan enabled (--enable-uban) on Linux x86_64 and doing jtreg tests afterwards I run into this error :
> 
> /jdk/src/java.base/unix/native/libjava/ProcessImpl_md.c:562:5: runtime error: null pointer passed as argument 2, which is declared to never be null
>     #0 0x7fd95bec78d8 in spawnChild /jdk/src/java.base/unix/native/libjava/ProcessImpl_md.c:562
>     #1 0x7fd95bec78d8 in startChild /jdk/src/java.base/unix/native/libjava/ProcessImpl_md.c:612
>     #2 0x7fd95bec78d8 in Java_java_lang_ProcessImpl_forkAndExec /jdk/src/java.base/unix/native/libjava/ProcessImpl_md.c:712
>     #3 0x7fd93797a06d (<unknown module>)
> 
> this is the memcpy call getting an unexpected null pointer :
>     memcpy(buf+offset, c->pdir, sp.dirlen); gets a second parameter null.
> Something similar was discussed and fixed here https://bugs.python.org/issue27570 for Python .
> 
> Similar issue in OpenJDK _ 
> https://bugs.openjdk.org/browse/JDK-8332473
> 8332473: ubsan: growableArray.hpp:290:10: runtime error: null pointer passed as argument 1, which is declared to never be null

src/java.base/unix/native/libjava/ProcessImpl_md.c line 565:

> 563:         memcpy(buf+offset, c->pdir, sp.dirlen);
> 564:     }
> 565:     offset += sp.dirlen;

I'd be inclined to check sp.dirlen > 0 in the `if` and move the offset += inside too. Like:
Suggestion:

    if (sp.dirlen > 0 && c->pdir != NULL) {
        memcpy(buf+offset, c->pdir, sp.dirlen);
        offset += sp.dirlen;
    }

The behavior is correct either way.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19329#discussion_r1610170951

From yzheng at openjdk.org  Wed May 22 15:24:05 2024
From: yzheng at openjdk.org (Yudi Zheng)
Date: Wed, 22 May 2024 15:24:05 GMT
Subject: RFR: 8327964: Simplify BigInteger.implMultiplyToLen intrinsic [v6]
In-Reply-To: <GkTIvOKs4GDKUOPjaw893H4fAoeBDuzQn4kKnQqG2dA=.7762f50b-40b1-4763-940b-7e0c8a66d466@github.com>
References: <Z5U-3OSq9_rd0t6DHNRhjF3LHtc9b6orz-mcQ4Uqzl8=.c4f0a0b8-9e10-4505-82f7-7d3a82929d22@github.com>
 <GkTIvOKs4GDKUOPjaw893H4fAoeBDuzQn4kKnQqG2dA=.7762f50b-40b1-4763-940b-7e0c8a66d466@github.com>
Message-ID: <kmk2M1IY3NsveNzjBiuDQwrRpmiMxnH9yfnvav-NQCc=.db1ec736-a1d0-4f39-a47d-b457a3c15b57@github.com>

On Wed, 22 May 2024 14:47:43 GMT, Yudi Zheng <yzheng at openjdk.org> wrote:

>> Moving array construction within BigInteger.implMultiplyToLen intrinsic candidate to its caller simplifies the intrinsic implementation in JIT compiler.
>
> Yudi Zheng has updated the pull request incrementally with one additional commit since the last revision:
> 
>   address comments.

@theRealAph @TheRealMDoerr @RealFYang @offamitkumar could you please help review the aarch64/ppc/riscv/s390 changes?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18226#issuecomment-2125073511

From dl at openjdk.org  Wed May 22 15:32:42 2024
From: dl at openjdk.org (Doug Lea)
Date: Wed, 22 May 2024 15:32:42 GMT
Subject: RFR: 8322732: ForkJoinPool may underutilize cores in async mode
 [v3]
In-Reply-To: <xRyDMAsSZ7obqpr3Aoc5qrHqILeJMxFVCeiRdctMI3U=.d5d3cd56-32eb-4431-ac01-081822fc86c6@github.com>
References: <xRyDMAsSZ7obqpr3Aoc5qrHqILeJMxFVCeiRdctMI3U=.d5d3cd56-32eb-4431-ac01-081822fc86c6@github.com>
Message-ID: <NsHVtOWDMBDqRJ0plVTy1pG9x4E2O9-q2WzeV6U7p4Q=.dae1bcaf-4b00-403f-b260-3efb3b556cab@github.com>

> This set of changes address causes of poor utilization with small numbers of cores due to overly aggressive contention avoidance. A number of further adjustments were needed to still avoid most contention effects in deployments with large numbers of cores

Doug Lea 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 36 additional commits since the last revision:

 - Merge branch 'openjdk:master' into JDK-8322732
 - More performance tradoffs
 - Address review comments
 - Merge branch 'openjdk:master' into JDK-8322732
 - Repack some fields; adjust control flow
 - Merge branch 'openjdk:master' into JDK-8322732
 - Next version
 - Merge branch 'openjdk:master' into JDK-8322732
 - Reduce unneeded signals
 - Merge branch 'openjdk:master' into JDK-8322732
 - ... and 26 more: https://git.openjdk.org/jdk/compare/5072e63c...f1fc4f3e

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19131/files
  - new: https://git.openjdk.org/jdk/pull/19131/files/8689ac12..f1fc4f3e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19131&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19131&range=01-02

  Stats: 64729 lines in 1007 files changed: 46563 ins; 12655 del; 5511 mod
  Patch: https://git.openjdk.org/jdk/pull/19131.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19131/head:pull/19131

PR: https://git.openjdk.org/jdk/pull/19131

From vklang at openjdk.org  Wed May 22 15:50:13 2024
From: vklang at openjdk.org (Viktor Klang)
Date: Wed, 22 May 2024 15:50:13 GMT
Subject: RFR: 8322732: ForkJoinPool may underutilize cores in async mode
 [v3]
In-Reply-To: <NsHVtOWDMBDqRJ0plVTy1pG9x4E2O9-q2WzeV6U7p4Q=.dae1bcaf-4b00-403f-b260-3efb3b556cab@github.com>
References: <xRyDMAsSZ7obqpr3Aoc5qrHqILeJMxFVCeiRdctMI3U=.d5d3cd56-32eb-4431-ac01-081822fc86c6@github.com>
 <NsHVtOWDMBDqRJ0plVTy1pG9x4E2O9-q2WzeV6U7p4Q=.dae1bcaf-4b00-403f-b260-3efb3b556cab@github.com>
Message-ID: <XtXQ5VAlOygdqWp0GJB9eMzbggl3v2AJijdOj7-pI3I=.44c78ae5-85fb-4adc-abce-77c2576f4ab4@github.com>

On Wed, 22 May 2024 15:32:42 GMT, Doug Lea <dl at openjdk.org> wrote:

>> This set of changes address causes of poor utilization with small numbers of cores due to overly aggressive contention avoidance. A number of further adjustments were needed to still avoid most contention effects in deployments with large numbers of cores
>
> Doug Lea 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 36 additional commits since the last revision:
> 
>  - Merge branch 'openjdk:master' into JDK-8322732
>  - More performance tradoffs
>  - Address review comments
>  - Merge branch 'openjdk:master' into JDK-8322732
>  - Repack some fields; adjust control flow
>  - Merge branch 'openjdk:master' into JDK-8322732
>  - Next version
>  - Merge branch 'openjdk:master' into JDK-8322732
>  - Reduce unneeded signals
>  - Merge branch 'openjdk:master' into JDK-8322732
>  - ... and 26 more: https://git.openjdk.org/jdk/compare/72365ee9...f1fc4f3e

src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 586:

> 584:      * term. We use Marsaglia XorShifts, seeded with the Weyl sequence
> 585:      * from ThreadLocalRandom probes, which are cheap and
> 586:      * suffice. Each queue's polling attempt o avoid becoming stuck

Suggestion:

     * suffice. Each queue's polling attempt to avoid becoming stuck

src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 597:

> 595:      * async mode.
> 596:      *
> 597:      * Deactivation. When no tasks are found by a worker in runWorker,

Suggestion:

     * Deactivation: When no tasks are found by a worker in runWorker,

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19131#discussion_r1610235852
PR Review Comment: https://git.openjdk.org/jdk/pull/19131#discussion_r1610239940

From vklang at openjdk.org  Wed May 22 15:53:10 2024
From: vklang at openjdk.org (Viktor Klang)
Date: Wed, 22 May 2024 15:53:10 GMT
Subject: RFR: 8322732: ForkJoinPool may underutilize cores in async mode
 [v3]
In-Reply-To: <NsHVtOWDMBDqRJ0plVTy1pG9x4E2O9-q2WzeV6U7p4Q=.dae1bcaf-4b00-403f-b260-3efb3b556cab@github.com>
References: <xRyDMAsSZ7obqpr3Aoc5qrHqILeJMxFVCeiRdctMI3U=.d5d3cd56-32eb-4431-ac01-081822fc86c6@github.com>
 <NsHVtOWDMBDqRJ0plVTy1pG9x4E2O9-q2WzeV6U7p4Q=.dae1bcaf-4b00-403f-b260-3efb3b556cab@github.com>
Message-ID: <hAZF--4zVOz2utGMo4UiCDoPiRFRyqAXFfUYn_Qiks8=.2554dbcb-63b9-4897-bdb8-57a78828689e@github.com>

On Wed, 22 May 2024 15:32:42 GMT, Doug Lea <dl at openjdk.org> wrote:

>> This set of changes address causes of poor utilization with small numbers of cores due to overly aggressive contention avoidance. A number of further adjustments were needed to still avoid most contention effects in deployments with large numbers of cores
>
> Doug Lea 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 36 additional commits since the last revision:
> 
>  - Merge branch 'openjdk:master' into JDK-8322732
>  - More performance tradoffs
>  - Address review comments
>  - Merge branch 'openjdk:master' into JDK-8322732
>  - Repack some fields; adjust control flow
>  - Merge branch 'openjdk:master' into JDK-8322732
>  - Next version
>  - Merge branch 'openjdk:master' into JDK-8322732
>  - Reduce unneeded signals
>  - Merge branch 'openjdk:master' into JDK-8322732
>  - ... and 26 more: https://git.openjdk.org/jdk/compare/d5552864...f1fc4f3e

src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 1440:

> 1438:             while (task != null) {
> 1439:                 task.doExec();
> 1440:                 task = nextLocalTask(fifo);

Clean! ?

src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 1884:

> 1882:             else
> 1883:                 nc = (v.stackPred & LMASK) | (c & TC_MASK);
> 1884:             if (c == (c = compareAndExchangeCtl(c, nc | ac))) {

So the TTAS wasn't worth it on some architectures? ?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19131#discussion_r1610244875
PR Review Comment: https://git.openjdk.org/jdk/pull/19131#discussion_r1610245643

From philip.race at oracle.com  Wed May 22 15:54:19 2024
From: philip.race at oracle.com (Philip Race)
Date: Wed, 22 May 2024 08:54:19 -0700
Subject: stack overflow in regex engine
In-Reply-To: <CH3PR12MB76197D4ECC54728844CE705CF9EB2@CH3PR12MB7619.namprd12.prod.outlook.com>
References: <CH3PR12MB76197D4ECC54728844CE705CF9EB2@CH3PR12MB7619.namprd12.prod.outlook.com>
Message-ID: <5b8019db-c9ac-4e4a-9452-20e477c5ec5e@oracle.com>

P4 is the default JBS priority, so sometimes it just means no one 
figured out the true priority.
But in general P4 bugs could be open for years, or even never get fixed.
The priority is also partially an assessment of where it falls as a 
priority for the JDK developers.
A user of JDK may have an entirely different perspective.
And that's why there are vendors who provide support for JDK. They can 
also arrange the backports you need.
But that's not done here. Here is where you come to participate and 
contribute fixes, not ask for fixes.
So my suggestion is to raise it via your support channel to your 
particular vendor who provided your binary.

-phil


On 5/21/24 8:46 PM, mark.yagnatinsky at barclays.com wrote:
>
> (Sorry about my previous ?do I need to subscribe?? email; in 
> retrospect that was needless noise.)
>
> The purpose of this email is twofold: first, inquire about the status 
> of ticket filed a few years ago, and second to point out some 
> non-obvious reasons why it might be slightly more serious than it seems.
>
> The ticket is this one https://bugs.openjdk.org/browse/JDK-8260866 
> (stack overflow in regex matching quantified alternation)
>
> The priority is listed as P4, which I guess means something like 
> ?medium? (more important than p5, but less than p3)
>
> It also has a specific person assigned, which seems vaguely 
> encouraging, but no updates at all in the years since it?s been 
> created, which seems less encouraging.
>
> It was seemingly never once discussed on this mailing list, not even 
> when it was first filed.
>
> As an outsider, I?m not quite sure how to interpret all these various 
> omens and turn them into guesses about its eventual fate.
>
> Will it remain unfixed for another decade or two?? Will it be fixed in 
> a few months, but then never backported to old versions?? Something 
> else?? No one knows?
>
> That concludes the status inquiry.? Now on to the advocacy.? Some bugs 
> are annoying, but once you hit them, you can work around them by 
> changing your code so it does not trigger the bug.
>
> Note the phrase ?your code? above.? This is much more awkward to do if 
> the bug triggered by third-party code you got from maven central or 
> something.
>
> At that point your options are to either ask the third party library 
> to work around it, or else fork the dependency (which is not well 
> supported by mainstream build tools (or maybe I?m just using them wrong)).
>
> In this case, regular expressions are so ubiquitous that the bug is 
> quite plausibly more likely to be triggered by some third party 
> dependency than by code you own.
>
> That was the case for me today: after spending hours trying to track 
> down a stack overflow error I found the offending regex in a third 
> party library.
>
> The good news is that for the kinds of inputs we need to handle, it is 
> indeed easy to substitute a much simpler regex that would avoid the issue.
>
> The bad news is that it?s not my code, so I can?t.? I could petition 
> the maintainers of the library, but this is not great because:
>
> First, maybe the version I?m on is not longer even supported, and 
> newer versions are not compatible,
>
> Second, it may take them a while to fix it, and third, it is wasteful 
> (and inelegant) to have workarounds slowly percolate throughout the 
> Java ecosystem instead of fixing the problem at the root.
>
> The other annoying thing here is that even when you have ?enough? 
> stack space to avoid crashing, using it may not be quite ?free?.
>
> For instance, project loom?s foundational premise seems to be that 
> ?most threads have oversized stacks; we can have more threads if we 
> start off with small stacks and grow them only when needed?.
>
> This would be false when the thread in question uses a regex with 
> quantified alternation.
>
> (Since many Loom threads will be based on the same Runnable, it?s a 
> pretty safe bet that if one of them uses this feature, many will, so 
> you can?t assume it will ?average out?.)
>
> There are other reasons besides loom to be low on stack space; maybe 
> you?re using some crazy framework(s) that like(s) to have call stacks 
> that are crazy deep.
>
> Or maybe you?re running with -Xss set pretty low.? Or you passed a 
> small value for stack space to the Thread constructor.
>
> Or maybe none of these things are true, but in most operating systems 
> a thread stack costs ?real? memory in proportion to its 
> high-watermark, so even a SINGLE heavy regex in the lifetime of a 
> thread is tantamount to a memory leak of hundreds of kilobytes.
>
> Practicalities aside, I don?t like it when code consumes ?surprising? 
> types of resources, or surprising amounts of them.
>
> For instance, you wouldn?t expect a sorting function to spawn threads 
> behind your back, unless it was called ?parallel sort? or something 
> like that.
>
> You wouldn?t expect it to allocate multi-gigabyte arrays, nor to 
> perform I/O.
>
> Similarly, most functions need only O(1) stack space, so this tends to 
> be the default assumption unless the docs explicitly call out ?this 
> thing might throw stack overflows at you so make sure you have plenty 
> of stack space?
>
> Some need a bit more? for instance, I would not be surprised if a 
> regex need stack space in proportion to the depth of the parse tree of 
> the regex.
>
> But stack space in proportion to the length of the string being 
> matched is the kind of thing that I?d hope gets called out in those 
> @implNotes thingies, or better yet fixed.
>
> Even people who know that regex matching can sometimes take 
> exponential time may naively assume that regex matching would not 
> consume O(n) stack space, where n is the input length.
>
> What?s worse, not only does it indeed consume stack space linear in 
> the length of the input, but the constant hidden by the O() notation 
> is itself pretty scary.
>
> For instance, consider the regex that caused my troubles today:
>
> https://github.com/apache/camel/blob/main/core/camel-support/src/main/java/org/apache/camel/support/ObjectHelper.java#L63
>
> After getting rid of extra escaping and also double-escaping caused by 
> java not having ?raw? strings, we?re left with this:
>
> ,(?!(?:[^(,]|[^)],[^)])+\))
>
> (I find the above hard to read; the regex I would have replaced it 
> with, if it had been ?our? code is simply a single comma.)
>
> Anyway, I tried creating a Scanner with the delimiter above and 
> looping through all the tokens in the string that originally caused 
> the crash.
>
> I thought that perhaps it would work, since I had a simple example 
> that does everything in main, but it also crashed.
>
> Then I decided to play an alternating game where I trimmed the string 
> until it stopped crashing, then lowered Xss by 64k and repeated.
>
> Eventually, I got it crashing with a call stack well over 500 calls 
> deep on a string less than a 128 characters long.
>
> (The string was not hand-crafted; it was simply a prefix of the 
> original string that caused the first crash I tracked down.)
>
> The string in question had a mere five tokens, which is to say that it 
> had just four commas.
>
> It had no open or close parenthesis, so the entire negative lookahead 
> assertion served as a giant no-op, at least when it wasn?t crashing.
>
> (Technically, the stack usage is linear in the length of the input 
> AFTER the first comma, but the first comma was pretty early.)
>
> Sorry if this email is poorly organized; I?ve already spent way too 
> many hours on it (not even counting the debugging that prompted it) 
> and I need to get some sleep now.
>
> If anyone actually reads all or most of this, thank you.
>
> Mark.
>
> P.S. if anyone actually responds, thank you even more.
>
> This message is for information purposes only. It is not a 
> recommendation, advice, offer or solicitation to buy or sell a product 
> or service, nor an official confirmation of any transaction. It is 
> directed at persons who are professionals and is intended for the 
> recipient(s) only. It is not directed at retail customers. This 
> message is subject to the terms at: 
> https://www.ib.barclays/disclosures/web-and-email-disclaimer.html.
>
> For important disclosures, please see: 
> https://www.ib.barclays/disclosures/sales-and-trading-disclaimer.html 
> regarding marketing commentary from Barclays Sales and/or Trading 
> desks, who are active market participants; 
> https://www.ib.barclays/disclosures/barclays-global-markets-disclosures.html 
> regarding our standard terms for Barclays Investment Bank where we 
> trade with you in principal-to-principal wholesale markets 
> transactions; and in respect to Barclays Research, including 
> disclosures relating to specific issuers, see: 
> http://publicresearch.barclays.com.
> __________________________________________________________________________________ 
>
> If you are incorporated or operating in Australia, read these 
> important disclosures: 
> https://www.ib.barclays/disclosures/important-disclosures-asia-pacific.html.
> __________________________________________________________________________________
> For more details about how we use personal information, see our 
> privacy notice: 
> https://www.ib.barclays/disclosures/personal-information-use.html.
> __________________________________________________________________________________
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240522/c0418bcf/attachment-0001.htm>

From prappo at openjdk.org  Wed May 22 15:55:04 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Wed, 22 May 2024 15:55:04 GMT
Subject: RFR: 8332084: Ensure JdkConsoleImpl.restoreEcho visibility in a
 shutdown hook [v8]
In-Reply-To: <s5UWj1VnzkiOOPZk8YMuJrbyAoMx-pVeV14Cx5UDZeE=.495ed70f-3dd5-4c4d-a616-0f20fcb92907@github.com>
References: <9JTWc3FRpfbILlSHlmIU_dL5IE69RTxnSIAOdIte15I=.5854a48f-21d7-42c9-adb7-5e3ed40d1211@github.com>
 <s5UWj1VnzkiOOPZk8YMuJrbyAoMx-pVeV14Cx5UDZeE=.495ed70f-3dd5-4c4d-a616-0f20fcb92907@github.com>
Message-ID: <H1uJUNGP8po9lZMucoOnkG2EaJhig3GcjZVewr99WyM=.b4ba43b9-7a80-4e2f-a2a4-ff0d828c7d32@github.com>

On Tue, 21 May 2024 22:51:14 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Making sure `restoreEcho` correctly reflects the state in the shutdown thread, which differs from the application's thread that issues the `readPassword()` method.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Used a dedicate lock for restoreEcho

I looked at the most recent commit, https://github.com/openjdk/jdk/pull/19184/commits/f69f747a8669647d6f924369fd98b945f9d0ae63.

You are right, the [race][] that we hypothesised previously when `restoreEcho` was `volatile` is no longer present. However, there's another race. If it's of any consolation, that new race isn't new at all: it was there before. (I know it's frustrating to be discussing the same problem over and over again, but we're making progress.)

What we want to do is restore the echo state immediately before JVM exits. We achieve this by installing a shutdown hook which restores the state. However, there's no coordination between the shutdown hook and any thread that also modifies the state.

If I read [this][shutdown-sequence] correctly, due to the mechanics of JVM exit, we simply don't know which thread finishes first: a thread that calls `readPassword` or the shutdown hook. If the shutdown hook finishes first, then a `readPassword` thread can corrupt the state: unlike the shutdown hook, which JVM _normally has to wait to complete_, the `readPassword` thread can be terminated at any moment. It might as well be terminated before `finally` but after `echo(false)`, in which case we end up with echo turned off.

What I'm saying is that we should ensure that the shutdown hook has the final say: once completed, no one should modify echo status. I understand that this means more involved communication between threads.

Does it make sense?

[shutdown-sequence]: https://docs.oracle.com/en/java/javase/22/docs/api/java.base/java/lang/Runtime.html#shutdown
[race]: https://github.com/openjdk/jdk/pull/19184#issuecomment-2109779741

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19184#issuecomment-2125137216

From vklang at openjdk.org  Wed May 22 15:59:07 2024
From: vklang at openjdk.org (Viktor Klang)
Date: Wed, 22 May 2024 15:59:07 GMT
Subject: RFR: 8322732: ForkJoinPool may underutilize cores in async mode
 [v3]
In-Reply-To: <NsHVtOWDMBDqRJ0plVTy1pG9x4E2O9-q2WzeV6U7p4Q=.dae1bcaf-4b00-403f-b260-3efb3b556cab@github.com>
References: <xRyDMAsSZ7obqpr3Aoc5qrHqILeJMxFVCeiRdctMI3U=.d5d3cd56-32eb-4431-ac01-081822fc86c6@github.com>
 <NsHVtOWDMBDqRJ0plVTy1pG9x4E2O9-q2WzeV6U7p4Q=.dae1bcaf-4b00-403f-b260-3efb3b556cab@github.com>
Message-ID: <UarhD4AmkH8uj1ZfNJUaulW6bemft22wrkGZgAXk_4I=.0b2beda5-4b95-46eb-8dbd-29e79f4b0b05@github.com>

On Wed, 22 May 2024 15:32:42 GMT, Doug Lea <dl at openjdk.org> wrote:

>> This set of changes address causes of poor utilization with small numbers of cores due to overly aggressive contention avoidance. A number of further adjustments were needed to still avoid most contention effects in deployments with large numbers of cores
>
> Doug Lea 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 36 additional commits since the last revision:
> 
>  - Merge branch 'openjdk:master' into JDK-8322732
>  - More performance tradoffs
>  - Address review comments
>  - Merge branch 'openjdk:master' into JDK-8322732
>  - Repack some fields; adjust control flow
>  - Merge branch 'openjdk:master' into JDK-8322732
>  - Next version
>  - Merge branch 'openjdk:master' into JDK-8322732
>  - Reduce unneeded signals
>  - Merge branch 'openjdk:master' into JDK-8322732
>  - ... and 26 more: https://git.openjdk.org/jdk/compare/bdb1c0d3...f1fc4f3e

src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 2053:

> 2051:                 WorkQueue[] qs;
> 2052:                 int spins = ((short)(qc >>> TC_SHIFT) << 1) + SPIN_WAITS + 1;
> 2053:                 while (((p = w.phase) & IDLE) != 0 && --spins > 0)

Nice catch on the spins :)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19131#discussion_r1610252517

From sgibbons at openjdk.org  Wed May 22 16:25:24 2024
From: sgibbons at openjdk.org (Scott Gibbons)
Date: Wed, 22 May 2024 16:25:24 GMT
Subject: RFR: 8320448: Accelerate IndexOf using AVX2 [v22]
In-Reply-To: <uWi4QxH31hL93771gkl_GgvP0m84IRSoR_1Yi8hD17E=.bc6ed458-7081-4c3f-9348-f59358fa05a4@github.com>
References: <uWi4QxH31hL93771gkl_GgvP0m84IRSoR_1Yi8hD17E=.bc6ed458-7081-4c3f-9348-f59358fa05a4@github.com>
Message-ID: <d_l0V1WOw_Fyou5H924ry3FoeFksYscUVHNShs0rqjM=.f26751e3-8807-4f9b-ba39-7db7f44284c4@github.com>

> Re-write the IndexOf code without the use of the pcmpestri instruction, only using AVX2 instructions.  This change accelerates String.IndexOf on average 1.3x for AVX2.  The benchmark numbers:
> 
> 
> Benchmark	                                               Score		Latest		
> StringIndexOf.advancedWithMediumSub   343.573		317.934		0.925375393x
> StringIndexOf.advancedWithShortSub1	  1039.081		1053.96		1.014319384x
> StringIndexOf.advancedWithShortSub2	      55.828		110.541		1.980027943x
> StringIndexOf.constantPattern	                9.361		11.906		1.271872663x
> StringIndexOf.searchCharLongSuccess	        4.216		4.218		1.000474383x
> StringIndexOf.searchCharMediumSuccess	3.133		3.216		1.02649218x
> StringIndexOf.searchCharShortSuccess	3.76		        3.761		1.000265957x
> StringIndexOf.success	                                9.186		9.713		1.057369911x
> StringIndexOf.successBig	                      14.341		46.343		3.231504079x
> StringIndexOfChar.latin1_AVX2_String	  6220.918		12154.52		1.953814533x
> StringIndexOfChar.latin1_AVX2_char	  5503.556		5540.044		1.006629895x
> StringIndexOfChar.latin1_SSE4_String	  6978.854		6818.689		0.977049957x
> StringIndexOfChar.latin1_SSE4_char	  5657.499		5474.624		0.967675646x
> StringIndexOfChar.latin1_Short_String	  7132.541		6863.359		0.962260014x
> StringIndexOfChar.latin1_Short_char	16013.389	      16162.437		1.009307711x
> StringIndexOfChar.latin1_mixed_String	  7386.123	      14771.622		1.999915517x
> StringIndexOfChar.latin1_mixed_char	  9901.671		9782.245		0.987938803

Scott Gibbons has updated the pull request incrementally with one additional commit since the last revision:

  Added comments; move n-k<32 code up a level

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/16753/files
  - new: https://git.openjdk.org/jdk/pull/16753/files/38868a35..f4ca4a5e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16753&range=21
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16753&range=20-21

  Stats: 214 lines in 4 files changed: 100 ins; 72 del; 42 mod
  Patch: https://git.openjdk.org/jdk/pull/16753.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16753/head:pull/16753

PR: https://git.openjdk.org/jdk/pull/16753

From duke at openjdk.org  Wed May 22 16:30:14 2024
From: duke at openjdk.org (Volodymyr Paprotski)
Date: Wed, 22 May 2024 16:30:14 GMT
Subject: Integrated: 8329538: Accelerate P256 on x86_64 using Montgomery
 intrinsic
In-Reply-To: <hanRK4GzOkFV8kG1gZRy8Br53trw4-Tu6G6uO8nsFuk=.d5bf723a-f683-4759-ac9e-4a58cb430f03@github.com>
References: <hanRK4GzOkFV8kG1gZRy8Br53trw4-Tu6G6uO8nsFuk=.d5bf723a-f683-4759-ac9e-4a58cb430f03@github.com>
Message-ID: <zas-6CozbjZN3BI3nzFMnA8iCJhXE9jqm1qkOtWrSMs=.5795f5e9-4d6e-4f0e-8239-28a28647808c@github.com>

On Tue, 2 Apr 2024 15:42:05 GMT, Volodymyr Paprotski <duke at openjdk.org> wrote:

> Performance. Before:
> 
> Benchmark                        (algorithm)  (dataSize)  (keyLength)  (provider)   Mode  Cnt     Score    Error  Units
> SignatureBench.ECDSA.sign    SHA256withECDSA        1024          256              thrpt    3  6443.934 ?  6.491  ops/s
> SignatureBench.ECDSA.sign    SHA256withECDSA       16384          256              thrpt    3  6152.979 ?  4.954  ops/s
> SignatureBench.ECDSA.verify  SHA256withECDSA        1024          256              thrpt    3  1895.410 ? 36.979  ops/s
> SignatureBench.ECDSA.verify  SHA256withECDSA       16384          256              thrpt    3  1878.955 ? 45.487  ops/s
> Benchmark                                            (algorithm)  (keyLength)  (kpgAlgorithm)  (provider)   Mode  Cnt     Score    Error  Units
> o.o.b.j.c.full.KeyAgreementBench.EC.generateSecret          ECDH          256              EC              thrpt    3  1357.810 ? 26.584  ops/s
> o.o.b.j.c.small.KeyAgreementBench.EC.generateSecret         ECDH          256              EC              thrpt    3  1352.119 ? 23.547  ops/s
> Benchmark                          (isMontBench)   Mode  Cnt     Score    Error  Units
> PolynomialP256Bench.benchMultiply          false  thrpt    3  1746.126 ? 10.970  ops/s
> 
> Performance, no intrinsic:
> 
> Benchmark                        (algorithm)  (dataSize)  (keyLength)  (provider)   Mode  Cnt     Score     Error  Units
> SignatureBench.ECDSA.sign    SHA256withECDSA        1024          256              thrpt    3  6529.839 ?  42.420  ops/s
> SignatureBench.ECDSA.sign    SHA256withECDSA       16384          256              thrpt    3  6199.747 ? 133.566  ops/s
> SignatureBench.ECDSA.verify  SHA256withECDSA        1024          256              thrpt    3  1973.676 ?  54.071  ops/s
> SignatureBench.ECDSA.verify  SHA256withECDSA       16384          256              thrpt    3  1932.127 ?  35.920  ops/s
> Benchmark                                            (algorithm)  (keyLength)  (kpgAlgorithm)  (provider)   Mode  Cnt     Score    Error  Units
> o.o.b.j.c.full.KeyAgreementBench.EC.generateSecret          ECDH          256              EC              thrpt    3  1355.788 ? 29.858  ops/s
> o.o.b.j.c.small.KeyAgreementBench.EC.generateSecret         ECDH          256              EC              thrpt    3  1346.523 ? 28.722  ops/s
> Benchmark                          (isMontBench)   Mode  Cnt     Score    Error  Units
> PolynomialP256Bench.benchMultiply           true  thrpt    3  1919.574 ? 10.591  ops/s
> 
> Performance, **with intrinsics*...

This pull request has now been integrated.

Changeset: afed7d0b
Author:    Volodymyr Paprotski <volodymyr.paprotski at intel.com>
Committer: Sandhya Viswanathan <sviswanathan at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/afed7d0b0593864e5595840a6b645c210ff28c7c
Stats:     2409 lines in 36 files changed: 2093 ins; 156 del; 160 mod

8329538: Accelerate P256 on x86_64 using Montgomery intrinsic

Reviewed-by: ihse, ascarpino, sviswanathan

-------------

PR: https://git.openjdk.org/jdk/pull/18583

From sgibbons at openjdk.org  Wed May 22 16:36:41 2024
From: sgibbons at openjdk.org (Scott Gibbons)
Date: Wed, 22 May 2024 16:36:41 GMT
Subject: RFR: 8320448: Accelerate IndexOf using AVX2 [v23]
In-Reply-To: <uWi4QxH31hL93771gkl_GgvP0m84IRSoR_1Yi8hD17E=.bc6ed458-7081-4c3f-9348-f59358fa05a4@github.com>
References: <uWi4QxH31hL93771gkl_GgvP0m84IRSoR_1Yi8hD17E=.bc6ed458-7081-4c3f-9348-f59358fa05a4@github.com>
Message-ID: <UYXAyEvp--Xnz9eze9JAiN_6qEWcUdEh9HyNobG_6fg=.e111764d-8e34-4736-a201-eeab7249a3f7@github.com>

> Re-write the IndexOf code without the use of the pcmpestri instruction, only using AVX2 instructions.  This change accelerates String.IndexOf on average 1.3x for AVX2.  The benchmark numbers:
> 
> 
> Benchmark	                                               Score		Latest		
> StringIndexOf.advancedWithMediumSub   343.573		317.934		0.925375393x
> StringIndexOf.advancedWithShortSub1	  1039.081		1053.96		1.014319384x
> StringIndexOf.advancedWithShortSub2	      55.828		110.541		1.980027943x
> StringIndexOf.constantPattern	                9.361		11.906		1.271872663x
> StringIndexOf.searchCharLongSuccess	        4.216		4.218		1.000474383x
> StringIndexOf.searchCharMediumSuccess	3.133		3.216		1.02649218x
> StringIndexOf.searchCharShortSuccess	3.76		        3.761		1.000265957x
> StringIndexOf.success	                                9.186		9.713		1.057369911x
> StringIndexOf.successBig	                      14.341		46.343		3.231504079x
> StringIndexOfChar.latin1_AVX2_String	  6220.918		12154.52		1.953814533x
> StringIndexOfChar.latin1_AVX2_char	  5503.556		5540.044		1.006629895x
> StringIndexOfChar.latin1_SSE4_String	  6978.854		6818.689		0.977049957x
> StringIndexOfChar.latin1_SSE4_char	  5657.499		5474.624		0.967675646x
> StringIndexOfChar.latin1_Short_String	  7132.541		6863.359		0.962260014x
> StringIndexOfChar.latin1_Short_char	16013.389	      16162.437		1.009307711x
> StringIndexOfChar.latin1_mixed_String	  7386.123	      14771.622		1.999915517x
> StringIndexOfChar.latin1_mixed_char	  9901.671		9782.245		0.987938803

Scott Gibbons has updated the pull request incrementally with one additional commit since the last revision:

  Adding exhaustive test

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/16753/files
  - new: https://git.openjdk.org/jdk/pull/16753/files/f4ca4a5e..b6d77fe0

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16753&range=22
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16753&range=21-22

  Stats: 249 lines in 1 file changed: 249 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/16753.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16753/head:pull/16753

PR: https://git.openjdk.org/jdk/pull/16753

From sgibbons at openjdk.org  Wed May 22 16:39:11 2024
From: sgibbons at openjdk.org (Scott Gibbons)
Date: Wed, 22 May 2024 16:39:11 GMT
Subject: RFR: 8320448: Accelerate IndexOf using AVX2 [v22]
In-Reply-To: <d_l0V1WOw_Fyou5H924ry3FoeFksYscUVHNShs0rqjM=.f26751e3-8807-4f9b-ba39-7db7f44284c4@github.com>
References: <uWi4QxH31hL93771gkl_GgvP0m84IRSoR_1Yi8hD17E=.bc6ed458-7081-4c3f-9348-f59358fa05a4@github.com>
 <d_l0V1WOw_Fyou5H924ry3FoeFksYscUVHNShs0rqjM=.f26751e3-8807-4f9b-ba39-7db7f44284c4@github.com>
Message-ID: <EmxiowL648CA8ouH1uBpNgFF0YGs6M6Fivvnm14M5p8=.1c64466f-fb63-4621-930b-91d93b98bb8d@github.com>

On Wed, 22 May 2024 16:25:24 GMT, Scott Gibbons <sgibbons at openjdk.org> wrote:

>> Re-write the IndexOf code without the use of the pcmpestri instruction, only using AVX2 instructions.  This change accelerates String.IndexOf on average 1.3x for AVX2.  The benchmark numbers:
>> 
>> 
>> Benchmark	                                               Score		Latest		
>> StringIndexOf.advancedWithMediumSub   343.573		317.934		0.925375393x
>> StringIndexOf.advancedWithShortSub1	  1039.081		1053.96		1.014319384x
>> StringIndexOf.advancedWithShortSub2	      55.828		110.541		1.980027943x
>> StringIndexOf.constantPattern	                9.361		11.906		1.271872663x
>> StringIndexOf.searchCharLongSuccess	        4.216		4.218		1.000474383x
>> StringIndexOf.searchCharMediumSuccess	3.133		3.216		1.02649218x
>> StringIndexOf.searchCharShortSuccess	3.76		        3.761		1.000265957x
>> StringIndexOf.success	                                9.186		9.713		1.057369911x
>> StringIndexOf.successBig	                      14.341		46.343		3.231504079x
>> StringIndexOfChar.latin1_AVX2_String	  6220.918		12154.52		1.953814533x
>> StringIndexOfChar.latin1_AVX2_char	  5503.556		5540.044		1.006629895x
>> StringIndexOfChar.latin1_SSE4_String	  6978.854		6818.689		0.977049957x
>> StringIndexOfChar.latin1_SSE4_char	  5657.499		5474.624		0.967675646x
>> StringIndexOfChar.latin1_Short_String	  7132.541		6863.359		0.962260014x
>> StringIndexOfChar.latin1_Short_char	16013.389	      16162.437		1.009307711x
>> StringIndexOfChar.latin1_mixed_String	  7386.123	      14771.622		1.999915517x
>> StringIndexOfChar.latin1_mixed_char	  9901.671		9782.245		0.987938803
>
> Scott Gibbons has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Added comments; move n-k<32 code up a level

By her request

-------------

PR Comment: https://git.openjdk.org/jdk/pull/16753#issuecomment-2125255793

From iklam at openjdk.org  Wed May 22 16:49:36 2024
From: iklam at openjdk.org (Ioi Lam)
Date: Wed, 22 May 2024 16:49:36 GMT
Subject: RFR: 8332340: Add JavacBench as a test case for CDS [v4]
In-Reply-To: <xqD4PeVZfIAKzywbLnjGZMFh36YSqXNolZkTgh1Vk6E=.44db7c57-64c1-4912-96e1-e61848312ccb@github.com>
References: <xqD4PeVZfIAKzywbLnjGZMFh36YSqXNolZkTgh1Vk6E=.44db7c57-64c1-4912-96e1-e61848312ccb@github.com>
Message-ID: <PgyOx-jq4-m7gJqgEUjDF_c2JFhFixTtypJWov6r1VA=.1fe4f700-a7f6-4bc6-8e44-41e95cfe9a7b@github.com>

> JavacBench is a test program that compiles 90 Java source files. It uses a fair amount of invokedynamic callsites, so it's good for testing CDS support for indy and lambda expressions.
> 
> This test was first integrated into the [leyden](https://github.com/openjdk/leyden/tree/premain) repo. Hence some of the files have copyrights in 2023.

Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:

  @matias9927 comments

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19256/files
  - new: https://git.openjdk.org/jdk/pull/19256/files/ad97efa1..be84efcc

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19256&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19256&range=02-03

  Stats: 108 lines in 1 file changed: 43 ins; 36 del; 29 mod
  Patch: https://git.openjdk.org/jdk/pull/19256.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19256/head:pull/19256

PR: https://git.openjdk.org/jdk/pull/19256

From iklam at openjdk.org  Wed May 22 16:49:36 2024
From: iklam at openjdk.org (Ioi Lam)
Date: Wed, 22 May 2024 16:49:36 GMT
Subject: RFR: 8332340: Add JavacBench as a test case for CDS [v3]
In-Reply-To: <9-7g3_XzveiMKyADlDCbZKOAH1m4cx6v3Qdz1Ob-XgY=.8aef78ae-af2b-460a-9edb-dc06318547a9@github.com>
References: <xqD4PeVZfIAKzywbLnjGZMFh36YSqXNolZkTgh1Vk6E=.44db7c57-64c1-4912-96e1-e61848312ccb@github.com>
 <JyXZjtHrBwxBbYTgyKfne732jbC7gCNzwgPDKWHAxAQ=.3b8e48bb-3bfa-4b85-88d4-65cee20a5cec@github.com>
 <9-7g3_XzveiMKyADlDCbZKOAH1m4cx6v3Qdz1Ob-XgY=.8aef78ae-af2b-460a-9edb-dc06318547a9@github.com>
Message-ID: <HTGHmqQDomJMiw1wRL-KwhiwPeb9eAHnLzo_AS9Fbxc=.7fd61aaf-74bd-4e1e-bb34-d725b7c0d2f4@github.com>

On Tue, 21 May 2024 21:03:20 GMT, Matias Saavedra Silva <matsaave at openjdk.org> wrote:

>> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   @calvinccheung comments
>
> test/lib/jdk/test/lib/cds/CDSAppTester.java line 147:
> 
>> 145:     }
>> 146: 
>> 147:     private OutputAnalyzer dumpStaticArchive() throws Exception {
> 
> The code from 156 to 162 is repeated 3 times here, is it worth making another function for this?

Thanks for the suggestion. I've refactored the code a bit to make it easier to write new execution modes (which will be needed in Leyden).

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19256#discussion_r1610325214

From sgibbons at openjdk.org  Wed May 22 16:54:26 2024
From: sgibbons at openjdk.org (Scott Gibbons)
Date: Wed, 22 May 2024 16:54:26 GMT
Subject: RFR: 8320448: Accelerate IndexOf using AVX2 [v24]
In-Reply-To: <uWi4QxH31hL93771gkl_GgvP0m84IRSoR_1Yi8hD17E=.bc6ed458-7081-4c3f-9348-f59358fa05a4@github.com>
References: <uWi4QxH31hL93771gkl_GgvP0m84IRSoR_1Yi8hD17E=.bc6ed458-7081-4c3f-9348-f59358fa05a4@github.com>
Message-ID: <cPrfQ8BDiaZZGUuUudFHlI37eoewMiWw7dsQdfa7Mgg=.5e4f3d4b-71da-413d-8777-fb046ffe49ea@github.com>

> Re-write the IndexOf code without the use of the pcmpestri instruction, only using AVX2 instructions.  This change accelerates String.IndexOf on average 1.3x for AVX2.  The benchmark numbers:
> 
> 
> Benchmark	                                               Score		Latest		
> StringIndexOf.advancedWithMediumSub   343.573		317.934		0.925375393x
> StringIndexOf.advancedWithShortSub1	  1039.081		1053.96		1.014319384x
> StringIndexOf.advancedWithShortSub2	      55.828		110.541		1.980027943x
> StringIndexOf.constantPattern	                9.361		11.906		1.271872663x
> StringIndexOf.searchCharLongSuccess	        4.216		4.218		1.000474383x
> StringIndexOf.searchCharMediumSuccess	3.133		3.216		1.02649218x
> StringIndexOf.searchCharShortSuccess	3.76		        3.761		1.000265957x
> StringIndexOf.success	                                9.186		9.713		1.057369911x
> StringIndexOf.successBig	                      14.341		46.343		3.231504079x
> StringIndexOfChar.latin1_AVX2_String	  6220.918		12154.52		1.953814533x
> StringIndexOfChar.latin1_AVX2_char	  5503.556		5540.044		1.006629895x
> StringIndexOfChar.latin1_SSE4_String	  6978.854		6818.689		0.977049957x
> StringIndexOfChar.latin1_SSE4_char	  5657.499		5474.624		0.967675646x
> StringIndexOfChar.latin1_Short_String	  7132.541		6863.359		0.962260014x
> StringIndexOfChar.latin1_Short_char	16013.389	      16162.437		1.009307711x
> StringIndexOfChar.latin1_mixed_String	  7386.123	      14771.622		1.999915517x
> StringIndexOfChar.latin1_mixed_char	  9901.671		9782.245		0.987938803

Scott Gibbons has updated the pull request incrementally with one additional commit since the last revision:

  Added header file

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/16753/files
  - new: https://git.openjdk.org/jdk/pull/16753/files/b6d77fe0..f002fd54

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16753&range=23
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16753&range=22-23

  Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/16753.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16753/head:pull/16753

PR: https://git.openjdk.org/jdk/pull/16753

From mli at openjdk.org  Wed May 22 17:03:03 2024
From: mli at openjdk.org (Hamlin Li)
Date: Wed, 22 May 2024 17:03:03 GMT
Subject: RFR: 8331196: vector api: Remove unnecessary index check in
 Byte/ShortVector.fromArray/fromArray0Template
In-Reply-To: <YLwvFU3XpoutOZCBehEbDwlkkucrAbHv1mF8K9zzDH0=.b49d1661-adac-4a96-b013-84f1b4dd7fcf@github.com>
References: <YLwvFU3XpoutOZCBehEbDwlkkucrAbHv1mF8K9zzDH0=.b49d1661-adac-4a96-b013-84f1b4dd7fcf@github.com>
Message-ID: <zTq2h-XmCfs3JrYCwdHaziJoqCMQzsFM7ZdcIAFZD2c=.46e648d2-3cba-41eb-a7ed-bc9171238c31@github.com>

On Fri, 26 Apr 2024 14:06:02 GMT, Hamlin Li <mli at openjdk.org> wrote:

> Hi,
> Can you help to review this simple patch?
> Some index check in Byte/ShortVector.fromArray/fromArray0Template seems not necessary, could be removed.
> Thanks

In one side, yes, there is a gap in the tests.

In another side, I wonder if the check here is necessary (i.e. `VectorIntrinsics.checkIndex(vix, a.length)`). 
* For default java implementation, it's not necessary, as java code will check it anyway; 
* for intrinsic implementation, I saw relative information (array, offset, index map, offset in the map) are wrapped in LoadVectorGatherNode, I wonder it will also check IOOBE?

As I totally removed `VectorIntrinsics.checkIndex(vix, a.length);`, and in either conditions it still throws IOOBE when it should throw IOOBE.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18977#issuecomment-2125320559

From naoto at openjdk.org  Wed May 22 17:23:15 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 22 May 2024 17:23:15 GMT
Subject: RFR: 8332084: Ensure JdkConsoleImpl.restoreEcho visibility in a
 shutdown hook [v8]
In-Reply-To: <s5UWj1VnzkiOOPZk8YMuJrbyAoMx-pVeV14Cx5UDZeE=.495ed70f-3dd5-4c4d-a616-0f20fcb92907@github.com>
References: <9JTWc3FRpfbILlSHlmIU_dL5IE69RTxnSIAOdIte15I=.5854a48f-21d7-42c9-adb7-5e3ed40d1211@github.com>
 <s5UWj1VnzkiOOPZk8YMuJrbyAoMx-pVeV14Cx5UDZeE=.495ed70f-3dd5-4c4d-a616-0f20fcb92907@github.com>
Message-ID: <3wqzT0bRvcYKv_nM7cvp3crD7Mdi6DtoTAbp5ojlg64=.b0ca72b7-4915-4c91-bc22-e2d06817b37c@github.com>

On Tue, 21 May 2024 22:51:14 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Making sure `restoreEcho` correctly reflects the state in the shutdown thread, which differs from the application's thread that issues the `readPassword()` method.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Used a dedicate lock for restoreEcho

Hi Pavel,

> If I read [this](https://docs.oracle.com/en/java/javase/22/docs/api/java.base/java/lang/Runtime.html#shutdown) correctly, due to the mechanics of JVM exit, we simply don't know which thread finishes first: a thread that calls `readPassword` or the shutdown hook.

IIUC, the thread that waits on `readPassword()` is not a shutdown hook, right? Then I think it is guaranteed that it is still waiting when all the shutdown hooks are executed.

> If the shutdown hook finishes first, then a `readPassword` thread can corrupt the state: unlike the shutdown hook, which JVM _normally has to wait to complete_, the `readPassword` thread can be terminated at any moment. It might as well be terminated before `finally` but after `echo(false)`, in which case we end up with echo turned off.

After the shutdown hooks finish, then the VM is terminated (https://docs.oracle.com/en/java/javase/22/docs/api/java.base/java/lang/Runtime.html#termination). In there:


finally clauses are not executed;

So I think the shutdown hook's restoreEcho has the final say, sans the situation if some app installs a shutdown hook with `readPassword` but I don't think we can guarantee that case, and I believe it is OK.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19184#issuecomment-2125369806

From sgibbons at openjdk.org  Wed May 22 17:40:24 2024
From: sgibbons at openjdk.org (Scott Gibbons)
Date: Wed, 22 May 2024 17:40:24 GMT
Subject: RFR: 8320448: Accelerate IndexOf using AVX2 [v25]
In-Reply-To: <uWi4QxH31hL93771gkl_GgvP0m84IRSoR_1Yi8hD17E=.bc6ed458-7081-4c3f-9348-f59358fa05a4@github.com>
References: <uWi4QxH31hL93771gkl_GgvP0m84IRSoR_1Yi8hD17E=.bc6ed458-7081-4c3f-9348-f59358fa05a4@github.com>
Message-ID: <U7QON8sfYvsebeu-QvEk1Gl5lnvMyVw4SgA29vFUwTo=.1614497f-15ed-454b-a458-0963c4227720@github.com>

> Re-write the IndexOf code without the use of the pcmpestri instruction, only using AVX2 instructions.  This change accelerates String.IndexOf on average 1.3x for AVX2.  The benchmark numbers:
> 
> 
> Benchmark	                                               Score		Latest		
> StringIndexOf.advancedWithMediumSub   343.573		317.934		0.925375393x
> StringIndexOf.advancedWithShortSub1	  1039.081		1053.96		1.014319384x
> StringIndexOf.advancedWithShortSub2	      55.828		110.541		1.980027943x
> StringIndexOf.constantPattern	                9.361		11.906		1.271872663x
> StringIndexOf.searchCharLongSuccess	        4.216		4.218		1.000474383x
> StringIndexOf.searchCharMediumSuccess	3.133		3.216		1.02649218x
> StringIndexOf.searchCharShortSuccess	3.76		        3.761		1.000265957x
> StringIndexOf.success	                                9.186		9.713		1.057369911x
> StringIndexOf.successBig	                      14.341		46.343		3.231504079x
> StringIndexOfChar.latin1_AVX2_String	  6220.918		12154.52		1.953814533x
> StringIndexOfChar.latin1_AVX2_char	  5503.556		5540.044		1.006629895x
> StringIndexOfChar.latin1_SSE4_String	  6978.854		6818.689		0.977049957x
> StringIndexOfChar.latin1_SSE4_char	  5657.499		5474.624		0.967675646x
> StringIndexOfChar.latin1_Short_String	  7132.541		6863.359		0.962260014x
> StringIndexOfChar.latin1_Short_char	16013.389	      16162.437		1.009307711x
> StringIndexOfChar.latin1_mixed_String	  7386.123	      14771.622		1.999915517x
> StringIndexOfChar.latin1_mixed_char	  9901.671		9782.245		0.987938803

Scott Gibbons has updated the pull request incrementally with one additional commit since the last revision:

  un-helper-ize preload_needle_helper; try fix for macos build

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/16753/files
  - new: https://git.openjdk.org/jdk/pull/16753/files/f002fd54..b0ef5e6f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16753&range=24
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16753&range=23-24

  Stats: 102 lines in 1 file changed: 5 ins; 91 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/16753.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16753/head:pull/16753

PR: https://git.openjdk.org/jdk/pull/16753

From mark.yagnatinsky at barclays.com  Wed May 22 17:51:02 2024
From: mark.yagnatinsky at barclays.com (mark.yagnatinsky at barclays.com)
Date: Wed, 22 May 2024 17:51:02 +0000
Subject: stack overflow in regex engine
In-Reply-To: <5b8019db-c9ac-4e4a-9452-20e477c5ec5e@oracle.com>
References: <CH3PR12MB76197D4ECC54728844CE705CF9EB2@CH3PR12MB7619.namprd12.prod.outlook.com>
 <5b8019db-c9ac-4e4a-9452-20e477c5ec5e@oracle.com>
Message-ID: <CH3PR12MB7619677F346E734C75AA6086F9EB2@CH3PR12MB7619.namprd12.prod.outlook.com>

Ah, didn't realize P4 is default; that makes sense.
So I should not even be trying to derive omens from that.
So I guess only the assignee would know whether or not the status is closer to
"I was going to work on that next week" versus
"I totally forgot about that thing, and am about to forget about it again"
I'm quite sure he's on this list and will hopefully read the advocacy section of my email.

Um.  I feel awkward writing this paragraph because you know how OpenJDK works much better than I do, so it feels a bit silly to argue with you about it.  But.  Um.
When you say "this is not the place to ask for fixes" ...
I was under the impression that "asking for fixes" actually does provide value, and not all of that value can be replaced by merely providing fixes.
In particular, asking for fixes gives maintainers a vague sense of how often people in the "real world" tend to run into an issue, which in turn informs how much "cost" is worth spending on addressing it.
(Where "cost" could mean things like "time" and also things like "this makes trickier and hence harder to maintain".)
In fact, I was under the impression that OpenJDK is slightly hostile to "big" fixes by "outsiders" because of the worry that there's now a big/complicated chunk of code that no one inside the project understands and yet the project is responsible for, and the original author might never be heard from again.

Anyway, thanks a bunch for responding; I was worried that no one would.

From: Philip Race <philip.race at oracle.com>
Sent: Wednesday, May 22, 2024 11:54 AM
To: Yagnatinsky, Mark : IT (NYK) <mark.yagnatinsky at barclays.com>; core-libs-dev at openjdk.org
Subject: Re: stack overflow in regex engine


CAUTION: This email originated from outside our organisation - philip.race at oracle.com<mailto:philip.race at oracle.com> Do not click on links, open attachments, or respond unless you recognize the sender and can validate the content is safe.
P4 is the default JBS priority, so sometimes it just means no one figured out the true priority.
But in general P4 bugs could be open for years, or even never get fixed.
The priority is also partially an assessment of where it falls as a priority for the JDK developers.
A user of JDK may have an entirely different perspective.
And that's why there are vendors who provide support for JDK. They can also arrange the backports you need.
But that's not done here. Here is where you come to participate and contribute fixes, not ask for fixes.
So my suggestion is to raise it via your support channel to your particular vendor who provided your binary.

-phil
On 5/21/24 8:46 PM, mark.yagnatinsky at barclays.com<mailto:mark.yagnatinsky at barclays.com> wrote:
(Sorry about my previous "do I need to subscribe?" email; in retrospect that was needless noise.)
The purpose of this email is twofold: first, inquire about the status of ticket filed a few years ago, and second to point out some non-obvious reasons why it might be slightly more serious than it seems.
The ticket is this one https://bugs.openjdk.org/browse/JDK-8260866<https://clicktime.symantec.com/15t5ekSGXorRH53n7q6GJ?h=e9ZmDJOAdCkeHz_PXjDgZiyUdvJmTZTTcGvZoAULMmE=&u=https://bugs.openjdk.org/browse/JDK-8260866> (stack overflow in regex matching quantified alternation)
The priority is listed as P4, which I guess means something like "medium" (more important than p5, but less than p3)
It also has a specific person assigned, which seems vaguely encouraging, but no updates at all in the years since it's been created, which seems less encouraging.
It was seemingly never once discussed on this mailing list, not even when it was first filed.
As an outsider, I'm not quite sure how to interpret all these various omens and turn them into guesses about its eventual fate.
Will it remain unfixed for another decade or two?  Will it be fixed in a few months, but then never backported to old versions?  Something else?  No one knows?

That concludes the status inquiry.  Now on to the advocacy.  Some bugs are annoying, but once you hit them, you can work around them by changing your code so it does not trigger the bug.
Note the phrase "your code" above.  This is much more awkward to do if the bug triggered by third-party code you got from maven central or something.
At that point your options are to either ask the third party library to work around it, or else fork the dependency (which is not well supported by mainstream build tools (or maybe I'm just using them wrong)).
In this case, regular expressions are so ubiquitous that the bug is quite plausibly more likely to be triggered by some third party dependency than by code you own.
That was the case for me today: after spending hours trying to track down a stack overflow error I found the offending regex in a third party library.
The good news is that for the kinds of inputs we need to handle, it is indeed easy to substitute a much simpler regex that would avoid the issue.
The bad news is that it's not my code, so I can't.  I could petition the maintainers of the library, but this is not great because:
First, maybe the version I'm on is not longer even supported, and newer versions are not compatible,
Second, it may take them a while to fix it, and third, it is wasteful (and inelegant) to have workarounds slowly percolate throughout the Java ecosystem instead of fixing the problem at the root.

The other annoying thing here is that even when you have "enough" stack space to avoid crashing, using it may not be quite "free".
For instance, project loom's foundational premise seems to be that "most threads have oversized stacks; we can have more threads if we start off with small stacks and grow them only when needed".
This would be false when the thread in question uses a regex with quantified alternation.
(Since many Loom threads will be based on the same Runnable, it's a pretty safe bet that if one of them uses this feature, many will, so you can't assume it will "average out".)
There are other reasons besides loom to be low on stack space; maybe you're using some crazy framework(s) that like(s) to have call stacks that are crazy deep.
Or maybe you're running with -Xss set pretty low.  Or you passed a small value for stack space to the Thread constructor.
Or maybe none of these things are true, but in most operating systems a thread stack costs "real" memory in proportion to its high-watermark, so even a SINGLE heavy regex in the lifetime of a thread is tantamount to a memory leak of hundreds of kilobytes.

Practicalities aside, I don't like it when code consumes "surprising" types of resources, or surprising amounts of them.
For instance, you wouldn't expect a sorting function to spawn threads behind your back, unless it was called "parallel sort" or something like that.
You wouldn't expect it to allocate multi-gigabyte arrays, nor to perform I/O.
Similarly, most functions need only O(1) stack space, so this tends to be the default assumption unless the docs explicitly call out "this thing might throw stack overflows at you so make sure you have plenty of stack space"
Some need a bit more... for instance, I would not be surprised if a regex need stack space in proportion to the depth of the parse tree of the regex.
But stack space in proportion to the length of the string being matched is the kind of thing that I'd hope gets called out in those @implNotes thingies, or better yet fixed.

Even people who know that regex matching can sometimes take exponential time may naively assume that regex matching would not consume O(n) stack space, where n is the input length.
What's worse, not only does it indeed consume stack space linear in the length of the input, but the constant hidden by the O() notation is itself pretty scary.
For instance, consider the regex that caused my troubles today:
https://github.com/apache/camel/blob/main/core/camel-support/src/main/java/org/apache/camel/support/ObjectHelper.java#L63<https://clicktime.symantec.com/15t5jadYzRY1h1shfPVQv?h=nT81oCo1qZ8nsQ8sI9SyBtH8DOuudlSAMaXkeKhYmgU=&u=https://github.com/apache/camel/blob/main/core/camel-support/src/main/java/org/apache/camel/support/ObjectHelper.java%23L63>
After getting rid of extra escaping and also double-escaping caused by java not having "raw" strings, we're left with this:
,(?!(?:[^(,]|[^)],[^)])+\))
(I find the above hard to read; the regex I would have replaced it with, if it had been "our" code is simply a single comma.)
Anyway, I tried creating a Scanner with the delimiter above and looping through all the tokens in the string that originally caused the crash.
I thought that perhaps it would work, since I had a simple example that does everything in main, but it also crashed.
Then I decided to play an alternating game where I trimmed the string until it stopped crashing, then lowered Xss by 64k and repeated.
Eventually, I got it crashing with a call stack well over 500 calls deep on a string less than a 128 characters long.
(The string was not hand-crafted; it was simply a prefix of the original string that caused the first crash I tracked down.)
The string in question had a mere five tokens, which is to say that it had just four commas.
It had no open or close parenthesis, so the entire negative lookahead assertion served as a giant no-op, at least when it wasn't crashing.
(Technically, the stack usage is linear in the length of the input AFTER the first comma, but the first comma was pretty early.)

Sorry if this email is poorly organized; I've already spent way too many hours on it (not even counting the debugging that prompted it) and I need to get some sleep now.

If anyone actually reads all or most of this, thank you.
Mark.

P.S. if anyone actually responds, thank you even more.

This message is for information purposes only. It is not a recommendation, advice, offer or solicitation to buy or sell a product or service, nor an official confirmation of any transaction. It is directed at persons who are professionals and is intended for the recipient(s) only. It is not directed at retail customers. This message is subject to the terms at: https://www.ib.barclays/disclosures/web-and-email-disclaimer.html<https://clicktime.symantec.com/15t69jbyHVwykk1KPBVA2?h=WSydRJ-8a9jEVWGSLyCrdLEU7Xfx-K-gu16DAstEYWQ=&u=https://www.ib.barclays/disclosures/web-and-email-disclaimer.html>.

For important disclosures, please see: https://www.ib.barclays/disclosures/sales-and-trading-disclaimer.html<https://clicktime.symantec.com/15t64uQgptGPLoBPqd61Q?h=sYkJo73WS5C5wTtskVoUQEfn7gI-sb4yDI0khVoYK3Q=&u=https://www.ib.barclays/disclosures/sales-and-trading-disclaimer.html> regarding marketing commentary from Barclays Sales and/or Trading desks, who are active market participants; https://www.ib.barclays/disclosures/barclays-global-markets-disclosures.html<https://clicktime.symantec.com/15t5pQpqT3Dc6xhdCwtZY?h=qVJHSoTdp0pI-_4TT9h4U49uHhqWqUQdMGYEdhG-Ouo=&u=https://www.ib.barclays/disclosures/barclays-global-markets-disclosures.html> regarding our standard terms for Barclays Investment Bank where we trade with you in principal-to-principal wholesale markets transactions; and in respect to Barclays Research, including disclosures relating to specific issuers, see: http://publicresearch.barclays.com<https://clicktime.symantec.com/15t5ZvEz5CAps8DraGh7g?h=87QBG12g6Fm-478KIe1pp-nBD10MhX6JgAq8TwQi770=&u=http://publicresearch.barclays.com>.
__________________________________________________________________________________
If you are incorporated or operating in Australia, read these important disclosures: https://www.ib.barclays/disclosures/important-disclosures-asia-pacific.html<https://clicktime.symantec.com/15t5uF27ueuCWuXYkWHiA?h=GPXVMoOv512jLvxDhIJnWdewKcbTe5uGye3MLfO8Uxc=&u=https://www.ib.barclays/disclosures/important-disclosures-asia-pacific.html>.
__________________________________________________________________________________
For more details about how we use personal information, see our privacy notice: https://www.ib.barclays/disclosures/personal-information-use.html<https://clicktime.symantec.com/15t5z5DQNGanvrMUJ4grn?h=zIClmLbPkrAGRja2m5HovRZhDKBBGmDTQHvE9kjAkxQ=&u=https://www.ib.barclays/disclosures/personal-information-use.html>.
__________________________________________________________________________________


This message is for information purposes only. It is not a recommendation, advice, offer or solicitation to buy or sell a product or service, nor an official confirmation of any transaction. It is directed at persons who are professionals and is intended for the recipient(s) only. It is not directed at retail customers. This message is subject to the terms at: https://www.ib.barclays/disclosures/web-and-email-disclaimer.html. 

For important disclosures, please see: https://www.ib.barclays/disclosures/sales-and-trading-disclaimer.html regarding marketing commentary from Barclays Sales and/or Trading desks, who are active market participants; https://www.ib.barclays/disclosures/barclays-global-markets-disclosures.html regarding our standard terms for Barclays Investment Bank where we trade with you in principal-to-principal wholesale markets transactions; and in respect to Barclays Research, including disclosures relating to specific issuers, see: http://publicresearch.barclays.com.
__________________________________________________________________________________ 
If you are incorporated or operating in Australia, read these important disclosures: https://www.ib.barclays/disclosures/important-disclosures-asia-pacific.html.
__________________________________________________________________________________
For more details about how we use personal information, see our privacy notice: https://www.ib.barclays/disclosures/personal-information-use.html. 
__________________________________________________________________________________
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240522/5802e317/attachment-0001.htm>

From amansha at kth.se  Wed May 22 18:19:41 2024
From: amansha at kth.se (Aman Sharma)
Date: Wed, 22 May 2024 18:19:41 +0000
Subject: Deterministic naming of subclasses of `java/lang/reflect/Proxy`
In-Reply-To: <b64077d6cf0045e98b630cf888785182@kth.se>
References: <bf26eb2f74874e02876b3868311922a9@kth.se>
 <CABe8uE0fk71Xy_PYHikSw9OtXE_i+M9zMbayPEXuTxLWLoy2ag@mail.gmail.com>
 <50405ca9c0a64372bace175b932f9ef7@kth.se>
 <61fbe3d9-9536-4113-adde-6cfc671ba1ee@oracle.com>
 <a860be44e06243799593aa8d67c048cd@kth.se>
 <CABe8uE115=DzYCdnvNazqFuuxtJoZnv9wRUkFA4-PS7g41QLMw@mail.gmail.com>
 <DB7PR02MB35938DCC3A392536B924164AFBEE2@DB7PR02MB3593.eurprd02.prod.outlook.com>
 <a0330ee0-5f45-4ef2-8500-e5fcdb696c52@oracle.com>
 <b214cc1a13fe4885a437e16b420e5483@kth.se>
 <ac2ebe5c-db49-4a2d-a5cd-10440a77aa16@oracle.com>
 <580b3aacd8df48fcaae3399718e229ab@kth.se>,
 <CABe8uE065Q3+0yNjtyDF-eJM4LN-MbY9kfC44CnSQ-KM4p862g@mail.gmail.com>,
 <b64077d6cf0045e98b630cf888785182@kth.se>
Message-ID: <eabfa5ae508e4257bd0c9bbef244637f@kth.se>

Hi,


Another thing I wanted to look into in this thread was the order of fields in the Proxy classes generated. They are also based on the a number. The same proxy classes across different executions can have random order of `Method` fields and the methods could be mapped to different field names.


For example, consider the proxy class based on `picocli.CommandLine<https://github.com/remkop/picocli/blob/da98db63d1b516141b7485881b0dcddfd082dbc8/src/main/java/picocli/CommandLine.java#L4541>` in two different executions.

// fields and method are truncated for brevity
public final class $Proxy9 extends Proxy implements CommandLine.Command {
    private static Method m1;
    private static Method m32;
    private static Method m21;
    private static Method m43;
    private static Method m36;
    private static Method m27;

    public final boolean helpCommand() throws  {
        try {
            return (Boolean)super.h.invoke(this, m32, (Object[])null);
        } catch (RuntimeException | Error var2) {
            throw var2;
        } catch (Throwable var3) {
            throw new UndeclaredThrowableException(var3);
        }
     }

// fields and method are truncated for brevity
public final class $Proxy13 extends Proxy implements CommandLine.Command {
    private static Method m1;
    private static Method m29;
    private static Method m16;
    private static Method m40;
    private static Method m38;
    private static Method m12;

    public final boolean helpCommand() throws  {
        try {
            return (Boolean)super.h.invoke(this, m29, (Object[])null);
        } catch (RuntimeException | Error var2) {
            throw var2;
        } catch (Throwable var3) {
            throw new UndeclaredThrowableException(var3);
        }
    }


Notice the difference in the order of fields and `helpCommand` method is mapped to a different field name in both classes. This happens because the method array returned by `getMethods` is not sorted in any particular order<https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/lang/Class.java#L2178> when generating a proxy class. What dictates this order? And why is it not deterministic?


Regards,
Aman Sharma

PhD Student
KTH Royal Institute of Technology
School of Electrical Engineering and Computer Science (EECS)
Department of Theoretical Computer Science (TCS)
<http://www.kth.se><https://www.kth.se/profile/amansha><https://www.kth.se/profile/amansha>
<https://www.kth.se/profile/amansha>https://algomaster99.github.io/
________________________________
From: Aman Sharma
Sent: Wednesday, May 22, 2024 4:12:19 PM
To: Chen Liang
Cc: David Holmes; core-libs-dev at openjdk.org; leyden-dev at openjdk.org
Subject: Re: Deterministic naming of subclasses of `java/lang/reflect/Proxy`


Hi Chen,


That's clear. Thanks for letting me know. I guess then Project Leyden is working on naming the hidden classes deterministically to achieve their goals<https://openjdk.org/projects/leyden/notes/01-beginnings>.


Regards,
Aman Sharma

PhD Student
KTH Royal Institute of Technology
School of Electrical Engineering and Computer Science (EECS)
Department of Theoretical Computer Science (TCS)
<http://www.kth.se><https://www.kth.se/profile/amansha><https://www.kth.se/profile/amansha>
<https://www.kth.se/profile/amansha>https://algomaster99.github.io/
________________________________
From: Chen Liang <liangchenblue at gmail.com>
Sent: Wednesday, May 22, 2024 1:35:46 PM
To: Aman Sharma
Cc: David Holmes; core-libs-dev at openjdk.org; leyden-dev at openjdk.org
Subject: Re: Deterministic naming of subclasses of `java/lang/reflect/Proxy`

Hi Aman,
We have tried defining Proxy as hidden classes; a previous attempt was on hold because of issues with serialization. Otherwise, Proxies work great as hidden classes.

Chen

On Mon, May 20, 2024 at 7:56?AM Aman Sharma <amansha at kth.se<mailto:amansha at kth.se>> wrote:

Hi David,


> I would not expect any class load
events.


I understand. I also haven't tried to intercept them but I see only one approach right now to include them in an allowlist - 1) statically look for invocations of "Lookup::defineHiddenClass". 2) Instrument them so that its first argument "bytes" can be looked into upon. I haven't looked into it much because I did not have much idea about it. And they are hidden so it made it worse. ? Thanks for sharing the JEP!


>

java.lang.reflect.Proxy could define hidden classes to act as the proxy classes which implement proxy interfaces; from JEP 317


It says that Proxy classes will also become hidden classes. Is it underway? Right now one can intercept, transform them, and include them in an allowlist. What do you think of naming them independent of AtomicLong so that a proxy class generated at runtime is easy to lookup in the allowlist?



Regards,
Aman Sharma

PhD Student
KTH Royal Institute of Technology
School of Electrical Engineering and Computer Science (EECS)
Department of Theoretical Computer Science (TCS)
<http://www.kth.se><https://www.kth.se/profile/amansha><https://www.kth.se/profile/amansha>
<https://www.kth.se/profile/amansha>https://algomaster99.github.io/
________________________________
From: David Holmes <david.holmes at oracle.com<mailto:david.holmes at oracle.com>>
Sent: Monday, May 20, 2024 2:30:37 PM
To: Aman Sharma; liangchenblue at gmail.com<mailto:liangchenblue at gmail.com>
Cc: core-libs-dev at openjdk.org<mailto:core-libs-dev at openjdk.org>; leyden-dev at openjdk.org<mailto:leyden-dev at openjdk.org>
Subject: Re: Deterministic naming of subclasses of `java/lang/reflect/Proxy`

On 20/05/2024 10:12 pm, Aman Sharma wrote:
> Hi David,
>
>
>  > How did you try to intercept them? Hidden classes are not "loaded" in
> the normal sense so won't trigger class load events.
>
>
> I could not intercept them. I only see them when I pass `-verbose:class`
> in the Java CLI.

Yes that is why I asked how you tried to intercept them.

>
> I also couldn't intercept them using JVMTI Class File Load Hook
> <https://docs.oracle.com/en/java/javase/21/docs/specs/jvmti.html#ClassFileLoadHook> event. However JEP 371 suggests that it should be possible to intercept them using JVMTI Class Load <https://docs.oracle.com/en/java/javase/21/docs/specs/jvmti.html#ClassLoad> event, but I won't have the bytecode at this stage. So is there no way to get its bytecode before it is linked and initialized in the JVM?

Hidden classes are not loaded so I would not expect any class load
events. However the exact nature of the JVMTI class load event is
unclear as it talks about "class or interface creation" which is neither
loading or defining per se. But a class prepare event sounds like it
should be issued. However neither give you access to the bytecode of the
class AFAICS.

David
-----


>
> Regards,
> Aman Sharma
>
> PhD Student
> KTH Royal Institute of Technology
> School of Electrical Engineering and Computer Science (EECS)
> Department of Theoretical Computer Science (TCS)
> <http://www.kth.se><https://www.kth.se/profile/amansha><https://www.kth.se/profile/amansha>
> <https://www.kth.se/profile/amansha>https://algomaster99.github.io/
> <https://algomaster99.github.io/>
> ------------------------------------------------------------------------
> *From:* David Holmes <david.holmes at oracle.com<mailto:david.holmes at oracle.com>>
> *Sent:* Monday, May 20, 2024 2:59:17 AM
> *To:* Aman Sharma; liangchenblue at gmail.com<mailto:liangchenblue at gmail.com>
> *Cc:* core-libs-dev at openjdk.org<mailto:core-libs-dev at openjdk.org>; leyden-dev at openjdk.org<mailto:leyden-dev at openjdk.org>
> *Subject:* Re: Deterministic naming of subclasses of
> `java/lang/reflect/Proxy`
> On 17/05/2024 9:43 pm, Aman Sharma wrote:
>> Hi Chen,
>>
>>  > java.lang.invoke.LambdaForm$MH/0x00000200cc000400
>>
>> I do see this as output when I pass -verbose:class. However, based on my
>> experiments, I have seen that neither an agent passed via 'javaagent'
>> nor an agent passed via 'agentpath' is able to intercept this hidden class.
>
> How did you try to intercept them? Hidden classes are not "loaded" in
> the normal sense so won't trigger class load events.
>
>> Also, I was a bit confused since I saw somewhere that the names of
>> hidden classes are null. But thanks for clarifying here.
>
> The JEP clearly defines the name format for hidden classes - though the
> final component is VM specific (and typically a hashcode).
>
> https://openjdk.org/jeps/371 <https://openjdk.org/jeps/371>
>
> Cheers,
> David
> -----
>
>>  > avoid dynamic class loading
>>
>> I don't see dynamic class loading as a problem. I only mind some
>> unstable generation aspects of them which make it hard to verify them
>> based on an allowlist.
>>
>> For example, if this hidden class is generated with the exact same name
>> and the exact same bytecode during runtime as well, it would be easy to
>> verify it. However, I do see the names are based on some sort of memory
>> address so and I don't know what bytecode it has so I don't have
>> suggestions to make them stable as of now. For Proxy classes, I feel it
>> can be addressed unless you disagree or some involved in Project Leyden
>> does. :) Thank you for forwarding my mail there.
>>
>> Regards,
>> Aman Sharma
>>
>> PhD Student
>> KTH Royal Institute of Technology
>> https://algomaster99.github.io/ <https://algomaster99.github.io/>
> <https://algomaster99.github.io/ <https://algomaster99.github.io/>>
>>
>> ------------------------------------------------------------------------
>> *From:* liangchenblue at gmail.com<mailto:liangchenblue at gmail.com> <liangchenblue at gmail.com<mailto:liangchenblue at gmail.com>>
>> *Sent:* Friday, May 17, 2024 1:23:58 pm
>> *To:* Aman Sharma <amansha at kth.se<mailto:amansha at kth.se>>
>> *Cc:* core-libs-dev at openjdk.org<mailto:core-libs-dev at openjdk.org> <core-libs-dev at openjdk.org<mailto:core-libs-dev at openjdk.org>>;
>> leyden-dev at openjdk.org<mailto:leyden-dev at openjdk.org> <leyden-dev at openjdk.org<mailto:leyden-dev at openjdk.org>>
>> *Subject:* Re: Deterministic naming of subclasses of
>> `java/lang/reflect/Proxy`
>>
>> Hi Aman,
>> For `-verbose:class`, it's a JVM argument instead of a program argument;
>> so when you run a java program like `java Main`, you should call it as
>> `java -verbose:class Main`.
>> When done correctly, you should see hidden class outputs like:
>> [0.032s][info][class,load]
>> java.lang.invoke.LambdaForm$MH/0x00000200cc000400 source:
>> __JVM_LookupDefineClass__
>> The loading of java.lang.invoke hidden classes requires your program to
>> use MethodHandle features, like a lambda.
>>
>> I think the problem you are exploring, that to avoid dynamic class
>> loading and effectively turn Java Platform closed for security, is also
>> being accomplished by project Leyden (as I've shared initially); Thus, I
>> am forwarding this to leyden-dev instead, so you can see what approach
>> Leyden uses to accomplish the same goal as yours.
>>
>> Regards, Chen Liang
>>
>> On Fri, May 17, 2024 at 4:40?AM Aman Sharma <amansha at kth.se<mailto:amansha at kth.se>
>> <mailto:amansha at kth.se<mailto:amansha at kth.se> <mailto:amansha at kth.se>>> wrote:
>>
>>     __
>>
>>     Hi Roger,
>>
>>
>>     Do you have ideas on how to intercept them? My javaagent is not able
>>     to nor a JVMTI agent passed using `agentpath` option. It also does
>>     not seem to show up in logs when I pass `-verbose:class`.
>>
>>
>>     Also, what do you think of renaming the proxy classes as suggested
>>     below?
>>
>>
>>     Regards,
>>     Aman Sharma
>>
>>     PhD Student
>>     KTH Royal Institute of Technology
>>     School of Electrical Engineering and Computer Science (EECS)
>>     Department of Theoretical Computer Science (TCS)
>>     <http://www.kth.se><https://www.kth.se/profile/amansha><https://www.kth.se/profile/amansha <http://www.kth.se><https://www.kth.se/profile/amansha><https://www.kth.se/profile/amansha>>
>>     <https://www.kth.se/profile/amansha
> <https://www.kth.se/profile/amansha>>https://algomaster99.github.io/
>>     <https://algomaster99.github.io/ <https://algomaster99.github.io/>>
>>     ------------------------------------------------------------------------
>>     *From:* core-libs-dev <core-libs-dev-retn at openjdk.org<mailto:core-libs-dev-retn at openjdk.org>
>>     <mailto:core-libs-dev-retn at openjdk.org<mailto:core-libs-dev-retn at openjdk.org>
> <mailto:core-libs-dev-retn at openjdk.org>>> on behalf of Roger Riggs
>>     <roger.riggs at oracle.com<mailto:roger.riggs at oracle.com> <mailto:roger.riggs at oracle.com<mailto:roger.riggs at oracle.com> <mailto:roger.riggs at oracle.com>>>
>>     *Sent:* Friday, May 17, 2024 4:57:46 AM
>>     *To:* core-libs-dev at openjdk.org<mailto:core-libs-dev at openjdk.org> <mailto:core-libs-dev at openjdk.org<mailto:core-libs-dev at openjdk.org> <mailto:core-libs-dev at openjdk.org>>
>>     *Subject:* Re: Deterministic naming of subclasses of
>>     `java/lang/reflect/Proxy`
>>     Hi Aman,
>>
>>     You may also run into hidden classes (JEP 371: Hidden Classes) that
>>     allow classes to be defined, at runtime, without names.
>>     It has been proposed to use them for generated proxies but that
>>     hasn't been implemented yet.
>>     There are benefits to having nameless classes, because they can't be
>>     referenced by name, only as a capability, they can be better
>>     encapsulated.
>>
>>     fyi, Roger Riggs
>>
>>
>>     On 5/16/24 8:11 AM, Aman Sharma wrote:
>>>
>>>     Hi,
>>>
>>>
>>>     Thanks for your response, Liang!
>>>
>>>
>>>     > I think you meant CVE-2021-42392 instead of 2022.
>>>
>>>
>>>     Sorry of the error. I indeed meant CVE-2021-42392
>>>     <https://nvd.nist.gov/vuln/detail/cve-2021-42392
> <https://nvd.nist.gov/vuln/detail/cve-2021-42392>>.
>>>
>>>
>>>     > Leyden mainly avoids this unstable generation by performing a
>>>     training run to collect classes loaded
>>>
>>>
>>>     Would love to know the details of Project Leyden and how they
>>>     worked so far to focus on this goal. In our case, the training run
>>>     is the test suite.
>>>
>>>
>>>     > GeneratedConstructorAccessor is already retired by JEP 416 [2]
>>>     in Java 18
>>>
>>>
>>>     I did see them not appearing in my allowlist when I ran my study
>>>     subject (Apache PDFBox) with Java 21. Thanks for letting me know
>>>     about this JEP. I see they are re-implemented with method handles.
>>>
>>>
>>>     > How are you checking the classes?
>>>
>>>
>>>     To detect runtime generated code, we have javaagent that is hooked
>>>     statically to the test suite execution. It gives us all classes
>>>     that that is loaded post the JVM and the javaagent are loaded. So
>>>     we only check the classes loaded for the purpose of running the
>>>     application. This is also why we did not choose -agentlib as it
>>>     would give classes for the setting up JVM and javaagent and we the
>>>     user of our tool must the classes they load.
>>>
>>>
>>>     Next, we have a `ClassFileTransformer` hook in the agent where we
>>>     produce the checksum using the bytecode. And we compare the
>>>     checksum with the one existing in the allowlist. The checksum
>>>     computation algorithm is same for both steps. Let me describe how
>>>     I compute the checksum.
>>>
>>>
>>>      1. I get the CONSTANT_Class_info
>>>         <https://docs.oracle.com/javase/specs/jvms/se11/html/jvms-4.html#jvms-4.4.1 <https://docs.oracle.com/javase/specs/jvms/se11/html/jvms-4.html#jvms-4.4.1>> entry corresponding to `this_class` and rewrite the CONSTANT_Utf8_info <https://docs.oracle.com/javase/specs/jvms/se11/html/jvms-4.html#jvms-4.4.7 <https://docs.oracle.com/javase/specs/jvms/se11/html/jvms-4.html#jvms-4.4.7>> corresponding to a fix String constant, say "foo".
>>>      2. Since, the name of the class is used to refer to its types
>>>         members (fields/method), I get all CONSTANT_Fieldref_info
>>>         <https://docs.oracle.com/javase/specs/jvms/se11/html/jvms-4.html#jvms-4.4.2 <https://docs.oracle.com/javase/specs/jvms/se11/html/jvms-4.html#jvms-4.4.2>> and if its `class_index` corresponds to the old `this_class`, we rewrite the UTF8 value of class_index to the same constant "foo".
>>>      3. Next, since the naming of the fields, in Proxy classes, are
>>>         also suffixed by numbers, for example, `private static Method
>>>         m4`, we rewrite the UTF8 value of name in the
>>>         CONSTANT_NameAndType_info
>>>         <https://docs.oracle.com/javase/specs/jvms/se11/html/jvms-4.html#jvms-4.4.6 <https://docs.oracle.com/javase/specs/jvms/se11/html/jvms-4.html#jvms-4.4.6>>.
>>>      4. These fields can also have a random order so we simply sort
>>>         the entire byte code using `Arrays.sort(byte[])` to eliminate
>>>         any differences due to ordering of fields/methods.
>>>      5. Simply sorting the byte array still had minute differences. I
>>>         could not understand why they existed even though values in
>>>         constant pool of the bytecode in allowlist and at runtime were
>>>         exactly the same after rewriting. The differences existed in
>>>         the bytes of the Code attribute of methods. I concluded that
>>>         the bytes stored some position information. To avoid this, I
>>>         created a subarray where I considered the bytes corresponding
>>>         to `CONSTANT_Utf8_info.bytes` only. Computing a checksum for
>>>         it resulted in the same checksums for both classfiles.
>>>
>>>
>>>     Let's understand the whole approach with an example of Proxy class.
>>>
>>>     `
>>>     public  final  class  $Proxy42  extends  Proxy  implements  org.apache.logging.log4j.core.config.plugins.Plugin  {
>>>     `
>>>
>>>     The will go in the allowlist as "Proxy_Plugin: <SHA256 checksum>".
>>>
>>>     When the same class is intercepted at runtime, say "$Proxy10", we
>>>     look for "Proxy_Plugin" in the allowlist and since the checksum
>>>     algorithm is same in both cases, we get a match and let the class
>>>     load.
>>>
>>>     This approach has seemed to work well for Proxy classes, Generated
>>>     Constructor Accessor (which is removed as you said). I also looked
>>>     at the species generated by method handles. I did not notice any
>>>     modification in them. Their name generation seemed okay to me. If
>>>     some new Species are generated, it is of course detected since it
>>>     is not in the allowlist.
>>>
>>>     I have not looked into LambdaMetafactory because I did not
>>>     encounter it as a problem so far, but I am aware its name
>>>     generation is also unstable. I have run my approach only a few
>>>     projects only. And for hidden classes, I assume the the agent
>>>     won't be able to intercept them so detecting them would be really
>>>     hard.
>>>
>>>
>>>     Regards,
>>>     Aman Sharma
>>>
>>>     PhD Student
>>>     KTH Royal Institute of Technology
>>>     School of Electrical Engineering and Computer Science (EECS)
>>>     Department of Theoretical Computer Science (TCS)
>>>     <https://www.kth.se/profile/amansha
> <https://www.kth.se/profile/amansha>>https://algomaster99.github.io/
> <https://algomaster99.github.io/ <https://algomaster99.github.io/>>
>>>     ------------------------------------------------------------------------
>>>     *From:* liangchenblue at gmail.com<mailto:liangchenblue at gmail.com> <mailto:liangchenblue at gmail.com<mailto:liangchenblue at gmail.com> <mailto:liangchenblue at gmail.com>>
>>>     <liangchenblue at gmail.com<mailto:liangchenblue at gmail.com>> <mailto:liangchenblue at gmail.com<mailto:liangchenblue at gmail.com> <mailto:liangchenblue at gmail.com>>
>>>     *Sent:* Thursday, May 16, 2024 5:52:03 AM
>>>     *To:* Aman Sharma; core-libs-dev
>>>     *Cc:* Martin Monperrus
>>>     *Subject:* Re: Deterministic naming of subclasses of
>>>     `java/lang/reflect/Proxy`
>>>     Hi Aman,
>>>     I think you meant CVE-2021-42392 instead of 2022.
>>>
>>>     For your approach of an "allowlist" for Java runtime, project
>>>     Leyden is looking to generate a static image [1], that
>>>     > At run time it cannot load classes from outside the image, nor
>>>     can it create classes dynamically.
>>>     Leyden mainly avoids this unstable generation by performing a
>>>     training run to collect classes loaded and even object graphs; I
>>>     am not familiar with the details unfortunately.
>>>
>>>     Otherwise, the Proxy discussion belongs better to core-libs-dev,
>>>     as java.lang.reflect.Proxy is part of Java's core libraries. I am
>>>     replying this thread to core-libs-dev.
>>>
>>>     For your perceived problem that classes don't have unique names,
>>>     your description sounds dubious: GeneratedConstructorAccessor is
>>>     already retired by JEP 416 [2] in Java 18, and there are many
>>>     other cases in which JDK generates classes without stable names,
>>>     notoriously LambdaMetafactory (Gradle wished for cacheable
>>>     Lambdas); the same applies for the generated classes for
>>>     MethodHandle's LambdaForms (which carries implementation code for
>>>     LambdaForm). How are you checking the classes? It seems you are
>>>     not checking hidden classes. Proxy and Lambda classes are defined
>>>     by the caller's class loader, while LambdaForms are under JDK's
>>>     system class loader I think. We need to ensure you are correctly
>>>     finding all unstable classes before we can proceed.
>>>
>>>     [1]: https://openjdk.org/projects/leyden/notes/01-beginnings
> <https://openjdk.org/projects/leyden/notes/01-beginnings>
>>>     <https://openjdk.org/projects/leyden/notes/01-beginnings
> <https://openjdk.org/projects/leyden/notes/01-beginnings>>
>>>     [2]: https://openjdk.org/jeps/416 <https://openjdk.org/jeps/416>
> <https://openjdk.org/jeps/416 <https://openjdk.org/jeps/416>>
>>>
>>>     On Wed, May 15, 2024 at 7:00?PM Aman Sharma <amansha at kth.se<mailto:amansha at kth.se>
>>>     <mailto:amansha at kth.se<mailto:amansha at kth.se> <mailto:amansha at kth.se>>> wrote:
>>>
>>>         Hi,
>>>
>>>
>>>         My name is Aman and I am a PhD student at KTH Royal Institute
>>>         of Technology, Stockholm, Sweden. I research as part of CHAINS
>>>         <https://chains.proj.kth.se/ <https://chains.proj.kth.se/>> project to
> strengthen the
>>>         software supply chain of multiple ecosystem. I particularly
>>>         focus on runtime integrity in Java. In this email, I want to
>>>         write about an issue I have discovered with /dynamic
>>>         generation of `java.lang.reflect.Proxy`classes/. I will
>>>         propose a solution and would love to hear the feedback from
>>>         the community. Let me know if this is the correct mailing-list
>>>         for such discussions. It seemed the most relevant from this
>>>         list <https://mail.openjdk.org/mailman/listinfo
> <https://mail.openjdk.org/mailman/listinfo>>.
>>>
>>>
>>>         *My research*
>>>
>>>         *
>>>         *
>>>
>>>         Java has features to load class on the fly - it can either
>>>         download or generate a class at runtime. These features are
>>>         useful for inner workings of JDK. For example, implementing
>>>         annotations, reflective access, etc. However, these features
>>>         have also contributed to critical vulnerabilities in the past
>>>         - CVE-2021-44228  (log4shell), CVE-2022-33980, CVE-2022-42392.
>>>         All of these vulnerabilities have one thing in common - /a
>>>         class that was not known during build time was
>>>         downloaded/generated at runtime and loaded into JVM./
>>>
>>>
>>>         To defend against such vulnerabilities, we propose a solution
>>>         to /allowlist classes for runtime/. This allowlist will
>>>         contain an exhaustive list of classes that can be loaded by
>>>         the JVM and it will be enforced at runtime. We build this
>>>         allowlist from three sources:
>>>
>>>          1. All classes of all modules provided by the Java Standard
>>>             Library. We use ClassGraph
>>>             <https://github.com/classgraph/classgraph
> <https://github.com/classgraph/classgraph>> to scan the JDK.
>>>          2. We can take the source code and all dependencies of an
>>>             application. We use a software bill of materials to get
>>>             all the data.
>>>          3. Finally, we use run the test suite to include any runtime
>>>             downloaded/generated classes.
>>>
>>>         Such a list is able to prevent the above 3 CVEs because it
>>>         does not let the "unknown" bytecode to be loaded.
>>>
>>>         *Problem with generating such an allowlist*
>>>         *
>>>         *
>>>         The first two parts of the allowlist are easy to get. The
>>>         problem is with the third step where we want to allowlist all
>>>         the classes that could be downloaded or generated. Upon
>>>         running the test suite and hooking to the classes it loads, we
>>>         observer that the list consists of classes that are called
>>>         "com/sun/proxy/$Proxy2",
>>>         "jdk/internal/reflect/GeneratedConstructorAccessor3" among
>>>         many more. The purpose of these classes can be identifed. The
>>>         proxy class is created for to implement an annotation. The
>>>         accessor gives access to constructor of a class to the JVM.
>>>
>>>         When enforcing this allowlist at runtime, we see that the
>>>         bytecode content for "com/sun/proxy/$Proxy2" differs in the
>>>         allowlist and at runtime. In our case, we we are experimenting
>>>         with pdfbox <https://github.com/apache/pdfbox <https://github.com/apache/pdfbox>> so
> we created
>>>         the allowlist using its test suite. Then we enforced this
>>>         allowlist while running some of its subcommands. However,
>>>         there was some other proxy class say "com/sun/proxy/$Proxy5"
>>>         at runtime that implemented the same interfaces and had the
>>>         same methods as "com/sun/proxy/$Proxy2" in the allowlist. They
>>>         only differed in the name of the class, order of fields, and
>>>         types for fields references. This could happen because the
>>>         order of the loading of class is workload dependent, but it
>>>         causes problem to generate such an allowlist.
>>>
>>>         *Solution
>>>         *
>>>
>>>
>>>         We propose that naming of subclasses of
>>>         "java/lang/reflect/Proxy" should not be dependent upon the
>>>         order of loading. In order to do so, two issues can be fixed:
>>>
>>>          1. The naming of the class should not be based on AtomicLong
>>>             <https://github.com/openjdk/jdk/blob/b687aa550837830b38f0f0faa69c353b1e85219c/src/java.base/share/classes/java/lang/reflect/Proxy.java#L531 <https://github.com/openjdk/jdk/blob/b687aa550837830b38f0f0faa69c353b1e85219c/src/java.base/share/classes/java/lang/reflect/Proxy.java#L531>>. Rather it could be named based on the interfaces it implements. I also wonder why AtomicLong is chosen in the first place.
>>>          2. Methods of the interfaces must be in a particular order.
>>>             Right now, they are not sorted in any particular order
>>>             <https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/lang/Class.java#L2178 <https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/lang/Class.java#L2178>>.
>>>
>>>
>>>         These fixes will make proxy class generation deterministic
>>>         with respect to order of loading and won't be flagged at
>>>         runtime since the test suite would already detect them.
>>>
>>>         I would love to hear from the community about these ideas. If
>>>         in agreement, I would be happy to produce a patch. I have
>>>         discovered this issue with subclasses of
>>>         GeneratedConstructorAccessor
>>>         <https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/jdk/internal/reflect/ConstructorAccessor.java <https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/jdk/internal/reflect/ConstructorAccessor.java>> as well and I imagine it will also apply to some other runtime generated classes. If you disagree, please let me know also. It helps with my research.
>>>
>>>         I also have PoCs for the above CVEs
>>>         <https://github.com/chains-project/exploits-for-sbom.exe
> <https://github.com/chains-project/exploits-for-sbom.exe>> and
>>>         a proof concept tool is being developed under the name
>>>         sbom.exe <https://github.com/chains-project/sbom.exe
> <https://github.com/chains-project/sbom.exe>> in case
>>>         any one wonders about the implementation. I would also be
>>>         happy to explain more.
>>>
>>>         Regards,
>>>         Aman Sharma
>>>
>>>         PhD Student
>>>         KTH Royal Institute of Technology
>>>         School of Electrical Engineering and Computer Science (EECS)
>>>         Department of Theoretical Computer Science (TCS)
>>>         <https://www.kth.se/profile/amansha
> <https://www.kth.se/profile/amansha>>https://algomaster99.github.io/
> <https://algomaster99.github.io/ <https://algomaster99.github.io/>>
>>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240522/39a71b5c/attachment-0001.htm>

From psandoz at openjdk.org  Wed May 22 18:21:02 2024
From: psandoz at openjdk.org (Paul Sandoz)
Date: Wed, 22 May 2024 18:21:02 GMT
Subject: RFR: 8331196: vector api: Remove unnecessary index check in
 Byte/ShortVector.fromArray/fromArray0Template
In-Reply-To: <YLwvFU3XpoutOZCBehEbDwlkkucrAbHv1mF8K9zzDH0=.b49d1661-adac-4a96-b013-84f1b4dd7fcf@github.com>
References: <YLwvFU3XpoutOZCBehEbDwlkkucrAbHv1mF8K9zzDH0=.b49d1661-adac-4a96-b013-84f1b4dd7fcf@github.com>
Message-ID: <8Pa1L6q9-HAb2YJWiLklTlq7R1FbwHWdD1lBscJqTZs=.b141c6b4-c628-4fa2-b43c-3d3388c31e5b@github.com>

On Fri, 26 Apr 2024 14:06:02 GMT, Hamlin Li <mli at openjdk.org> wrote:

> Hi,
> Can you help to review this simple patch?
> Some index check in Byte/ShortVector.fromArray/fromArray0Template seems not necessary, could be removed.
> Thanks

The intrinsic implementation will not perform bounds checks. I think what you may be observing is the result of bounds checks when Java code is interpreted (or perhaps from compiled C1 code). You need to first ensure the code is compiled to C2 before executing with out of bounds values.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18977#issuecomment-2125465612

From prappo at openjdk.org  Wed May 22 18:38:27 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Wed, 22 May 2024 18:38:27 GMT
Subject: RFR: 8332084: Ensure JdkConsoleImpl.restoreEcho visibility in a
 shutdown hook [v8]
In-Reply-To: <3wqzT0bRvcYKv_nM7cvp3crD7Mdi6DtoTAbp5ojlg64=.b0ca72b7-4915-4c91-bc22-e2d06817b37c@github.com>
References: <9JTWc3FRpfbILlSHlmIU_dL5IE69RTxnSIAOdIte15I=.5854a48f-21d7-42c9-adb7-5e3ed40d1211@github.com>
 <s5UWj1VnzkiOOPZk8YMuJrbyAoMx-pVeV14Cx5UDZeE=.495ed70f-3dd5-4c4d-a616-0f20fcb92907@github.com>
 <3wqzT0bRvcYKv_nM7cvp3crD7Mdi6DtoTAbp5ojlg64=.b0ca72b7-4915-4c91-bc22-e2d06817b37c@github.com>
Message-ID: <Sp1JCcgo-YVhpp8ySXyVST5iyC0FDWzXmhgHcASDB4M=.1fee6124-cf1e-4d33-94f1-b4dbebe55e51@github.com>

On Wed, 22 May 2024 17:20:02 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Hi Pavel,
> 
> > If I read [this](https://docs.oracle.com/en/java/javase/22/docs/api/java.base/java/lang/Runtime.html#shutdown) correctly, due to the mechanics of JVM exit, we simply don't know which thread finishes first: a thread that calls `readPassword` or the shutdown hook.
> 
> IIUC, the thread that waits on `readPassword()` is not a shutdown hook, right? Then I think it is guaranteed that it is still waiting when all the shutdown hooks are executed.
> 
> > If the shutdown hook finishes first, then a `readPassword` thread can corrupt the state: unlike the shutdown hook, which JVM _normally has to wait to complete_, the `readPassword` thread can be terminated at any moment. It might as well be terminated before `finally` but after `echo(false)`, in which case we end up with echo turned off.
> 
> After the shutdown hooks finish, then the VM is terminated (https://docs.oracle.com/en/java/javase/22/docs/api/java.base/java/lang/Runtime.html#termination). In there:
> 
> ```
> finally clauses are not executed;
> ```
> 
> So I think the shutdown hook's restoreEcho has the final say, sans the situation if some app installs a shutdown hook with `readPassword` but I don't think we can guarantee that case, and I believe it is OK.

I might be confused, but what if the shutdown hook completes and then some application thread enters `readPassword`. If that thread manages to turn off echo before all other shutdown hooks complete, it might never execute `finally`, hence a race.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19184#issuecomment-2125497081

From philip.race at oracle.com  Wed May 22 18:41:23 2024
From: philip.race at oracle.com (Philip Race)
Date: Wed, 22 May 2024 11:41:23 -0700
Subject: stack overflow in regex engine
In-Reply-To: <CH3PR12MB7619677F346E734C75AA6086F9EB2@CH3PR12MB7619.namprd12.prod.outlook.com>
References: <CH3PR12MB76197D4ECC54728844CE705CF9EB2@CH3PR12MB7619.namprd12.prod.outlook.com>
 <5b8019db-c9ac-4e4a-9452-20e477c5ec5e@oracle.com>
 <CH3PR12MB7619677F346E734C75AA6086F9EB2@CH3PR12MB7619.namprd12.prod.outlook.com>
Message-ID: <0bd0cc4b-cd78-4d43-9b31-ff90bd5253a2@oracle.com>



On 5/22/24 10:51 AM, mark.yagnatinsky at barclays.com wrote:
>
> Ah, didn?t realize P4 is default; that makes sense.
>
> So I should not even be trying to derive omens from that.
>
> So I guess only the assignee would know whether or not the status is 
> closer to
>
> ?I was going to work on that next week? versus
>
> ?I totally forgot about that thing, and am about to forget about it again?
>
> I?m quite sure he?s on this list and will hopefully read the advocacy 
> section of my email.
>
> Um.? I feel awkward writing this paragraph because you know how 
> OpenJDK works much better than I do, so it feels a bit silly to argue 
> with you about it.? But.? Um.
>
> When you say ?this is not the place to ask for fixes? ?
>
> I was under the impression that ?asking for fixes? actually does 
> provide value, and not all of that value can be replaced by merely 
> providing fixes.
>
> In particular, asking for fixes gives maintainers a vague sense of how 
> often people in the ?real world? tend to run into an issue, which in 
> turn informs how much ?cost? is worth spending on addressing it.
>
> (Where ?cost? could mean things like ?time? and also things like ?this 
> makes trickier and hence harder to maintain?.)
>
> In fact, I was under the impression that OpenJDK is slightly hostile 
> to ?big? fixes by ?outsiders? because of the worry that there?s now a 
> big/complicated chunk of code that no one inside the project 
> understands and yet the project is responsible for, and the original 
> author might never be heard from again.
>

I think that is mainly the case for some new feature.
Or if you want to take some existing feature / functionality and 
re-write it in a different way.

True "bug fixes" to existing code are generally welcome, although that 
isn't the same as saying
they are quickly accepted.? They still need review and testing, and if 
the area is sensitive or complex that
can be quite time consuming on all ends of it. Which would all also be 
the case even if an
experienced contributor provided the fix.

-phil.

> Anyway, thanks a bunch for responding; I was worried that no one would.
>
> *From:*Philip Race <philip.race at oracle.com>
> *Sent:* Wednesday, May 22, 2024 11:54 AM
> *To:* Yagnatinsky, Mark : IT (NYK) <mark.yagnatinsky at barclays.com>; 
> core-libs-dev at openjdk.org
> *Subject:* Re: stack overflow in regex engine
>
> CAUTION: This email originated from outside our organisation - 
> philip.race at oracle.com Do not click on links, open attachments, or 
> respond unless you recognize the sender and can validate the content 
> is safe.
>
> P4 is the default JBS priority, so sometimes it just means no one 
> figured out the true priority.
> But in general P4 bugs could be open for years, or even never get fixed.
> The priority is also partially an assessment of where it falls as a 
> priority for the JDK developers.
> A user of JDK may have an entirely different perspective.
> And that's why there are vendors who provide support for JDK. They can 
> also arrange the backports you need.
> But that's not done here. Here is where you come to participate and 
> contribute fixes, not ask for fixes.
> So my suggestion is to raise it via your support channel to your 
> particular vendor who provided your binary.
>
> -phil
>
> On 5/21/24 8:46 PM, mark.yagnatinsky at barclays.com wrote:
>
>     (Sorry about my previous ?do I need to subscribe?? email; in
>     retrospect that was needless noise.)
>
>     The purpose of this email is twofold: first, inquire about the
>     status of ticket filed a few years ago, and second to point out
>     some non-obvious reasons why it might be slightly more serious
>     than it seems.
>
>     The ticket is this one https://bugs.openjdk.org/browse/JDK-8260866
>     <https://clicktime.symantec.com/15t5ekSGXorRH53n7q6GJ?h=e9ZmDJOAdCkeHz_PXjDgZiyUdvJmTZTTcGvZoAULMmE=&u=https://bugs.openjdk.org/browse/JDK-8260866>
>     (stack overflow in regex matching quantified alternation)
>
>     The priority is listed as P4, which I guess means something like
>     ?medium? (more important than p5, but less than p3)
>
>     It also has a specific person assigned, which seems vaguely
>     encouraging, but no updates at all in the years since it?s been
>     created, which seems less encouraging.
>
>     It was seemingly never once discussed on this mailing list, not
>     even when it was first filed.
>
>     As an outsider, I?m not quite sure how to interpret all these
>     various omens and turn them into guesses about its eventual fate.
>
>     Will it remain unfixed for another decade or two?? Will it be
>     fixed in a few months, but then never backported to old versions??
>     Something else?? No one knows?
>
>     That concludes the status inquiry.? Now on to the advocacy.? Some
>     bugs are annoying, but once you hit them, you can work around them
>     by changing your code so it does not trigger the bug.
>
>     Note the phrase ?your code? above.? This is much more awkward to
>     do if the bug triggered by third-party code you got from maven
>     central or something.
>
>     At that point your options are to either ask the third party
>     library to work around it, or else fork the dependency (which is
>     not well supported by mainstream build tools (or maybe I?m just
>     using them wrong)).
>
>     In this case, regular expressions are so ubiquitous that the bug
>     is quite plausibly more likely to be triggered by some third party
>     dependency than by code you own.
>
>     That was the case for me today: after spending hours trying to
>     track down a stack overflow error I found the offending regex in a
>     third party library.
>
>     The good news is that for the kinds of inputs we need to handle,
>     it is indeed easy to substitute a much simpler regex that would
>     avoid the issue.
>
>     The bad news is that it?s not my code, so I can?t.? I could
>     petition the maintainers of the library, but this is not great
>     because:
>
>     First, maybe the version I?m on is not longer even supported, and
>     newer versions are not compatible,
>
>     Second, it may take them a while to fix it, and third, it is
>     wasteful (and inelegant) to have workarounds slowly percolate
>     throughout the Java ecosystem instead of fixing the problem at the
>     root.
>
>     The other annoying thing here is that even when you have ?enough?
>     stack space to avoid crashing, using it may not be quite ?free?.
>
>     For instance, project loom?s foundational premise seems to be that
>     ?most threads have oversized stacks; we can have more threads if
>     we start off with small stacks and grow them only when needed?.
>
>     This would be false when the thread in question uses a regex with
>     quantified alternation.
>
>     (Since many Loom threads will be based on the same Runnable, it?s
>     a pretty safe bet that if one of them uses this feature, many
>     will, so you can?t assume it will ?average out?.)
>
>     There are other reasons besides loom to be low on stack space;
>     maybe you?re using some crazy framework(s) that like(s) to have
>     call stacks that are crazy deep.
>
>     Or maybe you?re running with -Xss set pretty low.? Or you passed a
>     small value for stack space to the Thread constructor.
>
>     Or maybe none of these things are true, but in most operating
>     systems a thread stack costs ?real? memory in proportion to its
>     high-watermark, so even a SINGLE heavy regex in the lifetime of a
>     thread is tantamount to a memory leak of hundreds of kilobytes.
>
>     Practicalities aside, I don?t like it when code consumes
>     ?surprising? types of resources, or surprising amounts of them.
>
>     For instance, you wouldn?t expect a sorting function to spawn
>     threads behind your back, unless it was called ?parallel sort? or
>     something like that.
>
>     You wouldn?t expect it to allocate multi-gigabyte arrays, nor to
>     perform I/O.
>
>     Similarly, most functions need only O(1) stack space, so this
>     tends to be the default assumption unless the docs explicitly call
>     out ?this thing might throw stack overflows at you so make sure
>     you have plenty of stack space?
>
>     Some need a bit more? for instance, I would not be surprised if a
>     regex need stack space in proportion to the depth of the parse
>     tree of the regex.
>
>     But stack space in proportion to the length of the string being
>     matched is the kind of thing that I?d hope gets called out in
>     those @implNotes thingies, or better yet fixed.
>
>     Even people who know that regex matching can sometimes take
>     exponential time may naively assume that regex matching would not
>     consume O(n) stack space, where n is the input length.
>
>     What?s worse, not only does it indeed consume stack space linear
>     in the length of the input, but the constant hidden by the O()
>     notation is itself pretty scary.
>
>     For instance, consider the regex that caused my troubles today:
>
>     https://github.com/apache/camel/blob/main/core/camel-support/src/main/java/org/apache/camel/support/ObjectHelper.java#L63
>     <https://clicktime.symantec.com/15t5jadYzRY1h1shfPVQv?h=nT81oCo1qZ8nsQ8sI9SyBtH8DOuudlSAMaXkeKhYmgU=&u=https://github.com/apache/camel/blob/main/core/camel-support/src/main/java/org/apache/camel/support/ObjectHelper.java%23L63>
>
>     After getting rid of extra escaping and also double-escaping
>     caused by java not having ?raw? strings, we?re left with this:
>
>     ,(?!(?:[^(,]|[^)],[^)])+\))
>
>     (I find the above hard to read; the regex I would have replaced it
>     with, if it had been ?our? code is simply a single comma.)
>
>     Anyway, I tried creating a Scanner with the delimiter above and
>     looping through all the tokens in the string that originally
>     caused the crash.
>
>     I thought that perhaps it would work, since I had a simple example
>     that does everything in main, but it also crashed.
>
>     Then I decided to play an alternating game where I trimmed the
>     string until it stopped crashing, then lowered Xss by 64k and
>     repeated.
>
>     Eventually, I got it crashing with a call stack well over 500
>     calls deep on a string less than a 128 characters long.
>
>     (The string was not hand-crafted; it was simply a prefix of the
>     original string that caused the first crash I tracked down.)
>
>     The string in question had a mere five tokens, which is to say
>     that it had just four commas.
>
>     It had no open or close parenthesis, so the entire negative
>     lookahead assertion served as a giant no-op, at least when it
>     wasn?t crashing.
>
>     (Technically, the stack usage is linear in the length of the input
>     AFTER the first comma, but the first comma was pretty early.)
>
>     Sorry if this email is poorly organized; I?ve already spent way
>     too many hours on it (not even counting the debugging that
>     prompted it) and I need to get some sleep now.
>
>     If anyone actually reads all or most of this, thank you.
>
>     Mark.
>
>     P.S. if anyone actually responds, thank you even more.
>
>     This message is for information purposes only. It is not a
>     recommendation, advice, offer or solicitation to buy or sell a
>     product or service, nor an official confirmation of any
>     transaction. It is directed at persons who are professionals and
>     is intended for the recipient(s) only. It is not directed at
>     retail customers. This message is subject to the terms at:
>     https://www.ib.barclays/disclosures/web-and-email-disclaimer.html
>     <https://clicktime.symantec.com/15t69jbyHVwykk1KPBVA2?h=WSydRJ-8a9jEVWGSLyCrdLEU7Xfx-K-gu16DAstEYWQ=&u=https://www.ib.barclays/disclosures/web-and-email-disclaimer.html>.
>
>
>     For important disclosures, please see:
>     https://www.ib.barclays/disclosures/sales-and-trading-disclaimer.html
>     <https://clicktime.symantec.com/15t64uQgptGPLoBPqd61Q?h=sYkJo73WS5C5wTtskVoUQEfn7gI-sb4yDI0khVoYK3Q=&u=https://www.ib.barclays/disclosures/sales-and-trading-disclaimer.html>
>     regarding marketing commentary from Barclays Sales and/or Trading
>     desks, who are active market participants;
>     https://www.ib.barclays/disclosures/barclays-global-markets-disclosures.html
>     <https://clicktime.symantec.com/15t5pQpqT3Dc6xhdCwtZY?h=qVJHSoTdp0pI-_4TT9h4U49uHhqWqUQdMGYEdhG-Ouo=&u=https://www.ib.barclays/disclosures/barclays-global-markets-disclosures.html>
>     regarding our standard terms for Barclays Investment Bank where we
>     trade with you in principal-to-principal wholesale markets
>     transactions; and in respect to Barclays Research, including
>     disclosures relating to specific issuers, see:
>     http://publicresearch.barclays.com
>     <https://clicktime.symantec.com/15t5ZvEz5CAps8DraGh7g?h=87QBG12g6Fm-478KIe1pp-nBD10MhX6JgAq8TwQi770=&u=http://publicresearch.barclays.com>.
>     __________________________________________________________________________________
>
>     If you are incorporated or operating in Australia, read these
>     important disclosures:
>     https://www.ib.barclays/disclosures/important-disclosures-asia-pacific.html
>     <https://clicktime.symantec.com/15t5uF27ueuCWuXYkWHiA?h=GPXVMoOv512jLvxDhIJnWdewKcbTe5uGye3MLfO8Uxc=&u=https://www.ib.barclays/disclosures/important-disclosures-asia-pacific.html>.
>     __________________________________________________________________________________
>     For more details about how we use personal information, see our
>     privacy notice:
>     https://www.ib.barclays/disclosures/personal-information-use.html
>     <https://clicktime.symantec.com/15t5z5DQNGanvrMUJ4grn?h=zIClmLbPkrAGRja2m5HovRZhDKBBGmDTQHvE9kjAkxQ=&u=https://www.ib.barclays/disclosures/personal-information-use.html>.
>
>     __________________________________________________________________________________
>
> This message is for information purposes only. It is not a 
> recommendation, advice, offer or solicitation to buy or sell a product 
> or service, nor an official confirmation of any transaction. It is 
> directed at persons who are professionals and is intended for the 
> recipient(s) only. It is not directed at retail customers. This 
> message is subject to the terms at: 
> https://www.ib.barclays/disclosures/web-and-email-disclaimer.html.
>
> For important disclosures, please see: 
> https://www.ib.barclays/disclosures/sales-and-trading-disclaimer.html 
> regarding marketing commentary from Barclays Sales and/or Trading 
> desks, who are active market participants; 
> https://www.ib.barclays/disclosures/barclays-global-markets-disclosures.html 
> regarding our standard terms for Barclays Investment Bank where we 
> trade with you in principal-to-principal wholesale markets 
> transactions; and in respect to Barclays Research, including 
> disclosures relating to specific issuers, see: 
> http://publicresearch.barclays.com.
> __________________________________________________________________________________ 
>
> If you are incorporated or operating in Australia, read these 
> important disclosures: 
> https://www.ib.barclays/disclosures/important-disclosures-asia-pacific.html.
> __________________________________________________________________________________
> For more details about how we use personal information, see our 
> privacy notice: 
> https://www.ib.barclays/disclosures/personal-information-use.html.
> __________________________________________________________________________________
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240522/8c1e72f6/attachment-0001.htm>

From mark.yagnatinsky at barclays.com  Wed May 22 18:43:13 2024
From: mark.yagnatinsky at barclays.com (mark.yagnatinsky at barclays.com)
Date: Wed, 22 May 2024 18:43:13 +0000
Subject: stack overflow in regex engine
In-Reply-To: <0bd0cc4b-cd78-4d43-9b31-ff90bd5253a2@oracle.com>
References: <CH3PR12MB76197D4ECC54728844CE705CF9EB2@CH3PR12MB7619.namprd12.prod.outlook.com>
 <5b8019db-c9ac-4e4a-9452-20e477c5ec5e@oracle.com>
 <CH3PR12MB7619677F346E734C75AA6086F9EB2@CH3PR12MB7619.namprd12.prod.outlook.com>
 <0bd0cc4b-cd78-4d43-9b31-ff90bd5253a2@oracle.com>
Message-ID: <CH3PR12MB761933B54D58180FEF49BD35F9EB2@CH3PR12MB7619.namprd12.prod.outlook.com>

Makes sense, thanks!

From: Philip Race <philip.race at oracle.com>
Sent: Wednesday, May 22, 2024 2:41 PM
To: Yagnatinsky, Mark : IT (NYK) <mark.yagnatinsky at barclays.com>; core-libs-dev at openjdk.org
Subject: Re: stack overflow in regex engine


CAUTION: This email originated from outside our organisation - philip.race at oracle.com<mailto:philip.race at oracle.com> Do not click on links, open attachments, or respond unless you recognize the sender and can validate the content is safe.

On 5/22/24 10:51 AM, mark.yagnatinsky at barclays.com<mailto:mark.yagnatinsky at barclays.com> wrote:
Ah, didn't realize P4 is default; that makes sense.
So I should not even be trying to derive omens from that.
So I guess only the assignee would know whether or not the status is closer to
"I was going to work on that next week" versus
"I totally forgot about that thing, and am about to forget about it again"
I'm quite sure he's on this list and will hopefully read the advocacy section of my email.

Um.  I feel awkward writing this paragraph because you know how OpenJDK works much better than I do, so it feels a bit silly to argue with you about it.  But.  Um.
When you say "this is not the place to ask for fixes" ...
I was under the impression that "asking for fixes" actually does provide value, and not all of that value can be replaced by merely providing fixes.
In particular, asking for fixes gives maintainers a vague sense of how often people in the "real world" tend to run into an issue, which in turn informs how much "cost" is worth spending on addressing it.
(Where "cost" could mean things like "time" and also things like "this makes trickier and hence harder to maintain".)
In fact, I was under the impression that OpenJDK is slightly hostile to "big" fixes by "outsiders" because of the worry that there's now a big/complicated chunk of code that no one inside the project understands and yet the project is responsible for, and the original author might never be heard from again.

I think that is mainly the case for some new feature.
Or if you want to take some existing feature / functionality and re-write it in a different way.

True "bug fixes" to existing code are generally welcome, although that isn't the same as saying
they are quickly accepted.  They still need review and testing, and if the area is sensitive or complex that
can be quite time consuming on all ends of it. Which would all also be the case even if an
experienced contributor provided the fix.

-phil.



Anyway, thanks a bunch for responding; I was worried that no one would.

From: Philip Race <philip.race at oracle.com><mailto:philip.race at oracle.com>
Sent: Wednesday, May 22, 2024 11:54 AM
To: Yagnatinsky, Mark : IT (NYK) <mark.yagnatinsky at barclays.com><mailto:mark.yagnatinsky at barclays.com>; core-libs-dev at openjdk.org<mailto:core-libs-dev at openjdk.org>
Subject: Re: stack overflow in regex engine


CAUTION: This email originated from outside our organisation - philip.race at oracle.com<mailto:philip.race at oracle.com> Do not click on links, open attachments, or respond unless you recognize the sender and can validate the content is safe.
P4 is the default JBS priority, so sometimes it just means no one figured out the true priority.
But in general P4 bugs could be open for years, or even never get fixed.
The priority is also partially an assessment of where it falls as a priority for the JDK developers.
A user of JDK may have an entirely different perspective.
And that's why there are vendors who provide support for JDK. They can also arrange the backports you need.
But that's not done here. Here is where you come to participate and contribute fixes, not ask for fixes.
So my suggestion is to raise it via your support channel to your particular vendor who provided your binary.

-phil
On 5/21/24 8:46 PM, mark.yagnatinsky at barclays.com<mailto:mark.yagnatinsky at barclays.com> wrote:
(Sorry about my previous "do I need to subscribe?" email; in retrospect that was needless noise.)
The purpose of this email is twofold: first, inquire about the status of ticket filed a few years ago, and second to point out some non-obvious reasons why it might be slightly more serious than it seems.
The ticket is this one https://bugs.openjdk.org/browse/JDK-8260866<https://clicktime.symantec.com/15t5ekSGXorRH53n7q6GJ?h=e9ZmDJOAdCkeHz_PXjDgZiyUdvJmTZTTcGvZoAULMmE=&u=https://bugs.openjdk.org/browse/JDK-8260866> (stack overflow in regex matching quantified alternation)
The priority is listed as P4, which I guess means something like "medium" (more important than p5, but less than p3)
It also has a specific person assigned, which seems vaguely encouraging, but no updates at all in the years since it's been created, which seems less encouraging.
It was seemingly never once discussed on this mailing list, not even when it was first filed.
As an outsider, I'm not quite sure how to interpret all these various omens and turn them into guesses about its eventual fate.
Will it remain unfixed for another decade or two?  Will it be fixed in a few months, but then never backported to old versions?  Something else?  No one knows?

That concludes the status inquiry.  Now on to the advocacy.  Some bugs are annoying, but once you hit them, you can work around them by changing your code so it does not trigger the bug.
Note the phrase "your code" above.  This is much more awkward to do if the bug triggered by third-party code you got from maven central or something.
At that point your options are to either ask the third party library to work around it, or else fork the dependency (which is not well supported by mainstream build tools (or maybe I'm just using them wrong)).
In this case, regular expressions are so ubiquitous that the bug is quite plausibly more likely to be triggered by some third party dependency than by code you own.
That was the case for me today: after spending hours trying to track down a stack overflow error I found the offending regex in a third party library.
The good news is that for the kinds of inputs we need to handle, it is indeed easy to substitute a much simpler regex that would avoid the issue.
The bad news is that it's not my code, so I can't.  I could petition the maintainers of the library, but this is not great because:
First, maybe the version I'm on is not longer even supported, and newer versions are not compatible,
Second, it may take them a while to fix it, and third, it is wasteful (and inelegant) to have workarounds slowly percolate throughout the Java ecosystem instead of fixing the problem at the root.

The other annoying thing here is that even when you have "enough" stack space to avoid crashing, using it may not be quite "free".
For instance, project loom's foundational premise seems to be that "most threads have oversized stacks; we can have more threads if we start off with small stacks and grow them only when needed".
This would be false when the thread in question uses a regex with quantified alternation.
(Since many Loom threads will be based on the same Runnable, it's a pretty safe bet that if one of them uses this feature, many will, so you can't assume it will "average out".)
There are other reasons besides loom to be low on stack space; maybe you're using some crazy framework(s) that like(s) to have call stacks that are crazy deep.
Or maybe you're running with -Xss set pretty low.  Or you passed a small value for stack space to the Thread constructor.
Or maybe none of these things are true, but in most operating systems a thread stack costs "real" memory in proportion to its high-watermark, so even a SINGLE heavy regex in the lifetime of a thread is tantamount to a memory leak of hundreds of kilobytes.

Practicalities aside, I don't like it when code consumes "surprising" types of resources, or surprising amounts of them.
For instance, you wouldn't expect a sorting function to spawn threads behind your back, unless it was called "parallel sort" or something like that.
You wouldn't expect it to allocate multi-gigabyte arrays, nor to perform I/O.
Similarly, most functions need only O(1) stack space, so this tends to be the default assumption unless the docs explicitly call out "this thing might throw stack overflows at you so make sure you have plenty of stack space"
Some need a bit more... for instance, I would not be surprised if a regex need stack space in proportion to the depth of the parse tree of the regex.
But stack space in proportion to the length of the string being matched is the kind of thing that I'd hope gets called out in those @implNotes thingies, or better yet fixed.

Even people who know that regex matching can sometimes take exponential time may naively assume that regex matching would not consume O(n) stack space, where n is the input length.
What's worse, not only does it indeed consume stack space linear in the length of the input, but the constant hidden by the O() notation is itself pretty scary.
For instance, consider the regex that caused my troubles today:
https://github.com/apache/camel/blob/main/core/camel-support/src/main/java/org/apache/camel/support/ObjectHelper.java#L63<https://clicktime.symantec.com/15t5jadYzRY1h1shfPVQv?h=nT81oCo1qZ8nsQ8sI9SyBtH8DOuudlSAMaXkeKhYmgU=&u=https://github.com/apache/camel/blob/main/core/camel-support/src/main/java/org/apache/camel/support/ObjectHelper.java%23L63>
After getting rid of extra escaping and also double-escaping caused by java not having "raw" strings, we're left with this:
,(?!(?:[^(,]|[^)],[^)])+\))
(I find the above hard to read; the regex I would have replaced it with, if it had been "our" code is simply a single comma.)
Anyway, I tried creating a Scanner with the delimiter above and looping through all the tokens in the string that originally caused the crash.
I thought that perhaps it would work, since I had a simple example that does everything in main, but it also crashed.
Then I decided to play an alternating game where I trimmed the string until it stopped crashing, then lowered Xss by 64k and repeated.
Eventually, I got it crashing with a call stack well over 500 calls deep on a string less than a 128 characters long.
(The string was not hand-crafted; it was simply a prefix of the original string that caused the first crash I tracked down.)
The string in question had a mere five tokens, which is to say that it had just four commas.
It had no open or close parenthesis, so the entire negative lookahead assertion served as a giant no-op, at least when it wasn't crashing.
(Technically, the stack usage is linear in the length of the input AFTER the first comma, but the first comma was pretty early.)

Sorry if this email is poorly organized; I've already spent way too many hours on it (not even counting the debugging that prompted it) and I need to get some sleep now.

If anyone actually reads all or most of this, thank you.
Mark.

P.S. if anyone actually responds, thank you even more.

This message is for information purposes only. It is not a recommendation, advice, offer or solicitation to buy or sell a product or service, nor an official confirmation of any transaction. It is directed at persons who are professionals and is intended for the recipient(s) only. It is not directed at retail customers. This message is subject to the terms at: https://www.ib.barclays/disclosures/web-and-email-disclaimer.html<https://clicktime.symantec.com/15t69jbyHVwykk1KPBVA2?h=WSydRJ-8a9jEVWGSLyCrdLEU7Xfx-K-gu16DAstEYWQ=&u=https://www.ib.barclays/disclosures/web-and-email-disclaimer.html>.

For important disclosures, please see: https://www.ib.barclays/disclosures/sales-and-trading-disclaimer.html<https://clicktime.symantec.com/15t64uQgptGPLoBPqd61Q?h=sYkJo73WS5C5wTtskVoUQEfn7gI-sb4yDI0khVoYK3Q=&u=https://www.ib.barclays/disclosures/sales-and-trading-disclaimer.html> regarding marketing commentary from Barclays Sales and/or Trading desks, who are active market participants; https://www.ib.barclays/disclosures/barclays-global-markets-disclosures.html<https://clicktime.symantec.com/15t5pQpqT3Dc6xhdCwtZY?h=qVJHSoTdp0pI-_4TT9h4U49uHhqWqUQdMGYEdhG-Ouo=&u=https://www.ib.barclays/disclosures/barclays-global-markets-disclosures.html> regarding our standard terms for Barclays Investment Bank where we trade with you in principal-to-principal wholesale markets transactions; and in respect to Barclays Research, including disclosures relating to specific issuers, see: http://publicresearch.barclays.com<https://clicktime.symantec.com/15t5ZvEz5CAps8DraGh7g?h=87QBG12g6Fm-478KIe1pp-nBD10MhX6JgAq8TwQi770=&u=http://publicresearch.barclays.com>.
__________________________________________________________________________________
If you are incorporated or operating in Australia, read these important disclosures: https://www.ib.barclays/disclosures/important-disclosures-asia-pacific.html<https://clicktime.symantec.com/15t5uF27ueuCWuXYkWHiA?h=GPXVMoOv512jLvxDhIJnWdewKcbTe5uGye3MLfO8Uxc=&u=https://www.ib.barclays/disclosures/important-disclosures-asia-pacific.html>.
__________________________________________________________________________________
For more details about how we use personal information, see our privacy notice: https://www.ib.barclays/disclosures/personal-information-use.html<https://clicktime.symantec.com/15t5z5DQNGanvrMUJ4grn?h=zIClmLbPkrAGRja2m5HovRZhDKBBGmDTQHvE9kjAkxQ=&u=https://www.ib.barclays/disclosures/personal-information-use.html>.
__________________________________________________________________________________


This message is for information purposes only. It is not a recommendation, advice, offer or solicitation to buy or sell a product or service, nor an official confirmation of any transaction. It is directed at persons who are professionals and is intended for the recipient(s) only. It is not directed at retail customers. This message is subject to the terms at: https://www.ib.barclays/disclosures/web-and-email-disclaimer.html<https://clicktime.symantec.com/15sifMQo6NFuxonBGDD2R?h=31fYxBBeUOOcLbK3-e657_6iHQUS6TtBlndj-VGquns=&u=https://www.ib.barclays/disclosures/web-and-email-disclaimer.html>.

For important disclosures, please see: https://www.ib.barclays/disclosures/sales-and-trading-disclaimer.html<https://clicktime.symantec.com/15siaXDWdkaKYrxFieoso?h=jKNuBVm6laQKbpEUm0zMNvvU1n_jpYm3w2v0Nkzq6dg=&u=https://www.ib.barclays/disclosures/sales-and-trading-disclaimer.html> regarding marketing commentary from Barclays Sales and/or Trading desks, who are active market participants; https://www.ib.barclays/disclosures/barclays-global-markets-disclosures.html<https://clicktime.symantec.com/15siL2dfFuXYK2UV5ycRw?h=G6kTP1UjUXt3E_gfu3CFEScfkpWPORqYHslnKJcLauQ=&u=https://www.ib.barclays/disclosures/barclays-global-markets-disclosures.html> regarding our standard terms for Barclays Investment Bank where we trade with you in principal-to-principal wholesale markets transactions; and in respect to Barclays Research, including disclosures relating to specific issuers, see: http://publicresearch.barclays.com<https://clicktime.symantec.com/15siFCSNoHqwu5eZYRDHK?h=lXRZeobWtIYWvHze-aRlbEmu1uG0vZkRDmAuIelzvdQ=&u=http://publicresearch.barclays.com>.
__________________________________________________________________________________
If you are incorporated or operating in Australia, read these important disclosures: https://www.ib.barclays/disclosures/important-disclosures-asia-pacific.html<https://clicktime.symantec.com/15siQrpwiXD8iyJQdY1aZ?h=Pk08CG7ur_J5mBFzfvdiE7GcyHAtB-EQP-5ljSfnUe4=&u=https://www.ib.barclays/disclosures/important-disclosures-asia-pacific.html>.
__________________________________________________________________________________
For more details about how we use personal information, see our privacy notice: https://www.ib.barclays/disclosures/personal-information-use.html<https://clicktime.symantec.com/15siVh2EB8tj8v8LB6QjB?h=rNPopxxkHimMlRPW8JLyQJHFB5e78_YehatoCTCfUqo=&u=https://www.ib.barclays/disclosures/personal-information-use.html>.
__________________________________________________________________________________


This message is for information purposes only. It is not a recommendation, advice, offer or solicitation to buy or sell a product or service, nor an official confirmation of any transaction. It is directed at persons who are professionals and is intended for the recipient(s) only. It is not directed at retail customers. This message is subject to the terms at: https://www.ib.barclays/disclosures/web-and-email-disclaimer.html. 

For important disclosures, please see: https://www.ib.barclays/disclosures/sales-and-trading-disclaimer.html regarding marketing commentary from Barclays Sales and/or Trading desks, who are active market participants; https://www.ib.barclays/disclosures/barclays-global-markets-disclosures.html regarding our standard terms for Barclays Investment Bank where we trade with you in principal-to-principal wholesale markets transactions; and in respect to Barclays Research, including disclosures relating to specific issuers, see: http://publicresearch.barclays.com.
__________________________________________________________________________________ 
If you are incorporated or operating in Australia, read these important disclosures: https://www.ib.barclays/disclosures/important-disclosures-asia-pacific.html.
__________________________________________________________________________________
For more details about how we use personal information, see our privacy notice: https://www.ib.barclays/disclosures/personal-information-use.html. 
__________________________________________________________________________________
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240522/7f33af1f/attachment-0001.htm>

From sgibbons at openjdk.org  Wed May 22 18:44:21 2024
From: sgibbons at openjdk.org (Scott Gibbons)
Date: Wed, 22 May 2024 18:44:21 GMT
Subject: RFR: 8320448: Accelerate IndexOf using AVX2 [v26]
In-Reply-To: <uWi4QxH31hL93771gkl_GgvP0m84IRSoR_1Yi8hD17E=.bc6ed458-7081-4c3f-9348-f59358fa05a4@github.com>
References: <uWi4QxH31hL93771gkl_GgvP0m84IRSoR_1Yi8hD17E=.bc6ed458-7081-4c3f-9348-f59358fa05a4@github.com>
Message-ID: <FKcOLaTCZFoCq4ylzeZFgCC63xoKeWpR4mHfZXyYO8Y=.334da063-3146-41b1-984f-a2183c273e63@github.com>

> Re-write the IndexOf code without the use of the pcmpestri instruction, only using AVX2 instructions.  This change accelerates String.IndexOf on average 1.3x for AVX2.  The benchmark numbers:
> 
> 
> Benchmark	                                               Score		Latest		
> StringIndexOf.advancedWithMediumSub   343.573		317.934		0.925375393x
> StringIndexOf.advancedWithShortSub1	  1039.081		1053.96		1.014319384x
> StringIndexOf.advancedWithShortSub2	      55.828		110.541		1.980027943x
> StringIndexOf.constantPattern	                9.361		11.906		1.271872663x
> StringIndexOf.searchCharLongSuccess	        4.216		4.218		1.000474383x
> StringIndexOf.searchCharMediumSuccess	3.133		3.216		1.02649218x
> StringIndexOf.searchCharShortSuccess	3.76		        3.761		1.000265957x
> StringIndexOf.success	                                9.186		9.713		1.057369911x
> StringIndexOf.successBig	                      14.341		46.343		3.231504079x
> StringIndexOfChar.latin1_AVX2_String	  6220.918		12154.52		1.953814533x
> StringIndexOfChar.latin1_AVX2_char	  5503.556		5540.044		1.006629895x
> StringIndexOfChar.latin1_SSE4_String	  6978.854		6818.689		0.977049957x
> StringIndexOfChar.latin1_SSE4_char	  5657.499		5474.624		0.967675646x
> StringIndexOfChar.latin1_Short_String	  7132.541		6863.359		0.962260014x
> StringIndexOfChar.latin1_Short_char	16013.389	      16162.437		1.009307711x
> StringIndexOfChar.latin1_mixed_String	  7386.123	      14771.622		1.999915517x
> StringIndexOfChar.latin1_mixed_char	  9901.671		9782.245		0.987938803

Scott Gibbons has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 58 commits:

 - Merge branch 'openjdk:master' into indexof
 - un-helper-ize preload_needle_helper; try fix for macos build
 - Added header file
 - Adding exhaustive test
 - Added comments; move n-k<32 code up a level
 - Fixed CI compiles; re-factor UL processing
 - Addressing lots of comments.  Interim commit.
 - Rearrange; add lambdas for clarity
 - Merge remote-tracking branch 'origin/master' into indexof
 - Move arrays_equals back to c2_MacroAssembler
 - ... and 48 more: https://git.openjdk.org/jdk/compare/37c47785...f4eefe1a

-------------

Changes: https://git.openjdk.org/jdk/pull/16753/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16753&range=25
  Stats: 4303 lines in 16 files changed: 4140 ins; 26 del; 137 mod
  Patch: https://git.openjdk.org/jdk/pull/16753.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16753/head:pull/16753

PR: https://git.openjdk.org/jdk/pull/16753

From sgibbons at openjdk.org  Wed May 22 18:52:27 2024
From: sgibbons at openjdk.org (Scott Gibbons)
Date: Wed, 22 May 2024 18:52:27 GMT
Subject: RFR: 8320448: Accelerate IndexOf using AVX2 [v27]
In-Reply-To: <uWi4QxH31hL93771gkl_GgvP0m84IRSoR_1Yi8hD17E=.bc6ed458-7081-4c3f-9348-f59358fa05a4@github.com>
References: <uWi4QxH31hL93771gkl_GgvP0m84IRSoR_1Yi8hD17E=.bc6ed458-7081-4c3f-9348-f59358fa05a4@github.com>
Message-ID: <Lbuv70WFoRg-z7Z85Q5mx6UexSQRF-GbnxODre5ibnc=.22b52629-9c5c-4a08-ab82-50c97f228626@github.com>

> Re-write the IndexOf code without the use of the pcmpestri instruction, only using AVX2 instructions.  This change accelerates String.IndexOf on average 1.3x for AVX2.  The benchmark numbers:
> 
> 
> Benchmark	                                               Score		Latest		
> StringIndexOf.advancedWithMediumSub   343.573		317.934		0.925375393x
> StringIndexOf.advancedWithShortSub1	  1039.081		1053.96		1.014319384x
> StringIndexOf.advancedWithShortSub2	      55.828		110.541		1.980027943x
> StringIndexOf.constantPattern	                9.361		11.906		1.271872663x
> StringIndexOf.searchCharLongSuccess	        4.216		4.218		1.000474383x
> StringIndexOf.searchCharMediumSuccess	3.133		3.216		1.02649218x
> StringIndexOf.searchCharShortSuccess	3.76		        3.761		1.000265957x
> StringIndexOf.success	                                9.186		9.713		1.057369911x
> StringIndexOf.successBig	                      14.341		46.343		3.231504079x
> StringIndexOfChar.latin1_AVX2_String	  6220.918		12154.52		1.953814533x
> StringIndexOfChar.latin1_AVX2_char	  5503.556		5540.044		1.006629895x
> StringIndexOfChar.latin1_SSE4_String	  6978.854		6818.689		0.977049957x
> StringIndexOfChar.latin1_SSE4_char	  5657.499		5474.624		0.967675646x
> StringIndexOfChar.latin1_Short_String	  7132.541		6863.359		0.962260014x
> StringIndexOfChar.latin1_Short_char	16013.389	      16162.437		1.009307711x
> StringIndexOfChar.latin1_mixed_String	  7386.123	      14771.622		1.999915517x
> StringIndexOfChar.latin1_mixed_char	  9901.671		9782.245		0.987938803

Scott Gibbons has updated the pull request incrementally with one additional commit since the last revision:

  Revert last change to IndexOf.java

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/16753/files
  - new: https://git.openjdk.org/jdk/pull/16753/files/f4eefe1a..ed4451d1

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16753&range=26
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16753&range=25-26

  Stats: 3 lines in 1 file changed: 0 ins; 2 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/16753.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16753/head:pull/16753

PR: https://git.openjdk.org/jdk/pull/16753

From naoto at openjdk.org  Wed May 22 19:35:03 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 22 May 2024 19:35:03 GMT
Subject: RFR: 8332084: Ensure JdkConsoleImpl.restoreEcho visibility in a
 shutdown hook [v8]
In-Reply-To: <Sp1JCcgo-YVhpp8ySXyVST5iyC0FDWzXmhgHcASDB4M=.1fee6124-cf1e-4d33-94f1-b4dbebe55e51@github.com>
References: <9JTWc3FRpfbILlSHlmIU_dL5IE69RTxnSIAOdIte15I=.5854a48f-21d7-42c9-adb7-5e3ed40d1211@github.com>
 <s5UWj1VnzkiOOPZk8YMuJrbyAoMx-pVeV14Cx5UDZeE=.495ed70f-3dd5-4c4d-a616-0f20fcb92907@github.com>
 <3wqzT0bRvcYKv_nM7cvp3crD7Mdi6DtoTAbp5ojlg64=.b0ca72b7-4915-4c91-bc22-e2d06817b37c@github.com>
 <Sp1JCcgo-YVhpp8ySXyVST5iyC0FDWzXmhgHcASDB4M=.1fee6124-cf1e-4d33-94f1-b4dbebe55e51@github.com>
Message-ID: <-gmMJpHCz8ESdl7wginOk8QGr2prpGAzRBZz7cv7s3c=.b7b6ff60-aafe-4a31-b1ea-ad318cb4e4c4@github.com>

On Wed, 22 May 2024 18:35:40 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> I might be confused, but what if the shutdown hook completes and then some application thread enters `readPassword`. If that thread manages to turn off echo before all other shutdown hooks complete, it might never execute `finally`, hence a race.

Yes, that is possible. However I would say that it is equally unlikely as an app installs a shutdown hook with readPassword(), so I think this is OK too. BTW, if an app issues `Runtime.halt()` while `readPassword()` is waiting, then those shutdown hooks aren't even executed, thus ends up in not restoring the echo without a race, which I think is OK as well.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19184#issuecomment-2125602570

From liangchenblue at gmail.com  Wed May 22 19:37:16 2024
From: liangchenblue at gmail.com (Chen Liang)
Date: Wed, 22 May 2024 14:37:16 -0500
Subject: Deterministic naming of subclasses of `java/lang/reflect/Proxy`
In-Reply-To: <eabfa5ae508e4257bd0c9bbef244637f@kth.se>
References: <bf26eb2f74874e02876b3868311922a9@kth.se>
 <CABe8uE0fk71Xy_PYHikSw9OtXE_i+M9zMbayPEXuTxLWLoy2ag@mail.gmail.com>
 <50405ca9c0a64372bace175b932f9ef7@kth.se>
 <61fbe3d9-9536-4113-adde-6cfc671ba1ee@oracle.com>
 <a860be44e06243799593aa8d67c048cd@kth.se>
 <CABe8uE115=DzYCdnvNazqFuuxtJoZnv9wRUkFA4-PS7g41QLMw@mail.gmail.com>
 <DB7PR02MB35938DCC3A392536B924164AFBEE2@DB7PR02MB3593.eurprd02.prod.outlook.com>
 <a0330ee0-5f45-4ef2-8500-e5fcdb696c52@oracle.com>
 <b214cc1a13fe4885a437e16b420e5483@kth.se>
 <ac2ebe5c-db49-4a2d-a5cd-10440a77aa16@oracle.com>
 <580b3aacd8df48fcaae3399718e229ab@kth.se>
 <CABe8uE065Q3+0yNjtyDF-eJM4LN-MbY9kfC44CnSQ-KM4p862g@mail.gmail.com>
 <b64077d6cf0045e98b630cf888785182@kth.se>
 <eabfa5ae508e4257bd0c9bbef244637f@kth.se>
Message-ID: <CABe8uE13qRX7pRXJOdhUF0sUwF5WkxTAM517tSTOi1r2Q7ivOg@mail.gmail.com>

Hi Aman,
Even though the specification says "not in any particular order," the
getInterfaces and getMethods actually return an ordered array, in the order
these methods/interfaces are declared in their class files.

I believe you are decompiling the proxy classes generated by an older
version of the JDK; for example, back in JDK 8, the proxy methods were not
ordered because they were tracked in a HashMap:
https://github.com/openjdk/jdk8u/blob/6b53212ef78ad50f9eede829c5ff87cadcdb434b/jdk/src/share/classes/sun/misc/ProxyGenerator.java#L405
Which is no longer the case:
https://github.com/openjdk/jdk/blob/d59c12fe1041a1f61f68408241a9aa4d96ac4fd2/src/java.base/share/classes/java/lang/reflect/ProxyGenerator.java#L241

- Chen

On Wed, May 22, 2024 at 1:19?PM Aman Sharma <amansha at kth.se> wrote:

> Hi,
>
>
> Another thing I wanted to look into in this thread was the order of fields
> in the Proxy classes generated. They are also based on the a number. The
> same proxy classes across different executions can have random order of
> `Method` fields and the methods could be mapped to different field names.
>
>
> For example, consider the proxy class based on `picocli.CommandLine
> <https://github.com/remkop/picocli/blob/da98db63d1b516141b7485881b0dcddfd082dbc8/src/main/java/picocli/CommandLine.java#L4541>`
> in two different executions.
>
> // fields and method are truncated for brevity
> public final class $Proxy9 extends Proxy implements CommandLine.Command {
>     private static Method m1;
>     private static Method m32;
>     private static Method m21;
>     private static Method m43;
>     private static Method m36;
>     private static Method m27;
>
>     public final boolean helpCommand() throws  {
>         try {
>             return (Boolean)super.h.invoke(this, m32, (Object[])null);
>         } catch (RuntimeException | Error var2) {
>             throw var2;
>         } catch (Throwable var3) {
>             throw new UndeclaredThrowableException(var3);
>         }
>      }
>
> // fields and method are truncated for brevity
> public final class $Proxy13 extends Proxy implements CommandLine.Command {
>     private static Method m1;
>     private static Method m29;
>     private static Method m16;
>     private static Method m40;
>     private static Method m38;
>     private static Method m12;
>
>     public final boolean helpCommand() throws  {
>         try {
>             return (Boolean)super.h.invoke(this, m29, (Object[])null);
>         } catch (RuntimeException | Error var2) {
>             throw var2;
>         } catch (Throwable var3) {
>             throw new UndeclaredThrowableException(var3);
>         }
>     }
>
>
> Notice the difference in the order of fields and `helpCommand` method is
> mapped to a different field name in both classes. This happens because
> the method array returned by `getMethods` is not sorted in any particular
> order
> <https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/lang/Class.java#L2178>
> when generating a proxy class. What dictates this order? And why is it
> not deterministic?
>
>
> Regards,
> Aman Sharma
>
> PhD Student
> KTH Royal Institute of Technology
> School of Electrical Engineering and Computer Science (EECS)
> Department of Theoretical Computer Science (TCS)
> <http://www.kth.se> <https://www.kth.se/profile/amansha>
> <https://www.kth.se/profile/amansha>
> <https://www.kth.se/profile/amansha>https://algomaster99.github.io/
> ------------------------------
> *From:* Aman Sharma
> *Sent:* Wednesday, May 22, 2024 4:12:19 PM
> *To:* Chen Liang
> *Cc:* David Holmes; core-libs-dev at openjdk.org; leyden-dev at openjdk.org
> *Subject:* Re: Deterministic naming of subclasses of
> `java/lang/reflect/Proxy`
>
>
> Hi Chen,
>
>
> That's clear. Thanks for letting me know. I guess then Project Leyden is
> working on naming the hidden classes deterministically to achieve their
> goals <https://openjdk.org/projects/leyden/notes/01-beginnings>.
>
>
> Regards,
> Aman Sharma
>
> PhD Student
> KTH Royal Institute of Technology
> School of Electrical Engineering and Computer Science (EECS)
> Department of Theoretical Computer Science (TCS)
> <http://www.kth.se> <https://www.kth.se/profile/amansha>
> <https://www.kth.se/profile/amansha>
> <https://www.kth.se/profile/amansha>https://algomaster99.github.io/
> ------------------------------
> *From:* Chen Liang <liangchenblue at gmail.com>
> *Sent:* Wednesday, May 22, 2024 1:35:46 PM
> *To:* Aman Sharma
> *Cc:* David Holmes; core-libs-dev at openjdk.org; leyden-dev at openjdk.org
> *Subject:* Re: Deterministic naming of subclasses of
> `java/lang/reflect/Proxy`
>
> Hi Aman,
> We have tried defining Proxy as hidden classes; a previous attempt was on
> hold because of issues with serialization. Otherwise, Proxies work great as
> hidden classes.
>
> Chen
>
> On Mon, May 20, 2024 at 7:56?AM Aman Sharma <amansha at kth.se> wrote:
>
>> Hi David,
>>
>>
>> > I would not expect any class load
>> events.
>>
>>
>> I understand. I also haven't tried to intercept them but I see only one
>> approach right now to include them in an allowlist - 1) statically look for
>> invocations of "Lookup::defineHiddenClass". 2) Instrument them so that
>> its first argument "bytes" can be looked into upon. I haven't looked into
>> it much because I did not have much idea about it. And they are hidden so
>> it made it worse. ? Thanks for sharing the JEP!
>>
>>
>> >
>> java.lang.reflect.Proxy could define hidden classes to act as the proxy
>> classes which implement proxy interfaces; from JEP 317
>>
>>
>> It says that Proxy classes will also become hidden classes. Is it
>> underway? Right now one can intercept, transform them, and include them in
>> an allowlist. What do you think of naming them independent of AtomicLong so
>> that a proxy class generated at runtime is easy to lookup in the allowlist?
>>
>>
>>
>> Regards,
>> Aman Sharma
>>
>> PhD Student
>> KTH Royal Institute of Technology
>> School of Electrical Engineering and Computer Science (EECS)
>> Department of Theoretical Computer Science (TCS)
>> <http://www.kth.se> <https://www.kth.se/profile/amansha>
>> <https://www.kth.se/profile/amansha>
>> <https://www.kth.se/profile/amansha>https://algomaster99.github.io/
>> ------------------------------
>> *From:* David Holmes <david.holmes at oracle.com>
>> *Sent:* Monday, May 20, 2024 2:30:37 PM
>> *To:* Aman Sharma; liangchenblue at gmail.com
>> *Cc:* core-libs-dev at openjdk.org; leyden-dev at openjdk.org
>> *Subject:* Re: Deterministic naming of subclasses of
>> `java/lang/reflect/Proxy`
>>
>> On 20/05/2024 10:12 pm, Aman Sharma wrote:
>> > Hi David,
>> >
>> >
>> >  > How did you try to intercept them? Hidden classes are not "loaded" in
>> > the normal sense so won't trigger class load events.
>> >
>> >
>> > I could not intercept them. I only see them when I pass
>> `-verbose:class`
>> > in the Java CLI.
>>
>> Yes that is why I asked how you tried to intercept them.
>>
>> >
>> > I also couldn't intercept them using JVMTI Class File Load Hook
>> > <
>> https://docs.oracle.com/en/java/javase/21/docs/specs/jvmti.html#ClassFileLoadHook>
>> event. However JEP 371 suggests that it should be possible to intercept
>> them using JVMTI Class Load <
>> https://docs.oracle.com/en/java/javase/21/docs/specs/jvmti.html#ClassLoad>
>> event, but I won't have the bytecode at this stage. So is there no way to
>> get its bytecode before it is linked and initialized in the JVM?
>>
>> Hidden classes are not loaded so I would not expect any class load
>> events. However the exact nature of the JVMTI class load event is
>> unclear as it talks about "class or interface creation" which is neither
>> loading or defining per se. But a class prepare event sounds like it
>> should be issued. However neither give you access to the bytecode of the
>> class AFAICS.
>>
>> David
>> -----
>>
>>
>> >
>> > Regards,
>> > Aman Sharma
>> >
>> > PhD Student
>> > KTH Royal Institute of Technology
>> > School of Electrical Engineering and Computer Science (EECS)
>> > Department of Theoretical Computer Science (TCS)
>> > <
>> http://www.kth.se><https://www.kth.se/profile/amansha><https://www.kth.se/profile/amansha
>> >
>> > <https://www.kth.se/profile/amansha>https://algomaster99.github.io/
>> > <https://algomaster99.github.io/>
>> > ------------------------------------------------------------------------
>> > *From:* David Holmes <david.holmes at oracle.com>
>> > *Sent:* Monday, May 20, 2024 2:59:17 AM
>> > *To:* Aman Sharma; liangchenblue at gmail.com
>> > *Cc:* core-libs-dev at openjdk.org; leyden-dev at openjdk.org
>> > *Subject:* Re: Deterministic naming of subclasses of
>> > `java/lang/reflect/Proxy`
>> > On 17/05/2024 9:43 pm, Aman Sharma wrote:
>> >> Hi Chen,
>> >>
>> >>  > java.lang.invoke.LambdaForm$MH/0x00000200cc000400
>> >>
>> >> I do see this as output when I pass -verbose:class. However, based on
>> my
>> >> experiments, I have seen that neither an agent passed via 'javaagent'
>> >> nor an agent passed via 'agentpath' is able to intercept this hidden
>> class.
>> >
>> > How did you try to intercept them? Hidden classes are not "loaded" in
>> > the normal sense so won't trigger class load events.
>> >
>> >> Also, I was a bit confused since I saw somewhere that the names of
>> >> hidden classes are null. But thanks for clarifying here.
>> >
>> > The JEP clearly defines the name format for hidden classes - though the
>> > final component is VM specific (and typically a hashcode).
>> >
>> > https://openjdk.org/jeps/371 <https://openjdk.org/jeps/371>
>> >
>> > Cheers,
>> > David
>> > -----
>> >
>> >>  > avoid dynamic class loading
>> >>
>> >> I don't see dynamic class loading as a problem. I only mind some
>> >> unstable generation aspects of them which make it hard to verify them
>> >> based on an allowlist.
>> >>
>> >> For example, if this hidden class is generated with the exact same
>> name
>> >> and the exact same bytecode during runtime as well, it would be easy
>> to
>> >> verify it. However, I do see the names are based on some sort of
>> memory
>> >> address so and I don't know what bytecode it has so I don't have
>> >> suggestions to make them stable as of now. For Proxy classes, I feel
>> it
>> >> can be addressed unless you disagree or some involved in Project
>> Leyden
>> >> does. :) Thank you for forwarding my mail there.
>> >>
>> >> Regards,
>> >> Aman Sharma
>> >>
>> >> PhD Student
>> >> KTH Royal Institute of Technology
>> >> https://algomaster99.github.io/ <https://algomaster99.github.io/>
>> > <https://algomaster99.github.io/ <https://algomaster99.github.io/>>
>> >>
>> >>
>> ------------------------------------------------------------------------
>> >> *From:* liangchenblue at gmail.com <liangchenblue at gmail.com>
>> >> *Sent:* Friday, May 17, 2024 1:23:58 pm
>> >> *To:* Aman Sharma <amansha at kth.se>
>> >> *Cc:* core-libs-dev at openjdk.org <core-libs-dev at openjdk.org>;
>> >> leyden-dev at openjdk.org <leyden-dev at openjdk.org>
>> >> *Subject:* Re: Deterministic naming of subclasses of
>> >> `java/lang/reflect/Proxy`
>> >>
>> >> Hi Aman,
>> >> For `-verbose:class`, it's a JVM argument instead of a program
>> argument;
>> >> so when you run a java program like `java Main`, you should call it as
>> >> `java -verbose:class Main`.
>> >> When done correctly, you should see hidden class outputs like:
>> >> [0.032s][info][class,load]
>> >> java.lang.invoke.LambdaForm$MH/0x00000200cc000400 source:
>> >> __JVM_LookupDefineClass__
>> >> The loading of java.lang.invoke hidden classes requires your program
>> to
>> >> use MethodHandle features, like a lambda.
>> >>
>> >> I think the problem you are exploring, that to avoid dynamic class
>> >> loading and effectively turn Java Platform closed for security, is
>> also
>> >> being accomplished by project Leyden (as I've shared initially); Thus,
>> I
>> >> am forwarding this to leyden-dev instead, so you can see what approach
>> >> Leyden uses to accomplish the same goal as yours.
>> >>
>> >> Regards, Chen Liang
>> >>
>> >> On Fri, May 17, 2024 at 4:40?AM Aman Sharma <amansha at kth.se
>> >> <mailto:amansha at kth.se <mailto:amansha at kth.se <amansha at kth.se>>>>
>> wrote:
>> >>
>> >>     __
>> >>
>> >>     Hi Roger,
>> >>
>> >>
>> >>     Do you have ideas on how to intercept them? My javaagent is not
>> able
>> >>     to nor a JVMTI agent passed using `agentpath` option. It also does
>> >>     not seem to show up in logs when I pass `-verbose:class`.
>> >>
>> >>
>> >>     Also, what do you think of renaming the proxy classes as suggested
>> >>     below?
>> >>
>> >>
>> >>     Regards,
>> >>     Aman Sharma
>> >>
>> >>     PhD Student
>> >>     KTH Royal Institute of Technology
>> >>     School of Electrical Engineering and Computer Science (EECS)
>> >>     Department of Theoretical Computer Science (TCS)
>> >>     <http://www.kth.se><https://www.kth.se/profile/amansha><
>> https://www.kth.se/profile/amansha <
>> http://www.kth.se><https://www.kth.se/profile/amansha><https://www.kth.se/profile/amansha
>> >>
>> >>     <https://www.kth.se/profile/amansha
>> > <https://www.kth.se/profile/amansha>>https://algomaster99.github.io/
>> >>     <https://algomaster99.github.io/ <https://algomaster99.github.io/
>> >>
>> >>
>> ------------------------------------------------------------------------
>> >>     *From:* core-libs-dev <core-libs-dev-retn at openjdk.org
>> >>     <mailto:core-libs-dev-retn at openjdk.org
>> > <mailto:core-libs-dev-retn at openjdk.org <core-libs-dev-retn at openjdk.org>>>>
>> on behalf of Roger Riggs
>> >>     <roger.riggs at oracle.com <mailto:roger.riggs at oracle.com <
>> mailto:roger.riggs at oracle.com <roger.riggs at oracle.com>>>>
>> >>     *Sent:* Friday, May 17, 2024 4:57:46 AM
>> >>     *To:* core-libs-dev at openjdk.org <mailto:core-libs-dev at openjdk.org
>> <mailto:core-libs-dev at openjdk.org <core-libs-dev at openjdk.org>>>
>> >>     *Subject:* Re: Deterministic naming of subclasses of
>> >>     `java/lang/reflect/Proxy`
>> >>     Hi Aman,
>> >>
>> >>     You may also run into hidden classes (JEP 371: Hidden Classes) that
>> >>     allow classes to be defined, at runtime, without names.
>> >>     It has been proposed to use them for generated proxies but that
>> >>     hasn't been implemented yet.
>> >>     There are benefits to having nameless classes, because they can't
>> be
>> >>     referenced by name, only as a capability, they can be better
>> >>     encapsulated.
>> >>
>> >>     fyi, Roger Riggs
>> >>
>> >>
>> >>     On 5/16/24 8:11 AM, Aman Sharma wrote:
>> >>>
>> >>>     Hi,
>> >>>
>> >>>
>> >>>     Thanks for your response, Liang!
>> >>>
>> >>>
>> >>>     > I think you meant CVE-2021-42392 instead of 2022.
>> >>>
>> >>>
>> >>>     Sorry of the error. I indeed meant CVE-2021-42392
>> >>>     <https://nvd.nist.gov/vuln/detail/cve-2021-42392
>> > <https://nvd.nist.gov/vuln/detail/cve-2021-42392>>.
>> >>>
>> >>>
>> >>>     > Leyden mainly avoids this unstable generation by performing a
>> >>>     training run to collect classes loaded
>> >>>
>> >>>
>> >>>     Would love to know the details of Project Leyden and how they
>> >>>     worked so far to focus on this goal. In our case, the training run
>> >>>     is the test suite.
>> >>>
>> >>>
>> >>>     > GeneratedConstructorAccessor is already retired by JEP 416 [2]
>> >>>     in Java 18
>> >>>
>> >>>
>> >>>     I did see them not appearing in my allowlist when I ran my study
>> >>>     subject (Apache PDFBox) with Java 21. Thanks for letting me know
>> >>>     about this JEP. I see they are re-implemented with method handles.
>> >>>
>> >>>
>> >>>     > How are you checking the classes?
>> >>>
>> >>>
>> >>>     To detect runtime generated code, we have javaagent that is hooked
>> >>>     statically to the test suite execution. It gives us all classes
>> >>>     that that is loaded post the JVM and the javaagent are loaded. So
>> >>>     we only check the classes loaded for the purpose of running the
>> >>>     application. This is also why we did not choose -agentlib as it
>> >>>     would give classes for the setting up JVM and javaagent and we the
>> >>>     user of our tool must the classes they load.
>> >>>
>> >>>
>> >>>     Next, we have a `ClassFileTransformer` hook in the agent where we
>> >>>     produce the checksum using the bytecode. And we compare the
>> >>>     checksum with the one existing in the allowlist. The checksum
>> >>>     computation algorithm is same for both steps. Let me describe how
>> >>>     I compute the checksum.
>> >>>
>> >>>
>> >>>      1. I get the CONSTANT_Class_info
>> >>>         <
>> https://docs.oracle.com/javase/specs/jvms/se11/html/jvms-4.html#jvms-4.4.1
>> <
>> https://docs.oracle.com/javase/specs/jvms/se11/html/jvms-4.html#jvms-4.4.1>>
>> entry corresponding to `this_class` and rewrite the CONSTANT_Utf8_info <
>> https://docs.oracle.com/javase/specs/jvms/se11/html/jvms-4.html#jvms-4.4.7
>> <
>> https://docs.oracle.com/javase/specs/jvms/se11/html/jvms-4.html#jvms-4.4.7>>
>> corresponding to a fix String constant, say "foo".
>> >>>      2. Since, the name of the class is used to refer to its types
>> >>>         members (fields/method), I get all CONSTANT_Fieldref_info
>> >>>         <
>> https://docs.oracle.com/javase/specs/jvms/se11/html/jvms-4.html#jvms-4.4.2
>> <
>> https://docs.oracle.com/javase/specs/jvms/se11/html/jvms-4.html#jvms-4.4.2>>
>> and if its `class_index` corresponds to the old `this_class`, we rewrite
>> the UTF8 value of class_index to the same constant "foo".
>> >>>      3. Next, since the naming of the fields, in Proxy classes, are
>> >>>         also suffixed by numbers, for example, `private static Method
>> >>>         m4`, we rewrite the UTF8 value of name in the
>> >>>         CONSTANT_NameAndType_info
>> >>>         <
>> https://docs.oracle.com/javase/specs/jvms/se11/html/jvms-4.html#jvms-4.4.6
>> <
>> https://docs.oracle.com/javase/specs/jvms/se11/html/jvms-4.html#jvms-4.4.6
>> >>.
>> >>>      4. These fields can also have a random order so we simply sort
>> >>>         the entire byte code using `Arrays.sort(byte[])` to eliminate
>> >>>         any differences due to ordering of fields/methods.
>> >>>      5. Simply sorting the byte array still had minute differences. I
>> >>>         could not understand why they existed even though values in
>> >>>         constant pool of the bytecode in allowlist and at runtime were
>> >>>         exactly the same after rewriting. The differences existed in
>> >>>         the bytes of the Code attribute of methods. I concluded that
>> >>>         the bytes stored some position information. To avoid this, I
>> >>>         created a subarray where I considered the bytes corresponding
>> >>>         to `CONSTANT_Utf8_info.bytes` only. Computing a checksum for
>> >>>         it resulted in the same checksums for both classfiles.
>> >>>
>> >>>
>> >>>     Let's understand the whole approach with an example of Proxy
>> class.
>> >>>
>> >>>     `
>> >>>     public  final  class  $Proxy42  extends  Proxy  implements
>> org.apache.logging.log4j.core.config.plugins.Plugin  {
>> >>>     `
>> >>>
>> >>>     The will go in the allowlist as "Proxy_Plugin: <SHA256 checksum>".
>> >>>
>> >>>     When the same class is intercepted at runtime, say "$Proxy10", we
>> >>>     look for "Proxy_Plugin" in the allowlist and since the checksum
>> >>>     algorithm is same in both cases, we get a match and let the class
>> >>>     load.
>> >>>
>> >>>     This approach has seemed to work well for Proxy classes, Generated
>> >>>     Constructor Accessor (which is removed as you said). I also looked
>> >>>     at the species generated by method handles. I did not notice any
>> >>>     modification in them. Their name generation seemed okay to me. If
>> >>>     some new Species are generated, it is of course detected since it
>> >>>     is not in the allowlist.
>> >>>
>> >>>     I have not looked into LambdaMetafactory because I did not
>> >>>     encounter it as a problem so far, but I am aware its name
>> >>>     generation is also unstable. I have run my approach only a few
>> >>>     projects only. And for hidden classes, I assume the the agent
>> >>>     won't be able to intercept them so detecting them would be really
>> >>>     hard.
>> >>>
>> >>>
>> >>>     Regards,
>> >>>     Aman Sharma
>> >>>
>> >>>     PhD Student
>> >>>     KTH Royal Institute of Technology
>> >>>     School of Electrical Engineering and Computer Science (EECS)
>> >>>     Department of Theoretical Computer Science (TCS)
>> >>>     <https://www.kth.se/profile/amansha
>> > <https://www.kth.se/profile/amansha>>https://algomaster99.github.io/
>> > <https://algomaster99.github.io/ <https://algomaster99.github.io/>>
>> >>>
>> ------------------------------------------------------------------------
>> >>>     *From:* liangchenblue at gmail.com <mailto:liangchenblue at gmail.com <
>> mailto:liangchenblue at gmail.com <liangchenblue at gmail.com>>>
>> >>>     <liangchenblue at gmail.com> <mailto:liangchenblue at gmail.com <
>> mailto:liangchenblue at gmail.com <liangchenblue at gmail.com>>>
>> >>>     *Sent:* Thursday, May 16, 2024 5:52:03 AM
>> >>>     *To:* Aman Sharma; core-libs-dev
>> >>>     *Cc:* Martin Monperrus
>> >>>     *Subject:* Re: Deterministic naming of subclasses of
>> >>>     `java/lang/reflect/Proxy`
>> >>>     Hi Aman,
>> >>>     I think you meant CVE-2021-42392 instead of 2022.
>> >>>
>> >>>     For your approach of an "allowlist" for Java runtime, project
>> >>>     Leyden is looking to generate a static image [1], that
>> >>>     > At run time it cannot load classes from outside the image, nor
>> >>>     can it create classes dynamically.
>> >>>     Leyden mainly avoids this unstable generation by performing a
>> >>>     training run to collect classes loaded and even object graphs; I
>> >>>     am not familiar with the details unfortunately.
>> >>>
>> >>>     Otherwise, the Proxy discussion belongs better to core-libs-dev,
>> >>>     as java.lang.reflect.Proxy is part of Java's core libraries. I am
>> >>>     replying this thread to core-libs-dev.
>> >>>
>> >>>     For your perceived problem that classes don't have unique names,
>> >>>     your description sounds dubious: GeneratedConstructorAccessor is
>> >>>     already retired by JEP 416 [2] in Java 18, and there are many
>> >>>     other cases in which JDK generates classes without stable names,
>> >>>     notoriously LambdaMetafactory (Gradle wished for cacheable
>> >>>     Lambdas); the same applies for the generated classes for
>> >>>     MethodHandle's LambdaForms (which carries implementation code for
>> >>>     LambdaForm). How are you checking the classes? It seems you are
>> >>>     not checking hidden classes. Proxy and Lambda classes are defined
>> >>>     by the caller's class loader, while LambdaForms are under JDK's
>> >>>     system class loader I think. We need to ensure you are correctly
>> >>>     finding all unstable classes before we can proceed.
>> >>>
>> >>>     [1]: https://openjdk.org/projects/leyden/notes/01-beginnings
>> > <https://openjdk.org/projects/leyden/notes/01-beginnings>
>> >>>     <https://openjdk.org/projects/leyden/notes/01-beginnings
>> > <https://openjdk.org/projects/leyden/notes/01-beginnings>>
>> >>>     [2]: https://openjdk.org/jeps/416 <https://openjdk.org/jeps/416>
>> > <https://openjdk.org/jeps/416 <https://openjdk.org/jeps/416>>
>> >>>
>> >>>     On Wed, May 15, 2024 at 7:00?PM Aman Sharma <amansha at kth.se
>> >>>     <mailto:amansha at kth.se <mailto:amansha at kth.se <amansha at kth.se>>>>
>> wrote:
>> >>>
>> >>>         Hi,
>> >>>
>> >>>
>> >>>         My name is Aman and I am a PhD student at KTH Royal Institute
>> >>>         of Technology, Stockholm, Sweden. I research as part of CHAINS
>> >>>         <https://chains.proj.kth.se/ <https://chains.proj.kth.se/>>
>> project to
>> > strengthen the
>> >>>         software supply chain of multiple ecosystem. I particularly
>> >>>         focus on runtime integrity in Java. In this email, I want to
>> >>>         write about an issue I have discovered with /dynamic
>> >>>         generation of `java.lang.reflect.Proxy`classes/. I will
>> >>>         propose a solution and would love to hear the feedback from
>> >>>         the community. Let me know if this is the correct mailing-list
>> >>>         for such discussions. It seemed the most relevant from this
>> >>>         list <https://mail.openjdk.org/mailman/listinfo
>> > <https://mail.openjdk.org/mailman/listinfo>>.
>> >>>
>> >>>
>> >>>         *My research*
>> >>>
>> >>>         *
>> >>>         *
>> >>>
>> >>>         Java has features to load class on the fly - it can either
>> >>>         download or generate a class at runtime. These features are
>> >>>         useful for inner workings of JDK. For example, implementing
>> >>>         annotations, reflective access, etc. However, these features
>> >>>         have also contributed to critical vulnerabilities in the past
>> >>>         - CVE-2021-44228  (log4shell), CVE-2022-33980, CVE-2022-42392.
>> >>>         All of these vulnerabilities have one thing in common - /a
>> >>>         class that was not known during build time was
>> >>>         downloaded/generated at runtime and loaded into JVM./
>> >>>
>> >>>
>> >>>         To defend against such vulnerabilities, we propose a solution
>> >>>         to /allowlist classes for runtime/. This allowlist will
>> >>>         contain an exhaustive list of classes that can be loaded by
>> >>>         the JVM and it will be enforced at runtime. We build this
>> >>>         allowlist from three sources:
>> >>>
>> >>>          1. All classes of all modules provided by the Java Standard
>> >>>             Library. We use ClassGraph
>> >>>             <https://github.com/classgraph/classgraph
>> > <https://github.com/classgraph/classgraph>> to scan the JDK.
>> >>>          2. We can take the source code and all dependencies of an
>> >>>             application. We use a software bill of materials to get
>> >>>             all the data.
>> >>>          3. Finally, we use run the test suite to include any runtime
>> >>>             downloaded/generated classes.
>> >>>
>> >>>         Such a list is able to prevent the above 3 CVEs because it
>> >>>         does not let the "unknown" bytecode to be loaded.
>> >>>
>> >>>         *Problem with generating such an allowlist*
>> >>>         *
>> >>>         *
>> >>>         The first two parts of the allowlist are easy to get. The
>> >>>         problem is with the third step where we want to allowlist all
>> >>>         the classes that could be downloaded or generated. Upon
>> >>>         running the test suite and hooking to the classes it loads, we
>> >>>         observer that the list consists of classes that are called
>> >>>         "com/sun/proxy/$Proxy2",
>> >>>         "jdk/internal/reflect/GeneratedConstructorAccessor3" among
>> >>>         many more. The purpose of these classes can be identifed. The
>> >>>         proxy class is created for to implement an annotation. The
>> >>>         accessor gives access to constructor of a class to the JVM.
>> >>>
>> >>>         When enforcing this allowlist at runtime, we see that the
>> >>>         bytecode content for "com/sun/proxy/$Proxy2" differs in the
>> >>>         allowlist and at runtime. In our case, we we are experimenting
>> >>>         with pdfbox <https://github.com/apache/pdfbox <
>> https://github.com/apache/pdfbox>> so
>> > we created
>> >>>         the allowlist using its test suite. Then we enforced this
>> >>>         allowlist while running some of its subcommands. However,
>> >>>         there was some other proxy class say "com/sun/proxy/$Proxy5"
>> >>>         at runtime that implemented the same interfaces and had the
>> >>>         same methods as "com/sun/proxy/$Proxy2" in the allowlist. They
>> >>>         only differed in the name of the class, order of fields, and
>> >>>         types for fields references. This could happen because the
>> >>>         order of the loading of class is workload dependent, but it
>> >>>         causes problem to generate such an allowlist.
>> >>>
>> >>>         *Solution
>> >>>         *
>> >>>
>> >>>
>> >>>         We propose that naming of subclasses of
>> >>>         "java/lang/reflect/Proxy" should not be dependent upon the
>> >>>         order of loading. In order to do so, two issues can be fixed:
>> >>>
>> >>>          1. The naming of the class should not be based on AtomicLong
>> >>>             <
>> https://github.com/openjdk/jdk/blob/b687aa550837830b38f0f0faa69c353b1e85219c/src/java.base/share/classes/java/lang/reflect/Proxy.java#L531
>> <
>> https://github.com/openjdk/jdk/blob/b687aa550837830b38f0f0faa69c353b1e85219c/src/java.base/share/classes/java/lang/reflect/Proxy.java#L531>>.
>> Rather it could be named based on the interfaces it implements. I also
>> wonder why AtomicLong is chosen in the first place.
>> >>>          2. Methods of the interfaces must be in a particular order.
>> >>>             Right now, they are not sorted in any particular order
>> >>>             <
>> https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/lang/Class.java#L2178
>> <
>> https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/lang/Class.java#L2178
>> >>.
>> >>>
>> >>>
>> >>>         These fixes will make proxy class generation deterministic
>> >>>         with respect to order of loading and won't be flagged at
>> >>>         runtime since the test suite would already detect them.
>> >>>
>> >>>         I would love to hear from the community about these ideas. If
>> >>>         in agreement, I would be happy to produce a patch. I have
>> >>>         discovered this issue with subclasses of
>> >>>         GeneratedConstructorAccessor
>> >>>         <
>> https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/jdk/internal/reflect/ConstructorAccessor.java
>> <
>> https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/jdk/internal/reflect/ConstructorAccessor.java>>
>> as well and I imagine it will also apply to some other runtime generated
>> classes. If you disagree, please let me know also. It helps with my
>> research.
>> >>>
>> >>>         I also have PoCs for the above CVEs
>> >>>         <https://github.com/chains-project/exploits-for-sbom.exe
>> > <https://github.com/chains-project/exploits-for-sbom.exe>> and
>> >>>         a proof concept tool is being developed under the name
>> >>>         sbom.exe <https://github.com/chains-project/sbom.exe
>> > <https://github.com/chains-project/sbom.exe>> in case
>> >>>         any one wonders about the implementation. I would also be
>> >>>         happy to explain more.
>> >>>
>> >>>         Regards,
>> >>>         Aman Sharma
>> >>>
>> >>>         PhD Student
>> >>>         KTH Royal Institute of Technology
>> >>>         School of Electrical Engineering and Computer Science (EECS)
>> >>>         Department of Theoretical Computer Science (TCS)
>> >>>         <https://www.kth.se/profile/amansha
>> > <https://www.kth.se/profile/amansha>>https://algomaster99.github.io/
>> > <https://algomaster99.github.io/ <https://algomaster99.github.io/>>
>> >>>
>> >>
>> >>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240522/cde58d87/attachment-0001.htm>

From dlong at openjdk.org  Wed May 22 20:09:07 2024
From: dlong at openjdk.org (Dean Long)
Date: Wed, 22 May 2024 20:09:07 GMT
Subject: RFR: 8327964: Simplify BigInteger.implMultiplyToLen intrinsic [v6]
In-Reply-To: <1nU6OzVHKjN_v9tJD4vTnoQa6hTn5CgDF15PQsyr5YE=.ed74dc2b-33f8-4828-a730-43f03a9aa4ab@github.com>
References: <Z5U-3OSq9_rd0t6DHNRhjF3LHtc9b6orz-mcQ4Uqzl8=.c4f0a0b8-9e10-4505-82f7-7d3a82929d22@github.com>
 <mPGL9bhNOXF_0OStOh5bbG8PtunR_adftSmWy0Jr4NQ=.a8bb895a-25e1-4d60-988e-d306c63cf7e8@github.com>
 <EYByM73-dAJnDr1feKyeIBHK8ydoHh24wgn1opwTX0s=.c6e64958-7cf3-47de-a5a8-ec4a18c21ad0@github.com>
 <1nU6OzVHKjN_v9tJD4vTnoQa6hTn5CgDF15PQsyr5YE=.ed74dc2b-33f8-4828-a730-43f03a9aa4ab@github.com>
Message-ID: <VHPQ0RflNTliPllyF4A1JHNxLGftytfxFslO83oX1ks=.251ca3aa-57e8-4ba2-a81a-ad69df5024d5@github.com>

On Wed, 22 May 2024 14:28:41 GMT, Yudi Zheng <yzheng at openjdk.org> wrote:

>> src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 4693:
>> 
>>> 4691:     const Register xlen  = r1;
>>> 4692:     const Register z     = r2;
>>> 4693:     const Register zlen  = r3;
>> 
>> LibraryCallKit::inline_squareToLen() is still computing zlen and passing it as the 4th arg, even though the value is unused.
>
> ppc x86 are not using `multiply_to_len` for `generate_squareToLen`. I think we still need to pass zlen for these platforms.

OK.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18226#discussion_r1610580527

From naoto at openjdk.org  Wed May 22 20:18:02 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 22 May 2024 20:18:02 GMT
Subject: RFR: 8331879: Clean up non-standard use of /// comments in
 `java.base`
In-Reply-To: <BiSTG8MtjyRt2txRK2DIxsmbPPq6Pvp7QQzOnHXbH6w=.b01b4872-dc8b-4e4f-bae6-bdc501da33a6@github.com>
References: <BiSTG8MtjyRt2txRK2DIxsmbPPq6Pvp7QQzOnHXbH6w=.b01b4872-dc8b-4e4f-bae6-bdc501da33a6@github.com>
Message-ID: <SJEc7F5iCUK5ej9Tq6De8W--UT7MqbyP62IcVNPArRY=.3a3feed7-b8e1-4a14-8a01-fe9b2b7e5bd2@github.com>

On Tue, 7 May 2024 22:23:48 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> With the advent of JEP 467, `///` comments may be treated as documentation comments, and may be subject to the recently new `javac` warning about "dangling doc comments" in unexpected places.
> 
> In keeping with the policy to keep the `java.base` module free of all `javac` warnings, this patch proposes edits to existing uses of `///`.
> 
> There are two dominant policies in the proposed changes. 
> 1. A long horizontal line of `/////` is replaced by `//-----`
> 2. A long vertical series of lines beginning `///` is replaced by lines beginning `//|`.
> 
> As with all style changes, I have also tried to honor local usage, for consistency.
> 
> In one place, a pair of comments appeared to contain directives (`CLOVER:ON`, `CLOVER:OFF`).  I investigated the use of such comments to determine that the exact form of the comment prefix was not significant. (Phew!)
> 
> 
> (This PR is informally blocked by JEP 467).

src/java.base/share/classes/jdk/internal/icu/impl/StringPrepDataReader.java line 122:

> 120:      * see store.c of gennorm for more information and values
> 121:      */
> 122:     // /* dataFormat="SPRP" 0x53, 0x50, 0x52, 0x50  */

This source file is coming from the upstream ICU4J project. Even if this is a `non-standard` comment, I would keep it as it is to minimize the merge effort.

src/java.base/share/classes/jdk/internal/icu/lang/UCharacterDirection.java line 61:

> 59:     {
> 60:     }
> 61:     // CLOVER:ON

Same here.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19130#discussion_r1610588637
PR Review Comment: https://git.openjdk.org/jdk/pull/19130#discussion_r1610586405

From prappo at openjdk.org  Wed May 22 21:09:02 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Wed, 22 May 2024 21:09:02 GMT
Subject: RFR: 8332084: Ensure JdkConsoleImpl.restoreEcho visibility in a
 shutdown hook [v8]
In-Reply-To: <-gmMJpHCz8ESdl7wginOk8QGr2prpGAzRBZz7cv7s3c=.b7b6ff60-aafe-4a31-b1ea-ad318cb4e4c4@github.com>
References: <9JTWc3FRpfbILlSHlmIU_dL5IE69RTxnSIAOdIte15I=.5854a48f-21d7-42c9-adb7-5e3ed40d1211@github.com>
 <s5UWj1VnzkiOOPZk8YMuJrbyAoMx-pVeV14Cx5UDZeE=.495ed70f-3dd5-4c4d-a616-0f20fcb92907@github.com>
 <3wqzT0bRvcYKv_nM7cvp3crD7Mdi6DtoTAbp5ojlg64=.b0ca72b7-4915-4c91-bc22-e2d06817b37c@github.com>
 <Sp1JCcgo-YVhpp8ySXyVST5iyC0FDWzXmhgHcASDB4M=.1fee6124-cf1e-4d33-94f1-b4dbebe55e51@github.com>
 <-gmMJpHCz8ESdl7wginOk8QGr2prpGAzRBZz7cv7s3c=.b7b6ff60-aafe-4a31-b1ea-ad318cb4e4c4@github.com>
Message-ID: <a5A-YyYk3V4Is7t5ozLY_R6wYlZmiWGIifJuUNJKGuI=.9118a23d-7b2a-4712-b53f-5d749e9de110@github.com>

On Wed, 22 May 2024 19:32:07 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> > I might be confused, but what if the shutdown hook completes and then some application thread enters `readPassword`. If that thread manages to turn off echo before all other shutdown hooks complete, it might never execute `finally`, hence a race.
> 
> Yes, that is possible. However I would say that it is equally unlikely as an app installs a shutdown hook with readPassword(), so I think this is OK too. BTW, if an app issues `Runtime.halt()` while `readPassword()` is waiting, then those shutdown hooks aren't even executed, thus ends up in not restoring the echo without a race, which I think is OK as well.

Okay, but can we call it a best-effort attempt to restore the echo state? I guess, it is a judgement call.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19184#issuecomment-2125744051

From redestad at openjdk.org  Wed May 22 21:18:02 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Wed, 22 May 2024 21:18:02 GMT
Subject: RFR: 8332490: JMH
 org.openjdk.bench.java.util.zip.InflaterInputStreams.inflaterInputStreamRead
 OOM [v2]
In-Reply-To: <a9-gLlH5AgmhKJoJM5e7j5gZD-W3oEFl8SpX64WTHUA=.879a2374-aadf-4b5b-921a-3444c3de3797@github.com>
References: <nisubUXku9Aki5ZnEyRq7_l1TGWUpIIaEKpqZMo2DQw=.a01dd330-cfbb-4a6e-85b1-62378b963419@github.com>
 <a9-gLlH5AgmhKJoJM5e7j5gZD-W3oEFl8SpX64WTHUA=.879a2374-aadf-4b5b-921a-3444c3de3797@github.com>
Message-ID: <ZvYLsiuWqa-fqlwch8uKzlRd4Pa3DwwcrF7YODyCccw=.8002d69e-5037-4d39-9b72-728a7cf325bc@github.com>

On Wed, 22 May 2024 07:49:27 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this test-only change for addressing https://bugs.openjdk.org/browse/JDK-8332490?
>> 
>> The jmh test opens a `InflaterInputStream`, reads the stream contents, but then doesn't close the stream. This can lead to resource leak which can then cause OOM as noted in that JBS issue.
>> 
>> The commit in this PR closes the `InflaterInputStream` when the reads complete.
>> 
>> 
>> make test TEST=micro:org.openjdk.bench.java.util.zip.InflaterInputStreams
>> 
>> and
>> 
>> 
>> ./build/macosx-aarch64/images/jdk/bin/java -jar ./build/macosx-aarch64/images/test/micro/benchmarks.jar org.openjdk.bench.java.util.zip.InflaterInputStreams.inflaterInputStreamRead -t max -f 1 -wi 2 -foe true
>> 
>> pass after this change.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add a comment

Sorry, thought I had already approved. Comment is fine.

-------------

Marked as reviewed by redestad (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19340#pullrequestreview-2072382952

From naoto at openjdk.org  Wed May 22 21:23:01 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 22 May 2024 21:23:01 GMT
Subject: RFR: 8332084: Ensure JdkConsoleImpl.restoreEcho visibility in a
 shutdown hook [v8]
In-Reply-To: <a5A-YyYk3V4Is7t5ozLY_R6wYlZmiWGIifJuUNJKGuI=.9118a23d-7b2a-4712-b53f-5d749e9de110@github.com>
References: <9JTWc3FRpfbILlSHlmIU_dL5IE69RTxnSIAOdIte15I=.5854a48f-21d7-42c9-adb7-5e3ed40d1211@github.com>
 <s5UWj1VnzkiOOPZk8YMuJrbyAoMx-pVeV14Cx5UDZeE=.495ed70f-3dd5-4c4d-a616-0f20fcb92907@github.com>
 <3wqzT0bRvcYKv_nM7cvp3crD7Mdi6DtoTAbp5ojlg64=.b0ca72b7-4915-4c91-bc22-e2d06817b37c@github.com>
 <Sp1JCcgo-YVhpp8ySXyVST5iyC0FDWzXmhgHcASDB4M=.1fee6124-cf1e-4d33-94f1-b4dbebe55e51@github.com>
 <-gmMJpHCz8ESdl7wginOk8QGr2prpGAzRBZz7cv7s3c=.b7b6ff60-aafe-4a31-b1ea-ad318cb4e4c4@github.com>
 <a5A-YyYk3V4Is7t5ozLY_R6wYlZmiWGIifJuUNJKGuI=.9118a23d-7b2a-4712-b53f-5d749e9de110@github.com>
Message-ID: <5s-T6ekF1HH_LPQbtHDYkPqlNRLbqNOGpa0QzyBc2UQ=.84ff8f21-0a46-4e7c-8d29-831502213e81@github.com>

On Wed, 22 May 2024 21:06:11 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> Okay, but can we call it a best-effort attempt to restore the echo state? I guess, it is a judgement call.

That would be fair, and exactly what I am aiming for, considering we can do nothing for the `halt()` case.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19184#issuecomment-2125768900

From duke at openjdk.org  Wed May 22 21:26:03 2024
From: duke at openjdk.org (Sunmisc Unsafe)
Date: Wed, 22 May 2024 21:26:03 GMT
Subject: RFR: 8322732: ForkJoinPool may underutilize cores in async mode
 [v3]
In-Reply-To: <pvOc4bvTkPBH-Jvx3HA_K_orae2BqY3t6cuMNef_ni4=.742eea6e-0a49-4420-adc2-832a077b8542@github.com>
References: <xRyDMAsSZ7obqpr3Aoc5qrHqILeJMxFVCeiRdctMI3U=.d5d3cd56-32eb-4431-ac01-081822fc86c6@github.com>
 <v-lLqE7QmMb0Mq6DW18Q1igG3WMHNZHLqKVO6AHigWU=.c8bf86d2-4c95-409d-8eac-a0ce7d660d9a@github.com>
 <JUtCpfYxYkzw0CutHCbSfbFKNU0xadqFQMJx6x7meS4=.0517145f-be05-41f2-9d85-03d022d103a0@github.com>
 <pvOc4bvTkPBH-Jvx3HA_K_orae2BqY3t6cuMNef_ni4=.742eea6e-0a49-4420-adc2-832a077b8542@github.com>
Message-ID: <d6h4RNYI0FMm2-W1o1D-WXC6V-XrRNphkil-UhNsqHc=.2f49cb08-8366-4955-a3ab-67f4f5701f04@github.com>

On Sun, 12 May 2024 13:05:48 GMT, Doug Lea <dl at openjdk.org> wrote:

>> The goal is to reduce the worst form of contention: when queue arrays are laid out adjacently in memory. Increasing sizes has some impact but with diminishing returns. Thanks for the comment as a reminder that I haven't rechecked this lately in light of other layout changes. Will do.
>
> After recheckiing, the best policy is to leave internal queues the same, but initialize external queues larger.

Probably a misplaced post again, but why can't you allocate an array of arrays
where the outer array is 30
and the inner array will be doubled, 
then the segment can be calculated by log(index)
with: resize O(1), read/write O(1).

This approach can also be used in ConcurrentHashMap
sample implementation 
https://github.com/sunmisc/wormhole/blob/main/main/src/main/java/sunmisc/utils/concurrent/memory/ReferenceSegmentMemory.java

I don't know if this method exists anywhere else, I invented it, maybe it was invented before me.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19131#discussion_r1610669070

From jvernee at openjdk.org  Wed May 22 21:36:03 2024
From: jvernee at openjdk.org (Jorn Vernee)
Date: Wed, 22 May 2024 21:36:03 GMT
Subject: RFR: 8331865: Consolidate size and alignment checks in LayoutPath
 [v3]
In-Reply-To: <206PC955P0Z45jL6ZYWY-gRNyuyw0t2eeJBBE8-yRsY=.5c98c55d-0192-4d79-ba27-0c1a44e69b89@github.com>
References: <CvKkdESp5-uHiuZtQvGortWnzOMV89pfjaCHNBIV4B4=.51ad0f01-2371-48af-b3c6-8a9b80518cdb@github.com>
 <206PC955P0Z45jL6ZYWY-gRNyuyw0t2eeJBBE8-yRsY=.5c98c55d-0192-4d79-ba27-0c1a44e69b89@github.com>
Message-ID: <wkYW4EE0CyKepXRtF8hG79D6Oeh7HLQQF83UtgHEmEU=.962392ad-a43a-470b-ac7f-1edb4c21382c@github.com>

On Tue, 21 May 2024 10:20:27 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> When creating a nested memory access var handle, we ensure that the segment is accessed at the correct alignment for the root layout being accessed. But we do not ensure that the segment has at least the size of the accessed root layout. Example:
>> 
>> 
>> MemoryLayout LAYOUT = sequenceLayout(2, structLayout(JAVA_INT.withName("x"), JAVA_INT.withName("y")));
>> VarHandle X_HANDLE = LAYOUT.varHandle(PathElement.sequenceElement(), PathElement.groupElement("x"));
>> 
>> 
>> If I have a memory segment whose size is 12, I can successfully call X_HANDLE on it with index 1, like so:
>> 
>> 
>> MemorySegment segment = Arena.ofAuto().allocate(12);
>> int x = (int)X_HANDLE.get(segment, 0, 1);
>> 
>> 
>> This seems incorrect: after all, the provided segment doesn't have enough space to fit _two_ elements of the nested structs. 
>> 
>> This PR adds checks to detect this kind of scenario earlier, thus improving usability. To achieve this we could, in principle, just tweak `LayoutPath::checkEnclosingLayout` and add the required size check.
>> 
>> But doing so will add yet another redundant check on top of the other already added by [pull/19124](https://git.openjdk.org/jdk/pull/19124). Instead, this PR rethinks how memory segment var handles are created, in order to eliminate redundant checks.
>> 
>> The main observation is that size and alignment checks depend on an _enclosing_ layout. This layout *might* be the very same value layout being accessed (this is the case when e.g. using `JAVA_INT.varHandle()`). But, in the general case, the accessed value layout and the enclosing layout might differ (e.g. think about accessing a struct field).
>> 
>> Furthermore, the enclosing layout check depends on the _base_ offset at which the segment is accessed, _prior_ to any index computation that occurs if the accessed layout path has any open elements. It is important to notice that this base offset is only available when looking at the var handle that is returned to the user. For instance, an indexed var handle with coordinates:
>> 
>> 
>> (MemorySegment, long /* base */, long /* index 1 */, long /* index 2 */, long /* index 3 */)
>> 
>> 
>> Is obtained through adaptation, by taking a more basic var handle of the form:
>> 
>> 
>> (MemorySegment, long /* offset */)
>> 
>> 
>> And then injecting the result of the index multiplication into `offset`. As such, we can't add an enclosing layout check inside the var handle returned by `VarHandles::memorySegmentViewHandle`, as doing so will end up seeing the *wrong* off...
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix typo in javadoc

Marked as reviewed by jvernee (Reviewer).

src/java.base/share/classes/java/lang/invoke/X-VarHandleSegmentView.java.template line 123:

> 121:     static $type$ get(VarHandle ob, Object obb, long base) {
> 122:         VarHandleSegmentViewBase handle = (VarHandleSegmentViewBase)ob;
> 123:         AbstractMemorySegmentImpl bb = checkReadOnly(obb, true);

For getter methods, which pass a constant `true` here, `checkReadOnly` essentially just does a null check and cast on the segment. Not sure if it's worth simplifying... (I'm happy if you want to leave it like this as well)

-------------

PR Review: https://git.openjdk.org/jdk/pull/19251#pullrequestreview-2072366007
PR Review Comment: https://git.openjdk.org/jdk/pull/19251#discussion_r1610647133

From kcr at openjdk.org  Wed May 22 21:45:10 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 22 May 2024 21:45:10 GMT
Subject: RFR: 8331671: Implement JEP 472: Prepare to Restrict the Use of
 JNI [v8]
In-Reply-To: <vWr2PdgTv6vEllxW8820KO3aZ3tR3xvMhCxD2k7QpS0=.8bfd6c47-6c93-4fc3-aced-7079889aa6a2@github.com>
References: <CZGbki5iFdCGPPagE-ya-_L8Nkgf7OunywApOsxC548=.2cee82fa-a5d2-4165-b012-30982a85030a@github.com>
 <vWr2PdgTv6vEllxW8820KO3aZ3tR3xvMhCxD2k7QpS0=.8bfd6c47-6c93-4fc3-aced-7079889aa6a2@github.com>
Message-ID: <qjJH1kyq5odcLXm7ATxtnCY-EgNNWycboa8G2FAZjtg=.1c382646-3ed9-4506-b182-4efe832f79a8@github.com>

On Fri, 17 May 2024 13:38:25 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This PR implements [JEP 472](https://openjdk.org/jeps/472), by restricting the use of JNI in the following ways:
>> 
>> * `System::load` and `System::loadLibrary` are now restricted methods
>> * `Runtime::load` and `Runtime::loadLibrary` are now restricted methods
>> * binding a JNI `native` method declaration to a native implementation is now considered a restricted operation
>> 
>> This PR slightly changes the way in which the JDK deals with restricted methods, even for FFM API calls. In Java 22, the single `--enable-native-access` was used both to specify a set of modules for which native access should be allowed *and* to specify whether illegal native access (that is, native access occurring from a module not specified by `--enable-native-access`) should be treated as an error or a warning. More specifically, an error is only issued if the `--enable-native-access flag` is used at least once.
>> 
>> Here, a new flag is introduced, namely `illegal-native-access=allow/warn/deny`, which is used to specify what should happen when access to a restricted method and/or functionality is found outside the set of modules specified with `--enable-native-access`. The default policy is `warn`, but users can select `allow` to suppress the warnings, or `deny` to cause `IllegalCallerException` to be thrown. This aligns the treatment of restricted methods with other mechanisms, such as `--illegal-access` and the more recent `--sun-misc-unsafe-memory-access`.
>> 
>> Some changes were required in the package-info javadoc for `java.lang.foreign`, to reflect the changes in the command line flags described above.
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address review comments

I tested this with JavaFX and everything is working as I would expect. Without any options, I get the expected warnings, one time per modules for the three `javafx.*` modules that use JNI. If I pass the `--enable-native-access` options at runtime, listing those three modules, there is no warning. Further, I confirm that if I pass that option to jlink or jpackage when creating a custom runtime, there is no warning.

-------------

Marked as reviewed by kcr (Author).

PR Review: https://git.openjdk.org/jdk/pull/19213#pullrequestreview-2072430338

From sgibbons at openjdk.org  Wed May 22 21:45:50 2024
From: sgibbons at openjdk.org (Scott Gibbons)
Date: Wed, 22 May 2024 21:45:50 GMT
Subject: RFR: 8320448: Accelerate IndexOf using AVX2 [v28]
In-Reply-To: <uWi4QxH31hL93771gkl_GgvP0m84IRSoR_1Yi8hD17E=.bc6ed458-7081-4c3f-9348-f59358fa05a4@github.com>
References: <uWi4QxH31hL93771gkl_GgvP0m84IRSoR_1Yi8hD17E=.bc6ed458-7081-4c3f-9348-f59358fa05a4@github.com>
Message-ID: <X8Y4ZPhNrNT7sExcHSZVFEmAGMBGiAZcIgIo75VB7kE=.2adc6ab8-27ea-41d7-9b8f-d1dec14d4358@github.com>

> Re-write the IndexOf code without the use of the pcmpestri instruction, only using AVX2 instructions.  This change accelerates String.IndexOf on average 1.3x for AVX2.  The benchmark numbers:
> 
> 
> Benchmark	                                               Score		Latest		
> StringIndexOf.advancedWithMediumSub   343.573		317.934		0.925375393x
> StringIndexOf.advancedWithShortSub1	  1039.081		1053.96		1.014319384x
> StringIndexOf.advancedWithShortSub2	      55.828		110.541		1.980027943x
> StringIndexOf.constantPattern	                9.361		11.906		1.271872663x
> StringIndexOf.searchCharLongSuccess	        4.216		4.218		1.000474383x
> StringIndexOf.searchCharMediumSuccess	3.133		3.216		1.02649218x
> StringIndexOf.searchCharShortSuccess	3.76		        3.761		1.000265957x
> StringIndexOf.success	                                9.186		9.713		1.057369911x
> StringIndexOf.successBig	                      14.341		46.343		3.231504079x
> StringIndexOfChar.latin1_AVX2_String	  6220.918		12154.52		1.953814533x
> StringIndexOfChar.latin1_AVX2_char	  5503.556		5540.044		1.006629895x
> StringIndexOfChar.latin1_SSE4_String	  6978.854		6818.689		0.977049957x
> StringIndexOfChar.latin1_SSE4_char	  5657.499		5474.624		0.967675646x
> StringIndexOfChar.latin1_Short_String	  7132.541		6863.359		0.962260014x
> StringIndexOfChar.latin1_Short_char	16013.389	      16162.437		1.009307711x
> StringIndexOfChar.latin1_mixed_String	  7386.123	      14771.622		1.999915517x
> StringIndexOfChar.latin1_mixed_char	  9901.671		9782.245		0.987938803

Scott Gibbons has updated the pull request incrementally with one additional commit since the last revision:

  Remove DO_EARLY_BAILOUT

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/16753/files
  - new: https://git.openjdk.org/jdk/pull/16753/files/ed4451d1..027daf73

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16753&range=27
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16753&range=26-27

  Stats: 19 lines in 1 file changed: 0 ins; 19 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/16753.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16753/head:pull/16753

PR: https://git.openjdk.org/jdk/pull/16753

From mdoerr at openjdk.org  Wed May 22 21:46:12 2024
From: mdoerr at openjdk.org (Martin Doerr)
Date: Wed, 22 May 2024 21:46:12 GMT
Subject: RFR: 8327964: Simplify BigInteger.implMultiplyToLen intrinsic [v6]
In-Reply-To: <GkTIvOKs4GDKUOPjaw893H4fAoeBDuzQn4kKnQqG2dA=.7762f50b-40b1-4763-940b-7e0c8a66d466@github.com>
References: <Z5U-3OSq9_rd0t6DHNRhjF3LHtc9b6orz-mcQ4Uqzl8=.c4f0a0b8-9e10-4505-82f7-7d3a82929d22@github.com>
 <GkTIvOKs4GDKUOPjaw893H4fAoeBDuzQn4kKnQqG2dA=.7762f50b-40b1-4763-940b-7e0c8a66d466@github.com>
Message-ID: <eLbsuGfppmWzjEgfWQTMmaCZ7Lc0zIdlEnWC7tgDY54=.a07edd7c-e905-41ee-9612-a423df6e91b6@github.com>

On Wed, 22 May 2024 14:47:43 GMT, Yudi Zheng <yzheng at openjdk.org> wrote:

>> Moving array construction within BigInteger.implMultiplyToLen intrinsic candidate to its caller simplifies the intrinsic implementation in JIT compiler.
>
> Yudi Zheng has updated the pull request incrementally with one additional commit since the last revision:
> 
>   address comments.

PPC64 part and shared code looks correct. "java/math/BigInteger" tests have passed on PPC64. I didn't review the other platforms.

-------------

Marked as reviewed by mdoerr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18226#pullrequestreview-2072434441

From dl at openjdk.org  Wed May 22 23:28:06 2024
From: dl at openjdk.org (Doug Lea)
Date: Wed, 22 May 2024 23:28:06 GMT
Subject: RFR: 8322732: ForkJoinPool may underutilize cores in async mode
 [v3]
In-Reply-To: <XtXQ5VAlOygdqWp0GJB9eMzbggl3v2AJijdOj7-pI3I=.44c78ae5-85fb-4adc-abce-77c2576f4ab4@github.com>
References: <xRyDMAsSZ7obqpr3Aoc5qrHqILeJMxFVCeiRdctMI3U=.d5d3cd56-32eb-4431-ac01-081822fc86c6@github.com>
 <NsHVtOWDMBDqRJ0plVTy1pG9x4E2O9-q2WzeV6U7p4Q=.dae1bcaf-4b00-403f-b260-3efb3b556cab@github.com>
 <XtXQ5VAlOygdqWp0GJB9eMzbggl3v2AJijdOj7-pI3I=.44c78ae5-85fb-4adc-abce-77c2576f4ab4@github.com>
Message-ID: <jYpKbNbE5YlxrqUhfvD9QVEMZAhQVocG-1YiwnSNe_Q=.64ff545b-edfe-4110-9a7c-28ba0bc53a66@github.com>

On Wed, 22 May 2024 15:45:43 GMT, Viktor Klang <vklang at openjdk.org> wrote:

>> Doug Lea 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 36 additional commits since the last revision:
>> 
>>  - Merge branch 'openjdk:master' into JDK-8322732
>>  - More performance tradoffs
>>  - Address review comments
>>  - Merge branch 'openjdk:master' into JDK-8322732
>>  - Repack some fields; adjust control flow
>>  - Merge branch 'openjdk:master' into JDK-8322732
>>  - Next version
>>  - Merge branch 'openjdk:master' into JDK-8322732
>>  - Reduce unneeded signals
>>  - Merge branch 'openjdk:master' into JDK-8322732
>>  - ... and 26 more: https://git.openjdk.org/jdk/compare/709b497f...f1fc4f3e
>
> src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 586:
> 
>> 584:      * term. We use Marsaglia XorShifts, seeded with the Weyl sequence
>> 585:      * from ThreadLocalRandom probes, which are cheap and
>> 586:      * suffice. Each queue's polling attempt o avoid becoming stuck
> 
> Suggestion:
> 
>      * suffice. Each queue's polling attempt to avoid becoming stuck

thanks; fixed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19131#discussion_r1610782380

From dl at openjdk.org  Wed May 22 23:31:09 2024
From: dl at openjdk.org (Doug Lea)
Date: Wed, 22 May 2024 23:31:09 GMT
Subject: RFR: 8322732: ForkJoinPool may underutilize cores in async mode
 [v3]
In-Reply-To: <hAZF--4zVOz2utGMo4UiCDoPiRFRyqAXFfUYn_Qiks8=.2554dbcb-63b9-4897-bdb8-57a78828689e@github.com>
References: <xRyDMAsSZ7obqpr3Aoc5qrHqILeJMxFVCeiRdctMI3U=.d5d3cd56-32eb-4431-ac01-081822fc86c6@github.com>
 <NsHVtOWDMBDqRJ0plVTy1pG9x4E2O9-q2WzeV6U7p4Q=.dae1bcaf-4b00-403f-b260-3efb3b556cab@github.com>
 <hAZF--4zVOz2utGMo4UiCDoPiRFRyqAXFfUYn_Qiks8=.2554dbcb-63b9-4897-bdb8-57a78828689e@github.com>
Message-ID: <mTl58u8q91ZCvxHcZ0qK3L3ml5o0iTgbMr45NArquJc=.0aea535b-2753-42c6-bd80-fa75547a68bd@github.com>

On Wed, 22 May 2024 15:51:05 GMT, Viktor Klang <vklang at openjdk.org> wrote:

>> Doug Lea 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 36 additional commits since the last revision:
>> 
>>  - Merge branch 'openjdk:master' into JDK-8322732
>>  - More performance tradoffs
>>  - Address review comments
>>  - Merge branch 'openjdk:master' into JDK-8322732
>>  - Repack some fields; adjust control flow
>>  - Merge branch 'openjdk:master' into JDK-8322732
>>  - Next version
>>  - Merge branch 'openjdk:master' into JDK-8322732
>>  - Reduce unneeded signals
>>  - Merge branch 'openjdk:master' into JDK-8322732
>>  - ... and 26 more: https://git.openjdk.org/jdk/compare/44041895...f1fc4f3e
>
> src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 1884:
> 
>> 1882:             else
>> 1883:                 nc = (v.stackPred & LMASK) | (c & TC_MASK);
>> 1884:             if (c == (c = compareAndExchangeCtl(c, nc | ac))) {
> 
> So the TTAS wasn't worth it on some architectures? ?

Right. so just added to code path

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19131#discussion_r1610783672

From dl at openjdk.org  Wed May 22 23:36:02 2024
From: dl at openjdk.org (Doug Lea)
Date: Wed, 22 May 2024 23:36:02 GMT
Subject: RFR: 8322732: ForkJoinPool may underutilize cores in async mode
 [v2]
In-Reply-To: <t2Yzp7nujqzRe7bo3xKjoJqR5_9CdQgHhsBNbuBkBdM=.4dbcc790-7134-4421-b798-4bc589c41d32@github.com>
References: <xRyDMAsSZ7obqpr3Aoc5qrHqILeJMxFVCeiRdctMI3U=.d5d3cd56-32eb-4431-ac01-081822fc86c6@github.com>
 <1h7ssJJnGUbpqORLsdM_Udcl2dqYsrjuXP6ZPTH_bVo=.ce5a42ba-4eae-4430-9f7d-b6036a45ef9b@github.com>
 <t2Yzp7nujqzRe7bo3xKjoJqR5_9CdQgHhsBNbuBkBdM=.4dbcc790-7134-4421-b798-4bc589c41d32@github.com>
Message-ID: <sNcYW_EsNH8xT1ZrNVSLfPwlPzL-LGxw20-SKCFzlBI=.58fde65e-551b-4ccf-9f95-b3a9c9352f5e@github.com>

On Thu, 16 May 2024 10:29:48 GMT, Sunmisc Unsafe <duke at openjdk.org> wrote:

>> Doug Lea has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Address review comments
>
> Maybe I don't quite understand, or I don't have proof, But wouldn't it be better if invokeAll in FIFO mode (asyncMode) traverses the Future list as a FIFO (currently it traverses in LIFO order)

@sunmisc invokeAll doesn't specify an exec or join order; forward exec snf inverse normally uses fewest resources.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19131#issuecomment-2125944250

From dl at openjdk.org  Wed May 22 23:50:03 2024
From: dl at openjdk.org (Doug Lea)
Date: Wed, 22 May 2024 23:50:03 GMT
Subject: RFR: 8322732: ForkJoinPool may underutilize cores in async mode
 [v3]
In-Reply-To: <d6h4RNYI0FMm2-W1o1D-WXC6V-XrRNphkil-UhNsqHc=.2f49cb08-8366-4955-a3ab-67f4f5701f04@github.com>
References: <xRyDMAsSZ7obqpr3Aoc5qrHqILeJMxFVCeiRdctMI3U=.d5d3cd56-32eb-4431-ac01-081822fc86c6@github.com>
 <v-lLqE7QmMb0Mq6DW18Q1igG3WMHNZHLqKVO6AHigWU=.c8bf86d2-4c95-409d-8eac-a0ce7d660d9a@github.com>
 <JUtCpfYxYkzw0CutHCbSfbFKNU0xadqFQMJx6x7meS4=.0517145f-be05-41f2-9d85-03d022d103a0@github.com>
 <pvOc4bvTkPBH-Jvx3HA_K_orae2BqY3t6cuMNef_ni4=.742eea6e-0a49-4420-adc2-832a077b8542@github.com>
 <d6h4RNYI0FMm2-W1o1D-WXC6V-XrRNphkil-UhNsqHc=.2f49cb08-8366-4955-a3ab-67f4f5701f04@github.com>
Message-ID: <9ujFd5Ou_PzfvPEI9nNpcCeHLgD16FcLU_A1ieJ-lWE=.8c4c9122-d5c6-4bc8-bd71-11a3822606dc@github.com>

On Wed, 22 May 2024 21:23:04 GMT, Sunmisc Unsafe <duke at openjdk.org> wrote:

>> After recheckiing, the best policy is to leave internal queues the same, but initialize external queues larger.
>
> Probably a misplaced post again, but why can't you allocate an array of arrays
> where the outer array is 30
> and the inner array will be doubled, 
> then the segment can be calculated by log(index)
> with: resize O(1), read/write O(1).
> 
> This approach can also be used in ConcurrentHashMap
> sample implementation 
> https://github.com/sunmisc/wormhole/blob/main/main/src/main/java/sunmisc/utils/concurrent/memory/ReferenceSegmentMemory.java
> 
> I don't know if this method exists anywhere else, I invented it, maybe it was invented before me.

Thanks for link to sample code link. I had tried something like this in an analogous case in SubmissionPublisher, but couldn't reduce overhead enough to be worthwhile. I may try again there first,m since resizing there is more common and disruptive.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19131#discussion_r1610792954

From darcy at openjdk.org  Thu May 23 01:01:09 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Thu, 23 May 2024 01:01:09 GMT
Subject: RFR: 8320575: generic type information lost on mandated parameters
 of record's compact constructors [v7]
In-Reply-To: <8kc1FcJ-ilYErhHEJRu9S_64FWwg8lI5kZfTPDEeHYA=.7b75a759-2927-4434-8ec6-24f127f01a7e@github.com>
References: <20VdLsPE7Md_hxgniEhF0WPmdo_WXqbBswWdn2Az9N4=.0821e94c-4745-41e9-95a4-147f98657718@github.com>
 <UHA4xz5Ute6D_dTNMO4Ki4Jw7I3U7i6D5idwqPiuQ_w=.d44fe606-37f4-4451-9674-a0b1fa823647@github.com>
 <8kc1FcJ-ilYErhHEJRu9S_64FWwg8lI5kZfTPDEeHYA=.7b75a759-2927-4434-8ec6-24f127f01a7e@github.com>
Message-ID: <OMAhBsg48oTHmGMS5mzkPozNdqn7X05IXUKO-HY6w1Y=.dd65b533-6ca6-4e92-a4b7-7fb2b3481c47@github.com>

On Tue, 12 Dec 2023 22:21:29 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fixing comment
>
> As the core reflection code will encounter record classes compiled before and after the javac code generation change, if the old behavior can be triggered in javac using `--release $OLD`/`--source $OLD`, that would be helpful to include as part of the testing.

> @jddarcy I have uploaded a new commit addressing your comments, thanks

Thanks @vicente-romero-oracle .

As a general comment, please update all the links to "mandated" so that the text "implicitly declared" get linked to the MANDATED enum constant. The term "mandated" may not familiar to core reflection readers, but is defined elsewhere in the platform so I don't think having the term "mandated" appears in the text in core reflection is necessarily helpful to readers. Concretely, replace javadoc like
`
implicitly ({@linkplain java.compiler/javax.lang.model.util.Elements.Origin#MANDATED mandated}) declared`

with

{@linkplain java.compiler/javax.lang.model.util.Elements.Origin#MANDATED implicitly declared}

Also, before this PR is pushed, please reflow the updated paragraphs so avoid introducing long lines of text.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17070#issuecomment-2126006488

From jpai at openjdk.org  Thu May 23 01:06:11 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 23 May 2024 01:06:11 GMT
Subject: RFR: 8332490: JMH
 org.openjdk.bench.java.util.zip.InflaterInputStreams.inflaterInputStreamRead
 OOM [v2]
In-Reply-To: <a9-gLlH5AgmhKJoJM5e7j5gZD-W3oEFl8SpX64WTHUA=.879a2374-aadf-4b5b-921a-3444c3de3797@github.com>
References: <nisubUXku9Aki5ZnEyRq7_l1TGWUpIIaEKpqZMo2DQw=.a01dd330-cfbb-4a6e-85b1-62378b963419@github.com>
 <a9-gLlH5AgmhKJoJM5e7j5gZD-W3oEFl8SpX64WTHUA=.879a2374-aadf-4b5b-921a-3444c3de3797@github.com>
Message-ID: <IF3frCj01rbaUWo9ue3Hm8646uh9O0Pt_qQxpIgWZCw=.a761a98c-0a06-4c78-89ce-0ed648c80630@github.com>

On Wed, 22 May 2024 07:49:27 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this test-only change for addressing https://bugs.openjdk.org/browse/JDK-8332490?
>> 
>> The jmh test opens a `InflaterInputStream`, reads the stream contents, but then doesn't close the stream. This can lead to resource leak which can then cause OOM as noted in that JBS issue.
>> 
>> The commit in this PR closes the `InflaterInputStream` when the reads complete.
>> 
>> 
>> make test TEST=micro:org.openjdk.bench.java.util.zip.InflaterInputStreams
>> 
>> and
>> 
>> 
>> ./build/macosx-aarch64/images/jdk/bin/java -jar ./build/macosx-aarch64/images/test/micro/benchmarks.jar org.openjdk.bench.java.util.zip.InflaterInputStreams.inflaterInputStreamRead -t max -f 1 -wi 2 -foe true
>> 
>> pass after this change.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add a comment

Thank you Alan and Claes for the reviews.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19340#issuecomment-2126009374

From jpai at openjdk.org  Thu May 23 01:06:11 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 23 May 2024 01:06:11 GMT
Subject: Integrated: 8332490: JMH
 org.openjdk.bench.java.util.zip.InflaterInputStreams.inflaterInputStreamRead
 OOM
In-Reply-To: <nisubUXku9Aki5ZnEyRq7_l1TGWUpIIaEKpqZMo2DQw=.a01dd330-cfbb-4a6e-85b1-62378b963419@github.com>
References: <nisubUXku9Aki5ZnEyRq7_l1TGWUpIIaEKpqZMo2DQw=.a01dd330-cfbb-4a6e-85b1-62378b963419@github.com>
Message-ID: <eliJgWRBDV7zADzJpOEpZkkzSB8AlC1d2rqSP3bz9Uk=.73dc3121-7f67-472d-a08c-7dbca2491b74@github.com>

On Wed, 22 May 2024 05:16:42 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this test-only change for addressing https://bugs.openjdk.org/browse/JDK-8332490?
> 
> The jmh test opens a `InflaterInputStream`, reads the stream contents, but then doesn't close the stream. This can lead to resource leak which can then cause OOM as noted in that JBS issue.
> 
> The commit in this PR closes the `InflaterInputStream` when the reads complete.
> 
> 
> make test TEST=micro:org.openjdk.bench.java.util.zip.InflaterInputStreams
> 
> and
> 
> 
> ./build/macosx-aarch64/images/jdk/bin/java -jar ./build/macosx-aarch64/images/test/micro/benchmarks.jar org.openjdk.bench.java.util.zip.InflaterInputStreams.inflaterInputStreamRead -t max -f 1 -wi 2 -foe true
> 
> pass after this change.

This pull request has now been integrated.

Changeset: 98f6a808
Author:    Jaikiran Pai <jpai at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/98f6a80852383dcbdad7292b7d269a8547d54d45
Stats:     5 lines in 1 file changed: 3 ins; 0 del; 2 mod

8332490: JMH org.openjdk.bench.java.util.zip.InflaterInputStreams.inflaterInputStreamRead OOM

Reviewed-by: aturbanov, redestad

-------------

PR: https://git.openjdk.org/jdk/pull/19340

From liach at openjdk.org  Thu May 23 01:08:03 2024
From: liach at openjdk.org (Chen Liang)
Date: Thu, 23 May 2024 01:08:03 GMT
Subject: RFR: 8320575: generic type information lost on mandated parameters
 of record's compact constructors [v7]
In-Reply-To: <OMAhBsg48oTHmGMS5mzkPozNdqn7X05IXUKO-HY6w1Y=.dd65b533-6ca6-4e92-a4b7-7fb2b3481c47@github.com>
References: <20VdLsPE7Md_hxgniEhF0WPmdo_WXqbBswWdn2Az9N4=.0821e94c-4745-41e9-95a4-147f98657718@github.com>
 <UHA4xz5Ute6D_dTNMO4Ki4Jw7I3U7i6D5idwqPiuQ_w=.d44fe606-37f4-4451-9674-a0b1fa823647@github.com>
 <8kc1FcJ-ilYErhHEJRu9S_64FWwg8lI5kZfTPDEeHYA=.7b75a759-2927-4434-8ec6-24f127f01a7e@github.com>
 <OMAhBsg48oTHmGMS5mzkPozNdqn7X05IXUKO-HY6w1Y=.dd65b533-6ca6-4e92-a4b7-7fb2b3481c47@github.com>
Message-ID: <o6YH0Rw-Ucs6QYzE9gPNSmLRxCf-rJnSUbqW4ncN_zM=.a956dbfd-fbd1-41d4-90de-1c5063d708cf@github.com>

On Thu, 23 May 2024 00:58:14 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> As a general comment, please update all the links to "mandated" so that the text "implicitly declared" get linked to the MANDATED enum constant.

Should we update the API specification for `Parameter::isImplicit`, which checks the "mandated" status but does not refer to this concept at all?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17070#issuecomment-2126011251

From darcy at openjdk.org  Thu May 23 01:27:13 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Thu, 23 May 2024 01:27:13 GMT
Subject: RFR: 8320575: generic type information lost on mandated parameters
 of record's compact constructors [v7]
In-Reply-To: <o6YH0Rw-Ucs6QYzE9gPNSmLRxCf-rJnSUbqW4ncN_zM=.a956dbfd-fbd1-41d4-90de-1c5063d708cf@github.com>
References: <20VdLsPE7Md_hxgniEhF0WPmdo_WXqbBswWdn2Az9N4=.0821e94c-4745-41e9-95a4-147f98657718@github.com>
 <UHA4xz5Ute6D_dTNMO4Ki4Jw7I3U7i6D5idwqPiuQ_w=.d44fe606-37f4-4451-9674-a0b1fa823647@github.com>
 <8kc1FcJ-ilYErhHEJRu9S_64FWwg8lI5kZfTPDEeHYA=.7b75a759-2927-4434-8ec6-24f127f01a7e@github.com>
 <OMAhBsg48oTHmGMS5mzkPozNdqn7X05IXUKO-HY6w1Y=.dd65b533-6ca6-4e92-a4b7-7fb2b3481c47@github.com>
 <o6YH0Rw-Ucs6QYzE9gPNSmLRxCf-rJnSUbqW4ncN_zM=.a956dbfd-fbd1-41d4-90de-1c5063d708cf@github.com>
Message-ID: <P4-danMeHzIYJ8Xzqg5uophYjt6sBQYotXSqI7w0ttw=.c1b0790d-5364-4490-b5e7-bbf25f9499ca@github.com>

On Thu, 23 May 2024 01:05:07 GMT, Chen Liang <liach at openjdk.org> wrote:

> > As a general comment, please update all the links to "mandated" so that the text "implicitly declared" get linked to the MANDATED enum constant.
> 
> Should we update the API specification for `Parameter::isImplicit`, which checks the "mandated" status but does not refer to this concept at all?

I think it would be a reasonable separate RFE for Parameter:isImplicit to have an `@see` or `@link` tag to MANDATED.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17070#issuecomment-2126025587

From sgibbons at openjdk.org  Thu May 23 01:29:45 2024
From: sgibbons at openjdk.org (Scott Gibbons)
Date: Thu, 23 May 2024 01:29:45 GMT
Subject: RFR: 8320448: Accelerate IndexOf using AVX2 [v29]
In-Reply-To: <uWi4QxH31hL93771gkl_GgvP0m84IRSoR_1Yi8hD17E=.bc6ed458-7081-4c3f-9348-f59358fa05a4@github.com>
References: <uWi4QxH31hL93771gkl_GgvP0m84IRSoR_1Yi8hD17E=.bc6ed458-7081-4c3f-9348-f59358fa05a4@github.com>
Message-ID: <3Qow6_N97mxWzdMj2zmgj9MHmDWuIG4LYm_Lj4arxcg=.c8dba6ef-26bf-48e5-9a70-b010dcc8940b@github.com>

> Re-write the IndexOf code without the use of the pcmpestri instruction, only using AVX2 instructions.  This change accelerates String.IndexOf on average 1.3x for AVX2.  The benchmark numbers:
> 
> 
> Benchmark	                                               Score		Latest		
> StringIndexOf.advancedWithMediumSub   343.573		317.934		0.925375393x
> StringIndexOf.advancedWithShortSub1	  1039.081		1053.96		1.014319384x
> StringIndexOf.advancedWithShortSub2	      55.828		110.541		1.980027943x
> StringIndexOf.constantPattern	                9.361		11.906		1.271872663x
> StringIndexOf.searchCharLongSuccess	        4.216		4.218		1.000474383x
> StringIndexOf.searchCharMediumSuccess	3.133		3.216		1.02649218x
> StringIndexOf.searchCharShortSuccess	3.76		        3.761		1.000265957x
> StringIndexOf.success	                                9.186		9.713		1.057369911x
> StringIndexOf.successBig	                      14.341		46.343		3.231504079x
> StringIndexOfChar.latin1_AVX2_String	  6220.918		12154.52		1.953814533x
> StringIndexOfChar.latin1_AVX2_char	  5503.556		5540.044		1.006629895x
> StringIndexOfChar.latin1_SSE4_String	  6978.854		6818.689		0.977049957x
> StringIndexOfChar.latin1_SSE4_char	  5657.499		5474.624		0.967675646x
> StringIndexOfChar.latin1_Short_String	  7132.541		6863.359		0.962260014x
> StringIndexOfChar.latin1_Short_char	16013.389	      16162.437		1.009307711x
> StringIndexOfChar.latin1_mixed_String	  7386.123	      14771.622		1.999915517x
> StringIndexOfChar.latin1_mixed_char	  9901.671		9782.245		0.987938803

Scott Gibbons has updated the pull request incrementally with one additional commit since the last revision:

  Check macos build

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/16753/files
  - new: https://git.openjdk.org/jdk/pull/16753/files/027daf73..42af0b50

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16753&range=28
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16753&range=27-28

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/16753.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16753/head:pull/16753

PR: https://git.openjdk.org/jdk/pull/16753

From sgibbons at openjdk.org  Thu May 23 02:03:26 2024
From: sgibbons at openjdk.org (Scott Gibbons)
Date: Thu, 23 May 2024 02:03:26 GMT
Subject: RFR: 8320448: Accelerate IndexOf using AVX2 [v30]
In-Reply-To: <uWi4QxH31hL93771gkl_GgvP0m84IRSoR_1Yi8hD17E=.bc6ed458-7081-4c3f-9348-f59358fa05a4@github.com>
References: <uWi4QxH31hL93771gkl_GgvP0m84IRSoR_1Yi8hD17E=.bc6ed458-7081-4c3f-9348-f59358fa05a4@github.com>
Message-ID: <XUphW0oJVkXWaRMgYGXntl22owSREeX8w1BgHUMkEcE=.17ee1f73-3010-408e-a145-466a03cb9ed1@github.com>

> Re-write the IndexOf code without the use of the pcmpestri instruction, only using AVX2 instructions.  This change accelerates String.IndexOf on average 1.3x for AVX2.  The benchmark numbers:
> 
> 
> Benchmark	                                               Score		Latest		
> StringIndexOf.advancedWithMediumSub   343.573		317.934		0.925375393x
> StringIndexOf.advancedWithShortSub1	  1039.081		1053.96		1.014319384x
> StringIndexOf.advancedWithShortSub2	      55.828		110.541		1.980027943x
> StringIndexOf.constantPattern	                9.361		11.906		1.271872663x
> StringIndexOf.searchCharLongSuccess	        4.216		4.218		1.000474383x
> StringIndexOf.searchCharMediumSuccess	3.133		3.216		1.02649218x
> StringIndexOf.searchCharShortSuccess	3.76		        3.761		1.000265957x
> StringIndexOf.success	                                9.186		9.713		1.057369911x
> StringIndexOf.successBig	                      14.341		46.343		3.231504079x
> StringIndexOfChar.latin1_AVX2_String	  6220.918		12154.52		1.953814533x
> StringIndexOfChar.latin1_AVX2_char	  5503.556		5540.044		1.006629895x
> StringIndexOfChar.latin1_SSE4_String	  6978.854		6818.689		0.977049957x
> StringIndexOfChar.latin1_SSE4_char	  5657.499		5474.624		0.967675646x
> StringIndexOfChar.latin1_Short_String	  7132.541		6863.359		0.962260014x
> StringIndexOfChar.latin1_Short_char	16013.389	      16162.437		1.009307711x
> StringIndexOfChar.latin1_mixed_String	  7386.123	      14771.622		1.999915517x
> StringIndexOfChar.latin1_mixed_char	  9901.671		9782.245		0.987938803

Scott Gibbons has updated the pull request incrementally with one additional commit since the last revision:

  Check macos build

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/16753/files
  - new: https://git.openjdk.org/jdk/pull/16753/files/42af0b50..40a1e628

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16753&range=29
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16753&range=28-29

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/16753.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16753/head:pull/16753

PR: https://git.openjdk.org/jdk/pull/16753

From liach at openjdk.org  Thu May 23 03:33:10 2024
From: liach at openjdk.org (Chen Liang)
Date: Thu, 23 May 2024 03:33:10 GMT
Subject: RFR: 8242888: Convert dynamic proxy to hidden classes
Message-ID: <QO0dIumbbHUFWz43pCWbmsqdH5zG8NaVUB9FwNFlbTw=.8fe20db2-9cfc-46e9-9f98-0979259ac882@github.com>

Please review this change that convert dynamic proxies implementations to hidden classes, intended to target JDK 24.

Summary:
1. Adds new implementation while preserving the old implementation behind `-Djdk.reflect.useLegacyProxyImpl=true` in case there are compatibility issues.
2. ClassLoader.defineClass0 takes a ClassLoader instance but discards it in native code; I updated native code to reuse that ClassLoader for Proxy support.
3. ProxyGenerator changes mainly involve using Class data to pass Method list (accessed in a single condy) and removal of obsolete setup code generation.

Testing: tier1 and tier2 have no related failures.

Comment: Since #8278, Proxy has been converted to ClassFile API, and infrastructure has changed; now, the migration to hidden classes is much cleaner and has less impact, such as preserving ProtectionDomain and dynamic module without "anchor classes", and avoiding java.lang.invoke package.

-------------

Commit messages:
 - Fixes
 - Merge branch 'master' of https://github.com/openjdk/jdk into feature/hidden-proxy
 - First draft

Changes: https://git.openjdk.org/jdk/pull/19356/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19356&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8242888
  Stats: 303 lines in 8 files changed: 70 ins; 153 del; 80 mod
  Patch: https://git.openjdk.org/jdk/pull/19356.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19356/head:pull/19356

PR: https://git.openjdk.org/jdk/pull/19356

From joe.darcy at oracle.com  Thu May 23 04:38:18 2024
From: joe.darcy at oracle.com (Joseph D. Darcy)
Date: Wed, 22 May 2024 21:38:18 -0700
Subject: Deterministic naming of subclasses of `java/lang/reflect/Proxy`
In-Reply-To: <eabfa5ae508e4257bd0c9bbef244637f@kth.se>
References: <bf26eb2f74874e02876b3868311922a9@kth.se>
 <CABe8uE0fk71Xy_PYHikSw9OtXE_i+M9zMbayPEXuTxLWLoy2ag@mail.gmail.com>
 <50405ca9c0a64372bace175b932f9ef7@kth.se>
 <61fbe3d9-9536-4113-adde-6cfc671ba1ee@oracle.com>
 <a860be44e06243799593aa8d67c048cd@kth.se>
 <CABe8uE115=DzYCdnvNazqFuuxtJoZnv9wRUkFA4-PS7g41QLMw@mail.gmail.com>
 <DB7PR02MB35938DCC3A392536B924164AFBEE2@DB7PR02MB3593.eurprd02.prod.outlook.com>
 <a0330ee0-5f45-4ef2-8500-e5fcdb696c52@oracle.com>
 <b214cc1a13fe4885a437e16b420e5483@kth.se>
 <ac2ebe5c-db49-4a2d-a5cd-10440a77aa16@oracle.com>
 <580b3aacd8df48fcaae3399718e229ab@kth.se>
 <CABe8uE065Q3+0yNjtyDF-eJM4LN-MbY9kfC44CnSQ-KM4p862g@mail.gmail.com>
 <b64077d6cf0045e98b630cf888785182@kth.se>
 <eabfa5ae508e4257bd0c9bbef244637f@kth.se>
Message-ID: <116ea43a-696e-4d20-b866-362cfdc20e44@oracle.com>


On 5/22/2024 11:19 AM, Aman Sharma wrote:
>
> Hi,
>
[snip]


> Notice the difference in the order of fields and `helpCommand` method 
> is mapped to a different field name in both classes. This happens 
> because the method array returned by `getMethods` is not sorted in any 
> particular order 
> <https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/lang/Class.java#L2178> 
> when generating a proxy class. What dictates this order? And why is it 
> not deterministic?
>
>
> Regards,
> Aman Sharma


As a general comment, it is _not_ the goal of the API specification to 
(over) specify exact behavior in cases like this.

See as an example the discussion concerning behavioral compatibility 
starting around slide 46 of

"Contributing to OpenJDK: Participating in stewardship for the long-term,"
https://jcp.org/aboutJava/communityprocess/ec-public/materials/2023-06-13/Contributing_to_OpenJDK_2023_04_12.pdf


This approach has evolved over the years and releases.

In this case semantically, the array returned by getMethod is a set and 
the no particular meaning should be read into the order of the elements.

HTH,


-Joe
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240522/4035bb26/attachment-0001.htm>

From alanb at openjdk.org  Thu May 23 05:56:03 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 23 May 2024 05:56:03 GMT
Subject: RFR: 8331879: Clean up non-standard use of /// comments in
 `java.base`
In-Reply-To: <BiSTG8MtjyRt2txRK2DIxsmbPPq6Pvp7QQzOnHXbH6w=.b01b4872-dc8b-4e4f-bae6-bdc501da33a6@github.com>
References: <BiSTG8MtjyRt2txRK2DIxsmbPPq6Pvp7QQzOnHXbH6w=.b01b4872-dc8b-4e4f-bae6-bdc501da33a6@github.com>
Message-ID: <2RfxVIGqDgz9gQ9xO-Mh1cex-4Zg_1wfJFvNKPdG-Ow=.1e91b688-cb86-4f8a-b50b-d94f76b90576@github.com>

On Tue, 7 May 2024 22:23:48 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> A long vertical series of lines beginning /// is replaced by lines beginning //|.

This one looks unusual when it's just one line, I could imagine deleting the "|" in these cases.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19130#issuecomment-2126289283

From alanb at openjdk.org  Thu May 23 06:15:00 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 23 May 2024 06:15:00 GMT
Subject: RFR: 8242888: Convert dynamic proxy to hidden classes
In-Reply-To: <QO0dIumbbHUFWz43pCWbmsqdH5zG8NaVUB9FwNFlbTw=.8fe20db2-9cfc-46e9-9f98-0979259ac882@github.com>
References: <QO0dIumbbHUFWz43pCWbmsqdH5zG8NaVUB9FwNFlbTw=.8fe20db2-9cfc-46e9-9f98-0979259ac882@github.com>
Message-ID: <w7DMSgL_VRu-J78a16RHI7SwIvNMwvtBDXsJCBWqkoQ=.94b90b10-7e08-488b-922b-6f831ddfcf2a@github.com>

On Thu, 23 May 2024 03:28:30 GMT, Chen Liang <liach at openjdk.org> wrote:

> Please review this change that convert dynamic proxies implementations to hidden classes, intended to target JDK 24.
> 
> Summary:
> 1. Adds new implementation while preserving the old implementation behind `-Djdk.reflect.useLegacyProxyImpl=true` in case there are compatibility issues.
> 2. ClassLoader.defineClass0 takes a ClassLoader instance but discards it in native code; I updated native code to reuse that ClassLoader for Proxy support.
> 3. ProxyGenerator changes mainly involve using Class data to pass Method list (accessed in a single condy) and removal of obsolete setup code generation.
> 
> Testing: tier1 and tier2 have no related failures.
> 
> Comment: Since #8278, Proxy has been converted to ClassFile API, and infrastructure has changed; now, the migration to hidden classes is much cleaner and has less impact, such as preserving ProtectionDomain and dynamic module without "anchor classes", and avoiding java.lang.invoke package.

There are compatibility concerns and behavioural differences that will require significant effort to consider before doing this. This is the reason that this one has been kicked down the road several times.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19356#issuecomment-2126310091

From jpai at openjdk.org  Thu May 23 06:23:05 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 23 May 2024 06:23:05 GMT
Subject: RFR: 8331670: Deprecate the Memory-Access Methods in
 sun.misc.Unsafe for Removal [v3]
In-Reply-To: <ENm9bBCzUHGfXN_heTLJXeoiCjCMAciOlbxOnlFM59s=.496c5cc9-5335-497e-9f9f-448acb302c14@github.com>
References: <9FyO4QpCtH2CNkUEE78_Jjd9xs3bv3WJo16jyowHOvY=.e7131b91-37bb-4624-a60e-72a427a24c92@github.com>
 <ENm9bBCzUHGfXN_heTLJXeoiCjCMAciOlbxOnlFM59s=.496c5cc9-5335-497e-9f9f-448acb302c14@github.com>
Message-ID: <Dy219NETwAvvqgYECP3_EDRfiNPuSOSO0Trd3TbqkUk=.6a7d8076-1963-497f-aed0-6d8424f2205e@github.com>

On Tue, 21 May 2024 07:26:17 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> This is the implementation changes for JEP 471.
>> 
>> The methods in sun.misc.Unsafe for on-heap and off-heap access are deprecated for removal. This means a removal warning at compile time. No methods have been removed. A deprecated message is added to each of the methods but unlikely to be seen as the JDK does not generate or publish the API docs for this class.
>> 
>> A new command line option --sun-misc-unsafe-memory-access=$value is introduced to allow or deny access to these methods. The default proposed for JDK 23 is "allow" so no change in behavior compared to JDK 22 or previous releases.
>> 
>> A new test is added to test the command line option settings. The existing micros for FFM that use Unsafe are updated to suppress the removal warning at compile time. A new micro is introduced with a small sample of methods to ensure the changes doesn't cause any perf regressions ([sample results](https://cr.openjdk.org/~alanb/8331670-results.txt)).
>> 
>> For now, the changes include the update to the man page for the "java" command. It might be that this has to be separated out so that it goes with other updates in the release.
>
> Alan Bateman 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
>  - Add removal to DISABLED_WARNINGS
>    Fail at startup if bad value specified to option
>  - Merge
>  - Update man page
>  - Update man page
>  - Fix comment
>  - Merge
>  - Merge
>  - Whitespace
>  - Initial commit

Marked as reviewed by jpai (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/19174#pullrequestreview-2072956262

From alanb at openjdk.org  Thu May 23 06:23:04 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 23 May 2024 06:23:04 GMT
Subject: RFR: 8331671: Implement JEP 472: Prepare to Restrict the Use of
 JNI [v8]
In-Reply-To: <qjJH1kyq5odcLXm7ATxtnCY-EgNNWycboa8G2FAZjtg=.1c382646-3ed9-4506-b182-4efe832f79a8@github.com>
References: <CZGbki5iFdCGPPagE-ya-_L8Nkgf7OunywApOsxC548=.2cee82fa-a5d2-4165-b012-30982a85030a@github.com>
 <vWr2PdgTv6vEllxW8820KO3aZ3tR3xvMhCxD2k7QpS0=.8bfd6c47-6c93-4fc3-aced-7079889aa6a2@github.com>
 <qjJH1kyq5odcLXm7ATxtnCY-EgNNWycboa8G2FAZjtg=.1c382646-3ed9-4506-b182-4efe832f79a8@github.com>
Message-ID: <PNJI-ppWMr7wFNBMrH6Vu59Y8yMiIB0cEMi-idTzdHM=.02d527df-ff5f-45df-9319-645b2e732b3e@github.com>

On Wed, 22 May 2024 21:42:14 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> Further, I confirm that if I pass that option to jlink or jpackage when creating a custom runtime, there is no warning.

Great! What about jpackage without a custom runtime, wondering if --java-options can be tested.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19213#issuecomment-2126320311

From amitkumar at openjdk.org  Thu May 23 07:24:10 2024
From: amitkumar at openjdk.org (Amit Kumar)
Date: Thu, 23 May 2024 07:24:10 GMT
Subject: RFR: 8327964: Simplify BigInteger.implMultiplyToLen intrinsic [v6]
In-Reply-To: <GkTIvOKs4GDKUOPjaw893H4fAoeBDuzQn4kKnQqG2dA=.7762f50b-40b1-4763-940b-7e0c8a66d466@github.com>
References: <Z5U-3OSq9_rd0t6DHNRhjF3LHtc9b6orz-mcQ4Uqzl8=.c4f0a0b8-9e10-4505-82f7-7d3a82929d22@github.com>
 <GkTIvOKs4GDKUOPjaw893H4fAoeBDuzQn4kKnQqG2dA=.7762f50b-40b1-4763-940b-7e0c8a66d466@github.com>
Message-ID: <yQPwYcWUdOUxrmWxVlLdMO4AUDGnOw94XJpJvhmo648=.2c0b7cc3-5aaa-4fe1-bb06-edc7d8ec6261@github.com>

On Wed, 22 May 2024 14:47:43 GMT, Yudi Zheng <yzheng at openjdk.org> wrote:

>> Moving array construction within BigInteger.implMultiplyToLen intrinsic candidate to its caller simplifies the intrinsic implementation in JIT compiler.
>
> Yudi Zheng has updated the pull request incrementally with one additional commit since the last revision:
> 
>   address comments.

I have looked into s390x code and do not see any issue there. Also run test for BigInteger separately and a round of tier1 test as well. Result is clean there as well.

-------------

Marked as reviewed by amitkumar (Committer).

PR Review: https://git.openjdk.org/jdk/pull/18226#pullrequestreview-2073070871

From mbaesken at openjdk.org  Thu May 23 07:26:14 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 23 May 2024 07:26:14 GMT
Subject: RFR: 8332589: ubsan: unix/native/libjava/ProcessImpl_md.c:562:5:
 runtime error: null pointer passed as argument 2,
 which is declared to never be null [v2]
In-Reply-To: <AwlmAiTOhqSaoJ2Jh5YYrBpxakc0Pt9lYP9nvcBjXBo=.813efddf-3f87-4bbf-9cc5-cd769eabd2f7@github.com>
References: <AwlmAiTOhqSaoJ2Jh5YYrBpxakc0Pt9lYP9nvcBjXBo=.813efddf-3f87-4bbf-9cc5-cd769eabd2f7@github.com>
Message-ID: <Jmwe6R0-YXoCOmZLpD_riDxQortLtA2LXYd_ZOgXnr4=.209ec34c-7da1-4e49-879d-90e12df6d25f@github.com>

> When building with ubsan enabled (--enable-uban) on Linux x86_64 and doing jtreg tests afterwards I run into this error :
> 
> /jdk/src/java.base/unix/native/libjava/ProcessImpl_md.c:562:5: runtime error: null pointer passed as argument 2, which is declared to never be null
>     #0 0x7fd95bec78d8 in spawnChild /jdk/src/java.base/unix/native/libjava/ProcessImpl_md.c:562
>     #1 0x7fd95bec78d8 in startChild /jdk/src/java.base/unix/native/libjava/ProcessImpl_md.c:612
>     #2 0x7fd95bec78d8 in Java_java_lang_ProcessImpl_forkAndExec /jdk/src/java.base/unix/native/libjava/ProcessImpl_md.c:712
>     #3 0x7fd93797a06d (<unknown module>)
> 
> this is the memcpy call getting an unexpected null pointer :
>     memcpy(buf+offset, c->pdir, sp.dirlen); gets a second parameter null.
> Something similar was discussed and fixed here https://bugs.python.org/issue27570 for Python .
> 
> Similar issue in OpenJDK _ 
> https://bugs.openjdk.org/browse/JDK-8332473
> 8332473: ubsan: growableArray.hpp:290:10: runtime error: null pointer passed as argument 1, which is declared to never be null

Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:

  remarks Roger Riggs

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19329/files
  - new: https://git.openjdk.org/jdk/pull/19329/files/f2bebda2..b03ff0c5

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19329&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19329&range=00-01

  Stats: 3 lines in 1 file changed: 1 ins; 1 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/19329.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19329/head:pull/19329

PR: https://git.openjdk.org/jdk/pull/19329

From mbaesken at openjdk.org  Thu May 23 07:26:14 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 23 May 2024 07:26:14 GMT
Subject: RFR: 8332589: ubsan: unix/native/libjava/ProcessImpl_md.c:562:5:
 runtime error: null pointer passed as argument 2,
 which is declared to never be null
In-Reply-To: <AwlmAiTOhqSaoJ2Jh5YYrBpxakc0Pt9lYP9nvcBjXBo=.813efddf-3f87-4bbf-9cc5-cd769eabd2f7@github.com>
References: <AwlmAiTOhqSaoJ2Jh5YYrBpxakc0Pt9lYP9nvcBjXBo=.813efddf-3f87-4bbf-9cc5-cd769eabd2f7@github.com>
Message-ID: <jqpaUWZGccjNbdy4erXpGY4r8fctWeyCfvAi0DUiBLM=.09a6680f-5867-4042-858c-d62bf4d92429@github.com>

On Tue, 21 May 2024 14:28:38 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> When building with ubsan enabled (--enable-uban) on Linux x86_64 and doing jtreg tests afterwards I run into this error :
> 
> /jdk/src/java.base/unix/native/libjava/ProcessImpl_md.c:562:5: runtime error: null pointer passed as argument 2, which is declared to never be null
>     #0 0x7fd95bec78d8 in spawnChild /jdk/src/java.base/unix/native/libjava/ProcessImpl_md.c:562
>     #1 0x7fd95bec78d8 in startChild /jdk/src/java.base/unix/native/libjava/ProcessImpl_md.c:612
>     #2 0x7fd95bec78d8 in Java_java_lang_ProcessImpl_forkAndExec /jdk/src/java.base/unix/native/libjava/ProcessImpl_md.c:712
>     #3 0x7fd93797a06d (<unknown module>)
> 
> this is the memcpy call getting an unexpected null pointer :
>     memcpy(buf+offset, c->pdir, sp.dirlen); gets a second parameter null.
> Something similar was discussed and fixed here https://bugs.python.org/issue27570 for Python .
> 
> Similar issue in OpenJDK _ 
> https://bugs.openjdk.org/browse/JDK-8332473
> 8332473: ubsan: growableArray.hpp:290:10: runtime error: null pointer passed as argument 1, which is declared to never be null

Hi Roger, thanks for the hint !  I adjusted the coding.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19329#issuecomment-2126408877

From duke at openjdk.org  Thu May 23 09:14:08 2024
From: duke at openjdk.org (Sunmisc Unsafe)
Date: Thu, 23 May 2024 09:14:08 GMT
Subject: RFR: 8322732: ForkJoinPool may underutilize cores in async mode
 [v2]
In-Reply-To: <t2Yzp7nujqzRe7bo3xKjoJqR5_9CdQgHhsBNbuBkBdM=.4dbcc790-7134-4421-b798-4bc589c41d32@github.com>
References: <xRyDMAsSZ7obqpr3Aoc5qrHqILeJMxFVCeiRdctMI3U=.d5d3cd56-32eb-4431-ac01-081822fc86c6@github.com>
 <1h7ssJJnGUbpqORLsdM_Udcl2dqYsrjuXP6ZPTH_bVo=.ce5a42ba-4eae-4430-9f7d-b6036a45ef9b@github.com>
 <t2Yzp7nujqzRe7bo3xKjoJqR5_9CdQgHhsBNbuBkBdM=.4dbcc790-7134-4421-b798-4bc589c41d32@github.com>
Message-ID: <bbc_1k3hKtOkRNcdoLlTBlrLpQLFTlpYrtf1C8hyTIA=.405723f6-cd93-4558-bbbd-683a054e75bd@github.com>

On Thu, 16 May 2024 10:29:48 GMT, Sunmisc Unsafe <duke at openjdk.org> wrote:

>> Doug Lea has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Address review comments
>
> Maybe I don't quite understand, or I don't have proof, But wouldn't it be better if invokeAll in FIFO mode (asyncMode) traverses the Future list as a FIFO (currently it traverses in LIFO order)

> @sunmisc invokeAll doesn't specify an exec or join order; forward exec snf inverse normally uses fewest resources.

thanks, yes, but I meant a bit different if the tasks are done in FIFO order
then the first task might already be executed unlike the last one, which might reduce the blocking overhead?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19131#issuecomment-2126615413

From jlahoda at openjdk.org  Thu May 23 09:50:02 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Thu, 23 May 2024 09:50:02 GMT
Subject: RFR: 8332528: Generate code in SwitchBootstraps.generateTypeSwitch
 that require fewer adaptations [v3]
In-Reply-To: <obAr25A-jgVCp3uPrBeQJi-D5Oko0ML2lp4VevG8AoQ=.6438ef57-e47f-4f97-8c7e-d15d1b999848@github.com>
References: <wHUtsMWzEaVwNwDuQJAyrUJrpDkcQpXxb6i5KA7J_Bw=.17b2f7d2-2c8c-42e7-9c90-2bf9f5901f26@github.com>
 <obAr25A-jgVCp3uPrBeQJi-D5Oko0ML2lp4VevG8AoQ=.6438ef57-e47f-4f97-8c7e-d15d1b999848@github.com>
Message-ID: <XG6RFSeqk77Zgm7JaI4Qo-PRHlInkIF4NP4CpXyUa7g=.7d222405-fbd4-43b2-b3be-48293f0daa31@github.com>

On Tue, 21 May 2024 09:01:32 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> We can fold the call to `Objects.checkIndex` into the code generated in generateTypeSwitchSkeleton instead of doing so by filtering the MH argument. This loads 9 less classes (of which 8 generated LFs and Species classes) on a minimal test, while being neutral on a throughput sanity test:
>> 
>> 
>> Name                   Cnt  Base   Error   Test   Error  Unit  Change
>> SwitchSanity.switchSum  15 8,162 ? 0,117  8,152 ? 0,131 ns/op   1,00x (p = 0,800 )
>>   * = significant
>>   ```
>> 
>> A few additional optimizations includes moving some seldom used `findStatic` calls to a holder. All in all this means a reduction by 22M cycles to bootstrap a trivial switch expression on my M1.
>
> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add type switch to HelloClasslist

Seems goo to me, with one nit related to `MethodTypeDescImpl`.

src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java line 53:

> 51: import java.lang.classfile.instruction.SwitchCase;
> 52: 
> 53: import jdk.internal.constant.MethodTypeDescImpl;

Nit - this import seems to be unused, and neither seem to be the changes to `MethodTypeDescImpl`. Is there some use missing? (OTOH, I like the `StaticHolders` for the stuff that relates to the enum-switch special case, for the time being.)

-------------

PR Review: https://git.openjdk.org/jdk/pull/19307#pullrequestreview-2073448995
PR Review Comment: https://git.openjdk.org/jdk/pull/19307#discussion_r1611368747

From bkilambi at openjdk.org  Thu May 23 10:15:08 2024
From: bkilambi at openjdk.org (Bhavana Kilambi)
Date: Thu, 23 May 2024 10:15:08 GMT
Subject: RFR: 8327964: Simplify BigInteger.implMultiplyToLen intrinsic [v6]
In-Reply-To: <GkTIvOKs4GDKUOPjaw893H4fAoeBDuzQn4kKnQqG2dA=.7762f50b-40b1-4763-940b-7e0c8a66d466@github.com>
References: <Z5U-3OSq9_rd0t6DHNRhjF3LHtc9b6orz-mcQ4Uqzl8=.c4f0a0b8-9e10-4505-82f7-7d3a82929d22@github.com>
 <GkTIvOKs4GDKUOPjaw893H4fAoeBDuzQn4kKnQqG2dA=.7762f50b-40b1-4763-940b-7e0c8a66d466@github.com>
Message-ID: <PgN6dfopkQcs-atZRqVqPFIWd32n1Rgp6WG9HTPYmsk=.74227143-d79e-4a7b-8ace-2a6c2b014627@github.com>

On Wed, 22 May 2024 14:47:43 GMT, Yudi Zheng <yzheng at openjdk.org> wrote:

>> Moving array construction within BigInteger.implMultiplyToLen intrinsic candidate to its caller simplifies the intrinsic implementation in JIT compiler.
>
> Yudi Zheng has updated the pull request incrementally with one additional commit since the last revision:
> 
>   address comments.

src/hotspot/share/opto/library_call.cpp line 5925:

> 5923:   // Set the original stack and the reexecute bit for the interpreter to reexecute
> 5924:   // the bytecode that invokes BigInteger.multiplyToLen() if deoptimization happens
> 5925:   // on the return from z array allocation in runtime.

Since we are not allocating z array during runtime anymore, do we still need these comments?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18226#discussion_r1611403873

From bkilambi at openjdk.org  Thu May 23 10:30:08 2024
From: bkilambi at openjdk.org (Bhavana Kilambi)
Date: Thu, 23 May 2024 10:30:08 GMT
Subject: RFR: 8327964: Simplify BigInteger.implMultiplyToLen intrinsic [v6]
In-Reply-To: <GkTIvOKs4GDKUOPjaw893H4fAoeBDuzQn4kKnQqG2dA=.7762f50b-40b1-4763-940b-7e0c8a66d466@github.com>
References: <Z5U-3OSq9_rd0t6DHNRhjF3LHtc9b6orz-mcQ4Uqzl8=.c4f0a0b8-9e10-4505-82f7-7d3a82929d22@github.com>
 <GkTIvOKs4GDKUOPjaw893H4fAoeBDuzQn4kKnQqG2dA=.7762f50b-40b1-4763-940b-7e0c8a66d466@github.com>
Message-ID: <2K7bXCyATxLA0IoTcuyURmOJ7dlY1kH1-tvVadK6F6c=.db3668e6-4bb3-46ac-98aa-a8866c007708@github.com>

On Wed, 22 May 2024 14:47:43 GMT, Yudi Zheng <yzheng at openjdk.org> wrote:

>> Moving array construction within BigInteger.implMultiplyToLen intrinsic candidate to its caller simplifies the intrinsic implementation in JIT compiler.
>
> Yudi Zheng has updated the pull request incrementally with one additional commit since the last revision:
> 
>   address comments.

src/java.base/share/classes/java/math/BigInteger.java line 1836:

> 1834: 
> 1835:         if (z == null || z.length < (xlen + ylen))
> 1836:              z = new int[xlen + ylen];

Style: only 4 spaces indentation

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18226#discussion_r1611422191

From ihse at openjdk.org  Thu May 23 11:00:03 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 23 May 2024 11:00:03 GMT
Subject: RFR: 8332589: ubsan: unix/native/libjava/ProcessImpl_md.c:562:5:
 runtime error: null pointer passed as argument 2,
 which is declared to never be null [v2]
In-Reply-To: <Jmwe6R0-YXoCOmZLpD_riDxQortLtA2LXYd_ZOgXnr4=.209ec34c-7da1-4e49-879d-90e12df6d25f@github.com>
References: <AwlmAiTOhqSaoJ2Jh5YYrBpxakc0Pt9lYP9nvcBjXBo=.813efddf-3f87-4bbf-9cc5-cd769eabd2f7@github.com>
 <Jmwe6R0-YXoCOmZLpD_riDxQortLtA2LXYd_ZOgXnr4=.209ec34c-7da1-4e49-879d-90e12df6d25f@github.com>
Message-ID: <zdk73ZtWTAQUkJl42lkm31BsXCZl-LEs5dN0ywz8FIA=.0de5def9-6018-4897-ab87-b34fe4b70d71@github.com>

On Thu, 23 May 2024 07:26:14 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> When building with ubsan enabled (--enable-uban) on Linux x86_64 and doing jtreg tests afterwards I run into this error :
>> 
>> /jdk/src/java.base/unix/native/libjava/ProcessImpl_md.c:562:5: runtime error: null pointer passed as argument 2, which is declared to never be null
>>     #0 0x7fd95bec78d8 in spawnChild /jdk/src/java.base/unix/native/libjava/ProcessImpl_md.c:562
>>     #1 0x7fd95bec78d8 in startChild /jdk/src/java.base/unix/native/libjava/ProcessImpl_md.c:612
>>     #2 0x7fd95bec78d8 in Java_java_lang_ProcessImpl_forkAndExec /jdk/src/java.base/unix/native/libjava/ProcessImpl_md.c:712
>>     #3 0x7fd93797a06d (<unknown module>)
>> 
>> this is the memcpy call getting an unexpected null pointer :
>>     memcpy(buf+offset, c->pdir, sp.dirlen); gets a second parameter null.
>> Something similar was discussed and fixed here https://bugs.python.org/issue27570 for Python .
>> 
>> Similar issue in OpenJDK _ 
>> https://bugs.openjdk.org/browse/JDK-8332473
>> 8332473: ubsan: growableArray.hpp:290:10: runtime error: null pointer passed as argument 1, which is declared to never be null
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remarks Roger Riggs

This looks much better. 

However, if we ever call this with a non-zero `sp.dirlen` and a null `c->pdir`, we'd be in trouble. In the old code, we would have crashed. Now, we will just silently ignore this, and God knows what will happen after that part.

I don't have the full context on how this function is used, but if there is some way you can report back with an error to the caller in that case, I think it would be appropriate.

-------------

PR Review: https://git.openjdk.org/jdk/pull/19329#pullrequestreview-2073609282

From redestad at openjdk.org  Thu May 23 11:09:14 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Thu, 23 May 2024 11:09:14 GMT
Subject: RFR: 8332528: Generate code in SwitchBootstraps.generateTypeSwitch
 that require fewer adaptations [v4]
In-Reply-To: <wHUtsMWzEaVwNwDuQJAyrUJrpDkcQpXxb6i5KA7J_Bw=.17b2f7d2-2c8c-42e7-9c90-2bf9f5901f26@github.com>
References: <wHUtsMWzEaVwNwDuQJAyrUJrpDkcQpXxb6i5KA7J_Bw=.17b2f7d2-2c8c-42e7-9c90-2bf9f5901f26@github.com>
Message-ID: <iBzLtSPEtUfXCGKWoOZ13Y9GZ89bXofnu9usiAIJQWQ=.323c8ac2-6d50-4141-8352-62d4c6fc34e2@github.com>

> We can fold the call to `Objects.checkIndex` into the code generated in generateTypeSwitchSkeleton instead of doing so by filtering the MH argument. This loads 9 less classes (of which 8 generated LFs and Species classes) on a minimal test, while being neutral on a throughput sanity test:
> 
> 
> Name                   Cnt  Base   Error   Test   Error  Unit  Change
> SwitchSanity.switchSum  15 8,162 ? 0,117  8,152 ? 0,131 ns/op   1,00x (p = 0,800 )
>   * = significant
>   ```
> 
> A few additional optimizations includes moving some seldom used `findStatic` calls to a holder. All in all this means a reduction by 22M cycles to bootstrap a trivial switch expression on my M1.

Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:

  Remove unused import, revert left-overs in MethodTypeDescImpl

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19307/files
  - new: https://git.openjdk.org/jdk/pull/19307/files/f04d78ea..eb4babe5

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19307&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19307&range=02-03

  Stats: 3 lines in 2 files changed: 0 ins; 1 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/19307.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19307/head:pull/19307

PR: https://git.openjdk.org/jdk/pull/19307

From redestad at openjdk.org  Thu May 23 11:09:15 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Thu, 23 May 2024 11:09:15 GMT
Subject: RFR: 8332528: Generate code in SwitchBootstraps.generateTypeSwitch
 that require fewer adaptations [v3]
In-Reply-To: <XG6RFSeqk77Zgm7JaI4Qo-PRHlInkIF4NP4CpXyUa7g=.7d222405-fbd4-43b2-b3be-48293f0daa31@github.com>
References: <wHUtsMWzEaVwNwDuQJAyrUJrpDkcQpXxb6i5KA7J_Bw=.17b2f7d2-2c8c-42e7-9c90-2bf9f5901f26@github.com>
 <obAr25A-jgVCp3uPrBeQJi-D5Oko0ML2lp4VevG8AoQ=.6438ef57-e47f-4f97-8c7e-d15d1b999848@github.com>
 <XG6RFSeqk77Zgm7JaI4Qo-PRHlInkIF4NP4CpXyUa7g=.7d222405-fbd4-43b2-b3be-48293f0daa31@github.com>
Message-ID: <Yy08iUaNeMVjsoDlsCcee8sfzZtWaX7WrbSbdkoo25I=.a81f7e09-053c-450e-9c14-e6cce5d6b491@github.com>

On Thu, 23 May 2024 09:46:51 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add type switch to HelloClasslist
>
> src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java line 53:
> 
>> 51: import java.lang.classfile.instruction.SwitchCase;
>> 52: 
>> 53: import jdk.internal.constant.MethodTypeDescImpl;
> 
> Nit - this import seems to be unused, and neither seem to be the changes to `MethodTypeDescImpl`. Is there some use missing? (OTOH, I like the `StaticHolders` for the stuff that relates to the enum-switch special case, for the time being.)

Oops, some leftovers from the optimizations I reverted. Fixed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19307#discussion_r1611478359

From liach at openjdk.org  Thu May 23 11:28:01 2024
From: liach at openjdk.org (Chen Liang)
Date: Thu, 23 May 2024 11:28:01 GMT
Subject: RFR: 8242888: Convert dynamic proxy to hidden classes
In-Reply-To: <QO0dIumbbHUFWz43pCWbmsqdH5zG8NaVUB9FwNFlbTw=.8fe20db2-9cfc-46e9-9f98-0979259ac882@github.com>
References: <QO0dIumbbHUFWz43pCWbmsqdH5zG8NaVUB9FwNFlbTw=.8fe20db2-9cfc-46e9-9f98-0979259ac882@github.com>
Message-ID: <ZlaFVWmLKm_TeaoYNpcIQJqeCMOF807SvUF_NmnVqKw=.5ed04198-6a80-43fd-bdb4-75dc21c9cd9b@github.com>

On Thu, 23 May 2024 03:28:30 GMT, Chen Liang <liach at openjdk.org> wrote:

> Please review this change that convert dynamic proxies implementations to hidden classes, intended to target JDK 24.
> 
> Summary:
> 1. Adds new implementation while preserving the old implementation behind `-Djdk.reflect.useLegacyProxyImpl=true` in case there are compatibility issues.
> 2. ClassLoader.defineClass0 takes a ClassLoader instance but discards it in native code; I updated native code to reuse that ClassLoader for Proxy support.
> 3. ProxyGenerator changes mainly involve using Class data to pass Method list (accessed in a single condy) and removal of obsolete setup code generation.
> 
> Testing: tier1 and tier2 have no related failures.
> 
> Comment: Since #8278, Proxy has been converted to ClassFile API, and infrastructure has changed; now, the migration to hidden classes is much cleaner and has less impact, such as preserving ProtectionDomain and dynamic module without "anchor classes", and avoiding java.lang.invoke package.

A CSR targeting 24 describing the compatibility concerns and behavioral differences is here, somehow not linked by skara: https://bugs.openjdk.org/browse/JDK-8332770
The incompatibilities were much greater in the previous iterations of this issue, such as in dynamic modules, serialization, and in proxy class protection domain. Now these aspects are addressed by this patch, the only real one left is the change in stack trace. Feel free to raise other incompatibilities you have discovered.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19356#issuecomment-2126869679

From mbaesken at openjdk.org  Thu May 23 11:38:06 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 23 May 2024 11:38:06 GMT
Subject: RFR: 8332589: ubsan: unix/native/libjava/ProcessImpl_md.c:562:5:
 runtime error: null pointer passed as argument 2,
 which is declared to never be null [v2]
In-Reply-To: <zdk73ZtWTAQUkJl42lkm31BsXCZl-LEs5dN0ywz8FIA=.0de5def9-6018-4897-ab87-b34fe4b70d71@github.com>
References: <AwlmAiTOhqSaoJ2Jh5YYrBpxakc0Pt9lYP9nvcBjXBo=.813efddf-3f87-4bbf-9cc5-cd769eabd2f7@github.com>
 <Jmwe6R0-YXoCOmZLpD_riDxQortLtA2LXYd_ZOgXnr4=.209ec34c-7da1-4e49-879d-90e12df6d25f@github.com>
 <zdk73ZtWTAQUkJl42lkm31BsXCZl-LEs5dN0ywz8FIA=.0de5def9-6018-4897-ab87-b34fe4b70d71@github.com>
Message-ID: <tjvRpW654jVR6Gu-S_H4_0kgGqp82qT4ccPGr-P6erc=.caa838b7-9f92-4e9d-a4c4-c141a00b2865@github.com>

On Thu, 23 May 2024 10:57:28 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>However, if we ever call this with a non-zero sp.dirlen and a null c->pdir, we'd be in trouble. In the old code, we would have 
> crashed. Now, we will just silently ignore this, and God knows what will happen after that part.

In this special case we can return -1 ;  the spawnChild  function already returns -1 in some other error cases.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19329#issuecomment-2126888052

From alanb at openjdk.org  Thu May 23 11:39:02 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 23 May 2024 11:39:02 GMT
Subject: RFR: 8242888: Convert dynamic proxy to hidden classes
In-Reply-To: <ZlaFVWmLKm_TeaoYNpcIQJqeCMOF807SvUF_NmnVqKw=.5ed04198-6a80-43fd-bdb4-75dc21c9cd9b@github.com>
References: <QO0dIumbbHUFWz43pCWbmsqdH5zG8NaVUB9FwNFlbTw=.8fe20db2-9cfc-46e9-9f98-0979259ac882@github.com>
 <ZlaFVWmLKm_TeaoYNpcIQJqeCMOF807SvUF_NmnVqKw=.5ed04198-6a80-43fd-bdb4-75dc21c9cd9b@github.com>
Message-ID: <KwnUy2Qkpq1z39wsdBm00ecrCYBk_eYeio248uM1jYc=.eeba80b6-5c26-4d03-85c4-490db6c51a20@github.com>

On Thu, 23 May 2024 11:25:00 GMT, Chen Liang <liach at openjdk.org> wrote:

> A CSR targeting 24 describing the compatibility concerns and behavioral differences is here, somehow not linked by skara: https://bugs.openjdk.org/browse/JDK-8332770 The incompatibilities were much greater in the previous iterations of this issue, such as in dynamic modules, serialization, and in proxy class protection domain. Now these aspects are addressed by this patch, the only real one left is the change in stack trace. Feel free to raise other incompatibilities you have discovered.

Thanks for starting a CSR. The CSR can't be low risk, it's medium at least, maybe high. If we are doing this change then doing it early in a release and putting into outreach to frameworks will be important.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19356#issuecomment-2126890063

From forax at univ-mlv.fr  Thu May 23 11:43:38 2024
From: forax at univ-mlv.fr (Remi Forax)
Date: Thu, 23 May 2024 13:43:38 +0200 (CEST)
Subject: RFR: 8242888: Convert dynamic proxy to hidden classes
In-Reply-To: <ZlaFVWmLKm_TeaoYNpcIQJqeCMOF807SvUF_NmnVqKw=.5ed04198-6a80-43fd-bdb4-75dc21c9cd9b@github.com>
References: <QO0dIumbbHUFWz43pCWbmsqdH5zG8NaVUB9FwNFlbTw=.8fe20db2-9cfc-46e9-9f98-0979259ac882@github.com>
 <ZlaFVWmLKm_TeaoYNpcIQJqeCMOF807SvUF_NmnVqKw=.5ed04198-6a80-43fd-bdb4-75dc21c9cd9b@github.com>
Message-ID: <1193071457.29792413.1716464618330.JavaMail.zimbra@univ-eiffel.fr>

----- Original Message -----
> From: "Chen Liang" <liach at openjdk.org>
> To: "core-libs-dev" <core-libs-dev at openjdk.org>, "hotspot-dev" <hotspot-dev at openjdk.org>, kulla-dev at openjdk.org
> Sent: Thursday, May 23, 2024 1:28:01 PM
> Subject: Re: RFR: 8242888: Convert dynamic proxy to hidden classes

> On Thu, 23 May 2024 03:28:30 GMT, Chen Liang <liach at openjdk.org> wrote:
> 
>> Please review this change that convert dynamic proxies implementations to hidden
>> classes, intended to target JDK 24.
>> 
>> Summary:
>> 1. Adds new implementation while preserving the old implementation behind
>> `-Djdk.reflect.useLegacyProxyImpl=true` in case there are compatibility issues.
>> 2. ClassLoader.defineClass0 takes a ClassLoader instance but discards it in
>> native code; I updated native code to reuse that ClassLoader for Proxy support.
>> 3. ProxyGenerator changes mainly involve using Class data to pass Method list
>> (accessed in a single condy) and removal of obsolete setup code generation.
>> 
>> Testing: tier1 and tier2 have no related failures.
>> 
>> Comment: Since #8278, Proxy has been converted to ClassFile API, and
>> infrastructure has changed; now, the migration to hidden classes is much
>> cleaner and has less impact, such as preserving ProtectionDomain and dynamic
>> module without "anchor classes", and avoiding java.lang.invoke package.
> 
> A CSR targeting 24 describing the compatibility concerns and behavioral
> differences is here, somehow not linked by skara:
> https://bugs.openjdk.org/browse/JDK-8332770
> The incompatibilities were much greater in the previous iterations of this
> issue, such as in dynamic modules, serialization, and in proxy class protection
> domain. Now these aspects are addressed by this patch, the only real one left
> is the change in stack trace. Feel free to raise other incompatibilities you
> have discovered.

I wonder if instead of using hidden classes, we should not use usual named classes and add a new Lookup.defineClass() that takes a classData as parameter.
This will solve the both the problem of the stacktrace and the problem of the roundtrip proxyClass != Class.forName(proxyClass.getName()).

R?mi

> 
> -------------
> 
> PR Comment: https://git.openjdk.org/jdk/pull/19356#issuecomment-2126869679

From jlahoda at openjdk.org  Thu May 23 11:44:08 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Thu, 23 May 2024 11:44:08 GMT
Subject: RFR: 8332528: Generate code in SwitchBootstraps.generateTypeSwitch
 that require fewer adaptations [v4]
In-Reply-To: <iBzLtSPEtUfXCGKWoOZ13Y9GZ89bXofnu9usiAIJQWQ=.323c8ac2-6d50-4141-8352-62d4c6fc34e2@github.com>
References: <wHUtsMWzEaVwNwDuQJAyrUJrpDkcQpXxb6i5KA7J_Bw=.17b2f7d2-2c8c-42e7-9c90-2bf9f5901f26@github.com>
 <iBzLtSPEtUfXCGKWoOZ13Y9GZ89bXofnu9usiAIJQWQ=.323c8ac2-6d50-4141-8352-62d4c6fc34e2@github.com>
Message-ID: <O9hlJE0iCNTSzlUp9QGo1mfzZDhH44gcWF44V_6XNJw=.e628a593-a041-4794-873f-598075c9b5fc@github.com>

On Thu, 23 May 2024 11:09:14 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> We can fold the call to `Objects.checkIndex` into the code generated in generateTypeSwitchSkeleton instead of doing so by filtering the MH argument. This loads 9 less classes (of which 8 generated LFs and Species classes) on a minimal test, while being neutral on a throughput sanity test:
>> 
>> 
>> Name                   Cnt  Base   Error   Test   Error  Unit  Change
>> SwitchSanity.switchSum  15 8,162 ? 0,117  8,152 ? 0,131 ns/op   1,00x (p = 0,800 )
>>   * = significant
>>   ```
>> 
>> A few additional optimizations includes moving some seldom used `findStatic` calls to a holder. All in all this means a reduction by 22M cycles to bootstrap a trivial switch expression on my M1.
>
> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove unused import, revert left-overs in MethodTypeDescImpl

Looks good, thanks!

-------------

Marked as reviewed by jlahoda (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19307#pullrequestreview-2073701019

From pminborg at openjdk.org  Thu May 23 11:44:15 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 23 May 2024 11:44:15 GMT
Subject: RFR: 8332749: Broken link in MemorySegment.Scope.html
Message-ID: <xIxgAl7ds3CS1f-OFWGR_oqcOs_oQj8soD12-6IOVvQ=.1662ac42-19a2-4c22-a88c-02daa125f476@github.com>

This PR proposes to fix a broken link in the `MemorySegment.Scope` class.

-------------

Commit messages:
 - Fix link to section

Changes: https://git.openjdk.org/jdk/pull/19366/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19366&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8332749
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/19366.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19366/head:pull/19366

PR: https://git.openjdk.org/jdk/pull/19366

From pminborg at openjdk.org  Thu May 23 12:26:01 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 23 May 2024 12:26:01 GMT
Subject: RFR: 8332749: Broken link in MemorySegment.Scope.html
In-Reply-To: <xIxgAl7ds3CS1f-OFWGR_oqcOs_oQj8soD12-6IOVvQ=.1662ac42-19a2-4c22-a88c-02daa125f476@github.com>
References: <xIxgAl7ds3CS1f-OFWGR_oqcOs_oQj8soD12-6IOVvQ=.1662ac42-19a2-4c22-a88c-02daa125f476@github.com>
Message-ID: <gGivacYuO6NzETi4qNYQhdXwHMWf7EzeFzd1Zqm-ruA=.07e98b74-2aed-486f-9e6b-8a1a4c14cb91@github.com>

On Thu, 23 May 2024 11:39:11 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR proposes to fix a broken link in the `MemorySegment.Scope` class.

Seams to work after the patch:

![image](https://github.com/openjdk/jdk/assets/7457876/6a48599b-0e08-40b0-938e-f7cb13b74ae6)

.../api/java.base/java/lang/foreign/MemorySegment.html#wrapping-addresses

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19366#issuecomment-2126976574

From redestad at openjdk.org  Thu May 23 12:29:09 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Thu, 23 May 2024 12:29:09 GMT
Subject: RFR: 8332528: Generate code in SwitchBootstraps.generateTypeSwitch
 that require fewer adaptations [v4]
In-Reply-To: <iBzLtSPEtUfXCGKWoOZ13Y9GZ89bXofnu9usiAIJQWQ=.323c8ac2-6d50-4141-8352-62d4c6fc34e2@github.com>
References: <wHUtsMWzEaVwNwDuQJAyrUJrpDkcQpXxb6i5KA7J_Bw=.17b2f7d2-2c8c-42e7-9c90-2bf9f5901f26@github.com>
 <iBzLtSPEtUfXCGKWoOZ13Y9GZ89bXofnu9usiAIJQWQ=.323c8ac2-6d50-4141-8352-62d4c6fc34e2@github.com>
Message-ID: <o8Wmh2yf64Ymj6LZgWvt7OWP31RMrTVl65TIYoho5bE=.e72693b7-eee2-4f29-9bba-5d6ebd5a9b2a@github.com>

On Thu, 23 May 2024 11:09:14 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> We can fold the call to `Objects.checkIndex` into the code generated in generateTypeSwitchSkeleton instead of doing so by filtering the MH argument. This loads 9 less classes (of which 8 generated LFs and Species classes) on a minimal test, while being neutral on a throughput sanity test:
>> 
>> 
>> Name                   Cnt  Base   Error   Test   Error  Unit  Change
>> SwitchSanity.switchSum  15 8,162 ? 0,117  8,152 ? 0,131 ns/op   1,00x (p = 0,800 )
>>   * = significant
>>   ```
>> 
>> A few additional optimizations includes moving some seldom used `findStatic` calls to a holder. All in all this means a reduction by 22M cycles to bootstrap a trivial switch expression on my M1.
>
> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove unused import, revert left-overs in MethodTypeDescImpl

Thanks!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19307#issuecomment-2126979932

From redestad at openjdk.org  Thu May 23 12:29:11 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Thu, 23 May 2024 12:29:11 GMT
Subject: Integrated: 8332528: Generate code in
 SwitchBootstraps.generateTypeSwitch that require fewer adaptations
In-Reply-To: <wHUtsMWzEaVwNwDuQJAyrUJrpDkcQpXxb6i5KA7J_Bw=.17b2f7d2-2c8c-42e7-9c90-2bf9f5901f26@github.com>
References: <wHUtsMWzEaVwNwDuQJAyrUJrpDkcQpXxb6i5KA7J_Bw=.17b2f7d2-2c8c-42e7-9c90-2bf9f5901f26@github.com>
Message-ID: <K14VIPTvMnSOUB3VzEFgzUHuUIHScDcoiKG10TFXwbM=.7f7ed596-a585-4532-8623-0d996e053eb8@github.com>

On Mon, 20 May 2024 10:52:27 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> We can fold the call to `Objects.checkIndex` into the code generated in generateTypeSwitchSkeleton instead of doing so by filtering the MH argument. This loads 9 less classes (of which 8 generated LFs and Species classes) on a minimal test, while being neutral on a throughput sanity test:
> 
> 
> Name                   Cnt  Base   Error   Test   Error  Unit  Change
> SwitchSanity.switchSum  15 8,162 ? 0,117  8,152 ? 0,131 ns/op   1,00x (p = 0,800 )
>   * = significant
>   ```
> 
> A few additional optimizations includes moving some seldom used `findStatic` calls to a holder. All in all this means a reduction by 22M cycles to bootstrap a trivial switch expression on my M1.

This pull request has now been integrated.

Changeset: 2581935b
Author:    Claes Redestad <redestad at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/2581935b47afaf661a94c8a8e50ce08065d632f6
Stats:     165 lines in 4 files changed: 125 ins; 14 del; 26 mod

8332528: Generate code in SwitchBootstraps.generateTypeSwitch that require fewer adaptations

Reviewed-by: liach, jlahoda

-------------

PR: https://git.openjdk.org/jdk/pull/19307

From liangchenblue at gmail.com  Thu May 23 12:56:58 2024
From: liangchenblue at gmail.com (Chen Liang)
Date: Thu, 23 May 2024 07:56:58 -0500
Subject: RFR: 8242888: Convert dynamic proxy to hidden classes
In-Reply-To: <1193071457.29792413.1716464618330.JavaMail.zimbra@univ-eiffel.fr>
References: <QO0dIumbbHUFWz43pCWbmsqdH5zG8NaVUB9FwNFlbTw=.8fe20db2-9cfc-46e9-9f98-0979259ac882@github.com>
 <ZlaFVWmLKm_TeaoYNpcIQJqeCMOF807SvUF_NmnVqKw=.5ed04198-6a80-43fd-bdb4-75dc21c9cd9b@github.com>
 <1193071457.29792413.1716464618330.JavaMail.zimbra@univ-eiffel.fr>
Message-ID: <CABe8uE3mPp1ai8tzNnmXnEk=UJyMsqGjyVdO3MehmPhTo=Da4w@mail.gmail.com>

Hmm, I think Proxy being hidden in stacktraces might be an advantage; the
same happens for lambdas.
The main advantage of hidden classes compared to an explicit class with
classData is that it supports flexible unloading, which might be useful for
Proxy.
I still believe the flexible unloading advantage justifies the migration to
hidden classes.

Chen

On Thu, May 23, 2024 at 6:43?AM Remi Forax <forax at univ-mlv.fr> wrote:

> ----- Original Message -----
> > From: "Chen Liang" <liach at openjdk.org>
> > To: "core-libs-dev" <core-libs-dev at openjdk.org>, "hotspot-dev" <
> hotspot-dev at openjdk.org>, kulla-dev at openjdk.org
> > Sent: Thursday, May 23, 2024 1:28:01 PM
> > Subject: Re: RFR: 8242888: Convert dynamic proxy to hidden classes
>
> > On Thu, 23 May 2024 03:28:30 GMT, Chen Liang <liach at openjdk.org> wrote:
> >
> >> Please review this change that convert dynamic proxies implementations
> to hidden
> >> classes, intended to target JDK 24.
> >>
> >> Summary:
> >> 1. Adds new implementation while preserving the old implementation
> behind
> >> `-Djdk.reflect.useLegacyProxyImpl=true` in case there are compatibility
> issues.
> >> 2. ClassLoader.defineClass0 takes a ClassLoader instance but discards
> it in
> >> native code; I updated native code to reuse that ClassLoader for Proxy
> support.
> >> 3. ProxyGenerator changes mainly involve using Class data to pass
> Method list
> >> (accessed in a single condy) and removal of obsolete setup code
> generation.
> >>
> >> Testing: tier1 and tier2 have no related failures.
> >>
> >> Comment: Since #8278, Proxy has been converted to ClassFile API, and
> >> infrastructure has changed; now, the migration to hidden classes is much
> >> cleaner and has less impact, such as preserving ProtectionDomain and
> dynamic
> >> module without "anchor classes", and avoiding java.lang.invoke package.
> >
> > A CSR targeting 24 describing the compatibility concerns and behavioral
> > differences is here, somehow not linked by skara:
> > https://bugs.openjdk.org/browse/JDK-8332770
> > The incompatibilities were much greater in the previous iterations of
> this
> > issue, such as in dynamic modules, serialization, and in proxy class
> protection
> > domain. Now these aspects are addressed by this patch, the only real one
> left
> > is the change in stack trace. Feel free to raise other incompatibilities
> you
> > have discovered.
>
> I wonder if instead of using hidden classes, we should not use usual named
> classes and add a new Lookup.defineClass() that takes a classData as
> parameter.
> This will solve the both the problem of the stacktrace and the problem of
> the roundtrip proxyClass != Class.forName(proxyClass.getName()).
>
> R?mi
>
> >
> > -------------
> >
> > PR Comment:
> https://git.openjdk.org/jdk/pull/19356#issuecomment-2126869679
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240523/4c32512f/attachment-0001.htm>

From liach at openjdk.org  Thu May 23 13:31:01 2024
From: liach at openjdk.org (Chen Liang)
Date: Thu, 23 May 2024 13:31:01 GMT
Subject: RFR: 8242888: Convert dynamic proxy to hidden classes
In-Reply-To: <QO0dIumbbHUFWz43pCWbmsqdH5zG8NaVUB9FwNFlbTw=.8fe20db2-9cfc-46e9-9f98-0979259ac882@github.com>
References: <QO0dIumbbHUFWz43pCWbmsqdH5zG8NaVUB9FwNFlbTw=.8fe20db2-9cfc-46e9-9f98-0979259ac882@github.com>
Message-ID: <Q1fAfUu3tYgWGJWQVWYQGFF58eqLCD3N1EyGmpxQ2RI=.e6f90f69-fb25-4584-b7be-1ca4d86c95e4@github.com>

On Thu, 23 May 2024 03:28:30 GMT, Chen Liang <liach at openjdk.org> wrote:

> Please review this change that convert dynamic proxies implementations to hidden classes, intended to target JDK 24.
> 
> Summary:
> 1. Adds new implementation while preserving the old implementation behind `-Djdk.reflect.useLegacyProxyImpl=true` in case there are compatibility issues.
> 2. ClassLoader.defineClass0 takes a ClassLoader instance but discards it in native code; I updated native code to reuse that ClassLoader for Proxy support.
> 3. ProxyGenerator changes mainly involve using Class data to pass Method list (accessed in a single condy) and removal of obsolete setup code generation.
> 
> Testing: tier1 and tier2 have no related failures.
> 
> Comment: Since #8278, Proxy has been converted to ClassFile API, and infrastructure has changed; now, the migration to hidden classes is much cleaner and has less impact, such as preserving ProtectionDomain and dynamic module without "anchor classes", and avoiding java.lang.invoke package.

I have updated the compatibility risk description of the CSR.

My CSR proposes to allow dynamic unloading of the proxy implementation classes, but currently it's not implemented as they are strongly referenced in the ClassLoaderValue caches. Should I implement dynamic unloading suggested in the CSR in this patch, or should I do it later?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19356#issuecomment-2127111543

From forax at univ-mlv.fr  Thu May 23 13:45:14 2024
From: forax at univ-mlv.fr (forax at univ-mlv.fr)
Date: Thu, 23 May 2024 15:45:14 +0200 (CEST)
Subject: RFR: 8242888: Convert dynamic proxy to hidden classes
In-Reply-To: <CABe8uE3mPp1ai8tzNnmXnEk=UJyMsqGjyVdO3MehmPhTo=Da4w@mail.gmail.com>
References: <QO0dIumbbHUFWz43pCWbmsqdH5zG8NaVUB9FwNFlbTw=.8fe20db2-9cfc-46e9-9f98-0979259ac882@github.com>
 <ZlaFVWmLKm_TeaoYNpcIQJqeCMOF807SvUF_NmnVqKw=.5ed04198-6a80-43fd-bdb4-75dc21c9cd9b@github.com>
 <1193071457.29792413.1716464618330.JavaMail.zimbra@univ-eiffel.fr>
 <CABe8uE3mPp1ai8tzNnmXnEk=UJyMsqGjyVdO3MehmPhTo=Da4w@mail.gmail.com>
Message-ID: <1969145685.29901931.1716471914849.JavaMail.zimbra@univ-eiffel.fr>

> From: "-" <liangchenblue at gmail.com>
> To: "Remi Forax" <forax at univ-mlv.fr>
> Cc: "Chen Liang" <liach at openjdk.org>, "core-libs-dev"
> <core-libs-dev at openjdk.org>, "hotspot-dev" <hotspot-dev at openjdk.org>,
> "kulla-dev" <kulla-dev at openjdk.org>
> Sent: Thursday, May 23, 2024 2:56:58 PM
> Subject: Re: RFR: 8242888: Convert dynamic proxy to hidden classes

> Hmm, I think Proxy being hidden in stacktraces might be an advantage; the same
> happens for lambdas.
> The main advantage of hidden classes compared to an explicit class with
> classData is that it supports flexible unloading, which might be useful for
> Proxy.

Flexible unloading has a high cost in term of memory, the class + methods, etc need their own metaspace. 
While on paper it seems great, I've my doubt that it's a good idea to use that option for proxies given that the Proxy API allows an umbounded number of proxy classes. 
That's why lambda proxies does not use the flexible unloading anymore. 

> I still believe the flexible unloading advantage justifies the migration to
> hidden classes.

> Chen

R?mi 

> On Thu, May 23, 2024 at 6:43 AM Remi Forax < [ mailto:forax at univ-mlv.fr |
> forax at univ-mlv.fr ] > wrote:

>> ----- Original Message -----
>> > From: "Chen Liang" < [ mailto:liach at openjdk.org | liach at openjdk.org ] >
>>> To: "core-libs-dev" < [ mailto:core-libs-dev at openjdk.org |
>>> core-libs-dev at openjdk.org ] >, "hotspot-dev" < [ mailto:hotspot-dev at openjdk.org
>>> | hotspot-dev at openjdk.org ] >, [ mailto:kulla-dev at openjdk.org |
>> > kulla-dev at openjdk.org ]
>> > Sent: Thursday, May 23, 2024 1:28:01 PM
>> > Subject: Re: RFR: 8242888: Convert dynamic proxy to hidden classes

>>> On Thu, 23 May 2024 03:28:30 GMT, Chen Liang < [ mailto:liach at openjdk.org |
>> > liach at openjdk.org ] > wrote:

>> >> Please review this change that convert dynamic proxies implementations to hidden
>> >> classes, intended to target JDK 24.

>> >> Summary:
>> >> 1. Adds new implementation while preserving the old implementation behind
>> >> `-Djdk.reflect.useLegacyProxyImpl=true` in case there are compatibility issues.
>> >> 2. ClassLoader.defineClass0 takes a ClassLoader instance but discards it in
>> >> native code; I updated native code to reuse that ClassLoader for Proxy support.
>> >> 3. ProxyGenerator changes mainly involve using Class data to pass Method list
>> >> (accessed in a single condy) and removal of obsolete setup code generation.

>> >> Testing: tier1 and tier2 have no related failures.

>> >> Comment: Since #8278, Proxy has been converted to ClassFile API, and
>> >> infrastructure has changed; now, the migration to hidden classes is much
>> >> cleaner and has less impact, such as preserving ProtectionDomain and dynamic
>> >> module without "anchor classes", and avoiding java.lang.invoke package.

>> > A CSR targeting 24 describing the compatibility concerns and behavioral
>> > differences is here, somehow not linked by skara:
>>> [ https://bugs.openjdk.org/browse/JDK-8332770 |
>> > https://bugs.openjdk.org/browse/JDK-8332770 ]
>> > The incompatibilities were much greater in the previous iterations of this
>> > issue, such as in dynamic modules, serialization, and in proxy class protection
>> > domain. Now these aspects are addressed by this patch, the only real one left
>> > is the change in stack trace. Feel free to raise other incompatibilities you
>> > have discovered.

>> I wonder if instead of using hidden classes, we should not use usual named
>> classes and add a new Lookup.defineClass() that takes a classData as parameter.
>> This will solve the both the problem of the stacktrace and the problem of the
>> roundtrip proxyClass != Class.forName(proxyClass.getName()).

>> R?mi


>> > -------------

>>> PR Comment: [ https://git.openjdk.org/jdk/pull/19356#issuecomment-2126869679 |
>> > https://git.openjdk.org/jdk/pull/19356#issuecomment-2126869679 ]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240523/926a8572/attachment.htm>

From rriggs at openjdk.org  Thu May 23 13:50:05 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 23 May 2024 13:50:05 GMT
Subject: RFR: 8332589: ubsan: unix/native/libjava/ProcessImpl_md.c:562:5:
 runtime error: null pointer passed as argument 2,
 which is declared to never be null [v2]
In-Reply-To: <Jmwe6R0-YXoCOmZLpD_riDxQortLtA2LXYd_ZOgXnr4=.209ec34c-7da1-4e49-879d-90e12df6d25f@github.com>
References: <AwlmAiTOhqSaoJ2Jh5YYrBpxakc0Pt9lYP9nvcBjXBo=.813efddf-3f87-4bbf-9cc5-cd769eabd2f7@github.com>
 <Jmwe6R0-YXoCOmZLpD_riDxQortLtA2LXYd_ZOgXnr4=.209ec34c-7da1-4e49-879d-90e12df6d25f@github.com>
Message-ID: <pWVL3JcVw1l_iJcmT-LOrVV7SrYj6ArZEqBaDrjXwCs=.ad4f99c5-6d59-44c5-bf48-e9dc3622299d@github.com>

On Thu, 23 May 2024 07:26:14 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> When building with ubsan enabled (--enable-uban) on Linux x86_64 and doing jtreg tests afterwards I run into this error :
>> 
>> /jdk/src/java.base/unix/native/libjava/ProcessImpl_md.c:562:5: runtime error: null pointer passed as argument 2, which is declared to never be null
>>     #0 0x7fd95bec78d8 in spawnChild /jdk/src/java.base/unix/native/libjava/ProcessImpl_md.c:562
>>     #1 0x7fd95bec78d8 in startChild /jdk/src/java.base/unix/native/libjava/ProcessImpl_md.c:612
>>     #2 0x7fd95bec78d8 in Java_java_lang_ProcessImpl_forkAndExec /jdk/src/java.base/unix/native/libjava/ProcessImpl_md.c:712
>>     #3 0x7fd93797a06d (<unknown module>)
>> 
>> this is the memcpy call getting an unexpected null pointer :
>>     memcpy(buf+offset, c->pdir, sp.dirlen); gets a second parameter null.
>> Something similar was discussed and fixed here https://bugs.python.org/issue27570 for Python .
>> 
>> Similar issue in OpenJDK _ 
>> https://bugs.openjdk.org/browse/JDK-8332473
>> 8332473: ubsan: growableArray.hpp:290:10: runtime error: null pointer passed as argument 1, which is declared to never be null
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remarks Roger Riggs

LGTM

-------------

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19329#pullrequestreview-2074031918

From kcr at openjdk.org  Thu May 23 14:00:14 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 23 May 2024 14:00:14 GMT
Subject: RFR: 8331671: Implement JEP 472: Prepare to Restrict the Use of
 JNI [v8]
In-Reply-To: <PNJI-ppWMr7wFNBMrH6Vu59Y8yMiIB0cEMi-idTzdHM=.02d527df-ff5f-45df-9319-645b2e732b3e@github.com>
References: <CZGbki5iFdCGPPagE-ya-_L8Nkgf7OunywApOsxC548=.2cee82fa-a5d2-4165-b012-30982a85030a@github.com>
 <vWr2PdgTv6vEllxW8820KO3aZ3tR3xvMhCxD2k7QpS0=.8bfd6c47-6c93-4fc3-aced-7079889aa6a2@github.com>
 <qjJH1kyq5odcLXm7ATxtnCY-EgNNWycboa8G2FAZjtg=.1c382646-3ed9-4506-b182-4efe832f79a8@github.com>
 <PNJI-ppWMr7wFNBMrH6Vu59Y8yMiIB0cEMi-idTzdHM=.02d527df-ff5f-45df-9319-645b2e732b3e@github.com>
Message-ID: <nbhSCeRioIjK1ko19ohj2andX49zn9W9hqj5E1dWOI0=.3bd6f07a-0df5-42b8-aed2-44a3127b85c5@github.com>

On Thu, 23 May 2024 06:20:51 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> > Further, I confirm that if I pass that option to jlink or jpackage when creating a custom runtime, there is no warning.
> 
> Great! What about jpackage without a custom runtime, wondering if --java-options can be tested.

Yes, pointing to an existing runtime works, too. In either mode (jpackage using an existing Java runtime vs running jlink to create a new one), the options specified by `jpackage --java-options` are written to the application's `.cfg` file and used when the application launcher is run.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19213#issuecomment-2127188783

From alanb at openjdk.org  Thu May 23 14:00:12 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 23 May 2024 14:00:12 GMT
Subject: RFR: 8242888: Convert dynamic proxy to hidden classes
In-Reply-To: <Q1fAfUu3tYgWGJWQVWYQGFF58eqLCD3N1EyGmpxQ2RI=.e6f90f69-fb25-4584-b7be-1ca4d86c95e4@github.com>
References: <QO0dIumbbHUFWz43pCWbmsqdH5zG8NaVUB9FwNFlbTw=.8fe20db2-9cfc-46e9-9f98-0979259ac882@github.com>
 <Q1fAfUu3tYgWGJWQVWYQGFF58eqLCD3N1EyGmpxQ2RI=.e6f90f69-fb25-4584-b7be-1ca4d86c95e4@github.com>
Message-ID: <TxFTNGUZ2IWWumS8piKQoVRdGn-WdThNJ0N9gOt6joo=.df92f06f-93ce-4852-8769-7923d7ea3949@github.com>

On Thu, 23 May 2024 13:28:16 GMT, Chen Liang <liach at openjdk.org> wrote:

> I have updated the compatibility risk description of the CSR.
> 
> My CSR proposes to allow dynamic unloading of the proxy implementation classes, but currently it's not implemented as they are strongly referenced in the ClassLoaderValue caches. Should I implement dynamic unloading suggested in the CSR in this patch, or should I do it later?

I think the main compatibility concern is going to be that hidden classes don't have a binary name so we have to get a sense as to whether there are frameworks that do anything with the class name and Class.forName.

I suspect the work will also mean looking at cases where agents are somehow instrumenting proxy class (hidden classes are not modifiable). In the JDK 8 time frame we had to back out a change in this area due to one of the mocking tools filtering by class name and trying to redefine proxy classes.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19356#issuecomment-2127188839

From sgibbons at openjdk.org  Thu May 23 14:09:36 2024
From: sgibbons at openjdk.org (Scott Gibbons)
Date: Thu, 23 May 2024 14:09:36 GMT
Subject: RFR: 8320448: Accelerate IndexOf using AVX2 [v31]
In-Reply-To: <uWi4QxH31hL93771gkl_GgvP0m84IRSoR_1Yi8hD17E=.bc6ed458-7081-4c3f-9348-f59358fa05a4@github.com>
References: <uWi4QxH31hL93771gkl_GgvP0m84IRSoR_1Yi8hD17E=.bc6ed458-7081-4c3f-9348-f59358fa05a4@github.com>
Message-ID: <Oh5znqZWjnRczg5oW0ffiA02LJRTl8Yc8vjq-bzeLdE=.a705ff76-0b95-4ac8-8e5b-1306f6bf604f@github.com>

> Re-write the IndexOf code without the use of the pcmpestri instruction, only using AVX2 instructions.  This change accelerates String.IndexOf on average 1.3x for AVX2.  The benchmark numbers:
> 
> 
> Benchmark	                                               Score		Latest		
> StringIndexOf.advancedWithMediumSub   343.573		317.934		0.925375393x
> StringIndexOf.advancedWithShortSub1	  1039.081		1053.96		1.014319384x
> StringIndexOf.advancedWithShortSub2	      55.828		110.541		1.980027943x
> StringIndexOf.constantPattern	                9.361		11.906		1.271872663x
> StringIndexOf.searchCharLongSuccess	        4.216		4.218		1.000474383x
> StringIndexOf.searchCharMediumSuccess	3.133		3.216		1.02649218x
> StringIndexOf.searchCharShortSuccess	3.76		        3.761		1.000265957x
> StringIndexOf.success	                                9.186		9.713		1.057369911x
> StringIndexOf.successBig	                      14.341		46.343		3.231504079x
> StringIndexOfChar.latin1_AVX2_String	  6220.918		12154.52		1.953814533x
> StringIndexOfChar.latin1_AVX2_char	  5503.556		5540.044		1.006629895x
> StringIndexOfChar.latin1_SSE4_String	  6978.854		6818.689		0.977049957x
> StringIndexOfChar.latin1_SSE4_char	  5657.499		5474.624		0.967675646x
> StringIndexOfChar.latin1_Short_String	  7132.541		6863.359		0.962260014x
> StringIndexOfChar.latin1_Short_char	16013.389	      16162.437		1.009307711x
> StringIndexOfChar.latin1_mixed_String	  7386.123	      14771.622		1.999915517x
> StringIndexOfChar.latin1_mixed_char	  9901.671		9782.245		0.987938803

Scott Gibbons has updated the pull request incrementally with one additional commit since the last revision:

  Check macos build

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/16753/files
  - new: https://git.openjdk.org/jdk/pull/16753/files/40a1e628..87b1ebe8

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16753&range=30
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16753&range=29-30

  Stats: 2 lines in 1 file changed: 1 ins; 1 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/16753.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16753/head:pull/16753

PR: https://git.openjdk.org/jdk/pull/16753

From mbaesken at openjdk.org  Thu May 23 14:36:02 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 23 May 2024 14:36:02 GMT
Subject: RFR: 8332589: ubsan: unix/native/libjava/ProcessImpl_md.c:562:5:
 runtime error: null pointer passed as argument 2,
 which is declared to never be null [v2]
In-Reply-To: <Jmwe6R0-YXoCOmZLpD_riDxQortLtA2LXYd_ZOgXnr4=.209ec34c-7da1-4e49-879d-90e12df6d25f@github.com>
References: <AwlmAiTOhqSaoJ2Jh5YYrBpxakc0Pt9lYP9nvcBjXBo=.813efddf-3f87-4bbf-9cc5-cd769eabd2f7@github.com>
 <Jmwe6R0-YXoCOmZLpD_riDxQortLtA2LXYd_ZOgXnr4=.209ec34c-7da1-4e49-879d-90e12df6d25f@github.com>
Message-ID: <QeTcX0Oz-mohzXpBXIVOYv2wcKCJSO--M1PUv5St_-A=.e7310bad-937b-4429-bddd-0af1b6e18a57@github.com>

On Thu, 23 May 2024 07:26:14 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> When building with ubsan enabled (--enable-uban) on Linux x86_64 and doing jtreg tests afterwards I run into this error :
>> 
>> /jdk/src/java.base/unix/native/libjava/ProcessImpl_md.c:562:5: runtime error: null pointer passed as argument 2, which is declared to never be null
>>     #0 0x7fd95bec78d8 in spawnChild /jdk/src/java.base/unix/native/libjava/ProcessImpl_md.c:562
>>     #1 0x7fd95bec78d8 in startChild /jdk/src/java.base/unix/native/libjava/ProcessImpl_md.c:612
>>     #2 0x7fd95bec78d8 in Java_java_lang_ProcessImpl_forkAndExec /jdk/src/java.base/unix/native/libjava/ProcessImpl_md.c:712
>>     #3 0x7fd93797a06d (<unknown module>)
>> 
>> this is the memcpy call getting an unexpected null pointer :
>>     memcpy(buf+offset, c->pdir, sp.dirlen); gets a second parameter null.
>> Something similar was discussed and fixed here https://bugs.python.org/issue27570 for Python .
>> 
>> Similar issue in OpenJDK _ 
>> https://bugs.openjdk.org/browse/JDK-8332473
>> 8332473: ubsan: growableArray.hpp:290:10: runtime error: null pointer passed as argument 1, which is declared to never be null
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remarks Roger Riggs

Roger/Magnus,  should I still add some handling for Magnus' concern : "However, if we ever call this with a non-zero sp.dirlen and a null c->pdir, we'd be in trouble."
E.g. check for this and return -1  ?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19329#issuecomment-2127284704

From bkilambi at openjdk.org  Thu May 23 14:54:16 2024
From: bkilambi at openjdk.org (Bhavana Kilambi)
Date: Thu, 23 May 2024 14:54:16 GMT
Subject: RFR: 8327964: Simplify BigInteger.implMultiplyToLen intrinsic [v6]
In-Reply-To: <GkTIvOKs4GDKUOPjaw893H4fAoeBDuzQn4kKnQqG2dA=.7762f50b-40b1-4763-940b-7e0c8a66d466@github.com>
References: <Z5U-3OSq9_rd0t6DHNRhjF3LHtc9b6orz-mcQ4Uqzl8=.c4f0a0b8-9e10-4505-82f7-7d3a82929d22@github.com>
 <GkTIvOKs4GDKUOPjaw893H4fAoeBDuzQn4kKnQqG2dA=.7762f50b-40b1-4763-940b-7e0c8a66d466@github.com>
Message-ID: <MRg9cDtqSMtS8JaqakzD_612XvTDZpQmEGIllVNC680=.b42ec6b5-fe5f-4e2c-a922-63ce72ed5da7@github.com>

On Wed, 22 May 2024 14:47:43 GMT, Yudi Zheng <yzheng at openjdk.org> wrote:

>> Moving array construction within BigInteger.implMultiplyToLen intrinsic candidate to its caller simplifies the intrinsic implementation in JIT compiler.
>
> Yudi Zheng has updated the pull request incrementally with one additional commit since the last revision:
> 
>   address comments.

Tested tier1 on aarch64 and no failures. Also no regressions (or even gain) on aarch64 with the BigInteger testcase you mentioned. I think copyright year has not been updated for some of the files but I guess that's up to you.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18226#issuecomment-2127335211

From dl at openjdk.org  Thu May 23 14:56:20 2024
From: dl at openjdk.org (Doug Lea)
Date: Thu, 23 May 2024 14:56:20 GMT
Subject: RFR: 8322732: ForkJoinPool may underutilize cores in async mode
 [v4]
In-Reply-To: <xRyDMAsSZ7obqpr3Aoc5qrHqILeJMxFVCeiRdctMI3U=.d5d3cd56-32eb-4431-ac01-081822fc86c6@github.com>
References: <xRyDMAsSZ7obqpr3Aoc5qrHqILeJMxFVCeiRdctMI3U=.d5d3cd56-32eb-4431-ac01-081822fc86c6@github.com>
Message-ID: <HAznq6XP71iVBY1RA2l-3AyvNkL-TYhs-XAHVrsuuC4=.da36f31a-61ff-4271-82e5-171f43354bc8@github.com>

> This set of changes address causes of poor utilization with small numbers of cores due to overly aggressive contention avoidance. A number of further adjustments were needed to still avoid most contention effects in deployments with large numbers of cores

Doug Lea has updated the pull request incrementally with one additional commit since the last revision:

  Reduce memory stalls

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19131/files
  - new: https://git.openjdk.org/jdk/pull/19131/files/f1fc4f3e..28341747

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19131&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19131&range=02-03

  Stats: 57 lines in 1 file changed: 23 ins; 9 del; 25 mod
  Patch: https://git.openjdk.org/jdk/pull/19131.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19131/head:pull/19131

PR: https://git.openjdk.org/jdk/pull/19131

From iris at openjdk.org  Thu May 23 14:58:02 2024
From: iris at openjdk.org (Iris Clark)
Date: Thu, 23 May 2024 14:58:02 GMT
Subject: RFR: 8332749: Broken link in MemorySegment.Scope.html
In-Reply-To: <xIxgAl7ds3CS1f-OFWGR_oqcOs_oQj8soD12-6IOVvQ=.1662ac42-19a2-4c22-a88c-02daa125f476@github.com>
References: <xIxgAl7ds3CS1f-OFWGR_oqcOs_oQj8soD12-6IOVvQ=.1662ac42-19a2-4c22-a88c-02daa125f476@github.com>
Message-ID: <FhvUc80HnaEBi9GW6FTvOpaCzCHCq7Ji6UiUsXFtEZ0=.8cd07151-f9e4-4de0-bca2-bb454c901827@github.com>

On Thu, 23 May 2024 11:39:11 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR proposes to fix a broken link in the `MemorySegment.Scope` class.

Marked as reviewed by iris (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/19366#pullrequestreview-2074232921

From matsaave at openjdk.org  Thu May 23 15:07:07 2024
From: matsaave at openjdk.org (Matias Saavedra Silva)
Date: Thu, 23 May 2024 15:07:07 GMT
Subject: RFR: 8332340: Add JavacBench as a test case for CDS [v4]
In-Reply-To: <PgyOx-jq4-m7gJqgEUjDF_c2JFhFixTtypJWov6r1VA=.1fe4f700-a7f6-4bc6-8e44-41e95cfe9a7b@github.com>
References: <xqD4PeVZfIAKzywbLnjGZMFh36YSqXNolZkTgh1Vk6E=.44db7c57-64c1-4912-96e1-e61848312ccb@github.com>
 <PgyOx-jq4-m7gJqgEUjDF_c2JFhFixTtypJWov6r1VA=.1fe4f700-a7f6-4bc6-8e44-41e95cfe9a7b@github.com>
Message-ID: <PSAPbLdCPMlMqQPP8008r1zBot1-pbrMSzR0PCoVqCA=.d1c70e30-a475-45ac-bc0d-c4ef44f945f9@github.com>

On Wed, 22 May 2024 16:49:36 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> JavacBench is a test program that compiles 90 Java source files. It uses a fair amount of invokedynamic callsites, so it's good for testing CDS support for indy and lambda expressions.
>> 
>> This test was first integrated into the [leyden](https://github.com/openjdk/leyden/tree/premain) repo. Hence some of the files have copyrights in 2023.
>
> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
> 
>   @matias9927 comments

Changes look good

-------------

Marked as reviewed by matsaave (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19256#pullrequestreview-2074261985

From ihse at openjdk.org  Thu May 23 15:25:00 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 23 May 2024 15:25:00 GMT
Subject: RFR: 8332749: Broken link in MemorySegment.Scope.html
In-Reply-To: <xIxgAl7ds3CS1f-OFWGR_oqcOs_oQj8soD12-6IOVvQ=.1662ac42-19a2-4c22-a88c-02daa125f476@github.com>
References: <xIxgAl7ds3CS1f-OFWGR_oqcOs_oQj8soD12-6IOVvQ=.1662ac42-19a2-4c22-a88c-02daa125f476@github.com>
Message-ID: <911ryeXgYslH4RUQPGdQpgCkyzr21bBvsLCDnoi7gCQ=.124be388-0dc8-43bc-a94b-319b3bdcc6e9@github.com>

On Thu, 23 May 2024 11:39:11 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR proposes to fix a broken link in the `MemorySegment.Scope` class.

The fix looks fine but the bug title sounds like you are modifying an html file...

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19366#issuecomment-2127413592

From ihse at openjdk.org  Thu May 23 15:29:01 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 23 May 2024 15:29:01 GMT
Subject: RFR: 8332589: ubsan: unix/native/libjava/ProcessImpl_md.c:562:5:
 runtime error: null pointer passed as argument 2,
 which is declared to never be null [v2]
In-Reply-To: <Jmwe6R0-YXoCOmZLpD_riDxQortLtA2LXYd_ZOgXnr4=.209ec34c-7da1-4e49-879d-90e12df6d25f@github.com>
References: <AwlmAiTOhqSaoJ2Jh5YYrBpxakc0Pt9lYP9nvcBjXBo=.813efddf-3f87-4bbf-9cc5-cd769eabd2f7@github.com>
 <Jmwe6R0-YXoCOmZLpD_riDxQortLtA2LXYd_ZOgXnr4=.209ec34c-7da1-4e49-879d-90e12df6d25f@github.com>
Message-ID: <FT-0SpUBluODjxIqFGGYh7aJ_5hOG2NfY6PmDgHw7mo=.d4dab8d4-c139-436e-b137-793bad299a0e@github.com>

On Thu, 23 May 2024 07:26:14 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> When building with ubsan enabled (--enable-uban) on Linux x86_64 and doing jtreg tests afterwards I run into this error :
>> 
>> /jdk/src/java.base/unix/native/libjava/ProcessImpl_md.c:562:5: runtime error: null pointer passed as argument 2, which is declared to never be null
>>     #0 0x7fd95bec78d8 in spawnChild /jdk/src/java.base/unix/native/libjava/ProcessImpl_md.c:562
>>     #1 0x7fd95bec78d8 in startChild /jdk/src/java.base/unix/native/libjava/ProcessImpl_md.c:612
>>     #2 0x7fd95bec78d8 in Java_java_lang_ProcessImpl_forkAndExec /jdk/src/java.base/unix/native/libjava/ProcessImpl_md.c:712
>>     #3 0x7fd93797a06d (<unknown module>)
>> 
>> this is the memcpy call getting an unexpected null pointer :
>>     memcpy(buf+offset, c->pdir, sp.dirlen); gets a second parameter null.
>> Something similar was discussed and fixed here https://bugs.python.org/issue27570 for Python .
>> 
>> Similar issue in OpenJDK _ 
>> https://bugs.openjdk.org/browse/JDK-8332473
>> 8332473: ubsan: growableArray.hpp:290:10: runtime error: null pointer passed as argument 1, which is declared to never be null
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remarks Roger Riggs

As a general principle, I think you should detect errors and report them instead of ignoring them and continue. I don't know any details of this specific code, though.

The scenario with a null pointer and non-0 length seems unlikely and would only happen if there is a bug in the calling code. Nevertheless, I think it would be more prudent to guard against this condition.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19329#issuecomment-2127421468

From iklam at openjdk.org  Thu May 23 16:04:02 2024
From: iklam at openjdk.org (Ioi Lam)
Date: Thu, 23 May 2024 16:04:02 GMT
Subject: RFR: 8332340: Add JavacBench as a test case for CDS [v4]
In-Reply-To: <PgyOx-jq4-m7gJqgEUjDF_c2JFhFixTtypJWov6r1VA=.1fe4f700-a7f6-4bc6-8e44-41e95cfe9a7b@github.com>
References: <xqD4PeVZfIAKzywbLnjGZMFh36YSqXNolZkTgh1Vk6E=.44db7c57-64c1-4912-96e1-e61848312ccb@github.com>
 <PgyOx-jq4-m7gJqgEUjDF_c2JFhFixTtypJWov6r1VA=.1fe4f700-a7f6-4bc6-8e44-41e95cfe9a7b@github.com>
Message-ID: <ins3PH2tSS45cGXIf0Q7OQTMvlVRrDYZ2nIp0I3l4kk=.d2075e28-add7-4609-b20b-f05005bb0469@github.com>

On Wed, 22 May 2024 16:49:36 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> JavacBench is a test program that compiles 90 Java source files. It uses a fair amount of invokedynamic callsites, so it's good for testing CDS support for indy and lambda expressions.
>> 
>> This test was first integrated into the [leyden](https://github.com/openjdk/leyden/tree/premain) repo. Hence some of the files have copyrights in 2023.
>
> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
> 
>   @matias9927 comments

Thanks @liach @calvinccheung @matias9927 for the review

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19256#issuecomment-2127510912

From iklam at openjdk.org  Thu May 23 16:08:13 2024
From: iklam at openjdk.org (Ioi Lam)
Date: Thu, 23 May 2024 16:08:13 GMT
Subject: Integrated: 8332340: Add JavacBench as a test case for CDS
In-Reply-To: <xqD4PeVZfIAKzywbLnjGZMFh36YSqXNolZkTgh1Vk6E=.44db7c57-64c1-4912-96e1-e61848312ccb@github.com>
References: <xqD4PeVZfIAKzywbLnjGZMFh36YSqXNolZkTgh1Vk6E=.44db7c57-64c1-4912-96e1-e61848312ccb@github.com>
Message-ID: <6iCK1_BqrH_WODItf2jwI9Vt4qtygFj7MvecZ_iOoVg=.ca061ac6-1b9e-47af-81cc-0eb03042a7ca@github.com>

On Thu, 16 May 2024 02:37:02 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> JavacBench is a test program that compiles 90 Java source files. It uses a fair amount of invokedynamic callsites, so it's good for testing CDS support for indy and lambda expressions.
> 
> This test was first integrated into the [leyden](https://github.com/openjdk/leyden/tree/premain) repo. Hence some of the files have copyrights in 2023.

This pull request has now been integrated.

Changeset: 7fd9d6c7
Author:    Ioi Lam <iklam at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/7fd9d6c760c66d3e2f4034cf1a6b1b583ff829a9
Stats:     607 lines in 4 files changed: 607 ins; 0 del; 0 mod

8332340: Add JavacBench as a test case for CDS

Reviewed-by: ccheung, matsaave

-------------

PR: https://git.openjdk.org/jdk/pull/19256

From sgehwolf at openjdk.org  Thu May 23 16:45:14 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Thu, 23 May 2024 16:45:14 GMT
Subject: RFR: 8311302: Allow for jlinking a custom runtime without packaged
 modules being present [v23]
In-Reply-To: <jVDOxyjqQW4VQy-JvAzdBe1IN2U1oqWsSvFZ1I3psUg=.c1d71ba8-f5b8-4dd8-bad0-369ecb166966@github.com>
References: <Z0DJ87uKPbjS6mvJIE_oG5m-RWsbERXsytSgV8Bmhdo=.f8723513-0ac6-4e85-9131-3c3924860c61@github.com>
 <Xkl8CJMCXm7iBI2ZnfH9JnoZx08wd5InSwIZHW_kMeQ=.49022322-cb0d-4f1a-947a-6eb37b7da963@github.com>
 <fvDpjxyhqnpaEhF6KhMIJBv_sG87AsuC0axsJYo1Tvw=.442f5a11-44f0-4a00-812a-2c26ec15e8e6@github.com>
 <_sbNFJXG7ghwsfNfxaGvvoDQ7-UtWpnhGnygKsFTsgQ=.623700db-7306-4b34-9e05-ca9059797e39@github.com>
 <DpJV4x9Mnw0upmd3SR_ES2ytuLAo7PsI-ecHERPAOcY=.0a0c2f26-7a9f-4be6-8e71-0494d4673fe7@github.com>
 <jVDOxyjqQW4VQy-JvAzdBe1IN2U1oqWsSvFZ1I3psUg=.c1d71ba8-f5b8-4dd8-bad0-369ecb166966@github.com>
Message-ID: <0p024fM1f37tPV49K78xyyJ01uEUh5I1XcsXoJBK0_Q=.4c2e6cc4-71d0-4d6f-a3a3-13bba0ab2a84@github.com>

On Thu, 16 May 2024 13:47:20 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>>> If I understand you correctly, this would be no longer a build-time only approach to produce the "linkable runtime"? It would be some-kind of jlink-option driven approach (as it would run some code that should only run when producing a linkable runtime is requested)? Other than that, it should be fine as the previous iteration basically did that but at a different phase. Also note that the previous iteration used a build-only jlink plugin so as to satisfy the build-time only approach, yet it ran as part of the plugin-pipeline which wasn't desired either. But it was something similar to what you seem to be describing now. Did I get something wrong?
>> 
>> I think it continues to build time, it's just using some hidden jlink option. So yes, it similar to a previous iteration except that it doesn't run as a plugin the pipeline and the delta goes to the lib directory.
>> 
>> Let's see what @mlchung says. You've put a lot of work into this so let's see if we can converge to avoid too many more rounds.
>
>> @AlanBateman @mlchung The latest update now uses the `jlink` build time option `--generate-linkable-runtime` to add needed resources to the `jimage` when a runtime linkable JDK image is being asked for using the configure option. This now runs outside the plugin-pipeline. I think this is what you meant. Sorry it took longer to get back to this...
> 
> I think you've got this to a good place and I think the overall solution is good. It may be that JDK should move to this by default in the future, and at the same time re-visit the restriction on generating an image containing jdk.jlink, but let's see if any issues come up.
> 
> I've added myself as Reviewer to the CSR and I'm working through the code changes.

@AlanBateman 

> I'm working through the code changes.

Do you think you'll be able to review this next week?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14787#issuecomment-2127614784

From sgibbons at openjdk.org  Thu May 23 17:04:26 2024
From: sgibbons at openjdk.org (Scott Gibbons)
Date: Thu, 23 May 2024 17:04:26 GMT
Subject: RFR: 8320448: Accelerate IndexOf using AVX2 [v32]
In-Reply-To: <uWi4QxH31hL93771gkl_GgvP0m84IRSoR_1Yi8hD17E=.bc6ed458-7081-4c3f-9348-f59358fa05a4@github.com>
References: <uWi4QxH31hL93771gkl_GgvP0m84IRSoR_1Yi8hD17E=.bc6ed458-7081-4c3f-9348-f59358fa05a4@github.com>
Message-ID: <79fqpujoxeB-9xiWMWM9tTYQRsOqS6vHP4poomY0DSU=.7d52f61f-cafc-4a62-b27e-7ec9e35103ef@github.com>

> Re-write the IndexOf code without the use of the pcmpestri instruction, only using AVX2 instructions.  This change accelerates String.IndexOf on average 1.3x for AVX2.  The benchmark numbers:
> 
> 
> Benchmark	                                               Score		Latest		
> StringIndexOf.advancedWithMediumSub   343.573		317.934		0.925375393x
> StringIndexOf.advancedWithShortSub1	  1039.081		1053.96		1.014319384x
> StringIndexOf.advancedWithShortSub2	      55.828		110.541		1.980027943x
> StringIndexOf.constantPattern	                9.361		11.906		1.271872663x
> StringIndexOf.searchCharLongSuccess	        4.216		4.218		1.000474383x
> StringIndexOf.searchCharMediumSuccess	3.133		3.216		1.02649218x
> StringIndexOf.searchCharShortSuccess	3.76		        3.761		1.000265957x
> StringIndexOf.success	                                9.186		9.713		1.057369911x
> StringIndexOf.successBig	                      14.341		46.343		3.231504079x
> StringIndexOfChar.latin1_AVX2_String	  6220.918		12154.52		1.953814533x
> StringIndexOfChar.latin1_AVX2_char	  5503.556		5540.044		1.006629895x
> StringIndexOfChar.latin1_SSE4_String	  6978.854		6818.689		0.977049957x
> StringIndexOfChar.latin1_SSE4_char	  5657.499		5474.624		0.967675646x
> StringIndexOfChar.latin1_Short_String	  7132.541		6863.359		0.962260014x
> StringIndexOfChar.latin1_Short_char	16013.389	      16162.437		1.009307711x
> StringIndexOfChar.latin1_mixed_String	  7386.123	      14771.622		1.999915517x
> StringIndexOfChar.latin1_mixed_char	  9901.671		9782.245		0.987938803

Scott Gibbons has updated the pull request incrementally with one additional commit since the last revision:

  Check macos build

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/16753/files
  - new: https://git.openjdk.org/jdk/pull/16753/files/87b1ebe8..23d2c511

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16753&range=31
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16753&range=30-31

  Stats: 109 lines in 1 file changed: 42 ins; 4 del; 63 mod
  Patch: https://git.openjdk.org/jdk/pull/16753.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16753/head:pull/16753

PR: https://git.openjdk.org/jdk/pull/16753

From prappo at openjdk.org  Thu May 23 17:14:19 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Thu, 23 May 2024 17:14:19 GMT
Subject: RFR: 8305457: Implement java.io.IO [v13]
In-Reply-To: <w2msiw_qaMEIJS3s9D4bg8pFbz5WIF0KdP6Mm-XFjLI=.85b2020b-8c46-4bac-8a69-4975b068f2ff@github.com>
References: <w2msiw_qaMEIJS3s9D4bg8pFbz5WIF0KdP6Mm-XFjLI=.85b2020b-8c46-4bac-8a69-4975b068f2ff@github.com>
Message-ID: <OeX8FjKjxcEY8Xww8oZ31Uxo5odfSLt9msAYKr5AuIA=.40796307-4eab-4266-a3df-5cf4a8d422c8@github.com>

> Please review this PR which introduces the `java.io.IO` top-level class and three methods to `java.io.Console` for [Implicitly Declared Classes and Instance Main Methods (Third Preview)].
> 
> This PR has been obtained as `git merge --squash` of a now obsolete [draft PR].
> 
> [Implicitly Declared Classes and Instance Main Methods (Third Preview)]: https://bugs.openjdk.org/browse/JDK-8323335
> [draft PR]: https://github.com/openjdk/jdk/pull/18921

Pavel Rappo has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 23 commits:

 - Merge branch 'master' into 8305457-Implement-java.io.IO
 - Force reasonable terminal size
   
   JLine outputs unexpected stuff if the terminal isn't dumb and small,
   such as that of our CI machines:
   
       if (newLines.size() > displaySize && !isTerminalDumb()) {
           StringBuilder sb = new StringBuilder(">....");
   
   This causes the IO test to fail with timeout, because the expected
   prompt is never matched. To avoid that, we reasonably size the
   terminal.
 - Restructure the test
 - Add diagnostic output
 - Use "expect" that was found
 - Merge branch 'master' into 8305457-Implement-java.io.IO
   
   # Conflicts:
   #	src/java.base/share/classes/java/io/ProxyingConsole.java
   #	src/java.base/share/classes/jdk/internal/io/JdkConsole.java
   #	src/java.base/share/classes/jdk/internal/io/JdkConsoleImpl.java
   #	src/jdk.internal.le/share/classes/jdk/internal/org/jline/JdkConsoleProviderImpl.java
   #	src/jdk.jshell/share/classes/jdk/jshell/execution/impl/ConsoleImpl.java
 - Escape prompt
 - Merge branch 'master' into 8305457-Implement-java.io.IO
 - Clarify input charset
 - Make IO final
 - ... and 13 more: https://git.openjdk.org/jdk/compare/e19a421c...258ce133

-------------

Changes: https://git.openjdk.org/jdk/pull/19112/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19112&range=12
  Stats: 690 lines in 13 files changed: 690 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/19112.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19112/head:pull/19112

PR: https://git.openjdk.org/jdk/pull/19112

From sgibbons at openjdk.org  Thu May 23 17:25:34 2024
From: sgibbons at openjdk.org (Scott Gibbons)
Date: Thu, 23 May 2024 17:25:34 GMT
Subject: RFR: 8320448: Accelerate IndexOf using AVX2 [v33]
In-Reply-To: <uWi4QxH31hL93771gkl_GgvP0m84IRSoR_1Yi8hD17E=.bc6ed458-7081-4c3f-9348-f59358fa05a4@github.com>
References: <uWi4QxH31hL93771gkl_GgvP0m84IRSoR_1Yi8hD17E=.bc6ed458-7081-4c3f-9348-f59358fa05a4@github.com>
Message-ID: <kE-TMUMyr6ADsj3wtDB9RlLnXaJFbFzmd7cikzCEuSg=.490d5dd5-eaa8-4137-8e00-7d5de1efb598@github.com>

> Re-write the IndexOf code without the use of the pcmpestri instruction, only using AVX2 instructions.  This change accelerates String.IndexOf on average 1.3x for AVX2.  The benchmark numbers:
> 
> 
> Benchmark	                                               Score		Latest		
> StringIndexOf.advancedWithMediumSub   343.573		317.934		0.925375393x
> StringIndexOf.advancedWithShortSub1	  1039.081		1053.96		1.014319384x
> StringIndexOf.advancedWithShortSub2	      55.828		110.541		1.980027943x
> StringIndexOf.constantPattern	                9.361		11.906		1.271872663x
> StringIndexOf.searchCharLongSuccess	        4.216		4.218		1.000474383x
> StringIndexOf.searchCharMediumSuccess	3.133		3.216		1.02649218x
> StringIndexOf.searchCharShortSuccess	3.76		        3.761		1.000265957x
> StringIndexOf.success	                                9.186		9.713		1.057369911x
> StringIndexOf.successBig	                      14.341		46.343		3.231504079x
> StringIndexOfChar.latin1_AVX2_String	  6220.918		12154.52		1.953814533x
> StringIndexOfChar.latin1_AVX2_char	  5503.556		5540.044		1.006629895x
> StringIndexOfChar.latin1_SSE4_String	  6978.854		6818.689		0.977049957x
> StringIndexOfChar.latin1_SSE4_char	  5657.499		5474.624		0.967675646x
> StringIndexOfChar.latin1_Short_String	  7132.541		6863.359		0.962260014x
> StringIndexOfChar.latin1_Short_char	16013.389	      16162.437		1.009307711x
> StringIndexOfChar.latin1_mixed_String	  7386.123	      14771.622		1.999915517x
> StringIndexOfChar.latin1_mixed_char	  9901.671		9782.245		0.987938803

Scott Gibbons has updated the pull request incrementally with one additional commit since the last revision:

  Fix for IndexOf.java on mac

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/16753/files
  - new: https://git.openjdk.org/jdk/pull/16753/files/23d2c511..cba6ffbe

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16753&range=32
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16753&range=31-32

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/16753.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16753/head:pull/16753

PR: https://git.openjdk.org/jdk/pull/16753

From pminborg at openjdk.org  Thu May 23 18:16:10 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 23 May 2024 18:16:10 GMT
Subject: Integrated: 8332749: Broken link in MemorySegment.Scope.html
In-Reply-To: <xIxgAl7ds3CS1f-OFWGR_oqcOs_oQj8soD12-6IOVvQ=.1662ac42-19a2-4c22-a88c-02daa125f476@github.com>
References: <xIxgAl7ds3CS1f-OFWGR_oqcOs_oQj8soD12-6IOVvQ=.1662ac42-19a2-4c22-a88c-02daa125f476@github.com>
Message-ID: <N2YudCtjTp9xWhc3FCYBK5B-7OjFpXT_2yL3TAC6QdY=.4ef6d3a1-f294-4365-a1d4-7359a733d7b5@github.com>

On Thu, 23 May 2024 11:39:11 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR proposes to fix a broken link in the `MemorySegment.Scope` class.

This pull request has now been integrated.

Changeset: 0a9d1f8c
Author:    Per Minborg <pminborg at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/0a9d1f8c89e946d99f01549515f6044e53992168
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8332749: Broken link in MemorySegment.Scope.html

Reviewed-by: iris

-------------

PR: https://git.openjdk.org/jdk/pull/19366

From smarks at openjdk.org  Thu May 23 18:39:06 2024
From: smarks at openjdk.org (Stuart Marks)
Date: Thu, 23 May 2024 18:39:06 GMT
Subject: RFR: 8305457: Implement java.io.IO [v13]
In-Reply-To: <OeX8FjKjxcEY8Xww8oZ31Uxo5odfSLt9msAYKr5AuIA=.40796307-4eab-4266-a3df-5cf4a8d422c8@github.com>
References: <w2msiw_qaMEIJS3s9D4bg8pFbz5WIF0KdP6Mm-XFjLI=.85b2020b-8c46-4bac-8a69-4975b068f2ff@github.com>
 <OeX8FjKjxcEY8Xww8oZ31Uxo5odfSLt9msAYKr5AuIA=.40796307-4eab-4266-a3df-5cf4a8d422c8@github.com>
Message-ID: <8LfSUCtJ1kyqUam65aOt7od1_QTBgUpDSIeUgOX2uHU=.80249710-1354-4fab-ab1d-21af1ce56f9f@github.com>

On Thu, 23 May 2024 17:14:19 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Please review this PR which introduces the `java.io.IO` top-level class and three methods to `java.io.Console` for [Implicitly Declared Classes and Instance Main Methods (Third Preview)].
>> 
>> This PR has been obtained as `git merge --squash` of a now obsolete [draft PR].
>> 
>> [Implicitly Declared Classes and Instance Main Methods (Third Preview)]: https://bugs.openjdk.org/browse/JDK-8323335
>> [draft PR]: https://github.com/openjdk/jdk/pull/18921
>
> Pavel Rappo has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 23 commits:
> 
>  - Merge branch 'master' into 8305457-Implement-java.io.IO
>  - Force reasonable terminal size
>    
>    JLine outputs unexpected stuff if the terminal isn't dumb and small,
>    such as that of our CI machines:
>    
>        if (newLines.size() > displaySize && !isTerminalDumb()) {
>            StringBuilder sb = new StringBuilder(">....");
>    
>    This causes the IO test to fail with timeout, because the expected
>    prompt is never matched. To avoid that, we reasonably size the
>    terminal.
>  - Restructure the test
>  - Add diagnostic output
>  - Use "expect" that was found
>  - Merge branch 'master' into 8305457-Implement-java.io.IO
>    
>    # Conflicts:
>    #	src/java.base/share/classes/java/io/ProxyingConsole.java
>    #	src/java.base/share/classes/jdk/internal/io/JdkConsole.java
>    #	src/java.base/share/classes/jdk/internal/io/JdkConsoleImpl.java
>    #	src/jdk.internal.le/share/classes/jdk/internal/org/jline/JdkConsoleProviderImpl.java
>    #	src/jdk.jshell/share/classes/jdk/jshell/execution/impl/ConsoleImpl.java
>  - Escape prompt
>  - Merge branch 'master' into 8305457-Implement-java.io.IO
>  - Clarify input charset
>  - Make IO final
>  - ... and 13 more: https://git.openjdk.org/jdk/compare/e19a421c...258ce133

Updates look good.

-------------

Marked as reviewed by smarks (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19112#pullrequestreview-2074746185

From alanb at openjdk.org  Thu May 23 18:55:14 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 23 May 2024 18:55:14 GMT
Subject: RFR: 8311302: Allow for jlinking a custom runtime without packaged
 modules being present [v23]
In-Reply-To: <0p024fM1f37tPV49K78xyyJ01uEUh5I1XcsXoJBK0_Q=.4c2e6cc4-71d0-4d6f-a3a3-13bba0ab2a84@github.com>
References: <Z0DJ87uKPbjS6mvJIE_oG5m-RWsbERXsytSgV8Bmhdo=.f8723513-0ac6-4e85-9131-3c3924860c61@github.com>
 <Xkl8CJMCXm7iBI2ZnfH9JnoZx08wd5InSwIZHW_kMeQ=.49022322-cb0d-4f1a-947a-6eb37b7da963@github.com>
 <fvDpjxyhqnpaEhF6KhMIJBv_sG87AsuC0axsJYo1Tvw=.442f5a11-44f0-4a00-812a-2c26ec15e8e6@github.com>
 <_sbNFJXG7ghwsfNfxaGvvoDQ7-UtWpnhGnygKsFTsgQ=.623700db-7306-4b34-9e05-ca9059797e39@github.com>
 <DpJV4x9Mnw0upmd3SR_ES2ytuLAo7PsI-ecHERPAOcY=.0a0c2f26-7a9f-4be6-8e71-0494d4673fe7@github.com>
 <jVDOxyjqQW4VQy-JvAzdBe1IN2U1oqWsSvFZ1I3psUg=.c1d71ba8-f5b8-4dd8-bad0-369ecb166966@github.com>
 <0p024fM1f37tPV49K78xyyJ01uEUh5I1XcsXoJBK0_Q=.4c2e6cc4-71d0-4d6f-a3a3-13bba0ab2a84@github.com>
Message-ID: <e9Obu0f3PmWjFQZM0FzOw854j_iEfatxY4Cjpc70veE=.834d3df3-2758-4b48-a505-92ea59ecb017@github.com>

On Thu, 23 May 2024 16:42:39 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

> Do you think you'll be able to review this next week?

Yes, I want to help you get this one over the line.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14787#issuecomment-2127828050

From djelinski at openjdk.org  Thu May 23 19:12:12 2024
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Thu, 23 May 2024 19:12:12 GMT
Subject: RFR: 8320448: Accelerate IndexOf using AVX2 [v33]
In-Reply-To: <kE-TMUMyr6ADsj3wtDB9RlLnXaJFbFzmd7cikzCEuSg=.490d5dd5-eaa8-4137-8e00-7d5de1efb598@github.com>
References: <uWi4QxH31hL93771gkl_GgvP0m84IRSoR_1Yi8hD17E=.bc6ed458-7081-4c3f-9348-f59358fa05a4@github.com>
 <kE-TMUMyr6ADsj3wtDB9RlLnXaJFbFzmd7cikzCEuSg=.490d5dd5-eaa8-4137-8e00-7d5de1efb598@github.com>
Message-ID: <GkGAR2YTtCDe_xFo2a7MxxJyoo-dsgghT9TvqfntN3c=.e40c4157-c48d-4454-b08e-17d6eb9b85a1@github.com>

On Thu, 23 May 2024 17:25:34 GMT, Scott Gibbons <sgibbons at openjdk.org> wrote:

>> Re-write the IndexOf code without the use of the pcmpestri instruction, only using AVX2 instructions.  This change accelerates String.IndexOf on average 1.3x for AVX2.  The benchmark numbers:
>> 
>> 
>> Benchmark	                                               Score		Latest		
>> StringIndexOf.advancedWithMediumSub   343.573		317.934		0.925375393x
>> StringIndexOf.advancedWithShortSub1	  1039.081		1053.96		1.014319384x
>> StringIndexOf.advancedWithShortSub2	      55.828		110.541		1.980027943x
>> StringIndexOf.constantPattern	                9.361		11.906		1.271872663x
>> StringIndexOf.searchCharLongSuccess	        4.216		4.218		1.000474383x
>> StringIndexOf.searchCharMediumSuccess	3.133		3.216		1.02649218x
>> StringIndexOf.searchCharShortSuccess	3.76		        3.761		1.000265957x
>> StringIndexOf.success	                                9.186		9.713		1.057369911x
>> StringIndexOf.successBig	                      14.341		46.343		3.231504079x
>> StringIndexOfChar.latin1_AVX2_String	  6220.918		12154.52		1.953814533x
>> StringIndexOfChar.latin1_AVX2_char	  5503.556		5540.044		1.006629895x
>> StringIndexOfChar.latin1_SSE4_String	  6978.854		6818.689		0.977049957x
>> StringIndexOfChar.latin1_SSE4_char	  5657.499		5474.624		0.967675646x
>> StringIndexOfChar.latin1_Short_String	  7132.541		6863.359		0.962260014x
>> StringIndexOfChar.latin1_Short_char	16013.389	      16162.437		1.009307711x
>> StringIndexOfChar.latin1_mixed_String	  7386.123	      14771.622		1.999915517x
>> StringIndexOfChar.latin1_mixed_char	  9901.671		9782.245		0.987938803
>
> Scott Gibbons has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix for IndexOf.java on mac

src/hotspot/cpu/x86/stubGenerator_x86_64_string.cpp line 268:

> 266:   __ cmpq(needle_len_p, 0);
> 267:   __ jg_b(L_nextCheck);
> 268:   __ xorq(rax, rax);

out of curiosity, is there any advantage to using `xorq` instead of `xorl` here?

https://stackoverflow.com/a/33668295/7707617 suggests that `xorl` might be better, but it's a bit dated now.

src/hotspot/cpu/x86/stubGenerator_x86_64_string.cpp line 449:

> 447:   __ cmpq(r13, NUMBER_OF_CASES - 1);
> 448:   __ ja(L_smallCaseDefault);
> 449:   __ mov64(r15, (int64_t)small_jump_table);

would it make sense to use `lea` here?

src/hotspot/cpu/x86/stubGenerator_x86_64_string.cpp line 803:

> 801:     __ movq(index, needle_len);
> 802:     __ andq(index, 0xf);  // nLen % 16
> 803:     __ movq(offset, 0x10);

`movl` or `movptr` would produce a shorter encoding

src/hotspot/cpu/x86/stubGenerator_x86_64_string.cpp line 1544:

> 1542:   }
> 1543: 
> 1544:   __ align(8);

why `8` and not `OptoLoopAlignment` ?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1612178285
PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1612179069
PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1612180163
PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1612183311

From sgibbons at openjdk.org  Thu May 23 19:49:11 2024
From: sgibbons at openjdk.org (Scott Gibbons)
Date: Thu, 23 May 2024 19:49:11 GMT
Subject: RFR: 8320448: Accelerate IndexOf using AVX2 [v33]
In-Reply-To: <GkGAR2YTtCDe_xFo2a7MxxJyoo-dsgghT9TvqfntN3c=.e40c4157-c48d-4454-b08e-17d6eb9b85a1@github.com>
References: <uWi4QxH31hL93771gkl_GgvP0m84IRSoR_1Yi8hD17E=.bc6ed458-7081-4c3f-9348-f59358fa05a4@github.com>
 <kE-TMUMyr6ADsj3wtDB9RlLnXaJFbFzmd7cikzCEuSg=.490d5dd5-eaa8-4137-8e00-7d5de1efb598@github.com>
 <GkGAR2YTtCDe_xFo2a7MxxJyoo-dsgghT9TvqfntN3c=.e40c4157-c48d-4454-b08e-17d6eb9b85a1@github.com>
Message-ID: <nxpwP6Q_co_mHw7hIyjBjPSjuR6HUc3-ioT80k0tpqE=.fca7f3a5-a511-481c-b630-abeb4402268c@github.com>

On Thu, 23 May 2024 19:02:05 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> Scott Gibbons has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix for IndexOf.java on mac
>
> src/hotspot/cpu/x86/stubGenerator_x86_64_string.cpp line 268:
> 
>> 266:   __ cmpq(needle_len_p, 0);
>> 267:   __ jg_b(L_nextCheck);
>> 268:   __ xorq(rax, rax);
> 
> out of curiosity, is there any advantage to using `xorq` instead of `xorl` here?
> 
> https://stackoverflow.com/a/33668295/7707617 suggests that `xorl` might be better, but it's a bit dated now.

Thanks for finding this.  It was ignorance on my part as I thought the xorq would have logic to not emit the REX prefix if not necessary, but it doesn't.  Fixed.

> src/hotspot/cpu/x86/stubGenerator_x86_64_string.cpp line 449:
> 
>> 447:   __ cmpq(r13, NUMBER_OF_CASES - 1);
>> 448:   __ ja(L_smallCaseDefault);
>> 449:   __ mov64(r15, (int64_t)small_jump_table);
> 
> would it make sense to use `lea` here?

It may, but I believe the movq is shorter (although maybe not to r15).  I'll do some experimentation.

> src/hotspot/cpu/x86/stubGenerator_x86_64_string.cpp line 803:
> 
>> 801:     __ movq(index, needle_len);
>> 802:     __ andq(index, 0xf);  // nLen % 16
>> 803:     __ movq(offset, 0x10);
> 
> `movl` or `movptr` would produce a shorter encoding

I tried to be consistent with the whole {q,l} syntax throughout when referring to each symbolic register.  I feel that changing this would ripple through the code.  @sviswa7 what do you think?

> src/hotspot/cpu/x86/stubGenerator_x86_64_string.cpp line 1544:
> 
>> 1542:   }
>> 1543: 
>> 1544:   __ align(8);
> 
> why `8` and not `OptoLoopAlignment` ?

Short answer - because I didn't know there was such a thing as `OptoLoopAlignment`.  I'll change that throughout at the top of my loops.  Thanks.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1612201503
PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1612207461
PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1612216483
PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1612218363

From sgibbons at openjdk.org  Thu May 23 19:54:39 2024
From: sgibbons at openjdk.org (Scott Gibbons)
Date: Thu, 23 May 2024 19:54:39 GMT
Subject: RFR: 8320448: Accelerate IndexOf using AVX2 [v34]
In-Reply-To: <uWi4QxH31hL93771gkl_GgvP0m84IRSoR_1Yi8hD17E=.bc6ed458-7081-4c3f-9348-f59358fa05a4@github.com>
References: <uWi4QxH31hL93771gkl_GgvP0m84IRSoR_1Yi8hD17E=.bc6ed458-7081-4c3f-9348-f59358fa05a4@github.com>
Message-ID: <13CORNysYmupJ3F2_7ekNqob8pz_xNmTg8gyKIt5vgs=.572e9f52-62ea-44cd-bac4-ab99a09a7510@github.com>

> Re-write the IndexOf code without the use of the pcmpestri instruction, only using AVX2 instructions.  This change accelerates String.IndexOf on average 1.3x for AVX2.  The benchmark numbers:
> 
> 
> Benchmark	                                               Score		Latest		
> StringIndexOf.advancedWithMediumSub   343.573		317.934		0.925375393x
> StringIndexOf.advancedWithShortSub1	  1039.081		1053.96		1.014319384x
> StringIndexOf.advancedWithShortSub2	      55.828		110.541		1.980027943x
> StringIndexOf.constantPattern	                9.361		11.906		1.271872663x
> StringIndexOf.searchCharLongSuccess	        4.216		4.218		1.000474383x
> StringIndexOf.searchCharMediumSuccess	3.133		3.216		1.02649218x
> StringIndexOf.searchCharShortSuccess	3.76		        3.761		1.000265957x
> StringIndexOf.success	                                9.186		9.713		1.057369911x
> StringIndexOf.successBig	                      14.341		46.343		3.231504079x
> StringIndexOfChar.latin1_AVX2_String	  6220.918		12154.52		1.953814533x
> StringIndexOfChar.latin1_AVX2_char	  5503.556		5540.044		1.006629895x
> StringIndexOfChar.latin1_SSE4_String	  6978.854		6818.689		0.977049957x
> StringIndexOfChar.latin1_SSE4_char	  5657.499		5474.624		0.967675646x
> StringIndexOfChar.latin1_Short_String	  7132.541		6863.359		0.962260014x
> StringIndexOfChar.latin1_Short_char	16013.389	      16162.437		1.009307711x
> StringIndexOfChar.latin1_mixed_String	  7386.123	      14771.622		1.999915517x
> StringIndexOfChar.latin1_mixed_char	  9901.671		9782.245		0.987938803

Scott Gibbons has updated the pull request incrementally with one additional commit since the last revision:

  Addressing review comments

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/16753/files
  - new: https://git.openjdk.org/jdk/pull/16753/files/cba6ffbe..2283f2bf

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16753&range=33
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16753&range=32-33

  Stats: 7 lines in 2 files changed: 0 ins; 0 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/16753.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16753/head:pull/16753

PR: https://git.openjdk.org/jdk/pull/16753

From vromero at openjdk.org  Thu May 23 20:17:26 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 23 May 2024 20:17:26 GMT
Subject: RFR: 8320575: generic type information lost on mandated parameters
 of record's compact constructors [v21]
In-Reply-To: <20VdLsPE7Md_hxgniEhF0WPmdo_WXqbBswWdn2Az9N4=.0821e94c-4745-41e9-95a4-147f98657718@github.com>
References: <20VdLsPE7Md_hxgniEhF0WPmdo_WXqbBswWdn2Az9N4=.0821e94c-4745-41e9-95a4-147f98657718@github.com>
Message-ID: <k9FpfTiayQ_lra-xd5Z4UJd84zPwhR51H0mivQCRDp0=.c08397fa-bb99-4fbb-b405-35f4541f4cc0@github.com>

> Reflection is not retrieving generic type information for mandated parameters. This is a known issue which has been explicitly stated in the API of some reflection methods. Fix for [JDK-8292275](https://bugs.openjdk.org/browse/JDK-8292275) made the parameters of compact constructors of record classes `mandated` as specified in the spec. But this implied that users that previous to this change could retrieve the generic type of parameters of compact constructors now they can't anymore. The proposed fix is to try to retrieve generic type information for mandated parameters if available plus changing the spec of the related reflection methods.
> 
> TIA

Vicente Romero 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 22 additional commits since the last revision:

 - Merge branch 'master' into JDK-8320575
 - addressing review comments
 - Merge branch 'master' into JDK-8320575
 - minor refactoring
 - Merge branch 'master' into JDK-8320575
 - code refactoring
 - additional tests
 - special case the new code for records only
 - adding more tests
 - Update test/jdk/java/lang/reflect/records/RecordReflectionTest.java
   
   Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>
 - ... and 12 more: https://git.openjdk.org/jdk/compare/99407cc4...8ee8ffda

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17070/files
  - new: https://git.openjdk.org/jdk/pull/17070/files/37010e19..8ee8ffda

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17070&range=20
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17070&range=19-20

  Stats: 52649 lines in 828 files changed: 41644 ins; 7953 del; 3052 mod
  Patch: https://git.openjdk.org/jdk/pull/17070.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17070/head:pull/17070

PR: https://git.openjdk.org/jdk/pull/17070

From vromero at openjdk.org  Thu May 23 21:52:30 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 23 May 2024 21:52:30 GMT
Subject: RFR: 8320575: generic type information lost on mandated parameters
 of record's compact constructors [v22]
In-Reply-To: <20VdLsPE7Md_hxgniEhF0WPmdo_WXqbBswWdn2Az9N4=.0821e94c-4745-41e9-95a4-147f98657718@github.com>
References: <20VdLsPE7Md_hxgniEhF0WPmdo_WXqbBswWdn2Az9N4=.0821e94c-4745-41e9-95a4-147f98657718@github.com>
Message-ID: <qFZ40PoVZNuQw5sGW13ZZywJ5u2ehIhDKUOGkdkdWbs=.aefeb09a-b628-40ab-b10f-a1220a474e1c@github.com>

> Reflection is not retrieving generic type information for mandated parameters. This is a known issue which has been explicitly stated in the API of some reflection methods. Fix for [JDK-8292275](https://bugs.openjdk.org/browse/JDK-8292275) made the parameters of compact constructors of record classes `mandated` as specified in the spec. But this implied that users that previous to this change could retrieve the generic type of parameters of compact constructors now they can't anymore. The proposed fix is to try to retrieve generic type information for mandated parameters if available plus changing the spec of the related reflection methods.
> 
> TIA

Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:

  addressing review comments

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17070/files
  - new: https://git.openjdk.org/jdk/pull/17070/files/8ee8ffda..9ff2ba2e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17070&range=21
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17070&range=20-21

  Stats: 12 lines in 1 file changed: 4 ins; 0 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/17070.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17070/head:pull/17070

PR: https://git.openjdk.org/jdk/pull/17070

From kvn at openjdk.org  Thu May 23 22:11:12 2024
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Thu, 23 May 2024 22:11:12 GMT
Subject: RFR: 8320448: Accelerate IndexOf using AVX2 [v34]
In-Reply-To: <13CORNysYmupJ3F2_7ekNqob8pz_xNmTg8gyKIt5vgs=.572e9f52-62ea-44cd-bac4-ab99a09a7510@github.com>
References: <uWi4QxH31hL93771gkl_GgvP0m84IRSoR_1Yi8hD17E=.bc6ed458-7081-4c3f-9348-f59358fa05a4@github.com>
 <13CORNysYmupJ3F2_7ekNqob8pz_xNmTg8gyKIt5vgs=.572e9f52-62ea-44cd-bac4-ab99a09a7510@github.com>
Message-ID: <SBr7MJkJyoDmuaSRwd8yTvRONl8sWxZyoZsc2Q__9Jk=.5cd84a9b-8510-4cff-8fc6-c99ccbe7c5f6@github.com>

On Thu, 23 May 2024 19:54:39 GMT, Scott Gibbons <sgibbons at openjdk.org> wrote:

>> Re-write the IndexOf code without the use of the pcmpestri instruction, only using AVX2 instructions.  This change accelerates String.IndexOf on average 1.3x for AVX2.  The benchmark numbers:
>> 
>> 
>> Benchmark	                                               Score		Latest		
>> StringIndexOf.advancedWithMediumSub   343.573		317.934		0.925375393x
>> StringIndexOf.advancedWithShortSub1	  1039.081		1053.96		1.014319384x
>> StringIndexOf.advancedWithShortSub2	      55.828		110.541		1.980027943x
>> StringIndexOf.constantPattern	                9.361		11.906		1.271872663x
>> StringIndexOf.searchCharLongSuccess	        4.216		4.218		1.000474383x
>> StringIndexOf.searchCharMediumSuccess	3.133		3.216		1.02649218x
>> StringIndexOf.searchCharShortSuccess	3.76		        3.761		1.000265957x
>> StringIndexOf.success	                                9.186		9.713		1.057369911x
>> StringIndexOf.successBig	                      14.341		46.343		3.231504079x
>> StringIndexOfChar.latin1_AVX2_String	  6220.918		12154.52		1.953814533x
>> StringIndexOfChar.latin1_AVX2_char	  5503.556		5540.044		1.006629895x
>> StringIndexOfChar.latin1_SSE4_String	  6978.854		6818.689		0.977049957x
>> StringIndexOfChar.latin1_SSE4_char	  5657.499		5474.624		0.967675646x
>> StringIndexOfChar.latin1_Short_String	  7132.541		6863.359		0.962260014x
>> StringIndexOfChar.latin1_Short_char	16013.389	      16162.437		1.009307711x
>> StringIndexOfChar.latin1_mixed_String	  7386.123	      14771.622		1.999915517x
>> StringIndexOfChar.latin1_mixed_char	  9901.671		9782.245		0.987938803
>
> Scott Gibbons has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Addressing review comments

Few suggestions

src/hotspot/cpu/x86/stubGenerator_x86_64.cpp line 4250:

> 4248:   generate_chacha_stubs();
> 4249: 
> 4250:   if ((UseAVX == 2) && EnableX86ECoreOpts && VM_Version::supports_avx2()) {

`#ifdef COMPILER2` around this code to exclude JVMCI only case.

src/hotspot/cpu/x86/stubGenerator_x86_64.hpp line 582:

> 580: 
> 581: #ifdef COMPILER2
> 582:   void generate_string_indexof_stubs(address *fnptrs, StrIntrinsicNode::ArgEncoding ae);

Is it possible to make `generate_string_indexof_stubs()` as local static method in `stubGenerator_x86_64_string.cpp` and pass `StubGenerator*` as argument?
Then you don't to include "opto/intrinsicnode.hpp" here.

src/hotspot/cpu/x86/stubGenerator_x86_64_string.cpp line 2:

> 1: /*
> 2:  * Copyright (c) 2023, Intel Corporation. All rights reserved.

2024 year

src/hotspot/cpu/x86/stubGenerator_x86_64_string.cpp line 27:

> 25: 
> 26: #include "precompiled.hpp"
> 27: #ifdef COMPILER2

You can exclude this file completely from compilation without this `#ifdef` if you prefix the name with `c2_`.
There is code in make files to exclude such files: [JvmFeatures.gmk#L38](https://github.com/openjdk/jdk/blob/master/make/hotspot/lib/JvmFeatures.gmk#L38)

-------------

PR Review: https://git.openjdk.org/jdk/pull/16753#pullrequestreview-2075150606
PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1612352891
PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1612383969
PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1612365050
PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1612375730

From kvn at openjdk.org  Thu May 23 22:11:13 2024
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Thu, 23 May 2024 22:11:13 GMT
Subject: RFR: 8320448: Accelerate IndexOf using AVX2 [v34]
In-Reply-To: <SBr7MJkJyoDmuaSRwd8yTvRONl8sWxZyoZsc2Q__9Jk=.5cd84a9b-8510-4cff-8fc6-c99ccbe7c5f6@github.com>
References: <uWi4QxH31hL93771gkl_GgvP0m84IRSoR_1Yi8hD17E=.bc6ed458-7081-4c3f-9348-f59358fa05a4@github.com>
 <13CORNysYmupJ3F2_7ekNqob8pz_xNmTg8gyKIt5vgs=.572e9f52-62ea-44cd-bac4-ab99a09a7510@github.com>
 <SBr7MJkJyoDmuaSRwd8yTvRONl8sWxZyoZsc2Q__9Jk=.5cd84a9b-8510-4cff-8fc6-c99ccbe7c5f6@github.com>
Message-ID: <XoxORrKYNUo8mVR-vdVunOIwL5n6MO9f_hgyve4gkCk=.2b71607c-9e01-4326-bd56-f29eed851b56@github.com>

On Thu, 23 May 2024 21:50:15 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> Scott Gibbons has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Addressing review comments
>
> src/hotspot/cpu/x86/stubGenerator_x86_64.cpp line 4250:
> 
>> 4248:   generate_chacha_stubs();
>> 4249: 
>> 4250:   if ((UseAVX == 2) && EnableX86ECoreOpts && VM_Version::supports_avx2()) {
> 
> `#ifdef COMPILER2` around this code to exclude JVMCI only case.

You don't need to check `VM_Version::supports_avx2()` because we reset `UseAVX` if avx2 is not supported.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1612361847

From vromero at openjdk.org  Thu May 23 22:50:29 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 23 May 2024 22:50:29 GMT
Subject: RFR: 8320575: generic type information lost on mandated parameters
 of record's compact constructors [v23]
In-Reply-To: <20VdLsPE7Md_hxgniEhF0WPmdo_WXqbBswWdn2Az9N4=.0821e94c-4745-41e9-95a4-147f98657718@github.com>
References: <20VdLsPE7Md_hxgniEhF0WPmdo_WXqbBswWdn2Az9N4=.0821e94c-4745-41e9-95a4-147f98657718@github.com>
Message-ID: <J1gsz8vmZep-_ltsX0xUDlsG0tu4yhiPMYzS_D-rPYY=.558c28ac-fb26-4721-a257-ad8cc9d1f42d@github.com>

> Reflection is not retrieving generic type information for mandated parameters. This is a known issue which has been explicitly stated in the API of some reflection methods. Fix for [JDK-8292275](https://bugs.openjdk.org/browse/JDK-8292275) made the parameters of compact constructors of record classes `mandated` as specified in the spec. But this implied that users that previous to this change could retrieve the generic type of parameters of compact constructors now they can't anymore. The proposed fix is to try to retrieve generic type information for mandated parameters if available plus changing the spec of the related reflection methods.
> 
> TIA

Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:

  more review comments

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17070/files
  - new: https://git.openjdk.org/jdk/pull/17070/files/9ff2ba2e..db1d400e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17070&range=22
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17070&range=21-22

  Stats: 6 lines in 1 file changed: 0 ins; 0 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/17070.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17070/head:pull/17070

PR: https://git.openjdk.org/jdk/pull/17070

From sgibbons at openjdk.org  Thu May 23 23:00:10 2024
From: sgibbons at openjdk.org (Scott Gibbons)
Date: Thu, 23 May 2024 23:00:10 GMT
Subject: RFR: 8320448: Accelerate IndexOf using AVX2 [v34]
In-Reply-To: <XoxORrKYNUo8mVR-vdVunOIwL5n6MO9f_hgyve4gkCk=.2b71607c-9e01-4326-bd56-f29eed851b56@github.com>
References: <uWi4QxH31hL93771gkl_GgvP0m84IRSoR_1Yi8hD17E=.bc6ed458-7081-4c3f-9348-f59358fa05a4@github.com>
 <13CORNysYmupJ3F2_7ekNqob8pz_xNmTg8gyKIt5vgs=.572e9f52-62ea-44cd-bac4-ab99a09a7510@github.com>
 <SBr7MJkJyoDmuaSRwd8yTvRONl8sWxZyoZsc2Q__9Jk=.5cd84a9b-8510-4cff-8fc6-c99ccbe7c5f6@github.com>
 <XoxORrKYNUo8mVR-vdVunOIwL5n6MO9f_hgyve4gkCk=.2b71607c-9e01-4326-bd56-f29eed851b56@github.com>
Message-ID: <5L1PFeLmHP6Lfg1bKx_tRU-ESTFfpqUbP9vHVbiaqPo=.c3fa3b1b-5433-4a68-b639-ef82b4a388d1@github.com>

On Thu, 23 May 2024 21:56:39 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> src/hotspot/cpu/x86/stubGenerator_x86_64.cpp line 4250:
>> 
>>> 4248:   generate_chacha_stubs();
>>> 4249: 
>>> 4250:   if ((UseAVX == 2) && EnableX86ECoreOpts && VM_Version::supports_avx2()) {
>> 
>> `#ifdef COMPILER2` around this code to exclude JVMCI only case.
>
> You don't need to check `VM_Version::supports_avx2()` because we reset `UseAVX` if avx2 is not supported.

Done.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1612396114

From sgibbons at openjdk.org  Thu May 23 23:00:12 2024
From: sgibbons at openjdk.org (Scott Gibbons)
Date: Thu, 23 May 2024 23:00:12 GMT
Subject: RFR: 8320448: Accelerate IndexOf using AVX2 [v34]
In-Reply-To: <SBr7MJkJyoDmuaSRwd8yTvRONl8sWxZyoZsc2Q__9Jk=.5cd84a9b-8510-4cff-8fc6-c99ccbe7c5f6@github.com>
References: <uWi4QxH31hL93771gkl_GgvP0m84IRSoR_1Yi8hD17E=.bc6ed458-7081-4c3f-9348-f59358fa05a4@github.com>
 <13CORNysYmupJ3F2_7ekNqob8pz_xNmTg8gyKIt5vgs=.572e9f52-62ea-44cd-bac4-ab99a09a7510@github.com>
 <SBr7MJkJyoDmuaSRwd8yTvRONl8sWxZyoZsc2Q__9Jk=.5cd84a9b-8510-4cff-8fc6-c99ccbe7c5f6@github.com>
Message-ID: <SoJlMXzMLJme2VNXtIEKvPBFbPXLsqFgCmfwra-3vHA=.7713e5a3-14a9-4b81-a56e-3b6d35ba7a70@github.com>

On Thu, 23 May 2024 22:06:38 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> Scott Gibbons has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Addressing review comments
>
> src/hotspot/cpu/x86/stubGenerator_x86_64.hpp line 582:
> 
>> 580: 
>> 581: #ifdef COMPILER2
>> 582:   void generate_string_indexof_stubs(address *fnptrs, StrIntrinsicNode::ArgEncoding ae);
> 
> Is it possible to make `generate_string_indexof_stubs()` as local static method in `stubGenerator_x86_64_string.cpp` and pass `StubGenerator*` as argument?
> Then you don't to include "opto/intrinsicnode.hpp" here.

Done.

> src/hotspot/cpu/x86/stubGenerator_x86_64_string.cpp line 2:
> 
>> 1: /*
>> 2:  * Copyright (c) 2023, Intel Corporation. All rights reserved.
> 
> 2024 year

Fixed.

> src/hotspot/cpu/x86/stubGenerator_x86_64_string.cpp line 27:
> 
>> 25: 
>> 26: #include "precompiled.hpp"
>> 27: #ifdef COMPILER2
> 
> You can exclude this file completely from compilation without this `#ifdef` if you prefix the name with `c2_`.
> There is code in make files to exclude such files: [JvmFeatures.gmk#L38](https://github.com/openjdk/jdk/blob/master/make/hotspot/lib/JvmFeatures.gmk#L38)

I will change the name and remove the #ifdef.  Thanks for this.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1612401461
PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1612399243
PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1612400071

From vromero at openjdk.org  Thu May 23 23:08:17 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 23 May 2024 23:08:17 GMT
Subject: RFR: 8320575: generic type information lost on mandated parameters
 of record's compact constructors [v24]
In-Reply-To: <20VdLsPE7Md_hxgniEhF0WPmdo_WXqbBswWdn2Az9N4=.0821e94c-4745-41e9-95a4-147f98657718@github.com>
References: <20VdLsPE7Md_hxgniEhF0WPmdo_WXqbBswWdn2Az9N4=.0821e94c-4745-41e9-95a4-147f98657718@github.com>
Message-ID: <SLZopFe4uON7OHTy4OG1YK4MxWUQwelfj0j904OZxHw=.4343f3f1-e090-45e5-92d4-474632cca63a@github.com>

> Reflection is not retrieving generic type information for mandated parameters. This is a known issue which has been explicitly stated in the API of some reflection methods. Fix for [JDK-8292275](https://bugs.openjdk.org/browse/JDK-8292275) made the parameters of compact constructors of record classes `mandated` as specified in the spec. But this implied that users that previous to this change could retrieve the generic type of parameters of compact constructors now they can't anymore. The proposed fix is to try to retrieve generic type information for mandated parameters if available plus changing the spec of the related reflection methods.
> 
> TIA

Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:

  fixing lines length

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17070/files
  - new: https://git.openjdk.org/jdk/pull/17070/files/db1d400e..d2748f27

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17070&range=23
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17070&range=22-23

  Stats: 25 lines in 1 file changed: 11 ins; 0 del; 14 mod
  Patch: https://git.openjdk.org/jdk/pull/17070.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17070/head:pull/17070

PR: https://git.openjdk.org/jdk/pull/17070

From kvn at openjdk.org  Thu May 23 23:11:08 2024
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Thu, 23 May 2024 23:11:08 GMT
Subject: RFR: 8327964: Simplify BigInteger.implMultiplyToLen intrinsic [v6]
In-Reply-To: <GkTIvOKs4GDKUOPjaw893H4fAoeBDuzQn4kKnQqG2dA=.7762f50b-40b1-4763-940b-7e0c8a66d466@github.com>
References: <Z5U-3OSq9_rd0t6DHNRhjF3LHtc9b6orz-mcQ4Uqzl8=.c4f0a0b8-9e10-4505-82f7-7d3a82929d22@github.com>
 <GkTIvOKs4GDKUOPjaw893H4fAoeBDuzQn4kKnQqG2dA=.7762f50b-40b1-4763-940b-7e0c8a66d466@github.com>
Message-ID: <9l85eJF5sWNRxwdjtcyKdGmDRm9Hp9ZRKhSJejy5-FM=.29881024-aa33-42a5-b85b-06d359acfc66@github.com>

On Wed, 22 May 2024 14:47:43 GMT, Yudi Zheng <yzheng at openjdk.org> wrote:

>> Moving array construction within BigInteger.implMultiplyToLen intrinsic candidate to its caller simplifies the intrinsic implementation in JIT compiler.
>
> Yudi Zheng has updated the pull request incrementally with one additional commit since the last revision:
> 
>   address comments.

This is good. Please, merge latest mainline and rerun mach5 testing.

-------------

Marked as reviewed by kvn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18226#pullrequestreview-2075281290

From sgibbons at openjdk.org  Thu May 23 23:12:42 2024
From: sgibbons at openjdk.org (Scott Gibbons)
Date: Thu, 23 May 2024 23:12:42 GMT
Subject: RFR: 8320448: Accelerate IndexOf using AVX2 [v35]
In-Reply-To: <uWi4QxH31hL93771gkl_GgvP0m84IRSoR_1Yi8hD17E=.bc6ed458-7081-4c3f-9348-f59358fa05a4@github.com>
References: <uWi4QxH31hL93771gkl_GgvP0m84IRSoR_1Yi8hD17E=.bc6ed458-7081-4c3f-9348-f59358fa05a4@github.com>
Message-ID: <-vyOZzeMslZqgJpTsQnnOWi4abWiM8fNeWSVx5LEHm8=.d37011ee-102c-4874-aa26-d113949d25ea@github.com>

> Re-write the IndexOf code without the use of the pcmpestri instruction, only using AVX2 instructions.  This change accelerates String.IndexOf on average 1.3x for AVX2.  The benchmark numbers:
> 
> 
> Benchmark	                                               Score		Latest		
> StringIndexOf.advancedWithMediumSub   343.573		317.934		0.925375393x
> StringIndexOf.advancedWithShortSub1	  1039.081		1053.96		1.014319384x
> StringIndexOf.advancedWithShortSub2	      55.828		110.541		1.980027943x
> StringIndexOf.constantPattern	                9.361		11.906		1.271872663x
> StringIndexOf.searchCharLongSuccess	        4.216		4.218		1.000474383x
> StringIndexOf.searchCharMediumSuccess	3.133		3.216		1.02649218x
> StringIndexOf.searchCharShortSuccess	3.76		        3.761		1.000265957x
> StringIndexOf.success	                                9.186		9.713		1.057369911x
> StringIndexOf.successBig	                      14.341		46.343		3.231504079x
> StringIndexOfChar.latin1_AVX2_String	  6220.918		12154.52		1.953814533x
> StringIndexOfChar.latin1_AVX2_char	  5503.556		5540.044		1.006629895x
> StringIndexOfChar.latin1_SSE4_String	  6978.854		6818.689		0.977049957x
> StringIndexOfChar.latin1_SSE4_char	  5657.499		5474.624		0.967675646x
> StringIndexOfChar.latin1_Short_String	  7132.541		6863.359		0.962260014x
> StringIndexOfChar.latin1_Short_char	16013.389	      16162.437		1.009307711x
> StringIndexOfChar.latin1_mixed_String	  7386.123	      14771.622		1.999915517x
> StringIndexOfChar.latin1_mixed_char	  9901.671		9782.245		0.987938803

Scott Gibbons has updated the pull request incrementally with one additional commit since the last revision:

  Review comments - move stubGen*_string.cpp to c2_stubGen*_string.cpp

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/16753/files
  - new: https://git.openjdk.org/jdk/pull/16753/files/2283f2bf..c034d3f9

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16753&range=34
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16753&range=33-34

  Stats: 73 lines in 3 files changed: 6 ins; 59 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/16753.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16753/head:pull/16753

PR: https://git.openjdk.org/jdk/pull/16753

From liach at openjdk.org  Thu May 23 23:27:01 2024
From: liach at openjdk.org (Chen Liang)
Date: Thu, 23 May 2024 23:27:01 GMT
Subject: RFR: 8242888: Convert dynamic proxy to hidden classes
In-Reply-To: <QO0dIumbbHUFWz43pCWbmsqdH5zG8NaVUB9FwNFlbTw=.8fe20db2-9cfc-46e9-9f98-0979259ac882@github.com>
References: <QO0dIumbbHUFWz43pCWbmsqdH5zG8NaVUB9FwNFlbTw=.8fe20db2-9cfc-46e9-9f98-0979259ac882@github.com>
Message-ID: <A6RYDzBBFGsmRdFEmV0P7r9PL55ri7NlgIQ37MsWJH0=.2f8d69ab-cc90-4582-a7ca-a9f5a459acb5@github.com>

On Thu, 23 May 2024 03:28:30 GMT, Chen Liang <liach at openjdk.org> wrote:

> Please review this change that convert dynamic proxies implementations to hidden classes, intended to target JDK 24.
> 
> Summary:
> 1. Adds new implementation while preserving the old implementation behind `-Djdk.reflect.useLegacyProxyImpl=true` in case there are compatibility issues.
> 2. ClassLoader.defineClass0 takes a ClassLoader instance but discards it in native code; I updated native code to reuse that ClassLoader for Proxy support.
> 3. ProxyGenerator changes mainly involve using Class data to pass Method list (accessed in a single condy) and removal of obsolete setup code generation.
> 
> Testing: tier1 and tier2 have no related failures.
> 
> Comment: Since #8278, Proxy has been converted to ClassFile API, and infrastructure has changed; now, the migration to hidden classes is much cleaner and has less impact, such as preserving ProtectionDomain and dynamic module without "anchor classes", and avoiding java.lang.invoke package.

Hmm, actually, looking at the specs of the method again, does it imply that Proxy classes are never unloaded once defined in a ClassLoader, as seen in `Proxy::getProxyClass`:

> If a proxy class for the same permutation of interfaces has already been defined by the class loader, then the existing proxy class will be returned

If that's the case, Remi's suggestion on passing classdata to a non-hidden class might be better, and it seems to accomplish that in hotspot isn't too hard too.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19356#issuecomment-2128186405

From kvn at openjdk.org  Thu May 23 23:42:09 2024
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Thu, 23 May 2024 23:42:09 GMT
Subject: RFR: 8320448: Accelerate IndexOf using AVX2 [v35]
In-Reply-To: <-vyOZzeMslZqgJpTsQnnOWi4abWiM8fNeWSVx5LEHm8=.d37011ee-102c-4874-aa26-d113949d25ea@github.com>
References: <uWi4QxH31hL93771gkl_GgvP0m84IRSoR_1Yi8hD17E=.bc6ed458-7081-4c3f-9348-f59358fa05a4@github.com>
 <-vyOZzeMslZqgJpTsQnnOWi4abWiM8fNeWSVx5LEHm8=.d37011ee-102c-4874-aa26-d113949d25ea@github.com>
Message-ID: <vUO-CV6yzk2IGvck5ReC6Kxbuyvt1jRNwYjRfVRWueM=.6e742085-67da-469e-ab4d-2aadef1d61ce@github.com>

On Thu, 23 May 2024 23:12:42 GMT, Scott Gibbons <sgibbons at openjdk.org> wrote:

>> Re-write the IndexOf code without the use of the pcmpestri instruction, only using AVX2 instructions.  This change accelerates String.IndexOf on average 1.3x for AVX2.  The benchmark numbers:
>> 
>> 
>> Benchmark	                                               Score		Latest		
>> StringIndexOf.advancedWithMediumSub   343.573		317.934		0.925375393x
>> StringIndexOf.advancedWithShortSub1	  1039.081		1053.96		1.014319384x
>> StringIndexOf.advancedWithShortSub2	      55.828		110.541		1.980027943x
>> StringIndexOf.constantPattern	                9.361		11.906		1.271872663x
>> StringIndexOf.searchCharLongSuccess	        4.216		4.218		1.000474383x
>> StringIndexOf.searchCharMediumSuccess	3.133		3.216		1.02649218x
>> StringIndexOf.searchCharShortSuccess	3.76		        3.761		1.000265957x
>> StringIndexOf.success	                                9.186		9.713		1.057369911x
>> StringIndexOf.successBig	                      14.341		46.343		3.231504079x
>> StringIndexOfChar.latin1_AVX2_String	  6220.918		12154.52		1.953814533x
>> StringIndexOfChar.latin1_AVX2_char	  5503.556		5540.044		1.006629895x
>> StringIndexOfChar.latin1_SSE4_String	  6978.854		6818.689		0.977049957x
>> StringIndexOfChar.latin1_SSE4_char	  5657.499		5474.624		0.967675646x
>> StringIndexOfChar.latin1_Short_String	  7132.541		6863.359		0.962260014x
>> StringIndexOfChar.latin1_Short_char	16013.389	      16162.437		1.009307711x
>> StringIndexOfChar.latin1_mixed_String	  7386.123	      14771.622		1.999915517x
>> StringIndexOfChar.latin1_mixed_char	  9901.671		9782.245		0.987938803
>
> Scott Gibbons has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comments - move stubGen*_string.cpp to c2_stubGen*_string.cpp

I submitted our testing for latest v34 version of changes.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/16753#issuecomment-2128207810

From kvn at openjdk.org  Fri May 24 00:50:10 2024
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Fri, 24 May 2024 00:50:10 GMT
Subject: RFR: 8320448: Accelerate IndexOf using AVX2 [v35]
In-Reply-To: <-vyOZzeMslZqgJpTsQnnOWi4abWiM8fNeWSVx5LEHm8=.d37011ee-102c-4874-aa26-d113949d25ea@github.com>
References: <uWi4QxH31hL93771gkl_GgvP0m84IRSoR_1Yi8hD17E=.bc6ed458-7081-4c3f-9348-f59358fa05a4@github.com>
 <-vyOZzeMslZqgJpTsQnnOWi4abWiM8fNeWSVx5LEHm8=.d37011ee-102c-4874-aa26-d113949d25ea@github.com>
Message-ID: <rWYc3j0it-G8yJrMpEPeGvc3Q0caqx2MA-EzdmbdLN0=.d11c9960-ed18-4623-ad27-ba71f6db5507@github.com>

On Thu, 23 May 2024 23:12:42 GMT, Scott Gibbons <sgibbons at openjdk.org> wrote:

>> Re-write the IndexOf code without the use of the pcmpestri instruction, only using AVX2 instructions.  This change accelerates String.IndexOf on average 1.3x for AVX2.  The benchmark numbers:
>> 
>> 
>> Benchmark	                                               Score		Latest		
>> StringIndexOf.advancedWithMediumSub   343.573		317.934		0.925375393x
>> StringIndexOf.advancedWithShortSub1	  1039.081		1053.96		1.014319384x
>> StringIndexOf.advancedWithShortSub2	      55.828		110.541		1.980027943x
>> StringIndexOf.constantPattern	                9.361		11.906		1.271872663x
>> StringIndexOf.searchCharLongSuccess	        4.216		4.218		1.000474383x
>> StringIndexOf.searchCharMediumSuccess	3.133		3.216		1.02649218x
>> StringIndexOf.searchCharShortSuccess	3.76		        3.761		1.000265957x
>> StringIndexOf.success	                                9.186		9.713		1.057369911x
>> StringIndexOf.successBig	                      14.341		46.343		3.231504079x
>> StringIndexOfChar.latin1_AVX2_String	  6220.918		12154.52		1.953814533x
>> StringIndexOfChar.latin1_AVX2_char	  5503.556		5540.044		1.006629895x
>> StringIndexOfChar.latin1_SSE4_String	  6978.854		6818.689		0.977049957x
>> StringIndexOfChar.latin1_SSE4_char	  5657.499		5474.624		0.967675646x
>> StringIndexOfChar.latin1_Short_String	  7132.541		6863.359		0.962260014x
>> StringIndexOfChar.latin1_Short_char	16013.389	      16162.437		1.009307711x
>> StringIndexOfChar.latin1_mixed_String	  7386.123	      14771.622		1.999915517x
>> StringIndexOfChar.latin1_mixed_char	  9901.671		9782.245		0.987938803
>
> Scott Gibbons has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comments - move stubGen*_string.cpp to c2_stubGen*_string.cpp

test/jdk/java/lang/StringBuffer/IndexOf.java line 2:

> 1: /*
> 2:  * Copyright (c) 2000, 2024 Oracle and/or its affiliates. All rights reserved.

This copyright header validation failure. Missing comma `,` after 2024.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1612519675

From almatvee at openjdk.org  Fri May 24 01:13:25 2024
From: almatvee at openjdk.org (Alexander Matveev)
Date: Fri, 24 May 2024 01:13:25 GMT
Subject: RFR: 8332110: [macos] jpackage tries to sign added files without the
 --mac-sign option
Message-ID: <eiboU_LgwkTte_7rkPJAdDm1x_-Pzm8rdwUiY_4MAYI=.b982e161-fe24-44ab-9db5-2f1d80eb0d99@github.com>

This issue is reproducible with and without `--mac-sign`. jpackage will "_ad-hoc_" sign application bundle when `--mac-sign` is not specified by using pseudo-identity "_-_". This is why jpackage tries to sign added files and this is expected behavior by jpackage. "codesign" fails since added content made application bundle structure invalid. There is nothing we can do on jpackage side to sign such invalid bundles. As proposed solution we will output possible reason for "codesign" failure if it fails and `--app-content` was specified and possible solution. Proposed message: "One of the possible reason for "codesign" failure is additional content provided via "--app-content", which made application bundle structure invalid. Make sure to provide additional content in a way it will not break application bundle structure, otherwise add additional content as post-processing step."

Example:
Lets assume we have "ReadMe" folder with "ReadMe.txt" file in it.
1) jpackage --type app-image -n Test --app-content ReadMe/ReadMe.txt ...
"codesign" will fail with "In subcomponent: Test.app/Contents/ReadMe.txt". This is expected and "ReadMe.txt" placed in "Test.app/Contents" which is also expected.
2) jpackage --type app-image -n Test --app-content ReadMe ...
Works and "ReadMe.txt" will be placed under "Test.app/Contents/ReadMe".

Sample output before fix:

Error: "codesign" failed with following output:
Test.app: replacing existing signature
Test.app: code object is not signed at all
In subcomponent: Test.app/Contents/ReadMe.txt


Sample output after fix:

One of the possible reason for "codesign" failure is additional content provided via "--app-content", which made application bundle structure invalid. Make sure to provide additional content in a way it will not break application bundle structure, otherwise add additional content as post-processing step.
Error: "codesign" failed with following output:
Test.app: replacing existing signature
Test.app: code object is not signed at all
In subcomponent: Test.app/Contents/ReadMe.txt

-------------

Commit messages:
 - 8332110: jpackage tries to sign added files without the --mac-sign option

Changes: https://git.openjdk.org/jdk/pull/19377/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19377&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8332110
  Stats: 38 lines in 6 files changed: 24 ins; 0 del; 14 mod
  Patch: https://git.openjdk.org/jdk/pull/19377.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19377/head:pull/19377

PR: https://git.openjdk.org/jdk/pull/19377

From joehw at openjdk.org  Fri May 24 05:26:40 2024
From: joehw at openjdk.org (Joe Wang)
Date: Fri, 24 May 2024 05:26:40 GMT
Subject: RFR: 8330542: Template for Creating Strict JAXP Configuration File
 [v13]
In-Reply-To: <v1bAYKgH9zfooXpvnBw4Vu2TIqHuKqqtSmgB0hiNp-Q=.31661a99-ecfc-4a05-8045-67b5f680db60@github.com>
References: <v1bAYKgH9zfooXpvnBw4Vu2TIqHuKqqtSmgB0hiNp-Q=.31661a99-ecfc-4a05-8045-67b5f680db60@github.com>
Message-ID: <OSDfl2mY_eU6Otx-aSlb4ehXy-9kHGxsW0EStuPle70=.dcf73a63-a9b1-4832-b433-f2a721f082c0@github.com>

> Add two sample configuration files:
> 
>   jaxp-strict.properties: used to set strict configuration, stricter than jaxp.properties in previous versions such as JDK 22
> 
>>   jaxp-compat.properties: used to regain compatibility from any more restricted configuration than previous versions such as JDK 22
> 
> Updated on 5/16/2024
> 
> Design change:
> The design is changed to include in the JDK two configuration files that are the default jaxp.properties and jaxp-strict.properties, instead of three, dropping jaxp-compat.properties.
> 
> Updated on 5/18/2024
> 
> Withdraw changes to jaxp.properties. The original idea was to match jaxp-strict.properties with regard to the properties. However, that change impact the configuration process, resulting in tests that verify the process to fail.

Joe Wang has updated the pull request incrementally with one additional commit since the last revision:

  add a template instead of a property file; remove implNote; update test and make script accordingly.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/18831/files
  - new: https://git.openjdk.org/jdk/pull/18831/files/dd7f6239..0de8ad69

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18831&range=12
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18831&range=11-12

  Stats: 299 lines in 6 files changed: 133 ins; 155 del; 11 mod
  Patch: https://git.openjdk.org/jdk/pull/18831.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18831/head:pull/18831

PR: https://git.openjdk.org/jdk/pull/18831

From joehw at openjdk.org  Fri May 24 05:40:04 2024
From: joehw at openjdk.org (Joe Wang)
Date: Fri, 24 May 2024 05:40:04 GMT
Subject: RFR: 8330542: Template for Creating Strict JAXP Configuration File
 [v13]
In-Reply-To: <OSDfl2mY_eU6Otx-aSlb4ehXy-9kHGxsW0EStuPle70=.dcf73a63-a9b1-4832-b433-f2a721f082c0@github.com>
References: <v1bAYKgH9zfooXpvnBw4Vu2TIqHuKqqtSmgB0hiNp-Q=.31661a99-ecfc-4a05-8045-67b5f680db60@github.com>
 <OSDfl2mY_eU6Otx-aSlb4ehXy-9kHGxsW0EStuPle70=.dcf73a63-a9b1-4832-b433-f2a721f082c0@github.com>
Message-ID: <5Zo9U4clIGAtBQms45XLX7T2lBJzIerrJMpLQNSgqmo=.2a7bae6a-76fe-4626-ae0a-8a01fe55250e@github.com>

On Fri, 24 May 2024 05:26:40 GMT, Joe Wang <joehw at openjdk.org> wrote:

>> Add two sample configuration files:
>> 
>>   jaxp-strict.properties: used to set strict configuration, stricter than jaxp.properties in previous versions such as JDK 22
>> 
>>>   jaxp-compat.properties: used to regain compatibility from any more restricted configuration than previous versions such as JDK 22
>> 
>> Updated on 5/16/2024
>> 
>> Design change:
>> The design is changed to include in the JDK two configuration files that are the default jaxp.properties and jaxp-strict.properties, instead of three, dropping jaxp-compat.properties.
>> 
>> Updated on 5/18/2024
>> 
>> Withdraw changes to jaxp.properties. The original idea was to match jaxp-strict.properties with regard to the properties. However, that change impact the configuration process, resulting in tests that verify the process to fail.
>> 
>> Updated on 5/23/2024
>> 
>> Provide a template `jaxp-strict.template` instead of a properties file. This template can be used to create custom configuration files.
>
> Joe Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add a template instead of a property file; remove implNote; update test and make script accordingly.

Update: the plan has changed from providing a configuration file to a template. Module description, test and make file are updated accordingly. Thanks Erik for the new make file!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18831#issuecomment-2128568806

From joehw at openjdk.org  Fri May 24 05:40:05 2024
From: joehw at openjdk.org (Joe Wang)
Date: Fri, 24 May 2024 05:40:05 GMT
Subject: RFR: 8330542: Template for Creating Strict JAXP Configuration File
 [v12]
In-Reply-To: <8A-Z8Q-bmxb3P2_x64siGd3gN07jzf-nHxXiiV64G0A=.65e5be8d-1975-4840-b876-4038320dcf18@github.com>
References: <v1bAYKgH9zfooXpvnBw4Vu2TIqHuKqqtSmgB0hiNp-Q=.31661a99-ecfc-4a05-8045-67b5f680db60@github.com>
 <Xhrtr31Mwi_NwgwShsUonMQBkOITdwllZAmedF_k1Og=.26242046-84a7-4da7-ae88-901b794df2dc@github.com>
 <8A-Z8Q-bmxb3P2_x64siGd3gN07jzf-nHxXiiV64G0A=.65e5be8d-1975-4840-b876-4038320dcf18@github.com>
Message-ID: <cXKBJWVCnppQ3spvSPYKNfoXVpfX50-cbDH3OZqvElA=.41abc212-e3ae-4bce-a086-3bf6333d4e58@github.com>

On Wed, 22 May 2024 08:52:42 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Joe Wang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   add a note to module-info
>
> make/modules/java.xml/Copy.gmk line 35:
> 
>> 33: $(eval $(call SetupCopyFiles, COPY_XML_MODULE_CONF, \
>> 34:     DEST := $(CONF_DST_DIR), \
>> 35:     FILES := $(wildcard $(TOPDIR)/src/java.xml/share/conf/jaxp*.properties*), \
> 
> I don't think you need, nor should have, the asterisk after the extension. You are only copying `.properties` files.
> 
> Suggestion:
> 
>     FILES := $(wildcard $(TOPDIR)/src/java.xml/share/conf/jaxp*.properties), \

Thanks Magnus!

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18831#discussion_r1612802098

From djelinski at openjdk.org  Fri May 24 06:34:10 2024
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Fri, 24 May 2024 06:34:10 GMT
Subject: RFR: 8320448: Accelerate IndexOf using AVX2 [v33]
In-Reply-To: <nxpwP6Q_co_mHw7hIyjBjPSjuR6HUc3-ioT80k0tpqE=.fca7f3a5-a511-481c-b630-abeb4402268c@github.com>
References: <uWi4QxH31hL93771gkl_GgvP0m84IRSoR_1Yi8hD17E=.bc6ed458-7081-4c3f-9348-f59358fa05a4@github.com>
 <kE-TMUMyr6ADsj3wtDB9RlLnXaJFbFzmd7cikzCEuSg=.490d5dd5-eaa8-4137-8e00-7d5de1efb598@github.com>
 <GkGAR2YTtCDe_xFo2a7MxxJyoo-dsgghT9TvqfntN3c=.e40c4157-c48d-4454-b08e-17d6eb9b85a1@github.com>
 <nxpwP6Q_co_mHw7hIyjBjPSjuR6HUc3-ioT80k0tpqE=.fca7f3a5-a511-481c-b630-abeb4402268c@github.com>
Message-ID: <BfYSarY-tQu34szlCk9qBFTIPR1TlmM5quTXqmoZoGI=.de6da9a2-3ef7-4e1c-8de4-dea5bf134d0f@github.com>

On Thu, 23 May 2024 19:26:10 GMT, Scott Gibbons <sgibbons at openjdk.org> wrote:

>> src/hotspot/cpu/x86/stubGenerator_x86_64_string.cpp line 268:
>> 
>>> 266:   __ cmpq(needle_len_p, 0);
>>> 267:   __ jg_b(L_nextCheck);
>>> 268:   __ xorq(rax, rax);
>> 
>> out of curiosity, is there any advantage to using `xorq` instead of `xorl` here?
>> 
>> https://stackoverflow.com/a/33668295/7707617 suggests that `xorl` might be better, but it's a bit dated now.
>
> Thanks for finding this.  It was ignorance on my part as I thought the xorq would have logic to not emit the REX prefix if not necessary, but it doesn't.  Fixed.

Right, it seems to surprise people. There's a lot of preexisting uses of xorq / xorptr to zero a register. I think it would make sense to implement this logic in xorq. I can do this if others agree.

>> src/hotspot/cpu/x86/stubGenerator_x86_64_string.cpp line 449:
>> 
>>> 447:   __ cmpq(r13, NUMBER_OF_CASES - 1);
>>> 448:   __ ja(L_smallCaseDefault);
>>> 449:   __ mov64(r15, (int64_t)small_jump_table);
>> 
>> would it make sense to use `lea` here?
>
> It may, but I believe the movq is shorter (although maybe not to r15).  I'll do some experimentation.

the RIP-relative lea should have a shorter encoding. I think something like `lea(r15, ExternalAddress(small_jump_table))` should produce it (untested)

>> src/hotspot/cpu/x86/stubGenerator_x86_64_string.cpp line 803:
>> 
>>> 801:     __ movq(index, needle_len);
>>> 802:     __ andq(index, 0xf);  // nLen % 16
>>> 803:     __ movq(offset, 0x10);
>> 
>> `movl` or `movptr` would produce a shorter encoding
>
> I tried to be consistent with the whole {q,l} syntax throughout when referring to each symbolic register.  I feel that changing this would ripple through the code.  @sviswa7 what do you think?

Right, that makes sense. I wonder if there's any reason why the logic to select the best mov variant is in movptr, and not in movq. Usually the `ptr` functions just select the `l` or `q` overload depending on the target system, `movptr` is an exception here.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1612907959
PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1612908115
PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1612908219

From fyang at openjdk.org  Fri May 24 07:12:12 2024
From: fyang at openjdk.org (Fei Yang)
Date: Fri, 24 May 2024 07:12:12 GMT
Subject: RFR: 8327964: Simplify BigInteger.implMultiplyToLen intrinsic [v6]
In-Reply-To: <GkTIvOKs4GDKUOPjaw893H4fAoeBDuzQn4kKnQqG2dA=.7762f50b-40b1-4763-940b-7e0c8a66d466@github.com>
References: <Z5U-3OSq9_rd0t6DHNRhjF3LHtc9b6orz-mcQ4Uqzl8=.c4f0a0b8-9e10-4505-82f7-7d3a82929d22@github.com>
 <GkTIvOKs4GDKUOPjaw893H4fAoeBDuzQn4kKnQqG2dA=.7762f50b-40b1-4763-940b-7e0c8a66d466@github.com>
Message-ID: <jmHTaE8UUQCOAAL7RCaA9-deqHvdM3ThgGVO6KfYT4o=.6a6b1bac-39cd-4427-908a-998b321fdf28@github.com>

On Wed, 22 May 2024 14:47:43 GMT, Yudi Zheng <yzheng at openjdk.org> wrote:

>> Moving array construction within BigInteger.implMultiplyToLen intrinsic candidate to its caller simplifies the intrinsic implementation in JIT compiler.
>
> Yudi Zheng has updated the pull request incrementally with one additional commit since the last revision:
> 
>   address comments.

Hi, RISC-V part of change seems fine. "java/math/BigInteger" test result is clean on linux-riscv64 platform. Thanks for the ping.

-------------

Marked as reviewed by fyang (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18226#pullrequestreview-2076019194

From mbaesken at openjdk.org  Fri May 24 07:24:13 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 24 May 2024 07:24:13 GMT
Subject: RFR: 8332589: ubsan: unix/native/libjava/ProcessImpl_md.c:562:5:
 runtime error: null pointer passed as argument 2,
 which is declared to never be null [v3]
In-Reply-To: <AwlmAiTOhqSaoJ2Jh5YYrBpxakc0Pt9lYP9nvcBjXBo=.813efddf-3f87-4bbf-9cc5-cd769eabd2f7@github.com>
References: <AwlmAiTOhqSaoJ2Jh5YYrBpxakc0Pt9lYP9nvcBjXBo=.813efddf-3f87-4bbf-9cc5-cd769eabd2f7@github.com>
Message-ID: <1WfHx9Kgp1eOclYJ4qE5rCmqOIyn2GRARqDSN6PfDJw=.f9ed4c68-8eb8-4ad6-b132-39356d5445a6@github.com>

> When building with ubsan enabled (--enable-uban) on Linux x86_64 and doing jtreg tests afterwards I run into this error :
> 
> /jdk/src/java.base/unix/native/libjava/ProcessImpl_md.c:562:5: runtime error: null pointer passed as argument 2, which is declared to never be null
>     #0 0x7fd95bec78d8 in spawnChild /jdk/src/java.base/unix/native/libjava/ProcessImpl_md.c:562
>     #1 0x7fd95bec78d8 in startChild /jdk/src/java.base/unix/native/libjava/ProcessImpl_md.c:612
>     #2 0x7fd95bec78d8 in Java_java_lang_ProcessImpl_forkAndExec /jdk/src/java.base/unix/native/libjava/ProcessImpl_md.c:712
>     #3 0x7fd93797a06d (<unknown module>)
> 
> this is the memcpy call getting an unexpected null pointer :
>     memcpy(buf+offset, c->pdir, sp.dirlen); gets a second parameter null.
> Something similar was discussed and fixed here https://bugs.python.org/issue27570 for Python .
> 
> Similar issue in OpenJDK _ 
> https://bugs.openjdk.org/browse/JDK-8332473
> 8332473: ubsan: growableArray.hpp:290:10: runtime error: null pointer passed as argument 1, which is declared to never be null

Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:

  handle special case that memcpy src is NULL but a len larger than 0 was given

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19329/files
  - new: https://git.openjdk.org/jdk/pull/19329/files/b03ff0c5..aad00366

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19329&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19329&range=01-02

  Stats: 10 lines in 1 file changed: 7 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/19329.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19329/head:pull/19329

PR: https://git.openjdk.org/jdk/pull/19329

From mbaesken at openjdk.org  Fri May 24 07:24:14 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 24 May 2024 07:24:14 GMT
Subject: RFR: 8332589: ubsan: unix/native/libjava/ProcessImpl_md.c:562:5:
 runtime error: null pointer passed as argument 2,
 which is declared to never be null [v2]
In-Reply-To: <Jmwe6R0-YXoCOmZLpD_riDxQortLtA2LXYd_ZOgXnr4=.209ec34c-7da1-4e49-879d-90e12df6d25f@github.com>
References: <AwlmAiTOhqSaoJ2Jh5YYrBpxakc0Pt9lYP9nvcBjXBo=.813efddf-3f87-4bbf-9cc5-cd769eabd2f7@github.com>
 <Jmwe6R0-YXoCOmZLpD_riDxQortLtA2LXYd_ZOgXnr4=.209ec34c-7da1-4e49-879d-90e12df6d25f@github.com>
Message-ID: <4pcYNz509s4XKwjRajWFZwOSIzONZi21VT2qCiOIUjk=.34c75a28-38a7-4f72-b039-e6f1287fb388@github.com>

On Thu, 23 May 2024 07:26:14 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> When building with ubsan enabled (--enable-uban) on Linux x86_64 and doing jtreg tests afterwards I run into this error :
>> 
>> /jdk/src/java.base/unix/native/libjava/ProcessImpl_md.c:562:5: runtime error: null pointer passed as argument 2, which is declared to never be null
>>     #0 0x7fd95bec78d8 in spawnChild /jdk/src/java.base/unix/native/libjava/ProcessImpl_md.c:562
>>     #1 0x7fd95bec78d8 in startChild /jdk/src/java.base/unix/native/libjava/ProcessImpl_md.c:612
>>     #2 0x7fd95bec78d8 in Java_java_lang_ProcessImpl_forkAndExec /jdk/src/java.base/unix/native/libjava/ProcessImpl_md.c:712
>>     #3 0x7fd93797a06d (<unknown module>)
>> 
>> this is the memcpy call getting an unexpected null pointer :
>>     memcpy(buf+offset, c->pdir, sp.dirlen); gets a second parameter null.
>> Something similar was discussed and fixed here https://bugs.python.org/issue27570 for Python .
>> 
>> Similar issue in OpenJDK _ 
>> https://bugs.openjdk.org/browse/JDK-8332473
>> 8332473: ubsan: growableArray.hpp:290:10: runtime error: null pointer passed as argument 1, which is declared to never be null
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remarks Roger Riggs

Hi Magnus, I added handling of the special case that  memcpy src is a null pointer and non-0 length was given .

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19329#issuecomment-2128779448

From asotona at openjdk.org  Fri May 24 07:44:21 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Fri, 24 May 2024 07:44:21 GMT
Subject: RFR: 8331291: java.lang.classfile.Attributes class performs a lot
 of static initializations [v9]
In-Reply-To: <SHIvjbwCWBPERKxlytEsY_O_kEiJbSeEmSusuDwjTIw=.ae8dd21e-a822-476e-9760-dd489532dbf1@github.com>
References: <SHIvjbwCWBPERKxlytEsY_O_kEiJbSeEmSusuDwjTIw=.ae8dd21e-a822-476e-9760-dd489532dbf1@github.com>
Message-ID: <DZYpHXjil4en5RedPkpLjxRsGbkQtXzL-md_qbwYAJ0=.fc7aad15-d4b4-4f61-9ff8-cbbec74d46fb@github.com>

> Hi,
> During performance optimization work on Class-File API as JDK lambda generator we found some static initialization killers.
> One of them is `java.lang.classfile.Attributes` with tens of static fields initialized with individual attribute mappers, and common set of all mappers, and static map from attribute names to the mappers.
> 
> I propose to turn all the static fields into lazy-initialized static methods and remove `PREDEFINED_ATTRIBUTES` and `standardAttribute(Utf8Entry name)` static mapping method from the `Attributes` API class.
>  
> Please let me know your comments or objections and please review the [PR](https://github.com/openjdk/jdk/pull/19006) and [CSR](https://bugs.openjdk.org/browse/JDK-8331414), so we can make it into 23.
> 
> Thank you,
> Adam

Adam Sotona has updated the pull request incrementally with two additional commits since the last revision:

 - addressed CSR review comments
 - fixed CompilationIDMapper does not allow multiple instances

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19006/files
  - new: https://git.openjdk.org/jdk/pull/19006/files/b4203cfd..21515ec2

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19006&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19006&range=07-08

  Stats: 62 lines in 2 files changed: 61 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/19006.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19006/head:pull/19006

PR: https://git.openjdk.org/jdk/pull/19006

From alanb at openjdk.org  Fri May 24 08:05:01 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 24 May 2024 08:05:01 GMT
Subject: RFR: 8242888: Convert dynamic proxy to hidden classes
In-Reply-To: <A6RYDzBBFGsmRdFEmV0P7r9PL55ri7NlgIQ37MsWJH0=.2f8d69ab-cc90-4582-a7ca-a9f5a459acb5@github.com>
References: <QO0dIumbbHUFWz43pCWbmsqdH5zG8NaVUB9FwNFlbTw=.8fe20db2-9cfc-46e9-9f98-0979259ac882@github.com>
 <A6RYDzBBFGsmRdFEmV0P7r9PL55ri7NlgIQ37MsWJH0=.2f8d69ab-cc90-4582-a7ca-a9f5a459acb5@github.com>
Message-ID: <WO-JpBzTm-uKYRjeXp29Az2K8XAE5otmimcufHw6RMc=.42099601-3dc0-4895-9795-e336a0ab70ef@github.com>

On Thu, 23 May 2024 23:24:16 GMT, Chen Liang <liach at openjdk.org> wrote:

> Hmm, actually, looking at the specs of the method again, does it imply that Proxy classes are never unloaded once defined in a ClassLoader, as seen in `Proxy::getProxyClass`:

It's not specified, Proxy pre-dates hidden classes although its Proxy did require some changes to specify that it can't be a proxy to a hidden class. Given the getProxyClass is deprecated then it may be better to have it work the same way as it has always done.

If Proxy::newInstanceClass is changed to return an instance of a hidden class then spec changes are needed. Maybe too early to think about that now as there is a lot of analysis work required to do before going near code.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19356#issuecomment-2128853043

From asotona at openjdk.org  Fri May 24 08:24:15 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Fri, 24 May 2024 08:24:15 GMT
Subject: RFR: 8331291: java.lang.classfile.Attributes class performs a lot
 of static initializations [v10]
In-Reply-To: <SHIvjbwCWBPERKxlytEsY_O_kEiJbSeEmSusuDwjTIw=.ae8dd21e-a822-476e-9760-dd489532dbf1@github.com>
References: <SHIvjbwCWBPERKxlytEsY_O_kEiJbSeEmSusuDwjTIw=.ae8dd21e-a822-476e-9760-dd489532dbf1@github.com>
Message-ID: <EgXL6d-mlSgOxNS3NM_-6dlhKQ2jdTrcYpLndeFxa8g=.ad03c33e-6b9e-44a8-aef0-9068a51b0159@github.com>

> Hi,
> During performance optimization work on Class-File API as JDK lambda generator we found some static initialization killers.
> One of them is `java.lang.classfile.Attributes` with tens of static fields initialized with individual attribute mappers, and common set of all mappers, and static map from attribute names to the mappers.
> 
> I propose to turn all the static fields into lazy-initialized static methods and remove `PREDEFINED_ATTRIBUTES` and `standardAttribute(Utf8Entry name)` static mapping method from the `Attributes` API class.
>  
> Please let me know your comments or objections and please review the [PR](https://github.com/openjdk/jdk/pull/19006) and [CSR](https://bugs.openjdk.org/browse/JDK-8331414), so we can make it into 23.
> 
> Thank you,
> Adam

Adam Sotona has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 16 commits:

 - fixed jdeps.Dependencies
 - Merge branch 'master' into JDK-8331291-attributes
 - addressed CSR review comments
 - fixed CompilationIDMapper does not allow multiple instances
 - fixed tests
 - fixed tests
 - fixed tests
 - updated LimitsTest
 - Merge branch 'master' into JDK-8331291-attributes
   
   # Conflicts:
   #	test/jdk/jdk/classfile/SignaturesTest.java
 - Merge branch 'master' into JDK-8331291-attributes
 - ... and 6 more: https://git.openjdk.org/jdk/compare/239c1b33...37f7f63f

-------------

Changes: https://git.openjdk.org/jdk/pull/19006/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19006&range=09
  Stats: 2277 lines in 145 files changed: 960 ins; 613 del; 704 mod
  Patch: https://git.openjdk.org/jdk/pull/19006.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19006/head:pull/19006

PR: https://git.openjdk.org/jdk/pull/19006

From ihse at openjdk.org  Fri May 24 08:47:02 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 24 May 2024 08:47:02 GMT
Subject: RFR: 8332589: ubsan: unix/native/libjava/ProcessImpl_md.c:562:5:
 runtime error: null pointer passed as argument 2,
 which is declared to never be null [v3]
In-Reply-To: <1WfHx9Kgp1eOclYJ4qE5rCmqOIyn2GRARqDSN6PfDJw=.f9ed4c68-8eb8-4ad6-b132-39356d5445a6@github.com>
References: <AwlmAiTOhqSaoJ2Jh5YYrBpxakc0Pt9lYP9nvcBjXBo=.813efddf-3f87-4bbf-9cc5-cd769eabd2f7@github.com>
 <1WfHx9Kgp1eOclYJ4qE5rCmqOIyn2GRARqDSN6PfDJw=.f9ed4c68-8eb8-4ad6-b132-39356d5445a6@github.com>
Message-ID: <PAMhnIwlFlJ0sj1SDKPeiyESkZlt6kHs_mwszvqtLh0=.a4718423-3549-424c-9809-053cd2f6b42e@github.com>

On Fri, 24 May 2024 07:24:13 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> When building with ubsan enabled (--enable-uban) on Linux x86_64 and doing jtreg tests afterwards I run into this error :
>> 
>> /jdk/src/java.base/unix/native/libjava/ProcessImpl_md.c:562:5: runtime error: null pointer passed as argument 2, which is declared to never be null
>>     #0 0x7fd95bec78d8 in spawnChild /jdk/src/java.base/unix/native/libjava/ProcessImpl_md.c:562
>>     #1 0x7fd95bec78d8 in startChild /jdk/src/java.base/unix/native/libjava/ProcessImpl_md.c:612
>>     #2 0x7fd95bec78d8 in Java_java_lang_ProcessImpl_forkAndExec /jdk/src/java.base/unix/native/libjava/ProcessImpl_md.c:712
>>     #3 0x7fd93797a06d (<unknown module>)
>> 
>> this is the memcpy call getting an unexpected null pointer :
>>     memcpy(buf+offset, c->pdir, sp.dirlen); gets a second parameter null.
>> Something similar was discussed and fixed here https://bugs.python.org/issue27570 for Python .
>> 
>> Similar issue in OpenJDK _ 
>> https://bugs.openjdk.org/browse/JDK-8332473
>> 8332473: ubsan: growableArray.hpp:290:10: runtime error: null pointer passed as argument 1, which is declared to never be null
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   handle special case that memcpy src is NULL but a len larger than 0 was given

This looks much safer. Thank you! 

I think the code can be simplified a bit, as commented. It does not matter much, so you can keep the current code as well if you think it looks better.

src/java.base/unix/native/libjava/ProcessImpl_md.c line 563:

> 561:     offset = copystrings(buf, offset, &c->envv[0]);
> 562:     if (c->pdir != NULL) {
> 563:         if (sp.dirlen > 0) {

As long as c->pdir is non-null, I think the code below is safe to execute. `memcpy(a, b, len)` should be okay if `len` is 0, as long as `a` and `b` are non-null, right?

So this check here is not needed, I think.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19329#issuecomment-2128960961
PR Review Comment: https://git.openjdk.org/jdk/pull/19329#discussion_r1613102923

From mik3hall at gmail.com  Fri May 24 08:47:10 2024
From: mik3hall at gmail.com (Michael Hall)
Date: Fri, 24 May 2024 03:47:10 -0500
Subject: RFR: 8332110: [macos] jpackage tries to sign added files without
 the --mac-sign option
In-Reply-To: <B26D82CC-55A9-42E6-AD5D-418B95E5E565@gmail.com>
References: <eiboU_LgwkTte_7rkPJAdDm1x_-Pzm8rdwUiY_4MAYI=.b982e161-fe24-44ab-9db5-2f1d80eb0d99@github.com>
 <B26D82CC-55A9-42E6-AD5D-418B95E5E565@gmail.com>
Message-ID: <BA8E1B15-2616-432F-9F34-5D5171DE34F7@gmail.com>



> On May 24, 2024, at 3:08?AM, Michael Hall <mik3hall at gmail.com> wrote:
> 
>> On May 23, 2024, at 8:13?PM, Alexander Matveev <almatvee at openjdk.org <mailto:almatvee at openjdk.org>> wrote:
>> 
>> otherwise add additional content as post-processing step.
> 
> Doesn?t this still leave you with an application that isn?t validly signed? And probably won?t run because of that.
> 
>> 2) jpackage --type app-image -n Test --app-content ReadMe ...
> 
> For your example. This almost seems like an Apple bug if you can add a directory to the Contents directory but not a file? 

Sorry I made my prior off-list.

Would it also generally be a good idea to include a final codesign verify to fail the build if something is wrong with the signature?

Something like?

echo '*******************'
echo 'verifying signature'
echo '*******************'
codesign -v --verbose=4 outputdir/HalfPipe.app

Expected output?

*******************
verifying signature
*******************
outputdir/HalfPipe.app: valid on disk
outputdir/HalfPipe.app: satisfies its Designated Requirement

I think I have suggested this before but don?t remember if I did an enhancement request. Maybe you do that and I?m just not aware of it if it doesn?t appear in the jpackage output.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240524/ada5e0a4/attachment-0001.htm>

From mik3hall at gmail.com  Fri May 24 08:47:10 2024
From: mik3hall at gmail.com (Michael Hall)
Date: Fri, 24 May 2024 03:47:10 -0500
Subject: RFR: 8332110: [macos] jpackage tries to sign added files without
 the --mac-sign option
In-Reply-To: <B26D82CC-55A9-42E6-AD5D-418B95E5E565@gmail.com>
References: <eiboU_LgwkTte_7rkPJAdDm1x_-Pzm8rdwUiY_4MAYI=.b982e161-fe24-44ab-9db5-2f1d80eb0d99@github.com>
 <B26D82CC-55A9-42E6-AD5D-418B95E5E565@gmail.com>
Message-ID: <BA8E1B15-2616-432F-9F34-5D5171DE34F7@gmail.com>



> On May 24, 2024, at 3:08?AM, Michael Hall <mik3hall at gmail.com> wrote:
> 
>> On May 23, 2024, at 8:13?PM, Alexander Matveev <almatvee at openjdk.org <mailto:almatvee at openjdk.org>> wrote:
>> 
>> otherwise add additional content as post-processing step.
> 
> Doesn?t this still leave you with an application that isn?t validly signed? And probably won?t run because of that.
> 
>> 2) jpackage --type app-image -n Test --app-content ReadMe ...
> 
> For your example. This almost seems like an Apple bug if you can add a directory to the Contents directory but not a file? 

Sorry I made my prior off-list.

Would it also generally be a good idea to include a final codesign verify to fail the build if something is wrong with the signature?

Something like?

echo '*******************'
echo 'verifying signature'
echo '*******************'
codesign -v --verbose=4 outputdir/HalfPipe.app

Expected output?

*******************
verifying signature
*******************
outputdir/HalfPipe.app: valid on disk
outputdir/HalfPipe.app: satisfies its Designated Requirement

I think I have suggested this before but don?t remember if I did an enhancement request. Maybe you do that and I?m just not aware of it if it doesn?t appear in the jpackage output.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240524/ada5e0a4/attachment-0002.htm>

From ihse at openjdk.org  Fri May 24 08:54:07 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 24 May 2024 08:54:07 GMT
Subject: RFR: 8330542: Template for Creating Strict JAXP Configuration File
 [v13]
In-Reply-To: <OSDfl2mY_eU6Otx-aSlb4ehXy-9kHGxsW0EStuPle70=.dcf73a63-a9b1-4832-b433-f2a721f082c0@github.com>
References: <v1bAYKgH9zfooXpvnBw4Vu2TIqHuKqqtSmgB0hiNp-Q=.31661a99-ecfc-4a05-8045-67b5f680db60@github.com>
 <OSDfl2mY_eU6Otx-aSlb4ehXy-9kHGxsW0EStuPle70=.dcf73a63-a9b1-4832-b433-f2a721f082c0@github.com>
Message-ID: <J6B1TWx0BihlBG-DmhGMu83N_8sHa96smC-Ct8rR3RA=.3d39d1a2-8b00-419e-8cad-66cd4727b45b@github.com>

On Fri, 24 May 2024 05:26:40 GMT, Joe Wang <joehw at openjdk.org> wrote:

>> Add two sample configuration files:
>> 
>>   jaxp-strict.properties: used to set strict configuration, stricter than jaxp.properties in previous versions such as JDK 22
>> 
>>>   jaxp-compat.properties: used to regain compatibility from any more restricted configuration than previous versions such as JDK 22
>> 
>> Updated on 5/16/2024
>> 
>> Design change:
>> The design is changed to include in the JDK two configuration files that are the default jaxp.properties and jaxp-strict.properties, instead of three, dropping jaxp-compat.properties.
>> 
>> Updated on 5/18/2024
>> 
>> Withdraw changes to jaxp.properties. The original idea was to match jaxp-strict.properties with regard to the properties. However, that change impact the configuration process, resulting in tests that verify the process to fail.
>> 
>> Updated on 5/23/2024
>> 
>> Provide a template `jaxp-strict.template` instead of a properties file. This template can be used to create custom configuration files.
>
> Joe Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add a template instead of a property file; remove implNote; update test and make script accordingly.

I would recommend naming the new file `jaxp-strict.properties.template` instead. This would follow the pattern we have used in the JDK, and I think it is much better at providing clarify as to what this file actually is  -- a template for a `.properties` file.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18831#issuecomment-2128979310

From redestad at openjdk.org  Fri May 24 10:29:05 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Fri, 24 May 2024 10:29:05 GMT
Subject: RFR: 8331291: java.lang.classfile.Attributes class performs a lot
 of static initializations [v10]
In-Reply-To: <EgXL6d-mlSgOxNS3NM_-6dlhKQ2jdTrcYpLndeFxa8g=.ad03c33e-6b9e-44a8-aef0-9068a51b0159@github.com>
References: <SHIvjbwCWBPERKxlytEsY_O_kEiJbSeEmSusuDwjTIw=.ae8dd21e-a822-476e-9760-dd489532dbf1@github.com>
 <EgXL6d-mlSgOxNS3NM_-6dlhKQ2jdTrcYpLndeFxa8g=.ad03c33e-6b9e-44a8-aef0-9068a51b0159@github.com>
Message-ID: <geRaEbjcMTg695xtidYCHOu3R-6i9HVUFmCLaJlltvE=.4b86c992-0c6a-41d5-930e-9de485b6f9b0@github.com>

On Fri, 24 May 2024 08:24:15 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> Hi,
>> During performance optimization work on Class-File API as JDK lambda generator we found some static initialization killers.
>> One of them is `java.lang.classfile.Attributes` with tens of static fields initialized with individual attribute mappers, and common set of all mappers, and static map from attribute names to the mappers.
>> 
>> I propose to turn all the static fields into lazy-initialized static methods and remove `PREDEFINED_ATTRIBUTES` and `standardAttribute(Utf8Entry name)` static mapping method from the `Attributes` API class.
>>  
>> Please let me know your comments or objections and please review the [PR](https://github.com/openjdk/jdk/pull/19006) and [CSR](https://bugs.openjdk.org/browse/JDK-8331414), so we can make it into 23.
>> 
>> Thank you,
>> Adam
>
> Adam Sotona has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 16 commits:
> 
>  - fixed jdeps.Dependencies
>  - Merge branch 'master' into JDK-8331291-attributes
>  - addressed CSR review comments
>  - fixed CompilationIDMapper does not allow multiple instances
>  - fixed tests
>  - fixed tests
>  - fixed tests
>  - updated LimitsTest
>  - Merge branch 'master' into JDK-8331291-attributes
>    
>    # Conflicts:
>    #	test/jdk/jdk/classfile/SignaturesTest.java
>  - Merge branch 'master' into JDK-8331291-attributes
>  - ... and 6 more: https://git.openjdk.org/jdk/compare/239c1b33...37f7f63f

Looks good after revisions.

-------------

Marked as reviewed by redestad (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19006#pullrequestreview-2076508421

From jlahoda at openjdk.org  Fri May 24 11:09:05 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Fri, 24 May 2024 11:09:05 GMT
Subject: RFR: 8305457: Implement java.io.IO [v13]
In-Reply-To: <OeX8FjKjxcEY8Xww8oZ31Uxo5odfSLt9msAYKr5AuIA=.40796307-4eab-4266-a3df-5cf4a8d422c8@github.com>
References: <w2msiw_qaMEIJS3s9D4bg8pFbz5WIF0KdP6Mm-XFjLI=.85b2020b-8c46-4bac-8a69-4975b068f2ff@github.com>
 <OeX8FjKjxcEY8Xww8oZ31Uxo5odfSLt9msAYKr5AuIA=.40796307-4eab-4266-a3df-5cf4a8d422c8@github.com>
Message-ID: <iyygb7aV0KxQ_eV6LGyyux5gXb1b6LEcF0wcexXRJTY=.4da936e8-d138-4cb4-8c77-a2d4ae90db96@github.com>

On Thu, 23 May 2024 17:14:19 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Please review this PR which introduces the `java.io.IO` top-level class and three methods to `java.io.Console` for [Implicitly Declared Classes and Instance Main Methods (Third Preview)].
>> 
>> This PR has been obtained as `git merge --squash` of a now obsolete [draft PR].
>> 
>> [Implicitly Declared Classes and Instance Main Methods (Third Preview)]: https://bugs.openjdk.org/browse/JDK-8323335
>> [draft PR]: https://github.com/openjdk/jdk/pull/18921
>
> Pavel Rappo has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 23 commits:
> 
>  - Merge branch 'master' into 8305457-Implement-java.io.IO
>  - Force reasonable terminal size
>    
>    JLine outputs unexpected stuff if the terminal isn't dumb and small,
>    such as that of our CI machines:
>    
>        if (newLines.size() > displaySize && !isTerminalDumb()) {
>            StringBuilder sb = new StringBuilder(">....");
>    
>    This causes the IO test to fail with timeout, because the expected
>    prompt is never matched. To avoid that, we reasonably size the
>    terminal.
>  - Restructure the test
>  - Add diagnostic output
>  - Use "expect" that was found
>  - Merge branch 'master' into 8305457-Implement-java.io.IO
>    
>    # Conflicts:
>    #	src/java.base/share/classes/java/io/ProxyingConsole.java
>    #	src/java.base/share/classes/jdk/internal/io/JdkConsole.java
>    #	src/java.base/share/classes/jdk/internal/io/JdkConsoleImpl.java
>    #	src/jdk.internal.le/share/classes/jdk/internal/org/jline/JdkConsoleProviderImpl.java
>    #	src/jdk.jshell/share/classes/jdk/jshell/execution/impl/ConsoleImpl.java
>  - Escape prompt
>  - Merge branch 'master' into 8305457-Implement-java.io.IO
>  - Clarify input charset
>  - Make IO final
>  - ... and 13 more: https://git.openjdk.org/jdk/compare/e19a421c...258ce133

JShell-related changes look good to me.

-------------

Marked as reviewed by jlahoda (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19112#pullrequestreview-2076598544

From prappo at openjdk.org  Fri May 24 11:30:19 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Fri, 24 May 2024 11:30:19 GMT
Subject: RFR: 8305457: Implement java.io.IO [v14]
In-Reply-To: <w2msiw_qaMEIJS3s9D4bg8pFbz5WIF0KdP6Mm-XFjLI=.85b2020b-8c46-4bac-8a69-4975b068f2ff@github.com>
References: <w2msiw_qaMEIJS3s9D4bg8pFbz5WIF0KdP6Mm-XFjLI=.85b2020b-8c46-4bac-8a69-4975b068f2ff@github.com>
Message-ID: <XprICGpbitXh1b925_LstR5gouFRFszxOh1-82yjF3E=.c8cfef99-a48e-4c49-9448-7e01648a6a76@github.com>

> Please review this PR which introduces the `java.io.IO` top-level class and three methods to `java.io.Console` for [Implicitly Declared Classes and Instance Main Methods (Third Preview)].
> 
> This PR has been obtained as `git merge --squash` of a now obsolete [draft PR].
> 
> [Implicitly Declared Classes and Instance Main Methods (Third Preview)]: https://bugs.openjdk.org/browse/JDK-8323335
> [draft PR]: https://github.com/openjdk/jdk/pull/18921

Pavel Rappo has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 26 commits:

 - Fix test failure
   
   Caused by 4e6d851f3f061b4a9c2b5d2e3fba6a0277ac1f34:
   
       8325324: Implement JEP 477: Implicitly Declared Classes
                and Instance Main Methods (Third Preview)
 - Merge branch 'master' into 8305457-Implement-java.io.IO
 - Merge remote-tracking branch 'jdk/master' into 8305457-Implement-java.io.IO
 - Merge branch 'master' into 8305457-Implement-java.io.IO
 - Force reasonable terminal size
   
   JLine outputs unexpected stuff if the terminal isn't dumb and small,
   such as that of our CI machines:
   
       if (newLines.size() > displaySize && !isTerminalDumb()) {
           StringBuilder sb = new StringBuilder(">....");
   
   This causes the IO test to fail with timeout, because the expected
   prompt is never matched. To avoid that, we reasonably size the
   terminal.
 - Restructure the test
 - Add diagnostic output
 - Use "expect" that was found
 - Merge branch 'master' into 8305457-Implement-java.io.IO
   
   # Conflicts:
   #	src/java.base/share/classes/java/io/ProxyingConsole.java
   #	src/java.base/share/classes/jdk/internal/io/JdkConsole.java
   #	src/java.base/share/classes/jdk/internal/io/JdkConsoleImpl.java
   #	src/jdk.internal.le/share/classes/jdk/internal/org/jline/JdkConsoleProviderImpl.java
   #	src/jdk.jshell/share/classes/jdk/jshell/execution/impl/ConsoleImpl.java
 - Escape prompt
 - ... and 16 more: https://git.openjdk.org/jdk/compare/239c1b33...5edf686d

-------------

Changes: https://git.openjdk.org/jdk/pull/19112/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19112&range=13
  Stats: 696 lines in 15 files changed: 691 ins; 1 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/19112.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19112/head:pull/19112

PR: https://git.openjdk.org/jdk/pull/19112

From alanb at openjdk.org  Fri May 24 11:46:07 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 24 May 2024 11:46:07 GMT
Subject: RFR: 8330542: Template for Creating Strict JAXP Configuration File
 [v13]
In-Reply-To: <OSDfl2mY_eU6Otx-aSlb4ehXy-9kHGxsW0EStuPle70=.dcf73a63-a9b1-4832-b433-f2a721f082c0@github.com>
References: <v1bAYKgH9zfooXpvnBw4Vu2TIqHuKqqtSmgB0hiNp-Q=.31661a99-ecfc-4a05-8045-67b5f680db60@github.com>
 <OSDfl2mY_eU6Otx-aSlb4ehXy-9kHGxsW0EStuPle70=.dcf73a63-a9b1-4832-b433-f2a721f082c0@github.com>
Message-ID: <ZXpU_2es6CpvZv7A1TCoyPwqLJJE80m-JQ0IiHZ7V34=.f0c52286-434d-431a-93b8-d534ef54da60@github.com>

On Fri, 24 May 2024 05:26:40 GMT, Joe Wang <joehw at openjdk.org> wrote:

>> Add two sample configuration files:
>> 
>>   jaxp-strict.properties: used to set strict configuration, stricter than jaxp.properties in previous versions such as JDK 22
>> 
>>>   jaxp-compat.properties: used to regain compatibility from any more restricted configuration than previous versions such as JDK 22
>> 
>> Updated on 5/16/2024
>> 
>> Design change:
>> The design is changed to include in the JDK two configuration files that are the default jaxp.properties and jaxp-strict.properties, instead of three, dropping jaxp-compat.properties.
>> 
>> Updated on 5/18/2024
>> 
>> Withdraw changes to jaxp.properties. The original idea was to match jaxp-strict.properties with regard to the properties. However, that change impact the configuration process, resulting in tests that verify the process to fail.
>> 
>> Updated on 5/23/2024
>> 
>> Provide a template `jaxp-strict.template` instead of a properties file. This template can be used to create custom configuration files.
>
> Joe Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add a template instead of a property file; remove implNote; update test and make script accordingly.

Marked as reviewed by alanb (Reviewer).

Magnus's suggestion for the suffix to be .properties.template makes sense, consistent with the one .template that the JDK currently includes in the run-time image.

Overall this looks okay, I'm happy that the implNote update is removed from the proposal as it read too much like the introducing a new supported interface and would have been confusing to have two configurations in the conf directory.

-------------

PR Review: https://git.openjdk.org/jdk/pull/18831#pullrequestreview-2076667358
PR Comment: https://git.openjdk.org/jdk/pull/18831#issuecomment-2129320078

From lujaniuk at openjdk.org  Fri May 24 12:20:25 2024
From: lujaniuk at openjdk.org (Ludvig Janiuk)
Date: Fri, 24 May 2024 12:20:25 GMT
Subject: RFR: 8332885: Clarify failure_handler self-tests
Message-ID: <fSl5ksYZ89l98gCGy0q3jfhpoCO5UVBKlA5k7Fxt720=.886e149b-561d-4109-9e72-94346f02f25d@github.com>

Adding commetns to clarify that the failure_handler selftests are intended to be run manually. Ideally this would include a more thorough description of the exepcted outputs, but this is what I have time to add right now.

-------------

Commit messages:
 - 8332885 Clarify failure_handler self-tests

Changes: https://git.openjdk.org/jdk/pull/19393/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19393&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8332885
  Stats: 15 lines in 2 files changed: 15 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/19393.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19393/head:pull/19393

PR: https://git.openjdk.org/jdk/pull/19393

From asotona at openjdk.org  Fri May 24 12:35:21 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Fri, 24 May 2024 12:35:21 GMT
Subject: RFR: 8331291: java.lang.classfile.Attributes class performs a lot
 of static initializations [v11]
In-Reply-To: <SHIvjbwCWBPERKxlytEsY_O_kEiJbSeEmSusuDwjTIw=.ae8dd21e-a822-476e-9760-dd489532dbf1@github.com>
References: <SHIvjbwCWBPERKxlytEsY_O_kEiJbSeEmSusuDwjTIw=.ae8dd21e-a822-476e-9760-dd489532dbf1@github.com>
Message-ID: <6bLm0FINPSxkp-WhBPd8tJfDDKEie5fPBe45oNU5qWU=.8a9b299a-5b2f-49af-8ea1-7045f5532e6e@github.com>

> Hi,
> During performance optimization work on Class-File API as JDK lambda generator we found some static initialization killers.
> One of them is `java.lang.classfile.Attributes` with tens of static fields initialized with individual attribute mappers, and common set of all mappers, and static map from attribute names to the mappers.
> 
> I propose to turn all the static fields into lazy-initialized static methods and remove `PREDEFINED_ATTRIBUTES` and `standardAttribute(Utf8Entry name)` static mapping method from the `Attributes` API class.
>  
> Please let me know your comments or objections and please review the [PR](https://github.com/openjdk/jdk/pull/19006) and [CSR](https://bugs.openjdk.org/browse/JDK-8331414), so we can make it into 23.
> 
> Thank you,
> Adam

Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:

  fixed tests

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19006/files
  - new: https://git.openjdk.org/jdk/pull/19006/files/37f7f63f..db73c2dd

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19006&range=10
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19006&range=09-10

  Stats: 8 lines in 4 files changed: 1 ins; 2 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/19006.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19006/head:pull/19006

PR: https://git.openjdk.org/jdk/pull/19006

From jlahoda at openjdk.org  Fri May 24 13:40:16 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Fri, 24 May 2024 13:40:16 GMT
Subject: RFR: 8305457: Implement java.io.IO [v14]
In-Reply-To: <XprICGpbitXh1b925_LstR5gouFRFszxOh1-82yjF3E=.c8cfef99-a48e-4c49-9448-7e01648a6a76@github.com>
References: <w2msiw_qaMEIJS3s9D4bg8pFbz5WIF0KdP6Mm-XFjLI=.85b2020b-8c46-4bac-8a69-4975b068f2ff@github.com>
 <XprICGpbitXh1b925_LstR5gouFRFszxOh1-82yjF3E=.c8cfef99-a48e-4c49-9448-7e01648a6a76@github.com>
Message-ID: <khds7PK5-LZONmxHFttV_PrfAG2pxHfPq5R33jHcv2k=.a80637e1-a240-43bc-b16b-2b70c4680ece@github.com>

On Fri, 24 May 2024 11:30:19 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Please review this PR which introduces the `java.io.IO` top-level class and three methods to `java.io.Console` for [Implicitly Declared Classes and Instance Main Methods (Third Preview)].
>> 
>> This PR has been obtained as `git merge --squash` of a now obsolete [draft PR].
>> 
>> [Implicitly Declared Classes and Instance Main Methods (Third Preview)]: https://bugs.openjdk.org/browse/JDK-8323335
>> [draft PR]: https://github.com/openjdk/jdk/pull/18921
>
> Pavel Rappo has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 26 commits:
> 
>  - Fix test failure
>    
>    Caused by 4e6d851f3f061b4a9c2b5d2e3fba6a0277ac1f34:
>    
>        8325324: Implement JEP 477: Implicitly Declared Classes
>                 and Instance Main Methods (Third Preview)
>  - Merge branch 'master' into 8305457-Implement-java.io.IO
>  - Merge remote-tracking branch 'jdk/master' into 8305457-Implement-java.io.IO
>  - Merge branch 'master' into 8305457-Implement-java.io.IO
>  - Force reasonable terminal size
>    
>    JLine outputs unexpected stuff if the terminal isn't dumb and small,
>    such as that of our CI machines:
>    
>        if (newLines.size() > displaySize && !isTerminalDumb()) {
>            StringBuilder sb = new StringBuilder(">....");
>    
>    This causes the IO test to fail with timeout, because the expected
>    prompt is never matched. To avoid that, we reasonably size the
>    terminal.
>  - Restructure the test
>  - Add diagnostic output
>  - Use "expect" that was found
>  - Merge branch 'master' into 8305457-Implement-java.io.IO
>    
>    # Conflicts:
>    #	src/java.base/share/classes/java/io/ProxyingConsole.java
>    #	src/java.base/share/classes/jdk/internal/io/JdkConsole.java
>    #	src/java.base/share/classes/jdk/internal/io/JdkConsoleImpl.java
>    #	src/jdk.internal.le/share/classes/jdk/internal/org/jline/JdkConsoleProviderImpl.java
>    #	src/jdk.jshell/share/classes/jdk/jshell/execution/impl/ConsoleImpl.java
>  - Escape prompt
>  - ... and 16 more: https://git.openjdk.org/jdk/compare/239c1b33...5edf686d

Looks good to me.

-------------

Marked as reviewed by jlahoda (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19112#pullrequestreview-2076957513

From prappo at openjdk.org  Fri May 24 13:40:18 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Fri, 24 May 2024 13:40:18 GMT
Subject: Integrated: 8305457: Implement java.io.IO
In-Reply-To: <w2msiw_qaMEIJS3s9D4bg8pFbz5WIF0KdP6Mm-XFjLI=.85b2020b-8c46-4bac-8a69-4975b068f2ff@github.com>
References: <w2msiw_qaMEIJS3s9D4bg8pFbz5WIF0KdP6Mm-XFjLI=.85b2020b-8c46-4bac-8a69-4975b068f2ff@github.com>
Message-ID: <cw8_7M9ZZWTVorsWaj4C3EZmFOwhrFCO5dH7PhnzaXA=.2e4ff058-02ea-4b98-96e8-083b609a5484@github.com>

On Mon, 6 May 2024 21:45:12 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> Please review this PR which introduces the `java.io.IO` top-level class and three methods to `java.io.Console` for [Implicitly Declared Classes and Instance Main Methods (Third Preview)].
> 
> This PR has been obtained as `git merge --squash` of a now obsolete [draft PR].
> 
> [Implicitly Declared Classes and Instance Main Methods (Third Preview)]: https://bugs.openjdk.org/browse/JDK-8323335
> [draft PR]: https://github.com/openjdk/jdk/pull/18921

This pull request has now been integrated.

Changeset: c099f14f
Author:    Pavel Rappo <prappo at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/c099f14f07260713229cffbe7d23aa8305415a67
Stats:     696 lines in 15 files changed: 691 ins; 1 del; 4 mod

8305457: Implement java.io.IO

Reviewed-by: naoto, smarks, jpai, jlahoda

-------------

PR: https://git.openjdk.org/jdk/pull/19112

From sgibbons at openjdk.org  Fri May 24 13:44:28 2024
From: sgibbons at openjdk.org (Scott Gibbons)
Date: Fri, 24 May 2024 13:44:28 GMT
Subject: RFR: 8320448: Accelerate IndexOf using AVX2 [v36]
In-Reply-To: <uWi4QxH31hL93771gkl_GgvP0m84IRSoR_1Yi8hD17E=.bc6ed458-7081-4c3f-9348-f59358fa05a4@github.com>
References: <uWi4QxH31hL93771gkl_GgvP0m84IRSoR_1Yi8hD17E=.bc6ed458-7081-4c3f-9348-f59358fa05a4@github.com>
Message-ID: <uS7svs-LQbJNU3D-FQ_0kAs7SypBX8ZfqMeZ4ygyBEs=.284f2a02-4be4-47c4-8959-63b71fd3e2e8@github.com>

> Re-write the IndexOf code without the use of the pcmpestri instruction, only using AVX2 instructions.  This change accelerates String.IndexOf on average 1.3x for AVX2.  The benchmark numbers:
> 
> 
> Benchmark	                                               Score		Latest		
> StringIndexOf.advancedWithMediumSub   343.573		317.934		0.925375393x
> StringIndexOf.advancedWithShortSub1	  1039.081		1053.96		1.014319384x
> StringIndexOf.advancedWithShortSub2	      55.828		110.541		1.980027943x
> StringIndexOf.constantPattern	                9.361		11.906		1.271872663x
> StringIndexOf.searchCharLongSuccess	        4.216		4.218		1.000474383x
> StringIndexOf.searchCharMediumSuccess	3.133		3.216		1.02649218x
> StringIndexOf.searchCharShortSuccess	3.76		        3.761		1.000265957x
> StringIndexOf.success	                                9.186		9.713		1.057369911x
> StringIndexOf.successBig	                      14.341		46.343		3.231504079x
> StringIndexOfChar.latin1_AVX2_String	  6220.918		12154.52		1.953814533x
> StringIndexOfChar.latin1_AVX2_char	  5503.556		5540.044		1.006629895x
> StringIndexOfChar.latin1_SSE4_String	  6978.854		6818.689		0.977049957x
> StringIndexOfChar.latin1_SSE4_char	  5657.499		5474.624		0.967675646x
> StringIndexOfChar.latin1_Short_String	  7132.541		6863.359		0.962260014x
> StringIndexOfChar.latin1_Short_char	16013.389	      16162.437		1.009307711x
> StringIndexOfChar.latin1_mixed_String	  7386.123	      14771.622		1.999915517x
> StringIndexOfChar.latin1_mixed_char	  9901.671		9782.245		0.987938803

Scott Gibbons has updated the pull request incrementally with one additional commit since the last revision:

  Missing comma

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/16753/files
  - new: https://git.openjdk.org/jdk/pull/16753/files/c034d3f9..1a71eb10

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16753&range=35
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16753&range=34-35

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/16753.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16753/head:pull/16753

PR: https://git.openjdk.org/jdk/pull/16753

From sgibbons at openjdk.org  Fri May 24 13:44:28 2024
From: sgibbons at openjdk.org (Scott Gibbons)
Date: Fri, 24 May 2024 13:44:28 GMT
Subject: RFR: 8320448: Accelerate IndexOf using AVX2 [v33]
In-Reply-To: <BfYSarY-tQu34szlCk9qBFTIPR1TlmM5quTXqmoZoGI=.de6da9a2-3ef7-4e1c-8de4-dea5bf134d0f@github.com>
References: <uWi4QxH31hL93771gkl_GgvP0m84IRSoR_1Yi8hD17E=.bc6ed458-7081-4c3f-9348-f59358fa05a4@github.com>
 <kE-TMUMyr6ADsj3wtDB9RlLnXaJFbFzmd7cikzCEuSg=.490d5dd5-eaa8-4137-8e00-7d5de1efb598@github.com>
 <GkGAR2YTtCDe_xFo2a7MxxJyoo-dsgghT9TvqfntN3c=.e40c4157-c48d-4454-b08e-17d6eb9b85a1@github.com>
 <nxpwP6Q_co_mHw7hIyjBjPSjuR6HUc3-ioT80k0tpqE=.fca7f3a5-a511-481c-b630-abeb4402268c@github.com>
 <BfYSarY-tQu34szlCk9qBFTIPR1TlmM5quTXqmoZoGI=.de6da9a2-3ef7-4e1c-8de4-dea5bf134d0f@github.com>
Message-ID: <Gq0CWkBM_cXQcrNM-1YA384MXSQDJgGc5Fl_9xV6oS4=.a06de9f6-985f-431e-a275-65debbc0dd86@github.com>

On Fri, 24 May 2024 06:31:36 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> Thanks for finding this.  It was ignorance on my part as I thought the xorq would have logic to not emit the REX prefix if not necessary, but it doesn't.  Fixed.
>
> Right, it seems to surprise people. There's a lot of preexisting uses of xorq / xorptr to zero a register. I think it would make sense to implement this logic in xorq. I can do this if others agree.

Good idea.  I vote yes.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1613506958

From sgibbons at openjdk.org  Fri May 24 13:44:29 2024
From: sgibbons at openjdk.org (Scott Gibbons)
Date: Fri, 24 May 2024 13:44:29 GMT
Subject: RFR: 8320448: Accelerate IndexOf using AVX2 [v35]
In-Reply-To: <rWYc3j0it-G8yJrMpEPeGvc3Q0caqx2MA-EzdmbdLN0=.d11c9960-ed18-4623-ad27-ba71f6db5507@github.com>
References: <uWi4QxH31hL93771gkl_GgvP0m84IRSoR_1Yi8hD17E=.bc6ed458-7081-4c3f-9348-f59358fa05a4@github.com>
 <-vyOZzeMslZqgJpTsQnnOWi4abWiM8fNeWSVx5LEHm8=.d37011ee-102c-4874-aa26-d113949d25ea@github.com>
 <rWYc3j0it-G8yJrMpEPeGvc3Q0caqx2MA-EzdmbdLN0=.d11c9960-ed18-4623-ad27-ba71f6db5507@github.com>
Message-ID: <khCB9rBcBxccZPe_GOloNwHanCPja15PtC0n9FItSXk=.59b7aee5-9c5b-4c9d-957c-4df98eeb8525@github.com>

On Fri, 24 May 2024 00:47:04 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> Scott Gibbons has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Review comments - move stubGen*_string.cpp to c2_stubGen*_string.cpp
>
> test/jdk/java/lang/StringBuffer/IndexOf.java line 2:
> 
>> 1: /*
>> 2:  * Copyright (c) 2000, 2024 Oracle and/or its affiliates. All rights reserved.
> 
> This copyright header validation failure. Missing comma `,` after 2024.

Fixed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1613504949

From jlahoda at openjdk.org  Fri May 24 13:47:09 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Fri, 24 May 2024 13:47:09 GMT
Subject: RFR: 8331051: Add an `@since` checker test for `java.base` module
 [v7]
In-Reply-To: <fO1l01qTJQy4l47E5P23YC2kSsPVkZdSpr6fe9GFnxQ=.b4c38763-86aa-410f-8f6e-769e65bf5b53@github.com>
References: <NRZmbFYvDwXPuizcmCilJx5Yb6HjZ-2fJa-YILxYUl8=.a79f79e4-77d5-4910-b3df-5e78bb7e402b@github.com>
 <fO1l01qTJQy4l47E5P23YC2kSsPVkZdSpr6fe9GFnxQ=.b4c38763-86aa-410f-8f6e-769e65bf5b53@github.com>
Message-ID: <zs4GOR-oHJ_s0iQdGtazT3TZGQe53m1mbaSoz-QJN-g=.10915ba7-7ebc-4276-b58d-12df14643cda@github.com>

On Wed, 22 May 2024 13:58:21 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

>> This checker checks the values of the `@since` tag found in the documentation comment for an element against the release in which the element first appeared.
>> 
>> Real since value of an API element is computed as the oldest release in which the given API element was introduced. That is:
>> - for modules, classes and interfaces, the release in which the element with the given qualified name was introduced
>> - for constructors, the release in which the constructor with the given VM descriptor was introduced
>> - for methods and fields, the release in which the given method or field with the given VM descriptor became a member of its enclosing class or interface, whether direct or inherited
>> 
>> Effective since value of an API element is computed as follows:
>> - if the given element has a `@since` tag in its javadoc, it is used
>> - in all other cases, return the effective since value of the enclosing element
>> 
>> The since checker verifies that for every API element, the real since value and the effective since value are the same, and reports an error if they are not.
>> 
>> Preview method are handled as per JEP 12, if `@PreviewFeature` is used consistently going forward then the checker doesn't need to be updated with every release. The checker has explicit knowledge of preview elements that came before `JDK 14` because they weren't marked in a machine understandable way and preview elements that came before `JDK 17` that didn't have `@PreviewFeature`.
>> 
>> Important note : We only check code written since `JDK 9` as the releases used to determine the expected value of `@since` tags are taken from the historical data built into `javac` which only goes back that far
>> 
>> The intial comment at the beginning of `SinceChecker.java` holds more information into the program.
>> 
>> I already have filed issues and fixed some wrong tags like in #18640, #18032, #18030, #18055, #18373, #18954, #18972.
>
> Nizar Benalla has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add a few more legacy methods, needed a few more after changes to the checker

Looks good to me, thanks for doing this!

test/jdk/tools/sincechecker/SinceChecker.java line 351:

> 349:         }
> 350:         String uniqueId = getElementName(te, element, types);
> 351:         boolean isCommonMethod = uniqueId.endsWith("toString()") ||

Nit: `.toString()` instead of `toString()`?

-------------

Marked as reviewed by jlahoda (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18934#pullrequestreview-2076973109
PR Review Comment: https://git.openjdk.org/jdk/pull/18934#discussion_r1613507278

From rriggs at openjdk.org  Fri May 24 14:01:03 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 24 May 2024 14:01:03 GMT
Subject: RFR: 8332589: ubsan: unix/native/libjava/ProcessImpl_md.c:562:5:
 runtime error: null pointer passed as argument 2,
 which is declared to never be null [v3]
In-Reply-To: <1WfHx9Kgp1eOclYJ4qE5rCmqOIyn2GRARqDSN6PfDJw=.f9ed4c68-8eb8-4ad6-b132-39356d5445a6@github.com>
References: <AwlmAiTOhqSaoJ2Jh5YYrBpxakc0Pt9lYP9nvcBjXBo=.813efddf-3f87-4bbf-9cc5-cd769eabd2f7@github.com>
 <1WfHx9Kgp1eOclYJ4qE5rCmqOIyn2GRARqDSN6PfDJw=.f9ed4c68-8eb8-4ad6-b132-39356d5445a6@github.com>
Message-ID: <j2A19KIGd4iLpQm-H8h4so_erdG2pgCMGBbVX8GgJPQ=.b0b06a37-0cb0-4e8b-83e2-680ca3b10f6c@github.com>

On Fri, 24 May 2024 07:24:13 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> When building with ubsan enabled (--enable-uban) on Linux x86_64 and doing jtreg tests afterwards I run into this error :
>> 
>> /jdk/src/java.base/unix/native/libjava/ProcessImpl_md.c:562:5: runtime error: null pointer passed as argument 2, which is declared to never be null
>>     #0 0x7fd95bec78d8 in spawnChild /jdk/src/java.base/unix/native/libjava/ProcessImpl_md.c:562
>>     #1 0x7fd95bec78d8 in startChild /jdk/src/java.base/unix/native/libjava/ProcessImpl_md.c:612
>>     #2 0x7fd95bec78d8 in Java_java_lang_ProcessImpl_forkAndExec /jdk/src/java.base/unix/native/libjava/ProcessImpl_md.c:712
>>     #3 0x7fd93797a06d (<unknown module>)
>> 
>> this is the memcpy call getting an unexpected null pointer :
>>     memcpy(buf+offset, c->pdir, sp.dirlen); gets a second parameter null.
>> Something similar was discussed and fixed here https://bugs.python.org/issue27570 for Python .
>> 
>> Similar issue in OpenJDK _ 
>> https://bugs.openjdk.org/browse/JDK-8332473
>> 8332473: ubsan: growableArray.hpp:290:10: runtime error: null pointer passed as argument 1, which is declared to never be null
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   handle special case that memcpy src is NULL but a len larger than 0 was given

LGTM  (Freeing the buffer on fail)

-------------

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19329#pullrequestreview-2077014965

From sgibbons at openjdk.org  Fri May 24 14:22:11 2024
From: sgibbons at openjdk.org (Scott Gibbons)
Date: Fri, 24 May 2024 14:22:11 GMT
Subject: RFR: 8320448: Accelerate IndexOf using AVX2 [v33]
In-Reply-To: <BfYSarY-tQu34szlCk9qBFTIPR1TlmM5quTXqmoZoGI=.de6da9a2-3ef7-4e1c-8de4-dea5bf134d0f@github.com>
References: <uWi4QxH31hL93771gkl_GgvP0m84IRSoR_1Yi8hD17E=.bc6ed458-7081-4c3f-9348-f59358fa05a4@github.com>
 <kE-TMUMyr6ADsj3wtDB9RlLnXaJFbFzmd7cikzCEuSg=.490d5dd5-eaa8-4137-8e00-7d5de1efb598@github.com>
 <GkGAR2YTtCDe_xFo2a7MxxJyoo-dsgghT9TvqfntN3c=.e40c4157-c48d-4454-b08e-17d6eb9b85a1@github.com>
 <nxpwP6Q_co_mHw7hIyjBjPSjuR6HUc3-ioT80k0tpqE=.fca7f3a5-a511-481c-b630-abeb4402268c@github.com>
 <BfYSarY-tQu34szlCk9qBFTIPR1TlmM5quTXqmoZoGI=.de6da9a2-3ef7-4e1c-8de4-dea5bf134d0f@github.com>
Message-ID: <Y5yF2Y5MfT6Cz-mhe3qr68Bstkt1ODKOO-4NIh4yeCo=.6675b3fa-12f7-4201-8349-38828242660b@github.com>

On Fri, 24 May 2024 06:31:40 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> It may, but I believe the movq is shorter (although maybe not to r15).  I'll do some experimentation.
>
> the RIP-relative lea should have a shorter encoding. I think something like `lea(r15, ExternalAddress(small_jump_table))` should produce it (untested)

Just did the experiment and it turns out that `mov64(r15, (int64_t)small_jump_table)` and `lea(r15, ExternalAddress(small_jump_table))` produce exactly the same code:

`0x00007fffe463d68b:  49 bf a0 d5 63 e4 ff 7f 00 00   movabs r15,0x7fffe463d5a0`

The code in `MacroAssembler` for `lea` calls `mov_literal64` with no check for whether it can be ip-relative.

I tried doing it myself via `leaq(r15, Address(rip, (int64_t)small_jump_table - (int64_t)(__ pc())))` but there is no definition in `register_x86.hpp` for register `rip`.  So I'm not sure exactly how to produce RIP-relative addressing.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1613560044

From lujaniuk at openjdk.org  Fri May 24 14:39:08 2024
From: lujaniuk at openjdk.org (Ludvig Janiuk)
Date: Fri, 24 May 2024 14:39:08 GMT
Subject: RFR: 8332898: failure_handler: log directory of commands
Message-ID: <1QX0asjsisoy1ygDzWY1XaespvKbclWKms0Cf_eXqls=.189d31a0-d3ed-41a9-9ca9-8251e4e8edf7@github.com>

Also log the directory in which the command used by failure_handler was executed. While often the same, it isn't always, and so it this should simplify troubleshooting for someone looking at this at a glance without being a failure_handler expert.

Example output after this change:

----------------------------------------
[2024-05-24 14:26:46] [/usr/bin/pmap, -p, 2233017] timeout=20000 in /<my-absolute-project-dir>/JTwork/scratch
----------------------------------------

before:

----------------------------------------
[2024-05-24 14:26:46] [/usr/bin/pmap, -p, 2233017] timeout=20000
----------------------------------------

-------------

Commit messages:
 - 8332898 failure_handler: log directory of commands

Changes: https://git.openjdk.org/jdk/pull/19396/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19396&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8332898
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/19396.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19396/head:pull/19396

PR: https://git.openjdk.org/jdk/pull/19396

From djelinski at openjdk.org  Fri May 24 14:52:12 2024
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Fri, 24 May 2024 14:52:12 GMT
Subject: RFR: 8320448: Accelerate IndexOf using AVX2 [v33]
In-Reply-To: <Y5yF2Y5MfT6Cz-mhe3qr68Bstkt1ODKOO-4NIh4yeCo=.6675b3fa-12f7-4201-8349-38828242660b@github.com>
References: <uWi4QxH31hL93771gkl_GgvP0m84IRSoR_1Yi8hD17E=.bc6ed458-7081-4c3f-9348-f59358fa05a4@github.com>
 <kE-TMUMyr6ADsj3wtDB9RlLnXaJFbFzmd7cikzCEuSg=.490d5dd5-eaa8-4137-8e00-7d5de1efb598@github.com>
 <GkGAR2YTtCDe_xFo2a7MxxJyoo-dsgghT9TvqfntN3c=.e40c4157-c48d-4454-b08e-17d6eb9b85a1@github.com>
 <nxpwP6Q_co_mHw7hIyjBjPSjuR6HUc3-ioT80k0tpqE=.fca7f3a5-a511-481c-b630-abeb4402268c@github.com>
 <BfYSarY-tQu34szlCk9qBFTIPR1TlmM5quTXqmoZoGI=.de6da9a2-3ef7-4e1c-8de4-dea5bf134d0f@github.com>
 <Y5yF2Y5MfT6Cz-mhe3qr68Bstkt1ODKOO-4NIh4yeCo=.6675b3fa-12f7-4201-8349-38828242660b@github.com>
Message-ID: <D8_haA3HGt72E96jB_5XRfRMmtMX8QeeZ7yfXOMklYU=.88d509be-4795-49ce-987b-1d968280237e@github.com>

On Fri, 24 May 2024 14:19:13 GMT, Scott Gibbons <sgibbons at openjdk.org> wrote:

>> the RIP-relative lea should have a shorter encoding. I think something like `lea(r15, ExternalAddress(small_jump_table))` should produce it (untested)
>
> Just did the experiment and it turns out that `mov64(r15, (int64_t)small_jump_table)` and `lea(r15, ExternalAddress(small_jump_table))` produce exactly the same code:
> 
> `0x00007fffe463d68b:  49 bf a0 d5 63 e4 ff 7f 00 00   movabs r15,0x7fffe463d5a0`
> 
> The code in `MacroAssembler` for `lea` calls `mov_literal64` with no check for whether it can be ip-relative.
> 
> I tried doing it myself via `leaq(r15, Address(rip, (int64_t)small_jump_table - (int64_t)(__ pc())))` but there is no definition in `register_x86.hpp` for register `rip`.  So I'm not sure exactly how to produce RIP-relative addressing.

Thanks for checking. Well I know that the `MacroAssembler::movdqu(XMMRegister dst, AddressLiteral src, Register rscratch)` method actually generates rip-relative addresses. Maybe we could copy some of that code.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1613603833

From yzheng at openjdk.org  Fri May 24 14:55:08 2024
From: yzheng at openjdk.org (Yudi Zheng)
Date: Fri, 24 May 2024 14:55:08 GMT
Subject: RFR: 8327964: Simplify BigInteger.implMultiplyToLen intrinsic [v6]
In-Reply-To: <PgN6dfopkQcs-atZRqVqPFIWd32n1Rgp6WG9HTPYmsk=.74227143-d79e-4a7b-8ace-2a6c2b014627@github.com>
References: <Z5U-3OSq9_rd0t6DHNRhjF3LHtc9b6orz-mcQ4Uqzl8=.c4f0a0b8-9e10-4505-82f7-7d3a82929d22@github.com>
 <GkTIvOKs4GDKUOPjaw893H4fAoeBDuzQn4kKnQqG2dA=.7762f50b-40b1-4763-940b-7e0c8a66d466@github.com>
 <PgN6dfopkQcs-atZRqVqPFIWd32n1Rgp6WG9HTPYmsk=.74227143-d79e-4a7b-8ace-2a6c2b014627@github.com>
Message-ID: <lRBxCvIWxbgFqOpbP1bVjcomr4Wnjkt5-JgLpOPFOYQ=.c0fe879e-a988-41d5-9fcc-03995a7dd19a@github.com>

On Thu, 23 May 2024 10:12:17 GMT, Bhavana Kilambi <bkilambi at openjdk.org> wrote:

>> Yudi Zheng has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   address comments.
>
> src/hotspot/share/opto/library_call.cpp line 5925:
> 
>> 5923:   // Set the original stack and the reexecute bit for the interpreter to reexecute
>> 5924:   // the bytecode that invokes BigInteger.multiplyToLen() if deoptimization happens
>> 5925:   // on the return from z array allocation in runtime.
> 
> Since we are not allocating z array during runtime anymore, do we still need these comments?

Thanks for pointing it out! Removed.

> src/java.base/share/classes/java/math/BigInteger.java line 1836:
> 
>> 1834: 
>> 1835:         if (z == null || z.length < (xlen + ylen))
>> 1836:              z = new int[xlen + ylen];
> 
> Style: only 4 spaces indentation

Done

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18226#discussion_r1613608426
PR Review Comment: https://git.openjdk.org/jdk/pull/18226#discussion_r1613608653

From mdoerr at openjdk.org  Fri May 24 15:02:02 2024
From: mdoerr at openjdk.org (Martin Doerr)
Date: Fri, 24 May 2024 15:02:02 GMT
Subject: RFR: 8332589: ubsan: unix/native/libjava/ProcessImpl_md.c:562:5:
 runtime error: null pointer passed as argument 2,
 which is declared to never be null [v3]
In-Reply-To: <1WfHx9Kgp1eOclYJ4qE5rCmqOIyn2GRARqDSN6PfDJw=.f9ed4c68-8eb8-4ad6-b132-39356d5445a6@github.com>
References: <AwlmAiTOhqSaoJ2Jh5YYrBpxakc0Pt9lYP9nvcBjXBo=.813efddf-3f87-4bbf-9cc5-cd769eabd2f7@github.com>
 <1WfHx9Kgp1eOclYJ4qE5rCmqOIyn2GRARqDSN6PfDJw=.f9ed4c68-8eb8-4ad6-b132-39356d5445a6@github.com>
Message-ID: <rtGaftfACpUVMRmgjMDRs4qdx6GoS0ZCb_-ZSkfcCNY=.f405ece0-a9b3-4c12-a1a2-8ee4d9a98388@github.com>

On Fri, 24 May 2024 07:24:13 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> When building with ubsan enabled (--enable-uban) on Linux x86_64 and doing jtreg tests afterwards I run into this error :
>> 
>> /jdk/src/java.base/unix/native/libjava/ProcessImpl_md.c:562:5: runtime error: null pointer passed as argument 2, which is declared to never be null
>>     #0 0x7fd95bec78d8 in spawnChild /jdk/src/java.base/unix/native/libjava/ProcessImpl_md.c:562
>>     #1 0x7fd95bec78d8 in startChild /jdk/src/java.base/unix/native/libjava/ProcessImpl_md.c:612
>>     #2 0x7fd95bec78d8 in Java_java_lang_ProcessImpl_forkAndExec /jdk/src/java.base/unix/native/libjava/ProcessImpl_md.c:712
>>     #3 0x7fd93797a06d (<unknown module>)
>> 
>> this is the memcpy call getting an unexpected null pointer :
>>     memcpy(buf+offset, c->pdir, sp.dirlen); gets a second parameter null.
>> Something similar was discussed and fixed here https://bugs.python.org/issue27570 for Python .
>> 
>> Similar issue in OpenJDK _ 
>> https://bugs.openjdk.org/browse/JDK-8332473
>> 8332473: ubsan: growableArray.hpp:290:10: runtime error: null pointer passed as argument 1, which is declared to never be null
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   handle special case that memcpy src is NULL but a len larger than 0 was given

I also think that the `sp.dirlen > 0` check is not necessary, but I'm ok with this version, too.

-------------

Marked as reviewed by mdoerr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19329#pullrequestreview-2077166773

From yzheng at openjdk.org  Fri May 24 15:12:28 2024
From: yzheng at openjdk.org (Yudi Zheng)
Date: Fri, 24 May 2024 15:12:28 GMT
Subject: RFR: 8327964: Simplify BigInteger.implMultiplyToLen intrinsic [v7]
In-Reply-To: <Z5U-3OSq9_rd0t6DHNRhjF3LHtc9b6orz-mcQ4Uqzl8=.c4f0a0b8-9e10-4505-82f7-7d3a82929d22@github.com>
References: <Z5U-3OSq9_rd0t6DHNRhjF3LHtc9b6orz-mcQ4Uqzl8=.c4f0a0b8-9e10-4505-82f7-7d3a82929d22@github.com>
Message-ID: <9FFOmfnJsAIg1KJN0RcpDmAzpn68k4QBvFifeazLjmc=.dc821eea-3423-4a34-bcfc-217183169352@github.com>

> Moving array construction within BigInteger.implMultiplyToLen intrinsic candidate to its caller simplifies the intrinsic implementation in JIT compiler.

Yudi Zheng has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains eight additional commits since the last revision:

 - Merge remote-tracking branch 'upstream/master' into JDK-8327964
 - address comments.
 - address comments.
 - address comment.
 - address comment.
 - address comment.
 - address comment.
 - Simplify BigInteger.implMultiplyToLen intrinsic

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/18226/files
  - new: https://git.openjdk.org/jdk/pull/18226/files/7c6023f8..c719e0a9

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18226&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18226&range=05-06

  Stats: 560567 lines in 6784 files changed: 132593 ins; 81763 del; 346211 mod
  Patch: https://git.openjdk.org/jdk/pull/18226.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18226/head:pull/18226

PR: https://git.openjdk.org/jdk/pull/18226

From dfuchs at openjdk.org  Fri May 24 15:22:05 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 24 May 2024 15:22:05 GMT
Subject: RFR: 8331670: Deprecate the Memory-Access Methods in
 sun.misc.Unsafe for Removal [v3]
In-Reply-To: <ENm9bBCzUHGfXN_heTLJXeoiCjCMAciOlbxOnlFM59s=.496c5cc9-5335-497e-9f9f-448acb302c14@github.com>
References: <9FyO4QpCtH2CNkUEE78_Jjd9xs3bv3WJo16jyowHOvY=.e7131b91-37bb-4624-a60e-72a427a24c92@github.com>
 <ENm9bBCzUHGfXN_heTLJXeoiCjCMAciOlbxOnlFM59s=.496c5cc9-5335-497e-9f9f-448acb302c14@github.com>
Message-ID: <NNXzf8ApZAt6xWRmj1bxVpk0GVpirgYYh5STypd_2SI=.6fca1210-784b-4b0c-9803-7447da34f436@github.com>

On Tue, 21 May 2024 07:26:17 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> This is the implementation changes for JEP 471.
>> 
>> The methods in sun.misc.Unsafe for on-heap and off-heap access are deprecated for removal. This means a removal warning at compile time. No methods have been removed. A deprecated message is added to each of the methods but unlikely to be seen as the JDK does not generate or publish the API docs for this class.
>> 
>> A new command line option --sun-misc-unsafe-memory-access=$value is introduced to allow or deny access to these methods. The default proposed for JDK 23 is "allow" so no change in behavior compared to JDK 22 or previous releases.
>> 
>> A new test is added to test the command line option settings. The existing micros for FFM that use Unsafe are updated to suppress the removal warning at compile time. A new micro is introduced with a small sample of methods to ensure the changes doesn't cause any perf regressions ([sample results](https://cr.openjdk.org/~alanb/8331670-results.txt)).
>> 
>> For now, the changes include the update to the man page for the "java" command. It might be that this has to be separated out so that it goes with other updates in the release.
>
> Alan Bateman 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
>  - Add removal to DISABLED_WARNINGS
>    Fail at startup if bad value specified to option
>  - Merge
>  - Update man page
>  - Update man page
>  - Fix comment
>  - Merge
>  - Merge
>  - Whitespace
>  - Initial commit

src/jdk.unsupported/share/classes/sun/misc/Unsafe.java line 1750:

> 1748:     }
> 1749: 
> 1750:     // Instructure for --sun-misc-unsafe-memory-access=<value> command line option.

Suggestion:

    // Infrastructure for --sun-misc-unsafe-memory-access=<value> command line option.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19174#discussion_r1613644783

From kvn at openjdk.org  Fri May 24 15:25:11 2024
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Fri, 24 May 2024 15:25:11 GMT
Subject: RFR: 8320448: Accelerate IndexOf using AVX2 [v33]
In-Reply-To: <D8_haA3HGt72E96jB_5XRfRMmtMX8QeeZ7yfXOMklYU=.88d509be-4795-49ce-987b-1d968280237e@github.com>
References: <uWi4QxH31hL93771gkl_GgvP0m84IRSoR_1Yi8hD17E=.bc6ed458-7081-4c3f-9348-f59358fa05a4@github.com>
 <kE-TMUMyr6ADsj3wtDB9RlLnXaJFbFzmd7cikzCEuSg=.490d5dd5-eaa8-4137-8e00-7d5de1efb598@github.com>
 <GkGAR2YTtCDe_xFo2a7MxxJyoo-dsgghT9TvqfntN3c=.e40c4157-c48d-4454-b08e-17d6eb9b85a1@github.com>
 <nxpwP6Q_co_mHw7hIyjBjPSjuR6HUc3-ioT80k0tpqE=.fca7f3a5-a511-481c-b630-abeb4402268c@github.com>
 <BfYSarY-tQu34szlCk9qBFTIPR1TlmM5quTXqmoZoGI=.de6da9a2-3ef7-4e1c-8de4-dea5bf134d0f@github.com>
 <Y5yF2Y5MfT6Cz-mhe3qr68Bstkt1ODKOO-4NIh4yeCo=.6675b3fa-12f7-4201-8349-38828242660b@github.com>
 <D8_haA3HGt72E96jB_5XRfRMmtMX8QeeZ7yfXOMklYU=.88d509be-4795-49ce-987b-1d968280237e@github.com>
Message-ID: <lYFKdLvlpIJDVWFOfa6pEvEWyU4UZxrClN9CSpKRcMw=.eb6c2ddb-069b-40fa-b462-a43bb30cfd34@github.com>

On Fri, 24 May 2024 14:49:05 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> Just did the experiment and it turns out that `mov64(r15, (int64_t)small_jump_table)` and `lea(r15, ExternalAddress(small_jump_table))` produce exactly the same code:
>> 
>> `0x00007fffe463d68b:  49 bf a0 d5 63 e4 ff 7f 00 00   movabs r15,0x7fffe463d5a0`
>> 
>> The code in `MacroAssembler` for `lea` calls `mov_literal64` with no check for whether it can be ip-relative.
>> 
>> I tried doing it myself via `leaq(r15, Address(rip, (int64_t)small_jump_table - (int64_t)(__ pc())))` but there is no definition in `register_x86.hpp` for register `rip`.  So I'm not sure exactly how to produce RIP-relative addressing.
>
> Thanks for checking. Well I know that the `MacroAssembler::movdqu(XMMRegister dst, AddressLiteral src, Register rscratch)` method actually generates rip-relative addresses. Maybe we could copy some of that code.

Use `lea` and `InternalAddress()` for referencing jump tables since the addresses are in the same code section.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1613648648

From sgibbons at openjdk.org  Fri May 24 15:32:26 2024
From: sgibbons at openjdk.org (Scott Gibbons)
Date: Fri, 24 May 2024 15:32:26 GMT
Subject: RFR: 8320448: Accelerate IndexOf using AVX2 [v37]
In-Reply-To: <uWi4QxH31hL93771gkl_GgvP0m84IRSoR_1Yi8hD17E=.bc6ed458-7081-4c3f-9348-f59358fa05a4@github.com>
References: <uWi4QxH31hL93771gkl_GgvP0m84IRSoR_1Yi8hD17E=.bc6ed458-7081-4c3f-9348-f59358fa05a4@github.com>
Message-ID: <4xYUBsOJ_eDSuj6w9AjUo_6gFN_9piWR-ChLrHQoXl4=.88756684-8e9c-48e3-8b59-f5f684b81cde@github.com>

> Re-write the IndexOf code without the use of the pcmpestri instruction, only using AVX2 instructions.  This change accelerates String.IndexOf on average 1.3x for AVX2.  The benchmark numbers:
> 
> 
> Benchmark	                                               Score		Latest		
> StringIndexOf.advancedWithMediumSub   343.573		317.934		0.925375393x
> StringIndexOf.advancedWithShortSub1	  1039.081		1053.96		1.014319384x
> StringIndexOf.advancedWithShortSub2	      55.828		110.541		1.980027943x
> StringIndexOf.constantPattern	                9.361		11.906		1.271872663x
> StringIndexOf.searchCharLongSuccess	        4.216		4.218		1.000474383x
> StringIndexOf.searchCharMediumSuccess	3.133		3.216		1.02649218x
> StringIndexOf.searchCharShortSuccess	3.76		        3.761		1.000265957x
> StringIndexOf.success	                                9.186		9.713		1.057369911x
> StringIndexOf.successBig	                      14.341		46.343		3.231504079x
> StringIndexOfChar.latin1_AVX2_String	  6220.918		12154.52		1.953814533x
> StringIndexOfChar.latin1_AVX2_char	  5503.556		5540.044		1.006629895x
> StringIndexOfChar.latin1_SSE4_String	  6978.854		6818.689		0.977049957x
> StringIndexOfChar.latin1_SSE4_char	  5657.499		5474.624		0.967675646x
> StringIndexOfChar.latin1_Short_String	  7132.541		6863.359		0.962260014x
> StringIndexOfChar.latin1_Short_char	16013.389	      16162.437		1.009307711x
> StringIndexOfChar.latin1_mixed_String	  7386.123	      14771.622		1.999915517x
> StringIndexOfChar.latin1_mixed_char	  9901.671		9782.245		0.987938803

Scott Gibbons has updated the pull request incrementally with one additional commit since the last revision:

  mov64 => lea(InternalAddress)

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/16753/files
  - new: https://git.openjdk.org/jdk/pull/16753/files/1a71eb10..5d10a20b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16753&range=36
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16753&range=35-36

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/16753.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16753/head:pull/16753

PR: https://git.openjdk.org/jdk/pull/16753

From sgibbons at openjdk.org  Fri May 24 15:36:12 2024
From: sgibbons at openjdk.org (Scott Gibbons)
Date: Fri, 24 May 2024 15:36:12 GMT
Subject: RFR: 8320448: Accelerate IndexOf using AVX2 [v33]
In-Reply-To: <D8_haA3HGt72E96jB_5XRfRMmtMX8QeeZ7yfXOMklYU=.88d509be-4795-49ce-987b-1d968280237e@github.com>
References: <uWi4QxH31hL93771gkl_GgvP0m84IRSoR_1Yi8hD17E=.bc6ed458-7081-4c3f-9348-f59358fa05a4@github.com>
 <kE-TMUMyr6ADsj3wtDB9RlLnXaJFbFzmd7cikzCEuSg=.490d5dd5-eaa8-4137-8e00-7d5de1efb598@github.com>
 <GkGAR2YTtCDe_xFo2a7MxxJyoo-dsgghT9TvqfntN3c=.e40c4157-c48d-4454-b08e-17d6eb9b85a1@github.com>
 <nxpwP6Q_co_mHw7hIyjBjPSjuR6HUc3-ioT80k0tpqE=.fca7f3a5-a511-481c-b630-abeb4402268c@github.com>
 <BfYSarY-tQu34szlCk9qBFTIPR1TlmM5quTXqmoZoGI=.de6da9a2-3ef7-4e1c-8de4-dea5bf134d0f@github.com>
 <Y5yF2Y5MfT6Cz-mhe3qr68Bstkt1ODKOO-4NIh4yeCo=.6675b3fa-12f7-4201-8349-38828242660b@github.com>
 <D8_haA3HGt72E96jB_5XRfRMmtMX8QeeZ7yfXOMklYU=.88d509be-4795-49ce-987b-1d968280237e@github.com>
Message-ID: <xdDp4nAAOMal3mTMvlUohZm-hKfMWewOFB3LUK1VkUU=.10eaee6e-aee6-4ea5-a6fe-64d5c2f411de@github.com>

On Fri, 24 May 2024 14:49:05 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> Just did the experiment and it turns out that `mov64(r15, (int64_t)small_jump_table)` and `lea(r15, ExternalAddress(small_jump_table))` produce exactly the same code:
>> 
>> `0x00007fffe463d68b:  49 bf a0 d5 63 e4 ff 7f 00 00   movabs r15,0x7fffe463d5a0`
>> 
>> The code in `MacroAssembler` for `lea` calls `mov_literal64` with no check for whether it can be ip-relative.
>> 
>> I tried doing it myself via `leaq(r15, Address(rip, (int64_t)small_jump_table - (int64_t)(__ pc())))` but there is no definition in `register_x86.hpp` for register `rip`.  So I'm not sure exactly how to produce RIP-relative addressing.
>
> Thanks for checking. Well I know that the `MacroAssembler::movdqu(XMMRegister dst, AddressLiteral src, Register rscratch)` method actually generates rip-relative addresses. Maybe we could copy some of that code.

Changed to `lea` with `InternalAddress()`.  Generates the exact same code, but makes more sense.  I looked at `movdqu` and see no code that generates RIP-relative loads.  It merely checks `reachable()` and adds an intermediate `lea` if not reachable.  @djelinski can you clarify please?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1613665756

From naoto at openjdk.org  Fri May 24 15:38:16 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 24 May 2024 15:38:16 GMT
Subject: RFR: 8332084: Ensure JdkConsoleImpl.restoreEcho visibility in a
 shutdown hook [v9]
In-Reply-To: <9JTWc3FRpfbILlSHlmIU_dL5IE69RTxnSIAOdIte15I=.5854a48f-21d7-42c9-adb7-5e3ed40d1211@github.com>
References: <9JTWc3FRpfbILlSHlmIU_dL5IE69RTxnSIAOdIte15I=.5854a48f-21d7-42c9-adb7-5e3ed40d1211@github.com>
Message-ID: <E3m3-N2jb64-I6skgISoujivQNFUWSYcbVqhaa17ic0=.cf3879ac-3497-472d-9909-efdb93f75740@github.com>

> Making sure `restoreEcho` correctly reflects the state in the shutdown thread, which differs from the application's thread that issues the `readPassword()` method.

Naoto Sato 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 11 additional commits since the last revision:

 - Merge branch 'master' into JDK-8332084-restoreEcho-readLock
 - Used a dedicate lock for restoreEcho
 - Merge branch 'master' into JDK-8332084-restoreEcho-readLock
 - Merge branch 'master' into JDK-8332084-restoreEcho-readLock
 - copyright year
 - Merge branch 'master' into JDK-8332084-restoreEcho-readLock
 - get/setEcho()
 - Addresses a review comment
 - Replaced another unused exception with _
 - Update src/java.base/share/classes/jdk/internal/io/JdkConsoleImpl.java
   
   Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com>
 - ... and 1 more: https://git.openjdk.org/jdk/compare/472fb9f3...69ec27d6

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19184/files
  - new: https://git.openjdk.org/jdk/pull/19184/files/f69f747a..69ec27d6

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19184&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19184&range=07-08

  Stats: 14344 lines in 304 files changed: 9600 ins; 3407 del; 1337 mod
  Patch: https://git.openjdk.org/jdk/pull/19184.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19184/head:pull/19184

PR: https://git.openjdk.org/jdk/pull/19184

From naoto at openjdk.org  Fri May 24 15:45:22 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 24 May 2024 15:45:22 GMT
Subject: RFR: 8332161: Test restoring echo in the Console implementation
 (java.base) [v3]
In-Reply-To: <aSxuvnY7ghWwuDuegcWKJKlL_3KUCdIS_jHgTsn43ow=.b4d2e8d9-ffea-4318-9004-27b18298436e@github.com>
References: <aSxuvnY7ghWwuDuegcWKJKlL_3KUCdIS_jHgTsn43ow=.b4d2e8d9-ffea-4318-9004-27b18298436e@github.com>
Message-ID: <c6rGJiU5WFQny-Tu9Od5tKr_DIqkJc6G_1AbiDkLe3g=.14d2ddc7-115d-48fa-b16e-891b5851a2f6@github.com>

> This test intends to verify the behavior of JdkConsole for the java.base module, wrt restoring the echo. The test assumes the internal methods that sets/gets the echo status of the platform.

Naoto Sato 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 seven additional commits since the last revision:

 - fixing typo
 - Merge branch 'JDK-8332084-restoreEcho-readLock' into JDK-8332161-restoreEcho-Test
 - leftover typo
 - get/setEcho() -> echo()
 - Merge branch 'JDK-8332084-restoreEcho-readLock' into JDK-8332161-restoreEcho-Test
 - Merge branch 'JDK-8332084-restoreEcho-readLock' into JDK-8332161-restoreEcho-Test
 - initial commit

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19315/files
  - new: https://git.openjdk.org/jdk/pull/19315/files/ad4a4e47..1cd88c61

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19315&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19315&range=01-02

  Stats: 14345 lines in 305 files changed: 9600 ins; 3407 del; 1338 mod
  Patch: https://git.openjdk.org/jdk/pull/19315.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19315/head:pull/19315

PR: https://git.openjdk.org/jdk/pull/19315

From egahlin at openjdk.org  Fri May 24 15:52:02 2024
From: egahlin at openjdk.org (Erik Gahlin)
Date: Fri, 24 May 2024 15:52:02 GMT
Subject: RFR: 8331876: JFR: Move file read and write events to java.base
 [v3]
In-Reply-To: <HFfB0s4iYLwcSMYeKcsJvszuA0pTj1uQ-duKsmfHX4I=.a021f0d1-0e33-4a2d-a7b4-327143611a29@github.com>
References: <DDe0bKCC86AawVl7RylZ74uvvLBr2Zljpkcmxx1_WEU=.61cc10c6-b635-42dd-a850-b32ae1d68585@github.com>
 <SejX7NAvWNjrhDEN8uDf4oikQDBRclWXDg1fN5FCpkc=.7de48c6f-0af2-4bf4-a743-6e173d950d52@github.com>
 <DgjIOZTfztdSEeODuNZw5MmzsiohA82hhllWCceyPyU=.7bda36a1-e26d-4d7e-822a-e443d3cbc0df@github.com>
 <khrP38H7DBIyftQZtZt0CRXeH1ZkpOCjiRNvFTs3LSI=.fd62aba9-5153-4521-84e4-241b8a352720@github.com>
 <zGenHEqjgT6f_P_VtwfKbmzBeQoArW8MHwfAa6uVGVY=.eb912b9b-3f02-4cac-8d96-e1bdbaaea2b8@github.com>
 <wluFwF2Nhgjz-yspRYtEXIJ6jEiWm9imPd6CZlwYt6Y=.991f1032-1f5a-4762-8e5b-edc74d513e88@github.com>
 <UBAcBKmhmCkeevxrteAThIEvD8YNBWFrUa_qffEng14=.c50dbe19-3465-4385-9fe4-8c284a0b116e@github.com>
 <hCLpZtC0PzTKDqSFbBympxsb4A3Sta3G3N2Ec8JfsSs=.2c57b9ff-e81d-42a0-8384-3663b14192ca@github.com>
 <6jsW4CF22T2JlhtRKmS04_KXxr-aJxIiMyFwzWlM-pU=.b27ed11e-bd19-4823-a795-7f578b812d56@github.com>
 <HFfB0s4iYLwcSMYeKcsJvszuA0pTj1uQ-duKsmfHX4I=.a021f0d1-0e33-4a2d-a7b4-327143611a29@github.com>
Message-ID: <3tJRzBsJk5HIVu-Vy4YpxgnOY9GcAlkYNn__mLNTqRk=.1f4d38e3-966c-4580-99d5-2f39710a7056@github.com>

On Tue, 21 May 2024 22:41:12 GMT, Stuart Marks <smarks at openjdk.org> wrote:

>> I think `if (jfrTracing && FileReadEvent.enabled())` would be more readable as it would avoid calling going through the traceXXX methods when the flag is enabled but the specific event is not enabled.
>
> Collapsing the extra layer of methods and combining the test into
> 
>     if (jfrTracing && FileReadEvent.enabled())
> 
> would indeed keep things a little neater.
> 
> I'm still questioning the need for `jfrTracing` at all. There's the matter of how this boolean gets set and unset, and whether this is done in a way that comports with the memory model. Setting this aside, is the only benefit that it avoids loading an extra class at JVM startup time (without JFR)? In this case that would be the `FileReadEvent` class, which is the stub class in `jdk.internal.event`. Wouldn't this class be in the CDS archive, making it not worth the effort of bringing up this new `jfrTracing` mechanism simply to avoid loading it unnecessarily?
> 
> I observe that in JDK 22 some (but not all) of the event classes in `jdk.internal.event` seem to be present in the CDS archive. These include various virtual thread events.

I don't think issue is so much the overhead of loading (one or more) additional classes without JFR, even if it causes a extremely small regression, but the added overhead added to JFR when trying to fix the regression.

I did an experiment with:

`if (FlightRecorder.enabled && FileReadEvent.enabled())`

and it passes JFR tests and tier1/tier2. I don't think `FlightRecorder.enabled` needs to be used on every event class, but it would be good to use on event classes loaded during startup, both for safety reasons and to lower overhead of JFR startup. The `jfrTracing` flag works as well, but it is perhaps harder to comprehend and requires an additional static boolean in every class, which does clutter things up.

I can push Alan's suggestion of uniting the checks into one if-statement. It may help to see how it  looks.

Virtual thread events are typically loaded in main, after JFR has started, and not an issue unless `jcmd JFR.start `is used, which is not that common.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19129#discussion_r1613687099

From asotona at openjdk.org  Fri May 24 16:01:09 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Fri, 24 May 2024 16:01:09 GMT
Subject: Integrated: 8331291: java.lang.classfile.Attributes class performs a
 lot of static initializations
In-Reply-To: <SHIvjbwCWBPERKxlytEsY_O_kEiJbSeEmSusuDwjTIw=.ae8dd21e-a822-476e-9760-dd489532dbf1@github.com>
References: <SHIvjbwCWBPERKxlytEsY_O_kEiJbSeEmSusuDwjTIw=.ae8dd21e-a822-476e-9760-dd489532dbf1@github.com>
Message-ID: <b5A6WpCmYZnEQC1JJnx5FQI_fxXtwnyhQ2p6jd69alQ=.75f62c62-e4c9-403d-9845-b7ed211599f1@github.com>

On Mon, 29 Apr 2024 18:48:53 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> Hi,
> During performance optimization work on Class-File API as JDK lambda generator we found some static initialization killers.
> One of them is `java.lang.classfile.Attributes` with tens of static fields initialized with individual attribute mappers, and common set of all mappers, and static map from attribute names to the mappers.
> 
> I propose to turn all the static fields into lazy-initialized static methods and remove `PREDEFINED_ATTRIBUTES` and `standardAttribute(Utf8Entry name)` static mapping method from the `Attributes` API class.
>  
> Please let me know your comments or objections and please review the [PR](https://github.com/openjdk/jdk/pull/19006) and [CSR](https://bugs.openjdk.org/browse/JDK-8331414), so we can make it into 23.
> 
> Thank you,
> Adam

This pull request has now been integrated.

Changeset: cfdc64fc
Author:    Adam Sotona <asotona at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/cfdc64fcb43e3b261dddc6cc6947235a9e76154e
Stats:     2285 lines in 149 files changed: 961 ins; 615 del; 709 mod

8331291: java.lang.classfile.Attributes class performs a lot of static initializations

Reviewed-by: liach, redestad, vromero

-------------

PR: https://git.openjdk.org/jdk/pull/19006

From smarks at openjdk.org  Fri May 24 16:16:07 2024
From: smarks at openjdk.org (Stuart Marks)
Date: Fri, 24 May 2024 16:16:07 GMT
Subject: RFR: 8332084: Ensure JdkConsoleImpl.restoreEcho visibility in a
 shutdown hook [v9]
In-Reply-To: <E3m3-N2jb64-I6skgISoujivQNFUWSYcbVqhaa17ic0=.cf3879ac-3497-472d-9909-efdb93f75740@github.com>
References: <9JTWc3FRpfbILlSHlmIU_dL5IE69RTxnSIAOdIte15I=.5854a48f-21d7-42c9-adb7-5e3ed40d1211@github.com>
 <E3m3-N2jb64-I6skgISoujivQNFUWSYcbVqhaa17ic0=.cf3879ac-3497-472d-9909-efdb93f75740@github.com>
Message-ID: <tKNt1HT6BxTILHz7pXGCHvG90ZBWrvF04yajtxGf7Qw=.ffb390ea-5bbd-4dd5-b23a-0c8944d80acc@github.com>

On Fri, 24 May 2024 15:38:16 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Making sure `restoreEcho` correctly reflects the state in the shutdown thread, which differs from the application's thread that issues the `readPassword()` method.
>
> Naoto Sato 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 11 additional commits since the last revision:
> 
>  - Merge branch 'master' into JDK-8332084-restoreEcho-readLock
>  - Used a dedicate lock for restoreEcho
>  - Merge branch 'master' into JDK-8332084-restoreEcho-readLock
>  - Merge branch 'master' into JDK-8332084-restoreEcho-readLock
>  - copyright year
>  - Merge branch 'master' into JDK-8332084-restoreEcho-readLock
>  - get/setEcho()
>  - Addresses a review comment
>  - Replaced another unused exception with _
>  - Update src/java.base/share/classes/jdk/internal/io/JdkConsoleImpl.java
>    
>    Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com>
>  - ... and 1 more: https://git.openjdk.org/jdk/compare/b2ea52b6...69ec27d6

Latest updates look good.

-------------

Marked as reviewed by smarks (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19184#pullrequestreview-2077341454

From asotona at openjdk.org  Fri May 24 16:17:41 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Fri, 24 May 2024 16:17:41 GMT
Subject: RFR: 8320396: Class-File API ClassModel::verify should include
 checks from hotspot/share/classfile/classFileParser.cpp [v9]
In-Reply-To: <0a66asWcJ4_zBrjmReA18BZmsovN1ZeJRRSAPZDMZmo=.5bada03f-d88d-46cd-962d-c1e42c3048c1@github.com>
References: <0a66asWcJ4_zBrjmReA18BZmsovN1ZeJRRSAPZDMZmo=.5bada03f-d88d-46cd-962d-c1e42c3048c1@github.com>
Message-ID: <Kdd6IcPvA1Xn-444dkSMQN5HVRCMn2JmgqjQZbNQ9yc=.f7198271-db19-415a-99df-7c0c9e014252@github.com>

> ClassFile API `jdk.internal.classfile.verifier.VerifierImpl` performed only bytecode-level class verification.
> This patch adds `jdk.internal.classfile.verifier.ParserVerifier` with additional class checks inspired by `hotspot/share/classfile/classFileParser.cpp`.
> 
> Also new `VerifierSelfTest::testParserVerifier` has been added.
> 
> Please review.
> 
> Thanks,
> Adam

Adam Sotona has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 37 commits:

 - fixed ParserVerifier and VerifierSelfTest
 - Merge branch 'master' into JDK-8320396-verifier-extension
 - added verification of TypeAnnotation attributes
 - added verification of SMT attribute
 - added verification of module-related attributes
 - applied the suggested changes
 - applied the suggested changes
 - fixed error thrown by VerifierImpl
 - applied suggested changes
 - Merge branch 'master' into JDK-8320396-verifier-extension
 - ... and 27 more: https://git.openjdk.org/jdk/compare/cfdc64fc...b352b794

-------------

Changes: https://git.openjdk.org/jdk/pull/16809/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16809&range=08
  Stats: 869 lines in 6 files changed: 835 ins; 7 del; 27 mod
  Patch: https://git.openjdk.org/jdk/pull/16809.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16809/head:pull/16809

PR: https://git.openjdk.org/jdk/pull/16809

From asotona at openjdk.org  Fri May 24 16:24:13 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Fri, 24 May 2024 16:24:13 GMT
Subject: RFR: 8294960: Convert java.base/java.lang.invoke package to use
 the Classfile API to generate lambdas and method handles [v13]
In-Reply-To: <sP2SGhfcyggOAfbQT4Cm_lVg2Fsz3Z24PIoy2DX8WUg=.0aef65de-43fe-4140-b81d-11013c33529b@github.com>
References: <sP2SGhfcyggOAfbQT4Cm_lVg2Fsz3Z24PIoy2DX8WUg=.0aef65de-43fe-4140-b81d-11013c33529b@github.com>
Message-ID: <CCyED_T1nhSWkJ9K9V1fBozMWXVenmhdjdsHnp1sULc=.954183da-d2ed-4d46-8b33-d1cd268d5419@github.com>

> java.base java.lang.invoke package heavily uses ASM to generate lambdas and method handles.
> 
> This patch converts ASM calls to Classfile API.
> 
> This PR is continuation of https://github.com/openjdk/jdk/pull/12945
> 
> Any comments and suggestions are welcome.
> 
> Please review.
> 
> Thank you,
> Adam

Adam Sotona has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 23 commits:

 - Merge branch 'master' into JDK-8294960-invoke
   
   # Conflicts:
   #	src/java.base/share/classes/java/lang/classfile/Attributes.java
 - fixed CodeBuilder use in j.l.invoke
 - Merge branch 'master' into JDK-8294960-invoke
 - Merge pull request #4 from cl4es/boxunbox_holder
   
   Only create box/unbox MethodRefEntries on request
 - Only create box/unbox MethodRefEntries on request
 - Merge pull request #3 from cl4es/minor_init_improvements
   
   Reduce init overhead of InvokeBytecodeGenerator and StackMapGenerator
 - Remove stray MRE_LF_interpretWithArguments
 - Reduce init overhead of InvokeBytecodeGenerator and StackMapGenerator
 - Deferred initialization of attributes map by moving into a holder class
   
   Co-authored-by: Claes Redestad <redestad at openjdk.org>
 - Merge branch 'master' into JDK-8294960-invoke
 - ... and 13 more: https://git.openjdk.org/jdk/compare/cfdc64fc...e1dbabcb

-------------

Changes: https://git.openjdk.org/jdk/pull/17108/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17108&range=12
  Stats: 2113 lines in 10 files changed: 422 ins; 861 del; 830 mod
  Patch: https://git.openjdk.org/jdk/pull/17108.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17108/head:pull/17108

PR: https://git.openjdk.org/jdk/pull/17108

From joehw at openjdk.org  Fri May 24 16:36:32 2024
From: joehw at openjdk.org (Joe Wang)
Date: Fri, 24 May 2024 16:36:32 GMT
Subject: RFR: 8330542: Template for Creating Strict JAXP Configuration File
 [v14]
In-Reply-To: <v1bAYKgH9zfooXpvnBw4Vu2TIqHuKqqtSmgB0hiNp-Q=.31661a99-ecfc-4a05-8045-67b5f680db60@github.com>
References: <v1bAYKgH9zfooXpvnBw4Vu2TIqHuKqqtSmgB0hiNp-Q=.31661a99-ecfc-4a05-8045-67b5f680db60@github.com>
Message-ID: <-xQutVfz6r3JPZZnkO71_iimpzxhNvdoX8cpz8E7-X8=.5867b83a-ec89-4c69-ac7c-6bc11caeb93e@github.com>

> Add two sample configuration files:
> 
>   jaxp-strict.properties: used to set strict configuration, stricter than jaxp.properties in previous versions such as JDK 22
> 
>>   jaxp-compat.properties: used to regain compatibility from any more restricted configuration than previous versions such as JDK 22
> 
> Updated on 5/16/2024
> 
> Design change:
> The design is changed to include in the JDK two configuration files that are the default jaxp.properties and jaxp-strict.properties, instead of three, dropping jaxp-compat.properties.
> 
> Updated on 5/18/2024
> 
> Withdraw changes to jaxp.properties. The original idea was to match jaxp-strict.properties with regard to the properties. However, that change impact the configuration process, resulting in tests that verify the process to fail.
> 
> Updated on 5/23/2024
> 
> Provide a template `jaxp-strict.template` instead of a properties file. This template can be used to create custom configuration files.

Joe Wang has updated the pull request incrementally with one additional commit since the last revision:

  rename the template to jaxp-strict.properties.template

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/18831/files
  - new: https://git.openjdk.org/jdk/pull/18831/files/0de8ad69..714095d1

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18831&range=13
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18831&range=12-13

  Stats: 10 lines in 4 files changed: 0 ins; 0 del; 10 mod
  Patch: https://git.openjdk.org/jdk/pull/18831.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18831/head:pull/18831

PR: https://git.openjdk.org/jdk/pull/18831

From asotona at openjdk.org  Fri May 24 16:41:33 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Fri, 24 May 2024 16:41:33 GMT
Subject: RFR: 8332597: Remove redundant methods from
 j.l.classfile.ClassReader API [v2]
In-Reply-To: <UWBl0HMJIC4_22TkWuBhE9kd2F_l0eiPmpIx8rexFlU=.4f905822-ed5e-41be-b9d4-601af6a55eed@github.com>
References: <UWBl0HMJIC4_22TkWuBhE9kd2F_l0eiPmpIx8rexFlU=.4f905822-ed5e-41be-b9d4-601af6a55eed@github.com>
Message-ID: <YBwgwtTS-iUIA2rajoQ-wPQagUe1-7kf6yKQs7yVu60=.dafff0b2-8e92-491f-a652-de02c1648c85@github.com>

> j.l.classfile.ClassReader instance is exposed in the Class-File API through j.l.classfile.AttributeMapper::readAttribute method only.
> ClassReader only purpose is to serve as a tool for reading content of a custom attribute in a user-provided AttribtueMapper.
> It contains useful set of low-level class reading methods for user to implement a custom attribute content parser.
> 
> However methods ClassReader::thisClassPos and ClassReader::skipAttributeHolder are not necessary for a custom attribute content parsing and so redundant in the API.
> Class-File API implementation internally use these methods, however they should not be exposed in the API.
> 
> This patch removes the methods from the API.
> 
> Please review.
> 
> Thanks,
> Adam

Adam Sotona 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 JDK-8332597-classreader-redundancy
   
   # Conflicts:
   #	src/java.base/share/classes/jdk/internal/classfile/impl/ClassImpl.java
 - 8332597: Remove redundant methods from j.l.classfile.ClassReader API

-------------

Changes: https://git.openjdk.org/jdk/pull/19323/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19323&range=01
  Stats: 23 lines in 5 files changed: 0 ins; 17 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/19323.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19323/head:pull/19323

PR: https://git.openjdk.org/jdk/pull/19323

From joehw at openjdk.org  Fri May 24 16:47:04 2024
From: joehw at openjdk.org (Joe Wang)
Date: Fri, 24 May 2024 16:47:04 GMT
Subject: RFR: 8330542: Template for Creating Strict JAXP Configuration File
 [v14]
In-Reply-To: <-xQutVfz6r3JPZZnkO71_iimpzxhNvdoX8cpz8E7-X8=.5867b83a-ec89-4c69-ac7c-6bc11caeb93e@github.com>
References: <v1bAYKgH9zfooXpvnBw4Vu2TIqHuKqqtSmgB0hiNp-Q=.31661a99-ecfc-4a05-8045-67b5f680db60@github.com>
 <-xQutVfz6r3JPZZnkO71_iimpzxhNvdoX8cpz8E7-X8=.5867b83a-ec89-4c69-ac7c-6bc11caeb93e@github.com>
Message-ID: <GFjBEeCvQ6R_TYZE01PsGr0hFbgmHSP3E6DMJUc-Xt4=.153d677d-a04c-4b69-b999-1ffaf27a7ac1@github.com>

On Fri, 24 May 2024 16:36:32 GMT, Joe Wang <joehw at openjdk.org> wrote:

>> Add two sample configuration files:
>> 
>>   jaxp-strict.properties: used to set strict configuration, stricter than jaxp.properties in previous versions such as JDK 22
>> 
>>>   jaxp-compat.properties: used to regain compatibility from any more restricted configuration than previous versions such as JDK 22
>> 
>> Updated on 5/16/2024
>> 
>> Design change:
>> The design is changed to include in the JDK two configuration files that are the default jaxp.properties and jaxp-strict.properties, instead of three, dropping jaxp-compat.properties.
>> 
>> Updated on 5/18/2024
>> 
>> Withdraw changes to jaxp.properties. The original idea was to match jaxp-strict.properties with regard to the properties. However, that change impact the configuration process, resulting in tests that verify the process to fail.
>> 
>> Updated on 5/23/2024
>> 
>> Provide a template `jaxp-strict.template` instead of a properties file. This template can be used to create custom configuration files.
>
> Joe Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   rename the template to jaxp-strict.properties.template

Thanks Magnus, Alan. Renamed the template to jaxp-strict.properties.template.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18831#issuecomment-2129975324

From smarks at openjdk.org  Fri May 24 17:12:04 2024
From: smarks at openjdk.org (Stuart Marks)
Date: Fri, 24 May 2024 17:12:04 GMT
Subject: RFR: 8328821: Map.of().entrySet() mutators should throw
 UnsupportedOperationException
In-Reply-To: <np86XgOjE1gYESY--2_OXTPIvO1mvmJbD3UH-lIn9TY=.c4a288f1-0469-4cc6-a076-58bab04d24ad@github.com>
References: <np86XgOjE1gYESY--2_OXTPIvO1mvmJbD3UH-lIn9TY=.c4a288f1-0469-4cc6-a076-58bab04d24ad@github.com>
Message-ID: <DC8k4s7g04z-0KmtHyQ9jqlANHuI1cBQNsq6jGbthZY=.5e113e03-17cd-41b2-8467-26a4dc0243ed@github.com>

On Wed, 27 Mar 2024 17:36:28 GMT, Liam Miller-Cushon <cushon at openjdk.org> wrote:

> This change overrides mutator methods in the implementation returned by `Map.of().entrySet()` to throw `UnsupportedOperationException`.

Sorry for the delay, I'm still totally backlogged on other stuff. I can't commit to get this into JDK 23.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18522#issuecomment-2130014264

From naoto at openjdk.org  Fri May 24 17:21:15 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 24 May 2024 17:21:15 GMT
Subject: RFR: 8332084: Ensure JdkConsoleImpl.restoreEcho visibility in a
 shutdown hook [v10]
In-Reply-To: <9JTWc3FRpfbILlSHlmIU_dL5IE69RTxnSIAOdIte15I=.5854a48f-21d7-42c9-adb7-5e3ed40d1211@github.com>
References: <9JTWc3FRpfbILlSHlmIU_dL5IE69RTxnSIAOdIte15I=.5854a48f-21d7-42c9-adb7-5e3ed40d1211@github.com>
Message-ID: <Pv249eefDzgCeDKZUmZwNKBv4iLZDJ4b-Sn00k-lbg8=.c39dea59-356a-4072-a878-f3e2c20ea287@github.com>

> Making sure `restoreEcho` correctly reflects the state in the shutdown thread, which differs from the application's thread that issues the `readPassword()` method.

Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:

  Added comment for restoreEchoLock

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19184/files
  - new: https://git.openjdk.org/jdk/pull/19184/files/69ec27d6..d4b6e695

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19184&range=09
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19184&range=08-09

  Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/19184.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19184/head:pull/19184

PR: https://git.openjdk.org/jdk/pull/19184

From lmesnik at openjdk.org  Fri May 24 17:23:01 2024
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Fri, 24 May 2024 17:23:01 GMT
Subject: RFR: 8332885: Clarify failure_handler self-tests
In-Reply-To: <fSl5ksYZ89l98gCGy0q3jfhpoCO5UVBKlA5k7Fxt720=.886e149b-561d-4109-9e72-94346f02f25d@github.com>
References: <fSl5ksYZ89l98gCGy0q3jfhpoCO5UVBKlA5k7Fxt720=.886e149b-561d-4109-9e72-94346f02f25d@github.com>
Message-ID: <p5OwWWGOtYvxQdxb1ynN0X9n11A03wmmhm-XfGddVOs=.1a39a9a3-5fe9-4a3c-8cb7-ae952b84f151@github.com>

On Fri, 24 May 2024 12:16:25 GMT, Ludvig Janiuk <lujaniuk at openjdk.org> wrote:

> Adding commetns to clarify that the failure_handler selftests are intended to be run manually. Ideally this would include a more thorough description of the exepcted outputs, but this is what I have time to add right now.

Marked as reviewed by lmesnik (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/19393#pullrequestreview-2077481241

From lmesnik at openjdk.org  Fri May 24 17:31:02 2024
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Fri, 24 May 2024 17:31:02 GMT
Subject: RFR: 8332898: failure_handler: log directory of commands
In-Reply-To: <1QX0asjsisoy1ygDzWY1XaespvKbclWKms0Cf_eXqls=.189d31a0-d3ed-41a9-9ca9-8251e4e8edf7@github.com>
References: <1QX0asjsisoy1ygDzWY1XaespvKbclWKms0Cf_eXqls=.189d31a0-d3ed-41a9-9ca9-8251e4e8edf7@github.com>
Message-ID: <ijlrSexujg4UYFY6pV47T9eng_lxxMQv0xq8zMUY38U=.6e73a361-5e62-4ac6-a511-a9e335e97fe4@github.com>

On Fri, 24 May 2024 14:34:39 GMT, Ludvig Janiuk <lujaniuk at openjdk.org> wrote:

> Also log the directory in which the command used by failure_handler was executed. While often the same, it isn't always, and so it this should simplify troubleshooting for someone looking at this at a glance without being a failure_handler expert.
> 
> Example output after this change:
> 
> ----------------------------------------
> [2024-05-24 14:26:46] [/usr/bin/pmap, -p, 2233017] timeout=20000 in /<my-absolute-project-dir>/JTwork/scratch
> ----------------------------------------
> 
> before:
> 
> ----------------------------------------
> [2024-05-24 14:26:46] [/usr/bin/pmap, -p, 2233017] timeout=20000
> ----------------------------------------

Marked as reviewed by lmesnik (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/19396#pullrequestreview-2077492691

From naoto at openjdk.org  Fri May 24 17:54:09 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 24 May 2024 17:54:09 GMT
Subject: Integrated: 8332084: Ensure JdkConsoleImpl.restoreEcho visibility in a
 shutdown hook
In-Reply-To: <9JTWc3FRpfbILlSHlmIU_dL5IE69RTxnSIAOdIte15I=.5854a48f-21d7-42c9-adb7-5e3ed40d1211@github.com>
References: <9JTWc3FRpfbILlSHlmIU_dL5IE69RTxnSIAOdIte15I=.5854a48f-21d7-42c9-adb7-5e3ed40d1211@github.com>
Message-ID: <BSBR8Z-JkBSVckUocSByu6qrExx5taiuend1cr08mOo=.3d81c972-0621-4e1d-8361-1476fb4f4661@github.com>

On Fri, 10 May 2024 21:55:26 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Making sure `restoreEcho` correctly reflects the state in the shutdown thread, which differs from the application's thread that issues the `readPassword()` method.

This pull request has now been integrated.

Changeset: 236432db
Author:    Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/236432dbdb9bab4aece54c2fea08f055e5dbf97e
Stats:     18 lines in 1 file changed: 10 ins; 0 del; 8 mod

8332084: Ensure JdkConsoleImpl.restoreEcho visibility in a shutdown hook

Reviewed-by: prappo, joehw, smarks

-------------

PR: https://git.openjdk.org/jdk/pull/19184

From duke at openjdk.org  Fri May 24 18:00:47 2024
From: duke at openjdk.org (Oussama Louati)
Date: Fri, 24 May 2024 18:00:47 GMT
Subject: RFR: 8307818: Convert Indify tool to Classfile API [v9]
In-Reply-To: <tCFk9yrCtcoBnzvNIgceY0eOaXg9ZiN9nkCuhHIyMyw=.9cc5f994-8d35-411a-bb39-7c3f2ac34dda@github.com>
References: <tCFk9yrCtcoBnzvNIgceY0eOaXg9ZiN9nkCuhHIyMyw=.9cc5f994-8d35-411a-bb39-7c3f2ac34dda@github.com>
Message-ID: <ERPRn4imTD5OFe3XL2O99rBrkNqKMqeMU5HFp4YCgo8=.c80ad962-59fe-48f4-abad-89d19e882978@github.com>

> An indify tool in j.l.i tests (also in vmTestBase) convert some source-code private static methods with MT_ MH_, and INDY_ prefixes into MethodHandle, MethodType, and CallSite constants.
> It currently uses ad-hoc code to process class files and intends to migrate to ASM; but since we have the Classfile API, we can migrate to Classfile API instead.

Oussama Louati has updated the pull request incrementally with 19 additional commits since the last revision:

 - fix: fixed whitespaces
 - fix: fixed whitespaces
 - chore: used Class::descriptorString
 - remove: added removed test comments
 - remove: added removed test comments
 - remove: removed changes in tests
 - update: optimize imports and remove unnecessary utils
 - update: optimize imports
 - update: 5th patch of code review
 - update: 5th patch of code review
 - ... and 9 more: https://git.openjdk.org/jdk/compare/781c951d...2b8c94a7

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/18841/files
  - new: https://git.openjdk.org/jdk/pull/18841/files/781c951d..2b8c94a7

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18841&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18841&range=07-08

  Stats: 585 lines in 6 files changed: 49 ins; 338 del; 198 mod
  Patch: https://git.openjdk.org/jdk/pull/18841.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18841/head:pull/18841

PR: https://git.openjdk.org/jdk/pull/18841

From asotona at openjdk.org  Fri May 24 18:00:49 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Fri, 24 May 2024 18:00:49 GMT
Subject: RFR: 8307818: Convert Indify tool to Classfile API [v9]
In-Reply-To: <ERPRn4imTD5OFe3XL2O99rBrkNqKMqeMU5HFp4YCgo8=.c80ad962-59fe-48f4-abad-89d19e882978@github.com>
References: <tCFk9yrCtcoBnzvNIgceY0eOaXg9ZiN9nkCuhHIyMyw=.9cc5f994-8d35-411a-bb39-7c3f2ac34dda@github.com>
 <ERPRn4imTD5OFe3XL2O99rBrkNqKMqeMU5HFp4YCgo8=.c80ad962-59fe-48f4-abad-89d19e882978@github.com>
Message-ID: <P-UeDJ_ZCoCcTJKZMD2eu3IAmEsC1x9PyA77gAm1D8s=.1094b8b8-a01b-487f-a62c-3dcf5f46f9e2@github.com>

On Fri, 24 May 2024 17:57:28 GMT, Oussama Louati <duke at openjdk.org> wrote:

>> An indify tool in j.l.i tests (also in vmTestBase) convert some source-code private static methods with MT_ MH_, and INDY_ prefixes into MethodHandle, MethodType, and CallSite constants.
>> It currently uses ad-hoc code to process class files and intends to migrate to ASM; but since we have the Classfile API, we can migrate to Classfile API instead.
>
> Oussama Louati has updated the pull request incrementally with 19 additional commits since the last revision:
> 
>  - fix: fixed whitespaces
>  - fix: fixed whitespaces
>  - chore: used Class::descriptorString
>  - remove: added removed test comments
>  - remove: added removed test comments
>  - remove: removed changes in tests
>  - update: optimize imports and remove unnecessary utils
>  - update: optimize imports
>  - update: 5th patch of code review
>  - update: 5th patch of code review
>  - ... and 9 more: https://git.openjdk.org/jdk/compare/781c951d...2b8c94a7

I would recommend to use more high-level models of the Class-File API instead of filling the original code from a new source.
There are also some unnecessary reformats of the javadoc, which is very hard to review and forgotten debug prints.
For details see my inline comments.

Generally it is a move forward.

Changes requested by asotona (Reviewer).

test/jdk/java/lang/invoke/CallSiteTest.java line 96:

> 94:     }
> 95: 
> 96:     public static class MyCCS extends ConstantCallSite {

Any reason for this change?

test/jdk/java/lang/invoke/CallStaticInitOrder.java line 54:

> 52: 
> 53:     static int Init1Tick;
> 54:     public static class Init1 {

Is there a reason to change all the classes and methods to public?

test/jdk/java/lang/invoke/indify/Indify.java line 61:

> 59:  * meaning.
> 60:  * </p>
> 61:  *

Why is the javadoc reformatted?
It is not possible to review the changes if has changed.

test/jdk/java/lang/invoke/indify/Indify.java line 271:

> 269:                 switch (a) {
> 270:                 case "--java":
> 271:                     return;

Where this conditional code disappeared?

test/jdk/java/lang/invoke/indify/Indify.java line 352:

> 350:         if (verbose)  System.err.println("reading " + f);
> 351:         ClassModel model = parseClassFile(f);
> 352:         if (model == null) throw new IOException("Failed to parse class file: " + f.getName());

How it suppose to happen the model is null?

test/jdk/java/lang/invoke/indify/Indify.java line 354:

> 352:         if (model == null) throw new IOException("Failed to parse class file: " + f.getName());
> 353:         Logic logic = new Logic(model);
> 354:         if(logic.classModel == null) throw new IOException("Failed to create logic for class file: " + f.getName());

And null here again?

test/jdk/java/lang/invoke/indify/Indify.java line 383:

> 381:         if (verbose)  System.err.println("writing "+destFile);
> 382:         Files.write(destFile.toPath(), new_bytes);
> 383:         System.err.println("Wrote New ClassFile to: "+destFile);

This code assumes `dest` is always specified?
For me it looks like it diverges from the original behavior.

test/jdk/java/lang/invoke/indify/Indify.java line 438:

> 436:                 } catch (Exception ex) {
> 437:                     // pass error from reportPatternMethods, etc.
> 438:                     throw (RuntimeException) ex;

Casting all remaining exceptions to `RuntimeException` ?
I would suggest to keep the original code 
or include `RuntimeException` in the fall through section above and wrap all remaining exceptions into a `RuntimeException` to replicate the original behavior.

test/jdk/java/lang/invoke/indify/Indify.java line 470:

> 468:             Logic logic = new Logic(model);
> 469:             Boolean isChanged = logic.transform();
> 470:             if(!isChanged)  throw new IOException("No transformation has been done");

Throwing an exception when there is not change also significantly changes the original behavior.

test/jdk/java/lang/invoke/indify/Indify.java line 503:

> 501: 
> 502:                 Iterator<Instruction> instructionIterator =getInstructions(m).iterator();
> 503:                 final Stack<Boolean> shouldProceedAfterIndyAdded = new Stack<>();

What this stack of booleans suppose to do?

test/jdk/java/lang/invoke/indify/Indify.java line 540:

> 538:                         assert (i.sizeInBytes() == 3 || i2.sizeInBytes() == 3);
> 539:                         System.err.println("----------------------------------------------------------------Transforming Method INDY Instructions & Creating New ClassModels------------------------------------------------------------------}}}");
> 540:                         if (!quiet) System.err.println(":::Transfmoring the Method: "+ m.methodName() +" instruction: " + i + " invokedynamic: " + con.index() );

This debug print should be probably removed before integration.

test/jdk/java/lang/invoke/indify/Indify.java line 550:

> 548:                             if (e instanceof InvokeInstruction && Objects.equals(a1, a2)) {
> 549:                                 System.err.println(">> Removing instruction invokestatic for Method: " + ((InvokeInstruction) e).name());
> 550:                                 b.andThen(b);

What this suppose to do?

test/jdk/java/lang/invoke/indify/Indify.java line 553:

> 551:                             } else if (shouldProceed.peek() && e instanceof InvokeInstruction && ((InvokeInstruction) e).method().equals(((InvokeInstruction) i2).method())) {
> 552:                                 System.err.println(">> Removing instruction invokevirtual for Method: " + ((InvokeInstruction) e).name());
> 553:                                 b.andThen(b);

And this?

test/jdk/java/lang/invoke/indify/Indify.java line 572:

> 570:                     } else {
> 571:                         assert(i.sizeInBytes() == 3);
> 572:                         System.err.println("----------------------------------------------------------------Transforming Method LDC Instructions & Creating New ClassModels------------------------------------------------------------------}}}");

This debug print should be probably removed before integration.

test/jdk/java/lang/invoke/indify/Indify.java line 576:

> 574:                         codeTransform = (b, e) ->{
> 575:                             String a1 = null, a2 = null;
> 576:                             if(e instanceof InvokeInstruction){

Please use pattern matching and consolidate repeated `(e instanceof InvokeInstruction)`, followed by casting.

test/jdk/java/lang/invoke/indify/Indify.java line 578:

> 576:                         classTransform = ClassTransform.transformingMethodBodies(filter, codeTransform);
> 577:                         classModel = of().parse(
> 578:                              of().transform(classModel, classTransform));

What this transform (in the middle of instructions iteration) does?

test/jdk/java/lang/invoke/indify/Indify.java line 582:

> 580:                             if(e instanceof InvokeInstruction && Objects.equals(a1, a2)){
> 581:                                 System.err.println(":::Transfmoring the Method: "+ m.methodName() +" instruction: invokestatic " + ((InvokeInstruction) e).type() + " to ldc: " +  con.index() );
> 582:                                 b.constantInstruction(Opcode.LDC_W,  ((LoadableConstantEntry) con).constantValue());

`b.ldc((LoadableConstantEntry) con)` would do the same job, but so many blind casting is not a good pattern.

test/jdk/java/lang/invoke/indify/Indify.java line 599:

> 597:         ClassModel removePatternMethodsAndVerify(ClassModel classModel){
> 598: 
> 599:             ClassModel newClassModel = of(StackMapsOption.GENERATE_STACK_MAPS).parse(

`StackMapsOption.GENERATE_STACK_MAPS` is the default and it is not necessary to set it explicitly.

test/jdk/java/lang/invoke/indify/Indify.java line 610:

> 608:                     })
> 609:             );
> 610:             ClassHierarchyResolver classHierarchyResolver = classDesc -> ClassHierarchyResolver.ClassHierarchyInfo.ofInterface();

It is not necessary to fake the `ClassHierarchyResolver` for the verification if the above code generates stack maps and is able to resolve all necessary classes.

test/jdk/java/lang/invoke/indify/Indify.java line 645:

> 643:                         case GETSTATIC, GETFIELD, PUTSTATIC, PUTFIELD -> pops.replace("Q", type);
> 644:                         default -> {
> 645:                             if (!type.startsWith("("))

This is very low-level of bytecode instructions parsing. Class-File API already contains high-level models of the instructions and it would be worth to use that models or instead of the tricky up and down conversions and auxiliary structures describing the instructions.

test/jdk/java/lang/invoke/indify/Indify.java line 660:

> 658:          *
> 659:          * @return true if any marks were changed, false otherwise.
> 660:          */

This method does incremental analysis of the constant pool.
With Class-File API CP model it can be done in one pass, or even in no-pass and all requests to "marks" can be answered directly.

test/jdk/java/lang/invoke/indify/Indify.java line 678:

> 676:                     if (!Modifier.isPrivate(m.flags().flagsMask())) continue;
> 677:                     if (!Modifier.isStatic(m.flags().flagsMask())) continue;
> 678:                     if(nameAndTypeMark(m.methodName().index(), m.methodType().index()) == mark) {

Passing CP indexes instead of the entries (or maybe String values) is no more necessary.
Original code didn't have a full model of the constant pool.

test/jdk/java/lang/invoke/indify/Indify.java line 725:

> 723:                     }
> 724:                     if (entry instanceof IntegerEntry integerEntry) {
> 725:                         clb.constantPool().intEntry(integerEntry.intValue());

This whole code does effectively nothing and can be removed.
All the entries present in the `oldClassModel` are iterated and and re-entered into the same constant pool.

test/jdk/java/lang/invoke/indify/Indify.java line 809:

> 807:                     }
> 808: 
> 809:                     switch (poolEntry.tag()) {

I would recommend to convert this to a switch expression:

mark = switch (poolEntry) {
    case Utf8Entry utf -> nameMark(utf.stringValue());
    case NameAndTypeEntry nat -> nameAndTypeMark(nat.name(), nat.type());


Questionable is why to pass CP indexes to the auxiliary methods (for further entries lookup by index), when the pool entries contain all the necessary information.

test/jdk/java/lang/invoke/indify/Indify.java line 956:

> 954:                                                 case "double" -> 'D';
> 955:                                                 default -> throw new InternalError(argClass.toString());
> 956:                                             };

This code looks like composition of `ClassDesc`, I would look at `Class::descriptorString`

test/jdk/java/lang/invoke/indify/Indify.java line 1249:

> 1247:             } else {
> 1248:                 return null;
> 1249:             }

How does it happen that the argument might be a String or a StringEntry.

Also instead of:

if (x instanceof PoolEntry && ((PoolEntry) x).tag() == TAG_STRING) {
                 utf8Entry = ((StringEntry) x).utf8();

You can write:

if (x instanceof StringEntry se) {
                 utf8Entry = se.utf8();

test/jdk/java/lang/invoke/indify/Indify.java line 1273:

> 1271:             if(((con = args.get(argi)) instanceof MethodTypeEntry) || (con instanceof ClassEntry)){
> 1272:                 assert con instanceof MethodTypeEntry;
> 1273:                 type = ((MethodTypeEntry) con).descriptor();

This is a lot of low-level stuff, where a bunch of entries are filled into a List<Object> and then identified back as entries. It is very hard to read and debug, I would suggest to organize it a type-safe way.

test/jdk/java/lang/invoke/indify/Indify.java line 1334:

> 1332:                     if (x instanceof Float)   { x = poolBuilder.floatEntry((Float) x); }
> 1333:                     if (x instanceof Long)    { x = poolBuilder.longEntry((Long) x); }
> 1334:                     if (x instanceof Double)  { x = poolBuilder.doubleEntry((Double) x); }

This is a harder way, when you convert all the arguments into entries.
`ConstantPoolBuilder::bsmEntry(DirectMethodHandleDesc methodReference, List<ConstantDesc> arguments)` would do it for you.

test/jdk/java/lang/invoke/indify/Indify.java line 1368:

> 1366:             if (count == 0){
> 1367:                 poolBuilder.utf8Entry("BootstrapMethods");
> 1368:                 return specs;

It is not necessary to manually insert "BootstrapMethods" entry, Class-File API generates all the stuff if you add a bootstrap method, no matter if it is the first one or just another addition.

test/jdk/java/lang/invoke/indify/Indify.java line 1403:

> 1401:                     System.err.println(e.getMessage());
> 1402:                 }
> 1403:                 throw new IOException("Verification failed");

Is there a reason to verify source class files?

-------------

Changes requested by asotona (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18841#pullrequestreview-2070398734
PR Review: https://git.openjdk.org/jdk/pull/18841#pullrequestreview-2076472008
PR Review Comment: https://git.openjdk.org/jdk/pull/18841#discussion_r1609572765
PR Review Comment: https://git.openjdk.org/jdk/pull/18841#discussion_r1609572065
PR Review Comment: https://git.openjdk.org/jdk/pull/18841#discussion_r1609564032
PR Review Comment: https://git.openjdk.org/jdk/pull/18841#discussion_r1613228454
PR Review Comment: https://git.openjdk.org/jdk/pull/18841#discussion_r1609557109
PR Review Comment: https://git.openjdk.org/jdk/pull/18841#discussion_r1609557531
PR Review Comment: https://git.openjdk.org/jdk/pull/18841#discussion_r1613231918
PR Review Comment: https://git.openjdk.org/jdk/pull/18841#discussion_r1613245509
PR Review Comment: https://git.openjdk.org/jdk/pull/18841#discussion_r1613247462
PR Review Comment: https://git.openjdk.org/jdk/pull/18841#discussion_r1613250834
PR Review Comment: https://git.openjdk.org/jdk/pull/18841#discussion_r1609549832
PR Review Comment: https://git.openjdk.org/jdk/pull/18841#discussion_r1609555023
PR Review Comment: https://git.openjdk.org/jdk/pull/18841#discussion_r1609555309
PR Review Comment: https://git.openjdk.org/jdk/pull/18841#discussion_r1609548549
PR Review Comment: https://git.openjdk.org/jdk/pull/18841#discussion_r1609547516
PR Review Comment: https://git.openjdk.org/jdk/pull/18841#discussion_r1613256739
PR Review Comment: https://git.openjdk.org/jdk/pull/18841#discussion_r1609541900
PR Review Comment: https://git.openjdk.org/jdk/pull/18841#discussion_r1609536757
PR Review Comment: https://git.openjdk.org/jdk/pull/18841#discussion_r1609535430
PR Review Comment: https://git.openjdk.org/jdk/pull/18841#discussion_r1609527200
PR Review Comment: https://git.openjdk.org/jdk/pull/18841#discussion_r1613260699
PR Review Comment: https://git.openjdk.org/jdk/pull/18841#discussion_r1609520089
PR Review Comment: https://git.openjdk.org/jdk/pull/18841#discussion_r1609507447
PR Review Comment: https://git.openjdk.org/jdk/pull/18841#discussion_r1609498352
PR Review Comment: https://git.openjdk.org/jdk/pull/18841#discussion_r1613263637
PR Review Comment: https://git.openjdk.org/jdk/pull/18841#discussion_r1609486000
PR Review Comment: https://git.openjdk.org/jdk/pull/18841#discussion_r1609480304
PR Review Comment: https://git.openjdk.org/jdk/pull/18841#discussion_r1609473262
PR Review Comment: https://git.openjdk.org/jdk/pull/18841#discussion_r1609468693
PR Review Comment: https://git.openjdk.org/jdk/pull/18841#discussion_r1609462205

From duke at openjdk.org  Fri May 24 18:00:49 2024
From: duke at openjdk.org (Oussama Louati)
Date: Fri, 24 May 2024 18:00:49 GMT
Subject: RFR: 8307818: Convert Indify tool to Classfile API [v9]
In-Reply-To: <ERPRn4imTD5OFe3XL2O99rBrkNqKMqeMU5HFp4YCgo8=.c80ad962-59fe-48f4-abad-89d19e882978@github.com>
References: <tCFk9yrCtcoBnzvNIgceY0eOaXg9ZiN9nkCuhHIyMyw=.9cc5f994-8d35-411a-bb39-7c3f2ac34dda@github.com>
 <ERPRn4imTD5OFe3XL2O99rBrkNqKMqeMU5HFp4YCgo8=.c80ad962-59fe-48f4-abad-89d19e882978@github.com>
Message-ID: <byb0xtaAXsNNZj5k72wg1hlrvU2q_LtNVgLasxmYqHs=.84557ba8-4aca-419b-bec2-0d78d0239088@github.com>

On Fri, 24 May 2024 17:57:28 GMT, Oussama Louati <duke at openjdk.org> wrote:

>> An indify tool in j.l.i tests (also in vmTestBase) convert some source-code private static methods with MT_ MH_, and INDY_ prefixes into MethodHandle, MethodType, and CallSite constants.
>> It currently uses ad-hoc code to process class files and intends to migrate to ASM; but since we have the Classfile API, we can migrate to Classfile API instead.
>
> Oussama Louati has updated the pull request incrementally with 19 additional commits since the last revision:
> 
>  - fix: fixed whitespaces
>  - fix: fixed whitespaces
>  - chore: used Class::descriptorString
>  - remove: added removed test comments
>  - remove: added removed test comments
>  - remove: removed changes in tests
>  - update: optimize imports and remove unnecessary utils
>  - update: optimize imports
>  - update: 5th patch of code review
>  - update: 5th patch of code review
>  - ... and 9 more: https://git.openjdk.org/jdk/compare/781c951d...2b8c94a7

Addressing the second round of review from @asotona.

-------------

PR Review: https://git.openjdk.org/jdk/pull/18841#pullrequestreview-2076617737

From duke at openjdk.org  Fri May 24 18:00:50 2024
From: duke at openjdk.org (Oussama Louati)
Date: Fri, 24 May 2024 18:00:50 GMT
Subject: RFR: 8307818: Convert Indify tool to Classfile API [v8]
In-Reply-To: <2Ca4OTxbNasLB29gPwNK0-Qi6_vg-2peHWjN4nKQmLU=.3fea78d0-b4fb-4235-a34e-772d3380331f@github.com>
References: <tCFk9yrCtcoBnzvNIgceY0eOaXg9ZiN9nkCuhHIyMyw=.9cc5f994-8d35-411a-bb39-7c3f2ac34dda@github.com>
 <NkLMH9NX2o1zUUPbEdp_jGq-E8V3inBRBnadM9Z-_qU=.cf443418-a3a6-41fc-acfc-8a3de241c747@github.com>
 <2Ca4OTxbNasLB29gPwNK0-Qi6_vg-2peHWjN4nKQmLU=.3fea78d0-b4fb-4235-a34e-772d3380331f@github.com>
Message-ID: <Rkv7HtvqdPpgnPgpJ78she6Z7VeoZ4Fx8W57176LWbo=.91e6c7c3-fedd-4648-abd2-5113f45eb4cd@github.com>

On Tue, 21 May 2024 11:37:26 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> Indify invocation on Microbenchmarks as a part of the JDK build (after application of the above patch) still fails with:
> 
> ```
> Failure on /Applications/XcodeJIB.app/dev/github/jdk/build/macosx-aarch64/support/test/micro/classes
> Exception in thread "main" java.lang.NullPointerException: Cannot invoke "java.lang.classfile.ClassModel.thisClass()" because "model" is null
> 	at java.base/java.lang.classfile.ClassFile.transform(ClassFile.java:445)
> 	at indify.Indify.transformToBytes(Indify.java:369)
> 	at indify.Indify.writeNewClassFile(Indify.java:360)
> 	at indify.Indify.indifyFile(Indify.java:356)
> 	at indify.Indify.indifyTree(Indify.java:391)
> 	at indify.Indify.indifyTree(Indify.java:393)
> 	at indify.Indify.indifyTree(Indify.java:393)
> 	at indify.Indify.indifyTree(Indify.java:393)
> 	at indify.Indify.indifyTree(Indify.java:393)
> 	at indify.Indify.indifyTree(Indify.java:393)
> 	at indify.Indify.indifyTree(Indify.java:393)
> 	at indify.Indify.indify(Indify.java:339)
> 	at indify.Indify.run(Indify.java:191)
> 	at indify.Indify.main(Indify.java:101)
> ```

I applied a patch addressing this issue, the tool invocation should pass now  on Microbenchmarks.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18841#issuecomment-2123566807

From duke at openjdk.org  Fri May 24 18:00:50 2024
From: duke at openjdk.org (Oussama Louati)
Date: Fri, 24 May 2024 18:00:50 GMT
Subject: RFR: 8307818: Convert Indify tool to Classfile API [v9]
In-Reply-To: <P-UeDJ_ZCoCcTJKZMD2eu3IAmEsC1x9PyA77gAm1D8s=.1094b8b8-a01b-487f-a62c-3dcf5f46f9e2@github.com>
References: <tCFk9yrCtcoBnzvNIgceY0eOaXg9ZiN9nkCuhHIyMyw=.9cc5f994-8d35-411a-bb39-7c3f2ac34dda@github.com>
 <ERPRn4imTD5OFe3XL2O99rBrkNqKMqeMU5HFp4YCgo8=.c80ad962-59fe-48f4-abad-89d19e882978@github.com>
 <P-UeDJ_ZCoCcTJKZMD2eu3IAmEsC1x9PyA77gAm1D8s=.1094b8b8-a01b-487f-a62c-3dcf5f46f9e2@github.com>
Message-ID: <74l_lkysArBLJT8e9oXv8W0biPEPuXVwg6kBxfOjm8w=.385285ed-1d32-4a2a-9509-ace445fc94b7@github.com>

On Wed, 22 May 2024 08:57:23 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> Oussama Louati has updated the pull request incrementally with 19 additional commits since the last revision:
>> 
>>  - fix: fixed whitespaces
>>  - fix: fixed whitespaces
>>  - chore: used Class::descriptorString
>>  - remove: added removed test comments
>>  - remove: added removed test comments
>>  - remove: removed changes in tests
>>  - update: optimize imports and remove unnecessary utils
>>  - update: optimize imports
>>  - update: 5th patch of code review
>>  - update: 5th patch of code review
>>  - ... and 9 more: https://git.openjdk.org/jdk/compare/781c951d...2b8c94a7
>
> test/jdk/java/lang/invoke/CallSiteTest.java line 96:
> 
>> 94:     }
>> 95: 
>> 96:     public static class MyCCS extends ConstantCallSite {
> 
> Any reason for this change?

Otherwise, it throws an java.lang.IllegalAccessError:

> Caused by: java.lang.IllegalAccessError: failed to access class test.java.lang.invoke.CallSiteTest$MyCCS from class test.java.lang.invoke.CallSiteTest (test.java.lang.invoke.CallSiteTest$MyCCS is in unnamed module of loader 'app'; test.java.lang.invoke.CallSiteTest is in unnamed module of loader indify.Indify$Loader @234ba0f8)

> test/jdk/java/lang/invoke/CallStaticInitOrder.java line 54:
> 
>> 52: 
>> 53:     static int Init1Tick;
>> 54:     public static class Init1 {
> 
> Is there a reason to change all the classes and methods to public?

the test throws a java.lang.IllegalAccessError

> test/jdk/java/lang/invoke/indify/Indify.java line 61:
> 
>> 59:  * meaning.
>> 60:  * </p>
>> 61:  *
> 
> Why is the javadoc reformatted?
> It is not possible to review the changes if has changed.

Okay i removed it

> test/jdk/java/lang/invoke/indify/Indify.java line 271:
> 
>> 269:                 switch (a) {
>> 270:                 case "--java":
>> 271:                     return;
> 
> Where this conditional code disappeared?

I wrote it back inside the writeNewClassFile() method.

> test/jdk/java/lang/invoke/indify/Indify.java line 352:
> 
>> 350:         if (verbose)  System.err.println("reading " + f);
>> 351:         ClassModel model = parseClassFile(f);
>> 352:         if (model == null) throw new IOException("Failed to parse class file: " + f.getName());
> 
> How it suppose to happen the model is null?

I added this check to address the NullPointerException on MicroBenchmarks, it will be removed.

> test/jdk/java/lang/invoke/indify/Indify.java line 354:
> 
>> 352:         if (model == null) throw new IOException("Failed to parse class file: " + f.getName());
>> 353:         Logic logic = new Logic(model);
>> 354:         if(logic.classModel == null) throw new IOException("Failed to create logic for class file: " + f.getName());
> 
> And null here again?

I added this check to address the NullPointerException on MicroBenchmarks, it will be removed.

> test/jdk/java/lang/invoke/indify/Indify.java line 383:
> 
>> 381:         if (verbose)  System.err.println("writing "+destFile);
>> 382:         Files.write(destFile.toPath(), new_bytes);
>> 383:         System.err.println("Wrote New ClassFile to: "+destFile);
> 
> This code assumes `dest` is always specified?
> For me it looks like it diverges from the original behavior.

I added dest verification.

> test/jdk/java/lang/invoke/indify/Indify.java line 438:
> 
>> 436:                 } catch (Exception ex) {
>> 437:                     // pass error from reportPatternMethods, etc.
>> 438:                     throw (RuntimeException) ex;
> 
> Casting all remaining exceptions to `RuntimeException` ?
> I would suggest to keep the original code 
> or include `RuntimeException` in the fall through section above and wrap all remaining exceptions into a `RuntimeException` to replicate the original behavior.

I assumed that the condition 'ex instanceof RuntimeException' is always 'true',
Reverting to the original code to keep the behavior is applied.

> test/jdk/java/lang/invoke/indify/Indify.java line 470:
> 
>> 468:             Logic logic = new Logic(model);
>> 469:             Boolean isChanged = logic.transform();
>> 470:             if(!isChanged)  throw new IOException("No transformation has been done");
> 
> Throwing an exception when there is not change also significantly changes the original behavior.

Removed, Thank you for pointing that out. it solved the issue of making inner classes in tests public

> test/jdk/java/lang/invoke/indify/Indify.java line 503:
> 
>> 501: 
>> 502:                 Iterator<Instruction> instructionIterator =getInstructions(m).iterator();
>> 503:                 final Stack<Boolean> shouldProceedAfterIndyAdded = new Stack<>();
> 
> What this stack of booleans suppose to do?

We need a boolean value to determine if we should proceed after replacing the appropriate "pop" instruction with an "invokedynamic" instruction. However, instead of using just a boolean field, we use a stack. The reason for this is that within the lambda expression, we can only use final variables. By using a stack, we can update its value as needed, which is why this approach is chosen.

> test/jdk/java/lang/invoke/indify/Indify.java line 540:
> 
>> 538:                         assert (i.sizeInBytes() == 3 || i2.sizeInBytes() == 3);
>> 539:                         System.err.println("----------------------------------------------------------------Transforming Method INDY Instructions & Creating New ClassModels------------------------------------------------------------------}}}");
>> 540:                         if (!quiet) System.err.println(":::Transfmoring the Method: "+ m.methodName() +" instruction: " + i + " invokedynamic: " + con.index() );
> 
> This debug print should be probably removed before integration.

Yes it's temporary for debugging and subject to removal when integrating

> test/jdk/java/lang/invoke/indify/Indify.java line 550:
> 
>> 548:                             if (e instanceof InvokeInstruction && Objects.equals(a1, a2)) {
>> 549:                                 System.err.println(">> Removing instruction invokestatic for Method: " + ((InvokeInstruction) e).name());
>> 550:                                 b.andThen(b);
> 
> What this suppose to do?

This will be removed.
I was forcing the classBuilder to chain itself effectively appending no new elements and removing the current e "CodeElement I,e the instruction".

> test/jdk/java/lang/invoke/indify/Indify.java line 553:
> 
>> 551:                             } else if (shouldProceed.peek() && e instanceof InvokeInstruction && ((InvokeInstruction) e).method().equals(((InvokeInstruction) i2).method())) {
>> 552:                                 System.err.println(">> Removing instruction invokevirtual for Method: " + ((InvokeInstruction) e).name());
>> 553:                                 b.andThen(b);
> 
> And this?

same thing for this.

> test/jdk/java/lang/invoke/indify/Indify.java line 572:
> 
>> 570:                     } else {
>> 571:                         assert(i.sizeInBytes() == 3);
>> 572:                         System.err.println("----------------------------------------------------------------Transforming Method LDC Instructions & Creating New ClassModels------------------------------------------------------------------}}}");
> 
> This debug print should be probably removed before integration.

Yes it's temporary for debugging and subject to removal when integrating

> test/jdk/java/lang/invoke/indify/Indify.java line 576:
> 
>> 574:                         codeTransform = (b, e) ->{
>> 575:                             String a1 = null, a2 = null;
>> 576:                             if(e instanceof InvokeInstruction){
> 
> Please use pattern matching and consolidate repeated `(e instanceof InvokeInstruction)`, followed by casting.

Okay

> test/jdk/java/lang/invoke/indify/Indify.java line 578:
> 
>> 576:                         classTransform = ClassTransform.transformingMethodBodies(filter, codeTransform);
>> 577:                         classModel = of().parse(
>> 578:                              of().transform(classModel, classTransform));
> 
> What this transform (in the middle of instructions iteration) does?

It updates the current classfile so when moving to a next action we avoid this runtime error:

> STATUS:Failed.`main' threw exception: java.lang.VerifyError: Bad type on operand stack

> test/jdk/java/lang/invoke/indify/Indify.java line 582:
> 
>> 580:                             if(e instanceof InvokeInstruction && Objects.equals(a1, a2)){
>> 581:                                 System.err.println(":::Transfmoring the Method: "+ m.methodName() +" instruction: invokestatic " + ((InvokeInstruction) e).type() + " to ldc: " +  con.index() );
>> 582:                                 b.constantInstruction(Opcode.LDC_W,  ((LoadableConstantEntry) con).constantValue());
> 
> `b.ldc((LoadableConstantEntry) con)` would do the same job, but so many blind casting is not a good pattern.

Change applied.

> test/jdk/java/lang/invoke/indify/Indify.java line 599:
> 
>> 597:         ClassModel removePatternMethodsAndVerify(ClassModel classModel){
>> 598: 
>> 599:             ClassModel newClassModel = of(StackMapsOption.GENERATE_STACK_MAPS).parse(
> 
> `StackMapsOption.GENERATE_STACK_MAPS` is the default and it is not necessary to set it explicitly.

Okay, removed.

> test/jdk/java/lang/invoke/indify/Indify.java line 610:
> 
>> 608:                     })
>> 609:             );
>> 610:             ClassHierarchyResolver classHierarchyResolver = classDesc -> ClassHierarchyResolver.ClassHierarchyInfo.ofInterface();
> 
> It is not necessary to fake the `ClassHierarchyResolver` for the verification if the above code generates stack maps and is able to resolve all necessary classes.

Yes, I added it before because I had an exception thrown saying that the Verifier needs to know the classes used in the code. At least it needs to know if it is an interface or it super-class.

> test/jdk/java/lang/invoke/indify/Indify.java line 645:
> 
>> 643:                         case GETSTATIC, GETFIELD, PUTSTATIC, PUTFIELD -> pops.replace("Q", type);
>> 644:                         default -> {
>> 645:                             if (!type.startsWith("("))
> 
> This is very low-level of bytecode instructions parsing. Class-File API already contains high-level models of the instructions and it would be worth to use that models or instead of the tricky up and down conversions and auxiliary structures describing the instructions.

This is removed as its implementation is redundant and could be achieved easily using the API

> test/jdk/java/lang/invoke/indify/Indify.java line 660:
> 
>> 658:          *
>> 659:          * @return true if any marks were changed, false otherwise.
>> 660:          */
> 
> This method does incremental analysis of the constant pool.
> With Class-File API CP model it can be done in one pass, or even in no-pass and all requests to "marks" can be answered directly.

Thank you for the feedback. I will look into the Class-File API CP model and apply your suggestion to perform the analysis in one pass or handle requests to "marks" directly.

> test/jdk/java/lang/invoke/indify/Indify.java line 678:
> 
>> 676:                     if (!Modifier.isPrivate(m.flags().flagsMask())) continue;
>> 677:                     if (!Modifier.isStatic(m.flags().flagsMask())) continue;
>> 678:                     if(nameAndTypeMark(m.methodName().index(), m.methodType().index()) == mark) {
> 
> Passing CP indexes instead of the entries (or maybe String values) is no more necessary.
> Original code didn't have a full model of the constant pool.

I agree, we should focus on passing CP entries as we can have all info we need from it

> test/jdk/java/lang/invoke/indify/Indify.java line 725:
> 
>> 723:                     }
>> 724:                     if (entry instanceof IntegerEntry integerEntry) {
>> 725:                         clb.constantPool().intEntry(integerEntry.intValue());
> 
> This whole code does effectively nothing and can be removed.
> All the entries present in the `oldClassModel` are iterated and and re-entered into the same constant pool.

Okay, it's removed.

> test/jdk/java/lang/invoke/indify/Indify.java line 809:
> 
>> 807:                     }
>> 808: 
>> 809:                     switch (poolEntry.tag()) {
> 
> I would recommend to convert this to a switch expression:
> 
> mark = switch (poolEntry) {
>     case Utf8Entry utf -> nameMark(utf.stringValue());
>     case NameAndTypeEntry nat -> nameAndTypeMark(nat.name(), nat.type());
> 
> 
> Questionable is why to pass CP indexes to the auxiliary methods (for further entries lookup by index), when the pool entries contain all the necessary information.

Changed to switch expression and removed passing CP indexes to auxiliary methods

> test/jdk/java/lang/invoke/indify/Indify.java line 956:
> 
>> 954:                                                 case "double" -> 'D';
>> 955:                                                 default -> throw new InternalError(argClass.toString());
>> 956:                                             };
> 
> This code looks like composition of `ClassDesc`, I would look at `Class::descriptorString`

Thank you, it's now all replaced with:
> if (typeArg instanceof Class<?> argClass) {
                                        buf.append(argClass.descriptorString());
                                    }

> test/jdk/java/lang/invoke/indify/Indify.java line 1249:
> 
>> 1247:             } else {
>> 1248:                 return null;
>> 1249:             }
> 
> How does it happen that the argument might be a String or a StringEntry.
> 
> Also instead of:
> 
> if (x instanceof PoolEntry && ((PoolEntry) x).tag() == TAG_STRING) {
>                  utf8Entry = ((StringEntry) x).utf8();
> 
> You can write:
> 
> if (x instanceof StringEntry se) {
>                  utf8Entry = se.utf8();

Changed to use pattern matching:
the argument might be a String or a StringEntry happens because the method is being invoked with elements from the args list, which can contain different types of objects depending on the specific case being handled in the switch statement.

> test/jdk/java/lang/invoke/indify/Indify.java line 1273:
> 
>> 1271:             if(((con = args.get(argi)) instanceof MethodTypeEntry) || (con instanceof ClassEntry)){
>> 1272:                 assert con instanceof MethodTypeEntry;
>> 1273:                 type = ((MethodTypeEntry) con).descriptor();
> 
> This is a lot of low-level stuff, where a bunch of entries are filled into a List<Object> and then identified back as entries. It is very hard to read and debug, I would suggest to organize it a type-safe way.

Done

> test/jdk/java/lang/invoke/indify/Indify.java line 1334:
> 
>> 1332:                     if (x instanceof Float)   { x = poolBuilder.floatEntry((Float) x); }
>> 1333:                     if (x instanceof Long)    { x = poolBuilder.longEntry((Long) x); }
>> 1334:                     if (x instanceof Double)  { x = poolBuilder.doubleEntry((Double) x); }
> 
> This is a harder way, when you convert all the arguments into entries.
> `ConstantPoolBuilder::bsmEntry(DirectMethodHandleDesc methodReference, List<ConstantDesc> arguments)` would do it for you.

I agree, Done.
It's now using them as ClassDescs instead of creating them as entries manually so the API will do the rest of work

> test/jdk/java/lang/invoke/indify/Indify.java line 1368:
> 
>> 1366:             if (count == 0){
>> 1367:                 poolBuilder.utf8Entry("BootstrapMethods");
>> 1368:                 return specs;
> 
> It is not necessary to manually insert "BootstrapMethods" entry, Class-File API generates all the stuff if you add a bootstrap method, no matter if it is the first one or just another addition.

Okay, it's removed

> test/jdk/java/lang/invoke/indify/Indify.java line 1403:
> 
>> 1401:                     System.err.println(e.getMessage());
>> 1402:                 }
>> 1403:                 throw new IOException("Verification failed");
> 
> Is there a reason to verify source class files?

not necessarily, just to check the class files are syntactically and semantically correct

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18841#discussion_r1610748140
PR Review Comment: https://git.openjdk.org/jdk/pull/18841#discussion_r1610748495
PR Review Comment: https://git.openjdk.org/jdk/pull/18841#discussion_r1609759631
PR Review Comment: https://git.openjdk.org/jdk/pull/18841#discussion_r1613308306
PR Review Comment: https://git.openjdk.org/jdk/pull/18841#discussion_r1609776200
PR Review Comment: https://git.openjdk.org/jdk/pull/18841#discussion_r1609776328
PR Review Comment: https://git.openjdk.org/jdk/pull/18841#discussion_r1613309092
PR Review Comment: https://git.openjdk.org/jdk/pull/18841#discussion_r1613316282
PR Review Comment: https://git.openjdk.org/jdk/pull/18841#discussion_r1613496593
PR Review Comment: https://git.openjdk.org/jdk/pull/18841#discussion_r1613790639
PR Review Comment: https://git.openjdk.org/jdk/pull/18841#discussion_r1609777537
PR Review Comment: https://git.openjdk.org/jdk/pull/18841#discussion_r1610739563
PR Review Comment: https://git.openjdk.org/jdk/pull/18841#discussion_r1610739686
PR Review Comment: https://git.openjdk.org/jdk/pull/18841#discussion_r1609778215
PR Review Comment: https://git.openjdk.org/jdk/pull/18841#discussion_r1609778741
PR Review Comment: https://git.openjdk.org/jdk/pull/18841#discussion_r1613790489
PR Review Comment: https://git.openjdk.org/jdk/pull/18841#discussion_r1609784572
PR Review Comment: https://git.openjdk.org/jdk/pull/18841#discussion_r1609792441
PR Review Comment: https://git.openjdk.org/jdk/pull/18841#discussion_r1609798535
PR Review Comment: https://git.openjdk.org/jdk/pull/18841#discussion_r1611726680
PR Review Comment: https://git.openjdk.org/jdk/pull/18841#discussion_r1613836491
PR Review Comment: https://git.openjdk.org/jdk/pull/18841#discussion_r1609827878
PR Review Comment: https://git.openjdk.org/jdk/pull/18841#discussion_r1610153523
PR Review Comment: https://git.openjdk.org/jdk/pull/18841#discussion_r1610193396
PR Review Comment: https://git.openjdk.org/jdk/pull/18841#discussion_r1613813353
PR Review Comment: https://git.openjdk.org/jdk/pull/18841#discussion_r1610244205
PR Review Comment: https://git.openjdk.org/jdk/pull/18841#discussion_r1610270258
PR Review Comment: https://git.openjdk.org/jdk/pull/18841#discussion_r1610582725
PR Review Comment: https://git.openjdk.org/jdk/pull/18841#discussion_r1610281807
PR Review Comment: https://git.openjdk.org/jdk/pull/18841#discussion_r1610279669

From duke at openjdk.org  Fri May 24 18:00:50 2024
From: duke at openjdk.org (Oussama Louati)
Date: Fri, 24 May 2024 18:00:50 GMT
Subject: RFR: 8307818: Convert Indify tool to Classfile API [v9]
In-Reply-To: <74l_lkysArBLJT8e9oXv8W0biPEPuXVwg6kBxfOjm8w=.385285ed-1d32-4a2a-9509-ace445fc94b7@github.com>
References: <tCFk9yrCtcoBnzvNIgceY0eOaXg9ZiN9nkCuhHIyMyw=.9cc5f994-8d35-411a-bb39-7c3f2ac34dda@github.com>
 <ERPRn4imTD5OFe3XL2O99rBrkNqKMqeMU5HFp4YCgo8=.c80ad962-59fe-48f4-abad-89d19e882978@github.com>
 <P-UeDJ_ZCoCcTJKZMD2eu3IAmEsC1x9PyA77gAm1D8s=.1094b8b8-a01b-487f-a62c-3dcf5f46f9e2@github.com>
 <74l_lkysArBLJT8e9oXv8W0biPEPuXVwg6kBxfOjm8w=.385285ed-1d32-4a2a-9509-ace445fc94b7@github.com>
Message-ID: <AHqQZ95XjMLJ3hIaIxl7aD3lgrvRe7ZrsoNjnPa00SM=.aa813ed1-cfa4-4853-a310-9d82238e8216@github.com>

On Wed, 22 May 2024 22:37:35 GMT, Oussama Louati <duke at openjdk.org> wrote:

>> test/jdk/java/lang/invoke/CallSiteTest.java line 96:
>> 
>>> 94:     }
>>> 95: 
>>> 96:     public static class MyCCS extends ConstantCallSite {
>> 
>> Any reason for this change?
>
> Otherwise, it throws an java.lang.IllegalAccessError:
> 
>> Caused by: java.lang.IllegalAccessError: failed to access class test.java.lang.invoke.CallSiteTest$MyCCS from class test.java.lang.invoke.CallSiteTest (test.java.lang.invoke.CallSiteTest$MyCCS is in unnamed module of loader 'app'; test.java.lang.invoke.CallSiteTest is in unnamed module of loader indify.Indify$Loader @234ba0f8)

removed

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18841#discussion_r1613824020

From kvn at openjdk.org  Fri May 24 18:02:14 2024
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Fri, 24 May 2024 18:02:14 GMT
Subject: RFR: 8320448: Accelerate IndexOf using AVX2 [v37]
In-Reply-To: <4xYUBsOJ_eDSuj6w9AjUo_6gFN_9piWR-ChLrHQoXl4=.88756684-8e9c-48e3-8b59-f5f684b81cde@github.com>
References: <uWi4QxH31hL93771gkl_GgvP0m84IRSoR_1Yi8hD17E=.bc6ed458-7081-4c3f-9348-f59358fa05a4@github.com>
 <4xYUBsOJ_eDSuj6w9AjUo_6gFN_9piWR-ChLrHQoXl4=.88756684-8e9c-48e3-8b59-f5f684b81cde@github.com>
Message-ID: <m3ATrWA3fQ2BOuav21Uh9HYH4VCHDavqPsSqdJ5DV6I=.09cc34d4-439e-499b-9446-e0f6c7d26105@github.com>

On Fri, 24 May 2024 15:32:26 GMT, Scott Gibbons <sgibbons at openjdk.org> wrote:

>> Re-write the IndexOf code without the use of the pcmpestri instruction, only using AVX2 instructions.  This change accelerates String.IndexOf on average 1.3x for AVX2.  The benchmark numbers:
>> 
>> 
>> Benchmark	                                               Score		Latest		
>> StringIndexOf.advancedWithMediumSub   343.573		317.934		0.925375393x
>> StringIndexOf.advancedWithShortSub1	  1039.081		1053.96		1.014319384x
>> StringIndexOf.advancedWithShortSub2	      55.828		110.541		1.980027943x
>> StringIndexOf.constantPattern	                9.361		11.906		1.271872663x
>> StringIndexOf.searchCharLongSuccess	        4.216		4.218		1.000474383x
>> StringIndexOf.searchCharMediumSuccess	3.133		3.216		1.02649218x
>> StringIndexOf.searchCharShortSuccess	3.76		        3.761		1.000265957x
>> StringIndexOf.success	                                9.186		9.713		1.057369911x
>> StringIndexOf.successBig	                      14.341		46.343		3.231504079x
>> StringIndexOfChar.latin1_AVX2_String	  6220.918		12154.52		1.953814533x
>> StringIndexOfChar.latin1_AVX2_char	  5503.556		5540.044		1.006629895x
>> StringIndexOfChar.latin1_SSE4_String	  6978.854		6818.689		0.977049957x
>> StringIndexOfChar.latin1_SSE4_char	  5657.499		5474.624		0.967675646x
>> StringIndexOfChar.latin1_Short_String	  7132.541		6863.359		0.962260014x
>> StringIndexOfChar.latin1_Short_char	16013.389	      16162.437		1.009307711x
>> StringIndexOfChar.latin1_mixed_String	  7386.123	      14771.622		1.999915517x
>> StringIndexOfChar.latin1_mixed_char	  9901.671		9782.245		0.987938803
>
> Scott Gibbons has updated the pull request incrementally with one additional commit since the last revision:
> 
>   mov64 => lea(InternalAddress)

My testing for v34 passed without new failures.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/16753#issuecomment-2130096346

From kvn at openjdk.org  Fri May 24 18:16:13 2024
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Fri, 24 May 2024 18:16:13 GMT
Subject: RFR: 8320448: Accelerate IndexOf using AVX2 [v37]
In-Reply-To: <4xYUBsOJ_eDSuj6w9AjUo_6gFN_9piWR-ChLrHQoXl4=.88756684-8e9c-48e3-8b59-f5f684b81cde@github.com>
References: <uWi4QxH31hL93771gkl_GgvP0m84IRSoR_1Yi8hD17E=.bc6ed458-7081-4c3f-9348-f59358fa05a4@github.com>
 <4xYUBsOJ_eDSuj6w9AjUo_6gFN_9piWR-ChLrHQoXl4=.88756684-8e9c-48e3-8b59-f5f684b81cde@github.com>
Message-ID: <KmB_NdCdOwzwCaBNTPSidVBx8CruLQ3e3fmtn3NvIxo=.a23cba45-1977-4d55-8ca1-487744c4e6c1@github.com>

On Fri, 24 May 2024 15:32:26 GMT, Scott Gibbons <sgibbons at openjdk.org> wrote:

>> Re-write the IndexOf code without the use of the pcmpestri instruction, only using AVX2 instructions.  This change accelerates String.IndexOf on average 1.3x for AVX2.  The benchmark numbers:
>> 
>> 
>> Benchmark	                                               Score		Latest		
>> StringIndexOf.advancedWithMediumSub   343.573		317.934		0.925375393x
>> StringIndexOf.advancedWithShortSub1	  1039.081		1053.96		1.014319384x
>> StringIndexOf.advancedWithShortSub2	      55.828		110.541		1.980027943x
>> StringIndexOf.constantPattern	                9.361		11.906		1.271872663x
>> StringIndexOf.searchCharLongSuccess	        4.216		4.218		1.000474383x
>> StringIndexOf.searchCharMediumSuccess	3.133		3.216		1.02649218x
>> StringIndexOf.searchCharShortSuccess	3.76		        3.761		1.000265957x
>> StringIndexOf.success	                                9.186		9.713		1.057369911x
>> StringIndexOf.successBig	                      14.341		46.343		3.231504079x
>> StringIndexOfChar.latin1_AVX2_String	  6220.918		12154.52		1.953814533x
>> StringIndexOfChar.latin1_AVX2_char	  5503.556		5540.044		1.006629895x
>> StringIndexOfChar.latin1_SSE4_String	  6978.854		6818.689		0.977049957x
>> StringIndexOfChar.latin1_SSE4_char	  5657.499		5474.624		0.967675646x
>> StringIndexOfChar.latin1_Short_String	  7132.541		6863.359		0.962260014x
>> StringIndexOfChar.latin1_Short_char	16013.389	      16162.437		1.009307711x
>> StringIndexOfChar.latin1_mixed_String	  7386.123	      14771.622		1.999915517x
>> StringIndexOfChar.latin1_mixed_char	  9901.671		9782.245		0.987938803
>
> Scott Gibbons has updated the pull request incrementally with one additional commit since the last revision:
> 
>   mov64 => lea(InternalAddress)

I am fine with current version.

-------------

Marked as reviewed by kvn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/16753#pullrequestreview-2077568604

From sgibbons at openjdk.org  Fri May 24 18:16:14 2024
From: sgibbons at openjdk.org (Scott Gibbons)
Date: Fri, 24 May 2024 18:16:14 GMT
Subject: RFR: 8320448: Accelerate IndexOf using AVX2 [v37]
In-Reply-To: <m3ATrWA3fQ2BOuav21Uh9HYH4VCHDavqPsSqdJ5DV6I=.09cc34d4-439e-499b-9446-e0f6c7d26105@github.com>
References: <uWi4QxH31hL93771gkl_GgvP0m84IRSoR_1Yi8hD17E=.bc6ed458-7081-4c3f-9348-f59358fa05a4@github.com>
 <4xYUBsOJ_eDSuj6w9AjUo_6gFN_9piWR-ChLrHQoXl4=.88756684-8e9c-48e3-8b59-f5f684b81cde@github.com>
 <m3ATrWA3fQ2BOuav21Uh9HYH4VCHDavqPsSqdJ5DV6I=.09cc34d4-439e-499b-9446-e0f6c7d26105@github.com>
Message-ID: <LbLwE-Y9TzuQDDim5SOXrya8SurjLfYeXCE5bEMGs6Y=.34b214e3-beb3-4428-95a2-471019c8b373@github.com>

On Fri, 24 May 2024 17:59:49 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> Scott Gibbons has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   mov64 => lea(InternalAddress)
>
> My testing for v34 passed without new failures.

Thank you @vnkozlov .  Waiting for review from @sviswa7 and @jatin-bhateja, then I'll integrate.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/16753#issuecomment-2130114623

From duke at openjdk.org  Fri May 24 18:30:14 2024
From: duke at openjdk.org (Volodymyr Paprotski)
Date: Fri, 24 May 2024 18:30:14 GMT
Subject: RFR: 8320448: Accelerate IndexOf using AVX2 [v19]
In-Reply-To: <xwgol0oMgfd10mFw593hgE0wgaTsjCxA1ETGX3ZQLM0=.5a0bab49-7c5b-49ba-9a2c-4bee3a04ccd7@github.com>
References: <uWi4QxH31hL93771gkl_GgvP0m84IRSoR_1Yi8hD17E=.bc6ed458-7081-4c3f-9348-f59358fa05a4@github.com>
 <eQ4OBFrF8JlDJ1h9awTDOc0kfCc37IlL5vdqtuaqls0=.8f00616d-08e1-4f28-a7a5-5095116d2595@github.com>
 <aTbnceYj7mQGE4hpCoeUqv5r-W8iHSI_EqVncR0iU_s=.6a63f8c5-eafb-48d5-a871-4cc475e0f63f@github.com>
 <xwgol0oMgfd10mFw593hgE0wgaTsjCxA1ETGX3ZQLM0=.5a0bab49-7c5b-49ba-9a2c-4bee3a04ccd7@github.com>
Message-ID: <i5EYGyBhrS8WDuDABuhppAkYBuilvRWsUev-YvdLgb8=.b65c7a76-2cd1-4e16-a2bc-ae724a206a5b@github.com>

On Wed, 22 May 2024 14:41:36 GMT, Scott Gibbons <sgibbons at openjdk.org> wrote:

>> test/micro/org/openjdk/bench/java/lang/StringIndexOfHuge.java line 132:
>> 
>>> 130:   @Benchmark
>>> 131:   public int searchHugeLargeSubstring() {
>>> 132:       return dataStringHuge.indexOf("B".repeat(30) + "X" + "A".repeat(30), 74);
>> 
>> .repeat() call and string concatenation shouldn't be part of the benchmark (here and several other @Benchmark functions in this file) since it will detract from the measurement.
>> 
>> (String concatenation gets converted (by javac) into StringBuilder().append().append()....append().toString())
>
> Since we're only concerned with the delta of performance, does this really matter?  Can you suggest an alternative?

The needle really should be like the all the other strings, e.g. `dataStringHuge` itself, generated by the setup. 

As to weather it really matters; the answer is Amdahl's law. You can indeed measure the delta, but you can't measure the speedup of just the indexOf; not with repeat and concatenation obscuring the numbers.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1613864094

From duke at openjdk.org  Fri May 24 18:35:11 2024
From: duke at openjdk.org (Volodymyr Paprotski)
Date: Fri, 24 May 2024 18:35:11 GMT
Subject: RFR: 8320448: Accelerate IndexOf using AVX2 [v19]
In-Reply-To: <VO8cxJFwYuRGtF7af2NsAAIC2cmWQVSPb0_pkN-wm-E=.738560f5-0763-49d6-87fa-83c0b717ce4a@github.com>
References: <uWi4QxH31hL93771gkl_GgvP0m84IRSoR_1Yi8hD17E=.bc6ed458-7081-4c3f-9348-f59358fa05a4@github.com>
 <eQ4OBFrF8JlDJ1h9awTDOc0kfCc37IlL5vdqtuaqls0=.8f00616d-08e1-4f28-a7a5-5095116d2595@github.com>
 <aTbnceYj7mQGE4hpCoeUqv5r-W8iHSI_EqVncR0iU_s=.6a63f8c5-eafb-48d5-a871-4cc475e0f63f@github.com>
 <VO8cxJFwYuRGtF7af2NsAAIC2cmWQVSPb0_pkN-wm-E=.738560f5-0763-49d6-87fa-83c0b717ce4a@github.com>
Message-ID: <GKHsqPifhlm2OdzYjwNOUGeqYmRiJxJlFd3iB_UrlZs=.32565158-6e64-4c3a-a4d6-bf4c2064a714@github.com>

On Fri, 17 May 2024 23:59:05 GMT, Scott Gibbons <sgibbons at openjdk.org> wrote:

>> test/jdk/java/lang/StringBuffer/IndexOf.java line 40:
>> 
>>> 38:   private static boolean failure = false;
>>> 39:   public static void main(String[] args) throws Exception {
>>> 40:     String testName = "IndexOf";
>> 
>> intentation
>
> Fixed

(missed a `git add`? don't see the updates for this file)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1613870558

From kvn at openjdk.org  Fri May 24 18:40:12 2024
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Fri, 24 May 2024 18:40:12 GMT
Subject: RFR: 8320448: Accelerate IndexOf using AVX2 [v33]
In-Reply-To: <xdDp4nAAOMal3mTMvlUohZm-hKfMWewOFB3LUK1VkUU=.10eaee6e-aee6-4ea5-a6fe-64d5c2f411de@github.com>
References: <uWi4QxH31hL93771gkl_GgvP0m84IRSoR_1Yi8hD17E=.bc6ed458-7081-4c3f-9348-f59358fa05a4@github.com>
 <kE-TMUMyr6ADsj3wtDB9RlLnXaJFbFzmd7cikzCEuSg=.490d5dd5-eaa8-4137-8e00-7d5de1efb598@github.com>
 <GkGAR2YTtCDe_xFo2a7MxxJyoo-dsgghT9TvqfntN3c=.e40c4157-c48d-4454-b08e-17d6eb9b85a1@github.com>
 <nxpwP6Q_co_mHw7hIyjBjPSjuR6HUc3-ioT80k0tpqE=.fca7f3a5-a511-481c-b630-abeb4402268c@github.com>
 <BfYSarY-tQu34szlCk9qBFTIPR1TlmM5quTXqmoZoGI=.de6da9a2-3ef7-4e1c-8de4-dea5bf134d0f@github.com>
 <Y5yF2Y5MfT6Cz-mhe3qr68Bstkt1ODKOO-4NIh4yeCo=.6675b3fa-12f7-4201-8349-38828242660b@github.com>
 <D8_haA3HGt72E96jB_5XRfRMmtMX8QeeZ7yfXOMklYU=.88d509be-4795-49ce-987b-1d968280237e@github.com>
 <xdDp4nAAOMal3mTMvlUohZm-hKfMWewOFB3LUK1VkUU=.10eaee6e-aee6-4ea5-a6fe-64d5c2f411de@github.com>
Message-ID: <AtSz9Pq9tUXRfN6Yf2NWMMh2oq_AJkMqNmSF92foZuw=.1c28d950-dfe9-47a3-b49b-fb9132f3b24d@github.com>

On Fri, 24 May 2024 15:33:46 GMT, Scott Gibbons <sgibbons at openjdk.org> wrote:

>> Thanks for checking. Well I know that the `MacroAssembler::movdqu(XMMRegister dst, AddressLiteral src, Register rscratch)` method actually generates rip-relative addresses. Maybe we could copy some of that code.
>
> Changed to `lea` with `InternalAddress()`.  Generates the exact same code, but makes more sense.  I looked at `movdqu` and see no code that generates RIP-relative loads.  It merely checks `reachable()` and adds an intermediate `lea` if not reachable.  @djelinski can you clarify please?

I think HotSpot prefer to have full addresses in `lea` for possible patching.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1613874603

From naoto at openjdk.org  Fri May 24 18:40:33 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 24 May 2024 18:40:33 GMT
Subject: RFR: 8332161: Test restoring echo in the Console implementation
 (java.base) [v4]
In-Reply-To: <aSxuvnY7ghWwuDuegcWKJKlL_3KUCdIS_jHgTsn43ow=.b4d2e8d9-ffea-4318-9004-27b18298436e@github.com>
References: <aSxuvnY7ghWwuDuegcWKJKlL_3KUCdIS_jHgTsn43ow=.b4d2e8d9-ffea-4318-9004-27b18298436e@github.com>
Message-ID: <aGv14T_UNpYf2CZiOPLjXOVAlj-D4nSiG3IXXctwUe0=.e2cfdb2f-1ed1-4a2f-935f-29ae6e9ad560@github.com>

> This test intends to verify the behavior of JdkConsole for the java.base module, wrt restoring the echo. The test assumes the internal methods that sets/gets the echo status of the platform.

Naoto Sato 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 20 additional commits since the last revision:

 - Merge branch 'JDK-8332084-restoreEcho-readLock' into JDK-8332161-restoreEcho-Test
 - Added comment for restoreEchoLock
 - fixing typo
 - Merge branch 'JDK-8332084-restoreEcho-readLock' into JDK-8332161-restoreEcho-Test
 - Merge branch 'master' into JDK-8332084-restoreEcho-readLock
 - leftover typo
 - get/setEcho() -> echo()
 - Merge branch 'JDK-8332084-restoreEcho-readLock' into JDK-8332161-restoreEcho-Test
 - Used a dedicate lock for restoreEcho
 - Merge branch 'JDK-8332084-restoreEcho-readLock' into JDK-8332161-restoreEcho-Test
 - ... and 10 more: https://git.openjdk.org/jdk/compare/8d2a0559...7311487f

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19315/files
  - new: https://git.openjdk.org/jdk/pull/19315/files/1cd88c61..7311487f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19315&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19315&range=02-03

  Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/19315.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19315/head:pull/19315

PR: https://git.openjdk.org/jdk/pull/19315

From naoto at openjdk.org  Fri May 24 18:52:25 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 24 May 2024 18:52:25 GMT
Subject: RFR: 8332161: Test restoring echo in the Console implementation
 (java.base) [v5]
In-Reply-To: <aSxuvnY7ghWwuDuegcWKJKlL_3KUCdIS_jHgTsn43ow=.b4d2e8d9-ffea-4318-9004-27b18298436e@github.com>
References: <aSxuvnY7ghWwuDuegcWKJKlL_3KUCdIS_jHgTsn43ow=.b4d2e8d9-ffea-4318-9004-27b18298436e@github.com>
Message-ID: <YC26MyGb7EEK5TDX4Ky2-8kIgkpBSznNc0L6yzd9OAI=.172d4c63-197c-4071-88ef-3a5c097de577@github.com>

> This test intends to verify the behavior of JdkConsole for the java.base module, wrt restoring the echo. The test assumes the internal methods that sets/gets the echo status of the platform.

Naoto Sato has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 21 commits:

 - Merge branch 'master' into JDK-8332161-restoreEcho-Test
 - Merge branch 'JDK-8332084-restoreEcho-readLock' into JDK-8332161-restoreEcho-Test
 - Added comment for restoreEchoLock
 - fixing typo
 - Merge branch 'JDK-8332084-restoreEcho-readLock' into JDK-8332161-restoreEcho-Test
 - Merge branch 'master' into JDK-8332084-restoreEcho-readLock
 - leftover typo
 - get/setEcho() -> echo()
 - Merge branch 'JDK-8332084-restoreEcho-readLock' into JDK-8332161-restoreEcho-Test
 - Used a dedicate lock for restoreEcho
 - ... and 11 more: https://git.openjdk.org/jdk/compare/ebc520e8...36649fbd

-------------

Changes: https://git.openjdk.org/jdk/pull/19315/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19315&range=04
  Stats: 192 lines in 2 files changed: 192 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/19315.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19315/head:pull/19315

PR: https://git.openjdk.org/jdk/pull/19315

From erikj at openjdk.org  Fri May 24 19:30:04 2024
From: erikj at openjdk.org (Erik Joelsson)
Date: Fri, 24 May 2024 19:30:04 GMT
Subject: RFR: 8332885: Clarify failure_handler self-tests
In-Reply-To: <fSl5ksYZ89l98gCGy0q3jfhpoCO5UVBKlA5k7Fxt720=.886e149b-561d-4109-9e72-94346f02f25d@github.com>
References: <fSl5ksYZ89l98gCGy0q3jfhpoCO5UVBKlA5k7Fxt720=.886e149b-561d-4109-9e72-94346f02f25d@github.com>
Message-ID: <4WTtBtlrkbn2oagshFrdXjgeIO-Zbp9eob7HkOzOEgU=.01122e2f-61fe-48ee-9db9-eedd9eb4e21c@github.com>

On Fri, 24 May 2024 12:16:25 GMT, Ludvig Janiuk <lujaniuk at openjdk.org> wrote:

> Adding commetns to clarify that the failure_handler selftests are intended to be run manually. Ideally this would include a more thorough description of the exepcted outputs, but this is what I have time to add right now.

test/failure_handler/README line 115:

> 113: generated artifacts and cannot be run as part of a CI. They are tests which timeout, crash,
> 114: fail in various ways and you can check the failure_handler output yourself. They might also
> 115: leave processes running on your machine so be extra careful about cleaning up.

These lines are longer than the text blocks in the rest of this file. Could you adjust formatting to match?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19393#discussion_r1613935457

From lancea at openjdk.org  Fri May 24 19:32:06 2024
From: lancea at openjdk.org (Lance Andersen)
Date: Fri, 24 May 2024 19:32:06 GMT
Subject: RFR: 8330542: Template for Creating Strict JAXP Configuration File
 [v14]
In-Reply-To: <-xQutVfz6r3JPZZnkO71_iimpzxhNvdoX8cpz8E7-X8=.5867b83a-ec89-4c69-ac7c-6bc11caeb93e@github.com>
References: <v1bAYKgH9zfooXpvnBw4Vu2TIqHuKqqtSmgB0hiNp-Q=.31661a99-ecfc-4a05-8045-67b5f680db60@github.com>
 <-xQutVfz6r3JPZZnkO71_iimpzxhNvdoX8cpz8E7-X8=.5867b83a-ec89-4c69-ac7c-6bc11caeb93e@github.com>
Message-ID: <bkMafXvZ7TgNQCQaC0p8KzLZwLPl-gCRGu56_sZsPZo=.3cfc188b-76c2-4b26-9807-06988d702996@github.com>

On Fri, 24 May 2024 16:36:32 GMT, Joe Wang <joehw at openjdk.org> wrote:

>> Add two sample configuration files:
>> 
>>   jaxp-strict.properties: used to set strict configuration, stricter than jaxp.properties in previous versions such as JDK 22
>> 
>>>   jaxp-compat.properties: used to regain compatibility from any more restricted configuration than previous versions such as JDK 22
>> 
>> Updated on 5/16/2024
>> 
>> Design change:
>> The design is changed to include in the JDK two configuration files that are the default jaxp.properties and jaxp-strict.properties, instead of three, dropping jaxp-compat.properties.
>> 
>> Updated on 5/18/2024
>> 
>> Withdraw changes to jaxp.properties. The original idea was to match jaxp-strict.properties with regard to the properties. However, that change impact the configuration process, resulting in tests that verify the process to fail.
>> 
>> Updated on 5/23/2024
>> 
>> Provide a template `jaxp-strict.template` instead of a properties file. This template can be used to create custom configuration files.
>
> Joe Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   rename the template to jaxp-strict.properties.template

Marked as reviewed by lancea (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/18831#pullrequestreview-2077722644

From darcy at openjdk.org  Fri May 24 19:46:15 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 24 May 2024 19:46:15 GMT
Subject: RFR: 8330182: Start of release updates for JDK 24 [v6]
In-Reply-To: <YKsEQWuI-vNTEDjOBInuEjf8AEcTL4QZ_F4JYUqoxwk=.5ed43782-6dec-4383-948d-d9966a85b3bf@github.com>
References: <YKsEQWuI-vNTEDjOBInuEjf8AEcTL4QZ_F4JYUqoxwk=.5ed43782-6dec-4383-948d-d9966a85b3bf@github.com>
Message-ID: <fTr5SgVZo9VjsVCY76-kdjmd1ph0rF4ewsoCj3-mTiY=.eed4242f-a428-4f6d-9fdb-4404649b93b7@github.com>

> Get JDK 24 underway.

Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 13 commits:

 - Merge branch 'master' into JDK-8330188
 - Merge branch 'master' into JDK-8330188
 - Fix-up test.
 - Merge branch 'master' into JDK-8330188
 - Adjust test for deprecated options.
 - Merge branch 'master' into JDK-8330188
 - Update deprecated options test.
 - Merge branch 'master' into JDK-8330188
 - Merge branch 'master' into JDK-8330188
 - Merge branch 'master' into JDK-8330188
 - ... and 3 more: https://git.openjdk.org/jdk/compare/ebc520e8...2a023349

-------------

Changes: https://git.openjdk.org/jdk/pull/18787/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18787&range=05
  Stats: 107 lines in 37 files changed: 46 ins; 7 del; 54 mod
  Patch: https://git.openjdk.org/jdk/pull/18787.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18787/head:pull/18787

PR: https://git.openjdk.org/jdk/pull/18787

From darcy at openjdk.org  Fri May 24 19:53:04 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 24 May 2024 19:53:04 GMT
Subject: RFR: 8320575: generic type information lost on mandated parameters
 of record's compact constructors [v7]
In-Reply-To: <bCnoz4fGqSk4tcwn0rcIitmuEoRwAhd4xutzKtC64Sk=.0706cb8f-6a43-4893-8039-3514f9ab248d@github.com>
References: <20VdLsPE7Md_hxgniEhF0WPmdo_WXqbBswWdn2Az9N4=.0821e94c-4745-41e9-95a4-147f98657718@github.com>
 <UHA4xz5Ute6D_dTNMO4Ki4Jw7I3U7i6D5idwqPiuQ_w=.d44fe606-37f4-4451-9674-a0b1fa823647@github.com>
 <8kc1FcJ-ilYErhHEJRu9S_64FWwg8lI5kZfTPDEeHYA=.7b75a759-2927-4434-8ec6-24f127f01a7e@github.com>
 <bCnoz4fGqSk4tcwn0rcIitmuEoRwAhd4xutzKtC64Sk=.0706cb8f-6a43-4893-8039-3514f9ab248d@github.com>
Message-ID: <uaW0e5mb2985hboSCx69lv5SKsHAAGd2qYKxA-BZbXQ=.3553edcb-6238-4247-9a40-4431938053f3@github.com>

On Fri, 10 May 2024 21:06:22 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> As the core reflection code will encounter record classes compiled before and after the javac code generation change, if the old behavior can be triggered in javac using `--release $OLD`/`--source $OLD`, that would be helpful to include as part of the testing.
>
> @jddarcy I have uploaded a new commit addressing your comments, thanks

@vicente-romero-oracle , I think the current iteration of the specification changes look good.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17070#issuecomment-2130258071

From sgibbons at openjdk.org  Fri May 24 19:55:40 2024
From: sgibbons at openjdk.org (Scott Gibbons)
Date: Fri, 24 May 2024 19:55:40 GMT
Subject: RFR: 8320448: Accelerate IndexOf using AVX2 [v38]
In-Reply-To: <uWi4QxH31hL93771gkl_GgvP0m84IRSoR_1Yi8hD17E=.bc6ed458-7081-4c3f-9348-f59358fa05a4@github.com>
References: <uWi4QxH31hL93771gkl_GgvP0m84IRSoR_1Yi8hD17E=.bc6ed458-7081-4c3f-9348-f59358fa05a4@github.com>
Message-ID: <nDwq515-pZGnnCsqW0nkRtlqIyhnvqKXFTydeaXztHo=.eb511293-d67b-4a06-b792-264087af40d0@github.com>

> Re-write the IndexOf code without the use of the pcmpestri instruction, only using AVX2 instructions.  This change accelerates String.IndexOf on average 1.3x for AVX2.  The benchmark numbers:
> 
> 
> Benchmark	                                               Score		Latest		
> StringIndexOf.advancedWithMediumSub   343.573		317.934		0.925375393x
> StringIndexOf.advancedWithShortSub1	  1039.081		1053.96		1.014319384x
> StringIndexOf.advancedWithShortSub2	      55.828		110.541		1.980027943x
> StringIndexOf.constantPattern	                9.361		11.906		1.271872663x
> StringIndexOf.searchCharLongSuccess	        4.216		4.218		1.000474383x
> StringIndexOf.searchCharMediumSuccess	3.133		3.216		1.02649218x
> StringIndexOf.searchCharShortSuccess	3.76		        3.761		1.000265957x
> StringIndexOf.success	                                9.186		9.713		1.057369911x
> StringIndexOf.successBig	                      14.341		46.343		3.231504079x
> StringIndexOfChar.latin1_AVX2_String	  6220.918		12154.52		1.953814533x
> StringIndexOfChar.latin1_AVX2_char	  5503.556		5540.044		1.006629895x
> StringIndexOfChar.latin1_SSE4_String	  6978.854		6818.689		0.977049957x
> StringIndexOfChar.latin1_SSE4_char	  5657.499		5474.624		0.967675646x
> StringIndexOfChar.latin1_Short_String	  7132.541		6863.359		0.962260014x
> StringIndexOfChar.latin1_Short_char	16013.389	      16162.437		1.009307711x
> StringIndexOfChar.latin1_mixed_String	  7386.123	      14771.622		1.999915517x
> StringIndexOfChar.latin1_mixed_char	  9901.671		9782.245		0.987938803

Scott Gibbons has updated the pull request incrementally with one additional commit since the last revision:

  Test clarifications

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/16753/files
  - new: https://git.openjdk.org/jdk/pull/16753/files/5d10a20b..485d02fd

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16753&range=37
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16753&range=36-37

  Stats: 69 lines in 2 files changed: 16 ins; 10 del; 43 mod
  Patch: https://git.openjdk.org/jdk/pull/16753.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16753/head:pull/16753

PR: https://git.openjdk.org/jdk/pull/16753

From sgibbons at openjdk.org  Fri May 24 19:55:40 2024
From: sgibbons at openjdk.org (Scott Gibbons)
Date: Fri, 24 May 2024 19:55:40 GMT
Subject: RFR: 8320448: Accelerate IndexOf using AVX2 [v19]
In-Reply-To: <GKHsqPifhlm2OdzYjwNOUGeqYmRiJxJlFd3iB_UrlZs=.32565158-6e64-4c3a-a4d6-bf4c2064a714@github.com>
References: <uWi4QxH31hL93771gkl_GgvP0m84IRSoR_1Yi8hD17E=.bc6ed458-7081-4c3f-9348-f59358fa05a4@github.com>
 <eQ4OBFrF8JlDJ1h9awTDOc0kfCc37IlL5vdqtuaqls0=.8f00616d-08e1-4f28-a7a5-5095116d2595@github.com>
 <aTbnceYj7mQGE4hpCoeUqv5r-W8iHSI_EqVncR0iU_s=.6a63f8c5-eafb-48d5-a871-4cc475e0f63f@github.com>
 <VO8cxJFwYuRGtF7af2NsAAIC2cmWQVSPb0_pkN-wm-E=.738560f5-0763-49d6-87fa-83c0b717ce4a@github.com>
 <GKHsqPifhlm2OdzYjwNOUGeqYmRiJxJlFd3iB_UrlZs=.32565158-6e64-4c3a-a4d6-bf4c2064a714@github.com>
Message-ID: <nbqLbA6wXgT4a9T8yyUyvIREOpaNqPcpVCqXqOioGBk=.0f2c26dd-efb9-4933-8c15-98e713f6a246@github.com>

On Fri, 24 May 2024 18:32:53 GMT, Volodymyr Paprotski <duke at openjdk.org> wrote:

>> Fixed
>
> (missed a `git add`? don't see the updates for this file)

Hmmm... Not sure what happened.

>> Since we're only concerned with the delta of performance, does this really matter?  Can you suggest an alternative?
>
> The needle really should be like the all the other strings, e.g. `dataStringHuge` itself, generated by the setup. 
> 
> As to weather it really matters; the answer is Amdahl's law. You can indeed measure the delta, but you can't measure the speedup of just the indexOf; not with repeat and concatenation obscuring the numbers.

I have to believe that any relatively smart compiler would recognize that as a compile-time constant and make the change irrelevant.  I've yielded to your desire and changed the code.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1613956309
PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1613955264

From sgibbons at openjdk.org  Fri May 24 19:55:43 2024
From: sgibbons at openjdk.org (Scott Gibbons)
Date: Fri, 24 May 2024 19:55:43 GMT
Subject: RFR: 8320448: Accelerate IndexOf using AVX2 [v18]
In-Reply-To: <aTbnceYj7mQGE4hpCoeUqv5r-W8iHSI_EqVncR0iU_s=.6a63f8c5-eafb-48d5-a871-4cc475e0f63f@github.com>
References: <uWi4QxH31hL93771gkl_GgvP0m84IRSoR_1Yi8hD17E=.bc6ed458-7081-4c3f-9348-f59358fa05a4@github.com>
 <eQ4OBFrF8JlDJ1h9awTDOc0kfCc37IlL5vdqtuaqls0=.8f00616d-08e1-4f28-a7a5-5095116d2595@github.com>
 <aTbnceYj7mQGE4hpCoeUqv5r-W8iHSI_EqVncR0iU_s=.6a63f8c5-eafb-48d5-a871-4cc475e0f63f@github.com>
Message-ID: <eYkDoQSABoMpu6ONf0fYNt3h8-3SLjrG7JPSlKkrIOs=.8dcc81cf-03da-47f5-b49a-58196fe1fbf2@github.com>

On Wed, 15 May 2024 19:41:58 GMT, Volodymyr Paprotski <duke at openjdk.org> wrote:

>> Scott Gibbons has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 50 commits:
>> 
>>  - Merge remote-tracking branch 'origin/master' into indexof
>>  - Move arrays_equals back to c2_MacroAssembler
>>  - Merge branch 'openjdk:master' into indexof
>>  - Remove infinite loop (used for debugging)
>>  - Merge branch 'openjdk:master' into indexof
>>  - Cleaned up, ready for review
>>  - Pre-cleanup code
>>  - Add JMH. Add 16-byte compares to arrays_equals
>>  - Better method for mask creation
>>  - Merge branch 'openjdk:master' into indexof
>>  - ... and 40 more: https://git.openjdk.org/jdk/compare/b20fa7b4...f52d281d
>
> test/jdk/java/lang/StringBuffer/IndexOf.java line 81:
> 
>> 79:   String shs = (new String((hs_charset == StandardCharsets.UTF_16) ? haystack_16 : haystack)).substring(0, haystackSize);
>> 80: 
>> 81:   shs = "$&),,18+-!'8)+";
> 
> Should really keep the original test unmodified and add new tests as needed

The test functionality was not changed.  I just added printing of information when a failure occurs.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1613914184

From sgibbons at openjdk.org  Fri May 24 19:55:43 2024
From: sgibbons at openjdk.org (Scott Gibbons)
Date: Fri, 24 May 2024 19:55:43 GMT
Subject: RFR: 8320448: Accelerate IndexOf using AVX2 [v19]
In-Reply-To: <aTbnceYj7mQGE4hpCoeUqv5r-W8iHSI_EqVncR0iU_s=.6a63f8c5-eafb-48d5-a871-4cc475e0f63f@github.com>
References: <uWi4QxH31hL93771gkl_GgvP0m84IRSoR_1Yi8hD17E=.bc6ed458-7081-4c3f-9348-f59358fa05a4@github.com>
 <eQ4OBFrF8JlDJ1h9awTDOc0kfCc37IlL5vdqtuaqls0=.8f00616d-08e1-4f28-a7a5-5095116d2595@github.com>
 <aTbnceYj7mQGE4hpCoeUqv5r-W8iHSI_EqVncR0iU_s=.6a63f8c5-eafb-48d5-a871-4cc475e0f63f@github.com>
Message-ID: <G8G62lRk-T8coGzno_AyPlUbBW-UmVevNipvmbXUeAU=.8229009b-a686-4be0-aa42-7fb556af22e0@github.com>

On Wed, 15 May 2024 19:34:40 GMT, Volodymyr Paprotski <duke at openjdk.org> wrote:

>> Scott Gibbons has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Rearrange; add lambdas for clarity
>
> test/jdk/java/lang/StringBuffer/IndexOf.java line 90:
> 
>> 88: 
>> 89:   // printStringBytes(shs.getBytes(hs_charset));
>> 90:   for (int i = 0; i < 200000; i++) {
> 
> This wont be a deterministic way to reach the intrinsic. I would suggest copying the idea from test/jdk/com/sun/crypto/provider/Cipher/ChaCha20/unittest/Poly1305UnitTestDriver.java
> 
> i.e. Have two `@run main` invocations at the top of this file, one with default parameters, one with  `-Xcomp -XX:-TieredCompilation`. You dont need a 'driver' program, that was to handle something else.
> 
> 
> /*
>  * @test
>  * @modules java.base/com.sun.crypto.provider
>  * @run main java.base/com.sun.crypto.provider.Poly1305KAT
>  * @summary Unit test for com.sun.crypto.provider.Poly1305.
>  */
> 
> /*
>  * @test
>  * @modules java.base/com.sun.crypto.provider
>  * @summary Unit test for IntrinsicCandidate in com.sun.crypto.provider.Poly1305.
>  * @run main/othervm -Xcomp -XX:-TieredCompilation -XX:+UnlockDiagnosticVMOptions -XX:+ForceUnreachable java.base/com.sun.crypto.provider.Poly1305KAT
>  */

Done.

> test/jdk/java/lang/StringBuffer/IndexOf.java line 126:
> 
>> 124:     int aNewLength = getRandomIndex(min, max);
>> 125:     for (int y = 0; y < aNewLength; y++) {
>> 126:       int achar = generator.nextInt(30) + 30;
> 
> This will only ever generate LL cases, i.e. chars from [30,60]. Could be parametrized to also produce utf16 if instead of 30, offset was in the unicode range

Original code.

> test/jdk/java/lang/StringBuffer/IndexOf.java line 199:
> 
>> 197:                 System.out.println("Source="+sourceString.substring(hsBegin, hsBegin + haystackLen));
>> 198:                 System.out.println("Target="+targetString.substring(nBegin, nBegin + needleLen));
>> 199:                 System.out.println("haystackLen="+haystackLen+" neeldeLen="+needleLen+" hsBegin="+hsBegin+" nBegin="+nBegin+
> 
> This looks like 'development scaffolding' (i.e. printf debugging) that was meant to be removed

This is additional information printed upon failure instead of just saying "failed"

> test/jdk/java/lang/StringBuffer/IndexOf.java line 295:
> 
>> 293:         sourceString = generateTestString(99, 100);
>> 294:         sourceBuffer = new StringBuffer(sourceString);
>> 295:         targetString = generateTestString(10, 11);
> 
> Generate a random int [0,1,2] for LL, UU, UL, pass that as parameter to generateTestString() to test the other paths. Same for other tests in this file using this pattern.
> 
> This test is specific to haystacklen=100, needlelen=10..  what about other haystack/needle sizes to exercise all the paths in the intrinsic assembler (i.e. haystack >=, <=32, needlelen ={1,2,3,4,5..32..}). Elsewhere already?

Original code.

> test/jdk/java/lang/StringBuffer/IndexOf.java line 360:
> 
>> 358:         System.err.println("  sAnswer = " + sAnswer + ", sbAnswer = " + sbAnswer);
>> 359:         System.err.println("  testString = '" + testString + "'");
>> 360:         System.err.println("  testBuffer = '" + testBuffer + "'");
> 
> tracing left here and further down

Adding more information on failure.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1613915508
PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1613919180
PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1613920449
PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1613922554
PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1613923075

From kvn at openjdk.org  Fri May 24 20:15:13 2024
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Fri, 24 May 2024 20:15:13 GMT
Subject: RFR: 8320448: Accelerate IndexOf using AVX2 [v38]
In-Reply-To: <nDwq515-pZGnnCsqW0nkRtlqIyhnvqKXFTydeaXztHo=.eb511293-d67b-4a06-b792-264087af40d0@github.com>
References: <uWi4QxH31hL93771gkl_GgvP0m84IRSoR_1Yi8hD17E=.bc6ed458-7081-4c3f-9348-f59358fa05a4@github.com>
 <nDwq515-pZGnnCsqW0nkRtlqIyhnvqKXFTydeaXztHo=.eb511293-d67b-4a06-b792-264087af40d0@github.com>
Message-ID: <MImPmWGxi3FpwVq1rk0Rohfh3_5H_iqAgblEpn8_TQQ=.cbb5359c-d8df-48b8-8a0f-e9976923475f@github.com>

On Fri, 24 May 2024 19:55:40 GMT, Scott Gibbons <sgibbons at openjdk.org> wrote:

>> Re-write the IndexOf code without the use of the pcmpestri instruction, only using AVX2 instructions.  This change accelerates String.IndexOf on average 1.3x for AVX2.  The benchmark numbers:
>> 
>> 
>> Benchmark	                                               Score		Latest		
>> StringIndexOf.advancedWithMediumSub   343.573		317.934		0.925375393x
>> StringIndexOf.advancedWithShortSub1	  1039.081		1053.96		1.014319384x
>> StringIndexOf.advancedWithShortSub2	      55.828		110.541		1.980027943x
>> StringIndexOf.constantPattern	                9.361		11.906		1.271872663x
>> StringIndexOf.searchCharLongSuccess	        4.216		4.218		1.000474383x
>> StringIndexOf.searchCharMediumSuccess	3.133		3.216		1.02649218x
>> StringIndexOf.searchCharShortSuccess	3.76		        3.761		1.000265957x
>> StringIndexOf.success	                                9.186		9.713		1.057369911x
>> StringIndexOf.successBig	                      14.341		46.343		3.231504079x
>> StringIndexOfChar.latin1_AVX2_String	  6220.918		12154.52		1.953814533x
>> StringIndexOfChar.latin1_AVX2_char	  5503.556		5540.044		1.006629895x
>> StringIndexOfChar.latin1_SSE4_String	  6978.854		6818.689		0.977049957x
>> StringIndexOfChar.latin1_SSE4_char	  5657.499		5474.624		0.967675646x
>> StringIndexOfChar.latin1_Short_String	  7132.541		6863.359		0.962260014x
>> StringIndexOfChar.latin1_Short_char	16013.389	      16162.437		1.009307711x
>> StringIndexOfChar.latin1_mixed_String	  7386.123	      14771.622		1.999915517x
>> StringIndexOfChar.latin1_mixed_char	  9901.671		9782.245		0.987938803
>
> Scott Gibbons has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Test clarifications

test/jdk/java/lang/StringBuffer/IndexOf.java line 28:

> 26:  * @summary Test indexOf and lastIndexOf
> 27:  * @run main/othervm IndexOf
> 28:  * @run main/othervm -XX:+IgnoreUnrecognizedVMOptions -Xcomp -XX:-TieredCompilation -XX:UseAVX=2 -XX:+UnlockDiagnosticVMOptions -XX:+EnableX86ECoreOpts IndexOf

I suggest to split it into 2 subtest jobs and use `@requires vm.cpu.features ~= ".*avx2.*"` for second which specified `-XX:UseAVX=2`.
See `compiler/loopopts/superword/TestDependencyOffsets.java` for example.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1613972734

From sgibbons at openjdk.org  Fri May 24 20:26:40 2024
From: sgibbons at openjdk.org (Scott Gibbons)
Date: Fri, 24 May 2024 20:26:40 GMT
Subject: RFR: 8320448: Accelerate IndexOf using AVX2 [v39]
In-Reply-To: <uWi4QxH31hL93771gkl_GgvP0m84IRSoR_1Yi8hD17E=.bc6ed458-7081-4c3f-9348-f59358fa05a4@github.com>
References: <uWi4QxH31hL93771gkl_GgvP0m84IRSoR_1Yi8hD17E=.bc6ed458-7081-4c3f-9348-f59358fa05a4@github.com>
Message-ID: <seyjwbXYPgJlcp84r2vr5D5UBTNPWeXaRmyn7CwhTwE=.7f41f1c5-14dd-4366-882d-2fdc0346b81d@github.com>

> Re-write the IndexOf code without the use of the pcmpestri instruction, only using AVX2 instructions.  This change accelerates String.IndexOf on average 1.3x for AVX2.  The benchmark numbers:
> 
> 
> Benchmark	                                               Score		Latest		
> StringIndexOf.advancedWithMediumSub   343.573		317.934		0.925375393x
> StringIndexOf.advancedWithShortSub1	  1039.081		1053.96		1.014319384x
> StringIndexOf.advancedWithShortSub2	      55.828		110.541		1.980027943x
> StringIndexOf.constantPattern	                9.361		11.906		1.271872663x
> StringIndexOf.searchCharLongSuccess	        4.216		4.218		1.000474383x
> StringIndexOf.searchCharMediumSuccess	3.133		3.216		1.02649218x
> StringIndexOf.searchCharShortSuccess	3.76		        3.761		1.000265957x
> StringIndexOf.success	                                9.186		9.713		1.057369911x
> StringIndexOf.successBig	                      14.341		46.343		3.231504079x
> StringIndexOfChar.latin1_AVX2_String	  6220.918		12154.52		1.953814533x
> StringIndexOfChar.latin1_AVX2_char	  5503.556		5540.044		1.006629895x
> StringIndexOfChar.latin1_SSE4_String	  6978.854		6818.689		0.977049957x
> StringIndexOfChar.latin1_SSE4_char	  5657.499		5474.624		0.967675646x
> StringIndexOfChar.latin1_Short_String	  7132.541		6863.359		0.962260014x
> StringIndexOfChar.latin1_Short_char	16013.389	      16162.437		1.009307711x
> StringIndexOfChar.latin1_mixed_String	  7386.123	      14771.622		1.999915517x
> StringIndexOfChar.latin1_mixed_char	  9901.671		9782.245		0.987938803

Scott Gibbons has updated the pull request incrementally with one additional commit since the last revision:

  Split into two subtest jobs

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/16753/files
  - new: https://git.openjdk.org/jdk/pull/16753/files/485d02fd..69ca8d13

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16753&range=38
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16753&range=37-38

  Stats: 8 lines in 1 file changed: 8 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/16753.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16753/head:pull/16753

PR: https://git.openjdk.org/jdk/pull/16753

From duke at openjdk.org  Fri May 24 20:26:40 2024
From: duke at openjdk.org (Volodymyr Paprotski)
Date: Fri, 24 May 2024 20:26:40 GMT
Subject: RFR: 8320448: Accelerate IndexOf using AVX2 [v37]
In-Reply-To: <4xYUBsOJ_eDSuj6w9AjUo_6gFN_9piWR-ChLrHQoXl4=.88756684-8e9c-48e3-8b59-f5f684b81cde@github.com>
References: <uWi4QxH31hL93771gkl_GgvP0m84IRSoR_1Yi8hD17E=.bc6ed458-7081-4c3f-9348-f59358fa05a4@github.com>
 <4xYUBsOJ_eDSuj6w9AjUo_6gFN_9piWR-ChLrHQoXl4=.88756684-8e9c-48e3-8b59-f5f684b81cde@github.com>
Message-ID: <JKRjYVdOhgtD-GeDuecIVQ4hth9JFdfNdt_NFhgoZhg=.95c14b1f-c149-45df-b825-d30152aa0416@github.com>

On Fri, 24 May 2024 15:32:26 GMT, Scott Gibbons <sgibbons at openjdk.org> wrote:

>> Re-write the IndexOf code without the use of the pcmpestri instruction, only using AVX2 instructions.  This change accelerates String.IndexOf on average 1.3x for AVX2.  The benchmark numbers:
>> 
>> 
>> Benchmark	                                               Score		Latest		
>> StringIndexOf.advancedWithMediumSub   343.573		317.934		0.925375393x
>> StringIndexOf.advancedWithShortSub1	  1039.081		1053.96		1.014319384x
>> StringIndexOf.advancedWithShortSub2	      55.828		110.541		1.980027943x
>> StringIndexOf.constantPattern	                9.361		11.906		1.271872663x
>> StringIndexOf.searchCharLongSuccess	        4.216		4.218		1.000474383x
>> StringIndexOf.searchCharMediumSuccess	3.133		3.216		1.02649218x
>> StringIndexOf.searchCharShortSuccess	3.76		        3.761		1.000265957x
>> StringIndexOf.success	                                9.186		9.713		1.057369911x
>> StringIndexOf.successBig	                      14.341		46.343		3.231504079x
>> StringIndexOfChar.latin1_AVX2_String	  6220.918		12154.52		1.953814533x
>> StringIndexOfChar.latin1_AVX2_char	  5503.556		5540.044		1.006629895x
>> StringIndexOfChar.latin1_SSE4_String	  6978.854		6818.689		0.977049957x
>> StringIndexOfChar.latin1_SSE4_char	  5657.499		5474.624		0.967675646x
>> StringIndexOfChar.latin1_Short_String	  7132.541		6863.359		0.962260014x
>> StringIndexOfChar.latin1_Short_char	16013.389	      16162.437		1.009307711x
>> StringIndexOfChar.latin1_mixed_String	  7386.123	      14771.622		1.999915517x
>> StringIndexOfChar.latin1_mixed_char	  9901.671		9782.245		0.987938803
>
> Scott Gibbons has updated the pull request incrementally with one additional commit since the last revision:
> 
>   mov64 => lea(InternalAddress)

src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 4633:

> 4631:     andl(result, 0x0000000f);  //   tail count (in bytes)
> 4632:     andl(limit, 0xfffffff0);   // vector count (in bytes)
> 4633:     jcc(Assembler::zero, COMPARE_TAIL);

In the `expand_ary2` case, this is the same andl/compare as line 4549; i.e. I think you can just put `jcc(Assembler::zero, COMPARE_TAIL);` on line 4549, inside the if (and move the other jcc into the else branch)?

src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 4639:

> 4637:     negptr(limit);
> 4638: 
> 4639:     bind(COMPARE_WIDE_VECTORS_16);

Understanding-check.. this loop will execute at most 2 times, right?

i.e. process as many 32-byte chunks as possible, then 1-or-2 16-byte chunks then byte-by-byte?

(Still a good optimization, just trying to understand the scope)

src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 4718:

> 4716:     jmp(TRUE_LABEL);
> 4717:   } else {
> 4718:     movl(chr, Address(ary1, limit, scaleFactor));

scaleFactor is always Address::times_1 here (expand_ary2==false), might be clearer to change it back

test/jdk/java/lang/StringBuffer/ECoreIndexOf.java line 57:

> 55: 
> 56:     generator = new Random();
> 57:     long seed = generator.nextLong();//-5291521104060046276L;

dead code

test/jdk/java/lang/StringBuffer/ECoreIndexOf.java line 63:

> 61:     ///////////////////////////  WARM-UP //////////////////////////
> 62: 
> 63:     for (int i = 0; i < 20000; i++) {

-Xcomp should be more deterministic (and quicker) way to reach the intrinsic (i.e. like the other tests)

On other hand, perhaps this doesn't matter? @vnkozlov Understanding-check please.. these tests will run as part of every build from this point-till-infinity; Therefore, long test will affect every openjdk developer. But if this test is not run on every build, then the build-time does not matter, then this test can run for as long as it 'wants'.

test/jdk/java/lang/StringBuffer/ECoreIndexOf.java line 160:

> 158:   }
> 159: 
> 160:   private static String generateTestString(int min, int max) {

I see you have various `Charset[] charSets` above, but this function still only generates LL. Are those separate tests? Or am I missing some concatenation somewhere that will convert the generated string string to the correct encoding?

You could had implemented my suggestion from IndexOf.generateTestString here instead, so that the tests that do call this function endup with multiple encodings; i.e. similar to what you already do in the next function.

I suppose, with addition of String/IndexOf.java that is a moot point.

test/jdk/java/lang/StringBuffer/ECoreIndexOf.java line 185:

> 183:   }
> 184: 
> 185:   private static int indexOfKernel(String haystack, String needle) {

Is the intention of kernels not to be inlined so that it would be part of separate compilation?

If so, you probably want to annotate it with `@CompilerControl(CompilerControl.Mode.DONT_INLINE)`

i.e. https://github.com/openjdk/jmh/blob/master/jmh-samples/src/main/java/org/openjdk/jmh/samples/JMHSample_16_CompilerControl.java

test/jdk/java/lang/StringBuffer/ECoreIndexOf.java line 539:

> 537:     failCount = indexOfKernel("", "");
> 538: 
> 539:     for (int x = 0; x < 1000000; x++) {

Should we be concerned about the increased run-time? Or does this execute 'quickly enough'

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1613940896
PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1613943518
PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1613946470
PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1613955620
PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1613955354
PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1613970971
PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1613967681
PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1613983597

From sgibbons at openjdk.org  Fri May 24 20:26:41 2024
From: sgibbons at openjdk.org (Scott Gibbons)
Date: Fri, 24 May 2024 20:26:41 GMT
Subject: RFR: 8320448: Accelerate IndexOf using AVX2 [v38]
In-Reply-To: <MImPmWGxi3FpwVq1rk0Rohfh3_5H_iqAgblEpn8_TQQ=.cbb5359c-d8df-48b8-8a0f-e9976923475f@github.com>
References: <uWi4QxH31hL93771gkl_GgvP0m84IRSoR_1Yi8hD17E=.bc6ed458-7081-4c3f-9348-f59358fa05a4@github.com>
 <nDwq515-pZGnnCsqW0nkRtlqIyhnvqKXFTydeaXztHo=.eb511293-d67b-4a06-b792-264087af40d0@github.com>
 <MImPmWGxi3FpwVq1rk0Rohfh3_5H_iqAgblEpn8_TQQ=.cbb5359c-d8df-48b8-8a0f-e9976923475f@github.com>
Message-ID: <cbt591rlaYkzN1_MEpGj9ZFSREliPRPKKoKRPmX_g-E=.ad480a89-9896-4973-b5f1-12df202a4edf@github.com>

On Fri, 24 May 2024 20:12:07 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> Scott Gibbons has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Test clarifications
>
> test/jdk/java/lang/StringBuffer/IndexOf.java line 28:
> 
>> 26:  * @summary Test indexOf and lastIndexOf
>> 27:  * @run main/othervm IndexOf
>> 28:  * @run main/othervm -XX:+IgnoreUnrecognizedVMOptions -Xcomp -XX:-TieredCompilation -XX:UseAVX=2 -XX:+UnlockDiagnosticVMOptions -XX:+EnableX86ECoreOpts IndexOf
> 
> I suggest to split it into 2 subtest jobs and use `@requires vm.cpu.features ~= ".*avx2.*"` for second which specified `-XX:UseAVX=2`.
> See `compiler/loopopts/superword/TestDependencyOffsets.java` for example.

Right.  Done.  Also added `@requires vm.compiler2.enabled` since my stub is only valid with C2.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1613985672

From duke at openjdk.org  Fri May 24 20:26:41 2024
From: duke at openjdk.org (Volodymyr Paprotski)
Date: Fri, 24 May 2024 20:26:41 GMT
Subject: RFR: 8320448: Accelerate IndexOf using AVX2 [v19]
In-Reply-To: <xwgol0oMgfd10mFw593hgE0wgaTsjCxA1ETGX3ZQLM0=.5a0bab49-7c5b-49ba-9a2c-4bee3a04ccd7@github.com>
References: <uWi4QxH31hL93771gkl_GgvP0m84IRSoR_1Yi8hD17E=.bc6ed458-7081-4c3f-9348-f59358fa05a4@github.com>
 <eQ4OBFrF8JlDJ1h9awTDOc0kfCc37IlL5vdqtuaqls0=.8f00616d-08e1-4f28-a7a5-5095116d2595@github.com>
 <aTbnceYj7mQGE4hpCoeUqv5r-W8iHSI_EqVncR0iU_s=.6a63f8c5-eafb-48d5-a871-4cc475e0f63f@github.com>
 <xwgol0oMgfd10mFw593hgE0wgaTsjCxA1ETGX3ZQLM0=.5a0bab49-7c5b-49ba-9a2c-4bee3a04ccd7@github.com>
Message-ID: <iIEttZzZiGs6zxIzIVBAZx59BLiOxpOZWqy6TCR3b5A=.64cf53cf-af49-428e-9e39-2f113f586378@github.com>

On Wed, 22 May 2024 14:50:40 GMT, Scott Gibbons <sgibbons at openjdk.org> wrote:

>> test/jdk/java/lang/StringBuffer/IndexOf.java line 284:
>> 
>>> 282: 
>>> 283:   // Note: it is possible although highly improbable that failCount will
>>> 284:   // be > 0 even if everthing is working ok
>> 
>> This sounds like either a bug or a testcase bug? Same as line 301, `extremely remote possibility of > 1 match`?
>
> This was there from the original author.  I think they were trying to infer that a match could occur in the rare case that the same random string was produced.  They're random after all, and there's no reason the same sequence could be generated.

Makes sense

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1613872215

From sgibbons at openjdk.org  Fri May 24 20:47:23 2024
From: sgibbons at openjdk.org (Scott Gibbons)
Date: Fri, 24 May 2024 20:47:23 GMT
Subject: RFR: 8320448: Accelerate IndexOf using AVX2 [v40]
In-Reply-To: <uWi4QxH31hL93771gkl_GgvP0m84IRSoR_1Yi8hD17E=.bc6ed458-7081-4c3f-9348-f59358fa05a4@github.com>
References: <uWi4QxH31hL93771gkl_GgvP0m84IRSoR_1Yi8hD17E=.bc6ed458-7081-4c3f-9348-f59358fa05a4@github.com>
Message-ID: <jiMRlpCi04a3MIRYczPEv3tpwe1-va-BZf1vXbqQtDw=.5144a4e7-5d6f-4194-ab6b-f525c13e6448@github.com>

> Re-write the IndexOf code without the use of the pcmpestri instruction, only using AVX2 instructions.  This change accelerates String.IndexOf on average 1.3x for AVX2.  The benchmark numbers:
> 
> 
> Benchmark	                                               Score		Latest		
> StringIndexOf.advancedWithMediumSub   343.573		317.934		0.925375393x
> StringIndexOf.advancedWithShortSub1	  1039.081		1053.96		1.014319384x
> StringIndexOf.advancedWithShortSub2	      55.828		110.541		1.980027943x
> StringIndexOf.constantPattern	                9.361		11.906		1.271872663x
> StringIndexOf.searchCharLongSuccess	        4.216		4.218		1.000474383x
> StringIndexOf.searchCharMediumSuccess	3.133		3.216		1.02649218x
> StringIndexOf.searchCharShortSuccess	3.76		        3.761		1.000265957x
> StringIndexOf.success	                                9.186		9.713		1.057369911x
> StringIndexOf.successBig	                      14.341		46.343		3.231504079x
> StringIndexOfChar.latin1_AVX2_String	  6220.918		12154.52		1.953814533x
> StringIndexOfChar.latin1_AVX2_char	  5503.556		5540.044		1.006629895x
> StringIndexOfChar.latin1_SSE4_String	  6978.854		6818.689		0.977049957x
> StringIndexOfChar.latin1_SSE4_char	  5657.499		5474.624		0.967675646x
> StringIndexOfChar.latin1_Short_String	  7132.541		6863.359		0.962260014x
> StringIndexOfChar.latin1_Short_char	16013.389	      16162.437		1.009307711x
> StringIndexOfChar.latin1_mixed_String	  7386.123	      14771.622		1.999915517x
> StringIndexOfChar.latin1_mixed_char	  9901.671		9782.245		0.987938803

Scott Gibbons has updated the pull request incrementally with one additional commit since the last revision:

  Review comments.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/16753/files
  - new: https://git.openjdk.org/jdk/pull/16753/files/69ca8d13..be001e2c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16753&range=39
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16753&range=38-39

  Stats: 13 lines in 2 files changed: 10 ins; 1 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/16753.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16753/head:pull/16753

PR: https://git.openjdk.org/jdk/pull/16753

From sgibbons at openjdk.org  Fri May 24 20:47:24 2024
From: sgibbons at openjdk.org (Scott Gibbons)
Date: Fri, 24 May 2024 20:47:24 GMT
Subject: RFR: 8320448: Accelerate IndexOf using AVX2 [v37]
In-Reply-To: <JKRjYVdOhgtD-GeDuecIVQ4hth9JFdfNdt_NFhgoZhg=.95c14b1f-c149-45df-b825-d30152aa0416@github.com>
References: <uWi4QxH31hL93771gkl_GgvP0m84IRSoR_1Yi8hD17E=.bc6ed458-7081-4c3f-9348-f59358fa05a4@github.com>
 <4xYUBsOJ_eDSuj6w9AjUo_6gFN_9piWR-ChLrHQoXl4=.88756684-8e9c-48e3-8b59-f5f684b81cde@github.com>
 <JKRjYVdOhgtD-GeDuecIVQ4hth9JFdfNdt_NFhgoZhg=.95c14b1f-c149-45df-b825-d30152aa0416@github.com>
Message-ID: <CiGyOjJRAxrpvCiabceN1M1AvbWQz2orh4YQ8YQ4jl0=.1ebff8e5-15cd-44ee-a92a-1161f8744215@github.com>

On Fri, 24 May 2024 19:30:54 GMT, Volodymyr Paprotski <duke at openjdk.org> wrote:

>> Scott Gibbons has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   mov64 => lea(InternalAddress)
>
> src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 4633:
> 
>> 4631:     andl(result, 0x0000000f);  //   tail count (in bytes)
>> 4632:     andl(limit, 0xfffffff0);   // vector count (in bytes)
>> 4633:     jcc(Assembler::zero, COMPARE_TAIL);
> 
> In the `expand_ary2` case, this is the same andl/compare as line 4549; i.e. I think you can just put `jcc(Assembler::zero, COMPARE_TAIL);` on line 4549, inside the if (and move the other jcc into the else branch)?

OK.  Shortens pathlength by 4 instructions.

> src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 4639:
> 
>> 4637:     negptr(limit);
>> 4638: 
>> 4639:     bind(COMPARE_WIDE_VECTORS_16);
> 
> Understanding-check.. this loop will execute at most 2 times, right?
> 
> i.e. process as many 32-byte chunks as possible, then 1-or-2 16-byte chunks then byte-by-byte?
> 
> (Still a good optimization, just trying to understand the scope)

Yes.

> src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 4718:
> 
>> 4716:     jmp(TRUE_LABEL);
>> 4717:   } else {
>> 4718:     movl(chr, Address(ary1, limit, scaleFactor));
> 
> scaleFactor is always Address::times_1 here (expand_ary2==false), might be clearer to change it back

*Sigh*.  Changing it back.

> test/jdk/java/lang/StringBuffer/ECoreIndexOf.java line 57:
> 
>> 55: 
>> 56:     generator = new Random();
>> 57:     long seed = generator.nextLong();//-5291521104060046276L;
> 
> dead code

Fixed

> test/jdk/java/lang/StringBuffer/ECoreIndexOf.java line 63:
> 
>> 61:     ///////////////////////////  WARM-UP //////////////////////////
>> 62: 
>> 63:     for (int i = 0; i < 20000; i++) {
> 
> -Xcomp should be more deterministic (and quicker) way to reach the intrinsic (i.e. like the other tests)
> 
> On other hand, perhaps this doesn't matter? @vnkozlov Understanding-check please.. these tests will run as part of every build from this point-till-infinity; Therefore, long test will affect every openjdk developer. But if this test is not run on every build, then the build-time does not matter, then this test can run for as long as it 'wants'.

This test runs in well under 2 minutes.  I'm not sure what is trying to be accomplished?

> test/jdk/java/lang/StringBuffer/ECoreIndexOf.java line 160:
> 
>> 158:   }
>> 159: 
>> 160:   private static String generateTestString(int min, int max) {
> 
> I see you have various `Charset[] charSets` above, but this function still only generates LL. Are those separate tests? Or am I missing some concatenation somewhere that will convert the generated string string to the correct encoding?
> 
> You could had implemented my suggestion from IndexOf.generateTestString here instead, so that the tests that do call this function endup with multiple encodings; i.e. similar to what you already do in the next function.
> 
> I suppose, with addition of String/IndexOf.java that is a moot point.

Yes, I think it's a moot point.  Thanks.

> test/jdk/java/lang/StringBuffer/ECoreIndexOf.java line 185:
> 
>> 183:   }
>> 184: 
>> 185:   private static int indexOfKernel(String haystack, String needle) {
> 
> Is the intention of kernels not to be inlined so that it would be part of separate compilation?
> 
> If so, you probably want to annotate it with `@CompilerControl(CompilerControl.Mode.DONT_INLINE)`
> 
> i.e. https://github.com/openjdk/jmh/blob/master/jmh-samples/src/main/java/org/openjdk/jmh/samples/JMHSample_16_CompilerControl.java

Fixed.

> test/jdk/java/lang/StringBuffer/ECoreIndexOf.java line 539:
> 
>> 537:     failCount = indexOfKernel("", "");
>> 538: 
>> 539:     for (int x = 0; x < 1000000; x++) {
> 
> Should we be concerned about the increased run-time? Or does this execute 'quickly enough'

Runs in well under 2 minutes.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1613997645
PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1613993657
PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1613998432
PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1614000081
PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1614000885
PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1614001480
PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1614002801
PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1614003072

From vromero at openjdk.org  Fri May 24 20:48:16 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 24 May 2024 20:48:16 GMT
Subject: Integrated: 8320575: generic type information lost on mandated
 parameters of record's compact constructors
In-Reply-To: <20VdLsPE7Md_hxgniEhF0WPmdo_WXqbBswWdn2Az9N4=.0821e94c-4745-41e9-95a4-147f98657718@github.com>
References: <20VdLsPE7Md_hxgniEhF0WPmdo_WXqbBswWdn2Az9N4=.0821e94c-4745-41e9-95a4-147f98657718@github.com>
Message-ID: <hK-Hs2UCHK3o3KE0HOzSIjoYiJz3whKPAN-_H5Qqpfw=.0cdefc7b-48a7-4766-a951-367b6dab30c3@github.com>

On Mon, 11 Dec 2023 23:33:16 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> Reflection is not retrieving generic type information for mandated parameters. This is a known issue which has been explicitly stated in the API of some reflection methods. Fix for [JDK-8292275](https://bugs.openjdk.org/browse/JDK-8292275) made the parameters of compact constructors of record classes `mandated` as specified in the spec. But this implied that users that previous to this change could retrieve the generic type of parameters of compact constructors now they can't anymore. The proposed fix is to try to retrieve generic type information for mandated parameters if available plus changing the spec of the related reflection methods.
> 
> TIA

This pull request has now been integrated.

Changeset: 7bf1989f
Author:    Vicente Romero <vromero at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/7bf1989f59695c3d08b4bd116fb4c022cf9661f4
Stats:     405 lines in 3 files changed: 376 ins; 6 del; 23 mod

8320575: generic type information lost on mandated parameters of record's compact constructors

Co-authored-by: Chen Liang <liach at openjdk.org>
Reviewed-by: jlahoda

-------------

PR: https://git.openjdk.org/jdk/pull/17070

From alexander.matveev at oracle.com  Fri May 24 21:14:40 2024
From: alexander.matveev at oracle.com (Alexander Matveev)
Date: Fri, 24 May 2024 21:14:40 +0000
Subject: RFR: 8332110: [macos] jpackage tries to sign added files without
 the --mac-sign option
In-Reply-To: <BA8E1B15-2616-432F-9F34-5D5171DE34F7@gmail.com>
References: <eiboU_LgwkTte_7rkPJAdDm1x_-Pzm8rdwUiY_4MAYI=.b982e161-fe24-44ab-9db5-2f1d80eb0d99@github.com>
 <B26D82CC-55A9-42E6-AD5D-418B95E5E565@gmail.com>
 <BA8E1B15-2616-432F-9F34-5D5171DE34F7@gmail.com>
Message-ID: <PH7PR10MB7055707BCDA794208E1FF19399F52@PH7PR10MB7055.namprd10.prod.outlook.com>

Hi Michael,

> Doesn?t this still leave you with an application that isn?t validly signed? And probably won?t run because of that.
Yes, it will leave you with an application that isn?t signed. I was able to run such application on same machine as it was generated by jpackage.

> For your example. This almost seems like an Apple bug if you can add a directory to the Contents directory but not a file?
Not sure if it is an Apple bug.

> Would it also generally be a good idea to include a final codesign verify to fail the build if something is wrong with the signature?
Yes, you already suggested it. See https://bugs.openjdk.org/browse/JDK-8318063 and it was closed as won?t fix because such verification is redundant.

Thanks,
Alexander

From: Michael Hall <mik3hall at gmail.com>
Date: Friday, May 24, 2024 at 1:47?AM
To: Alexander Matveev <almatvee at openjdk.org>
Cc: core-libs-dev <core-libs-dev at openjdk.org>
Subject: Re: RFR: 8332110: [macos] jpackage tries to sign added files without the --mac-sign option



On May 24, 2024, at 3:08?AM, Michael Hall <mik3hall at gmail.com> wrote:

On May 23, 2024, at 8:13?PM, Alexander Matveev <almatvee at openjdk.org<mailto:almatvee at openjdk.org>> wrote:

otherwise add additional content as post-processing step.

Doesn?t this still leave you with an application that isn?t validly signed? And probably won?t run because of that.

2) jpackage --type app-image -n Test --app-content ReadMe ...

For your example. This almost seems like an Apple bug if you can add a directory to the Contents directory but not a file?

Sorry I made my prior off-list.

Would it also generally be a good idea to include a final codesign verify to fail the build if something is wrong with the signature?

Something like?

echo '*******************'
echo 'verifying signature'
echo '*******************'
codesign -v --verbose=4 outputdir/HalfPipe.app

Expected output?

*******************
verifying signature
*******************
outputdir/HalfPipe.app: valid on disk
outputdir/HalfPipe.app: satisfies its Designated Requirement

I think I have suggested this before but don?t remember if I did an enhancement request. Maybe you do that and I?m just not aware of it if it doesn?t appear in the jpackage output.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240524/a8387c0b/attachment-0001.htm>

From bchristi at openjdk.org  Fri May 24 21:39:33 2024
From: bchristi at openjdk.org (Brent Christian)
Date: Fri, 24 May 2024 21:39:33 GMT
Subject: RFR: 8314480: Memory ordering spec updates in java.lang.ref [v32]
In-Reply-To: <R74ontYwjYg6HeZY0cWrlo0amjl4E1YsFWeuh4pda14=.08ac62df-b2f8-4b4d-b338-07adb289601b@github.com>
References: <R74ontYwjYg6HeZY0cWrlo0amjl4E1YsFWeuh4pda14=.08ac62df-b2f8-4b4d-b338-07adb289601b@github.com>
Message-ID: <B0N9o2KSYGCNvvsmnpJ3dqFoRHAR2TaVHrpOpH4WWG4=.27a02e0c-1cf1-4912-860d-3263581d7237@github.com>

> Classes in the `java.lang.ref` package would benefit from an update to bring the spec in line with how the VM already behaves. The changes would focus on _happens-before_ edges at some key points during reference processing.
> 
> A couple key things we want to be able to say are:
> - `Reference.reachabilityFence(x)` _happens-before_ reference processing occurs for 'x'.
> - `Cleaner.register()` _happens-before_ the Cleaner thread runs the registered cleaning action.
> 
> This will bring Cleaner in line (or close) with the memory visibility guarantees made for finalizers in [JLS 17.4.5](https://docs.oracle.com/javase/specs/jls/se18/html/jls-17.html#jls-17.4.5):
> _"There is a happens-before edge from the end of a constructor of an object to the start of a finalizer (?12.6) for that object."_

Brent Christian has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 69 commits:

 - Merge branch 'master' into refDocs2
 - add link to Thread.isAlive()
 - small review tweaks; shorten MemoryConsistency links
 - small grammar fixes
 - new section for finalizer memviz
 - add memviz bullet for finalization
 - remove quotes from dequeue
 - package spec updates, mostly about reference queues and dequeueing
 - move reachability section before notification; update section header
 - add details on use of reference queues; swap reachability/memviz sections
 - ... and 59 more: https://git.openjdk.org/jdk/compare/7bf1989f...d7cbf0d3

-------------

Changes: https://git.openjdk.org/jdk/pull/16644/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16644&range=31
  Stats: 226 lines in 4 files changed: 132 ins; 19 del; 75 mod
  Patch: https://git.openjdk.org/jdk/pull/16644.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16644/head:pull/16644

PR: https://git.openjdk.org/jdk/pull/16644

From sviswanathan at openjdk.org  Fri May 24 22:33:15 2024
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Fri, 24 May 2024 22:33:15 GMT
Subject: RFR: 8320448: Accelerate IndexOf using AVX2 [v40]
In-Reply-To: <jiMRlpCi04a3MIRYczPEv3tpwe1-va-BZf1vXbqQtDw=.5144a4e7-5d6f-4194-ab6b-f525c13e6448@github.com>
References: <uWi4QxH31hL93771gkl_GgvP0m84IRSoR_1Yi8hD17E=.bc6ed458-7081-4c3f-9348-f59358fa05a4@github.com>
 <jiMRlpCi04a3MIRYczPEv3tpwe1-va-BZf1vXbqQtDw=.5144a4e7-5d6f-4194-ab6b-f525c13e6448@github.com>
Message-ID: <6r30gPhGsZAoAOSYsP39qr2czQ8Wj7YMOxlP2VZZpAI=.61ee3985-d3a5-40b2-9bce-453253185600@github.com>

On Fri, 24 May 2024 20:47:23 GMT, Scott Gibbons <sgibbons at openjdk.org> wrote:

>> Re-write the IndexOf code without the use of the pcmpestri instruction, only using AVX2 instructions.  This change accelerates String.IndexOf on average 1.3x for AVX2.  The benchmark numbers:
>> 
>> 
>> Benchmark	                                               Score		Latest		
>> StringIndexOf.advancedWithMediumSub   343.573		317.934		0.925375393x
>> StringIndexOf.advancedWithShortSub1	  1039.081		1053.96		1.014319384x
>> StringIndexOf.advancedWithShortSub2	      55.828		110.541		1.980027943x
>> StringIndexOf.constantPattern	                9.361		11.906		1.271872663x
>> StringIndexOf.searchCharLongSuccess	        4.216		4.218		1.000474383x
>> StringIndexOf.searchCharMediumSuccess	3.133		3.216		1.02649218x
>> StringIndexOf.searchCharShortSuccess	3.76		        3.761		1.000265957x
>> StringIndexOf.success	                                9.186		9.713		1.057369911x
>> StringIndexOf.successBig	                      14.341		46.343		3.231504079x
>> StringIndexOfChar.latin1_AVX2_String	  6220.918		12154.52		1.953814533x
>> StringIndexOfChar.latin1_AVX2_char	  5503.556		5540.044		1.006629895x
>> StringIndexOfChar.latin1_SSE4_String	  6978.854		6818.689		0.977049957x
>> StringIndexOfChar.latin1_SSE4_char	  5657.499		5474.624		0.967675646x
>> StringIndexOfChar.latin1_Short_String	  7132.541		6863.359		0.962260014x
>> StringIndexOfChar.latin1_Short_char	16013.389	      16162.437		1.009307711x
>> StringIndexOfChar.latin1_mixed_String	  7386.123	      14771.622		1.999915517x
>> StringIndexOfChar.latin1_mixed_char	  9901.671		9782.245		0.987938803
>
> Scott Gibbons has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comments.

src/hotspot/cpu/x86/c2_stubGenerator_x86_64_string.cpp line 1122:

> 1120: // eq_mask - The bit mask returned that holds the result of the comparison
> 1121: // rTmp - a temporary register
> 1122: // rTmp2 - a temporary register

There is no rtmp, rtmp2 here.

src/hotspot/cpu/x86/c2_stubGenerator_x86_64_string.cpp line 1129:

> 1127: // _masm - Current MacroAssembler instance pointer
> 1128: //
> 1129: // If (n - k) < 32, need to handle reading past end of haystack

Don't see (n-k) < 32 being handled in this function.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1614091336
PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1614092828

From sviswanathan at openjdk.org  Fri May 24 22:33:16 2024
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Fri, 24 May 2024 22:33:16 GMT
Subject: RFR: 8320448: Accelerate IndexOf using AVX2 [v35]
In-Reply-To: <-vyOZzeMslZqgJpTsQnnOWi4abWiM8fNeWSVx5LEHm8=.d37011ee-102c-4874-aa26-d113949d25ea@github.com>
References: <uWi4QxH31hL93771gkl_GgvP0m84IRSoR_1Yi8hD17E=.bc6ed458-7081-4c3f-9348-f59358fa05a4@github.com>
 <-vyOZzeMslZqgJpTsQnnOWi4abWiM8fNeWSVx5LEHm8=.d37011ee-102c-4874-aa26-d113949d25ea@github.com>
Message-ID: <SlNe7ZMt-yuK6U7vkWI97_X76udZW7bv3oc3kiKKhsc=.e337c2be-514c-43cf-85f1-30ca5c809e98@github.com>

On Thu, 23 May 2024 23:12:42 GMT, Scott Gibbons <sgibbons at openjdk.org> wrote:

>> Re-write the IndexOf code without the use of the pcmpestri instruction, only using AVX2 instructions.  This change accelerates String.IndexOf on average 1.3x for AVX2.  The benchmark numbers:
>> 
>> 
>> Benchmark	                                               Score		Latest		
>> StringIndexOf.advancedWithMediumSub   343.573		317.934		0.925375393x
>> StringIndexOf.advancedWithShortSub1	  1039.081		1053.96		1.014319384x
>> StringIndexOf.advancedWithShortSub2	      55.828		110.541		1.980027943x
>> StringIndexOf.constantPattern	                9.361		11.906		1.271872663x
>> StringIndexOf.searchCharLongSuccess	        4.216		4.218		1.000474383x
>> StringIndexOf.searchCharMediumSuccess	3.133		3.216		1.02649218x
>> StringIndexOf.searchCharShortSuccess	3.76		        3.761		1.000265957x
>> StringIndexOf.success	                                9.186		9.713		1.057369911x
>> StringIndexOf.successBig	                      14.341		46.343		3.231504079x
>> StringIndexOfChar.latin1_AVX2_String	  6220.918		12154.52		1.953814533x
>> StringIndexOfChar.latin1_AVX2_char	  5503.556		5540.044		1.006629895x
>> StringIndexOfChar.latin1_SSE4_String	  6978.854		6818.689		0.977049957x
>> StringIndexOfChar.latin1_SSE4_char	  5657.499		5474.624		0.967675646x
>> StringIndexOfChar.latin1_Short_String	  7132.541		6863.359		0.962260014x
>> StringIndexOfChar.latin1_Short_char	16013.389	      16162.437		1.009307711x
>> StringIndexOfChar.latin1_mixed_String	  7386.123	      14771.622		1.999915517x
>> StringIndexOfChar.latin1_mixed_char	  9901.671		9782.245		0.987938803
>
> Scott Gibbons has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comments - move stubGen*_string.cpp to c2_stubGen*_string.cpp

src/hotspot/cpu/x86/c2_stubGenerator_x86_64_string.cpp line 1754:

> 1752:         continue;
> 1753:       } else {
> 1754:         Label L_loopTop;

L_loopTop label not used in the else block.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1612495013

From sviswanathan at openjdk.org  Fri May 24 22:33:17 2024
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Fri, 24 May 2024 22:33:17 GMT
Subject: RFR: 8320448: Accelerate IndexOf using AVX2 [v25]
In-Reply-To: <U7QON8sfYvsebeu-QvEk1Gl5lnvMyVw4SgA29vFUwTo=.1614497f-15ed-454b-a458-0963c4227720@github.com>
References: <uWi4QxH31hL93771gkl_GgvP0m84IRSoR_1Yi8hD17E=.bc6ed458-7081-4c3f-9348-f59358fa05a4@github.com>
 <U7QON8sfYvsebeu-QvEk1Gl5lnvMyVw4SgA29vFUwTo=.1614497f-15ed-454b-a458-0963c4227720@github.com>
Message-ID: <WcP0eapBF2ih0XujGZVkecBL9uIa01dfDU-HdSH_nmo=.0a969b95-e0cb-4911-8b3e-141f51e99a23@github.com>

On Wed, 22 May 2024 17:40:24 GMT, Scott Gibbons <sgibbons at openjdk.org> wrote:

>> Re-write the IndexOf code without the use of the pcmpestri instruction, only using AVX2 instructions.  This change accelerates String.IndexOf on average 1.3x for AVX2.  The benchmark numbers:
>> 
>> 
>> Benchmark	                                               Score		Latest		
>> StringIndexOf.advancedWithMediumSub   343.573		317.934		0.925375393x
>> StringIndexOf.advancedWithShortSub1	  1039.081		1053.96		1.014319384x
>> StringIndexOf.advancedWithShortSub2	      55.828		110.541		1.980027943x
>> StringIndexOf.constantPattern	                9.361		11.906		1.271872663x
>> StringIndexOf.searchCharLongSuccess	        4.216		4.218		1.000474383x
>> StringIndexOf.searchCharMediumSuccess	3.133		3.216		1.02649218x
>> StringIndexOf.searchCharShortSuccess	3.76		        3.761		1.000265957x
>> StringIndexOf.success	                                9.186		9.713		1.057369911x
>> StringIndexOf.successBig	                      14.341		46.343		3.231504079x
>> StringIndexOfChar.latin1_AVX2_String	  6220.918		12154.52		1.953814533x
>> StringIndexOfChar.latin1_AVX2_char	  5503.556		5540.044		1.006629895x
>> StringIndexOfChar.latin1_SSE4_String	  6978.854		6818.689		0.977049957x
>> StringIndexOfChar.latin1_SSE4_char	  5657.499		5474.624		0.967675646x
>> StringIndexOfChar.latin1_Short_String	  7132.541		6863.359		0.962260014x
>> StringIndexOfChar.latin1_Short_char	16013.389	      16162.437		1.009307711x
>> StringIndexOfChar.latin1_mixed_String	  7386.123	      14771.622		1.999915517x
>> StringIndexOfChar.latin1_mixed_char	  9901.671		9782.245		0.987938803
>
> Scott Gibbons has updated the pull request incrementally with one additional commit since the last revision:
> 
>   un-helper-ize preload_needle_helper; try fix for macos build

src/hotspot/cpu/x86/stubGenerator_x86_64_string.cpp line 101:

> 99:   if (isU) {                 \
> 100:     __ blsrl(tmp, mask);     \
> 101:     __ blsrl(mask, tmp);     \

We could do this as 
  __ blsrl(mask, mask);     \
  __ blsrl(mask, mask);     \
Thereby removing the need for tmp.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1610453473

From sviswanathan at openjdk.org  Fri May 24 22:33:19 2024
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Fri, 24 May 2024 22:33:19 GMT
Subject: RFR: 8320448: Accelerate IndexOf using AVX2 [v27]
In-Reply-To: <Lbuv70WFoRg-z7Z85Q5mx6UexSQRF-GbnxODre5ibnc=.22b52629-9c5c-4a08-ab82-50c97f228626@github.com>
References: <uWi4QxH31hL93771gkl_GgvP0m84IRSoR_1Yi8hD17E=.bc6ed458-7081-4c3f-9348-f59358fa05a4@github.com>
 <Lbuv70WFoRg-z7Z85Q5mx6UexSQRF-GbnxODre5ibnc=.22b52629-9c5c-4a08-ab82-50c97f228626@github.com>
Message-ID: <xIfoulUwYta4u367ZhVJnRkMMCJ3jxQF6zl2XxIySQY=.b2d73170-e4dc-4d37-b00d-254d3d301dc1@github.com>

On Wed, 22 May 2024 18:52:27 GMT, Scott Gibbons <sgibbons at openjdk.org> wrote:

>> Re-write the IndexOf code without the use of the pcmpestri instruction, only using AVX2 instructions.  This change accelerates String.IndexOf on average 1.3x for AVX2.  The benchmark numbers:
>> 
>> 
>> Benchmark	                                               Score		Latest		
>> StringIndexOf.advancedWithMediumSub   343.573		317.934		0.925375393x
>> StringIndexOf.advancedWithShortSub1	  1039.081		1053.96		1.014319384x
>> StringIndexOf.advancedWithShortSub2	      55.828		110.541		1.980027943x
>> StringIndexOf.constantPattern	                9.361		11.906		1.271872663x
>> StringIndexOf.searchCharLongSuccess	        4.216		4.218		1.000474383x
>> StringIndexOf.searchCharMediumSuccess	3.133		3.216		1.02649218x
>> StringIndexOf.searchCharShortSuccess	3.76		        3.761		1.000265957x
>> StringIndexOf.success	                                9.186		9.713		1.057369911x
>> StringIndexOf.successBig	                      14.341		46.343		3.231504079x
>> StringIndexOfChar.latin1_AVX2_String	  6220.918		12154.52		1.953814533x
>> StringIndexOfChar.latin1_AVX2_char	  5503.556		5540.044		1.006629895x
>> StringIndexOfChar.latin1_SSE4_String	  6978.854		6818.689		0.977049957x
>> StringIndexOfChar.latin1_SSE4_char	  5657.499		5474.624		0.967675646x
>> StringIndexOfChar.latin1_Short_String	  7132.541		6863.359		0.962260014x
>> StringIndexOfChar.latin1_Short_char	16013.389	      16162.437		1.009307711x
>> StringIndexOfChar.latin1_mixed_String	  7386.123	      14771.622		1.999915517x
>> StringIndexOfChar.latin1_mixed_char	  9901.671		9782.245		0.987938803
>
> Scott Gibbons has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert last change to IndexOf.java

src/hotspot/cpu/x86/stubGenerator_x86_64_string.cpp line 1218:

> 1216: // isU - true if argument encoding is either UU or UL
> 1217: // eq_mask - The bit mask returned that holds the result of the comparison
> 1218: // needleLen - a temporary register.  Only used if isUL true

needleLen is not a temporary register. needleLen is used to read the kThByte from haystack below when !sizeKnown so must hold valid info.

src/hotspot/cpu/x86/stubGenerator_x86_64_string.cpp line 1439:

> 1437:   // back to last valid read position
> 1438:   __ cmpq(hsPtrRet, last);
> 1439:   __ jb_b(L_midLoop);

could be  jbe_b?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1610617943
PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1610740998

From sviswanathan at openjdk.org  Fri May 24 22:33:13 2024
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Fri, 24 May 2024 22:33:13 GMT
Subject: RFR: 8320448: Accelerate IndexOf using AVX2 [v20]
In-Reply-To: <zveo9CR_AqXFJWd23RU784fOfMEHg13VDMrD-KDtVWw=.e3036047-55dd-4584-bd9a-6de1e79c1bbd@github.com>
References: <uWi4QxH31hL93771gkl_GgvP0m84IRSoR_1Yi8hD17E=.bc6ed458-7081-4c3f-9348-f59358fa05a4@github.com>
 <zveo9CR_AqXFJWd23RU784fOfMEHg13VDMrD-KDtVWw=.e3036047-55dd-4584-bd9a-6de1e79c1bbd@github.com>
Message-ID: <vjiH1u-WS6hSr2gVj8e75i_16zLC5QSidBhBBAV_Zl4=.ce295003-5520-420a-b6dc-91ae75041ec8@github.com>

On Fri, 17 May 2024 23:47:45 GMT, Scott Gibbons <sgibbons at openjdk.org> wrote:

>> Re-write the IndexOf code without the use of the pcmpestri instruction, only using AVX2 instructions.  This change accelerates String.IndexOf on average 1.3x for AVX2.  The benchmark numbers:
>> 
>> 
>> Benchmark	                                               Score		Latest		
>> StringIndexOf.advancedWithMediumSub   343.573		317.934		0.925375393x
>> StringIndexOf.advancedWithShortSub1	  1039.081		1053.96		1.014319384x
>> StringIndexOf.advancedWithShortSub2	      55.828		110.541		1.980027943x
>> StringIndexOf.constantPattern	                9.361		11.906		1.271872663x
>> StringIndexOf.searchCharLongSuccess	        4.216		4.218		1.000474383x
>> StringIndexOf.searchCharMediumSuccess	3.133		3.216		1.02649218x
>> StringIndexOf.searchCharShortSuccess	3.76		        3.761		1.000265957x
>> StringIndexOf.success	                                9.186		9.713		1.057369911x
>> StringIndexOf.successBig	                      14.341		46.343		3.231504079x
>> StringIndexOfChar.latin1_AVX2_String	  6220.918		12154.52		1.953814533x
>> StringIndexOfChar.latin1_AVX2_char	  5503.556		5540.044		1.006629895x
>> StringIndexOfChar.latin1_SSE4_String	  6978.854		6818.689		0.977049957x
>> StringIndexOfChar.latin1_SSE4_char	  5657.499		5474.624		0.967675646x
>> StringIndexOfChar.latin1_Short_String	  7132.541		6863.359		0.962260014x
>> StringIndexOfChar.latin1_Short_char	16013.389	      16162.437		1.009307711x
>> StringIndexOfChar.latin1_mixed_String	  7386.123	      14771.622		1.999915517x
>> StringIndexOfChar.latin1_mixed_char	  9901.671		9782.245		0.987938803
>
> Scott Gibbons has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Addressing lots of comments.  Interim commit.

src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 4737:

> 4735:     bind(COMPARE_BYTE);
> 4736:   } else {
> 4737:     lea(ary1, Address(ary1, expand_ary2 ? 4 : 2));

This change is not required. expand_ary2 code doesn't come here.

src/hotspot/cpu/x86/stubGenerator_x86_64_string.cpp line 1233:

> 1231:   __ andq(eq_mask, rTmp);
> 1232: 
> 1233:   __ testl(eq_mask, eq_mask);

Mismatch of operation size q vs l: andq and testl.

src/hotspot/cpu/x86/stubGenerator_x86_64_string.cpp line 1623:

> 1621:     ////////////////////////////////////////////////////////////////////////////////////////
> 1622:     //
> 1623:     // Small haystack (<32 bytes) switch

This should be <= 32 bytes.

src/hotspot/cpu/x86/stubGenerator_x86_64_string.cpp line 1709:

> 1707:     //  XMM_BYTE_K - last element of needle, broadcast
> 1708:     //
> 1709:     //  The haystack is >= 32 bytes

Should this be > 32 bytes?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1609023624
PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1609043720
PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1609160143
PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1609163535

From sgibbons at openjdk.org  Fri May 24 23:11:15 2024
From: sgibbons at openjdk.org (Scott Gibbons)
Date: Fri, 24 May 2024 23:11:15 GMT
Subject: RFR: 8320448: Accelerate IndexOf using AVX2 [v40]
In-Reply-To: <6r30gPhGsZAoAOSYsP39qr2czQ8Wj7YMOxlP2VZZpAI=.61ee3985-d3a5-40b2-9bce-453253185600@github.com>
References: <uWi4QxH31hL93771gkl_GgvP0m84IRSoR_1Yi8hD17E=.bc6ed458-7081-4c3f-9348-f59358fa05a4@github.com>
 <jiMRlpCi04a3MIRYczPEv3tpwe1-va-BZf1vXbqQtDw=.5144a4e7-5d6f-4194-ab6b-f525c13e6448@github.com>
 <6r30gPhGsZAoAOSYsP39qr2czQ8Wj7YMOxlP2VZZpAI=.61ee3985-d3a5-40b2-9bce-453253185600@github.com>
Message-ID: <38c22L3m_I_joyXB6ZAzaAaec3-Gj4spqor35Pv1h6c=.31c1e620-dd74-49d9-8c8b-a4864167a6cc@github.com>

On Fri, 24 May 2024 22:26:56 GMT, Sandhya Viswanathan <sviswanathan at openjdk.org> wrote:

>> Scott Gibbons has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Review comments.
>
> src/hotspot/cpu/x86/c2_stubGenerator_x86_64_string.cpp line 1122:
> 
>> 1120: // eq_mask - The bit mask returned that holds the result of the comparison
>> 1121: // rTmp - a temporary register
>> 1122: // rTmp2 - a temporary register
> 
> There is no rtmp, rtmp2 here.

Fixed.

> src/hotspot/cpu/x86/c2_stubGenerator_x86_64_string.cpp line 1129:
> 
>> 1127: // _masm - Current MacroAssembler instance pointer
>> 1128: //
>> 1129: // If (n - k) < 32, need to handle reading past end of haystack
> 
> Don't see (n-k) < 32 being handled in this function.

Fixed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1614116033
PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1614116814

From sgibbons at openjdk.org  Fri May 24 23:11:16 2024
From: sgibbons at openjdk.org (Scott Gibbons)
Date: Fri, 24 May 2024 23:11:16 GMT
Subject: RFR: 8320448: Accelerate IndexOf using AVX2 [v35]
In-Reply-To: <SlNe7ZMt-yuK6U7vkWI97_X76udZW7bv3oc3kiKKhsc=.e337c2be-514c-43cf-85f1-30ca5c809e98@github.com>
References: <uWi4QxH31hL93771gkl_GgvP0m84IRSoR_1Yi8hD17E=.bc6ed458-7081-4c3f-9348-f59358fa05a4@github.com>
 <-vyOZzeMslZqgJpTsQnnOWi4abWiM8fNeWSVx5LEHm8=.d37011ee-102c-4874-aa26-d113949d25ea@github.com>
 <SlNe7ZMt-yuK6U7vkWI97_X76udZW7bv3oc3kiKKhsc=.e337c2be-514c-43cf-85f1-30ca5c809e98@github.com>
Message-ID: <m20dvpuv0wMwKMRxusojOYMqluYQ0YAByEJXOTYSXzk=.97124271-dcb3-478e-9b9b-b0b1eafe5baf@github.com>

On Fri, 24 May 2024 00:09:38 GMT, Sandhya Viswanathan <sviswanathan at openjdk.org> wrote:

>> Scott Gibbons has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Review comments - move stubGen*_string.cpp to c2_stubGen*_string.cpp
>
> src/hotspot/cpu/x86/c2_stubGenerator_x86_64_string.cpp line 1754:
> 
>> 1752:         continue;
>> 1753:       } else {
>> 1754:         Label L_loopTop;
> 
> L_loopTop label not used in the else block.

Removed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1614117294

From sgibbons at openjdk.org  Fri May 24 23:11:17 2024
From: sgibbons at openjdk.org (Scott Gibbons)
Date: Fri, 24 May 2024 23:11:17 GMT
Subject: RFR: 8320448: Accelerate IndexOf using AVX2 [v25]
In-Reply-To: <WcP0eapBF2ih0XujGZVkecBL9uIa01dfDU-HdSH_nmo=.0a969b95-e0cb-4911-8b3e-141f51e99a23@github.com>
References: <uWi4QxH31hL93771gkl_GgvP0m84IRSoR_1Yi8hD17E=.bc6ed458-7081-4c3f-9348-f59358fa05a4@github.com>
 <U7QON8sfYvsebeu-QvEk1Gl5lnvMyVw4SgA29vFUwTo=.1614497f-15ed-454b-a458-0963c4227720@github.com>
 <WcP0eapBF2ih0XujGZVkecBL9uIa01dfDU-HdSH_nmo=.0a969b95-e0cb-4911-8b3e-141f51e99a23@github.com>
Message-ID: <oYsIUqN-PHCnG6-6ADS-1keWeE-uBt-eySlEYS1sGyc=.408a9972-6dba-4110-b535-ceb77c35ea5a@github.com>

On Wed, 22 May 2024 18:22:24 GMT, Sandhya Viswanathan <sviswanathan at openjdk.org> wrote:

>> Scott Gibbons has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   un-helper-ize preload_needle_helper; try fix for macos build
>
> src/hotspot/cpu/x86/stubGenerator_x86_64_string.cpp line 101:
> 
>> 99:   if (isU) {                 \
>> 100:     __ blsrl(tmp, mask);     \
>> 101:     __ blsrl(mask, tmp);     \
> 
> We could do this as 
>   __ blsrl(mask, mask);     \
>   __ blsrl(mask, mask);     \
> Thereby removing the need for tmp.

Fixed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1614127638

From sgibbons at openjdk.org  Fri May 24 23:11:19 2024
From: sgibbons at openjdk.org (Scott Gibbons)
Date: Fri, 24 May 2024 23:11:19 GMT
Subject: RFR: 8320448: Accelerate IndexOf using AVX2 [v27]
In-Reply-To: <xIfoulUwYta4u367ZhVJnRkMMCJ3jxQF6zl2XxIySQY=.b2d73170-e4dc-4d37-b00d-254d3d301dc1@github.com>
References: <uWi4QxH31hL93771gkl_GgvP0m84IRSoR_1Yi8hD17E=.bc6ed458-7081-4c3f-9348-f59358fa05a4@github.com>
 <Lbuv70WFoRg-z7Z85Q5mx6UexSQRF-GbnxODre5ibnc=.22b52629-9c5c-4a08-ab82-50c97f228626@github.com>
 <xIfoulUwYta4u367ZhVJnRkMMCJ3jxQF6zl2XxIySQY=.b2d73170-e4dc-4d37-b00d-254d3d301dc1@github.com>
Message-ID: <yNuDY9qa_l58i-7DSSe2ss3oA9-YgMYYUh1Sl2TKHhA=.6055d456-cad7-44db-87e5-495e91a5002e@github.com>

On Wed, 22 May 2024 20:36:25 GMT, Sandhya Viswanathan <sviswanathan at openjdk.org> wrote:

>> Scott Gibbons has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Revert last change to IndexOf.java
>
> src/hotspot/cpu/x86/stubGenerator_x86_64_string.cpp line 1218:
> 
>> 1216: // isU - true if argument encoding is either UU or UL
>> 1217: // eq_mask - The bit mask returned that holds the result of the comparison
>> 1218: // needleLen - a temporary register.  Only used if isUL true
> 
> needleLen is not a temporary register. needleLen is used to read the kThByte from haystack below when !sizeKnown so must hold valid info.

Fixed.

> src/hotspot/cpu/x86/stubGenerator_x86_64_string.cpp line 1439:
> 
>> 1437:   // back to last valid read position
>> 1438:   __ cmpq(hsPtrRet, last);
>> 1439:   __ jb_b(L_midLoop);
> 
> could be  jbe_b?

Fixed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1614127526
PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1614127356

From sgibbons at openjdk.org  Fri May 24 23:11:13 2024
From: sgibbons at openjdk.org (Scott Gibbons)
Date: Fri, 24 May 2024 23:11:13 GMT
Subject: RFR: 8320448: Accelerate IndexOf using AVX2 [v20]
In-Reply-To: <vjiH1u-WS6hSr2gVj8e75i_16zLC5QSidBhBBAV_Zl4=.ce295003-5520-420a-b6dc-91ae75041ec8@github.com>
References: <uWi4QxH31hL93771gkl_GgvP0m84IRSoR_1Yi8hD17E=.bc6ed458-7081-4c3f-9348-f59358fa05a4@github.com>
 <zveo9CR_AqXFJWd23RU784fOfMEHg13VDMrD-KDtVWw=.e3036047-55dd-4584-bd9a-6de1e79c1bbd@github.com>
 <vjiH1u-WS6hSr2gVj8e75i_16zLC5QSidBhBBAV_Zl4=.ce295003-5520-420a-b6dc-91ae75041ec8@github.com>
Message-ID: <3A1V-APGmN8EO49abMKEzdGA-VLYsIiKtTrJCPtuYUc=.a6c13f99-c314-4872-a347-02e6c8a6b8aa@github.com>

On Tue, 21 May 2024 22:39:42 GMT, Sandhya Viswanathan <sviswanathan at openjdk.org> wrote:

>> Scott Gibbons has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Addressing lots of comments.  Interim commit.
>
> src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 4737:
> 
>> 4735:     bind(COMPARE_BYTE);
>> 4736:   } else {
>> 4737:     lea(ary1, Address(ary1, expand_ary2 ? 4 : 2));
> 
> This change is not required. expand_ary2 code doesn't come here.

Right.  Fixed.

> src/hotspot/cpu/x86/stubGenerator_x86_64_string.cpp line 1233:
> 
>> 1231:   __ andq(eq_mask, rTmp);
>> 1232: 
>> 1233:   __ testl(eq_mask, eq_mask);
> 
> Mismatch of operation size q vs l: andq and testl.

Fixed.

> src/hotspot/cpu/x86/stubGenerator_x86_64_string.cpp line 1623:
> 
>> 1621:     ////////////////////////////////////////////////////////////////////////////////////////
>> 1622:     //
>> 1623:     // Small haystack (<32 bytes) switch
> 
> This should be <= 32 bytes.

Fixed.

> src/hotspot/cpu/x86/stubGenerator_x86_64_string.cpp line 1709:
> 
>> 1707:     //  XMM_BYTE_K - last element of needle, broadcast
>> 1708:     //
>> 1709:     //  The haystack is >= 32 bytes
> 
> Should this be > 32 bytes?

Fixed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1614114763
PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1614127986
PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1614127889
PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1614127781

From sgibbons at openjdk.org  Fri May 24 23:15:26 2024
From: sgibbons at openjdk.org (Scott Gibbons)
Date: Fri, 24 May 2024 23:15:26 GMT
Subject: RFR: 8320448: Accelerate IndexOf using AVX2 [v41]
In-Reply-To: <uWi4QxH31hL93771gkl_GgvP0m84IRSoR_1Yi8hD17E=.bc6ed458-7081-4c3f-9348-f59358fa05a4@github.com>
References: <uWi4QxH31hL93771gkl_GgvP0m84IRSoR_1Yi8hD17E=.bc6ed458-7081-4c3f-9348-f59358fa05a4@github.com>
Message-ID: <atTesjhro2xH1gQek1JHVwgQiERxY_XbAna9KXmcHBA=.0a359fe5-aacf-483d-bc7c-6357afbd2da7@github.com>

> Re-write the IndexOf code without the use of the pcmpestri instruction, only using AVX2 instructions.  This change accelerates String.IndexOf on average 1.3x for AVX2.  The benchmark numbers:
> 
> 
> Benchmark	                                               Score		Latest		
> StringIndexOf.advancedWithMediumSub   343.573		317.934		0.925375393x
> StringIndexOf.advancedWithShortSub1	  1039.081		1053.96		1.014319384x
> StringIndexOf.advancedWithShortSub2	      55.828		110.541		1.980027943x
> StringIndexOf.constantPattern	                9.361		11.906		1.271872663x
> StringIndexOf.searchCharLongSuccess	        4.216		4.218		1.000474383x
> StringIndexOf.searchCharMediumSuccess	3.133		3.216		1.02649218x
> StringIndexOf.searchCharShortSuccess	3.76		        3.761		1.000265957x
> StringIndexOf.success	                                9.186		9.713		1.057369911x
> StringIndexOf.successBig	                      14.341		46.343		3.231504079x
> StringIndexOfChar.latin1_AVX2_String	  6220.918		12154.52		1.953814533x
> StringIndexOfChar.latin1_AVX2_char	  5503.556		5540.044		1.006629895x
> StringIndexOfChar.latin1_SSE4_String	  6978.854		6818.689		0.977049957x
> StringIndexOfChar.latin1_SSE4_char	  5657.499		5474.624		0.967675646x
> StringIndexOfChar.latin1_Short_String	  7132.541		6863.359		0.962260014x
> StringIndexOfChar.latin1_Short_char	16013.389	      16162.437		1.009307711x
> StringIndexOfChar.latin1_mixed_String	  7386.123	      14771.622		1.999915517x
> StringIndexOfChar.latin1_mixed_char	  9901.671		9782.245		0.987938803

Scott Gibbons has updated the pull request incrementally with one additional commit since the last revision:

  Fix test; review comments

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/16753/files
  - new: https://git.openjdk.org/jdk/pull/16753/files/be001e2c..b154faee

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16753&range=40
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16753&range=39-40

  Stats: 31 lines in 3 files changed: 4 ins; 13 del; 14 mod
  Patch: https://git.openjdk.org/jdk/pull/16753.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16753/head:pull/16753

PR: https://git.openjdk.org/jdk/pull/16753

From ihse at openjdk.org  Fri May 24 23:19:03 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 24 May 2024 23:19:03 GMT
Subject: RFR: 8330542: Template for Creating Strict JAXP Configuration File
 [v14]
In-Reply-To: <-xQutVfz6r3JPZZnkO71_iimpzxhNvdoX8cpz8E7-X8=.5867b83a-ec89-4c69-ac7c-6bc11caeb93e@github.com>
References: <v1bAYKgH9zfooXpvnBw4Vu2TIqHuKqqtSmgB0hiNp-Q=.31661a99-ecfc-4a05-8045-67b5f680db60@github.com>
 <-xQutVfz6r3JPZZnkO71_iimpzxhNvdoX8cpz8E7-X8=.5867b83a-ec89-4c69-ac7c-6bc11caeb93e@github.com>
Message-ID: <r3C77sC-MHqY6Y6fMowUKHj1zhExlc-TEvCYqZ1ey30=.e5ef6cf2-3c0e-4390-87e5-5e9d10265988@github.com>

On Fri, 24 May 2024 16:36:32 GMT, Joe Wang <joehw at openjdk.org> wrote:

>> Add two sample configuration files:
>> 
>>   jaxp-strict.properties: used to set strict configuration, stricter than jaxp.properties in previous versions such as JDK 22
>> 
>>>   jaxp-compat.properties: used to regain compatibility from any more restricted configuration than previous versions such as JDK 22
>> 
>> Updated on 5/16/2024
>> 
>> Design change:
>> The design is changed to include in the JDK two configuration files that are the default jaxp.properties and jaxp-strict.properties, instead of three, dropping jaxp-compat.properties.
>> 
>> Updated on 5/18/2024
>> 
>> Withdraw changes to jaxp.properties. The original idea was to match jaxp-strict.properties with regard to the properties. However, that change impact the configuration process, resulting in tests that verify the process to fail.
>> 
>> Updated on 5/23/2024
>> 
>> Provide a template `jaxp-strict.template` instead of a properties file. This template can be used to create custom configuration files.
>
> Joe Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   rename the template to jaxp-strict.properties.template

LGTM

-------------

Marked as reviewed by ihse (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18831#pullrequestreview-2078188172

From liach at openjdk.org  Fri May 24 23:22:16 2024
From: liach at openjdk.org (Chen Liang)
Date: Fri, 24 May 2024 23:22:16 GMT
Subject: RFR: 8332614: Type-checked ConstantPool.entryByIndex and
 ClassReader.readEntryOrNull [v3]
In-Reply-To: <UP8XpBov1w74UcUrAkD08x3vQGy_zRQ8NFRXuMU8us4=.3cce8ca0-742b-43f2-a282-894c7f61c969@github.com>
References: <UP8XpBov1w74UcUrAkD08x3vQGy_zRQ8NFRXuMU8us4=.3cce8ca0-742b-43f2-a282-894c7f61c969@github.com>
Message-ID: <MoUeXCdvrCNJ_XKOaejau1Xou2HQXZcJnEqS1x23DmU=.870248a1-2f40-46ff-ab30-bb377ed982c8@github.com>

> I propose to add type-checked ConstantPool.entryByIndex and ClassReader.readEntryOrNull taking an extra Class parameter, which throws ConstantPoolException instead of ClassCastException on type mismatch, which can happen to malformed ClassFiles.
> 
> Requesting a review from @asotona. Thanks!
> 
> Proposal on mailing list: https://mail.openjdk.org/pipermail/classfile-api-dev/2024-May/000512.html

Chen Liang 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 branch 'master' of https://github.com/openjdk/jdk into feature/entry-by-type
 - Merge branch 'master' of https://github.com/openjdk/jdk into feature/entry-by-type
 - Use constants, beautify code
 - 8332614: Type-checked ConstantPool.entryByIndex and ClassReader.readEntryOrNull

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19330/files
  - new: https://git.openjdk.org/jdk/pull/19330/files/c9f6fc18..a68519d3

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19330&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19330&range=01-02

  Stats: 15592 lines in 362 files changed: 10436 ins; 3396 del; 1760 mod
  Patch: https://git.openjdk.org/jdk/pull/19330.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19330/head:pull/19330

PR: https://git.openjdk.org/jdk/pull/19330

From darcy at openjdk.org  Fri May 24 23:53:54 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 24 May 2024 23:53:54 GMT
Subject: RFR: 8330182: Start of release updates for JDK 24 [v7]
In-Reply-To: <YKsEQWuI-vNTEDjOBInuEjf8AEcTL4QZ_F4JYUqoxwk=.5ed43782-6dec-4383-948d-d9966a85b3bf@github.com>
References: <YKsEQWuI-vNTEDjOBInuEjf8AEcTL4QZ_F4JYUqoxwk=.5ed43782-6dec-4383-948d-d9966a85b3bf@github.com>
Message-ID: <rhQzODFQ76zlWMAq75Ktqio26UA4boEuj1cA1edglO4=.285c6d58-04e3-47d3-83a8-1a890e13a165@github.com>

> Get JDK 24 underway.

Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:

  Add symbol files current with JDK 23 build 24.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/18787/files
  - new: https://git.openjdk.org/jdk/pull/18787/files/2a023349..5586ce5d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18787&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18787&range=05-06

  Stats: 1635 lines in 12 files changed: 1633 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/18787.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18787/head:pull/18787

PR: https://git.openjdk.org/jdk/pull/18787

From sviswanathan at openjdk.org  Sat May 25 00:46:19 2024
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Sat, 25 May 2024 00:46:19 GMT
Subject: RFR: 8320448: Accelerate IndexOf using AVX2 [v41]
In-Reply-To: <atTesjhro2xH1gQek1JHVwgQiERxY_XbAna9KXmcHBA=.0a359fe5-aacf-483d-bc7c-6357afbd2da7@github.com>
References: <uWi4QxH31hL93771gkl_GgvP0m84IRSoR_1Yi8hD17E=.bc6ed458-7081-4c3f-9348-f59358fa05a4@github.com>
 <atTesjhro2xH1gQek1JHVwgQiERxY_XbAna9KXmcHBA=.0a359fe5-aacf-483d-bc7c-6357afbd2da7@github.com>
Message-ID: <shAjphsNO3mHk65j7tCZHfwm-065JuWb9aCGrzZkynA=.472714d0-ed3c-41c2-aa95-4b76192d2297@github.com>

On Fri, 24 May 2024 23:15:26 GMT, Scott Gibbons <sgibbons at openjdk.org> wrote:

>> Re-write the IndexOf code without the use of the pcmpestri instruction, only using AVX2 instructions.  This change accelerates String.IndexOf on average 1.3x for AVX2.  The benchmark numbers:
>> 
>> 
>> Benchmark	                                               Score		Latest		
>> StringIndexOf.advancedWithMediumSub   343.573		317.934		0.925375393x
>> StringIndexOf.advancedWithShortSub1	  1039.081		1053.96		1.014319384x
>> StringIndexOf.advancedWithShortSub2	      55.828		110.541		1.980027943x
>> StringIndexOf.constantPattern	                9.361		11.906		1.271872663x
>> StringIndexOf.searchCharLongSuccess	        4.216		4.218		1.000474383x
>> StringIndexOf.searchCharMediumSuccess	3.133		3.216		1.02649218x
>> StringIndexOf.searchCharShortSuccess	3.76		        3.761		1.000265957x
>> StringIndexOf.success	                                9.186		9.713		1.057369911x
>> StringIndexOf.successBig	                      14.341		46.343		3.231504079x
>> StringIndexOfChar.latin1_AVX2_String	  6220.918		12154.52		1.953814533x
>> StringIndexOfChar.latin1_AVX2_char	  5503.556		5540.044		1.006629895x
>> StringIndexOfChar.latin1_SSE4_String	  6978.854		6818.689		0.977049957x
>> StringIndexOfChar.latin1_SSE4_char	  5657.499		5474.624		0.967675646x
>> StringIndexOfChar.latin1_Short_String	  7132.541		6863.359		0.962260014x
>> StringIndexOfChar.latin1_Short_char	16013.389	      16162.437		1.009307711x
>> StringIndexOfChar.latin1_mixed_String	  7386.123	      14771.622		1.999915517x
>> StringIndexOfChar.latin1_mixed_char	  9901.671		9782.245		0.987938803
>
> Scott Gibbons has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix test; review comments

src/hotspot/cpu/x86/c2_stubGenerator_x86_64_string.cpp line 316:

> 314:   // Set up jump tables.  Used when needle size <= NUMBER_OF_CASES
> 315:   setup_jump_tables(ae, L_returnRBP, L_checkRangeAndReturn, L_bigCaseFixupAndReturn,
> 316:                     &big_jump_table, &small_jump_table, _masm);

We could directly use L_returnError here instead of L_returnRBP.

src/hotspot/cpu/x86/c2_stubGenerator_x86_64_string.cpp line 476:

> 474: // Used to check and return value in rbp - usually error
> 475:   __ bind(L_returnRBP);
> 476:   __ movq(rax, rbp);

This seems spurious as rax is being overwritten at line 489. Did you intend to return -1?

src/hotspot/cpu/x86/c2_stubGenerator_x86_64_string.cpp line 1816:

> 1814:         byte_compare_helper(i + 1, L_loopTop, L_fixup, needle, needle_val, hs_ptr, eq_mask, set_bit,
> 1815:                             rTmp4, ae, _masm);
> 1816:       }

L_checkRange on NoMatch could be L_error instead.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1614172379
PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1614172021
PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1614175081

From sviswanathan at openjdk.org  Sat May 25 00:46:19 2024
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Sat, 25 May 2024 00:46:19 GMT
Subject: RFR: 8320448: Accelerate IndexOf using AVX2 [v35]
In-Reply-To: <-vyOZzeMslZqgJpTsQnnOWi4abWiM8fNeWSVx5LEHm8=.d37011ee-102c-4874-aa26-d113949d25ea@github.com>
References: <uWi4QxH31hL93771gkl_GgvP0m84IRSoR_1Yi8hD17E=.bc6ed458-7081-4c3f-9348-f59358fa05a4@github.com>
 <-vyOZzeMslZqgJpTsQnnOWi4abWiM8fNeWSVx5LEHm8=.d37011ee-102c-4874-aa26-d113949d25ea@github.com>
Message-ID: <tI546ou6EUgSgpexgC_lyWf1C-WtWEjyV6rBZEihYQQ=.5be9e688-e107-498e-8103-0b7d3acc87bc@github.com>

On Thu, 23 May 2024 23:12:42 GMT, Scott Gibbons <sgibbons at openjdk.org> wrote:

>> Re-write the IndexOf code without the use of the pcmpestri instruction, only using AVX2 instructions.  This change accelerates String.IndexOf on average 1.3x for AVX2.  The benchmark numbers:
>> 
>> 
>> Benchmark	                                               Score		Latest		
>> StringIndexOf.advancedWithMediumSub   343.573		317.934		0.925375393x
>> StringIndexOf.advancedWithShortSub1	  1039.081		1053.96		1.014319384x
>> StringIndexOf.advancedWithShortSub2	      55.828		110.541		1.980027943x
>> StringIndexOf.constantPattern	                9.361		11.906		1.271872663x
>> StringIndexOf.searchCharLongSuccess	        4.216		4.218		1.000474383x
>> StringIndexOf.searchCharMediumSuccess	3.133		3.216		1.02649218x
>> StringIndexOf.searchCharShortSuccess	3.76		        3.761		1.000265957x
>> StringIndexOf.success	                                9.186		9.713		1.057369911x
>> StringIndexOf.successBig	                      14.341		46.343		3.231504079x
>> StringIndexOfChar.latin1_AVX2_String	  6220.918		12154.52		1.953814533x
>> StringIndexOfChar.latin1_AVX2_char	  5503.556		5540.044		1.006629895x
>> StringIndexOfChar.latin1_SSE4_String	  6978.854		6818.689		0.977049957x
>> StringIndexOfChar.latin1_SSE4_char	  5657.499		5474.624		0.967675646x
>> StringIndexOfChar.latin1_Short_String	  7132.541		6863.359		0.962260014x
>> StringIndexOfChar.latin1_Short_char	16013.389	      16162.437		1.009307711x
>> StringIndexOfChar.latin1_mixed_String	  7386.123	      14771.622		1.999915517x
>> StringIndexOfChar.latin1_mixed_char	  9901.671		9782.245		0.987938803
>
> Scott Gibbons has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comments - move stubGen*_string.cpp to c2_stubGen*_string.cpp

src/hotspot/cpu/x86/c2_stubGenerator_x86_64_string.cpp line 1740:

> 1738:     //
> 1739:     // If a match is found, jump to L_checkRangeAndReturn, which ensures the
> 1740:     // matched needle is not past the end of the haystack.

These labels are not in this function.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1614125339

From alanb at openjdk.org  Sat May 25 06:36:12 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Sat, 25 May 2024 06:36:12 GMT
Subject: RFR: 8320448: Accelerate IndexOf using AVX2 [v41]
In-Reply-To: <atTesjhro2xH1gQek1JHVwgQiERxY_XbAna9KXmcHBA=.0a359fe5-aacf-483d-bc7c-6357afbd2da7@github.com>
References: <uWi4QxH31hL93771gkl_GgvP0m84IRSoR_1Yi8hD17E=.bc6ed458-7081-4c3f-9348-f59358fa05a4@github.com>
 <atTesjhro2xH1gQek1JHVwgQiERxY_XbAna9KXmcHBA=.0a359fe5-aacf-483d-bc7c-6357afbd2da7@github.com>
Message-ID: <PWJcJvCQOtmwRGr0paU-uIQYjeBLhsU-JI_VdkIpLOo=.c36bcb0d-43dd-4277-84d0-a1506bd9e15b@github.com>

On Fri, 24 May 2024 23:15:26 GMT, Scott Gibbons <sgibbons at openjdk.org> wrote:

>> Re-write the IndexOf code without the use of the pcmpestri instruction, only using AVX2 instructions.  This change accelerates String.IndexOf on average 1.3x for AVX2.  The benchmark numbers:
>> 
>> 
>> Benchmark	                                               Score		Latest		
>> StringIndexOf.advancedWithMediumSub   343.573		317.934		0.925375393x
>> StringIndexOf.advancedWithShortSub1	  1039.081		1053.96		1.014319384x
>> StringIndexOf.advancedWithShortSub2	      55.828		110.541		1.980027943x
>> StringIndexOf.constantPattern	                9.361		11.906		1.271872663x
>> StringIndexOf.searchCharLongSuccess	        4.216		4.218		1.000474383x
>> StringIndexOf.searchCharMediumSuccess	3.133		3.216		1.02649218x
>> StringIndexOf.searchCharShortSuccess	3.76		        3.761		1.000265957x
>> StringIndexOf.success	                                9.186		9.713		1.057369911x
>> StringIndexOf.successBig	                      14.341		46.343		3.231504079x
>> StringIndexOfChar.latin1_AVX2_String	  6220.918		12154.52		1.953814533x
>> StringIndexOfChar.latin1_AVX2_char	  5503.556		5540.044		1.006629895x
>> StringIndexOfChar.latin1_SSE4_String	  6978.854		6818.689		0.977049957x
>> StringIndexOfChar.latin1_SSE4_char	  5657.499		5474.624		0.967675646x
>> StringIndexOfChar.latin1_Short_String	  7132.541		6863.359		0.962260014x
>> StringIndexOfChar.latin1_Short_char	16013.389	      16162.437		1.009307711x
>> StringIndexOfChar.latin1_mixed_String	  7386.123	      14771.622		1.999915517x
>> StringIndexOfChar.latin1_mixed_char	  9901.671		9782.245		0.987938803
>
> Scott Gibbons has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix test; review comments

test/jdk/java/lang/StringBuffer/IndexOf.java line 47:

> 45: public class IndexOf {
> 46: 
> 47:   static Random generator = new Random();

@RogerRiggs Would you have cycles to look at Scott's changes to this test? I suspect it will need to be re-structured, re-formatted, and commented to get into maintainable shape.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1614383260

From dl at openjdk.org  Sat May 25 12:49:30 2024
From: dl at openjdk.org (Doug Lea)
Date: Sat, 25 May 2024 12:49:30 GMT
Subject: RFR: 8322732: ForkJoinPool may underutilize cores in async mode
 [v5]
In-Reply-To: <xRyDMAsSZ7obqpr3Aoc5qrHqILeJMxFVCeiRdctMI3U=.d5d3cd56-32eb-4431-ac01-081822fc86c6@github.com>
References: <xRyDMAsSZ7obqpr3Aoc5qrHqILeJMxFVCeiRdctMI3U=.d5d3cd56-32eb-4431-ac01-081822fc86c6@github.com>
Message-ID: <OMW8nKcGEY8kHUiSbvNFIq5BWzFmJU8NgdiKf9oK1EI=.b26cd87e-c30f-4bc5-a5ea-fbd53c1b9286@github.com>

> This set of changes address causes of poor utilization with small numbers of cores due to overly aggressive contention avoidance. A number of further adjustments were needed to still avoid most contention effects in deployments with large numbers of cores

Doug Lea has updated the pull request incrementally with one additional commit since the last revision:

  Adjust control flow

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19131/files
  - new: https://git.openjdk.org/jdk/pull/19131/files/28341747..72224779

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19131&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19131&range=03-04

  Stats: 72 lines in 1 file changed: 15 ins; 14 del; 43 mod
  Patch: https://git.openjdk.org/jdk/pull/19131.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19131/head:pull/19131

PR: https://git.openjdk.org/jdk/pull/19131

From amansha at kth.se  Sat May 25 21:03:43 2024
From: amansha at kth.se (Aman Sharma)
Date: Sat, 25 May 2024 21:03:43 +0000
Subject: Deterministic naming of subclasses of `java/lang/reflect/Proxy`
In-Reply-To: <CABe8uE13qRX7pRXJOdhUF0sUwF5WkxTAM517tSTOi1r2Q7ivOg@mail.gmail.com>
References: <bf26eb2f74874e02876b3868311922a9@kth.se>
 <CABe8uE0fk71Xy_PYHikSw9OtXE_i+M9zMbayPEXuTxLWLoy2ag@mail.gmail.com>
 <50405ca9c0a64372bace175b932f9ef7@kth.se>
 <61fbe3d9-9536-4113-adde-6cfc671ba1ee@oracle.com>
 <a860be44e06243799593aa8d67c048cd@kth.se>
 <CABe8uE115=DzYCdnvNazqFuuxtJoZnv9wRUkFA4-PS7g41QLMw@mail.gmail.com>
 <DB7PR02MB35938DCC3A392536B924164AFBEE2@DB7PR02MB3593.eurprd02.prod.outlook.com>
 <a0330ee0-5f45-4ef2-8500-e5fcdb696c52@oracle.com>
 <b214cc1a13fe4885a437e16b420e5483@kth.se>
 <ac2ebe5c-db49-4a2d-a5cd-10440a77aa16@oracle.com>
 <580b3aacd8df48fcaae3399718e229ab@kth.se>
 <CABe8uE065Q3+0yNjtyDF-eJM4LN-MbY9kfC44CnSQ-KM4p862g@mail.gmail.com>
 <b64077d6cf0045e98b630cf888785182@kth.se>
 <eabfa5ae508e4257bd0c9bbef244637f@kth.se>,
 <CABe8uE13qRX7pRXJOdhUF0sUwF5WkxTAM517tSTOi1r2Q7ivOg@mail.gmail.com>
Message-ID: <fb6a2cb13c2449acac32fdfb781b0ce0@kth.se>

Hi Chen,

I am attaching proxy classes generated in the JVM of OpenJDK 22. I, instead of decompiling, I disassembled them and I do see a difference. For example, see method `footerHeading` in both classes. In $Proxy9, it is mapped to `m39` field and in $Proxy13, it is mapped to `m21` field. What is the reason for this ordering? Why is mapping of methods to fields depend upon the execution?


Regards,
Aman Sharma

PhD Student
KTH Royal Institute of Technology
School of Electrical Engineering and Computer Science (EECS)
Department of Theoretical Computer Science (TCS)
<https://www.kth.se/profile/amansha>https://algomaster99.github.io/
________________________________
From: Chen Liang <liangchenblue at gmail.com>
Sent: Wednesday, May 22, 2024 9:37:16 PM
To: Aman Sharma
Cc: core-libs-dev at openjdk.org; leyden-dev at openjdk.org
Subject: Re: Deterministic naming of subclasses of `java/lang/reflect/Proxy`

Hi Aman,
Even though the specification says "not in any particular order," the getInterfaces and getMethods actually return an ordered array, in the order these methods/interfaces are declared in their class files.

I believe you are decompiling the proxy classes generated by an older version of the JDK; for example, back in JDK 8, the proxy methods were not ordered because they were tracked in a HashMap: https://github.com/openjdk/jdk8u/blob/6b53212ef78ad50f9eede829c5ff87cadcdb434b/jdk/src/share/classes/sun/misc/ProxyGenerator.java#L405
Which is no longer the case: https://github.com/openjdk/jdk/blob/d59c12fe1041a1f61f68408241a9aa4d96ac4fd2/src/java.base/share/classes/java/lang/reflect/ProxyGenerator.java#L241

- Chen

On Wed, May 22, 2024 at 1:19?PM Aman Sharma <amansha at kth.se<mailto:amansha at kth.se>> wrote:

Hi,


Another thing I wanted to look into in this thread was the order of fields in the Proxy classes generated. They are also based on the a number. The same proxy classes across different executions can have random order of `Method` fields and the methods could be mapped to different field names.


For example, consider the proxy class based on `picocli.CommandLine<https://github.com/remkop/picocli/blob/da98db63d1b516141b7485881b0dcddfd082dbc8/src/main/java/picocli/CommandLine.java#L4541>` in two different executions.

// fields and method are truncated for brevity
public final class $Proxy9 extends Proxy implements CommandLine.Command {
    private static Method m1;
    private static Method m32;
    private static Method m21;
    private static Method m43;
    private static Method m36;
    private static Method m27;

    public final boolean helpCommand() throws  {
        try {
            return (Boolean)super.h.invoke(this, m32, (Object[])null);
        } catch (RuntimeException | Error var2) {
            throw var2;
        } catch (Throwable var3) {
            throw new UndeclaredThrowableException(var3);
        }
     }

// fields and method are truncated for brevity
public final class $Proxy13 extends Proxy implements CommandLine.Command {
    private static Method m1;
    private static Method m29;
    private static Method m16;
    private static Method m40;
    private static Method m38;
    private static Method m12;

    public final boolean helpCommand() throws  {
        try {
            return (Boolean)super.h.invoke(this, m29, (Object[])null);
        } catch (RuntimeException | Error var2) {
            throw var2;
        } catch (Throwable var3) {
            throw new UndeclaredThrowableException(var3);
        }
    }


Notice the difference in the order of fields and `helpCommand` method is mapped to a different field name in both classes. This happens because the method array returned by `getMethods` is not sorted in any particular order<https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/lang/Class.java#L2178> when generating a proxy class. What dictates this order? And why is it not deterministic?


Regards,
Aman Sharma

PhD Student
KTH Royal Institute of Technology
School of Electrical Engineering and Computer Science (EECS)
Department of Theoretical Computer Science (TCS)
<http://www.kth.se><https://www.kth.se/profile/amansha><https://www.kth.se/profile/amansha>
<https://www.kth.se/profile/amansha>https://algomaster99.github.io/
________________________________
From: Aman Sharma
Sent: Wednesday, May 22, 2024 4:12:19 PM
To: Chen Liang
Cc: David Holmes; core-libs-dev at openjdk.org<mailto:core-libs-dev at openjdk.org>; leyden-dev at openjdk.org<mailto:leyden-dev at openjdk.org>
Subject: Re: Deterministic naming of subclasses of `java/lang/reflect/Proxy`


Hi Chen,


That's clear. Thanks for letting me know. I guess then Project Leyden is working on naming the hidden classes deterministically to achieve their goals<https://openjdk.org/projects/leyden/notes/01-beginnings>.


Regards,
Aman Sharma

PhD Student
KTH Royal Institute of Technology
School of Electrical Engineering and Computer Science (EECS)
Department of Theoretical Computer Science (TCS)
<http://www.kth.se><https://www.kth.se/profile/amansha><https://www.kth.se/profile/amansha>
<https://www.kth.se/profile/amansha>https://algomaster99.github.io/
________________________________
From: Chen Liang <liangchenblue at gmail.com<mailto:liangchenblue at gmail.com>>
Sent: Wednesday, May 22, 2024 1:35:46 PM
To: Aman Sharma
Cc: David Holmes; core-libs-dev at openjdk.org<mailto:core-libs-dev at openjdk.org>; leyden-dev at openjdk.org<mailto:leyden-dev at openjdk.org>
Subject: Re: Deterministic naming of subclasses of `java/lang/reflect/Proxy`

Hi Aman,
We have tried defining Proxy as hidden classes; a previous attempt was on hold because of issues with serialization. Otherwise, Proxies work great as hidden classes.

Chen

On Mon, May 20, 2024 at 7:56?AM Aman Sharma <amansha at kth.se<mailto:amansha at kth.se>> wrote:

Hi David,


> I would not expect any class load
events.


I understand. I also haven't tried to intercept them but I see only one approach right now to include them in an allowlist - 1) statically look for invocations of "Lookup::defineHiddenClass". 2) Instrument them so that its first argument "bytes" can be looked into upon. I haven't looked into it much because I did not have much idea about it. And they are hidden so it made it worse. ? Thanks for sharing the JEP!


>

java.lang.reflect.Proxy could define hidden classes to act as the proxy classes which implement proxy interfaces; from JEP 317


It says that Proxy classes will also become hidden classes. Is it underway? Right now one can intercept, transform them, and include them in an allowlist. What do you think of naming them independent of AtomicLong so that a proxy class generated at runtime is easy to lookup in the allowlist?



Regards,
Aman Sharma

PhD Student
KTH Royal Institute of Technology
School of Electrical Engineering and Computer Science (EECS)
Department of Theoretical Computer Science (TCS)
<http://www.kth.se><https://www.kth.se/profile/amansha><https://www.kth.se/profile/amansha>
<https://www.kth.se/profile/amansha>https://algomaster99.github.io/
________________________________
From: David Holmes <david.holmes at oracle.com<mailto:david.holmes at oracle.com>>
Sent: Monday, May 20, 2024 2:30:37 PM
To: Aman Sharma; liangchenblue at gmail.com<mailto:liangchenblue at gmail.com>
Cc: core-libs-dev at openjdk.org<mailto:core-libs-dev at openjdk.org>; leyden-dev at openjdk.org<mailto:leyden-dev at openjdk.org>
Subject: Re: Deterministic naming of subclasses of `java/lang/reflect/Proxy`

On 20/05/2024 10:12 pm, Aman Sharma wrote:
> Hi David,
>
>
>  > How did you try to intercept them? Hidden classes are not "loaded" in
> the normal sense so won't trigger class load events.
>
>
> I could not intercept them. I only see them when I pass `-verbose:class`
> in the Java CLI.

Yes that is why I asked how you tried to intercept them.

>
> I also couldn't intercept them using JVMTI Class File Load Hook
> <https://docs.oracle.com/en/java/javase/21/docs/specs/jvmti.html#ClassFileLoadHook> event. However JEP 371 suggests that it should be possible to intercept them using JVMTI Class Load <https://docs.oracle.com/en/java/javase/21/docs/specs/jvmti.html#ClassLoad> event, but I won't have the bytecode at this stage. So is there no way to get its bytecode before it is linked and initialized in the JVM?

Hidden classes are not loaded so I would not expect any class load
events. However the exact nature of the JVMTI class load event is
unclear as it talks about "class or interface creation" which is neither
loading or defining per se. But a class prepare event sounds like it
should be issued. However neither give you access to the bytecode of the
class AFAICS.

David
-----


>
> Regards,
> Aman Sharma
>
> PhD Student
> KTH Royal Institute of Technology
> School of Electrical Engineering and Computer Science (EECS)
> Department of Theoretical Computer Science (TCS)
> <http://www.kth.se><https://www.kth.se/profile/amansha><https://www.kth.se/profile/amansha>
> <https://www.kth.se/profile/amansha>https://algomaster99.github.io/
> <https://algomaster99.github.io/>
> ------------------------------------------------------------------------
> *From:* David Holmes <david.holmes at oracle.com<mailto:david.holmes at oracle.com>>
> *Sent:* Monday, May 20, 2024 2:59:17 AM
> *To:* Aman Sharma; liangchenblue at gmail.com<mailto:liangchenblue at gmail.com>
> *Cc:* core-libs-dev at openjdk.org<mailto:core-libs-dev at openjdk.org>; leyden-dev at openjdk.org<mailto:leyden-dev at openjdk.org>
> *Subject:* Re: Deterministic naming of subclasses of
> `java/lang/reflect/Proxy`
> On 17/05/2024 9:43 pm, Aman Sharma wrote:
>> Hi Chen,
>>
>>  > java.lang.invoke.LambdaForm$MH/0x00000200cc000400
>>
>> I do see this as output when I pass -verbose:class. However, based on my
>> experiments, I have seen that neither an agent passed via 'javaagent'
>> nor an agent passed via 'agentpath' is able to intercept this hidden class.
>
> How did you try to intercept them? Hidden classes are not "loaded" in
> the normal sense so won't trigger class load events.
>
>> Also, I was a bit confused since I saw somewhere that the names of
>> hidden classes are null. But thanks for clarifying here.
>
> The JEP clearly defines the name format for hidden classes - though the
> final component is VM specific (and typically a hashcode).
>
> https://openjdk.org/jeps/371 <https://openjdk.org/jeps/371>
>
> Cheers,
> David
> -----
>
>>  > avoid dynamic class loading
>>
>> I don't see dynamic class loading as a problem. I only mind some
>> unstable generation aspects of them which make it hard to verify them
>> based on an allowlist.
>>
>> For example, if this hidden class is generated with the exact same name
>> and the exact same bytecode during runtime as well, it would be easy to
>> verify it. However, I do see the names are based on some sort of memory
>> address so and I don't know what bytecode it has so I don't have
>> suggestions to make them stable as of now. For Proxy classes, I feel it
>> can be addressed unless you disagree or some involved in Project Leyden
>> does. :) Thank you for forwarding my mail there.
>>
>> Regards,
>> Aman Sharma
>>
>> PhD Student
>> KTH Royal Institute of Technology
>> https://algomaster99.github.io/ <https://algomaster99.github.io/>
> <https://algomaster99.github.io/ <https://algomaster99.github.io/>>
>>
>> ------------------------------------------------------------------------
>> *From:* liangchenblue at gmail.com<mailto:liangchenblue at gmail.com> <liangchenblue at gmail.com<mailto:liangchenblue at gmail.com>>
>> *Sent:* Friday, May 17, 2024 1:23:58 pm
>> *To:* Aman Sharma <amansha at kth.se<mailto:amansha at kth.se>>
>> *Cc:* core-libs-dev at openjdk.org<mailto:core-libs-dev at openjdk.org> <core-libs-dev at openjdk.org<mailto:core-libs-dev at openjdk.org>>;
>> leyden-dev at openjdk.org<mailto:leyden-dev at openjdk.org> <leyden-dev at openjdk.org<mailto:leyden-dev at openjdk.org>>
>> *Subject:* Re: Deterministic naming of subclasses of
>> `java/lang/reflect/Proxy`
>>
>> Hi Aman,
>> For `-verbose:class`, it's a JVM argument instead of a program argument;
>> so when you run a java program like `java Main`, you should call it as
>> `java -verbose:class Main`.
>> When done correctly, you should see hidden class outputs like:
>> [0.032s][info][class,load]
>> java.lang.invoke.LambdaForm$MH/0x00000200cc000400 source:
>> __JVM_LookupDefineClass__
>> The loading of java.lang.invoke hidden classes requires your program to
>> use MethodHandle features, like a lambda.
>>
>> I think the problem you are exploring, that to avoid dynamic class
>> loading and effectively turn Java Platform closed for security, is also
>> being accomplished by project Leyden (as I've shared initially); Thus, I
>> am forwarding this to leyden-dev instead, so you can see what approach
>> Leyden uses to accomplish the same goal as yours.
>>
>> Regards, Chen Liang
>>
>> On Fri, May 17, 2024 at 4:40?AM Aman Sharma <amansha at kth.se<mailto:amansha at kth.se>
>> <mailto:amansha at kth.se<mailto:amansha at kth.se> <mailto:amansha at kth.se>>> wrote:
>>
>>     __
>>
>>     Hi Roger,
>>
>>
>>     Do you have ideas on how to intercept them? My javaagent is not able
>>     to nor a JVMTI agent passed using `agentpath` option. It also does
>>     not seem to show up in logs when I pass `-verbose:class`.
>>
>>
>>     Also, what do you think of renaming the proxy classes as suggested
>>     below?
>>
>>
>>     Regards,
>>     Aman Sharma
>>
>>     PhD Student
>>     KTH Royal Institute of Technology
>>     School of Electrical Engineering and Computer Science (EECS)
>>     Department of Theoretical Computer Science (TCS)
>>     <http://www.kth.se><https://www.kth.se/profile/amansha><https://www.kth.se/profile/amansha <http://www.kth.se><https://www.kth.se/profile/amansha><https://www.kth.se/profile/amansha>>
>>     <https://www.kth.se/profile/amansha
> <https://www.kth.se/profile/amansha>>https://algomaster99.github.io/
>>     <https://algomaster99.github.io/ <https://algomaster99.github.io/>>
>>     ------------------------------------------------------------------------
>>     *From:* core-libs-dev <core-libs-dev-retn at openjdk.org<mailto:core-libs-dev-retn at openjdk.org>
>>     <mailto:core-libs-dev-retn at openjdk.org<mailto:core-libs-dev-retn at openjdk.org>
> <mailto:core-libs-dev-retn at openjdk.org>>> on behalf of Roger Riggs
>>     <roger.riggs at oracle.com<mailto:roger.riggs at oracle.com> <mailto:roger.riggs at oracle.com<mailto:roger.riggs at oracle.com> <mailto:roger.riggs at oracle.com>>>
>>     *Sent:* Friday, May 17, 2024 4:57:46 AM
>>     *To:* core-libs-dev at openjdk.org<mailto:core-libs-dev at openjdk.org> <mailto:core-libs-dev at openjdk.org<mailto:core-libs-dev at openjdk.org> <mailto:core-libs-dev at openjdk.org>>
>>     *Subject:* Re: Deterministic naming of subclasses of
>>     `java/lang/reflect/Proxy`
>>     Hi Aman,
>>
>>     You may also run into hidden classes (JEP 371: Hidden Classes) that
>>     allow classes to be defined, at runtime, without names.
>>     It has been proposed to use them for generated proxies but that
>>     hasn't been implemented yet.
>>     There are benefits to having nameless classes, because they can't be
>>     referenced by name, only as a capability, they can be better
>>     encapsulated.
>>
>>     fyi, Roger Riggs
>>
>>
>>     On 5/16/24 8:11 AM, Aman Sharma wrote:
>>>
>>>     Hi,
>>>
>>>
>>>     Thanks for your response, Liang!
>>>
>>>
>>>     > I think you meant CVE-2021-42392 instead of 2022.
>>>
>>>
>>>     Sorry of the error. I indeed meant CVE-2021-42392
>>>     <https://nvd.nist.gov/vuln/detail/cve-2021-42392
> <https://nvd.nist.gov/vuln/detail/cve-2021-42392>>.
>>>
>>>
>>>     > Leyden mainly avoids this unstable generation by performing a
>>>     training run to collect classes loaded
>>>
>>>
>>>     Would love to know the details of Project Leyden and how they
>>>     worked so far to focus on this goal. In our case, the training run
>>>     is the test suite.
>>>
>>>
>>>     > GeneratedConstructorAccessor is already retired by JEP 416 [2]
>>>     in Java 18
>>>
>>>
>>>     I did see them not appearing in my allowlist when I ran my study
>>>     subject (Apache PDFBox) with Java 21. Thanks for letting me know
>>>     about this JEP. I see they are re-implemented with method handles.
>>>
>>>
>>>     > How are you checking the classes?
>>>
>>>
>>>     To detect runtime generated code, we have javaagent that is hooked
>>>     statically to the test suite execution. It gives us all classes
>>>     that that is loaded post the JVM and the javaagent are loaded. So
>>>     we only check the classes loaded for the purpose of running the
>>>     application. This is also why we did not choose -agentlib as it
>>>     would give classes for the setting up JVM and javaagent and we the
>>>     user of our tool must the classes they load.
>>>
>>>
>>>     Next, we have a `ClassFileTransformer` hook in the agent where we
>>>     produce the checksum using the bytecode. And we compare the
>>>     checksum with the one existing in the allowlist. The checksum
>>>     computation algorithm is same for both steps. Let me describe how
>>>     I compute the checksum.
>>>
>>>
>>>      1. I get the CONSTANT_Class_info
>>>         <https://docs.oracle.com/javase/specs/jvms/se11/html/jvms-4.html#jvms-4.4.1 <https://docs.oracle.com/javase/specs/jvms/se11/html/jvms-4.html#jvms-4.4.1>> entry corresponding to `this_class` and rewrite the CONSTANT_Utf8_info <https://docs.oracle.com/javase/specs/jvms/se11/html/jvms-4.html#jvms-4.4.7 <https://docs.oracle.com/javase/specs/jvms/se11/html/jvms-4.html#jvms-4.4.7>> corresponding to a fix String constant, say "foo".
>>>      2. Since, the name of the class is used to refer to its types
>>>         members (fields/method), I get all CONSTANT_Fieldref_info
>>>         <https://docs.oracle.com/javase/specs/jvms/se11/html/jvms-4.html#jvms-4.4.2 <https://docs.oracle.com/javase/specs/jvms/se11/html/jvms-4.html#jvms-4.4.2>> and if its `class_index` corresponds to the old `this_class`, we rewrite the UTF8 value of class_index to the same constant "foo".
>>>      3. Next, since the naming of the fields, in Proxy classes, are
>>>         also suffixed by numbers, for example, `private static Method
>>>         m4`, we rewrite the UTF8 value of name in the
>>>         CONSTANT_NameAndType_info
>>>         <https://docs.oracle.com/javase/specs/jvms/se11/html/jvms-4.html#jvms-4.4.6 <https://docs.oracle.com/javase/specs/jvms/se11/html/jvms-4.html#jvms-4.4.6>>.
>>>      4. These fields can also have a random order so we simply sort
>>>         the entire byte code using `Arrays.sort(byte[])` to eliminate
>>>         any differences due to ordering of fields/methods.
>>>      5. Simply sorting the byte array still had minute differences. I
>>>         could not understand why they existed even though values in
>>>         constant pool of the bytecode in allowlist and at runtime were
>>>         exactly the same after rewriting. The differences existed in
>>>         the bytes of the Code attribute of methods. I concluded that
>>>         the bytes stored some position information. To avoid this, I
>>>         created a subarray where I considered the bytes corresponding
>>>         to `CONSTANT_Utf8_info.bytes` only. Computing a checksum for
>>>         it resulted in the same checksums for both classfiles.
>>>
>>>
>>>     Let's understand the whole approach with an example of Proxy class.
>>>
>>>     `
>>>     public  final  class  $Proxy42  extends  Proxy  implements  org.apache.logging.log4j.core.config.plugins.Plugin  {
>>>     `
>>>
>>>     The will go in the allowlist as "Proxy_Plugin: <SHA256 checksum>".
>>>
>>>     When the same class is intercepted at runtime, say "$Proxy10", we
>>>     look for "Proxy_Plugin" in the allowlist and since the checksum
>>>     algorithm is same in both cases, we get a match and let the class
>>>     load.
>>>
>>>     This approach has seemed to work well for Proxy classes, Generated
>>>     Constructor Accessor (which is removed as you said). I also looked
>>>     at the species generated by method handles. I did not notice any
>>>     modification in them. Their name generation seemed okay to me. If
>>>     some new Species are generated, it is of course detected since it
>>>     is not in the allowlist.
>>>
>>>     I have not looked into LambdaMetafactory because I did not
>>>     encounter it as a problem so far, but I am aware its name
>>>     generation is also unstable. I have run my approach only a few
>>>     projects only. And for hidden classes, I assume the the agent
>>>     won't be able to intercept them so detecting them would be really
>>>     hard.
>>>
>>>
>>>     Regards,
>>>     Aman Sharma
>>>
>>>     PhD Student
>>>     KTH Royal Institute of Technology
>>>     School of Electrical Engineering and Computer Science (EECS)
>>>     Department of Theoretical Computer Science (TCS)
>>>     <https://www.kth.se/profile/amansha
> <https://www.kth.se/profile/amansha>>https://algomaster99.github.io/
> <https://algomaster99.github.io/ <https://algomaster99.github.io/>>
>>>     ------------------------------------------------------------------------
>>>     *From:* liangchenblue at gmail.com<mailto:liangchenblue at gmail.com> <mailto:liangchenblue at gmail.com<mailto:liangchenblue at gmail.com> <mailto:liangchenblue at gmail.com>>
>>>     <liangchenblue at gmail.com<mailto:liangchenblue at gmail.com>> <mailto:liangchenblue at gmail.com<mailto:liangchenblue at gmail.com> <mailto:liangchenblue at gmail.com>>
>>>     *Sent:* Thursday, May 16, 2024 5:52:03 AM
>>>     *To:* Aman Sharma; core-libs-dev
>>>     *Cc:* Martin Monperrus
>>>     *Subject:* Re: Deterministic naming of subclasses of
>>>     `java/lang/reflect/Proxy`
>>>     Hi Aman,
>>>     I think you meant CVE-2021-42392 instead of 2022.
>>>
>>>     For your approach of an "allowlist" for Java runtime, project
>>>     Leyden is looking to generate a static image [1], that
>>>     > At run time it cannot load classes from outside the image, nor
>>>     can it create classes dynamically.
>>>     Leyden mainly avoids this unstable generation by performing a
>>>     training run to collect classes loaded and even object graphs; I
>>>     am not familiar with the details unfortunately.
>>>
>>>     Otherwise, the Proxy discussion belongs better to core-libs-dev,
>>>     as java.lang.reflect.Proxy is part of Java's core libraries. I am
>>>     replying this thread to core-libs-dev.
>>>
>>>     For your perceived problem that classes don't have unique names,
>>>     your description sounds dubious: GeneratedConstructorAccessor is
>>>     already retired by JEP 416 [2] in Java 18, and there are many
>>>     other cases in which JDK generates classes without stable names,
>>>     notoriously LambdaMetafactory (Gradle wished for cacheable
>>>     Lambdas); the same applies for the generated classes for
>>>     MethodHandle's LambdaForms (which carries implementation code for
>>>     LambdaForm). How are you checking the classes? It seems you are
>>>     not checking hidden classes. Proxy and Lambda classes are defined
>>>     by the caller's class loader, while LambdaForms are under JDK's
>>>     system class loader I think. We need to ensure you are correctly
>>>     finding all unstable classes before we can proceed.
>>>
>>>     [1]: https://openjdk.org/projects/leyden/notes/01-beginnings
> <https://openjdk.org/projects/leyden/notes/01-beginnings>
>>>     <https://openjdk.org/projects/leyden/notes/01-beginnings
> <https://openjdk.org/projects/leyden/notes/01-beginnings>>
>>>     [2]: https://openjdk.org/jeps/416 <https://openjdk.org/jeps/416>
> <https://openjdk.org/jeps/416 <https://openjdk.org/jeps/416>>
>>>
>>>     On Wed, May 15, 2024 at 7:00?PM Aman Sharma <amansha at kth.se<mailto:amansha at kth.se>
>>>     <mailto:amansha at kth.se<mailto:amansha at kth.se> <mailto:amansha at kth.se>>> wrote:
>>>
>>>         Hi,
>>>
>>>
>>>         My name is Aman and I am a PhD student at KTH Royal Institute
>>>         of Technology, Stockholm, Sweden. I research as part of CHAINS
>>>         <https://chains.proj.kth.se/ <https://chains.proj.kth.se/>> project to
> strengthen the
>>>         software supply chain of multiple ecosystem. I particularly
>>>         focus on runtime integrity in Java. In this email, I want to
>>>         write about an issue I have discovered with /dynamic
>>>         generation of `java.lang.reflect.Proxy`classes/. I will
>>>         propose a solution and would love to hear the feedback from
>>>         the community. Let me know if this is the correct mailing-list
>>>         for such discussions. It seemed the most relevant from this
>>>         list <https://mail.openjdk.org/mailman/listinfo
> <https://mail.openjdk.org/mailman/listinfo>>.
>>>
>>>
>>>         *My research*
>>>
>>>         *
>>>         *
>>>
>>>         Java has features to load class on the fly - it can either
>>>         download or generate a class at runtime. These features are
>>>         useful for inner workings of JDK. For example, implementing
>>>         annotations, reflective access, etc. However, these features
>>>         have also contributed to critical vulnerabilities in the past
>>>         - CVE-2021-44228  (log4shell), CVE-2022-33980, CVE-2022-42392.
>>>         All of these vulnerabilities have one thing in common - /a
>>>         class that was not known during build time was
>>>         downloaded/generated at runtime and loaded into JVM./
>>>
>>>
>>>         To defend against such vulnerabilities, we propose a solution
>>>         to /allowlist classes for runtime/. This allowlist will
>>>         contain an exhaustive list of classes that can be loaded by
>>>         the JVM and it will be enforced at runtime. We build this
>>>         allowlist from three sources:
>>>
>>>          1. All classes of all modules provided by the Java Standard
>>>             Library. We use ClassGraph
>>>             <https://github.com/classgraph/classgraph
> <https://github.com/classgraph/classgraph>> to scan the JDK.
>>>          2. We can take the source code and all dependencies of an
>>>             application. We use a software bill of materials to get
>>>             all the data.
>>>          3. Finally, we use run the test suite to include any runtime
>>>             downloaded/generated classes.
>>>
>>>         Such a list is able to prevent the above 3 CVEs because it
>>>         does not let the "unknown" bytecode to be loaded.
>>>
>>>         *Problem with generating such an allowlist*
>>>         *
>>>         *
>>>         The first two parts of the allowlist are easy to get. The
>>>         problem is with the third step where we want to allowlist all
>>>         the classes that could be downloaded or generated. Upon
>>>         running the test suite and hooking to the classes it loads, we
>>>         observer that the list consists of classes that are called
>>>         "com/sun/proxy/$Proxy2",
>>>         "jdk/internal/reflect/GeneratedConstructorAccessor3" among
>>>         many more. The purpose of these classes can be identifed. The
>>>         proxy class is created for to implement an annotation. The
>>>         accessor gives access to constructor of a class to the JVM.
>>>
>>>         When enforcing this allowlist at runtime, we see that the
>>>         bytecode content for "com/sun/proxy/$Proxy2" differs in the
>>>         allowlist and at runtime. In our case, we we are experimenting
>>>         with pdfbox <https://github.com/apache/pdfbox <https://github.com/apache/pdfbox>> so
> we created
>>>         the allowlist using its test suite. Then we enforced this
>>>         allowlist while running some of its subcommands. However,
>>>         there was some other proxy class say "com/sun/proxy/$Proxy5"
>>>         at runtime that implemented the same interfaces and had the
>>>         same methods as "com/sun/proxy/$Proxy2" in the allowlist. They
>>>         only differed in the name of the class, order of fields, and
>>>         types for fields references. This could happen because the
>>>         order of the loading of class is workload dependent, but it
>>>         causes problem to generate such an allowlist.
>>>
>>>         *Solution
>>>         *
>>>
>>>
>>>         We propose that naming of subclasses of
>>>         "java/lang/reflect/Proxy" should not be dependent upon the
>>>         order of loading. In order to do so, two issues can be fixed:
>>>
>>>          1. The naming of the class should not be based on AtomicLong
>>>             <https://github.com/openjdk/jdk/blob/b687aa550837830b38f0f0faa69c353b1e85219c/src/java.base/share/classes/java/lang/reflect/Proxy.java#L531 <https://github.com/openjdk/jdk/blob/b687aa550837830b38f0f0faa69c353b1e85219c/src/java.base/share/classes/java/lang/reflect/Proxy.java#L531>>. Rather it could be named based on the interfaces it implements. I also wonder why AtomicLong is chosen in the first place.
>>>          2. Methods of the interfaces must be in a particular order.
>>>             Right now, they are not sorted in any particular order
>>>             <https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/lang/Class.java#L2178 <https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/lang/Class.java#L2178>>.
>>>
>>>
>>>         These fixes will make proxy class generation deterministic
>>>         with respect to order of loading and won't be flagged at
>>>         runtime since the test suite would already detect them.
>>>
>>>         I would love to hear from the community about these ideas. If
>>>         in agreement, I would be happy to produce a patch. I have
>>>         discovered this issue with subclasses of
>>>         GeneratedConstructorAccessor
>>>         <https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/jdk/internal/reflect/ConstructorAccessor.java <https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/jdk/internal/reflect/ConstructorAccessor.java>> as well and I imagine it will also apply to some other runtime generated classes. If you disagree, please let me know also. It helps with my research.
>>>
>>>         I also have PoCs for the above CVEs
>>>         <https://github.com/chains-project/exploits-for-sbom.exe
> <https://github.com/chains-project/exploits-for-sbom.exe>> and
>>>         a proof concept tool is being developed under the name
>>>         sbom.exe <https://github.com/chains-project/sbom.exe
> <https://github.com/chains-project/sbom.exe>> in case
>>>         any one wonders about the implementation. I would also be
>>>         happy to explain more.
>>>
>>>         Regards,
>>>         Aman Sharma
>>>
>>>         PhD Student
>>>         KTH Royal Institute of Technology
>>>         School of Electrical Engineering and Computer Science (EECS)
>>>         Department of Theoretical Computer Science (TCS)
>>>         <https://www.kth.se/profile/amansha
> <https://www.kth.se/profile/amansha>>https://algomaster99.github.io/
> <https://algomaster99.github.io/ <https://algomaster99.github.io/>>
>>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240525/34f19a7d/attachment-0001.htm>

From liangchenblue at gmail.com  Sat May 25 21:28:01 2024
From: liangchenblue at gmail.com (Chen Liang)
Date: Sat, 25 May 2024 16:28:01 -0500
Subject: Deterministic naming of subclasses of `java/lang/reflect/Proxy`
In-Reply-To: <fb6a2cb13c2449acac32fdfb781b0ce0@kth.se>
References: <bf26eb2f74874e02876b3868311922a9@kth.se>
 <CABe8uE0fk71Xy_PYHikSw9OtXE_i+M9zMbayPEXuTxLWLoy2ag@mail.gmail.com>
 <50405ca9c0a64372bace175b932f9ef7@kth.se>
 <61fbe3d9-9536-4113-adde-6cfc671ba1ee@oracle.com>
 <a860be44e06243799593aa8d67c048cd@kth.se>
 <CABe8uE115=DzYCdnvNazqFuuxtJoZnv9wRUkFA4-PS7g41QLMw@mail.gmail.com>
 <DB7PR02MB35938DCC3A392536B924164AFBEE2@DB7PR02MB3593.eurprd02.prod.outlook.com>
 <a0330ee0-5f45-4ef2-8500-e5fcdb696c52@oracle.com>
 <b214cc1a13fe4885a437e16b420e5483@kth.se>
 <ac2ebe5c-db49-4a2d-a5cd-10440a77aa16@oracle.com>
 <580b3aacd8df48fcaae3399718e229ab@kth.se>
 <CABe8uE065Q3+0yNjtyDF-eJM4LN-MbY9kfC44CnSQ-KM4p862g@mail.gmail.com>
 <b64077d6cf0045e98b630cf888785182@kth.se>
 <eabfa5ae508e4257bd0c9bbef244637f@kth.se>
 <CABe8uE13qRX7pRXJOdhUF0sUwF5WkxTAM517tSTOi1r2Q7ivOg@mail.gmail.com>
 <fb6a2cb13c2449acac32fdfb781b0ce0@kth.se>
Message-ID: <CABe8uE2M4mY-dmOaCVuJr0X-xC8vvrKx_FFv3eo8YqpBH=YM+Q@mail.gmail.com>

Did you reorder the field in picocli.CommandLine$Command?
In class 13 the usageHelpWidth was preceded by versionProvider, in class 9
it's preceded by requiredOptionMarker. It would also be helpful if you can
provide the bytecode for Command class, as it might be due to method
ordering in reflection from multiple inheritance (if Command extends
multiple interfaces), as you see some subsections of the methods (such as
from requiredOptionMarker to said footerHeading) are ordered.

Chen

On Sat, May 25, 2024 at 4:03?PM Aman Sharma <amansha at kth.se> wrote:

> Hi Chen,
>
> I am attaching proxy classes generated in the JVM of OpenJDK 22. I,
> instead of decompiling, I disassembled them and I do see a difference. For
> example, see method `footerHeading` in both classes. In $Proxy9, it is
> mapped to `m39` field and in $Proxy13, it is mapped to `m21` field. What is
> the reason for this ordering? Why is mapping of methods to fields depend
> upon the execution?
>
>
> Regards,
> Aman Sharma
>
> PhD Student
> KTH Royal Institute of Technology
> School of Electrical Engineering and Computer Science (EECS)
> Department of Theoretical Computer Science (TCS)
> <https://www.kth.se/profile/amansha>https://algomaster99.github.io/
> ------------------------------
> *From:* Chen Liang <liangchenblue at gmail.com>
> *Sent:* Wednesday, May 22, 2024 9:37:16 PM
> *To:* Aman Sharma
> *Cc:* core-libs-dev at openjdk.org; leyden-dev at openjdk.org
> *Subject:* Re: Deterministic naming of subclasses of
> `java/lang/reflect/Proxy`
>
> Hi Aman,
> Even though the specification says "not in any particular order," the
> getInterfaces and getMethods actually return an ordered array, in the order
> these methods/interfaces are declared in their class files.
>
> I believe you are decompiling the proxy classes generated by an older
> version of the JDK; for example, back in JDK 8, the proxy methods were not
> ordered because they were tracked in a HashMap:
> https://github.com/openjdk/jdk8u/blob/6b53212ef78ad50f9eede829c5ff87cadcdb434b/jdk/src/share/classes/sun/misc/ProxyGenerator.java#L405
> Which is no longer the case:
> https://github.com/openjdk/jdk/blob/d59c12fe1041a1f61f68408241a9aa4d96ac4fd2/src/java.base/share/classes/java/lang/reflect/ProxyGenerator.java#L241
>
> - Chen
>
> On Wed, May 22, 2024 at 1:19?PM Aman Sharma <amansha at kth.se> wrote:
>
>> Hi,
>>
>>
>> Another thing I wanted to look into in this thread was the order of
>> fields in the Proxy classes generated. They are also based on the a
>> number. The same proxy classes across different executions can have random
>> order of `Method` fields and the methods could be mapped to different field
>> names.
>>
>>
>> For example, consider the proxy class based on `picocli.CommandLine
>> <https://github.com/remkop/picocli/blob/da98db63d1b516141b7485881b0dcddfd082dbc8/src/main/java/picocli/CommandLine.java#L4541>`
>> in two different executions.
>>
>> // fields and method are truncated for brevity
>> public final class $Proxy9 extends Proxy implements CommandLine.Command {
>>     private static Method m1;
>>     private static Method m32;
>>     private static Method m21;
>>     private static Method m43;
>>     private static Method m36;
>>     private static Method m27;
>>
>>     public final boolean helpCommand() throws  {
>>         try {
>>             return (Boolean)super.h.invoke(this, m32, (Object[])null);
>>         } catch (RuntimeException | Error var2) {
>>             throw var2;
>>         } catch (Throwable var3) {
>>             throw new UndeclaredThrowableException(var3);
>>         }
>>      }
>>
>> // fields and method are truncated for brevity
>> public final class $Proxy13 extends Proxy implements CommandLine.Command {
>>     private static Method m1;
>>     private static Method m29;
>>     private static Method m16;
>>     private static Method m40;
>>     private static Method m38;
>>     private static Method m12;
>>
>>     public final boolean helpCommand() throws  {
>>         try {
>>             return (Boolean)super.h.invoke(this, m29, (Object[])null);
>>         } catch (RuntimeException | Error var2) {
>>             throw var2;
>>         } catch (Throwable var3) {
>>             throw new UndeclaredThrowableException(var3);
>>         }
>>     }
>>
>>
>> Notice the difference in the order of fields and `helpCommand` method is
>> mapped to a different field name in both classes. This happens because
>> the method array returned by `getMethods` is not sorted in any
>> particular order
>> <https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/lang/Class.java#L2178>
>> when generating a proxy class. What dictates this order? And why is it
>> not deterministic?
>>
>>
>> Regards,
>> Aman Sharma
>>
>> PhD Student
>> KTH Royal Institute of Technology
>> School of Electrical Engineering and Computer Science (EECS)
>> Department of Theoretical Computer Science (TCS)
>> <http://www.kth.se> <https://www.kth.se/profile/amansha>
>> <https://www.kth.se/profile/amansha>
>> <https://www.kth.se/profile/amansha>https://algomaster99.github.io/
>> ------------------------------
>> *From:* Aman Sharma
>> *Sent:* Wednesday, May 22, 2024 4:12:19 PM
>> *To:* Chen Liang
>> *Cc:* David Holmes; core-libs-dev at openjdk.org; leyden-dev at openjdk.org
>> *Subject:* Re: Deterministic naming of subclasses of
>> `java/lang/reflect/Proxy`
>>
>>
>> Hi Chen,
>>
>>
>> That's clear. Thanks for letting me know. I guess then Project Leyden is
>> working on naming the hidden classes deterministically to achieve their
>> goals <https://openjdk.org/projects/leyden/notes/01-beginnings>.
>>
>>
>> Regards,
>> Aman Sharma
>>
>> PhD Student
>> KTH Royal Institute of Technology
>> School of Electrical Engineering and Computer Science (EECS)
>> Department of Theoretical Computer Science (TCS)
>> <http://www.kth.se> <https://www.kth.se/profile/amansha>
>> <https://www.kth.se/profile/amansha>
>> <https://www.kth.se/profile/amansha>https://algomaster99.github.io/
>> ------------------------------
>> *From:* Chen Liang <liangchenblue at gmail.com>
>> *Sent:* Wednesday, May 22, 2024 1:35:46 PM
>> *To:* Aman Sharma
>> *Cc:* David Holmes; core-libs-dev at openjdk.org; leyden-dev at openjdk.org
>> *Subject:* Re: Deterministic naming of subclasses of
>> `java/lang/reflect/Proxy`
>>
>> Hi Aman,
>> We have tried defining Proxy as hidden classes; a previous attempt was on
>> hold because of issues with serialization. Otherwise, Proxies work great as
>> hidden classes.
>>
>> Chen
>>
>> On Mon, May 20, 2024 at 7:56?AM Aman Sharma <amansha at kth.se> wrote:
>>
>>> Hi David,
>>>
>>>
>>> > I would not expect any class load
>>> events.
>>>
>>>
>>> I understand. I also haven't tried to intercept them but I see only one
>>> approach right now to include them in an allowlist - 1) statically look for
>>> invocations of "Lookup::defineHiddenClass". 2) Instrument them so that
>>> its first argument "bytes" can be looked into upon. I haven't looked into
>>> it much because I did not have much idea about it. And they are hidden so
>>> it made it worse. ? Thanks for sharing the JEP!
>>>
>>>
>>> >
>>> java.lang.reflect.Proxy could define hidden classes to act as the proxy
>>> classes which implement proxy interfaces; from JEP 317
>>>
>>>
>>> It says that Proxy classes will also become hidden classes. Is it
>>> underway? Right now one can intercept, transform them, and include them in
>>> an allowlist. What do you think of naming them independent of AtomicLong so
>>> that a proxy class generated at runtime is easy to lookup in the allowlist?
>>>
>>>
>>>
>>> Regards,
>>> Aman Sharma
>>>
>>> PhD Student
>>> KTH Royal Institute of Technology
>>> School of Electrical Engineering and Computer Science (EECS)
>>> Department of Theoretical Computer Science (TCS)
>>> <http://www.kth.se> <https://www.kth.se/profile/amansha>
>>> <https://www.kth.se/profile/amansha>
>>> <https://www.kth.se/profile/amansha>https://algomaster99.github.io/
>>> ------------------------------
>>> *From:* David Holmes <david.holmes at oracle.com>
>>> *Sent:* Monday, May 20, 2024 2:30:37 PM
>>> *To:* Aman Sharma; liangchenblue at gmail.com
>>> *Cc:* core-libs-dev at openjdk.org; leyden-dev at openjdk.org
>>> *Subject:* Re: Deterministic naming of subclasses of
>>> `java/lang/reflect/Proxy`
>>>
>>> On 20/05/2024 10:12 pm, Aman Sharma wrote:
>>> > Hi David,
>>> >
>>> >
>>> >  > How did you try to intercept them? Hidden classes are not "loaded"
>>> in
>>> > the normal sense so won't trigger class load events.
>>> >
>>> >
>>> > I could not intercept them. I only see them when I pass
>>> `-verbose:class`
>>> > in the Java CLI.
>>>
>>> Yes that is why I asked how you tried to intercept them.
>>>
>>> >
>>> > I also couldn't intercept them using JVMTI Class File Load Hook
>>> > <
>>> https://docs.oracle.com/en/java/javase/21/docs/specs/jvmti.html#ClassFileLoadHook>
>>> event. However JEP 371 suggests that it should be possible to intercept
>>> them using JVMTI Class Load <
>>> https://docs.oracle.com/en/java/javase/21/docs/specs/jvmti.html#ClassLoad>
>>> event, but I won't have the bytecode at this stage. So is there no way to
>>> get its bytecode before it is linked and initialized in the JVM?
>>>
>>> Hidden classes are not loaded so I would not expect any class load
>>> events. However the exact nature of the JVMTI class load event is
>>> unclear as it talks about "class or interface creation" which is neither
>>> loading or defining per se. But a class prepare event sounds like it
>>> should be issued. However neither give you access to the bytecode of the
>>> class AFAICS.
>>>
>>> David
>>> -----
>>>
>>>
>>> >
>>> > Regards,
>>> > Aman Sharma
>>> >
>>> > PhD Student
>>> > KTH Royal Institute of Technology
>>> > School of Electrical Engineering and Computer Science (EECS)
>>> > Department of Theoretical Computer Science (TCS)
>>> > <
>>> http://www.kth.se><https://www.kth.se/profile/amansha><https://www.kth.se/profile/amansha
>>> >
>>> > <https://www.kth.se/profile/amansha>https://algomaster99.github.io/
>>> > <https://algomaster99.github.io/>
>>> >
>>> ------------------------------------------------------------------------
>>> > *From:* David Holmes <david.holmes at oracle.com>
>>> > *Sent:* Monday, May 20, 2024 2:59:17 AM
>>> > *To:* Aman Sharma; liangchenblue at gmail.com
>>> > *Cc:* core-libs-dev at openjdk.org; leyden-dev at openjdk.org
>>> > *Subject:* Re: Deterministic naming of subclasses of
>>> > `java/lang/reflect/Proxy`
>>> > On 17/05/2024 9:43 pm, Aman Sharma wrote:
>>> >> Hi Chen,
>>> >>
>>> >>  > java.lang.invoke.LambdaForm$MH/0x00000200cc000400
>>> >>
>>> >> I do see this as output when I pass -verbose:class. However, based on
>>> my
>>> >> experiments, I have seen that neither an agent passed via 'javaagent'
>>> >> nor an agent passed via 'agentpath' is able to intercept this hidden
>>> class.
>>> >
>>> > How did you try to intercept them? Hidden classes are not "loaded" in
>>> > the normal sense so won't trigger class load events.
>>> >
>>> >> Also, I was a bit confused since I saw somewhere that the names of
>>> >> hidden classes are null. But thanks for clarifying here.
>>> >
>>> > The JEP clearly defines the name format for hidden classes - though the
>>> > final component is VM specific (and typically a hashcode).
>>> >
>>> > https://openjdk.org/jeps/371 <https://openjdk.org/jeps/371>
>>> >
>>> > Cheers,
>>> > David
>>> > -----
>>> >
>>> >>  > avoid dynamic class loading
>>> >>
>>> >> I don't see dynamic class loading as a problem. I only mind some
>>> >> unstable generation aspects of them which make it hard to verify them
>>> >> based on an allowlist.
>>> >>
>>> >> For example, if this hidden class is generated with the exact same
>>> name
>>> >> and the exact same bytecode during runtime as well, it would be easy
>>> to
>>> >> verify it. However, I do see the names are based on some sort of
>>> memory
>>> >> address so and I don't know what bytecode it has so I don't have
>>> >> suggestions to make them stable as of now. For Proxy classes, I feel
>>> it
>>> >> can be addressed unless you disagree or some involved in Project
>>> Leyden
>>> >> does. :) Thank you for forwarding my mail there.
>>> >>
>>> >> Regards,
>>> >> Aman Sharma
>>> >>
>>> >> PhD Student
>>> >> KTH Royal Institute of Technology
>>> >> https://algomaster99.github.io/ <https://algomaster99.github.io/>
>>> > <https://algomaster99.github.io/ <https://algomaster99.github.io/>>
>>> >>
>>> >>
>>> ------------------------------------------------------------------------
>>> >> *From:* liangchenblue at gmail.com <liangchenblue at gmail.com>
>>> >> *Sent:* Friday, May 17, 2024 1:23:58 pm
>>> >> *To:* Aman Sharma <amansha at kth.se>
>>> >> *Cc:* core-libs-dev at openjdk.org <core-libs-dev at openjdk.org>;
>>> >> leyden-dev at openjdk.org <leyden-dev at openjdk.org>
>>> >> *Subject:* Re: Deterministic naming of subclasses of
>>> >> `java/lang/reflect/Proxy`
>>> >>
>>> >> Hi Aman,
>>> >> For `-verbose:class`, it's a JVM argument instead of a program
>>> argument;
>>> >> so when you run a java program like `java Main`, you should call it
>>> as
>>> >> `java -verbose:class Main`.
>>> >> When done correctly, you should see hidden class outputs like:
>>> >> [0.032s][info][class,load]
>>> >> java.lang.invoke.LambdaForm$MH/0x00000200cc000400 source:
>>> >> __JVM_LookupDefineClass__
>>> >> The loading of java.lang.invoke hidden classes requires your program
>>> to
>>> >> use MethodHandle features, like a lambda.
>>> >>
>>> >> I think the problem you are exploring, that to avoid dynamic class
>>> >> loading and effectively turn Java Platform closed for security, is
>>> also
>>> >> being accomplished by project Leyden (as I've shared initially);
>>> Thus, I
>>> >> am forwarding this to leyden-dev instead, so you can see what
>>> approach
>>> >> Leyden uses to accomplish the same goal as yours.
>>> >>
>>> >> Regards, Chen Liang
>>> >>
>>> >> On Fri, May 17, 2024 at 4:40?AM Aman Sharma <amansha at kth.se
>>> >> <mailto:amansha at kth.se <mailto:amansha at kth.se <amansha at kth.se>>>>
>>> wrote:
>>> >>
>>> >>     __
>>> >>
>>> >>     Hi Roger,
>>> >>
>>> >>
>>> >>     Do you have ideas on how to intercept them? My javaagent is not
>>> able
>>> >>     to nor a JVMTI agent passed using `agentpath` option. It also does
>>> >>     not seem to show up in logs when I pass `-verbose:class`.
>>> >>
>>> >>
>>> >>     Also, what do you think of renaming the proxy classes as suggested
>>> >>     below?
>>> >>
>>> >>
>>> >>     Regards,
>>> >>     Aman Sharma
>>> >>
>>> >>     PhD Student
>>> >>     KTH Royal Institute of Technology
>>> >>     School of Electrical Engineering and Computer Science (EECS)
>>> >>     Department of Theoretical Computer Science (TCS)
>>> >>     <http://www.kth.se><https://www.kth.se/profile/amansha><
>>> https://www.kth.se/profile/amansha <
>>> http://www.kth.se><https://www.kth.se/profile/amansha><https://www.kth.se/profile/amansha
>>> >>
>>> >>     <https://www.kth.se/profile/amansha
>>> > <https://www.kth.se/profile/amansha>>https://algomaster99.github.io/
>>> >>     <https://algomaster99.github.io/ <https://algomaster99.github.io/
>>> >>
>>> >>
>>> ------------------------------------------------------------------------
>>> >>     *From:* core-libs-dev <core-libs-dev-retn at openjdk.org
>>> >>     <mailto:core-libs-dev-retn at openjdk.org
>>> > <mailto:core-libs-dev-retn at openjdk.org
>>> <core-libs-dev-retn at openjdk.org>>>> on behalf of Roger Riggs
>>> >>     <roger.riggs at oracle.com <mailto:roger.riggs at oracle.com <
>>> mailto:roger.riggs at oracle.com <roger.riggs at oracle.com>>>>
>>> >>     *Sent:* Friday, May 17, 2024 4:57:46 AM
>>> >>     *To:* core-libs-dev at openjdk.org <mailto:core-libs-dev at openjdk.org
>>> <mailto:core-libs-dev at openjdk.org <core-libs-dev at openjdk.org>>>
>>> >>     *Subject:* Re: Deterministic naming of subclasses of
>>> >>     `java/lang/reflect/Proxy`
>>> >>     Hi Aman,
>>> >>
>>> >>     You may also run into hidden classes (JEP 371: Hidden Classes)
>>> that
>>> >>     allow classes to be defined, at runtime, without names.
>>> >>     It has been proposed to use them for generated proxies but that
>>> >>     hasn't been implemented yet.
>>> >>     There are benefits to having nameless classes, because they can't
>>> be
>>> >>     referenced by name, only as a capability, they can be better
>>> >>     encapsulated.
>>> >>
>>> >>     fyi, Roger Riggs
>>> >>
>>> >>
>>> >>     On 5/16/24 8:11 AM, Aman Sharma wrote:
>>> >>>
>>> >>>     Hi,
>>> >>>
>>> >>>
>>> >>>     Thanks for your response, Liang!
>>> >>>
>>> >>>
>>> >>>     > I think you meant CVE-2021-42392 instead of 2022.
>>> >>>
>>> >>>
>>> >>>     Sorry of the error. I indeed meant CVE-2021-42392
>>> >>>     <https://nvd.nist.gov/vuln/detail/cve-2021-42392
>>> > <https://nvd.nist.gov/vuln/detail/cve-2021-42392>>.
>>> >>>
>>> >>>
>>> >>>     > Leyden mainly avoids this unstable generation by performing a
>>> >>>     training run to collect classes loaded
>>> >>>
>>> >>>
>>> >>>     Would love to know the details of Project Leyden and how they
>>> >>>     worked so far to focus on this goal. In our case, the training
>>> run
>>> >>>     is the test suite.
>>> >>>
>>> >>>
>>> >>>     > GeneratedConstructorAccessor is already retired by JEP 416 [2]
>>> >>>     in Java 18
>>> >>>
>>> >>>
>>> >>>     I did see them not appearing in my allowlist when I ran my study
>>> >>>     subject (Apache PDFBox) with Java 21. Thanks for letting me know
>>> >>>     about this JEP. I see they are re-implemented with method
>>> handles.
>>> >>>
>>> >>>
>>> >>>     > How are you checking the classes?
>>> >>>
>>> >>>
>>> >>>     To detect runtime generated code, we have javaagent that is
>>> hooked
>>> >>>     statically to the test suite execution. It gives us all classes
>>> >>>     that that is loaded post the JVM and the javaagent are loaded. So
>>> >>>     we only check the classes loaded for the purpose of running the
>>> >>>     application. This is also why we did not choose -agentlib as it
>>> >>>     would give classes for the setting up JVM and javaagent and we
>>> the
>>> >>>     user of our tool must the classes they load.
>>> >>>
>>> >>>
>>> >>>     Next, we have a `ClassFileTransformer` hook in the agent where we
>>> >>>     produce the checksum using the bytecode. And we compare the
>>> >>>     checksum with the one existing in the allowlist. The checksum
>>> >>>     computation algorithm is same for both steps. Let me describe how
>>> >>>     I compute the checksum.
>>> >>>
>>> >>>
>>> >>>      1. I get the CONSTANT_Class_info
>>> >>>         <
>>> https://docs.oracle.com/javase/specs/jvms/se11/html/jvms-4.html#jvms-4.4.1
>>> <
>>> https://docs.oracle.com/javase/specs/jvms/se11/html/jvms-4.html#jvms-4.4.1>>
>>> entry corresponding to `this_class` and rewrite the CONSTANT_Utf8_info <
>>> https://docs.oracle.com/javase/specs/jvms/se11/html/jvms-4.html#jvms-4.4.7
>>> <
>>> https://docs.oracle.com/javase/specs/jvms/se11/html/jvms-4.html#jvms-4.4.7>>
>>> corresponding to a fix String constant, say "foo".
>>> >>>      2. Since, the name of the class is used to refer to its types
>>> >>>         members (fields/method), I get all CONSTANT_Fieldref_info
>>> >>>         <
>>> https://docs.oracle.com/javase/specs/jvms/se11/html/jvms-4.html#jvms-4.4.2
>>> <
>>> https://docs.oracle.com/javase/specs/jvms/se11/html/jvms-4.html#jvms-4.4.2>>
>>> and if its `class_index` corresponds to the old `this_class`, we rewrite
>>> the UTF8 value of class_index to the same constant "foo".
>>> >>>      3. Next, since the naming of the fields, in Proxy classes, are
>>> >>>         also suffixed by numbers, for example, `private static Method
>>> >>>         m4`, we rewrite the UTF8 value of name in the
>>> >>>         CONSTANT_NameAndType_info
>>> >>>         <
>>> https://docs.oracle.com/javase/specs/jvms/se11/html/jvms-4.html#jvms-4.4.6
>>> <
>>> https://docs.oracle.com/javase/specs/jvms/se11/html/jvms-4.html#jvms-4.4.6
>>> >>.
>>> >>>      4. These fields can also have a random order so we simply sort
>>> >>>         the entire byte code using `Arrays.sort(byte[])` to eliminate
>>> >>>         any differences due to ordering of fields/methods.
>>> >>>      5. Simply sorting the byte array still had minute differences. I
>>> >>>         could not understand why they existed even though values in
>>> >>>         constant pool of the bytecode in allowlist and at runtime
>>> were
>>> >>>         exactly the same after rewriting. The differences existed in
>>> >>>         the bytes of the Code attribute of methods. I concluded that
>>> >>>         the bytes stored some position information. To avoid this, I
>>> >>>         created a subarray where I considered the bytes corresponding
>>> >>>         to `CONSTANT_Utf8_info.bytes` only. Computing a checksum for
>>> >>>         it resulted in the same checksums for both classfiles.
>>> >>>
>>> >>>
>>> >>>     Let's understand the whole approach with an example of Proxy
>>> class.
>>> >>>
>>> >>>     `
>>> >>>     public  final  class  $Proxy42  extends  Proxy  implements
>>> org.apache.logging.log4j.core.config.plugins.Plugin  {
>>> >>>     `
>>> >>>
>>> >>>     The will go in the allowlist as "Proxy_Plugin: <SHA256
>>> checksum>".
>>> >>>
>>> >>>     When the same class is intercepted at runtime, say "$Proxy10", we
>>> >>>     look for "Proxy_Plugin" in the allowlist and since the checksum
>>> >>>     algorithm is same in both cases, we get a match and let the class
>>> >>>     load.
>>> >>>
>>> >>>     This approach has seemed to work well for Proxy classes,
>>> Generated
>>> >>>     Constructor Accessor (which is removed as you said). I also
>>> looked
>>> >>>     at the species generated by method handles. I did not notice any
>>> >>>     modification in them. Their name generation seemed okay to me. If
>>> >>>     some new Species are generated, it is of course detected since it
>>> >>>     is not in the allowlist.
>>> >>>
>>> >>>     I have not looked into LambdaMetafactory because I did not
>>> >>>     encounter it as a problem so far, but I am aware its name
>>> >>>     generation is also unstable. I have run my approach only a few
>>> >>>     projects only. And for hidden classes, I assume the the agent
>>> >>>     won't be able to intercept them so detecting them would be really
>>> >>>     hard.
>>> >>>
>>> >>>
>>> >>>     Regards,
>>> >>>     Aman Sharma
>>> >>>
>>> >>>     PhD Student
>>> >>>     KTH Royal Institute of Technology
>>> >>>     School of Electrical Engineering and Computer Science (EECS)
>>> >>>     Department of Theoretical Computer Science (TCS)
>>> >>>     <https://www.kth.se/profile/amansha
>>> > <https://www.kth.se/profile/amansha>>https://algomaster99.github.io/
>>> > <https://algomaster99.github.io/ <https://algomaster99.github.io/>>
>>> >>>
>>> ------------------------------------------------------------------------
>>> >>>     *From:* liangchenblue at gmail.com <mailto:liangchenblue at gmail.com
>>> <mailto:liangchenblue at gmail.com <liangchenblue at gmail.com>>>
>>> >>>     <liangchenblue at gmail.com> <mailto:liangchenblue at gmail.com <
>>> mailto:liangchenblue at gmail.com <liangchenblue at gmail.com>>>
>>> >>>     *Sent:* Thursday, May 16, 2024 5:52:03 AM
>>> >>>     *To:* Aman Sharma; core-libs-dev
>>> >>>     *Cc:* Martin Monperrus
>>> >>>     *Subject:* Re: Deterministic naming of subclasses of
>>> >>>     `java/lang/reflect/Proxy`
>>> >>>     Hi Aman,
>>> >>>     I think you meant CVE-2021-42392 instead of 2022.
>>> >>>
>>> >>>     For your approach of an "allowlist" for Java runtime, project
>>> >>>     Leyden is looking to generate a static image [1], that
>>> >>>     > At run time it cannot load classes from outside the image, nor
>>> >>>     can it create classes dynamically.
>>> >>>     Leyden mainly avoids this unstable generation by performing a
>>> >>>     training run to collect classes loaded and even object graphs; I
>>> >>>     am not familiar with the details unfortunately.
>>> >>>
>>> >>>     Otherwise, the Proxy discussion belongs better to core-libs-dev,
>>> >>>     as java.lang.reflect.Proxy is part of Java's core libraries. I am
>>> >>>     replying this thread to core-libs-dev.
>>> >>>
>>> >>>     For your perceived problem that classes don't have unique names,
>>> >>>     your description sounds dubious: GeneratedConstructorAccessor is
>>> >>>     already retired by JEP 416 [2] in Java 18, and there are many
>>> >>>     other cases in which JDK generates classes without stable names,
>>> >>>     notoriously LambdaMetafactory (Gradle wished for cacheable
>>> >>>     Lambdas); the same applies for the generated classes for
>>> >>>     MethodHandle's LambdaForms (which carries implementation code for
>>> >>>     LambdaForm). How are you checking the classes? It seems you are
>>> >>>     not checking hidden classes. Proxy and Lambda classes are defined
>>> >>>     by the caller's class loader, while LambdaForms are under JDK's
>>> >>>     system class loader I think. We need to ensure you are correctly
>>> >>>     finding all unstable classes before we can proceed.
>>> >>>
>>> >>>     [1]: https://openjdk.org/projects/leyden/notes/01-beginnings
>>> > <https://openjdk.org/projects/leyden/notes/01-beginnings>
>>> >>>     <https://openjdk.org/projects/leyden/notes/01-beginnings
>>> > <https://openjdk.org/projects/leyden/notes/01-beginnings>>
>>> >>>     [2]: https://openjdk.org/jeps/416 <https://openjdk.org/jeps/416>
>>>
>>> > <https://openjdk.org/jeps/416 <https://openjdk.org/jeps/416>>
>>> >>>
>>> >>>     On Wed, May 15, 2024 at 7:00?PM Aman Sharma <amansha at kth.se
>>> >>>     <mailto:amansha at kth.se <mailto:amansha at kth.se <amansha at kth.se>>>>
>>> wrote:
>>> >>>
>>> >>>         Hi,
>>> >>>
>>> >>>
>>> >>>         My name is Aman and I am a PhD student at KTH Royal Institute
>>> >>>         of Technology, Stockholm, Sweden. I research as part of
>>> CHAINS
>>> >>>         <https://chains.proj.kth.se/ <https://chains.proj.kth.se/>>
>>> project to
>>> > strengthen the
>>> >>>         software supply chain of multiple ecosystem. I particularly
>>> >>>         focus on runtime integrity in Java. In this email, I want to
>>> >>>         write about an issue I have discovered with /dynamic
>>> >>>         generation of `java.lang.reflect.Proxy`classes/. I will
>>> >>>         propose a solution and would love to hear the feedback from
>>> >>>         the community. Let me know if this is the correct
>>> mailing-list
>>> >>>         for such discussions. It seemed the most relevant from this
>>> >>>         list <https://mail.openjdk.org/mailman/listinfo
>>> > <https://mail.openjdk.org/mailman/listinfo>>.
>>> >>>
>>> >>>
>>> >>>         *My research*
>>> >>>
>>> >>>         *
>>> >>>         *
>>> >>>
>>> >>>         Java has features to load class on the fly - it can either
>>> >>>         download or generate a class at runtime. These features are
>>> >>>         useful for inner workings of JDK. For example, implementing
>>> >>>         annotations, reflective access, etc. However, these features
>>> >>>         have also contributed to critical vulnerabilities in the past
>>> >>>         - CVE-2021-44228  (log4shell), CVE-2022-33980,
>>> CVE-2022-42392.
>>> >>>         All of these vulnerabilities have one thing in common - /a
>>> >>>         class that was not known during build time was
>>> >>>         downloaded/generated at runtime and loaded into JVM./
>>> >>>
>>> >>>
>>> >>>         To defend against such vulnerabilities, we propose a solution
>>> >>>         to /allowlist classes for runtime/. This allowlist will
>>> >>>         contain an exhaustive list of classes that can be loaded by
>>> >>>         the JVM and it will be enforced at runtime. We build this
>>> >>>         allowlist from three sources:
>>> >>>
>>> >>>          1. All classes of all modules provided by the Java Standard
>>> >>>             Library. We use ClassGraph
>>> >>>             <https://github.com/classgraph/classgraph
>>> > <https://github.com/classgraph/classgraph>> to scan the JDK.
>>> >>>          2. We can take the source code and all dependencies of an
>>> >>>             application. We use a software bill of materials to get
>>> >>>             all the data.
>>> >>>          3. Finally, we use run the test suite to include any runtime
>>> >>>             downloaded/generated classes.
>>> >>>
>>> >>>         Such a list is able to prevent the above 3 CVEs because it
>>> >>>         does not let the "unknown" bytecode to be loaded.
>>> >>>
>>> >>>         *Problem with generating such an allowlist*
>>> >>>         *
>>> >>>         *
>>> >>>         The first two parts of the allowlist are easy to get. The
>>> >>>         problem is with the third step where we want to allowlist all
>>> >>>         the classes that could be downloaded or generated. Upon
>>> >>>         running the test suite and hooking to the classes it loads,
>>> we
>>> >>>         observer that the list consists of classes that are called
>>> >>>         "com/sun/proxy/$Proxy2",
>>> >>>         "jdk/internal/reflect/GeneratedConstructorAccessor3" among
>>> >>>         many more. The purpose of these classes can be identifed. The
>>> >>>         proxy class is created for to implement an annotation. The
>>> >>>         accessor gives access to constructor of a class to the JVM.
>>> >>>
>>> >>>         When enforcing this allowlist at runtime, we see that the
>>> >>>         bytecode content for "com/sun/proxy/$Proxy2" differs in the
>>> >>>         allowlist and at runtime. In our case, we we are
>>> experimenting
>>> >>>         with pdfbox <https://github.com/apache/pdfbox <
>>> https://github.com/apache/pdfbox>> so
>>> > we created
>>> >>>         the allowlist using its test suite. Then we enforced this
>>> >>>         allowlist while running some of its subcommands. However,
>>> >>>         there was some other proxy class say "com/sun/proxy/$Proxy5"
>>> >>>         at runtime that implemented the same interfaces and had the
>>> >>>         same methods as "com/sun/proxy/$Proxy2" in the allowlist.
>>> They
>>> >>>         only differed in the name of the class, order of fields, and
>>> >>>         types for fields references. This could happen because the
>>> >>>         order of the loading of class is workload dependent, but it
>>> >>>         causes problem to generate such an allowlist.
>>> >>>
>>> >>>         *Solution
>>> >>>         *
>>> >>>
>>> >>>
>>> >>>         We propose that naming of subclasses of
>>> >>>         "java/lang/reflect/Proxy" should not be dependent upon the
>>> >>>         order of loading. In order to do so, two issues can be fixed:
>>> >>>
>>> >>>          1. The naming of the class should not be based on AtomicLong
>>> >>>             <
>>> https://github.com/openjdk/jdk/blob/b687aa550837830b38f0f0faa69c353b1e85219c/src/java.base/share/classes/java/lang/reflect/Proxy.java#L531
>>> <
>>> https://github.com/openjdk/jdk/blob/b687aa550837830b38f0f0faa69c353b1e85219c/src/java.base/share/classes/java/lang/reflect/Proxy.java#L531>>.
>>> Rather it could be named based on the interfaces it implements. I also
>>> wonder why AtomicLong is chosen in the first place.
>>> >>>          2. Methods of the interfaces must be in a particular order.
>>> >>>             Right now, they are not sorted in any particular order
>>> >>>             <
>>> https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/lang/Class.java#L2178
>>> <
>>> https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/lang/Class.java#L2178
>>> >>.
>>> >>>
>>> >>>
>>> >>>         These fixes will make proxy class generation deterministic
>>> >>>         with respect to order of loading and won't be flagged at
>>> >>>         runtime since the test suite would already detect them.
>>> >>>
>>> >>>         I would love to hear from the community about these ideas. If
>>> >>>         in agreement, I would be happy to produce a patch. I have
>>> >>>         discovered this issue with subclasses of
>>> >>>         GeneratedConstructorAccessor
>>> >>>         <
>>> https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/jdk/internal/reflect/ConstructorAccessor.java
>>> <
>>> https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/jdk/internal/reflect/ConstructorAccessor.java>>
>>> as well and I imagine it will also apply to some other runtime generated
>>> classes. If you disagree, please let me know also. It helps with my
>>> research.
>>> >>>
>>> >>>         I also have PoCs for the above CVEs
>>> >>>         <https://github.com/chains-project/exploits-for-sbom.exe
>>> > <https://github.com/chains-project/exploits-for-sbom.exe>> and
>>> >>>         a proof concept tool is being developed under the name
>>> >>>         sbom.exe <https://github.com/chains-project/sbom.exe
>>> > <https://github.com/chains-project/sbom.exe>> in case
>>> >>>         any one wonders about the implementation. I would also be
>>> >>>         happy to explain more.
>>> >>>
>>> >>>         Regards,
>>> >>>         Aman Sharma
>>> >>>
>>> >>>         PhD Student
>>> >>>         KTH Royal Institute of Technology
>>> >>>         School of Electrical Engineering and Computer Science (EECS)
>>> >>>         Department of Theoretical Computer Science (TCS)
>>> >>>         <https://www.kth.se/profile/amansha
>>> > <https://www.kth.se/profile/amansha>>https://algomaster99.github.io/
>>> > <https://algomaster99.github.io/ <https://algomaster99.github.io/>>
>>> >>>
>>> >>
>>> >>
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240525/e5cedb02/attachment-0001.htm>

From sgibbons at openjdk.org  Sat May 25 21:57:13 2024
From: sgibbons at openjdk.org (Scott Gibbons)
Date: Sat, 25 May 2024 21:57:13 GMT
Subject: RFR: 8320448: Accelerate IndexOf using AVX2 [v41]
In-Reply-To: <shAjphsNO3mHk65j7tCZHfwm-065JuWb9aCGrzZkynA=.472714d0-ed3c-41c2-aa95-4b76192d2297@github.com>
References: <uWi4QxH31hL93771gkl_GgvP0m84IRSoR_1Yi8hD17E=.bc6ed458-7081-4c3f-9348-f59358fa05a4@github.com>
 <atTesjhro2xH1gQek1JHVwgQiERxY_XbAna9KXmcHBA=.0a359fe5-aacf-483d-bc7c-6357afbd2da7@github.com>
 <shAjphsNO3mHk65j7tCZHfwm-065JuWb9aCGrzZkynA=.472714d0-ed3c-41c2-aa95-4b76192d2297@github.com>
Message-ID: <BlgHqK0FFYpSoNvaw6d7xBK1Xig3QSacyCkjFFryCDU=.55e8f808-6ebc-4c8c-8bf2-9ffe18ad97bd@github.com>

On Sat, 25 May 2024 00:15:03 GMT, Sandhya Viswanathan <sviswanathan at openjdk.org> wrote:

>> Scott Gibbons has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix test; review comments
>
> src/hotspot/cpu/x86/c2_stubGenerator_x86_64_string.cpp line 316:
> 
>> 314:   // Set up jump tables.  Used when needle size <= NUMBER_OF_CASES
>> 315:   setup_jump_tables(ae, L_returnRBP, L_checkRangeAndReturn, L_bigCaseFixupAndReturn,
>> 316:                     &big_jump_table, &small_jump_table, _masm);
> 
> We could directly use L_returnError here instead of L_returnRBP.

OK

> src/hotspot/cpu/x86/c2_stubGenerator_x86_64_string.cpp line 476:
> 
>> 474: // Used to check and return value in rbp - usually error
>> 475:   __ bind(L_returnRBP);
>> 476:   __ movq(rax, rbp);
> 
> This seems spurious as rax is being overwritten at line 489. Did you intend to return -1?

Removed all references to L_returnRBP.  Replaced with L_returnError.

> src/hotspot/cpu/x86/c2_stubGenerator_x86_64_string.cpp line 1816:
> 
>> 1814:         byte_compare_helper(i + 1, L_loopTop, L_fixup, needle, needle_val, hs_ptr, eq_mask, set_bit,
>> 1815:                             rTmp4, ae, _masm);
>> 1816:       }
> 
> L_checkRange on NoMatch could be L_error instead.

Fixed

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1614900796
PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1614903860
PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1614901577

From sgibbons at openjdk.org  Sat May 25 21:57:14 2024
From: sgibbons at openjdk.org (Scott Gibbons)
Date: Sat, 25 May 2024 21:57:14 GMT
Subject: RFR: 8320448: Accelerate IndexOf using AVX2 [v35]
In-Reply-To: <tI546ou6EUgSgpexgC_lyWf1C-WtWEjyV6rBZEihYQQ=.5be9e688-e107-498e-8103-0b7d3acc87bc@github.com>
References: <uWi4QxH31hL93771gkl_GgvP0m84IRSoR_1Yi8hD17E=.bc6ed458-7081-4c3f-9348-f59358fa05a4@github.com>
 <-vyOZzeMslZqgJpTsQnnOWi4abWiM8fNeWSVx5LEHm8=.d37011ee-102c-4874-aa26-d113949d25ea@github.com>
 <tI546ou6EUgSgpexgC_lyWf1C-WtWEjyV6rBZEihYQQ=.5be9e688-e107-498e-8103-0b7d3acc87bc@github.com>
Message-ID: <dwcdnr96sIA1Tgd99C2mhfoiHQ585F900SH5zEDaYvc=.945857ff-a53f-46a9-b91e-12c8b81abb01@github.com>

On Fri, 24 May 2024 23:04:55 GMT, Sandhya Viswanathan <sviswanathan at openjdk.org> wrote:

>> Scott Gibbons has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Review comments - move stubGen*_string.cpp to c2_stubGen*_string.cpp
>
> src/hotspot/cpu/x86/c2_stubGenerator_x86_64_string.cpp line 1740:
> 
>> 1738:     //
>> 1739:     // If a match is found, jump to L_checkRangeAndReturn, which ensures the
>> 1740:     // matched needle is not past the end of the haystack.
> 
> These labels are not in this function.

Fixed

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1614901350

From sgibbons at openjdk.org  Sat May 25 22:16:41 2024
From: sgibbons at openjdk.org (Scott Gibbons)
Date: Sat, 25 May 2024 22:16:41 GMT
Subject: RFR: 8320448: Accelerate IndexOf using AVX2 [v42]
In-Reply-To: <uWi4QxH31hL93771gkl_GgvP0m84IRSoR_1Yi8hD17E=.bc6ed458-7081-4c3f-9348-f59358fa05a4@github.com>
References: <uWi4QxH31hL93771gkl_GgvP0m84IRSoR_1Yi8hD17E=.bc6ed458-7081-4c3f-9348-f59358fa05a4@github.com>
Message-ID: <F71Kcmpc9wzXmQY-Tb9EP-0Z9R222Elp-VDLPcR2LjA=.d6cd6c09-ea4f-49f8-bbd5-8edd7bbd9e8a@github.com>

> Re-write the IndexOf code without the use of the pcmpestri instruction, only using AVX2 instructions.  This change accelerates String.IndexOf on average 1.3x for AVX2.  The benchmark numbers:
> 
> 
> Benchmark	                                               Score		Latest		
> StringIndexOf.advancedWithMediumSub   343.573		317.934		0.925375393x
> StringIndexOf.advancedWithShortSub1	  1039.081		1053.96		1.014319384x
> StringIndexOf.advancedWithShortSub2	      55.828		110.541		1.980027943x
> StringIndexOf.constantPattern	                9.361		11.906		1.271872663x
> StringIndexOf.searchCharLongSuccess	        4.216		4.218		1.000474383x
> StringIndexOf.searchCharMediumSuccess	3.133		3.216		1.02649218x
> StringIndexOf.searchCharShortSuccess	3.76		        3.761		1.000265957x
> StringIndexOf.success	                                9.186		9.713		1.057369911x
> StringIndexOf.successBig	                      14.341		46.343		3.231504079x
> StringIndexOfChar.latin1_AVX2_String	  6220.918		12154.52		1.953814533x
> StringIndexOfChar.latin1_AVX2_char	  5503.556		5540.044		1.006629895x
> StringIndexOfChar.latin1_SSE4_String	  6978.854		6818.689		0.977049957x
> StringIndexOfChar.latin1_SSE4_char	  5657.499		5474.624		0.967675646x
> StringIndexOfChar.latin1_Short_String	  7132.541		6863.359		0.962260014x
> StringIndexOfChar.latin1_Short_char	16013.389	      16162.437		1.009307711x
> StringIndexOfChar.latin1_mixed_String	  7386.123	      14771.622		1.999915517x
> StringIndexOfChar.latin1_mixed_char	  9901.671		9782.245		0.987938803

Scott Gibbons has updated the pull request incrementally with one additional commit since the last revision:

  Review comments; fix reading past end of haystack when (n-k) < 32

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/16753/files
  - new: https://git.openjdk.org/jdk/pull/16753/files/b154faee..e13c7ea4

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16753&range=41
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16753&range=40-41

  Stats: 78 lines in 1 file changed: 29 ins; 9 del; 40 mod
  Patch: https://git.openjdk.org/jdk/pull/16753.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16753/head:pull/16753

PR: https://git.openjdk.org/jdk/pull/16753

From sgibbons at openjdk.org  Sat May 25 22:19:41 2024
From: sgibbons at openjdk.org (Scott Gibbons)
Date: Sat, 25 May 2024 22:19:41 GMT
Subject: RFR: 8320448: Accelerate IndexOf using AVX2 [v43]
In-Reply-To: <uWi4QxH31hL93771gkl_GgvP0m84IRSoR_1Yi8hD17E=.bc6ed458-7081-4c3f-9348-f59358fa05a4@github.com>
References: <uWi4QxH31hL93771gkl_GgvP0m84IRSoR_1Yi8hD17E=.bc6ed458-7081-4c3f-9348-f59358fa05a4@github.com>
Message-ID: <oFs22uebWl0oFfLMtpgvsLv0U18o5uUwttHFHbTMUhI=.0f8507e2-48d2-4d92-8c66-bad4d2276774@github.com>

> Re-write the IndexOf code without the use of the pcmpestri instruction, only using AVX2 instructions.  This change accelerates String.IndexOf on average 1.3x for AVX2.  The benchmark numbers:
> 
> 
> Benchmark	                                               Score		Latest		
> StringIndexOf.advancedWithMediumSub   343.573		317.934		0.925375393x
> StringIndexOf.advancedWithShortSub1	  1039.081		1053.96		1.014319384x
> StringIndexOf.advancedWithShortSub2	      55.828		110.541		1.980027943x
> StringIndexOf.constantPattern	                9.361		11.906		1.271872663x
> StringIndexOf.searchCharLongSuccess	        4.216		4.218		1.000474383x
> StringIndexOf.searchCharMediumSuccess	3.133		3.216		1.02649218x
> StringIndexOf.searchCharShortSuccess	3.76		        3.761		1.000265957x
> StringIndexOf.success	                                9.186		9.713		1.057369911x
> StringIndexOf.successBig	                      14.341		46.343		3.231504079x
> StringIndexOfChar.latin1_AVX2_String	  6220.918		12154.52		1.953814533x
> StringIndexOfChar.latin1_AVX2_char	  5503.556		5540.044		1.006629895x
> StringIndexOfChar.latin1_SSE4_String	  6978.854		6818.689		0.977049957x
> StringIndexOfChar.latin1_SSE4_char	  5657.499		5474.624		0.967675646x
> StringIndexOfChar.latin1_Short_String	  7132.541		6863.359		0.962260014x
> StringIndexOfChar.latin1_Short_char	16013.389	      16162.437		1.009307711x
> StringIndexOfChar.latin1_mixed_String	  7386.123	      14771.622		1.999915517x
> StringIndexOfChar.latin1_mixed_char	  9901.671		9782.245		0.987938803

Scott Gibbons has updated the pull request incrementally with one additional commit since the last revision:

  Fix tests

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/16753/files
  - new: https://git.openjdk.org/jdk/pull/16753/files/e13c7ea4..15994a39

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16753&range=42
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16753&range=41-42

  Stats: 2 lines in 2 files changed: 0 ins; 2 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/16753.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16753/head:pull/16753

PR: https://git.openjdk.org/jdk/pull/16753

From syan at openjdk.org  Sun May 26 03:03:26 2024
From: syan at openjdk.org (SendaoYan)
Date: Sun, 26 May 2024 03:03:26 GMT
Subject: RFR: 8332922: Test java/io/IO/IO.java fails when /usr/bin/expect not
 exist
Message-ID: <D1Cl6K47G6JKyEiuE6t_iZDqBPqT2TzeojrjqGa9tlA=.5fcb96a3-9803-41bf-8155-d62a3d9ba0c8@github.com>

Hi all,
  When there is no `/usr/bin/expect` in system, `throw new SkippedException` will not make the jvm exit in `@BeforeAll` junit stage, thus this will cause this testcase run failed. So I make change from `throw new SkippedException` to `System.exit` to avoid this issue. When use `System.exit`, I think we should use `othervm` mode in jtreg.
  Only change the testcase, the risk is low.

Thanks.

-------------

Commit messages:
 - 8332922: Test java/io/IO/IO.java fails when /usr/bin/expect not exist

Changes: https://git.openjdk.org/jdk/pull/19403/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19403&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8332922
  Stats: 4 lines in 1 file changed: 2 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/19403.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19403/head:pull/19403

PR: https://git.openjdk.org/jdk/pull/19403

From liach at openjdk.org  Sun May 26 06:07:07 2024
From: liach at openjdk.org (Chen Liang)
Date: Sun, 26 May 2024 06:07:07 GMT
Subject: RFR: 8327858: Improve spliterator and forEach for single-element
 immutable collections [v3]
In-Reply-To: <7Or8-abveTsvZXbVkS5E93rJdGMyr92Eai04ATdFtcw=.8fb787ad-6418-46e6-9af6-dc7434d442e5@github.com>
References: <UUULUZ6TOYKmKRqBcfSCUIia0twwVYuzxssahpMMFLA=.c0dd040a-9d67-4e8a-97b9-dd6fcb20f298@github.com>
 <7Or8-abveTsvZXbVkS5E93rJdGMyr92Eai04ATdFtcw=.8fb787ad-6418-46e6-9af6-dc7434d442e5@github.com>
Message-ID: <fyk3SZkxR03uPxlAauu8Z3AxxYHEC0TBP0FZOVlxonQ=.e7dc13cd-38e2-4ed3-a4bd-9b64560580e3@github.com>

On Fri, 26 Apr 2024 22:27:21 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Please review this patch that:
>> 1. Implemented `forEach` to optimize for 1 or 2 element collections.
>> 2. Implemented `spliterator` to optimize for a single element.
>> 
>> The default implementations for multiple-element immutable collections are fine as-is, specializing implementation doesn't provide much benefit.
>
> Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 16 commits:
> 
>  - Add test to ensure reproducible iteration order
>  - Merge branch 'master' of https://github.com/openjdk/jdk into feature/imm-coll-stream
>  - Merge branch 'master' of https://github.com/openjdk/jdk into feature/imm-coll-stream
>  - Use the improved form in forEach
>  - Merge branch 'master' of https://github.com/openjdk/jdk into feature/imm-coll-stream
>  - Null checks should probably be in the beginning...
>  - mark implicit null checks
>  - Merge branch 'master' of https://github.com/openjdk/jdk into feature/imm-coll-stream
>  - Copyright year, revert changes for non-few element collections
>  - Merge branch 'master' of https://github.com/openjdk/jdk into feature/imm-coll-stream
>  - ... and 6 more: https://git.openjdk.org/jdk/compare/a920af23...70583024

Keep-alive.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15834#issuecomment-2132078702

From djelinski at openjdk.org  Sun May 26 06:10:05 2024
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Sun, 26 May 2024 06:10:05 GMT
Subject: RFR: 8332922: Test java/io/IO/IO.java fails when /usr/bin/expect
 not exist
In-Reply-To: <D1Cl6K47G6JKyEiuE6t_iZDqBPqT2TzeojrjqGa9tlA=.5fcb96a3-9803-41bf-8155-d62a3d9ba0c8@github.com>
References: <D1Cl6K47G6JKyEiuE6t_iZDqBPqT2TzeojrjqGa9tlA=.5fcb96a3-9803-41bf-8155-d62a3d9ba0c8@github.com>
Message-ID: <QZ6L57GZIMq0MEkfgB-dvnx8aEgE9dSATn2DJZKUIo8=.ffbd31e1-ac42-4897-9184-579c0962eded@github.com>

On Sun, 26 May 2024 02:58:02 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
>   When there is no `/usr/bin/expect` in system, `throw new SkippedException` will not make the jvm exit in `@BeforeAll` junit stage, thus this will cause this testcase run failed. So I make change from `throw new SkippedException` to `System.exit` to avoid this issue. When use `System.exit`, I think we should use `othervm` mode in jtreg.
>   Only change the testcase, the risk is low.
> 
> Thanks.

Changes requested by djelinski (Reviewer).

test/jdk/java/io/IO/IO.java line 64:

> 62:             expect = Paths.get("/usr/bin/expect"); // os-specific path
> 63:             if (!Files.exists(expect) || !Files.isExecutable(expect)) {
> 64:                 System.out.println("jtreg.SkippedException: '" + expect + "' not found");

SkippedException works with jtreg tests only. For jUnit you need to use [Assumptions.abort](https://junit.org/junit5/docs/5.9.1/api/org.junit.jupiter.api/org/junit/jupiter/api/Assumptions.html#abort(java.lang.String))

-------------

PR Review: https://git.openjdk.org/jdk/pull/19403#pullrequestreview-2079411377
PR Review Comment: https://git.openjdk.org/jdk/pull/19403#discussion_r1615031307

From alanb at openjdk.org  Sun May 26 06:19:11 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Sun, 26 May 2024 06:19:11 GMT
Subject: RFR: 8332922: Test java/io/IO/IO.java fails when /usr/bin/expect
 not exist
In-Reply-To: <QZ6L57GZIMq0MEkfgB-dvnx8aEgE9dSATn2DJZKUIo8=.ffbd31e1-ac42-4897-9184-579c0962eded@github.com>
References: <D1Cl6K47G6JKyEiuE6t_iZDqBPqT2TzeojrjqGa9tlA=.5fcb96a3-9803-41bf-8155-d62a3d9ba0c8@github.com>
 <QZ6L57GZIMq0MEkfgB-dvnx8aEgE9dSATn2DJZKUIo8=.ffbd31e1-ac42-4897-9184-579c0962eded@github.com>
Message-ID: <k2v3lOYSZUsUsNxZOXzqnJrrfRZWHpdHeG6eU-6paYA=.7b8f289d-99d8-4c48-bf61-441273c29ba3@github.com>

On Sun, 26 May 2024 06:06:50 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> SkippedException works with jtreg tests only. For jUnit you need to use [Assumptions.abort](https://junit.org/junit5/docs/5.9.1/api/org.junit.jupiter.api/org/junit/jupiter/api/Assumptions.html#abort(java.lang.String))

Yes, the Assumptions API should be used here. We use that in several JUnit tests that skip when tests when they can't run and you want it to fail the test.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19403#discussion_r1615032893

From djelinski at openjdk.org  Sun May 26 06:21:15 2024
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Sun, 26 May 2024 06:21:15 GMT
Subject: RFR: 8320448: Accelerate IndexOf using AVX2 [v33]
In-Reply-To: <AtSz9Pq9tUXRfN6Yf2NWMMh2oq_AJkMqNmSF92foZuw=.1c28d950-dfe9-47a3-b49b-fb9132f3b24d@github.com>
References: <uWi4QxH31hL93771gkl_GgvP0m84IRSoR_1Yi8hD17E=.bc6ed458-7081-4c3f-9348-f59358fa05a4@github.com>
 <kE-TMUMyr6ADsj3wtDB9RlLnXaJFbFzmd7cikzCEuSg=.490d5dd5-eaa8-4137-8e00-7d5de1efb598@github.com>
 <GkGAR2YTtCDe_xFo2a7MxxJyoo-dsgghT9TvqfntN3c=.e40c4157-c48d-4454-b08e-17d6eb9b85a1@github.com>
 <nxpwP6Q_co_mHw7hIyjBjPSjuR6HUc3-ioT80k0tpqE=.fca7f3a5-a511-481c-b630-abeb4402268c@github.com>
 <BfYSarY-tQu34szlCk9qBFTIPR1TlmM5quTXqmoZoGI=.de6da9a2-3ef7-4e1c-8de4-dea5bf134d0f@github.com>
 <Y5yF2Y5MfT6Cz-mhe3qr68Bstkt1ODKOO-4NIh4yeCo=.6675b3fa-12f7-4201-8349-38828242660b@github.com>
 <D8_haA3HGt72E96jB_5XRfRMmtMX8QeeZ7yfXOMklYU=.88d509be-4795-49ce-987b-1d968280237e@github.com>
 <xdDp4nAAOMal3mTMvlUohZm-hKfMWewOFB3LUK1VkUU=.10eaee6e-aee6-4ea5-a6fe-64d5c2f411de@github.com>
 <AtSz9Pq9tUXRfN6Yf2NWMMh2oq_AJkMqNmSF92foZuw=.1c28d950-dfe9-47a3-b49b-fb9132f3b24d@github.com>
Message-ID: <PzODegnBrCu94PZxRqh3BSqt9o2je658xpolZwKdXzw=.5e90b620-285f-4c4d-ab6e-94473b12397e@github.com>

On Fri, 24 May 2024 18:37:13 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> Changed to `lea` with `InternalAddress()`.  Generates the exact same code, but makes more sense.  I looked at `movdqu` and see no code that generates RIP-relative loads.  It merely checks `reachable()` and adds an intermediate `lea` if not reachable.  @djelinski can you clarify please?
>
> I think HotSpot prefer to have full addresses in `lea` for possible patching.

Right. Our assembler implements rip-relative addressing for some instructions, but apparently lea isn't one of them.
I'll experiment with it.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1615033502

From syan at openjdk.org  Sun May 26 07:24:16 2024
From: syan at openjdk.org (SendaoYan)
Date: Sun, 26 May 2024 07:24:16 GMT
Subject: RFR: 8332922: Test java/io/IO/IO.java fails when /usr/bin/expect
 not exist [v2]
In-Reply-To: <D1Cl6K47G6JKyEiuE6t_iZDqBPqT2TzeojrjqGa9tlA=.5fcb96a3-9803-41bf-8155-d62a3d9ba0c8@github.com>
References: <D1Cl6K47G6JKyEiuE6t_iZDqBPqT2TzeojrjqGa9tlA=.5fcb96a3-9803-41bf-8155-d62a3d9ba0c8@github.com>
Message-ID: <lZ7myP-_rzS9Dm_ebKYJ3soi7JPyW2bzjYqPK1dCVQA=.8d26888c-f01a-4ed5-93a1-c36700187203@github.com>

> Hi all,
>   When there is no `/usr/bin/expect` in system, `throw new SkippedException` will not make the jvm exit in `@BeforeAll` junit stage, thus this will cause this testcase run failed. So I make change from `throw new SkippedException` to `System.exit` to avoid this issue. When use `System.exit`, I think we should use `othervm` mode in jtreg.
>   Only change the testcase, the risk is low.
> 
> Thanks.

SendaoYan has updated the pull request incrementally with two additional commits since the last revision:

 - delete "static final int JCK_STATUS_BASE = 95;"
   
   Signed-off-by: sendaoYan <yansendao.ysd at alibaba-inc.com>
 - 8332922: Test java/io/IO/IO.java fails when /usr/bin/expect not exist
   
   Signed-off-by: sendaoYan <yansendao.ysd at alibaba-inc.com>

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19403/files
  - new: https://git.openjdk.org/jdk/pull/19403/files/90fa1e13..57b4dee5

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19403&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19403&range=00-01

  Stats: 5 lines in 1 file changed: 0 ins; 2 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/19403.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19403/head:pull/19403

PR: https://git.openjdk.org/jdk/pull/19403

From syan at openjdk.org  Sun May 26 07:24:17 2024
From: syan at openjdk.org (SendaoYan)
Date: Sun, 26 May 2024 07:24:17 GMT
Subject: RFR: 8332922: Test java/io/IO/IO.java fails when /usr/bin/expect
 not exist [v2]
In-Reply-To: <k2v3lOYSZUsUsNxZOXzqnJrrfRZWHpdHeG6eU-6paYA=.7b8f289d-99d8-4c48-bf61-441273c29ba3@github.com>
References: <D1Cl6K47G6JKyEiuE6t_iZDqBPqT2TzeojrjqGa9tlA=.5fcb96a3-9803-41bf-8155-d62a3d9ba0c8@github.com>
 <QZ6L57GZIMq0MEkfgB-dvnx8aEgE9dSATn2DJZKUIo8=.ffbd31e1-ac42-4897-9184-579c0962eded@github.com>
 <k2v3lOYSZUsUsNxZOXzqnJrrfRZWHpdHeG6eU-6paYA=.7b8f289d-99d8-4c48-bf61-441273c29ba3@github.com>
Message-ID: <Aay9qxGhw3iaeXrXDUGIX1K8EtR1k2RCRrMHcxh6-qo=.e84fd047-1346-48d5-b3b0-84c1cd4f7c93@github.com>

On Sun, 26 May 2024 06:16:44 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> test/jdk/java/io/IO/IO.java line 64:
>> 
>>> 62:             expect = Paths.get("/usr/bin/expect"); // os-specific path
>>> 63:             if (!Files.exists(expect) || !Files.isExecutable(expect)) {
>>> 64:                 System.out.println("jtreg.SkippedException: '" + expect + "' not found");
>> 
>> SkippedException works with jtreg tests only. For jUnit you need to use [Assumptions.abort](https://junit.org/junit5/docs/5.9.1/api/org.junit.jupiter.api/org/junit/jupiter/api/Assumptions.html#abort(java.lang.String))
>
>> SkippedException works with jtreg tests only. For jUnit you need to use [Assumptions.abort](https://junit.org/junit5/docs/5.9.1/api/org.junit.jupiter.api/org/junit/jupiter/api/Assumptions.html#abort(java.lang.String))
> 
> Yes, the Assumptions API should be used here. We use that in several JUnit tests that skip when tests when they can't run and you want it to fail the test.

Thanks for the review and suggest. The code has been updated according the suggest. Thanks.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19403#discussion_r1615075147

From djelinski at openjdk.org  Sun May 26 07:43:03 2024
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Sun, 26 May 2024 07:43:03 GMT
Subject: RFR: 8332922: Test java/io/IO/IO.java fails when /usr/bin/expect
 not exist [v2]
In-Reply-To: <lZ7myP-_rzS9Dm_ebKYJ3soi7JPyW2bzjYqPK1dCVQA=.8d26888c-f01a-4ed5-93a1-c36700187203@github.com>
References: <D1Cl6K47G6JKyEiuE6t_iZDqBPqT2TzeojrjqGa9tlA=.5fcb96a3-9803-41bf-8155-d62a3d9ba0c8@github.com>
 <lZ7myP-_rzS9Dm_ebKYJ3soi7JPyW2bzjYqPK1dCVQA=.8d26888c-f01a-4ed5-93a1-c36700187203@github.com>
Message-ID: <9KuUy1z61W3h-l_xjpEJ081h5kuwCVNE_wPHFQy7L2U=.00e4e053-665e-47b1-83e7-5eb05a4508b4@github.com>

On Sun, 26 May 2024 07:24:16 GMT, SendaoYan <syan at openjdk.org> wrote:

>> Hi all,
>>   When there is no `/usr/bin/expect` in system, `throw new SkippedException` will not make the jvm exit in `@BeforeAll` junit stage, thus this will cause this testcase run failed. So I make change from `throw new SkippedException` to `Assumptions.abort` to avoid this issue.
>>   Only change the testcase, no risk.
>> 
>> Thanks.
>
> SendaoYan has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - delete "static final int JCK_STATUS_BASE = 95;"
>    
>    Signed-off-by: sendaoYan <yansendao.ysd at alibaba-inc.com>
>  - 8332922: Test java/io/IO/IO.java fails when /usr/bin/expect not exist
>    
>    Signed-off-by: sendaoYan <yansendao.ysd at alibaba-inc.com>

LGTM. I assume you verified it does the right thing.

-------------

Marked as reviewed by djelinski (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19403#pullrequestreview-2079496098

From syan at openjdk.org  Sun May 26 08:03:00 2024
From: syan at openjdk.org (SendaoYan)
Date: Sun, 26 May 2024 08:03:00 GMT
Subject: RFR: 8332922: Test java/io/IO/IO.java fails when /usr/bin/expect
 not exist [v2]
In-Reply-To: <9KuUy1z61W3h-l_xjpEJ081h5kuwCVNE_wPHFQy7L2U=.00e4e053-665e-47b1-83e7-5eb05a4508b4@github.com>
References: <D1Cl6K47G6JKyEiuE6t_iZDqBPqT2TzeojrjqGa9tlA=.5fcb96a3-9803-41bf-8155-d62a3d9ba0c8@github.com>
 <lZ7myP-_rzS9Dm_ebKYJ3soi7JPyW2bzjYqPK1dCVQA=.8d26888c-f01a-4ed5-93a1-c36700187203@github.com>
 <9KuUy1z61W3h-l_xjpEJ081h5kuwCVNE_wPHFQy7L2U=.00e4e053-665e-47b1-83e7-5eb05a4508b4@github.com>
Message-ID: <eBSC2aixCuBfjwPC6kBtEvX1Rnac5dKrkS7Ki_4YmNA=.b231f71b-957b-401e-9259-dc157bf1ea47@github.com>

On Sun, 26 May 2024 07:40:38 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> LGTM. I assume you verified it does the right thing.

Thanks for the review and approved. The change has been verified.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19403#issuecomment-2132120584

From duke at openjdk.org  Mon May 27 00:12:04 2024
From: duke at openjdk.org (ExE Boss)
Date: Mon, 27 May 2024 00:12:04 GMT
Subject: RFR: 8242888: Convert dynamic proxy to hidden classes
In-Reply-To: <QO0dIumbbHUFWz43pCWbmsqdH5zG8NaVUB9FwNFlbTw=.8fe20db2-9cfc-46e9-9f98-0979259ac882@github.com>
References: <QO0dIumbbHUFWz43pCWbmsqdH5zG8NaVUB9FwNFlbTw=.8fe20db2-9cfc-46e9-9f98-0979259ac882@github.com>
Message-ID: <frmKNM6V-m2MNi9ZHirgqfLgzKRbfVGc73GMj-l-KYU=.2a9e5223-9b85-499b-b391-f9ba89fd73fe@github.com>

On Thu, 23 May 2024 03:28:30 GMT, Chen Liang <liach at openjdk.org> wrote:

> Please review this change that convert dynamic proxies implementations to hidden classes, intended to target JDK 24.
> 
> Summary:
> 1. Adds new implementation while preserving the old implementation behind `-Djdk.reflect.useLegacyProxyImpl=true` in case there are compatibility issues.
> 2. ClassLoader.defineClass0 takes a ClassLoader instance but discards it in native code; I updated native code to reuse that ClassLoader for Proxy support.
> 3. ProxyGenerator changes mainly involve using Class data to pass Method list (accessed in a single condy) and removal of obsolete setup code generation.
> 
> Testing: tier1 and tier2 have no related failures.
> 
> Comment: Since #8278, Proxy has been converted to ClassFile API, and infrastructure has changed; now, the migration to hidden classes is much cleaner and has less impact, such as preserving ProtectionDomain and dynamic module without "anchor classes", and avoiding java.lang.invoke package.

`useLegacyProxyImpl &&?!useOldSerializableConstructor` would?always be?`false` when `useOldSerializableConstructor` is?`true`, which?is?the?opposite of?what?s?described in?the?CSR.

src/java.base/share/classes/jdk/internal/reflect/ReflectionFactory.java line 557:

> 555:     public static boolean useLegacyProxyImpl() {
> 556:         var config = config();
> 557:         return config.useLegacyProxyImpl && !config.useOldSerializableConstructor;

Suggestion:

        return config.useLegacyProxyImpl || config.useOldSerializableConstructor;

src/java.base/share/classes/jdk/internal/reflect/ReflectionFactory.java line 624:

> 622:             "true".equals(props.getProperty("jdk.disableSerialConstructorChecks"));
> 623: 
> 624:         useLegacyProxyImpl &= !useOldSerializableConstructor;

Suggestion:

        useLegacyProxyImpl |= useOldSerializableConstructor;

-------------

PR Review: https://git.openjdk.org/jdk/pull/19356#pullrequestreview-2079825251
PR Review Comment: https://git.openjdk.org/jdk/pull/19356#discussion_r1615362157
PR Review Comment: https://git.openjdk.org/jdk/pull/19356#discussion_r1615362271

From liach at openjdk.org  Mon May 27 01:25:11 2024
From: liach at openjdk.org (Chen Liang)
Date: Mon, 27 May 2024 01:25:11 GMT
Subject: RFR: 8242888: Convert dynamic proxy to hidden classes
In-Reply-To: <frmKNM6V-m2MNi9ZHirgqfLgzKRbfVGc73GMj-l-KYU=.2a9e5223-9b85-499b-b391-f9ba89fd73fe@github.com>
References: <QO0dIumbbHUFWz43pCWbmsqdH5zG8NaVUB9FwNFlbTw=.8fe20db2-9cfc-46e9-9f98-0979259ac882@github.com>
 <frmKNM6V-m2MNi9ZHirgqfLgzKRbfVGc73GMj-l-KYU=.2a9e5223-9b85-499b-b391-f9ba89fd73fe@github.com>
Message-ID: <7Kf2Il9AOTNK5iJrHGm0ta37FjRE-1MpVHgv14NA8x0=.0440b81c-607b-4df6-a725-6de09b31b30a@github.com>

On Mon, 27 May 2024 00:03:41 GMT, ExE Boss <duke at openjdk.org> wrote:

>> Please review this change that convert dynamic proxies implementations to hidden classes, intended to target JDK 24.
>> 
>> Summary:
>> 1. Adds new implementation while preserving the old implementation behind `-Djdk.reflect.useLegacyProxyImpl=true` in case there are compatibility issues.
>> 2. ClassLoader.defineClass0 takes a ClassLoader instance but discards it in native code; I updated native code to reuse that ClassLoader for Proxy support.
>> 3. ProxyGenerator changes mainly involve using Class data to pass Method list (accessed in a single condy) and removal of obsolete setup code generation.
>> 
>> Testing: tier1 and tier2 have no related failures.
>> 
>> Comment: Since #8278, Proxy has been converted to ClassFile API, and infrastructure has changed; now, the migration to hidden classes is much cleaner and has less impact, such as preserving ProtectionDomain and dynamic module without "anchor classes", and avoiding java.lang.invoke package.
>
> src/java.base/share/classes/jdk/internal/reflect/ReflectionFactory.java line 557:
> 
>> 555:     public static boolean useLegacyProxyImpl() {
>> 556:         var config = config();
>> 557:         return config.useLegacyProxyImpl && !config.useOldSerializableConstructor;
> 
> Suggestion:
> 
>         return config.useLegacyProxyImpl || config.useOldSerializableConstructor;

This site can actually simply be `config.useLegacyProxyImpl` as it's initialized in `loadConfig`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19356#discussion_r1615382817

From syan at openjdk.org  Mon May 27 06:35:05 2024
From: syan at openjdk.org (SendaoYan)
Date: Mon, 27 May 2024 06:35:05 GMT
Subject: Integrated: 8332922: Test java/io/IO/IO.java fails when
 /usr/bin/expect not exist
In-Reply-To: <D1Cl6K47G6JKyEiuE6t_iZDqBPqT2TzeojrjqGa9tlA=.5fcb96a3-9803-41bf-8155-d62a3d9ba0c8@github.com>
References: <D1Cl6K47G6JKyEiuE6t_iZDqBPqT2TzeojrjqGa9tlA=.5fcb96a3-9803-41bf-8155-d62a3d9ba0c8@github.com>
Message-ID: <Qy9uMNmKtlhN6vOXQa1n2AfmdQEFdbOtxcaYBKk-PMc=.2bcbfb0e-1cbe-4b52-a923-985965c23bf2@github.com>

On Sun, 26 May 2024 02:58:02 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
>   When there is no `/usr/bin/expect` in system, `throw new SkippedException` will not make the jvm exit in `@BeforeAll` junit stage, thus this will cause this testcase run failed. So I make change from `throw new SkippedException` to `Assumptions.abort` to avoid this issue.
>   Only change the testcase, no risk.
> 
> Thanks.

This pull request has now been integrated.

Changeset: 4e8deb39
Author:    SendaoYan <syan at openjdk.org>
Committer: Daniel Jeli?ski <djelinski at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/4e8deb396e38c69de22b6348dca637d814d73aef
Stats:     2 lines in 1 file changed: 0 ins; 0 del; 2 mod

8332922: Test java/io/IO/IO.java fails when /usr/bin/expect not exist

Reviewed-by: djelinski

-------------

PR: https://git.openjdk.org/jdk/pull/19403

From mbaesken at openjdk.org  Mon May 27 06:38:12 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Mon, 27 May 2024 06:38:12 GMT
Subject: Integrated: 8332589: ubsan:
 unix/native/libjava/ProcessImpl_md.c:562:5: runtime error: null pointer passed
 as argument 2, which is declared to never be null
In-Reply-To: <AwlmAiTOhqSaoJ2Jh5YYrBpxakc0Pt9lYP9nvcBjXBo=.813efddf-3f87-4bbf-9cc5-cd769eabd2f7@github.com>
References: <AwlmAiTOhqSaoJ2Jh5YYrBpxakc0Pt9lYP9nvcBjXBo=.813efddf-3f87-4bbf-9cc5-cd769eabd2f7@github.com>
Message-ID: <-1iWnvxbyKuXssHEmkGqLPtVWt84ne96I0q3qUzyjvc=.d9caafa6-99c8-412d-b52d-17984538a3e9@github.com>

On Tue, 21 May 2024 14:28:38 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> When building with ubsan enabled (--enable-uban) on Linux x86_64 and doing jtreg tests afterwards I run into this error :
> 
> /jdk/src/java.base/unix/native/libjava/ProcessImpl_md.c:562:5: runtime error: null pointer passed as argument 2, which is declared to never be null
>     #0 0x7fd95bec78d8 in spawnChild /jdk/src/java.base/unix/native/libjava/ProcessImpl_md.c:562
>     #1 0x7fd95bec78d8 in startChild /jdk/src/java.base/unix/native/libjava/ProcessImpl_md.c:612
>     #2 0x7fd95bec78d8 in Java_java_lang_ProcessImpl_forkAndExec /jdk/src/java.base/unix/native/libjava/ProcessImpl_md.c:712
>     #3 0x7fd93797a06d (<unknown module>)
> 
> this is the memcpy call getting an unexpected null pointer :
>     memcpy(buf+offset, c->pdir, sp.dirlen); gets a second parameter null.
> Something similar was discussed and fixed here https://bugs.python.org/issue27570 for Python .
> 
> Similar issue in OpenJDK _ 
> https://bugs.openjdk.org/browse/JDK-8332473
> 8332473: ubsan: growableArray.hpp:290:10: runtime error: null pointer passed as argument 1, which is declared to never be null

This pull request has now been integrated.

Changeset: 16dba04e
Author:    Matthias Baesken <mbaesken at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/16dba04e8dfa871f8056480a42a9baeb24a2fb24
Stats:     12 lines in 1 file changed: 9 ins; 0 del; 3 mod

8332589: ubsan: unix/native/libjava/ProcessImpl_md.c:562:5: runtime error: null pointer passed as argument 2, which is declared to never be null

Reviewed-by: rriggs, mdoerr

-------------

PR: https://git.openjdk.org/jdk/pull/19329

From syan at openjdk.org  Mon May 27 06:49:05 2024
From: syan at openjdk.org (SendaoYan)
Date: Mon, 27 May 2024 06:49:05 GMT
Subject: RFR: 8332922: Test java/io/IO/IO.java fails when /usr/bin/expect
 not exist [v2]
In-Reply-To: <lZ7myP-_rzS9Dm_ebKYJ3soi7JPyW2bzjYqPK1dCVQA=.8d26888c-f01a-4ed5-93a1-c36700187203@github.com>
References: <D1Cl6K47G6JKyEiuE6t_iZDqBPqT2TzeojrjqGa9tlA=.5fcb96a3-9803-41bf-8155-d62a3d9ba0c8@github.com>
 <lZ7myP-_rzS9Dm_ebKYJ3soi7JPyW2bzjYqPK1dCVQA=.8d26888c-f01a-4ed5-93a1-c36700187203@github.com>
Message-ID: <HZ8vE7Gs611c06gnDgm4XDHa1Gosx4v_nMwfgdKB4PA=.393d3d0f-6ac1-474f-9455-735af0d5dae8@github.com>

On Sun, 26 May 2024 07:24:16 GMT, SendaoYan <syan at openjdk.org> wrote:

>> Hi all,
>>   When there is no `/usr/bin/expect` in system, `throw new SkippedException` will not make the jvm exit in `@BeforeAll` junit stage, thus this will cause this testcase run failed. So I make change from `throw new SkippedException` to `Assumptions.abort` to avoid this issue.
>>   Only change the testcase, no risk.
>> 
>> Thanks.
>
> SendaoYan has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - delete "static final int JCK_STATUS_BASE = 95;"
>    
>    Signed-off-by: sendaoYan <yansendao.ysd at alibaba-inc.com>
>  - 8332922: Test java/io/IO/IO.java fails when /usr/bin/expect not exist
>    
>    Signed-off-by: sendaoYan <yansendao.ysd at alibaba-inc.com>

> /sponsor

Thanks.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19403#issuecomment-2132757338

From pminborg at openjdk.org  Mon May 27 07:27:03 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 27 May 2024 07:27:03 GMT
Subject: RFR: 8328821: Map.of().entrySet() mutators should throw
 UnsupportedOperationException
In-Reply-To: <np86XgOjE1gYESY--2_OXTPIvO1mvmJbD3UH-lIn9TY=.c4a288f1-0469-4cc6-a076-58bab04d24ad@github.com>
References: <np86XgOjE1gYESY--2_OXTPIvO1mvmJbD3UH-lIn9TY=.c4a288f1-0469-4cc6-a076-58bab04d24ad@github.com>
Message-ID: <i2k1vxw0WKnzRbVSOnDrDd0JCOuOhkreN68c7yRdJYs=.8616f12f-6515-4d98-9e98-f98b36d914ad@github.com>

On Wed, 27 Mar 2024 17:36:28 GMT, Liam Miller-Cushon <cushon at openjdk.org> wrote:

> This change overrides mutator methods in the implementation returned by `Map.of().entrySet()` to throw `UnsupportedOperationException`.

src/java.base/share/classes/java/util/ImmutableCollections.java line 1323:

> 1321:                 @Override
> 1322:                 public int hashCode() {
> 1323:                     return MapN.this.hashCode();

The hash code for a `Set` is defined as the sum of the elements in the `Set` (hash(`null`) == 0). The `Map. Entry` hash code is defined the same way `MapN.this.hashCode` operates so this seems right. It would be nice with a couple of tests that assert this invariant.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18522#discussion_r1615591889

From asotona at openjdk.org  Mon May 27 09:06:23 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 27 May 2024 09:06:23 GMT
Subject: RFR: 8332457: Examine startup overheads from JDK-8294961
Message-ID: <YdSsOH6RBi4-Xy1ZTpSdTqQprzvhAYIenwxWxvC6GrU=.6961b30c-2d67-49b6-aa3e-b4736be0458b@github.com>

[JDK-8294961](https://bugs.openjdk.org/browse/JDK-8294961) changed to use classfile API for reflection proxy-generation. Actual implementation of `ProxyGenerator` is focused on performance, however it causes JDK bootstrap regressions. `ProxyGenerator.TEMPLATE` class model is statically created and each proxy class is transformed from the template.

This patch is intended to examine plain proxy generation impact on performance and JDK bootstrap (vs proxy transformation from template).

Please review.

Thank you,
Adam

-------------

Commit messages:
 - 8332457: Examine startup overheads from JDK-8294961

Changes: https://git.openjdk.org/jdk/pull/19410/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19410&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8332457
  Stats: 233 lines in 1 file changed: 27 ins; 113 del; 93 mod
  Patch: https://git.openjdk.org/jdk/pull/19410.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19410/head:pull/19410

PR: https://git.openjdk.org/jdk/pull/19410

From lujaniuk at openjdk.org  Mon May 27 09:37:07 2024
From: lujaniuk at openjdk.org (Ludvig Janiuk)
Date: Mon, 27 May 2024 09:37:07 GMT
Subject: RFR: 8332885: Clarify failure_handler self-tests
In-Reply-To: <4WTtBtlrkbn2oagshFrdXjgeIO-Zbp9eob7HkOzOEgU=.01122e2f-61fe-48ee-9db9-eedd9eb4e21c@github.com>
References: <fSl5ksYZ89l98gCGy0q3jfhpoCO5UVBKlA5k7Fxt720=.886e149b-561d-4109-9e72-94346f02f25d@github.com>
 <4WTtBtlrkbn2oagshFrdXjgeIO-Zbp9eob7HkOzOEgU=.01122e2f-61fe-48ee-9db9-eedd9eb4e21c@github.com>
Message-ID: <M9RqNrza8OlzgQwKzmVaFCtqNKOWsnuMR9R2txBGq3k=.1fcf14ec-ee23-4482-b7aa-7ca41d01778f@github.com>

On Fri, 24 May 2024 19:26:29 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> Adding commetns to clarify that the failure_handler selftests are intended to be run manually. Ideally this would include a more thorough description of the exepcted outputs, but this is what I have time to add right now.
>
> test/failure_handler/README line 115:
> 
>> 113: generated artifacts and cannot be run as part of a CI. They are tests which timeout, crash,
>> 114: fail in various ways and you can check the failure_handler output yourself. They might also
>> 115: leave processes running on your machine so be extra careful about cleaning up.
> 
> These lines are longer than the text blocks in the rest of this file. Could you adjust formatting to match?

Sure, thanks for noticing.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19393#discussion_r1615787886

From lujaniuk at openjdk.org  Mon May 27 09:39:09 2024
From: lujaniuk at openjdk.org (Ludvig Janiuk)
Date: Mon, 27 May 2024 09:39:09 GMT
Subject: Integrated: 8332898: failure_handler: log directory of commands
In-Reply-To: <1QX0asjsisoy1ygDzWY1XaespvKbclWKms0Cf_eXqls=.189d31a0-d3ed-41a9-9ca9-8251e4e8edf7@github.com>
References: <1QX0asjsisoy1ygDzWY1XaespvKbclWKms0Cf_eXqls=.189d31a0-d3ed-41a9-9ca9-8251e4e8edf7@github.com>
Message-ID: <aIIMZTVv1htPzDQw8KK0AksVk1xo7vo_98yu2ML5DRI=.16e261c6-ef88-4f57-b304-9d67ec292549@github.com>

On Fri, 24 May 2024 14:34:39 GMT, Ludvig Janiuk <lujaniuk at openjdk.org> wrote:

> Also log the directory in which the command used by failure_handler was executed. While often the same, it isn't always, and so it this should simplify troubleshooting for someone looking at this at a glance without being a failure_handler expert.
> 
> Example output after this change:
> 
> ----------------------------------------
> [2024-05-24 14:26:46] [/usr/bin/pmap, -p, 2233017] timeout=20000 in /<my-absolute-project-dir>/JTwork/scratch
> ----------------------------------------
> 
> before:
> 
> ----------------------------------------
> [2024-05-24 14:26:46] [/usr/bin/pmap, -p, 2233017] timeout=20000
> ----------------------------------------

This pull request has now been integrated.

Changeset: 7f0ad513
Author:    Ludvig Janiuk <lujaniuk at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/7f0ad513c30359816ac840f821ca0a22d723a642
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8332898: failure_handler: log directory of commands

Reviewed-by: lmesnik

-------------

PR: https://git.openjdk.org/jdk/pull/19396

From lujaniuk at openjdk.org  Mon May 27 09:46:31 2024
From: lujaniuk at openjdk.org (Ludvig Janiuk)
Date: Mon, 27 May 2024 09:46:31 GMT
Subject: RFR: 8332885: Clarify failure_handler self-tests [v2]
In-Reply-To: <fSl5ksYZ89l98gCGy0q3jfhpoCO5UVBKlA5k7Fxt720=.886e149b-561d-4109-9e72-94346f02f25d@github.com>
References: <fSl5ksYZ89l98gCGy0q3jfhpoCO5UVBKlA5k7Fxt720=.886e149b-561d-4109-9e72-94346f02f25d@github.com>
Message-ID: <QaIvS_1qwBDvTWHe0EZbHj5ER0yDJuqDKZtXvy0ejDU=.86d2127d-7f98-4c01-8046-7d30922f7a7e@github.com>

> Adding commetns to clarify that the failure_handler selftests are intended to be run manually. Ideally this would include a more thorough description of the exepcted outputs, but this is what I have time to add right now.

Ludvig Janiuk has updated the pull request incrementally with three additional commits since the last revision:

 - styling
 - typo
 - reflow

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19393/files
  - new: https://git.openjdk.org/jdk/pull/19393/files/26a7be5c..a9d2cab2

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19393&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19393&range=00-01

  Stats: 7 lines in 1 file changed: 1 ins; 0 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/19393.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19393/head:pull/19393

PR: https://git.openjdk.org/jdk/pull/19393

From lujaniuk at openjdk.org  Mon May 27 09:46:31 2024
From: lujaniuk at openjdk.org (Ludvig Janiuk)
Date: Mon, 27 May 2024 09:46:31 GMT
Subject: Integrated: 8332885: Clarify failure_handler self-tests
In-Reply-To: <fSl5ksYZ89l98gCGy0q3jfhpoCO5UVBKlA5k7Fxt720=.886e149b-561d-4109-9e72-94346f02f25d@github.com>
References: <fSl5ksYZ89l98gCGy0q3jfhpoCO5UVBKlA5k7Fxt720=.886e149b-561d-4109-9e72-94346f02f25d@github.com>
Message-ID: <KwEeTUw1efQrAKdZhk9RgMgHqmuz6uzLLe4NdlaEOQY=.f3774d99-d6e0-4a5d-89ba-b5a94471952f@github.com>

On Fri, 24 May 2024 12:16:25 GMT, Ludvig Janiuk <lujaniuk at openjdk.org> wrote:

> Adding commetns to clarify that the failure_handler selftests are intended to be run manually. Ideally this would include a more thorough description of the exepcted outputs, but this is what I have time to add right now.

This pull request has now been integrated.

Changeset: 08891553
Author:    Ludvig Janiuk <lujaniuk at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/08891553bbd3d71337d8a94c75051db74e15903f
Stats:     16 lines in 2 files changed: 16 ins; 0 del; 0 mod

8332885: Clarify failure_handler self-tests

Reviewed-by: lmesnik

-------------

PR: https://git.openjdk.org/jdk/pull/19393

From asotona at openjdk.org  Mon May 27 10:37:26 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 27 May 2024 10:37:26 GMT
Subject: RFR: 8332457: Examine startup overheads from JDK-8294961 [v2]
In-Reply-To: <YdSsOH6RBi4-Xy1ZTpSdTqQprzvhAYIenwxWxvC6GrU=.6961b30c-2d67-49b6-aa3e-b4736be0458b@github.com>
References: <YdSsOH6RBi4-Xy1ZTpSdTqQprzvhAYIenwxWxvC6GrU=.6961b30c-2d67-49b6-aa3e-b4736be0458b@github.com>
Message-ID: <0qVYXLdz3W69NmojtYKlywE99KqHphTfrQH9xkXRx30=.c84ce710-5870-4d5b-b37b-42451fc5be33@github.com>

> [JDK-8294961](https://bugs.openjdk.org/browse/JDK-8294961) changed to use classfile API for reflection proxy-generation. Actual implementation of `ProxyGenerator` is focused on performance, however it causes JDK bootstrap regressions. `ProxyGenerator.TEMPLATE` class model is statically created and each proxy class is transformed from the template.
> 
> This patch is intended to examine plain proxy generation impact on performance and JDK bootstrap (vs proxy transformation from template).
> 
> Please review.
> 
> Thank you,
> Adam

Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:

  manual stack maps

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19410/files
  - new: https://git.openjdk.org/jdk/pull/19410/files/246efa11..1d4edea5

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19410&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19410&range=00-01

  Stats: 39 lines in 1 file changed: 18 ins; 0 del; 21 mod
  Patch: https://git.openjdk.org/jdk/pull/19410.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19410/head:pull/19410

PR: https://git.openjdk.org/jdk/pull/19410

From prappo at openjdk.org  Mon May 27 11:27:05 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Mon, 27 May 2024 11:27:05 GMT
Subject: RFR: 8332922: Test java/io/IO/IO.java fails when /usr/bin/expect
 not exist [v2]
In-Reply-To: <lZ7myP-_rzS9Dm_ebKYJ3soi7JPyW2bzjYqPK1dCVQA=.8d26888c-f01a-4ed5-93a1-c36700187203@github.com>
References: <D1Cl6K47G6JKyEiuE6t_iZDqBPqT2TzeojrjqGa9tlA=.5fcb96a3-9803-41bf-8155-d62a3d9ba0c8@github.com>
 <lZ7myP-_rzS9Dm_ebKYJ3soi7JPyW2bzjYqPK1dCVQA=.8d26888c-f01a-4ed5-93a1-c36700187203@github.com>
Message-ID: <m_u2MN_HMF2uh6_cnePIi2SeJ_c957A9Z72WQIh9bLA=.f7bce508-2942-458e-a89b-9b007e8a6431@github.com>

On Sun, 26 May 2024 07:24:16 GMT, SendaoYan <syan at openjdk.org> wrote:

>> Hi all,
>>   When there is no `/usr/bin/expect` in system, `throw new SkippedException` will not make the jvm exit in `@BeforeAll` junit stage, thus this will cause this testcase run failed. So I make change from `throw new SkippedException` to `Assumptions.abort` to avoid this issue.
>>   Only change the testcase, no risk.
>> 
>> Thanks.
>
> SendaoYan has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - delete "static final int JCK_STATUS_BASE = 95;"
>    
>    Signed-off-by: sendaoYan <yansendao.ysd at alibaba-inc.com>
>  - 8332922: Test java/io/IO/IO.java fails when /usr/bin/expect not exist
>    
>    Signed-off-by: sendaoYan <yansendao.ysd at alibaba-inc.com>

Thanks for fixing that. I can see that `Assumptions.abort` is a rather new addition: since 5.9. What was the correct way to abort a test in these circumstances prior to that method?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19403#issuecomment-2133269802

From asotona at openjdk.org  Mon May 27 11:47:15 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 27 May 2024 11:47:15 GMT
Subject: RFR: 8332457: Examine startup overheads from JDK-8294961 [v3]
In-Reply-To: <YdSsOH6RBi4-Xy1ZTpSdTqQprzvhAYIenwxWxvC6GrU=.6961b30c-2d67-49b6-aa3e-b4736be0458b@github.com>
References: <YdSsOH6RBi4-Xy1ZTpSdTqQprzvhAYIenwxWxvC6GrU=.6961b30c-2d67-49b6-aa3e-b4736be0458b@github.com>
Message-ID: <bLw0t5oT2Poi6g22CvAN2s3p4uQHyDa9GKYpBQ89DbQ=.649d7b2b-8389-44d4-bd32-3e5119566206@github.com>

> [JDK-8294961](https://bugs.openjdk.org/browse/JDK-8294961) changed to use classfile API for reflection proxy-generation. Actual implementation of `ProxyGenerator` is focused on performance, however it causes JDK bootstrap regressions. `ProxyGenerator.TEMPLATE` class model is statically created and each proxy class is transformed from the template.
> 
> This patch is intended to examine plain proxy generation impact on performance and JDK bootstrap (vs proxy transformation from template).
> 
> Please review.
> 
> Thank you,
> Adam

Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:

  performance improvements

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19410/files
  - new: https://git.openjdk.org/jdk/pull/19410/files/1d4edea5..29ca6a4e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19410&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19410&range=01-02

  Stats: 77 lines in 2 files changed: 39 ins; 9 del; 29 mod
  Patch: https://git.openjdk.org/jdk/pull/19410.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19410/head:pull/19410

PR: https://git.openjdk.org/jdk/pull/19410

From djelinski at openjdk.org  Mon May 27 11:54:06 2024
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Mon, 27 May 2024 11:54:06 GMT
Subject: RFR: 8332922: Test java/io/IO/IO.java fails when /usr/bin/expect
 not exist [v2]
In-Reply-To: <lZ7myP-_rzS9Dm_ebKYJ3soi7JPyW2bzjYqPK1dCVQA=.8d26888c-f01a-4ed5-93a1-c36700187203@github.com>
References: <D1Cl6K47G6JKyEiuE6t_iZDqBPqT2TzeojrjqGa9tlA=.5fcb96a3-9803-41bf-8155-d62a3d9ba0c8@github.com>
 <lZ7myP-_rzS9Dm_ebKYJ3soi7JPyW2bzjYqPK1dCVQA=.8d26888c-f01a-4ed5-93a1-c36700187203@github.com>
Message-ID: <XRYvdf4NXhjYTCQmZ85GTNeFZ1rwPnJO7s6vCDmGuds=.d81f7350-e01b-4730-8856-cd47e05e74b9@github.com>

On Sun, 26 May 2024 07:24:16 GMT, SendaoYan <syan at openjdk.org> wrote:

>> Hi all,
>>   When there is no `/usr/bin/expect` in system, `throw new SkippedException` will not make the jvm exit in `@BeforeAll` junit stage, thus this will cause this testcase run failed. So I make change from `throw new SkippedException` to `Assumptions.abort` to avoid this issue.
>>   Only change the testcase, no risk.
>> 
>> Thanks.
>
> SendaoYan has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - delete "static final int JCK_STATUS_BASE = 95;"
>    
>    Signed-off-by: sendaoYan <yansendao.ysd at alibaba-inc.com>
>  - 8332922: Test java/io/IO/IO.java fails when /usr/bin/expect not exist
>    
>    Signed-off-by: sendaoYan <yansendao.ysd at alibaba-inc.com>

Check the other methods on the Assumptions class, they are older than this.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19403#issuecomment-2133314171

From nbenalla at openjdk.org  Mon May 27 12:04:20 2024
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Mon, 27 May 2024 12:04:20 GMT
Subject: RFR: 8331051: Add an `@since` checker test for `java.base` module
 [v8]
In-Reply-To: <NRZmbFYvDwXPuizcmCilJx5Yb6HjZ-2fJa-YILxYUl8=.a79f79e4-77d5-4910-b3df-5e78bb7e402b@github.com>
References: <NRZmbFYvDwXPuizcmCilJx5Yb6HjZ-2fJa-YILxYUl8=.a79f79e4-77d5-4910-b3df-5e78bb7e402b@github.com>
Message-ID: <Sl-YxaDHlRxKaXgli2T63-tOgWUfW-1Skj-w533G3_M=.12340b80-6ddc-4bae-8ea0-e1f525376e39@github.com>

> This checker checks the values of the `@since` tag found in the documentation comment for an element against the release in which the element first appeared.
> 
> Real since value of an API element is computed as the oldest release in which the given API element was introduced. That is:
> - for modules, classes and interfaces, the release in which the element with the given qualified name was introduced
> - for constructors, the release in which the constructor with the given VM descriptor was introduced
> - for methods and fields, the release in which the given method or field with the given VM descriptor became a member of its enclosing class or interface, whether direct or inherited
> 
> Effective since value of an API element is computed as follows:
> - if the given element has a `@since` tag in its javadoc, it is used
> - in all other cases, return the effective since value of the enclosing element
> 
> The since checker verifies that for every API element, the real since value and the effective since value are the same, and reports an error if they are not.
> 
> Preview method are handled as per JEP 12, if `@PreviewFeature` is used consistently going forward then the checker doesn't need to be updated with every release. The checker has explicit knowledge of preview elements that came before `JDK 14` because they weren't marked in a machine understandable way and preview elements that came before `JDK 17` that didn't have `@PreviewFeature`.
> 
> Important note : We only check code written since `JDK 9` as the releases used to determine the expected value of `@since` tags are taken from the historical data built into `javac` which only goes back that far
> 
> The intial comment at the beginning of `SinceChecker.java` holds more information into the program.
> 
> I already have filed issues and fixed some wrong tags like in #18640, #18032, #18030, #18055, #18373, #18954, #18972.

Nizar Benalla has updated the pull request incrementally with one additional commit since the last revision:

  - removed unused parameter `i`
  - make rest of methods private
  - ".toString" instead of "toString"
  
  Signed-off-by: Nizar Benalla <nizar.benalla at oracle.com>

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/18934/files
  - new: https://git.openjdk.org/jdk/pull/18934/files/fc10107a..85b2d1a5

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18934&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18934&range=06-07

  Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/18934.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18934/head:pull/18934

PR: https://git.openjdk.org/jdk/pull/18934

From liach at openjdk.org  Mon May 27 12:21:03 2024
From: liach at openjdk.org (Chen Liang)
Date: Mon, 27 May 2024 12:21:03 GMT
Subject: RFR: 8328821: Map.of().entrySet() mutators should throw
 UnsupportedOperationException
In-Reply-To: <i2k1vxw0WKnzRbVSOnDrDd0JCOuOhkreN68c7yRdJYs=.8616f12f-6515-4d98-9e98-f98b36d914ad@github.com>
References: <np86XgOjE1gYESY--2_OXTPIvO1mvmJbD3UH-lIn9TY=.c4a288f1-0469-4cc6-a076-58bab04d24ad@github.com>
 <i2k1vxw0WKnzRbVSOnDrDd0JCOuOhkreN68c7yRdJYs=.8616f12f-6515-4d98-9e98-f98b36d914ad@github.com>
Message-ID: <UHVWvGcW9Gog04O9WNhwTfZx_jFdhtDrLmkzVOxXXks=.5f84615e-5890-4a51-baed-a1fe02a89b5b@github.com>

On Mon, 27 May 2024 07:24:47 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This change overrides mutator methods in the implementation returned by `Map.of().entrySet()` to throw `UnsupportedOperationException`.
>
> src/java.base/share/classes/java/util/ImmutableCollections.java line 1323:
> 
>> 1321:                 @Override
>> 1322:                 public int hashCode() {
>> 1323:                     return MapN.this.hashCode();
> 
> The hash code for a `Set` is defined as the sum of the elements in the `Set` (hash(`null`) == 0). The `Map. Entry` hash code is defined the same way `MapN.this.hashCode` operates so this seems right. It would be nice with a couple of tests that assert this invariant.
> 
> Perhaps the existing tests already cover this?

Good point, this is currently missing from MOAT in Collections.

Though it can be as simple as one line here:
https://github.com/openjdk/jdk/blob/891d5aedf12e837c9a9c7cb800fb3affa7430f00/test/jdk/java/util/Collection/MOAT.java#L1329

check(m.hashCode() == m.entrySet().hashCode());

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18522#discussion_r1615976036

From sgehwolf at openjdk.org  Mon May 27 12:28:22 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Mon, 27 May 2024 12:28:22 GMT
Subject: RFR: 8311302: Allow for jlinking a custom runtime without packaged
 modules being present [v23]
In-Reply-To: <e9Obu0f3PmWjFQZM0FzOw854j_iEfatxY4Cjpc70veE=.834d3df3-2758-4b48-a505-92ea59ecb017@github.com>
References: <Z0DJ87uKPbjS6mvJIE_oG5m-RWsbERXsytSgV8Bmhdo=.f8723513-0ac6-4e85-9131-3c3924860c61@github.com>
 <Xkl8CJMCXm7iBI2ZnfH9JnoZx08wd5InSwIZHW_kMeQ=.49022322-cb0d-4f1a-947a-6eb37b7da963@github.com>
 <fvDpjxyhqnpaEhF6KhMIJBv_sG87AsuC0axsJYo1Tvw=.442f5a11-44f0-4a00-812a-2c26ec15e8e6@github.com>
 <_sbNFJXG7ghwsfNfxaGvvoDQ7-UtWpnhGnygKsFTsgQ=.623700db-7306-4b34-9e05-ca9059797e39@github.com>
 <DpJV4x9Mnw0upmd3SR_ES2ytuLAo7PsI-ecHERPAOcY=.0a0c2f26-7a9f-4be6-8e71-0494d4673fe7@github.com>
 <jVDOxyjqQW4VQy-JvAzdBe1IN2U1oqWsSvFZ1I3psUg=.c1d71ba8-f5b8-4dd8-bad0-369ecb166966@github.com>
 <0p024fM1f37tPV49K78xyyJ01uEUh5I1XcsXoJBK0_Q=.4c2e6cc4-71d0-4d6f-a3a3-13bba0ab2a84@github.com>
 <e9Obu0f3PmWjFQZM0FzOw854j_iEfatxY4Cjpc70veE=.834d3df3-2758-4b48-a505-92ea59ecb017@github.com>
Message-ID: <kOsD-ATBEA1xH7tAo-YmsYcmj1lsn2nar2up4WnZkX8=.21b6c70b-c37c-4fa9-a5a7-7eba000352fd@github.com>

On Thu, 23 May 2024 18:52:53 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> Yes, I want to help you get this one over the line.

Thanks! Appreciate that.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14787#issuecomment-2133375454

From asotona at openjdk.org  Mon May 27 12:29:26 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 27 May 2024 12:29:26 GMT
Subject: RFR: 8332457: Examine startup overheads from JDK-8294961 [v4]
In-Reply-To: <YdSsOH6RBi4-Xy1ZTpSdTqQprzvhAYIenwxWxvC6GrU=.6961b30c-2d67-49b6-aa3e-b4736be0458b@github.com>
References: <YdSsOH6RBi4-Xy1ZTpSdTqQprzvhAYIenwxWxvC6GrU=.6961b30c-2d67-49b6-aa3e-b4736be0458b@github.com>
Message-ID: <X9R-tIaXqeJgKu4498gaZF_qdfFbeBuc1ewP_Sc7JAk=.558b218d-5d0a-4ecf-9cce-d53a35af9c37@github.com>

> [JDK-8294961](https://bugs.openjdk.org/browse/JDK-8294961) changed to use classfile API for reflection proxy-generation. Actual implementation of `ProxyGenerator` is focused on performance, however it causes JDK bootstrap regressions. `ProxyGenerator.TEMPLATE` class model is statically created and each proxy class is transformed from the template.
> 
> This patch is intended to examine plain proxy generation impact on performance and JDK bootstrap (vs proxy transformation from template).
> 
> Please review.
> 
> Thank you,
> Adam

Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:

  more improvements

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19410/files
  - new: https://git.openjdk.org/jdk/pull/19410/files/29ca6a4e..eaf30201

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19410&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19410&range=02-03

  Stats: 14 lines in 1 file changed: 3 ins; 0 del; 11 mod
  Patch: https://git.openjdk.org/jdk/pull/19410.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19410/head:pull/19410

PR: https://git.openjdk.org/jdk/pull/19410

From liach at openjdk.org  Mon May 27 12:29:26 2024
From: liach at openjdk.org (Chen Liang)
Date: Mon, 27 May 2024 12:29:26 GMT
Subject: RFR: 8332457: Examine startup overheads from JDK-8294961 [v3]
In-Reply-To: <bLw0t5oT2Poi6g22CvAN2s3p4uQHyDa9GKYpBQ89DbQ=.649d7b2b-8389-44d4-bd32-3e5119566206@github.com>
References: <YdSsOH6RBi4-Xy1ZTpSdTqQprzvhAYIenwxWxvC6GrU=.6961b30c-2d67-49b6-aa3e-b4736be0458b@github.com>
 <bLw0t5oT2Poi6g22CvAN2s3p4uQHyDa9GKYpBQ89DbQ=.649d7b2b-8389-44d4-bd32-3e5119566206@github.com>
Message-ID: <AZiGAwtgnXbZ_b2VkBaRz_-VwvcQXP8tybroNYUS308=.b542b24e-a7f7-41a1-b65e-f7d042522df0@github.com>

On Mon, 27 May 2024 11:47:15 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> [JDK-8294961](https://bugs.openjdk.org/browse/JDK-8294961) changed to use classfile API for reflection proxy-generation. Actual implementation of `ProxyGenerator` is focused on performance, however it causes JDK bootstrap regressions. `ProxyGenerator.TEMPLATE` class model is statically created and each proxy class is transformed from the template.
>> 
>> This patch is intended to examine plain proxy generation impact on performance and JDK bootstrap (vs proxy transformation from template).
>> 
>> Please review.
>> 
>> Thank you,
>> Adam
>
> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
> 
>   performance improvements

src/java.base/share/classes/java/lang/reflect/ProxyGenerator.java line 76:

> 74: 
> 75:     private static final MethodTypeDesc
> 76:             MTD_boolean = MethodTypeDescImpl.ofValidated(CD_boolean, ConstantUtils.EMPTY_CLASSDESC),

Maybe we can change the `MethodTypeDescImpl.ofValidated` to varargs so we don't need explicit array initializations.

src/java.base/share/classes/java/lang/reflect/ProxyGenerator.java line 822:

> 820:                .iconst_0() // false
> 821:                .aload(0)// classLoader
> 822:                .invokestatic(CD_Class, "forName", MTD_Class_String_boolean_ClassLoader);

We can probably replace this `forName(name, false, thisClassLoader)` with loading a class constant to reduce load on symbols.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19410#discussion_r1615978269
PR Review Comment: https://git.openjdk.org/jdk/pull/19410#discussion_r1615982718

From amansha at kth.se  Mon May 27 12:31:43 2024
From: amansha at kth.se (Aman Sharma)
Date: Mon, 27 May 2024 12:31:43 +0000
Subject: Deterministic naming of subclasses of `java/lang/reflect/Proxy`
In-Reply-To: <CABe8uE2M4mY-dmOaCVuJr0X-xC8vvrKx_FFv3eo8YqpBH=YM+Q@mail.gmail.com>
References: <bf26eb2f74874e02876b3868311922a9@kth.se>
 <CABe8uE0fk71Xy_PYHikSw9OtXE_i+M9zMbayPEXuTxLWLoy2ag@mail.gmail.com>
 <50405ca9c0a64372bace175b932f9ef7@kth.se>
 <61fbe3d9-9536-4113-adde-6cfc671ba1ee@oracle.com>
 <a860be44e06243799593aa8d67c048cd@kth.se>
 <CABe8uE115=DzYCdnvNazqFuuxtJoZnv9wRUkFA4-PS7g41QLMw@mail.gmail.com>
 <DB7PR02MB35938DCC3A392536B924164AFBEE2@DB7PR02MB3593.eurprd02.prod.outlook.com>
 <a0330ee0-5f45-4ef2-8500-e5fcdb696c52@oracle.com>
 <b214cc1a13fe4885a437e16b420e5483@kth.se>
 <ac2ebe5c-db49-4a2d-a5cd-10440a77aa16@oracle.com>
 <580b3aacd8df48fcaae3399718e229ab@kth.se>
 <CABe8uE065Q3+0yNjtyDF-eJM4LN-MbY9kfC44CnSQ-KM4p862g@mail.gmail.com>
 <b64077d6cf0045e98b630cf888785182@kth.se>
 <eabfa5ae508e4257bd0c9bbef244637f@kth.se>
 <CABe8uE13qRX7pRXJOdhUF0sUwF5WkxTAM517tSTOi1r2Q7ivOg@mail.gmail.com>
 <fb6a2cb13c2449acac32fdfb781b0ce0@kth.se>,
 <CABe8uE2M4mY-dmOaCVuJr0X-xC8vvrKx_FFv3eo8YqpBH=YM+Q@mail.gmail.com>
Message-ID: <05576e3cfb004fe980dd18b470f79291@kth.se>

Hi Chen,


> Did you reorder the field in picocli.CommandLine$Command?


No. I did not touch the bytecode. The attached bytecode are taken from the `classfileBuffer` parameter of java.lang.instrument.ClassFileTransformer. As you can see, they are exactly equal.


Regards,
Aman Sharma

PhD Student
KTH Royal Institute of Technology
School of Electrical Engineering and Computer Science (EECS)
Department of Theoretical Computer Science (TCS)
<http://www.kth.se><https://www.kth.se/profile/amansha><https://www.kth.se/profile/amansha>
<https://www.kth.se/profile/amansha>https://algomaster99.github.io/
________________________________
From: Chen Liang <liangchenblue at gmail.com>
Sent: Saturday, May 25, 2024 11:28:01 PM
To: Aman Sharma
Cc: core-libs-dev at openjdk.org
Subject: Re: Deterministic naming of subclasses of `java/lang/reflect/Proxy`

Did you reorder the field in picocli.CommandLine$Command?
In class 13 the usageHelpWidth was preceded by versionProvider, in class 9 it's preceded by requiredOptionMarker. It would also be helpful if you can provide the bytecode for Command class, as it might be due to method ordering in reflection from multiple inheritance (if Command extends multiple interfaces), as you see some subsections of the methods (such as from requiredOptionMarker to said footerHeading) are ordered.

Chen

On Sat, May 25, 2024 at 4:03?PM Aman Sharma <amansha at kth.se<mailto:amansha at kth.se>> wrote:

Hi Chen,

I am attaching proxy classes generated in the JVM of OpenJDK 22. I, instead of decompiling, I disassembled them and I do see a difference. For example, see method `footerHeading` in both classes. In $Proxy9, it is mapped to `m39` field and in $Proxy13, it is mapped to `m21` field. What is the reason for this ordering? Why is mapping of methods to fields depend upon the execution?


Regards,
Aman Sharma

PhD Student
KTH Royal Institute of Technology
School of Electrical Engineering and Computer Science (EECS)
Department of Theoretical Computer Science (TCS)
<https://www.kth.se/profile/amansha>https://algomaster99.github.io/
________________________________
From: Chen Liang <liangchenblue at gmail.com<mailto:liangchenblue at gmail.com>>
Sent: Wednesday, May 22, 2024 9:37:16 PM
To: Aman Sharma
Cc: core-libs-dev at openjdk.org<mailto:core-libs-dev at openjdk.org>; leyden-dev at openjdk.org<mailto:leyden-dev at openjdk.org>
Subject: Re: Deterministic naming of subclasses of `java/lang/reflect/Proxy`

Hi Aman,
Even though the specification says "not in any particular order," the getInterfaces and getMethods actually return an ordered array, in the order these methods/interfaces are declared in their class files.

I believe you are decompiling the proxy classes generated by an older version of the JDK; for example, back in JDK 8, the proxy methods were not ordered because they were tracked in a HashMap: https://github.com/openjdk/jdk8u/blob/6b53212ef78ad50f9eede829c5ff87cadcdb434b/jdk/src/share/classes/sun/misc/ProxyGenerator.java#L405
Which is no longer the case: https://github.com/openjdk/jdk/blob/d59c12fe1041a1f61f68408241a9aa4d96ac4fd2/src/java.base/share/classes/java/lang/reflect/ProxyGenerator.java#L241

- Chen

On Wed, May 22, 2024 at 1:19?PM Aman Sharma <amansha at kth.se<mailto:amansha at kth.se>> wrote:

Hi,


Another thing I wanted to look into in this thread was the order of fields in the Proxy classes generated. They are also based on the a number. The same proxy classes across different executions can have random order of `Method` fields and the methods could be mapped to different field names.


For example, consider the proxy class based on `picocli.CommandLine<https://github.com/remkop/picocli/blob/da98db63d1b516141b7485881b0dcddfd082dbc8/src/main/java/picocli/CommandLine.java#L4541>` in two different executions.

// fields and method are truncated for brevity
public final class $Proxy9 extends Proxy implements CommandLine.Command {
    private static Method m1;
    private static Method m32;
    private static Method m21;
    private static Method m43;
    private static Method m36;
    private static Method m27;

    public final boolean helpCommand() throws  {
        try {
            return (Boolean)super.h.invoke(this, m32, (Object[])null);
        } catch (RuntimeException | Error var2) {
            throw var2;
        } catch (Throwable var3) {
            throw new UndeclaredThrowableException(var3);
        }
     }

// fields and method are truncated for brevity
public final class $Proxy13 extends Proxy implements CommandLine.Command {
    private static Method m1;
    private static Method m29;
    private static Method m16;
    private static Method m40;
    private static Method m38;
    private static Method m12;

    public final boolean helpCommand() throws  {
        try {
            return (Boolean)super.h.invoke(this, m29, (Object[])null);
        } catch (RuntimeException | Error var2) {
            throw var2;
        } catch (Throwable var3) {
            throw new UndeclaredThrowableException(var3);
        }
    }


Notice the difference in the order of fields and `helpCommand` method is mapped to a different field name in both classes. This happens because the method array returned by `getMethods` is not sorted in any particular order<https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/lang/Class.java#L2178> when generating a proxy class. What dictates this order? And why is it not deterministic?


Regards,
Aman Sharma

PhD Student
KTH Royal Institute of Technology
School of Electrical Engineering and Computer Science (EECS)
Department of Theoretical Computer Science (TCS)
<http://www.kth.se><https://www.kth.se/profile/amansha><https://www.kth.se/profile/amansha>
<https://www.kth.se/profile/amansha>https://algomaster99.github.io/
________________________________
From: Aman Sharma
Sent: Wednesday, May 22, 2024 4:12:19 PM
To: Chen Liang
Cc: David Holmes; core-libs-dev at openjdk.org<mailto:core-libs-dev at openjdk.org>; leyden-dev at openjdk.org<mailto:leyden-dev at openjdk.org>
Subject: Re: Deterministic naming of subclasses of `java/lang/reflect/Proxy`


Hi Chen,


That's clear. Thanks for letting me know. I guess then Project Leyden is working on naming the hidden classes deterministically to achieve their goals<https://openjdk.org/projects/leyden/notes/01-beginnings>.


Regards,
Aman Sharma

PhD Student
KTH Royal Institute of Technology
School of Electrical Engineering and Computer Science (EECS)
Department of Theoretical Computer Science (TCS)
<http://www.kth.se><https://www.kth.se/profile/amansha><https://www.kth.se/profile/amansha>
<https://www.kth.se/profile/amansha>https://algomaster99.github.io/
________________________________
From: Chen Liang <liangchenblue at gmail.com<mailto:liangchenblue at gmail.com>>
Sent: Wednesday, May 22, 2024 1:35:46 PM
To: Aman Sharma
Cc: David Holmes; core-libs-dev at openjdk.org<mailto:core-libs-dev at openjdk.org>; leyden-dev at openjdk.org<mailto:leyden-dev at openjdk.org>
Subject: Re: Deterministic naming of subclasses of `java/lang/reflect/Proxy`

Hi Aman,
We have tried defining Proxy as hidden classes; a previous attempt was on hold because of issues with serialization. Otherwise, Proxies work great as hidden classes.

Chen

On Mon, May 20, 2024 at 7:56?AM Aman Sharma <amansha at kth.se<mailto:amansha at kth.se>> wrote:

Hi David,


> I would not expect any class load
events.


I understand. I also haven't tried to intercept them but I see only one approach right now to include them in an allowlist - 1) statically look for invocations of "Lookup::defineHiddenClass". 2) Instrument them so that its first argument "bytes" can be looked into upon. I haven't looked into it much because I did not have much idea about it. And they are hidden so it made it worse. ? Thanks for sharing the JEP!


>

java.lang.reflect.Proxy could define hidden classes to act as the proxy classes which implement proxy interfaces; from JEP 317


It says that Proxy classes will also become hidden classes. Is it underway? Right now one can intercept, transform them, and include them in an allowlist. What do you think of naming them independent of AtomicLong so that a proxy class generated at runtime is easy to lookup in the allowlist?



Regards,
Aman Sharma

PhD Student
KTH Royal Institute of Technology
School of Electrical Engineering and Computer Science (EECS)
Department of Theoretical Computer Science (TCS)
<http://www.kth.se><https://www.kth.se/profile/amansha><https://www.kth.se/profile/amansha>
<https://www.kth.se/profile/amansha>https://algomaster99.github.io/
________________________________
From: David Holmes <david.holmes at oracle.com<mailto:david.holmes at oracle.com>>
Sent: Monday, May 20, 2024 2:30:37 PM
To: Aman Sharma; liangchenblue at gmail.com<mailto:liangchenblue at gmail.com>
Cc: core-libs-dev at openjdk.org<mailto:core-libs-dev at openjdk.org>; leyden-dev at openjdk.org<mailto:leyden-dev at openjdk.org>
Subject: Re: Deterministic naming of subclasses of `java/lang/reflect/Proxy`

On 20/05/2024 10:12 pm, Aman Sharma wrote:
> Hi David,
>
>
>  > How did you try to intercept them? Hidden classes are not "loaded" in
> the normal sense so won't trigger class load events.
>
>
> I could not intercept them. I only see them when I pass `-verbose:class`
> in the Java CLI.

Yes that is why I asked how you tried to intercept them.

>
> I also couldn't intercept them using JVMTI Class File Load Hook
> <https://docs.oracle.com/en/java/javase/21/docs/specs/jvmti.html#ClassFileLoadHook> event. However JEP 371 suggests that it should be possible to intercept them using JVMTI Class Load <https://docs.oracle.com/en/java/javase/21/docs/specs/jvmti.html#ClassLoad> event, but I won't have the bytecode at this stage. So is there no way to get its bytecode before it is linked and initialized in the JVM?

Hidden classes are not loaded so I would not expect any class load
events. However the exact nature of the JVMTI class load event is
unclear as it talks about "class or interface creation" which is neither
loading or defining per se. But a class prepare event sounds like it
should be issued. However neither give you access to the bytecode of the
class AFAICS.

David
-----


>
> Regards,
> Aman Sharma
>
> PhD Student
> KTH Royal Institute of Technology
> School of Electrical Engineering and Computer Science (EECS)
> Department of Theoretical Computer Science (TCS)
> <http://www.kth.se><https://www.kth.se/profile/amansha><https://www.kth.se/profile/amansha>
> <https://www.kth.se/profile/amansha>https://algomaster99.github.io/
> <https://algomaster99.github.io/>
> ------------------------------------------------------------------------
> *From:* David Holmes <david.holmes at oracle.com<mailto:david.holmes at oracle.com>>
> *Sent:* Monday, May 20, 2024 2:59:17 AM
> *To:* Aman Sharma; liangchenblue at gmail.com<mailto:liangchenblue at gmail.com>
> *Cc:* core-libs-dev at openjdk.org<mailto:core-libs-dev at openjdk.org>; leyden-dev at openjdk.org<mailto:leyden-dev at openjdk.org>
> *Subject:* Re: Deterministic naming of subclasses of
> `java/lang/reflect/Proxy`
> On 17/05/2024 9:43 pm, Aman Sharma wrote:
>> Hi Chen,
>>
>>  > java.lang.invoke.LambdaForm$MH/0x00000200cc000400
>>
>> I do see this as output when I pass -verbose:class. However, based on my
>> experiments, I have seen that neither an agent passed via 'javaagent'
>> nor an agent passed via 'agentpath' is able to intercept this hidden class.
>
> How did you try to intercept them? Hidden classes are not "loaded" in
> the normal sense so won't trigger class load events.
>
>> Also, I was a bit confused since I saw somewhere that the names of
>> hidden classes are null. But thanks for clarifying here.
>
> The JEP clearly defines the name format for hidden classes - though the
> final component is VM specific (and typically a hashcode).
>
> https://openjdk.org/jeps/371 <https://openjdk.org/jeps/371>
>
> Cheers,
> David
> -----
>
>>  > avoid dynamic class loading
>>
>> I don't see dynamic class loading as a problem. I only mind some
>> unstable generation aspects of them which make it hard to verify them
>> based on an allowlist.
>>
>> For example, if this hidden class is generated with the exact same name
>> and the exact same bytecode during runtime as well, it would be easy to
>> verify it. However, I do see the names are based on some sort of memory
>> address so and I don't know what bytecode it has so I don't have
>> suggestions to make them stable as of now. For Proxy classes, I feel it
>> can be addressed unless you disagree or some involved in Project Leyden
>> does. :) Thank you for forwarding my mail there.
>>
>> Regards,
>> Aman Sharma
>>
>> PhD Student
>> KTH Royal Institute of Technology
>> https://algomaster99.github.io/ <https://algomaster99.github.io/>
> <https://algomaster99.github.io/ <https://algomaster99.github.io/>>
>>
>> ------------------------------------------------------------------------
>> *From:* liangchenblue at gmail.com<mailto:liangchenblue at gmail.com> <liangchenblue at gmail.com<mailto:liangchenblue at gmail.com>>
>> *Sent:* Friday, May 17, 2024 1:23:58 pm
>> *To:* Aman Sharma <amansha at kth.se<mailto:amansha at kth.se>>
>> *Cc:* core-libs-dev at openjdk.org<mailto:core-libs-dev at openjdk.org> <core-libs-dev at openjdk.org<mailto:core-libs-dev at openjdk.org>>;
>> leyden-dev at openjdk.org<mailto:leyden-dev at openjdk.org> <leyden-dev at openjdk.org<mailto:leyden-dev at openjdk.org>>
>> *Subject:* Re: Deterministic naming of subclasses of
>> `java/lang/reflect/Proxy`
>>
>> Hi Aman,
>> For `-verbose:class`, it's a JVM argument instead of a program argument;
>> so when you run a java program like `java Main`, you should call it as
>> `java -verbose:class Main`.
>> When done correctly, you should see hidden class outputs like:
>> [0.032s][info][class,load]
>> java.lang.invoke.LambdaForm$MH/0x00000200cc000400 source:
>> __JVM_LookupDefineClass__
>> The loading of java.lang.invoke hidden classes requires your program to
>> use MethodHandle features, like a lambda.
>>
>> I think the problem you are exploring, that to avoid dynamic class
>> loading and effectively turn Java Platform closed for security, is also
>> being accomplished by project Leyden (as I've shared initially); Thus, I
>> am forwarding this to leyden-dev instead, so you can see what approach
>> Leyden uses to accomplish the same goal as yours.
>>
>> Regards, Chen Liang
>>
>> On Fri, May 17, 2024 at 4:40?AM Aman Sharma <amansha at kth.se<mailto:amansha at kth.se>
>> <mailto:amansha at kth.se<mailto:amansha at kth.se> <mailto:amansha at kth.se>>> wrote:
>>
>>     __
>>
>>     Hi Roger,
>>
>>
>>     Do you have ideas on how to intercept them? My javaagent is not able
>>     to nor a JVMTI agent passed using `agentpath` option. It also does
>>     not seem to show up in logs when I pass `-verbose:class`.
>>
>>
>>     Also, what do you think of renaming the proxy classes as suggested
>>     below?
>>
>>
>>     Regards,
>>     Aman Sharma
>>
>>     PhD Student
>>     KTH Royal Institute of Technology
>>     School of Electrical Engineering and Computer Science (EECS)
>>     Department of Theoretical Computer Science (TCS)
>>     <http://www.kth.se><https://www.kth.se/profile/amansha><https://www.kth.se/profile/amansha <http://www.kth.se><https://www.kth.se/profile/amansha><https://www.kth.se/profile/amansha>>
>>     <https://www.kth.se/profile/amansha
> <https://www.kth.se/profile/amansha>>https://algomaster99.github.io/
>>     <https://algomaster99.github.io/ <https://algomaster99.github.io/>>
>>     ------------------------------------------------------------------------
>>     *From:* core-libs-dev <core-libs-dev-retn at openjdk.org<mailto:core-libs-dev-retn at openjdk.org>
>>     <mailto:core-libs-dev-retn at openjdk.org<mailto:core-libs-dev-retn at openjdk.org>
> <mailto:core-libs-dev-retn at openjdk.org>>> on behalf of Roger Riggs
>>     <roger.riggs at oracle.com<mailto:roger.riggs at oracle.com> <mailto:roger.riggs at oracle.com<mailto:roger.riggs at oracle.com> <mailto:roger.riggs at oracle.com>>>
>>     *Sent:* Friday, May 17, 2024 4:57:46 AM
>>     *To:* core-libs-dev at openjdk.org<mailto:core-libs-dev at openjdk.org> <mailto:core-libs-dev at openjdk.org<mailto:core-libs-dev at openjdk.org> <mailto:core-libs-dev at openjdk.org>>
>>     *Subject:* Re: Deterministic naming of subclasses of
>>     `java/lang/reflect/Proxy`
>>     Hi Aman,
>>
>>     You may also run into hidden classes (JEP 371: Hidden Classes) that
>>     allow classes to be defined, at runtime, without names.
>>     It has been proposed to use them for generated proxies but that
>>     hasn't been implemented yet.
>>     There are benefits to having nameless classes, because they can't be
>>     referenced by name, only as a capability, they can be better
>>     encapsulated.
>>
>>     fyi, Roger Riggs
>>
>>
>>     On 5/16/24 8:11 AM, Aman Sharma wrote:
>>>
>>>     Hi,
>>>
>>>
>>>     Thanks for your response, Liang!
>>>
>>>
>>>     > I think you meant CVE-2021-42392 instead of 2022.
>>>
>>>
>>>     Sorry of the error. I indeed meant CVE-2021-42392
>>>     <https://nvd.nist.gov/vuln/detail/cve-2021-42392
> <https://nvd.nist.gov/vuln/detail/cve-2021-42392>>.
>>>
>>>
>>>     > Leyden mainly avoids this unstable generation by performing a
>>>     training run to collect classes loaded
>>>
>>>
>>>     Would love to know the details of Project Leyden and how they
>>>     worked so far to focus on this goal. In our case, the training run
>>>     is the test suite.
>>>
>>>
>>>     > GeneratedConstructorAccessor is already retired by JEP 416 [2]
>>>     in Java 18
>>>
>>>
>>>     I did see them not appearing in my allowlist when I ran my study
>>>     subject (Apache PDFBox) with Java 21. Thanks for letting me know
>>>     about this JEP. I see they are re-implemented with method handles.
>>>
>>>
>>>     > How are you checking the classes?
>>>
>>>
>>>     To detect runtime generated code, we have javaagent that is hooked
>>>     statically to the test suite execution. It gives us all classes
>>>     that that is loaded post the JVM and the javaagent are loaded. So
>>>     we only check the classes loaded for the purpose of running the
>>>     application. This is also why we did not choose -agentlib as it
>>>     would give classes for the setting up JVM and javaagent and we the
>>>     user of our tool must the classes they load.
>>>
>>>
>>>     Next, we have a `ClassFileTransformer` hook in the agent where we
>>>     produce the checksum using the bytecode. And we compare the
>>>     checksum with the one existing in the allowlist. The checksum
>>>     computation algorithm is same for both steps. Let me describe how
>>>     I compute the checksum.
>>>
>>>
>>>      1. I get the CONSTANT_Class_info
>>>         <https://docs.oracle.com/javase/specs/jvms/se11/html/jvms-4.html#jvms-4.4.1 <https://docs.oracle.com/javase/specs/jvms/se11/html/jvms-4.html#jvms-4.4.1>> entry corresponding to `this_class` and rewrite the CONSTANT_Utf8_info <https://docs.oracle.com/javase/specs/jvms/se11/html/jvms-4.html#jvms-4.4.7 <https://docs.oracle.com/javase/specs/jvms/se11/html/jvms-4.html#jvms-4.4.7>> corresponding to a fix String constant, say "foo".
>>>      2. Since, the name of the class is used to refer to its types
>>>         members (fields/method), I get all CONSTANT_Fieldref_info
>>>         <https://docs.oracle.com/javase/specs/jvms/se11/html/jvms-4.html#jvms-4.4.2 <https://docs.oracle.com/javase/specs/jvms/se11/html/jvms-4.html#jvms-4.4.2>> and if its `class_index` corresponds to the old `this_class`, we rewrite the UTF8 value of class_index to the same constant "foo".
>>>      3. Next, since the naming of the fields, in Proxy classes, are
>>>         also suffixed by numbers, for example, `private static Method
>>>         m4`, we rewrite the UTF8 value of name in the
>>>         CONSTANT_NameAndType_info
>>>         <https://docs.oracle.com/javase/specs/jvms/se11/html/jvms-4.html#jvms-4.4.6 <https://docs.oracle.com/javase/specs/jvms/se11/html/jvms-4.html#jvms-4.4.6>>.
>>>      4. These fields can also have a random order so we simply sort
>>>         the entire byte code using `Arrays.sort(byte[])` to eliminate
>>>         any differences due to ordering of fields/methods.
>>>      5. Simply sorting the byte array still had minute differences. I
>>>         could not understand why they existed even though values in
>>>         constant pool of the bytecode in allowlist and at runtime were
>>>         exactly the same after rewriting. The differences existed in
>>>         the bytes of the Code attribute of methods. I concluded that
>>>         the bytes stored some position information. To avoid this, I
>>>         created a subarray where I considered the bytes corresponding
>>>         to `CONSTANT_Utf8_info.bytes` only. Computing a checksum for
>>>         it resulted in the same checksums for both classfiles.
>>>
>>>
>>>     Let's understand the whole approach with an example of Proxy class.
>>>
>>>     `
>>>     public  final  class  $Proxy42  extends  Proxy  implements  org.apache.logging.log4j.core.config.plugins.Plugin  {
>>>     `
>>>
>>>     The will go in the allowlist as "Proxy_Plugin: <SHA256 checksum>".
>>>
>>>     When the same class is intercepted at runtime, say "$Proxy10", we
>>>     look for "Proxy_Plugin" in the allowlist and since the checksum
>>>     algorithm is same in both cases, we get a match and let the class
>>>     load.
>>>
>>>     This approach has seemed to work well for Proxy classes, Generated
>>>     Constructor Accessor (which is removed as you said). I also looked
>>>     at the species generated by method handles. I did not notice any
>>>     modification in them. Their name generation seemed okay to me. If
>>>     some new Species are generated, it is of course detected since it
>>>     is not in the allowlist.
>>>
>>>     I have not looked into LambdaMetafactory because I did not
>>>     encounter it as a problem so far, but I am aware its name
>>>     generation is also unstable. I have run my approach only a few
>>>     projects only. And for hidden classes, I assume the the agent
>>>     won't be able to intercept them so detecting them would be really
>>>     hard.
>>>
>>>
>>>     Regards,
>>>     Aman Sharma
>>>
>>>     PhD Student
>>>     KTH Royal Institute of Technology
>>>     School of Electrical Engineering and Computer Science (EECS)
>>>     Department of Theoretical Computer Science (TCS)
>>>     <https://www.kth.se/profile/amansha
> <https://www.kth.se/profile/amansha>>https://algomaster99.github.io/
> <https://algomaster99.github.io/ <https://algomaster99.github.io/>>
>>>     ------------------------------------------------------------------------
>>>     *From:* liangchenblue at gmail.com<mailto:liangchenblue at gmail.com> <mailto:liangchenblue at gmail.com<mailto:liangchenblue at gmail.com> <mailto:liangchenblue at gmail.com>>
>>>     <liangchenblue at gmail.com<mailto:liangchenblue at gmail.com>> <mailto:liangchenblue at gmail.com<mailto:liangchenblue at gmail.com> <mailto:liangchenblue at gmail.com>>
>>>     *Sent:* Thursday, May 16, 2024 5:52:03 AM
>>>     *To:* Aman Sharma; core-libs-dev
>>>     *Cc:* Martin Monperrus
>>>     *Subject:* Re: Deterministic naming of subclasses of
>>>     `java/lang/reflect/Proxy`
>>>     Hi Aman,
>>>     I think you meant CVE-2021-42392 instead of 2022.
>>>
>>>     For your approach of an "allowlist" for Java runtime, project
>>>     Leyden is looking to generate a static image [1], that
>>>     > At run time it cannot load classes from outside the image, nor
>>>     can it create classes dynamically.
>>>     Leyden mainly avoids this unstable generation by performing a
>>>     training run to collect classes loaded and even object graphs; I
>>>     am not familiar with the details unfortunately.
>>>
>>>     Otherwise, the Proxy discussion belongs better to core-libs-dev,
>>>     as java.lang.reflect.Proxy is part of Java's core libraries. I am
>>>     replying this thread to core-libs-dev.
>>>
>>>     For your perceived problem that classes don't have unique names,
>>>     your description sounds dubious: GeneratedConstructorAccessor is
>>>     already retired by JEP 416 [2] in Java 18, and there are many
>>>     other cases in which JDK generates classes without stable names,
>>>     notoriously LambdaMetafactory (Gradle wished for cacheable
>>>     Lambdas); the same applies for the generated classes for
>>>     MethodHandle's LambdaForms (which carries implementation code for
>>>     LambdaForm). How are you checking the classes? It seems you are
>>>     not checking hidden classes. Proxy and Lambda classes are defined
>>>     by the caller's class loader, while LambdaForms are under JDK's
>>>     system class loader I think. We need to ensure you are correctly
>>>     finding all unstable classes before we can proceed.
>>>
>>>     [1]: https://openjdk.org/projects/leyden/notes/01-beginnings
> <https://openjdk.org/projects/leyden/notes/01-beginnings>
>>>     <https://openjdk.org/projects/leyden/notes/01-beginnings
> <https://openjdk.org/projects/leyden/notes/01-beginnings>>
>>>     [2]: https://openjdk.org/jeps/416 <https://openjdk.org/jeps/416>
> <https://openjdk.org/jeps/416 <https://openjdk.org/jeps/416>>
>>>
>>>     On Wed, May 15, 2024 at 7:00?PM Aman Sharma <amansha at kth.se<mailto:amansha at kth.se>
>>>     <mailto:amansha at kth.se<mailto:amansha at kth.se> <mailto:amansha at kth.se>>> wrote:
>>>
>>>         Hi,
>>>
>>>
>>>         My name is Aman and I am a PhD student at KTH Royal Institute
>>>         of Technology, Stockholm, Sweden. I research as part of CHAINS
>>>         <https://chains.proj.kth.se/ <https://chains.proj.kth.se/>> project to
> strengthen the
>>>         software supply chain of multiple ecosystem. I particularly
>>>         focus on runtime integrity in Java. In this email, I want to
>>>         write about an issue I have discovered with /dynamic
>>>         generation of `java.lang.reflect.Proxy`classes/. I will
>>>         propose a solution and would love to hear the feedback from
>>>         the community. Let me know if this is the correct mailing-list
>>>         for such discussions. It seemed the most relevant from this
>>>         list <https://mail.openjdk.org/mailman/listinfo
> <https://mail.openjdk.org/mailman/listinfo>>.
>>>
>>>
>>>         *My research*
>>>
>>>         *
>>>         *
>>>
>>>         Java has features to load class on the fly - it can either
>>>         download or generate a class at runtime. These features are
>>>         useful for inner workings of JDK. For example, implementing
>>>         annotations, reflective access, etc. However, these features
>>>         have also contributed to critical vulnerabilities in the past
>>>         - CVE-2021-44228  (log4shell), CVE-2022-33980, CVE-2022-42392.
>>>         All of these vulnerabilities have one thing in common - /a
>>>         class that was not known during build time was
>>>         downloaded/generated at runtime and loaded into JVM./
>>>
>>>
>>>         To defend against such vulnerabilities, we propose a solution
>>>         to /allowlist classes for runtime/. This allowlist will
>>>         contain an exhaustive list of classes that can be loaded by
>>>         the JVM and it will be enforced at runtime. We build this
>>>         allowlist from three sources:
>>>
>>>          1. All classes of all modules provided by the Java Standard
>>>             Library. We use ClassGraph
>>>             <https://github.com/classgraph/classgraph
> <https://github.com/classgraph/classgraph>> to scan the JDK.
>>>          2. We can take the source code and all dependencies of an
>>>             application. We use a software bill of materials to get
>>>             all the data.
>>>          3. Finally, we use run the test suite to include any runtime
>>>             downloaded/generated classes.
>>>
>>>         Such a list is able to prevent the above 3 CVEs because it
>>>         does not let the "unknown" bytecode to be loaded.
>>>
>>>         *Problem with generating such an allowlist*
>>>         *
>>>         *
>>>         The first two parts of the allowlist are easy to get. The
>>>         problem is with the third step where we want to allowlist all
>>>         the classes that could be downloaded or generated. Upon
>>>         running the test suite and hooking to the classes it loads, we
>>>         observer that the list consists of classes that are called
>>>         "com/sun/proxy/$Proxy2",
>>>         "jdk/internal/reflect/GeneratedConstructorAccessor3" among
>>>         many more. The purpose of these classes can be identifed. The
>>>         proxy class is created for to implement an annotation. The
>>>         accessor gives access to constructor of a class to the JVM.
>>>
>>>         When enforcing this allowlist at runtime, we see that the
>>>         bytecode content for "com/sun/proxy/$Proxy2" differs in the
>>>         allowlist and at runtime. In our case, we we are experimenting
>>>         with pdfbox <https://github.com/apache/pdfbox <https://github.com/apache/pdfbox>> so
> we created
>>>         the allowlist using its test suite. Then we enforced this
>>>         allowlist while running some of its subcommands. However,
>>>         there was some other proxy class say "com/sun/proxy/$Proxy5"
>>>         at runtime that implemented the same interfaces and had the
>>>         same methods as "com/sun/proxy/$Proxy2" in the allowlist. They
>>>         only differed in the name of the class, order of fields, and
>>>         types for fields references. This could happen because the
>>>         order of the loading of class is workload dependent, but it
>>>         causes problem to generate such an allowlist.
>>>
>>>         *Solution
>>>         *
>>>
>>>
>>>         We propose that naming of subclasses of
>>>         "java/lang/reflect/Proxy" should not be dependent upon the
>>>         order of loading. In order to do so, two issues can be fixed:
>>>
>>>          1. The naming of the class should not be based on AtomicLong
>>>             <https://github.com/openjdk/jdk/blob/b687aa550837830b38f0f0faa69c353b1e85219c/src/java.base/share/classes/java/lang/reflect/Proxy.java#L531 <https://github.com/openjdk/jdk/blob/b687aa550837830b38f0f0faa69c353b1e85219c/src/java.base/share/classes/java/lang/reflect/Proxy.java#L531>>. Rather it could be named based on the interfaces it implements. I also wonder why AtomicLong is chosen in the first place.
>>>          2. Methods of the interfaces must be in a particular order.
>>>             Right now, they are not sorted in any particular order
>>>             <https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/lang/Class.java#L2178 <https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/lang/Class.java#L2178>>.
>>>
>>>
>>>         These fixes will make proxy class generation deterministic
>>>         with respect to order of loading and won't be flagged at
>>>         runtime since the test suite would already detect them.
>>>
>>>         I would love to hear from the community about these ideas. If
>>>         in agreement, I would be happy to produce a patch. I have
>>>         discovered this issue with subclasses of
>>>         GeneratedConstructorAccessor
>>>         <https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/jdk/internal/reflect/ConstructorAccessor.java <https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/jdk/internal/reflect/ConstructorAccessor.java>> as well and I imagine it will also apply to some other runtime generated classes. If you disagree, please let me know also. It helps with my research.
>>>
>>>         I also have PoCs for the above CVEs
>>>         <https://github.com/chains-project/exploits-for-sbom.exe
> <https://github.com/chains-project/exploits-for-sbom.exe>> and
>>>         a proof concept tool is being developed under the name
>>>         sbom.exe <https://github.com/chains-project/sbom.exe
> <https://github.com/chains-project/sbom.exe>> in case
>>>         any one wonders about the implementation. I would also be
>>>         happy to explain more.
>>>
>>>         Regards,
>>>         Aman Sharma
>>>
>>>         PhD Student
>>>         KTH Royal Institute of Technology
>>>         School of Electrical Engineering and Computer Science (EECS)
>>>         Department of Theoretical Computer Science (TCS)
>>>         <https://www.kth.se/profile/amansha
> <https://www.kth.se/profile/amansha>>https://algomaster99.github.io/
> <https://algomaster99.github.io/ <https://algomaster99.github.io/>>
>>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240527/d2d22b95/attachment-0001.htm>

From liach at openjdk.org  Mon May 27 12:43:04 2024
From: liach at openjdk.org (Chen Liang)
Date: Mon, 27 May 2024 12:43:04 GMT
Subject: RFR: 8292955: Collections.checkedMap Map.merge does not properly
 check key and value [v3]
In-Reply-To: <KQYW7IawS6gwsNsRrwaPkvWLfuapu-CJK6Sey-nIsNk=.4d0eeacd-5484-430f-ae99-8d5e124d4e8f@github.com>
References: <uYx7ZckdmpZfQzBBlp-i5gZXe1Y6lKaZ3WfynZJbdeU=.0b7fd470-f97e-40b6-989a-5fd0e5e4e179@github.com>
 <KQYW7IawS6gwsNsRrwaPkvWLfuapu-CJK6Sey-nIsNk=.4d0eeacd-5484-430f-ae99-8d5e124d4e8f@github.com>
Message-ID: <8lChj2IPfcR2_MKvykrzNW4n2Har70v3BXEhm1xO1YU=.1828b012-a6f8-460b-b3fc-a2e8d7d33611@github.com>

On Thu, 7 Mar 2024 05:33:16 GMT, Lei Zhu <duke at openjdk.org> wrote:

>> When the specified key did not associated with a value, should check the `key` and `value` type.
>
> Lei Zhu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use testNG builtin functionalities and modify the test function name

@minborg Is it possible for you to review this collection bugfix?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18141#issuecomment-2133400541

From yzheng at openjdk.org  Mon May 27 13:08:09 2024
From: yzheng at openjdk.org (Yudi Zheng)
Date: Mon, 27 May 2024 13:08:09 GMT
Subject: RFR: 8327964: Simplify BigInteger.implMultiplyToLen intrinsic [v7]
In-Reply-To: <9FFOmfnJsAIg1KJN0RcpDmAzpn68k4QBvFifeazLjmc=.dc821eea-3423-4a34-bcfc-217183169352@github.com>
References: <Z5U-3OSq9_rd0t6DHNRhjF3LHtc9b6orz-mcQ4Uqzl8=.c4f0a0b8-9e10-4505-82f7-7d3a82929d22@github.com>
 <9FFOmfnJsAIg1KJN0RcpDmAzpn68k4QBvFifeazLjmc=.dc821eea-3423-4a34-bcfc-217183169352@github.com>
Message-ID: <AmBaliHk_ECRNVAYiTBNl52WQk6rKYln7Y331dOPtcw=.7a8f1fa2-91ec-40b6-9381-a156b01a0e44@github.com>

On Fri, 24 May 2024 15:12:28 GMT, Yudi Zheng <yzheng at openjdk.org> wrote:

>> Moving array construction within BigInteger.implMultiplyToLen intrinsic candidate to its caller simplifies the intrinsic implementation in JIT compiler.
>
> Yudi Zheng has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains eight additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'upstream/master' into JDK-8327964
>  - address comments.
>  - address comments.
>  - address comment.
>  - address comment.
>  - address comment.
>  - address comment.
>  - Simplify BigInteger.implMultiplyToLen intrinsic

Thanks for the reviews! Mach5 testing looks good except for a couple known timeouts unrelated to this PR. GHA test failure is due to [JDK-8332923](https://bugs.openjdk.org/browse/JDK-8332923).

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18226#issuecomment-2133444527

From yzheng at openjdk.org  Mon May 27 14:28:14 2024
From: yzheng at openjdk.org (Yudi Zheng)
Date: Mon, 27 May 2024 14:28:14 GMT
Subject: Integrated: 8327964: Simplify BigInteger.implMultiplyToLen intrinsic
In-Reply-To: <Z5U-3OSq9_rd0t6DHNRhjF3LHtc9b6orz-mcQ4Uqzl8=.c4f0a0b8-9e10-4505-82f7-7d3a82929d22@github.com>
References: <Z5U-3OSq9_rd0t6DHNRhjF3LHtc9b6orz-mcQ4Uqzl8=.c4f0a0b8-9e10-4505-82f7-7d3a82929d22@github.com>
Message-ID: <UQ0_vXRZhvW0uBl5C_WMjDvO0WKcfZNFU7zek_mniUU=.c7a6870d-7a69-4d03-96aa-833c3bd189ac@github.com>

On Tue, 12 Mar 2024 10:44:54 GMT, Yudi Zheng <yzheng at openjdk.org> wrote:

> Moving array construction within BigInteger.implMultiplyToLen intrinsic candidate to its caller simplifies the intrinsic implementation in JIT compiler.

This pull request has now been integrated.

Changeset: ed81a478
Author:    Yudi Zheng <yzheng at openjdk.org>
Committer: Martin Doerr <mdoerr at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/ed81a478e175631f1de69eb4b43f927629fefd74
Stats:     146 lines in 17 files changed: 11 ins; 82 del; 53 mod

8327964: Simplify BigInteger.implMultiplyToLen intrinsic

Reviewed-by: mdoerr, amitkumar, kvn, fyang

-------------

PR: https://git.openjdk.org/jdk/pull/18226

From alanb at openjdk.org  Mon May 27 15:51:35 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 27 May 2024 15:51:35 GMT
Subject: RFR: 8332064: Implementation of Structured Concurrency (Third
 Preview) [v2]
In-Reply-To: <YKVRqYuGwAB4cPvyVacCBrrMlS-m5K1fJSGpe7hQ744=.da388230-47ff-4097-9f9c-7d590bddcb8b@github.com>
References: <YKVRqYuGwAB4cPvyVacCBrrMlS-m5K1fJSGpe7hQ744=.da388230-47ff-4097-9f9c-7d590bddcb8b@github.com>
Message-ID: <_aO0UrKNkK8eYKwFIZNFhb0C-P-vOZhyAXFLqY2pI34=.82609124-db03-437c-a94e-4e5c939b976d@github.com>

> There aren't any API or implementations changes in third preview but the JEP number/title needs to be bumped for the javadoc page.

Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:

 - Merge
 - Initial commit

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19175/files
  - new: https://git.openjdk.org/jdk/pull/19175/files/cff7b36b..c9ae4566

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19175&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19175&range=00-01

  Stats: 63129 lines in 1184 files changed: 47890 ins; 9587 del; 5652 mod
  Patch: https://git.openjdk.org/jdk/pull/19175.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19175/head:pull/19175

PR: https://git.openjdk.org/jdk/pull/19175

From asotona at openjdk.org  Mon May 27 16:05:13 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 27 May 2024 16:05:13 GMT
Subject: RFR: 8332457: Examine startup overheads from JDK-8294961 [v5]
In-Reply-To: <YdSsOH6RBi4-Xy1ZTpSdTqQprzvhAYIenwxWxvC6GrU=.6961b30c-2d67-49b6-aa3e-b4736be0458b@github.com>
References: <YdSsOH6RBi4-Xy1ZTpSdTqQprzvhAYIenwxWxvC6GrU=.6961b30c-2d67-49b6-aa3e-b4736be0458b@github.com>
Message-ID: <CFCqQvi1oVrhLFFtX7QNHiGBITmN3EhrITutGD9k4jo=.8cb26a9f-e704-4bc8-9711-e6989e9ae6a4@github.com>

> [JDK-8294961](https://bugs.openjdk.org/browse/JDK-8294961) changed to use classfile API for reflection proxy-generation. Actual implementation of `ProxyGenerator` is focused on performance, however it causes JDK bootstrap regressions. `ProxyGenerator.TEMPLATE` class model is statically created and each proxy class is transformed from the template.
> 
> This patch is intended to examine plain proxy generation impact on performance and JDK bootstrap (vs proxy transformation from template).
> 
> Please review.
> 
> Thank you,
> Adam

Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:

  simplification of the proxy class loading

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19410/files
  - new: https://git.openjdk.org/jdk/pull/19410/files/eaf30201..3d975d28

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19410&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19410&range=03-04

  Stats: 60 lines in 1 file changed: 0 ins; 50 del; 10 mod
  Patch: https://git.openjdk.org/jdk/pull/19410.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19410/head:pull/19410

PR: https://git.openjdk.org/jdk/pull/19410

From asotona at openjdk.org  Mon May 27 16:11:02 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 27 May 2024 16:11:02 GMT
Subject: RFR: 8332457: Examine startup overheads from JDK-8294961 [v3]
In-Reply-To: <AZiGAwtgnXbZ_b2VkBaRz_-VwvcQXP8tybroNYUS308=.b542b24e-a7f7-41a1-b65e-f7d042522df0@github.com>
References: <YdSsOH6RBi4-Xy1ZTpSdTqQprzvhAYIenwxWxvC6GrU=.6961b30c-2d67-49b6-aa3e-b4736be0458b@github.com>
 <bLw0t5oT2Poi6g22CvAN2s3p4uQHyDa9GKYpBQ89DbQ=.649d7b2b-8389-44d4-bd32-3e5119566206@github.com>
 <AZiGAwtgnXbZ_b2VkBaRz_-VwvcQXP8tybroNYUS308=.b542b24e-a7f7-41a1-b65e-f7d042522df0@github.com>
Message-ID: <4KhKiJQ4RKvgyU7Vo2hpb1l_inqYT2eK4OS0uT-ad7U=.a731cecf-04d0-4121-ba1f-c549688913e0@github.com>

On Mon, 27 May 2024 12:24:31 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   performance improvements
>
> src/java.base/share/classes/java/lang/reflect/ProxyGenerator.java line 822:
> 
>> 820:                .iconst_0() // false
>> 821:                .aload(0)// classLoader
>> 822:                .invokestatic(CD_Class, "forName", MTD_Class_String_boolean_ClassLoader);
> 
> We can probably replace this `forName(name, false, thisClassLoader)` with loading a class constant to reduce load on symbols.

I'm wondering why all the `Class.forName(... <proxyClass>.getClassLoader())` is necessary?
Simple `ldc <class entry>` seems to work well.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19410#discussion_r1616232095

From liach at openjdk.org  Mon May 27 16:22:02 2024
From: liach at openjdk.org (Chen Liang)
Date: Mon, 27 May 2024 16:22:02 GMT
Subject: RFR: 8332457: Examine startup overheads from JDK-8294961 [v3]
In-Reply-To: <4KhKiJQ4RKvgyU7Vo2hpb1l_inqYT2eK4OS0uT-ad7U=.a731cecf-04d0-4121-ba1f-c549688913e0@github.com>
References: <YdSsOH6RBi4-Xy1ZTpSdTqQprzvhAYIenwxWxvC6GrU=.6961b30c-2d67-49b6-aa3e-b4736be0458b@github.com>
 <bLw0t5oT2Poi6g22CvAN2s3p4uQHyDa9GKYpBQ89DbQ=.649d7b2b-8389-44d4-bd32-3e5119566206@github.com>
 <AZiGAwtgnXbZ_b2VkBaRz_-VwvcQXP8tybroNYUS308=.b542b24e-a7f7-41a1-b65e-f7d042522df0@github.com>
 <4KhKiJQ4RKvgyU7Vo2hpb1l_inqYT2eK4OS0uT-ad7U=.a731cecf-04d0-4121-ba1f-c549688913e0@github.com>
Message-ID: <l2ILDq7iGeIWYOI96gfX3FIQwOXAyRMvROWb59EzsLo=.b606ed14-4208-45ee-bdba-cdd7798c1489@github.com>

On Mon, 27 May 2024 16:08:04 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/reflect/ProxyGenerator.java line 822:
>> 
>>> 820:                .iconst_0() // false
>>> 821:                .aload(0)// classLoader
>>> 822:                .invokestatic(CD_Class, "forName", MTD_Class_String_boolean_ClassLoader);
>> 
>> We can probably replace this `forName(name, false, thisClassLoader)` with loading a class constant to reduce load on symbols.
>
> I'm wondering why all the `Class.forName(... <proxyClass>.getClassLoader())` is necessary?
> Simple `ldc <class entry>` seems to work well.

Indeed, I initially added it because a JBS ticket recommended so. ldc instruction has the same behavior as such as forName call.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19410#discussion_r1616241702

From alanb at openjdk.org  Mon May 27 16:25:30 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 27 May 2024 16:25:30 GMT
Subject: RFR: 8331670: Deprecate the Memory-Access Methods in
 sun.misc.Unsafe for Removal [v4]
In-Reply-To: <9FyO4QpCtH2CNkUEE78_Jjd9xs3bv3WJo16jyowHOvY=.e7131b91-37bb-4624-a60e-72a427a24c92@github.com>
References: <9FyO4QpCtH2CNkUEE78_Jjd9xs3bv3WJo16jyowHOvY=.e7131b91-37bb-4624-a60e-72a427a24c92@github.com>
Message-ID: <LfHU978PF6tqPXX0-_jkgKg_slZP2te-lZlxcs1rWZI=.9544ef9b-284c-466a-8937-d4560f6cba85@github.com>

> This is the implementation changes for JEP 471.
> 
> The methods in sun.misc.Unsafe for on-heap and off-heap access are deprecated for removal. This means a removal warning at compile time. No methods have been removed. A deprecated message is added to each of the methods but unlikely to be seen as the JDK does not generate or publish the API docs for this class.
> 
> A new command line option --sun-misc-unsafe-memory-access=$value is introduced to allow or deny access to these methods. The default proposed for JDK 23 is "allow" so no change in behavior compared to JDK 22 or previous releases.
> 
> A new test is added to test the command line option settings. The existing micros for FFM that use Unsafe are updated to suppress the removal warning at compile time. A new micro is introduced with a small sample of methods to ensure the changes doesn't cause any perf regressions ([sample results](https://cr.openjdk.org/~alanb/8331670-results.txt)).
> 
> For now, the changes include the update to the man page for the "java" command. It might be that this has to be separated out so that it goes with other updates in the release.

Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 13 commits:

 - Merge
 - Fix typo in comment
 - Merge
 - Merge
 - Add removal to DISABLED_WARNINGS
   Fail at startup if bad value specified to option
 - Merge
 - Update man page
 - Update man page
 - Fix comment
 - Merge
 - ... and 3 more: https://git.openjdk.org/jdk/compare/985b9ce7...78fc22d7

-------------

Changes: https://git.openjdk.org/jdk/pull/19174/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19174&range=03
  Stats: 1234 lines in 8 files changed: 1150 ins; 5 del; 79 mod
  Patch: https://git.openjdk.org/jdk/pull/19174.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19174/head:pull/19174

PR: https://git.openjdk.org/jdk/pull/19174

From prappo at openjdk.org  Mon May 27 16:29:09 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Mon, 27 May 2024 16:29:09 GMT
Subject: Withdrawn: 8311864: Add ArraysSupport.hashCode(int[] a, fromIndex,
 length, initialValue)
In-Reply-To: <xh6T_mvwyT2yxFZoK-6yg3eudfeRmTt3D_AxR_eScqE=.2c66d4d6-f0f0-4f24-8892-ea2aa5b56c2d@github.com>
References: <xh6T_mvwyT2yxFZoK-6yg3eudfeRmTt3D_AxR_eScqE=.2c66d4d6-f0f0-4f24-8892-ea2aa5b56c2d@github.com>
Message-ID: <TXTabD0cClxCYvpPepiwe8heoRPP6QxHxe3828MwY2o=.f7715fea-96d9-438b-bf29-e1d42fd1648f@github.com>

On Tue, 11 Jul 2023 16:35:51 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> This PR adds an internal method to calculate hash code from the provided integer array, offset and length into that array, and the initial hash code value.
> 
> Current options for calculating a hash code for int[] are inflexible. It's either ArraysSupport.vectorizedHashCode with an offset, length and initial value, or Arrays.hashCode with just an array.
> 
> For an arbitrary int[], unconditional vectorization might be unwarranted or puzzling. Unfortunately, it's the only hash code method that operates on an array subrange or accepts the initial hash code value.
> 
> A more convenient method could be added and then used, for example, here:
> 
> * https://github.com/openjdk/jdk/blob/0ef03f122866f010ebf50683097e9b92e41cdaad/src/java.base/share/classes/java/util/concurrent/CopyOnWriteArrayList.java#L1076-L1083
> 
> * https://github.com/openjdk/jdk/blob/0ef03f122866f010ebf50683097e9b92e41cdaad/src/java.base/share/classes/java/util/ArrayList.java#L669-L680
> 
> * https://github.com/openjdk/jdk/blob/0ef03f122866f010ebf50683097e9b92e41cdaad/src/java.base/share/classes/sun/security/pkcs10/PKCS10.java#L356-L362
> 
> This PR adds such a method and provides tests for it. Additionally, this PR adds tests for `null` passed to `java.util.Arrays.hashCode` overloads, behaviour which was specified but untested.

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/14831

From prappo at openjdk.org  Mon May 27 16:33:09 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Mon, 27 May 2024 16:33:09 GMT
Subject: RFR: 8332826: Make hashCode methods in ArraysSupport friendlier
Message-ID: <ujd2AT3eYXrHPcSG0vMDe2WOx3INNPU1n0t8haKH0_M=.b1a168d7-ab4c-4920-92ef-1c72e5ffc0cf@github.com>

Please review this PR, which supersedes a now withdrawn https://github.com/openjdk/jdk/pull/14831.

This PR replaces `ArraysSupport.vectorizedHashCode` with a set of more user-friendly methods. Here's a summary:

- Made the operand constants (i.e. `T_BOOLEAN` and friends) and the `vectorizedHashCode` method private

- Made the `vectorizedHashCode` method private, but didn't rename it. Renaming would dramatically increase this PR review cost, because that method's name is used by a lot of VM code. On a bright side, since the method is now private, it's no longer callable by clients of `ArraysSupport`, thus a problem of an inaccurate name is less severe.

- Made the `ArraysSupport.utf16HashCode` method private

- Moved tiny cases (i.e. 0, 1, 2) to `ArraysSupport`

-------------

Commit messages:
 - Initial commit

Changes: https://git.openjdk.org/jdk/pull/19414/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19414&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8332826
  Stats: 258 lines in 13 files changed: 186 ins; 32 del; 40 mod
  Patch: https://git.openjdk.org/jdk/pull/19414.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19414/head:pull/19414

PR: https://git.openjdk.org/jdk/pull/19414

From amansha at kth.se  Mon May 27 16:44:27 2024
From: amansha at kth.se (Aman Sharma)
Date: Mon, 27 May 2024 16:44:27 +0000
Subject: Deterministic naming of subclasses of `java/lang/reflect/Proxy`
In-Reply-To: <05576e3cfb004fe980dd18b470f79291@kth.se>
References: <bf26eb2f74874e02876b3868311922a9@kth.se>
 <CABe8uE0fk71Xy_PYHikSw9OtXE_i+M9zMbayPEXuTxLWLoy2ag@mail.gmail.com>
 <50405ca9c0a64372bace175b932f9ef7@kth.se>
 <61fbe3d9-9536-4113-adde-6cfc671ba1ee@oracle.com>
 <a860be44e06243799593aa8d67c048cd@kth.se>
 <CABe8uE115=DzYCdnvNazqFuuxtJoZnv9wRUkFA4-PS7g41QLMw@mail.gmail.com>
 <DB7PR02MB35938DCC3A392536B924164AFBEE2@DB7PR02MB3593.eurprd02.prod.outlook.com>
 <a0330ee0-5f45-4ef2-8500-e5fcdb696c52@oracle.com>
 <b214cc1a13fe4885a437e16b420e5483@kth.se>
 <ac2ebe5c-db49-4a2d-a5cd-10440a77aa16@oracle.com>
 <580b3aacd8df48fcaae3399718e229ab@kth.se>
 <CABe8uE065Q3+0yNjtyDF-eJM4LN-MbY9kfC44CnSQ-KM4p862g@mail.gmail.com>
 <b64077d6cf0045e98b630cf888785182@kth.se>
 <eabfa5ae508e4257bd0c9bbef244637f@kth.se>
 <CABe8uE13qRX7pRXJOdhUF0sUwF5WkxTAM517tSTOi1r2Q7ivOg@mail.gmail.com>
 <fb6a2cb13c2449acac32fdfb781b0ce0@kth.se>,
 <CABe8uE2M4mY-dmOaCVuJr0X-xC8vvrKx_FFv3eo8YqpBH=YM+Q@mail.gmail.com>,
 <05576e3cfb004fe980dd18b470f79291@kth.se>
Message-ID: <4cb1f1ef34dd485cae4eb6199447835a@kth.se>

Hi Chen,


You can also observe this difference in a Proxy class based on the internal Java classes - `java.beans.BeanProperty`. I see a difference in the order of methods when I disassembled the attached classfiles using OpenJDK 22+36.


Regards,
Aman Sharma

PhD Student
KTH Royal Institute of Technology
School of Electrical Engineering and Computer Science (EECS)
Department of Theoretical Computer Science (TCS)
<http://www.kth.se><https://www.kth.se/profile/amansha><https://www.kth.se/profile/amansha>
<https://www.kth.se/profile/amansha>https://algomaster99.github.io/
________________________________
From: Aman Sharma
Sent: Monday, May 27, 2024 2:31:43 PM
To: Chen Liang
Cc: core-libs-dev at openjdk.org
Subject: Re: Deterministic naming of subclasses of `java/lang/reflect/Proxy`


Hi Chen,


> Did you reorder the field in picocli.CommandLine$Command?


No. I did not touch the bytecode. The attached bytecode are taken from the `classfileBuffer` parameter of java.lang.instrument.ClassFileTransformer. As you can see, they are exactly equal.


Regards,
Aman Sharma

PhD Student
KTH Royal Institute of Technology
School of Electrical Engineering and Computer Science (EECS)
Department of Theoretical Computer Science (TCS)
<http://www.kth.se><https://www.kth.se/profile/amansha><https://www.kth.se/profile/amansha>
<https://www.kth.se/profile/amansha>https://algomaster99.github.io/
________________________________
From: Chen Liang <liangchenblue at gmail.com>
Sent: Saturday, May 25, 2024 11:28:01 PM
To: Aman Sharma
Cc: core-libs-dev at openjdk.org
Subject: Re: Deterministic naming of subclasses of `java/lang/reflect/Proxy`

Did you reorder the field in picocli.CommandLine$Command?
In class 13 the usageHelpWidth was preceded by versionProvider, in class 9 it's preceded by requiredOptionMarker. It would also be helpful if you can provide the bytecode for Command class, as it might be due to method ordering in reflection from multiple inheritance (if Command extends multiple interfaces), as you see some subsections of the methods (such as from requiredOptionMarker to said footerHeading) are ordered.

Chen

On Sat, May 25, 2024 at 4:03?PM Aman Sharma <amansha at kth.se<mailto:amansha at kth.se>> wrote:

Hi Chen,

I am attaching proxy classes generated in the JVM of OpenJDK 22. I, instead of decompiling, I disassembled them and I do see a difference. For example, see method `footerHeading` in both classes. In $Proxy9, it is mapped to `m39` field and in $Proxy13, it is mapped to `m21` field. What is the reason for this ordering? Why is mapping of methods to fields depend upon the execution?


Regards,
Aman Sharma

PhD Student
KTH Royal Institute of Technology
School of Electrical Engineering and Computer Science (EECS)
Department of Theoretical Computer Science (TCS)
<https://www.kth.se/profile/amansha>https://algomaster99.github.io/
________________________________
From: Chen Liang <liangchenblue at gmail.com<mailto:liangchenblue at gmail.com>>
Sent: Wednesday, May 22, 2024 9:37:16 PM
To: Aman Sharma
Cc: core-libs-dev at openjdk.org<mailto:core-libs-dev at openjdk.org>; leyden-dev at openjdk.org<mailto:leyden-dev at openjdk.org>
Subject: Re: Deterministic naming of subclasses of `java/lang/reflect/Proxy`

Hi Aman,
Even though the specification says "not in any particular order," the getInterfaces and getMethods actually return an ordered array, in the order these methods/interfaces are declared in their class files.

I believe you are decompiling the proxy classes generated by an older version of the JDK; for example, back in JDK 8, the proxy methods were not ordered because they were tracked in a HashMap: https://github.com/openjdk/jdk8u/blob/6b53212ef78ad50f9eede829c5ff87cadcdb434b/jdk/src/share/classes/sun/misc/ProxyGenerator.java#L405
Which is no longer the case: https://github.com/openjdk/jdk/blob/d59c12fe1041a1f61f68408241a9aa4d96ac4fd2/src/java.base/share/classes/java/lang/reflect/ProxyGenerator.java#L241

- Chen

On Wed, May 22, 2024 at 1:19?PM Aman Sharma <amansha at kth.se<mailto:amansha at kth.se>> wrote:

Hi,


Another thing I wanted to look into in this thread was the order of fields in the Proxy classes generated. They are also based on the a number. The same proxy classes across different executions can have random order of `Method` fields and the methods could be mapped to different field names.


For example, consider the proxy class based on `picocli.CommandLine<https://github.com/remkop/picocli/blob/da98db63d1b516141b7485881b0dcddfd082dbc8/src/main/java/picocli/CommandLine.java#L4541>` in two different executions.

// fields and method are truncated for brevity
public final class $Proxy9 extends Proxy implements CommandLine.Command {
    private static Method m1;
    private static Method m32;
    private static Method m21;
    private static Method m43;
    private static Method m36;
    private static Method m27;

    public final boolean helpCommand() throws  {
        try {
            return (Boolean)super.h.invoke(this, m32, (Object[])null);
        } catch (RuntimeException | Error var2) {
            throw var2;
        } catch (Throwable var3) {
            throw new UndeclaredThrowableException(var3);
        }
     }

// fields and method are truncated for brevity
public final class $Proxy13 extends Proxy implements CommandLine.Command {
    private static Method m1;
    private static Method m29;
    private static Method m16;
    private static Method m40;
    private static Method m38;
    private static Method m12;

    public final boolean helpCommand() throws  {
        try {
            return (Boolean)super.h.invoke(this, m29, (Object[])null);
        } catch (RuntimeException | Error var2) {
            throw var2;
        } catch (Throwable var3) {
            throw new UndeclaredThrowableException(var3);
        }
    }


Notice the difference in the order of fields and `helpCommand` method is mapped to a different field name in both classes. This happens because the method array returned by `getMethods` is not sorted in any particular order<https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/lang/Class.java#L2178> when generating a proxy class. What dictates this order? And why is it not deterministic?


Regards,
Aman Sharma

PhD Student
KTH Royal Institute of Technology
School of Electrical Engineering and Computer Science (EECS)
Department of Theoretical Computer Science (TCS)
<http://www.kth.se><https://www.kth.se/profile/amansha><https://www.kth.se/profile/amansha>
<https://www.kth.se/profile/amansha>https://algomaster99.github.io/
________________________________
From: Aman Sharma
Sent: Wednesday, May 22, 2024 4:12:19 PM
To: Chen Liang
Cc: David Holmes; core-libs-dev at openjdk.org<mailto:core-libs-dev at openjdk.org>; leyden-dev at openjdk.org<mailto:leyden-dev at openjdk.org>
Subject: Re: Deterministic naming of subclasses of `java/lang/reflect/Proxy`


Hi Chen,


That's clear. Thanks for letting me know. I guess then Project Leyden is working on naming the hidden classes deterministically to achieve their goals<https://openjdk.org/projects/leyden/notes/01-beginnings>.


Regards,
Aman Sharma

PhD Student
KTH Royal Institute of Technology
School of Electrical Engineering and Computer Science (EECS)
Department of Theoretical Computer Science (TCS)
<http://www.kth.se><https://www.kth.se/profile/amansha><https://www.kth.se/profile/amansha>
<https://www.kth.se/profile/amansha>https://algomaster99.github.io/
________________________________
From: Chen Liang <liangchenblue at gmail.com<mailto:liangchenblue at gmail.com>>
Sent: Wednesday, May 22, 2024 1:35:46 PM
To: Aman Sharma
Cc: David Holmes; core-libs-dev at openjdk.org<mailto:core-libs-dev at openjdk.org>; leyden-dev at openjdk.org<mailto:leyden-dev at openjdk.org>
Subject: Re: Deterministic naming of subclasses of `java/lang/reflect/Proxy`

Hi Aman,
We have tried defining Proxy as hidden classes; a previous attempt was on hold because of issues with serialization. Otherwise, Proxies work great as hidden classes.

Chen

On Mon, May 20, 2024 at 7:56?AM Aman Sharma <amansha at kth.se<mailto:amansha at kth.se>> wrote:

Hi David,


> I would not expect any class load
events.


I understand. I also haven't tried to intercept them but I see only one approach right now to include them in an allowlist - 1) statically look for invocations of "Lookup::defineHiddenClass". 2) Instrument them so that its first argument "bytes" can be looked into upon. I haven't looked into it much because I did not have much idea about it. And they are hidden so it made it worse. ? Thanks for sharing the JEP!


>

java.lang.reflect.Proxy could define hidden classes to act as the proxy classes which implement proxy interfaces; from JEP 317


It says that Proxy classes will also become hidden classes. Is it underway? Right now one can intercept, transform them, and include them in an allowlist. What do you think of naming them independent of AtomicLong so that a proxy class generated at runtime is easy to lookup in the allowlist?



Regards,
Aman Sharma

PhD Student
KTH Royal Institute of Technology
School of Electrical Engineering and Computer Science (EECS)
Department of Theoretical Computer Science (TCS)
<http://www.kth.se><https://www.kth.se/profile/amansha><https://www.kth.se/profile/amansha>
<https://www.kth.se/profile/amansha>https://algomaster99.github.io/
________________________________
From: David Holmes <david.holmes at oracle.com<mailto:david.holmes at oracle.com>>
Sent: Monday, May 20, 2024 2:30:37 PM
To: Aman Sharma; liangchenblue at gmail.com<mailto:liangchenblue at gmail.com>
Cc: core-libs-dev at openjdk.org<mailto:core-libs-dev at openjdk.org>; leyden-dev at openjdk.org<mailto:leyden-dev at openjdk.org>
Subject: Re: Deterministic naming of subclasses of `java/lang/reflect/Proxy`

On 20/05/2024 10:12 pm, Aman Sharma wrote:
> Hi David,
>
>
>  > How did you try to intercept them? Hidden classes are not "loaded" in
> the normal sense so won't trigger class load events.
>
>
> I could not intercept them. I only see them when I pass `-verbose:class`
> in the Java CLI.

Yes that is why I asked how you tried to intercept them.

>
> I also couldn't intercept them using JVMTI Class File Load Hook
> <https://docs.oracle.com/en/java/javase/21/docs/specs/jvmti.html#ClassFileLoadHook> event. However JEP 371 suggests that it should be possible to intercept them using JVMTI Class Load <https://docs.oracle.com/en/java/javase/21/docs/specs/jvmti.html#ClassLoad> event, but I won't have the bytecode at this stage. So is there no way to get its bytecode before it is linked and initialized in the JVM?

Hidden classes are not loaded so I would not expect any class load
events. However the exact nature of the JVMTI class load event is
unclear as it talks about "class or interface creation" which is neither
loading or defining per se. But a class prepare event sounds like it
should be issued. However neither give you access to the bytecode of the
class AFAICS.

David
-----


>
> Regards,
> Aman Sharma
>
> PhD Student
> KTH Royal Institute of Technology
> School of Electrical Engineering and Computer Science (EECS)
> Department of Theoretical Computer Science (TCS)
> <http://www.kth.se><https://www.kth.se/profile/amansha><https://www.kth.se/profile/amansha>
> <https://www.kth.se/profile/amansha>https://algomaster99.github.io/
> <https://algomaster99.github.io/>
> ------------------------------------------------------------------------
> *From:* David Holmes <david.holmes at oracle.com<mailto:david.holmes at oracle.com>>
> *Sent:* Monday, May 20, 2024 2:59:17 AM
> *To:* Aman Sharma; liangchenblue at gmail.com<mailto:liangchenblue at gmail.com>
> *Cc:* core-libs-dev at openjdk.org<mailto:core-libs-dev at openjdk.org>; leyden-dev at openjdk.org<mailto:leyden-dev at openjdk.org>
> *Subject:* Re: Deterministic naming of subclasses of
> `java/lang/reflect/Proxy`
> On 17/05/2024 9:43 pm, Aman Sharma wrote:
>> Hi Chen,
>>
>>  > java.lang.invoke.LambdaForm$MH/0x00000200cc000400
>>
>> I do see this as output when I pass -verbose:class. However, based on my
>> experiments, I have seen that neither an agent passed via 'javaagent'
>> nor an agent passed via 'agentpath' is able to intercept this hidden class.
>
> How did you try to intercept them? Hidden classes are not "loaded" in
> the normal sense so won't trigger class load events.
>
>> Also, I was a bit confused since I saw somewhere that the names of
>> hidden classes are null. But thanks for clarifying here.
>
> The JEP clearly defines the name format for hidden classes - though the
> final component is VM specific (and typically a hashcode).
>
> https://openjdk.org/jeps/371 <https://openjdk.org/jeps/371>
>
> Cheers,
> David
> -----
>
>>  > avoid dynamic class loading
>>
>> I don't see dynamic class loading as a problem. I only mind some
>> unstable generation aspects of them which make it hard to verify them
>> based on an allowlist.
>>
>> For example, if this hidden class is generated with the exact same name
>> and the exact same bytecode during runtime as well, it would be easy to
>> verify it. However, I do see the names are based on some sort of memory
>> address so and I don't know what bytecode it has so I don't have
>> suggestions to make them stable as of now. For Proxy classes, I feel it
>> can be addressed unless you disagree or some involved in Project Leyden
>> does. :) Thank you for forwarding my mail there.
>>
>> Regards,
>> Aman Sharma
>>
>> PhD Student
>> KTH Royal Institute of Technology
>> https://algomaster99.github.io/ <https://algomaster99.github.io/>
> <https://algomaster99.github.io/ <https://algomaster99.github.io/>>
>>
>> ------------------------------------------------------------------------
>> *From:* liangchenblue at gmail.com<mailto:liangchenblue at gmail.com> <liangchenblue at gmail.com<mailto:liangchenblue at gmail.com>>
>> *Sent:* Friday, May 17, 2024 1:23:58 pm
>> *To:* Aman Sharma <amansha at kth.se<mailto:amansha at kth.se>>
>> *Cc:* core-libs-dev at openjdk.org<mailto:core-libs-dev at openjdk.org> <core-libs-dev at openjdk.org<mailto:core-libs-dev at openjdk.org>>;
>> leyden-dev at openjdk.org<mailto:leyden-dev at openjdk.org> <leyden-dev at openjdk.org<mailto:leyden-dev at openjdk.org>>
>> *Subject:* Re: Deterministic naming of subclasses of
>> `java/lang/reflect/Proxy`
>>
>> Hi Aman,
>> For `-verbose:class`, it's a JVM argument instead of a program argument;
>> so when you run a java program like `java Main`, you should call it as
>> `java -verbose:class Main`.
>> When done correctly, you should see hidden class outputs like:
>> [0.032s][info][class,load]
>> java.lang.invoke.LambdaForm$MH/0x00000200cc000400 source:
>> __JVM_LookupDefineClass__
>> The loading of java.lang.invoke hidden classes requires your program to
>> use MethodHandle features, like a lambda.
>>
>> I think the problem you are exploring, that to avoid dynamic class
>> loading and effectively turn Java Platform closed for security, is also
>> being accomplished by project Leyden (as I've shared initially); Thus, I
>> am forwarding this to leyden-dev instead, so you can see what approach
>> Leyden uses to accomplish the same goal as yours.
>>
>> Regards, Chen Liang
>>
>> On Fri, May 17, 2024 at 4:40?AM Aman Sharma <amansha at kth.se<mailto:amansha at kth.se>
>> <mailto:amansha at kth.se<mailto:amansha at kth.se> <mailto:amansha at kth.se>>> wrote:
>>
>>     __
>>
>>     Hi Roger,
>>
>>
>>     Do you have ideas on how to intercept them? My javaagent is not able
>>     to nor a JVMTI agent passed using `agentpath` option. It also does
>>     not seem to show up in logs when I pass `-verbose:class`.
>>
>>
>>     Also, what do you think of renaming the proxy classes as suggested
>>     below?
>>
>>
>>     Regards,
>>     Aman Sharma
>>
>>     PhD Student
>>     KTH Royal Institute of Technology
>>     School of Electrical Engineering and Computer Science (EECS)
>>     Department of Theoretical Computer Science (TCS)
>>     <http://www.kth.se><https://www.kth.se/profile/amansha><https://www.kth.se/profile/amansha <http://www.kth.se><https://www.kth.se/profile/amansha><https://www.kth.se/profile/amansha>>
>>     <https://www.kth.se/profile/amansha
> <https://www.kth.se/profile/amansha>>https://algomaster99.github.io/
>>     <https://algomaster99.github.io/ <https://algomaster99.github.io/>>
>>     ------------------------------------------------------------------------
>>     *From:* core-libs-dev <core-libs-dev-retn at openjdk.org<mailto:core-libs-dev-retn at openjdk.org>
>>     <mailto:core-libs-dev-retn at openjdk.org<mailto:core-libs-dev-retn at openjdk.org>
> <mailto:core-libs-dev-retn at openjdk.org>>> on behalf of Roger Riggs
>>     <roger.riggs at oracle.com<mailto:roger.riggs at oracle.com> <mailto:roger.riggs at oracle.com<mailto:roger.riggs at oracle.com> <mailto:roger.riggs at oracle.com>>>
>>     *Sent:* Friday, May 17, 2024 4:57:46 AM
>>     *To:* core-libs-dev at openjdk.org<mailto:core-libs-dev at openjdk.org> <mailto:core-libs-dev at openjdk.org<mailto:core-libs-dev at openjdk.org> <mailto:core-libs-dev at openjdk.org>>
>>     *Subject:* Re: Deterministic naming of subclasses of
>>     `java/lang/reflect/Proxy`
>>     Hi Aman,
>>
>>     You may also run into hidden classes (JEP 371: Hidden Classes) that
>>     allow classes to be defined, at runtime, without names.
>>     It has been proposed to use them for generated proxies but that
>>     hasn't been implemented yet.
>>     There are benefits to having nameless classes, because they can't be
>>     referenced by name, only as a capability, they can be better
>>     encapsulated.
>>
>>     fyi, Roger Riggs
>>
>>
>>     On 5/16/24 8:11 AM, Aman Sharma wrote:
>>>
>>>     Hi,
>>>
>>>
>>>     Thanks for your response, Liang!
>>>
>>>
>>>     > I think you meant CVE-2021-42392 instead of 2022.
>>>
>>>
>>>     Sorry of the error. I indeed meant CVE-2021-42392
>>>     <https://nvd.nist.gov/vuln/detail/cve-2021-42392
> <https://nvd.nist.gov/vuln/detail/cve-2021-42392>>.
>>>
>>>
>>>     > Leyden mainly avoids this unstable generation by performing a
>>>     training run to collect classes loaded
>>>
>>>
>>>     Would love to know the details of Project Leyden and how they
>>>     worked so far to focus on this goal. In our case, the training run
>>>     is the test suite.
>>>
>>>
>>>     > GeneratedConstructorAccessor is already retired by JEP 416 [2]
>>>     in Java 18
>>>
>>>
>>>     I did see them not appearing in my allowlist when I ran my study
>>>     subject (Apache PDFBox) with Java 21. Thanks for letting me know
>>>     about this JEP. I see they are re-implemented with method handles.
>>>
>>>
>>>     > How are you checking the classes?
>>>
>>>
>>>     To detect runtime generated code, we have javaagent that is hooked
>>>     statically to the test suite execution. It gives us all classes
>>>     that that is loaded post the JVM and the javaagent are loaded. So
>>>     we only check the classes loaded for the purpose of running the
>>>     application. This is also why we did not choose -agentlib as it
>>>     would give classes for the setting up JVM and javaagent and we the
>>>     user of our tool must the classes they load.
>>>
>>>
>>>     Next, we have a `ClassFileTransformer` hook in the agent where we
>>>     produce the checksum using the bytecode. And we compare the
>>>     checksum with the one existing in the allowlist. The checksum
>>>     computation algorithm is same for both steps. Let me describe how
>>>     I compute the checksum.
>>>
>>>
>>>      1. I get the CONSTANT_Class_info
>>>         <https://docs.oracle.com/javase/specs/jvms/se11/html/jvms-4.html#jvms-4.4.1 <https://docs.oracle.com/javase/specs/jvms/se11/html/jvms-4.html#jvms-4.4.1>> entry corresponding to `this_class` and rewrite the CONSTANT_Utf8_info <https://docs.oracle.com/javase/specs/jvms/se11/html/jvms-4.html#jvms-4.4.7 <https://docs.oracle.com/javase/specs/jvms/se11/html/jvms-4.html#jvms-4.4.7>> corresponding to a fix String constant, say "foo".
>>>      2. Since, the name of the class is used to refer to its types
>>>         members (fields/method), I get all CONSTANT_Fieldref_info
>>>         <https://docs.oracle.com/javase/specs/jvms/se11/html/jvms-4.html#jvms-4.4.2 <https://docs.oracle.com/javase/specs/jvms/se11/html/jvms-4.html#jvms-4.4.2>> and if its `class_index` corresponds to the old `this_class`, we rewrite the UTF8 value of class_index to the same constant "foo".
>>>      3. Next, since the naming of the fields, in Proxy classes, are
>>>         also suffixed by numbers, for example, `private static Method
>>>         m4`, we rewrite the UTF8 value of name in the
>>>         CONSTANT_NameAndType_info
>>>         <https://docs.oracle.com/javase/specs/jvms/se11/html/jvms-4.html#jvms-4.4.6 <https://docs.oracle.com/javase/specs/jvms/se11/html/jvms-4.html#jvms-4.4.6>>.
>>>      4. These fields can also have a random order so we simply sort
>>>         the entire byte code using `Arrays.sort(byte[])` to eliminate
>>>         any differences due to ordering of fields/methods.
>>>      5. Simply sorting the byte array still had minute differences. I
>>>         could not understand why they existed even though values in
>>>         constant pool of the bytecode in allowlist and at runtime were
>>>         exactly the same after rewriting. The differences existed in
>>>         the bytes of the Code attribute of methods. I concluded that
>>>         the bytes stored some position information. To avoid this, I
>>>         created a subarray where I considered the bytes corresponding
>>>         to `CONSTANT_Utf8_info.bytes` only. Computing a checksum for
>>>         it resulted in the same checksums for both classfiles.
>>>
>>>
>>>     Let's understand the whole approach with an example of Proxy class.
>>>
>>>     `
>>>     public  final  class  $Proxy42  extends  Proxy  implements  org.apache.logging.log4j.core.config.plugins.Plugin  {
>>>     `
>>>
>>>     The will go in the allowlist as "Proxy_Plugin: <SHA256 checksum>".
>>>
>>>     When the same class is intercepted at runtime, say "$Proxy10", we
>>>     look for "Proxy_Plugin" in the allowlist and since the checksum
>>>     algorithm is same in both cases, we get a match and let the class
>>>     load.
>>>
>>>     This approach has seemed to work well for Proxy classes, Generated
>>>     Constructor Accessor (which is removed as you said). I also looked
>>>     at the species generated by method handles. I did not notice any
>>>     modification in them. Their name generation seemed okay to me. If
>>>     some new Species are generated, it is of course detected since it
>>>     is not in the allowlist.
>>>
>>>     I have not looked into LambdaMetafactory because I did not
>>>     encounter it as a problem so far, but I am aware its name
>>>     generation is also unstable. I have run my approach only a few
>>>     projects only. And for hidden classes, I assume the the agent
>>>     won't be able to intercept them so detecting them would be really
>>>     hard.
>>>
>>>
>>>     Regards,
>>>     Aman Sharma
>>>
>>>     PhD Student
>>>     KTH Royal Institute of Technology
>>>     School of Electrical Engineering and Computer Science (EECS)
>>>     Department of Theoretical Computer Science (TCS)
>>>     <https://www.kth.se/profile/amansha
> <https://www.kth.se/profile/amansha>>https://algomaster99.github.io/
> <https://algomaster99.github.io/ <https://algomaster99.github.io/>>
>>>     ------------------------------------------------------------------------
>>>     *From:* liangchenblue at gmail.com<mailto:liangchenblue at gmail.com> <mailto:liangchenblue at gmail.com<mailto:liangchenblue at gmail.com> <mailto:liangchenblue at gmail.com>>
>>>     <liangchenblue at gmail.com<mailto:liangchenblue at gmail.com>> <mailto:liangchenblue at gmail.com<mailto:liangchenblue at gmail.com> <mailto:liangchenblue at gmail.com>>
>>>     *Sent:* Thursday, May 16, 2024 5:52:03 AM
>>>     *To:* Aman Sharma; core-libs-dev
>>>     *Cc:* Martin Monperrus
>>>     *Subject:* Re: Deterministic naming of subclasses of
>>>     `java/lang/reflect/Proxy`
>>>     Hi Aman,
>>>     I think you meant CVE-2021-42392 instead of 2022.
>>>
>>>     For your approach of an "allowlist" for Java runtime, project
>>>     Leyden is looking to generate a static image [1], that
>>>     > At run time it cannot load classes from outside the image, nor
>>>     can it create classes dynamically.
>>>     Leyden mainly avoids this unstable generation by performing a
>>>     training run to collect classes loaded and even object graphs; I
>>>     am not familiar with the details unfortunately.
>>>
>>>     Otherwise, the Proxy discussion belongs better to core-libs-dev,
>>>     as java.lang.reflect.Proxy is part of Java's core libraries. I am
>>>     replying this thread to core-libs-dev.
>>>
>>>     For your perceived problem that classes don't have unique names,
>>>     your description sounds dubious: GeneratedConstructorAccessor is
>>>     already retired by JEP 416 [2] in Java 18, and there are many
>>>     other cases in which JDK generates classes without stable names,
>>>     notoriously LambdaMetafactory (Gradle wished for cacheable
>>>     Lambdas); the same applies for the generated classes for
>>>     MethodHandle's LambdaForms (which carries implementation code for
>>>     LambdaForm). How are you checking the classes? It seems you are
>>>     not checking hidden classes. Proxy and Lambda classes are defined
>>>     by the caller's class loader, while LambdaForms are under JDK's
>>>     system class loader I think. We need to ensure you are correctly
>>>     finding all unstable classes before we can proceed.
>>>
>>>     [1]: https://openjdk.org/projects/leyden/notes/01-beginnings
> <https://openjdk.org/projects/leyden/notes/01-beginnings>
>>>     <https://openjdk.org/projects/leyden/notes/01-beginnings
> <https://openjdk.org/projects/leyden/notes/01-beginnings>>
>>>     [2]: https://openjdk.org/jeps/416 <https://openjdk.org/jeps/416>
> <https://openjdk.org/jeps/416 <https://openjdk.org/jeps/416>>
>>>
>>>     On Wed, May 15, 2024 at 7:00?PM Aman Sharma <amansha at kth.se<mailto:amansha at kth.se>
>>>     <mailto:amansha at kth.se<mailto:amansha at kth.se> <mailto:amansha at kth.se>>> wrote:
>>>
>>>         Hi,
>>>
>>>
>>>         My name is Aman and I am a PhD student at KTH Royal Institute
>>>         of Technology, Stockholm, Sweden. I research as part of CHAINS
>>>         <https://chains.proj.kth.se/ <https://chains.proj.kth.se/>> project to
> strengthen the
>>>         software supply chain of multiple ecosystem. I particularly
>>>         focus on runtime integrity in Java. In this email, I want to
>>>         write about an issue I have discovered with /dynamic
>>>         generation of `java.lang.reflect.Proxy`classes/. I will
>>>         propose a solution and would love to hear the feedback from
>>>         the community. Let me know if this is the correct mailing-list
>>>         for such discussions. It seemed the most relevant from this
>>>         list <https://mail.openjdk.org/mailman/listinfo
> <https://mail.openjdk.org/mailman/listinfo>>.
>>>
>>>
>>>         *My research*
>>>
>>>         *
>>>         *
>>>
>>>         Java has features to load class on the fly - it can either
>>>         download or generate a class at runtime. These features are
>>>         useful for inner workings of JDK. For example, implementing
>>>         annotations, reflective access, etc. However, these features
>>>         have also contributed to critical vulnerabilities in the past
>>>         - CVE-2021-44228  (log4shell), CVE-2022-33980, CVE-2022-42392.
>>>         All of these vulnerabilities have one thing in common - /a
>>>         class that was not known during build time was
>>>         downloaded/generated at runtime and loaded into JVM./
>>>
>>>
>>>         To defend against such vulnerabilities, we propose a solution
>>>         to /allowlist classes for runtime/. This allowlist will
>>>         contain an exhaustive list of classes that can be loaded by
>>>         the JVM and it will be enforced at runtime. We build this
>>>         allowlist from three sources:
>>>
>>>          1. All classes of all modules provided by the Java Standard
>>>             Library. We use ClassGraph
>>>             <https://github.com/classgraph/classgraph
> <https://github.com/classgraph/classgraph>> to scan the JDK.
>>>          2. We can take the source code and all dependencies of an
>>>             application. We use a software bill of materials to get
>>>             all the data.
>>>          3. Finally, we use run the test suite to include any runtime
>>>             downloaded/generated classes.
>>>
>>>         Such a list is able to prevent the above 3 CVEs because it
>>>         does not let the "unknown" bytecode to be loaded.
>>>
>>>         *Problem with generating such an allowlist*
>>>         *
>>>         *
>>>         The first two parts of the allowlist are easy to get. The
>>>         problem is with the third step where we want to allowlist all
>>>         the classes that could be downloaded or generated. Upon
>>>         running the test suite and hooking to the classes it loads, we
>>>         observer that the list consists of classes that are called
>>>         "com/sun/proxy/$Proxy2",
>>>         "jdk/internal/reflect/GeneratedConstructorAccessor3" among
>>>         many more. The purpose of these classes can be identifed. The
>>>         proxy class is created for to implement an annotation. The
>>>         accessor gives access to constructor of a class to the JVM.
>>>
>>>         When enforcing this allowlist at runtime, we see that the
>>>         bytecode content for "com/sun/proxy/$Proxy2" differs in the
>>>         allowlist and at runtime. In our case, we we are experimenting
>>>         with pdfbox <https://github.com/apache/pdfbox <https://github.com/apache/pdfbox>> so
> we created
>>>         the allowlist using its test suite. Then we enforced this
>>>         allowlist while running some of its subcommands. However,
>>>         there was some other proxy class say "com/sun/proxy/$Proxy5"
>>>         at runtime that implemented the same interfaces and had the
>>>         same methods as "com/sun/proxy/$Proxy2" in the allowlist. They
>>>         only differed in the name of the class, order of fields, and
>>>         types for fields references. This could happen because the
>>>         order of the loading of class is workload dependent, but it
>>>         causes problem to generate such an allowlist.
>>>
>>>         *Solution
>>>         *
>>>
>>>
>>>         We propose that naming of subclasses of
>>>         "java/lang/reflect/Proxy" should not be dependent upon the
>>>         order of loading. In order to do so, two issues can be fixed:
>>>
>>>          1. The naming of the class should not be based on AtomicLong
>>>             <https://github.com/openjdk/jdk/blob/b687aa550837830b38f0f0faa69c353b1e85219c/src/java.base/share/classes/java/lang/reflect/Proxy.java#L531 <https://github.com/openjdk/jdk/blob/b687aa550837830b38f0f0faa69c353b1e85219c/src/java.base/share/classes/java/lang/reflect/Proxy.java#L531>>. Rather it could be named based on the interfaces it implements. I also wonder why AtomicLong is chosen in the first place.
>>>          2. Methods of the interfaces must be in a particular order.
>>>             Right now, they are not sorted in any particular order
>>>             <https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/lang/Class.java#L2178 <https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/lang/Class.java#L2178>>.
>>>
>>>
>>>         These fixes will make proxy class generation deterministic
>>>         with respect to order of loading and won't be flagged at
>>>         runtime since the test suite would already detect them.
>>>
>>>         I would love to hear from the community about these ideas. If
>>>         in agreement, I would be happy to produce a patch. I have
>>>         discovered this issue with subclasses of
>>>         GeneratedConstructorAccessor
>>>         <https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/jdk/internal/reflect/ConstructorAccessor.java <https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/jdk/internal/reflect/ConstructorAccessor.java>> as well and I imagine it will also apply to some other runtime generated classes. If you disagree, please let me know also. It helps with my research.
>>>
>>>         I also have PoCs for the above CVEs
>>>         <https://github.com/chains-project/exploits-for-sbom.exe
> <https://github.com/chains-project/exploits-for-sbom.exe>> and
>>>         a proof concept tool is being developed under the name
>>>         sbom.exe <https://github.com/chains-project/sbom.exe
> <https://github.com/chains-project/sbom.exe>> in case
>>>         any one wonders about the implementation. I would also be
>>>         happy to explain more.
>>>
>>>         Regards,
>>>         Aman Sharma
>>>
>>>         PhD Student
>>>         KTH Royal Institute of Technology
>>>         School of Electrical Engineering and Computer Science (EECS)
>>>         Department of Theoretical Computer Science (TCS)
>>>         <https://www.kth.se/profile/amansha
> <https://www.kth.se/profile/amansha>>https://algomaster99.github.io/
> <https://algomaster99.github.io/ <https://algomaster99.github.io/>>
>>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240527/90801663/attachment-0001.htm>

From cushon at openjdk.org  Mon May 27 18:27:20 2024
From: cushon at openjdk.org (Liam Miller-Cushon)
Date: Mon, 27 May 2024 18:27:20 GMT
Subject: RFR: 8328821: Map.of().entrySet() mutators should throw
 UnsupportedOperationException [v2]
In-Reply-To: <np86XgOjE1gYESY--2_OXTPIvO1mvmJbD3UH-lIn9TY=.c4a288f1-0469-4cc6-a076-58bab04d24ad@github.com>
References: <np86XgOjE1gYESY--2_OXTPIvO1mvmJbD3UH-lIn9TY=.c4a288f1-0469-4cc6-a076-58bab04d24ad@github.com>
Message-ID: <J-Epz9-xlq3Ml56PdM6vH3-tGJ90P5pWr5zN661sjZY=.e93df065-4770-46ba-8444-2fbb6577e8cf@github.com>

> This change overrides mutator methods in the implementation returned by `Map.of().entrySet()` to throw `UnsupportedOperationException`.

Liam Miller-Cushon 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:

 - Check m.entrySet().hashCode() in MOAT
 - Merge remote-tracking branch 'origin/master' into JDK-8328821-make-clear-consistent
 - Use AbstractImmutableSet
 - Throw UOE for all Map.of().entrySet() mutator methods
 - 8328821: Make the ImmutableCollections clear() call consistent
   
   Without overriding clear(), a call to it in an empty map would
   just return, as iterator.hasNext() would be false. However if
   calling Map.of().clear() throws an exception. To make the
   behavior of Map.of().entrySet().clear() consistent, we need to
   have an implementation of clear() for the entry set that throws
   as well.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/18522/files
  - new: https://git.openjdk.org/jdk/pull/18522/files/42d67d16..17851d80

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18522&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18522&range=00-01

  Stats: 211051 lines in 4323 files changed: 117813 ins; 68929 del; 24309 mod
  Patch: https://git.openjdk.org/jdk/pull/18522.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18522/head:pull/18522

PR: https://git.openjdk.org/jdk/pull/18522

From cushon at openjdk.org  Mon May 27 18:27:20 2024
From: cushon at openjdk.org (Liam Miller-Cushon)
Date: Mon, 27 May 2024 18:27:20 GMT
Subject: RFR: 8328821: Map.of().entrySet() mutators should throw
 UnsupportedOperationException [v2]
In-Reply-To: <UHVWvGcW9Gog04O9WNhwTfZx_jFdhtDrLmkzVOxXXks=.5f84615e-5890-4a51-baed-a1fe02a89b5b@github.com>
References: <np86XgOjE1gYESY--2_OXTPIvO1mvmJbD3UH-lIn9TY=.c4a288f1-0469-4cc6-a076-58bab04d24ad@github.com>
 <i2k1vxw0WKnzRbVSOnDrDd0JCOuOhkreN68c7yRdJYs=.8616f12f-6515-4d98-9e98-f98b36d914ad@github.com>
 <UHVWvGcW9Gog04O9WNhwTfZx_jFdhtDrLmkzVOxXXks=.5f84615e-5890-4a51-baed-a1fe02a89b5b@github.com>
Message-ID: <8XtuDxLcKfcZIc_SsfiUxujzPcBrUJtzaST8-GKL6zo=.9be9b226-b86d-490b-8101-6679859ee51f@github.com>

On Mon, 27 May 2024 12:18:23 GMT, Chen Liang <liach at openjdk.org> wrote:

>> src/java.base/share/classes/java/util/ImmutableCollections.java line 1323:
>> 
>>> 1321:                 @Override
>>> 1322:                 public int hashCode() {
>>> 1323:                     return MapN.this.hashCode();
>> 
>> The hash code for a `Set` is defined as the sum of the elements in the `Set` (hash(`null`) == 0). The `Map. Entry` hash code is defined the same way `MapN.this.hashCode` operates so this seems right. It would be nice with a couple of tests that assert this invariant.
>> 
>> Perhaps the existing tests already cover this?
>
> Good point, this is currently missing from MOAT in Collections.
> 
> Though it can be as simple as one line here:
> https://github.com/openjdk/jdk/blob/891d5aedf12e837c9a9c7cb800fb3affa7430f00/test/jdk/java/util/Collection/MOAT.java#L1329
> 
> check(m.hashCode() == m.entrySet().hashCode());

Thanks, I added the suggested assertion.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18522#discussion_r1616313870

From prappo at openjdk.org  Mon May 27 20:55:29 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Mon, 27 May 2024 20:55:29 GMT
Subject: RFR: 8332826: Make hashCode methods in ArraysSupport friendlier
 [v2]
In-Reply-To: <ujd2AT3eYXrHPcSG0vMDe2WOx3INNPU1n0t8haKH0_M=.b1a168d7-ab4c-4920-92ef-1c72e5ffc0cf@github.com>
References: <ujd2AT3eYXrHPcSG0vMDe2WOx3INNPU1n0t8haKH0_M=.b1a168d7-ab4c-4920-92ef-1c72e5ffc0cf@github.com>
Message-ID: <1tx_tl3PV2W5NCEXXawQY5V2ndnSOHPfjisypuhKdhA=.79840096-bac0-4da4-8102-c7ecea7cb5f0@github.com>

> Please review this PR, which supersedes a now withdrawn https://github.com/openjdk/jdk/pull/14831.
> 
> This PR replaces `ArraysSupport.vectorizedHashCode` with a set of more user-friendly methods. Here's a summary:
> 
> - Made the operand constants (i.e. `T_BOOLEAN` and friends) and the `vectorizedHashCode` method private
> 
> - Made the `vectorizedHashCode` method private, but didn't rename it. Renaming would dramatically increase this PR review cost, because that method's name is used by a lot of VM code. On a bright side, since the method is now private, it's no longer callable by clients of `ArraysSupport`, thus a problem of an inaccurate name is less severe.
> 
> - Made the `ArraysSupport.utf16HashCode` method private
> 
> - Moved tiny cases (i.e. 0, 1, 2) to `ArraysSupport`

Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:

  Fix incorrect utf16 hashCode adaptation

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19414/files
  - new: https://git.openjdk.org/jdk/pull/19414/files/4ed451d6..adc7557d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19414&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19414&range=00-01

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/19414.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19414/head:pull/19414

PR: https://git.openjdk.org/jdk/pull/19414

From pminborg at openjdk.org  Tue May 28 06:37:05 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 28 May 2024 06:37:05 GMT
Subject: RFR: 8292955: Collections.checkedMap Map.merge does not properly
 check key and value [v3]
In-Reply-To: <8lChj2IPfcR2_MKvykrzNW4n2Har70v3BXEhm1xO1YU=.1828b012-a6f8-460b-b3fc-a2e8d7d33611@github.com>
References: <uYx7ZckdmpZfQzBBlp-i5gZXe1Y6lKaZ3WfynZJbdeU=.0b7fd470-f97e-40b6-989a-5fd0e5e4e179@github.com>
 <KQYW7IawS6gwsNsRrwaPkvWLfuapu-CJK6Sey-nIsNk=.4d0eeacd-5484-430f-ae99-8d5e124d4e8f@github.com>
 <8lChj2IPfcR2_MKvykrzNW4n2Har70v3BXEhm1xO1YU=.1828b012-a6f8-460b-b3fc-a2e8d7d33611@github.com>
Message-ID: <_th1c4DY28-RkweRQQ9HIRfFEQKhJre-wzUTnq-HJ7o=.5a4ac724-e230-4144-b573-93f286fa946b@github.com>

On Mon, 27 May 2024 12:40:07 GMT, Chen Liang <liach at openjdk.org> wrote:

> @minborg Is it possible for you to review this collection bugfix?

Will do! Thanks for the heads up.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18141#issuecomment-2134446236

From pminborg at openjdk.org  Tue May 28 06:43:05 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 28 May 2024 06:43:05 GMT
Subject: RFR: 8292955: Collections.checkedMap Map.merge does not properly
 check key and value [v3]
In-Reply-To: <KQYW7IawS6gwsNsRrwaPkvWLfuapu-CJK6Sey-nIsNk=.4d0eeacd-5484-430f-ae99-8d5e124d4e8f@github.com>
References: <uYx7ZckdmpZfQzBBlp-i5gZXe1Y6lKaZ3WfynZJbdeU=.0b7fd470-f97e-40b6-989a-5fd0e5e4e179@github.com>
 <KQYW7IawS6gwsNsRrwaPkvWLfuapu-CJK6Sey-nIsNk=.4d0eeacd-5484-430f-ae99-8d5e124d4e8f@github.com>
Message-ID: <fSNG0CcTG1_CMlWNQ9GNUU8hZt30Q25tZNHCN2JtXEw=.0c5ffe79-12b4-4bca-81e0-d44290f98ea5@github.com>

On Thu, 7 Mar 2024 05:33:16 GMT, Lei Zhu <duke at openjdk.org> wrote:

>> When the specified key did not associated with a value, should check the `key` and `value` type.
>
> Lei Zhu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use testNG builtin functionalities and modify the test function name

Adding the checks before remapping seems the right thing to do in order to uphold the checked maps guarantees on types and values.

-------------

Marked as reviewed by pminborg (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18141#pullrequestreview-2081881249

From duke at openjdk.org  Tue May 28 06:46:09 2024
From: duke at openjdk.org (Lei Zhu)
Date: Tue, 28 May 2024 06:46:09 GMT
Subject: Integrated: 8292955: Collections.checkedMap Map.merge does not
 properly check key and value
In-Reply-To: <uYx7ZckdmpZfQzBBlp-i5gZXe1Y6lKaZ3WfynZJbdeU=.0b7fd470-f97e-40b6-989a-5fd0e5e4e179@github.com>
References: <uYx7ZckdmpZfQzBBlp-i5gZXe1Y6lKaZ3WfynZJbdeU=.0b7fd470-f97e-40b6-989a-5fd0e5e4e179@github.com>
Message-ID: <0DmFhj_-kGklckyyfKPdKhqU86k1_AP38hMtmcnQ1j8=.a007bd1c-72de-412d-8dd8-15d451e5d1c6@github.com>

On Wed, 6 Mar 2024 18:26:16 GMT, Lei Zhu <duke at openjdk.org> wrote:

> When the specified key did not associated with a value, should check the `key` and `value` type.

This pull request has now been integrated.

Changeset: b5e1615c
Author:    Korov <korov at korov-win-laptop>
Committer: Per Minborg <pminborg at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/b5e1615c0084538f2161fe9b56748d188983e972
Stats:     12 lines in 2 files changed: 9 ins; 0 del; 3 mod

8292955: Collections.checkedMap Map.merge does not properly check key and value

Reviewed-by: gli, liach, pminborg

-------------

PR: https://git.openjdk.org/jdk/pull/18141

From duke at openjdk.org  Tue May 28 11:03:18 2024
From: duke at openjdk.org (Oussama Louati)
Date: Tue, 28 May 2024 11:03:18 GMT
Subject: RFR: 8307818: Convert Indify tool to Classfile API [v10]
In-Reply-To: <tCFk9yrCtcoBnzvNIgceY0eOaXg9ZiN9nkCuhHIyMyw=.9cc5f994-8d35-411a-bb39-7c3f2ac34dda@github.com>
References: <tCFk9yrCtcoBnzvNIgceY0eOaXg9ZiN9nkCuhHIyMyw=.9cc5f994-8d35-411a-bb39-7c3f2ac34dda@github.com>
Message-ID: <UfxoKDo2autP7ThykBrrk7_uf9LCPahZQp0kKYRzzeM=.9f921b0f-2ac6-4110-ace9-41b84913653a@github.com>

> An indify tool in j.l.i tests (also in vmTestBase) convert some source-code private static methods with MT_ MH_, and INDY_ prefixes into MethodHandle, MethodType, and CallSite constants.
> It currently uses ad-hoc code to process class files and intends to migrate to ASM; but since we have the Classfile API, we can migrate to Classfile API instead.

Oussama Louati has updated the pull request incrementally with one additional commit since the last revision:

  chore: changed pool marking initialization to be done in one pass

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/18841/files
  - new: https://git.openjdk.org/jdk/pull/18841/files/2b8c94a7..0cac912d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18841&range=09
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18841&range=08-09

  Stats: 91 lines in 1 file changed: 9 ins; 53 del; 29 mod
  Patch: https://git.openjdk.org/jdk/pull/18841.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18841/head:pull/18841

PR: https://git.openjdk.org/jdk/pull/18841

From egahlin at openjdk.org  Tue May 28 11:30:44 2024
From: egahlin at openjdk.org (Erik Gahlin)
Date: Tue, 28 May 2024 11:30:44 GMT
Subject: RFR: 8331876: JFR: Move file read and write events to java.base
 [v6]
In-Reply-To: <DDe0bKCC86AawVl7RylZ74uvvLBr2Zljpkcmxx1_WEU=.61cc10c6-b635-42dd-a850-b32ae1d68585@github.com>
References: <DDe0bKCC86AawVl7RylZ74uvvLBr2Zljpkcmxx1_WEU=.61cc10c6-b635-42dd-a850-b32ae1d68585@github.com>
Message-ID: <v9L0ksfzAWD-RLDk9Oqbjo9rhPUebfwqbUqyCGvsL1M=.50fb35ea-3a5a-4b27-a977-3e38b7e9a0f9@github.com>

> Hi,
> 
> Could I have a review of a change that moves the jdk.FileRead and jdk.FileWrite events to java.base to remove the use of the ASM instrumentation.
> 
> Testing: jdk/jdk/jfr
> 
> Thanks
> Erik

Erik Gahlin has updated the pull request incrementally with one additional commit since the last revision:

  Fix typos

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19129/files
  - new: https://git.openjdk.org/jdk/pull/19129/files/c4c64774..8a44b649

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19129&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19129&range=04-05

  Stats: 5 lines in 5 files changed: 0 ins; 0 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/19129.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19129/head:pull/19129

PR: https://git.openjdk.org/jdk/pull/19129

From duke at openjdk.org  Tue May 28 11:33:09 2024
From: duke at openjdk.org (Oussama Louati)
Date: Tue, 28 May 2024 11:33:09 GMT
Subject: RFR: 8307818: Convert Indify tool to Classfile API [v10]
In-Reply-To: <74l_lkysArBLJT8e9oXv8W0biPEPuXVwg6kBxfOjm8w=.385285ed-1d32-4a2a-9509-ace445fc94b7@github.com>
References: <tCFk9yrCtcoBnzvNIgceY0eOaXg9ZiN9nkCuhHIyMyw=.9cc5f994-8d35-411a-bb39-7c3f2ac34dda@github.com>
 <ERPRn4imTD5OFe3XL2O99rBrkNqKMqeMU5HFp4YCgo8=.c80ad962-59fe-48f4-abad-89d19e882978@github.com>
 <P-UeDJ_ZCoCcTJKZMD2eu3IAmEsC1x9PyA77gAm1D8s=.1094b8b8-a01b-487f-a62c-3dcf5f46f9e2@github.com>
 <74l_lkysArBLJT8e9oXv8W0biPEPuXVwg6kBxfOjm8w=.385285ed-1d32-4a2a-9509-ace445fc94b7@github.com>
Message-ID: <NSeqSx1DOOG7SXAXkM-5D0zARByI_JqLNTyx7RE_MFY=.8114fb58-cbcc-4157-a8fe-84cb6e8060ff@github.com>

On Fri, 24 May 2024 17:57:28 GMT, Oussama Louati <duke at openjdk.org> wrote:

>> test/jdk/java/lang/invoke/indify/Indify.java line 660:
>> 
>>> 658:          *
>>> 659:          * @return true if any marks were changed, false otherwise.
>>> 660:          */
>> 
>> This method does incremental analysis of the constant pool.
>> With Class-File API CP model it can be done in one pass, or even in no-pass and all requests to "marks" can be answered directly.
>
> Thank you for the feedback. I will look into the Class-File API CP model and apply your suggestion to perform the analysis in one pass or handle requests to "marks" directly.

Done

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18841#discussion_r1617070598

From asotona at openjdk.org  Tue May 28 11:41:14 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Tue, 28 May 2024 11:41:14 GMT
Subject: RFR: 8332457: Examine startup overheads from JDK-8294961 [v6]
In-Reply-To: <YdSsOH6RBi4-Xy1ZTpSdTqQprzvhAYIenwxWxvC6GrU=.6961b30c-2d67-49b6-aa3e-b4736be0458b@github.com>
References: <YdSsOH6RBi4-Xy1ZTpSdTqQprzvhAYIenwxWxvC6GrU=.6961b30c-2d67-49b6-aa3e-b4736be0458b@github.com>
Message-ID: <8NdOWVk9h3OFSQKd1B9zdeWlef-ehKckyqc9JZO0pEA=.bffda1a7-e500-43a8-b91a-20692aa023df@github.com>

> [JDK-8294961](https://bugs.openjdk.org/browse/JDK-8294961) changed to use classfile API for reflection proxy-generation. Actual implementation of `ProxyGenerator` is focused on performance, however it causes JDK bootstrap regressions. `ProxyGenerator.TEMPLATE` class model is statically created and each proxy class is transformed from the template.
> 
> This patch is intended to examine plain proxy generation impact on performance and JDK bootstrap (vs proxy transformation from template).
> 
> Please review.
> 
> Thank you,
> Adam

Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:

  CONDY implementation of ProxyGenerator

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19410/files
  - new: https://git.openjdk.org/jdk/pull/19410/files/3d975d28..c407e40e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19410&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19410&range=04-05

  Stats: 69 lines in 1 file changed: 8 ins; 39 del; 22 mod
  Patch: https://git.openjdk.org/jdk/pull/19410.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19410/head:pull/19410

PR: https://git.openjdk.org/jdk/pull/19410

From asotona at openjdk.org  Tue May 28 11:48:27 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Tue, 28 May 2024 11:48:27 GMT
Subject: RFR: 8332457: Examine startup overheads from JDK-8294961 [v7]
In-Reply-To: <YdSsOH6RBi4-Xy1ZTpSdTqQprzvhAYIenwxWxvC6GrU=.6961b30c-2d67-49b6-aa3e-b4736be0458b@github.com>
References: <YdSsOH6RBi4-Xy1ZTpSdTqQprzvhAYIenwxWxvC6GrU=.6961b30c-2d67-49b6-aa3e-b4736be0458b@github.com>
Message-ID: <fvdP6j3ty0crgRe_0GG7GgM8j6F9HhvKnApYhz-tTT4=.67a4290c-711d-44a4-b4e5-bf1fd17e9a11@github.com>

> [JDK-8294961](https://bugs.openjdk.org/browse/JDK-8294961) changed to use classfile API for reflection proxy-generation. Actual implementation of `ProxyGenerator` is focused on performance, however it causes JDK bootstrap regressions. `ProxyGenerator.TEMPLATE` class model is statically created and each proxy class is transformed from the template.
> 
> This patch is intended to examine plain proxy generation impact on performance and JDK bootstrap (vs proxy transformation from template).
> 
> Please review.
> 
> Thank you,
> Adam

Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:

  fixed javadoc

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19410/files
  - new: https://git.openjdk.org/jdk/pull/19410/files/c407e40e..22e87768

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19410&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19410&range=05-06

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/19410.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19410/head:pull/19410

PR: https://git.openjdk.org/jdk/pull/19410

From asotona at openjdk.org  Tue May 28 11:55:30 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Tue, 28 May 2024 11:55:30 GMT
Subject: RFR: 8332457: Examine startup overheads from JDK-8294961 [v8]
In-Reply-To: <YdSsOH6RBi4-Xy1ZTpSdTqQprzvhAYIenwxWxvC6GrU=.6961b30c-2d67-49b6-aa3e-b4736be0458b@github.com>
References: <YdSsOH6RBi4-Xy1ZTpSdTqQprzvhAYIenwxWxvC6GrU=.6961b30c-2d67-49b6-aa3e-b4736be0458b@github.com>
Message-ID: <zkwvAyZ4d0_63HGPN33h5m_H7VhzZR-ZnlLgKYCDJ7k=.4386454e-ee6f-4ba1-a543-dd83a20def88@github.com>

> [JDK-8294961](https://bugs.openjdk.org/browse/JDK-8294961) changed to use classfile API for reflection proxy-generation. Actual implementation of `ProxyGenerator` is focused on performance, however it causes JDK bootstrap regressions. `ProxyGenerator.TEMPLATE` class model is statically created and each proxy class is transformed from the template.
> 
> This patch is intended to examine plain proxy generation impact on performance and JDK bootstrap (vs proxy transformation from template).
> 
> Please review.
> 
> Thank you,
> Adam

Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:

  MTD_ cleanup

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19410/files
  - new: https://git.openjdk.org/jdk/pull/19410/files/22e87768..fe596465

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19410&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19410&range=06-07

  Stats: 5 lines in 1 file changed: 3 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/19410.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19410/head:pull/19410

PR: https://git.openjdk.org/jdk/pull/19410

From jlahoda at openjdk.org  Tue May 28 12:21:06 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Tue, 28 May 2024 12:21:06 GMT
Subject: RFR: 8332505: JEP 457: ClassRemapper forgets to remap bootstrap
 method references
In-Reply-To: <Y0fO03Ed3zbniIMZPeMK4mIVjmqCXfSYdkYtsPbXqyk=.8bd9cdde-57ca-4da8-b8f3-6fe2e1854b38@github.com>
References: <Y0fO03Ed3zbniIMZPeMK4mIVjmqCXfSYdkYtsPbXqyk=.8bd9cdde-57ca-4da8-b8f3-6fe2e1854b38@github.com>
Message-ID: <ouXX9RHJ30SSYGVXN-dyywPFMJSEjFLgNIf84wH1v4I=.c94269a9-7b36-4eda-9291-eadb2ea9b49c@github.com>

On Mon, 20 May 2024 08:03:28 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> Class-File API `ClassRemapper` component suppose to remap all classes referenced in a class file.
> Actual implementation missed remapping of bootstrap methods referenced from `invokedynamic` instructions.
> This patch fixes the remapping and adds relevant test.
> 
> Please review.
> 
> Thanks,
> Adam

Looks reasonable to me.

-------------

Marked as reviewed by jlahoda (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19299#pullrequestreview-2082624013

From egahlin at openjdk.org  Tue May 28 12:27:46 2024
From: egahlin at openjdk.org (Erik Gahlin)
Date: Tue, 28 May 2024 12:27:46 GMT
Subject: RFR: 8331876: JFR: Move file read and write events to java.base
 [v7]
In-Reply-To: <DDe0bKCC86AawVl7RylZ74uvvLBr2Zljpkcmxx1_WEU=.61cc10c6-b635-42dd-a850-b32ae1d68585@github.com>
References: <DDe0bKCC86AawVl7RylZ74uvvLBr2Zljpkcmxx1_WEU=.61cc10c6-b635-42dd-a850-b32ae1d68585@github.com>
Message-ID: <vVXLwBCh6Ze0req5niwTOO870sWFgYTOC2Tns9i2XT4=.39d39b68-03cd-4ee1-8b27-fde548da1614@github.com>

> Hi,
> 
> Could I have a review of a change that moves the jdk.FileRead and jdk.FileWrite events to java.base to remove the use of the ASM instrumentation.
> 
> Testing: jdk/jdk/jfr
> 
> Thanks
> Erik

Erik Gahlin has updated the pull request incrementally with one additional commit since the last revision:

  Reduce clutter

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19129/files
  - new: https://git.openjdk.org/jdk/pull/19129/files/8a44b649..87647f9d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19129&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19129&range=05-06

  Stats: 63 lines in 4 files changed: 0 ins; 47 del; 16 mod
  Patch: https://git.openjdk.org/jdk/pull/19129.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19129/head:pull/19129

PR: https://git.openjdk.org/jdk/pull/19129

From asotona at openjdk.org  Tue May 28 12:32:06 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Tue, 28 May 2024 12:32:06 GMT
Subject: Integrated: 8332505: JEP 457: ClassRemapper forgets to remap bootstrap
 method references
In-Reply-To: <Y0fO03Ed3zbniIMZPeMK4mIVjmqCXfSYdkYtsPbXqyk=.8bd9cdde-57ca-4da8-b8f3-6fe2e1854b38@github.com>
References: <Y0fO03Ed3zbniIMZPeMK4mIVjmqCXfSYdkYtsPbXqyk=.8bd9cdde-57ca-4da8-b8f3-6fe2e1854b38@github.com>
Message-ID: <6fTtPa-JDET_KP2yJi1VA2A2hy6CRmLHU5KpzCwmjm0=.62062944-f7f6-4dac-b232-8233c543b5b8@github.com>

On Mon, 20 May 2024 08:03:28 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> Class-File API `ClassRemapper` component suppose to remap all classes referenced in a class file.
> Actual implementation missed remapping of bootstrap methods referenced from `invokedynamic` instructions.
> This patch fixes the remapping and adds relevant test.
> 
> Please review.
> 
> Thanks,
> Adam

This pull request has now been integrated.

Changeset: aa4c83a5
Author:    Adam Sotona <asotona at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/aa4c83a5bfe146714a46fb454aafc7393d2d8453
Stats:     9 lines in 2 files changed: 4 ins; 0 del; 5 mod

8332505: JEP 457: ClassRemapper forgets to remap bootstrap method references

Reviewed-by: jlahoda

-------------

PR: https://git.openjdk.org/jdk/pull/19299

From jlahoda at openjdk.org  Tue May 28 12:34:09 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Tue, 28 May 2024 12:34:09 GMT
Subject: RFR: 8332597: Remove redundant methods from
 j.l.classfile.ClassReader API [v2]
In-Reply-To: <YBwgwtTS-iUIA2rajoQ-wPQagUe1-7kf6yKQs7yVu60=.dafff0b2-8e92-491f-a652-de02c1648c85@github.com>
References: <UWBl0HMJIC4_22TkWuBhE9kd2F_l0eiPmpIx8rexFlU=.4f905822-ed5e-41be-b9d4-601af6a55eed@github.com>
 <YBwgwtTS-iUIA2rajoQ-wPQagUe1-7kf6yKQs7yVu60=.dafff0b2-8e92-491f-a652-de02c1648c85@github.com>
Message-ID: <lT2eP4JMj3wEBLfJdd4cYOxM3IuPwXpnx8Mle8MhN6E=.abc6eda0-2f1a-4371-8f1e-ec7362f95fee@github.com>

On Fri, 24 May 2024 16:41:33 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> j.l.classfile.ClassReader instance is exposed in the Class-File API through j.l.classfile.AttributeMapper::readAttribute method only.
>> ClassReader only purpose is to serve as a tool for reading content of a custom attribute in a user-provided AttribtueMapper.
>> It contains useful set of low-level class reading methods for user to implement a custom attribute content parser.
>> 
>> However methods ClassReader::thisClassPos and ClassReader::skipAttributeHolder are not necessary for a custom attribute content parsing and so redundant in the API.
>> Class-File API implementation internally use these methods, however they should not be exposed in the API.
>> 
>> This patch removes the methods from the API.
>> 
>> Please review.
>> 
>> Thanks,
>> Adam
>
> Adam Sotona 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 JDK-8332597-classreader-redundancy
>    
>    # Conflicts:
>    #	src/java.base/share/classes/jdk/internal/classfile/impl/ClassImpl.java
>  - 8332597: Remove redundant methods from j.l.classfile.ClassReader API

Marked as reviewed by jlahoda (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/19323#pullrequestreview-2082655142

From alanb at openjdk.org  Tue May 28 13:11:08 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 28 May 2024 13:11:08 GMT
Subject: Integrated: 8332064: Implementation of Structured Concurrency (Third
 Preview)
In-Reply-To: <YKVRqYuGwAB4cPvyVacCBrrMlS-m5K1fJSGpe7hQ744=.da388230-47ff-4097-9f9c-7d590bddcb8b@github.com>
References: <YKVRqYuGwAB4cPvyVacCBrrMlS-m5K1fJSGpe7hQ744=.da388230-47ff-4097-9f9c-7d590bddcb8b@github.com>
Message-ID: <mbRoFltrqC9ucvewYDvUxgZ-b3_hzmXKca_8phv5fN4=.9459c381-3b62-4c3f-aecc-a4e10d0194fc@github.com>

On Fri, 10 May 2024 10:58:42 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> There aren't any API or implementations changes in third preview but the JEP number/title needs to be bumped for the javadoc page.

This pull request has now been integrated.

Changeset: e708d135
Author:    Alan Bateman <alanb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/e708d135e3af7e0652cdbb680388a0735582ba74
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8332064: Implementation of Structured Concurrency (Third Preview)

Reviewed-by: jpai, bpb, mcimadamore

-------------

PR: https://git.openjdk.org/jdk/pull/19175

From egahlin at openjdk.org  Tue May 28 13:18:06 2024
From: egahlin at openjdk.org (Erik Gahlin)
Date: Tue, 28 May 2024 13:18:06 GMT
Subject: RFR: 8331876: JFR: Move file read and write events to java.base
 [v3]
In-Reply-To: <3tJRzBsJk5HIVu-Vy4YpxgnOY9GcAlkYNn__mLNTqRk=.1f4d38e3-966c-4580-99d5-2f39710a7056@github.com>
References: <DDe0bKCC86AawVl7RylZ74uvvLBr2Zljpkcmxx1_WEU=.61cc10c6-b635-42dd-a850-b32ae1d68585@github.com>
 <SejX7NAvWNjrhDEN8uDf4oikQDBRclWXDg1fN5FCpkc=.7de48c6f-0af2-4bf4-a743-6e173d950d52@github.com>
 <DgjIOZTfztdSEeODuNZw5MmzsiohA82hhllWCceyPyU=.7bda36a1-e26d-4d7e-822a-e443d3cbc0df@github.com>
 <khrP38H7DBIyftQZtZt0CRXeH1ZkpOCjiRNvFTs3LSI=.fd62aba9-5153-4521-84e4-241b8a352720@github.com>
 <zGenHEqjgT6f_P_VtwfKbmzBeQoArW8MHwfAa6uVGVY=.eb912b9b-3f02-4cac-8d96-e1bdbaaea2b8@github.com>
 <wluFwF2Nhgjz-yspRYtEXIJ6jEiWm9imPd6CZlwYt6Y=.991f1032-1f5a-4762-8e5b-edc74d513e88@github.com>
 <UBAcBKmhmCkeevxrteAThIEvD8YNBWFrUa_qffEng14=.c50dbe19-3465-4385-9fe4-8c284a0b116e@github.com>
 <hCLpZtC0PzTKDqSFbBympxsb4A3Sta3G3N2Ec8JfsSs=.2c57b9ff-e81d-42a0-8384-3663b14192ca@github.com>
 <6jsW4CF22T2JlhtRKmS04_KXxr-aJxIiMyFwzWlM-pU=.b27ed11e-bd19-4823-a795-7f578b812d56@github.com>
 <HFfB0s4iYLwcSMYeKcsJvszuA0pTj1uQ-duKsmfHX4I=.a021f0d1-0e33-4a2d-a7b4-327143611a29@github.com>
 <3tJRzBsJk5HIVu-Vy4YpxgnOY9GcAlkYNn_
 _mLNTqRk=.1f4d38e3-966c-4580-99d5-2f39710a7056@github.com>
Message-ID: <sLe4jtEWRy7hyFk57ZCiMRp_K1gcOBBJch6_R-0L5SI=.cd99932c-ce9a-43b1-b019-56991edfba04@github.com>

On Fri, 24 May 2024 15:45:07 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

>> Collapsing the extra layer of methods and combining the test into
>> 
>>     if (jfrTracing && FileReadEvent.enabled())
>> 
>> would indeed keep things a little neater.
>> 
>> I'm still questioning the need for `jfrTracing` at all. There's the matter of how this boolean gets set and unset, and whether this is done in a way that comports with the memory model. Setting this aside, is the only benefit that it avoids loading an extra class at JVM startup time (without JFR)? In this case that would be the `FileReadEvent` class, which is the stub class in `jdk.internal.event`. Wouldn't this class be in the CDS archive, making it not worth the effort of bringing up this new `jfrTracing` mechanism simply to avoid loading it unnecessarily?
>> 
>> I observe that in JDK 22 some (but not all) of the event classes in `jdk.internal.event` seem to be present in the CDS archive. These include various virtual thread events.
>
> I don't think the issue is so much the overhead of loading (one or more) additional classes without JFR, even if it causes an extremely small regression, but the added overhead to JFR when trying to fix the regression. The cost of a JVMTI retransformation is perhaps 100 - 1000 times that of loading a class in the CDS archive.
> 
> I did an experiment with:
> 
> `if (FlightRecorder.enabled && FileReadEvent.enabled())`
> 
> and it passes JFR tests and tier1/tier2. I don't think `FlightRecorder.enabled` needs to be used on every event class, but it would be good to use on event classes loaded during startup, both for safety reasons (ClassCircularityError) and to lower overhead of JFR startup. The `jfrTracing` flag works as well, but it is perhaps harder to comprehend and requires an additional static boolean in every class, which does clutter things up.
> 
> I can push Alan's suggestion of uniting the checks into one if-statement. It may help to see how it  looks.
> 
> Virtual thread events are typically loaded in main, after JFR has started, and not an issue unless `jcmd JFR.start` is used, which is not that common.

Updated with Alan's suggestion to make the code more readable.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19129#discussion_r1617228065

From asotona at openjdk.org  Tue May 28 13:25:21 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Tue, 28 May 2024 13:25:21 GMT
Subject: RFR: 8320396: Class-File API ClassModel::verify should include
 checks from hotspot/share/classfile/classFileParser.cpp [v9]
In-Reply-To: <Kdd6IcPvA1Xn-444dkSMQN5HVRCMn2JmgqjQZbNQ9yc=.f7198271-db19-415a-99df-7c0c9e014252@github.com>
References: <0a66asWcJ4_zBrjmReA18BZmsovN1ZeJRRSAPZDMZmo=.5bada03f-d88d-46cd-962d-c1e42c3048c1@github.com>
 <Kdd6IcPvA1Xn-444dkSMQN5HVRCMn2JmgqjQZbNQ9yc=.f7198271-db19-415a-99df-7c0c9e014252@github.com>
Message-ID: <SHgfrexSc3-WLJC0WtZTBUuE9siQOBG6O6O4pETYB8g=.6fc4e0b8-4175-4d74-8ab0-f9d699b74c70@github.com>

On Fri, 24 May 2024 16:17:41 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> ClassFile API `jdk.internal.classfile.verifier.VerifierImpl` performed only bytecode-level class verification.
>> This patch adds `jdk.internal.classfile.verifier.ParserVerifier` with additional class checks inspired by `hotspot/share/classfile/classFileParser.cpp`.
>> 
>> Also new `VerifierSelfTest::testParserVerifier` has been added.
>> 
>> Please review.
>> 
>> Thanks,
>> Adam
>
> Adam Sotona has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 37 commits:
> 
>  - fixed ParserVerifier and VerifierSelfTest
>  - Merge branch 'master' into JDK-8320396-verifier-extension
>  - added verification of TypeAnnotation attributes
>  - added verification of SMT attribute
>  - added verification of module-related attributes
>  - applied the suggested changes
>  - applied the suggested changes
>  - fixed error thrown by VerifierImpl
>  - applied suggested changes
>  - Merge branch 'master' into JDK-8320396-verifier-extension
>  - ... and 27 more: https://git.openjdk.org/jdk/compare/cfdc64fc...b352b794

Please review!

This verifier extension is actually blocking new `javap` feature for 23, see:  https://github.com/openjdk/jdk/pull/18629 
Missing all of these class file verifications in `javap -verify` would be sad.

Thank you!

Adam

-------------

PR Comment: https://git.openjdk.org/jdk/pull/16809#issuecomment-2135209023

From liach at openjdk.org  Tue May 28 13:27:06 2024
From: liach at openjdk.org (Chen Liang)
Date: Tue, 28 May 2024 13:27:06 GMT
Subject: RFR: 8332457: Examine startup overheads from JDK-8294961 [v8]
In-Reply-To: <zkwvAyZ4d0_63HGPN33h5m_H7VhzZR-ZnlLgKYCDJ7k=.4386454e-ee6f-4ba1-a543-dd83a20def88@github.com>
References: <YdSsOH6RBi4-Xy1ZTpSdTqQprzvhAYIenwxWxvC6GrU=.6961b30c-2d67-49b6-aa3e-b4736be0458b@github.com>
 <zkwvAyZ4d0_63HGPN33h5m_H7VhzZR-ZnlLgKYCDJ7k=.4386454e-ee6f-4ba1-a543-dd83a20def88@github.com>
Message-ID: <QJZnmA28sxeUotCL5qDMvEMqVTvDzldJEZqvo8TGH78=.e5e4f8bb-d589-4af7-9c42-63a4365b7164@github.com>

On Tue, 28 May 2024 11:55:30 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> [JDK-8294961](https://bugs.openjdk.org/browse/JDK-8294961) changed to use classfile API for reflection proxy-generation. Actual implementation of `ProxyGenerator` is focused on performance, however it causes JDK bootstrap regressions. `ProxyGenerator.TEMPLATE` class model is statically created and each proxy class is transformed from the template.
>> 
>> This patch is intended to examine plain proxy generation impact on performance and JDK bootstrap (vs proxy transformation from template).
>> 
>> Please review.
>> 
>> Thank you,
>> Adam
>
> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
> 
>   MTD_ cleanup

Nice work migrating method object initialization to condy.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19410#issuecomment-2135212751

From liach at openjdk.org  Tue May 28 13:32:05 2024
From: liach at openjdk.org (Chen Liang)
Date: Tue, 28 May 2024 13:32:05 GMT
Subject: RFR: 8320396: Class-File API ClassModel::verify should include
 checks from hotspot/share/classfile/classFileParser.cpp [v9]
In-Reply-To: <Kdd6IcPvA1Xn-444dkSMQN5HVRCMn2JmgqjQZbNQ9yc=.f7198271-db19-415a-99df-7c0c9e014252@github.com>
References: <0a66asWcJ4_zBrjmReA18BZmsovN1ZeJRRSAPZDMZmo=.5bada03f-d88d-46cd-962d-c1e42c3048c1@github.com>
 <Kdd6IcPvA1Xn-444dkSMQN5HVRCMn2JmgqjQZbNQ9yc=.f7198271-db19-415a-99df-7c0c9e014252@github.com>
Message-ID: <p9M176NgHSEKGDas3byVW-aJRnSiUOHn5QlUj4FlfJc=.747fb87a-cc20-4ba4-b4e7-bf71a7a47d37@github.com>

On Fri, 24 May 2024 16:17:41 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> ClassFile API `jdk.internal.classfile.verifier.VerifierImpl` performed only bytecode-level class verification.
>> This patch adds `jdk.internal.classfile.verifier.ParserVerifier` with additional class checks inspired by `hotspot/share/classfile/classFileParser.cpp`.
>> 
>> Also new `VerifierSelfTest::testParserVerifier` has been added.
>> 
>> Please review.
>> 
>> Thanks,
>> Adam
>
> Adam Sotona has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 37 commits:
> 
>  - fixed ParserVerifier and VerifierSelfTest
>  - Merge branch 'master' into JDK-8320396-verifier-extension
>  - added verification of TypeAnnotation attributes
>  - added verification of SMT attribute
>  - added verification of module-related attributes
>  - applied the suggested changes
>  - applied the suggested changes
>  - fixed error thrown by VerifierImpl
>  - applied suggested changes
>  - Merge branch 'master' into JDK-8320396-verifier-extension
>  - ... and 27 more: https://git.openjdk.org/jdk/compare/cfdc64fc...b352b794

Marked as reviewed by liach (Author).

-------------

PR Review: https://git.openjdk.org/jdk/pull/16809#pullrequestreview-2082798275

From alanb at openjdk.org  Tue May 28 13:43:03 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 28 May 2024 13:43:03 GMT
Subject: RFR: 8331876: JFR: Move file read and write events to java.base
 [v7]
In-Reply-To: <vVXLwBCh6Ze0req5niwTOO870sWFgYTOC2Tns9i2XT4=.39d39b68-03cd-4ee1-8b27-fde548da1614@github.com>
References: <DDe0bKCC86AawVl7RylZ74uvvLBr2Zljpkcmxx1_WEU=.61cc10c6-b635-42dd-a850-b32ae1d68585@github.com>
 <vVXLwBCh6Ze0req5niwTOO870sWFgYTOC2Tns9i2XT4=.39d39b68-03cd-4ee1-8b27-fde548da1614@github.com>
Message-ID: <l60biqfyhDziMfdXmVTkvE98Io9a-znImLk_WFU_IkI=.6209da9a-18d9-484d-9176-281417a50a0c@github.com>

On Tue, 28 May 2024 12:27:46 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

>> Hi,
>> 
>> Could I have a review of a change that moves the jdk.FileRead and jdk.FileWrite events to java.base to remove the use of the ASM instrumentation.
>> 
>> Testing: jdk/jdk/jfr
>> 
>> Thanks
>> Erik
>
> Erik Gahlin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reduce clutter

I think this looks okay for now and great to see the instrumentation going away.

Follow-on work for the future will be to re-examine the issue with the plan read of the flag (which seems to have previously existed) and to see if we reduce this down to one test rather than two.

-------------

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19129#pullrequestreview-2082828370

From liach at openjdk.org  Tue May 28 14:00:02 2024
From: liach at openjdk.org (Chen Liang)
Date: Tue, 28 May 2024 14:00:02 GMT
Subject: RFR: 8332457: Examine startup overheads from JDK-8294961 [v8]
In-Reply-To: <zkwvAyZ4d0_63HGPN33h5m_H7VhzZR-ZnlLgKYCDJ7k=.4386454e-ee6f-4ba1-a543-dd83a20def88@github.com>
References: <YdSsOH6RBi4-Xy1ZTpSdTqQprzvhAYIenwxWxvC6GrU=.6961b30c-2d67-49b6-aa3e-b4736be0458b@github.com>
 <zkwvAyZ4d0_63HGPN33h5m_H7VhzZR-ZnlLgKYCDJ7k=.4386454e-ee6f-4ba1-a543-dd83a20def88@github.com>
Message-ID: <3rM80fM5Kf0Dqp7xC4ZamAMmsrP2QDQBFeehNgozXj4=.4831ec4d-6c1a-44ff-9cbd-e065d789641a@github.com>

On Tue, 28 May 2024 11:55:30 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> [JDK-8294961](https://bugs.openjdk.org/browse/JDK-8294961) changed to use classfile API for reflection proxy-generation. Actual implementation of `ProxyGenerator` is focused on performance, however it causes JDK bootstrap regressions. `ProxyGenerator.TEMPLATE` class model is statically created and each proxy class is transformed from the template.
>> 
>> This patch is intended to examine plain proxy generation impact on performance and JDK bootstrap (vs proxy transformation from template).
>> 
>> The generated proxy is migrated from static initialization to CONDY bootstrap.
>> 
>> Please review.
>> 
>> Thank you,
>> Adam
>
> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
> 
>   MTD_ cleanup

Marked as reviewed by liach (Author).

-------------

PR Review: https://git.openjdk.org/jdk/pull/19410#pullrequestreview-2082875192

From mdoerr at openjdk.org  Tue May 28 14:06:25 2024
From: mdoerr at openjdk.org (Martin Doerr)
Date: Tue, 28 May 2024 14:06:25 GMT
Subject: RFR: 8332228: TypePollution.java: Unrecognized VM option
 'UseSecondarySuperCache'
Message-ID: <EW0ZlYhOWfRYoAx1ZrgBYwN4IYbz87ea_OPBL_hvEUU=.2b88c7e4-86a4-4b43-9539-27d5eef051f8@github.com>

Fix obvious typo in micro benchmark.

-------------

Commit messages:
 - 8332228: TypePollution.java: Unrecognized VM option 'UseSecondarySuperCache'

Changes: https://git.openjdk.org/jdk/pull/19427/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19427&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8332228
  Stats: 8 lines in 1 file changed: 0 ins; 0 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/19427.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19427/head:pull/19427

PR: https://git.openjdk.org/jdk/pull/19427

From asotona at openjdk.org  Tue May 28 14:56:35 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Tue, 28 May 2024 14:56:35 GMT
Subject: RFR: 8332457: Examine startup overheads from JDK-8294961 [v9]
In-Reply-To: <YdSsOH6RBi4-Xy1ZTpSdTqQprzvhAYIenwxWxvC6GrU=.6961b30c-2d67-49b6-aa3e-b4736be0458b@github.com>
References: <YdSsOH6RBi4-Xy1ZTpSdTqQprzvhAYIenwxWxvC6GrU=.6961b30c-2d67-49b6-aa3e-b4736be0458b@github.com>
Message-ID: <8EEHmjOEj1Zt0CaU5B35ad0grxLFhZasfS9Zuhdg5kk=.f061d51a-cd7a-449b-a08e-9dd39d87740c@github.com>

> [JDK-8294961](https://bugs.openjdk.org/browse/JDK-8294961) changed to use classfile API for reflection proxy-generation. Actual implementation of `ProxyGenerator` is focused on performance, however it causes JDK bootstrap regressions. `ProxyGenerator.TEMPLATE` class model is statically created and each proxy class is transformed from the template.
> 
> This patch is intended to examine plain proxy generation impact on performance and JDK bootstrap (vs proxy transformation from template).
> 
> The generated proxy is migrated from static initialization to CONDY bootstrap.
> 
> Please review.
> 
> Thank you,
> Adam

Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:

  removed obsolete entry

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19410/files
  - new: https://git.openjdk.org/jdk/pull/19410/files/fe596465..b3f6be89

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19410&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19410&range=07-08

  Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/19410.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19410/head:pull/19410

PR: https://git.openjdk.org/jdk/pull/19410

From mullan at openjdk.org  Tue May 28 14:58:12 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Tue, 28 May 2024 14:58:12 GMT
Subject: RFR: 8330542: Template for Creating Strict JAXP Configuration File
 [v14]
In-Reply-To: <-xQutVfz6r3JPZZnkO71_iimpzxhNvdoX8cpz8E7-X8=.5867b83a-ec89-4c69-ac7c-6bc11caeb93e@github.com>
References: <v1bAYKgH9zfooXpvnBw4Vu2TIqHuKqqtSmgB0hiNp-Q=.31661a99-ecfc-4a05-8045-67b5f680db60@github.com>
 <-xQutVfz6r3JPZZnkO71_iimpzxhNvdoX8cpz8E7-X8=.5867b83a-ec89-4c69-ac7c-6bc11caeb93e@github.com>
Message-ID: <sV-F99ivq26IC42Z1QdTxjG8Jen8Eot0tLuXA7GUWAI=.701617a9-653c-4ff2-8328-d6fa9dcbbf26@github.com>

On Fri, 24 May 2024 16:36:32 GMT, Joe Wang <joehw at openjdk.org> wrote:

>> Add two sample configuration files:
>> 
>>   jaxp-strict.properties: used to set strict configuration, stricter than jaxp.properties in previous versions such as JDK 22
>> 
>>>   jaxp-compat.properties: used to regain compatibility from any more restricted configuration than previous versions such as JDK 22
>> 
>> Updated on 5/16/2024
>> 
>> Design change:
>> The design is changed to include in the JDK two configuration files that are the default jaxp.properties and jaxp-strict.properties, instead of three, dropping jaxp-compat.properties.
>> 
>> Updated on 5/18/2024
>> 
>> Withdraw changes to jaxp.properties. The original idea was to match jaxp-strict.properties with regard to the properties. However, that change impact the configuration process, resulting in tests that verify the process to fail.
>> 
>> Updated on 5/23/2024
>> 
>> Provide a template `jaxp-strict.template` instead of a properties file. This template can be used to create custom configuration files.
>
> Joe Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   rename the template to jaxp-strict.properties.template

Just some wording suggestions.

src/java.xml/share/conf/jaxp-strict.properties.template line 36:

> 34: # This property determines whether XSLT and XPath extension functions are allowed.
> 35: # The value type is boolean and the default value is true (allowing
> 36: # extension functions). The following entry would override the default value and

I prefer the latter wording suggestion as in other places like the Limits section, you use present tense, which I also think sounds better.

s/would/will/ 
or 
s/would override/overrides/
s/disallow/disallows/

src/java.xml/share/conf/jaxp-strict.properties.template line 44:

> 42: # Overriding the default parser:
> 43: #
> 44: # This property allows using a third party implementation to override the default

s/using a third party implementation/a third party implementation/

src/java.xml/share/conf/jaxp-strict.properties.template line 60:

> 58: #     strict -- indicates that the resolver should throw a CatalogException
> 59: #
> 60: # The following setting would cause the resolve to throw a CatalogException when

s/would/will/ 
or 
s/would cause/causes/

s/resolve/CatalogResolver/ ?

src/java.xml/share/conf/jaxp-strict.properties.template line 67:

> 65: # Implementation Specific Properties - DTD
> 66: #
> 67: # This property instructs the parsers to: deny, ignore or allow DTD processing.

s/to:/to/

src/java.xml/share/conf/jaxp-strict.properties.template line 68:

> 66: #
> 67: # This property instructs the parsers to: deny, ignore or allow DTD processing.
> 68: # The following setting would cause the parser to reject DTD by throwing an exception.

s/would/will/
or
s/would cause/causes/

s/DTD/DTDs/

src/java.xml/share/conf/jaxp.properties line 1:

> 1: ################################################################################

Similar wording suggestions as in the `jaxp-strict.properties.template` file.

-------------

PR Review: https://git.openjdk.org/jdk/pull/18831#pullrequestreview-2083052633
PR Review Comment: https://git.openjdk.org/jdk/pull/18831#discussion_r1617388223
PR Review Comment: https://git.openjdk.org/jdk/pull/18831#discussion_r1617389854
PR Review Comment: https://git.openjdk.org/jdk/pull/18831#discussion_r1617392917
PR Review Comment: https://git.openjdk.org/jdk/pull/18831#discussion_r1617394277
PR Review Comment: https://git.openjdk.org/jdk/pull/18831#discussion_r1617395992
PR Review Comment: https://git.openjdk.org/jdk/pull/18831#discussion_r1617407662

From chagedorn at openjdk.org  Tue May 28 15:01:02 2024
From: chagedorn at openjdk.org (Christian Hagedorn)
Date: Tue, 28 May 2024 15:01:02 GMT
Subject: RFR: 8332228: TypePollution.java: Unrecognized VM option
 'UseSecondarySuperCache'
In-Reply-To: <EW0ZlYhOWfRYoAx1ZrgBYwN4IYbz87ea_OPBL_hvEUU=.2b88c7e4-86a4-4b43-9539-27d5eef051f8@github.com>
References: <EW0ZlYhOWfRYoAx1ZrgBYwN4IYbz87ea_OPBL_hvEUU=.2b88c7e4-86a4-4b43-9539-27d5eef051f8@github.com>
Message-ID: <buJFjbJQG6EcZ4FrzV9eWSz_9dBOf5tLylY9CkP7icA=.017a1925-c620-46bd-925e-ba23f6d9fb26@github.com>

On Tue, 28 May 2024 14:01:44 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

> Fix obvious typo in micro benchmark.

Looks good and trivial!

-------------

Marked as reviewed by chagedorn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19427#pullrequestreview-2083086912

From mdoerr at openjdk.org  Tue May 28 15:01:02 2024
From: mdoerr at openjdk.org (Martin Doerr)
Date: Tue, 28 May 2024 15:01:02 GMT
Subject: RFR: 8332228: TypePollution.java: Unrecognized VM option
 'UseSecondarySuperCache'
In-Reply-To: <EW0ZlYhOWfRYoAx1ZrgBYwN4IYbz87ea_OPBL_hvEUU=.2b88c7e4-86a4-4b43-9539-27d5eef051f8@github.com>
References: <EW0ZlYhOWfRYoAx1ZrgBYwN4IYbz87ea_OPBL_hvEUU=.2b88c7e4-86a4-4b43-9539-27d5eef051f8@github.com>
Message-ID: <31R6Qxgzx0ykcomNZ0i3M7wlRPjUknBQMEUII71yo98=.6853a244-c87d-4c86-8522-005c85a4d372@github.com>

On Tue, 28 May 2024 14:01:44 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

> Fix obvious typo in micro benchmark.

Thanks for the review!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19427#issuecomment-2135446758

From alanb at openjdk.org  Tue May 28 15:09:09 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 28 May 2024 15:09:09 GMT
Subject: Integrated: 8331670: Deprecate the Memory-Access Methods in
 sun.misc.Unsafe for Removal
In-Reply-To: <9FyO4QpCtH2CNkUEE78_Jjd9xs3bv3WJo16jyowHOvY=.e7131b91-37bb-4624-a60e-72a427a24c92@github.com>
References: <9FyO4QpCtH2CNkUEE78_Jjd9xs3bv3WJo16jyowHOvY=.e7131b91-37bb-4624-a60e-72a427a24c92@github.com>
Message-ID: <74mNNB6--TZMU5Mr7A4--VpvEYNdsoYSU_tVZo2mTSg=.14ab58f6-8101-40dd-83e7-87446c79c055@github.com>

On Fri, 10 May 2024 10:06:55 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> This is the implementation changes for JEP 471.
> 
> The methods in sun.misc.Unsafe for on-heap and off-heap access are deprecated for removal. This means a removal warning at compile time. No methods have been removed. A deprecated message is added to each of the methods but unlikely to be seen as the JDK does not generate or publish the API docs for this class.
> 
> A new command line option --sun-misc-unsafe-memory-access=$value is introduced to allow or deny access to these methods. The default proposed for JDK 23 is "allow" so no change in behavior compared to JDK 22 or previous releases.
> 
> A new test is added to test the command line option settings. The existing micros for FFM that use Unsafe are updated to suppress the removal warning at compile time. A new micro is introduced with a small sample of methods to ensure the changes doesn't cause any perf regressions ([sample results](https://cr.openjdk.org/~alanb/8331670-results.txt)).
> 
> For now, the changes include the update to the man page for the "java" command. It might be that this has to be separated out so that it goes with other updates in the release.

This pull request has now been integrated.

Changeset: 0f3e2cc3
Author:    Alan Bateman <alanb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/0f3e2cc334e5926d53bbbce22e4a6bfeb2752140
Stats:     1234 lines in 8 files changed: 1150 ins; 5 del; 79 mod

8331670: Deprecate the Memory-Access Methods in sun.misc.Unsafe for Removal

Reviewed-by: mcimadamore, jpai, pminborg

-------------

PR: https://git.openjdk.org/jdk/pull/19174

From liach at openjdk.org  Tue May 28 15:14:02 2024
From: liach at openjdk.org (Chen Liang)
Date: Tue, 28 May 2024 15:14:02 GMT
Subject: RFR: 8332457: Examine startup overheads from JDK-8294961 [v9]
In-Reply-To: <8EEHmjOEj1Zt0CaU5B35ad0grxLFhZasfS9Zuhdg5kk=.f061d51a-cd7a-449b-a08e-9dd39d87740c@github.com>
References: <YdSsOH6RBi4-Xy1ZTpSdTqQprzvhAYIenwxWxvC6GrU=.6961b30c-2d67-49b6-aa3e-b4736be0458b@github.com>
 <8EEHmjOEj1Zt0CaU5B35ad0grxLFhZasfS9Zuhdg5kk=.f061d51a-cd7a-449b-a08e-9dd39d87740c@github.com>
Message-ID: <-bZbxEBVvFmHB1d6XJztRM9Tq97_W9mXSCVy_ybrD_4=.7bb722e7-9a4c-468c-863a-9f57c33903d5@github.com>

On Tue, 28 May 2024 14:56:35 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> [JDK-8294961](https://bugs.openjdk.org/browse/JDK-8294961) changed to use classfile API for reflection proxy-generation. Actual implementation of `ProxyGenerator` is focused on performance, however it causes JDK bootstrap regressions. `ProxyGenerator.TEMPLATE` class model is statically created and each proxy class is transformed from the template.
>> 
>> This patch is intended to examine plain proxy generation impact on performance and JDK bootstrap (vs proxy transformation from template).
>> 
>> The generated proxy is migrated from static initialization to CONDY bootstrap.
>> 
>> Please review.
>> 
>> Thank you,
>> Adam
>
> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
> 
>   removed obsolete entry

src/java.base/share/classes/java/lang/reflect/ProxyGenerator.java line 676:

> 674:                                 toClassDesc(fromClass),
> 675:                                 method.getName(),
> 676:                                 MethodType.methodType(method.getReturnType(), method.getParameterTypes()).describeConstable().get()));

Suggestion:

                                desc);

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19410#discussion_r1617457062

From asotona at openjdk.org  Tue May 28 15:19:15 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Tue, 28 May 2024 15:19:15 GMT
Subject: RFR: 8332457: Examine startup overheads from JDK-8294961 [v10]
In-Reply-To: <YdSsOH6RBi4-Xy1ZTpSdTqQprzvhAYIenwxWxvC6GrU=.6961b30c-2d67-49b6-aa3e-b4736be0458b@github.com>
References: <YdSsOH6RBi4-Xy1ZTpSdTqQprzvhAYIenwxWxvC6GrU=.6961b30c-2d67-49b6-aa3e-b4736be0458b@github.com>
Message-ID: <b0iWEr5_zp-3ziMVfhhPpBI-fSPGCTAtvzj0dVsXeQ4=.aca996ea-b54e-4b8a-828a-ccbd5db8b2f8@github.com>

> [JDK-8294961](https://bugs.openjdk.org/browse/JDK-8294961) changed to use classfile API for reflection proxy-generation. Actual implementation of `ProxyGenerator` is focused on performance, however it causes JDK bootstrap regressions. `ProxyGenerator.TEMPLATE` class model is statically created and each proxy class is transformed from the template.
> 
> This patch is intended to examine plain proxy generation impact on performance and JDK bootstrap (vs proxy transformation from template).
> 
> The generated proxy is migrated from static initialization to CONDY bootstrap.
> 
> Please review.
> 
> Thank you,
> Adam

Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:

  Update src/java.base/share/classes/java/lang/reflect/ProxyGenerator.java
  
  Co-authored-by: liach <7806504+liach at users.noreply.github.com>

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19410/files
  - new: https://git.openjdk.org/jdk/pull/19410/files/b3f6be89..9ce8377c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19410&range=09
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19410&range=08-09

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/19410.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19410/head:pull/19410

PR: https://git.openjdk.org/jdk/pull/19410

From asotona at openjdk.org  Tue May 28 15:19:16 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Tue, 28 May 2024 15:19:16 GMT
Subject: RFR: 8332457: Examine startup overheads from JDK-8294961 [v9]
In-Reply-To: <-bZbxEBVvFmHB1d6XJztRM9Tq97_W9mXSCVy_ybrD_4=.7bb722e7-9a4c-468c-863a-9f57c33903d5@github.com>
References: <YdSsOH6RBi4-Xy1ZTpSdTqQprzvhAYIenwxWxvC6GrU=.6961b30c-2d67-49b6-aa3e-b4736be0458b@github.com>
 <8EEHmjOEj1Zt0CaU5B35ad0grxLFhZasfS9Zuhdg5kk=.f061d51a-cd7a-449b-a08e-9dd39d87740c@github.com>
 <-bZbxEBVvFmHB1d6XJztRM9Tq97_W9mXSCVy_ybrD_4=.7bb722e7-9a4c-468c-863a-9f57c33903d5@github.com>
Message-ID: <1IKWTLZGYdDu4U4W0EmQMHlhKWoEZ459RTDHnAxI_MM=.9266a536-29aa-4bbd-babf-5c4cda6b9432@github.com>

On Tue, 28 May 2024 15:11:39 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   removed obsolete entry
>
> src/java.base/share/classes/java/lang/reflect/ProxyGenerator.java line 676:
> 
>> 674:                                 toClassDesc(fromClass),
>> 675:                                 method.getName(),
>> 676:                                 MethodType.methodType(method.getReturnType(), method.getParameterTypes()).describeConstable().get()));
> 
> Suggestion:
> 
>                                 desc);

good catch :)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19410#discussion_r1617486750

From asotona at openjdk.org  Tue May 28 15:23:15 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Tue, 28 May 2024 15:23:15 GMT
Subject: RFR: 8332457: Examine startup overheads from JDK-8294961 [v11]
In-Reply-To: <YdSsOH6RBi4-Xy1ZTpSdTqQprzvhAYIenwxWxvC6GrU=.6961b30c-2d67-49b6-aa3e-b4736be0458b@github.com>
References: <YdSsOH6RBi4-Xy1ZTpSdTqQprzvhAYIenwxWxvC6GrU=.6961b30c-2d67-49b6-aa3e-b4736be0458b@github.com>
Message-ID: <lR7ECrrN6x9rDA90_CR3QI7zuhMTQObX848nxIHXiEE=.ef381262-f618-4ed4-b539-b6c9b8eb94c3@github.com>

> [JDK-8294961](https://bugs.openjdk.org/browse/JDK-8294961) changed to use classfile API for reflection proxy-generation. Actual implementation of `ProxyGenerator` is focused on performance, however it causes JDK bootstrap regressions. `ProxyGenerator.TEMPLATE` class model is statically created and each proxy class is transformed from the template.
> 
> This patch is intended to examine plain proxy generation impact on performance and JDK bootstrap (vs proxy transformation from template).
> 
> The generated proxy is migrated from static initialization to CONDY bootstrap.
> 
> Please review.
> 
> Thank you,
> Adam

Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:

  missing bracket

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19410/files
  - new: https://git.openjdk.org/jdk/pull/19410/files/9ce8377c..24b60451

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19410&range=10
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19410&range=09-10

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/19410.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19410/head:pull/19410

PR: https://git.openjdk.org/jdk/pull/19410

From kvn at openjdk.org  Tue May 28 15:55:05 2024
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Tue, 28 May 2024 15:55:05 GMT
Subject: RFR: 8332228: TypePollution.java: Unrecognized VM option
 'UseSecondarySuperCache'
In-Reply-To: <EW0ZlYhOWfRYoAx1ZrgBYwN4IYbz87ea_OPBL_hvEUU=.2b88c7e4-86a4-4b43-9539-27d5eef051f8@github.com>
References: <EW0ZlYhOWfRYoAx1ZrgBYwN4IYbz87ea_OPBL_hvEUU=.2b88c7e4-86a4-4b43-9539-27d5eef051f8@github.com>
Message-ID: <bD_S80EDe3hsD1jPEiRHRYtPEe8YKxTSTJDX2jA94lE=.1c987d8e-33c6-4631-8f4c-564af996e5f2@github.com>

On Tue, 28 May 2024 14:01:44 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

> Fix obvious typo in micro benchmark.

Good.

-------------

Marked as reviewed by kvn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19427#pullrequestreview-2083281226

From sgibbons at openjdk.org  Tue May 28 16:03:16 2024
From: sgibbons at openjdk.org (Scott Gibbons)
Date: Tue, 28 May 2024 16:03:16 GMT
Subject: RFR: 8320448: Accelerate IndexOf using AVX2 [v38]
In-Reply-To: <MImPmWGxi3FpwVq1rk0Rohfh3_5H_iqAgblEpn8_TQQ=.cbb5359c-d8df-48b8-8a0f-e9976923475f@github.com>
References: <uWi4QxH31hL93771gkl_GgvP0m84IRSoR_1Yi8hD17E=.bc6ed458-7081-4c3f-9348-f59358fa05a4@github.com>
 <nDwq515-pZGnnCsqW0nkRtlqIyhnvqKXFTydeaXztHo=.eb511293-d67b-4a06-b792-264087af40d0@github.com>
 <MImPmWGxi3FpwVq1rk0Rohfh3_5H_iqAgblEpn8_TQQ=.cbb5359c-d8df-48b8-8a0f-e9976923475f@github.com>
Message-ID: <DEIgE5V0yqkQUTe5KWlFvLmApPYpP2JGMcUlpkuvt4U=.89e9cddd-3a3c-445b-9080-cb0eaca0a963@github.com>

On Fri, 24 May 2024 20:12:07 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> Scott Gibbons has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Test clarifications
>
> test/jdk/java/lang/StringBuffer/IndexOf.java line 28:
> 
>> 26:  * @summary Test indexOf and lastIndexOf
>> 27:  * @run main/othervm IndexOf
>> 28:  * @run main/othervm -XX:+IgnoreUnrecognizedVMOptions -Xcomp -XX:-TieredCompilation -XX:UseAVX=2 -XX:+UnlockDiagnosticVMOptions -XX:+EnableX86ECoreOpts IndexOf
> 
> I suggest to split it into 2 subtest jobs and use `@requires vm.cpu.features ~= ".*avx2.*"` for second which specified `-XX:UseAVX=2`.
> See `compiler/loopopts/superword/TestDependencyOffsets.java` for example.

@vnkozlov I'm getting an error in CI tests with this line added.  Can you please advise?

`TEST RESULT: Error. Parse Exception: Syntax error in @requires expression: invalid name: vm.cpu.features`

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1617556335

From naoto at openjdk.org  Tue May 28 16:06:12 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 28 May 2024 16:06:12 GMT
Subject: RFR: 8330542: Template for Creating Strict JAXP Configuration File
 [v14]
In-Reply-To: <-xQutVfz6r3JPZZnkO71_iimpzxhNvdoX8cpz8E7-X8=.5867b83a-ec89-4c69-ac7c-6bc11caeb93e@github.com>
References: <v1bAYKgH9zfooXpvnBw4Vu2TIqHuKqqtSmgB0hiNp-Q=.31661a99-ecfc-4a05-8045-67b5f680db60@github.com>
 <-xQutVfz6r3JPZZnkO71_iimpzxhNvdoX8cpz8E7-X8=.5867b83a-ec89-4c69-ac7c-6bc11caeb93e@github.com>
Message-ID: <__L9xATnjfcEu_zrbjjbL1Pf_01AuhcmeHOY1XEwXxI=.89c23772-de9c-48d5-9707-7650039e28fc@github.com>

On Fri, 24 May 2024 16:36:32 GMT, Joe Wang <joehw at openjdk.org> wrote:

>> Add two sample configuration files:
>> 
>>   jaxp-strict.properties: used to set strict configuration, stricter than jaxp.properties in previous versions such as JDK 22
>> 
>>>   jaxp-compat.properties: used to regain compatibility from any more restricted configuration than previous versions such as JDK 22
>> 
>> Updated on 5/16/2024
>> 
>> Design change:
>> The design is changed to include in the JDK two configuration files that are the default jaxp.properties and jaxp-strict.properties, instead of three, dropping jaxp-compat.properties.
>> 
>> Updated on 5/18/2024
>> 
>> Withdraw changes to jaxp.properties. The original idea was to match jaxp-strict.properties with regard to the properties. However, that change impact the configuration process, resulting in tests that verify the process to fail.
>> 
>> Updated on 5/23/2024
>> 
>> Provide a template `jaxp-strict.template` instead of a properties file. This template can be used to create custom configuration files.
>
> Joe Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   rename the template to jaxp-strict.properties.template

LGTM

test/jaxp/javax/xml/jaxp/unittest/common/config/ConfigFileTest.java line 41:

> 39:  * @run driver common.config.ConfigFileTest 0 // verifies jaxp.properties
> 40:  * @run driver common.config.ConfigFileTest 1 // verifies jaxp-strict.properties.template
> 41:  * @summary verifies the default JAXP configuration file jaxp.properties and

Summary would read better after the @test tag

-------------

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18831#pullrequestreview-2079802647
PR Review Comment: https://git.openjdk.org/jdk/pull/18831#discussion_r1615343327

From sgibbons at openjdk.org  Tue May 28 16:06:16 2024
From: sgibbons at openjdk.org (Scott Gibbons)
Date: Tue, 28 May 2024 16:06:16 GMT
Subject: RFR: 8320448: Accelerate IndexOf using AVX2 [v41]
In-Reply-To: <PWJcJvCQOtmwRGr0paU-uIQYjeBLhsU-JI_VdkIpLOo=.c36bcb0d-43dd-4277-84d0-a1506bd9e15b@github.com>
References: <uWi4QxH31hL93771gkl_GgvP0m84IRSoR_1Yi8hD17E=.bc6ed458-7081-4c3f-9348-f59358fa05a4@github.com>
 <atTesjhro2xH1gQek1JHVwgQiERxY_XbAna9KXmcHBA=.0a359fe5-aacf-483d-bc7c-6357afbd2da7@github.com>
 <PWJcJvCQOtmwRGr0paU-uIQYjeBLhsU-JI_VdkIpLOo=.c36bcb0d-43dd-4277-84d0-a1506bd9e15b@github.com>
Message-ID: <DHEe55jk51zkJav-Q0Aq4120dInC4L77wjRpJDK9Iw0=.720bc7d4-ab0c-4a90-b0aa-ad4da45f0f37@github.com>

On Sat, 25 May 2024 06:33:51 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Scott Gibbons has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix test; review comments
>
> test/jdk/java/lang/StringBuffer/IndexOf.java line 47:
> 
>> 45: public class IndexOf {
>> 46: 
>> 47:   static Random generator = new Random();
> 
> @RogerRiggs Would you have cycles to look at Scott's changes to this test? I suspect it will need to be re-structured, re-formatted, and commented to get into maintainable shape.

I am going to revert my changes to this file as the test `jdk/java/lang/String/IndexOf.java` covers the code better.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1617560447

From sgibbons at openjdk.org  Tue May 28 16:12:43 2024
From: sgibbons at openjdk.org (Scott Gibbons)
Date: Tue, 28 May 2024 16:12:43 GMT
Subject: RFR: 8320448: Accelerate IndexOf using AVX2 [v44]
In-Reply-To: <uWi4QxH31hL93771gkl_GgvP0m84IRSoR_1Yi8hD17E=.bc6ed458-7081-4c3f-9348-f59358fa05a4@github.com>
References: <uWi4QxH31hL93771gkl_GgvP0m84IRSoR_1Yi8hD17E=.bc6ed458-7081-4c3f-9348-f59358fa05a4@github.com>
Message-ID: <dyoWKdFGxEd6phSRO7aJ6U7tcakcuujQt1ueRemoTUI=.0ce45077-9e6f-4d35-9b17-8e3e13bbfff5@github.com>

> Re-write the IndexOf code without the use of the pcmpestri instruction, only using AVX2 instructions.  This change accelerates String.IndexOf on average 1.3x for AVX2.  The benchmark numbers:
> 
> 
> Benchmark	                                               Score		Latest		
> StringIndexOf.advancedWithMediumSub   343.573		317.934		0.925375393x
> StringIndexOf.advancedWithShortSub1	  1039.081		1053.96		1.014319384x
> StringIndexOf.advancedWithShortSub2	      55.828		110.541		1.980027943x
> StringIndexOf.constantPattern	                9.361		11.906		1.271872663x
> StringIndexOf.searchCharLongSuccess	        4.216		4.218		1.000474383x
> StringIndexOf.searchCharMediumSuccess	3.133		3.216		1.02649218x
> StringIndexOf.searchCharShortSuccess	3.76		        3.761		1.000265957x
> StringIndexOf.success	                                9.186		9.713		1.057369911x
> StringIndexOf.successBig	                      14.341		46.343		3.231504079x
> StringIndexOfChar.latin1_AVX2_String	  6220.918		12154.52		1.953814533x
> StringIndexOfChar.latin1_AVX2_char	  5503.556		5540.044		1.006629895x
> StringIndexOfChar.latin1_SSE4_String	  6978.854		6818.689		0.977049957x
> StringIndexOfChar.latin1_SSE4_char	  5657.499		5474.624		0.967675646x
> StringIndexOfChar.latin1_Short_String	  7132.541		6863.359		0.962260014x
> StringIndexOfChar.latin1_Short_char	16013.389	      16162.437		1.009307711x
> StringIndexOfChar.latin1_mixed_String	  7386.123	      14771.622		1.999915517x
> StringIndexOfChar.latin1_mixed_char	  9901.671		9782.245		0.987938803

Scott Gibbons has updated the pull request incrementally with one additional commit since the last revision:

  Revert changes to IndexOf.java

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/16753/files
  - new: https://git.openjdk.org/jdk/pull/16753/files/15994a39..01cb58fb

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16753&range=43
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16753&range=42-43

  Stats: 382 lines in 1 file changed: 0 ins; 222 del; 160 mod
  Patch: https://git.openjdk.org/jdk/pull/16753.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16753/head:pull/16753

PR: https://git.openjdk.org/jdk/pull/16753

From joehw at openjdk.org  Tue May 28 16:27:24 2024
From: joehw at openjdk.org (Joe Wang)
Date: Tue, 28 May 2024 16:27:24 GMT
Subject: RFR: 8330542: Template for Creating Strict JAXP Configuration File
 [v15]
In-Reply-To: <v1bAYKgH9zfooXpvnBw4Vu2TIqHuKqqtSmgB0hiNp-Q=.31661a99-ecfc-4a05-8045-67b5f680db60@github.com>
References: <v1bAYKgH9zfooXpvnBw4Vu2TIqHuKqqtSmgB0hiNp-Q=.31661a99-ecfc-4a05-8045-67b5f680db60@github.com>
Message-ID: <r87A_imjsCHGuWwHEX4oq4ak90-5hMq67dUvOvDLOmA=.bbaa7b1b-a2a0-449d-92b1-81e433519dc7@github.com>

> Add two sample configuration files:
> 
>   jaxp-strict.properties: used to set strict configuration, stricter than jaxp.properties in previous versions such as JDK 22
> 
>>   jaxp-compat.properties: used to regain compatibility from any more restricted configuration than previous versions such as JDK 22
> 
> Updated on 5/16/2024
> 
> Design change:
> The design is changed to include in the JDK two configuration files that are the default jaxp.properties and jaxp-strict.properties, instead of three, dropping jaxp-compat.properties.
> 
> Updated on 5/18/2024
> 
> Withdraw changes to jaxp.properties. The original idea was to match jaxp-strict.properties with regard to the properties. However, that change impact the configuration process, resulting in tests that verify the process to fail.
> 
> Updated on 5/23/2024
> 
> Provide a template `jaxp-strict.template` instead of a properties file. This template can be used to create custom configuration files.

Joe Wang has updated the pull request incrementally with one additional commit since the last revision:

  update properties files with wording suggestions; move summary to after the test tag

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/18831/files
  - new: https://git.openjdk.org/jdk/pull/18831/files/714095d1..abc1e88b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18831&range=14
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18831&range=13-14

  Stats: 21 lines in 3 files changed: 2 ins; 2 del; 17 mod
  Patch: https://git.openjdk.org/jdk/pull/18831.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18831/head:pull/18831

PR: https://git.openjdk.org/jdk/pull/18831

From joehw at openjdk.org  Tue May 28 16:27:24 2024
From: joehw at openjdk.org (Joe Wang)
Date: Tue, 28 May 2024 16:27:24 GMT
Subject: RFR: 8330542: Template for Creating Strict JAXP Configuration File
 [v14]
In-Reply-To: <-xQutVfz6r3JPZZnkO71_iimpzxhNvdoX8cpz8E7-X8=.5867b83a-ec89-4c69-ac7c-6bc11caeb93e@github.com>
References: <v1bAYKgH9zfooXpvnBw4Vu2TIqHuKqqtSmgB0hiNp-Q=.31661a99-ecfc-4a05-8045-67b5f680db60@github.com>
 <-xQutVfz6r3JPZZnkO71_iimpzxhNvdoX8cpz8E7-X8=.5867b83a-ec89-4c69-ac7c-6bc11caeb93e@github.com>
Message-ID: <UjEEpIiLbiMTODQq5peb72DFzwbNSSkU5tk1Ly29OQw=.6551ef81-702e-40d9-b6d4-a2338ad15db5@github.com>

On Fri, 24 May 2024 16:36:32 GMT, Joe Wang <joehw at openjdk.org> wrote:

>> Add two sample configuration files:
>> 
>>   jaxp-strict.properties: used to set strict configuration, stricter than jaxp.properties in previous versions such as JDK 22
>> 
>>>   jaxp-compat.properties: used to regain compatibility from any more restricted configuration than previous versions such as JDK 22
>> 
>> Updated on 5/16/2024
>> 
>> Design change:
>> The design is changed to include in the JDK two configuration files that are the default jaxp.properties and jaxp-strict.properties, instead of three, dropping jaxp-compat.properties.
>> 
>> Updated on 5/18/2024
>> 
>> Withdraw changes to jaxp.properties. The original idea was to match jaxp-strict.properties with regard to the properties. However, that change impact the configuration process, resulting in tests that verify the process to fail.
>> 
>> Updated on 5/23/2024
>> 
>> Provide a template `jaxp-strict.template` instead of a properties file. This template can be used to create custom configuration files.
>
> Joe Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   rename the template to jaxp-strict.properties.template

Thanks Sean, Naoto!  Updated accordingly.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18831#issuecomment-2135662540

From sviswanathan at openjdk.org  Tue May 28 16:42:19 2024
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Tue, 28 May 2024 16:42:19 GMT
Subject: RFR: 8320448: Accelerate IndexOf using AVX2 [v43]
In-Reply-To: <oFs22uebWl0oFfLMtpgvsLv0U18o5uUwttHFHbTMUhI=.0f8507e2-48d2-4d92-8c66-bad4d2276774@github.com>
References: <uWi4QxH31hL93771gkl_GgvP0m84IRSoR_1Yi8hD17E=.bc6ed458-7081-4c3f-9348-f59358fa05a4@github.com>
 <oFs22uebWl0oFfLMtpgvsLv0U18o5uUwttHFHbTMUhI=.0f8507e2-48d2-4d92-8c66-bad4d2276774@github.com>
Message-ID: <8iJLAJvIzHgXpr5P1hWOLTj-bfO6THNUJkQf7Ki2P9Y=.43680b7c-c3e1-41f8-b065-7955e6237613@github.com>

On Sat, 25 May 2024 22:19:41 GMT, Scott Gibbons <sgibbons at openjdk.org> wrote:

>> Re-write the IndexOf code without the use of the pcmpestri instruction, only using AVX2 instructions.  This change accelerates String.IndexOf on average 1.3x for AVX2.  The benchmark numbers:
>> 
>> 
>> Benchmark	                                               Score		Latest		
>> StringIndexOf.advancedWithMediumSub   343.573		317.934		0.925375393x
>> StringIndexOf.advancedWithShortSub1	  1039.081		1053.96		1.014319384x
>> StringIndexOf.advancedWithShortSub2	      55.828		110.541		1.980027943x
>> StringIndexOf.constantPattern	                9.361		11.906		1.271872663x
>> StringIndexOf.searchCharLongSuccess	        4.216		4.218		1.000474383x
>> StringIndexOf.searchCharMediumSuccess	3.133		3.216		1.02649218x
>> StringIndexOf.searchCharShortSuccess	3.76		        3.761		1.000265957x
>> StringIndexOf.success	                                9.186		9.713		1.057369911x
>> StringIndexOf.successBig	                      14.341		46.343		3.231504079x
>> StringIndexOfChar.latin1_AVX2_String	  6220.918		12154.52		1.953814533x
>> StringIndexOfChar.latin1_AVX2_char	  5503.556		5540.044		1.006629895x
>> StringIndexOfChar.latin1_SSE4_String	  6978.854		6818.689		0.977049957x
>> StringIndexOfChar.latin1_SSE4_char	  5657.499		5474.624		0.967675646x
>> StringIndexOfChar.latin1_Short_String	  7132.541		6863.359		0.962260014x
>> StringIndexOfChar.latin1_Short_char	16013.389	      16162.437		1.009307711x
>> StringIndexOfChar.latin1_mixed_String	  7386.123	      14771.622		1.999915517x
>> StringIndexOfChar.latin1_mixed_char	  9901.671		9782.245		0.987938803
>
> Scott Gibbons has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix tests

src/hotspot/cpu/x86/c2_stubGenerator_x86_64_string.cpp line 239:

> 237:   //  the needle size is less than 32 bytes, we default to a
> 238:   //  byte-by-byte comparison (this will be rare).
> 239:   //

Is this still true?

src/hotspot/cpu/x86/c2_stubGenerator_x86_64_string.cpp line 278:

> 276:   __ bind(L_nextCheck);
> 277:   __ testq(haystack_len_p, haystack_len_p);
> 278:   __ je(L_zeroCheckFailed);

This check could be removed as the next check covers this one.

src/hotspot/cpu/x86/c2_stubGenerator_x86_64_string.cpp line 360:

> 358:   __ push(rcx);
> 359:   __ push(r8);
> 360:   __ push(r9);

No need to save/restore rcx/r8/r9 on windows platform as well.

src/hotspot/cpu/x86/c2_stubGenerator_x86_64_string.cpp line 379:

> 377: 
> 378:   // Assume failure
> 379:   __ movq(rbp, -1);

We are no more using rbp at return point so this is not needed now?

src/hotspot/cpu/x86/c2_stubGenerator_x86_64_string.cpp line 488:

> 486:   __ cmpq(r11, nMinusK);
> 487:   __ ja_b(L_return);
> 488:   __ movq(rax, r11);

At places where we know that return value in r11 is correct, we dont need to checkRange so this could have its own label.

src/hotspot/cpu/x86/c2_stubGenerator_x86_64_string.cpp line 566:

> 564:     //  rbp: -1
> 565:     //  XMM_BYTE_0 - first element of needle broadcast
> 566:     //  XMM_BYTE_K - last element of needle broadcast

The only registers that are used as input in the switch case are:
r14 = needle
rbx = haystack
rsi = haystack length (n)
r12 = needle length (k)
r10 = n - k (where k is needle length)
XMM_BYTE_0 = first element of needle, broadcast
XMM_BYTE_K = last element of needle, broadcast
So we could only list these, making it easier to comprehend.

src/hotspot/cpu/x86/c2_stubGenerator_x86_64_string.cpp line 578:

> 576:     // helper jumps to L_checkRangeAndReturn with a (-1) return value.
> 577:     big_case_loop_helper(false, 0, L_checkRangeAndReturn, L_loopTop, mask, hsPtrRet, needleLen,
> 578:                          needle, haystack, hsLength, tmp1, tmp2, tmp3, rScratch, ae, _masm);

If we run out of haystack instead of jumping to L_checkRangeAndReturn, we could directly jump to  L_retrunError.

src/hotspot/cpu/x86/c2_stubGenerator_x86_64_string.cpp line 597:

> 595: 
> 596:     // Need a lot of registers here to preserve state across arrays_equals call
> 597: 

This comment is no longer valid, could be removed.

src/hotspot/cpu/x86/c2_stubGenerator_x86_64_string.cpp line 621:

> 619:     __ addq(hsPtrRet, index);
> 620:     __ movq(r11, hsPtrRet);
> 621:     __ jmp(L_checkRangeAndReturn);

Why do we have to checkRange here, would it not be always correct? It so we could return r11 directly (by moving into rax).

src/hotspot/cpu/x86/c2_stubGenerator_x86_64_string.cpp line 660:

> 658:   //  Haystack always copied to stack, so 32-byte reads OK
> 659:   //  Haystack length < 32
> 660:   //  10 < needle length < 32

Haystack length <= 32
10 < needle length <= 32

src/hotspot/cpu/x86/c2_stubGenerator_x86_64_string.cpp line 721:

> 719:                        false /* char */, knoreg);
> 720:     __ testl(rTmp3, rTmp3);
> 721:     __ jne(L_checkRangeAndReturn);

Why do we have to checkRange here, would it not be always correct? It so we could return r11 directly (by moving into rax).

src/hotspot/cpu/x86/c2_stubGenerator_x86_64_string.cpp line 1333:

> 1331: 
> 1332:   __ cmpq(nMinusK, 32);
> 1333:   __ jae_b(L_greaterThan32);

Should this check be (n-k+1) >= 32? And so accordingly (n-k) >= 31
 __ cmpq(nMinusK, 31);
 __ jae_b(L_greaterThan32);

src/hotspot/cpu/x86/c2_stubGenerator_x86_64_string.cpp line 1382:

> 1380: 
> 1381:   __ testl(eq_mask, eq_mask);
> 1382:   __ je(noMatch);

We are mixing operation width l and q here.

src/hotspot/cpu/x86/c2_stubGenerator_x86_64_string.cpp line 1750:

> 1748:     //  r15 = unused
> 1749:     //  XMM_BYTE_0 - first element of needle, broadcast
> 1750:     //  XMM_BYTE_K - last element of needle, broadcast

This comment is duplicated for both small haystack case and big haystack case, could be made a common comment. 
Also the only registers that are used as input in the switch case are:
r14 = needle
rbx = haystack
rsi = haystack length (n)
r12 = needle length (k)
r10 = n - k (where k is needle length)
XMM_BYTE_0 = first element of needle, broadcast
XMM_BYTE_K = last element of needle, broadcast
So we could only list these, making it easier to comprehend.

src/hotspot/cpu/x86/c2_stubGenerator_x86_64_string.cpp line 1758:

> 1756:     //
> 1757:     // If a match is found, jump to L_checkRange, which ensures the
> 1758:     // matched needle is not past the end of the haystack.

Another comment here would be useful:
// The found index is returned in set_bit (r11).

src/hotspot/cpu/x86/c2_stubGenerator_x86_64_string.cpp line 1810:

> 1808:     //  XMM_BYTE_K - last element of needle, broadcast
> 1809:     //
> 1810:     //  The haystack is > 32 bytes

Good to mention some info about the return found index value in comment about how it is a combination of set_bit (r8), hs_ptr, and haystack.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1617187600
PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1617193503
PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1617216424
PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1617218826
PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1617603927
PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1617318645
PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1617307443
PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1617536831
PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1617569308
PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1617575018
PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1617601913
PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1616424912
PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1616427773
PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1617263035
PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1617267415
PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1617273352

From mullan at openjdk.org  Tue May 28 16:46:05 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Tue, 28 May 2024 16:46:05 GMT
Subject: RFR: 8330542: Template for Creating Strict JAXP Configuration File
 [v15]
In-Reply-To: <r87A_imjsCHGuWwHEX4oq4ak90-5hMq67dUvOvDLOmA=.bbaa7b1b-a2a0-449d-92b1-81e433519dc7@github.com>
References: <v1bAYKgH9zfooXpvnBw4Vu2TIqHuKqqtSmgB0hiNp-Q=.31661a99-ecfc-4a05-8045-67b5f680db60@github.com>
 <r87A_imjsCHGuWwHEX4oq4ak90-5hMq67dUvOvDLOmA=.bbaa7b1b-a2a0-449d-92b1-81e433519dc7@github.com>
Message-ID: <NkW7mQvCoJpMsqiVuZqYlHZZ6m0Ly5QTvfM1SH5NAE0=.05bcfef0-5507-4dc9-aac0-3f7be0071422@github.com>

On Tue, 28 May 2024 16:27:24 GMT, Joe Wang <joehw at openjdk.org> wrote:

>> Add two sample configuration files:
>> 
>>   jaxp-strict.properties: used to set strict configuration, stricter than jaxp.properties in previous versions such as JDK 22
>> 
>>>   jaxp-compat.properties: used to regain compatibility from any more restricted configuration than previous versions such as JDK 22
>> 
>> Updated on 5/16/2024
>> 
>> Design change:
>> The design is changed to include in the JDK two configuration files that are the default jaxp.properties and jaxp-strict.properties, instead of three, dropping jaxp-compat.properties.
>> 
>> Updated on 5/18/2024
>> 
>> Withdraw changes to jaxp.properties. The original idea was to match jaxp-strict.properties with regard to the properties. However, that change impact the configuration process, resulting in tests that verify the process to fail.
>> 
>> Updated on 5/23/2024
>> 
>> Provide a template `jaxp-strict.template` instead of a properties file. This template can be used to create custom configuration files.
>
> Joe Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update properties files with wording suggestions; move summary to after the test tag

Marked as reviewed by mullan (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/18831#pullrequestreview-2083391002

From naoto at openjdk.org  Tue May 28 16:56:18 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 28 May 2024 16:56:18 GMT
Subject: RFR: 8332161: Test restoring echo in the Console implementation
 (java.base) [v6]
In-Reply-To: <aSxuvnY7ghWwuDuegcWKJKlL_3KUCdIS_jHgTsn43ow=.b4d2e8d9-ffea-4318-9004-27b18298436e@github.com>
References: <aSxuvnY7ghWwuDuegcWKJKlL_3KUCdIS_jHgTsn43ow=.b4d2e8d9-ffea-4318-9004-27b18298436e@github.com>
Message-ID: <FkVs4Tu1LpzmoozGa1zmZqqB4KsVsCoRyh7sQ1A7cIc=.f830cded-5ecf-402c-9679-57b6c35bbe63@github.com>

> This test intends to verify the behavior of JdkConsole for the java.base module, wrt restoring the echo. The test assumes the internal methods that sets/gets the echo status of the platform.

Naoto Sato has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 23 commits:

 - incorporated the same fix from 8332922
 - Merge branch 'master' into JDK-8332161-restoreEcho-Test
 - Merge branch 'master' into JDK-8332161-restoreEcho-Test
 - Merge branch 'JDK-8332084-restoreEcho-readLock' into JDK-8332161-restoreEcho-Test
 - Added comment for restoreEchoLock
 - fixing typo
 - Merge branch 'JDK-8332084-restoreEcho-readLock' into JDK-8332161-restoreEcho-Test
 - Merge branch 'master' into JDK-8332084-restoreEcho-readLock
 - leftover typo
 - get/setEcho() -> echo()
 - ... and 13 more: https://git.openjdk.org/jdk/compare/b8f2ec90...2477adf4

-------------

Changes: https://git.openjdk.org/jdk/pull/19315/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19315&range=05
  Stats: 192 lines in 2 files changed: 192 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/19315.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19315/head:pull/19315

PR: https://git.openjdk.org/jdk/pull/19315

From kvn at openjdk.org  Tue May 28 17:00:22 2024
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Tue, 28 May 2024 17:00:22 GMT
Subject: RFR: 8320448: Accelerate IndexOf using AVX2 [v38]
In-Reply-To: <DEIgE5V0yqkQUTe5KWlFvLmApPYpP2JGMcUlpkuvt4U=.89e9cddd-3a3c-445b-9080-cb0eaca0a963@github.com>
References: <uWi4QxH31hL93771gkl_GgvP0m84IRSoR_1Yi8hD17E=.bc6ed458-7081-4c3f-9348-f59358fa05a4@github.com>
 <nDwq515-pZGnnCsqW0nkRtlqIyhnvqKXFTydeaXztHo=.eb511293-d67b-4a06-b792-264087af40d0@github.com>
 <MImPmWGxi3FpwVq1rk0Rohfh3_5H_iqAgblEpn8_TQQ=.cbb5359c-d8df-48b8-8a0f-e9976923475f@github.com>
 <DEIgE5V0yqkQUTe5KWlFvLmApPYpP2JGMcUlpkuvt4U=.89e9cddd-3a3c-445b-9080-cb0eaca0a963@github.com>
Message-ID: <7jqyfDXW_EbstH_s90Fp4O7a214ZaejdM0CyAffzOHs=.544c7a91-c66b-4487-a2bf-0b8e300a94c0@github.com>

On Tue, 28 May 2024 16:00:10 GMT, Scott Gibbons <sgibbons at openjdk.org> wrote:

>> test/jdk/java/lang/StringBuffer/IndexOf.java line 28:
>> 
>>> 26:  * @summary Test indexOf and lastIndexOf
>>> 27:  * @run main/othervm IndexOf
>>> 28:  * @run main/othervm -XX:+IgnoreUnrecognizedVMOptions -Xcomp -XX:-TieredCompilation -XX:UseAVX=2 -XX:+UnlockDiagnosticVMOptions -XX:+EnableX86ECoreOpts IndexOf
>> 
>> I suggest to split it into 2 subtest jobs and use `@requires vm.cpu.features ~= ".*avx2.*"` for second which specified `-XX:UseAVX=2`.
>> See `compiler/loopopts/superword/TestDependencyOffsets.java` for example.
>
> @vnkozlov I'm getting an error in CI tests with this line added.  Can you please advise?
> 
> `TEST RESULT: Error. Parse Exception: Syntax error in @requires expression: invalid name: vm.cpu.features`

You need to add `vm.cpu.features ` line to `test/jdk/TEST.ROOT` file. Similar to what we have in `test/hotspot/jtreg/TEST.ROOT`

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1617630712

From sgibbons at openjdk.org  Tue May 28 18:30:30 2024
From: sgibbons at openjdk.org (Scott Gibbons)
Date: Tue, 28 May 2024 18:30:30 GMT
Subject: RFR: 8320448: Accelerate IndexOf using AVX2 [v45]
In-Reply-To: <uWi4QxH31hL93771gkl_GgvP0m84IRSoR_1Yi8hD17E=.bc6ed458-7081-4c3f-9348-f59358fa05a4@github.com>
References: <uWi4QxH31hL93771gkl_GgvP0m84IRSoR_1Yi8hD17E=.bc6ed458-7081-4c3f-9348-f59358fa05a4@github.com>
Message-ID: <lt4QcfecNGRtNlt9H3l7406C5s6prQSAklO4K0ZlSaI=.0a6e0c11-ee23-4c2d-a384-f7c44489b190@github.com>

> Re-write the IndexOf code without the use of the pcmpestri instruction, only using AVX2 instructions.  This change accelerates String.IndexOf on average 1.3x for AVX2.  The benchmark numbers:
> 
> 
> Benchmark	                                               Score		Latest		
> StringIndexOf.advancedWithMediumSub   343.573		317.934		0.925375393x
> StringIndexOf.advancedWithShortSub1	  1039.081		1053.96		1.014319384x
> StringIndexOf.advancedWithShortSub2	      55.828		110.541		1.980027943x
> StringIndexOf.constantPattern	                9.361		11.906		1.271872663x
> StringIndexOf.searchCharLongSuccess	        4.216		4.218		1.000474383x
> StringIndexOf.searchCharMediumSuccess	3.133		3.216		1.02649218x
> StringIndexOf.searchCharShortSuccess	3.76		        3.761		1.000265957x
> StringIndexOf.success	                                9.186		9.713		1.057369911x
> StringIndexOf.successBig	                      14.341		46.343		3.231504079x
> StringIndexOfChar.latin1_AVX2_String	  6220.918		12154.52		1.953814533x
> StringIndexOfChar.latin1_AVX2_char	  5503.556		5540.044		1.006629895x
> StringIndexOfChar.latin1_SSE4_String	  6978.854		6818.689		0.977049957x
> StringIndexOfChar.latin1_SSE4_char	  5657.499		5474.624		0.967675646x
> StringIndexOfChar.latin1_Short_String	  7132.541		6863.359		0.962260014x
> StringIndexOfChar.latin1_Short_char	16013.389	      16162.437		1.009307711x
> StringIndexOfChar.latin1_mixed_String	  7386.123	      14771.622		1.999915517x
> StringIndexOfChar.latin1_mixed_char	  9901.671		9782.245		0.987938803

Scott Gibbons has updated the pull request incrementally with one additional commit since the last revision:

  Review comments

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/16753/files
  - new: https://git.openjdk.org/jdk/pull/16753/files/01cb58fb..751aace8

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16753&range=44
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16753&range=43-44

  Stats: 49 lines in 4 files changed: 20 ins; 13 del; 16 mod
  Patch: https://git.openjdk.org/jdk/pull/16753.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16753/head:pull/16753

PR: https://git.openjdk.org/jdk/pull/16753

From sgibbons at openjdk.org  Tue May 28 18:30:31 2024
From: sgibbons at openjdk.org (Scott Gibbons)
Date: Tue, 28 May 2024 18:30:31 GMT
Subject: RFR: 8320448: Accelerate IndexOf using AVX2 [v43]
In-Reply-To: <8iJLAJvIzHgXpr5P1hWOLTj-bfO6THNUJkQf7Ki2P9Y=.43680b7c-c3e1-41f8-b065-7955e6237613@github.com>
References: <uWi4QxH31hL93771gkl_GgvP0m84IRSoR_1Yi8hD17E=.bc6ed458-7081-4c3f-9348-f59358fa05a4@github.com>
 <oFs22uebWl0oFfLMtpgvsLv0U18o5uUwttHFHbTMUhI=.0f8507e2-48d2-4d92-8c66-bad4d2276774@github.com>
 <8iJLAJvIzHgXpr5P1hWOLTj-bfO6THNUJkQf7Ki2P9Y=.43680b7c-c3e1-41f8-b065-7955e6237613@github.com>
Message-ID: <Luyf7AUJS5vrDWsayavrN5qUJ9fkAyUv3lLdSGcDQoo=.7c7cec0d-ce11-49fc-9644-d80d50731289@github.com>

On Tue, 28 May 2024 12:48:19 GMT, Sandhya Viswanathan <sviswanathan at openjdk.org> wrote:

>> Scott Gibbons has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix tests
>
> src/hotspot/cpu/x86/c2_stubGenerator_x86_64_string.cpp line 239:
> 
>> 237:   //  the needle size is less than 32 bytes, we default to a
>> 238:   //  byte-by-byte comparison (this will be rare).
>> 239:   //
> 
> Is this still true?

Yes.  For UL, the code within `L_compareFull` effectively does byte-by-byte.

> src/hotspot/cpu/x86/c2_stubGenerator_x86_64_string.cpp line 278:
> 
>> 276:   __ bind(L_nextCheck);
>> 277:   __ testq(haystack_len_p, haystack_len_p);
>> 278:   __ je(L_zeroCheckFailed);
> 
> This check could be removed as the next check covers this one.

No.  This is checking for a zero length haystack.  The following compare checks for needle length longer than haystack, regardless of the value in each.  The comparison is signed, so a haystack length of 0 with a needle length of -1 will pass the following test and assume validity.

> src/hotspot/cpu/x86/c2_stubGenerator_x86_64_string.cpp line 360:
> 
>> 358:   __ push(rcx);
>> 359:   __ push(r8);
>> 360:   __ push(r9);
> 
> No need to save/restore rcx/r8/r9 on windows platform as well.

OK.

> src/hotspot/cpu/x86/c2_stubGenerator_x86_64_string.cpp line 379:
> 
>> 377: 
>> 378:   // Assume failure
>> 379:   __ movq(rbp, -1);
> 
> We are no more using rbp at return point so this is not needed now?

Removed.

> src/hotspot/cpu/x86/c2_stubGenerator_x86_64_string.cpp line 488:
> 
>> 486:   __ cmpq(r11, nMinusK);
>> 487:   __ ja_b(L_return);
>> 488:   __ movq(rax, r11);
> 
> At places where we know that return value in r11 is correct, we dont need to checkRange so this could have its own label.

I don't want to change this because its reason for existence is to ensure we don't return a value that's beyond the end of the haystack.  We don't yet have a good enough test to validate whether we're reading past the end of the haystack, so I like this as insurance.

> src/hotspot/cpu/x86/c2_stubGenerator_x86_64_string.cpp line 566:
> 
>> 564:     //  rbp: -1
>> 565:     //  XMM_BYTE_0 - first element of needle broadcast
>> 566:     //  XMM_BYTE_K - last element of needle broadcast
> 
> The only registers that are used as input in the switch case are:
> r14 = needle
> rbx = haystack
> rsi = haystack length (n)
> r12 = needle length (k)
> r10 = n - k (where k is needle length)
> XMM_BYTE_0 = first element of needle, broadcast
> XMM_BYTE_K = last element of needle, broadcast
> So we could only list these, making it easier to comprehend.

I listed these registers to make it clear which registers had no expected value and could be used for temps, etc.

> src/hotspot/cpu/x86/c2_stubGenerator_x86_64_string.cpp line 578:
> 
>> 576:     // helper jumps to L_checkRangeAndReturn with a (-1) return value.
>> 577:     big_case_loop_helper(false, 0, L_checkRangeAndReturn, L_loopTop, mask, hsPtrRet, needleLen,
>> 578:                          needle, haystack, hsLength, tmp1, tmp2, tmp3, rScratch, ae, _masm);
> 
> If we run out of haystack instead of jumping to L_checkRangeAndReturn, we could directly jump to  L_retrunError.

Again, I think we ought to leave this in.  Although it executes ~3 instructions that may not be necessary in some cases I think it's best to perform the check.  Once we have a good enough test to check reading past the end of the haystack we can change it.

> src/hotspot/cpu/x86/c2_stubGenerator_x86_64_string.cpp line 597:
> 
>> 595: 
>> 596:     // Need a lot of registers here to preserve state across arrays_equals call
>> 597: 
> 
> This comment is no longer valid, could be removed.

OK

> src/hotspot/cpu/x86/c2_stubGenerator_x86_64_string.cpp line 621:
> 
>> 619:     __ addq(hsPtrRet, index);
>> 620:     __ movq(r11, hsPtrRet);
>> 621:     __ jmp(L_checkRangeAndReturn);
> 
> Why do we have to checkRange here, would it not be always correct? It so we could return r11 directly (by moving into rax).

There are cases where r11 could have a value that, when added to (k - 1) would go past the end of the haystack.  I did all in my power to ensure that it doesn't but there's no test I know of to ensure that condition.  I would recommend leaving this in for now.

> src/hotspot/cpu/x86/c2_stubGenerator_x86_64_string.cpp line 660:
> 
>> 658:   //  Haystack always copied to stack, so 32-byte reads OK
>> 659:   //  Haystack length < 32
>> 660:   //  10 < needle length < 32
> 
> Haystack length <= 32
> 10 < needle length <= 32

Changed.

> src/hotspot/cpu/x86/c2_stubGenerator_x86_64_string.cpp line 721:
> 
>> 719:                        false /* char */, knoreg);
>> 720:     __ testl(rTmp3, rTmp3);
>> 721:     __ jne(L_checkRangeAndReturn);
> 
> Why do we have to checkRange here, would it not be always correct? It so we could return r11 directly (by moving into rax).

OK

> src/hotspot/cpu/x86/c2_stubGenerator_x86_64_string.cpp line 1333:
> 
>> 1331: 
>> 1332:   __ cmpq(nMinusK, 32);
>> 1333:   __ jae_b(L_greaterThan32);
> 
> Should this check be (n-k+1) >= 32? And so accordingly (n-k) >= 31
>  __ cmpq(nMinusK, 31);
>  __ jae_b(L_greaterThan32);

No. For (n-k)==32 we can do full reads.  I'll clarify by changing the label name.

> src/hotspot/cpu/x86/c2_stubGenerator_x86_64_string.cpp line 1382:
> 
>> 1380: 
>> 1381:   __ testl(eq_mask, eq_mask);
>> 1382:   __ je(noMatch);
> 
> We are mixing operation width l and q here.

Fixed.

> src/hotspot/cpu/x86/c2_stubGenerator_x86_64_string.cpp line 1750:
> 
>> 1748:     //  r15 = unused
>> 1749:     //  XMM_BYTE_0 - first element of needle, broadcast
>> 1750:     //  XMM_BYTE_K - last element of needle, broadcast
> 
> This comment is duplicated for both small haystack case and big haystack case, could be made a common comment. 
> Also the only registers that are used as input in the switch case are:
> r14 = needle
> rbx = haystack
> rsi = haystack length (n)
> r12 = needle length (k)
> r10 = n - k (where k is needle length)
> XMM_BYTE_0 = first element of needle, broadcast
> XMM_BYTE_K = last element of needle, broadcast
> So we could only list these, making it easier to comprehend.

I listed all registers for clarity.  This ensures that we know what can be used as values or as scratch registers with no ambiguity.

> src/hotspot/cpu/x86/c2_stubGenerator_x86_64_string.cpp line 1758:
> 
>> 1756:     //
>> 1757:     // If a match is found, jump to L_checkRange, which ensures the
>> 1758:     // matched needle is not past the end of the haystack.
> 
> Another comment here would be useful:
> // The found index is returned in set_bit (r11).

Added.

> src/hotspot/cpu/x86/c2_stubGenerator_x86_64_string.cpp line 1810:
> 
>> 1808:     //  XMM_BYTE_K - last element of needle, broadcast
>> 1809:     //
>> 1810:     //  The haystack is > 32 bytes
> 
> Good to mention some info about the return found index value in comment about how it is a combination of set_bit (r8), hs_ptr, and haystack.

Done.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1617663227
PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1617667775
PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1617669103
PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1617671612
PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1617673870
PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1617680570
PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1617699879
PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1617700813
PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1617704836
PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1617705505
PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1617711973
PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1617713299
PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1617714825
PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1617716598
PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1617717873
PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1617726261

From jjg at openjdk.org  Tue May 28 18:53:02 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Tue, 28 May 2024 18:53:02 GMT
Subject: RFR: 8331879: Clean up non-standard use of /// comments in
 `java.base`
In-Reply-To: <SJEc7F5iCUK5ej9Tq6De8W--UT7MqbyP62IcVNPArRY=.3a3feed7-b8e1-4a14-8a01-fe9b2b7e5bd2@github.com>
References: <BiSTG8MtjyRt2txRK2DIxsmbPPq6Pvp7QQzOnHXbH6w=.b01b4872-dc8b-4e4f-bae6-bdc501da33a6@github.com>
 <SJEc7F5iCUK5ej9Tq6De8W--UT7MqbyP62IcVNPArRY=.3a3feed7-b8e1-4a14-8a01-fe9b2b7e5bd2@github.com>
Message-ID: <f9vxrbiyG8nALy7dkCpZ1eqUgQCyg0Strdn_zc5qeFk=.ff6ef4b9-f39d-4900-a76e-61c7d0f1402c@github.com>

On Wed, 22 May 2024 20:13:08 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> With the advent of JEP 467, `///` comments may be treated as documentation comments, and may be subject to the recently new `javac` warning about "dangling doc comments" in unexpected places.
>> 
>> In keeping with the policy to keep the `java.base` module free of all `javac` warnings, this patch proposes edits to existing uses of `///`.
>> 
>> There are two dominant policies in the proposed changes. 
>> 1. A long horizontal line of `/////` is replaced by `//-----`
>> 2. A long vertical series of lines beginning `///` is replaced by lines beginning `//|`.
>> 
>> As with all style changes, I have also tried to honor local usage, for consistency.
>> 
>> In one place, a pair of comments appeared to contain directives (`CLOVER:ON`, `CLOVER:OFF`).  I investigated the use of such comments to determine that the exact form of the comment prefix was not significant. (Phew!)
>> 
>> 
>> (This PR is informally blocked by JEP 467).
>
> src/java.base/share/classes/jdk/internal/icu/impl/StringPrepDataReader.java line 122:
> 
>> 120:      * see store.c of gennorm for more information and values
>> 121:      */
>> 122:     // /* dataFormat="SPRP" 0x53, 0x50, 0x52, 0x50  */
> 
> This source file is coming from the upstream ICU4J project. Even if this is a `non-standard` comment, I would keep it as it is to minimize the merge effort.

As a non-standard comment, it will trigger a warning, since the prevailing standard for `java.base` is to compile with all warnings enabled and no warnings found.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19130#discussion_r1617755455

From jjg at openjdk.org  Tue May 28 19:00:02 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Tue, 28 May 2024 19:00:02 GMT
Subject: RFR: 8331879: Clean up non-standard use of /// comments in
 `java.base`
In-Reply-To: <2RfxVIGqDgz9gQ9xO-Mh1cex-4Zg_1wfJFvNKPdG-Ow=.1e91b688-cb86-4f8a-b50b-d94f76b90576@github.com>
References: <BiSTG8MtjyRt2txRK2DIxsmbPPq6Pvp7QQzOnHXbH6w=.b01b4872-dc8b-4e4f-bae6-bdc501da33a6@github.com>
 <2RfxVIGqDgz9gQ9xO-Mh1cex-4Zg_1wfJFvNKPdG-Ow=.1e91b688-cb86-4f8a-b50b-d94f76b90576@github.com>
Message-ID: <0AiLzNg8FqqN9UajZrSXHBb2dtYCqT-TkamkXagQJMo=.28b3b8f6-105b-44d3-8be2-dc6c03e953c5@github.com>

On Thu, 23 May 2024 05:52:57 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> > A long vertical series of lines beginning /// is replaced by lines beginning //|.
> 
> This one looks unusual when it's just one line, I could imagine deleting the "|" in these cases.

OK. I was just trying to honor the apparent intent to make the comment stand out more than just a plain `//` comment, but I have no strong feelings against reducing `///` to `//`

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19130#issuecomment-2135914838

From jvernee at openjdk.org  Tue May 28 19:29:04 2024
From: jvernee at openjdk.org (Jorn Vernee)
Date: Tue, 28 May 2024 19:29:04 GMT
Subject: RFR: 8332826: Make hashCode methods in ArraysSupport friendlier
 [v2]
In-Reply-To: <1tx_tl3PV2W5NCEXXawQY5V2ndnSOHPfjisypuhKdhA=.79840096-bac0-4da4-8102-c7ecea7cb5f0@github.com>
References: <ujd2AT3eYXrHPcSG0vMDe2WOx3INNPU1n0t8haKH0_M=.b1a168d7-ab4c-4920-92ef-1c72e5ffc0cf@github.com>
 <1tx_tl3PV2W5NCEXXawQY5V2ndnSOHPfjisypuhKdhA=.79840096-bac0-4da4-8102-c7ecea7cb5f0@github.com>
Message-ID: <FBIH-xc1qN8grLt03to-5lUHj-jOEzsSk1HPMKZLmSU=.637e8eb0-b2eb-4a0d-a84e-610a142fa5a3@github.com>

On Mon, 27 May 2024 20:55:29 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Please review this PR, which supersedes a now withdrawn https://github.com/openjdk/jdk/pull/14831.
>> 
>> This PR replaces `ArraysSupport.vectorizedHashCode` with a set of more user-friendly methods. Here's a summary:
>> 
>> - Made the operand constants (i.e. `T_BOOLEAN` and friends) and the `vectorizedHashCode` method private
>> 
>> - Made the `vectorizedHashCode` method private, but didn't rename it. Renaming would dramatically increase this PR review cost, because that method's name is used by a lot of VM code. On a bright side, since the method is now private, it's no longer callable by clients of `ArraysSupport`, thus a problem of an inaccurate name is less severe.
>> 
>> - Made the `ArraysSupport.utf16HashCode` method private
>> 
>> - Moved tiny cases (i.e. 0, 1, 2) to `ArraysSupport`
>
> Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix incorrect utf16 hashCode adaptation

src/java.base/share/classes/jdk/internal/util/ArraysSupport.java line 252:

> 250:         return switch (length) {
> 251:             case 0 -> initialValue;
> 252:             case 1 -> 31 * initialValue + (int) a[fromIndex];

Suggestion:

            case 1 -> 31 * initialValue + (int) a[fromIndex]; // sign extension

src/java.base/share/classes/jdk/internal/util/ArraysSupport.java line 275:

> 273:         return switch (length) {
> 274:             case 0 -> initialValue;
> 275:             case 1 -> 31 * initialValue + (a[fromIndex] & 0xff);

For clarity, if you think it helps:
Suggestion:

            case 1 -> 31 * initialValue + Byte.toUnsignedInt(a[fromIndex]);

src/java.base/share/classes/jdk/internal/util/ArraysSupport.java line 301:

> 299:         return switch (length) {
> 300:             case 0 -> initialValue;
> 301:             case 1 -> 31 * initialValue + JLA.getUTF16Char(a, fromIndex);

There seems to be a mismatch here with the original code in StringUTF16, where the length that is tested for is `2` instead of `1`.

test/hotspot/jtreg/compiler/intrinsics/TestArraysHashCode.java line 88:

> 86:     private static int testIntrinsic(byte[] bytes, int type)
> 87:             throws InvocationTargetException, IllegalAccessException {
> 88:         return (int) vectorizedHashCode.invoke(null, bytes, 0, 256, 1, type);

Better to just call `hashCodeOfUnsigned` here I think.

The test for the non-constant type could be dropped. That is no longer a part of the 'API' of `ArraySupport`. It looks like the intrinsic bails out when the basic type is not constant any ways: https://github.com/openjdk/jdk/blob/master/src/hotspot/share/opto/library_call.cpp#L6401-L6404

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19414#discussion_r1617778741
PR Review Comment: https://git.openjdk.org/jdk/pull/19414#discussion_r1617778493
PR Review Comment: https://git.openjdk.org/jdk/pull/19414#discussion_r1617777798
PR Review Comment: https://git.openjdk.org/jdk/pull/19414#discussion_r1617784996

From joehw at openjdk.org  Tue May 28 19:29:11 2024
From: joehw at openjdk.org (Joe Wang)
Date: Tue, 28 May 2024 19:29:11 GMT
Subject: Integrated: 8330542: Template for Creating Strict JAXP Configuration
 File
In-Reply-To: <v1bAYKgH9zfooXpvnBw4Vu2TIqHuKqqtSmgB0hiNp-Q=.31661a99-ecfc-4a05-8045-67b5f680db60@github.com>
References: <v1bAYKgH9zfooXpvnBw4Vu2TIqHuKqqtSmgB0hiNp-Q=.31661a99-ecfc-4a05-8045-67b5f680db60@github.com>
Message-ID: <6Fc9SynPKR0GhTm0dc3ScBGlQh-OXUuNMpmaBO4Pnmw=.59ba1002-bf02-49c6-8d1e-de431e305867@github.com>

On Wed, 17 Apr 2024 23:24:06 GMT, Joe Wang <joehw at openjdk.org> wrote:

> Add two sample configuration files:
> 
>   jaxp-strict.properties: used to set strict configuration, stricter than jaxp.properties in previous versions such as JDK 22
> 
>>   jaxp-compat.properties: used to regain compatibility from any more restricted configuration than previous versions such as JDK 22
> 
> Updated on 5/16/2024
> 
> Design change:
> The design is changed to include in the JDK two configuration files that are the default jaxp.properties and jaxp-strict.properties, instead of three, dropping jaxp-compat.properties.
> 
> Updated on 5/18/2024
> 
> Withdraw changes to jaxp.properties. The original idea was to match jaxp-strict.properties with regard to the properties. However, that change impact the configuration process, resulting in tests that verify the process to fail.
> 
> Updated on 5/23/2024
> 
> Provide a template `jaxp-strict.template` instead of a properties file. This template can be used to create custom configuration files.

This pull request has now been integrated.

Changeset: 91caec07
Author:    Joe Wang <joehw at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/91caec07cb2e4d98d4366f5627f55834282caa94
Stats:     287 lines in 5 files changed: 263 ins; 7 del; 17 mod

8330542: Template for Creating Strict JAXP Configuration File

Reviewed-by: lancea, erikj, alanb, ihse, mullan, naoto

-------------

PR: https://git.openjdk.org/jdk/pull/18831

From mdoerr at openjdk.org  Tue May 28 20:03:05 2024
From: mdoerr at openjdk.org (Martin Doerr)
Date: Tue, 28 May 2024 20:03:05 GMT
Subject: Integrated: 8332228: TypePollution.java: Unrecognized VM option
 'UseSecondarySuperCache'
In-Reply-To: <EW0ZlYhOWfRYoAx1ZrgBYwN4IYbz87ea_OPBL_hvEUU=.2b88c7e4-86a4-4b43-9539-27d5eef051f8@github.com>
References: <EW0ZlYhOWfRYoAx1ZrgBYwN4IYbz87ea_OPBL_hvEUU=.2b88c7e4-86a4-4b43-9539-27d5eef051f8@github.com>
Message-ID: <85PGhPbexhdUePSavv2kKNLGCWNd3ba_lswZFlob-oc=.07afbfdb-4f76-48b0-9215-541e9add95a9@github.com>

On Tue, 28 May 2024 14:01:44 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

> Fix obvious typo in micro benchmark.

This pull request has now been integrated.

Changeset: 9ac8d05a
Author:    Martin Doerr <mdoerr at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/9ac8d05a2567fbf65b944660739e5f8ad1fc2020
Stats:     8 lines in 1 file changed: 0 ins; 0 del; 8 mod

8332228: TypePollution.java: Unrecognized VM option 'UseSecondarySuperCache'

Reviewed-by: chagedorn, kvn

-------------

PR: https://git.openjdk.org/jdk/pull/19427

From mdoerr at openjdk.org  Tue May 28 20:03:05 2024
From: mdoerr at openjdk.org (Martin Doerr)
Date: Tue, 28 May 2024 20:03:05 GMT
Subject: RFR: 8332228: TypePollution.java: Unrecognized VM option
 'UseSecondarySuperCache'
In-Reply-To: <EW0ZlYhOWfRYoAx1ZrgBYwN4IYbz87ea_OPBL_hvEUU=.2b88c7e4-86a4-4b43-9539-27d5eef051f8@github.com>
References: <EW0ZlYhOWfRYoAx1ZrgBYwN4IYbz87ea_OPBL_hvEUU=.2b88c7e4-86a4-4b43-9539-27d5eef051f8@github.com>
Message-ID: <Y9z2YXxixqz_g8EBlWdX2aZZQCvwcwdc03P7MdhFNtA=.cc299ec1-d078-4d16-bee6-25de20b474bb@github.com>

On Tue, 28 May 2024 14:01:44 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

> Fix obvious typo in micro benchmark.

Thanks!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19427#issuecomment-2136008570

From alanb at openjdk.org  Tue May 28 20:04:01 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 28 May 2024 20:04:01 GMT
Subject: RFR: 8331879: Clean up non-standard use of /// comments in
 `java.base`
In-Reply-To: <0AiLzNg8FqqN9UajZrSXHBb2dtYCqT-TkamkXagQJMo=.28b3b8f6-105b-44d3-8be2-dc6c03e953c5@github.com>
References: <BiSTG8MtjyRt2txRK2DIxsmbPPq6Pvp7QQzOnHXbH6w=.b01b4872-dc8b-4e4f-bae6-bdc501da33a6@github.com>
 <2RfxVIGqDgz9gQ9xO-Mh1cex-4Zg_1wfJFvNKPdG-Ow=.1e91b688-cb86-4f8a-b50b-d94f76b90576@github.com>
 <0AiLzNg8FqqN9UajZrSXHBb2dtYCqT-TkamkXagQJMo=.28b3b8f6-105b-44d3-8be2-dc6c03e953c5@github.com>
Message-ID: <dX5j9gYZRoTrwbwqnBBpTaB6ePRafdff8hfND0QDmSc=.fa5b3aae-59ca-4307-b79b-fd5b5f2f4a6b@github.com>

On Tue, 28 May 2024 18:57:07 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> OK. I was just trying to honor the apparent intent to make the comment stand out more than just a plain `//` comment, but I have no strong feelings against reducing `///` to `//`

In this case I would reduce it to '//' but others will have different opinions of course.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19130#issuecomment-2136012355

From asemenyuk at openjdk.org  Tue May 28 20:17:24 2024
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Tue, 28 May 2024 20:17:24 GMT
Subject: RFR: 8333116: test/jdk/tools/jpackage/share/ServiceTest.java test
 fails
Message-ID: <hUHU7hSA5_QIjrVTZYZ9izeUG5rl52qm8Kd0ZY5Bmas=.cf180b34-c52d-4aec-999c-350d53d06028@github.com>

Add missing "--add-opens jdk.jpackage/jdk.jpackage.internal=ALL-UNNAMED" to the test descriptor

-------------

Commit messages:
 - Add missing "--add-opens jdk.jpackage/jdk.jpackage.internal=ALL-UNNAMED" to test desc. It fixes the following error:

Changes: https://git.openjdk.org/jdk/pull/19436/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19436&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8333116
  Stats: 4 lines in 1 file changed: 2 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/19436.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19436/head:pull/19436

PR: https://git.openjdk.org/jdk/pull/19436

From redestad at openjdk.org  Tue May 28 20:24:01 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Tue, 28 May 2024 20:24:01 GMT
Subject: RFR: 8332826: Make hashCode methods in ArraysSupport friendlier
 [v2]
In-Reply-To: <FBIH-xc1qN8grLt03to-5lUHj-jOEzsSk1HPMKZLmSU=.637e8eb0-b2eb-4a0d-a84e-610a142fa5a3@github.com>
References: <ujd2AT3eYXrHPcSG0vMDe2WOx3INNPU1n0t8haKH0_M=.b1a168d7-ab4c-4920-92ef-1c72e5ffc0cf@github.com>
 <1tx_tl3PV2W5NCEXXawQY5V2ndnSOHPfjisypuhKdhA=.79840096-bac0-4da4-8102-c7ecea7cb5f0@github.com>
 <FBIH-xc1qN8grLt03to-5lUHj-jOEzsSk1HPMKZLmSU=.637e8eb0-b2eb-4a0d-a84e-610a142fa5a3@github.com>
Message-ID: <aqEt9hX5CliI-FvDQKlX1NEMw5OvyBrmcq1kP86sucI=.b07e58fb-e6a8-4df0-b21a-3e3ff8b1b36d@github.com>

On Tue, 28 May 2024 19:19:51 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix incorrect utf16 hashCode adaptation
>
> test/hotspot/jtreg/compiler/intrinsics/TestArraysHashCode.java line 88:
> 
>> 86:     private static int testIntrinsic(byte[] bytes, int type)
>> 87:             throws InvocationTargetException, IllegalAccessException {
>> 88:         return (int) vectorizedHashCode.invoke(null, bytes, 0, 256, 1, type);
> 
> Better to just call `hashCodeOfUnsigned` here I think.
> 
> The test for the non-constant type could be dropped. That is no longer a part of the 'API' of `ArraySupport`. It looks like the intrinsic bails out when the basic type is not constant any ways: https://github.com/openjdk/jdk/blob/master/src/hotspot/share/opto/library_call.cpp#L6401-L6404

The non-constant test was added because that very bailout caused a crash. The other test is actually less interesting since it'll likely be covered indirectly by regular use. But as we are hiding these away this gets ever more obscure and perhaps the test could be dropped entirely.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19414#discussion_r1617848032

From jjg at openjdk.org  Tue May 28 20:25:02 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Tue, 28 May 2024 20:25:02 GMT
Subject: RFR: 8331879: Clean up non-standard use of /// comments in
 `java.base`
In-Reply-To: <dX5j9gYZRoTrwbwqnBBpTaB6ePRafdff8hfND0QDmSc=.fa5b3aae-59ca-4307-b79b-fd5b5f2f4a6b@github.com>
References: <BiSTG8MtjyRt2txRK2DIxsmbPPq6Pvp7QQzOnHXbH6w=.b01b4872-dc8b-4e4f-bae6-bdc501da33a6@github.com>
 <2RfxVIGqDgz9gQ9xO-Mh1cex-4Zg_1wfJFvNKPdG-Ow=.1e91b688-cb86-4f8a-b50b-d94f76b90576@github.com>
 <0AiLzNg8FqqN9UajZrSXHBb2dtYCqT-TkamkXagQJMo=.28b3b8f6-105b-44d3-8be2-dc6c03e953c5@github.com>
 <dX5j9gYZRoTrwbwqnBBpTaB6ePRafdff8hfND0QDmSc=.fa5b3aae-59ca-4307-b79b-fd5b5f2f4a6b@github.com>
Message-ID: <SC3ceHNBx1KkhuZoLKzoIYPixB1_XfTJiuQmS37tOvk=.fb7e3d03-15fc-4813-b906-f634bd14e787@github.com>

On Tue, 28 May 2024 20:01:46 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> > OK. I was just trying to honor the apparent intent to make the comment stand out more than just a plain `//` comment, but I have no strong feelings against reducing `///` to `//`
> 
> In this case I would reduce it to '//' but others will have different opinions of course.

What about changing `///` to `//---` to give slightly more prominence to these comments, over plain old `//` comments.
The dashes give a small sense of a horizontal rule, to delimit sections of code.

(FWIW, I have locally edited `//|` to `//` and such comments do not stand out beside existing use of `//`.)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19130#issuecomment-2136042843

From sviswanathan at openjdk.org  Tue May 28 20:28:16 2024
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Tue, 28 May 2024 20:28:16 GMT
Subject: RFR: 8320448: Accelerate IndexOf using AVX2 [v43]
In-Reply-To: <Luyf7AUJS5vrDWsayavrN5qUJ9fkAyUv3lLdSGcDQoo=.7c7cec0d-ce11-49fc-9644-d80d50731289@github.com>
References: <uWi4QxH31hL93771gkl_GgvP0m84IRSoR_1Yi8hD17E=.bc6ed458-7081-4c3f-9348-f59358fa05a4@github.com>
 <oFs22uebWl0oFfLMtpgvsLv0U18o5uUwttHFHbTMUhI=.0f8507e2-48d2-4d92-8c66-bad4d2276774@github.com>
 <8iJLAJvIzHgXpr5P1hWOLTj-bfO6THNUJkQf7Ki2P9Y=.43680b7c-c3e1-41f8-b065-7955e6237613@github.com>
 <Luyf7AUJS5vrDWsayavrN5qUJ9fkAyUv3lLdSGcDQoo=.7c7cec0d-ce11-49fc-9644-d80d50731289@github.com>
Message-ID: <amB-2V14mDSXfu86LHe_-Epo5sginUCYjlg64etjSIk=.17134ae5-f970-4a32-918f-b7d9ae1452ac@github.com>

On Tue, 28 May 2024 17:59:49 GMT, Scott Gibbons <sgibbons at openjdk.org> wrote:

>> src/hotspot/cpu/x86/c2_stubGenerator_x86_64_string.cpp line 578:
>> 
>>> 576:     // helper jumps to L_checkRangeAndReturn with a (-1) return value.
>>> 577:     big_case_loop_helper(false, 0, L_checkRangeAndReturn, L_loopTop, mask, hsPtrRet, needleLen,
>>> 578:                          needle, haystack, hsLength, tmp1, tmp2, tmp3, rScratch, ae, _masm);
>> 
>> If we run out of haystack instead of jumping to L_checkRangeAndReturn, we could directly jump to  L_retrunError.
>
> Again, I think we ought to leave this in.  Although it executes ~3 instructions that may not be necessary in some cases I think it's best to perform the check.  Once we have a good enough test to check reading past the end of the haystack we can change it.

In this particular case, we are returning -1 (NoMatch), so no need to do L_checkRangeAndReturn here, we could directly jump to L_returnError.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1617853337

From naoto at openjdk.org  Tue May 28 20:31:02 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 28 May 2024 20:31:02 GMT
Subject: RFR: 8331879: Clean up non-standard use of /// comments in
 `java.base`
In-Reply-To: <BiSTG8MtjyRt2txRK2DIxsmbPPq6Pvp7QQzOnHXbH6w=.b01b4872-dc8b-4e4f-bae6-bdc501da33a6@github.com>
References: <BiSTG8MtjyRt2txRK2DIxsmbPPq6Pvp7QQzOnHXbH6w=.b01b4872-dc8b-4e4f-bae6-bdc501da33a6@github.com>
Message-ID: <8POTApWGgmVYc3I-AnJMa_tX63Tlb_23hsfFfF7cf1E=.f53d0c56-4d1f-42ea-a1cf-4051f4a05653@github.com>

On Tue, 7 May 2024 22:23:48 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> With the advent of JEP 467, `///` comments may be treated as documentation comments, and may be subject to the recently new `javac` warning about "dangling doc comments" in unexpected places.
> 
> In keeping with the policy to keep the `java.base` module free of all `javac` warnings, this patch proposes edits to existing uses of `///`.
> 
> There are two dominant policies in the proposed changes. 
> 1. A long horizontal line of `/////` is replaced by `//-----`
> 2. A long vertical series of lines beginning `///` is replaced by lines beginning `//|`.
> 
> As with all style changes, I have also tried to honor local usage, for consistency.
> 
> In one place, a pair of comments appeared to contain directives (`CLOVER:ON`, `CLOVER:OFF`).  I investigated the use of such comments to determine that the exact form of the comment prefix was not significant. (Phew!)
> 
> 
> (This PR is informally blocked by JEP 467).

`GregorianCalendar` and ICU4J files LGTM

-------------

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19130#pullrequestreview-2083793439

From naoto at openjdk.org  Tue May 28 20:31:04 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 28 May 2024 20:31:04 GMT
Subject: RFR: 8331879: Clean up non-standard use of /// comments in
 `java.base`
In-Reply-To: <f9vxrbiyG8nALy7dkCpZ1eqUgQCyg0Strdn_zc5qeFk=.ff6ef4b9-f39d-4900-a76e-61c7d0f1402c@github.com>
References: <BiSTG8MtjyRt2txRK2DIxsmbPPq6Pvp7QQzOnHXbH6w=.b01b4872-dc8b-4e4f-bae6-bdc501da33a6@github.com>
 <SJEc7F5iCUK5ej9Tq6De8W--UT7MqbyP62IcVNPArRY=.3a3feed7-b8e1-4a14-8a01-fe9b2b7e5bd2@github.com>
 <f9vxrbiyG8nALy7dkCpZ1eqUgQCyg0Strdn_zc5qeFk=.ff6ef4b9-f39d-4900-a76e-61c7d0f1402c@github.com>
Message-ID: <EoZMoTpe6E1I3xu0czS9FUj3brOEmagEXyCijfBemhA=.b2884274-448b-41c8-8da4-91c9cce24e46@github.com>

On Tue, 28 May 2024 18:50:38 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/icu/impl/StringPrepDataReader.java line 122:
>> 
>>> 120:      * see store.c of gennorm for more information and values
>>> 121:      */
>>> 122:     // /* dataFormat="SPRP" 0x53, 0x50, 0x52, 0x50  */
>> 
>> This source file is coming from the upstream ICU4J project. Even if this is a `non-standard` comment, I would keep it as it is to minimize the merge effort.
>
> As a non-standard comment, it will trigger a warning (and hence an error), since the prevailing standard for `java.base` is to compile with all warnings enabled (`-Xlint`) and no warnings found (verified by `-Werror`)
> 
> The alternative would be to use `@SuppressWarnings` for the `dangling-doc-comment` warning, but that too would be a code change to these imported files.

OK, we will need to live with it.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19130#discussion_r1617854422

From sviswanathan at openjdk.org  Tue May 28 20:32:16 2024
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Tue, 28 May 2024 20:32:16 GMT
Subject: RFR: 8320448: Accelerate IndexOf using AVX2 [v43]
In-Reply-To: <Luyf7AUJS5vrDWsayavrN5qUJ9fkAyUv3lLdSGcDQoo=.7c7cec0d-ce11-49fc-9644-d80d50731289@github.com>
References: <uWi4QxH31hL93771gkl_GgvP0m84IRSoR_1Yi8hD17E=.bc6ed458-7081-4c3f-9348-f59358fa05a4@github.com>
 <oFs22uebWl0oFfLMtpgvsLv0U18o5uUwttHFHbTMUhI=.0f8507e2-48d2-4d92-8c66-bad4d2276774@github.com>
 <8iJLAJvIzHgXpr5P1hWOLTj-bfO6THNUJkQf7Ki2P9Y=.43680b7c-c3e1-41f8-b065-7955e6237613@github.com>
 <Luyf7AUJS5vrDWsayavrN5qUJ9fkAyUv3lLdSGcDQoo=.7c7cec0d-ce11-49fc-9644-d80d50731289@github.com>
Message-ID: <7FujNShE9NvvlsGRZUR061xtnF-PCD8k8fmkM2kCS1I=.25525aec-f0bd-4587-b571-78d5dedc7d55@github.com>

On Tue, 28 May 2024 17:30:24 GMT, Scott Gibbons <sgibbons at openjdk.org> wrote:

>> src/hotspot/cpu/x86/c2_stubGenerator_x86_64_string.cpp line 278:
>> 
>>> 276:   __ bind(L_nextCheck);
>>> 277:   __ testq(haystack_len_p, haystack_len_p);
>>> 278:   __ je(L_zeroCheckFailed);
>> 
>> This check could be removed as the next check covers this one.
>
> No.  This is checking for a zero length haystack.  The following compare checks for needle length longer than haystack, regardless of the value in each.  The comparison is signed, so a haystack length of 0 with a needle length of -1 will pass the following test and assume validity.

But we have already checked for needle length to be greater than 0 in the following lines:
__ cmpq(needle_len_p, 0);
 __ jg_b(L_nextCheck);

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1617857240

From alanb at openjdk.org  Tue May 28 20:37:01 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 28 May 2024 20:37:01 GMT
Subject: RFR: 8331879: Clean up non-standard use of /// comments in
 `java.base`
In-Reply-To: <SC3ceHNBx1KkhuZoLKzoIYPixB1_XfTJiuQmS37tOvk=.fb7e3d03-15fc-4813-b906-f634bd14e787@github.com>
References: <BiSTG8MtjyRt2txRK2DIxsmbPPq6Pvp7QQzOnHXbH6w=.b01b4872-dc8b-4e4f-bae6-bdc501da33a6@github.com>
 <2RfxVIGqDgz9gQ9xO-Mh1cex-4Zg_1wfJFvNKPdG-Ow=.1e91b688-cb86-4f8a-b50b-d94f76b90576@github.com>
 <0AiLzNg8FqqN9UajZrSXHBb2dtYCqT-TkamkXagQJMo=.28b3b8f6-105b-44d3-8be2-dc6c03e953c5@github.com>
 <dX5j9gYZRoTrwbwqnBBpTaB6ePRafdff8hfND0QDmSc=.fa5b3aae-59ca-4307-b79b-fd5b5f2f4a6b@github.com>
 <SC3ceHNBx1KkhuZoLKzoIYPixB1_XfTJiuQmS37tOvk=.fb7e3d03-15fc-4813-b906-f634bd14e787@github.com>
Message-ID: <3LvqqG1kXgsMgY-FyY5f3vH4nx7DYcD6979slljNj3s=.000a8d65-1fa5-4546-b4fd-5878a79104ce@github.com>

On Tue, 28 May 2024 20:22:24 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> What about changing `///` to `//---` to give slightly more prominence to these comments, over plain old `//` comments. The dashes give a small sense of a horizontal rule, to delimit sections of code.
> 
> (FWIW, I have locally edited `//|` to `//` and such comments do not stand out beside existing use of `//`.)

`//---` seems okay, it would stand out a bit more.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19130#issuecomment-2136060411

From sviswanathan at openjdk.org  Tue May 28 20:40:17 2024
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Tue, 28 May 2024 20:40:17 GMT
Subject: RFR: 8320448: Accelerate IndexOf using AVX2 [v43]
In-Reply-To: <Luyf7AUJS5vrDWsayavrN5qUJ9fkAyUv3lLdSGcDQoo=.7c7cec0d-ce11-49fc-9644-d80d50731289@github.com>
References: <uWi4QxH31hL93771gkl_GgvP0m84IRSoR_1Yi8hD17E=.bc6ed458-7081-4c3f-9348-f59358fa05a4@github.com>
 <oFs22uebWl0oFfLMtpgvsLv0U18o5uUwttHFHbTMUhI=.0f8507e2-48d2-4d92-8c66-bad4d2276774@github.com>
 <8iJLAJvIzHgXpr5P1hWOLTj-bfO6THNUJkQf7Ki2P9Y=.43680b7c-c3e1-41f8-b065-7955e6237613@github.com>
 <Luyf7AUJS5vrDWsayavrN5qUJ9fkAyUv3lLdSGcDQoo=.7c7cec0d-ce11-49fc-9644-d80d50731289@github.com>
Message-ID: <HDdDsFDQcnWcnRCr2XT1hyleoLW-M9NhrLbQ74TOjgo=.4a45295e-fca8-48c1-aeb8-0b2bcb195cff@github.com>

On Tue, 28 May 2024 18:11:13 GMT, Scott Gibbons <sgibbons at openjdk.org> wrote:

>> src/hotspot/cpu/x86/c2_stubGenerator_x86_64_string.cpp line 1333:
>> 
>>> 1331: 
>>> 1332:   __ cmpq(nMinusK, 32);
>>> 1333:   __ jae_b(L_greaterThan32);
>> 
>> Should this check be (n-k+1) >= 32? And so accordingly (n-k) >= 31
>>  __ cmpq(nMinusK, 31);
>>  __ jae_b(L_greaterThan32);
>
> No. For (n-k)==32 we can do full reads.  I'll clarify by changing the label name.

We can also do full reads for (n-k) == 31, as we also compare the kth byte.

>> src/hotspot/cpu/x86/c2_stubGenerator_x86_64_string.cpp line 1750:
>> 
>>> 1748:     //  r15 = unused
>>> 1749:     //  XMM_BYTE_0 - first element of needle, broadcast
>>> 1750:     //  XMM_BYTE_K - last element of needle, broadcast
>> 
>> This comment is duplicated for both small haystack case and big haystack case, could be made a common comment. 
>> Also the only registers that are used as input in the switch case are:
>> r14 = needle
>> rbx = haystack
>> rsi = haystack length (n)
>> r12 = needle length (k)
>> r10 = n - k (where k is needle length)
>> XMM_BYTE_0 = first element of needle, broadcast
>> XMM_BYTE_K = last element of needle, broadcast
>> So we could only list these, making it easier to comprehend.
>
> I listed all registers for clarity.  This ensures that we know what can be used as values or as scratch registers with no ambiguity.

Sounds good. We could keep only comment out of the two as it is the same for both small haystack and big haystack.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1617862799
PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1617865049

From redestad at openjdk.org  Tue May 28 20:43:02 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Tue, 28 May 2024 20:43:02 GMT
Subject: RFR: 8332826: Make hashCode methods in ArraysSupport friendlier
 [v2]
In-Reply-To: <FBIH-xc1qN8grLt03to-5lUHj-jOEzsSk1HPMKZLmSU=.637e8eb0-b2eb-4a0d-a84e-610a142fa5a3@github.com>
References: <ujd2AT3eYXrHPcSG0vMDe2WOx3INNPU1n0t8haKH0_M=.b1a168d7-ab4c-4920-92ef-1c72e5ffc0cf@github.com>
 <1tx_tl3PV2W5NCEXXawQY5V2ndnSOHPfjisypuhKdhA=.79840096-bac0-4da4-8102-c7ecea7cb5f0@github.com>
 <FBIH-xc1qN8grLt03to-5lUHj-jOEzsSk1HPMKZLmSU=.637e8eb0-b2eb-4a0d-a84e-610a142fa5a3@github.com>
Message-ID: <Tp-e5hM6KkSCm7JvRiMLRKL4nuB_HSb_UUrV4Xk3DOk=.72009f0d-35fb-4d95-8af8-05ad7410e41d@github.com>

On Tue, 28 May 2024 19:13:30 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix incorrect utf16 hashCode adaptation
>
> src/java.base/share/classes/jdk/internal/util/ArraysSupport.java line 275:
> 
>> 273:         return switch (length) {
>> 274:             case 0 -> initialValue;
>> 275:             case 1 -> 31 * initialValue + (a[fromIndex] & 0xff);
> 
> For clarity, if you think it helps:
> Suggestion:
> 
>             case 1 -> 31 * initialValue + Byte.toUnsignedInt(a[fromIndex]);

I don't care as long as microbenchmarks don't get a hiccup.

> src/java.base/share/classes/jdk/internal/util/ArraysSupport.java line 301:
> 
>> 299:         return switch (length) {
>> 300:             case 0 -> initialValue;
>> 301:             case 1 -> 31 * initialValue + JLA.getUTF16Char(a, fromIndex);
> 
> There seems to be a mismatch here with the original code in StringUTF16, where the length that is tested for is `2` instead of `1`.

Yes, should be `2` (`a` is semantically a `char[]`). This typo likely pass functional testing since `1` can never happen in practice, and the default case should work for any value. There might be a String microbenchmark out there that might be slightly unhappy, though.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19414#discussion_r1617867797
PR Review Comment: https://git.openjdk.org/jdk/pull/19414#discussion_r1617865658

From sgibbons at openjdk.org  Tue May 28 20:54:15 2024
From: sgibbons at openjdk.org (Scott Gibbons)
Date: Tue, 28 May 2024 20:54:15 GMT
Subject: RFR: 8320448: Accelerate IndexOf using AVX2 [v43]
In-Reply-To: <7FujNShE9NvvlsGRZUR061xtnF-PCD8k8fmkM2kCS1I=.25525aec-f0bd-4587-b571-78d5dedc7d55@github.com>
References: <uWi4QxH31hL93771gkl_GgvP0m84IRSoR_1Yi8hD17E=.bc6ed458-7081-4c3f-9348-f59358fa05a4@github.com>
 <oFs22uebWl0oFfLMtpgvsLv0U18o5uUwttHFHbTMUhI=.0f8507e2-48d2-4d92-8c66-bad4d2276774@github.com>
 <8iJLAJvIzHgXpr5P1hWOLTj-bfO6THNUJkQf7Ki2P9Y=.43680b7c-c3e1-41f8-b065-7955e6237613@github.com>
 <Luyf7AUJS5vrDWsayavrN5qUJ9fkAyUv3lLdSGcDQoo=.7c7cec0d-ce11-49fc-9644-d80d50731289@github.com>
 <7FujNShE9NvvlsGRZUR061xtnF-PCD8k8fmkM2kCS1I=.25525aec-f0bd-4587-b571-78d5dedc7d55@github.com>
Message-ID: <pERlGMw7XxkMU487lEL9kL3IOQsJ_UeXTIeEzUrJEoQ=.2d54e9f1-136e-4a36-83eb-401534704546@github.com>

On Tue, 28 May 2024 20:29:38 GMT, Sandhya Viswanathan <sviswanathan at openjdk.org> wrote:

>> No.  This is checking for a zero length haystack.  The following compare checks for needle length longer than haystack, regardless of the value in each.  The comparison is signed, so a haystack length of 0 with a needle length of -1 will pass the following test and assume validity.
>
> But we have already checked for needle length to be greater than 0 in the following lines:
> __ cmpq(needle_len_p, 0);
>  __ jg_b(L_nextCheck);

OK

>> Again, I think we ought to leave this in.  Although it executes ~3 instructions that may not be necessary in some cases I think it's best to perform the check.  Once we have a good enough test to check reading past the end of the haystack we can change it.
>
> In this particular case, we are returning -1 (NoMatch), so no need to do L_checkRangeAndReturn here, we could directly jump to L_returnError.

OK.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1617876757
PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1617874637

From sgibbons at openjdk.org  Tue May 28 20:59:16 2024
From: sgibbons at openjdk.org (Scott Gibbons)
Date: Tue, 28 May 2024 20:59:16 GMT
Subject: RFR: 8320448: Accelerate IndexOf using AVX2 [v43]
In-Reply-To: <HDdDsFDQcnWcnRCr2XT1hyleoLW-M9NhrLbQ74TOjgo=.4a45295e-fca8-48c1-aeb8-0b2bcb195cff@github.com>
References: <uWi4QxH31hL93771gkl_GgvP0m84IRSoR_1Yi8hD17E=.bc6ed458-7081-4c3f-9348-f59358fa05a4@github.com>
 <oFs22uebWl0oFfLMtpgvsLv0U18o5uUwttHFHbTMUhI=.0f8507e2-48d2-4d92-8c66-bad4d2276774@github.com>
 <8iJLAJvIzHgXpr5P1hWOLTj-bfO6THNUJkQf7Ki2P9Y=.43680b7c-c3e1-41f8-b065-7955e6237613@github.com>
 <Luyf7AUJS5vrDWsayavrN5qUJ9fkAyUv3lLdSGcDQoo=.7c7cec0d-ce11-49fc-9644-d80d50731289@github.com>
 <HDdDsFDQcnWcnRCr2XT1hyleoLW-M9NhrLbQ74TOjgo=.4a45295e-fca8-48c1-aeb8-0b2bcb195cff@github.com>
Message-ID: <oIFRZTMoYpvsPhycohsgZbWa2GdaqzwqgQ_nLlJ0Dwg=.769c88f7-9c95-4457-91ba-32e2ae30701a@github.com>

On Tue, 28 May 2024 20:35:26 GMT, Sandhya Viswanathan <sviswanathan at openjdk.org> wrote:

>> No. For (n-k)==32 we can do full reads.  I'll clarify by changing the label name.
>
> We can also do full reads for (n-k) == 31, as we also compare the kth byte.

I'll change and test.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1617883225

From asemenyuk at openjdk.org  Tue May 28 21:02:01 2024
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Tue, 28 May 2024 21:02:01 GMT
Subject: RFR: 8333116: test/jdk/tools/jpackage/share/ServiceTest.java test
 fails
In-Reply-To: <hUHU7hSA5_QIjrVTZYZ9izeUG5rl52qm8Kd0ZY5Bmas=.cf180b34-c52d-4aec-999c-350d53d06028@github.com>
References: <hUHU7hSA5_QIjrVTZYZ9izeUG5rl52qm8Kd0ZY5Bmas=.cf180b34-c52d-4aec-999c-350d53d06028@github.com>
Message-ID: <95Z4yx3i6hozPV5CSX2LsQAXHLJybv7xo0MViWOg864=.812f33a0-bfc7-47a0-8477-8f5819bb8a99@github.com>

On Tue, 28 May 2024 20:13:24 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> Add missing "--add-opens jdk.jpackage/jdk.jpackage.internal=ALL-UNNAMED" to the test descriptor

@sashamatveev please review

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19436#issuecomment-2136094953

From duke at openjdk.org  Tue May 28 21:06:14 2024
From: duke at openjdk.org (Volodymyr Paprotski)
Date: Tue, 28 May 2024 21:06:14 GMT
Subject: RFR: 8320448: Accelerate IndexOf using AVX2 [v43]
In-Reply-To: <Luyf7AUJS5vrDWsayavrN5qUJ9fkAyUv3lLdSGcDQoo=.7c7cec0d-ce11-49fc-9644-d80d50731289@github.com>
References: <uWi4QxH31hL93771gkl_GgvP0m84IRSoR_1Yi8hD17E=.bc6ed458-7081-4c3f-9348-f59358fa05a4@github.com>
 <oFs22uebWl0oFfLMtpgvsLv0U18o5uUwttHFHbTMUhI=.0f8507e2-48d2-4d92-8c66-bad4d2276774@github.com>
 <8iJLAJvIzHgXpr5P1hWOLTj-bfO6THNUJkQf7Ki2P9Y=.43680b7c-c3e1-41f8-b065-7955e6237613@github.com>
 <Luyf7AUJS5vrDWsayavrN5qUJ9fkAyUv3lLdSGcDQoo=.7c7cec0d-ce11-49fc-9644-d80d50731289@github.com>
Message-ID: <xv1-IcbRKzPgvp9ZS9HKLT2jhGn6-p82Pf-KDe7TfQg=.5ef024c7-8323-42c1-9bd3-d65d79fba224@github.com>

On Tue, 28 May 2024 17:36:03 GMT, Scott Gibbons <sgibbons at openjdk.org> wrote:

>> src/hotspot/cpu/x86/c2_stubGenerator_x86_64_string.cpp line 488:
>> 
>>> 486:   __ cmpq(r11, nMinusK);
>>> 487:   __ ja_b(L_return);
>>> 488:   __ movq(rax, r11);
>> 
>> At places where we know that return value in r11 is correct, we dont need to checkRange so this could have its own label.
>
> I don't want to change this because its reason for existence is to ensure we don't return a value that's beyond the end of the haystack.  We don't yet have a good enough test to validate whether we're reading past the end of the haystack, so I like this as insurance.

I would recommend an experiment. Disable the range-check and run String/IndexOf.java test. Particularly run test4(), which is designed exactly to test the reads beyond the end. 

It wont find all the bad reads, but right now if there are any failures, they are 'hidden' by this range-check.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1617888680

From sgibbons at openjdk.org  Tue May 28 21:06:15 2024
From: sgibbons at openjdk.org (Scott Gibbons)
Date: Tue, 28 May 2024 21:06:15 GMT
Subject: RFR: 8320448: Accelerate IndexOf using AVX2 [v43]
In-Reply-To: <HDdDsFDQcnWcnRCr2XT1hyleoLW-M9NhrLbQ74TOjgo=.4a45295e-fca8-48c1-aeb8-0b2bcb195cff@github.com>
References: <uWi4QxH31hL93771gkl_GgvP0m84IRSoR_1Yi8hD17E=.bc6ed458-7081-4c3f-9348-f59358fa05a4@github.com>
 <oFs22uebWl0oFfLMtpgvsLv0U18o5uUwttHFHbTMUhI=.0f8507e2-48d2-4d92-8c66-bad4d2276774@github.com>
 <8iJLAJvIzHgXpr5P1hWOLTj-bfO6THNUJkQf7Ki2P9Y=.43680b7c-c3e1-41f8-b065-7955e6237613@github.com>
 <Luyf7AUJS5vrDWsayavrN5qUJ9fkAyUv3lLdSGcDQoo=.7c7cec0d-ce11-49fc-9644-d80d50731289@github.com>
 <HDdDsFDQcnWcnRCr2XT1hyleoLW-M9NhrLbQ74TOjgo=.4a45295e-fca8-48c1-aeb8-0b2bcb195cff@github.com>
Message-ID: <BFXjvIvFXfEnzs531QlFsE-R-ZhYBOVZqULGQCYa8sg=.d37bb723-db44-46ac-8064-1325c13b230a@github.com>

On Tue, 28 May 2024 20:37:43 GMT, Sandhya Viswanathan <sviswanathan at openjdk.org> wrote:

>> I listed all registers for clarity.  This ensures that we know what can be used as values or as scratch registers with no ambiguity.
>
> Sounds good. We could keep only comment out of the two as it is the same for both small haystack and big haystack.

OK

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1617889756

From sgibbons at openjdk.org  Tue May 28 21:06:14 2024
From: sgibbons at openjdk.org (Scott Gibbons)
Date: Tue, 28 May 2024 21:06:14 GMT
Subject: RFR: 8320448: Accelerate IndexOf using AVX2 [v43]
In-Reply-To: <oIFRZTMoYpvsPhycohsgZbWa2GdaqzwqgQ_nLlJ0Dwg=.769c88f7-9c95-4457-91ba-32e2ae30701a@github.com>
References: <uWi4QxH31hL93771gkl_GgvP0m84IRSoR_1Yi8hD17E=.bc6ed458-7081-4c3f-9348-f59358fa05a4@github.com>
 <oFs22uebWl0oFfLMtpgvsLv0U18o5uUwttHFHbTMUhI=.0f8507e2-48d2-4d92-8c66-bad4d2276774@github.com>
 <8iJLAJvIzHgXpr5P1hWOLTj-bfO6THNUJkQf7Ki2P9Y=.43680b7c-c3e1-41f8-b065-7955e6237613@github.com>
 <Luyf7AUJS5vrDWsayavrN5qUJ9fkAyUv3lLdSGcDQoo=.7c7cec0d-ce11-49fc-9644-d80d50731289@github.com>
 <HDdDsFDQcnWcnRCr2XT1hyleoLW-M9NhrLbQ74TOjgo=.4a45295e-fca8-48c1-aeb8-0b2bcb195cff@github.com>
 <oIFRZTMoYpvsPhycohsgZbWa2GdaqzwqgQ_nLlJ0Dwg=.769c88f7-9c95-4457-91ba-32e2ae30701a@github.com>
Message-ID: <H5uppi4vKZSRCIv9tBWu-jgVdYOo4N6du7gSTdd-2ag=.4f3732af-1a92-4d24-92e6-2a0f5c1eb628@github.com>

On Tue, 28 May 2024 20:56:42 GMT, Scott Gibbons <sgibbons at openjdk.org> wrote:

>> We can also do full reads for (n-k) == 31, as we also compare the kth byte.
>
> I'll change and test.

Passes tests, so I'll change.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1617886613

From sgibbons at openjdk.org  Tue May 28 21:12:16 2024
From: sgibbons at openjdk.org (Scott Gibbons)
Date: Tue, 28 May 2024 21:12:16 GMT
Subject: RFR: 8320448: Accelerate IndexOf using AVX2 [v37]
In-Reply-To: <CiGyOjJRAxrpvCiabceN1M1AvbWQz2orh4YQ8YQ4jl0=.1ebff8e5-15cd-44ee-a92a-1161f8744215@github.com>
References: <uWi4QxH31hL93771gkl_GgvP0m84IRSoR_1Yi8hD17E=.bc6ed458-7081-4c3f-9348-f59358fa05a4@github.com>
 <4xYUBsOJ_eDSuj6w9AjUo_6gFN_9piWR-ChLrHQoXl4=.88756684-8e9c-48e3-8b59-f5f684b81cde@github.com>
 <JKRjYVdOhgtD-GeDuecIVQ4hth9JFdfNdt_NFhgoZhg=.95c14b1f-c149-45df-b825-d30152aa0416@github.com>
 <CiGyOjJRAxrpvCiabceN1M1AvbWQz2orh4YQ8YQ4jl0=.1ebff8e5-15cd-44ee-a92a-1161f8744215@github.com>
Message-ID: <hPUj1QMfDI_F0OKo54x84zwUczEWKGDvB909a046Waw=.2c8a4d35-d9b3-4039-9fff-efffcdca5d53@github.com>

On Fri, 24 May 2024 20:42:12 GMT, Scott Gibbons <sgibbons at openjdk.org> wrote:

>> test/jdk/java/lang/StringBuffer/ECoreIndexOf.java line 185:
>> 
>>> 183:   }
>>> 184: 
>>> 185:   private static int indexOfKernel(String haystack, String needle) {
>> 
>> Is the intention of kernels not to be inlined so that it would be part of separate compilation?
>> 
>> If so, you probably want to annotate it with `@CompilerControl(CompilerControl.Mode.DONT_INLINE)`
>> 
>> i.e. https://github.com/openjdk/jmh/blob/master/jmh-samples/src/main/java/org/openjdk/jmh/samples/JMHSample_16_CompilerControl.java
>
> Fixed.

CompilerControl is unavailable here.  Added a runtime option instead.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1617894475

From sgibbons at openjdk.org  Tue May 28 21:12:16 2024
From: sgibbons at openjdk.org (Scott Gibbons)
Date: Tue, 28 May 2024 21:12:16 GMT
Subject: RFR: 8320448: Accelerate IndexOf using AVX2 [v38]
In-Reply-To: <7jqyfDXW_EbstH_s90Fp4O7a214ZaejdM0CyAffzOHs=.544c7a91-c66b-4487-a2bf-0b8e300a94c0@github.com>
References: <uWi4QxH31hL93771gkl_GgvP0m84IRSoR_1Yi8hD17E=.bc6ed458-7081-4c3f-9348-f59358fa05a4@github.com>
 <nDwq515-pZGnnCsqW0nkRtlqIyhnvqKXFTydeaXztHo=.eb511293-d67b-4a06-b792-264087af40d0@github.com>
 <MImPmWGxi3FpwVq1rk0Rohfh3_5H_iqAgblEpn8_TQQ=.cbb5359c-d8df-48b8-8a0f-e9976923475f@github.com>
 <DEIgE5V0yqkQUTe5KWlFvLmApPYpP2JGMcUlpkuvt4U=.89e9cddd-3a3c-445b-9080-cb0eaca0a963@github.com>
 <7jqyfDXW_EbstH_s90Fp4O7a214ZaejdM0CyAffzOHs=.544c7a91-c66b-4487-a2bf-0b8e300a94c0@github.com>
Message-ID: <m-0k3Vr5718X-N5HujUj506usjtrYRxDZZxDWBbx5Qw=.b087999c-c798-4d9c-8a98-359daeff26cb@github.com>

On Tue, 28 May 2024 16:57:54 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> @vnkozlov I'm getting an error in CI tests with this line added.  Can you please advise?
>> 
>> `TEST RESULT: Error. Parse Exception: Syntax error in @requires expression: invalid name: vm.cpu.features`
>
> You need to add `vm.cpu.features ` line to `test/jdk/TEST.ROOT` file. Similar to what we have in `test/hotspot/jtreg/TEST.ROOT`

Fixed.  Thanks.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1617893462

From sgibbons at openjdk.org  Tue May 28 21:20:15 2024
From: sgibbons at openjdk.org (Scott Gibbons)
Date: Tue, 28 May 2024 21:20:15 GMT
Subject: RFR: 8320448: Accelerate IndexOf using AVX2 [v43]
In-Reply-To: <8iJLAJvIzHgXpr5P1hWOLTj-bfO6THNUJkQf7Ki2P9Y=.43680b7c-c3e1-41f8-b065-7955e6237613@github.com>
References: <uWi4QxH31hL93771gkl_GgvP0m84IRSoR_1Yi8hD17E=.bc6ed458-7081-4c3f-9348-f59358fa05a4@github.com>
 <oFs22uebWl0oFfLMtpgvsLv0U18o5uUwttHFHbTMUhI=.0f8507e2-48d2-4d92-8c66-bad4d2276774@github.com>
 <8iJLAJvIzHgXpr5P1hWOLTj-bfO6THNUJkQf7Ki2P9Y=.43680b7c-c3e1-41f8-b065-7955e6237613@github.com>
Message-ID: <Bf57ojt82TeuzzFicVTBNKMHxM9y76FBh8IfTKLziGU=.125bacfb-17ae-4fa4-bc3a-c6c5a3493761@github.com>

On Tue, 28 May 2024 16:37:23 GMT, Sandhya Viswanathan <sviswanathan at openjdk.org> wrote:

>> Scott Gibbons has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix tests
>
> src/hotspot/cpu/x86/c2_stubGenerator_x86_64_string.cpp line 488:
> 
>> 486:   __ cmpq(r11, nMinusK);
>> 487:   __ ja_b(L_return);
>> 488:   __ movq(rax, r11);
> 
> At places where we know that return value in r11 is correct, we dont need to checkRange so this could have its own label.

Disabling causes the test to succeed, so we're not finding matches beyond the end of the string, correct?  Are we confident that this test passing can warrant removing the range check? @sviswa7 ?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1617901070

From almatvee at openjdk.org  Tue May 28 21:38:00 2024
From: almatvee at openjdk.org (Alexander Matveev)
Date: Tue, 28 May 2024 21:38:00 GMT
Subject: RFR: 8332110: [macos] jpackage tries to sign added files without
 the --mac-sign option
In-Reply-To: <eiboU_LgwkTte_7rkPJAdDm1x_-Pzm8rdwUiY_4MAYI=.b982e161-fe24-44ab-9db5-2f1d80eb0d99@github.com>
References: <eiboU_LgwkTte_7rkPJAdDm1x_-Pzm8rdwUiY_4MAYI=.b982e161-fe24-44ab-9db5-2f1d80eb0d99@github.com>
Message-ID: <5tJ6-nSQbxgRfL6CFhA6wzpTUMgopG7uHUs6vYwqpRo=.712c3c28-5a64-4f6e-ac77-8768d7acc077@github.com>

On Fri, 24 May 2024 01:08:03 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

> This issue is reproducible with and without `--mac-sign`. jpackage will "_ad-hoc_" sign application bundle when `--mac-sign` is not specified by using pseudo-identity "_-_". This is why jpackage tries to sign added files and this is expected behavior by jpackage. "codesign" fails since added content made application bundle structure invalid. There is nothing we can do on jpackage side to sign such invalid bundles. As proposed solution we will output possible reason for "codesign" failure if it fails and `--app-content` was specified and possible solution. Proposed message: "One of the possible reason for "codesign" failure is additional content provided via "--app-content", which made application bundle structure invalid. Make sure to provide additional content in a way it will not break application bundle structure, otherwise add additional content as post-processing step."
> 
> Example:
> Lets assume we have "ReadMe" folder with "ReadMe.txt" file in it.
> 1) jpackage --type app-image -n Test --app-content ReadMe/ReadMe.txt ...
> "codesign" will fail with "In subcomponent: Test.app/Contents/ReadMe.txt". This is expected and "ReadMe.txt" placed in "Test.app/Contents" which is also expected.
> 2) jpackage --type app-image -n Test --app-content ReadMe ...
> Works and "ReadMe.txt" will be placed under "Test.app/Contents/ReadMe".
> 
> Sample output before fix:
> 
> Error: "codesign" failed with following output:
> Test.app: replacing existing signature
> Test.app: code object is not signed at all
> In subcomponent: Test.app/Contents/ReadMe.txt
> 
> 
> Sample output after fix:
> 
> One of the possible reason for "codesign" failure is additional content provided via "--app-content", which made application bundle structure invalid. Make sure to provide additional content in a way it will not break application bundle structure, otherwise add additional content as post-processing step.
> Error: "codesign" failed with following output:
> Test.app: replacing existing signature
> Test.app: code object is not signed at all
> In subcomponent: Test.app/Contents/ReadMe.txt

@alexeysemenyukoracle please review

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19377#issuecomment-2136148629

From almatvee at openjdk.org  Tue May 28 21:42:04 2024
From: almatvee at openjdk.org (Alexander Matveev)
Date: Tue, 28 May 2024 21:42:04 GMT
Subject: RFR: 8333116: test/jdk/tools/jpackage/share/ServiceTest.java test
 fails
In-Reply-To: <hUHU7hSA5_QIjrVTZYZ9izeUG5rl52qm8Kd0ZY5Bmas=.cf180b34-c52d-4aec-999c-350d53d06028@github.com>
References: <hUHU7hSA5_QIjrVTZYZ9izeUG5rl52qm8Kd0ZY5Bmas=.cf180b34-c52d-4aec-999c-350d53d06028@github.com>
Message-ID: <lTT0sv8pIklO79fdp7PDT10DeR523iycw1vDocQ34_c=.191776c2-0c97-4589-b076-4ac0b83a0b6a@github.com>

On Tue, 28 May 2024 20:13:24 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> Add missing "--add-opens jdk.jpackage/jdk.jpackage.internal=ALL-UNNAMED" to the test descriptor

Looks good.

-------------

Marked as reviewed by almatvee (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19436#pullrequestreview-2083892285

From asemenyuk at openjdk.org  Tue May 28 21:42:05 2024
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Tue, 28 May 2024 21:42:05 GMT
Subject: Integrated: 8333116: test/jdk/tools/jpackage/share/ServiceTest.java
 test fails
In-Reply-To: <hUHU7hSA5_QIjrVTZYZ9izeUG5rl52qm8Kd0ZY5Bmas=.cf180b34-c52d-4aec-999c-350d53d06028@github.com>
References: <hUHU7hSA5_QIjrVTZYZ9izeUG5rl52qm8Kd0ZY5Bmas=.cf180b34-c52d-4aec-999c-350d53d06028@github.com>
Message-ID: <u6BKqpGRo52LL-MtbOKJ8Ox4GEvK0y4L7HA8WW9xQHQ=.39b9f699-49de-486d-91cc-8f618cfeab64@github.com>

On Tue, 28 May 2024 20:13:24 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> Add missing "--add-opens jdk.jpackage/jdk.jpackage.internal=ALL-UNNAMED" to the test descriptor

This pull request has now been integrated.

Changeset: 91ab088d
Author:    Alexey Semenyuk <asemenyuk at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/91ab088d5e64e068bafcda8d08f1769c39ba10d6
Stats:     4 lines in 1 file changed: 2 ins; 0 del; 2 mod

8333116: test/jdk/tools/jpackage/share/ServiceTest.java test fails

Reviewed-by: almatvee

-------------

PR: https://git.openjdk.org/jdk/pull/19436

From prappo at openjdk.org  Tue May 28 22:13:01 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Tue, 28 May 2024 22:13:01 GMT
Subject: RFR: 8332826: Make hashCode methods in ArraysSupport friendlier
 [v2]
In-Reply-To: <Tp-e5hM6KkSCm7JvRiMLRKL4nuB_HSb_UUrV4Xk3DOk=.72009f0d-35fb-4d95-8af8-05ad7410e41d@github.com>
References: <ujd2AT3eYXrHPcSG0vMDe2WOx3INNPU1n0t8haKH0_M=.b1a168d7-ab4c-4920-92ef-1c72e5ffc0cf@github.com>
 <1tx_tl3PV2W5NCEXXawQY5V2ndnSOHPfjisypuhKdhA=.79840096-bac0-4da4-8102-c7ecea7cb5f0@github.com>
 <FBIH-xc1qN8grLt03to-5lUHj-jOEzsSk1HPMKZLmSU=.637e8eb0-b2eb-4a0d-a84e-610a142fa5a3@github.com>
 <Tp-e5hM6KkSCm7JvRiMLRKL4nuB_HSb_UUrV4Xk3DOk=.72009f0d-35fb-4d95-8af8-05ad7410e41d@github.com>
Message-ID: <qlBhTcZ9jGgKULL58_D41n40d0vcuDybgl84tS1dghU=.b3ffa540-2ad0-44c4-8ade-17d690122778@github.com>

On Tue, 28 May 2024 20:38:21 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/util/ArraysSupport.java line 301:
>> 
>>> 299:         return switch (length) {
>>> 300:             case 0 -> initialValue;
>>> 301:             case 1 -> 31 * initialValue + JLA.getUTF16Char(a, fromIndex);
>> 
>> There seems to be a mismatch here with the original code in StringUTF16, where the length that is tested for is `2` instead of `1`.
>
> Yes, should be `2` (`a` is semantically a `char[]`). This typo likely pass functional testing since `1` can never happen in practice, and the default case should work for any value. There might be a String microbenchmark out there that might be slightly unhappy, though.

I believe, it should be `1`. Hear me out. In this method, the `length` is scaled down, whereas in `StringUTF16` it is not. In this method, it's `length`, in `StringUTF16` it's `((byte[]) value).length`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19414#discussion_r1617941436

From prappo at openjdk.org  Tue May 28 22:23:01 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Tue, 28 May 2024 22:23:01 GMT
Subject: RFR: 8332826: Make hashCode methods in ArraysSupport friendlier
 [v2]
In-Reply-To: <qlBhTcZ9jGgKULL58_D41n40d0vcuDybgl84tS1dghU=.b3ffa540-2ad0-44c4-8ade-17d690122778@github.com>
References: <ujd2AT3eYXrHPcSG0vMDe2WOx3INNPU1n0t8haKH0_M=.b1a168d7-ab4c-4920-92ef-1c72e5ffc0cf@github.com>
 <1tx_tl3PV2W5NCEXXawQY5V2ndnSOHPfjisypuhKdhA=.79840096-bac0-4da4-8102-c7ecea7cb5f0@github.com>
 <FBIH-xc1qN8grLt03to-5lUHj-jOEzsSk1HPMKZLmSU=.637e8eb0-b2eb-4a0d-a84e-610a142fa5a3@github.com>
 <Tp-e5hM6KkSCm7JvRiMLRKL4nuB_HSb_UUrV4Xk3DOk=.72009f0d-35fb-4d95-8af8-05ad7410e41d@github.com>
 <qlBhTcZ9jGgKULL58_D41n40d0vcuDybgl84tS1dghU=.b3ffa540-2ad0-44c4-8ade-17d690122778@github.com>
Message-ID: <m6okZxhUfvRDlSMs4lwSIsOScyEuDsQqYUJ_AXTFJx0=.7f0a9af8-b55f-4491-8c36-1975c4271a17@github.com>

On Tue, 28 May 2024 22:08:06 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Yes, should be `2` (`a` is semantically a `char[]`). This typo likely pass functional testing since `1` can never happen in practice, and the default case should work for any value. There might be a String microbenchmark out there that might be slightly unhappy, though.
>
> I believe, it should be `1`. Hear me out. In this method, the `length` is scaled down, whereas in `StringUTF16` it is not. In this method, it's `length`, in `StringUTF16` it's `((byte[]) value).length`.

In fact, if I change it to `2`, the following tests will fail:

  - `jdk/jdk/classfile/Utf8EntryTest.java`
  - `jdk/java/util/zip/ZipCoding.java`
  - `jdk/java/text/Format/MessageFormat/MessageRegression.java`

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19414#discussion_r1617950633

From jjg at openjdk.org  Tue May 28 22:31:15 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Tue, 28 May 2024 22:31:15 GMT
Subject: RFR: 8331879: Clean up non-standard use of /// comments in
 `java.base` [v2]
In-Reply-To: <BiSTG8MtjyRt2txRK2DIxsmbPPq6Pvp7QQzOnHXbH6w=.b01b4872-dc8b-4e4f-bae6-bdc501da33a6@github.com>
References: <BiSTG8MtjyRt2txRK2DIxsmbPPq6Pvp7QQzOnHXbH6w=.b01b4872-dc8b-4e4f-bae6-bdc501da33a6@github.com>
Message-ID: <PkVqSQtpxtoqeA6HppVjaaktDiquGqXkNT_v49aK-vM=.ea0d04b6-5b0d-487b-8b2b-190954ca5a7a@github.com>

> With the advent of JEP 467, `///` comments may be treated as documentation comments, and may be subject to the recently new `javac` warning about "dangling doc comments" in unexpected places.
> 
> In keeping with the policy to keep the `java.base` module free of all `javac` warnings, this patch proposes edits to existing uses of `///`.
> 
> There are two dominant policies in the proposed changes. 
> 1. A long horizontal line of `/////` is replaced by `//-----`
> 2. A long vertical series of lines beginning `///` is replaced by lines beginning `//|`.
> 
> As with all style changes, I have also tried to honor local usage, for consistency.
> 
> In one place, a pair of comments appeared to contain directives (`CLOVER:ON`, `CLOVER:OFF`).  I investigated the use of such comments to determine that the exact form of the comment prefix was not significant. (Phew!)
> 
> 
> (This PR is informally blocked by JEP 467).

Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision:

  incorporate review comments

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19130/files
  - new: https://git.openjdk.org/jdk/pull/19130/files/3e039b43..e77a4d14

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19130&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19130&range=00-01

  Stats: 24 lines in 7 files changed: 0 ins; 0 del; 24 mod
  Patch: https://git.openjdk.org/jdk/pull/19130.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19130/head:pull/19130

PR: https://git.openjdk.org/jdk/pull/19130

From sgibbons at openjdk.org  Tue May 28 22:33:18 2024
From: sgibbons at openjdk.org (Scott Gibbons)
Date: Tue, 28 May 2024 22:33:18 GMT
Subject: RFR: 8320448: Accelerate IndexOf using AVX2 [v43]
In-Reply-To: <Bf57ojt82TeuzzFicVTBNKMHxM9y76FBh8IfTKLziGU=.125bacfb-17ae-4fa4-bc3a-c6c5a3493761@github.com>
References: <uWi4QxH31hL93771gkl_GgvP0m84IRSoR_1Yi8hD17E=.bc6ed458-7081-4c3f-9348-f59358fa05a4@github.com>
 <oFs22uebWl0oFfLMtpgvsLv0U18o5uUwttHFHbTMUhI=.0f8507e2-48d2-4d92-8c66-bad4d2276774@github.com>
 <8iJLAJvIzHgXpr5P1hWOLTj-bfO6THNUJkQf7Ki2P9Y=.43680b7c-c3e1-41f8-b065-7955e6237613@github.com>
 <Bf57ojt82TeuzzFicVTBNKMHxM9y76FBh8IfTKLziGU=.125bacfb-17ae-4fa4-bc3a-c6c5a3493761@github.com>
Message-ID: <2OsgJsQtfArLRfrVbwvYJKpx3ljhT2fU3UUdWJsUiCY=.91914663-2fef-4696-b1d8-4f7b0c951205@github.com>

On Tue, 28 May 2024 21:17:07 GMT, Scott Gibbons <sgibbons at openjdk.org> wrote:

>> src/hotspot/cpu/x86/c2_stubGenerator_x86_64_string.cpp line 488:
>> 
>>> 486:   __ cmpq(r11, nMinusK);
>>> 487:   __ ja_b(L_return);
>>> 488:   __ movq(rax, r11);
>> 
>> At places where we know that return value in r11 is correct, we dont need to checkRange so this could have its own label.
>
> Disabling causes the test to succeed, so we're not finding matches beyond the end of the string, correct?  Are we confident that this test passing can warrant removing the range check? @sviswa7 ?

Removed.

>> src/hotspot/cpu/x86/c2_stubGenerator_x86_64_string.cpp line 621:
>> 
>>> 619:     __ addq(hsPtrRet, index);
>>> 620:     __ movq(r11, hsPtrRet);
>>> 621:     __ jmp(L_checkRangeAndReturn);
>> 
>> Why do we have to checkRange here, would it not be always correct? It so we could return r11 directly (by moving into rax).
>
> There are cases where r11 could have a value that, when added to (k - 1) would go past the end of the haystack.  I did all in my power to ensure that it doesn't but there's no test I know of to ensure that condition.  I would recommend leaving this in for now.

Removed checkRangeAndReturn

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1617956870
PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1617956635

From sgibbons at openjdk.org  Tue May 28 22:33:19 2024
From: sgibbons at openjdk.org (Scott Gibbons)
Date: Tue, 28 May 2024 22:33:19 GMT
Subject: RFR: 8320448: Accelerate IndexOf using AVX2 [v19]
In-Reply-To: <qqhUK6_L8rqutc-MtL_BzjZbBy88a-TDws9NuLIWC9g=.d97368e7-4b28-439d-959e-fee2ec13d2c9@github.com>
References: <uWi4QxH31hL93771gkl_GgvP0m84IRSoR_1Yi8hD17E=.bc6ed458-7081-4c3f-9348-f59358fa05a4@github.com>
 <eQ4OBFrF8JlDJ1h9awTDOc0kfCc37IlL5vdqtuaqls0=.8f00616d-08e1-4f28-a7a5-5095116d2595@github.com>
 <8Y-nIHc8vfB1X_hp3tpqqqgpCzu6dAt6BBIP_zc4Q70=.c9a48c68-8c14-4af9-8357-ab50e62a5fd3@github.com>
 <qqhUK6_L8rqutc-MtL_BzjZbBy88a-TDws9NuLIWC9g=.d97368e7-4b28-439d-959e-fee2ec13d2c9@github.com>
Message-ID: <Q_3NlJoiuxNmHPHXXYJlhuATcmeAaFW8HcTGeCexw0M=.f6c9e44a-4b2e-4579-9f6f-d77f06bc5271@github.com>

On Thu, 16 May 2024 18:09:04 GMT, Scott Gibbons <sgibbons at openjdk.org> wrote:

>> src/hotspot/cpu/x86/stubGenerator_x86_64_string.cpp line 418:
>> 
>>> 416:       __ cmpq(haystack_len, 0x10);
>>> 417:       __ ja_b(L_moreThan16);
>>> 418: 
>> 
>> An assert here to check for header size >= 16 would be good. 
>> Also a comment here would he good, something like: 
>> // Copy 16 or 32 bytes prior to haystack end onto stack 
>> // This will possibly including some object header bytes when haystack length is less than 16 or 32 bytes // Set the new haystack address to beginning of copied haystack on stack adjusting for extra bytes copied
>
> I don't know how to assert header size >= 16 bytes, so I'll add a comment stating such.  If you can tell me how to assert, I'll add that code in place of the comment.

Fixed in library_call.cpp

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1617955173

From sgibbons at openjdk.org  Tue May 28 22:47:42 2024
From: sgibbons at openjdk.org (Scott Gibbons)
Date: Tue, 28 May 2024 22:47:42 GMT
Subject: RFR: 8320448: Accelerate IndexOf using AVX2 [v46]
In-Reply-To: <uWi4QxH31hL93771gkl_GgvP0m84IRSoR_1Yi8hD17E=.bc6ed458-7081-4c3f-9348-f59358fa05a4@github.com>
References: <uWi4QxH31hL93771gkl_GgvP0m84IRSoR_1Yi8hD17E=.bc6ed458-7081-4c3f-9348-f59358fa05a4@github.com>
Message-ID: <xEagMDcwaOEHKKalRQxzaZyDg8K2bcPP528hUzYk1Go=.d741f089-e58e-4dd6-9115-67e7eb33cf18@github.com>

> Re-write the IndexOf code without the use of the pcmpestri instruction, only using AVX2 instructions.  This change accelerates String.IndexOf on average 1.3x for AVX2.  The benchmark numbers:
> 
> 
> Benchmark	                                               Score		Latest		
> StringIndexOf.advancedWithMediumSub   343.573		317.934		0.925375393x
> StringIndexOf.advancedWithShortSub1	  1039.081		1053.96		1.014319384x
> StringIndexOf.advancedWithShortSub2	      55.828		110.541		1.980027943x
> StringIndexOf.constantPattern	                9.361		11.906		1.271872663x
> StringIndexOf.searchCharLongSuccess	        4.216		4.218		1.000474383x
> StringIndexOf.searchCharMediumSuccess	3.133		3.216		1.02649218x
> StringIndexOf.searchCharShortSuccess	3.76		        3.761		1.000265957x
> StringIndexOf.success	                                9.186		9.713		1.057369911x
> StringIndexOf.successBig	                      14.341		46.343		3.231504079x
> StringIndexOfChar.latin1_AVX2_String	  6220.918		12154.52		1.953814533x
> StringIndexOfChar.latin1_AVX2_char	  5503.556		5540.044		1.006629895x
> StringIndexOfChar.latin1_SSE4_String	  6978.854		6818.689		0.977049957x
> StringIndexOfChar.latin1_SSE4_char	  5657.499		5474.624		0.967675646x
> StringIndexOfChar.latin1_Short_String	  7132.541		6863.359		0.962260014x
> StringIndexOfChar.latin1_Short_char	16013.389	      16162.437		1.009307711x
> StringIndexOfChar.latin1_mixed_String	  7386.123	      14771.622		1.999915517x
> StringIndexOfChar.latin1_mixed_char	  9901.671		9782.245		0.987938803

Scott Gibbons has updated the pull request incrementally with one additional commit since the last revision:

  Final review comments

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/16753/files
  - new: https://git.openjdk.org/jdk/pull/16753/files/751aace8..355325d0

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16753&range=45
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16753&range=44-45

  Stats: 95 lines in 3 files changed: 23 ins; 51 del; 21 mod
  Patch: https://git.openjdk.org/jdk/pull/16753.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16753/head:pull/16753

PR: https://git.openjdk.org/jdk/pull/16753

From sgibbons at openjdk.org  Tue May 28 23:52:27 2024
From: sgibbons at openjdk.org (Scott Gibbons)
Date: Tue, 28 May 2024 23:52:27 GMT
Subject: RFR: 8320448: Accelerate IndexOf using AVX2 [v47]
In-Reply-To: <uWi4QxH31hL93771gkl_GgvP0m84IRSoR_1Yi8hD17E=.bc6ed458-7081-4c3f-9348-f59358fa05a4@github.com>
References: <uWi4QxH31hL93771gkl_GgvP0m84IRSoR_1Yi8hD17E=.bc6ed458-7081-4c3f-9348-f59358fa05a4@github.com>
Message-ID: <hfkXncWufSFi3ulNYKQzo3hUs4wfxPOX-GLAT9VF6n8=.1a2b0ca7-92e0-4ea8-a92b-6ee7e82fdd14@github.com>

> Re-write the IndexOf code without the use of the pcmpestri instruction, only using AVX2 instructions.  This change accelerates String.IndexOf on average 1.3x for AVX2.  The benchmark numbers:
> 
> 
> Benchmark	                                               Score		Latest		
> StringIndexOf.advancedWithMediumSub   343.573		317.934		0.925375393x
> StringIndexOf.advancedWithShortSub1	  1039.081		1053.96		1.014319384x
> StringIndexOf.advancedWithShortSub2	      55.828		110.541		1.980027943x
> StringIndexOf.constantPattern	                9.361		11.906		1.271872663x
> StringIndexOf.searchCharLongSuccess	        4.216		4.218		1.000474383x
> StringIndexOf.searchCharMediumSuccess	3.133		3.216		1.02649218x
> StringIndexOf.searchCharShortSuccess	3.76		        3.761		1.000265957x
> StringIndexOf.success	                                9.186		9.713		1.057369911x
> StringIndexOf.successBig	                      14.341		46.343		3.231504079x
> StringIndexOfChar.latin1_AVX2_String	  6220.918		12154.52		1.953814533x
> StringIndexOfChar.latin1_AVX2_char	  5503.556		5540.044		1.006629895x
> StringIndexOfChar.latin1_SSE4_String	  6978.854		6818.689		0.977049957x
> StringIndexOfChar.latin1_SSE4_char	  5657.499		5474.624		0.967675646x
> StringIndexOfChar.latin1_Short_String	  7132.541		6863.359		0.962260014x
> StringIndexOfChar.latin1_Short_char	16013.389	      16162.437		1.009307711x
> StringIndexOfChar.latin1_mixed_String	  7386.123	      14771.622		1.999915517x
> StringIndexOfChar.latin1_mixed_char	  9901.671		9782.245		0.987938803

Scott Gibbons has updated the pull request incrementally with one additional commit since the last revision:

  Move assert to where it's actually important.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/16753/files
  - new: https://git.openjdk.org/jdk/pull/16753/files/355325d0..db0ab75a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16753&range=46
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16753&range=45-46

  Stats: 2 lines in 1 file changed: 1 ins; 1 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/16753.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16753/head:pull/16753

PR: https://git.openjdk.org/jdk/pull/16753

From darcy at openjdk.org  Wed May 29 01:11:02 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 29 May 2024 01:11:02 GMT
Subject: RFR: 8331879: Clean up non-standard use of /// comments in
 `java.base` [v2]
In-Reply-To: <EoZMoTpe6E1I3xu0czS9FUj3brOEmagEXyCijfBemhA=.b2884274-448b-41c8-8da4-91c9cce24e46@github.com>
References: <BiSTG8MtjyRt2txRK2DIxsmbPPq6Pvp7QQzOnHXbH6w=.b01b4872-dc8b-4e4f-bae6-bdc501da33a6@github.com>
 <SJEc7F5iCUK5ej9Tq6De8W--UT7MqbyP62IcVNPArRY=.3a3feed7-b8e1-4a14-8a01-fe9b2b7e5bd2@github.com>
 <f9vxrbiyG8nALy7dkCpZ1eqUgQCyg0Strdn_zc5qeFk=.ff6ef4b9-f39d-4900-a76e-61c7d0f1402c@github.com>
 <EoZMoTpe6E1I3xu0czS9FUj3brOEmagEXyCijfBemhA=.b2884274-448b-41c8-8da4-91c9cce24e46@github.com>
Message-ID: <q0nCyqJQP0O_Qf7Zl8vOT8qYminwdMrCP9bvQpNO4bI=.28d742ab-4d9a-419d-b8ab-2f86cbdaa75e@github.com>

On Tue, 28 May 2024 20:26:40 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> As a non-standard comment, it will trigger a warning (and hence an error), since the prevailing standard for `java.base` is to compile with all warnings enabled (`-Xlint`) and no warnings found (verified by `-Werror`)
>> 
>> The alternative would be to use `@SuppressWarnings` for the `dangling-doc-comment` warning, but that too would be a code change to these imported files.
>
> OK, we will need to live with it.

Yes, while there is a strong preference to leave upstream sources unedited in the JDK, to my mind being able to compile the java.base module with all warnings enabled should take precedence.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19130#discussion_r1618046467

From sviswanathan at openjdk.org  Wed May 29 03:05:18 2024
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Wed, 29 May 2024 03:05:18 GMT
Subject: RFR: 8320448: Accelerate IndexOf using AVX2 [v47]
In-Reply-To: <hfkXncWufSFi3ulNYKQzo3hUs4wfxPOX-GLAT9VF6n8=.1a2b0ca7-92e0-4ea8-a92b-6ee7e82fdd14@github.com>
References: <uWi4QxH31hL93771gkl_GgvP0m84IRSoR_1Yi8hD17E=.bc6ed458-7081-4c3f-9348-f59358fa05a4@github.com>
 <hfkXncWufSFi3ulNYKQzo3hUs4wfxPOX-GLAT9VF6n8=.1a2b0ca7-92e0-4ea8-a92b-6ee7e82fdd14@github.com>
Message-ID: <xTMRg4L9qLapK07KqyN6f3yt3qzMW9uRxQIEV0ISlCI=.394ea9e6-3fc9-4f0c-a61c-2c28eb9b2ec2@github.com>

On Tue, 28 May 2024 23:52:27 GMT, Scott Gibbons <sgibbons at openjdk.org> wrote:

>> Re-write the IndexOf code without the use of the pcmpestri instruction, only using AVX2 instructions.  This change accelerates String.IndexOf on average 1.3x for AVX2.  The benchmark numbers:
>> 
>> 
>> Benchmark	                                               Score		Latest		
>> StringIndexOf.advancedWithMediumSub   343.573		317.934		0.925375393x
>> StringIndexOf.advancedWithShortSub1	  1039.081		1053.96		1.014319384x
>> StringIndexOf.advancedWithShortSub2	      55.828		110.541		1.980027943x
>> StringIndexOf.constantPattern	                9.361		11.906		1.271872663x
>> StringIndexOf.searchCharLongSuccess	        4.216		4.218		1.000474383x
>> StringIndexOf.searchCharMediumSuccess	3.133		3.216		1.02649218x
>> StringIndexOf.searchCharShortSuccess	3.76		        3.761		1.000265957x
>> StringIndexOf.success	                                9.186		9.713		1.057369911x
>> StringIndexOf.successBig	                      14.341		46.343		3.231504079x
>> StringIndexOfChar.latin1_AVX2_String	  6220.918		12154.52		1.953814533x
>> StringIndexOfChar.latin1_AVX2_char	  5503.556		5540.044		1.006629895x
>> StringIndexOfChar.latin1_SSE4_String	  6978.854		6818.689		0.977049957x
>> StringIndexOfChar.latin1_SSE4_char	  5657.499		5474.624		0.967675646x
>> StringIndexOfChar.latin1_Short_String	  7132.541		6863.359		0.962260014x
>> StringIndexOfChar.latin1_Short_char	16013.389	      16162.437		1.009307711x
>> StringIndexOfChar.latin1_mixed_String	  7386.123	      14771.622		1.999915517x
>> StringIndexOfChar.latin1_mixed_char	  9901.671		9782.245		0.987938803
>
> Scott Gibbons has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Move assert to where it's actually important.

Looks good to me.

-------------

Marked as reviewed by sviswanathan (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/16753#pullrequestreview-2084177134

From liach at openjdk.org  Wed May 29 03:24:01 2024
From: liach at openjdk.org (Chen Liang)
Date: Wed, 29 May 2024 03:24:01 GMT
Subject: RFR: 8332826: Make hashCode methods in ArraysSupport friendlier
 [v2]
In-Reply-To: <m6okZxhUfvRDlSMs4lwSIsOScyEuDsQqYUJ_AXTFJx0=.7f0a9af8-b55f-4491-8c36-1975c4271a17@github.com>
References: <ujd2AT3eYXrHPcSG0vMDe2WOx3INNPU1n0t8haKH0_M=.b1a168d7-ab4c-4920-92ef-1c72e5ffc0cf@github.com>
 <1tx_tl3PV2W5NCEXXawQY5V2ndnSOHPfjisypuhKdhA=.79840096-bac0-4da4-8102-c7ecea7cb5f0@github.com>
 <FBIH-xc1qN8grLt03to-5lUHj-jOEzsSk1HPMKZLmSU=.637e8eb0-b2eb-4a0d-a84e-610a142fa5a3@github.com>
 <Tp-e5hM6KkSCm7JvRiMLRKL4nuB_HSb_UUrV4Xk3DOk=.72009f0d-35fb-4d95-8af8-05ad7410e41d@github.com>
 <qlBhTcZ9jGgKULL58_D41n40d0vcuDybgl84tS1dghU=.b3ffa540-2ad0-44c4-8ade-17d690122778@github.com>
 <m6okZxhUfvRDlSMs4lwSIsOScyEuDsQqYUJ_AXTFJx0=.7f0a9af8-b55f-4491-8c36-1975c4271a17@github.com>
Message-ID: <vAHQ4n1kzZg54jkguIQWkc6GBtc4bjQ08ltLhsQxZJU=.932e0a99-321f-407e-887c-b82144ca2879@github.com>

On Tue, 28 May 2024 22:20:39 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> I believe, it should be `1`. Hear me out. In this method, the `length` is scaled down, whereas in `StringUTF16` it is not. In this method, it's `length`, in `StringUTF16` it's `((byte[]) value).length`.
>
> In fact, if I change it to `2`, the following tests will fail:
> 
>   - `jdk/jdk/classfile/Utf8EntryTest.java`
>   - `jdk/java/util/zip/ZipCoding.java`
>   - `jdk/java/text/Format/MessageFormat/MessageRegression.java`

Indeed, the actual length passed at call site is `value.length >> 1` instead of `value.length`; this adjusted char-length carries on to `vectorizedHashCode` call.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19414#discussion_r1618126401

From liach at openjdk.org  Wed May 29 03:24:02 2024
From: liach at openjdk.org (Chen Liang)
Date: Wed, 29 May 2024 03:24:02 GMT
Subject: RFR: 8332826: Make hashCode methods in ArraysSupport friendlier
 [v2]
In-Reply-To: <1tx_tl3PV2W5NCEXXawQY5V2ndnSOHPfjisypuhKdhA=.79840096-bac0-4da4-8102-c7ecea7cb5f0@github.com>
References: <ujd2AT3eYXrHPcSG0vMDe2WOx3INNPU1n0t8haKH0_M=.b1a168d7-ab4c-4920-92ef-1c72e5ffc0cf@github.com>
 <1tx_tl3PV2W5NCEXXawQY5V2ndnSOHPfjisypuhKdhA=.79840096-bac0-4da4-8102-c7ecea7cb5f0@github.com>
Message-ID: <mu6JpXJGF6upNeEPyxGM84H6ZZrAY8hAsgRKTllFmvs=.de8d1782-1ede-40ce-be1b-73734b08773e@github.com>

On Mon, 27 May 2024 20:55:29 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Please review this PR, which supersedes a now withdrawn https://github.com/openjdk/jdk/pull/14831.
>> 
>> This PR replaces `ArraysSupport.vectorizedHashCode` with a set of more user-friendly methods. Here's a summary:
>> 
>> - Made the operand constants (i.e. `T_BOOLEAN` and friends) and the `vectorizedHashCode` method private
>> 
>> - Made the `vectorizedHashCode` method private, but didn't rename it. Renaming would dramatically increase this PR review cost, because that method's name is used by a lot of VM code. On a bright side, since the method is now private, it's no longer callable by clients of `ArraysSupport`, thus a problem of an inaccurate name is less severe.
>> 
>> - Made the `ArraysSupport.utf16HashCode` method private
>> 
>> - Moved tiny cases (i.e. 0, 1, 2) to `ArraysSupport`
>
> Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix incorrect utf16 hashCode adaptation

src/java.base/share/classes/jdk/internal/util/ArraysSupport.java line 320:

> 318:      * @return the calculated hash value
> 319:      */
> 320:     public static int hashCode(Object[] a, int fromIndex, int length, int initialValue) {

Is the object variant necessary here? The object version is hard for JIT to profile as it's quite polymorphic compared to other arrays, and the initial value is always 1.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19414#discussion_r1618129002

From liach at openjdk.org  Wed May 29 04:04:07 2024
From: liach at openjdk.org (Chen Liang)
Date: Wed, 29 May 2024 04:04:07 GMT
Subject: RFR: 8332597: Remove redundant methods from
 j.l.classfile.ClassReader API [v2]
In-Reply-To: <YBwgwtTS-iUIA2rajoQ-wPQagUe1-7kf6yKQs7yVu60=.dafff0b2-8e92-491f-a652-de02c1648c85@github.com>
References: <UWBl0HMJIC4_22TkWuBhE9kd2F_l0eiPmpIx8rexFlU=.4f905822-ed5e-41be-b9d4-601af6a55eed@github.com>
 <YBwgwtTS-iUIA2rajoQ-wPQagUe1-7kf6yKQs7yVu60=.dafff0b2-8e92-491f-a652-de02c1648c85@github.com>
Message-ID: <_xTSd78qL4CSrluyKAHo_DqLxOELh3_m425q2LwfjVc=.7aa8cf97-aa55-4956-9749-8f55f3c36175@github.com>

On Fri, 24 May 2024 16:41:33 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> j.l.classfile.ClassReader instance is exposed in the Class-File API through j.l.classfile.AttributeMapper::readAttribute method only.
>> ClassReader only purpose is to serve as a tool for reading content of a custom attribute in a user-provided AttribtueMapper.
>> It contains useful set of low-level class reading methods for user to implement a custom attribute content parser.
>> 
>> However methods ClassReader::thisClassPos and ClassReader::skipAttributeHolder are not necessary for a custom attribute content parsing and so redundant in the API.
>> Class-File API implementation internally use these methods, however they should not be exposed in the API.
>> 
>> This patch removes the methods from the API.
>> 
>> Please review.
>> 
>> Thanks,
>> Adam
>
> Adam Sotona 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 JDK-8332597-classreader-redundancy
>    
>    # Conflicts:
>    #	src/java.base/share/classes/jdk/internal/classfile/impl/ClassImpl.java
>  - 8332597: Remove redundant methods from j.l.classfile.ClassReader API

@asotona Can you transition the CSR to proposed again for reviewing?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19323#issuecomment-2136470497

From darcy at openjdk.org  Wed May 29 04:52:33 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 29 May 2024 04:52:33 GMT
Subject: RFR: 8330182: Start of release updates for JDK 24 [v8]
In-Reply-To: <YKsEQWuI-vNTEDjOBInuEjf8AEcTL4QZ_F4JYUqoxwk=.5ed43782-6dec-4383-948d-d9966a85b3bf@github.com>
References: <YKsEQWuI-vNTEDjOBInuEjf8AEcTL4QZ_F4JYUqoxwk=.5ed43782-6dec-4383-948d-d9966a85b3bf@github.com>
Message-ID: <oIKCw4XMypDWvC3wJbfsg0oub4MTnkDQEOW7fCsIY9g=.1e43397f-121a-40ea-bd0e-b07114f8f95c@github.com>

> Get JDK 24 underway.

Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 16 commits:

 - Correct release year.
 - Merge branch 'master' into JDK-8330188
 - Add symbol files current with JDK 23 build 24.
 - Merge branch 'master' into JDK-8330188
 - Merge branch 'master' into JDK-8330188
 - Fix-up test.
 - Merge branch 'master' into JDK-8330188
 - Adjust test for deprecated options.
 - Merge branch 'master' into JDK-8330188
 - Update deprecated options test.
 - ... and 6 more: https://git.openjdk.org/jdk/compare/0f3e2cc3...45e1c040

-------------

Changes: https://git.openjdk.org/jdk/pull/18787/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18787&range=07
  Stats: 1742 lines in 49 files changed: 1679 ins; 7 del; 56 mod
  Patch: https://git.openjdk.org/jdk/pull/18787.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18787/head:pull/18787

PR: https://git.openjdk.org/jdk/pull/18787

From joehw at openjdk.org  Wed May 29 05:13:02 2024
From: joehw at openjdk.org (Joe Wang)
Date: Wed, 29 May 2024 05:13:02 GMT
Subject: RFR: 8332161: Test restoring echo in the Console implementation
 (java.base) [v6]
In-Reply-To: <FkVs4Tu1LpzmoozGa1zmZqqB4KsVsCoRyh7sQ1A7cIc=.f830cded-5ecf-402c-9679-57b6c35bbe63@github.com>
References: <aSxuvnY7ghWwuDuegcWKJKlL_3KUCdIS_jHgTsn43ow=.b4d2e8d9-ffea-4318-9004-27b18298436e@github.com>
 <FkVs4Tu1LpzmoozGa1zmZqqB4KsVsCoRyh7sQ1A7cIc=.f830cded-5ecf-402c-9679-57b6c35bbe63@github.com>
Message-ID: <n5ObYb3IT2X9H5342wqMDXWbJ_cCAZ0XkB7zOO9Iujw=.828c11ca-54f4-4105-bf6c-5a42c3ed1e11@github.com>

On Tue, 28 May 2024 16:56:18 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> This test intends to verify the behavior of JdkConsole for the java.base module, wrt restoring the echo. The test assumes the internal methods that sets/gets the echo status of the platform.
>
> Naoto Sato has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 23 commits:
> 
>  - incorporated the same fix from 8332922
>  - Merge branch 'master' into JDK-8332161-restoreEcho-Test
>  - Merge branch 'master' into JDK-8332161-restoreEcho-Test
>  - Merge branch 'JDK-8332084-restoreEcho-readLock' into JDK-8332161-restoreEcho-Test
>  - Added comment for restoreEchoLock
>  - fixing typo
>  - Merge branch 'JDK-8332084-restoreEcho-readLock' into JDK-8332161-restoreEcho-Test
>  - Merge branch 'master' into JDK-8332084-restoreEcho-readLock
>  - leftover typo
>  - get/setEcho() -> echo()
>  - ... and 13 more: https://git.openjdk.org/jdk/compare/b8f2ec90...2477adf4

Marked as reviewed by joehw (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/19315#pullrequestreview-2084275580

From liach at openjdk.org  Wed May 29 05:19:28 2024
From: liach at openjdk.org (Chen Liang)
Date: Wed, 29 May 2024 05:19:28 GMT
Subject: RFR: 8332614: Type-checked ConstantPool.entryByIndex and
 ClassReader.readEntryOrNull [v4]
In-Reply-To: <UP8XpBov1w74UcUrAkD08x3vQGy_zRQ8NFRXuMU8us4=.3cce8ca0-742b-43f2-a282-894c7f61c969@github.com>
References: <UP8XpBov1w74UcUrAkD08x3vQGy_zRQ8NFRXuMU8us4=.3cce8ca0-742b-43f2-a282-894c7f61c969@github.com>
Message-ID: <kEV9sArwlblRDvwoRCFz_KouXo-IcStCptbT4xtqD9c=.5070af67-f54e-4de0-a3eb-5025d31ee6c5@github.com>

> I propose to add type-checked ConstantPool.entryByIndex and ClassReader.readEntryOrNull taking an extra Class parameter, which throws ConstantPoolException instead of ClassCastException on type mismatch, which can happen to malformed ClassFiles.
> 
> Requesting a review from @asotona. Thanks!
> 
> Proposal on mailing list: https://mail.openjdk.org/pipermail/classfile-api-dev/2024-May/000512.html

Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision:

 - Use switch
 - Merge branch 'master' of https://github.com/openjdk/jdk into feature/entry-by-type
 - Merge branch 'master' of https://github.com/openjdk/jdk into feature/entry-by-type
 - Merge branch 'master' of https://github.com/openjdk/jdk into feature/entry-by-type
 - Use constants, beautify code
 - 8332614: Type-checked ConstantPool.entryByIndex and ClassReader.readEntryOrNull

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19330/files
  - new: https://git.openjdk.org/jdk/pull/19330/files/a68519d3..b3b94639

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19330&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19330&range=02-03

  Stats: 6144 lines in 270 files changed: 3709 ins; 843 del; 1592 mod
  Patch: https://git.openjdk.org/jdk/pull/19330.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19330/head:pull/19330

PR: https://git.openjdk.org/jdk/pull/19330

From asotona at openjdk.org  Wed May 29 06:45:03 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Wed, 29 May 2024 06:45:03 GMT
Subject: RFR: 8332614: Type-checked ConstantPool.entryByIndex and
 ClassReader.readEntryOrNull [v4]
In-Reply-To: <kEV9sArwlblRDvwoRCFz_KouXo-IcStCptbT4xtqD9c=.5070af67-f54e-4de0-a3eb-5025d31ee6c5@github.com>
References: <UP8XpBov1w74UcUrAkD08x3vQGy_zRQ8NFRXuMU8us4=.3cce8ca0-742b-43f2-a282-894c7f61c969@github.com>
 <kEV9sArwlblRDvwoRCFz_KouXo-IcStCptbT4xtqD9c=.5070af67-f54e-4de0-a3eb-5025d31ee6c5@github.com>
Message-ID: <yV2nk4yssiFncffogiVRRE7i5pNpux3p4L47P4swvkk=.909e62ea-c32b-4cdc-b7c2-4f0066f6b092@github.com>

On Wed, 29 May 2024 05:19:28 GMT, Chen Liang <liach at openjdk.org> wrote:

>> I propose to add type-checked ConstantPool.entryByIndex and ClassReader.readEntryOrNull taking an extra Class parameter, which throws ConstantPoolException instead of ClassCastException on type mismatch, which can happen to malformed ClassFiles.
>> 
>> Requesting a review from @asotona. Thanks!
>> 
>> Proposal on mailing list: https://mail.openjdk.org/pipermail/classfile-api-dev/2024-May/000512.html
>
> Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision:
> 
>  - Use switch
>  - Merge branch 'master' of https://github.com/openjdk/jdk into feature/entry-by-type
>  - Merge branch 'master' of https://github.com/openjdk/jdk into feature/entry-by-type
>  - Merge branch 'master' of https://github.com/openjdk/jdk into feature/entry-by-type
>  - Use constants, beautify code
>  - 8332614: Type-checked ConstantPool.entryByIndex and ClassReader.readEntryOrNull

Looks good to me, thanks!

-------------

Marked as reviewed by asotona (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19330#pullrequestreview-2084437069

From asotona at openjdk.org  Wed May 29 07:17:38 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Wed, 29 May 2024 07:17:38 GMT
Subject: RFR: 8332457: Examine startup overheads from JDK-8294961 [v12]
In-Reply-To: <YdSsOH6RBi4-Xy1ZTpSdTqQprzvhAYIenwxWxvC6GrU=.6961b30c-2d67-49b6-aa3e-b4736be0458b@github.com>
References: <YdSsOH6RBi4-Xy1ZTpSdTqQprzvhAYIenwxWxvC6GrU=.6961b30c-2d67-49b6-aa3e-b4736be0458b@github.com>
Message-ID: <NP-R_t0gqI7icqXoea0pCTTySYMPzl2-j93QtKMpH9A=.3574da5b-67f2-4aa7-ae7d-ac6cd2415713@github.com>

> [JDK-8294961](https://bugs.openjdk.org/browse/JDK-8294961) changed to use classfile API for reflection proxy-generation. Actual implementation of `ProxyGenerator` is focused on performance, however it causes JDK bootstrap regressions. `ProxyGenerator.TEMPLATE` class model is statically created and each proxy class is transformed from the template.
> 
> This patch is intended to examine plain proxy generation impact on performance and JDK bootstrap (vs proxy transformation from template).
> 
> The generated proxy is migrated from static initialization to CONDY bootstrap.
> 
> Please review.
> 
> Thank you,
> Adam

Adam Sotona 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 13 additional commits since the last revision:

 - obsolete import
 - Merge branch 'master' into JDK-8332457-proxy-startup
 - missing bracket
 - Update src/java.base/share/classes/java/lang/reflect/ProxyGenerator.java
   
   Co-authored-by: liach <7806504+liach at users.noreply.github.com>
 - removed obsolete entry
 - MTD_ cleanup
 - fixed javadoc
 - CONDY implementation of ProxyGenerator
 - simplification of the proxy class loading
 - more improvements
 - ... and 3 more: https://git.openjdk.org/jdk/compare/386e173f...942342d5

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19410/files
  - new: https://git.openjdk.org/jdk/pull/19410/files/24b60451..942342d5

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19410&range=11
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19410&range=10-11

  Stats: 4440 lines in 143 files changed: 3169 ins; 738 del; 533 mod
  Patch: https://git.openjdk.org/jdk/pull/19410.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19410/head:pull/19410

PR: https://git.openjdk.org/jdk/pull/19410

From redestad at openjdk.org  Wed May 29 08:39:01 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Wed, 29 May 2024 08:39:01 GMT
Subject: RFR: 8332826: Make hashCode methods in ArraysSupport friendlier
 [v2]
In-Reply-To: <vAHQ4n1kzZg54jkguIQWkc6GBtc4bjQ08ltLhsQxZJU=.932e0a99-321f-407e-887c-b82144ca2879@github.com>
References: <ujd2AT3eYXrHPcSG0vMDe2WOx3INNPU1n0t8haKH0_M=.b1a168d7-ab4c-4920-92ef-1c72e5ffc0cf@github.com>
 <1tx_tl3PV2W5NCEXXawQY5V2ndnSOHPfjisypuhKdhA=.79840096-bac0-4da4-8102-c7ecea7cb5f0@github.com>
 <FBIH-xc1qN8grLt03to-5lUHj-jOEzsSk1HPMKZLmSU=.637e8eb0-b2eb-4a0d-a84e-610a142fa5a3@github.com>
 <Tp-e5hM6KkSCm7JvRiMLRKL4nuB_HSb_UUrV4Xk3DOk=.72009f0d-35fb-4d95-8af8-05ad7410e41d@github.com>
 <qlBhTcZ9jGgKULL58_D41n40d0vcuDybgl84tS1dghU=.b3ffa540-2ad0-44c4-8ade-17d690122778@github.com>
 <m6okZxhUfvRDlSMs4lwSIsOScyEuDsQqYUJ_AXTFJx0=.7f0a9af8-b55f-4491-8c36-1975c4271a17@github.com>
 <vAHQ4n1kzZg54jkguIQWkc6GBtc4bjQ08ltLhsQxZJU=.932e0a99-321f-407e-887c-b82144ca2879@github.com>
Message-ID: <VA4_vXaW-Z7KD3K4kE35sG8X6VgxSt4sIpa2n0E_vWc=.803964ca-fc27-45f3-951d-8dae86e02280@github.com>

On Wed, 29 May 2024 03:16:02 GMT, Chen Liang <liach at openjdk.org> wrote:

>> In fact, if I change it to `2`, the following tests will fail:
>> 
>>   - `jdk/jdk/classfile/Utf8EntryTest.java`
>>   - `jdk/java/util/zip/ZipCoding.java`
>>   - `jdk/java/text/Format/MessageFormat/MessageRegression.java`
>
> Indeed, the actual length passed at call site is `value.length >> 1` instead of `value.length`; this adjusted char-length carries on to `vectorizedHashCode` call.

Ah, sneaky. Might affect scores for the zero and one-char cases since the shift now happens unconditionally, but probably doesn't matter in practice.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19414#discussion_r1618456668

From redestad at openjdk.org  Wed May 29 08:43:01 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Wed, 29 May 2024 08:43:01 GMT
Subject: RFR: 8332826: Make hashCode methods in ArraysSupport friendlier
 [v2]
In-Reply-To: <1tx_tl3PV2W5NCEXXawQY5V2ndnSOHPfjisypuhKdhA=.79840096-bac0-4da4-8102-c7ecea7cb5f0@github.com>
References: <ujd2AT3eYXrHPcSG0vMDe2WOx3INNPU1n0t8haKH0_M=.b1a168d7-ab4c-4920-92ef-1c72e5ffc0cf@github.com>
 <1tx_tl3PV2W5NCEXXawQY5V2ndnSOHPfjisypuhKdhA=.79840096-bac0-4da4-8102-c7ecea7cb5f0@github.com>
Message-ID: <ppdZUmFJI2tDkC8sDMTGBWwTrUtUxO5qgOK9pTE1suE=.e7d5401d-1b0f-43ac-b1c1-69288992f660@github.com>

On Mon, 27 May 2024 20:55:29 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Please review this PR, which supersedes a now withdrawn https://github.com/openjdk/jdk/pull/14831.
>> 
>> This PR replaces `ArraysSupport.vectorizedHashCode` with a set of more user-friendly methods. Here's a summary:
>> 
>> - Made the operand constants (i.e. `T_BOOLEAN` and friends) and the `vectorizedHashCode` method private
>> 
>> - Made the `vectorizedHashCode` method private, but didn't rename it. Renaming would dramatically increase this PR review cost, because that method's name is used by a lot of VM code. On a bright side, since the method is now private, it's no longer callable by clients of `ArraysSupport`, thus a problem of an inaccurate name is less severe.
>> 
>> - Made the `ArraysSupport.utf16HashCode` method private
>> 
>> - Moved tiny cases (i.e. 0, 1, 2) to `ArraysSupport`
>
> Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix incorrect utf16 hashCode adaptation

Marked as reviewed by redestad (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/19414#pullrequestreview-2084714609

From prappo at openjdk.org  Wed May 29 09:21:02 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Wed, 29 May 2024 09:21:02 GMT
Subject: RFR: 8332826: Make hashCode methods in ArraysSupport friendlier
 [v2]
In-Reply-To: <aqEt9hX5CliI-FvDQKlX1NEMw5OvyBrmcq1kP86sucI=.b07e58fb-e6a8-4df0-b21a-3e3ff8b1b36d@github.com>
References: <ujd2AT3eYXrHPcSG0vMDe2WOx3INNPU1n0t8haKH0_M=.b1a168d7-ab4c-4920-92ef-1c72e5ffc0cf@github.com>
 <1tx_tl3PV2W5NCEXXawQY5V2ndnSOHPfjisypuhKdhA=.79840096-bac0-4da4-8102-c7ecea7cb5f0@github.com>
 <FBIH-xc1qN8grLt03to-5lUHj-jOEzsSk1HPMKZLmSU=.637e8eb0-b2eb-4a0d-a84e-610a142fa5a3@github.com>
 <aqEt9hX5CliI-FvDQKlX1NEMw5OvyBrmcq1kP86sucI=.b07e58fb-e6a8-4df0-b21a-3e3ff8b1b36d@github.com>
Message-ID: <ETcMbUPqlSBIdvEDCPnpfUljutq3dO8NgZJ98MxqUQM=.4d2eac7c-bfc3-4ece-81e5-675c3e399e91@github.com>

On Tue, 28 May 2024 20:21:34 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> test/hotspot/jtreg/compiler/intrinsics/TestArraysHashCode.java line 88:
>> 
>>> 86:     private static int testIntrinsic(byte[] bytes, int type)
>>> 87:             throws InvocationTargetException, IllegalAccessException {
>>> 88:         return (int) vectorizedHashCode.invoke(null, bytes, 0, 256, 1, type);
>> 
>> Better to just call `hashCodeOfUnsigned` here I think.
>> 
>> The test for the non-constant type could be dropped. That is no longer a part of the 'API' of `ArraySupport`. It looks like the intrinsic bails out when the basic type is not constant any ways: https://github.com/openjdk/jdk/blob/master/src/hotspot/share/opto/library_call.cpp#L6401-L6404
>
> The non-constant test was added because that very bailout caused a crash. The other test is actually less interesting since it'll likely be covered indirectly by regular use. But as we are hiding these away this gets ever more obscure and perhaps the test could be dropped entirely.

@cl4es, do you want me to delete that test file altogether?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19414#discussion_r1618536122

From prappo at openjdk.org  Wed May 29 10:28:06 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Wed, 29 May 2024 10:28:06 GMT
Subject: RFR: 8332826: Make hashCode methods in ArraysSupport friendlier
 [v2]
In-Reply-To: <mu6JpXJGF6upNeEPyxGM84H6ZZrAY8hAsgRKTllFmvs=.de8d1782-1ede-40ce-be1b-73734b08773e@github.com>
References: <ujd2AT3eYXrHPcSG0vMDe2WOx3INNPU1n0t8haKH0_M=.b1a168d7-ab4c-4920-92ef-1c72e5ffc0cf@github.com>
 <1tx_tl3PV2W5NCEXXawQY5V2ndnSOHPfjisypuhKdhA=.79840096-bac0-4da4-8102-c7ecea7cb5f0@github.com>
 <mu6JpXJGF6upNeEPyxGM84H6ZZrAY8hAsgRKTllFmvs=.de8d1782-1ede-40ce-be1b-73734b08773e@github.com>
Message-ID: <5hNYOD-Vz4Pi9bww3h1BCCvSwHEs_D8LcRqafU8wqtw=.977f0923-b9c9-4490-bf37-fa393225e54e@github.com>

On Wed, 29 May 2024 03:21:27 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix incorrect utf16 hashCode adaptation
>
> src/java.base/share/classes/jdk/internal/util/ArraysSupport.java line 320:
> 
>> 318:      * @return the calculated hash value
>> 319:      */
>> 320:     public static int hashCode(Object[] a, int fromIndex, int length, int initialValue) {
> 
> Is the object variant necessary here? The object version is hard for JIT to profile as it's quite polymorphic compared to other arrays, and the initial value is always 1.

This is a cleanup/refactoring PR, so none of this is necessary. My motivation for the `Object[]` variant was to provide reusable functionality for methods like these:

 - https://github.com/openjdk/jdk/blob/0ef03f122866f010ebf50683097e9b92e41cdaad/src/java.base/share/classes/java/util/concurrent/CopyOnWriteArrayList.java#L1076-L1083
 - https://github.com/openjdk/jdk/blob/0ef03f122866f010ebf50683097e9b92e41cdaad/src/java.base/share/classes/java/util/ArrayList.java#L669-L680

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19414#discussion_r1618644177

From daniel at wwwmaster.at  Wed May 29 11:09:44 2024
From: daniel at wwwmaster.at (Daniel Schmid)
Date: Wed, 29 May 2024 13:09:44 +0200
Subject: Can we improve the charset parameter Javadoc in PrintStream?
Message-ID: <b0868599-6025-487b-9f8f-93ebbec516c6@wwwmaster.at>

Hi,

When viewing the Javadoc of PrintStream, I noticed that the Javadocs of 
the constructors involving charsets seems to be a bit lacking.
In most cases, these just mention something like "a charset" instead of 
saying what it's used for. While the class description specifies that, I 
think it could also be present in the parameter information of the 
constructors since PrintStream is a commonly used class.

- The second parameter of PrintStream(File, String) is named "csn" and 
described as "The name of a supported charset". I suggest naming the 
parameter "encoding" and changing the description to "The name of a 
supported character encoding to be used for be used for converting 
characters to bytes" (with the appropriate link). This would be 
consistent with the PrintStream(OutputStream, boolean, String) constructor.
- The second parameter of PrintStream(File, Charset) is described as "A 
charset". I think this could be changed to "The charset used for 
converting characters to bytes" or similar.
- The third parameter of PrintStream(OutputStream, boolean, String) is 
named "encoding" and described as "The name of a supported character 
encoding". This could be changed to "The name of a supported character 
encoding to be used for be used for converting characters to bytes".
- The third parameter of PrintStream(OutputStream, boolean, Charset) is 
described as "A charset". I suggest changing this to "The charset used 
for converting characters to bytes".

Instead of using "encoding" for the String parameter names, 
"charsetName" would be another option. In this case, I would suggest 
something like "The name of a supported charset to be used for be used 
for converting characters to bytes".

If wanted, I can write a pull request for this but as I don't have JBS 
access, I can't create the issue and CSR by myself.

Yours,
Daniel

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4490 bytes
Desc: S/MIME Cryptographic Signature
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240529/2d207913/smime.p7s>

From mcimadamore at openjdk.org  Wed May 29 11:10:07 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 29 May 2024 11:10:07 GMT
Subject: RFR: 8331865: Consolidate size and alignment checks in LayoutPath
 [v3]
In-Reply-To: <wkYW4EE0CyKepXRtF8hG79D6Oeh7HLQQF83UtgHEmEU=.962392ad-a43a-470b-ac7f-1edb4c21382c@github.com>
References: <CvKkdESp5-uHiuZtQvGortWnzOMV89pfjaCHNBIV4B4=.51ad0f01-2371-48af-b3c6-8a9b80518cdb@github.com>
 <206PC955P0Z45jL6ZYWY-gRNyuyw0t2eeJBBE8-yRsY=.5c98c55d-0192-4d79-ba27-0c1a44e69b89@github.com>
 <wkYW4EE0CyKepXRtF8hG79D6Oeh7HLQQF83UtgHEmEU=.962392ad-a43a-470b-ac7f-1edb4c21382c@github.com>
Message-ID: <nk_0xzXvZ25vtY0qm3ws317kBQA7SSQ2NXXWXuVDoyE=.dbe82a7a-fda6-4bf8-99dc-75354385e605@github.com>

On Wed, 22 May 2024 21:03:57 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix typo in javadoc
>
> src/java.base/share/classes/java/lang/invoke/X-VarHandleSegmentView.java.template line 123:
> 
>> 121:     static $type$ get(VarHandle ob, Object obb, long base) {
>> 122:         VarHandleSegmentViewBase handle = (VarHandleSegmentViewBase)ob;
>> 123:         AbstractMemorySegmentImpl bb = checkReadOnly(obb, true);
> 
> For getter methods, which pass a constant `true` here, `checkReadOnly` essentially just does a null check and cast on the segment. Not sure if it's worth simplifying... (I'm happy if you want to leave it like this as well)

I'll leave it for now. There's always a trade-off with these generated templates...

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19251#discussion_r1618694460

From mcimadamore at openjdk.org  Wed May 29 11:15:10 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 29 May 2024 11:15:10 GMT
Subject: Integrated: 8331865: Consolidate size and alignment checks in
 LayoutPath
In-Reply-To: <CvKkdESp5-uHiuZtQvGortWnzOMV89pfjaCHNBIV4B4=.51ad0f01-2371-48af-b3c6-8a9b80518cdb@github.com>
References: <CvKkdESp5-uHiuZtQvGortWnzOMV89pfjaCHNBIV4B4=.51ad0f01-2371-48af-b3c6-8a9b80518cdb@github.com>
Message-ID: <wysiw3FKvPqThg3piJQYooTcdn07Hc7-X34gdzXVL3U=.191a502c-0f67-47f8-934b-7ed7428e6927@github.com>

On Wed, 15 May 2024 15:43:45 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> When creating a nested memory access var handle, we ensure that the segment is accessed at the correct alignment for the root layout being accessed. But we do not ensure that the segment has at least the size of the accessed root layout. Example:
> 
> 
> MemoryLayout LAYOUT = sequenceLayout(2, structLayout(JAVA_INT.withName("x"), JAVA_INT.withName("y")));
> VarHandle X_HANDLE = LAYOUT.varHandle(PathElement.sequenceElement(), PathElement.groupElement("x"));
> 
> 
> If I have a memory segment whose size is 12, I can successfully call X_HANDLE on it with index 1, like so:
> 
> 
> MemorySegment segment = Arena.ofAuto().allocate(12);
> int x = (int)X_HANDLE.get(segment, 0, 1);
> 
> 
> This seems incorrect: after all, the provided segment doesn't have enough space to fit _two_ elements of the nested structs. 
> 
> This PR adds checks to detect this kind of scenario earlier, thus improving usability. To achieve this we could, in principle, just tweak `LayoutPath::checkEnclosingLayout` and add the required size check.
> 
> But doing so will add yet another redundant check on top of the other already added by [pull/19124](https://git.openjdk.org/jdk/pull/19124). Instead, this PR rethinks how memory segment var handles are created, in order to eliminate redundant checks.
> 
> The main observation is that size and alignment checks depend on an _enclosing_ layout. This layout *might* be the very same value layout being accessed (this is the case when e.g. using `JAVA_INT.varHandle()`). But, in the general case, the accessed value layout and the enclosing layout might differ (e.g. think about accessing a struct field).
> 
> Furthermore, the enclosing layout check depends on the _base_ offset at which the segment is accessed, _prior_ to any index computation that occurs if the accessed layout path has any open elements. It is important to notice that this base offset is only available when looking at the var handle that is returned to the user. For instance, an indexed var handle with coordinates:
> 
> 
> (MemorySegment, long /* base */, long /* index 1 */, long /* index 2 */, long /* index 3 */)
> 
> 
> Is obtained through adaptation, by taking a more basic var handle of the form:
> 
> 
> (MemorySegment, long /* offset */)
> 
> 
> And then injecting the result of the index multiplication into `offset`. As such, we can't add an enclosing layout check inside the var handle returned by `VarHandles::memorySegmentViewHandle`, as doing so will end up seeing the *wrong* offset (e.g. an offset in which the index part has already been mixed in)...

This pull request has now been integrated.

Changeset: c003c120
Author:    Maurizio Cimadamore <mcimadamore at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/c003c1207fae07bcfe5a6f642a9c05e6c591e7a6
Stats:     205 lines in 12 files changed: 72 ins; 39 del; 94 mod

8331865: Consolidate size and alignment checks in LayoutPath

Reviewed-by: psandoz, jvernee

-------------

PR: https://git.openjdk.org/jdk/pull/19251

From dl at openjdk.org  Wed May 29 11:22:41 2024
From: dl at openjdk.org (Doug Lea)
Date: Wed, 29 May 2024 11:22:41 GMT
Subject: RFR: 8322732: ForkJoinPool may underutilize cores in async mode
 [v6]
In-Reply-To: <xRyDMAsSZ7obqpr3Aoc5qrHqILeJMxFVCeiRdctMI3U=.d5d3cd56-32eb-4431-ac01-081822fc86c6@github.com>
References: <xRyDMAsSZ7obqpr3Aoc5qrHqILeJMxFVCeiRdctMI3U=.d5d3cd56-32eb-4431-ac01-081822fc86c6@github.com>
Message-ID: <hWTR-P83oD54BdAb28CN3LnckQk9CTSBNBH51nsa7DU=.32eb28e0-2bde-4317-bc2c-d8e207c06331@github.com>

> This set of changes address causes of poor utilization with small numbers of cores due to overly aggressive contention avoidance. A number of further adjustments were needed to still avoid most contention effects in deployments with large numbers of cores

Doug Lea has updated the pull request incrementally with two additional commits since the last revision:

 - Add test for utilization with interdependent tasks
 - Un-misplace onSpinWait call

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19131/files
  - new: https://git.openjdk.org/jdk/pull/19131/files/72224779..a262f6c6

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19131&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19131&range=04-05

  Stats: 52 lines in 2 files changed: 51 ins; 1 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/19131.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19131/head:pull/19131

PR: https://git.openjdk.org/jdk/pull/19131

From dl at openjdk.org  Wed May 29 11:33:40 2024
From: dl at openjdk.org (Doug Lea)
Date: Wed, 29 May 2024 11:33:40 GMT
Subject: RFR: 8322732: ForkJoinPool may underutilize cores in async mode
 [v7]
In-Reply-To: <xRyDMAsSZ7obqpr3Aoc5qrHqILeJMxFVCeiRdctMI3U=.d5d3cd56-32eb-4431-ac01-081822fc86c6@github.com>
References: <xRyDMAsSZ7obqpr3Aoc5qrHqILeJMxFVCeiRdctMI3U=.d5d3cd56-32eb-4431-ac01-081822fc86c6@github.com>
Message-ID: <HDSzlGiKtB10QAHsZiC06nJ79ofx26RbzSROrLuBepg=.29855e54-4d7e-4d9f-97b6-e1cffb117690@github.com>

> This set of changes address causes of poor utilization with small numbers of cores due to overly aggressive contention avoidance. A number of further adjustments were needed to still avoid most contention effects in deployments with large numbers of cores

Doug Lea 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 41 additional commits since the last revision:

 - Merge branch 'openjdk:master' into JDK-8322732
 - Add test for utilization with interdependent tasks
 - Un-misplace onSpinWait call
 - Adjust control flow
 - Reduce memory stalls
 - Merge branch 'openjdk:master' into JDK-8322732
 - More performance tradoffs
 - Address review comments
 - Merge branch 'openjdk:master' into JDK-8322732
 - Repack some fields; adjust control flow
 - ... and 31 more: https://git.openjdk.org/jdk/compare/cc3280e5...cf5fe55c

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19131/files
  - new: https://git.openjdk.org/jdk/pull/19131/files/a262f6c6..cf5fe55c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19131&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19131&range=05-06

  Stats: 23145 lines in 634 files changed: 14865 ins; 4679 del; 3601 mod
  Patch: https://git.openjdk.org/jdk/pull/19131.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19131/head:pull/19131

PR: https://git.openjdk.org/jdk/pull/19131

From liach at openjdk.org  Wed May 29 11:42:05 2024
From: liach at openjdk.org (Chen Liang)
Date: Wed, 29 May 2024 11:42:05 GMT
Subject: RFR: 8332457: Examine startup overheads from JDK-8294961 [v12]
In-Reply-To: <NP-R_t0gqI7icqXoea0pCTTySYMPzl2-j93QtKMpH9A=.3574da5b-67f2-4aa7-ae7d-ac6cd2415713@github.com>
References: <YdSsOH6RBi4-Xy1ZTpSdTqQprzvhAYIenwxWxvC6GrU=.6961b30c-2d67-49b6-aa3e-b4736be0458b@github.com>
 <NP-R_t0gqI7icqXoea0pCTTySYMPzl2-j93QtKMpH9A=.3574da5b-67f2-4aa7-ae7d-ac6cd2415713@github.com>
Message-ID: <9Whgc6v-y458Oap6hGQY4a9BJhKz2Hbm86gT45t5iNY=.4d7510b0-8f24-4384-b856-708828467ef2@github.com>

On Wed, 29 May 2024 07:17:38 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> [JDK-8294961](https://bugs.openjdk.org/browse/JDK-8294961) changed to use classfile API for reflection proxy-generation. Actual implementation of `ProxyGenerator` is focused on performance, however it causes JDK bootstrap regressions. `ProxyGenerator.TEMPLATE` class model is statically created and each proxy class is transformed from the template.
>> 
>> This patch is intended to examine plain proxy generation impact on performance and JDK bootstrap (vs proxy transformation from template).
>> 
>> The generated proxy is migrated from static initialization to CONDY bootstrap.
>> 
>> Please review.
>> 
>> Thank you,
>> Adam
>
> Adam Sotona 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 13 additional commits since the last revision:
> 
>  - obsolete import
>  - Merge branch 'master' into JDK-8332457-proxy-startup
>  - missing bracket
>  - Update src/java.base/share/classes/java/lang/reflect/ProxyGenerator.java
>    
>    Co-authored-by: liach <7806504+liach at users.noreply.github.com>
>  - removed obsolete entry
>  - MTD_ cleanup
>  - fixed javadoc
>  - CONDY implementation of ProxyGenerator
>  - simplification of the proxy class loading
>  - more improvements
>  - ... and 3 more: https://git.openjdk.org/jdk/compare/19d52556...942342d5

Marked as reviewed by liach (Author).

-------------

PR Review: https://git.openjdk.org/jdk/pull/19410#pullrequestreview-2085154590

From liach at openjdk.org  Wed May 29 11:45:07 2024
From: liach at openjdk.org (Chen Liang)
Date: Wed, 29 May 2024 11:45:07 GMT
Subject: RFR: 8332826: Make hashCode methods in ArraysSupport friendlier
 [v2]
In-Reply-To: <1tx_tl3PV2W5NCEXXawQY5V2ndnSOHPfjisypuhKdhA=.79840096-bac0-4da4-8102-c7ecea7cb5f0@github.com>
References: <ujd2AT3eYXrHPcSG0vMDe2WOx3INNPU1n0t8haKH0_M=.b1a168d7-ab4c-4920-92ef-1c72e5ffc0cf@github.com>
 <1tx_tl3PV2W5NCEXXawQY5V2ndnSOHPfjisypuhKdhA=.79840096-bac0-4da4-8102-c7ecea7cb5f0@github.com>
Message-ID: <opOZcFz-xbd5RsZ69zuZroNjvi_hxLDdZxqxqVw9l9A=.df322102-4350-4c98-85ec-84c10b9b975c@github.com>

On Mon, 27 May 2024 20:55:29 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Please review this PR, which supersedes a now withdrawn https://github.com/openjdk/jdk/pull/14831.
>> 
>> This PR replaces `ArraysSupport.vectorizedHashCode` with a set of more user-friendly methods. Here's a summary:
>> 
>> - Made the operand constants (i.e. `T_BOOLEAN` and friends) and the `vectorizedHashCode` method private
>> 
>> - Made the `vectorizedHashCode` method private, but didn't rename it. Renaming would dramatically increase this PR review cost, because that method's name is used by a lot of VM code. On a bright side, since the method is now private, it's no longer callable by clients of `ArraysSupport`, thus a problem of an inaccurate name is less severe.
>> 
>> - Made the `ArraysSupport.utf16HashCode` method private
>> 
>> - Moved tiny cases (i.e. 0, 1, 2) to `ArraysSupport`
>
> Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix incorrect utf16 hashCode adaptation

Marked as reviewed by liach (Author).

-------------

PR Review: https://git.openjdk.org/jdk/pull/19414#pullrequestreview-2085162416

From liach at openjdk.org  Wed May 29 12:08:28 2024
From: liach at openjdk.org (Chen Liang)
Date: Wed, 29 May 2024 12:08:28 GMT
Subject: RFR: 8332614: Type-checked ConstantPool.entryByIndex and
 ClassReader.readEntryOrNull [v5]
In-Reply-To: <UP8XpBov1w74UcUrAkD08x3vQGy_zRQ8NFRXuMU8us4=.3cce8ca0-742b-43f2-a282-894c7f61c969@github.com>
References: <UP8XpBov1w74UcUrAkD08x3vQGy_zRQ8NFRXuMU8us4=.3cce8ca0-742b-43f2-a282-894c7f61c969@github.com>
Message-ID: <SWME8ZGmO26txeAZI4EDq8wNEAuf-6jCCUd5CKXpS0s=.91807c5a-564e-4ffa-be8a-261941c337ec@github.com>

> I propose to add type-checked ConstantPool.entryByIndex and ClassReader.readEntryOrNull taking an extra Class parameter, which throws ConstantPoolException instead of ClassCastException on type mismatch, which can happen to malformed ClassFiles.
> 
> Requesting a review from @asotona. Thanks!
> 
> Proposal on mailing list: https://mail.openjdk.org/pipermail/classfile-api-dev/2024-May/000512.html

Chen Liang has updated the pull request incrementally with one additional commit since the last revision:

  Remove redundant import

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19330/files
  - new: https://git.openjdk.org/jdk/pull/19330/files/b3b94639..ec56ce98

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19330&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19330&range=03-04

  Stats: 2 lines in 1 file changed: 0 ins; 2 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/19330.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19330/head:pull/19330

PR: https://git.openjdk.org/jdk/pull/19330

From redestad at openjdk.org  Wed May 29 12:39:05 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Wed, 29 May 2024 12:39:05 GMT
Subject: RFR: 8332457: Examine startup overheads from JDK-8294961 [v12]
In-Reply-To: <NP-R_t0gqI7icqXoea0pCTTySYMPzl2-j93QtKMpH9A=.3574da5b-67f2-4aa7-ae7d-ac6cd2415713@github.com>
References: <YdSsOH6RBi4-Xy1ZTpSdTqQprzvhAYIenwxWxvC6GrU=.6961b30c-2d67-49b6-aa3e-b4736be0458b@github.com>
 <NP-R_t0gqI7icqXoea0pCTTySYMPzl2-j93QtKMpH9A=.3574da5b-67f2-4aa7-ae7d-ac6cd2415713@github.com>
Message-ID: <sEuvvWzjGb8TH8uY67_Mzq_e_qpdUlq5ZJYDIZTjQE4=.785daba0-9fc0-4a23-84ff-54023a69dd0f@github.com>

On Wed, 29 May 2024 07:17:38 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> [JDK-8294961](https://bugs.openjdk.org/browse/JDK-8294961) changed to use classfile API for reflection proxy-generation. Actual implementation of `ProxyGenerator` is focused on performance, however it causes JDK bootstrap regressions. `ProxyGenerator.TEMPLATE` class model is statically created and each proxy class is transformed from the template.
>> 
>> This patch is intended to examine plain proxy generation impact on performance and JDK bootstrap (vs proxy transformation from template).
>> 
>> The generated proxy is migrated from static initialization to CONDY bootstrap.
>> 
>> Please review.
>> 
>> Thank you,
>> Adam
>
> Adam Sotona 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 13 additional commits since the last revision:
> 
>  - obsolete import
>  - Merge branch 'master' into JDK-8332457-proxy-startup
>  - missing bracket
>  - Update src/java.base/share/classes/java/lang/reflect/ProxyGenerator.java
>    
>    Co-authored-by: liach <7806504+liach at users.noreply.github.com>
>  - removed obsolete entry
>  - MTD_ cleanup
>  - fixed javadoc
>  - CONDY implementation of ProxyGenerator
>  - simplification of the proxy class loading
>  - more improvements
>  - ... and 3 more: https://git.openjdk.org/jdk/compare/62348071...942342d5

The condy bootstrapping adds a little noise when running this through an affected startup benchmark. Overall the net impact is small or even negative. This is a nice cleanup, though, but perhaps we ought to keep JDK-8332457 open (or file a new bug to keep investigating overheads).

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19410#issuecomment-2137310415

From prappo at openjdk.org  Wed May 29 12:47:02 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Wed, 29 May 2024 12:47:02 GMT
Subject: RFR: 8332826: Make hashCode methods in ArraysSupport friendlier
 [v2]
In-Reply-To: <Tp-e5hM6KkSCm7JvRiMLRKL4nuB_HSb_UUrV4Xk3DOk=.72009f0d-35fb-4d95-8af8-05ad7410e41d@github.com>
References: <ujd2AT3eYXrHPcSG0vMDe2WOx3INNPU1n0t8haKH0_M=.b1a168d7-ab4c-4920-92ef-1c72e5ffc0cf@github.com>
 <1tx_tl3PV2W5NCEXXawQY5V2ndnSOHPfjisypuhKdhA=.79840096-bac0-4da4-8102-c7ecea7cb5f0@github.com>
 <FBIH-xc1qN8grLt03to-5lUHj-jOEzsSk1HPMKZLmSU=.637e8eb0-b2eb-4a0d-a84e-610a142fa5a3@github.com>
 <Tp-e5hM6KkSCm7JvRiMLRKL4nuB_HSb_UUrV4Xk3DOk=.72009f0d-35fb-4d95-8af8-05ad7410e41d@github.com>
Message-ID: <ARAKf_bShs9-3lUlQL1x4oKvtzp6ZgRRzPe_h9oFDIk=.d98e7c72-fe6a-48d4-bcf5-ac06d7870199@github.com>

On Tue, 28 May 2024 20:40:30 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/util/ArraysSupport.java line 275:
>> 
>>> 273:         return switch (length) {
>>> 274:             case 0 -> initialValue;
>>> 275:             case 1 -> 31 * initialValue + (a[fromIndex] & 0xff);
>> 
>> For clarity, if you think it helps:
>> Suggestion:
>> 
>>             case 1 -> 31 * initialValue + Byte.toUnsignedInt(a[fromIndex]);
>
> I don't care as long as microbenchmarks don't get a hiccup.

@cl4es, here are some results from my machine (macosx-aarch64):

Name                       (size) Cnt     Base    Error      Test    Error  Unit  Change
ArraysHashCode.bytes            1  15    0.715 ?  0.004     0.725 ?  0.029 ns/op   0.99x (p = 0.182 )
ArraysHashCode.bytes           10  15    3.753 ?  0.024     3.747 ?  0.011 ns/op   1.00x (p = 0.322 )
ArraysHashCode.bytes          100  15   69.731 ?  0.157    69.737 ?  0.092 ns/op   1.00x (p = 0.891 )
ArraysHashCode.bytes        10000  15 9369.386 ?  1.449  9372.008 ?  6.678 ns/op   1.00x (p = 0.133 )
ArraysHashCode.chars            1  15    0.719 ?  0.024     0.734 ?  0.024 ns/op   0.98x (p = 0.076 )
ArraysHashCode.chars           10  15    3.744 ?  0.005     3.746 ?  0.004 ns/op   1.00x (p = 0.308 )
ArraysHashCode.chars          100  15   69.741 ?  0.112    69.714 ?  0.044 ns/op   1.00x (p = 0.365 )
ArraysHashCode.chars        10000  15 9367.123 ?  5.320  9371.325 ?  6.407 ns/op   1.00x (p = 0.046 )
ArraysHashCode.ints             1  15    0.711 ?  0.013     0.706 ?  0.006 ns/op   1.01x (p = 0.137 )
ArraysHashCode.ints            10  15    3.750 ?  0.002     3.752 ?  0.004 ns/op   1.00x (p = 0.283 )
ArraysHashCode.ints           100  15   69.753 ?  0.086    69.711 ?  0.016 ns/op   1.00x (p = 0.065 )
ArraysHashCode.ints         10000  15 9376.225 ?  5.845  9376.218 ? 12.181 ns/op   1.00x (p = 0.999 )
ArraysHashCode.multibytes       1  15    0.741 ?  0.001     0.740 ?  0.001 ns/op   1.00x (p = 0.038 )
ArraysHashCode.multibytes      10  15    2.737 ?  0.001     2.826 ?  0.136 ns/op   0.97x (p = 0.017 )
ArraysHashCode.multibytes     100  15   32.202 ?  0.059    32.153 ?  0.006 ns/op   1.00x (p = 0.004*)
ArraysHashCode.multibytes   10000  15 4922.740 ? 25.590  4921.468 ?  7.372 ns/op   1.00x (p = 0.846 )
ArraysHashCode.multichars       1  15    0.740 ?  0.005     0.740 ?  0.000 ns/op   1.00x (p = 0.996 )
ArraysHashCode.multichars      10  15    2.732 ?  0.002     2.737 ?  0.003 ns/op   1.00x (p = 0.000*)
ArraysHashCode.multichars     100  15   32.109 ?  0.017    32.182 ?  0.028 ns/op   1.00x (p = 0.000*)
ArraysHashCode.multichars   10000  15 4925.750 ? 46.366  4930.684 ? 26.001 ns/op   1.00x (p = 0.704 )
ArraysHashCode.multiints        1  15    0.740 ?  0.000     0.739 ?  0.000 ns/op   1.00x (p = 0.000*)
ArraysHashCode.multiints       10  15    2.919 ?  0.002     2.953 ?  0.059 ns/op   0.99x (p = 0.033 )
ArraysHashCode.multiints      100  15   32.140 ?  0.011    32.094 ?  0.004 ns/op   1.00x (p = 0.000*)
ArraysHashCode.multiints    10000  15 4918.911 ?  3.512  4913.884 ? 11.618 ns/op   1.00x (p = 0.105 )
ArraysHashCode.multishorts      1  15    0.740 ?  0.001     0.739 ?  0.000 ns/op   1.00x (p = 0.000*)
ArraysHashCode.multishorts     10  15    2.736 ?  0.002     2.733 ?  0.008 ns/op   1.00x (p = 0.159 )
ArraysHashCode.multishorts    100  15   32.162 ?  0.033    32.105 ?  0.008 ns/op   1.00x (p = 0.000*)
ArraysHashCode.multishorts  10000  15 4916.984 ?  3.276  4912.000 ? 11.479 ns/op   1.00x (p = 0.103 )
ArraysHashCode.shorts           1  15    0.711 ?  0.023     0.709 ?  0.016 ns/op   1.00x (p = 0.818 )
ArraysHashCode.shorts          10  15    3.745 ?  0.003     3.739 ?  0.010 ns/op   1.00x (p = 0.049 )
ArraysHashCode.shorts         100  15   69.725 ?  0.082    69.620 ?  0.051 ns/op   1.00x (p = 0.000*)
ArraysHashCode.shorts       10000  15 9370.882 ?  8.306  9356.215 ?  3.996 ns/op   1.00x (p = 0.000*)
  * = significant

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19414#discussion_r1618821363

From prappo at openjdk.org  Wed May 29 12:56:02 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Wed, 29 May 2024 12:56:02 GMT
Subject: RFR: 8332826: Make hashCode methods in ArraysSupport friendlier
 [v2]
In-Reply-To: <FBIH-xc1qN8grLt03to-5lUHj-jOEzsSk1HPMKZLmSU=.637e8eb0-b2eb-4a0d-a84e-610a142fa5a3@github.com>
References: <ujd2AT3eYXrHPcSG0vMDe2WOx3INNPU1n0t8haKH0_M=.b1a168d7-ab4c-4920-92ef-1c72e5ffc0cf@github.com>
 <1tx_tl3PV2W5NCEXXawQY5V2ndnSOHPfjisypuhKdhA=.79840096-bac0-4da4-8102-c7ecea7cb5f0@github.com>
 <FBIH-xc1qN8grLt03to-5lUHj-jOEzsSk1HPMKZLmSU=.637e8eb0-b2eb-4a0d-a84e-610a142fa5a3@github.com>
Message-ID: <sXR2o-TfhZ_35uvl1T61u8d3cWLj-kgTb1b86xketRk=.533af83c-54eb-4b3e-9efa-52502fc245ee@github.com>

On Tue, 28 May 2024 19:13:50 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix incorrect utf16 hashCode adaptation
>
> src/java.base/share/classes/jdk/internal/util/ArraysSupport.java line 252:
> 
>> 250:         return switch (length) {
>> 251:             case 0 -> initialValue;
>> 252:             case 1 -> 31 * initialValue + (int) a[fromIndex];
> 
> Suggestion:
> 
>             case 1 -> 31 * initialValue + (int) a[fromIndex]; // sign extension

To be honest, I don't think that this cast is needed. A better solution than to add a comment would be to delete all `(int)` casts from new `hashCode*` methods of `ArraysSupport`.

Those `(int)` casts migrated from `hashCode` methods of `Arrays` where there were used if neither of two `+` operands were of type `int`. But in `ArraysSupport` it's no longer the case: `31 * initialValue` is always `int` because `initialValue` is. So, `a[fromIndex]` is promoted to `int` by the virtue of https://docs.oracle.com/javase/specs/jls/se22/html/jls-5.html#jls-5.6.

For more confidence, consider that the `private static int hashCode` methods (implementation) of `ArraysSupport` do not have those casts.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19414#discussion_r1618835934

From liach at openjdk.org  Wed May 29 13:06:05 2024
From: liach at openjdk.org (Chen Liang)
Date: Wed, 29 May 2024 13:06:05 GMT
Subject: RFR: 8332457: Examine startup overheads from JDK-8294961 [v12]
In-Reply-To: <NP-R_t0gqI7icqXoea0pCTTySYMPzl2-j93QtKMpH9A=.3574da5b-67f2-4aa7-ae7d-ac6cd2415713@github.com>
References: <YdSsOH6RBi4-Xy1ZTpSdTqQprzvhAYIenwxWxvC6GrU=.6961b30c-2d67-49b6-aa3e-b4736be0458b@github.com>
 <NP-R_t0gqI7icqXoea0pCTTySYMPzl2-j93QtKMpH9A=.3574da5b-67f2-4aa7-ae7d-ac6cd2415713@github.com>
Message-ID: <RZ2LUfHtF7kcPmg09eElX1WtD25SaOx0eGTLDrZiMOY=.ca597757-df25-4d58-9260-1e89df70dc7b@github.com>

On Wed, 29 May 2024 07:17:38 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> [JDK-8294961](https://bugs.openjdk.org/browse/JDK-8294961) changed to use classfile API for reflection proxy-generation. Actual implementation of `ProxyGenerator` is focused on performance, however it causes JDK bootstrap regressions. `ProxyGenerator.TEMPLATE` class model is statically created and each proxy class is transformed from the template.
>> 
>> This patch is intended to examine plain proxy generation impact on performance and JDK bootstrap (vs proxy transformation from template).
>> 
>> The generated proxy is migrated from static initialization to CONDY bootstrap.
>> 
>> Please review.
>> 
>> Thank you,
>> Adam
>
> Adam Sotona 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 13 additional commits since the last revision:
> 
>  - obsolete import
>  - Merge branch 'master' into JDK-8332457-proxy-startup
>  - missing bracket
>  - Update src/java.base/share/classes/java/lang/reflect/ProxyGenerator.java
>    
>    Co-authored-by: liach <7806504+liach at users.noreply.github.com>
>  - removed obsolete entry
>  - MTD_ cleanup
>  - fixed javadoc
>  - CONDY implementation of ProxyGenerator
>  - simplification of the proxy class loading
>  - more improvements
>  - ... and 3 more: https://git.openjdk.org/jdk/compare/7a251c2c...942342d5

Shouldn't condy mainly benefit the cases where only some of the methods are called so the proxy doesn't have to initialize all methods with reflection, or the case where a proxy is created but none of its methods is called? Does it show a regression in those cases as well?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19410#issuecomment-2137366357

From vklang at openjdk.org  Wed May 29 13:29:08 2024
From: vklang at openjdk.org (Viktor Klang)
Date: Wed, 29 May 2024 13:29:08 GMT
Subject: RFR: 8322732: ForkJoinPool may underutilize cores in async mode
 [v7]
In-Reply-To: <HDSzlGiKtB10QAHsZiC06nJ79ofx26RbzSROrLuBepg=.29855e54-4d7e-4d9f-97b6-e1cffb117690@github.com>
References: <xRyDMAsSZ7obqpr3Aoc5qrHqILeJMxFVCeiRdctMI3U=.d5d3cd56-32eb-4431-ac01-081822fc86c6@github.com>
 <HDSzlGiKtB10QAHsZiC06nJ79ofx26RbzSROrLuBepg=.29855e54-4d7e-4d9f-97b6-e1cffb117690@github.com>
Message-ID: <MwbzuvBhZdh-sG4dBTez6XVFUiw8YIzYLJRkoZOKkOs=.ac805c82-0a49-43c6-9164-450043802347@github.com>

On Wed, 29 May 2024 11:33:40 GMT, Doug Lea <dl at openjdk.org> wrote:

>> This set of changes address causes of poor utilization with small numbers of cores due to overly aggressive contention avoidance. A number of further adjustments were needed to still avoid most contention effects in deployments with large numbers of cores
>
> Doug Lea 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 41 additional commits since the last revision:
> 
>  - Merge branch 'openjdk:master' into JDK-8322732
>  - Add test for utilization with interdependent tasks
>  - Un-misplace onSpinWait call
>  - Adjust control flow
>  - Reduce memory stalls
>  - Merge branch 'openjdk:master' into JDK-8322732
>  - More performance tradoffs
>  - Address review comments
>  - Merge branch 'openjdk:master' into JDK-8322732
>  - Repack some fields; adjust control flow
>  - ... and 31 more: https://git.openjdk.org/jdk/compare/9388a872...cf5fe55c

src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 912:

> 910:      * enough to avoid resizing in most tree-structured tasks, but
> 911:      * larger for external queues where both false-sharing problems
> 912:      * and the need for resizing are more common..  (Maintenance note:

Suggestion:

     * and the need for resizing are more common.  (Maintenance note:

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19131#discussion_r1618884462

From dfuchs at openjdk.org  Wed May 29 13:46:02 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 29 May 2024 13:46:02 GMT
Subject: RFR: 8331879: Clean up non-standard use of /// comments in
 `java.base` [v2]
In-Reply-To: <PkVqSQtpxtoqeA6HppVjaaktDiquGqXkNT_v49aK-vM=.ea0d04b6-5b0d-487b-8b2b-190954ca5a7a@github.com>
References: <BiSTG8MtjyRt2txRK2DIxsmbPPq6Pvp7QQzOnHXbH6w=.b01b4872-dc8b-4e4f-bae6-bdc501da33a6@github.com>
 <PkVqSQtpxtoqeA6HppVjaaktDiquGqXkNT_v49aK-vM=.ea0d04b6-5b0d-487b-8b2b-190954ca5a7a@github.com>
Message-ID: <kuueAO4AVu0qj0HZ1LaglR8_pSMzuA9SFVURZFnbu6w=.38b23b92-9fa5-402a-8a8b-484e8b8be0e0@github.com>

On Tue, 28 May 2024 22:31:15 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> With the advent of JEP 467, `///` comments may be treated as documentation comments, and may be subject to the recently new `javac` warning about "dangling doc comments" in unexpected places.
>> 
>> In keeping with the policy to keep the `java.base` module free of all `javac` warnings, this patch proposes edits to existing uses of `///`.
>> 
>> There are two dominant policies in the proposed changes. 
>> 1. A long horizontal line of `/////` is replaced by `//-----`
>> 2. A long vertical series of lines beginning `///` is replaced by lines beginning `//|`.
>> 
>> As with all style changes, I have also tried to honor local usage, for consistency.
>> 
>> In one place, a pair of comments appeared to contain directives (`CLOVER:ON`, `CLOVER:OFF`).  I investigated the use of such comments to determine that the exact form of the comment prefix was not significant. (Phew!)
>> 
>> 
>> (This PR is informally blocked by JEP 467).
>
> Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision:
> 
>   incorporate review comments

I like `//---` ; +1!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19130#issuecomment-2137452920

From vklang at openjdk.org  Wed May 29 14:04:09 2024
From: vklang at openjdk.org (Viktor Klang)
Date: Wed, 29 May 2024 14:04:09 GMT
Subject: RFR: 8322732: ForkJoinPool may underutilize cores in async mode
 [v7]
In-Reply-To: <HDSzlGiKtB10QAHsZiC06nJ79ofx26RbzSROrLuBepg=.29855e54-4d7e-4d9f-97b6-e1cffb117690@github.com>
References: <xRyDMAsSZ7obqpr3Aoc5qrHqILeJMxFVCeiRdctMI3U=.d5d3cd56-32eb-4431-ac01-081822fc86c6@github.com>
 <HDSzlGiKtB10QAHsZiC06nJ79ofx26RbzSROrLuBepg=.29855e54-4d7e-4d9f-97b6-e1cffb117690@github.com>
Message-ID: <pie4FuxJATfSyYb0cmMDMh2E5FTh2-dpRV-D1uBLM9c=.80d4afeb-a782-4f76-8751-089ed8464694@github.com>

On Wed, 29 May 2024 11:33:40 GMT, Doug Lea <dl at openjdk.org> wrote:

>> This set of changes address causes of poor utilization with small numbers of cores due to overly aggressive contention avoidance. A number of further adjustments were needed to still avoid most contention effects in deployments with large numbers of cores
>
> Doug Lea 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 41 additional commits since the last revision:
> 
>  - Merge branch 'openjdk:master' into JDK-8322732
>  - Add test for utilization with interdependent tasks
>  - Un-misplace onSpinWait call
>  - Adjust control flow
>  - Reduce memory stalls
>  - Merge branch 'openjdk:master' into JDK-8322732
>  - More performance tradoffs
>  - Address review comments
>  - Merge branch 'openjdk:master' into JDK-8322732
>  - Repack some fields; adjust control flow
>  - ... and 31 more: https://git.openjdk.org/jdk/compare/2d55c424...cf5fe55c

src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 1452:

> 1450:          * Runs the given task, as well as remaining local tasks.
> 1451:          */
> 1452:         final void topLevelExec(ForkJoinTask<?> task, int cfg) {

Looks real clean, nice work @DougLea

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19131#discussion_r1618948755

From vklang at openjdk.org  Wed May 29 14:08:10 2024
From: vklang at openjdk.org (Viktor Klang)
Date: Wed, 29 May 2024 14:08:10 GMT
Subject: RFR: 8322732: ForkJoinPool may underutilize cores in async mode
 [v7]
In-Reply-To: <HDSzlGiKtB10QAHsZiC06nJ79ofx26RbzSROrLuBepg=.29855e54-4d7e-4d9f-97b6-e1cffb117690@github.com>
References: <xRyDMAsSZ7obqpr3Aoc5qrHqILeJMxFVCeiRdctMI3U=.d5d3cd56-32eb-4431-ac01-081822fc86c6@github.com>
 <HDSzlGiKtB10QAHsZiC06nJ79ofx26RbzSROrLuBepg=.29855e54-4d7e-4d9f-97b6-e1cffb117690@github.com>
Message-ID: <qdHE4RlUZ7U5MPfiRHzVW6o8QhgasshU2Bm9hPcDKPM=.e8df30ec-0f01-4440-a1e8-f1257f1de945@github.com>

On Wed, 29 May 2024 11:33:40 GMT, Doug Lea <dl at openjdk.org> wrote:

>> This set of changes address causes of poor utilization with small numbers of cores due to overly aggressive contention avoidance. A number of further adjustments were needed to still avoid most contention effects in deployments with large numbers of cores
>
> Doug Lea 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 41 additional commits since the last revision:
> 
>  - Merge branch 'openjdk:master' into JDK-8322732
>  - Add test for utilization with interdependent tasks
>  - Un-misplace onSpinWait call
>  - Adjust control flow
>  - Reduce memory stalls
>  - Merge branch 'openjdk:master' into JDK-8322732
>  - More performance tradoffs
>  - Address review comments
>  - Merge branch 'openjdk:master' into JDK-8322732
>  - Repack some fields; adjust control flow
>  - ... and 31 more: https://git.openjdk.org/jdk/compare/f715b3e6...cf5fe55c

src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 1857:

> 1855:                                        (LMASK & c)))));
> 1856:         }
> 1857:         if ((tryTerminate(false, false) & STOP) == 0 && w != null) {

Suggestion:

        if ((tryTerminate(false, false) & STOP) == 0L && w != null) {

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19131#discussion_r1618956269

From vklang at openjdk.org  Wed May 29 14:12:11 2024
From: vklang at openjdk.org (Viktor Klang)
Date: Wed, 29 May 2024 14:12:11 GMT
Subject: RFR: 8322732: ForkJoinPool may underutilize cores in async mode
 [v7]
In-Reply-To: <HDSzlGiKtB10QAHsZiC06nJ79ofx26RbzSROrLuBepg=.29855e54-4d7e-4d9f-97b6-e1cffb117690@github.com>
References: <xRyDMAsSZ7obqpr3Aoc5qrHqILeJMxFVCeiRdctMI3U=.d5d3cd56-32eb-4431-ac01-081822fc86c6@github.com>
 <HDSzlGiKtB10QAHsZiC06nJ79ofx26RbzSROrLuBepg=.29855e54-4d7e-4d9f-97b6-e1cffb117690@github.com>
Message-ID: <RyHSHRqQ8d6lOhVnhQXxBOP5DVwXSYPrMxo1lVAx1Sg=.d6868a1c-30ad-4759-b389-8f002a2e21d5@github.com>

On Wed, 29 May 2024 11:33:40 GMT, Doug Lea <dl at openjdk.org> wrote:

>> This set of changes address causes of poor utilization with small numbers of cores due to overly aggressive contention avoidance. A number of further adjustments were needed to still avoid most contention effects in deployments with large numbers of cores
>
> Doug Lea 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 41 additional commits since the last revision:
> 
>  - Merge branch 'openjdk:master' into JDK-8322732
>  - Add test for utilization with interdependent tasks
>  - Un-misplace onSpinWait call
>  - Adjust control flow
>  - Reduce memory stalls
>  - Merge branch 'openjdk:master' into JDK-8322732
>  - More performance tradoffs
>  - Address review comments
>  - Merge branch 'openjdk:master' into JDK-8322732
>  - Repack some fields; adjust control flow
>  - ... and 31 more: https://git.openjdk.org/jdk/compare/01d11057...cf5fe55c

src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 1969:

> 1967:                 else if ((e & SHUTDOWN) == 0)
> 1968:                     return 0;
> 1969:                 else if (compareAndSetCtl(c, c) && casRunState(e, e | STOP))

is the `compareAndSetCtl(c, c)` needed for the read+write fence if ctl == c?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19131#discussion_r1618963723

From prappo at openjdk.org  Wed May 29 14:13:11 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Wed, 29 May 2024 14:13:11 GMT
Subject: RFR: 8332161: Test restoring echo in the Console implementation
 (java.base) [v6]
In-Reply-To: <FkVs4Tu1LpzmoozGa1zmZqqB4KsVsCoRyh7sQ1A7cIc=.f830cded-5ecf-402c-9679-57b6c35bbe63@github.com>
References: <aSxuvnY7ghWwuDuegcWKJKlL_3KUCdIS_jHgTsn43ow=.b4d2e8d9-ffea-4318-9004-27b18298436e@github.com>
 <FkVs4Tu1LpzmoozGa1zmZqqB4KsVsCoRyh7sQ1A7cIc=.f830cded-5ecf-402c-9679-57b6c35bbe63@github.com>
Message-ID: <cWhe7J1c2aCf8el5s5so5pH8pi6rMBByUBjFGRH1oeU=.2967005e-6ee7-4343-b661-1a5ef84089a8@github.com>

On Tue, 28 May 2024 16:56:18 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> This test intends to verify the behavior of JdkConsole for the java.base module, wrt restoring the echo. The test assumes the internal methods that sets/gets the echo status of the platform.
>
> Naoto Sato has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 23 commits:
> 
>  - incorporated the same fix from 8332922
>  - Merge branch 'master' into JDK-8332161-restoreEcho-Test
>  - Merge branch 'master' into JDK-8332161-restoreEcho-Test
>  - Merge branch 'JDK-8332084-restoreEcho-readLock' into JDK-8332161-restoreEcho-Test
>  - Added comment for restoreEchoLock
>  - fixing typo
>  - Merge branch 'JDK-8332084-restoreEcho-readLock' into JDK-8332161-restoreEcho-Test
>  - Merge branch 'master' into JDK-8332084-restoreEcho-readLock
>  - leftover typo
>  - get/setEcho() -> echo()
>  - ... and 13 more: https://git.openjdk.org/jdk/compare/b8f2ec90...2477adf4

I might be mistaken, but this looks like a very well written unit test, which tests that an implementation flag retains its initial value. This does not look like an end-to-end test, which we usually write.

I wonder if we can use `expect` to run two end-to-end tests as follows. The first test would set up a console with echo on and then verify that after the spawned command completes the echo is still on. The second test would do the same for echo off.

The difference between the above approach and the test that this PR has proposed is that with the above approach we won't rely on an implementation detail, whose relevance to an objectively observed state is non-obvious or unknown. Instead, we'll use an OS utility, which makes for a relevant, straightforward, and maintainable test.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19315#issuecomment-2137515849

From vklang at openjdk.org  Wed May 29 14:19:06 2024
From: vklang at openjdk.org (Viktor Klang)
Date: Wed, 29 May 2024 14:19:06 GMT
Subject: RFR: 8322732: ForkJoinPool may underutilize cores in async mode
 [v7]
In-Reply-To: <HDSzlGiKtB10QAHsZiC06nJ79ofx26RbzSROrLuBepg=.29855e54-4d7e-4d9f-97b6-e1cffb117690@github.com>
References: <xRyDMAsSZ7obqpr3Aoc5qrHqILeJMxFVCeiRdctMI3U=.d5d3cd56-32eb-4431-ac01-081822fc86c6@github.com>
 <HDSzlGiKtB10QAHsZiC06nJ79ofx26RbzSROrLuBepg=.29855e54-4d7e-4d9f-97b6-e1cffb117690@github.com>
Message-ID: <Qz7OFz6DW7MOVoACGVSzGwRlVwQUA-VSUjIvRABw_1o=.ef3c8bbe-9b88-42f8-a634-2075885227df@github.com>

On Wed, 29 May 2024 11:33:40 GMT, Doug Lea <dl at openjdk.org> wrote:

>> This set of changes address causes of poor utilization with small numbers of cores due to overly aggressive contention avoidance. A number of further adjustments were needed to still avoid most contention effects in deployments with large numbers of cores
>
> Doug Lea 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 41 additional commits since the last revision:
> 
>  - Merge branch 'openjdk:master' into JDK-8322732
>  - Add test for utilization with interdependent tasks
>  - Un-misplace onSpinWait call
>  - Adjust control flow
>  - Reduce memory stalls
>  - Merge branch 'openjdk:master' into JDK-8322732
>  - More performance tradoffs
>  - Address review comments
>  - Merge branch 'openjdk:master' into JDK-8322732
>  - Repack some fields; adjust control flow
>  - ... and 31 more: https://git.openjdk.org/jdk/compare/3d109313...cf5fe55c

src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 2061:

> 2059:                 w.stackPred = (int)pc;           // set ctl stack link
> 2060:                 qc = (active & LMASK) | ((pc - RC_UNIT) & UMASK);
> 2061:                 if (pc == (pc = compareAndExchangeCtl(pc, qc)))

If I'm reading this right you might want to add a comment :)

Suggestion:

                if (pc == (pc = compareAndExchangeCtl(pc, qc))) // consistent

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19131#discussion_r1618974704

From vklang at openjdk.org  Wed May 29 14:23:07 2024
From: vklang at openjdk.org (Viktor Klang)
Date: Wed, 29 May 2024 14:23:07 GMT
Subject: RFR: 8322732: ForkJoinPool may underutilize cores in async mode
 [v7]
In-Reply-To: <HDSzlGiKtB10QAHsZiC06nJ79ofx26RbzSROrLuBepg=.29855e54-4d7e-4d9f-97b6-e1cffb117690@github.com>
References: <xRyDMAsSZ7obqpr3Aoc5qrHqILeJMxFVCeiRdctMI3U=.d5d3cd56-32eb-4431-ac01-081822fc86c6@github.com>
 <HDSzlGiKtB10QAHsZiC06nJ79ofx26RbzSROrLuBepg=.29855e54-4d7e-4d9f-97b6-e1cffb117690@github.com>
Message-ID: <lP2WFKCj0qgiZKJLiXOzaY9uxqSRme8CS0viD0sPJ9w=.b79cd6c6-7ba2-4453-bdc2-e67b90006bda@github.com>

On Wed, 29 May 2024 11:33:40 GMT, Doug Lea <dl at openjdk.org> wrote:

>> This set of changes address causes of poor utilization with small numbers of cores due to overly aggressive contention avoidance. A number of further adjustments were needed to still avoid most contention effects in deployments with large numbers of cores
>
> Doug Lea 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 41 additional commits since the last revision:
> 
>  - Merge branch 'openjdk:master' into JDK-8322732
>  - Add test for utilization with interdependent tasks
>  - Un-misplace onSpinWait call
>  - Adjust control flow
>  - Reduce memory stalls
>  - Merge branch 'openjdk:master' into JDK-8322732
>  - More performance tradoffs
>  - Address review comments
>  - Merge branch 'openjdk:master' into JDK-8322732
>  - Repack some fields; adjust control flow
>  - ... and 31 more: https://git.openjdk.org/jdk/compare/1dc80514...cf5fe55c

src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 2094:

> 2092:                         if (((p = w.phase) & IDLE) != 0)
> 2093:                             p = awaitWork(w, delay); // block, drop, or exit
> 2094:                     }

I'm presuming the code below would be equivalent but avoid calculating the delay unless w.phase is IDLE?

Suggestion:

                    if ((p & IDLE) != 0 && ((p = w.phase) & IDLE) != 0) {
                        long delay = (((qc & RC_MASK) > 0L) ? 0L :
                                      (w.source != INVALID_ID) ? keepAlive :
                                      TIMEOUT_SLOP); // minimal delay if cascade
                        p = awaitWork(w, delay); // block, drop, or exit
                    }

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19131#discussion_r1618980694

From dl at openjdk.org  Wed May 29 14:49:08 2024
From: dl at openjdk.org (Doug Lea)
Date: Wed, 29 May 2024 14:49:08 GMT
Subject: RFR: 8322732: ForkJoinPool may underutilize cores in async mode
 [v7]
In-Reply-To: <MwbzuvBhZdh-sG4dBTez6XVFUiw8YIzYLJRkoZOKkOs=.ac805c82-0a49-43c6-9164-450043802347@github.com>
References: <xRyDMAsSZ7obqpr3Aoc5qrHqILeJMxFVCeiRdctMI3U=.d5d3cd56-32eb-4431-ac01-081822fc86c6@github.com>
 <HDSzlGiKtB10QAHsZiC06nJ79ofx26RbzSROrLuBepg=.29855e54-4d7e-4d9f-97b6-e1cffb117690@github.com>
 <MwbzuvBhZdh-sG4dBTez6XVFUiw8YIzYLJRkoZOKkOs=.ac805c82-0a49-43c6-9164-450043802347@github.com>
Message-ID: <Jf5DJTDkK4ksxuiXwsGrPbtMLUnXh7jU_-OruxZcj_E=.07fab537-512f-454a-a3d3-a37dd1396a14@github.com>

On Wed, 29 May 2024 13:26:10 GMT, Viktor Klang <vklang at openjdk.org> wrote:

>> Doug Lea 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 41 additional commits since the last revision:
>> 
>>  - Merge branch 'openjdk:master' into JDK-8322732
>>  - Add test for utilization with interdependent tasks
>>  - Un-misplace onSpinWait call
>>  - Adjust control flow
>>  - Reduce memory stalls
>>  - Merge branch 'openjdk:master' into JDK-8322732
>>  - More performance tradoffs
>>  - Address review comments
>>  - Merge branch 'openjdk:master' into JDK-8322732
>>  - Repack some fields; adjust control flow
>>  - ... and 31 more: https://git.openjdk.org/jdk/compare/c056aa9c...cf5fe55c
>
> src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 912:
> 
>> 910:      * enough to avoid resizing in most tree-structured tasks, but
>> 911:      * larger for external queues where both false-sharing problems
>> 912:      * and the need for resizing are more common..  (Maintenance note:
> 
> Suggestion:
> 
>      * and the need for resizing are more common.  (Maintenance note:

thanks, done.

> src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 1857:
> 
>> 1855:                                        (LMASK & c)))));
>> 1856:         }
>> 1857:         if ((tryTerminate(false, false) & STOP) == 0 && w != null) {
> 
> Suggestion:
> 
>         if ((tryTerminate(false, false) & STOP) == 0L && w != null) {

yes.

> src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 2061:
> 
>> 2059:                 w.stackPred = (int)pc;           // set ctl stack link
>> 2060:                 qc = (active & LMASK) | ((pc - RC_UNIT) & UMASK);
>> 2061:                 if (pc == (pc = compareAndExchangeCtl(pc, qc)))
> 
> If I'm reading this right you might want to add a comment :)
> 
> Suggestion:
> 
>                 if (pc == (pc = compareAndExchangeCtl(pc, qc))) // consistent

thanks, done.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19131#discussion_r1619023295
PR Review Comment: https://git.openjdk.org/jdk/pull/19131#discussion_r1619024417
PR Review Comment: https://git.openjdk.org/jdk/pull/19131#discussion_r1619025818

From dl at openjdk.org  Wed May 29 14:54:11 2024
From: dl at openjdk.org (Doug Lea)
Date: Wed, 29 May 2024 14:54:11 GMT
Subject: RFR: 8322732: ForkJoinPool may underutilize cores in async mode
 [v7]
In-Reply-To: <lP2WFKCj0qgiZKJLiXOzaY9uxqSRme8CS0viD0sPJ9w=.b79cd6c6-7ba2-4453-bdc2-e67b90006bda@github.com>
References: <xRyDMAsSZ7obqpr3Aoc5qrHqILeJMxFVCeiRdctMI3U=.d5d3cd56-32eb-4431-ac01-081822fc86c6@github.com>
 <HDSzlGiKtB10QAHsZiC06nJ79ofx26RbzSROrLuBepg=.29855e54-4d7e-4d9f-97b6-e1cffb117690@github.com>
 <lP2WFKCj0qgiZKJLiXOzaY9uxqSRme8CS0viD0sPJ9w=.b79cd6c6-7ba2-4453-bdc2-e67b90006bda@github.com>
Message-ID: <0vz_es_NDiKZm2fQrFxpl1ITEEzpCC2CQEBPqr_bEek=.c22c1b25-dfe0-4fc2-b102-4f5ef3dcbc08@github.com>

On Wed, 29 May 2024 14:19:52 GMT, Viktor Klang <vklang at openjdk.org> wrote:

>> Doug Lea 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 41 additional commits since the last revision:
>> 
>>  - Merge branch 'openjdk:master' into JDK-8322732
>>  - Add test for utilization with interdependent tasks
>>  - Un-misplace onSpinWait call
>>  - Adjust control flow
>>  - Reduce memory stalls
>>  - Merge branch 'openjdk:master' into JDK-8322732
>>  - More performance tradoffs
>>  - Address review comments
>>  - Merge branch 'openjdk:master' into JDK-8322732
>>  - Repack some fields; adjust control flow
>>  - ... and 31 more: https://git.openjdk.org/jdk/compare/2d88272f...cf5fe55c
>
> src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 2094:
> 
>> 2092:                         if (((p = w.phase) & IDLE) != 0)
>> 2093:                             p = awaitWork(w, delay); // block, drop, or exit
>> 2094:                     }
> 
> I'm presuming the code below would be equivalent but avoid calculating the delay unless w.phase is IDLE?
> 
> Suggestion:
> 
>                     if ((p & IDLE) != 0 && ((p = w.phase) & IDLE) != 0) {
>                         long delay = (((qc & RC_MASK) > 0L) ? 0L :
>                                       (w.source != INVALID_ID) ? keepAlive :
>                                       TIMEOUT_SLOP); // minimal delay if cascade
>                         p = awaitWork(w, delay); // block, drop, or exit
>                     }

Seems slightly better not to recheck until call, since previous loop would usually have caught this if there was actually any work.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19131#discussion_r1619034460

From dl at openjdk.org  Wed May 29 15:09:30 2024
From: dl at openjdk.org (Doug Lea)
Date: Wed, 29 May 2024 15:09:30 GMT
Subject: RFR: 8322732: ForkJoinPool may underutilize cores in async mode
 [v8]
In-Reply-To: <xRyDMAsSZ7obqpr3Aoc5qrHqILeJMxFVCeiRdctMI3U=.d5d3cd56-32eb-4431-ac01-081822fc86c6@github.com>
References: <xRyDMAsSZ7obqpr3Aoc5qrHqILeJMxFVCeiRdctMI3U=.d5d3cd56-32eb-4431-ac01-081822fc86c6@github.com>
Message-ID: <j1ZtqJkO0YmA_zDtIp6Skb6_8A6iXG24ACqufUbpX5Q=.7334cb0f-0389-45f1-9acb-26e6222e5af7@github.com>

> This set of changes address causes of poor utilization with small numbers of cores due to overly aggressive contention avoidance. A number of further adjustments were needed to still avoid most contention effects in deployments with large numbers of cores

Doug Lea has updated the pull request incrementally with one additional commit since the last revision:

  Address review comments

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19131/files
  - new: https://git.openjdk.org/jdk/pull/19131/files/cf5fe55c..e5c4a556

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19131&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19131&range=06-07

  Stats: 9 lines in 1 file changed: 1 ins; 3 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/19131.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19131/head:pull/19131

PR: https://git.openjdk.org/jdk/pull/19131

From alanb at openjdk.org  Wed May 29 15:35:41 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 29 May 2024 15:35:41 GMT
Subject: RFR: 8331189: Implementation of Scoped Values (Third Preview) [v2]
In-Reply-To: <kFWNL6QScozy3Z7CHuifpZgaobVm5ypn8dhNWiBebt4=.c47076f2-8a76-4bf1-b17d-5b50a0c9bb2f@github.com>
References: <kFWNL6QScozy3Z7CHuifpZgaobVm5ypn8dhNWiBebt4=.c47076f2-8a76-4bf1-b17d-5b50a0c9bb2f@github.com>
Message-ID: <Fgp7pXQcC722WTqX5RWGKMhSji4d_bIAPwlL_jZP3kg=.032a5aaa-3f9a-4d79-ad12-b8f4a22d6ea1@github.com>

> JEP 481 proposes Scoped Values to continue to preview in JDK 23 with one change. The type of the operation parameter of the callWhere method is changed to a new functional interface to avoid having the API throw Exception. With that change, the getWhere (and the corresponding method on Carrier) are no longer needed. The functional interface is not proposed for j.u.function at this time.

Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision:

 - Merge
 - Merge
 - Merge
 - Set JEP number
 - Sync up from loom repo
 - Merge
 - Initial commit

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19136/files
  - new: https://git.openjdk.org/jdk/pull/19136/files/744e8665..b2166e66

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19136&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19136&range=00-01

  Stats: 25898 lines in 731 files changed: 16263 ins; 5627 del; 4008 mod
  Patch: https://git.openjdk.org/jdk/pull/19136.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19136/head:pull/19136

PR: https://git.openjdk.org/jdk/pull/19136

From mcimadamore at openjdk.org  Wed May 29 15:40:08 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 29 May 2024 15:40:08 GMT
Subject: RFR: 8331865: Consolidate size and alignment checks in LayoutPath
In-Reply-To: <UmdCxnGlDjVJ98TCRxhGz0hIdQexIanpEUFPyd6jemM=.8a9fc62d-63a9-47d0-bd9d-48fb081053c4@github.com>
References: <CvKkdESp5-uHiuZtQvGortWnzOMV89pfjaCHNBIV4B4=.51ad0f01-2371-48af-b3c6-8a9b80518cdb@github.com>
 <YP62xs9MjNijSMC6gTf62GRswUyTAKNimgQGZ-PQnKY=.4edbc89a-1a01-4fdb-9880-096cab35af8a@github.com>
 <eTKhBQscqkgwLn6_x9fqwYHt2W_ECqPqkkzIoLCiKRk=.24c4319b-0877-4c17-aa90-6139fd4dc0fd@github.com>
 <UmdCxnGlDjVJ98TCRxhGz0hIdQexIanpEUFPyd6jemM=.8a9fc62d-63a9-47d0-bd9d-48fb081053c4@github.com>
Message-ID: <yUDS_ohYndvXtn-8stCDfNETLitUJdebjHUuRnjSC54=.c1bacd57-0464-46a0-8fa4-f0864eb6b1ea@github.com>

On Thu, 16 May 2024 14:11:47 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> > > Do we have any performance tests available to see if there are any potential impacts?
> > 
> > 
> > I've run all micro benchmarks whose name match `LoopOver*`. No regression was found. Few benchmarks seems a tad faster, but the percentages are so tiny that I'm sure it has nothing to do with the patch. I compared results before/after using [JMH visualizer](https://jmh.morethan.io/).
> 
> Results here: https://cr.openjdk.org/~mcimadamore/jdk/8331865/ Unfortunately I can't seem to be able to upload the results in the visualizer (which would be handy, so I could share a link to the results). Not sure if it's an issue in the visualizer, or in the cr server itself. But, it is possible to at least download the above results locally, and then upload them to the visualizer tool.

Here's a link to the results:
https://jmh.morethan.io/?sources=https://corsproxy.io/?https://cr.openjdk.org/~mcimadamore/jdk/8331865/loop_over_00_baseline.json,https://corsproxy.io/?https://cr.openjdk.org/~mcimadamore/jdk/8331865/loop_over_01_8331865.json

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19251#issuecomment-2137713233

From prappo at openjdk.org  Wed May 29 15:50:32 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Wed, 29 May 2024 15:50:32 GMT
Subject: RFR: 8332826: Make hashCode methods in ArraysSupport friendlier
 [v3]
In-Reply-To: <ujd2AT3eYXrHPcSG0vMDe2WOx3INNPU1n0t8haKH0_M=.b1a168d7-ab4c-4920-92ef-1c72e5ffc0cf@github.com>
References: <ujd2AT3eYXrHPcSG0vMDe2WOx3INNPU1n0t8haKH0_M=.b1a168d7-ab4c-4920-92ef-1c72e5ffc0cf@github.com>
Message-ID: <p0Cui4K3CfScK0nnDRK3B_QEuu1zJFXuajZDoebGn_4=.a8303c9a-3502-4f74-8934-6d5a2f5aa27a@github.com>

> Please review this PR, which supersedes a now withdrawn https://github.com/openjdk/jdk/pull/14831.
> 
> This PR replaces `ArraysSupport.vectorizedHashCode` with a set of more user-friendly methods. Here's a summary:
> 
> - Made the operand constants (i.e. `T_BOOLEAN` and friends) and the `vectorizedHashCode` method private
> 
> - Made the `vectorizedHashCode` method private, but didn't rename it. Renaming would dramatically increase this PR review cost, because that method's name is used by a lot of VM code. On a bright side, since the method is now private, it's no longer callable by clients of `ArraysSupport`, thus a problem of an inaccurate name is less severe.
> 
> - Made the `ArraysSupport.utf16HashCode` method private
> 
> - Moved tiny cases (i.e. 0, 1, 2) to `ArraysSupport`

Pavel Rappo has updated the pull request incrementally with three additional commits since the last revision:

 - Update copyright years
   
   Note: any commit hashes below might be outdated due to subsequent
   history rewriting (e.g. git rebase).
   
    + update src/java.base/share/classes/java/lang/CharacterName.java due to 4ed451d691c
    + update src/java.base/share/classes/java/lang/StringLatin1.java due to 4ed451d691c
    + update src/java.base/share/classes/java/nio/Heap-X-Buffer.java.template due to 4ed451d691c
    + update src/java.base/share/classes/jdk/internal/classfile/impl/AbstractPoolEntry.java due to 4ed451d691c
    + update src/java.base/share/classes/sun/security/util/DerValue.java due to 4ed451d691c
    + update src/java.base/unix/classes/sun/nio/fs/UnixPath.java due to 4ed451d691c
    + update test/hotspot/jtreg/compiler/intrinsics/TestArraysHashCode.java due to 4ed451d691c
 - Drop redundant (int) cast
 - Use Byte.toUnsignedInt not & 0xff

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19414/files
  - new: https://git.openjdk.org/jdk/pull/19414/files/adc7557d..53d4ed09

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19414&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19414&range=01-02

  Stats: 12 lines in 8 files changed: 0 ins; 0 del; 12 mod
  Patch: https://git.openjdk.org/jdk/pull/19414.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19414/head:pull/19414

PR: https://git.openjdk.org/jdk/pull/19414

From prappo at openjdk.org  Wed May 29 15:54:02 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Wed, 29 May 2024 15:54:02 GMT
Subject: RFR: 8332826: Make hashCode methods in ArraysSupport friendlier
 [v2]
In-Reply-To: <sXR2o-TfhZ_35uvl1T61u8d3cWLj-kgTb1b86xketRk=.533af83c-54eb-4b3e-9efa-52502fc245ee@github.com>
References: <ujd2AT3eYXrHPcSG0vMDe2WOx3INNPU1n0t8haKH0_M=.b1a168d7-ab4c-4920-92ef-1c72e5ffc0cf@github.com>
 <1tx_tl3PV2W5NCEXXawQY5V2ndnSOHPfjisypuhKdhA=.79840096-bac0-4da4-8102-c7ecea7cb5f0@github.com>
 <FBIH-xc1qN8grLt03to-5lUHj-jOEzsSk1HPMKZLmSU=.637e8eb0-b2eb-4a0d-a84e-610a142fa5a3@github.com>
 <sXR2o-TfhZ_35uvl1T61u8d3cWLj-kgTb1b86xketRk=.533af83c-54eb-4b3e-9efa-52502fc245ee@github.com>
Message-ID: <yzpOFAdED6HL6WCSC5LCZGUWNQBs4LcXsnI_GEEbVB4=.bb2185dd-ecf7-404d-b70f-f04a19ab2ee0@github.com>

On Wed, 29 May 2024 12:53:42 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/util/ArraysSupport.java line 252:
>> 
>>> 250:         return switch (length) {
>>> 251:             case 0 -> initialValue;
>>> 252:             case 1 -> 31 * initialValue + (int) a[fromIndex];
>> 
>> Suggestion:
>> 
>>             case 1 -> 31 * initialValue + (int) a[fromIndex]; // sign extension
>
> To be honest, I don't think that this cast is needed. A better solution than to add a comment would be to delete all `(int)` casts from new `hashCode*` methods of `ArraysSupport`.
> 
> Those `(int)` casts migrated from `hashCode` methods of `Arrays` where there were used if neither of two `+` operands were of type `int`. But in `ArraysSupport` it's no longer the case: `31 * initialValue` is always `int` because `initialValue` is. So, `a[fromIndex]` is promoted to `int` by the virtue of https://docs.oracle.com/javase/specs/jls/se22/html/jls-5.html#jls-5.6.
> 
> For more confidence, consider that the `private static int hashCode` methods (implementation) of `ArraysSupport` do not have those casts.

Removed casts in https://github.com/openjdk/jdk/pull/19414/commits/d8dabc68c4264520fd6c57c949049f2ab5c8e0ec.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19414#discussion_r1619127224

From prappo at openjdk.org  Wed May 29 15:54:03 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Wed, 29 May 2024 15:54:03 GMT
Subject: RFR: 8332826: Make hashCode methods in ArraysSupport friendlier
 [v2]
In-Reply-To: <ARAKf_bShs9-3lUlQL1x4oKvtzp6ZgRRzPe_h9oFDIk=.d98e7c72-fe6a-48d4-bcf5-ac06d7870199@github.com>
References: <ujd2AT3eYXrHPcSG0vMDe2WOx3INNPU1n0t8haKH0_M=.b1a168d7-ab4c-4920-92ef-1c72e5ffc0cf@github.com>
 <1tx_tl3PV2W5NCEXXawQY5V2ndnSOHPfjisypuhKdhA=.79840096-bac0-4da4-8102-c7ecea7cb5f0@github.com>
 <FBIH-xc1qN8grLt03to-5lUHj-jOEzsSk1HPMKZLmSU=.637e8eb0-b2eb-4a0d-a84e-610a142fa5a3@github.com>
 <Tp-e5hM6KkSCm7JvRiMLRKL4nuB_HSb_UUrV4Xk3DOk=.72009f0d-35fb-4d95-8af8-05ad7410e41d@github.com>
 <ARAKf_bShs9-3lUlQL1x4oKvtzp6ZgRRzPe_h9oFDIk=.d98e7c72-fe6a-48d4-bcf5-ac06d7870199@github.com>
Message-ID: <XSZhIa834EemkvztCmAL_vEanlvOsltjL9UGMq0OaJw=.ce058bec-ca7c-4174-bc67-91164fef76b0@github.com>

On Wed, 29 May 2024 12:44:45 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> I don't care as long as microbenchmarks don't get a hiccup.
>
> @cl4es, here are some results from my machine (macosx-aarch64):
> 
> Name                       (size) Cnt     Base    Error      Test    Error  Unit  Change
> ArraysHashCode.bytes            1  15    0.715 ?  0.004     0.725 ?  0.029 ns/op   0.99x (p = 0.182 )
> ArraysHashCode.bytes           10  15    3.753 ?  0.024     3.747 ?  0.011 ns/op   1.00x (p = 0.322 )
> ArraysHashCode.bytes          100  15   69.731 ?  0.157    69.737 ?  0.092 ns/op   1.00x (p = 0.891 )
> ArraysHashCode.bytes        10000  15 9369.386 ?  1.449  9372.008 ?  6.678 ns/op   1.00x (p = 0.133 )
> ArraysHashCode.chars            1  15    0.719 ?  0.024     0.734 ?  0.024 ns/op   0.98x (p = 0.076 )
> ArraysHashCode.chars           10  15    3.744 ?  0.005     3.746 ?  0.004 ns/op   1.00x (p = 0.308 )
> ArraysHashCode.chars          100  15   69.741 ?  0.112    69.714 ?  0.044 ns/op   1.00x (p = 0.365 )
> ArraysHashCode.chars        10000  15 9367.123 ?  5.320  9371.325 ?  6.407 ns/op   1.00x (p = 0.046 )
> ArraysHashCode.ints             1  15    0.711 ?  0.013     0.706 ?  0.006 ns/op   1.01x (p = 0.137 )
> ArraysHashCode.ints            10  15    3.750 ?  0.002     3.752 ?  0.004 ns/op   1.00x (p = 0.283 )
> ArraysHashCode.ints           100  15   69.753 ?  0.086    69.711 ?  0.016 ns/op   1.00x (p = 0.065 )
> ArraysHashCode.ints         10000  15 9376.225 ?  5.845  9376.218 ? 12.181 ns/op   1.00x (p = 0.999 )
> ArraysHashCode.multibytes       1  15    0.741 ?  0.001     0.740 ?  0.001 ns/op   1.00x (p = 0.038 )
> ArraysHashCode.multibytes      10  15    2.737 ?  0.001     2.826 ?  0.136 ns/op   0.97x (p = 0.017 )
> ArraysHashCode.multibytes     100  15   32.202 ?  0.059    32.153 ?  0.006 ns/op   1.00x (p = 0.004*)
> ArraysHashCode.multibytes   10000  15 4922.740 ? 25.590  4921.468 ?  7.372 ns/op   1.00x (p = 0.846 )
> ArraysHashCode.multichars       1  15    0.740 ?  0.005     0.740 ?  0.000 ns/op   1.00x (p = 0.996 )
> ArraysHashCode.multichars      10  15    2.732 ?  0.002     2.737 ?  0.003 ns/op   1.00x (p = 0.000*)
> ArraysHashCode.multichars     100  15   32.109 ?  0.017    32.182 ?  0.028 ns/op   1.00x (p = 0.000*)
> ArraysHashCode.multichars   10000  15 4925.750 ? 46.366  4930.684 ? 26.001 ns/op   1.00x (p = 0.704 )
> ArraysHashCode.multiints        1  15    0.740 ?  0.000     0.739 ?  0.000 ns/op   1.00x (p = 0.000*)
> ArraysHashCode.multiints       10  15    2.919 ?  0.002     2.953 ?  0.059 ns/op   0.99x (p = 0.033 )
> ArraysHashCode.multiints      100  15   32.140 ?  0.011    32.094 ?  0.004 ns/op   1.00x (p = 0.000*)
> ...

Just to clarify, the above comparison is between master and https://github.com/openjdk/jdk/pull/19414/commits/534ff367bc50ec4150e4b206ce7203c7ff9f5cad.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19414#discussion_r1619125150

From prappo at openjdk.org  Wed May 29 15:57:02 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Wed, 29 May 2024 15:57:02 GMT
Subject: RFR: 8332826: Make hashCode methods in ArraysSupport friendlier
 [v2]
In-Reply-To: <XSZhIa834EemkvztCmAL_vEanlvOsltjL9UGMq0OaJw=.ce058bec-ca7c-4174-bc67-91164fef76b0@github.com>
References: <ujd2AT3eYXrHPcSG0vMDe2WOx3INNPU1n0t8haKH0_M=.b1a168d7-ab4c-4920-92ef-1c72e5ffc0cf@github.com>
 <1tx_tl3PV2W5NCEXXawQY5V2ndnSOHPfjisypuhKdhA=.79840096-bac0-4da4-8102-c7ecea7cb5f0@github.com>
 <FBIH-xc1qN8grLt03to-5lUHj-jOEzsSk1HPMKZLmSU=.637e8eb0-b2eb-4a0d-a84e-610a142fa5a3@github.com>
 <Tp-e5hM6KkSCm7JvRiMLRKL4nuB_HSb_UUrV4Xk3DOk=.72009f0d-35fb-4d95-8af8-05ad7410e41d@github.com>
 <ARAKf_bShs9-3lUlQL1x4oKvtzp6ZgRRzPe_h9oFDIk=.d98e7c72-fe6a-48d4-bcf5-ac06d7870199@github.com>
 <XSZhIa834EemkvztCmAL_vEanlvOsltjL9UGMq0OaJw=.ce058bec-ca7c-4174-bc67-91164fef76b0@github.com>
Message-ID: <CmBDTMYWeGKklm4KEIe_AAtE9UsSdQWj5bkaXd04m5Y=.70eed0e2-9d8e-4728-a572-1ebf76a76ee8@github.com>

On Wed, 29 May 2024 15:50:05 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> @cl4es, here are some results from my machine (macosx-aarch64):
>> 
>> Name                       (size) Cnt     Base    Error      Test    Error  Unit  Change
>> ArraysHashCode.bytes            1  15    0.715 ?  0.004     0.725 ?  0.029 ns/op   0.99x (p = 0.182 )
>> ArraysHashCode.bytes           10  15    3.753 ?  0.024     3.747 ?  0.011 ns/op   1.00x (p = 0.322 )
>> ArraysHashCode.bytes          100  15   69.731 ?  0.157    69.737 ?  0.092 ns/op   1.00x (p = 0.891 )
>> ArraysHashCode.bytes        10000  15 9369.386 ?  1.449  9372.008 ?  6.678 ns/op   1.00x (p = 0.133 )
>> ArraysHashCode.chars            1  15    0.719 ?  0.024     0.734 ?  0.024 ns/op   0.98x (p = 0.076 )
>> ArraysHashCode.chars           10  15    3.744 ?  0.005     3.746 ?  0.004 ns/op   1.00x (p = 0.308 )
>> ArraysHashCode.chars          100  15   69.741 ?  0.112    69.714 ?  0.044 ns/op   1.00x (p = 0.365 )
>> ArraysHashCode.chars        10000  15 9367.123 ?  5.320  9371.325 ?  6.407 ns/op   1.00x (p = 0.046 )
>> ArraysHashCode.ints             1  15    0.711 ?  0.013     0.706 ?  0.006 ns/op   1.01x (p = 0.137 )
>> ArraysHashCode.ints            10  15    3.750 ?  0.002     3.752 ?  0.004 ns/op   1.00x (p = 0.283 )
>> ArraysHashCode.ints           100  15   69.753 ?  0.086    69.711 ?  0.016 ns/op   1.00x (p = 0.065 )
>> ArraysHashCode.ints         10000  15 9376.225 ?  5.845  9376.218 ? 12.181 ns/op   1.00x (p = 0.999 )
>> ArraysHashCode.multibytes       1  15    0.741 ?  0.001     0.740 ?  0.001 ns/op   1.00x (p = 0.038 )
>> ArraysHashCode.multibytes      10  15    2.737 ?  0.001     2.826 ?  0.136 ns/op   0.97x (p = 0.017 )
>> ArraysHashCode.multibytes     100  15   32.202 ?  0.059    32.153 ?  0.006 ns/op   1.00x (p = 0.004*)
>> ArraysHashCode.multibytes   10000  15 4922.740 ? 25.590  4921.468 ?  7.372 ns/op   1.00x (p = 0.846 )
>> ArraysHashCode.multichars       1  15    0.740 ?  0.005     0.740 ?  0.000 ns/op   1.00x (p = 0.996 )
>> ArraysHashCode.multichars      10  15    2.732 ?  0.002     2.737 ?  0.003 ns/op   1.00x (p = 0.000*)
>> ArraysHashCode.multichars     100  15   32.109 ?  0.017    32.182 ?  0.028 ns/op   1.00x (p = 0.000*)
>> ArraysHashCode.multichars   10000  15 4925.750 ? 46.366  4930.684 ? 26.001 ns/op   1.00x (p = 0.704 )
>> ArraysHashCode.multiints        1  15    0.740 ?  0.000     0.739 ?  0.000 ns/op   1.00x (p = 0.000*)
>> ArraysHashCode.multiints       10  15    2.919 ?  0.002     2.953 ?  0.059 ns/op   0.99x (p = 0.033 )
>> ArraysHashCode.multiints      100  15   32.140 ?  ...
>
> Just to clarify, the above comparison is between master and https://github.com/openjdk/jdk/pull/19414/commits/534ff367bc50ec4150e4b206ce7203c7ff9f5cad.

> For clarity, if you think it helps:

I did that and a little bit more in https://github.com/openjdk/jdk/pull/19414/commits/534ff367bc50ec4150e4b206ce7203c7ff9f5cad.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19414#discussion_r1619130669

From zhengyu.gu at servicenow.com  Wed May 29 16:34:37 2024
From: zhengyu.gu at servicenow.com (Zhengyu Gu)
Date: Wed, 29 May 2024 16:34:37 +0000
Subject: Question on Lambda function
In-Reply-To: <LV8PR08MB955444A8983A6E579694DFC7F0F22@LV8PR08MB9554.namprd08.prod.outlook.com>
References: <LV8PR08MB955444A8983A6E579694DFC7F0F22@LV8PR08MB9554.namprd08.prod.outlook.com>
Message-ID: <LV8PR08MB955466D6C9CCE80D1F4E48F4F0F22@LV8PR08MB9554.namprd08.prod.outlook.com>

Hello Lambda experts,

Since we upgraded JDK from 11 to 17, we?re experiencing metaspace pressure, largely due to Lambda class implementation changes.

There?s a scenario (see attached test case),  that is especially puzzled me, hopefully, you can share some insights.

In this test case, there is only one Lambda class is created inside the loop, but each one for the same functions outside loop.

Example output:

0: Func =  LambdaFunc$$Lambda/0x00001f80000c4a20 at 4de8b406
testMethod() called
1: Func =  LambdaFunc$$Lambda/0x00001f80000c4a20 at 4de8b406
testMethod() called
2: Func =  LambdaFunc$$Lambda/0x00001f80000c4a20 at 4de8b406
testMethod() called
3: Func =  LambdaFunc$$Lambda/0x00001f80000c4a20 at 4de8b406
testMethod() called
4: Func =  LambdaFunc$$Lambda/0x00001f80000c4a20 at 4de8b406
testMethod() called

?.

Outside loop1, Func =  LambdaFunc$$Lambda/0x00001f80000c4c58 at 402f32ff
testMethod() called
Outside loop2 Func = LambdaFunc$$Lambda/0x00001f80000d1000 at 5ae9a829
testMethod() called
Outside loop3 Func = LambdaFunc$$Lambda/0x00001f80000d1238 at 548b7f67
testMethod() called

And jcmd also confirmed there were 4 Lambda classes created:

  49: CLD 0x000060000134cb50: "app" instance of jdk.internal.loader.ClassLoaders$AppClassLoader
      Loaded classes:
         1:    LambdaFunc$$Lambda/0x00001f80000d1238
         2:    LambdaFunc$$Lambda/0x00001f80000d1000
         3:    LambdaFunc$$Lambda/0x00001f80000c4c58
         4:    LambdaFunc$$Lambda/0x00001f80000c4a20
         5:    LambdaFunc

Looking into bytecode, all four call sites have the same invokedynamic bytecode (invokedynamic #7,  0              // InvokeDynamic #0:run:()Ljava/lang/Runnable; ) and the first invokedynamic bytecode is inside the loop.

But when I ran the program with -XX:+TraceBytecodes, it seems that the first invokedynamic was hoisted and result was used in the subsequence loop.

Can anyone explain where this magic happens?  If the magic can apply to the instances outside the loop, so that only one Lambda class is created?


Thank you for your time and expertise,

-Zhengyu



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240529/80713643/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: LambdaFunc.java
Type: application/octet-stream
Size: 936 bytes
Desc: LambdaFunc.java
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240529/80713643/LambdaFunc-0001.java>

From sgibbons at openjdk.org  Wed May 29 16:55:14 2024
From: sgibbons at openjdk.org (Scott Gibbons)
Date: Wed, 29 May 2024 16:55:14 GMT
Subject: RFR: 8320448: Accelerate IndexOf using AVX2 [v47]
In-Reply-To: <hfkXncWufSFi3ulNYKQzo3hUs4wfxPOX-GLAT9VF6n8=.1a2b0ca7-92e0-4ea8-a92b-6ee7e82fdd14@github.com>
References: <uWi4QxH31hL93771gkl_GgvP0m84IRSoR_1Yi8hD17E=.bc6ed458-7081-4c3f-9348-f59358fa05a4@github.com>
 <hfkXncWufSFi3ulNYKQzo3hUs4wfxPOX-GLAT9VF6n8=.1a2b0ca7-92e0-4ea8-a92b-6ee7e82fdd14@github.com>
Message-ID: <pShxcm8ICxLtuDY2OiTQSxrm9YRqeiUxhhK5zbXpFng=.ec3a7fd2-3dcd-4c87-81b5-938b32ac8f9f@github.com>

On Tue, 28 May 2024 23:52:27 GMT, Scott Gibbons <sgibbons at openjdk.org> wrote:

>> Re-write the IndexOf code without the use of the pcmpestri instruction, only using AVX2 instructions.  This change accelerates String.IndexOf on average 1.3x for AVX2.  The benchmark numbers:
>> 
>> 
>> Benchmark	                                               Score		Latest		
>> StringIndexOf.advancedWithMediumSub   343.573		317.934		0.925375393x
>> StringIndexOf.advancedWithShortSub1	  1039.081		1053.96		1.014319384x
>> StringIndexOf.advancedWithShortSub2	      55.828		110.541		1.980027943x
>> StringIndexOf.constantPattern	                9.361		11.906		1.271872663x
>> StringIndexOf.searchCharLongSuccess	        4.216		4.218		1.000474383x
>> StringIndexOf.searchCharMediumSuccess	3.133		3.216		1.02649218x
>> StringIndexOf.searchCharShortSuccess	3.76		        3.761		1.000265957x
>> StringIndexOf.success	                                9.186		9.713		1.057369911x
>> StringIndexOf.successBig	                      14.341		46.343		3.231504079x
>> StringIndexOfChar.latin1_AVX2_String	  6220.918		12154.52		1.953814533x
>> StringIndexOfChar.latin1_AVX2_char	  5503.556		5540.044		1.006629895x
>> StringIndexOfChar.latin1_SSE4_String	  6978.854		6818.689		0.977049957x
>> StringIndexOfChar.latin1_SSE4_char	  5657.499		5474.624		0.967675646x
>> StringIndexOfChar.latin1_Short_String	  7132.541		6863.359		0.962260014x
>> StringIndexOfChar.latin1_Short_char	16013.389	      16162.437		1.009307711x
>> StringIndexOfChar.latin1_mixed_String	  7386.123	      14771.622		1.999915517x
>> StringIndexOfChar.latin1_mixed_char	  9901.671		9782.245		0.987938803
>
> Scott Gibbons has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Move assert to where it's actually important.

Thank you all for the comments.  If there are no objections, I'll integrate these fixes tomorrow morning.

I've run tier1-3 tests with the appropriate options on my machine with no errors, so my confidence is high.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/16753#issuecomment-2137861781

From dl at openjdk.org  Wed May 29 16:58:08 2024
From: dl at openjdk.org (Doug Lea)
Date: Wed, 29 May 2024 16:58:08 GMT
Subject: RFR: 8322732: ForkJoinPool may underutilize cores in async mode
 [v7]
In-Reply-To: <RyHSHRqQ8d6lOhVnhQXxBOP5DVwXSYPrMxo1lVAx1Sg=.d6868a1c-30ad-4759-b389-8f002a2e21d5@github.com>
References: <xRyDMAsSZ7obqpr3Aoc5qrHqILeJMxFVCeiRdctMI3U=.d5d3cd56-32eb-4431-ac01-081822fc86c6@github.com>
 <HDSzlGiKtB10QAHsZiC06nJ79ofx26RbzSROrLuBepg=.29855e54-4d7e-4d9f-97b6-e1cffb117690@github.com>
 <RyHSHRqQ8d6lOhVnhQXxBOP5DVwXSYPrMxo1lVAx1Sg=.d6868a1c-30ad-4759-b389-8f002a2e21d5@github.com>
Message-ID: <mEvn2QaPk4LO47-Ae-r0iKifMiU90ezrvQgx4gF-lVs=.58dc8132-68d7-430a-bdb2-3ac0836afed3@github.com>

On Wed, 29 May 2024 14:09:51 GMT, Viktor Klang <vklang at openjdk.org> wrote:

>> Doug Lea 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 41 additional commits since the last revision:
>> 
>>  - Merge branch 'openjdk:master' into JDK-8322732
>>  - Add test for utilization with interdependent tasks
>>  - Un-misplace onSpinWait call
>>  - Adjust control flow
>>  - Reduce memory stalls
>>  - Merge branch 'openjdk:master' into JDK-8322732
>>  - More performance tradoffs
>>  - Address review comments
>>  - Merge branch 'openjdk:master' into JDK-8322732
>>  - Repack some fields; adjust control flow
>>  - ... and 31 more: https://git.openjdk.org/jdk/compare/ae4752d2...cf5fe55c
>
> src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 1969:
> 
>> 1967:                 else if ((e & SHUTDOWN) == 0)
>> 1968:                     return 0;
>> 1969:                 else if (compareAndSetCtl(c, c) && casRunState(e, e | STOP))
> 
> is the `compareAndSetCtl(c, c)` needed for the read+write fence if ctl == c?

yes.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19131#discussion_r1619209374

From dl at openjdk.org  Wed May 29 18:06:39 2024
From: dl at openjdk.org (Doug Lea)
Date: Wed, 29 May 2024 18:06:39 GMT
Subject: RFR: 8322732: ForkJoinPool may underutilize cores in async mode
 [v9]
In-Reply-To: <xRyDMAsSZ7obqpr3Aoc5qrHqILeJMxFVCeiRdctMI3U=.d5d3cd56-32eb-4431-ac01-081822fc86c6@github.com>
References: <xRyDMAsSZ7obqpr3Aoc5qrHqILeJMxFVCeiRdctMI3U=.d5d3cd56-32eb-4431-ac01-081822fc86c6@github.com>
Message-ID: <pW0mOj77kg3w2GtTSM6UZfhf-NAn0QGPjYiaMI6V6vw=.61a96a06-8807-4c49-b248-58239eee1afd@github.com>

> This set of changes address causes of poor utilization with small numbers of cores due to overly aggressive contention avoidance. A number of further adjustments were needed to still avoid most contention effects in deployments with large numbers of cores

Doug Lea 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 43 additional commits since the last revision:

 - Merge branch 'openjdk:master' into JDK-8322732
 - Address review comments
 - Merge branch 'openjdk:master' into JDK-8322732
 - Add test for utilization with interdependent tasks
 - Un-misplace onSpinWait call
 - Adjust control flow
 - Reduce memory stalls
 - Merge branch 'openjdk:master' into JDK-8322732
 - More performance tradoffs
 - Address review comments
 - ... and 33 more: https://git.openjdk.org/jdk/compare/281b7e15...5e44de45

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19131/files
  - new: https://git.openjdk.org/jdk/pull/19131/files/e5c4a556..5e44de45

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19131&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19131&range=07-08

  Stats: 617 lines in 10 files changed: 419 ins; 182 del; 16 mod
  Patch: https://git.openjdk.org/jdk/pull/19131.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19131/head:pull/19131

PR: https://git.openjdk.org/jdk/pull/19131

From liangchenblue at gmail.com  Wed May 29 18:43:33 2024
From: liangchenblue at gmail.com (Chen Liang)
Date: Wed, 29 May 2024 13:43:33 -0500
Subject: Question on Lambda function
In-Reply-To: <LV8PR08MB955466D6C9CCE80D1F4E48F4F0F22@LV8PR08MB9554.namprd08.prod.outlook.com>
References: <LV8PR08MB955444A8983A6E579694DFC7F0F22@LV8PR08MB9554.namprd08.prod.outlook.com>
 <LV8PR08MB955466D6C9CCE80D1F4E48F4F0F22@LV8PR08MB9554.namprd08.prod.outlook.com>
Message-ID: <CABe8uE3vLVzCH9=nj1wrKSS8nOT-nDJTgRW0M4=2bgrnGxhQog@mail.gmail.com>

Hi Gu,
CallSite is specific to each invokedynamic instruction instead of each
InvokeDynamic constant pool entry:
https://docs.oracle.com/javase/specs/jvms/se22/html/jvms-6.html#jvms-6.5.invokedynamic
And the linking is done by MethodHandleNatives.linkCallSite if you want to
follow the Java implementation code.
For why the lambda in the loop is constant, it's a feature from
InnerClassLambdaMetafactory:
https://github.com/openjdk/jdk/blob/c8eea59f508158075382079316cf0990116ff98e/src/java.base/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java#L236
When the lambda is non-capturing, the bootstrap method
LambdaMetafactory.metafactory will eagerly create a singleton instance and
return this singleton in the indy instruction.

Also, your metaspace pressure might be caused by the fact that Lambda
classes (not instances) are no longer eagerly unloaded; see
https://github.com/openjdk/jdk/pull/12493 and
https://bugs.openjdk.org/browse/JDK-8302154. You are recommended to create
your own facility to create hidden classes in Java 17 instead of continue
to use LambdaMetafactory explicitly in code.

Regards,
Chen Liang

On Wed, May 29, 2024 at 12:53?PM Zhengyu Gu <zhengyu.gu at servicenow.com>
wrote:

> Hello Lambda experts,
>
>
>
> Since we upgraded JDK from 11 to 17, we?re experiencing metaspace
> pressure, largely due to Lambda class implementation changes.
>
>
>
> There?s a scenario (see attached test case),  that is especially puzzled
> me, hopefully, you can share some insights.
>
>
>
> In this test case, there is only one Lambda class is created inside the
> loop, but each one for the same functions outside loop.
>
>
>
> Example output:
>
>
>
> 0: Func =  LambdaFunc$$Lambda/0x00001f80000c4a20 at 4de8b406
>
> testMethod() called
>
> 1: Func =  LambdaFunc$$Lambda/0x00001f80000c4a20 at 4de8b406
>
> testMethod() called
>
> 2: Func =  LambdaFunc$$Lambda/0x00001f80000c4a20 at 4de8b406
>
> testMethod() called
>
> 3: Func =  LambdaFunc$$Lambda/0x00001f80000c4a20 at 4de8b406
>
> testMethod() called
>
> 4: Func =  LambdaFunc$$Lambda/0x00001f80000c4a20 at 4de8b406
>
> testMethod() called
>
>
>
> ?.
>
>
>
> Outside loop1, Func =  LambdaFunc$$Lambda/0x00001f80000c4c58 at 402f32ff
>
> testMethod() called
>
> Outside loop2 Func = LambdaFunc$$Lambda/0x00001f80000d1000 at 5ae9a829
>
> testMethod() called
>
> Outside loop3 Func = LambdaFunc$$Lambda/0x00001f80000d1238 at 548b7f67
>
> testMethod() called
>
>
>
> And jcmd also confirmed there were 4 Lambda classes created:
>
>
>
>   49: CLD 0x000060000134cb50: "app" instance of
> jdk.internal.loader.ClassLoaders$AppClassLoader
>
>       Loaded classes:
>
>          1:    LambdaFunc$$Lambda/0x00001f80000d1238
>
>          2:    LambdaFunc$$Lambda/0x00001f80000d1000
>
>          3:    LambdaFunc$$Lambda/0x00001f80000c4c58
>
>          4:    LambdaFunc$$Lambda/0x00001f80000c4a20
>
>          5:    LambdaFunc
>
>
>
> Looking into bytecode, all four call sites have the same invokedynamic
> bytecode (invokedynamic #7,  0              // InvokeDynamic
> #0:run:()Ljava/lang/Runnable; ) and the first invokedynamic bytecode is
> inside the loop.
>
>
>
> But when I ran the program with -XX:+TraceBytecodes, it seems that the
> first invokedynamic was hoisted and result was used in the subsequence loop.
>
>
>
> Can anyone explain where this magic happens?  If the magic can apply to
> the instances outside the loop, so that only one Lambda class is created?
>
>
>
>
>
> Thank you for your time and expertise,
>
>
>
> -Zhengyu
>
>
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240529/0f1171bf/attachment-0001.htm>

From liach at openjdk.org  Wed May 29 19:27:17 2024
From: liach at openjdk.org (Chen Liang)
Date: Wed, 29 May 2024 19:27:17 GMT
Subject: RFR: 8332614: Type-checked ConstantPool.entryByIndex and
 ClassReader.readEntryOrNull [v6]
In-Reply-To: <UP8XpBov1w74UcUrAkD08x3vQGy_zRQ8NFRXuMU8us4=.3cce8ca0-742b-43f2-a282-894c7f61c969@github.com>
References: <UP8XpBov1w74UcUrAkD08x3vQGy_zRQ8NFRXuMU8us4=.3cce8ca0-742b-43f2-a282-894c7f61c969@github.com>
Message-ID: <cvMjPfM9XcTkHA1D_dHe69_RO8S6ElJGeiMX49dOfTc=.e1a1b003-1ab8-4d9d-a522-1ec5a0d66ce1@github.com>

> I propose to add type-checked ConstantPool.entryByIndex and ClassReader.readEntryOrNull taking an extra Class parameter, which throws ConstantPoolException instead of ClassCastException on type mismatch, which can happen to malformed ClassFiles.
> 
> Requesting a review from @asotona. Thanks!
> 
> Proposal on mailing list: https://mail.openjdk.org/pipermail/classfile-api-dev/2024-May/000512.html

Chen Liang 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:

 - Add test to validate ClassReader behavior
 - Merge branch 'master' of https://github.com/openjdk/jdk into feature/entry-by-type
 - Null-check the entry class eagerly, avoid returning null or throwing IAE
 - Remove redundant import
 - Use switch
 - Merge branch 'master' of https://github.com/openjdk/jdk into feature/entry-by-type
 - Merge branch 'master' of https://github.com/openjdk/jdk into feature/entry-by-type
 - Merge branch 'master' of https://github.com/openjdk/jdk into feature/entry-by-type
 - Use constants, beautify code
 - 8332614: Type-checked ConstantPool.entryByIndex and ClassReader.readEntryOrNull

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19330/files
  - new: https://git.openjdk.org/jdk/pull/19330/files/ec56ce98..e9021f24

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19330&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19330&range=04-05

  Stats: 1876 lines in 41 files changed: 1109 ins; 498 del; 269 mod
  Patch: https://git.openjdk.org/jdk/pull/19330.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19330/head:pull/19330

PR: https://git.openjdk.org/jdk/pull/19330

From naoto at openjdk.org  Wed May 29 20:33:08 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 29 May 2024 20:33:08 GMT
Subject: RFR: 8333103: Re-examine the console provider loading
Message-ID: <M5dxmPs_RJJGqd344t3bMLPMiZmwdtxtbIVP9Bd-ons=.8c7525cc-e3a5-4ed5-81a6-e85398ee6ca6@github.com>

There is an initialization code in `Console` class that searches for the Console implementations. Refactoring the init code not to use lambda/stream would reduce the (initial) number of loaded classes by about 100 for java.base implementations. This would become relevant when the java.io.IO (JEP 477) uses Console as the underlying framework.

-------------

Commit messages:
 - initial commit

Changes: https://git.openjdk.org/jdk/pull/19467/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19467&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8333103
  Stats: 20 lines in 1 file changed: 4 ins; 0 del; 16 mod
  Patch: https://git.openjdk.org/jdk/pull/19467.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19467/head:pull/19467

PR: https://git.openjdk.org/jdk/pull/19467

From zhengyu.gu at servicenow.com  Wed May 29 20:35:41 2024
From: zhengyu.gu at servicenow.com (Zhengyu Gu)
Date: Wed, 29 May 2024 20:35:41 +0000
Subject: Question on Lambda function
In-Reply-To: <CABe8uE3vLVzCH9=nj1wrKSS8nOT-nDJTgRW0M4=2bgrnGxhQog@mail.gmail.com>
References: <LV8PR08MB955444A8983A6E579694DFC7F0F22@LV8PR08MB9554.namprd08.prod.outlook.com>
 <LV8PR08MB955466D6C9CCE80D1F4E48F4F0F22@LV8PR08MB9554.namprd08.prod.outlook.com>
 <CABe8uE3vLVzCH9=nj1wrKSS8nOT-nDJTgRW0M4=2bgrnGxhQog@mail.gmail.com>
Message-ID: <LV8PR08MB95549FE12A28843BB4ED020AF0F22@LV8PR08MB9554.namprd08.prod.outlook.com>

Hi Chen,

Thanks for the insights.

We did refactor our code to avoid using LambdaMetaFactory,metafactory() directly.

With increasing use of Lambdas, in our applications and libraries, the metaspace impact becomes a concern. If current implementation (not able to unload unused Lambda classes) here to stay, we must come up with a coding guideline to avoid excessive creation of Lambda classes,  any pointers or suggestions would be greatly appreciated.

Best,

-Zhengyu

From: Chen Liang <liangchenblue at gmail.com>
Date: Wednesday, May 29, 2024 at 2:43?PM
To: Zhengyu Gu <zhengyu.gu at servicenow.com>
Cc: core-libs-dev at openjdk.org <core-libs-dev at openjdk.org>
Subject: Re: Question on Lambda function
[External Email]

________________________________
Hi Gu,
CallSite is specific to each invokedynamic instruction instead of each InvokeDynamic constant pool entry: https://docs.oracle.com/javase/specs/jvms/se22/html/jvms-6.html#jvms-6.5.invokedynamic<https://docs.oracle.com/javase/specs/jvms/se22/html/jvms-6.html#jvms-6.5.invokedynamic>
And the linking is done by MethodHandleNatives.linkCallSite if you want to follow the Java implementation code.
For why the lambda in the loop is constant, it's a feature from InnerClassLambdaMetafactory: https://github.com/openjdk/jdk/blob/c8eea59f508158075382079316cf0990116ff98e/src/java.base/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java#L236
When the lambda is non-capturing, the bootstrap method LambdaMetafactory.metafactory will eagerly create a singleton instance and return this singleton in the indy instruction.

Also, your metaspace pressure might be caused by the fact that Lambda classes (not instances) are no longer eagerly unloaded; see https://github.com/openjdk/jdk/pull/12493 and https://bugs.openjdk.org/browse/JDK-8302154<https://bugs.openjdk.org/browse/JDK-8302154>. You are recommended to create your own facility to create hidden classes in Java 17 instead of continue to use LambdaMetafactory explicitly in code.

Regards,
Chen Liang

On Wed, May 29, 2024 at 12:53?PM Zhengyu Gu <zhengyu.gu at servicenow.com<mailto:zhengyu.gu at servicenow.com>> wrote:
Hello Lambda experts,

Since we upgraded JDK from 11 to 17, we?re experiencing metaspace pressure, largely due to Lambda class implementation changes.

There?s a scenario (see attached test case),  that is especially puzzled me, hopefully, you can share some insights.

In this test case, there is only one Lambda class is created inside the loop, but each one for the same functions outside loop.

Example output:

0: Func =  LambdaFunc$$Lambda/0x00001f80000c4a20 at 4de8b406
testMethod() called
1: Func =  LambdaFunc$$Lambda/0x00001f80000c4a20 at 4de8b406
testMethod() called
2: Func =  LambdaFunc$$Lambda/0x00001f80000c4a20 at 4de8b406
testMethod() called
3: Func =  LambdaFunc$$Lambda/0x00001f80000c4a20 at 4de8b406
testMethod() called
4: Func =  LambdaFunc$$Lambda/0x00001f80000c4a20 at 4de8b406
testMethod() called

?.

Outside loop1, Func =  LambdaFunc$$Lambda/0x00001f80000c4c58 at 402f32ff
testMethod() called
Outside loop2 Func = LambdaFunc$$Lambda/0x00001f80000d1000 at 5ae9a829
testMethod() called
Outside loop3 Func = LambdaFunc$$Lambda/0x00001f80000d1238 at 548b7f67
testMethod() called

And jcmd also confirmed there were 4 Lambda classes created:

  49: CLD 0x000060000134cb50: "app" instance of jdk.internal.loader.ClassLoaders$AppClassLoader
      Loaded classes:
         1:    LambdaFunc$$Lambda/0x00001f80000d1238
         2:    LambdaFunc$$Lambda/0x00001f80000d1000
         3:    LambdaFunc$$Lambda/0x00001f80000c4c58
         4:    LambdaFunc$$Lambda/0x00001f80000c4a20
         5:    LambdaFunc

Looking into bytecode, all four call sites have the same invokedynamic bytecode (invokedynamic #7,  0              // InvokeDynamic #0:run:()Ljava/lang/Runnable; ) and the first invokedynamic bytecode is inside the loop.

But when I ran the program with -XX:+TraceBytecodes, it seems that the first invokedynamic was hoisted and result was used in the subsequence loop.

Can anyone explain where this magic happens?  If the magic can apply to the instances outside the loop, so that only one Lambda class is created?


Thank you for your time and expertise,

-Zhengyu



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240529/0669b47f/attachment-0001.htm>

From liangchenblue at gmail.com  Wed May 29 21:19:37 2024
From: liangchenblue at gmail.com (Chen Liang)
Date: Wed, 29 May 2024 16:19:37 -0500
Subject: Question on Lambda function
In-Reply-To: <LV8PR08MB95549FE12A28843BB4ED020AF0F22@LV8PR08MB9554.namprd08.prod.outlook.com>
References: <LV8PR08MB955444A8983A6E579694DFC7F0F22@LV8PR08MB9554.namprd08.prod.outlook.com>
 <LV8PR08MB955466D6C9CCE80D1F4E48F4F0F22@LV8PR08MB9554.namprd08.prod.outlook.com>
 <CABe8uE3vLVzCH9=nj1wrKSS8nOT-nDJTgRW0M4=2bgrnGxhQog@mail.gmail.com>
 <LV8PR08MB95549FE12A28843BB4ED020AF0F22@LV8PR08MB9554.namprd08.prod.outlook.com>
Message-ID: <CABe8uE3gfmbeDGb6TVF3Fe=yM4np8OJTWQnEybkn5h7gLBuobw@mail.gmail.com>

Hi Zhengyu,
What is your usage pattern of these single-abstract-method implementations?
Since it sounds like you are creating a lot of them, are you storing them
in collections?
If you are keeping a lot of them in collection (say, as event handlers),
you may try to use `MethodHandleProxies.asInterfaceInstance` as a temporary
workaround on JDK 22 and higher (older version uses Proxy, which has
horrible invocation performance).
If you are on older versions from 15 to 21, unfortunately you might have to
write a hidden class for the same purpose or use an existing library. One
library that might be useful is https://github.com/LanternPowered/Lmbda
that effectively generates unloadable hidden classes, but its 3.x builds
are not maven central so you have to build yourself.

- Chen

On Wed, May 29, 2024 at 3:35?PM Zhengyu Gu <zhengyu.gu at servicenow.com>
wrote:

> Hi Chen,
>
>
>
> Thanks for the insights.
>
>
>
> We did refactor our code to avoid using LambdaMetaFactory,metafactory()
> directly.
>
>
>
> With increasing use of Lambdas, in our applications and libraries, the
> metaspace impact becomes a concern. If current implementation (not able to
> unload unused Lambda classes) here to stay, we must come up with a coding
> guideline to avoid excessive creation of Lambda classes,  any pointers or
> suggestions would be greatly appreciated.
>
>
>
> Best,
>
>
>
> -Zhengyu
>
>
>
> *From: *Chen Liang <liangchenblue at gmail.com>
> *Date: *Wednesday, May 29, 2024 at 2:43?PM
> *To: *Zhengyu Gu <zhengyu.gu at servicenow.com>
> *Cc: *core-libs-dev at openjdk.org <core-libs-dev at openjdk.org>
> *Subject: *Re: Question on Lambda function
> *[External Email]*
>
>
> ------------------------------
>
> Hi Gu,
>
> CallSite is specific to each invokedynamic instruction instead of each
> InvokeDynamic constant pool entry:
> https://docs.oracle.com/javase/specs/jvms/se22/html/jvms-6.html#jvms-6.5.invokedynamic
>
> And the linking is done by MethodHandleNatives.linkCallSite if you want to
> follow the Java implementation code.
>
> For why the lambda in the loop is constant, it's a feature from
> InnerClassLambdaMetafactory:
> https://github.com/openjdk/jdk/blob/c8eea59f508158075382079316cf0990116ff98e/src/java.base/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java#L236
>
> When the lambda is non-capturing, the bootstrap method
> LambdaMetafactory.metafactory will eagerly create a singleton instance and
> return this singleton in the indy instruction.
>
>
>
> Also, your metaspace pressure might be caused by the fact that Lambda
> classes (not instances) are no longer eagerly unloaded; see
> https://github.com/openjdk/jdk/pull/12493 and
> https://bugs.openjdk.org/browse/JDK-8302154. You are recommended to
> create your own facility to create hidden classes in Java 17 instead of
> continue to use LambdaMetafactory explicitly in code.
>
>
>
> Regards,
>
> Chen Liang
>
>
>
> On Wed, May 29, 2024 at 12:53?PM Zhengyu Gu <zhengyu.gu at servicenow.com>
> wrote:
>
> Hello Lambda experts,
>
>
>
> Since we upgraded JDK from 11 to 17, we?re experiencing metaspace
> pressure, largely due to Lambda class implementation changes.
>
>
>
> There?s a scenario (see attached test case),  that is especially puzzled
> me, hopefully, you can share some insights.
>
>
>
> In this test case, there is only one Lambda class is created inside the
> loop, but each one for the same functions outside loop.
>
>
>
> Example output:
>
>
>
> 0: Func =  LambdaFunc$$Lambda/0x00001f80000c4a20 at 4de8b406
>
> testMethod() called
>
> 1: Func =  LambdaFunc$$Lambda/0x00001f80000c4a20 at 4de8b406
>
> testMethod() called
>
> 2: Func =  LambdaFunc$$Lambda/0x00001f80000c4a20 at 4de8b406
>
> testMethod() called
>
> 3: Func =  LambdaFunc$$Lambda/0x00001f80000c4a20 at 4de8b406
>
> testMethod() called
>
> 4: Func =  LambdaFunc$$Lambda/0x00001f80000c4a20 at 4de8b406
>
> testMethod() called
>
>
>
> ?.
>
>
>
> Outside loop1, Func =  LambdaFunc$$Lambda/0x00001f80000c4c58 at 402f32ff
>
> testMethod() called
>
> Outside loop2 Func = LambdaFunc$$Lambda/0x00001f80000d1000 at 5ae9a829
>
> testMethod() called
>
> Outside loop3 Func = LambdaFunc$$Lambda/0x00001f80000d1238 at 548b7f67
>
> testMethod() called
>
>
>
> And jcmd also confirmed there were 4 Lambda classes created:
>
>
>
>   49: CLD 0x000060000134cb50: "app" instance of
> jdk.internal.loader.ClassLoaders$AppClassLoader
>
>       Loaded classes:
>
>          1:    LambdaFunc$$Lambda/0x00001f80000d1238
>
>          2:    LambdaFunc$$Lambda/0x00001f80000d1000
>
>          3:    LambdaFunc$$Lambda/0x00001f80000c4c58
>
>          4:    LambdaFunc$$Lambda/0x00001f80000c4a20
>
>          5:    LambdaFunc
>
>
>
> Looking into bytecode, all four call sites have the same invokedynamic
> bytecode (invokedynamic #7,  0              // InvokeDynamic
> #0:run:()Ljava/lang/Runnable; ) and the first invokedynamic bytecode is
> inside the loop.
>
>
>
> But when I ran the program with -XX:+TraceBytecodes, it seems that the
> first invokedynamic was hoisted and result was used in the subsequence loop.
>
>
>
> Can anyone explain where this magic happens?  If the magic can apply to
> the instances outside the loop, so that only one Lambda class is created?
>
>
>
>
>
> Thank you for your time and expertise,
>
>
>
> -Zhengyu
>
>
>
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240529/7af7fda3/attachment.htm>

From redestad at openjdk.org  Wed May 29 21:24:04 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Wed, 29 May 2024 21:24:04 GMT
Subject: RFR: 8333103: Re-examine the console provider loading
In-Reply-To: <M5dxmPs_RJJGqd344t3bMLPMiZmwdtxtbIVP9Bd-ons=.8c7525cc-e3a5-4ed5-81a6-e85398ee6ca6@github.com>
References: <M5dxmPs_RJJGqd344t3bMLPMiZmwdtxtbIVP9Bd-ons=.8c7525cc-e3a5-4ed5-81a6-e85398ee6ca6@github.com>
Message-ID: <EvSaehfC__i_LzkI1lXRcEbSeGhrjf9ZE_2QWCkp_XI=.0dbe7541-dcdd-4a16-af0f-447218a1e04d@github.com>

On Wed, 29 May 2024 19:51:36 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> There is an initialization code in `Console` class that searches for the Console implementations. Refactoring the init code not to use lambda/stream would reduce the (initial) number of loaded classes by about 100 for java.base implementations. This would become relevant when the java.io.IO (JEP 477) uses Console as the underlying framework.

Marked as reviewed by redestad (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/19467#pullrequestreview-2086537783

From liach at openjdk.org  Wed May 29 21:30:02 2024
From: liach at openjdk.org (Chen Liang)
Date: Wed, 29 May 2024 21:30:02 GMT
Subject: RFR: 8333103: Re-examine the console provider loading
In-Reply-To: <M5dxmPs_RJJGqd344t3bMLPMiZmwdtxtbIVP9Bd-ons=.8c7525cc-e3a5-4ed5-81a6-e85398ee6ca6@github.com>
References: <M5dxmPs_RJJGqd344t3bMLPMiZmwdtxtbIVP9Bd-ons=.8c7525cc-e3a5-4ed5-81a6-e85398ee6ca6@github.com>
Message-ID: <cGedShjEGjk6Su-gyXv_BSvKY8VPf1Rbh5FWpQ1Ea_4=.a0ad9532-91db-4918-bd2e-e15252b2edb9@github.com>

On Wed, 29 May 2024 19:51:36 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> There is an initialization code in `Console` class that searches for the Console implementations. Refactoring the init code not to use lambda/stream would reduce the (initial) number of loaded classes by about 100 for java.base implementations. This would become relevant when the java.io.IO (JEP 477) uses Console as the underlying framework.

src/java.base/share/classes/java/io/Console.java line 673:

> 671:                                 return new ProxyingConsole(jc);
> 672:                             }
> 673:                             break;

Suggestion:


The original `findAny` is only after `filter(Objects::nonNull)` meaning we don't return `null` on a null `jcp.console` result.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19467#discussion_r1619495420

From kvn at openjdk.org  Wed May 29 21:39:14 2024
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Wed, 29 May 2024 21:39:14 GMT
Subject: RFR: 8320448: Accelerate IndexOf using AVX2 [v47]
In-Reply-To: <hfkXncWufSFi3ulNYKQzo3hUs4wfxPOX-GLAT9VF6n8=.1a2b0ca7-92e0-4ea8-a92b-6ee7e82fdd14@github.com>
References: <uWi4QxH31hL93771gkl_GgvP0m84IRSoR_1Yi8hD17E=.bc6ed458-7081-4c3f-9348-f59358fa05a4@github.com>
 <hfkXncWufSFi3ulNYKQzo3hUs4wfxPOX-GLAT9VF6n8=.1a2b0ca7-92e0-4ea8-a92b-6ee7e82fdd14@github.com>
Message-ID: <VtoFl7FZ90WLPPzORT8YBRpQCpgTG4LIRMVlQzvjIa4=.c21536ab-f4ba-43da-8d49-59379f3d1794@github.com>

On Tue, 28 May 2024 23:52:27 GMT, Scott Gibbons <sgibbons at openjdk.org> wrote:

>> Re-write the IndexOf code without the use of the pcmpestri instruction, only using AVX2 instructions.  This change accelerates String.IndexOf on average 1.3x for AVX2.  The benchmark numbers:
>> 
>> 
>> Benchmark	                                               Score		Latest		
>> StringIndexOf.advancedWithMediumSub   343.573		317.934		0.925375393x
>> StringIndexOf.advancedWithShortSub1	  1039.081		1053.96		1.014319384x
>> StringIndexOf.advancedWithShortSub2	      55.828		110.541		1.980027943x
>> StringIndexOf.constantPattern	                9.361		11.906		1.271872663x
>> StringIndexOf.searchCharLongSuccess	        4.216		4.218		1.000474383x
>> StringIndexOf.searchCharMediumSuccess	3.133		3.216		1.02649218x
>> StringIndexOf.searchCharShortSuccess	3.76		        3.761		1.000265957x
>> StringIndexOf.success	                                9.186		9.713		1.057369911x
>> StringIndexOf.successBig	                      14.341		46.343		3.231504079x
>> StringIndexOfChar.latin1_AVX2_String	  6220.918		12154.52		1.953814533x
>> StringIndexOfChar.latin1_AVX2_char	  5503.556		5540.044		1.006629895x
>> StringIndexOfChar.latin1_SSE4_String	  6978.854		6818.689		0.977049957x
>> StringIndexOfChar.latin1_SSE4_char	  5657.499		5474.624		0.967675646x
>> StringIndexOfChar.latin1_Short_String	  7132.541		6863.359		0.962260014x
>> StringIndexOfChar.latin1_Short_char	16013.389	      16162.437		1.009307711x
>> StringIndexOfChar.latin1_mixed_String	  7386.123	      14771.622		1.999915517x
>> StringIndexOfChar.latin1_mixed_char	  9901.671		9782.245		0.987938803
>
> Scott Gibbons has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Move assert to where it's actually important.

Let me test the latest version before integration.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/16753#issuecomment-2138303300

From prappo at openjdk.org  Wed May 29 21:42:05 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Wed, 29 May 2024 21:42:05 GMT
Subject: RFR: 8333103: Re-examine the console provider loading
In-Reply-To: <cGedShjEGjk6Su-gyXv_BSvKY8VPf1Rbh5FWpQ1Ea_4=.a0ad9532-91db-4918-bd2e-e15252b2edb9@github.com>
References: <M5dxmPs_RJJGqd344t3bMLPMiZmwdtxtbIVP9Bd-ons=.8c7525cc-e3a5-4ed5-81a6-e85398ee6ca6@github.com>
 <cGedShjEGjk6Su-gyXv_BSvKY8VPf1Rbh5FWpQ1Ea_4=.a0ad9532-91db-4918-bd2e-e15252b2edb9@github.com>
Message-ID: <kGh8i2IkeuM5wNHC1mybHhqvS8pgpN_O35p-BtMnSxI=.0921c15a-ea95-48b9-9bba-e2993c876d98@github.com>

On Wed, 29 May 2024 21:27:30 GMT, Chen Liang <liach at openjdk.org> wrote:

>> There is an initialization code in `Console` class that searches for the Console implementations. Refactoring the init code not to use lambda/stream would reduce the (initial) number of loaded classes by about 100 for java.base implementations. This would become relevant when the java.io.IO (JEP 477) uses Console as the underlying framework.
>
> src/java.base/share/classes/java/io/Console.java line 673:
> 
>> 671:                                 return new ProxyingConsole(jc);
>> 672:                             }
>> 673:                             break;
> 
> Suggestion:
> 
> 
> The original `findAny` is only after `filter(Objects::nonNull)` meaning we don't return `null` on a null `jcp.console` result.

Yes, `break` guarantees that the search completes one way or another once the module name has been matched. This is not how it used to be done.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19467#discussion_r1619504988

From kvn at openjdk.org  Wed May 29 21:44:17 2024
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Wed, 29 May 2024 21:44:17 GMT
Subject: RFR: 8320448: Accelerate IndexOf using AVX2 [v47]
In-Reply-To: <hfkXncWufSFi3ulNYKQzo3hUs4wfxPOX-GLAT9VF6n8=.1a2b0ca7-92e0-4ea8-a92b-6ee7e82fdd14@github.com>
References: <uWi4QxH31hL93771gkl_GgvP0m84IRSoR_1Yi8hD17E=.bc6ed458-7081-4c3f-9348-f59358fa05a4@github.com>
 <hfkXncWufSFi3ulNYKQzo3hUs4wfxPOX-GLAT9VF6n8=.1a2b0ca7-92e0-4ea8-a92b-6ee7e82fdd14@github.com>
Message-ID: <-jpTM1HhjURGU9BNxceoaF1OlfoVla_Jlnj9BYVCOTQ=.088cff2a-eb4d-43a1-8072-4b688af1d244@github.com>

On Tue, 28 May 2024 23:52:27 GMT, Scott Gibbons <sgibbons at openjdk.org> wrote:

>> Re-write the IndexOf code without the use of the pcmpestri instruction, only using AVX2 instructions.  This change accelerates String.IndexOf on average 1.3x for AVX2.  The benchmark numbers:
>> 
>> 
>> Benchmark	                                               Score		Latest		
>> StringIndexOf.advancedWithMediumSub   343.573		317.934		0.925375393x
>> StringIndexOf.advancedWithShortSub1	  1039.081		1053.96		1.014319384x
>> StringIndexOf.advancedWithShortSub2	      55.828		110.541		1.980027943x
>> StringIndexOf.constantPattern	                9.361		11.906		1.271872663x
>> StringIndexOf.searchCharLongSuccess	        4.216		4.218		1.000474383x
>> StringIndexOf.searchCharMediumSuccess	3.133		3.216		1.02649218x
>> StringIndexOf.searchCharShortSuccess	3.76		        3.761		1.000265957x
>> StringIndexOf.success	                                9.186		9.713		1.057369911x
>> StringIndexOf.successBig	                      14.341		46.343		3.231504079x
>> StringIndexOfChar.latin1_AVX2_String	  6220.918		12154.52		1.953814533x
>> StringIndexOfChar.latin1_AVX2_char	  5503.556		5540.044		1.006629895x
>> StringIndexOfChar.latin1_SSE4_String	  6978.854		6818.689		0.977049957x
>> StringIndexOfChar.latin1_SSE4_char	  5657.499		5474.624		0.967675646x
>> StringIndexOfChar.latin1_Short_String	  7132.541		6863.359		0.962260014x
>> StringIndexOfChar.latin1_Short_char	16013.389	      16162.437		1.009307711x
>> StringIndexOfChar.latin1_mixed_String	  7386.123	      14771.622		1.999915517x
>> StringIndexOfChar.latin1_mixed_char	  9901.671		9782.245		0.987938803
>
> Scott Gibbons has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Move assert to where it's actually important.

test/jdk/TEST.ROOT line 103:

> 101:     vm.jvmti \
> 102:     vm.cpu.features \
> 103:     vm.compiler2.enabled \

`vm.compiler2.enabled ` already listed at line 91

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1619506711

From sgibbons at openjdk.org  Wed May 29 22:20:31 2024
From: sgibbons at openjdk.org (Scott Gibbons)
Date: Wed, 29 May 2024 22:20:31 GMT
Subject: RFR: 8320448: Accelerate IndexOf using AVX2 [v48]
In-Reply-To: <uWi4QxH31hL93771gkl_GgvP0m84IRSoR_1Yi8hD17E=.bc6ed458-7081-4c3f-9348-f59358fa05a4@github.com>
References: <uWi4QxH31hL93771gkl_GgvP0m84IRSoR_1Yi8hD17E=.bc6ed458-7081-4c3f-9348-f59358fa05a4@github.com>
Message-ID: <jJHpKyrD7KBeyP2gEh_CfKKNv2YM8hLccPuG6N9S1JU=.77539396-e5ac-4334-8f2c-a9a1ed5bc478@github.com>

> Re-write the IndexOf code without the use of the pcmpestri instruction, only using AVX2 instructions.  This change accelerates String.IndexOf on average 1.3x for AVX2.  The benchmark numbers:
> 
> 
> Benchmark	                                               Score		Latest		
> StringIndexOf.advancedWithMediumSub   343.573		317.934		0.925375393x
> StringIndexOf.advancedWithShortSub1	  1039.081		1053.96		1.014319384x
> StringIndexOf.advancedWithShortSub2	      55.828		110.541		1.980027943x
> StringIndexOf.constantPattern	                9.361		11.906		1.271872663x
> StringIndexOf.searchCharLongSuccess	        4.216		4.218		1.000474383x
> StringIndexOf.searchCharMediumSuccess	3.133		3.216		1.02649218x
> StringIndexOf.searchCharShortSuccess	3.76		        3.761		1.000265957x
> StringIndexOf.success	                                9.186		9.713		1.057369911x
> StringIndexOf.successBig	                      14.341		46.343		3.231504079x
> StringIndexOfChar.latin1_AVX2_String	  6220.918		12154.52		1.953814533x
> StringIndexOfChar.latin1_AVX2_char	  5503.556		5540.044		1.006629895x
> StringIndexOfChar.latin1_SSE4_String	  6978.854		6818.689		0.977049957x
> StringIndexOfChar.latin1_SSE4_char	  5657.499		5474.624		0.967675646x
> StringIndexOfChar.latin1_Short_String	  7132.541		6863.359		0.962260014x
> StringIndexOfChar.latin1_Short_char	16013.389	      16162.437		1.009307711x
> StringIndexOfChar.latin1_mixed_String	  7386.123	      14771.622		1.999915517x
> StringIndexOfChar.latin1_mixed_char	  9901.671		9782.245		0.987938803

Scott Gibbons has updated the pull request incrementally with one additional commit since the last revision:

  Remove duplicate vm.compiler2.enabled

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/16753/files
  - new: https://git.openjdk.org/jdk/pull/16753/files/db0ab75a..ed06edd6

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16753&range=47
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16753&range=46-47

  Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/16753.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16753/head:pull/16753

PR: https://git.openjdk.org/jdk/pull/16753

From sgibbons at openjdk.org  Wed May 29 22:20:31 2024
From: sgibbons at openjdk.org (Scott Gibbons)
Date: Wed, 29 May 2024 22:20:31 GMT
Subject: RFR: 8320448: Accelerate IndexOf using AVX2 [v47]
In-Reply-To: <-jpTM1HhjURGU9BNxceoaF1OlfoVla_Jlnj9BYVCOTQ=.088cff2a-eb4d-43a1-8072-4b688af1d244@github.com>
References: <uWi4QxH31hL93771gkl_GgvP0m84IRSoR_1Yi8hD17E=.bc6ed458-7081-4c3f-9348-f59358fa05a4@github.com>
 <hfkXncWufSFi3ulNYKQzo3hUs4wfxPOX-GLAT9VF6n8=.1a2b0ca7-92e0-4ea8-a92b-6ee7e82fdd14@github.com>
 <-jpTM1HhjURGU9BNxceoaF1OlfoVla_Jlnj9BYVCOTQ=.088cff2a-eb4d-43a1-8072-4b688af1d244@github.com>
Message-ID: <NvF_lv23W87V2ewvPzHjMoO6m7gtqgbmHFjDRvn992I=.aaf6b4e0-718f-4fa7-a302-0b48bde38eac@github.com>

On Wed, 29 May 2024 21:41:42 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> Scott Gibbons has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Move assert to where it's actually important.
>
> test/jdk/TEST.ROOT line 103:
> 
>> 101:     vm.jvmti \
>> 102:     vm.cpu.features \
>> 103:     vm.compiler2.enabled \
> 
> `vm.compiler2.enabled ` already listed at line 91

Thanks!  Removed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1619532884

From naoto at openjdk.org  Wed May 29 22:28:03 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 29 May 2024 22:28:03 GMT
Subject: RFR: 8333103: Re-examine the console provider loading
In-Reply-To: <kGh8i2IkeuM5wNHC1mybHhqvS8pgpN_O35p-BtMnSxI=.0921c15a-ea95-48b9-9bba-e2993c876d98@github.com>
References: <M5dxmPs_RJJGqd344t3bMLPMiZmwdtxtbIVP9Bd-ons=.8c7525cc-e3a5-4ed5-81a6-e85398ee6ca6@github.com>
 <cGedShjEGjk6Su-gyXv_BSvKY8VPf1Rbh5FWpQ1Ea_4=.a0ad9532-91db-4918-bd2e-e15252b2edb9@github.com>
 <kGh8i2IkeuM5wNHC1mybHhqvS8pgpN_O35p-BtMnSxI=.0921c15a-ea95-48b9-9bba-e2993c876d98@github.com>
Message-ID: <vSJN2UO7GQgMyRZ_4Fytuioz3nImPHPYUWU6dsmacws=.d9210a00-4a14-4f22-8d68-db7d87f3af15@github.com>

On Wed, 29 May 2024 21:39:37 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> src/java.base/share/classes/java/io/Console.java line 673:
>> 
>>> 671:                                 return new ProxyingConsole(jc);
>>> 672:                             }
>>> 673:                             break;
>> 
>> Suggestion:
>> 
>> 
>> The original `findAny` is only after `filter(Objects::nonNull)` meaning we don't return `null` on a null `jcp.console` result.
>
> Yes, `break` guarantees that the search completes one way or another once the module name has been matched. This is not how it used to be done.

Right. Since `findAny` is after the module name matching, there is at most 1 match. In the case we didn't find any, the final `orElse(null)` eventually returns null. So the refactored code is semantically the same.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19467#discussion_r1619537359

From dl at openjdk.org  Wed May 29 23:24:15 2024
From: dl at openjdk.org (Doug Lea)
Date: Wed, 29 May 2024 23:24:15 GMT
Subject: RFR: 8322732: ForkJoinPool may underutilize cores in async mode
 [v10]
In-Reply-To: <xRyDMAsSZ7obqpr3Aoc5qrHqILeJMxFVCeiRdctMI3U=.d5d3cd56-32eb-4431-ac01-081822fc86c6@github.com>
References: <xRyDMAsSZ7obqpr3Aoc5qrHqILeJMxFVCeiRdctMI3U=.d5d3cd56-32eb-4431-ac01-081822fc86c6@github.com>
Message-ID: <i9_wI9T_IFnoB6JpskFhRdfv9Ogh1P3oYw-aFkHnONM=.80965932-f746-46b0-abc0-ed792a27f1f9@github.com>

> This set of changes address causes of poor utilization with small numbers of cores due to overly aggressive contention avoidance. A number of further adjustments were needed to still avoid most contention effects in deployments with large numbers of cores

Doug Lea has updated the pull request incrementally with one additional commit since the last revision:

  unguard signal

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19131/files
  - new: https://git.openjdk.org/jdk/pull/19131/files/5e44de45..4564b92c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19131&range=09
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19131&range=08-09

  Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/19131.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19131/head:pull/19131

PR: https://git.openjdk.org/jdk/pull/19131

From zhengyu.gu at servicenow.com  Thu May 30 00:28:36 2024
From: zhengyu.gu at servicenow.com (Zhengyu Gu)
Date: Thu, 30 May 2024 00:28:36 +0000
Subject: Question on Lambda function
In-Reply-To: <CABe8uE3gfmbeDGb6TVF3Fe=yM4np8OJTWQnEybkn5h7gLBuobw@mail.gmail.com>
References: <LV8PR08MB955444A8983A6E579694DFC7F0F22@LV8PR08MB9554.namprd08.prod.outlook.com>
 <LV8PR08MB955466D6C9CCE80D1F4E48F4F0F22@LV8PR08MB9554.namprd08.prod.outlook.com>
 <CABe8uE3vLVzCH9=nj1wrKSS8nOT-nDJTgRW0M4=2bgrnGxhQog@mail.gmail.com>
 <LV8PR08MB95549FE12A28843BB4ED020AF0F22@LV8PR08MB9554.namprd08.prod.outlook.com>
 <CABe8uE3gfmbeDGb6TVF3Fe=yM4np8OJTWQnEybkn5h7gLBuobw@mail.gmail.com>
Message-ID: <LV8PR08MB955417E4E6ED6C9CBF7ACB3DF0F32@LV8PR08MB9554.namprd08.prod.outlook.com>

Hi Chen,

What is your usage pattern of these single-abstract-method implementations? Since it sounds like you are
creating a lot of them, are you storing them in collections?

Yes, we do have such usage patterns, e.g. stores methods as Function in hash table as handlers, etc.


If you are keeping a lot of them in collection (say, as event handlers), you may try to use `MethodHandleProxies.asInterfaceInstance` as a temporary workaround on JDK 22 and higher (older version uses Proxy, which has horrible invocation performance).

Thanks for the suggestion. We are currently at 17, I will investigate the library.


Best,

-Zhengyu


If you are on older versions from 15 to 21, unfortunately you might have to write a hidden class for the same purpose or use an existing library. One library that might be useful is https://github.com/LanternPowered/Lmbda that effectively generates unloadable hidden classes, but its 3.x builds are not maven central so you have to build yourself.

- Chen

On Wed, May 29, 2024 at 3:35?PM Zhengyu Gu <zhengyu.gu at servicenow.com<mailto:zhengyu.gu at servicenow.com>> wrote:
Hi Chen,

Thanks for the insights.

We did refactor our code to avoid using LambdaMetaFactory,metafactory() directly.

With increasing use of Lambdas, in our applications and libraries, the metaspace impact becomes a concern. If current implementation (not able to unload unused Lambda classes) here to stay, we must come up with a coding guideline to avoid excessive creation of Lambda classes,  any pointers or suggestions would be greatly appreciated.

Best,

-Zhengyu

From: Chen Liang <liangchenblue at gmail.com<mailto:liangchenblue at gmail.com>>
Date: Wednesday, May 29, 2024 at 2:43?PM
To: Zhengyu Gu <zhengyu.gu at servicenow.com<mailto:zhengyu.gu at servicenow.com>>
Cc: core-libs-dev at openjdk.org<mailto:core-libs-dev at openjdk.org> <core-libs-dev at openjdk.org<mailto:core-libs-dev at openjdk.org>>
Subject: Re: Question on Lambda function
[External Email]

________________________________
Hi Gu,
CallSite is specific to each invokedynamic instruction instead of each InvokeDynamic constant pool entry: https://docs.oracle.com/javase/specs/jvms/se22/html/jvms-6.html#jvms-6.5.invokedynamic<https://docs.oracle.com/javase/specs/jvms/se22/html/jvms-6.html#jvms-6.5.invokedynamic>
And the linking is done by MethodHandleNatives.linkCallSite if you want to follow the Java implementation code.
For why the lambda in the loop is constant, it's a feature from InnerClassLambdaMetafactory: https://github.com/openjdk/jdk/blob/c8eea59f508158075382079316cf0990116ff98e/src/java.base/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java#L236
When the lambda is non-capturing, the bootstrap method LambdaMetafactory.metafactory will eagerly create a singleton instance and return this singleton in the indy instruction.

Also, your metaspace pressure might be caused by the fact that Lambda classes (not instances) are no longer eagerly unloaded; see https://github.com/openjdk/jdk/pull/12493 and https://bugs.openjdk.org/browse/JDK-8302154<https://bugs.openjdk.org/browse/JDK-8302154>. You are recommended to create your own facility to create hidden classes in Java 17 instead of continue to use LambdaMetafactory explicitly in code.

Regards,
Chen Liang

On Wed, May 29, 2024 at 12:53?PM Zhengyu Gu <zhengyu.gu at servicenow.com<mailto:zhengyu.gu at servicenow.com>> wrote:
Hello Lambda experts,

Since we upgraded JDK from 11 to 17, we?re experiencing metaspace pressure, largely due to Lambda class implementation changes.

There?s a scenario (see attached test case),  that is especially puzzled me, hopefully, you can share some insights.

In this test case, there is only one Lambda class is created inside the loop, but each one for the same functions outside loop.

Example output:

0: Func =  LambdaFunc$$Lambda/0x00001f80000c4a20 at 4de8b406
testMethod() called
1: Func =  LambdaFunc$$Lambda/0x00001f80000c4a20 at 4de8b406
testMethod() called
2: Func =  LambdaFunc$$Lambda/0x00001f80000c4a20 at 4de8b406
testMethod() called
3: Func =  LambdaFunc$$Lambda/0x00001f80000c4a20 at 4de8b406
testMethod() called
4: Func =  LambdaFunc$$Lambda/0x00001f80000c4a20 at 4de8b406
testMethod() called

?.

Outside loop1, Func =  LambdaFunc$$Lambda/0x00001f80000c4c58 at 402f32ff
testMethod() called
Outside loop2 Func = LambdaFunc$$Lambda/0x00001f80000d1000 at 5ae9a829
testMethod() called
Outside loop3 Func = LambdaFunc$$Lambda/0x00001f80000d1238 at 548b7f67
testMethod() called

And jcmd also confirmed there were 4 Lambda classes created:

  49: CLD 0x000060000134cb50: "app" instance of jdk.internal.loader.ClassLoaders$AppClassLoader
      Loaded classes:
         1:    LambdaFunc$$Lambda/0x00001f80000d1238
         2:    LambdaFunc$$Lambda/0x00001f80000d1000
         3:    LambdaFunc$$Lambda/0x00001f80000c4c58
         4:    LambdaFunc$$Lambda/0x00001f80000c4a20
         5:    LambdaFunc

Looking into bytecode, all four call sites have the same invokedynamic bytecode (invokedynamic #7,  0              // InvokeDynamic #0:run:()Ljava/lang/Runnable; ) and the first invokedynamic bytecode is inside the loop.

But when I ran the program with -XX:+TraceBytecodes, it seems that the first invokedynamic was hoisted and result was used in the subsequence loop.

Can anyone explain where this magic happens?  If the magic can apply to the instances outside the loop, so that only one Lambda class is created?


Thank you for your time and expertise,

-Zhengyu



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240530/6c5103ec/attachment-0001.htm>

From kvn at openjdk.org  Thu May 30 02:21:13 2024
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Thu, 30 May 2024 02:21:13 GMT
Subject: RFR: 8320448: Accelerate IndexOf using AVX2 [v48]
In-Reply-To: <jJHpKyrD7KBeyP2gEh_CfKKNv2YM8hLccPuG6N9S1JU=.77539396-e5ac-4334-8f2c-a9a1ed5bc478@github.com>
References: <uWi4QxH31hL93771gkl_GgvP0m84IRSoR_1Yi8hD17E=.bc6ed458-7081-4c3f-9348-f59358fa05a4@github.com>
 <jJHpKyrD7KBeyP2gEh_CfKKNv2YM8hLccPuG6N9S1JU=.77539396-e5ac-4334-8f2c-a9a1ed5bc478@github.com>
Message-ID: <pDDNHq2jkXkgnRvxILazdQWvjZtko_8JKZ3-GHyYSas=.0e2cd59c-1010-461c-a2e1-5a73b6a9843e@github.com>

On Wed, 29 May 2024 22:20:31 GMT, Scott Gibbons <sgibbons at openjdk.org> wrote:

>> Re-write the IndexOf code without the use of the pcmpestri instruction, only using AVX2 instructions.  This change accelerates String.IndexOf on average 1.3x for AVX2.  The benchmark numbers:
>> 
>> 
>> Benchmark	                                               Score		Latest		
>> StringIndexOf.advancedWithMediumSub   343.573		317.934		0.925375393x
>> StringIndexOf.advancedWithShortSub1	  1039.081		1053.96		1.014319384x
>> StringIndexOf.advancedWithShortSub2	      55.828		110.541		1.980027943x
>> StringIndexOf.constantPattern	                9.361		11.906		1.271872663x
>> StringIndexOf.searchCharLongSuccess	        4.216		4.218		1.000474383x
>> StringIndexOf.searchCharMediumSuccess	3.133		3.216		1.02649218x
>> StringIndexOf.searchCharShortSuccess	3.76		        3.761		1.000265957x
>> StringIndexOf.success	                                9.186		9.713		1.057369911x
>> StringIndexOf.successBig	                      14.341		46.343		3.231504079x
>> StringIndexOfChar.latin1_AVX2_String	  6220.918		12154.52		1.953814533x
>> StringIndexOfChar.latin1_AVX2_char	  5503.556		5540.044		1.006629895x
>> StringIndexOfChar.latin1_SSE4_String	  6978.854		6818.689		0.977049957x
>> StringIndexOfChar.latin1_SSE4_char	  5657.499		5474.624		0.967675646x
>> StringIndexOfChar.latin1_Short_String	  7132.541		6863.359		0.962260014x
>> StringIndexOfChar.latin1_Short_char	16013.389	      16162.437		1.009307711x
>> StringIndexOfChar.latin1_mixed_String	  7386.123	      14771.622		1.999915517x
>> StringIndexOfChar.latin1_mixed_char	  9901.671		9782.245		0.987938803
>
> Scott Gibbons has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove duplicate vm.compiler2.enabled

My testing passed.

-------------

Marked as reviewed by kvn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/16753#pullrequestreview-2086978326

From lmesnik at openjdk.org  Thu May 30 02:34:28 2024
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Thu, 30 May 2024 02:34:28 GMT
Subject: RFR: 8330702: Update failure handler to don't generate Error message
 if cores actions are empty.
Message-ID: <rDvdKl90aCp8AXBSFjWULjZxRwVYjnIH65s8CPBCL_M=.65ca8ddb-17e2-4e4e-9911-3dd176d6a9e7@github.com>

The message is generated if cores (or any other tools) section doesn't exist or is empty. However, there is no any tool for cores processing now defined. So ERROR message is generating, confusing users.
The fix is to don't print error for empty toolset which is the valid case. The message is still generate is tool is not defined to get error message in the case of miswriting.

-------------

Commit messages:
 - 8330702

Changes: https://git.openjdk.org/jdk/pull/19470/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19470&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8330702
  Stats: 9 lines in 2 files changed: 5 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/19470.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19470/head:pull/19470

PR: https://git.openjdk.org/jdk/pull/19470

From jpai at openjdk.org  Thu May 30 03:53:00 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 30 May 2024 03:53:00 GMT
Subject: RFR: 8333103: Re-examine the console provider loading
In-Reply-To: <M5dxmPs_RJJGqd344t3bMLPMiZmwdtxtbIVP9Bd-ons=.8c7525cc-e3a5-4ed5-81a6-e85398ee6ca6@github.com>
References: <M5dxmPs_RJJGqd344t3bMLPMiZmwdtxtbIVP9Bd-ons=.8c7525cc-e3a5-4ed5-81a6-e85398ee6ca6@github.com>
Message-ID: <Pvw_a7NfXyA5aBJOJDx1rIXDTZHn59ohDc4dFe7zjKo=.6adb449e-6a9d-4724-984a-9e28e2d19d04@github.com>

On Wed, 29 May 2024 19:51:36 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> There is an initialization code in `Console` class that searches for the Console implementations. Refactoring the init code not to use lambda/stream would reduce the (initial) number of loaded classes by about 100 for java.base implementations. This would become relevant when the java.io.IO (JEP 477) uses Console as the underlying framework.

The change to replace lambda with anonymous class looks OK to me.

-------------

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19467#pullrequestreview-2087164330

From darcy at openjdk.org  Thu May 30 05:19:11 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Thu, 30 May 2024 05:19:11 GMT
Subject: RFR: 8314480: Memory ordering spec updates in java.lang.ref [v32]
In-Reply-To: <B0N9o2KSYGCNvvsmnpJ3dqFoRHAR2TaVHrpOpH4WWG4=.27a02e0c-1cf1-4912-860d-3263581d7237@github.com>
References: <R74ontYwjYg6HeZY0cWrlo0amjl4E1YsFWeuh4pda14=.08ac62df-b2f8-4b4d-b338-07adb289601b@github.com>
 <B0N9o2KSYGCNvvsmnpJ3dqFoRHAR2TaVHrpOpH4WWG4=.27a02e0c-1cf1-4912-860d-3263581d7237@github.com>
Message-ID: <uMV_TS2cChxa1ajeMsUFxhLzcxIw1mXCEfiUZ4nZIok=.596fe594-23a8-46a8-b8bb-0fc66c76f261@github.com>

On Fri, 24 May 2024 21:39:33 GMT, Brent Christian <bchristi at openjdk.org> wrote:

>> Classes in the `java.lang.ref` package would benefit from an update to bring the spec in line with how the VM already behaves. The changes would focus on _happens-before_ edges at some key points during reference processing.
>> 
>> A couple key things we want to be able to say are:
>> - `Reference.reachabilityFence(x)` _happens-before_ reference processing occurs for 'x'.
>> - `Cleaner.register()` _happens-before_ the Cleaner thread runs the registered cleaning action.
>> 
>> This will bring Cleaner in line (or close) with the memory visibility guarantees made for finalizers in [JLS 17.4.5](https://docs.oracle.com/javase/specs/jls/se18/html/jls-17.html#jls-17.4.5):
>> _"There is a happens-before edge from the end of a constructor of an object to the start of a finalizer (?12.6) for that object."_
>
> Brent Christian has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 69 commits:
> 
>  - Merge branch 'master' into refDocs2
>  - add link to Thread.isAlive()
>  - small review tweaks; shorten MemoryConsistency links
>  - small grammar fixes
>  - new section for finalizer memviz
>  - add memviz bullet for finalization
>  - remove quotes from dequeue
>  - package spec updates, mostly about reference queues and dequeueing
>  - move reachability section before notification; update section header
>  - add details on use of reference queues; swap reachability/memviz sections
>  - ... and 59 more: https://git.openjdk.org/jdk/compare/7bf1989f...d7cbf0d3

src/java.base/share/classes/java/lang/ref/Reference.java line 491:

> 489:      * method is <b><i>unsuccessful</i></b> and returns false.
> 490:      *
> 491:      * <p><a href="package-summary.html#MemoryConsistency">Memory consistency effects</a>:

Note the `<a href="package-summary.thml#Foo>` syntax can be replaced with something like
`{@link java.lang.ref##Foo}`.

src/java.base/share/classes/java/lang/ref/Reference.java line 548:

> 546:      * This reachability is assured regardless of any optimizing transformations
> 547:      * the virtual machine may perform that might otherwise allow the object to
> 548:      * become unreachable (see {@jls 12.6.1}). Thus, the given object is not

I recommend replacing `(see {@jls 12.6.1})` with something like ` (see JLS {@jls 12.6.1})`, an idiom used elsewhere in core libs in formatting links into the JLS.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16644#discussion_r1619921063
PR Review Comment: https://git.openjdk.org/jdk/pull/16644#discussion_r1619923554

From darcy at openjdk.org  Thu May 30 05:27:19 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Thu, 30 May 2024 05:27:19 GMT
Subject: RFR: 8314480: Memory ordering spec updates in java.lang.ref [v32]
In-Reply-To: <B0N9o2KSYGCNvvsmnpJ3dqFoRHAR2TaVHrpOpH4WWG4=.27a02e0c-1cf1-4912-860d-3263581d7237@github.com>
References: <R74ontYwjYg6HeZY0cWrlo0amjl4E1YsFWeuh4pda14=.08ac62df-b2f8-4b4d-b338-07adb289601b@github.com>
 <B0N9o2KSYGCNvvsmnpJ3dqFoRHAR2TaVHrpOpH4WWG4=.27a02e0c-1cf1-4912-860d-3263581d7237@github.com>
Message-ID: <m_4qKmO1RqcGIMjj1hNLa--nZ_GCnY65RWHubQ_ZnlM=.658594a7-86c3-4e19-b033-47874853ce48@github.com>

On Fri, 24 May 2024 21:39:33 GMT, Brent Christian <bchristi at openjdk.org> wrote:

>> Classes in the `java.lang.ref` package would benefit from an update to bring the spec in line with how the VM already behaves. The changes would focus on _happens-before_ edges at some key points during reference processing.
>> 
>> A couple key things we want to be able to say are:
>> - `Reference.reachabilityFence(x)` _happens-before_ reference processing occurs for 'x'.
>> - `Cleaner.register()` _happens-before_ the Cleaner thread runs the registered cleaning action.
>> 
>> This will bring Cleaner in line (or close) with the memory visibility guarantees made for finalizers in [JLS 17.4.5](https://docs.oracle.com/javase/specs/jls/se18/html/jls-17.html#jls-17.4.5):
>> _"There is a happens-before edge from the end of a constructor of an object to the start of a finalizer (?12.6) for that object."_
>
> Brent Christian has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 69 commits:
> 
>  - Merge branch 'master' into refDocs2
>  - add link to Thread.isAlive()
>  - small review tweaks; shorten MemoryConsistency links
>  - small grammar fixes
>  - new section for finalizer memviz
>  - add memviz bullet for finalization
>  - remove quotes from dequeue
>  - package spec updates, mostly about reference queues and dequeueing
>  - move reachability section before notification; update section header
>  - add details on use of reference queues; swap reachability/memviz sections
>  - ... and 59 more: https://git.openjdk.org/jdk/compare/7bf1989f...d7cbf0d3

src/java.base/share/classes/java/lang/ref/Reference.java line 556:

> 554:      *   int myIndex;
> 555:      *   Resource(...) {
> 556:      *     myIndex = ...

Convert this code sample to a snippet?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16644#discussion_r1619935008

From asotona at openjdk.org  Thu May 30 06:16:06 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Thu, 30 May 2024 06:16:06 GMT
Subject: Integrated: 8332597: Remove redundant methods from
 j.l.classfile.ClassReader API
In-Reply-To: <UWBl0HMJIC4_22TkWuBhE9kd2F_l0eiPmpIx8rexFlU=.4f905822-ed5e-41be-b9d4-601af6a55eed@github.com>
References: <UWBl0HMJIC4_22TkWuBhE9kd2F_l0eiPmpIx8rexFlU=.4f905822-ed5e-41be-b9d4-601af6a55eed@github.com>
Message-ID: <-4kwybbhhoOxN16a7ejFH2AVDYtkmK33haPHsCTLiys=.23cb9142-536f-4791-b815-d8a8749b9db6@github.com>

On Tue, 21 May 2024 09:20:36 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> j.l.classfile.ClassReader instance is exposed in the Class-File API through j.l.classfile.AttributeMapper::readAttribute method only.
> ClassReader only purpose is to serve as a tool for reading content of a custom attribute in a user-provided AttribtueMapper.
> It contains useful set of low-level class reading methods for user to implement a custom attribute content parser.
> 
> However methods ClassReader::thisClassPos and ClassReader::skipAttributeHolder are not necessary for a custom attribute content parsing and so redundant in the API.
> Class-File API implementation internally use these methods, however they should not be exposed in the API.
> 
> This patch removes the methods from the API.
> 
> Please review.
> 
> Thanks,
> Adam

This pull request has now been integrated.

Changeset: 579cf705
Author:    Adam Sotona <asotona at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/579cf705ff74d1ebb56b605d9a7ca17d87c36d84
Stats:     23 lines in 5 files changed: 0 ins; 17 del; 6 mod

8332597: Remove redundant methods from j.l.classfile.ClassReader API

Reviewed-by: liach, jlahoda

-------------

PR: https://git.openjdk.org/jdk/pull/19323

From thartmann at openjdk.org  Thu May 30 06:28:20 2024
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Thu, 30 May 2024 06:28:20 GMT
Subject: RFR: 8320448: Accelerate IndexOf using AVX2 [v48]
In-Reply-To: <jJHpKyrD7KBeyP2gEh_CfKKNv2YM8hLccPuG6N9S1JU=.77539396-e5ac-4334-8f2c-a9a1ed5bc478@github.com>
References: <uWi4QxH31hL93771gkl_GgvP0m84IRSoR_1Yi8hD17E=.bc6ed458-7081-4c3f-9348-f59358fa05a4@github.com>
 <jJHpKyrD7KBeyP2gEh_CfKKNv2YM8hLccPuG6N9S1JU=.77539396-e5ac-4334-8f2c-a9a1ed5bc478@github.com>
Message-ID: <bF4gn-6TzP7hCsTzUuaJrsEGaX-5aqbimI30E2b3Du8=.999e585e-0bee-459a-b78f-8ed6668cb32b@github.com>

On Wed, 29 May 2024 22:20:31 GMT, Scott Gibbons <sgibbons at openjdk.org> wrote:

>> Re-write the IndexOf code without the use of the pcmpestri instruction, only using AVX2 instructions.  This change accelerates String.IndexOf on average 1.3x for AVX2.  The benchmark numbers:
>> 
>> 
>> Benchmark	                                               Score		Latest		
>> StringIndexOf.advancedWithMediumSub   343.573		317.934		0.925375393x
>> StringIndexOf.advancedWithShortSub1	  1039.081		1053.96		1.014319384x
>> StringIndexOf.advancedWithShortSub2	      55.828		110.541		1.980027943x
>> StringIndexOf.constantPattern	                9.361		11.906		1.271872663x
>> StringIndexOf.searchCharLongSuccess	        4.216		4.218		1.000474383x
>> StringIndexOf.searchCharMediumSuccess	3.133		3.216		1.02649218x
>> StringIndexOf.searchCharShortSuccess	3.76		        3.761		1.000265957x
>> StringIndexOf.success	                                9.186		9.713		1.057369911x
>> StringIndexOf.successBig	                      14.341		46.343		3.231504079x
>> StringIndexOfChar.latin1_AVX2_String	  6220.918		12154.52		1.953814533x
>> StringIndexOfChar.latin1_AVX2_char	  5503.556		5540.044		1.006629895x
>> StringIndexOfChar.latin1_SSE4_String	  6978.854		6818.689		0.977049957x
>> StringIndexOfChar.latin1_SSE4_char	  5657.499		5474.624		0.967675646x
>> StringIndexOfChar.latin1_Short_String	  7132.541		6863.359		0.962260014x
>> StringIndexOfChar.latin1_Short_char	16013.389	      16162.437		1.009307711x
>> StringIndexOfChar.latin1_mixed_String	  7386.123	      14771.622		1.999915517x
>> StringIndexOfChar.latin1_mixed_char	  9901.671		9782.245		0.987938803
>
> Scott Gibbons has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove duplicate vm.compiler2.enabled

Control question: Are we confident with this potentially going into JDK 23 or should we rather postpone to JDK 24? The fork is next week.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/16753#issuecomment-2138771509

From epeter at openjdk.org  Thu May 30 06:28:21 2024
From: epeter at openjdk.org (Emanuel Peter)
Date: Thu, 30 May 2024 06:28:21 GMT
Subject: RFR: 8320448: Accelerate IndexOf using AVX2 [v48]
In-Reply-To: <jJHpKyrD7KBeyP2gEh_CfKKNv2YM8hLccPuG6N9S1JU=.77539396-e5ac-4334-8f2c-a9a1ed5bc478@github.com>
References: <uWi4QxH31hL93771gkl_GgvP0m84IRSoR_1Yi8hD17E=.bc6ed458-7081-4c3f-9348-f59358fa05a4@github.com>
 <jJHpKyrD7KBeyP2gEh_CfKKNv2YM8hLccPuG6N9S1JU=.77539396-e5ac-4334-8f2c-a9a1ed5bc478@github.com>
Message-ID: <dp-Dou__skj5A-nyS74949VYGO15gA6SKiCfXC1D6SQ=.3c118c11-0c9c-49d1-a514-d4ffe756f01c@github.com>

On Wed, 29 May 2024 22:20:31 GMT, Scott Gibbons <sgibbons at openjdk.org> wrote:

>> Re-write the IndexOf code without the use of the pcmpestri instruction, only using AVX2 instructions.  This change accelerates String.IndexOf on average 1.3x for AVX2.  The benchmark numbers:
>> 
>> 
>> Benchmark	                                               Score		Latest		
>> StringIndexOf.advancedWithMediumSub   343.573		317.934		0.925375393x
>> StringIndexOf.advancedWithShortSub1	  1039.081		1053.96		1.014319384x
>> StringIndexOf.advancedWithShortSub2	      55.828		110.541		1.980027943x
>> StringIndexOf.constantPattern	                9.361		11.906		1.271872663x
>> StringIndexOf.searchCharLongSuccess	        4.216		4.218		1.000474383x
>> StringIndexOf.searchCharMediumSuccess	3.133		3.216		1.02649218x
>> StringIndexOf.searchCharShortSuccess	3.76		        3.761		1.000265957x
>> StringIndexOf.success	                                9.186		9.713		1.057369911x
>> StringIndexOf.successBig	                      14.341		46.343		3.231504079x
>> StringIndexOfChar.latin1_AVX2_String	  6220.918		12154.52		1.953814533x
>> StringIndexOfChar.latin1_AVX2_char	  5503.556		5540.044		1.006629895x
>> StringIndexOfChar.latin1_SSE4_String	  6978.854		6818.689		0.977049957x
>> StringIndexOfChar.latin1_SSE4_char	  5657.499		5474.624		0.967675646x
>> StringIndexOfChar.latin1_Short_String	  7132.541		6863.359		0.962260014x
>> StringIndexOfChar.latin1_Short_char	16013.389	      16162.437		1.009307711x
>> StringIndexOfChar.latin1_mixed_String	  7386.123	      14771.622		1.999915517x
>> StringIndexOfChar.latin1_mixed_char	  9901.671		9782.245		0.987938803
>
> Scott Gibbons has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove duplicate vm.compiler2.enabled

test/jdk/java/lang/String/IndexOf.java line 35:

> 33:  * @requires vm.cpu.features ~= ".*avx2.*"
> 34:  * @requires vm.compiler2.enabled
> 35:  * @run main/othervm -XX:+IgnoreUnrecognizedVMOptions -Xcomp -XX:-TieredCompilation -XX:UseAVX=2 -XX:+UnlockDiagnosticVMOptions -XX:+EnableX86ECoreOpts IndexOf

Same here: why is the test AVX2 specific? Could other platforms not also be "tickled" in interesting ways with this test?

test/jdk/java/lang/StringBuffer/ECoreIndexOf.java line 29:

> 27:  * @requires vm.cpu.features ~= ".*avx2.*"
> 28:  * @requires vm.compiler2.enabled
> 29:  * @run main/othervm -XX:+UnlockDiagnosticVMOptions -XX:+EnableX86ECoreOpts -XX:UseAVX=2 -Xbatch -XX:-TieredCompilation -XX:CompileCommand=dontinline,ECoreIndexOf.indexOfKernel ECoreIndexOf

Does this test really need to be `avx2` specific? Does it even need to be C2 specific?
Or can this run on all platforms?

test/jdk/java/lang/StringBuffer/IndexOf.java line 188:

> 186:      }
> 187: 
> 188:  }

It looks like you just indented basically the whole file by 1 space. Why?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1620019084
PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1620016717
PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1620013302

From epeter at openjdk.org  Thu May 30 06:28:21 2024
From: epeter at openjdk.org (Emanuel Peter)
Date: Thu, 30 May 2024 06:28:21 GMT
Subject: RFR: 8320448: Accelerate IndexOf using AVX2 [v48]
In-Reply-To: <dp-Dou__skj5A-nyS74949VYGO15gA6SKiCfXC1D6SQ=.3c118c11-0c9c-49d1-a514-d4ffe756f01c@github.com>
References: <uWi4QxH31hL93771gkl_GgvP0m84IRSoR_1Yi8hD17E=.bc6ed458-7081-4c3f-9348-f59358fa05a4@github.com>
 <jJHpKyrD7KBeyP2gEh_CfKKNv2YM8hLccPuG6N9S1JU=.77539396-e5ac-4334-8f2c-a9a1ed5bc478@github.com>
 <dp-Dou__skj5A-nyS74949VYGO15gA6SKiCfXC1D6SQ=.3c118c11-0c9c-49d1-a514-d4ffe756f01c@github.com>
Message-ID: <_0H1QRaXnFyO9eGa7IvO1l4ZzNK_27D59ebYAphp8eg=.0fe38944-0b61-4a1a-b63d-04315b02117f@github.com>

On Thu, 30 May 2024 06:21:36 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

>> Scott Gibbons has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove duplicate vm.compiler2.enabled
>
> test/jdk/java/lang/StringBuffer/ECoreIndexOf.java line 29:
> 
>> 27:  * @requires vm.cpu.features ~= ".*avx2.*"
>> 28:  * @requires vm.compiler2.enabled
>> 29:  * @run main/othervm -XX:+UnlockDiagnosticVMOptions -XX:+EnableX86ECoreOpts -XX:UseAVX=2 -Xbatch -XX:-TieredCompilation -XX:CompileCommand=dontinline,ECoreIndexOf.indexOfKernel ECoreIndexOf
> 
> Does this test really need to be `avx2` specific? Does it even need to be C2 specific?
> Or can this run on all platforms?

Would be a shame to spend so much time on writing a test and then not apply it everywhere ;)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1620017891

From redestad at openjdk.org  Thu May 30 07:47:02 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Thu, 30 May 2024 07:47:02 GMT
Subject: RFR: 8333103: Re-examine the console provider loading
In-Reply-To: <vSJN2UO7GQgMyRZ_4Fytuioz3nImPHPYUWU6dsmacws=.d9210a00-4a14-4f22-8d68-db7d87f3af15@github.com>
References: <M5dxmPs_RJJGqd344t3bMLPMiZmwdtxtbIVP9Bd-ons=.8c7525cc-e3a5-4ed5-81a6-e85398ee6ca6@github.com>
 <cGedShjEGjk6Su-gyXv_BSvKY8VPf1Rbh5FWpQ1Ea_4=.a0ad9532-91db-4918-bd2e-e15252b2edb9@github.com>
 <kGh8i2IkeuM5wNHC1mybHhqvS8pgpN_O35p-BtMnSxI=.0921c15a-ea95-48b9-9bba-e2993c876d98@github.com>
 <vSJN2UO7GQgMyRZ_4Fytuioz3nImPHPYUWU6dsmacws=.d9210a00-4a14-4f22-8d68-db7d87f3af15@github.com>
Message-ID: <zLgCAUpJIvUZXNqpK_CLq4fm1iA6MvhItKVf8s6_ECg=.e0738cd1-cebb-4031-b2ee-2ba749deb58b@github.com>

On Wed, 29 May 2024 22:25:09 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Yes, `break` guarantees that the search completes one way or another once the module name has been matched. This is not how it used to be done.
>
> Right. Since `findAny` is after the module name matching, there is at most 1 match. In the case we didn't find any, the final `orElse(null)` eventually returns null. So the refactored code is semantically the same.

It's only semantically the same if we assume a module can only provide a single `JdkConsoleProvider`, no? The `break;` disallows multiple providers (for disjoint sets of charsets) in a single module.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19467#discussion_r1620164006

From prappo at openjdk.org  Thu May 30 08:26:02 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Thu, 30 May 2024 08:26:02 GMT
Subject: RFR: 8333103: Re-examine the console provider loading
In-Reply-To: <zLgCAUpJIvUZXNqpK_CLq4fm1iA6MvhItKVf8s6_ECg=.e0738cd1-cebb-4031-b2ee-2ba749deb58b@github.com>
References: <M5dxmPs_RJJGqd344t3bMLPMiZmwdtxtbIVP9Bd-ons=.8c7525cc-e3a5-4ed5-81a6-e85398ee6ca6@github.com>
 <cGedShjEGjk6Su-gyXv_BSvKY8VPf1Rbh5FWpQ1Ea_4=.a0ad9532-91db-4918-bd2e-e15252b2edb9@github.com>
 <kGh8i2IkeuM5wNHC1mybHhqvS8pgpN_O35p-BtMnSxI=.0921c15a-ea95-48b9-9bba-e2993c876d98@github.com>
 <vSJN2UO7GQgMyRZ_4Fytuioz3nImPHPYUWU6dsmacws=.d9210a00-4a14-4f22-8d68-db7d87f3af15@github.com>
 <zLgCAUpJIvUZXNqpK_CLq4fm1iA6MvhItKVf8s6_ECg=.e0738cd1-cebb-4031-b2ee-2ba749deb58b@github.com>
Message-ID: <n8AdYMDA3qvNTbm8CWI-wGOoGwBks-6jOfeefMboq18=.1585eb22-285d-4fe6-97f5-5162d5b516cd@github.com>

On Thu, 30 May 2024 07:44:24 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> Right. Since `findAny` is after the module name matching, there is at most 1 match. In the case we didn't find any, the final `orElse(null)` eventually returns null. So the refactored code is semantically the same.
>
> It's only semantically the same if we assume a module can only provide a single `JdkConsoleProvider`, no? The `break;` disallows multiple providers (for disjoint sets of charsets) in a single module.

Claes has described the issue well. Like I said, `break` short-circuits the search. If a module can provide more than one console provider, the suggested stream-less replacement is **not** equivalent.

If a module can provide more than one console provider, not only the code needs to be fixed, but a relevant test should be added too. The test should be in this PR, but tagged with the initial bug, [8295803], not this (performance) bug.

[8295803]: https://bugs.openjdk.org/browse/JDK-8295803

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19467#discussion_r1620237958

From redestad at openjdk.org  Thu May 30 08:38:02 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Thu, 30 May 2024 08:38:02 GMT
Subject: RFR: 8332826: Make hashCode methods in ArraysSupport friendlier
 [v2]
In-Reply-To: <ETcMbUPqlSBIdvEDCPnpfUljutq3dO8NgZJ98MxqUQM=.4d2eac7c-bfc3-4ece-81e5-675c3e399e91@github.com>
References: <ujd2AT3eYXrHPcSG0vMDe2WOx3INNPU1n0t8haKH0_M=.b1a168d7-ab4c-4920-92ef-1c72e5ffc0cf@github.com>
 <1tx_tl3PV2W5NCEXXawQY5V2ndnSOHPfjisypuhKdhA=.79840096-bac0-4da4-8102-c7ecea7cb5f0@github.com>
 <FBIH-xc1qN8grLt03to-5lUHj-jOEzsSk1HPMKZLmSU=.637e8eb0-b2eb-4a0d-a84e-610a142fa5a3@github.com>
 <aqEt9hX5CliI-FvDQKlX1NEMw5OvyBrmcq1kP86sucI=.b07e58fb-e6a8-4df0-b21a-3e3ff8b1b36d@github.com>
 <ETcMbUPqlSBIdvEDCPnpfUljutq3dO8NgZJ98MxqUQM=.4d2eac7c-bfc3-4ece-81e5-675c3e399e91@github.com>
Message-ID: <qn3ebQlJPTCJHE9mm9ZAtaRH62oKlg6nDxp7EJ3L_RU=.37defa7c-e7b3-43dc-8808-d3aeb9575ab9@github.com>

On Wed, 29 May 2024 09:18:51 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> The non-constant test was added because that very bailout caused a crash. The other test is actually less interesting since it'll likely be covered indirectly by regular use. But as we are hiding these away this gets ever more obscure and perhaps the test could be dropped entirely.
>
> @cl4es, do you want me to delete that test file altogether?

I thought you verified that the non-constant type test still provoke a crash (on x86) if you back out the code changes in https://github.com/openjdk/jdk/commit/969f6a37e4649079c7acea1952f5537fd9ba2f0a ? If so that test is still somewhat useful to guard against future coding mistakes by verifying that the bail out doesn't mess things up. The constant type tests have less utility, perhaps. I'd keep it as is unless there's a strong desire to reduce test runtime (these should be pretty quick).

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19414#discussion_r1620259115

From prappo at openjdk.org  Thu May 30 08:44:05 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Thu, 30 May 2024 08:44:05 GMT
Subject: RFR: 8332826: Make hashCode methods in ArraysSupport friendlier
 [v2]
In-Reply-To: <qn3ebQlJPTCJHE9mm9ZAtaRH62oKlg6nDxp7EJ3L_RU=.37defa7c-e7b3-43dc-8808-d3aeb9575ab9@github.com>
References: <ujd2AT3eYXrHPcSG0vMDe2WOx3INNPU1n0t8haKH0_M=.b1a168d7-ab4c-4920-92ef-1c72e5ffc0cf@github.com>
 <1tx_tl3PV2W5NCEXXawQY5V2ndnSOHPfjisypuhKdhA=.79840096-bac0-4da4-8102-c7ecea7cb5f0@github.com>
 <FBIH-xc1qN8grLt03to-5lUHj-jOEzsSk1HPMKZLmSU=.637e8eb0-b2eb-4a0d-a84e-610a142fa5a3@github.com>
 <aqEt9hX5CliI-FvDQKlX1NEMw5OvyBrmcq1kP86sucI=.b07e58fb-e6a8-4df0-b21a-3e3ff8b1b36d@github.com>
 <ETcMbUPqlSBIdvEDCPnpfUljutq3dO8NgZJ98MxqUQM=.4d2eac7c-bfc3-4ece-81e5-675c3e399e91@github.com>
 <qn3ebQlJPTCJHE9mm9ZAtaRH62oKlg6nDxp7EJ3L_RU=.37defa7c-e7b3-43dc-8808-d3aeb9575ab9@github.com>
Message-ID: <RQ6SGUS9sZkjiAFVqQ1gtff7_6e_Zj6bceJKdFNqTW8=.3eb73cb4-4a30-4ef6-9856-30ae50008506@github.com>

On Thu, 30 May 2024 08:34:59 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> @cl4es, do you want me to delete that test file altogether?
>
> I thought you verified that the non-constant type test still provoke a crash (on x86) if you back out the code changes in https://github.com/openjdk/jdk/commit/969f6a37e4649079c7acea1952f5537fd9ba2f0a ? If so that test is still somewhat useful to guard against future coding mistakes by verifying that the bail out doesn't mess things up. The constant type tests have less utility, perhaps. I'd keep it as is unless there's a strong desire to reduce test runtime (these should be pretty quick).

I did verify it. Sorry, momentary lapse of the ability to reason. I'll integrate this PR very shortly then. Thanks.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19414#discussion_r1620268479

From prappo at openjdk.org  Thu May 30 09:36:06 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Thu, 30 May 2024 09:36:06 GMT
Subject: Integrated: 8332826: Make hashCode methods in ArraysSupport friendlier
In-Reply-To: <ujd2AT3eYXrHPcSG0vMDe2WOx3INNPU1n0t8haKH0_M=.b1a168d7-ab4c-4920-92ef-1c72e5ffc0cf@github.com>
References: <ujd2AT3eYXrHPcSG0vMDe2WOx3INNPU1n0t8haKH0_M=.b1a168d7-ab4c-4920-92ef-1c72e5ffc0cf@github.com>
Message-ID: <j9qEB6_iVRTqN6l8gqGYUd2OwMstSxSnyj5e5ZlXArg=.f38af05f-564a-478d-b586-7d3fdee47e17@github.com>

On Mon, 27 May 2024 16:28:31 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> Please review this PR, which supersedes a now withdrawn https://github.com/openjdk/jdk/pull/14831.
> 
> This PR replaces `ArraysSupport.vectorizedHashCode` with a set of more user-friendly methods. Here's a summary:
> 
> - Made the operand constants (i.e. `T_BOOLEAN` and friends) and the `vectorizedHashCode` method private
> 
> - Made the `vectorizedHashCode` method private, but didn't rename it. Renaming would dramatically increase this PR review cost, because that method's name is used by a lot of VM code. On a bright side, since the method is now private, it's no longer callable by clients of `ArraysSupport`, thus a problem of an inaccurate name is less severe.
> 
> - Made the `ArraysSupport.utf16HashCode` method private
> 
> - Moved tiny cases (i.e. 0, 1, 2) to `ArraysSupport`

This pull request has now been integrated.

Changeset: 3cff588a
Author:    Pavel Rappo <prappo at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/3cff588a3104aa5224e7236eb2c2bb5852de9202
Stats:     266 lines in 13 files changed: 186 ins; 32 del; 48 mod

8332826: Make hashCode methods in ArraysSupport friendlier

Reviewed-by: redestad, liach

-------------

PR: https://git.openjdk.org/jdk/pull/19414

From amansha at kth.se  Thu May 30 09:43:03 2024
From: amansha at kth.se (Aman Sharma)
Date: Thu, 30 May 2024 09:43:03 +0000
Subject: Deterministic naming of subclasses of `java/lang/reflect/Proxy`
In-Reply-To: <eabfa5ae508e4257bd0c9bbef244637f@kth.se>
References: <bf26eb2f74874e02876b3868311922a9@kth.se>
 <CABe8uE0fk71Xy_PYHikSw9OtXE_i+M9zMbayPEXuTxLWLoy2ag@mail.gmail.com>
 <50405ca9c0a64372bace175b932f9ef7@kth.se>
 <61fbe3d9-9536-4113-adde-6cfc671ba1ee@oracle.com>
 <a860be44e06243799593aa8d67c048cd@kth.se>
 <CABe8uE115=DzYCdnvNazqFuuxtJoZnv9wRUkFA4-PS7g41QLMw@mail.gmail.com>
 <DB7PR02MB35938DCC3A392536B924164AFBEE2@DB7PR02MB3593.eurprd02.prod.outlook.com>
 <a0330ee0-5f45-4ef2-8500-e5fcdb696c52@oracle.com>
 <b214cc1a13fe4885a437e16b420e5483@kth.se>
 <ac2ebe5c-db49-4a2d-a5cd-10440a77aa16@oracle.com>
 <580b3aacd8df48fcaae3399718e229ab@kth.se>,
 <CABe8uE065Q3+0yNjtyDF-eJM4LN-MbY9kfC44CnSQ-KM4p862g@mail.gmail.com>,
 <b64077d6cf0045e98b630cf888785182@kth.se>,
 <eabfa5ae508e4257bd0c9bbef244637f@kth.se>
Message-ID: <46b6b1bd2ca040509834b188da8a21c9@kth.se>

Hi Joe,


> As a general comment, it is _not_ the goal of the API specification to
(over) specify exact behavior in cases like this.

> See as an example the discussion concerning behavioral compatibility
starting around slide 46 of

> "Contributing to OpenJDK: Participating in stewardship for the long-term,"
https://jcp.org/aboutJava/communityprocess/ec-public/materials/2023-06-13/Contributing_to_OpenJDK_2023_04_12.pdf


> This approach has evolved over the years and releases.

> In this case semantically, the array returned by getMethod is a set and
the no particular meaning should be read into the order of the elements.

> HTH,


> -Joe

Missed this email of yours. Thanks for making it clear.


Regards,
Aman Sharma

PhD Student
KTH Royal Institute of Technology
School of Electrical Engineering and Computer Science (EECS)
Department of Theoretical Computer Science (TCS)
<http://www.kth.se><https://www.kth.se/profile/amansha><https://www.kth.se/profile/amansha>
<https://www.kth.se/profile/amansha>https://algomaster99.github.io/
________________________________
From: Aman Sharma
Sent: Wednesday, May 22, 2024 8:19:41 PM
To: Chen Liang
Cc: David Holmes; core-libs-dev at openjdk.org; leyden-dev at openjdk.org
Subject: Re: Deterministic naming of subclasses of `java/lang/reflect/Proxy`


Hi,


Another thing I wanted to look into in this thread was the order of fields in the Proxy classes generated. They are also based on the a number. The same proxy classes across different executions can have random order of `Method` fields and the methods could be mapped to different field names.


For example, consider the proxy class based on `picocli.CommandLine<https://github.com/remkop/picocli/blob/da98db63d1b516141b7485881b0dcddfd082dbc8/src/main/java/picocli/CommandLine.java#L4541>` in two different executions.

// fields and method are truncated for brevity
public final class $Proxy9 extends Proxy implements CommandLine.Command {
    private static Method m1;
    private static Method m32;
    private static Method m21;
    private static Method m43;
    private static Method m36;
    private static Method m27;

    public final boolean helpCommand() throws  {
        try {
            return (Boolean)super.h.invoke(this, m32, (Object[])null);
        } catch (RuntimeException | Error var2) {
            throw var2;
        } catch (Throwable var3) {
            throw new UndeclaredThrowableException(var3);
        }
     }

// fields and method are truncated for brevity
public final class $Proxy13 extends Proxy implements CommandLine.Command {
    private static Method m1;
    private static Method m29;
    private static Method m16;
    private static Method m40;
    private static Method m38;
    private static Method m12;

    public final boolean helpCommand() throws  {
        try {
            return (Boolean)super.h.invoke(this, m29, (Object[])null);
        } catch (RuntimeException | Error var2) {
            throw var2;
        } catch (Throwable var3) {
            throw new UndeclaredThrowableException(var3);
        }
    }


Notice the difference in the order of fields and `helpCommand` method is mapped to a different field name in both classes. This happens because the method array returned by `getMethods` is not sorted in any particular order<https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/lang/Class.java#L2178> when generating a proxy class. What dictates this order? And why is it not deterministic?


Regards,
Aman Sharma

PhD Student
KTH Royal Institute of Technology
School of Electrical Engineering and Computer Science (EECS)
Department of Theoretical Computer Science (TCS)
<http://www.kth.se><https://www.kth.se/profile/amansha><https://www.kth.se/profile/amansha>
<https://www.kth.se/profile/amansha>https://algomaster99.github.io/
________________________________
From: Aman Sharma
Sent: Wednesday, May 22, 2024 4:12:19 PM
To: Chen Liang
Cc: David Holmes; core-libs-dev at openjdk.org; leyden-dev at openjdk.org
Subject: Re: Deterministic naming of subclasses of `java/lang/reflect/Proxy`


Hi Chen,


That's clear. Thanks for letting me know. I guess then Project Leyden is working on naming the hidden classes deterministically to achieve their goals<https://openjdk.org/projects/leyden/notes/01-beginnings>.


Regards,
Aman Sharma

PhD Student
KTH Royal Institute of Technology
School of Electrical Engineering and Computer Science (EECS)
Department of Theoretical Computer Science (TCS)
<http://www.kth.se><https://www.kth.se/profile/amansha><https://www.kth.se/profile/amansha>
<https://www.kth.se/profile/amansha>https://algomaster99.github.io/
________________________________
From: Chen Liang <liangchenblue at gmail.com>
Sent: Wednesday, May 22, 2024 1:35:46 PM
To: Aman Sharma
Cc: David Holmes; core-libs-dev at openjdk.org; leyden-dev at openjdk.org
Subject: Re: Deterministic naming of subclasses of `java/lang/reflect/Proxy`

Hi Aman,
We have tried defining Proxy as hidden classes; a previous attempt was on hold because of issues with serialization. Otherwise, Proxies work great as hidden classes.

Chen

On Mon, May 20, 2024 at 7:56?AM Aman Sharma <amansha at kth.se<mailto:amansha at kth.se>> wrote:

Hi David,


> I would not expect any class load
events.


I understand. I also haven't tried to intercept them but I see only one approach right now to include them in an allowlist - 1) statically look for invocations of "Lookup::defineHiddenClass". 2) Instrument them so that its first argument "bytes" can be looked into upon. I haven't looked into it much because I did not have much idea about it. And they are hidden so it made it worse. ? Thanks for sharing the JEP!


>

java.lang.reflect.Proxy could define hidden classes to act as the proxy classes which implement proxy interfaces; from JEP 317


It says that Proxy classes will also become hidden classes. Is it underway? Right now one can intercept, transform them, and include them in an allowlist. What do you think of naming them independent of AtomicLong so that a proxy class generated at runtime is easy to lookup in the allowlist?



Regards,
Aman Sharma

PhD Student
KTH Royal Institute of Technology
School of Electrical Engineering and Computer Science (EECS)
Department of Theoretical Computer Science (TCS)
<http://www.kth.se><https://www.kth.se/profile/amansha><https://www.kth.se/profile/amansha>
<https://www.kth.se/profile/amansha>https://algomaster99.github.io/
________________________________
From: David Holmes <david.holmes at oracle.com<mailto:david.holmes at oracle.com>>
Sent: Monday, May 20, 2024 2:30:37 PM
To: Aman Sharma; liangchenblue at gmail.com<mailto:liangchenblue at gmail.com>
Cc: core-libs-dev at openjdk.org<mailto:core-libs-dev at openjdk.org>; leyden-dev at openjdk.org<mailto:leyden-dev at openjdk.org>
Subject: Re: Deterministic naming of subclasses of `java/lang/reflect/Proxy`

On 20/05/2024 10:12 pm, Aman Sharma wrote:
> Hi David,
>
>
>  > How did you try to intercept them? Hidden classes are not "loaded" in
> the normal sense so won't trigger class load events.
>
>
> I could not intercept them. I only see them when I pass `-verbose:class`
> in the Java CLI.

Yes that is why I asked how you tried to intercept them.

>
> I also couldn't intercept them using JVMTI Class File Load Hook
> <https://docs.oracle.com/en/java/javase/21/docs/specs/jvmti.html#ClassFileLoadHook> event. However JEP 371 suggests that it should be possible to intercept them using JVMTI Class Load <https://docs.oracle.com/en/java/javase/21/docs/specs/jvmti.html#ClassLoad> event, but I won't have the bytecode at this stage. So is there no way to get its bytecode before it is linked and initialized in the JVM?

Hidden classes are not loaded so I would not expect any class load
events. However the exact nature of the JVMTI class load event is
unclear as it talks about "class or interface creation" which is neither
loading or defining per se. But a class prepare event sounds like it
should be issued. However neither give you access to the bytecode of the
class AFAICS.

David
-----


>
> Regards,
> Aman Sharma
>
> PhD Student
> KTH Royal Institute of Technology
> School of Electrical Engineering and Computer Science (EECS)
> Department of Theoretical Computer Science (TCS)
> <http://www.kth.se><https://www.kth.se/profile/amansha><https://www.kth.se/profile/amansha>
> <https://www.kth.se/profile/amansha>https://algomaster99.github.io/
> <https://algomaster99.github.io/>
> ------------------------------------------------------------------------
> *From:* David Holmes <david.holmes at oracle.com<mailto:david.holmes at oracle.com>>
> *Sent:* Monday, May 20, 2024 2:59:17 AM
> *To:* Aman Sharma; liangchenblue at gmail.com<mailto:liangchenblue at gmail.com>
> *Cc:* core-libs-dev at openjdk.org<mailto:core-libs-dev at openjdk.org>; leyden-dev at openjdk.org<mailto:leyden-dev at openjdk.org>
> *Subject:* Re: Deterministic naming of subclasses of
> `java/lang/reflect/Proxy`
> On 17/05/2024 9:43 pm, Aman Sharma wrote:
>> Hi Chen,
>>
>>  > java.lang.invoke.LambdaForm$MH/0x00000200cc000400
>>
>> I do see this as output when I pass -verbose:class. However, based on my
>> experiments, I have seen that neither an agent passed via 'javaagent'
>> nor an agent passed via 'agentpath' is able to intercept this hidden class.
>
> How did you try to intercept them? Hidden classes are not "loaded" in
> the normal sense so won't trigger class load events.
>
>> Also, I was a bit confused since I saw somewhere that the names of
>> hidden classes are null. But thanks for clarifying here.
>
> The JEP clearly defines the name format for hidden classes - though the
> final component is VM specific (and typically a hashcode).
>
> https://openjdk.org/jeps/371 <https://openjdk.org/jeps/371>
>
> Cheers,
> David
> -----
>
>>  > avoid dynamic class loading
>>
>> I don't see dynamic class loading as a problem. I only mind some
>> unstable generation aspects of them which make it hard to verify them
>> based on an allowlist.
>>
>> For example, if this hidden class is generated with the exact same name
>> and the exact same bytecode during runtime as well, it would be easy to
>> verify it. However, I do see the names are based on some sort of memory
>> address so and I don't know what bytecode it has so I don't have
>> suggestions to make them stable as of now. For Proxy classes, I feel it
>> can be addressed unless you disagree or some involved in Project Leyden
>> does. :) Thank you for forwarding my mail there.
>>
>> Regards,
>> Aman Sharma
>>
>> PhD Student
>> KTH Royal Institute of Technology
>> https://algomaster99.github.io/ <https://algomaster99.github.io/>
> <https://algomaster99.github.io/ <https://algomaster99.github.io/>>
>>
>> ------------------------------------------------------------------------
>> *From:* liangchenblue at gmail.com<mailto:liangchenblue at gmail.com> <liangchenblue at gmail.com<mailto:liangchenblue at gmail.com>>
>> *Sent:* Friday, May 17, 2024 1:23:58 pm
>> *To:* Aman Sharma <amansha at kth.se<mailto:amansha at kth.se>>
>> *Cc:* core-libs-dev at openjdk.org<mailto:core-libs-dev at openjdk.org> <core-libs-dev at openjdk.org<mailto:core-libs-dev at openjdk.org>>;
>> leyden-dev at openjdk.org<mailto:leyden-dev at openjdk.org> <leyden-dev at openjdk.org<mailto:leyden-dev at openjdk.org>>
>> *Subject:* Re: Deterministic naming of subclasses of
>> `java/lang/reflect/Proxy`
>>
>> Hi Aman,
>> For `-verbose:class`, it's a JVM argument instead of a program argument;
>> so when you run a java program like `java Main`, you should call it as
>> `java -verbose:class Main`.
>> When done correctly, you should see hidden class outputs like:
>> [0.032s][info][class,load]
>> java.lang.invoke.LambdaForm$MH/0x00000200cc000400 source:
>> __JVM_LookupDefineClass__
>> The loading of java.lang.invoke hidden classes requires your program to
>> use MethodHandle features, like a lambda.
>>
>> I think the problem you are exploring, that to avoid dynamic class
>> loading and effectively turn Java Platform closed for security, is also
>> being accomplished by project Leyden (as I've shared initially); Thus, I
>> am forwarding this to leyden-dev instead, so you can see what approach
>> Leyden uses to accomplish the same goal as yours.
>>
>> Regards, Chen Liang
>>
>> On Fri, May 17, 2024 at 4:40?AM Aman Sharma <amansha at kth.se<mailto:amansha at kth.se>
>> <mailto:amansha at kth.se<mailto:amansha at kth.se> <mailto:amansha at kth.se>>> wrote:
>>
>>     __
>>
>>     Hi Roger,
>>
>>
>>     Do you have ideas on how to intercept them? My javaagent is not able
>>     to nor a JVMTI agent passed using `agentpath` option. It also does
>>     not seem to show up in logs when I pass `-verbose:class`.
>>
>>
>>     Also, what do you think of renaming the proxy classes as suggested
>>     below?
>>
>>
>>     Regards,
>>     Aman Sharma
>>
>>     PhD Student
>>     KTH Royal Institute of Technology
>>     School of Electrical Engineering and Computer Science (EECS)
>>     Department of Theoretical Computer Science (TCS)
>>     <http://www.kth.se><https://www.kth.se/profile/amansha><https://www.kth.se/profile/amansha <http://www.kth.se><https://www.kth.se/profile/amansha><https://www.kth.se/profile/amansha>>
>>     <https://www.kth.se/profile/amansha
> <https://www.kth.se/profile/amansha>>https://algomaster99.github.io/
>>     <https://algomaster99.github.io/ <https://algomaster99.github.io/>>
>>     ------------------------------------------------------------------------
>>     *From:* core-libs-dev <core-libs-dev-retn at openjdk.org<mailto:core-libs-dev-retn at openjdk.org>
>>     <mailto:core-libs-dev-retn at openjdk.org<mailto:core-libs-dev-retn at openjdk.org>
> <mailto:core-libs-dev-retn at openjdk.org>>> on behalf of Roger Riggs
>>     <roger.riggs at oracle.com<mailto:roger.riggs at oracle.com> <mailto:roger.riggs at oracle.com<mailto:roger.riggs at oracle.com> <mailto:roger.riggs at oracle.com>>>
>>     *Sent:* Friday, May 17, 2024 4:57:46 AM
>>     *To:* core-libs-dev at openjdk.org<mailto:core-libs-dev at openjdk.org> <mailto:core-libs-dev at openjdk.org<mailto:core-libs-dev at openjdk.org> <mailto:core-libs-dev at openjdk.org>>
>>     *Subject:* Re: Deterministic naming of subclasses of
>>     `java/lang/reflect/Proxy`
>>     Hi Aman,
>>
>>     You may also run into hidden classes (JEP 371: Hidden Classes) that
>>     allow classes to be defined, at runtime, without names.
>>     It has been proposed to use them for generated proxies but that
>>     hasn't been implemented yet.
>>     There are benefits to having nameless classes, because they can't be
>>     referenced by name, only as a capability, they can be better
>>     encapsulated.
>>
>>     fyi, Roger Riggs
>>
>>
>>     On 5/16/24 8:11 AM, Aman Sharma wrote:
>>>
>>>     Hi,
>>>
>>>
>>>     Thanks for your response, Liang!
>>>
>>>
>>>     > I think you meant CVE-2021-42392 instead of 2022.
>>>
>>>
>>>     Sorry of the error. I indeed meant CVE-2021-42392
>>>     <https://nvd.nist.gov/vuln/detail/cve-2021-42392
> <https://nvd.nist.gov/vuln/detail/cve-2021-42392>>.
>>>
>>>
>>>     > Leyden mainly avoids this unstable generation by performing a
>>>     training run to collect classes loaded
>>>
>>>
>>>     Would love to know the details of Project Leyden and how they
>>>     worked so far to focus on this goal. In our case, the training run
>>>     is the test suite.
>>>
>>>
>>>     > GeneratedConstructorAccessor is already retired by JEP 416 [2]
>>>     in Java 18
>>>
>>>
>>>     I did see them not appearing in my allowlist when I ran my study
>>>     subject (Apache PDFBox) with Java 21. Thanks for letting me know
>>>     about this JEP. I see they are re-implemented with method handles.
>>>
>>>
>>>     > How are you checking the classes?
>>>
>>>
>>>     To detect runtime generated code, we have javaagent that is hooked
>>>     statically to the test suite execution. It gives us all classes
>>>     that that is loaded post the JVM and the javaagent are loaded. So
>>>     we only check the classes loaded for the purpose of running the
>>>     application. This is also why we did not choose -agentlib as it
>>>     would give classes for the setting up JVM and javaagent and we the
>>>     user of our tool must the classes they load.
>>>
>>>
>>>     Next, we have a `ClassFileTransformer` hook in the agent where we
>>>     produce the checksum using the bytecode. And we compare the
>>>     checksum with the one existing in the allowlist. The checksum
>>>     computation algorithm is same for both steps. Let me describe how
>>>     I compute the checksum.
>>>
>>>
>>>      1. I get the CONSTANT_Class_info
>>>         <https://docs.oracle.com/javase/specs/jvms/se11/html/jvms-4.html#jvms-4.4.1 <https://docs.oracle.com/javase/specs/jvms/se11/html/jvms-4.html#jvms-4.4.1>> entry corresponding to `this_class` and rewrite the CONSTANT_Utf8_info <https://docs.oracle.com/javase/specs/jvms/se11/html/jvms-4.html#jvms-4.4.7 <https://docs.oracle.com/javase/specs/jvms/se11/html/jvms-4.html#jvms-4.4.7>> corresponding to a fix String constant, say "foo".
>>>      2. Since, the name of the class is used to refer to its types
>>>         members (fields/method), I get all CONSTANT_Fieldref_info
>>>         <https://docs.oracle.com/javase/specs/jvms/se11/html/jvms-4.html#jvms-4.4.2 <https://docs.oracle.com/javase/specs/jvms/se11/html/jvms-4.html#jvms-4.4.2>> and if its `class_index` corresponds to the old `this_class`, we rewrite the UTF8 value of class_index to the same constant "foo".
>>>      3. Next, since the naming of the fields, in Proxy classes, are
>>>         also suffixed by numbers, for example, `private static Method
>>>         m4`, we rewrite the UTF8 value of name in the
>>>         CONSTANT_NameAndType_info
>>>         <https://docs.oracle.com/javase/specs/jvms/se11/html/jvms-4.html#jvms-4.4.6 <https://docs.oracle.com/javase/specs/jvms/se11/html/jvms-4.html#jvms-4.4.6>>.
>>>      4. These fields can also have a random order so we simply sort
>>>         the entire byte code using `Arrays.sort(byte[])` to eliminate
>>>         any differences due to ordering of fields/methods.
>>>      5. Simply sorting the byte array still had minute differences. I
>>>         could not understand why they existed even though values in
>>>         constant pool of the bytecode in allowlist and at runtime were
>>>         exactly the same after rewriting. The differences existed in
>>>         the bytes of the Code attribute of methods. I concluded that
>>>         the bytes stored some position information. To avoid this, I
>>>         created a subarray where I considered the bytes corresponding
>>>         to `CONSTANT_Utf8_info.bytes` only. Computing a checksum for
>>>         it resulted in the same checksums for both classfiles.
>>>
>>>
>>>     Let's understand the whole approach with an example of Proxy class.
>>>
>>>     `
>>>     public  final  class  $Proxy42  extends  Proxy  implements  org.apache.logging.log4j.core.config.plugins.Plugin  {
>>>     `
>>>
>>>     The will go in the allowlist as "Proxy_Plugin: <SHA256 checksum>".
>>>
>>>     When the same class is intercepted at runtime, say "$Proxy10", we
>>>     look for "Proxy_Plugin" in the allowlist and since the checksum
>>>     algorithm is same in both cases, we get a match and let the class
>>>     load.
>>>
>>>     This approach has seemed to work well for Proxy classes, Generated
>>>     Constructor Accessor (which is removed as you said). I also looked
>>>     at the species generated by method handles. I did not notice any
>>>     modification in them. Their name generation seemed okay to me. If
>>>     some new Species are generated, it is of course detected since it
>>>     is not in the allowlist.
>>>
>>>     I have not looked into LambdaMetafactory because I did not
>>>     encounter it as a problem so far, but I am aware its name
>>>     generation is also unstable. I have run my approach only a few
>>>     projects only. And for hidden classes, I assume the the agent
>>>     won't be able to intercept them so detecting them would be really
>>>     hard.
>>>
>>>
>>>     Regards,
>>>     Aman Sharma
>>>
>>>     PhD Student
>>>     KTH Royal Institute of Technology
>>>     School of Electrical Engineering and Computer Science (EECS)
>>>     Department of Theoretical Computer Science (TCS)
>>>     <https://www.kth.se/profile/amansha
> <https://www.kth.se/profile/amansha>>https://algomaster99.github.io/
> <https://algomaster99.github.io/ <https://algomaster99.github.io/>>
>>>     ------------------------------------------------------------------------
>>>     *From:* liangchenblue at gmail.com<mailto:liangchenblue at gmail.com> <mailto:liangchenblue at gmail.com<mailto:liangchenblue at gmail.com> <mailto:liangchenblue at gmail.com>>
>>>     <liangchenblue at gmail.com<mailto:liangchenblue at gmail.com>> <mailto:liangchenblue at gmail.com<mailto:liangchenblue at gmail.com> <mailto:liangchenblue at gmail.com>>
>>>     *Sent:* Thursday, May 16, 2024 5:52:03 AM
>>>     *To:* Aman Sharma; core-libs-dev
>>>     *Cc:* Martin Monperrus
>>>     *Subject:* Re: Deterministic naming of subclasses of
>>>     `java/lang/reflect/Proxy`
>>>     Hi Aman,
>>>     I think you meant CVE-2021-42392 instead of 2022.
>>>
>>>     For your approach of an "allowlist" for Java runtime, project
>>>     Leyden is looking to generate a static image [1], that
>>>     > At run time it cannot load classes from outside the image, nor
>>>     can it create classes dynamically.
>>>     Leyden mainly avoids this unstable generation by performing a
>>>     training run to collect classes loaded and even object graphs; I
>>>     am not familiar with the details unfortunately.
>>>
>>>     Otherwise, the Proxy discussion belongs better to core-libs-dev,
>>>     as java.lang.reflect.Proxy is part of Java's core libraries. I am
>>>     replying this thread to core-libs-dev.
>>>
>>>     For your perceived problem that classes don't have unique names,
>>>     your description sounds dubious: GeneratedConstructorAccessor is
>>>     already retired by JEP 416 [2] in Java 18, and there are many
>>>     other cases in which JDK generates classes without stable names,
>>>     notoriously LambdaMetafactory (Gradle wished for cacheable
>>>     Lambdas); the same applies for the generated classes for
>>>     MethodHandle's LambdaForms (which carries implementation code for
>>>     LambdaForm). How are you checking the classes? It seems you are
>>>     not checking hidden classes. Proxy and Lambda classes are defined
>>>     by the caller's class loader, while LambdaForms are under JDK's
>>>     system class loader I think. We need to ensure you are correctly
>>>     finding all unstable classes before we can proceed.
>>>
>>>     [1]: https://openjdk.org/projects/leyden/notes/01-beginnings
> <https://openjdk.org/projects/leyden/notes/01-beginnings>
>>>     <https://openjdk.org/projects/leyden/notes/01-beginnings
> <https://openjdk.org/projects/leyden/notes/01-beginnings>>
>>>     [2]: https://openjdk.org/jeps/416 <https://openjdk.org/jeps/416>
> <https://openjdk.org/jeps/416 <https://openjdk.org/jeps/416>>
>>>
>>>     On Wed, May 15, 2024 at 7:00?PM Aman Sharma <amansha at kth.se<mailto:amansha at kth.se>
>>>     <mailto:amansha at kth.se<mailto:amansha at kth.se> <mailto:amansha at kth.se>>> wrote:
>>>
>>>         Hi,
>>>
>>>
>>>         My name is Aman and I am a PhD student at KTH Royal Institute
>>>         of Technology, Stockholm, Sweden. I research as part of CHAINS
>>>         <https://chains.proj.kth.se/ <https://chains.proj.kth.se/>> project to
> strengthen the
>>>         software supply chain of multiple ecosystem. I particularly
>>>         focus on runtime integrity in Java. In this email, I want to
>>>         write about an issue I have discovered with /dynamic
>>>         generation of `java.lang.reflect.Proxy`classes/. I will
>>>         propose a solution and would love to hear the feedback from
>>>         the community. Let me know if this is the correct mailing-list
>>>         for such discussions. It seemed the most relevant from this
>>>         list <https://mail.openjdk.org/mailman/listinfo
> <https://mail.openjdk.org/mailman/listinfo>>.
>>>
>>>
>>>         *My research*
>>>
>>>         *
>>>         *
>>>
>>>         Java has features to load class on the fly - it can either
>>>         download or generate a class at runtime. These features are
>>>         useful for inner workings of JDK. For example, implementing
>>>         annotations, reflective access, etc. However, these features
>>>         have also contributed to critical vulnerabilities in the past
>>>         - CVE-2021-44228  (log4shell), CVE-2022-33980, CVE-2022-42392.
>>>         All of these vulnerabilities have one thing in common - /a
>>>         class that was not known during build time was
>>>         downloaded/generated at runtime and loaded into JVM./
>>>
>>>
>>>         To defend against such vulnerabilities, we propose a solution
>>>         to /allowlist classes for runtime/. This allowlist will
>>>         contain an exhaustive list of classes that can be loaded by
>>>         the JVM and it will be enforced at runtime. We build this
>>>         allowlist from three sources:
>>>
>>>          1. All classes of all modules provided by the Java Standard
>>>             Library. We use ClassGraph
>>>             <https://github.com/classgraph/classgraph
> <https://github.com/classgraph/classgraph>> to scan the JDK.
>>>          2. We can take the source code and all dependencies of an
>>>             application. We use a software bill of materials to get
>>>             all the data.
>>>          3. Finally, we use run the test suite to include any runtime
>>>             downloaded/generated classes.
>>>
>>>         Such a list is able to prevent the above 3 CVEs because it
>>>         does not let the "unknown" bytecode to be loaded.
>>>
>>>         *Problem with generating such an allowlist*
>>>         *
>>>         *
>>>         The first two parts of the allowlist are easy to get. The
>>>         problem is with the third step where we want to allowlist all
>>>         the classes that could be downloaded or generated. Upon
>>>         running the test suite and hooking to the classes it loads, we
>>>         observer that the list consists of classes that are called
>>>         "com/sun/proxy/$Proxy2",
>>>         "jdk/internal/reflect/GeneratedConstructorAccessor3" among
>>>         many more. The purpose of these classes can be identifed. The
>>>         proxy class is created for to implement an annotation. The
>>>         accessor gives access to constructor of a class to the JVM.
>>>
>>>         When enforcing this allowlist at runtime, we see that the
>>>         bytecode content for "com/sun/proxy/$Proxy2" differs in the
>>>         allowlist and at runtime. In our case, we we are experimenting
>>>         with pdfbox <https://github.com/apache/pdfbox <https://github.com/apache/pdfbox>> so
> we created
>>>         the allowlist using its test suite. Then we enforced this
>>>         allowlist while running some of its subcommands. However,
>>>         there was some other proxy class say "com/sun/proxy/$Proxy5"
>>>         at runtime that implemented the same interfaces and had the
>>>         same methods as "com/sun/proxy/$Proxy2" in the allowlist. They
>>>         only differed in the name of the class, order of fields, and
>>>         types for fields references. This could happen because the
>>>         order of the loading of class is workload dependent, but it
>>>         causes problem to generate such an allowlist.
>>>
>>>         *Solution
>>>         *
>>>
>>>
>>>         We propose that naming of subclasses of
>>>         "java/lang/reflect/Proxy" should not be dependent upon the
>>>         order of loading. In order to do so, two issues can be fixed:
>>>
>>>          1. The naming of the class should not be based on AtomicLong
>>>             <https://github.com/openjdk/jdk/blob/b687aa550837830b38f0f0faa69c353b1e85219c/src/java.base/share/classes/java/lang/reflect/Proxy.java#L531 <https://github.com/openjdk/jdk/blob/b687aa550837830b38f0f0faa69c353b1e85219c/src/java.base/share/classes/java/lang/reflect/Proxy.java#L531>>. Rather it could be named based on the interfaces it implements. I also wonder why AtomicLong is chosen in the first place.
>>>          2. Methods of the interfaces must be in a particular order.
>>>             Right now, they are not sorted in any particular order
>>>             <https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/lang/Class.java#L2178 <https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/lang/Class.java#L2178>>.
>>>
>>>
>>>         These fixes will make proxy class generation deterministic
>>>         with respect to order of loading and won't be flagged at
>>>         runtime since the test suite would already detect them.
>>>
>>>         I would love to hear from the community about these ideas. If
>>>         in agreement, I would be happy to produce a patch. I have
>>>         discovered this issue with subclasses of
>>>         GeneratedConstructorAccessor
>>>         <https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/jdk/internal/reflect/ConstructorAccessor.java <https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/jdk/internal/reflect/ConstructorAccessor.java>> as well and I imagine it will also apply to some other runtime generated classes. If you disagree, please let me know also. It helps with my research.
>>>
>>>         I also have PoCs for the above CVEs
>>>         <https://github.com/chains-project/exploits-for-sbom.exe
> <https://github.com/chains-project/exploits-for-sbom.exe>> and
>>>         a proof concept tool is being developed under the name
>>>         sbom.exe <https://github.com/chains-project/sbom.exe
> <https://github.com/chains-project/sbom.exe>> in case
>>>         any one wonders about the implementation. I would also be
>>>         happy to explain more.
>>>
>>>         Regards,
>>>         Aman Sharma
>>>
>>>         PhD Student
>>>         KTH Royal Institute of Technology
>>>         School of Electrical Engineering and Computer Science (EECS)
>>>         Department of Theoretical Computer Science (TCS)
>>>         <https://www.kth.se/profile/amansha
> <https://www.kth.se/profile/amansha>>https://algomaster99.github.io/
> <https://algomaster99.github.io/ <https://algomaster99.github.io/>>
>>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240530/2d58546f/attachment-0001.htm>

From alanb at openjdk.org  Thu May 30 10:05:05 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 30 May 2024 10:05:05 GMT
Subject: RFR: 8333103: Re-examine the console provider loading
In-Reply-To: <M5dxmPs_RJJGqd344t3bMLPMiZmwdtxtbIVP9Bd-ons=.8c7525cc-e3a5-4ed5-81a6-e85398ee6ca6@github.com>
References: <M5dxmPs_RJJGqd344t3bMLPMiZmwdtxtbIVP9Bd-ons=.8c7525cc-e3a5-4ed5-81a6-e85398ee6ca6@github.com>
Message-ID: <A0ymlIT-U6QzlB6hxS8C3UVbLZRmxf7vsOMepR7rxCE=.1a3c57c7-dbba-4de8-b9e1-7b5a57f5bb48@github.com>

On Wed, 29 May 2024 19:51:36 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> There is an initialization code in `Console` class that searches for the Console implementations. Refactoring the init code not to use lambda/stream would reduce the (initial) number of loaded classes by about 100 for java.base implementations. This would become relevant when the java.io.IO (JEP 477) uses Console as the underlying framework.

Would it be possible to provide more context/background here? This is not code that is used during startup. Is there benchmark data to share for first use of java.io.IO ?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19467#issuecomment-2139208694

From redestad at openjdk.org  Thu May 30 10:11:01 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Thu, 30 May 2024 10:11:01 GMT
Subject: RFR: 8333103: Re-examine the console provider loading
In-Reply-To: <A0ymlIT-U6QzlB6hxS8C3UVbLZRmxf7vsOMepR7rxCE=.1a3c57c7-dbba-4de8-b9e1-7b5a57f5bb48@github.com>
References: <M5dxmPs_RJJGqd344t3bMLPMiZmwdtxtbIVP9Bd-ons=.8c7525cc-e3a5-4ed5-81a6-e85398ee6ca6@github.com>
 <A0ymlIT-U6QzlB6hxS8C3UVbLZRmxf7vsOMepR7rxCE=.1a3c57c7-dbba-4de8-b9e1-7b5a57f5bb48@github.com>
Message-ID: <rJlhuNozh7mXQtehkJONz_f8aAfuWB6Gex0OcPr9DXk=.b8b837d7-03df-44d6-b71f-b58d12e36b6a@github.com>

On Thu, 30 May 2024 10:02:25 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> Would it be possible to provide more context/background here? This is not code that is used during startup. Is there benchmark data to share for first use of java.io.IO ?

I think this was brought to the fore by https://openjdk.org/jeps/477 where running the example implicit main:

void main() {
    println("Hello, World!");
}

 .. brings in this code. This PR is one of several to try and smoothen a few rough edges that makes the startup of that quite a bit heavier than the baseline non-implicit Hello World.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19467#issuecomment-2139218517

From jlahoda at openjdk.org  Thu May 30 10:33:04 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Thu, 30 May 2024 10:33:04 GMT
Subject: RFR: 8333103: Re-examine the console provider loading
In-Reply-To: <M5dxmPs_RJJGqd344t3bMLPMiZmwdtxtbIVP9Bd-ons=.8c7525cc-e3a5-4ed5-81a6-e85398ee6ca6@github.com>
References: <M5dxmPs_RJJGqd344t3bMLPMiZmwdtxtbIVP9Bd-ons=.8c7525cc-e3a5-4ed5-81a6-e85398ee6ca6@github.com>
Message-ID: <9ARGdvwW5ae7Dg12yFpQ2iNpGtRRxjPwTrDkv5JApLc=.cc92629c-529c-4334-a00b-40b9ef1b1af3@github.com>

On Wed, 29 May 2024 19:51:36 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> There is an initialization code in `Console` class that searches for the Console implementations. Refactoring the init code not to use lambda/stream would reduce the (initial) number of loaded classes by about 100 for java.base implementations. This would become relevant when the java.io.IO (JEP 477) uses Console as the underlying framework.

Just to clarify a bit, this is only vaguely related to the implicitly declared classes. The actual issue is that having two programs:

public class SystemPrint {
    public static void main(String... args) {
        System.err.println("Hello!");
    }
}

and:

public class IOPrint {
    public static void main(String... args) {
        java.io.IO.println("Hello!");
    }
}

(note there are no implicitly declared classes, and no implicit imports in the samples), there is a considerable difference in the runtime of (compiled versions) of these classes. E.g. on my laptop:


$ time java -classpath /tmp SystemPrint 
Hello!

real    0m0,035s
user    0m0,019s
sys     0m0,019s

$ time java -classpath /tmp --enable-preview IOPrint 
Hello!

real    0m0,165s
user    0m0,324s
sys     0m0,042s


(Vast) majority of the time is spent in JLine initialization. There's https://bugs.openjdk.org/browse/JDK-8333086 for that, where the intent is to avoid initializing JLine for simple printing. There may be other opportunities to make JLine initialization faster in case we need to initialize it.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19467#issuecomment-2139255172

From liach at openjdk.org  Thu May 30 11:54:04 2024
From: liach at openjdk.org (Chen Liang)
Date: Thu, 30 May 2024 11:54:04 GMT
Subject: Integrated: 8332614: Type-checked ConstantPool.entryByIndex and
 ClassReader.readEntryOrNull
In-Reply-To: <UP8XpBov1w74UcUrAkD08x3vQGy_zRQ8NFRXuMU8us4=.3cce8ca0-742b-43f2-a282-894c7f61c969@github.com>
References: <UP8XpBov1w74UcUrAkD08x3vQGy_zRQ8NFRXuMU8us4=.3cce8ca0-742b-43f2-a282-894c7f61c969@github.com>
Message-ID: <d5GHDgTYVIE2GYkuIHFKyZxvtccXWiMvjxKRL8WlFTQ=.c14a33f0-7870-45b5-992a-433ec394ba1b@github.com>

On Tue, 21 May 2024 14:33:54 GMT, Chen Liang <liach at openjdk.org> wrote:

> I propose to add type-checked ConstantPool.entryByIndex and ClassReader.readEntryOrNull taking an extra Class parameter, which throws ConstantPoolException instead of ClassCastException on type mismatch, which can happen to malformed ClassFiles.
> 
> Requesting a review from @asotona. Thanks!
> 
> Proposal on mailing list: https://mail.openjdk.org/pipermail/classfile-api-dev/2024-May/000512.html

This pull request has now been integrated.

Changeset: f608918d
Author:    Chen Liang <liach at openjdk.org>
Committer: Adam Sotona <asotona at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/f608918df3f887277845db383cf07b0863bba615
Stats:     269 lines in 15 files changed: 179 ins; 39 del; 51 mod

8332614: Type-checked ConstantPool.entryByIndex and ClassReader.readEntryOrNull

Reviewed-by: asotona

-------------

PR: https://git.openjdk.org/jdk/pull/19330

From dl at openjdk.org  Thu May 30 12:13:33 2024
From: dl at openjdk.org (Doug Lea)
Date: Thu, 30 May 2024 12:13:33 GMT
Subject: RFR: 8322732: ForkJoinPool may underutilize cores in async mode
 [v11]
In-Reply-To: <xRyDMAsSZ7obqpr3Aoc5qrHqILeJMxFVCeiRdctMI3U=.d5d3cd56-32eb-4431-ac01-081822fc86c6@github.com>
References: <xRyDMAsSZ7obqpr3Aoc5qrHqILeJMxFVCeiRdctMI3U=.d5d3cd56-32eb-4431-ac01-081822fc86c6@github.com>
Message-ID: <LHvXvYYY18KbT0FhafK0RYrY1Z8v8rz-KmTehroyGv0=.01f72425-9002-4103-b482-6d2bd14d35e1@github.com>

> This set of changes address causes of poor utilization with small numbers of cores due to overly aggressive contention avoidance. A number of further adjustments were needed to still avoid most contention effects in deployments with large numbers of cores

Doug Lea has updated the pull request incrementally with one additional commit since the last revision:

  re-enable rescan; slim down test

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19131/files
  - new: https://git.openjdk.org/jdk/pull/19131/files/4564b92c..1b818b48

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19131&range=10
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19131&range=09-10

  Stats: 21 lines in 2 files changed: 10 ins; 6 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/19131.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19131/head:pull/19131

PR: https://git.openjdk.org/jdk/pull/19131

From jpai at openjdk.org  Thu May 30 12:19:12 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 30 May 2024 12:19:12 GMT
Subject: RFR: 8210471: GZIPInputStream constructor could leak an un-end()ed
 Inflater
Message-ID: <zugElcASx7a5x5uqkjArVCSH2zWDzsAFeJ9XB5FhXfE=.d5dbc5af-2af4-48cb-ba1b-724924de23f4@github.com>

Can I please get a review of this change which proposes to address the issue noted in https://bugs.openjdk.org/browse/JDK-8210471?

`java.util.zip.Inflater` when instantiated will hold on the native resources which are freed only when `Inflater.end()` is called. The constructor of `java.util.zip.GZIPInputStream` instantiates an `Inflater` for its internal use. After instantiating the `Inflater`, the `GZIPInputStream` constructor before returning from the constructor, can run into either a `IllegalArgumentException` (because the `size` is `<=0`) or an `IOException` when trying to read a GZIP header from the underlying `InputStream`. In either of these cases, the `Inflater` that the `GZIPInputStream` created internally will end up leaking and the caller has no way to `end()` that `Inflater` or even knowledge of that `Inflater`.

The commit in this PR catches the `IOException` when reading the GZIP header and `end()`s the `Inflater`. Furthermore, to prevent instantiation of an `Inflater`, the `GZIPInputStream` constructor before calling `super(...)` will now check the `InputStream` to be non-null and `size` to be `>0`, both of which were being done by the `super` constructor.

Given the nature of the change, no new test has been added. Existing tests in `test/jdk/java/util/zip` continue to pass and tier1, tier2 and tier3 testing is in progress.

-------------

Commit messages:
 - 8210471: GZIPInputStream constructor could leak an un-end()ed Inflater

Changes: https://git.openjdk.org/jdk/pull/19475/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19475&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8210471
  Stats: 23 lines in 1 file changed: 21 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/19475.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19475/head:pull/19475

PR: https://git.openjdk.org/jdk/pull/19475

From jpai at openjdk.org  Thu May 30 12:32:22 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 30 May 2024 12:32:22 GMT
Subject: RFR: 8210471: GZIPInputStream constructor could leak an un-end()ed
 Inflater [v2]
In-Reply-To: <zugElcASx7a5x5uqkjArVCSH2zWDzsAFeJ9XB5FhXfE=.d5dbc5af-2af4-48cb-ba1b-724924de23f4@github.com>
References: <zugElcASx7a5x5uqkjArVCSH2zWDzsAFeJ9XB5FhXfE=.d5dbc5af-2af4-48cb-ba1b-724924de23f4@github.com>
Message-ID: <oh3vme22_tGraiuVSHUwLdrmZQfuXWcgQN3F_4ksyuY=.7fee6023-66e5-4ea4-a3cb-8cbb6c124dc6@github.com>

> Can I please get a review of this change which proposes to address the issue noted in https://bugs.openjdk.org/browse/JDK-8210471?
> 
> `java.util.zip.Inflater` when instantiated will hold on the native resources which are freed only when `Inflater.end()` is called. The constructor of `java.util.zip.GZIPInputStream` instantiates an `Inflater` for its internal use. After instantiating the `Inflater`, the `GZIPInputStream` constructor before returning from the constructor, can run into either a `IllegalArgumentException` (because the `size` is `<=0`) or an `IOException` when trying to read a GZIP header from the underlying `InputStream`. In either of these cases, the `Inflater` that the `GZIPInputStream` created internally will end up leaking and the caller has no way to `end()` that `Inflater` or even knowledge of that `Inflater`.
> 
> The commit in this PR catches the `IOException` when reading the GZIP header and `end()`s the `Inflater`. Furthermore, to prevent instantiation of an `Inflater`, the `GZIPInputStream` constructor before calling `super(...)` will now check the `InputStream` to be non-null and `size` to be `>0`, both of which were being done by the `super` constructor.
> 
> Given the nature of the change, no new test has been added. Existing tests in `test/jdk/java/util/zip` continue to pass and tier1, tier2 and tier3 testing is in progress.

Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:

  introduce a basic test for GZIPInputStream

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19475/files
  - new: https://git.openjdk.org/jdk/pull/19475/files/8d565e11..3d079802

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19475&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19475&range=00-01

  Stats: 55 lines in 1 file changed: 55 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/19475.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19475/head:pull/19475

PR: https://git.openjdk.org/jdk/pull/19475

From jpai at openjdk.org  Thu May 30 12:40:01 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 30 May 2024 12:40:01 GMT
Subject: RFR: 8210471: GZIPInputStream constructor could leak an un-end()ed
 Inflater [v2]
In-Reply-To: <oh3vme22_tGraiuVSHUwLdrmZQfuXWcgQN3F_4ksyuY=.7fee6023-66e5-4ea4-a3cb-8cbb6c124dc6@github.com>
References: <zugElcASx7a5x5uqkjArVCSH2zWDzsAFeJ9XB5FhXfE=.d5dbc5af-2af4-48cb-ba1b-724924de23f4@github.com>
 <oh3vme22_tGraiuVSHUwLdrmZQfuXWcgQN3F_4ksyuY=.7fee6023-66e5-4ea4-a3cb-8cbb6c124dc6@github.com>
Message-ID: <9jz3_ALnN1-ZfbkfBzSGA1qFcuMhOxXAtatQ1hZC5cw=.d65a1ddb-2281-4e0a-a221-ec5b6e89f1d7@github.com>

On Thu, 30 May 2024 12:32:22 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change which proposes to address the issue noted in https://bugs.openjdk.org/browse/JDK-8210471?
>> 
>> `java.util.zip.Inflater` when instantiated will hold on the native resources which are freed only when `Inflater.end()` is called. The constructor of `java.util.zip.GZIPInputStream` instantiates an `Inflater` for its internal use. After instantiating the `Inflater`, the `GZIPInputStream` constructor before returning from the constructor, can run into either a `IllegalArgumentException` (because the `size` is `<=0`) or an `IOException` when trying to read a GZIP header from the underlying `InputStream`. In either of these cases, the `Inflater` that the `GZIPInputStream` created internally will end up leaking and the caller has no way to `end()` that `Inflater` or even knowledge of that `Inflater`.
>> 
>> The commit in this PR catches the `IOException` when reading the GZIP header and `end()`s the `Inflater`. Furthermore, to prevent instantiation of an `Inflater`, the `GZIPInputStream` constructor before calling `super(...)` will now check the `InputStream` to be non-null and `size` to be `>0`, both of which were being done by the `super` constructor.
>> 
>> Given the nature of the change, no new test has been added. Existing tests in `test/jdk/java/util/zip` continue to pass and tier1, tier2 and tier3 testing is in progress.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   introduce a basic test for GZIPInputStream

> Given the nature of the change, no new test has been added.

I noticed that the `GZIPInputStream` doesn't have any basic tests (at least) for its constructors, so I went ahead and added one which verifies the expected exceptions are thrown from the constructor.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19475#issuecomment-2139463615

From redestad at openjdk.org  Thu May 30 12:55:24 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Thu, 30 May 2024 12:55:24 GMT
Subject: RFR: 8333265: De-duplicate method references in
 java.util.stream.FindOps
Message-ID: <1oIB6hqDegMWORETDlXfVgb_xM405KYmoM1DCACMolk=.e2a1e506-77a0-403a-aeec-8d2edf2d73e2@github.com>

Extracting duplicate method references to static field reduce proxy class spinning and loading. In this case 2 less classes loaded when using `findAny()` on each type of stream.

-------------

Commit messages:
 - De-duplicate identical lambdas in FindOps

Changes: https://git.openjdk.org/jdk/pull/19477/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19477&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8333265
  Stats: 35 lines in 2 files changed: 17 ins; 7 del; 11 mod
  Patch: https://git.openjdk.org/jdk/pull/19477.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19477/head:pull/19477

PR: https://git.openjdk.org/jdk/pull/19477

From liach at openjdk.org  Thu May 30 13:07:01 2024
From: liach at openjdk.org (Chen Liang)
Date: Thu, 30 May 2024 13:07:01 GMT
Subject: RFR: 8333265: De-duplicate method references in
 java.util.stream.FindOps
In-Reply-To: <1oIB6hqDegMWORETDlXfVgb_xM405KYmoM1DCACMolk=.e2a1e506-77a0-403a-aeec-8d2edf2d73e2@github.com>
References: <1oIB6hqDegMWORETDlXfVgb_xM405KYmoM1DCACMolk=.e2a1e506-77a0-403a-aeec-8d2edf2d73e2@github.com>
Message-ID: <90dsQVmL8DhPftCRgAte_Pexq62nuS_59tPcyzg6eiM=.eef8a8a1-8a6d-4d9d-8191-4706ab3b30ee@github.com>

On Thu, 30 May 2024 12:50:36 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> Extracting duplicate method references to static field reduce proxy class spinning and loading. In this case 2 less classes loaded when using `findAny()` on each type of stream.

Should we extract them to private static utility methods for potential laziness support in the future?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19477#issuecomment-2139514424

From sgibbons at openjdk.org  Thu May 30 13:19:57 2024
From: sgibbons at openjdk.org (Scott Gibbons)
Date: Thu, 30 May 2024 13:19:57 GMT
Subject: RFR: 8320448: Accelerate IndexOf using AVX2 [v49]
In-Reply-To: <uWi4QxH31hL93771gkl_GgvP0m84IRSoR_1Yi8hD17E=.bc6ed458-7081-4c3f-9348-f59358fa05a4@github.com>
References: <uWi4QxH31hL93771gkl_GgvP0m84IRSoR_1Yi8hD17E=.bc6ed458-7081-4c3f-9348-f59358fa05a4@github.com>
Message-ID: <9PIuILHZnLHrZf1sz0Dsq6iup6qgyXw50mD0nGVS04c=.63bd0afd-d818-46fa-a082-a3d2066829cd@github.com>

> Re-write the IndexOf code without the use of the pcmpestri instruction, only using AVX2 instructions.  This change accelerates String.IndexOf on average 1.3x for AVX2.  The benchmark numbers:
> 
> 
> Benchmark	                                               Score		Latest		
> StringIndexOf.advancedWithMediumSub   343.573		317.934		0.925375393x
> StringIndexOf.advancedWithShortSub1	  1039.081		1053.96		1.014319384x
> StringIndexOf.advancedWithShortSub2	      55.828		110.541		1.980027943x
> StringIndexOf.constantPattern	                9.361		11.906		1.271872663x
> StringIndexOf.searchCharLongSuccess	        4.216		4.218		1.000474383x
> StringIndexOf.searchCharMediumSuccess	3.133		3.216		1.02649218x
> StringIndexOf.searchCharShortSuccess	3.76		        3.761		1.000265957x
> StringIndexOf.success	                                9.186		9.713		1.057369911x
> StringIndexOf.successBig	                      14.341		46.343		3.231504079x
> StringIndexOfChar.latin1_AVX2_String	  6220.918		12154.52		1.953814533x
> StringIndexOfChar.latin1_AVX2_char	  5503.556		5540.044		1.006629895x
> StringIndexOfChar.latin1_SSE4_String	  6978.854		6818.689		0.977049957x
> StringIndexOfChar.latin1_SSE4_char	  5657.499		5474.624		0.967675646x
> StringIndexOfChar.latin1_Short_String	  7132.541		6863.359		0.962260014x
> StringIndexOfChar.latin1_Short_char	16013.389	      16162.437		1.009307711x
> StringIndexOfChar.latin1_mixed_String	  7386.123	      14771.622		1.999915517x
> StringIndexOfChar.latin1_mixed_char	  9901.671		9782.245		0.987938803

Scott Gibbons has updated the pull request incrementally with two additional commits since the last revision:

 - Stupid EOL at end
 - Add @test block; fix test indentation

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/16753/files
  - new: https://git.openjdk.org/jdk/pull/16753/files/ed06edd6..3e150fe3

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16753&range=48
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16753&range=47-48

  Stats: 166 lines in 2 files changed: 7 ins; 0 del; 159 mod
  Patch: https://git.openjdk.org/jdk/pull/16753.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16753/head:pull/16753

PR: https://git.openjdk.org/jdk/pull/16753

From sgibbons at openjdk.org  Thu May 30 13:20:01 2024
From: sgibbons at openjdk.org (Scott Gibbons)
Date: Thu, 30 May 2024 13:20:01 GMT
Subject: RFR: 8320448: Accelerate IndexOf using AVX2 [v48]
In-Reply-To: <_0H1QRaXnFyO9eGa7IvO1l4ZzNK_27D59ebYAphp8eg=.0fe38944-0b61-4a1a-b63d-04315b02117f@github.com>
References: <uWi4QxH31hL93771gkl_GgvP0m84IRSoR_1Yi8hD17E=.bc6ed458-7081-4c3f-9348-f59358fa05a4@github.com>
 <jJHpKyrD7KBeyP2gEh_CfKKNv2YM8hLccPuG6N9S1JU=.77539396-e5ac-4334-8f2c-a9a1ed5bc478@github.com>
 <dp-Dou__skj5A-nyS74949VYGO15gA6SKiCfXC1D6SQ=.3c118c11-0c9c-49d1-a514-d4ffe756f01c@github.com>
 <_0H1QRaXnFyO9eGa7IvO1l4ZzNK_27D59ebYAphp8eg=.0fe38944-0b61-4a1a-b63d-04315b02117f@github.com>
Message-ID: <aq30UnpubKb1usw62f3WV1le6r1Y1NzbsOpe4Sd2PjA=.e8ebfc39-2245-4e09-90da-5ce92f321dc4@github.com>

On Thu, 30 May 2024 06:22:17 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

>> test/jdk/java/lang/StringBuffer/ECoreIndexOf.java line 29:
>> 
>>> 27:  * @requires vm.cpu.features ~= ".*avx2.*"
>>> 28:  * @requires vm.compiler2.enabled
>>> 29:  * @run main/othervm -XX:+UnlockDiagnosticVMOptions -XX:+EnableX86ECoreOpts -XX:UseAVX=2 -Xbatch -XX:-TieredCompilation -XX:CompileCommand=dontinline,ECoreIndexOf.indexOfKernel ECoreIndexOf
>> 
>> Does this test really need to be `avx2` specific? Does it even need to be C2 specific?
>> Or can this run on all platforms?
>
> Would be a shame to spend so much time on writing a test and then not apply it everywhere ;)

I'll add a separate @test block to this file.  It was, however, written specifically tuned for the new algorithm to exercise known edge cases.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1620676513

From sgibbons at openjdk.org  Thu May 30 13:19:59 2024
From: sgibbons at openjdk.org (Scott Gibbons)
Date: Thu, 30 May 2024 13:19:59 GMT
Subject: RFR: 8320448: Accelerate IndexOf using AVX2 [v48]
In-Reply-To: <dp-Dou__skj5A-nyS74949VYGO15gA6SKiCfXC1D6SQ=.3c118c11-0c9c-49d1-a514-d4ffe756f01c@github.com>
References: <uWi4QxH31hL93771gkl_GgvP0m84IRSoR_1Yi8hD17E=.bc6ed458-7081-4c3f-9348-f59358fa05a4@github.com>
 <jJHpKyrD7KBeyP2gEh_CfKKNv2YM8hLccPuG6N9S1JU=.77539396-e5ac-4334-8f2c-a9a1ed5bc478@github.com>
 <dp-Dou__skj5A-nyS74949VYGO15gA6SKiCfXC1D6SQ=.3c118c11-0c9c-49d1-a514-d4ffe756f01c@github.com>
Message-ID: <IBEfcEX9FdY2lvaYmdtuTCFu9qWb9m38WkgPAzNhqn8=.11e5bd1a-784f-4bc1-aa86-45abec6e59d0@github.com>

On Thu, 30 May 2024 06:23:05 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

>> Scott Gibbons has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove duplicate vm.compiler2.enabled
>
> test/jdk/java/lang/String/IndexOf.java line 35:
> 
>> 33:  * @requires vm.cpu.features ~= ".*avx2.*"
>> 34:  * @requires vm.compiler2.enabled
>> 35:  * @run main/othervm -XX:+IgnoreUnrecognizedVMOptions -Xcomp -XX:-TieredCompilation -XX:UseAVX=2 -XX:+UnlockDiagnosticVMOptions -XX:+EnableX86ECoreOpts IndexOf
> 
> Same here: why is the test AVX2 specific? Could other platforms not also be "tickled" in interesting ways with this test?

There are two test blocks, so all platforms will be able to take advantage of the test via the first block.  I'm told that's how this works.

> test/jdk/java/lang/StringBuffer/IndexOf.java line 188:
> 
>> 186:      }
>> 187: 
>> 188:  }
> 
> It looks like you just indented basically the whole file by 1 space. Why?

I hadn't noticed this.  It's most likely an artifact of my editor as it wasn't intentional.  I'll change this back.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1620669257
PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1620679629

From egahlin at openjdk.org  Thu May 30 13:36:13 2024
From: egahlin at openjdk.org (Erik Gahlin)
Date: Thu, 30 May 2024 13:36:13 GMT
Subject: Integrated: 8331876: JFR: Move file read and write events to java.base
In-Reply-To: <DDe0bKCC86AawVl7RylZ74uvvLBr2Zljpkcmxx1_WEU=.61cc10c6-b635-42dd-a850-b32ae1d68585@github.com>
References: <DDe0bKCC86AawVl7RylZ74uvvLBr2Zljpkcmxx1_WEU=.61cc10c6-b635-42dd-a850-b32ae1d68585@github.com>
Message-ID: <j8p4W4TGu9hHyr290VE3drycFtzqbjGSScNk1_HjziM=.a4590e7c-d6a4-4b24-84f7-e6345af13cc4@github.com>

On Tue, 7 May 2024 19:32:57 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> Hi,
> 
> Could I have a review of a change that moves the jdk.FileRead and jdk.FileWrite events to java.base to remove the use of the ASM instrumentation.
> 
> Testing: jdk/jdk/jfr, tier1-tier4
> 
> Thanks
> Erik

This pull request has now been integrated.

Changeset: 4a20691e
Author:    Erik Gahlin <egahlin at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/4a20691e9b0276e2dc5e7eb6a4d05393d6b4c99c
Stats:     1438 lines in 22 files changed: 651 ins; 762 del; 25 mod

8331876: JFR: Move file read and write events to java.base

Reviewed-by: mgronlun, alanb

-------------

PR: https://git.openjdk.org/jdk/pull/19129

From sgibbons at openjdk.org  Thu May 30 13:36:18 2024
From: sgibbons at openjdk.org (Scott Gibbons)
Date: Thu, 30 May 2024 13:36:18 GMT
Subject: RFR: 8320448: Accelerate IndexOf using AVX2 [v48]
In-Reply-To: <bF4gn-6TzP7hCsTzUuaJrsEGaX-5aqbimI30E2b3Du8=.999e585e-0bee-459a-b78f-8ed6668cb32b@github.com>
References: <uWi4QxH31hL93771gkl_GgvP0m84IRSoR_1Yi8hD17E=.bc6ed458-7081-4c3f-9348-f59358fa05a4@github.com>
 <jJHpKyrD7KBeyP2gEh_CfKKNv2YM8hLccPuG6N9S1JU=.77539396-e5ac-4334-8f2c-a9a1ed5bc478@github.com>
 <bF4gn-6TzP7hCsTzUuaJrsEGaX-5aqbimI30E2b3Du8=.999e585e-0bee-459a-b78f-8ed6668cb32b@github.com>
Message-ID: <hkI625ksfSHj5w-RmwS4b6tgLBV9gh-MbOKYEXZG_qQ=.9e0c631a-578d-4534-83de-cdfd53f248b8@github.com>

On Thu, 30 May 2024 06:25:32 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

>> Scott Gibbons has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove duplicate vm.compiler2.enabled
>
> Control question: Are we confident with this potentially going into JDK 23 or should we rather postpone to JDK 24? The fork is next week.

Thank you all for the comments.  @TobiHartmann I'm comfortable with this going into JDK 23.  The code has been functionally stable for me for the past 2 months.  The recent churn centers primarily around restructuring the code for readability and maintainability and ensuring protection against reading past the end of strings.  Both Vlad (Volodymyr) and @sviswa7 have scoured the code with me and together we have convinced ourselves that we've covered all the bases.  Of course we may have missed something but my confidence is high.

The overall performance gain as reported by the StringIndexOf JMH averages ~7x running on an e-core as compared with baseline on the same core.  It's skewed somewhat towards massive gains for long (~2K) strings (avg 14.4x) and modest gains for small-ish strings (avg ~1.8x).  I've measured up to 60x performance improvement for some 2K UTF-16 indexOf operations.

Again, thank you all.  It's been a fun exercise and I've learned a lot.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/16753#issuecomment-2139569361

From redestad at openjdk.org  Thu May 30 13:40:01 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Thu, 30 May 2024 13:40:01 GMT
Subject: RFR: 8333265: De-duplicate method references in
 java.util.stream.FindOps
In-Reply-To: <90dsQVmL8DhPftCRgAte_Pexq62nuS_59tPcyzg6eiM=.eef8a8a1-8a6d-4d9d-8191-4706ab3b30ee@github.com>
References: <1oIB6hqDegMWORETDlXfVgb_xM405KYmoM1DCACMolk=.e2a1e506-77a0-403a-aeec-8d2edf2d73e2@github.com>
 <90dsQVmL8DhPftCRgAte_Pexq62nuS_59tPcyzg6eiM=.eef8a8a1-8a6d-4d9d-8191-4706ab3b30ee@github.com>
Message-ID: <rRvESzUUkc2maHxBivVHxn4-N1Xo8FcX7nAQf152rUU=.14791467-47ca-4e88-9a9b-2004d85be494@github.com>

On Thu, 30 May 2024 13:04:46 GMT, Chen Liang <liach at openjdk.org> wrote:

> Should we extract them to private static utility methods for potential laziness support in the future?

Ideally we shouldn't have to do any of this. I thought such method references were already de-duplicated in javac - at least within the same compilation units - but I saw this in a startup profile and was surprised myself that the demonstrated manual de-duplication has an observable effect.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19477#issuecomment-2139576911

From liach at openjdk.org  Thu May 30 13:53:03 2024
From: liach at openjdk.org (Chen Liang)
Date: Thu, 30 May 2024 13:53:03 GMT
Subject: RFR: 8333265: De-duplicate method references in
 java.util.stream.FindOps
In-Reply-To: <1oIB6hqDegMWORETDlXfVgb_xM405KYmoM1DCACMolk=.e2a1e506-77a0-403a-aeec-8d2edf2d73e2@github.com>
References: <1oIB6hqDegMWORETDlXfVgb_xM405KYmoM1DCACMolk=.e2a1e506-77a0-403a-aeec-8d2edf2d73e2@github.com>
Message-ID: <PXZDg9ntMqtvnR-wvPR9xJl5P0sRaRAYEQFCBoh4MR8=.e03bbb89-2fb1-4fe7-a369-738fde9c183c@github.com>

On Thu, 30 May 2024 12:50:36 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> Extracting duplicate method references to static field reduce proxy class spinning and loading. In this case 2 less classes loaded when using `findAny()` on each type of stream.

Marked as reviewed by liach (Author).

Indeed, CallSites are created per indy instruction instead of per CP indy entry (required by JVMS); thus sharing instruction either in initializers or static methods would have the same effect. javac only deduplicates the CP entry.

-------------

PR Review: https://git.openjdk.org/jdk/pull/19477#pullrequestreview-2088345919
PR Comment: https://git.openjdk.org/jdk/pull/19477#issuecomment-2139602569

From jlahoda at openjdk.org  Thu May 30 13:55:14 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Thu, 30 May 2024 13:55:14 GMT
Subject: RFR: 8333086: Using Console.println is unnecessarily slow due to JLine
 initalization
Message-ID: <H9mNqL67B1jUNevUVidObx5gBGJEKYqolrR_OABapDQ=.be099164-4d6c-4d1d-ab6b-20d7b41fab76@github.com>

Consider these two programs:


public class SystemPrint {
    public static void main(String... args) {
        System.err.println("Hello!");
    }
}

and:

public class IOPrint {
    public static void main(String... args) {
        java.io.IO.println("Hello!");
    }
}


They do the same conceptual thing - write a text to the output. But, `IO.println` delegates to `Console.println`, which then delegates to a `Console` backend, and the default backend is currently based on JLine.

The issues is that JLine takes a quite a long time to initialize, and in a program like this, JLine is not really needed - it is used to provide better editing experience when reading input, but there's no reading in these programs.

For example, on my computer:

$ time java -classpath /tmp SystemPrint 
Hello!

real    0m0,035s
user    0m0,019s
sys     0m0,019s

$ time java -classpath /tmp --enable-preview IOPrint 
Hello!

real    0m0,165s
user    0m0,324s
sys     0m0,042s


The proposal herein is to delegate to the simpler `Console` backend from `java.base` as long as the user only uses methods that print to output, and switch to the JLine delegate when other methods (typically input) is used. Note that while technically `writer()` is a method doing output, it will force JLine initialization to avoid possible problems if the client caches the writer and uses it after switching the delegates.

With this patch, I can get timing like this:

$ time java --enable-preview -classpath /tmp/ IOPrint 
Hello!

real    0m0,051s
user    0m0,038s
sys     0m0,020s


which seems much more acceptable.

There is also #19467, which may reduce the time further.

A future work might focus on making JLine initialize faster, but avoiding JLine initialization in case where we don't need it seems like a good step to me in any case.

-------------

Commit messages:
 - Cleanup, addint test.
 - Using println correctly, flushing the java.base delegate before switching to JLine.
 - Force Terminal when writer is requested.
 - Attempting to speedup start by delaying initialization of JLine until really necessary.

Changes: https://git.openjdk.org/jdk/pull/19479/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19479&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8333086
  Stats: 225 lines in 2 files changed: 212 ins; 1 del; 12 mod
  Patch: https://git.openjdk.org/jdk/pull/19479.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19479/head:pull/19479

PR: https://git.openjdk.org/jdk/pull/19479

From epeter at openjdk.org  Thu May 30 13:59:15 2024
From: epeter at openjdk.org (Emanuel Peter)
Date: Thu, 30 May 2024 13:59:15 GMT
Subject: RFR: 8320448: Accelerate IndexOf using AVX2 [v48]
In-Reply-To: <hkI625ksfSHj5w-RmwS4b6tgLBV9gh-MbOKYEXZG_qQ=.9e0c631a-578d-4534-83de-cdfd53f248b8@github.com>
References: <uWi4QxH31hL93771gkl_GgvP0m84IRSoR_1Yi8hD17E=.bc6ed458-7081-4c3f-9348-f59358fa05a4@github.com>
 <jJHpKyrD7KBeyP2gEh_CfKKNv2YM8hLccPuG6N9S1JU=.77539396-e5ac-4334-8f2c-a9a1ed5bc478@github.com>
 <bF4gn-6TzP7hCsTzUuaJrsEGaX-5aqbimI30E2b3Du8=.999e585e-0bee-459a-b78f-8ed6668cb32b@github.com>
 <hkI625ksfSHj5w-RmwS4b6tgLBV9gh-MbOKYEXZG_qQ=.9e0c631a-578d-4534-83de-cdfd53f248b8@github.com>
Message-ID: <yhivPR-B9j7opXjunx8aQusBsDIvDUiAldkq1be36X0=.6d6611f2-2c98-40fc-b4d7-54bd1cf9a9c5@github.com>

On Thu, 30 May 2024 13:33:40 GMT, Scott Gibbons <sgibbons at openjdk.org> wrote:

>> Control question: Are we confident with this potentially going into JDK 23 or should we rather postpone to JDK 24? The fork is next week.
>
> Thank you all for the comments.  @TobiHartmann I'm comfortable with this going into JDK 23.  The code has been functionally stable for me for the past 2 months.  The recent churn centers primarily around restructuring the code for readability and maintainability and ensuring protection against reading past the end of strings.  Both Vlad (Volodymyr) and @sviswa7 have scoured the code with me and together we have convinced ourselves that we've covered all the bases.  Of course we may have missed something but my confidence is high.
> 
> The overall performance gain as reported by the StringIndexOf JMH averages ~7x running on an e-core as compared with baseline on the same core.  It's skewed somewhat towards massive gains for long (~2K) strings (avg 14.4x) and modest gains for small-ish strings (avg ~1.8x).  I've measured up to 60x performance improvement for some 2K UTF-16 indexOf operations.
> 
> Again, thank you all.  It's been a fun exercise and I've learned a lot.

@asgibbons generally it would be nice if you waited for me to accept your changes before integrating.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/16753#issuecomment-2139604424

From epeter at openjdk.org  Thu May 30 13:59:19 2024
From: epeter at openjdk.org (Emanuel Peter)
Date: Thu, 30 May 2024 13:59:19 GMT
Subject: RFR: 8320448: Accelerate IndexOf using AVX2 [v48]
In-Reply-To: <aq30UnpubKb1usw62f3WV1le6r1Y1NzbsOpe4Sd2PjA=.e8ebfc39-2245-4e09-90da-5ce92f321dc4@github.com>
References: <uWi4QxH31hL93771gkl_GgvP0m84IRSoR_1Yi8hD17E=.bc6ed458-7081-4c3f-9348-f59358fa05a4@github.com>
 <jJHpKyrD7KBeyP2gEh_CfKKNv2YM8hLccPuG6N9S1JU=.77539396-e5ac-4334-8f2c-a9a1ed5bc478@github.com>
 <dp-Dou__skj5A-nyS74949VYGO15gA6SKiCfXC1D6SQ=.3c118c11-0c9c-49d1-a514-d4ffe756f01c@github.com>
 <_0H1QRaXnFyO9eGa7IvO1l4ZzNK_27D59ebYAphp8eg=.0fe38944-0b61-4a1a-b63d-04315b02117f@github.com>
 <aq30UnpubKb1usw62f3WV1le6r1Y1NzbsOpe4Sd2PjA=.e8ebfc39-2245-4e09-90da-5ce92f321dc4@github.com>
Message-ID: <hOhkJjv32sEQ2uDY6i6AMKI4BSn39a_klRAAMTq4rQk=.8a85d55e-951e-49f8-b965-067fe8d12973@github.com>

On Thu, 30 May 2024 13:03:06 GMT, Scott Gibbons <sgibbons at openjdk.org> wrote:

>> Would be a shame to spend so much time on writing a test and then not apply it everywhere ;)
>
> I'll add a separate @test block to this file.  It was, however, written specifically tuned for the new algorithm to exercise known edge cases.

A new `@test` sounds like a good idea

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1620747402

From epeter at openjdk.org  Thu May 30 13:59:19 2024
From: epeter at openjdk.org (Emanuel Peter)
Date: Thu, 30 May 2024 13:59:19 GMT
Subject: RFR: 8320448: Accelerate IndexOf using AVX2 [v48]
In-Reply-To: <IBEfcEX9FdY2lvaYmdtuTCFu9qWb9m38WkgPAzNhqn8=.11e5bd1a-784f-4bc1-aa86-45abec6e59d0@github.com>
References: <uWi4QxH31hL93771gkl_GgvP0m84IRSoR_1Yi8hD17E=.bc6ed458-7081-4c3f-9348-f59358fa05a4@github.com>
 <jJHpKyrD7KBeyP2gEh_CfKKNv2YM8hLccPuG6N9S1JU=.77539396-e5ac-4334-8f2c-a9a1ed5bc478@github.com>
 <dp-Dou__skj5A-nyS74949VYGO15gA6SKiCfXC1D6SQ=.3c118c11-0c9c-49d1-a514-d4ffe756f01c@github.com>
 <IBEfcEX9FdY2lvaYmdtuTCFu9qWb9m38WkgPAzNhqn8=.11e5bd1a-784f-4bc1-aa86-45abec6e59d0@github.com>
Message-ID: <raBzIHoEKv0oXXIJ-l-h4P_KPf6NA7I7TyaaDssg_uw=.7c53e5b4-82d1-4647-9cec-5620bb0c49e5@github.com>

On Thu, 30 May 2024 12:58:27 GMT, Scott Gibbons <sgibbons at openjdk.org> wrote:

>> test/jdk/java/lang/String/IndexOf.java line 35:
>> 
>>> 33:  * @requires vm.cpu.features ~= ".*avx2.*"
>>> 34:  * @requires vm.compiler2.enabled
>>> 35:  * @run main/othervm -XX:+IgnoreUnrecognizedVMOptions -Xcomp -XX:-TieredCompilation -XX:UseAVX=2 -XX:+UnlockDiagnosticVMOptions -XX:+EnableX86ECoreOpts IndexOf
>> 
>> Same here: why is the test AVX2 specific? Could other platforms not also be "tickled" in interesting ways with this test?
>
> There are two test blocks, so all platforms will be able to take advantage of the test via the first block.  I'm told that's how this works.

Yes, that is right. Good.

>> test/jdk/java/lang/StringBuffer/IndexOf.java line 188:
>> 
>>> 186:      }
>>> 187: 
>>> 188:  }
>> 
>> It looks like you just indented basically the whole file by 1 space. Why?
>
> I hadn't noticed this.  It's most likely an artifact of my editor as it wasn't intentional.  I'll change this back.

Ok, maybe check your code on GitHub next time ;)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1620768228
PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1620746147

From epeter at openjdk.org  Thu May 30 13:59:15 2024
From: epeter at openjdk.org (Emanuel Peter)
Date: Thu, 30 May 2024 13:59:15 GMT
Subject: RFR: 8320448: Accelerate IndexOf using AVX2 [v48]
In-Reply-To: <bF4gn-6TzP7hCsTzUuaJrsEGaX-5aqbimI30E2b3Du8=.999e585e-0bee-459a-b78f-8ed6668cb32b@github.com>
References: <uWi4QxH31hL93771gkl_GgvP0m84IRSoR_1Yi8hD17E=.bc6ed458-7081-4c3f-9348-f59358fa05a4@github.com>
 <jJHpKyrD7KBeyP2gEh_CfKKNv2YM8hLccPuG6N9S1JU=.77539396-e5ac-4334-8f2c-a9a1ed5bc478@github.com>
 <bF4gn-6TzP7hCsTzUuaJrsEGaX-5aqbimI30E2b3Du8=.999e585e-0bee-459a-b78f-8ed6668cb32b@github.com>
Message-ID: <_4hKqcW7tE4shxVqG8Et3BjeehNjl0NWvS7PCKZaLe0=.73dc8315-22ee-47c0-8f5b-be74edc2f7a3@github.com>

On Thu, 30 May 2024 06:25:32 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> Control question: Are we confident with this potentially going into JDK 23 or should we rather postpone to JDK 24? The fork is next week.

I would hold off. @asgibbons it may pass our tests, and your extensive testing. But you never know what the fuzzer can find over a few weeks once it runs with your changes. I have made that experience many times. Let's just give it a few days, and then we have one JDK version less to worry about for backports on possible follow-up bugs ;)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/16753#issuecomment-2139615822

From epeter at openjdk.org  Thu May 30 13:59:18 2024
From: epeter at openjdk.org (Emanuel Peter)
Date: Thu, 30 May 2024 13:59:18 GMT
Subject: RFR: 8320448: Accelerate IndexOf using AVX2 [v49]
In-Reply-To: <9PIuILHZnLHrZf1sz0Dsq6iup6qgyXw50mD0nGVS04c=.63bd0afd-d818-46fa-a082-a3d2066829cd@github.com>
References: <uWi4QxH31hL93771gkl_GgvP0m84IRSoR_1Yi8hD17E=.bc6ed458-7081-4c3f-9348-f59358fa05a4@github.com>
 <9PIuILHZnLHrZf1sz0Dsq6iup6qgyXw50mD0nGVS04c=.63bd0afd-d818-46fa-a082-a3d2066829cd@github.com>
Message-ID: <NDAt69tQ4Ni4t1pCE11IiOPz7IXpdqaTHI_Mj9Z7KLA=.6d790280-a2ff-4634-b626-c7663a7815f4@github.com>

On Thu, 30 May 2024 13:19:57 GMT, Scott Gibbons <sgibbons at openjdk.org> wrote:

>> Re-write the IndexOf code without the use of the pcmpestri instruction, only using AVX2 instructions.  This change accelerates String.IndexOf on average 1.3x for AVX2.  The benchmark numbers:
>> 
>> 
>> Benchmark	                                               Score		Latest		
>> StringIndexOf.advancedWithMediumSub   343.573		317.934		0.925375393x
>> StringIndexOf.advancedWithShortSub1	  1039.081		1053.96		1.014319384x
>> StringIndexOf.advancedWithShortSub2	      55.828		110.541		1.980027943x
>> StringIndexOf.constantPattern	                9.361		11.906		1.271872663x
>> StringIndexOf.searchCharLongSuccess	        4.216		4.218		1.000474383x
>> StringIndexOf.searchCharMediumSuccess	3.133		3.216		1.02649218x
>> StringIndexOf.searchCharShortSuccess	3.76		        3.761		1.000265957x
>> StringIndexOf.success	                                9.186		9.713		1.057369911x
>> StringIndexOf.successBig	                      14.341		46.343		3.231504079x
>> StringIndexOfChar.latin1_AVX2_String	  6220.918		12154.52		1.953814533x
>> StringIndexOfChar.latin1_AVX2_char	  5503.556		5540.044		1.006629895x
>> StringIndexOfChar.latin1_SSE4_String	  6978.854		6818.689		0.977049957x
>> StringIndexOfChar.latin1_SSE4_char	  5657.499		5474.624		0.967675646x
>> StringIndexOfChar.latin1_Short_String	  7132.541		6863.359		0.962260014x
>> StringIndexOfChar.latin1_Short_char	16013.389	      16162.437		1.009307711x
>> StringIndexOfChar.latin1_mixed_String	  7386.123	      14771.622		1.999915517x
>> StringIndexOfChar.latin1_mixed_char	  9901.671		9782.245		0.987938803
>
> Scott Gibbons has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Stupid EOL at end
>  - Add @test block; fix test indentation

test/jdk/java/lang/String/IndexOf.java line 25:

> 23: 
> 24: /*
> 25:  * @test

You should add the `@bug 8320448` for all runs.

test/jdk/java/lang/String/IndexOf.java line 27:

> 25:  * @test
> 26:  * @summary test String indexOf() intrinsic
> 27:  * @run main/othervm IndexOf

Suggestion:

 * @run main IndexOf

You do not need a new VM if you have no arguments ;)

test/jdk/java/lang/StringBuffer/ECoreIndexOf.java line 25:

> 23: 
> 24: /* @test
> 25:  * @bug 4162796 4162796

You need to fix the bug numbers.

test/jdk/java/lang/StringBuffer/ECoreIndexOf.java line 27:

> 25:  * @bug 4162796 4162796
> 26:  * @summary Test indexOf and lastIndexOf
> 27:  * @run main/othervm -Xbatch -XX:-TieredCompilation -XX:CompileCommand=dontinline,ECoreIndexOf.indexOfKernel ECoreIndexOf

I would also add a line without `-XX:-TieredCompilation`, then C1 can be tested with this too

test/jdk/java/lang/StringBuffer/ECoreIndexOf.java line 32:

> 30: 
> 31: /* @test
> 32:  * @bug 4162796 4162796

Here too

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1620760730
PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1620756896
PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1620753321
PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1620754948
PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1620753577

From forax at openjdk.org  Thu May 30 14:13:01 2024
From: forax at openjdk.org (=?UTF-8?B?UsOpbWk=?= Forax)
Date: Thu, 30 May 2024 14:13:01 GMT
Subject: RFR: 8333265: De-duplicate method references in
 java.util.stream.FindOps
In-Reply-To: <1oIB6hqDegMWORETDlXfVgb_xM405KYmoM1DCACMolk=.e2a1e506-77a0-403a-aeec-8d2edf2d73e2@github.com>
References: <1oIB6hqDegMWORETDlXfVgb_xM405KYmoM1DCACMolk=.e2a1e506-77a0-403a-aeec-8d2edf2d73e2@github.com>
Message-ID: <WTDemLGDQ_H7b9Hvj8syn-As0AZdOp4QeiT0tUEaZT8=.514088fa-9727-441d-b142-8f4ba32a9045@github.com>

On Thu, 30 May 2024 12:50:36 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> Extracting duplicate method references to static field reduce proxy class spinning and loading. In this case 2 less classes loaded when using `findAny()` on each type of stream.

For constant method reference, the solution is to use a constant dynamic instead of an invokedynamic.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19477#issuecomment-2139645936

From dl at openjdk.org  Thu May 30 14:18:32 2024
From: dl at openjdk.org (Doug Lea)
Date: Thu, 30 May 2024 14:18:32 GMT
Subject: RFR: 8322732: ForkJoinPool may underutilize cores in async mode
 [v12]
In-Reply-To: <xRyDMAsSZ7obqpr3Aoc5qrHqILeJMxFVCeiRdctMI3U=.d5d3cd56-32eb-4431-ac01-081822fc86c6@github.com>
References: <xRyDMAsSZ7obqpr3Aoc5qrHqILeJMxFVCeiRdctMI3U=.d5d3cd56-32eb-4431-ac01-081822fc86c6@github.com>
Message-ID: <ok_Uf8j2tQK5iy1v2Ympt0YyrsrjhC-O7wJ1P_eiLsc=.868e56ae-5c79-4c27-a315-da29d01a1af0@github.com>

> This set of changes address causes of poor utilization with small numbers of cores due to overly aggressive contention avoidance. A number of further adjustments were needed to still avoid most contention effects in deployments with large numbers of cores

Doug Lea has updated the pull request incrementally with one additional commit since the last revision:

  Don't shadow parks

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19131/files
  - new: https://git.openjdk.org/jdk/pull/19131/files/1b818b48..b13d8ee1

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19131&range=11
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19131&range=10-11

  Stats: 19 lines in 1 file changed: 5 ins; 9 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/19131.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19131/head:pull/19131

PR: https://git.openjdk.org/jdk/pull/19131

From mcimadamore at openjdk.org  Thu May 30 14:26:04 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 30 May 2024 14:26:04 GMT
Subject: RFR: 8331189: Implementation of Scoped Values (Third Preview) [v2]
In-Reply-To: <Fgp7pXQcC722WTqX5RWGKMhSji4d_bIAPwlL_jZP3kg=.032a5aaa-3f9a-4d79-ad12-b8f4a22d6ea1@github.com>
References: <kFWNL6QScozy3Z7CHuifpZgaobVm5ypn8dhNWiBebt4=.c47076f2-8a76-4bf1-b17d-5b50a0c9bb2f@github.com>
 <Fgp7pXQcC722WTqX5RWGKMhSji4d_bIAPwlL_jZP3kg=.032a5aaa-3f9a-4d79-ad12-b8f4a22d6ea1@github.com>
Message-ID: <jTdYyOYJcD1etVy1jAx1XwJlH9_t2Hc4NwMI0s0xr-U=.6f0691a2-af87-4c06-85af-55ac66e8b674@github.com>

On Wed, 29 May 2024 15:35:41 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> JEP 481 proposes Scoped Values to continue to preview in JDK 23 with one change. The type of the operation parameter of the callWhere method is changed to a new functional interface to avoid having the API throw Exception. With that change, the getWhere (and the corresponding method on Carrier) are no longer needed. The functional interface is not proposed for j.u.function at this time.
>
> Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision:
> 
>  - Merge
>  - Merge
>  - Merge
>  - Set JEP number
>  - Sync up from loom repo
>  - Merge
>  - Initial commit

Changes look good. I like how the new functional interface makes the API seem smaller.

-------------

Marked as reviewed by mcimadamore (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19136#pullrequestreview-2088433436

From redestad at openjdk.org  Thu May 30 14:33:01 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Thu, 30 May 2024 14:33:01 GMT
Subject: RFR: 8333265: De-duplicate method references in
 java.util.stream.FindOps
In-Reply-To: <1oIB6hqDegMWORETDlXfVgb_xM405KYmoM1DCACMolk=.e2a1e506-77a0-403a-aeec-8d2edf2d73e2@github.com>
References: <1oIB6hqDegMWORETDlXfVgb_xM405KYmoM1DCACMolk=.e2a1e506-77a0-403a-aeec-8d2edf2d73e2@github.com>
Message-ID: <26eXu5xMOFQ-eKF6qsul6TAEKj3aEWUlfa0-NHSpYKg=.13b01305-cf1a-4653-956c-4b8eaf346afb@github.com>

On Thu, 30 May 2024 12:50:36 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> Extracting duplicate method references to static field reduce proxy class spinning and loading. In this case 2 less classes loaded when using `findAny()` on each type of stream.

Vicente filed a bug on javac to investigate this: https://bugs.openjdk.org/browse/JDK-8333278

I wouldn't mind using condy for constant aka non-capturing lambdas. I recall we had a prototype for that years ago, but switching over was shelved for some reason.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19477#issuecomment-2139703977

From asemenyuk at openjdk.org  Thu May 30 14:43:02 2024
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Thu, 30 May 2024 14:43:02 GMT
Subject: RFR: 8332110: [macos] jpackage tries to sign added files without
 the --mac-sign option
In-Reply-To: <eiboU_LgwkTte_7rkPJAdDm1x_-Pzm8rdwUiY_4MAYI=.b982e161-fe24-44ab-9db5-2f1d80eb0d99@github.com>
References: <eiboU_LgwkTte_7rkPJAdDm1x_-Pzm8rdwUiY_4MAYI=.b982e161-fe24-44ab-9db5-2f1d80eb0d99@github.com>
Message-ID: <XIR7DrFOEjMV_4YCwopS9JJrUYQ_VYwEJjXJLnhNZGg=.ffba9efd-62f5-41fa-8564-0aaf17b00b41@github.com>

On Fri, 24 May 2024 01:08:03 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

> This issue is reproducible with and without `--mac-sign`. jpackage will "_ad-hoc_" sign application bundle when `--mac-sign` is not specified by using pseudo-identity "_-_". This is why jpackage tries to sign added files and this is expected behavior by jpackage. "codesign" fails since added content made application bundle structure invalid. There is nothing we can do on jpackage side to sign such invalid bundles. As proposed solution we will output possible reason for "codesign" failure if it fails and `--app-content` was specified and possible solution. Proposed message: "One of the possible reason for "codesign" failure is additional content provided via "--app-content", which made application bundle structure invalid. Make sure to provide additional content in a way it will not break application bundle structure, otherwise add additional content as post-processing step."
> 
> Example:
> Lets assume we have "ReadMe" folder with "ReadMe.txt" file in it.
> 1) jpackage --type app-image -n Test --app-content ReadMe/ReadMe.txt ...
> "codesign" will fail with "In subcomponent: Test.app/Contents/ReadMe.txt". This is expected and "ReadMe.txt" placed in "Test.app/Contents" which is also expected.
> 2) jpackage --type app-image -n Test --app-content ReadMe ...
> Works and "ReadMe.txt" will be placed under "Test.app/Contents/ReadMe".
> 
> Sample output before fix:
> 
> Error: "codesign" failed with following output:
> Test.app: replacing existing signature
> Test.app: code object is not signed at all
> In subcomponent: Test.app/Contents/ReadMe.txt
> 
> 
> Sample output after fix:
> 
> One of the possible reason for "codesign" failure is additional content provided via "--app-content", which made application bundle structure invalid. Make sure to provide additional content in a way it will not break application bundle structure, otherwise add additional content as post-processing step.
> Error: "codesign" failed with following output:
> Test.app: replacing existing signature
> Test.app: code object is not signed at all
> In subcomponent: Test.app/Contents/ReadMe.txt

How about this wording for the message:

"codesign" failed and additional application content was supplied via the "--app-content" parameter. Probably the additional content broke the integrity of the application bundle and caused the failure. Ensure content supplied via the "--app-content" parameter does not break the integrity of the application bundle, or add it in the post-processing step.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19377#issuecomment-2139747437

From sgibbons at openjdk.org  Thu May 30 15:00:19 2024
From: sgibbons at openjdk.org (Scott Gibbons)
Date: Thu, 30 May 2024 15:00:19 GMT
Subject: RFR: 8320448: Accelerate IndexOf using AVX2 [v48]
In-Reply-To: <_4hKqcW7tE4shxVqG8Et3BjeehNjl0NWvS7PCKZaLe0=.73dc8315-22ee-47c0-8f5b-be74edc2f7a3@github.com>
References: <uWi4QxH31hL93771gkl_GgvP0m84IRSoR_1Yi8hD17E=.bc6ed458-7081-4c3f-9348-f59358fa05a4@github.com>
 <jJHpKyrD7KBeyP2gEh_CfKKNv2YM8hLccPuG6N9S1JU=.77539396-e5ac-4334-8f2c-a9a1ed5bc478@github.com>
 <bF4gn-6TzP7hCsTzUuaJrsEGaX-5aqbimI30E2b3Du8=.999e585e-0bee-459a-b78f-8ed6668cb32b@github.com>
 <_4hKqcW7tE4shxVqG8Et3BjeehNjl0NWvS7PCKZaLe0=.73dc8315-22ee-47c0-8f5b-be74edc2f7a3@github.com>
Message-ID: <nHBRwqo5NJIAvmrIZMg1D49qztd3xBos2kXurEYA5h4=.1623467c-4922-4157-a285-4d819ae57dce@github.com>

On Thu, 30 May 2024 13:56:30 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

>> Control question: Are we confident with this potentially going into JDK 23 or should we rather postpone to JDK 24? The fork is next week.
>
>> Control question: Are we confident with this potentially going into JDK 23 or should we rather postpone to JDK 24? The fork is next week.
> 
> I would hold off. @asgibbons it may pass our tests, and your extensive testing. But you never know what the fuzzer can find over a few weeks once it runs with your changes. I have made that experience many times. Let's just give it a few days, and then we have one JDK version less to worry about for backports on possible follow-up bugs ;)

@eme64 I'm glad to have received your feedback.  I see I have erroneously assumed that by making the exact code change you requested still requires your acceptance - I won't make that mistake again.  I had also erroneously assumed that your review was complete and you had no further changes for me to make.  I'd also not like to make that mistake again, but I'm unsure how to conclude that a review is complete - it seems like 7 hours of elapsed time isn't sufficient to indicate completion, so can you please help me figure this out? Perhaps it's just my distaste for "trickle-in" comments, which I should get over, or is there another way you can suggest?

As for the fuzzer I would be very interested in learning more about this.  We have a significant number of compute resources, so it may be valuable for us to set up a copy of the fuzzer on-site to improve the quality of our submissions.  Can you help in pointing me to someone that can advise me on how to do this?

As for holding off the integration, I'll leave the decision to a sponsor for this PR.  I don't believe increasing the reviewer count just to "force" reevaluation should be an acceptable practice, although I'm not an insider in this community.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/16753#issuecomment-2139814010

From lancea at openjdk.org  Thu May 30 15:04:03 2024
From: lancea at openjdk.org (Lance Andersen)
Date: Thu, 30 May 2024 15:04:03 GMT
Subject: RFR: 8210471: GZIPInputStream constructor could leak an un-end()ed
 Inflater [v2]
In-Reply-To: <oh3vme22_tGraiuVSHUwLdrmZQfuXWcgQN3F_4ksyuY=.7fee6023-66e5-4ea4-a3cb-8cbb6c124dc6@github.com>
References: <zugElcASx7a5x5uqkjArVCSH2zWDzsAFeJ9XB5FhXfE=.d5dbc5af-2af4-48cb-ba1b-724924de23f4@github.com>
 <oh3vme22_tGraiuVSHUwLdrmZQfuXWcgQN3F_4ksyuY=.7fee6023-66e5-4ea4-a3cb-8cbb6c124dc6@github.com>
Message-ID: <Bjj-rJ0tqG8oswA6GnoHJnKinVdfaMSyFrNch2hOHfw=.0db6820a-5219-4bef-9240-6136daf10cf3@github.com>

On Thu, 30 May 2024 12:32:22 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change which proposes to address the issue noted in https://bugs.openjdk.org/browse/JDK-8210471?
>> 
>> `java.util.zip.Inflater` when instantiated will hold on the native resources which are freed only when `Inflater.end()` is called. The constructor of `java.util.zip.GZIPInputStream` instantiates an `Inflater` for its internal use. After instantiating the `Inflater`, the `GZIPInputStream` constructor before returning from the constructor, can run into either a `IllegalArgumentException` (because the `size` is `<=0`) or an `IOException` when trying to read a GZIP header from the underlying `InputStream`. In either of these cases, the `Inflater` that the `GZIPInputStream` created internally will end up leaking and the caller has no way to `end()` that `Inflater` or even knowledge of that `Inflater`.
>> 
>> The commit in this PR catches the `IOException` when reading the GZIP header and `end()`s the `Inflater`. Furthermore, to prevent instantiation of an `Inflater`, the `GZIPInputStream` constructor before calling `super(...)` will now check the `InputStream` to be non-null and `size` to be `>0`, both of which were being done by the `super` constructor.
>> 
>> Given the nature of the change, no new test has been added. Existing tests in `test/jdk/java/util/zip` continue to pass and tier1, tier2 and tier3 testing is in progress.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   introduce a basic test for GZIPInputStream

Looks good overall, but I believe we need to address the comment below unless I missed something

src/java.base/share/classes/java/util/zip/GZIPInputStream.java line 97:

> 95:      */
> 96:     private static Inflater createInflater(InputStream in, int size) {
> 97:         Objects.requireNonNull(in);

I don't believe we currently indicate at at NPE will be thrown if the InputStream is null so this would require a CSR if we need to document it

-------------

PR Review: https://git.openjdk.org/jdk/pull/19475#pullrequestreview-2088514194
PR Review Comment: https://git.openjdk.org/jdk/pull/19475#discussion_r1620877576

From duke at openjdk.org  Thu May 30 15:19:17 2024
From: duke at openjdk.org (Volodymyr Paprotski)
Date: Thu, 30 May 2024 15:19:17 GMT
Subject: RFR: 8320448: Accelerate IndexOf using AVX2 [v48]
In-Reply-To: <_4hKqcW7tE4shxVqG8Et3BjeehNjl0NWvS7PCKZaLe0=.73dc8315-22ee-47c0-8f5b-be74edc2f7a3@github.com>
References: <uWi4QxH31hL93771gkl_GgvP0m84IRSoR_1Yi8hD17E=.bc6ed458-7081-4c3f-9348-f59358fa05a4@github.com>
 <jJHpKyrD7KBeyP2gEh_CfKKNv2YM8hLccPuG6N9S1JU=.77539396-e5ac-4334-8f2c-a9a1ed5bc478@github.com>
 <bF4gn-6TzP7hCsTzUuaJrsEGaX-5aqbimI30E2b3Du8=.999e585e-0bee-459a-b78f-8ed6668cb32b@github.com>
 <_4hKqcW7tE4shxVqG8Et3BjeehNjl0NWvS7PCKZaLe0=.73dc8315-22ee-47c0-8f5b-be74edc2f7a3@github.com>
Message-ID: <3r6BovGjkFUudXIeF6FF3ODENJ5F_wdHG1z4eyjpI-Y=.61eb125c-932d-4713-93fe-9f9ccb6584e4@github.com>

On Thu, 30 May 2024 13:56:30 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

>> Control question: Are we confident with this potentially going into JDK 23 or should we rather postpone to JDK 24? The fork is next week.
>
>> Control question: Are we confident with this potentially going into JDK 23 or should we rather postpone to JDK 24? The fork is next week.
> 
> I would hold off. @asgibbons it may pass our tests, and your extensive testing. But you never know what the fuzzer can find over a few weeks once it runs with your changes. I have made that experience many times. Let's just give it a few days, and then we have one JDK version less to worry about for backports on possible follow-up bugs ;)

@eme64 I guess to add some confidence.. we did also 'test it independently' to catch blind spots. i.e. `String/IndexOf.java` is from me. I tried to be as paranoid as possible with non-random strings. Passed everything I could throw at it..

-------------

PR Comment: https://git.openjdk.org/jdk/pull/16753#issuecomment-2139882544

From epeter at openjdk.org  Thu May 30 15:19:18 2024
From: epeter at openjdk.org (Emanuel Peter)
Date: Thu, 30 May 2024 15:19:18 GMT
Subject: RFR: 8320448: Accelerate IndexOf using AVX2 [v48]
In-Reply-To: <nHBRwqo5NJIAvmrIZMg1D49qztd3xBos2kXurEYA5h4=.1623467c-4922-4157-a285-4d819ae57dce@github.com>
References: <uWi4QxH31hL93771gkl_GgvP0m84IRSoR_1Yi8hD17E=.bc6ed458-7081-4c3f-9348-f59358fa05a4@github.com>
 <jJHpKyrD7KBeyP2gEh_CfKKNv2YM8hLccPuG6N9S1JU=.77539396-e5ac-4334-8f2c-a9a1ed5bc478@github.com>
 <bF4gn-6TzP7hCsTzUuaJrsEGaX-5aqbimI30E2b3Du8=.999e585e-0bee-459a-b78f-8ed6668cb32b@github.com>
 <_4hKqcW7tE4shxVqG8Et3BjeehNjl0NWvS7PCKZaLe0=.73dc8315-22ee-47c0-8f5b-be74edc2f7a3@github.com>
 <nHBRwqo5NJIAvmrIZMg1D49qztd3xBos2kXurEYA5h4=.1623467c-4922-4157-a285-4d819ae57dce@github.com>
Message-ID: <2MrjPeUReR3CJbw_L3K92H8O7xrKSIdZVzfpf7LVkIM=.dab21bd9-b149-4917-92dd-3e6abcca482b@github.com>

On Thu, 30 May 2024 14:57:35 GMT, Scott Gibbons <sgibbons at openjdk.org> wrote:

>>> Control question: Are we confident with this potentially going into JDK 23 or should we rather postpone to JDK 24? The fork is next week.
>> 
>> I would hold off. @asgibbons it may pass our tests, and your extensive testing. But you never know what the fuzzer can find over a few weeks once it runs with your changes. I have made that experience many times. Let's just give it a few days, and then we have one JDK version less to worry about for backports on possible follow-up bugs ;)
>
> @eme64 I'm glad to have received your feedback.  I see I have erroneously assumed that by making the exact code change you requested still requires your acceptance - I won't make that mistake again.  I had also erroneously assumed that your review was complete and you had no further changes for me to make.  I'd also not like to make that mistake again, but I'm unsure how to conclude that a review is complete - it seems like 7 hours of elapsed time isn't sufficient to indicate completion, so can you please help me figure this out? Perhaps it's just my distaste for "trickle-in" comments, which I should get over, or is there another way you can suggest?
> 
> As for the fuzzer I would be very interested in learning more about this.  We have a significant number of compute resources, so it may be valuable for us to set up a copy of the fuzzer on-site to improve the quality of our submissions.  Can you help in pointing me to someone that can advise me on how to do this?
> 
> As for holding off the integration, I'll leave the decision to a sponsor for this PR.  I don't believe increasing the reviewer count just to "force" reevaluation should be an acceptable practice, although I'm not an insider in this community.

@asgibbons I was done with my review, or at least so I thought ? 
Still: if I give comments, it would be nice to quickly finish the conversation, unless if I don't respond in many days and not even to emails.

Often I only see the glaring issues. Then you fix them, and then I see something else around it. Then I may give more comments. That is what happened.

If I think that I have small suggestions and then I'm done, then I might even approve even though there are suggestions still to be added.

I just put up the limit really quick so that nobody else would by accident sponsor it before we have finished the conversation, and I will definitely give you my approval once the little issues are resolved ;)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/16753#issuecomment-2139893561

From epeter at openjdk.org  Thu May 30 15:19:18 2024
From: epeter at openjdk.org (Emanuel Peter)
Date: Thu, 30 May 2024 15:19:18 GMT
Subject: RFR: 8320448: Accelerate IndexOf using AVX2 [v49]
In-Reply-To: <9PIuILHZnLHrZf1sz0Dsq6iup6qgyXw50mD0nGVS04c=.63bd0afd-d818-46fa-a082-a3d2066829cd@github.com>
References: <uWi4QxH31hL93771gkl_GgvP0m84IRSoR_1Yi8hD17E=.bc6ed458-7081-4c3f-9348-f59358fa05a4@github.com>
 <9PIuILHZnLHrZf1sz0Dsq6iup6qgyXw50mD0nGVS04c=.63bd0afd-d818-46fa-a082-a3d2066829cd@github.com>
Message-ID: <4ZM8wZFYPZjIbjb_O6n6DNAlpYOa2EHfmhSZHVUAXNA=.b923e319-f143-4a4c-9916-face36f337db@github.com>

On Thu, 30 May 2024 13:19:57 GMT, Scott Gibbons <sgibbons at openjdk.org> wrote:

>> Re-write the IndexOf code without the use of the pcmpestri instruction, only using AVX2 instructions.  This change accelerates String.IndexOf on average 1.3x for AVX2.  The benchmark numbers:
>> 
>> 
>> Benchmark	                                               Score		Latest		
>> StringIndexOf.advancedWithMediumSub   343.573		317.934		0.925375393x
>> StringIndexOf.advancedWithShortSub1	  1039.081		1053.96		1.014319384x
>> StringIndexOf.advancedWithShortSub2	      55.828		110.541		1.980027943x
>> StringIndexOf.constantPattern	                9.361		11.906		1.271872663x
>> StringIndexOf.searchCharLongSuccess	        4.216		4.218		1.000474383x
>> StringIndexOf.searchCharMediumSuccess	3.133		3.216		1.02649218x
>> StringIndexOf.searchCharShortSuccess	3.76		        3.761		1.000265957x
>> StringIndexOf.success	                                9.186		9.713		1.057369911x
>> StringIndexOf.successBig	                      14.341		46.343		3.231504079x
>> StringIndexOfChar.latin1_AVX2_String	  6220.918		12154.52		1.953814533x
>> StringIndexOfChar.latin1_AVX2_char	  5503.556		5540.044		1.006629895x
>> StringIndexOfChar.latin1_SSE4_String	  6978.854		6818.689		0.977049957x
>> StringIndexOfChar.latin1_SSE4_char	  5657.499		5474.624		0.967675646x
>> StringIndexOfChar.latin1_Short_String	  7132.541		6863.359		0.962260014x
>> StringIndexOfChar.latin1_Short_char	16013.389	      16162.437		1.009307711x
>> StringIndexOfChar.latin1_mixed_String	  7386.123	      14771.622		1.999915517x
>> StringIndexOfChar.latin1_mixed_char	  9901.671		9782.245		0.987938803
>
> Scott Gibbons has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Stupid EOL at end
>  - Add @test block; fix test indentation

About the fuzzer: we have it in our closed tests. But I think it comes from this: https://github.com/shipilev/JavaFuzzer

-------------

PR Comment: https://git.openjdk.org/jdk/pull/16753#issuecomment-2139901477

From sgibbons at openjdk.org  Thu May 30 15:27:18 2024
From: sgibbons at openjdk.org (Scott Gibbons)
Date: Thu, 30 May 2024 15:27:18 GMT
Subject: RFR: 8320448: Accelerate IndexOf using AVX2 [v49]
In-Reply-To: <NDAt69tQ4Ni4t1pCE11IiOPz7IXpdqaTHI_Mj9Z7KLA=.6d790280-a2ff-4634-b626-c7663a7815f4@github.com>
References: <uWi4QxH31hL93771gkl_GgvP0m84IRSoR_1Yi8hD17E=.bc6ed458-7081-4c3f-9348-f59358fa05a4@github.com>
 <9PIuILHZnLHrZf1sz0Dsq6iup6qgyXw50mD0nGVS04c=.63bd0afd-d818-46fa-a082-a3d2066829cd@github.com>
 <NDAt69tQ4Ni4t1pCE11IiOPz7IXpdqaTHI_Mj9Z7KLA=.6d790280-a2ff-4634-b626-c7663a7815f4@github.com>
Message-ID: <KJR30Qv07mnWhYaAbQyTitJu6cgAHhAl0McaqXPCk2Q=.019351a8-adcf-4582-8958-8ebc482e29f3@github.com>

On Thu, 30 May 2024 13:50:01 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

>> Scott Gibbons has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Stupid EOL at end
>>  - Add @test block; fix test indentation
>
> test/jdk/java/lang/String/IndexOf.java line 25:
> 
>> 23: 
>> 24: /*
>> 25:  * @test
> 
> You should add the `@bug 8320448` for all runs.

Done.

> test/jdk/java/lang/String/IndexOf.java line 27:
> 
>> 25:  * @test
>> 26:  * @summary test String indexOf() intrinsic
>> 27:  * @run main/othervm IndexOf
> 
> Suggestion:
> 
>  * @run main IndexOf
> 
> You do not need a new VM if you have no arguments ;)

Done.

> test/jdk/java/lang/StringBuffer/ECoreIndexOf.java line 25:
> 
>> 23: 
>> 24: /* @test
>> 25:  * @bug 4162796 4162796
> 
> You need to fix the bug numbers.

Done.

> test/jdk/java/lang/StringBuffer/ECoreIndexOf.java line 27:
> 
>> 25:  * @bug 4162796 4162796
>> 26:  * @summary Test indexOf and lastIndexOf
>> 27:  * @run main/othervm -Xbatch -XX:-TieredCompilation -XX:CompileCommand=dontinline,ECoreIndexOf.indexOfKernel ECoreIndexOf
> 
> I would also add a line without `-XX:-TieredCompilation`, then C1 can be tested with this too

Done.

> test/jdk/java/lang/StringBuffer/ECoreIndexOf.java line 32:
> 
>> 30: 
>> 31: /* @test
>> 32:  * @bug 4162796 4162796
> 
> Here too

Done.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1620951690
PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1620949315
PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1620945040
PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1620947641
PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1620945484

From sgibbons at openjdk.org  Thu May 30 15:30:45 2024
From: sgibbons at openjdk.org (Scott Gibbons)
Date: Thu, 30 May 2024 15:30:45 GMT
Subject: RFR: 8320448: Accelerate IndexOf using AVX2 [v50]
In-Reply-To: <uWi4QxH31hL93771gkl_GgvP0m84IRSoR_1Yi8hD17E=.bc6ed458-7081-4c3f-9348-f59358fa05a4@github.com>
References: <uWi4QxH31hL93771gkl_GgvP0m84IRSoR_1Yi8hD17E=.bc6ed458-7081-4c3f-9348-f59358fa05a4@github.com>
Message-ID: <Ac1LWjWBcw5mjWBO7thEFGb2IVfqixkhI6hu46btLog=.5d05f253-511e-49e2-9550-acb081ab43c3@github.com>

> Re-write the IndexOf code without the use of the pcmpestri instruction, only using AVX2 instructions.  This change accelerates String.IndexOf on average 1.3x for AVX2.  The benchmark numbers:
> 
> 
> Benchmark	                                               Score		Latest		
> StringIndexOf.advancedWithMediumSub   343.573		317.934		0.925375393x
> StringIndexOf.advancedWithShortSub1	  1039.081		1053.96		1.014319384x
> StringIndexOf.advancedWithShortSub2	      55.828		110.541		1.980027943x
> StringIndexOf.constantPattern	                9.361		11.906		1.271872663x
> StringIndexOf.searchCharLongSuccess	        4.216		4.218		1.000474383x
> StringIndexOf.searchCharMediumSuccess	3.133		3.216		1.02649218x
> StringIndexOf.searchCharShortSuccess	3.76		        3.761		1.000265957x
> StringIndexOf.success	                                9.186		9.713		1.057369911x
> StringIndexOf.successBig	                      14.341		46.343		3.231504079x
> StringIndexOfChar.latin1_AVX2_String	  6220.918		12154.52		1.953814533x
> StringIndexOfChar.latin1_AVX2_char	  5503.556		5540.044		1.006629895x
> StringIndexOfChar.latin1_SSE4_String	  6978.854		6818.689		0.977049957x
> StringIndexOfChar.latin1_SSE4_char	  5657.499		5474.624		0.967675646x
> StringIndexOfChar.latin1_Short_String	  7132.541		6863.359		0.962260014x
> StringIndexOfChar.latin1_Short_char	16013.389	      16162.437		1.009307711x
> StringIndexOfChar.latin1_mixed_String	  7386.123	      14771.622		1.999915517x
> StringIndexOfChar.latin1_mixed_char	  9901.671		9782.245		0.987938803

Scott Gibbons has updated the pull request incrementally with one additional commit since the last revision:

  Review comments

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/16753/files
  - new: https://git.openjdk.org/jdk/pull/16753/files/3e150fe3..57e115d7

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16753&range=49
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16753&range=48-49

  Stats: 6 lines in 2 files changed: 3 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/16753.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16753/head:pull/16753

PR: https://git.openjdk.org/jdk/pull/16753

From epeter at openjdk.org  Thu May 30 15:37:18 2024
From: epeter at openjdk.org (Emanuel Peter)
Date: Thu, 30 May 2024 15:37:18 GMT
Subject: RFR: 8320448: Accelerate IndexOf using AVX2 [v49]
In-Reply-To: <KJR30Qv07mnWhYaAbQyTitJu6cgAHhAl0McaqXPCk2Q=.019351a8-adcf-4582-8958-8ebc482e29f3@github.com>
References: <uWi4QxH31hL93771gkl_GgvP0m84IRSoR_1Yi8hD17E=.bc6ed458-7081-4c3f-9348-f59358fa05a4@github.com>
 <9PIuILHZnLHrZf1sz0Dsq6iup6qgyXw50mD0nGVS04c=.63bd0afd-d818-46fa-a082-a3d2066829cd@github.com>
 <NDAt69tQ4Ni4t1pCE11IiOPz7IXpdqaTHI_Mj9Z7KLA=.6d790280-a2ff-4634-b626-c7663a7815f4@github.com>
 <KJR30Qv07mnWhYaAbQyTitJu6cgAHhAl0McaqXPCk2Q=.019351a8-adcf-4582-8958-8ebc482e29f3@github.com>
Message-ID: <Bur0H_YHJonNHnUYysoSyaFn4zmLvfg-clpeQ3lRjEQ=.e7f7290d-ec7a-49f5-9b72-21315632cc4c@github.com>

On Thu, 30 May 2024 15:21:10 GMT, Scott Gibbons <sgibbons at openjdk.org> wrote:

> Done.

I still see the numbers `4162796 4162796`. I'm not sure if this bug number is relevant. But certainly it should only be mentioned once ;)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1620960158

From epeter at openjdk.org  Thu May 30 15:37:18 2024
From: epeter at openjdk.org (Emanuel Peter)
Date: Thu, 30 May 2024 15:37:18 GMT
Subject: RFR: 8320448: Accelerate IndexOf using AVX2 [v49]
In-Reply-To: <Bur0H_YHJonNHnUYysoSyaFn4zmLvfg-clpeQ3lRjEQ=.e7f7290d-ec7a-49f5-9b72-21315632cc4c@github.com>
References: <uWi4QxH31hL93771gkl_GgvP0m84IRSoR_1Yi8hD17E=.bc6ed458-7081-4c3f-9348-f59358fa05a4@github.com>
 <9PIuILHZnLHrZf1sz0Dsq6iup6qgyXw50mD0nGVS04c=.63bd0afd-d818-46fa-a082-a3d2066829cd@github.com>
 <NDAt69tQ4Ni4t1pCE11IiOPz7IXpdqaTHI_Mj9Z7KLA=.6d790280-a2ff-4634-b626-c7663a7815f4@github.com>
 <KJR30Qv07mnWhYaAbQyTitJu6cgAHhAl0McaqXPCk2Q=.019351a8-adcf-4582-8958-8ebc482e29f3@github.com>
 <Bur0H_YHJonNHnUYysoSyaFn4zmLvfg-clpeQ3lRjEQ=.e7f7290d-ec7a-49f5-9b72-21315632cc4c@github.com>
Message-ID: <oKzt6i9mUWUO76ikbgb6M-unjag9279E3uI5JBqzghE=.cb5ff466-fa9a-474e-b552-b05b7f598bbb@github.com>

On Thu, 30 May 2024 15:30:26 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

>> Done.
>
>> Done.
> 
> I still see the numbers `4162796 4162796`. I'm not sure if this bug number is relevant. But certainly it should only be mentioned once ;)

I never add old bug number to new tests...

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1620963284

From epeter at openjdk.org  Thu May 30 15:37:20 2024
From: epeter at openjdk.org (Emanuel Peter)
Date: Thu, 30 May 2024 15:37:20 GMT
Subject: RFR: 8320448: Accelerate IndexOf using AVX2 [v50]
In-Reply-To: <Ac1LWjWBcw5mjWBO7thEFGb2IVfqixkhI6hu46btLog=.5d05f253-511e-49e2-9550-acb081ab43c3@github.com>
References: <uWi4QxH31hL93771gkl_GgvP0m84IRSoR_1Yi8hD17E=.bc6ed458-7081-4c3f-9348-f59358fa05a4@github.com>
 <Ac1LWjWBcw5mjWBO7thEFGb2IVfqixkhI6hu46btLog=.5d05f253-511e-49e2-9550-acb081ab43c3@github.com>
Message-ID: <dYdy_udAmuMBvpALEXWwFW60CNpSVDb46UTmFHPRY_I=.7b70ad22-6527-483b-b6e2-451a3eaf175b@github.com>

On Thu, 30 May 2024 15:30:45 GMT, Scott Gibbons <sgibbons at openjdk.org> wrote:

>> Re-write the IndexOf code without the use of the pcmpestri instruction, only using AVX2 instructions.  This change accelerates String.IndexOf on average 1.3x for AVX2.  The benchmark numbers:
>> 
>> 
>> Benchmark	                                               Score		Latest		
>> StringIndexOf.advancedWithMediumSub   343.573		317.934		0.925375393x
>> StringIndexOf.advancedWithShortSub1	  1039.081		1053.96		1.014319384x
>> StringIndexOf.advancedWithShortSub2	      55.828		110.541		1.980027943x
>> StringIndexOf.constantPattern	                9.361		11.906		1.271872663x
>> StringIndexOf.searchCharLongSuccess	        4.216		4.218		1.000474383x
>> StringIndexOf.searchCharMediumSuccess	3.133		3.216		1.02649218x
>> StringIndexOf.searchCharShortSuccess	3.76		        3.761		1.000265957x
>> StringIndexOf.success	                                9.186		9.713		1.057369911x
>> StringIndexOf.successBig	                      14.341		46.343		3.231504079x
>> StringIndexOfChar.latin1_AVX2_String	  6220.918		12154.52		1.953814533x
>> StringIndexOfChar.latin1_AVX2_char	  5503.556		5540.044		1.006629895x
>> StringIndexOfChar.latin1_SSE4_String	  6978.854		6818.689		0.977049957x
>> StringIndexOfChar.latin1_SSE4_char	  5657.499		5474.624		0.967675646x
>> StringIndexOfChar.latin1_Short_String	  7132.541		6863.359		0.962260014x
>> StringIndexOfChar.latin1_Short_char	16013.389	      16162.437		1.009307711x
>> StringIndexOfChar.latin1_mixed_String	  7386.123	      14771.622		1.999915517x
>> StringIndexOfChar.latin1_mixed_char	  9901.671		9782.245		0.987938803
>
> Scott Gibbons has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comments

test/jdk/java/lang/StringBuffer/ECoreIndexOf.java line 25:

> 23: 
> 24: /* @test
> 25:  * @bug 4162796 4162796 8320448

Suggestion:

 * @bug 8320448

test/jdk/java/lang/StringBuffer/ECoreIndexOf.java line 33:

> 31: 
> 32: /* @test
> 33:  * @bug 4162796 4162796 8320448

Suggestion:

 * @bug 8320448

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1620964138
PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1620964720

From epeter at openjdk.org  Thu May 30 15:37:20 2024
From: epeter at openjdk.org (Emanuel Peter)
Date: Thu, 30 May 2024 15:37:20 GMT
Subject: RFR: 8320448: Accelerate IndexOf using AVX2 [v50]
In-Reply-To: <dYdy_udAmuMBvpALEXWwFW60CNpSVDb46UTmFHPRY_I=.7b70ad22-6527-483b-b6e2-451a3eaf175b@github.com>
References: <uWi4QxH31hL93771gkl_GgvP0m84IRSoR_1Yi8hD17E=.bc6ed458-7081-4c3f-9348-f59358fa05a4@github.com>
 <Ac1LWjWBcw5mjWBO7thEFGb2IVfqixkhI6hu46btLog=.5d05f253-511e-49e2-9550-acb081ab43c3@github.com>
 <dYdy_udAmuMBvpALEXWwFW60CNpSVDb46UTmFHPRY_I=.7b70ad22-6527-483b-b6e2-451a3eaf175b@github.com>
Message-ID: <l7fKDAn3o4NcR1NLEf4u1s61H3THrJ9BhgXGnbwWJoo=.f07384ee-5a3e-435d-9507-923ed892dba0@github.com>

On Thu, 30 May 2024 15:33:16 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

>> Scott Gibbons has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Review comments
>
> test/jdk/java/lang/StringBuffer/ECoreIndexOf.java line 25:
> 
>> 23: 
>> 24: /* @test
>> 25:  * @bug 4162796 4162796 8320448
> 
> Suggestion:
> 
>  * @bug 8320448

As I said above: I never add old bug numbers to new tests. But here it is even duplicated ;)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1620966568

From alanb at openjdk.org  Thu May 30 15:45:13 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 30 May 2024 15:45:13 GMT
Subject: Integrated: 8331189: Implementation of Scoped Values (Third Preview)
In-Reply-To: <kFWNL6QScozy3Z7CHuifpZgaobVm5ypn8dhNWiBebt4=.c47076f2-8a76-4bf1-b17d-5b50a0c9bb2f@github.com>
References: <kFWNL6QScozy3Z7CHuifpZgaobVm5ypn8dhNWiBebt4=.c47076f2-8a76-4bf1-b17d-5b50a0c9bb2f@github.com>
Message-ID: <26q1p_nL6BomzLlMeMwkK80-uB8GJ7_gWDoCRqRUMrE=.74763a95-1c02-4293-a66f-e58d14d3389d@github.com>

On Wed, 8 May 2024 09:40:38 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> JEP 481 proposes Scoped Values to continue to preview in JDK 23 with one change. The type of the operation parameter of the callWhere method is changed to a new functional interface to avoid having the API throw Exception. With that change, the getWhere (and the corresponding method on Carrier) are no longer needed. The functional interface is not proposed for j.u.function at this time.

This pull request has now been integrated.

Changeset: 70715423
Author:    Alan Bateman <alanb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/707154235b29bebc4c3fdb797e24acd8e9f6916a
Stats:     298 lines in 7 files changed: 31 ins; 203 del; 64 mod

8331189: Implementation of Scoped Values (Third Preview)

Reviewed-by: aph, jpai, mcimadamore

-------------

PR: https://git.openjdk.org/jdk/pull/19136

From dl at openjdk.org  Thu May 30 15:47:34 2024
From: dl at openjdk.org (Doug Lea)
Date: Thu, 30 May 2024 15:47:34 GMT
Subject: RFR: 8322732: ForkJoinPool may underutilize cores in async mode
 [v13]
In-Reply-To: <xRyDMAsSZ7obqpr3Aoc5qrHqILeJMxFVCeiRdctMI3U=.d5d3cd56-32eb-4431-ac01-081822fc86c6@github.com>
References: <xRyDMAsSZ7obqpr3Aoc5qrHqILeJMxFVCeiRdctMI3U=.d5d3cd56-32eb-4431-ac01-081822fc86c6@github.com>
Message-ID: <A1F-uNAfLZoEg7E5fpNlOVSDBhTy1WQoWRKDp9h0msE=.d0c195fb-7c33-4767-bc3b-7f1aa8942cc9@github.com>

> This set of changes address causes of poor utilization with small numbers of cores due to overly aggressive contention avoidance. A number of further adjustments were needed to still avoid most contention effects in deployments with large numbers of cores

Doug Lea has updated the pull request incrementally with one additional commit since the last revision:

  reshadow; avoid test loop bleed

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19131/files
  - new: https://git.openjdk.org/jdk/pull/19131/files/b13d8ee1..398e5c6a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19131&range=12
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19131&range=11-12

  Stats: 23 lines in 2 files changed: 10 ins; 0 del; 13 mod
  Patch: https://git.openjdk.org/jdk/pull/19131.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19131/head:pull/19131

PR: https://git.openjdk.org/jdk/pull/19131

From sgibbons at openjdk.org  Thu May 30 15:48:50 2024
From: sgibbons at openjdk.org (Scott Gibbons)
Date: Thu, 30 May 2024 15:48:50 GMT
Subject: RFR: 8320448: Accelerate IndexOf using AVX2 [v51]
In-Reply-To: <uWi4QxH31hL93771gkl_GgvP0m84IRSoR_1Yi8hD17E=.bc6ed458-7081-4c3f-9348-f59358fa05a4@github.com>
References: <uWi4QxH31hL93771gkl_GgvP0m84IRSoR_1Yi8hD17E=.bc6ed458-7081-4c3f-9348-f59358fa05a4@github.com>
Message-ID: <73yhW7umbpUKGvfaJ5hkzLjIQ6_8hakVYD59s0-60OY=.321f0126-06a2-4efc-a271-80a518c53baa@github.com>

> Re-write the IndexOf code without the use of the pcmpestri instruction, only using AVX2 instructions.  This change accelerates String.IndexOf on average 1.3x for AVX2.  The benchmark numbers:
> 
> 
> Benchmark	                                               Score		Latest		
> StringIndexOf.advancedWithMediumSub   343.573		317.934		0.925375393x
> StringIndexOf.advancedWithShortSub1	  1039.081		1053.96		1.014319384x
> StringIndexOf.advancedWithShortSub2	      55.828		110.541		1.980027943x
> StringIndexOf.constantPattern	                9.361		11.906		1.271872663x
> StringIndexOf.searchCharLongSuccess	        4.216		4.218		1.000474383x
> StringIndexOf.searchCharMediumSuccess	3.133		3.216		1.02649218x
> StringIndexOf.searchCharShortSuccess	3.76		        3.761		1.000265957x
> StringIndexOf.success	                                9.186		9.713		1.057369911x
> StringIndexOf.successBig	                      14.341		46.343		3.231504079x
> StringIndexOfChar.latin1_AVX2_String	  6220.918		12154.52		1.953814533x
> StringIndexOfChar.latin1_AVX2_char	  5503.556		5540.044		1.006629895x
> StringIndexOfChar.latin1_SSE4_String	  6978.854		6818.689		0.977049957x
> StringIndexOfChar.latin1_SSE4_char	  5657.499		5474.624		0.967675646x
> StringIndexOfChar.latin1_Short_String	  7132.541		6863.359		0.962260014x
> StringIndexOfChar.latin1_Short_char	16013.389	      16162.437		1.009307711x
> StringIndexOfChar.latin1_mixed_String	  7386.123	      14771.622		1.999915517x
> StringIndexOfChar.latin1_mixed_char	  9901.671		9782.245		0.987938803

Scott Gibbons has updated the pull request incrementally with one additional commit since the last revision:

  Fix bug number in tests

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/16753/files
  - new: https://git.openjdk.org/jdk/pull/16753/files/57e115d7..6eae46e5

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16753&range=50
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16753&range=49-50

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/16753.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16753/head:pull/16753

PR: https://git.openjdk.org/jdk/pull/16753

From sgibbons at openjdk.org  Thu May 30 15:48:50 2024
From: sgibbons at openjdk.org (Scott Gibbons)
Date: Thu, 30 May 2024 15:48:50 GMT
Subject: RFR: 8320448: Accelerate IndexOf using AVX2 [v50]
In-Reply-To: <l7fKDAn3o4NcR1NLEf4u1s61H3THrJ9BhgXGnbwWJoo=.f07384ee-5a3e-435d-9507-923ed892dba0@github.com>
References: <uWi4QxH31hL93771gkl_GgvP0m84IRSoR_1Yi8hD17E=.bc6ed458-7081-4c3f-9348-f59358fa05a4@github.com>
 <Ac1LWjWBcw5mjWBO7thEFGb2IVfqixkhI6hu46btLog=.5d05f253-511e-49e2-9550-acb081ab43c3@github.com>
 <dYdy_udAmuMBvpALEXWwFW60CNpSVDb46UTmFHPRY_I=.7b70ad22-6527-483b-b6e2-451a3eaf175b@github.com>
 <l7fKDAn3o4NcR1NLEf4u1s61H3THrJ9BhgXGnbwWJoo=.f07384ee-5a3e-435d-9507-923ed892dba0@github.com>
Message-ID: <22JtxwmXnPAAUHF8c3g6lmvUtymzGr6Ekib_nUAKbW4=.3315da8b-09bc-4534-9f27-0fe1485456c7@github.com>

On Thu, 30 May 2024 15:34:17 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

>> test/jdk/java/lang/StringBuffer/ECoreIndexOf.java line 25:
>> 
>>> 23: 
>>> 24: /* @test
>>> 25:  * @bug 4162796 4162796 8320448
>> 
>> Suggestion:
>> 
>>  * @bug 8320448
>
> As I said above: I never add old bug numbers to new tests. But here it is even duplicated ;)

The file I used as baseline for this `test/jdk/java/lang/StringBuffer/IndexOf.java` has the bug number listed twice (copy/paste).  I'll remove it from here, but leave it in the original unless requested to change it.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1620985844

From sgibbons at openjdk.org  Thu May 30 15:48:50 2024
From: sgibbons at openjdk.org (Scott Gibbons)
Date: Thu, 30 May 2024 15:48:50 GMT
Subject: RFR: 8320448: Accelerate IndexOf using AVX2 [v50]
In-Reply-To: <dYdy_udAmuMBvpALEXWwFW60CNpSVDb46UTmFHPRY_I=.7b70ad22-6527-483b-b6e2-451a3eaf175b@github.com>
References: <uWi4QxH31hL93771gkl_GgvP0m84IRSoR_1Yi8hD17E=.bc6ed458-7081-4c3f-9348-f59358fa05a4@github.com>
 <Ac1LWjWBcw5mjWBO7thEFGb2IVfqixkhI6hu46btLog=.5d05f253-511e-49e2-9550-acb081ab43c3@github.com>
 <dYdy_udAmuMBvpALEXWwFW60CNpSVDb46UTmFHPRY_I=.7b70ad22-6527-483b-b6e2-451a3eaf175b@github.com>
Message-ID: <3nJczHjyjWVNAlPneM19NW6Dc0MRql6sDE2hX4tyZpc=.3539eed5-c871-422c-806b-1f2d5bcbae2f@github.com>

On Thu, 30 May 2024 15:33:27 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

>> Scott Gibbons has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Review comments
>
> test/jdk/java/lang/StringBuffer/ECoreIndexOf.java line 33:
> 
>> 31: 
>> 32: /* @test
>> 33:  * @bug 4162796 4162796 8320448
> 
> Suggestion:
> 
>  * @bug 8320448

Fixed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1620988308

From epeter at openjdk.org  Thu May 30 16:10:17 2024
From: epeter at openjdk.org (Emanuel Peter)
Date: Thu, 30 May 2024 16:10:17 GMT
Subject: RFR: 8320448: Accelerate IndexOf using AVX2 [v51]
In-Reply-To: <73yhW7umbpUKGvfaJ5hkzLjIQ6_8hakVYD59s0-60OY=.321f0126-06a2-4efc-a271-80a518c53baa@github.com>
References: <uWi4QxH31hL93771gkl_GgvP0m84IRSoR_1Yi8hD17E=.bc6ed458-7081-4c3f-9348-f59358fa05a4@github.com>
 <73yhW7umbpUKGvfaJ5hkzLjIQ6_8hakVYD59s0-60OY=.321f0126-06a2-4efc-a271-80a518c53baa@github.com>
Message-ID: <Kvh-nRZNsl6DlXee_OYh5rbJX1QDK2FvdFJoxeWcKds=.448278ff-47d4-4065-8ab3-b8cc205c13de@github.com>

On Thu, 30 May 2024 15:48:50 GMT, Scott Gibbons <sgibbons at openjdk.org> wrote:

>> Re-write the IndexOf code without the use of the pcmpestri instruction, only using AVX2 instructions.  This change accelerates String.IndexOf on average 1.3x for AVX2.  The benchmark numbers:
>> 
>> 
>> Benchmark	                                               Score		Latest		
>> StringIndexOf.advancedWithMediumSub   343.573		317.934		0.925375393x
>> StringIndexOf.advancedWithShortSub1	  1039.081		1053.96		1.014319384x
>> StringIndexOf.advancedWithShortSub2	      55.828		110.541		1.980027943x
>> StringIndexOf.constantPattern	                9.361		11.906		1.271872663x
>> StringIndexOf.searchCharLongSuccess	        4.216		4.218		1.000474383x
>> StringIndexOf.searchCharMediumSuccess	3.133		3.216		1.02649218x
>> StringIndexOf.searchCharShortSuccess	3.76		        3.761		1.000265957x
>> StringIndexOf.success	                                9.186		9.713		1.057369911x
>> StringIndexOf.successBig	                      14.341		46.343		3.231504079x
>> StringIndexOfChar.latin1_AVX2_String	  6220.918		12154.52		1.953814533x
>> StringIndexOfChar.latin1_AVX2_char	  5503.556		5540.044		1.006629895x
>> StringIndexOfChar.latin1_SSE4_String	  6978.854		6818.689		0.977049957x
>> StringIndexOfChar.latin1_SSE4_char	  5657.499		5474.624		0.967675646x
>> StringIndexOfChar.latin1_Short_String	  7132.541		6863.359		0.962260014x
>> StringIndexOfChar.latin1_Short_char	16013.389	      16162.437		1.009307711x
>> StringIndexOfChar.latin1_mixed_String	  7386.123	      14771.622		1.999915517x
>> StringIndexOfChar.latin1_mixed_char	  9901.671		9782.245		0.987938803
>
> Scott Gibbons has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix bug number in tests

Ok, now it is good for me. But I would definately wait with integration for after the fork next week.

src/hotspot/cpu/x86/c2_stubGenerator_x86_64_string.cpp line 2:

> 1: /*
> 2:  * Copyright (c) 2023, 2024 Intel Corporation. All rights reserved.

Is the 2023 year intentional? I don't know your policy, so you can just ignore this ;)

src/hotspot/cpu/x86/c2_stubGenerator_x86_64_string.cpp line 334:

> 332:   // NUMBER_OF_CASES (currently 10) needle sizes for both big and small.  There are special
> 333:   // routines for handling needle sizes > NUMBER_OF_CASES (L_{big,small}CaseDefault).  These
> 334:   // cases use C@'s arrays_equals() to compare the needle to the haystack.  The small cases

Suggestion:

  // cases use C2's arrays_equals() to compare the needle to the haystack.  The small cases

Randomly spotted this.

src/hotspot/cpu/x86/c2_stubGenerator_x86_64_string.cpp line 773:

> 771:     // jae done
> 772:     //
> 773:     // Final index of start of needle @((16 - (ndlLen %16)) & 0xf) << 1

What is the meaning of the `@`? Maybe `at`. I'd use the same consistently

-------------

Marked as reviewed by epeter (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/16753#pullrequestreview-2088739965
PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1621015782
PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1621017548
PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1621019611

From sgibbons at openjdk.org  Thu May 30 16:16:45 2024
From: sgibbons at openjdk.org (Scott Gibbons)
Date: Thu, 30 May 2024 16:16:45 GMT
Subject: RFR: 8320448: Accelerate IndexOf using AVX2 [v52]
In-Reply-To: <uWi4QxH31hL93771gkl_GgvP0m84IRSoR_1Yi8hD17E=.bc6ed458-7081-4c3f-9348-f59358fa05a4@github.com>
References: <uWi4QxH31hL93771gkl_GgvP0m84IRSoR_1Yi8hD17E=.bc6ed458-7081-4c3f-9348-f59358fa05a4@github.com>
Message-ID: <jFq_cE058-ZI-yhw7-CylWUxkUkPOP2Xu9-w1pQvY0s=.ff6a8cd0-0e1d-417a-83cd-e49d293f43dc@github.com>

> Re-write the IndexOf code without the use of the pcmpestri instruction, only using AVX2 instructions.  This change accelerates String.IndexOf on average 1.3x for AVX2.  The benchmark numbers:
> 
> 
> Benchmark	                                               Score		Latest		
> StringIndexOf.advancedWithMediumSub   343.573		317.934		0.925375393x
> StringIndexOf.advancedWithShortSub1	  1039.081		1053.96		1.014319384x
> StringIndexOf.advancedWithShortSub2	      55.828		110.541		1.980027943x
> StringIndexOf.constantPattern	                9.361		11.906		1.271872663x
> StringIndexOf.searchCharLongSuccess	        4.216		4.218		1.000474383x
> StringIndexOf.searchCharMediumSuccess	3.133		3.216		1.02649218x
> StringIndexOf.searchCharShortSuccess	3.76		        3.761		1.000265957x
> StringIndexOf.success	                                9.186		9.713		1.057369911x
> StringIndexOf.successBig	                      14.341		46.343		3.231504079x
> StringIndexOfChar.latin1_AVX2_String	  6220.918		12154.52		1.953814533x
> StringIndexOfChar.latin1_AVX2_char	  5503.556		5540.044		1.006629895x
> StringIndexOfChar.latin1_SSE4_String	  6978.854		6818.689		0.977049957x
> StringIndexOfChar.latin1_SSE4_char	  5657.499		5474.624		0.967675646x
> StringIndexOfChar.latin1_Short_String	  7132.541		6863.359		0.962260014x
> StringIndexOfChar.latin1_Short_char	16013.389	      16162.437		1.009307711x
> StringIndexOfChar.latin1_mixed_String	  7386.123	      14771.622		1.999915517x
> StringIndexOfChar.latin1_mixed_char	  9901.671		9782.245		0.987938803

Scott Gibbons has updated the pull request incrementally with one additional commit since the last revision:

  Fix copyright & a couple of comment typos

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/16753/files
  - new: https://git.openjdk.org/jdk/pull/16753/files/6eae46e5..f432320f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16753&range=51
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16753&range=50-51

  Stats: 5 lines in 2 files changed: 0 ins; 0 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/16753.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16753/head:pull/16753

PR: https://git.openjdk.org/jdk/pull/16753

From kvn at openjdk.org  Thu May 30 16:16:45 2024
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Thu, 30 May 2024 16:16:45 GMT
Subject: RFR: 8320448: Accelerate IndexOf using AVX2 [v49]
In-Reply-To: <4ZM8wZFYPZjIbjb_O6n6DNAlpYOa2EHfmhSZHVUAXNA=.b923e319-f143-4a4c-9916-face36f337db@github.com>
References: <uWi4QxH31hL93771gkl_GgvP0m84IRSoR_1Yi8hD17E=.bc6ed458-7081-4c3f-9348-f59358fa05a4@github.com>
 <9PIuILHZnLHrZf1sz0Dsq6iup6qgyXw50mD0nGVS04c=.63bd0afd-d818-46fa-a082-a3d2066829cd@github.com>
 <4ZM8wZFYPZjIbjb_O6n6DNAlpYOa2EHfmhSZHVUAXNA=.b923e319-f143-4a4c-9916-face36f337db@github.com>
Message-ID: <SjGmgmsLi6a72FuK8VxeKwplUzGWvPdNdtlthjqN1-Q=.b3293fa4-9a29-4b56-85ec-15c634332b42@github.com>

On Thu, 30 May 2024 15:16:34 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

>> Scott Gibbons has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Stupid EOL at end
>>  - Add @test block; fix test indentation
>
> About the fuzzer: we have it in our closed tests. But I think it comes from this: https://github.com/shipilev/JavaFuzzer

I agree with @eme64 to postpone the integration after JDK 23 is forked in one week. It is not about how you confident with code. It is size of code. I did only limited (tier1-4) testing in our infra which did not cover all our testing configuration.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/16753#issuecomment-2140103757

From sgibbons at openjdk.org  Thu May 30 16:16:45 2024
From: sgibbons at openjdk.org (Scott Gibbons)
Date: Thu, 30 May 2024 16:16:45 GMT
Subject: RFR: 8320448: Accelerate IndexOf using AVX2 [v51]
In-Reply-To: <Kvh-nRZNsl6DlXee_OYh5rbJX1QDK2FvdFJoxeWcKds=.448278ff-47d4-4065-8ab3-b8cc205c13de@github.com>
References: <uWi4QxH31hL93771gkl_GgvP0m84IRSoR_1Yi8hD17E=.bc6ed458-7081-4c3f-9348-f59358fa05a4@github.com>
 <73yhW7umbpUKGvfaJ5hkzLjIQ6_8hakVYD59s0-60OY=.321f0126-06a2-4efc-a271-80a518c53baa@github.com>
 <Kvh-nRZNsl6DlXee_OYh5rbJX1QDK2FvdFJoxeWcKds=.448278ff-47d4-4065-8ab3-b8cc205c13de@github.com>
Message-ID: <1veKa8k9a_OgFxuy0XD_MPxOHgGpy8LXTgG6gEPfXiU=.3ed8e416-4267-40c5-8daf-8a9517f51557@github.com>

On Thu, 30 May 2024 16:03:29 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

>> Scott Gibbons has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix bug number in tests
>
> src/hotspot/cpu/x86/c2_stubGenerator_x86_64_string.cpp line 2:
> 
>> 1: /*
>> 2:  * Copyright (c) 2023, 2024 Intel Corporation. All rights reserved.
> 
> Is the 2023 year intentional? I don't know your policy, so you can just ignore this ;)

I started this in November :-)

> src/hotspot/cpu/x86/c2_stubGenerator_x86_64_string.cpp line 334:
> 
>> 332:   // NUMBER_OF_CASES (currently 10) needle sizes for both big and small.  There are special
>> 333:   // routines for handling needle sizes > NUMBER_OF_CASES (L_{big,small}CaseDefault).  These
>> 334:   // cases use C@'s arrays_equals() to compare the needle to the haystack.  The small cases
> 
> Suggestion:
> 
>   // cases use C2's arrays_equals() to compare the needle to the haystack.  The small cases
> 
> Randomly spotted this.

Fixed.

> src/hotspot/cpu/x86/c2_stubGenerator_x86_64_string.cpp line 773:
> 
>> 771:     // jae done
>> 772:     //
>> 773:     // Final index of start of needle @((16 - (ndlLen %16)) & 0xf) << 1
> 
> What is the meaning of the `@`? Maybe `at`. I'd use the same consistently

Changed to "at".

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1621034441
PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1621034583
PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1621034821

From sgibbons at openjdk.org  Thu May 30 16:23:34 2024
From: sgibbons at openjdk.org (Scott Gibbons)
Date: Thu, 30 May 2024 16:23:34 GMT
Subject: RFR: 8320448: Accelerate IndexOf using AVX2 [v49]
In-Reply-To: <SjGmgmsLi6a72FuK8VxeKwplUzGWvPdNdtlthjqN1-Q=.b3293fa4-9a29-4b56-85ec-15c634332b42@github.com>
References: <uWi4QxH31hL93771gkl_GgvP0m84IRSoR_1Yi8hD17E=.bc6ed458-7081-4c3f-9348-f59358fa05a4@github.com>
 <9PIuILHZnLHrZf1sz0Dsq6iup6qgyXw50mD0nGVS04c=.63bd0afd-d818-46fa-a082-a3d2066829cd@github.com>
 <4ZM8wZFYPZjIbjb_O6n6DNAlpYOa2EHfmhSZHVUAXNA=.b923e319-f143-4a4c-9916-face36f337db@github.com>
 <SjGmgmsLi6a72FuK8VxeKwplUzGWvPdNdtlthjqN1-Q=.b3293fa4-9a29-4b56-85ec-15c634332b42@github.com>
Message-ID: <u_pbdNB9toaq3YQx8J9a7KqaFhZL2-5tGEyetJWwF1I=.fba7dc85-e0e8-441f-becb-a521df24f63d@github.com>

On Thu, 30 May 2024 16:10:53 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> About the fuzzer: we have it in our closed tests. But I think it comes from this: https://github.com/shipilev/JavaFuzzer
>
> I agree with @eme64 to postpone the integration after JDK 23 is forked in one week. It is not about how you confident with code. It is size of code. I did only limited (tier1-4) testing in our infra which did not cover all our testing configuration.

@vnkozlov OK.  I'll defer to you all.  I've contacted the author of the fuzzer to see what I can do to set up a local instance.  Would this be sufficient to increase confidence for future submissions?  We can run it perpetually on fixes (provided I can set it up).  Had I done that, we could have had 6 months of fuzzing on top of our tests.  Would that have alleviated this concern?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/16753#issuecomment-2140124882

From epeter at openjdk.org  Thu May 30 16:23:34 2024
From: epeter at openjdk.org (Emanuel Peter)
Date: Thu, 30 May 2024 16:23:34 GMT
Subject: RFR: 8320448: Accelerate IndexOf using AVX2 [v49]
In-Reply-To: <u_pbdNB9toaq3YQx8J9a7KqaFhZL2-5tGEyetJWwF1I=.fba7dc85-e0e8-441f-becb-a521df24f63d@github.com>
References: <uWi4QxH31hL93771gkl_GgvP0m84IRSoR_1Yi8hD17E=.bc6ed458-7081-4c3f-9348-f59358fa05a4@github.com>
 <9PIuILHZnLHrZf1sz0Dsq6iup6qgyXw50mD0nGVS04c=.63bd0afd-d818-46fa-a082-a3d2066829cd@github.com>
 <4ZM8wZFYPZjIbjb_O6n6DNAlpYOa2EHfmhSZHVUAXNA=.b923e319-f143-4a4c-9916-face36f337db@github.com>
 <SjGmgmsLi6a72FuK8VxeKwplUzGWvPdNdtlthjqN1-Q=.b3293fa4-9a29-4b56-85ec-15c634332b42@github.com>
 <u_pbdNB9toaq3YQx8J9a7KqaFhZL2-5tGEyetJWwF1I=.fba7dc85-e0e8-441f-becb-a521df24f63d@github.com>
Message-ID: <9Gep5o1EEF96gprsHB1vDiw8KSQON-c6uh_9gBJyq9c=.43962158-2f23-4929-9e72-d4827a4fa5e8@github.com>

On Thu, 30 May 2024 16:16:59 GMT, Scott Gibbons <sgibbons at openjdk.org> wrote:

>> I agree with @eme64 to postpone the integration after JDK 23 is forked in one week. It is not about how you confident with code. It is size of code. I did only limited (tier1-4) testing in our infra which did not cover all our testing configuration.
>
> @vnkozlov OK.  I'll defer to you all.  I've contacted the author of the fuzzer to see what I can do to set up a local instance.  Would this be sufficient to increase confidence for future submissions?  We can run it perpetually on fixes (provided I can set it up).  Had I done that, we could have had 6 months of fuzzing on top of our tests.  Would that have alleviated this concern?

@asgibbons I generally just stop pushing ANY RFE's a week or two before the fork. Even if you did run the fuzzer with it - there are often last-minute changes. And your code here is rather large, so even if you are confident, there must be at least one bug hiding.

Running the fuzzer is nice as pre-integration, but it mostly only catches things post-integration.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/16753#issuecomment-2140136262

From mcimadamore at openjdk.org  Thu May 30 16:26:40 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 30 May 2024 16:26:40 GMT
Subject: RFR: 8333236: Test java/foreign/TestAccessModes.java is timing out
 after passing
Message-ID: <mLVkvSWgzjrvnm1R6MZxjacSbTN0CxdA5f5D3lqDti0=.bb215ff2-8bfd-4ce4-8986-522f0ef1af08@github.com>

This PR restores a var handle cache in `Utils::makeSegmentViewVarHandle`. The cache was moved to `ValueLayouts::varHandle` as part of [pull/19251](https://git.openjdk.org/jdk/pull/19251), on the basis that we want to optimize the common case like:


ValueLayout layout = ...
layout.varHandle().get(...)


And that caching more complex var handles didn't seem to add value, given that, for these var handles, the logic in `LayoutPath` needs to adapt the returned var handle anyways.

But, `TestAccessModes` revealed a different picture - w/o any cache in `Utils` the test end up allocating 8963 var handle instances (instead of just 4), in each of the 4 runs the test includes. While this is admittedly a stress test, it seems nice to restore the level of sharing we had before [pull/19251](https://git.openjdk.org/jdk/pull/19251).

-------------

Commit messages:
 - Initial push

Changes: https://git.openjdk.org/jdk/pull/19485/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19485&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8333236
  Stats: 11 lines in 1 file changed: 10 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/19485.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19485/head:pull/19485

PR: https://git.openjdk.org/jdk/pull/19485

From mcimadamore at openjdk.org  Thu May 30 16:26:40 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 30 May 2024 16:26:40 GMT
Subject: RFR: 8333236: Test java/foreign/TestAccessModes.java is timing out
 after passing
In-Reply-To: <mLVkvSWgzjrvnm1R6MZxjacSbTN0CxdA5f5D3lqDti0=.bb215ff2-8bfd-4ce4-8986-522f0ef1af08@github.com>
References: <mLVkvSWgzjrvnm1R6MZxjacSbTN0CxdA5f5D3lqDti0=.bb215ff2-8bfd-4ce4-8986-522f0ef1af08@github.com>
Message-ID: <xNPiEtPhrhdykiv6DG3JIQOXfDNr53bvdxfPROYcwNs=.28b454d1-cf0f-4e79-a252-285ce411951a@github.com>

On Thu, 30 May 2024 16:15:22 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> This PR restores a var handle cache in `Utils::makeSegmentViewVarHandle`. The cache was moved to `ValueLayouts::varHandle` as part of [pull/19251](https://git.openjdk.org/jdk/pull/19251), on the basis that we want to optimize the common case like:
> 
> 
> ValueLayout layout = ...
> layout.varHandle().get(...)
> 
> 
> And that caching more complex var handles didn't seem to add value, given that, for these var handles, the logic in `LayoutPath` needs to adapt the returned var handle anyways.
> 
> But, `TestAccessModes` revealed a different picture - w/o any cache in `Utils` the test end up allocating 8963 var handle instances (instead of just 4), in each of the 4 runs the test includes. While this is admittedly a stress test, it seems nice to restore the level of sharing we had before [pull/19251](https://git.openjdk.org/jdk/pull/19251).

A different approach could be to find a way to add a per-layout cache. E.g. if the root layout is a group layout, that layout could have a cache for all the different var handles generated from it. The key would be the path element used to retrieve the var handle.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19485#issuecomment-2140148973

From darcy at openjdk.org  Thu May 30 16:44:21 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Thu, 30 May 2024 16:44:21 GMT
Subject: RFR: 8330182: Start of release updates for JDK 24 [v9]
In-Reply-To: <YKsEQWuI-vNTEDjOBInuEjf8AEcTL4QZ_F4JYUqoxwk=.5ed43782-6dec-4383-948d-d9966a85b3bf@github.com>
References: <YKsEQWuI-vNTEDjOBInuEjf8AEcTL4QZ_F4JYUqoxwk=.5ed43782-6dec-4383-948d-d9966a85b3bf@github.com>
Message-ID: <GhS6NRLILEG1FmXLVDy_fSyixDLQLTSGZQsFXNwJ2FI=.94839b39-99fb-4334-bbd4-33d23e459565@github.com>

> Get JDK 24 underway.

Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:

  Update symbol files for JDK 23 build 25.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/18787/files
  - new: https://git.openjdk.org/jdk/pull/18787/files/45e1c040..0d15aaf4

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18787&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18787&range=07-08

  Stats: 341 lines in 4 files changed: 340 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/18787.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18787/head:pull/18787

PR: https://git.openjdk.org/jdk/pull/18787

From jvernee at openjdk.org  Thu May 30 17:07:00 2024
From: jvernee at openjdk.org (Jorn Vernee)
Date: Thu, 30 May 2024 17:07:00 GMT
Subject: RFR: 8333236: Test java/foreign/TestAccessModes.java is timing out
 after passing
In-Reply-To: <mLVkvSWgzjrvnm1R6MZxjacSbTN0CxdA5f5D3lqDti0=.bb215ff2-8bfd-4ce4-8986-522f0ef1af08@github.com>
References: <mLVkvSWgzjrvnm1R6MZxjacSbTN0CxdA5f5D3lqDti0=.bb215ff2-8bfd-4ce4-8986-522f0ef1af08@github.com>
Message-ID: <YH9u0h82laNPYgeZ034P0bDITuDG6Faii7BAoRGINeA=.422531b0-d821-47ca-8632-d2e455df14fb@github.com>

On Thu, 30 May 2024 16:15:22 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> This PR restores a var handle cache in `Utils::makeSegmentViewVarHandle`. The cache was moved to `ValueLayouts::varHandle` as part of [pull/19251](https://git.openjdk.org/jdk/pull/19251), on the basis that we want to optimize the common case like:
> 
> 
> ValueLayout layout = ...
> layout.varHandle().get(...)
> 
> 
> And that caching more complex var handles didn't seem to add value, given that, for these var handles, the logic in `LayoutPath` needs to adapt the returned var handle anyways.
> 
> But, `TestAccessModes` revealed a different picture - w/o any cache in `Utils` the test end up allocating 8963 var handle instances (instead of just 4), in each of the 4 runs the test includes. While this is admittedly a stress test, it seems nice to restore the level of sharing we had before [pull/19251](https://git.openjdk.org/jdk/pull/19251).

I suggest leaving a comment to document which cases this cache is trying to address. I think that's mainly cases where the same ValueLayout is created many times in different places (instead of the same layout being reused, for which we already have a cache field on the layout instance itself).

-------------

Marked as reviewed by jvernee (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19485#pullrequestreview-2088881021

From darcy at openjdk.org  Thu May 30 17:11:31 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Thu, 30 May 2024 17:11:31 GMT
Subject: RFR: 8330182: Start of release updates for JDK 24 [v10]
In-Reply-To: <YKsEQWuI-vNTEDjOBInuEjf8AEcTL4QZ_F4JYUqoxwk=.5ed43782-6dec-4383-948d-d9966a85b3bf@github.com>
References: <YKsEQWuI-vNTEDjOBInuEjf8AEcTL4QZ_F4JYUqoxwk=.5ed43782-6dec-4383-948d-d9966a85b3bf@github.com>
Message-ID: <h_vQLALgmncaZI-FTAjoKsa2qUMVN7qZM1X_XklPuxI=.e31b097c-14c4-4a63-9f3f-929ba0f26b17@github.com>

> Get JDK 24 underway.

Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 18 commits:

 - Merge branch 'master' into JDK-8330188
 - Update symbol files for JDK 23 build 25.
 - Correct release year.
 - Merge branch 'master' into JDK-8330188
 - Add symbol files current with JDK 23 build 24.
 - Merge branch 'master' into JDK-8330188
 - Merge branch 'master' into JDK-8330188
 - Fix-up test.
 - Merge branch 'master' into JDK-8330188
 - Adjust test for deprecated options.
 - ... and 8 more: https://git.openjdk.org/jdk/compare/32636dcc...39a028c3

-------------

Changes: https://git.openjdk.org/jdk/pull/18787/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18787&range=09
  Stats: 2082 lines in 50 files changed: 2019 ins; 7 del; 56 mod
  Patch: https://git.openjdk.org/jdk/pull/18787.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18787/head:pull/18787

PR: https://git.openjdk.org/jdk/pull/18787

From iris at openjdk.org  Thu May 30 17:49:04 2024
From: iris at openjdk.org (Iris Clark)
Date: Thu, 30 May 2024 17:49:04 GMT
Subject: RFR: 8330182: Start of release updates for JDK 24 [v10]
In-Reply-To: <h_vQLALgmncaZI-FTAjoKsa2qUMVN7qZM1X_XklPuxI=.e31b097c-14c4-4a63-9f3f-929ba0f26b17@github.com>
References: <YKsEQWuI-vNTEDjOBInuEjf8AEcTL4QZ_F4JYUqoxwk=.5ed43782-6dec-4383-948d-d9966a85b3bf@github.com>
 <h_vQLALgmncaZI-FTAjoKsa2qUMVN7qZM1X_XklPuxI=.e31b097c-14c4-4a63-9f3f-929ba0f26b17@github.com>
Message-ID: <D5Rj2hFZEqdHTYjdQP4J55cblFImxqx7m-bf5cVt46U=.dea49b54-a0e2-4062-909f-619fb0f78b9e@github.com>

On Thu, 30 May 2024 17:11:31 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Get JDK 24 underway.
>
> Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 18 commits:
> 
>  - Merge branch 'master' into JDK-8330188
>  - Update symbol files for JDK 23 build 25.
>  - Correct release year.
>  - Merge branch 'master' into JDK-8330188
>  - Add symbol files current with JDK 23 build 24.
>  - Merge branch 'master' into JDK-8330188
>  - Merge branch 'master' into JDK-8330188
>  - Fix-up test.
>  - Merge branch 'master' into JDK-8330188
>  - Adjust test for deprecated options.
>  - ... and 8 more: https://git.openjdk.org/jdk/compare/32636dcc...39a028c3

Marked as reviewed by iris (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/18787#pullrequestreview-2089018766

From naoto at openjdk.org  Thu May 30 18:13:05 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 30 May 2024 18:13:05 GMT
Subject: RFR: 8333103: Re-examine the console provider loading
In-Reply-To: <n8AdYMDA3qvNTbm8CWI-wGOoGwBks-6jOfeefMboq18=.1585eb22-285d-4fe6-97f5-5162d5b516cd@github.com>
References: <M5dxmPs_RJJGqd344t3bMLPMiZmwdtxtbIVP9Bd-ons=.8c7525cc-e3a5-4ed5-81a6-e85398ee6ca6@github.com>
 <cGedShjEGjk6Su-gyXv_BSvKY8VPf1Rbh5FWpQ1Ea_4=.a0ad9532-91db-4918-bd2e-e15252b2edb9@github.com>
 <kGh8i2IkeuM5wNHC1mybHhqvS8pgpN_O35p-BtMnSxI=.0921c15a-ea95-48b9-9bba-e2993c876d98@github.com>
 <vSJN2UO7GQgMyRZ_4Fytuioz3nImPHPYUWU6dsmacws=.d9210a00-4a14-4f22-8d68-db7d87f3af15@github.com>
 <zLgCAUpJIvUZXNqpK_CLq4fm1iA6MvhItKVf8s6_ECg=.e0738cd1-cebb-4031-b2ee-2ba749deb58b@github.com>
 <n8AdYMDA3qvNTbm8CWI-wGOoGwBks-6jOfeefMboq18=.1585eb22-285d-4fe6-97f5-5162d5b516cd@github.com>
Message-ID: <XFA7puTbjaO_Bu2DeiP-HuJBOg3qewHOc8J-H_4SmlQ=.f949a85f-112e-487a-854e-812ec5c92feb@github.com>

On Thu, 30 May 2024 08:23:25 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> It's only semantically the same if we assume a module can only provide a single `JdkConsoleProvider`, no? The `break;` disallows multiple providers (for disjoint sets of charsets) in a single module.
>
> Claes has described the issue well. Like I said, `break` short-circuits the search. If a module can provide more than one console provider, the suggested stream-less replacement is **not** equivalent.
> 
> If a module can provide more than one console provider, not only the code needs to be fixed, but a relevant test should be added too. The test should be in this PR, but tagged with the initial bug, [8295803], not this (performance) bug.
> 
> [8295803]: https://bugs.openjdk.org/browse/JDK-8295803

In fact, this started simply for incorporating JLine implementation into Console, and using ServiceLoader was a mere means to load its impl as it resides outside the java.base module. So yes, module and its console implementation is 1:1, which is reflected by the system property `jdk.console` that takes the module name. So that `break;` effectively shortcut the unnecessary looping (I don't think it would happen btw).
That said, I think it needs to be described in the comment above that piece of code. I will add it shortly.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19467#discussion_r1621231072

From liach at openjdk.org  Thu May 30 18:42:06 2024
From: liach at openjdk.org (Chen Liang)
Date: Thu, 30 May 2024 18:42:06 GMT
Subject: RFR: 8330182: Start of release updates for JDK 24 [v9]
In-Reply-To: <GhS6NRLILEG1FmXLVDy_fSyixDLQLTSGZQsFXNwJ2FI=.94839b39-99fb-4334-bbd4-33d23e459565@github.com>
References: <YKsEQWuI-vNTEDjOBInuEjf8AEcTL4QZ_F4JYUqoxwk=.5ed43782-6dec-4383-948d-d9966a85b3bf@github.com>
 <GhS6NRLILEG1FmXLVDy_fSyixDLQLTSGZQsFXNwJ2FI=.94839b39-99fb-4334-bbd4-33d23e459565@github.com>
Message-ID: <_kfO09TJdTBjXUELlNSPOSGVckqS7Y9zQGFJa7mxhms=.c13df261-10fb-40da-969a-530a8a7ce1dc@github.com>

On Thu, 30 May 2024 16:44:21 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Get JDK 24 underway.
>
> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update symbol files for JDK 23 build 25.

src/jdk.compiler/share/data/symbols/jdk.incubator.foreign-N.sym.txt line 1:

> 1: #

Just curious, does CreateSymbols not track module migrations, now that jdk.incubator.foreign is completely merged into java.base?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18787#discussion_r1621274290

From prappo at openjdk.org  Thu May 30 18:42:05 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Thu, 30 May 2024 18:42:05 GMT
Subject: RFR: 8333103: Re-examine the console provider loading
In-Reply-To: <XFA7puTbjaO_Bu2DeiP-HuJBOg3qewHOc8J-H_4SmlQ=.f949a85f-112e-487a-854e-812ec5c92feb@github.com>
References: <M5dxmPs_RJJGqd344t3bMLPMiZmwdtxtbIVP9Bd-ons=.8c7525cc-e3a5-4ed5-81a6-e85398ee6ca6@github.com>
 <cGedShjEGjk6Su-gyXv_BSvKY8VPf1Rbh5FWpQ1Ea_4=.a0ad9532-91db-4918-bd2e-e15252b2edb9@github.com>
 <kGh8i2IkeuM5wNHC1mybHhqvS8pgpN_O35p-BtMnSxI=.0921c15a-ea95-48b9-9bba-e2993c876d98@github.com>
 <vSJN2UO7GQgMyRZ_4Fytuioz3nImPHPYUWU6dsmacws=.d9210a00-4a14-4f22-8d68-db7d87f3af15@github.com>
 <zLgCAUpJIvUZXNqpK_CLq4fm1iA6MvhItKVf8s6_ECg=.e0738cd1-cebb-4031-b2ee-2ba749deb58b@github.com>
 <n8AdYMDA3qvNTbm8CWI-wGOoGwBks-6jOfeefMboq18=.1585eb22-285d-4fe6-97f5-5162d5b516cd@github.com>
 <XFA7puTbjaO_Bu2DeiP-HuJBOg3qewHOc8J-H_4SmlQ=.f949a85f-112e-487a-854e-812ec5c92feb@github.com>
Message-ID: <aUuHMa4Nfn2Z7Qnzumd4vndU9iGHox5fZPBWC2E5zR8=.096a21ae-12e1-49e2-8a70-d1fbdb9c6a75@github.com>

On Thu, 30 May 2024 18:10:14 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Claes has described the issue well. Like I said, `break` short-circuits the search. If a module can provide more than one console provider, the suggested stream-less replacement is **not** equivalent.
>> 
>> If a module can provide more than one console provider, not only the code needs to be fixed, but a relevant test should be added too. The test should be in this PR, but tagged with the initial bug, [8295803], not this (performance) bug.
>> 
>> [8295803]: https://bugs.openjdk.org/browse/JDK-8295803
>
> In fact, this started simply for incorporating JLine implementation into Console, and using ServiceLoader was a mere means to load its impl as it resides outside the java.base module. So yes, module and its console implementation is 1:1, which is reflected by the system property `jdk.console` that takes the module name. So that `break;` effectively shortcut the unnecessary looping (I don't think it would happen btw).
> That said, I think it needs to be described in the comment above that piece of code. I will add it shortly.

So, it's the previous (stream) version that was more permissive and inadvertently so, yes?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19467#discussion_r1621273970

From naoto at openjdk.org  Thu May 30 18:49:01 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 30 May 2024 18:49:01 GMT
Subject: RFR: 8333103: Re-examine the console provider loading
In-Reply-To: <aUuHMa4Nfn2Z7Qnzumd4vndU9iGHox5fZPBWC2E5zR8=.096a21ae-12e1-49e2-8a70-d1fbdb9c6a75@github.com>
References: <M5dxmPs_RJJGqd344t3bMLPMiZmwdtxtbIVP9Bd-ons=.8c7525cc-e3a5-4ed5-81a6-e85398ee6ca6@github.com>
 <cGedShjEGjk6Su-gyXv_BSvKY8VPf1Rbh5FWpQ1Ea_4=.a0ad9532-91db-4918-bd2e-e15252b2edb9@github.com>
 <kGh8i2IkeuM5wNHC1mybHhqvS8pgpN_O35p-BtMnSxI=.0921c15a-ea95-48b9-9bba-e2993c876d98@github.com>
 <vSJN2UO7GQgMyRZ_4Fytuioz3nImPHPYUWU6dsmacws=.d9210a00-4a14-4f22-8d68-db7d87f3af15@github.com>
 <zLgCAUpJIvUZXNqpK_CLq4fm1iA6MvhItKVf8s6_ECg=.e0738cd1-cebb-4031-b2ee-2ba749deb58b@github.com>
 <n8AdYMDA3qvNTbm8CWI-wGOoGwBks-6jOfeefMboq18=.1585eb22-285d-4fe6-97f5-5162d5b516cd@github.com>
 <XFA7puTbjaO_Bu2DeiP-HuJBOg3qewHOc8J-H_4SmlQ=.f949a85f-112e-487a-854e-812ec5c92feb@github.com>
 <aUuHMa4Nfn2Z7Qnzumd4vndU9iGHox5fZPBWC2E5zR8=.096a21ae-12e1-49e2-8a70-d1fbdb9c6a75@github.com>
Message-ID: <-QBfP53hWal2_JmKd0q_-a90iIehpbFiBghL0kI4lBE=.8db2a50a-f133-444a-97da-b57b12a3a5bf@github.com>

On Thu, 30 May 2024 18:38:59 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> In fact, this started simply for incorporating JLine implementation into Console, and using ServiceLoader was a mere means to load its impl as it resides outside the java.base module. So yes, module and its console implementation is 1:1, which is reflected by the system property `jdk.console` that takes the module name. So that `break;` effectively shortcut the unnecessary looping (I don't think it would happen btw).
>> That said, I think it needs to be described in the comment above that piece of code. I will add it shortly.
>
> So, it's the previous (stream) version that was more permissive and inadvertently so, yes?

Yes, correct. If hypothetically Jline provided two impls, it were not specified which impl was used. Now we only use the first one found.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19467#discussion_r1621284108

From jlahoda at openjdk.org  Thu May 30 19:13:05 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Thu, 30 May 2024 19:13:05 GMT
Subject: RFR: 8330182: Start of release updates for JDK 24 [v9]
In-Reply-To: <_kfO09TJdTBjXUELlNSPOSGVckqS7Y9zQGFJa7mxhms=.c13df261-10fb-40da-969a-530a8a7ce1dc@github.com>
References: <YKsEQWuI-vNTEDjOBInuEjf8AEcTL4QZ_F4JYUqoxwk=.5ed43782-6dec-4383-948d-d9966a85b3bf@github.com>
 <GhS6NRLILEG1FmXLVDy_fSyixDLQLTSGZQsFXNwJ2FI=.94839b39-99fb-4334-bbd4-33d23e459565@github.com>
 <_kfO09TJdTBjXUELlNSPOSGVckqS7Y9zQGFJa7mxhms=.c13df261-10fb-40da-969a-530a8a7ce1dc@github.com>
Message-ID: <Nk3avVtqWTHpYmwBk8wXj5zyBThclSzR9kSgCvaDEuM=.31f73d15-8b9a-488a-82fb-392e051c2bf1@github.com>

On Thu, 30 May 2024 18:39:19 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update symbol files for JDK 23 build 25.
>
> src/jdk.compiler/share/data/symbols/jdk.incubator.foreign-N.sym.txt line 1:
> 
>> 1: #
> 
> Just curious, does CreateSymbols not track module migrations, now that jdk.incubator.foreign is completely merged into java.base?

When writing these symbol files, CreateSymbols does not keep track where a given package was in a given version, and puts packages to files based on the first version where the package was first introduced. Technically, it should not matter, as the assignment of classes/packages to modules is not based on the file from which the description of the class was read. So, so far, it didn't seem necessary to keep track of package movement for writing of these files. But it is feasible to do so, if the need arises. (When writing ct.sym, it keeps track of the exact package module for every version, of course.)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18787#discussion_r1621320340

From dl at openjdk.org  Thu May 30 19:14:35 2024
From: dl at openjdk.org (Doug Lea)
Date: Thu, 30 May 2024 19:14:35 GMT
Subject: RFR: 8322732: ForkJoinPool may underutilize cores in async mode
 [v14]
In-Reply-To: <xRyDMAsSZ7obqpr3Aoc5qrHqILeJMxFVCeiRdctMI3U=.d5d3cd56-32eb-4431-ac01-081822fc86c6@github.com>
References: <xRyDMAsSZ7obqpr3Aoc5qrHqILeJMxFVCeiRdctMI3U=.d5d3cd56-32eb-4431-ac01-081822fc86c6@github.com>
Message-ID: <FoZIhTIkHJre1JaaZcYIiy6DhxH2DJcHjH6tsOyQ0Lk=.85e95000-6593-4ada-93ff-8323983bfa95@github.com>

> This set of changes address causes of poor utilization with small numbers of cores due to overly aggressive contention avoidance. A number of further adjustments were needed to still avoid most contention effects in deployments with large numbers of cores

Doug Lea has updated the pull request incrementally with one additional commit since the last revision:

  Reinstate quiescence signals

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19131/files
  - new: https://git.openjdk.org/jdk/pull/19131/files/398e5c6a..47ce3643

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19131&range=13
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19131&range=12-13

  Stats: 15 lines in 1 file changed: 4 ins; 1 del; 10 mod
  Patch: https://git.openjdk.org/jdk/pull/19131.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19131/head:pull/19131

PR: https://git.openjdk.org/jdk/pull/19131

From ihse at openjdk.org  Thu May 30 19:20:24 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 30 May 2024 19:20:24 GMT
Subject: RFR: 8333301: Remove static builds using --enable-static-build
Message-ID: <Hqzi-1Qtf2u8Jxd3kysadUcT5MVPXTNjPSTkxVPO2n0=.43501180-2814-43e9-b952-d40a9f767362@github.com>

The original way of building static libraries in the JDK was to use the configure argument --enable-static-build, which set the value of the make variable STATIC_BUILD. (Note that this is not the same as the source code definition STATIC_BUILD, which will be set by other means as well.)

This method only ever worked on macOS, and has long since stopped working. It was originally introduced for the Mobile Project, but I've now learn that not even they use it anymore.

It just adds clutter to the build system, and should be removed.

-------------

Commit messages:
 - 8333301: Remove static builds using --enable-static-build

Changes: https://git.openjdk.org/jdk/pull/19487/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19487&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8333301
  Stats: 218 lines in 14 files changed: 4 ins; 206 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/19487.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19487/head:pull/19487

PR: https://git.openjdk.org/jdk/pull/19487

From duke at openjdk.org  Thu May 30 19:30:12 2024
From: duke at openjdk.org (jengebr)
Date: Thu, 30 May 2024 19:30:12 GMT
Subject: RFR: 8332586: Avoid cloning empty arrays in
 java.lang.reflect.{Method,Constructor}
Message-ID: <R5bpPuNj1Q2M6uo6_2d6out53rqb17tpheL1jcBDcXw=.3fe0cb7f-1d37-47b0-b4ac-5b7b3ef01bd4@github.com>

Improve `java/lang/reflect/Method.java`  by eliminating needless cloning of Class[0] instances.  This cloning is intended to prevent callers from changing array contents, but smany Methods have zero exceptions or zero parameters, and returning the original `Class[0]` is sufficient.

-------------

Commit messages:
 - Merge branch 'openjdk:master' into Method_ArrayCloning
 - Updating copyright year
 - Merge branch 'openjdk:master' into Method_ArrayCloning
 - Merge branch 'openjdk:master' into Method_ArrayCloning
 - Reverting to expressions rather than utility method
 - Moving utility method to AccessibleObject
 - Fixing whitespace
 - Extracted logic to utility method
 - Expanding no-cloning coverage to Constructor
 - Reducing array allocation rate by eliminating cloned Class[0]

Changes: https://git.openjdk.org/jdk/pull/19327/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19327&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8332586
  Stats: 7 lines in 2 files changed: 0 ins; 1 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/19327.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19327/head:pull/19327

PR: https://git.openjdk.org/jdk/pull/19327

From liach at openjdk.org  Thu May 30 19:30:12 2024
From: liach at openjdk.org (Chen Liang)
Date: Thu, 30 May 2024 19:30:12 GMT
Subject: RFR: 8332586: Avoid cloning empty arrays in
 java.lang.reflect.{Method,Constructor}
In-Reply-To: <R5bpPuNj1Q2M6uo6_2d6out53rqb17tpheL1jcBDcXw=.3fe0cb7f-1d37-47b0-b4ac-5b7b3ef01bd4@github.com>
References: <R5bpPuNj1Q2M6uo6_2d6out53rqb17tpheL1jcBDcXw=.3fe0cb7f-1d37-47b0-b4ac-5b7b3ef01bd4@github.com>
Message-ID: <UfcMBfXOT5WR54aedx4BBty9JvPkAoo8fCDxekExYI4=.209c56ba-1ccc-443d-a833-cf3f6906d711@github.com>

On Tue, 21 May 2024 13:49:18 GMT, jengebr <duke at openjdk.org> wrote:

> Improve `java/lang/reflect/Method.java`  by eliminating needless cloning of Class[0] instances.  This cloning is intended to prevent callers from changing array contents, but smany Methods have zero exceptions or zero parameters, and returning the original `Class[0]` is sufficient.

I think we should probably create a utility method dedicated to clone only mutable Class arrays. This utility can be used for the other methods in other reflection classes.

Can you update the ending copyright years from 2023 to 2024 on the 2nd line of the 2 modified files?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19327#issuecomment-2122710633
PR Comment: https://git.openjdk.org/jdk/pull/19327#issuecomment-2130420945

From liach at openjdk.org  Thu May 30 19:30:12 2024
From: liach at openjdk.org (Chen Liang)
Date: Thu, 30 May 2024 19:30:12 GMT
Subject: RFR: 8332586: Avoid cloning empty arrays in
 java.lang.reflect.{Method,Constructor}
In-Reply-To: <j-Fvi9FpQ7GwZLFn8VWODGmKJq6LmrOkSAfbipIdio0=.afaffce3-a542-4a48-968b-1a9b0502e89d@github.com>
References: <R5bpPuNj1Q2M6uo6_2d6out53rqb17tpheL1jcBDcXw=.3fe0cb7f-1d37-47b0-b4ac-5b7b3ef01bd4@github.com>
 <j-Fvi9FpQ7GwZLFn8VWODGmKJq6LmrOkSAfbipIdio0=.afaffce3-a542-4a48-968b-1a9b0502e89d@github.com>
Message-ID: <dPFcAYrhiFvC5XOQT2f6RzuO9x7-BKYzo4958zwCLL4=.e9132895-1947-4f12-8da6-0ac608418509@github.com>

On Tue, 21 May 2024 14:07:29 GMT, jengebr <duke at openjdk.org> wrote:

> Any suggestions?

I would recommend a new method `copyClasses`/`copyTypes` in `jdk.internal.reflect.ReflectionFactory`, as it already has related `copyConstructor` and `getExecutableSharedParameterTypes` methods.

Also, can you rename your PR's title to `8332586: Avoid cloning empty arrays in java.lang.reflect.{Method,Constructor}` for the bot to handle this?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19327#issuecomment-2122798223

From duke at openjdk.org  Thu May 30 19:30:12 2024
From: duke at openjdk.org (jengebr)
Date: Thu, 30 May 2024 19:30:12 GMT
Subject: RFR: 8332586: Avoid cloning empty arrays in
 java.lang.reflect.{Method,Constructor}
In-Reply-To: <R5bpPuNj1Q2M6uo6_2d6out53rqb17tpheL1jcBDcXw=.3fe0cb7f-1d37-47b0-b4ac-5b7b3ef01bd4@github.com>
References: <R5bpPuNj1Q2M6uo6_2d6out53rqb17tpheL1jcBDcXw=.3fe0cb7f-1d37-47b0-b4ac-5b7b3ef01bd4@github.com>
Message-ID: <j-Fvi9FpQ7GwZLFn8VWODGmKJq6LmrOkSAfbipIdio0=.afaffce3-a542-4a48-968b-1a9b0502e89d@github.com>

On Tue, 21 May 2024 13:49:18 GMT, jengebr <duke at openjdk.org> wrote:

> Improve `java/lang/reflect/Method.java`  by eliminating needless cloning of Class[0] instances.  This cloning is intended to prevent callers from changing array contents, but smany Methods have zero exceptions or zero parameters, and returning the original `Class[0]` is sufficient.

Thanks for the suggestion!  I'll definitely add coverage of the other instances in this package, but I don't see an obvious place to put a utility method.  Any suggestions?

New method added, PR renamed.

OCA process is progressing, once finalized I'll rerun checks and publish the PR.

OCA completed, ready for review.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19327#issuecomment-2122723979
PR Comment: https://git.openjdk.org/jdk/pull/19327#issuecomment-2122984663
PR Comment: https://git.openjdk.org/jdk/pull/19327#issuecomment-2127017202
PR Comment: https://git.openjdk.org/jdk/pull/19327#issuecomment-2140731037

From shade at openjdk.org  Thu May 30 19:30:13 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 30 May 2024 19:30:13 GMT
Subject: RFR: 8332586: Avoid cloning empty arrays in
 java.lang.reflect.{Method,Constructor}
In-Reply-To: <R5bpPuNj1Q2M6uo6_2d6out53rqb17tpheL1jcBDcXw=.3fe0cb7f-1d37-47b0-b4ac-5b7b3ef01bd4@github.com>
References: <R5bpPuNj1Q2M6uo6_2d6out53rqb17tpheL1jcBDcXw=.3fe0cb7f-1d37-47b0-b4ac-5b7b3ef01bd4@github.com>
Message-ID: <wWyb1JPXNXH8kmEvRxzQYGFRtqsIiGWEBvZsDao42Xg=.36910126-4813-4e50-b985-f2177e4441ed@github.com>

On Tue, 21 May 2024 13:49:18 GMT, jengebr <duke at openjdk.org> wrote:

> Improve `java/lang/reflect/Method.java`  by eliminating needless cloning of Class[0] instances.  This cloning is intended to prevent callers from changing array contents, but smany Methods have zero exceptions or zero parameters, and returning the original `Class[0]` is sufficient.

Please also enable GHA testing: https://github.com/jengebr/jdk/actions. You may need to trigger the test run manually after this, since the PR hook have already missed it. Go to "OpenJDK Sanity Checks" on the left on that page, then select your branch on in the drop-down on the right, and trigger the run.

src/java.base/share/classes/jdk/internal/reflect/ReflectionFactory.java line 249:

> 247:      * the original can safely be reused.
> 248:      */
> 249:     public Class<?>[] copyClasses(Class<?>[] classes) {

There is no need to make this utility method non-static. This would also obviate the need for having an instance of `ReflectionFactory` to access it. 

Additionally, at the risk of more bikeshedding, I think this utility method is better suited in `AccessibleObject` base class, with package-private visibility. Putting the util methods in `ReflectionFactory` erodes this comment a bit:


    <P> The methods in this class are extremely unsafe and can cause
    subversion of both the language and the verifier. For this reason,
    they are all instance methods, and access to the constructor of
    this factory is guarded by a security check, in similar style to
    {@link jdk.internal.misc.Unsafe}. </P>

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19327#issuecomment-2124338419
PR Review Comment: https://git.openjdk.org/jdk/pull/19327#discussion_r1609635793

From duke at openjdk.org  Thu May 30 19:30:13 2024
From: duke at openjdk.org (jengebr)
Date: Thu, 30 May 2024 19:30:13 GMT
Subject: RFR: 8332586: Avoid cloning empty arrays in
 java.lang.reflect.{Method,Constructor}
In-Reply-To: <wWyb1JPXNXH8kmEvRxzQYGFRtqsIiGWEBvZsDao42Xg=.36910126-4813-4e50-b985-f2177e4441ed@github.com>
References: <R5bpPuNj1Q2M6uo6_2d6out53rqb17tpheL1jcBDcXw=.3fe0cb7f-1d37-47b0-b4ac-5b7b3ef01bd4@github.com>
 <wWyb1JPXNXH8kmEvRxzQYGFRtqsIiGWEBvZsDao42Xg=.36910126-4813-4e50-b985-f2177e4441ed@github.com>
Message-ID: <saeX4vxaH-4p5KiXyUS-5EK3CVQNHaUCMxU9IHjHIvA=.58b6ee69-201e-465a-8518-cf0c5ea61c92@github.com>

On Wed, 22 May 2024 09:44:18 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Please also enable GHA testing: https://github.com/jengebr/jdk/actions. You may need to trigger the test run manually after this, since the PR hook have already missed it. Go to "OpenJDK Sanity Checks" on the left on that page, then select your branch on in the drop-down on the right, and trigger the run.

Thank you for the detailed instructions, workflow is triggered.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19327#issuecomment-2124771545

From duke at openjdk.org  Thu May 30 19:30:13 2024
From: duke at openjdk.org (jengebr)
Date: Thu, 30 May 2024 19:30:13 GMT
Subject: RFR: 8332586: Avoid cloning empty arrays in
 java.lang.reflect.{Method,Constructor}
In-Reply-To: <UfcMBfXOT5WR54aedx4BBty9JvPkAoo8fCDxekExYI4=.209c56ba-1ccc-443d-a833-cf3f6906d711@github.com>
References: <R5bpPuNj1Q2M6uo6_2d6out53rqb17tpheL1jcBDcXw=.3fe0cb7f-1d37-47b0-b4ac-5b7b3ef01bd4@github.com>
 <UfcMBfXOT5WR54aedx4BBty9JvPkAoo8fCDxekExYI4=.209c56ba-1ccc-443d-a833-cf3f6906d711@github.com>
Message-ID: <pKIln-Czy7JP2KLSqNH6tqwu6faCYhqmH0fljnkpreM=.db641e8c-f00e-4327-891b-7df27ddb76c5@github.com>

On Fri, 24 May 2024 21:59:58 GMT, Chen Liang <liach at openjdk.org> wrote:

> Can you update the ending copyright years from 2023 to 2024 on the 2nd line of the 2 modified files?

Done, thank you.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19327#issuecomment-2135215681

From duke at openjdk.org  Thu May 30 19:30:14 2024
From: duke at openjdk.org (jengebr)
Date: Thu, 30 May 2024 19:30:14 GMT
Subject: RFR: 8332586: Avoid cloning empty arrays in
 java.lang.reflect.{Method,Constructor}
In-Reply-To: <urI3243XmbDPMDy44JJ94CJ0xedd4b9Fmof2_N_WAsc=.0ec4cbb4-0a17-4b3c-9dc4-0999b83c30b9@github.com>
References: <R5bpPuNj1Q2M6uo6_2d6out53rqb17tpheL1jcBDcXw=.3fe0cb7f-1d37-47b0-b4ac-5b7b3ef01bd4@github.com>
 <wWyb1JPXNXH8kmEvRxzQYGFRtqsIiGWEBvZsDao42Xg=.36910126-4813-4e50-b985-f2177e4441ed@github.com>
 <urI3243XmbDPMDy44JJ94CJ0xedd4b9Fmof2_N_WAsc=.0ec4cbb4-0a17-4b3c-9dc4-0999b83c30b9@github.com>
Message-ID: <z0BMLK-XsvV2LEpfUJ68BG5oepleFmb-68Hxc5ePPa4=.ee3e5cbc-beb9-4898-b825-8e08d8294539@github.com>

On Wed, 22 May 2024 10:27:16 GMT, Chen Liang <liach at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/reflect/ReflectionFactory.java line 249:
>> 
>>> 247:      * the original can safely be reused.
>>> 248:      */
>>> 249:     public Class<?>[] copyClasses(Class<?>[] classes) {
>> 
>> There is no need to make this utility method non-static. This would also obviate the need for having an instance of `ReflectionFactory` to access it. 
>> 
>> Additionally, at the risk of more bikeshedding, I think this utility method is better suited in `AccessibleObject` base class, with package-private visibility. Putting the util methods in `ReflectionFactory` erodes this comment a bit:
>> 
>> 
>>     <P> The methods in this class are extremely unsafe and can cause
>>     subversion of both the language and the verifier. For this reason,
>>     they are all instance methods, and access to the constructor of
>>     this factory is guarded by a security check, in similar style to
>>     {@link jdk.internal.misc.Unsafe}. </P>
>
> Can't this be used by class cloning interfaces too?

@liach I see such an opportunity in `Proxy.getProxyConstructor`, is that what you have in mind?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19327#discussion_r1609907464

From liach at openjdk.org  Thu May 30 19:30:14 2024
From: liach at openjdk.org (Chen Liang)
Date: Thu, 30 May 2024 19:30:14 GMT
Subject: RFR: 8332586: Avoid cloning empty arrays in
 java.lang.reflect.{Method,Constructor}
In-Reply-To: <nNYiXGtqTV2IpoWw1F2ngrxYO5Tf3yFUFWWvAMAHCUQ=.5496bc84-d8f1-4fd7-b0aa-3bd61e2bc6dc@github.com>
References: <R5bpPuNj1Q2M6uo6_2d6out53rqb17tpheL1jcBDcXw=.3fe0cb7f-1d37-47b0-b4ac-5b7b3ef01bd4@github.com>
 <wWyb1JPXNXH8kmEvRxzQYGFRtqsIiGWEBvZsDao42Xg=.36910126-4813-4e50-b985-f2177e4441ed@github.com>
 <urI3243XmbDPMDy44JJ94CJ0xedd4b9Fmof2_N_WAsc=.0ec4cbb4-0a17-4b3c-9dc4-0999b83c30b9@github.com>
 <z0BMLK-XsvV2LEpfUJ68BG5oepleFmb-68Hxc5ePPa4=.ee3e5cbc-beb9-4898-b825-8e08d8294539@github.com>
 <3JU7e5YOg-8JNc0973MioDwZIAN4RpHazhmD5gUXQDw=.9f85d606-3192-45d2-927b-179e84aef3dd@github.com>
 <nNYiXGtqTV2IpoWw1F2ngrxYO5Tf3yFUFWWvAMAHCUQ=.5496bc84-d8f1-4fd7-b0aa-3bd61e2bc6dc@github.com>
Message-ID: <siqI6ZZBK4jp0ZTiTrW_s_bCVBFS9X9WHNgpwF6BmOU=.3e861fc9-7e2f-4a14-b6ee-1013655a6c97@github.com>

On Wed, 22 May 2024 14:24:40 GMT, jengebr <duke at openjdk.org> wrote:

>> No, I mean here: https://github.com/openjdk/jdk/blob/4f1a10f84bcfadef263a0890b6834ccd3d5bb52f/src/java.base/share/classes/java/lang/Class.java#L1329
>> 
>> (That's also why I suggest putting the utiltiy method in ReflectionFactory instead of AccessibleObject or Executable)
>> 
>> `Proxy` is meaningless with an empty list of interfaces, as it's solely for implementing interfaces and delegating method calls to the given InvocationHandler. So I would ignore that scenario.
>
> Thanks.  Unfortunately the variable `cloneArray` is actually a method parameter, and most of the callers pass in `false` - so using this utility method to control cloning would actually introduce cloning in several places where it is explicitly avoided.  We may get a performance gain by modifying `Class.getInterfaces()` directly (the sole caller that passes `true`) then eliminating the parameter, then modifying each caller, etc. but that feels like a separate change inspired by this one.
> 
> Thoughts?

Why can't you do something like this:

return cloneArray ? ReflectionFactory.copyClasses(interfaces) : interfaces;


Alternatively, your proposal is a good one too; we can rename this `getInterfaces(boolean)` to `getInterfacesShared()` (like `getSharedEnumConstants()`) and move this copy operation to `getInterfaces()` as you suggest.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19327#discussion_r1610109601

From shade at openjdk.org  Thu May 30 19:30:14 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 30 May 2024 19:30:14 GMT
Subject: RFR: 8332586: Avoid cloning empty arrays in
 java.lang.reflect.{Method,Constructor}
In-Reply-To: <mlNYFhkfw_VYSzOodQscBZCKVmMyxzC1eHVUqz8DH9Y=.4729a699-1435-4e93-b396-55732359d1ff@github.com>
References: <R5bpPuNj1Q2M6uo6_2d6out53rqb17tpheL1jcBDcXw=.3fe0cb7f-1d37-47b0-b4ac-5b7b3ef01bd4@github.com>
 <wWyb1JPXNXH8kmEvRxzQYGFRtqsIiGWEBvZsDao42Xg=.36910126-4813-4e50-b985-f2177e4441ed@github.com>
 <urI3243XmbDPMDy44JJ94CJ0xedd4b9Fmof2_N_WAsc=.0ec4cbb4-0a17-4b3c-9dc4-0999b83c30b9@github.com>
 <z0BMLK-XsvV2LEpfUJ68BG5oepleFmb-68Hxc5ePPa4=.ee3e5cbc-beb9-4898-b825-8e08d8294539@github.com>
 <3JU7e5YOg-8JNc0973MioDwZIAN4RpHazhmD5gUXQDw=.9f85d606-3192-45d2-927b-179e84aef3dd@github.com>
 <nNYiXGtqTV2IpoWw1F2ngrxYO5Tf3yFUFWWvAMAHCUQ=.5496bc84-d8f1-4fd7-b0aa-3bd61e2bc6dc@github.com>
 <siqI6ZZBK4jp0ZTiTrW_s_bCVBFS9X9WHNgpwF6BmOU=.3e861fc9-7e2f-4a14-b6ee-1013655a6c97@github.com>
 <Zj4re-mvBs370qK5lLv-3N7NwocJSe_ER9KzjxbYhW4=.6a2af5ea-2cfe-4631-a7e5-512133669f71@github.com>
 <mlNYFhkfw_VYSzOodQscBZCKVmMyxzC1eHVUqz8DH9Y=.4729a699-1435-4e93-b396-55732359d1ff@github.com>
Message-ID: <1TGp8BAli2zXdkqBqdV4Imc4d9Hl0w92NlRbPpqzijQ=.9e2149eb-5db6-4717-ac5d-49fb9ea4c36b@github.com>

On Wed, 22 May 2024 19:48:49 GMT, Chen Liang <liach at openjdk.org> wrote:

>> I really see no reason to try and save on re-use of this one-line method for _everything_. In fact, I do not quite see a very compelling reason to even have the utility method. Sharing the code between `Method` and `Constructor` is clean enough and provides a good balance between reuse and cleanliness. Everything else can have the copy of the method definition, if needed.
>
> Alternatively, if a utility method is overkill, we can inline these to `Executable`:
> 
> public Class<?>[] getParameterTypes() {
>     var shared = getSharedParameterTypes();
>     return shared.length == 0 ? shared : shared.clone();
> }
> 
> And the overrides in `Method` and `Constructor` will simply call super; the declarations are kept to preserve the API documentation.

I had to read JLS to confirm that changing the `abstract` method to non-abstract one does not break compatibility. 

I am still thinking that we are overthinking this: the readability/maintainability benefits for introducing a one-liner utility method are slim at best. I believe we are spending the disproportionate time on this. So if we cannot agree where to put the utility method -- which implies there is no good place for it -- let's not do it at all. Inline the ternary selector in 4 affected places, and be done with it.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19327#discussion_r1611304563

From liach at openjdk.org  Thu May 30 19:30:14 2024
From: liach at openjdk.org (Chen Liang)
Date: Thu, 30 May 2024 19:30:14 GMT
Subject: RFR: 8332586: Avoid cloning empty arrays in
 java.lang.reflect.{Method,Constructor}
In-Reply-To: <z0BMLK-XsvV2LEpfUJ68BG5oepleFmb-68Hxc5ePPa4=.ee3e5cbc-beb9-4898-b825-8e08d8294539@github.com>
References: <R5bpPuNj1Q2M6uo6_2d6out53rqb17tpheL1jcBDcXw=.3fe0cb7f-1d37-47b0-b4ac-5b7b3ef01bd4@github.com>
 <wWyb1JPXNXH8kmEvRxzQYGFRtqsIiGWEBvZsDao42Xg=.36910126-4813-4e50-b985-f2177e4441ed@github.com>
 <urI3243XmbDPMDy44JJ94CJ0xedd4b9Fmof2_N_WAsc=.0ec4cbb4-0a17-4b3c-9dc4-0999b83c30b9@github.com>
 <z0BMLK-XsvV2LEpfUJ68BG5oepleFmb-68Hxc5ePPa4=.ee3e5cbc-beb9-4898-b825-8e08d8294539@github.com>
Message-ID: <3JU7e5YOg-8JNc0973MioDwZIAN4RpHazhmD5gUXQDw=.9f85d606-3192-45d2-927b-179e84aef3dd@github.com>

On Wed, 22 May 2024 12:58:40 GMT, jengebr <duke at openjdk.org> wrote:

>> Can't this be used by class cloning interfaces too?
>
> @liach I see such an opportunity in `Proxy.getProxyConstructor`, is that what you have in mind?

No, I mean here: https://github.com/openjdk/jdk/blob/4f1a10f84bcfadef263a0890b6834ccd3d5bb52f/src/java.base/share/classes/java/lang/Class.java#L1329

(That's also why I suggest putting the utiltiy method in ReflectionFactory instead of AccessibleObject or Executable)

`Proxy` is meaningless with an empty list of interfaces, as it's solely for implementing interfaces and delegating method calls to the given InvocationHandler. So I would ignore that scenario.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19327#discussion_r1609992490

From duke at openjdk.org  Thu May 30 19:30:14 2024
From: duke at openjdk.org (jengebr)
Date: Thu, 30 May 2024 19:30:14 GMT
Subject: RFR: 8332586: Avoid cloning empty arrays in
 java.lang.reflect.{Method,Constructor}
In-Reply-To: <1TGp8BAli2zXdkqBqdV4Imc4d9Hl0w92NlRbPpqzijQ=.9e2149eb-5db6-4717-ac5d-49fb9ea4c36b@github.com>
References: <R5bpPuNj1Q2M6uo6_2d6out53rqb17tpheL1jcBDcXw=.3fe0cb7f-1d37-47b0-b4ac-5b7b3ef01bd4@github.com>
 <wWyb1JPXNXH8kmEvRxzQYGFRtqsIiGWEBvZsDao42Xg=.36910126-4813-4e50-b985-f2177e4441ed@github.com>
 <urI3243XmbDPMDy44JJ94CJ0xedd4b9Fmof2_N_WAsc=.0ec4cbb4-0a17-4b3c-9dc4-0999b83c30b9@github.com>
 <z0BMLK-XsvV2LEpfUJ68BG5oepleFmb-68Hxc5ePPa4=.ee3e5cbc-beb9-4898-b825-8e08d8294539@github.com>
 <3JU7e5YOg-8JNc0973MioDwZIAN4RpHazhmD5gUXQDw=.9f85d606-3192-45d2-927b-179e84aef3dd@github.com>
 <nNYiXGtqTV2IpoWw1F2ngrxYO5Tf3yFUFWWvAMAHCUQ=.5496bc84-d8f1-4fd7-b0aa-3bd61e2bc6dc@github.com>
 <siqI6ZZBK4jp0ZTiTrW_s_bCVBFS9X9WHNgpwF6BmOU=.3e861fc9-7e2f-4a14-b6ee-1013655a6c97@github.com>
 <Zj4re-mvBs370qK5lLv-3N7NwocJSe_ER9KzjxbYhW4=.6a2af5ea-2cfe-4631-a7e5-512133669f71@github.com>
 <mlNYFhkfw_VYSzOodQscBZCKVmMyxzC1eHVUqz8DH9Y=.4729a699-1435-4e93-b396-55732359d1ff@github.com>
 <1TGp8BAli2zXdkqBqdV4Imc4d9Hl0w92NlRbPpqzijQ=.9e2149eb-5db6-4717-ac5d-49fb9ea4c36b@github.com>
Message-ID: <YoEtAKiLl1EhcLXUKGwgCTs8baFG9O6sX__0Vjn9uA8=.0f96e34c-96e6-4a1a-b80d-510528c02de6@github.com>

On Thu, 23 May 2024 09:05:09 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Alternatively, if a utility method is overkill, we can inline these to `Executable`:
>> 
>> public Class<?>[] getParameterTypes() {
>>     var shared = getSharedParameterTypes();
>>     return shared.length == 0 ? shared : shared.clone();
>> }
>> 
>> And the overrides in `Method` and `Constructor` will simply call super; the declarations are kept to preserve the API documentation.
>
> I had to read JLS to confirm that changing the `abstract` method to non-abstract one does not break compatibility. 
> 
> I am still thinking that we are overthinking this: the readability/maintainability benefits for introducing a one-liner utility method are slim at best. I believe we are spending the disproportionate time on this. So if we cannot agree where to put the utility method -- which implies there is no good place for it -- let's not do it at all. Inline the ternary selector in 4 affected places, and be done with it.

I've reverted to ternary logic.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19327#discussion_r1611628951

From duke at openjdk.org  Thu May 30 19:30:14 2024
From: duke at openjdk.org (jengebr)
Date: Thu, 30 May 2024 19:30:14 GMT
Subject: RFR: 8332586: Avoid cloning empty arrays in
 java.lang.reflect.{Method,Constructor}
In-Reply-To: <3JU7e5YOg-8JNc0973MioDwZIAN4RpHazhmD5gUXQDw=.9f85d606-3192-45d2-927b-179e84aef3dd@github.com>
References: <R5bpPuNj1Q2M6uo6_2d6out53rqb17tpheL1jcBDcXw=.3fe0cb7f-1d37-47b0-b4ac-5b7b3ef01bd4@github.com>
 <wWyb1JPXNXH8kmEvRxzQYGFRtqsIiGWEBvZsDao42Xg=.36910126-4813-4e50-b985-f2177e4441ed@github.com>
 <urI3243XmbDPMDy44JJ94CJ0xedd4b9Fmof2_N_WAsc=.0ec4cbb4-0a17-4b3c-9dc4-0999b83c30b9@github.com>
 <z0BMLK-XsvV2LEpfUJ68BG5oepleFmb-68Hxc5ePPa4=.ee3e5cbc-beb9-4898-b825-8e08d8294539@github.com>
 <3JU7e5YOg-8JNc0973MioDwZIAN4RpHazhmD5gUXQDw=.9f85d606-3192-45d2-927b-179e84aef3dd@github.com>
Message-ID: <nNYiXGtqTV2IpoWw1F2ngrxYO5Tf3yFUFWWvAMAHCUQ=.5496bc84-d8f1-4fd7-b0aa-3bd61e2bc6dc@github.com>

On Wed, 22 May 2024 13:44:59 GMT, Chen Liang <liach at openjdk.org> wrote:

>> @liach I see such an opportunity in `Proxy.getProxyConstructor`, is that what you have in mind?
>
> No, I mean here: https://github.com/openjdk/jdk/blob/4f1a10f84bcfadef263a0890b6834ccd3d5bb52f/src/java.base/share/classes/java/lang/Class.java#L1329
> 
> (That's also why I suggest putting the utiltiy method in ReflectionFactory instead of AccessibleObject or Executable)
> 
> `Proxy` is meaningless with an empty list of interfaces, as it's solely for implementing interfaces and delegating method calls to the given InvocationHandler. So I would ignore that scenario.

Thanks.  Unfortunately the variable `cloneArray` is actually a method parameter, and most of the callers pass in `false` - so using this utility method to control cloning would actually introduce cloning in several places where it is explicitly avoided.  We may get a performance gain by modifying `Class.getInterfaces()` directly (the sole caller that passes `true`) then eliminating the parameter, then modifying each caller, etc. but that feels like a separate change inspired by this one.

Thoughts?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19327#discussion_r1610079752

From liach at openjdk.org  Thu May 30 19:30:14 2024
From: liach at openjdk.org (Chen Liang)
Date: Thu, 30 May 2024 19:30:14 GMT
Subject: RFR: 8332586: Avoid cloning empty arrays in
 java.lang.reflect.{Method,Constructor}
In-Reply-To: <wWyb1JPXNXH8kmEvRxzQYGFRtqsIiGWEBvZsDao42Xg=.36910126-4813-4e50-b985-f2177e4441ed@github.com>
References: <R5bpPuNj1Q2M6uo6_2d6out53rqb17tpheL1jcBDcXw=.3fe0cb7f-1d37-47b0-b4ac-5b7b3ef01bd4@github.com>
 <wWyb1JPXNXH8kmEvRxzQYGFRtqsIiGWEBvZsDao42Xg=.36910126-4813-4e50-b985-f2177e4441ed@github.com>
Message-ID: <urI3243XmbDPMDy44JJ94CJ0xedd4b9Fmof2_N_WAsc=.0ec4cbb4-0a17-4b3c-9dc4-0999b83c30b9@github.com>

On Wed, 22 May 2024 09:39:50 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Improve `java/lang/reflect/Method.java`  by eliminating needless cloning of Class[0] instances.  This cloning is intended to prevent callers from changing array contents, but smany Methods have zero exceptions or zero parameters, and returning the original `Class[0]` is sufficient.
>
> src/java.base/share/classes/jdk/internal/reflect/ReflectionFactory.java line 249:
> 
>> 247:      * the original can safely be reused.
>> 248:      */
>> 249:     public Class<?>[] copyClasses(Class<?>[] classes) {
> 
> There is no need to make this utility method non-static. This would also obviate the need for having an instance of `ReflectionFactory` to access it. 
> 
> Additionally, at the risk of more bikeshedding, I think this utility method is better suited in `AccessibleObject` base class, with package-private visibility. Putting the util methods in `ReflectionFactory` erodes this comment a bit:
> 
> 
>     <P> The methods in this class are extremely unsafe and can cause
>     subversion of both the language and the verifier. For this reason,
>     they are all instance methods, and access to the constructor of
>     this factory is guarded by a security check, in similar style to
>     {@link jdk.internal.misc.Unsafe}. </P>

Can't this be used by class cloning interfaces too?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19327#discussion_r1609710019

From shade at openjdk.org  Thu May 30 19:30:14 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 30 May 2024 19:30:14 GMT
Subject: RFR: 8332586: Avoid cloning empty arrays in
 java.lang.reflect.{Method,Constructor}
In-Reply-To: <siqI6ZZBK4jp0ZTiTrW_s_bCVBFS9X9WHNgpwF6BmOU=.3e861fc9-7e2f-4a14-b6ee-1013655a6c97@github.com>
References: <R5bpPuNj1Q2M6uo6_2d6out53rqb17tpheL1jcBDcXw=.3fe0cb7f-1d37-47b0-b4ac-5b7b3ef01bd4@github.com>
 <wWyb1JPXNXH8kmEvRxzQYGFRtqsIiGWEBvZsDao42Xg=.36910126-4813-4e50-b985-f2177e4441ed@github.com>
 <urI3243XmbDPMDy44JJ94CJ0xedd4b9Fmof2_N_WAsc=.0ec4cbb4-0a17-4b3c-9dc4-0999b83c30b9@github.com>
 <z0BMLK-XsvV2LEpfUJ68BG5oepleFmb-68Hxc5ePPa4=.ee3e5cbc-beb9-4898-b825-8e08d8294539@github.com>
 <3JU7e5YOg-8JNc0973MioDwZIAN4RpHazhmD5gUXQDw=.9f85d606-3192-45d2-927b-179e84aef3dd@github.com>
 <nNYiXGtqTV2IpoWw1F2ngrxYO5Tf3yFUFWWvAMAHCUQ=.5496bc84-d8f1-4fd7-b0aa-3bd61e2bc6dc@github.com>
 <siqI6ZZBK4jp0ZTiTrW_s_bCVBFS9X9WHNgpwF6BmOU=.3e861fc9-7e2f-4a14-b6ee-1013655a6c97@github.com>
Message-ID: <Zj4re-mvBs370qK5lLv-3N7NwocJSe_ER9KzjxbYhW4=.6a2af5ea-2cfe-4631-a7e5-512133669f71@github.com>

On Wed, 22 May 2024 14:32:23 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Thanks.  Unfortunately the variable `cloneArray` is actually a method parameter, and most of the callers pass in `false` - so using this utility method to control cloning would actually introduce cloning in several places where it is explicitly avoided.  We may get a performance gain by modifying `Class.getInterfaces()` directly (the sole caller that passes `true`) then eliminating the parameter, then modifying each caller, etc. but that feels like a separate change inspired by this one.
>> 
>> Thoughts?
>
> Why can't you do something like this:
> 
> return cloneArray ? ReflectionFactory.copyClasses(interfaces) : interfaces;
> 
> 
> Alternatively, your proposal is a good one too; we can rename this `getInterfaces(boolean)` to `getInterfacesShared()` (like `getSharedEnumConstants()`) and move this copy operation to `getInterfaces()` as you suggest.

I really see no reason to try and save on re-use of this one-line method for _everything_. In fact, I do not quite see a very compelling reason to even have the utility method. Sharing the code between `Method` and `Constructor` is clean enough and provides a good balance between reuse and cleanliness. Everything else can have the copy of the method definition, if needed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19327#discussion_r1610112885

From liach at openjdk.org  Thu May 30 19:30:14 2024
From: liach at openjdk.org (Chen Liang)
Date: Thu, 30 May 2024 19:30:14 GMT
Subject: RFR: 8332586: Avoid cloning empty arrays in
 java.lang.reflect.{Method,Constructor}
In-Reply-To: <Zj4re-mvBs370qK5lLv-3N7NwocJSe_ER9KzjxbYhW4=.6a2af5ea-2cfe-4631-a7e5-512133669f71@github.com>
References: <R5bpPuNj1Q2M6uo6_2d6out53rqb17tpheL1jcBDcXw=.3fe0cb7f-1d37-47b0-b4ac-5b7b3ef01bd4@github.com>
 <wWyb1JPXNXH8kmEvRxzQYGFRtqsIiGWEBvZsDao42Xg=.36910126-4813-4e50-b985-f2177e4441ed@github.com>
 <urI3243XmbDPMDy44JJ94CJ0xedd4b9Fmof2_N_WAsc=.0ec4cbb4-0a17-4b3c-9dc4-0999b83c30b9@github.com>
 <z0BMLK-XsvV2LEpfUJ68BG5oepleFmb-68Hxc5ePPa4=.ee3e5cbc-beb9-4898-b825-8e08d8294539@github.com>
 <3JU7e5YOg-8JNc0973MioDwZIAN4RpHazhmD5gUXQDw=.9f85d606-3192-45d2-927b-179e84aef3dd@github.com>
 <nNYiXGtqTV2IpoWw1F2ngrxYO5Tf3yFUFWWvAMAHCUQ=.5496bc84-d8f1-4fd7-b0aa-3bd61e2bc6dc@github.com>
 <siqI6ZZBK4jp0ZTiTrW_s_bCVBFS9X9WHNgpwF6BmOU=.3e861fc9-7e2f-4a14-b6ee-1013655a6c97@github.com>
 <Zj4re-mvBs370qK5lLv-3N7NwocJSe_ER9KzjxbYhW4=.6a2af5ea-2cfe-4631-a7e5-512133669f71@github.com>
Message-ID: <mlNYFhkfw_VYSzOodQscBZCKVmMyxzC1eHVUqz8DH9Y=.4729a699-1435-4e93-b396-55732359d1ff@github.com>

On Wed, 22 May 2024 14:33:31 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Why can't you do something like this:
>> 
>> return cloneArray ? ReflectionFactory.copyClasses(interfaces) : interfaces;
>> 
>> 
>> Alternatively, your proposal is a good one too; we can rename this `getInterfaces(boolean)` to `getInterfacesShared()` (like `getSharedEnumConstants()`) and move this copy operation to `getInterfaces()` as you suggest.
>
> I really see no reason to try and save on re-use of this one-line method for _everything_. In fact, I do not quite see a very compelling reason to even have the utility method. Sharing the code between `Method` and `Constructor` is clean enough and provides a good balance between reuse and cleanliness. Everything else can have the copy of the method definition, if needed.

Alternatively, if a utility method is overkill, we can inline these to `Executable`:

public Class<?>[] getParameterTypes() {
    var shared = getSharedParameterTypes();
    return shared.length == 0 ? shared : shared.clone();
}

And the overrides in `Method` and `Constructor` will simply call super; the declarations are kept to preserve the API documentation.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19327#discussion_r1610561896

From shade at openjdk.org  Thu May 30 19:36:04 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 30 May 2024 19:36:04 GMT
Subject: RFR: 8332586: Avoid cloning empty arrays in
 java.lang.reflect.{Method,Constructor}
In-Reply-To: <R5bpPuNj1Q2M6uo6_2d6out53rqb17tpheL1jcBDcXw=.3fe0cb7f-1d37-47b0-b4ac-5b7b3ef01bd4@github.com>
References: <R5bpPuNj1Q2M6uo6_2d6out53rqb17tpheL1jcBDcXw=.3fe0cb7f-1d37-47b0-b4ac-5b7b3ef01bd4@github.com>
Message-ID: <pkyEINTomJF8e7ip1I8FF5KMJBy5jsLzfGX0L6FaKeY=.0228c5fa-a626-48f1-8ce3-b4201e15e1cf@github.com>

On Tue, 21 May 2024 13:49:18 GMT, jengebr <duke at openjdk.org> wrote:

> Improve `java/lang/reflect/Method.java`  by eliminating needless cloning of Class[0] instances.  This cloning is intended to prevent callers from changing array contents, but smany Methods have zero exceptions or zero parameters, and returning the original `Class[0]` is sufficient.

This looks fine to me. Since this is a first-time contribution, someone else needs to take a look as well. You may want to put a simple microbenchmark somewhere here: 
https://github.com/openjdk/jdk/tree/master/test/micro/org/openjdk/bench/java/lang/reflect

-------------

Marked as reviewed by shade (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19327#pullrequestreview-2089223720

From rriggs at openjdk.org  Thu May 30 19:43:03 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 30 May 2024 19:43:03 GMT
Subject: RFR: 8332586: Avoid cloning empty arrays in
 java.lang.reflect.{Method,Constructor}
In-Reply-To: <R5bpPuNj1Q2M6uo6_2d6out53rqb17tpheL1jcBDcXw=.3fe0cb7f-1d37-47b0-b4ac-5b7b3ef01bd4@github.com>
References: <R5bpPuNj1Q2M6uo6_2d6out53rqb17tpheL1jcBDcXw=.3fe0cb7f-1d37-47b0-b4ac-5b7b3ef01bd4@github.com>
Message-ID: <agCj8W29rGge-GlkPtWC6v39hf51jyjZYEXULH7Q-Yk=.118ea804-4d50-4f8e-9fcf-54fcefb7a869@github.com>

On Tue, 21 May 2024 13:49:18 GMT, jengebr <duke at openjdk.org> wrote:

> Improve `java/lang/reflect/Method.java`  by eliminating needless cloning of Class[0] instances.  This cloning is intended to prevent callers from changing array contents, but smany Methods have zero exceptions or zero parameters, and returning the original `Class[0]` is sufficient.

LGTM;  the localized change is concise and clear as to why the clone is unnecessary.

-------------

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19327#pullrequestreview-2089235024

From duke at openjdk.org  Thu May 30 19:47:07 2024
From: duke at openjdk.org (David M. Lloyd)
Date: Thu, 30 May 2024 19:47:07 GMT
Subject: RFR: 8332614: Type-checked ConstantPool.entryByIndex and
 ClassReader.readEntryOrNull [v6]
In-Reply-To: <cvMjPfM9XcTkHA1D_dHe69_RO8S6ElJGeiMX49dOfTc=.e1a1b003-1ab8-4d9d-a522-1ec5a0d66ce1@github.com>
References: <UP8XpBov1w74UcUrAkD08x3vQGy_zRQ8NFRXuMU8us4=.3cce8ca0-742b-43f2-a282-894c7f61c969@github.com>
 <cvMjPfM9XcTkHA1D_dHe69_RO8S6ElJGeiMX49dOfTc=.e1a1b003-1ab8-4d9d-a522-1ec5a0d66ce1@github.com>
Message-ID: <N0p3dL80S1JXIVLLNFNs_nWrM1m9A6OOOWWzagDzFkA=.d7b7e1f5-0e96-44f6-aacb-1e2a1521e497@github.com>

On Wed, 29 May 2024 19:27:17 GMT, Chen Liang <liach at openjdk.org> wrote:

>> I propose to add type-checked ConstantPool.entryByIndex and ClassReader.readEntryOrNull taking an extra Class parameter, which throws ConstantPoolException instead of ClassCastException on type mismatch, which can happen to malformed ClassFiles.
>> 
>> Requesting a review from @asotona. Thanks!
>> 
>> Proposal on mailing list: https://mail.openjdk.org/pipermail/classfile-api-dev/2024-May/000512.html
>
> Chen Liang 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:
> 
>  - Add test to validate ClassReader behavior
>  - Merge branch 'master' of https://github.com/openjdk/jdk into feature/entry-by-type
>  - Null-check the entry class eagerly, avoid returning null or throwing IAE
>  - Remove redundant import
>  - Use switch
>  - Merge branch 'master' of https://github.com/openjdk/jdk into feature/entry-by-type
>  - Merge branch 'master' of https://github.com/openjdk/jdk into feature/entry-by-type
>  - Merge branch 'master' of https://github.com/openjdk/jdk into feature/entry-by-type
>  - Use constants, beautify code
>  - 8332614: Type-checked ConstantPool.entryByIndex and ClassReader.readEntryOrNull

src/java.base/share/classes/java/lang/classfile/ClassReader.java line 142:

> 140:      * @throws ConstantPoolException if the index is out of range of the
> 141:      *         constant pool size, or zero, or the entry is not of the given type
> 142:      * @since 24

I just noticed that these are marked `@since 24`. Am I correct that this should be `@since 23`?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19330#discussion_r1621350942

From naoto at openjdk.org  Thu May 30 19:48:25 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 30 May 2024 19:48:25 GMT
Subject: RFR: 8333103: Re-examine the console provider loading [v2]
In-Reply-To: <M5dxmPs_RJJGqd344t3bMLPMiZmwdtxtbIVP9Bd-ons=.8c7525cc-e3a5-4ed5-81a6-e85398ee6ca6@github.com>
References: <M5dxmPs_RJJGqd344t3bMLPMiZmwdtxtbIVP9Bd-ons=.8c7525cc-e3a5-4ed5-81a6-e85398ee6ca6@github.com>
Message-ID: <d45DFoxzcW07FcgKRb1tWGKQHx_y2D9Beb9j5InMHFI=.d8f116ab-f758-4074-8475-a8c381b6c24a@github.com>

> There is an initialization code in `Console` class that searches for the Console implementations. Refactoring the init code not to use lambda/stream would reduce the (initial) number of loaded classes by about 100 for java.base implementations. This would become relevant when the java.io.IO (JEP 477) uses Console as the underlying framework.

Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:

  Clarify the comment for multiple impls in the module case

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19467/files
  - new: https://git.openjdk.org/jdk/pull/19467/files/ae06bb2c..42a45323

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19467&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19467&range=00-01

  Stats: 3 lines in 1 file changed: 1 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/19467.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19467/head:pull/19467

PR: https://git.openjdk.org/jdk/pull/19467

From jlu at openjdk.org  Thu May 30 20:08:07 2024
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 30 May 2024 20:08:07 GMT
Subject: RFR: 8331485: Odd Results when Parsing Scientific Notation with
 Large Exponent [v6]
In-Reply-To: <L9rX71_vg7z_ZAbDZE6u-Gbe_KuDPu3C9gq_xc035B4=.6fc97e3a-0bb6-41fd-8975-4877c7588407@github.com>
References: <lTOZ4RbzZFMN0yLrQKGOcMihdTop24YbYJe2h36SodM=.0addc2ad-b0d1-4721-b860-a9395fa14977@github.com>
 <L9rX71_vg7z_ZAbDZE6u-Gbe_KuDPu3C9gq_xc035B4=.6fc97e3a-0bb6-41fd-8975-4877c7588407@github.com>
Message-ID: <kB6jlXxEp-sWizIQpARtZRA9EgDCTWCHo4UnBtKcdhk=.72dfb06e-53a1-4a18-b336-c5231224288b@github.com>

On Fri, 17 May 2024 21:59:38 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please review this PR which corrects an edge case bug for java.text.DecimalFormat that causes incorrect parsing results for strings with very large exponent values.
>> 
>> When parsing values with large exponents, if the value of the exponent exceeds `Integer.MAX_VALUE`, the parsed value  is equal to 0. If the value of the exponent exceeds `Long.MAX_VALUE`, the parsed value is equal to the mantissa. Both results are confusing and incorrect.
>> 
>> For example,
>> 
>> 
>> NumberFormat fmt = NumberFormat.getInstance(Locale.US);
>> fmt.parse(".1E2147483648"); // returns 0.0
>> fmt.parse(".1E9223372036854775808"); // returns 0.1
>> // For comparison
>> Double.parseDouble(".1E2147483648"); // returns Infinity
>> Double.parseDouble(".1E9223372036854775808"); // returns Infinity
>> 
>> 
>> After this change, both parse calls return `Double.POSITIVE_INFINITY` now.
>
> Justin Lu has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - change impl to support whitebox test
>  - adjust impl to increase accuracy when decimalAt/exponent value are both around Integer.MAX/MIN

Thanks for the reviews; tests pass after merge with latest master.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19075#issuecomment-2140780684

From jlu at openjdk.org  Thu May 30 20:08:08 2024
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 30 May 2024 20:08:08 GMT
Subject: Integrated: 8331485: Odd Results when Parsing Scientific Notation with
 Large Exponent
In-Reply-To: <lTOZ4RbzZFMN0yLrQKGOcMihdTop24YbYJe2h36SodM=.0addc2ad-b0d1-4721-b860-a9395fa14977@github.com>
References: <lTOZ4RbzZFMN0yLrQKGOcMihdTop24YbYJe2h36SodM=.0addc2ad-b0d1-4721-b860-a9395fa14977@github.com>
Message-ID: <5gkeQacGp6ukorFddlGoIoHtgVC1eaDSAqsNNs0kv_o=.620981b4-7ca3-49d3-baba-5f95b3e54a39@github.com>

On Fri, 3 May 2024 08:47:03 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which corrects an edge case bug for java.text.DecimalFormat that causes incorrect parsing results for strings with very large exponent values.
> 
> When parsing values with large exponents, if the value of the exponent exceeds `Integer.MAX_VALUE`, the parsed value  is equal to 0. If the value of the exponent exceeds `Long.MAX_VALUE`, the parsed value is equal to the mantissa. Both results are confusing and incorrect.
> 
> For example,
> 
> 
> NumberFormat fmt = NumberFormat.getInstance(Locale.US);
> fmt.parse(".1E2147483648"); // returns 0.0
> fmt.parse(".1E9223372036854775808"); // returns 0.1
> // For comparison
> Double.parseDouble(".1E2147483648"); // returns Infinity
> Double.parseDouble(".1E9223372036854775808"); // returns Infinity
> 
> 
> After this change, both parse calls return `Double.POSITIVE_INFINITY` now.

This pull request has now been integrated.

Changeset: ffb0867e
Author:    Justin Lu <jlu at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/ffb0867e2c07b41cb7124e11fe6cf63d9471f0d2
Stats:     269 lines in 4 files changed: 254 ins; 2 del; 13 mod

8331485: Odd Results when Parsing Scientific Notation with Large Exponent
8331680: NumberFormat is missing some bad exponent strict parse cases

Reviewed-by: naoto

-------------

PR: https://git.openjdk.org/jdk/pull/19075

From asemenyuk at openjdk.org  Thu May 30 20:18:11 2024
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Thu, 30 May 2024 20:18:11 GMT
Subject: RFR: 8333303: Issues with DottedVersion class
Message-ID: <65hH6QalinCN-LZjuppxoFiPGpGfhgOFlr9nsGz-dNc=.4e6c1975-c06d-42b5-9086-a7c34e1852ba@github.com>

- Get rid of DottedVersion#greedy field.
 - Add support to save the unrecognizable remainder of the version string (required to handle Wix4 version string).
 - Implement DottedVersion#equals().
 - add DottedVersion#compareComponents(DottedVersion, DottedVersion) that compares recognized components of the given DottedVersion instances.
 - remove DottedVersion#compareTo(String)

[Edit](https://bugs.openjdk.org/secure/EditComment!default.jspa?id=5130726&commentId=14677610)
[Delete](https://bugs.openjdk.org/secure/DeleteComment!default.jspa?id=5130726&commentId=14677610)

-------------

Commit messages:
 - DottedVersion#compareTo() has been replaced with DottedVersion#compareComponents()
 - DottedVersion refactored. Old parsing code used "==" to test equality of two BiInteger objects and it didn't work right. When the bug was fixed app version check on Windows platform stopped working. It required a bit of work to get it working right.

Changes: https://git.openjdk.org/jdk/pull/19488/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19488&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8333303
  Stats: 320 lines in 6 files changed: 195 ins; 58 del; 67 mod
  Patch: https://git.openjdk.org/jdk/pull/19488.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19488/head:pull/19488

PR: https://git.openjdk.org/jdk/pull/19488

From asemenyuk at openjdk.org  Thu May 30 20:18:12 2024
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Thu, 30 May 2024 20:18:12 GMT
Subject: RFR: 8333303: Issues with DottedVersion class
In-Reply-To: <65hH6QalinCN-LZjuppxoFiPGpGfhgOFlr9nsGz-dNc=.4e6c1975-c06d-42b5-9086-a7c34e1852ba@github.com>
References: <65hH6QalinCN-LZjuppxoFiPGpGfhgOFlr9nsGz-dNc=.4e6c1975-c06d-42b5-9086-a7c34e1852ba@github.com>
Message-ID: <I7Bkg6lhDW9GVSohNVgJNCqA5Mmgxw8j-uZhkQd-X3k=.f2c18c90-2647-41e3-9fda-c82044344420@github.com>

On Thu, 30 May 2024 20:10:05 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> - Get rid of DottedVersion#greedy field.
>  - Add support to save the unrecognizable remainder of the version string (required to handle Wix4 version string).
>  - Implement DottedVersion#equals().
>  - add DottedVersion#compareComponents(DottedVersion, DottedVersion) that compares recognized components of the given DottedVersion instances.
>  - remove DottedVersion#compareTo(String)
> 
> [Edit](https://bugs.openjdk.org/secure/EditComment!default.jspa?id=5130726&commentId=14677610)
> [Delete](https://bugs.openjdk.org/secure/DeleteComment!default.jspa?id=5130726&commentId=14677610)

@sashamatveev please review

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19488#issuecomment-2140794827

From darcy at openjdk.org  Thu May 30 20:18:03 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Thu, 30 May 2024 20:18:03 GMT
Subject: RFR: 8332586: Avoid cloning empty arrays in
 java.lang.reflect.{Method,Constructor}
In-Reply-To: <R5bpPuNj1Q2M6uo6_2d6out53rqb17tpheL1jcBDcXw=.3fe0cb7f-1d37-47b0-b4ac-5b7b3ef01bd4@github.com>
References: <R5bpPuNj1Q2M6uo6_2d6out53rqb17tpheL1jcBDcXw=.3fe0cb7f-1d37-47b0-b4ac-5b7b3ef01bd4@github.com>
Message-ID: <CGJclhzgnUtjnjLKNGQV-vLmWkEZeDwyf-j_QV4QY-4=.a9f7bedf-3367-4da7-93a3-27b789801f53@github.com>

On Tue, 21 May 2024 13:49:18 GMT, jengebr <duke at openjdk.org> wrote:

> Improve `java/lang/reflect/Method.java`  by eliminating needless cloning of Class[0] instances.  This cloning is intended to prevent callers from changing array contents, but smany Methods have zero exceptions or zero parameters, and returning the original `Class[0]` is sufficient.

This is a bit of a behavioral change, but I think it falls under the threshold that would require CSR review.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19327#issuecomment-2140795211

From cushon at openjdk.org  Thu May 30 20:29:04 2024
From: cushon at openjdk.org (Liam Miller-Cushon)
Date: Thu, 30 May 2024 20:29:04 GMT
Subject: RFR: 8328995: Launcher can't open jar files where the offset of
 the manifest is >4GB [v6]
In-Reply-To: <mFJD586uS9BKVdghAP0y8c1qkULzQbEgypPZwkd2YDI=.4c643822-c8b2-41ad-955a-2420c7e0af5e@github.com>
References: <bgsm1_QUL0EbnTCEdpLZq2KV5kJJ2vB-A_E6uBOFi3c=.f322218f-d68e-428b-b518-bb51dfc470b7@github.com>
 <mFJD586uS9BKVdghAP0y8c1qkULzQbEgypPZwkd2YDI=.4c643822-c8b2-41ad-955a-2420c7e0af5e@github.com>
Message-ID: <5qJEY-WPndRHH2bFUGB5BC-L0zbhsebcepWFxlEq310=.3ccf6e2e-b610-4152-88aa-83e737375436@github.com>

On Thu, 4 Apr 2024 16:57:40 GMT, Liam Miller-Cushon <cushon at openjdk.org> wrote:

>> This change fixes a zip64 bug in the launcher that is prevent it from reading the manifest of jars where the 'relative offset of local header' field in the central directory entry is >4GB. As described in APPNOTE.TXT 4.5.3, the offset is too large to be stored in the central directory it is stored in a 'Zip64 Extended Information Extra Field'.
>
> Liam Miller-Cushon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Move test to test/jdk/tools/launcher

@bridgekeeper please keep this open

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18479#issuecomment-2140810530

From asemenyuk at openjdk.org  Thu May 30 20:30:10 2024
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Thu, 30 May 2024 20:30:10 GMT
Subject: RFR: 8333307: Don't suppress jpackage logging in tests when it is
 detecting packaging tools in the system
Message-ID: <QGZC7XIKGG88vfB2-sJal2TjyAiFep4mGgXu9UA0cJY=.18d6beb0-aa54-468f-8eb7-482b356944c7@github.com>

Change jpackage tests output from:


[19:16:29.586] Create: SimplePackageTest.test
[19:16:29.587] [ RUN ] SimplePackageTest.test
[19:16:29.663] TRACE: Bundler rpm supported
[19:16:29.674] TRACE: Actions: [[initialize], [create], [unpack], [verify-install], [finalize]]


to:


[19:16:29.586] Create: SimplePackageTest.test
[19:16:29.587] [ RUN ] SimplePackageTest.test
[19:16:29.621] Running dpkg
[19:16:29.633] Running dpkg-deb
[19:16:29.651] Running rpmbuild
[19:16:29.663] TRACE: Bundler rpm supported
[19:16:29.674] TRACE: Actions: [[initialize], [create], [unpack], [verify-install], [finalize]]

-------------

Commit messages:
 - Don't suppress jpackage output when it is detecting what packaging tools available and what bundlers are supported.

Changes: https://git.openjdk.org/jdk/pull/19489/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19489&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8333307
  Stats: 29 lines in 1 file changed: 27 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/19489.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19489/head:pull/19489

PR: https://git.openjdk.org/jdk/pull/19489

From darcy at openjdk.org  Thu May 30 20:39:34 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Thu, 30 May 2024 20:39:34 GMT
Subject: RFR: 8330182: Start of release updates for JDK 24 [v11]
In-Reply-To: <YKsEQWuI-vNTEDjOBInuEjf8AEcTL4QZ_F4JYUqoxwk=.5ed43782-6dec-4383-948d-d9966a85b3bf@github.com>
References: <YKsEQWuI-vNTEDjOBInuEjf8AEcTL4QZ_F4JYUqoxwk=.5ed43782-6dec-4383-948d-d9966a85b3bf@github.com>
Message-ID: <9w0ZJ6HUb9FK1G3UPRCWic-VHDD-vcCE4Bu5dKmPWI0=.c8bad1d1-9c37-490b-a6d0-f1fa95521906@github.com>

> Get JDK 24 underway.

Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:

  Temporarily problem list java.lang.instrument tests until jar generation is fixed.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/18787/files
  - new: https://git.openjdk.org/jdk/pull/18787/files/39a028c3..6a6499dd

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18787&range=10
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18787&range=09-10

  Stats: 3 lines in 1 file changed: 3 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/18787.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18787/head:pull/18787

PR: https://git.openjdk.org/jdk/pull/18787

From liach at openjdk.org  Thu May 30 21:50:07 2024
From: liach at openjdk.org (Chen Liang)
Date: Thu, 30 May 2024 21:50:07 GMT
Subject: RFR: 8332614: Type-checked ConstantPool.entryByIndex and
 ClassReader.readEntryOrNull [v6]
In-Reply-To: <N0p3dL80S1JXIVLLNFNs_nWrM1m9A6OOOWWzagDzFkA=.d7b7e1f5-0e96-44f6-aacb-1e2a1521e497@github.com>
References: <UP8XpBov1w74UcUrAkD08x3vQGy_zRQ8NFRXuMU8us4=.3cce8ca0-742b-43f2-a282-894c7f61c969@github.com>
 <cvMjPfM9XcTkHA1D_dHe69_RO8S6ElJGeiMX49dOfTc=.e1a1b003-1ab8-4d9d-a522-1ec5a0d66ce1@github.com>
 <N0p3dL80S1JXIVLLNFNs_nWrM1m9A6OOOWWzagDzFkA=.d7b7e1f5-0e96-44f6-aacb-1e2a1521e497@github.com>
Message-ID: <OwWsHUW2KYU_fyapy_iZ-40Noglvs6eeOxWnLBi_B_k=.36f23c49-b240-4d26-afcd-c9a2ff326d85@github.com>

On Thu, 30 May 2024 19:44:29 GMT, David M. Lloyd <duke at openjdk.org> wrote:

>> Chen Liang 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:
>> 
>>  - Add test to validate ClassReader behavior
>>  - Merge branch 'master' of https://github.com/openjdk/jdk into feature/entry-by-type
>>  - Null-check the entry class eagerly, avoid returning null or throwing IAE
>>  - Remove redundant import
>>  - Use switch
>>  - Merge branch 'master' of https://github.com/openjdk/jdk into feature/entry-by-type
>>  - Merge branch 'master' of https://github.com/openjdk/jdk into feature/entry-by-type
>>  - Merge branch 'master' of https://github.com/openjdk/jdk into feature/entry-by-type
>>  - Use constants, beautify code
>>  - 8332614: Type-checked ConstantPool.entryByIndex and ClassReader.readEntryOrNull
>
> src/java.base/share/classes/java/lang/classfile/ClassReader.java line 142:
> 
>> 140:      * @throws ConstantPoolException if the index is out of range of the
>> 141:      *         constant pool size, or zero, or the entry is not of the given type
>> 142:      * @since 24
> 
> I just noticed that these are marked `@since 24`. Am I correct that this should be `@since 23`?

Thanks for pointing out, I was under the assumption that this patch might not come into 23. I will create an issue, and you can make a PR if you feel like contributing (doc-only changes can integrate before RDPs so no rush)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19330#discussion_r1621460803

From bchristi at openjdk.org  Thu May 30 22:11:39 2024
From: bchristi at openjdk.org (Brent Christian)
Date: Thu, 30 May 2024 22:11:39 GMT
Subject: RFR: 8314480: Memory ordering spec updates in java.lang.ref [v33]
In-Reply-To: <R74ontYwjYg6HeZY0cWrlo0amjl4E1YsFWeuh4pda14=.08ac62df-b2f8-4b4d-b338-07adb289601b@github.com>
References: <R74ontYwjYg6HeZY0cWrlo0amjl4E1YsFWeuh4pda14=.08ac62df-b2f8-4b4d-b338-07adb289601b@github.com>
Message-ID: <gfnrkbuvrbjRu52DxzcgbWGVvdvHNrVXruuH2IENShs=.f21f5f6c-4f48-48f4-bd12-9c9ea1efec8d@github.com>

> Classes in the `java.lang.ref` package would benefit from an update to bring the spec in line with how the VM already behaves. The changes would focus on _happens-before_ edges at some key points during reference processing.
> 
> A couple key things we want to be able to say are:
> - `Reference.reachabilityFence(x)` _happens-before_ reference processing occurs for 'x'.
> - `Cleaner.register()` _happens-before_ the Cleaner thread runs the registered cleaning action.
> 
> This will bring Cleaner in line (or close) with the memory visibility guarantees made for finalizers in [JLS 17.4.5](https://docs.oracle.com/javase/specs/jls/se18/html/jls-17.html#jls-17.4.5):
> _"There is a happens-before edge from the end of a constructor of an object to the start of a finalizer (?12.6) for that object."_

Brent Christian has updated the pull request incrementally with one additional commit since the last revision:

  convert sample to snippet; add 'JLS' label to jls links

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/16644/files
  - new: https://git.openjdk.org/jdk/pull/16644/files/d7cbf0d3..33334d06

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16644&range=32
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16644&range=31-32

  Stats: 7 lines in 2 files changed: 1 ins; 0 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/16644.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16644/head:pull/16644

PR: https://git.openjdk.org/jdk/pull/16644

From almatvee at openjdk.org  Thu May 30 22:42:01 2024
From: almatvee at openjdk.org (Alexander Matveev)
Date: Thu, 30 May 2024 22:42:01 GMT
Subject: RFR: 8333307: Don't suppress jpackage logging in tests when it is
 detecting packaging tools in the system
In-Reply-To: <QGZC7XIKGG88vfB2-sJal2TjyAiFep4mGgXu9UA0cJY=.18d6beb0-aa54-468f-8eb7-482b356944c7@github.com>
References: <QGZC7XIKGG88vfB2-sJal2TjyAiFep4mGgXu9UA0cJY=.18d6beb0-aa54-468f-8eb7-482b356944c7@github.com>
Message-ID: <wEDMa2s-2MZhIZAN2V9t4QI5twoh3Ia0Tf8y6QGhRpU=.677cca87-761f-465d-88cf-3a70f78ff58f@github.com>

On Thu, 30 May 2024 20:26:02 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> Change jpackage tests output from:
> 
> 
> [19:16:29.586] Create: SimplePackageTest.test
> [19:16:29.587] [ RUN ] SimplePackageTest.test
> [19:16:29.663] TRACE: Bundler rpm supported
> [19:16:29.674] TRACE: Actions: [[initialize], [create], [unpack], [verify-install], [finalize]]
> 
> 
> to:
> 
> 
> [19:16:29.586] Create: SimplePackageTest.test
> [19:16:29.587] [ RUN ] SimplePackageTest.test
> [19:16:29.621] Running dpkg
> [19:16:29.633] Running dpkg-deb
> [19:16:29.651] Running rpmbuild
> [19:16:29.663] TRACE: Bundler rpm supported
> [19:16:29.674] TRACE: Actions: [[initialize], [create], [unpack], [verify-install], [finalize]]

Looks good, but I am confused why it is targeted to 24? I think you need to postpone integration until 24 or target it to 23.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19489#issuecomment-2140961328

From asemenyuk at openjdk.org  Thu May 30 22:47:00 2024
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Thu, 30 May 2024 22:47:00 GMT
Subject: RFR: 8333307: Don't suppress jpackage logging in tests when it is
 detecting packaging tools in the system
In-Reply-To: <QGZC7XIKGG88vfB2-sJal2TjyAiFep4mGgXu9UA0cJY=.18d6beb0-aa54-468f-8eb7-482b356944c7@github.com>
References: <QGZC7XIKGG88vfB2-sJal2TjyAiFep4mGgXu9UA0cJY=.18d6beb0-aa54-468f-8eb7-482b356944c7@github.com>
Message-ID: <GKj8Jyre4dgQ1nvlswmZbR8mpXRhvZuIWKs-DThZFyg=.4bcd0b56-8bc6-4879-9966-fed6ec786d40@github.com>

On Thu, 30 May 2024 20:26:02 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> Change jpackage tests output from:
> 
> 
> [19:16:29.586] Create: SimplePackageTest.test
> [19:16:29.587] [ RUN ] SimplePackageTest.test
> [19:16:29.663] TRACE: Bundler rpm supported
> [19:16:29.674] TRACE: Actions: [[initialize], [create], [unpack], [verify-install], [finalize]]
> 
> 
> to:
> 
> 
> [19:16:29.586] Create: SimplePackageTest.test
> [19:16:29.587] [ RUN ] SimplePackageTest.test
> [19:16:29.621] Running dpkg
> [19:16:29.633] Running dpkg-deb
> [19:16:29.651] Running rpmbuild
> [19:16:29.663] TRACE: Bundler rpm supported
> [19:16:29.674] TRACE: Actions: [[initialize], [create], [unpack], [verify-install], [finalize]]

Retargeted it to 23

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19489#issuecomment-2140965618

From almatvee at openjdk.org  Thu May 30 22:54:12 2024
From: almatvee at openjdk.org (Alexander Matveev)
Date: Thu, 30 May 2024 22:54:12 GMT
Subject: RFR: 8332110: [macos] jpackage tries to sign added files without
 the --mac-sign option [v2]
In-Reply-To: <eiboU_LgwkTte_7rkPJAdDm1x_-Pzm8rdwUiY_4MAYI=.b982e161-fe24-44ab-9db5-2f1d80eb0d99@github.com>
References: <eiboU_LgwkTte_7rkPJAdDm1x_-Pzm8rdwUiY_4MAYI=.b982e161-fe24-44ab-9db5-2f1d80eb0d99@github.com>
Message-ID: <HI6HYfkNrR1fV5fKnQbAwk-TUWPhRjYIEfdnosvAZ60=.b205f7ba-d2c8-46bc-b192-439d318df63f@github.com>

> This issue is reproducible with and without `--mac-sign`. jpackage will "_ad-hoc_" sign application bundle when `--mac-sign` is not specified by using pseudo-identity "_-_". This is why jpackage tries to sign added files and this is expected behavior by jpackage. "codesign" fails since added content made application bundle structure invalid. There is nothing we can do on jpackage side to sign such invalid bundles. As proposed solution we will output possible reason for "codesign" failure if it fails and `--app-content` was specified and possible solution. Proposed message: "One of the possible reason for "codesign" failure is additional content provided via "--app-content", which made application bundle structure invalid. Make sure to provide additional content in a way it will not break application bundle structure, otherwise add additional content as post-processing step."
> 
> Example:
> Lets assume we have "ReadMe" folder with "ReadMe.txt" file in it.
> 1) jpackage --type app-image -n Test --app-content ReadMe/ReadMe.txt ...
> "codesign" will fail with "In subcomponent: Test.app/Contents/ReadMe.txt". This is expected and "ReadMe.txt" placed in "Test.app/Contents" which is also expected.
> 2) jpackage --type app-image -n Test --app-content ReadMe ...
> Works and "ReadMe.txt" will be placed under "Test.app/Contents/ReadMe".
> 
> Sample output before fix:
> 
> Error: "codesign" failed with following output:
> Test.app: replacing existing signature
> Test.app: code object is not signed at all
> In subcomponent: Test.app/Contents/ReadMe.txt
> 
> 
> Sample output after fix:
> 
> "codesign" failed and additional application content was supplied via the "--app-content" parameter. Probably the additional content broke the integrity of the application bundle and caused the failure. Ensure content supplied via the "--app-content" parameter does not break the integrity of the application bundle, or add it in the post-processing step.
> Error: "codesign" failed with following output:
> Test.app: replacing existing signature
> Test.app: code object is not signed at all
> In subcomponent: Test.app/Contents/ReadMe.txt

Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision:

  8332110: jpackage tries to sign added files without the --mac-sign option [v2]

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19377/files
  - new: https://git.openjdk.org/jdk/pull/19377/files/0ad02cbb..7c1973ad

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19377&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19377&range=00-01

  Stats: 9 lines in 6 files changed: 1 ins; 0 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/19377.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19377/head:pull/19377

PR: https://git.openjdk.org/jdk/pull/19377

From almatvee at openjdk.org  Thu May 30 22:57:06 2024
From: almatvee at openjdk.org (Alexander Matveev)
Date: Thu, 30 May 2024 22:57:06 GMT
Subject: RFR: 8332110: [macos] jpackage tries to sign added files without
 the --mac-sign option [v2]
In-Reply-To: <HI6HYfkNrR1fV5fKnQbAwk-TUWPhRjYIEfdnosvAZ60=.b205f7ba-d2c8-46bc-b192-439d318df63f@github.com>
References: <eiboU_LgwkTte_7rkPJAdDm1x_-Pzm8rdwUiY_4MAYI=.b982e161-fe24-44ab-9db5-2f1d80eb0d99@github.com>
 <HI6HYfkNrR1fV5fKnQbAwk-TUWPhRjYIEfdnosvAZ60=.b205f7ba-d2c8-46bc-b192-439d318df63f@github.com>
Message-ID: <NlwVGV_OjooJbJBypiZjLVIhF_stPNDB1hxSVX6lW7w=.1072535e-6920-4f4a-8050-a71bd5ae99dc@github.com>

On Thu, 30 May 2024 22:54:12 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

>> This issue is reproducible with and without `--mac-sign`. jpackage will "_ad-hoc_" sign application bundle when `--mac-sign` is not specified by using pseudo-identity "_-_". This is why jpackage tries to sign added files and this is expected behavior by jpackage. "codesign" fails since added content made application bundle structure invalid. There is nothing we can do on jpackage side to sign such invalid bundles. As proposed solution we will output possible reason for "codesign" failure if it fails and `--app-content` was specified and possible solution. Proposed message: "One of the possible reason for "codesign" failure is additional content provided via "--app-content", which made application bundle structure invalid. Make sure to provide additional content in a way it will not break application bundle structure, otherwise add additional content as post-processing step."
>> 
>> Example:
>> Lets assume we have "ReadMe" folder with "ReadMe.txt" file in it.
>> 1) jpackage --type app-image -n Test --app-content ReadMe/ReadMe.txt ...
>> "codesign" will fail with "In subcomponent: Test.app/Contents/ReadMe.txt". This is expected and "ReadMe.txt" placed in "Test.app/Contents" which is also expected.
>> 2) jpackage --type app-image -n Test --app-content ReadMe ...
>> Works and "ReadMe.txt" will be placed under "Test.app/Contents/ReadMe".
>> 
>> Sample output before fix:
>> 
>> Error: "codesign" failed with following output:
>> Test.app: replacing existing signature
>> Test.app: code object is not signed at all
>> In subcomponent: Test.app/Contents/ReadMe.txt
>> 
>> 
>> Sample output after fix:
>> 
>> "codesign" failed and additional application content was supplied via the "--app-content" parameter. Probably the additional content broke the integrity of the application bundle and caused the failure. Ensure content supplied via the "--app-content" parameter does not break the integrity of the application bundle, or add it in the post-processing step.
>> Error: "codesign" failed with following output:
>> Test.app: replacing existing signature
>> Test.app: code object is not signed at all
>> In subcomponent: Test.app/Contents/ReadMe.txt
>
> Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8332110: jpackage tries to sign added files without the --mac-sign option [v2]

8332110: jpackage tries to sign added files without the --mac-sign option [v2]
 - Updated error message as suggested.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19377#issuecomment-2140973262

From almatvee at openjdk.org  Thu May 30 22:59:03 2024
From: almatvee at openjdk.org (Alexander Matveev)
Date: Thu, 30 May 2024 22:59:03 GMT
Subject: RFR: 8333307: Don't suppress jpackage logging in tests when it is
 detecting packaging tools in the system
In-Reply-To: <QGZC7XIKGG88vfB2-sJal2TjyAiFep4mGgXu9UA0cJY=.18d6beb0-aa54-468f-8eb7-482b356944c7@github.com>
References: <QGZC7XIKGG88vfB2-sJal2TjyAiFep4mGgXu9UA0cJY=.18d6beb0-aa54-468f-8eb7-482b356944c7@github.com>
Message-ID: <2DVvVLeYV-d1fls6y0UV7zksbTRJ1qzo9xKh_xF3jls=.ba054f8b-7576-47bb-ba95-21fb4e5f378c@github.com>

On Thu, 30 May 2024 20:26:02 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> Change jpackage tests output from:
> 
> 
> [19:16:29.586] Create: SimplePackageTest.test
> [19:16:29.587] [ RUN ] SimplePackageTest.test
> [19:16:29.663] TRACE: Bundler rpm supported
> [19:16:29.674] TRACE: Actions: [[initialize], [create], [unpack], [verify-install], [finalize]]
> 
> 
> to:
> 
> 
> [19:16:29.586] Create: SimplePackageTest.test
> [19:16:29.587] [ RUN ] SimplePackageTest.test
> [19:16:29.621] Running dpkg
> [19:16:29.633] Running dpkg-deb
> [19:16:29.651] Running rpmbuild
> [19:16:29.663] TRACE: Bundler rpm supported
> [19:16:29.674] TRACE: Actions: [[initialize], [create], [unpack], [verify-install], [finalize]]

Marked as reviewed by almatvee (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/19489#pullrequestreview-2089482543

From mcimadamore at openjdk.org  Thu May 30 23:08:01 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 30 May 2024 23:08:01 GMT
Subject: RFR: 8333236: Test java/foreign/TestAccessModes.java is timing out
 after passing
In-Reply-To: <YH9u0h82laNPYgeZ034P0bDITuDG6Faii7BAoRGINeA=.422531b0-d821-47ca-8632-d2e455df14fb@github.com>
References: <mLVkvSWgzjrvnm1R6MZxjacSbTN0CxdA5f5D3lqDti0=.bb215ff2-8bfd-4ce4-8986-522f0ef1af08@github.com>
 <YH9u0h82laNPYgeZ034P0bDITuDG6Faii7BAoRGINeA=.422531b0-d821-47ca-8632-d2e455df14fb@github.com>
Message-ID: <-l4FLZZ5RAr5nFmKMcktBs-zAF9ILvkhwM2cvODpceE=.390ddfea-fd2c-4a52-874c-cbfc0e5c4828@github.com>

On Thu, 30 May 2024 17:04:44 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

> I suggest leaving a comment to document which cases this cache is trying to address. I think that's mainly cases where the same ValueLayout is created many times in different places (instead of the same layout being reused, for which we already have a cache field on the layout instance itself).

Not quite. Note that since the recent changes, the handle we get from `Utils::makeSegmentViewVarHandle` is no longer cached *directly* on the value layout (because that handle is "raw" and has no size checks). What we cache is the adapted version of the handle which has the correct checks.

When we create a var handle from some other root layout, we don't cache the resulting var handle anywhere - in part because doing so would be relatively expensive (you'd need a map from PathElement[] to VarHandle, and that's just for `varHandle`), and in part because reusing chance are rather low.

That said, in both cases, to construct the "final" var handle, we have to create some raw var handle using `Utils::makeSegmentViewVarHandle`, so caching these raw handles seems to add up.

But yes, all the above rationale should be captured in a comment.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19485#issuecomment-2140981239

From dl at openjdk.org  Thu May 30 23:09:16 2024
From: dl at openjdk.org (Doug Lea)
Date: Thu, 30 May 2024 23:09:16 GMT
Subject: RFR: 8322732: ForkJoinPool may underutilize cores in async mode
 [v15]
In-Reply-To: <xRyDMAsSZ7obqpr3Aoc5qrHqILeJMxFVCeiRdctMI3U=.d5d3cd56-32eb-4431-ac01-081822fc86c6@github.com>
References: <xRyDMAsSZ7obqpr3Aoc5qrHqILeJMxFVCeiRdctMI3U=.d5d3cd56-32eb-4431-ac01-081822fc86c6@github.com>
Message-ID: <9Mlqw5EhAaMt2DMCDIRFq3hSWCUhFMn1fQr4s9tjSjk=.1e9aaa32-5a4f-4577-9511-8b16a024d6d8@github.com>

> This set of changes address causes of poor utilization with small numbers of cores due to overly aggressive contention avoidance. A number of further adjustments were needed to still avoid most contention effects in deployments with large numbers of cores

Doug Lea has updated the pull request incrementally with one additional commit since the last revision:

  diagnostic

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19131/files
  - new: https://git.openjdk.org/jdk/pull/19131/files/47ce3643..becabd04

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19131&range=14
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19131&range=13-14

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/19131.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19131/head:pull/19131

PR: https://git.openjdk.org/jdk/pull/19131

From almatvee at openjdk.org  Thu May 30 23:33:01 2024
From: almatvee at openjdk.org (Alexander Matveev)
Date: Thu, 30 May 2024 23:33:01 GMT
Subject: RFR: 8333303: Issues with DottedVersion class
In-Reply-To: <65hH6QalinCN-LZjuppxoFiPGpGfhgOFlr9nsGz-dNc=.4e6c1975-c06d-42b5-9086-a7c34e1852ba@github.com>
References: <65hH6QalinCN-LZjuppxoFiPGpGfhgOFlr9nsGz-dNc=.4e6c1975-c06d-42b5-9086-a7c34e1852ba@github.com>
Message-ID: <Bnib4Ddp-_zA4XiE8VOBPZ4DZJzPl1ityIxH4vkVcLA=.4bd4ba50-d1ce-485e-a6e7-eecccd87b5ba@github.com>

On Thu, 30 May 2024 20:10:05 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> - Get rid of DottedVersion#greedy field.
>  - Add support to save the unrecognizable remainder of the version string (required to handle Wix4 version string).
>  - Implement DottedVersion#equals().
>  - add DottedVersion#compareComponents(DottedVersion, DottedVersion) that compares recognized components of the given DottedVersion instances.
>  - remove DottedVersion#compareTo(String)
> 
> [Edit](https://bugs.openjdk.org/secure/EditComment!default.jspa?id=5130726&commentId=14677610)
> [Delete](https://bugs.openjdk.org/secure/DeleteComment!default.jspa?id=5130726&commentId=14677610)

Looks good.

-------------

Marked as reviewed by almatvee (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19488#pullrequestreview-2089507390

From mcimadamore at openjdk.org  Thu May 30 23:39:04 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 30 May 2024 23:39:04 GMT
Subject: RFR: 8320396: Class-File API ClassModel::verify should include
 checks from hotspot/share/classfile/classFileParser.cpp [v9]
In-Reply-To: <Kdd6IcPvA1Xn-444dkSMQN5HVRCMn2JmgqjQZbNQ9yc=.f7198271-db19-415a-99df-7c0c9e014252@github.com>
References: <0a66asWcJ4_zBrjmReA18BZmsovN1ZeJRRSAPZDMZmo=.5bada03f-d88d-46cd-962d-c1e42c3048c1@github.com>
 <Kdd6IcPvA1Xn-444dkSMQN5HVRCMn2JmgqjQZbNQ9yc=.f7198271-db19-415a-99df-7c0c9e014252@github.com>
Message-ID: <_hPwSGv4z9Jw9pxsawxnauor45zRW0BjRfKQcZtk7xI=.1a347766-8e47-4e63-95ee-884c41a17b4f@github.com>

On Fri, 24 May 2024 16:17:41 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> ClassFile API `jdk.internal.classfile.verifier.VerifierImpl` performed only bytecode-level class verification.
>> This patch adds `jdk.internal.classfile.verifier.ParserVerifier` with additional class checks inspired by `hotspot/share/classfile/classFileParser.cpp`.
>> 
>> Also new `VerifierSelfTest::testParserVerifier` has been added.
>> 
>> Please review.
>> 
>> Thanks,
>> Adam
>
> Adam Sotona has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 37 commits:
> 
>  - fixed ParserVerifier and VerifierSelfTest
>  - Merge branch 'master' into JDK-8320396-verifier-extension
>  - added verification of TypeAnnotation attributes
>  - added verification of SMT attribute
>  - added verification of module-related attributes
>  - applied the suggested changes
>  - applied the suggested changes
>  - fixed error thrown by VerifierImpl
>  - applied suggested changes
>  - Merge branch 'master' into JDK-8320396-verifier-extension
>  - ... and 27 more: https://git.openjdk.org/jdk/compare/cfdc64fc...b352b794

Great work!

-------------

Marked as reviewed by mcimadamore (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/16809#pullrequestreview-2089511401

From jpai at openjdk.org  Fri May 31 00:56:01 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 31 May 2024 00:56:01 GMT
Subject: RFR: 8210471: GZIPInputStream constructor could leak an un-end()ed
 Inflater [v2]
In-Reply-To: <Bjj-rJ0tqG8oswA6GnoHJnKinVdfaMSyFrNch2hOHfw=.0db6820a-5219-4bef-9240-6136daf10cf3@github.com>
References: <zugElcASx7a5x5uqkjArVCSH2zWDzsAFeJ9XB5FhXfE=.d5dbc5af-2af4-48cb-ba1b-724924de23f4@github.com>
 <oh3vme22_tGraiuVSHUwLdrmZQfuXWcgQN3F_4ksyuY=.7fee6023-66e5-4ea4-a3cb-8cbb6c124dc6@github.com>
 <Bjj-rJ0tqG8oswA6GnoHJnKinVdfaMSyFrNch2hOHfw=.0db6820a-5219-4bef-9240-6136daf10cf3@github.com>
Message-ID: <Ymm13N8RjI5kYNByDou1DpCtSQqA3Vd4cPkUr6SV66c=.45b84618-fe35-4fa0-acb9-bc7a9aa3787d@github.com>

On Thu, 30 May 2024 14:56:00 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   introduce a basic test for GZIPInputStream
>
> src/java.base/share/classes/java/util/zip/GZIPInputStream.java line 97:
> 
>> 95:      */
>> 96:     private static Inflater createInflater(InputStream in, int size) {
>> 97:         Objects.requireNonNull(in);
> 
> I don't believe we currently indicate at at NPE will be thrown if the InputStream is null so this would require a CSR if we need to document it

Hello Lance, both the constructors of `GZIPInputStream` already state that they throw a NullPointerException when the input stream is null:


     * @throws    NullPointerException if {@code in} is null

It was already being thrown from within the super constructor. To prevent creation of a `Inflater` when `in` is null, I had to add this check here.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19475#discussion_r1621554479

From jpai at openjdk.org  Fri May 31 01:02:41 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 31 May 2024 01:02:41 GMT
Subject: RFR: 7022325: TEST_BUG:
 test/java/util/zip/ZipFile/ReadLongZipFileName.java leaks files if it fails
Message-ID: <3IbUCEnZFVdQyBOtxtjoqRNfhlJYQVZ6DagF6T9mGgA=.adf1c246-1b8d-4609-bf58-5e381bcd5ae3@github.com>

Can I please get a review of this test-only change which updates a couple of places in the test to use `try-with-resource`?

As noted in https://bugs.openjdk.org/browse/JDK-7022325 this change should prevent leaking of resources in case there's any failure in the test. The test continues to pass with this change.

-------------

Commit messages:
 - 7022325: TEST_BUG: test/java/util/zip/ZipFile/ReadLongZipFileName.java leaks files if it fails

Changes: https://git.openjdk.org/jdk/pull/19492/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19492&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-7022325
  Stats: 28 lines in 1 file changed: 2 ins; 4 del; 22 mod
  Patch: https://git.openjdk.org/jdk/pull/19492.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19492/head:pull/19492

PR: https://git.openjdk.org/jdk/pull/19492

From lance.andersen at oracle.com  Fri May 31 01:10:05 2024
From: lance.andersen at oracle.com (Lance Andersen)
Date: Fri, 31 May 2024 01:10:05 +0000
Subject: RFR: 8210471: GZIPInputStream constructor could leak an
 un-end()ed Inflater [v2]
In-Reply-To: <Ymm13N8RjI5kYNByDou1DpCtSQqA3Vd4cPkUr6SV66c=.45b84618-fe35-4fa0-acb9-bc7a9aa3787d@github.com>
References: <zugElcASx7a5x5uqkjArVCSH2zWDzsAFeJ9XB5FhXfE=.d5dbc5af-2af4-48cb-ba1b-724924de23f4@github.com>
 <oh3vme22_tGraiuVSHUwLdrmZQfuXWcgQN3F_4ksyuY=.7fee6023-66e5-4ea4-a3cb-8cbb6c124dc6@github.com>
 <Bjj-rJ0tqG8oswA6GnoHJnKinVdfaMSyFrNch2hOHfw=.0db6820a-5219-4bef-9240-6136daf10cf3@github.com>
 <Ymm13N8RjI5kYNByDou1DpCtSQqA3Vd4cPkUr6SV66c=.45b84618-fe35-4fa0-acb9-bc7a9aa3787d@github.com>
Message-ID: <A5627C70-C56F-4235-923C-423B4D14DD33@oracle.com>

I was looking at jdk 22 and now see the npe was added to the constructor specification earlier this year and I reviewed it?
Sent from my iPad

> On May 30, 2024, at 8:56?PM, Jaikiran Pai <jpai at openjdk.org> wrote:
> 
> ?On Thu, 30 May 2024 14:56:00 GMT, Lance Andersen <lancea at openjdk.org> wrote:
> 
>>> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
>>> 
>>>  introduce a basic test for GZIPInputStream
>> 
>> src/java.base/share/classes/java/util/zip/GZIPInputStream.java line 97:
>> 
>>> 95:      */
>>> 96:     private static Inflater createInflater(InputStream in, int size) {
>>> 97:         Objects.requireNonNull(in);
>> 
>> I don't believe we currently indicate at at NPE will be thrown if the InputStream is null so this would require a CSR if we need to document it
> 
> Hello Lance, both the constructors of `GZIPInputStream` already state that they throw a NullPointerException when the input stream is null:
> 
> 
>     * @throws    NullPointerException if {@code in} is null
> 
> It was already being thrown from within the super constructor. To prevent creation of a `Inflater` when `in` is null, I had to add this check here.
> 
> -------------
> 
> PR Review Comment: https://git.openjdk.org/jdk/pull/19475#discussion_r1621554479

From jai.forums2013 at gmail.com  Fri May 31 01:22:10 2024
From: jai.forums2013 at gmail.com (Jaikiran Pai)
Date: Fri, 31 May 2024 06:52:10 +0530
Subject: RFR: 8210471: GZIPInputStream constructor could leak an
 un-end()ed Inflater [v2]
In-Reply-To: <A5627C70-C56F-4235-923C-423B4D14DD33@oracle.com>
References: <zugElcASx7a5x5uqkjArVCSH2zWDzsAFeJ9XB5FhXfE=.d5dbc5af-2af4-48cb-ba1b-724924de23f4@github.com>
 <oh3vme22_tGraiuVSHUwLdrmZQfuXWcgQN3F_4ksyuY=.7fee6023-66e5-4ea4-a3cb-8cbb6c124dc6@github.com>
 <Bjj-rJ0tqG8oswA6GnoHJnKinVdfaMSyFrNch2hOHfw=.0db6820a-5219-4bef-9240-6136daf10cf3@github.com>
 <Ymm13N8RjI5kYNByDou1DpCtSQqA3Vd4cPkUr6SV66c=.45b84618-fe35-4fa0-acb9-bc7a9aa3787d@github.com>
 <A5627C70-C56F-4235-923C-423B4D14DD33@oracle.com>
Message-ID: <14a789df-fe93-41d3-a8ed-e1b45f5731a1@gmail.com>

Now that you mentioned it was added in Java 23, I went back to check 
what change brought that in. Turns out it was me who introduced it, that 
too as recently as a few months back. I too had forgotten about it :)

-Jaikiran

On 31/05/24 6:40 am, Lance Andersen wrote:
> I was looking at jdk 22 and now see the npe was added to the constructor specification earlier this year and I reviewed it?
> Sent from my iPad
>
>> On May 30, 2024, at 8:56?PM, Jaikiran Pai <jpai at openjdk.org> wrote:
>>
>> ?On Thu, 30 May 2024 14:56:00 GMT, Lance Andersen <lancea at openjdk.org> wrote:
>>
>>>> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
>>>>
>>>>   introduce a basic test for GZIPInputStream
>>> src/java.base/share/classes/java/util/zip/GZIPInputStream.java line 97:
>>>
>>>> 95:      */
>>>> 96:     private static Inflater createInflater(InputStream in, int size) {
>>>> 97:         Objects.requireNonNull(in);
>>> I don't believe we currently indicate at at NPE will be thrown if the InputStream is null so this would require a CSR if we need to document it
>> Hello Lance, both the constructors of `GZIPInputStream` already state that they throw a NullPointerException when the input stream is null:
>>
>>
>>      * @throws    NullPointerException if {@code in} is null
>>
>> It was already being thrown from within the super constructor. To prevent creation of a `Inflater` when `in` is null, I had to add this check here.
>>
>> -------------
>>
>> PR Review Comment: https://git.openjdk.org/jdk/pull/19475#discussion_r1621554479

From bchristi at openjdk.org  Fri May 31 01:34:45 2024
From: bchristi at openjdk.org (Brent Christian)
Date: Fri, 31 May 2024 01:34:45 GMT
Subject: RFR: 8314480: Memory ordering spec updates in java.lang.ref [v34]
In-Reply-To: <R74ontYwjYg6HeZY0cWrlo0amjl4E1YsFWeuh4pda14=.08ac62df-b2f8-4b4d-b338-07adb289601b@github.com>
References: <R74ontYwjYg6HeZY0cWrlo0amjl4E1YsFWeuh4pda14=.08ac62df-b2f8-4b4d-b338-07adb289601b@github.com>
Message-ID: <XBDlBM4z3j6VBhSkGkdQOAKSKnKJ-pdUKW961jfl4LY=.9cf0d01b-fa94-4652-bed5-dc3a53617301@github.com>

> Classes in the `java.lang.ref` package would benefit from an update to bring the spec in line with how the VM already behaves. The changes would focus on _happens-before_ edges at some key points during reference processing.
> 
> A couple key things we want to be able to say are:
> - `Reference.reachabilityFence(x)` _happens-before_ reference processing occurs for 'x'.
> - `Cleaner.register()` _happens-before_ the Cleaner thread runs the registered cleaning action.
> 
> This will bring Cleaner in line (or close) with the memory visibility guarantees made for finalizers in [JLS 17.4.5](https://docs.oracle.com/javase/specs/jls/se18/html/jls-17.html#jls-17.4.5):
> _"There is a happens-before edge from the end of a constructor of an object to the start of a finalizer (?12.6) for that object."_

Brent Christian has updated the pull request incrementally with one additional commit since the last revision:

  simplify some java.lang.ref package doc links

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/16644/files
  - new: https://git.openjdk.org/jdk/pull/16644/files/33334d06..e02bf98e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16644&range=33
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16644&range=32-33

  Stats: 6 lines in 2 files changed: 0 ins; 1 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/16644.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16644/head:pull/16644

PR: https://git.openjdk.org/jdk/pull/16644

From bchristi at openjdk.org  Fri May 31 01:34:52 2024
From: bchristi at openjdk.org (Brent Christian)
Date: Fri, 31 May 2024 01:34:52 GMT
Subject: RFR: 8314480: Memory ordering spec updates in java.lang.ref [v32]
In-Reply-To: <uMV_TS2cChxa1ajeMsUFxhLzcxIw1mXCEfiUZ4nZIok=.596fe594-23a8-46a8-b8bb-0fc66c76f261@github.com>
References: <R74ontYwjYg6HeZY0cWrlo0amjl4E1YsFWeuh4pda14=.08ac62df-b2f8-4b4d-b338-07adb289601b@github.com>
 <B0N9o2KSYGCNvvsmnpJ3dqFoRHAR2TaVHrpOpH4WWG4=.27a02e0c-1cf1-4912-860d-3263581d7237@github.com>
 <uMV_TS2cChxa1ajeMsUFxhLzcxIw1mXCEfiUZ4nZIok=.596fe594-23a8-46a8-b8bb-0fc66c76f261@github.com>
Message-ID: <L9acQHYRxACQAXsms9MWAA_PjnOafppRulDcGBWUfkY=.c82da600-eb62-4b98-8bea-fc34ecc9dedb@github.com>

On Thu, 30 May 2024 05:14:30 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Brent Christian has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 69 commits:
>> 
>>  - Merge branch 'master' into refDocs2
>>  - add link to Thread.isAlive()
>>  - small review tweaks; shorten MemoryConsistency links
>>  - small grammar fixes
>>  - new section for finalizer memviz
>>  - add memviz bullet for finalization
>>  - remove quotes from dequeue
>>  - package spec updates, mostly about reference queues and dequeueing
>>  - move reachability section before notification; update section header
>>  - add details on use of reference queues; swap reachability/memviz sections
>>  - ... and 59 more: https://git.openjdk.org/jdk/compare/7bf1989f...d7cbf0d3
>
> src/java.base/share/classes/java/lang/ref/Reference.java line 491:
> 
>> 489:      * method is <b><i>unsuccessful</i></b> and returns false.
>> 490:      *
>> 491:      * <p><a href="package-summary.html#MemoryConsistency">Memory consistency effects</a>:
> 
> Note the `<a href="package-summary.thml#Foo>` syntax can be replaced with something like
> `{@link java.lang.ref##Foo}`.

Thanks. I've updated the links that don't involve italicized/emphasized text.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16644#discussion_r1621570783

From darcy at openjdk.org  Fri May 31 02:26:12 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 31 May 2024 02:26:12 GMT
Subject: RFR: 8314480: Memory ordering spec updates in java.lang.ref [v34]
In-Reply-To: <XBDlBM4z3j6VBhSkGkdQOAKSKnKJ-pdUKW961jfl4LY=.9cf0d01b-fa94-4652-bed5-dc3a53617301@github.com>
References: <R74ontYwjYg6HeZY0cWrlo0amjl4E1YsFWeuh4pda14=.08ac62df-b2f8-4b4d-b338-07adb289601b@github.com>
 <XBDlBM4z3j6VBhSkGkdQOAKSKnKJ-pdUKW961jfl4LY=.9cf0d01b-fa94-4652-bed5-dc3a53617301@github.com>
Message-ID: <ifoal7AA3eYPPiOzdXfVtdipBbEzVtepTnGICQHarL8=.f6391cb0-ad8b-442f-bffb-52b4909a079a@github.com>

On Fri, 31 May 2024 01:34:45 GMT, Brent Christian <bchristi at openjdk.org> wrote:

>> Classes in the `java.lang.ref` package would benefit from an update to bring the spec in line with how the VM already behaves. The changes would focus on _happens-before_ edges at some key points during reference processing.
>> 
>> A couple key things we want to be able to say are:
>> - `Reference.reachabilityFence(x)` _happens-before_ reference processing occurs for 'x'.
>> - `Cleaner.register()` _happens-before_ the Cleaner thread runs the registered cleaning action.
>> 
>> This will bring Cleaner in line (or close) with the memory visibility guarantees made for finalizers in [JLS 17.4.5](https://docs.oracle.com/javase/specs/jls/se18/html/jls-17.html#jls-17.4.5):
>> _"There is a happens-before edge from the end of a constructor of an object to the start of a finalizer (?12.6) for that object."_
>
> Brent Christian has updated the pull request incrementally with one additional commit since the last revision:
> 
>   simplify some java.lang.ref package doc links

Marked as reviewed by darcy (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/16644#pullrequestreview-2089797089

From asemenyuk at openjdk.org  Fri May 31 03:05:04 2024
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Fri, 31 May 2024 03:05:04 GMT
Subject: Integrated: 8333307: Don't suppress jpackage logging in tests when it
 is detecting packaging tools in the system
In-Reply-To: <QGZC7XIKGG88vfB2-sJal2TjyAiFep4mGgXu9UA0cJY=.18d6beb0-aa54-468f-8eb7-482b356944c7@github.com>
References: <QGZC7XIKGG88vfB2-sJal2TjyAiFep4mGgXu9UA0cJY=.18d6beb0-aa54-468f-8eb7-482b356944c7@github.com>
Message-ID: <K6xsVblA9KWMbfJRHtDrTrZ_DdCACTt-HM-gnGlU6Bk=.64b465f3-e35a-452b-8446-ca989893e7fb@github.com>

On Thu, 30 May 2024 20:26:02 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> Change jpackage tests output from:
> 
> 
> [19:16:29.586] Create: SimplePackageTest.test
> [19:16:29.587] [ RUN ] SimplePackageTest.test
> [19:16:29.663] TRACE: Bundler rpm supported
> [19:16:29.674] TRACE: Actions: [[initialize], [create], [unpack], [verify-install], [finalize]]
> 
> 
> to:
> 
> 
> [19:16:29.586] Create: SimplePackageTest.test
> [19:16:29.587] [ RUN ] SimplePackageTest.test
> [19:16:29.621] Running dpkg
> [19:16:29.633] Running dpkg-deb
> [19:16:29.651] Running rpmbuild
> [19:16:29.663] TRACE: Bundler rpm supported
> [19:16:29.674] TRACE: Actions: [[initialize], [create], [unpack], [verify-install], [finalize]]

This pull request has now been integrated.

Changeset: e304a8ae
Author:    Alexey Semenyuk <asemenyuk at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/e304a8ae63fdec125e085bd5048d62cf555e2caa
Stats:     29 lines in 1 file changed: 27 ins; 0 del; 2 mod

8333307: Don't suppress jpackage logging in tests when it is detecting packaging tools in the system

Reviewed-by: almatvee

-------------

PR: https://git.openjdk.org/jdk/pull/19489

From asemenyuk at openjdk.org  Fri May 31 03:06:07 2024
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Fri, 31 May 2024 03:06:07 GMT
Subject: RFR: 8332110: [macos] jpackage tries to sign added files without
 the --mac-sign option [v2]
In-Reply-To: <HI6HYfkNrR1fV5fKnQbAwk-TUWPhRjYIEfdnosvAZ60=.b205f7ba-d2c8-46bc-b192-439d318df63f@github.com>
References: <eiboU_LgwkTte_7rkPJAdDm1x_-Pzm8rdwUiY_4MAYI=.b982e161-fe24-44ab-9db5-2f1d80eb0d99@github.com>
 <HI6HYfkNrR1fV5fKnQbAwk-TUWPhRjYIEfdnosvAZ60=.b205f7ba-d2c8-46bc-b192-439d318df63f@github.com>
Message-ID: <MHX7njtAIaHbux16PHC0OmzQTP1So7-LVfa4iKnaYS8=.55735e6f-8f60-4de6-9af5-eac8c7a861d4@github.com>

On Thu, 30 May 2024 22:54:12 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

>> This issue is reproducible with and without `--mac-sign`. jpackage will "_ad-hoc_" sign application bundle when `--mac-sign` is not specified by using pseudo-identity "_-_". This is why jpackage tries to sign added files and this is expected behavior by jpackage. "codesign" fails since added content made application bundle structure invalid. There is nothing we can do on jpackage side to sign such invalid bundles. As proposed solution we will output possible reason for "codesign" failure if it fails and `--app-content` was specified and possible solution. Proposed message: "One of the possible reason for "codesign" failure is additional content provided via "--app-content", which made application bundle structure invalid. Make sure to provide additional content in a way it will not break application bundle structure, otherwise add additional content as post-processing step."
>> 
>> Example:
>> Lets assume we have "ReadMe" folder with "ReadMe.txt" file in it.
>> 1) jpackage --type app-image -n Test --app-content ReadMe/ReadMe.txt ...
>> "codesign" will fail with "In subcomponent: Test.app/Contents/ReadMe.txt". This is expected and "ReadMe.txt" placed in "Test.app/Contents" which is also expected.
>> 2) jpackage --type app-image -n Test --app-content ReadMe ...
>> Works and "ReadMe.txt" will be placed under "Test.app/Contents/ReadMe".
>> 
>> Sample output before fix:
>> 
>> Error: "codesign" failed with following output:
>> Test.app: replacing existing signature
>> Test.app: code object is not signed at all
>> In subcomponent: Test.app/Contents/ReadMe.txt
>> 
>> 
>> Sample output after fix:
>> 
>> "codesign" failed and additional application content was supplied via the "--app-content" parameter. Probably the additional content broke the integrity of the application bundle and caused the failure. Ensure content supplied via the "--app-content" parameter does not break the integrity of the application bundle, or add it in the post-processing step.
>> Error: "codesign" failed with following output:
>> Test.app: replacing existing signature
>> Test.app: code object is not signed at all
>> In subcomponent: Test.app/Contents/ReadMe.txt
>
> Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8332110: jpackage tries to sign added files without the --mac-sign option [v2]

Marked as reviewed by asemenyuk (Reviewer).

test/jdk/tools/jpackage/macosx/SigningOptionsTest.java line 97:

> 95:                     new String[]{"--app-content", TEST_DUKE},
> 96:                     null,
> 97:                     "\"codesign\" failure is additional content provided via \"--app-content\""},

Why is this not a `One of the possible reason for "{0}" failure is additional content provided via "--app-content"`?

-------------

PR Review: https://git.openjdk.org/jdk/pull/19377#pullrequestreview-2088429523
PR Review Comment: https://git.openjdk.org/jdk/pull/19377#discussion_r1620824169

From asemenyuk at openjdk.org  Fri May 31 03:08:07 2024
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Fri, 31 May 2024 03:08:07 GMT
Subject: Integrated: 8333303: Issues with DottedVersion class
In-Reply-To: <65hH6QalinCN-LZjuppxoFiPGpGfhgOFlr9nsGz-dNc=.4e6c1975-c06d-42b5-9086-a7c34e1852ba@github.com>
References: <65hH6QalinCN-LZjuppxoFiPGpGfhgOFlr9nsGz-dNc=.4e6c1975-c06d-42b5-9086-a7c34e1852ba@github.com>
Message-ID: <vlK0qvjaROcxCQTYn-ItJlwP04XhfLjYA3BlUamOnz4=.4a79713e-e675-4878-b3a5-6e4ad154fcca@github.com>

On Thu, 30 May 2024 20:10:05 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> - Get rid of DottedVersion#greedy field.
>  - Add support to save the unrecognizable remainder of the version string (required to handle Wix4 version string).
>  - Implement DottedVersion#equals().
>  - add DottedVersion#compareComponents(DottedVersion, DottedVersion) that compares recognized components of the given DottedVersion instances.
>  - remove DottedVersion#compareTo(String)
> 
> [Edit](https://bugs.openjdk.org/secure/EditComment!default.jspa?id=5130726&commentId=14677610)
> [Delete](https://bugs.openjdk.org/secure/DeleteComment!default.jspa?id=5130726&commentId=14677610)

This pull request has now been integrated.

Changeset: 1b7d59f1
Author:    Alexey Semenyuk <asemenyuk at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/1b7d59f171d0e2a3bdd234cddffac548b1f8ba57
Stats:     320 lines in 6 files changed: 195 ins; 58 del; 67 mod

8333303: Issues with DottedVersion class

Reviewed-by: almatvee

-------------

PR: https://git.openjdk.org/jdk/pull/19488

From asotona at openjdk.org  Fri May 31 06:29:12 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Fri, 31 May 2024 06:29:12 GMT
Subject: Integrated: 8320396: Class-File API ClassModel::verify should include
 checks from hotspot/share/classfile/classFileParser.cpp
In-Reply-To: <0a66asWcJ4_zBrjmReA18BZmsovN1ZeJRRSAPZDMZmo=.5bada03f-d88d-46cd-962d-c1e42c3048c1@github.com>
References: <0a66asWcJ4_zBrjmReA18BZmsovN1ZeJRRSAPZDMZmo=.5bada03f-d88d-46cd-962d-c1e42c3048c1@github.com>
Message-ID: <t44nXMCTQBJUtypZqorHctTaY7GQF-sh_jPMQH28rA0=.ce701298-4433-422a-908f-d94ac04cd262@github.com>

On Fri, 24 Nov 2023 13:20:20 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> ClassFile API `jdk.internal.classfile.verifier.VerifierImpl` performed only bytecode-level class verification.
> This patch adds `jdk.internal.classfile.verifier.ParserVerifier` with additional class checks inspired by `hotspot/share/classfile/classFileParser.cpp`.
> 
> Also new `VerifierSelfTest::testParserVerifier` has been added.
> 
> Please review.
> 
> Thanks,
> Adam

This pull request has now been integrated.

Changeset: 22ef827e
Author:    Adam Sotona <asotona at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/22ef827e2cc2409f21ad5c26611cb13d39b5cb3e
Stats:     869 lines in 6 files changed: 835 ins; 7 del; 27 mod

8320396: Class-File API ClassModel::verify should include checks from hotspot/share/classfile/classFileParser.cpp

Reviewed-by: liach, mcimadamore

-------------

PR: https://git.openjdk.org/jdk/pull/16809

From asotona at openjdk.org  Fri May 31 06:49:28 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Fri, 31 May 2024 06:49:28 GMT
Subject: RFR: 8182774: Verify code in javap [v3]
In-Reply-To: <khSsamCrV5bkc6ySKQDBYoTHsSyjGggfqkzoc7YxfTo=.2588f7fa-e91e-4e99-bd75-1e77e4b17c6a@github.com>
References: <khSsamCrV5bkc6ySKQDBYoTHsSyjGggfqkzoc7YxfTo=.2588f7fa-e91e-4e99-bd75-1e77e4b17c6a@github.com>
Message-ID: <HqnL81laJw2bljwi0IgrwgZ32Lx0VJgMrwLzXnBSkUw=.cab3d23a-5b6c-4d45-b6a2-cd5c7113f86b@github.com>

> This patch adds `javap -verify` option to check the class and print obvious verification errors found.
> Implementation depends on extended Class-File API verification support, so PR #16809 is important to precede.
> The new `javap` option is mentioned in man pages and a release note will be provided.
> 
> Please review.
> 
> Thank you,
> Adam

Adam Sotona has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 34 commits:

 - Merge branch 'master' into JDK-8182774-javap-verify
   
   # Conflicts:
   #	src/java.base/share/classes/jdk/internal/classfile/impl/verifier/ParserVerifier.java
   #	src/java.base/share/classes/jdk/internal/classfile/impl/verifier/VerifierImpl.java
   #	test/jdk/jdk/classfile/VerifierSelfTest.java
 - fixed typo
 - added VerificationTest
 - Merge branch 'JDK-8320396-verifier-extension' into JDK-8182774-javap-verify
 - Merge branch 'master' into JDK-8320396-verifier-extension
 - added description to javap cmd help and man page
 - 8182774: Verify code in javap
 - added references to jvms
 - Merge remote-tracking branch 'openjdk/master' into JDK-8320396-verifier-extension
 - work in progress
 - ... and 24 more: https://git.openjdk.org/jdk/compare/22ef827e...2cbcb1b4

-------------

Changes: https://git.openjdk.org/jdk/pull/18629/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18629&range=02
  Stats: 101 lines in 6 files changed: 101 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/18629.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18629/head:pull/18629

PR: https://git.openjdk.org/jdk/pull/18629

From jpai at openjdk.org  Fri May 31 08:02:06 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 31 May 2024 08:02:06 GMT
Subject: RFR: 8329581: Java launcher no longer prints a stack trace [v10]
In-Reply-To: <nFQS3JDegumTJOWSla6qGad04vc7PP7W3ZZ483XQuqs=.d28be017-00a0-44e0-9eee-bd70d56498e8@github.com>
References: <Z0pDMIc_XvZhcZdeFsIQUlqI17q5ybj0BnQ9Kl3jwxg=.8f981c46-a8a3-4520-a6e3-79ee7fce0253@github.com>
 <nFQS3JDegumTJOWSla6qGad04vc7PP7W3ZZ483XQuqs=.d28be017-00a0-44e0-9eee-bd70d56498e8@github.com>
Message-ID: <2h6DHUPdxCOz0bPxibHF220Vlmx57Iv0QQ82Ye6vDAQ=.d98292f4-72ef-4632-b745-f149f43613e4@github.com>

On Thu, 9 May 2024 19:52:12 GMT, Sonia Zaldana Calles <szaldana at openjdk.org> wrote:

>> Hi folks, 
>> 
>> This PR aims to fix [JDK-8329581](https://bugs.openjdk.org/browse/JDK-8329581). 
>> 
>> I think the regression got introduced in [JDK-8315458](https://bugs.openjdk.org/browse/JDK-8315458). 
>> 
>> In the issue linked above, [LauncherHelper#getMainType](https://github.com/openjdk/jdk/pull/16461/files#diff-108a3a3e3c2d108c8c7f19ea498f641413b7c9239ecd2975a6c27d904c2ba226) got removed to simplify launcher code.
>> 
>> Previously, we used ```getMainType``` to do the appropriate main method invocation in ```JavaMain```. However, we currently attempt to do all types of main method invocations at the same time [here](https://github.com/openjdk/jdk/blob/master/src/java.base/share/native/libjli/java.c#L623). 
>> 
>> Note how all of these invocations clear the exception reported with [CHECK_EXCEPTION_FAIL](https://github.com/openjdk/jdk/blob/140f56718bbbfc31bb0c39255c68568fad285a1f/src/java.base/share/native/libjli/java.c#L390). 
>> 
>> Therefore, if a legitimate exception comes up during one of these invocations, it does not get reported. 
>> 
>> I propose reintroducing ```LauncherHelper#getMainType``` but I'm looking forward to your suggestions. 
>> 
>> Cheers, 
>> Sonia
>
> Sonia Zaldana Calles has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Decreasing diff size addressing unnecessary changes

Hello Sonia, I happened to be working on something else and ended up hitting an issue where the java launch was no longer throwing the exception from the main application and realized that this PR hasn't been integrated.

I see Alan has suggested a change but I'm unsure if you plan to implement that in this PR or if that's something that's suggested for a subsequent cleanup. I think it would be good to have the review suggestions resolved soon and have this integrated.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18786#issuecomment-2141428133

From asotona at openjdk.org  Fri May 31 08:51:13 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Fri, 31 May 2024 08:51:13 GMT
Subject: Integrated: 8182774: Verify code in javap
In-Reply-To: <khSsamCrV5bkc6ySKQDBYoTHsSyjGggfqkzoc7YxfTo=.2588f7fa-e91e-4e99-bd75-1e77e4b17c6a@github.com>
References: <khSsamCrV5bkc6ySKQDBYoTHsSyjGggfqkzoc7YxfTo=.2588f7fa-e91e-4e99-bd75-1e77e4b17c6a@github.com>
Message-ID: <6zXZhWlSOTzyaDCB7GWjx3X4DGCLywEgFYZ_45mawUY=.16070c31-4988-47ba-9867-737982ebbb86@github.com>

On Thu, 4 Apr 2024 15:13:46 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> This patch adds `javap -verify` option to check the class and print obvious verification errors found.
> Implementation depends on extended Class-File API verification support, so PR #16809 is important to precede.
> The new `javap` option is mentioned in man pages and a release note will be provided.
> 
> Please review.
> 
> Thank you,
> Adam

This pull request has now been integrated.

Changeset: a7864af0
Author:    Adam Sotona <asotona at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a7864af08acbe63d09f770ca66780738260faac4
Stats:     101 lines in 6 files changed: 101 ins; 0 del; 0 mod

8182774: Verify code in javap

Reviewed-by: mcimadamore

-------------

PR: https://git.openjdk.org/jdk/pull/18629

From jpai at openjdk.org  Fri May 31 09:06:11 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 31 May 2024 09:06:11 GMT
Subject: RFR: 8333130: MakeJAR2.sh uses hard-coded JDK version
Message-ID: <b7zNC0INazceqMBgTTUTpQd11C8V-3uQsCHPUuw_f8I=.7f7ecc22-7465-45c9-8ae2-df851523bb9b@github.com>

Can I please get a review of this test-only change which addresses https://bugs.openjdk.org/browse/JDK-8333130?

There are a couple of tests `NativeMethodPrefixApp` and `RetransformApp` under `test/jdk/java/lang/instrument/` which launch  the app/test with a `-javaagent:<jar>` pointing to a test specific jar. The test, launched with that `javaagent`, then verifies the test specific details.

In their current form, in order to construct the agent `.jar` and make it available to the jtreg test that's launched, they `@run` a  jtreg `shell` test. This `shell` test uses the `MakeJAR2.sh` script to generate the jar file. The contents of the script is relatively straightforward - it compiles (using `javac`) some boot classpath classes, some agent specific classes and then generates a jar file with the agent classes and a `MANIFEST.MF` which points to the boot classpath classes along with test specific manifest attributes. In a recent PR the `MakeJAR2.sh` script was updated to pass `--enable-preview --release 23` since one of the existing agent class was updated to use the ClassFile API PreviewFeature (https://github.com/openjdk/jdk/pull/13009).

This generated agent jar then is passed as `-javaagent:` to the subsequent `@run main` test which does the actual testing.

So essentially the `shell` test which uses the `MakeJAR2.sh` is merely there to create a jar file that's needed by the actual test. Within the JDK we have several tests which compile other classes and generate jar files using in-process test libraries and the `java.util.spi.ToolProvider` implementations. These 2 tests too can be updated to use a similar technique, to completely get rid of the `MakeJAR2.sh`. Removing the `MakeJAR2.sh` will simplify the ability to pass around value for `--release` when using `--enable-preview`.

The commit in this PR updates these 2 tests to use `@run driver` which then compiles relevant classes (maintaining the semantics of `MakeJAR2.sh`) and generates the agent jar file and then finally launching the test process. As part of the update, I did not retain the `@author` tag from the 2 test definitions, since it's my understanding that we no longer use those. I will add them back if we should retain them.

The tests continue to pass locally with this change. I've also triggered tier testing in our CI for this change.

-------------

Commit messages:
 - 8333130: MakeJAR2.sh uses hard-coded JDK version

Changes: https://git.openjdk.org/jdk/pull/19495/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19495&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8333130
  Stats: 409 lines in 5 files changed: 265 ins; 131 del; 13 mod
  Patch: https://git.openjdk.org/jdk/pull/19495.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19495/head:pull/19495

PR: https://git.openjdk.org/jdk/pull/19495

From duke at openjdk.org  Fri May 31 09:07:15 2024
From: duke at openjdk.org (MaxXing)
Date: Fri, 31 May 2024 09:07:15 GMT
Subject: RFR: 8333334: C2: Make result of `Node::dominates` more precise to
 enhance scalar replacement
Message-ID: <ARdyBPCqSDKlOM-u5kGZGqgOySxOT2MbznAiZaQMWx8=.21dfdc0c-1b92-4484-ad05-203e819a8569@github.com>

This patch changes the algorithm of `Node::dominates` to make the result more precise, and allows the iterators of `ConcurrentHashMap` to be scalar replaced.

The previous algorithm will return a conservative result when encountering a dead control flow, and only try the first two input paths of a multi-input Region node, which may prevent the scalar replacement in some cases.

For example, with G1 GC enabled, C2 generates GC barriers for `ConcurrentHashMap` iteration operations at some early phases, and then eliminates them in a later IGVN, but `LoadNode` is also idealized in the same IGVN. This causes `LoadNode::Ideal` to see some dead barrier control flows, and refuse to split some instance field loads through Phi due to the conservative result of `Node::dominates`, and thus the scalar replacement can not be applied to iterators in the later macro elimination phase.

This patch allows `Node::dominates` to try other paths of the last multi-input Region node when the first path is dead, and makes `ConcurrentHashMap` iteration ~30% faster:


Benchmark                            (nkeys)  Mode  Cnt        Score       Error  Units
Maps.testConcurrentHashMapIterators    10000  avgt   15   414099.085 ? 33230.945  ns/op   # baseline
Maps.testConcurrentHashMapIterators    10000  avgt   15   315490.281 ?  3037.056  ns/op   # patch


Testing: tier1-4.

-------------

Commit messages:
 - Make `Node::dominates` more precise so that iterators of `ConcurrentHashMap` can be scalar replaced.

Changes: https://git.openjdk.org/jdk/pull/19496/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19496&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8333334
  Stats: 87 lines in 4 files changed: 53 ins; 15 del; 19 mod
  Patch: https://git.openjdk.org/jdk/pull/19496.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19496/head:pull/19496

PR: https://git.openjdk.org/jdk/pull/19496

From jpai at openjdk.org  Fri May 31 10:09:20 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 31 May 2024 10:09:20 GMT
Subject: RFR: 8210471: GZIPInputStream constructor could leak an un-end()ed
 Inflater [v3]
In-Reply-To: <zugElcASx7a5x5uqkjArVCSH2zWDzsAFeJ9XB5FhXfE=.d5dbc5af-2af4-48cb-ba1b-724924de23f4@github.com>
References: <zugElcASx7a5x5uqkjArVCSH2zWDzsAFeJ9XB5FhXfE=.d5dbc5af-2af4-48cb-ba1b-724924de23f4@github.com>
Message-ID: <aBqnjrW1AAopOnVI67Rg2TVd904BsO_VJJiDxe4MitQ=.b527d7bb-b715-44a8-8ece-1bdd8c58ecef@github.com>

> Can I please get a review of this change which proposes to address the issue noted in https://bugs.openjdk.org/browse/JDK-8210471?
> 
> `java.util.zip.Inflater` when instantiated will hold on the native resources which are freed only when `Inflater.end()` is called. The constructor of `java.util.zip.GZIPInputStream` instantiates an `Inflater` for its internal use. After instantiating the `Inflater`, the `GZIPInputStream` constructor before returning from the constructor, can run into either a `IllegalArgumentException` (because the `size` is `<=0`) or an `IOException` when trying to read a GZIP header from the underlying `InputStream`. In either of these cases, the `Inflater` that the `GZIPInputStream` created internally will end up leaking and the caller has no way to `end()` that `Inflater` or even knowledge of that `Inflater`.
> 
> The commit in this PR catches the `IOException` when reading the GZIP header and `end()`s the `Inflater`. Furthermore, to prevent instantiation of an `Inflater`, the `GZIPInputStream` constructor before calling `super(...)` will now check the `InputStream` to be non-null and `size` to be `>0`, both of which were being done by the `super` constructor.
> 
> Given the nature of the change, no new test has been added. Existing tests in `test/jdk/java/util/zip` continue to pass and tier1, tier2 and tier3 testing is in progress.

Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:

  enhance the new test to even verify IOException from the constructor

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19475/files
  - new: https://git.openjdk.org/jdk/pull/19475/files/3d079802..a70ddc79

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19475&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19475&range=01-02

  Stats: 11 lines in 1 file changed: 11 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/19475.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19475/head:pull/19475

PR: https://git.openjdk.org/jdk/pull/19475

From dl at openjdk.org  Fri May 31 10:24:40 2024
From: dl at openjdk.org (Doug Lea)
Date: Fri, 31 May 2024 10:24:40 GMT
Subject: RFR: 8322732: ForkJoinPool may underutilize cores in async mode
 [v16]
In-Reply-To: <xRyDMAsSZ7obqpr3Aoc5qrHqILeJMxFVCeiRdctMI3U=.d5d3cd56-32eb-4431-ac01-081822fc86c6@github.com>
References: <xRyDMAsSZ7obqpr3Aoc5qrHqILeJMxFVCeiRdctMI3U=.d5d3cd56-32eb-4431-ac01-081822fc86c6@github.com>
Message-ID: <o0pZEk8Wecac0DcUsU4Ij3KY_ax_YzMsm6WMwDNPcow=.692cb1f4-d6ad-4adb-9a56-ac2fa268d09b@github.com>

> This set of changes address causes of poor utilization with small numbers of cores due to overly aggressive contention avoidance. A number of further adjustments were needed to still avoid most contention effects in deployments with large numbers of cores

Doug Lea 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 50 additional commits since the last revision:

 - Merge branch 'openjdk:master' into JDK-8322732
 - diagnostic
 - Reinstate quiescence signals
 - reshadow; avoid test loop bleed
 - Don't shadow parks
 - re-enable rescan; slim down test
 - unguard signal
 - Merge branch 'openjdk:master' into JDK-8322732
 - Address review comments
 - Merge branch 'openjdk:master' into JDK-8322732
 - ... and 40 more: https://git.openjdk.org/jdk/compare/1dba1675...3836207b

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19131/files
  - new: https://git.openjdk.org/jdk/pull/19131/files/becabd04..3836207b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19131&range=15
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19131&range=14-15

  Stats: 5398 lines in 158 files changed: 3327 ins; 1425 del; 646 mod
  Patch: https://git.openjdk.org/jdk/pull/19131.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19131/head:pull/19131

PR: https://git.openjdk.org/jdk/pull/19131

From lancea at openjdk.org  Fri May 31 10:38:07 2024
From: lancea at openjdk.org (Lance Andersen)
Date: Fri, 31 May 2024 10:38:07 GMT
Subject: RFR: 8210471: GZIPInputStream constructor could leak an un-end()ed
 Inflater [v3]
In-Reply-To: <aBqnjrW1AAopOnVI67Rg2TVd904BsO_VJJiDxe4MitQ=.b527d7bb-b715-44a8-8ece-1bdd8c58ecef@github.com>
References: <zugElcASx7a5x5uqkjArVCSH2zWDzsAFeJ9XB5FhXfE=.d5dbc5af-2af4-48cb-ba1b-724924de23f4@github.com>
 <aBqnjrW1AAopOnVI67Rg2TVd904BsO_VJJiDxe4MitQ=.b527d7bb-b715-44a8-8ece-1bdd8c58ecef@github.com>
Message-ID: <P6O433Edp5vbQGIEOC0kkQ4HK0t5bx0MPOcrosk90Uw=.41028574-b413-4f52-9c48-ad748f1fde14@github.com>

On Fri, 31 May 2024 10:09:20 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change which proposes to address the issue noted in https://bugs.openjdk.org/browse/JDK-8210471?
>> 
>> `java.util.zip.Inflater` when instantiated will hold on the native resources which are freed only when `Inflater.end()` is called. The constructor of `java.util.zip.GZIPInputStream` instantiates an `Inflater` for its internal use. After instantiating the `Inflater`, the `GZIPInputStream` constructor before returning from the constructor, can run into either a `IllegalArgumentException` (because the `size` is `<=0`) or an `IOException` when trying to read a GZIP header from the underlying `InputStream`. In either of these cases, the `Inflater` that the `GZIPInputStream` created internally will end up leaking and the caller has no way to `end()` that `Inflater` or even knowledge of that `Inflater`.
>> 
>> The commit in this PR catches the `IOException` when reading the GZIP header and `end()`s the `Inflater`. Furthermore, to prevent instantiation of an `Inflater`, the `GZIPInputStream` constructor before calling `super(...)` will now check the `InputStream` to be non-null and `size` to be `>0`, both of which were being done by the `super` constructor.
>> 
>> Given the nature of the change, no new test has been added. Existing tests in `test/jdk/java/util/zip` continue to pass and tier1, tier2 and tier3 testing is in progress.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   enhance the new test to even verify IOException from the constructor

Looks fine overall Jai.

Personally, I would have had each assertThrows  as its own test,  as if one fails(which should not in this case) then the rest of the assertions are never executed until the first failure is addressed.

-------------

Marked as reviewed by lancea (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19475#pullrequestreview-2090494111

From jpai at openjdk.org  Fri May 31 11:03:18 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 31 May 2024 11:03:18 GMT
Subject: RFR: 8210471: GZIPInputStream constructor could leak an un-end()ed
 Inflater [v4]
In-Reply-To: <zugElcASx7a5x5uqkjArVCSH2zWDzsAFeJ9XB5FhXfE=.d5dbc5af-2af4-48cb-ba1b-724924de23f4@github.com>
References: <zugElcASx7a5x5uqkjArVCSH2zWDzsAFeJ9XB5FhXfE=.d5dbc5af-2af4-48cb-ba1b-724924de23f4@github.com>
Message-ID: <rT4PRaKhtF4tbwKKC3M8eXX8xPblhVpStHAhBxDx9YU=.ca216d03-fe00-4fa0-9f45-d13ff4eb7d76@github.com>

> Can I please get a review of this change which proposes to address the issue noted in https://bugs.openjdk.org/browse/JDK-8210471?
> 
> `java.util.zip.Inflater` when instantiated will hold on the native resources which are freed only when `Inflater.end()` is called. The constructor of `java.util.zip.GZIPInputStream` instantiates an `Inflater` for its internal use. After instantiating the `Inflater`, the `GZIPInputStream` constructor before returning from the constructor, can run into either a `IllegalArgumentException` (because the `size` is `<=0`) or an `IOException` when trying to read a GZIP header from the underlying `InputStream`. In either of these cases, the `Inflater` that the `GZIPInputStream` created internally will end up leaking and the caller has no way to `end()` that `Inflater` or even knowledge of that `Inflater`.
> 
> The commit in this PR catches the `IOException` when reading the GZIP header and `end()`s the `Inflater`. Furthermore, to prevent instantiation of an `Inflater`, the `GZIPInputStream` constructor before calling `super(...)` will now check the `InputStream` to be non-null and `size` to be `>0`, both of which were being done by the `super` constructor.
> 
> Given the nature of the change, no new test has been added. Existing tests in `test/jdk/java/util/zip` continue to pass and tier1, tier2 and tier3 testing is in progress.

Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:

  rework the test to make it parameterized

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19475/files
  - new: https://git.openjdk.org/jdk/pull/19475/files/a70ddc79..41f5736b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19475&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19475&range=02-03

  Stats: 62 lines in 1 file changed: 38 ins; 9 del; 15 mod
  Patch: https://git.openjdk.org/jdk/pull/19475.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19475/head:pull/19475

PR: https://git.openjdk.org/jdk/pull/19475

From jpai at openjdk.org  Fri May 31 11:03:18 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 31 May 2024 11:03:18 GMT
Subject: RFR: 8210471: GZIPInputStream constructor could leak an un-end()ed
 Inflater [v3]
In-Reply-To: <P6O433Edp5vbQGIEOC0kkQ4HK0t5bx0MPOcrosk90Uw=.41028574-b413-4f52-9c48-ad748f1fde14@github.com>
References: <zugElcASx7a5x5uqkjArVCSH2zWDzsAFeJ9XB5FhXfE=.d5dbc5af-2af4-48cb-ba1b-724924de23f4@github.com>
 <aBqnjrW1AAopOnVI67Rg2TVd904BsO_VJJiDxe4MitQ=.b527d7bb-b715-44a8-8ece-1bdd8c58ecef@github.com>
 <P6O433Edp5vbQGIEOC0kkQ4HK0t5bx0MPOcrosk90Uw=.41028574-b413-4f52-9c48-ad748f1fde14@github.com>
Message-ID: <pmlJ37uiuv3gobOVw0PUiKOJ5hwGhzOFZbYKo41ubug=.bcc92260-1768-42cf-8398-86d20208cbed@github.com>

On Fri, 31 May 2024 10:35:11 GMT, Lance Andersen <lancea at openjdk.org> wrote:

> Personally, I would have had each assertThrows as its own test, as if one fails(which should not in this case) then the rest of the assertions are never executed until the first failure is addressed.

I have now updated the PR to redo this new test to use ParameterizedTest. That way, each one will be run independent of the other. The test continues to pass after this change.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19475#issuecomment-2141776021

From lancea at openjdk.org  Fri May 31 11:09:02 2024
From: lancea at openjdk.org (Lance Andersen)
Date: Fri, 31 May 2024 11:09:02 GMT
Subject: RFR: 8210471: GZIPInputStream constructor could leak an un-end()ed
 Inflater [v4]
In-Reply-To: <rT4PRaKhtF4tbwKKC3M8eXX8xPblhVpStHAhBxDx9YU=.ca216d03-fe00-4fa0-9f45-d13ff4eb7d76@github.com>
References: <zugElcASx7a5x5uqkjArVCSH2zWDzsAFeJ9XB5FhXfE=.d5dbc5af-2af4-48cb-ba1b-724924de23f4@github.com>
 <rT4PRaKhtF4tbwKKC3M8eXX8xPblhVpStHAhBxDx9YU=.ca216d03-fe00-4fa0-9f45-d13ff4eb7d76@github.com>
Message-ID: <mQcLKyUPH7hvq9vbA5dBs7NOYpt_34MliaIePQI9QnA=.8bd4ba06-2573-4630-b13f-e0116220ca66@github.com>

On Fri, 31 May 2024 11:03:18 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change which proposes to address the issue noted in https://bugs.openjdk.org/browse/JDK-8210471?
>> 
>> `java.util.zip.Inflater` when instantiated will hold on the native resources which are freed only when `Inflater.end()` is called. The constructor of `java.util.zip.GZIPInputStream` instantiates an `Inflater` for its internal use. After instantiating the `Inflater`, the `GZIPInputStream` constructor before returning from the constructor, can run into either a `IllegalArgumentException` (because the `size` is `<=0`) or an `IOException` when trying to read a GZIP header from the underlying `InputStream`. In either of these cases, the `Inflater` that the `GZIPInputStream` created internally will end up leaking and the caller has no way to `end()` that `Inflater` or even knowledge of that `Inflater`.
>> 
>> The commit in this PR catches the `IOException` when reading the GZIP header and `end()`s the `Inflater`. Furthermore, to prevent instantiation of an `Inflater`, the `GZIPInputStream` constructor before calling `super(...)` will now check the `InputStream` to be non-null and `size` to be `>0`, both of which were being done by the `super` constructor.
>> 
>> Given the nature of the change, no new test has been added. Existing tests in `test/jdk/java/util/zip` continue to pass and tier1, tier2 and tier3 testing is in progress.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   rework the test to make it parameterized

Thank you Jai for the update.  I think this makes the test much cleaner

-------------

Marked as reviewed by lancea (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19475#pullrequestreview-2090569778

From duke at openjdk.org  Fri May 31 13:07:06 2024
From: duke at openjdk.org (David M. Lloyd)
Date: Fri, 31 May 2024 13:07:06 GMT
Subject: RFR: 8332614: Type-checked ConstantPool.entryByIndex and
 ClassReader.readEntryOrNull [v6]
In-Reply-To: <OwWsHUW2KYU_fyapy_iZ-40Noglvs6eeOxWnLBi_B_k=.36f23c49-b240-4d26-afcd-c9a2ff326d85@github.com>
References: <UP8XpBov1w74UcUrAkD08x3vQGy_zRQ8NFRXuMU8us4=.3cce8ca0-742b-43f2-a282-894c7f61c969@github.com>
 <cvMjPfM9XcTkHA1D_dHe69_RO8S6ElJGeiMX49dOfTc=.e1a1b003-1ab8-4d9d-a522-1ec5a0d66ce1@github.com>
 <N0p3dL80S1JXIVLLNFNs_nWrM1m9A6OOOWWzagDzFkA=.d7b7e1f5-0e96-44f6-aacb-1e2a1521e497@github.com>
 <OwWsHUW2KYU_fyapy_iZ-40Noglvs6eeOxWnLBi_B_k=.36f23c49-b240-4d26-afcd-c9a2ff326d85@github.com>
Message-ID: <CUgFY6j38IGvGJTCdjMeukhVW4mbC57rBq7xjZjsJl8=.f1b16913-d15c-42de-8f0e-b554078e0aee@github.com>

On Thu, 30 May 2024 21:47:02 GMT, Chen Liang <liach at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/classfile/ClassReader.java line 142:
>> 
>>> 140:      * @throws ConstantPoolException if the index is out of range of the
>>> 141:      *         constant pool size, or zero, or the entry is not of the given type
>>> 142:      * @since 24
>> 
>> I just noticed that these are marked `@since 24`. Am I correct that this should be `@since 23`?
>
> Thanks for pointing out, I was under the assumption that this patch might not come into 23. I will create an issue, and you can make a PR if you feel like contributing (doc-only changes can integrate before RDPs so no rush)
> 
> Created an issue at https://bugs.openjdk.org/browse/JDK-8333312

Opened #19501.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19330#discussion_r1622391543

From duke at openjdk.org  Fri May 31 13:09:10 2024
From: duke at openjdk.org (David M. Lloyd)
Date: Fri, 31 May 2024 13:09:10 GMT
Subject: RFR: 8333312: Incorrect since tags on new ClassReader and ConstantPool
 methods
Message-ID: <Jr9vq4Lgl1P9WYJvGMCFJo-vU-rnHgRw9VDK3YoEQgM=.70f480e1-dfdb-47d1-90a6-43fc0c97dd13@github.com>

The new method additions ClassReader.readEntryOrNull(int, Class) and ConstantPool.entryByIndex(int, Class) have incorrect since tags; they should be `@since 23`.

-------------

Commit messages:
 - 8333312: Incorrect since tags on new ClassReader and ConstantPool methods

Changes: https://git.openjdk.org/jdk/pull/19501/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19501&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8333312
  Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/19501.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19501/head:pull/19501

PR: https://git.openjdk.org/jdk/pull/19501

From liach at openjdk.org  Fri May 31 13:15:01 2024
From: liach at openjdk.org (Chen Liang)
Date: Fri, 31 May 2024 13:15:01 GMT
Subject: RFR: 8333312: Incorrect since tags on new ClassReader and
 ConstantPool methods
In-Reply-To: <Jr9vq4Lgl1P9WYJvGMCFJo-vU-rnHgRw9VDK3YoEQgM=.70f480e1-dfdb-47d1-90a6-43fc0c97dd13@github.com>
References: <Jr9vq4Lgl1P9WYJvGMCFJo-vU-rnHgRw9VDK3YoEQgM=.70f480e1-dfdb-47d1-90a6-43fc0c97dd13@github.com>
Message-ID: <Gsv2PPgWDREXhaLH0y8VhK678qOJlzUG1yvXL-Ix2aU=.6f4bb9b7-2c2a-4f1e-b130-9c28ae258b1d@github.com>

On Fri, 31 May 2024 13:04:03 GMT, David M. Lloyd <duke at openjdk.org> wrote:

> The new method additions ClassReader.readEntryOrNull(int, Class) and ConstantPool.entryByIndex(int, Class) have incorrect since tags; they should be `@since 23`.

Marked as reviewed by liach (Author).

-------------

PR Review: https://git.openjdk.org/jdk/pull/19501#pullrequestreview-2090804861

From dl at openjdk.org  Fri May 31 13:18:33 2024
From: dl at openjdk.org (Doug Lea)
Date: Fri, 31 May 2024 13:18:33 GMT
Subject: RFR: 8322732: ForkJoinPool may underutilize cores in async mode
 [v17]
In-Reply-To: <xRyDMAsSZ7obqpr3Aoc5qrHqILeJMxFVCeiRdctMI3U=.d5d3cd56-32eb-4431-ac01-081822fc86c6@github.com>
References: <xRyDMAsSZ7obqpr3Aoc5qrHqILeJMxFVCeiRdctMI3U=.d5d3cd56-32eb-4431-ac01-081822fc86c6@github.com>
Message-ID: <IOco_UwtcYWKCrMyfSpHdFxCLEVaQ8Ktqsw94Y4faoc=.45eb6420-1be9-44e3-b46a-8a49f82082d9@github.com>

> This set of changes address causes of poor utilization with small numbers of cores due to overly aggressive contention avoidance. A number of further adjustments were needed to still avoid most contention effects in deployments with large numbers of cores

Doug Lea has updated the pull request incrementally with one additional commit since the last revision:

  Reconcile changes

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19131/files
  - new: https://git.openjdk.org/jdk/pull/19131/files/3836207b..aedf9fc4

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19131&range=16
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19131&range=15-16

  Stats: 44 lines in 1 file changed: 9 ins; 8 del; 27 mod
  Patch: https://git.openjdk.org/jdk/pull/19131.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19131/head:pull/19131

PR: https://git.openjdk.org/jdk/pull/19131

From vklang at openjdk.org  Fri May 31 13:35:15 2024
From: vklang at openjdk.org (Viktor Klang)
Date: Fri, 31 May 2024 13:35:15 GMT
Subject: RFR: 8314480: Memory ordering spec updates in java.lang.ref [v22]
In-Reply-To: <FfwbHK6PeIQuZprgt9UkHRmZENLUg6iQ-abe9q15XRU=.92b2a9b9-78aa-4145-bb52-461e60eec277@github.com>
References: <R74ontYwjYg6HeZY0cWrlo0amjl4E1YsFWeuh4pda14=.08ac62df-b2f8-4b4d-b338-07adb289601b@github.com>
 <iSAFZXJw0U2itwjjNTLOuChx4kx9K1J6odAc4IyngK8=.67614a1a-833f-4079-8bfa-f204083a3cee@github.com>
 <fa0Mqk6azF75mkiKAwMZHmtC5Lsw4KqcTAMZb3bIJWo=.16abf539-e6c6-4ab5-a937-a0505522d802@github.com>
 <vgHrkAj_5vBtWEy1C8966ZzsP7eUUdW4PQkTs96WD-U=.b488ae70-a7ce-4074-9489-c2a39496c6b6@github.com>
 <FfwbHK6PeIQuZprgt9UkHRmZENLUg6iQ-abe9q15XRU=.92b2a9b9-78aa-4145-bb52-461e60eec277@github.com>
Message-ID: <-RVW9tZxHe4dIBnu08GWxjp1fkInR7UwL48KcfFpLdg=.3755ad56-5de6-40ed-a17c-441d319b2dd8@github.com>

On Wed, 22 May 2024 07:56:26 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>>> @bchristi-git Just checking in?we're waiting for CSR-approval here before integrating? ?
>> 
>> Indeed - can't move forward without a CSR. Also wouldn't mind more reviewer ??s. ?
>
>> Indeed - can't move forward without a CSR. Also wouldn't mind more reviewer ??s. ?
> 
> I can do that.  One other thing to do is to rebase the changes, it looks like this branch is 6 months behind main line.

@AlanBateman @stuart-marks Any final words before @bchristi-git gets to do the honors of integrating? :)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/16644#issuecomment-2142174930

From asotona at openjdk.org  Fri May 31 13:40:01 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Fri, 31 May 2024 13:40:01 GMT
Subject: RFR: 8333312: Incorrect since tags on new ClassReader and
 ConstantPool methods
In-Reply-To: <Jr9vq4Lgl1P9WYJvGMCFJo-vU-rnHgRw9VDK3YoEQgM=.70f480e1-dfdb-47d1-90a6-43fc0c97dd13@github.com>
References: <Jr9vq4Lgl1P9WYJvGMCFJo-vU-rnHgRw9VDK3YoEQgM=.70f480e1-dfdb-47d1-90a6-43fc0c97dd13@github.com>
Message-ID: <SPJbpmmhjaaevRNSjEX7IURGyZCRPPXEB97m_0kBEKA=.f351d8b9-9f5a-48b2-b364-13a0d7ab236f@github.com>

On Fri, 31 May 2024 13:04:03 GMT, David M. Lloyd <duke at openjdk.org> wrote:

> The new method additions ClassReader.readEntryOrNull(int, Class) and ConstantPool.entryByIndex(int, Class) have incorrect since tags; they should be `@since 23`.

Thank you for the fix.

-------------

Marked as reviewed by asotona (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19501#pullrequestreview-2090857569

From jpai at openjdk.org  Fri May 31 13:48:12 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 31 May 2024 13:48:12 GMT
Subject: RFR: 8210471: GZIPInputStream constructor could leak an un-end()ed
 Inflater [v4]
In-Reply-To: <rT4PRaKhtF4tbwKKC3M8eXX8xPblhVpStHAhBxDx9YU=.ca216d03-fe00-4fa0-9f45-d13ff4eb7d76@github.com>
References: <zugElcASx7a5x5uqkjArVCSH2zWDzsAFeJ9XB5FhXfE=.d5dbc5af-2af4-48cb-ba1b-724924de23f4@github.com>
 <rT4PRaKhtF4tbwKKC3M8eXX8xPblhVpStHAhBxDx9YU=.ca216d03-fe00-4fa0-9f45-d13ff4eb7d76@github.com>
Message-ID: <SspmLqkJC-y8e-V3fn_9Gu0AlCyN1nAl4XPAr8WNFcI=.4976c6b4-1a51-4cda-88a0-547e8bdbef61@github.com>

On Fri, 31 May 2024 11:03:18 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change which proposes to address the issue noted in https://bugs.openjdk.org/browse/JDK-8210471?
>> 
>> `java.util.zip.Inflater` when instantiated will hold on the native resources which are freed only when `Inflater.end()` is called. The constructor of `java.util.zip.GZIPInputStream` instantiates an `Inflater` for its internal use. After instantiating the `Inflater`, the `GZIPInputStream` constructor before returning from the constructor, can run into either a `IllegalArgumentException` (because the `size` is `<=0`) or an `IOException` when trying to read a GZIP header from the underlying `InputStream`. In either of these cases, the `Inflater` that the `GZIPInputStream` created internally will end up leaking and the caller has no way to `end()` that `Inflater` or even knowledge of that `Inflater`.
>> 
>> The commit in this PR catches the `IOException` when reading the GZIP header and `end()`s the `Inflater`. Furthermore, to prevent instantiation of an `Inflater`, the `GZIPInputStream` constructor before calling `super(...)` will now check the `InputStream` to be non-null and `size` to be `>0`, both of which were being done by the `super` constructor.
>> 
>> Given the nature of the change, no new test has been added. Existing tests in `test/jdk/java/util/zip` continue to pass and tier1, tier2 and tier3 testing is in progress.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   rework the test to make it parameterized

Thank you Lance for the review. tier testing went fine with the latest state in this PR. I'll go ahead and integrate this now.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19475#issuecomment-2142193675

From jpai at openjdk.org  Fri May 31 13:48:14 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 31 May 2024 13:48:14 GMT
Subject: Integrated: 8210471: GZIPInputStream constructor could leak an
 un-end()ed Inflater
In-Reply-To: <zugElcASx7a5x5uqkjArVCSH2zWDzsAFeJ9XB5FhXfE=.d5dbc5af-2af4-48cb-ba1b-724924de23f4@github.com>
References: <zugElcASx7a5x5uqkjArVCSH2zWDzsAFeJ9XB5FhXfE=.d5dbc5af-2af4-48cb-ba1b-724924de23f4@github.com>
Message-ID: <m4HbwmUvvBOd4c-bU5wj58J0RQ6omPJA28rjg_eZm8M=.d4dad965-e155-44a1-8e36-73415d37f10f@github.com>

On Thu, 30 May 2024 12:14:53 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change which proposes to address the issue noted in https://bugs.openjdk.org/browse/JDK-8210471?
> 
> `java.util.zip.Inflater` when instantiated will hold on the native resources which are freed only when `Inflater.end()` is called. The constructor of `java.util.zip.GZIPInputStream` instantiates an `Inflater` for its internal use. After instantiating the `Inflater`, the `GZIPInputStream` constructor before returning from the constructor, can run into either a `IllegalArgumentException` (because the `size` is `<=0`) or an `IOException` when trying to read a GZIP header from the underlying `InputStream`. In either of these cases, the `Inflater` that the `GZIPInputStream` created internally will end up leaking and the caller has no way to `end()` that `Inflater` or even knowledge of that `Inflater`.
> 
> The commit in this PR catches the `IOException` when reading the GZIP header and `end()`s the `Inflater`. Furthermore, to prevent instantiation of an `Inflater`, the `GZIPInputStream` constructor before calling `super(...)` will now check the `InputStream` to be non-null and `size` to be `>0`, both of which were being done by the `super` constructor.
> 
> Given the nature of the change, no new test has been added. Existing tests in `test/jdk/java/util/zip` continue to pass and tier1, tier2 and tier3 testing is in progress.

This pull request has now been integrated.

Changeset: d9e7b7e7
Author:    Jaikiran Pai <jpai at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/d9e7b7e7da98a0170d26301a4bbd61aad0127c6e
Stats:     118 lines in 2 files changed: 116 ins; 0 del; 2 mod

8210471: GZIPInputStream constructor could leak an un-end()ed Inflater

Reviewed-by: lancea

-------------

PR: https://git.openjdk.org/jdk/pull/19475

From zhengyu.gu at servicenow.com  Fri May 31 14:03:48 2024
From: zhengyu.gu at servicenow.com (Zhengyu Gu)
Date: Fri, 31 May 2024 14:03:48 +0000
Subject: Question on Lambda function
In-Reply-To: <LV8PR08MB955417E4E6ED6C9CBF7ACB3DF0F32@LV8PR08MB9554.namprd08.prod.outlook.com>
References: <LV8PR08MB955444A8983A6E579694DFC7F0F22@LV8PR08MB9554.namprd08.prod.outlook.com>
 <LV8PR08MB955466D6C9CCE80D1F4E48F4F0F22@LV8PR08MB9554.namprd08.prod.outlook.com>
 <CABe8uE3vLVzCH9=nj1wrKSS8nOT-nDJTgRW0M4=2bgrnGxhQog@mail.gmail.com>
 <LV8PR08MB95549FE12A28843BB4ED020AF0F22@LV8PR08MB9554.namprd08.prod.outlook.com>
 <CABe8uE3gfmbeDGb6TVF3Fe=yM4np8OJTWQnEybkn5h7gLBuobw@mail.gmail.com>
 <LV8PR08MB955417E4E6ED6C9CBF7ACB3DF0F32@LV8PR08MB9554.namprd08.prod.outlook.com>
Message-ID: <LV8PR08MB9554A2E4F28653234C93B058F0FC2@LV8PR08MB9554.namprd08.prod.outlook.com>

Hi Chen,

Do you see any pros and cons of wrapping a MethodHandle, e.g.

new Function<D, C>() {
  @Override
  public C apply(D t) {
    try {
       return (C) handle.invoke(t);
    } catch (Throwable e) {
      ....
    }
  }


vs using MethodHandleProxies.asInterfaceInstance() ?

I would really appreciate your insights.

Thanks,

-Zhengyu








From: Zhengyu Gu <zhengyu.gu at servicenow.com>
Date: Wednesday, May 29, 2024 at 8:28?PM
To: Chen Liang <liangchenblue at gmail.com>
Cc: core-libs-dev at openjdk.org <core-libs-dev at openjdk.org>
Subject: Re: Question on Lambda function
Hi Chen,

What is your usage pattern of these single-abstract-method implementations? Since it sounds like you are
creating a lot of them, are you storing them in collections?

Yes, we do have such usage patterns, e.g. stores methods as Function in hash table as handlers, etc.


If you are keeping a lot of them in collection (say, as event handlers), you may try to use `MethodHandleProxies.asInterfaceInstance` as a temporary workaround on JDK 22 and higher (older version uses Proxy, which has horrible invocation performance).

Thanks for the suggestion. We are currently at 17, I will investigate the library.


Best,

-Zhengyu


If you are on older versions from 15 to 21, unfortunately you might have to write a hidden class for the same purpose or use an existing library. One library that might be useful is https://github.com/LanternPowered/Lmbda that effectively generates unloadable hidden classes, but its 3.x builds are not maven central so you have to build yourself.

- Chen

On Wed, May 29, 2024 at 3:35?PM Zhengyu Gu <zhengyu.gu at servicenow.com<mailto:zhengyu.gu at servicenow.com>> wrote:
Hi Chen,

Thanks for the insights.

We did refactor our code to avoid using LambdaMetaFactory,metafactory() directly.

With increasing use of Lambdas, in our applications and libraries, the metaspace impact becomes a concern. If current implementation (not able to unload unused Lambda classes) here to stay, we must come up with a coding guideline to avoid excessive creation of Lambda classes,  any pointers or suggestions would be greatly appreciated.

Best,

-Zhengyu

From: Chen Liang <liangchenblue at gmail.com<mailto:liangchenblue at gmail.com>>
Date: Wednesday, May 29, 2024 at 2:43?PM
To: Zhengyu Gu <zhengyu.gu at servicenow.com<mailto:zhengyu.gu at servicenow.com>>
Cc: core-libs-dev at openjdk.org<mailto:core-libs-dev at openjdk.org> <core-libs-dev at openjdk.org<mailto:core-libs-dev at openjdk.org>>
Subject: Re: Question on Lambda function
[External Email]

________________________________
Hi Gu,
CallSite is specific to each invokedynamic instruction instead of each InvokeDynamic constant pool entry: https://docs.oracle.com/javase/specs/jvms/se22/html/jvms-6.html#jvms-6.5.invokedynamic<https://docs.oracle.com/javase/specs/jvms/se22/html/jvms-6.html#jvms-6.5.invokedynamic>
And the linking is done by MethodHandleNatives.linkCallSite if you want to follow the Java implementation code.
For why the lambda in the loop is constant, it's a feature from InnerClassLambdaMetafactory: https://github.com/openjdk/jdk/blob/c8eea59f508158075382079316cf0990116ff98e/src/java.base/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java#L236
When the lambda is non-capturing, the bootstrap method LambdaMetafactory.metafactory will eagerly create a singleton instance and return this singleton in the indy instruction.

Also, your metaspace pressure might be caused by the fact that Lambda classes (not instances) are no longer eagerly unloaded; see https://github.com/openjdk/jdk/pull/12493 and https://bugs.openjdk.org/browse/JDK-8302154<https://bugs.openjdk.org/browse/JDK-8302154>. You are recommended to create your own facility to create hidden classes in Java 17 instead of continue to use LambdaMetafactory explicitly in code.

Regards,
Chen Liang

On Wed, May 29, 2024 at 12:53?PM Zhengyu Gu <zhengyu.gu at servicenow.com<mailto:zhengyu.gu at servicenow.com>> wrote:
Hello Lambda experts,

Since we upgraded JDK from 11 to 17, we?re experiencing metaspace pressure, largely due to Lambda class implementation changes.

There?s a scenario (see attached test case),  that is especially puzzled me, hopefully, you can share some insights.

In this test case, there is only one Lambda class is created inside the loop, but each one for the same functions outside loop.

Example output:

0: Func =  LambdaFunc$$Lambda/0x00001f80000c4a20 at 4de8b406
testMethod() called
1: Func =  LambdaFunc$$Lambda/0x00001f80000c4a20 at 4de8b406
testMethod() called
2: Func =  LambdaFunc$$Lambda/0x00001f80000c4a20 at 4de8b406
testMethod() called
3: Func =  LambdaFunc$$Lambda/0x00001f80000c4a20 at 4de8b406
testMethod() called
4: Func =  LambdaFunc$$Lambda/0x00001f80000c4a20 at 4de8b406
testMethod() called

?.

Outside loop1, Func =  LambdaFunc$$Lambda/0x00001f80000c4c58 at 402f32ff
testMethod() called
Outside loop2 Func = LambdaFunc$$Lambda/0x00001f80000d1000 at 5ae9a829
testMethod() called
Outside loop3 Func = LambdaFunc$$Lambda/0x00001f80000d1238 at 548b7f67
testMethod() called

And jcmd also confirmed there were 4 Lambda classes created:

  49: CLD 0x000060000134cb50: "app" instance of jdk.internal.loader.ClassLoaders$AppClassLoader
      Loaded classes:
         1:    LambdaFunc$$Lambda/0x00001f80000d1238
         2:    LambdaFunc$$Lambda/0x00001f80000d1000
         3:    LambdaFunc$$Lambda/0x00001f80000c4c58
         4:    LambdaFunc$$Lambda/0x00001f80000c4a20
         5:    LambdaFunc

Looking into bytecode, all four call sites have the same invokedynamic bytecode (invokedynamic #7,  0              // InvokeDynamic #0:run:()Ljava/lang/Runnable; ) and the first invokedynamic bytecode is inside the loop.

But when I ran the program with -XX:+TraceBytecodes, it seems that the first invokedynamic was hoisted and result was used in the subsequence loop.

Can anyone explain where this magic happens?  If the magic can apply to the instances outside the loop, so that only one Lambda class is created?


Thank you for your time and expertise,

-Zhengyu



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240531/2bd48989/attachment-0001.htm>

From vklang at openjdk.org  Fri May 31 14:07:09 2024
From: vklang at openjdk.org (Viktor Klang)
Date: Fri, 31 May 2024 14:07:09 GMT
Subject: RFR: 8322732: ForkJoinPool may underutilize cores in async mode
 [v17]
In-Reply-To: <IOco_UwtcYWKCrMyfSpHdFxCLEVaQ8Ktqsw94Y4faoc=.45eb6420-1be9-44e3-b46a-8a49f82082d9@github.com>
References: <xRyDMAsSZ7obqpr3Aoc5qrHqILeJMxFVCeiRdctMI3U=.d5d3cd56-32eb-4431-ac01-081822fc86c6@github.com>
 <IOco_UwtcYWKCrMyfSpHdFxCLEVaQ8Ktqsw94Y4faoc=.45eb6420-1be9-44e3-b46a-8a49f82082d9@github.com>
Message-ID: <ycGQD3QzzgLrS2zztyVMSEPPcbF1Oht-OicGwUU55RQ=.9af7f61d-80aa-4cce-bdc7-2ff9427dc111@github.com>

On Fri, 31 May 2024 13:18:33 GMT, Doug Lea <dl at openjdk.org> wrote:

>> This set of changes address causes of poor utilization with small numbers of cores due to overly aggressive contention avoidance. A number of further adjustments were needed to still avoid most contention effects in deployments with large numbers of cores
>
> Doug Lea has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reconcile changes

src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 2024:

> 2022:                                 }
> 2023:                                 if (pb == (pb = b))       // base unchanged
> 2024:                                     Thread.onSpinWait();

@DougLea Doesn't this mean that we'll always onSpinWait at least once here (since pb is initialized to -1 and not written until this check)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19131#discussion_r1622475121

From vklang at openjdk.org  Fri May 31 14:11:05 2024
From: vklang at openjdk.org (Viktor Klang)
Date: Fri, 31 May 2024 14:11:05 GMT
Subject: RFR: 8322732: ForkJoinPool may underutilize cores in async mode
 [v17]
In-Reply-To: <IOco_UwtcYWKCrMyfSpHdFxCLEVaQ8Ktqsw94Y4faoc=.45eb6420-1be9-44e3-b46a-8a49f82082d9@github.com>
References: <xRyDMAsSZ7obqpr3Aoc5qrHqILeJMxFVCeiRdctMI3U=.d5d3cd56-32eb-4431-ac01-081822fc86c6@github.com>
 <IOco_UwtcYWKCrMyfSpHdFxCLEVaQ8Ktqsw94Y4faoc=.45eb6420-1be9-44e3-b46a-8a49f82082d9@github.com>
Message-ID: <a6I9kB4B6wTo1-yyPDYQp65yOSaRGQC-DZeYsKxEcVQ=.bc8a3fab-3893-489f-9788-abc5b18c40bd@github.com>

On Fri, 31 May 2024 13:18:33 GMT, Doug Lea <dl at openjdk.org> wrote:

>> This set of changes address causes of poor utilization with small numbers of cores due to overly aggressive contention avoidance. A number of further adjustments were needed to still avoid most contention effects in deployments with large numbers of cores
>
> Doug Lea has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reconcile changes

src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 2075:

> 2073:             }
> 2074:             if (p != phase &&                    // check quiescent termination
> 2075:                 ((runState & SHUTDOWN) == 0L || quiescent() <= 0)) {

@DougLea `runState` is a volatile, so this change implies a slight difference in memory effects from the `qc` check, I presume this is intentional? ?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19131#discussion_r1622482495

From liangchenblue at gmail.com  Fri May 31 14:19:16 2024
From: liangchenblue at gmail.com (Chen Liang)
Date: Fri, 31 May 2024 09:19:16 -0500
Subject: Question on Lambda function
In-Reply-To: <LV8PR08MB9554A2E4F28653234C93B058F0FC2@LV8PR08MB9554.namprd08.prod.outlook.com>
References: <LV8PR08MB955444A8983A6E579694DFC7F0F22@LV8PR08MB9554.namprd08.prod.outlook.com>
 <LV8PR08MB955466D6C9CCE80D1F4E48F4F0F22@LV8PR08MB9554.namprd08.prod.outlook.com>
 <CABe8uE3vLVzCH9=nj1wrKSS8nOT-nDJTgRW0M4=2bgrnGxhQog@mail.gmail.com>
 <LV8PR08MB95549FE12A28843BB4ED020AF0F22@LV8PR08MB9554.namprd08.prod.outlook.com>
 <CABe8uE3gfmbeDGb6TVF3Fe=yM4np8OJTWQnEybkn5h7gLBuobw@mail.gmail.com>
 <LV8PR08MB955417E4E6ED6C9CBF7ACB3DF0F32@LV8PR08MB9554.namprd08.prod.outlook.com>
 <LV8PR08MB9554A2E4F28653234C93B058F0FC2@LV8PR08MB9554.namprd08.prod.outlook.com>
Message-ID: <CABe8uE23CmLtMZqnxg+WTBB9pC_4OhaVQ_oQVJ+JwZrM7woPqA@mail.gmail.com>

Hi Zhengyu,
This implementation is actually quite good in terms of performance and
cost. One improvement you can have is to replace the `invoke`
with `invokeExact` (and remember to call MethodHandle.asType() before
passing into your anonymous class).

Unfortunately, it will be somewhat slow due to lack of constant folding, as
this handle is not stored in a static final but just an instance final
field (without -XX:+TrustFinalNonStaticFields VM flag;
https://shipilev.net/jvm/anatomy-quarks/17-trust-nonstatic-final-fields/).
Therefore, it will be slower than Java 22 MethodHandleProxies (MHP), which
uses hidden classes that are automatically trusted.

Your simple implementation is already better than the existing
MethodHandleProxies (at least before 22). MHP uses Proxy, which needs to go
through InvocationHandler so it had an extra layer of slowness.

Feel free to ask if you have any questions.

Regards,
Chen

On Fri, May 31, 2024 at 9:03?AM Zhengyu Gu <zhengyu.gu at servicenow.com>
wrote:

> Hi Chen,
>
>
>
> Do you see any pros and cons of wrapping a MethodHandle, e.g.
>
>
>
> new Function<D, C>() {
>
>   @Override
>
>   public C apply(D t) {
>
>     try {
>
>        return (C) handle.invoke(t);
>
>     } catch (Throwable e) {
>
>       ....
>
>     }
>
>   }
>
>
>
>
>
> vs using MethodHandleProxies.asInterfaceInstance() ?
>
>
>
> I would really appreciate your insights.
>
>
>
> Thanks,
>
>
>
> -Zhengyu
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> *From: *Zhengyu Gu <zhengyu.gu at servicenow.com>
> *Date: *Wednesday, May 29, 2024 at 8:28?PM
> *To: *Chen Liang <liangchenblue at gmail.com>
> *Cc: *core-libs-dev at openjdk.org <core-libs-dev at openjdk.org>
> *Subject: *Re: Question on Lambda function
>
> Hi Chen,
>
>
>
> What is your usage pattern of these
> single-abstract-method implementations? Since it sounds like you are
>
> creating a lot of them, are you storing them in collections?
>
>
>
> Yes, we do have such usage patterns, e.g. stores methods as Function in
> hash table as handlers, etc.
>
>
>
>
>
> If you are keeping a lot of them in collection (say, as event handlers),
> you may try to use `MethodHandleProxies.asInterfaceInstance` as a temporary
> workaround on JDK 22 and higher (older version uses Proxy, which has
> horrible invocation performance).
>
>
>
> Thanks for the suggestion. We are currently at 17, I will investigate the
> library.
>
>
>
>
>
> Best,
>
>
>
> -Zhengyu
>
>
>
>
>
> If you are on older versions from 15 to 21, unfortunately you might have
> to write a hidden class for the same purpose or use an existing library.
> One library that might be useful is
> https://github.com/LanternPowered/Lmbda that effectively generates
> unloadable hidden classes, but its 3.x builds are not maven central so you
> have to build yourself.
>
>
>
> - Chen
>
>
>
> On Wed, May 29, 2024 at 3:35?PM Zhengyu Gu <zhengyu.gu at servicenow.com>
> wrote:
>
> Hi Chen,
>
>
>
> Thanks for the insights.
>
>
>
> We did refactor our code to avoid using LambdaMetaFactory,metafactory()
> directly.
>
>
>
> With increasing use of Lambdas, in our applications and libraries, the
> metaspace impact becomes a concern. If current implementation (not able to
> unload unused Lambda classes) here to stay, we must come up with a coding
> guideline to avoid excessive creation of Lambda classes,  any pointers or
> suggestions would be greatly appreciated.
>
>
>
> Best,
>
>
>
> -Zhengyu
>
>
>
> *From: *Chen Liang <liangchenblue at gmail.com>
> *Date: *Wednesday, May 29, 2024 at 2:43?PM
> *To: *Zhengyu Gu <zhengyu.gu at servicenow.com>
> *Cc: *core-libs-dev at openjdk.org <core-libs-dev at openjdk.org>
> *Subject: *Re: Question on Lambda function
> *[External Email]*
>
>
> ------------------------------
>
> Hi Gu,
>
> CallSite is specific to each invokedynamic instruction instead of each
> InvokeDynamic constant pool entry:
> https://docs.oracle.com/javase/specs/jvms/se22/html/jvms-6.html#jvms-6.5.invokedynamic
>
> And the linking is done by MethodHandleNatives.linkCallSite if you want to
> follow the Java implementation code.
>
> For why the lambda in the loop is constant, it's a feature from
> InnerClassLambdaMetafactory:
> https://github.com/openjdk/jdk/blob/c8eea59f508158075382079316cf0990116ff98e/src/java.base/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java#L236
>
> When the lambda is non-capturing, the bootstrap method
> LambdaMetafactory.metafactory will eagerly create a singleton instance and
> return this singleton in the indy instruction.
>
>
>
> Also, your metaspace pressure might be caused by the fact that Lambda
> classes (not instances) are no longer eagerly unloaded; see
> https://github.com/openjdk/jdk/pull/12493 and
> https://bugs.openjdk.org/browse/JDK-8302154. You are recommended to
> create your own facility to create hidden classes in Java 17 instead of
> continue to use LambdaMetafactory explicitly in code.
>
>
>
> Regards,
>
> Chen Liang
>
>
>
> On Wed, May 29, 2024 at 12:53?PM Zhengyu Gu <zhengyu.gu at servicenow.com>
> wrote:
>
> Hello Lambda experts,
>
>
>
> Since we upgraded JDK from 11 to 17, we?re experiencing metaspace
> pressure, largely due to Lambda class implementation changes.
>
>
>
> There?s a scenario (see attached test case),  that is especially puzzled
> me, hopefully, you can share some insights.
>
>
>
> In this test case, there is only one Lambda class is created inside the
> loop, but each one for the same functions outside loop.
>
>
>
> Example output:
>
>
>
> 0: Func =  LambdaFunc$$Lambda/0x00001f80000c4a20 at 4de8b406
>
> testMethod() called
>
> 1: Func =  LambdaFunc$$Lambda/0x00001f80000c4a20 at 4de8b406
>
> testMethod() called
>
> 2: Func =  LambdaFunc$$Lambda/0x00001f80000c4a20 at 4de8b406
>
> testMethod() called
>
> 3: Func =  LambdaFunc$$Lambda/0x00001f80000c4a20 at 4de8b406
>
> testMethod() called
>
> 4: Func =  LambdaFunc$$Lambda/0x00001f80000c4a20 at 4de8b406
>
> testMethod() called
>
>
>
> ?.
>
>
>
> Outside loop1, Func =  LambdaFunc$$Lambda/0x00001f80000c4c58 at 402f32ff
>
> testMethod() called
>
> Outside loop2 Func = LambdaFunc$$Lambda/0x00001f80000d1000 at 5ae9a829
>
> testMethod() called
>
> Outside loop3 Func = LambdaFunc$$Lambda/0x00001f80000d1238 at 548b7f67
>
> testMethod() called
>
>
>
> And jcmd also confirmed there were 4 Lambda classes created:
>
>
>
>   49: CLD 0x000060000134cb50: "app" instance of
> jdk.internal.loader.ClassLoaders$AppClassLoader
>
>       Loaded classes:
>
>          1:    LambdaFunc$$Lambda/0x00001f80000d1238
>
>          2:    LambdaFunc$$Lambda/0x00001f80000d1000
>
>          3:    LambdaFunc$$Lambda/0x00001f80000c4c58
>
>          4:    LambdaFunc$$Lambda/0x00001f80000c4a20
>
>          5:    LambdaFunc
>
>
>
> Looking into bytecode, all four call sites have the same invokedynamic
> bytecode (invokedynamic #7,  0              // InvokeDynamic
> #0:run:()Ljava/lang/Runnable; ) and the first invokedynamic bytecode is
> inside the loop.
>
>
>
> But when I ran the program with -XX:+TraceBytecodes, it seems that the
> first invokedynamic was hoisted and result was used in the subsequence loop.
>
>
>
> Can anyone explain where this magic happens?  If the magic can apply to
> the instances outside the loop, so that only one Lambda class is created?
>
>
>
>
>
> Thank you for your time and expertise,
>
>
>
> -Zhengyu
>
>
>
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240531/9faa57b2/attachment-0001.htm>

From dl at openjdk.org  Fri May 31 14:28:07 2024
From: dl at openjdk.org (Doug Lea)
Date: Fri, 31 May 2024 14:28:07 GMT
Subject: RFR: 8322732: ForkJoinPool may underutilize cores in async mode
 [v17]
In-Reply-To: <ycGQD3QzzgLrS2zztyVMSEPPcbF1Oht-OicGwUU55RQ=.9af7f61d-80aa-4cce-bdc7-2ff9427dc111@github.com>
References: <xRyDMAsSZ7obqpr3Aoc5qrHqILeJMxFVCeiRdctMI3U=.d5d3cd56-32eb-4431-ac01-081822fc86c6@github.com>
 <IOco_UwtcYWKCrMyfSpHdFxCLEVaQ8Ktqsw94Y4faoc=.45eb6420-1be9-44e3-b46a-8a49f82082d9@github.com>
 <ycGQD3QzzgLrS2zztyVMSEPPcbF1Oht-OicGwUU55RQ=.9af7f61d-80aa-4cce-bdc7-2ff9427dc111@github.com>
Message-ID: <OWTn2TGSJ5p96JabDkov17K5ijuzRUmq4D6uQ9phHWg=.42047e4a-3b43-47e1-939c-181bb0fd5512@github.com>

On Fri, 31 May 2024 14:04:50 GMT, Viktor Klang <vklang at openjdk.org> wrote:

>> Doug Lea has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Reconcile changes
>
> src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 2024:
> 
>> 2022:                                 }
>> 2023:                                 if (pb == (pb = b))       // base unchanged
>> 2024:                                     Thread.onSpinWait();
> 
> @DougLea Doesn't this mean that we'll always onSpinWait at least once here (since pb is initialized to -1 and not written until this check)

No, almost the opposite: it only spinWaits if base is apparently stuck, except (harmlessly) every 4B encounters when it happens to be -1. (The value -1 works best here since base starts at 0 and is simpler than other ways of checking for stalls.)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19131#discussion_r1622505491

From dl at openjdk.org  Fri May 31 14:32:06 2024
From: dl at openjdk.org (Doug Lea)
Date: Fri, 31 May 2024 14:32:06 GMT
Subject: RFR: 8322732: ForkJoinPool may underutilize cores in async mode
 [v17]
In-Reply-To: <a6I9kB4B6wTo1-yyPDYQp65yOSaRGQC-DZeYsKxEcVQ=.bc8a3fab-3893-489f-9788-abc5b18c40bd@github.com>
References: <xRyDMAsSZ7obqpr3Aoc5qrHqILeJMxFVCeiRdctMI3U=.d5d3cd56-32eb-4431-ac01-081822fc86c6@github.com>
 <IOco_UwtcYWKCrMyfSpHdFxCLEVaQ8Ktqsw94Y4faoc=.45eb6420-1be9-44e3-b46a-8a49f82082d9@github.com>
 <a6I9kB4B6wTo1-yyPDYQp65yOSaRGQC-DZeYsKxEcVQ=.bc8a3fab-3893-489f-9788-abc5b18c40bd@github.com>
Message-ID: <2tyvehHEkmGMw08so8XejloH7sBkMru1Uydwo-JogaA=.f6dc7a7f-2a9c-4fbe-9599-cff1db8ee3c3@github.com>

On Fri, 31 May 2024 14:08:49 GMT, Viktor Klang <vklang at openjdk.org> wrote:

>> Doug Lea has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Reconcile changes
>
> src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 2075:
> 
>> 2073:             }
>> 2074:             if (p != phase &&                    // check quiescent termination
>> 2075:                 ((runState & SHUTDOWN) == 0L || quiescent() <= 0)) {
> 
> @DougLea `runState` is a volatile, so this change implies a slight difference in memory effects from the `qc` check, I presume this is intentional? ?

Yes. This check makes termination a bit faster because SHUTDOWN is also true if STOP, (as quiescent() will report)  so avoids enough spins and rechecks to be worth the extra read.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19131#discussion_r1622510645

From sgehwolf at openjdk.org  Fri May 31 14:33:02 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Fri, 31 May 2024 14:33:02 GMT
Subject: RFR: 8333301: Remove static builds using --enable-static-build
In-Reply-To: <Hqzi-1Qtf2u8Jxd3kysadUcT5MVPXTNjPSTkxVPO2n0=.43501180-2814-43e9-b952-d40a9f767362@github.com>
References: <Hqzi-1Qtf2u8Jxd3kysadUcT5MVPXTNjPSTkxVPO2n0=.43501180-2814-43e9-b952-d40a9f767362@github.com>
Message-ID: <9T-m8cUCdsKn69wAgHPCIGi-oZ6bF-197kVuORzxdCs=.2929771f-6805-422f-b9b1-4191ee67bb9e@github.com>

On Thu, 30 May 2024 19:14:43 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> The original way of building static libraries in the JDK was to use the configure argument --enable-static-build, which set the value of the make variable STATIC_BUILD. (Note that this is not the same as the source code definition STATIC_BUILD, which will be set by other means as well.)
> 
> This method only ever worked on macOS, and has long since stopped working. It was originally introduced for the Mobile Project, but I've now learn that not even they use it anymore.
> 
> It just adds clutter to the build system, and should be removed.

Looks OK to me.

-------------

Marked as reviewed by sgehwolf (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19487#pullrequestreview-2091001402

From szaldana at openjdk.org  Fri May 31 14:37:06 2024
From: szaldana at openjdk.org (Sonia Zaldana Calles)
Date: Fri, 31 May 2024 14:37:06 GMT
Subject: RFR: 8329581: Java launcher no longer prints a stack trace [v10]
In-Reply-To: <nFQS3JDegumTJOWSla6qGad04vc7PP7W3ZZ483XQuqs=.d28be017-00a0-44e0-9eee-bd70d56498e8@github.com>
References: <Z0pDMIc_XvZhcZdeFsIQUlqI17q5ybj0BnQ9Kl3jwxg=.8f981c46-a8a3-4520-a6e3-79ee7fce0253@github.com>
 <nFQS3JDegumTJOWSla6qGad04vc7PP7W3ZZ483XQuqs=.d28be017-00a0-44e0-9eee-bd70d56498e8@github.com>
Message-ID: <-UOwxqkVlfuaUcyTRnAWx76pUzUHyHV-oBUC4HBP8HA=.df291aa8-2c4e-4771-a68a-a31b91ae8d8b@github.com>

On Thu, 9 May 2024 19:52:12 GMT, Sonia Zaldana Calles <szaldana at openjdk.org> wrote:

>> Hi folks, 
>> 
>> This PR aims to fix [JDK-8329581](https://bugs.openjdk.org/browse/JDK-8329581). 
>> 
>> I think the regression got introduced in [JDK-8315458](https://bugs.openjdk.org/browse/JDK-8315458). 
>> 
>> In the issue linked above, [LauncherHelper#getMainType](https://github.com/openjdk/jdk/pull/16461/files#diff-108a3a3e3c2d108c8c7f19ea498f641413b7c9239ecd2975a6c27d904c2ba226) got removed to simplify launcher code.
>> 
>> Previously, we used ```getMainType``` to do the appropriate main method invocation in ```JavaMain```. However, we currently attempt to do all types of main method invocations at the same time [here](https://github.com/openjdk/jdk/blob/master/src/java.base/share/native/libjli/java.c#L623). 
>> 
>> Note how all of these invocations clear the exception reported with [CHECK_EXCEPTION_FAIL](https://github.com/openjdk/jdk/blob/140f56718bbbfc31bb0c39255c68568fad285a1f/src/java.base/share/native/libjli/java.c#L390). 
>> 
>> Therefore, if a legitimate exception comes up during one of these invocations, it does not get reported. 
>> 
>> I propose reintroducing ```LauncherHelper#getMainType``` but I'm looking forward to your suggestions. 
>> 
>> Cheers, 
>> Sonia
>
> Sonia Zaldana Calles has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Decreasing diff size addressing unnecessary changes

Hi all,  

I think there's some consensus that we need some follow up cleanup issues for the JNI spec, renaming constants, fixing return codes, etc. 

Seeing how that grows the scope of the issue quite a bit, I'd like to push this patch and track the other issues brought up separately. 

If there are no objections about the current state, I'd like to integrate some time next week. Let me know your thoughts.

cc: @jaikiran, @AlanBateman

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18786#issuecomment-2142383991

From vklang at openjdk.org  Fri May 31 14:38:05 2024
From: vklang at openjdk.org (Viktor Klang)
Date: Fri, 31 May 2024 14:38:05 GMT
Subject: RFR: 8322732: ForkJoinPool may underutilize cores in async mode
 [v17]
In-Reply-To: <OWTn2TGSJ5p96JabDkov17K5ijuzRUmq4D6uQ9phHWg=.42047e4a-3b43-47e1-939c-181bb0fd5512@github.com>
References: <xRyDMAsSZ7obqpr3Aoc5qrHqILeJMxFVCeiRdctMI3U=.d5d3cd56-32eb-4431-ac01-081822fc86c6@github.com>
 <IOco_UwtcYWKCrMyfSpHdFxCLEVaQ8Ktqsw94Y4faoc=.45eb6420-1be9-44e3-b46a-8a49f82082d9@github.com>
 <ycGQD3QzzgLrS2zztyVMSEPPcbF1Oht-OicGwUU55RQ=.9af7f61d-80aa-4cce-bdc7-2ff9427dc111@github.com>
 <OWTn2TGSJ5p96JabDkov17K5ijuzRUmq4D6uQ9phHWg=.42047e4a-3b43-47e1-939c-181bb0fd5512@github.com>
Message-ID: <pv0R4_qpiTh6yvosUNtMFUvUJ9-popunG-PpJ8yK6a8=.39529421-e988-4c23-abec-68d81d4cdf38@github.com>

On Fri, 31 May 2024 14:24:56 GMT, Doug Lea <dl at openjdk.org> wrote:

>> src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 2024:
>> 
>>> 2022:                                 }
>>> 2023:                                 if (pb == (pb = b))       // base unchanged
>>> 2024:                                     Thread.onSpinWait();
>> 
>> @DougLea Doesn't this mean that we'll always onSpinWait at least once here (since pb is initialized to -1 and not written until this check)
>
> No, almost the opposite: it only spinWaits if base is apparently stuck, except (harmlessly) every 4B encounters when it happens to be -1. (The value -1 works best here since base starts at 0 and is simpler than other ways of checking for stalls.)

@DougLea You're right, I've seen too many of these consistency-checks to have my brain read "!=" automatically. Sorry for the noise :)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19131#discussion_r1622520678

From dfuchs at openjdk.org  Fri May 31 15:01:11 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 31 May 2024 15:01:11 GMT
Subject: RFR: 8333270: HandlersOnComplexResetUpdate and HandlersOnComplexUpdate
 tests fail with "Unexpected reference" if timeoutFactor is less than 1/3
Message-ID: <sQVFYehjzZ3qdbC1LutUCI_Igxa4IopKRdOBKnZUA4Q=.96a95231-ba65-4387-8351-4c4a2f119fe6@github.com>

HandlersOnComplexResetUpdate and HandlersOnComplexUpdate tests verify that loggers are GC'ed (or not GC'ed) after a reset or an update. For that they poll a ReferenceQueue in a loop. The number of iteration is adjusted according to the jtreg timeout factor. However, the logic in the test did not expect that the timeout might be less than 1.

This fix does two things:

1. fix the adjustCount logic - so that the number of iteration can only be increased
2. use remove(timeout) instead of poll() in order to minimize the waiting time.

-------------

Commit messages:
 - 8333270

Changes: https://git.openjdk.org/jdk/pull/19503/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19503&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8333270
  Stats: 11 lines in 2 files changed: 0 ins; 2 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/19503.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19503/head:pull/19503

PR: https://git.openjdk.org/jdk/pull/19503

From zhengyu.gu at servicenow.com  Fri May 31 15:18:35 2024
From: zhengyu.gu at servicenow.com (Zhengyu Gu)
Date: Fri, 31 May 2024 15:18:35 +0000
Subject: Question on Lambda function
In-Reply-To: <CABe8uE23CmLtMZqnxg+WTBB9pC_4OhaVQ_oQVJ+JwZrM7woPqA@mail.gmail.com>
References: <LV8PR08MB955444A8983A6E579694DFC7F0F22@LV8PR08MB9554.namprd08.prod.outlook.com>
 <LV8PR08MB955466D6C9CCE80D1F4E48F4F0F22@LV8PR08MB9554.namprd08.prod.outlook.com>
 <CABe8uE3vLVzCH9=nj1wrKSS8nOT-nDJTgRW0M4=2bgrnGxhQog@mail.gmail.com>
 <LV8PR08MB95549FE12A28843BB4ED020AF0F22@LV8PR08MB9554.namprd08.prod.outlook.com>
 <CABe8uE3gfmbeDGb6TVF3Fe=yM4np8OJTWQnEybkn5h7gLBuobw@mail.gmail.com>
 <LV8PR08MB955417E4E6ED6C9CBF7ACB3DF0F32@LV8PR08MB9554.namprd08.prod.outlook.com>
 <LV8PR08MB9554A2E4F28653234C93B058F0FC2@LV8PR08MB9554.namprd08.prod.outlook.com>
 <CABe8uE23CmLtMZqnxg+WTBB9pC_4OhaVQ_oQVJ+JwZrM7woPqA@mail.gmail.com>
Message-ID: <LV8PR08MB9554ABAF5CCE63EA85A02504F0FC2@LV8PR08MB9554.namprd08.prod.outlook.com>

Thanks a lot, Chen

-Zhengyu


From: Chen Liang <liangchenblue at gmail.com>
Date: Friday, May 31, 2024 at 10:19?AM
To: Zhengyu Gu <zhengyu.gu at servicenow.com>
Cc: core-libs-dev at openjdk.org <core-libs-dev at openjdk.org>
Subject: Re: Question on Lambda function
[External Email]

________________________________
Hi Zhengyu,
This implementation is actually quite good in terms of performance and cost. One improvement you can have is to replace the `invoke` with `invokeExact` (and remember to call MethodHandle.asType() before passing into your anonymous class).

Unfortunately, it will be somewhat slow due to lack of constant folding, as this handle is not stored in a static final but just an instance final field (without -XX:+TrustFinalNonStaticFields VM flag; https://shipilev.net/jvm/anatomy-quarks/17-trust-nonstatic-final-fields/<https://shipilev.net/jvm/anatomy-quarks/17-trust-nonstatic-final-fields>). Therefore, it will be slower than Java 22 MethodHandleProxies (MHP), which uses hidden classes that are automatically trusted.

Your simple implementation is already better than the existing MethodHandleProxies (at least before 22). MHP uses Proxy, which needs to go through InvocationHandler so it had an extra layer of slowness.

Feel free to ask if you have any questions.

Regards,
Chen

On Fri, May 31, 2024 at 9:03?AM Zhengyu Gu <zhengyu.gu at servicenow.com<mailto:zhengyu.gu at servicenow.com>> wrote:
Hi Chen,

Do you see any pros and cons of wrapping a MethodHandle, e.g.

new Function<D, C>() {
  @Override
  public C apply(D t) {
    try {
       return (C) handle.invoke(t);
    } catch (Throwable e) {
      ....
    }
  }


vs using MethodHandleProxies.asInterfaceInstance() ?

I would really appreciate your insights.

Thanks,

-Zhengyu








From: Zhengyu Gu <zhengyu.gu at servicenow.com<mailto:zhengyu.gu at servicenow.com>>
Date: Wednesday, May 29, 2024 at 8:28?PM
To: Chen Liang <liangchenblue at gmail.com<mailto:liangchenblue at gmail.com>>
Cc: core-libs-dev at openjdk.org<mailto:core-libs-dev at openjdk.org> <core-libs-dev at openjdk.org<mailto:core-libs-dev at openjdk.org>>
Subject: Re: Question on Lambda function
Hi Chen,

What is your usage pattern of these single-abstract-method implementations? Since it sounds like you are
creating a lot of them, are you storing them in collections?

Yes, we do have such usage patterns, e.g. stores methods as Function in hash table as handlers, etc.


If you are keeping a lot of them in collection (say, as event handlers), you may try to use `MethodHandleProxies.asInterfaceInstance` as a temporary workaround on JDK 22 and higher (older version uses Proxy, which has horrible invocation performance).

Thanks for the suggestion. We are currently at 17, I will investigate the library.


Best,

-Zhengyu


If you are on older versions from 15 to 21, unfortunately you might have to write a hidden class for the same purpose or use an existing library. One library that might be useful is https://github.com/LanternPowered/Lmbda that effectively generates unloadable hidden classes, but its 3.x builds are not maven central so you have to build yourself.

- Chen

On Wed, May 29, 2024 at 3:35?PM Zhengyu Gu <zhengyu.gu at servicenow.com<mailto:zhengyu.gu at servicenow.com>> wrote:
Hi Chen,

Thanks for the insights.

We did refactor our code to avoid using LambdaMetaFactory,metafactory() directly.

With increasing use of Lambdas, in our applications and libraries, the metaspace impact becomes a concern. If current implementation (not able to unload unused Lambda classes) here to stay, we must come up with a coding guideline to avoid excessive creation of Lambda classes,  any pointers or suggestions would be greatly appreciated.

Best,

-Zhengyu

From: Chen Liang <liangchenblue at gmail.com<mailto:liangchenblue at gmail.com>>
Date: Wednesday, May 29, 2024 at 2:43?PM
To: Zhengyu Gu <zhengyu.gu at servicenow.com<mailto:zhengyu.gu at servicenow.com>>
Cc: core-libs-dev at openjdk.org<mailto:core-libs-dev at openjdk.org> <core-libs-dev at openjdk.org<mailto:core-libs-dev at openjdk.org>>
Subject: Re: Question on Lambda function
[External Email]

________________________________
Hi Gu,
CallSite is specific to each invokedynamic instruction instead of each InvokeDynamic constant pool entry: https://docs.oracle.com/javase/specs/jvms/se22/html/jvms-6.html#jvms-6.5.invokedynamic<https://docs.oracle.com/javase/specs/jvms/se22/html/jvms-6.html#jvms-6.5.invokedynamic>
And the linking is done by MethodHandleNatives.linkCallSite if you want to follow the Java implementation code.
For why the lambda in the loop is constant, it's a feature from InnerClassLambdaMetafactory: https://github.com/openjdk/jdk/blob/c8eea59f508158075382079316cf0990116ff98e/src/java.base/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java#L236
When the lambda is non-capturing, the bootstrap method LambdaMetafactory.metafactory will eagerly create a singleton instance and return this singleton in the indy instruction.

Also, your metaspace pressure might be caused by the fact that Lambda classes (not instances) are no longer eagerly unloaded; see https://github.com/openjdk/jdk/pull/12493 and https://bugs.openjdk.org/browse/JDK-8302154<https://bugs.openjdk.org/browse/JDK-8302154>. You are recommended to create your own facility to create hidden classes in Java 17 instead of continue to use LambdaMetafactory explicitly in code.

Regards,
Chen Liang

On Wed, May 29, 2024 at 12:53?PM Zhengyu Gu <zhengyu.gu at servicenow.com<mailto:zhengyu.gu at servicenow.com>> wrote:
Hello Lambda experts,

Since we upgraded JDK from 11 to 17, we?re experiencing metaspace pressure, largely due to Lambda class implementation changes.

There?s a scenario (see attached test case),  that is especially puzzled me, hopefully, you can share some insights.

In this test case, there is only one Lambda class is created inside the loop, but each one for the same functions outside loop.

Example output:

0: Func =  LambdaFunc$$Lambda/0x00001f80000c4a20 at 4de8b406
testMethod() called
1: Func =  LambdaFunc$$Lambda/0x00001f80000c4a20 at 4de8b406
testMethod() called
2: Func =  LambdaFunc$$Lambda/0x00001f80000c4a20 at 4de8b406
testMethod() called
3: Func =  LambdaFunc$$Lambda/0x00001f80000c4a20 at 4de8b406
testMethod() called
4: Func =  LambdaFunc$$Lambda/0x00001f80000c4a20 at 4de8b406
testMethod() called

?.

Outside loop1, Func =  LambdaFunc$$Lambda/0x00001f80000c4c58 at 402f32ff
testMethod() called
Outside loop2 Func = LambdaFunc$$Lambda/0x00001f80000d1000 at 5ae9a829
testMethod() called
Outside loop3 Func = LambdaFunc$$Lambda/0x00001f80000d1238 at 548b7f67
testMethod() called

And jcmd also confirmed there were 4 Lambda classes created:

  49: CLD 0x000060000134cb50: "app" instance of jdk.internal.loader.ClassLoaders$AppClassLoader
      Loaded classes:
         1:    LambdaFunc$$Lambda/0x00001f80000d1238
         2:    LambdaFunc$$Lambda/0x00001f80000d1000
         3:    LambdaFunc$$Lambda/0x00001f80000c4c58
         4:    LambdaFunc$$Lambda/0x00001f80000c4a20
         5:    LambdaFunc

Looking into bytecode, all four call sites have the same invokedynamic bytecode (invokedynamic #7,  0              // InvokeDynamic #0:run:()Ljava/lang/Runnable; ) and the first invokedynamic bytecode is inside the loop.

But when I ran the program with -XX:+TraceBytecodes, it seems that the first invokedynamic was hoisted and result was used in the subsequence loop.

Can anyone explain where this magic happens?  If the magic can apply to the instances outside the loop, so that only one Lambda class is created?


Thank you for your time and expertise,

-Zhengyu



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240531/02679e3f/attachment-0001.htm>

From lancea at openjdk.org  Fri May 31 15:26:02 2024
From: lancea at openjdk.org (Lance Andersen)
Date: Fri, 31 May 2024 15:26:02 GMT
Subject: RFR: 7022325: TEST_BUG:
 test/java/util/zip/ZipFile/ReadLongZipFileName.java leaks files if it fails
In-Reply-To: <3IbUCEnZFVdQyBOtxtjoqRNfhlJYQVZ6DagF6T9mGgA=.adf1c246-1b8d-4609-bf58-5e381bcd5ae3@github.com>
References: <3IbUCEnZFVdQyBOtxtjoqRNfhlJYQVZ6DagF6T9mGgA=.adf1c246-1b8d-4609-bf58-5e381bcd5ae3@github.com>
Message-ID: <93hVwVb4Xw_7JCsU3TNerJhzVemUXHTNs8iFKqyra-s=.4c01deea-4f1c-40aa-a106-eb8e0f6d2d8d@github.com>

On Fri, 31 May 2024 00:57:18 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this test-only change which updates a couple of places in the test to use `try-with-resource`?
> 
> As noted in https://bugs.openjdk.org/browse/JDK-7022325 this change should prevent leaking of resources in case there's any failure in the test. The test continues to pass with this change.

Hi Jai,

I think the change is fine.  I might suggest that we take the opportunity to convert this test  to use junit  as part of this PR

-------------

Marked as reviewed by lancea (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19492#pullrequestreview-2091120545

From mcimadamore at openjdk.org  Fri May 31 16:18:33 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 31 May 2024 16:18:33 GMT
Subject: RFR: 8333236: Test java/foreign/TestAccessModes.java is timing out
 after passing [v2]
In-Reply-To: <mLVkvSWgzjrvnm1R6MZxjacSbTN0CxdA5f5D3lqDti0=.bb215ff2-8bfd-4ce4-8986-522f0ef1af08@github.com>
References: <mLVkvSWgzjrvnm1R6MZxjacSbTN0CxdA5f5D3lqDti0=.bb215ff2-8bfd-4ce4-8986-522f0ef1af08@github.com>
Message-ID: <8TBY8YjU1O2BM5p9a0oG-REt8-1nvtDx_yC4RVotzLc=.8f383b2d-80e4-43b2-ba44-34ce4e55368c@github.com>

> This PR restores a var handle cache in `Utils::makeSegmentViewVarHandle`. The cache was moved to `ValueLayouts::varHandle` as part of [pull/19251](https://git.openjdk.org/jdk/pull/19251), on the basis that we want to optimize the common case like:
> 
> 
> ValueLayout layout = ...
> layout.varHandle().get(...)
> 
> 
> And that caching more complex var handles didn't seem to add value, given that, for these var handles, the logic in `LayoutPath` needs to adapt the returned var handle anyways.
> 
> But, `TestAccessModes` revealed a different picture - w/o any cache in `Utils` the test end up allocating 8963 var handle instances (instead of just 4), in each of the 4 runs the test includes. While this is admittedly a stress test, it seems nice to restore the level of sharing we had before [pull/19251](https://git.openjdk.org/jdk/pull/19251).

Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:

  Address review comments

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19485/files
  - new: https://git.openjdk.org/jdk/pull/19485/files/b37f9cc9..3b2a3380

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19485&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19485&range=00-01

  Stats: 18 lines in 2 files changed: 14 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/19485.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19485/head:pull/19485

PR: https://git.openjdk.org/jdk/pull/19485

From mcimadamore at openjdk.org  Fri May 31 16:18:33 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 31 May 2024 16:18:33 GMT
Subject: RFR: 8333236: Test java/foreign/TestAccessModes.java is timing out
 after passing [v2]
In-Reply-To: <8TBY8YjU1O2BM5p9a0oG-REt8-1nvtDx_yC4RVotzLc=.8f383b2d-80e4-43b2-ba44-34ce4e55368c@github.com>
References: <mLVkvSWgzjrvnm1R6MZxjacSbTN0CxdA5f5D3lqDti0=.bb215ff2-8bfd-4ce4-8986-522f0ef1af08@github.com>
 <8TBY8YjU1O2BM5p9a0oG-REt8-1nvtDx_yC4RVotzLc=.8f383b2d-80e4-43b2-ba44-34ce4e55368c@github.com>
Message-ID: <ikHcRP-QXREk7zJ4AyfO6uwSwQE_e6SXvcwQciofOqY=.a49b5209-1ab8-4cbd-9f2c-04e275941193@github.com>

On Fri, 31 May 2024 16:15:12 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This PR restores a var handle cache in `Utils::makeSegmentViewVarHandle`. The cache was moved to `ValueLayouts::varHandle` as part of [pull/19251](https://git.openjdk.org/jdk/pull/19251), on the basis that we want to optimize the common case like:
>> 
>> 
>> ValueLayout layout = ...
>> layout.varHandle().get(...)
>> 
>> 
>> And that caching more complex var handles didn't seem to add value, given that, for these var handles, the logic in `LayoutPath` needs to adapt the returned var handle anyways.
>> 
>> But, `TestAccessModes` revealed a different picture - w/o any cache in `Utils` the test end up allocating 8963 var handle instances (instead of just 4), in each of the 4 runs the test includes. While this is admittedly a stress test, it seems nice to restore the level of sharing we had before [pull/19251](https://git.openjdk.org/jdk/pull/19251).
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address review comments

src/java.base/share/classes/jdk/internal/foreign/Utils.java line 106:

> 104:      * @return a raw memory segment var handle.
> 105:      */
> 106:     public static VarHandle makeRawSegmentViewVarHandle(ValueLayout layout) {

Since I was here, I took the opportunity to rename this to include `raw`, to denote that the var handle returned by this method should not be exposed by APIs as is.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19485#discussion_r1622666280

From duke at openjdk.org  Fri May 31 16:21:36 2024
From: duke at openjdk.org (jengebr)
Date: Fri, 31 May 2024 16:21:36 GMT
Subject: RFR: 8332586: Avoid cloning empty arrays in
 java.lang.reflect.{Method,Constructor} [v2]
In-Reply-To: <R5bpPuNj1Q2M6uo6_2d6out53rqb17tpheL1jcBDcXw=.3fe0cb7f-1d37-47b0-b4ac-5b7b3ef01bd4@github.com>
References: <R5bpPuNj1Q2M6uo6_2d6out53rqb17tpheL1jcBDcXw=.3fe0cb7f-1d37-47b0-b4ac-5b7b3ef01bd4@github.com>
Message-ID: <StZrZwoC16F1l4TSvBHuUuMqIEZUua_3hC8DjJss80A=.e76c4812-11ba-4f14-b004-b9575d21959e@github.com>

> Improve `java/lang/reflect/Method.java`  by eliminating needless cloning of Class[0] instances.  This cloning is intended to prevent callers from changing array contents, but smany Methods have zero exceptions or zero parameters, and returning the original `Class[0]` is sufficient.

jengebr has updated the pull request incrementally with one additional commit since the last revision:

  Adding JMH benchmark

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19327/files
  - new: https://git.openjdk.org/jdk/pull/19327/files/3202c8cb..4865dede

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19327&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19327&range=00-01

  Stats: 82 lines in 1 file changed: 82 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/19327.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19327/head:pull/19327

PR: https://git.openjdk.org/jdk/pull/19327

From liach at openjdk.org  Fri May 31 16:21:36 2024
From: liach at openjdk.org (Chen Liang)
Date: Fri, 31 May 2024 16:21:36 GMT
Subject: RFR: 8332586: Avoid cloning empty arrays in
 java.lang.reflect.{Method,Constructor} [v2]
In-Reply-To: <StZrZwoC16F1l4TSvBHuUuMqIEZUua_3hC8DjJss80A=.e76c4812-11ba-4f14-b004-b9575d21959e@github.com>
References: <R5bpPuNj1Q2M6uo6_2d6out53rqb17tpheL1jcBDcXw=.3fe0cb7f-1d37-47b0-b4ac-5b7b3ef01bd4@github.com>
 <StZrZwoC16F1l4TSvBHuUuMqIEZUua_3hC8DjJss80A=.e76c4812-11ba-4f14-b004-b9575d21959e@github.com>
Message-ID: <l3Je73XakyJXZENjz8QhDyi-GF2qxUjsUfOoR6USceo=.f425815f-1c20-4525-b83e-61225ea5355f@github.com>

On Fri, 31 May 2024 16:18:01 GMT, jengebr <duke at openjdk.org> wrote:

>> Improve `java/lang/reflect/Method.java`  by eliminating needless cloning of Class[0] instances.  This cloning is intended to prevent callers from changing array contents, but smany Methods have zero exceptions or zero parameters, and returning the original `Class[0]` is sufficient.
>
> jengebr has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adding JMH benchmark

test/micro/org/openjdk/bench/java/lang/reflect/ExecutableParameterAndExceptionTypesBenchmark.java line 69:

> 67: 
> 68:     @Benchmark
> 69:     public void constructorParametersWithNoExceptions(Blackhole bh) throws Exception {

Wrong name. Maybe rename this to `constructorParametersEmpty` and the exception ones to `constructorExceptionsEmpty`?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19327#discussion_r1622668928

From duke at openjdk.org  Fri May 31 16:21:36 2024
From: duke at openjdk.org (jengebr)
Date: Fri, 31 May 2024 16:21:36 GMT
Subject: RFR: 8332586: Avoid cloning empty arrays in
 java.lang.reflect.{Method,Constructor}
In-Reply-To: <wWyb1JPXNXH8kmEvRxzQYGFRtqsIiGWEBvZsDao42Xg=.36910126-4813-4e50-b985-f2177e4441ed@github.com>
References: <R5bpPuNj1Q2M6uo6_2d6out53rqb17tpheL1jcBDcXw=.3fe0cb7f-1d37-47b0-b4ac-5b7b3ef01bd4@github.com>
 <wWyb1JPXNXH8kmEvRxzQYGFRtqsIiGWEBvZsDao42Xg=.36910126-4813-4e50-b985-f2177e4441ed@github.com>
Message-ID: <rkLoyHwPE2Bj2B3tAOyZUGzuFzmCXZaKgzZFZwbN9rM=.aadd19a8-fe5e-4e46-9af5-ca4e48f7ca26@github.com>

On Wed, 22 May 2024 09:44:18 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Improve `java/lang/reflect/Method.java`  by eliminating needless cloning of Class[0] instances.  This cloning is intended to prevent callers from changing array contents, but smany Methods have zero exceptions or zero parameters, and returning the original `Class[0]` is sufficient.
>
> Please also enable GHA testing: https://github.com/jengebr/jdk/actions. You may need to trigger the test run manually after this, since the PR hook have already missed it. Go to "OpenJDK Sanity Checks" on the left on that page, then select your branch on in the drop-down on the right, and trigger the run.

@shipilev JMH benchmark is added.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19327#issuecomment-2142587755

From pminborg at openjdk.org  Fri May 31 16:29:02 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Fri, 31 May 2024 16:29:02 GMT
Subject: RFR: 8333236: Test java/foreign/TestAccessModes.java is timing out
 after passing [v2]
In-Reply-To: <8TBY8YjU1O2BM5p9a0oG-REt8-1nvtDx_yC4RVotzLc=.8f383b2d-80e4-43b2-ba44-34ce4e55368c@github.com>
References: <mLVkvSWgzjrvnm1R6MZxjacSbTN0CxdA5f5D3lqDti0=.bb215ff2-8bfd-4ce4-8986-522f0ef1af08@github.com>
 <8TBY8YjU1O2BM5p9a0oG-REt8-1nvtDx_yC4RVotzLc=.8f383b2d-80e4-43b2-ba44-34ce4e55368c@github.com>
Message-ID: <mOHW5iislXzALa56FST-_VY8eQKo2YOlCUEFYHw7hFU=.badf68d6-1924-4ef4-9ee9-92e33ac834ff@github.com>

On Fri, 31 May 2024 16:18:33 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This PR restores a var handle cache in `Utils::makeSegmentViewVarHandle`. The cache was moved to `ValueLayouts::varHandle` as part of [pull/19251](https://git.openjdk.org/jdk/pull/19251), on the basis that we want to optimize the common case like:
>> 
>> 
>> ValueLayout layout = ...
>> layout.varHandle().get(...)
>> 
>> 
>> And that caching more complex var handles didn't seem to add value, given that, for these var handles, the logic in `LayoutPath` needs to adapt the returned var handle anyways.
>> 
>> But, `TestAccessModes` revealed a different picture - w/o any cache in `Utils` the test end up allocating 8963 var handle instances (instead of just 4), in each of the 4 runs the test includes. While this is admittedly a stress test, it seems nice to restore the level of sharing we had before [pull/19251](https://git.openjdk.org/jdk/pull/19251).
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address review comments

Would it make sense to add some tests that assert, `VarHandle` objects get cached?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19485#issuecomment-2142604322

From duke at openjdk.org  Fri May 31 16:35:11 2024
From: duke at openjdk.org (Sean Gwizdak)
Date: Fri, 31 May 2024 16:35:11 GMT
Subject: RFR: 8332249: Micro-optimize Method.hashCode
Message-ID: <Qh0DBSlUP_zHtQBgVPTK_tH-a3bvAdLRPGEHbcwaTOA=.e9808239-e01d-4ca7-8c8a-8ce4ee7e4997@github.com>

Improve the speed of Method.hashCode by caching the hashcode on first use. I've seen an application where Method.hashCode is a hot path, and this is a fairly simple speedup. The memory overhead is low. 

This addresses issue [JDK-8332249](https://bugs.openjdk.org/browse/JDK-8332249). 

Before:

Benchmark                         Mode  Cnt  Score   Error  Units
# Intel Skylake
MethodHashCode.benchmarkHashCode  avgt    5  1.843 ? 0.149  ns/op
# Arm Neoverse N1
MethodHashCode.benchmarkHashCode  avgt    5  2.363 ? 0.091  ns/op



After:


Benchmark                         Mode  Cnt  Score   Error  Units
# Intel Skylake
MethodHashCode.benchmarkHashCode  avgt    5  1.121 ? 1.189  ns/op
# Arm Neoverse N1
MethodHashCode.benchmarkHashCode  avgt    5  1.001 ? 0.001  ns/op

-------------

Commit messages:
 - Remove changes to JavaDoc per guidance.
 - Fix whitespace issues pointed by the bot
 - Micro-optimize Method.hashCode

Changes: https://git.openjdk.org/jdk/pull/19433/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19433&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8332249
  Stats: 58 lines in 2 files changed: 57 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/19433.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19433/head:pull/19433

PR: https://git.openjdk.org/jdk/pull/19433

From liach at openjdk.org  Fri May 31 16:35:12 2024
From: liach at openjdk.org (Chen Liang)
Date: Fri, 31 May 2024 16:35:12 GMT
Subject: RFR: 8332249: Micro-optimize Method.hashCode
In-Reply-To: <Qh0DBSlUP_zHtQBgVPTK_tH-a3bvAdLRPGEHbcwaTOA=.e9808239-e01d-4ca7-8c8a-8ce4ee7e4997@github.com>
References: <Qh0DBSlUP_zHtQBgVPTK_tH-a3bvAdLRPGEHbcwaTOA=.e9808239-e01d-4ca7-8c8a-8ce4ee7e4997@github.com>
Message-ID: <68bP4OaEhjeBisrD5wDLvmOBykXE4J_UlxO9BcFSZl8=.455e75dd-1983-4989-92cf-9101c3ff1696@github.com>

On Tue, 28 May 2024 17:25:34 GMT, Sean Gwizdak <duke at openjdk.org> wrote:

> Improve the speed of Method.hashCode by caching the hashcode on first use. I've seen an application where Method.hashCode is a hot path, and this is a fairly simple speedup. The memory overhead is low. 
> 
> This addresses issue [JDK-8332249](https://bugs.openjdk.org/browse/JDK-8332249). 
> 
> Before:
> 
> Benchmark                         Mode  Cnt  Score   Error  Units
> # Intel Skylake
> MethodHashCode.benchmarkHashCode  avgt    5  1.843 ? 0.149  ns/op
> # Arm Neoverse N1
> MethodHashCode.benchmarkHashCode  avgt    5  2.363 ? 0.091  ns/op
> 
> 
> 
> After:
> 
> 
> Benchmark                         Mode  Cnt  Score   Error  Units
> # Intel Skylake
> MethodHashCode.benchmarkHashCode  avgt    5  1.121 ? 1.189  ns/op
> # Arm Neoverse N1
> MethodHashCode.benchmarkHashCode  avgt    5  1.001 ? 0.001  ns/op

Also, have you considered micro-optimize Constructor.hashCode too? Given its similar status to Method.

src/java.base/share/classes/java/lang/reflect/Method.java line 99:

> 97:     private Method              root;
> 98:     // Hash code of this object
> 99:     private int                 hash;

We can declare this field `@Stable`, like the `methodAccessor`.

src/java.base/share/classes/java/lang/reflect/Method.java line 388:

> 386:         int hc = hash;
> 387: 
> 388:         if (hc == 0) {

Should we add an extra field `hashIsZero` like in `String` to avoid repeated computation if the hash is 0?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19433#issuecomment-2137679451
PR Review Comment: https://git.openjdk.org/jdk/pull/19433#discussion_r1618110657
PR Review Comment: https://git.openjdk.org/jdk/pull/19433#discussion_r1618110354

From duke at openjdk.org  Fri May 31 16:35:12 2024
From: duke at openjdk.org (Sean Gwizdak)
Date: Fri, 31 May 2024 16:35:12 GMT
Subject: RFR: 8332249: Micro-optimize Method.hashCode
In-Reply-To: <68bP4OaEhjeBisrD5wDLvmOBykXE4J_UlxO9BcFSZl8=.455e75dd-1983-4989-92cf-9101c3ff1696@github.com>
References: <Qh0DBSlUP_zHtQBgVPTK_tH-a3bvAdLRPGEHbcwaTOA=.e9808239-e01d-4ca7-8c8a-8ce4ee7e4997@github.com>
 <68bP4OaEhjeBisrD5wDLvmOBykXE4J_UlxO9BcFSZl8=.455e75dd-1983-4989-92cf-9101c3ff1696@github.com>
Message-ID: <RmVBj_5UwgheR-GF78Hf-0PcXMnEskhhOJCt5BoSfRc=.e91d44ce-8629-46b8-b26f-ee4017108f87@github.com>

On Wed, 29 May 2024 15:20:56 GMT, Chen Liang <liach at openjdk.org> wrote:

> Also, have you considered micro-optimize Constructor.hashCode too? Given its similar status to Method.

Not at this time. This PR is motivated by observing Method.hashCode as a hotspot in a Spring heavy application when migrating to an ARM based platform. We did not observe Constructor.hashCode to be a hotspot in this application.

> src/java.base/share/classes/java/lang/reflect/Method.java line 99:
> 
>> 97:     private Method              root;
>> 98:     // Hash code of this object
>> 99:     private int                 hash;
> 
> We can declare this field `@Stable`, like the `methodAccessor`.

This was something that I tried and I observed a performance regression on the ARM platform that I was testing. From my understanding, `@Stable` tells the compiler to trust the contents of this field which is only given when the field holder is a known constant. This is generally true for cases like `Enums` but not usually for `Method`. 


Benchmark                         Mode  Cnt  Score   Error  Units
# Intel Skylake
MethodHashCode.benchmarkHashCode  avgt    5  1.113 ? 1.146  ns/op
# Arm Neoverse N1
MethodHashCode.benchmarkHashCode  avgt    5  3.204 ? 0.001  ns/op

> src/java.base/share/classes/java/lang/reflect/Method.java line 388:
> 
>> 386:         int hc = hash;
>> 387: 
>> 388:         if (hc == 0) {
> 
> Should we add an extra field `hashIsZero` like in `String` to avoid repeated computation if the hash is 0?

Unlike with `String`, I don't often see cases where `Method` results in a hashCode of zero, which should be weighed with the overhead of adding in an additional variable. I believe some of the reasoning for handling zero-hashed Strings was about how easy it is to construct hash collisions and feed the JVM with bad Strings from an external actor. I don't believe this is an issue for `Method`.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19433#issuecomment-2137699178
PR Review Comment: https://git.openjdk.org/jdk/pull/19433#discussion_r1619053915
PR Review Comment: https://git.openjdk.org/jdk/pull/19433#discussion_r1619079001

From liach at openjdk.org  Fri May 31 16:35:12 2024
From: liach at openjdk.org (Chen Liang)
Date: Fri, 31 May 2024 16:35:12 GMT
Subject: RFR: 8332249: Micro-optimize Method.hashCode
In-Reply-To: <RmVBj_5UwgheR-GF78Hf-0PcXMnEskhhOJCt5BoSfRc=.e91d44ce-8629-46b8-b26f-ee4017108f87@github.com>
References: <Qh0DBSlUP_zHtQBgVPTK_tH-a3bvAdLRPGEHbcwaTOA=.e9808239-e01d-4ca7-8c8a-8ce4ee7e4997@github.com>
 <68bP4OaEhjeBisrD5wDLvmOBykXE4J_UlxO9BcFSZl8=.455e75dd-1983-4989-92cf-9101c3ff1696@github.com>
 <RmVBj_5UwgheR-GF78Hf-0PcXMnEskhhOJCt5BoSfRc=.e91d44ce-8629-46b8-b26f-ee4017108f87@github.com>
Message-ID: <e2ypna3AumYuZ17RHAjCCvwDINMZLFAFUq9qATiZtAU=.f232b73e-0f01-42ef-85a5-66799a84b62a@github.com>

On Wed, 29 May 2024 15:03:15 GMT, Sean Gwizdak <duke at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/reflect/Method.java line 99:
>> 
>>> 97:     private Method              root;
>>> 98:     // Hash code of this object
>>> 99:     private int                 hash;
>> 
>> We can declare this field `@Stable`, like the `methodAccessor`.
>
> This was something that I tried and I observed a performance regression on the ARM platform that I was testing. From my understanding, `@Stable` tells the compiler to trust the contents of this field which is only given when the field holder is a known constant. This is generally true for cases like `Enums` but not usually for `Method`. 
> 
> 
> Benchmark                         Mode  Cnt  Score   Error  Units
> # Intel Skylake
> MethodHashCode.benchmarkHashCode  avgt    5  1.113 ? 1.146  ns/op
> # Arm Neoverse N1
> MethodHashCode.benchmarkHashCode  avgt    5  3.204 ? 0.001  ns/op

Interesting, don't know about hotspot internals so I can't diagnose the exact cause of this regression.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19433#discussion_r1619080123

From shade at openjdk.org  Fri May 31 16:39:04 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Fri, 31 May 2024 16:39:04 GMT
Subject: RFR: 8332586: Avoid cloning empty arrays in
 java.lang.reflect.{Method,Constructor} [v2]
In-Reply-To: <StZrZwoC16F1l4TSvBHuUuMqIEZUua_3hC8DjJss80A=.e76c4812-11ba-4f14-b004-b9575d21959e@github.com>
References: <R5bpPuNj1Q2M6uo6_2d6out53rqb17tpheL1jcBDcXw=.3fe0cb7f-1d37-47b0-b4ac-5b7b3ef01bd4@github.com>
 <StZrZwoC16F1l4TSvBHuUuMqIEZUua_3hC8DjJss80A=.e76c4812-11ba-4f14-b004-b9575d21959e@github.com>
Message-ID: <0_dw_Nhkn4cQsZSHM2XUfE6j4L1MuSq0WND5EefB3Vs=.a13c86c0-738d-48d9-a618-bae2a066a5c5@github.com>

On Fri, 31 May 2024 16:21:36 GMT, jengebr <duke at openjdk.org> wrote:

>> Improve `java/lang/reflect/Method.java`  by eliminating needless cloning of Class[0] instances.  This cloning is intended to prevent callers from changing array contents, but smany Methods have zero exceptions or zero parameters, and returning the original `Class[0]` is sufficient.
>
> jengebr has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adding JMH benchmark

Let's bikeshed about the benchmark a little :)

test/micro/org/openjdk/bench/java/lang/reflect/ExecutableParameterAndExceptionTypesBenchmark.java line 49:

> 47: @Warmup(iterations = 3, time = 2, timeUnit = TimeUnit.SECONDS)
> 48: @Measurement(iterations = 5, time = 2, timeUnit = TimeUnit.SECONDS)
> 49: public class ExecutableParameterAndExceptionTypesBenchmark {

I think we want to have two benchmark classes, like we already have `Clazz` as sibling.

Something like:
 MethodBenchmark.getExceptionTypes
 MethodBenchmark.getExceptionTypesEmpty
 MethodBenchmark.getParameterTypes
 MethodBenchmark.getParameterTypesEmtpy
 ConstructorBenchmark.getExceptionTypes
 ConstructorBenchmark.getExceptionTypesEmpty
 ConstructorBenchmark.getParameterTypes
 ConstructorBenchmark.getParameterTypesEmtpy

test/micro/org/openjdk/bench/java/lang/reflect/ExecutableParameterAndExceptionTypesBenchmark.java line 66:

> 64:     public void constructorExceptionsWithNoExceptions(Blackhole bh) throws Exception {
> 65:         bh.consume(objectConstructor.getExceptionTypes());
> 66:     }

Here and later, the common shape for these is:


    @Benchmark
    public Object[] constructorExceptionsWithNoExceptions() {
        return objectConstructor.getExceptionTypes();
    }

-------------

PR Review: https://git.openjdk.org/jdk/pull/19327#pullrequestreview-2091270415
PR Review Comment: https://git.openjdk.org/jdk/pull/19327#discussion_r1622686626
PR Review Comment: https://git.openjdk.org/jdk/pull/19327#discussion_r1622682560

From duke at openjdk.org  Fri May 31 16:53:36 2024
From: duke at openjdk.org (jengebr)
Date: Fri, 31 May 2024 16:53:36 GMT
Subject: RFR: 8332586: Avoid cloning empty arrays in
 java.lang.reflect.{Method,Constructor} [v3]
In-Reply-To: <R5bpPuNj1Q2M6uo6_2d6out53rqb17tpheL1jcBDcXw=.3fe0cb7f-1d37-47b0-b4ac-5b7b3ef01bd4@github.com>
References: <R5bpPuNj1Q2M6uo6_2d6out53rqb17tpheL1jcBDcXw=.3fe0cb7f-1d37-47b0-b4ac-5b7b3ef01bd4@github.com>
Message-ID: <yRmgXWKOYIUMqfIwoqI1ibCEuC-o5XOiQt7grHRC2vg=.01c252f4-90ef-40bc-8790-41136410cbcd@github.com>

> Improve `java/lang/reflect/Method.java`  by eliminating needless cloning of Class[0] instances.  This cloning is intended to prevent callers from changing array contents, but smany Methods have zero exceptions or zero parameters, and returning the original `Class[0]` is sufficient.

jengebr has updated the pull request incrementally with one additional commit since the last revision:

  Correcting and renaming benchmark

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19327/files
  - new: https://git.openjdk.org/jdk/pull/19327/files/4865dede..31b64951

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19327&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19327&range=01-02

  Stats: 145 lines in 2 files changed: 63 ins; 82 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/19327.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19327/head:pull/19327

PR: https://git.openjdk.org/jdk/pull/19327

From erikj at openjdk.org  Fri May 31 17:04:00 2024
From: erikj at openjdk.org (Erik Joelsson)
Date: Fri, 31 May 2024 17:04:00 GMT
Subject: RFR: 8333301: Remove static builds using --enable-static-build
In-Reply-To: <Hqzi-1Qtf2u8Jxd3kysadUcT5MVPXTNjPSTkxVPO2n0=.43501180-2814-43e9-b952-d40a9f767362@github.com>
References: <Hqzi-1Qtf2u8Jxd3kysadUcT5MVPXTNjPSTkxVPO2n0=.43501180-2814-43e9-b952-d40a9f767362@github.com>
Message-ID: <wwpsuVS-iZmayzK0AUkQdu6bZHQJw8jzzLv9UhbPV0g=.dfdf4b4e-2f57-41eb-a1b7-6a3d7ac3d012@github.com>

On Thu, 30 May 2024 19:14:43 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> The original way of building static libraries in the JDK was to use the configure argument --enable-static-build, which set the value of the make variable STATIC_BUILD. (Note that this is not the same as the source code definition STATIC_BUILD, which will be set by other means as well.)
> 
> This method only ever worked on macOS, and has long since stopped working. It was originally introduced for the Mobile Project, but I've now learn that not even they use it anymore.
> 
> It just adds clutter to the build system, and should be removed.

Marked as reviewed by erikj (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/19487#pullrequestreview-2091321250

From duke at openjdk.org  Fri May 31 17:30:17 2024
From: duke at openjdk.org (jengebr)
Date: Fri, 31 May 2024 17:30:17 GMT
Subject: RFR: 8332586: Avoid cloning empty arrays in
 java.lang.reflect.{Method,Constructor} [v4]
In-Reply-To: <R5bpPuNj1Q2M6uo6_2d6out53rqb17tpheL1jcBDcXw=.3fe0cb7f-1d37-47b0-b4ac-5b7b3ef01bd4@github.com>
References: <R5bpPuNj1Q2M6uo6_2d6out53rqb17tpheL1jcBDcXw=.3fe0cb7f-1d37-47b0-b4ac-5b7b3ef01bd4@github.com>
Message-ID: <DzirL6g6wyul0YxRspBuBEOFtxzLTcF0u7vrTM8f0kQ=.5a002152-b443-4b95-93de-a3ac5d384dd7@github.com>

> Improve `java/lang/reflect/Method.java`  by eliminating needless cloning of Class[0] instances.  This cloning is intended to prevent callers from changing array contents, but many Methods have zero exceptions or zero parameters, and returning the original `Class[0]` is sufficient.
> 
> Results from the included JMH benchmark:
> Before:
> 
> Benchmark                                    Mode  Cnt  Score   Error  Units
> ConstructorBenchmark.getExceptionTypes       avgt    5  6.526 ? 0.183  ns/op
> ConstructorBenchmark.getExceptionTypesEmpty  avgt    5  5.803 ? 0.073  ns/op
> ConstructorBenchmark.getParameterTypes       avgt    5  6.521 ? 0.188  ns/op
> ConstructorBenchmark.getParameterTypesEmpty  avgt    5  5.747 ? 0.087  ns/op
> MethodBenchmark.getExceptionTypes            avgt    5  6.525 ? 0.163  ns/op
> MethodBenchmark.getExceptionTypesEmpty       avgt    5  5.783 ? 0.130  ns/op
> MethodBenchmark.getParameterTypes            avgt    5  6.518 ? 0.195  ns/op
> MethodBenchmark.getParameterTypesEmpty       avgt    5  5.742 ? 0.028  ns/op
> 
> 
> After:
> 
> Benchmark                                    Mode  Cnt  Score   Error  Units
> ConstructorBenchmark.getExceptionTypes       avgt    5  6.590 ? 0.124  ns/op
> ConstructorBenchmark.getExceptionTypesEmpty  avgt    5  1.351 ? 0.061  ns/op
> ConstructorBenchmark.getParameterTypes       avgt    5  6.651 ? 0.132  ns/op
> ConstructorBenchmark.getParameterTypesEmpty  avgt    5  1.353 ? 0.150  ns/op
> MethodBenchmark.getExceptionTypes            avgt    5  6.701 ? 0.151  ns/op
> MethodBenchmark.getExceptionTypesEmpty       avgt    5  1.422 ? 0.025  ns/op
> MethodBenchmark.getParameterTypes            avgt    5  6.629 ? 0.142  ns/op
> MethodBenchmark.getParameterTypesEmpty       avgt    5  1.273 ? 0.169  ns/op

jengebr has updated the pull request incrementally with one additional commit since the last revision:

  rewriting JMH per comments

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19327/files
  - new: https://git.openjdk.org/jdk/pull/19327/files/31b64951..e043fd57

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19327&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19327&range=02-03

  Stats: 87 lines in 2 files changed: 72 ins; 1 del; 14 mod
  Patch: https://git.openjdk.org/jdk/pull/19327.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19327/head:pull/19327

PR: https://git.openjdk.org/jdk/pull/19327

From duke at openjdk.org  Fri May 31 17:30:18 2024
From: duke at openjdk.org (jengebr)
Date: Fri, 31 May 2024 17:30:18 GMT
Subject: RFR: 8332586: Avoid cloning empty arrays in
 java.lang.reflect.{Method,Constructor} [v3]
In-Reply-To: <yRmgXWKOYIUMqfIwoqI1ibCEuC-o5XOiQt7grHRC2vg=.01c252f4-90ef-40bc-8790-41136410cbcd@github.com>
References: <R5bpPuNj1Q2M6uo6_2d6out53rqb17tpheL1jcBDcXw=.3fe0cb7f-1d37-47b0-b4ac-5b7b3ef01bd4@github.com>
 <yRmgXWKOYIUMqfIwoqI1ibCEuC-o5XOiQt7grHRC2vg=.01c252f4-90ef-40bc-8790-41136410cbcd@github.com>
Message-ID: <hw8s52Jeec1SEyiAxIX-FXMv8AGkGPWerkxnNWx_-3E=.84f8bc07-bfd7-4982-be7f-238d2a57fd75@github.com>

On Fri, 31 May 2024 16:53:36 GMT, jengebr <duke at openjdk.org> wrote:

>> Improve `java/lang/reflect/Method.java`  by eliminating needless cloning of Class[0] instances.  This cloning is intended to prevent callers from changing array contents, but many Methods have zero exceptions or zero parameters, and returning the original `Class[0]` is sufficient.
>> 
>> Results from the included JMH benchmark:
>> Before:
>> 
>> Benchmark                                    Mode  Cnt  Score   Error  Units
>> ConstructorBenchmark.getExceptionTypes       avgt    5  6.526 ? 0.183  ns/op
>> ConstructorBenchmark.getExceptionTypesEmpty  avgt    5  5.803 ? 0.073  ns/op
>> ConstructorBenchmark.getParameterTypes       avgt    5  6.521 ? 0.188  ns/op
>> ConstructorBenchmark.getParameterTypesEmpty  avgt    5  5.747 ? 0.087  ns/op
>> MethodBenchmark.getExceptionTypes            avgt    5  6.525 ? 0.163  ns/op
>> MethodBenchmark.getExceptionTypesEmpty       avgt    5  5.783 ? 0.130  ns/op
>> MethodBenchmark.getParameterTypes            avgt    5  6.518 ? 0.195  ns/op
>> MethodBenchmark.getParameterTypesEmpty       avgt    5  5.742 ? 0.028  ns/op
>> 
>> 
>> After:
>> 
>> Benchmark                                    Mode  Cnt  Score   Error  Units
>> ConstructorBenchmark.getExceptionTypes       avgt    5  6.590 ? 0.124  ns/op
>> ConstructorBenchmark.getExceptionTypesEmpty  avgt    5  1.351 ? 0.061  ns/op
>> ConstructorBenchmark.getParameterTypes       avgt    5  6.651 ? 0.132  ns/op
>> ConstructorBenchmark.getParameterTypesEmpty  avgt    5  1.353 ? 0.150  ns/op
>> MethodBenchmark.getExceptionTypes            avgt    5  6.701 ? 0.151  ns/op
>> MethodBenchmark.getExceptionTypesEmpty       avgt    5  1.422 ? 0.025  ns/op
>> MethodBenchmark.getParameterTypes            avgt    5  6.629 ? 0.142  ns/op
>> MethodBenchmark.getParameterTypesEmpty       avgt    5  1.273 ? 0.169  ns/op
>
> jengebr has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Correcting and renaming benchmark

JMH modified per comments, description updated to include before-and-after results.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19327#issuecomment-2142690919

From jvernee at openjdk.org  Fri May 31 17:35:06 2024
From: jvernee at openjdk.org (Jorn Vernee)
Date: Fri, 31 May 2024 17:35:06 GMT
Subject: RFR: 8333236: Test java/foreign/TestAccessModes.java is timing out
 after passing [v2]
In-Reply-To: <8TBY8YjU1O2BM5p9a0oG-REt8-1nvtDx_yC4RVotzLc=.8f383b2d-80e4-43b2-ba44-34ce4e55368c@github.com>
References: <mLVkvSWgzjrvnm1R6MZxjacSbTN0CxdA5f5D3lqDti0=.bb215ff2-8bfd-4ce4-8986-522f0ef1af08@github.com>
 <8TBY8YjU1O2BM5p9a0oG-REt8-1nvtDx_yC4RVotzLc=.8f383b2d-80e4-43b2-ba44-34ce4e55368c@github.com>
Message-ID: <g0g54-8rkpfIUHTWFzhxW3z19Mh9X8oaP74Biqcmvmk=.63d4a47f-862a-4d45-a5c5-d30e5ad37caa@github.com>

On Fri, 31 May 2024 16:18:33 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This PR restores a var handle cache in `Utils::makeSegmentViewVarHandle`. The cache was moved to `ValueLayouts::varHandle` as part of [pull/19251](https://git.openjdk.org/jdk/pull/19251), on the basis that we want to optimize the common case like:
>> 
>> 
>> ValueLayout layout = ...
>> layout.varHandle().get(...)
>> 
>> 
>> And that caching more complex var handles didn't seem to add value, given that, for these var handles, the logic in `LayoutPath` needs to adapt the returned var handle anyways.
>> 
>> But, `TestAccessModes` revealed a different picture - w/o any cache in `Utils` the test end up allocating 8963 var handle instances (instead of just 4), in each of the 4 runs the test includes. While this is admittedly a stress test, it seems nice to restore the level of sharing we had before [pull/19251](https://git.openjdk.org/jdk/pull/19251).
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address review comments

Thanks for adding the comment. Looks good

src/java.base/share/classes/jdk/internal/foreign/Utils.java line 98:

> 96:      * <p>
> 97:      * We provide two level of caching of the generated var handles. First, the var handle associated
> 98:      * to a {@link ValueLayout#varHandle()} call is cached inside a stable field of the value layout implementation.

Suggestion:

     * with a {@link ValueLayout#varHandle()} call is cached inside a stable field of the value layout implementation.

-------------

Marked as reviewed by jvernee (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19485#pullrequestreview-2091379947
PR Review Comment: https://git.openjdk.org/jdk/pull/19485#discussion_r1622749916

From iris at openjdk.org  Fri May 31 17:35:06 2024
From: iris at openjdk.org (Iris Clark)
Date: Fri, 31 May 2024 17:35:06 GMT
Subject: RFR: 8331879: Clean up non-standard use of /// comments in
 `java.base` [v2]
In-Reply-To: <PkVqSQtpxtoqeA6HppVjaaktDiquGqXkNT_v49aK-vM=.ea0d04b6-5b0d-487b-8b2b-190954ca5a7a@github.com>
References: <BiSTG8MtjyRt2txRK2DIxsmbPPq6Pvp7QQzOnHXbH6w=.b01b4872-dc8b-4e4f-bae6-bdc501da33a6@github.com>
 <PkVqSQtpxtoqeA6HppVjaaktDiquGqXkNT_v49aK-vM=.ea0d04b6-5b0d-487b-8b2b-190954ca5a7a@github.com>
Message-ID: <EqBvJu1fE9WCmJ6MK-LR9fF06mPlmR1xbdBGg_D--WE=.e4400a2b-d80a-466a-ac1a-fd535f872a20@github.com>

On Tue, 28 May 2024 22:31:15 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> With the advent of JEP 467, `///` comments may be treated as documentation comments, and may be subject to the recently new `javac` warning about "dangling doc comments" in unexpected places.
>> 
>> In keeping with the policy to keep the `java.base` module free of all `javac` warnings, this patch proposes edits to existing uses of `///`.
>> 
>> There are two dominant policies in the proposed changes. 
>> 1. A long horizontal line of `/////` is replaced by `//-----`
>> 2. A long vertical series of lines beginning `///` is replaced by lines beginning `//|`.
>> 
>> As with all style changes, I have also tried to honor local usage, for consistency.
>> 
>> In one place, a pair of comments appeared to contain directives (`CLOVER:ON`, `CLOVER:OFF`).  I investigated the use of such comments to determine that the exact form of the comment prefix was not significant. (Phew!)
>> 
>> 
>> (This PR is informally blocked by JEP 467).
>
> Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision:
> 
>   incorporate review comments

Thanks for making these updates.

To my eye, replacement of "///" with "//---" is preferable over "//|", but I think either choice is acceptable.

-------------

Marked as reviewed by iris (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19130#pullrequestreview-2091379761

From mcimadamore at openjdk.org  Fri May 31 17:50:15 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 31 May 2024 17:50:15 GMT
Subject: RFR: 8333236: Test java/foreign/TestAccessModes.java is timing out
 after passing [v3]
In-Reply-To: <mLVkvSWgzjrvnm1R6MZxjacSbTN0CxdA5f5D3lqDti0=.bb215ff2-8bfd-4ce4-8986-522f0ef1af08@github.com>
References: <mLVkvSWgzjrvnm1R6MZxjacSbTN0CxdA5f5D3lqDti0=.bb215ff2-8bfd-4ce4-8986-522f0ef1af08@github.com>
Message-ID: <85Zy_5QZH9yvwKZD2vUOwiL14JdvGvwIemQ9ncRWiMI=.c66cbf2f-6dc7-4b46-bf84-69ae57b161ff@github.com>

> This PR restores a var handle cache in `Utils::makeSegmentViewVarHandle`. The cache was moved to `ValueLayouts::varHandle` as part of [pull/19251](https://git.openjdk.org/jdk/pull/19251), on the basis that we want to optimize the common case like:
> 
> 
> ValueLayout layout = ...
> layout.varHandle().get(...)
> 
> 
> And that caching more complex var handles didn't seem to add value, given that, for these var handles, the logic in `LayoutPath` needs to adapt the returned var handle anyways.
> 
> But, `TestAccessModes` revealed a different picture - w/o any cache in `Utils` the test end up allocating 8963 var handle instances (instead of just 4), in each of the 4 runs the test includes. While this is admittedly a stress test, it seems nice to restore the level of sharing we had before [pull/19251](https://git.openjdk.org/jdk/pull/19251).

Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:

  Update src/java.base/share/classes/jdk/internal/foreign/Utils.java
  
  Co-authored-by: Jorn Vernee <JornVernee at users.noreply.github.com>

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19485/files
  - new: https://git.openjdk.org/jdk/pull/19485/files/3b2a3380..1ff11392

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19485&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19485&range=01-02

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/19485.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19485/head:pull/19485

PR: https://git.openjdk.org/jdk/pull/19485

From mcimadamore at openjdk.org  Fri May 31 17:56:06 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 31 May 2024 17:56:06 GMT
Subject: RFR: 8333236: Test java/foreign/TestAccessModes.java is timing out
 after passing [v2]
In-Reply-To: <mOHW5iislXzALa56FST-_VY8eQKo2YOlCUEFYHw7hFU=.badf68d6-1924-4ef4-9ee9-92e33ac834ff@github.com>
References: <mLVkvSWgzjrvnm1R6MZxjacSbTN0CxdA5f5D3lqDti0=.bb215ff2-8bfd-4ce4-8986-522f0ef1af08@github.com>
 <8TBY8YjU1O2BM5p9a0oG-REt8-1nvtDx_yC4RVotzLc=.8f383b2d-80e4-43b2-ba44-34ce4e55368c@github.com>
 <mOHW5iislXzALa56FST-_VY8eQKo2YOlCUEFYHw7hFU=.badf68d6-1924-4ef4-9ee9-92e33ac834ff@github.com>
Message-ID: <K3kBlJ6BQZAG8jg94w1QFm-vMxClNJPJJXX0KyWEmMM=.22a8c665-bda4-467a-839a-0981d20669ae@github.com>

On Fri, 31 May 2024 16:26:50 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> Would it make sense to add some tests that assert, `VarHandle` objects get cached?

We can't - at least not easily. As explained in the new comment, the var handles cached by this method are "raw" and always adapted by some other API. So you will never observe their identities from outside.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19485#issuecomment-2142726918

From mcimadamore at openjdk.org  Fri May 31 17:56:07 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 31 May 2024 17:56:07 GMT
Subject: Integrated: 8333236: Test java/foreign/TestAccessModes.java is timing
 out after passing
In-Reply-To: <mLVkvSWgzjrvnm1R6MZxjacSbTN0CxdA5f5D3lqDti0=.bb215ff2-8bfd-4ce4-8986-522f0ef1af08@github.com>
References: <mLVkvSWgzjrvnm1R6MZxjacSbTN0CxdA5f5D3lqDti0=.bb215ff2-8bfd-4ce4-8986-522f0ef1af08@github.com>
Message-ID: <KW85ebq7tOjW7rNBQgMC7li0N4d9LoeblnQIfxCDmMg=.25168b4c-0fec-43a5-82bb-ce349089983d@github.com>

On Thu, 30 May 2024 16:15:22 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> This PR restores a var handle cache in `Utils::makeSegmentViewVarHandle`. The cache was moved to `ValueLayouts::varHandle` as part of [pull/19251](https://git.openjdk.org/jdk/pull/19251), on the basis that we want to optimize the common case like:
> 
> 
> ValueLayout layout = ...
> layout.varHandle().get(...)
> 
> 
> And that caching more complex var handles didn't seem to add value, given that, for these var handles, the logic in `LayoutPath` needs to adapt the returned var handle anyways.
> 
> But, `TestAccessModes` revealed a different picture - w/o any cache in `Utils` the test end up allocating 8963 var handle instances (instead of just 4), in each of the 4 runs the test includes. While this is admittedly a stress test, it seems nice to restore the level of sharing we had before [pull/19251](https://git.openjdk.org/jdk/pull/19251).

This pull request has now been integrated.

Changeset: e99f6a65
Author:    Maurizio Cimadamore <mcimadamore at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/e99f6a65a8307e6b31a08a677914dfd20d46687f
Stats:     27 lines in 2 files changed: 24 ins; 0 del; 3 mod

8333236: Test java/foreign/TestAccessModes.java is timing out after passing

Reviewed-by: jvernee

-------------

PR: https://git.openjdk.org/jdk/pull/19485

From duke at openjdk.org  Fri May 31 17:59:18 2024
From: duke at openjdk.org (jengebr)
Date: Fri, 31 May 2024 17:59:18 GMT
Subject: RFR: 8332586: Avoid cloning empty arrays in
 java.lang.reflect.{Method,Constructor} [v5]
In-Reply-To: <R5bpPuNj1Q2M6uo6_2d6out53rqb17tpheL1jcBDcXw=.3fe0cb7f-1d37-47b0-b4ac-5b7b3ef01bd4@github.com>
References: <R5bpPuNj1Q2M6uo6_2d6out53rqb17tpheL1jcBDcXw=.3fe0cb7f-1d37-47b0-b4ac-5b7b3ef01bd4@github.com>
Message-ID: <wIJN9LO5e1yI-JbRNDRRrUuRz4gzeb4LiktYviATkmk=.4c875827-0b0f-4ce3-8ed7-09e3af4fedc6@github.com>

> Improve `java/lang/reflect/Method.java`  by eliminating needless cloning of Class[0] instances.  This cloning is intended to prevent callers from changing array contents, but many Methods have zero exceptions or zero parameters, and returning the original `Class[0]` is sufficient.
> 
> Results from the included JMH benchmark:
> Before:
> 
> Benchmark                                    Mode  Cnt  Score   Error  Units
> ConstructorBenchmark.getExceptionTypes       avgt    5  6.526 ? 0.183  ns/op
> ConstructorBenchmark.getExceptionTypesEmpty  avgt    5  5.803 ? 0.073  ns/op
> ConstructorBenchmark.getParameterTypes       avgt    5  6.521 ? 0.188  ns/op
> ConstructorBenchmark.getParameterTypesEmpty  avgt    5  5.747 ? 0.087  ns/op
> MethodBenchmark.getExceptionTypes            avgt    5  6.525 ? 0.163  ns/op
> MethodBenchmark.getExceptionTypesEmpty       avgt    5  5.783 ? 0.130  ns/op
> MethodBenchmark.getParameterTypes            avgt    5  6.518 ? 0.195  ns/op
> MethodBenchmark.getParameterTypesEmpty       avgt    5  5.742 ? 0.028  ns/op
> 
> 
> After:
> 
> Benchmark                                    Mode  Cnt  Score   Error  Units
> ConstructorBenchmark.getExceptionTypes       avgt    5  6.590 ? 0.124  ns/op
> ConstructorBenchmark.getExceptionTypesEmpty  avgt    5  1.351 ? 0.061  ns/op
> ConstructorBenchmark.getParameterTypes       avgt    5  6.651 ? 0.132  ns/op
> ConstructorBenchmark.getParameterTypesEmpty  avgt    5  1.353 ? 0.150  ns/op
> MethodBenchmark.getExceptionTypes            avgt    5  6.701 ? 0.151  ns/op
> MethodBenchmark.getExceptionTypesEmpty       avgt    5  1.422 ? 0.025  ns/op
> MethodBenchmark.getParameterTypes            avgt    5  6.629 ? 0.142  ns/op
> MethodBenchmark.getParameterTypesEmpty       avgt    5  1.273 ? 0.169  ns/op

jengebr has updated the pull request incrementally with one additional commit since the last revision:

  Fixing copyright message, returning values from benchmark

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19327/files
  - new: https://git.openjdk.org/jdk/pull/19327/files/e043fd57..b0d7942f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19327&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19327&range=03-04

  Stats: 54 lines in 2 files changed: 38 ins; 0 del; 16 mod
  Patch: https://git.openjdk.org/jdk/pull/19327.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19327/head:pull/19327

PR: https://git.openjdk.org/jdk/pull/19327

From shade at openjdk.org  Fri May 31 18:02:03 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Fri, 31 May 2024 18:02:03 GMT
Subject: RFR: 8332586: Avoid cloning empty arrays in
 java.lang.reflect.{Method,Constructor} [v5]
In-Reply-To: <wIJN9LO5e1yI-JbRNDRRrUuRz4gzeb4LiktYviATkmk=.4c875827-0b0f-4ce3-8ed7-09e3af4fedc6@github.com>
References: <R5bpPuNj1Q2M6uo6_2d6out53rqb17tpheL1jcBDcXw=.3fe0cb7f-1d37-47b0-b4ac-5b7b3ef01bd4@github.com>
 <wIJN9LO5e1yI-JbRNDRRrUuRz4gzeb4LiktYviATkmk=.4c875827-0b0f-4ce3-8ed7-09e3af4fedc6@github.com>
Message-ID: <Ef-XYWEbYTVE8eEQdOsgn5JjGYyTWagNxKZNGshk1L4=.b5d0fb71-52d5-4dfb-8ffb-90d8cb09cee9@github.com>

On Fri, 31 May 2024 17:59:18 GMT, jengebr <duke at openjdk.org> wrote:

>> Improve `java/lang/reflect/Method.java`  by eliminating needless cloning of Class[0] instances.  This cloning is intended to prevent callers from changing array contents, but many Methods have zero exceptions or zero parameters, and returning the original `Class[0]` is sufficient.
>> 
>> Results from the included JMH benchmark:
>> Before:
>> 
>> Benchmark                                    Mode  Cnt  Score   Error  Units
>> ConstructorBenchmark.getExceptionTypes       avgt    5  6.526 ? 0.183  ns/op
>> ConstructorBenchmark.getExceptionTypesEmpty  avgt    5  5.803 ? 0.073  ns/op
>> ConstructorBenchmark.getParameterTypes       avgt    5  6.521 ? 0.188  ns/op
>> ConstructorBenchmark.getParameterTypesEmpty  avgt    5  5.747 ? 0.087  ns/op
>> MethodBenchmark.getExceptionTypes            avgt    5  6.525 ? 0.163  ns/op
>> MethodBenchmark.getExceptionTypesEmpty       avgt    5  5.783 ? 0.130  ns/op
>> MethodBenchmark.getParameterTypes            avgt    5  6.518 ? 0.195  ns/op
>> MethodBenchmark.getParameterTypesEmpty       avgt    5  5.742 ? 0.028  ns/op
>> 
>> 
>> After:
>> 
>> Benchmark                                    Mode  Cnt  Score   Error  Units
>> ConstructorBenchmark.getExceptionTypes       avgt    5  6.590 ? 0.124  ns/op
>> ConstructorBenchmark.getExceptionTypesEmpty  avgt    5  1.351 ? 0.061  ns/op
>> ConstructorBenchmark.getParameterTypes       avgt    5  6.651 ? 0.132  ns/op
>> ConstructorBenchmark.getParameterTypesEmpty  avgt    5  1.353 ? 0.150  ns/op
>> MethodBenchmark.getExceptionTypes            avgt    5  6.701 ? 0.151  ns/op
>> MethodBenchmark.getExceptionTypesEmpty       avgt    5  1.422 ? 0.025  ns/op
>> MethodBenchmark.getParameterTypes            avgt    5  6.629 ? 0.142  ns/op
>> MethodBenchmark.getParameterTypesEmpty       avgt    5  1.273 ? 0.169  ns/op
>
> jengebr has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixing copyright message, returning values from benchmark

Thanks for adding the benchmark. This looks good to me. Other nits below, your call if you want to fix them or not. (This is usually done if there are other changes requested, but they are not important enough to require standalone work.)

test/micro/org/openjdk/bench/java/lang/reflect/ConstructorBenchmark.java line 64:

> 62:             throw new RuntimeException(e);
> 63:         }
> 64: 

Here and in another benchmark.  Excess newline?

test/micro/org/openjdk/bench/java/lang/reflect/ConstructorBenchmark.java line 85:

> 83:     public Object[] getParameterTypes() throws Exception {
> 84:         return oneParameterConstructor.getParameterTypes();
> 85:     }

Here and in another benchmark. Order looks weird: non-empty, empty, empty, non-empty.

-------------

Marked as reviewed by shade (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19327#pullrequestreview-2091420074
PR Review Comment: https://git.openjdk.org/jdk/pull/19327#discussion_r1622774426
PR Review Comment: https://git.openjdk.org/jdk/pull/19327#discussion_r1622775072

From bchristi at openjdk.org  Fri May 31 18:33:39 2024
From: bchristi at openjdk.org (Brent Christian)
Date: Fri, 31 May 2024 18:33:39 GMT
Subject: RFR: 8314480: Memory ordering spec updates in java.lang.ref [v35]
In-Reply-To: <R74ontYwjYg6HeZY0cWrlo0amjl4E1YsFWeuh4pda14=.08ac62df-b2f8-4b4d-b338-07adb289601b@github.com>
References: <R74ontYwjYg6HeZY0cWrlo0amjl4E1YsFWeuh4pda14=.08ac62df-b2f8-4b4d-b338-07adb289601b@github.com>
Message-ID: <q1FPAZv5Ri_LysFtpAM3BlpJVZ3RoUTA_9GkLwc-ppE=.efc42fb9-c5d6-4a15-ad30-3dcbf8449828@github.com>

> Classes in the `java.lang.ref` package would benefit from an update to bring the spec in line with how the VM already behaves. The changes would focus on _happens-before_ edges at some key points during reference processing.
> 
> A couple key things we want to be able to say are:
> - `Reference.reachabilityFence(x)` _happens-before_ reference processing occurs for 'x'.
> - `Cleaner.register()` _happens-before_ the Cleaner thread runs the registered cleaning action.
> 
> This will bring Cleaner in line (or close) with the memory visibility guarantees made for finalizers in [JLS 17.4.5](https://docs.oracle.com/javase/specs/jls/se18/html/jls-17.html#jls-17.4.5):
> _"There is a happens-before edge from the end of a constructor of an object to the start of a finalizer (?12.6) for that object."_

Brent Christian has updated the pull request incrementally with one additional commit since the last revision:

  another package doc link

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/16644/files
  - new: https://git.openjdk.org/jdk/pull/16644/files/e02bf98e..cf0dc3b8

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16644&range=34
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16644&range=33-34

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/16644.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16644/head:pull/16644

PR: https://git.openjdk.org/jdk/pull/16644

From duke at openjdk.org  Fri May 31 18:39:33 2024
From: duke at openjdk.org (jengebr)
Date: Fri, 31 May 2024 18:39:33 GMT
Subject: RFR: 8332586: Avoid cloning empty arrays in
 java.lang.reflect.{Method,Constructor} [v6]
In-Reply-To: <R5bpPuNj1Q2M6uo6_2d6out53rqb17tpheL1jcBDcXw=.3fe0cb7f-1d37-47b0-b4ac-5b7b3ef01bd4@github.com>
References: <R5bpPuNj1Q2M6uo6_2d6out53rqb17tpheL1jcBDcXw=.3fe0cb7f-1d37-47b0-b4ac-5b7b3ef01bd4@github.com>
Message-ID: <9ci7LNaIJt3-hmeXTHJYCw4qc-LCW_WjFZ1wC70da3M=.8aa1d843-c71e-4b0b-b497-e18e52bfc48e@github.com>

> Improve `java/lang/reflect/Method.java`  by eliminating needless cloning of Class[0] instances.  This cloning is intended to prevent callers from changing array contents, but many Methods have zero exceptions or zero parameters, and returning the original `Class[0]` is sufficient.
> 
> Results from the included JMH benchmark:
> Before:
> 
> Benchmark                                    Mode  Cnt  Score   Error  Units
> ConstructorBenchmark.getExceptionTypes       avgt    5  6.526 ? 0.183  ns/op
> ConstructorBenchmark.getExceptionTypesEmpty  avgt    5  5.803 ? 0.073  ns/op
> ConstructorBenchmark.getParameterTypes       avgt    5  6.521 ? 0.188  ns/op
> ConstructorBenchmark.getParameterTypesEmpty  avgt    5  5.747 ? 0.087  ns/op
> MethodBenchmark.getExceptionTypes            avgt    5  6.525 ? 0.163  ns/op
> MethodBenchmark.getExceptionTypesEmpty       avgt    5  5.783 ? 0.130  ns/op
> MethodBenchmark.getParameterTypes            avgt    5  6.518 ? 0.195  ns/op
> MethodBenchmark.getParameterTypesEmpty       avgt    5  5.742 ? 0.028  ns/op
> 
> 
> After:
> 
> Benchmark                                    Mode  Cnt  Score   Error  Units
> ConstructorBenchmark.getExceptionTypes       avgt    5  6.590 ? 0.124  ns/op
> ConstructorBenchmark.getExceptionTypesEmpty  avgt    5  1.351 ? 0.061  ns/op
> ConstructorBenchmark.getParameterTypes       avgt    5  6.651 ? 0.132  ns/op
> ConstructorBenchmark.getParameterTypesEmpty  avgt    5  1.353 ? 0.150  ns/op
> MethodBenchmark.getExceptionTypes            avgt    5  6.701 ? 0.151  ns/op
> MethodBenchmark.getExceptionTypesEmpty       avgt    5  1.422 ? 0.025  ns/op
> MethodBenchmark.getParameterTypes            avgt    5  6.629 ? 0.142  ns/op
> MethodBenchmark.getParameterTypesEmpty       avgt    5  1.273 ? 0.169  ns/op

jengebr has updated the pull request incrementally with one additional commit since the last revision:

  Fixing nits in benchmark

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19327/files
  - new: https://git.openjdk.org/jdk/pull/19327/files/b0d7942f..28ac4d25

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19327&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19327&range=04-05

  Stats: 18 lines in 2 files changed: 4 ins; 6 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/19327.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19327/head:pull/19327

PR: https://git.openjdk.org/jdk/pull/19327

From duke at openjdk.org  Fri May 31 18:39:34 2024
From: duke at openjdk.org (jengebr)
Date: Fri, 31 May 2024 18:39:34 GMT
Subject: RFR: 8332586: Avoid cloning empty arrays in
 java.lang.reflect.{Method,Constructor} [v5]
In-Reply-To: <wIJN9LO5e1yI-JbRNDRRrUuRz4gzeb4LiktYviATkmk=.4c875827-0b0f-4ce3-8ed7-09e3af4fedc6@github.com>
References: <R5bpPuNj1Q2M6uo6_2d6out53rqb17tpheL1jcBDcXw=.3fe0cb7f-1d37-47b0-b4ac-5b7b3ef01bd4@github.com>
 <wIJN9LO5e1yI-JbRNDRRrUuRz4gzeb4LiktYviATkmk=.4c875827-0b0f-4ce3-8ed7-09e3af4fedc6@github.com>
Message-ID: <acUp2zjIgt601KDxYgT2qN1XpvxLi2-BKzA4V0aGFfs=.e7ffa11a-872e-43ec-97b6-c46b840fdbcd@github.com>

On Fri, 31 May 2024 17:59:18 GMT, jengebr <duke at openjdk.org> wrote:

>> Improve `java/lang/reflect/Method.java`  by eliminating needless cloning of Class[0] instances.  This cloning is intended to prevent callers from changing array contents, but many Methods have zero exceptions or zero parameters, and returning the original `Class[0]` is sufficient.
>> 
>> Results from the included JMH benchmark:
>> Before:
>> 
>> Benchmark                                    Mode  Cnt  Score   Error  Units
>> ConstructorBenchmark.getExceptionTypes       avgt    5  6.526 ? 0.183  ns/op
>> ConstructorBenchmark.getExceptionTypesEmpty  avgt    5  5.803 ? 0.073  ns/op
>> ConstructorBenchmark.getParameterTypes       avgt    5  6.521 ? 0.188  ns/op
>> ConstructorBenchmark.getParameterTypesEmpty  avgt    5  5.747 ? 0.087  ns/op
>> MethodBenchmark.getExceptionTypes            avgt    5  6.525 ? 0.163  ns/op
>> MethodBenchmark.getExceptionTypesEmpty       avgt    5  5.783 ? 0.130  ns/op
>> MethodBenchmark.getParameterTypes            avgt    5  6.518 ? 0.195  ns/op
>> MethodBenchmark.getParameterTypesEmpty       avgt    5  5.742 ? 0.028  ns/op
>> 
>> 
>> After:
>> 
>> Benchmark                                    Mode  Cnt  Score   Error  Units
>> ConstructorBenchmark.getExceptionTypes       avgt    5  6.590 ? 0.124  ns/op
>> ConstructorBenchmark.getExceptionTypesEmpty  avgt    5  1.351 ? 0.061  ns/op
>> ConstructorBenchmark.getParameterTypes       avgt    5  6.651 ? 0.132  ns/op
>> ConstructorBenchmark.getParameterTypesEmpty  avgt    5  1.353 ? 0.150  ns/op
>> MethodBenchmark.getExceptionTypes            avgt    5  6.701 ? 0.151  ns/op
>> MethodBenchmark.getExceptionTypesEmpty       avgt    5  1.422 ? 0.025  ns/op
>> MethodBenchmark.getParameterTypes            avgt    5  6.629 ? 0.142  ns/op
>> MethodBenchmark.getParameterTypesEmpty       avgt    5  1.273 ? 0.169  ns/op
>
> jengebr has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixing copyright message, returning values from benchmark

Thanks!  Blank line removed, fields and methods alphabetized.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19327#issuecomment-2142793269

From shade at openjdk.org  Fri May 31 18:45:02 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Fri, 31 May 2024 18:45:02 GMT
Subject: RFR: 8332586: Avoid cloning empty arrays in
 java.lang.reflect.{Method,Constructor} [v6]
In-Reply-To: <9ci7LNaIJt3-hmeXTHJYCw4qc-LCW_WjFZ1wC70da3M=.8aa1d843-c71e-4b0b-b497-e18e52bfc48e@github.com>
References: <R5bpPuNj1Q2M6uo6_2d6out53rqb17tpheL1jcBDcXw=.3fe0cb7f-1d37-47b0-b4ac-5b7b3ef01bd4@github.com>
 <9ci7LNaIJt3-hmeXTHJYCw4qc-LCW_WjFZ1wC70da3M=.8aa1d843-c71e-4b0b-b497-e18e52bfc48e@github.com>
Message-ID: <Wv4-H6-CIiSbDbcbkjf80pyw8m27KucY5itZkKPjF5w=.96d9ef9a-8432-4b9e-8117-f7bef868c7a8@github.com>

On Fri, 31 May 2024 18:39:33 GMT, jengebr <duke at openjdk.org> wrote:

>> Improve `java/lang/reflect/Method.java`  by eliminating needless cloning of Class[0] instances.  This cloning is intended to prevent callers from changing array contents, but many Methods have zero exceptions or zero parameters, and returning the original `Class[0]` is sufficient.
>> 
>> Results from the included JMH benchmark:
>> Before:
>> 
>> Benchmark                                    Mode  Cnt  Score   Error  Units
>> ConstructorBenchmark.getExceptionTypes       avgt    5  6.526 ? 0.183  ns/op
>> ConstructorBenchmark.getExceptionTypesEmpty  avgt    5  5.803 ? 0.073  ns/op
>> ConstructorBenchmark.getParameterTypes       avgt    5  6.521 ? 0.188  ns/op
>> ConstructorBenchmark.getParameterTypesEmpty  avgt    5  5.747 ? 0.087  ns/op
>> MethodBenchmark.getExceptionTypes            avgt    5  6.525 ? 0.163  ns/op
>> MethodBenchmark.getExceptionTypesEmpty       avgt    5  5.783 ? 0.130  ns/op
>> MethodBenchmark.getParameterTypes            avgt    5  6.518 ? 0.195  ns/op
>> MethodBenchmark.getParameterTypesEmpty       avgt    5  5.742 ? 0.028  ns/op
>> 
>> 
>> After:
>> 
>> Benchmark                                    Mode  Cnt  Score   Error  Units
>> ConstructorBenchmark.getExceptionTypes       avgt    5  6.590 ? 0.124  ns/op
>> ConstructorBenchmark.getExceptionTypesEmpty  avgt    5  1.351 ? 0.061  ns/op
>> ConstructorBenchmark.getParameterTypes       avgt    5  6.651 ? 0.132  ns/op
>> ConstructorBenchmark.getParameterTypesEmpty  avgt    5  1.353 ? 0.150  ns/op
>> MethodBenchmark.getExceptionTypes            avgt    5  6.701 ? 0.151  ns/op
>> MethodBenchmark.getExceptionTypesEmpty       avgt    5  1.422 ? 0.025  ns/op
>> MethodBenchmark.getParameterTypes            avgt    5  6.629 ? 0.142  ns/op
>> MethodBenchmark.getParameterTypesEmpty       avgt    5  1.273 ? 0.169  ns/op
>
> jengebr has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixing nits in benchmark

Marked as reviewed by shade (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/19327#pullrequestreview-2091506122

From liach at openjdk.org  Fri May 31 19:03:03 2024
From: liach at openjdk.org (Chen Liang)
Date: Fri, 31 May 2024 19:03:03 GMT
Subject: RFR: 8332586: Avoid cloning empty arrays in
 java.lang.reflect.{Method,Constructor} [v6]
In-Reply-To: <9ci7LNaIJt3-hmeXTHJYCw4qc-LCW_WjFZ1wC70da3M=.8aa1d843-c71e-4b0b-b497-e18e52bfc48e@github.com>
References: <R5bpPuNj1Q2M6uo6_2d6out53rqb17tpheL1jcBDcXw=.3fe0cb7f-1d37-47b0-b4ac-5b7b3ef01bd4@github.com>
 <9ci7LNaIJt3-hmeXTHJYCw4qc-LCW_WjFZ1wC70da3M=.8aa1d843-c71e-4b0b-b497-e18e52bfc48e@github.com>
Message-ID: <5NEx9ZonZuD2g7kX4i6mR3B3jGZQWxFLft0IH1gXwl4=.5b350ffd-e16d-4553-bdb2-0f252188ecd7@github.com>

On Fri, 31 May 2024 18:39:33 GMT, jengebr <duke at openjdk.org> wrote:

>> Improve `java/lang/reflect/Method.java`  by eliminating needless cloning of Class[0] instances.  This cloning is intended to prevent callers from changing array contents, but many Methods have zero exceptions or zero parameters, and returning the original `Class[0]` is sufficient.
>> 
>> Results from the included JMH benchmark:
>> Before:
>> 
>> Benchmark                                    Mode  Cnt  Score   Error  Units
>> ConstructorBenchmark.getExceptionTypes       avgt    5  6.526 ? 0.183  ns/op
>> ConstructorBenchmark.getExceptionTypesEmpty  avgt    5  5.803 ? 0.073  ns/op
>> ConstructorBenchmark.getParameterTypes       avgt    5  6.521 ? 0.188  ns/op
>> ConstructorBenchmark.getParameterTypesEmpty  avgt    5  5.747 ? 0.087  ns/op
>> MethodBenchmark.getExceptionTypes            avgt    5  6.525 ? 0.163  ns/op
>> MethodBenchmark.getExceptionTypesEmpty       avgt    5  5.783 ? 0.130  ns/op
>> MethodBenchmark.getParameterTypes            avgt    5  6.518 ? 0.195  ns/op
>> MethodBenchmark.getParameterTypesEmpty       avgt    5  5.742 ? 0.028  ns/op
>> 
>> 
>> After:
>> 
>> Benchmark                                    Mode  Cnt  Score   Error  Units
>> ConstructorBenchmark.getExceptionTypes       avgt    5  6.590 ? 0.124  ns/op
>> ConstructorBenchmark.getExceptionTypesEmpty  avgt    5  1.351 ? 0.061  ns/op
>> ConstructorBenchmark.getParameterTypes       avgt    5  6.651 ? 0.132  ns/op
>> ConstructorBenchmark.getParameterTypesEmpty  avgt    5  1.353 ? 0.150  ns/op
>> MethodBenchmark.getExceptionTypes            avgt    5  6.701 ? 0.151  ns/op
>> MethodBenchmark.getExceptionTypesEmpty       avgt    5  1.422 ? 0.025  ns/op
>> MethodBenchmark.getParameterTypes            avgt    5  6.629 ? 0.142  ns/op
>> MethodBenchmark.getParameterTypesEmpty       avgt    5  1.273 ? 0.169  ns/op
>
> jengebr has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixing nits in benchmark

Marked as reviewed by liach (Author).

-------------

PR Review: https://git.openjdk.org/jdk/pull/19327#pullrequestreview-2091537949

From almatvee at openjdk.org  Fri May 31 19:44:02 2024
From: almatvee at openjdk.org (Alexander Matveev)
Date: Fri, 31 May 2024 19:44:02 GMT
Subject: RFR: 8332110: [macos] jpackage tries to sign added files without
 the --mac-sign option [v2]
In-Reply-To: <MHX7njtAIaHbux16PHC0OmzQTP1So7-LVfa4iKnaYS8=.55735e6f-8f60-4de6-9af5-eac8c7a861d4@github.com>
References: <eiboU_LgwkTte_7rkPJAdDm1x_-Pzm8rdwUiY_4MAYI=.b982e161-fe24-44ab-9db5-2f1d80eb0d99@github.com>
 <HI6HYfkNrR1fV5fKnQbAwk-TUWPhRjYIEfdnosvAZ60=.b205f7ba-d2c8-46bc-b192-439d318df63f@github.com>
 <MHX7njtAIaHbux16PHC0OmzQTP1So7-LVfa4iKnaYS8=.55735e6f-8f60-4de6-9af5-eac8c7a861d4@github.com>
Message-ID: <1nTM9jQVjDVUqETnJr9e8rViOTSVtcTeKLrDLSTN2L8=.5d23e112-56ad-4675-8a06-9b8336088adc@github.com>

On Thu, 30 May 2024 14:21:51 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

>> Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8332110: jpackage tries to sign added files without the --mac-sign option [v2]
>
> test/jdk/tools/jpackage/macosx/SigningOptionsTest.java line 97:
> 
>> 95:                     new String[]{"--app-content", TEST_DUKE},
>> 96:                     null,
>> 97:                     "\"codesign\" failure is additional content provided via \"--app-content\""},
> 
> Why is this not a `One of the possible reason for "{0}" failure is additional content provided via "--app-content"`?

It was part of old message. Latest test version has latest message: ""codesign" failed and additional application content was supplied via the "--app-content" parameter."

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19377#discussion_r1622884704

From darcy at openjdk.org  Fri May 31 20:06:03 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 31 May 2024 20:06:03 GMT
Subject: RFR: 8331879: Clean up non-standard use of /// comments in
 `java.base` [v2]
In-Reply-To: <PkVqSQtpxtoqeA6HppVjaaktDiquGqXkNT_v49aK-vM=.ea0d04b6-5b0d-487b-8b2b-190954ca5a7a@github.com>
References: <BiSTG8MtjyRt2txRK2DIxsmbPPq6Pvp7QQzOnHXbH6w=.b01b4872-dc8b-4e4f-bae6-bdc501da33a6@github.com>
 <PkVqSQtpxtoqeA6HppVjaaktDiquGqXkNT_v49aK-vM=.ea0d04b6-5b0d-487b-8b2b-190954ca5a7a@github.com>
Message-ID: <zC7vJ8kh4jrcoDQ4XsFXxLdxI7-KwVwSwFi9P-1h6y4=.4d8f0da1-98c5-4c6d-9392-600398bf0f84@github.com>

On Tue, 28 May 2024 22:31:15 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> With the advent of JEP 467, `///` comments may be treated as documentation comments, and may be subject to the recently new `javac` warning about "dangling doc comments" in unexpected places.
>> 
>> In keeping with the policy to keep the `java.base` module free of all `javac` warnings, this patch proposes edits to existing uses of `///`.
>> 
>> There are two dominant policies in the proposed changes. 
>> 1. A long horizontal line of `/////` is replaced by `//-----`
>> 2. A long vertical series of lines beginning `///` is replaced by lines beginning `//|`.
>> 
>> As with all style changes, I have also tried to honor local usage, for consistency.
>> 
>> In one place, a pair of comments appeared to contain directives (`CLOVER:ON`, `CLOVER:OFF`).  I investigated the use of such comments to determine that the exact form of the comment prefix was not significant. (Phew!)
>> 
>> 
>> (This PR is informally blocked by JEP 467).
>
> Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision:
> 
>   incorporate review comments

Marked as reviewed by darcy (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/19130#pullrequestreview-2091633348

From almatvee at openjdk.org  Fri May 31 20:33:07 2024
From: almatvee at openjdk.org (Alexander Matveev)
Date: Fri, 31 May 2024 20:33:07 GMT
Subject: Integrated: 8332110: [macos] jpackage tries to sign added files
 without the --mac-sign option
In-Reply-To: <eiboU_LgwkTte_7rkPJAdDm1x_-Pzm8rdwUiY_4MAYI=.b982e161-fe24-44ab-9db5-2f1d80eb0d99@github.com>
References: <eiboU_LgwkTte_7rkPJAdDm1x_-Pzm8rdwUiY_4MAYI=.b982e161-fe24-44ab-9db5-2f1d80eb0d99@github.com>
Message-ID: <ab-fXAcg-zC3MGuACDD5WmFum9S7EuCxzKvV1ef5T0U=.7ac3b531-004f-473d-ad34-2c621499c53b@github.com>

On Fri, 24 May 2024 01:08:03 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

> This issue is reproducible with and without `--mac-sign`. jpackage will "_ad-hoc_" sign application bundle when `--mac-sign` is not specified by using pseudo-identity "_-_". This is why jpackage tries to sign added files and this is expected behavior by jpackage. "codesign" fails since added content made application bundle structure invalid. There is nothing we can do on jpackage side to sign such invalid bundles. As proposed solution we will output possible reason for "codesign" failure if it fails and `--app-content` was specified and possible solution. Proposed message: "One of the possible reason for "codesign" failure is additional content provided via "--app-content", which made application bundle structure invalid. Make sure to provide additional content in a way it will not break application bundle structure, otherwise add additional content as post-processing step."
> 
> Example:
> Lets assume we have "ReadMe" folder with "ReadMe.txt" file in it.
> 1) jpackage --type app-image -n Test --app-content ReadMe/ReadMe.txt ...
> "codesign" will fail with "In subcomponent: Test.app/Contents/ReadMe.txt". This is expected and "ReadMe.txt" placed in "Test.app/Contents" which is also expected.
> 2) jpackage --type app-image -n Test --app-content ReadMe ...
> Works and "ReadMe.txt" will be placed under "Test.app/Contents/ReadMe".
> 
> Sample output before fix:
> 
> Error: "codesign" failed with following output:
> Test.app: replacing existing signature
> Test.app: code object is not signed at all
> In subcomponent: Test.app/Contents/ReadMe.txt
> 
> 
> Sample output after fix:
> 
> "codesign" failed and additional application content was supplied via the "--app-content" parameter. Probably the additional content broke the integrity of the application bundle and caused the failure. Ensure content supplied via the "--app-content" parameter does not break the integrity of the application bundle, or add it in the post-processing step.
> Error: "codesign" failed with following output:
> Test.app: replacing existing signature
> Test.app: code object is not signed at all
> In subcomponent: Test.app/Contents/ReadMe.txt

This pull request has now been integrated.

Changeset: 9fd0e734
Author:    Alexander Matveev <almatvee at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/9fd0e7349ebf4a49b5c0c7a16c866b5b8e626b53
Stats:     39 lines in 6 files changed: 25 ins; 0 del; 14 mod

8332110: [macos] jpackage tries to sign added files without the --mac-sign option

Reviewed-by: asemenyuk

-------------

PR: https://git.openjdk.org/jdk/pull/19377

From nlisker at openjdk.org  Fri May 31 20:46:06 2024
From: nlisker at openjdk.org (Nir Lisker)
Date: Fri, 31 May 2024 20:46:06 GMT
Subject: RFR: 8332110: [macos] jpackage tries to sign added files without
 the --mac-sign option
In-Reply-To: <PH7PR10MB7055707BCDA794208E1FF19399F52@PH7PR10MB7055.namprd10.prod.outlook.com>
References: <eiboU_LgwkTte_7rkPJAdDm1x_-Pzm8rdwUiY_4MAYI=.b982e161-fe24-44ab-9db5-2f1d80eb0d99@github.com>
 <PH7PR10MB7055707BCDA794208E1FF19399F52@PH7PR10MB7055.namprd10.prod.outlook.com>
Message-ID: <O38-sgnCLSaGSCfSpIWYQ2uNz1ZUc6Tv6xJYCF4hj3M=.1e5af57b-ecda-4fe0-8c60-eed5378703ac@github.com>

On Sat, 25 May 2024 01:12:56 GMT, Alexander Matveev <alexander.matveev at oracle.com> wrote:

> > For your example. This almost seems like an Apple bug if you can add a directory to the Contents directory but not a file?
> 
> Not sure if it is an Apple bug.

Can this be reported to Apple somehow?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19377#issuecomment-2142953200

From rriggs at openjdk.org  Fri May 31 20:52:04 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 31 May 2024 20:52:04 GMT
Subject: RFR: 8332586: Avoid cloning empty arrays in
 java.lang.reflect.{Method,Constructor} [v6]
In-Reply-To: <9ci7LNaIJt3-hmeXTHJYCw4qc-LCW_WjFZ1wC70da3M=.8aa1d843-c71e-4b0b-b497-e18e52bfc48e@github.com>
References: <R5bpPuNj1Q2M6uo6_2d6out53rqb17tpheL1jcBDcXw=.3fe0cb7f-1d37-47b0-b4ac-5b7b3ef01bd4@github.com>
 <9ci7LNaIJt3-hmeXTHJYCw4qc-LCW_WjFZ1wC70da3M=.8aa1d843-c71e-4b0b-b497-e18e52bfc48e@github.com>
Message-ID: <YldKyF5eqq_RkZUdquuSuLVLzLsYYv9CpEHYspF3u14=.eaf676bd-dcb2-4f08-9948-d8c10dbbf613@github.com>

On Fri, 31 May 2024 18:39:33 GMT, jengebr <duke at openjdk.org> wrote:

>> Improve `java/lang/reflect/Method.java`  by eliminating needless cloning of Class[0] instances.  This cloning is intended to prevent callers from changing array contents, but many Methods have zero exceptions or zero parameters, and returning the original `Class[0]` is sufficient.
>> 
>> Results from the included JMH benchmark:
>> Before:
>> 
>> Benchmark                                    Mode  Cnt  Score   Error  Units
>> ConstructorBenchmark.getExceptionTypes       avgt    5  6.526 ? 0.183  ns/op
>> ConstructorBenchmark.getExceptionTypesEmpty  avgt    5  5.803 ? 0.073  ns/op
>> ConstructorBenchmark.getParameterTypes       avgt    5  6.521 ? 0.188  ns/op
>> ConstructorBenchmark.getParameterTypesEmpty  avgt    5  5.747 ? 0.087  ns/op
>> MethodBenchmark.getExceptionTypes            avgt    5  6.525 ? 0.163  ns/op
>> MethodBenchmark.getExceptionTypesEmpty       avgt    5  5.783 ? 0.130  ns/op
>> MethodBenchmark.getParameterTypes            avgt    5  6.518 ? 0.195  ns/op
>> MethodBenchmark.getParameterTypesEmpty       avgt    5  5.742 ? 0.028  ns/op
>> 
>> 
>> After:
>> 
>> Benchmark                                    Mode  Cnt  Score   Error  Units
>> ConstructorBenchmark.getExceptionTypes       avgt    5  6.590 ? 0.124  ns/op
>> ConstructorBenchmark.getExceptionTypesEmpty  avgt    5  1.351 ? 0.061  ns/op
>> ConstructorBenchmark.getParameterTypes       avgt    5  6.651 ? 0.132  ns/op
>> ConstructorBenchmark.getParameterTypesEmpty  avgt    5  1.353 ? 0.150  ns/op
>> MethodBenchmark.getExceptionTypes            avgt    5  6.701 ? 0.151  ns/op
>> MethodBenchmark.getExceptionTypesEmpty       avgt    5  1.422 ? 0.025  ns/op
>> MethodBenchmark.getParameterTypes            avgt    5  6.629 ? 0.142  ns/op
>> MethodBenchmark.getParameterTypesEmpty       avgt    5  1.273 ? 0.169  ns/op
>
> jengebr has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixing nits in benchmark

Marked as reviewed by rriggs (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/19327#pullrequestreview-2091692284

From almatvee at openjdk.org  Fri May 31 21:13:10 2024
From: almatvee at openjdk.org (Alexander Matveev)
Date: Fri, 31 May 2024 21:13:10 GMT
Subject: RFR: 8332110: [macos] jpackage tries to sign added files without
 the --mac-sign option
In-Reply-To: <O38-sgnCLSaGSCfSpIWYQ2uNz1ZUc6Tv6xJYCF4hj3M=.1e5af57b-ecda-4fe0-8c60-eed5378703ac@github.com>
References: <eiboU_LgwkTte_7rkPJAdDm1x_-Pzm8rdwUiY_4MAYI=.b982e161-fe24-44ab-9db5-2f1d80eb0d99@github.com>
 <PH7PR10MB7055707BCDA794208E1FF19399F52@PH7PR10MB7055.namprd10.prod.outlook.com>
 <O38-sgnCLSaGSCfSpIWYQ2uNz1ZUc6Tv6xJYCF4hj3M=.1e5af57b-ecda-4fe0-8c60-eed5378703ac@github.com>
Message-ID: <o2-kfe1_cW1sER-6eX8udlgPXgXkTrGFrpv168f1kGc=.ae4bef34-70e3-4b9e-8e4d-cfcc5eb6f720@github.com>

On Fri, 31 May 2024 20:43:45 GMT, Nir Lisker <nlisker at openjdk.org> wrote:

> > > For your example. This almost seems like an Apple bug if you can add a directory to the Contents directory but not a file?
> > 
> > 
> > Not sure if it is an Apple bug.
> 
> Can this be reported to Apple somehow?

I do not think that it is an Apple bug. If you look at an Apple documentation [1] about "Placing content in a bundle" you will see highlighted important message that you should not put content in the wrong location.

[1] https://developer.apple.com/documentation/bundleresources/placing_content_in_a_bundle?language=objc

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19377#issuecomment-2142981609

From bchristi at openjdk.org  Fri May 31 21:32:30 2024
From: bchristi at openjdk.org (Brent Christian)
Date: Fri, 31 May 2024 21:32:30 GMT
Subject: Integrated: 8314480: Memory ordering spec updates in java.lang.ref
In-Reply-To: <R74ontYwjYg6HeZY0cWrlo0amjl4E1YsFWeuh4pda14=.08ac62df-b2f8-4b4d-b338-07adb289601b@github.com>
References: <R74ontYwjYg6HeZY0cWrlo0amjl4E1YsFWeuh4pda14=.08ac62df-b2f8-4b4d-b338-07adb289601b@github.com>
Message-ID: <vcFuzfIXa6aWTczReQfIMVJbHEUyXjtl7HRg9-ZAPkw=.20cebd04-af43-4721-98e4-4b69e329e3b0@github.com>

On Mon, 13 Nov 2023 22:31:16 GMT, Brent Christian <bchristi at openjdk.org> wrote:

> Classes in the `java.lang.ref` package would benefit from an update to bring the spec in line with how the VM already behaves. The changes would focus on _happens-before_ edges at some key points during reference processing.
> 
> A couple key things we want to be able to say are:
> - `Reference.reachabilityFence(x)` _happens-before_ reference processing occurs for 'x'.
> - `Cleaner.register()` _happens-before_ the Cleaner thread runs the registered cleaning action.
> 
> This will bring Cleaner in line (or close) with the memory visibility guarantees made for finalizers in [JLS 17.4.5](https://docs.oracle.com/javase/specs/jls/se18/html/jls-17.html#jls-17.4.5):
> _"There is a happens-before edge from the end of a constructor of an object to the start of a finalizer (?12.6) for that object."_

This pull request has now been integrated.

Changeset: 2cae9a03
Author:    Brent Christian <bchristi at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/2cae9a0397f4e46c6faec0a998ecad1c7015564d
Stats:     229 lines in 4 files changed: 132 ins; 19 del; 78 mod

8314480: Memory ordering spec updates in java.lang.ref

Reviewed-by: dholmes, alanb, darcy

-------------

PR: https://git.openjdk.org/jdk/pull/16644

From nlisker at openjdk.org  Fri May 31 21:40:13 2024
From: nlisker at openjdk.org (Nir Lisker)
Date: Fri, 31 May 2024 21:40:13 GMT
Subject: RFR: 8332110: [macos] jpackage tries to sign added files without
 the --mac-sign option [v2]
In-Reply-To: <HI6HYfkNrR1fV5fKnQbAwk-TUWPhRjYIEfdnosvAZ60=.b205f7ba-d2c8-46bc-b192-439d318df63f@github.com>
References: <eiboU_LgwkTte_7rkPJAdDm1x_-Pzm8rdwUiY_4MAYI=.b982e161-fe24-44ab-9db5-2f1d80eb0d99@github.com>
 <HI6HYfkNrR1fV5fKnQbAwk-TUWPhRjYIEfdnosvAZ60=.b205f7ba-d2c8-46bc-b192-439d318df63f@github.com>
Message-ID: <IHcGMmiYJrbHZlmnyh0mMTJbGyQtm6F2qhScXR2CWco=.f52f6c80-21e3-405e-979c-8b8a6fc10af7@github.com>

On Thu, 30 May 2024 22:54:12 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

>> This issue is reproducible with and without `--mac-sign`. jpackage will "_ad-hoc_" sign application bundle when `--mac-sign` is not specified by using pseudo-identity "_-_". This is why jpackage tries to sign added files and this is expected behavior by jpackage. "codesign" fails since added content made application bundle structure invalid. There is nothing we can do on jpackage side to sign such invalid bundles. As proposed solution we will output possible reason for "codesign" failure if it fails and `--app-content` was specified and possible solution. Proposed message: "One of the possible reason for "codesign" failure is additional content provided via "--app-content", which made application bundle structure invalid. Make sure to provide additional content in a way it will not break application bundle structure, otherwise add additional content as post-processing step."
>> 
>> Example:
>> Lets assume we have "ReadMe" folder with "ReadMe.txt" file in it.
>> 1) jpackage --type app-image -n Test --app-content ReadMe/ReadMe.txt ...
>> "codesign" will fail with "In subcomponent: Test.app/Contents/ReadMe.txt". This is expected and "ReadMe.txt" placed in "Test.app/Contents" which is also expected.
>> 2) jpackage --type app-image -n Test --app-content ReadMe ...
>> Works and "ReadMe.txt" will be placed under "Test.app/Contents/ReadMe".
>> 
>> Sample output before fix:
>> 
>> Error: "codesign" failed with following output:
>> Test.app: replacing existing signature
>> Test.app: code object is not signed at all
>> In subcomponent: Test.app/Contents/ReadMe.txt
>> 
>> 
>> Sample output after fix:
>> 
>> "codesign" failed and additional application content was supplied via the "--app-content" parameter. Probably the additional content broke the integrity of the application bundle and caused the failure. Ensure content supplied via the "--app-content" parameter does not break the integrity of the application bundle, or add it in the post-processing step.
>> Error: "codesign" failed with following output:
>> Test.app: replacing existing signature
>> Test.app: code object is not signed at all
>> In subcomponent: Test.app/Contents/ReadMe.txt
>
> Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8332110: jpackage tries to sign added files without the --mac-sign option [v2]

I see, but it doesn't say where to put license files, which are usually in the root. Do you know where these belong?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19377#issuecomment-2143012428

From almatvee at openjdk.org  Fri May 31 21:54:13 2024
From: almatvee at openjdk.org (Alexander Matveev)
Date: Fri, 31 May 2024 21:54:13 GMT
Subject: RFR: 8332110: [macos] jpackage tries to sign added files without
 the --mac-sign option [v2]
In-Reply-To: <IHcGMmiYJrbHZlmnyh0mMTJbGyQtm6F2qhScXR2CWco=.f52f6c80-21e3-405e-979c-8b8a6fc10af7@github.com>
References: <eiboU_LgwkTte_7rkPJAdDm1x_-Pzm8rdwUiY_4MAYI=.b982e161-fe24-44ab-9db5-2f1d80eb0d99@github.com>
 <HI6HYfkNrR1fV5fKnQbAwk-TUWPhRjYIEfdnosvAZ60=.b205f7ba-d2c8-46bc-b192-439d318df63f@github.com>
 <IHcGMmiYJrbHZlmnyh0mMTJbGyQtm6F2qhScXR2CWco=.f52f6c80-21e3-405e-979c-8b8a6fc10af7@github.com>
Message-ID: <RU4IUwwYsJRt-e1HbOEid_bRVYbkP-kxTD-x1gc66WY=.28c60a94-513f-4589-9bde-d4809db66b56@github.com>

On Fri, 31 May 2024 21:36:56 GMT, Nir Lisker <nlisker at openjdk.org> wrote:

> I see, but it doesn't say where to put license files, which are usually in the root. Do you know where these belong?

No idea.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19377#issuecomment-2143025767

From jjg at openjdk.org  Fri May 31 22:19:14 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Fri, 31 May 2024 22:19:14 GMT
Subject: Integrated: 8331879: Clean up non-standard use of /// comments in
 `java.base`
In-Reply-To: <BiSTG8MtjyRt2txRK2DIxsmbPPq6Pvp7QQzOnHXbH6w=.b01b4872-dc8b-4e4f-bae6-bdc501da33a6@github.com>
References: <BiSTG8MtjyRt2txRK2DIxsmbPPq6Pvp7QQzOnHXbH6w=.b01b4872-dc8b-4e4f-bae6-bdc501da33a6@github.com>
Message-ID: <nYpGLq4WNF5Bhs3N-0BGguqc9QiFmtf6nWbjRMhtpnA=.0ca9d6e4-a645-4850-b59d-e552e278b182@github.com>

On Tue, 7 May 2024 22:23:48 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> With the advent of JEP 467, `///` comments may be treated as documentation comments, and may be subject to the recently new `javac` warning about "dangling doc comments" in unexpected places.
> 
> In keeping with the policy to keep the `java.base` module free of all `javac` warnings, this patch proposes edits to existing uses of `///`.
> 
> There are two dominant policies in the proposed changes. 
> 1. A long horizontal line of `/////` is replaced by `//-----`
> 2. A long vertical series of lines beginning `///` is replaced by lines beginning `//|`.
> 
> As with all style changes, I have also tried to honor local usage, for consistency.
> 
> In one place, a pair of comments appeared to contain directives (`CLOVER:ON`, `CLOVER:OFF`).  I investigated the use of such comments to determine that the exact form of the comment prefix was not significant. (Phew!)
> 
> 
> (This PR is informally blocked by JEP 467).

This pull request has now been integrated.

Changeset: 10eb1cb6
Author:    Jonathan Gibbons <jjg at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/10eb1cb639095caa2636cc87c45201d4f8cf1eb4
Stats:     117 lines in 25 files changed: 0 ins; 0 del; 117 mod

8331879: Clean up non-standard use of /// comments in `java.base`

Reviewed-by: naoto, iris, darcy

-------------

PR: https://git.openjdk.org/jdk/pull/19130

From duke at openjdk.org  Fri May 31 22:29:50 2024
From: duke at openjdk.org (ExE Boss)
Date: Fri, 31 May 2024 22:29:50 GMT
Subject: RFR: 8333377: Migrate Generic Signature parsing to ClassFile API
In-Reply-To: <8_XK2UpYcewLX40oL3TS0T7KGAgfBprN4aauvhVQBy4=.420255be-10a3-4a64-bac9-491b21983265@github.com>
References: <8_XK2UpYcewLX40oL3TS0T7KGAgfBprN4aauvhVQBy4=.420255be-10a3-4a64-bac9-491b21983265@github.com>
Message-ID: <RiWnDKZXRqmiMGnw6-P2jUJ2AZ8BfRYvELI3K_c2f9U=.eb2e7a79-71c2-49b0-9290-782fc530e1f6@github.com>

On Fri, 17 May 2024 12:01:23 GMT, Chen Liang <liach at openjdk.org> wrote:

> Core reflection's generic signature parsing uses an ancient library with outdated visitor pattern on a tree model and contains unnecessary boilerplates. This is a duplication of ClassFile API's signature model. We should just move to ClassFile API, which is more throughoutly tested as well.
> 
> To ensure compatibility, new tests are added to ensure consistent behavior when encountering malformed signatures or signatures with missing types. The reflective objects have been preserved and the only change is that lazy expansion now happens from CF objects, to reduce compatibility risks.

src/java.base/share/classes/java/lang/Class.java line 3487:

> 3485: 
> 3486:     // Generic info repository; lazily initialized
> 3487:     private transient volatile @Stable ClassGenericInfo<T> genericInfo;

I?don?t think this?field can?be?`@Stable`, as?generic signatures can?change when a?class gets redefined by?**JVM?TI**, just?like [simple][Class?::getSimpleName()] and?[canonical?names][Class?::getCanonicalName()].
https://github.com/openjdk/jdk/blob/8acdd2d7c8de17515b87815d54ce556237039406/src/java.base/share/classes/java/lang/Class.java#L3452-L3454

[Class?::getSimpleName()]: https://docs.oracle.com/en/java/javase/22/docs/api/java.base/java/lang/Class.html#getSimpleName()
[Class?::getCanonicalName()]: https://docs.oracle.com/en/java/javase/22/docs/api/java.base/java/lang/Class.html#getCanonicalName()

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19281#discussion_r1605677886

From liach at openjdk.org  Fri May 31 22:29:50 2024
From: liach at openjdk.org (Chen Liang)
Date: Fri, 31 May 2024 22:29:50 GMT
Subject: RFR: 8333377: Migrate Generic Signature parsing to ClassFile API
Message-ID: <8_XK2UpYcewLX40oL3TS0T7KGAgfBprN4aauvhVQBy4=.420255be-10a3-4a64-bac9-491b21983265@github.com>

Core reflection's generic signature parsing uses an ancient library with outdated visitor pattern on a tree model and contains unnecessary boilerplates. This is a duplication of ClassFile API's signature model. We should just move to ClassFile API, which is more throughoutly tested as well.

To ensure compatibility, new tests are added to ensure consistent behavior when encountering malformed signatures or signatures with missing types. The reflective objects have been preserved and the only change is that lazy expansion now happens from CF objects, to reduce compatibility risks.

-------------

Commit messages:
 - Remove redundant try-catch in getEnclosingMethod/Constructor
 - Merge branch 'test/signature-error' into feature/new-generic-info
 - Fix everything
 - Fixxes
 - Stage
 - Stage new tests
 - Merge branch 'master' of https://github.com/openjdk/jdk into feature/new-generic-info
 - Merge branch 'master' of https://github.com/openjdk/jdk into feature/new-generic-info
 - Merge branch 'master' of https://github.com/openjdk/jdk into feature/new-generic-info
 - Merge branch 'master' of https://github.com/openjdk/jdk into feature/new-generic-info
 - ... and 5 more: https://git.openjdk.org/jdk/compare/8aeada10...4110c13f

Changes: https://git.openjdk.org/jdk/pull/19281/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19281&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8333377
  Stats: 4605 lines in 66 files changed: 1027 ins; 3483 del; 95 mod
  Patch: https://git.openjdk.org/jdk/pull/19281.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19281/head:pull/19281

PR: https://git.openjdk.org/jdk/pull/19281

From liach at openjdk.org  Fri May 31 22:29:50 2024
From: liach at openjdk.org (Chen Liang)
Date: Fri, 31 May 2024 22:29:50 GMT
Subject: RFR: 8333377: Migrate Generic Signature parsing to ClassFile API
In-Reply-To: <RiWnDKZXRqmiMGnw6-P2jUJ2AZ8BfRYvELI3K_c2f9U=.eb2e7a79-71c2-49b0-9290-782fc530e1f6@github.com>
References: <8_XK2UpYcewLX40oL3TS0T7KGAgfBprN4aauvhVQBy4=.420255be-10a3-4a64-bac9-491b21983265@github.com>
 <RiWnDKZXRqmiMGnw6-P2jUJ2AZ8BfRYvELI3K_c2f9U=.eb2e7a79-71c2-49b0-9290-782fc530e1f6@github.com>
Message-ID: <1hET4GxxgfRGp29qGoa_-vs4OgaPob6ceQgnWiX1Ihk=.66121930-ee5a-4ff0-a891-0807da213e98@github.com>

On Sat, 18 May 2024 05:24:16 GMT, ExE Boss <duke at openjdk.org> wrote:

>> Core reflection's generic signature parsing uses an ancient library with outdated visitor pattern on a tree model and contains unnecessary boilerplates. This is a duplication of ClassFile API's signature model. We should just move to ClassFile API, which is more throughoutly tested as well.
>> 
>> To ensure compatibility, new tests are added to ensure consistent behavior when encountering malformed signatures or signatures with missing types. The reflective objects have been preserved and the only change is that lazy expansion now happens from CF objects, to reduce compatibility risks.
>
> src/java.base/share/classes/java/lang/Class.java line 3487:
> 
>> 3485: 
>> 3486:     // Generic info repository; lazily initialized
>> 3487:     private transient volatile @Stable ClassGenericInfo<T> genericInfo;
> 
> I?don?t think this?field can?be?`@Stable`, as?generic signatures can?change when a?class gets redefined by?**JVM?TI**, just?like [simple][Class?::getSimpleName()] and?[canonical?names][Class?::getCanonicalName()].
> https://github.com/openjdk/jdk/blob/8acdd2d7c8de17515b87815d54ce556237039406/src/java.base/share/classes/java/lang/Class.java#L3452-L3454
> 
> [Class?::getSimpleName()]: https://docs.oracle.com/en/java/javase/22/docs/api/java.base/java/lang/Class.html#getSimpleName()
> [Class?::getCanonicalName()]: https://docs.oracle.com/en/java/javase/22/docs/api/java.base/java/lang/Class.html#getCanonicalName()

Existing genericInfo is not part of ReflectionData. The migration of genericInfo into reflectionData should be done in a separate task.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19281#discussion_r1605781541

From darcy at openjdk.org  Fri May 31 22:45:02 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 31 May 2024 22:45:02 GMT
Subject: RFR: 8333377: Migrate Generic Signature parsing to ClassFile API
In-Reply-To: <8_XK2UpYcewLX40oL3TS0T7KGAgfBprN4aauvhVQBy4=.420255be-10a3-4a64-bac9-491b21983265@github.com>
References: <8_XK2UpYcewLX40oL3TS0T7KGAgfBprN4aauvhVQBy4=.420255be-10a3-4a64-bac9-491b21983265@github.com>
Message-ID: <eaj0XcjDfrQdqFDopubQgkebF72XYfd0nkNzNtxE6nA=.b822a954-1541-41b0-b8d7-47fcc59b85fa@github.com>

On Fri, 17 May 2024 12:01:23 GMT, Chen Liang <liach at openjdk.org> wrote:

> Core reflection's generic signature parsing uses an ancient library with outdated visitor pattern on a tree model and contains unnecessary boilerplates. This is a duplication of ClassFile API's signature model. We should just move to ClassFile API, which is more throughoutly tested as well.
> 
> To ensure compatibility, new tests are added to ensure consistent behavior when encountering malformed signatures or signatures with missing types. The reflective objects have been preserved and the only change is that lazy expansion now happens from CF objects, to reduce compatibility risks.

I think I'll need to be one of the reviews on this, but don't anticipate being able to review it before JDK 23 rampdown. Therefore, I think this would be appropriate to be targeted to JDK 24.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19281#issuecomment-2143066139

From mik3hall at gmail.com  Fri May 31 23:05:04 2024
From: mik3hall at gmail.com (Michael Hall)
Date: Fri, 31 May 2024 18:05:04 -0500
Subject: RFR: 8332110: [macos] jpackage tries to sign added files without
 the --mac-sign option [v2]
In-Reply-To: <IHcGMmiYJrbHZlmnyh0mMTJbGyQtm6F2qhScXR2CWco=.f52f6c80-21e3-405e-979c-8b8a6fc10af7@github.com>
References: <eiboU_LgwkTte_7rkPJAdDm1x_-Pzm8rdwUiY_4MAYI=.b982e161-fe24-44ab-9db5-2f1d80eb0d99@github.com>
 <HI6HYfkNrR1fV5fKnQbAwk-TUWPhRjYIEfdnosvAZ60=.b205f7ba-d2c8-46bc-b192-439d318df63f@github.com>
 <IHcGMmiYJrbHZlmnyh0mMTJbGyQtm6F2qhScXR2CWco=.f52f6c80-21e3-405e-979c-8b8a6fc10af7@github.com>
Message-ID: <E44C990E-5A04-4722-9AD8-2F9BC18001E7@gmail.com>

Yes you can file an Apple bug report but I think these days it requires a developer account to get to the bug reporter.

The indicated documentation doesn?t mention anything about your own files/directories. So I think a bug report might be appropriate. One in but the other out doesn?t seem right.

I used to have my own directory in an application but that was pre-jpackage. And prior to Apple?s incremental security crack-downs with Gatekeeper. I think I had code with special class loading requirements where I wanted to load it outside class path. 

My app no longer includes that. I have a resources jar where I dump all my miscellaneous and retrieve them from there.

> On May 31, 2024, at 4:40?PM, Nir Lisker <nlisker at openjdk.org> wrote:
> 
> 
> I see, but it doesn't say where to put license files, which are usually in the root. Do you know where these belong?
> 
> -------------
> 
> PR Comment: https://git.openjdk.org/jdk/pull/19377#issuecomment-2143012428

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240531/7b1e385f/attachment.htm>

From asemenyuk at openjdk.org  Fri May 31 23:56:09 2024
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Fri, 31 May 2024 23:56:09 GMT
Subject: RFR: 8331977: Crash: SIGSEGV in dlerror()
Message-ID: <ZJ-3CSix-7KDLyG4pkBY38ompRlk8InxhIPsmJy-NGQ=.a6984371-8759-4165-863d-491e10e25cab@github.com>

Fix MainClassTest class to use HelloApp.AppOutputVerifier class to run app launcher instead of raw Executor. This makes MainClassTest test run app launchers with retries. This change addresses the primary issue.

Fix inconsistencies in HelloApp.AppOutputVerifier class. It used to provide API allowing to run launchers without retries. It inconsistently allowed the execution of launchers with suppressed output (stdout and stderr). It inconsistently executed launchers with/without PATH removed from the environment.

These loopholes were eliminated:

 - stdout and stderr of app launchers is never suppressed;
 - PATH env variable is always deleted for app launchers on Windows. It is not deleted on other platforms. This change sets the correct scope of [JDK-8254920](https://bugs.openjdk.org/browse/JDK-8254920) fix that introduced the removal of PATH env variable for app launchers;
 - app launchers are always executed with retries unless the launcher is executed with `jpackage.test.noexit` system property set to `true` indicating the test app will not terminate on its own.

Other changes are due to changes in HelloApp.AppOutputVerifier class.

-------------

Commit messages:
 - Trailing spaces removed.
 - Run app launcher with retries if "jpackage.test.noexit" jpackage java option is not set or set to "false".  Otherwise run app launcher without retries. If the launcher never exits (jpackage.test.noexit=true), it should be terminated externally and thus it should not be restarted.
 - 8331977: Crash: SIGSEGV in dlerror()

Changes: https://git.openjdk.org/jdk/pull/19502/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19502&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8331977
  Stats: 122 lines in 5 files changed: 48 ins; 41 del; 33 mod
  Patch: https://git.openjdk.org/jdk/pull/19502.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19502/head:pull/19502

PR: https://git.openjdk.org/jdk/pull/19502

From asemenyuk at openjdk.org  Fri May 31 23:56:09 2024
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Fri, 31 May 2024 23:56:09 GMT
Subject: RFR: 8331977: Crash: SIGSEGV in dlerror()
In-Reply-To: <ZJ-3CSix-7KDLyG4pkBY38ompRlk8InxhIPsmJy-NGQ=.a6984371-8759-4165-863d-491e10e25cab@github.com>
References: <ZJ-3CSix-7KDLyG4pkBY38ompRlk8InxhIPsmJy-NGQ=.a6984371-8759-4165-863d-491e10e25cab@github.com>
Message-ID: <wJfQrx4uOnWBbi2SNQandsRgubhvI3foUWK-UwnANLw=.03d4abd0-9364-479d-829c-62b8c42b45f5@github.com>

On Fri, 31 May 2024 14:05:07 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> Fix MainClassTest class to use HelloApp.AppOutputVerifier class to run app launcher instead of raw Executor. This makes MainClassTest test run app launchers with retries. This change addresses the primary issue.
> 
> Fix inconsistencies in HelloApp.AppOutputVerifier class. It used to provide API allowing to run launchers without retries. It inconsistently allowed the execution of launchers with suppressed output (stdout and stderr). It inconsistently executed launchers with/without PATH removed from the environment.
> 
> These loopholes were eliminated:
> 
>  - stdout and stderr of app launchers is never suppressed;
>  - PATH env variable is always deleted for app launchers on Windows. It is not deleted on other platforms. This change sets the correct scope of [JDK-8254920](https://bugs.openjdk.org/browse/JDK-8254920) fix that introduced the removal of PATH env variable for app launchers;
>  - app launchers are always executed with retries unless the launcher is executed with `jpackage.test.noexit` system property set to `true` indicating the test app will not terminate on its own.
> 
> Other changes are due to changes in HelloApp.AppOutputVerifier class.

@sashamatveev please review

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19502#issuecomment-2143129082