From bhuang at openjdk.org  Wed Feb  1 01:12:10 2023
From: bhuang at openjdk.org (Bill Huang)
Date: Wed, 1 Feb 2023 01:12:10 GMT
Subject: RFR: JDK-8299994: java/security/Policy/Root/Root.java fails when
 home directory is read-only [v3]
In-Reply-To: <qIGOmJu4rLPxuoDW-zteCD-5kapxMWxc2k6ra3kgXpA=.64cb7150-e0d1-4f6e-82ae-3641c0f1d772@github.com>
References: <qIGOmJu4rLPxuoDW-zteCD-5kapxMWxc2k6ra3kgXpA=.64cb7150-e0d1-4f6e-82ae-3641c0f1d772@github.com>
Message-ID: <QZp6qCcVISsTilYS14cUoWRCS6-siVnPC2EPhgZYviY=.203fd96b-3914-4b77-8ad3-9a97c48b4199@github.com>

> Root.java is changed to a manual test because it requires test to be run with the root user privilege, and it requires to modify the user policy file in the home director.

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

  Check root privilege with user id instead of user name.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12354/files
  - new: https://git.openjdk.org/jdk/pull/12354/files/60096f09..3b736036

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

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

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

From duke at openjdk.org  Wed Feb  1 01:51:53 2023
From: duke at openjdk.org (Tingjun Yuan)
Date: Wed, 1 Feb 2023 01:51:53 GMT
Subject: RFR: 8301043: Super-interface for PrintStream and PrintWriter [v2]
In-Reply-To: <sX4X8nZjKTGw0yl57z0je-WYaRR_f2X7Jie2-KSZh2M=.58338e02-03f5-4549-9f52-4f36eb21c1f5@github.com>
References: <LZBf71PPG8_HkJLPL4e77q_kNrIOjN_BS8E8fTPf7uQ=.8ba39988-a57d-4434-a417-b3b6e1b990ed@github.com>
 <xTErOK11Mr6m5rqaPi7DJST19ELDDDK3Y3WlXmttntQ=.fbe84fc0-b5b6-4b9e-a94d-58ffcf6e898f@github.com>
 <sX4X8nZjKTGw0yl57z0je-WYaRR_f2X7Jie2-KSZh2M=.58338e02-03f5-4549-9f52-4f36eb21c1f5@github.com>
Message-ID: <IJPEvsGaCZBeEkwRR1Lcw8pT_ifrgWulkSmM_9zenLI=.6fab1f76-4e3a-4943-942d-a21a981b3e7d@github.com>

On Tue, 31 Jan 2023 18:28:59 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> A PR may be a bit premature as this probably needs discussion first on whether this is worth doing. Yes, there are common methods between the two but at the same time, the byte and character hierarchies have always been distinct. Have you encountered many libraries with overloads for PrintStream and PrintWriter?

I see, I'm the submitter of the issue and I created this PR for discussion and evaluation. I apologize for any confusion and thank you again for commenting. I will evaluate further whether it's worth and reasonable doing this.

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

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

From duke at openjdk.org  Wed Feb  1 02:10:36 2023
From: duke at openjdk.org (Glavo)
Date: Wed, 1 Feb 2023 02:10:36 GMT
Subject: RFR: 8301569: list mode of jmod and jimage cannot be used normally in
 turkish locale
Message-ID: <v0uxR1eF4vFNvA8DMLlwG1x2M-oH3o-xTJgKPs25UNA=.35fe243b-db18-42b6-b32b-115b649340f6@github.com>

When the default Locale is `tr`, the jmod and jimage commands have the following problems:

* The jmod command does not correctly recognize the `list` mode typed in lowercase;
* The jimage command cannot obtain the help information of the `list` mode.

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

Commit messages:
 - list mode of jmod and jimage cannot be used normally in turkish locale

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

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

From duke at openjdk.org  Wed Feb  1 02:10:36 2023
From: duke at openjdk.org (Glavo)
Date: Wed, 1 Feb 2023 02:10:36 GMT
Subject: RFR: 8301569: list mode of jmod and jimage cannot be used normally
 in turkish locale
In-Reply-To: <v0uxR1eF4vFNvA8DMLlwG1x2M-oH3o-xTJgKPs25UNA=.35fe243b-db18-42b6-b32b-115b649340f6@github.com>
References: <v0uxR1eF4vFNvA8DMLlwG1x2M-oH3o-xTJgKPs25UNA=.35fe243b-db18-42b6-b32b-115b649340f6@github.com>
Message-ID: <urKhB25OcB0cL8GsImcRZhD_yALNP8Hz1lXTwFJmDbo=.5318961c-5bbe-4be3-8811-af22b1415a83@github.com>

On Sun, 29 Jan 2023 15:37:28 GMT, Glavo <duke at openjdk.org> wrote:

> When the default Locale is `tr`, the jmod and jimage commands have the following problems:
> 
> * The jmod command does not correctly recognize the `list` mode typed in lowercase;
> * The jimage command cannot obtain the help information of the `list` mode.

There are some similar hidden dangers in OpenJDK. I hope to clean them up.

These hidden dangers are scattered in many modules. Should I solve them in multiple PRs?

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

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

From duke at openjdk.org  Wed Feb  1 05:04:50 2023
From: duke at openjdk.org (Amit Kumar)
Date: Wed, 1 Feb 2023 05:04:50 GMT
Subject: RFR: 8299748: java/util/zip/Deinflate.java failing on s390x
In-Reply-To: <52ZwQHgwsqpLSXlv9x2J7ognWkJ87ZIKJd-6Aj6Gxzs=.92bbbdc3-ebd5-4c78-ae50-704292a2505e@github.com>
References: <Usxi4wE5GSHHv-cKPfW6OXylhieAypbsidUX_Jo6FSQ=.34104cf0-2243-478f-86ce-9a91905c6755@github.com>
 <ZtgFFDxBrJ1Ta7wIsprcHMbKzPCCmpNpNv-QENRIyGg=.5446f8e2-d3b1-4276-a255-b911871a471a@github.com>
 <n9yyttjOa9MR3Q2sqNd4qlyiQBof4NdFFbeH5U6Ll1k=.88010c9d-59cd-47ee-8bab-e85c48453cf4@github.com>
 <52ZwQHgwsqpLSXlv9x2J7ognWkJ87ZIKJd-6Aj6Gxzs=.92bbbdc3-ebd5-4c78-ae50-704292a2505e@github.com>
Message-ID: <wKbgZtx_hBWOMerEsgsg79sVmc1aGSgvf5V5FpBN0pY=.ab8ab79a-09b1-4c04-b078-f711da56341c@github.com>

On Tue, 31 Jan 2023 09:00:18 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Hi @jaikiran ,
>> On my system OS's zlib is being used. and here is stack-trace.
>> 
>> ----------System.out:(2/78)----------
>> level:-1, strategy: 0, dowrap: false
>> m=525312, n=498060, len=524288, eq=false
>> ----------System.err:(11/585)----------
>> java.lang.RuntimeException: De/inflater failed:java.util.zip.Deflater at 5ce95579
>>     at DeInflate.check(DeInflate.java:141)
>>     at DeInflate.main(DeInflate.java:290)
>>     at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
>>     at java.base/java.lang.reflect.Method.invoke(Method.java:578)
>>     at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:312)
>>     at java.base/java.lang.Thread.run(Thread.java:1623)
>> 
>> JavaTest Message: Test threw exception: java.lang.RuntimeException
>> JavaTest Message: shutting down test
>> 
>> result: Failed. Execution failed: `main' threw exception: java.lang.RuntimeException: De/inflater failed:java.util.zip.Deflater at 5ce95579
>> 
>> test result: Failed. Execution failed: `main' threw exception: java.lang.RuntimeException: De/inflater failed:java.util.zip.Deflater at 5ce95579
>
>> m=525312, n=498060, len=524288, eq=false
> 
> The test doesn't print this so I assume this is tracing that you added in your runs. If I read it correctly, the initial input is len=524288, it deflates to m=525312, then re-inflates to n=498060. So it looks like it has been truncated. Would it be possible to print out the value of inf.getRemaining()?  I'm wondering if the test needs to be changed to call inflate in a loop until there are no remaining bytes.

Hi @AlanBateman ,
I haven't done any modification in the test/build. The info is being printed by the test itself. `m, n, len, eq` are printed just before the exception raised. 

I tried to use `inf.getRemaining()` (after restoring back to original file) and In my case it returns `0`, and then test fails.
Changes I test with: 

diff --git a/test/jdk/java/util/zip/DeInflate.java b/test/jdk/java/util/zip/DeInflate.java
index a6a749fda83..d334903e5dc 100644
--- a/test/jdk/java/util/zip/DeInflate.java
+++ b/test/jdk/java/util/zip/DeInflate.java
@@ -132,7 +132,7 @@ public class DeInflate {
         Inflater inf = new Inflater(nowrap);
         inf.setInput(out1, 0, m);
         int n = inf.inflate(out2);
-
+        System.out.println("remaining data: " + inf.getRemaining());
         if (n != len ||
             !Arrays.equals(Arrays.copyOf(in, len), Arrays.copyOf(out2, len)) ||
             inf.inflate(out2) != 0) {

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

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

From dholmes at openjdk.org  Wed Feb  1 06:20:49 2023
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 1 Feb 2023 06:20:49 GMT
Subject: RFR: 8300917: Regression 2x and bimodal startup on Mac aarch64 in
 b27
In-Reply-To: <AXAsqyTdLlz7c_RI-soi4AmkqJDG-laNLbzTVxnmbZU=.35fd56bf-abd5-4aa3-aaee-8a9f7f11eb0a@github.com>
References: <AXAsqyTdLlz7c_RI-soi4AmkqJDG-laNLbzTVxnmbZU=.35fd56bf-abd5-4aa3-aaee-8a9f7f11eb0a@github.com>
Message-ID: <ZqJ-knniiJOt-Fg6DK0ChDSARlVQfT5loXLSHOS6Dig=.4b97be21-50cf-4316-b541-fb6b334aae49@github.com>

On Wed, 25 Jan 2023 12:26:26 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR proposed to reduce contention in synchronized methods mainly by doing I/O operations outside synch blocks.

I can't quite see the effect of the change here. You went from a synchronized instance method, to a non-synchronized static method which then immediately synchronizes on the passed in instance. ??

That aside I'm not sure what the synchronization issues are here - isn't setting the native access bit an idempotent operation?

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

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

From duke at openjdk.org  Wed Feb  1 07:14:55 2023
From: duke at openjdk.org (Viktor Klang)
Date: Wed, 1 Feb 2023 07:14:55 GMT
Subject: RFR: 8301552: Use AtomicReferenceArray for caching instead of CHM
 in ZoneOffset
In-Reply-To: <1su0_EK4Sx_blL9MQLS7147NWLaYH80QCSvM2iyV7h4=.6c053033-45ce-4234-912c-3de05ee0ef46@github.com>
References: <b228oWPoEJf0lfGgIVXwmo1mATeKWRTivuJ2PbgwAmI=.465a4f9b-7a4b-4bbb-9f94-66d1d889a072@github.com>
 <1su0_EK4Sx_blL9MQLS7147NWLaYH80QCSvM2iyV7h4=.6c053033-45ce-4234-912c-3de05ee0ef46@github.com>
Message-ID: <NAyN1NNVtwqZo__rU87kBdCzJovXOLv-_gM7S1R4BeU=.4ea64600-7f83-4595-807d-007ed53229f0@github.com>

On Tue, 31 Jan 2023 16:02:07 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> `ZoneOffset` instances are cached by the `ZoneOffset` class itself for values in the range [-18h, 18h] for each second that is on an even quarter of an hour (i.e. at most 2*18*4+1 = 145 values). 
>> 
>> Instead of using a `ConcurrentHashMap` for caching instanced, we could instead use an `AtomicReferenceArray` with direct slot value access for said even seconds. This will improve performance and reduce the number of object even though the backing array will go from an initial 32 in the CHM to an initial/final 145 in the ARA. The CHM will contain much more objects and array slots for typical numbers of entries in the cache and will compute hash/bucket/collision on the hot code path for each cache access.
>
> src/java.base/share/classes/java/time/ZoneOffset.java line 432:
> 
>> 430:         if (totalSeconds % (15 * SECONDS_PER_MINUTE) == 0) {
>> 431:             int slot = cacheSlot(totalSeconds);
>> 432:             ZoneOffset cached = SECONDS_CACHE.get(slot);
> 
> I miss `AtomicReferenceArray::computeIfNull` that atomically will compute an element if the value at a certain index is `null`.

@minborg You could compareAndExchange in a CompletableFuture?if you succeed you can complete it with the computation (bonus points since the computation can be done async) and if you fail you get either a value or a CompletableFuture you can decide if you want to block on it, and for how long?

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

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

From alanb at openjdk.org  Wed Feb  1 07:14:55 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 1 Feb 2023 07:14:55 GMT
Subject: RFR: 8300917: Regression 2x and bimodal startup on Mac aarch64 in
 b27
In-Reply-To: <ZqJ-knniiJOt-Fg6DK0ChDSARlVQfT5loXLSHOS6Dig=.4b97be21-50cf-4316-b541-fb6b334aae49@github.com>
References: <AXAsqyTdLlz7c_RI-soi4AmkqJDG-laNLbzTVxnmbZU=.35fd56bf-abd5-4aa3-aaee-8a9f7f11eb0a@github.com>
 <ZqJ-knniiJOt-Fg6DK0ChDSARlVQfT5loXLSHOS6Dig=.4b97be21-50cf-4316-b541-fb6b334aae49@github.com>
Message-ID: <e6KiKjEmQSRZlewocxWpXkrFjVItLGV-iWlnm9PfrBA=.4c7bc708-53d3-4fe6-b9ab-7c1744bd3d59@github.com>

On Wed, 1 Feb 2023 06:17:37 GMT, David Holmes <dholmes at openjdk.org> wrote:

> I can't quite see the effect of the change here. 

@minborg Have you used the wrong JBS issue by any chance? There is no information in the JBS issue, or here, that the proposed change fixes the reported startup regression after the JEP 434 integration and maybe this is a drive-by cleanup while investigating the startup issue?

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

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

From darcy at openjdk.org  Wed Feb  1 07:16:25 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 1 Feb 2023 07:16:25 GMT
Subject: RFR: JDK-8301392: Port fdlibm log1p to Java [v3]
In-Reply-To: <g8yhvnKZcwHr9U-z5SqNsw2vLN7ZbdeF8bgazG7eFE4=.326c60bb-81c6-449f-b9bc-8ca5bdcfde99@github.com>
References: <g8yhvnKZcwHr9U-z5SqNsw2vLN7ZbdeF8bgazG7eFE4=.326c60bb-81c6-449f-b9bc-8ca5bdcfde99@github.com>
Message-ID: <pcpvsJ0ZUyvcmd2rPRuiq9rgJEceqJM_XmAWY8F2Ww0=.95bc61bd-21ff-4adb-b858-f954c9481914@github.com>

> Another day, another PR to port FDLBIM to Java, this time for the log1p method.
> 
> Other than using the two-argument form of the __HI method in Java transliteration version rather than C macro, there are no appreciable differences between the original C source in 
> 
> src/java.base/share/native/libfdlibm/s_log1p.c
> 
> and the transliteration for testing purposes in
> 
> test/jdk/java/lang/StrictMath/FdlibmTranslit.java
> 
> The more idiomatic port in
> 
> src/java.base/share/classes/java/lang/FdLibm.java
> 
> has had a series of transformation applied layering on the transliteration. The intermediate commits show the progress.
> 
> The regression tests include probing around input values the implementation uses to decided which branch to take.

Joe Darcy has updated the pull request incrementally with two additional commits since the last revision:

 - Appease jcheck.
 - Fix typo; improve tests.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12301/files
  - new: https://git.openjdk.org/jdk/pull/12301/files/acd3693f..87a14ecc

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

  Stats: 30 lines in 2 files changed: 19 ins; 1 del; 10 mod
  Patch: https://git.openjdk.org/jdk/pull/12301.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12301/head:pull/12301

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

From stsypanov at openjdk.org  Wed Feb  1 07:19:19 2023
From: stsypanov at openjdk.org (Sergey Tsypanov)
Date: Wed, 1 Feb 2023 07:19:19 GMT
Subject: RFR: 8301492: Modernize equals() method of ResourceBundle.CacheKey
 and Bundles.CacheKey [v2]
In-Reply-To: <5xdnQZ8wLrkyB6U2miAOizqpvHGTFzy7OF_a24CUabc=.db6a65d7-9a29-44dc-94aa-692fbbfc82c7@github.com>
References: <5xdnQZ8wLrkyB6U2miAOizqpvHGTFzy7OF_a24CUabc=.db6a65d7-9a29-44dc-94aa-692fbbfc82c7@github.com>
Message-ID: <cWhV737xlTeebLP1pgncFuPqMC1X-IM_Y8-naZf-SnA=.6e0d306f-c6fc-40cc-bb10-d05cf1886fcd@github.com>

> `ResourceBundle.CacheKey.equals()` and `Bundles.CacheKey.equals()` are quire outdated. This simple clean-up modernizes them.

Sergey Tsypanov has updated the pull request incrementally with one additional commit since the last revision:

  Fix logic

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12328/files
  - new: https://git.openjdk.org/jdk/pull/12328/files/b74164a3..82b03202

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

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

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

From alanb at openjdk.org  Wed Feb  1 07:22:52 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 1 Feb 2023 07:22:52 GMT
Subject: RFR: 8301569: list mode of jmod and jimage cannot be used normally
 in turkish locale
In-Reply-To: <v0uxR1eF4vFNvA8DMLlwG1x2M-oH3o-xTJgKPs25UNA=.35fe243b-db18-42b6-b32b-115b649340f6@github.com>
References: <v0uxR1eF4vFNvA8DMLlwG1x2M-oH3o-xTJgKPs25UNA=.35fe243b-db18-42b6-b32b-115b649340f6@github.com>
Message-ID: <YGY2k5Yxc64cmMkwT71Tl2M8nzHXAO8_ATTSajL9DQI=.58727057-78b4-4d5a-900e-e35d1de444d3@github.com>

On Sun, 29 Jan 2023 15:37:28 GMT, Glavo <duke at openjdk.org> wrote:

> When the default Locale is `tr`, the jmod and jimage commands have the following problems:
> 
> * The jmod command does not correctly recognize the `list` mode typed in lowercase;
> * The jimage command cannot obtain the help information of the `list` mode.

src/jdk.jlink/share/classes/jdk/tools/jimage/JImageTask.java line 214:

> 212:                     try {
> 213:                         log.println(TASK_HELPER.getMessage("main.usage." +
> 214:                                 options.task.toString().toLowerCase(Locale.ROOT)));

This is the lookup of the main.usage.list resource (`jimage list --help`) rather than the `list` option but good to fix this anyway.

src/jdk.jlink/share/classes/jdk/tools/jmod/JmodTask.java line 1474:

> 1472:             String verb = words.get(0);
> 1473:             try {
> 1474:                 options.mode = Enum.valueOf(Mode.class, verb.toUpperCase(Locale.ROOT));

The equivalent in jlink and jimage are using Locale.ENGLISH, I guess we should try to keep them consistent.

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

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

From duke at openjdk.org  Wed Feb  1 07:23:50 2023
From: duke at openjdk.org (Viktor Klang)
Date: Wed, 1 Feb 2023 07:23:50 GMT
Subject: RFR: 8300917: Regression 2x and bimodal startup on Mac aarch64 in
 b27
In-Reply-To: <AXAsqyTdLlz7c_RI-soi4AmkqJDG-laNLbzTVxnmbZU=.35fd56bf-abd5-4aa3-aaee-8a9f7f11eb0a@github.com>
References: <AXAsqyTdLlz7c_RI-soi4AmkqJDG-laNLbzTVxnmbZU=.35fd56bf-abd5-4aa3-aaee-8a9f7f11eb0a@github.com>
Message-ID: <AYNubIzLfR_sqjBDcJ13qDBKsKlU9INSsnUNyiYZSUw=.02c4d0ff-f125-47b6-b25c-6ac83a0c8292@github.com>

On Wed, 25 Jan 2023 12:26:26 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR proposed to reduce contention in synchronized methods mainly by doing I/O operations outside synch blocks.

src/java.base/share/classes/java/lang/Module.java line 281:

> 279: 
> 280:     private static boolean isNativeAccessEnabled(Module target) {
> 281:         if (target.enableNativeAccess)

@minborg It'd seem a bit easier to implement using VarHandle and not having to use `synchronized`? Is the reason that you don't want to init VarHandle in this class? ?

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

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

From alanb at openjdk.org  Wed Feb  1 07:52:48 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 1 Feb 2023 07:52:48 GMT
Subject: RFR: 8299748: java/util/zip/Deinflate.java failing on s390x
In-Reply-To: <52ZwQHgwsqpLSXlv9x2J7ognWkJ87ZIKJd-6Aj6Gxzs=.92bbbdc3-ebd5-4c78-ae50-704292a2505e@github.com>
References: <Usxi4wE5GSHHv-cKPfW6OXylhieAypbsidUX_Jo6FSQ=.34104cf0-2243-478f-86ce-9a91905c6755@github.com>
 <ZtgFFDxBrJ1Ta7wIsprcHMbKzPCCmpNpNv-QENRIyGg=.5446f8e2-d3b1-4276-a255-b911871a471a@github.com>
 <n9yyttjOa9MR3Q2sqNd4qlyiQBof4NdFFbeH5U6Ll1k=.88010c9d-59cd-47ee-8bab-e85c48453cf4@github.com>
 <52ZwQHgwsqpLSXlv9x2J7ognWkJ87ZIKJd-6Aj6Gxzs=.92bbbdc3-ebd5-4c78-ae50-704292a2505e@github.com>
Message-ID: <0bGLJFdzULqbrLF1r-E57ZgDHAS7_C9UYxZDD-k9MYc=.3dc4be1e-b784-437c-90e3-26be2b541254@github.com>

On Tue, 31 Jan 2023 09:00:18 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Hi @jaikiran ,
>> On my system OS's zlib is being used. and here is stack-trace.
>> 
>> ----------System.out:(2/78)----------
>> level:-1, strategy: 0, dowrap: false
>> m=525312, n=498060, len=524288, eq=false
>> ----------System.err:(11/585)----------
>> java.lang.RuntimeException: De/inflater failed:java.util.zip.Deflater at 5ce95579
>>     at DeInflate.check(DeInflate.java:141)
>>     at DeInflate.main(DeInflate.java:290)
>>     at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
>>     at java.base/java.lang.reflect.Method.invoke(Method.java:578)
>>     at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:312)
>>     at java.base/java.lang.Thread.run(Thread.java:1623)
>> 
>> JavaTest Message: Test threw exception: java.lang.RuntimeException
>> JavaTest Message: shutting down test
>> 
>> result: Failed. Execution failed: `main' threw exception: java.lang.RuntimeException: De/inflater failed:java.util.zip.Deflater at 5ce95579
>> 
>> test result: Failed. Execution failed: `main' threw exception: java.lang.RuntimeException: De/inflater failed:java.util.zip.Deflater at 5ce95579
>
>> m=525312, n=498060, len=524288, eq=false
> 
> The test doesn't print this so I assume this is tracing that you added in your runs. If I read it correctly, the initial input is len=524288, it deflates to m=525312, then re-inflates to n=498060. So it looks like it has been truncated. Would it be possible to print out the value of inf.getRemaining()?  I'm wondering if the test needs to be changed to call inflate in a loop until there are no remaining bytes.

> Hi @AlanBateman , I haven't done any modification in the test/build. The info is being printed by the test itself. `m, n, len, eq` are printed just before the exception raised.
> 
> I tried to use `inf.getRemaining()` (after restoring back to original file) and In my case it returns `0`, and then test fails. Changes I test with:

Ah okay, so this suggests it's the deflate that is not compressing all the input. Would you mind just printing out the value of def.finished() after the deflate?

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

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

From pminborg at openjdk.org  Wed Feb  1 07:54:49 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 1 Feb 2023 07:54:49 GMT
Subject: RFR: 8300917: Regression 2x and bimodal startup on Mac aarch64 in
 b27
In-Reply-To: <AYNubIzLfR_sqjBDcJ13qDBKsKlU9INSsnUNyiYZSUw=.02c4d0ff-f125-47b6-b25c-6ac83a0c8292@github.com>
References: <AXAsqyTdLlz7c_RI-soi4AmkqJDG-laNLbzTVxnmbZU=.35fd56bf-abd5-4aa3-aaee-8a9f7f11eb0a@github.com>
 <AYNubIzLfR_sqjBDcJ13qDBKsKlU9INSsnUNyiYZSUw=.02c4d0ff-f125-47b6-b25c-6ac83a0c8292@github.com>
Message-ID: <2U1m9YRtuuJXu-IfGiz7zLj7FsnSZgv0M-fc0AaS6tc=.97247c72-d228-4e3f-9462-97edba56372e@github.com>

On Wed, 1 Feb 2023 07:21:10 GMT, Viktor Klang <duke at openjdk.org> wrote:

>> This PR proposed to reduce contention in synchronized methods mainly by doing I/O operations outside synch blocks.
>
> src/java.base/share/classes/java/lang/Module.java line 281:
> 
>> 279: 
>> 280:     private static boolean isNativeAccessEnabled(Module target) {
>> 281:         if (target.enableNativeAccess)
> 
> @minborg It'd seem a bit easier to implement using VarHandle and not having to use `synchronized`? Is the reason that you don't want to init VarHandle in this class? ?

It is a bootstrap problem. We cannot use AtomicBoolean, VarHandle or Unsafe here.

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

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

From aturbanov at openjdk.org  Wed Feb  1 08:00:51 2023
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Wed, 1 Feb 2023 08:00:51 GMT
Subject: RFR: 8301552: Use AtomicReferenceArray for caching instead of CHM
 in ZoneOffset
In-Reply-To: <b228oWPoEJf0lfGgIVXwmo1mATeKWRTivuJ2PbgwAmI=.465a4f9b-7a4b-4bbb-9f94-66d1d889a072@github.com>
References: <b228oWPoEJf0lfGgIVXwmo1mATeKWRTivuJ2PbgwAmI=.465a4f9b-7a4b-4bbb-9f94-66d1d889a072@github.com>
Message-ID: <CTKH5YNx2G5Qt2Q2GPUUfn-zqe1mEPATIgdbFNeYx-E=.85241b63-91b8-4387-99ec-d49f5d97b30c@github.com>

On Tue, 31 Jan 2023 15:57:43 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> `ZoneOffset` instances are cached by the `ZoneOffset` class itself for values in the range [-18h, 18h] for each second that is on an even quarter of an hour (i.e. at most 2*18*4+1 = 145 values). 
> 
> Instead of using a `ConcurrentHashMap` for caching instanced, we could instead use an `AtomicReferenceArray` with direct slot value access for said even seconds. This will improve performance and reduce the number of object even though the backing array will go from an initial 32 in the CHM to an initial/final 145 in the ARA. The CHM will contain much more objects and array slots for typical numbers of entries in the cache and will compute hash/bucket/collision on the hot code path for each cache access.

src/java.base/share/classes/java/time/ZoneOffset.java line 147:

> 145: 
> 146:     /** Cache of time-zone offset by offset in seconds [-18h, +18h] for each even quarter of an hour. */
> 147:     private static final AtomicReferenceArray<ZoneOffset> SECONDS_CACHE = new AtomicReferenceArray<>(MAX_SECONDS_CACHE_SLOT * 2 + 1);

Can we use regular array instead?

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

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

From duke at openjdk.org  Wed Feb  1 08:35:49 2023
From: duke at openjdk.org (Amit Kumar)
Date: Wed, 1 Feb 2023 08:35:49 GMT
Subject: RFR: 8299748: java/util/zip/Deinflate.java failing on s390x
In-Reply-To: <Usxi4wE5GSHHv-cKPfW6OXylhieAypbsidUX_Jo6FSQ=.34104cf0-2243-478f-86ce-9a91905c6755@github.com>
References: <Usxi4wE5GSHHv-cKPfW6OXylhieAypbsidUX_Jo6FSQ=.34104cf0-2243-478f-86ce-9a91905c6755@github.com>
Message-ID: <nN80i01pPGVl8QlQ09eEEEeFTz5z2hpM6udh2bNJwpU=.925ff5c6-586b-4262-bcd0-fd67d44cfde2@github.com>

On Mon, 30 Jan 2023 08:03:38 GMT, Amit Kumar <duke at openjdk.org> wrote:

> DeInflate.java test fails on s390x platform because size for out1 array which is responsible for storing the compressed data is insufficient. And being unable to write whole compressed data on array, on s390 whole data can't be recovered after compression. So this fix increase Array size (for s390).

Hi Alan, here is output: 

level:0, strategy: 2, dowrap: true                                                                                                
is finished: true                                                
is finished: true
is finished: true
is finished: true                                                                                                                 is finished: true
level:1, strategy: 0, dowrap: false               
is finished: false     
m=525312, n=497972, len=524288, eq=false                                                                                          STDERR:    
java.lang.RuntimeException: De/inflater failed:java.util.zip.Deflater at 23a0858b                                               



But I guess this behaviour could be explained (by zEDC). On s390x, there is additional instruction present and it could be enabled by setting `DFLTCC=1`. And for accelerator the size of compressed data could go`2 times` the size of actual data. Again this is not deterministic as well, i.e. for same data there could be different valid deflate stream.

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

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

From pminborg at openjdk.org  Wed Feb  1 08:37:47 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 1 Feb 2023 08:37:47 GMT
Subject: RFR: 8301578: Perform output outside synchronization in
 Module.class
In-Reply-To: <AXAsqyTdLlz7c_RI-soi4AmkqJDG-laNLbzTVxnmbZU=.35fd56bf-abd5-4aa3-aaee-8a9f7f11eb0a@github.com>
References: <AXAsqyTdLlz7c_RI-soi4AmkqJDG-laNLbzTVxnmbZU=.35fd56bf-abd5-4aa3-aaee-8a9f7f11eb0a@github.com>
Message-ID: <vUQfyxo1Na5gGE1N1TUeTv3_CmEUuqO3FSAbt4sOZoo=.3a04f3ef-8355-4496-a365-91db3c79d673@github.com>

On Wed, 25 Jan 2023 12:26:26 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR proposed to reduce contention in synchronized methods mainly by doing I/O operations outside synch blocks.

Let me take a step back here and explain the reason why I think this PR is worth looking at. Firstly, I think the argument that this might not solve https://bugs.openjdk.org/browse/JDK-8300917 is perfectly valid. Therefore, I have filed a separate issue and linked this PR to this. Thanks for pointing this out. This PR is more like a drive-by cleanup as mentioned.

Back to the contents of the PR. My fear (which may or may not be substantiated) is that if we perform operations via the relatively slow `System.err.printf,` while being in a synchronization block, we are exposed to a number of potential problems:

* Another thread might be performing `System.err` operations which will be under a separate lock/sync
* Other threads are calling `ensureNativeAccess` for the same module
* A "storm of calls" during bootstrap
* Combinations of any of the above

Again, this might not be the case in reality but I think removing the risk is worthwhile.

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

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

From pminborg at openjdk.org  Wed Feb  1 08:45:15 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 1 Feb 2023 08:45:15 GMT
Subject: RFR: 8301578: Perform output outside synchronization in
 Module.class [v2]
In-Reply-To: <AXAsqyTdLlz7c_RI-soi4AmkqJDG-laNLbzTVxnmbZU=.35fd56bf-abd5-4aa3-aaee-8a9f7f11eb0a@github.com>
References: <AXAsqyTdLlz7c_RI-soi4AmkqJDG-laNLbzTVxnmbZU=.35fd56bf-abd5-4aa3-aaee-8a9f7f11eb0a@github.com>
Message-ID: <rVvhKhpdMqNadMWCRWfhE6tXKdMLlNYw3fyDh9cyJ48=.a246f1c1-c9c2-4252-b2c2-382ada66b225@github.com>

> This PR proposed to reduce contention in synchronized methods mainly by doing I/O operations outside synch blocks.

Per Minborg has updated the pull request incrementally with two additional commits since the last revision:

 - Update after comments
 - Remove warning

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12193/files
  - new: https://git.openjdk.org/jdk/pull/12193/files/cdd3ac4c..9af658b1

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

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

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

From alanb at openjdk.org  Wed Feb  1 08:48:50 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 1 Feb 2023 08:48:50 GMT
Subject: RFR: 8299748: java/util/zip/Deinflate.java failing on s390x
In-Reply-To: <nN80i01pPGVl8QlQ09eEEEeFTz5z2hpM6udh2bNJwpU=.925ff5c6-586b-4262-bcd0-fd67d44cfde2@github.com>
References: <Usxi4wE5GSHHv-cKPfW6OXylhieAypbsidUX_Jo6FSQ=.34104cf0-2243-478f-86ce-9a91905c6755@github.com>
 <nN80i01pPGVl8QlQ09eEEEeFTz5z2hpM6udh2bNJwpU=.925ff5c6-586b-4262-bcd0-fd67d44cfde2@github.com>
Message-ID: <jyL7HTlmcVxDKffdPqij6GNM0ePfzVxlypfy3hTtOAM=.3347a8dd-4722-4b79-b93e-b20892901c6b@github.com>

On Wed, 1 Feb 2023 08:33:16 GMT, Amit Kumar <duke at openjdk.org> wrote:

> level:1, strategy: 0, dowrap: false               
> is finished: false     

Thanks for checking that. So "is finished: false" is telling us that not all of the input was compressed. So I think the right thing is to do the deflate in a loop until there is more input to compress, the inflate probably needs the same. Your original proposal was to make the output buffer larger and I suspect that is just working around a threshold or block size used by the accelerator.

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

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

From pminborg at openjdk.org  Wed Feb  1 08:51:16 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 1 Feb 2023 08:51:16 GMT
Subject: RFR: 8301578: Perform output outside synchronization in
 Module.class [v3]
In-Reply-To: <AXAsqyTdLlz7c_RI-soi4AmkqJDG-laNLbzTVxnmbZU=.35fd56bf-abd5-4aa3-aaee-8a9f7f11eb0a@github.com>
References: <AXAsqyTdLlz7c_RI-soi4AmkqJDG-laNLbzTVxnmbZU=.35fd56bf-abd5-4aa3-aaee-8a9f7f11eb0a@github.com>
Message-ID: <yUInbpslOJ5zBLati4j-6FdJcnJvcdkUcG-5eG_7Aws=.1235e39e-ae82-482a-bcbc-ae355b52af55@github.com>

> This PR proposed to reduce contention in synchronized methods mainly by doing I/O operations outside synch blocks.

Per Minborg has updated the pull request incrementally with three additional commits since the last revision:

 - Revert benchmark change
 - Fix typo
 - Use another type of comment

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12193/files
  - new: https://git.openjdk.org/jdk/pull/12193/files/9af658b1..b0aeb64b

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

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

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

From duke at openjdk.org  Wed Feb  1 09:28:54 2023
From: duke at openjdk.org (Glavo)
Date: Wed, 1 Feb 2023 09:28:54 GMT
Subject: RFR: 8301569: list mode of jmod and jimage cannot be used normally
 in turkish locale
In-Reply-To: <YGY2k5Yxc64cmMkwT71Tl2M8nzHXAO8_ATTSajL9DQI=.58727057-78b4-4d5a-900e-e35d1de444d3@github.com>
References: <v0uxR1eF4vFNvA8DMLlwG1x2M-oH3o-xTJgKPs25UNA=.35fe243b-db18-42b6-b32b-115b649340f6@github.com>
 <YGY2k5Yxc64cmMkwT71Tl2M8nzHXAO8_ATTSajL9DQI=.58727057-78b4-4d5a-900e-e35d1de444d3@github.com>
Message-ID: <c_nKgF39mKpvMYopNLdMen6vNuEjGQdNa_lBnX_ShEw=.c9cd0c29-5b73-40e2-ac47-c6a78ecf2e10@github.com>

On Wed, 1 Feb 2023 07:20:13 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> The equivalent in jlink and jimage are using Locale.ENGLISH, I guess we should try to keep them consistent.

This class is using `Locale.ROOT` to convert modifiers to lowercase, and there is no reference to `Locale.ENGLISH`.

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

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

From duke at openjdk.org  Wed Feb  1 09:40:51 2023
From: duke at openjdk.org (Glavo)
Date: Wed, 1 Feb 2023 09:40:51 GMT
Subject: RFR: 8301569: list mode of jmod and jimage cannot be used normally
 in turkish locale
In-Reply-To: <YGY2k5Yxc64cmMkwT71Tl2M8nzHXAO8_ATTSajL9DQI=.58727057-78b4-4d5a-900e-e35d1de444d3@github.com>
References: <v0uxR1eF4vFNvA8DMLlwG1x2M-oH3o-xTJgKPs25UNA=.35fe243b-db18-42b6-b32b-115b649340f6@github.com>
 <YGY2k5Yxc64cmMkwT71Tl2M8nzHXAO8_ATTSajL9DQI=.58727057-78b4-4d5a-900e-e35d1de444d3@github.com>
Message-ID: <y3If-khLjoyjraaQGk0HbCADtDmej7hKjf6hNx2Y134=.2fe98426-32d0-49ce-affb-8a316ae70d97@github.com>

On Wed, 1 Feb 2023 07:20:17 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> This is the lookup of the main.usage.list resource (`jimage list --help`) rather than the `list` option but good to fix this anyway.

Sorry, I found the problem with text search, but didn't look at them carefully.

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

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

From rgiulietti at openjdk.org  Wed Feb  1 10:26:26 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Wed, 1 Feb 2023 10:26:26 GMT
Subject: RFR: 8300869: Make use of the Double.toString(double) algorithm in
 java.util.Formatter [v8]
In-Reply-To: <SBTbJWmhb-9rmOWnNXtIH-ztXLj2fNvdE0XCMIVmoZA=.5a6a1ef3-a42a-4675-96c1-a137c5f6ec1a@github.com>
References: <SBTbJWmhb-9rmOWnNXtIH-ztXLj2fNvdE0XCMIVmoZA=.5a6a1ef3-a42a-4675-96c1-a137c5f6ec1a@github.com>
Message-ID: <BmEb7ZreTAdkNarpJgk7pZGGU8Ed6uNsexlvk4xlrbM=.85509eb8-9950-4a43-9703-edf9de311fe2@github.com>

> Align `double` and `float` decimal conversions in `java.util.Formatter` with the algorithm used in `Double.toString(double)`.

Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:

  8300869: Make use of the Double.toString(double) algorithm in java.util.Formatter

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12259/files
  - new: https://git.openjdk.org/jdk/pull/12259/files/5e488a70..bf7d9f64

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

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

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

From rgiulietti at openjdk.org  Wed Feb  1 10:26:27 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Wed, 1 Feb 2023 10:26:27 GMT
Subject: RFR: 8300869: Make use of the Double.toString(double) algorithm in
 java.util.Formatter [v7]
In-Reply-To: <p3INCZYlaAZF00qaPkL5OOF079XlElugdRDOe3vEXUo=.b4fc5759-7387-4521-8c15-424980d44c8c@github.com>
References: <SBTbJWmhb-9rmOWnNXtIH-ztXLj2fNvdE0XCMIVmoZA=.5a6a1ef3-a42a-4675-96c1-a137c5f6ec1a@github.com>
 <nOpniQff5eA8HQLfs3OlhcJUvYCK29-RF41KNkbyc-I=.ad311826-3f61-46f2-b5c5-6a8015067bfc@github.com>
 <p3INCZYlaAZF00qaPkL5OOF079XlElugdRDOe3vEXUo=.b4fc5759-7387-4521-8c15-424980d44c8c@github.com>
Message-ID: <4FDCIv_rq0v1SUez4QWFS_45ja2Wdp6uvud9mv2vElM=.58113abe-beb3-498f-ae8d-cbbeb440780d@github.com>

On Tue, 31 Jan 2023 22:19:25 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8300869: Make use of the Double.toString(double) algorithm in java.util.Formatter
>
> src/java.base/share/classes/jdk/internal/math/FormattedFPDecimal.java line 28:
> 
>> 26: package jdk.internal.math;
>> 27: 
>> 28: public final class FormattedFPDecimal {
> 
> I suggest adding a short explanation of what this class is used for.

Addressed.

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

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

From stsypanov at openjdk.org  Wed Feb  1 10:36:12 2023
From: stsypanov at openjdk.org (Sergey Tsypanov)
Date: Wed, 1 Feb 2023 10:36:12 GMT
Subject: RFR: 8301492: Modernize equals() method of ResourceBundle.CacheKey
 and Bundles.CacheKey [v3]
In-Reply-To: <5xdnQZ8wLrkyB6U2miAOizqpvHGTFzy7OF_a24CUabc=.db6a65d7-9a29-44dc-94aa-692fbbfc82c7@github.com>
References: <5xdnQZ8wLrkyB6U2miAOizqpvHGTFzy7OF_a24CUabc=.db6a65d7-9a29-44dc-94aa-692fbbfc82c7@github.com>
Message-ID: <fvmMrOWZG6N-QjWdqH5lfMzKqEdvDPmkh6ccV8anLvQ=.b7591ed2-0275-4ee8-a013-dbd65ec68cfd@github.com>

> `ResourceBundle.CacheKey.equals()` and `Bundles.CacheKey.equals()` are quire outdated. This simple clean-up modernizes them.

Sergey Tsypanov has updated the pull request incrementally with one additional commit since the last revision:

  Restore logic

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12328/files
  - new: https://git.openjdk.org/jdk/pull/12328/files/82b03202..2b07e47e

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

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

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

From jpai at openjdk.org  Wed Feb  1 10:38:49 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 1 Feb 2023 10:38:49 GMT
Subject: RFR: 8301367: Add exception handler method to the BaseLdapServer
In-Reply-To: <IGbyuw-gT2l_XwCle-EwHxngqsvA-HRPmRVV6jKf2Rs=.ef06d2ce-82d9-468f-a545-8fd61b336aeb@github.com>
References: <IGbyuw-gT2l_XwCle-EwHxngqsvA-HRPmRVV6jKf2Rs=.ef06d2ce-82d9-468f-a545-8fd61b336aeb@github.com>
Message-ID: <rO68NnmjJk9yx4XXKREGNJNsfX_f-Dh2yaJGeDQsEY4=.17de604e-5dea-442e-9adb-55fa52d1835d@github.com>

On Tue, 31 Jan 2023 16:19:34 GMT, Aleksei Efimov <aefimov at openjdk.org> wrote:

> The proposed change adds a new exception handler method to the `test/jdk/com/sun/jndi/ldap/lib/BaseLdapServer.java` LDAP test library class. It will allow LDAP tests to customize the handling of server-side exceptions.   
> The current `BaseLdapTestServer` implementation prints an exception and its stack trace to the standard error stream.
> 
> Existing tests in `test/jdk/com/sun/jndi/ldap` that use the modified library class are passing with the modified version.

Hello Aleksei, the change looks fine to me.

The new method name `handleSocketException` could be a bit confusing since it might indicate this is about handling `java.net.SocketException`. But I think, given that this is just a test library code and that the method has a comment explaining when it's called, I think it's OK.

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

Marked as reviewed by jpai (Reviewer).

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

From jpai at openjdk.org  Wed Feb  1 10:56:49 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 1 Feb 2023 10:56:49 GMT
Subject: RFR: JDK-8300098 :
 java/util/concurrent/ConcurrentHashMap/ConcurrentAssociateTest.java fails with
 internal timeout when executed with TieredCompilation1/3
In-Reply-To: <CPbu_uqDyvV1hu2fjL-A6LIx3kK-ncM26_cDlXVxIeY=.1c30805e-ff8c-432d-a5a9-c9ca59383ace@github.com>
References: <CPbu_uqDyvV1hu2fjL-A6LIx3kK-ncM26_cDlXVxIeY=.1c30805e-ff8c-432d-a5a9-c9ca59383ace@github.com>
Message-ID: <XwHIZ6nBmDZ5G8EwuRa7faoJnYRGpaVEd2mCsP_hlCE=.91c8b74b-0bd3-42bd-a27b-5576b645b348@github.com>

On Tue, 31 Jan 2023 10:45:07 GMT, Viktor Klang <duke at openjdk.org> wrote:

> The proposed fix by @DougLea ensures that the state transition into waiting is retried in the cases where a previous waiter isn't making progress and a new waiter goes into waiting.

Hello Viktor, I don't have enough knowledge of this area, but looking at this change and going by what Doug noted in the JBS issue:
> There's a CHM bug scenario that I haven't been able to rule out after looking at this again: A late clearing of waiter field in ConcurrentHashMap.contendedLock by a previous waiter. There may be a constraint I've forgotten that makes this impossible in principle, but it is easy to change to be more clearly correct by replacing the writes with CASes

this change looks OK to me.

You might have to add a `noreg-hard` label to that JBS issue.

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

Marked as reviewed by jpai (Reviewer).

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

From pminborg at openjdk.org  Wed Feb  1 11:41:16 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 1 Feb 2023 11:41:16 GMT
Subject: RFR: 8301552: Use AtomicReferenceArray for caching instead of CHM
 in ZoneOffset [v2]
In-Reply-To: <b228oWPoEJf0lfGgIVXwmo1mATeKWRTivuJ2PbgwAmI=.465a4f9b-7a4b-4bbb-9f94-66d1d889a072@github.com>
References: <b228oWPoEJf0lfGgIVXwmo1mATeKWRTivuJ2PbgwAmI=.465a4f9b-7a4b-4bbb-9f94-66d1d889a072@github.com>
Message-ID: <HBHnOjm6nfd5ENpq8sATk_HpLtcsu73V7OekzluMWF4=.dd8ff1c1-0be3-4d01-a722-0c2edb6da5eb@github.com>

> `ZoneOffset` instances are cached by the `ZoneOffset` class itself for values in the range [-18h, 18h] for each second that is on an even quarter of an hour (i.e. at most 2*18*4+1 = 145 values). 
> 
> Instead of using a `ConcurrentHashMap` for caching instanced, we could instead use an `AtomicReferenceArray` with direct slot value access for said even seconds. This will improve performance and reduce the number of object even though the backing array will go from an initial 32 in the CHM to an initial/final 145 in the ARA. The CHM will contain much more objects and array slots for typical numbers of entries in the cache and will compute hash/bucket/collision on the hot code path for each cache access.

Per Minborg has updated the pull request incrementally with one additional commit since the last revision:

  Rework using a regular array and acquire/release semantics

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12346/files
  - new: https://git.openjdk.org/jdk/pull/12346/files/eedec09d..a99dd083

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

  Stats: 43 lines in 1 file changed: 33 ins; 1 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/12346.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12346/head:pull/12346

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

From pminborg at openjdk.org  Wed Feb  1 11:41:18 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 1 Feb 2023 11:41:18 GMT
Subject: RFR: 8301552: Use AtomicReferenceArray for caching instead of CHM
 in ZoneOffset [v2]
In-Reply-To: <CTKH5YNx2G5Qt2Q2GPUUfn-zqe1mEPATIgdbFNeYx-E=.85241b63-91b8-4387-99ec-d49f5d97b30c@github.com>
References: <b228oWPoEJf0lfGgIVXwmo1mATeKWRTivuJ2PbgwAmI=.465a4f9b-7a4b-4bbb-9f94-66d1d889a072@github.com>
 <CTKH5YNx2G5Qt2Q2GPUUfn-zqe1mEPATIgdbFNeYx-E=.85241b63-91b8-4387-99ec-d49f5d97b30c@github.com>
Message-ID: <YZtD-22CoEUUEKKffO00sDOXC_8VlK06-wI_AwtJUTA=.5392452d-543f-4e7d-9a7f-fdf9b1c49503@github.com>

On Wed, 1 Feb 2023 07:58:02 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

>> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Rework using a regular array and acquire/release semantics
>
> src/java.base/share/classes/java/time/ZoneOffset.java line 147:
> 
>> 145: 
>> 146:     /** Cache of time-zone offset by offset in seconds [-18h, +18h] for each even quarter of an hour. */
>> 147:     private static final AtomicReferenceArray<ZoneOffset> SECONDS_CACHE = new AtomicReferenceArray<>(MAX_SECONDS_CACHE_SLOT * 2 + 1);
> 
> Can we use regular array instead?

We can but that entails special handling to ensure thread-safety. I will provide such a solution. Thanks.

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

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

From pminborg at openjdk.org  Wed Feb  1 12:06:25 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 1 Feb 2023 12:06:25 GMT
Subject: RFR: 8301552: Use AtomicReferenceArray for caching instead of CHM
 in ZoneOffset [v3]
In-Reply-To: <b228oWPoEJf0lfGgIVXwmo1mATeKWRTivuJ2PbgwAmI=.465a4f9b-7a4b-4bbb-9f94-66d1d889a072@github.com>
References: <b228oWPoEJf0lfGgIVXwmo1mATeKWRTivuJ2PbgwAmI=.465a4f9b-7a4b-4bbb-9f94-66d1d889a072@github.com>
Message-ID: <aT7UpnfCt_KjdNSuivnJwMH3uFFOfsGP247_zDODBno=.8c4ea21e-1052-4128-a946-5b2cd72db03d@github.com>

> `ZoneOffset` instances are cached by the `ZoneOffset` class itself for values in the range [-18h, 18h] for each second that is on an even quarter of an hour (i.e. at most 2*18*4+1 = 145 values). 
> 
> Instead of using a `ConcurrentHashMap` for caching instanced, we could instead use an `AtomicReferenceArray` with direct slot value access for said even seconds. This will improve performance and reduce the number of object even though the backing array will go from an initial 32 in the CHM to an initial/final 145 in the ARA. The CHM will contain much more objects and array slots for typical numbers of entries in the cache and will compute hash/bucket/collision on the hot code path for each cache access.

Per Minborg has updated the pull request incrementally with one additional commit since the last revision:

  Remove code commented out

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12346/files
  - new: https://git.openjdk.org/jdk/pull/12346/files/a99dd083..5a8e9720

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

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

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

From pminborg at openjdk.org  Wed Feb  1 13:18:31 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 1 Feb 2023 13:18:31 GMT
Subject: RFR: 8301552: Use AtomicReferenceArray for caching instead of CHM
 in ZoneOffset [v4]
In-Reply-To: <b228oWPoEJf0lfGgIVXwmo1mATeKWRTivuJ2PbgwAmI=.465a4f9b-7a4b-4bbb-9f94-66d1d889a072@github.com>
References: <b228oWPoEJf0lfGgIVXwmo1mATeKWRTivuJ2PbgwAmI=.465a4f9b-7a4b-4bbb-9f94-66d1d889a072@github.com>
Message-ID: <hsJDiMZ6OJcbc9z1577V64xshorl5wYbF1Lm3k8TUzs=.6d47a875-6190-4688-a0ac-12f48dbcfa72@github.com>

> `ZoneOffset` instances are cached by the `ZoneOffset` class itself for values in the range [-18h, 18h] for each second that is on an even quarter of an hour (i.e. at most 2*18*4+1 = 145 values). 
> 
> Instead of using a `ConcurrentHashMap` for caching instanced, we could instead use an `AtomicReferenceArray` with direct slot value access for said even seconds. This will improve performance and reduce the number of object even though the backing array will go from an initial 32 in the CHM to an initial/final 145 in the ARA. The CHM will contain much more objects and array slots for typical numbers of entries in the cache and will compute hash/bucket/collision on the hot code path for each cache access.

Per Minborg has updated the pull request incrementally with two additional commits since the last revision:

 - Simplify benchmark
 - Add benchmark

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12346/files
  - new: https://git.openjdk.org/jdk/pull/12346/files/5a8e9720..562885c7

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

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

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

From pminborg at openjdk.org  Wed Feb  1 13:40:52 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 1 Feb 2023 13:40:52 GMT
Subject: RFR: 8301552: Use AtomicReferenceArray for caching instead of CHM
 in ZoneOffset [v4]
In-Reply-To: <hsJDiMZ6OJcbc9z1577V64xshorl5wYbF1Lm3k8TUzs=.6d47a875-6190-4688-a0ac-12f48dbcfa72@github.com>
References: <b228oWPoEJf0lfGgIVXwmo1mATeKWRTivuJ2PbgwAmI=.465a4f9b-7a4b-4bbb-9f94-66d1d889a072@github.com>
 <hsJDiMZ6OJcbc9z1577V64xshorl5wYbF1Lm3k8TUzs=.6d47a875-6190-4688-a0ac-12f48dbcfa72@github.com>
Message-ID: <BaYxA84q3TgEJfSaZTSKdwIQv-3pXNPK1uCVdrRWcwI=.77ca6006-d3ad-4dd5-a06c-9a013a72d245@github.com>

On Wed, 1 Feb 2023 13:18:31 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> `ZoneOffset` instances are cached by the `ZoneOffset` class itself for values in the range [-18h, 18h] for each second that is on an even quarter of an hour (i.e. at most 2*18*4+1 = 145 values). 
>> 
>> Instead of using a `ConcurrentHashMap` for caching instanced, we could instead use an `AtomicReferenceArray` with direct slot value access for said even seconds. This will improve performance and reduce the number of object even though the backing array will go from an initial 32 in the CHM to an initial/final 145 in the ARA. The CHM will contain much more objects and array slots for typical numbers of entries in the cache and will compute hash/bucket/collision on the hot code path for each cache access.
>
> Per Minborg has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Simplify benchmark
>  - Add benchmark

A > 3X performance increase is obtained via this PR for `ZoneOffset::ofTotalSeconds` for values from the cache (higher is better):


Baseline
Result "org.openjdk.bench.java.time.ZoneOffsetBench.getFromCache":
  1.088 ?(99.9%) 0.019 ops/us [Average]
  (min, avg, max) = (1.046, 1.088, 1.109), stdev = 0.018
  CI (99.9%): [1.069, 1.108] (assumes normal distribution)

PR
Result "org.openjdk.bench.java.time.ZoneOffsetBench.getFromCache":
  3.710 ?(99.9%) 0.031 ops/us [Average]
  (min, avg, max) = (3.651, 3.710, 3.745), stdev = 0.029
  CI (99.9%): [3.680, 3.741] (assumes normal distribution)


![image](https://user-images.githubusercontent.com/7457876/216058153-03c06037-5ddb-40cb-8e2c-5beae0560126.png)

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

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

From jbhateja at openjdk.org  Wed Feb  1 14:23:02 2023
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Wed, 1 Feb 2023 14:23:02 GMT
Subject: RFR: 8293198: [vectorapi] Improve the implementation of
 VectorMask.indexInRange()
In-Reply-To: <fN58bi3n01tqWpG0-jjUPZQe8hmls2GQ5X3NL2o1RPg=.80e7965d-50af-4fac-bd7c-0a2b99cffe7e@github.com>
References: <fN58bi3n01tqWpG0-jjUPZQe8hmls2GQ5X3NL2o1RPg=.80e7965d-50af-4fac-bd7c-0a2b99cffe7e@github.com>
Message-ID: <ueWKU-J85vkS2Iss-2P1YvBAgbywubU6rnXLI4ddZ-o=.b566a7e6-98cb-4897-ab61-970e3388ff5a@github.com>

On Wed, 18 Jan 2023 08:58:42 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

> The Vector API `"indexInRange(int offset, int limit)"` is used
> to compute a vector mask whose lanes are set to true if the
> index of the lane is inside the range specified by the `"offset"`
> and `"limit"` arguments, otherwise the lanes are set to false.
> 
> There are two special cases for this API:
>  1) If `"offset >= 0 && offset >= limit"`, all the lanes of the
> generated mask are false.
>  2) If` "offset >= 0 && limit - offset >= vlength"`, all the
> lanes of the generated mask are true. Note that `"vlength"` is
> the number of vector lanes.
> 
> For such special cases, we can simply use `"maskAll(false|true)"`
> to implement the API. Otherwise, the original comparison with
> `"iota" `vector is needed. And for further optimization, we have
> optimal instruction supported by SVE (i.e. whilelo [1]), which
> can implement the API directly if the `"offset >= 0"`.
> 
> As a summary, to optimize the API, we can use the if-else branches
> to handle the specific cases in java level and intrinsify the
> remaining case by C2 compiler:
> 
> 
>   public VectorMask<E> indexInRange(int offset, int limit) {
>       if (offset < 0) {
>           return this.and(indexInRange0Helper(offset, limit));
>       } else if (offset >= limit) {
>           return this.and(vectorSpecies().maskAll(false));
>       } else if (limit - offset >= length()) {
>           return this.and(vectorSpecies().maskAll(true));
>       }
>       return this.and(indexInRange0(offset, limit));
>  }
> 
> 
> The last part (i.e. `"indexInRange0"`) in the above implementation
> is expected to be intrinsified by C2 compiler if the necessary IRs
> are supported. Otherwise, it will fall back to the original API
> implementation (i.e. `"indexInRange0Helper"`). Regarding to the
> intrinsifaction, the compiler will generate `"VectorMaskGen"` IR
> with "limit - offset" as the input if the current platform supports
> it. Otherwise, it generates `"VectorLoadConst + VectorMaskCmp"` based
> on `"iota < limit - offset"`.
> 
> For the following java code which uses `"indexInRange"`:
> 
> 
> static final VectorSpecies<Double> SPECIES =
>                                    DoubleVector.SPECIES_PREFERRED;
> static final int LENGTH = 1027;
> 
> public static double[] da;
> public static double[] db;
> public static double[] dc;
> 
> private static void func() {
>     for (int i = 0; i < LENGTH; i += SPECIES.length()) {
>         var m = SPECIES.indexInRange(i, LENGTH);
>         var av = DoubleVector.fromArray(SPECIES, da, i, m);
>         av.lanewise(VectorOperators.NEG).intoArray(dc, i, m);
>     }
> }
> 
> 
> The core code generated with SVE 256-bit vector size is:
> 
> 
>   ptrue   p2.d                  ; maskAll(true)
>   ...
> LOOP:
>   ...
>   sub     w11, w13, w14         ; limit - offset
>   cmp     w14, w13
>   b.cs    LABEL-1               ; if (offset >= limit) => uncommon-trap
>   cmp     w11, #0x4
>   b.lt    LABEL-2               ; if (limit - offset < vlength)
>   mov     p1.b, p2.b
> LABEL-3:
>   ld1d    {z16.d}, p1/z, [x10]  ; load vector masked
>   ...
>   cmp     w14, w29
>   b.cc    LOOP
>   ...
> LABEL-2:
>   whilelo p1.d, x16, x10        ; VectorMaskGen
>   ...
>   b       LABEL-3
>   ...
> LABEL-1:
>   uncommon-trap
> 
> 
> Please note that if the array size `LENGTH` is aligned with
> the vector size 256 (i.e. `LENGTH = 1024`), the branch "LABEL-2"
> will be optimized out by compiler and it becomes another
> uncommon-trap.
> 
> For NEON, the main CFG is the same with above. But the compiler
> intrinsification is different. Here is the code:
> 
> 
>   sub     x10, x10, x12          ; limit - offset
>   scvtf   d16, x10
>   dup     v16.2d, v16.d[0]       ; replicateD
> 
>   mov     x8, #0xd8d0
>   movk    x8, #0x84cb, lsl #16
>   movk    x8, #0xffff, lsl #32
>   ldr     q17, [x8], #0          ; load the "iota" const vector
>   fcmgt   v18.2d, v16.2d, v17.2d ; mask = iota < limit - offset
> 
> 
> Here is the performance data of the new added benchmark on an ARM
> SVE 256-bit platform:
> 
> 
> Benchmark                               (size)  Before    After   Units
> IndexInRangeBenchmark.byteIndexInRange   1024 11203.697 41404.431 ops/ms
> IndexInRangeBenchmark.byteIndexInRange   1027  2365.920  8747.004 ops/ms
> IndexInRangeBenchmark.doubleIndexInRange 1024  1227.505  6092.194 ops/ms
> IndexInRangeBenchmark.doubleIndexInRange 1027   351.215  1156.683 ops/ms
> IndexInRangeBenchmark.floatIndexInRange  1024  1468.876 11032.580 ops/ms
> IndexInRangeBenchmark.floatIndexInRange  1027   699.645  2439.671 ops/ms
> IndexInRangeBenchmark.intIndexInRange    1024  2842.187 11903.544 ops/ms
> IndexInRangeBenchmark.intIndexInRange    1027   689.866  2547.424 ops/ms
> IndexInRangeBenchmark.longIndexInRange   1024  1394.135  5902.973 ops/ms
> IndexInRangeBenchmark.longIndexInRange   1027   355.621  1189.458 ops/ms
> IndexInRangeBenchmark.shortIndexInRange  1024  5521.468 21578.340 ops/ms
> IndexInRangeBenchmark.shortIndexInRange  1027  1264.816  4640.504 ops/ms
> 
> 
> And the performance data with ARM NEON:
> 
> 
> Benchmark                               (size)  Before    After   Units
> IndexInRangeBenchmark.byteIndexInRange   1024  4026.548 15562.880 ops/ms
> IndexInRangeBenchmark.byteIndexInRange   1027   305.314   576.559 ops/ms
> IndexInRangeBenchmark.doubleIndexInRange 1024   289.224  2244.080 ops/ms
> IndexInRangeBenchmark.doubleIndexInRange 1027    39.740    76.499 ops/ms
> IndexInRangeBenchmark.floatIndexInRange  1024   675.264  4457.470 ops/ms
> IndexInRangeBenchmark.floatIndexInRange  1027    79.918   144.952 ops/ms
> IndexInRangeBenchmark.intIndexInRange    1024   740.139  4014.583 ops/ms
> IndexInRangeBenchmark.intIndexInRange    1027    78.608   147.903 ops/ms
> IndexInRangeBenchmark.longIndexInRange   1024   400.683  2209.551 ops/ms
> IndexInRangeBenchmark.longIndexInRange   1027    41.146    69.599 ops/ms
> IndexInRangeBenchmark.shortIndexInRange  1024  1821.736  8153.546 ops/ms
> IndexInRangeBenchmark.shortIndexInRange  1027   158.810   243.205 ops/ms
> 
> 
> The performance improves about `3.5x ~ 7.5x` on the vector size aligned
> (1024 size) benchmarks both with NEON and SVE. And it improves about
> `3.5x/1.8x` on the vector size not aligned (1027 size) benchmarks with
> SVE/NEON respectively. We can also observe the similar improvement on
> the x86 platforms.
> 
> [1] https://developer.arm.com/documentation/ddi0596/2020-12/SVE-Instructions/WHILELO--While-incrementing-unsigned-scalar-lower-than-scalar-

src/jdk.incubator.vector/share/classes/jdk/incubator/vector/AbstractMask.java line 236:

> 234:         } else if (offset >= limit) {
> 235:             return vectorSpecies().maskAll(false);
> 236:         } else if (limit - offset >= length()) {

Can you move this else if check at the top, this is the most general case appearing in the loop and hence two extra uncommon trap jumps before it for special cases may penalize this.

src/jdk.incubator.vector/share/classes/jdk/incubator/vector/AbstractMask.java line 239:

> 237:             return this;
> 238:         }
> 239:         return this.and(indexInRange0(offset, limit));

Not related to this patch, but I also see a possibility of following ideal transformations:-
        maskAll(true).allTrue() => true 
        maskAll(false).anyTrue() => false

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

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

From jbhateja at openjdk.org  Wed Feb  1 14:23:04 2023
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Wed, 1 Feb 2023 14:23:04 GMT
Subject: RFR: 8293198: [vectorapi] Improve the implementation of
 VectorMask.indexInRange()
In-Reply-To: <ueWKU-J85vkS2Iss-2P1YvBAgbywubU6rnXLI4ddZ-o=.b566a7e6-98cb-4897-ab61-970e3388ff5a@github.com>
References: <fN58bi3n01tqWpG0-jjUPZQe8hmls2GQ5X3NL2o1RPg=.80e7965d-50af-4fac-bd7c-0a2b99cffe7e@github.com>
 <ueWKU-J85vkS2Iss-2P1YvBAgbywubU6rnXLI4ddZ-o=.b566a7e6-98cb-4897-ab61-970e3388ff5a@github.com>
Message-ID: <xrdln-eR6POz41Xgq4fVbV6FPVQ_Eq0dCcRhOx6dGIs=.6d29b24c-71c1-4906-b256-b2cc6af25a75@github.com>

On Wed, 1 Feb 2023 12:30:36 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> The Vector API `"indexInRange(int offset, int limit)"` is used
>> to compute a vector mask whose lanes are set to true if the
>> index of the lane is inside the range specified by the `"offset"`
>> and `"limit"` arguments, otherwise the lanes are set to false.
>> 
>> There are two special cases for this API:
>>  1) If `"offset >= 0 && offset >= limit"`, all the lanes of the
>> generated mask are false.
>>  2) If` "offset >= 0 && limit - offset >= vlength"`, all the
>> lanes of the generated mask are true. Note that `"vlength"` is
>> the number of vector lanes.
>> 
>> For such special cases, we can simply use `"maskAll(false|true)"`
>> to implement the API. Otherwise, the original comparison with
>> `"iota" `vector is needed. And for further optimization, we have
>> optimal instruction supported by SVE (i.e. whilelo [1]), which
>> can implement the API directly if the `"offset >= 0"`.
>> 
>> As a summary, to optimize the API, we can use the if-else branches
>> to handle the specific cases in java level and intrinsify the
>> remaining case by C2 compiler:
>> 
>> 
>>   public VectorMask<E> indexInRange(int offset, int limit) {
>>       if (offset < 0) {
>>           return this.and(indexInRange0Helper(offset, limit));
>>       } else if (offset >= limit) {
>>           return this.and(vectorSpecies().maskAll(false));
>>       } else if (limit - offset >= length()) {
>>           return this.and(vectorSpecies().maskAll(true));
>>       }
>>       return this.and(indexInRange0(offset, limit));
>>  }
>> 
>> 
>> The last part (i.e. `"indexInRange0"`) in the above implementation
>> is expected to be intrinsified by C2 compiler if the necessary IRs
>> are supported. Otherwise, it will fall back to the original API
>> implementation (i.e. `"indexInRange0Helper"`). Regarding to the
>> intrinsifaction, the compiler will generate `"VectorMaskGen"` IR
>> with "limit - offset" as the input if the current platform supports
>> it. Otherwise, it generates `"VectorLoadConst + VectorMaskCmp"` based
>> on `"iota < limit - offset"`.
>> 
>> For the following java code which uses `"indexInRange"`:
>> 
>> 
>> static final VectorSpecies<Double> SPECIES =
>>                                    DoubleVector.SPECIES_PREFERRED;
>> static final int LENGTH = 1027;
>> 
>> public static double[] da;
>> public static double[] db;
>> public static double[] dc;
>> 
>> private static void func() {
>>     for (int i = 0; i < LENGTH; i += SPECIES.length()) {
>>         var m = SPECIES.indexInRange(i, LENGTH);
>>         var av = DoubleVector.fromArray(SPECIES, da, i, m);
>>         av.lanewise(VectorOperators.NEG).intoArray(dc, i, m);
>>     }
>> }
>> 
>> 
>> The core code generated with SVE 256-bit vector size is:
>> 
>> 
>>   ptrue   p2.d                  ; maskAll(true)
>>   ...
>> LOOP:
>>   ...
>>   sub     w11, w13, w14         ; limit - offset
>>   cmp     w14, w13
>>   b.cs    LABEL-1               ; if (offset >= limit) => uncommon-trap
>>   cmp     w11, #0x4
>>   b.lt    LABEL-2               ; if (limit - offset < vlength)
>>   mov     p1.b, p2.b
>> LABEL-3:
>>   ld1d    {z16.d}, p1/z, [x10]  ; load vector masked
>>   ...
>>   cmp     w14, w29
>>   b.cc    LOOP
>>   ...
>> LABEL-2:
>>   whilelo p1.d, x16, x10        ; VectorMaskGen
>>   ...
>>   b       LABEL-3
>>   ...
>> LABEL-1:
>>   uncommon-trap
>> 
>> 
>> Please note that if the array size `LENGTH` is aligned with
>> the vector size 256 (i.e. `LENGTH = 1024`), the branch "LABEL-2"
>> will be optimized out by compiler and it becomes another
>> uncommon-trap.
>> 
>> For NEON, the main CFG is the same with above. But the compiler
>> intrinsification is different. Here is the code:
>> 
>> 
>>   sub     x10, x10, x12          ; limit - offset
>>   scvtf   d16, x10
>>   dup     v16.2d, v16.d[0]       ; replicateD
>> 
>>   mov     x8, #0xd8d0
>>   movk    x8, #0x84cb, lsl #16
>>   movk    x8, #0xffff, lsl #32
>>   ldr     q17, [x8], #0          ; load the "iota" const vector
>>   fcmgt   v18.2d, v16.2d, v17.2d ; mask = iota < limit - offset
>> 
>> 
>> Here is the performance data of the new added benchmark on an ARM
>> SVE 256-bit platform:
>> 
>> 
>> Benchmark                               (size)  Before    After   Units
>> IndexInRangeBenchmark.byteIndexInRange   1024 11203.697 41404.431 ops/ms
>> IndexInRangeBenchmark.byteIndexInRange   1027  2365.920  8747.004 ops/ms
>> IndexInRangeBenchmark.doubleIndexInRange 1024  1227.505  6092.194 ops/ms
>> IndexInRangeBenchmark.doubleIndexInRange 1027   351.215  1156.683 ops/ms
>> IndexInRangeBenchmark.floatIndexInRange  1024  1468.876 11032.580 ops/ms
>> IndexInRangeBenchmark.floatIndexInRange  1027   699.645  2439.671 ops/ms
>> IndexInRangeBenchmark.intIndexInRange    1024  2842.187 11903.544 ops/ms
>> IndexInRangeBenchmark.intIndexInRange    1027   689.866  2547.424 ops/ms
>> IndexInRangeBenchmark.longIndexInRange   1024  1394.135  5902.973 ops/ms
>> IndexInRangeBenchmark.longIndexInRange   1027   355.621  1189.458 ops/ms
>> IndexInRangeBenchmark.shortIndexInRange  1024  5521.468 21578.340 ops/ms
>> IndexInRangeBenchmark.shortIndexInRange  1027  1264.816  4640.504 ops/ms
>> 
>> 
>> And the performance data with ARM NEON:
>> 
>> 
>> Benchmark                               (size)  Before    After   Units
>> IndexInRangeBenchmark.byteIndexInRange   1024  4026.548 15562.880 ops/ms
>> IndexInRangeBenchmark.byteIndexInRange   1027   305.314   576.559 ops/ms
>> IndexInRangeBenchmark.doubleIndexInRange 1024   289.224  2244.080 ops/ms
>> IndexInRangeBenchmark.doubleIndexInRange 1027    39.740    76.499 ops/ms
>> IndexInRangeBenchmark.floatIndexInRange  1024   675.264  4457.470 ops/ms
>> IndexInRangeBenchmark.floatIndexInRange  1027    79.918   144.952 ops/ms
>> IndexInRangeBenchmark.intIndexInRange    1024   740.139  4014.583 ops/ms
>> IndexInRangeBenchmark.intIndexInRange    1027    78.608   147.903 ops/ms
>> IndexInRangeBenchmark.longIndexInRange   1024   400.683  2209.551 ops/ms
>> IndexInRangeBenchmark.longIndexInRange   1027    41.146    69.599 ops/ms
>> IndexInRangeBenchmark.shortIndexInRange  1024  1821.736  8153.546 ops/ms
>> IndexInRangeBenchmark.shortIndexInRange  1027   158.810   243.205 ops/ms
>> 
>> 
>> The performance improves about `3.5x ~ 7.5x` on the vector size aligned
>> (1024 size) benchmarks both with NEON and SVE. And it improves about
>> `3.5x/1.8x` on the vector size not aligned (1027 size) benchmarks with
>> SVE/NEON respectively. We can also observe the similar improvement on
>> the x86 platforms.
>> 
>> [1] https://developer.arm.com/documentation/ddi0596/2020-12/SVE-Instructions/WHILELO--While-incrementing-unsigned-scalar-lower-than-scalar-
>
> src/jdk.incubator.vector/share/classes/jdk/incubator/vector/AbstractMask.java line 236:
> 
>> 234:         } else if (offset >= limit) {
>> 235:             return vectorSpecies().maskAll(false);
>> 236:         } else if (limit - offset >= length()) {
> 
> Can you move this else if check at the top, this is the most general case appearing in the loop and hence two extra uncommon trap jumps before it for special cases may penalize this.

Your patch re-organized the code to take care of following cases :-
1.   offset < 0                         : Still falling over to old code.
2.   offset >= limit                  : Special case optimized 
3.   (limit - offset) >= length  :  Most general case.
4.   Partial in range check       :  New intrinsic, existing java side implementation in checkIndex0 is also composed of intrinsified calls,  infrequently taken paths will anyways lead to uncommon traps.

Have you tried introducing just case 3 (first) and then case 2 in existing indexInRange implementation.

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

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

From pminborg at openjdk.org  Wed Feb  1 15:13:27 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 1 Feb 2023 15:13:27 GMT
Subject: RFR: 8300235: Use VarHandle access in Image(Input |
 Output)StreamImpl classes [v2]
In-Reply-To: <PPJBgKqkFFPV_e0GALCKfL3IXCw162qaY0IRWw4S0-M=.e118bdd0-f7b4-4765-9fba-5206ee264f7f@github.com>
References: <PPJBgKqkFFPV_e0GALCKfL3IXCw162qaY0IRWw4S0-M=.e118bdd0-f7b4-4765-9fba-5206ee264f7f@github.com>
Message-ID: <e0diTLO_z58sVZyjWMKvMWfcAPq5M_0dIQqru0--Pfc=.e8c039af-cdf7-4ce9-b59e-8e136cc05ddd@github.com>

> This PR suggests improving performance by using the newly introduced class `jdk.internal.util.ByteArray` to improve packing/unpacking operations.
> 
> The PR also proposes adding a `ByteArrayLittleEndian` class for support for little endian packing/unpacking.

Per Minborg has updated the pull request incrementally with one additional commit since the last revision:

  Add benchmark

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12204/files
  - new: https://git.openjdk.org/jdk/pull/12204/files/3fb71333..3b3873d5

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

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

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

From duke at openjdk.org  Wed Feb  1 18:28:25 2023
From: duke at openjdk.org (Scott Gibbons)
Date: Wed, 1 Feb 2023 18:28:25 GMT
Subject: RFR: JDK-8300808: Accelerate Base64 on x86 for AVX2 [v7]
In-Reply-To: <9zN3bjyMEikXYOlpjTy9_QPc-9usYiBJMUFdb-TaVrQ=.e8f65ce9-ac0f-4f8d-9c6b-b39ae1c26cd2@github.com>
References: <9zN3bjyMEikXYOlpjTy9_QPc-9usYiBJMUFdb-TaVrQ=.e8f65ce9-ac0f-4f8d-9c6b-b39ae1c26cd2@github.com>
Message-ID: <eyAXp-rZ5Dhd6F4jmDzFSeWJPknJBOhKN51delMUahc=.8f5d6102-5cb9-4fd1-8014-11812771962c@github.com>

> Added code for Base64 acceleration (encode and decode) which will accelerate ~4x for AVX2 platforms.
> 
> Encode performance:
> **Old:**
> 
> Benchmark                      (maxNumBytes)   Mode  Cnt     Score   Error   Units
> Base64Encode.testBase64Encode           1024  thrpt    3  4309.439 ? 2.632  ops/ms
> 
> 
> **New:**
> 
> Benchmark                      (maxNumBytes)   Mode  Cnt      Score     Error   Units
> Base64Encode.testBase64Encode           1024  thrpt    3  24211.397 ? 102.026  ops/ms
> 
> 
> Decode performance:
> **Old:**
> 
> Benchmark                      (errorIndex)  (lineSize)  (maxNumBytes)   Mode  Cnt     Score    Error   Units
> Base64Decode.testBase64Decode           144           4           1024  thrpt    3  3961.768 ? 93.409  ops/ms
> 
> **New:**
> Benchmark                      (errorIndex)  (lineSize)  (maxNumBytes)   Mode  Cnt      Score    Error   Units
> Base64Decode.testBase64Decode           144           4           1024  thrpt    3  14738.051 ? 24.383  ops/ms

Scott Gibbons has updated the pull request incrementally with one additional commit since the last revision:

  Handle AVX2 URL; address review comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12126/files
  - new: https://git.openjdk.org/jdk/pull/12126/files/3e66f7be..4007e984

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

  Stats: 94 lines in 4 files changed: 48 ins; 32 del; 14 mod
  Patch: https://git.openjdk.org/jdk/pull/12126.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12126/head:pull/12126

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

From stsypanov at openjdk.org  Wed Feb  1 18:59:51 2023
From: stsypanov at openjdk.org (Sergey Tsypanov)
Date: Wed, 1 Feb 2023 18:59:51 GMT
Subject: RFR: 8301552: Use AtomicReferenceArray for caching instead of CHM
 in ZoneOffset [v4]
In-Reply-To: <hsJDiMZ6OJcbc9z1577V64xshorl5wYbF1Lm3k8TUzs=.6d47a875-6190-4688-a0ac-12f48dbcfa72@github.com>
References: <b228oWPoEJf0lfGgIVXwmo1mATeKWRTivuJ2PbgwAmI=.465a4f9b-7a4b-4bbb-9f94-66d1d889a072@github.com>
 <hsJDiMZ6OJcbc9z1577V64xshorl5wYbF1Lm3k8TUzs=.6d47a875-6190-4688-a0ac-12f48dbcfa72@github.com>
Message-ID: <LRKtgfbpeUpRN5o7XLDKMRC1yIjCj10shl0EjXyvhvc=.da35247c-9a66-4a12-93f9-48c3e6c0b44f@github.com>

On Wed, 1 Feb 2023 13:18:31 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> `ZoneOffset` instances are cached by the `ZoneOffset` class itself for values in the range [-18h, 18h] for each second that is on an even quarter of an hour (i.e. at most 2*18*4+1 = 145 values). 
>> 
>> Instead of using a `ConcurrentHashMap` for caching instanced, we could instead use an `AtomicReferenceArray` with direct slot value access for said even seconds. This will improve performance and reduce the number of object even though the backing array will go from an initial 32 in the CHM to an initial/final 145 in the ARA. The CHM will contain much more objects and array slots for typical numbers of entries in the cache and will compute hash/bucket/collision on the hot code path for each cache access.
>
> Per Minborg has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Simplify benchmark
>  - Add benchmark

test/micro/org/openjdk/bench/java/time/ZoneOffsetBench.java line 66:

> 64:         for (int s : CACHED_SECONDS) {
> 65:             ZoneOffset zo = ZoneOffset.ofTotalSeconds(s);
> 66:             sum += zo.getTotalSeconds();

I think we should feed the value of `zo.getTotalSeconds()` into Blackhole, see https://github.com/openjdk/jmh/blob/master/jmh-samples/src/main/java/org/openjdk/jmh/samples/JMHSample_34_SafeLooping.java#L128

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

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

From darcy at openjdk.org  Wed Feb  1 19:01:04 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 1 Feb 2023 19:01:04 GMT
Subject: RFR: JDK-8301392: Port fdlibm log1p to Java [v3]
In-Reply-To: <pcpvsJ0ZUyvcmd2rPRuiq9rgJEceqJM_XmAWY8F2Ww0=.95bc61bd-21ff-4adb-b858-f954c9481914@github.com>
References: <g8yhvnKZcwHr9U-z5SqNsw2vLN7ZbdeF8bgazG7eFE4=.326c60bb-81c6-449f-b9bc-8ca5bdcfde99@github.com>
 <pcpvsJ0ZUyvcmd2rPRuiq9rgJEceqJM_XmAWY8F2Ww0=.95bc61bd-21ff-4adb-b858-f954c9481914@github.com>
Message-ID: <cdq9oDO62Jw4T8jeaopXYIANbSdPc6oOU1B1GGZYsr4=.cb358d99-d077-4a25-ba83-330ec688d14e@github.com>

On Wed, 1 Feb 2023 07:16:25 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Another day, another PR to port FDLBIM to Java, this time for the log1p method.
>> 
>> Other than using the two-argument form of the __HI method in Java transliteration version rather than C macro, there are no appreciable differences between the original C source in 
>> 
>> src/java.base/share/native/libfdlibm/s_log1p.c
>> 
>> and the transliteration for testing purposes in
>> 
>> test/jdk/java/lang/StrictMath/FdlibmTranslit.java
>> 
>> The more idiomatic port in
>> 
>> src/java.base/share/classes/java/lang/FdLibm.java
>> 
>> has had a series of transformation applied layering on the transliteration. The intermediate commits show the progress.
>> 
>> The regression tests include probing around input values the implementation uses to decided which branch to take.
>
> Joe Darcy has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Appease jcheck.
>  - Fix typo; improve tests.

PS To provide more context for the review, below are the "diff -w" output for the original C fdlibm with the transliteration port and the transliteration port with the more idiomatic port.


$ diff -w Log1p.c Log1p.translit.java 
1c1,2
< /* double log1p(double x)
---
>     /**
>      * Returns the natural logarithm of the sum of the argument and 1.
64a66,77
>     static class Log1p {
>         private static double ln2_hi  =  6.93147180369123816490e-01;  /* 3fe62e42 fee00000 */
>         private static double ln2_lo  =  1.90821492927058770002e-10;  /* 3dea39ef 35793c76 */
>         private static double two54   =  1.80143985094819840000e+16;  /* 43500000 00000000 */
>         private static double Lp1 = 6.666666666666735130e-01;  /* 3FE55555 55555593 */
>         private static double Lp2 = 3.999999999940941908e-01;  /* 3FD99999 9997FA04 */
>         private static double Lp3 = 2.857142874366239149e-01;  /* 3FD24924 94229359 */
>         private static double Lp4 = 2.222219843214978396e-01;  /* 3FCC71C5 1D8E78AF */
>         private static double Lp5 = 1.818357216161805012e-01;  /* 3FC74664 96CB03DE */
>         private static double Lp6 = 1.531383769920937332e-01;  /* 3FC39A09 D078C69F */
>         private static double Lp7 = 1.479819860511658591e-01;  /* 3FC2F112 DF3E5244 */
>         private static double zero = 0.0;
66,92c79
< #include "fdlibm.h"
< 
< #ifdef __STDC__
< static const double
< #else
< static double
< #endif
< ln2_hi  =  6.93147180369123816490e-01,  /* 3fe62e42 fee00000 */
< ln2_lo  =  1.90821492927058770002e-10,  /* 3dea39ef 35793c76 */
< two54   =  1.80143985094819840000e+16,  /* 43500000 00000000 */
< Lp1 = 6.666666666666735130e-01,  /* 3FE55555 55555593 */
< Lp2 = 3.999999999940941908e-01,  /* 3FD99999 9997FA04 */
< Lp3 = 2.857142874366239149e-01,  /* 3FD24924 94229359 */
< Lp4 = 2.222219843214978396e-01,  /* 3FCC71C5 1D8E78AF */
< Lp5 = 1.818357216161805012e-01,  /* 3FC74664 96CB03DE */
< Lp6 = 1.531383769920937332e-01,  /* 3FC39A09 D078C69F */
< Lp7 = 1.479819860511658591e-01;  /* 3FC2F112 DF3E5244 */
< 
< static double zero = 0.0;
< 
< #ifdef __STDC__
<         double log1p(double x)
< #else
<         double log1p(x)
<         double x;
< #endif
< {
---
>         public static double compute(double x) {
137c124
<                 __HI(u) = hu|0x3ff00000;        /* normalize u */
---
>                     u = __HI(u, hu|0x3ff00000);        /* normalize u */
140c127
<                 __HI(u) = hu|0x3fe00000;        /* normalize u/2 */
---
>                     u = __HI(u, hu|0x3fe00000);        /* normalize u/2 */
158a146
>     }


The constants are reformatted as expected and the __HI() C macro used on the left-hand side of an assignment is replaced by a Java method call.

And port-vs-port:


$ diff -w Log1p.translit.java Log1p.fdlibm.java 
67,77c67,75
<         private static double ln2_hi  =  6.93147180369123816490e-01;  /* 3fe62e42 fee00000 */
<         private static double ln2_lo  =  1.90821492927058770002e-10;  /* 3dea39ef 35793c76 */
<         private static double two54   =  1.80143985094819840000e+16;  /* 43500000 00000000 */
<         private static double Lp1 = 6.666666666666735130e-01;  /* 3FE55555 55555593 */
<         private static double Lp2 = 3.999999999940941908e-01;  /* 3FD99999 9997FA04 */
<         private static double Lp3 = 2.857142874366239149e-01;  /* 3FD24924 94229359 */
<         private static double Lp4 = 2.222219843214978396e-01;  /* 3FCC71C5 1D8E78AF */
<         private static double Lp5 = 1.818357216161805012e-01;  /* 3FC74664 96CB03DE */
<         private static double Lp6 = 1.531383769920937332e-01;  /* 3FC39A09 D078C69F */
<         private static double Lp7 = 1.479819860511658591e-01;  /* 3FC2F112 DF3E5244 */
<         private static double zero = 0.0;
---
>         private static final double ln2_hi = 0x1.62e42feep-1;       // 6.93147180369123816490e-01
>         private static final double ln2_lo = 0x1.a39ef35793c76p-33; // 1.90821492927058770002e-10
>         private static final double Lp1    = 0x1.5555555555593p-1;  // 6.666666666666735130e-01
>         private static final double Lp2    = 0x1.999999997fa04p-2;  // 3.999999999940941908e-01
>         private static final double Lp3    = 0x1.2492494229359p-2;  // 2.857142874366239149e-01
>         private static final double Lp4    = 0x1.c71c51d8e78afp-3;  // 2.222219843214978396e-01
>         private static final double Lp5    = 0x1.7466496cb03dep-3;  // 1.818357216161805012e-01
>         private static final double Lp6    = 0x1.39a09d078c69fp-3;  // 1.531383769920937332e-01
>         private static final double Lp7    = 0x1.2f112df3e5244p-3;  // 1.479819860511658591e-01
84c82
<             ax = hx&0x7fffffff;
---
>             ax = hx & 0x7fff_ffff;
87,94c85,88
<             if (hx < 0x3FDA827A) {                  /* x < 0.41422  */
<                 if(ax>=0x3ff00000) {                /* x <= -1.0 */
<                     /*
<                      * Added redundant test against hx to work around VC++
<                      * code generation problem.
<                      */
<                     if(x==-1.0 && (hx==0xbff00000)) /* log1p(-1)=-inf */
<                         return -two54/zero;
---
>             if (hx < 0x3FDA_827A) {                  /* x < 0.41422  */
>                 if (ax >= 0x3ff0_0000) {             /* x <= -1.0 */
>                     if (x == -1.0) /* log1p(-1)=-inf */
>                         return -INFINITY;
96c90
<                         return (x-x)/(x-x);           /* log1p(x<-1)=NaN */
---
>                         return Double.NaN;           /* log1p(x < -1) = NaN */
98,100c92,95
<                 if(ax<0x3e200000) {                 /* |x| < 2**-29 */
<                     if(two54+x>zero                 /* raise inexact */
<                        &&ax<0x3c900000)            /* |x| < 2**-54 */
---
> 
>                 if (ax < 0x3e20_0000) {                /* |x| < 2**-29 */
>                     if (TWO54 + x > 0.0                /* raise inexact */
>                        && ax < 0x3c90_0000)            /* |x| < 2**-54 */
105,106c100,105
<                 if(hx>0||hx<=((int)0xbfd2bec3)) {
<                     k=0;f=x;hu=1;}  /* -0.2929<x<0.41422 */
---
> 
>                 if (hx > 0 || hx <= 0xbfd2_bec3) { /* -0.2929 < x < 0.41422 */
>                     k=0;
>                     f=x;
>                     hu=1;
>                 }
108c107,111
<             if (hx >= 0x7ff00000) return x+x;
---
> 
>             if (hx >= 0x7ff0_0000) {
>                 return x+x;
>             }
> 
110c113
<                 if(hx<0x43400000) {
---
>                 if (hx < 0x4340_0000) {
122,124c125,127
<                 hu &= 0x000fffff;
<                 if(hu<0x6a09e) {
<                     u = __HI(u, hu|0x3ff00000);        /* normalize u */
---
>                 hu &= 0x000f_ffff;
>                 if (hu < 0x6_a09e) {
>                     u = __HI(u, hu | 0x3ff0_0000);       /* normalize u */
127,128c130,131
<                     u = __HI(u, hu|0x3fe00000);        /* normalize u/2 */
<                     hu = (0x00100000-hu)>>2;
---
>                     u = __HI(u, hu | 0x3fe0_0000);       /* normalize u/2 */
>                     hu = (0x0010_0000 - hu) >> 2;
131a135
> 
134,135c138,145
<                 if(f==zero) { if(k==0) return zero;
<                     else {c += k*ln2_lo; return k*ln2_hi+c;}}
---
>                 if (f == 0.0) {
>                     if (k == 0) {
>                         return 0.0;
>                     } else {
>                         c += k * ln2_lo;
>                         return k * ln2_hi + c;
>                     }
>                 }
137c147,149
<                 if(k==0) return f-R; else
---
>                 if (k == 0) {
>                     return f - R;
>                 } else {
139a152
>             }
143c156,158
<             if(k==0) return f-(hfsq-s*(hfsq+R)); else
---
>             if (k == 0) {
>                 return f-(hfsq-s*(hfsq+R));
>             } else {
144a160
>             }

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

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

From duke at openjdk.org  Wed Feb  1 19:07:17 2023
From: duke at openjdk.org (Scott Gibbons)
Date: Wed, 1 Feb 2023 19:07:17 GMT
Subject: RFR: JDK-8300808: Accelerate Base64 on x86 for AVX2 [v8]
In-Reply-To: <9zN3bjyMEikXYOlpjTy9_QPc-9usYiBJMUFdb-TaVrQ=.e8f65ce9-ac0f-4f8d-9c6b-b39ae1c26cd2@github.com>
References: <9zN3bjyMEikXYOlpjTy9_QPc-9usYiBJMUFdb-TaVrQ=.e8f65ce9-ac0f-4f8d-9c6b-b39ae1c26cd2@github.com>
Message-ID: <eF4pTseOICr9nNZQb-VHAkJN0Z2i0MBY1B3V91XI3u8=.46527b0e-d3ed-40df-a0ba-f52dd4cd318f@github.com>

> Added code for Base64 acceleration (encode and decode) which will accelerate ~4x for AVX2 platforms.
> 
> Encode performance:
> **Old:**
> 
> Benchmark                      (maxNumBytes)   Mode  Cnt     Score   Error   Units
> Base64Encode.testBase64Encode           1024  thrpt    3  4309.439 ? 2.632  ops/ms
> 
> 
> **New:**
> 
> Benchmark                      (maxNumBytes)   Mode  Cnt      Score     Error   Units
> Base64Encode.testBase64Encode           1024  thrpt    3  24211.397 ? 102.026  ops/ms
> 
> 
> Decode performance:
> **Old:**
> 
> Benchmark                      (errorIndex)  (lineSize)  (maxNumBytes)   Mode  Cnt     Score    Error   Units
> Base64Decode.testBase64Decode           144           4           1024  thrpt    3  3961.768 ? 93.409  ops/ms
> 
> **New:**
> Benchmark                      (errorIndex)  (lineSize)  (maxNumBytes)   Mode  Cnt      Score    Error   Units
> Base64Decode.testBase64Decode           144           4           1024  thrpt    3  14738.051 ? 24.383  ops/ms

Scott Gibbons has updated the pull request incrementally with one additional commit since the last revision:

  Change break-even buffer size for AVX512

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12126/files
  - new: https://git.openjdk.org/jdk/pull/12126/files/4007e984..80fbf4ef

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

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

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

From darcy at openjdk.org  Wed Feb  1 19:19:05 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 1 Feb 2023 19:19:05 GMT
Subject: RFR: JDK-8301392: Port fdlibm log1p to Java [v4]
In-Reply-To: <g8yhvnKZcwHr9U-z5SqNsw2vLN7ZbdeF8bgazG7eFE4=.326c60bb-81c6-449f-b9bc-8ca5bdcfde99@github.com>
References: <g8yhvnKZcwHr9U-z5SqNsw2vLN7ZbdeF8bgazG7eFE4=.326c60bb-81c6-449f-b9bc-8ca5bdcfde99@github.com>
Message-ID: <iP_zmf7-2sC65mDLRC3CCTITEwj1OpxXGp1OBfBaIFg=.a4e5e7db-9dba-47db-8fbf-cfbd94984d22@github.com>

> Another day, another PR to port FDLBIM to Java, this time for the log1p method.
> 
> Other than using the two-argument form of the __HI method in Java transliteration version rather than C macro, there are no appreciable differences between the original C source in 
> 
> src/java.base/share/native/libfdlibm/s_log1p.c
> 
> and the transliteration for testing purposes in
> 
> test/jdk/java/lang/StrictMath/FdlibmTranslit.java
> 
> The more idiomatic port in
> 
> src/java.base/share/classes/java/lang/FdLibm.java
> 
> has had a series of transformation applied layering on the transliteration. The intermediate commits show the progress.
> 
> The regression tests include probing around input values the implementation uses to decided which branch to take.

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

  Improve spacing.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12301/files
  - new: https://git.openjdk.org/jdk/pull/12301/files/87a14ecc..b3e028ac

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

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

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

From mchung at openjdk.org  Wed Feb  1 19:59:10 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Wed, 1 Feb 2023 19:59:10 GMT
Subject: RFR: JDK-8284236: Remove java/lang/ref/ReferenceEnqueue.java from
 ProblemList-Xcomp.txt
Message-ID: <uIAaiv447U5bZLGNKv16ktaCy0DvY1j82eZCtb_ADdM=.eeec9a68-4778-4a8c-b4cd-47f71b1abecc@github.com>

This test failure is no longer reproducible.   It was added to the problem list from JDK-8286368 as a clean up after JEP 425 Virtual Threads integration.  This PR removes it from the problem list.

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

Commit messages:
 - JDK-8284236: Remove java/lang/ref/ReferenceEnqueue.java from ProblemList-Xcomp.txt

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

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

From alanb at openjdk.org  Wed Feb  1 19:59:11 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 1 Feb 2023 19:59:11 GMT
Subject: RFR: JDK-8284236: Remove java/lang/ref/ReferenceEnqueue.java from
 ProblemList-Xcomp.txt
In-Reply-To: <uIAaiv447U5bZLGNKv16ktaCy0DvY1j82eZCtb_ADdM=.eeec9a68-4778-4a8c-b4cd-47f71b1abecc@github.com>
References: <uIAaiv447U5bZLGNKv16ktaCy0DvY1j82eZCtb_ADdM=.eeec9a68-4778-4a8c-b4cd-47f71b1abecc@github.com>
Message-ID: <oRZgG4InChnAsNloGTdd1zkxOSGKF0N9dlgcRA5501c=.1cd1e159-7218-458d-b4af-2d779455cfb2@github.com>

On Wed, 1 Feb 2023 19:09:48 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> This test failure is no longer reproducible.   It was added to the problem list from JDK-8286368 as a clean up after JEP 425 Virtual Threads integration.  This PR removes it from the problem list.

Marked as reviewed by alanb (Reviewer).

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

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

From duke at openjdk.org  Wed Feb  1 20:08:49 2023
From: duke at openjdk.org (kabutz)
Date: Wed, 1 Feb 2023 20:08:49 GMT
Subject: RFR: JDK-8301637: Fixed bug that regressed TLR.doubles()
Message-ID: <-mno_ek28PD0IyhDHBc3-ZCqGFq9G5t_Yt73ub665uA=.5e3e655e-631d-4302-b91c-6288581a1070@github.com>

ThreadLocalRandom.current().doubles().parallel() had a bad regression, because it called the superclass methods of the ThreadLocalRandomProxy's nextDouble() method instead of delegating to the ThreadLocalRandom.current().

Affects all versions of ThreadLocalRandom since Java 17.

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

Commit messages:
 - Fixed bug that regressed TLR.doubles()

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

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

From duke at openjdk.org  Wed Feb  1 20:22:49 2023
From: duke at openjdk.org (cheenar)
Date: Wed, 1 Feb 2023 20:22:49 GMT
Subject: RFR: 8301552: Use AtomicReferenceArray for caching instead of CHM
 in ZoneOffset [v4]
In-Reply-To: <hsJDiMZ6OJcbc9z1577V64xshorl5wYbF1Lm3k8TUzs=.6d47a875-6190-4688-a0ac-12f48dbcfa72@github.com>
References: <b228oWPoEJf0lfGgIVXwmo1mATeKWRTivuJ2PbgwAmI=.465a4f9b-7a4b-4bbb-9f94-66d1d889a072@github.com>
 <hsJDiMZ6OJcbc9z1577V64xshorl5wYbF1Lm3k8TUzs=.6d47a875-6190-4688-a0ac-12f48dbcfa72@github.com>
Message-ID: <05rUH2WPjpBg564PQ1g8t7Sq5Ui4-hZ8mnUAQj3uYqU=.bcc1afda-8172-4e4c-9afe-d5272b60defc@github.com>

On Wed, 1 Feb 2023 13:18:31 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> `ZoneOffset` instances are cached by the `ZoneOffset` class itself for values in the range [-18h, 18h] for each second that is on an even quarter of an hour (i.e. at most 2*18*4+1 = 145 values). 
>> 
>> Instead of using a `ConcurrentHashMap` for caching instanced, we could instead use an `AtomicReferenceArray` with direct slot value access for said even seconds. This will improve performance and reduce the number of object even though the backing array will go from an initial 32 in the CHM to an initial/final 145 in the ARA. The CHM will contain much more objects and array slots for typical numbers of entries in the cache and will compute hash/bucket/collision on the hot code path for each cache access.
>
> Per Minborg has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Simplify benchmark
>  - Add benchmark

test/jdk/java/time/tck/java/time/zone/TCKFixedZoneRules.java line 141:

> 139:     @Test(dataProvider="rules")
> 140:     public void test_isValidOffset_LDT_ZO(ZoneRules test, ZoneOffset expectedOffset) {
> 141:         if (expectedOffset == ZoneOffset.UTC)

Extremely minor but why not wrap if with `{}` for improved readability here with the comment

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

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

From duke at openjdk.org  Wed Feb  1 20:22:51 2023
From: duke at openjdk.org (cheenar)
Date: Wed, 1 Feb 2023 20:22:51 GMT
Subject: RFR: 8301552: Use AtomicReferenceArray for caching instead of CHM
 in ZoneOffset [v4]
In-Reply-To: <05rUH2WPjpBg564PQ1g8t7Sq5Ui4-hZ8mnUAQj3uYqU=.bcc1afda-8172-4e4c-9afe-d5272b60defc@github.com>
References: <b228oWPoEJf0lfGgIVXwmo1mATeKWRTivuJ2PbgwAmI=.465a4f9b-7a4b-4bbb-9f94-66d1d889a072@github.com>
 <hsJDiMZ6OJcbc9z1577V64xshorl5wYbF1Lm3k8TUzs=.6d47a875-6190-4688-a0ac-12f48dbcfa72@github.com>
 <05rUH2WPjpBg564PQ1g8t7Sq5Ui4-hZ8mnUAQj3uYqU=.bcc1afda-8172-4e4c-9afe-d5272b60defc@github.com>
Message-ID: <4H30se4qw_TKSWrvInldU08F3KKcHmAPPSSuWc9kXYY=.6e30a782-6617-43f9-83d2-8237d5389b85@github.com>

On Wed, 1 Feb 2023 20:16:56 GMT, cheenar <duke at openjdk.org> wrote:

>> Per Minborg has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Simplify benchmark
>>  - Add benchmark
>
> test/jdk/java/time/tck/java/time/zone/TCKFixedZoneRules.java line 141:
> 
>> 139:     @Test(dataProvider="rules")
>> 140:     public void test_isValidOffset_LDT_ZO(ZoneRules test, ZoneOffset expectedOffset) {
>> 141:         if (expectedOffset == ZoneOffset.UTC)
> 
> Extremely minor but why not wrap if with `{}` for improved readability here with the comment

Same [here](https://github.com/openjdk/jdk/pull/12346/commits/ec49ca3bc03d2e97fa0429c84290923066667871?diff=unified&w=0#diff-9e5aa282dc2d02c31e1d7c5ec8196a1d3d23c06e471d5114d0bd0c78ee4fe5f6R433) although it feels much more dangerous than the test!

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

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

From mchung at openjdk.org  Wed Feb  1 20:30:36 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Wed, 1 Feb 2023 20:30:36 GMT
Subject: Integrated: JDK-8284236: Remove java/lang/ref/ReferenceEnqueue.java
 from ProblemList-Xcomp.txt
In-Reply-To: <uIAaiv447U5bZLGNKv16ktaCy0DvY1j82eZCtb_ADdM=.eeec9a68-4778-4a8c-b4cd-47f71b1abecc@github.com>
References: <uIAaiv447U5bZLGNKv16ktaCy0DvY1j82eZCtb_ADdM=.eeec9a68-4778-4a8c-b4cd-47f71b1abecc@github.com>
Message-ID: <4spA2u4mB04X5fMMHOcEhNTvdv6IUrhDAhv8hRwVDVY=.94aee2b9-ff9f-4795-b002-033a8969df7c@github.com>

On Wed, 1 Feb 2023 19:09:48 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> This test failure is no longer reproducible.   It was added to the problem list from JDK-8286368 as a clean up after JEP 425 Virtual Threads integration.  This PR removes it from the problem list.

This pull request has now been integrated.

Changeset: 51ac8783
Author:    Mandy Chung <mchung at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/51ac8783b951258cb05f899e1f84fdf1d184bc03
Stats:     1 line in 1 file changed: 0 ins; 1 del; 0 mod

8284236: Remove java/lang/ref/ReferenceEnqueue.java from ProblemList-Xcomp.txt

Reviewed-by: alanb

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

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

From duke at openjdk.org  Wed Feb  1 20:32:10 2023
From: duke at openjdk.org (kabutz)
Date: Wed, 1 Feb 2023 20:32:10 GMT
Subject: RFR: 8301637: ThreadLocalRandom.current().doubles().parallel()
 contention
In-Reply-To: <-mno_ek28PD0IyhDHBc3-ZCqGFq9G5t_Yt73ub665uA=.5e3e655e-631d-4302-b91c-6288581a1070@github.com>
References: <-mno_ek28PD0IyhDHBc3-ZCqGFq9G5t_Yt73ub665uA=.5e3e655e-631d-4302-b91c-6288581a1070@github.com>
Message-ID: <a7-KfA95JowhNDOETcGFRPDZsIeMcXvLMxDj814kutM=.9f55606f-983c-4e30-a712-cbd9df9d2cce@github.com>

On Wed, 1 Feb 2023 15:51:33 GMT, kabutz <duke at openjdk.org> wrote:

> ThreadLocalRandom.current().doubles().parallel() had a bad regression, because it called the superclass methods of the ThreadLocalRandomProxy's nextDouble() method instead of delegating to the ThreadLocalRandom.current().
> 
> Affects all versions of ThreadLocalRandom since Java 17.

Could this fix be back-ported to JDK 17? It's been an issue from then until now.

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

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

From darcy at openjdk.org  Wed Feb  1 20:41:15 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 1 Feb 2023 20:41:15 GMT
Subject: RFR: 8301637: ThreadLocalRandom.current().doubles().parallel()
 contention
In-Reply-To: <a7-KfA95JowhNDOETcGFRPDZsIeMcXvLMxDj814kutM=.9f55606f-983c-4e30-a712-cbd9df9d2cce@github.com>
References: <-mno_ek28PD0IyhDHBc3-ZCqGFq9G5t_Yt73ub665uA=.5e3e655e-631d-4302-b91c-6288581a1070@github.com>
 <a7-KfA95JowhNDOETcGFRPDZsIeMcXvLMxDj814kutM=.9f55606f-983c-4e30-a712-cbd9df9d2cce@github.com>
Message-ID: <-4YVbBvKxM5xV25E1_3WusREckyEBc2qURgt0fbe_Ts=.3d90b84b-71f3-4a5d-a567-73d3affc0d7f@github.com>

On Wed, 1 Feb 2023 20:29:27 GMT, kabutz <duke at openjdk.org> wrote:

> Could this fix be back-ported to JDK 17? It's been an issue from then until now.

Assuming the fix goes into mainline, there are procedures for backporting to the update releases; e.g.

https://wiki.openjdk.org/display/JDKUpdates/JDK+17u

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

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

From redestad at openjdk.org  Wed Feb  1 20:57:05 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Wed, 1 Feb 2023 20:57:05 GMT
Subject: RFR: JDK-8300808: Accelerate Base64 on x86 for AVX2 [v7]
In-Reply-To: <eyAXp-rZ5Dhd6F4jmDzFSeWJPknJBOhKN51delMUahc=.8f5d6102-5cb9-4fd1-8014-11812771962c@github.com>
References: <9zN3bjyMEikXYOlpjTy9_QPc-9usYiBJMUFdb-TaVrQ=.e8f65ce9-ac0f-4f8d-9c6b-b39ae1c26cd2@github.com>
 <eyAXp-rZ5Dhd6F4jmDzFSeWJPknJBOhKN51delMUahc=.8f5d6102-5cb9-4fd1-8014-11812771962c@github.com>
Message-ID: <qJm4si333sDFG9blT75d2B8HdmEXMqOg0NgsPq9N1o0=.ae3077ce-390a-481b-9402-ad9b8009c5c2@github.com>

On Wed, 1 Feb 2023 18:28:25 GMT, Scott Gibbons <duke at openjdk.org> wrote:

>> Added code for Base64 acceleration (encode and decode) which will accelerate ~4x for AVX2 platforms.
>> 
>> Encode performance:
>> **Old:**
>> 
>> Benchmark                      (maxNumBytes)   Mode  Cnt     Score   Error   Units
>> Base64Encode.testBase64Encode           1024  thrpt    3  4309.439 ? 2.632  ops/ms
>> 
>> 
>> **New:**
>> 
>> Benchmark                      (maxNumBytes)   Mode  Cnt      Score     Error   Units
>> Base64Encode.testBase64Encode           1024  thrpt    3  24211.397 ? 102.026  ops/ms
>> 
>> 
>> Decode performance:
>> **Old:**
>> 
>> Benchmark                      (errorIndex)  (lineSize)  (maxNumBytes)   Mode  Cnt     Score    Error   Units
>> Base64Decode.testBase64Decode           144           4           1024  thrpt    3  3961.768 ? 93.409  ops/ms
>> 
>> **New:**
>> Benchmark                      (errorIndex)  (lineSize)  (maxNumBytes)   Mode  Cnt      Score    Error   Units
>> Base64Decode.testBase64Decode           144           4           1024  thrpt    3  14738.051 ? 24.383  ops/ms
>
> Scott Gibbons has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Handle AVX2 URL; address review comments

src/hotspot/cpu/x86/stubGenerator_x86_64.cpp line 2202:

> 2200: }
> 2201: 
> 2202: address StubGenerator::base64_AVX2_decode_URL_tables_addr() {

Shouldn't this be `decode_lut_tables`? As it's used for URL and non-URL decoding alike.

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

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

From duke at openjdk.org  Wed Feb  1 21:02:31 2023
From: duke at openjdk.org (Scott Gibbons)
Date: Wed, 1 Feb 2023 21:02:31 GMT
Subject: RFR: JDK-8300808: Accelerate Base64 on x86 for AVX2 [v7]
In-Reply-To: <qJm4si333sDFG9blT75d2B8HdmEXMqOg0NgsPq9N1o0=.ae3077ce-390a-481b-9402-ad9b8009c5c2@github.com>
References: <9zN3bjyMEikXYOlpjTy9_QPc-9usYiBJMUFdb-TaVrQ=.e8f65ce9-ac0f-4f8d-9c6b-b39ae1c26cd2@github.com>
 <eyAXp-rZ5Dhd6F4jmDzFSeWJPknJBOhKN51delMUahc=.8f5d6102-5cb9-4fd1-8014-11812771962c@github.com>
 <qJm4si333sDFG9blT75d2B8HdmEXMqOg0NgsPq9N1o0=.ae3077ce-390a-481b-9402-ad9b8009c5c2@github.com>
Message-ID: <yH0SmOEnIsEo6bCgNRCBy5Pv7EeyuUn3pAvUswyVQjI=.4a4915bd-3f89-4c5b-8fc8-7206c2885cff@github.com>

On Wed, 1 Feb 2023 20:53:54 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> Scott Gibbons has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Handle AVX2 URL; address review comments
>
> src/hotspot/cpu/x86/stubGenerator_x86_64.cpp line 2202:
> 
>> 2200: }
>> 2201: 
>> 2202: address StubGenerator::base64_AVX2_decode_URL_tables_addr() {
> 
> Shouldn't this be `decode_lut_tables`? As it's used for URL and non-URL decoding alike.

These tables are used for both URL and non-URL based on the parameter, and they are only two of the three lut tables used (the other is in `base64_AVX2_decode_tables_addr` ).  Both names are essentially incorrect.  Does the name really matter that much?  It's the same as `base64_AVX2_decode_tables_addr` with the addition of URL tables.

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

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

From duke at openjdk.org  Wed Feb  1 21:02:38 2023
From: duke at openjdk.org (Scott Gibbons)
Date: Wed, 1 Feb 2023 21:02:38 GMT
Subject: RFR: JDK-8300808: Accelerate Base64 on x86 for AVX2 [v6]
In-Reply-To: <XXsryYpVQwgwFSW9J0Ii9PDOIZN15oTfDo0izJWTp0s=.0e0e4e97-1675-4315-9f99-686879de365b@github.com>
References: <9zN3bjyMEikXYOlpjTy9_QPc-9usYiBJMUFdb-TaVrQ=.e8f65ce9-ac0f-4f8d-9c6b-b39ae1c26cd2@github.com>
 <0oERFNuGS7s0R-naHhheLiPGTQvo7jHbTtR47LGOSE8=.1401d6bb-7095-425d-ad45-83fbed127c3c@github.com>
 <XXsryYpVQwgwFSW9J0Ii9PDOIZN15oTfDo0izJWTp0s=.0e0e4e97-1675-4315-9f99-686879de365b@github.com>
Message-ID: <q7vszdnmkg3TLWwSc3dL7710UjtV13EgFMaa9ClnEWA=.77cac473-9cc3-4adf-8043-353c42428274@github.com>

On Fri, 27 Jan 2023 21:45:37 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> Scott Gibbons has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 13 additional commits since the last revision:
>> 
>>  - Merge branch 'openjdk:master' into Base64-AVX2
>>  - Merge branch 'openjdk:master' into Base64-AVX2
>>  - Merge branch 'openjdk:master' into Base64-AVX2
>>  - Merge branch 'Base64-AVX2' of https://github.com/asgibbons/jdk into Base64-AVX2
>>  - Merge branch 'openjdk:master' into Base64-AVX2
>>  - Address review comment
>>  - Remove whitespace
>>  - Fix wrong register usage
>>  - Working version of Base64 decode with AVX2 (4x perf improvement). No URL support
>>  - Merge branch 'Base64-AVX2' of https://github.com/asgibbons/jdk into Base64-AVX2
>>  - ... and 3 more: https://git.openjdk.org/jdk/compare/52737e0d...3e66f7be
>
> src/hotspot/cpu/x86/stubGenerator_x86_64.cpp line 2651:
> 
>> 2649:     __ jcc(Assembler::notZero, L_tailProc);
>> 2650: 
>> 2651:     __ cmpl(length, 44);
> 
> Perform `length` checks first to avoid unnecessary branches on small inputs?
> 
> Ideal might be to move this length check up just before the `_cmpl(length, 128)` in the AVX-512 block, so that if `AVX=3` short inputs branch directly to the scalar tail procedure without jumping around. This might also apply to the encode stub, though that's pre-existing.

Done.

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

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

From redestad at openjdk.org  Thu Feb  2 00:37:29 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Thu, 2 Feb 2023 00:37:29 GMT
Subject: RFR: JDK-8300808: Accelerate Base64 on x86 for AVX2 [v7]
In-Reply-To: <yH0SmOEnIsEo6bCgNRCBy5Pv7EeyuUn3pAvUswyVQjI=.4a4915bd-3f89-4c5b-8fc8-7206c2885cff@github.com>
References: <9zN3bjyMEikXYOlpjTy9_QPc-9usYiBJMUFdb-TaVrQ=.e8f65ce9-ac0f-4f8d-9c6b-b39ae1c26cd2@github.com>
 <eyAXp-rZ5Dhd6F4jmDzFSeWJPknJBOhKN51delMUahc=.8f5d6102-5cb9-4fd1-8014-11812771962c@github.com>
 <qJm4si333sDFG9blT75d2B8HdmEXMqOg0NgsPq9N1o0=.ae3077ce-390a-481b-9402-ad9b8009c5c2@github.com>
 <yH0SmOEnIsEo6bCgNRCBy5Pv7EeyuUn3pAvUswyVQjI=.4a4915bd-3f89-4c5b-8fc8-7206c2885cff@github.com>
Message-ID: <CvrXAGNcDEJr-xaovmpYAmO4-G5m193XowKMLLX8GeQ=.0cf6fc11-1710-4b2e-b3d8-d17e445490e7@github.com>

On Wed, 1 Feb 2023 20:59:24 GMT, Scott Gibbons <duke at openjdk.org> wrote:

>> src/hotspot/cpu/x86/stubGenerator_x86_64.cpp line 2202:
>> 
>>> 2200: }
>>> 2201: 
>>> 2202: address StubGenerator::base64_AVX2_decode_URL_tables_addr() {
>> 
>> Shouldn't this be `decode_lut_tables`? As it's used for URL and non-URL decoding alike.
>
> These tables are used for both URL and non-URL based on the parameter, and they are only two of the three lut tables used (the other is in `base64_AVX2_decode_tables_addr` ).  Both names are essentially incorrect.  Does the name really matter that much?  It's the same as `base64_AVX2_decode_tables_addr` with the addition of URL tables.

Names are important, but always hard to get right. At the very least they need to be correct. Maybe call it something like `..parameterized_decode_tables..` and the other `..shared_decode_tables..`?

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

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

From xgong at openjdk.org  Thu Feb  2 01:42:25 2023
From: xgong at openjdk.org (Xiaohong Gong)
Date: Thu, 2 Feb 2023 01:42:25 GMT
Subject: RFR: 8293198: [vectorapi] Improve the implementation of
 VectorMask.indexInRange()
In-Reply-To: <ueWKU-J85vkS2Iss-2P1YvBAgbywubU6rnXLI4ddZ-o=.b566a7e6-98cb-4897-ab61-970e3388ff5a@github.com>
References: <fN58bi3n01tqWpG0-jjUPZQe8hmls2GQ5X3NL2o1RPg=.80e7965d-50af-4fac-bd7c-0a2b99cffe7e@github.com>
 <ueWKU-J85vkS2Iss-2P1YvBAgbywubU6rnXLI4ddZ-o=.b566a7e6-98cb-4897-ab61-970e3388ff5a@github.com>
Message-ID: <6zxbdPTPUEFWpjSHyb1Z7esniTQHJtMHfsgJAMTuL5U=.230c51d7-7156-400f-9420-3c679dd01ea2@github.com>

On Wed, 1 Feb 2023 13:22:07 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> The Vector API `"indexInRange(int offset, int limit)"` is used
>> to compute a vector mask whose lanes are set to true if the
>> index of the lane is inside the range specified by the `"offset"`
>> and `"limit"` arguments, otherwise the lanes are set to false.
>> 
>> There are two special cases for this API:
>>  1) If `"offset >= 0 && offset >= limit"`, all the lanes of the
>> generated mask are false.
>>  2) If` "offset >= 0 && limit - offset >= vlength"`, all the
>> lanes of the generated mask are true. Note that `"vlength"` is
>> the number of vector lanes.
>> 
>> For such special cases, we can simply use `"maskAll(false|true)"`
>> to implement the API. Otherwise, the original comparison with
>> `"iota" `vector is needed. And for further optimization, we have
>> optimal instruction supported by SVE (i.e. whilelo [1]), which
>> can implement the API directly if the `"offset >= 0"`.
>> 
>> As a summary, to optimize the API, we can use the if-else branches
>> to handle the specific cases in java level and intrinsify the
>> remaining case by C2 compiler:
>> 
>> 
>>   public VectorMask<E> indexInRange(int offset, int limit) {
>>       if (offset < 0) {
>>           return this.and(indexInRange0Helper(offset, limit));
>>       } else if (offset >= limit) {
>>           return this.and(vectorSpecies().maskAll(false));
>>       } else if (limit - offset >= length()) {
>>           return this.and(vectorSpecies().maskAll(true));
>>       }
>>       return this.and(indexInRange0(offset, limit));
>>  }
>> 
>> 
>> The last part (i.e. `"indexInRange0"`) in the above implementation
>> is expected to be intrinsified by C2 compiler if the necessary IRs
>> are supported. Otherwise, it will fall back to the original API
>> implementation (i.e. `"indexInRange0Helper"`). Regarding to the
>> intrinsifaction, the compiler will generate `"VectorMaskGen"` IR
>> with "limit - offset" as the input if the current platform supports
>> it. Otherwise, it generates `"VectorLoadConst + VectorMaskCmp"` based
>> on `"iota < limit - offset"`.
>> 
>> For the following java code which uses `"indexInRange"`:
>> 
>> 
>> static final VectorSpecies<Double> SPECIES =
>>                                    DoubleVector.SPECIES_PREFERRED;
>> static final int LENGTH = 1027;
>> 
>> public static double[] da;
>> public static double[] db;
>> public static double[] dc;
>> 
>> private static void func() {
>>     for (int i = 0; i < LENGTH; i += SPECIES.length()) {
>>         var m = SPECIES.indexInRange(i, LENGTH);
>>         var av = DoubleVector.fromArray(SPECIES, da, i, m);
>>         av.lanewise(VectorOperators.NEG).intoArray(dc, i, m);
>>     }
>> }
>> 
>> 
>> The core code generated with SVE 256-bit vector size is:
>> 
>> 
>>   ptrue   p2.d                  ; maskAll(true)
>>   ...
>> LOOP:
>>   ...
>>   sub     w11, w13, w14         ; limit - offset
>>   cmp     w14, w13
>>   b.cs    LABEL-1               ; if (offset >= limit) => uncommon-trap
>>   cmp     w11, #0x4
>>   b.lt    LABEL-2               ; if (limit - offset < vlength)
>>   mov     p1.b, p2.b
>> LABEL-3:
>>   ld1d    {z16.d}, p1/z, [x10]  ; load vector masked
>>   ...
>>   cmp     w14, w29
>>   b.cc    LOOP
>>   ...
>> LABEL-2:
>>   whilelo p1.d, x16, x10        ; VectorMaskGen
>>   ...
>>   b       LABEL-3
>>   ...
>> LABEL-1:
>>   uncommon-trap
>> 
>> 
>> Please note that if the array size `LENGTH` is aligned with
>> the vector size 256 (i.e. `LENGTH = 1024`), the branch "LABEL-2"
>> will be optimized out by compiler and it becomes another
>> uncommon-trap.
>> 
>> For NEON, the main CFG is the same with above. But the compiler
>> intrinsification is different. Here is the code:
>> 
>> 
>>   sub     x10, x10, x12          ; limit - offset
>>   scvtf   d16, x10
>>   dup     v16.2d, v16.d[0]       ; replicateD
>> 
>>   mov     x8, #0xd8d0
>>   movk    x8, #0x84cb, lsl #16
>>   movk    x8, #0xffff, lsl #32
>>   ldr     q17, [x8], #0          ; load the "iota" const vector
>>   fcmgt   v18.2d, v16.2d, v17.2d ; mask = iota < limit - offset
>> 
>> 
>> Here is the performance data of the new added benchmark on an ARM
>> SVE 256-bit platform:
>> 
>> 
>> Benchmark                               (size)  Before    After   Units
>> IndexInRangeBenchmark.byteIndexInRange   1024 11203.697 41404.431 ops/ms
>> IndexInRangeBenchmark.byteIndexInRange   1027  2365.920  8747.004 ops/ms
>> IndexInRangeBenchmark.doubleIndexInRange 1024  1227.505  6092.194 ops/ms
>> IndexInRangeBenchmark.doubleIndexInRange 1027   351.215  1156.683 ops/ms
>> IndexInRangeBenchmark.floatIndexInRange  1024  1468.876 11032.580 ops/ms
>> IndexInRangeBenchmark.floatIndexInRange  1027   699.645  2439.671 ops/ms
>> IndexInRangeBenchmark.intIndexInRange    1024  2842.187 11903.544 ops/ms
>> IndexInRangeBenchmark.intIndexInRange    1027   689.866  2547.424 ops/ms
>> IndexInRangeBenchmark.longIndexInRange   1024  1394.135  5902.973 ops/ms
>> IndexInRangeBenchmark.longIndexInRange   1027   355.621  1189.458 ops/ms
>> IndexInRangeBenchmark.shortIndexInRange  1024  5521.468 21578.340 ops/ms
>> IndexInRangeBenchmark.shortIndexInRange  1027  1264.816  4640.504 ops/ms
>> 
>> 
>> And the performance data with ARM NEON:
>> 
>> 
>> Benchmark                               (size)  Before    After   Units
>> IndexInRangeBenchmark.byteIndexInRange   1024  4026.548 15562.880 ops/ms
>> IndexInRangeBenchmark.byteIndexInRange   1027   305.314   576.559 ops/ms
>> IndexInRangeBenchmark.doubleIndexInRange 1024   289.224  2244.080 ops/ms
>> IndexInRangeBenchmark.doubleIndexInRange 1027    39.740    76.499 ops/ms
>> IndexInRangeBenchmark.floatIndexInRange  1024   675.264  4457.470 ops/ms
>> IndexInRangeBenchmark.floatIndexInRange  1027    79.918   144.952 ops/ms
>> IndexInRangeBenchmark.intIndexInRange    1024   740.139  4014.583 ops/ms
>> IndexInRangeBenchmark.intIndexInRange    1027    78.608   147.903 ops/ms
>> IndexInRangeBenchmark.longIndexInRange   1024   400.683  2209.551 ops/ms
>> IndexInRangeBenchmark.longIndexInRange   1027    41.146    69.599 ops/ms
>> IndexInRangeBenchmark.shortIndexInRange  1024  1821.736  8153.546 ops/ms
>> IndexInRangeBenchmark.shortIndexInRange  1027   158.810   243.205 ops/ms
>> 
>> 
>> The performance improves about `3.5x ~ 7.5x` on the vector size aligned
>> (1024 size) benchmarks both with NEON and SVE. And it improves about
>> `3.5x/1.8x` on the vector size not aligned (1027 size) benchmarks with
>> SVE/NEON respectively. We can also observe the similar improvement on
>> the x86 platforms.
>> 
>> [1] https://developer.arm.com/documentation/ddi0596/2020-12/SVE-Instructions/WHILELO--While-incrementing-unsigned-scalar-lower-than-scalar-
>
> src/jdk.incubator.vector/share/classes/jdk/incubator/vector/AbstractMask.java line 239:
> 
>> 237:             return this;
>> 238:         }
>> 239:         return this.and(indexInRange0(offset, limit));
> 
> Not related to this patch, but I also see a possibility of following ideal transformations:-
>         maskAll(true).allTrue() => true 
>         maskAll(false).anyTrue() => false

Agree! Maybe we could create another PR to handle these optimization in JIT-compiler.

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

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

From xgong at openjdk.org  Thu Feb  2 02:02:24 2023
From: xgong at openjdk.org (Xiaohong Gong)
Date: Thu, 2 Feb 2023 02:02:24 GMT
Subject: RFR: 8293198: [vectorapi] Improve the implementation of
 VectorMask.indexInRange()
In-Reply-To: <xrdln-eR6POz41Xgq4fVbV6FPVQ_Eq0dCcRhOx6dGIs=.6d29b24c-71c1-4906-b256-b2cc6af25a75@github.com>
References: <fN58bi3n01tqWpG0-jjUPZQe8hmls2GQ5X3NL2o1RPg=.80e7965d-50af-4fac-bd7c-0a2b99cffe7e@github.com>
 <ueWKU-J85vkS2Iss-2P1YvBAgbywubU6rnXLI4ddZ-o=.b566a7e6-98cb-4897-ab61-970e3388ff5a@github.com>
 <xrdln-eR6POz41Xgq4fVbV6FPVQ_Eq0dCcRhOx6dGIs=.6d29b24c-71c1-4906-b256-b2cc6af25a75@github.com>
Message-ID: <DlZuIlO-osVsKxMFzvRydSpz_g6g7c42Mj7quFUItVE=.fac87516-f7ff-4ec0-a605-2e4a6cf43261@github.com>

On Wed, 1 Feb 2023 14:20:05 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> src/jdk.incubator.vector/share/classes/jdk/incubator/vector/AbstractMask.java line 236:
>> 
>>> 234:         } else if (offset >= limit) {
>>> 235:             return vectorSpecies().maskAll(false);
>>> 236:         } else if (limit - offset >= length()) {
>> 
>> Can you move this else if check at the top, this is the most general case appearing in the loop and hence two extra uncommon trap jumps before it for special cases may penalize this.
>
> Your patch re-organized the code to take care of following cases :-
> 1.   offset < 0                         : Still falling over to old code.
> 2.   offset >= limit                  : Special case optimized 
> 3.   (limit - offset) >= length  :  Most general case.
> 4.   Partial in range check       :  New intrinsic, existing java side implementation in checkIndex0 is also composed of intrinsified calls,  infrequently taken paths will anyways lead to uncommon traps.
> 
> Have you tried introducing just case 3 (first) and then case 2 in existing indexInRange implementation.

Thanks for the review @jatin-bhateja !

> Have you tried introducing just case 3 (first) and then case 2 in existing indexInRange implementation.

Yes, I tried with this way as well, together with the performance testing compared with current version. The result is:
1. For cases that the array size is aligned with the vector size, the performance is almost the same with each other.
2. For cases that the array size is not aligned (which needs the masked operation), the performance with current version can improve about 5%~6% compared with the way as you suggested. But the improvement is limited to the cases with smaller vector size, whose tail loop size is bigger.

So, adding the new intrinsic has no side effect for me, except for the more complex java side code and one additional intrinsic.

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

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

From xgong at openjdk.org  Thu Feb  2 02:53:22 2023
From: xgong at openjdk.org (Xiaohong Gong)
Date: Thu, 2 Feb 2023 02:53:22 GMT
Subject: RFR: 8293198: [vectorapi] Improve the implementation of
 VectorMask.indexInRange()
In-Reply-To: <DlZuIlO-osVsKxMFzvRydSpz_g6g7c42Mj7quFUItVE=.fac87516-f7ff-4ec0-a605-2e4a6cf43261@github.com>
References: <fN58bi3n01tqWpG0-jjUPZQe8hmls2GQ5X3NL2o1RPg=.80e7965d-50af-4fac-bd7c-0a2b99cffe7e@github.com>
 <ueWKU-J85vkS2Iss-2P1YvBAgbywubU6rnXLI4ddZ-o=.b566a7e6-98cb-4897-ab61-970e3388ff5a@github.com>
 <xrdln-eR6POz41Xgq4fVbV6FPVQ_Eq0dCcRhOx6dGIs=.6d29b24c-71c1-4906-b256-b2cc6af25a75@github.com>
 <DlZuIlO-osVsKxMFzvRydSpz_g6g7c42Mj7quFUItVE=.fac87516-f7ff-4ec0-a605-2e4a6cf43261@github.com>
Message-ID: <cvPp0ViO1TkvyEgKQlX5hJUJTNcmiBqNsXJbIz-7IFU=.f06947bd-cd5c-4e80-92c4-1f7286d0de75@github.com>

On Thu, 2 Feb 2023 01:59:09 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

>> Your patch re-organized the code to take care of following cases :-
>> 1.   offset < 0                         : Still falling over to old code.
>> 2.   offset >= limit                  : Special case optimized 
>> 3.   (limit - offset) >= length  :  Most general case.
>> 4.   Partial in range check       :  New intrinsic, existing java side implementation in checkIndex0 is also composed of intrinsified calls,  infrequently taken paths will anyways lead to uncommon traps.
>> 
>> Have you tried introducing just case 3 (first) and then case 2 in existing indexInRange implementation.
>
> Thanks for the review @jatin-bhateja !
> 
>> Have you tried introducing just case 3 (first) and then case 2 in existing indexInRange implementation.
> 
> Yes, I tried with this way as well, together with the performance testing compared with current version. The result is:
> 1. For cases that the array size is aligned with the vector size, the performance is almost the same with each other.
> 2. For cases that the array size is not aligned (which needs the masked operation), the performance with current version can improve about 5%~6% compared with the way as you suggested. But the improvement is limited to the cases with smaller vector size, whose tail loop size is bigger.
> 
> So, adding the new intrinsic has no side effect for me, except for the more complex java side code and one additional intrinsic.

> Can you move this else if check at the top, this is the most general case appearing in the loop and hence two extra uncommon trap jumps before it for special cases may penalize this.

The generated code does not have any difference by moving the most general case at the top. It still will generate the uncommon trap jumps before it. Besides, moving it at the top may make the code in java side harder to understand. The code may seem like:

public VectorMask<E> indexInRange(int offset, int limit) {
        if (offset > 0 && limit - offset >= length()) {
            return this;
        } else if (offset > 0 && offset < limit) {
            return this.and(indexInRange0(offset, limit));
        } else if (offset >= limit) {
            return vectorSpecies().maskAll(false);
        } else {
           return this.and(indexInRange0Helper(offset, limit));
        }
}
``` 

But as what you suggested above, if we remove the new intrinsic and keep using the "checkIndex0" to handle the tail loop, the code may be easier, such as:

public VectorMask<E> indexInRange(int offset, int limit) {
        if (offset > 0 && limit - offset >= length()) {
            return this;
        } else if (offset >= limit) {
            return vectorSpecies().maskAll(false);
        } else {
           return this.and(indexInRange0Helper(offset, limit));
        }
}

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

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

From xgong at openjdk.org  Thu Feb  2 03:45:22 2023
From: xgong at openjdk.org (Xiaohong Gong)
Date: Thu, 2 Feb 2023 03:45:22 GMT
Subject: RFR: 8293198: [vectorapi] Improve the implementation of
 VectorMask.indexInRange()
In-Reply-To: <xrdln-eR6POz41Xgq4fVbV6FPVQ_Eq0dCcRhOx6dGIs=.6d29b24c-71c1-4906-b256-b2cc6af25a75@github.com>
References: <fN58bi3n01tqWpG0-jjUPZQe8hmls2GQ5X3NL2o1RPg=.80e7965d-50af-4fac-bd7c-0a2b99cffe7e@github.com>
 <ueWKU-J85vkS2Iss-2P1YvBAgbywubU6rnXLI4ddZ-o=.b566a7e6-98cb-4897-ab61-970e3388ff5a@github.com>
 <xrdln-eR6POz41Xgq4fVbV6FPVQ_Eq0dCcRhOx6dGIs=.6d29b24c-71c1-4906-b256-b2cc6af25a75@github.com>
Message-ID: <3h2CWPKB8YKgZnSE9iMBe114cI2VSGp4UZDgZTK5I-8=.c44439d2-c598-4aa9-bcf5-288a226280d7@github.com>

On Wed, 1 Feb 2023 14:20:05 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> src/jdk.incubator.vector/share/classes/jdk/incubator/vector/AbstractMask.java line 236:
>> 
>>> 234:         } else if (offset >= limit) {
>>> 235:             return vectorSpecies().maskAll(false);
>>> 236:         } else if (limit - offset >= length()) {
>> 
>> Can you move this else if check at the top, this is the most general case appearing in the loop and hence two extra uncommon trap jumps before it for special cases may penalize this.
>
> Your patch re-organized the code to take care of following cases :-
> 1.   offset < 0                         : Still falling over to old code.
> 2.   offset >= limit                  : Special case optimized 
> 3.   (limit - offset) >= length  :  Most general case.
> 4.   Partial in range check       :  New intrinsic, existing java side implementation in checkIndex0 is also composed of intrinsified calls,  infrequently taken paths will anyways lead to uncommon traps.
> 
> Have you tried introducing just case 3 (first) and then case 2 in existing indexInRange implementation.

> Thanks for the review @jatin-bhateja !
> 
> > Have you tried introducing just case 3 (first) and then case 2 in existing indexInRange implementation.
> 
> Yes, I tried with this way as well, together with the performance testing compared with current version. The result is:
> 
> 1. For cases that the array size is aligned with the vector size, the performance is almost the same with each other.
> 2. For cases that the array size is not aligned (which needs the masked operation), the performance with current version can improve about 5%~6% compared with the way as you suggested. But the improvement is limited to the cases with smaller vector size, whose tail loop size is bigger.
> 
> So, adding the new intrinsic has no side effect for me, except for the more complex java side code and one additional intrinsic.

Another benefit is the code change will be simpler, that almost all the files except the `AbstractMask.java` do not need to be changed. I will make the modification and rerun the benchmarks to decide whether it's necessary to add the new intrinsics. Thanks!

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

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

From jpai at openjdk.org  Thu Feb  2 05:31:12 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 2 Feb 2023 05:31:12 GMT
Subject: RFR: 8301655: Problemlist
 jdk/jdk/nio/zipfs/TestLocOffsetFromZip64EF.java on Linux
Message-ID: <t-D5qzxSzHIDoyffNi8j_WxnzMjyJ0bn052nI_3XHDQ=.49a2ca2b-f791-42bb-8fc6-fe57126145be@github.com>

Can I please get a review of this change which problem lists `TestLocOffsetFromZip64EF`? 

This test uses the `zip` command to generate a zip file. The `zip` binary shipped in recent versions of Linux (like Oracle Linux 9) are missing some features due to what appears to be a regression in that binary. That issue is being addressed upstream in https://bugzilla.redhat.com/show_bug.cgi?id=2162688. Until that issue is fixed, the proposal is to problem list this test on `linux-all` (the issue was reproduced on both `x64` and `aarch64`).

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

Commit messages:
 - 8301655: Problemlist jdk/jdk/nio/zipfs/TestLocOffsetFromZip64EF.java on Linux

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

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

From jbhateja at openjdk.org  Thu Feb  2 06:41:26 2023
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Thu, 2 Feb 2023 06:41:26 GMT
Subject: RFR: 8293198: [vectorapi] Improve the implementation of
 VectorMask.indexInRange()
In-Reply-To: <3h2CWPKB8YKgZnSE9iMBe114cI2VSGp4UZDgZTK5I-8=.c44439d2-c598-4aa9-bcf5-288a226280d7@github.com>
References: <fN58bi3n01tqWpG0-jjUPZQe8hmls2GQ5X3NL2o1RPg=.80e7965d-50af-4fac-bd7c-0a2b99cffe7e@github.com>
 <ueWKU-J85vkS2Iss-2P1YvBAgbywubU6rnXLI4ddZ-o=.b566a7e6-98cb-4897-ab61-970e3388ff5a@github.com>
 <xrdln-eR6POz41Xgq4fVbV6FPVQ_Eq0dCcRhOx6dGIs=.6d29b24c-71c1-4906-b256-b2cc6af25a75@github.com>
 <3h2CWPKB8YKgZnSE9iMBe114cI2VSGp4UZDgZTK5I-8=.c44439d2-c598-4aa9-bcf5-288a226280d7@github.com>
Message-ID: <wj-6qdPOG8OMnqBd88LlMI_KSd-dWTl7jhOZLB1hu94=.955c5e16-9f14-44c2-92b0-cd0da5a4f633@github.com>

On Thu, 2 Feb 2023 03:42:34 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

>> Your patch re-organized the code to take care of following cases :-
>> 1.   offset < 0                         : Still falling over to old code.
>> 2.   offset >= limit                  : Special case optimized 
>> 3.   (limit - offset) >= length  :  Most general case.
>> 4.   Partial in range check       :  New intrinsic, existing java side implementation in checkIndex0 is also composed of intrinsified calls,  infrequently taken paths will anyways lead to uncommon traps.
>> 
>> Have you tried introducing just case 3 (first) and then case 2 in existing indexInRange implementation.
>
>> Thanks for the review @jatin-bhateja !
>> 
>> > Have you tried introducing just case 3 (first) and then case 2 in existing indexInRange implementation.
>> 
>> Yes, I tried with this way as well, together with the performance testing compared with current version. The result is:
>> 
>> 1. For cases that the array size is aligned with the vector size, the performance is almost the same with each other.
>> 2. For cases that the array size is not aligned (which needs the masked operation), the performance with current version can improve about 5%~6% compared with the way as you suggested. But the improvement is limited to the cases with smaller vector size, whose tail loop size is bigger.
>> 
>> So, adding the new intrinsic has no side effect for me, except for the more complex java side code and one additional intrinsic.
> 
> Another benefit is the code change will be simpler, that almost all the files except the `AbstractMask.java` do not need to be changed. I will make the modification and rerun the benchmarks to decide whether it's necessary to add the new intrinsics. Thanks!

While you talked about Java side changes, I found another opportunity for optimization in checkIndex0 implementation, in the following code snippet from checkIndex0 method, indexLimit is guaranteed to be a +ve value.


         int indexLimit = Math.max(0, Math.min(length - offset, vlength));
         VectorMask<E> badMask =
            iota.compare(GE, iota.broadcast(indexLimit)); 

For float/double iota vectors, subsequent broadcast operation accepting long argument checks for precision loss before broadcasting floating point value.  


       long longToElementBits(long value) {
            // Do the conversion, and then test it for failure.
            float e = (float) value;
            if ((long) e != value) {
                throw badElementBits(value, e);
            }
            return toBits(e);
        }`

 
This can be saved by doing a prior casting of indexLimit to floating point value before calling broadcast, effectively we may need to move checkIndex0 to template generated abstract vector classes.

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

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

From alanb at openjdk.org  Thu Feb  2 07:06:22 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 2 Feb 2023 07:06:22 GMT
Subject: RFR: 8301637: ThreadLocalRandom.current().doubles().parallel()
 contention
In-Reply-To: <-mno_ek28PD0IyhDHBc3-ZCqGFq9G5t_Yt73ub665uA=.5e3e655e-631d-4302-b91c-6288581a1070@github.com>
References: <-mno_ek28PD0IyhDHBc3-ZCqGFq9G5t_Yt73ub665uA=.5e3e655e-631d-4302-b91c-6288581a1070@github.com>
Message-ID: <-153az2rcx8btNcOg9ZdyoZmWiz54t6WWPglCiv-izs=.ef2bbc39-6507-41e0-9b1f-c1646a201b66@github.com>

On Wed, 1 Feb 2023 15:51:33 GMT, kabutz <duke at openjdk.org> wrote:

> ThreadLocalRandom.current().doubles().parallel() had a bad regression, because it called the superclass methods of the ThreadLocalRandomProxy's nextDouble() method instead of delegating to the ThreadLocalRandom.current().
> 
> Affects all versions of ThreadLocalRandom since Java 17.

Marked as reviewed by alanb (Reviewer).

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

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

From vtewari at openjdk.org  Thu Feb  2 07:11:24 2023
From: vtewari at openjdk.org (Vyom Tewari)
Date: Thu, 2 Feb 2023 07:11:24 GMT
Subject: RFR: 8301367: Add exception handler method to the BaseLdapServer
In-Reply-To: <IGbyuw-gT2l_XwCle-EwHxngqsvA-HRPmRVV6jKf2Rs=.ef06d2ce-82d9-468f-a545-8fd61b336aeb@github.com>
References: <IGbyuw-gT2l_XwCle-EwHxngqsvA-HRPmRVV6jKf2Rs=.ef06d2ce-82d9-468f-a545-8fd61b336aeb@github.com>
Message-ID: <fDtuR4V4OFVQvnKnnUO_no_2NbIdskcbdIe8KSIjXHE=.da181b89-55eb-490a-945e-c65161f64d06@github.com>

On Tue, 31 Jan 2023 16:19:34 GMT, Aleksei Efimov <aefimov at openjdk.org> wrote:

> The proposed change adds a new exception handler method to the `test/jdk/com/sun/jndi/ldap/lib/BaseLdapServer.java` LDAP test library class. It will allow LDAP tests to customize the handling of server-side exceptions.   
> The current `BaseLdapTestServer` implementation prints an exception and its stack trace to the standard error stream.
> 
> Existing tests in `test/jdk/com/sun/jndi/ldap` that use the modified library class are passing with the modified version.

Looks Ok to me.

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

Marked as reviewed by vtewari (Committer).

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

From alanb at openjdk.org  Thu Feb  2 07:41:23 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 2 Feb 2023 07:41:23 GMT
Subject: RFR: 8301569: list mode of jmod and jimage cannot be used normally
 in turkish locale
In-Reply-To: <c_nKgF39mKpvMYopNLdMen6vNuEjGQdNa_lBnX_ShEw=.c9cd0c29-5b73-40e2-ac47-c6a78ecf2e10@github.com>
References: <v0uxR1eF4vFNvA8DMLlwG1x2M-oH3o-xTJgKPs25UNA=.35fe243b-db18-42b6-b32b-115b649340f6@github.com>
 <YGY2k5Yxc64cmMkwT71Tl2M8nzHXAO8_ATTSajL9DQI=.58727057-78b4-4d5a-900e-e35d1de444d3@github.com>
 <c_nKgF39mKpvMYopNLdMen6vNuEjGQdNa_lBnX_ShEw=.c9cd0c29-5b73-40e2-ac47-c6a78ecf2e10@github.com>
Message-ID: <bdpVgGkUEmrRA8PzEe-fZnCZEm_cBwBzuuppvsEcQFU=.167fe36d-19bc-48aa-a6ca-d1e1ef82f0dd@github.com>

On Wed, 1 Feb 2023 09:26:17 GMT, Glavo <duke at openjdk.org> wrote:

>> src/jdk.jlink/share/classes/jdk/tools/jmod/JmodTask.java line 1474:
>> 
>>> 1472:             String verb = words.get(0);
>>> 1473:             try {
>>> 1474:                 options.mode = Enum.valueOf(Mode.class, verb.toUpperCase(Locale.ROOT));
>> 
>> The equivalent in jlink and jimage are using Locale.ENGLISH, I guess we should try to keep them consistent.
>
>> The equivalent in jlink and jimage are using Locale.ENGLISH, I guess we should try to keep them consistent.
> 
> This class is using `Locale.ROOT` to convert modifiers to lowercase, and there is no reference to `Locale.ENGLISH`.

My comment was about these cases:

src/jdk.jlink/share/classes/jdk/tools/jlink/internal/JlinkTask.java:                        String name = entry.name().toUpperCase(Locale.ENGLISH);
src/jdk.jlink/share/classes/jdk/tools/jimage/JImageTask.java:                options.task = Enum.valueOf(Task.class, args[0].toUpperCase(Locale.ENGLISH));

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

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

From alanb at openjdk.org  Thu Feb  2 07:47:23 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 2 Feb 2023 07:47:23 GMT
Subject: RFR: 8300819: -Dfile.encoding=Cp943C option does not work as
 expected since jdk18 [v2]
In-Reply-To: <f15YxBbS9ZPUqqlBy9YKCv2XFtBf5A9FTXPMZrofPNU=.a21022fc-bb41-49e0-996b-5f8ab34e148b@github.com>
References: <e0lHdFW5cwElhb81t2f3oFbWdlqeAMwI_nMwaqIxSd4=.0513038a-d43f-4924-bb01-ec9b71b0633b@github.com>
 <GB9IC03qS7HSGqP17sdu2qRK62ypV5FXYer6Ql44h2w=.9d2ac382-3ddf-4d38-baae-dc6fa936f0af@github.com>
 <7jlCwNW-fr0cXI8zxqQjhpeEjRqJWUiUxsESrSHo_7s=.6e0ee193-bb07-43d0-81cd-f27ad23507cd@github.com>
 <Ytd2ATb0A0ElURCjx5MTiBjtS_-0Z7E7fXVKM7twIf0=.9fb9741f-1d7b-4511-b601-bf3c8f51111e@github.com>
 <JoUcsRSDluRVYb0nd-lTfawp8SX7nRaGDXZ_LiSwT0w=.3579d10b-f904-40d3-9007-2edf56431f00@github.com>
 <vS4OpBlBKgv9NYddpVH6RITZpoXN15NksCOOM01DHUM=.3d61764a-d66f-466d-8915-4ec77bf38598@github.com>
 <H5dR1wC91-aqAH9tzEhIb2D3me9BtLeWVRFhQIEKuB4=.972ce810-0bd8-448d-85ab-2c12336316a5@github.com>
 <f15YxBbS9ZPUqqlBy9YKCv2XFtBf5A9FTXPMZrofPNU=.a21022fc-bb41-49e0-996b-5f8ab34e148b@github.com>
Message-ID: <Id0Y8L2ncdiJusCE87q7N4e-K0i0ih8inlJSERtVSJA=.3cec8d86-eae6-48e5-b54b-d622e3690014@github.com>

On Wed, 25 Jan 2023 12:12:12 GMT, Ichiroh Takiguchi <itakiguchi at openjdk.org> wrote:

> We checked String.getByte()/new String(...)/Reader/Writer/ByteArrayOutputStream.toString()... Is there good way to pick up which parts need to be fixed ?

I don't think there is so you may have to audit the classes that use Charset.defaultCharset. Do you have any information on what it does, that might help narrow it down.

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

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

From xgong at openjdk.org  Thu Feb  2 08:18:29 2023
From: xgong at openjdk.org (Xiaohong Gong)
Date: Thu, 2 Feb 2023 08:18:29 GMT
Subject: RFR: 8293198: [vectorapi] Improve the implementation of
 VectorMask.indexInRange()
In-Reply-To: <wj-6qdPOG8OMnqBd88LlMI_KSd-dWTl7jhOZLB1hu94=.955c5e16-9f14-44c2-92b0-cd0da5a4f633@github.com>
References: <fN58bi3n01tqWpG0-jjUPZQe8hmls2GQ5X3NL2o1RPg=.80e7965d-50af-4fac-bd7c-0a2b99cffe7e@github.com>
 <ueWKU-J85vkS2Iss-2P1YvBAgbywubU6rnXLI4ddZ-o=.b566a7e6-98cb-4897-ab61-970e3388ff5a@github.com>
 <xrdln-eR6POz41Xgq4fVbV6FPVQ_Eq0dCcRhOx6dGIs=.6d29b24c-71c1-4906-b256-b2cc6af25a75@github.com>
 <3h2CWPKB8YKgZnSE9iMBe114cI2VSGp4UZDgZTK5I-8=.c44439d2-c598-4aa9-bcf5-288a226280d7@github.com>
 <wj-6qdPOG8OMnqBd88LlMI_KSd-dWTl7jhOZLB1hu94=.955c5e16-9f14-44c2-92b0-cd0da5a4f633@github.com>
Message-ID: <BaXpr7WSFP0elo2Z3Qk5DJlAC3xgJLHZ1UITbUxjsCg=.d429f7b4-7493-44e3-a734-7adf238c51ff@github.com>

On Thu, 2 Feb 2023 06:38:58 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>>> Thanks for the review @jatin-bhateja !
>>> 
>>> > Have you tried introducing just case 3 (first) and then case 2 in existing indexInRange implementation.
>>> 
>>> Yes, I tried with this way as well, together with the performance testing compared with current version. The result is:
>>> 
>>> 1. For cases that the array size is aligned with the vector size, the performance is almost the same with each other.
>>> 2. For cases that the array size is not aligned (which needs the masked operation), the performance with current version can improve about 5%~6% compared with the way as you suggested. But the improvement is limited to the cases with smaller vector size, whose tail loop size is bigger.
>>> 
>>> So, adding the new intrinsic has no side effect for me, except for the more complex java side code and one additional intrinsic.
>> 
>> Another benefit is the code change will be simpler, that almost all the files except the `AbstractMask.java` do not need to be changed. I will make the modification and rerun the benchmarks to decide whether it's necessary to add the new intrinsics. Thanks!
>
> While you talked about Java side changes, I found another opportunity for optimization in checkIndex0 implementation, in the following code snippet from checkIndex0 method, indexLimit is guaranteed to be a +ve value.
> 
> 
>          int indexLimit = Math.max(0, Math.min(length - offset, vlength));
>          VectorMask<E> badMask =
>             iota.compare(GE, iota.broadcast(indexLimit)); 
> 
> For float/double iota vectors, subsequent broadcast operation accepting long argument checks for precision loss before broadcasting floating point value.  
> 
> 
>        long longToElementBits(long value) {
>             // Do the conversion, and then test it for failure.
>             float e = (float) value;
>             if ((long) e != value) {
>                 throw badElementBits(value, e);
>             }
>             return toBits(e);
>         }`
> 
>  
> This can be saved by doing a prior casting of indexLimit to floating point value before calling broadcast, effectively we may need to move checkIndex0 to template generated abstract vector classes.

Hi, I modified a version by using the old implementation for the tail loop instead of adding the new intrinsics. The code looks like:

public VectorMask<E> indexInRange(int offset, int limit) {
        int vlength = length();
        if (offset >= 0 && limit - offset >= length()) {
            return this;
        } else if (offset >= limit) {
            return vectorSpecies().maskAll(false);
        }

        Vector<E> iota = vectorSpecies().zero().addIndex(1);
        VectorMask<E> badMask = checkIndex0(offset, limit, iota, vlength);
        return this.andNot(badMask);
    }

And I tested the performance of the new added benchmarks with different vector size on NEON/SVE and x86 avx2/avx512 architectures. The results show that the performance of changed version is not better than the current version, if the array size is not aligned with the vector size, especially for the double/long type with larger size.

Here are some raw data with NEON:

Benchmark                                 (size)   Mode  Cnt  current   modified   Units
IndexInRangeBenchmark.byteIndexInRange       131  thrpt    5  2654.919  2584.423   ops/ms
IndexInRangeBenchmark.byteIndexInRange       259  thrpt    5  1830.364  1802.876   ops/ms
IndexInRangeBenchmark.byteIndexInRange       515  thrpt    5  1058.548  1073.742   ops/ms
IndexInRangeBenchmark.doubleIndexInRange     131  thrpt    5   594.920   593.832   ops/ms
IndexInRangeBenchmark.doubleIndexInRange     259  thrpt    5   308.678   149.279   ops/ms
IndexInRangeBenchmark.doubleIndexInRange     515  thrpt    5   160.639    74.579   ops/ms
IndexInRangeBenchmark.floatIndexInRange      131  thrpt    5  1097.567  1104.008   ops/ms
IndexInRangeBenchmark.floatIndexInRange      259  thrpt    5   617.845   606.886   ops/ms
IndexInRangeBenchmark.floatIndexInRange      515  thrpt    5   315.978   152.046   ops/ms
IndexInRangeBenchmark.intIndexInRange        131  thrpt    5  1165.279  1205.486   ops/ms
IndexInRangeBenchmark.intIndexInRange        259  thrpt    5   633.648   631.672   ops/ms
IndexInRangeBenchmark.intIndexInRange        515  thrpt    5   315.370   154.144   ops/ms
IndexInRangeBenchmark.longIndexInRange       131  thrpt    5   639.840   633.623   ops/ms
IndexInRangeBenchmark.longIndexInRange       259  thrpt    5   312.267   152.788   ops/ms
IndexInRangeBenchmark.longIndexInRange       515  thrpt    5   163.028    78.150   ops/ms
IndexInRangeBenchmark.shortIndexInRange      131  thrpt    5  1834.318  1800.318   ops/ms
IndexInRangeBenchmark.shortIndexInRange      259  thrpt    5  1105.695  1094.347   ops/ms
IndexInRangeBenchmark.shortIndexInRange      515  thrpt    5   602.442   599.827   ops/ms


And the data with SVE 256-bit vector size:

Benchmark                                 (size)   Mode  Cnt   current   modified Units
IndexInRangeBenchmark.byteIndexInRange       131  thrpt    5  23772.370 22921.113 ops/ms
IndexInRangeBenchmark.byteIndexInRange       259  thrpt    5  18930.388 17920.910 ops/ms
IndexInRangeBenchmark.byteIndexInRange       515  thrpt    5  13528.610 13282.504 ops/ms
IndexInRangeBenchmark.doubleIndexInRange     131  thrpt    5   7850.522  7975.720 ops/ms
IndexInRangeBenchmark.doubleIndexInRange     259  thrpt    5   4281.749  4373.926 ops/ms
IndexInRangeBenchmark.doubleIndexInRange     515  thrpt    5   2160.001   604.458 ops/ms
IndexInRangeBenchmark.floatIndexInRange      131  thrpt    5  13594.943 13306.904 ops/ms
IndexInRangeBenchmark.floatIndexInRange      259  thrpt    5   8163.134  7912.343 ops/ms
IndexInRangeBenchmark.floatIndexInRange      515  thrpt    5   4335.529  4198.555 ops/ms
IndexInRangeBenchmark.intIndexInRange        131  thrpt    5  22106.880 20348.266 ops/ms
IndexInRangeBenchmark.intIndexInRange        259  thrpt    5  11711.588 10958.299 ops/ms
IndexInRangeBenchmark.intIndexInRange        515  thrpt    5   5501.034  5358.441 ops/ms
IndexInRangeBenchmark.longIndexInRange       131  thrpt    5   9832.578  9829.398 ops/ms
IndexInRangeBenchmark.longIndexInRange       259  thrpt    5   4979.326  4947.166 ops/ms
IndexInRangeBenchmark.longIndexInRange       515  thrpt    5   2269.131   614.204 ops/ms
IndexInRangeBenchmark.shortIndexInRange      131  thrpt    5  19865.866 19297.628 ops/ms
IndexInRangeBenchmark.shortIndexInRange      259  thrpt    5  14005.214 13592.407 ops/ms
IndexInRangeBenchmark.shortIndexInRange      515  thrpt    5   8766.450  8531.675 ops/ms

As a conclusion, I prefer to keep the current version. WDYT?

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

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

From duke at openjdk.org  Thu Feb  2 08:27:55 2023
From: duke at openjdk.org (Amit Kumar)
Date: Thu, 2 Feb 2023 08:27:55 GMT
Subject: RFR: 8299748: java/util/zip/Deinflate.java failing on s390x [v2]
In-Reply-To: <Usxi4wE5GSHHv-cKPfW6OXylhieAypbsidUX_Jo6FSQ=.34104cf0-2243-478f-86ce-9a91905c6755@github.com>
References: <Usxi4wE5GSHHv-cKPfW6OXylhieAypbsidUX_Jo6FSQ=.34104cf0-2243-478f-86ce-9a91905c6755@github.com>
Message-ID: <3z7u66KVgFfL7S7S4uxDtOA6gD-WkNU7R-zon0trIVg=.d27446ca-c11d-49cc-bb85-b162e5ac58f2@github.com>

> DeInflate.java test fails on s390x platform because size for out1 array which is responsible for storing the compressed data is insufficient. And being unable to write whole compressed data on array, on s390 whole data can't be recovered after compression. So this fix increase Array size (for s390).

Amit Kumar has updated the pull request incrementally with one additional commit since the last revision:

  change acc to Alan comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12283/files
  - new: https://git.openjdk.org/jdk/pull/12283/files/7957c02b..5a7fa279

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

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

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

From duke at openjdk.org  Thu Feb  2 08:28:31 2023
From: duke at openjdk.org (Amit Kumar)
Date: Thu, 2 Feb 2023 08:28:31 GMT
Subject: RFR: 8299748: java/util/zip/Deinflate.java failing on s390x
In-Reply-To: <jyL7HTlmcVxDKffdPqij6GNM0ePfzVxlypfy3hTtOAM=.3347a8dd-4722-4b79-b93e-b20892901c6b@github.com>
References: <Usxi4wE5GSHHv-cKPfW6OXylhieAypbsidUX_Jo6FSQ=.34104cf0-2243-478f-86ce-9a91905c6755@github.com>
 <nN80i01pPGVl8QlQ09eEEEeFTz5z2hpM6udh2bNJwpU=.925ff5c6-586b-4262-bcd0-fd67d44cfde2@github.com>
 <jyL7HTlmcVxDKffdPqij6GNM0ePfzVxlypfy3hTtOAM=.3347a8dd-4722-4b79-b93e-b20892901c6b@github.com>
Message-ID: <t0-xZa1roKvPdOm1oUNGN2UWPOBviOquptunKzJZusc=.a2026653-4cb8-436d-9766-00786d3bb7d3@github.com>

On Wed, 1 Feb 2023 08:46:12 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Hi Alan, here is output: 
>> 
>> level:0, strategy: 2, dowrap: true                                                                                                
>> is finished: true                                                
>> is finished: true
>> is finished: true
>> is finished: true                                                                                                                 is finished: true
>> level:1, strategy: 0, dowrap: false               
>> is finished: false     
>> m=525312, n=497972, len=524288, eq=false                                                                                          STDERR:    
>> java.lang.RuntimeException: De/inflater failed:java.util.zip.Deflater at 23a0858b                                               
>> 
>> 
>> 
>> But I guess this behaviour could be explained (by zEDC). On s390x, there is additional instruction present and it could be enabled by setting `DFLTCC=1`. And for accelerator the size of compressed data could go`2 times` the size of actual data. Again this is not deterministic as well, i.e. for same data there could be different valid deflate stream.
>
>> level:1, strategy: 0, dowrap: false               
>> is finished: false     
> 
> Thanks for checking that. So "is finished: false" is telling us that not all of the input was compressed. So I think the right thing is to do the deflate in a loop until there is more input to compress, the inflate probably needs the same. Your original proposal was to make the output buffer larger and I suspect that is just working around a threshold or block size used by the accelerator.

Hi @AlanBateman ,
with latest changes (doing inflate/deinflate) test passes over s390 and x86 as well. Please take a look now.

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

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

From alanb at openjdk.org  Thu Feb  2 08:29:22 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 2 Feb 2023 08:29:22 GMT
Subject: RFR: JDK-8300098 :
 java/util/concurrent/ConcurrentHashMap/ConcurrentAssociateTest.java fails with
 internal timeout when executed with TieredCompilation1/3
In-Reply-To: <CPbu_uqDyvV1hu2fjL-A6LIx3kK-ncM26_cDlXVxIeY=.1c30805e-ff8c-432d-a5a9-c9ca59383ace@github.com>
References: <CPbu_uqDyvV1hu2fjL-A6LIx3kK-ncM26_cDlXVxIeY=.1c30805e-ff8c-432d-a5a9-c9ca59383ace@github.com>
Message-ID: <L0ssh1DLTRml_I3GHfo6VK8R-mRbOAKnzfDdOBv76l4=.7a86bc93-52d7-45c9-8027-456523011235@github.com>

On Tue, 31 Jan 2023 10:45:07 GMT, Viktor Klang <duke at openjdk.org> wrote:

> The proposed fix by @DougLea ensures that the state transition into waiting is retried in the cases where a previous waiter isn't making progress and a new waiter goes into waiting.

Marked as reviewed by alanb (Reviewer).

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

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

From duke at openjdk.org  Thu Feb  2 09:29:59 2023
From: duke at openjdk.org (j3graham)
Date: Thu, 2 Feb 2023 09:29:59 GMT
Subject: RFR: 8301552: Use AtomicReferenceArray for caching instead of CHM
 in ZoneOffset [v4]
In-Reply-To: <YZtD-22CoEUUEKKffO00sDOXC_8VlK06-wI_AwtJUTA=.5392452d-543f-4e7d-9a7f-fdf9b1c49503@github.com>
References: <b228oWPoEJf0lfGgIVXwmo1mATeKWRTivuJ2PbgwAmI=.465a4f9b-7a4b-4bbb-9f94-66d1d889a072@github.com>
 <CTKH5YNx2G5Qt2Q2GPUUfn-zqe1mEPATIgdbFNeYx-E=.85241b63-91b8-4387-99ec-d49f5d97b30c@github.com>
 <YZtD-22CoEUUEKKffO00sDOXC_8VlK06-wI_AwtJUTA=.5392452d-543f-4e7d-9a7f-fdf9b1c49503@github.com>
Message-ID: <1JFNX-OhKD3tX8MPVdvQ6WEdsdrdId1C7VJshazArZU=.52bfd266-dede-4362-b41d-38e535d53aa5@github.com>

On Wed, 1 Feb 2023 11:37:16 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> src/java.base/share/classes/java/time/ZoneOffset.java line 147:
>> 
>>> 145: 
>>> 146:     /** Cache of time-zone offset by offset in seconds [-18h, +18h] for each even quarter of an hour. */
>>> 147:     private static final AtomicReferenceArray<ZoneOffset> SECONDS_CACHE = new AtomicReferenceArray<>(MAX_SECONDS_CACHE_SLOT * 2 + 1);
>> 
>> Can we use regular array instead?
>
> We can but that entails special handling to ensure thread-safety. I will provide such a solution. Thanks.

If you need the thread-safety, perhaps sticking with `AtomicReferenceArray` is a simpler solution than the regular array one.

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

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

From rgiulietti at openjdk.org  Thu Feb  2 09:46:34 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Thu, 2 Feb 2023 09:46:34 GMT
Subject: RFR: 8300869: Make use of the Double.toString(double) algorithm in
 java.util.Formatter [v8]
In-Reply-To: <BmEb7ZreTAdkNarpJgk7pZGGU8Ed6uNsexlvk4xlrbM=.85509eb8-9950-4a43-9703-edf9de311fe2@github.com>
References: <SBTbJWmhb-9rmOWnNXtIH-ztXLj2fNvdE0XCMIVmoZA=.5a6a1ef3-a42a-4675-96c1-a137c5f6ec1a@github.com>
 <BmEb7ZreTAdkNarpJgk7pZGGU8Ed6uNsexlvk4xlrbM=.85509eb8-9950-4a43-9703-edf9de311fe2@github.com>
Message-ID: <R6iJ4b41C83kt2QxS-M8d3r5orriF6Lx4lA-OjzqHYM=.6c2e7a4b-e4ff-4d34-a8a5-e6ef6c5ea617@github.com>

On Wed, 1 Feb 2023 10:26:26 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> Align `double` and `float` decimal conversions in `java.util.Formatter` with the algorithm used in `Double.toString(double)`.
>
> Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8300869: Make use of the Double.toString(double) algorithm in java.util.Formatter

Anyone from **i18n** wants to review before integration?

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

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

From dfuchs at openjdk.org  Thu Feb  2 09:56:21 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 2 Feb 2023 09:56:21 GMT
Subject: RFR: 8301367: Add exception handler method to the BaseLdapServer
In-Reply-To: <IGbyuw-gT2l_XwCle-EwHxngqsvA-HRPmRVV6jKf2Rs=.ef06d2ce-82d9-468f-a545-8fd61b336aeb@github.com>
References: <IGbyuw-gT2l_XwCle-EwHxngqsvA-HRPmRVV6jKf2Rs=.ef06d2ce-82d9-468f-a545-8fd61b336aeb@github.com>
Message-ID: <D1V7bcNPth6tXvbsJS3r2bQQ3cSSsxUwv8i_TuwbJVQ=.d3ffe624-1f39-4433-9d6b-034ef0e23400@github.com>

On Tue, 31 Jan 2023 16:19:34 GMT, Aleksei Efimov <aefimov at openjdk.org> wrote:

> The proposed change adds a new exception handler method to the `test/jdk/com/sun/jndi/ldap/lib/BaseLdapServer.java` LDAP test library class. It will allow LDAP tests to customize the handling of server-side exceptions.   
> The current `BaseLdapTestServer` implementation prints an exception and its stack trace to the standard error stream.
> 
> Existing tests in `test/jdk/com/sun/jndi/ldap` that use the modified library class are passing with the modified version.

Like Jaikiran I don't like the name of the new method much - but anything I could come up with was not much better. At least the new method gets both the socket and the exception as parameter, so that makes the name more reasonable. So approved as it stands!

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

Marked as reviewed by dfuchs (Reviewer).

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

From rgiulietti at openjdk.org  Thu Feb  2 10:07:09 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Thu, 2 Feb 2023 10:07:09 GMT
Subject: RFR: JDK-8301392: Port fdlibm log1p to Java [v4]
In-Reply-To: <iP_zmf7-2sC65mDLRC3CCTITEwj1OpxXGp1OBfBaIFg=.a4e5e7db-9dba-47db-8fbf-cfbd94984d22@github.com>
References: <g8yhvnKZcwHr9U-z5SqNsw2vLN7ZbdeF8bgazG7eFE4=.326c60bb-81c6-449f-b9bc-8ca5bdcfde99@github.com>
 <iP_zmf7-2sC65mDLRC3CCTITEwj1OpxXGp1OBfBaIFg=.a4e5e7db-9dba-47db-8fbf-cfbd94984d22@github.com>
Message-ID: <dXpm4P0-L-k21ryHfESXYAHOTWs2SOK88fxZd8d4Xtc=.312e15c3-cb44-46fd-8ecd-656766bacc9c@github.com>

On Wed, 1 Feb 2023 19:19:05 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Another day, another PR to port FDLBIM to Java, this time for the log1p method.
>> 
>> Other than using the two-argument form of the __HI method in Java transliteration version rather than C macro, there are no appreciable differences between the original C source in 
>> 
>> src/java.base/share/native/libfdlibm/s_log1p.c
>> 
>> and the transliteration for testing purposes in
>> 
>> test/jdk/java/lang/StrictMath/FdlibmTranslit.java
>> 
>> The more idiomatic port in
>> 
>> src/java.base/share/classes/java/lang/FdLibm.java
>> 
>> has had a series of transformation applied layering on the transliteration. The intermediate commits show the progress.
>> 
>> The regression tests include probing around input values the implementation uses to decided which branch to take.
>
> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Improve spacing.

test/jdk/java/lang/StrictMath/Log1pTests.java line 245:

> 243:              -0x1.0p-54,
> 244:               0x1.0p-54,
> 245: 

maybe add a comment like
`/* approximations around sqrt(2)/2 - 1 and around sqrt(2) - 1 */`

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

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

From rgiulietti at openjdk.org  Thu Feb  2 10:07:10 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Thu, 2 Feb 2023 10:07:10 GMT
Subject: RFR: JDK-8301392: Port fdlibm log1p to Java [v4]
In-Reply-To: <dXpm4P0-L-k21ryHfESXYAHOTWs2SOK88fxZd8d4Xtc=.312e15c3-cb44-46fd-8ecd-656766bacc9c@github.com>
References: <g8yhvnKZcwHr9U-z5SqNsw2vLN7ZbdeF8bgazG7eFE4=.326c60bb-81c6-449f-b9bc-8ca5bdcfde99@github.com>
 <iP_zmf7-2sC65mDLRC3CCTITEwj1OpxXGp1OBfBaIFg=.a4e5e7db-9dba-47db-8fbf-cfbd94984d22@github.com>
 <dXpm4P0-L-k21ryHfESXYAHOTWs2SOK88fxZd8d4Xtc=.312e15c3-cb44-46fd-8ecd-656766bacc9c@github.com>
Message-ID: <-LKgfwm1P6wdF-URmH-SyfYPnN8reUM59XYynmrDb00=.c86e486a-a742-4164-8aa9-3658a5535feb@github.com>

On Thu, 2 Feb 2023 10:03:29 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Improve spacing.
>
> test/jdk/java/lang/StrictMath/Log1pTests.java line 245:
> 
>> 243:              -0x1.0p-54,
>> 244:               0x1.0p-54,
>> 245: 
> 
> maybe add a comment like
> `/* approximations around sqrt(2)/2 - 1 and around sqrt(2) - 1 */`

(I mean, for the doubles starting at L.246)

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

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

From alanb at openjdk.org  Thu Feb  2 10:09:04 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 2 Feb 2023 10:09:04 GMT
Subject: RFR: 8299748: java/util/zip/Deinflate.java failing on s390x
In-Reply-To: <jyL7HTlmcVxDKffdPqij6GNM0ePfzVxlypfy3hTtOAM=.3347a8dd-4722-4b79-b93e-b20892901c6b@github.com>
References: <Usxi4wE5GSHHv-cKPfW6OXylhieAypbsidUX_Jo6FSQ=.34104cf0-2243-478f-86ce-9a91905c6755@github.com>
 <nN80i01pPGVl8QlQ09eEEEeFTz5z2hpM6udh2bNJwpU=.925ff5c6-586b-4262-bcd0-fd67d44cfde2@github.com>
 <jyL7HTlmcVxDKffdPqij6GNM0ePfzVxlypfy3hTtOAM=.3347a8dd-4722-4b79-b93e-b20892901c6b@github.com>
Message-ID: <2eqxeIzcejWahzfAMe-czlbIQ96bV8s_RIkXQsXMtsY=.b329489c-40fc-4e91-9e30-10a3df53711e@github.com>

On Wed, 1 Feb 2023 08:46:12 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Hi Alan, here is output: 
>> 
>> level:0, strategy: 2, dowrap: true                                                                                                
>> is finished: true                                                
>> is finished: true
>> is finished: true
>> is finished: true                                                                                                                 is finished: true
>> level:1, strategy: 0, dowrap: false               
>> is finished: false     
>> m=525312, n=497972, len=524288, eq=false                                                                                          STDERR:    
>> java.lang.RuntimeException: De/inflater failed:java.util.zip.Deflater at 23a0858b                                               
>> 
>> 
>> 
>> But I guess this behaviour could be explained (by zEDC). On s390x, there is additional instruction present and it could be enabled by setting `DFLTCC=1`. And for accelerator the size of compressed data could go`2 times` the size of actual data. Again this is not deterministic as well, i.e. for same data there could be different valid deflate stream.
>
>> level:1, strategy: 0, dowrap: false               
>> is finished: false     
> 
> Thanks for checking that. So "is finished: false" is telling us that not all of the input was compressed. So I think the right thing is to do the deflate in a loop until there is more input to compress, the inflate probably needs the same. Your original proposal was to make the output buffer larger and I suspect that is just working around a threshold or block size used by the accelerator.

> Hi @AlanBateman ,
> with latest changes (doing inflate/deinflate) test passes over s390 and x86 as well. Please take a look now.

Good. One thing to try is to just deflate/inflate into out1/out2, no need for the intermediate BAOS, try this:


--- a/test/jdk/java/util/zip/DeInflate.java
+++ b/test/jdk/java/util/zip/DeInflate.java
@@ -1,5 +1,5 @@
 /*
- * Copyright (c) 2011, 2018, Oracle and/or its affiliates. All rights reserved.
+ * Copyright (c) 2011, 2023, Oracle and/or its affiliates. All rights reserved.
  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
  *
  * This code is free software; you can redistribute it and/or modify it
@@ -127,11 +127,25 @@ public class DeInflate {
 
         def.setInput(in, 0, len);
         def.finish();
-        int m = def.deflate(out1);
+        int m = 0;
+        while (!def.finished()) {
+            int remaining = out1.length - m;
+            if (remaining == 0) {
+                throw new RuntimeException("out1 is small");
+            }
+            m += def.deflate(out1, m, remaining);
+        }
 
         Inflater inf = new Inflater(nowrap);
         inf.setInput(out1, 0, m);
-        int n = inf.inflate(out2);
+        int n = 0;
+        while (!inf.finished()) {
+            int remaining = out2.length - n;
+            if (remaining == 0) {
+                throw new RuntimeException("out2 is small");
+            }
+            n += inf.inflate(out2, n, remaining);
+        }
 
         if (n != len ||
             !Arrays.equals(Arrays.copyOf(in, len), Arrays.copyOf(out2, len)) ||

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

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

From lancea at openjdk.org  Thu Feb  2 10:43:26 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Thu, 2 Feb 2023 10:43:26 GMT
Subject: RFR: 8301655: Problemlist
 jdk/jdk/nio/zipfs/TestLocOffsetFromZip64EF.java on Linux
In-Reply-To: <t-D5qzxSzHIDoyffNi8j_WxnzMjyJ0bn052nI_3XHDQ=.49a2ca2b-f791-42bb-8fc6-fe57126145be@github.com>
References: <t-D5qzxSzHIDoyffNi8j_WxnzMjyJ0bn052nI_3XHDQ=.49a2ca2b-f791-42bb-8fc6-fe57126145be@github.com>
Message-ID: <lrGEzZG9SLIgrmlxWjhTZheLvNEhqWfNEbOsewrWt6U=.33fc39d9-7f15-470d-81b1-db73e194f65c@github.com>

On Thu, 2 Feb 2023 02:00:33 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change which problem lists `TestLocOffsetFromZip64EF`? 
> 
> This test uses the `zip` command to generate a zip file. The `zip` binary shipped in recent versions of Linux (like Oracle Linux 9) are missing some features due to what appears to be a regression in that binary. That issue is being addressed upstream in https://bugzilla.redhat.com/show_bug.cgi?id=2162688. Until that issue is fixed, the proposal is to problem list this test on `linux-all` (the issue was reproduced on both `x64` and `aarch64`).

Thank you Jai for handling this for us

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

Marked as reviewed by lancea (Reviewer).

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

From duke at openjdk.org  Thu Feb  2 10:51:24 2023
From: duke at openjdk.org (Amit Kumar)
Date: Thu, 2 Feb 2023 10:51:24 GMT
Subject: RFR: 8299748: java/util/zip/Deinflate.java failing on s390x [v2]
In-Reply-To: <3z7u66KVgFfL7S7S4uxDtOA6gD-WkNU7R-zon0trIVg=.d27446ca-c11d-49cc-bb85-b162e5ac58f2@github.com>
References: <Usxi4wE5GSHHv-cKPfW6OXylhieAypbsidUX_Jo6FSQ=.34104cf0-2243-478f-86ce-9a91905c6755@github.com>
 <3z7u66KVgFfL7S7S4uxDtOA6gD-WkNU7R-zon0trIVg=.d27446ca-c11d-49cc-bb85-b162e5ac58f2@github.com>
Message-ID: <VugiOuhO1Lxlmq6G_rjKTDY3WaTQj2rEy0o8kPBI5gA=.fd4cdacd-514c-420f-b474-37d53c88987e@github.com>

On Thu, 2 Feb 2023 08:27:55 GMT, Amit Kumar <duke at openjdk.org> wrote:

>> DeInflate.java test fails on s390x platform because size for out1 array which is responsible for storing the compressed data is insufficient. And being unable to write whole compressed data on array, on s390 whole data can't be recovered after compression. So this fix increase Array size (for s390).
>
> Amit Kumar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   change acc to Alan comments

Alan RuntimeException is being thrown with the changes you've suggested.
Test Result: 

level:0, strategy: 2, dowrap: true
level:1, strategy: 0, dowrap: false
STDERR:
java.lang.RuntimeException: out1 is small
        at DeInflate.check(DeInflate.java:135)
        at DeInflate.main(DeInflate.java:304)
        at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
        at java.base/java.lang.reflect.Method.invoke(Method.java:578)
        at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:312)
        at java.base/java.lang.Thread.run(Thread.java:1623)

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

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

From scolebourne at openjdk.org  Thu Feb  2 10:55:25 2023
From: scolebourne at openjdk.org (Stephen Colebourne)
Date: Thu, 2 Feb 2023 10:55:25 GMT
Subject: RFR: 8301552: Use AtomicReferenceArray for caching instead of CHM
 in ZoneOffset [v4]
In-Reply-To: <4H30se4qw_TKSWrvInldU08F3KKcHmAPPSSuWc9kXYY=.6e30a782-6617-43f9-83d2-8237d5389b85@github.com>
References: <b228oWPoEJf0lfGgIVXwmo1mATeKWRTivuJ2PbgwAmI=.465a4f9b-7a4b-4bbb-9f94-66d1d889a072@github.com>
 <hsJDiMZ6OJcbc9z1577V64xshorl5wYbF1Lm3k8TUzs=.6d47a875-6190-4688-a0ac-12f48dbcfa72@github.com>
 <05rUH2WPjpBg564PQ1g8t7Sq5Ui4-hZ8mnUAQj3uYqU=.bcc1afda-8172-4e4c-9afe-d5272b60defc@github.com>
 <4H30se4qw_TKSWrvInldU08F3KKcHmAPPSSuWc9kXYY=.6e30a782-6617-43f9-83d2-8237d5389b85@github.com>
Message-ID: <SkxxZJGo3o7KCmwVIQE2qghuPKx8mbLFhTM3sdtCalo=.717fe5a3-5441-4001-80dd-cd3c18e6a89d@github.com>

On Wed, 1 Feb 2023 20:19:20 GMT, cheenar <duke at openjdk.org> wrote:

>> test/jdk/java/time/tck/java/time/zone/TCKFixedZoneRules.java line 141:
>> 
>>> 139:     @Test(dataProvider="rules")
>>> 140:     public void test_isValidOffset_LDT_ZO(ZoneRules test, ZoneOffset expectedOffset) {
>>> 141:         if (expectedOffset == ZoneOffset.UTC)
>> 
>> Extremely minor but why not wrap if with `{}` for improved readability here with the comment
>
> Same [here](https://github.com/openjdk/jdk/pull/12346/commits/ec49ca3bc03d2e97fa0429c84290923066667871?diff=unified&w=0#diff-9e5aa282dc2d02c31e1d7c5ec8196a1d3d23c06e471d5114d0bd0c78ee4fe5f6R433) although it feels much more dangerous than the test!

Yes, please always wrap with `{}` in java.time.*

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

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

From duke at openjdk.org  Thu Feb  2 12:07:50 2023
From: duke at openjdk.org (SUN Guoyun)
Date: Thu, 2 Feb 2023 12:07:50 GMT
Subject: RFR: 8301306: java/net/httpclient/* fail with -Xcomp:
 java.io.IOException: HTTP/1.1 header parser received no bytes [v2]
In-Reply-To: <EmO-pO3meTsjSQg2YB41x_363TqX3no8VadRYgM4Gk4=.9982c4e4-9200-4de5-a745-eec6179a4b7c@github.com>
References: <EmO-pO3meTsjSQg2YB41x_363TqX3no8VadRYgM4Gk4=.9982c4e4-9200-4de5-a745-eec6179a4b7c@github.com>
Message-ID: <rF8kzEOUAddzPmGalo_a56kvGbXX5_XpIANSYMDb4GE=.99366f7e-96b8-4f01-9041-8f3bd31ff129@github.com>

> Hi all,
> I think `BackgroundCompilation` should not be set to false when `-Xcomp` be used, which causes the java thread to block for longer, then causing the following tests failed frequently on the AArch64 and LoongArch64 architecture.
> 
> java/net/httpclient/ByteArrayPublishers.java ?fastdebug -Xcomp?
> java/net/httpclient/ManyRequestsLegacy.java ?fastdebug -Xcomp?
> java/net/httpclient/HttpClientLocalAddrTest.java ?fastdebug -Xcomp?
> jdk/incubator/concurrent/StructuredTaskScope/StructuredTaskScopeTest.java ?fastdebug -Xcomp?
> java/rmi/server/UnicastRemoteObject/serialFilter/FilterUROTest.java ?release -Xcomp?
> 
> This PR delete BackgroundCompilation be setted, Above tests can be passed. Please help review it.
> 
> Thanks.

SUN Guoyun has updated the pull request incrementally with one additional commit since the last revision:

  8301306: java/net/httpclient/* fail with -Xcomp

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12282/files
  - new: https://git.openjdk.org/jdk/pull/12282/files/b193aca4..449ff65c

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

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

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

From aefimov at openjdk.org  Thu Feb  2 12:48:33 2023
From: aefimov at openjdk.org (Aleksei Efimov)
Date: Thu, 2 Feb 2023 12:48:33 GMT
Subject: RFR: 8301367: Add exception handler method to the BaseLdapServer
In-Reply-To: <IGbyuw-gT2l_XwCle-EwHxngqsvA-HRPmRVV6jKf2Rs=.ef06d2ce-82d9-468f-a545-8fd61b336aeb@github.com>
References: <IGbyuw-gT2l_XwCle-EwHxngqsvA-HRPmRVV6jKf2Rs=.ef06d2ce-82d9-468f-a545-8fd61b336aeb@github.com>
Message-ID: <9Z8AYK4lsXY6OitcvlNTaO0biBrbCbA_MsQnevP72zQ=.ca4035f3-f7d3-43e8-a0df-31c8190f76b8@github.com>

On Tue, 31 Jan 2023 16:19:34 GMT, Aleksei Efimov <aefimov at openjdk.org> wrote:

> The proposed change adds a new exception handler method to the `test/jdk/com/sun/jndi/ldap/lib/BaseLdapServer.java` LDAP test library class. It will allow LDAP tests to customize the handling of server-side exceptions.   
> The current `BaseLdapTestServer` implementation prints an exception and its stack trace to the standard error stream.
> 
> Existing tests in `test/jdk/com/sun/jndi/ldap` that use the modified library class are passing with the modified version.

> Hello Aleksei, the change looks fine to me.
> 
> The new method name handleSocketException could be a bit confusing since it might indicate this is about handling java.net.SocketException. But I think, given that this is just a test library code and that the method has a comment explaining when it's called, I think it's OK.

> Like Jaikiran I don't like the name of the new method much - but anything I could come up with was not much better. 

Hi Jaikiran, Daniel, Vyom,
Thanks for your reviews. I can see how the method name can be confusing, but I will stick with `handleSocketException` given that it:  
 a) has a comment describing its use cases;  b) takes two parameters that give a clue on intended usage; c) has no better alternative; d) is a test library method and we can change it later if better alternative is found.

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

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

From aefimov at openjdk.org  Thu Feb  2 12:48:34 2023
From: aefimov at openjdk.org (Aleksei Efimov)
Date: Thu, 2 Feb 2023 12:48:34 GMT
Subject: Integrated: 8301367: Add exception handler method to the
 BaseLdapServer
In-Reply-To: <IGbyuw-gT2l_XwCle-EwHxngqsvA-HRPmRVV6jKf2Rs=.ef06d2ce-82d9-468f-a545-8fd61b336aeb@github.com>
References: <IGbyuw-gT2l_XwCle-EwHxngqsvA-HRPmRVV6jKf2Rs=.ef06d2ce-82d9-468f-a545-8fd61b336aeb@github.com>
Message-ID: <ZEZ6-KPV76JUPWZ7BSbUlJOp9k8aPAmsLXBxZAOYJkU=.29bc4066-c863-4d13-8279-4837a40f29cb@github.com>

On Tue, 31 Jan 2023 16:19:34 GMT, Aleksei Efimov <aefimov at openjdk.org> wrote:

> The proposed change adds a new exception handler method to the `test/jdk/com/sun/jndi/ldap/lib/BaseLdapServer.java` LDAP test library class. It will allow LDAP tests to customize the handling of server-side exceptions.   
> The current `BaseLdapTestServer` implementation prints an exception and its stack trace to the standard error stream.
> 
> Existing tests in `test/jdk/com/sun/jndi/ldap` that use the modified library class are passing with the modified version.

This pull request has now been integrated.

Changeset: 03b23a1e
Author:    Aleksei Efimov <aefimov at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/03b23a1e1bd724019ef4fdbee3463d0646329164
Stats:     11 lines in 1 file changed: 9 ins; 0 del; 2 mod

8301367: Add exception handler method to the BaseLdapServer

Reviewed-by: jpai, vtewari, dfuchs

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

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

From eirbjo at gmail.com  Thu Feb  2 13:38:08 2023
From: eirbjo at gmail.com (=?UTF-8?B?RWlyaWsgQmrDuHJzbsO4cw==?=)
Date: Thu, 2 Feb 2023 14:38:08 +0100
Subject: Avoid string decoding in ZipFile.Source.getEntryPos
Message-ID: <CA+pBWht+ML7eMFVCacPkMR4m0+cx-6wgGt5eFRDXU0PLAwAQzg@mail.gmail.com>

Hi,

Please review this PR which speeds up ZipFile entry lookup by ~17%, mostly
by removing a string decode / allocation when getEntryPos compares lookup
names with names in the CEN:

https://github.com/openjdk/jdk/pull/12290

Thanks,
Eirik.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20230202/43010c34/attachment.htm>

From duke at openjdk.org  Thu Feb  2 13:51:27 2023
From: duke at openjdk.org (kabutz)
Date: Thu, 2 Feb 2023 13:51:27 GMT
Subject: RFR: 8301637: ThreadLocalRandom.current().doubles().parallel()
 contention
In-Reply-To: <-153az2rcx8btNcOg9ZdyoZmWiz54t6WWPglCiv-izs=.ef2bbc39-6507-41e0-9b1f-c1646a201b66@github.com>
References: <-mno_ek28PD0IyhDHBc3-ZCqGFq9G5t_Yt73ub665uA=.5e3e655e-631d-4302-b91c-6288581a1070@github.com>
 <-153az2rcx8btNcOg9ZdyoZmWiz54t6WWPglCiv-izs=.ef2bbc39-6507-41e0-9b1f-c1646a201b66@github.com>
Message-ID: <m9tqNK6bLlOJozhLyNLZepkd8FOAIiPuJxm611tK_A8=.98be2e35-d3ef-4001-8c95-bbc20404da61@github.com>

On Thu, 2 Feb 2023 07:03:44 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> ThreadLocalRandom.current().doubles().parallel() had a bad regression, because it called the superclass methods of the ThreadLocalRandomProxy's nextDouble() method instead of delegating to the ThreadLocalRandom.current().
>> 
>> Affects all versions of ThreadLocalRandom since Java 17.
>
> Marked as reviewed by alanb (Reviewer).

Could someone please sponsor this change? @AlanBateman or @jddarcy ?

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

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

From pminborg at openjdk.org  Thu Feb  2 15:04:57 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 2 Feb 2023 15:04:57 GMT
Subject: RFR: 8300235: Use VarHandle access in Image(Input |
 Output)StreamImpl classes [v3]
In-Reply-To: <PPJBgKqkFFPV_e0GALCKfL3IXCw162qaY0IRWw4S0-M=.e118bdd0-f7b4-4765-9fba-5206ee264f7f@github.com>
References: <PPJBgKqkFFPV_e0GALCKfL3IXCw162qaY0IRWw4S0-M=.e118bdd0-f7b4-4765-9fba-5206ee264f7f@github.com>
Message-ID: <j_I89bmSRiKzBcN0t4m-FxKFABD5pisKPrkVeORuAIM=.3587f329-a2ca-4779-8a6f-e17f3cacebc9@github.com>

> This PR suggests improving performance by using the newly introduced class `jdk.internal.util.ByteArray` to improve packing/unpacking operations.
> 
> The PR also proposes adding a `ByteArrayLittleEndian` class for support for little endian packing/unpacking.

Per Minborg has updated the pull request incrementally with one additional commit since the last revision:

  Fix problem in benchmark

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12204/files
  - new: https://git.openjdk.org/jdk/pull/12204/files/3b3873d5..68d72946

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

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

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

From pminborg at openjdk.org  Thu Feb  2 15:05:00 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 2 Feb 2023 15:05:00 GMT
Subject: RFR: 8300235: Use VarHandle access in Image(Input |
 Output)StreamImpl classes [v2]
In-Reply-To: <e0diTLO_z58sVZyjWMKvMWfcAPq5M_0dIQqru0--Pfc=.e8c039af-cdf7-4ce9-b59e-8e136cc05ddd@github.com>
References: <PPJBgKqkFFPV_e0GALCKfL3IXCw162qaY0IRWw4S0-M=.e118bdd0-f7b4-4765-9fba-5206ee264f7f@github.com>
 <e0diTLO_z58sVZyjWMKvMWfcAPq5M_0dIQqru0--Pfc=.e8c039af-cdf7-4ce9-b59e-8e136cc05ddd@github.com>
Message-ID: <t9pMCgx7-yAlMygcXq7EvzpTS8nXG3d9riiDMYFDaW0=.61e42f00-ac4e-41b4-9d5d-7b937b9ac8eb@github.com>

On Wed, 1 Feb 2023 15:13:27 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR suggests improving performance by using the newly introduced class `jdk.internal.util.ByteArray` to improve packing/unpacking operations.
>> 
>> The PR also proposes adding a `ByteArrayLittleEndian` class for support for little endian packing/unpacking.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add benchmark

Here are some benchmarks:


Baseline (JDK21, master (called Java 20 below))
Benchmark                       Mode  Cnt  Score   Error  Units
ImageInputStreamBench.readInt   avgt   15  1.289 ? 0.029  ns/op
ImageInputStreamBench.readLong  avgt   15  1.308 ? 0.017  ns/op

Patch (called Java 21 below)
Benchmark                       Mode  Cnt  Score   Error  Units
ImageInputStreamBench.readInt   avgt   15  0.946 ? 0.046  ns/op
ImageInputStreamBench.readLong  avgt   15  0.954 ? 0.010  ns/op



![image](https://user-images.githubusercontent.com/7457876/216359253-a2594137-0c7f-4fac-a673-177576fc43ed.png)

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

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

From pminborg at openjdk.org  Thu Feb  2 15:13:08 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 2 Feb 2023 15:13:08 GMT
Subject: RFR: 8301552: Use AtomicReferenceArray for caching instead of CHM
 in ZoneOffset [v5]
In-Reply-To: <b228oWPoEJf0lfGgIVXwmo1mATeKWRTivuJ2PbgwAmI=.465a4f9b-7a4b-4bbb-9f94-66d1d889a072@github.com>
References: <b228oWPoEJf0lfGgIVXwmo1mATeKWRTivuJ2PbgwAmI=.465a4f9b-7a4b-4bbb-9f94-66d1d889a072@github.com>
Message-ID: <Q_ZRnNTLyg5j6ca5K-fC9yXiNjXyCkHGBbLj42mqBco=.166a063f-5093-46c2-afed-5e5e707fa367@github.com>

> `ZoneOffset` instances are cached by the `ZoneOffset` class itself for values in the range [-18h, 18h] for each second that is on an even quarter of an hour (i.e. at most 2*18*4+1 = 145 values). 
> 
> Instead of using a `ConcurrentHashMap` for caching instanced, we could instead use an `AtomicReferenceArray` with direct slot value access for said even seconds. This will improve performance and reduce the number of object even though the backing array will go from an initial 32 in the CHM to an initial/final 145 in the ARA. The CHM will contain much more objects and array slots for typical numbers of entries in the cache and will compute hash/bucket/collision on the hot code path for each cache access.

Per Minborg has updated the pull request incrementally with one additional commit since the last revision:

  Add brackets

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12346/files
  - new: https://git.openjdk.org/jdk/pull/12346/files/562885c7..48438fd8

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

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

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

From pminborg at openjdk.org  Thu Feb  2 15:13:11 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 2 Feb 2023 15:13:11 GMT
Subject: RFR: 8301552: Use AtomicReferenceArray for caching instead of CHM
 in ZoneOffset [v5]
In-Reply-To: <1JFNX-OhKD3tX8MPVdvQ6WEdsdrdId1C7VJshazArZU=.52bfd266-dede-4362-b41d-38e535d53aa5@github.com>
References: <b228oWPoEJf0lfGgIVXwmo1mATeKWRTivuJ2PbgwAmI=.465a4f9b-7a4b-4bbb-9f94-66d1d889a072@github.com>
 <CTKH5YNx2G5Qt2Q2GPUUfn-zqe1mEPATIgdbFNeYx-E=.85241b63-91b8-4387-99ec-d49f5d97b30c@github.com>
 <YZtD-22CoEUUEKKffO00sDOXC_8VlK06-wI_AwtJUTA=.5392452d-543f-4e7d-9a7f-fdf9b1c49503@github.com>
 <1JFNX-OhKD3tX8MPVdvQ6WEdsdrdId1C7VJshazArZU=.52bfd266-dede-4362-b41d-38e535d53aa5@github.com>
Message-ID: <J95ufZAPHLSvwUCMyp4uAFj8saTr965SG92mw10NuFM=.4259506d-bc11-416f-b064-8cd23cf31d0a@github.com>

On Thu, 2 Feb 2023 09:26:55 GMT, j3graham <duke at openjdk.org> wrote:

>> We can but that entails special handling to ensure thread-safety. I will provide such a solution. Thanks.
>
> If you need the thread-safety, perhaps sticking with `AtomicReferenceArray` is a simpler solution than the regular array one.

As I used a regular array, I realized I could provide better performance with not much added complexity. See the use of `@Stable` for the components in the array.

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

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

From duke at openjdk.org  Thu Feb  2 15:36:09 2023
From: duke at openjdk.org (Scott Gibbons)
Date: Thu, 2 Feb 2023 15:36:09 GMT
Subject: RFR: JDK-8300808: Accelerate Base64 on x86 for AVX2 [v7]
In-Reply-To: <CvrXAGNcDEJr-xaovmpYAmO4-G5m193XowKMLLX8GeQ=.0cf6fc11-1710-4b2e-b3d8-d17e445490e7@github.com>
References: <9zN3bjyMEikXYOlpjTy9_QPc-9usYiBJMUFdb-TaVrQ=.e8f65ce9-ac0f-4f8d-9c6b-b39ae1c26cd2@github.com>
 <eyAXp-rZ5Dhd6F4jmDzFSeWJPknJBOhKN51delMUahc=.8f5d6102-5cb9-4fd1-8014-11812771962c@github.com>
 <qJm4si333sDFG9blT75d2B8HdmEXMqOg0NgsPq9N1o0=.ae3077ce-390a-481b-9402-ad9b8009c5c2@github.com>
 <yH0SmOEnIsEo6bCgNRCBy5Pv7EeyuUn3pAvUswyVQjI=.4a4915bd-3f89-4c5b-8fc8-7206c2885cff@github.com>
 <CvrXAGNcDEJr-xaovmpYAmO4-G5m193XowKMLLX8GeQ=.0cf6fc11-1710-4b2e-b3d8-d17e445490e7@github.com>
Message-ID: <Y0HEaVyWFWxvcBttJ1kfnRnNmkzNrXDZVC_czjkkjek=.dfa729db-67fb-4800-8e2b-fc85a2e8a376@github.com>

On Thu, 2 Feb 2023 00:34:32 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> These tables are used for both URL and non-URL based on the parameter, and they are only two of the three lut tables used (the other is in `base64_AVX2_decode_tables_addr` ).  Both names are essentially incorrect.  Does the name really matter that much?  It's the same as `base64_AVX2_decode_tables_addr` with the addition of URL tables.
>
> Names are important, but always hard to get right. At the very least they need to be correct. Maybe call it something like `..parameterized_decode_tables..` and the other `..shared_decode_tables..`?

I prefer leaving them the way they are.  I don't think the names, along with the associated comments within the tables, causes any undue confusion as to their function.  However I will implement the name change if that's all it takes to procure a review approval.  Please provide the specific names you'd like me to use and I'll change them.  Or just approve as-is :-).

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

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

From pminborg at openjdk.org  Thu Feb  2 15:44:54 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 2 Feb 2023 15:44:54 GMT
Subject: RFR: 8301552: Use AtomicReferenceArray for caching instead of CHM
 in ZoneOffset [v6]
In-Reply-To: <b228oWPoEJf0lfGgIVXwmo1mATeKWRTivuJ2PbgwAmI=.465a4f9b-7a4b-4bbb-9f94-66d1d889a072@github.com>
References: <b228oWPoEJf0lfGgIVXwmo1mATeKWRTivuJ2PbgwAmI=.465a4f9b-7a4b-4bbb-9f94-66d1d889a072@github.com>
Message-ID: <3yEmX_TScPCLb-W1zwHwEXZXvXWAzemtwCtYTFPsSXg=.d8aaa569-8812-45dd-a3b5-af99b677165b@github.com>

> `ZoneOffset` instances are cached by the `ZoneOffset` class itself for values in the range [-18h, 18h] for each second that is on an even quarter of an hour (i.e. at most 2*18*4+1 = 145 values). 
> 
> Instead of using a `ConcurrentHashMap` for caching instanced, we could instead use an `AtomicReferenceArray` with direct slot value access for said even seconds. This will improve performance and reduce the number of object even though the backing array will go from an initial 32 in the CHM to an initial/final 145 in the ARA. The CHM will contain much more objects and array slots for typical numbers of entries in the cache and will compute hash/bucket/collision on the hot code path for each cache access.

Per Minborg has updated the pull request incrementally with one additional commit since the last revision:

  Fix benchmark

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12346/files
  - new: https://git.openjdk.org/jdk/pull/12346/files/48438fd8..1cd2b406

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

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

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

From pminborg at openjdk.org  Thu Feb  2 16:23:55 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 2 Feb 2023 16:23:55 GMT
Subject: RFR: 8301552: Use AtomicReferenceArray for caching instead of CHM
 in ZoneOffset [v6]
In-Reply-To: <3yEmX_TScPCLb-W1zwHwEXZXvXWAzemtwCtYTFPsSXg=.d8aaa569-8812-45dd-a3b5-af99b677165b@github.com>
References: <b228oWPoEJf0lfGgIVXwmo1mATeKWRTivuJ2PbgwAmI=.465a4f9b-7a4b-4bbb-9f94-66d1d889a072@github.com>
 <3yEmX_TScPCLb-W1zwHwEXZXvXWAzemtwCtYTFPsSXg=.d8aaa569-8812-45dd-a3b5-af99b677165b@github.com>
Message-ID: <SJRHEgWT3V7Qun7tbzqhL1XSzU_H55dp6RkVoDtLmDo=.0e2b6336-897b-4b3d-88cb-2d47c2c9fdc1@github.com>

On Thu, 2 Feb 2023 15:44:54 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> `ZoneOffset` instances are cached by the `ZoneOffset` class itself for values in the range [-18h, 18h] for each second that is on an even quarter of an hour (i.e. at most 2*18*4+1 = 145 values). 
>> 
>> Instead of using a `ConcurrentHashMap` for caching instanced, we could instead use an `AtomicReferenceArray` with direct slot value access for said even seconds. This will improve performance and reduce the number of object even though the backing array will go from an initial 32 in the CHM to an initial/final 145 in the ARA. The CHM will contain much more objects and array slots for typical numbers of entries in the cache and will compute hash/bucket/collision on the hot code path for each cache access.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix benchmark

Updated figures with the new benchmark:


Baseline
Result "org.openjdk.bench.java.time.ZoneOffsetBench.getFromCache":
  887.478 ?(99.9%) 10.206 ns/op [Average]
  (min, avg, max) = (876.206, 887.478, 906.754), stdev = 9.547
  CI (99.9%): [877.271, 897.684] (assumes normal distribution)


Patch
Result "org.openjdk.bench.java.time.ZoneOffsetBench.getFromCache":
  252.646 ?(99.9%) 2.794 ns/op [Average]
  (min, avg, max) = (250.451, 252.646, 258.890), stdev = 2.614
  CI (99.9%): [249.851, 255.440] (assumes normal distribution)



JDK 20 - Baseline (JDK 21 before patch)
JDK 21 - Patch

![image](https://user-images.githubusercontent.com/7457876/216381349-38318d43-a9f3-44f8-9019-293ddd7bf3e2.png)

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

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

From naoto at openjdk.org  Thu Feb  2 17:50:28 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 2 Feb 2023 17:50:28 GMT
Subject: RFR: 8300869: Make use of the Double.toString(double) algorithm in
 java.util.Formatter [v8]
In-Reply-To: <BmEb7ZreTAdkNarpJgk7pZGGU8Ed6uNsexlvk4xlrbM=.85509eb8-9950-4a43-9703-edf9de311fe2@github.com>
References: <SBTbJWmhb-9rmOWnNXtIH-ztXLj2fNvdE0XCMIVmoZA=.5a6a1ef3-a42a-4675-96c1-a137c5f6ec1a@github.com>
 <BmEb7ZreTAdkNarpJgk7pZGGU8Ed6uNsexlvk4xlrbM=.85509eb8-9950-4a43-9703-edf9de311fe2@github.com>
Message-ID: <yaW9YMxSo_PEaeRilctDOzD9Tg23ei3p3cO7jJkKJ60=.ec1958a8-4946-4de3-9ae2-4a05ef7d03da@github.com>

On Wed, 1 Feb 2023 10:26:26 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> Align `double` and `float` decimal conversions in `java.util.Formatter` with the algorithm used in `Double.toString(double)`.
>
> Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8300869: Make use of the Double.toString(double) algorithm in java.util.Formatter

I skimmed through the changes, and see no problem wrt the i18n area.

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

Marked as reviewed by naoto (Reviewer).

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

From darcy at openjdk.org  Thu Feb  2 18:06:00 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Thu, 2 Feb 2023 18:06:00 GMT
Subject: RFR: JDK-8301392: Port fdlibm log1p to Java [v5]
In-Reply-To: <g8yhvnKZcwHr9U-z5SqNsw2vLN7ZbdeF8bgazG7eFE4=.326c60bb-81c6-449f-b9bc-8ca5bdcfde99@github.com>
References: <g8yhvnKZcwHr9U-z5SqNsw2vLN7ZbdeF8bgazG7eFE4=.326c60bb-81c6-449f-b9bc-8ca5bdcfde99@github.com>
Message-ID: <cu_O-WJLTAkLqwkKKcyNL2iqlnLVHGWazJQZ_rrNmCY=.e68eb259-ce60-4653-8c21-d0f4a98a2b58@github.com>

> Another day, another PR to port FDLBIM to Java, this time for the log1p method.
> 
> Other than using the two-argument form of the __HI method in Java transliteration version rather than C macro, there are no appreciable differences between the original C source in 
> 
> src/java.base/share/native/libfdlibm/s_log1p.c
> 
> and the transliteration for testing purposes in
> 
> test/jdk/java/lang/StrictMath/FdlibmTranslit.java
> 
> The more idiomatic port in
> 
> src/java.base/share/classes/java/lang/FdLibm.java
> 
> has had a series of transformation applied layering on the transliteration. The intermediate commits show the progress.
> 
> The regression tests include probing around input values the implementation uses to decided which branch to take.

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

  Refine test per code review feedback.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12301/files
  - new: https://git.openjdk.org/jdk/pull/12301/files/b3e028ac..7740edc9

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

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

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

From darcy at openjdk.org  Thu Feb  2 18:08:31 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Thu, 2 Feb 2023 18:08:31 GMT
Subject: RFR: JDK-8301392: Port fdlibm log1p to Java [v4]
In-Reply-To: <-LKgfwm1P6wdF-URmH-SyfYPnN8reUM59XYynmrDb00=.c86e486a-a742-4164-8aa9-3658a5535feb@github.com>
References: <g8yhvnKZcwHr9U-z5SqNsw2vLN7ZbdeF8bgazG7eFE4=.326c60bb-81c6-449f-b9bc-8ca5bdcfde99@github.com>
 <iP_zmf7-2sC65mDLRC3CCTITEwj1OpxXGp1OBfBaIFg=.a4e5e7db-9dba-47db-8fbf-cfbd94984d22@github.com>
 <dXpm4P0-L-k21ryHfESXYAHOTWs2SOK88fxZd8d4Xtc=.312e15c3-cb44-46fd-8ecd-656766bacc9c@github.com>
 <-LKgfwm1P6wdF-URmH-SyfYPnN8reUM59XYynmrDb00=.c86e486a-a742-4164-8aa9-3658a5535feb@github.com>
Message-ID: <ppjBSVNWllKF2jc5ETyvSH8MGygBsm9HWRHye-obiOI=.c62d0160-1aaf-4b4e-9b83-6b628a090e27@github.com>

On Thu, 2 Feb 2023 10:04:39 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> test/jdk/java/lang/StrictMath/Log1pTests.java line 245:
>> 
>>> 243:              -0x1.0p-54,
>>> 244:               0x1.0p-54,
>>> 245: 
>> 
>> maybe add a comment like
>> `/* approximations around sqrt(2)/2 - 1 and around sqrt(2) - 1 */`
>
> (I mean, for the doubles starting at L.246)

> maybe add a comment like `/* approximations around sqrt(2)/2 - 1 and around sqrt(2) - 1 */`

Good clarification.

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

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

From jbhateja at openjdk.org  Thu Feb  2 18:11:27 2023
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Thu, 2 Feb 2023 18:11:27 GMT
Subject: RFR: 8293198: [vectorapi] Improve the implementation of
 VectorMask.indexInRange()
In-Reply-To: <BaXpr7WSFP0elo2Z3Qk5DJlAC3xgJLHZ1UITbUxjsCg=.d429f7b4-7493-44e3-a734-7adf238c51ff@github.com>
References: <fN58bi3n01tqWpG0-jjUPZQe8hmls2GQ5X3NL2o1RPg=.80e7965d-50af-4fac-bd7c-0a2b99cffe7e@github.com>
 <ueWKU-J85vkS2Iss-2P1YvBAgbywubU6rnXLI4ddZ-o=.b566a7e6-98cb-4897-ab61-970e3388ff5a@github.com>
 <xrdln-eR6POz41Xgq4fVbV6FPVQ_Eq0dCcRhOx6dGIs=.6d29b24c-71c1-4906-b256-b2cc6af25a75@github.com>
 <3h2CWPKB8YKgZnSE9iMBe114cI2VSGp4UZDgZTK5I-8=.c44439d2-c598-4aa9-bcf5-288a226280d7@github.com>
 <wj-6qdPOG8OMnqBd88LlMI_KSd-dWTl7jhOZLB1hu94=.955c5e16-9f14-44c2-92b0-cd0da5a4f633@github.com>
 <BaXpr7WSFP0elo2Z3Qk5DJlAC3xgJLHZ1UITbUxjsCg=.d429f7b4-7493-44e3-a734-7adf238c51ff@github.com>
Message-ID: <3FVPcbRS3IKcSY3cvfKJ9FtGwiFVs7vxMv8Pr3ylCIs=.1e17fdcc-4738-41d7-baf3-1cf4741ed1d4@github.com>

On Thu, 2 Feb 2023 08:15:14 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

>> While you talked about Java side changes, I found another opportunity for optimization in checkIndex0 implementation, in the following code snippet from checkIndex0 method, indexLimit is guaranteed to be a +ve value.
>> 
>> 
>>          int indexLimit = Math.max(0, Math.min(length - offset, vlength));
>>          VectorMask<E> badMask =
>>             iota.compare(GE, iota.broadcast(indexLimit)); 
>> 
>> For float/double iota vectors, subsequent broadcast operation accepting long argument checks for precision loss before broadcasting floating point value.  
>> 
>> 
>>        long longToElementBits(long value) {
>>             // Do the conversion, and then test it for failure.
>>             float e = (float) value;
>>             if ((long) e != value) {
>>                 throw badElementBits(value, e);
>>             }
>>             return toBits(e);
>>         }`
>> 
>>  
>> This can be saved by doing a prior casting of indexLimit to floating point value before calling broadcast, effectively we may need to move checkIndex0 to template generated abstract vector classes.
>
> Hi, I modified a version by using the old implementation for the tail loop instead of adding the new intrinsics. The code looks like:
> 
> public VectorMask<E> indexInRange(int offset, int limit) {
>         int vlength = length();
>         if (offset >= 0 && limit - offset >= length()) {
>             return this;
>         } else if (offset >= limit) {
>             return vectorSpecies().maskAll(false);
>         }
> 
>         Vector<E> iota = vectorSpecies().zero().addIndex(1);
>         VectorMask<E> badMask = checkIndex0(offset, limit, iota, vlength);
>         return this.andNot(badMask);
>     }
> 
> And I tested the performance of the new added benchmarks with different vector size on NEON/SVE and x86 avx2/avx512 architectures. The results show that the performance of changed version is not better than the current version, if the array size is not aligned with the vector size, especially for the double/long type with larger size.
> 
> Here are some raw data with NEON:
> 
> Benchmark                                 (size)   Mode  Cnt  current   modified   Units
> IndexInRangeBenchmark.byteIndexInRange       131  thrpt    5  2654.919  2584.423   ops/ms
> IndexInRangeBenchmark.byteIndexInRange       259  thrpt    5  1830.364  1802.876   ops/ms
> IndexInRangeBenchmark.byteIndexInRange       515  thrpt    5  1058.548  1073.742   ops/ms
> IndexInRangeBenchmark.doubleIndexInRange     131  thrpt    5   594.920   593.832   ops/ms
> IndexInRangeBenchmark.doubleIndexInRange     259  thrpt    5   308.678   149.279   ops/ms
> IndexInRangeBenchmark.doubleIndexInRange     515  thrpt    5   160.639    74.579   ops/ms
> IndexInRangeBenchmark.floatIndexInRange      131  thrpt    5  1097.567  1104.008   ops/ms
> IndexInRangeBenchmark.floatIndexInRange      259  thrpt    5   617.845   606.886   ops/ms
> IndexInRangeBenchmark.floatIndexInRange      515  thrpt    5   315.978   152.046   ops/ms
> IndexInRangeBenchmark.intIndexInRange        131  thrpt    5  1165.279  1205.486   ops/ms
> IndexInRangeBenchmark.intIndexInRange        259  thrpt    5   633.648   631.672   ops/ms
> IndexInRangeBenchmark.intIndexInRange        515  thrpt    5   315.370   154.144   ops/ms
> IndexInRangeBenchmark.longIndexInRange       131  thrpt    5   639.840   633.623   ops/ms
> IndexInRangeBenchmark.longIndexInRange       259  thrpt    5   312.267   152.788   ops/ms
> IndexInRangeBenchmark.longIndexInRange       515  thrpt    5   163.028    78.150   ops/ms
> IndexInRangeBenchmark.shortIndexInRange      131  thrpt    5  1834.318  1800.318   ops/ms
> IndexInRangeBenchmark.shortIndexInRange      259  thrpt    5  1105.695  1094.347   ops/ms
> IndexInRangeBenchmark.shortIndexInRange      515  thrpt    5   602.442   599.827   ops/ms
> 
> 
> And the data with SVE 256-bit vector size:
> 
> Benchmark                                 (size)   Mode  Cnt   current   modified Units
> IndexInRangeBenchmark.byteIndexInRange       131  thrpt    5  23772.370 22921.113 ops/ms
> IndexInRangeBenchmark.byteIndexInRange       259  thrpt    5  18930.388 17920.910 ops/ms
> IndexInRangeBenchmark.byteIndexInRange       515  thrpt    5  13528.610 13282.504 ops/ms
> IndexInRangeBenchmark.doubleIndexInRange     131  thrpt    5   7850.522  7975.720 ops/ms
> IndexInRangeBenchmark.doubleIndexInRange     259  thrpt    5   4281.749  4373.926 ops/ms
> IndexInRangeBenchmark.doubleIndexInRange     515  thrpt    5   2160.001   604.458 ops/ms
> IndexInRangeBenchmark.floatIndexInRange      131  thrpt    5  13594.943 13306.904 ops/ms
> IndexInRangeBenchmark.floatIndexInRange      259  thrpt    5   8163.134  7912.343 ops/ms
> IndexInRangeBenchmark.floatIndexInRange      515  thrpt    5   4335.529  4198.555 ops/ms
> IndexInRangeBenchmark.intIndexInRange        131  thrpt    5  22106.880 20348.266 ops/ms
> IndexInRangeBenchmark.intIndexInRange        259  thrpt    5  11711.588 10958.299 ops/ms
> IndexInRangeBenchmark.intIndexInRange        515  thrpt    5   5501.034  5358.441 ops/ms
> IndexInRangeBenchmark.longIndexInRange       131  thrpt    5   9832.578  9829.398 ops/ms
> IndexInRangeBenchmark.longIndexInRange       259  thrpt    5   4979.326  4947.166 ops/ms
> IndexInRangeBenchmark.longIndexInRange       515  thrpt    5   2269.131   614.204 ops/ms
> IndexInRangeBenchmark.shortIndexInRange      131  thrpt    5  19865.866 19297.628 ops/ms
> IndexInRangeBenchmark.shortIndexInRange      259  thrpt    5  14005.214 13592.407 ops/ms
> IndexInRangeBenchmark.shortIndexInRange      515  thrpt    5   8766.450  8531.675 ops/ms
> 
> As a conclusion, I prefer to keep the current version. WDYT?

Yes, I agree, I did collect performance data with your benchmarks at various AVX levels and see significant gains.

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

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

From duke at openjdk.org  Thu Feb  2 18:31:30 2023
From: duke at openjdk.org (kabutz)
Date: Thu, 2 Feb 2023 18:31:30 GMT
Subject: Integrated: 8301637: ThreadLocalRandom.current().doubles().parallel()
 contention
In-Reply-To: <-mno_ek28PD0IyhDHBc3-ZCqGFq9G5t_Yt73ub665uA=.5e3e655e-631d-4302-b91c-6288581a1070@github.com>
References: <-mno_ek28PD0IyhDHBc3-ZCqGFq9G5t_Yt73ub665uA=.5e3e655e-631d-4302-b91c-6288581a1070@github.com>
Message-ID: <eizt8hUQIkwzkK9igCouAIZHvXexzU8DFheqr0fwQfU=.d42874e3-a64e-451b-b01c-d62d3cc42660@github.com>

On Wed, 1 Feb 2023 15:51:33 GMT, kabutz <duke at openjdk.org> wrote:

> ThreadLocalRandom.current().doubles().parallel() had a bad regression, because it called the superclass methods of the ThreadLocalRandomProxy's nextDouble() method instead of delegating to the ThreadLocalRandom.current().
> 
> Affects all versions of ThreadLocalRandom since Java 17.

This pull request has now been integrated.

Changeset: cf6b9eb8
Author:    Dr Heinz M. Kabutz <heinz at javaspecialists.eu>
Committer: Tagir F. Valeev <tvaleev at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/cf6b9eb8c8cca4a54fbd97fb073eafc1b8835099
Stats:     4 lines in 1 file changed: 4 ins; 0 del; 0 mod

8301637: ThreadLocalRandom.current().doubles().parallel() contention

Reviewed-by: alanb

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

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

From rgiulietti at openjdk.org  Thu Feb  2 19:14:35 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Thu, 2 Feb 2023 19:14:35 GMT
Subject: Integrated: 8300869: Make use of the Double.toString(double) algorithm
 in java.util.Formatter
In-Reply-To: <SBTbJWmhb-9rmOWnNXtIH-ztXLj2fNvdE0XCMIVmoZA=.5a6a1ef3-a42a-4675-96c1-a137c5f6ec1a@github.com>
References: <SBTbJWmhb-9rmOWnNXtIH-ztXLj2fNvdE0XCMIVmoZA=.5a6a1ef3-a42a-4675-96c1-a137c5f6ec1a@github.com>
Message-ID: <XnJFbZ_uc73ulODZfg2QvWzvb5yBenqA1tSq4M_PSRA=.8f0de484-3ec4-4940-b4f8-b358de3547d2@github.com>

On Fri, 27 Jan 2023 16:02:38 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

> Align `double` and `float` decimal conversions in `java.util.Formatter` with the algorithm used in `Double.toString(double)`.

This pull request has now been integrated.

Changeset: f696785f
Author:    Raffaello Giulietti <rgiulietti at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/f696785fd3bc5b27c06260088a2e0ce520e12142
Stats:     936 lines in 11 files changed: 524 ins; 372 del; 40 mod

8300869: Make use of the Double.toString(double) algorithm in java.util.Formatter

Reviewed-by: darcy, naoto

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

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

From rriggs at openjdk.org  Thu Feb  2 19:18:26 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 2 Feb 2023 19:18:26 GMT
Subject: RFR: 8300235: Use VarHandle access in Image(Input |
 Output)StreamImpl classes [v3]
In-Reply-To: <j_I89bmSRiKzBcN0t4m-FxKFABD5pisKPrkVeORuAIM=.3587f329-a2ca-4779-8a6f-e17f3cacebc9@github.com>
References: <PPJBgKqkFFPV_e0GALCKfL3IXCw162qaY0IRWw4S0-M=.e118bdd0-f7b4-4765-9fba-5206ee264f7f@github.com>
 <j_I89bmSRiKzBcN0t4m-FxKFABD5pisKPrkVeORuAIM=.3587f329-a2ca-4779-8a6f-e17f3cacebc9@github.com>
Message-ID: <doj0tfo-LObflO9ZKWAQ5J7Mm3btecZTVbkUtwpK0Vg=.e13304b2-f3c0-4f89-96be-740604de8efd@github.com>

On Thu, 2 Feb 2023 15:04:57 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR suggests improving performance by using the newly introduced class `jdk.internal.util.ByteArray` to improve packing/unpacking operations.
>> 
>> The PR also proposes adding a `ByteArrayLittleEndian` class for support for little endian packing/unpacking.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix problem in benchmark

Looks good. 
Thanks for the JMH benchmarks.

src/java.base/share/classes/jdk/internal/util/ByteArrayLittleEndian.java line 420:

> 418:     }
> 419: 
> 420:     private static VarHandle create(Class<?> viewArrayClass) {

Renaming the method to `createLittleEndian` would make the static assignments at the top unambiguous.

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

Marked as reviewed by rriggs (Reviewer).

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

From pminborg at openjdk.org  Thu Feb  2 19:29:05 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 2 Feb 2023 19:29:05 GMT
Subject: RFR: 8300235: Use VarHandle access in Image(Input |
 Output)StreamImpl classes [v4]
In-Reply-To: <PPJBgKqkFFPV_e0GALCKfL3IXCw162qaY0IRWw4S0-M=.e118bdd0-f7b4-4765-9fba-5206ee264f7f@github.com>
References: <PPJBgKqkFFPV_e0GALCKfL3IXCw162qaY0IRWw4S0-M=.e118bdd0-f7b4-4765-9fba-5206ee264f7f@github.com>
Message-ID: <ViV_w-br_doi4-b5zLEUNoco0hH-5OOIDGMZVCHIRsU=.149b260e-a50c-4c22-8782-ddb1c29ec1bd@github.com>

> This PR suggests improving performance by using the newly introduced class `jdk.internal.util.ByteArray` to improve packing/unpacking operations.
> 
> The PR also proposes adding a `ByteArrayLittleEndian` class for support for little endian packing/unpacking.

Per Minborg has updated the pull request incrementally with one additional commit since the last revision:

  Rename to createLittleEndian

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12204/files
  - new: https://git.openjdk.org/jdk/pull/12204/files/68d72946..d58e22fc

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

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

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

From mchung at openjdk.org  Thu Feb  2 20:18:14 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Thu, 2 Feb 2023 20:18:14 GMT
Subject: RFR: JDK-8301704: Shorten the number of GCs in UnloadingTest.java to
 verify a class loader not being unloaded
Message-ID: <bdUKXSHJGqFT5OdTZgU21MwCcuP9aAkg3lIP3WQbyJY=.c41376be-4fc1-409c-a2c1-42f1d0b30aba@github.com>

`test/jdk/java/lang/invoke/defineHiddenClass/UnloadingTest.java` defines hidden classes and verify cases that a class loader is not unloaded using `ForceGC::wait`.    ForceGC::wait` defaults the timeout to 1000ms * jtreg timeout factor, which is designed to work well to expect an object being reclaimed, i.e. the boolean supplier returns true.   On the other hand, if the boolean supplier never returns true, the method returns after it timeouts which may be long depending on the timeout factor. 

This PR adds a variant of `ForceGC::wait` to take a timeout parameter and tests can specify the timeout to reduce the time it takes testing a strongly reachable object not being reclaimed.

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

Commit messages:
 - JDK-8301704: Shorten the number of GCs in UnloadingTest.java to verify a strongly reachable object not being unloaded

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

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

From bpb at openjdk.org  Thu Feb  2 20:32:37 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 2 Feb 2023 20:32:37 GMT
Subject: RFR: JDK-8301392: Port fdlibm log1p to Java [v5]
In-Reply-To: <cu_O-WJLTAkLqwkKKcyNL2iqlnLVHGWazJQZ_rrNmCY=.e68eb259-ce60-4653-8c21-d0f4a98a2b58@github.com>
References: <g8yhvnKZcwHr9U-z5SqNsw2vLN7ZbdeF8bgazG7eFE4=.326c60bb-81c6-449f-b9bc-8ca5bdcfde99@github.com>
 <cu_O-WJLTAkLqwkKKcyNL2iqlnLVHGWazJQZ_rrNmCY=.e68eb259-ce60-4653-8c21-d0f4a98a2b58@github.com>
Message-ID: <My2pWqkZqZppmXj_Kyk1Hp64Ns9Bo8ZsbrBJfB6c5JI=.57318be4-7a29-45af-8b2e-57487cace164@github.com>

On Thu, 2 Feb 2023 18:06:00 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Another day, another PR to port FDLBIM to Java, this time for the log1p method.
>> 
>> Other than using the two-argument form of the __HI method in Java transliteration version rather than C macro, there are no appreciable differences between the original C source in 
>> 
>> src/java.base/share/native/libfdlibm/s_log1p.c
>> 
>> and the transliteration for testing purposes in
>> 
>> test/jdk/java/lang/StrictMath/FdlibmTranslit.java
>> 
>> The more idiomatic port in
>> 
>> src/java.base/share/classes/java/lang/FdLibm.java
>> 
>> has had a series of transformation applied layering on the transliteration. The intermediate commits show the progress.
>> 
>> The regression tests include probing around input values the implementation uses to decided which branch to take.
>
> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Refine test per code review feedback.

No problems apparent to me: Reviewed.

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

Marked as reviewed by bpb (Reviewer).

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

From darcy at openjdk.org  Thu Feb  2 20:39:29 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Thu, 2 Feb 2023 20:39:29 GMT
Subject: Integrated: JDK-8301392: Port fdlibm log1p to Java
In-Reply-To: <g8yhvnKZcwHr9U-z5SqNsw2vLN7ZbdeF8bgazG7eFE4=.326c60bb-81c6-449f-b9bc-8ca5bdcfde99@github.com>
References: <g8yhvnKZcwHr9U-z5SqNsw2vLN7ZbdeF8bgazG7eFE4=.326c60bb-81c6-449f-b9bc-8ca5bdcfde99@github.com>
Message-ID: <K8VURrQCFf5KpU7U8Fd-zULqmsaYjFh1VgAD-w4JM9A=.f99e60c7-cdc5-4d38-8f5a-97c25e8049ce@github.com>

On Tue, 31 Jan 2023 02:52:45 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Another day, another PR to port FDLBIM to Java, this time for the log1p method.
> 
> Other than using the two-argument form of the __HI method in Java transliteration version rather than C macro, there are no appreciable differences between the original C source in 
> 
> src/java.base/share/native/libfdlibm/s_log1p.c
> 
> and the transliteration for testing purposes in
> 
> test/jdk/java/lang/StrictMath/FdlibmTranslit.java
> 
> The more idiomatic port in
> 
> src/java.base/share/classes/java/lang/FdLibm.java
> 
> has had a series of transformation applied layering on the transliteration. The intermediate commits show the progress.
> 
> The regression tests include probing around input values the implementation uses to decided which branch to take.

This pull request has now been integrated.

Changeset: ee0f5b5e
Author:    Joe Darcy <darcy at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/ee0f5b5ed0f8f081c5e61e2083c31863cbf14fd2
Stats:     410 lines in 4 files changed: 395 ins; 1 del; 14 mod

8301392: Port fdlibm log1p to Java

Reviewed-by: bpb

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

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

From rriggs at openjdk.org  Thu Feb  2 21:43:35 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 2 Feb 2023 21:43:35 GMT
Subject: Withdrawn: 8297271: AccessFlags should be specific to class file
 version
In-Reply-To: <T91R2VWcljZdnCDmWKcuSubKtS2qk5e5sGgKEi1v3Yk=.510cef48-e0f0-4590-b7d4-c16aafe71087@github.com>
References: <T91R2VWcljZdnCDmWKcuSubKtS2qk5e5sGgKEi1v3Yk=.510cef48-e0f0-4590-b7d4-c16aafe71087@github.com>
Message-ID: <sNQogysTL725R_K0VcpBZ8VzOvko1RVDHQUw8ciO4V0=.41a93093-a00c-4336-b8e1-303dd0995da7@github.com>

On Mon, 28 Nov 2022 22:56:27 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> The accessFlags() methods added (in JDK 20, the current release) to java.lang.Class, java.lang.reflect.Executable, and java.lang.reflect.Field implicitly uses the access flags from the current/most recent class file format version. For current and past class file format versions there are few significant variations but future changes are anticipated that change the meaning of some access flag mask bits.
> 
> The accessFlags() methods are clarified to return the access flags that are applicable to the class file format version of the class. The existing AccessFlag.Locations API already contains information about the locations that are applicable to a class file format version. That information should be used to construct the set of AccessFlags returned. A method is added to AccessFlag that returns the applicable flags for a particular mask, Location, and class file format version:

This pull request has been closed without being integrated.

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

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

From bhuang at openjdk.org  Thu Feb  2 22:14:08 2023
From: bhuang at openjdk.org (Bill Huang)
Date: Thu, 2 Feb 2023 22:14:08 GMT
Subject: RFR: JDK-8299994: java/security/Policy/Root/Root.java fails when
 home directory is read-only [v4]
In-Reply-To: <qIGOmJu4rLPxuoDW-zteCD-5kapxMWxc2k6ra3kgXpA=.64cb7150-e0d1-4f6e-82ae-3641c0f1d772@github.com>
References: <qIGOmJu4rLPxuoDW-zteCD-5kapxMWxc2k6ra3kgXpA=.64cb7150-e0d1-4f6e-82ae-3641c0f1d772@github.com>
Message-ID: <P7tVGmixEOz2ZMOshVQl8eMbnSbDZ2nVtVTJLe99lk0=.0d45c4eb-508d-4abf-ac7c-35ddce949c27@github.com>

> Root.java is changed to a manual test because it requires test to be run with the root user privilege, and it requires to modify the user policy file in the home director.

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

  Check non-windows platform before retrieving user id.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12354/files
  - new: https://git.openjdk.org/jdk/pull/12354/files/3b736036..49848a01

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

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

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

From darcy at openjdk.org  Thu Feb  2 22:35:29 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Thu, 2 Feb 2023 22:35:29 GMT
Subject: RFR: JDK-8301396: Port fdlibm expm1 to Java
Message-ID: <U3Jo6dH5rPBRmSVceetCxwisBbTPlaHshGCP2zL9kD0=.1d76ebf0-e729-4066-b9b6-46e06b350eb3@github.com>

Next on the FDLIBM C -> Java port, expm1.
Coming soon, hyperbolic transcendentals (sinh, cosh, tanh)!

For expm1, the C vs transliteration port show the usual kind of differences, beside formatting of the constants, the use of the __HI macro on the left-hand side needs to be replaced by a method call and an assignment, as seen below:


< 
< #include "fdlibm.h"
< 
< #ifdef __STDC__
< static const double
< #else
< static double
< #endif
< one             = 1.0,
< huge            = 1.0e+300,
< tiny            = 1.0e-300,
< o_threshold     = 7.09782712893383973096e+02,/* 0x40862E42, 0xFEFA39EF */
< ln2_hi          = 6.93147180369123816490e-01,/* 0x3fe62e42, 0xfee00000 */
< ln2_lo          = 1.90821492927058770002e-10,/* 0x3dea39ef, 0x35793c76 */
< invln2          = 1.44269504088896338700e+00,/* 0x3ff71547, 0x652b82fe */
---
>     static class Expm1 {
>         private static final double one             = 1.0;
>         private static final double huge            = 1.0e+300;
>         private static final double tiny            = 1.0e-300;
>         private static final double o_threshold     = 7.09782712893383973096e+02; /* 0x40862E42, 0xFEFA39EF */
>         private static final double ln2_hi          = 6.93147180369123816490e-01; /* 0x3fe62e42, 0xfee00000 */
>         private static final double ln2_lo          = 1.90821492927058770002e-10; /* 0x3dea39ef, 0x35793c76 */
>         private static final double invln2          = 1.44269504088896338700e+00; /* 0x3ff71547, 0x652b82fe */
111,115c104,108
< Q1  =  -3.33333333333331316428e-02, /* BFA11111 111110F4 */
< Q2  =   1.58730158725481460165e-03, /* 3F5A01A0 19FE5585 */
< Q3  =  -7.93650757867487942473e-05, /* BF14CE19 9EAADBB7 */
< Q4  =   4.00821782732936239552e-06, /* 3ED0CFCA 86E65239 */
< Q5  =  -2.01099218183624371326e-07; /* BE8AFDB7 6E09C32D */
---
>         private static final double Q1  =  -3.33333333333331316428e-02; /* BFA11111 111110F4 */
>         private static final double Q2  =   1.58730158725481460165e-03; /* 3F5A01A0 19FE5585 */
>         private static final double Q3  =  -7.93650757867487942473e-05; /* BF14CE19 9EAADBB7 */
>         private static final double Q4  =   4.00821782732936239552e-06; /* 3ED0CFCA 86E65239 */
>         private static final double Q5  =  -2.01099218183624371326e-07; /* BE8AFDB7 6E09C32D */
117,123c110
< #ifdef __STDC__
<         double expm1(double x)
< #else
<         double expm1(x)
<         double x;
< #endif
< {
---
>         static double compute(double x) {
126c113
<         unsigned hx;
---
>             /*unsigned*/ int hx;
157c144
<                 k  = invln2*x+((xsb==0)?0.5:-0.5);
---
>                     k  = (int)(invln2*x+((xsb==0)?0.5:-0.5));
188c175
<                 __HI(y) += (k<<20);     /* add k to y's exponent */
---
>                     y = __HI(y,  __HI(y) + (k<<20));     /* add k to y's exponent */
193c180
<                 __HI(t) = 0x3ff00000 - (0x200000>>k);  /* t=1-2^-k */
---
>                     t = __HI(t, 0x3ff00000 - (0x200000>>k));  /* t=1-2^-k */
195c182
<                 __HI(y) += (k<<20);     /* add k to y's exponent */
---
>                     y = __HI(y, __HI(y) + (k<<20));     /* add k to y's exponent */
197c184
<                 __HI(t)  = ((0x3ff-k)<<20);     /* 2^-k */
---
>                     t = __HI(t, ((0x3ff-k)<<20));     /* 2^-k */
200c187
<                 __HI(y) += (k<<20);     /* add k to y's exponent */
---
>                     y = __HI(y, __HI(y) + (k<<20));     /* add k to y's exponent */
205c192
< 
---
>     }


When comparing the transliteration port and the more idiomatic port, there were no surprising or notable differences:


$ diff -w Expm1.translit.java Expm1.fdlibm.java  
99,102c99,102
<         private static final double o_threshold     = 7.09782712893383973096e+02; /* 0x40862E42, 0xFEFA39EF */
<         private static final double ln2_hi          = 6.93147180369123816490e-01; /* 0x3fe62e42, 0xfee00000 */
<         private static final double ln2_lo          = 1.90821492927058770002e-10; /* 0x3dea39ef, 0x35793c76 */
<         private static final double invln2          = 1.44269504088896338700e+00; /* 0x3ff71547, 0x652b82fe */
---
>         private static final double o_threshold =  0x1.62e42fefa39efp9;   //  7.09782712893383973096e+02
>         private static final double ln2_hi      =  0x1.62e42feep-1;       //  6.93147180369123816490e-01
>         private static final double ln2_lo      =  0x1.a39ef35793c76p-33; //  1.90821492927058770002e-10
>         private static final double invln2      =  0x1.71547652b82fep0;   //  1.44269504088896338700e+00
104,108c104,108
<         private static final double Q1  =  -3.33333333333331316428e-02; /* BFA11111 111110F4 */
<         private static final double Q2  =   1.58730158725481460165e-03; /* 3F5A01A0 19FE5585 */
<         private static final double Q3  =  -7.93650757867487942473e-05; /* BF14CE19 9EAADBB7 */
<         private static final double Q4  =   4.00821782732936239552e-06; /* 3ED0CFCA 86E65239 */
<         private static final double Q5  =  -2.01099218183624371326e-07; /* BE8AFDB7 6E09C32D */
---
>         private static final double Q1          = -0x1.11111111110f4p-5;  // -3.33333333333331316428e-02
>         private static final double Q2          =  0x1.a01a019fe5585p-10; //  1.58730158725481460165e-03
>         private static final double Q3          = -0x1.4ce199eaadbb7p-14; // -7.93650757867487942473e-05
>         private static final double Q4          =  0x1.0cfca86e65239p-18; //  4.00821782732936239552e-06
>         private static final double Q5          = -0x1.afdb76e09c32dp-23; // -2.01099218183624371326e-07
116,118c116,118
<             xsb = hx&0x80000000;            /* sign bit of x */
<             if(xsb==0) y=x; else y= -x;     /* y = |x| */
<             hx &= 0x7fffffff;               /* high word of |x| */
---
>             xsb = hx & 0x8000_0000;            /* sign bit of x */
>             y = Math.abs(x);
>             hx &= 0x7fff_ffff;               /* high word of |x| */
121,124c121,124
<             if(hx >= 0x4043687A) {                  /* if |x|>=56*ln2 */
<                 if(hx >= 0x40862E42) {              /* if |x|>=709.78... */
<                     if(hx>=0x7ff00000) {
<                         if(((hx&0xfffff)|__LO(x))!=0)
---
>             if (hx >= 0x4043_687A) {                  /* if |x| >= 56*ln2 */
>                 if (hx >= 0x4086_2E42) {              /* if |x| >= 709.78... */
>                     if (hx >= 0x7ff_00000) {
>                         if (((hx & 0xf_ffff) | __LO(x)) != 0) {
126c126,131
<                         else return (xsb==0)? x:-1.0;/* exp(+-inf)={inf,-1} */
---
>                         } else {
>                             return (xsb == 0)? x : -1.0; /* exp(+-inf)={inf,-1} */
>                         }
>                     }
>                     if (x > o_threshold) {
>                         return huge*huge; /* overflow */
128d132
<                     if(x > o_threshold) return huge*huge; /* overflow */
131c135
<                     if(x+tiny<0.0)          /* raise inexact */
---
>                     if (x + tiny < 0.0) {         /* raise inexact */
134a139
>             }
137,142c142,152
<             if(hx > 0x3fd62e42) {           /* if  |x| > 0.5 ln2 */
<                 if(hx < 0x3FF0A2B2) {       /* and |x| < 1.5 ln2 */
<                     if(xsb==0)
<                         {hi = x - ln2_hi; lo =  ln2_lo;  k =  1;}
<                     else
<                         {hi = x + ln2_hi; lo = -ln2_lo;  k = -1;}
---
>             if (hx > 0x3fd6_2e42) {           /* if  |x| > 0.5 ln2 */
>                 if (hx < 0x3FF0_A2B2) {       /* and |x| < 1.5 ln2 */
>                     if (xsb == 0) {
>                         hi = x - ln2_hi;
>                         lo =  ln2_lo;
>                         k =  1;}
>                     else {
>                         hi = x + ln2_hi;
>                         lo = -ln2_lo;
>                         k = -1;
>                     }
151,152c161
<             }
<             else if(hx < 0x3c900000) {      /* when |x|<2**-54, return x */
---
>             } else if (hx < 0x3c90_0000) {      /* when |x|<2**-54, return x */
154a164,165
>             } else {
>                 k = 0;
156d166
<             else k = 0;
164,165c174,176
<             if(k==0) return x - (x*e-hxs);          /* c is 0 */
<             else {
---
>             if (k == 0) {
>                 return x - (x*e - hxs);          /* c is 0 */
>             } else {
168c179,181
<                 if(k== -1) return 0.5*(x-e)-0.5;
---
>                 if (k == -1) {
>                     return 0.5*(x - e) - 0.5;
>                 }
170,171c183,187
<                     if(x < -0.25) return -2.0*(e-(x+0.5));
<                     else          return  one+2.0*(x-e);
---
>                     if(x < -0.25) {
>                         return -2.0*(e - (x + 0.5));
>                     } else {
>                         return  one + 2.0*(x - e);
>                     }
180c196
<                     t = __HI(t, 0x3ff00000 - (0x200000>>k));  /* t=1-2^-k */
---
>                     t = __HI(t, 0x3ff0_0000 - (0x2_00000 >> k));  /* t=1-2^-k */

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

Commit messages:
 - JDK-8301396: Port fdlibm expm1 to Java

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

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

From bhuang at openjdk.org  Fri Feb  3 00:41:29 2023
From: bhuang at openjdk.org (Bill Huang)
Date: Fri, 3 Feb 2023 00:41:29 GMT
Subject: RFR: JDK-8299994: java/security/Policy/Root/Root.java fails when
 home directory is read-only [v5]
In-Reply-To: <qIGOmJu4rLPxuoDW-zteCD-5kapxMWxc2k6ra3kgXpA=.64cb7150-e0d1-4f6e-82ae-3641c0f1d772@github.com>
References: <qIGOmJu4rLPxuoDW-zteCD-5kapxMWxc2k6ra3kgXpA=.64cb7150-e0d1-4f6e-82ae-3641c0f1d772@github.com>
Message-ID: <1bRlAqwPrUsxVheBscnkECVvkbSVN6rDL0C8Hl-CNHA=.8ffc3074-f047-4054-bac6-060e1c3f89ce@github.com>

> Root.java is changed to a manual test because it requires test to be run with the root user privilege, and it requires to modify the user policy file in the home director.

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

  Exclude Windows.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12354/files
  - new: https://git.openjdk.org/jdk/pull/12354/files/49848a01..b8883211

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

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

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

From jpai at openjdk.org  Fri Feb  3 01:07:06 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 3 Feb 2023 01:07:06 GMT
Subject: RFR: 8301655: Problemlist
 jdk/jdk/nio/zipfs/TestLocOffsetFromZip64EF.java on Linux
In-Reply-To: <t-D5qzxSzHIDoyffNi8j_WxnzMjyJ0bn052nI_3XHDQ=.49a2ca2b-f791-42bb-8fc6-fe57126145be@github.com>
References: <t-D5qzxSzHIDoyffNi8j_WxnzMjyJ0bn052nI_3XHDQ=.49a2ca2b-f791-42bb-8fc6-fe57126145be@github.com>
Message-ID: <IXIzUvASIIIaB92pzKtSQF8CnisNpxu88Lpmu3zsy7g=.4d1b6fbb-fd61-4f36-a1e0-ebc172b554fa@github.com>

On Thu, 2 Feb 2023 02:00:33 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change which problem lists `TestLocOffsetFromZip64EF`? 
> 
> This test uses the `zip` command to generate a zip file. The `zip` binary shipped in recent versions of Linux (like Oracle Linux 9) are missing some features due to what appears to be a regression in that binary. That issue is being addressed upstream in https://bugzilla.redhat.com/show_bug.cgi?id=2162688. Until that issue is fixed, the proposal is to problem list this test on `linux-all` (the issue was reproduced on both `x64` and `aarch64`).

Thank you Lance.

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

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

From jpai at openjdk.org  Fri Feb  3 01:07:07 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 3 Feb 2023 01:07:07 GMT
Subject: Integrated: 8301655: Problemlist
 jdk/jdk/nio/zipfs/TestLocOffsetFromZip64EF.java on Linux
In-Reply-To: <t-D5qzxSzHIDoyffNi8j_WxnzMjyJ0bn052nI_3XHDQ=.49a2ca2b-f791-42bb-8fc6-fe57126145be@github.com>
References: <t-D5qzxSzHIDoyffNi8j_WxnzMjyJ0bn052nI_3XHDQ=.49a2ca2b-f791-42bb-8fc6-fe57126145be@github.com>
Message-ID: <X-twcU6pjzd5k079SzGqmFG931lguSs8Db1bNBT6KVg=.37c96e1b-b32e-42bc-919e-cad512db986d@github.com>

On Thu, 2 Feb 2023 02:00:33 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change which problem lists `TestLocOffsetFromZip64EF`? 
> 
> This test uses the `zip` command to generate a zip file. The `zip` binary shipped in recent versions of Linux (like Oracle Linux 9) are missing some features due to what appears to be a regression in that binary. That issue is being addressed upstream in https://bugzilla.redhat.com/show_bug.cgi?id=2162688. Until that issue is fixed, the proposal is to problem list this test on `linux-all` (the issue was reproduced on both `x64` and `aarch64`).

This pull request has now been integrated.

Changeset: 4c9de876
Author:    Jaikiran Pai <jpai at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/4c9de876bffe5abb94db1c8c2b919d8243317ff8
Stats:     1 line in 1 file changed: 1 ins; 0 del; 0 mod

8301655: Problemlist jdk/jdk/nio/zipfs/TestLocOffsetFromZip64EF.java on Linux

Reviewed-by: lancea

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

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

From xgong at openjdk.org  Fri Feb  3 01:47:52 2023
From: xgong at openjdk.org (Xiaohong Gong)
Date: Fri, 3 Feb 2023 01:47:52 GMT
Subject: RFR: 8293198: [vectorapi] Improve the implementation of
 VectorMask.indexInRange()
In-Reply-To: <3FVPcbRS3IKcSY3cvfKJ9FtGwiFVs7vxMv8Pr3ylCIs=.1e17fdcc-4738-41d7-baf3-1cf4741ed1d4@github.com>
References: <fN58bi3n01tqWpG0-jjUPZQe8hmls2GQ5X3NL2o1RPg=.80e7965d-50af-4fac-bd7c-0a2b99cffe7e@github.com>
 <ueWKU-J85vkS2Iss-2P1YvBAgbywubU6rnXLI4ddZ-o=.b566a7e6-98cb-4897-ab61-970e3388ff5a@github.com>
 <xrdln-eR6POz41Xgq4fVbV6FPVQ_Eq0dCcRhOx6dGIs=.6d29b24c-71c1-4906-b256-b2cc6af25a75@github.com>
 <3h2CWPKB8YKgZnSE9iMBe114cI2VSGp4UZDgZTK5I-8=.c44439d2-c598-4aa9-bcf5-288a226280d7@github.com>
 <wj-6qdPOG8OMnqBd88LlMI_KSd-dWTl7jhOZLB1hu94=.955c5e16-9f14-44c2-92b0-cd0da5a4f633@github.com>
 <BaXpr7WSFP0elo2Z3Qk5DJlAC3xgJLHZ1UITbUxjsCg=.d429f7b4-7493-44e3-a734-7adf238c51ff@github.com>
 <3FVPcbRS3IKcSY3cvfKJ9FtGwiFVs7vxMv8Pr3ylCIs=.1e17fdcc-4738-41d7-baf3-1cf4741ed1d4@github.com>
Message-ID: <m2D9OfhDpkdekq2QRFbpwCMspbkZDOHZXkJFrYlD5tY=.8c3ef5c1-ed3a-4a51-8b29-a379f63346c5@github.com>

On Thu, 2 Feb 2023 18:07:59 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Hi, I modified a version by using the old implementation for the tail loop instead of adding the new intrinsics. The code looks like:
>> 
>> public VectorMask<E> indexInRange(int offset, int limit) {
>>         int vlength = length();
>>         if (offset >= 0 && limit - offset >= length()) {
>>             return this;
>>         } else if (offset >= limit) {
>>             return vectorSpecies().maskAll(false);
>>         }
>> 
>>         Vector<E> iota = vectorSpecies().zero().addIndex(1);
>>         VectorMask<E> badMask = checkIndex0(offset, limit, iota, vlength);
>>         return this.andNot(badMask);
>>     }
>> 
>> And I tested the performance of the new added benchmarks with different vector size on NEON/SVE and x86 avx2/avx512 architectures. The results show that the performance of changed version is not better than the current version, if the array size is not aligned with the vector size, especially for the double/long type with larger size.
>> 
>> Here are some raw data with NEON:
>> 
>> Benchmark                                 (size)   Mode  Cnt  current   modified   Units
>> IndexInRangeBenchmark.byteIndexInRange       131  thrpt    5  2654.919  2584.423   ops/ms
>> IndexInRangeBenchmark.byteIndexInRange       259  thrpt    5  1830.364  1802.876   ops/ms
>> IndexInRangeBenchmark.byteIndexInRange       515  thrpt    5  1058.548  1073.742   ops/ms
>> IndexInRangeBenchmark.doubleIndexInRange     131  thrpt    5   594.920   593.832   ops/ms
>> IndexInRangeBenchmark.doubleIndexInRange     259  thrpt    5   308.678   149.279   ops/ms
>> IndexInRangeBenchmark.doubleIndexInRange     515  thrpt    5   160.639    74.579   ops/ms
>> IndexInRangeBenchmark.floatIndexInRange      131  thrpt    5  1097.567  1104.008   ops/ms
>> IndexInRangeBenchmark.floatIndexInRange      259  thrpt    5   617.845   606.886   ops/ms
>> IndexInRangeBenchmark.floatIndexInRange      515  thrpt    5   315.978   152.046   ops/ms
>> IndexInRangeBenchmark.intIndexInRange        131  thrpt    5  1165.279  1205.486   ops/ms
>> IndexInRangeBenchmark.intIndexInRange        259  thrpt    5   633.648   631.672   ops/ms
>> IndexInRangeBenchmark.intIndexInRange        515  thrpt    5   315.370   154.144   ops/ms
>> IndexInRangeBenchmark.longIndexInRange       131  thrpt    5   639.840   633.623   ops/ms
>> IndexInRangeBenchmark.longIndexInRange       259  thrpt    5   312.267   152.788   ops/ms
>> IndexInRangeBenchmark.longIndexInRange       515  thrpt    5   163.028    78.150   ops/ms
>> IndexInRangeBenchmark.shortIndexInRange      131  thrpt    5  1834.318  1800.318   ops/ms
>> IndexInRangeBenchmark.shortIndexInRange      259  thrpt    5  1105.695  1094.347   ops/ms
>> IndexInRangeBenchmark.shortIndexInRange      515  thrpt    5   602.442   599.827   ops/ms
>> 
>> 
>> And the data with SVE 256-bit vector size:
>> 
>> Benchmark                                 (size)   Mode  Cnt   current   modified Units
>> IndexInRangeBenchmark.byteIndexInRange       131  thrpt    5  23772.370 22921.113 ops/ms
>> IndexInRangeBenchmark.byteIndexInRange       259  thrpt    5  18930.388 17920.910 ops/ms
>> IndexInRangeBenchmark.byteIndexInRange       515  thrpt    5  13528.610 13282.504 ops/ms
>> IndexInRangeBenchmark.doubleIndexInRange     131  thrpt    5   7850.522  7975.720 ops/ms
>> IndexInRangeBenchmark.doubleIndexInRange     259  thrpt    5   4281.749  4373.926 ops/ms
>> IndexInRangeBenchmark.doubleIndexInRange     515  thrpt    5   2160.001   604.458 ops/ms
>> IndexInRangeBenchmark.floatIndexInRange      131  thrpt    5  13594.943 13306.904 ops/ms
>> IndexInRangeBenchmark.floatIndexInRange      259  thrpt    5   8163.134  7912.343 ops/ms
>> IndexInRangeBenchmark.floatIndexInRange      515  thrpt    5   4335.529  4198.555 ops/ms
>> IndexInRangeBenchmark.intIndexInRange        131  thrpt    5  22106.880 20348.266 ops/ms
>> IndexInRangeBenchmark.intIndexInRange        259  thrpt    5  11711.588 10958.299 ops/ms
>> IndexInRangeBenchmark.intIndexInRange        515  thrpt    5   5501.034  5358.441 ops/ms
>> IndexInRangeBenchmark.longIndexInRange       131  thrpt    5   9832.578  9829.398 ops/ms
>> IndexInRangeBenchmark.longIndexInRange       259  thrpt    5   4979.326  4947.166 ops/ms
>> IndexInRangeBenchmark.longIndexInRange       515  thrpt    5   2269.131   614.204 ops/ms
>> IndexInRangeBenchmark.shortIndexInRange      131  thrpt    5  19865.866 19297.628 ops/ms
>> IndexInRangeBenchmark.shortIndexInRange      259  thrpt    5  14005.214 13592.407 ops/ms
>> IndexInRangeBenchmark.shortIndexInRange      515  thrpt    5   8766.450  8531.675 ops/ms
>> 
>> As a conclusion, I prefer to keep the current version. WDYT?
>
> Yes, I agree, I did collect performance data with your benchmarks at various AVX levels and see significant gains. Cause of performance variation b/w integer and floating point cases is due to below limitation.
> https://github.com/openjdk/jdk/pull/12064#discussion_r1094101761
> Which can be addressed in a separate PR.
> 
> FTR here are performance numbers at UseAVX=3
> 
> 
> Benchmark                                 (size)   Mode  Cnt      Score   Error   Units
> IndexInRangeBenchmark.byteIndexInRange      1024  thrpt    2  74983.406          ops/ms
> IndexInRangeBenchmark.byteIndexInRange      1027  thrpt    2  19156.962          ops/ms
> IndexInRangeBenchmark.doubleIndexInRange    1024  thrpt    2  11368.179          ops/ms
> IndexInRangeBenchmark.doubleIndexInRange    1027  thrpt    2   2165.207          ops/ms
> IndexInRangeBenchmark.floatIndexInRange     1024  thrpt    2  18736.787          ops/ms
> IndexInRangeBenchmark.floatIndexInRange     1027  thrpt    2   3798.996          ops/ms
> IndexInRangeBenchmark.intIndexInRange       1024  thrpt    2  18797.863          ops/ms
> IndexInRangeBenchmark.intIndexInRange       1027  thrpt    2   5455.317          ops/ms
> IndexInRangeBenchmark.longIndexInRange      1024  thrpt    2  11866.493          ops/ms
> IndexInRangeBenchmark.longIndexInRange      1027  thrpt    2   2227.896          ops/ms
> IndexInRangeBenchmark.shortIndexInRange     1024  thrpt    2  46921.520          ops/ms
> IndexInRangeBenchmark.shortIndexInRange     1027  thrpt    2   8532.394          ops/ms

Thanks for the performance testing on x86 systems! Agree that a separate PR is fine, and I will address it once this PR merged.

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

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

From jbhateja at openjdk.org  Fri Feb  3 02:05:52 2023
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Fri, 3 Feb 2023 02:05:52 GMT
Subject: RFR: 8293198: [vectorapi] Improve the implementation of
 VectorMask.indexInRange()
In-Reply-To: <fN58bi3n01tqWpG0-jjUPZQe8hmls2GQ5X3NL2o1RPg=.80e7965d-50af-4fac-bd7c-0a2b99cffe7e@github.com>
References: <fN58bi3n01tqWpG0-jjUPZQe8hmls2GQ5X3NL2o1RPg=.80e7965d-50af-4fac-bd7c-0a2b99cffe7e@github.com>
Message-ID: <slq_H7aJmdxgBUkHbT5JolMB19OnGnkYdpZlyzrd87s=.77740147-6ec5-4fd5-a10a-a118389d911c@github.com>

On Wed, 18 Jan 2023 08:58:42 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

> The Vector API `"indexInRange(int offset, int limit)"` is used
> to compute a vector mask whose lanes are set to true if the
> index of the lane is inside the range specified by the `"offset"`
> and `"limit"` arguments, otherwise the lanes are set to false.
> 
> There are two special cases for this API:
>  1) If `"offset >= 0 && offset >= limit"`, all the lanes of the
> generated mask are false.
>  2) If` "offset >= 0 && limit - offset >= vlength"`, all the
> lanes of the generated mask are true. Note that `"vlength"` is
> the number of vector lanes.
> 
> For such special cases, we can simply use `"maskAll(false|true)"`
> to implement the API. Otherwise, the original comparison with
> `"iota" `vector is needed. And for further optimization, we have
> optimal instruction supported by SVE (i.e. whilelo [1]), which
> can implement the API directly if the `"offset >= 0"`.
> 
> As a summary, to optimize the API, we can use the if-else branches
> to handle the specific cases in java level and intrinsify the
> remaining case by C2 compiler:
> 
> 
>   public VectorMask<E> indexInRange(int offset, int limit) {
>       if (offset < 0) {
>           return this.and(indexInRange0Helper(offset, limit));
>       } else if (offset >= limit) {
>           return this.and(vectorSpecies().maskAll(false));
>       } else if (limit - offset >= length()) {
>           return this.and(vectorSpecies().maskAll(true));
>       }
>       return this.and(indexInRange0(offset, limit));
>  }
> 
> 
> The last part (i.e. `"indexInRange0"`) in the above implementation
> is expected to be intrinsified by C2 compiler if the necessary IRs
> are supported. Otherwise, it will fall back to the original API
> implementation (i.e. `"indexInRange0Helper"`). Regarding to the
> intrinsifaction, the compiler will generate `"VectorMaskGen"` IR
> with "limit - offset" as the input if the current platform supports
> it. Otherwise, it generates `"VectorLoadConst + VectorMaskCmp"` based
> on `"iota < limit - offset"`.
> 
> For the following java code which uses `"indexInRange"`:
> 
> 
> static final VectorSpecies<Double> SPECIES =
>                                    DoubleVector.SPECIES_PREFERRED;
> static final int LENGTH = 1027;
> 
> public static double[] da;
> public static double[] db;
> public static double[] dc;
> 
> private static void func() {
>     for (int i = 0; i < LENGTH; i += SPECIES.length()) {
>         var m = SPECIES.indexInRange(i, LENGTH);
>         var av = DoubleVector.fromArray(SPECIES, da, i, m);
>         av.lanewise(VectorOperators.NEG).intoArray(dc, i, m);
>     }
> }
> 
> 
> The core code generated with SVE 256-bit vector size is:
> 
> 
>   ptrue   p2.d                  ; maskAll(true)
>   ...
> LOOP:
>   ...
>   sub     w11, w13, w14         ; limit - offset
>   cmp     w14, w13
>   b.cs    LABEL-1               ; if (offset >= limit) => uncommon-trap
>   cmp     w11, #0x4
>   b.lt    LABEL-2               ; if (limit - offset < vlength)
>   mov     p1.b, p2.b
> LABEL-3:
>   ld1d    {z16.d}, p1/z, [x10]  ; load vector masked
>   ...
>   cmp     w14, w29
>   b.cc    LOOP
>   ...
> LABEL-2:
>   whilelo p1.d, x16, x10        ; VectorMaskGen
>   ...
>   b       LABEL-3
>   ...
> LABEL-1:
>   uncommon-trap
> 
> 
> Please note that if the array size `LENGTH` is aligned with
> the vector size 256 (i.e. `LENGTH = 1024`), the branch "LABEL-2"
> will be optimized out by compiler and it becomes another
> uncommon-trap.
> 
> For NEON, the main CFG is the same with above. But the compiler
> intrinsification is different. Here is the code:
> 
> 
>   sub     x10, x10, x12          ; limit - offset
>   scvtf   d16, x10
>   dup     v16.2d, v16.d[0]       ; replicateD
> 
>   mov     x8, #0xd8d0
>   movk    x8, #0x84cb, lsl #16
>   movk    x8, #0xffff, lsl #32
>   ldr     q17, [x8], #0          ; load the "iota" const vector
>   fcmgt   v18.2d, v16.2d, v17.2d ; mask = iota < limit - offset
> 
> 
> Here is the performance data of the new added benchmark on an ARM
> SVE 256-bit platform:
> 
> 
> Benchmark                               (size)  Before    After   Units
> IndexInRangeBenchmark.byteIndexInRange   1024 11203.697 41404.431 ops/ms
> IndexInRangeBenchmark.byteIndexInRange   1027  2365.920  8747.004 ops/ms
> IndexInRangeBenchmark.doubleIndexInRange 1024  1227.505  6092.194 ops/ms
> IndexInRangeBenchmark.doubleIndexInRange 1027   351.215  1156.683 ops/ms
> IndexInRangeBenchmark.floatIndexInRange  1024  1468.876 11032.580 ops/ms
> IndexInRangeBenchmark.floatIndexInRange  1027   699.645  2439.671 ops/ms
> IndexInRangeBenchmark.intIndexInRange    1024  2842.187 11903.544 ops/ms
> IndexInRangeBenchmark.intIndexInRange    1027   689.866  2547.424 ops/ms
> IndexInRangeBenchmark.longIndexInRange   1024  1394.135  5902.973 ops/ms
> IndexInRangeBenchmark.longIndexInRange   1027   355.621  1189.458 ops/ms
> IndexInRangeBenchmark.shortIndexInRange  1024  5521.468 21578.340 ops/ms
> IndexInRangeBenchmark.shortIndexInRange  1027  1264.816  4640.504 ops/ms
> 
> 
> And the performance data with ARM NEON:
> 
> 
> Benchmark                               (size)  Before    After   Units
> IndexInRangeBenchmark.byteIndexInRange   1024  4026.548 15562.880 ops/ms
> IndexInRangeBenchmark.byteIndexInRange   1027   305.314   576.559 ops/ms
> IndexInRangeBenchmark.doubleIndexInRange 1024   289.224  2244.080 ops/ms
> IndexInRangeBenchmark.doubleIndexInRange 1027    39.740    76.499 ops/ms
> IndexInRangeBenchmark.floatIndexInRange  1024   675.264  4457.470 ops/ms
> IndexInRangeBenchmark.floatIndexInRange  1027    79.918   144.952 ops/ms
> IndexInRangeBenchmark.intIndexInRange    1024   740.139  4014.583 ops/ms
> IndexInRangeBenchmark.intIndexInRange    1027    78.608   147.903 ops/ms
> IndexInRangeBenchmark.longIndexInRange   1024   400.683  2209.551 ops/ms
> IndexInRangeBenchmark.longIndexInRange   1027    41.146    69.599 ops/ms
> IndexInRangeBenchmark.shortIndexInRange  1024  1821.736  8153.546 ops/ms
> IndexInRangeBenchmark.shortIndexInRange  1027   158.810   243.205 ops/ms
> 
> 
> The performance improves about `3.5x ~ 7.5x` on the vector size aligned
> (1024 size) benchmarks both with NEON and SVE. And it improves about
> `3.5x/1.8x` on the vector size not aligned (1027 size) benchmarks with
> SVE/NEON respectively. We can also observe the similar improvement on
> the x86 platforms.
> 
> [1] https://developer.arm.com/documentation/ddi0596/2020-12/SVE-Instructions/WHILELO--While-incrementing-unsigned-scalar-lower-than-scalar-

LGTM

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

Marked as reviewed by jbhateja (Reviewer).

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

From bpb at openjdk.org  Fri Feb  3 02:12:43 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 3 Feb 2023 02:12:43 GMT
Subject: RFR: 8298619: java/io/File/GetXSpace.java is failing
Message-ID: <6LnAAIclo5mZZgba4XUSTSc72vyNrBinzUlO9-kJXbU=.fe0c5e94-9e36-4484-b8e7-0f19cb10cb05@github.com>

Modify the `Space` instances used for size comparison to be created with total number of bytes derived from the Windows `diskFree` utility instead of Cygwin?s `df`.

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

Commit messages:
 - 8298619: java/io/File/GetXSpace.java is failing

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

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

From bpb at openjdk.org  Fri Feb  3 02:12:44 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 3 Feb 2023 02:12:44 GMT
Subject: RFR: 8298619: java/io/File/GetXSpace.java is failing
In-Reply-To: <6LnAAIclo5mZZgba4XUSTSc72vyNrBinzUlO9-kJXbU=.fe0c5e94-9e36-4484-b8e7-0f19cb10cb05@github.com>
References: <6LnAAIclo5mZZgba4XUSTSc72vyNrBinzUlO9-kJXbU=.fe0c5e94-9e36-4484-b8e7-0f19cb10cb05@github.com>
Message-ID: <j_VJAayGVt8inR39keqci478bsy_QRmkppfTT94W6r8=.12559d4f-b16a-41ee-bb6b-e026f589be27@github.com>

On Fri, 3 Feb 2023 02:02:39 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Modify the `Space` instances used for size comparison to be created with total number of bytes derived from the Windows `diskFree` utility instead of Cygwin?s `df`.

With reference to the Windows `DISK_SPACE_INFORMATION` structure, the `File` methods `getTotalSpace`, `getFreeSpace`, and `getUsableSpace` return the number of bytes implied by `CallerTotalAllocationUnits`, `ActualAvailableAllocationUnits`, and `CallerAvailableAllocationUnits`, respectively. The total and usable values reflect any quota imposed on the user. Currently the reference values against which these space values are compared are derived from the Cygwin `df` command. The total number of bytes given by `df` corresponds to `ActualTotalAllocationUnits` and does not account for quotas. Hence it is not appropriate as a reference when quotas are imposed. The total number of bytes indicated by the output of the Windows `diskFree` utility is however equivalent to `CallerTotalAllocationUnits` hence is the correct reference.

With this change the test passes on all platforms, include 110 repeats on Windows.

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

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

From duke at openjdk.org  Fri Feb  3 02:21:59 2023
From: duke at openjdk.org (duke)
Date: Fri, 3 Feb 2023 02:21:59 GMT
Subject: Withdrawn: 8297632: InputStream.transferTo() method should specify
 what the return value should be when the number of bytes transfered is larger
 than Long.MAX_VALUE
In-Reply-To: <T38kO1hcz3rhpqOOPYmoPl1TlRORJBifQWtXLl10x8Y=.595338d3-df98-4202-95b5-eda88a4ed0a2@github.com>
References: <T38kO1hcz3rhpqOOPYmoPl1TlRORJBifQWtXLl10x8Y=.595338d3-df98-4202-95b5-eda88a4ed0a2@github.com>
Message-ID: <h5WHg4WiVhcmVFpdDi8IHcNUDzUJsi2XK3NsB6OEi3Y=.d4d950d6-a194-4c4e-915b-65343ff4bbb4@github.com>

On Tue, 29 Nov 2022 00:56:58 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> `java.io.InputStream::transferTo` could conceivably return a negative value if the count of bytes transferred overflows a `long`. Modify the method to limit the number of bytes transferred to `Long.MAX_VALUE` per invocation.

This pull request has been closed without being integrated.

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

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

From qamai at openjdk.org  Fri Feb  3 02:56:49 2023
From: qamai at openjdk.org (Quan Anh Mai)
Date: Fri, 3 Feb 2023 02:56:49 GMT
Subject: RFR: 8293198: [vectorapi] Improve the implementation of
 VectorMask.indexInRange()
In-Reply-To: <fN58bi3n01tqWpG0-jjUPZQe8hmls2GQ5X3NL2o1RPg=.80e7965d-50af-4fac-bd7c-0a2b99cffe7e@github.com>
References: <fN58bi3n01tqWpG0-jjUPZQe8hmls2GQ5X3NL2o1RPg=.80e7965d-50af-4fac-bd7c-0a2b99cffe7e@github.com>
Message-ID: <8_PwnvpT11s1fv0Mwhrh0ON6ECgsfDy249m0tl4_d2A=.284697c6-b3dc-429c-bf7c-06d6c41d47b2@github.com>

On Wed, 18 Jan 2023 08:58:42 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

> The Vector API `"indexInRange(int offset, int limit)"` is used
> to compute a vector mask whose lanes are set to true if the
> index of the lane is inside the range specified by the `"offset"`
> and `"limit"` arguments, otherwise the lanes are set to false.
> 
> There are two special cases for this API:
>  1) If `"offset >= 0 && offset >= limit"`, all the lanes of the
> generated mask are false.
>  2) If` "offset >= 0 && limit - offset >= vlength"`, all the
> lanes of the generated mask are true. Note that `"vlength"` is
> the number of vector lanes.
> 
> For such special cases, we can simply use `"maskAll(false|true)"`
> to implement the API. Otherwise, the original comparison with
> `"iota" `vector is needed. And for further optimization, we have
> optimal instruction supported by SVE (i.e. whilelo [1]), which
> can implement the API directly if the `"offset >= 0"`.
> 
> As a summary, to optimize the API, we can use the if-else branches
> to handle the specific cases in java level and intrinsify the
> remaining case by C2 compiler:
> 
> 
>   public VectorMask<E> indexInRange(int offset, int limit) {
>       if (offset < 0) {
>           return this.and(indexInRange0Helper(offset, limit));
>       } else if (offset >= limit) {
>           return this.and(vectorSpecies().maskAll(false));
>       } else if (limit - offset >= length()) {
>           return this.and(vectorSpecies().maskAll(true));
>       }
>       return this.and(indexInRange0(offset, limit));
>  }
> 
> 
> The last part (i.e. `"indexInRange0"`) in the above implementation
> is expected to be intrinsified by C2 compiler if the necessary IRs
> are supported. Otherwise, it will fall back to the original API
> implementation (i.e. `"indexInRange0Helper"`). Regarding to the
> intrinsifaction, the compiler will generate `"VectorMaskGen"` IR
> with "limit - offset" as the input if the current platform supports
> it. Otherwise, it generates `"VectorLoadConst + VectorMaskCmp"` based
> on `"iota < limit - offset"`.
> 
> For the following java code which uses `"indexInRange"`:
> 
> 
> static final VectorSpecies<Double> SPECIES =
>                                    DoubleVector.SPECIES_PREFERRED;
> static final int LENGTH = 1027;
> 
> public static double[] da;
> public static double[] db;
> public static double[] dc;
> 
> private static void func() {
>     for (int i = 0; i < LENGTH; i += SPECIES.length()) {
>         var m = SPECIES.indexInRange(i, LENGTH);
>         var av = DoubleVector.fromArray(SPECIES, da, i, m);
>         av.lanewise(VectorOperators.NEG).intoArray(dc, i, m);
>     }
> }
> 
> 
> The core code generated with SVE 256-bit vector size is:
> 
> 
>   ptrue   p2.d                  ; maskAll(true)
>   ...
> LOOP:
>   ...
>   sub     w11, w13, w14         ; limit - offset
>   cmp     w14, w13
>   b.cs    LABEL-1               ; if (offset >= limit) => uncommon-trap
>   cmp     w11, #0x4
>   b.lt    LABEL-2               ; if (limit - offset < vlength)
>   mov     p1.b, p2.b
> LABEL-3:
>   ld1d    {z16.d}, p1/z, [x10]  ; load vector masked
>   ...
>   cmp     w14, w29
>   b.cc    LOOP
>   ...
> LABEL-2:
>   whilelo p1.d, x16, x10        ; VectorMaskGen
>   ...
>   b       LABEL-3
>   ...
> LABEL-1:
>   uncommon-trap
> 
> 
> Please note that if the array size `LENGTH` is aligned with
> the vector size 256 (i.e. `LENGTH = 1024`), the branch "LABEL-2"
> will be optimized out by compiler and it becomes another
> uncommon-trap.
> 
> For NEON, the main CFG is the same with above. But the compiler
> intrinsification is different. Here is the code:
> 
> 
>   sub     x10, x10, x12          ; limit - offset
>   scvtf   d16, x10
>   dup     v16.2d, v16.d[0]       ; replicateD
> 
>   mov     x8, #0xd8d0
>   movk    x8, #0x84cb, lsl #16
>   movk    x8, #0xffff, lsl #32
>   ldr     q17, [x8], #0          ; load the "iota" const vector
>   fcmgt   v18.2d, v16.2d, v17.2d ; mask = iota < limit - offset
> 
> 
> Here is the performance data of the new added benchmark on an ARM
> SVE 256-bit platform:
> 
> 
> Benchmark                               (size)  Before    After   Units
> IndexInRangeBenchmark.byteIndexInRange   1024 11203.697 41404.431 ops/ms
> IndexInRangeBenchmark.byteIndexInRange   1027  2365.920  8747.004 ops/ms
> IndexInRangeBenchmark.doubleIndexInRange 1024  1227.505  6092.194 ops/ms
> IndexInRangeBenchmark.doubleIndexInRange 1027   351.215  1156.683 ops/ms
> IndexInRangeBenchmark.floatIndexInRange  1024  1468.876 11032.580 ops/ms
> IndexInRangeBenchmark.floatIndexInRange  1027   699.645  2439.671 ops/ms
> IndexInRangeBenchmark.intIndexInRange    1024  2842.187 11903.544 ops/ms
> IndexInRangeBenchmark.intIndexInRange    1027   689.866  2547.424 ops/ms
> IndexInRangeBenchmark.longIndexInRange   1024  1394.135  5902.973 ops/ms
> IndexInRangeBenchmark.longIndexInRange   1027   355.621  1189.458 ops/ms
> IndexInRangeBenchmark.shortIndexInRange  1024  5521.468 21578.340 ops/ms
> IndexInRangeBenchmark.shortIndexInRange  1027  1264.816  4640.504 ops/ms
> 
> 
> And the performance data with ARM NEON:
> 
> 
> Benchmark                               (size)  Before    After   Units
> IndexInRangeBenchmark.byteIndexInRange   1024  4026.548 15562.880 ops/ms
> IndexInRangeBenchmark.byteIndexInRange   1027   305.314   576.559 ops/ms
> IndexInRangeBenchmark.doubleIndexInRange 1024   289.224  2244.080 ops/ms
> IndexInRangeBenchmark.doubleIndexInRange 1027    39.740    76.499 ops/ms
> IndexInRangeBenchmark.floatIndexInRange  1024   675.264  4457.470 ops/ms
> IndexInRangeBenchmark.floatIndexInRange  1027    79.918   144.952 ops/ms
> IndexInRangeBenchmark.intIndexInRange    1024   740.139  4014.583 ops/ms
> IndexInRangeBenchmark.intIndexInRange    1027    78.608   147.903 ops/ms
> IndexInRangeBenchmark.longIndexInRange   1024   400.683  2209.551 ops/ms
> IndexInRangeBenchmark.longIndexInRange   1027    41.146    69.599 ops/ms
> IndexInRangeBenchmark.shortIndexInRange  1024  1821.736  8153.546 ops/ms
> IndexInRangeBenchmark.shortIndexInRange  1027   158.810   243.205 ops/ms
> 
> 
> The performance improves about `3.5x ~ 7.5x` on the vector size aligned
> (1024 size) benchmarks both with NEON and SVE. And it improves about
> `3.5x/1.8x` on the vector size not aligned (1027 size) benchmarks with
> SVE/NEON respectively. We can also observe the similar improvement on
> the x86 platforms.
> 
> [1] https://developer.arm.com/documentation/ddi0596/2020-12/SVE-Instructions/WHILELO--While-incrementing-unsigned-scalar-lower-than-scalar-

Can you add benchmarks which perform `indexInRange` on really short arrays, such as with size smaller than that of the vectors.

    var m = ispecies.indexInRange(0, size);
    IntVector.fromArray(ispecies, intIn, 0, m).intoArray(intOut, 0, m);

For longer arrays, I think this code shape is not much more verbose and might perform better:

    int bound = ispecies.loopBound(size);
    for (int i = 0; i < bound; i += ispecies.length()) {
        IntVector.fromArray(ispecies, intIn, i).intoArray(intOut, i);
    }
    var m = ispecies.indexInRange(bound, size);
    IntVector.fromArray(ispecies, intIn, bound, m).intoArray(intOut, bound, m);

Thanks.

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

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

From xgong at openjdk.org  Fri Feb  3 03:08:54 2023
From: xgong at openjdk.org (Xiaohong Gong)
Date: Fri, 3 Feb 2023 03:08:54 GMT
Subject: RFR: 8293198: [vectorapi] Improve the implementation of
 VectorMask.indexInRange()
In-Reply-To: <fN58bi3n01tqWpG0-jjUPZQe8hmls2GQ5X3NL2o1RPg=.80e7965d-50af-4fac-bd7c-0a2b99cffe7e@github.com>
References: <fN58bi3n01tqWpG0-jjUPZQe8hmls2GQ5X3NL2o1RPg=.80e7965d-50af-4fac-bd7c-0a2b99cffe7e@github.com>
Message-ID: <5CIfIv7KGwY4wtIDnmskuFkyzsgOMDOF8G05nEpvleY=.550a1e68-a1b6-4b95-bd4e-8a6ce2bf7a43@github.com>

On Wed, 18 Jan 2023 08:58:42 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

> The Vector API `"indexInRange(int offset, int limit)"` is used
> to compute a vector mask whose lanes are set to true if the
> index of the lane is inside the range specified by the `"offset"`
> and `"limit"` arguments, otherwise the lanes are set to false.
> 
> There are two special cases for this API:
>  1) If `"offset >= 0 && offset >= limit"`, all the lanes of the
> generated mask are false.
>  2) If` "offset >= 0 && limit - offset >= vlength"`, all the
> lanes of the generated mask are true. Note that `"vlength"` is
> the number of vector lanes.
> 
> For such special cases, we can simply use `"maskAll(false|true)"`
> to implement the API. Otherwise, the original comparison with
> `"iota" `vector is needed. And for further optimization, we have
> optimal instruction supported by SVE (i.e. whilelo [1]), which
> can implement the API directly if the `"offset >= 0"`.
> 
> As a summary, to optimize the API, we can use the if-else branches
> to handle the specific cases in java level and intrinsify the
> remaining case by C2 compiler:
> 
> 
>   public VectorMask<E> indexInRange(int offset, int limit) {
>       if (offset < 0) {
>           return this.and(indexInRange0Helper(offset, limit));
>       } else if (offset >= limit) {
>           return this.and(vectorSpecies().maskAll(false));
>       } else if (limit - offset >= length()) {
>           return this.and(vectorSpecies().maskAll(true));
>       }
>       return this.and(indexInRange0(offset, limit));
>  }
> 
> 
> The last part (i.e. `"indexInRange0"`) in the above implementation
> is expected to be intrinsified by C2 compiler if the necessary IRs
> are supported. Otherwise, it will fall back to the original API
> implementation (i.e. `"indexInRange0Helper"`). Regarding to the
> intrinsifaction, the compiler will generate `"VectorMaskGen"` IR
> with "limit - offset" as the input if the current platform supports
> it. Otherwise, it generates `"VectorLoadConst + VectorMaskCmp"` based
> on `"iota < limit - offset"`.
> 
> For the following java code which uses `"indexInRange"`:
> 
> 
> static final VectorSpecies<Double> SPECIES =
>                                    DoubleVector.SPECIES_PREFERRED;
> static final int LENGTH = 1027;
> 
> public static double[] da;
> public static double[] db;
> public static double[] dc;
> 
> private static void func() {
>     for (int i = 0; i < LENGTH; i += SPECIES.length()) {
>         var m = SPECIES.indexInRange(i, LENGTH);
>         var av = DoubleVector.fromArray(SPECIES, da, i, m);
>         av.lanewise(VectorOperators.NEG).intoArray(dc, i, m);
>     }
> }
> 
> 
> The core code generated with SVE 256-bit vector size is:
> 
> 
>   ptrue   p2.d                  ; maskAll(true)
>   ...
> LOOP:
>   ...
>   sub     w11, w13, w14         ; limit - offset
>   cmp     w14, w13
>   b.cs    LABEL-1               ; if (offset >= limit) => uncommon-trap
>   cmp     w11, #0x4
>   b.lt    LABEL-2               ; if (limit - offset < vlength)
>   mov     p1.b, p2.b
> LABEL-3:
>   ld1d    {z16.d}, p1/z, [x10]  ; load vector masked
>   ...
>   cmp     w14, w29
>   b.cc    LOOP
>   ...
> LABEL-2:
>   whilelo p1.d, x16, x10        ; VectorMaskGen
>   ...
>   b       LABEL-3
>   ...
> LABEL-1:
>   uncommon-trap
> 
> 
> Please note that if the array size `LENGTH` is aligned with
> the vector size 256 (i.e. `LENGTH = 1024`), the branch "LABEL-2"
> will be optimized out by compiler and it becomes another
> uncommon-trap.
> 
> For NEON, the main CFG is the same with above. But the compiler
> intrinsification is different. Here is the code:
> 
> 
>   sub     x10, x10, x12          ; limit - offset
>   scvtf   d16, x10
>   dup     v16.2d, v16.d[0]       ; replicateD
> 
>   mov     x8, #0xd8d0
>   movk    x8, #0x84cb, lsl #16
>   movk    x8, #0xffff, lsl #32
>   ldr     q17, [x8], #0          ; load the "iota" const vector
>   fcmgt   v18.2d, v16.2d, v17.2d ; mask = iota < limit - offset
> 
> 
> Here is the performance data of the new added benchmark on an ARM
> SVE 256-bit platform:
> 
> 
> Benchmark                               (size)  Before    After   Units
> IndexInRangeBenchmark.byteIndexInRange   1024 11203.697 41404.431 ops/ms
> IndexInRangeBenchmark.byteIndexInRange   1027  2365.920  8747.004 ops/ms
> IndexInRangeBenchmark.doubleIndexInRange 1024  1227.505  6092.194 ops/ms
> IndexInRangeBenchmark.doubleIndexInRange 1027   351.215  1156.683 ops/ms
> IndexInRangeBenchmark.floatIndexInRange  1024  1468.876 11032.580 ops/ms
> IndexInRangeBenchmark.floatIndexInRange  1027   699.645  2439.671 ops/ms
> IndexInRangeBenchmark.intIndexInRange    1024  2842.187 11903.544 ops/ms
> IndexInRangeBenchmark.intIndexInRange    1027   689.866  2547.424 ops/ms
> IndexInRangeBenchmark.longIndexInRange   1024  1394.135  5902.973 ops/ms
> IndexInRangeBenchmark.longIndexInRange   1027   355.621  1189.458 ops/ms
> IndexInRangeBenchmark.shortIndexInRange  1024  5521.468 21578.340 ops/ms
> IndexInRangeBenchmark.shortIndexInRange  1027  1264.816  4640.504 ops/ms
> 
> 
> And the performance data with ARM NEON:
> 
> 
> Benchmark                               (size)  Before    After   Units
> IndexInRangeBenchmark.byteIndexInRange   1024  4026.548 15562.880 ops/ms
> IndexInRangeBenchmark.byteIndexInRange   1027   305.314   576.559 ops/ms
> IndexInRangeBenchmark.doubleIndexInRange 1024   289.224  2244.080 ops/ms
> IndexInRangeBenchmark.doubleIndexInRange 1027    39.740    76.499 ops/ms
> IndexInRangeBenchmark.floatIndexInRange  1024   675.264  4457.470 ops/ms
> IndexInRangeBenchmark.floatIndexInRange  1027    79.918   144.952 ops/ms
> IndexInRangeBenchmark.intIndexInRange    1024   740.139  4014.583 ops/ms
> IndexInRangeBenchmark.intIndexInRange    1027    78.608   147.903 ops/ms
> IndexInRangeBenchmark.longIndexInRange   1024   400.683  2209.551 ops/ms
> IndexInRangeBenchmark.longIndexInRange   1027    41.146    69.599 ops/ms
> IndexInRangeBenchmark.shortIndexInRange  1024  1821.736  8153.546 ops/ms
> IndexInRangeBenchmark.shortIndexInRange  1027   158.810   243.205 ops/ms
> 
> 
> The performance improves about `3.5x ~ 7.5x` on the vector size aligned
> (1024 size) benchmarks both with NEON and SVE. And it improves about
> `3.5x/1.8x` on the vector size not aligned (1027 size) benchmarks with
> SVE/NEON respectively. We can also observe the similar improvement on
> the x86 platforms.
> 
> [1] https://developer.arm.com/documentation/ddi0596/2020-12/SVE-Instructions/WHILELO--While-incrementing-unsigned-scalar-lower-than-scalar-

> 

Thanks for the suggestion! Totally agree with you that the tail loop is better to be separated from the main vector loop. Adding smaller value in the ` "@Param" ` set for `size` can match what you mean. I will run the performance with smaller size. Thanks!

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

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

From duke at openjdk.org  Fri Feb  3 04:00:28 2023
From: duke at openjdk.org (SUN Guoyun)
Date: Fri, 3 Feb 2023 04:00:28 GMT
Subject: RFR: 8301737:
 java/rmi/server/UnicastRemoteObject/serialFilter/FilterUROTest.java fail with
 -Xcomp
Message-ID: <l5m5_9io2QMSFNY7dBHT3Nr2I9Er8wmd92Ze8FP-XE0=.a40d29be-77be-4719-a0a0-71d032eea1e5@github.com>

Hi all,
When -Xcomp be used, java thread to block for longer, then causing this test failed frequently on the AArch64 and LoongArch64 architecture.

This PR fix the issue, Please help review it.

Thanks.

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

Commit messages:
 - 8301737: java/rmi/server/UnicastRemoteObject/serialFilter/FilterUROTest.java fail with -Xcomp

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

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

From aturbanov at openjdk.org  Fri Feb  3 07:07:59 2023
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Fri, 3 Feb 2023 07:07:59 GMT
Subject: RFR: JDK-8301396: Port fdlibm expm1 to Java
In-Reply-To: <U3Jo6dH5rPBRmSVceetCxwisBbTPlaHshGCP2zL9kD0=.1d76ebf0-e729-4066-b9b6-46e06b350eb3@github.com>
References: <U3Jo6dH5rPBRmSVceetCxwisBbTPlaHshGCP2zL9kD0=.1d76ebf0-e729-4066-b9b6-46e06b350eb3@github.com>
Message-ID: <_DYpJjykAbt3J79RdcCo1px6D7XJY5fdx5f_s9B_gZc=.ad78f65d-8f87-43c2-a301-6401391116d3@github.com>

On Thu, 2 Feb 2023 22:18:32 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Next on the FDLIBM C -> Java port, expm1.
> Coming soon, hyperbolic transcendentals (sinh, cosh, tanh)!
> 
> For expm1, the C vs transliteration port show the usual kind of differences, beside formatting of the constants, the use of the __HI macro on the left-hand side needs to be replaced by a method call and an assignment, as seen below:
> 
> 
> < 
> < #include "fdlibm.h"
> < 
> < #ifdef __STDC__
> < static const double
> < #else
> < static double
> < #endif
> < one             = 1.0,
> < huge            = 1.0e+300,
> < tiny            = 1.0e-300,
> < o_threshold     = 7.09782712893383973096e+02,/* 0x40862E42, 0xFEFA39EF */
> < ln2_hi          = 6.93147180369123816490e-01,/* 0x3fe62e42, 0xfee00000 */
> < ln2_lo          = 1.90821492927058770002e-10,/* 0x3dea39ef, 0x35793c76 */
> < invln2          = 1.44269504088896338700e+00,/* 0x3ff71547, 0x652b82fe */
> ---
>>     static class Expm1 {
>>         private static final double one             = 1.0;
>>         private static final double huge            = 1.0e+300;
>>         private static final double tiny            = 1.0e-300;
>>         private static final double o_threshold     = 7.09782712893383973096e+02; /* 0x40862E42, 0xFEFA39EF */
>>         private static final double ln2_hi          = 6.93147180369123816490e-01; /* 0x3fe62e42, 0xfee00000 */
>>         private static final double ln2_lo          = 1.90821492927058770002e-10; /* 0x3dea39ef, 0x35793c76 */
>>         private static final double invln2          = 1.44269504088896338700e+00; /* 0x3ff71547, 0x652b82fe */
> 111,115c104,108
> < Q1  =  -3.33333333333331316428e-02, /* BFA11111 111110F4 */
> < Q2  =   1.58730158725481460165e-03, /* 3F5A01A0 19FE5585 */
> < Q3  =  -7.93650757867487942473e-05, /* BF14CE19 9EAADBB7 */
> < Q4  =   4.00821782732936239552e-06, /* 3ED0CFCA 86E65239 */
> < Q5  =  -2.01099218183624371326e-07; /* BE8AFDB7 6E09C32D */
> ---
>>         private static final double Q1  =  -3.33333333333331316428e-02; /* BFA11111 111110F4 */
>>         private static final double Q2  =   1.58730158725481460165e-03; /* 3F5A01A0 19FE5585 */
>>         private static final double Q3  =  -7.93650757867487942473e-05; /* BF14CE19 9EAADBB7 */
>>         private static final double Q4  =   4.00821782732936239552e-06; /* 3ED0CFCA 86E65239 */
>>         private static final double Q5  =  -2.01099218183624371326e-07; /* BE8AFDB7 6E09C32D */
> 117,123c110
> < #ifdef __STDC__
> <         double expm1(double x)
> < #else
> <         double expm1(x)
> <         double x;
> < #endif
> < {
> ---
>>         static double compute(double x) {
> 126c113
> <         unsigned hx;
> ---
>>             /*unsigned*/ int hx;
> 157c144
> <                 k  = invln2*x+((xsb==0)?0.5:-0.5);
> ---
>>                     k  = (int)(invln2*x+((xsb==0)?0.5:-0.5));
> 188c175
> <                 __HI(y) += (k<<20);     /* add k to y's exponent */
> ---
>>                     y = __HI(y,  __HI(y) + (k<<20));     /* add k to y's exponent */
> 193c180
> <                 __HI(t) = 0x3ff00000 - (0x200000>>k);  /* t=1-2^-k */
> ---
>>                     t = __HI(t, 0x3ff00000 - (0x200000>>k));  /* t=1-2^-k */
> 195c182
> <                 __HI(y) += (k<<20);     /* add k to y's exponent */
> ---
>>                     y = __HI(y, __HI(y) + (k<<20));     /* add k to y's exponent */
> 197c184
> <                 __HI(t)  = ((0x3ff-k)<<20);     /* 2^-k */
> ---
>>                     t = __HI(t, ((0x3ff-k)<<20));     /* 2^-k */
> 200c187
> <                 __HI(y) += (k<<20);     /* add k to y's exponent */
> ---
>>                     y = __HI(y, __HI(y) + (k<<20));     /* add k to y's exponent */
> 205c192
> < 
> ---
>>     }
> 
> 
> When comparing the transliteration port and the more idiomatic port, there were no surprising or notable differences:
> 
> 
> $ diff -w Expm1.translit.java Expm1.fdlibm.java  
> 99,102c99,102
> <         private static final double o_threshold     = 7.09782712893383973096e+02; /* 0x40862E42, 0xFEFA39EF */
> <         private static final double ln2_hi          = 6.93147180369123816490e-01; /* 0x3fe62e42, 0xfee00000 */
> <         private static final double ln2_lo          = 1.90821492927058770002e-10; /* 0x3dea39ef, 0x35793c76 */
> <         private static final double invln2          = 1.44269504088896338700e+00; /* 0x3ff71547, 0x652b82fe */
> ---
>>         private static final double o_threshold =  0x1.62e42fefa39efp9;   //  7.09782712893383973096e+02
>>         private static final double ln2_hi      =  0x1.62e42feep-1;       //  6.93147180369123816490e-01
>>         private static final double ln2_lo      =  0x1.a39ef35793c76p-33; //  1.90821492927058770002e-10
>>         private static final double invln2      =  0x1.71547652b82fep0;   //  1.44269504088896338700e+00
> 104,108c104,108
> <         private static final double Q1  =  -3.33333333333331316428e-02; /* BFA11111 111110F4 */
> <         private static final double Q2  =   1.58730158725481460165e-03; /* 3F5A01A0 19FE5585 */
> <         private static final double Q3  =  -7.93650757867487942473e-05; /* BF14CE19 9EAADBB7 */
> <         private static final double Q4  =   4.00821782732936239552e-06; /* 3ED0CFCA 86E65239 */
> <         private static final double Q5  =  -2.01099218183624371326e-07; /* BE8AFDB7 6E09C32D */
> ---
>>         private static final double Q1          = -0x1.11111111110f4p-5;  // -3.33333333333331316428e-02
>>         private static final double Q2          =  0x1.a01a019fe5585p-10; //  1.58730158725481460165e-03
>>         private static final double Q3          = -0x1.4ce199eaadbb7p-14; // -7.93650757867487942473e-05
>>         private static final double Q4          =  0x1.0cfca86e65239p-18; //  4.00821782732936239552e-06
>>         private static final double Q5          = -0x1.afdb76e09c32dp-23; // -2.01099218183624371326e-07
> 116,118c116,118
> <             xsb = hx&0x80000000;            /* sign bit of x */
> <             if(xsb==0) y=x; else y= -x;     /* y = |x| */
> <             hx &= 0x7fffffff;               /* high word of |x| */
> ---
>>             xsb = hx & 0x8000_0000;            /* sign bit of x */
>>             y = Math.abs(x);
>>             hx &= 0x7fff_ffff;               /* high word of |x| */
> 121,124c121,124
> <             if(hx >= 0x4043687A) {                  /* if |x|>=56*ln2 */
> <                 if(hx >= 0x40862E42) {              /* if |x|>=709.78... */
> <                     if(hx>=0x7ff00000) {
> <                         if(((hx&0xfffff)|__LO(x))!=0)
> ---
>>             if (hx >= 0x4043_687A) {                  /* if |x| >= 56*ln2 */
>>                 if (hx >= 0x4086_2E42) {              /* if |x| >= 709.78... */
>>                     if (hx >= 0x7ff_00000) {
>>                         if (((hx & 0xf_ffff) | __LO(x)) != 0) {
> 126c126,131
> <                         else return (xsb==0)? x:-1.0;/* exp(+-inf)={inf,-1} */
> ---
>>                         } else {
>>                             return (xsb == 0)? x : -1.0; /* exp(+-inf)={inf,-1} */
>>                         }
>>                     }
>>                     if (x > o_threshold) {
>>                         return huge*huge; /* overflow */
> 128d132
> <                     if(x > o_threshold) return huge*huge; /* overflow */
> 131c135
> <                     if(x+tiny<0.0)          /* raise inexact */
> ---
>>                     if (x + tiny < 0.0) {         /* raise inexact */
> 134a139
>>             }
> 137,142c142,152
> <             if(hx > 0x3fd62e42) {           /* if  |x| > 0.5 ln2 */
> <                 if(hx < 0x3FF0A2B2) {       /* and |x| < 1.5 ln2 */
> <                     if(xsb==0)
> <                         {hi = x - ln2_hi; lo =  ln2_lo;  k =  1;}
> <                     else
> <                         {hi = x + ln2_hi; lo = -ln2_lo;  k = -1;}
> ---
>>             if (hx > 0x3fd6_2e42) {           /* if  |x| > 0.5 ln2 */
>>                 if (hx < 0x3FF0_A2B2) {       /* and |x| < 1.5 ln2 */
>>                     if (xsb == 0) {
>>                         hi = x - ln2_hi;
>>                         lo =  ln2_lo;
>>                         k =  1;}
>>                     else {
>>                         hi = x + ln2_hi;
>>                         lo = -ln2_lo;
>>                         k = -1;
>>                     }
> 151,152c161
> <             }
> <             else if(hx < 0x3c900000) {      /* when |x|<2**-54, return x */
> ---
>>             } else if (hx < 0x3c90_0000) {      /* when |x|<2**-54, return x */
> 154a164,165
>>             } else {
>>                 k = 0;
> 156d166
> <             else k = 0;
> 164,165c174,176
> <             if(k==0) return x - (x*e-hxs);          /* c is 0 */
> <             else {
> ---
>>             if (k == 0) {
>>                 return x - (x*e - hxs);          /* c is 0 */
>>             } else {
> 168c179,181
> <                 if(k== -1) return 0.5*(x-e)-0.5;
> ---
>>                 if (k == -1) {
>>                     return 0.5*(x - e) - 0.5;
>>                 }
> 170,171c183,187
> <                     if(x < -0.25) return -2.0*(e-(x+0.5));
> <                     else          return  one+2.0*(x-e);
> ---
>>                     if(x < -0.25) {
>>                         return -2.0*(e - (x + 0.5));
>>                     } else {
>>                         return  one + 2.0*(x - e);
>>                     }
> 180c196
> <                     t = __HI(t, 0x3ff00000 - (0x200000>>k));  /* t=1-2^-k */
> ---
>>                     t = __HI(t, 0x3ff0_0000 - (0x2_00000 >> k));  /* t=1-2^-k */

src/java.base/share/classes/java/lang/FdLibm.java line 1084:

> 1082:      */
> 1083:     static class Expm1 {
> 1084:         private static final double one         =  1.0;

Not sure if it's worth to have constant field for such primitive value.

src/java.base/share/classes/java/lang/FdLibm.java line 1105:

> 1103:             hx  = __HI(x);  /* high word of x */
> 1104:             xsb = hx & 0x8000_0000;            /* sign bit of x */
> 1105:             y = Math.abs(x);

let's align this variable too
Suggestion:

            y   = Math.abs(x);

src/java.base/share/classes/java/lang/FdLibm.java line 1134:

> 1132:                     if (xsb == 0) {
> 1133:                         hi = x - ln2_hi;
> 1134:                         lo =  ln2_lo;

Suggestion:

                        lo = ln2_lo;

src/java.base/share/classes/java/lang/FdLibm.java line 1135:

> 1133:                         hi = x - ln2_hi;
> 1134:                         lo =  ln2_lo;
> 1135:                         k =  1;}

Suggestion:

                        k =  1;
                    }

src/java.base/share/classes/java/lang/FdLibm.java line 1147:

> 1145:                     lo = t*ln2_lo;
> 1146:                 }
> 1147:                 x  = hi - lo;

Suggestion:

                x = hi - lo;

src/java.base/share/classes/java/lang/FdLibm.java line 1171:

> 1169:                 }
> 1170:                 if (k == 1) {
> 1171:                     if(x < -0.25) {

Suggestion:

                    if (x < -0.25) {

src/java.base/share/classes/java/lang/FdLibm.java line 1174:

> 1172:                         return -2.0*(e - (x + 0.5));
> 1173:                     } else {
> 1174:                         return  one + 2.0*(x - e);

Suggestion:

                        return one + 2.0*(x - e);

test/jdk/java/lang/StrictMath/Expm1Tests.java line 80:

> 78: 
> 79:         // ... and just below subnormal threshold ...
> 80:          x =  Math.nextDown(Double.MIN_NORMAL);

Suggestion:

         x = Math.nextDown(Double.MIN_NORMAL);

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

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

From xgong at openjdk.org  Fri Feb  3 07:13:10 2023
From: xgong at openjdk.org (Xiaohong Gong)
Date: Fri, 3 Feb 2023 07:13:10 GMT
Subject: RFR: 8293198: [vectorapi] Improve the implementation of
 VectorMask.indexInRange() [v2]
In-Reply-To: <fN58bi3n01tqWpG0-jjUPZQe8hmls2GQ5X3NL2o1RPg=.80e7965d-50af-4fac-bd7c-0a2b99cffe7e@github.com>
References: <fN58bi3n01tqWpG0-jjUPZQe8hmls2GQ5X3NL2o1RPg=.80e7965d-50af-4fac-bd7c-0a2b99cffe7e@github.com>
Message-ID: <0dNCRVASsdME6qS79u5z7c6mikJs1jfucfo54lo71ik=.d8c2dc6e-bc60-499f-899c-880a2219b052@github.com>

> The Vector API `"indexInRange(int offset, int limit)"` is used
> to compute a vector mask whose lanes are set to true if the
> index of the lane is inside the range specified by the `"offset"`
> and `"limit"` arguments, otherwise the lanes are set to false.
> 
> There are two special cases for this API:
>  1) If `"offset >= 0 && offset >= limit"`, all the lanes of the
> generated mask are false.
>  2) If` "offset >= 0 && limit - offset >= vlength"`, all the
> lanes of the generated mask are true. Note that `"vlength"` is
> the number of vector lanes.
> 
> For such special cases, we can simply use `"maskAll(false|true)"`
> to implement the API. Otherwise, the original comparison with
> `"iota" `vector is needed. And for further optimization, we have
> optimal instruction supported by SVE (i.e. whilelo [1]), which
> can implement the API directly if the `"offset >= 0"`.
> 
> As a summary, to optimize the API, we can use the if-else branches
> to handle the specific cases in java level and intrinsify the
> remaining case by C2 compiler:
> 
> 
>   public VectorMask<E> indexInRange(int offset, int limit) {
>       if (offset < 0) {
>           return this.and(indexInRange0Helper(offset, limit));
>       } else if (offset >= limit) {
>           return this.and(vectorSpecies().maskAll(false));
>       } else if (limit - offset >= length()) {
>           return this.and(vectorSpecies().maskAll(true));
>       }
>       return this.and(indexInRange0(offset, limit));
>  }
> 
> 
> The last part (i.e. `"indexInRange0"`) in the above implementation
> is expected to be intrinsified by C2 compiler if the necessary IRs
> are supported. Otherwise, it will fall back to the original API
> implementation (i.e. `"indexInRange0Helper"`). Regarding to the
> intrinsifaction, the compiler will generate `"VectorMaskGen"` IR
> with "limit - offset" as the input if the current platform supports
> it. Otherwise, it generates `"VectorLoadConst + VectorMaskCmp"` based
> on `"iota < limit - offset"`.
> 
> For the following java code which uses `"indexInRange"`:
> 
> 
> static final VectorSpecies<Double> SPECIES =
>                                    DoubleVector.SPECIES_PREFERRED;
> static final int LENGTH = 1027;
> 
> public static double[] da;
> public static double[] db;
> public static double[] dc;
> 
> private static void func() {
>     for (int i = 0; i < LENGTH; i += SPECIES.length()) {
>         var m = SPECIES.indexInRange(i, LENGTH);
>         var av = DoubleVector.fromArray(SPECIES, da, i, m);
>         av.lanewise(VectorOperators.NEG).intoArray(dc, i, m);
>     }
> }
> 
> 
> The core code generated with SVE 256-bit vector size is:
> 
> 
>   ptrue   p2.d                  ; maskAll(true)
>   ...
> LOOP:
>   ...
>   sub     w11, w13, w14         ; limit - offset
>   cmp     w14, w13
>   b.cs    LABEL-1               ; if (offset >= limit) => uncommon-trap
>   cmp     w11, #0x4
>   b.lt    LABEL-2               ; if (limit - offset < vlength)
>   mov     p1.b, p2.b
> LABEL-3:
>   ld1d    {z16.d}, p1/z, [x10]  ; load vector masked
>   ...
>   cmp     w14, w29
>   b.cc    LOOP
>   ...
> LABEL-2:
>   whilelo p1.d, x16, x10        ; VectorMaskGen
>   ...
>   b       LABEL-3
>   ...
> LABEL-1:
>   uncommon-trap
> 
> 
> Please note that if the array size `LENGTH` is aligned with
> the vector size 256 (i.e. `LENGTH = 1024`), the branch "LABEL-2"
> will be optimized out by compiler and it becomes another
> uncommon-trap.
> 
> For NEON, the main CFG is the same with above. But the compiler
> intrinsification is different. Here is the code:
> 
> 
>   sub     x10, x10, x12          ; limit - offset
>   scvtf   d16, x10
>   dup     v16.2d, v16.d[0]       ; replicateD
> 
>   mov     x8, #0xd8d0
>   movk    x8, #0x84cb, lsl #16
>   movk    x8, #0xffff, lsl #32
>   ldr     q17, [x8], #0          ; load the "iota" const vector
>   fcmgt   v18.2d, v16.2d, v17.2d ; mask = iota < limit - offset
> 
> 
> Here is the performance data of the new added benchmark on an ARM
> SVE 256-bit platform:
> 
> 
> Benchmark                               (size)  Before    After   Units
> IndexInRangeBenchmark.byteIndexInRange   1024 11203.697 41404.431 ops/ms
> IndexInRangeBenchmark.byteIndexInRange   1027  2365.920  8747.004 ops/ms
> IndexInRangeBenchmark.doubleIndexInRange 1024  1227.505  6092.194 ops/ms
> IndexInRangeBenchmark.doubleIndexInRange 1027   351.215  1156.683 ops/ms
> IndexInRangeBenchmark.floatIndexInRange  1024  1468.876 11032.580 ops/ms
> IndexInRangeBenchmark.floatIndexInRange  1027   699.645  2439.671 ops/ms
> IndexInRangeBenchmark.intIndexInRange    1024  2842.187 11903.544 ops/ms
> IndexInRangeBenchmark.intIndexInRange    1027   689.866  2547.424 ops/ms
> IndexInRangeBenchmark.longIndexInRange   1024  1394.135  5902.973 ops/ms
> IndexInRangeBenchmark.longIndexInRange   1027   355.621  1189.458 ops/ms
> IndexInRangeBenchmark.shortIndexInRange  1024  5521.468 21578.340 ops/ms
> IndexInRangeBenchmark.shortIndexInRange  1027  1264.816  4640.504 ops/ms
> 
> 
> And the performance data with ARM NEON:
> 
> 
> Benchmark                               (size)  Before    After   Units
> IndexInRangeBenchmark.byteIndexInRange   1024  4026.548 15562.880 ops/ms
> IndexInRangeBenchmark.byteIndexInRange   1027   305.314   576.559 ops/ms
> IndexInRangeBenchmark.doubleIndexInRange 1024   289.224  2244.080 ops/ms
> IndexInRangeBenchmark.doubleIndexInRange 1027    39.740    76.499 ops/ms
> IndexInRangeBenchmark.floatIndexInRange  1024   675.264  4457.470 ops/ms
> IndexInRangeBenchmark.floatIndexInRange  1027    79.918   144.952 ops/ms
> IndexInRangeBenchmark.intIndexInRange    1024   740.139  4014.583 ops/ms
> IndexInRangeBenchmark.intIndexInRange    1027    78.608   147.903 ops/ms
> IndexInRangeBenchmark.longIndexInRange   1024   400.683  2209.551 ops/ms
> IndexInRangeBenchmark.longIndexInRange   1027    41.146    69.599 ops/ms
> IndexInRangeBenchmark.shortIndexInRange  1024  1821.736  8153.546 ops/ms
> IndexInRangeBenchmark.shortIndexInRange  1027   158.810   243.205 ops/ms
> 
> 
> The performance improves about `3.5x ~ 7.5x` on the vector size aligned
> (1024 size) benchmarks both with NEON and SVE. And it improves about
> `3.5x/1.8x` on the vector size not aligned (1027 size) benchmarks with
> SVE/NEON respectively. We can also observe the similar improvement on
> the x86 platforms.
> 
> [1] https://developer.arm.com/documentation/ddi0596/2020-12/SVE-Instructions/WHILELO--While-incrementing-unsigned-scalar-lower-than-scalar-

Xiaohong Gong has updated the pull request incrementally with one additional commit since the last revision:

  Add smaller array size for benchmark tests

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12064/files
  - new: https://git.openjdk.org/jdk/pull/12064/files/6f7c30be..9388e29d

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

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

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

From xgong at openjdk.org  Fri Feb  3 07:25:49 2023
From: xgong at openjdk.org (Xiaohong Gong)
Date: Fri, 3 Feb 2023 07:25:49 GMT
Subject: RFR: 8293198: [vectorapi] Improve the implementation of
 VectorMask.indexInRange()
In-Reply-To: <8_PwnvpT11s1fv0Mwhrh0ON6ECgsfDy249m0tl4_d2A=.284697c6-b3dc-429c-bf7c-06d6c41d47b2@github.com>
References: <fN58bi3n01tqWpG0-jjUPZQe8hmls2GQ5X3NL2o1RPg=.80e7965d-50af-4fac-bd7c-0a2b99cffe7e@github.com>
 <8_PwnvpT11s1fv0Mwhrh0ON6ECgsfDy249m0tl4_d2A=.284697c6-b3dc-429c-bf7c-06d6c41d47b2@github.com>
Message-ID: <yDxv39yPjDUHA754-PiCFFfNqRE5E10H0pFPjYVoG9Y=.727fc4bb-f22a-4800-9e71-66f8e0fa1b17@github.com>

On Fri, 3 Feb 2023 02:54:32 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

>> The Vector API `"indexInRange(int offset, int limit)"` is used
>> to compute a vector mask whose lanes are set to true if the
>> index of the lane is inside the range specified by the `"offset"`
>> and `"limit"` arguments, otherwise the lanes are set to false.
>> 
>> There are two special cases for this API:
>>  1) If `"offset >= 0 && offset >= limit"`, all the lanes of the
>> generated mask are false.
>>  2) If` "offset >= 0 && limit - offset >= vlength"`, all the
>> lanes of the generated mask are true. Note that `"vlength"` is
>> the number of vector lanes.
>> 
>> For such special cases, we can simply use `"maskAll(false|true)"`
>> to implement the API. Otherwise, the original comparison with
>> `"iota" `vector is needed. And for further optimization, we have
>> optimal instruction supported by SVE (i.e. whilelo [1]), which
>> can implement the API directly if the `"offset >= 0"`.
>> 
>> As a summary, to optimize the API, we can use the if-else branches
>> to handle the specific cases in java level and intrinsify the
>> remaining case by C2 compiler:
>> 
>> 
>>   public VectorMask<E> indexInRange(int offset, int limit) {
>>       if (offset < 0) {
>>           return this.and(indexInRange0Helper(offset, limit));
>>       } else if (offset >= limit) {
>>           return this.and(vectorSpecies().maskAll(false));
>>       } else if (limit - offset >= length()) {
>>           return this.and(vectorSpecies().maskAll(true));
>>       }
>>       return this.and(indexInRange0(offset, limit));
>>  }
>> 
>> 
>> The last part (i.e. `"indexInRange0"`) in the above implementation
>> is expected to be intrinsified by C2 compiler if the necessary IRs
>> are supported. Otherwise, it will fall back to the original API
>> implementation (i.e. `"indexInRange0Helper"`). Regarding to the
>> intrinsifaction, the compiler will generate `"VectorMaskGen"` IR
>> with "limit - offset" as the input if the current platform supports
>> it. Otherwise, it generates `"VectorLoadConst + VectorMaskCmp"` based
>> on `"iota < limit - offset"`.
>> 
>> For the following java code which uses `"indexInRange"`:
>> 
>> 
>> static final VectorSpecies<Double> SPECIES =
>>                                    DoubleVector.SPECIES_PREFERRED;
>> static final int LENGTH = 1027;
>> 
>> public static double[] da;
>> public static double[] db;
>> public static double[] dc;
>> 
>> private static void func() {
>>     for (int i = 0; i < LENGTH; i += SPECIES.length()) {
>>         var m = SPECIES.indexInRange(i, LENGTH);
>>         var av = DoubleVector.fromArray(SPECIES, da, i, m);
>>         av.lanewise(VectorOperators.NEG).intoArray(dc, i, m);
>>     }
>> }
>> 
>> 
>> The core code generated with SVE 256-bit vector size is:
>> 
>> 
>>   ptrue   p2.d                  ; maskAll(true)
>>   ...
>> LOOP:
>>   ...
>>   sub     w11, w13, w14         ; limit - offset
>>   cmp     w14, w13
>>   b.cs    LABEL-1               ; if (offset >= limit) => uncommon-trap
>>   cmp     w11, #0x4
>>   b.lt    LABEL-2               ; if (limit - offset < vlength)
>>   mov     p1.b, p2.b
>> LABEL-3:
>>   ld1d    {z16.d}, p1/z, [x10]  ; load vector masked
>>   ...
>>   cmp     w14, w29
>>   b.cc    LOOP
>>   ...
>> LABEL-2:
>>   whilelo p1.d, x16, x10        ; VectorMaskGen
>>   ...
>>   b       LABEL-3
>>   ...
>> LABEL-1:
>>   uncommon-trap
>> 
>> 
>> Please note that if the array size `LENGTH` is aligned with
>> the vector size 256 (i.e. `LENGTH = 1024`), the branch "LABEL-2"
>> will be optimized out by compiler and it becomes another
>> uncommon-trap.
>> 
>> For NEON, the main CFG is the same with above. But the compiler
>> intrinsification is different. Here is the code:
>> 
>> 
>>   sub     x10, x10, x12          ; limit - offset
>>   scvtf   d16, x10
>>   dup     v16.2d, v16.d[0]       ; replicateD
>> 
>>   mov     x8, #0xd8d0
>>   movk    x8, #0x84cb, lsl #16
>>   movk    x8, #0xffff, lsl #32
>>   ldr     q17, [x8], #0          ; load the "iota" const vector
>>   fcmgt   v18.2d, v16.2d, v17.2d ; mask = iota < limit - offset
>> 
>> 
>> Here is the performance data of the new added benchmark on an ARM
>> SVE 256-bit platform:
>> 
>> 
>> Benchmark                               (size)  Before    After   Units
>> IndexInRangeBenchmark.byteIndexInRange   1024 11203.697 41404.431 ops/ms
>> IndexInRangeBenchmark.byteIndexInRange   1027  2365.920  8747.004 ops/ms
>> IndexInRangeBenchmark.doubleIndexInRange 1024  1227.505  6092.194 ops/ms
>> IndexInRangeBenchmark.doubleIndexInRange 1027   351.215  1156.683 ops/ms
>> IndexInRangeBenchmark.floatIndexInRange  1024  1468.876 11032.580 ops/ms
>> IndexInRangeBenchmark.floatIndexInRange  1027   699.645  2439.671 ops/ms
>> IndexInRangeBenchmark.intIndexInRange    1024  2842.187 11903.544 ops/ms
>> IndexInRangeBenchmark.intIndexInRange    1027   689.866  2547.424 ops/ms
>> IndexInRangeBenchmark.longIndexInRange   1024  1394.135  5902.973 ops/ms
>> IndexInRangeBenchmark.longIndexInRange   1027   355.621  1189.458 ops/ms
>> IndexInRangeBenchmark.shortIndexInRange  1024  5521.468 21578.340 ops/ms
>> IndexInRangeBenchmark.shortIndexInRange  1027  1264.816  4640.504 ops/ms
>> 
>> 
>> And the performance data with ARM NEON:
>> 
>> 
>> Benchmark                               (size)  Before    After   Units
>> IndexInRangeBenchmark.byteIndexInRange   1024  4026.548 15562.880 ops/ms
>> IndexInRangeBenchmark.byteIndexInRange   1027   305.314   576.559 ops/ms
>> IndexInRangeBenchmark.doubleIndexInRange 1024   289.224  2244.080 ops/ms
>> IndexInRangeBenchmark.doubleIndexInRange 1027    39.740    76.499 ops/ms
>> IndexInRangeBenchmark.floatIndexInRange  1024   675.264  4457.470 ops/ms
>> IndexInRangeBenchmark.floatIndexInRange  1027    79.918   144.952 ops/ms
>> IndexInRangeBenchmark.intIndexInRange    1024   740.139  4014.583 ops/ms
>> IndexInRangeBenchmark.intIndexInRange    1027    78.608   147.903 ops/ms
>> IndexInRangeBenchmark.longIndexInRange   1024   400.683  2209.551 ops/ms
>> IndexInRangeBenchmark.longIndexInRange   1027    41.146    69.599 ops/ms
>> IndexInRangeBenchmark.shortIndexInRange  1024  1821.736  8153.546 ops/ms
>> IndexInRangeBenchmark.shortIndexInRange  1027   158.810   243.205 ops/ms
>> 
>> 
>> The performance improves about `3.5x ~ 7.5x` on the vector size aligned
>> (1024 size) benchmarks both with NEON and SVE. And it improves about
>> `3.5x/1.8x` on the vector size not aligned (1027 size) benchmarks with
>> SVE/NEON respectively. We can also observe the similar improvement on
>> the x86 platforms.
>> 
>> [1] https://developer.arm.com/documentation/ddi0596/2020-12/SVE-Instructions/WHILELO--While-incrementing-unsigned-scalar-lower-than-scalar-
>
> Can you add benchmarks which perform `indexInRange` on really short arrays, such as with size smaller than that of the vectors.
> 
>     var m = ispecies.indexInRange(0, size);
>     IntVector.fromArray(ispecies, intIn, 0, m).intoArray(intOut, 0, m);
> 
> For longer arrays, I think this code shape is not much more verbose and might perform better:
> 
>     int bound = ispecies.loopBound(size);
>     for (int i = 0; i < bound; i += ispecies.length()) {
>         IntVector.fromArray(ispecies, intIn, i).intoArray(intOut, i);
>     }
>     var m = ispecies.indexInRange(bound, size);
>     IntVector.fromArray(ispecies, intIn, bound, m).intoArray(intOut, bound, m);
> 
> Thanks.

Hi @merykitty ,

I added a smaller array size (i.e. 7) in the benchmark tests. And to make the test size gap not so large, I changed the original 1027 to 259. 

Following is the benchmark result compared with the jdk mainline, ran on a SVE 512-bit vector size hardware:


Benchmark                                 (size) Mode Cnt   Before    After    Units
IndexInRangeBenchmark.byteIndexInRange       7  thrpt  5  35730.865 41386.360  ops/ms
IndexInRangeBenchmark.byteIndexInRange     259  thrpt  5   1902.071  3526.831  ops/ms
IndexInRangeBenchmark.doubleIndexInRange     7  thrpt  5  23329.810 25691.336  ops/ms
IndexInRangeBenchmark.doubleIndexInRange   259  thrpt  5    275.182  1613.951  ops/ms
IndexInRangeBenchmark.floatIndexInRange      7  thrpt  5  24095.898 26462.455  ops/ms
IndexInRangeBenchmark.floatIndexInRange    259  thrpt  5    556.816  2121.836  ops/ms
IndexInRangeBenchmark.intIndexInRange        7  thrpt  5  35722.428 39673.349  ops/ms
IndexInRangeBenchmark.intIndexInRange      259  thrpt  5   4869.695  5368.887  ops/ms
IndexInRangeBenchmark.longIndexInRange       7  thrpt  5  35985.543 41213.203  ops/ms
IndexInRangeBenchmark.longIndexInRange     259  thrpt  5   2303.811  3236.426  ops/ms
IndexInRangeBenchmark.shortIndexInRange      7  thrpt  5  35725.591 41008.665  ops/ms
IndexInRangeBenchmark.shortIndexInRange    259  thrpt  5   1138.442  3172.590  ops/ms


Similar improvement can also be observed on X86 AVX-512 machine with -XX:UseAVX=3.

On a 512-bit vector size system, the vector length for long/double is `8`, which is larger than `8` for other types. To make sure the tests just contain the tail loop part, the smaller array size is set to `7`.  Is it ok for you?  It's not meaningful to me that running the smaller size on non-predicated architectures, because the vector boxing is needed due to the masked `fromArray()/intoArray()` cannot be vectorized, which can affect the benchmark results.

Thanks,
Xiaohong

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

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

From pminborg at openjdk.org  Fri Feb  3 07:28:02 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Fri, 3 Feb 2023 07:28:02 GMT
Subject: Integrated: 8300235: Use VarHandle access in Image(Input |
 Output)StreamImpl classes
In-Reply-To: <PPJBgKqkFFPV_e0GALCKfL3IXCw162qaY0IRWw4S0-M=.e118bdd0-f7b4-4765-9fba-5206ee264f7f@github.com>
References: <PPJBgKqkFFPV_e0GALCKfL3IXCw162qaY0IRWw4S0-M=.e118bdd0-f7b4-4765-9fba-5206ee264f7f@github.com>
Message-ID: <zkfy8mHlUXx8B-5DZowdBEs4bzU-WOXxqc5fj2hphIQ=.35082180-960b-4001-9525-f49c175ebb5a@github.com>

On Wed, 25 Jan 2023 16:39:04 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR suggests improving performance by using the newly introduced class `jdk.internal.util.ByteArray` to improve packing/unpacking operations.
> 
> The PR also proposes adding a `ByteArrayLittleEndian` class for support for little endian packing/unpacking.

This pull request has now been integrated.

Changeset: b504c941
Author:    Per Minborg <pminborg at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/b504c9411e4a7a93e07a340a5d32a5ca9764a006
Stats:     373 lines in 6 files changed: 95 ins; 144 del; 134 mod

8300235: Use VarHandle access in Image(Input | Output)StreamImpl classes

Reviewed-by: rriggs

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

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

From duke at openjdk.org  Fri Feb  3 07:36:36 2023
From: duke at openjdk.org (SUN Guoyun)
Date: Fri, 3 Feb 2023 07:36:36 GMT
Subject: RFR: 8301736:
 jdk/incubator/concurrent/StructuredTaskScope/StructuredTaskScopeTest.java fail
 with -Xcomp
Message-ID: <VhsVSI7-pYyffYNvgIrla6sTwX6WFuntg-QBGWPy3tw=.38aad54b-0cbe-4d0d-b732-776ff2effb7c@github.com>

Hi all,
When `-Xcomp` be used, java thread to block for longer, then causing StructuredTaskScopeTest.java failed frequently on the AArch64 and LoongArch64 architecture.

This PR fix the issue, Please help review it.

Thanks.

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

Commit messages:
 - 8301736: jdk/incubator/concurrent/StructuredTaskScope/StructuredTaskScopeTest.java fail with -Xcomp

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

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

From alanb at openjdk.org  Fri Feb  3 07:36:37 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 3 Feb 2023 07:36:37 GMT
Subject: RFR: 8301736:
 jdk/incubator/concurrent/StructuredTaskScope/StructuredTaskScopeTest.java fail
 with -Xcomp
In-Reply-To: <VhsVSI7-pYyffYNvgIrla6sTwX6WFuntg-QBGWPy3tw=.38aad54b-0cbe-4d0d-b732-776ff2effb7c@github.com>
References: <VhsVSI7-pYyffYNvgIrla6sTwX6WFuntg-QBGWPy3tw=.38aad54b-0cbe-4d0d-b732-776ff2effb7c@github.com>
Message-ID: <y7BZUwO8_m4G8jyD0Wi3VjCd5KFABPw78A_sV_CRvlM=.03b34c44-3e3e-4908-a784-ac4670b3a92e@github.com>

On Fri, 3 Feb 2023 03:19:05 GMT, SUN Guoyun <duke at openjdk.org> wrote:

> Hi all,
> When `-Xcomp` be used, java thread to block for longer, then causing StructuredTaskScopeTest.java failed frequently on the AArch64 and LoongArch64 architecture.
> 
> This PR fix the issue, Please help review it.
> 
> Thanks.

test/jdk/jdk/incubator/concurrent/StructuredTaskScope/StructuredTaskScopeTest.java line 617:

> 615:         try (var scope = new StructuredTaskScope(null, factory)) {
> 616:             Future<String> future = scope.fork(() -> {
> 617:                 Thread.sleep(Duration.ofMillis(1000));

As a short term fix, this is okay, Duration.ofSeconds(2) might be a bit more robust. We are iterating on this API so there are test changes in the works, in this case we can change it to until that the sub-tasks is parked before calling joinUntil with the interrupt status set.

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

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

From alanb at openjdk.org  Fri Feb  3 07:40:00 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 3 Feb 2023 07:40:00 GMT
Subject: RFR: 8300235: Use VarHandle access in Image(Input |
 Output)StreamImpl classes [v4]
In-Reply-To: <ViV_w-br_doi4-b5zLEUNoco0hH-5OOIDGMZVCHIRsU=.149b260e-a50c-4c22-8782-ddb1c29ec1bd@github.com>
References: <PPJBgKqkFFPV_e0GALCKfL3IXCw162qaY0IRWw4S0-M=.e118bdd0-f7b4-4765-9fba-5206ee264f7f@github.com>
 <ViV_w-br_doi4-b5zLEUNoco0hH-5OOIDGMZVCHIRsU=.149b260e-a50c-4c22-8782-ddb1c29ec1bd@github.com>
Message-ID: <A2az7mf95jU2mvmYG9AXL7Mj46BbqqKgTanlzNVFrso=.901a636a-7b28-45eb-9b1a-b2ad641d747d@github.com>

On Thu, 2 Feb 2023 19:29:05 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR suggests improving performance by using the newly introduced class `jdk.internal.util.ByteArray` to improve packing/unpacking operations.
>> 
>> The PR also proposes adding a `ByteArrayLittleEndian` class for support for little endian packing/unpacking.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rename to createLittleEndian

Do I read this correctly that the proposal is to have ByteArray and ByteArrayLittleEndian?

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

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

From duke at openjdk.org  Fri Feb  3 07:43:51 2023
From: duke at openjdk.org (SUN Guoyun)
Date: Fri, 3 Feb 2023 07:43:51 GMT
Subject: RFR: 8301736:
 jdk/incubator/concurrent/StructuredTaskScope/StructuredTaskScopeTest.java fail
 with -Xcomp
In-Reply-To: <y7BZUwO8_m4G8jyD0Wi3VjCd5KFABPw78A_sV_CRvlM=.03b34c44-3e3e-4908-a784-ac4670b3a92e@github.com>
References: <VhsVSI7-pYyffYNvgIrla6sTwX6WFuntg-QBGWPy3tw=.38aad54b-0cbe-4d0d-b732-776ff2effb7c@github.com>
 <y7BZUwO8_m4G8jyD0Wi3VjCd5KFABPw78A_sV_CRvlM=.03b34c44-3e3e-4908-a784-ac4670b3a92e@github.com>
Message-ID: <UpdlUIY4wRuP2AJPoR93i2E4Hgr-GlGIWqmOJJFrIZU=.9a885878-a1c5-418e-ae7c-882071ad1f30@github.com>

On Fri, 3 Feb 2023 07:31:21 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Hi all,
>> When `-Xcomp` be used, java thread to block for longer, then causing StructuredTaskScopeTest.java failed frequently on the AArch64 and LoongArch64 architecture.
>> 
>> This PR fix the issue, Please help review it.
>> 
>> Thanks.
>
> test/jdk/jdk/incubator/concurrent/StructuredTaskScope/StructuredTaskScopeTest.java line 617:
> 
>> 615:         try (var scope = new StructuredTaskScope(null, factory)) {
>> 616:             Future<String> future = scope.fork(() -> {
>> 617:                 Thread.sleep(Duration.ofMillis(1000));
> 
> As a short term fix, this is okay, Duration.ofSeconds(2) might be a bit more robust. We are iterating on this API so there are test changes in the works, in this case we can change it to poll until the sub-task is parked before calling joinUntil with the interrupt status set.

So do I change to  `Duration.ofSeconds(2)` or cancel this PR?

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

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

From alanb at openjdk.org  Fri Feb  3 07:46:51 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 3 Feb 2023 07:46:51 GMT
Subject: RFR: 8301736:
 jdk/incubator/concurrent/StructuredTaskScope/StructuredTaskScopeTest.java fail
 with -Xcomp
In-Reply-To: <UpdlUIY4wRuP2AJPoR93i2E4Hgr-GlGIWqmOJJFrIZU=.9a885878-a1c5-418e-ae7c-882071ad1f30@github.com>
References: <VhsVSI7-pYyffYNvgIrla6sTwX6WFuntg-QBGWPy3tw=.38aad54b-0cbe-4d0d-b732-776ff2effb7c@github.com>
 <y7BZUwO8_m4G8jyD0Wi3VjCd5KFABPw78A_sV_CRvlM=.03b34c44-3e3e-4908-a784-ac4670b3a92e@github.com>
 <UpdlUIY4wRuP2AJPoR93i2E4Hgr-GlGIWqmOJJFrIZU=.9a885878-a1c5-418e-ae7c-882071ad1f30@github.com>
Message-ID: <0P42OXAgTEJOtVs02dOt4rwH3fyjx3XOnsNJmUMDd4A=.d7d37726-1e3a-4cc1-9bd6-e61aba1d013c@github.com>

On Fri, 3 Feb 2023 07:41:24 GMT, SUN Guoyun <duke at openjdk.org> wrote:

>> test/jdk/jdk/incubator/concurrent/StructuredTaskScope/StructuredTaskScopeTest.java line 617:
>> 
>>> 615:         try (var scope = new StructuredTaskScope(null, factory)) {
>>> 616:             Future<String> future = scope.fork(() -> {
>>> 617:                 Thread.sleep(Duration.ofMillis(1000));
>> 
>> As a short term fix, this is okay, Duration.ofSeconds(2) might be a bit more robust. We are iterating on this API so there are test changes in the works, in this case we can change it to poll until the sub-task is parked before calling joinUntil with the interrupt status set.
>
> So do I change to  `Duration.ofSeconds(2)` or cancel this PR?

Go ahead with the change as this testInterruptJoinUntil isn't robust (as you've found with the -Xcomp runs). When we refresh the test we'll replace this part so that it poll the subtask until it is parked before testing joinUntil with the interrupt status set.

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

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

From duke at openjdk.org  Fri Feb  3 07:59:25 2023
From: duke at openjdk.org (SUN Guoyun)
Date: Fri, 3 Feb 2023 07:59:25 GMT
Subject: RFR: 8301736:
 jdk/incubator/concurrent/StructuredTaskScope/StructuredTaskScopeTest.java fail
 with -Xcomp [v2]
In-Reply-To: <VhsVSI7-pYyffYNvgIrla6sTwX6WFuntg-QBGWPy3tw=.38aad54b-0cbe-4d0d-b732-776ff2effb7c@github.com>
References: <VhsVSI7-pYyffYNvgIrla6sTwX6WFuntg-QBGWPy3tw=.38aad54b-0cbe-4d0d-b732-776ff2effb7c@github.com>
Message-ID: <5Eef3Ky4IVsBoJXsf5frxckrHifV-gJhNapvjiWcoKc=.90425d68-79cb-462b-884e-77c50699d45e@github.com>

> Hi all,
> When `-Xcomp` be used, java thread to block for longer, then causing StructuredTaskScopeTest.java failed frequently on the AArch64 and LoongArch64 architecture.
> 
> This PR fix the issue, Please help review it.
> 
> Thanks.

SUN Guoyun has updated the pull request incrementally with one additional commit since the last revision:

  8301736: jdk/incubator/concurrent/StructuredTaskScope/StructuredTaskScopeTest.java fail with -Xcomp

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12398/files
  - new: https://git.openjdk.org/jdk/pull/12398/files/d52a156a..c448c97e

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

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

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

From alanb at openjdk.org  Fri Feb  3 07:59:26 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 3 Feb 2023 07:59:26 GMT
Subject: RFR: 8301736:
 jdk/incubator/concurrent/StructuredTaskScope/StructuredTaskScopeTest.java fail
 with -Xcomp [v2]
In-Reply-To: <5Eef3Ky4IVsBoJXsf5frxckrHifV-gJhNapvjiWcoKc=.90425d68-79cb-462b-884e-77c50699d45e@github.com>
References: <VhsVSI7-pYyffYNvgIrla6sTwX6WFuntg-QBGWPy3tw=.38aad54b-0cbe-4d0d-b732-776ff2effb7c@github.com>
 <5Eef3Ky4IVsBoJXsf5frxckrHifV-gJhNapvjiWcoKc=.90425d68-79cb-462b-884e-77c50699d45e@github.com>
Message-ID: <PGWVDnn8aij-twtntYj2LxCh9nwTekrc2k5yKvOWJf8=.44dab0c9-3b61-4d8d-b9f9-2aa46abcd3ff@github.com>

On Fri, 3 Feb 2023 07:55:05 GMT, SUN Guoyun <duke at openjdk.org> wrote:

>> Hi all,
>> When `-Xcomp` be used, java thread to block for longer, then causing StructuredTaskScopeTest.java failed frequently on the AArch64 and LoongArch64 architecture.
>> 
>> This PR fix the issue, Please help review it.
>> 
>> Thanks.
>
> SUN Guoyun has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8301736: jdk/incubator/concurrent/StructuredTaskScope/StructuredTaskScopeTest.java fail with -Xcomp

Marked as reviewed by alanb (Reviewer).

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

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

From duke at openjdk.org  Fri Feb  3 09:40:08 2023
From: duke at openjdk.org (duke)
Date: Fri, 3 Feb 2023 09:40:08 GMT
Subject: Withdrawn: 6478546: FileInputStream.read() throws OutOfMemoryError
 when there is plenty available
In-Reply-To: <7zMVWPqTuT6RazzzaPgj41iN6BjrlpYS2a2NFoFO_-k=.67ac646d-f4bb-4d4f-8f96-f90fd03908a1@github.com>
References: <7zMVWPqTuT6RazzzaPgj41iN6BjrlpYS2a2NFoFO_-k=.67ac646d-f4bb-4d4f-8f96-f90fd03908a1@github.com>
Message-ID: <HqKZEbagThGPo9BL8dCqeqbrPQo3VdNvjPehqca_C4M=.56795a7b-21e4-4068-9ea6-211745615e13@github.com>

On Thu, 14 Apr 2022 01:40:50 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Modify native multi-byte read-write code used by the `java.io` classes to limit the size of the allocated native buffer thereby decreasing off-heap memory footprint and increasing throughput.

This pull request has been closed without being integrated.

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

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

From rgiulietti at openjdk.org  Fri Feb  3 12:52:49 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Fri, 3 Feb 2023 12:52:49 GMT
Subject: RFR: JDK-8301396: Port fdlibm expm1 to Java
In-Reply-To: <U3Jo6dH5rPBRmSVceetCxwisBbTPlaHshGCP2zL9kD0=.1d76ebf0-e729-4066-b9b6-46e06b350eb3@github.com>
References: <U3Jo6dH5rPBRmSVceetCxwisBbTPlaHshGCP2zL9kD0=.1d76ebf0-e729-4066-b9b6-46e06b350eb3@github.com>
Message-ID: <O5WJYUuhoy7t8QVm7ROmKwquiNJ43TyUCMwp2zrBYTg=.765fb5e8-4d53-4b18-b26d-5118eb7d94ee@github.com>

On Thu, 2 Feb 2023 22:18:32 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Next on the FDLIBM C -> Java port, expm1.
> Coming soon, hyperbolic transcendentals (sinh, cosh, tanh)!
> 
> For expm1, the C vs transliteration port show the usual kind of differences, beside formatting of the constants, the use of the __HI macro on the left-hand side needs to be replaced by a method call and an assignment, as seen below:
> 
> 
> < 
> < #include "fdlibm.h"
> < 
> < #ifdef __STDC__
> < static const double
> < #else
> < static double
> < #endif
> < one             = 1.0,
> < huge            = 1.0e+300,
> < tiny            = 1.0e-300,
> < o_threshold     = 7.09782712893383973096e+02,/* 0x40862E42, 0xFEFA39EF */
> < ln2_hi          = 6.93147180369123816490e-01,/* 0x3fe62e42, 0xfee00000 */
> < ln2_lo          = 1.90821492927058770002e-10,/* 0x3dea39ef, 0x35793c76 */
> < invln2          = 1.44269504088896338700e+00,/* 0x3ff71547, 0x652b82fe */
> ---
>>     static class Expm1 {
>>         private static final double one             = 1.0;
>>         private static final double huge            = 1.0e+300;
>>         private static final double tiny            = 1.0e-300;
>>         private static final double o_threshold     = 7.09782712893383973096e+02; /* 0x40862E42, 0xFEFA39EF */
>>         private static final double ln2_hi          = 6.93147180369123816490e-01; /* 0x3fe62e42, 0xfee00000 */
>>         private static final double ln2_lo          = 1.90821492927058770002e-10; /* 0x3dea39ef, 0x35793c76 */
>>         private static final double invln2          = 1.44269504088896338700e+00; /* 0x3ff71547, 0x652b82fe */
> 111,115c104,108
> < Q1  =  -3.33333333333331316428e-02, /* BFA11111 111110F4 */
> < Q2  =   1.58730158725481460165e-03, /* 3F5A01A0 19FE5585 */
> < Q3  =  -7.93650757867487942473e-05, /* BF14CE19 9EAADBB7 */
> < Q4  =   4.00821782732936239552e-06, /* 3ED0CFCA 86E65239 */
> < Q5  =  -2.01099218183624371326e-07; /* BE8AFDB7 6E09C32D */
> ---
>>         private static final double Q1  =  -3.33333333333331316428e-02; /* BFA11111 111110F4 */
>>         private static final double Q2  =   1.58730158725481460165e-03; /* 3F5A01A0 19FE5585 */
>>         private static final double Q3  =  -7.93650757867487942473e-05; /* BF14CE19 9EAADBB7 */
>>         private static final double Q4  =   4.00821782732936239552e-06; /* 3ED0CFCA 86E65239 */
>>         private static final double Q5  =  -2.01099218183624371326e-07; /* BE8AFDB7 6E09C32D */
> 117,123c110
> < #ifdef __STDC__
> <         double expm1(double x)
> < #else
> <         double expm1(x)
> <         double x;
> < #endif
> < {
> ---
>>         static double compute(double x) {
> 126c113
> <         unsigned hx;
> ---
>>             /*unsigned*/ int hx;
> 157c144
> <                 k  = invln2*x+((xsb==0)?0.5:-0.5);
> ---
>>                     k  = (int)(invln2*x+((xsb==0)?0.5:-0.5));
> 188c175
> <                 __HI(y) += (k<<20);     /* add k to y's exponent */
> ---
>>                     y = __HI(y,  __HI(y) + (k<<20));     /* add k to y's exponent */
> 193c180
> <                 __HI(t) = 0x3ff00000 - (0x200000>>k);  /* t=1-2^-k */
> ---
>>                     t = __HI(t, 0x3ff00000 - (0x200000>>k));  /* t=1-2^-k */
> 195c182
> <                 __HI(y) += (k<<20);     /* add k to y's exponent */
> ---
>>                     y = __HI(y, __HI(y) + (k<<20));     /* add k to y's exponent */
> 197c184
> <                 __HI(t)  = ((0x3ff-k)<<20);     /* 2^-k */
> ---
>>                     t = __HI(t, ((0x3ff-k)<<20));     /* 2^-k */
> 200c187
> <                 __HI(y) += (k<<20);     /* add k to y's exponent */
> ---
>>                     y = __HI(y, __HI(y) + (k<<20));     /* add k to y's exponent */
> 205c192
> < 
> ---
>>     }
> 
> 
> When comparing the transliteration port and the more idiomatic port, there were no surprising or notable differences:
> 
> 
> $ diff -w Expm1.translit.java Expm1.fdlibm.java  
> 99,102c99,102
> <         private static final double o_threshold     = 7.09782712893383973096e+02; /* 0x40862E42, 0xFEFA39EF */
> <         private static final double ln2_hi          = 6.93147180369123816490e-01; /* 0x3fe62e42, 0xfee00000 */
> <         private static final double ln2_lo          = 1.90821492927058770002e-10; /* 0x3dea39ef, 0x35793c76 */
> <         private static final double invln2          = 1.44269504088896338700e+00; /* 0x3ff71547, 0x652b82fe */
> ---
>>         private static final double o_threshold =  0x1.62e42fefa39efp9;   //  7.09782712893383973096e+02
>>         private static final double ln2_hi      =  0x1.62e42feep-1;       //  6.93147180369123816490e-01
>>         private static final double ln2_lo      =  0x1.a39ef35793c76p-33; //  1.90821492927058770002e-10
>>         private static final double invln2      =  0x1.71547652b82fep0;   //  1.44269504088896338700e+00
> 104,108c104,108
> <         private static final double Q1  =  -3.33333333333331316428e-02; /* BFA11111 111110F4 */
> <         private static final double Q2  =   1.58730158725481460165e-03; /* 3F5A01A0 19FE5585 */
> <         private static final double Q3  =  -7.93650757867487942473e-05; /* BF14CE19 9EAADBB7 */
> <         private static final double Q4  =   4.00821782732936239552e-06; /* 3ED0CFCA 86E65239 */
> <         private static final double Q5  =  -2.01099218183624371326e-07; /* BE8AFDB7 6E09C32D */
> ---
>>         private static final double Q1          = -0x1.11111111110f4p-5;  // -3.33333333333331316428e-02
>>         private static final double Q2          =  0x1.a01a019fe5585p-10; //  1.58730158725481460165e-03
>>         private static final double Q3          = -0x1.4ce199eaadbb7p-14; // -7.93650757867487942473e-05
>>         private static final double Q4          =  0x1.0cfca86e65239p-18; //  4.00821782732936239552e-06
>>         private static final double Q5          = -0x1.afdb76e09c32dp-23; // -2.01099218183624371326e-07
> 116,118c116,118
> <             xsb = hx&0x80000000;            /* sign bit of x */
> <             if(xsb==0) y=x; else y= -x;     /* y = |x| */
> <             hx &= 0x7fffffff;               /* high word of |x| */
> ---
>>             xsb = hx & 0x8000_0000;            /* sign bit of x */
>>             y = Math.abs(x);
>>             hx &= 0x7fff_ffff;               /* high word of |x| */
> 121,124c121,124
> <             if(hx >= 0x4043687A) {                  /* if |x|>=56*ln2 */
> <                 if(hx >= 0x40862E42) {              /* if |x|>=709.78... */
> <                     if(hx>=0x7ff00000) {
> <                         if(((hx&0xfffff)|__LO(x))!=0)
> ---
>>             if (hx >= 0x4043_687A) {                  /* if |x| >= 56*ln2 */
>>                 if (hx >= 0x4086_2E42) {              /* if |x| >= 709.78... */
>>                     if (hx >= 0x7ff_00000) {
>>                         if (((hx & 0xf_ffff) | __LO(x)) != 0) {
> 126c126,131
> <                         else return (xsb==0)? x:-1.0;/* exp(+-inf)={inf,-1} */
> ---
>>                         } else {
>>                             return (xsb == 0)? x : -1.0; /* exp(+-inf)={inf,-1} */
>>                         }
>>                     }
>>                     if (x > o_threshold) {
>>                         return huge*huge; /* overflow */
> 128d132
> <                     if(x > o_threshold) return huge*huge; /* overflow */
> 131c135
> <                     if(x+tiny<0.0)          /* raise inexact */
> ---
>>                     if (x + tiny < 0.0) {         /* raise inexact */
> 134a139
>>             }
> 137,142c142,152
> <             if(hx > 0x3fd62e42) {           /* if  |x| > 0.5 ln2 */
> <                 if(hx < 0x3FF0A2B2) {       /* and |x| < 1.5 ln2 */
> <                     if(xsb==0)
> <                         {hi = x - ln2_hi; lo =  ln2_lo;  k =  1;}
> <                     else
> <                         {hi = x + ln2_hi; lo = -ln2_lo;  k = -1;}
> ---
>>             if (hx > 0x3fd6_2e42) {           /* if  |x| > 0.5 ln2 */
>>                 if (hx < 0x3FF0_A2B2) {       /* and |x| < 1.5 ln2 */
>>                     if (xsb == 0) {
>>                         hi = x - ln2_hi;
>>                         lo =  ln2_lo;
>>                         k =  1;}
>>                     else {
>>                         hi = x + ln2_hi;
>>                         lo = -ln2_lo;
>>                         k = -1;
>>                     }
> 151,152c161
> <             }
> <             else if(hx < 0x3c900000) {      /* when |x|<2**-54, return x */
> ---
>>             } else if (hx < 0x3c90_0000) {      /* when |x|<2**-54, return x */
> 154a164,165
>>             } else {
>>                 k = 0;
> 156d166
> <             else k = 0;
> 164,165c174,176
> <             if(k==0) return x - (x*e-hxs);          /* c is 0 */
> <             else {
> ---
>>             if (k == 0) {
>>                 return x - (x*e - hxs);          /* c is 0 */
>>             } else {
> 168c179,181
> <                 if(k== -1) return 0.5*(x-e)-0.5;
> ---
>>                 if (k == -1) {
>>                     return 0.5*(x - e) - 0.5;
>>                 }
> 170,171c183,187
> <                     if(x < -0.25) return -2.0*(e-(x+0.5));
> <                     else          return  one+2.0*(x-e);
> ---
>>                     if(x < -0.25) {
>>                         return -2.0*(e - (x + 0.5));
>>                     } else {
>>                         return  one + 2.0*(x - e);
>>                     }
> 180c196
> <                     t = __HI(t, 0x3ff00000 - (0x200000>>k));  /* t=1-2^-k */
> ---
>>                     t = __HI(t, 0x3ff0_0000 - (0x2_00000 >> k));  /* t=1-2^-k */

With the corrections by @turbanoff LGTM.

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

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

From asotona at openjdk.org  Fri Feb  3 14:31:24 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Fri, 3 Feb 2023 14:31:24 GMT
Subject: RFR: 8294982: Implementation of Classfile API [v12]
In-Reply-To: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
References: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
Message-ID: <Q4VeZ2yWAg85FqUDJa5hYq3jHty5H547gD0H-x3oIq0=.58d463a4-237a-4fee-bd0f-83262d49522a@github.com>

> This is root pull request with Classfile API implementation, tests and benchmarks initial drop into JDK.
> 
> Following pull requests consolidating JDK class files parsing, generating, and transforming ([JDK-8294957](https://bugs.openjdk.org/browse/JDK-8294957)) will chain to this one.
> 
> Classfile API development is tracked at:
> https://github.com/openjdk/jdk-sandbox/tree/classfile-api-branch
> 
> Development branch of consolidated JDK class files parsing, generating, and transforming is at:
> https://github.com/openjdk/jdk-sandbox/tree/classfile-api-dev-branch
> 
> Classfile API [JEP](https://bugs.openjdk.org/browse/JDK-8280389) and [online API documentation](https://htmlpreview.github.io/?https://raw.githubusercontent.com/openjdk/jdk-sandbox/classfile-api-javadoc-branch/doc/classfile-api/javadoc/java.base/jdk/classfile/package-summary.html) is also available.
> 
> Please take you time to review this non-trivial JDK addition.
> 
> Thank you,
> Adam

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

  Classfile API moved under jdk.internal.classfile package

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10982/files
  - new: https://git.openjdk.org/jdk/pull/10982/files/80213e61..8df1dc21

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10982&range=11
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10982&range=10-11

  Stats: 21514 lines in 401 files changed: 10054 ins; 10054 del; 1406 mod
  Patch: https://git.openjdk.org/jdk/pull/10982.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10982/head:pull/10982

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

From rriggs at openjdk.org  Fri Feb  3 15:09:51 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 3 Feb 2023 15:09:51 GMT
Subject: RFR: 8301737:
 java/rmi/server/UnicastRemoteObject/serialFilter/FilterUROTest.java fail with
 -Xcomp
In-Reply-To: <l5m5_9io2QMSFNY7dBHT3Nr2I9Er8wmd92Ze8FP-XE0=.a40d29be-77be-4719-a0a0-71d032eea1e5@github.com>
References: <l5m5_9io2QMSFNY7dBHT3Nr2I9Er8wmd92Ze8FP-XE0=.a40d29be-77be-4719-a0a0-71d032eea1e5@github.com>
Message-ID: <L33z7qV77oHz2xnVX-S_od1es6PXKuW6g8Zt7HXvHCg=.e0964097-b507-4a28-a10e-08c976b78a87@github.com>

On Fri, 3 Feb 2023 03:52:39 GMT, SUN Guoyun <duke at openjdk.org> wrote:

> Hi all,
> When -Xcomp be used, java thread to block for longer, then causing this test failed frequently on the AArch64 and LoongArch64 architecture.
> 
> This PR fix the issue, Please help review it.
> 
> Thanks.

What is the connection between -Xcomp and the fix: `-Dsun.net.httpserver.idleInterval=50000`?
The test does not use httpserver.  Perhaps jtreg /agent does, but an explanation of the interaction would be appreciated.

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

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

From asotona at openjdk.org  Fri Feb  3 15:11:30 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Fri, 3 Feb 2023 15:11:30 GMT
Subject: RFR: 8294961: java.base java.lang.reflect.ProxyGenerator uses ASM
 to generate proxy classes [v2]
In-Reply-To: <rqqi61cKbJ8TjDVSzsjh6BVXjF1ZxL2ZFHheuXzL5E8=.bd1f1a2c-6f35-4180-a0a5-8a6e3cb93e75@github.com>
References: <rqqi61cKbJ8TjDVSzsjh6BVXjF1ZxL2ZFHheuXzL5E8=.bd1f1a2c-6f35-4180-a0a5-8a6e3cb93e75@github.com>
Message-ID: <pllZmQlszffAmAiq-P45e6FyZkNbRTp1VbIbUe29xo8=.449d0bfc-a712-484a-8aee-0140a054b2d6@github.com>

> java.base java.lang.reflect.ProxyGenerator uses ASM to generate proxy classes and this patch converts it to use Classfile API.
> 
> This pull request suppose to chain on the 8294982: Implementation of Classfile API https://github.com/openjdk/jdk/pull/10982
> 
> 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 four additional commits since the last revision:

 - j.l.r.ProxyGenerator fix - Classfile API moved under jdk.internal.classfile package
 - Merge branch 'JDK-8294982' into JDK-8294961
 - Merge branch 'JDK-8294982' into JDK-8294961
 - 8294961: java.base java.lang.reflect.ProxyGenerator uses ASM to generate proxy classes

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10991/files
  - new: https://git.openjdk.org/jdk/pull/10991/files/faf84e41..c242a4a2

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

  Stats: 308313 lines in 5554 files changed: 150280 ins; 116292 del; 41741 mod
  Patch: https://git.openjdk.org/jdk/pull/10991.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10991/head:pull/10991

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

From rriggs at openjdk.org  Fri Feb  3 15:47:07 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 3 Feb 2023 15:47:07 GMT
Subject: RFR: 8301552: Use AtomicReferenceArray for caching instead of CHM
 in ZoneOffset [v6]
In-Reply-To: <3yEmX_TScPCLb-W1zwHwEXZXvXWAzemtwCtYTFPsSXg=.d8aaa569-8812-45dd-a3b5-af99b677165b@github.com>
References: <b228oWPoEJf0lfGgIVXwmo1mATeKWRTivuJ2PbgwAmI=.465a4f9b-7a4b-4bbb-9f94-66d1d889a072@github.com>
 <3yEmX_TScPCLb-W1zwHwEXZXvXWAzemtwCtYTFPsSXg=.d8aaa569-8812-45dd-a3b5-af99b677165b@github.com>
Message-ID: <3NLsh7ML4B9x-YSlpvJjfFPCNIS5ZCpeGisUHgmTF_k=.f6cea935-ee7d-4cac-ac6d-03178f0dfd8b@github.com>

On Thu, 2 Feb 2023 15:44:54 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> `ZoneOffset` instances are cached by the `ZoneOffset` class itself for values in the range [-18h, 18h] for each second that is on an even quarter of an hour (i.e. at most 2*18*4+1 = 145 values). 
>> 
>> Instead of using a `ConcurrentHashMap` for caching instanced, we could instead use an `AtomicReferenceArray` with direct slot value access for said even seconds. This will improve performance and reduce the number of object even though the backing array will go from an initial 32 in the CHM to an initial/final 145 in the ARA. The CHM will contain much more objects and array slots for typical numbers of entries in the cache and will compute hash/bucket/collision on the hot code path for each cache access.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix benchmark

Is this added complexity and startup time (VarHandle) worth it? 
Will normal usage be noticed by typical applications?(Microbenchmark not withstanding).

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

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

From dfuchs at openjdk.org  Fri Feb  3 15:54:56 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 3 Feb 2023 15:54:56 GMT
Subject: RFR: 8301737:
 java/rmi/server/UnicastRemoteObject/serialFilter/FilterUROTest.java fail with
 -Xcomp
In-Reply-To: <l5m5_9io2QMSFNY7dBHT3Nr2I9Er8wmd92Ze8FP-XE0=.a40d29be-77be-4719-a0a0-71d032eea1e5@github.com>
References: <l5m5_9io2QMSFNY7dBHT3Nr2I9Er8wmd92Ze8FP-XE0=.a40d29be-77be-4719-a0a0-71d032eea1e5@github.com>
Message-ID: <Rx4Yso3GBMPTSCb-ofT80DXdRkVkxl8r1Di6Ay3XhUo=.8b150a73-58f3-4aaf-af1a-9445ee9064bd@github.com>

On Fri, 3 Feb 2023 03:52:39 GMT, SUN Guoyun <duke at openjdk.org> wrote:

> Hi all,
> When -Xcomp be used, java thread to block for longer, then causing this test failed frequently on the AArch64 and LoongArch64 architecture.
> 
> This PR fix the issue, Please help review it.
> 
> Thanks.

test/jdk/java/rmi/server/UnicastRemoteObject/serialFilter/FilterUROTest.java line 41:

> 39: /*
> 40:  * @test
> 41:  * @run testng/othervm -Dsun.net.httpserver.idleInterval=50000 FilterUROTest

This test doesn't seem to be using an HttpServer so setting this system property seems useless as it should have no effect.

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

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

From qamai at openjdk.org  Fri Feb  3 16:25:53 2023
From: qamai at openjdk.org (Quan Anh Mai)
Date: Fri, 3 Feb 2023 16:25:53 GMT
Subject: RFR: 8293198: [vectorapi] Improve the implementation of
 VectorMask.indexInRange() [v2]
In-Reply-To: <0dNCRVASsdME6qS79u5z7c6mikJs1jfucfo54lo71ik=.d8c2dc6e-bc60-499f-899c-880a2219b052@github.com>
References: <fN58bi3n01tqWpG0-jjUPZQe8hmls2GQ5X3NL2o1RPg=.80e7965d-50af-4fac-bd7c-0a2b99cffe7e@github.com>
 <0dNCRVASsdME6qS79u5z7c6mikJs1jfucfo54lo71ik=.d8c2dc6e-bc60-499f-899c-880a2219b052@github.com>
Message-ID: <jqseZ2dqTzyM1riPqfYIbJO6AetVgLV9Z_8ypwnyOvc=.5f6b6a60-e4dc-4162-8014-a5892dfdfa71@github.com>

On Fri, 3 Feb 2023 07:13:10 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

>> The Vector API `"indexInRange(int offset, int limit)"` is used
>> to compute a vector mask whose lanes are set to true if the
>> index of the lane is inside the range specified by the `"offset"`
>> and `"limit"` arguments, otherwise the lanes are set to false.
>> 
>> There are two special cases for this API:
>>  1) If `"offset >= 0 && offset >= limit"`, all the lanes of the
>> generated mask are false.
>>  2) If` "offset >= 0 && limit - offset >= vlength"`, all the
>> lanes of the generated mask are true. Note that `"vlength"` is
>> the number of vector lanes.
>> 
>> For such special cases, we can simply use `"maskAll(false|true)"`
>> to implement the API. Otherwise, the original comparison with
>> `"iota" `vector is needed. And for further optimization, we have
>> optimal instruction supported by SVE (i.e. whilelo [1]), which
>> can implement the API directly if the `"offset >= 0"`.
>> 
>> As a summary, to optimize the API, we can use the if-else branches
>> to handle the specific cases in java level and intrinsify the
>> remaining case by C2 compiler:
>> 
>> 
>>   public VectorMask<E> indexInRange(int offset, int limit) {
>>       if (offset < 0) {
>>           return this.and(indexInRange0Helper(offset, limit));
>>       } else if (offset >= limit) {
>>           return this.and(vectorSpecies().maskAll(false));
>>       } else if (limit - offset >= length()) {
>>           return this.and(vectorSpecies().maskAll(true));
>>       }
>>       return this.and(indexInRange0(offset, limit));
>>  }
>> 
>> 
>> The last part (i.e. `"indexInRange0"`) in the above implementation
>> is expected to be intrinsified by C2 compiler if the necessary IRs
>> are supported. Otherwise, it will fall back to the original API
>> implementation (i.e. `"indexInRange0Helper"`). Regarding to the
>> intrinsifaction, the compiler will generate `"VectorMaskGen"` IR
>> with "limit - offset" as the input if the current platform supports
>> it. Otherwise, it generates `"VectorLoadConst + VectorMaskCmp"` based
>> on `"iota < limit - offset"`.
>> 
>> For the following java code which uses `"indexInRange"`:
>> 
>> 
>> static final VectorSpecies<Double> SPECIES =
>>                                    DoubleVector.SPECIES_PREFERRED;
>> static final int LENGTH = 1027;
>> 
>> public static double[] da;
>> public static double[] db;
>> public static double[] dc;
>> 
>> private static void func() {
>>     for (int i = 0; i < LENGTH; i += SPECIES.length()) {
>>         var m = SPECIES.indexInRange(i, LENGTH);
>>         var av = DoubleVector.fromArray(SPECIES, da, i, m);
>>         av.lanewise(VectorOperators.NEG).intoArray(dc, i, m);
>>     }
>> }
>> 
>> 
>> The core code generated with SVE 256-bit vector size is:
>> 
>> 
>>   ptrue   p2.d                  ; maskAll(true)
>>   ...
>> LOOP:
>>   ...
>>   sub     w11, w13, w14         ; limit - offset
>>   cmp     w14, w13
>>   b.cs    LABEL-1               ; if (offset >= limit) => uncommon-trap
>>   cmp     w11, #0x4
>>   b.lt    LABEL-2               ; if (limit - offset < vlength)
>>   mov     p1.b, p2.b
>> LABEL-3:
>>   ld1d    {z16.d}, p1/z, [x10]  ; load vector masked
>>   ...
>>   cmp     w14, w29
>>   b.cc    LOOP
>>   ...
>> LABEL-2:
>>   whilelo p1.d, x16, x10        ; VectorMaskGen
>>   ...
>>   b       LABEL-3
>>   ...
>> LABEL-1:
>>   uncommon-trap
>> 
>> 
>> Please note that if the array size `LENGTH` is aligned with
>> the vector size 256 (i.e. `LENGTH = 1024`), the branch "LABEL-2"
>> will be optimized out by compiler and it becomes another
>> uncommon-trap.
>> 
>> For NEON, the main CFG is the same with above. But the compiler
>> intrinsification is different. Here is the code:
>> 
>> 
>>   sub     x10, x10, x12          ; limit - offset
>>   scvtf   d16, x10
>>   dup     v16.2d, v16.d[0]       ; replicateD
>> 
>>   mov     x8, #0xd8d0
>>   movk    x8, #0x84cb, lsl #16
>>   movk    x8, #0xffff, lsl #32
>>   ldr     q17, [x8], #0          ; load the "iota" const vector
>>   fcmgt   v18.2d, v16.2d, v17.2d ; mask = iota < limit - offset
>> 
>> 
>> Here is the performance data of the new added benchmark on an ARM
>> SVE 256-bit platform:
>> 
>> 
>> Benchmark                               (size)  Before    After   Units
>> IndexInRangeBenchmark.byteIndexInRange   1024 11203.697 41404.431 ops/ms
>> IndexInRangeBenchmark.byteIndexInRange   1027  2365.920  8747.004 ops/ms
>> IndexInRangeBenchmark.doubleIndexInRange 1024  1227.505  6092.194 ops/ms
>> IndexInRangeBenchmark.doubleIndexInRange 1027   351.215  1156.683 ops/ms
>> IndexInRangeBenchmark.floatIndexInRange  1024  1468.876 11032.580 ops/ms
>> IndexInRangeBenchmark.floatIndexInRange  1027   699.645  2439.671 ops/ms
>> IndexInRangeBenchmark.intIndexInRange    1024  2842.187 11903.544 ops/ms
>> IndexInRangeBenchmark.intIndexInRange    1027   689.866  2547.424 ops/ms
>> IndexInRangeBenchmark.longIndexInRange   1024  1394.135  5902.973 ops/ms
>> IndexInRangeBenchmark.longIndexInRange   1027   355.621  1189.458 ops/ms
>> IndexInRangeBenchmark.shortIndexInRange  1024  5521.468 21578.340 ops/ms
>> IndexInRangeBenchmark.shortIndexInRange  1027  1264.816  4640.504 ops/ms
>> 
>> 
>> And the performance data with ARM NEON:
>> 
>> 
>> Benchmark                               (size)  Before    After   Units
>> IndexInRangeBenchmark.byteIndexInRange   1024  4026.548 15562.880 ops/ms
>> IndexInRangeBenchmark.byteIndexInRange   1027   305.314   576.559 ops/ms
>> IndexInRangeBenchmark.doubleIndexInRange 1024   289.224  2244.080 ops/ms
>> IndexInRangeBenchmark.doubleIndexInRange 1027    39.740    76.499 ops/ms
>> IndexInRangeBenchmark.floatIndexInRange  1024   675.264  4457.470 ops/ms
>> IndexInRangeBenchmark.floatIndexInRange  1027    79.918   144.952 ops/ms
>> IndexInRangeBenchmark.intIndexInRange    1024   740.139  4014.583 ops/ms
>> IndexInRangeBenchmark.intIndexInRange    1027    78.608   147.903 ops/ms
>> IndexInRangeBenchmark.longIndexInRange   1024   400.683  2209.551 ops/ms
>> IndexInRangeBenchmark.longIndexInRange   1027    41.146    69.599 ops/ms
>> IndexInRangeBenchmark.shortIndexInRange  1024  1821.736  8153.546 ops/ms
>> IndexInRangeBenchmark.shortIndexInRange  1027   158.810   243.205 ops/ms
>> 
>> 
>> The performance improves about `3.5x ~ 7.5x` on the vector size aligned
>> (1024 size) benchmarks both with NEON and SVE. And it improves about
>> `3.5x/1.8x` on the vector size not aligned (1027 size) benchmarks with
>> SVE/NEON respectively. We can also observe the similar improvement on
>> the x86 platforms.
>> 
>> [1] https://developer.arm.com/documentation/ddi0596/2020-12/SVE-Instructions/WHILELO--While-incrementing-unsigned-scalar-lower-than-scalar-
>
> Xiaohong Gong has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add smaller array size for benchmark tests

Thanks, the patch LGTM.

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

Marked as reviewed by qamai (Committer).

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

From heinz at javaspecialists.eu  Fri Feb  3 18:20:36 2023
From: heinz at javaspecialists.eu (Dr Heinz M. Kabutz)
Date: Fri, 3 Feb 2023 20:20:36 +0200
Subject: JEP415: FilterInThread Example
Message-ID: <76209504-e958-b981-8b6b-b90955fd5f5d@javaspecialists.eu>

I was trying to get my head around the FilterInThread example in JEP 415 
(https://openjdk.org/jeps/415) and the JavaDoc for the ObjectInputFilter 
(https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/io/ObjectInputFilter.html)

For example, let's assume we have three filters. The first allow 
ArrayList, the second allows Integer, the third restricts arrays to not 
be larger than 1000.

 ??? ObjectInputFilter allowArrayList = ObjectInputFilter.allowFilter(
 ??????????? Set.of(ArrayList.class, Object.class)::contains, UNDECIDED
 ??? );
 ??? ObjectInputFilter allowInteger = ObjectInputFilter.allowFilter(
 ??????????? Set.of(Number.class, Integer.class)::contains, UNDECIDED
 ??? );
 ??? ObjectInputFilter restrictLargeArrays =
ObjectInputFilter.Config.createFilter("maxarray=1000");

Let's say that we create a FilterInThread instance and install that as 
our factory. Furthermore, we set the allowArrayList as the global serial 
filter. When we call filterInThread.doWithSerialFilter() we pass in the 
allowInteger filter. Lastly, during the actual deserialization, we call 
setObjectInputFilter() on the ObjectInputStream with the 
restrictLargeArrays filter. Ideally, I would want the final filter to 
look like this:

rejectUndecidedClass(merge(restrictLargeArrays,merge(allowInteger,allowArrayList)))

However, in the FilterInThread example, we add the 
rejectUndecidedClass() wrapper around each of the steps. Thus we would 
get something like:

rejectUndecidedClass(merge(restrictLargeArrays,rejectUndecidedClass(merge(allowInteger,rejectUndecidedClass(allowArrayList)))))

Thus we could never allow any classes except for ArrayList.


Regards

Heinz
-- 
Dr Heinz M. Kabutz (PhD CompSci)
Author of "The Java? Specialists' Newsletter" - www.javaspecialists.eu
Java Champion - www.javachampions.org
JavaOne Rock Star Speaker
Tel: +30 69 75 595 262
Skype: kabutz


From mcimadamore at openjdk.org  Fri Feb  3 18:42:12 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 3 Feb 2023 18:42:12 GMT
Subject: RFR: 8294982: Implementation of Classfile API [v12]
In-Reply-To: <Q4VeZ2yWAg85FqUDJa5hYq3jHty5H547gD0H-x3oIq0=.58d463a4-237a-4fee-bd0f-83262d49522a@github.com>
References: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
 <Q4VeZ2yWAg85FqUDJa5hYq3jHty5H547gD0H-x3oIq0=.58d463a4-237a-4fee-bd0f-83262d49522a@github.com>
Message-ID: <c022hrWNEHW76nhP_sXTQXCTjtL8jjM8r_yYv0IvbPI=.2a9cfbae-2fef-4cdb-8189-b869b1513fef@github.com>

On Fri, 3 Feb 2023 14:31:24 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> This is root pull request with Classfile API implementation, tests and benchmarks initial drop into JDK.
>> 
>> Following pull requests consolidating JDK class files parsing, generating, and transforming ([JDK-8294957](https://bugs.openjdk.org/browse/JDK-8294957)) will chain to this one.
>> 
>> Classfile API development is tracked at:
>> https://github.com/openjdk/jdk-sandbox/tree/classfile-api-branch
>> 
>> Development branch of consolidated JDK class files parsing, generating, and transforming is at:
>> https://github.com/openjdk/jdk-sandbox/tree/classfile-api-dev-branch
>> 
>> Classfile API [JEP](https://bugs.openjdk.org/browse/JDK-8280389) and [online API documentation](https://htmlpreview.github.io/?https://raw.githubusercontent.com/openjdk/jdk-sandbox/classfile-api-javadoc-branch/doc/classfile-api/javadoc/java.base/jdk/classfile/package-summary.html) is also available.
>> 
>> Please take you time to review this non-trivial JDK addition.
>> 
>> Thank you,
>> Adam
>
> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Classfile API moved under jdk.internal.classfile package

src/java.base/share/classes/jdk/internal/classfile/AttributedElement.java line 94:

> 92:      * are permitted.
> 93:      */
> 94:     enum Kind {

Not sure how to interpret this. This seems to refer to an attribute - e.g. where is an attribute allowed - rather than to the element (e.g. the declaration to which the attribute is attached). All the constants are unused, so hard to make sense of how this is used.

src/java.base/share/classes/jdk/internal/classfile/Attributes.java line 774:

> 772:      */
> 773:     public static AttributeMapper<?> standardAttribute(Utf8Entry name) {
> 774:         int hash = name.hashCode();

If we have a map, why do we need this "inlined" map here? Performance reasons?

src/java.base/share/classes/jdk/internal/classfile/BootstrapMethodEntry.java line 41:

> 39:  * part of the constant pool.
> 40:  */
> 41: public sealed interface BootstrapMethodEntry

Usages of this seem all to fall into the `constantpool` package - does this interface belong there?

src/java.base/share/classes/jdk/internal/classfile/BufWriter.java line 40:

> 38:  * to the end of the buffer, as well as to create constant pool entries.
> 39:  */
> 40: public sealed interface BufWriter

What is the relationship between this and ClassReader? Is one the dual of the other - e.g. is the intended use for BufWriter to write custom attributes, whereas ClassReader reads custom attributes?

src/java.base/share/classes/jdk/internal/classfile/ClassModel.java line 104:

> 102:      * found
> 103:      */
> 104:     default List<VerifyError> verify(Consumer<String> debugOutput) {

not super sure whether `verify` belongs here - could be another component in the `components` package?

src/java.base/share/classes/jdk/internal/classfile/ClassSignature.java line 34:

> 32:  * Models the generic signature of a class file, as defined by JVMS 4.7.9.
> 33:  */
> 34: public sealed interface ClassSignature

It is a bit odd to have Signature and XYZSignature in the API with the latter not extending the former. I think I get what the API is aiming for though - e.g. Signature is for modelling low-level "portions" of the signature attributes, whereas ClassSignature, MethodSignature and friends are there to model the signature attribute attached to a class, method, etc.

src/java.base/share/classes/jdk/internal/classfile/Classfile.java line 58:

> 56:  * Main entry points for parsing, transforming, and generating classfiles.
> 57:  */
> 58: public class Classfile {

class or interface? (bikeshed, I realize)

src/java.base/share/classes/jdk/internal/classfile/Classfile.java line 197:

> 195:      * @return the classfile bytes
> 196:      */
> 197:     public static byte[] build(ClassDesc thisClass,

The "build" methods here seem regular - e.g. build { class, module } x { byte array, path }. As a future improvement, perhaps capturing the "sink" of a build process might be helpful - so that you can avoid overloads between array and path variants. (e.g. `build(.... toByteArray(arr))`, or `build(...).toByteArray(...)`.

src/java.base/share/classes/jdk/internal/classfile/Classfile.java line 346:

> 344:     public static final int MAGIC_NUMBER = 0xCAFEBABE;
> 345: 
> 346:     public static final int NOP             = 0;

Not sure how I feel about the constants being here. It seems to me that they can be moved to more appropriate places - e.g. Instructor, TypeAnnotation (for the TAT ones), ConstantPool (for the TAG ones).

The classfile versions, OTOH, do seem to belong here.

src/java.base/share/classes/jdk/internal/classfile/CodeBuilder.java line 202:

> 200:     default CodeBuilder block(Consumer<BlockCodeBuilder> handler) {
> 201:         Label breakLabel = newLabel();
> 202:         BlockCodeBuilderImpl child = new BlockCodeBuilderImpl(this, breakLabel);

Nice trick! I like the `breakLabel` concept

src/java.base/share/classes/jdk/internal/classfile/CodeBuilder.java line 333:

> 331:          * @see #catchingAll
> 332:          */
> 333:         CatchBuilder catching(ClassDesc exceptionType, Consumer<BlockCodeBuilder> catchHandler);

I imagine there are name clashes with Java keyword, hence the `ing` in the names. That said, this should probably revisited in a later bikeshedding round - as in the current form, the code builder API has most method names that are nouns (the thing being built) but it also has some verbs in there (trying, catching) which seem odd.

src/java.base/share/classes/jdk/internal/classfile/CodeBuilder.java line 613:

> 611:     }
> 612: 
> 613:     default CodeBuilder labelBinding(Label label) {

Maybe just `bind` or `bindLabel` ?

src/java.base/share/classes/jdk/internal/classfile/CodeBuilder.java line 1371:

> 1369:     }
> 1370: 
> 1371:     default CodeBuilder tableswitch(Label defaultTarget, List<SwitchCase> cases) {

`switch` seems the one instruction for which an high-level variant (like `trying`) could be useful, as generating code for that can be quite painful.

src/java.base/share/classes/jdk/internal/classfile/FieldTransform.java line 92:

> 90:      * @return the field transform
> 91:      */
> 92:     static FieldTransform dropping(Predicate<FieldElement> filter) {

Could this be a more general static generic method on ClassfileTransform? (but I see CodeTransform doesn't have it - not sure if that's deliberate).

src/java.base/share/classes/jdk/internal/classfile/Opcode.java line 39:

> 37:  */
> 38: public enum Opcode {
> 39:     NOP(Classfile.NOP, 1, Kind.NOP),

This also duplicates the constants in classfile...

src/java.base/share/classes/jdk/internal/classfile/TypeAnnotation.java line 75:

> 73:      * The kind of target on which the annotation appears.
> 74:      */
> 75:     public enum TargetType {

My IDE says this enum is not being used. I tend to believe it, since the TargetInfo sealed interface also seems to model the same thing?

src/java.base/share/classes/jdk/internal/classfile/TypeAnnotation.java line 577:

> 575: 
> 576:     /**
> 577:      * type_path.path.

The javadoc in this class seems off

src/java.base/share/classes/jdk/internal/classfile/TypeAnnotation.java line 617:

> 615:         }
> 616: 
> 617:         public static final TypePathComponent ARRAY = new UnboundAttribute.TypePathComponentImpl(Kind.ARRAY, 0);

`public static final` is redundant here (it's an interface) - please check these (I've seen others). E.g. all `public` modifier for types nested in interfaces are redundant as well.

src/java.base/share/classes/jdk/internal/classfile/TypeAnnotation.java line 641:

> 639:         int typeArgumentIndex();
> 640: 
> 641:         static TypePathComponent of(int typePathKind, int typeArgumentIndex) {

Should this take a `Kind` instead of an `int`?

src/java.base/share/classes/jdk/internal/classfile/attribute/SignatureAttribute.java line 66:

> 64: 
> 65:     /**
> 66:      * Parse the siganture as a method signature.

typo here `siganture` - check the entire class

src/java.base/share/classes/jdk/internal/classfile/package-info.java line 39:

> 37:  * <p>
> 38:  * {@snippet lang=java :
> 39:  * ClassModel cm = ClassModel.of(bytes);

There are several references to `ClassModel::of` (here and elsewhere), but this seems to have been moved to `ClassFile::parse`

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

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

From mcimadamore at openjdk.org  Fri Feb  3 18:42:15 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 3 Feb 2023 18:42:15 GMT
Subject: RFR: 8294982: Implementation of Classfile API [v12]
In-Reply-To: <c022hrWNEHW76nhP_sXTQXCTjtL8jjM8r_yYv0IvbPI=.2a9cfbae-2fef-4cdb-8189-b869b1513fef@github.com>
References: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
 <Q4VeZ2yWAg85FqUDJa5hYq3jHty5H547gD0H-x3oIq0=.58d463a4-237a-4fee-bd0f-83262d49522a@github.com>
 <c022hrWNEHW76nhP_sXTQXCTjtL8jjM8r_yYv0IvbPI=.2a9cfbae-2fef-4cdb-8189-b869b1513fef@github.com>
Message-ID: <2dfIIfnZwgc-wezRVH81l9b5VjLjP02k7PjU64wjAww=.5c9e7ba6-4254-46cd-a6c0-553dcea7dc3b@github.com>

On Fri, 3 Feb 2023 17:46:32 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Classfile API moved under jdk.internal.classfile package
>
> src/java.base/share/classes/jdk/internal/classfile/Classfile.java line 346:
> 
>> 344:     public static final int MAGIC_NUMBER = 0xCAFEBABE;
>> 345: 
>> 346:     public static final int NOP             = 0;
> 
> Not sure how I feel about the constants being here. It seems to me that they can be moved to more appropriate places - e.g. Instructor, TypeAnnotation (for the TAT ones), ConstantPool (for the TAG ones).
> 
> The classfile versions, OTOH, do seem to belong here.

Actually, we also have a ClassfileVersion class, so that could be a better place for version numbers?

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

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

From rhalade at openjdk.org  Fri Feb  3 19:15:51 2023
From: rhalade at openjdk.org (Rajan Halade)
Date: Fri, 3 Feb 2023 19:15:51 GMT
Subject: RFR: JDK-8299994: java/security/Policy/Root/Root.java fails when
 home directory is read-only [v5]
In-Reply-To: <1bRlAqwPrUsxVheBscnkECVvkbSVN6rDL0C8Hl-CNHA=.8ffc3074-f047-4054-bac6-060e1c3f89ce@github.com>
References: <qIGOmJu4rLPxuoDW-zteCD-5kapxMWxc2k6ra3kgXpA=.64cb7150-e0d1-4f6e-82ae-3641c0f1d772@github.com>
 <1bRlAqwPrUsxVheBscnkECVvkbSVN6rDL0C8Hl-CNHA=.8ffc3074-f047-4054-bac6-060e1c3f89ce@github.com>
Message-ID: <qquZHn9vCf8C8UwfVgzMZYNyK1SccVfN1sf6HTibTFI=.d710f437-2edb-46f4-8bc9-9196118d1d34@github.com>

On Fri, 3 Feb 2023 00:41:29 GMT, Bill Huang <bhuang at openjdk.org> wrote:

>> Root.java is changed to a manual test because it requires test to be run with the root user privilege, and it requires to modify the user policy file in the home director.
>
> Bill Huang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Exclude Windows.

Marked as reviewed by rhalade (Reviewer).

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

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

From bhuang at openjdk.org  Fri Feb  3 19:22:00 2023
From: bhuang at openjdk.org (Bill Huang)
Date: Fri, 3 Feb 2023 19:22:00 GMT
Subject: Integrated: JDK-8299994: java/security/Policy/Root/Root.java fails
 when home directory is read-only
In-Reply-To: <qIGOmJu4rLPxuoDW-zteCD-5kapxMWxc2k6ra3kgXpA=.64cb7150-e0d1-4f6e-82ae-3641c0f1d772@github.com>
References: <qIGOmJu4rLPxuoDW-zteCD-5kapxMWxc2k6ra3kgXpA=.64cb7150-e0d1-4f6e-82ae-3641c0f1d772@github.com>
Message-ID: <Dy0-QBlGXcQRPzw_pvVgQhYO_hpqAokIi4EZusXhA2s=.36f30dd5-f5f7-4450-96b9-3948c7d08169@github.com>

On Tue, 31 Jan 2023 22:35:21 GMT, Bill Huang <bhuang at openjdk.org> wrote:

> Root.java is changed to a manual test because it requires test to be run with the root user privilege, and it requires to modify the user policy file in the home director.

This pull request has now been integrated.

Changeset: 20579e48
Author:    Bill Huang <bhuang at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/20579e48cf598e890aa35c5518ec8d0594f45385
Stats:     41 lines in 3 files changed: 37 ins; 1 del; 3 mod

8299994: java/security/Policy/Root/Root.java fails when home directory is read-only

Reviewed-by: rhalade

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

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

From jcking at openjdk.org  Fri Feb  3 19:56:46 2023
From: jcking at openjdk.org (Justin King)
Date: Fri, 3 Feb 2023 19:56:46 GMT
Subject: RFR: JDK-8301621: libzip should use pread instead of lseek+read
Message-ID: <pjSF1ED9D3FXjCFeqz2MRllCf0UT9suWaYa4O7kFeCM=.d16583a7-2c82-46c2-aaf1-2102c8978f2b@github.com>

Avoid using `lseek` + `read` in favor of `pread`. For Windows, we can do the same thing by using `OVERLAPPED`, as we are in synchronous mode we can use `Offset` and `OffsetHigh` to achieve the same thing.

Additionally I updated open to use `O_CLOEXEC` when available, as that really should be used.

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

Commit messages:
 - Avoid extra seek syscall in libzip while reading

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

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

From darcy at openjdk.org  Fri Feb  3 21:04:15 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 3 Feb 2023 21:04:15 GMT
Subject: RFR: JDK-8301396: Port fdlibm expm1 to Java [v2]
In-Reply-To: <U3Jo6dH5rPBRmSVceetCxwisBbTPlaHshGCP2zL9kD0=.1d76ebf0-e729-4066-b9b6-46e06b350eb3@github.com>
References: <U3Jo6dH5rPBRmSVceetCxwisBbTPlaHshGCP2zL9kD0=.1d76ebf0-e729-4066-b9b6-46e06b350eb3@github.com>
Message-ID: <Xwful8ptiuz7_NWCqmth5VAGSRqYpHnI9ZfRdntxnog=.0276afad-1dc5-4c1b-8b37-85e093c813f3@github.com>

> Next on the FDLIBM C -> Java port, expm1.
> Coming soon, hyperbolic transcendentals (sinh, cosh, tanh)!
> 
> For expm1, the C vs transliteration port show the usual kind of differences, beside formatting of the constants, the use of the __HI macro on the left-hand side needs to be replaced by a method call and an assignment, as seen below:
> 
> 
> < 
> < #include "fdlibm.h"
> < 
> < #ifdef __STDC__
> < static const double
> < #else
> < static double
> < #endif
> < one             = 1.0,
> < huge            = 1.0e+300,
> < tiny            = 1.0e-300,
> < o_threshold     = 7.09782712893383973096e+02,/* 0x40862E42, 0xFEFA39EF */
> < ln2_hi          = 6.93147180369123816490e-01,/* 0x3fe62e42, 0xfee00000 */
> < ln2_lo          = 1.90821492927058770002e-10,/* 0x3dea39ef, 0x35793c76 */
> < invln2          = 1.44269504088896338700e+00,/* 0x3ff71547, 0x652b82fe */
> ---
>>     static class Expm1 {
>>         private static final double one             = 1.0;
>>         private static final double huge            = 1.0e+300;
>>         private static final double tiny            = 1.0e-300;
>>         private static final double o_threshold     = 7.09782712893383973096e+02; /* 0x40862E42, 0xFEFA39EF */
>>         private static final double ln2_hi          = 6.93147180369123816490e-01; /* 0x3fe62e42, 0xfee00000 */
>>         private static final double ln2_lo          = 1.90821492927058770002e-10; /* 0x3dea39ef, 0x35793c76 */
>>         private static final double invln2          = 1.44269504088896338700e+00; /* 0x3ff71547, 0x652b82fe */
> 111,115c104,108
> < Q1  =  -3.33333333333331316428e-02, /* BFA11111 111110F4 */
> < Q2  =   1.58730158725481460165e-03, /* 3F5A01A0 19FE5585 */
> < Q3  =  -7.93650757867487942473e-05, /* BF14CE19 9EAADBB7 */
> < Q4  =   4.00821782732936239552e-06, /* 3ED0CFCA 86E65239 */
> < Q5  =  -2.01099218183624371326e-07; /* BE8AFDB7 6E09C32D */
> ---
>>         private static final double Q1  =  -3.33333333333331316428e-02; /* BFA11111 111110F4 */
>>         private static final double Q2  =   1.58730158725481460165e-03; /* 3F5A01A0 19FE5585 */
>>         private static final double Q3  =  -7.93650757867487942473e-05; /* BF14CE19 9EAADBB7 */
>>         private static final double Q4  =   4.00821782732936239552e-06; /* 3ED0CFCA 86E65239 */
>>         private static final double Q5  =  -2.01099218183624371326e-07; /* BE8AFDB7 6E09C32D */
> 117,123c110
> < #ifdef __STDC__
> <         double expm1(double x)
> < #else
> <         double expm1(x)
> <         double x;
> < #endif
> < {
> ---
>>         static double compute(double x) {
> 126c113
> <         unsigned hx;
> ---
>>             /*unsigned*/ int hx;
> 157c144
> <                 k  = invln2*x+((xsb==0)?0.5:-0.5);
> ---
>>                     k  = (int)(invln2*x+((xsb==0)?0.5:-0.5));
> 188c175
> <                 __HI(y) += (k<<20);     /* add k to y's exponent */
> ---
>>                     y = __HI(y,  __HI(y) + (k<<20));     /* add k to y's exponent */
> 193c180
> <                 __HI(t) = 0x3ff00000 - (0x200000>>k);  /* t=1-2^-k */
> ---
>>                     t = __HI(t, 0x3ff00000 - (0x200000>>k));  /* t=1-2^-k */
> 195c182
> <                 __HI(y) += (k<<20);     /* add k to y's exponent */
> ---
>>                     y = __HI(y, __HI(y) + (k<<20));     /* add k to y's exponent */
> 197c184
> <                 __HI(t)  = ((0x3ff-k)<<20);     /* 2^-k */
> ---
>>                     t = __HI(t, ((0x3ff-k)<<20));     /* 2^-k */
> 200c187
> <                 __HI(y) += (k<<20);     /* add k to y's exponent */
> ---
>>                     y = __HI(y, __HI(y) + (k<<20));     /* add k to y's exponent */
> 205c192
> < 
> ---
>>     }
> 
> 
> When comparing the transliteration port and the more idiomatic port, there were no surprising or notable differences:
> 
> 
> $ diff -w Expm1.translit.java Expm1.fdlibm.java  
> 99,102c99,102
> <         private static final double o_threshold     = 7.09782712893383973096e+02; /* 0x40862E42, 0xFEFA39EF */
> <         private static final double ln2_hi          = 6.93147180369123816490e-01; /* 0x3fe62e42, 0xfee00000 */
> <         private static final double ln2_lo          = 1.90821492927058770002e-10; /* 0x3dea39ef, 0x35793c76 */
> <         private static final double invln2          = 1.44269504088896338700e+00; /* 0x3ff71547, 0x652b82fe */
> ---
>>         private static final double o_threshold =  0x1.62e42fefa39efp9;   //  7.09782712893383973096e+02
>>         private static final double ln2_hi      =  0x1.62e42feep-1;       //  6.93147180369123816490e-01
>>         private static final double ln2_lo      =  0x1.a39ef35793c76p-33; //  1.90821492927058770002e-10
>>         private static final double invln2      =  0x1.71547652b82fep0;   //  1.44269504088896338700e+00
> 104,108c104,108
> <         private static final double Q1  =  -3.33333333333331316428e-02; /* BFA11111 111110F4 */
> <         private static final double Q2  =   1.58730158725481460165e-03; /* 3F5A01A0 19FE5585 */
> <         private static final double Q3  =  -7.93650757867487942473e-05; /* BF14CE19 9EAADBB7 */
> <         private static final double Q4  =   4.00821782732936239552e-06; /* 3ED0CFCA 86E65239 */
> <         private static final double Q5  =  -2.01099218183624371326e-07; /* BE8AFDB7 6E09C32D */
> ---
>>         private static final double Q1          = -0x1.11111111110f4p-5;  // -3.33333333333331316428e-02
>>         private static final double Q2          =  0x1.a01a019fe5585p-10; //  1.58730158725481460165e-03
>>         private static final double Q3          = -0x1.4ce199eaadbb7p-14; // -7.93650757867487942473e-05
>>         private static final double Q4          =  0x1.0cfca86e65239p-18; //  4.00821782732936239552e-06
>>         private static final double Q5          = -0x1.afdb76e09c32dp-23; // -2.01099218183624371326e-07
> 116,118c116,118
> <             xsb = hx&0x80000000;            /* sign bit of x */
> <             if(xsb==0) y=x; else y= -x;     /* y = |x| */
> <             hx &= 0x7fffffff;               /* high word of |x| */
> ---
>>             xsb = hx & 0x8000_0000;            /* sign bit of x */
>>             y = Math.abs(x);
>>             hx &= 0x7fff_ffff;               /* high word of |x| */
> 121,124c121,124
> <             if(hx >= 0x4043687A) {                  /* if |x|>=56*ln2 */
> <                 if(hx >= 0x40862E42) {              /* if |x|>=709.78... */
> <                     if(hx>=0x7ff00000) {
> <                         if(((hx&0xfffff)|__LO(x))!=0)
> ---
>>             if (hx >= 0x4043_687A) {                  /* if |x| >= 56*ln2 */
>>                 if (hx >= 0x4086_2E42) {              /* if |x| >= 709.78... */
>>                     if (hx >= 0x7ff_00000) {
>>                         if (((hx & 0xf_ffff) | __LO(x)) != 0) {
> 126c126,131
> <                         else return (xsb==0)? x:-1.0;/* exp(+-inf)={inf,-1} */
> ---
>>                         } else {
>>                             return (xsb == 0)? x : -1.0; /* exp(+-inf)={inf,-1} */
>>                         }
>>                     }
>>                     if (x > o_threshold) {
>>                         return huge*huge; /* overflow */
> 128d132
> <                     if(x > o_threshold) return huge*huge; /* overflow */
> 131c135
> <                     if(x+tiny<0.0)          /* raise inexact */
> ---
>>                     if (x + tiny < 0.0) {         /* raise inexact */
> 134a139
>>             }
> 137,142c142,152
> <             if(hx > 0x3fd62e42) {           /* if  |x| > 0.5 ln2 */
> <                 if(hx < 0x3FF0A2B2) {       /* and |x| < 1.5 ln2 */
> <                     if(xsb==0)
> <                         {hi = x - ln2_hi; lo =  ln2_lo;  k =  1;}
> <                     else
> <                         {hi = x + ln2_hi; lo = -ln2_lo;  k = -1;}
> ---
>>             if (hx > 0x3fd6_2e42) {           /* if  |x| > 0.5 ln2 */
>>                 if (hx < 0x3FF0_A2B2) {       /* and |x| < 1.5 ln2 */
>>                     if (xsb == 0) {
>>                         hi = x - ln2_hi;
>>                         lo =  ln2_lo;
>>                         k =  1;}
>>                     else {
>>                         hi = x + ln2_hi;
>>                         lo = -ln2_lo;
>>                         k = -1;
>>                     }
> 151,152c161
> <             }
> <             else if(hx < 0x3c900000) {      /* when |x|<2**-54, return x */
> ---
>>             } else if (hx < 0x3c90_0000) {      /* when |x|<2**-54, return x */
> 154a164,165
>>             } else {
>>                 k = 0;
> 156d166
> <             else k = 0;
> 164,165c174,176
> <             if(k==0) return x - (x*e-hxs);          /* c is 0 */
> <             else {
> ---
>>             if (k == 0) {
>>                 return x - (x*e - hxs);          /* c is 0 */
>>             } else {
> 168c179,181
> <                 if(k== -1) return 0.5*(x-e)-0.5;
> ---
>>                 if (k == -1) {
>>                     return 0.5*(x - e) - 0.5;
>>                 }
> 170,171c183,187
> <                     if(x < -0.25) return -2.0*(e-(x+0.5));
> <                     else          return  one+2.0*(x-e);
> ---
>>                     if(x < -0.25) {
>>                         return -2.0*(e - (x + 0.5));
>>                     } else {
>>                         return  one + 2.0*(x - e);
>>                     }
> 180c196
> <                     t = __HI(t, 0x3ff00000 - (0x200000>>k));  /* t=1-2^-k */
> ---
>>                     t = __HI(t, 0x3ff0_0000 - (0x2_00000 >> k));  /* t=1-2^-k */

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

  Respond to review feedback; use // comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12394/files
  - new: https://git.openjdk.org/jdk/pull/12394/files/203092fe..5c065d3d

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

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

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

From darcy at openjdk.org  Fri Feb  3 21:05:56 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 3 Feb 2023 21:05:56 GMT
Subject: RFR: JDK-8301396: Port fdlibm expm1 to Java [v2]
In-Reply-To: <_DYpJjykAbt3J79RdcCo1px6D7XJY5fdx5f_s9B_gZc=.ad78f65d-8f87-43c2-a301-6401391116d3@github.com>
References: <U3Jo6dH5rPBRmSVceetCxwisBbTPlaHshGCP2zL9kD0=.1d76ebf0-e729-4066-b9b6-46e06b350eb3@github.com>
 <_DYpJjykAbt3J79RdcCo1px6D7XJY5fdx5f_s9B_gZc=.ad78f65d-8f87-43c2-a301-6401391116d3@github.com>
Message-ID: <X55OqYnUZkA3Mpj08zmL5YJgAh1eQwdiwx_3lWEmnEc=.3bad0888-9634-4f4b-9adc-9449377e5f6c@github.com>

On Fri, 3 Feb 2023 07:03:51 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

>> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Respond to review feedback; use // comments
>
> src/java.base/share/classes/java/lang/FdLibm.java line 1147:
> 
>> 1145:                     lo = t*ln2_lo;
>> 1146:                 }
>> 1147:                 x  = hi - lo;
> 
> Suggestion:
> 
>                 x = hi - lo;

> 

Thanks for the close reading; pushed those suggestions along with some others.

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

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

From bpb at openjdk.org  Fri Feb  3 23:58:51 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 3 Feb 2023 23:58:51 GMT
Subject: RFR: JDK-8301396: Port fdlibm expm1 to Java [v2]
In-Reply-To: <Xwful8ptiuz7_NWCqmth5VAGSRqYpHnI9ZfRdntxnog=.0276afad-1dc5-4c1b-8b37-85e093c813f3@github.com>
References: <U3Jo6dH5rPBRmSVceetCxwisBbTPlaHshGCP2zL9kD0=.1d76ebf0-e729-4066-b9b6-46e06b350eb3@github.com>
 <Xwful8ptiuz7_NWCqmth5VAGSRqYpHnI9ZfRdntxnog=.0276afad-1dc5-4c1b-8b37-85e093c813f3@github.com>
Message-ID: <FDgjAgUAr1k2K3GE7-3COgxNzJWWH91sOovNhFc4w24=.4bda4b58-6d8d-4494-9abb-d0cb266ceccb@github.com>

On Fri, 3 Feb 2023 21:04:15 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Next on the FDLIBM C -> Java port, expm1.
>> Coming soon, hyperbolic transcendentals (sinh, cosh, tanh)!
>> 
>> For expm1, the C vs transliteration port show the usual kind of differences, beside formatting of the constants, the use of the __HI macro on the left-hand side needs to be replaced by a method call and an assignment, as seen below:
>> 
>> 
>> < 
>> < #include "fdlibm.h"
>> < 
>> < #ifdef __STDC__
>> < static const double
>> < #else
>> < static double
>> < #endif
>> < one             = 1.0,
>> < huge            = 1.0e+300,
>> < tiny            = 1.0e-300,
>> < o_threshold     = 7.09782712893383973096e+02,/* 0x40862E42, 0xFEFA39EF */
>> < ln2_hi          = 6.93147180369123816490e-01,/* 0x3fe62e42, 0xfee00000 */
>> < ln2_lo          = 1.90821492927058770002e-10,/* 0x3dea39ef, 0x35793c76 */
>> < invln2          = 1.44269504088896338700e+00,/* 0x3ff71547, 0x652b82fe */
>> ---
>>>     static class Expm1 {
>>>         private static final double one             = 1.0;
>>>         private static final double huge            = 1.0e+300;
>>>         private static final double tiny            = 1.0e-300;
>>>         private static final double o_threshold     = 7.09782712893383973096e+02; /* 0x40862E42, 0xFEFA39EF */
>>>         private static final double ln2_hi          = 6.93147180369123816490e-01; /* 0x3fe62e42, 0xfee00000 */
>>>         private static final double ln2_lo          = 1.90821492927058770002e-10; /* 0x3dea39ef, 0x35793c76 */
>>>         private static final double invln2          = 1.44269504088896338700e+00; /* 0x3ff71547, 0x652b82fe */
>> 111,115c104,108
>> < Q1  =  -3.33333333333331316428e-02, /* BFA11111 111110F4 */
>> < Q2  =   1.58730158725481460165e-03, /* 3F5A01A0 19FE5585 */
>> < Q3  =  -7.93650757867487942473e-05, /* BF14CE19 9EAADBB7 */
>> < Q4  =   4.00821782732936239552e-06, /* 3ED0CFCA 86E65239 */
>> < Q5  =  -2.01099218183624371326e-07; /* BE8AFDB7 6E09C32D */
>> ---
>>>         private static final double Q1  =  -3.33333333333331316428e-02; /* BFA11111 111110F4 */
>>>         private static final double Q2  =   1.58730158725481460165e-03; /* 3F5A01A0 19FE5585 */
>>>         private static final double Q3  =  -7.93650757867487942473e-05; /* BF14CE19 9EAADBB7 */
>>>         private static final double Q4  =   4.00821782732936239552e-06; /* 3ED0CFCA 86E65239 */
>>>         private static final double Q5  =  -2.01099218183624371326e-07; /* BE8AFDB7 6E09C32D */
>> 117,123c110
>> < #ifdef __STDC__
>> <         double expm1(double x)
>> < #else
>> <         double expm1(x)
>> <         double x;
>> < #endif
>> < {
>> ---
>>>         static double compute(double x) {
>> 126c113
>> <         unsigned hx;
>> ---
>>>             /*unsigned*/ int hx;
>> 157c144
>> <                 k  = invln2*x+((xsb==0)?0.5:-0.5);
>> ---
>>>                     k  = (int)(invln2*x+((xsb==0)?0.5:-0.5));
>> 188c175
>> <                 __HI(y) += (k<<20);     /* add k to y's exponent */
>> ---
>>>                     y = __HI(y,  __HI(y) + (k<<20));     /* add k to y's exponent */
>> 193c180
>> <                 __HI(t) = 0x3ff00000 - (0x200000>>k);  /* t=1-2^-k */
>> ---
>>>                     t = __HI(t, 0x3ff00000 - (0x200000>>k));  /* t=1-2^-k */
>> 195c182
>> <                 __HI(y) += (k<<20);     /* add k to y's exponent */
>> ---
>>>                     y = __HI(y, __HI(y) + (k<<20));     /* add k to y's exponent */
>> 197c184
>> <                 __HI(t)  = ((0x3ff-k)<<20);     /* 2^-k */
>> ---
>>>                     t = __HI(t, ((0x3ff-k)<<20));     /* 2^-k */
>> 200c187
>> <                 __HI(y) += (k<<20);     /* add k to y's exponent */
>> ---
>>>                     y = __HI(y, __HI(y) + (k<<20));     /* add k to y's exponent */
>> 205c192
>> < 
>> ---
>>>     }
>> 
>> 
>> When comparing the transliteration port and the more idiomatic port, there were no surprising or notable differences:
>> 
>> 
>> $ diff -w Expm1.translit.java Expm1.fdlibm.java  
>> 99,102c99,102
>> <         private static final double o_threshold     = 7.09782712893383973096e+02; /* 0x40862E42, 0xFEFA39EF */
>> <         private static final double ln2_hi          = 6.93147180369123816490e-01; /* 0x3fe62e42, 0xfee00000 */
>> <         private static final double ln2_lo          = 1.90821492927058770002e-10; /* 0x3dea39ef, 0x35793c76 */
>> <         private static final double invln2          = 1.44269504088896338700e+00; /* 0x3ff71547, 0x652b82fe */
>> ---
>>>         private static final double o_threshold =  0x1.62e42fefa39efp9;   //  7.09782712893383973096e+02
>>>         private static final double ln2_hi      =  0x1.62e42feep-1;       //  6.93147180369123816490e-01
>>>         private static final double ln2_lo      =  0x1.a39ef35793c76p-33; //  1.90821492927058770002e-10
>>>         private static final double invln2      =  0x1.71547652b82fep0;   //  1.44269504088896338700e+00
>> 104,108c104,108
>> <         private static final double Q1  =  -3.33333333333331316428e-02; /* BFA11111 111110F4 */
>> <         private static final double Q2  =   1.58730158725481460165e-03; /* 3F5A01A0 19FE5585 */
>> <         private static final double Q3  =  -7.93650757867487942473e-05; /* BF14CE19 9EAADBB7 */
>> <         private static final double Q4  =   4.00821782732936239552e-06; /* 3ED0CFCA 86E65239 */
>> <         private static final double Q5  =  -2.01099218183624371326e-07; /* BE8AFDB7 6E09C32D */
>> ---
>>>         private static final double Q1          = -0x1.11111111110f4p-5;  // -3.33333333333331316428e-02
>>>         private static final double Q2          =  0x1.a01a019fe5585p-10; //  1.58730158725481460165e-03
>>>         private static final double Q3          = -0x1.4ce199eaadbb7p-14; // -7.93650757867487942473e-05
>>>         private static final double Q4          =  0x1.0cfca86e65239p-18; //  4.00821782732936239552e-06
>>>         private static final double Q5          = -0x1.afdb76e09c32dp-23; // -2.01099218183624371326e-07
>> 116,118c116,118
>> <             xsb = hx&0x80000000;            /* sign bit of x */
>> <             if(xsb==0) y=x; else y= -x;     /* y = |x| */
>> <             hx &= 0x7fffffff;               /* high word of |x| */
>> ---
>>>             xsb = hx & 0x8000_0000;            /* sign bit of x */
>>>             y = Math.abs(x);
>>>             hx &= 0x7fff_ffff;               /* high word of |x| */
>> 121,124c121,124
>> <             if(hx >= 0x4043687A) {                  /* if |x|>=56*ln2 */
>> <                 if(hx >= 0x40862E42) {              /* if |x|>=709.78... */
>> <                     if(hx>=0x7ff00000) {
>> <                         if(((hx&0xfffff)|__LO(x))!=0)
>> ---
>>>             if (hx >= 0x4043_687A) {                  /* if |x| >= 56*ln2 */
>>>                 if (hx >= 0x4086_2E42) {              /* if |x| >= 709.78... */
>>>                     if (hx >= 0x7ff_00000) {
>>>                         if (((hx & 0xf_ffff) | __LO(x)) != 0) {
>> 126c126,131
>> <                         else return (xsb==0)? x:-1.0;/* exp(+-inf)={inf,-1} */
>> ---
>>>                         } else {
>>>                             return (xsb == 0)? x : -1.0; /* exp(+-inf)={inf,-1} */
>>>                         }
>>>                     }
>>>                     if (x > o_threshold) {
>>>                         return huge*huge; /* overflow */
>> 128d132
>> <                     if(x > o_threshold) return huge*huge; /* overflow */
>> 131c135
>> <                     if(x+tiny<0.0)          /* raise inexact */
>> ---
>>>                     if (x + tiny < 0.0) {         /* raise inexact */
>> 134a139
>>>             }
>> 137,142c142,152
>> <             if(hx > 0x3fd62e42) {           /* if  |x| > 0.5 ln2 */
>> <                 if(hx < 0x3FF0A2B2) {       /* and |x| < 1.5 ln2 */
>> <                     if(xsb==0)
>> <                         {hi = x - ln2_hi; lo =  ln2_lo;  k =  1;}
>> <                     else
>> <                         {hi = x + ln2_hi; lo = -ln2_lo;  k = -1;}
>> ---
>>>             if (hx > 0x3fd6_2e42) {           /* if  |x| > 0.5 ln2 */
>>>                 if (hx < 0x3FF0_A2B2) {       /* and |x| < 1.5 ln2 */
>>>                     if (xsb == 0) {
>>>                         hi = x - ln2_hi;
>>>                         lo =  ln2_lo;
>>>                         k =  1;}
>>>                     else {
>>>                         hi = x + ln2_hi;
>>>                         lo = -ln2_lo;
>>>                         k = -1;
>>>                     }
>> 151,152c161
>> <             }
>> <             else if(hx < 0x3c900000) {      /* when |x|<2**-54, return x */
>> ---
>>>             } else if (hx < 0x3c90_0000) {      /* when |x|<2**-54, return x */
>> 154a164,165
>>>             } else {
>>>                 k = 0;
>> 156d166
>> <             else k = 0;
>> 164,165c174,176
>> <             if(k==0) return x - (x*e-hxs);          /* c is 0 */
>> <             else {
>> ---
>>>             if (k == 0) {
>>>                 return x - (x*e - hxs);          /* c is 0 */
>>>             } else {
>> 168c179,181
>> <                 if(k== -1) return 0.5*(x-e)-0.5;
>> ---
>>>                 if (k == -1) {
>>>                     return 0.5*(x - e) - 0.5;
>>>                 }
>> 170,171c183,187
>> <                     if(x < -0.25) return -2.0*(e-(x+0.5));
>> <                     else          return  one+2.0*(x-e);
>> ---
>>>                     if(x < -0.25) {
>>>                         return -2.0*(e - (x + 0.5));
>>>                     } else {
>>>                         return  one + 2.0*(x - e);
>>>                     }
>> 180c196
>> <                     t = __HI(t, 0x3ff00000 - (0x200000>>k));  /* t=1-2^-k */
>> ---
>>>                     t = __HI(t, 0x3ff0_0000 - (0x2_00000 >> k));  /* t=1-2^-k */
>
> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Respond to review feedback; use // comments

Looks fine.

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

Marked as reviewed by bpb (Reviewer).

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

From darcy at openjdk.org  Sat Feb  4 00:52:04 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Sat, 4 Feb 2023 00:52:04 GMT
Subject: Integrated: JDK-8301396: Port fdlibm expm1 to Java
In-Reply-To: <U3Jo6dH5rPBRmSVceetCxwisBbTPlaHshGCP2zL9kD0=.1d76ebf0-e729-4066-b9b6-46e06b350eb3@github.com>
References: <U3Jo6dH5rPBRmSVceetCxwisBbTPlaHshGCP2zL9kD0=.1d76ebf0-e729-4066-b9b6-46e06b350eb3@github.com>
Message-ID: <TU-9Hcq6q7i4O-6QYue0fB-4xnfq_IGe7aFIkkKmMtY=.8d9738c5-eae6-4e5c-9c75-2d8c9e399271@github.com>

On Thu, 2 Feb 2023 22:18:32 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Next on the FDLIBM C -> Java port, expm1.
> Coming soon, hyperbolic transcendentals (sinh, cosh, tanh)!
> 
> For expm1, the C vs transliteration port show the usual kind of differences, beside formatting of the constants, the use of the __HI macro on the left-hand side needs to be replaced by a method call and an assignment, as seen below:
> 
> 
> < 
> < #include "fdlibm.h"
> < 
> < #ifdef __STDC__
> < static const double
> < #else
> < static double
> < #endif
> < one             = 1.0,
> < huge            = 1.0e+300,
> < tiny            = 1.0e-300,
> < o_threshold     = 7.09782712893383973096e+02,/* 0x40862E42, 0xFEFA39EF */
> < ln2_hi          = 6.93147180369123816490e-01,/* 0x3fe62e42, 0xfee00000 */
> < ln2_lo          = 1.90821492927058770002e-10,/* 0x3dea39ef, 0x35793c76 */
> < invln2          = 1.44269504088896338700e+00,/* 0x3ff71547, 0x652b82fe */
> ---
>>     static class Expm1 {
>>         private static final double one             = 1.0;
>>         private static final double huge            = 1.0e+300;
>>         private static final double tiny            = 1.0e-300;
>>         private static final double o_threshold     = 7.09782712893383973096e+02; /* 0x40862E42, 0xFEFA39EF */
>>         private static final double ln2_hi          = 6.93147180369123816490e-01; /* 0x3fe62e42, 0xfee00000 */
>>         private static final double ln2_lo          = 1.90821492927058770002e-10; /* 0x3dea39ef, 0x35793c76 */
>>         private static final double invln2          = 1.44269504088896338700e+00; /* 0x3ff71547, 0x652b82fe */
> 111,115c104,108
> < Q1  =  -3.33333333333331316428e-02, /* BFA11111 111110F4 */
> < Q2  =   1.58730158725481460165e-03, /* 3F5A01A0 19FE5585 */
> < Q3  =  -7.93650757867487942473e-05, /* BF14CE19 9EAADBB7 */
> < Q4  =   4.00821782732936239552e-06, /* 3ED0CFCA 86E65239 */
> < Q5  =  -2.01099218183624371326e-07; /* BE8AFDB7 6E09C32D */
> ---
>>         private static final double Q1  =  -3.33333333333331316428e-02; /* BFA11111 111110F4 */
>>         private static final double Q2  =   1.58730158725481460165e-03; /* 3F5A01A0 19FE5585 */
>>         private static final double Q3  =  -7.93650757867487942473e-05; /* BF14CE19 9EAADBB7 */
>>         private static final double Q4  =   4.00821782732936239552e-06; /* 3ED0CFCA 86E65239 */
>>         private static final double Q5  =  -2.01099218183624371326e-07; /* BE8AFDB7 6E09C32D */
> 117,123c110
> < #ifdef __STDC__
> <         double expm1(double x)
> < #else
> <         double expm1(x)
> <         double x;
> < #endif
> < {
> ---
>>         static double compute(double x) {
> 126c113
> <         unsigned hx;
> ---
>>             /*unsigned*/ int hx;
> 157c144
> <                 k  = invln2*x+((xsb==0)?0.5:-0.5);
> ---
>>                     k  = (int)(invln2*x+((xsb==0)?0.5:-0.5));
> 188c175
> <                 __HI(y) += (k<<20);     /* add k to y's exponent */
> ---
>>                     y = __HI(y,  __HI(y) + (k<<20));     /* add k to y's exponent */
> 193c180
> <                 __HI(t) = 0x3ff00000 - (0x200000>>k);  /* t=1-2^-k */
> ---
>>                     t = __HI(t, 0x3ff00000 - (0x200000>>k));  /* t=1-2^-k */
> 195c182
> <                 __HI(y) += (k<<20);     /* add k to y's exponent */
> ---
>>                     y = __HI(y, __HI(y) + (k<<20));     /* add k to y's exponent */
> 197c184
> <                 __HI(t)  = ((0x3ff-k)<<20);     /* 2^-k */
> ---
>>                     t = __HI(t, ((0x3ff-k)<<20));     /* 2^-k */
> 200c187
> <                 __HI(y) += (k<<20);     /* add k to y's exponent */
> ---
>>                     y = __HI(y, __HI(y) + (k<<20));     /* add k to y's exponent */
> 205c192
> < 
> ---
>>     }
> 
> 
> When comparing the transliteration port and the more idiomatic port, there were no surprising or notable differences:
> 
> 
> $ diff -w Expm1.translit.java Expm1.fdlibm.java  
> 99,102c99,102
> <         private static final double o_threshold     = 7.09782712893383973096e+02; /* 0x40862E42, 0xFEFA39EF */
> <         private static final double ln2_hi          = 6.93147180369123816490e-01; /* 0x3fe62e42, 0xfee00000 */
> <         private static final double ln2_lo          = 1.90821492927058770002e-10; /* 0x3dea39ef, 0x35793c76 */
> <         private static final double invln2          = 1.44269504088896338700e+00; /* 0x3ff71547, 0x652b82fe */
> ---
>>         private static final double o_threshold =  0x1.62e42fefa39efp9;   //  7.09782712893383973096e+02
>>         private static final double ln2_hi      =  0x1.62e42feep-1;       //  6.93147180369123816490e-01
>>         private static final double ln2_lo      =  0x1.a39ef35793c76p-33; //  1.90821492927058770002e-10
>>         private static final double invln2      =  0x1.71547652b82fep0;   //  1.44269504088896338700e+00
> 104,108c104,108
> <         private static final double Q1  =  -3.33333333333331316428e-02; /* BFA11111 111110F4 */
> <         private static final double Q2  =   1.58730158725481460165e-03; /* 3F5A01A0 19FE5585 */
> <         private static final double Q3  =  -7.93650757867487942473e-05; /* BF14CE19 9EAADBB7 */
> <         private static final double Q4  =   4.00821782732936239552e-06; /* 3ED0CFCA 86E65239 */
> <         private static final double Q5  =  -2.01099218183624371326e-07; /* BE8AFDB7 6E09C32D */
> ---
>>         private static final double Q1          = -0x1.11111111110f4p-5;  // -3.33333333333331316428e-02
>>         private static final double Q2          =  0x1.a01a019fe5585p-10; //  1.58730158725481460165e-03
>>         private static final double Q3          = -0x1.4ce199eaadbb7p-14; // -7.93650757867487942473e-05
>>         private static final double Q4          =  0x1.0cfca86e65239p-18; //  4.00821782732936239552e-06
>>         private static final double Q5          = -0x1.afdb76e09c32dp-23; // -2.01099218183624371326e-07
> 116,118c116,118
> <             xsb = hx&0x80000000;            /* sign bit of x */
> <             if(xsb==0) y=x; else y= -x;     /* y = |x| */
> <             hx &= 0x7fffffff;               /* high word of |x| */
> ---
>>             xsb = hx & 0x8000_0000;            /* sign bit of x */
>>             y = Math.abs(x);
>>             hx &= 0x7fff_ffff;               /* high word of |x| */
> 121,124c121,124
> <             if(hx >= 0x4043687A) {                  /* if |x|>=56*ln2 */
> <                 if(hx >= 0x40862E42) {              /* if |x|>=709.78... */
> <                     if(hx>=0x7ff00000) {
> <                         if(((hx&0xfffff)|__LO(x))!=0)
> ---
>>             if (hx >= 0x4043_687A) {                  /* if |x| >= 56*ln2 */
>>                 if (hx >= 0x4086_2E42) {              /* if |x| >= 709.78... */
>>                     if (hx >= 0x7ff_00000) {
>>                         if (((hx & 0xf_ffff) | __LO(x)) != 0) {
> 126c126,131
> <                         else return (xsb==0)? x:-1.0;/* exp(+-inf)={inf,-1} */
> ---
>>                         } else {
>>                             return (xsb == 0)? x : -1.0; /* exp(+-inf)={inf,-1} */
>>                         }
>>                     }
>>                     if (x > o_threshold) {
>>                         return huge*huge; /* overflow */
> 128d132
> <                     if(x > o_threshold) return huge*huge; /* overflow */
> 131c135
> <                     if(x+tiny<0.0)          /* raise inexact */
> ---
>>                     if (x + tiny < 0.0) {         /* raise inexact */
> 134a139
>>             }
> 137,142c142,152
> <             if(hx > 0x3fd62e42) {           /* if  |x| > 0.5 ln2 */
> <                 if(hx < 0x3FF0A2B2) {       /* and |x| < 1.5 ln2 */
> <                     if(xsb==0)
> <                         {hi = x - ln2_hi; lo =  ln2_lo;  k =  1;}
> <                     else
> <                         {hi = x + ln2_hi; lo = -ln2_lo;  k = -1;}
> ---
>>             if (hx > 0x3fd6_2e42) {           /* if  |x| > 0.5 ln2 */
>>                 if (hx < 0x3FF0_A2B2) {       /* and |x| < 1.5 ln2 */
>>                     if (xsb == 0) {
>>                         hi = x - ln2_hi;
>>                         lo =  ln2_lo;
>>                         k =  1;}
>>                     else {
>>                         hi = x + ln2_hi;
>>                         lo = -ln2_lo;
>>                         k = -1;
>>                     }
> 151,152c161
> <             }
> <             else if(hx < 0x3c900000) {      /* when |x|<2**-54, return x */
> ---
>>             } else if (hx < 0x3c90_0000) {      /* when |x|<2**-54, return x */
> 154a164,165
>>             } else {
>>                 k = 0;
> 156d166
> <             else k = 0;
> 164,165c174,176
> <             if(k==0) return x - (x*e-hxs);          /* c is 0 */
> <             else {
> ---
>>             if (k == 0) {
>>                 return x - (x*e - hxs);          /* c is 0 */
>>             } else {
> 168c179,181
> <                 if(k== -1) return 0.5*(x-e)-0.5;
> ---
>>                 if (k == -1) {
>>                     return 0.5*(x - e) - 0.5;
>>                 }
> 170,171c183,187
> <                     if(x < -0.25) return -2.0*(e-(x+0.5));
> <                     else          return  one+2.0*(x-e);
> ---
>>                     if(x < -0.25) {
>>                         return -2.0*(e - (x + 0.5));
>>                     } else {
>>                         return  one + 2.0*(x - e);
>>                     }
> 180c196
> <                     t = __HI(t, 0x3ff00000 - (0x200000>>k));  /* t=1-2^-k */
> ---
>>                     t = __HI(t, 0x3ff0_0000 - (0x2_00000 >> k));  /* t=1-2^-k */

This pull request has now been integrated.

Changeset: 34493248
Author:    Joe Darcy <darcy at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/34493248c02102a0f0a85b21e2def8ef534476d8
Stats:     516 lines in 4 files changed: 497 ins; 12 del; 7 mod

8301396: Port fdlibm expm1 to Java

Reviewed-by: bpb

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

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

From tvaleev at openjdk.org  Sat Feb  4 14:30:38 2023
From: tvaleev at openjdk.org (Tagir F. Valeev)
Date: Sat, 4 Feb 2023 14:30:38 GMT
Subject: RFR: 8301226: Add clamp() methods to java.lang.Math and to StrictMath
Message-ID: <c7kJhZvT8oz5hScMxnWI23H7wjCaJ854ajjSRtxBnW4=.3f4e24ca-c608-4541-b80e-cf3452ec6400@github.com>

clamp() methods added to Math and StrictMath

`int clamp(long, int, int)` is somewhat different, as it accepts a `long` value and safely clamps it to an `int` range. Other overloads work with a particular type (long, float and double). Using similar approach in other cases (e.g. `float clamp(double, float, float)`) may cause accidental precision loss even if the value is within range, so I decided to avoid this.

In all cases, `max >= min` precondition should met. For double and float we additionally order `-0.0 < 0.0`, similarly to what Math.max or Double.compare do. In double and float overloads I try to keep at most one arg-check comparison on common path, so the order of checks might look unusual.

For tests, I noticed that tests in java/lang/Math don't use any testing framework (even newer tests), so I somehow mimic the approach of neighbour tests.

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

Commit messages:
 - Line breaks
 - Trailing whitespace removed
 - Copyright added
 - 8301226 Add clamp() methods to java.lang.Math and to StrictMath

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

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

From duke at openjdk.org  Sat Feb  4 15:16:49 2023
From: duke at openjdk.org (Emily)
Date: Sat, 4 Feb 2023 15:16:49 GMT
Subject: RFR: 8301226: Add clamp() methods to java.lang.Math and to
 StrictMath
In-Reply-To: <c7kJhZvT8oz5hScMxnWI23H7wjCaJ854ajjSRtxBnW4=.3f4e24ca-c608-4541-b80e-cf3452ec6400@github.com>
References: <c7kJhZvT8oz5hScMxnWI23H7wjCaJ854ajjSRtxBnW4=.3f4e24ca-c608-4541-b80e-cf3452ec6400@github.com>
Message-ID: <lYoF9NldVE_lziyUpYczocQrZfHcNKangMU1TX5Et08=.b0f6d0d5-4b0e-4c9a-814a-a4c6fc437436@github.com>

On Sat, 4 Feb 2023 13:24:11 GMT, Tagir F. Valeev <tvaleev at openjdk.org> wrote:

> clamp() methods added to Math and StrictMath
> 
> `int clamp(long, int, int)` is somewhat different, as it accepts a `long` value and safely clamps it to an `int` range. Other overloads work with a particular type (long, float and double). Using similar approach in other cases (e.g. `float clamp(double, float, float)`) may cause accidental precision loss even if the value is within range, so I decided to avoid this.
> 
> In all cases, `max >= min` precondition should met. For double and float we additionally order `-0.0 < 0.0`, similarly to what Math.max or Double.compare do. In double and float overloads I try to keep at most one arg-check comparison on common path, so the order of checks might look unusual.
> 
> For tests, I noticed that tests in java/lang/Math don't use any testing framework (even newer tests), so I somehow mimic the approach of neighbour tests.

src/java.base/share/classes/java/lang/Math.java line 2209:

> 2207:      * @param max maximal allowed value
> 2208:      * @return a clamped value that fits into {@code min..max} interval
> 2209:      * @throws IllegalArgumentException if {@code min < max}

Maybe I'm missing something but shouldn't this say `if {@code min > max}`? It's also repeated throughout the rest of the javadoc.

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

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

From tvaleev at openjdk.org  Sat Feb  4 21:34:50 2023
From: tvaleev at openjdk.org (Tagir F. Valeev)
Date: Sat, 4 Feb 2023 21:34:50 GMT
Subject: RFR: 8301226: Add clamp() methods to java.lang.Math and to
 StrictMath [v2]
In-Reply-To: <c7kJhZvT8oz5hScMxnWI23H7wjCaJ854ajjSRtxBnW4=.3f4e24ca-c608-4541-b80e-cf3452ec6400@github.com>
References: <c7kJhZvT8oz5hScMxnWI23H7wjCaJ854ajjSRtxBnW4=.3f4e24ca-c608-4541-b80e-cf3452ec6400@github.com>
Message-ID: <HD7wHqgfG1HUEElreURLgxBPOk9-R1jMiKNuquMvarE=.0f5a58cd-6faf-41db-87d8-5358f1251ab9@github.com>

> clamp() methods added to Math and StrictMath
> 
> `int clamp(long, int, int)` is somewhat different, as it accepts a `long` value and safely clamps it to an `int` range. Other overloads work with a particular type (long, float and double). Using similar approach in other cases (e.g. `float clamp(double, float, float)`) may cause accidental precision loss even if the value is within range, so I decided to avoid this.
> 
> In all cases, `max >= min` precondition should met. For double and float we additionally order `-0.0 < 0.0`, similarly to what Math.max or Double.compare do. In double and float overloads I try to keep at most one arg-check comparison on common path, so the order of checks might look unusual.
> 
> For tests, I noticed that tests in java/lang/Math don't use any testing framework (even newer tests), so I somehow mimic the approach of neighbour tests.

Tagir F. Valeev has updated the pull request incrementally with one additional commit since the last revision:

  Typo in doc fixed

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12428/files
  - new: https://git.openjdk.org/jdk/pull/12428/files/1bedd2d0..2ecba76e

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

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

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

From tvaleev at openjdk.org  Sat Feb  4 21:34:53 2023
From: tvaleev at openjdk.org (Tagir F. Valeev)
Date: Sat, 4 Feb 2023 21:34:53 GMT
Subject: RFR: 8301226: Add clamp() methods to java.lang.Math and to
 StrictMath [v2]
In-Reply-To: <lYoF9NldVE_lziyUpYczocQrZfHcNKangMU1TX5Et08=.b0f6d0d5-4b0e-4c9a-814a-a4c6fc437436@github.com>
References: <c7kJhZvT8oz5hScMxnWI23H7wjCaJ854ajjSRtxBnW4=.3f4e24ca-c608-4541-b80e-cf3452ec6400@github.com>
 <lYoF9NldVE_lziyUpYczocQrZfHcNKangMU1TX5Et08=.b0f6d0d5-4b0e-4c9a-814a-a4c6fc437436@github.com>
Message-ID: <WcX34Vu9xXIKP_8QCYwoVORw-rq9WzE3-YFnyH_dktY=.af0f7fec-188a-4c27-bfea-8f2995933498@github.com>

On Sat, 4 Feb 2023 15:09:04 GMT, Emily <duke at openjdk.org> wrote:

>> Tagir F. Valeev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Typo in doc fixed
>
> src/java.base/share/classes/java/lang/Math.java line 2209:
> 
>> 2207:      * @param max maximal allowed value
>> 2208:      * @return a clamped value that fits into {@code min..max} interval
>> 2209:      * @throws IllegalArgumentException if {@code min < max}
> 
> Maybe I'm missing something but shouldn't this say `if {@code min > max}`? It's also repeated throughout the rest of the javadoc.

Indeed, a typo. Thanks!

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

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

From darcy at openjdk.org  Sun Feb  5 03:11:27 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Sun, 5 Feb 2023 03:11:27 GMT
Subject: RFR: JDK-8301444: Port fdlibm hyperbolic transcendental functions to
 Java
Message-ID: <_s8xnppoDTnAajAjlmfB-dX5DBdawUcSSPaGWGLzFBk=.cdbf468a-ace7-45e5-a25a-833c760b776c@github.com>

Initial pass of porting FDLIBM sinh/cosh/tanh to Java. I do intend to refactor the regression tests a bit to reduce duplication, but the actual ports should be ready for review.

Diff'ing the ports as before, original vs transliteration port:


$ diff -w Hyperbolic.c Hyperbolic.translit.java
1c1
< /* __ieee754_sinh(x)
---
>     /**
17a18,19
>     static class Sinh {
>         private static final double one = 1.0, shuge = 1.0e307;
19,33c21
< #include "fdlibm.h"
< 
< #ifdef __STDC__
< static const double one = 1.0, shuge = 1.0e307;
< #else
< static double one = 1.0, shuge = 1.0e307;
< #endif
< 
< #ifdef __STDC__
<         double __ieee754_sinh(double x)
< #else
<         double __ieee754_sinh(x)
<         double x;
< #endif
< {
---
>         private static double compute(double x) {
36c24
<         unsigned lx;
---
>             /* unsigned */ int lx;
51c39
<             t = expm1(fabs(x));
---
>                 t = FdlibmTranslit.expm1(Math.abs(x));
57c45
<         if (ix < 0x40862E42)  return h*__ieee754_exp(fabs(x));
---
>             if (ix < 0x40862E42)  return h*StrictMath.exp(Math.abs(x)); // TODO switch to translit
60,62c48,52
<         lx = *( (((*(unsigned*)&one)>>29)) + (unsigned*)&x);
<         if (ix<0x408633CE || ((ix==0x408633ce)&&(lx<=(unsigned)0x8fb9f87d))) {
<             w = __ieee754_exp(0.5*fabs(x));
---
>             // lx = *( (((*(unsigned*)&one)>>29)) + (unsigned*)&x);
>             // lx =  (((*(unsigned*)&one)>>29)) + (unsigned*)&x ;
>             lx = __LO(x);
>             if (ix<0x408633CE || ((ix==0x408633ce)&&(Long.compareUnsigned(lx, 0x8fb9f87d) <= 0 ))) {
>                 w = StrictMath.exp(0.5*Math.abs(x)); // TODO switch to translit
70c60,62
< /* __ieee754_cosh(x)
---
>     }
> 
>     /**
90,105c82,84
< 
< #include "fdlibm.h"
< 
< #ifdef __STDC__
< static const double one = 1.0, half=0.5, huge = 1.0e300;
< #else
< static double one = 1.0, half=0.5, huge = 1.0e300;
< #endif
< 
< #ifdef __STDC__
<         double __ieee754_cosh(double x)
< #else
<         double __ieee754_cosh(x)
<         double x;
< #endif
< {
---
>     static class Cosh {
>         private static final double one = 1.0, half=0.5, huge = 1.0e300;
>         private static double compute(double x) {
108c87
<         unsigned lx;
---
>             /*unsigned*/ int lx;
119c98
<             t = expm1(fabs(x));
---
>                 t = expm1(Math.abs(x));
127c106
<                 t = __ieee754_exp(fabs(x));
---
>                 t = StrictMath.exp(Math.abs(x)); // TODO switch to translit
132c111
<         if (ix < 0x40862E42)  return half*__ieee754_exp(fabs(x));
---
>             if (ix < 0x40862E42)  return half*StrictMath.exp(Math.abs(x)); // TODO switch to translit
135c114
<         lx = *( (((*(unsigned*)&one)>>29)) + (unsigned*)&x);
---
>             lx = __LO(x);
137,138c116,117
<               ((ix==0x408633ce)&&(lx<=(unsigned)0x8fb9f87d))) {
<             w = __ieee754_exp(half*fabs(x));
---
>                 ((ix==0x408633ce)&&(Integer.compareUnsigned(lx, 0x8fb9f87d) <= 0))) {
>                 w = StrictMath.exp(half*Math.abs(x)); // TODO switch to translit
146c125,127
< /* Tanh(x)
---
>     }
> 
>     /**
169,184c150,152
< 
< #include "fdlibm.h"
< 
< #ifdef __STDC__
< static const double one=1.0, two=2.0, tiny = 1.0e-300;
< #else
< static double one=1.0, two=2.0, tiny = 1.0e-300;
< #endif
< 
< #ifdef __STDC__
<         double tanh(double x)
< #else
<         double tanh(x)
<         double x;
< #endif
< {
---
>     static class Tanh {
>         private static final double one=1.0, two=2.0, tiny = 1.0e-300;
>         static double compute(double x) {
203c171
<                 t = expm1(two*fabs(x));
---
>                     t = expm1(two*Math.abs(x));
206c174
<                 t = expm1(-two*fabs(x));
---
>                     t = expm1(-two*Math.abs(x));
214a183
>     }


Note that the original has a in-line version of the "__LO" macro rather than using the macro.


And transliteration vs more idiomatic:


$ diff -w Hyperbolic.translit.java Hyperbolic.fdlibm.java 
21c21
<         private static double compute(double x) {
---
>          static double compute(double x) {
26c26
<             /* High word of |x|. */
---
>             // High word of |x|
28c28
<             ix = jx&0x7fffffff;
---
>             ix = jx & 0x7fff_ffff;
30,31c30,33
<             /* x is INF or NaN */
<             if(ix>=0x7ff00000) return x+x;
---
>             // x is INF or NaN
>             if ( ix >= 0x7ff0_0000) {
>                 return x + x;
>             }
34,40c36,48
<             if (jx<0) h = -h;
<             /* |x| in [0,22], return sign(x)*0.5*(E+E/(E+1))) */
<             if (ix < 0x40360000) {          /* |x|<22 */
<                 if (ix<0x3e300000)          /* |x|<2**-28 */
<                     if(shuge+x>one) return x;/* sinh(tiny) = tiny with inexact */
<                 t = FdlibmTranslit.expm1(Math.abs(x));
<                 if(ix<0x3ff00000) return h*(2.0*t-t*t/(t+one));
---
>             if ( jx < 0) {
>                 h = -h;
>             }
>             // |x| in [0,22], return sign(x)*0.5*(E+E/(E+1)))
>             if (ix < 0x4036_0000) {          // |x| < 22
>                 if (ix < 0x3e30_0000)        // |x| < 2**-28
>                     if (shuge + x > one) {   // sinh(tiny) = tiny with inexact
>                         return x;
>                     }
>                 t = StrictMath.expm1(Math.abs(x));
>                 if (ix < 0x3ff0_0000) {
>                     return h*(2.0 * t - t*t/(t + one));
>                 }
44,45c52,55
<             /* |x| in [22, log(maxdouble)] return 0.5*exp(|x|) */
<             if (ix < 0x40862E42)  return h*StrictMath.exp(Math.abs(x)); // TODO switch to translit
---
>             // |x| in [22, log(maxdouble)] return 0.5*exp(|x|)
>             if (ix < 0x4086_2E42) {
>                 return h*StrictMath.exp(Math.abs(x));
>             }
47,49c57
<             /* |x| in [log(maxdouble), overflowthresold] */
<             // lx = *( (((*(unsigned*)&one)>>29)) + (unsigned*)&x);
<             // lx =  (((*(unsigned*)&one)>>29)) + (unsigned*)&x ;
---
>             // |x| in [log(maxdouble), overflowthresold]
51,52c59,62
<             if (ix<0x408633CE || ((ix==0x408633ce)&&(Long.compareUnsigned(lx, 0x8fb9f87d) <= 0 ))) {
<                 w = StrictMath.exp(0.5*Math.abs(x)); // TODO switch to translit
---
>             if (ix < 0x4086_33CE ||
>                 ((ix == 0x4086_33ce) &&
>                  (Long.compareUnsigned(lx, 0x8fb9_f87d) <= 0 ))) {
>                 w = StrictMath.exp(0.5 * Math.abs(x));
57c67
<             /* |x| > overflowthresold, sinh(x) overflow */
---
>             // |x| > overflowthresold, sinh(x) overflow
84c94
<         private static double compute(double x) {
---
>         static double compute(double x) {
89c99
<             /* High word of |x|. */
---
>             // High word of |x|
91c101
<             ix &= 0x7fffffff;
---
>             ix &= 0x7fff_ffff;
93,94c103,106
<             /* x is INF or NaN */
<             if(ix>=0x7ff00000) return x*x;
---
>             // x is INF or NaN
>             if (ix >= 0x7ff_00000) {
>                 return x*x;
>             }
96,98c108,110
<             /* |x| in [0,0.5*ln2], return 1+expm1(|x|)^2/(2*exp(|x|)) */
<             if(ix<0x3fd62e43) {
<                 t = expm1(Math.abs(x));
---
>             // |x| in [0,0.5*ln2], return 1+expm1(|x|)^2/(2*exp(|x|))
>             if (ix < 0x3fd6_2e43) {
>                 t = StrictMath.expm1(Math.abs(x));
100c112,114
<                 if (ix<0x3c800000) return w;        /* cosh(tiny) = 1 */
---
>                 if (ix < 0x3c80_0000) { // cosh(tiny) = 1
>                     return w;
>                 }
104,106c118,120
<             /* |x| in [0.5*ln2,22], return (exp(|x|)+1/exp(|x|)/2; */
<             if (ix < 0x40360000) {
<                 t = StrictMath.exp(Math.abs(x)); // TODO switch to translit
---
>             // |x| in [0.5*ln2, 22], return (exp(|x|) + 1/exp(|x|)/2
>             if (ix < 0x4036_0000) {
>                 t = StrictMath.exp(Math.abs(x));
110,111c124,127
<             /* |x| in [22, log(maxdouble)] return half*exp(|x|) */
<             if (ix < 0x40862E42)  return half*StrictMath.exp(Math.abs(x)); // TODO switch to translit
---
>             // |x| in [22, log(maxdouble)] return half*exp(|x|)
>             if (ix < 0x4086_2E42) {
>                 return half*StrictMath.exp(Math.abs(x));
>             }
113c129
<             /* |x| in [log(maxdouble), overflowthresold] */
---
>             // |x| in [log(maxdouble), overflowthresold]
115,117c131,134
<             if (ix<0x408633CE ||
<                 ((ix==0x408633ce)&&(Integer.compareUnsigned(lx, 0x8fb9f87d) <= 0))) {
<                 w = StrictMath.exp(half*Math.abs(x)); // TODO switch to translit
---
>             if (ix<0x4086_33CE ||
>                 ((ix == 0x4086_33ce) &&
>                  (Integer.compareUnsigned(lx, 0x8fb9_f87d) <= 0))) {
>                 w = StrictMath.exp(half*Math.abs(x));
122c139
<             /* |x| > overflowthresold, cosh(x) overflow */
---
>             // |x| > overflowthresold, cosh(x) overflow
126d142
< 
156c172
<             /* High word of |x|. */
---
>             // High word of |x|.
158c174
<             ix = jx&0x7fffffff;
---
>             ix = jx & 0x7fff_ffff;
160,163c176,182
<             /* x is INF or NaN */
<             if(ix>=0x7ff00000) {
<                 if (jx>=0) return one/x+one;    /* tanh(+-inf)=+-1 */
<                 else       return one/x-one;    /* tanh(NaN) = NaN */
---
>             // x is INF or NaN
>             if (ix >= 0x7ff0_0000) {
>                 if (jx >= 0) {  // tanh(+-inf)=+-1
>                     return one/x + one;
>                 } else {        // tanh(NaN) = NaN
>                     return one/x - one;
>                 }
166,171c185,190
<             /* |x| < 22 */
<             if (ix < 0x40360000) {          /* |x|<22 */
<                 if (ix<0x3c800000)          /* |x|<2**-55 */
<                     return x*(one+x);       /* tanh(small) = small */
<                 if (ix>=0x3ff00000) {       /* |x|>=1  */
<                     t = expm1(two*Math.abs(x));
---
>             // |x| < 22
>             if (ix < 0x4036_0000) {          // |x| < 22
>                 if (ix<0x3c80_0000)          // |x| < 2**-55
>                     return x*(one + x);      // tanh(small) = small
>                 if (ix>=0x3ff0_0000) {       // |x| >= 1
>                     t = StrictMath.expm1(two*Math.abs(x));
174c193
<                     t = expm1(-two*Math.abs(x));
---
>                     t = StrictMath.expm1(-two*Math.abs(x));
177,179c196,197
<                 /* |x| > 22, return +-1 */
<             } else {
<                 z = one - tiny;             /* raised inexact flag */
---
>             } else { // |x| > 22, return +-1
>                 z = one - tiny;             // raised inexact flag

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

Commit messages:
 - JDK-8301444: Port fdlibm hyperbolic transcendental functions to Java

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

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

From stsypanov at openjdk.org  Sun Feb  5 13:47:49 2023
From: stsypanov at openjdk.org (Sergey Tsypanov)
Date: Sun, 5 Feb 2023 13:47:49 GMT
Subject: RFR: 8301226: Add clamp() methods to java.lang.Math and to
 StrictMath [v2]
In-Reply-To: <HD7wHqgfG1HUEElreURLgxBPOk9-R1jMiKNuquMvarE=.0f5a58cd-6faf-41db-87d8-5358f1251ab9@github.com>
References: <c7kJhZvT8oz5hScMxnWI23H7wjCaJ854ajjSRtxBnW4=.3f4e24ca-c608-4541-b80e-cf3452ec6400@github.com>
 <HD7wHqgfG1HUEElreURLgxBPOk9-R1jMiKNuquMvarE=.0f5a58cd-6faf-41db-87d8-5358f1251ab9@github.com>
Message-ID: <oU6n6E3S_FAjYy0GVpNSPh68ovrr1TVyTOoMzuydsC4=.5e5edaa7-ebf8-404f-9f0c-3ea40dd01c89@github.com>

On Sat, 4 Feb 2023 21:34:50 GMT, Tagir F. Valeev <tvaleev at openjdk.org> wrote:

>> clamp() methods added to Math and StrictMath
>> 
>> `int clamp(long, int, int)` is somewhat different, as it accepts a `long` value and safely clamps it to an `int` range. Other overloads work with a particular type (long, float and double). Using similar approach in other cases (e.g. `float clamp(double, float, float)`) may cause accidental precision loss even if the value is within range, so I decided to avoid this.
>> 
>> In all cases, `max >= min` precondition should met. For double and float we additionally order `-0.0 < 0.0`, similarly to what Math.max or Double.compare do. In double and float overloads I try to keep at most one arg-check comparison on common path, so the order of checks might look unusual.
>> 
>> For tests, I noticed that tests in java/lang/Math don't use any testing framework (even newer tests), so I somehow mimic the approach of neighbour tests.
>
> Tagir F. Valeev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Typo in doc fixed

src/java.base/share/classes/java/lang/Math.java line 2297:

> 2295:      */
> 2296:     public static float clamp(float value, float min, float max) {
> 2297:         if (!(min < max)) {

Wouldn't it be more simple to replace `!(min < max)` with `min >= max`?

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

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

From tvaleev at openjdk.org  Sun Feb  5 13:54:51 2023
From: tvaleev at openjdk.org (Tagir F. Valeev)
Date: Sun, 5 Feb 2023 13:54:51 GMT
Subject: RFR: 8301226: Add clamp() methods to java.lang.Math and to
 StrictMath [v2]
In-Reply-To: <oU6n6E3S_FAjYy0GVpNSPh68ovrr1TVyTOoMzuydsC4=.5e5edaa7-ebf8-404f-9f0c-3ea40dd01c89@github.com>
References: <c7kJhZvT8oz5hScMxnWI23H7wjCaJ854ajjSRtxBnW4=.3f4e24ca-c608-4541-b80e-cf3452ec6400@github.com>
 <HD7wHqgfG1HUEElreURLgxBPOk9-R1jMiKNuquMvarE=.0f5a58cd-6faf-41db-87d8-5358f1251ab9@github.com>
 <oU6n6E3S_FAjYy0GVpNSPh68ovrr1TVyTOoMzuydsC4=.5e5edaa7-ebf8-404f-9f0c-3ea40dd01c89@github.com>
Message-ID: <thxWsSRsQgxN2keYfS3GKJO4nxRANJLXo-6HNjvMYvM=.2b707505-691f-4550-96c9-2f3d2fafea18@github.com>

On Sun, 5 Feb 2023 13:45:15 GMT, Sergey Tsypanov <stsypanov at openjdk.org> wrote:

>> Tagir F. Valeev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Typo in doc fixed
>
> src/java.base/share/classes/java/lang/Math.java line 2297:
> 
>> 2295:      */
>> 2296:     public static float clamp(float value, float min, float max) {
>> 2297:         if (!(min < max)) {
> 
> Wouldn't it be more simple to replace `!(min < max)` with `min >= max`?

No. I want NaNs to go into this branch

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

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

From duke at openjdk.org  Sun Feb  5 18:21:55 2023
From: duke at openjdk.org (ExE Boss)
Date: Sun, 5 Feb 2023 18:21:55 GMT
Subject: RFR: 8301226: Add clamp() methods to java.lang.Math and to
 StrictMath [v2]
In-Reply-To: <HD7wHqgfG1HUEElreURLgxBPOk9-R1jMiKNuquMvarE=.0f5a58cd-6faf-41db-87d8-5358f1251ab9@github.com>
References: <c7kJhZvT8oz5hScMxnWI23H7wjCaJ854ajjSRtxBnW4=.3f4e24ca-c608-4541-b80e-cf3452ec6400@github.com>
 <HD7wHqgfG1HUEElreURLgxBPOk9-R1jMiKNuquMvarE=.0f5a58cd-6faf-41db-87d8-5358f1251ab9@github.com>
Message-ID: <jDUID4DZVg9PMYqC-QogTLTgI-JDctEjL26Z_VzWSH0=.5689e9c8-ced5-42ab-b773-b310cd9227e1@github.com>

On Sat, 4 Feb 2023 21:34:50 GMT, Tagir F. Valeev <tvaleev at openjdk.org> wrote:

>> clamp() methods added to Math and StrictMath
>> 
>> `int clamp(long, int, int)` is somewhat different, as it accepts a `long` value and safely clamps it to an `int` range. Other overloads work with a particular type (long, float and double). Using similar approach in other cases (e.g. `float clamp(double, float, float)`) may cause accidental precision loss even if the value is within range, so I decided to avoid this.
>> 
>> In all cases, `max >= min` precondition should met. For double and float we additionally order `-0.0 < 0.0`, similarly to what Math.max or Double.compare do. In double and float overloads I try to keep at most one arg-check comparison on common path, so the order of checks might look unusual.
>> 
>> For tests, I noticed that tests in java/lang/Math don't use any testing framework (even newer tests), so I somehow mimic the approach of neighbour tests.
>
> Tagir F. Valeev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Typo in doc fixed

src/java.base/share/classes/java/lang/Math.java line 2213:

> 2211:      * @since 21
> 2212:      */
> 2213:     public static int clamp(long value, int min, int max) {

There?should probably?also?be a?pure `int`?overload:

public static int clamp(int?value, int?min, int?max)

src/java.base/share/classes/java/lang/Math.java line 2215:

> 2213:     public static int clamp(long value, int min, int max) {
> 2214:         if (min > max) {
> 2215:             throw new IllegalArgumentException(min + ">" + max);

These?should probably?have some?spacing or?a?better error?message:
Suggestion:

            throw new IllegalArgumentException(min + " > " + max);

src/java.base/share/classes/java/lang/Math.java line 2236:

> 2234:     public static long clamp(long value, long min, long max) {
> 2235:         if (min > max) {
> 2236:             throw new IllegalArgumentException(min + ">" + max);

Suggestion:

            throw new IllegalArgumentException(min + " > " + max);

src/java.base/share/classes/java/lang/Math.java line 2270:

> 2268:             }
> 2269:             if (Double.compare(min, max) > 0) {
> 2270:                 throw new IllegalArgumentException(min + ">" + max);

Suggestion:

                throw new IllegalArgumentException(min + " > " + max);

src/java.base/share/classes/java/lang/Math.java line 2305:

> 2303:             }
> 2304:             if (Float.compare(min, max) > 0) {
> 2305:                 throw new IllegalArgumentException(min + ">" + max);

Suggestion:

                throw new IllegalArgumentException(min + " > " + max);

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

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

From duke at openjdk.org  Sun Feb  5 18:21:57 2023
From: duke at openjdk.org (ExE Boss)
Date: Sun, 5 Feb 2023 18:21:57 GMT
Subject: RFR: 8301226: Add clamp() methods to java.lang.Math and to
 StrictMath [v2]
In-Reply-To: <thxWsSRsQgxN2keYfS3GKJO4nxRANJLXo-6HNjvMYvM=.2b707505-691f-4550-96c9-2f3d2fafea18@github.com>
References: <c7kJhZvT8oz5hScMxnWI23H7wjCaJ854ajjSRtxBnW4=.3f4e24ca-c608-4541-b80e-cf3452ec6400@github.com>
 <HD7wHqgfG1HUEElreURLgxBPOk9-R1jMiKNuquMvarE=.0f5a58cd-6faf-41db-87d8-5358f1251ab9@github.com>
 <oU6n6E3S_FAjYy0GVpNSPh68ovrr1TVyTOoMzuydsC4=.5e5edaa7-ebf8-404f-9f0c-3ea40dd01c89@github.com>
 <thxWsSRsQgxN2keYfS3GKJO4nxRANJLXo-6HNjvMYvM=.2b707505-691f-4550-96c9-2f3d2fafea18@github.com>
Message-ID: <aZ_-6ku0kFbX0r5ixNYVN782O5kgCvGVp5orepRD8uw=.fc66bc7a-5f74-43db-84a8-aa81153f89f0@github.com>

On Sun, 5 Feb 2023 13:52:23 GMT, Tagir F. Valeev <tvaleev at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/Math.java line 2297:
>> 
>>> 2295:      */
>>> 2296:     public static float clamp(float value, float min, float max) {
>>> 2297:         if (!(min < max)) {
>> 
>> Wouldn't it be more simple to replace `!(min < max)` with `min >= max`?
>
> No. I want NaNs to go into this branch

That?should probably?include a?comment?then.

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

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

From duke at openjdk.org  Sun Feb  5 18:39:49 2023
From: duke at openjdk.org (ExE Boss)
Date: Sun, 5 Feb 2023 18:39:49 GMT
Subject: RFR: 8301220: Return value of toArray() of
 =?UTF-8?B?0KFvbGxlY3Rpb24=?= types from java.base should be trusted [v3]
In-Reply-To: <0dRAGAS3vCAyRTvj_20L56QJVbMmMSu1dwy00zT61HE=.4558906d-22a3-4541-ae35-eb6d8166723c@github.com>
References: <TT0uMtRrRVdLtw3Rr2RUjL9aNrjTlcyIRDk2zxIG8OQ=.f46f2e33-313f-4e40-ab2a-2fb82f6da58f@github.com>
 <wXDeNy2hI8_vi7t9eI2dSSIPxq3vk9vu0g2rm6rVZuQ=.7a968a18-870b-4178-8a37-ca872f5f629c@github.com>
 <ZgHkOKdIsnDJZXhUBUCIRCzi_yEDGP9H4TJ4tlD5YkA=.0e1b03f2-787e-4e59-aacd-7e04c276deab@github.com>
 <b5h9X-XLcRtSKe_XVwh3TgNy7QKkRzFr0Hw21BUYTi8=.435384d3-4656-4bac-aaf1-b1a899a3fb15@github.com>
 <Tb8_AEbBDXOtiEQ3stEWS_3mG0wv-sGgquIg6PhEQiY=.276c316f-833d-43aa-8f6e-5477ec0855eb@github.com>
 <0dRAGAS3vCAyRTvj_20L56QJVbMmMSu1dwy00zT61HE=.4558906d-22a3-4541-ae35-eb6d8166723c@github.com>
Message-ID: <XoaYHPb00Ba5GMCWPNvnI-mKjFDaD9OLOuB7ipJMvg4=.c5f9136b-bb8e-4b5c-9134-80926a38e59c@github.com>

On Mon, 30 Jan 2023 03:13:01 GMT, Glavo <duke at openjdk.org> wrote:

> > > > Why not use set of classes?
> > > 
> > > 
> > > Because some classes are not visible here (such as `Arrays.ArrayList`).
> > > I'm not sure what the best choice is, so I'm trying to explore the implementation plan.
> > 
> > 
> > Only `Arrays.ArrayList` is not visible here. You can change it to package-private.
> 
> Another problem is that use set of classes may cause unnecessary classes to be loaded, which has a negative impact on startup speed. I want to do some tests in the next few days.

Class?constants don?t?cause class?initialization, only?bare?bones?loading (in?case `NoClassDefFoundError` needs?to?be?thrown).

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

One?option would?be to?move these?sets into?a?method inner?class, such?as:

static boolean isTrustedCollection(Collection<?> coll) {
	final class Holder {
		private static final Set<Class<? extends Collection<?>>> TRUSTED_COLLECTIONS = Set.of(
			// ...
		);

		private static final Set<Class<? extends Map<?, ?>>> TRUSTED_MAPS = Set.of(
			// ...
		);
	}

	if (coll.getClass().getModule() == Object.class.getModule()) {
		if (coll instanceof CollectionWrapper wrapper) {
			return isTrustedCollection(wrapper.getCollection());
		}

		if (Holder.TRUSTED_COLLECTIONS.contains(coll.getClass().getName())) {
			return true;
		}

		if (coll instanceof ImmutableCollections.AbstractImmutableCollection<?>) {
			return true;
		}

		// Map keys set or entries set
		if (coll instanceof Set<?> && coll.getClass().isMemberClass()) {
			return Holder.TRUSTED_MAPS.contains(coll.getClass().getNestHost().getName());
		}
	}

	return false;
}

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

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

From duke at openjdk.org  Sun Feb  5 18:48:50 2023
From: duke at openjdk.org (ExE Boss)
Date: Sun, 5 Feb 2023 18:48:50 GMT
Subject: RFR: 8301578: Perform output outside synchronization in
 Module.class [v3]
In-Reply-To: <2U1m9YRtuuJXu-IfGiz7zLj7FsnSZgv0M-fc0AaS6tc=.97247c72-d228-4e3f-9462-97edba56372e@github.com>
References: <AXAsqyTdLlz7c_RI-soi4AmkqJDG-laNLbzTVxnmbZU=.35fd56bf-abd5-4aa3-aaee-8a9f7f11eb0a@github.com>
 <AYNubIzLfR_sqjBDcJ13qDBKsKlU9INSsnUNyiYZSUw=.02c4d0ff-f125-47b6-b25c-6ac83a0c8292@github.com>
 <2U1m9YRtuuJXu-IfGiz7zLj7FsnSZgv0M-fc0AaS6tc=.97247c72-d228-4e3f-9462-97edba56372e@github.com>
Message-ID: <yqeUf7s6mn9xFCFQQxSLnRYbWBhm-g8Zl7ugZDkS-E0=.9ff66d4b-fb5a-46ae-99a5-5ed07477f939@github.com>

On Wed, 1 Feb 2023 07:52:25 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/Module.java line 281:
>> 
>>> 279: 
>>> 280:     private static boolean isNativeAccessEnabled(Module target) {
>>> 281:         if (target.enableNativeAccess)
>> 
>> @minborg It'd seem a bit easier to implement using VarHandle and not having to use `synchronized`? Is the reason that you don't want to init VarHandle in this class? ?
>
> It is a bootstrap problem. We cannot use AtomicBoolean, VarHandle or Unsafe here.

Shouldn?t?`Unsafe` already?be?loaded at?this?point?

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

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

From duke at openjdk.org  Sun Feb  5 18:48:52 2023
From: duke at openjdk.org (ExE Boss)
Date: Sun, 5 Feb 2023 18:48:52 GMT
Subject: RFR: 8301578: Perform output outside synchronization in
 Module.class [v3]
In-Reply-To: <yUInbpslOJ5zBLati4j-6FdJcnJvcdkUcG-5eG_7Aws=.1235e39e-ae82-482a-bcbc-ae355b52af55@github.com>
References: <AXAsqyTdLlz7c_RI-soi4AmkqJDG-laNLbzTVxnmbZU=.35fd56bf-abd5-4aa3-aaee-8a9f7f11eb0a@github.com>
 <yUInbpslOJ5zBLati4j-6FdJcnJvcdkUcG-5eG_7Aws=.1235e39e-ae82-482a-bcbc-ae355b52af55@github.com>
Message-ID: <iaN1zYIFMXsfOzHVoFZhs0k9quw5ViOgwMkxpQtnSCk=.3b050184-4a96-4f28-afbd-368fea7ae207@github.com>

On Wed, 1 Feb 2023 08:51:16 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR proposed to reduce contention in synchronized methods mainly by doing I/O operations outside synch blocks.
>
> Per Minborg has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Revert benchmark change
>  - Fix typo
>  - Use another type of comment

src/java.base/share/classes/java/lang/Module.java line 316:

> 314:                             %n""", cls, mtd, mod, modflag);
> 315:                 }
> 316:             }

The?`else` and?`if`?blocks can?be?merged:
Suggestion:

            } else if (trySetEnableNativeAccess(target)) {
                // warn and set flag, so that only one warning is reported per module
                String cls = owner.getName();
                String mtd = cls + "::" + methodName;
                String mod = isNamed() ? "module " + getName() : "the unnamed module";
                String modflag = isNamed() ? getName() : "ALL-UNNAMED";
                System.err.printf("""
                        WARNING: A restricted method in %s has been called
                        WARNING: %s has been called by %s
                        WARNING: Use --enable-native-access=%s to avoid a warning for this module
                        %n""", cls, mtd, mod, modflag);
            }

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

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

From alanb at openjdk.org  Sun Feb  5 19:06:50 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Sun, 5 Feb 2023 19:06:50 GMT
Subject: RFR: JDK-8301621: libzip should use pread instead of lseek+read
In-Reply-To: <pjSF1ED9D3FXjCFeqz2MRllCf0UT9suWaYa4O7kFeCM=.d16583a7-2c82-46c2-aaf1-2102c8978f2b@github.com>
References: <pjSF1ED9D3FXjCFeqz2MRllCf0UT9suWaYa4O7kFeCM=.d16583a7-2c82-46c2-aaf1-2102c8978f2b@github.com>
Message-ID: <3bJG6XaNtGLpJ7tUCH82VSmfGirG_KeaOu5KR0EDtyo=.5a43e09e-43a4-479d-a34e-e81f6095ed41@github.com>

On Fri, 3 Feb 2023 19:49:44 GMT, Justin King <jcking at openjdk.org> wrote:

> Avoid using `lseek` + `read` in favor of `pread`. For Windows, we can do the same thing by using `OVERLAPPED`, as we are in synchronous mode we can use `Offset` and `OffsetHigh` to achieve the same thing.
> 
> Additionally I updated open to use `O_CLOEXEC` when available, as that really should be used.

Are you planning to include benchmark results to go with this change?

It should be okay to change readFullyAt to use pread, and ReadFile with an OV with the position. The latter has a side effect that it changes the file pointer but it should be okay in the zip code. One thing that the changes highlight is that this native file is begging to be refactoring into platform specific code (this isn't the PR to do that).

In passing, the JNI code use 4 space indent, not 2.

The O_CLOEXEC part is probably okay but if you look at the Runtime.exec/Process implementation you'll see that it isn't really because that code closes all file descriptors on exec.

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

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

From redestad at openjdk.org  Sun Feb  5 23:37:49 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Sun, 5 Feb 2023 23:37:49 GMT
Subject: RFR: JDK-8300808: Accelerate Base64 on x86 for AVX2 [v7]
In-Reply-To: <Y0HEaVyWFWxvcBttJ1kfnRnNmkzNrXDZVC_czjkkjek=.dfa729db-67fb-4800-8e2b-fc85a2e8a376@github.com>
References: <9zN3bjyMEikXYOlpjTy9_QPc-9usYiBJMUFdb-TaVrQ=.e8f65ce9-ac0f-4f8d-9c6b-b39ae1c26cd2@github.com>
 <eyAXp-rZ5Dhd6F4jmDzFSeWJPknJBOhKN51delMUahc=.8f5d6102-5cb9-4fd1-8014-11812771962c@github.com>
 <qJm4si333sDFG9blT75d2B8HdmEXMqOg0NgsPq9N1o0=.ae3077ce-390a-481b-9402-ad9b8009c5c2@github.com>
 <yH0SmOEnIsEo6bCgNRCBy5Pv7EeyuUn3pAvUswyVQjI=.4a4915bd-3f89-4c5b-8fc8-7206c2885cff@github.com>
 <CvrXAGNcDEJr-xaovmpYAmO4-G5m193XowKMLLX8GeQ=.0cf6fc11-1710-4b2e-b3d8-d17e445490e7@github.com>
 <Y0HEaVyWFWxvcBttJ1kfnRnNmkzNrXDZVC_czjkkjek=.dfa729db-67fb-4800-8e2b-fc85a2e8a376@github.com>
Message-ID: <C27dfSGsAhqcVohvNZu78pwuOQnIMSQOUy_NLa_QnJ0=.3852b8e0-615c-4122-939b-6a36c2f7855d@github.com>

On Thu, 2 Feb 2023 15:33:29 GMT, Scott Gibbons <duke at openjdk.org> wrote:

>> Names are important, but always hard to get right. At the very least they need to be correct. Maybe call it something like `..parameterized_decode_tables..` and the other `..shared_decode_tables..`?
>
> I prefer leaving them the way they are.  I don't think the names, along with the associated comments within the tables, causes any undue confusion as to their function.  However I will implement the name change if that's all it takes to procure a review approval.  Please provide the specific names you'd like me to use and I'll change them.  Or just approve as-is :-).

I meant no disrespect here. By your own words `base64_AVX2_decode_URL_tables_addr` is "essentially incorrect", so I suggested some alternatives that I thought would make the code slightly more approachable. Regardless of whether you fix this detail I am not ready to approve this PR since I would need time to digest the latest changes. I'll ask a more senior engineer to review and give final approval (these changes need 2 reviewers approval anyhow).

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

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

From darcy at openjdk.org  Mon Feb  6 01:58:42 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Mon, 6 Feb 2023 01:58:42 GMT
Subject: RFR: JDK-8301833: Add manual tests for FDLIBM porting
Message-ID: <wgghXoOC-eICroAklhQSO8UYEBvYHF_QHZ4C_1wnW0Q=.61574f1b-9c40-4c34-b234-502b95a99c8f@github.com>

To help add assurances that the main-line port of FDLIBM to Java is working correctly, added some long-running manual tests to probe that the transliteration port and the corresponding StrictMath method are in agreement on a large number of argument, say, all float values.

To test the transliteration port, this test can be run against a build where the JDK has *not* had the FDLIBM code used for StrictMath ported to Java.

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

Commit messages:
 - Added trailing line terminator.
 - JDK-8301833: Add manual tests for FDLIBM porting

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

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

From xgong at openjdk.org  Mon Feb  6 02:04:50 2023
From: xgong at openjdk.org (Xiaohong Gong)
Date: Mon, 6 Feb 2023 02:04:50 GMT
Subject: RFR: 8293198: [vectorapi] Improve the implementation of
 VectorMask.indexInRange() [v2]
In-Reply-To: <slq_H7aJmdxgBUkHbT5JolMB19OnGnkYdpZlyzrd87s=.77740147-6ec5-4fd5-a10a-a118389d911c@github.com>
References: <fN58bi3n01tqWpG0-jjUPZQe8hmls2GQ5X3NL2o1RPg=.80e7965d-50af-4fac-bd7c-0a2b99cffe7e@github.com>
 <slq_H7aJmdxgBUkHbT5JolMB19OnGnkYdpZlyzrd87s=.77740147-6ec5-4fd5-a10a-a118389d911c@github.com>
Message-ID: <QxylMK8i9amF-g5XlBBzLXTbimRtsRToBYeSnE4VfgQ=.60c1f19f-3413-425a-a92a-f70f914df7e2@github.com>

On Fri, 3 Feb 2023 02:03:14 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Xiaohong Gong has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add smaller array size for benchmark tests
>
> LGTM

Thanks for the review @jatin-bhateja @merykitty !

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

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

From darcy at openjdk.org  Mon Feb  6 02:42:47 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Mon, 6 Feb 2023 02:42:47 GMT
Subject: RFR: JDK-8301833: Add manual tests for FDLIBM porting
In-Reply-To: <wgghXoOC-eICroAklhQSO8UYEBvYHF_QHZ4C_1wnW0Q=.61574f1b-9c40-4c34-b234-502b95a99c8f@github.com>
References: <wgghXoOC-eICroAklhQSO8UYEBvYHF_QHZ4C_1wnW0Q=.61574f1b-9c40-4c34-b234-502b95a99c8f@github.com>
Message-ID: <znCMgH6WMtRx5kML4_as9XT0RK_PBEnmJdwx2HEgBwQ=.968a55a9-a8cb-4d85-b4df-34c3af75b60f@github.com>

On Mon, 6 Feb 2023 01:50:55 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> To help add assurances that the main-line port of FDLIBM to Java is working correctly, added some long-running manual tests to probe that the transliteration port and the corresponding StrictMath method are in agreement on a large number of argument, say, all float values.
> 
> To test the transliteration port, this test can be run against a build where the JDK has *not* had the FDLIBM code used for StrictMath ported to Java.

PS The manual test passes when run against a JDK 20 build, helping to validate the new-in-21 transliteration ports done so far in JDK 21 (log10, log1p, expm1).

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

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

From duke at openjdk.org  Mon Feb  6 02:49:49 2023
From: duke at openjdk.org (SUN Guoyun)
Date: Mon, 6 Feb 2023 02:49:49 GMT
Subject: RFR: 8301737:
 java/rmi/server/UnicastRemoteObject/serialFilter/FilterUROTest.java fail with
 -Xcomp
In-Reply-To: <Rx4Yso3GBMPTSCb-ofT80DXdRkVkxl8r1Di6Ay3XhUo=.8b150a73-58f3-4aaf-af1a-9445ee9064bd@github.com>
References: <l5m5_9io2QMSFNY7dBHT3Nr2I9Er8wmd92Ze8FP-XE0=.a40d29be-77be-4719-a0a0-71d032eea1e5@github.com>
 <Rx4Yso3GBMPTSCb-ofT80DXdRkVkxl8r1Di6Ay3XhUo=.8b150a73-58f3-4aaf-af1a-9445ee9064bd@github.com>
Message-ID: <Q5-8OMpjBinptXuXoM7dVpJez7QbnKAN1l2NA8sGdAM=.195aa190-2cbd-4532-8a8f-024354da17b3@github.com>

On Fri, 3 Feb 2023 15:52:09 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Hi all,
>> When -Xcomp be used, java thread to block for longer, then causing this test failed frequently on the AArch64 and LoongArch64 architecture.
>> 
>> This PR fix the issue, Please help review it.
>> 
>> Thanks.
>
> test/jdk/java/rmi/server/UnicastRemoteObject/serialFilter/FilterUROTest.java line 41:
> 
>> 39: /*
>> 40:  * @test
>> 41:  * @run testng/othervm -Dsun.net.httpserver.idleInterval=50000 FilterUROTest
> 
> This test doesn't seem to be using an HttpServer so setting this system property seems useless as it should have no effect.

Sorry, I was mistaken. I'll fix it later

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

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

From qamai at openjdk.org  Mon Feb  6 03:28:50 2023
From: qamai at openjdk.org (Quan Anh Mai)
Date: Mon, 6 Feb 2023 03:28:50 GMT
Subject: RFR: 8301226: Add clamp() methods to java.lang.Math and to
 StrictMath [v2]
In-Reply-To: <thxWsSRsQgxN2keYfS3GKJO4nxRANJLXo-6HNjvMYvM=.2b707505-691f-4550-96c9-2f3d2fafea18@github.com>
References: <c7kJhZvT8oz5hScMxnWI23H7wjCaJ854ajjSRtxBnW4=.3f4e24ca-c608-4541-b80e-cf3452ec6400@github.com>
 <HD7wHqgfG1HUEElreURLgxBPOk9-R1jMiKNuquMvarE=.0f5a58cd-6faf-41db-87d8-5358f1251ab9@github.com>
 <oU6n6E3S_FAjYy0GVpNSPh68ovrr1TVyTOoMzuydsC4=.5e5edaa7-ebf8-404f-9f0c-3ea40dd01c89@github.com>
 <thxWsSRsQgxN2keYfS3GKJO4nxRANJLXo-6HNjvMYvM=.2b707505-691f-4550-96c9-2f3d2fafea18@github.com>
Message-ID: <Y1II-DQHU1SwJoRJk98AK8Be4gnO-jgpPQ72TgsAfWk=.4f32e18a-1c69-4115-9f6f-796b771a2e37@github.com>

On Sun, 5 Feb 2023 13:52:23 GMT, Tagir F. Valeev <tvaleev at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/Math.java line 2297:
>> 
>>> 2295:      */
>>> 2296:     public static float clamp(float value, float min, float max) {
>>> 2297:         if (!(min < max)) {
>> 
>> Wouldn't it be more simple to replace `!(min < max)` with `min >= max`?
>
> No. I want NaNs to go into this branch

@amaembo Should that be `if (!(min <= max))` instead?

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

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

From roger.riggs at oracle.com  Mon Feb  6 04:55:10 2023
From: roger.riggs at oracle.com (Roger Riggs)
Date: Sun, 5 Feb 2023 23:55:10 -0500
Subject: JEP415: FilterInThread Example
In-Reply-To: <76209504-e958-b981-8b6b-b90955fd5f5d@javaspecialists.eu>
References: <76209504-e958-b981-8b6b-b90955fd5f5d@javaspecialists.eu>
Message-ID: <1555d359-0a01-764d-c014-f2b5b678cabb@oracle.com>

Hi Heinz,

Indeed, this example is not intuitive and does not do what was intended 
and could use a better explanation.

The interaction of three filters gets complicated and their combination 
depends on the ordering and intention of each filter and the particular 
filter factory goal. The FilterInThread example provides only one of 
many possible functions.

The FilterInThread example uses the JVM-wide filter, thread filter, and 
stream filter for different purposes.

The JVM-wide filter has a particular role in that it can be set on the 
command line via a system property.
It is typically used as a backstop after the application is deployed to 
patch in additional rejection of classes.
The property value syntax allows for either allowing or rejecting 
classes, and an otherwise unmentioned class is left UNDECIDED, possibly 
with some risk exposure.

The thread filter is used to more focus de-serialization on a group of 
classes, either to narrow it or expand it.

The FilterInThread example takes the position that any UNDECIDED in the 
thread's filter and the JVM-wide filter should be rejected even if the 
pattern does not explicitly do so.? This keeps an oversight in filter 
construction from becoming a risk.

The stream filter is included mostly for backward compatibility, 
introduced in JDK 9 via JEP 290. The stream filter is set by the code 
creating the ObjectInputStream and part of its design and purpose. In 
the FilterInThread example, if it returns UNDECIDED, the result is 
determined by a merge of the other two filters and further rejecting 
UNDECIDED.

The bug in the example, that individually rejects UNDECIDED in the 
JVM-wide and thread filters respectively, should instead reject only if 
both return UNDECIDED.

The revised example is:

*// Returns a composite filter of the static JVM-wide filter, a 
thread-specific filter, *// and the stream-specific filter. *public 
ObjectInputFilter apply(ObjectInputFilter curr, ObjectInputFilter next) 
{ *if (curr == null) { *// Called from the OIS constructor or perhaps 
OIS.setObjectInputFilter with no current filter *var filter = 
filterThreadLocal.get(); *if (filter != null) { *// Merge to invoke the 
thread local filter and then the JVM-wide filter (if any) *filter = 
ObjectInputFilter.merge(filter, next); *return 
ObjectInputFilter.rejectUndecidedClass(filter); *} *return (next == 
null) ? null : ObjectInputFilter.rejectUndecidedClass(next); *} else { 
*// Called from OIS.setObjectInputFilter with a current filter and a 
stream-specific filter. *// The curr filter already incorporates the 
thread filter and static JVM-wide filter *// and rejection of undecided 
classes *// If there is a stream-specific filter merge to invoke it and 
then the current filter. *if (next != null) { *return 
ObjectInputFilter.merge(next, curr); *} *return curr; *} *}


The filters are evaluated as:
merge(restrictLargeArrays,rejectUndecidedClass(merge(allowInteger,allowArrayList)))

The first call to the factory returns a filter:? `var f1 = 
rejectUndecidedClass(merge(allowInteger,allowArrayList))`
The second call to the factory returns filter: `var f2 = 
merge(restrictLargeArrays, f1)`

The filters are evaluated in order, until an accept or reject is returned:
 ? 1) restrictLargeArrays? (stream)
 ? 2) allowInteger??? ??? ??? (thread filter)
 ? 3) allowArrayList???? ??? (JVM-wide filter)

This has the same value as your ideal but without an extra 
RejectUndecidedClass.

Note that in this composition, the choice by a filter to accept or 
reject can not be overridden by a subsequent filter.

Thank you for the comments and suggestions, Roger

On 2/3/23 1:20 PM, Dr Heinz M. Kabutz wrote:
> I was trying to get my head around the FilterInThread example in JEP 
> 415 (https://openjdk.org/jeps/415) and the JavaDoc for the 
> ObjectInputFilter 
> (https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/io/ObjectInputFilter.html)
>
> For example, let's assume we have three filters. The first allow 
> ArrayList, the second allows Integer, the third restricts arrays to 
> not be larger than 1000.
>
> ??? ObjectInputFilter allowArrayList = ObjectInputFilter.allowFilter(
> ??????????? Set.of(ArrayList.class, Object.class)::contains, UNDECIDED
> ??? );
> ??? ObjectInputFilter allowInteger = ObjectInputFilter.allowFilter(
> ??????????? Set.of(Number.class, Integer.class)::contains, UNDECIDED
> ??? );
> ??? ObjectInputFilter restrictLargeArrays =
> ObjectInputFilter.Config.createFilter("maxarray=1000");
>
> Let's say that we create a FilterInThread instance and install that as 
> our factory. Furthermore, we set the allowArrayList as the global 
> serial filter. When we call filterInThread.doWithSerialFilter() we 
> pass in the allowInteger filter. Lastly, during the actual 
> deserialization, we call setObjectInputFilter() on the 
> ObjectInputStream with the restrictLargeArrays filter. Ideally, I 
> would want the final filter to look like this:
>
> rejectUndecidedClass(merge(restrictLargeArrays,merge(allowInteger,allowArrayList))) 
>
>
> However, in the FilterInThread example, we add the 
> rejectUndecidedClass() wrapper around each of the steps. Thus we would 
> get something like:
>
> rejectUndecidedClass(merge(restrictLargeArrays,rejectUndecidedClass(merge(allowInteger,rejectUndecidedClass(allowArrayList))))) 
>
>
> Thus we could never allow any classes except for ArrayList.
>
>
> Regards
>
> Heinz
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20230205/473a6346/attachment-0001.htm>

From jbhateja at openjdk.org  Mon Feb  6 06:39:51 2023
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Mon, 6 Feb 2023 06:39:51 GMT
Subject: RFR: JDK-8300808: Accelerate Base64 on x86 for AVX2 [v8]
In-Reply-To: <eF4pTseOICr9nNZQb-VHAkJN0Z2i0MBY1B3V91XI3u8=.46527b0e-d3ed-40df-a0ba-f52dd4cd318f@github.com>
References: <9zN3bjyMEikXYOlpjTy9_QPc-9usYiBJMUFdb-TaVrQ=.e8f65ce9-ac0f-4f8d-9c6b-b39ae1c26cd2@github.com>
 <eF4pTseOICr9nNZQb-VHAkJN0Z2i0MBY1B3V91XI3u8=.46527b0e-d3ed-40df-a0ba-f52dd4cd318f@github.com>
Message-ID: <rBhuJMMmLwyYsV8SWxi4jXCgjU_y5jj1fYR7A_Sd30Q=.0ec8e02b-7b42-4c06-bdc7-dc98cd122493@github.com>

On Wed, 1 Feb 2023 19:07:17 GMT, Scott Gibbons <duke at openjdk.org> wrote:

>> Added code for Base64 acceleration (encode and decode) which will accelerate ~4x for AVX2 platforms.
>> 
>> Encode performance:
>> **Old:**
>> 
>> Benchmark                      (maxNumBytes)   Mode  Cnt     Score   Error   Units
>> Base64Encode.testBase64Encode           1024  thrpt    3  4309.439 ? 2.632  ops/ms
>> 
>> 
>> **New:**
>> 
>> Benchmark                      (maxNumBytes)   Mode  Cnt      Score     Error   Units
>> Base64Encode.testBase64Encode           1024  thrpt    3  24211.397 ? 102.026  ops/ms
>> 
>> 
>> Decode performance:
>> **Old:**
>> 
>> Benchmark                      (errorIndex)  (lineSize)  (maxNumBytes)   Mode  Cnt     Score    Error   Units
>> Base64Decode.testBase64Decode           144           4           1024  thrpt    3  3961.768 ? 93.409  ops/ms
>> 
>> **New:**
>> Benchmark                      (errorIndex)  (lineSize)  (maxNumBytes)   Mode  Cnt      Score    Error   Units
>> Base64Decode.testBase64Decode           144           4           1024  thrpt    3  14738.051 ? 24.383  ops/ms
>
> Scott Gibbons has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Change break-even buffer size for AVX512

src/hotspot/cpu/x86/stubGenerator_x86_64.cpp line 2693:

> 2691:     __ vpshufb(xmm0, xmm0, xmm13, Assembler::AVX_256bit);
> 2692:     __ vpermd(xmm0, xmm12, xmm0, Assembler::AVX_256bit);
> 2693:     __ subl(length, 0x20);

Subtraction effects EFLAGs we can save one redundant compare per iteration on [#L2697](https://github.com/openjdk/jdk/pull/12126/files#diff-b938ab8a7bd9f57eb02271e2dd24a305bca30f06e9f8b028e18a139c4908ec92R2697)
by doing a prior subtraction by 0x2c (44) in pre-loop and increment by same amount post loop.

Same goes out for encode main loop also.

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

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

From jpai at openjdk.org  Mon Feb  6 07:03:25 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 6 Feb 2023 07:03:25 GMT
Subject: RFR: 8301834: Templated Buffer classes leave a lot of empty lines in
 the generated source
Message-ID: <NShlonPoOpwt90csJyyyz71GUhwMkuVuXi1Ev8p8jcE=.17eec3ac-280e-4abc-9c39-76753c62d14f@github.com>

Can I please get a review for this change which proposes to fix the issue noted in https://bugs.openjdk.org/browse/JDK-8301834?

Some classes in `java.nio` package are generated from template files, during the build. The template files are processed by a build tool implemented by a Java class `make/jdk/src/classes/build/tools/spp/Spp.java`. This template processing tool allows for an (optional) parameter called `-nel` which as per its documentation:

>  If -nel is declared then empty lines will not be substituted for lines of
>  text in the template that do not appear in the output.

Various places in the JDK build where this tool is used to generate source from template files, already use the `-nel` option to not generate the empty lines in the source files. However, the `GensrcBuffer.gmk` which generates the source for `java.nio` classes doesn't use this option. The commit in this PR adds this option when generating the `java.nio` classes.

Existing tests in `test/jdk/java/nio` continue to pass after this change. I've always checked the generated content and compared it with the older versions to verify that these empty lines no longer appear in these generated classes.

Additional `tier` testing has been triggered to make sure no regression is introduced.

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

Commit messages:
 - 8301834: Templated Buffer classes leave a lot of empty lines in the generated source

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

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

From alanb at openjdk.org  Mon Feb  6 08:05:50 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 6 Feb 2023 08:05:50 GMT
Subject: RFR: 8301834: Templated Buffer classes leave a lot of empty lines
 in the generated source
In-Reply-To: <NShlonPoOpwt90csJyyyz71GUhwMkuVuXi1Ev8p8jcE=.17eec3ac-280e-4abc-9c39-76753c62d14f@github.com>
References: <NShlonPoOpwt90csJyyyz71GUhwMkuVuXi1Ev8p8jcE=.17eec3ac-280e-4abc-9c39-76753c62d14f@github.com>
Message-ID: <EPHXKsBRiK7YneI_e6PQeMArUNYw_S4FLgwpDfKu7oU=.979d972b-30f3-4ba6-ab24-ee19f9d3ba4f@github.com>

On Mon, 6 Feb 2023 06:57:43 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review for this change which proposes to fix the issue noted in https://bugs.openjdk.org/browse/JDK-8301834?
> 
> Some classes in `java.nio` package are generated from template files, during the build. The template files are processed by a build tool implemented by a Java class `make/jdk/src/classes/build/tools/spp/Spp.java`. This template processing tool allows for an (optional) parameter called `-nel` which as per its documentation:
> 
>>  If -nel is declared then empty lines will not be substituted for lines of
>>  text in the template that do not appear in the output.
> 
> Various places in the JDK build where this tool is used to generate source from template files, already use the `-nel` option to not generate the empty lines in the source files. However, the `GensrcBuffer.gmk` which generates the source for `java.nio` classes doesn't use this option. The commit in this PR adds this option when generating the `java.nio` classes.
> 
> Existing tests in `test/jdk/java/nio` continue to pass after this change. I've checked the generated content and compared it with the older versions to verify that these empty lines no longer appear in these generated classes.
> 
> Additional `tier` testing has been triggered to make sure no regression is introduced.

See JDK-8207804 for the last discussion on this issue.

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

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

From alanb at openjdk.org  Mon Feb  6 08:23:03 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 6 Feb 2023 08:23:03 GMT
Subject: RFR: JDK-8301396: Port fdlibm expm1 to Java [v2]
In-Reply-To: <Xwful8ptiuz7_NWCqmth5VAGSRqYpHnI9ZfRdntxnog=.0276afad-1dc5-4c1b-8b37-85e093c813f3@github.com>
References: <U3Jo6dH5rPBRmSVceetCxwisBbTPlaHshGCP2zL9kD0=.1d76ebf0-e729-4066-b9b6-46e06b350eb3@github.com>
 <Xwful8ptiuz7_NWCqmth5VAGSRqYpHnI9ZfRdntxnog=.0276afad-1dc5-4c1b-8b37-85e093c813f3@github.com>
Message-ID: <3uEwLb5RgU3fDXlaNIPtpRDc80YcGxOjHckTVCeoy98=.a2ef426d-4d1a-4a29-a0d7-338c952f9723@github.com>

On Fri, 3 Feb 2023 21:04:15 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Next on the FDLIBM C -> Java port, expm1.
>> Coming soon, hyperbolic transcendentals (sinh, cosh, tanh)!
>> 
>> For expm1, the C vs transliteration port show the usual kind of differences, beside formatting of the constants, the use of the __HI macro on the left-hand side needs to be replaced by a method call and an assignment, as seen below:
>> 
>> 
>> < 
>> < #include "fdlibm.h"
>> < 
>> < #ifdef __STDC__
>> < static const double
>> < #else
>> < static double
>> < #endif
>> < one             = 1.0,
>> < huge            = 1.0e+300,
>> < tiny            = 1.0e-300,
>> < o_threshold     = 7.09782712893383973096e+02,/* 0x40862E42, 0xFEFA39EF */
>> < ln2_hi          = 6.93147180369123816490e-01,/* 0x3fe62e42, 0xfee00000 */
>> < ln2_lo          = 1.90821492927058770002e-10,/* 0x3dea39ef, 0x35793c76 */
>> < invln2          = 1.44269504088896338700e+00,/* 0x3ff71547, 0x652b82fe */
>> ---
>>>     static class Expm1 {
>>>         private static final double one             = 1.0;
>>>         private static final double huge            = 1.0e+300;
>>>         private static final double tiny            = 1.0e-300;
>>>         private static final double o_threshold     = 7.09782712893383973096e+02; /* 0x40862E42, 0xFEFA39EF */
>>>         private static final double ln2_hi          = 6.93147180369123816490e-01; /* 0x3fe62e42, 0xfee00000 */
>>>         private static final double ln2_lo          = 1.90821492927058770002e-10; /* 0x3dea39ef, 0x35793c76 */
>>>         private static final double invln2          = 1.44269504088896338700e+00; /* 0x3ff71547, 0x652b82fe */
>> 111,115c104,108
>> < Q1  =  -3.33333333333331316428e-02, /* BFA11111 111110F4 */
>> < Q2  =   1.58730158725481460165e-03, /* 3F5A01A0 19FE5585 */
>> < Q3  =  -7.93650757867487942473e-05, /* BF14CE19 9EAADBB7 */
>> < Q4  =   4.00821782732936239552e-06, /* 3ED0CFCA 86E65239 */
>> < Q5  =  -2.01099218183624371326e-07; /* BE8AFDB7 6E09C32D */
>> ---
>>>         private static final double Q1  =  -3.33333333333331316428e-02; /* BFA11111 111110F4 */
>>>         private static final double Q2  =   1.58730158725481460165e-03; /* 3F5A01A0 19FE5585 */
>>>         private static final double Q3  =  -7.93650757867487942473e-05; /* BF14CE19 9EAADBB7 */
>>>         private static final double Q4  =   4.00821782732936239552e-06; /* 3ED0CFCA 86E65239 */
>>>         private static final double Q5  =  -2.01099218183624371326e-07; /* BE8AFDB7 6E09C32D */
>> 117,123c110
>> < #ifdef __STDC__
>> <         double expm1(double x)
>> < #else
>> <         double expm1(x)
>> <         double x;
>> < #endif
>> < {
>> ---
>>>         static double compute(double x) {
>> 126c113
>> <         unsigned hx;
>> ---
>>>             /*unsigned*/ int hx;
>> 157c144
>> <                 k  = invln2*x+((xsb==0)?0.5:-0.5);
>> ---
>>>                     k  = (int)(invln2*x+((xsb==0)?0.5:-0.5));
>> 188c175
>> <                 __HI(y) += (k<<20);     /* add k to y's exponent */
>> ---
>>>                     y = __HI(y,  __HI(y) + (k<<20));     /* add k to y's exponent */
>> 193c180
>> <                 __HI(t) = 0x3ff00000 - (0x200000>>k);  /* t=1-2^-k */
>> ---
>>>                     t = __HI(t, 0x3ff00000 - (0x200000>>k));  /* t=1-2^-k */
>> 195c182
>> <                 __HI(y) += (k<<20);     /* add k to y's exponent */
>> ---
>>>                     y = __HI(y, __HI(y) + (k<<20));     /* add k to y's exponent */
>> 197c184
>> <                 __HI(t)  = ((0x3ff-k)<<20);     /* 2^-k */
>> ---
>>>                     t = __HI(t, ((0x3ff-k)<<20));     /* 2^-k */
>> 200c187
>> <                 __HI(y) += (k<<20);     /* add k to y's exponent */
>> ---
>>>                     y = __HI(y, __HI(y) + (k<<20));     /* add k to y's exponent */
>> 205c192
>> < 
>> ---
>>>     }
>> 
>> 
>> When comparing the transliteration port and the more idiomatic port, there were no surprising or notable differences:
>> 
>> 
>> $ diff -w Expm1.translit.java Expm1.fdlibm.java  
>> 99,102c99,102
>> <         private static final double o_threshold     = 7.09782712893383973096e+02; /* 0x40862E42, 0xFEFA39EF */
>> <         private static final double ln2_hi          = 6.93147180369123816490e-01; /* 0x3fe62e42, 0xfee00000 */
>> <         private static final double ln2_lo          = 1.90821492927058770002e-10; /* 0x3dea39ef, 0x35793c76 */
>> <         private static final double invln2          = 1.44269504088896338700e+00; /* 0x3ff71547, 0x652b82fe */
>> ---
>>>         private static final double o_threshold =  0x1.62e42fefa39efp9;   //  7.09782712893383973096e+02
>>>         private static final double ln2_hi      =  0x1.62e42feep-1;       //  6.93147180369123816490e-01
>>>         private static final double ln2_lo      =  0x1.a39ef35793c76p-33; //  1.90821492927058770002e-10
>>>         private static final double invln2      =  0x1.71547652b82fep0;   //  1.44269504088896338700e+00
>> 104,108c104,108
>> <         private static final double Q1  =  -3.33333333333331316428e-02; /* BFA11111 111110F4 */
>> <         private static final double Q2  =   1.58730158725481460165e-03; /* 3F5A01A0 19FE5585 */
>> <         private static final double Q3  =  -7.93650757867487942473e-05; /* BF14CE19 9EAADBB7 */
>> <         private static final double Q4  =   4.00821782732936239552e-06; /* 3ED0CFCA 86E65239 */
>> <         private static final double Q5  =  -2.01099218183624371326e-07; /* BE8AFDB7 6E09C32D */
>> ---
>>>         private static final double Q1          = -0x1.11111111110f4p-5;  // -3.33333333333331316428e-02
>>>         private static final double Q2          =  0x1.a01a019fe5585p-10; //  1.58730158725481460165e-03
>>>         private static final double Q3          = -0x1.4ce199eaadbb7p-14; // -7.93650757867487942473e-05
>>>         private static final double Q4          =  0x1.0cfca86e65239p-18; //  4.00821782732936239552e-06
>>>         private static final double Q5          = -0x1.afdb76e09c32dp-23; // -2.01099218183624371326e-07
>> 116,118c116,118
>> <             xsb = hx&0x80000000;            /* sign bit of x */
>> <             if(xsb==0) y=x; else y= -x;     /* y = |x| */
>> <             hx &= 0x7fffffff;               /* high word of |x| */
>> ---
>>>             xsb = hx & 0x8000_0000;            /* sign bit of x */
>>>             y = Math.abs(x);
>>>             hx &= 0x7fff_ffff;               /* high word of |x| */
>> 121,124c121,124
>> <             if(hx >= 0x4043687A) {                  /* if |x|>=56*ln2 */
>> <                 if(hx >= 0x40862E42) {              /* if |x|>=709.78... */
>> <                     if(hx>=0x7ff00000) {
>> <                         if(((hx&0xfffff)|__LO(x))!=0)
>> ---
>>>             if (hx >= 0x4043_687A) {                  /* if |x| >= 56*ln2 */
>>>                 if (hx >= 0x4086_2E42) {              /* if |x| >= 709.78... */
>>>                     if (hx >= 0x7ff_00000) {
>>>                         if (((hx & 0xf_ffff) | __LO(x)) != 0) {
>> 126c126,131
>> <                         else return (xsb==0)? x:-1.0;/* exp(+-inf)={inf,-1} */
>> ---
>>>                         } else {
>>>                             return (xsb == 0)? x : -1.0; /* exp(+-inf)={inf,-1} */
>>>                         }
>>>                     }
>>>                     if (x > o_threshold) {
>>>                         return huge*huge; /* overflow */
>> 128d132
>> <                     if(x > o_threshold) return huge*huge; /* overflow */
>> 131c135
>> <                     if(x+tiny<0.0)          /* raise inexact */
>> ---
>>>                     if (x + tiny < 0.0) {         /* raise inexact */
>> 134a139
>>>             }
>> 137,142c142,152
>> <             if(hx > 0x3fd62e42) {           /* if  |x| > 0.5 ln2 */
>> <                 if(hx < 0x3FF0A2B2) {       /* and |x| < 1.5 ln2 */
>> <                     if(xsb==0)
>> <                         {hi = x - ln2_hi; lo =  ln2_lo;  k =  1;}
>> <                     else
>> <                         {hi = x + ln2_hi; lo = -ln2_lo;  k = -1;}
>> ---
>>>             if (hx > 0x3fd6_2e42) {           /* if  |x| > 0.5 ln2 */
>>>                 if (hx < 0x3FF0_A2B2) {       /* and |x| < 1.5 ln2 */
>>>                     if (xsb == 0) {
>>>                         hi = x - ln2_hi;
>>>                         lo =  ln2_lo;
>>>                         k =  1;}
>>>                     else {
>>>                         hi = x + ln2_hi;
>>>                         lo = -ln2_lo;
>>>                         k = -1;
>>>                     }
>> 151,152c161
>> <             }
>> <             else if(hx < 0x3c900000) {      /* when |x|<2**-54, return x */
>> ---
>>>             } else if (hx < 0x3c90_0000) {      /* when |x|<2**-54, return x */
>> 154a164,165
>>>             } else {
>>>                 k = 0;
>> 156d166
>> <             else k = 0;
>> 164,165c174,176
>> <             if(k==0) return x - (x*e-hxs);          /* c is 0 */
>> <             else {
>> ---
>>>             if (k == 0) {
>>>                 return x - (x*e - hxs);          /* c is 0 */
>>>             } else {
>> 168c179,181
>> <                 if(k== -1) return 0.5*(x-e)-0.5;
>> ---
>>>                 if (k == -1) {
>>>                     return 0.5*(x - e) - 0.5;
>>>                 }
>> 170,171c183,187
>> <                     if(x < -0.25) return -2.0*(e-(x+0.5));
>> <                     else          return  one+2.0*(x-e);
>> ---
>>>                     if(x < -0.25) {
>>>                         return -2.0*(e - (x + 0.5));
>>>                     } else {
>>>                         return  one + 2.0*(x - e);
>>>                     }
>> 180c196
>> <                     t = __HI(t, 0x3ff00000 - (0x200000>>k));  /* t=1-2^-k */
>> ---
>>>                     t = __HI(t, 0x3ff0_0000 - (0x2_00000 >> k));  /* t=1-2^-k */
>
> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Respond to review feedback; use // comments

@jddarcy Are you planning a GC of unused functions in StrictMath.c too? (for this PR I'm wondering about Java_java_lang_StrictMath_expm1).

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

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

From aturbanov at openjdk.org  Mon Feb  6 08:36:57 2023
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Mon, 6 Feb 2023 08:36:57 GMT
Subject: RFR: JDK-8301444: Port fdlibm hyperbolic transcendental functions
 to Java
In-Reply-To: <_s8xnppoDTnAajAjlmfB-dX5DBdawUcSSPaGWGLzFBk=.cdbf468a-ace7-45e5-a25a-833c760b776c@github.com>
References: <_s8xnppoDTnAajAjlmfB-dX5DBdawUcSSPaGWGLzFBk=.cdbf468a-ace7-45e5-a25a-833c760b776c@github.com>
Message-ID: <2dHRl3CFLAqCZJeCULJHwuI-msEWVD3NR9W96zdPrpM=.3b945995-e933-4a41-b86d-e28eaa74a38d@github.com>

On Sun, 5 Feb 2023 03:05:55 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Initial pass of porting FDLIBM sinh/cosh/tanh to Java. I do intend to refactor the regression tests a bit to reduce duplication, but the actual ports should be ready for review.
> 
> Diff'ing the ports as before, original vs transliteration port:
> 
> 
> $ diff -w Hyperbolic.c Hyperbolic.translit.java
> 1c1
> < /* __ieee754_sinh(x)
> ---
>>     /**
> 17a18,19
>>     static class Sinh {
>>         private static final double one = 1.0, shuge = 1.0e307;
> 19,33c21
> < #include "fdlibm.h"
> < 
> < #ifdef __STDC__
> < static const double one = 1.0, shuge = 1.0e307;
> < #else
> < static double one = 1.0, shuge = 1.0e307;
> < #endif
> < 
> < #ifdef __STDC__
> <         double __ieee754_sinh(double x)
> < #else
> <         double __ieee754_sinh(x)
> <         double x;
> < #endif
> < {
> ---
>>         private static double compute(double x) {
> 36c24
> <         unsigned lx;
> ---
>>             /* unsigned */ int lx;
> 51c39
> <             t = expm1(fabs(x));
> ---
>>                 t = FdlibmTranslit.expm1(Math.abs(x));
> 57c45
> <         if (ix < 0x40862E42)  return h*__ieee754_exp(fabs(x));
> ---
>>             if (ix < 0x40862E42)  return h*StrictMath.exp(Math.abs(x)); // TODO switch to translit
> 60,62c48,52
> <         lx = *( (((*(unsigned*)&one)>>29)) + (unsigned*)&x);
> <         if (ix<0x408633CE || ((ix==0x408633ce)&&(lx<=(unsigned)0x8fb9f87d))) {
> <             w = __ieee754_exp(0.5*fabs(x));
> ---
>>             // lx = *( (((*(unsigned*)&one)>>29)) + (unsigned*)&x);
>>             // lx =  (((*(unsigned*)&one)>>29)) + (unsigned*)&x ;
>>             lx = __LO(x);
>>             if (ix<0x408633CE || ((ix==0x408633ce)&&(Long.compareUnsigned(lx, 0x8fb9f87d) <= 0 ))) {
>>                 w = StrictMath.exp(0.5*Math.abs(x)); // TODO switch to translit
> 70c60,62
> < /* __ieee754_cosh(x)
> ---
>>     }
>> 
>>     /**
> 90,105c82,84
> < 
> < #include "fdlibm.h"
> < 
> < #ifdef __STDC__
> < static const double one = 1.0, half=0.5, huge = 1.0e300;
> < #else
> < static double one = 1.0, half=0.5, huge = 1.0e300;
> < #endif
> < 
> < #ifdef __STDC__
> <         double __ieee754_cosh(double x)
> < #else
> <         double __ieee754_cosh(x)
> <         double x;
> < #endif
> < {
> ---
>>     static class Cosh {
>>         private static final double one = 1.0, half=0.5, huge = 1.0e300;
>>         private static double compute(double x) {
> 108c87
> <         unsigned lx;
> ---
>>             /*unsigned*/ int lx;
> 119c98
> <             t = expm1(fabs(x));
> ---
>>                 t = expm1(Math.abs(x));
> 127c106
> <                 t = __ieee754_exp(fabs(x));
> ---
>>                 t = StrictMath.exp(Math.abs(x)); // TODO switch to translit
> 132c111
> <         if (ix < 0x40862E42)  return half*__ieee754_exp(fabs(x));
> ---
>>             if (ix < 0x40862E42)  return half*StrictMath.exp(Math.abs(x)); // TODO switch to translit
> 135c114
> <         lx = *( (((*(unsigned*)&one)>>29)) + (unsigned*)&x);
> ---
>>             lx = __LO(x);
> 137,138c116,117
> <               ((ix==0x408633ce)&&(lx<=(unsigned)0x8fb9f87d))) {
> <             w = __ieee754_exp(half*fabs(x));
> ---
>>                 ((ix==0x408633ce)&&(Integer.compareUnsigned(lx, 0x8fb9f87d) <= 0))) {
>>                 w = StrictMath.exp(half*Math.abs(x)); // TODO switch to translit
> 146c125,127
> < /* Tanh(x)
> ---
>>     }
>> 
>>     /**
> 169,184c150,152
> < 
> < #include "fdlibm.h"
> < 
> < #ifdef __STDC__
> < static const double one=1.0, two=2.0, tiny = 1.0e-300;
> < #else
> < static double one=1.0, two=2.0, tiny = 1.0e-300;
> < #endif
> < 
> < #ifdef __STDC__
> <         double tanh(double x)
> < #else
> <         double tanh(x)
> <         double x;
> < #endif
> < {
> ---
>>     static class Tanh {
>>         private static final double one=1.0, two=2.0, tiny = 1.0e-300;
>>         static double compute(double x) {
> 203c171
> <                 t = expm1(two*fabs(x));
> ---
>>                     t = expm1(two*Math.abs(x));
> 206c174
> <                 t = expm1(-two*fabs(x));
> ---
>>                     t = expm1(-two*Math.abs(x));
> 214a183
>>     }
> 
> 
> Note that the original has a in-line version of the "__LO" macro rather than using the macro.
> 
> 
> And transliteration vs more idiomatic:
> 
> 
> $ diff -w Hyperbolic.translit.java Hyperbolic.fdlibm.java 
> 21c21
> <         private static double compute(double x) {
> ---
>>          static double compute(double x) {
> 26c26
> <             /* High word of |x|. */
> ---
>>             // High word of |x|
> 28c28
> <             ix = jx&0x7fffffff;
> ---
>>             ix = jx & 0x7fff_ffff;
> 30,31c30,33
> <             /* x is INF or NaN */
> <             if(ix>=0x7ff00000) return x+x;
> ---
>>             // x is INF or NaN
>>             if ( ix >= 0x7ff0_0000) {
>>                 return x + x;
>>             }
> 34,40c36,48
> <             if (jx<0) h = -h;
> <             /* |x| in [0,22], return sign(x)*0.5*(E+E/(E+1))) */
> <             if (ix < 0x40360000) {          /* |x|<22 */
> <                 if (ix<0x3e300000)          /* |x|<2**-28 */
> <                     if(shuge+x>one) return x;/* sinh(tiny) = tiny with inexact */
> <                 t = FdlibmTranslit.expm1(Math.abs(x));
> <                 if(ix<0x3ff00000) return h*(2.0*t-t*t/(t+one));
> ---
>>             if ( jx < 0) {
>>                 h = -h;
>>             }
>>             // |x| in [0,22], return sign(x)*0.5*(E+E/(E+1)))
>>             if (ix < 0x4036_0000) {          // |x| < 22
>>                 if (ix < 0x3e30_0000)        // |x| < 2**-28
>>                     if (shuge + x > one) {   // sinh(tiny) = tiny with inexact
>>                         return x;
>>                     }
>>                 t = StrictMath.expm1(Math.abs(x));
>>                 if (ix < 0x3ff0_0000) {
>>                     return h*(2.0 * t - t*t/(t + one));
>>                 }
> 44,45c52,55
> <             /* |x| in [22, log(maxdouble)] return 0.5*exp(|x|) */
> <             if (ix < 0x40862E42)  return h*StrictMath.exp(Math.abs(x)); // TODO switch to translit
> ---
>>             // |x| in [22, log(maxdouble)] return 0.5*exp(|x|)
>>             if (ix < 0x4086_2E42) {
>>                 return h*StrictMath.exp(Math.abs(x));
>>             }
> 47,49c57
> <             /* |x| in [log(maxdouble), overflowthresold] */
> <             // lx = *( (((*(unsigned*)&one)>>29)) + (unsigned*)&x);
> <             // lx =  (((*(unsigned*)&one)>>29)) + (unsigned*)&x ;
> ---
>>             // |x| in [log(maxdouble), overflowthresold]
> 51,52c59,62
> <             if (ix<0x408633CE || ((ix==0x408633ce)&&(Long.compareUnsigned(lx, 0x8fb9f87d) <= 0 ))) {
> <                 w = StrictMath.exp(0.5*Math.abs(x)); // TODO switch to translit
> ---
>>             if (ix < 0x4086_33CE ||
>>                 ((ix == 0x4086_33ce) &&
>>                  (Long.compareUnsigned(lx, 0x8fb9_f87d) <= 0 ))) {
>>                 w = StrictMath.exp(0.5 * Math.abs(x));
> 57c67
> <             /* |x| > overflowthresold, sinh(x) overflow */
> ---
>>             // |x| > overflowthresold, sinh(x) overflow
> 84c94
> <         private static double compute(double x) {
> ---
>>         static double compute(double x) {
> 89c99
> <             /* High word of |x|. */
> ---
>>             // High word of |x|
> 91c101
> <             ix &= 0x7fffffff;
> ---
>>             ix &= 0x7fff_ffff;
> 93,94c103,106
> <             /* x is INF or NaN */
> <             if(ix>=0x7ff00000) return x*x;
> ---
>>             // x is INF or NaN
>>             if (ix >= 0x7ff_00000) {
>>                 return x*x;
>>             }
> 96,98c108,110
> <             /* |x| in [0,0.5*ln2], return 1+expm1(|x|)^2/(2*exp(|x|)) */
> <             if(ix<0x3fd62e43) {
> <                 t = expm1(Math.abs(x));
> ---
>>             // |x| in [0,0.5*ln2], return 1+expm1(|x|)^2/(2*exp(|x|))
>>             if (ix < 0x3fd6_2e43) {
>>                 t = StrictMath.expm1(Math.abs(x));
> 100c112,114
> <                 if (ix<0x3c800000) return w;        /* cosh(tiny) = 1 */
> ---
>>                 if (ix < 0x3c80_0000) { // cosh(tiny) = 1
>>                     return w;
>>                 }
> 104,106c118,120
> <             /* |x| in [0.5*ln2,22], return (exp(|x|)+1/exp(|x|)/2; */
> <             if (ix < 0x40360000) {
> <                 t = StrictMath.exp(Math.abs(x)); // TODO switch to translit
> ---
>>             // |x| in [0.5*ln2, 22], return (exp(|x|) + 1/exp(|x|)/2
>>             if (ix < 0x4036_0000) {
>>                 t = StrictMath.exp(Math.abs(x));
> 110,111c124,127
> <             /* |x| in [22, log(maxdouble)] return half*exp(|x|) */
> <             if (ix < 0x40862E42)  return half*StrictMath.exp(Math.abs(x)); // TODO switch to translit
> ---
>>             // |x| in [22, log(maxdouble)] return half*exp(|x|)
>>             if (ix < 0x4086_2E42) {
>>                 return half*StrictMath.exp(Math.abs(x));
>>             }
> 113c129
> <             /* |x| in [log(maxdouble), overflowthresold] */
> ---
>>             // |x| in [log(maxdouble), overflowthresold]
> 115,117c131,134
> <             if (ix<0x408633CE ||
> <                 ((ix==0x408633ce)&&(Integer.compareUnsigned(lx, 0x8fb9f87d) <= 0))) {
> <                 w = StrictMath.exp(half*Math.abs(x)); // TODO switch to translit
> ---
>>             if (ix<0x4086_33CE ||
>>                 ((ix == 0x4086_33ce) &&
>>                  (Integer.compareUnsigned(lx, 0x8fb9_f87d) <= 0))) {
>>                 w = StrictMath.exp(half*Math.abs(x));
> 122c139
> <             /* |x| > overflowthresold, cosh(x) overflow */
> ---
>>             // |x| > overflowthresold, cosh(x) overflow
> 126d142
> < 
> 156c172
> <             /* High word of |x|. */
> ---
>>             // High word of |x|.
> 158c174
> <             ix = jx&0x7fffffff;
> ---
>>             ix = jx & 0x7fff_ffff;
> 160,163c176,182
> <             /* x is INF or NaN */
> <             if(ix>=0x7ff00000) {
> <                 if (jx>=0) return one/x+one;    /* tanh(+-inf)=+-1 */
> <                 else       return one/x-one;    /* tanh(NaN) = NaN */
> ---
>>             // x is INF or NaN
>>             if (ix >= 0x7ff0_0000) {
>>                 if (jx >= 0) {  // tanh(+-inf)=+-1
>>                     return one/x + one;
>>                 } else {        // tanh(NaN) = NaN
>>                     return one/x - one;
>>                 }
> 166,171c185,190
> <             /* |x| < 22 */
> <             if (ix < 0x40360000) {          /* |x|<22 */
> <                 if (ix<0x3c800000)          /* |x|<2**-55 */
> <                     return x*(one+x);       /* tanh(small) = small */
> <                 if (ix>=0x3ff00000) {       /* |x|>=1  */
> <                     t = expm1(two*Math.abs(x));
> ---
>>             // |x| < 22
>>             if (ix < 0x4036_0000) {          // |x| < 22
>>                 if (ix<0x3c80_0000)          // |x| < 2**-55
>>                     return x*(one + x);      // tanh(small) = small
>>                 if (ix>=0x3ff0_0000) {       // |x| >= 1
>>                     t = StrictMath.expm1(two*Math.abs(x));
> 174c193
> <                     t = expm1(-two*Math.abs(x));
> ---
>>                     t = StrictMath.expm1(-two*Math.abs(x));
> 177,179c196,197
> <                 /* |x| > 22, return +-1 */
> <             } else {
> <                 z = one - tiny;             /* raised inexact flag */
> ---
>>             } else { // |x| > 22, return +-1
>>                 z = one - tiny;             // raised inexact flag

src/java.base/share/classes/java/lang/FdLibm.java line 1228:

> 1226: 
> 1227:             // x is INF or NaN
> 1228:             if ( ix >= 0x7ff0_0000) {

Suggestion:

            if (ix >= 0x7ff0_0000) {

src/java.base/share/classes/java/lang/FdLibm.java line 1233:

> 1231: 
> 1232:             h = 0.5;
> 1233:             if ( jx < 0) {

Suggestion:

            if (jx < 0) {

test/jdk/java/lang/StrictMath/HyperbolicTests.java line 86:

> 84: 
> 85:          // ... and just below subnormal threshold ...
> 86:           x =  Math.nextDown(Double.MIN_NORMAL);

Suggestion:

          x = Math.nextDown(Double.MIN_NORMAL);

test/jdk/java/lang/StrictMath/HyperbolicTests.java line 140:

> 138: 
> 139:          // ... and just below subnormal threshold ...
> 140:           x =  Math.nextDown(Double.MIN_NORMAL);

Suggestion:

          x = Math.nextDown(Double.MIN_NORMAL);

test/jdk/java/lang/StrictMath/HyperbolicTests.java line 198:

> 196: 
> 197:          // ... and just below subnormal threshold ...
> 198:           x =  Math.nextDown(Double.MIN_NORMAL);

Suggestion:

          x = Math.nextDown(Double.MIN_NORMAL);

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

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

From tvaleev at openjdk.org  Mon Feb  6 08:46:54 2023
From: tvaleev at openjdk.org (Tagir F. Valeev)
Date: Mon, 6 Feb 2023 08:46:54 GMT
Subject: RFR: 8301226: Add clamp() methods to java.lang.Math and to
 StrictMath [v2]
In-Reply-To: <jDUID4DZVg9PMYqC-QogTLTgI-JDctEjL26Z_VzWSH0=.5689e9c8-ced5-42ab-b773-b310cd9227e1@github.com>
References: <c7kJhZvT8oz5hScMxnWI23H7wjCaJ854ajjSRtxBnW4=.3f4e24ca-c608-4541-b80e-cf3452ec6400@github.com>
 <HD7wHqgfG1HUEElreURLgxBPOk9-R1jMiKNuquMvarE=.0f5a58cd-6faf-41db-87d8-5358f1251ab9@github.com>
 <jDUID4DZVg9PMYqC-QogTLTgI-JDctEjL26Z_VzWSH0=.5689e9c8-ced5-42ab-b773-b310cd9227e1@github.com>
Message-ID: <qnUokZ-1TMMQGZ9iS7CxOB74udDSe_SQGpMoAESbKso=.5c62e6b4-5eaf-4974-8d40-529ec8a04cf0@github.com>

On Sun, 5 Feb 2023 18:13:35 GMT, ExE Boss <duke at openjdk.org> wrote:

>> Tagir F. Valeev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Typo in doc fixed
>
> src/java.base/share/classes/java/lang/Math.java line 2213:
> 
>> 2211:      * @since 21
>> 2212:      */
>> 2213:     public static int clamp(long value, int min, int max) {
> 
> There?should probably?also?be a?pure `int`?overload:
> 
> public static int clamp(int?value, int?min, int?max)

@ExE-Boss which problem such an overload would solve? It looks like, `int clamp(long, int, int)` can be used everywhere where proposed `int clamp(int, int, int)` could be useful.

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

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

From tvaleev at openjdk.org  Mon Feb  6 08:46:55 2023
From: tvaleev at openjdk.org (Tagir F. Valeev)
Date: Mon, 6 Feb 2023 08:46:55 GMT
Subject: RFR: 8301226: Add clamp() methods to java.lang.Math and to
 StrictMath [v2]
In-Reply-To: <Y1II-DQHU1SwJoRJk98AK8Be4gnO-jgpPQ72TgsAfWk=.4f32e18a-1c69-4115-9f6f-796b771a2e37@github.com>
References: <c7kJhZvT8oz5hScMxnWI23H7wjCaJ854ajjSRtxBnW4=.3f4e24ca-c608-4541-b80e-cf3452ec6400@github.com>
 <HD7wHqgfG1HUEElreURLgxBPOk9-R1jMiKNuquMvarE=.0f5a58cd-6faf-41db-87d8-5358f1251ab9@github.com>
 <oU6n6E3S_FAjYy0GVpNSPh68ovrr1TVyTOoMzuydsC4=.5e5edaa7-ebf8-404f-9f0c-3ea40dd01c89@github.com>
 <thxWsSRsQgxN2keYfS3GKJO4nxRANJLXo-6HNjvMYvM=.2b707505-691f-4550-96c9-2f3d2fafea18@github.com>
 <Y1II-DQHU1SwJoRJk98AK8Be4gnO-jgpPQ72TgsAfWk=.4f32e18a-1c69-4115-9f6f-796b771a2e37@github.com>
Message-ID: <1suw9mB1XEV8MkOJBsqdtYhsXwh7yyjVdMdkgLqvZjg=.c8a6e73b-f463-4bf7-b420-80fcd6f188e0@github.com>

On Mon, 6 Feb 2023 03:25:50 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

>> No. I want NaNs to go into this branch
>
> @amaembo Should that be `if (!(min <= max))` instead?

@merykitty no. I want `min = +0.0` and `max = -0.0` to go into this branch, so we can report it. A marginal case when `min` and `max` are exactly equal goes through all the checks and still succeeds (it's covered by unit-tests).

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

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

From tvaleev at openjdk.org  Mon Feb  6 08:49:53 2023
From: tvaleev at openjdk.org (Tagir F. Valeev)
Date: Mon, 6 Feb 2023 08:49:53 GMT
Subject: RFR: 8301226: Add clamp() methods to java.lang.Math and to
 StrictMath [v2]
In-Reply-To: <aZ_-6ku0kFbX0r5ixNYVN782O5kgCvGVp5orepRD8uw=.fc66bc7a-5f74-43db-84a8-aa81153f89f0@github.com>
References: <c7kJhZvT8oz5hScMxnWI23H7wjCaJ854ajjSRtxBnW4=.3f4e24ca-c608-4541-b80e-cf3452ec6400@github.com>
 <HD7wHqgfG1HUEElreURLgxBPOk9-R1jMiKNuquMvarE=.0f5a58cd-6faf-41db-87d8-5358f1251ab9@github.com>
 <oU6n6E3S_FAjYy0GVpNSPh68ovrr1TVyTOoMzuydsC4=.5e5edaa7-ebf8-404f-9f0c-3ea40dd01c89@github.com>
 <thxWsSRsQgxN2keYfS3GKJO4nxRANJLXo-6HNjvMYvM=.2b707505-691f-4550-96c9-2f3d2fafea18@github.com>
 <aZ_-6ku0kFbX0r5ixNYVN782O5kgCvGVp5orepRD8uw=.fc66bc7a-5f74-43db-84a8-aa81153f89f0@github.com>
Message-ID: <p_w6KxQe5nLjbgYRN8Vght8Vs02F_Tgj8-kAWmfiygc=.f5e4711e-8076-4e75-953b-b751a919e610@github.com>

On Sun, 5 Feb 2023 18:08:47 GMT, ExE Boss <duke at openjdk.org> wrote:

>> No. I want NaNs to go into this branch
>
> That?should probably?include a?comment?then.

@ExE-Boss I think that immediately following `isNaN` checks give enough hint that we want NaN to be here.

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

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

From jpai at openjdk.org  Mon Feb  6 08:59:00 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 6 Feb 2023 08:59:00 GMT
Subject: RFR: 8301834: Templated Buffer classes leave a lot of empty lines
 in the generated source
In-Reply-To: <NShlonPoOpwt90csJyyyz71GUhwMkuVuXi1Ev8p8jcE=.17eec3ac-280e-4abc-9c39-76753c62d14f@github.com>
References: <NShlonPoOpwt90csJyyyz71GUhwMkuVuXi1Ev8p8jcE=.17eec3ac-280e-4abc-9c39-76753c62d14f@github.com>
Message-ID: <065Y_wY9PnpHKTQqlBdg4pzfhGf1kYyjpkIatxYPuYA=.85fb4dfc-8005-4b30-a087-788a6a9841b2@github.com>

On Mon, 6 Feb 2023 06:57:43 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review for this change which proposes to fix the issue noted in https://bugs.openjdk.org/browse/JDK-8301834?
> 
> Some classes in `java.nio` package are generated from template files, during the build. The template files are processed by a build tool implemented by a Java class `make/jdk/src/classes/build/tools/spp/Spp.java`. This template processing tool allows for an (optional) parameter called `-nel` which as per its documentation:
> 
>>  If -nel is declared then empty lines will not be substituted for lines of
>>  text in the template that do not appear in the output.
> 
> Various places in the JDK build where this tool is used to generate source from template files, already use the `-nel` option to not generate the empty lines in the source files. However, the `GensrcBuffer.gmk` which generates the source for `java.nio` classes doesn't use this option. The commit in this PR adds this option when generating the `java.nio` classes.
> 
> Existing tests in `test/jdk/java/nio` continue to pass after this change. I've checked the generated content and compared it with the older versions to verify that these empty lines no longer appear in these generated classes.
> 
> Additional `tier` testing has been triggered to make sure no regression is introduced.

Thank you Alan for pointing to the previous discussion.

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

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

From jpai at openjdk.org  Mon Feb  6 08:59:01 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 6 Feb 2023 08:59:01 GMT
Subject: Withdrawn: 8301834: Templated Buffer classes leave a lot of empty
 lines in the generated source
In-Reply-To: <NShlonPoOpwt90csJyyyz71GUhwMkuVuXi1Ev8p8jcE=.17eec3ac-280e-4abc-9c39-76753c62d14f@github.com>
References: <NShlonPoOpwt90csJyyyz71GUhwMkuVuXi1Ev8p8jcE=.17eec3ac-280e-4abc-9c39-76753c62d14f@github.com>
Message-ID: <CdY6C4XLttS82FmapCWhw-ddEp8jyLdT6ofY-84_1GY=.994c8fb3-826f-4f7b-a427-0c2fe980b729@github.com>

On Mon, 6 Feb 2023 06:57:43 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review for this change which proposes to fix the issue noted in https://bugs.openjdk.org/browse/JDK-8301834?
> 
> Some classes in `java.nio` package are generated from template files, during the build. The template files are processed by a build tool implemented by a Java class `make/jdk/src/classes/build/tools/spp/Spp.java`. This template processing tool allows for an (optional) parameter called `-nel` which as per its documentation:
> 
>>  If -nel is declared then empty lines will not be substituted for lines of
>>  text in the template that do not appear in the output.
> 
> Various places in the JDK build where this tool is used to generate source from template files, already use the `-nel` option to not generate the empty lines in the source files. However, the `GensrcBuffer.gmk` which generates the source for `java.nio` classes doesn't use this option. The commit in this PR adds this option when generating the `java.nio` classes.
> 
> Existing tests in `test/jdk/java/nio` continue to pass after this change. I've checked the generated content and compared it with the older versions to verify that these empty lines no longer appear in these generated classes.
> 
> Additional `tier` testing has been triggered to make sure no regression is introduced.

This pull request has been closed without being integrated.

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

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

From qamai at openjdk.org  Mon Feb  6 09:06:49 2023
From: qamai at openjdk.org (Quan Anh Mai)
Date: Mon, 6 Feb 2023 09:06:49 GMT
Subject: RFR: 8301226: Add clamp() methods to java.lang.Math and to
 StrictMath [v2]
In-Reply-To: <p_w6KxQe5nLjbgYRN8Vght8Vs02F_Tgj8-kAWmfiygc=.f5e4711e-8076-4e75-953b-b751a919e610@github.com>
References: <c7kJhZvT8oz5hScMxnWI23H7wjCaJ854ajjSRtxBnW4=.3f4e24ca-c608-4541-b80e-cf3452ec6400@github.com>
 <HD7wHqgfG1HUEElreURLgxBPOk9-R1jMiKNuquMvarE=.0f5a58cd-6faf-41db-87d8-5358f1251ab9@github.com>
 <oU6n6E3S_FAjYy0GVpNSPh68ovrr1TVyTOoMzuydsC4=.5e5edaa7-ebf8-404f-9f0c-3ea40dd01c89@github.com>
 <thxWsSRsQgxN2keYfS3GKJO4nxRANJLXo-6HNjvMYvM=.2b707505-691f-4550-96c9-2f3d2fafea18@github.com>
 <aZ_-6ku0kFbX0r5ixNYVN782O5kgCvGVp5orepRD8uw=.fc66bc7a-5f74-43db-84a8-aa81153f89f0@github.com>
 <p_w6KxQe5nLjbgYRN8Vght8Vs02F_Tgj8-kAWmfiygc=.f5e4711e-8076-4e75-953b-b751a919e610@github.com>
Message-ID: <0So-9C3Fb-LT2E9Vr1GIuP4BE7dQKshE8sUgYRIqyS8=.9c0f666e-46b8-408b-a046-f90d838332c1@github.com>

On Mon, 6 Feb 2023 08:46:54 GMT, Tagir F. Valeev <tvaleev at openjdk.org> wrote:

>> That?should probably?include a?comment?then.
>
> @ExE-Boss I think that immediately following `isNaN` checks give enough hint that we want NaN to be here.

Ah I see, a comment explaining the intention would be helpful here, then

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

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

From alanb at openjdk.org  Mon Feb  6 09:21:55 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 6 Feb 2023 09:21:55 GMT
Subject: RFR: JDK-8301833: Add manual tests for FDLIBM porting
In-Reply-To: <wgghXoOC-eICroAklhQSO8UYEBvYHF_QHZ4C_1wnW0Q=.61574f1b-9c40-4c34-b234-502b95a99c8f@github.com>
References: <wgghXoOC-eICroAklhQSO8UYEBvYHF_QHZ4C_1wnW0Q=.61574f1b-9c40-4c34-b234-502b95a99c8f@github.com>
Message-ID: <JSOpjfwMLEyZJbU6i9F7ECuuaxitsd8UQtaYKmZnNAU=.094f3b9d-e88d-4195-8015-4490a0dc632c@github.com>

On Mon, 6 Feb 2023 01:50:55 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> To help add assurances that the main-line port of FDLIBM to Java is working correctly, added some long-running manual tests to probe that the transliteration port and the corresponding StrictMath method are in agreement on a large number of argument, say, all float values.
> 
> To test the transliteration port, this test can be run against a build where the JDK has *not* had the FDLIBM code used for StrictMath ported to Java.

Manual tests are the tests of last resort :-) This test may be useful for the current transliteration work but it's not clear how this manual test would be run by someone tasked with running the manual tests.  Right now, it looks like it's more of a long running stress test but I think the expectation is that someone running this test needs to do a special build or somehow compare results with an older JDK release.  Have you explored alternatives to adding a manual test? Long running HotSpot stress tests run in higher tiers. For comparison, I'm wondering if samples could be captured in a golden file for the test to use.

If we are adding a manual test here then I think it will need good instructions. @bwhuang-us has done work in recent times on making sure that the manual tests are in test groups with instructions.

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

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

From heinz at javaspecialists.eu  Mon Feb  6 09:35:38 2023
From: heinz at javaspecialists.eu (Dr Heinz M. Kabutz)
Date: Mon, 6 Feb 2023 11:35:38 +0200
Subject: JEP415: FilterInThread Example
In-Reply-To: <1555d359-0a01-764d-c014-f2b5b678cabb@oracle.com>
References: <76209504-e958-b981-8b6b-b90955fd5f5d@javaspecialists.eu>
 <1555d359-0a01-764d-c014-f2b5b678cabb@oracle.com>
Message-ID: <f49cf939-ffee-c91d-bdaf-9a1a04666b81@javaspecialists.eu>

Hi Roger,

thanks for your quick response. That does seem to work better.

Regards

Heinz
-- 
Dr Heinz M. Kabutz (PhD CompSci)
Author of "The Java? Specialists' Newsletter" -www.javaspecialists.eu
Java Champion -www.javachampions.org
JavaOne Rock Star Speaker
Tel: +30 69 75 595 262
Skype: kabutz

On 2023/02/06 06:55, Roger Riggs wrote:
> *// Returns a composite filter of the static JVM-wide filter, a 
> thread-specific filter, *// and the stream-specific filter. *public 
> ObjectInputFilter apply(ObjectInputFilter curr, ObjectInputFilter 
> next) { *if (curr == null) { *// Called from the OIS constructor or 
> perhaps OIS.setObjectInputFilter with no current filter *var filter = 
> filterThreadLocal.get(); *if (filter != null) { *// Merge to invoke 
> the thread local filter and then the JVM-wide filter (if any) *filter 
> = ObjectInputFilter.merge(filter, next); *return 
> ObjectInputFilter.rejectUndecidedClass(filter); *} *return (next == 
> null) ? null : ObjectInputFilter.rejectUndecidedClass(next); *} else { 
> *// Called from OIS.setObjectInputFilter with a current filter and a 
> stream-specific filter. *// The curr filter already incorporates the 
> thread filter and static JVM-wide filter *// and rejection of 
> undecided classes *// If there is a stream-specific filter merge to 
> invoke it and then the current filter. *if (next != null) { *return 
> ObjectInputFilter.merge(next, curr); *} *return curr; *} *}
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20230206/36f56bb5/attachment.htm>

From tvaleev at openjdk.org  Mon Feb  6 09:37:20 2023
From: tvaleev at openjdk.org (Tagir F. Valeev)
Date: Mon, 6 Feb 2023 09:37:20 GMT
Subject: RFR: 8301226: Add clamp() methods to java.lang.Math and to
 StrictMath [v3]
In-Reply-To: <c7kJhZvT8oz5hScMxnWI23H7wjCaJ854ajjSRtxBnW4=.3f4e24ca-c608-4541-b80e-cf3452ec6400@github.com>
References: <c7kJhZvT8oz5hScMxnWI23H7wjCaJ854ajjSRtxBnW4=.3f4e24ca-c608-4541-b80e-cf3452ec6400@github.com>
Message-ID: <jgQBL0MuSlkhuinmwD1WFq2GCwbX-7G5mS06On-TeMQ=.ee10c20b-d4e3-4a05-ae31-432f1d81fc14@github.com>

> clamp() methods added to Math and StrictMath
> 
> `int clamp(long, int, int)` is somewhat different, as it accepts a `long` value and safely clamps it to an `int` range. Other overloads work with a particular type (long, float and double). Using similar approach in other cases (e.g. `float clamp(double, float, float)`) may cause accidental precision loss even if the value is within range, so I decided to avoid this.
> 
> In all cases, `max >= min` precondition should met. For double and float we additionally order `-0.0 < 0.0`, similarly to what Math.max or Double.compare do. In double and float overloads I try to keep at most one arg-check comparison on common path, so the order of checks might look unusual.
> 
> For tests, I noticed that tests in java/lang/Math don't use any testing framework (even newer tests), so I somehow mimic the approach of neighbour tests.

Tagir F. Valeev has updated the pull request incrementally with one additional commit since the last revision:

  Spaces in exception message

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12428/files
  - new: https://git.openjdk.org/jdk/pull/12428/files/2ecba76e..9b73965a

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

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

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

From tvaleev at openjdk.org  Mon Feb  6 09:37:23 2023
From: tvaleev at openjdk.org (Tagir F. Valeev)
Date: Mon, 6 Feb 2023 09:37:23 GMT
Subject: RFR: 8301226: Add clamp() methods to java.lang.Math and to
 StrictMath [v2]
In-Reply-To: <jDUID4DZVg9PMYqC-QogTLTgI-JDctEjL26Z_VzWSH0=.5689e9c8-ced5-42ab-b773-b310cd9227e1@github.com>
References: <c7kJhZvT8oz5hScMxnWI23H7wjCaJ854ajjSRtxBnW4=.3f4e24ca-c608-4541-b80e-cf3452ec6400@github.com>
 <HD7wHqgfG1HUEElreURLgxBPOk9-R1jMiKNuquMvarE=.0f5a58cd-6faf-41db-87d8-5358f1251ab9@github.com>
 <jDUID4DZVg9PMYqC-QogTLTgI-JDctEjL26Z_VzWSH0=.5689e9c8-ced5-42ab-b773-b310cd9227e1@github.com>
Message-ID: <w4II28Jv30_1i_6I7OzNW9pPtAxvY2Rg2ubOr1YN_9o=.bc1d87d1-99dc-4e1e-9e00-f7679fa02346@github.com>

On Sun, 5 Feb 2023 18:14:28 GMT, ExE Boss <duke at openjdk.org> wrote:

>> Tagir F. Valeev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Typo in doc fixed
>
> src/java.base/share/classes/java/lang/Math.java line 2215:
> 
>> 2213:     public static int clamp(long value, int min, int max) {
>> 2214:         if (min > max) {
>> 2215:             throw new IllegalArgumentException(min + ">" + max);
> 
> These?should probably?have some?spacing or?a?better error?message:
> Suggestion:
> 
>             throw new IllegalArgumentException(min + " > " + max);

Updated, thanks

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

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

From tvaleev at openjdk.org  Mon Feb  6 09:46:15 2023
From: tvaleev at openjdk.org (Tagir F. Valeev)
Date: Mon, 6 Feb 2023 09:46:15 GMT
Subject: RFR: 8301226: Add clamp() methods to java.lang.Math and to
 StrictMath [v4]
In-Reply-To: <c7kJhZvT8oz5hScMxnWI23H7wjCaJ854ajjSRtxBnW4=.3f4e24ca-c608-4541-b80e-cf3452ec6400@github.com>
References: <c7kJhZvT8oz5hScMxnWI23H7wjCaJ854ajjSRtxBnW4=.3f4e24ca-c608-4541-b80e-cf3452ec6400@github.com>
Message-ID: <Ddvn1DCxT2qXxF7oOltTVKlnvkATfbHTuq7ZBtWWdwI=.bf25f42a-9fa0-4ee0-95a9-f0a7ab94434b@github.com>

> clamp() methods added to Math and StrictMath
> 
> `int clamp(long, int, int)` is somewhat different, as it accepts a `long` value and safely clamps it to an `int` range. Other overloads work with a particular type (long, float and double). Using similar approach in other cases (e.g. `float clamp(double, float, float)`) may cause accidental precision loss even if the value is within range, so I decided to avoid this.
> 
> In all cases, `max >= min` precondition should met. For double and float we additionally order `-0.0 < 0.0`, similarly to what Math.max or Double.compare do. In double and float overloads I try to keep at most one arg-check comparison on common path, so the order of checks might look unusual.
> 
> For tests, I noticed that tests in java/lang/Math don't use any testing framework (even newer tests), so I somehow mimic the approach of neighbour tests.

Tagir F. Valeev has updated the pull request incrementally with one additional commit since the last revision:

  Added explanatory comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12428/files
  - new: https://git.openjdk.org/jdk/pull/12428/files/9b73965a..065018f4

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

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

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

From tvaleev at openjdk.org  Mon Feb  6 09:46:16 2023
From: tvaleev at openjdk.org (Tagir F. Valeev)
Date: Mon, 6 Feb 2023 09:46:16 GMT
Subject: RFR: 8301226: Add clamp() methods to java.lang.Math and to
 StrictMath [v2]
In-Reply-To: <0So-9C3Fb-LT2E9Vr1GIuP4BE7dQKshE8sUgYRIqyS8=.9c0f666e-46b8-408b-a046-f90d838332c1@github.com>
References: <c7kJhZvT8oz5hScMxnWI23H7wjCaJ854ajjSRtxBnW4=.3f4e24ca-c608-4541-b80e-cf3452ec6400@github.com>
 <HD7wHqgfG1HUEElreURLgxBPOk9-R1jMiKNuquMvarE=.0f5a58cd-6faf-41db-87d8-5358f1251ab9@github.com>
 <oU6n6E3S_FAjYy0GVpNSPh68ovrr1TVyTOoMzuydsC4=.5e5edaa7-ebf8-404f-9f0c-3ea40dd01c89@github.com>
 <thxWsSRsQgxN2keYfS3GKJO4nxRANJLXo-6HNjvMYvM=.2b707505-691f-4550-96c9-2f3d2fafea18@github.com>
 <aZ_-6ku0kFbX0r5ixNYVN782O5kgCvGVp5orepRD8uw=.fc66bc7a-5f74-43db-84a8-aa81153f89f0@github.com>
 <p_w6KxQe5nLjbgYRN8Vght8Vs02F_Tgj8-kAWmfiygc=.f5e4711e-8076-4e75-953b-b751a919e610@github.com>
 <0So-9C3Fb-LT2E9Vr1GIuP4BE7dQKshE8sUgYRIqyS8=.9c0f666e-46b8-408b-a046-f90d838332c1@github.com>
Message-ID: <_jNuGTE1vVGhshyY88g8YxphDy3eWnF4HP1kxytzTNE=.7e42f562-2268-4ef3-82da-25fb70c7820a@github.com>

On Mon, 6 Feb 2023 09:03:48 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

>> @ExE-Boss I think that immediately following `isNaN` checks give enough hint that we want NaN to be here.
>
> Ah I see, a comment explaining the intention would be helpful here, then

Ok, added some explanatory comments. Hopefully they clarify the intention.

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

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

From qamai at openjdk.org  Mon Feb  6 10:04:55 2023
From: qamai at openjdk.org (Quan Anh Mai)
Date: Mon, 6 Feb 2023 10:04:55 GMT
Subject: RFR: 8301226: Add clamp() methods to java.lang.Math and to
 StrictMath [v4]
In-Reply-To: <Ddvn1DCxT2qXxF7oOltTVKlnvkATfbHTuq7ZBtWWdwI=.bf25f42a-9fa0-4ee0-95a9-f0a7ab94434b@github.com>
References: <c7kJhZvT8oz5hScMxnWI23H7wjCaJ854ajjSRtxBnW4=.3f4e24ca-c608-4541-b80e-cf3452ec6400@github.com>
 <Ddvn1DCxT2qXxF7oOltTVKlnvkATfbHTuq7ZBtWWdwI=.bf25f42a-9fa0-4ee0-95a9-f0a7ab94434b@github.com>
Message-ID: <QloHZFnILCUk8VgnmEsdUK4pq4U-k6J-nssl6XrEE94=.58c2457d-d1ca-4fe4-9279-9d705952ccc5@github.com>

On Mon, 6 Feb 2023 09:46:15 GMT, Tagir F. Valeev <tvaleev at openjdk.org> wrote:

>> clamp() methods added to Math and StrictMath
>> 
>> `int clamp(long, int, int)` is somewhat different, as it accepts a `long` value and safely clamps it to an `int` range. Other overloads work with a particular type (long, float and double). Using similar approach in other cases (e.g. `float clamp(double, float, float)`) may cause accidental precision loss even if the value is within range, so I decided to avoid this.
>> 
>> In all cases, `max >= min` precondition should met. For double and float we additionally order `-0.0 < 0.0`, similarly to what Math.max or Double.compare do. In double and float overloads I try to keep at most one arg-check comparison on common path, so the order of checks might look unusual.
>> 
>> For tests, I noticed that tests in java/lang/Math don't use any testing framework (even newer tests), so I somehow mimic the approach of neighbour tests.
>
> Tagir F. Valeev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Added explanatory comments

Suggestion: Refactor the uncommon cases into separate functions so the compiler can have easier time inlining the common path. Thanks

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

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

From tvaleev at openjdk.org  Mon Feb  6 10:08:52 2023
From: tvaleev at openjdk.org (Tagir F. Valeev)
Date: Mon, 6 Feb 2023 10:08:52 GMT
Subject: RFR: 8301226: Add clamp() methods to java.lang.Math and to
 StrictMath [v4]
In-Reply-To: <QloHZFnILCUk8VgnmEsdUK4pq4U-k6J-nssl6XrEE94=.58c2457d-d1ca-4fe4-9279-9d705952ccc5@github.com>
References: <c7kJhZvT8oz5hScMxnWI23H7wjCaJ854ajjSRtxBnW4=.3f4e24ca-c608-4541-b80e-cf3452ec6400@github.com>
 <Ddvn1DCxT2qXxF7oOltTVKlnvkATfbHTuq7ZBtWWdwI=.bf25f42a-9fa0-4ee0-95a9-f0a7ab94434b@github.com>
 <QloHZFnILCUk8VgnmEsdUK4pq4U-k6J-nssl6XrEE94=.58c2457d-d1ca-4fe4-9279-9d705952ccc5@github.com>
Message-ID: <qX0y_xd58_EUcziidLVB7dMdXfVV5ObmOpaT9P258ow=.ca564934-26d3-4e4f-8e2d-f2ff5f42877d@github.com>

On Mon, 6 Feb 2023 10:01:49 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

> Suggestion: Refactor the uncommon cases into separate functions so the compiler can have easier time inlining the common path. Thanks

@merykitty this probably needs confirmation from VM folks. I'm pretty sure that C2 will be capable to do this having the profiling information, and I'm not sure whether we should optimize for C1. In any case, this could be done separately later, after careful benchmarking.

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

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

From rgiulietti at openjdk.org  Mon Feb  6 11:41:49 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Mon, 6 Feb 2023 11:41:49 GMT
Subject: RFR: JDK-8301444: Port fdlibm hyperbolic transcendental functions
 to Java
In-Reply-To: <_s8xnppoDTnAajAjlmfB-dX5DBdawUcSSPaGWGLzFBk=.cdbf468a-ace7-45e5-a25a-833c760b776c@github.com>
References: <_s8xnppoDTnAajAjlmfB-dX5DBdawUcSSPaGWGLzFBk=.cdbf468a-ace7-45e5-a25a-833c760b776c@github.com>
Message-ID: <fMzn-Bu9W5Lbqt1uTwKRQqu1lebKEUomO22TX0iMQc8=.4c547336-380c-4825-9cdb-bb091d6f8e75@github.com>

On Sun, 5 Feb 2023 03:05:55 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Initial pass of porting FDLIBM sinh/cosh/tanh to Java. I do intend to refactor the regression tests a bit to reduce duplication, but the actual ports should be ready for review.
> 
> Diff'ing the ports as before, original vs transliteration port:
> 
> 
> $ diff -w Hyperbolic.c Hyperbolic.translit.java
> 1c1
> < /* __ieee754_sinh(x)
> ---
>>     /**
> 17a18,19
>>     static class Sinh {
>>         private static final double one = 1.0, shuge = 1.0e307;
> 19,33c21
> < #include "fdlibm.h"
> < 
> < #ifdef __STDC__
> < static const double one = 1.0, shuge = 1.0e307;
> < #else
> < static double one = 1.0, shuge = 1.0e307;
> < #endif
> < 
> < #ifdef __STDC__
> <         double __ieee754_sinh(double x)
> < #else
> <         double __ieee754_sinh(x)
> <         double x;
> < #endif
> < {
> ---
>>         private static double compute(double x) {
> 36c24
> <         unsigned lx;
> ---
>>             /* unsigned */ int lx;
> 51c39
> <             t = expm1(fabs(x));
> ---
>>                 t = FdlibmTranslit.expm1(Math.abs(x));
> 57c45
> <         if (ix < 0x40862E42)  return h*__ieee754_exp(fabs(x));
> ---
>>             if (ix < 0x40862E42)  return h*StrictMath.exp(Math.abs(x)); // TODO switch to translit
> 60,62c48,52
> <         lx = *( (((*(unsigned*)&one)>>29)) + (unsigned*)&x);
> <         if (ix<0x408633CE || ((ix==0x408633ce)&&(lx<=(unsigned)0x8fb9f87d))) {
> <             w = __ieee754_exp(0.5*fabs(x));
> ---
>>             // lx = *( (((*(unsigned*)&one)>>29)) + (unsigned*)&x);
>>             // lx =  (((*(unsigned*)&one)>>29)) + (unsigned*)&x ;
>>             lx = __LO(x);
>>             if (ix<0x408633CE || ((ix==0x408633ce)&&(Long.compareUnsigned(lx, 0x8fb9f87d) <= 0 ))) {
>>                 w = StrictMath.exp(0.5*Math.abs(x)); // TODO switch to translit
> 70c60,62
> < /* __ieee754_cosh(x)
> ---
>>     }
>> 
>>     /**
> 90,105c82,84
> < 
> < #include "fdlibm.h"
> < 
> < #ifdef __STDC__
> < static const double one = 1.0, half=0.5, huge = 1.0e300;
> < #else
> < static double one = 1.0, half=0.5, huge = 1.0e300;
> < #endif
> < 
> < #ifdef __STDC__
> <         double __ieee754_cosh(double x)
> < #else
> <         double __ieee754_cosh(x)
> <         double x;
> < #endif
> < {
> ---
>>     static class Cosh {
>>         private static final double one = 1.0, half=0.5, huge = 1.0e300;
>>         private static double compute(double x) {
> 108c87
> <         unsigned lx;
> ---
>>             /*unsigned*/ int lx;
> 119c98
> <             t = expm1(fabs(x));
> ---
>>                 t = expm1(Math.abs(x));
> 127c106
> <                 t = __ieee754_exp(fabs(x));
> ---
>>                 t = StrictMath.exp(Math.abs(x)); // TODO switch to translit
> 132c111
> <         if (ix < 0x40862E42)  return half*__ieee754_exp(fabs(x));
> ---
>>             if (ix < 0x40862E42)  return half*StrictMath.exp(Math.abs(x)); // TODO switch to translit
> 135c114
> <         lx = *( (((*(unsigned*)&one)>>29)) + (unsigned*)&x);
> ---
>>             lx = __LO(x);
> 137,138c116,117
> <               ((ix==0x408633ce)&&(lx<=(unsigned)0x8fb9f87d))) {
> <             w = __ieee754_exp(half*fabs(x));
> ---
>>                 ((ix==0x408633ce)&&(Integer.compareUnsigned(lx, 0x8fb9f87d) <= 0))) {
>>                 w = StrictMath.exp(half*Math.abs(x)); // TODO switch to translit
> 146c125,127
> < /* Tanh(x)
> ---
>>     }
>> 
>>     /**
> 169,184c150,152
> < 
> < #include "fdlibm.h"
> < 
> < #ifdef __STDC__
> < static const double one=1.0, two=2.0, tiny = 1.0e-300;
> < #else
> < static double one=1.0, two=2.0, tiny = 1.0e-300;
> < #endif
> < 
> < #ifdef __STDC__
> <         double tanh(double x)
> < #else
> <         double tanh(x)
> <         double x;
> < #endif
> < {
> ---
>>     static class Tanh {
>>         private static final double one=1.0, two=2.0, tiny = 1.0e-300;
>>         static double compute(double x) {
> 203c171
> <                 t = expm1(two*fabs(x));
> ---
>>                     t = expm1(two*Math.abs(x));
> 206c174
> <                 t = expm1(-two*fabs(x));
> ---
>>                     t = expm1(-two*Math.abs(x));
> 214a183
>>     }
> 
> 
> Note that the original has a in-line version of the "__LO" macro rather than using the macro.
> 
> 
> And transliteration vs more idiomatic:
> 
> 
> $ diff -w Hyperbolic.translit.java Hyperbolic.fdlibm.java 
> 21c21
> <         private static double compute(double x) {
> ---
>>          static double compute(double x) {
> 26c26
> <             /* High word of |x|. */
> ---
>>             // High word of |x|
> 28c28
> <             ix = jx&0x7fffffff;
> ---
>>             ix = jx & 0x7fff_ffff;
> 30,31c30,33
> <             /* x is INF or NaN */
> <             if(ix>=0x7ff00000) return x+x;
> ---
>>             // x is INF or NaN
>>             if ( ix >= 0x7ff0_0000) {
>>                 return x + x;
>>             }
> 34,40c36,48
> <             if (jx<0) h = -h;
> <             /* |x| in [0,22], return sign(x)*0.5*(E+E/(E+1))) */
> <             if (ix < 0x40360000) {          /* |x|<22 */
> <                 if (ix<0x3e300000)          /* |x|<2**-28 */
> <                     if(shuge+x>one) return x;/* sinh(tiny) = tiny with inexact */
> <                 t = FdlibmTranslit.expm1(Math.abs(x));
> <                 if(ix<0x3ff00000) return h*(2.0*t-t*t/(t+one));
> ---
>>             if ( jx < 0) {
>>                 h = -h;
>>             }
>>             // |x| in [0,22], return sign(x)*0.5*(E+E/(E+1)))
>>             if (ix < 0x4036_0000) {          // |x| < 22
>>                 if (ix < 0x3e30_0000)        // |x| < 2**-28
>>                     if (shuge + x > one) {   // sinh(tiny) = tiny with inexact
>>                         return x;
>>                     }
>>                 t = StrictMath.expm1(Math.abs(x));
>>                 if (ix < 0x3ff0_0000) {
>>                     return h*(2.0 * t - t*t/(t + one));
>>                 }
> 44,45c52,55
> <             /* |x| in [22, log(maxdouble)] return 0.5*exp(|x|) */
> <             if (ix < 0x40862E42)  return h*StrictMath.exp(Math.abs(x)); // TODO switch to translit
> ---
>>             // |x| in [22, log(maxdouble)] return 0.5*exp(|x|)
>>             if (ix < 0x4086_2E42) {
>>                 return h*StrictMath.exp(Math.abs(x));
>>             }
> 47,49c57
> <             /* |x| in [log(maxdouble), overflowthresold] */
> <             // lx = *( (((*(unsigned*)&one)>>29)) + (unsigned*)&x);
> <             // lx =  (((*(unsigned*)&one)>>29)) + (unsigned*)&x ;
> ---
>>             // |x| in [log(maxdouble), overflowthresold]
> 51,52c59,62
> <             if (ix<0x408633CE || ((ix==0x408633ce)&&(Long.compareUnsigned(lx, 0x8fb9f87d) <= 0 ))) {
> <                 w = StrictMath.exp(0.5*Math.abs(x)); // TODO switch to translit
> ---
>>             if (ix < 0x4086_33CE ||
>>                 ((ix == 0x4086_33ce) &&
>>                  (Long.compareUnsigned(lx, 0x8fb9_f87d) <= 0 ))) {
>>                 w = StrictMath.exp(0.5 * Math.abs(x));
> 57c67
> <             /* |x| > overflowthresold, sinh(x) overflow */
> ---
>>             // |x| > overflowthresold, sinh(x) overflow
> 84c94
> <         private static double compute(double x) {
> ---
>>         static double compute(double x) {
> 89c99
> <             /* High word of |x|. */
> ---
>>             // High word of |x|
> 91c101
> <             ix &= 0x7fffffff;
> ---
>>             ix &= 0x7fff_ffff;
> 93,94c103,106
> <             /* x is INF or NaN */
> <             if(ix>=0x7ff00000) return x*x;
> ---
>>             // x is INF or NaN
>>             if (ix >= 0x7ff_00000) {
>>                 return x*x;
>>             }
> 96,98c108,110
> <             /* |x| in [0,0.5*ln2], return 1+expm1(|x|)^2/(2*exp(|x|)) */
> <             if(ix<0x3fd62e43) {
> <                 t = expm1(Math.abs(x));
> ---
>>             // |x| in [0,0.5*ln2], return 1+expm1(|x|)^2/(2*exp(|x|))
>>             if (ix < 0x3fd6_2e43) {
>>                 t = StrictMath.expm1(Math.abs(x));
> 100c112,114
> <                 if (ix<0x3c800000) return w;        /* cosh(tiny) = 1 */
> ---
>>                 if (ix < 0x3c80_0000) { // cosh(tiny) = 1
>>                     return w;
>>                 }
> 104,106c118,120
> <             /* |x| in [0.5*ln2,22], return (exp(|x|)+1/exp(|x|)/2; */
> <             if (ix < 0x40360000) {
> <                 t = StrictMath.exp(Math.abs(x)); // TODO switch to translit
> ---
>>             // |x| in [0.5*ln2, 22], return (exp(|x|) + 1/exp(|x|)/2
>>             if (ix < 0x4036_0000) {
>>                 t = StrictMath.exp(Math.abs(x));
> 110,111c124,127
> <             /* |x| in [22, log(maxdouble)] return half*exp(|x|) */
> <             if (ix < 0x40862E42)  return half*StrictMath.exp(Math.abs(x)); // TODO switch to translit
> ---
>>             // |x| in [22, log(maxdouble)] return half*exp(|x|)
>>             if (ix < 0x4086_2E42) {
>>                 return half*StrictMath.exp(Math.abs(x));
>>             }
> 113c129
> <             /* |x| in [log(maxdouble), overflowthresold] */
> ---
>>             // |x| in [log(maxdouble), overflowthresold]
> 115,117c131,134
> <             if (ix<0x408633CE ||
> <                 ((ix==0x408633ce)&&(Integer.compareUnsigned(lx, 0x8fb9f87d) <= 0))) {
> <                 w = StrictMath.exp(half*Math.abs(x)); // TODO switch to translit
> ---
>>             if (ix<0x4086_33CE ||
>>                 ((ix == 0x4086_33ce) &&
>>                  (Integer.compareUnsigned(lx, 0x8fb9_f87d) <= 0))) {
>>                 w = StrictMath.exp(half*Math.abs(x));
> 122c139
> <             /* |x| > overflowthresold, cosh(x) overflow */
> ---
>>             // |x| > overflowthresold, cosh(x) overflow
> 126d142
> < 
> 156c172
> <             /* High word of |x|. */
> ---
>>             // High word of |x|.
> 158c174
> <             ix = jx&0x7fffffff;
> ---
>>             ix = jx & 0x7fff_ffff;
> 160,163c176,182
> <             /* x is INF or NaN */
> <             if(ix>=0x7ff00000) {
> <                 if (jx>=0) return one/x+one;    /* tanh(+-inf)=+-1 */
> <                 else       return one/x-one;    /* tanh(NaN) = NaN */
> ---
>>             // x is INF or NaN
>>             if (ix >= 0x7ff0_0000) {
>>                 if (jx >= 0) {  // tanh(+-inf)=+-1
>>                     return one/x + one;
>>                 } else {        // tanh(NaN) = NaN
>>                     return one/x - one;
>>                 }
> 166,171c185,190
> <             /* |x| < 22 */
> <             if (ix < 0x40360000) {          /* |x|<22 */
> <                 if (ix<0x3c800000)          /* |x|<2**-55 */
> <                     return x*(one+x);       /* tanh(small) = small */
> <                 if (ix>=0x3ff00000) {       /* |x|>=1  */
> <                     t = expm1(two*Math.abs(x));
> ---
>>             // |x| < 22
>>             if (ix < 0x4036_0000) {          // |x| < 22
>>                 if (ix<0x3c80_0000)          // |x| < 2**-55
>>                     return x*(one + x);      // tanh(small) = small
>>                 if (ix>=0x3ff0_0000) {       // |x| >= 1
>>                     t = StrictMath.expm1(two*Math.abs(x));
> 174c193
> <                     t = expm1(-two*Math.abs(x));
> ---
>>                     t = StrictMath.expm1(-two*Math.abs(x));
> 177,179c196,197
> <                 /* |x| > 22, return +-1 */
> <             } else {
> <                 z = one - tiny;             /* raised inexact flag */
> ---
>>             } else { // |x| > 22, return +-1
>>                 z = one - tiny;             // raised inexact flag

test/jdk/java/lang/StrictMath/FdlibmTranslit.java line 874:

> 872:             // lx = *( (((*(unsigned*)&one)>>29)) + (unsigned*)&x);
> 873:             // lx =  (((*(unsigned*)&one)>>29)) + (unsigned*)&x ;
> 874:             lx = __LO(x);

This aspect of the transliteration is unclear.
The C code seems to ignore endianness of `double` values, and there's a shift by 29 that seems intentional for some reason.
Are we safe with the `__LO(x)` transliteration?

test/jdk/java/lang/StrictMath/FdlibmTranslit.java line 938:

> 936: 
> 937:             /* |x| in [log(maxdouble), overflowthresold] */
> 938:             lx = __LO(x);

Same concern as above about the transliteration to `__LO(x)`

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

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

From duke at openjdk.org  Mon Feb  6 11:44:07 2023
From: duke at openjdk.org (SUN Guoyun)
Date: Mon, 6 Feb 2023 11:44:07 GMT
Subject: RFR: 8301737:
 java/rmi/server/UnicastRemoteObject/serialFilter/FilterUROTest.java fail with
 -Xcomp [v2]
In-Reply-To: <l5m5_9io2QMSFNY7dBHT3Nr2I9Er8wmd92Ze8FP-XE0=.a40d29be-77be-4719-a0a0-71d032eea1e5@github.com>
References: <l5m5_9io2QMSFNY7dBHT3Nr2I9Er8wmd92Ze8FP-XE0=.a40d29be-77be-4719-a0a0-71d032eea1e5@github.com>
Message-ID: <_KLsDrGvRYUmtKo962dExyk9Ajb6blQnPOXbGpO5mN0=.bdb33bcb-799d-4a8f-979a-bb0c2f3ce3a1@github.com>

> Hi all,
> When -Xcomp be used, java thread to block for longer, then causing this test failed frequently on the AArch64 and LoongArch64 architecture.
> 
> This PR fix the issue, Please help review it.
> 
> Thanks.

SUN Guoyun has updated the pull request incrementally with one additional commit since the last revision:

  8301737: java/rmi/server/UnicastRemoteObject/serialFilter/FilterUROTest.java fail with -Xcomp

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12399/files
  - new: https://git.openjdk.org/jdk/pull/12399/files/517b9fc4..650c8163

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

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

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

From rgiulietti at openjdk.org  Mon Feb  6 11:48:52 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Mon, 6 Feb 2023 11:48:52 GMT
Subject: RFR: JDK-8301444: Port fdlibm hyperbolic transcendental functions
 to Java
In-Reply-To: <_s8xnppoDTnAajAjlmfB-dX5DBdawUcSSPaGWGLzFBk=.cdbf468a-ace7-45e5-a25a-833c760b776c@github.com>
References: <_s8xnppoDTnAajAjlmfB-dX5DBdawUcSSPaGWGLzFBk=.cdbf468a-ace7-45e5-a25a-833c760b776c@github.com>
Message-ID: <zdXmt8AodusBXiKjq9nKRDW5wh6pMyzV9zjpdk3gZVo=.0694ea22-a2c2-4234-84a3-251e2ac1a026@github.com>

On Sun, 5 Feb 2023 03:05:55 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Initial pass of porting FDLIBM sinh/cosh/tanh to Java. I do intend to refactor the regression tests a bit to reduce duplication, but the actual ports should be ready for review.
> 
> Diff'ing the ports as before, original vs transliteration port:
> 
> 
> $ diff -w Hyperbolic.c Hyperbolic.translit.java
> 1c1
> < /* __ieee754_sinh(x)
> ---
>>     /**
> 17a18,19
>>     static class Sinh {
>>         private static final double one = 1.0, shuge = 1.0e307;
> 19,33c21
> < #include "fdlibm.h"
> < 
> < #ifdef __STDC__
> < static const double one = 1.0, shuge = 1.0e307;
> < #else
> < static double one = 1.0, shuge = 1.0e307;
> < #endif
> < 
> < #ifdef __STDC__
> <         double __ieee754_sinh(double x)
> < #else
> <         double __ieee754_sinh(x)
> <         double x;
> < #endif
> < {
> ---
>>         private static double compute(double x) {
> 36c24
> <         unsigned lx;
> ---
>>             /* unsigned */ int lx;
> 51c39
> <             t = expm1(fabs(x));
> ---
>>                 t = FdlibmTranslit.expm1(Math.abs(x));
> 57c45
> <         if (ix < 0x40862E42)  return h*__ieee754_exp(fabs(x));
> ---
>>             if (ix < 0x40862E42)  return h*StrictMath.exp(Math.abs(x)); // TODO switch to translit
> 60,62c48,52
> <         lx = *( (((*(unsigned*)&one)>>29)) + (unsigned*)&x);
> <         if (ix<0x408633CE || ((ix==0x408633ce)&&(lx<=(unsigned)0x8fb9f87d))) {
> <             w = __ieee754_exp(0.5*fabs(x));
> ---
>>             // lx = *( (((*(unsigned*)&one)>>29)) + (unsigned*)&x);
>>             // lx =  (((*(unsigned*)&one)>>29)) + (unsigned*)&x ;
>>             lx = __LO(x);
>>             if (ix<0x408633CE || ((ix==0x408633ce)&&(Long.compareUnsigned(lx, 0x8fb9f87d) <= 0 ))) {
>>                 w = StrictMath.exp(0.5*Math.abs(x)); // TODO switch to translit
> 70c60,62
> < /* __ieee754_cosh(x)
> ---
>>     }
>> 
>>     /**
> 90,105c82,84
> < 
> < #include "fdlibm.h"
> < 
> < #ifdef __STDC__
> < static const double one = 1.0, half=0.5, huge = 1.0e300;
> < #else
> < static double one = 1.0, half=0.5, huge = 1.0e300;
> < #endif
> < 
> < #ifdef __STDC__
> <         double __ieee754_cosh(double x)
> < #else
> <         double __ieee754_cosh(x)
> <         double x;
> < #endif
> < {
> ---
>>     static class Cosh {
>>         private static final double one = 1.0, half=0.5, huge = 1.0e300;
>>         private static double compute(double x) {
> 108c87
> <         unsigned lx;
> ---
>>             /*unsigned*/ int lx;
> 119c98
> <             t = expm1(fabs(x));
> ---
>>                 t = expm1(Math.abs(x));
> 127c106
> <                 t = __ieee754_exp(fabs(x));
> ---
>>                 t = StrictMath.exp(Math.abs(x)); // TODO switch to translit
> 132c111
> <         if (ix < 0x40862E42)  return half*__ieee754_exp(fabs(x));
> ---
>>             if (ix < 0x40862E42)  return half*StrictMath.exp(Math.abs(x)); // TODO switch to translit
> 135c114
> <         lx = *( (((*(unsigned*)&one)>>29)) + (unsigned*)&x);
> ---
>>             lx = __LO(x);
> 137,138c116,117
> <               ((ix==0x408633ce)&&(lx<=(unsigned)0x8fb9f87d))) {
> <             w = __ieee754_exp(half*fabs(x));
> ---
>>                 ((ix==0x408633ce)&&(Integer.compareUnsigned(lx, 0x8fb9f87d) <= 0))) {
>>                 w = StrictMath.exp(half*Math.abs(x)); // TODO switch to translit
> 146c125,127
> < /* Tanh(x)
> ---
>>     }
>> 
>>     /**
> 169,184c150,152
> < 
> < #include "fdlibm.h"
> < 
> < #ifdef __STDC__
> < static const double one=1.0, two=2.0, tiny = 1.0e-300;
> < #else
> < static double one=1.0, two=2.0, tiny = 1.0e-300;
> < #endif
> < 
> < #ifdef __STDC__
> <         double tanh(double x)
> < #else
> <         double tanh(x)
> <         double x;
> < #endif
> < {
> ---
>>     static class Tanh {
>>         private static final double one=1.0, two=2.0, tiny = 1.0e-300;
>>         static double compute(double x) {
> 203c171
> <                 t = expm1(two*fabs(x));
> ---
>>                     t = expm1(two*Math.abs(x));
> 206c174
> <                 t = expm1(-two*fabs(x));
> ---
>>                     t = expm1(-two*Math.abs(x));
> 214a183
>>     }
> 
> 
> Note that the original has a in-line version of the "__LO" macro rather than using the macro.
> 
> 
> And transliteration vs more idiomatic:
> 
> 
> $ diff -w Hyperbolic.translit.java Hyperbolic.fdlibm.java 
> 21c21
> <         private static double compute(double x) {
> ---
>>          static double compute(double x) {
> 26c26
> <             /* High word of |x|. */
> ---
>>             // High word of |x|
> 28c28
> <             ix = jx&0x7fffffff;
> ---
>>             ix = jx & 0x7fff_ffff;
> 30,31c30,33
> <             /* x is INF or NaN */
> <             if(ix>=0x7ff00000) return x+x;
> ---
>>             // x is INF or NaN
>>             if ( ix >= 0x7ff0_0000) {
>>                 return x + x;
>>             }
> 34,40c36,48
> <             if (jx<0) h = -h;
> <             /* |x| in [0,22], return sign(x)*0.5*(E+E/(E+1))) */
> <             if (ix < 0x40360000) {          /* |x|<22 */
> <                 if (ix<0x3e300000)          /* |x|<2**-28 */
> <                     if(shuge+x>one) return x;/* sinh(tiny) = tiny with inexact */
> <                 t = FdlibmTranslit.expm1(Math.abs(x));
> <                 if(ix<0x3ff00000) return h*(2.0*t-t*t/(t+one));
> ---
>>             if ( jx < 0) {
>>                 h = -h;
>>             }
>>             // |x| in [0,22], return sign(x)*0.5*(E+E/(E+1)))
>>             if (ix < 0x4036_0000) {          // |x| < 22
>>                 if (ix < 0x3e30_0000)        // |x| < 2**-28
>>                     if (shuge + x > one) {   // sinh(tiny) = tiny with inexact
>>                         return x;
>>                     }
>>                 t = StrictMath.expm1(Math.abs(x));
>>                 if (ix < 0x3ff0_0000) {
>>                     return h*(2.0 * t - t*t/(t + one));
>>                 }
> 44,45c52,55
> <             /* |x| in [22, log(maxdouble)] return 0.5*exp(|x|) */
> <             if (ix < 0x40862E42)  return h*StrictMath.exp(Math.abs(x)); // TODO switch to translit
> ---
>>             // |x| in [22, log(maxdouble)] return 0.5*exp(|x|)
>>             if (ix < 0x4086_2E42) {
>>                 return h*StrictMath.exp(Math.abs(x));
>>             }
> 47,49c57
> <             /* |x| in [log(maxdouble), overflowthresold] */
> <             // lx = *( (((*(unsigned*)&one)>>29)) + (unsigned*)&x);
> <             // lx =  (((*(unsigned*)&one)>>29)) + (unsigned*)&x ;
> ---
>>             // |x| in [log(maxdouble), overflowthresold]
> 51,52c59,62
> <             if (ix<0x408633CE || ((ix==0x408633ce)&&(Long.compareUnsigned(lx, 0x8fb9f87d) <= 0 ))) {
> <                 w = StrictMath.exp(0.5*Math.abs(x)); // TODO switch to translit
> ---
>>             if (ix < 0x4086_33CE ||
>>                 ((ix == 0x4086_33ce) &&
>>                  (Long.compareUnsigned(lx, 0x8fb9_f87d) <= 0 ))) {
>>                 w = StrictMath.exp(0.5 * Math.abs(x));
> 57c67
> <             /* |x| > overflowthresold, sinh(x) overflow */
> ---
>>             // |x| > overflowthresold, sinh(x) overflow
> 84c94
> <         private static double compute(double x) {
> ---
>>         static double compute(double x) {
> 89c99
> <             /* High word of |x|. */
> ---
>>             // High word of |x|
> 91c101
> <             ix &= 0x7fffffff;
> ---
>>             ix &= 0x7fff_ffff;
> 93,94c103,106
> <             /* x is INF or NaN */
> <             if(ix>=0x7ff00000) return x*x;
> ---
>>             // x is INF or NaN
>>             if (ix >= 0x7ff_00000) {
>>                 return x*x;
>>             }
> 96,98c108,110
> <             /* |x| in [0,0.5*ln2], return 1+expm1(|x|)^2/(2*exp(|x|)) */
> <             if(ix<0x3fd62e43) {
> <                 t = expm1(Math.abs(x));
> ---
>>             // |x| in [0,0.5*ln2], return 1+expm1(|x|)^2/(2*exp(|x|))
>>             if (ix < 0x3fd6_2e43) {
>>                 t = StrictMath.expm1(Math.abs(x));
> 100c112,114
> <                 if (ix<0x3c800000) return w;        /* cosh(tiny) = 1 */
> ---
>>                 if (ix < 0x3c80_0000) { // cosh(tiny) = 1
>>                     return w;
>>                 }
> 104,106c118,120
> <             /* |x| in [0.5*ln2,22], return (exp(|x|)+1/exp(|x|)/2; */
> <             if (ix < 0x40360000) {
> <                 t = StrictMath.exp(Math.abs(x)); // TODO switch to translit
> ---
>>             // |x| in [0.5*ln2, 22], return (exp(|x|) + 1/exp(|x|)/2
>>             if (ix < 0x4036_0000) {
>>                 t = StrictMath.exp(Math.abs(x));
> 110,111c124,127
> <             /* |x| in [22, log(maxdouble)] return half*exp(|x|) */
> <             if (ix < 0x40862E42)  return half*StrictMath.exp(Math.abs(x)); // TODO switch to translit
> ---
>>             // |x| in [22, log(maxdouble)] return half*exp(|x|)
>>             if (ix < 0x4086_2E42) {
>>                 return half*StrictMath.exp(Math.abs(x));
>>             }
> 113c129
> <             /* |x| in [log(maxdouble), overflowthresold] */
> ---
>>             // |x| in [log(maxdouble), overflowthresold]
> 115,117c131,134
> <             if (ix<0x408633CE ||
> <                 ((ix==0x408633ce)&&(Integer.compareUnsigned(lx, 0x8fb9f87d) <= 0))) {
> <                 w = StrictMath.exp(half*Math.abs(x)); // TODO switch to translit
> ---
>>             if (ix<0x4086_33CE ||
>>                 ((ix == 0x4086_33ce) &&
>>                  (Integer.compareUnsigned(lx, 0x8fb9_f87d) <= 0))) {
>>                 w = StrictMath.exp(half*Math.abs(x));
> 122c139
> <             /* |x| > overflowthresold, cosh(x) overflow */
> ---
>>             // |x| > overflowthresold, cosh(x) overflow
> 126d142
> < 
> 156c172
> <             /* High word of |x|. */
> ---
>>             // High word of |x|.
> 158c174
> <             ix = jx&0x7fffffff;
> ---
>>             ix = jx & 0x7fff_ffff;
> 160,163c176,182
> <             /* x is INF or NaN */
> <             if(ix>=0x7ff00000) {
> <                 if (jx>=0) return one/x+one;    /* tanh(+-inf)=+-1 */
> <                 else       return one/x-one;    /* tanh(NaN) = NaN */
> ---
>>             // x is INF or NaN
>>             if (ix >= 0x7ff0_0000) {
>>                 if (jx >= 0) {  // tanh(+-inf)=+-1
>>                     return one/x + one;
>>                 } else {        // tanh(NaN) = NaN
>>                     return one/x - one;
>>                 }
> 166,171c185,190
> <             /* |x| < 22 */
> <             if (ix < 0x40360000) {          /* |x|<22 */
> <                 if (ix<0x3c800000)          /* |x|<2**-55 */
> <                     return x*(one+x);       /* tanh(small) = small */
> <                 if (ix>=0x3ff00000) {       /* |x|>=1  */
> <                     t = expm1(two*Math.abs(x));
> ---
>>             // |x| < 22
>>             if (ix < 0x4036_0000) {          // |x| < 22
>>                 if (ix<0x3c80_0000)          // |x| < 2**-55
>>                     return x*(one + x);      // tanh(small) = small
>>                 if (ix>=0x3ff0_0000) {       // |x| >= 1
>>                     t = StrictMath.expm1(two*Math.abs(x));
> 174c193
> <                     t = expm1(-two*Math.abs(x));
> ---
>>                     t = StrictMath.expm1(-two*Math.abs(x));
> 177,179c196,197
> <                 /* |x| > 22, return +-1 */
> <             } else {
> <                 z = one - tiny;             /* raised inexact flag */
> ---
>>             } else { // |x| > 22, return +-1
>>                 z = one - tiny;             // raised inexact flag

src/java.base/share/classes/java/lang/FdLibm.java line 1301:

> 1299: 
> 1300:             // x is INF or NaN
> 1301:             if (ix >= 0x7ff_00000) {

For consistency with L.1228 and L.1374:
`ix >= 0x7ff0_0000`

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

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

From duke at openjdk.org  Mon Feb  6 11:59:50 2023
From: duke at openjdk.org (SUN Guoyun)
Date: Mon, 6 Feb 2023 11:59:50 GMT
Subject: RFR: 8301737:
 java/rmi/server/UnicastRemoteObject/serialFilter/FilterUROTest.java fail with
 -Xcomp [v2]
In-Reply-To: <_KLsDrGvRYUmtKo962dExyk9Ajb6blQnPOXbGpO5mN0=.bdb33bcb-799d-4a8f-979a-bb0c2f3ce3a1@github.com>
References: <l5m5_9io2QMSFNY7dBHT3Nr2I9Er8wmd92Ze8FP-XE0=.a40d29be-77be-4719-a0a0-71d032eea1e5@github.com>
 <_KLsDrGvRYUmtKo962dExyk9Ajb6blQnPOXbGpO5mN0=.bdb33bcb-799d-4a8f-979a-bb0c2f3ce3a1@github.com>
Message-ID: <oZlgJu_DE08L_O403yCNq6MH5e74Wh6Bo4VQIQnd_S0=.32c1fdaa-0820-4c3d-b6ed-b9dee8bad3af@github.com>

On Mon, 6 Feb 2023 11:44:07 GMT, SUN Guoyun <duke at openjdk.org> wrote:

>> Hi all,
>> When -Xcomp be used, this testcase will use more codecaches, causing the GC to be triggered early, then causing this test failed on LoongArch64 architecture.
>> 
>> This PR fix the issue, Please help review it.
>> 
>> Thanks.
>
> SUN Guoyun has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8301737: java/rmi/server/UnicastRemoteObject/serialFilter/FilterUROTest.java fail with -Xcomp

I found the non-permanent target will be collection by GC early with `-Xcomp`. using `-Xlog:gc` can found the reason is:
`GC(0) Pause Young (Concurrent Start) (CodeCache GC Threshold) 12M->2M(258M) 16.437ms`
so I add `-XX:ReservedCodeCacheSize=512m` to make sure the test PASSED. Please review again, thank you.

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

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

From duke at openjdk.org  Mon Feb  6 11:59:52 2023
From: duke at openjdk.org (SUN Guoyun)
Date: Mon, 6 Feb 2023 11:59:52 GMT
Subject: RFR: 8301737:
 java/rmi/server/UnicastRemoteObject/serialFilter/FilterUROTest.java fail with
 -Xcomp [v2]
In-Reply-To: <Q5-8OMpjBinptXuXoM7dVpJez7QbnKAN1l2NA8sGdAM=.195aa190-2cbd-4532-8a8f-024354da17b3@github.com>
References: <l5m5_9io2QMSFNY7dBHT3Nr2I9Er8wmd92Ze8FP-XE0=.a40d29be-77be-4719-a0a0-71d032eea1e5@github.com>
 <Rx4Yso3GBMPTSCb-ofT80DXdRkVkxl8r1Di6Ay3XhUo=.8b150a73-58f3-4aaf-af1a-9445ee9064bd@github.com>
 <Q5-8OMpjBinptXuXoM7dVpJez7QbnKAN1l2NA8sGdAM=.195aa190-2cbd-4532-8a8f-024354da17b3@github.com>
Message-ID: <ibcDdRc6gA_u4UrYuePCAk1aSdRX4Ck67EZz7g_9UVM=.107b3862-58b8-4a59-8b13-adcdf327352d@github.com>

On Mon, 6 Feb 2023 02:46:46 GMT, SUN Guoyun <duke at openjdk.org> wrote:

>> test/jdk/java/rmi/server/UnicastRemoteObject/serialFilter/FilterUROTest.java line 41:
>> 
>>> 39: /*
>>> 40:  * @test
>>> 41:  * @run testng/othervm -Dsun.net.httpserver.idleInterval=50000 FilterUROTest
>> 
>> This test doesn't seem to be using an HttpServer so setting this system property seems useless as it should have no effect.
>
> Sorry, I was mistaken. I'll fix it later

Done. please review again, thank you.

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

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

From duke at openjdk.org  Mon Feb  6 12:14:52 2023
From: duke at openjdk.org (SUN Guoyun)
Date: Mon, 6 Feb 2023 12:14:52 GMT
Subject: RFR: 8301737:
 java/rmi/server/UnicastRemoteObject/serialFilter/FilterUROTest.java fail with
 -Xcomp
In-Reply-To: <L33z7qV77oHz2xnVX-S_od1es6PXKuW6g8Zt7HXvHCg=.e0964097-b507-4a28-a10e-08c976b78a87@github.com>
References: <l5m5_9io2QMSFNY7dBHT3Nr2I9Er8wmd92Ze8FP-XE0=.a40d29be-77be-4719-a0a0-71d032eea1e5@github.com>
 <L33z7qV77oHz2xnVX-S_od1es6PXKuW6g8Zt7HXvHCg=.e0964097-b507-4a28-a10e-08c976b78a87@github.com>
Message-ID: <wy_e5WfJ7CrL-2x73_fiWz-GJ58ZDxXEirku44As2xQ=.e419915d-91f8-4467-ab12-05ffd23f501c@github.com>

On Fri, 3 Feb 2023 15:07:30 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> What is the connection between -Xcomp and the fix: `-Dsun.net.httpserver.idleInterval=50000`? The test does not use httpserver. Perhaps jtreg /agent does, but an explanation of the interaction would be appreciated.

Please review again, thank you.

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

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

From asotona at openjdk.org  Mon Feb  6 12:44:57 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 6 Feb 2023 12:44:57 GMT
Subject: RFR: 8294982: Implementation of Classfile API [v12]
In-Reply-To: <c022hrWNEHW76nhP_sXTQXCTjtL8jjM8r_yYv0IvbPI=.2a9cfbae-2fef-4cdb-8189-b869b1513fef@github.com>
References: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
 <Q4VeZ2yWAg85FqUDJa5hYq3jHty5H547gD0H-x3oIq0=.58d463a4-237a-4fee-bd0f-83262d49522a@github.com>
 <c022hrWNEHW76nhP_sXTQXCTjtL8jjM8r_yYv0IvbPI=.2a9cfbae-2fef-4cdb-8189-b869b1513fef@github.com>
Message-ID: <xWZSZo4TZ9iFr1eJSCmR7rd3Qw3pX78wwyjZfO79N20=.1ce95c71-7267-4f56-bd21-141301e64b6f@github.com>

On Fri, 3 Feb 2023 17:22:32 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Classfile API moved under jdk.internal.classfile package
>
> src/java.base/share/classes/jdk/internal/classfile/TypeAnnotation.java line 75:
> 
>> 73:      * The kind of target on which the annotation appears.
>> 74:      */
>> 75:     public enum TargetType {
> 
> My IDE says this enum is not being used. I tend to believe it, since the TargetInfo sealed interface also seems to model the same thing?

There is only one TargetInfo for all TargetTypes, so instead of 22 sub-interfaces of TargetInfo, the instance of TargetType enum is hold in TargetInfo.

> src/java.base/share/classes/jdk/internal/classfile/TypeAnnotation.java line 577:
> 
>> 575: 
>> 576:     /**
>> 577:      * type_path.path.
> 
> The javadoc in this class seems off

will fix, thanks

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

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

From vtewari at openjdk.org  Mon Feb  6 12:48:49 2023
From: vtewari at openjdk.org (Vyom Tewari)
Date: Mon, 6 Feb 2023 12:48:49 GMT
Subject: RFR: JDK-8301621: libzip should use pread instead of lseek+read
In-Reply-To: <pjSF1ED9D3FXjCFeqz2MRllCf0UT9suWaYa4O7kFeCM=.d16583a7-2c82-46c2-aaf1-2102c8978f2b@github.com>
References: <pjSF1ED9D3FXjCFeqz2MRllCf0UT9suWaYa4O7kFeCM=.d16583a7-2c82-46c2-aaf1-2102c8978f2b@github.com>
Message-ID: <yWtchn11mKE_M1gIMbS-nd7Rb2GSAuTNgR2ksSkXTUw=.8bb364a0-500a-4431-b384-d700cfdd3a0a@github.com>

On Fri, 3 Feb 2023 19:49:44 GMT, Justin King <jcking at openjdk.org> wrote:

> Avoid using `lseek` + `read` in favor of `pread`. For Windows, we can do the same thing by using `OVERLAPPED`, as we are in synchronous mode we can use `Offset` and `OffsetHigh` to achieve the same thing.
> 
> Additionally I updated open to use `O_CLOEXEC` when available, as that really should be used.

src/java.base/share/native/libzip/zip_util.c line 227:

> 225:       number_of_bytes_to_read = (DWORD) (nbytes - total);
> 226:     }
> 227:     number_of_bytes_read = 0;

do we really need to set number_of_bytes_read = 0 in every iteration ? .  As per MSDN it looks like ReadFile will do it implicitly.

[out, optional] lpNumberOfBytesRead

A pointer to the variable that receives the number of bytes read when using a synchronous hFile parameter. ReadFile sets this value to zero before doing any work or error checking. Use NULL for this parameter if this is an asynchronous operation to avoid potentially erroneous results.

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

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

From asotona at openjdk.org  Mon Feb  6 12:59:52 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 6 Feb 2023 12:59:52 GMT
Subject: RFR: 8294982: Implementation of Classfile API [v12]
In-Reply-To: <c022hrWNEHW76nhP_sXTQXCTjtL8jjM8r_yYv0IvbPI=.2a9cfbae-2fef-4cdb-8189-b869b1513fef@github.com>
References: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
 <Q4VeZ2yWAg85FqUDJa5hYq3jHty5H547gD0H-x3oIq0=.58d463a4-237a-4fee-bd0f-83262d49522a@github.com>
 <c022hrWNEHW76nhP_sXTQXCTjtL8jjM8r_yYv0IvbPI=.2a9cfbae-2fef-4cdb-8189-b869b1513fef@github.com>
Message-ID: <WYk_uF6k545myEF_jlt-3hWca2kkbTeCMzUMWjoennI=.cdf77ab2-81a2-42a3-b47c-81be7d981f51@github.com>

On Fri, 3 Feb 2023 17:23:51 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Classfile API moved under jdk.internal.classfile package
>
> src/java.base/share/classes/jdk/internal/classfile/TypeAnnotation.java line 641:
> 
>> 639:         int typeArgumentIndex();
>> 640: 
>> 641:         static TypePathComponent of(int typePathKind, int typeArgumentIndex) {
> 
> Should this take a `Kind` instead of an `int`?

Yes, will fix, thanks.

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

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

From asotona at openjdk.org  Mon Feb  6 13:02:54 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 6 Feb 2023 13:02:54 GMT
Subject: RFR: 8294982: Implementation of Classfile API [v12]
In-Reply-To: <c022hrWNEHW76nhP_sXTQXCTjtL8jjM8r_yYv0IvbPI=.2a9cfbae-2fef-4cdb-8189-b869b1513fef@github.com>
References: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
 <Q4VeZ2yWAg85FqUDJa5hYq3jHty5H547gD0H-x3oIq0=.58d463a4-237a-4fee-bd0f-83262d49522a@github.com>
 <c022hrWNEHW76nhP_sXTQXCTjtL8jjM8r_yYv0IvbPI=.2a9cfbae-2fef-4cdb-8189-b869b1513fef@github.com>
Message-ID: <Sd27fH9teWjwNVcNtVhEm5bGcOYA1zo14GR1Zz26Bbs=.4bac577d-bb01-49ac-b585-29758b816759@github.com>

On Fri, 3 Feb 2023 17:20:19 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Classfile API moved under jdk.internal.classfile package
>
> src/java.base/share/classes/jdk/internal/classfile/TypeAnnotation.java line 617:
> 
>> 615:         }
>> 616: 
>> 617:         public static final TypePathComponent ARRAY = new UnboundAttribute.TypePathComponentImpl(Kind.ARRAY, 0);
> 
> `public static final` is redundant here (it's an interface) - please check these (I've seen others). E.g. all `public` modifier for types nested in interfaces are redundant as well.

yes, will fix and search for other such cases, thanks.

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

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

From asotona at openjdk.org  Mon Feb  6 13:21:57 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 6 Feb 2023 13:21:57 GMT
Subject: RFR: 8294982: Implementation of Classfile API [v12]
In-Reply-To: <c022hrWNEHW76nhP_sXTQXCTjtL8jjM8r_yYv0IvbPI=.2a9cfbae-2fef-4cdb-8189-b869b1513fef@github.com>
References: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
 <Q4VeZ2yWAg85FqUDJa5hYq3jHty5H547gD0H-x3oIq0=.58d463a4-237a-4fee-bd0f-83262d49522a@github.com>
 <c022hrWNEHW76nhP_sXTQXCTjtL8jjM8r_yYv0IvbPI=.2a9cfbae-2fef-4cdb-8189-b869b1513fef@github.com>
Message-ID: <0w7b4dGcbkGxU1JL3pmoyjaXA2U91cwyp9Ule0uu_q4=.4e29b9c0-47e3-4ed9-9110-338d13ab9db1@github.com>

On Fri, 3 Feb 2023 17:32:37 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Classfile API moved under jdk.internal.classfile package
>
> src/java.base/share/classes/jdk/internal/classfile/attribute/SignatureAttribute.java line 66:
> 
>> 64: 
>> 65:     /**
>> 66:      * Parse the siganture as a method signature.
> 
> typo here `siganture` - check the entire class

will fix, thanks

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

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

From heinz at javaspecialists.eu  Mon Feb  6 13:26:04 2023
From: heinz at javaspecialists.eu (Dr Heinz M. Kabutz)
Date: Mon, 6 Feb 2023 15:26:04 +0200
Subject: JEP415: FilterInThread Example
In-Reply-To: <1555d359-0a01-764d-c014-f2b5b678cabb@oracle.com>
References: <76209504-e958-b981-8b6b-b90955fd5f5d@javaspecialists.eu>
 <1555d359-0a01-764d-c014-f2b5b678cabb@oracle.com>
Message-ID: <2e76369a-2569-c406-9e3f-85a3854c68ce@javaspecialists.eu>

FWIW, I've also submitted this as a bug report:

https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8301863


Regards

Heinz
-- 
Dr Heinz M. Kabutz (PhD CompSci)
Author of "The Java? Specialists' Newsletter" -www.javaspecialists.eu
Java Champion -www.javachampions.org
JavaOne Rock Star Speaker
Tel: +30 69 75 595 262
Skype: kabutz

On 2023/02/06 06:55, Roger Riggs wrote:
> Hi Heinz,
>
> Indeed, this example is not intuitive and does not do what was 
> intended and could use a better explanation.
>
> The interaction of three filters gets complicated and their 
> combination depends on the ordering and intention of each filter and 
> the particular filter factory goal. The FilterInThread example 
> provides only one of many possible functions.
>
> The FilterInThread example uses the JVM-wide filter, thread filter, 
> and stream filter for different purposes.
>
> The JVM-wide filter has a particular role in that it can be set on the 
> command line via a system property.
> It is typically used as a backstop after the application is deployed 
> to patch in additional rejection of classes.
> The property value syntax allows for either allowing or rejecting 
> classes, and an otherwise unmentioned class is left UNDECIDED, 
> possibly with some risk exposure.
>
> The thread filter is used to more focus de-serialization on a group of 
> classes, either to narrow it or expand it.
>
> The FilterInThread example takes the position that any UNDECIDED in 
> the thread's filter and the JVM-wide filter should be rejected even if 
> the pattern does not explicitly do so.? This keeps an oversight in 
> filter construction from becoming a risk.
>
> The stream filter is included mostly for backward compatibility, 
> introduced in JDK 9 via JEP 290. The stream filter is set by the code 
> creating the ObjectInputStream and part of its design and purpose. In 
> the FilterInThread example, if it returns UNDECIDED, the result is 
> determined by a merge of the other two filters and further rejecting 
> UNDECIDED.
>
> The bug in the example, that individually rejects UNDECIDED in the 
> JVM-wide and thread filters respectively, should instead reject only 
> if both return UNDECIDED.
>
> The revised example is:
>
> *// Returns a composite filter of the static JVM-wide filter, a 
> thread-specific filter, *// and the stream-specific filter. *public 
> ObjectInputFilter apply(ObjectInputFilter curr, ObjectInputFilter 
> next) { *if (curr == null) { *// Called from the OIS constructor or 
> perhaps OIS.setObjectInputFilter with no current filter *var filter = 
> filterThreadLocal.get(); *if (filter != null) { *// Merge to invoke 
> the thread local filter and then the JVM-wide filter (if any) *filter 
> = ObjectInputFilter.merge(filter, next); *return 
> ObjectInputFilter.rejectUndecidedClass(filter); *} *return (next == 
> null) ? null : ObjectInputFilter.rejectUndecidedClass(next); *} else { 
> *// Called from OIS.setObjectInputFilter with a current filter and a 
> stream-specific filter. *// The curr filter already incorporates the 
> thread filter and static JVM-wide filter *// and rejection of 
> undecided classes *// If there is a stream-specific filter merge to 
> invoke it and then the current filter. *if (next != null) { *return 
> ObjectInputFilter.merge(next, curr); *} *return curr; *} *}
>
> The filters are evaluated as:
> merge(restrictLargeArrays,rejectUndecidedClass(merge(allowInteger,allowArrayList)))
>
> The first call to the factory returns a filter:? `var f1 = 
> rejectUndecidedClass(merge(allowInteger,allowArrayList))`
> The second call to the factory returns filter: `var f2 = 
> merge(restrictLargeArrays, f1)`
>
> The filters are evaluated in order, until an accept or reject is returned:
> ? 1) restrictLargeArrays? (stream)
> ? 2) allowInteger??? ??? ??? (thread filter)
> ? 3) allowArrayList???? ??? (JVM-wide filter)
>
> This has the same value as your ideal but without an extra 
> RejectUndecidedClass.
>
> Note that in this composition, the choice by a filter to accept or 
> reject can not be overridden by a subsequent filter.
>
> Thank you for the comments and suggestions, Roger
>
> On 2/3/23 1:20 PM, Dr Heinz M. Kabutz wrote:
>> I was trying to get my head around the FilterInThread example in JEP 
>> 415 (https://openjdk.org/jeps/415) and the JavaDoc for the 
>> ObjectInputFilter 
>> (https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/io/ObjectInputFilter.html)
>>
>> For example, let's assume we have three filters. The first allow 
>> ArrayList, the second allows Integer, the third restricts arrays to 
>> not be larger than 1000.
>>
>> ??? ObjectInputFilter allowArrayList = ObjectInputFilter.allowFilter(
>> ??????????? Set.of(ArrayList.class, Object.class)::contains, UNDECIDED
>> ??? );
>> ??? ObjectInputFilter allowInteger = ObjectInputFilter.allowFilter(
>> ??????????? Set.of(Number.class, Integer.class)::contains, UNDECIDED
>> ??? );
>> ??? ObjectInputFilter restrictLargeArrays =
>> ObjectInputFilter.Config.createFilter("maxarray=1000");
>>
>> Let's say that we create a FilterInThread instance and install that 
>> as our factory. Furthermore, we set the allowArrayList as the global 
>> serial filter. When we call filterInThread.doWithSerialFilter() we 
>> pass in the allowInteger filter. Lastly, during the actual 
>> deserialization, we call setObjectInputFilter() on the 
>> ObjectInputStream with the restrictLargeArrays filter. Ideally, I 
>> would want the final filter to look like this:
>>
>> rejectUndecidedClass(merge(restrictLargeArrays,merge(allowInteger,allowArrayList))) 
>>
>>
>> However, in the FilterInThread example, we add the 
>> rejectUndecidedClass() wrapper around each of the steps. Thus we 
>> would get something like:
>>
>> rejectUndecidedClass(merge(restrictLargeArrays,rejectUndecidedClass(merge(allowInteger,rejectUndecidedClass(allowArrayList))))) 
>>
>>
>> Thus we could never allow any classes except for ArrayList.
>>
>>
>> Regards
>>
>> Heinz
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20230206/64852efa/attachment-0001.htm>

From asotona at openjdk.org  Mon Feb  6 13:29:10 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 6 Feb 2023 13:29:10 GMT
Subject: RFR: 8294982: Implementation of Classfile API [v13]
In-Reply-To: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
References: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
Message-ID: <Ej4u9wRtUuLS5LJhMkXwmown_MGuwR0gH9ruJ1A1g30=.f6405576-6655-4252-9135-ebc77765436e@github.com>

> This is root pull request with Classfile API implementation, tests and benchmarks initial drop into JDK.
> 
> Following pull requests consolidating JDK class files parsing, generating, and transforming ([JDK-8294957](https://bugs.openjdk.org/browse/JDK-8294957)) will chain to this one.
> 
> Classfile API development is tracked at:
> https://github.com/openjdk/jdk-sandbox/tree/classfile-api-branch
> 
> Development branch of consolidated JDK class files parsing, generating, and transforming is at:
> https://github.com/openjdk/jdk-sandbox/tree/classfile-api-dev-branch
> 
> Classfile API [JEP](https://bugs.openjdk.org/browse/JDK-8280389) and [online API documentation](https://htmlpreview.github.io/?https://raw.githubusercontent.com/openjdk/jdk-sandbox/classfile-api-javadoc-branch/doc/classfile-api/javadoc/java.base/jdk/classfile/package-summary.html) is also available.
> 
> Please take you time to review this non-trivial JDK addition.
> 
> Thank you,
> Adam

Adam Sotona has updated the pull request incrementally with three additional commits since the last revision:

 - javadoc fixes
 - obsolete identifiers and unused imports cleanup
 - TypeAnnotation.TypePathComponent cleanup

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10982/files
  - new: https://git.openjdk.org/jdk/pull/10982/files/8df1dc21..1aabe0e3

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10982&range=12
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10982&range=11-12

  Stats: 32 lines in 9 files changed: 8 ins; 5 del; 19 mod
  Patch: https://git.openjdk.org/jdk/pull/10982.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10982/head:pull/10982

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

From asotona at openjdk.org  Mon Feb  6 13:29:14 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 6 Feb 2023 13:29:14 GMT
Subject: RFR: 8294982: Implementation of Classfile API [v12]
In-Reply-To: <c022hrWNEHW76nhP_sXTQXCTjtL8jjM8r_yYv0IvbPI=.2a9cfbae-2fef-4cdb-8189-b869b1513fef@github.com>
References: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
 <Q4VeZ2yWAg85FqUDJa5hYq3jHty5H547gD0H-x3oIq0=.58d463a4-237a-4fee-bd0f-83262d49522a@github.com>
 <c022hrWNEHW76nhP_sXTQXCTjtL8jjM8r_yYv0IvbPI=.2a9cfbae-2fef-4cdb-8189-b869b1513fef@github.com>
Message-ID: <o5D1SoQKDn5rezslHFUV7H-P63htmA2s0XXUe3xDjUE=.5cab2bd2-926c-4222-8885-df9e913c6c95@github.com>

On Fri, 3 Feb 2023 17:37:55 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Classfile API moved under jdk.internal.classfile package
>
> src/java.base/share/classes/jdk/internal/classfile/package-info.java line 39:
> 
>> 37:  * <p>
>> 38:  * {@snippet lang=java :
>> 39:  * ClassModel cm = ClassModel.of(bytes);
> 
> There are several references to `ClassModel::of` (here and elsewhere), but this seems to have been moved to `ClassFile::parse`

will fix, thanks

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

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

From asotona at openjdk.org  Mon Feb  6 13:45:56 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 6 Feb 2023 13:45:56 GMT
Subject: RFR: 8294982: Implementation of Classfile API [v12]
In-Reply-To: <c022hrWNEHW76nhP_sXTQXCTjtL8jjM8r_yYv0IvbPI=.2a9cfbae-2fef-4cdb-8189-b869b1513fef@github.com>
References: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
 <Q4VeZ2yWAg85FqUDJa5hYq3jHty5H547gD0H-x3oIq0=.58d463a4-237a-4fee-bd0f-83262d49522a@github.com>
 <c022hrWNEHW76nhP_sXTQXCTjtL8jjM8r_yYv0IvbPI=.2a9cfbae-2fef-4cdb-8189-b869b1513fef@github.com>
Message-ID: <WtoD_37G0yKzxNTqSuaGNGsfEt35H7lXw16z_lg9S8k=.a623b8ee-2db5-4157-8db5-4f80fe92f05b@github.com>

On Fri, 3 Feb 2023 17:43:22 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Classfile API moved under jdk.internal.classfile package
>
> src/java.base/share/classes/jdk/internal/classfile/Classfile.java line 58:
> 
>> 56:  * Main entry points for parsing, transforming, and generating classfiles.
>> 57:  */
>> 58: public class Classfile {
> 
> class or interface? (bikeshed, I realize)

yes, a bikeshed

> src/java.base/share/classes/jdk/internal/classfile/Classfile.java line 197:
> 
>> 195:      * @return the classfile bytes
>> 196:      */
>> 197:     public static byte[] build(ClassDesc thisClass,
> 
> The "build" methods here seem regular - e.g. build { class, module } x { byte array, path }. As a future improvement, perhaps capturing the "sink" of a build process might be helpful - so that you can avoid overloads between array and path variants. (e.g. `build(.... toByteArray(arr))`, or `build(...).toByteArray(...)`.

Classfile::build always return byte array and there is no "sink" model inside.
Classfile::buildTo is frequently used extension; a wrapper calling build and writing the byte array using Files::write.

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

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

From asotona at openjdk.org  Mon Feb  6 13:52:54 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 6 Feb 2023 13:52:54 GMT
Subject: RFR: 8294982: Implementation of Classfile API [v12]
In-Reply-To: <2dfIIfnZwgc-wezRVH81l9b5VjLjP02k7PjU64wjAww=.5c9e7ba6-4254-46cd-a6c0-553dcea7dc3b@github.com>
References: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
 <Q4VeZ2yWAg85FqUDJa5hYq3jHty5H547gD0H-x3oIq0=.58d463a4-237a-4fee-bd0f-83262d49522a@github.com>
 <c022hrWNEHW76nhP_sXTQXCTjtL8jjM8r_yYv0IvbPI=.2a9cfbae-2fef-4cdb-8189-b869b1513fef@github.com>
 <2dfIIfnZwgc-wezRVH81l9b5VjLjP02k7PjU64wjAww=.5c9e7ba6-4254-46cd-a6c0-553dcea7dc3b@github.com>
Message-ID: <F9Z-fMHgQtKGeEZu3jv2V7dTEmGVnfY28dFLu5sIS7Q=.3a6db219-3ae0-4352-a146-0ac45820b1a1@github.com>

On Fri, 3 Feb 2023 18:07:27 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/classfile/Classfile.java line 346:
>> 
>>> 344:     public static final int MAGIC_NUMBER = 0xCAFEBABE;
>>> 345: 
>>> 346:     public static final int NOP             = 0;
>> 
>> Not sure how I feel about the constants being here. It seems to me that they can be moved to more appropriate places - e.g. Instructor, TypeAnnotation (for the TAT ones), ConstantPool (for the TAG ones).
>> 
>> The classfile versions, OTOH, do seem to belong here.
>
> Actually, we also have a ClassfileVersion class, so that could be a better place for version numbers?

There were several iterations of "where to store numeric constants".
It is hard to find them when spread across many classes and duplicities appear instantly.
Dedicated "Constants" would be another bikeshed with conflicting name.
Co-location in Classfile was the latest decission as it is not just a central bikeshed, but it also reflect connection with classfile specification.
Please raise that discussion at classfile-api-dev at openjdk.org if necessary.

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

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

From asotona at openjdk.org  Mon Feb  6 13:58:58 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 6 Feb 2023 13:58:58 GMT
Subject: RFR: 8294982: Implementation of Classfile API [v12]
In-Reply-To: <c022hrWNEHW76nhP_sXTQXCTjtL8jjM8r_yYv0IvbPI=.2a9cfbae-2fef-4cdb-8189-b869b1513fef@github.com>
References: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
 <Q4VeZ2yWAg85FqUDJa5hYq3jHty5H547gD0H-x3oIq0=.58d463a4-237a-4fee-bd0f-83262d49522a@github.com>
 <c022hrWNEHW76nhP_sXTQXCTjtL8jjM8r_yYv0IvbPI=.2a9cfbae-2fef-4cdb-8189-b869b1513fef@github.com>
Message-ID: <rzZgV5Ffapr1PM-e0qssZQwGCRGpcP9jv3Ua4aUY-TQ=.2540b2e9-cc38-4dfc-9f24-a31bb1b242e9@github.com>

On Fri, 3 Feb 2023 17:52:49 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Classfile API moved under jdk.internal.classfile package
>
> src/java.base/share/classes/jdk/internal/classfile/AttributedElement.java line 94:
> 
>> 92:      * are permitted.
>> 93:      */
>> 94:     enum Kind {
> 
> Not sure how to interpret this. This seems to refer to an attribute - e.g. where is an attribute allowed - rather than to the element (e.g. the declaration to which the attribute is attached). All the constants are unused, so hard to make sense of how this is used.

There are at least 72 usages of AttributedElement.Kind across the Classfile API.
Do you suggest to rename it to something else (for example Location)?

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

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

From asotona at openjdk.org  Mon Feb  6 14:04:58 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 6 Feb 2023 14:04:58 GMT
Subject: RFR: 8294982: Implementation of Classfile API [v12]
In-Reply-To: <c022hrWNEHW76nhP_sXTQXCTjtL8jjM8r_yYv0IvbPI=.2a9cfbae-2fef-4cdb-8189-b869b1513fef@github.com>
References: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
 <Q4VeZ2yWAg85FqUDJa5hYq3jHty5H547gD0H-x3oIq0=.58d463a4-237a-4fee-bd0f-83262d49522a@github.com>
 <c022hrWNEHW76nhP_sXTQXCTjtL8jjM8r_yYv0IvbPI=.2a9cfbae-2fef-4cdb-8189-b869b1513fef@github.com>
Message-ID: <Bgo7s5q6imUmwyWqUY4rLqXfpzEYz7xTrPp_VBdOhsQ=.850f98ce-8689-4ae2-b032-50d2916fcc25@github.com>

On Fri, 3 Feb 2023 17:56:45 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Classfile API moved under jdk.internal.classfile package
>
> src/java.base/share/classes/jdk/internal/classfile/Attributes.java line 774:
> 
>> 772:      */
>> 773:     public static AttributeMapper<?> standardAttribute(Utf8Entry name) {
>> 774:         int hash = name.hashCode();
> 
> If we have a map, why do we need this "inlined" map here? Performance reasons?

Yes, performance is the main reason.
I'll note to do a fresh differential performance benchmarks with a HashMap.

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

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

From asotona at openjdk.org  Mon Feb  6 14:11:57 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 6 Feb 2023 14:11:57 GMT
Subject: RFR: 8294982: Implementation of Classfile API [v12]
In-Reply-To: <c022hrWNEHW76nhP_sXTQXCTjtL8jjM8r_yYv0IvbPI=.2a9cfbae-2fef-4cdb-8189-b869b1513fef@github.com>
References: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
 <Q4VeZ2yWAg85FqUDJa5hYq3jHty5H547gD0H-x3oIq0=.58d463a4-237a-4fee-bd0f-83262d49522a@github.com>
 <c022hrWNEHW76nhP_sXTQXCTjtL8jjM8r_yYv0IvbPI=.2a9cfbae-2fef-4cdb-8189-b869b1513fef@github.com>
Message-ID: <iJyGP0x-bzXtRchGky3D7nJr-J2k4XPtl64FjcXJtCQ=.a9d4c1cd-08a7-4b8b-b43e-57a264d7265c@github.com>

On Fri, 3 Feb 2023 17:58: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:
>> 
>>   Classfile API moved under jdk.internal.classfile package
>
> src/java.base/share/classes/jdk/internal/classfile/BootstrapMethodEntry.java line 41:
> 
>> 39:  * part of the constant pool.
>> 40:  */
>> 41: public sealed interface BootstrapMethodEntry
> 
> Usages of this seem all to fall into the `constantpool` package - does this interface belong there?

`BootstrapMethodEntry` is not a constant pool entry, but `BootstrapMethodsAttribute` entry.
It might be rather moved under `attribute` package and renamed to `BootstrapMethodInfo` to follow the same pattern as other attributes/infos.

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

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

From asotona at openjdk.org  Mon Feb  6 14:16:59 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 6 Feb 2023 14:16:59 GMT
Subject: RFR: 8294982: Implementation of Classfile API [v12]
In-Reply-To: <c022hrWNEHW76nhP_sXTQXCTjtL8jjM8r_yYv0IvbPI=.2a9cfbae-2fef-4cdb-8189-b869b1513fef@github.com>
References: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
 <Q4VeZ2yWAg85FqUDJa5hYq3jHty5H547gD0H-x3oIq0=.58d463a4-237a-4fee-bd0f-83262d49522a@github.com>
 <c022hrWNEHW76nhP_sXTQXCTjtL8jjM8r_yYv0IvbPI=.2a9cfbae-2fef-4cdb-8189-b869b1513fef@github.com>
Message-ID: <8tqh8yQ47KA2UrWlPItUcFMQ97uvNXCiCJUj-PDksJo=.c9e71d26-15ef-4915-8317-651337a23af9@github.com>

On Fri, 3 Feb 2023 17:59:53 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Classfile API moved under jdk.internal.classfile package
>
> src/java.base/share/classes/jdk/internal/classfile/BufWriter.java line 40:
> 
>> 38:  * to the end of the buffer, as well as to create constant pool entries.
>> 39:  */
>> 40: public sealed interface BufWriter
> 
> What is the relationship between this and ClassReader? Is one the dual of the other - e.g. is the intended use for BufWriter to write custom attributes, whereas ClassReader reads custom attributes?

Yes, it is an exposure of low-level API to support custom attributes.

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

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

From asotona at openjdk.org  Mon Feb  6 14:29:04 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 6 Feb 2023 14:29:04 GMT
Subject: RFR: 8294982: Implementation of Classfile API [v12]
In-Reply-To: <c022hrWNEHW76nhP_sXTQXCTjtL8jjM8r_yYv0IvbPI=.2a9cfbae-2fef-4cdb-8189-b869b1513fef@github.com>
References: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
 <Q4VeZ2yWAg85FqUDJa5hYq3jHty5H547gD0H-x3oIq0=.58d463a4-237a-4fee-bd0f-83262d49522a@github.com>
 <c022hrWNEHW76nhP_sXTQXCTjtL8jjM8r_yYv0IvbPI=.2a9cfbae-2fef-4cdb-8189-b869b1513fef@github.com>
Message-ID: <V9_FdxdSeOeFwSCRWE9yMBtOPXh57tf7eJuLl_qw0H0=.0a954224-a444-4cde-bc47-8a37f275721b@github.com>

On Fri, 3 Feb 2023 18:11:41 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Classfile API moved under jdk.internal.classfile package
>
> src/java.base/share/classes/jdk/internal/classfile/ClassModel.java line 104:
> 
>> 102:      * found
>> 103:      */
>> 104:     default List<VerifyError> verify(Consumer<String> debugOutput) {
> 
> not super sure whether `verify` belongs here - could be another component in the `components` package?

Classfile API by default does not verify produced or transformed bytecode, so this is more a question if we want to have verification an integral part of the API or a standalone tool.

> src/java.base/share/classes/jdk/internal/classfile/CodeBuilder.java line 613:
> 
>> 611:     }
>> 612: 
>> 613:     default CodeBuilder labelBinding(Label label) {
> 
> Maybe just `bind` or `bindLabel` ?

It has been discussed (and changed) many times. Please raise this discussion at classfile-api-dev at openjdk.org

> src/java.base/share/classes/jdk/internal/classfile/CodeBuilder.java line 1371:
> 
>> 1369:     }
>> 1370: 
>> 1371:     default CodeBuilder tableswitch(Label defaultTarget, List<SwitchCase> cases) {
> 
> `switch` seems the one instruction for which an high-level variant (like `trying`) could be useful, as generating code for that can be quite painful.

Nice RFE, thanks.

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

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

From asotona at openjdk.org  Mon Feb  6 14:35:57 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 6 Feb 2023 14:35:57 GMT
Subject: RFR: 8294982: Implementation of Classfile API [v12]
In-Reply-To: <c022hrWNEHW76nhP_sXTQXCTjtL8jjM8r_yYv0IvbPI=.2a9cfbae-2fef-4cdb-8189-b869b1513fef@github.com>
References: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
 <Q4VeZ2yWAg85FqUDJa5hYq3jHty5H547gD0H-x3oIq0=.58d463a4-237a-4fee-bd0f-83262d49522a@github.com>
 <c022hrWNEHW76nhP_sXTQXCTjtL8jjM8r_yYv0IvbPI=.2a9cfbae-2fef-4cdb-8189-b869b1513fef@github.com>
Message-ID: <FbFekphAbS5DQzn6B-uUHkX-2EF8Aq4NcijjMdlxAM0=.280a7529-4008-4539-9137-da7600e13eee@github.com>

On Fri, 3 Feb 2023 18:37:43 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Classfile API moved under jdk.internal.classfile package
>
> src/java.base/share/classes/jdk/internal/classfile/ClassSignature.java line 34:
> 
>> 32:  * Models the generic signature of a class file, as defined by JVMS 4.7.9.
>> 33:  */
>> 34: public sealed interface ClassSignature
> 
> It is a bit odd to have Signature and XYZSignature in the API with the latter not extending the former. I think I get what the API is aiming for though - e.g. Signature is for modelling low-level "portions" of the signature attributes, whereas ClassSignature, MethodSignature and friends are there to model the signature attribute attached to a class, method, etc.

The confusion come from simplified name. Signature probably should be called JavaTypeSignature according to the spec. ClassSignature and MethodSignature could not extend it, as it would not respect the reality. Each of them are completely different species. Signature (or JavaTypeSignature) on the other side has many sub-types.

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

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

From roger.riggs at oracle.com  Mon Feb  6 14:48:34 2023
From: roger.riggs at oracle.com (Roger Riggs)
Date: Mon, 6 Feb 2023 09:48:34 -0500
Subject: JEP415: FilterInThread Example
In-Reply-To: <2e76369a-2569-c406-9e3f-85a3854c68ce@javaspecialists.eu>
References: <76209504-e958-b981-8b6b-b90955fd5f5d@javaspecialists.eu>
 <1555d359-0a01-764d-c014-f2b5b678cabb@oracle.com>
 <2e76369a-2569-c406-9e3f-85a3854c68ce@javaspecialists.eu>
Message-ID: <600bc68e-a3c0-5119-c919-411d31c18e18@oracle.com>

Thanks, I'd planned to file a bug too.

If you think of any improvements, let me know.

On 2/6/23 8:26 AM, Dr Heinz M. Kabutz wrote:
>
> FWIW, I've also submitted this as a bug report:
>
> https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8301863
>
>
> Regards
>
> Heinz
> -- 
> Dr Heinz M. Kabutz (PhD CompSci)
> Author of "The Java? Specialists' Newsletter" -www.javaspecialists.eu
> Java Champion -www.javachampions.org
> JavaOne Rock Star Speaker
> Tel: +30 69 75 595 262
> Skype: kabutz
> On 2023/02/06 06:55, Roger Riggs wrote:
>> Hi Heinz,
>>
>> Indeed, this example is not intuitive and does not do what was 
>> intended and could use a better explanation.
>>
>> The interaction of three filters gets complicated and their 
>> combination depends on the ordering and intention of each filter and 
>> the particular filter factory goal. The FilterInThread example 
>> provides only one of many possible functions.
>>
>> The FilterInThread example uses the JVM-wide filter, thread filter, 
>> and stream filter for different purposes.
>>
>> The JVM-wide filter has a particular role in that it can be set on 
>> the command line via a system property.
>> It is typically used as a backstop after the application is deployed 
>> to patch in additional rejection of classes.
>> The property value syntax allows for either allowing or rejecting 
>> classes, and an otherwise unmentioned class is left UNDECIDED, 
>> possibly with some risk exposure.
>>
>> The thread filter is used to more focus de-serialization on a group 
>> of classes, either to narrow it or expand it.
>>
>> The FilterInThread example takes the position that any UNDECIDED in 
>> the thread's filter and the JVM-wide filter should be rejected even 
>> if the pattern does not explicitly do so.? This keeps an oversight in 
>> filter construction from becoming a risk.
>>
>> The stream filter is included mostly for backward compatibility, 
>> introduced in JDK 9 via JEP 290. The stream filter is set by the code 
>> creating the ObjectInputStream and part of its design and purpose. In 
>> the FilterInThread example, if it returns UNDECIDED, the result is 
>> determined by a merge of the other two filters and further rejecting 
>> UNDECIDED.
>>
>> The bug in the example, that individually rejects UNDECIDED in the 
>> JVM-wide and thread filters respectively, should instead reject only 
>> if both return UNDECIDED.
>>
>> The revised example is:
>>
>> *// Returns a composite filter of the static JVM-wide filter, a 
>> thread-specific filter, *// and the stream-specific filter. *public 
>> ObjectInputFilter apply(ObjectInputFilter curr, ObjectInputFilter 
>> next) { *if (curr == null) { *// Called from the OIS constructor or 
>> perhaps OIS.setObjectInputFilter with no current filter *var filter = 
>> filterThreadLocal.get(); *if (filter != null) { *// Merge to invoke 
>> the thread local filter and then the JVM-wide filter (if any) *filter 
>> = ObjectInputFilter.merge(filter, next); *return 
>> ObjectInputFilter.rejectUndecidedClass(filter); *} *return (next == 
>> null) ? null : ObjectInputFilter.rejectUndecidedClass(next); *} else 
>> { *// Called from OIS.setObjectInputFilter with a current filter and 
>> a stream-specific filter. *// The curr filter already incorporates 
>> the thread filter and static JVM-wide filter *// and rejection of 
>> undecided classes *// If there is a stream-specific filter merge to 
>> invoke it and then the current filter. *if (next != null) { *return 
>> ObjectInputFilter.merge(next, curr); *} *return curr; *} *}
>>
>> The filters are evaluated as:
>> merge(restrictLargeArrays,rejectUndecidedClass(merge(allowInteger,allowArrayList)))
>>
>> The first call to the factory returns a filter:? `var f1 = 
>> rejectUndecidedClass(merge(allowInteger,allowArrayList))`
>> The second call to the factory returns filter: `var f2 = 
>> merge(restrictLargeArrays, f1)`
>>
>> The filters are evaluated in order, until an accept or reject is 
>> returned:
>> ? 1) restrictLargeArrays? (stream)
>> ? 2) allowInteger??? ??? ??? (thread filter)
>> ? 3) allowArrayList???? ??? (JVM-wide filter)
>>
>> This has the same value as your ideal but without an extra 
>> RejectUndecidedClass.
>>
>> Note that in this composition, the choice by a filter to accept or 
>> reject can not be overridden by a subsequent filter.
>>
>> Thank you for the comments and suggestions, Roger
>>
>> On 2/3/23 1:20 PM, Dr Heinz M. Kabutz wrote:
>>> I was trying to get my head around the FilterInThread example in JEP 
>>> 415 (https://openjdk.org/jeps/415) and the JavaDoc for the 
>>> ObjectInputFilter 
>>> (https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/io/ObjectInputFilter.html)
>>>
>>> For example, let's assume we have three filters. The first allow 
>>> ArrayList, the second allows Integer, the third restricts arrays to 
>>> not be larger than 1000.
>>>
>>> ??? ObjectInputFilter allowArrayList = ObjectInputFilter.allowFilter(
>>> ??????????? Set.of(ArrayList.class, Object.class)::contains, UNDECIDED
>>> ??? );
>>> ??? ObjectInputFilter allowInteger = ObjectInputFilter.allowFilter(
>>> ??????????? Set.of(Number.class, Integer.class)::contains, UNDECIDED
>>> ??? );
>>> ??? ObjectInputFilter restrictLargeArrays =
>>> ObjectInputFilter.Config.createFilter("maxarray=1000");
>>>
>>> Let's say that we create a FilterInThread instance and install that 
>>> as our factory. Furthermore, we set the allowArrayList as the global 
>>> serial filter. When we call filterInThread.doWithSerialFilter() we 
>>> pass in the allowInteger filter. Lastly, during the actual 
>>> deserialization, we call setObjectInputFilter() on the 
>>> ObjectInputStream with the restrictLargeArrays filter. Ideally, I 
>>> would want the final filter to look like this:
>>>
>>> rejectUndecidedClass(merge(restrictLargeArrays,merge(allowInteger,allowArrayList))) 
>>>
>>>
>>> However, in the FilterInThread example, we add the 
>>> rejectUndecidedClass() wrapper around each of the steps. Thus we 
>>> would get something like:
>>>
>>> rejectUndecidedClass(merge(restrictLargeArrays,rejectUndecidedClass(merge(allowInteger,rejectUndecidedClass(allowArrayList))))) 
>>>
>>>
>>> Thus we could never allow any classes except for ArrayList.
>>>
>>>
>>> Regards
>>>
>>> Heinz
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20230206/c6b2e3a4/attachment-0001.htm>

From duke at openjdk.org  Mon Feb  6 15:03:33 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Mon, 6 Feb 2023 15:03:33 GMT
Subject: RFR: 8301873: Avoid string decoding in ZipFile.Source.getEntryPos
Message-ID: <FkmdspiHVjkAKFqm5kUgwaf55YH5cBbczS_3krqsdFs=.05eca901-f55f-47d9-b1bc-0cf2f5b87536@github.com>

After finding a hash match, getEntryPos needs to compare the lookup name up to the encoded entry name in the CEN. This comparison is done by decoding the entry name into a String. The names can then be compared using the String API. This decoding step adds a significat cost to this method.

This PR suggest to update the string comparison such that in the common case where  both the lookup name and the entry name are encoded in ASCII-compatible UTF-8,  decoding can be avoided and the byte arrays can instead be compared direcly. 

ZipCoder is updated with a new method to compare a string with an encoded byte array range.  The default implementation decodes to string (like the current code), while the UTF-8 implementation uses JavaLangAccess.getBytesNoRepl to get the  bytes. Both methods thes uses Arrays.mismatch for comparison with or without matching trailing slashes. 

Additionally, this PR suggest to make the following updates to getEntryPos:

- The try/catch for IAE is redundant and can be safely removed. (initCEN already checks this and will throws IAE for invalid UTF-8). This seems to give a 3-4% speedup on micros)
- A new test InvalidBytesInEntryNameOrComment is a added to verify that initCEN does in fact reject invalid UTF-8 in CEN file names and comments. (I found no existing test coverage for this)
- The recursion when looking for "name/" matches is replaced with iteration. We keep track of any "name/" match and return it at the end of the search. (I feel this is easier to follow and it also gives a ~30% speedup for addSlash lookups with no regression on regular lookups)

(My though is that including these additional updates in this PR might reduce reviewer overhead given that it touches the exact same code. I might be wrong on this, please advise :)

I'm seeing a ~17% saving on the micro ZipFileGetEntry.getEntryHit (modified to use xalan.jar):

Baseline:

Benchmark                             (size)  Mode  Cnt    Score   Error  Units
ZipFileGetEntry.getEntryHit              512  avgt   15   74.941 ? 1.004  ns/op
ZipFileGetEntry.getEntryHit             1024  avgt   15   84.943 ? 1.320  ns/op
ZipFileGetEntry.getEntryHitUncached      512  avgt   15  120.371 ? 2.386  ns/op
ZipFileGetEntry.getEntryHitUncached     1024  avgt   15  126.128 ? 1.075  ns/op
ZipFileGetEntry.getEntryMiss             512  avgt   15   23.818 ? 0.838  ns/op
ZipFileGetEntry.getEntryMiss            1024  avgt   15   29.762 ? 5.998  ns/op
ZipFileGetEntry.getEntryMissUncached     512  avgt   15   59.405 ? 0.545  ns/op
ZipFileGetEntry.getEntryMissUncached    1024  avgt   15   71.840 ? 2.455  ns/op
ZipFileGetEntry.getEntrySlash            512  avgt   15  135.621 ? 4.341  ns/op
ZipFileGetEntry.getEntrySlash           1024  avgt   15  134.190 ? 2.141  ns/op



PR:


Benchmark                             (size)  Mode  Cnt    Score   Error  Units
ZipFileGetEntry.getEntryHit              512  avgt   15   62.267 ? 1.329  ns/op
ZipFileGetEntry.getEntryHit             1024  avgt   15   72.916 ? 2.428  ns/op
ZipFileGetEntry.getEntryHitUncached      512  avgt   15  101.630 ? 1.154  ns/op
ZipFileGetEntry.getEntryHitUncached     1024  avgt   15  113.161 ? 0.502  ns/op
ZipFileGetEntry.getEntryMiss             512  avgt   15   23.003 ? 1.191  ns/op
ZipFileGetEntry.getEntryMiss            1024  avgt   15   23.236 ? 1.114  ns/op
ZipFileGetEntry.getEntryMissUncached     512  avgt   15   56.781 ? 1.505  ns/op
ZipFileGetEntry.getEntryMissUncached    1024  avgt   15   67.767 ? 1.963  ns/op
ZipFileGetEntry.getEntrySlash            512  avgt   15   73.745 ? 2.717  ns/op
ZipFileGetEntry.getEntrySlash           1024  avgt   15   75.784 ? 1.051  ns/op


To assess the impact on startup/warmup, I made a main method class which measures the total time of calling ZipFile.getEntry for all entries in the 109 JAR file dependenies of spring-petclinic. The shows a nice improvement (time in micros):


Percentile Baseline Patch
50?%          23155 21149
75?%          23598 21454
90?%          23989 21691
95?%          24238 21973
99?%          25270 22446
STDEV           792   549
Count           500   500

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

Commit messages:
 - Replace new shared secret with using getBytesNoRepl in UTF8ZipCoder.compare. Add a test case for UTF-8 encoded entry name which is latin1, but not ASCII
 - Rename test to InvalidBytesInEntryNameOrComment
 - Adjust whitespace
 - Some minor improvements to code comments
 - Micros seem to indicate that the range checks in Arrays.mismatch might have as much as 5% regression
 - Move String/byte[] comparison into ZipCoder. Change the default implementation to decode to string for comparison instead of encoding to bytes, this seems safer. Revert some changes from previous commits to parameters in the hasTrailingSlash method.
 - ByteBuffers for reading ZIP files must be little-endian
 - Produce template ZIP as a byte[] instead of writing it to disk
 - Improve summary for the test
 - Simplify comment for "name/" match
 - ... and 7 more: https://git.openjdk.org/jdk/compare/dff41316...3ca98e21

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

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

From duke at openjdk.org  Mon Feb  6 15:03:35 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Mon, 6 Feb 2023 15:03:35 GMT
Subject: RFR: 8301873: Avoid string decoding in ZipFile.Source.getEntryPos
In-Reply-To: <FkmdspiHVjkAKFqm5kUgwaf55YH5cBbczS_3krqsdFs=.05eca901-f55f-47d9-b1bc-0cf2f5b87536@github.com>
References: <FkmdspiHVjkAKFqm5kUgwaf55YH5cBbczS_3krqsdFs=.05eca901-f55f-47d9-b1bc-0cf2f5b87536@github.com>
Message-ID: <8y5f1YxDu1ALUEanR55V1S4za2fgUdWcarnFVqU3AR8=.67a750cd-d1db-4f0f-8a55-f3c2938d2090@github.com>

On Mon, 30 Jan 2023 10:32:38 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

> After finding a hash match, getEntryPos needs to compare the lookup name up to the encoded entry name in the CEN. This comparison is done by decoding the entry name into a String. The names can then be compared using the String API. This decoding step adds a significat cost to this method.
> 
> This PR suggest to update the string comparison such that in the common case where  both the lookup name and the entry name are encoded in ASCII-compatible UTF-8,  decoding can be avoided and the byte arrays can instead be compared direcly. 
> 
> ZipCoder is updated with a new method to compare a string with an encoded byte array range.  The default implementation decodes to string (like the current code), while the UTF-8 implementation uses JavaLangAccess.getBytesNoRepl to get the  bytes. Both methods thes uses Arrays.mismatch for comparison with or without matching trailing slashes. 
> 
> Additionally, this PR suggest to make the following updates to getEntryPos:
> 
> - The try/catch for IAE is redundant and can be safely removed. (initCEN already checks this and will throws IAE for invalid UTF-8). This seems to give a 3-4% speedup on micros)
> - A new test InvalidBytesInEntryNameOrComment is a added to verify that initCEN does in fact reject invalid UTF-8 in CEN file names and comments. (I found no existing test coverage for this)
> - The recursion when looking for "name/" matches is replaced with iteration. We keep track of any "name/" match and return it at the end of the search. (I feel this is easier to follow and it also gives a ~30% speedup for addSlash lookups with no regression on regular lookups)
> 
> (My though is that including these additional updates in this PR might reduce reviewer overhead given that it touches the exact same code. I might be wrong on this, please advise :)
> 
> I'm seeing a ~17% saving on the micro ZipFileGetEntry.getEntryHit (modified to use xalan.jar):
> 
> Baseline:
> 
> Benchmark                             (size)  Mode  Cnt    Score   Error  Units
> ZipFileGetEntry.getEntryHit              512  avgt   15   74.941 ? 1.004  ns/op
> ZipFileGetEntry.getEntryHit             1024  avgt   15   84.943 ? 1.320  ns/op
> ZipFileGetEntry.getEntryHitUncached      512  avgt   15  120.371 ? 2.386  ns/op
> ZipFileGetEntry.getEntryHitUncached     1024  avgt   15  126.128 ? 1.075  ns/op
> ZipFileGetEntry.getEntryMiss             512  avgt   15   23.818 ? 0.838  ns/op
> ZipFileGetEntry.getEntryMiss            1024  avgt   15   29.762 ? 5.998  ns/op
> ZipFileGetEntry.getEntryMissUncached     512  avgt   15   59.405 ? 0.545  ns/op
> ZipFileGetEntry.getEntryMissUncached    1024  avgt   15   71.840 ? 2.455  ns/op
> ZipFileGetEntry.getEntrySlash            512  avgt   15  135.621 ? 4.341  ns/op
> ZipFileGetEntry.getEntrySlash           1024  avgt   15  134.190 ? 2.141  ns/op
> 
> 
> 
> PR:
> 
> 
> Benchmark                             (size)  Mode  Cnt    Score   Error  Units
> ZipFileGetEntry.getEntryHit              512  avgt   15   62.267 ? 1.329  ns/op
> ZipFileGetEntry.getEntryHit             1024  avgt   15   72.916 ? 2.428  ns/op
> ZipFileGetEntry.getEntryHitUncached      512  avgt   15  101.630 ? 1.154  ns/op
> ZipFileGetEntry.getEntryHitUncached     1024  avgt   15  113.161 ? 0.502  ns/op
> ZipFileGetEntry.getEntryMiss             512  avgt   15   23.003 ? 1.191  ns/op
> ZipFileGetEntry.getEntryMiss            1024  avgt   15   23.236 ? 1.114  ns/op
> ZipFileGetEntry.getEntryMissUncached     512  avgt   15   56.781 ? 1.505  ns/op
> ZipFileGetEntry.getEntryMissUncached    1024  avgt   15   67.767 ? 1.963  ns/op
> ZipFileGetEntry.getEntrySlash            512  avgt   15   73.745 ? 2.717  ns/op
> ZipFileGetEntry.getEntrySlash           1024  avgt   15   75.784 ? 1.051  ns/op
> 
> 
> To assess the impact on startup/warmup, I made a main method class which measures the total time of calling ZipFile.getEntry for all entries in the 109 JAR file dependenies of spring-petclinic. The shows a nice improvement (time in micros):
> 
> 
> Percentile Baseline Patch
> 50?%          23155 21149
> 75?%          23598 21454
> 90?%          23989 21691
> 95?%          24238 21973
> 99?%          25270 22446
> STDEV           792   549
> Count           500   500

As suggested by @cl4es, I've replaced the use of ArraySupport.mismatch with Arrays.mismatch. The added range checks seems to give a regression of ~3% on the getEntryHit micro.

I realized that encoding to bytes and then comparing to CEN bytes might not be safe for encodings were multiple representations is possible for the same code points. So I moved string/byte array comparison into ZipCoder, which can now decode from CEN and compare as in the current code. Micros indicate this has no performance impact.

src/java.base/share/classes/java/lang/System.java line 2678:

> 2676:                 }
> 2677:                 return Arrays.mismatch(encoded, 0, encoded.length, b, fromIndex, toIndex);
> 2678:             }

Leaving the ArraySupport.mismatch code here for now if anyone wants to investigate the ~3% regression introduced by the range checks in Arrays.mismatch

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

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

From redestad at openjdk.org  Mon Feb  6 15:03:39 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Mon, 6 Feb 2023 15:03:39 GMT
Subject: RFR: 8301873: Avoid string decoding in ZipFile.Source.getEntryPos
In-Reply-To: <FkmdspiHVjkAKFqm5kUgwaf55YH5cBbczS_3krqsdFs=.05eca901-f55f-47d9-b1bc-0cf2f5b87536@github.com>
References: <FkmdspiHVjkAKFqm5kUgwaf55YH5cBbczS_3krqsdFs=.05eca901-f55f-47d9-b1bc-0cf2f5b87536@github.com>
Message-ID: <xDqqtB7TheeLd3XFDYpM3wGLBiNupA5azSbnC2b5EKU=.a1670b43-7467-4009-9a6b-056e3c7265f8@github.com>

On Mon, 30 Jan 2023 10:32:38 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

> After finding a hash match, getEntryPos needs to compare the lookup name up to the encoded entry name in the CEN. This comparison is done by decoding the entry name into a String. The names can then be compared using the String API. This decoding step adds a significat cost to this method.
> 
> This PR suggest to update the string comparison such that in the common case where  both the lookup name and the entry name are encoded in ASCII-compatible UTF-8,  decoding can be avoided and the byte arrays can instead be compared direcly. 
> 
> ZipCoder is updated with a new method to compare a string with an encoded byte array range.  The default implementation decodes to string (like the current code), while the UTF-8 implementation uses JavaLangAccess.getBytesNoRepl to get the  bytes. Both methods thes uses Arrays.mismatch for comparison with or without matching trailing slashes. 
> 
> Additionally, this PR suggest to make the following updates to getEntryPos:
> 
> - The try/catch for IAE is redundant and can be safely removed. (initCEN already checks this and will throws IAE for invalid UTF-8). This seems to give a 3-4% speedup on micros)
> - A new test InvalidBytesInEntryNameOrComment is a added to verify that initCEN does in fact reject invalid UTF-8 in CEN file names and comments. (I found no existing test coverage for this)
> - The recursion when looking for "name/" matches is replaced with iteration. We keep track of any "name/" match and return it at the end of the search. (I feel this is easier to follow and it also gives a ~30% speedup for addSlash lookups with no regression on regular lookups)
> 
> (My though is that including these additional updates in this PR might reduce reviewer overhead given that it touches the exact same code. I might be wrong on this, please advise :)
> 
> I'm seeing a ~17% saving on the micro ZipFileGetEntry.getEntryHit (modified to use xalan.jar):
> 
> Baseline:
> 
> Benchmark                             (size)  Mode  Cnt    Score   Error  Units
> ZipFileGetEntry.getEntryHit              512  avgt   15   74.941 ? 1.004  ns/op
> ZipFileGetEntry.getEntryHit             1024  avgt   15   84.943 ? 1.320  ns/op
> ZipFileGetEntry.getEntryHitUncached      512  avgt   15  120.371 ? 2.386  ns/op
> ZipFileGetEntry.getEntryHitUncached     1024  avgt   15  126.128 ? 1.075  ns/op
> ZipFileGetEntry.getEntryMiss             512  avgt   15   23.818 ? 0.838  ns/op
> ZipFileGetEntry.getEntryMiss            1024  avgt   15   29.762 ? 5.998  ns/op
> ZipFileGetEntry.getEntryMissUncached     512  avgt   15   59.405 ? 0.545  ns/op
> ZipFileGetEntry.getEntryMissUncached    1024  avgt   15   71.840 ? 2.455  ns/op
> ZipFileGetEntry.getEntrySlash            512  avgt   15  135.621 ? 4.341  ns/op
> ZipFileGetEntry.getEntrySlash           1024  avgt   15  134.190 ? 2.141  ns/op
> 
> 
> 
> PR:
> 
> 
> Benchmark                             (size)  Mode  Cnt    Score   Error  Units
> ZipFileGetEntry.getEntryHit              512  avgt   15   62.267 ? 1.329  ns/op
> ZipFileGetEntry.getEntryHit             1024  avgt   15   72.916 ? 2.428  ns/op
> ZipFileGetEntry.getEntryHitUncached      512  avgt   15  101.630 ? 1.154  ns/op
> ZipFileGetEntry.getEntryHitUncached     1024  avgt   15  113.161 ? 0.502  ns/op
> ZipFileGetEntry.getEntryMiss             512  avgt   15   23.003 ? 1.191  ns/op
> ZipFileGetEntry.getEntryMiss            1024  avgt   15   23.236 ? 1.114  ns/op
> ZipFileGetEntry.getEntryMissUncached     512  avgt   15   56.781 ? 1.505  ns/op
> ZipFileGetEntry.getEntryMissUncached    1024  avgt   15   67.767 ? 1.963  ns/op
> ZipFileGetEntry.getEntrySlash            512  avgt   15   73.745 ? 2.717  ns/op
> ZipFileGetEntry.getEntrySlash           1024  avgt   15   75.784 ? 1.051  ns/op
> 
> 
> To assess the impact on startup/warmup, I made a main method class which measures the total time of calling ZipFile.getEntry for all entries in the 109 JAR file dependenies of spring-petclinic. The shows a nice improvement (time in micros):
> 
> 
> Percentile Baseline Patch
> 50?%          23155 21149
> 75?%          23598 21454
> 90?%          23989 21691
> 95?%          24238 21973
> 99?%          25270 22446
> STDEV           792   549
> Count           500   500

Filed JDK-8301873 for this, update PR title when you're ready.

src/java.base/share/classes/java/lang/System.java line 2668:

> 2666:             @Override
> 2667:             public int mismatchUTF8(String str, byte[] b, int fromIndex, int toIndex) {
> 2668:                 byte[] encoded = str.isLatin1() ? str.value() : str.getBytes(UTF_8.INSTANCE);

I think this is incorrect: latin-1 characters above codepoint 127 (non-ascii) would be represented by 2 bytes in UTF-8. What you want here is probably `str.isAscii() ? ...`. The ASCII check will have to look at the bytes, so will incur a minor penalty.

Good news is that you should already be able to do this with what's already exposed via `JLA.getBytesNoRepl(str, StandardCharsets.UTF_8)`, so no need for more shared secrets.

src/java.base/share/classes/java/lang/System.java line 2671:

> 2669:                 if (false) {
> 2670:                     // Arrays.mismatch without the range checks (~5% faster micro getEntryHit)
> 2671:                     int aLength = encoded.length;

Part of the difference you're seeing is due to knowing that you'll be matching the entire length of the first array (`encoded, 0, encoded.length`).

As an experiment I added `Arrays.mismatch(byte[], byte[], int, int)` to mismatch the entire range of the first array argument vs the range of the second and can spot an improvement in affected micros:

Benchmark                                     (size)  Mode  Cnt   Score   Error  Units
ArraysMismatch.Char.differentSubrangeMatches      90  avgt   10  12.165 ? 0.074  ns/op # mismatch(a, aFrom, aTo, b, bFrom, bTo)
ArraysMismatch.Char.subrangeMatches               90  avgt   10  10.748 ? 0.006  ns/op # mismatch(a, b, bFrom, bTo)

This might be something we can solve in the JITs without having to add new methods to `java.util.Arrays` to deal as efficiently as possible with the case when we're matching against the entirety of one of the arrays.

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

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

From duke at openjdk.org  Mon Feb  6 15:03:41 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Mon, 6 Feb 2023 15:03:41 GMT
Subject: RFR: 8301873: Avoid string decoding in ZipFile.Source.getEntryPos
In-Reply-To: <xDqqtB7TheeLd3XFDYpM3wGLBiNupA5azSbnC2b5EKU=.a1670b43-7467-4009-9a6b-056e3c7265f8@github.com>
References: <FkmdspiHVjkAKFqm5kUgwaf55YH5cBbczS_3krqsdFs=.05eca901-f55f-47d9-b1bc-0cf2f5b87536@github.com>
 <xDqqtB7TheeLd3XFDYpM3wGLBiNupA5azSbnC2b5EKU=.a1670b43-7467-4009-9a6b-056e3c7265f8@github.com>
Message-ID: <avbAmX-S_MAOZdvQnJleQySR2ngsDS5ELNCRAuWpzkI=.6b161234-cf8e-47d6-a5cb-d9891a483837@github.com>

On Sun, 5 Feb 2023 22:13:50 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> After finding a hash match, getEntryPos needs to compare the lookup name up to the encoded entry name in the CEN. This comparison is done by decoding the entry name into a String. The names can then be compared using the String API. This decoding step adds a significat cost to this method.
>> 
>> This PR suggest to update the string comparison such that in the common case where  both the lookup name and the entry name are encoded in ASCII-compatible UTF-8,  decoding can be avoided and the byte arrays can instead be compared direcly. 
>> 
>> ZipCoder is updated with a new method to compare a string with an encoded byte array range.  The default implementation decodes to string (like the current code), while the UTF-8 implementation uses JavaLangAccess.getBytesNoRepl to get the  bytes. Both methods thes uses Arrays.mismatch for comparison with or without matching trailing slashes. 
>> 
>> Additionally, this PR suggest to make the following updates to getEntryPos:
>> 
>> - The try/catch for IAE is redundant and can be safely removed. (initCEN already checks this and will throws IAE for invalid UTF-8). This seems to give a 3-4% speedup on micros)
>> - A new test InvalidBytesInEntryNameOrComment is a added to verify that initCEN does in fact reject invalid UTF-8 in CEN file names and comments. (I found no existing test coverage for this)
>> - The recursion when looking for "name/" matches is replaced with iteration. We keep track of any "name/" match and return it at the end of the search. (I feel this is easier to follow and it also gives a ~30% speedup for addSlash lookups with no regression on regular lookups)
>> 
>> (My though is that including these additional updates in this PR might reduce reviewer overhead given that it touches the exact same code. I might be wrong on this, please advise :)
>> 
>> I'm seeing a ~17% saving on the micro ZipFileGetEntry.getEntryHit (modified to use xalan.jar):
>> 
>> Baseline:
>> 
>> Benchmark                             (size)  Mode  Cnt    Score   Error  Units
>> ZipFileGetEntry.getEntryHit              512  avgt   15   74.941 ? 1.004  ns/op
>> ZipFileGetEntry.getEntryHit             1024  avgt   15   84.943 ? 1.320  ns/op
>> ZipFileGetEntry.getEntryHitUncached      512  avgt   15  120.371 ? 2.386  ns/op
>> ZipFileGetEntry.getEntryHitUncached     1024  avgt   15  126.128 ? 1.075  ns/op
>> ZipFileGetEntry.getEntryMiss             512  avgt   15   23.818 ? 0.838  ns/op
>> ZipFileGetEntry.getEntryMiss            1024  avgt   15   29.762 ? 5.998  ns/op
>> ZipFileGetEntry.getEntryMissUncached     512  avgt   15   59.405 ? 0.545  ns/op
>> ZipFileGetEntry.getEntryMissUncached    1024  avgt   15   71.840 ? 2.455  ns/op
>> ZipFileGetEntry.getEntrySlash            512  avgt   15  135.621 ? 4.341  ns/op
>> ZipFileGetEntry.getEntrySlash           1024  avgt   15  134.190 ? 2.141  ns/op
>> 
>> 
>> 
>> PR:
>> 
>> 
>> Benchmark                             (size)  Mode  Cnt    Score   Error  Units
>> ZipFileGetEntry.getEntryHit              512  avgt   15   62.267 ? 1.329  ns/op
>> ZipFileGetEntry.getEntryHit             1024  avgt   15   72.916 ? 2.428  ns/op
>> ZipFileGetEntry.getEntryHitUncached      512  avgt   15  101.630 ? 1.154  ns/op
>> ZipFileGetEntry.getEntryHitUncached     1024  avgt   15  113.161 ? 0.502  ns/op
>> ZipFileGetEntry.getEntryMiss             512  avgt   15   23.003 ? 1.191  ns/op
>> ZipFileGetEntry.getEntryMiss            1024  avgt   15   23.236 ? 1.114  ns/op
>> ZipFileGetEntry.getEntryMissUncached     512  avgt   15   56.781 ? 1.505  ns/op
>> ZipFileGetEntry.getEntryMissUncached    1024  avgt   15   67.767 ? 1.963  ns/op
>> ZipFileGetEntry.getEntrySlash            512  avgt   15   73.745 ? 2.717  ns/op
>> ZipFileGetEntry.getEntrySlash           1024  avgt   15   75.784 ? 1.051  ns/op
>> 
>> 
>> To assess the impact on startup/warmup, I made a main method class which measures the total time of calling ZipFile.getEntry for all entries in the 109 JAR file dependenies of spring-petclinic. The shows a nice improvement (time in micros):
>> 
>> 
>> Percentile Baseline Patch
>> 50?%          23155 21149
>> 75?%          23598 21454
>> 90?%          23989 21691
>> 95?%          24238 21973
>> 99?%          25270 22446
>> STDEV           792   549
>> Count           500   500
>
> src/java.base/share/classes/java/lang/System.java line 2668:
> 
>> 2666:             @Override
>> 2667:             public int mismatchUTF8(String str, byte[] b, int fromIndex, int toIndex) {
>> 2668:                 byte[] encoded = str.isLatin1() ? str.value() : str.getBytes(UTF_8.INSTANCE);
> 
> I think this is incorrect: latin-1 characters above codepoint 127 (non-ascii) would be represented by 2 bytes in UTF-8. What you want here is probably `str.isAscii() ? ...`. The ASCII check will have to look at the bytes, so will incur a minor penalty.
> 
> Good news is that you should already be able to do this with what's already exposed via `JLA.getBytesNoRepl(str, StandardCharsets.UTF_8)`, so no need for more shared secrets.

Nice, I have updated the PR such that the new shared secret is replaced with using getBytesNoRepl instead. If there is a performance difference, it seems to hide in the noise.

I had expected such a regression to be caught by existing tests, which seems not to be the case. I added TestZipFileEncodings.latin1NotAscii to adress this.

> src/java.base/share/classes/java/lang/System.java line 2671:
> 
>> 2669:                 if (false) {
>> 2670:                     // Arrays.mismatch without the range checks (~5% faster micro getEntryHit)
>> 2671:                     int aLength = encoded.length;
> 
> Part of the difference you're seeing is due to knowing that you'll be matching the entire length of the first array (`encoded, 0, encoded.length`).
> 
> As an experiment I added `Arrays.mismatch(byte[], byte[], int, int)` to mismatch the entire range of the first array argument vs the range of the second and can spot an improvement in affected micros:
> 
> Benchmark                                     (size)  Mode  Cnt   Score   Error  Units
> ArraysMismatch.Char.differentSubrangeMatches      90  avgt   10  12.165 ? 0.074  ns/op # mismatch(a, aFrom, aTo, b, bFrom, bTo)
> ArraysMismatch.Char.subrangeMatches               90  avgt   10  10.748 ? 0.006  ns/op # mismatch(a, b, bFrom, bTo)
> 
> This might be something we can solve in the JITs without having to add new methods to `java.util.Arrays` to deal as efficiently as possible with the case when we're matching against the entirety of one of the arrays.

Interesting. Would be nice to solve this in the JIT!

This disabled code got deleted in my last commit, but it seems like you have a good analysis so we can let it go now.

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

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

From duke at openjdk.org  Mon Feb  6 15:03:43 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Mon, 6 Feb 2023 15:03:43 GMT
Subject: RFR: 8301873: Avoid string decoding in ZipFile.Source.getEntryPos
In-Reply-To: <avbAmX-S_MAOZdvQnJleQySR2ngsDS5ELNCRAuWpzkI=.6b161234-cf8e-47d6-a5cb-d9891a483837@github.com>
References: <FkmdspiHVjkAKFqm5kUgwaf55YH5cBbczS_3krqsdFs=.05eca901-f55f-47d9-b1bc-0cf2f5b87536@github.com>
 <xDqqtB7TheeLd3XFDYpM3wGLBiNupA5azSbnC2b5EKU=.a1670b43-7467-4009-9a6b-056e3c7265f8@github.com>
 <avbAmX-S_MAOZdvQnJleQySR2ngsDS5ELNCRAuWpzkI=.6b161234-cf8e-47d6-a5cb-d9891a483837@github.com>
Message-ID: <8VuNna-hLp1SzcAKlCIepnlXabh_U4tYZIDRGEpKu5g=.df5d974f-e7c9-4c3d-be66-63117a43c597@github.com>

On Mon, 6 Feb 2023 11:47:42 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/System.java line 2668:
>> 
>>> 2666:             @Override
>>> 2667:             public int mismatchUTF8(String str, byte[] b, int fromIndex, int toIndex) {
>>> 2668:                 byte[] encoded = str.isLatin1() ? str.value() : str.getBytes(UTF_8.INSTANCE);
>> 
>> I think this is incorrect: latin-1 characters above codepoint 127 (non-ascii) would be represented by 2 bytes in UTF-8. What you want here is probably `str.isAscii() ? ...`. The ASCII check will have to look at the bytes, so will incur a minor penalty.
>> 
>> Good news is that you should already be able to do this with what's already exposed via `JLA.getBytesNoRepl(str, StandardCharsets.UTF_8)`, so no need for more shared secrets.
>
> Nice, I have updated the PR such that the new shared secret is replaced with using getBytesNoRepl instead. If there is a performance difference, it seems to hide in the noise.
> 
> I had expected such a regression to be caught by existing tests, which seems not to be the case. I added TestZipFileEncodings.latin1NotAscii to adress this.

getBytesNoRepl throws CharacterCodingException "for malformed input or unmappable characters".

This should never happen since initCEN should already reject it. If it should happen anyway, I return NO_MATCH which will ignore the match just like the catch in getEntryPos currently does.

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

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

From redestad at openjdk.org  Mon Feb  6 15:03:44 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Mon, 6 Feb 2023 15:03:44 GMT
Subject: RFR: 8301873: Avoid string decoding in ZipFile.Source.getEntryPos
In-Reply-To: <8VuNna-hLp1SzcAKlCIepnlXabh_U4tYZIDRGEpKu5g=.df5d974f-e7c9-4c3d-be66-63117a43c597@github.com>
References: <FkmdspiHVjkAKFqm5kUgwaf55YH5cBbczS_3krqsdFs=.05eca901-f55f-47d9-b1bc-0cf2f5b87536@github.com>
 <xDqqtB7TheeLd3XFDYpM3wGLBiNupA5azSbnC2b5EKU=.a1670b43-7467-4009-9a6b-056e3c7265f8@github.com>
 <avbAmX-S_MAOZdvQnJleQySR2ngsDS5ELNCRAuWpzkI=.6b161234-cf8e-47d6-a5cb-d9891a483837@github.com>
 <8VuNna-hLp1SzcAKlCIepnlXabh_U4tYZIDRGEpKu5g=.df5d974f-e7c9-4c3d-be66-63117a43c597@github.com>
Message-ID: <Cdn107SRWSWB4K34Mmk2CZK_gK4Aw09q-EWyVRPBVVA=.56db4621-15fd-4acf-9ca3-cf3dc1ad4485@github.com>

On Mon, 6 Feb 2023 12:01:19 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

>> Nice, I have updated the PR such that the new shared secret is replaced with using getBytesNoRepl instead. If there is a performance difference, it seems to hide in the noise.
>> 
>> I had expected such a regression to be caught by existing tests, which seems not to be the case. I added TestZipFileEncodings.latin1NotAscii to adress this.
>
> getBytesNoRepl throws CharacterCodingException "for malformed input or unmappable characters".
> 
> This should never happen since initCEN should already reject it. If it should happen anyway, I return NO_MATCH which will ignore the match just like the catch in getEntryPos currently does.

Yes, this should be fine.

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

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

From redestad at openjdk.org  Mon Feb  6 15:03:46 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Mon, 6 Feb 2023 15:03:46 GMT
Subject: RFR: 8301873: Avoid string decoding in ZipFile.Source.getEntryPos
In-Reply-To: <avbAmX-S_MAOZdvQnJleQySR2ngsDS5ELNCRAuWpzkI=.6b161234-cf8e-47d6-a5cb-d9891a483837@github.com>
References: <FkmdspiHVjkAKFqm5kUgwaf55YH5cBbczS_3krqsdFs=.05eca901-f55f-47d9-b1bc-0cf2f5b87536@github.com>
 <xDqqtB7TheeLd3XFDYpM3wGLBiNupA5azSbnC2b5EKU=.a1670b43-7467-4009-9a6b-056e3c7265f8@github.com>
 <avbAmX-S_MAOZdvQnJleQySR2ngsDS5ELNCRAuWpzkI=.6b161234-cf8e-47d6-a5cb-d9891a483837@github.com>
Message-ID: <eCFHU69SKQpSlZyHJfmABBrCNtUcKIYh9zPZTmPpSdk=.5f1a6051-5e06-4290-8225-14e6e602492e@github.com>

On Mon, 6 Feb 2023 11:56:22 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/System.java line 2671:
>> 
>>> 2669:                 if (false) {
>>> 2670:                     // Arrays.mismatch without the range checks (~5% faster micro getEntryHit)
>>> 2671:                     int aLength = encoded.length;
>> 
>> Part of the difference you're seeing is due to knowing that you'll be matching the entire length of the first array (`encoded, 0, encoded.length`).
>> 
>> As an experiment I added `Arrays.mismatch(byte[], byte[], int, int)` to mismatch the entire range of the first array argument vs the range of the second and can spot an improvement in affected micros:
>> 
>> Benchmark                                     (size)  Mode  Cnt   Score   Error  Units
>> ArraysMismatch.Char.differentSubrangeMatches      90  avgt   10  12.165 ? 0.074  ns/op # mismatch(a, aFrom, aTo, b, bFrom, bTo)
>> ArraysMismatch.Char.subrangeMatches               90  avgt   10  10.748 ? 0.006  ns/op # mismatch(a, b, bFrom, bTo)
>> 
>> This might be something we can solve in the JITs without having to add new methods to `java.util.Arrays` to deal as efficiently as possible with the case when we're matching against the entirety of one of the arrays.
>
> Interesting. Would be nice to solve this in the JIT!
> 
> This disabled code got deleted in my last commit, but it seems like you have a good analysis so we can let it go now.

Right. I might have fumbled this experiment a bit, and perhaps your setup would inline and then eliminate some of the known-in-range checks already. 

Though we have intrinsified some of the `Preconditions.check*` methods in the past to help improve range checks, but the `checkFromToIndex` method that would be applicable here has not been intrinsified. It might be a reasonable path forward to replace `Arrays.rangeCheck` with `Preconditions.checkFromToIndex` and then look at intrinsifying that method to help eliminating or optimizing some of the checks.

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

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

From redestad at openjdk.org  Mon Feb  6 15:03:47 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Mon, 6 Feb 2023 15:03:47 GMT
Subject: RFR: 8301873: Avoid string decoding in ZipFile.Source.getEntryPos
In-Reply-To: <eCFHU69SKQpSlZyHJfmABBrCNtUcKIYh9zPZTmPpSdk=.5f1a6051-5e06-4290-8225-14e6e602492e@github.com>
References: <FkmdspiHVjkAKFqm5kUgwaf55YH5cBbczS_3krqsdFs=.05eca901-f55f-47d9-b1bc-0cf2f5b87536@github.com>
 <xDqqtB7TheeLd3XFDYpM3wGLBiNupA5azSbnC2b5EKU=.a1670b43-7467-4009-9a6b-056e3c7265f8@github.com>
 <avbAmX-S_MAOZdvQnJleQySR2ngsDS5ELNCRAuWpzkI=.6b161234-cf8e-47d6-a5cb-d9891a483837@github.com>
 <eCFHU69SKQpSlZyHJfmABBrCNtUcKIYh9zPZTmPpSdk=.5f1a6051-5e06-4290-8225-14e6e602492e@github.com>
Message-ID: <FpTjuqARcCTWFJv5H1LBcyL5fYSp5XXRvhGaFWqP2N8=.dae5bb05-fead-4fe7-8a20-9882b13962da@github.com>

On Mon, 6 Feb 2023 14:27:36 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> Interesting. Would be nice to solve this in the JIT!
>> 
>> This disabled code got deleted in my last commit, but it seems like you have a good analysis so we can let it go now.
>
> Right. I might have fumbled this experiment a bit, and perhaps your setup would inline and then eliminate some of the known-in-range checks already. 
> 
> Though we have intrinsified some of the `Preconditions.check*` methods in the past to help improve range checks, but the `checkFromToIndex` method that would be applicable here has not been intrinsified. It might be a reasonable path forward to replace `Arrays.rangeCheck` with `Preconditions.checkFromToIndex` and then look at intrinsifying that method to help eliminating or optimizing some of the checks.

Nevermind, I had a flaw in my experiment and seems the first range check in a call like `Arrays.mismatch(encoded, 0, encoded.length, b, off, off+len);` should be eliminated. So perhaps you're seeing the cost of the second range check, which might be unavoidable to be safe (zip meta data could otherwise be doctored to try and perform out of bounds reads via intrinsified code)

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

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

From duke at openjdk.org  Mon Feb  6 15:03:49 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Mon, 6 Feb 2023 15:03:49 GMT
Subject: RFR: 8301873: Avoid string decoding in ZipFile.Source.getEntryPos
In-Reply-To: <8y5f1YxDu1ALUEanR55V1S4za2fgUdWcarnFVqU3AR8=.67a750cd-d1db-4f0f-8a55-f3c2938d2090@github.com>
References: <FkmdspiHVjkAKFqm5kUgwaf55YH5cBbczS_3krqsdFs=.05eca901-f55f-47d9-b1bc-0cf2f5b87536@github.com>
 <8y5f1YxDu1ALUEanR55V1S4za2fgUdWcarnFVqU3AR8=.67a750cd-d1db-4f0f-8a55-f3c2938d2090@github.com>
Message-ID: <UO7zdMbi3wAPMizFEKQ3dVuxLC4by60G8zVZMhsbzwg=.8f145eb7-d571-4244-80b4-85ab2dbab760@github.com>

On Mon, 30 Jan 2023 14:20:58 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

>> After finding a hash match, getEntryPos needs to compare the lookup name up to the encoded entry name in the CEN. This comparison is done by decoding the entry name into a String. The names can then be compared using the String API. This decoding step adds a significat cost to this method.
>> 
>> This PR suggest to update the string comparison such that in the common case where  both the lookup name and the entry name are encoded in ASCII-compatible UTF-8,  decoding can be avoided and the byte arrays can instead be compared direcly. 
>> 
>> ZipCoder is updated with a new method to compare a string with an encoded byte array range.  The default implementation decodes to string (like the current code), while the UTF-8 implementation uses JavaLangAccess.getBytesNoRepl to get the  bytes. Both methods thes uses Arrays.mismatch for comparison with or without matching trailing slashes. 
>> 
>> Additionally, this PR suggest to make the following updates to getEntryPos:
>> 
>> - The try/catch for IAE is redundant and can be safely removed. (initCEN already checks this and will throws IAE for invalid UTF-8). This seems to give a 3-4% speedup on micros)
>> - A new test InvalidBytesInEntryNameOrComment is a added to verify that initCEN does in fact reject invalid UTF-8 in CEN file names and comments. (I found no existing test coverage for this)
>> - The recursion when looking for "name/" matches is replaced with iteration. We keep track of any "name/" match and return it at the end of the search. (I feel this is easier to follow and it also gives a ~30% speedup for addSlash lookups with no regression on regular lookups)
>> 
>> (My though is that including these additional updates in this PR might reduce reviewer overhead given that it touches the exact same code. I might be wrong on this, please advise :)
>> 
>> I'm seeing a ~17% saving on the micro ZipFileGetEntry.getEntryHit (modified to use xalan.jar):
>> 
>> Baseline:
>> 
>> Benchmark                             (size)  Mode  Cnt    Score   Error  Units
>> ZipFileGetEntry.getEntryHit              512  avgt   15   74.941 ? 1.004  ns/op
>> ZipFileGetEntry.getEntryHit             1024  avgt   15   84.943 ? 1.320  ns/op
>> ZipFileGetEntry.getEntryHitUncached      512  avgt   15  120.371 ? 2.386  ns/op
>> ZipFileGetEntry.getEntryHitUncached     1024  avgt   15  126.128 ? 1.075  ns/op
>> ZipFileGetEntry.getEntryMiss             512  avgt   15   23.818 ? 0.838  ns/op
>> ZipFileGetEntry.getEntryMiss            1024  avgt   15   29.762 ? 5.998  ns/op
>> ZipFileGetEntry.getEntryMissUncached     512  avgt   15   59.405 ? 0.545  ns/op
>> ZipFileGetEntry.getEntryMissUncached    1024  avgt   15   71.840 ? 2.455  ns/op
>> ZipFileGetEntry.getEntrySlash            512  avgt   15  135.621 ? 4.341  ns/op
>> ZipFileGetEntry.getEntrySlash           1024  avgt   15  134.190 ? 2.141  ns/op
>> 
>> 
>> 
>> PR:
>> 
>> 
>> Benchmark                             (size)  Mode  Cnt    Score   Error  Units
>> ZipFileGetEntry.getEntryHit              512  avgt   15   62.267 ? 1.329  ns/op
>> ZipFileGetEntry.getEntryHit             1024  avgt   15   72.916 ? 2.428  ns/op
>> ZipFileGetEntry.getEntryHitUncached      512  avgt   15  101.630 ? 1.154  ns/op
>> ZipFileGetEntry.getEntryHitUncached     1024  avgt   15  113.161 ? 0.502  ns/op
>> ZipFileGetEntry.getEntryMiss             512  avgt   15   23.003 ? 1.191  ns/op
>> ZipFileGetEntry.getEntryMiss            1024  avgt   15   23.236 ? 1.114  ns/op
>> ZipFileGetEntry.getEntryMissUncached     512  avgt   15   56.781 ? 1.505  ns/op
>> ZipFileGetEntry.getEntryMissUncached    1024  avgt   15   67.767 ? 1.963  ns/op
>> ZipFileGetEntry.getEntrySlash            512  avgt   15   73.745 ? 2.717  ns/op
>> ZipFileGetEntry.getEntrySlash           1024  avgt   15   75.784 ? 1.051  ns/op
>> 
>> 
>> To assess the impact on startup/warmup, I made a main method class which measures the total time of calling ZipFile.getEntry for all entries in the 109 JAR file dependenies of spring-petclinic. The shows a nice improvement (time in micros):
>> 
>> 
>> Percentile Baseline Patch
>> 50?%          23155 21149
>> 75?%          23598 21454
>> 90?%          23989 21691
>> 95?%          24238 21973
>> 99?%          25270 22446
>> STDEV           792   549
>> Count           500   500
>
> src/java.base/share/classes/java/lang/System.java line 2678:
> 
>> 2676:                 }
>> 2677:                 return Arrays.mismatch(encoded, 0, encoded.length, b, fromIndex, toIndex);
>> 2678:             }
> 
> Leaving the ArraySupport.mismatch code here for now if anyone wants to investigate the ~3% regression introduced by the range checks in Arrays.mismatch

The performance hit of using Arrays.mismatch instead of  ArraysSupport might be more like 5% actually:


Benchmark                             (size)  Mode  Cnt    Score    Error  Units
ZipFileGetEntry.getEntryHit              512  avgt   15   59.149 ?  0.820  ns/op
ZipFileGetEntry.getEntryHit             1024  avgt   15   73.250 ?  1.114  ns/op
ZipFileGetEntry.getEntryHitUncached      512  avgt   15  103.377 ?  1.118  ns/op
ZipFileGetEntry.getEntryHitUncached     1024  avgt   15  115.418 ?  2.767  ns/op
ZipFileGetEntry.getEntryMiss             512  avgt   15   22.200 ?  0.145  ns/op
ZipFileGetEntry.getEntryMiss            1024  avgt   15   22.528 ?  0.271  ns/op
ZipFileGetEntry.getEntryMissUncached     512  avgt   15   57.359 ?  0.428  ns/op
ZipFileGetEntry.getEntryMissUncached    1024  avgt   15   68.013 ?  2.070  ns/op
ZipFileGetEntry.getEntrySlash            512  avgt   15   72.407 ?  0.603  ns/op
ZipFileGetEntry.getEntrySlash           1024  avgt   15   82.875 ? 11.094  ns/op

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

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

From duke at openjdk.org  Mon Feb  6 15:21:10 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Mon, 6 Feb 2023 15:21:10 GMT
Subject: RFR: 8301873: Avoid string decoding in ZipFile.Source.getEntryPos
 [v2]
In-Reply-To: <FkmdspiHVjkAKFqm5kUgwaf55YH5cBbczS_3krqsdFs=.05eca901-f55f-47d9-b1bc-0cf2f5b87536@github.com>
References: <FkmdspiHVjkAKFqm5kUgwaf55YH5cBbczS_3krqsdFs=.05eca901-f55f-47d9-b1bc-0cf2f5b87536@github.com>
Message-ID: <_-_GFWJh2QwMpBbASlE3co1kr__pKBxahIU_EoHsix8=.05d0cd8a-b5de-456f-a740-75f2214870d3@github.com>

> After finding a hash match, getEntryPos needs to compare the lookup name up to the encoded entry name in the CEN. This comparison is done by decoding the entry name into a String. The names can then be compared using the String API. This decoding step adds a significat cost to this method.
> 
> This PR suggest to update the string comparison such that in the common case where  both the lookup name and the entry name are encoded in ASCII-compatible UTF-8,  decoding can be avoided and the byte arrays can instead be compared direcly. 
> 
> ZipCoder is updated with a new method to compare a string with an encoded byte array range.  The default implementation decodes to string (like the current code), while the UTF-8 implementation uses JavaLangAccess.getBytesNoRepl to get the  bytes. Both methods thes uses Arrays.mismatch for comparison with or without matching trailing slashes. 
> 
> Additionally, this PR suggest to make the following updates to getEntryPos:
> 
> - The try/catch for IAE is redundant and can be safely removed. (initCEN already checks this and will throws IAE for invalid UTF-8). This seems to give a 3-4% speedup on micros)
> - A new test InvalidBytesInEntryNameOrComment is a added to verify that initCEN does in fact reject invalid UTF-8 in CEN file names and comments. (I found no existing test coverage for this)
> - The recursion when looking for "name/" matches is replaced with iteration. We keep track of any "name/" match and return it at the end of the search. (I feel this is easier to follow and it also gives a ~30% speedup for addSlash lookups with no regression on regular lookups)
> 
> (My though is that including these additional updates in this PR might reduce reviewer overhead given that it touches the exact same code. I might be wrong on this, please advise :)
> 
> I'm seeing a ~17% saving on the micro ZipFileGetEntry.getEntryHit (modified to use xalan.jar):
> 
> Baseline:
> 
> Benchmark                             (size)  Mode  Cnt    Score   Error  Units
> ZipFileGetEntry.getEntryHit              512  avgt   15   74.941 ? 1.004  ns/op
> ZipFileGetEntry.getEntryHit             1024  avgt   15   84.943 ? 1.320  ns/op
> ZipFileGetEntry.getEntryHitUncached      512  avgt   15  120.371 ? 2.386  ns/op
> ZipFileGetEntry.getEntryHitUncached     1024  avgt   15  126.128 ? 1.075  ns/op
> ZipFileGetEntry.getEntryMiss             512  avgt   15   23.818 ? 0.838  ns/op
> ZipFileGetEntry.getEntryMiss            1024  avgt   15   29.762 ? 5.998  ns/op
> ZipFileGetEntry.getEntryMissUncached     512  avgt   15   59.405 ? 0.545  ns/op
> ZipFileGetEntry.getEntryMissUncached    1024  avgt   15   71.840 ? 2.455  ns/op
> ZipFileGetEntry.getEntrySlash            512  avgt   15  135.621 ? 4.341  ns/op
> ZipFileGetEntry.getEntrySlash           1024  avgt   15  134.190 ? 2.141  ns/op
> 
> 
> 
> PR:
> 
> 
> Benchmark                             (size)  Mode  Cnt    Score   Error  Units
> ZipFileGetEntry.getEntryHit              512  avgt   15   62.267 ? 1.329  ns/op
> ZipFileGetEntry.getEntryHit             1024  avgt   15   72.916 ? 2.428  ns/op
> ZipFileGetEntry.getEntryHitUncached      512  avgt   15  101.630 ? 1.154  ns/op
> ZipFileGetEntry.getEntryHitUncached     1024  avgt   15  113.161 ? 0.502  ns/op
> ZipFileGetEntry.getEntryMiss             512  avgt   15   23.003 ? 1.191  ns/op
> ZipFileGetEntry.getEntryMiss            1024  avgt   15   23.236 ? 1.114  ns/op
> ZipFileGetEntry.getEntryMissUncached     512  avgt   15   56.781 ? 1.505  ns/op
> ZipFileGetEntry.getEntryMissUncached    1024  avgt   15   67.767 ? 1.963  ns/op
> ZipFileGetEntry.getEntrySlash            512  avgt   15   73.745 ? 2.717  ns/op
> ZipFileGetEntry.getEntrySlash           1024  avgt   15   75.784 ? 1.051  ns/op
> 
> 
> To assess the impact on startup/warmup, I made a main method class which measures the total time of calling ZipFile.getEntry for all entries in the 109 JAR file dependenies of spring-petclinic. The shows a nice improvement (time in micros):
> 
> 
> Percentile Baseline Patch
> 50?%          23155 21149
> 75?%          23598 21454
> 90?%          23989 21691
> 95?%          24238 21973
> 99?%          25270 22446
> STDEV           792   549
> Count           500   500

Eirik Bjorsnos has updated the pull request incrementally with one additional commit since the last revision:

  Spelling fix in test data for non-ascii latin1 string

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12290/files
  - new: https://git.openjdk.org/jdk/pull/12290/files/3ca98e21..d0c12325

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

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

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

From duke at openjdk.org  Mon Feb  6 15:21:11 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Mon, 6 Feb 2023 15:21:11 GMT
Subject: RFR: 8301873: Avoid string decoding in ZipFile.Source.getEntryPos
 [v2]
In-Reply-To: <_-_GFWJh2QwMpBbASlE3co1kr__pKBxahIU_EoHsix8=.05d0cd8a-b5de-456f-a740-75f2214870d3@github.com>
References: <FkmdspiHVjkAKFqm5kUgwaf55YH5cBbczS_3krqsdFs=.05eca901-f55f-47d9-b1bc-0cf2f5b87536@github.com>
 <_-_GFWJh2QwMpBbASlE3co1kr__pKBxahIU_EoHsix8=.05d0cd8a-b5de-456f-a740-75f2214870d3@github.com>
Message-ID: <aetLV3k8G1u-yGPlhDGy_AskhX2NqM5nmVLj8kHJfY4=.41d597fb-cc92-4398-9f54-f152b8e1d40c@github.com>

On Mon, 6 Feb 2023 15:17:14 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

>> After finding a hash match, getEntryPos needs to compare the lookup name up to the encoded entry name in the CEN. This comparison is done by decoding the entry name into a String. The names can then be compared using the String API. This decoding step adds a significat cost to this method.
>> 
>> This PR suggest to update the string comparison such that in the common case where  both the lookup name and the entry name are encoded in ASCII-compatible UTF-8,  decoding can be avoided and the byte arrays can instead be compared direcly. 
>> 
>> ZipCoder is updated with a new method to compare a string with an encoded byte array range.  The default implementation decodes to string (like the current code), while the UTF-8 implementation uses JavaLangAccess.getBytesNoRepl to get the  bytes. Both methods thes uses Arrays.mismatch for comparison with or without matching trailing slashes. 
>> 
>> Additionally, this PR suggest to make the following updates to getEntryPos:
>> 
>> - The try/catch for IAE is redundant and can be safely removed. (initCEN already checks this and will throws IAE for invalid UTF-8). This seems to give a 3-4% speedup on micros)
>> - A new test InvalidBytesInEntryNameOrComment is a added to verify that initCEN does in fact reject invalid UTF-8 in CEN file names and comments. (I found no existing test coverage for this)
>> - The recursion when looking for "name/" matches is replaced with iteration. We keep track of any "name/" match and return it at the end of the search. (I feel this is easier to follow and it also gives a ~30% speedup for addSlash lookups with no regression on regular lookups)
>> 
>> (My though is that including these additional updates in this PR might reduce reviewer overhead given that it touches the exact same code. I might be wrong on this, please advise :)
>> 
>> I'm seeing a ~17% saving on the micro ZipFileGetEntry.getEntryHit (modified to use xalan.jar):
>> 
>> Baseline:
>> 
>> Benchmark                             (size)  Mode  Cnt    Score   Error  Units
>> ZipFileGetEntry.getEntryHit              512  avgt   15   74.941 ? 1.004  ns/op
>> ZipFileGetEntry.getEntryHit             1024  avgt   15   84.943 ? 1.320  ns/op
>> ZipFileGetEntry.getEntryHitUncached      512  avgt   15  120.371 ? 2.386  ns/op
>> ZipFileGetEntry.getEntryHitUncached     1024  avgt   15  126.128 ? 1.075  ns/op
>> ZipFileGetEntry.getEntryMiss             512  avgt   15   23.818 ? 0.838  ns/op
>> ZipFileGetEntry.getEntryMiss            1024  avgt   15   29.762 ? 5.998  ns/op
>> ZipFileGetEntry.getEntryMissUncached     512  avgt   15   59.405 ? 0.545  ns/op
>> ZipFileGetEntry.getEntryMissUncached    1024  avgt   15   71.840 ? 2.455  ns/op
>> ZipFileGetEntry.getEntrySlash            512  avgt   15  135.621 ? 4.341  ns/op
>> ZipFileGetEntry.getEntrySlash           1024  avgt   15  134.190 ? 2.141  ns/op
>> 
>> 
>> 
>> PR:
>> 
>> 
>> Benchmark                             (size)  Mode  Cnt    Score   Error  Units
>> ZipFileGetEntry.getEntryHit              512  avgt   15   62.267 ? 1.329  ns/op
>> ZipFileGetEntry.getEntryHit             1024  avgt   15   72.916 ? 2.428  ns/op
>> ZipFileGetEntry.getEntryHitUncached      512  avgt   15  101.630 ? 1.154  ns/op
>> ZipFileGetEntry.getEntryHitUncached     1024  avgt   15  113.161 ? 0.502  ns/op
>> ZipFileGetEntry.getEntryMiss             512  avgt   15   23.003 ? 1.191  ns/op
>> ZipFileGetEntry.getEntryMiss            1024  avgt   15   23.236 ? 1.114  ns/op
>> ZipFileGetEntry.getEntryMissUncached     512  avgt   15   56.781 ? 1.505  ns/op
>> ZipFileGetEntry.getEntryMissUncached    1024  avgt   15   67.767 ? 1.963  ns/op
>> ZipFileGetEntry.getEntrySlash            512  avgt   15   73.745 ? 2.717  ns/op
>> ZipFileGetEntry.getEntrySlash           1024  avgt   15   75.784 ? 1.051  ns/op
>> 
>> 
>> To assess the impact on startup/warmup, I made a main method class which measures the total time of calling ZipFile.getEntry for all entries in the 109 JAR file dependenies of spring-petclinic. The shows a nice improvement (time in micros):
>> 
>> 
>> Percentile Baseline Patch
>> 50?%          23155 21149
>> 75?%          23598 21454
>> 90?%          23989 21691
>> 95?%          24238 21973
>> 99?%          25270 22446
>> STDEV           792   549
>> Count           500   500
>
> Eirik Bjorsnos has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Spelling fix in test data for non-ascii latin1 string

test/jdk/java/util/zip/ZipFile/TestZipFileEncodings.java line 126:

> 124:         // latin1, but not ASCII
> 125:         String entryName = "sm?rg?rdsbord";
> 126: 

@cl4es Are we ok with non-ASCII in source files? I'd hate to escape this ;-)

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

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

From jcking at openjdk.org  Mon Feb  6 15:24:49 2023
From: jcking at openjdk.org (Justin King)
Date: Mon, 6 Feb 2023 15:24:49 GMT
Subject: RFR: JDK-8301621: libzip should use pread instead of lseek+read
In-Reply-To: <3bJG6XaNtGLpJ7tUCH82VSmfGirG_KeaOu5KR0EDtyo=.5a43e09e-43a4-479d-a34e-e81f6095ed41@github.com>
References: <pjSF1ED9D3FXjCFeqz2MRllCf0UT9suWaYa4O7kFeCM=.d16583a7-2c82-46c2-aaf1-2102c8978f2b@github.com>
 <3bJG6XaNtGLpJ7tUCH82VSmfGirG_KeaOu5KR0EDtyo=.5a43e09e-43a4-479d-a34e-e81f6095ed41@github.com>
Message-ID: <In0QIKSjkj7JM4z1zBb9nWPOpcb8q7Golpjk-BdbdmY=.3b4e1c18-c5ba-4a0b-ab82-386d6956638b@github.com>

On Sun, 5 Feb 2023 19:04:24 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> Are you planning to include benchmark results to go with this change?
> 
> It should be okay to change readFullyAt to use pread, and ReadFile with an OV with the position. The latter has a side effect that it changes the file pointer but it should be okay in the zip code. One thing that the changes highlight is that this native file is begging to be refactoring into platform specific code (this isn't the PR to do that).
> 
> In passing, the JNI code use 4 space indent, not 2.
> 
> The O_CLOEXEC part is probably okay but if you look at the Runtime.exec/Process implementation you'll see that it isn't really because that code closes all file descriptors on exec.

I can add benchmarks later this week. I'll also fix the indentation. On `O_CLOEXEC`, closing after exec isn't really foolproof. Additionally that requires always using the Java method of subprocess spawning, which isn't always the case. `O_CLOEXEC` covers all use cases and is generally the correct thing to do unless a file descriptor is explicitly intended to be shared.

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

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

From duke at openjdk.org  Mon Feb  6 15:29:59 2023
From: duke at openjdk.org (Viktor Klang)
Date: Mon, 6 Feb 2023 15:29:59 GMT
Subject: Integrated: JDK-8300098 :
 java/util/concurrent/ConcurrentHashMap/ConcurrentAssociateTest.java fails with
 internal timeout when executed with TieredCompilation1/3
In-Reply-To: <CPbu_uqDyvV1hu2fjL-A6LIx3kK-ncM26_cDlXVxIeY=.1c30805e-ff8c-432d-a5a9-c9ca59383ace@github.com>
References: <CPbu_uqDyvV1hu2fjL-A6LIx3kK-ncM26_cDlXVxIeY=.1c30805e-ff8c-432d-a5a9-c9ca59383ace@github.com>
Message-ID: <XK4rn4eIcY8bD69dmvg75pkldOz47vjVlTDXV2uFY7s=.41644776-2c98-449f-9a25-9bc3d05a77ac@github.com>

On Tue, 31 Jan 2023 10:45:07 GMT, Viktor Klang <duke at openjdk.org> wrote:

> The proposed fix by @DougLea ensures that the state transition into waiting is retried in the cases where a previous waiter isn't making progress and a new waiter goes into waiting.

This pull request has now been integrated.

Changeset: ecf8842c
Author:    Viktor Klang <viktor.klang at oracle.com>
Committer: Alan Bateman <alanb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/ecf8842cd2309210f3d5eee7f9f28a198a860686
Stats:     12 lines in 1 file changed: 2 ins; 2 del; 8 mod

8300098: java/util/concurrent/ConcurrentHashMap/ConcurrentAssociateTest.java fails with internal timeout when executed with TieredCompilation1/3

Co-authored-by: Doug Lea <dl at openjdk.org>
Reviewed-by: jpai, alanb

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

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

From rriggs at openjdk.org  Mon Feb  6 15:37:53 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 6 Feb 2023 15:37:53 GMT
Subject: RFR: 8301737:
 java/rmi/server/UnicastRemoteObject/serialFilter/FilterUROTest.java fail with
 -Xcomp [v2]
In-Reply-To: <_KLsDrGvRYUmtKo962dExyk9Ajb6blQnPOXbGpO5mN0=.bdb33bcb-799d-4a8f-979a-bb0c2f3ce3a1@github.com>
References: <l5m5_9io2QMSFNY7dBHT3Nr2I9Er8wmd92Ze8FP-XE0=.a40d29be-77be-4719-a0a0-71d032eea1e5@github.com>
 <_KLsDrGvRYUmtKo962dExyk9Ajb6blQnPOXbGpO5mN0=.bdb33bcb-799d-4a8f-979a-bb0c2f3ce3a1@github.com>
Message-ID: <2FSnoFjlzmgc-lNVYeTYH8x4fBt_xTI8IG62e9jNf2s=.6f6dde1f-296d-4dff-960f-798b6f87c24c@github.com>

On Mon, 6 Feb 2023 11:44:07 GMT, SUN Guoyun <duke at openjdk.org> wrote:

>> Hi all,
>> When -Xcomp be used, this testcase will use more codecaches, causing the GC to be triggered early, then causing this test failed on LoongArch64 architecture.
>> 
>> This PR fix the issue, Please help review it.
>> 
>> Thanks.
>
> SUN Guoyun has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8301737: java/rmi/server/UnicastRemoteObject/serialFilter/FilterUROTest.java fail with -Xcomp

Please add @bug 8301737

It is not going to be obvious why a larger code cashe is needed (and only for aarch64).

Can you split the test runs so the original does not run on aarch64 and a new second run runs only on aarch64. For example,

/*
 * @test
 * @bug 8301737
 * @summary Check that objects are exported with ObjectInputFilters via UnicastRemoteObject
 * @requires os.arch != "aarch64"
 * @run testng/othervm FilterUROTest
 */

/*
 * @test
 * @summary Check that objects are exported with ObjectInputFilters via UnicastRemoteObject
 * @requires os.arch == "aarch64"
 * @run testng/othervm -XX:ReservedCodeCacheSize=512m FilterUROTest
 */

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

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

From weijun at openjdk.org  Mon Feb  6 15:47:52 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Mon, 6 Feb 2023 15:47:52 GMT
Subject: RFR: 8300259: Add test coverage for processing of pending block
 files in signed JARs [v2]
In-Reply-To: <C6eR-gsDGOO9u4-ELduSXdACSe_sdwkGW_p5hVuC3ug=.5fdb1397-16d0-4922-b8cb-33c5dcb859e0@github.com>
References: <cyoAdel_KXj3W8Giw6FWoblQM3zXAJBoks4AG1jqZgo=.3b04f7ca-d8eb-40da-812f-c371210b1f8b@github.com>
 <C6eR-gsDGOO9u4-ELduSXdACSe_sdwkGW_p5hVuC3ug=.5fdb1397-16d0-4922-b8cb-33c5dcb859e0@github.com>
Message-ID: <47NuYXRJbBJslno6CYAQ9VwCzpyc-QY7y55Np-3Iwng=.02d5cd14-745c-42aa-a2a2-2589280266fa@github.com>

On Tue, 17 Jan 2023 18:54:13 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

>> This PR adds test coverage for pending block files in signed JAR files
>> 
>> A signed JAR has pending block files if the block file [RSA, DSA, EC] comes before the corresponding signature file [SF] in the JAR. 
>> 
>> JarVerifier.processEntry supports processing of such pending block files, but this code path does not seem to be exercised by current test.
>> 
>> The new test PendingBlocksJar checks that signed JARs  with pending blocks are processed correctly, both for the valid and invalid cases.
>
> Eirik Bjorsnos has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Make it more clear in the @summary tag that it is the block file that is pending, not the signature file
>  - Renamed test from PendingBlocksJar to more descriptive SignedJarPendingBlock

Marked as reviewed by weijun (Reviewer).

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

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

From redestad at openjdk.org  Mon Feb  6 15:55:52 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Mon, 6 Feb 2023 15:55:52 GMT
Subject: RFR: 8301873: Avoid string decoding in ZipFile.Source.getEntryPos
 [v2]
In-Reply-To: <aetLV3k8G1u-yGPlhDGy_AskhX2NqM5nmVLj8kHJfY4=.41d597fb-cc92-4398-9f54-f152b8e1d40c@github.com>
References: <FkmdspiHVjkAKFqm5kUgwaf55YH5cBbczS_3krqsdFs=.05eca901-f55f-47d9-b1bc-0cf2f5b87536@github.com>
 <_-_GFWJh2QwMpBbASlE3co1kr__pKBxahIU_EoHsix8=.05d0cd8a-b5de-456f-a740-75f2214870d3@github.com>
 <aetLV3k8G1u-yGPlhDGy_AskhX2NqM5nmVLj8kHJfY4=.41d597fb-cc92-4398-9f54-f152b8e1d40c@github.com>
Message-ID: <C2b10FjDXIwxDfQoB3DuFjrfA1qzbQR3LbJ8HNN11G0=.c644ab25-5876-4917-bfdf-b8fba9734ffc@github.com>

On Mon, 6 Feb 2023 15:14:37 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

>> Eirik Bjorsnos has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Spelling fix in test data for non-ascii latin1 string
>
> test/jdk/java/util/zip/ZipFile/TestZipFileEncodings.java line 126:
> 
>> 124:         // latin1, but not ASCII
>> 125:         String entryName = "sm?rg?rdsbord";
>> 126: 
> 
> @cl4es Are we ok with non-ASCII in source files? I'd hate to escape this ;-)

As long as the file is UTF-8 encoded then I think it should be fine. Thanks for fixing the spelling before I could remark on it! :D

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

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

From duke at openjdk.org  Mon Feb  6 15:57:01 2023
From: duke at openjdk.org (altrisi)
Date: Mon, 6 Feb 2023 15:57:01 GMT
Subject: RFR: 8301834: Templated Buffer classes leave a lot of empty lines
 in the generated source
In-Reply-To: <NShlonPoOpwt90csJyyyz71GUhwMkuVuXi1Ev8p8jcE=.17eec3ac-280e-4abc-9c39-76753c62d14f@github.com>
References: <NShlonPoOpwt90csJyyyz71GUhwMkuVuXi1Ev8p8jcE=.17eec3ac-280e-4abc-9c39-76753c62d14f@github.com>
Message-ID: <3ebCEPYLnPp4ZzR3-qPt0oLtVpi_1PoSy8F0Wh4MMw8=.3b261957-848f-4d0a-a2ee-76a2d9c27b74@github.com>

On Mon, 6 Feb 2023 06:57:43 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review for this change which proposes to fix the issue noted in https://bugs.openjdk.org/browse/JDK-8301834?
> 
> Some classes in `java.nio` package are generated from template files, during the build. The template files are processed by a build tool implemented by a Java class `make/jdk/src/classes/build/tools/spp/Spp.java`. This template processing tool allows for an (optional) parameter called `-nel` which as per its documentation:
> 
>>  If -nel is declared then empty lines will not be substituted for lines of
>>  text in the template that do not appear in the output.
> 
> Various places in the JDK build where this tool is used to generate source from template files, already use the `-nel` option to not generate the empty lines in the source files. However, the `GensrcBuffer.gmk` which generates the source for `java.nio` classes doesn't use this option. The commit in this PR adds this option when generating the `java.nio` classes.
> 
> Existing tests in `test/jdk/java/nio` continue to pass after this change. I've checked the generated content and compared it with the older versions to verify that these empty lines no longer appear in these generated classes.
> 
> Additional `tier` testing has been triggered to make sure no regression is introduced.

Would it be feasible (and useful) to maybe just in release builds have these removed? Or maybe create some mappings to the templates for the debugging purposes? Some classes get very unreadable with these.

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

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

From redestad at openjdk.org  Mon Feb  6 15:58:52 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Mon, 6 Feb 2023 15:58:52 GMT
Subject: RFR: 8301873: Avoid string decoding in ZipFile.Source.getEntryPos
 [v2]
In-Reply-To: <_-_GFWJh2QwMpBbASlE3co1kr__pKBxahIU_EoHsix8=.05d0cd8a-b5de-456f-a740-75f2214870d3@github.com>
References: <FkmdspiHVjkAKFqm5kUgwaf55YH5cBbczS_3krqsdFs=.05eca901-f55f-47d9-b1bc-0cf2f5b87536@github.com>
 <_-_GFWJh2QwMpBbASlE3co1kr__pKBxahIU_EoHsix8=.05d0cd8a-b5de-456f-a740-75f2214870d3@github.com>
Message-ID: <4y6TArTKErM-B-nDJCqh2482tTMiyCak05SI9wAqCfM=.3651c522-f00a-4e72-b757-18df5a0a6ae1@github.com>

On Mon, 6 Feb 2023 15:21:10 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

>> After finding a hash match, getEntryPos needs to compare the lookup name up to the encoded entry name in the CEN. This comparison is done by decoding the entry name into a String. The names can then be compared using the String API. This decoding step adds a significat cost to this method.
>> 
>> This PR suggest to update the string comparison such that in the common case where  both the lookup name and the entry name are encoded in ASCII-compatible UTF-8,  decoding can be avoided and the byte arrays can instead be compared direcly. 
>> 
>> ZipCoder is updated with a new method to compare a string with an encoded byte array range.  The default implementation decodes to string (like the current code), while the UTF-8 implementation uses JavaLangAccess.getBytesNoRepl to get the  bytes. Both methods thes uses Arrays.mismatch for comparison with or without matching trailing slashes. 
>> 
>> Additionally, this PR suggest to make the following updates to getEntryPos:
>> 
>> - The try/catch for IAE is redundant and can be safely removed. (initCEN already checks this and will throws IAE for invalid UTF-8). This seems to give a 3-4% speedup on micros)
>> - A new test InvalidBytesInEntryNameOrComment is a added to verify that initCEN does in fact reject invalid UTF-8 in CEN file names and comments. (I found no existing test coverage for this)
>> - The recursion when looking for "name/" matches is replaced with iteration. We keep track of any "name/" match and return it at the end of the search. (I feel this is easier to follow and it also gives a ~30% speedup for addSlash lookups with no regression on regular lookups)
>> 
>> (My though is that including these additional updates in this PR might reduce reviewer overhead given that it touches the exact same code. I might be wrong on this, please advise :)
>> 
>> I'm seeing a ~17% saving on the micro ZipFileGetEntry.getEntryHit (modified to use xalan.jar):
>> 
>> Baseline:
>> 
>> Benchmark                             (size)  Mode  Cnt    Score   Error  Units
>> ZipFileGetEntry.getEntryHit              512  avgt   15   74.941 ? 1.004  ns/op
>> ZipFileGetEntry.getEntryHit             1024  avgt   15   84.943 ? 1.320  ns/op
>> ZipFileGetEntry.getEntryHitUncached      512  avgt   15  120.371 ? 2.386  ns/op
>> ZipFileGetEntry.getEntryHitUncached     1024  avgt   15  126.128 ? 1.075  ns/op
>> ZipFileGetEntry.getEntryMiss             512  avgt   15   23.818 ? 0.838  ns/op
>> ZipFileGetEntry.getEntryMiss            1024  avgt   15   29.762 ? 5.998  ns/op
>> ZipFileGetEntry.getEntryMissUncached     512  avgt   15   59.405 ? 0.545  ns/op
>> ZipFileGetEntry.getEntryMissUncached    1024  avgt   15   71.840 ? 2.455  ns/op
>> ZipFileGetEntry.getEntrySlash            512  avgt   15  135.621 ? 4.341  ns/op
>> ZipFileGetEntry.getEntrySlash           1024  avgt   15  134.190 ? 2.141  ns/op
>> 
>> 
>> 
>> PR:
>> 
>> 
>> Benchmark                             (size)  Mode  Cnt    Score   Error  Units
>> ZipFileGetEntry.getEntryHit              512  avgt   15   62.267 ? 1.329  ns/op
>> ZipFileGetEntry.getEntryHit             1024  avgt   15   72.916 ? 2.428  ns/op
>> ZipFileGetEntry.getEntryHitUncached      512  avgt   15  101.630 ? 1.154  ns/op
>> ZipFileGetEntry.getEntryHitUncached     1024  avgt   15  113.161 ? 0.502  ns/op
>> ZipFileGetEntry.getEntryMiss             512  avgt   15   23.003 ? 1.191  ns/op
>> ZipFileGetEntry.getEntryMiss            1024  avgt   15   23.236 ? 1.114  ns/op
>> ZipFileGetEntry.getEntryMissUncached     512  avgt   15   56.781 ? 1.505  ns/op
>> ZipFileGetEntry.getEntryMissUncached    1024  avgt   15   67.767 ? 1.963  ns/op
>> ZipFileGetEntry.getEntrySlash            512  avgt   15   73.745 ? 2.717  ns/op
>> ZipFileGetEntry.getEntrySlash           1024  avgt   15   75.784 ? 1.051  ns/op
>> 
>> 
>> To assess the impact on startup/warmup, I made a main method class which measures the total time of calling ZipFile.getEntry for all entries in the 109 JAR file dependenies of spring-petclinic. The shows a nice improvement (time in micros):
>> 
>> 
>> Percentile Baseline Patch
>> 50?%          23155 21149
>> 75?%          23598 21454
>> 90?%          23989 21691
>> 95?%          24238 21973
>> 99?%          25270 22446
>> STDEV           792   549
>> Count           500   500
>
> Eirik Bjorsnos has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Spelling fix in test data for non-ascii latin1 string

test/jdk/java/util/zip/ZipFile/InvalidBytesInEntryNameOrComment.java line 153:

> 151:         // Need to skip past the length of the name and extra fields
> 152:         int nlen = buffer.getShort(off + NLEN);
> 153:         int elen = buffer.getShort(off + NLEN);

Is this supposed to say `ELEN`?

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

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

From redestad at openjdk.org  Mon Feb  6 16:02:53 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Mon, 6 Feb 2023 16:02:53 GMT
Subject: RFR: 8301873: Avoid string decoding in ZipFile.Source.getEntryPos
 [v2]
In-Reply-To: <_-_GFWJh2QwMpBbASlE3co1kr__pKBxahIU_EoHsix8=.05d0cd8a-b5de-456f-a740-75f2214870d3@github.com>
References: <FkmdspiHVjkAKFqm5kUgwaf55YH5cBbczS_3krqsdFs=.05eca901-f55f-47d9-b1bc-0cf2f5b87536@github.com>
 <_-_GFWJh2QwMpBbASlE3co1kr__pKBxahIU_EoHsix8=.05d0cd8a-b5de-456f-a740-75f2214870d3@github.com>
Message-ID: <nDhwZYL6cilJsFpKp5Ub3puvmqNc5Cz8UP9wgx7ADXY=.7263f482-7375-45d2-9e25-242eab276860@github.com>

On Mon, 6 Feb 2023 15:21:10 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

>> After finding a hash match, getEntryPos needs to compare the lookup name up to the encoded entry name in the CEN. This comparison is done by decoding the entry name into a String. The names can then be compared using the String API. This decoding step adds a significat cost to this method.
>> 
>> This PR suggest to update the string comparison such that in the common case where  both the lookup name and the entry name are encoded in ASCII-compatible UTF-8,  decoding can be avoided and the byte arrays can instead be compared direcly. 
>> 
>> ZipCoder is updated with a new method to compare a string with an encoded byte array range.  The default implementation decodes to string (like the current code), while the UTF-8 implementation uses JavaLangAccess.getBytesNoRepl to get the  bytes. Both methods thes uses Arrays.mismatch for comparison with or without matching trailing slashes. 
>> 
>> Additionally, this PR suggest to make the following updates to getEntryPos:
>> 
>> - The try/catch for IAE is redundant and can be safely removed. (initCEN already checks this and will throws IAE for invalid UTF-8). This seems to give a 3-4% speedup on micros)
>> - A new test InvalidBytesInEntryNameOrComment is a added to verify that initCEN does in fact reject invalid UTF-8 in CEN file names and comments. (I found no existing test coverage for this)
>> - The recursion when looking for "name/" matches is replaced with iteration. We keep track of any "name/" match and return it at the end of the search. (I feel this is easier to follow and it also gives a ~30% speedup for addSlash lookups with no regression on regular lookups)
>> 
>> (My though is that including these additional updates in this PR might reduce reviewer overhead given that it touches the exact same code. I might be wrong on this, please advise :)
>> 
>> I'm seeing a ~17% saving on the micro ZipFileGetEntry.getEntryHit (modified to use xalan.jar):
>> 
>> Baseline:
>> 
>> Benchmark                             (size)  Mode  Cnt    Score   Error  Units
>> ZipFileGetEntry.getEntryHit              512  avgt   15   74.941 ? 1.004  ns/op
>> ZipFileGetEntry.getEntryHit             1024  avgt   15   84.943 ? 1.320  ns/op
>> ZipFileGetEntry.getEntryHitUncached      512  avgt   15  120.371 ? 2.386  ns/op
>> ZipFileGetEntry.getEntryHitUncached     1024  avgt   15  126.128 ? 1.075  ns/op
>> ZipFileGetEntry.getEntryMiss             512  avgt   15   23.818 ? 0.838  ns/op
>> ZipFileGetEntry.getEntryMiss            1024  avgt   15   29.762 ? 5.998  ns/op
>> ZipFileGetEntry.getEntryMissUncached     512  avgt   15   59.405 ? 0.545  ns/op
>> ZipFileGetEntry.getEntryMissUncached    1024  avgt   15   71.840 ? 2.455  ns/op
>> ZipFileGetEntry.getEntrySlash            512  avgt   15  135.621 ? 4.341  ns/op
>> ZipFileGetEntry.getEntrySlash           1024  avgt   15  134.190 ? 2.141  ns/op
>> 
>> 
>> 
>> PR:
>> 
>> 
>> Benchmark                             (size)  Mode  Cnt    Score   Error  Units
>> ZipFileGetEntry.getEntryHit              512  avgt   15   62.267 ? 1.329  ns/op
>> ZipFileGetEntry.getEntryHit             1024  avgt   15   72.916 ? 2.428  ns/op
>> ZipFileGetEntry.getEntryHitUncached      512  avgt   15  101.630 ? 1.154  ns/op
>> ZipFileGetEntry.getEntryHitUncached     1024  avgt   15  113.161 ? 0.502  ns/op
>> ZipFileGetEntry.getEntryMiss             512  avgt   15   23.003 ? 1.191  ns/op
>> ZipFileGetEntry.getEntryMiss            1024  avgt   15   23.236 ? 1.114  ns/op
>> ZipFileGetEntry.getEntryMissUncached     512  avgt   15   56.781 ? 1.505  ns/op
>> ZipFileGetEntry.getEntryMissUncached    1024  avgt   15   67.767 ? 1.963  ns/op
>> ZipFileGetEntry.getEntrySlash            512  avgt   15   73.745 ? 2.717  ns/op
>> ZipFileGetEntry.getEntrySlash           1024  avgt   15   75.784 ? 1.051  ns/op
>> 
>> 
>> To assess the impact on startup/warmup, I made a main method class which measures the total time of calling ZipFile.getEntry for all entries in the 109 JAR file dependenies of spring-petclinic. The shows a nice improvement (time in micros):
>> 
>> 
>> Percentile Baseline Patch
>> 50?%          23155 21149
>> 75?%          23598 21454
>> 90?%          23989 21691
>> 95?%          24238 21973
>> 99?%          25270 22446
>> STDEV           792   549
>> Count           500   500
>
> Eirik Bjorsnos has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Spelling fix in test data for non-ascii latin1 string

I think this looks good. Glad we can get this done without adding even more ways to peek into `String` internals.

test/jdk/java/util/zip/ZipFile/InvalidBytesInEntryNameOrComment.java line 158:

> 156:         int coff = off + CEN_HDR + nlen + elen;
> 157: 
> 158:         // Write invald bytes

`invalid`

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

Marked as reviewed by redestad (Reviewer).

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

From duke at openjdk.org  Mon Feb  6 16:14:14 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Mon, 6 Feb 2023 16:14:14 GMT
Subject: RFR: 8301873: Avoid string decoding in ZipFile.Source.getEntryPos
 [v3]
In-Reply-To: <FkmdspiHVjkAKFqm5kUgwaf55YH5cBbczS_3krqsdFs=.05eca901-f55f-47d9-b1bc-0cf2f5b87536@github.com>
References: <FkmdspiHVjkAKFqm5kUgwaf55YH5cBbczS_3krqsdFs=.05eca901-f55f-47d9-b1bc-0cf2f5b87536@github.com>
Message-ID: <kocafii57-tSO8NfHg_5ywyqC_5DMPWa07dbqdG7884=.1e6e34d0-1e26-4ea7-aa52-466908d45d16@github.com>

> After finding a hash match, getEntryPos needs to compare the lookup name up to the encoded entry name in the CEN. This comparison is done by decoding the entry name into a String. The names can then be compared using the String API. This decoding step adds a significat cost to this method.
> 
> This PR suggest to update the string comparison such that in the common case where  both the lookup name and the entry name are encoded in ASCII-compatible UTF-8,  decoding can be avoided and the byte arrays can instead be compared direcly. 
> 
> ZipCoder is updated with a new method to compare a string with an encoded byte array range.  The default implementation decodes to string (like the current code), while the UTF-8 implementation uses JavaLangAccess.getBytesNoRepl to get the  bytes. Both methods thes uses Arrays.mismatch for comparison with or without matching trailing slashes. 
> 
> Additionally, this PR suggest to make the following updates to getEntryPos:
> 
> - The try/catch for IAE is redundant and can be safely removed. (initCEN already checks this and will throws IAE for invalid UTF-8). This seems to give a 3-4% speedup on micros)
> - A new test InvalidBytesInEntryNameOrComment is a added to verify that initCEN does in fact reject invalid UTF-8 in CEN file names and comments. (I found no existing test coverage for this)
> - The recursion when looking for "name/" matches is replaced with iteration. We keep track of any "name/" match and return it at the end of the search. (I feel this is easier to follow and it also gives a ~30% speedup for addSlash lookups with no regression on regular lookups)
> 
> (My though is that including these additional updates in this PR might reduce reviewer overhead given that it touches the exact same code. I might be wrong on this, please advise :)
> 
> I'm seeing a ~17% saving on the micro ZipFileGetEntry.getEntryHit (modified to use xalan.jar):
> 
> Baseline:
> 
> Benchmark                             (size)  Mode  Cnt    Score   Error  Units
> ZipFileGetEntry.getEntryHit              512  avgt   15   74.941 ? 1.004  ns/op
> ZipFileGetEntry.getEntryHit             1024  avgt   15   84.943 ? 1.320  ns/op
> ZipFileGetEntry.getEntryHitUncached      512  avgt   15  120.371 ? 2.386  ns/op
> ZipFileGetEntry.getEntryHitUncached     1024  avgt   15  126.128 ? 1.075  ns/op
> ZipFileGetEntry.getEntryMiss             512  avgt   15   23.818 ? 0.838  ns/op
> ZipFileGetEntry.getEntryMiss            1024  avgt   15   29.762 ? 5.998  ns/op
> ZipFileGetEntry.getEntryMissUncached     512  avgt   15   59.405 ? 0.545  ns/op
> ZipFileGetEntry.getEntryMissUncached    1024  avgt   15   71.840 ? 2.455  ns/op
> ZipFileGetEntry.getEntrySlash            512  avgt   15  135.621 ? 4.341  ns/op
> ZipFileGetEntry.getEntrySlash           1024  avgt   15  134.190 ? 2.141  ns/op
> 
> 
> 
> PR:
> 
> 
> Benchmark                             (size)  Mode  Cnt    Score   Error  Units
> ZipFileGetEntry.getEntryHit              512  avgt   15   62.267 ? 1.329  ns/op
> ZipFileGetEntry.getEntryHit             1024  avgt   15   72.916 ? 2.428  ns/op
> ZipFileGetEntry.getEntryHitUncached      512  avgt   15  101.630 ? 1.154  ns/op
> ZipFileGetEntry.getEntryHitUncached     1024  avgt   15  113.161 ? 0.502  ns/op
> ZipFileGetEntry.getEntryMiss             512  avgt   15   23.003 ? 1.191  ns/op
> ZipFileGetEntry.getEntryMiss            1024  avgt   15   23.236 ? 1.114  ns/op
> ZipFileGetEntry.getEntryMissUncached     512  avgt   15   56.781 ? 1.505  ns/op
> ZipFileGetEntry.getEntryMissUncached    1024  avgt   15   67.767 ? 1.963  ns/op
> ZipFileGetEntry.getEntrySlash            512  avgt   15   73.745 ? 2.717  ns/op
> ZipFileGetEntry.getEntrySlash           1024  avgt   15   75.784 ? 1.051  ns/op
> 
> 
> To assess the impact on startup/warmup, I made a main method class which measures the total time of calling ZipFile.getEntry for all entries in the 109 JAR file dependenies of spring-petclinic. The shows a nice improvement (time in micros):
> 
> 
> Percentile Baseline Patch
> 50?%          23155 21149
> 75?%          23598 21454
> 90?%          23989 21691
> 95?%          24238 21973
> 99?%          25270 22446
> STDEV           792   549
> Count           500   500

Eirik Bjorsnos has updated the pull request incrementally with one additional commit since the last revision:

  Fix incorrect offset for the CEN "length of extra field". Fixed spelling of "invalid".

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12290/files
  - new: https://git.openjdk.org/jdk/pull/12290/files/d0c12325..2c5e7c2c

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

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

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

From duke at openjdk.org  Mon Feb  6 16:14:17 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Mon, 6 Feb 2023 16:14:17 GMT
Subject: RFR: 8301873: Avoid string decoding in ZipFile.Source.getEntryPos
 [v2]
In-Reply-To: <4y6TArTKErM-B-nDJCqh2482tTMiyCak05SI9wAqCfM=.3651c522-f00a-4e72-b757-18df5a0a6ae1@github.com>
References: <FkmdspiHVjkAKFqm5kUgwaf55YH5cBbczS_3krqsdFs=.05eca901-f55f-47d9-b1bc-0cf2f5b87536@github.com>
 <_-_GFWJh2QwMpBbASlE3co1kr__pKBxahIU_EoHsix8=.05d0cd8a-b5de-456f-a740-75f2214870d3@github.com>
 <4y6TArTKErM-B-nDJCqh2482tTMiyCak05SI9wAqCfM=.3651c522-f00a-4e72-b757-18df5a0a6ae1@github.com>
Message-ID: <uqtMRxTKCzZXANG-dvJ8aY_7gw2bcf3UbMdBpbUgFio=.f2d1e7fe-3145-4ea6-b5e0-db8aa45ecb92@github.com>

On Mon, 6 Feb 2023 15:56:09 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> Eirik Bjorsnos has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Spelling fix in test data for non-ascii latin1 string
>
> test/jdk/java/util/zip/ZipFile/InvalidBytesInEntryNameOrComment.java line 153:
> 
>> 151:         // Need to skip past the length of the name and extra fields
>> 152:         int nlen = buffer.getShort(off + NLEN);
>> 153:         int elen = buffer.getShort(off + NLEN);
> 
> Is this supposed to say `ELEN`?

Indeed, good catch! Must have lucked out on the comment be longer than the name :-)

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

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

From turbanoff at gmail.com  Mon Feb  6 16:41:53 2023
From: turbanoff at gmail.com (Andrey Turbanov)
Date: Mon, 6 Feb 2023 19:41:53 +0300
Subject: java.util.Date.parse(String) doesn't declare thrown
 IllegalArgumentException
Message-ID: <CAF+DQ5eOvpJPwe4wBWjhLVbidhCEgpDQo317==y5E493xKROnw@mail.gmail.com>

Hello.
I've noticed that method 'long java.util.Date.parse(String)' doesn't
have a reference to IllegalArgumentException in its javadoc.
https://docs.oracle.com/javase/7/docs/api/java/util/Date.html#parse(java.lang.String)
But this exception is thrown in implementation.

I know that this method is deprecated, but it still is used within JDK
code itself.
Is it intentional that exception is not documented in this method?

Andrey Turbanov

From darcy at openjdk.org  Mon Feb  6 16:55:02 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Mon, 6 Feb 2023 16:55:02 GMT
Subject: RFR: JDK-8301396: Port fdlibm expm1 to Java [v2]
In-Reply-To: <3uEwLb5RgU3fDXlaNIPtpRDc80YcGxOjHckTVCeoy98=.a2ef426d-4d1a-4a29-a0d7-338c952f9723@github.com>
References: <U3Jo6dH5rPBRmSVceetCxwisBbTPlaHshGCP2zL9kD0=.1d76ebf0-e729-4066-b9b6-46e06b350eb3@github.com>
 <Xwful8ptiuz7_NWCqmth5VAGSRqYpHnI9ZfRdntxnog=.0276afad-1dc5-4c1b-8b37-85e093c813f3@github.com>
 <3uEwLb5RgU3fDXlaNIPtpRDc80YcGxOjHckTVCeoy98=.a2ef426d-4d1a-4a29-a0d7-338c952f9723@github.com>
Message-ID: <IjC5sx3iwODuMcAap17duJtHxWCl-RMdgxPR21NKf7A=.2134bebf-d36d-46ce-81a4-168526e4ab79@github.com>

On Mon, 6 Feb 2023 08:19:36 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> @jddarcy Are you planning a GC of unused functions in StrictMath.c too? (for this PR I'm wondering about Java_java_lang_StrictMath_expm1).

Yes, once the port is done, I'll remove all the remaining FDLIBM C files. There are dependencies between the different C files, sinh calls expm1, etc., so to avoid needed to untangle all of those, I was going to do the removal in one step at the end.

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

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

From roger.riggs at oracle.com  Mon Feb  6 16:55:25 2023
From: roger.riggs at oracle.com (Roger Riggs)
Date: Mon, 6 Feb 2023 11:55:25 -0500
Subject: java.util.Date.parse(String) doesn't declare thrown
 IllegalArgumentException
In-Reply-To: <CAF+DQ5eOvpJPwe4wBWjhLVbidhCEgpDQo317==y5E493xKROnw@mail.gmail.com>
References: <CAF+DQ5eOvpJPwe4wBWjhLVbidhCEgpDQo317==y5E493xKROnw@mail.gmail.com>
Message-ID: <6e15390b-e4ed-91a7-3dc7-398ecbd12fe6@oracle.com>

Hi Andrey,

Instead, perhaps replace (carefully) the remaining uses in the JDK.
Developers should be using the correct APIs and not reading deprecated 
javadoc.

Regards, Roger

On 2/6/23 11:41 AM, Andrey Turbanov wrote:
> Hello.
> I've noticed that method 'long java.util.Date.parse(String)' doesn't
> have a reference to IllegalArgumentException in its javadoc.
> https://docs.oracle.com/javase/7/docs/api/java/util/Date.html#parse(java.lang.String)
> But this exception is thrown in implementation.
>
> I know that this method is deprecated, but it still is used within JDK
> code itself.
> Is it intentional that exception is not documented in this method?
>
> Andrey Turbanov


From duke at openjdk.org  Mon Feb  6 17:19:05 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Mon, 6 Feb 2023 17:19:05 GMT
Subject: Integrated: 8300259: Add test coverage for processing of pending block
 files in signed JARs
In-Reply-To: <cyoAdel_KXj3W8Giw6FWoblQM3zXAJBoks4AG1jqZgo=.3b04f7ca-d8eb-40da-812f-c371210b1f8b@github.com>
References: <cyoAdel_KXj3W8Giw6FWoblQM3zXAJBoks4AG1jqZgo=.3b04f7ca-d8eb-40da-812f-c371210b1f8b@github.com>
Message-ID: <BGmZCs657zYJ2ZPpoD6SHVvX27pd51FEapN6osIMl4c=.e0ab71b0-4ab3-4b5e-bc3b-fdd298ffdee6@github.com>

On Mon, 16 Jan 2023 11:44:36 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

> This PR adds test coverage for pending block files in signed JAR files
> 
> A signed JAR has pending block files if the block file [RSA, DSA, EC] comes before the corresponding signature file [SF] in the JAR. 
> 
> JarVerifier.processEntry supports processing of such pending block files, but this code path does not seem to be exercised by current test.
> 
> The new test PendingBlocksJar checks that signed JARs  with pending blocks are processed correctly, both for the valid and invalid cases.

This pull request has now been integrated.

Changeset: c129ce46
Author:    Eirik Bjorsnos <eirbjo at gmail.com>
Committer: Weijun Wang <weijun at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/c129ce4660e6c9b5365c8bf89fb916e2a7c28e98
Stats:     173 lines in 1 file changed: 173 ins; 0 del; 0 mod

8300259: Add test coverage for processing of pending block files in signed JARs

Reviewed-by: weijun

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

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

From duke at openjdk.org  Mon Feb  6 17:35:18 2023
From: duke at openjdk.org (Scott Gibbons)
Date: Mon, 6 Feb 2023 17:35:18 GMT
Subject: RFR: JDK-8300808: Accelerate Base64 on x86 for AVX2 [v9]
In-Reply-To: <9zN3bjyMEikXYOlpjTy9_QPc-9usYiBJMUFdb-TaVrQ=.e8f65ce9-ac0f-4f8d-9c6b-b39ae1c26cd2@github.com>
References: <9zN3bjyMEikXYOlpjTy9_QPc-9usYiBJMUFdb-TaVrQ=.e8f65ce9-ac0f-4f8d-9c6b-b39ae1c26cd2@github.com>
Message-ID: <B1BHSjPB8V14-0PJIFcPXg-w8PgF1ne3KAAALykknyo=.2ea1580e-5efb-4571-9a64-5ed19e426746@github.com>

> Added code for Base64 acceleration (encode and decode) which will accelerate ~4x for AVX2 platforms.
> 
> Encode performance:
> **Old:**
> 
> Benchmark                      (maxNumBytes)   Mode  Cnt     Score   Error   Units
> Base64Encode.testBase64Encode           1024  thrpt    3  4309.439 ? 2.632  ops/ms
> 
> 
> **New:**
> 
> Benchmark                      (maxNumBytes)   Mode  Cnt      Score     Error   Units
> Base64Encode.testBase64Encode           1024  thrpt    3  24211.397 ? 102.026  ops/ms
> 
> 
> Decode performance:
> **Old:**
> 
> Benchmark                      (errorIndex)  (lineSize)  (maxNumBytes)   Mode  Cnt     Score    Error   Units
> Base64Decode.testBase64Decode           144           4           1024  thrpt    3  3961.768 ? 93.409  ops/ms
> 
> **New:**
> Benchmark                      (errorIndex)  (lineSize)  (maxNumBytes)   Mode  Cnt      Score    Error   Units
> Base64Decode.testBase64Decode           144           4           1024  thrpt    3  14738.051 ? 24.383  ops/ms

Scott Gibbons has updated the pull request incrementally with one additional commit since the last revision:

  Removal of a redundant cmp in inner loop.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12126/files
  - new: https://git.openjdk.org/jdk/pull/12126/files/80fbf4ef..a8ecc15a

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

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

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

From psandoz at openjdk.org  Mon Feb  6 17:42:52 2023
From: psandoz at openjdk.org (Paul Sandoz)
Date: Mon, 6 Feb 2023 17:42:52 GMT
Subject: RFR: 8293198: [vectorapi] Improve the implementation of
 VectorMask.indexInRange() [v2]
In-Reply-To: <0dNCRVASsdME6qS79u5z7c6mikJs1jfucfo54lo71ik=.d8c2dc6e-bc60-499f-899c-880a2219b052@github.com>
References: <fN58bi3n01tqWpG0-jjUPZQe8hmls2GQ5X3NL2o1RPg=.80e7965d-50af-4fac-bd7c-0a2b99cffe7e@github.com>
 <0dNCRVASsdME6qS79u5z7c6mikJs1jfucfo54lo71ik=.d8c2dc6e-bc60-499f-899c-880a2219b052@github.com>
Message-ID: <7BM1vdj6ShoztqsIgXgTjzVMTiZtdSCL8JqxwXz44Kw=.0f5a61df-4838-4043-8155-dc3ae45ca99b@github.com>

On Fri, 3 Feb 2023 07:13:10 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

>> The Vector API `"indexInRange(int offset, int limit)"` is used
>> to compute a vector mask whose lanes are set to true if the
>> index of the lane is inside the range specified by the `"offset"`
>> and `"limit"` arguments, otherwise the lanes are set to false.
>> 
>> There are two special cases for this API:
>>  1) If `"offset >= 0 && offset >= limit"`, all the lanes of the
>> generated mask are false.
>>  2) If` "offset >= 0 && limit - offset >= vlength"`, all the
>> lanes of the generated mask are true. Note that `"vlength"` is
>> the number of vector lanes.
>> 
>> For such special cases, we can simply use `"maskAll(false|true)"`
>> to implement the API. Otherwise, the original comparison with
>> `"iota" `vector is needed. And for further optimization, we have
>> optimal instruction supported by SVE (i.e. whilelo [1]), which
>> can implement the API directly if the `"offset >= 0"`.
>> 
>> As a summary, to optimize the API, we can use the if-else branches
>> to handle the specific cases in java level and intrinsify the
>> remaining case by C2 compiler:
>> 
>> 
>>   public VectorMask<E> indexInRange(int offset, int limit) {
>>       if (offset < 0) {
>>           return this.and(indexInRange0Helper(offset, limit));
>>       } else if (offset >= limit) {
>>           return this.and(vectorSpecies().maskAll(false));
>>       } else if (limit - offset >= length()) {
>>           return this.and(vectorSpecies().maskAll(true));
>>       }
>>       return this.and(indexInRange0(offset, limit));
>>  }
>> 
>> 
>> The last part (i.e. `"indexInRange0"`) in the above implementation
>> is expected to be intrinsified by C2 compiler if the necessary IRs
>> are supported. Otherwise, it will fall back to the original API
>> implementation (i.e. `"indexInRange0Helper"`). Regarding to the
>> intrinsifaction, the compiler will generate `"VectorMaskGen"` IR
>> with "limit - offset" as the input if the current platform supports
>> it. Otherwise, it generates `"VectorLoadConst + VectorMaskCmp"` based
>> on `"iota < limit - offset"`.
>> 
>> For the following java code which uses `"indexInRange"`:
>> 
>> 
>> static final VectorSpecies<Double> SPECIES =
>>                                    DoubleVector.SPECIES_PREFERRED;
>> static final int LENGTH = 1027;
>> 
>> public static double[] da;
>> public static double[] db;
>> public static double[] dc;
>> 
>> private static void func() {
>>     for (int i = 0; i < LENGTH; i += SPECIES.length()) {
>>         var m = SPECIES.indexInRange(i, LENGTH);
>>         var av = DoubleVector.fromArray(SPECIES, da, i, m);
>>         av.lanewise(VectorOperators.NEG).intoArray(dc, i, m);
>>     }
>> }
>> 
>> 
>> The core code generated with SVE 256-bit vector size is:
>> 
>> 
>>   ptrue   p2.d                  ; maskAll(true)
>>   ...
>> LOOP:
>>   ...
>>   sub     w11, w13, w14         ; limit - offset
>>   cmp     w14, w13
>>   b.cs    LABEL-1               ; if (offset >= limit) => uncommon-trap
>>   cmp     w11, #0x4
>>   b.lt    LABEL-2               ; if (limit - offset < vlength)
>>   mov     p1.b, p2.b
>> LABEL-3:
>>   ld1d    {z16.d}, p1/z, [x10]  ; load vector masked
>>   ...
>>   cmp     w14, w29
>>   b.cc    LOOP
>>   ...
>> LABEL-2:
>>   whilelo p1.d, x16, x10        ; VectorMaskGen
>>   ...
>>   b       LABEL-3
>>   ...
>> LABEL-1:
>>   uncommon-trap
>> 
>> 
>> Please note that if the array size `LENGTH` is aligned with
>> the vector size 256 (i.e. `LENGTH = 1024`), the branch "LABEL-2"
>> will be optimized out by compiler and it becomes another
>> uncommon-trap.
>> 
>> For NEON, the main CFG is the same with above. But the compiler
>> intrinsification is different. Here is the code:
>> 
>> 
>>   sub     x10, x10, x12          ; limit - offset
>>   scvtf   d16, x10
>>   dup     v16.2d, v16.d[0]       ; replicateD
>> 
>>   mov     x8, #0xd8d0
>>   movk    x8, #0x84cb, lsl #16
>>   movk    x8, #0xffff, lsl #32
>>   ldr     q17, [x8], #0          ; load the "iota" const vector
>>   fcmgt   v18.2d, v16.2d, v17.2d ; mask = iota < limit - offset
>> 
>> 
>> Here is the performance data of the new added benchmark on an ARM
>> SVE 256-bit platform:
>> 
>> 
>> Benchmark                               (size)  Before    After   Units
>> IndexInRangeBenchmark.byteIndexInRange   1024 11203.697 41404.431 ops/ms
>> IndexInRangeBenchmark.byteIndexInRange   1027  2365.920  8747.004 ops/ms
>> IndexInRangeBenchmark.doubleIndexInRange 1024  1227.505  6092.194 ops/ms
>> IndexInRangeBenchmark.doubleIndexInRange 1027   351.215  1156.683 ops/ms
>> IndexInRangeBenchmark.floatIndexInRange  1024  1468.876 11032.580 ops/ms
>> IndexInRangeBenchmark.floatIndexInRange  1027   699.645  2439.671 ops/ms
>> IndexInRangeBenchmark.intIndexInRange    1024  2842.187 11903.544 ops/ms
>> IndexInRangeBenchmark.intIndexInRange    1027   689.866  2547.424 ops/ms
>> IndexInRangeBenchmark.longIndexInRange   1024  1394.135  5902.973 ops/ms
>> IndexInRangeBenchmark.longIndexInRange   1027   355.621  1189.458 ops/ms
>> IndexInRangeBenchmark.shortIndexInRange  1024  5521.468 21578.340 ops/ms
>> IndexInRangeBenchmark.shortIndexInRange  1027  1264.816  4640.504 ops/ms
>> 
>> 
>> And the performance data with ARM NEON:
>> 
>> 
>> Benchmark                               (size)  Before    After   Units
>> IndexInRangeBenchmark.byteIndexInRange   1024  4026.548 15562.880 ops/ms
>> IndexInRangeBenchmark.byteIndexInRange   1027   305.314   576.559 ops/ms
>> IndexInRangeBenchmark.doubleIndexInRange 1024   289.224  2244.080 ops/ms
>> IndexInRangeBenchmark.doubleIndexInRange 1027    39.740    76.499 ops/ms
>> IndexInRangeBenchmark.floatIndexInRange  1024   675.264  4457.470 ops/ms
>> IndexInRangeBenchmark.floatIndexInRange  1027    79.918   144.952 ops/ms
>> IndexInRangeBenchmark.intIndexInRange    1024   740.139  4014.583 ops/ms
>> IndexInRangeBenchmark.intIndexInRange    1027    78.608   147.903 ops/ms
>> IndexInRangeBenchmark.longIndexInRange   1024   400.683  2209.551 ops/ms
>> IndexInRangeBenchmark.longIndexInRange   1027    41.146    69.599 ops/ms
>> IndexInRangeBenchmark.shortIndexInRange  1024  1821.736  8153.546 ops/ms
>> IndexInRangeBenchmark.shortIndexInRange  1027   158.810   243.205 ops/ms
>> 
>> 
>> The performance improves about `3.5x ~ 7.5x` on the vector size aligned
>> (1024 size) benchmarks both with NEON and SVE. And it improves about
>> `3.5x/1.8x` on the vector size not aligned (1027 size) benchmarks with
>> SVE/NEON respectively. We can also observe the similar improvement on
>> the x86 platforms.
>> 
>> [1] https://developer.arm.com/documentation/ddi0596/2020-12/SVE-Instructions/WHILELO--While-incrementing-unsigned-scalar-lower-than-scalar-
>
> Xiaohong Gong has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add smaller array size for benchmark tests

I think it would be useful to adjust the naming and comments of some methods to make it clearer the method parameter constraints.

`indexInRange0Helper` is now called if the index is partially or totally out of range at the lower or upper ends and `indexInRange0` is called if partially or totally out of range at the upper end.
e.g. a more literal naming could be:
`AbstractMask::indexInRange0Helper` -> `AbstractMask::indexPartiallyInRangeHelper`
`VectorSupport::indexInRange` -> VectorSupport::indexPartiallyInUpperRange`
?

IIUC the performance numbers show that when the array is not a multiple of the vector size there is still quite an impact overall to calling `VectorSupport::indexInRange` for the last loop iteration. I am guessing the overall loop shape is different which impacts other optimizations?

To do this more optimally likely requires a loop transformation where the last loop iteration is peeled off, but that's a harder transformation in one of the more complicated areas of C2 (although it already supports pre/post loop, so maybe its possible to leverage that?).

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

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

From darcy at openjdk.org  Mon Feb  6 17:55:48 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Mon, 6 Feb 2023 17:55:48 GMT
Subject: RFR: JDK-8301833: Add manual tests for FDLIBM porting
In-Reply-To: <JSOpjfwMLEyZJbU6i9F7ECuuaxitsd8UQtaYKmZnNAU=.094f3b9d-e88d-4195-8015-4490a0dc632c@github.com>
References: <wgghXoOC-eICroAklhQSO8UYEBvYHF_QHZ4C_1wnW0Q=.61574f1b-9c40-4c34-b234-502b95a99c8f@github.com>
 <JSOpjfwMLEyZJbU6i9F7ECuuaxitsd8UQtaYKmZnNAU=.094f3b9d-e88d-4195-8015-4490a0dc632c@github.com>
Message-ID: <RR8Dy2nmLla5Q8jPCEW3ZeMNo3mbzNNvgZwlH7LbfiU=.4c1a7d2c-89e5-441b-b10f-fd3f570f5854@github.com>

On Mon, 6 Feb 2023 09:18:35 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> Manual tests are the tests of last resort :-) This test may be useful for the current transliteration work but it's not clear how this manual test would be run by someone tasked with running the manual tests. Right now, it looks like it's more of a long running stress test but I think the expectation is that someone running this test needs to do a special build or somehow compare results with an older JDK release. Have you explored alternatives to adding a manual test? Long running HotSpot stress tests run in higher tiers. For comparison, I'm wondering if samples could be captured in a golden file for the test to use.
> 
> If we are adding a manual test here then I think it will need good instructions. @bwhuang-us has done work in recent times on making sure that the manual tests are in test groups with instructions.

To add some quick background: the FDLIBM porting effort is now doing two ports per method:
* A transliteration port that is as close to the original FDLIBM C as possible
* A (more) idiomatic port closed to regular Java coding
In the future, there may be further changes to the idiomatic port to enhance performance or clarity _while returning the same results_, etc.

These exhaustive tests are helpful now to provide another layer of checking to the transliteration port (by validating it against say, a JDK 20 build) and also helpful in the future to validate any implementation optimization to the idiomatic port when run against the transliteration port.

The tests are long-running (one of the order of at least a minute or two per method under test) and in my estimation don't provide enough utility for their cost to be run all the time. However, they have much higher utility to help validate this initial port and for future refactorings. Therefore, I think these tests should be included in the repository, but not run all the time, which led me to declare them as a manual jtreg test.

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

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

From eirbjo at gmail.com  Mon Feb  6 18:19:06 2023
From: eirbjo at gmail.com (=?UTF-8?B?RWlyaWsgQmrDuHJzbsO4cw==?=)
Date: Mon, 6 Feb 2023 19:19:06 +0100
Subject: Update TestTooManyEntries to run non-manual
In-Reply-To: <809C4EF8-2020-448D-B8EF-0ADD0C9F26A8@oracle.com>
References: <CA+pBWhu6c7kGy--U2Q9D9oYNwoc0OCLmrVYcuSKpS6CYey8R8Q@mail.gmail.com>
 <906bf503-8553-cf40-8dd0-fa1dc829fdef@oracle.com>
 <CA+pBWhupO=opRwD-u4_TFNPn3T7PO19PCQdYgbnvB+9AGFR-2Q@mail.gmail.com>
 <809C4EF8-2020-448D-B8EF-0ADD0C9F26A8@oracle.com>
Message-ID: <CA+pBWht_LxGOEe7PvvrbS_p0xC4tQq-8_Q1fTObND_nrzaOU4A@mail.gmail.com>

On Sat, Jan 28, 2023 at 5:29 PM Lance Andersen <lance.andersen at oracle.com>
wrote:

> I think it is fine to move the validation immediately following findEND()
> though I am not sure there is a big win overall.
>
> I also would prefer to see the test based off of an actual ZIP(or at least
> have the current/modified version of the test).
>

Hi,

I  updated the PR to "inflate" the CEN such that its size on disk matches
the size stated in the END record. As suggested by Alan, this is done using
sparse files, the actual disk usage is kept low.

While a ZIP with a zero-padded CEN is still not technically valid, the END
record is now at least valid with respect to its offset. This allows us to
test the validation of the various END record validation scenarios
independently and without updating the ZipFile validation order to
facilitate the testing.

There are now three test methods in the test, one for each of the possible
ZipExceptions thrown during END record validation.

Cheers,
Eirik.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20230206/5f085a15/attachment.htm>

From duke at openjdk.org  Mon Feb  6 19:29:08 2023
From: duke at openjdk.org (Scott Gibbons)
Date: Mon, 6 Feb 2023 19:29:08 GMT
Subject: RFR: JDK-8300808: Accelerate Base64 on x86 for AVX2 [v10]
In-Reply-To: <9zN3bjyMEikXYOlpjTy9_QPc-9usYiBJMUFdb-TaVrQ=.e8f65ce9-ac0f-4f8d-9c6b-b39ae1c26cd2@github.com>
References: <9zN3bjyMEikXYOlpjTy9_QPc-9usYiBJMUFdb-TaVrQ=.e8f65ce9-ac0f-4f8d-9c6b-b39ae1c26cd2@github.com>
Message-ID: <emma0ZV9BnvAwZXnMHaQutQ-paPyGSAqNvWFzwBBF0I=.6069221a-a552-4040-8d49-6957ae6cdac2@github.com>

> Added code for Base64 acceleration (encode and decode) which will accelerate ~4x for AVX2 platforms.
> 
> Encode performance:
> **Old:**
> 
> Benchmark                      (maxNumBytes)   Mode  Cnt     Score   Error   Units
> Base64Encode.testBase64Encode           1024  thrpt    3  4309.439 ? 2.632  ops/ms
> 
> 
> **New:**
> 
> Benchmark                      (maxNumBytes)   Mode  Cnt      Score     Error   Units
> Base64Encode.testBase64Encode           1024  thrpt    3  24211.397 ? 102.026  ops/ms
> 
> 
> Decode performance:
> **Old:**
> 
> Benchmark                      (errorIndex)  (lineSize)  (maxNumBytes)   Mode  Cnt     Score    Error   Units
> Base64Decode.testBase64Decode           144           4           1024  thrpt    3  3961.768 ? 93.409  ops/ms
> 
> **New:**
> Benchmark                      (errorIndex)  (lineSize)  (maxNumBytes)   Mode  Cnt      Score    Error   Units
> Base64Decode.testBase64Decode           144           4           1024  thrpt    3  14738.051 ? 24.383  ops/ms

Scott Gibbons has updated the pull request incrementally with one additional commit since the last revision:

  Remove redundant cmp from inner loop of encode

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12126/files
  - new: https://git.openjdk.org/jdk/pull/12126/files/a8ecc15a..cb271c00

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

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

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

From igraves at openjdk.org  Mon Feb  6 20:12:09 2023
From: igraves at openjdk.org (Ian Graves)
Date: Mon, 6 Feb 2023 20:12:09 GMT
Subject: RFR: 8293667: Align jlink's --compress option with jmod's
 --compress option [v5]
In-Reply-To: <JWevwHuR2vF3k-JRxmTAxfNN6g-EBkgG2N9DHn4fkGY=.f9768dfd-cab4-49a9-83b9-d77a1572e917@github.com>
References: <JWevwHuR2vF3k-JRxmTAxfNN6g-EBkgG2N9DHn4fkGY=.f9768dfd-cab4-49a9-83b9-d77a1572e917@github.com>
Message-ID: <A7oOY2Fsic1IQ-nBaDAmShi3CEV_5ZLfJ1BxOWqqhi4=.11e8c2c2-412d-4ee8-afbd-cdd05bc2a6a3@github.com>

> This is an approach to adding a flag to jlink that will allow --compress to take the same types of arguments as jmod, thus bringing the two into alignment. This likely requires a CSR and a discussion on whether we should deprecate or simply remove the original numeric compression arguments.

Ian Graves has updated the pull request incrementally with one additional commit since the last revision:

  Adding plugin type to force compact strings vs zip ordering

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11617/files
  - new: https://git.openjdk.org/jdk/pull/11617/files/41e52039..06f4b3c3

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

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

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

From rriggs at openjdk.org  Mon Feb  6 20:46:35 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 6 Feb 2023 20:46:35 GMT
Subject: [jdk20] RFR: 8301864: ObjectInputFilter example incorrectly calls
 rejectUndecideClass
Message-ID: <i0ZaWMa10jaiLQL21r8epcqXwsnnmMUhF-ilhTWERlQ=.2a911a8f-4606-403f-8eba-13146a829304@github.com>

The example code in ObjectInputFilter for the FilterInThread filter factory does not do what is intended and is poorly described. Clarifies that the JVM-wide filter and the thread local filter are merged and will reject classes that are otherwise not accepted or rejected. If a stream specific filter is set and does not accept or reject a class, the combined filter is applied.

This is a doc-only change.

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

Commit messages:
 - 8301864: ObjectInputFilter example incorrectly calls rejectUndecidedClass

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

PR: https://git.openjdk.org/jdk20/pull/121

From darcy at openjdk.org  Mon Feb  6 20:51:16 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Mon, 6 Feb 2023 20:51:16 GMT
Subject: RFR: JDK-8301444: Port fdlibm hyperbolic transcendental functions
 to Java [v2]
In-Reply-To: <_s8xnppoDTnAajAjlmfB-dX5DBdawUcSSPaGWGLzFBk=.cdbf468a-ace7-45e5-a25a-833c760b776c@github.com>
References: <_s8xnppoDTnAajAjlmfB-dX5DBdawUcSSPaGWGLzFBk=.cdbf468a-ace7-45e5-a25a-833c760b776c@github.com>
Message-ID: <9LiKEhtsmSx-In5IDGtm6ZXi9EnaMB9mAkoTxLKGfo4=.628920ed-88b3-4c6c-900c-178271136079@github.com>

> Initial pass of porting FDLIBM sinh/cosh/tanh to Java. I do intend to refactor the regression tests a bit to reduce duplication, but the actual ports should be ready for review.
> 
> Diff'ing the ports as before, original vs transliteration port:
> 
> 
> $ diff -w Hyperbolic.c Hyperbolic.translit.java
> 1c1
> < /* __ieee754_sinh(x)
> ---
>>     /**
> 17a18,19
>>     static class Sinh {
>>         private static final double one = 1.0, shuge = 1.0e307;
> 19,33c21
> < #include "fdlibm.h"
> < 
> < #ifdef __STDC__
> < static const double one = 1.0, shuge = 1.0e307;
> < #else
> < static double one = 1.0, shuge = 1.0e307;
> < #endif
> < 
> < #ifdef __STDC__
> <         double __ieee754_sinh(double x)
> < #else
> <         double __ieee754_sinh(x)
> <         double x;
> < #endif
> < {
> ---
>>         private static double compute(double x) {
> 36c24
> <         unsigned lx;
> ---
>>             /* unsigned */ int lx;
> 51c39
> <             t = expm1(fabs(x));
> ---
>>                 t = FdlibmTranslit.expm1(Math.abs(x));
> 57c45
> <         if (ix < 0x40862E42)  return h*__ieee754_exp(fabs(x));
> ---
>>             if (ix < 0x40862E42)  return h*StrictMath.exp(Math.abs(x)); // TODO switch to translit
> 60,62c48,52
> <         lx = *( (((*(unsigned*)&one)>>29)) + (unsigned*)&x);
> <         if (ix<0x408633CE || ((ix==0x408633ce)&&(lx<=(unsigned)0x8fb9f87d))) {
> <             w = __ieee754_exp(0.5*fabs(x));
> ---
>>             // lx = *( (((*(unsigned*)&one)>>29)) + (unsigned*)&x);
>>             // lx =  (((*(unsigned*)&one)>>29)) + (unsigned*)&x ;
>>             lx = __LO(x);
>>             if (ix<0x408633CE || ((ix==0x408633ce)&&(Long.compareUnsigned(lx, 0x8fb9f87d) <= 0 ))) {
>>                 w = StrictMath.exp(0.5*Math.abs(x)); // TODO switch to translit
> 70c60,62
> < /* __ieee754_cosh(x)
> ---
>>     }
>> 
>>     /**
> 90,105c82,84
> < 
> < #include "fdlibm.h"
> < 
> < #ifdef __STDC__
> < static const double one = 1.0, half=0.5, huge = 1.0e300;
> < #else
> < static double one = 1.0, half=0.5, huge = 1.0e300;
> < #endif
> < 
> < #ifdef __STDC__
> <         double __ieee754_cosh(double x)
> < #else
> <         double __ieee754_cosh(x)
> <         double x;
> < #endif
> < {
> ---
>>     static class Cosh {
>>         private static final double one = 1.0, half=0.5, huge = 1.0e300;
>>         private static double compute(double x) {
> 108c87
> <         unsigned lx;
> ---
>>             /*unsigned*/ int lx;
> 119c98
> <             t = expm1(fabs(x));
> ---
>>                 t = expm1(Math.abs(x));
> 127c106
> <                 t = __ieee754_exp(fabs(x));
> ---
>>                 t = StrictMath.exp(Math.abs(x)); // TODO switch to translit
> 132c111
> <         if (ix < 0x40862E42)  return half*__ieee754_exp(fabs(x));
> ---
>>             if (ix < 0x40862E42)  return half*StrictMath.exp(Math.abs(x)); // TODO switch to translit
> 135c114
> <         lx = *( (((*(unsigned*)&one)>>29)) + (unsigned*)&x);
> ---
>>             lx = __LO(x);
> 137,138c116,117
> <               ((ix==0x408633ce)&&(lx<=(unsigned)0x8fb9f87d))) {
> <             w = __ieee754_exp(half*fabs(x));
> ---
>>                 ((ix==0x408633ce)&&(Integer.compareUnsigned(lx, 0x8fb9f87d) <= 0))) {
>>                 w = StrictMath.exp(half*Math.abs(x)); // TODO switch to translit
> 146c125,127
> < /* Tanh(x)
> ---
>>     }
>> 
>>     /**
> 169,184c150,152
> < 
> < #include "fdlibm.h"
> < 
> < #ifdef __STDC__
> < static const double one=1.0, two=2.0, tiny = 1.0e-300;
> < #else
> < static double one=1.0, two=2.0, tiny = 1.0e-300;
> < #endif
> < 
> < #ifdef __STDC__
> <         double tanh(double x)
> < #else
> <         double tanh(x)
> <         double x;
> < #endif
> < {
> ---
>>     static class Tanh {
>>         private static final double one=1.0, two=2.0, tiny = 1.0e-300;
>>         static double compute(double x) {
> 203c171
> <                 t = expm1(two*fabs(x));
> ---
>>                     t = expm1(two*Math.abs(x));
> 206c174
> <                 t = expm1(-two*fabs(x));
> ---
>>                     t = expm1(-two*Math.abs(x));
> 214a183
>>     }
> 
> 
> Note that the original has a in-line version of the "__LO" macro rather than using the macro.
> 
> 
> And transliteration vs more idiomatic:
> 
> 
> $ diff -w Hyperbolic.translit.java Hyperbolic.fdlibm.java 
> 21c21
> <         private static double compute(double x) {
> ---
>>          static double compute(double x) {
> 26c26
> <             /* High word of |x|. */
> ---
>>             // High word of |x|
> 28c28
> <             ix = jx&0x7fffffff;
> ---
>>             ix = jx & 0x7fff_ffff;
> 30,31c30,33
> <             /* x is INF or NaN */
> <             if(ix>=0x7ff00000) return x+x;
> ---
>>             // x is INF or NaN
>>             if ( ix >= 0x7ff0_0000) {
>>                 return x + x;
>>             }
> 34,40c36,48
> <             if (jx<0) h = -h;
> <             /* |x| in [0,22], return sign(x)*0.5*(E+E/(E+1))) */
> <             if (ix < 0x40360000) {          /* |x|<22 */
> <                 if (ix<0x3e300000)          /* |x|<2**-28 */
> <                     if(shuge+x>one) return x;/* sinh(tiny) = tiny with inexact */
> <                 t = FdlibmTranslit.expm1(Math.abs(x));
> <                 if(ix<0x3ff00000) return h*(2.0*t-t*t/(t+one));
> ---
>>             if ( jx < 0) {
>>                 h = -h;
>>             }
>>             // |x| in [0,22], return sign(x)*0.5*(E+E/(E+1)))
>>             if (ix < 0x4036_0000) {          // |x| < 22
>>                 if (ix < 0x3e30_0000)        // |x| < 2**-28
>>                     if (shuge + x > one) {   // sinh(tiny) = tiny with inexact
>>                         return x;
>>                     }
>>                 t = StrictMath.expm1(Math.abs(x));
>>                 if (ix < 0x3ff0_0000) {
>>                     return h*(2.0 * t - t*t/(t + one));
>>                 }
> 44,45c52,55
> <             /* |x| in [22, log(maxdouble)] return 0.5*exp(|x|) */
> <             if (ix < 0x40862E42)  return h*StrictMath.exp(Math.abs(x)); // TODO switch to translit
> ---
>>             // |x| in [22, log(maxdouble)] return 0.5*exp(|x|)
>>             if (ix < 0x4086_2E42) {
>>                 return h*StrictMath.exp(Math.abs(x));
>>             }
> 47,49c57
> <             /* |x| in [log(maxdouble), overflowthresold] */
> <             // lx = *( (((*(unsigned*)&one)>>29)) + (unsigned*)&x);
> <             // lx =  (((*(unsigned*)&one)>>29)) + (unsigned*)&x ;
> ---
>>             // |x| in [log(maxdouble), overflowthresold]
> 51,52c59,62
> <             if (ix<0x408633CE || ((ix==0x408633ce)&&(Long.compareUnsigned(lx, 0x8fb9f87d) <= 0 ))) {
> <                 w = StrictMath.exp(0.5*Math.abs(x)); // TODO switch to translit
> ---
>>             if (ix < 0x4086_33CE ||
>>                 ((ix == 0x4086_33ce) &&
>>                  (Long.compareUnsigned(lx, 0x8fb9_f87d) <= 0 ))) {
>>                 w = StrictMath.exp(0.5 * Math.abs(x));
> 57c67
> <             /* |x| > overflowthresold, sinh(x) overflow */
> ---
>>             // |x| > overflowthresold, sinh(x) overflow
> 84c94
> <         private static double compute(double x) {
> ---
>>         static double compute(double x) {
> 89c99
> <             /* High word of |x|. */
> ---
>>             // High word of |x|
> 91c101
> <             ix &= 0x7fffffff;
> ---
>>             ix &= 0x7fff_ffff;
> 93,94c103,106
> <             /* x is INF or NaN */
> <             if(ix>=0x7ff00000) return x*x;
> ---
>>             // x is INF or NaN
>>             if (ix >= 0x7ff_00000) {
>>                 return x*x;
>>             }
> 96,98c108,110
> <             /* |x| in [0,0.5*ln2], return 1+expm1(|x|)^2/(2*exp(|x|)) */
> <             if(ix<0x3fd62e43) {
> <                 t = expm1(Math.abs(x));
> ---
>>             // |x| in [0,0.5*ln2], return 1+expm1(|x|)^2/(2*exp(|x|))
>>             if (ix < 0x3fd6_2e43) {
>>                 t = StrictMath.expm1(Math.abs(x));
> 100c112,114
> <                 if (ix<0x3c800000) return w;        /* cosh(tiny) = 1 */
> ---
>>                 if (ix < 0x3c80_0000) { // cosh(tiny) = 1
>>                     return w;
>>                 }
> 104,106c118,120
> <             /* |x| in [0.5*ln2,22], return (exp(|x|)+1/exp(|x|)/2; */
> <             if (ix < 0x40360000) {
> <                 t = StrictMath.exp(Math.abs(x)); // TODO switch to translit
> ---
>>             // |x| in [0.5*ln2, 22], return (exp(|x|) + 1/exp(|x|)/2
>>             if (ix < 0x4036_0000) {
>>                 t = StrictMath.exp(Math.abs(x));
> 110,111c124,127
> <             /* |x| in [22, log(maxdouble)] return half*exp(|x|) */
> <             if (ix < 0x40862E42)  return half*StrictMath.exp(Math.abs(x)); // TODO switch to translit
> ---
>>             // |x| in [22, log(maxdouble)] return half*exp(|x|)
>>             if (ix < 0x4086_2E42) {
>>                 return half*StrictMath.exp(Math.abs(x));
>>             }
> 113c129
> <             /* |x| in [log(maxdouble), overflowthresold] */
> ---
>>             // |x| in [log(maxdouble), overflowthresold]
> 115,117c131,134
> <             if (ix<0x408633CE ||
> <                 ((ix==0x408633ce)&&(Integer.compareUnsigned(lx, 0x8fb9f87d) <= 0))) {
> <                 w = StrictMath.exp(half*Math.abs(x)); // TODO switch to translit
> ---
>>             if (ix<0x4086_33CE ||
>>                 ((ix == 0x4086_33ce) &&
>>                  (Integer.compareUnsigned(lx, 0x8fb9_f87d) <= 0))) {
>>                 w = StrictMath.exp(half*Math.abs(x));
> 122c139
> <             /* |x| > overflowthresold, cosh(x) overflow */
> ---
>>             // |x| > overflowthresold, cosh(x) overflow
> 126d142
> < 
> 156c172
> <             /* High word of |x|. */
> ---
>>             // High word of |x|.
> 158c174
> <             ix = jx&0x7fffffff;
> ---
>>             ix = jx & 0x7fff_ffff;
> 160,163c176,182
> <             /* x is INF or NaN */
> <             if(ix>=0x7ff00000) {
> <                 if (jx>=0) return one/x+one;    /* tanh(+-inf)=+-1 */
> <                 else       return one/x-one;    /* tanh(NaN) = NaN */
> ---
>>             // x is INF or NaN
>>             if (ix >= 0x7ff0_0000) {
>>                 if (jx >= 0) {  // tanh(+-inf)=+-1
>>                     return one/x + one;
>>                 } else {        // tanh(NaN) = NaN
>>                     return one/x - one;
>>                 }
> 166,171c185,190
> <             /* |x| < 22 */
> <             if (ix < 0x40360000) {          /* |x|<22 */
> <                 if (ix<0x3c800000)          /* |x|<2**-55 */
> <                     return x*(one+x);       /* tanh(small) = small */
> <                 if (ix>=0x3ff00000) {       /* |x|>=1  */
> <                     t = expm1(two*Math.abs(x));
> ---
>>             // |x| < 22
>>             if (ix < 0x4036_0000) {          // |x| < 22
>>                 if (ix<0x3c80_0000)          // |x| < 2**-55
>>                     return x*(one + x);      // tanh(small) = small
>>                 if (ix>=0x3ff0_0000) {       // |x| >= 1
>>                     t = StrictMath.expm1(two*Math.abs(x));
> 174c193
> <                     t = expm1(-two*Math.abs(x));
> ---
>>                     t = StrictMath.expm1(-two*Math.abs(x));
> 177,179c196,197
> <                 /* |x| > 22, return +-1 */
> <             } else {
> <                 z = one - tiny;             /* raised inexact flag */
> ---
>>             } else { // |x| > 22, return +-1
>>                 z = one - tiny;             // raised inexact flag

Joe Darcy has updated the pull request incrementally with two additional commits since the last revision:

 - Two more spacing fixes.
 - Implement spacing improvements from code review comments.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12429/files
  - new: https://git.openjdk.org/jdk/pull/12429/files/867235d1..c5b8dc16

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

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

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

From darcy at openjdk.org  Mon Feb  6 20:51:17 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Mon, 6 Feb 2023 20:51:17 GMT
Subject: RFR: JDK-8301444: Port fdlibm hyperbolic transcendental functions
 to Java [v2]
In-Reply-To: <2dHRl3CFLAqCZJeCULJHwuI-msEWVD3NR9W96zdPrpM=.3b945995-e933-4a41-b86d-e28eaa74a38d@github.com>
References: <_s8xnppoDTnAajAjlmfB-dX5DBdawUcSSPaGWGLzFBk=.cdbf468a-ace7-45e5-a25a-833c760b776c@github.com>
 <2dHRl3CFLAqCZJeCULJHwuI-msEWVD3NR9W96zdPrpM=.3b945995-e933-4a41-b86d-e28eaa74a38d@github.com>
Message-ID: <fH7P6UcewLSmbd4QCZ7X8ZTfD4S1xCNhindSuXGTX0A=.10840910-5209-46df-a5ac-5a9d3d262f37@github.com>

On Mon, 6 Feb 2023 08:33:37 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

>> Joe Darcy has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Two more spacing fixes.
>>  - Implement spacing improvements from code review comments.
>
> src/java.base/share/classes/java/lang/FdLibm.java line 1233:
> 
>> 1231: 
>> 1232:             h = 0.5;
>> 1233:             if ( jx < 0) {
> 
> Suggestion:
> 
>             if (jx < 0) {

Spacing fixed; thanks @turbanoff .

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

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

From darcy at openjdk.org  Mon Feb  6 21:57:52 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Mon, 6 Feb 2023 21:57:52 GMT
Subject: RFR: JDK-8301444: Port fdlibm hyperbolic transcendental functions
 to Java [v2]
In-Reply-To: <fMzn-Bu9W5Lbqt1uTwKRQqu1lebKEUomO22TX0iMQc8=.4c547336-380c-4825-9cdb-bb091d6f8e75@github.com>
References: <_s8xnppoDTnAajAjlmfB-dX5DBdawUcSSPaGWGLzFBk=.cdbf468a-ace7-45e5-a25a-833c760b776c@github.com>
 <fMzn-Bu9W5Lbqt1uTwKRQqu1lebKEUomO22TX0iMQc8=.4c547336-380c-4825-9cdb-bb091d6f8e75@github.com>
Message-ID: <SqN7pgh29PWFA1NsmeJxU4a8MclqswrH__waOfzz1Eg=.a2e5d6c1-7231-4d90-8057-fbec8dcc8c58@github.com>

On Mon, 6 Feb 2023 11:34:40 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> Joe Darcy has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Two more spacing fixes.
>>  - Implement spacing improvements from code review comments.
>
> test/jdk/java/lang/StrictMath/FdlibmTranslit.java line 874:
> 
>> 872:             // lx = *( (((*(unsigned*)&one)>>29)) + (unsigned*)&x);
>> 873:             // lx =  (((*(unsigned*)&one)>>29)) + (unsigned*)&x ;
>> 874:             lx = __LO(x);
> 
> This aspect of the transliteration is unclear.
> The C code seems to ignore endianness of `double` values, and there's a shift by 29 that seems intentional for some reason.
> Are we safe with the `__LO(x)` transliteration?

Yes, it gave me pause when doing the transliteration.

Unpacking the code a bit,


            /* |x| in [log(maxdouble), overflowthresold] */
            // lx = *( (((*(unsigned*)&one)>>29)) + (unsigned*)&x);
            lx = __LO(x);
            if (ix<0x408633CE || 
            ((ix==0x408633ce)&&(Long.compareUnsigned(lx, 0x8fb9f87d) <= 0 ))) {...}


Assuming the comment accurate describe the intention of the code, identifying values between log(maxdouble) and the overflow threshold. Those particular values are as decimal fp, hex hp, and long bits:

709.782712893384    0x1.62e42fefa39efp9    40862e42__fefa39ef
710.4758600739439    0x1.633ce8fb9f87dp9    408633ce_8fb9f87d

so the conditional is checking if the high word (ix) is for something less than the low end of the range OR if the high word matches the high word for the high end of the range AND low bits are for less than the high end of the range. Therefore, I think taking __LO(x) is the correct semantics here.

FWIW, the ExhaustingTest of running all the float values against sinh/cosh/tanh in the transliteration port passes when using JDK 20 baseline as a reference.

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

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

From darcy at openjdk.org  Mon Feb  6 22:08:06 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Mon, 6 Feb 2023 22:08:06 GMT
Subject: RFR: JDK-8301444: Port fdlibm hyperbolic transcendental functions
 to Java [v3]
In-Reply-To: <_s8xnppoDTnAajAjlmfB-dX5DBdawUcSSPaGWGLzFBk=.cdbf468a-ace7-45e5-a25a-833c760b776c@github.com>
References: <_s8xnppoDTnAajAjlmfB-dX5DBdawUcSSPaGWGLzFBk=.cdbf468a-ace7-45e5-a25a-833c760b776c@github.com>
Message-ID: <HoCaJ-zkReSJFfNp11mlphGXA2jVJLQW_hZisTm7bhE=.561a6b8c-69e8-439e-bbcb-e19286e313d5@github.com>

> Initial pass of porting FDLIBM sinh/cosh/tanh to Java. I do intend to refactor the regression tests a bit to reduce duplication, but the actual ports should be ready for review.
> 
> Diff'ing the ports as before, original vs transliteration port:
> 
> 
> $ diff -w Hyperbolic.c Hyperbolic.translit.java
> 1c1
> < /* __ieee754_sinh(x)
> ---
>>     /**
> 17a18,19
>>     static class Sinh {
>>         private static final double one = 1.0, shuge = 1.0e307;
> 19,33c21
> < #include "fdlibm.h"
> < 
> < #ifdef __STDC__
> < static const double one = 1.0, shuge = 1.0e307;
> < #else
> < static double one = 1.0, shuge = 1.0e307;
> < #endif
> < 
> < #ifdef __STDC__
> <         double __ieee754_sinh(double x)
> < #else
> <         double __ieee754_sinh(x)
> <         double x;
> < #endif
> < {
> ---
>>         private static double compute(double x) {
> 36c24
> <         unsigned lx;
> ---
>>             /* unsigned */ int lx;
> 51c39
> <             t = expm1(fabs(x));
> ---
>>                 t = FdlibmTranslit.expm1(Math.abs(x));
> 57c45
> <         if (ix < 0x40862E42)  return h*__ieee754_exp(fabs(x));
> ---
>>             if (ix < 0x40862E42)  return h*StrictMath.exp(Math.abs(x)); // TODO switch to translit
> 60,62c48,52
> <         lx = *( (((*(unsigned*)&one)>>29)) + (unsigned*)&x);
> <         if (ix<0x408633CE || ((ix==0x408633ce)&&(lx<=(unsigned)0x8fb9f87d))) {
> <             w = __ieee754_exp(0.5*fabs(x));
> ---
>>             // lx = *( (((*(unsigned*)&one)>>29)) + (unsigned*)&x);
>>             // lx =  (((*(unsigned*)&one)>>29)) + (unsigned*)&x ;
>>             lx = __LO(x);
>>             if (ix<0x408633CE || ((ix==0x408633ce)&&(Long.compareUnsigned(lx, 0x8fb9f87d) <= 0 ))) {
>>                 w = StrictMath.exp(0.5*Math.abs(x)); // TODO switch to translit
> 70c60,62
> < /* __ieee754_cosh(x)
> ---
>>     }
>> 
>>     /**
> 90,105c82,84
> < 
> < #include "fdlibm.h"
> < 
> < #ifdef __STDC__
> < static const double one = 1.0, half=0.5, huge = 1.0e300;
> < #else
> < static double one = 1.0, half=0.5, huge = 1.0e300;
> < #endif
> < 
> < #ifdef __STDC__
> <         double __ieee754_cosh(double x)
> < #else
> <         double __ieee754_cosh(x)
> <         double x;
> < #endif
> < {
> ---
>>     static class Cosh {
>>         private static final double one = 1.0, half=0.5, huge = 1.0e300;
>>         private static double compute(double x) {
> 108c87
> <         unsigned lx;
> ---
>>             /*unsigned*/ int lx;
> 119c98
> <             t = expm1(fabs(x));
> ---
>>                 t = expm1(Math.abs(x));
> 127c106
> <                 t = __ieee754_exp(fabs(x));
> ---
>>                 t = StrictMath.exp(Math.abs(x)); // TODO switch to translit
> 132c111
> <         if (ix < 0x40862E42)  return half*__ieee754_exp(fabs(x));
> ---
>>             if (ix < 0x40862E42)  return half*StrictMath.exp(Math.abs(x)); // TODO switch to translit
> 135c114
> <         lx = *( (((*(unsigned*)&one)>>29)) + (unsigned*)&x);
> ---
>>             lx = __LO(x);
> 137,138c116,117
> <               ((ix==0x408633ce)&&(lx<=(unsigned)0x8fb9f87d))) {
> <             w = __ieee754_exp(half*fabs(x));
> ---
>>                 ((ix==0x408633ce)&&(Integer.compareUnsigned(lx, 0x8fb9f87d) <= 0))) {
>>                 w = StrictMath.exp(half*Math.abs(x)); // TODO switch to translit
> 146c125,127
> < /* Tanh(x)
> ---
>>     }
>> 
>>     /**
> 169,184c150,152
> < 
> < #include "fdlibm.h"
> < 
> < #ifdef __STDC__
> < static const double one=1.0, two=2.0, tiny = 1.0e-300;
> < #else
> < static double one=1.0, two=2.0, tiny = 1.0e-300;
> < #endif
> < 
> < #ifdef __STDC__
> <         double tanh(double x)
> < #else
> <         double tanh(x)
> <         double x;
> < #endif
> < {
> ---
>>     static class Tanh {
>>         private static final double one=1.0, two=2.0, tiny = 1.0e-300;
>>         static double compute(double x) {
> 203c171
> <                 t = expm1(two*fabs(x));
> ---
>>                     t = expm1(two*Math.abs(x));
> 206c174
> <                 t = expm1(-two*fabs(x));
> ---
>>                     t = expm1(-two*Math.abs(x));
> 214a183
>>     }
> 
> 
> Note that the original has a in-line version of the "__LO" macro rather than using the macro.
> 
> 
> And transliteration vs more idiomatic:
> 
> 
> $ diff -w Hyperbolic.translit.java Hyperbolic.fdlibm.java 
> 21c21
> <         private static double compute(double x) {
> ---
>>          static double compute(double x) {
> 26c26
> <             /* High word of |x|. */
> ---
>>             // High word of |x|
> 28c28
> <             ix = jx&0x7fffffff;
> ---
>>             ix = jx & 0x7fff_ffff;
> 30,31c30,33
> <             /* x is INF or NaN */
> <             if(ix>=0x7ff00000) return x+x;
> ---
>>             // x is INF or NaN
>>             if ( ix >= 0x7ff0_0000) {
>>                 return x + x;
>>             }
> 34,40c36,48
> <             if (jx<0) h = -h;
> <             /* |x| in [0,22], return sign(x)*0.5*(E+E/(E+1))) */
> <             if (ix < 0x40360000) {          /* |x|<22 */
> <                 if (ix<0x3e300000)          /* |x|<2**-28 */
> <                     if(shuge+x>one) return x;/* sinh(tiny) = tiny with inexact */
> <                 t = FdlibmTranslit.expm1(Math.abs(x));
> <                 if(ix<0x3ff00000) return h*(2.0*t-t*t/(t+one));
> ---
>>             if ( jx < 0) {
>>                 h = -h;
>>             }
>>             // |x| in [0,22], return sign(x)*0.5*(E+E/(E+1)))
>>             if (ix < 0x4036_0000) {          // |x| < 22
>>                 if (ix < 0x3e30_0000)        // |x| < 2**-28
>>                     if (shuge + x > one) {   // sinh(tiny) = tiny with inexact
>>                         return x;
>>                     }
>>                 t = StrictMath.expm1(Math.abs(x));
>>                 if (ix < 0x3ff0_0000) {
>>                     return h*(2.0 * t - t*t/(t + one));
>>                 }
> 44,45c52,55
> <             /* |x| in [22, log(maxdouble)] return 0.5*exp(|x|) */
> <             if (ix < 0x40862E42)  return h*StrictMath.exp(Math.abs(x)); // TODO switch to translit
> ---
>>             // |x| in [22, log(maxdouble)] return 0.5*exp(|x|)
>>             if (ix < 0x4086_2E42) {
>>                 return h*StrictMath.exp(Math.abs(x));
>>             }
> 47,49c57
> <             /* |x| in [log(maxdouble), overflowthresold] */
> <             // lx = *( (((*(unsigned*)&one)>>29)) + (unsigned*)&x);
> <             // lx =  (((*(unsigned*)&one)>>29)) + (unsigned*)&x ;
> ---
>>             // |x| in [log(maxdouble), overflowthresold]
> 51,52c59,62
> <             if (ix<0x408633CE || ((ix==0x408633ce)&&(Long.compareUnsigned(lx, 0x8fb9f87d) <= 0 ))) {
> <                 w = StrictMath.exp(0.5*Math.abs(x)); // TODO switch to translit
> ---
>>             if (ix < 0x4086_33CE ||
>>                 ((ix == 0x4086_33ce) &&
>>                  (Long.compareUnsigned(lx, 0x8fb9_f87d) <= 0 ))) {
>>                 w = StrictMath.exp(0.5 * Math.abs(x));
> 57c67
> <             /* |x| > overflowthresold, sinh(x) overflow */
> ---
>>             // |x| > overflowthresold, sinh(x) overflow
> 84c94
> <         private static double compute(double x) {
> ---
>>         static double compute(double x) {
> 89c99
> <             /* High word of |x|. */
> ---
>>             // High word of |x|
> 91c101
> <             ix &= 0x7fffffff;
> ---
>>             ix &= 0x7fff_ffff;
> 93,94c103,106
> <             /* x is INF or NaN */
> <             if(ix>=0x7ff00000) return x*x;
> ---
>>             // x is INF or NaN
>>             if (ix >= 0x7ff_00000) {
>>                 return x*x;
>>             }
> 96,98c108,110
> <             /* |x| in [0,0.5*ln2], return 1+expm1(|x|)^2/(2*exp(|x|)) */
> <             if(ix<0x3fd62e43) {
> <                 t = expm1(Math.abs(x));
> ---
>>             // |x| in [0,0.5*ln2], return 1+expm1(|x|)^2/(2*exp(|x|))
>>             if (ix < 0x3fd6_2e43) {
>>                 t = StrictMath.expm1(Math.abs(x));
> 100c112,114
> <                 if (ix<0x3c800000) return w;        /* cosh(tiny) = 1 */
> ---
>>                 if (ix < 0x3c80_0000) { // cosh(tiny) = 1
>>                     return w;
>>                 }
> 104,106c118,120
> <             /* |x| in [0.5*ln2,22], return (exp(|x|)+1/exp(|x|)/2; */
> <             if (ix < 0x40360000) {
> <                 t = StrictMath.exp(Math.abs(x)); // TODO switch to translit
> ---
>>             // |x| in [0.5*ln2, 22], return (exp(|x|) + 1/exp(|x|)/2
>>             if (ix < 0x4036_0000) {
>>                 t = StrictMath.exp(Math.abs(x));
> 110,111c124,127
> <             /* |x| in [22, log(maxdouble)] return half*exp(|x|) */
> <             if (ix < 0x40862E42)  return half*StrictMath.exp(Math.abs(x)); // TODO switch to translit
> ---
>>             // |x| in [22, log(maxdouble)] return half*exp(|x|)
>>             if (ix < 0x4086_2E42) {
>>                 return half*StrictMath.exp(Math.abs(x));
>>             }
> 113c129
> <             /* |x| in [log(maxdouble), overflowthresold] */
> ---
>>             // |x| in [log(maxdouble), overflowthresold]
> 115,117c131,134
> <             if (ix<0x408633CE ||
> <                 ((ix==0x408633ce)&&(Integer.compareUnsigned(lx, 0x8fb9f87d) <= 0))) {
> <                 w = StrictMath.exp(half*Math.abs(x)); // TODO switch to translit
> ---
>>             if (ix<0x4086_33CE ||
>>                 ((ix == 0x4086_33ce) &&
>>                  (Integer.compareUnsigned(lx, 0x8fb9_f87d) <= 0))) {
>>                 w = StrictMath.exp(half*Math.abs(x));
> 122c139
> <             /* |x| > overflowthresold, cosh(x) overflow */
> ---
>>             // |x| > overflowthresold, cosh(x) overflow
> 126d142
> < 
> 156c172
> <             /* High word of |x|. */
> ---
>>             // High word of |x|.
> 158c174
> <             ix = jx&0x7fffffff;
> ---
>>             ix = jx & 0x7fff_ffff;
> 160,163c176,182
> <             /* x is INF or NaN */
> <             if(ix>=0x7ff00000) {
> <                 if (jx>=0) return one/x+one;    /* tanh(+-inf)=+-1 */
> <                 else       return one/x-one;    /* tanh(NaN) = NaN */
> ---
>>             // x is INF or NaN
>>             if (ix >= 0x7ff0_0000) {
>>                 if (jx >= 0) {  // tanh(+-inf)=+-1
>>                     return one/x + one;
>>                 } else {        // tanh(NaN) = NaN
>>                     return one/x - one;
>>                 }
> 166,171c185,190
> <             /* |x| < 22 */
> <             if (ix < 0x40360000) {          /* |x|<22 */
> <                 if (ix<0x3c800000)          /* |x|<2**-55 */
> <                     return x*(one+x);       /* tanh(small) = small */
> <                 if (ix>=0x3ff00000) {       /* |x|>=1  */
> <                     t = expm1(two*Math.abs(x));
> ---
>>             // |x| < 22
>>             if (ix < 0x4036_0000) {          // |x| < 22
>>                 if (ix<0x3c80_0000)          // |x| < 2**-55
>>                     return x*(one + x);      // tanh(small) = small
>>                 if (ix>=0x3ff0_0000) {       // |x| >= 1
>>                     t = StrictMath.expm1(two*Math.abs(x));
> 174c193
> <                     t = expm1(-two*Math.abs(x));
> ---
>>                     t = StrictMath.expm1(-two*Math.abs(x));
> 177,179c196,197
> <                 /* |x| > 22, return +-1 */
> <             } else {
> <                 z = one - tiny;             /* raised inexact flag */
> ---
>>             } else { // |x| > 22, return +-1
>>                 z = one - tiny;             // raised inexact flag

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

  Correct overflow limit in regression test.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12429/files
  - new: https://git.openjdk.org/jdk/pull/12429/files/c5b8dc16..420f119d

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

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

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

From darcy at openjdk.org  Mon Feb  6 22:08:07 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Mon, 6 Feb 2023 22:08:07 GMT
Subject: RFR: JDK-8301444: Port fdlibm hyperbolic transcendental functions
 to Java [v3]
In-Reply-To: <SqN7pgh29PWFA1NsmeJxU4a8MclqswrH__waOfzz1Eg=.a2e5d6c1-7231-4d90-8057-fbec8dcc8c58@github.com>
References: <_s8xnppoDTnAajAjlmfB-dX5DBdawUcSSPaGWGLzFBk=.cdbf468a-ace7-45e5-a25a-833c760b776c@github.com>
 <fMzn-Bu9W5Lbqt1uTwKRQqu1lebKEUomO22TX0iMQc8=.4c547336-380c-4825-9cdb-bb091d6f8e75@github.com>
 <SqN7pgh29PWFA1NsmeJxU4a8MclqswrH__waOfzz1Eg=.a2e5d6c1-7231-4d90-8057-fbec8dcc8c58@github.com>
Message-ID: <oOdHn8vDoAaIM9aWH1v8t3kkae0Iod5p3aHjGO_6DcQ=.35f4064b-6b04-43fa-ab2d-40bfd9ad1809@github.com>

On Mon, 6 Feb 2023 21:55:26 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> test/jdk/java/lang/StrictMath/FdlibmTranslit.java line 874:
>> 
>>> 872:             // lx = *( (((*(unsigned*)&one)>>29)) + (unsigned*)&x);
>>> 873:             // lx =  (((*(unsigned*)&one)>>29)) + (unsigned*)&x ;
>>> 874:             lx = __LO(x);
>> 
>> This aspect of the transliteration is unclear.
>> The C code seems to ignore endianness of `double` values, and there's a shift by 29 that seems intentional for some reason.
>> Are we safe with the `__LO(x)` transliteration?
>
> Yes, it gave me pause when doing the transliteration.
> 
> Unpacking the code a bit,
> 
> 
>             /* |x| in [log(maxdouble), overflowthresold] */
>             // lx = *( (((*(unsigned*)&one)>>29)) + (unsigned*)&x);
>             lx = __LO(x);
>             if (ix<0x408633CE || 
>             ((ix==0x408633ce)&&(Long.compareUnsigned(lx, 0x8fb9f87d) <= 0 ))) {...}
> 
> 
> Assuming the comment accurate describe the intention of the code, identifying values between log(maxdouble) and the overflow threshold. Those particular values are as decimal fp, hex hp, and long bits:
> 
> 709.782712893384    0x1.62e42fefa39efp9    40862e42__fefa39ef
> 710.4758600739439    0x1.633ce8fb9f87dp9    408633ce_8fb9f87d
> 
> so the conditional is checking if the high word (ix) is for something less than the low end of the range OR if the high word matches the high word for the high end of the range AND low bits are for less than the high end of the range. Therefore, I think taking __LO(x) is the correct semantics here.
> 
> FWIW, the ExhaustingTest of running all the float values against sinh/cosh/tanh in the transliteration port passes when using JDK 20 baseline as a reference.

PS One possible future refactoring to the code in

src/java.base/share/classes/java/lang/FdLibm.java

would be to replace such integer-based range checks with floating-point based range checks, in this case something like:


if (absX <= 0x1.633ce8fb9f87dp9) { // 710.4758600739439
    ...}

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

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

From rriggs at openjdk.org  Mon Feb  6 22:52:10 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 6 Feb 2023 22:52:10 GMT
Subject: [jdk20] RFR: 8301863: ObjectInputFilter example incorrectly calls
 rejectUndecidedClass [v2]
In-Reply-To: <i0ZaWMa10jaiLQL21r8epcqXwsnnmMUhF-ilhTWERlQ=.2a911a8f-4606-403f-8eba-13146a829304@github.com>
References: <i0ZaWMa10jaiLQL21r8epcqXwsnnmMUhF-ilhTWERlQ=.2a911a8f-4606-403f-8eba-13146a829304@github.com>
Message-ID: <Qu4md0CW6xzEabvMDqf2ZLwZw5dxQpP8NjGnfR5ejIw=.c22fe67a-fb68-41c2-9d0a-0ebbb8f0f60c@github.com>

> The example code in ObjectInputFilter for the FilterInThread filter factory does not do what is intended and is poorly described. Clarifies that the JVM-wide filter and the thread local filter are merged and will reject classes that are otherwise not accepted or rejected. If a stream specific filter is set and does not accept or reject a class, the combined filter is applied.
> 
> This is a doc-only change.

Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:

  8301863: ObjectInputFilter example incorrectly calls rejectUndecidedClass
  Correct typo in prose.

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

Changes:
  - all: https://git.openjdk.org/jdk20/pull/121/files
  - new: https://git.openjdk.org/jdk20/pull/121/files/a71e9cfa..aaf5d38c

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

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

PR: https://git.openjdk.org/jdk20/pull/121

From asotona at openjdk.org  Mon Feb  6 23:24:28 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 6 Feb 2023 23:24:28 GMT
Subject: RFR: 8294982: Implementation of Classfile API [v12]
In-Reply-To: <c022hrWNEHW76nhP_sXTQXCTjtL8jjM8r_yYv0IvbPI=.2a9cfbae-2fef-4cdb-8189-b869b1513fef@github.com>
References: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
 <Q4VeZ2yWAg85FqUDJa5hYq3jHty5H547gD0H-x3oIq0=.58d463a4-237a-4fee-bd0f-83262d49522a@github.com>
 <c022hrWNEHW76nhP_sXTQXCTjtL8jjM8r_yYv0IvbPI=.2a9cfbae-2fef-4cdb-8189-b869b1513fef@github.com>
Message-ID: <72tbazC88v5YoHtiss3ZJ6bmRP02sRG1j6-h9q752fc=.2acd02a8-018c-45d5-b65d-7089c1819815@github.com>

On Fri, 3 Feb 2023 18:25:17 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Classfile API moved under jdk.internal.classfile package
>
> src/java.base/share/classes/jdk/internal/classfile/CodeBuilder.java line 333:
> 
>> 331:          * @see #catchingAll
>> 332:          */
>> 333:         CatchBuilder catching(ClassDesc exceptionType, Consumer<BlockCodeBuilder> catchHandler);
> 
> I imagine there are name clashes with Java keyword, hence the `ing` in the names. That said, this should probably revisited in a later bikeshedding round - as in the current form, the code builder API has most method names that are nouns (the thing being built) but it also has some verbs in there (trying, catching) which seem odd.

Please raise the naming convention discussion at classfile-api-dev at openjdk.org
Thanks.

> src/java.base/share/classes/jdk/internal/classfile/Opcode.java line 39:
> 
>> 37:  */
>> 38: public enum Opcode {
>> 39:     NOP(Classfile.NOP, 1, Kind.NOP),
> 
> This also duplicates the constants in classfile...

On the contrary, it has been deduplicated. Opcode is referencing numeric constants stored in Classfile.

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

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

From duke at openjdk.org  Tue Feb  7 00:12:21 2023
From: duke at openjdk.org (Scott Gibbons)
Date: Tue, 7 Feb 2023 00:12:21 GMT
Subject: RFR: JDK-8300808: Accelerate Base64 on x86 for AVX2 [v11]
In-Reply-To: <9zN3bjyMEikXYOlpjTy9_QPc-9usYiBJMUFdb-TaVrQ=.e8f65ce9-ac0f-4f8d-9c6b-b39ae1c26cd2@github.com>
References: <9zN3bjyMEikXYOlpjTy9_QPc-9usYiBJMUFdb-TaVrQ=.e8f65ce9-ac0f-4f8d-9c6b-b39ae1c26cd2@github.com>
Message-ID: <PoM3RCbgsT0X64L1fHCggfoUZB4kNLCRz6kgU8u18Vw=.7754c1ba-ff32-4f2a-b991-3d042b2377d8@github.com>

> Added code for Base64 acceleration (encode and decode) which will accelerate ~4x for AVX2 platforms.
> 
> Encode performance:
> **Old:**
> 
> Benchmark                      (maxNumBytes)   Mode  Cnt     Score   Error   Units
> Base64Encode.testBase64Encode           1024  thrpt    3  4309.439 ? 2.632  ops/ms
> 
> 
> **New:**
> 
> Benchmark                      (maxNumBytes)   Mode  Cnt      Score     Error   Units
> Base64Encode.testBase64Encode           1024  thrpt    3  24211.397 ? 102.026  ops/ms
> 
> 
> Decode performance:
> **Old:**
> 
> Benchmark                      (errorIndex)  (lineSize)  (maxNumBytes)   Mode  Cnt     Score    Error   Units
> Base64Decode.testBase64Decode           144           4           1024  thrpt    3  3961.768 ? 93.409  ops/ms
> 
> **New:**
> Benchmark                      (errorIndex)  (lineSize)  (maxNumBytes)   Mode  Cnt      Score    Error   Units
> Base64Decode.testBase64Decode           144           4           1024  thrpt    3  14738.051 ? 24.383  ops/ms

Scott Gibbons has updated the pull request incrementally with one additional commit since the last revision:

  Add algorithm comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12126/files
  - new: https://git.openjdk.org/jdk/pull/12126/files/cb271c00..0a274e5a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12126&range=10
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12126&range=09-10

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

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

From sviswanathan at openjdk.org  Tue Feb  7 00:51:46 2023
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Tue, 7 Feb 2023 00:51:46 GMT
Subject: RFR: JDK-8300808: Accelerate Base64 on x86 for AVX2 [v11]
In-Reply-To: <PoM3RCbgsT0X64L1fHCggfoUZB4kNLCRz6kgU8u18Vw=.7754c1ba-ff32-4f2a-b991-3d042b2377d8@github.com>
References: <9zN3bjyMEikXYOlpjTy9_QPc-9usYiBJMUFdb-TaVrQ=.e8f65ce9-ac0f-4f8d-9c6b-b39ae1c26cd2@github.com>
 <PoM3RCbgsT0X64L1fHCggfoUZB4kNLCRz6kgU8u18Vw=.7754c1ba-ff32-4f2a-b991-3d042b2377d8@github.com>
Message-ID: <a631lHirqhoYAr42BnOfqC5ZZeLk5u-7kqLX8ufcBew=.742a2296-aeca-4788-ad43-874d6eeacef6@github.com>

On Tue, 7 Feb 2023 00:12:21 GMT, Scott Gibbons <duke at openjdk.org> wrote:

>> Added code for Base64 acceleration (encode and decode) which will accelerate ~4x for AVX2 platforms.
>> 
>> Encode performance:
>> **Old:**
>> 
>> Benchmark                      (maxNumBytes)   Mode  Cnt     Score   Error   Units
>> Base64Encode.testBase64Encode           1024  thrpt    3  4309.439 ? 2.632  ops/ms
>> 
>> 
>> **New:**
>> 
>> Benchmark                      (maxNumBytes)   Mode  Cnt      Score     Error   Units
>> Base64Encode.testBase64Encode           1024  thrpt    3  24211.397 ? 102.026  ops/ms
>> 
>> 
>> Decode performance:
>> **Old:**
>> 
>> Benchmark                      (errorIndex)  (lineSize)  (maxNumBytes)   Mode  Cnt     Score    Error   Units
>> Base64Decode.testBase64Decode           144           4           1024  thrpt    3  3961.768 ? 93.409  ops/ms
>> 
>> **New:**
>> Benchmark                      (errorIndex)  (lineSize)  (maxNumBytes)   Mode  Cnt      Score    Error   Units
>> Base64Decode.testBase64Decode           144           4           1024  thrpt    3  14738.051 ? 24.383  ops/ms
>
> Scott Gibbons has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add algorithm comments

src/hotspot/cpu/x86/stubGenerator_x86_64.cpp line 2720:

> 2718:     __ vpshufb(xmm5, xmm9, xmm1, Assembler::AVX_256bit);
> 2719:     // If the and of the two is non-zero, we have an invalid input character
> 2720:     __ vptest(xmm3, xmm5);

For isURL, it looks to me that the vptest will fail for URL valid input 0x5F ("_"):
  upper_nibble =  0x5; 
  lower_nibble = 0xF;
  lut_lo_URL = 0x1B; (corresponding to 0xF)
  lut_hi = 0x8; (corresponding to 0x5)
  lut_lo_URL & lut_hi = 0x8; (not zero, taken as not allowable and so exit from loop)
Could you please verify on your end and fix this?
My understanding is that this is happening because 5 and 7 upper nibble get the same encoding 0x8.

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

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

From darcy at openjdk.org  Tue Feb  7 01:00:46 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 7 Feb 2023 01:00:46 GMT
Subject: RFR: 8301226: Add clamp() methods to java.lang.Math and to
 StrictMath [v4]
In-Reply-To: <Ddvn1DCxT2qXxF7oOltTVKlnvkATfbHTuq7ZBtWWdwI=.bf25f42a-9fa0-4ee0-95a9-f0a7ab94434b@github.com>
References: <c7kJhZvT8oz5hScMxnWI23H7wjCaJ854ajjSRtxBnW4=.3f4e24ca-c608-4541-b80e-cf3452ec6400@github.com>
 <Ddvn1DCxT2qXxF7oOltTVKlnvkATfbHTuq7ZBtWWdwI=.bf25f42a-9fa0-4ee0-95a9-f0a7ab94434b@github.com>
Message-ID: <WC-fFkld71Gc7paBNaPbRBjWomTq5E_Ol5muDjRrVvw=.8e859ec2-0f60-4721-96e1-33fb69e7860e@github.com>

On Mon, 6 Feb 2023 09:46:15 GMT, Tagir F. Valeev <tvaleev at openjdk.org> wrote:

>> clamp() methods added to Math and StrictMath
>> 
>> `int clamp(long, int, int)` is somewhat different, as it accepts a `long` value and safely clamps it to an `int` range. Other overloads work with a particular type (long, float and double). Using similar approach in other cases (e.g. `float clamp(double, float, float)`) may cause accidental precision loss even if the value is within range, so I decided to avoid this.
>> 
>> In all cases, `max >= min` precondition should met. For double and float we additionally order `-0.0 < 0.0`, similarly to what Math.max or Double.compare do. In double and float overloads I try to keep at most one arg-check comparison on common path, so the order of checks might look unusual.
>> 
>> For tests, I noticed that tests in java/lang/Math don't use any testing framework (even newer tests), so I somehow mimic the approach of neighbour tests.
>
> Tagir F. Valeev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Added explanatory comments

src/java.base/share/classes/java/lang/Math.java line 2266:

> 2264:         // If min == max, we should additionally check for +0.0/-0.0 case,
> 2265:         // so we're still visiting the if statement.
> 2266:         if (!(min < max)) {

A suggestion for an additional comment on this line like:

// min greater than, equal to, or unordered with respect to max; NaN values are unorded

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

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

From darcy at openjdk.org  Tue Feb  7 01:05:49 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 7 Feb 2023 01:05:49 GMT
Subject: RFR: 8301226: Add clamp() methods to java.lang.Math and to
 StrictMath [v4]
In-Reply-To: <Ddvn1DCxT2qXxF7oOltTVKlnvkATfbHTuq7ZBtWWdwI=.bf25f42a-9fa0-4ee0-95a9-f0a7ab94434b@github.com>
References: <c7kJhZvT8oz5hScMxnWI23H7wjCaJ854ajjSRtxBnW4=.3f4e24ca-c608-4541-b80e-cf3452ec6400@github.com>
 <Ddvn1DCxT2qXxF7oOltTVKlnvkATfbHTuq7ZBtWWdwI=.bf25f42a-9fa0-4ee0-95a9-f0a7ab94434b@github.com>
Message-ID: <PUtjAcSAvAMpJS2IrYDyCdJ-75Fie003i5nquEE9WQQ=.5823db09-c208-40c3-b4ff-fda58169075e@github.com>

On Mon, 6 Feb 2023 09:46:15 GMT, Tagir F. Valeev <tvaleev at openjdk.org> wrote:

>> clamp() methods added to Math and StrictMath
>> 
>> `int clamp(long, int, int)` is somewhat different, as it accepts a `long` value and safely clamps it to an `int` range. Other overloads work with a particular type (long, float and double). Using similar approach in other cases (e.g. `float clamp(double, float, float)`) may cause accidental precision loss even if the value is within range, so I decided to avoid this.
>> 
>> In all cases, `max >= min` precondition should met. For double and float we additionally order `-0.0 < 0.0`, similarly to what Math.max or Double.compare do. In double and float overloads I try to keep at most one arg-check comparison on common path, so the order of checks might look unusual.
>> 
>> For tests, I noticed that tests in java/lang/Math don't use any testing framework (even newer tests), so I somehow mimic the approach of neighbour tests.
>
> Tagir F. Valeev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Added explanatory comments

test/jdk/java/lang/Math/Clamp.java line 47:

> 45:     private static int testIntClamp() {
> 46:         int failures = 0;
> 47:         failures += checkIntClamp(0, 1, 2, 1);

Possible refactoring here: represent the test cases in, say, a 2D int array or an array/list of records and loop over them.

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

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

From xgong at openjdk.org  Tue Feb  7 02:29:45 2023
From: xgong at openjdk.org (Xiaohong Gong)
Date: Tue, 7 Feb 2023 02:29:45 GMT
Subject: RFR: 8293198: [vectorapi] Improve the implementation of
 VectorMask.indexInRange() [v2]
In-Reply-To: <7BM1vdj6ShoztqsIgXgTjzVMTiZtdSCL8JqxwXz44Kw=.0f5a61df-4838-4043-8155-dc3ae45ca99b@github.com>
References: <fN58bi3n01tqWpG0-jjUPZQe8hmls2GQ5X3NL2o1RPg=.80e7965d-50af-4fac-bd7c-0a2b99cffe7e@github.com>
 <0dNCRVASsdME6qS79u5z7c6mikJs1jfucfo54lo71ik=.d8c2dc6e-bc60-499f-899c-880a2219b052@github.com>
 <7BM1vdj6ShoztqsIgXgTjzVMTiZtdSCL8JqxwXz44Kw=.0f5a61df-4838-4043-8155-dc3ae45ca99b@github.com>
Message-ID: <cv64k3l_3Md1MbY90_OcNMTiLsCg_zx_XIKwqkMOH5g=.2adad684-79e3-481d-9412-5c5ed0cb593c@github.com>

On Mon, 6 Feb 2023 17:39:42 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>> Xiaohong Gong has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add smaller array size for benchmark tests
>
> I think it would be useful to adjust the naming and comments of some methods to make it clearer the method parameter constraints.
> 
> `indexInRange0Helper` is now called if the index is partially or totally out of range at the lower or upper ends and `indexInRange0` is called if partially or totally out of range at the upper end.
> e.g. a more literal naming could be:
> `AbstractMask::indexInRange0Helper` -> `AbstractMask::indexPartiallyInRangeHelper`
> `VectorSupport::indexInRange` -> VectorSupport::indexPartiallyInUpperRange`
> ?
> 
> IIUC the performance numbers show that when the array is not a multiple of the vector size there is still quite an impact overall to calling `VectorSupport::indexInRange` for the last loop iteration. I am guessing the overall loop shape is different which impacts other optimizations?
> 
> To do this more optimally likely requires a loop transformation where the last loop iteration is peeled off, but that's a harder transformation in one of the more complicated areas of C2 (although it already supports pre/post loop, so maybe its possible to leverage that?).

Thanks for looking at this PR @PaulSandoz !

> I think it would be useful to adjust the naming and comments of some methods to make it clearer the method parameter constraints.
> 
> `indexInRange0Helper` is now called if the index is partially or totally out of range at the lower or upper ends and `indexInRange0` is called if partially or totally out of range at the upper end. e.g. a more literal naming could be: `AbstractMask::indexInRange0Helper` -> `AbstractMask::indexPartiallyInRangeHelper` `VectorSupport::indexInRange` -> VectorSupport::indexPartiallyInUpperRange` ?

The renaming looks good to me. Thanks!

> IIUC the performance numbers show that when the array is not a multiple of the vector size there is still quite an impact overall to calling `VectorSupport::indexInRange` for the last loop iteration. I am guessing the overall loop shape is different which impacts other optimizations?

I think the main influence of the benchmark result comes from the masked ` fromArray()/intoArray()` APIs, especially the masked intoArray() API. For the tail loop part, there is the vector boxing needed on all architectures, with the following reasons:

- If the architecture doesn't support predicate feature, it cannot be intrinsified.
- The `checkMaskFromIndexSize` called inside the `else->if` branch may not be inlined, and the `indexInRange()` generated mask `m` needs the boxing before it.


public final
    void intoArray(double[] a, int offset,
                   VectorMask<Double> m) {
        if (m.allTrue()) {
            intoArray(a, offset);
        } else {
            DoubleSpecies vsp = vspecies();
            if (!VectorIntrinsics.indexInRange(offset, vsp.length(), a.length)) {
                checkMaskFromIndexSize(offset, vsp, m, 1, a.length);
            }
            intoArray0(a, offset, m);
        }
    }


If the array size is aligned with the vector size, the generated `m` is all true. Hence, the non-masked `intoArray()` is called instead, which improves the performance a lot.

Regarding to the `indexInRange()` API implementation, if the array size is the multiple num of vector size, the branch for the tail loop part is optimized out to an uncommon-trap by C2 compiler, which may improves the performance as well. 

Regarding to the added benchmark, since it is a testing for `indexInRange`, maybe we can remove the calling to the masked `fromArray()/intoArray()` APIs and directly save the mask into a boolean array instead. I guess this may reduce the overall performance gap. 

> 
> To do this more optimally likely requires a loop transformation where the last loop iteration is peeled off, but that's a harder transformation in one of the more complicated areas of C2 (although it already supports pre/post loop, so maybe its possible to leverage that?).

Yes, it is!

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

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

From duke at openjdk.org  Tue Feb  7 02:47:43 2023
From: duke at openjdk.org (SUN Guoyun)
Date: Tue, 7 Feb 2023 02:47:43 GMT
Subject: RFR: 8301737:
 java/rmi/server/UnicastRemoteObject/serialFilter/FilterUROTest.java fail with
 -Xcomp [v2]
In-Reply-To: <2FSnoFjlzmgc-lNVYeTYH8x4fBt_xTI8IG62e9jNf2s=.6f6dde1f-296d-4dff-960f-798b6f87c24c@github.com>
References: <l5m5_9io2QMSFNY7dBHT3Nr2I9Er8wmd92Ze8FP-XE0=.a40d29be-77be-4719-a0a0-71d032eea1e5@github.com>
 <_KLsDrGvRYUmtKo962dExyk9Ajb6blQnPOXbGpO5mN0=.bdb33bcb-799d-4a8f-979a-bb0c2f3ce3a1@github.com>
 <2FSnoFjlzmgc-lNVYeTYH8x4fBt_xTI8IG62e9jNf2s=.6f6dde1f-296d-4dff-960f-798b6f87c24c@github.com>
Message-ID: <3rAaBXGvpnhcJtMJM3wXk0j84k3x4vr1pwn5XNnq8qk=.3dd4ccac-554e-4831-9508-c8c1f3f4965b@github.com>

On Mon, 6 Feb 2023 15:35:30 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> Please add @bug 8301737
> 
> It is not going to be obvious why a larger code cashe is needed (and only for aarch64).
> 
The error message in the .jtr file is `java.rmi.NoSuchObjectException: no such object in table`, which corresponding source code is as follows?
<pre><code class="java">
// src/java.rmi/share/classes/sun/rmi/transport/Transport.java
176             if (target == null || (impl = target.getImpl()) == null) {          // target is null
177                 throw new NoSuchObjectException("no such object in table");     
178             }  
</code></pre>

why target is null with `-Xcomp`? then you see the other source code:

<pre><code class="java">
// src/java.rmi//share/classes/sun/rmi/transport/ObjectTable.java
346     private static class Reaper implements Runnable {                           
347                                                                                 
348         public void run() {                                                     
349             try {                                                               
350                 do {                                                            
351                     // wait for next cleared weak reference                     
352                     WeakRef weakImpl = (WeakRef) reapQueue.remove();   // Monitor GC here  
353                                                                                 
354                     synchronized (tableLock) {                                  
355                         Target target = implTable.get(weakImpl);                
356                         if (target != null) {                                   
357                             if (!target.isEmpty()) {                            
358                                 throw new Error(                                
359                                     "object with known references collected");  
360                             } else if (target.isPermanent()) {                  
361                                 throw new Error("permanent object collected");  
362                             }                                                   
363                             removeTarget(target);             // target will be removed after GC. which happen before getTarget()
364                         }                                                       
365                     }                                                           
366                 } while (!Thread.interrupted());                                
367             } catch (InterruptedException e) {                                  
368                 // pass away if interrupted                                     
369             }                                                                   
370         }                                                                       
371     } 

So I used `-Xlog:gc` to find that the trigger gc is caused by insufficient codecache. 
</code></pre>

> Can you split the test runs so the original does not run on aarch64 and a new second run runs only on aarch64. For example,
> 
> ```
> /*
>  * @test
>  * @bug 8301737
>  * @summary Check that objects are exported with ObjectInputFilters via UnicastRemoteObject
>  * @requires os.arch != "aarch64"
>  * @run testng/othervm FilterUROTest
>  */
> 
> /*
>  * @test
>  * @summary Check that objects are exported with ObjectInputFilters via UnicastRemoteObject
>  * @requires os.arch == "aarch64"
>  * @run testng/othervm -XX:ReservedCodeCacheSize=512m FilterUROTest
>  */
> ```
This bug only for LoongArch64 architecture, x86_64 and AArch64 is ok. Perhaps the number of instructions under the LoongArch64 architecture is higher than in aarch64/x86_64. I'm not sure if the s390/risc-v/ppc architecture has the same problem, so I`m only use `@requires os.arch == "loongarch64" `?

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

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

From sviswanathan at openjdk.org  Tue Feb  7 02:52:46 2023
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Tue, 7 Feb 2023 02:52:46 GMT
Subject: RFR: JDK-8300808: Accelerate Base64 on x86 for AVX2 [v11]
In-Reply-To: <PoM3RCbgsT0X64L1fHCggfoUZB4kNLCRz6kgU8u18Vw=.7754c1ba-ff32-4f2a-b991-3d042b2377d8@github.com>
References: <9zN3bjyMEikXYOlpjTy9_QPc-9usYiBJMUFdb-TaVrQ=.e8f65ce9-ac0f-4f8d-9c6b-b39ae1c26cd2@github.com>
 <PoM3RCbgsT0X64L1fHCggfoUZB4kNLCRz6kgU8u18Vw=.7754c1ba-ff32-4f2a-b991-3d042b2377d8@github.com>
Message-ID: <BU4DTrvn7YzuMYMKlaxGabUFg3nppXV1oDhS9mwCQIs=.65ffd677-99eb-49a9-a8c7-f7f199fa7ad6@github.com>

On Tue, 7 Feb 2023 00:12:21 GMT, Scott Gibbons <duke at openjdk.org> wrote:

>> Added code for Base64 acceleration (encode and decode) which will accelerate ~4x for AVX2 platforms.
>> 
>> Encode performance:
>> **Old:**
>> 
>> Benchmark                      (maxNumBytes)   Mode  Cnt     Score   Error   Units
>> Base64Encode.testBase64Encode           1024  thrpt    3  4309.439 ? 2.632  ops/ms
>> 
>> 
>> **New:**
>> 
>> Benchmark                      (maxNumBytes)   Mode  Cnt      Score     Error   Units
>> Base64Encode.testBase64Encode           1024  thrpt    3  24211.397 ? 102.026  ops/ms
>> 
>> 
>> Decode performance:
>> **Old:**
>> 
>> Benchmark                      (errorIndex)  (lineSize)  (maxNumBytes)   Mode  Cnt     Score    Error   Units
>> Base64Decode.testBase64Decode           144           4           1024  thrpt    3  3961.768 ? 93.409  ops/ms
>> 
>> **New:**
>> Benchmark                      (errorIndex)  (lineSize)  (maxNumBytes)   Mode  Cnt      Score    Error   Units
>> Base64Decode.testBase64Decode           144           4           1024  thrpt    3  14738.051 ? 24.383  ops/ms
>
> Scott Gibbons has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add algorithm comments

src/hotspot/cpu/x86/stubGenerator_x86_64.cpp line 2227:

> 2225: 
> 2226:   // lut_roll URL
> 2227:   __ emit_data64(0xb9b9bfbf04111000, relocInfo::none);

The lut_roll URL doesn't seem to be correct:
0x5F (URL base64 ASCII for "/") would need an offset of -20H i.e. 0xEC.
However the others with upper nibble as 5 need an offset of -65H i.e. 0xBF.

It looks to me that the adjustment for 5F should be -4 instead of -1 at line 2722.

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

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

From darcy at openjdk.org  Tue Feb  7 03:47:44 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 7 Feb 2023 03:47:44 GMT
Subject: RFR: JDK-8301444: Port fdlibm hyperbolic transcendental functions
 to Java [v3]
In-Reply-To: <fMzn-Bu9W5Lbqt1uTwKRQqu1lebKEUomO22TX0iMQc8=.4c547336-380c-4825-9cdb-bb091d6f8e75@github.com>
References: <_s8xnppoDTnAajAjlmfB-dX5DBdawUcSSPaGWGLzFBk=.cdbf468a-ace7-45e5-a25a-833c760b776c@github.com>
 <fMzn-Bu9W5Lbqt1uTwKRQqu1lebKEUomO22TX0iMQc8=.4c547336-380c-4825-9cdb-bb091d6f8e75@github.com>
Message-ID: <B4i0y0O8nAI-6PUbspvT6_bUet6uI2AVCZl4Uo-z2II=.cc4aa5a8-3d10-4a59-b8a7-03eb90748547@github.com>

On Mon, 6 Feb 2023 11:37:41 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Correct overflow limit in regression test.
>
> test/jdk/java/lang/StrictMath/FdlibmTranslit.java line 938:
> 
>> 936: 
>> 937:             /* |x| in [log(maxdouble), overflowthresold] */
>> 938:             lx = __LO(x);
> 
> Same concern as above about the transliteration to `__LO(x)`

Right; sinh and cosh overflow at the same input.

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

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

From duke at openjdk.org  Tue Feb  7 04:37:41 2023
From: duke at openjdk.org (Amit Kumar)
Date: Tue, 7 Feb 2023 04:37:41 GMT
Subject: RFR: 8299748: java/util/zip/Deinflate.java failing on s390x
In-Reply-To: <2eqxeIzcejWahzfAMe-czlbIQ96bV8s_RIkXQsXMtsY=.b329489c-40fc-4e91-9e30-10a3df53711e@github.com>
References: <Usxi4wE5GSHHv-cKPfW6OXylhieAypbsidUX_Jo6FSQ=.34104cf0-2243-478f-86ce-9a91905c6755@github.com>
 <nN80i01pPGVl8QlQ09eEEEeFTz5z2hpM6udh2bNJwpU=.925ff5c6-586b-4262-bcd0-fd67d44cfde2@github.com>
 <jyL7HTlmcVxDKffdPqij6GNM0ePfzVxlypfy3hTtOAM=.3347a8dd-4722-4b79-b93e-b20892901c6b@github.com>
 <2eqxeIzcejWahzfAMe-czlbIQ96bV8s_RIkXQsXMtsY=.b329489c-40fc-4e91-9e30-10a3df53711e@github.com>
Message-ID: <4cLz-rZwqQbMLRLrFkliOlAFRym-0xeQmVJkghFcHEE=.30eb5b44-c2f8-465a-a054-135ff17f82ae@github.com>

On Thu, 2 Feb 2023 10:06:23 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>>> level:1, strategy: 0, dowrap: false               
>>> is finished: false     
>> 
>> Thanks for checking that. So "is finished: false" is telling us that not all of the input was compressed. So I think the right thing is to do the deflate in a loop until there is more input to compress, the inflate probably needs the same. Your original proposal was to make the output buffer larger and I suspect that is just working around a threshold or block size used by the accelerator.
>
>> Hi @AlanBateman ,
>> with latest changes (doing inflate/deinflate) test passes over s390 and x86 as well. Please take a look now.
> 
> Good. One thing to try is to just deflate/inflate into out1/out2, no need for the intermediate BAOS, try this:
> 
> 
> --- a/test/jdk/java/util/zip/DeInflate.java
> +++ b/test/jdk/java/util/zip/DeInflate.java
> @@ -1,5 +1,5 @@
>  /*
> - * Copyright (c) 2011, 2018, Oracle and/or its affiliates. All rights reserved.
> + * Copyright (c) 2011, 2023, Oracle and/or its affiliates. All rights reserved.
>   * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>   *
>   * This code is free software; you can redistribute it and/or modify it
> @@ -127,11 +127,25 @@ public class DeInflate {
>  
>          def.setInput(in, 0, len);
>          def.finish();
> -        int m = def.deflate(out1);
> +        int m = 0;
> +        while (!def.finished()) {
> +            int remaining = out1.length - m;
> +            if (remaining == 0) {
> +                throw new RuntimeException("out1 is small");
> +            }
> +            m += def.deflate(out1, m, remaining);
> +        }
>  
>          Inflater inf = new Inflater(nowrap);
>          inf.setInput(out1, 0, m);
> -        int n = inf.inflate(out2);
> +        int n = 0;
> +        while (!inf.finished()) {
> +            int remaining = out2.length - n;
> +            if (remaining == 0) {
> +                throw new RuntimeException("out2 is small");
> +            }
> +            n += inf.inflate(out2, n, remaining);
> +        }
>  
>          if (n != len ||
>              !Arrays.equals(Arrays.copyOf(in, len), Arrays.copyOf(out2, len)) ||

@AlanBateman should we proceed with the current changes then ?

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

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

From alanb at openjdk.org  Tue Feb  7 07:10:46 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 7 Feb 2023 07:10:46 GMT
Subject: RFR: 8299748: java/util/zip/Deinflate.java failing on s390x
In-Reply-To: <2eqxeIzcejWahzfAMe-czlbIQ96bV8s_RIkXQsXMtsY=.b329489c-40fc-4e91-9e30-10a3df53711e@github.com>
References: <Usxi4wE5GSHHv-cKPfW6OXylhieAypbsidUX_Jo6FSQ=.34104cf0-2243-478f-86ce-9a91905c6755@github.com>
 <nN80i01pPGVl8QlQ09eEEEeFTz5z2hpM6udh2bNJwpU=.925ff5c6-586b-4262-bcd0-fd67d44cfde2@github.com>
 <jyL7HTlmcVxDKffdPqij6GNM0ePfzVxlypfy3hTtOAM=.3347a8dd-4722-4b79-b93e-b20892901c6b@github.com>
 <2eqxeIzcejWahzfAMe-czlbIQ96bV8s_RIkXQsXMtsY=.b329489c-40fc-4e91-9e30-10a3df53711e@github.com>
Message-ID: <p1li8W4D2kYNZlxTOyvlqVrZWOjGbh6g1JfG6eHxAmE=.389b076c-0943-4cfd-af82-f24a56d1ac61@github.com>

On Thu, 2 Feb 2023 10:06:23 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>>> level:1, strategy: 0, dowrap: false               
>>> is finished: false     
>> 
>> Thanks for checking that. So "is finished: false" is telling us that not all of the input was compressed. So I think the right thing is to do the deflate in a loop until there is more input to compress, the inflate probably needs the same. Your original proposal was to make the output buffer larger and I suspect that is just working around a threshold or block size used by the accelerator.
>
>> Hi @AlanBateman ,
>> with latest changes (doing inflate/deinflate) test passes over s390 and x86 as well. Please take a look now.
> 
> Good. One thing to try is to just deflate/inflate into out1/out2, no need for the intermediate BAOS, try this:
> 
> 
> --- a/test/jdk/java/util/zip/DeInflate.java
> +++ b/test/jdk/java/util/zip/DeInflate.java
> @@ -1,5 +1,5 @@
>  /*
> - * Copyright (c) 2011, 2018, Oracle and/or its affiliates. All rights reserved.
> + * Copyright (c) 2011, 2023, Oracle and/or its affiliates. All rights reserved.
>   * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>   *
>   * This code is free software; you can redistribute it and/or modify it
> @@ -127,11 +127,25 @@ public class DeInflate {
>  
>          def.setInput(in, 0, len);
>          def.finish();
> -        int m = def.deflate(out1);
> +        int m = 0;
> +        while (!def.finished()) {
> +            int remaining = out1.length - m;
> +            if (remaining == 0) {
> +                throw new RuntimeException("out1 is small");
> +            }
> +            m += def.deflate(out1, m, remaining);
> +        }
>  
>          Inflater inf = new Inflater(nowrap);
>          inf.setInput(out1, 0, m);
> -        int n = inf.inflate(out2);
> +        int n = 0;
> +        while (!inf.finished()) {
> +            int remaining = out2.length - n;
> +            if (remaining == 0) {
> +                throw new RuntimeException("out2 is small");
> +            }
> +            n += inf.inflate(out2, n, remaining);
> +        }
>  
>          if (n != len ||
>              !Arrays.equals(Arrays.copyOf(in, len), Arrays.copyOf(out2, len)) ||

> @AlanBateman should we proceed with the current changes then ?

The BAOS in your current proposal shouldn't be needed so I suspect there is something else "interesting" with this zlib implementation.  For the patch above, can you remove the checking for remaining == 0 and print out the value from deflate at each iterate of the loop. I'm wondering if it returns 0 before def.finished() returns true.

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

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

From alanb at openjdk.org  Tue Feb  7 07:13:40 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 7 Feb 2023 07:13:40 GMT
Subject: RFR: 8301767: Convert virtual thread tests to JUnit
Message-ID: <37UDjOGF9PZxUiP2BwkrfIKh82vQgdvA8pwxaln4pl8=.5f368aea-d8a2-4e4a-a6ae-4376e1f05c9b@github.com>

The non-hotspot tests integrated with JEP 425/428 were mostly TestNG tests. We'd like to convert these JUnit in the main line in advance of other updates to these tests in 21.  The changes are mostly mechanical and trivial:

- BeforeClass/AfterClass changed to static BeforeAll/AfterAll methods
- Tests using data providers are changed to parameterized tests
- The order of the parameters to assertEquals are swapped so that the expected result is the first parameter
- Usages of expectThrows are changed to assertThrows
- Tests that threw SkipException are changed to the Assumptions API

There are a small number of drive-by changes to the tests, nothing significant, e.g.

- GetStackTrace and ParkWithFixedThreadPool changed from "@run testng" to "@run main" as they aren't TestNG tests.
- A few of the tests in StructuredTaskScopeTest for joinXXX are changed to use a CountDownLatch rather than sleeping, as the original tests weren't very robust.

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

Commit messages:
 - Fix typos in comments
 - GetStackTrace.java test missing @requires vm.continuations
 - Initial commit

Changes: https://git.openjdk.org/jdk/pull/12426/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12426&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8301767
  Stats: 1416 lines in 34 files changed: 205 ins; 79 del; 1132 mod
  Patch: https://git.openjdk.org/jdk/pull/12426.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12426/head:pull/12426

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

From alanb at openjdk.org  Tue Feb  7 07:26:45 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 7 Feb 2023 07:26:45 GMT
Subject: RFR: JDK-8301833: Add manual tests for FDLIBM porting
In-Reply-To: <RR8Dy2nmLla5Q8jPCEW3ZeMNo3mbzNNvgZwlH7LbfiU=.4c1a7d2c-89e5-441b-b10f-fd3f570f5854@github.com>
References: <wgghXoOC-eICroAklhQSO8UYEBvYHF_QHZ4C_1wnW0Q=.61574f1b-9c40-4c34-b234-502b95a99c8f@github.com>
 <JSOpjfwMLEyZJbU6i9F7ECuuaxitsd8UQtaYKmZnNAU=.094f3b9d-e88d-4195-8015-4490a0dc632c@github.com>
 <RR8Dy2nmLla5Q8jPCEW3ZeMNo3mbzNNvgZwlH7LbfiU=.4c1a7d2c-89e5-441b-b10f-fd3f570f5854@github.com>
Message-ID: <n22FMnvex1n3Vt_82vRoh0i0EDwdUiqCJAc2oOGYHWs=.68d873ce-2a6f-476d-9135-654f4d0c8924@github.com>

On Mon, 6 Feb 2023 17:53:24 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Therefore, I think these tests should be included in the repository, but not run all the time, which led me to declare them as a manual jtreg test.

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

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

From alanb at openjdk.org  Tue Feb  7 07:38:47 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 7 Feb 2023 07:38:47 GMT
Subject: RFR: JDK-8301833: Add manual tests for FDLIBM porting
In-Reply-To: <RR8Dy2nmLla5Q8jPCEW3ZeMNo3mbzNNvgZwlH7LbfiU=.4c1a7d2c-89e5-441b-b10f-fd3f570f5854@github.com>
References: <wgghXoOC-eICroAklhQSO8UYEBvYHF_QHZ4C_1wnW0Q=.61574f1b-9c40-4c34-b234-502b95a99c8f@github.com>
 <JSOpjfwMLEyZJbU6i9F7ECuuaxitsd8UQtaYKmZnNAU=.094f3b9d-e88d-4195-8015-4490a0dc632c@github.com>
 <RR8Dy2nmLla5Q8jPCEW3ZeMNo3mbzNNvgZwlH7LbfiU=.4c1a7d2c-89e5-441b-b10f-fd3f570f5854@github.com>
Message-ID: <xESFfpiSXoiuuzyfEVnkmylii6JBxzj6wK44IDlQ6m4=.5ee3d199-de61-48a4-8413-f0c6deffd76c@github.com>

On Mon, 6 Feb 2023 17:53:24 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Therefore, I think these tests should be included in the repository, but not run all the time, which led me to declare them as a manual jtreg test.

Manual tests are run at each release. There are a couple of examples in the repo with tests that don't have @test tags. There are easily forgotten but they have been useful in a few areas for cases like this where the maintainer wants something in the repo doesn't doesn't want it run by regular testing. If you do decide to make this a manual test then I think it will need instructions so that someone knows what to do.

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

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

From duke at openjdk.org  Tue Feb  7 08:27:57 2023
From: duke at openjdk.org (SUN Guoyun)
Date: Tue, 7 Feb 2023 08:27:57 GMT
Subject: RFR: 8301737:
 java/rmi/server/UnicastRemoteObject/serialFilter/FilterUROTest.java fail with
 -Xcomp [v3]
In-Reply-To: <l5m5_9io2QMSFNY7dBHT3Nr2I9Er8wmd92Ze8FP-XE0=.a40d29be-77be-4719-a0a0-71d032eea1e5@github.com>
References: <l5m5_9io2QMSFNY7dBHT3Nr2I9Er8wmd92Ze8FP-XE0=.a40d29be-77be-4719-a0a0-71d032eea1e5@github.com>
Message-ID: <zMo8OEhYAKUz5LWOssEWEUQDoySJo7hsL7_KAzfNU34=.2309b7bb-5e1d-47e8-b932-aedfbce71e5b@github.com>

> Hi all,
> When -Xcomp be used, this testcase will use more codecaches, causing the GC to be triggered early, then causing this test failed on LoongArch64 architecture.
> 
> This PR fix the issue, Please help review it.
> 
> Thanks.

SUN Guoyun has updated the pull request incrementally with one additional commit since the last revision:

  8301737: java/rmi/server/UnicastRemoteObject/serialFilter/FilterUROTest.java fail with -Xcomp

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12399/files
  - new: https://git.openjdk.org/jdk/pull/12399/files/650c8163..06559478

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

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

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

From cstein at openjdk.org  Tue Feb  7 08:36:44 2023
From: cstein at openjdk.org (Christian Stein)
Date: Tue, 7 Feb 2023 08:36:44 GMT
Subject: RFR: 8301767: Convert virtual thread tests to JUnit
In-Reply-To: <37UDjOGF9PZxUiP2BwkrfIKh82vQgdvA8pwxaln4pl8=.5f368aea-d8a2-4e4a-a6ae-4376e1f05c9b@github.com>
References: <37UDjOGF9PZxUiP2BwkrfIKh82vQgdvA8pwxaln4pl8=.5f368aea-d8a2-4e4a-a6ae-4376e1f05c9b@github.com>
Message-ID: <jMwCmrAMI9A0RLUzlt41fT8KOMhFLA_ym9der9ZH2Yo=.ad246769-d203-410c-b30a-320922e1c540@github.com>

On Sat, 4 Feb 2023 08:59:29 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> The non-hotspot tests integrated with JEP 425/428 were mostly TestNG tests. We'd like to convert these JUnit in the main line in advance of other updates to these tests in 21.  The changes are mostly mechanical and trivial:
> 
> - BeforeClass/AfterClass changed to static BeforeAll/AfterAll methods
> - Tests using data providers are changed to parameterized tests
> - The order of the parameters to assertEquals are swapped so that the expected result is the first parameter
> - Usages of expectThrows are changed to assertThrows
> - Tests that threw SkipException are changed to the Assumptions API
> 
> There are a small number of drive-by changes to the tests, nothing significant, e.g.
> 
> - GetStackTrace and ParkWithFixedThreadPool changed from "@run testng" to "@run main" as they aren't TestNG tests.
> - A few of the tests in StructuredTaskScopeTest for joinXXX are changed to use a CountDownLatch rather than sleeping, as the original tests weren't very robust.

Marked as reviewed by cstein (Committer).

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

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

From duke at openjdk.org  Tue Feb  7 08:41:43 2023
From: duke at openjdk.org (SUN Guoyun)
Date: Tue, 7 Feb 2023 08:41:43 GMT
Subject: RFR: 8301736:
 jdk/incubator/concurrent/StructuredTaskScope/StructuredTaskScopeTest.java fail
 with -Xcomp [v2]
In-Reply-To: <5Eef3Ky4IVsBoJXsf5frxckrHifV-gJhNapvjiWcoKc=.90425d68-79cb-462b-884e-77c50699d45e@github.com>
References: <VhsVSI7-pYyffYNvgIrla6sTwX6WFuntg-QBGWPy3tw=.38aad54b-0cbe-4d0d-b732-776ff2effb7c@github.com>
 <5Eef3Ky4IVsBoJXsf5frxckrHifV-gJhNapvjiWcoKc=.90425d68-79cb-462b-884e-77c50699d45e@github.com>
Message-ID: <sajkBXHlg6RFzWo2Fie46b3TopRa-OXphby2-fe96bk=.6d80f310-8c65-440c-a95a-9a8d4e7f3d6f@github.com>

On Fri, 3 Feb 2023 07:59:25 GMT, SUN Guoyun <duke at openjdk.org> wrote:

>> Hi all,
>> When `-Xcomp` be used, java thread to block for longer, then causing StructuredTaskScopeTest.java failed frequently on the AArch64 and LoongArch64 architecture.
>> 
>> This PR fix the issue, Please help review it.
>> 
>> Thanks.
>
> SUN Guoyun has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8301736: jdk/incubator/concurrent/StructuredTaskScope/StructuredTaskScopeTest.java fail with -Xcomp

@DamonFool  Could you please sponsor it for me?

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

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

From alanb at openjdk.org  Tue Feb  7 08:48:42 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 7 Feb 2023 08:48:42 GMT
Subject: RFR: 8301736:
 jdk/incubator/concurrent/StructuredTaskScope/StructuredTaskScopeTest.java fail
 with -Xcomp [v2]
In-Reply-To: <sajkBXHlg6RFzWo2Fie46b3TopRa-OXphby2-fe96bk=.6d80f310-8c65-440c-a95a-9a8d4e7f3d6f@github.com>
References: <VhsVSI7-pYyffYNvgIrla6sTwX6WFuntg-QBGWPy3tw=.38aad54b-0cbe-4d0d-b732-776ff2effb7c@github.com>
 <5Eef3Ky4IVsBoJXsf5frxckrHifV-gJhNapvjiWcoKc=.90425d68-79cb-462b-884e-77c50699d45e@github.com>
 <sajkBXHlg6RFzWo2Fie46b3TopRa-OXphby2-fe96bk=.6d80f310-8c65-440c-a95a-9a8d4e7f3d6f@github.com>
Message-ID: <Kb645gSk84Pep9ajtitMv2v4KalxIrXeRoVMA3wev68=.ec772634-a986-4961-92df-a0997543dae3@github.com>

On Tue, 7 Feb 2023 08:39:13 GMT, SUN Guoyun <duke at openjdk.org> wrote:

> @DamonFool Could you please sponsor it for me?

Note that the problematic sleep in the joinXXX tests will be replaced if [PR 12426](https://github.com/openjdk/jdk/pull/12426) is integrated.

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

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

From jiefu at openjdk.org  Tue Feb  7 09:19:57 2023
From: jiefu at openjdk.org (Jie Fu)
Date: Tue, 7 Feb 2023 09:19:57 GMT
Subject: RFR: 8301736:
 jdk/incubator/concurrent/StructuredTaskScope/StructuredTaskScopeTest.java fail
 with -Xcomp [v2]
In-Reply-To: <Kb645gSk84Pep9ajtitMv2v4KalxIrXeRoVMA3wev68=.ec772634-a986-4961-92df-a0997543dae3@github.com>
References: <VhsVSI7-pYyffYNvgIrla6sTwX6WFuntg-QBGWPy3tw=.38aad54b-0cbe-4d0d-b732-776ff2effb7c@github.com>
 <5Eef3Ky4IVsBoJXsf5frxckrHifV-gJhNapvjiWcoKc=.90425d68-79cb-462b-884e-77c50699d45e@github.com>
 <sajkBXHlg6RFzWo2Fie46b3TopRa-OXphby2-fe96bk=.6d80f310-8c65-440c-a95a-9a8d4e7f3d6f@github.com>
 <Kb645gSk84Pep9ajtitMv2v4KalxIrXeRoVMA3wev68=.ec772634-a986-4961-92df-a0997543dae3@github.com>
Message-ID: <xA8w5fqKXaOV_P6D0Jk0nGYxmV3rqtzBcwXlKp4el-8=.eb291af0-efd0-4dc3-9e0a-88ad943b7f10@github.com>

On Tue, 7 Feb 2023 08:45:49 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> It's okay if your change goes first of course, it's just that I hope to replace these sleeps to make the tests more robust.

So just sponsor it.

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

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

From duke at openjdk.org  Tue Feb  7 09:19:59 2023
From: duke at openjdk.org (SUN Guoyun)
Date: Tue, 7 Feb 2023 09:19:59 GMT
Subject: Integrated: 8301736:
 jdk/incubator/concurrent/StructuredTaskScope/StructuredTaskScopeTest.java fail
 with -Xcomp
In-Reply-To: <VhsVSI7-pYyffYNvgIrla6sTwX6WFuntg-QBGWPy3tw=.38aad54b-0cbe-4d0d-b732-776ff2effb7c@github.com>
References: <VhsVSI7-pYyffYNvgIrla6sTwX6WFuntg-QBGWPy3tw=.38aad54b-0cbe-4d0d-b732-776ff2effb7c@github.com>
Message-ID: <Q7l3EfQCmQBJiEwdBP4BO8mXVSaWiAq8rTOJUIMl9Cs=.ad84b4a8-9100-4ce1-a644-c0383cd25abb@github.com>

On Fri, 3 Feb 2023 03:19:05 GMT, SUN Guoyun <duke at openjdk.org> wrote:

> Hi all,
> When `-Xcomp` be used, java thread to block for longer, then causing StructuredTaskScopeTest.java failed frequently on the AArch64 and LoongArch64 architecture.
> 
> This PR fix the issue, Please help review it.
> 
> Thanks.

This pull request has now been integrated.

Changeset: 1aaf394b
Author:    sunguoyun <sunguoyun at loongson.cn>
Committer: Jie Fu <jiefu at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/1aaf394b33da750803a54df84c6548717e78ea30
Stats:     2 lines in 1 file changed: 0 ins; 0 del; 2 mod

8301736: jdk/incubator/concurrent/StructuredTaskScope/StructuredTaskScopeTest.java fail with -Xcomp

Reviewed-by: alanb

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

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

From djelinski at openjdk.org  Tue Feb  7 09:38:13 2023
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Tue, 7 Feb 2023 09:38:13 GMT
Subject: RFR: 8301214: Adjust handshakeTimeout value in test
 HandshakeTimeout.java after 8189338 [v2]
In-Reply-To: <lNI2dGqbIvao8fiOOkCZQeOflJ2pNq1099RZZvo_bnc=.ba51e479-f21a-4594-b2b0-4ab5dd24d896@github.com>
References: <lNI2dGqbIvao8fiOOkCZQeOflJ2pNq1099RZZvo_bnc=.ba51e479-f21a-4594-b2b0-4ab5dd24d896@github.com>
Message-ID: <dgdSwVg67xeZXeEsLzTGhoDrwke6P4XXD1mP6AAe-9k=.ad755037-43b4-4cc1-8c9a-6e3149c5031a@github.com>

> Please review this patch that reduces the socket timeout used in HandshakeTimeout test to its minimum value of 1 millisecond.
> 
> This change makes the test complete 10 seconds faster; before this change it took 5 seconds for the handshake to timeout, and the test attempts 2 handshakes.
> 
> The change also makes the test more likely to pass when it has to compete with other tests for CPU time.

Daniel Jeli?ski 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:

 - Restructure test
 - Merge remote-tracking branch 'origin' into rmi-test-timeout
 - Reduce socket timeout

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12292/files
  - new: https://git.openjdk.org/jdk/pull/12292/files/8bad1d87..eaacd1e4

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

  Stats: 16832 lines in 640 files changed: 7781 ins; 4227 del; 4824 mod
  Patch: https://git.openjdk.org/jdk/pull/12292.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12292/head:pull/12292

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

From xgong at openjdk.org  Tue Feb  7 09:51:19 2023
From: xgong at openjdk.org (Xiaohong Gong)
Date: Tue, 7 Feb 2023 09:51:19 GMT
Subject: RFR: 8293198: [vectorapi] Improve the implementation of
 VectorMask.indexInRange() [v3]
In-Reply-To: <fN58bi3n01tqWpG0-jjUPZQe8hmls2GQ5X3NL2o1RPg=.80e7965d-50af-4fac-bd7c-0a2b99cffe7e@github.com>
References: <fN58bi3n01tqWpG0-jjUPZQe8hmls2GQ5X3NL2o1RPg=.80e7965d-50af-4fac-bd7c-0a2b99cffe7e@github.com>
Message-ID: <LkFyD4yv4dzpVbmsZEINxFyqWLrBFYDXoXFVcyBVR2g=.e333fbd3-6c4c-43f7-860b-136bf247488a@github.com>

> The Vector API `"indexInRange(int offset, int limit)"` is used
> to compute a vector mask whose lanes are set to true if the
> index of the lane is inside the range specified by the `"offset"`
> and `"limit"` arguments, otherwise the lanes are set to false.
> 
> There are two special cases for this API:
>  1) If `"offset >= 0 && offset >= limit"`, all the lanes of the
> generated mask are false.
>  2) If` "offset >= 0 && limit - offset >= vlength"`, all the
> lanes of the generated mask are true. Note that `"vlength"` is
> the number of vector lanes.
> 
> For such special cases, we can simply use `"maskAll(false|true)"`
> to implement the API. Otherwise, the original comparison with
> `"iota" `vector is needed. And for further optimization, we have
> optimal instruction supported by SVE (i.e. whilelo [1]), which
> can implement the API directly if the `"offset >= 0"`.
> 
> As a summary, to optimize the API, we can use the if-else branches
> to handle the specific cases in java level and intrinsify the
> remaining case by C2 compiler:
> 
> 
>   public VectorMask<E> indexInRange(int offset, int limit) {
>       if (offset < 0) {
>           return this.and(indexInRange0Helper(offset, limit));
>       } else if (offset >= limit) {
>           return this.and(vectorSpecies().maskAll(false));
>       } else if (limit - offset >= length()) {
>           return this.and(vectorSpecies().maskAll(true));
>       }
>       return this.and(indexInRange0(offset, limit));
>  }
> 
> 
> The last part (i.e. `"indexInRange0"`) in the above implementation
> is expected to be intrinsified by C2 compiler if the necessary IRs
> are supported. Otherwise, it will fall back to the original API
> implementation (i.e. `"indexInRange0Helper"`). Regarding to the
> intrinsifaction, the compiler will generate `"VectorMaskGen"` IR
> with "limit - offset" as the input if the current platform supports
> it. Otherwise, it generates `"VectorLoadConst + VectorMaskCmp"` based
> on `"iota < limit - offset"`.
> 
> For the following java code which uses `"indexInRange"`:
> 
> 
> static final VectorSpecies<Double> SPECIES =
>                                    DoubleVector.SPECIES_PREFERRED;
> static final int LENGTH = 1027;
> 
> public static double[] da;
> public static double[] db;
> public static double[] dc;
> 
> private static void func() {
>     for (int i = 0; i < LENGTH; i += SPECIES.length()) {
>         var m = SPECIES.indexInRange(i, LENGTH);
>         var av = DoubleVector.fromArray(SPECIES, da, i, m);
>         av.lanewise(VectorOperators.NEG).intoArray(dc, i, m);
>     }
> }
> 
> 
> The core code generated with SVE 256-bit vector size is:
> 
> 
>   ptrue   p2.d                  ; maskAll(true)
>   ...
> LOOP:
>   ...
>   sub     w11, w13, w14         ; limit - offset
>   cmp     w14, w13
>   b.cs    LABEL-1               ; if (offset >= limit) => uncommon-trap
>   cmp     w11, #0x4
>   b.lt    LABEL-2               ; if (limit - offset < vlength)
>   mov     p1.b, p2.b
> LABEL-3:
>   ld1d    {z16.d}, p1/z, [x10]  ; load vector masked
>   ...
>   cmp     w14, w29
>   b.cc    LOOP
>   ...
> LABEL-2:
>   whilelo p1.d, x16, x10        ; VectorMaskGen
>   ...
>   b       LABEL-3
>   ...
> LABEL-1:
>   uncommon-trap
> 
> 
> Please note that if the array size `LENGTH` is aligned with
> the vector size 256 (i.e. `LENGTH = 1024`), the branch "LABEL-2"
> will be optimized out by compiler and it becomes another
> uncommon-trap.
> 
> For NEON, the main CFG is the same with above. But the compiler
> intrinsification is different. Here is the code:
> 
> 
>   sub     x10, x10, x12          ; limit - offset
>   scvtf   d16, x10
>   dup     v16.2d, v16.d[0]       ; replicateD
> 
>   mov     x8, #0xd8d0
>   movk    x8, #0x84cb, lsl #16
>   movk    x8, #0xffff, lsl #32
>   ldr     q17, [x8], #0          ; load the "iota" const vector
>   fcmgt   v18.2d, v16.2d, v17.2d ; mask = iota < limit - offset
> 
> 
> Here is the performance data of the new added benchmark on an ARM
> SVE 256-bit platform:
> 
> 
> Benchmark                               (size)  Before    After   Units
> IndexInRangeBenchmark.byteIndexInRange   1024 11203.697 41404.431 ops/ms
> IndexInRangeBenchmark.byteIndexInRange   1027  2365.920  8747.004 ops/ms
> IndexInRangeBenchmark.doubleIndexInRange 1024  1227.505  6092.194 ops/ms
> IndexInRangeBenchmark.doubleIndexInRange 1027   351.215  1156.683 ops/ms
> IndexInRangeBenchmark.floatIndexInRange  1024  1468.876 11032.580 ops/ms
> IndexInRangeBenchmark.floatIndexInRange  1027   699.645  2439.671 ops/ms
> IndexInRangeBenchmark.intIndexInRange    1024  2842.187 11903.544 ops/ms
> IndexInRangeBenchmark.intIndexInRange    1027   689.866  2547.424 ops/ms
> IndexInRangeBenchmark.longIndexInRange   1024  1394.135  5902.973 ops/ms
> IndexInRangeBenchmark.longIndexInRange   1027   355.621  1189.458 ops/ms
> IndexInRangeBenchmark.shortIndexInRange  1024  5521.468 21578.340 ops/ms
> IndexInRangeBenchmark.shortIndexInRange  1027  1264.816  4640.504 ops/ms
> 
> 
> And the performance data with ARM NEON:
> 
> 
> Benchmark                               (size)  Before    After   Units
> IndexInRangeBenchmark.byteIndexInRange   1024  4026.548 15562.880 ops/ms
> IndexInRangeBenchmark.byteIndexInRange   1027   305.314   576.559 ops/ms
> IndexInRangeBenchmark.doubleIndexInRange 1024   289.224  2244.080 ops/ms
> IndexInRangeBenchmark.doubleIndexInRange 1027    39.740    76.499 ops/ms
> IndexInRangeBenchmark.floatIndexInRange  1024   675.264  4457.470 ops/ms
> IndexInRangeBenchmark.floatIndexInRange  1027    79.918   144.952 ops/ms
> IndexInRangeBenchmark.intIndexInRange    1024   740.139  4014.583 ops/ms
> IndexInRangeBenchmark.intIndexInRange    1027    78.608   147.903 ops/ms
> IndexInRangeBenchmark.longIndexInRange   1024   400.683  2209.551 ops/ms
> IndexInRangeBenchmark.longIndexInRange   1027    41.146    69.599 ops/ms
> IndexInRangeBenchmark.shortIndexInRange  1024  1821.736  8153.546 ops/ms
> IndexInRangeBenchmark.shortIndexInRange  1027   158.810   243.205 ops/ms
> 
> 
> The performance improves about `3.5x ~ 7.5x` on the vector size aligned
> (1024 size) benchmarks both with NEON and SVE. And it improves about
> `3.5x/1.8x` on the vector size not aligned (1027 size) benchmarks with
> SVE/NEON respectively. We can also observe the similar improvement on
> the x86 platforms.
> 
> [1] https://developer.arm.com/documentation/ddi0596/2020-12/SVE-Instructions/WHILELO--While-incrementing-unsigned-scalar-lower-than-scalar-

Xiaohong Gong has updated the pull request incrementally with one additional commit since the last revision:

  Rename the indexInRange API and simply the benchmarks

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12064/files
  - new: https://git.openjdk.org/jdk/pull/12064/files/9388e29d..d6558e30

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

  Stats: 179 lines in 39 files changed: 14 ins; 46 del; 119 mod
  Patch: https://git.openjdk.org/jdk/pull/12064.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12064/head:pull/12064

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

From xgong at openjdk.org  Tue Feb  7 09:54:45 2023
From: xgong at openjdk.org (Xiaohong Gong)
Date: Tue, 7 Feb 2023 09:54:45 GMT
Subject: RFR: 8293198: [vectorapi] Improve the implementation of
 VectorMask.indexInRange() [v3]
In-Reply-To: <LkFyD4yv4dzpVbmsZEINxFyqWLrBFYDXoXFVcyBVR2g=.e333fbd3-6c4c-43f7-860b-136bf247488a@github.com>
References: <fN58bi3n01tqWpG0-jjUPZQe8hmls2GQ5X3NL2o1RPg=.80e7965d-50af-4fac-bd7c-0a2b99cffe7e@github.com>
 <LkFyD4yv4dzpVbmsZEINxFyqWLrBFYDXoXFVcyBVR2g=.e333fbd3-6c4c-43f7-860b-136bf247488a@github.com>
Message-ID: <GQ5bF_v-9LpAMCAGN4E0-54saK4GvWSJnMC7FQAxxUw=.daf1a468-8835-447b-b658-dd7f947c237f@github.com>

On Tue, 7 Feb 2023 09:51:19 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

>> The Vector API `"indexInRange(int offset, int limit)"` is used
>> to compute a vector mask whose lanes are set to true if the
>> index of the lane is inside the range specified by the `"offset"`
>> and `"limit"` arguments, otherwise the lanes are set to false.
>> 
>> There are two special cases for this API:
>>  1) If `"offset >= 0 && offset >= limit"`, all the lanes of the
>> generated mask are false.
>>  2) If` "offset >= 0 && limit - offset >= vlength"`, all the
>> lanes of the generated mask are true. Note that `"vlength"` is
>> the number of vector lanes.
>> 
>> For such special cases, we can simply use `"maskAll(false|true)"`
>> to implement the API. Otherwise, the original comparison with
>> `"iota" `vector is needed. And for further optimization, we have
>> optimal instruction supported by SVE (i.e. whilelo [1]), which
>> can implement the API directly if the `"offset >= 0"`.
>> 
>> As a summary, to optimize the API, we can use the if-else branches
>> to handle the specific cases in java level and intrinsify the
>> remaining case by C2 compiler:
>> 
>> 
>>   public VectorMask<E> indexInRange(int offset, int limit) {
>>       if (offset < 0) {
>>           return this.and(indexInRange0Helper(offset, limit));
>>       } else if (offset >= limit) {
>>           return this.and(vectorSpecies().maskAll(false));
>>       } else if (limit - offset >= length()) {
>>           return this.and(vectorSpecies().maskAll(true));
>>       }
>>       return this.and(indexInRange0(offset, limit));
>>  }
>> 
>> 
>> The last part (i.e. `"indexInRange0"`) in the above implementation
>> is expected to be intrinsified by C2 compiler if the necessary IRs
>> are supported. Otherwise, it will fall back to the original API
>> implementation (i.e. `"indexInRange0Helper"`). Regarding to the
>> intrinsifaction, the compiler will generate `"VectorMaskGen"` IR
>> with "limit - offset" as the input if the current platform supports
>> it. Otherwise, it generates `"VectorLoadConst + VectorMaskCmp"` based
>> on `"iota < limit - offset"`.
>> 
>> For the following java code which uses `"indexInRange"`:
>> 
>> 
>> static final VectorSpecies<Double> SPECIES =
>>                                    DoubleVector.SPECIES_PREFERRED;
>> static final int LENGTH = 1027;
>> 
>> public static double[] da;
>> public static double[] db;
>> public static double[] dc;
>> 
>> private static void func() {
>>     for (int i = 0; i < LENGTH; i += SPECIES.length()) {
>>         var m = SPECIES.indexInRange(i, LENGTH);
>>         var av = DoubleVector.fromArray(SPECIES, da, i, m);
>>         av.lanewise(VectorOperators.NEG).intoArray(dc, i, m);
>>     }
>> }
>> 
>> 
>> The core code generated with SVE 256-bit vector size is:
>> 
>> 
>>   ptrue   p2.d                  ; maskAll(true)
>>   ...
>> LOOP:
>>   ...
>>   sub     w11, w13, w14         ; limit - offset
>>   cmp     w14, w13
>>   b.cs    LABEL-1               ; if (offset >= limit) => uncommon-trap
>>   cmp     w11, #0x4
>>   b.lt    LABEL-2               ; if (limit - offset < vlength)
>>   mov     p1.b, p2.b
>> LABEL-3:
>>   ld1d    {z16.d}, p1/z, [x10]  ; load vector masked
>>   ...
>>   cmp     w14, w29
>>   b.cc    LOOP
>>   ...
>> LABEL-2:
>>   whilelo p1.d, x16, x10        ; VectorMaskGen
>>   ...
>>   b       LABEL-3
>>   ...
>> LABEL-1:
>>   uncommon-trap
>> 
>> 
>> Please note that if the array size `LENGTH` is aligned with
>> the vector size 256 (i.e. `LENGTH = 1024`), the branch "LABEL-2"
>> will be optimized out by compiler and it becomes another
>> uncommon-trap.
>> 
>> For NEON, the main CFG is the same with above. But the compiler
>> intrinsification is different. Here is the code:
>> 
>> 
>>   sub     x10, x10, x12          ; limit - offset
>>   scvtf   d16, x10
>>   dup     v16.2d, v16.d[0]       ; replicateD
>> 
>>   mov     x8, #0xd8d0
>>   movk    x8, #0x84cb, lsl #16
>>   movk    x8, #0xffff, lsl #32
>>   ldr     q17, [x8], #0          ; load the "iota" const vector
>>   fcmgt   v18.2d, v16.2d, v17.2d ; mask = iota < limit - offset
>> 
>> 
>> Here is the performance data of the new added benchmark on an ARM
>> SVE 256-bit platform:
>> 
>> 
>> Benchmark                               (size)  Before    After   Units
>> IndexInRangeBenchmark.byteIndexInRange   1024 11203.697 41404.431 ops/ms
>> IndexInRangeBenchmark.byteIndexInRange   1027  2365.920  8747.004 ops/ms
>> IndexInRangeBenchmark.doubleIndexInRange 1024  1227.505  6092.194 ops/ms
>> IndexInRangeBenchmark.doubleIndexInRange 1027   351.215  1156.683 ops/ms
>> IndexInRangeBenchmark.floatIndexInRange  1024  1468.876 11032.580 ops/ms
>> IndexInRangeBenchmark.floatIndexInRange  1027   699.645  2439.671 ops/ms
>> IndexInRangeBenchmark.intIndexInRange    1024  2842.187 11903.544 ops/ms
>> IndexInRangeBenchmark.intIndexInRange    1027   689.866  2547.424 ops/ms
>> IndexInRangeBenchmark.longIndexInRange   1024  1394.135  5902.973 ops/ms
>> IndexInRangeBenchmark.longIndexInRange   1027   355.621  1189.458 ops/ms
>> IndexInRangeBenchmark.shortIndexInRange  1024  5521.468 21578.340 ops/ms
>> IndexInRangeBenchmark.shortIndexInRange  1027  1264.816  4640.504 ops/ms
>> 
>> 
>> And the performance data with ARM NEON:
>> 
>> 
>> Benchmark                               (size)  Before    After   Units
>> IndexInRangeBenchmark.byteIndexInRange   1024  4026.548 15562.880 ops/ms
>> IndexInRangeBenchmark.byteIndexInRange   1027   305.314   576.559 ops/ms
>> IndexInRangeBenchmark.doubleIndexInRange 1024   289.224  2244.080 ops/ms
>> IndexInRangeBenchmark.doubleIndexInRange 1027    39.740    76.499 ops/ms
>> IndexInRangeBenchmark.floatIndexInRange  1024   675.264  4457.470 ops/ms
>> IndexInRangeBenchmark.floatIndexInRange  1027    79.918   144.952 ops/ms
>> IndexInRangeBenchmark.intIndexInRange    1024   740.139  4014.583 ops/ms
>> IndexInRangeBenchmark.intIndexInRange    1027    78.608   147.903 ops/ms
>> IndexInRangeBenchmark.longIndexInRange   1024   400.683  2209.551 ops/ms
>> IndexInRangeBenchmark.longIndexInRange   1027    41.146    69.599 ops/ms
>> IndexInRangeBenchmark.shortIndexInRange  1024  1821.736  8153.546 ops/ms
>> IndexInRangeBenchmark.shortIndexInRange  1027   158.810   243.205 ops/ms
>> 
>> 
>> The performance improves about `3.5x ~ 7.5x` on the vector size aligned
>> (1024 size) benchmarks both with NEON and SVE. And it improves about
>> `3.5x/1.8x` on the vector size not aligned (1027 size) benchmarks with
>> SVE/NEON respectively. We can also observe the similar improvement on
>> the x86 platforms.
>> 
>> [1] https://developer.arm.com/documentation/ddi0596/2020-12/SVE-Instructions/WHILELO--While-incrementing-unsigned-scalar-lower-than-scalar-
>
> Xiaohong Gong has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rename the indexInRange API and simply the benchmarks

Hi Paul,

I updated the API name as you suggested and simply the benchmarks by removing the calling to masked `fromArray()/intoArray()` APIs.

Here are the benchmark result compared with jdk/master with ARM NEON:

Benchmark                                (size)  Mode  Cnt    Before    After    Units
IndexInRangeBenchmark.byteIndexInRange       7  thrpt   5  164957.447 188954.757 ops/ms
IndexInRangeBenchmark.byteIndexInRange     256  thrpt   5   28373.131  60895.091 ops/ms
IndexInRangeBenchmark.byteIndexInRange     259  thrpt   5   28290.365  55573.807 ops/ms
IndexInRangeBenchmark.byteIndexInRange     512  thrpt   5   15695.618  49147.370 ops/ms
IndexInRangeBenchmark.doubleIndexInRange     7  thrpt   5   58926.711  87837.117 ops/ms
IndexInRangeBenchmark.doubleIndexInRange   256  thrpt   5    2558.505  17795.100 ops/ms
IndexInRangeBenchmark.doubleIndexInRange   259  thrpt   5    2521.995   5309.487 ops/ms
IndexInRangeBenchmark.doubleIndexInRange   512  thrpt   5    1289.556   8882.959 ops/ms
IndexInRangeBenchmark.floatIndexInRange      7  thrpt   5  113429.518 114530.506 ops/ms
IndexInRangeBenchmark.floatIndexInRange    256  thrpt   5    5681.129  31686.156 ops/ms
IndexInRangeBenchmark.floatIndexInRange    259  thrpt   5    5614.762  13659.272 ops/ms
IndexInRangeBenchmark.floatIndexInRange    512  thrpt   5    2897.391  17796.357 ops/ms
IndexInRangeBenchmark.intIndexInRange        7  thrpt   5   50990.391 125139.575 ops/ms
IndexInRangeBenchmark.intIndexInRange      256  thrpt   5    8444.632  31090.867 ops/ms
IndexInRangeBenchmark.intIndexInRange      259  thrpt   5    8349.075  20258.705 ops/ms
IndexInRangeBenchmark.intIndexInRange      512  thrpt   5    4525.218  17555.370 ops/ms
IndexInRangeBenchmark.longIndexInRange       7  thrpt   5   77003.438  89592.650 ops/ms
IndexInRangeBenchmark.longIndexInRange     256  thrpt   5    3669.537  17455.742 ops/ms
IndexInRangeBenchmark.longIndexInRange     259  thrpt   5    3672.086  11150.989 ops/ms
IndexInRangeBenchmark.longIndexInRange     512  thrpt   5    1883.831   8832.311 ops/ms
IndexInRangeBenchmark.shortIndexInRange      7  thrpt   5  159881.634 185593.426 ops/ms
IndexInRangeBenchmark.shortIndexInRange    256  thrpt   5   16762.736  50486.836 ops/ms
IndexInRangeBenchmark.shortIndexInRange    259  thrpt   5   16490.397  35110.418 ops/ms
IndexInRangeBenchmark.shortIndexInRange    512  thrpt   5    8815.322  31113.907 ops/ms

And the result with SVE 512-bit vector size:

Benchmark                                (size)  Mode  Cnt   Before    After     Units
IndexInRangeBenchmark.byteIndexInRange       7  thrpt   5  48977.004  62712.3874 ops/ms
IndexInRangeBenchmark.byteIndexInRange     256  thrpt   5  28005.444  36067.6281 ops/ms
IndexInRangeBenchmark.byteIndexInRange     259  thrpt   5  26833.661  33337.5660 ops/ms
IndexInRangeBenchmark.byteIndexInRange     512  thrpt   5  18621.850  26251.4372 ops/ms
IndexInRangeBenchmark.doubleIndexInRange     7  thrpt   5  31556.967  63184.8951 ops/ms
IndexInRangeBenchmark.doubleIndexInRange   256  thrpt   5   4394.624  22536.9730 ops/ms
IndexInRangeBenchmark.doubleIndexInRange   259  thrpt   5   4390.727  13714.7822 ops/ms
IndexInRangeBenchmark.doubleIndexInRange   512  thrpt   5   2358.633  15654.2022 ops/ms
IndexInRangeBenchmark.floatIndexInRange      7  thrpt   5  31507.582  62985.8334 ops/ms
IndexInRangeBenchmark.floatIndexInRange    256  thrpt   5   7873.270  25331.0291 ops/ms
IndexInRangeBenchmark.floatIndexInRange    259  thrpt   5   7733.960  22011.2921 ops/ms
IndexInRangeBenchmark.floatIndexInRange    512  thrpt   5   4392.090  21542.3555 ops/ms
IndexInRangeBenchmark.intIndexInRange        7  thrpt   5  55291.415  62846.4699 ops/ms
IndexInRangeBenchmark.intIndexInRange      256  thrpt   5  12580.224  25637.0236 ops/ms
IndexInRangeBenchmark.intIndexInRange      259  thrpt   5  12815.614  23283.9921 ops/ms
IndexInRangeBenchmark.intIndexInRange      512  thrpt   5   7737.667  21611.9642 ops/ms
IndexInRangeBenchmark.longIndexInRange       7  thrpt   5  46632.264  63072.6243 ops/ms
IndexInRangeBenchmark.longIndexInRange     256  thrpt   5   6664.042  22541.1474 ops/ms
IndexInRangeBenchmark.longIndexInRange     259  thrpt   5   6294.857  16994.0206 ops/ms
IndexInRangeBenchmark.longIndexInRange     512  thrpt   5   3446.688  15689.5675 ops/ms
IndexInRangeBenchmark.shortIndexInRange      7  thrpt   5  43243.398  63971.3060 ops/ms
IndexInRangeBenchmark.shortIndexInRange    256  thrpt   5  17997.651  27081.8088 ops/ms
IndexInRangeBenchmark.shortIndexInRange    259  thrpt   5  16572.132  30804.5928 ops/ms
IndexInRangeBenchmark.shortIndexInRange    512  thrpt   5  10211.183  21771.9652 ops/ms


Similar gains can also be observed on x86 different systems. From the result, we can see the performance doesn't have too much gap between the 256/259 array sizes.

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

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

From djelinski at openjdk.org  Tue Feb  7 10:02:55 2023
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Tue, 7 Feb 2023 10:02:55 GMT
Subject: RFR: 8301214: Adjust handshakeTimeout value in test
 HandshakeTimeout.java after 8189338 [v2]
In-Reply-To: <dgdSwVg67xeZXeEsLzTGhoDrwke6P4XXD1mP6AAe-9k=.ad755037-43b4-4cc1-8c9a-6e3149c5031a@github.com>
References: <lNI2dGqbIvao8fiOOkCZQeOflJ2pNq1099RZZvo_bnc=.ba51e479-f21a-4594-b2b0-4ab5dd24d896@github.com>
 <dgdSwVg67xeZXeEsLzTGhoDrwke6P4XXD1mP6AAe-9k=.ad755037-43b4-4cc1-8c9a-6e3149c5031a@github.com>
Message-ID: <uLAl9TVoymr5LL9b24oIebN2Jx_SNhWx1b6kh2Emq5c=.f2604a33-df65-4513-81e8-92333f66fc07@github.com>

On Tue, 7 Feb 2023 09:38:13 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> Please review this patch that reduces the socket timeout used in HandshakeTimeout test to its minimum value of 1 millisecond.
>> 
>> This change makes the test complete 10 seconds faster; before this change it took 5 seconds for the handshake to timeout, and the test attempts 2 handshakes.
>> 
>> The change also makes the test more likely to pass when it has to compete with other tests for CPU time.
>
> Daniel Jeli?ski 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:
> 
>  - Restructure test
>  - Merge remote-tracking branch 'origin' into rmi-test-timeout
>  - Reduce socket timeout

The original motivation to touch this test was that the SSL version timed out; the handshake timeout was too long in proportion to the test timeout, which was fixed at 10 seconds (see `TIMEOUT` constant).
The `sun.rmi.transport.tcp.handshakeTimeout` property only applies to a single network operation in the current implementation. SSL part of the handshake (client hello/key share generation) does not count towards the timeout, and if there are multiple network operations (e.g. when doing SSL handshake we first write to the socket, then read from it), each operation can use the full timeout value.

The purpose of this test is to verify that the handshake does not block forever (JDK-4322806 was for plain handshake, JDK-8189338 was for SSL handshake). After my changes the test still does that; without the fixes for the above bugs, the test times out.

Thanks for the restructuring suggestion. I modified the test to run in a single thread. Test timeout is now handled by JTReg timeout handler, which means that 1) we will have a thread dump when that happens, 2) timeout factor will be used in timeout calculations.

Let me know if that addresses your concerns.

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

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

From tvaleev at openjdk.org  Tue Feb  7 10:16:35 2023
From: tvaleev at openjdk.org (Tagir F. Valeev)
Date: Tue, 7 Feb 2023 10:16:35 GMT
Subject: RFR: 8301226: Add clamp() methods to java.lang.Math and to
 StrictMath [v5]
In-Reply-To: <c7kJhZvT8oz5hScMxnWI23H7wjCaJ854ajjSRtxBnW4=.3f4e24ca-c608-4541-b80e-cf3452ec6400@github.com>
References: <c7kJhZvT8oz5hScMxnWI23H7wjCaJ854ajjSRtxBnW4=.3f4e24ca-c608-4541-b80e-cf3452ec6400@github.com>
Message-ID: <pDDEuk5mhBnuXaJX3Fh3VB0xRYJXaX_095LXuB2FHKI=.1fc8c870-39c4-4607-8bc7-be983272cd62@github.com>

> clamp() methods added to Math and StrictMath
> 
> `int clamp(long, int, int)` is somewhat different, as it accepts a `long` value and safely clamps it to an `int` range. Other overloads work with a particular type (long, float and double). Using similar approach in other cases (e.g. `float clamp(double, float, float)`) may cause accidental precision loss even if the value is within range, so I decided to avoid this.
> 
> In all cases, `max >= min` precondition should met. For double and float we additionally order `-0.0 < 0.0`, similarly to what Math.max or Double.compare do. In double and float overloads I try to keep at most one arg-check comparison on common path, so the order of checks might look unusual.
> 
> For tests, I noticed that tests in java/lang/Math don't use any testing framework (even newer tests), so I somehow mimic the approach of neighbour tests.

Tagir F. Valeev has updated the pull request incrementally with two additional commits since the last revision:

 - Tests refactoring
 - More clarifying comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12428/files
  - new: https://git.openjdk.org/jdk/pull/12428/files/065018f4..b758b8db

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

  Stats: 220 lines in 2 files changed: 84 ins; 36 del; 100 mod
  Patch: https://git.openjdk.org/jdk/pull/12428.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12428/head:pull/12428

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

From tvaleev at openjdk.org  Tue Feb  7 10:24:24 2023
From: tvaleev at openjdk.org (Tagir F. Valeev)
Date: Tue, 7 Feb 2023 10:24:24 GMT
Subject: RFR: 8301226: Add clamp() methods to java.lang.Math and to
 StrictMath [v6]
In-Reply-To: <c7kJhZvT8oz5hScMxnWI23H7wjCaJ854ajjSRtxBnW4=.3f4e24ca-c608-4541-b80e-cf3452ec6400@github.com>
References: <c7kJhZvT8oz5hScMxnWI23H7wjCaJ854ajjSRtxBnW4=.3f4e24ca-c608-4541-b80e-cf3452ec6400@github.com>
Message-ID: <vlPKiqQDWJKn4Y91Gc9vOjiNBMkLsK2tNymYTR2OYKk=.ac4bd530-b665-4c6c-a61a-ff78c689fb63@github.com>

> clamp() methods added to Math and StrictMath
> 
> `int clamp(long, int, int)` is somewhat different, as it accepts a `long` value and safely clamps it to an `int` range. Other overloads work with a particular type (long, float and double). Using similar approach in other cases (e.g. `float clamp(double, float, float)`) may cause accidental precision loss even if the value is within range, so I decided to avoid this.
> 
> In all cases, `max >= min` precondition should met. For double and float we additionally order `-0.0 < 0.0`, similarly to what Math.max or Double.compare do. In double and float overloads I try to keep at most one arg-check comparison on common path, so the order of checks might look unusual.
> 
> For tests, I noticed that tests in java/lang/Math don't use any testing framework (even newer tests), so I somehow mimic the approach of neighbour tests.

Tagir F. Valeev has updated the pull request incrementally with one additional commit since the last revision:

  Whitespace fixed

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12428/files
  - new: https://git.openjdk.org/jdk/pull/12428/files/b758b8db..803ab852

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

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

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

From tvaleev at openjdk.org  Tue Feb  7 10:24:25 2023
From: tvaleev at openjdk.org (Tagir F. Valeev)
Date: Tue, 7 Feb 2023 10:24:25 GMT
Subject: RFR: 8301226: Add clamp() methods to java.lang.Math and to
 StrictMath [v4]
In-Reply-To: <WC-fFkld71Gc7paBNaPbRBjWomTq5E_Ol5muDjRrVvw=.8e859ec2-0f60-4721-96e1-33fb69e7860e@github.com>
References: <c7kJhZvT8oz5hScMxnWI23H7wjCaJ854ajjSRtxBnW4=.3f4e24ca-c608-4541-b80e-cf3452ec6400@github.com>
 <Ddvn1DCxT2qXxF7oOltTVKlnvkATfbHTuq7ZBtWWdwI=.bf25f42a-9fa0-4ee0-95a9-f0a7ab94434b@github.com>
 <WC-fFkld71Gc7paBNaPbRBjWomTq5E_Ol5muDjRrVvw=.8e859ec2-0f60-4721-96e1-33fb69e7860e@github.com>
Message-ID: <pmOHg3CcPj_PvvwtVD8FflDuJ2Uy9VOVQfPhse0ugy4=.3c0c73aa-4cee-48fc-bbc6-bc34bc6550f0@github.com>

On Tue, 7 Feb 2023 00:57:54 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Tagir F. Valeev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Added explanatory comments
>
> src/java.base/share/classes/java/lang/Math.java line 2266:
> 
>> 2264:         // If min == max, we should additionally check for +0.0/-0.0 case,
>> 2265:         // so we're still visiting the if statement.
>> 2266:         if (!(min < max)) {
> 
> A suggestion for an additional comment on this line like:
> 
> // min greater than, equal to, or unordered with respect to max; NaN values are unorded

Added, thanks!

> test/jdk/java/lang/Math/Clamp.java line 47:
> 
>> 45:     private static int testIntClamp() {
>> 46:         int failures = 0;
>> 47:         failures += checkIntClamp(0, 1, 2, 1);
> 
> Possible refactoring here: represent the test cases in, say, a 2D int array or an array/list of records and loop over them.

Updated. Is it better this way?

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

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

From duke at openjdk.org  Tue Feb  7 11:08:55 2023
From: duke at openjdk.org (SUN Guoyun)
Date: Tue, 7 Feb 2023 11:08:55 GMT
Subject: RFR: 8301736:
 jdk/incubator/concurrent/StructuredTaskScope/StructuredTaskScopeTest.java fail
 with -Xcomp [v2]
In-Reply-To: <5Eef3Ky4IVsBoJXsf5frxckrHifV-gJhNapvjiWcoKc=.90425d68-79cb-462b-884e-77c50699d45e@github.com>
References: <VhsVSI7-pYyffYNvgIrla6sTwX6WFuntg-QBGWPy3tw=.38aad54b-0cbe-4d0d-b732-776ff2effb7c@github.com>
 <5Eef3Ky4IVsBoJXsf5frxckrHifV-gJhNapvjiWcoKc=.90425d68-79cb-462b-884e-77c50699d45e@github.com>
Message-ID: <6VErS0VKRyY5OsckbOSiYXEqUOdWzHeTuyepbWuURoA=.04541495-a776-4977-99ad-cfd7e388a50a@github.com>

On Fri, 3 Feb 2023 07:59:25 GMT, SUN Guoyun <duke at openjdk.org> wrote:

>> Hi all,
>> When `-Xcomp` be used, java thread to block for longer, then causing StructuredTaskScopeTest.java failed frequently on the AArch64 and LoongArch64 architecture.
>> 
>> This PR fix the issue, Please help review it.
>> 
>> Thanks.
>
> SUN Guoyun has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8301736: jdk/incubator/concurrent/StructuredTaskScope/StructuredTaskScopeTest.java fail with -Xcomp

> > It's okay if your change goes first of course, it's just that I hope to replace these sleeps to make the tests more robust.
> 
> So just sponsor it. /sponsor

Thank you

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

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

From duke at openjdk.org  Tue Feb  7 11:14:46 2023
From: duke at openjdk.org (Amit Kumar)
Date: Tue, 7 Feb 2023 11:14:46 GMT
Subject: RFR: 8299748: java/util/zip/Deinflate.java failing on s390x [v2]
In-Reply-To: <3z7u66KVgFfL7S7S4uxDtOA6gD-WkNU7R-zon0trIVg=.d27446ca-c11d-49cc-bb85-b162e5ac58f2@github.com>
References: <Usxi4wE5GSHHv-cKPfW6OXylhieAypbsidUX_Jo6FSQ=.34104cf0-2243-478f-86ce-9a91905c6755@github.com>
 <3z7u66KVgFfL7S7S4uxDtOA6gD-WkNU7R-zon0trIVg=.d27446ca-c11d-49cc-bb85-b162e5ac58f2@github.com>
Message-ID: <Xu2V-y1c_0VVqi84PW3onpnycW2Xk62wVJB9ZvmJaBM=.c1a03cc1-d74a-4a1b-a464-381f782566a4@github.com>

On Thu, 2 Feb 2023 08:27:55 GMT, Amit Kumar <duke at openjdk.org> wrote:

>> DeInflate.java test fails on s390x platform because size for out1 array which is responsible for storing the compressed data is insufficient. And being unable to write whole compressed data on array, on s390 whole data can't be recovered after compression. So this fix increase Array size (for s390).
>
> Amit Kumar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   change acc to Alan comments

Alan, with these changes I've pasted the output below:

diff --git a/test/jdk/java/util/zip/DeInflate.java b/test/jdk/java/util/zip/DeInflate.java
index 9ad0aa5d250..eaf1fb2ba45 100644
--- a/test/jdk/java/util/zip/DeInflate.java
+++ b/test/jdk/java/util/zip/DeInflate.java
@@ -131,9 +131,14 @@ public class DeInflate {
 
         ByteArrayOutputStream baos = new ByteArrayOutputStream(len);
         while (!def.finished()) {
-            int temp_counter = def.deflate(out1);
-            m += temp_counter;
-            baos.write(out1, 0, temp_counter);
+            int remaining = out1.length - m;
+            int temp_value = def.deflate(out1, m, remaining);
+            System.out.println("compressed: " + temp_value); 
+            System.out.println("is finished: " + def.finished());
+//            if (remaining == 0) {
+//                throw new RuntimeException("out1 is small");
+//            }
+            m += temp_value;
         }
         out1 = baos.toByteArray();
         baos.reset();
@@ -142,9 +147,11 @@ public class DeInflate {
         int n = 0;
 
         while (!inf.finished()) {
-            int temp_counter = inf.inflate(out2);
-            n += temp_counter;
-            baos.write(out2, 0,  temp_counter);
+            int remaining = out2.length - n;
+            if (remaining == 0) {
+                throw new RuntimeException("out2 is small");
+            }
+            n += inf.inflate(out2, n, remaining);
         }


I'm getting this output:

level:-1, strategy: 0, dowrap: false
compressed: 524454
is finished: true
result: Failed. Execution failed: `main' threw exception: java.lang.ArrayIndexOutOfBoundsException: Range [524454, 524454 + 0) out of bounds for length 0

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

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

From rgiulietti at openjdk.org  Tue Feb  7 11:38:45 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Tue, 7 Feb 2023 11:38:45 GMT
Subject: RFR: 8301226: Add clamp() methods to java.lang.Math and to
 StrictMath [v6]
In-Reply-To: <vlPKiqQDWJKn4Y91Gc9vOjiNBMkLsK2tNymYTR2OYKk=.ac4bd530-b665-4c6c-a61a-ff78c689fb63@github.com>
References: <c7kJhZvT8oz5hScMxnWI23H7wjCaJ854ajjSRtxBnW4=.3f4e24ca-c608-4541-b80e-cf3452ec6400@github.com>
 <vlPKiqQDWJKn4Y91Gc9vOjiNBMkLsK2tNymYTR2OYKk=.ac4bd530-b665-4c6c-a61a-ff78c689fb63@github.com>
Message-ID: <MTZqRrjZ1A1vgwKzIoJdXJr5z_LwXQRStkjBgH-7pBc=.10559c9a-b13d-4398-a8d1-088e465ccdb3@github.com>

On Tue, 7 Feb 2023 10:24:24 GMT, Tagir F. Valeev <tvaleev at openjdk.org> wrote:

>> clamp() methods added to Math and StrictMath
>> 
>> `int clamp(long, int, int)` is somewhat different, as it accepts a `long` value and safely clamps it to an `int` range. Other overloads work with a particular type (long, float and double). Using similar approach in other cases (e.g. `float clamp(double, float, float)`) may cause accidental precision loss even if the value is within range, so I decided to avoid this.
>> 
>> In all cases, `max >= min` precondition should met. For double and float we additionally order `-0.0 < 0.0`, similarly to what Math.max or Double.compare do. In double and float overloads I try to keep at most one arg-check comparison on common path, so the order of checks might look unusual.
>> 
>> For tests, I noticed that tests in java/lang/Math don't use any testing framework (even newer tests), so I somehow mimic the approach of neighbour tests.
>
> Tagir F. Valeev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Whitespace fixed

test/jdk/java/lang/Math/Clamp.java line 149:

> 147:                 {-0.0, 0.0, 0.0, 0.0},
> 148:                 {0.0, 0.0, 0.0, 0.0},
> 149:                 {1.0, 0.0, 0.0, 0.0},

What about adding similar tests for the [-0.0, -0.0] interval?

test/jdk/java/lang/Math/Clamp.java line 160:

> 158:                 {0.0, Double.NaN, 0.0},
> 159:                 {Double.NaN, 1.0, 0.0},
> 160:                 {0.0, 0.0, -0.0}

Perhaps add other empty intervals, like [1.0, -1.0]

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

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

From mcimadamore at openjdk.org  Tue Feb  7 11:43:52 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 7 Feb 2023 11:43:52 GMT
Subject: RFR: 8294982: Implementation of Classfile API [v12]
In-Reply-To: <xWZSZo4TZ9iFr1eJSCmR7rd3Qw3pX78wwyjZfO79N20=.1ce95c71-7267-4f56-bd21-141301e64b6f@github.com>
References: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
 <Q4VeZ2yWAg85FqUDJa5hYq3jHty5H547gD0H-x3oIq0=.58d463a4-237a-4fee-bd0f-83262d49522a@github.com>
 <c022hrWNEHW76nhP_sXTQXCTjtL8jjM8r_yYv0IvbPI=.2a9cfbae-2fef-4cdb-8189-b869b1513fef@github.com>
 <xWZSZo4TZ9iFr1eJSCmR7rd3Qw3pX78wwyjZfO79N20=.1ce95c71-7267-4f56-bd21-141301e64b6f@github.com>
Message-ID: <8L9D0Rni2RoK0TMbTIe1QNqD_3qKqFPmCW_Hij6i8m4=.dfb7efd6-5a5a-42b1-908c-f3849970a0c7@github.com>

On Mon, 6 Feb 2023 12:41:44 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/classfile/TypeAnnotation.java line 75:
>> 
>>> 73:      * The kind of target on which the annotation appears.
>>> 74:      */
>>> 75:     public enum TargetType {
>> 
>> My IDE says this enum is not being used. I tend to believe it, since the TargetInfo sealed interface also seems to model the same thing?
>
> There is only one TargetInfo for all TargetTypes, so instead of 22 sub-interfaces of TargetInfo, the instance of TargetType enum is hold in TargetInfo.

Ok, I see that now - for some reason the IDE could not find the usage... thanks

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

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

From mcimadamore at openjdk.org  Tue Feb  7 11:51:53 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 7 Feb 2023 11:51:53 GMT
Subject: RFR: 8294982: Implementation of Classfile API [v12]
In-Reply-To: <rzZgV5Ffapr1PM-e0qssZQwGCRGpcP9jv3Ua4aUY-TQ=.2540b2e9-cc38-4dfc-9f24-a31bb1b242e9@github.com>
References: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
 <Q4VeZ2yWAg85FqUDJa5hYq3jHty5H547gD0H-x3oIq0=.58d463a4-237a-4fee-bd0f-83262d49522a@github.com>
 <c022hrWNEHW76nhP_sXTQXCTjtL8jjM8r_yYv0IvbPI=.2a9cfbae-2fef-4cdb-8189-b869b1513fef@github.com>
 <rzZgV5Ffapr1PM-e0qssZQwGCRGpcP9jv3Ua4aUY-TQ=.2540b2e9-cc38-4dfc-9f24-a31bb1b242e9@github.com>
Message-ID: <WWAU3RkvjyiU0BobfO36OiaiYdtGdybXshpWKHc5AIg=.aacaf93c-95ab-433e-82a0-d6d62d92acc1@github.com>

On Mon, 6 Feb 2023 13:55:59 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/classfile/AttributedElement.java line 94:
>> 
>>> 92:      * are permitted.
>>> 93:      */
>>> 94:     enum Kind {
>> 
>> Not sure how to interpret this. This seems to refer to an attribute - e.g. where is an attribute allowed - rather than to the element (e.g. the declaration to which the attribute is attached). All the constants are unused, so hard to make sense of how this is used.
>
> There are at least 72 usages of AttributedElement.Kind across the Classfile API.
> Do you suggest to rename it to something else (for example Location)?

Uhm - I can't see these usages... something seems to be off with my IDE configuration. I did a grep and I now saw the uses. That said, having the Kind/Location inside AttributedElement still looks weird to me. The "places where an attribute can appear" is a property of an `Attribute`, not of an attributed element (which is used to model elements which can have attributes).

>> src/java.base/share/classes/jdk/internal/classfile/Attributes.java line 774:
>> 
>>> 772:      */
>>> 773:     public static AttributeMapper<?> standardAttribute(Utf8Entry name) {
>>> 774:         int hash = name.hashCode();
>> 
>> If we have a map, why do we need this "inlined" map here? Performance reasons?
>
> Yes, performance is the main reason.
> I'll note to do a fresh differential performance benchmarks with a HashMap.

thanks

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

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

From mcimadamore at openjdk.org  Tue Feb  7 11:56:55 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 7 Feb 2023 11:56:55 GMT
Subject: RFR: 8294982: Implementation of Classfile API [v12]
In-Reply-To: <iJyGP0x-bzXtRchGky3D7nJr-J2k4XPtl64FjcXJtCQ=.a9d4c1cd-08a7-4b8b-b43e-57a264d7265c@github.com>
References: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
 <Q4VeZ2yWAg85FqUDJa5hYq3jHty5H547gD0H-x3oIq0=.58d463a4-237a-4fee-bd0f-83262d49522a@github.com>
 <c022hrWNEHW76nhP_sXTQXCTjtL8jjM8r_yYv0IvbPI=.2a9cfbae-2fef-4cdb-8189-b869b1513fef@github.com>
 <iJyGP0x-bzXtRchGky3D7nJr-J2k4XPtl64FjcXJtCQ=.a9d4c1cd-08a7-4b8b-b43e-57a264d7265c@github.com>
Message-ID: <qitIL4woheCXgtU3PEQiW2HgXeKxvsInBTYqJOSG3cY=.e28eda15-5eec-40e5-81c1-21c3b7b23ac4@github.com>

On Mon, 6 Feb 2023 14:09:08 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/classfile/BootstrapMethodEntry.java line 41:
>> 
>>> 39:  * part of the constant pool.
>>> 40:  */
>>> 41: public sealed interface BootstrapMethodEntry
>> 
>> Usages of this seem all to fall into the `constantpool` package - does this interface belong there?
>
> `BootstrapMethodEntry` is not a constant pool entry, but `BootstrapMethodsAttribute` entry.
> It might be rather moved under `attribute` package and renamed to `BootstrapMethodInfo` to follow the same pattern as other attributes/infos.

I know it's part of an attribute - but reading the javadoc:

/**
 * Models an entry in the bootstrap method table.  The bootstrap method table
 * is stored in the {@code BootstrapMethods} attribute, but is modeled by
 * the {@link ConstantPool}, since the bootstrap method table is logically
 * part of the constant pool.
 */
 ```
 
 And also, seeing the method:
 
 ```
 /**
     * {@return the constant pool associated with this entry}
     */
    ConstantPool constantPool();


It seems like the API is doing the (justifiable) trick of making BSMs look like if they are first-class CP entries (even if not specified that way in the JVMLS). I think that's a fine move, but if we go down that path we should be honest, and put this class in constantpool. At least this is my 0.02$.

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

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

From duke at openjdk.org  Tue Feb  7 12:00:47 2023
From: duke at openjdk.org (Matthew Donovan)
Date: Tue, 7 Feb 2023 12:00:47 GMT
Subject: RFR: 8298939: Refactor
 open/test/jdk/javax/rmi/ssl/SSLSocketParametersTest.sh to jtreg java test
In-Reply-To: <VC_ou2XS44PtyTfwXw0VZRtXcHEbXImlLZKniIPRqOw=.7d10a168-77f8-4552-97a3-8b2570e3fe29@github.com>
References: <VC_ou2XS44PtyTfwXw0VZRtXcHEbXImlLZKniIPRqOw=.7d10a168-77f8-4552-97a3-8b2570e3fe29@github.com>
Message-ID: <Q4N5giM6Em1XOpiNsR87jDww5uSsxuLU6G0USL_zOdI=.6a46937a-9841-475c-81a6-643bdc8e6a07@github.com>

On Mon, 9 Jan 2023 19:54:24 GMT, Matthew Donovan <duke at openjdk.org> wrote:

> Removed SSLSocketParametersTest.sh script (which just called a Java file) and configured the java code to run directly with jtreg

Can someone take a look at this? Thanks!

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

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

From mcimadamore at openjdk.org  Tue Feb  7 12:13:51 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 7 Feb 2023 12:13:51 GMT
Subject: RFR: 8294982: Implementation of Classfile API [v12]
In-Reply-To: <FbFekphAbS5DQzn6B-uUHkX-2EF8Aq4NcijjMdlxAM0=.280a7529-4008-4539-9137-da7600e13eee@github.com>
References: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
 <Q4VeZ2yWAg85FqUDJa5hYq3jHty5H547gD0H-x3oIq0=.58d463a4-237a-4fee-bd0f-83262d49522a@github.com>
 <c022hrWNEHW76nhP_sXTQXCTjtL8jjM8r_yYv0IvbPI=.2a9cfbae-2fef-4cdb-8189-b869b1513fef@github.com>
 <FbFekphAbS5DQzn6B-uUHkX-2EF8Aq4NcijjMdlxAM0=.280a7529-4008-4539-9137-da7600e13eee@github.com>
Message-ID: <kxds1bmvZ8TbtVK5iDx_hZtrqN3uywsa6GqumJ7RubE=.ffd151e4-a1ba-4018-914c-518fd122dd4f@github.com>

On Mon, 6 Feb 2023 14:32:12 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/classfile/ClassSignature.java line 34:
>> 
>>> 32:  * Models the generic signature of a class file, as defined by JVMS 4.7.9.
>>> 33:  */
>>> 34: public sealed interface ClassSignature
>> 
>> It is a bit odd to have Signature and XYZSignature in the API with the latter not extending the former. I think I get what the API is aiming for though - e.g. Signature is for modelling low-level "portions" of the signature attributes, whereas ClassSignature, MethodSignature and friends are there to model the signature attribute attached to a class, method, etc.
>
> The confusion come from simplified name. Signature probably should be called JavaTypeSignature according to the spec. ClassSignature and MethodSignature could not extend it, as it would not respect the reality. Each of them are completely different species. Signature (or JavaTypeSignature) on the other side has many sub-types.

I think you mean `TypeSignature` from JLS 4.3.4 ? If so, I get it. To me it looks as if "Signature" really means "TypeSignature" - then it would make sense as to why `MethodSignature::arguments` returns a `List<Signature>` (e.g. because it should be `List<TypeSignature>`, as in the spec).

Also, from a modelling perspective, I see other problems too - in the JVMS, type signatures are defined as follows:


TypeSignature:
    FieldTypeSignature
    BaseType
```    
And:


FieldTypeSignature:
    ClassTypeSignature
    ArrayTypeSignature
    TypeVariableSignature 


So I'd roughly expect a type with 4 subclasses (type, then class <: type, array <: type, tvar <: type).

But the Signature class currently has other subclasses too - such as `ThrowableSig` - which is really only an (optional) part of method signatures. And, similarly, it also has `TypeParam`, which is a part of method/class signature - but is _not_ a type signature per se.

Summing up, it seems to me that the naming issue (which is not that important) hides a bigger modelling issue.

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

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

From mcimadamore at openjdk.org  Tue Feb  7 12:17:53 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 7 Feb 2023 12:17:53 GMT
Subject: RFR: 8294982: Implementation of Classfile API [v12]
In-Reply-To: <72tbazC88v5YoHtiss3ZJ6bmRP02sRG1j6-h9q752fc=.2acd02a8-018c-45d5-b65d-7089c1819815@github.com>
References: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
 <Q4VeZ2yWAg85FqUDJa5hYq3jHty5H547gD0H-x3oIq0=.58d463a4-237a-4fee-bd0f-83262d49522a@github.com>
 <c022hrWNEHW76nhP_sXTQXCTjtL8jjM8r_yYv0IvbPI=.2a9cfbae-2fef-4cdb-8189-b869b1513fef@github.com>
 <72tbazC88v5YoHtiss3ZJ6bmRP02sRG1j6-h9q752fc=.2acd02a8-018c-45d5-b65d-7089c1819815@github.com>
Message-ID: <otc76ggmH6uIFllMsC6ofRAvI_ZlBTbo-08MADEQa70=.b605e09d-4b69-4d5e-a359-cab60fa1216c@github.com>

On Mon, 6 Feb 2023 14:35:43 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/classfile/Opcode.java line 39:
>> 
>>> 37:  */
>>> 38: public enum Opcode {
>>> 39:     NOP(Classfile.NOP, 1, Kind.NOP),
>> 
>> This also duplicates the constants in classfile...
>
> On the contrary, it has been deduplicated. Opcode is referencing numeric constants stored in Classfile.

sure, but my question is - once you have a nice enum that is 1-1 with the opcodes - why would a client want to use the low-level opcode bytes? Shouldn't the API only deal with Opcodes? (and, in the rare occurrence where a client wants to really know the int value of an opcode, they can do e.g. `PUTSTATIC.bytecode()`)

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

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

From rgiulietti at openjdk.org  Tue Feb  7 12:22:43 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Tue, 7 Feb 2023 12:22:43 GMT
Subject: RFR: JDK-8301444: Port fdlibm hyperbolic transcendental functions
 to Java [v3]
In-Reply-To: <oOdHn8vDoAaIM9aWH1v8t3kkae0Iod5p3aHjGO_6DcQ=.35f4064b-6b04-43fa-ab2d-40bfd9ad1809@github.com>
References: <_s8xnppoDTnAajAjlmfB-dX5DBdawUcSSPaGWGLzFBk=.cdbf468a-ace7-45e5-a25a-833c760b776c@github.com>
 <fMzn-Bu9W5Lbqt1uTwKRQqu1lebKEUomO22TX0iMQc8=.4c547336-380c-4825-9cdb-bb091d6f8e75@github.com>
 <SqN7pgh29PWFA1NsmeJxU4a8MclqswrH__waOfzz1Eg=.a2e5d6c1-7231-4d90-8057-fbec8dcc8c58@github.com>
 <oOdHn8vDoAaIM9aWH1v8t3kkae0Iod5p3aHjGO_6DcQ=.35f4064b-6b04-43fa-ab2d-40bfd9ad1809@github.com>
Message-ID: <XzfAt8vshMa_dnOEAKDFWQJREpST21T5Y3nOSR_Yp18=.2cf82767-85e6-45ad-b921-3cbbeeba3a65@github.com>

On Mon, 6 Feb 2023 22:03:17 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Yes, it gave me pause when doing the transliteration.
>> 
>> Unpacking the code a bit,
>> 
>> 
>>             /* |x| in [log(maxdouble), overflowthresold] */
>>             // lx = *( (((*(unsigned*)&one)>>29)) + (unsigned*)&x);
>>             lx = __LO(x);
>>             if (ix<0x408633CE || 
>>             ((ix==0x408633ce)&&(Long.compareUnsigned(lx, 0x8fb9f87d) <= 0 ))) {...}
>> 
>> 
>> Assuming the comment accurate describe the intention of the code, identifying values between log(maxdouble) and the overflow threshold. Those particular values are as decimal fp, hex hp, and long bits:
>> 
>> 709.782712893384    0x1.62e42fefa39efp9    40862e42__fefa39ef
>> 710.4758600739439    0x1.633ce8fb9f87dp9    408633ce_8fb9f87d
>> 
>> so the conditional is checking if the high word (ix) is for something less than the low end of the range OR if the high word matches the high word for the high end of the range AND low bits are for less than the high end of the range. Therefore, I think taking __LO(x) is the correct semantics here.
>> 
>> FWIW, the ExhaustingTest of running all the float values against sinh/cosh/tanh in the transliteration port passes when using JDK 20 baseline as a reference.
>
> PS One possible future refactoring to the code in
> 
> src/java.base/share/classes/java/lang/FdLibm.java
> 
> would be to replace such integer-based range checks with floating-point based range checks, in this case something like:
> 
> 
> if (absX <= 0x1.633ce8fb9f87dp9) { // 710.4758600739439
>     ...}

Let's discuss this C fragment.
`*( (((*(unsigned*)&one)>>29)) + (unsigned*)&x)`

On a big-endian platform, `*(unsigned*)&one` returns `__HI(one) = 0x3ff0_0000`. It is then shifted right by 29, giving `1`. And `(unsigned*)&x` is the _address_ of the high word of `x`. The sum with `1` thus gives the address of the low word of `x`, which is dereferenced by the leftmost `*`, resulting in `__LO(x)`.

On a little-endian platform, `*(unsigned*)&one` returns `__LO(one) = 0x0`. It is then shifted right by 29, giving `0`. And `(unsigned*)&x` is the _address_ of the low word of `x`. The sum with `0` thus gives the address of the low word of `x`, which is dereferenced by the leftmost `*`, resulting in `__LO(x)` as well.

In other words, this is a complicated way to say `__LO(x)`, right? I wonder why the author came up with this creative code...

Would it make sense to add this discussion as a block comment?

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

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

From asotona at openjdk.org  Tue Feb  7 12:25:55 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Tue, 7 Feb 2023 12:25:55 GMT
Subject: RFR: 8294982: Implementation of Classfile API [v12]
In-Reply-To: <WWAU3RkvjyiU0BobfO36OiaiYdtGdybXshpWKHc5AIg=.aacaf93c-95ab-433e-82a0-d6d62d92acc1@github.com>
References: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
 <Q4VeZ2yWAg85FqUDJa5hYq3jHty5H547gD0H-x3oIq0=.58d463a4-237a-4fee-bd0f-83262d49522a@github.com>
 <c022hrWNEHW76nhP_sXTQXCTjtL8jjM8r_yYv0IvbPI=.2a9cfbae-2fef-4cdb-8189-b869b1513fef@github.com>
 <rzZgV5Ffapr1PM-e0qssZQwGCRGpcP9jv3Ua4aUY-TQ=.2540b2e9-cc38-4dfc-9f24-a31bb1b242e9@github.com>
 <WWAU3RkvjyiU0BobfO36OiaiYdtGdybXshpWKHc5AIg=.aacaf93c-95ab-433e-82a0-d6d62d92acc1@github.com>
Message-ID: <3BVe_gLrmvi-zHVIgeLbDiShOwtZR7VTjBclB1ajSmA=.f290f641-8002-4606-a057-200c66a034a7@github.com>

On Tue, 7 Feb 2023 11:48:28 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> There are at least 72 usages of AttributedElement.Kind across the Classfile API.
>> Do you suggest to rename it to something else (for example Location)?
>
> Uhm - I can't see these usages... something seems to be off with my IDE configuration. I did a grep and I now saw the uses. That said, having the Kind/Location inside AttributedElement still looks weird to me. The "places where an attribute can appear" is a property of an `Attribute`, not of an attributed element (which is used to model elements which can have attributes).

`AttributedElement::attributedElementKind` identifies the one kind of the attributes holder.
The "places where an attribute can appear" is available through `AttributeMapper::whereApplicable` and matched against `AttributedElement::attributedElementKind`.
We may consider to hide or remove this auxiliary method, as `AttributedElement::attributedElementKind` might be computed from the ClassfileElement instance type.

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

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

From mcimadamore at openjdk.org  Tue Feb  7 12:37:54 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 7 Feb 2023 12:37:54 GMT
Subject: RFR: 8294982: Implementation of Classfile API [v12]
In-Reply-To: <3BVe_gLrmvi-zHVIgeLbDiShOwtZR7VTjBclB1ajSmA=.f290f641-8002-4606-a057-200c66a034a7@github.com>
References: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
 <Q4VeZ2yWAg85FqUDJa5hYq3jHty5H547gD0H-x3oIq0=.58d463a4-237a-4fee-bd0f-83262d49522a@github.com>
 <c022hrWNEHW76nhP_sXTQXCTjtL8jjM8r_yYv0IvbPI=.2a9cfbae-2fef-4cdb-8189-b869b1513fef@github.com>
 <rzZgV5Ffapr1PM-e0qssZQwGCRGpcP9jv3Ua4aUY-TQ=.2540b2e9-cc38-4dfc-9f24-a31bb1b242e9@github.com>
 <WWAU3RkvjyiU0BobfO36OiaiYdtGdybXshpWKHc5AIg=.aacaf93c-95ab-433e-82a0-d6d62d92acc1@github.com>
 <3BVe_gLrmvi-zHVIgeLbDiShOwtZR7VTjBclB1ajSmA=.f290f641-8002-4606-a057-200c66a034a7@github.com>
Message-ID: <DT_uR31fEtDPJ-BI3G5i6_6GUV9RPf0Yt1guetkRkU4=.f5b32b65-1d36-4f66-895e-f376f6ea2d9a@github.com>

On Tue, 7 Feb 2023 12:23:05 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> Uhm - I can't see these usages... something seems to be off with my IDE configuration. I did a grep and I now saw the uses. That said, having the Kind/Location inside AttributedElement still looks weird to me. The "places where an attribute can appear" is a property of an `Attribute`, not of an attributed element (which is used to model elements which can have attributes).
>
> `AttributedElement::attributedElementKind` identifies the one kind of the attributes holder.
> The "places where an attribute can appear" is available through `AttributeMapper::whereApplicable` and matched against `AttributedElement::attributedElementKind`.
> We may consider to hide or remove this auxiliary method, as `AttributedElement::attributedElementKind` might be computed from the ClassfileElement instance type.

Still, there seems to be a modelling issue here. The property of "where could this attribute go" is a property of the attribute. Of course, for usability reason, an AttributedElement might expose a predicate saying "I only accept attributes of these kinds". But it seems to me as if the API has this relationship backwards, due to _where_ the Kind interface is being defined. I think if `Kind` was defined in `AttributeMapper` it would be a tad easier to understand. And, perhaps, the `attributedElementKind` name should be changed to something like `applicableAttributeKinds` or something like that.

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

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

From tvaleev at openjdk.org  Tue Feb  7 12:44:16 2023
From: tvaleev at openjdk.org (Tagir F. Valeev)
Date: Tue, 7 Feb 2023 12:44:16 GMT
Subject: RFR: 8301226: Add clamp() methods to java.lang.Math and to
 StrictMath [v7]
In-Reply-To: <c7kJhZvT8oz5hScMxnWI23H7wjCaJ854ajjSRtxBnW4=.3f4e24ca-c608-4541-b80e-cf3452ec6400@github.com>
References: <c7kJhZvT8oz5hScMxnWI23H7wjCaJ854ajjSRtxBnW4=.3f4e24ca-c608-4541-b80e-cf3452ec6400@github.com>
Message-ID: <EAA65ZAB9K5274PqAciRl15yasuTeOZmpEPVeoH9Ep8=.d72a39f7-aed4-41e0-a98b-b4e688873487@github.com>

> clamp() methods added to Math and StrictMath
> 
> `int clamp(long, int, int)` is somewhat different, as it accepts a `long` value and safely clamps it to an `int` range. Other overloads work with a particular type (long, float and double). Using similar approach in other cases (e.g. `float clamp(double, float, float)`) may cause accidental precision loss even if the value is within range, so I decided to avoid this.
> 
> In all cases, `max >= min` precondition should met. For double and float we additionally order `-0.0 < 0.0`, similarly to what Math.max or Double.compare do. In double and float overloads I try to keep at most one arg-check comparison on common path, so the order of checks might look unusual.
> 
> For tests, I noticed that tests in java/lang/Math don't use any testing framework (even newer tests), so I somehow mimic the approach of neighbour tests.

Tagir F. Valeev has updated the pull request incrementally with one additional commit since the last revision:

  More tests

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12428/files
  - new: https://git.openjdk.org/jdk/pull/12428/files/803ab852..47549342

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

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

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

From asotona at openjdk.org  Tue Feb  7 12:48:51 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Tue, 7 Feb 2023 12:48:51 GMT
Subject: RFR: 8294982: Implementation of Classfile API [v12]
In-Reply-To: <otc76ggmH6uIFllMsC6ofRAvI_ZlBTbo-08MADEQa70=.b605e09d-4b69-4d5e-a359-cab60fa1216c@github.com>
References: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
 <Q4VeZ2yWAg85FqUDJa5hYq3jHty5H547gD0H-x3oIq0=.58d463a4-237a-4fee-bd0f-83262d49522a@github.com>
 <c022hrWNEHW76nhP_sXTQXCTjtL8jjM8r_yYv0IvbPI=.2a9cfbae-2fef-4cdb-8189-b869b1513fef@github.com>
 <72tbazC88v5YoHtiss3ZJ6bmRP02sRG1j6-h9q752fc=.2acd02a8-018c-45d5-b65d-7089c1819815@github.com>
 <otc76ggmH6uIFllMsC6ofRAvI_ZlBTbo-08MADEQa70=.b605e09d-4b69-4d5e-a359-cab60fa1216c@github.com>
Message-ID: <e1MH_Z2M5gaGfHGOh_OSxncBMyXxPukpkfThs4wTSuo=.9dfb02a3-bdab-44e4-a4c3-e36f3b52679d@github.com>

On Tue, 7 Feb 2023 12:14:40 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> On the contrary, it has been deduplicated. Opcode is referencing numeric constants stored in Classfile.
>
> sure, but my question is - once you have a nice enum that is 1-1 with the opcodes - why would a client want to use the low-level opcode bytes? Shouldn't the API only deal with Opcodes? (and, in the rare occurrence where a client wants to really know the int value of an opcode, they can do e.g. `PUTSTATIC.bytecode()`)

It is the question of co-location of all numeric constants in one place in Classfile (or not).
I would agree with your proposal if the architectural decision is to decentralise the numeric constants and reduce Classfile footprint.

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

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

From tvaleev at openjdk.org  Tue Feb  7 12:53:25 2023
From: tvaleev at openjdk.org (Tagir F. Valeev)
Date: Tue, 7 Feb 2023 12:53:25 GMT
Subject: RFR: 8301226: Add clamp() methods to java.lang.Math and to
 StrictMath [v8]
In-Reply-To: <c7kJhZvT8oz5hScMxnWI23H7wjCaJ854ajjSRtxBnW4=.3f4e24ca-c608-4541-b80e-cf3452ec6400@github.com>
References: <c7kJhZvT8oz5hScMxnWI23H7wjCaJ854ajjSRtxBnW4=.3f4e24ca-c608-4541-b80e-cf3452ec6400@github.com>
Message-ID: <-RM6Jh13GZ4ZSt1qMwNp8Wb26qjGphOY89TaGenMzkM=.a04659cd-9f11-4af8-a53c-98d9ff837198@github.com>

> clamp() methods added to Math and StrictMath
> 
> `int clamp(long, int, int)` is somewhat different, as it accepts a `long` value and safely clamps it to an `int` range. Other overloads work with a particular type (long, float and double). Using similar approach in other cases (e.g. `float clamp(double, float, float)`) may cause accidental precision loss even if the value is within range, so I decided to avoid this.
> 
> In all cases, `max >= min` precondition should met. For double and float we additionally order `-0.0 < 0.0`, similarly to what Math.max or Double.compare do. In double and float overloads I try to keep at most one arg-check comparison on common path, so the order of checks might look unusual.
> 
> For tests, I noticed that tests in java/lang/Math don't use any testing framework (even newer tests), so I somehow mimic the approach of neighbour tests.

Tagir F. Valeev has updated the pull request incrementally with one additional commit since the last revision:

  Comments in tests

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12428/files
  - new: https://git.openjdk.org/jdk/pull/12428/files/47549342..500a8260

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

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

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

From tvaleev at openjdk.org  Tue Feb  7 12:53:28 2023
From: tvaleev at openjdk.org (Tagir F. Valeev)
Date: Tue, 7 Feb 2023 12:53:28 GMT
Subject: RFR: 8301226: Add clamp() methods to java.lang.Math and to
 StrictMath [v6]
In-Reply-To: <MTZqRrjZ1A1vgwKzIoJdXJr5z_LwXQRStkjBgH-7pBc=.10559c9a-b13d-4398-a8d1-088e465ccdb3@github.com>
References: <c7kJhZvT8oz5hScMxnWI23H7wjCaJ854ajjSRtxBnW4=.3f4e24ca-c608-4541-b80e-cf3452ec6400@github.com>
 <vlPKiqQDWJKn4Y91Gc9vOjiNBMkLsK2tNymYTR2OYKk=.ac4bd530-b665-4c6c-a61a-ff78c689fb63@github.com>
 <MTZqRrjZ1A1vgwKzIoJdXJr5z_LwXQRStkjBgH-7pBc=.10559c9a-b13d-4398-a8d1-088e465ccdb3@github.com>
Message-ID: <HodtzKFnCMDcRCnbYZHwcemo4-2h0EWYri92WKA2XD8=.f814f2b2-92fa-4846-aedf-118278875807@github.com>

On Tue, 7 Feb 2023 11:33:12 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> Tagir F. Valeev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Whitespace fixed
>
> test/jdk/java/lang/Math/Clamp.java line 149:
> 
>> 147:                 {-0.0, 0.0, 0.0, 0.0},
>> 148:                 {0.0, 0.0, 0.0, 0.0},
>> 149:                 {1.0, 0.0, 0.0, 0.0},
> 
> What about adding similar tests for the [-0.0, -0.0] interval?

Added, thanks

> test/jdk/java/lang/Math/Clamp.java line 160:
> 
>> 158:                 {0.0, Double.NaN, 0.0},
>> 159:                 {Double.NaN, 1.0, 0.0},
>> 160:                 {0.0, 0.0, -0.0}
> 
> Perhaps add other empty intervals, like [1.0, -1.0]

Added 1.0, -1.0. Anything else?

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

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

From rgiulietti at openjdk.org  Tue Feb  7 12:59:49 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Tue, 7 Feb 2023 12:59:49 GMT
Subject: RFR: 8301226: Add clamp() methods to java.lang.Math and to
 StrictMath [v6]
In-Reply-To: <HodtzKFnCMDcRCnbYZHwcemo4-2h0EWYri92WKA2XD8=.f814f2b2-92fa-4846-aedf-118278875807@github.com>
References: <c7kJhZvT8oz5hScMxnWI23H7wjCaJ854ajjSRtxBnW4=.3f4e24ca-c608-4541-b80e-cf3452ec6400@github.com>
 <vlPKiqQDWJKn4Y91Gc9vOjiNBMkLsK2tNymYTR2OYKk=.ac4bd530-b665-4c6c-a61a-ff78c689fb63@github.com>
 <MTZqRrjZ1A1vgwKzIoJdXJr5z_LwXQRStkjBgH-7pBc=.10559c9a-b13d-4398-a8d1-088e465ccdb3@github.com>
 <HodtzKFnCMDcRCnbYZHwcemo4-2h0EWYri92WKA2XD8=.f814f2b2-92fa-4846-aedf-118278875807@github.com>
Message-ID: <wDRWIMQW_iPkrXXaVNvmhamOEZXl5CAt7MljgnVs3ys=.28554b0f-135f-47e2-93fe-3d1fece9e5ae@github.com>

On Tue, 7 Feb 2023 12:43:56 GMT, Tagir F. Valeev <tvaleev at openjdk.org> wrote:

>> test/jdk/java/lang/Math/Clamp.java line 149:
>> 
>>> 147:                 {-0.0, 0.0, 0.0, 0.0},
>>> 148:                 {0.0, 0.0, 0.0, 0.0},
>>> 149:                 {1.0, 0.0, 0.0, 0.0},
>> 
>> What about adding similar tests for the [-0.0, -0.0] interval?
>
> Added, thanks

@amaembo I think you added tests for the [0.0, 0.0] interval, rather than [-0.0, -0.0]

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

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

From asotona at openjdk.org  Tue Feb  7 13:04:55 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Tue, 7 Feb 2023 13:04:55 GMT
Subject: RFR: 8294982: Implementation of Classfile API [v12]
In-Reply-To: <DT_uR31fEtDPJ-BI3G5i6_6GUV9RPf0Yt1guetkRkU4=.f5b32b65-1d36-4f66-895e-f376f6ea2d9a@github.com>
References: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
 <Q4VeZ2yWAg85FqUDJa5hYq3jHty5H547gD0H-x3oIq0=.58d463a4-237a-4fee-bd0f-83262d49522a@github.com>
 <c022hrWNEHW76nhP_sXTQXCTjtL8jjM8r_yYv0IvbPI=.2a9cfbae-2fef-4cdb-8189-b869b1513fef@github.com>
 <rzZgV5Ffapr1PM-e0qssZQwGCRGpcP9jv3Ua4aUY-TQ=.2540b2e9-cc38-4dfc-9f24-a31bb1b242e9@github.com>
 <WWAU3RkvjyiU0BobfO36OiaiYdtGdybXshpWKHc5AIg=.aacaf93c-95ab-433e-82a0-d6d62d92acc1@github.com>
 <3BVe_gLrmvi-zHVIgeLbDiShOwtZR7VTjBclB1ajSmA=.f290f641-8002-4606-a057-200c66a034a7@github.com>
 <DT_uR31fEtDPJ-BI3G5i6_6GUV9RPf0Yt1guetkRkU4=.f5b32b65-1d36-4f66-895e-f376f6ea2d9a@github.com>
Message-ID: <gqd04f9Ou36F5o0o05spkG2JgXoyix3wDUe78xpDb6M=.e3efc999-4545-414e-9daa-73a8b67dc7fd@github.com>

On Tue, 7 Feb 2023 12:34:50 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> `AttributedElement::attributedElementKind` identifies the one kind of the attributes holder.
>> The "places where an attribute can appear" is available through `AttributeMapper::whereApplicable` and matched against `AttributedElement::attributedElementKind`.
>> We may consider to hide or remove this auxiliary method, as `AttributedElement::attributedElementKind` might be computed from the ClassfileElement instance type.
>
> Still, there seems to be a modelling issue here. The property of "where could this attribute go" is a property of the attribute. Of course, for usability reason, an AttributedElement might expose a predicate saying "I only accept attributes of these kinds". But it seems to me as if the API has this relationship backwards, due to _where_ the Kind interface is being defined. I think if `Kind` was defined in `AttributeMapper` it would be a tad easier to understand. And, perhaps, the `attributedElementKind` name should be changed to something like `applicableAttributeKinds` or something like that.

The relation is that each `Attribute` is applicable in N `AttributedElements` and not vice versa.
For example `ClassModel::attributedElementKind` returns `CLASS` and for example `Attributes.RUNTIME_INVISIBLE_TYPE_ANNOTATIONS::applicableAttributeKinds` returns `Set.of(CLASS, METHOD, FIELD, CODE_ATTRIBUTE, RECORD_COMPONENT)`, so we know it is applicable.

However I'll try to re-visit this part of API if needed at all.

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

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

From duke at openjdk.org  Tue Feb  7 13:12:57 2023
From: duke at openjdk.org (ExE Boss)
Date: Tue, 7 Feb 2023 13:12:57 GMT
Subject: RFR: 8301226: Add clamp() methods to java.lang.Math and to
 StrictMath [v2]
In-Reply-To: <qnUokZ-1TMMQGZ9iS7CxOB74udDSe_SQGpMoAESbKso=.5c62e6b4-5eaf-4974-8d40-529ec8a04cf0@github.com>
References: <c7kJhZvT8oz5hScMxnWI23H7wjCaJ854ajjSRtxBnW4=.3f4e24ca-c608-4541-b80e-cf3452ec6400@github.com>
 <HD7wHqgfG1HUEElreURLgxBPOk9-R1jMiKNuquMvarE=.0f5a58cd-6faf-41db-87d8-5358f1251ab9@github.com>
 <jDUID4DZVg9PMYqC-QogTLTgI-JDctEjL26Z_VzWSH0=.5689e9c8-ced5-42ab-b773-b310cd9227e1@github.com>
 <qnUokZ-1TMMQGZ9iS7CxOB74udDSe_SQGpMoAESbKso=.5c62e6b4-5eaf-4974-8d40-529ec8a04cf0@github.com>
Message-ID: <a6b2jZCBiX1fOyI-gWTu81vKWKAJ-FvjPCu2WfwYlqM=.38ce531a-f759-451f-bfaf-6c76c1631d46@github.com>

On Mon, 6 Feb 2023 08:44:22 GMT, Tagir F. Valeev <tvaleev at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/Math.java line 2213:
>> 
>>> 2211:      * @since 21
>>> 2212:      */
>>> 2213:     public static int clamp(long value, int min, int max) {
>> 
>> There?should probably?also?be a?pure `int`?overload:
>> 
>> public static int clamp(int?value, int?min, int?max)
>
> @ExE-Boss which problem such an overload would solve? It looks like, `int clamp(long, int, int)` can be used everywhere where proposed `int clamp(int, int, int)` could be useful.

A?pure `int`?only overload doesn?t have?to?go through the?`int` ??`long` ??`int`?conversion.

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

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

From redestad at openjdk.org  Tue Feb  7 13:14:48 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Tue, 7 Feb 2023 13:14:48 GMT
Subject: RFR: 8301873: Avoid string decoding in ZipFile.Source.getEntryPos
 [v3]
In-Reply-To: <kocafii57-tSO8NfHg_5ywyqC_5DMPWa07dbqdG7884=.1e6e34d0-1e26-4ea7-aa52-466908d45d16@github.com>
References: <FkmdspiHVjkAKFqm5kUgwaf55YH5cBbczS_3krqsdFs=.05eca901-f55f-47d9-b1bc-0cf2f5b87536@github.com>
 <kocafii57-tSO8NfHg_5ywyqC_5DMPWa07dbqdG7884=.1e6e34d0-1e26-4ea7-aa52-466908d45d16@github.com>
Message-ID: <tN-FR3uI-_c3ZiWNk2iOyYoXbj958BblH1WWVs4xLNA=.755a09be-65c2-4e74-892c-e8e4ab256bc4@github.com>

On Mon, 6 Feb 2023 16:14:14 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

>> After finding a hash match, getEntryPos needs to compare the lookup name up to the encoded entry name in the CEN. This comparison is done by decoding the entry name into a String. The names can then be compared using the String API. This decoding step adds a significat cost to this method.
>> 
>> This PR suggest to update the string comparison such that in the common case where  both the lookup name and the entry name are encoded in ASCII-compatible UTF-8,  decoding can be avoided and the byte arrays can instead be compared direcly. 
>> 
>> ZipCoder is updated with a new method to compare a string with an encoded byte array range.  The default implementation decodes to string (like the current code), while the UTF-8 implementation uses JavaLangAccess.getBytesNoRepl to get the  bytes. Both methods thes uses Arrays.mismatch for comparison with or without matching trailing slashes. 
>> 
>> Additionally, this PR suggest to make the following updates to getEntryPos:
>> 
>> - The try/catch for IAE is redundant and can be safely removed. (initCEN already checks this and will throws IAE for invalid UTF-8). This seems to give a 3-4% speedup on micros)
>> - A new test InvalidBytesInEntryNameOrComment is a added to verify that initCEN does in fact reject invalid UTF-8 in CEN file names and comments. (I found no existing test coverage for this)
>> - The recursion when looking for "name/" matches is replaced with iteration. We keep track of any "name/" match and return it at the end of the search. (I feel this is easier to follow and it also gives a ~30% speedup for addSlash lookups with no regression on regular lookups)
>> 
>> (My though is that including these additional updates in this PR might reduce reviewer overhead given that it touches the exact same code. I might be wrong on this, please advise :)
>> 
>> I'm seeing a ~17% saving on the micro ZipFileGetEntry.getEntryHit (modified to use xalan.jar):
>> 
>> Baseline:
>> 
>> Benchmark                             (size)  Mode  Cnt    Score   Error  Units
>> ZipFileGetEntry.getEntryHit              512  avgt   15   74.941 ? 1.004  ns/op
>> ZipFileGetEntry.getEntryHit             1024  avgt   15   84.943 ? 1.320  ns/op
>> ZipFileGetEntry.getEntryHitUncached      512  avgt   15  120.371 ? 2.386  ns/op
>> ZipFileGetEntry.getEntryHitUncached     1024  avgt   15  126.128 ? 1.075  ns/op
>> ZipFileGetEntry.getEntryMiss             512  avgt   15   23.818 ? 0.838  ns/op
>> ZipFileGetEntry.getEntryMiss            1024  avgt   15   29.762 ? 5.998  ns/op
>> ZipFileGetEntry.getEntryMissUncached     512  avgt   15   59.405 ? 0.545  ns/op
>> ZipFileGetEntry.getEntryMissUncached    1024  avgt   15   71.840 ? 2.455  ns/op
>> ZipFileGetEntry.getEntrySlash            512  avgt   15  135.621 ? 4.341  ns/op
>> ZipFileGetEntry.getEntrySlash           1024  avgt   15  134.190 ? 2.141  ns/op
>> 
>> 
>> 
>> PR:
>> 
>> 
>> Benchmark                             (size)  Mode  Cnt    Score   Error  Units
>> ZipFileGetEntry.getEntryHit              512  avgt   15   62.267 ? 1.329  ns/op
>> ZipFileGetEntry.getEntryHit             1024  avgt   15   72.916 ? 2.428  ns/op
>> ZipFileGetEntry.getEntryHitUncached      512  avgt   15  101.630 ? 1.154  ns/op
>> ZipFileGetEntry.getEntryHitUncached     1024  avgt   15  113.161 ? 0.502  ns/op
>> ZipFileGetEntry.getEntryMiss             512  avgt   15   23.003 ? 1.191  ns/op
>> ZipFileGetEntry.getEntryMiss            1024  avgt   15   23.236 ? 1.114  ns/op
>> ZipFileGetEntry.getEntryMissUncached     512  avgt   15   56.781 ? 1.505  ns/op
>> ZipFileGetEntry.getEntryMissUncached    1024  avgt   15   67.767 ? 1.963  ns/op
>> ZipFileGetEntry.getEntrySlash            512  avgt   15   73.745 ? 2.717  ns/op
>> ZipFileGetEntry.getEntrySlash           1024  avgt   15   75.784 ? 1.051  ns/op
>> 
>> 
>> To assess the impact on startup/warmup, I made a main method class which measures the total time of calling ZipFile.getEntry for all entries in the 109 JAR file dependenies of spring-petclinic. The shows a nice improvement (time in micros):
>> 
>> 
>> Percentile Baseline Patch
>> 50?%          23155 21149
>> 75?%          23598 21454
>> 90?%          23989 21691
>> 95?%          24238 21973
>> 99?%          25270 22446
>> STDEV           792   549
>> Count           500   500
>
> Eirik Bjorsnos has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix incorrect offset for the CEN "length of extra field". Fixed spelling of "invalid".

Some GHA testing seem to have failed due to infrastructure issues - try merging in master to trigger testing again.

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

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

From duke at openjdk.org  Tue Feb  7 13:23:26 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Tue, 7 Feb 2023 13:23:26 GMT
Subject: RFR: 8301873: Avoid string decoding in ZipFile.Source.getEntryPos
 [v4]
In-Reply-To: <FkmdspiHVjkAKFqm5kUgwaf55YH5cBbczS_3krqsdFs=.05eca901-f55f-47d9-b1bc-0cf2f5b87536@github.com>
References: <FkmdspiHVjkAKFqm5kUgwaf55YH5cBbczS_3krqsdFs=.05eca901-f55f-47d9-b1bc-0cf2f5b87536@github.com>
Message-ID: <QHObV5Qz9Ygw1cjIooMNFMcXEYlwXUrqpmzvzXeR9-A=.4282ffa4-e17c-4b98-be2f-6b01f8be214d@github.com>

> After finding a hash match, getEntryPos needs to compare the lookup name up to the encoded entry name in the CEN. This comparison is done by decoding the entry name into a String. The names can then be compared using the String API. This decoding step adds a significat cost to this method.
> 
> This PR suggest to update the string comparison such that in the common case where  both the lookup name and the entry name are encoded in ASCII-compatible UTF-8,  decoding can be avoided and the byte arrays can instead be compared direcly. 
> 
> ZipCoder is updated with a new method to compare a string with an encoded byte array range.  The default implementation decodes to string (like the current code), while the UTF-8 implementation uses JavaLangAccess.getBytesNoRepl to get the  bytes. Both methods thes uses Arrays.mismatch for comparison with or without matching trailing slashes. 
> 
> Additionally, this PR suggest to make the following updates to getEntryPos:
> 
> - The try/catch for IAE is redundant and can be safely removed. (initCEN already checks this and will throws IAE for invalid UTF-8). This seems to give a 3-4% speedup on micros)
> - A new test InvalidBytesInEntryNameOrComment is a added to verify that initCEN does in fact reject invalid UTF-8 in CEN file names and comments. (I found no existing test coverage for this)
> - The recursion when looking for "name/" matches is replaced with iteration. We keep track of any "name/" match and return it at the end of the search. (I feel this is easier to follow and it also gives a ~30% speedup for addSlash lookups with no regression on regular lookups)
> 
> (My though is that including these additional updates in this PR might reduce reviewer overhead given that it touches the exact same code. I might be wrong on this, please advise :)
> 
> I'm seeing a ~17% saving on the micro ZipFileGetEntry.getEntryHit (modified to use xalan.jar):
> 
> Baseline:
> 
> Benchmark                             (size)  Mode  Cnt    Score   Error  Units
> ZipFileGetEntry.getEntryHit              512  avgt   15   74.941 ? 1.004  ns/op
> ZipFileGetEntry.getEntryHit             1024  avgt   15   84.943 ? 1.320  ns/op
> ZipFileGetEntry.getEntryHitUncached      512  avgt   15  120.371 ? 2.386  ns/op
> ZipFileGetEntry.getEntryHitUncached     1024  avgt   15  126.128 ? 1.075  ns/op
> ZipFileGetEntry.getEntryMiss             512  avgt   15   23.818 ? 0.838  ns/op
> ZipFileGetEntry.getEntryMiss            1024  avgt   15   29.762 ? 5.998  ns/op
> ZipFileGetEntry.getEntryMissUncached     512  avgt   15   59.405 ? 0.545  ns/op
> ZipFileGetEntry.getEntryMissUncached    1024  avgt   15   71.840 ? 2.455  ns/op
> ZipFileGetEntry.getEntrySlash            512  avgt   15  135.621 ? 4.341  ns/op
> ZipFileGetEntry.getEntrySlash           1024  avgt   15  134.190 ? 2.141  ns/op
> 
> 
> 
> PR:
> 
> 
> Benchmark                             (size)  Mode  Cnt    Score   Error  Units
> ZipFileGetEntry.getEntryHit              512  avgt   15   62.267 ? 1.329  ns/op
> ZipFileGetEntry.getEntryHit             1024  avgt   15   72.916 ? 2.428  ns/op
> ZipFileGetEntry.getEntryHitUncached      512  avgt   15  101.630 ? 1.154  ns/op
> ZipFileGetEntry.getEntryHitUncached     1024  avgt   15  113.161 ? 0.502  ns/op
> ZipFileGetEntry.getEntryMiss             512  avgt   15   23.003 ? 1.191  ns/op
> ZipFileGetEntry.getEntryMiss            1024  avgt   15   23.236 ? 1.114  ns/op
> ZipFileGetEntry.getEntryMissUncached     512  avgt   15   56.781 ? 1.505  ns/op
> ZipFileGetEntry.getEntryMissUncached    1024  avgt   15   67.767 ? 1.963  ns/op
> ZipFileGetEntry.getEntrySlash            512  avgt   15   73.745 ? 2.717  ns/op
> ZipFileGetEntry.getEntrySlash           1024  avgt   15   75.784 ? 1.051  ns/op
> 
> 
> To assess the impact on startup/warmup, I made a main method class which measures the total time of calling ZipFile.getEntry for all entries in the 109 JAR file dependenies of spring-petclinic. The shows a nice improvement (time in micros):
> 
> 
> Percentile Baseline Patch
> 50?%          23155 21149
> 75?%          23598 21454
> 90?%          23989 21691
> 95?%          24238 21973
> 99?%          25270 22446
> STDEV           792   549
> Count           500   500

Eirik Bjorsnos 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 'master' into getentrypos-prefixmatch
 - Fix incorrect offset for the CEN "length of extra field". Fixed spelling of "invalid".
 - Spelling fix in test data for non-ascii latin1 string
 - Replace new shared secret with using getBytesNoRepl in UTF8ZipCoder.compare. Add a test case for UTF-8 encoded entry name which is latin1, but not ASCII
 - Rename test to InvalidBytesInEntryNameOrComment
 - Adjust whitespace
 - Some minor improvements to code comments
 - Micros seem to indicate that the range checks in Arrays.mismatch might have as much as 5% regression
 - Move String/byte[] comparison into ZipCoder. Change the default implementation to decode to string for comparison instead of encoding to bytes, this seems safer. Revert some changes from previous commits to parameters in the hasTrailingSlash method.
 - ByteBuffers for reading ZIP files must be little-endian
 - ... and 10 more: https://git.openjdk.org/jdk/compare/23f44474...06047377

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12290/files
  - new: https://git.openjdk.org/jdk/pull/12290/files/2c5e7c2c..06047377

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

  Stats: 22651 lines in 906 files changed: 9116 ins; 4377 del; 9158 mod
  Patch: https://git.openjdk.org/jdk/pull/12290.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12290/head:pull/12290

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

From tvaleev at openjdk.org  Tue Feb  7 13:32:44 2023
From: tvaleev at openjdk.org (Tagir F. Valeev)
Date: Tue, 7 Feb 2023 13:32:44 GMT
Subject: RFR: 8301226: Add clamp() methods to java.lang.Math and to
 StrictMath [v2]
In-Reply-To: <a6b2jZCBiX1fOyI-gWTu81vKWKAJ-FvjPCu2WfwYlqM=.38ce531a-f759-451f-bfaf-6c76c1631d46@github.com>
References: <c7kJhZvT8oz5hScMxnWI23H7wjCaJ854ajjSRtxBnW4=.3f4e24ca-c608-4541-b80e-cf3452ec6400@github.com>
 <HD7wHqgfG1HUEElreURLgxBPOk9-R1jMiKNuquMvarE=.0f5a58cd-6faf-41db-87d8-5358f1251ab9@github.com>
 <jDUID4DZVg9PMYqC-QogTLTgI-JDctEjL26Z_VzWSH0=.5689e9c8-ced5-42ab-b773-b310cd9227e1@github.com>
 <qnUokZ-1TMMQGZ9iS7CxOB74udDSe_SQGpMoAESbKso=.5c62e6b4-5eaf-4974-8d40-529ec8a04cf0@github.com>
 <a6b2jZCBiX1fOyI-gWTu81vKWKAJ-FvjPCu2WfwYlqM=.38ce531a-f759-451f-bfaf-6c76c1631d46@github.com>
Message-ID: <B0MVO0tdv89nSvtjf17yQJRzLZIyB3Rvi2fvdfs1o10=.9f84433c-2ff5-49e1-bdc3-df1c68a72ad2@github.com>

On Tue, 7 Feb 2023 13:09:39 GMT, ExE Boss <duke at openjdk.org> wrote:

>> @ExE-Boss which problem such an overload would solve? It looks like, `int clamp(long, int, int)` can be used everywhere where proposed `int clamp(int, int, int)` could be useful.
>
> A?pure `int`?only overload doesn?t have?to?go through the?`int` ??`long` ??`int`?conversion.

Is this a real problem?

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

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

From msheppar at openjdk.org  Tue Feb  7 13:35:45 2023
From: msheppar at openjdk.org (Mark Sheppard)
Date: Tue, 7 Feb 2023 13:35:45 GMT
Subject: RFR: 8301214: Adjust handshakeTimeout value in test
 HandshakeTimeout.java after 8189338 [v2]
In-Reply-To: <dgdSwVg67xeZXeEsLzTGhoDrwke6P4XXD1mP6AAe-9k=.ad755037-43b4-4cc1-8c9a-6e3149c5031a@github.com>
References: <lNI2dGqbIvao8fiOOkCZQeOflJ2pNq1099RZZvo_bnc=.ba51e479-f21a-4594-b2b0-4ab5dd24d896@github.com>
 <dgdSwVg67xeZXeEsLzTGhoDrwke6P4XXD1mP6AAe-9k=.ad755037-43b4-4cc1-8c9a-6e3149c5031a@github.com>
Message-ID: <drSlWk1YvhbQebBYOJ3L_7R6RqVgOklY9-CxucBg3Fk=.66e60adb-d7e7-4f7f-838a-00753ae15830@github.com>

On Tue, 7 Feb 2023 09:38:13 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> Please review this patch that reduces the socket timeout used in HandshakeTimeout test to its minimum value of 1 millisecond.
>> 
>> This change makes the test complete 10 seconds faster; before this change it took 5 seconds for the handshake to timeout, and the test attempts 2 handshakes.
>> 
>> The change also makes the test more likely to pass when it has to compete with other tests for CPU time.
>
> Daniel Jeli?ski 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:
> 
>  - Restructure test
>  - Merge remote-tracking branch 'origin' into rmi-test-timeout
>  - Reduce socket timeout

Marked as reviewed by msheppar (Reviewer).

the restructuring is good idea. I never think of running clint and server in same thread, but it will eliminate any possibility of race between main thread and Connector thread. so job done (LGTM)

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

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

From redestad at openjdk.org  Tue Feb  7 13:46:28 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Tue, 7 Feb 2023 13:46:28 GMT
Subject: RFR: 8301958: Avoid Arrays.copyOfRange overhead in java.lang.String
Message-ID: <2pdPoSHz2RJ7YDHOwOyszQMVv0v7FQFOwykfJ-za_e0=.cfe480da-a045-4b9a-bec7-7fffd0f47206@github.com>

This adds a local, specialized `copyBytes` method to `String` that avoids certain redundant range checks and clamping that JIT has issues removing fully.

This has a small but statistically significant effect on `String` microbenchmarks, eg.:

Baseline

Benchmark                                            (size)  Mode  Cnt   Score   Error  Units
StringConstructor.newStringFromArray                      7  avgt   15  16.817 ? 0.369  ns/op
StringConstructor.newStringFromArrayWithCharset           7  avgt   15  16.866 ? 0.449  ns/op
StringConstructor.newStringFromArrayWithCharsetName       7  avgt   15  22.198 ? 0.396  ns/op


Patch:

Benchmark                                            (size)  Mode  Cnt   Score   Error  Units
StringConstructor.newStringFromArray                      7  avgt   15  15.477 ? 0.342  ns/op
StringConstructor.newStringFromArrayWithCharset           7  avgt   15  15.557 ? 0.352  ns/op
StringConstructor.newStringFromArrayWithCharsetName       7  avgt   15  21.272 ? 0.398  ns/op


Care has to be taken to ensure preconditions have been checked when using `checkBytes`. In the case of `String(AbstractStringBuilder)` there's a possible pre-existing issue where the constructor might either throw an exception or truncate the buffer if the builder byte array and length is not in agreement (theoretically possible if you clear/remove and call `trimToSize()` concurrently). Adding an explicit check here seem to be the right thing to do regardless of this RFE.

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

Commit messages:
 - Include some callsites in StringLatin1/UTF16, rename to copyBytes to disambiguate from generic utility methods, tune microbenchmark
 - 8301958: Avoid overhead of Arrays.copyOfRange in String

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

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

From mcimadamore at openjdk.org  Tue Feb  7 14:17:56 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 7 Feb 2023 14:17:56 GMT
Subject: RFR: 8294982: Implementation of Classfile API [v12]
In-Reply-To: <gqd04f9Ou36F5o0o05spkG2JgXoyix3wDUe78xpDb6M=.e3efc999-4545-414e-9daa-73a8b67dc7fd@github.com>
References: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
 <Q4VeZ2yWAg85FqUDJa5hYq3jHty5H547gD0H-x3oIq0=.58d463a4-237a-4fee-bd0f-83262d49522a@github.com>
 <c022hrWNEHW76nhP_sXTQXCTjtL8jjM8r_yYv0IvbPI=.2a9cfbae-2fef-4cdb-8189-b869b1513fef@github.com>
 <rzZgV5Ffapr1PM-e0qssZQwGCRGpcP9jv3Ua4aUY-TQ=.2540b2e9-cc38-4dfc-9f24-a31bb1b242e9@github.com>
 <WWAU3RkvjyiU0BobfO36OiaiYdtGdybXshpWKHc5AIg=.aacaf93c-95ab-433e-82a0-d6d62d92acc1@github.com>
 <3BVe_gLrmvi-zHVIgeLbDiShOwtZR7VTjBclB1ajSmA=.f290f641-8002-4606-a057-200c66a034a7@github.com>
 <DT_uR31fEtDPJ-BI3G5i6_6GUV9RPf0Yt1guetkRkU4=.f5b32b65-1d36-4f66-895e-f376f6ea2d9a@github.com>
 <gqd04f9Ou36F5o0o05spkG2JgXoyix3wDUe78xpDb6M=.e3efc999-4545-414e-9daa-73a8b67dc7fd@github.com>
Message-ID: <ZpKX5fdvJXIpc6r8SgzNoLIp5FMSz97Oo2R2XM0z1zE=.94b6465d-874b-4e7d-bbdf-a6976feb6606@github.com>

On Tue, 7 Feb 2023 12:59:32 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> Still, there seems to be a modelling issue here. The property of "where could this attribute go" is a property of the attribute. Of course, for usability reason, an AttributedElement might expose a predicate saying "I only accept attributes of these kinds". But it seems to me as if the API has this relationship backwards, due to _where_ the Kind interface is being defined. I think if `Kind` was defined in `AttributeMapper` it would be a tad easier to understand. And, perhaps, the `attributedElementKind` name should be changed to something like `applicableAttributeKinds` or something like that.
>
> The relation is that each `Attribute` is applicable in N `AttributedElements` and not vice versa.
> For example `ClassModel::attributedElementKind` returns `CLASS` and for example `Attributes.RUNTIME_INVISIBLE_TYPE_ANNOTATIONS::applicableAttributeKinds` returns `Set.of(CLASS, METHOD, FIELD, CODE_ATTRIBUTE, RECORD_COMPONENT)`, so we know it is applicable.
> 
> However I'll try to re-visit this part of API if needed at all.

I understand what the API, in its current form, wants to do. IMHO, the same functionality would be better expressed if the API had a way to say:

* each attribute has a _target_, where target can be a set of CLASS, METHOD, ...
* an attribute mapper supports a set of attribute targets
* an attributed element also supports a set of attribute targets

E.g. the target of the attribute is the concept to model - then AttributeMapper and AttributedElement just happen to expose a set of supported targets, which clients can query if needed.

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

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

From duke at openjdk.org  Tue Feb  7 14:30:53 2023
From: duke at openjdk.org (Scott Gibbons)
Date: Tue, 7 Feb 2023 14:30:53 GMT
Subject: RFR: JDK-8300808: Accelerate Base64 on x86 for AVX2 [v11]
In-Reply-To: <PoM3RCbgsT0X64L1fHCggfoUZB4kNLCRz6kgU8u18Vw=.7754c1ba-ff32-4f2a-b991-3d042b2377d8@github.com>
References: <9zN3bjyMEikXYOlpjTy9_QPc-9usYiBJMUFdb-TaVrQ=.e8f65ce9-ac0f-4f8d-9c6b-b39ae1c26cd2@github.com>
 <PoM3RCbgsT0X64L1fHCggfoUZB4kNLCRz6kgU8u18Vw=.7754c1ba-ff32-4f2a-b991-3d042b2377d8@github.com>
Message-ID: <TAQjhBbKeWUHAAnpBx3Q1xtPA39-6Dlh_TWA4BIOyUw=.9233a61e-d595-45ac-be57-17976e4b629b@github.com>

On Tue, 7 Feb 2023 00:12:21 GMT, Scott Gibbons <duke at openjdk.org> wrote:

>> Added code for Base64 acceleration (encode and decode) which will accelerate ~4x for AVX2 platforms.
>> 
>> Encode performance:
>> **Old:**
>> 
>> Benchmark                      (maxNumBytes)   Mode  Cnt     Score   Error   Units
>> Base64Encode.testBase64Encode           1024  thrpt    3  4309.439 ? 2.632  ops/ms
>> 
>> 
>> **New:**
>> 
>> Benchmark                      (maxNumBytes)   Mode  Cnt      Score     Error   Units
>> Base64Encode.testBase64Encode           1024  thrpt    3  24211.397 ? 102.026  ops/ms
>> 
>> 
>> Decode performance:
>> **Old:**
>> 
>> Benchmark                      (errorIndex)  (lineSize)  (maxNumBytes)   Mode  Cnt     Score    Error   Units
>> Base64Decode.testBase64Decode           144           4           1024  thrpt    3  3961.768 ? 93.409  ops/ms
>> 
>> **New:**
>> Benchmark                      (errorIndex)  (lineSize)  (maxNumBytes)   Mode  Cnt      Score    Error   Units
>> Base64Decode.testBase64Decode           144           4           1024  thrpt    3  14738.051 ? 24.383  ops/ms
>
> Scott Gibbons has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add algorithm comments

@sviswa7 Can you please share the test(s) you used to determine the stated failures?  I've run all of the tier1-3 tests in the suite with no failures.  Plus, if what you say is true, then the same logic would apply for the non-URL case as well as it applies to 0x2F ('/') in the same manner as 0x5F ('_').

If your test(s) do indeed show the failure, we should probably add them to the test suite.  Thanks.

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

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

From redestad at openjdk.org  Tue Feb  7 14:35:15 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Tue, 7 Feb 2023 14:35:15 GMT
Subject: RFR: 8301958: Avoid Arrays.copyOfRange overhead in
 java.lang.String [v2]
In-Reply-To: <2pdPoSHz2RJ7YDHOwOyszQMVv0v7FQFOwykfJ-za_e0=.cfe480da-a045-4b9a-bec7-7fffd0f47206@github.com>
References: <2pdPoSHz2RJ7YDHOwOyszQMVv0v7FQFOwykfJ-za_e0=.cfe480da-a045-4b9a-bec7-7fffd0f47206@github.com>
Message-ID: <VRM4Ow8zAUoYn3NBU76lly4k99mSvPKI-pnm3dMMZ8I=.35a8bb32-ce01-481e-9280-6807e41a4614@github.com>

> This adds a local, specialized `copyBytes` method to `String` that avoids certain redundant range checks and clamping that JIT has issues removing fully.
> 
> This has a small but statistically significant effect on `String` microbenchmarks, eg.:
> 
> Baseline
> 
> Benchmark                                            (size)  Mode  Cnt   Score   Error  Units
> StringConstructor.newStringFromArray                      7  avgt   15  16.817 ? 0.369  ns/op
> StringConstructor.newStringFromArrayWithCharset           7  avgt   15  16.866 ? 0.449  ns/op
> StringConstructor.newStringFromArrayWithCharsetName       7  avgt   15  22.198 ? 0.396  ns/op
> 
> 
> Patch:
> 
> Benchmark                                            (size)  Mode  Cnt   Score   Error  Units
> StringConstructor.newStringFromArray                      7  avgt   15  15.477 ? 0.342  ns/op
> StringConstructor.newStringFromArrayWithCharset           7  avgt   15  15.557 ? 0.352  ns/op
> StringConstructor.newStringFromArrayWithCharsetName       7  avgt   15  21.272 ? 0.398  ns/op
> 
> 
> Care has to be taken to ensure preconditions have been checked when using `checkBytes`. In the case of `String(AbstractStringBuilder)` there's a possible pre-existing issue where the constructor might either throw an exception or truncate the buffer if the builder byte array and length is not in agreement (theoretically possible if you clear/remove and call `trimToSize()` concurrently). Adding an explicit check here seem to be the right thing to do regardless of this RFE.

Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:

  fix StringUTF16.trim bug, rename locals to reduce confusion

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12453/files
  - new: https://git.openjdk.org/jdk/pull/12453/files/2d1f8e37..5b637e09

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

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

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

From redestad at openjdk.org  Tue Feb  7 14:39:31 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Tue, 7 Feb 2023 14:39:31 GMT
Subject: RFR: 8301958: Avoid Arrays.copyOfRange overhead in
 java.lang.String [v3]
In-Reply-To: <2pdPoSHz2RJ7YDHOwOyszQMVv0v7FQFOwykfJ-za_e0=.cfe480da-a045-4b9a-bec7-7fffd0f47206@github.com>
References: <2pdPoSHz2RJ7YDHOwOyszQMVv0v7FQFOwykfJ-za_e0=.cfe480da-a045-4b9a-bec7-7fffd0f47206@github.com>
Message-ID: <EHtXelxk9Pyzb1Tr_b9zVcQKXMsSQJn6LY7p_DJ39QQ=.0a94b1fe-4c7b-495a-8556-1b8a15fd334c@github.com>

> This adds a local, specialized `copyBytes` method to `String` that avoids certain redundant range checks and clamping that JIT has issues removing fully.
> 
> This has a small but statistically significant effect on `String` microbenchmarks, eg.:
> 
> Baseline
> 
> Benchmark                                            (size)  Mode  Cnt   Score   Error  Units
> StringConstructor.newStringFromArray                      7  avgt   15  16.817 ? 0.369  ns/op
> StringConstructor.newStringFromArrayWithCharset           7  avgt   15  16.866 ? 0.449  ns/op
> StringConstructor.newStringFromArrayWithCharsetName       7  avgt   15  22.198 ? 0.396  ns/op
> 
> 
> Patch:
> 
> Benchmark                                            (size)  Mode  Cnt   Score   Error  Units
> StringConstructor.newStringFromArray                      7  avgt   15  15.477 ? 0.342  ns/op
> StringConstructor.newStringFromArrayWithCharset           7  avgt   15  15.557 ? 0.352  ns/op
> StringConstructor.newStringFromArrayWithCharsetName       7  avgt   15  21.272 ? 0.398  ns/op
> 
> 
> Care has to be taken to ensure preconditions have been checked when using `checkBytes`. In the case of `String(AbstractStringBuilder)` there's a possible pre-existing issue where the constructor might either throw an exception or truncate the buffer if the builder byte array and length is not in agreement (theoretically possible if you clear/remove and call `trimToSize()` concurrently). Adding an explicit check here seem to be the right thing to do regardless of this RFE.

Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:

  Update StringLatin1.trim for consistency

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12453/files
  - new: https://git.openjdk.org/jdk/pull/12453/files/5b637e09..a5e494bc

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

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

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

From asotona at openjdk.org  Tue Feb  7 14:40:04 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Tue, 7 Feb 2023 14:40:04 GMT
Subject: RFR: 8294982: Implementation of Classfile API [v12]
In-Reply-To: <ZpKX5fdvJXIpc6r8SgzNoLIp5FMSz97Oo2R2XM0z1zE=.94b6465d-874b-4e7d-bbdf-a6976feb6606@github.com>
References: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
 <Q4VeZ2yWAg85FqUDJa5hYq3jHty5H547gD0H-x3oIq0=.58d463a4-237a-4fee-bd0f-83262d49522a@github.com>
 <c022hrWNEHW76nhP_sXTQXCTjtL8jjM8r_yYv0IvbPI=.2a9cfbae-2fef-4cdb-8189-b869b1513fef@github.com>
 <rzZgV5Ffapr1PM-e0qssZQwGCRGpcP9jv3Ua4aUY-TQ=.2540b2e9-cc38-4dfc-9f24-a31bb1b242e9@github.com>
 <WWAU3RkvjyiU0BobfO36OiaiYdtGdybXshpWKHc5AIg=.aacaf93c-95ab-433e-82a0-d6d62d92acc1@github.com>
 <3BVe_gLrmvi-zHVIgeLbDiShOwtZR7VTjBclB1ajSmA=.f290f641-8002-4606-a057-200c66a034a7@github.com>
 <DT_uR31fEtDPJ-BI3G5i6_6GUV9RPf0Yt1guetkRkU4=.f5b32b65-1d36-4f66-895e-f376f6ea2d9a@github.com>
 <gqd04f9Ou36F5o0o05spkG2JgXoyix3wDUe78xpDb6M=.e3efc999-4545-414e-9daa-73a8b67dc7fd@github.com>
 <ZpKX5fdvJXIpc6r8SgzNoLIp5FMSz97Oo2R2XM0z1zE=.94b6465d-874b-4e7d-bbdf-a6976feb6606@github.com>
Message-ID: <0K15FVxXOGvJNCRa1UOHSXr8pYxi0gdGvrPsgQhzi2s=.837fe9b4-605f-4526-8c2b-0556c8dd4495@github.com>

On Tue, 7 Feb 2023 14:14:50 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> The relation is that each `Attribute` is applicable in N `AttributedElements` and not vice versa.
>> For example `ClassModel::attributedElementKind` returns `CLASS` and for example `Attributes.RUNTIME_INVISIBLE_TYPE_ANNOTATIONS::applicableAttributeKinds` returns `Set.of(CLASS, METHOD, FIELD, CODE_ATTRIBUTE, RECORD_COMPONENT)`, so we know it is applicable.
>> 
>> However I'll try to re-visit this part of API if needed at all.
>
> I understand what the API, in its current form, wants to do. IMHO, the same functionality would be better expressed if the API had a way to say:
> 
> * each attribute has a _target_, where target can be a set of CLASS, METHOD, ...
> * an attribute mapper supports a set of attribute targets
> * an attributed element also supports a set of attribute targets
> 
> E.g. the target of the attribute is the concept to model - then AttributeMapper and AttributedElement just happen to expose a set of supported targets, which clients can query if needed.

I've prepared pull request to jdk-sandbox with complete removal of the AttributedElement.Kind and sent following note to classfile-api-dev at openjdk.org :


I would like to propose removal of AttributedElement.Kind across all Classfile API.
The AttributedElement.Kind models Attributes ?where applicable? and it is a duplication of each Attribute extending ClassElement, MethodElement, CodeElement, etc?

Classfile API is not actively using the AttributedElement.Kind except for parsing, where inappropriate AttributedElement.Kind is resolved as UnknownAttribute.

Following proposal removes all usages of AttributedElement.Kind from Classfile API:
https://github.com/openjdk/jdk-sandbox/pull/48/files

Please let me know is there are any objections.

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

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

From vtewari at openjdk.org  Tue Feb  7 14:50:51 2023
From: vtewari at openjdk.org (Vyom Tewari)
Date: Tue, 7 Feb 2023 14:50:51 GMT
Subject: RFR: 8301214: Adjust handshakeTimeout value in test
 HandshakeTimeout.java after 8189338 [v2]
In-Reply-To: <dgdSwVg67xeZXeEsLzTGhoDrwke6P4XXD1mP6AAe-9k=.ad755037-43b4-4cc1-8c9a-6e3149c5031a@github.com>
References: <lNI2dGqbIvao8fiOOkCZQeOflJ2pNq1099RZZvo_bnc=.ba51e479-f21a-4594-b2b0-4ab5dd24d896@github.com>
 <dgdSwVg67xeZXeEsLzTGhoDrwke6P4XXD1mP6AAe-9k=.ad755037-43b4-4cc1-8c9a-6e3149c5031a@github.com>
Message-ID: <Qrh2trvkYJDvODo0NJPQmzgeUlpxw4i990HdEWTeRl0=.75835489-cadb-4a44-a725-e16e0b3e9f9f@github.com>

On Tue, 7 Feb 2023 09:38:13 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> Please review this patch that reduces the socket timeout used in HandshakeTimeout test to its minimum value of 1 millisecond.
>> 
>> This change makes the test complete 10 seconds faster; before this change it took 5 seconds for the handshake to timeout, and the test attempts 2 handshakes.
>> 
>> The change also makes the test more likely to pass when it has to compete with other tests for CPU time.
>
> Daniel Jeli?ski 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:
> 
>  - Restructure test
>  - Merge remote-tracking branch 'origin' into rmi-test-timeout
>  - Reduce socket timeout

Refactored test looks good to me.

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

Marked as reviewed by vtewari (Committer).

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

From asotona at openjdk.org  Tue Feb  7 14:54:06 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Tue, 7 Feb 2023 14:54:06 GMT
Subject: RFR: 8294982: Implementation of Classfile API [v12]
In-Reply-To: <kxds1bmvZ8TbtVK5iDx_hZtrqN3uywsa6GqumJ7RubE=.ffd151e4-a1ba-4018-914c-518fd122dd4f@github.com>
References: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
 <Q4VeZ2yWAg85FqUDJa5hYq3jHty5H547gD0H-x3oIq0=.58d463a4-237a-4fee-bd0f-83262d49522a@github.com>
 <c022hrWNEHW76nhP_sXTQXCTjtL8jjM8r_yYv0IvbPI=.2a9cfbae-2fef-4cdb-8189-b869b1513fef@github.com>
 <FbFekphAbS5DQzn6B-uUHkX-2EF8Aq4NcijjMdlxAM0=.280a7529-4008-4539-9137-da7600e13eee@github.com>
 <kxds1bmvZ8TbtVK5iDx_hZtrqN3uywsa6GqumJ7RubE=.ffd151e4-a1ba-4018-914c-518fd122dd4f@github.com>
Message-ID: <WxjOq5CRJ9OtviOIxDKH9C78bScpiGmkiBqVXLDddzU=.a5a85537-43e8-4cf4-b747-86b945999d71@github.com>

On Tue, 7 Feb 2023 12:10:43 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> The confusion come from simplified name. Signature probably should be called JavaTypeSignature according to the spec. ClassSignature and MethodSignature could not extend it, as it would not respect the reality. Each of them are completely different species. Signature (or JavaTypeSignature) on the other side has many sub-types.
>
> I think you mean `TypeSignature` from JLS 4.3.4 ? If so, I get it. To me it looks as if "Signature" really means "TypeSignature" - then it would make sense as to why `MethodSignature::arguments` returns a `List<Signature>` (e.g. because it should be `List<TypeSignature>`, as in the spec).
> 
> Also, from a modelling perspective, I see other problems too - in the JVMS, type signatures are defined as follows:
> 
> 
> TypeSignature:
>     FieldTypeSignature
>     BaseType
> ```    
> And:
> 
> 
> FieldTypeSignature:
>     ClassTypeSignature
>     ArrayTypeSignature
>     TypeVariableSignature 
> 
> 
> So I'd roughly expect a type with 4 subclasses (type, then class <: type, array <: type, tvar <: type).
> 
> But the Signature class currently has other subclasses too - such as `ThrowableSig` - which is really only an (optional) part of method signatures. And, similarly, it also has `TypeParam`, which is a part of method/class signature - but is _not_ a type signature per se.
> 
> Summing up, it seems to me that the naming issue (which is not that important) hides a bigger modelling issue.

Class `Signature` (aka `JavaTypeSignature`), all subclasses, `MethodSignature` and `ClassSignature` are designed according to [JVMS 4.7.9.1 Signatures](https://docs.oracle.com/javase/specs/jvms/se19/html/jvms-4.html#jvms-4.7.9.1)

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

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

From alanb at openjdk.org  Tue Feb  7 15:01:01 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 7 Feb 2023 15:01:01 GMT
Subject: RFR: 8301958: Avoid Arrays.copyOfRange overhead in
 java.lang.String [v3]
In-Reply-To: <EHtXelxk9Pyzb1Tr_b9zVcQKXMsSQJn6LY7p_DJ39QQ=.0a94b1fe-4c7b-495a-8556-1b8a15fd334c@github.com>
References: <2pdPoSHz2RJ7YDHOwOyszQMVv0v7FQFOwykfJ-za_e0=.cfe480da-a045-4b9a-bec7-7fffd0f47206@github.com>
 <EHtXelxk9Pyzb1Tr_b9zVcQKXMsSQJn6LY7p_DJ39QQ=.0a94b1fe-4c7b-495a-8556-1b8a15fd334c@github.com>
Message-ID: <SUstulRQ2QtT5d4Lg97e84Bucd_NA1qTthKKpzSasGo=.8dd2691e-5e92-416c-a468-95e8d2690c69@github.com>

On Tue, 7 Feb 2023 14:39:31 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> This adds a local, specialized `copyBytes` method to `String` that avoids certain redundant range checks and clamping that JIT has issues removing fully.
>> 
>> This has a small but statistically significant effect on `String` microbenchmarks, eg.:
>> 
>> Baseline
>> 
>> Benchmark                                            (size)  Mode  Cnt   Score   Error  Units
>> StringConstructor.newStringFromArray                      7  avgt   15  16.817 ? 0.369  ns/op
>> StringConstructor.newStringFromArrayWithCharset           7  avgt   15  16.866 ? 0.449  ns/op
>> StringConstructor.newStringFromArrayWithCharsetName       7  avgt   15  22.198 ? 0.396  ns/op
>> 
>> 
>> Patch:
>> 
>> Benchmark                                            (size)  Mode  Cnt   Score   Error  Units
>> StringConstructor.newStringFromArray                      7  avgt   15  15.477 ? 0.342  ns/op
>> StringConstructor.newStringFromArrayWithCharset           7  avgt   15  15.557 ? 0.352  ns/op
>> StringConstructor.newStringFromArrayWithCharsetName       7  avgt   15  21.272 ? 0.398  ns/op
>> 
>> 
>> Care has to be taken to ensure preconditions have been checked when using `checkBytes`. In the case of `String(AbstractStringBuilder)` there's a possible pre-existing issue where the constructor might either throw an exception or truncate the buffer if the builder byte array and length is not in agreement (theoretically possible if you clear/remove and call `trimToSize()` concurrently). Adding an explicit check here seem to be the right thing to do regardless of this RFE.
>
> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update StringLatin1.trim for consistency

src/java.base/share/classes/java/lang/String.java line 4546:

> 4544:         // To avoid surprises due to data races (which would either truncate or throw an exception)
> 4545:         // we should check that length <= val.length up front
> 4546:         checkOffset(length, val.length);

I agree a check is needed here but I assume using checkOffset means that SB::toString could fail with SIOOBE. I wonder if Math.min(length, val.length) would be better here.

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

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

From redestad at openjdk.org  Tue Feb  7 15:12:15 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Tue, 7 Feb 2023 15:12:15 GMT
Subject: RFR: 8301958: Avoid Arrays.copyOfRange overhead in
 java.lang.String [v4]
In-Reply-To: <2pdPoSHz2RJ7YDHOwOyszQMVv0v7FQFOwykfJ-za_e0=.cfe480da-a045-4b9a-bec7-7fffd0f47206@github.com>
References: <2pdPoSHz2RJ7YDHOwOyszQMVv0v7FQFOwykfJ-za_e0=.cfe480da-a045-4b9a-bec7-7fffd0f47206@github.com>
Message-ID: <y3yz2AC2TXazDpCL2TEzrud9T1dDUiswzTfqRJy8vQQ=.13c7a836-0a63-48ad-90c3-62253de9149d@github.com>

> This adds a local, specialized `copyBytes` method to `String` that avoids certain redundant range checks and clamping that JIT has issues removing fully.
> 
> This has a small but statistically significant effect on `String` microbenchmarks, eg.:
> 
> Baseline
> 
> Benchmark                                            (size)  Mode  Cnt   Score   Error  Units
> StringConstructor.newStringFromArray                      7  avgt   15  16.817 ? 0.369  ns/op
> StringConstructor.newStringFromArrayWithCharset           7  avgt   15  16.866 ? 0.449  ns/op
> StringConstructor.newStringFromArrayWithCharsetName       7  avgt   15  22.198 ? 0.396  ns/op
> 
> 
> Patch:
> 
> Benchmark                                            (size)  Mode  Cnt   Score   Error  Units
> StringConstructor.newStringFromArray                      7  avgt   15  15.477 ? 0.342  ns/op
> StringConstructor.newStringFromArrayWithCharset           7  avgt   15  15.557 ? 0.352  ns/op
> StringConstructor.newStringFromArrayWithCharsetName       7  avgt   15  21.272 ? 0.398  ns/op
> 
> 
> Care has to be taken to ensure preconditions have been checked when using `checkBytes`. In the case of `String(AbstractStringBuilder)` there's a possible pre-existing issue where the constructor might either throw an exception or truncate the buffer if the builder byte array and length is not in agreement (theoretically possible if you clear/remove and call `trimToSize()` concurrently). Adding an explicit check here seem to be the right thing to do regardless of this RFE.

Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:

  truncate rather than throw in String(AbstractStringBuilder), keeping current behavior

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12453/files
  - new: https://git.openjdk.org/jdk/pull/12453/files/a5e494bc..2e33c27f

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

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

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

From redestad at openjdk.org  Tue Feb  7 15:14:09 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Tue, 7 Feb 2023 15:14:09 GMT
Subject: RFR: 8301958: Avoid Arrays.copyOfRange overhead in
 java.lang.String [v3]
In-Reply-To: <SUstulRQ2QtT5d4Lg97e84Bucd_NA1qTthKKpzSasGo=.8dd2691e-5e92-416c-a468-95e8d2690c69@github.com>
References: <2pdPoSHz2RJ7YDHOwOyszQMVv0v7FQFOwykfJ-za_e0=.cfe480da-a045-4b9a-bec7-7fffd0f47206@github.com>
 <EHtXelxk9Pyzb1Tr_b9zVcQKXMsSQJn6LY7p_DJ39QQ=.0a94b1fe-4c7b-495a-8556-1b8a15fd334c@github.com>
 <SUstulRQ2QtT5d4Lg97e84Bucd_NA1qTthKKpzSasGo=.8dd2691e-5e92-416c-a468-95e8d2690c69@github.com>
Message-ID: <fPhK10Afvgn32HznGp4ebvraLCrzaocsFLDAUBb3NCQ=.94844397-9a45-467f-b455-6f3badda18ac@github.com>

On Tue, 7 Feb 2023 14:57:52 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update StringLatin1.trim for consistency
>
> src/java.base/share/classes/java/lang/String.java line 4546:
> 
>> 4544:         // To avoid surprises due to data races (which would either truncate or throw an exception)
>> 4545:         // we should check that length <= val.length up front
>> 4546:         checkOffset(length, val.length);
> 
> I agree a check is needed here but I assume using checkOffset means that SB::toString could fail with SIOOBE. I wonder if Math.min(length, val.length) would be better here.

Ok. That keeps behavior consistent for most cases and removes a path where we can fail with SIOOBE in the existing code (down `StringUTF16::compress`).

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

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

From redestad at openjdk.org  Tue Feb  7 15:25:05 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Tue, 7 Feb 2023 15:25:05 GMT
Subject: RFR: 8301958: Avoid Arrays.copyOfRange overhead in
 java.lang.String [v5]
In-Reply-To: <2pdPoSHz2RJ7YDHOwOyszQMVv0v7FQFOwykfJ-za_e0=.cfe480da-a045-4b9a-bec7-7fffd0f47206@github.com>
References: <2pdPoSHz2RJ7YDHOwOyszQMVv0v7FQFOwykfJ-za_e0=.cfe480da-a045-4b9a-bec7-7fffd0f47206@github.com>
Message-ID: <cTuycT9n4HMlEf6dR1e4JGfRblzZai5m8ikN0t37qVc=.97f067d2-dd61-4f35-b79a-5717e95f5a4b@github.com>

> This adds a local, specialized `copyBytes` method to `String` that avoids certain redundant range checks and clamping that JIT has issues removing fully.
> 
> This has a small but statistically significant effect on `String` microbenchmarks, eg.:
> 
> Baseline
> 
> Benchmark                                            (size)  Mode  Cnt   Score   Error  Units
> StringConstructor.newStringFromArray                      7  avgt   15  16.817 ? 0.369  ns/op
> StringConstructor.newStringFromArrayWithCharset           7  avgt   15  16.866 ? 0.449  ns/op
> StringConstructor.newStringFromArrayWithCharsetName       7  avgt   15  22.198 ? 0.396  ns/op
> 
> 
> Patch:
> 
> Benchmark                                            (size)  Mode  Cnt   Score   Error  Units
> StringConstructor.newStringFromArray                      7  avgt   15  15.477 ? 0.342  ns/op
> StringConstructor.newStringFromArrayWithCharset           7  avgt   15  15.557 ? 0.352  ns/op
> StringConstructor.newStringFromArrayWithCharsetName       7  avgt   15  21.272 ? 0.398  ns/op
> 
> 
> Care has to be taken to ensure preconditions have been checked when using `checkBytes`. In the case of `String(AbstractStringBuilder)` there's a possible pre-existing issue where the constructor might either throw an exception or truncate the buffer if the builder byte array and length is not in agreement (theoretically possible if you clear/remove and call `trimToSize()` concurrently). Adding an explicit check here seem to be the right thing to do regardless of this RFE.

Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:

  copyrights

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12453/files
  - new: https://git.openjdk.org/jdk/pull/12453/files/2e33c27f..cece6f80

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

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

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

From alanb at openjdk.org  Tue Feb  7 15:25:08 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 7 Feb 2023 15:25:08 GMT
Subject: RFR: 8301958: Avoid Arrays.copyOfRange overhead in
 java.lang.String [v4]
In-Reply-To: <y3yz2AC2TXazDpCL2TEzrud9T1dDUiswzTfqRJy8vQQ=.13c7a836-0a63-48ad-90c3-62253de9149d@github.com>
References: <2pdPoSHz2RJ7YDHOwOyszQMVv0v7FQFOwykfJ-za_e0=.cfe480da-a045-4b9a-bec7-7fffd0f47206@github.com>
 <y3yz2AC2TXazDpCL2TEzrud9T1dDUiswzTfqRJy8vQQ=.13c7a836-0a63-48ad-90c3-62253de9149d@github.com>
Message-ID: <qgN8n0OASfeuR_BePV_tk6SSASNDVtjzuEv9enj8U8c=.94e3f519-2c99-4658-ba05-0608cb114b29@github.com>

On Tue, 7 Feb 2023 15:12:15 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> This adds a local, specialized `copyBytes` method to `String` that avoids certain redundant range checks and clamping that JIT has issues removing fully.
>> 
>> This has a small but statistically significant effect on `String` microbenchmarks, eg.:
>> 
>> Baseline
>> 
>> Benchmark                                            (size)  Mode  Cnt   Score   Error  Units
>> StringConstructor.newStringFromArray                      7  avgt   15  16.817 ? 0.369  ns/op
>> StringConstructor.newStringFromArrayWithCharset           7  avgt   15  16.866 ? 0.449  ns/op
>> StringConstructor.newStringFromArrayWithCharsetName       7  avgt   15  22.198 ? 0.396  ns/op
>> 
>> 
>> Patch:
>> 
>> Benchmark                                            (size)  Mode  Cnt   Score   Error  Units
>> StringConstructor.newStringFromArray                      7  avgt   15  15.477 ? 0.342  ns/op
>> StringConstructor.newStringFromArrayWithCharset           7  avgt   15  15.557 ? 0.352  ns/op
>> StringConstructor.newStringFromArrayWithCharsetName       7  avgt   15  21.272 ? 0.398  ns/op
>> 
>> 
>> Care has to be taken to ensure preconditions have been checked when using `checkBytes`. In the case of `String(AbstractStringBuilder)` there's a possible pre-existing issue where the constructor might either throw an exception or truncate the buffer if the builder byte array and length is not in agreement (theoretically possible if you clear/remove and call `trimToSize()` concurrently). Adding an explicit check here seem to be the right thing to do regardless of this RFE.
>
> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   truncate rather than throw in String(AbstractStringBuilder), keeping current behavior

Latest version looks good, I assume you've bump the copyright date on the files that still have 2022 as their last edit.

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

Marked as reviewed by alanb (Reviewer).

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

From dfuchs at openjdk.org  Tue Feb  7 15:56:57 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 7 Feb 2023 15:56:57 GMT
Subject: RFR: 8298939: Refactor
 open/test/jdk/javax/rmi/ssl/SSLSocketParametersTest.sh to jtreg java test
In-Reply-To: <VC_ou2XS44PtyTfwXw0VZRtXcHEbXImlLZKniIPRqOw=.7d10a168-77f8-4552-97a3-8b2570e3fe29@github.com>
References: <VC_ou2XS44PtyTfwXw0VZRtXcHEbXImlLZKniIPRqOw=.7d10a168-77f8-4552-97a3-8b2570e3fe29@github.com>
Message-ID: <0he17_UqLW1xZFjtb1R1AB8VbvZrqERfOmdmwnKm5tI=.5e343b27-6e26-41ae-a876-e4a799b23a66@github.com>

On Mon, 9 Jan 2023 19:54:24 GMT, Matthew Donovan <duke at openjdk.org> wrote:

> Removed SSLSocketParametersTest.sh script (which just called a Java file) and configured the java code to run directly with jtreg

test/jdk/javax/rmi/ssl/SSLSocketParametersTest.java line 192:

> 190:                         throw exc;
> 191:                     }
> 192:                 }

What is the story with the different exception catching here and in case 5? It doesn't look like a simple refactoring. Is another bug being fixed here?

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

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

From sviswanathan at openjdk.org  Tue Feb  7 15:57:00 2023
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Tue, 7 Feb 2023 15:57:00 GMT
Subject: RFR: JDK-8300808: Accelerate Base64 on x86 for AVX2 [v11]
In-Reply-To: <BU4DTrvn7YzuMYMKlaxGabUFg3nppXV1oDhS9mwCQIs=.65ffd677-99eb-49a9-a8c7-f7f199fa7ad6@github.com>
References: <9zN3bjyMEikXYOlpjTy9_QPc-9usYiBJMUFdb-TaVrQ=.e8f65ce9-ac0f-4f8d-9c6b-b39ae1c26cd2@github.com>
 <PoM3RCbgsT0X64L1fHCggfoUZB4kNLCRz6kgU8u18Vw=.7754c1ba-ff32-4f2a-b991-3d042b2377d8@github.com>
 <BU4DTrvn7YzuMYMKlaxGabUFg3nppXV1oDhS9mwCQIs=.65ffd677-99eb-49a9-a8c7-f7f199fa7ad6@github.com>
Message-ID: <pNpFd6pMZN04r-1x6Ex5v2DkL6cAMpAHCtIwYwBHlZ8=.52a327bd-6dbf-4e49-af15-3cc66bb33dc5@github.com>

On Tue, 7 Feb 2023 02:49:44 GMT, Sandhya Viswanathan <sviswanathan at openjdk.org> wrote:

>> Scott Gibbons has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add algorithm comments
>
> src/hotspot/cpu/x86/stubGenerator_x86_64.cpp line 2227:
> 
>> 2225: 
>> 2226:   // lut_roll URL
>> 2227:   __ emit_data64(0xb9b9bfbf04111000, relocInfo::none);
> 
> The lut_roll URL doesn't seem to be correct:
> 0x5F (URL base64 ASCII for "/") would need an offset of -20H i.e. 0xEC.
> However the others with upper nibble as 5 need an offset of -65H i.e. 0xBF.
> 
> It looks to me that the adjustment for 5F should be -4 instead of -1 at line 2722.

@asgibbons Currently the base64 string with "_" is not getting the vectorized implementation. as per my previous comment. It should show up in the jmh test. Once you fix that you will come across this bug. The logic is wrong here for 5F case.

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

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

From duke at openjdk.org  Tue Feb  7 16:05:18 2023
From: duke at openjdk.org (Matthew Donovan)
Date: Tue, 7 Feb 2023 16:05:18 GMT
Subject: RFR: 8298939: Refactor
 open/test/jdk/javax/rmi/ssl/SSLSocketParametersTest.sh to jtreg java test
In-Reply-To: <0he17_UqLW1xZFjtb1R1AB8VbvZrqERfOmdmwnKm5tI=.5e343b27-6e26-41ae-a876-e4a799b23a66@github.com>
References: <VC_ou2XS44PtyTfwXw0VZRtXcHEbXImlLZKniIPRqOw=.7d10a168-77f8-4552-97a3-8b2570e3fe29@github.com>
 <0he17_UqLW1xZFjtb1R1AB8VbvZrqERfOmdmwnKm5tI=.5e343b27-6e26-41ae-a876-e4a799b23a66@github.com>
Message-ID: <gCvIHE_VLLddikdJ377nerMbvLT9uRSuX6CjJz0Kfxo=.2d9aa3ac-dee9-4a2d-89ce-5ce755063279@github.com>

On Tue, 7 Feb 2023 15:54:06 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Removed SSLSocketParametersTest.sh script (which just called a Java file) and configured the java code to run directly with jtreg
>
> test/jdk/javax/rmi/ssl/SSLSocketParametersTest.java line 192:
> 
>> 190:                         throw exc;
>> 191:                     }
>> 192:                 }
> 
> What is the story with the different exception catching here and in case 5? It doesn't look like a simple refactoring. Is another bug being fixed here?

The expected result of cases 4 and 5 is that an IllegalArgumentException is thrown because of the unsupported ciphersuite. The original code just caught `Exception` which would hide a problem in the test e.g., if `SSLContext.getDefault()` throws the NoSuchAlgorithmException.

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

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

From ihse at openjdk.org  Tue Feb  7 16:05:23 2023
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 7 Feb 2023 16:05:23 GMT
Subject: RFR: JDK-8301444: Port fdlibm hyperbolic transcendental functions
 to Java [v3]
In-Reply-To: <HoCaJ-zkReSJFfNp11mlphGXA2jVJLQW_hZisTm7bhE=.561a6b8c-69e8-439e-bbcb-e19286e313d5@github.com>
References: <_s8xnppoDTnAajAjlmfB-dX5DBdawUcSSPaGWGLzFBk=.cdbf468a-ace7-45e5-a25a-833c760b776c@github.com>
 <HoCaJ-zkReSJFfNp11mlphGXA2jVJLQW_hZisTm7bhE=.561a6b8c-69e8-439e-bbcb-e19286e313d5@github.com>
Message-ID: <MyH3dC3PiO1_qR9BoCMo3G-E-TfO4cwHdoC75iwTB5A=.dd75623a-6ae7-4ab0-b352-9b0e605102f6@github.com>

On Mon, 6 Feb 2023 22:08:06 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Initial pass of porting FDLIBM sinh/cosh/tanh to Java. I do intend to refactor the regression tests a bit to reduce duplication, but the actual ports should be ready for review.
>> 
>> Diff'ing the ports as before, original vs transliteration port:
>> 
>> 
>> $ diff -w Hyperbolic.c Hyperbolic.translit.java
>> 1c1
>> < /* __ieee754_sinh(x)
>> ---
>>>     /**
>> 17a18,19
>>>     static class Sinh {
>>>         private static final double one = 1.0, shuge = 1.0e307;
>> 19,33c21
>> < #include "fdlibm.h"
>> < 
>> < #ifdef __STDC__
>> < static const double one = 1.0, shuge = 1.0e307;
>> < #else
>> < static double one = 1.0, shuge = 1.0e307;
>> < #endif
>> < 
>> < #ifdef __STDC__
>> <         double __ieee754_sinh(double x)
>> < #else
>> <         double __ieee754_sinh(x)
>> <         double x;
>> < #endif
>> < {
>> ---
>>>         private static double compute(double x) {
>> 36c24
>> <         unsigned lx;
>> ---
>>>             /* unsigned */ int lx;
>> 51c39
>> <             t = expm1(fabs(x));
>> ---
>>>                 t = FdlibmTranslit.expm1(Math.abs(x));
>> 57c45
>> <         if (ix < 0x40862E42)  return h*__ieee754_exp(fabs(x));
>> ---
>>>             if (ix < 0x40862E42)  return h*StrictMath.exp(Math.abs(x)); // TODO switch to translit
>> 60,62c48,52
>> <         lx = *( (((*(unsigned*)&one)>>29)) + (unsigned*)&x);
>> <         if (ix<0x408633CE || ((ix==0x408633ce)&&(lx<=(unsigned)0x8fb9f87d))) {
>> <             w = __ieee754_exp(0.5*fabs(x));
>> ---
>>>             // lx = *( (((*(unsigned*)&one)>>29)) + (unsigned*)&x);
>>>             // lx =  (((*(unsigned*)&one)>>29)) + (unsigned*)&x ;
>>>             lx = __LO(x);
>>>             if (ix<0x408633CE || ((ix==0x408633ce)&&(Long.compareUnsigned(lx, 0x8fb9f87d) <= 0 ))) {
>>>                 w = StrictMath.exp(0.5*Math.abs(x)); // TODO switch to translit
>> 70c60,62
>> < /* __ieee754_cosh(x)
>> ---
>>>     }
>>> 
>>>     /**
>> 90,105c82,84
>> < 
>> < #include "fdlibm.h"
>> < 
>> < #ifdef __STDC__
>> < static const double one = 1.0, half=0.5, huge = 1.0e300;
>> < #else
>> < static double one = 1.0, half=0.5, huge = 1.0e300;
>> < #endif
>> < 
>> < #ifdef __STDC__
>> <         double __ieee754_cosh(double x)
>> < #else
>> <         double __ieee754_cosh(x)
>> <         double x;
>> < #endif
>> < {
>> ---
>>>     static class Cosh {
>>>         private static final double one = 1.0, half=0.5, huge = 1.0e300;
>>>         private static double compute(double x) {
>> 108c87
>> <         unsigned lx;
>> ---
>>>             /*unsigned*/ int lx;
>> 119c98
>> <             t = expm1(fabs(x));
>> ---
>>>                 t = expm1(Math.abs(x));
>> 127c106
>> <                 t = __ieee754_exp(fabs(x));
>> ---
>>>                 t = StrictMath.exp(Math.abs(x)); // TODO switch to translit
>> 132c111
>> <         if (ix < 0x40862E42)  return half*__ieee754_exp(fabs(x));
>> ---
>>>             if (ix < 0x40862E42)  return half*StrictMath.exp(Math.abs(x)); // TODO switch to translit
>> 135c114
>> <         lx = *( (((*(unsigned*)&one)>>29)) + (unsigned*)&x);
>> ---
>>>             lx = __LO(x);
>> 137,138c116,117
>> <               ((ix==0x408633ce)&&(lx<=(unsigned)0x8fb9f87d))) {
>> <             w = __ieee754_exp(half*fabs(x));
>> ---
>>>                 ((ix==0x408633ce)&&(Integer.compareUnsigned(lx, 0x8fb9f87d) <= 0))) {
>>>                 w = StrictMath.exp(half*Math.abs(x)); // TODO switch to translit
>> 146c125,127
>> < /* Tanh(x)
>> ---
>>>     }
>>> 
>>>     /**
>> 169,184c150,152
>> < 
>> < #include "fdlibm.h"
>> < 
>> < #ifdef __STDC__
>> < static const double one=1.0, two=2.0, tiny = 1.0e-300;
>> < #else
>> < static double one=1.0, two=2.0, tiny = 1.0e-300;
>> < #endif
>> < 
>> < #ifdef __STDC__
>> <         double tanh(double x)
>> < #else
>> <         double tanh(x)
>> <         double x;
>> < #endif
>> < {
>> ---
>>>     static class Tanh {
>>>         private static final double one=1.0, two=2.0, tiny = 1.0e-300;
>>>         static double compute(double x) {
>> 203c171
>> <                 t = expm1(two*fabs(x));
>> ---
>>>                     t = expm1(two*Math.abs(x));
>> 206c174
>> <                 t = expm1(-two*fabs(x));
>> ---
>>>                     t = expm1(-two*Math.abs(x));
>> 214a183
>>>     }
>> 
>> 
>> Note that the original has a in-line version of the "__LO" macro rather than using the macro.
>> 
>> 
>> And transliteration vs more idiomatic:
>> 
>> 
>> $ diff -w Hyperbolic.translit.java Hyperbolic.fdlibm.java 
>> 21c21
>> <         private static double compute(double x) {
>> ---
>>>          static double compute(double x) {
>> 26c26
>> <             /* High word of |x|. */
>> ---
>>>             // High word of |x|
>> 28c28
>> <             ix = jx&0x7fffffff;
>> ---
>>>             ix = jx & 0x7fff_ffff;
>> 30,31c30,33
>> <             /* x is INF or NaN */
>> <             if(ix>=0x7ff00000) return x+x;
>> ---
>>>             // x is INF or NaN
>>>             if ( ix >= 0x7ff0_0000) {
>>>                 return x + x;
>>>             }
>> 34,40c36,48
>> <             if (jx<0) h = -h;
>> <             /* |x| in [0,22], return sign(x)*0.5*(E+E/(E+1))) */
>> <             if (ix < 0x40360000) {          /* |x|<22 */
>> <                 if (ix<0x3e300000)          /* |x|<2**-28 */
>> <                     if(shuge+x>one) return x;/* sinh(tiny) = tiny with inexact */
>> <                 t = FdlibmTranslit.expm1(Math.abs(x));
>> <                 if(ix<0x3ff00000) return h*(2.0*t-t*t/(t+one));
>> ---
>>>             if ( jx < 0) {
>>>                 h = -h;
>>>             }
>>>             // |x| in [0,22], return sign(x)*0.5*(E+E/(E+1)))
>>>             if (ix < 0x4036_0000) {          // |x| < 22
>>>                 if (ix < 0x3e30_0000)        // |x| < 2**-28
>>>                     if (shuge + x > one) {   // sinh(tiny) = tiny with inexact
>>>                         return x;
>>>                     }
>>>                 t = StrictMath.expm1(Math.abs(x));
>>>                 if (ix < 0x3ff0_0000) {
>>>                     return h*(2.0 * t - t*t/(t + one));
>>>                 }
>> 44,45c52,55
>> <             /* |x| in [22, log(maxdouble)] return 0.5*exp(|x|) */
>> <             if (ix < 0x40862E42)  return h*StrictMath.exp(Math.abs(x)); // TODO switch to translit
>> ---
>>>             // |x| in [22, log(maxdouble)] return 0.5*exp(|x|)
>>>             if (ix < 0x4086_2E42) {
>>>                 return h*StrictMath.exp(Math.abs(x));
>>>             }
>> 47,49c57
>> <             /* |x| in [log(maxdouble), overflowthresold] */
>> <             // lx = *( (((*(unsigned*)&one)>>29)) + (unsigned*)&x);
>> <             // lx =  (((*(unsigned*)&one)>>29)) + (unsigned*)&x ;
>> ---
>>>             // |x| in [log(maxdouble), overflowthresold]
>> 51,52c59,62
>> <             if (ix<0x408633CE || ((ix==0x408633ce)&&(Long.compareUnsigned(lx, 0x8fb9f87d) <= 0 ))) {
>> <                 w = StrictMath.exp(0.5*Math.abs(x)); // TODO switch to translit
>> ---
>>>             if (ix < 0x4086_33CE ||
>>>                 ((ix == 0x4086_33ce) &&
>>>                  (Long.compareUnsigned(lx, 0x8fb9_f87d) <= 0 ))) {
>>>                 w = StrictMath.exp(0.5 * Math.abs(x));
>> 57c67
>> <             /* |x| > overflowthresold, sinh(x) overflow */
>> ---
>>>             // |x| > overflowthresold, sinh(x) overflow
>> 84c94
>> <         private static double compute(double x) {
>> ---
>>>         static double compute(double x) {
>> 89c99
>> <             /* High word of |x|. */
>> ---
>>>             // High word of |x|
>> 91c101
>> <             ix &= 0x7fffffff;
>> ---
>>>             ix &= 0x7fff_ffff;
>> 93,94c103,106
>> <             /* x is INF or NaN */
>> <             if(ix>=0x7ff00000) return x*x;
>> ---
>>>             // x is INF or NaN
>>>             if (ix >= 0x7ff_00000) {
>>>                 return x*x;
>>>             }
>> 96,98c108,110
>> <             /* |x| in [0,0.5*ln2], return 1+expm1(|x|)^2/(2*exp(|x|)) */
>> <             if(ix<0x3fd62e43) {
>> <                 t = expm1(Math.abs(x));
>> ---
>>>             // |x| in [0,0.5*ln2], return 1+expm1(|x|)^2/(2*exp(|x|))
>>>             if (ix < 0x3fd6_2e43) {
>>>                 t = StrictMath.expm1(Math.abs(x));
>> 100c112,114
>> <                 if (ix<0x3c800000) return w;        /* cosh(tiny) = 1 */
>> ---
>>>                 if (ix < 0x3c80_0000) { // cosh(tiny) = 1
>>>                     return w;
>>>                 }
>> 104,106c118,120
>> <             /* |x| in [0.5*ln2,22], return (exp(|x|)+1/exp(|x|)/2; */
>> <             if (ix < 0x40360000) {
>> <                 t = StrictMath.exp(Math.abs(x)); // TODO switch to translit
>> ---
>>>             // |x| in [0.5*ln2, 22], return (exp(|x|) + 1/exp(|x|)/2
>>>             if (ix < 0x4036_0000) {
>>>                 t = StrictMath.exp(Math.abs(x));
>> 110,111c124,127
>> <             /* |x| in [22, log(maxdouble)] return half*exp(|x|) */
>> <             if (ix < 0x40862E42)  return half*StrictMath.exp(Math.abs(x)); // TODO switch to translit
>> ---
>>>             // |x| in [22, log(maxdouble)] return half*exp(|x|)
>>>             if (ix < 0x4086_2E42) {
>>>                 return half*StrictMath.exp(Math.abs(x));
>>>             }
>> 113c129
>> <             /* |x| in [log(maxdouble), overflowthresold] */
>> ---
>>>             // |x| in [log(maxdouble), overflowthresold]
>> 115,117c131,134
>> <             if (ix<0x408633CE ||
>> <                 ((ix==0x408633ce)&&(Integer.compareUnsigned(lx, 0x8fb9f87d) <= 0))) {
>> <                 w = StrictMath.exp(half*Math.abs(x)); // TODO switch to translit
>> ---
>>>             if (ix<0x4086_33CE ||
>>>                 ((ix == 0x4086_33ce) &&
>>>                  (Integer.compareUnsigned(lx, 0x8fb9_f87d) <= 0))) {
>>>                 w = StrictMath.exp(half*Math.abs(x));
>> 122c139
>> <             /* |x| > overflowthresold, cosh(x) overflow */
>> ---
>>>             // |x| > overflowthresold, cosh(x) overflow
>> 126d142
>> < 
>> 156c172
>> <             /* High word of |x|. */
>> ---
>>>             // High word of |x|.
>> 158c174
>> <             ix = jx&0x7fffffff;
>> ---
>>>             ix = jx & 0x7fff_ffff;
>> 160,163c176,182
>> <             /* x is INF or NaN */
>> <             if(ix>=0x7ff00000) {
>> <                 if (jx>=0) return one/x+one;    /* tanh(+-inf)=+-1 */
>> <                 else       return one/x-one;    /* tanh(NaN) = NaN */
>> ---
>>>             // x is INF or NaN
>>>             if (ix >= 0x7ff0_0000) {
>>>                 if (jx >= 0) {  // tanh(+-inf)=+-1
>>>                     return one/x + one;
>>>                 } else {        // tanh(NaN) = NaN
>>>                     return one/x - one;
>>>                 }
>> 166,171c185,190
>> <             /* |x| < 22 */
>> <             if (ix < 0x40360000) {          /* |x|<22 */
>> <                 if (ix<0x3c800000)          /* |x|<2**-55 */
>> <                     return x*(one+x);       /* tanh(small) = small */
>> <                 if (ix>=0x3ff00000) {       /* |x|>=1  */
>> <                     t = expm1(two*Math.abs(x));
>> ---
>>>             // |x| < 22
>>>             if (ix < 0x4036_0000) {          // |x| < 22
>>>                 if (ix<0x3c80_0000)          // |x| < 2**-55
>>>                     return x*(one + x);      // tanh(small) = small
>>>                 if (ix>=0x3ff0_0000) {       // |x| >= 1
>>>                     t = StrictMath.expm1(two*Math.abs(x));
>> 174c193
>> <                     t = expm1(-two*Math.abs(x));
>> ---
>>>                     t = StrictMath.expm1(-two*Math.abs(x));
>> 177,179c196,197
>> <                 /* |x| > 22, return +-1 */
>> <             } else {
>> <                 z = one - tiny;             /* raised inexact flag */
>> ---
>>>             } else { // |x| > 22, return +-1
>>>                 z = one - tiny;             // raised inexact flag
>
> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Correct overflow limit in regression test.

src/java.base/share/classes/java/lang/FdLibm.java line 1215:

> 1213:      *      only sinh(0)=0 is exact for finite x.
> 1214:      */
> 1215:     static class Sinh {

For clarity, should this not be declared `final`?

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

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

From dfuchs at openjdk.org  Tue Feb  7 16:17:05 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 7 Feb 2023 16:17:05 GMT
Subject: RFR: 8298939: Refactor
 open/test/jdk/javax/rmi/ssl/SSLSocketParametersTest.sh to jtreg java test
In-Reply-To: <gCvIHE_VLLddikdJ377nerMbvLT9uRSuX6CjJz0Kfxo=.2d9aa3ac-dee9-4a2d-89ce-5ce755063279@github.com>
References: <VC_ou2XS44PtyTfwXw0VZRtXcHEbXImlLZKniIPRqOw=.7d10a168-77f8-4552-97a3-8b2570e3fe29@github.com>
 <0he17_UqLW1xZFjtb1R1AB8VbvZrqERfOmdmwnKm5tI=.5e343b27-6e26-41ae-a876-e4a799b23a66@github.com>
 <gCvIHE_VLLddikdJ377nerMbvLT9uRSuX6CjJz0Kfxo=.2d9aa3ac-dee9-4a2d-89ce-5ce755063279@github.com>
Message-ID: <7cBm5g5RZOvI13OmoGWpt45cfjIPgXMZFENVNHdcSn8=.850c3665-962f-4975-ba4f-4e8152fd6106@github.com>

On Tue, 7 Feb 2023 16:02:30 GMT, Matthew Donovan <duke at openjdk.org> wrote:

>> test/jdk/javax/rmi/ssl/SSLSocketParametersTest.java line 192:
>> 
>>> 190:                         throw exc;
>>> 191:                     }
>>> 192:                 }
>> 
>> What is the story with the different exception catching here and in case 5? It doesn't look like a simple refactoring. Is another bug being fixed here?
>
> The expected result of cases 4 and 5 is that an IllegalArgumentException is thrown because of the unsupported ciphersuite. The original code just caught `Exception` which would hide a problem in the test e.g., if `SSLContext.getDefault()` throws the NoSuchAlgorithmException.

OK - but the run( ) method catches IllegalArgumentException already?

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

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

From mcimadamore at openjdk.org  Tue Feb  7 16:25:11 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 7 Feb 2023 16:25:11 GMT
Subject: RFR: 8294982: Implementation of Classfile API [v12]
In-Reply-To: <WxjOq5CRJ9OtviOIxDKH9C78bScpiGmkiBqVXLDddzU=.a5a85537-43e8-4cf4-b747-86b945999d71@github.com>
References: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
 <Q4VeZ2yWAg85FqUDJa5hYq3jHty5H547gD0H-x3oIq0=.58d463a4-237a-4fee-bd0f-83262d49522a@github.com>
 <c022hrWNEHW76nhP_sXTQXCTjtL8jjM8r_yYv0IvbPI=.2a9cfbae-2fef-4cdb-8189-b869b1513fef@github.com>
 <FbFekphAbS5DQzn6B-uUHkX-2EF8Aq4NcijjMdlxAM0=.280a7529-4008-4539-9137-da7600e13eee@github.com>
 <kxds1bmvZ8TbtVK5iDx_hZtrqN3uywsa6GqumJ7RubE=.ffd151e4-a1ba-4018-914c-518fd122dd4f@github.com>
 <WxjOq5CRJ9OtviOIxDKH9C78bScpiGmkiBqVXLDddzU=.a5a85537-43e8-4cf4-b747-86b945999d71@github.com>
Message-ID: <84RlLSIsacJTJVM-esvzoXnQ5rDEByog5b1ibFRJOE8=.05e8e7a7-2185-4e1c-b5b9-59ce3b3eea03@github.com>

On Tue, 7 Feb 2023 14:51:06 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> Class `Signature` (aka `JavaTypeSignature`), all subclasses, `MethodSignature` and `ClassSignature` are designed according to [JVMS 4.7.9.1 Signatures](https://docs.oracle.com/javase/specs/jvms/se19/html/jvms-4.html#jvms-4.7.9.1)

The production is the same as the one I quoted, but thanks for pointing me at the correct one. So:


JavaTypeSignature:
   ReferenceTypeSignature
   BaseType 


and


ReferenceTypeSignature:
   ClassTypeSignature
   TypeVariableSignature
   ArrayTypeSignature


So, while I can expect that `ArrayTypeSignature` *is a* `Signature` (or `JavaTypeSignature`), I cannot explain why `ThrowsSignature` extends `Signature`. That doesn't seem to follow from the production. That is, if a client obtains a `Signature` and wanted to pattern match, what are the cases it should worry about? I believe the cases are the ones listed above.

One thing I missed is that e.g. `TypeParam` is *not* a signature (which is the only case among the nested classes in `Signature`). But `ThrowsSignature`, `TypeArg` and `TypeParam` are signatures even though that doesn't seem to be the case when looking at the production in the JVMS. If we want to keep these fine, but I don't think they should extend `Signature`, either directly or indirectly. That is, `Signature` should be a sealed type with 4 leaves (base-type/array/type var/class-type).

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

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

From mcimadamore at openjdk.org  Tue Feb  7 16:25:25 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 7 Feb 2023 16:25:25 GMT
Subject: RFR: 8294982: Implementation of Classfile API [v13]
In-Reply-To: <Ej4u9wRtUuLS5LJhMkXwmown_MGuwR0gH9ruJ1A1g30=.f6405576-6655-4252-9135-ebc77765436e@github.com>
References: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
 <Ej4u9wRtUuLS5LJhMkXwmown_MGuwR0gH9ruJ1A1g30=.f6405576-6655-4252-9135-ebc77765436e@github.com>
Message-ID: <u6VmkXvghsyyf7qwyHyDpcqZ-wVCfFnZgOoB_wiz2-A=.ce2c44e1-81b0-4851-811c-5f4fd3fdda62@github.com>

On Mon, 6 Feb 2023 13:29:10 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> This is root pull request with Classfile API implementation, tests and benchmarks initial drop into JDK.
>> 
>> Following pull requests consolidating JDK class files parsing, generating, and transforming ([JDK-8294957](https://bugs.openjdk.org/browse/JDK-8294957)) will chain to this one.
>> 
>> Classfile API development is tracked at:
>> https://github.com/openjdk/jdk-sandbox/tree/classfile-api-branch
>> 
>> Development branch of consolidated JDK class files parsing, generating, and transforming is at:
>> https://github.com/openjdk/jdk-sandbox/tree/classfile-api-dev-branch
>> 
>> Classfile API [JEP](https://bugs.openjdk.org/browse/JDK-8280389) and [online API documentation](https://htmlpreview.github.io/?https://raw.githubusercontent.com/openjdk/jdk-sandbox/classfile-api-javadoc-branch/doc/classfile-api/javadoc/java.base/jdk/classfile/package-summary.html) is also available.
>> 
>> Please take you time to review this non-trivial JDK addition.
>> 
>> Thank you,
>> Adam
>
> Adam Sotona has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - javadoc fixes
>  - obsolete identifiers and unused imports cleanup
>  - TypeAnnotation.TypePathComponent cleanup

src/java.base/share/classes/jdk/internal/classfile/attribute/CharacterRangeInfo.java line 80:

> 78:      * well as increment and decrement expressions (both prefix and postfix).
> 79:      * <li>{@link jdk.internal.classfile.Classfile#CRT_FLOW_CONTROLLER} An expression
> 80:      * whose value will effect control flow. Flowcon in the following:

This sentence seems hard to parse. If `Flowcon` is the name of an expression in pseudocode, perhaps using `{@code}` would help.

src/java.base/share/classes/jdk/internal/classfile/attribute/CharacterRangeInfo.java line 146:

> 144:      * @param flags the range flags
> 145:      */
> 146:     static CharacterRangeInfo of(int startPc,

I get that the encoding is as per JaCoCo specification. However, I also wonder if the API should provide better accessors and or factories to let clients just reason about line/columns numbers. Or, maybe, provide static helpers to do the encoding/decoding.

src/java.base/share/classes/jdk/internal/classfile/attribute/CodeAttribute.java line 52:

> 50:     byte[] codeArray();
> 51: 
> 52:     int labelToBci(Label label);

Missing javadoc here. (also, this method looks a bit odd in here - but I see uses e.g. in ClassPrinterImpl)

src/java.base/share/classes/jdk/internal/classfile/attribute/ModuleAttribute.java line 132:

> 130:     }
> 131: 
> 132:     static ModuleAttribute of(ModuleDesc moduleName,

Some missing javadoc in this class

src/java.base/share/classes/jdk/internal/classfile/attribute/ModuleExportInfo.java line 107:

> 105:      * @param exportsTo the modules to which this package is exported
> 106:      */
> 107:     static ModuleExportInfo of(PackageEntry exports,

(Here and elsewhere) - should there be factories also taking a PackageDesc (which seems to be an extension of the ClassDesc API, but for packages) ?

src/java.base/share/classes/jdk/internal/classfile/attribute/NestMembersAttribute.java line 72:

> 70:      * @param nestMembers the member classes of the nest
> 71:      */
> 72:     static NestMembersAttribute ofSymbols(List<ClassDesc> nestMembers) {

I see that in some classes we use the `Symbols` prefix, in others we just use `of` - we should try to make the more consistent (in the future).

src/java.base/share/classes/jdk/internal/classfile/attribute/StackMapTableAttribute.java line 68:

> 66:      * A simple stack value.
> 67:      */
> 68:     public enum SimpleVerificationTypeInfo implements VerificationTypeInfo {

I note that in this class we have made the decision to model all the innards (XYZInfo) as nested classes - while in all the other cases XYZInfo are toplevel types. Moving forward, we should pick something consistent.

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

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

From bpb at openjdk.org  Tue Feb  7 16:40:06 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 7 Feb 2023 16:40:06 GMT
Subject: RFR: 8297632: InputStream.transferTo() method should specify what
 the return value should be when the number of bytes transfered is
 larger than Long.MAX_VALUE [v6]
In-Reply-To: <T38kO1hcz3rhpqOOPYmoPl1TlRORJBifQWtXLl10x8Y=.595338d3-df98-4202-95b5-eda88a4ed0a2@github.com>
References: <T38kO1hcz3rhpqOOPYmoPl1TlRORJBifQWtXLl10x8Y=.595338d3-df98-4202-95b5-eda88a4ed0a2@github.com>
Message-ID: <v_KgToOO76ZvAmeGRMZ03QVLzO13iXAQZ6DGFSyfpA0=.c3aa2d43-3019-40d4-baf0-033a20c98bc4@github.com>

> `java.io.InputStream::transferTo` could conceivably return a negative value if the count of bytes transferred overflows a `long`. Modify the method to limit the number of bytes transferred to `Long.MAX_VALUE` per invocation.

Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:

  8297632: Increment recent copyright year to 2023

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11403/files
  - new: https://git.openjdk.org/jdk/pull/11403/files/446771db..b1cd84ec

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

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

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

From smarks at openjdk.org  Tue Feb  7 17:30:42 2023
From: smarks at openjdk.org (Stuart Marks)
Date: Tue, 7 Feb 2023 17:30:42 GMT
Subject: RFR: 8301958: Avoid Arrays.copyOfRange overhead in
 java.lang.String [v5]
In-Reply-To: <cTuycT9n4HMlEf6dR1e4JGfRblzZai5m8ikN0t37qVc=.97f067d2-dd61-4f35-b79a-5717e95f5a4b@github.com>
References: <2pdPoSHz2RJ7YDHOwOyszQMVv0v7FQFOwykfJ-za_e0=.cfe480da-a045-4b9a-bec7-7fffd0f47206@github.com>
 <cTuycT9n4HMlEf6dR1e4JGfRblzZai5m8ikN0t37qVc=.97f067d2-dd61-4f35-b79a-5717e95f5a4b@github.com>
Message-ID: <KL_eDuf3IQ4Twt6c5XGrNydV5-jZ-48QtRXi0DVyxZc=.1aa9b031-9594-44aa-b33d-e987bd98a64b@github.com>

On Tue, 7 Feb 2023 15:25:05 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> This adds a local, specialized `copyBytes` method to `String` that avoids certain redundant range checks and clamping that JIT has issues removing fully.
>> 
>> This has a small but statistically significant effect on `String` microbenchmarks, eg.:
>> 
>> Baseline
>> 
>> Benchmark                                            (size)  Mode  Cnt   Score   Error  Units
>> StringConstructor.newStringFromArray                      7  avgt   15  16.817 ? 0.369  ns/op
>> StringConstructor.newStringFromArrayWithCharset           7  avgt   15  16.866 ? 0.449  ns/op
>> StringConstructor.newStringFromArrayWithCharsetName       7  avgt   15  22.198 ? 0.396  ns/op
>> 
>> 
>> Patch:
>> 
>> Benchmark                                            (size)  Mode  Cnt   Score   Error  Units
>> StringConstructor.newStringFromArray                      7  avgt   15  15.477 ? 0.342  ns/op
>> StringConstructor.newStringFromArrayWithCharset           7  avgt   15  15.557 ? 0.352  ns/op
>> StringConstructor.newStringFromArrayWithCharsetName       7  avgt   15  21.272 ? 0.398  ns/op
>> 
>> 
>> Care has to be taken to ensure preconditions have been checked when using `checkBytes`. In the case of `String(AbstractStringBuilder)` there's a possible pre-existing issue where the constructor might either throw an exception or truncate the buffer if the builder byte array and length is not in agreement (theoretically possible if you clear/remove and call `trimToSize()` concurrently). Adding an explicit check here seem to be the right thing to do regardless of this RFE.
>
> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   copyrights

Marked as reviewed by smarks (Reviewer).

src/java.base/share/classes/java/lang/StringLatin1.java line 763:

> 761:             return "";
> 762:         }
> 763:         return new String(String.copyBytes(val, index, len), LATIN1);

It might be worthwhile putting a comment at the top of this method saying that the caller is required to bounds-check the arguments. It's called from several other classes in this package, so it would be good to document this package-internal contract. I checked the callers and they seem fine.

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

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

From duke at openjdk.org  Tue Feb  7 18:15:22 2023
From: duke at openjdk.org (Scott Gibbons)
Date: Tue, 7 Feb 2023 18:15:22 GMT
Subject: RFR: JDK-8300808: Accelerate Base64 on x86 for AVX2 [v12]
In-Reply-To: <9zN3bjyMEikXYOlpjTy9_QPc-9usYiBJMUFdb-TaVrQ=.e8f65ce9-ac0f-4f8d-9c6b-b39ae1c26cd2@github.com>
References: <9zN3bjyMEikXYOlpjTy9_QPc-9usYiBJMUFdb-TaVrQ=.e8f65ce9-ac0f-4f8d-9c6b-b39ae1c26cd2@github.com>
Message-ID: <XcV7GlyUBxY2yJtbGrTrXQRLWjc_7kIemIB-DnMelcw=.94a5d898-fe0f-42fe-a8d6-0170fe1bbe89@github.com>

> Added code for Base64 acceleration (encode and decode) which will accelerate ~4x for AVX2 platforms.
> 
> Encode performance:
> **Old:**
> 
> Benchmark                      (maxNumBytes)   Mode  Cnt     Score   Error   Units
> Base64Encode.testBase64Encode           1024  thrpt    3  4309.439 ? 2.632  ops/ms
> 
> 
> **New:**
> 
> Benchmark                      (maxNumBytes)   Mode  Cnt      Score     Error   Units
> Base64Encode.testBase64Encode           1024  thrpt    3  24211.397 ? 102.026  ops/ms
> 
> 
> Decode performance:
> **Old:**
> 
> Benchmark                      (errorIndex)  (lineSize)  (maxNumBytes)   Mode  Cnt     Score    Error   Units
> Base64Decode.testBase64Decode           144           4           1024  thrpt    3  3961.768 ? 93.409  ops/ms
> 
> **New:**
> Benchmark                      (errorIndex)  (lineSize)  (maxNumBytes)   Mode  Cnt      Score    Error   Units
> Base64Decode.testBase64Decode           144           4           1024  thrpt    3  14738.051 ? 24.383  ops/ms

Scott Gibbons has updated the pull request incrementally with one additional commit since the last revision:

  Back out change to encode

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12126/files
  - new: https://git.openjdk.org/jdk/pull/12126/files/0a274e5a..d23206db

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12126&range=11
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12126&range=10-11

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

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

From jrose at openjdk.org  Tue Feb  7 18:38:26 2023
From: jrose at openjdk.org (John R Rose)
Date: Tue, 7 Feb 2023 18:38:26 GMT
Subject: RFR: 8301958: Avoid Arrays.copyOfRange overhead in
 java.lang.String [v5]
In-Reply-To: <cTuycT9n4HMlEf6dR1e4JGfRblzZai5m8ikN0t37qVc=.97f067d2-dd61-4f35-b79a-5717e95f5a4b@github.com>
References: <2pdPoSHz2RJ7YDHOwOyszQMVv0v7FQFOwykfJ-za_e0=.cfe480da-a045-4b9a-bec7-7fffd0f47206@github.com>
 <cTuycT9n4HMlEf6dR1e4JGfRblzZai5m8ikN0t37qVc=.97f067d2-dd61-4f35-b79a-5717e95f5a4b@github.com>
Message-ID: <KSk1hqu889HGlNrPb4ii0iI2KXveXUPRYmLoAMcX-7A=.0c4a1af6-3a5e-4e87-9f0b-cdd5e0255628@github.com>

On Tue, 7 Feb 2023 15:25:05 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> This adds a local, specialized `copyBytes` method to `String` that avoids certain redundant range checks and clamping that JIT has issues removing fully.
>> 
>> This has a small but statistically significant effect on `String` microbenchmarks, eg.:
>> 
>> Baseline
>> 
>> Benchmark                                            (size)  Mode  Cnt   Score   Error  Units
>> StringConstructor.newStringFromArray                      7  avgt   15  16.817 ? 0.369  ns/op
>> StringConstructor.newStringFromArrayWithCharset           7  avgt   15  16.866 ? 0.449  ns/op
>> StringConstructor.newStringFromArrayWithCharsetName       7  avgt   15  22.198 ? 0.396  ns/op
>> 
>> 
>> Patch:
>> 
>> Benchmark                                            (size)  Mode  Cnt   Score   Error  Units
>> StringConstructor.newStringFromArray                      7  avgt   15  15.477 ? 0.342  ns/op
>> StringConstructor.newStringFromArrayWithCharset           7  avgt   15  15.557 ? 0.352  ns/op
>> StringConstructor.newStringFromArrayWithCharsetName       7  avgt   15  21.272 ? 0.398  ns/op
>> 
>> 
>> Care has to be taken to ensure preconditions have been checked when using `checkBytes`. In the case of `String(AbstractStringBuilder)` there's a possible pre-existing issue where the constructor might either throw an exception or truncate the buffer if the builder byte array and length is not in agreement (theoretically possible if you clear/remove and call `trimToSize()` concurrently). Adding an explicit check here seem to be the right thing to do regardless of this RFE.
>
> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   copyrights

Our source code is a reference implementation, and people will look at this change as evidence that `Arrays::copyOfRange` should be hand-inlined by savvy coders.  Surely we could also fix this small performance pothole by improving C2?s treatment of `Arrays.copyOfRange`.  That would benefit all users as well, not just `String`.  That is our preferred way to handle things.

On the other hand, `String` is an important class and worthy of every tiny tweak we give it.  Do we need this fix now?  If so, I suggest putting in a comment in the code which says something like ?normally one would use Arrays.copyOfRange here, but we get slightly better code in this particular case?.  Also, regarding the bug against the JIT, I suggest that we back out this change to `String` when that JIT bug is fixed.  Perhaps the comment in `String` should reference that bug.

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

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

From lancea at openjdk.org  Tue Feb  7 18:42:14 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Tue, 7 Feb 2023 18:42:14 GMT
Subject: RFR: 8301767: Convert virtual thread tests to JUnit
In-Reply-To: <37UDjOGF9PZxUiP2BwkrfIKh82vQgdvA8pwxaln4pl8=.5f368aea-d8a2-4e4a-a6ae-4376e1f05c9b@github.com>
References: <37UDjOGF9PZxUiP2BwkrfIKh82vQgdvA8pwxaln4pl8=.5f368aea-d8a2-4e4a-a6ae-4376e1f05c9b@github.com>
Message-ID: <LRtKXRE4cHAMZKH1J_Mt2rPxMxf_L-xaaiWHgHtCDwg=.049fdf82-0c34-4734-965e-8a3495a2baf7@github.com>

On Sat, 4 Feb 2023 08:59:29 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> The non-hotspot tests integrated with JEP 425/428 were mostly TestNG tests. We'd like to convert these JUnit in the main line in advance of other updates to these tests in 21.  The changes are mostly mechanical and trivial:
> 
> - BeforeClass/AfterClass changed to static BeforeAll/AfterAll methods
> - Tests using data providers are changed to parameterized tests
> - The order of the parameters to assertEquals are swapped so that the expected result is the first parameter
> - Usages of expectThrows are changed to assertThrows
> - Tests that threw SkipException are changed to the Assumptions API
> 
> There are a small number of drive-by changes to the tests, nothing significant, e.g.
> 
> - GetStackTrace and ParkWithFixedThreadPool changed from "@run testng" to "@run main" as they aren't TestNG tests.
> - A few of the tests in StructuredTaskScopeTest for joinXXX are changed to use a CountDownLatch rather than sleeping, as the original tests weren't very robust.

Changes look good Alan

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

Marked as reviewed by lancea (Reviewer).

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

From redestad at openjdk.org  Tue Feb  7 19:15:24 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Tue, 7 Feb 2023 19:15:24 GMT
Subject: RFR: 8301958: Avoid Arrays.copyOfRange overhead in
 java.lang.String [v5]
In-Reply-To: <KSk1hqu889HGlNrPb4ii0iI2KXveXUPRYmLoAMcX-7A=.0c4a1af6-3a5e-4e87-9f0b-cdd5e0255628@github.com>
References: <2pdPoSHz2RJ7YDHOwOyszQMVv0v7FQFOwykfJ-za_e0=.cfe480da-a045-4b9a-bec7-7fffd0f47206@github.com>
 <cTuycT9n4HMlEf6dR1e4JGfRblzZai5m8ikN0t37qVc=.97f067d2-dd61-4f35-b79a-5717e95f5a4b@github.com>
 <KSk1hqu889HGlNrPb4ii0iI2KXveXUPRYmLoAMcX-7A=.0c4a1af6-3a5e-4e87-9f0b-cdd5e0255628@github.com>
Message-ID: <1zJhHKlcmcdG4esZSosLoSjgWyquJcrl_to3NkurO7s=.03310338-b931-4a8b-bd20-f0727e023f99@github.com>

On Tue, 7 Feb 2023 18:35:32 GMT, John R Rose <jrose at openjdk.org> wrote:

> Our source code is a reference implementation, and people will look at this change as evidence that `Arrays::copyOfRange` should be hand-inlined by savvy coders. Surely we could also fix this small performance pothole by improving C2?s treatment of `Arrays.copyOfRange`. That would benefit all users as well, not just `String`. That is our preferred way to handle things.
> 
> On the other hand, `String` is an important class and worthy of every tiny tweak we give it. Do we need this fix now? If so, I suggest putting in a comment in the code which says something like ?normally one would use Arrays.copyOfRange here, but we get slightly better code in this particular case?. Also, regarding the bug against the JIT, I suggest that we back out this change to `String` when that JIT bug is fixed. Perhaps the comment in `String` should reference that bug.

It might be that the redundant checks in `Arrays.copyOfRange` would be eliminated properly with more inlining, and that the issue here is that the affected `String` constructor is particularly gnarly. This gnarliness is due 1) the need to construct the `value` and `coder` in one go and 2) the lack of multiple return values. Give me a value-based record type so we can split apart the constructor into charset-specific methods with zero overhead and we might be able to split up the logic into better-sized chunks.

But yes, I will add some commentary to the effect that this should ideally be handled by our JIT, along with comments that the method deliberately avoids safety checks.

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

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

From smarks at openjdk.org  Tue Feb  7 19:26:49 2023
From: smarks at openjdk.org (Stuart Marks)
Date: Tue, 7 Feb 2023 19:26:49 GMT
Subject: RFR: 8301958: Avoid Arrays.copyOfRange overhead in
 java.lang.String [v5]
In-Reply-To: <1zJhHKlcmcdG4esZSosLoSjgWyquJcrl_to3NkurO7s=.03310338-b931-4a8b-bd20-f0727e023f99@github.com>
References: <2pdPoSHz2RJ7YDHOwOyszQMVv0v7FQFOwykfJ-za_e0=.cfe480da-a045-4b9a-bec7-7fffd0f47206@github.com>
 <cTuycT9n4HMlEf6dR1e4JGfRblzZai5m8ikN0t37qVc=.97f067d2-dd61-4f35-b79a-5717e95f5a4b@github.com>
 <KSk1hqu889HGlNrPb4ii0iI2KXveXUPRYmLoAMcX-7A=.0c4a1af6-3a5e-4e87-9f0b-cdd5e0255628@github.com>
 <1zJhHKlcmcdG4esZSosLoSjgWyquJcrl_to3NkurO7s=.03310338-b931-4a8b-bd20-f0727e023f99@github.com>
Message-ID: <5OEUTSVjJxqfeM8fJbDCkiw48A83X85-dORQXPoZXeQ=.aaffe5dd-6370-4b6c-b353-6cf8871b45a4@github.com>

On Tue, 7 Feb 2023 19:12:38 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> It might be that the redundant checks in Arrays.copyOfRange would be eliminated properly with more inlining, and that the issue here is that the affected String constructor is particularly gnarly. This gnarliness is due 1) the need to construct the value and coder in one go and 2) the lack of multiple return values. Give me a value-based record type so we can split apart the constructor into charset-specific methods with zero overhead and we might be able to split up the logic into better-sized chunks.

I'm wondering if another contributing factor to the complexity of this code is the continued support of the non-compact-String codepaths. This means there are actually three code paths through every string computation. Do we need to continue to support the non-compact-string code paths? I'm concerned about maintainability too.

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

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

From duke at openjdk.org  Tue Feb  7 19:33:23 2023
From: duke at openjdk.org (Matthew Donovan)
Date: Tue, 7 Feb 2023 19:33:23 GMT
Subject: RFR: 8298939: Refactor
 open/test/jdk/javax/rmi/ssl/SSLSocketParametersTest.sh to jtreg java test [v2]
In-Reply-To: <VC_ou2XS44PtyTfwXw0VZRtXcHEbXImlLZKniIPRqOw=.7d10a168-77f8-4552-97a3-8b2570e3fe29@github.com>
References: <VC_ou2XS44PtyTfwXw0VZRtXcHEbXImlLZKniIPRqOw=.7d10a168-77f8-4552-97a3-8b2570e3fe29@github.com>
Message-ID: <S5lhPxcQWHQlgHCv40I7JE4rzk6kFRNItQMWPcesDkw=.fd59517e-1fd2-446d-b1a8-8f6f7d277c6a@github.com>

> Removed SSLSocketParametersTest.sh script (which just called a Java file) and configured the java code to run directly with jtreg

Matthew Donovan has updated the pull request incrementally with one additional commit since the last revision:

  clarified cases 4 and 5

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11910/files
  - new: https://git.openjdk.org/jdk/pull/11910/files/ac9cbfcf..5bd4f2cf

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

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

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

From duke at openjdk.org  Tue Feb  7 19:33:24 2023
From: duke at openjdk.org (Matthew Donovan)
Date: Tue, 7 Feb 2023 19:33:24 GMT
Subject: RFR: 8298939: Refactor
 open/test/jdk/javax/rmi/ssl/SSLSocketParametersTest.sh to jtreg java test [v2]
In-Reply-To: <7cBm5g5RZOvI13OmoGWpt45cfjIPgXMZFENVNHdcSn8=.850c3665-962f-4975-ba4f-4e8152fd6106@github.com>
References: <VC_ou2XS44PtyTfwXw0VZRtXcHEbXImlLZKniIPRqOw=.7d10a168-77f8-4552-97a3-8b2570e3fe29@github.com>
 <0he17_UqLW1xZFjtb1R1AB8VbvZrqERfOmdmwnKm5tI=.5e343b27-6e26-41ae-a876-e4a799b23a66@github.com>
 <gCvIHE_VLLddikdJ377nerMbvLT9uRSuX6CjJz0Kfxo=.2d9aa3ac-dee9-4a2d-89ce-5ce755063279@github.com>
 <7cBm5g5RZOvI13OmoGWpt45cfjIPgXMZFENVNHdcSn8=.850c3665-962f-4975-ba4f-4e8152fd6106@github.com>
Message-ID: <TNK1fORyByBUzU3Un1MOKJ5GDVvtSqi8thMOUnAJ6Tg=.5b8afa50-0084-4907-887e-bfc75f2404a2@github.com>

On Tue, 7 Feb 2023 16:13:40 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> The expected result of cases 4 and 5 is that an IllegalArgumentException is thrown because of the unsupported ciphersuite. The original code just caught `Exception` which would hide a problem in the test e.g., if `SSLContext.getDefault()` throws the NoSuchAlgorithmException.
>
> OK - but the run( ) method catches IllegalArgumentException already?

The exception is actually being thrown from the `ServerFactory` constructor.  I updated the code to remove the call to `run()` and added a comment clarifying the exception handling.

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

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

From redestad at openjdk.org  Tue Feb  7 19:40:43 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Tue, 7 Feb 2023 19:40:43 GMT
Subject: RFR: 8301958: Avoid Arrays.copyOfRange overhead in
 java.lang.String [v5]
In-Reply-To: <5OEUTSVjJxqfeM8fJbDCkiw48A83X85-dORQXPoZXeQ=.aaffe5dd-6370-4b6c-b353-6cf8871b45a4@github.com>
References: <2pdPoSHz2RJ7YDHOwOyszQMVv0v7FQFOwykfJ-za_e0=.cfe480da-a045-4b9a-bec7-7fffd0f47206@github.com>
 <cTuycT9n4HMlEf6dR1e4JGfRblzZai5m8ikN0t37qVc=.97f067d2-dd61-4f35-b79a-5717e95f5a4b@github.com>
 <KSk1hqu889HGlNrPb4ii0iI2KXveXUPRYmLoAMcX-7A=.0c4a1af6-3a5e-4e87-9f0b-cdd5e0255628@github.com>
 <1zJhHKlcmcdG4esZSosLoSjgWyquJcrl_to3NkurO7s=.03310338-b931-4a8b-bd20-f0727e023f99@github.com>
 <5OEUTSVjJxqfeM8fJbDCkiw48A83X85-dORQXPoZXeQ=.aaffe5dd-6370-4b6c-b353-6cf8871b45a4@github.com>
Message-ID: <YmWhVUsssP1SOTQTB6Zg6PEoG8XLwCXaF9c5Y3suQqE=.ba15f898-30b2-400d-8ca9-297cbcbba4f3@github.com>

On Tue, 7 Feb 2023 19:24:11 GMT, Stuart Marks <smarks at openjdk.org> wrote:

> > It might be that the redundant checks in Arrays.copyOfRange would be eliminated properly with more inlining, and that the issue here is that the affected String constructor is particularly gnarly. This gnarliness is due 1) the need to construct the value and coder in one go and 2) the lack of multiple return values. Give me a value-based record type so we can split apart the constructor into charset-specific methods with zero overhead and we might be able to split up the logic into better-sized chunks.
> 
> I'm wondering if another contributing factor to the complexity of this code is the continued support of the non-compact-String codepaths. This means there are actually three code paths through every string computation. Do we need to continue to support the non-compact-string code paths? I'm concerned about maintainability too.

I think most apps have sufficient ASCII/latin1-encodable data to make compact strings a net win. Especially with recent improvements to key intrinsics that has narrowed the gap. 

I still think turning off compact strings might be beneficial in locales where most strings are UTF-16, but as you say there might be wins to maintainability and code complexity by ripping out `-XX:-CompactStrings` (which could mean a net performance win for all).

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

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

From duke at openjdk.org  Tue Feb  7 19:48:30 2023
From: duke at openjdk.org (Francesco Nigro)
Date: Tue, 7 Feb 2023 19:48:30 GMT
Subject: RFR: 8301958: Avoid Arrays.copyOfRange overhead in
 java.lang.String [v5]
In-Reply-To: <cTuycT9n4HMlEf6dR1e4JGfRblzZai5m8ikN0t37qVc=.97f067d2-dd61-4f35-b79a-5717e95f5a4b@github.com>
References: <2pdPoSHz2RJ7YDHOwOyszQMVv0v7FQFOwykfJ-za_e0=.cfe480da-a045-4b9a-bec7-7fffd0f47206@github.com>
 <cTuycT9n4HMlEf6dR1e4JGfRblzZai5m8ikN0t37qVc=.97f067d2-dd61-4f35-b79a-5717e95f5a4b@github.com>
Message-ID: <mzLzktb_CCmvPSXUpir8ZP1xGFW_7ktZFoXNXp-VDs4=.5501a144-449b-46a0-820c-5c2324855a35@github.com>

On Tue, 7 Feb 2023 15:25:05 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> This adds a local, specialized `copyBytes` method to `String` that avoids certain redundant range checks and clamping that JIT has issues removing fully.
>> 
>> This has a small but statistically significant effect on `String` microbenchmarks, eg.:
>> 
>> Baseline
>> 
>> Benchmark                                            (size)  Mode  Cnt   Score   Error  Units
>> StringConstructor.newStringFromArray                      7  avgt   15  16.817 ? 0.369  ns/op
>> StringConstructor.newStringFromArrayWithCharset           7  avgt   15  16.866 ? 0.449  ns/op
>> StringConstructor.newStringFromArrayWithCharsetName       7  avgt   15  22.198 ? 0.396  ns/op
>> 
>> 
>> Patch:
>> 
>> Benchmark                                            (size)  Mode  Cnt   Score   Error  Units
>> StringConstructor.newStringFromArray                      7  avgt   15  15.477 ? 0.342  ns/op
>> StringConstructor.newStringFromArrayWithCharset           7  avgt   15  15.557 ? 0.352  ns/op
>> StringConstructor.newStringFromArrayWithCharsetName       7  avgt   15  21.272 ? 0.398  ns/op
>> 
>> 
>> Care has to be taken to ensure preconditions have been checked when using `checkBytes`. In the case of `String(AbstractStringBuilder)` there's a possible pre-existing issue where the constructor might either throw an exception or truncate the buffer if the builder byte array and length is not in agreement (theoretically possible if you clear/remove and call `trimToSize()` concurrently). Adding an explicit check here seem to be the right thing to do regardless of this RFE.
>
> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   copyrights

Thanks @cl4es to look into this!

src/java.base/share/classes/java/lang/String.java line 698:

> 696:     }
> 697: 
> 698:     static byte[] copyBytes(byte[] bytes, int offset, int length) {

Given that the stub generated for array copy seems highly dependent by the call site constrains, did you tried adding a check for offset == 0 and/or length == bytes.length?

If (offset == 0 && bytes.length == length) {
    System.arrayCopy(bytes, 0, dst, bytes.length);
    // etc etc the other combinations 

This should have different generated stubs with much smaller ASM depending by the enforced constrains

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

Changes requested by franz1981 at github.com (no known OpenJDK username).

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

From jrose at openjdk.org  Tue Feb  7 20:02:43 2023
From: jrose at openjdk.org (John R Rose)
Date: Tue, 7 Feb 2023 20:02:43 GMT
Subject: RFR: 8301958: Avoid Arrays.copyOfRange overhead in
 java.lang.String [v5]
In-Reply-To: <cTuycT9n4HMlEf6dR1e4JGfRblzZai5m8ikN0t37qVc=.97f067d2-dd61-4f35-b79a-5717e95f5a4b@github.com>
References: <2pdPoSHz2RJ7YDHOwOyszQMVv0v7FQFOwykfJ-za_e0=.cfe480da-a045-4b9a-bec7-7fffd0f47206@github.com>
 <cTuycT9n4HMlEf6dR1e4JGfRblzZai5m8ikN0t37qVc=.97f067d2-dd61-4f35-b79a-5717e95f5a4b@github.com>
Message-ID: <mdxpjC53_tcHgHHKn3qCTRGb-zklyeAxNrFKC0lm7O0=.2654ff59-02f6-4018-9b0a-7aaf6252155a@github.com>

On Tue, 7 Feb 2023 15:25:05 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> This adds a local, specialized `copyBytes` method to `String` that avoids certain redundant range checks and clamping that JIT has issues removing fully.
>> 
>> This has a small but statistically significant effect on `String` microbenchmarks, eg.:
>> 
>> Baseline
>> 
>> Benchmark                                            (size)  Mode  Cnt   Score   Error  Units
>> StringConstructor.newStringFromArray                      7  avgt   15  16.817 ? 0.369  ns/op
>> StringConstructor.newStringFromArrayWithCharset           7  avgt   15  16.866 ? 0.449  ns/op
>> StringConstructor.newStringFromArrayWithCharsetName       7  avgt   15  22.198 ? 0.396  ns/op
>> 
>> 
>> Patch:
>> 
>> Benchmark                                            (size)  Mode  Cnt   Score   Error  Units
>> StringConstructor.newStringFromArray                      7  avgt   15  15.477 ? 0.342  ns/op
>> StringConstructor.newStringFromArrayWithCharset           7  avgt   15  15.557 ? 0.352  ns/op
>> StringConstructor.newStringFromArrayWithCharsetName       7  avgt   15  21.272 ? 0.398  ns/op
>> 
>> 
>> Care has to be taken to ensure preconditions have been checked when using `checkBytes`. In the case of `String(AbstractStringBuilder)` there's a possible pre-existing issue where the constructor might either throw an exception or truncate the buffer if the builder byte array and length is not in agreement (theoretically possible if you clear/remove and call `trimToSize()` concurrently). Adding an explicit check here seem to be the right thing to do regardless of this RFE.
>
> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   copyrights

It is at least possible that splitting `Arrays::copyOfRange` would make it inline more readily in all use cases as well as this particular one.

By splitting, in this case, I mean moving the first three lines into a helper routine called `copyArrayChecks`, and returning `newLength` as a result.  That would make it inline better, I?m pretty sure.

It?s sad and true, until we get a better inliner, which of course will disrupt the ecosystem because there is no unique best answer to an inlining problem (if it is complex enough, and they are).  So for now we pretend to be good O-O programmers and code separate concerns in separate methods.

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

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

From dfuchs at openjdk.org  Tue Feb  7 20:13:44 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 7 Feb 2023 20:13:44 GMT
Subject: RFR: 8298939: Refactor
 open/test/jdk/javax/rmi/ssl/SSLSocketParametersTest.sh to jtreg java test [v2]
In-Reply-To: <S5lhPxcQWHQlgHCv40I7JE4rzk6kFRNItQMWPcesDkw=.fd59517e-1fd2-446d-b1a8-8f6f7d277c6a@github.com>
References: <VC_ou2XS44PtyTfwXw0VZRtXcHEbXImlLZKniIPRqOw=.7d10a168-77f8-4552-97a3-8b2570e3fe29@github.com>
 <S5lhPxcQWHQlgHCv40I7JE4rzk6kFRNItQMWPcesDkw=.fd59517e-1fd2-446d-b1a8-8f6f7d277c6a@github.com>
Message-ID: <hh014052n6Tq3tGIIPiTcNkZNYTIYhQ1J033ooALxUc=.0baeaf04-f7d1-467a-b547-7fe43f562c95@github.com>

On Tue, 7 Feb 2023 19:33:23 GMT, Matthew Donovan <duke at openjdk.org> wrote:

>> Removed SSLSocketParametersTest.sh script (which just called a Java file) and configured the java code to run directly with jtreg
>
> Matthew Donovan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   clarified cases 4 and 5

test/jdk/javax/rmi/ssl/SSLSocketParametersTest.java line 184:

> 182:                 try {
> 183:                     new ServerFactory(SSLContext.getDefault(),
> 184:                             new String[]{"dummy_ciphersuite"}, null, false);

what if the constructor doesn't throw any exception? shouldn't the test fail? or should `run` be called in that case?

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

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

From redestad at openjdk.org  Tue Feb  7 20:26:47 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Tue, 7 Feb 2023 20:26:47 GMT
Subject: RFR: 8301958: Avoid Arrays.copyOfRange overhead in
 java.lang.String [v5]
In-Reply-To: <cTuycT9n4HMlEf6dR1e4JGfRblzZai5m8ikN0t37qVc=.97f067d2-dd61-4f35-b79a-5717e95f5a4b@github.com>
References: <2pdPoSHz2RJ7YDHOwOyszQMVv0v7FQFOwykfJ-za_e0=.cfe480da-a045-4b9a-bec7-7fffd0f47206@github.com>
 <cTuycT9n4HMlEf6dR1e4JGfRblzZai5m8ikN0t37qVc=.97f067d2-dd61-4f35-b79a-5717e95f5a4b@github.com>
Message-ID: <b5zKmzJ-iyYqkjihBNmga6O3yi_7JZNPIp1CcufE9Vw=.ffdab533-f3ad-4462-b9a4-b237b481ce1c@github.com>

On Tue, 7 Feb 2023 15:25:05 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> This adds a local, specialized `copyBytes` method to `String` that avoids certain redundant range checks and clamping that JIT has issues removing fully.
>> 
>> This has a small but statistically significant effect on `String` microbenchmarks, eg.:
>> 
>> Baseline
>> 
>> Benchmark                                            (size)  Mode  Cnt   Score   Error  Units
>> StringConstructor.newStringFromArray                      7  avgt   15  16.817 ? 0.369  ns/op
>> StringConstructor.newStringFromArrayWithCharset           7  avgt   15  16.866 ? 0.449  ns/op
>> StringConstructor.newStringFromArrayWithCharsetName       7  avgt   15  22.198 ? 0.396  ns/op
>> 
>> 
>> Patch:
>> 
>> Benchmark                                            (size)  Mode  Cnt   Score   Error  Units
>> StringConstructor.newStringFromArray                      7  avgt   15  15.477 ? 0.342  ns/op
>> StringConstructor.newStringFromArrayWithCharset           7  avgt   15  15.557 ? 0.352  ns/op
>> StringConstructor.newStringFromArrayWithCharsetName       7  avgt   15  21.272 ? 0.398  ns/op
>> 
>> 
>> Care has to be taken to ensure preconditions have been checked when using `checkBytes`. In the case of `String(AbstractStringBuilder)` there's a possible pre-existing issue where the constructor might either throw an exception or truncate the buffer if the builder byte array and length is not in agreement (theoretically possible if you clear/remove and call `trimToSize()` concurrently). Adding an explicit check here seem to be the right thing to do regardless of this RFE.
>
> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   copyrights

> 

Rather than splitting right down the middle isn't it more effective to factor out code that would typically not be executed, such as the exception creation + formatting? That additionally allows the JIT to outline such code altogether, allowing more aggressive inlining of the non-exceptional path(s).

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

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

From redestad at openjdk.org  Tue Feb  7 20:35:17 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Tue, 7 Feb 2023 20:35:17 GMT
Subject: RFR: 8301958: Avoid Arrays.copyOfRange overhead in
 java.lang.String [v5]
In-Reply-To: <mzLzktb_CCmvPSXUpir8ZP1xGFW_7ktZFoXNXp-VDs4=.5501a144-449b-46a0-820c-5c2324855a35@github.com>
References: <2pdPoSHz2RJ7YDHOwOyszQMVv0v7FQFOwykfJ-za_e0=.cfe480da-a045-4b9a-bec7-7fffd0f47206@github.com>
 <cTuycT9n4HMlEf6dR1e4JGfRblzZai5m8ikN0t37qVc=.97f067d2-dd61-4f35-b79a-5717e95f5a4b@github.com>
 <mzLzktb_CCmvPSXUpir8ZP1xGFW_7ktZFoXNXp-VDs4=.5501a144-449b-46a0-820c-5c2324855a35@github.com>
Message-ID: <0BgZdr0gKingBzlE-J4MDoR3iNGCgcb7j4te2LO5Xvg=.94bf5b91-f651-4a15-900b-711ba4de5b4d@github.com>

On Tue, 7 Feb 2023 19:08:59 GMT, Francesco Nigro <duke at openjdk.org> wrote:

>> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   copyrights
>
> src/java.base/share/classes/java/lang/String.java line 698:
> 
>> 696:     }
>> 697: 
>> 698:     static byte[] copyBytes(byte[] bytes, int offset, int length) {
> 
> Given that the stub generated for array copy seems highly dependent by the call site constrains, did you tried adding a check for offset == 0 and/or length == bytes.length?
> 
> If (offset == 0 && bytes.length == length) {
>     System.arrayCopy(bytes, 0, dst, 0, bytes.length);
>     // etc etc the other combinations 
> 
> This should have different generated stubs with much smaller ASM depending by the enforced constrains (and shouldn't affect terribly the code size of the method, given that the stub won't be inlined AFAIK)
> 
> Beware, as noted by others, I'm not suggesting that's the way to fix this, but it would be interesting to check how much perf we leave on the ground due to the this supposed "inefficient" stub generation (if that's the issue).

I did some quick experiments but saw no clear win from doing anything like this here. Feel free to experiment and see if there's some particular configuration that comes out ahead.

FTR I did not intend for this RFE to solve https://bugs.openjdk.org/browse/JDK-8295496 completely, but provide a small, partial win that might possibly clear a path to solving that likely orthogonal issue.

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

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

From duke at openjdk.org  Tue Feb  7 20:38:40 2023
From: duke at openjdk.org (Matthew Donovan)
Date: Tue, 7 Feb 2023 20:38:40 GMT
Subject: RFR: 8298939: Refactor
 open/test/jdk/javax/rmi/ssl/SSLSocketParametersTest.sh to jtreg java test [v3]
In-Reply-To: <VC_ou2XS44PtyTfwXw0VZRtXcHEbXImlLZKniIPRqOw=.7d10a168-77f8-4552-97a3-8b2570e3fe29@github.com>
References: <VC_ou2XS44PtyTfwXw0VZRtXcHEbXImlLZKniIPRqOw=.7d10a168-77f8-4552-97a3-8b2570e3fe29@github.com>
Message-ID: <y65OxkcJ9OlzgC1Q-o62zILzqMIQA9SQk_pg6zdpe7U=.d7745cdf-f803-45bd-a3fb-8d6bb146c2c2@github.com>

> Removed SSLSocketParametersTest.sh script (which just called a Java file) and configured the java code to run directly with jtreg

Matthew Donovan has updated the pull request incrementally with one additional commit since the last revision:

  added exceptions for cases 4 and 5

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11910/files
  - new: https://git.openjdk.org/jdk/pull/11910/files/5bd4f2cf..205226d4

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

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

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

From duke at openjdk.org  Tue Feb  7 20:38:45 2023
From: duke at openjdk.org (Matthew Donovan)
Date: Tue, 7 Feb 2023 20:38:45 GMT
Subject: RFR: 8298939: Refactor
 open/test/jdk/javax/rmi/ssl/SSLSocketParametersTest.sh to jtreg java test [v2]
In-Reply-To: <hh014052n6Tq3tGIIPiTcNkZNYTIYhQ1J033ooALxUc=.0baeaf04-f7d1-467a-b547-7fe43f562c95@github.com>
References: <VC_ou2XS44PtyTfwXw0VZRtXcHEbXImlLZKniIPRqOw=.7d10a168-77f8-4552-97a3-8b2570e3fe29@github.com>
 <S5lhPxcQWHQlgHCv40I7JE4rzk6kFRNItQMWPcesDkw=.fd59517e-1fd2-446d-b1a8-8f6f7d277c6a@github.com>
 <hh014052n6Tq3tGIIPiTcNkZNYTIYhQ1J033ooALxUc=.0baeaf04-f7d1-467a-b547-7fe43f562c95@github.com>
Message-ID: <uWNsA-GBX2mEq1tr0wp_Gf45lsXg2281EEUHuMMxZfQ=.aee092cf-8430-4577-8d62-77e7ff6b5aa8@github.com>

On Tue, 7 Feb 2023 20:10:47 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Matthew Donovan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   clarified cases 4 and 5
>
> test/jdk/javax/rmi/ssl/SSLSocketParametersTest.java line 184:
> 
>> 182:                 try {
>> 183:                     new ServerFactory(SSLContext.getDefault(),
>> 184:                             new String[]{"dummy_ciphersuite"}, null, false);
> 
> what if the constructor doesn't throw any exception? shouldn't the test fail? or should `run` be called in that case?

good catch; yes, the test should fail. I updated these cases.

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

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

From jrose at openjdk.org  Tue Feb  7 20:43:47 2023
From: jrose at openjdk.org (John R Rose)
Date: Tue, 7 Feb 2023 20:43:47 GMT
Subject: RFR: 8301958: Avoid Arrays.copyOfRange overhead in
 java.lang.String [v5]
In-Reply-To: <cTuycT9n4HMlEf6dR1e4JGfRblzZai5m8ikN0t37qVc=.97f067d2-dd61-4f35-b79a-5717e95f5a4b@github.com>
References: <2pdPoSHz2RJ7YDHOwOyszQMVv0v7FQFOwykfJ-za_e0=.cfe480da-a045-4b9a-bec7-7fffd0f47206@github.com>
 <cTuycT9n4HMlEf6dR1e4JGfRblzZai5m8ikN0t37qVc=.97f067d2-dd61-4f35-b79a-5717e95f5a4b@github.com>
Message-ID: <yoiLPHmLoOBIj69WWCNGhGAshF-4fviazqVpd7xmY1k=.e8dfc4a7-006a-4856-abd2-c3b089a3e1fb@github.com>

On Tue, 7 Feb 2023 15:25:05 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> This adds a local, specialized `copyBytes` method to `String` that avoids certain redundant range checks and clamping that JIT has issues removing fully.
>> 
>> This has a small but statistically significant effect on `String` microbenchmarks, eg.:
>> 
>> Baseline
>> 
>> Benchmark                                            (size)  Mode  Cnt   Score   Error  Units
>> StringConstructor.newStringFromArray                      7  avgt   15  16.817 ? 0.369  ns/op
>> StringConstructor.newStringFromArrayWithCharset           7  avgt   15  16.866 ? 0.449  ns/op
>> StringConstructor.newStringFromArrayWithCharsetName       7  avgt   15  22.198 ? 0.396  ns/op
>> 
>> 
>> Patch:
>> 
>> Benchmark                                            (size)  Mode  Cnt   Score   Error  Units
>> StringConstructor.newStringFromArray                      7  avgt   15  15.477 ? 0.342  ns/op
>> StringConstructor.newStringFromArrayWithCharset           7  avgt   15  15.557 ? 0.352  ns/op
>> StringConstructor.newStringFromArrayWithCharsetName       7  avgt   15  21.272 ? 0.398  ns/op
>> 
>> 
>> Care has to be taken to ensure preconditions have been checked when using `checkBytes`. In the case of `String(AbstractStringBuilder)` there's a possible pre-existing issue where the constructor might either throw an exception or truncate the buffer if the builder byte array and length is not in agreement (theoretically possible if you clear/remove and call `trimToSize()` concurrently). Adding an explicit check here seem to be the right thing to do regardless of this RFE.
>
> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   copyrights

You could split it that way as well.  It pushes the inliner a little harder, but doesn?t make it fall over.

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

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

From rriggs at openjdk.org  Tue Feb  7 20:50:14 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 7 Feb 2023 20:50:14 GMT
Subject: RFR: 8301737:
 java/rmi/server/UnicastRemoteObject/serialFilter/FilterUROTest.java fail with
 -Xcomp [v3]
In-Reply-To: <zMo8OEhYAKUz5LWOssEWEUQDoySJo7hsL7_KAzfNU34=.2309b7bb-5e1d-47e8-b932-aedfbce71e5b@github.com>
References: <l5m5_9io2QMSFNY7dBHT3Nr2I9Er8wmd92Ze8FP-XE0=.a40d29be-77be-4719-a0a0-71d032eea1e5@github.com>
 <zMo8OEhYAKUz5LWOssEWEUQDoySJo7hsL7_KAzfNU34=.2309b7bb-5e1d-47e8-b932-aedfbce71e5b@github.com>
Message-ID: <PtGxV9PeStEfGQjHpOaZR5LEhx2BGqzfDORIqE6U2Lk=.b1756e3f-1363-482f-a307-ee80390f7669@github.com>

On Tue, 7 Feb 2023 08:27:57 GMT, SUN Guoyun <duke at openjdk.org> wrote:

>> Hi all,
>> When -Xcomp be used, this testcase will use more codecaches, causing the GC to be triggered early, then causing this test failed on LoongArch64 architecture.
>> 
>> This PR fix the issue, Please help review it.
>> 
>> Thanks.
>
> SUN Guoyun has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8301737: java/rmi/server/UnicastRemoteObject/serialFilter/FilterUROTest.java fail with -Xcomp

I'm going to backup a bit; so another question...
This test is a fairly simple test that should not be taxing on GC or any other resource so I'm surprised the the default configuration is not sufficient.  It might be worth looking a bit deeper into the GC vs Xcomp conditions and the interplay with "looongaarch64".
I can't help much there, not being familiar with details of GC or the compiler.

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

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

From duke at openjdk.org  Tue Feb  7 21:07:05 2023
From: duke at openjdk.org (Francesco Nigro)
Date: Tue, 7 Feb 2023 21:07:05 GMT
Subject: RFR: 8301958: Avoid Arrays.copyOfRange overhead in
 java.lang.String [v5]
In-Reply-To: <0BgZdr0gKingBzlE-J4MDoR3iNGCgcb7j4te2LO5Xvg=.94bf5b91-f651-4a15-900b-711ba4de5b4d@github.com>
References: <2pdPoSHz2RJ7YDHOwOyszQMVv0v7FQFOwykfJ-za_e0=.cfe480da-a045-4b9a-bec7-7fffd0f47206@github.com>
 <cTuycT9n4HMlEf6dR1e4JGfRblzZai5m8ikN0t37qVc=.97f067d2-dd61-4f35-b79a-5717e95f5a4b@github.com>
 <mzLzktb_CCmvPSXUpir8ZP1xGFW_7ktZFoXNXp-VDs4=.5501a144-449b-46a0-820c-5c2324855a35@github.com>
 <0BgZdr0gKingBzlE-J4MDoR3iNGCgcb7j4te2LO5Xvg=.94bf5b91-f651-4a15-900b-711ba4de5b4d@github.com>
Message-ID: <y3KvOzym_1S-1e9g2TZf166VQcIwruwY1hrMowuT1mE=.359685c0-9253-4258-a0c1-106290f0e51d@github.com>

On Tue, 7 Feb 2023 20:32:11 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/String.java line 698:
>> 
>>> 696:     }
>>> 697: 
>>> 698:     static byte[] copyBytes(byte[] bytes, int offset, int length) {
>> 
>> Given that the stub generated for array copy seems highly dependent by the call site constrains, did you tried adding a check for offset == 0 and/or length == bytes.length?
>> 
>> If (offset == 0 && bytes.length == length) {
>>     System.arrayCopy(bytes, 0, dst, 0, bytes.length);
>>     // etc etc the other combinations 
>> 
>> This should have different generated stubs with much smaller ASM depending by the enforced constrains (and shouldn't affect terribly the code size of the method, given that the stub won't be inlined AFAIK)
>> 
>> Beware, as noted by others, I'm not suggesting that's the way to fix this, but it would be interesting to check how much perf we leave on the ground due to the this supposed "inefficient" stub generation (if that's the issue).
>
> I did some quick experiments but saw no clear win from doing anything like this here. Feel free to experiment and see if there's some particular configuration that comes out ahead.
> 
> FTR I did not intend for this RFE to solve https://bugs.openjdk.org/browse/JDK-8295496 completely, but provide a small, partial win that might possibly clear a path to solving that likely orthogonal issue.

I've created a separate benchmark for this (named as your by accident - given that I've used it as a blueprint):
https://gist.github.com/franz1981/658c2bf6796aab4ae04a84bef1ef34b6
results are

Benchmark                             (offset)  (size)  Mode  Cnt   Score   Error  Units
StringConstructor.arrayCopy                  0       7  avgt   10   9.519 ? 0.131  ns/op
StringConstructor.arrayCopy                  1       7  avgt   10   9.194 ? 0.232  ns/op
StringConstructor.copyOf                     0       7  avgt   10  11.548 ? 0.133  ns/op
StringConstructor.copyOf                     1       7  avgt   10   9.812 ? 0.018  ns/op
StringConstructor.optimizedArrayCopy         0       7  avgt   10   6.854 ? 0.355  ns/op    <---- THAT'S COOL
StringConstructor.optimizedArrayCopy         1       7  avgt   10   9.088 ? 0.049  ns/op

the optimized array copy is helping C2 on stub generation.
I didn't checked yet if this applies to the `String` case and I didn't created a long enough dataset array to check the effects on the branch predictor with the newly introduced conditions too, but in term of generated stub, there's a difference.

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

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

From lance.andersen at oracle.com  Tue Feb  7 21:38:49 2023
From: lance.andersen at oracle.com (Lance Andersen)
Date: Tue, 7 Feb 2023 21:38:49 +0000
Subject: RFR: 8301873: Avoid string decoding in ZipFile.Source.getEntryPos
 [v4]
In-Reply-To: <QHObV5Qz9Ygw1cjIooMNFMcXEYlwXUrqpmzvzXeR9-A=.4282ffa4-e17c-4b98-be2f-6b01f8be214d@github.com>
References: <FkmdspiHVjkAKFqm5kUgwaf55YH5cBbczS_3krqsdFs=.05eca901-f55f-47d9-b1bc-0cf2f5b87536@github.com>
 <QHObV5Qz9Ygw1cjIooMNFMcXEYlwXUrqpmzvzXeR9-A=.4282ffa4-e17c-4b98-be2f-6b01f8be214d@github.com>
Message-ID: <BFCB87DC-E42F-49D5-BC05-CDC9C99B0F5B@oracle.com>

This is still on my list to review will get to it in the next day or so

On Feb 7, 2023, at 8:23 AM, Eirik Bjorsnos <duke at openjdk.org<mailto:duke at openjdk.org>> wrote:

After finding a hash match, getEntryPos needs to compare the lookup name up to the encoded entry name in the CEN. This comparison is done by decoding the entry name into a String. The names can then be compared using the String API. This decoding step adds a significat cost to this method.

This PR suggest to update the string comparison such that in the common case where  both the lookup name and the entry name are encoded in ASCII-compatible UTF-8,  decoding can be avoided and the byte arrays can instead be compared direcly.

ZipCoder is updated with a new method to compare a string with an encoded byte array range.  The default implementation decodes to string (like the current code), while the UTF-8 implementation uses JavaLangAccess.getBytesNoRepl to get the  bytes. Both methods thes uses Arrays.mismatch for comparison with or without matching trailing slashes.

Additionally, this PR suggest to make the following updates to getEntryPos:

- The try/catch for IAE is redundant and can be safely removed. (initCEN already checks this and will throws IAE for invalid UTF-8). This seems to give a 3-4% speedup on micros)
- A new test InvalidBytesInEntryNameOrComment is a added to verify that initCEN does in fact reject invalid UTF-8 in CEN file names and comments. (I found no existing test coverage for this)
- The recursion when looking for "name/" matches is replaced with iteration. We keep track of any "name/" match and return it at the end of the search. (I feel this is easier to follow and it also gives a ~30% speedup for addSlash lookups with no regression on regular lookups)

(My though is that including these additional updates in this PR might reduce reviewer overhead given that it touches the exact same code. I might be wrong on this, please advise :)

I'm seeing a ~17% saving on the micro ZipFileGetEntry.getEntryHit (modified to use xalan.jar):

Baseline:

Benchmark                             (size)  Mode  Cnt    Score   Error  Units
ZipFileGetEntry.getEntryHit              512  avgt   15   74.941 ? 1.004  ns/op
ZipFileGetEntry.getEntryHit             1024  avgt   15   84.943 ? 1.320  ns/op
ZipFileGetEntry.getEntryHitUncached      512  avgt   15  120.371 ? 2.386  ns/op
ZipFileGetEntry.getEntryHitUncached     1024  avgt   15  126.128 ? 1.075  ns/op
ZipFileGetEntry.getEntryMiss             512  avgt   15   23.818 ? 0.838  ns/op
ZipFileGetEntry.getEntryMiss            1024  avgt   15   29.762 ? 5.998  ns/op
ZipFileGetEntry.getEntryMissUncached     512  avgt   15   59.405 ? 0.545  ns/op
ZipFileGetEntry.getEntryMissUncached    1024  avgt   15   71.840 ? 2.455  ns/op
ZipFileGetEntry.getEntrySlash            512  avgt   15  135.621 ? 4.341  ns/op
ZipFileGetEntry.getEntrySlash           1024  avgt   15  134.190 ? 2.141  ns/op



PR:


Benchmark                             (size)  Mode  Cnt    Score   Error  Units
ZipFileGetEntry.getEntryHit              512  avgt   15   62.267 ? 1.329  ns/op
ZipFileGetEntry.getEntryHit             1024  avgt   15   72.916 ? 2.428  ns/op
ZipFileGetEntry.getEntryHitUncached      512  avgt   15  101.630 ? 1.154  ns/op
ZipFileGetEntry.getEntryHitUncached     1024  avgt   15  113.161 ? 0.502  ns/op
ZipFileGetEntry.getEntryMiss             512  avgt   15   23.003 ? 1.191  ns/op
ZipFileGetEntry.getEntryMiss            1024  avgt   15   23.236 ? 1.114  ns/op
ZipFileGetEntry.getEntryMissUncached     512  avgt   15   56.781 ? 1.505  ns/op
ZipFileGetEntry.getEntryMissUncached    1024  avgt   15   67.767 ? 1.963  ns/op
ZipFileGetEntry.getEntrySlash            512  avgt   15   73.745 ? 2.717  ns/op
ZipFileGetEntry.getEntrySlash           1024  avgt   15   75.784 ? 1.051  ns/op


To assess the impact on startup/warmup, I made a main method class which measures the total time of calling ZipFile.getEntry for all entries in the 109 JAR file dependenies of spring-petclinic. The shows a nice improvement (time in micros):


Percentile Baseline Patch
50 %          23155 21149
75 %          23598 21454
90 %          23989 21691
95 %          24238 21973
99 %          25270 22446
STDEV           792   549
Count           500   500

Eirik Bjorsnos 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 'master' into getentrypos-prefixmatch
- Fix incorrect offset for the CEN "length of extra field". Fixed spelling of "invalid".
- Spelling fix in test data for non-ascii latin1 string
- Replace new shared secret with using getBytesNoRepl in UTF8ZipCoder.compare. Add a test case for UTF-8 encoded entry name which is latin1, but not ASCII
- Rename test to InvalidBytesInEntryNameOrComment
- Adjust whitespace
- Some minor improvements to code comments
- Micros seem to indicate that the range checks in Arrays.mismatch might have as much as 5% regression
- Move String/byte[] comparison into ZipCoder. Change the default implementation to decode to string for comparison instead of encoding to bytes, this seems safer. Revert some changes from previous commits to parameters in the hasTrailingSlash method.
- ByteBuffers for reading ZIP files must be little-endian
- ... and 10 more: https://git.openjdk.org/jdk/compare/23f44474...06047377

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

Changes:
 - all: https://git.openjdk.org/jdk/pull/12290/files
 - new: https://git.openjdk.org/jdk/pull/12290/files/2c5e7c2c..06047377

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

 Stats: 22651 lines in 906 files changed: 9116 ins; 4377 del; 9158 mod
 Patch: https://git.openjdk.org/jdk/pull/12290.diff
 Fetch: git fetch https://git.openjdk.org/jdk pull/12290/head:pull/12290

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

[cid:E1C4E2F0-ECD0-4C9D-ADB4-B16CA7BCB7FC at home]






Lance Andersen | Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering
1 Network Drive
Burlington, MA 01803
Lance.Andersen at oracle.com<mailto:Lance.Andersen at oracle.com>



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20230207/e873a076/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: oracle_sig_logo.gif
Type: image/gif
Size: 658 bytes
Desc: oracle_sig_logo.gif
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20230207/e873a076/oracle_sig_logo-0001.gif>

From mchung at openjdk.org  Tue Feb  7 22:32:32 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Tue, 7 Feb 2023 22:32:32 GMT
Subject: RFR: JDK-8301462: Convert Permission files to use lambda after
 JDK-8076596
Message-ID: <HVWMALUhjljFTe0W9OlvK7CfpFgg4z3Um8V6ChTHA18=.cf1fb1d5-3594-4e97-beb6-144b6a726bf0@github.com>

A trivial fix.   Convert the use of anonymous inner classes in a few Permission classes to lambdas to work around JDK-8076596, which has been resolved.

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

Commit messages:
 - JDK-8301462: Convert Permission files to use lambda after JDK-8076596

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

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

From redestad at openjdk.org  Tue Feb  7 22:43:15 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Tue, 7 Feb 2023 22:43:15 GMT
Subject: RFR: 8301958: Avoid Arrays.copyOfRange overhead in
 java.lang.String [v6]
In-Reply-To: <2pdPoSHz2RJ7YDHOwOyszQMVv0v7FQFOwykfJ-za_e0=.cfe480da-a045-4b9a-bec7-7fffd0f47206@github.com>
References: <2pdPoSHz2RJ7YDHOwOyszQMVv0v7FQFOwykfJ-za_e0=.cfe480da-a045-4b9a-bec7-7fffd0f47206@github.com>
Message-ID: <o6IxgDxmt3ws5xy1YiHnblHIcGC7svB3hraCHhR5XDc=.d779b699-cb69-4290-86d3-02367d148a4f@github.com>

> This adds a local, specialized `copyBytes` method to `String` that avoids certain redundant range checks and clamping that JIT has issues removing fully.
> 
> This has a small but statistically significant effect on `String` microbenchmarks, eg.:
> 
> Baseline
> 
> Benchmark                                            (size)  Mode  Cnt   Score   Error  Units
> StringConstructor.newStringFromArray                      7  avgt   15  16.817 ? 0.369  ns/op
> StringConstructor.newStringFromArrayWithCharset           7  avgt   15  16.866 ? 0.449  ns/op
> StringConstructor.newStringFromArrayWithCharsetName       7  avgt   15  22.198 ? 0.396  ns/op
> 
> 
> Patch:
> 
> Benchmark                                            (size)  Mode  Cnt   Score   Error  Units
> StringConstructor.newStringFromArray                      7  avgt   15  15.477 ? 0.342  ns/op
> StringConstructor.newStringFromArrayWithCharset           7  avgt   15  15.557 ? 0.352  ns/op
> StringConstructor.newStringFromArrayWithCharsetName       7  avgt   15  21.272 ? 0.398  ns/op
> 
> 
> Care has to be taken to ensure preconditions have been checked when using `checkBytes`. In the case of `String(AbstractStringBuilder)` there's a possible pre-existing issue where the constructor might either throw an exception or truncate the buffer if the builder byte array and length is not in agreement (theoretically possible if you clear/remove and call `trimToSize()` concurrently). Adding an explicit check here seem to be the right thing to do regardless of this RFE.

Claes Redestad has updated the pull request incrementally with two additional commits since the last revision:

 - Apply @franz1981's idea but directly to Arrays.copyOfRange, factoring out range checks and helping JIT pick the best arraycopy adapter
 - Back out all changes except micro

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12453/files
  - new: https://git.openjdk.org/jdk/pull/12453/files/cece6f80..72138930

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

  Stats: 62 lines in 4 files changed: 24 ins; 8 del; 30 mod
  Patch: https://git.openjdk.org/jdk/pull/12453.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12453/head:pull/12453

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

From redestad at openjdk.org  Tue Feb  7 22:47:45 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Tue, 7 Feb 2023 22:47:45 GMT
Subject: RFR: 8301958: Avoid Arrays.copyOfRange overhead in
 java.lang.String [v5]
In-Reply-To: <mzLzktb_CCmvPSXUpir8ZP1xGFW_7ktZFoXNXp-VDs4=.5501a144-449b-46a0-820c-5c2324855a35@github.com>
References: <2pdPoSHz2RJ7YDHOwOyszQMVv0v7FQFOwykfJ-za_e0=.cfe480da-a045-4b9a-bec7-7fffd0f47206@github.com>
 <cTuycT9n4HMlEf6dR1e4JGfRblzZai5m8ikN0t37qVc=.97f067d2-dd61-4f35-b79a-5717e95f5a4b@github.com>
 <mzLzktb_CCmvPSXUpir8ZP1xGFW_7ktZFoXNXp-VDs4=.5501a144-449b-46a0-820c-5c2324855a35@github.com>
Message-ID: <DvxdHBOrzFJZK2Q-SZ-AddVDDuOAyso60f_lzNKtNgY=.06ea8de2-d537-4c61-8515-2c4c42bfd651@github.com>

On Tue, 7 Feb 2023 19:10:08 GMT, Francesco Nigro <duke at openjdk.org> wrote:

>> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   copyrights
>
> Thanks @cl4es to look into this!

@franz1981 idea seems to apply nicely here, and going back and applying it to `Arrays.copyOfRange` end up on top for the common case where `copyOfRange` copies the entire range:


Benchmark                                            (size)  Mode  Cnt   Score   Error  Units
StringConstructor.newStringFromArray                      7  avgt   15  14.666 ? 0.336  ns/op
StringConstructor.newStringFromArrayWithCharset           7  avgt   15  14.582 ? 0.288  ns/op
StringConstructor.newStringFromArrayWithCharsetName       7  avgt   15  20.339 ? 0.328  ns/op


We might still benefit for some cases to specialize a `copyBytes` method, but this solution might help more cases. If others agree I might take a step back and apply this optimization to all the `copyOfRange` methods and add some microbenchmarking to verify this more widely.

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

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

From redestad at openjdk.org  Tue Feb  7 22:54:46 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Tue, 7 Feb 2023 22:54:46 GMT
Subject: RFR: 8301873: Avoid string decoding in ZipFile.Source.getEntryPos
 [v4]
In-Reply-To: <QHObV5Qz9Ygw1cjIooMNFMcXEYlwXUrqpmzvzXeR9-A=.4282ffa4-e17c-4b98-be2f-6b01f8be214d@github.com>
References: <FkmdspiHVjkAKFqm5kUgwaf55YH5cBbczS_3krqsdFs=.05eca901-f55f-47d9-b1bc-0cf2f5b87536@github.com>
 <QHObV5Qz9Ygw1cjIooMNFMcXEYlwXUrqpmzvzXeR9-A=.4282ffa4-e17c-4b98-be2f-6b01f8be214d@github.com>
Message-ID: <gfoFEViv2qZrDUuwbVWROrXkrVMoopJgIg0kdwm1kKg=.be54ea9c-b144-457c-8cb6-021be0ea8d75@github.com>

On Tue, 7 Feb 2023 13:23:26 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

>> After finding a hash match, getEntryPos needs to compare the lookup name up to the encoded entry name in the CEN. This comparison is done by decoding the entry name into a String. The names can then be compared using the String API. This decoding step adds a significat cost to this method.
>> 
>> This PR suggest to update the string comparison such that in the common case where  both the lookup name and the entry name are encoded in ASCII-compatible UTF-8,  decoding can be avoided and the byte arrays can instead be compared direcly. 
>> 
>> ZipCoder is updated with a new method to compare a string with an encoded byte array range.  The default implementation decodes to string (like the current code), while the UTF-8 implementation uses JavaLangAccess.getBytesNoRepl to get the  bytes. Both methods thes uses Arrays.mismatch for comparison with or without matching trailing slashes. 
>> 
>> Additionally, this PR suggest to make the following updates to getEntryPos:
>> 
>> - The try/catch for IAE is redundant and can be safely removed. (initCEN already checks this and will throws IAE for invalid UTF-8). This seems to give a 3-4% speedup on micros)
>> - A new test InvalidBytesInEntryNameOrComment is a added to verify that initCEN does in fact reject invalid UTF-8 in CEN file names and comments. (I found no existing test coverage for this)
>> - The recursion when looking for "name/" matches is replaced with iteration. We keep track of any "name/" match and return it at the end of the search. (I feel this is easier to follow and it also gives a ~30% speedup for addSlash lookups with no regression on regular lookups)
>> 
>> (My though is that including these additional updates in this PR might reduce reviewer overhead given that it touches the exact same code. I might be wrong on this, please advise :)
>> 
>> I'm seeing a ~17% saving on the micro ZipFileGetEntry.getEntryHit (modified to use xalan.jar):
>> 
>> Baseline:
>> 
>> Benchmark                             (size)  Mode  Cnt    Score   Error  Units
>> ZipFileGetEntry.getEntryHit              512  avgt   15   74.941 ? 1.004  ns/op
>> ZipFileGetEntry.getEntryHit             1024  avgt   15   84.943 ? 1.320  ns/op
>> ZipFileGetEntry.getEntryHitUncached      512  avgt   15  120.371 ? 2.386  ns/op
>> ZipFileGetEntry.getEntryHitUncached     1024  avgt   15  126.128 ? 1.075  ns/op
>> ZipFileGetEntry.getEntryMiss             512  avgt   15   23.818 ? 0.838  ns/op
>> ZipFileGetEntry.getEntryMiss            1024  avgt   15   29.762 ? 5.998  ns/op
>> ZipFileGetEntry.getEntryMissUncached     512  avgt   15   59.405 ? 0.545  ns/op
>> ZipFileGetEntry.getEntryMissUncached    1024  avgt   15   71.840 ? 2.455  ns/op
>> ZipFileGetEntry.getEntrySlash            512  avgt   15  135.621 ? 4.341  ns/op
>> ZipFileGetEntry.getEntrySlash           1024  avgt   15  134.190 ? 2.141  ns/op
>> 
>> 
>> 
>> PR:
>> 
>> 
>> Benchmark                             (size)  Mode  Cnt    Score   Error  Units
>> ZipFileGetEntry.getEntryHit              512  avgt   15   62.267 ? 1.329  ns/op
>> ZipFileGetEntry.getEntryHit             1024  avgt   15   72.916 ? 2.428  ns/op
>> ZipFileGetEntry.getEntryHitUncached      512  avgt   15  101.630 ? 1.154  ns/op
>> ZipFileGetEntry.getEntryHitUncached     1024  avgt   15  113.161 ? 0.502  ns/op
>> ZipFileGetEntry.getEntryMiss             512  avgt   15   23.003 ? 1.191  ns/op
>> ZipFileGetEntry.getEntryMiss            1024  avgt   15   23.236 ? 1.114  ns/op
>> ZipFileGetEntry.getEntryMissUncached     512  avgt   15   56.781 ? 1.505  ns/op
>> ZipFileGetEntry.getEntryMissUncached    1024  avgt   15   67.767 ? 1.963  ns/op
>> ZipFileGetEntry.getEntrySlash            512  avgt   15   73.745 ? 2.717  ns/op
>> ZipFileGetEntry.getEntrySlash           1024  avgt   15   75.784 ? 1.051  ns/op
>> 
>> 
>> To assess the impact on startup/warmup, I made a main method class which measures the total time of calling ZipFile.getEntry for all entries in the 109 JAR file dependenies of spring-petclinic. The shows a nice improvement (time in micros):
>> 
>> 
>> Percentile Baseline Patch
>> 50?%          23155 21149
>> 75?%          23598 21454
>> 90?%          23989 21691
>> 95?%          24238 21973
>> 99?%          25270 22446
>> STDEV           792   549
>> Count           500   500
>
> Eirik Bjorsnos 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 'master' into getentrypos-prefixmatch
>  - Fix incorrect offset for the CEN "length of extra field". Fixed spelling of "invalid".
>  - Spelling fix in test data for non-ascii latin1 string
>  - Replace new shared secret with using getBytesNoRepl in UTF8ZipCoder.compare. Add a test case for UTF-8 encoded entry name which is latin1, but not ASCII
>  - Rename test to InvalidBytesInEntryNameOrComment
>  - Adjust whitespace
>  - Some minor improvements to code comments
>  - Micros seem to indicate that the range checks in Arrays.mismatch might have as much as 5% regression
>  - Move String/byte[] comparison into ZipCoder. Change the default implementation to decode to string for comparison instead of encoding to bytes, this seems safer. Revert some changes from previous commits to parameters in the hasTrailingSlash method.
>  - ByteBuffers for reading ZIP files must be little-endian
>  - ... and 10 more: https://git.openjdk.org/jdk/compare/184e3101...06047377

Seems there's a possible real test failure lurking here, might be intermittent since it only showed on one platform:

java.lang.AssertionError: expected [837891402] but found [837891401]
	at org.testng.Assert.fail(Assert.java:99)
	at org.testng.Assert.failNotEquals(Assert.java:1037)
	at org.testng.Assert.assertEqualsImpl(Assert.java:140)
	at org.testng.Assert.assertEquals(Assert.java:122)
	at org.testng.Assert.assertEquals(Assert.java:797)
	at org.testng.Assert.assertEquals(Assert.java:807)
	at TestZipFileEncodings.checkEqual(TestZipFileEncodings.java:153)
	at TestZipFileEncodings.doTest0(TestZipFileEncodings.java:190)
	at TestZipFileEncodings.doTest(TestZipFileEncodings.java:162)
	at TestZipFileEncodings.test(TestZipFileEncodings.java:146)
	at TestZipFileEncodings.testUnicodeManyEntries(TestZipFileEncodings.java:116)```

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

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

From duke at openjdk.org  Tue Feb  7 23:31:45 2023
From: duke at openjdk.org (Francesco Nigro)
Date: Tue, 7 Feb 2023 23:31:45 GMT
Subject: RFR: 8301958: Reduce Arrays.copyOfRange overheads [v6]
In-Reply-To: <o6IxgDxmt3ws5xy1YiHnblHIcGC7svB3hraCHhR5XDc=.d779b699-cb69-4290-86d3-02367d148a4f@github.com>
References: <2pdPoSHz2RJ7YDHOwOyszQMVv0v7FQFOwykfJ-za_e0=.cfe480da-a045-4b9a-bec7-7fffd0f47206@github.com>
 <o6IxgDxmt3ws5xy1YiHnblHIcGC7svB3hraCHhR5XDc=.d779b699-cb69-4290-86d3-02367d148a4f@github.com>
Message-ID: <2vG1hiQmNdalcDXfL-5i6rlagQRRMlnLVMZbpU9qrcA=.4db5d6b1-42a8-4755-9644-acbab5504e79@github.com>

On Tue, 7 Feb 2023 22:43:15 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> This adds a local, specialized `copyBytes` method to `String` that avoids certain redundant range checks and clamping that JIT has issues removing fully.
>> 
>> This has a small but statistically significant effect on `String` microbenchmarks, eg.:
>> 
>> Baseline
>> 
>> Benchmark                                            (size)  Mode  Cnt   Score   Error  Units
>> StringConstructor.newStringFromArray                      7  avgt   15  16.817 ? 0.369  ns/op
>> StringConstructor.newStringFromArrayWithCharset           7  avgt   15  16.866 ? 0.449  ns/op
>> StringConstructor.newStringFromArrayWithCharsetName       7  avgt   15  22.198 ? 0.396  ns/op
>> 
>> 
>> Patch:
>> 
>> Benchmark                                            (size)  Mode  Cnt   Score   Error  Units
>> StringConstructor.newStringFromArray                      7  avgt   15  15.477 ? 0.342  ns/op
>> StringConstructor.newStringFromArrayWithCharset           7  avgt   15  15.557 ? 0.352  ns/op
>> StringConstructor.newStringFromArrayWithCharsetName       7  avgt   15  21.272 ? 0.398  ns/op
>> 
>> 
>> Care has to be taken to ensure preconditions have been checked when using `checkBytes`. In the case of `String(AbstractStringBuilder)` there's a possible pre-existing issue where the constructor might either throw an exception or truncate the buffer if the builder byte array and length is not in agreement (theoretically possible if you clear/remove and call `trimToSize()` concurrently). Adding an explicit check here seem to be the right thing to do regardless of this RFE.
>
> Claes Redestad has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Apply @franz1981's idea but directly to Arrays.copyOfRange, factoring out range checks and helping JIT pick the best arraycopy adapter
>  - Back out all changes except micro

LGTM

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

Marked as reviewed by franz1981 at github.com (no known OpenJDK username).

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

From duke at openjdk.org  Wed Feb  8 00:03:12 2023
From: duke at openjdk.org (Scott Gibbons)
Date: Wed, 8 Feb 2023 00:03:12 GMT
Subject: RFR: JDK-8300808: Accelerate Base64 on x86 for AVX2 [v13]
In-Reply-To: <9zN3bjyMEikXYOlpjTy9_QPc-9usYiBJMUFdb-TaVrQ=.e8f65ce9-ac0f-4f8d-9c6b-b39ae1c26cd2@github.com>
References: <9zN3bjyMEikXYOlpjTy9_QPc-9usYiBJMUFdb-TaVrQ=.e8f65ce9-ac0f-4f8d-9c6b-b39ae1c26cd2@github.com>
Message-ID: <pHWCuWZlVOiv5bKEFr58eTE9pCdeJKhKgdQAD8It1IY=.fca0f4a3-d4a8-485a-90da-4f44a4fe9176@github.com>

> Added code for Base64 acceleration (encode and decode) which will accelerate ~4x for AVX2 platforms.
> 
> Encode performance:
> **Old:**
> 
> Benchmark                      (maxNumBytes)   Mode  Cnt     Score   Error   Units
> Base64Encode.testBase64Encode           1024  thrpt    3  4309.439 ? 2.632  ops/ms
> 
> 
> **New:**
> 
> Benchmark                      (maxNumBytes)   Mode  Cnt      Score     Error   Units
> Base64Encode.testBase64Encode           1024  thrpt    3  24211.397 ? 102.026  ops/ms
> 
> 
> Decode performance:
> **Old:**
> 
> Benchmark                      (errorIndex)  (lineSize)  (maxNumBytes)   Mode  Cnt     Score    Error   Units
> Base64Decode.testBase64Decode           144           4           1024  thrpt    3  3961.768 ? 93.409  ops/ms
> 
> **New:**
> Benchmark                      (errorIndex)  (lineSize)  (maxNumBytes)   Mode  Cnt      Score    Error   Units
> Base64Decode.testBase64Decode           144           4           1024  thrpt    3  14738.051 ? 24.383  ops/ms

Scott Gibbons 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/12126/files
  - new: https://git.openjdk.org/jdk/pull/12126/files/d23206db..d174c43f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12126&range=12
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12126&range=11-12

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

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

From redestad at openjdk.org  Wed Feb  8 00:07:14 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Wed, 8 Feb 2023 00:07:14 GMT
Subject: RFR: 8301958: Reduce Arrays.copyOf/-Range overheads [v7]
In-Reply-To: <2pdPoSHz2RJ7YDHOwOyszQMVv0v7FQFOwykfJ-za_e0=.cfe480da-a045-4b9a-bec7-7fffd0f47206@github.com>
References: <2pdPoSHz2RJ7YDHOwOyszQMVv0v7FQFOwykfJ-za_e0=.cfe480da-a045-4b9a-bec7-7fffd0f47206@github.com>
Message-ID: <n8n_xh_R8sORHd7q5kwEa0kRxoSgBvgaWe_qdliwFFw=.52872c7b-7cb6-4ea4-932f-5d4f57c515eb@github.com>

> This patch adds special-cases to `Arrays.copyOf` and `Arrays.copyOfRange` to clone arrays when `newLength` or range inputs span the input array. This helps eliminate range checks and has been verified to help various String operations. Example:
> 
> Baseline
> 
> Benchmark                                            (size)  Mode  Cnt   Score   Error  Units
> StringConstructor.newStringFromArray                      7  avgt   15  16.817 ? 0.369  ns/op
> StringConstructor.newStringFromArrayWithCharset           7  avgt   15  16.866 ? 0.449  ns/op
> StringConstructor.newStringFromArrayWithCharsetName       7  avgt   15  22.198 ? 0.396  ns/op
> 
> Patch: 
> 
> Benchmark                                            (size)  Mode  Cnt   Score   Error  Units
> StringConstructor.newStringFromArray                      7  avgt   15  14.666 ? 0.336  ns/op
> StringConstructor.newStringFromArrayWithCharset           7  avgt   15  14.582 ? 0.288  ns/op
> StringConstructor.newStringFromArrayWithCharsetName       7  avgt   15  20.339 ? 0.328  ns/op

Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:

  Minimize, force inline, generalize

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12453/files
  - new: https://git.openjdk.org/jdk/pull/12453/files/72138930..c906c730

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

  Stats: 154 lines in 1 file changed: 120 ins; 23 del; 11 mod
  Patch: https://git.openjdk.org/jdk/pull/12453.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12453/head:pull/12453

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

From joehw at openjdk.org  Wed Feb  8 00:23:44 2023
From: joehw at openjdk.org (Joe Wang)
Date: Wed, 8 Feb 2023 00:23:44 GMT
Subject: RFR: 8301269: Update Commons BCEL to Version 6.7.0
Message-ID: <0RNjHfl4qXA0zwLZz10RDxolN96AdrScP27KS1bsT6A=.74cd0696-d037-405d-97eb-be3cbf1e849b@github.com>

Update Commons BCEL in the JDK from 6.5.0 to 6.7.0. 

1. Improvement
   Code modernization (using relatively more modern language features), normalization (such as naming), javadocs, cleanup and minor improvements made up most of the changes. These changes do not change how BCEL works for the XSLT function in the JDK. Many of the changes unfortunately created long lines, for example merging multiple lines into a single long line, not what we would like to have in the JDK, but I have to leave them as they are so that they don't show up as changes in future updates. 

2. Exclusions
   As it has always been, the focus of the BCEL component is to satisfy the needs for the XSLT functionality. Classes not needed for the JDK are excluded as it has been done previously, this is especially true in the util package. The verifier package is also excluded. Methods and sources that have dependencies on the excluded classes are either removed or modified.

3. Deprecation and Warnings
   
   Deprecated classes and contents relying on them are removed or modified to use proper methods without changing the functionality. Deprecated fields in the original source were changed to private ones in previous update in the JDK, however, since the update process applies sources from the upstream again, they were reverted back. In order to not have to go through them on every update, I'll keep the original source this time. 

    Warnings were one of the main reasons for the changes made to the original source. It has been done in the previous update. In this update, many of the previous JDK fixes on warnings have already been addressed in the upstream source as the result of item 1, thus lessoned the needs to reapply the warning patches. Fixed the rest of warnings as they showed up during build.

4. Note that JRocket specific patches are not in the current code base.

5. Test
    Tier2 tests passed.
    JCK XML tests passed.

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

Commit messages:
 - 8301269: Update Commons BCEL to Version 6.7.0

Changes: https://git.openjdk.org/jdk/pull/12464/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12464&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8301269
  Stats: 30510 lines in 334 files changed: 9313 ins; 10828 del; 10369 mod
  Patch: https://git.openjdk.org/jdk/pull/12464.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12464/head:pull/12464

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

From darcy at openjdk.org  Wed Feb  8 00:38:46 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 8 Feb 2023 00:38:46 GMT
Subject: RFR: JDK-8301202: Port fdlibm log to Java
Message-ID: <t0yhKjTMAtSuAZjI0unvr73crUuYEM-2HQ8sUI2_sNU=.82036639-980d-46de-a201-3d85bd84563d@github.com>

Next up on the FDLIBM porting countdown, the log method.

Original C vs transliteration port:


$ diff -w Log.c Log.translit.java 
1c1
< /* __ieee754_log(x)
---
>     /**
51,58c51,52
< 
< #include "fdlibm.h"
< 
< #ifdef __STDC__
< static const double
< #else
< static double
< #endif
---
>     static class Log {
>         private static final  double
70c64
< static double zero   =  0.0;
---
>         private static double zero   =  0.0;
72,78c66
< #ifdef __STDC__
<         double __ieee754_log(double x)
< #else
<         double __ieee754_log(x)
<         double x;
< #endif
< {
---
>         static double compute(double x) {
81c69
<         unsigned lx;
---
>             /*unsigned*/ int lx;
98c86,87
<         __HI(x) = hx|(i^0x3ff00000);    /* normalize x or x/2 */
---
>             // __HI(x) = hx|(i^0x3ff00000);    /* normalize x or x/2 */
>             x =__HI(x, hx|(i^0x3ff00000));    /* normalize x or x/2 */
128a118
>     }


Transliteration port vs more idiomatic port:


$ diff -w  Log.translit.java Log.fdlibm.java 
2c2
<      * Return the logarithm of x
---
>      * Return the (natural) logarithm of x
53,62c53,54
<             ln2_hi  =  6.93147180369123816490e-01,  /* 3fe62e42 fee00000 */
<             ln2_lo  =  1.90821492927058770002e-10,  /* 3dea39ef 35793c76 */
<             two54   =  1.80143985094819840000e+16,  /* 43500000 00000000 */
<             Lg1 = 6.666666666666735130e-01,  /* 3FE55555 55555593 */
<             Lg2 = 3.999999999940941908e-01,  /* 3FD99999 9997FA04 */
<             Lg3 = 2.857142874366239149e-01,  /* 3FD24924 94229359 */
<             Lg4 = 2.222219843214978396e-01,  /* 3FCC71C5 1D8E78AF */
<             Lg5 = 1.818357216161805012e-01,  /* 3FC74664 96CB03DE */
<             Lg6 = 1.531383769920937332e-01,  /* 3FC39A09 D078C69F */
<             Lg7 = 1.479819860511658591e-01;  /* 3FC2F112 DF3E5244 */
---
>             ln2_hi = 0x1.62e42feep-1,       // 6.93147180369123816490e-01
>             ln2_lo = 0x1.a39ef35793c76p-33, // 1.90821492927058770002e-10
64c56,64
<         private static double zero   =  0.0;
---
>             Lg1    = 0x1.5555555555593p-1,  // 6.666666666666735130e-01
>             Lg2    = 0x1.999999997fa04p-2,  // 3.999999999940941908e-01
>             Lg3    = 0x1.2492494229359p-2,  // 2.857142874366239149e-01
>             Lg4    = 0x1.c71c51d8e78afp-3,  // 2.222219843214978396e-01
>             Lg5    = 0x1.7466496cb03dep-3,  // 1.818357216161805012e-01
>             Lg6    = 0x1.39a09d078c69fp-3,  // 1.531383769920937332e-01
>             Lg7    = 0x1.2f112df3e5244p-3;  // 1.479819860511658591e-01
> 
>         private static final double zero = 0.0;
71,72c71,72
<             hx = __HI(x);           /* high word of x */
<             lx = __LO(x);           /* low  word of x */
---
>             hx = __HI(x);           // high word of x
>             lx = __LO(x);           // low  word of x
75,80c75,87
<             if (hx < 0x00100000) {                  /* x < 2**-1022  */
<                 if (((hx&0x7fffffff)|lx)==0)
<                     return -two54/zero;             /* log(+-0)=-inf */
<                 if (hx<0) return (x-x)/zero;        /* log(-#) = NaN */
<                 k -= 54; x *= two54; /* subnormal number, scale up x */
<                 hx = __HI(x);               /* high word of x */
---
>             if (hx < 0x0010_0000) {                  // x < 2**-1022
>                 if (((hx & 0x7fff_ffff) | lx) ==0) { // log(+-0) = -inf
>                     return -TWO54/zero;
>                 }
>                 if (hx < 0) {                        // log(-#) = NaN
>                     return (x - x)/zero;
>                 }
>                 k -= 54;
>                 x *= TWO54;    // subnormal number, scale up x
>                 hx = __HI(x);  // high word of x
>             }
>             if (hx >= 0x7ff0_0000) {
>                 return x+x;
82d88
<             if (hx >= 0x7ff00000) return x+x;
84,87c90,92
<             hx &= 0x000fffff;
<             i = (hx+0x95f64)&0x100000;
<             // __HI(x) = hx|(i^0x3ff00000);    /* normalize x or x/2 */
<             x =__HI(x, hx|(i^0x3ff00000));    /* normalize x or x/2 */
---
>             hx &= 0x000f_ffff;
>             i = (hx + 0x9_5f64) & 0x10_0000;
>             x =__HI(x, hx|(i ^ 0x3ff0_0000));  // normalize x or x/2
90c95
<             if((0x000fffff&(2+hx))<3) {     /* |f| < 2**-20 */
---
>             if ((0x000f_ffff & (2 + hx)) < 3) {// |f| < 2**-20
92,93c97,102
<                     if (k==0) return zero;
<                     else {dk=(double)k; return dk*ln2_hi+dk*ln2_lo;}
---
>                     if (k == 0) {
>                         return zero;
>                     } else {
>                         dk = (double)k;
>                         return dk*ln2_hi + dk*ln2_lo;
>                     }
96,97c105,110
<                 if(k==0) return f-R; else {dk=(double)k;
<                     return dk*ln2_hi-((R-dk*ln2_lo)-f);}
---
>                 if (k == 0) {
>                     return f - R;
>                 } else {
>                     dk = (double)k;
>                     return dk*ln2_hi - ((R - dk*ln2_lo) - f);
>                 }
102c115
<             i = hx-0x6147a;
---
>             i = hx - 0x6_147a;
111c124,126
<                 if(k==0) return f-(hfsq-s*(hfsq+R)); else
---
>                 if (k == 0) {
>                     return f-(hfsq-s*(hfsq+R));
>                 } else {
112a128,131
>                 }
>             } else {
>                 if (k == 0) {
>                     return f - s*(f - R);
114d132
<                 if(k==0) return f-s*(f-R); else
115a134
>                 }


The transliteration port passes the "exhausting" test of all float arguments when run against a JDK 20 build. The idiomatic port matches the transliteration port on the same test.

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

Commit messages:
 - Appease jcheck.
 - Preliminary version of regression test.
 - Switch to hex literals.
 - JDK-8301202: Port fdlibm log to Java

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

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

From darcy at openjdk.org  Wed Feb  8 00:38:48 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 8 Feb 2023 00:38:48 GMT
Subject: RFR: JDK-8301202: Port fdlibm log to Java
In-Reply-To: <t0yhKjTMAtSuAZjI0unvr73crUuYEM-2HQ8sUI2_sNU=.82036639-980d-46de-a201-3d85bd84563d@github.com>
References: <t0yhKjTMAtSuAZjI0unvr73crUuYEM-2HQ8sUI2_sNU=.82036639-980d-46de-a201-3d85bd84563d@github.com>
Message-ID: <weHHYZklR2cB19XZaAbRo7PdxCitH6xtvfzdj9me_h8=.88ce318e-43ce-43c1-a519-15e73a4346c9@github.com>

On Wed, 8 Feb 2023 00:25:32 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Next up on the FDLIBM porting countdown, the log method.
> 
> Original C vs transliteration port:
> 
> 
> $ diff -w Log.c Log.translit.java 
> 1c1
> < /* __ieee754_log(x)
> ---
>>     /**
> 51,58c51,52
> < 
> < #include "fdlibm.h"
> < 
> < #ifdef __STDC__
> < static const double
> < #else
> < static double
> < #endif
> ---
>>     static class Log {
>>         private static final  double
> 70c64
> < static double zero   =  0.0;
> ---
>>         private static double zero   =  0.0;
> 72,78c66
> < #ifdef __STDC__
> <         double __ieee754_log(double x)
> < #else
> <         double __ieee754_log(x)
> <         double x;
> < #endif
> < {
> ---
>>         static double compute(double x) {
> 81c69
> <         unsigned lx;
> ---
>>             /*unsigned*/ int lx;
> 98c86,87
> <         __HI(x) = hx|(i^0x3ff00000);    /* normalize x or x/2 */
> ---
>>             // __HI(x) = hx|(i^0x3ff00000);    /* normalize x or x/2 */
>>             x =__HI(x, hx|(i^0x3ff00000));    /* normalize x or x/2 */
> 128a118
>>     }
> 
> 
> Transliteration port vs more idiomatic port:
> 
> 
> $ diff -w  Log.translit.java Log.fdlibm.java 
> 2c2
> <      * Return the logarithm of x
> ---
>>      * Return the (natural) logarithm of x
> 53,62c53,54
> <             ln2_hi  =  6.93147180369123816490e-01,  /* 3fe62e42 fee00000 */
> <             ln2_lo  =  1.90821492927058770002e-10,  /* 3dea39ef 35793c76 */
> <             two54   =  1.80143985094819840000e+16,  /* 43500000 00000000 */
> <             Lg1 = 6.666666666666735130e-01,  /* 3FE55555 55555593 */
> <             Lg2 = 3.999999999940941908e-01,  /* 3FD99999 9997FA04 */
> <             Lg3 = 2.857142874366239149e-01,  /* 3FD24924 94229359 */
> <             Lg4 = 2.222219843214978396e-01,  /* 3FCC71C5 1D8E78AF */
> <             Lg5 = 1.818357216161805012e-01,  /* 3FC74664 96CB03DE */
> <             Lg6 = 1.531383769920937332e-01,  /* 3FC39A09 D078C69F */
> <             Lg7 = 1.479819860511658591e-01;  /* 3FC2F112 DF3E5244 */
> ---
>>             ln2_hi = 0x1.62e42feep-1,       // 6.93147180369123816490e-01
>>             ln2_lo = 0x1.a39ef35793c76p-33, // 1.90821492927058770002e-10
> 64c56,64
> <         private static double zero   =  0.0;
> ---
>>             Lg1    = 0x1.5555555555593p-1,  // 6.666666666666735130e-01
>>             Lg2    = 0x1.999999997fa04p-2,  // 3.999999999940941908e-01
>>             Lg3    = 0x1.2492494229359p-2,  // 2.857142874366239149e-01
>>             Lg4    = 0x1.c71c51d8e78afp-3,  // 2.222219843214978396e-01
>>             Lg5    = 0x1.7466496cb03dep-3,  // 1.818357216161805012e-01
>>             Lg6    = 0x1.39a09d078c69fp-3,  // 1.531383769920937332e-01
>>             Lg7    = 0x1.2f112df3e5244p-3;  // 1.479819860511658591e-01
>> 
>>         private static final double zero = 0.0;
> 71,72c71,72
> <             hx = __HI(x);           /* high word of x */
> <             lx = __LO(x);           /* low  word of x */
> ---
>>             hx = __HI(x);           // high word of x
>>             lx = __LO(x);           // low  word of x
> 75,80c75,87
> <             if (hx < 0x00100000) {                  /* x < 2**-1022  */
> <                 if (((hx&0x7fffffff)|lx)==0)
> <                     return -two54/zero;             /* log(+-0)=-inf */
> <                 if (hx<0) return (x-x)/zero;        /* log(-#) = NaN */
> <                 k -= 54; x *= two54; /* subnormal number, scale up x */
> <                 hx = __HI(x);               /* high word of x */
> ---
>>             if (hx < 0x0010_0000) {                  // x < 2**-1022
>>                 if (((hx & 0x7fff_ffff) | lx) ==0) { // log(+-0) = -inf
>>                     return -TWO54/zero;
>>                 }
>>                 if (hx < 0) {                        // log(-#) = NaN
>>                     return (x - x)/zero;
>>                 }
>>                 k -= 54;
>>                 x *= TWO54;    // subnormal number, scale up x
>>                 hx = __HI(x);  // high word of x
>>             }
>>             if (hx >= 0x7ff0_0000) {
>>                 return x+x;
> 82d88
> <             if (hx >= 0x7ff00000) return x+x;
> 84,87c90,92
> <             hx &= 0x000fffff;
> <             i = (hx+0x95f64)&0x100000;
> <             // __HI(x) = hx|(i^0x3ff00000);    /* normalize x or x/2 */
> <             x =__HI(x, hx|(i^0x3ff00000));    /* normalize x or x/2 */
> ---
>>             hx &= 0x000f_ffff;
>>             i = (hx + 0x9_5f64) & 0x10_0000;
>>             x =__HI(x, hx|(i ^ 0x3ff0_0000));  // normalize x or x/2
> 90c95
> <             if((0x000fffff&(2+hx))<3) {     /* |f| < 2**-20 */
> ---
>>             if ((0x000f_ffff & (2 + hx)) < 3) {// |f| < 2**-20
> 92,93c97,102
> <                     if (k==0) return zero;
> <                     else {dk=(double)k; return dk*ln2_hi+dk*ln2_lo;}
> ---
>>                     if (k == 0) {
>>                         return zero;
>>                     } else {
>>                         dk = (double)k;
>>                         return dk*ln2_hi + dk*ln2_lo;
>>                     }
> 96,97c105,110
> <                 if(k==0) return f-R; else {dk=(double)k;
> <                     return dk*ln2_hi-((R-dk*ln2_lo)-f);}
> ---
>>                 if (k == 0) {
>>                     return f - R;
>>                 } else {
>>                     dk = (double)k;
>>                     return dk*ln2_hi - ((R - dk*ln2_lo) - f);
>>                 }
> 102c115
> <             i = hx-0x6147a;
> ---
>>             i = hx - 0x6_147a;
> 111c124,126
> <                 if(k==0) return f-(hfsq-s*(hfsq+R)); else
> ---
>>                 if (k == 0) {
>>                     return f-(hfsq-s*(hfsq+R));
>>                 } else {
> 112a128,131
>>                 }
>>             } else {
>>                 if (k == 0) {
>>                     return f - s*(f - R);
> 114d132
> <                 if(k==0) return f-s*(f-R); else
> 115a134
>>                 }
> 
> 
> The transliteration port passes the "exhausting" test of all float arguments when run against a JDK 20 build. The idiomatic port matches the transliteration port on the same test.

PS Forgot to include the new regression test file in the initial state of the PR. I'll augment the regression test to input arguments where Math.log(x) and StrictMath.log(x) return different results. However, I wanted to get the bulk of the port out for review.

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

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

From mchung at openjdk.org  Wed Feb  8 00:40:52 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Wed, 8 Feb 2023 00:40:52 GMT
Subject: RFR: 8294961: java.base java.lang.reflect.ProxyGenerator uses ASM
 to generate proxy classes [v2]
In-Reply-To: <pllZmQlszffAmAiq-P45e6FyZkNbRTp1VbIbUe29xo8=.449d0bfc-a712-484a-8aee-0140a054b2d6@github.com>
References: <rqqi61cKbJ8TjDVSzsjh6BVXjF1ZxL2ZFHheuXzL5E8=.bd1f1a2c-6f35-4180-a0a5-8a6e3cb93e75@github.com>
 <pllZmQlszffAmAiq-P45e6FyZkNbRTp1VbIbUe29xo8=.449d0bfc-a712-484a-8aee-0140a054b2d6@github.com>
Message-ID: <sSGmswappyrpfAAIJsyfQ_zjusccyLc3mzXWYjp596M=.08e13292-d0de-46f4-9fa5-e398f0838fb9@github.com>

On Fri, 3 Feb 2023 15:11:30 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> java.base java.lang.reflect.ProxyGenerator uses ASM to generate proxy classes and this patch converts it to use Classfile API.
>> 
>> This pull request suppose to chain on the 8294982: Implementation of Classfile API https://github.com/openjdk/jdk/pull/10982
>> 
>> 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 four additional commits since the last revision:
> 
>  - j.l.r.ProxyGenerator fix - Classfile API moved under jdk.internal.classfile package
>  - Merge branch 'JDK-8294982' into JDK-8294961
>  - Merge branch 'JDK-8294982' into JDK-8294961
>  - 8294961: java.base java.lang.reflect.ProxyGenerator uses ASM to generate proxy classes

This looks good in general.   I like this, easy to use, easy to read and understand and greatly simplified.

Reviewing this is one easy way to study the ClassFile API.

src/java.base/share/classes/java/lang/reflect/ProxyGenerator.java line 390:

> 388:             uniqueList.add(ex);
> 389:         }
> 390:         return uniqueList.stream().map(ex -> ClassDesc.ofDescriptor(ex.descriptorString())).toList();

It would be useful to add a helper method to convert Class to ClassDesc:

     private static ClassDesc toClassDesc(Class<?> type) {
         return ClassDesc.ofDescriptor(type.descriptorString());
     }
     
Suggestion:

        return uniqueList.stream().map(ProxyGenerator::toClassDesc).toList();

src/java.base/share/classes/java/lang/reflect/ProxyGenerator.java line 423:

> 421:     private byte[] generateClassFile() {
> 422:         var localCache = new HashMap<ClassDesc, ClassHierarchyResolver.ClassHierarchyInfo>();
> 423:         return Classfile.build(classDesc, List.of(Classfile.Option.classHierarchyResolver(classDesc ->

How/when is `ClassHierarchyResolver` being called?   I didn't dig deeper.

src/java.base/share/classes/java/lang/reflect/ProxyGenerator.java line 664:

> 662:          */
> 663:         private void generateMethod(ClassBuilder clb, ClassDesc className) {
> 664:             MethodTypeDesc desc = MethodTypeDesc.ofDescriptor(MethodType.methodType(returnType, parameterTypes).toMethodDescriptorString());

I slightly prefer to call `MethodType::descriptorString` that `descriptorString` is called for both `Class` and `MethodType`. 


MethodTypeDesc desc = MethodTypeDesc.ofDescriptor(MethodType.methodType(returnType, parameterTypes).descriptorString());


Alternatively, use `describeConstable` instead.


MethodTypeDesc desc = MethodType.methodType(returnType, parameterTypes).describeConstable().orElseThrow();

src/java.base/share/classes/java/lang/reflect/ProxyGenerator.java line 665:

> 663:         private void generateMethod(ClassBuilder clb, ClassDesc className) {
> 664:             MethodTypeDesc desc = MethodTypeDesc.ofDescriptor(MethodType.methodType(returnType, parameterTypes).toMethodDescriptorString());
> 665:             int accessFlags = (method.isVarArgs()) ? ACC_VARARGS | ACC_PUBLIC | ACC_FINAL : ACC_PUBLIC | ACC_FINAL;

Nit: 
Suggestion:

            int accessFlags = (method.isVarArgs()) ? ACC_VARARGS | ACC_PUBLIC | ACC_FINAL
                                                   : ACC_PUBLIC | ACC_FINAL;

src/java.base/share/classes/java/lang/reflect/ProxyGenerator.java line 672:

> 670:                         .stream()
> 671:                         .map(cpb::classEntry)
> 672:                         .toList();

Suggestion:

                List<ClassEntry> exceptionClassEntries = Arrays.asList(exceptionTypes)
                        .stream()
                        .map(ProxyGenerator::toClassDesc)
                        .map(cpb::classEntry)
                        .toList();


`typeNames` streams over the given types.   This can be simplified by mapping `Class` to `ClassDesc` in place here.   I would also suggest to add  the `toClassDesc` helper method.

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

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

From mchung at openjdk.org  Wed Feb  8 00:52:49 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Wed, 8 Feb 2023 00:52:49 GMT
Subject: RFR: 8294961: java.base java.lang.reflect.ProxyGenerator uses ASM
 to generate proxy classes [v2]
In-Reply-To: <pllZmQlszffAmAiq-P45e6FyZkNbRTp1VbIbUe29xo8=.449d0bfc-a712-484a-8aee-0140a054b2d6@github.com>
References: <rqqi61cKbJ8TjDVSzsjh6BVXjF1ZxL2ZFHheuXzL5E8=.bd1f1a2c-6f35-4180-a0a5-8a6e3cb93e75@github.com>
 <pllZmQlszffAmAiq-P45e6FyZkNbRTp1VbIbUe29xo8=.449d0bfc-a712-484a-8aee-0140a054b2d6@github.com>
Message-ID: <OCfHAgOQug6VIZNh-Ac91v30TwwjreXR0oIT9RVT7Pw=.5e50e045-1908-4a98-8abc-9f6a891dd391@github.com>

On Fri, 3 Feb 2023 15:11:30 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> java.base java.lang.reflect.ProxyGenerator uses ASM to generate proxy classes and this patch converts it to use Classfile API.
>> 
>> This pull request suppose to chain on the 8294982: Implementation of Classfile API https://github.com/openjdk/jdk/pull/10982
>> 
>> 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 four additional commits since the last revision:
> 
>  - j.l.r.ProxyGenerator fix - Classfile API moved under jdk.internal.classfile package
>  - Merge branch 'JDK-8294982' into JDK-8294961
>  - Merge branch 'JDK-8294982' into JDK-8294961
>  - 8294961: java.base java.lang.reflect.ProxyGenerator uses ASM to generate proxy classes

src/java.base/share/classes/java/lang/reflect/ProxyGenerator.java line 221:

> 219:      * null or empty
> 220:      */
> 221:     private static List<ClassDesc> typeNames(List<Class<?>> classes) {

I think this method is not strictly necessary. 

`clb.withInterfaceSymbols(typeNames(interfaces))` can simply be replaced with 


clb.withInterfaceSymbols(interfaces.stream().map(ProxyGenerator::toClassDesc).toList());


`interfaces` should be non-null.  We can add `Objects.requireNonNull(interfaces)` in static `generateProxyClass` method.

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

PR: https://git.openjdk.org/jdk/pull/10991

From duke at openjdk.org  Wed Feb  8 01:15:44 2023
From: duke at openjdk.org (David Schlosnagle)
Date: Wed, 8 Feb 2023 01:15:44 GMT
Subject: RFR: 8301958: Reduce Arrays.copyOf/-Range overheads [v7]
In-Reply-To: <n8n_xh_R8sORHd7q5kwEa0kRxoSgBvgaWe_qdliwFFw=.52872c7b-7cb6-4ea4-932f-5d4f57c515eb@github.com>
References: <2pdPoSHz2RJ7YDHOwOyszQMVv0v7FQFOwykfJ-za_e0=.cfe480da-a045-4b9a-bec7-7fffd0f47206@github.com>
 <n8n_xh_R8sORHd7q5kwEa0kRxoSgBvgaWe_qdliwFFw=.52872c7b-7cb6-4ea4-932f-5d4f57c515eb@github.com>
Message-ID: <cEcoqLzuQ2goUGLKLd1HPqaJbPgpLIid7tWgv3HSQds=.c0a87a8c-3656-4a8e-b970-fe8298cd3ca2@github.com>

On Wed, 8 Feb 2023 00:07:14 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> This patch adds special-cases to `Arrays.copyOf` and `Arrays.copyOfRange` to clone arrays when `newLength` or range inputs span the input array. This helps eliminate range checks and has been verified to help various String operations. Example:
>> 
>> Baseline
>> 
>> Benchmark                                            (size)  Mode  Cnt   Score   Error  Units
>> StringConstructor.newStringFromArray                      7  avgt   15  16.817 ? 0.369  ns/op
>> StringConstructor.newStringFromArrayWithCharset           7  avgt   15  16.866 ? 0.449  ns/op
>> StringConstructor.newStringFromArrayWithCharsetName       7  avgt   15  22.198 ? 0.396  ns/op
>> 
>> Patch: 
>> 
>> Benchmark                                            (size)  Mode  Cnt   Score   Error  Units
>> StringConstructor.newStringFromArray                      7  avgt   15  14.666 ? 0.336  ns/op
>> StringConstructor.newStringFromArrayWithCharset           7  avgt   15  14.582 ? 0.288  ns/op
>> StringConstructor.newStringFromArrayWithCharsetName       7  avgt   15  20.339 ? 0.328  ns/op
>
> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Minimize, force inline, generalize

src/java.base/share/classes/java/util/Arrays.java line 3594:

> 3592:     public static int[] copyOf(int[] original, int newLength) {
> 3593:         if (newLength == original.length) {
> 3594:             return original.clone();

I am curious about the use of `clone ` for some primitive array types and `copyOf` using `System.arraycopy` in other types (e.g. `byte[]`). Do these types optimize differently or hit different intrinsics depending on primitive type? Is there difference in array zeroing?

-------------

PR: https://git.openjdk.org/jdk/pull/12453

From jpai at openjdk.org  Wed Feb  8 01:55:48 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 8 Feb 2023 01:55:48 GMT
Subject: RFR: JDK-8301462: Convert Permission files to use lambda after
 JDK-8076596
In-Reply-To: <HVWMALUhjljFTe0W9OlvK7CfpFgg4z3Um8V6ChTHA18=.cf1fb1d5-3594-4e97-beb6-144b6a726bf0@github.com>
References: <HVWMALUhjljFTe0W9OlvK7CfpFgg4z3Um8V6ChTHA18=.cf1fb1d5-3594-4e97-beb6-144b6a726bf0@github.com>
Message-ID: <vdtstlMwXANkrCKAMuAn8UpnQVptdiD_JSnhg_y4_88=.ceda6eef-dc3b-4081-8e23-5f6bb704e5a3@github.com>

On Tue, 7 Feb 2023 22:25:43 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> A trivial fix.   Convert the use of anonymous inner classes in a few Permission classes to lambdas to work around JDK-8076596, which has been resolved.

Hello Mandy, the changes look fine to me.

Each of these files will need a copyright year update before integrating.

-------------

Marked as reviewed by jpai (Reviewer).

PR: https://git.openjdk.org/jdk/pull/12463

From duke at openjdk.org  Wed Feb  8 02:58:42 2023
From: duke at openjdk.org (SUN Guoyun)
Date: Wed, 8 Feb 2023 02:58:42 GMT
Subject: RFR: 8301737:
 java/rmi/server/UnicastRemoteObject/serialFilter/FilterUROTest.java fail with
 -Xcomp [v3]
In-Reply-To: <PtGxV9PeStEfGQjHpOaZR5LEhx2BGqzfDORIqE6U2Lk=.b1756e3f-1363-482f-a307-ee80390f7669@github.com>
References: <l5m5_9io2QMSFNY7dBHT3Nr2I9Er8wmd92Ze8FP-XE0=.a40d29be-77be-4719-a0a0-71d032eea1e5@github.com>
 <zMo8OEhYAKUz5LWOssEWEUQDoySJo7hsL7_KAzfNU34=.2309b7bb-5e1d-47e8-b932-aedfbce71e5b@github.com>
 <PtGxV9PeStEfGQjHpOaZR5LEhx2BGqzfDORIqE6U2Lk=.b1756e3f-1363-482f-a307-ee80390f7669@github.com>
Message-ID: <mKriPqZyXRFp2tsTma_JkBbX_HTyKvejKUu1vZ8Vaqg=.133efef9-0ecc-4c7b-b892-7bb8cb3f7bfc@github.com>

On Tue, 7 Feb 2023 20:47:28 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> I'm going to backup a bit; so another question... This test is a fairly simple test that should not be taxing on GC or any other resource so I'm surprised the the default configuration is not sufficient. It might be worth looking a bit deeper into the GC vs Xcomp conditions and the interplay with "looongaarch64". I can't help much there, not being familiar with details of GC or the compiler.

Using `-Xcomp` necessarily results in more methods being compiled. And in hotspot, the codecache does not trigger the GC after it is full, but triggers the GC when it reaches a certain threshold with `SweeperThreshold`. 

<pre><code class="cpp">
// ./src/hotspot/share/code/codeCache.cpp
 818   if (allocated_since_last_ratio > threshold) {        // threshold  = SweeperThreshold / 100.0;                  
 819     // In case the GC is concurrent, we make sure only one thread requests the GC.
 820     if (Atomic::cmpxchg(&_unloading_threshold_gc_requested, false, true) == false) {
 821       log_info(codecache)("Triggering threshold (%.3f%%) GC due to allocating %.3f%% since last unloading (%.3f%% used -> %.3f%% used)",
 822                           threshold * 100.0, allocated_since_last_ratio * 100.0, last_used_ratio * 100.0, used_ratio * 100.0);
 823       Universe::heap()->collect(GCCause::_codecache_GC_threshold);              
 824     }                                                                           
 825   }   
</code></pre>

So, when I adjust `-XX:SweeperThreshold=30`, the test passes also.

-------------

PR: https://git.openjdk.org/jdk/pull/12399

From mchung at openjdk.org  Wed Feb  8 03:42:16 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Wed, 8 Feb 2023 03:42:16 GMT
Subject: RFR: JDK-8301462: Convert Permission files to use lambda after
 JDK-8076596 [v2]
In-Reply-To: <HVWMALUhjljFTe0W9OlvK7CfpFgg4z3Um8V6ChTHA18=.cf1fb1d5-3594-4e97-beb6-144b6a726bf0@github.com>
References: <HVWMALUhjljFTe0W9OlvK7CfpFgg4z3Um8V6ChTHA18=.cf1fb1d5-3594-4e97-beb6-144b6a726bf0@github.com>
Message-ID: <pJX2oOarrhU6mm0oJY5pH7avyZlRmVnGQSulKKFA1dM=.fe116030-80ed-4b7f-9ed4-33dd04f2d4ab@github.com>

> A trivial fix.   Convert the use of anonymous inner classes in a few Permission classes to lambdas to work around JDK-8076596, which has been resolved.

Mandy Chung has updated the pull request incrementally with one additional commit since the last revision:

  update copyright end year

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12463/files
  - new: https://git.openjdk.org/jdk/pull/12463/files/abeecaf1..627da759

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12463&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12463&range=00-01

  Stats: 4 lines in 4 files changed: 0 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/12463.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12463/head:pull/12463

PR: https://git.openjdk.org/jdk/pull/12463

From mchung at openjdk.org  Wed Feb  8 03:42:16 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Wed, 8 Feb 2023 03:42:16 GMT
Subject: RFR: JDK-8301462: Convert Permission files to use lambda after
 JDK-8076596 [v2]
In-Reply-To: <vdtstlMwXANkrCKAMuAn8UpnQVptdiD_JSnhg_y4_88=.ceda6eef-dc3b-4081-8e23-5f6bb704e5a3@github.com>
References: <HVWMALUhjljFTe0W9OlvK7CfpFgg4z3Um8V6ChTHA18=.cf1fb1d5-3594-4e97-beb6-144b6a726bf0@github.com>
 <vdtstlMwXANkrCKAMuAn8UpnQVptdiD_JSnhg_y4_88=.ceda6eef-dc3b-4081-8e23-5f6bb704e5a3@github.com>
Message-ID: <H4m2RQUlmogrkbwTgirveFq8DP8vnjmzpGGpmg33CNU=.bf747d3d-be49-45ef-aa94-ec92e79e2764@github.com>

On Wed, 8 Feb 2023 01:53:02 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Mandy Chung has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   update copyright end year
>
> Hello Mandy, the changes look fine to me.
> 
> Each of these files will need a copyright year update before integrating.

Thanks for the review @jaikiran

-------------

PR: https://git.openjdk.org/jdk/pull/12463

From duke at openjdk.org  Wed Feb  8 03:54:50 2023
From: duke at openjdk.org (David Schlosnagle)
Date: Wed, 8 Feb 2023 03:54:50 GMT
Subject: RFR: 8301958: Reduce Arrays.copyOf/-Range overheads [v7]
In-Reply-To: <n8n_xh_R8sORHd7q5kwEa0kRxoSgBvgaWe_qdliwFFw=.52872c7b-7cb6-4ea4-932f-5d4f57c515eb@github.com>
References: <2pdPoSHz2RJ7YDHOwOyszQMVv0v7FQFOwykfJ-za_e0=.cfe480da-a045-4b9a-bec7-7fffd0f47206@github.com>
 <n8n_xh_R8sORHd7q5kwEa0kRxoSgBvgaWe_qdliwFFw=.52872c7b-7cb6-4ea4-932f-5d4f57c515eb@github.com>
Message-ID: <TW-KNWkgAmEkbfbv8sKTukJ_3RsrqHcMaBNiyv7E6wY=.99f45046-eba2-481b-9a6e-e3302535d94a@github.com>

On Wed, 8 Feb 2023 00:07:14 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> This patch adds special-cases to `Arrays.copyOf` and `Arrays.copyOfRange` to clone arrays when `newLength` or range inputs span the input array. This helps eliminate range checks and has been verified to help various String operations. Example:
>> 
>> Baseline
>> 
>> Benchmark                                            (size)  Mode  Cnt   Score   Error  Units
>> StringConstructor.newStringFromArray                      7  avgt   15  16.817 ? 0.369  ns/op
>> StringConstructor.newStringFromArrayWithCharset           7  avgt   15  16.866 ? 0.449  ns/op
>> StringConstructor.newStringFromArrayWithCharsetName       7  avgt   15  22.198 ? 0.396  ns/op
>> 
>> Patch: 
>> 
>> Benchmark                                            (size)  Mode  Cnt   Score   Error  Units
>> StringConstructor.newStringFromArray                      7  avgt   15  14.666 ? 0.336  ns/op
>> StringConstructor.newStringFromArrayWithCharset           7  avgt   15  14.582 ? 0.288  ns/op
>> StringConstructor.newStringFromArrayWithCharsetName       7  avgt   15  20.339 ? 0.328  ns/op
>
> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Minimize, force inline, generalize

I'm also curious if returning the new length from `checkLength` would be worthwhile

src/java.base/share/classes/java/util/Arrays.java line 3823:

> 3821:         if (to - from < 0) {
> 3822:             throw new IllegalArgumentException(from + " > " + to);
> 3823:         }

Would it be beneficial to return the difference of `to` and `from` for caller use?

Suggestion:

    private static int checkLength(int from, int to) {
        int newLength = to - from;
        if (newLength < 0) {
            throw new IllegalArgumentException(from + " > " + to);
        }
        return newLength;

src/java.base/share/classes/java/util/Arrays.java line 3870:

> 3868:     private static byte[] copyOfRangeGeneric(byte[] original, int from, int to) {
> 3869:         checkLength(from, to);
> 3870:         int newLength = to - from;

```suggestion        
        int newLength = checkLength(from, to);

src/java.base/share/classes/java/util/Arrays.java line 3914:

> 3912:     private static short[] copyOfRangeGeneric(short[] original, int from, int to) {
> 3913:         checkLength(from, to);
> 3914:         int newLength = to - from;

Suggestion:

        int newLength = checkLength(from, to);

src/java.base/share/classes/java/util/Arrays.java line 3958:

> 3956:     private static int[] copyOfRangeGeneric(int[] original, int from, int to) {
> 3957:         checkLength(from, to);
> 3958:         int newLength = to - from;

Suggestion:

        int newLength = checkLength(from, to);

src/java.base/share/classes/java/util/Arrays.java line 4002:

> 4000:     private static long[] copyOfRangeGeneric(long[] original, int from, int to) {
> 4001:         checkLength(from, to);
> 4002:         int newLength = to - from;

Suggestion:

        int newLength = checkLength(from, to);

src/java.base/share/classes/java/util/Arrays.java line 4046:

> 4044:     private static char[] copyOfRangeGeneric(char[] original, int from, int to) {
> 4045:         checkLength(from, to);
> 4046:         int newLength = to - from;

Suggestion:

        int newLength = checkLength(from, to);

src/java.base/share/classes/java/util/Arrays.java line 4091:

> 4089:     private static float[] copyOfRangeGeneric(float[] original, int from, int to) {
> 4090:         checkLength(from, to);
> 4091:         int newLength = to - from;

Suggestion:

        int newLength = checkLength(from, to);

src/java.base/share/classes/java/util/Arrays.java line 4142:

> 4140:     private static double[] copyOfRangeGeneric(double[] original, int from, int to) {
> 4141:         checkLength(from, to);
> 4142:         int newLength = to - from;

Suggestion:

        int newLength = checkLength(from, to);

src/java.base/share/classes/java/util/Arrays.java line 4193:

> 4191:     private static boolean[] copyOfRangeGeneric(boolean[] original, int from, int to) {
> 4192:         checkLength(from, to);
> 4193:         int newLength = to - from;

Suggestion:

        int newLength = checkLength(from, to);

-------------

PR: https://git.openjdk.org/jdk/pull/12453

From duke at openjdk.org  Wed Feb  8 04:47:43 2023
From: duke at openjdk.org (Tingjun Yuan)
Date: Wed, 8 Feb 2023 04:47:43 GMT
Subject: RFR: 8296935: Arrays.asList().set() with wrong types throws
 undocumented ArrayStoreException [v7]
In-Reply-To: <ZZurFel-Py9rfobJ9aOTKXiN91B7h72kQMFoZWTPvU0=.930c0c30-a314-4992-805b-95237333defd@github.com>
References: <9JFNgXqBSj9uR8vR9oIooJMxtf74y12L0-GbjOO7fJg=.769953c2-40f3-49c0-8598-ce940d2d95d4@github.com>
 <ZZurFel-Py9rfobJ9aOTKXiN91B7h72kQMFoZWTPvU0=.930c0c30-a314-4992-805b-95237333defd@github.com>
Message-ID: <KP-N_ALpuA6vs8IZY_tzjvcmVa8GoTxkw3fzMIMzwxY=.b275506b-d2e5-4b52-a8f9-96474d61b200@github.com>

On Mon, 23 Jan 2023 07:33:21 GMT, Tingjun Yuan <duke at openjdk.org> wrote:

>> Document `java.util.Arrays.asList` that the list will throw an `ArrayStoreException` when attempting to set an element with a wrong type.
>
> Tingjun Yuan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update `implSpec` and remove the docs of the impl.

If I just add a `@implNote` section into this documentation and do not modify the current behavior, does this PR require a CSR then?

-------------

PR: https://git.openjdk.org/jdk/pull/12135

From jpai at openjdk.org  Wed Feb  8 05:27:42 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 8 Feb 2023 05:27:42 GMT
Subject: RFR: JDK-8301462: Convert Permission files to use lambda after
 JDK-8076596 [v2]
In-Reply-To: <pJX2oOarrhU6mm0oJY5pH7avyZlRmVnGQSulKKFA1dM=.fe116030-80ed-4b7f-9ed4-33dd04f2d4ab@github.com>
References: <HVWMALUhjljFTe0W9OlvK7CfpFgg4z3Um8V6ChTHA18=.cf1fb1d5-3594-4e97-beb6-144b6a726bf0@github.com>
 <pJX2oOarrhU6mm0oJY5pH7avyZlRmVnGQSulKKFA1dM=.fe116030-80ed-4b7f-9ed4-33dd04f2d4ab@github.com>
Message-ID: <VGPMX9KZjPSWR31jdYdTScjtg4KFOjTa_OMgMsFKKTQ=.1d9a5d8f-4215-49ea-897f-1f1ce242d41a@github.com>

On Wed, 8 Feb 2023 03:42:16 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> A trivial fix.   Convert the use of anonymous inner classes in a few Permission classes to lambdas to work around JDK-8076596, which has been resolved.
>
> Mandy Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update copyright end year

Marked as reviewed by jpai (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/12463

From duke at openjdk.org  Wed Feb  8 05:28:30 2023
From: duke at openjdk.org (Varada M)
Date: Wed, 8 Feb 2023 05:28:30 GMT
Subject: RFR: 8300139 : [AIX] Use pthreads to avoid JNI_createVM call from
 primordial thread
Message-ID: <qbwPBNdxzk4QmB9L6y2t-X6uYgAaPjzAEwYfs_5XV_0=.4ea982e6-30da-4219-b8ad-fa36690170b8@github.com>

1. test/jdk/jni/nullCaller/NullCallerTest.java
2. test/jdk/java/lang/reflect/exeCallerAccessTest/CallerAccessTest.java
3. test/hotspot/jtreg/runtime/jni/CalleeSavedRegisters/FPRegs.java 

    The above tests were blocked on AIX [@require os.family != "aix"] because these tests are failing to call JNI_CreateJavaVM. This is solved by implementing JNI_CreateJavaVM call via POSIX threads. 
   Similarly there are tests which are not blocked and still failing to call JNI_CreateJavaVM on AIX :

4. test/hotspot/jtreg/runtime/jni/daemonDestroy/TestDaemonDestroy.java { PR : [12006](https://github.com/openjdk/jdk/pull/12006) }
5. test/lib-test/jdk/test/lib/process/TestNativeProcessBuilder.java 

The reported issue : [8300139](https://bugs.openjdk.org/browse/JDK-8300139l)

-------------

Commit messages:
 - 8300139 : [AIX] Use pthreads to avoid JNI_createVM call from primordial thread
 - 8300139 : [AIX] Use pthreads to avoid JNI_createVM call from primordial thread
 - 8300139 : [AIX] Use pthreads to avoid JNI_createVM call from primordial thread
 - Indentation Fixes
 - 8300139:[AIX] Use pthreads to avoid JNI_createVM call from primordial thread

Changes: https://git.openjdk.org/jdk/pull/12302/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12302&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8300139
  Stats: 122 lines in 7 files changed: 88 ins; 8 del; 26 mod
  Patch: https://git.openjdk.org/jdk/pull/12302.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12302/head:pull/12302

PR: https://git.openjdk.org/jdk/pull/12302

From jpai at openjdk.org  Wed Feb  8 06:01:42 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 8 Feb 2023 06:01:42 GMT
Subject: RFR: 8299748: java/util/zip/Deinflate.java failing on s390x [v2]
In-Reply-To: <3z7u66KVgFfL7S7S4uxDtOA6gD-WkNU7R-zon0trIVg=.d27446ca-c11d-49cc-bb85-b162e5ac58f2@github.com>
References: <Usxi4wE5GSHHv-cKPfW6OXylhieAypbsidUX_Jo6FSQ=.34104cf0-2243-478f-86ce-9a91905c6755@github.com>
 <3z7u66KVgFfL7S7S4uxDtOA6gD-WkNU7R-zon0trIVg=.d27446ca-c11d-49cc-bb85-b162e5ac58f2@github.com>
Message-ID: <9EjafTFI65ABleS2lvrZTrTYsumKrSk7Mgc5ORj1Xx8=.c319c84f-eb6e-422f-9b01-96f4841f753e@github.com>

On Thu, 2 Feb 2023 08:27:55 GMT, Amit Kumar <duke at openjdk.org> wrote:

>> DeInflate.java test fails on s390x platform because size for out1 array which is responsible for storing the compressed data is insufficient. And being unable to write whole compressed data on array, on s390 whole data can't be recovered after compression. So this fix increase Array size (for s390).
>
> Amit Kumar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   change acc to Alan comments

Hello Amit, just to get a bit more details about this zlib library, would it be possible to get the zlib version and the zlib compiler flags used to build it? The crudest (but simplest) way of doing this is applying the following patch to the JDK and rebuilding the JDK and running that specific test again:


diff --git a/src/java.base/share/native/libzip/Deflater.c b/src/java.base/share/native/libzip/Deflater.c
index 1ed1994d471..951cd7a6664 100644
--- a/src/java.base/share/native/libzip/Deflater.c
+++ b/src/java.base/share/native/libzip/Deflater.c
@@ -38,10 +38,17 @@
 
 #define DEF_MEM_LEVEL 8
 
+static jint logged = 0;
+
 JNIEXPORT jlong JNICALL
 Java_java_util_zip_Deflater_init(JNIEnv *env, jclass cls, jint level,
                                  jint strategy, jboolean nowrap)
 {
+    if (logged == 0) {
+        logged = 1;
+        fprintf(stderr, "zlib version is %s\n", zlibVersion());
+        fprintf(stderr, "zlib compiler flags are %lu\n", zlibCompileFlags());
+    }
     z_stream *strm = calloc(1, sizeof(z_stream));
 
     if (strm == 0) {




The .jtr file will then have these log messages in the System.err section. For me it is:


----------System.err:(3/66)----------
zlib version is 1.2.13
zlib compiler flags are 169

It would be interesting to see what it prints on that specific system where it is behaving differently.

-------------

PR: https://git.openjdk.org/jdk/pull/12283

From duke at openjdk.org  Wed Feb  8 06:36:44 2023
From: duke at openjdk.org (Amit Kumar)
Date: Wed, 8 Feb 2023 06:36:44 GMT
Subject: RFR: 8299748: java/util/zip/Deinflate.java failing on s390x [v2]
In-Reply-To: <3z7u66KVgFfL7S7S4uxDtOA6gD-WkNU7R-zon0trIVg=.d27446ca-c11d-49cc-bb85-b162e5ac58f2@github.com>
References: <Usxi4wE5GSHHv-cKPfW6OXylhieAypbsidUX_Jo6FSQ=.34104cf0-2243-478f-86ce-9a91905c6755@github.com>
 <3z7u66KVgFfL7S7S4uxDtOA6gD-WkNU7R-zon0trIVg=.d27446ca-c11d-49cc-bb85-b162e5ac58f2@github.com>
Message-ID: <UDnm_8mIu8nNqNtX2MhcmVn2CFXbEqsmfD7fUHsYjOc=.f2a6b57e-c44e-4283-b72e-70f1c71f3b0d@github.com>

On Thu, 2 Feb 2023 08:27:55 GMT, Amit Kumar <duke at openjdk.org> wrote:

>> DeInflate.java test fails on s390x platform because size for out1 array which is responsible for storing the compressed data is insufficient. And being unable to write whole compressed data on array, on s390 whole data can't be recovered after compression. So this fix increase Array size (for s390).
>
> Amit Kumar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   change acc to Alan comments

While building itself, i got this output:

Creating jdk.jlink.jmod
zlib version is 1.2.13
zlib compiler flags are 169
Creating java.base.jmod
zlib version is 1.2.13
zlib compiler flags are 169
Creating jdk image
Creating CDS archive for jdk image for server
Creating CDS-NOCOOPS archive for jdk image for server
Stopping javac server
Finished building target 'images' in configuration 'linux-s390x-server-fastdebug'


There is some tweak in `zlib` being used on s390. You may see it here: https://github.com/iii-i/zlib/commit/113203437eda67261848b14b6c80a33ff7e33d34

-------------

PR: https://git.openjdk.org/jdk/pull/12283

From asotona at openjdk.org  Wed Feb  8 07:23:49 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Wed, 8 Feb 2023 07:23:49 GMT
Subject: RFR: 8294982: Implementation of Classfile API [v12]
In-Reply-To: <84RlLSIsacJTJVM-esvzoXnQ5rDEByog5b1ibFRJOE8=.05e8e7a7-2185-4e1c-b5b9-59ce3b3eea03@github.com>
References: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
 <Q4VeZ2yWAg85FqUDJa5hYq3jHty5H547gD0H-x3oIq0=.58d463a4-237a-4fee-bd0f-83262d49522a@github.com>
 <c022hrWNEHW76nhP_sXTQXCTjtL8jjM8r_yYv0IvbPI=.2a9cfbae-2fef-4cdb-8189-b869b1513fef@github.com>
 <FbFekphAbS5DQzn6B-uUHkX-2EF8Aq4NcijjMdlxAM0=.280a7529-4008-4539-9137-da7600e13eee@github.com>
 <kxds1bmvZ8TbtVK5iDx_hZtrqN3uywsa6GqumJ7RubE=.ffd151e4-a1ba-4018-914c-518fd122dd4f@github.com>
 <WxjOq5CRJ9OtviOIxDKH9C78bScpiGmkiBqVXLDddzU=.a5a85537-43e8-4cf4-b747-86b945999d71@github.com>
 <84RlLSIsacJTJVM-esvzoXnQ5rDEByog5b1ibFRJOE8=.05e8e7a7-2185-4e1c-b5b9-59ce3b3eea03@github.com>
Message-ID: <sQwAa41mu1z226uzYIA2_v0tN8un257MDgc-WPO8SFY=.486c845c-5012-4291-bcd7-c7b0247e02dd@github.com>

On Tue, 7 Feb 2023 15:47:25 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Class `Signature` (aka `JavaTypeSignature`), all subclasses, `MethodSignature` and `ClassSignature` are designed according to [JVMS 4.7.9.1 Signatures](https://docs.oracle.com/javase/specs/jvms/se19/html/jvms-4.html#jvms-4.7.9.1)
>
>> Class `Signature` (aka `JavaTypeSignature`), all subclasses, `MethodSignature` and `ClassSignature` are designed according to [JVMS 4.7.9.1 Signatures](https://docs.oracle.com/javase/specs/jvms/se19/html/jvms-4.html#jvms-4.7.9.1)
> 
> The production is the same as the one I quoted, but thanks for pointing me at the correct one. So:
> 
> 
> JavaTypeSignature:
>    ReferenceTypeSignature
>    BaseType 
> 
> 
> and
> 
> 
> ReferenceTypeSignature:
>    ClassTypeSignature
>    TypeVariableSignature
>    ArrayTypeSignature
> 
> 
> So, while I can expect that `ArrayTypeSignature` *is a* `Signature` (or `JavaTypeSignature`), I cannot explain why `ThrowsSignature` extends `Signature`. That doesn't seem to follow from the production. That is, if a client obtains a `Signature` and wanted to pattern match, what are the cases it should worry about? I believe the cases are the ones listed above.
> 
> One thing I missed is that e.g. `TypeParam` is *not* a signature (which is the only case among the nested classes in `Signature`). But `ThrowsSignature`, `TypeArg` and `TypeParam` are signatures even though that doesn't seem to be the case when looking at the production in the JVMS. If we want to keep these fine, but I don't think they should extend `Signature`, either directly or indirectly. That is, `Signature` should be a sealed type with 4 leaves (base-type/array/type var/class-type).

**Specification:**

MethodSignature:
[TypeParameters] ( {JavaTypeSignature} ) Result {ThrowsSignature}

Result:
JavaTypeSignature 
VoidDescriptor

ThrowsSignature:
^ ClassTypeSignature 
^ TypeVariableSignature



**Reflect in API mapping:**

    public sealed interface ClassTypeSig
            extends RefTypeSig, ThrowableSig

and

    public sealed interface TypeVarSig
            extends RefTypeSig, ThrowableSig

and

    /**
     * @return method signature
     * @param typeParameters signatures for the type parameters
     * @param exceptions sigantures for the exceptions
     * @param result signature for the return type
     * @param arguments signatures for the method arguments
     */
    public static MethodSignature of(List<Signature.TypeParam> typeParameters,
                                     List<Signature.ThrowableSig> exceptions,
                                     Signature result,
                                     Signature... arguments) {


`Signature.ThrowableSig` is a `Signature` and it is a common super of `ClassTypeSig` and `ClassTypeSig`.

-------------

PR: https://git.openjdk.org/jdk/pull/10982

From asotona at openjdk.org  Wed Feb  8 07:26:47 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Wed, 8 Feb 2023 07:26:47 GMT
Subject: RFR: 8294982: Implementation of Classfile API [v12]
In-Reply-To: <sQwAa41mu1z226uzYIA2_v0tN8un257MDgc-WPO8SFY=.486c845c-5012-4291-bcd7-c7b0247e02dd@github.com>
References: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
 <Q4VeZ2yWAg85FqUDJa5hYq3jHty5H547gD0H-x3oIq0=.58d463a4-237a-4fee-bd0f-83262d49522a@github.com>
 <c022hrWNEHW76nhP_sXTQXCTjtL8jjM8r_yYv0IvbPI=.2a9cfbae-2fef-4cdb-8189-b869b1513fef@github.com>
 <FbFekphAbS5DQzn6B-uUHkX-2EF8Aq4NcijjMdlxAM0=.280a7529-4008-4539-9137-da7600e13eee@github.com>
 <kxds1bmvZ8TbtVK5iDx_hZtrqN3uywsa6GqumJ7RubE=.ffd151e4-a1ba-4018-914c-518fd122dd4f@github.com>
 <WxjOq5CRJ9OtviOIxDKH9C78bScpiGmkiBqVXLDddzU=.a5a85537-43e8-4cf4-b747-86b945999d71@github.com>
 <84RlLSIsacJTJVM-esvzoXnQ5rDEByog5b1ibFRJOE8=.05e8e7a7-2185-4e1c-b5b9-59ce3b3eea03@github.com>
 <sQwAa41mu1z226uzYIA2_v0tN8un257MDgc-WPO8SFY=.486c845c-5012-4291-bcd7-c7b0247e02dd@github.com>
Message-ID: <wxsAcKZwigc4sIUexg5m-6UlOg8ZHflccTs47FJCgdQ=.1ae6dcde-eed4-406a-8ab4-84a1d1f6332b@github.com>

On Wed, 8 Feb 2023 07:21:07 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>>> Class `Signature` (aka `JavaTypeSignature`), all subclasses, `MethodSignature` and `ClassSignature` are designed according to [JVMS 4.7.9.1 Signatures](https://docs.oracle.com/javase/specs/jvms/se19/html/jvms-4.html#jvms-4.7.9.1)
>> 
>> The production is the same as the one I quoted, but thanks for pointing me at the correct one. So:
>> 
>> 
>> JavaTypeSignature:
>>    ReferenceTypeSignature
>>    BaseType 
>> 
>> 
>> and
>> 
>> 
>> ReferenceTypeSignature:
>>    ClassTypeSignature
>>    TypeVariableSignature
>>    ArrayTypeSignature
>> 
>> 
>> So, while I can expect that `ArrayTypeSignature` *is a* `Signature` (or `JavaTypeSignature`), I cannot explain why `ThrowsSignature` extends `Signature`. That doesn't seem to follow from the production. That is, if a client obtains a `Signature` and wanted to pattern match, what are the cases it should worry about? I believe the cases are the ones listed above.
>> 
>> One thing I missed is that e.g. `TypeParam` is *not* a signature (which is the only case among the nested classes in `Signature`). But `ThrowsSignature`, `TypeArg` and `TypeParam` are signatures even though that doesn't seem to be the case when looking at the production in the JVMS. If we want to keep these fine, but I don't think they should extend `Signature`, either directly or indirectly. That is, `Signature` should be a sealed type with 4 leaves (base-type/array/type var/class-type).
>
> **Specification:**
> 
> MethodSignature:
> [TypeParameters] ( {JavaTypeSignature} ) Result {ThrowsSignature}
> 
> Result:
> JavaTypeSignature 
> VoidDescriptor
> 
> ThrowsSignature:
> ^ ClassTypeSignature 
> ^ TypeVariableSignature
> 
> 
> 
> **Reflect in API mapping:**
> 
>     public sealed interface ClassTypeSig
>             extends RefTypeSig, ThrowableSig
> 
> and
> 
>     public sealed interface TypeVarSig
>             extends RefTypeSig, ThrowableSig
> 
> and
> 
>     /**
>      * @return method signature
>      * @param typeParameters signatures for the type parameters
>      * @param exceptions sigantures for the exceptions
>      * @param result signature for the return type
>      * @param arguments signatures for the method arguments
>      */
>     public static MethodSignature of(List<Signature.TypeParam> typeParameters,
>                                      List<Signature.ThrowableSig> exceptions,
>                                      Signature result,
>                                      Signature... arguments) {
> 
> 
> `Signature.ThrowableSig` is a `Signature` and it is a common super of `ClassTypeSig` and `ClassTypeSig`.

`TypeParam` is not a signature, because it simply is not a signature.
Per spec:

TypeParameter:
Identifier ClassBound {InterfaceBound}

-------------

PR: https://git.openjdk.org/jdk/pull/10982

From asotona at openjdk.org  Wed Feb  8 07:27:48 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Wed, 8 Feb 2023 07:27:48 GMT
Subject: RFR: 8294982: Implementation of Classfile API [v12]
In-Reply-To: <sQwAa41mu1z226uzYIA2_v0tN8un257MDgc-WPO8SFY=.486c845c-5012-4291-bcd7-c7b0247e02dd@github.com>
References: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
 <Q4VeZ2yWAg85FqUDJa5hYq3jHty5H547gD0H-x3oIq0=.58d463a4-237a-4fee-bd0f-83262d49522a@github.com>
 <c022hrWNEHW76nhP_sXTQXCTjtL8jjM8r_yYv0IvbPI=.2a9cfbae-2fef-4cdb-8189-b869b1513fef@github.com>
 <FbFekphAbS5DQzn6B-uUHkX-2EF8Aq4NcijjMdlxAM0=.280a7529-4008-4539-9137-da7600e13eee@github.com>
 <kxds1bmvZ8TbtVK5iDx_hZtrqN3uywsa6GqumJ7RubE=.ffd151e4-a1ba-4018-914c-518fd122dd4f@github.com>
 <WxjOq5CRJ9OtviOIxDKH9C78bScpiGmkiBqVXLDddzU=.a5a85537-43e8-4cf4-b747-86b945999d71@github.com>
 <84RlLSIsacJTJVM-esvzoXnQ5rDEByog5b1ibFRJOE8=.05e8e7a7-2185-4e1c-b5b9-59ce3b3eea03@github.com>
 <sQwAa41mu1z226uzYIA2_v0tN8un257MDgc-WPO8SFY=.486c845c-5012-4291-bcd7-c7b0247e02dd@github.com>
Message-ID: <wxsAcKZwigc4sIUexg5m-6UlOg8ZHflccTs47FJCgdQ=.5613b95e-96b0-4ced-a587-ccca3f80595d@github.com>

On Wed, 8 Feb 2023 07:21:07 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>>> Class `Signature` (aka `JavaTypeSignature`), all subclasses, `MethodSignature` and `ClassSignature` are designed according to [JVMS 4.7.9.1 Signatures](https://docs.oracle.com/javase/specs/jvms/se19/html/jvms-4.html#jvms-4.7.9.1)
>> 
>> The production is the same as the one I quoted, but thanks for pointing me at the correct one. So:
>> 
>> 
>> JavaTypeSignature:
>>    ReferenceTypeSignature
>>    BaseType 
>> 
>> 
>> and
>> 
>> 
>> ReferenceTypeSignature:
>>    ClassTypeSignature
>>    TypeVariableSignature
>>    ArrayTypeSignature
>> 
>> 
>> So, while I can expect that `ArrayTypeSignature` *is a* `Signature` (or `JavaTypeSignature`), I cannot explain why `ThrowsSignature` extends `Signature`. That doesn't seem to follow from the production. That is, if a client obtains a `Signature` and wanted to pattern match, what are the cases it should worry about? I believe the cases are the ones listed above.
>> 
>> One thing I missed is that e.g. `TypeParam` is *not* a signature (which is the only case among the nested classes in `Signature`). But `ThrowsSignature`, `TypeArg` and `TypeParam` are signatures even though that doesn't seem to be the case when looking at the production in the JVMS. If we want to keep these fine, but I don't think they should extend `Signature`, either directly or indirectly. That is, `Signature` should be a sealed type with 4 leaves (base-type/array/type var/class-type).
>
> **Specification:**
> 
> MethodSignature:
> [TypeParameters] ( {JavaTypeSignature} ) Result {ThrowsSignature}
> 
> Result:
> JavaTypeSignature 
> VoidDescriptor
> 
> ThrowsSignature:
> ^ ClassTypeSignature 
> ^ TypeVariableSignature
> 
> 
> 
> **Reflect in API mapping:**
> 
>     public sealed interface ClassTypeSig
>             extends RefTypeSig, ThrowableSig
> 
> and
> 
>     public sealed interface TypeVarSig
>             extends RefTypeSig, ThrowableSig
> 
> and
> 
>     /**
>      * @return method signature
>      * @param typeParameters signatures for the type parameters
>      * @param exceptions sigantures for the exceptions
>      * @param result signature for the return type
>      * @param arguments signatures for the method arguments
>      */
>     public static MethodSignature of(List<Signature.TypeParam> typeParameters,
>                                      List<Signature.ThrowableSig> exceptions,
>                                      Signature result,
>                                      Signature... arguments) {
> 
> 
> `Signature.ThrowableSig` is a `Signature` and it is a common super of `ClassTypeSig` and `TypeVarSig`.

`TypeParam` is not a signature, because it simply is not a signature.
Per spec:

TypeParameter:
Identifier ClassBound {InterfaceBound}

-------------

PR: https://git.openjdk.org/jdk/pull/10982

From asotona at openjdk.org  Wed Feb  8 07:33:53 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Wed, 8 Feb 2023 07:33:53 GMT
Subject: RFR: 8294982: Implementation of Classfile API [v13]
In-Reply-To: <u6VmkXvghsyyf7qwyHyDpcqZ-wVCfFnZgOoB_wiz2-A=.ce2c44e1-81b0-4851-811c-5f4fd3fdda62@github.com>
References: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
 <Ej4u9wRtUuLS5LJhMkXwmown_MGuwR0gH9ruJ1A1g30=.f6405576-6655-4252-9135-ebc77765436e@github.com>
 <u6VmkXvghsyyf7qwyHyDpcqZ-wVCfFnZgOoB_wiz2-A=.ce2c44e1-81b0-4851-811c-5f4fd3fdda62@github.com>
Message-ID: <XmkS1CfKIATrXGdgIqZNmfY4LI3R3wBuTj903AkwkR0=.3787d0f1-f617-426d-95ae-ac736abc43ed@github.com>

On Tue, 7 Feb 2023 15:20:15 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Adam Sotona has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - javadoc fixes
>>  - obsolete identifiers and unused imports cleanup
>>  - TypeAnnotation.TypePathComponent cleanup
>
> src/java.base/share/classes/jdk/internal/classfile/attribute/CharacterRangeInfo.java line 146:
> 
>> 144:      * @param flags the range flags
>> 145:      */
>> 146:     static CharacterRangeInfo of(int startPc,
> 
> I get that the encoding is as per JaCoCo specification. However, I also wonder if the API should provide better accessors and or factories to let clients just reason about line/columns numbers. Or, maybe, provide static helpers to do the encoding/decoding.

Any reference to an official specification of CharacterRangeInfo is appreciated.
Thanks.

-------------

PR: https://git.openjdk.org/jdk/pull/10982

From djelinski at openjdk.org  Wed Feb  8 08:04:55 2023
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Wed, 8 Feb 2023 08:04:55 GMT
Subject: Integrated: 8301214: Adjust handshakeTimeout value in test
 HandshakeTimeout.java after 8189338
In-Reply-To: <lNI2dGqbIvao8fiOOkCZQeOflJ2pNq1099RZZvo_bnc=.ba51e479-f21a-4594-b2b0-4ab5dd24d896@github.com>
References: <lNI2dGqbIvao8fiOOkCZQeOflJ2pNq1099RZZvo_bnc=.ba51e479-f21a-4594-b2b0-4ab5dd24d896@github.com>
Message-ID: <iuVSIp02H6v7e4iDG7FWLsh-dHOZ62FuWJVwIyz2QcQ=.a217bedf-30bc-4a09-b3d8-301de0cc3e84@github.com>

On Mon, 30 Jan 2023 11:06:05 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> Please review this patch that reduces the socket timeout used in HandshakeTimeout test to its minimum value of 1 millisecond.
> 
> This change makes the test complete 10 seconds faster; before this change it took 5 seconds for the handshake to timeout, and the test attempts 2 handshakes.
> 
> The change also makes the test more likely to pass when it has to compete with other tests for CPU time.

This pull request has now been integrated.

Changeset: e628fd5c
Author:    Daniel Jeli?ski <djelinski at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/e628fd5c39847f2f9813cce8e78be8db5e60507d
Stats:     72 lines in 1 file changed: 2 ins; 59 del; 11 mod

8301214: Adjust handshakeTimeout value in test HandshakeTimeout.java after 8189338

Reviewed-by: msheppar, vtewari

-------------

PR: https://git.openjdk.org/jdk/pull/12292

From asotona at openjdk.org  Wed Feb  8 08:13:52 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Wed, 8 Feb 2023 08:13:52 GMT
Subject: RFR: 8294982: Implementation of Classfile API [v12]
In-Reply-To: <qitIL4woheCXgtU3PEQiW2HgXeKxvsInBTYqJOSG3cY=.e28eda15-5eec-40e5-81c1-21c3b7b23ac4@github.com>
References: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
 <Q4VeZ2yWAg85FqUDJa5hYq3jHty5H547gD0H-x3oIq0=.58d463a4-237a-4fee-bd0f-83262d49522a@github.com>
 <c022hrWNEHW76nhP_sXTQXCTjtL8jjM8r_yYv0IvbPI=.2a9cfbae-2fef-4cdb-8189-b869b1513fef@github.com>
 <iJyGP0x-bzXtRchGky3D7nJr-J2k4XPtl64FjcXJtCQ=.a9d4c1cd-08a7-4b8b-b43e-57a264d7265c@github.com>
 <qitIL4woheCXgtU3PEQiW2HgXeKxvsInBTYqJOSG3cY=.e28eda15-5eec-40e5-81c1-21c3b7b23ac4@github.com>
Message-ID: <i1dqvKVO0JLyBTVg_Rc7Pv6VyjHRwXUeY_V3LO6XQmA=.e041677f-6011-4205-86c6-f91efd1a7598@github.com>

On Tue, 7 Feb 2023 11:53:46 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> `BootstrapMethodEntry` is not a constant pool entry, but `BootstrapMethodsAttribute` entry.
>> It might be rather moved under `attribute` package and renamed to `BootstrapMethodInfo` to follow the same pattern as other attributes/infos.
>
> I know it's part of an attribute - but reading the javadoc:
> 
> /**
>  * Models an entry in the bootstrap method table.  The bootstrap method table
>  * is stored in the {@code BootstrapMethods} attribute, but is modeled by
>  * the {@link ConstantPool}, since the bootstrap method table is logically
>  * part of the constant pool.
>  */
>  ```
>  
>  And also, seeing the method:
>  
>  ```
>  /**
>      * {@return the constant pool associated with this entry}
>      */
>     ConstantPool constantPool();
> 
> 
> It seems like the API is doing the (justifiable) trick of making BSMs look like if they are first-class CP entries (even if not specified that way in the JVMLS). I think that's a fine move, but if we go down that path we should be honest, and put this class in constantpool. At least this is my 0.02$.

I see your point. The duality of `BootstrapMethodEntry` and potential confusion when moved under `attribute` or under `constantpool` package is the reason why it probably should stay where it is.
However feel free to discuss it at the mailing list.
Thanks.

-------------

PR: https://git.openjdk.org/jdk/pull/10982

From alanb at openjdk.org  Wed Feb  8 08:14:33 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 8 Feb 2023 08:14:33 GMT
Subject: RFR: 8301767: Convert virtual thread tests to JUnit [v2]
In-Reply-To: <37UDjOGF9PZxUiP2BwkrfIKh82vQgdvA8pwxaln4pl8=.5f368aea-d8a2-4e4a-a6ae-4376e1f05c9b@github.com>
References: <37UDjOGF9PZxUiP2BwkrfIKh82vQgdvA8pwxaln4pl8=.5f368aea-d8a2-4e4a-a6ae-4376e1f05c9b@github.com>
Message-ID: <uVH-roGm09SLtu0SV6K_oadsB_NpmPw2V7DtLEu1qUY=.9963cf59-e7ea-498e-8f5d-47dc8fa95440@github.com>

> The non-hotspot tests integrated with JEP 425/428 were mostly TestNG tests. We'd like to convert these JUnit in the main line in advance of other updates to these tests in 21.  The changes are mostly mechanical and trivial:
> 
> - BeforeClass/AfterClass changed to static BeforeAll/AfterAll methods
> - Tests using data providers are changed to parameterized tests
> - The order of the parameters to assertEquals are swapped so that the expected result is the first parameter
> - Usages of expectThrows are changed to assertThrows
> - Tests that threw SkipException are changed to the Assumptions API
> 
> There are a small number of drive-by changes to the tests, nothing significant, e.g.
> 
> - GetStackTrace and ParkWithFixedThreadPool changed from "@run testng" to "@run main" as they aren't TestNG tests.
> - A few of the tests in StructuredTaskScopeTest for joinXXX are changed to use a CountDownLatch rather than sleeping, as the original tests weren't very robust.

Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits:

 - Merge
 - Merge
 - Fix typos in comments
 - GetStackTrace.java test missing @requires vm.continuations
 - Initial commit

-------------

Changes: https://git.openjdk.org/jdk/pull/12426/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12426&range=01
  Stats: 1415 lines in 34 files changed: 205 ins; 79 del; 1131 mod
  Patch: https://git.openjdk.org/jdk/pull/12426.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12426/head:pull/12426

PR: https://git.openjdk.org/jdk/pull/12426

From duke at openjdk.org  Wed Feb  8 08:18:52 2023
From: duke at openjdk.org (Francesco Nigro)
Date: Wed, 8 Feb 2023 08:18:52 GMT
Subject: RFR: 8301958: Reduce Arrays.copyOf/-Range overheads [v7]
In-Reply-To: <n8n_xh_R8sORHd7q5kwEa0kRxoSgBvgaWe_qdliwFFw=.52872c7b-7cb6-4ea4-932f-5d4f57c515eb@github.com>
References: <2pdPoSHz2RJ7YDHOwOyszQMVv0v7FQFOwykfJ-za_e0=.cfe480da-a045-4b9a-bec7-7fffd0f47206@github.com>
 <n8n_xh_R8sORHd7q5kwEa0kRxoSgBvgaWe_qdliwFFw=.52872c7b-7cb6-4ea4-932f-5d4f57c515eb@github.com>
Message-ID: <4cuay6Q7tha4k6shmgdxHJf4f5MlsTqSZeq29w8MzP4=.310f087e-e09d-4a09-b9ae-afdf2d1f273c@github.com>

On Wed, 8 Feb 2023 00:07:14 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> This patch adds special-cases to `Arrays.copyOf` and `Arrays.copyOfRange` to clone arrays when `newLength` or range inputs span the input array. This helps eliminate range checks and has been verified to help various String operations. Example:
>> 
>> Baseline
>> 
>> Benchmark                                            (size)  Mode  Cnt   Score   Error  Units
>> StringConstructor.newStringFromArray                      7  avgt   15  16.817 ? 0.369  ns/op
>> StringConstructor.newStringFromArrayWithCharset           7  avgt   15  16.866 ? 0.449  ns/op
>> StringConstructor.newStringFromArrayWithCharsetName       7  avgt   15  22.198 ? 0.396  ns/op
>> 
>> Patch: 
>> 
>> Benchmark                                            (size)  Mode  Cnt   Score   Error  Units
>> StringConstructor.newStringFromArray                      7  avgt   15  14.666 ? 0.336  ns/op
>> StringConstructor.newStringFromArrayWithCharset           7  avgt   15  14.582 ? 0.288  ns/op
>> StringConstructor.newStringFromArrayWithCharsetName       7  avgt   15  20.339 ? 0.328  ns/op
>
> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Minimize, force inline, generalize

test/micro/org/openjdk/bench/java/lang/StringConstructor.java line 40:

> 38: 
> 39:   @Param({"0", "7", "64"})
> 40:   public int size;

I suggest to add the param `offset` for future experiment: together with `perfasm` it helps to check how different stubs are used and emulate the different branches of the optimized code

-------------

PR: https://git.openjdk.org/jdk/pull/12453

From asotona at openjdk.org  Wed Feb  8 08:20:54 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Wed, 8 Feb 2023 08:20:54 GMT
Subject: RFR: 8294982: Implementation of Classfile API [v12]
In-Reply-To: <c022hrWNEHW76nhP_sXTQXCTjtL8jjM8r_yYv0IvbPI=.2a9cfbae-2fef-4cdb-8189-b869b1513fef@github.com>
References: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
 <Q4VeZ2yWAg85FqUDJa5hYq3jHty5H547gD0H-x3oIq0=.58d463a4-237a-4fee-bd0f-83262d49522a@github.com>
 <c022hrWNEHW76nhP_sXTQXCTjtL8jjM8r_yYv0IvbPI=.2a9cfbae-2fef-4cdb-8189-b869b1513fef@github.com>
Message-ID: <5QI6iG-7drs8x5fRc_0seFFHcfmOvYvkZCEMKaVN8Zw=.ebcb480c-019d-4339-af32-6759198aacac@github.com>

On Fri, 3 Feb 2023 18:33:46 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Classfile API moved under jdk.internal.classfile package
>
> src/java.base/share/classes/jdk/internal/classfile/FieldTransform.java line 92:
> 
>> 90:      * @return the field transform
>> 91:      */
>> 92:     static FieldTransform dropping(Predicate<FieldElement> filter) {
> 
> Could this be a more general static generic method on ClassfileTransform? (but I see CodeTransform doesn't have it - not sure if that's deliberate).

It is deliberate as we didn't found meaningful use case for transformation just dropping individual code elements.

-------------

PR: https://git.openjdk.org/jdk/pull/10982

From asotona at openjdk.org  Wed Feb  8 08:20:59 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Wed, 8 Feb 2023 08:20:59 GMT
Subject: RFR: 8294982: Implementation of Classfile API [v13]
In-Reply-To: <u6VmkXvghsyyf7qwyHyDpcqZ-wVCfFnZgOoB_wiz2-A=.ce2c44e1-81b0-4851-811c-5f4fd3fdda62@github.com>
References: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
 <Ej4u9wRtUuLS5LJhMkXwmown_MGuwR0gH9ruJ1A1g30=.f6405576-6655-4252-9135-ebc77765436e@github.com>
 <u6VmkXvghsyyf7qwyHyDpcqZ-wVCfFnZgOoB_wiz2-A=.ce2c44e1-81b0-4851-811c-5f4fd3fdda62@github.com>
Message-ID: <5dkNbhPrs6OGfgCDFzyB-KljRx8eT_UTqQfAIPNJy7w=.b950570a-4d5e-45fa-901d-95cc2b1560fc@github.com>

On Tue, 7 Feb 2023 15:18:17 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Adam Sotona has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - javadoc fixes
>>  - obsolete identifiers and unused imports cleanup
>>  - TypeAnnotation.TypePathComponent cleanup
>
> src/java.base/share/classes/jdk/internal/classfile/attribute/CharacterRangeInfo.java line 80:
> 
>> 78:      * well as increment and decrement expressions (both prefix and postfix).
>> 79:      * <li>{@link jdk.internal.classfile.Classfile#CRT_FLOW_CONTROLLER} An expression
>> 80:      * whose value will effect control flow. Flowcon in the following:
> 
> This sentence seems hard to parse. If `Flowcon` is the name of an expression in pseudocode, perhaps using `{@code}` would help.

Will fix it, thanks.

-------------

PR: https://git.openjdk.org/jdk/pull/10982

From asotona at openjdk.org  Wed Feb  8 09:00:58 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Wed, 8 Feb 2023 09:00:58 GMT
Subject: RFR: 8294982: Implementation of Classfile API [v13]
In-Reply-To: <u6VmkXvghsyyf7qwyHyDpcqZ-wVCfFnZgOoB_wiz2-A=.ce2c44e1-81b0-4851-811c-5f4fd3fdda62@github.com>
References: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
 <Ej4u9wRtUuLS5LJhMkXwmown_MGuwR0gH9ruJ1A1g30=.f6405576-6655-4252-9135-ebc77765436e@github.com>
 <u6VmkXvghsyyf7qwyHyDpcqZ-wVCfFnZgOoB_wiz2-A=.ce2c44e1-81b0-4851-811c-5f4fd3fdda62@github.com>
Message-ID: <pU5kuRB02JMpu4LGjx9lFi4tpXaUOL8s9y2r-kqDb9Q=.bb0f46e8-1aec-436f-9b0a-0542ef1b55a9@github.com>

On Tue, 7 Feb 2023 15:26:12 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Adam Sotona has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - javadoc fixes
>>  - obsolete identifiers and unused imports cleanup
>>  - TypeAnnotation.TypePathComponent cleanup
>
> src/java.base/share/classes/jdk/internal/classfile/attribute/CodeAttribute.java line 52:
> 
>> 50:     byte[] codeArray();
>> 51: 
>> 52:     int labelToBci(Label label);
> 
> Missing javadoc here. (also, this method looks a bit odd in here - but I see uses e.g. in ClassPrinterImpl)

Will fix it, thanks.

-------------

PR: https://git.openjdk.org/jdk/pull/10982

From jpai at openjdk.org  Wed Feb  8 09:16:52 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 8 Feb 2023 09:16:52 GMT
Subject: RFR: 8301767: Convert virtual thread tests to JUnit [v2]
In-Reply-To: <uVH-roGm09SLtu0SV6K_oadsB_NpmPw2V7DtLEu1qUY=.9963cf59-e7ea-498e-8f5d-47dc8fa95440@github.com>
References: <37UDjOGF9PZxUiP2BwkrfIKh82vQgdvA8pwxaln4pl8=.5f368aea-d8a2-4e4a-a6ae-4376e1f05c9b@github.com>
 <uVH-roGm09SLtu0SV6K_oadsB_NpmPw2V7DtLEu1qUY=.9963cf59-e7ea-498e-8f5d-47dc8fa95440@github.com>
Message-ID: <ORxqaxpUaUXmz6N3cg0R5vYgFLswtxpi3BCh6xQF6tM=.1ffa8327-e143-4ef6-b479-53d2cd0451b9@github.com>

On Wed, 8 Feb 2023 08:14:33 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> The non-hotspot tests integrated with JEP 425/428 were mostly TestNG tests. We'd like to convert these JUnit in the main line in advance of other updates to these tests in 21.  The changes are mostly mechanical and trivial:
>> 
>> - BeforeClass/AfterClass changed to static BeforeAll/AfterAll methods
>> - Tests using data providers are changed to parameterized tests
>> - The order of the parameters to assertEquals are swapped so that the expected result is the first parameter
>> - Usages of expectThrows are changed to assertThrows
>> - Tests that threw SkipException are changed to the Assumptions API
>> 
>> There are a small number of drive-by changes to the tests, nothing significant, e.g.
>> 
>> - GetStackTrace and ParkWithFixedThreadPool changed from "@run testng" to "@run main" as they aren't TestNG tests.
>> - A few of the tests in StructuredTaskScopeTest for joinXXX are changed to use a CountDownLatch rather than sleeping, as the original tests weren't very robust.
>
> Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits:
> 
>  - Merge
>  - Merge
>  - Fix typos in comments
>  - GetStackTrace.java test missing @requires vm.continuations
>  - Initial commit

test/jdk/java/lang/Thread/BuilderTest.java line 294:

> 292:     void testPriority3() {
> 293:         Thread currentThread = Thread.currentThread();
> 294:         assumeFalse(currentThread.isVirtual(), "Main test is a virtual thread");

Hello Alan, not specifically related to the changes in this PR, but should that message have been "Main thread ..." instead of "Main test ..."?

-------------

PR: https://git.openjdk.org/jdk/pull/12426

From jpai at openjdk.org  Wed Feb  8 09:25:46 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 8 Feb 2023 09:25:46 GMT
Subject: RFR: 8301767: Convert virtual thread tests to JUnit [v2]
In-Reply-To: <ORxqaxpUaUXmz6N3cg0R5vYgFLswtxpi3BCh6xQF6tM=.1ffa8327-e143-4ef6-b479-53d2cd0451b9@github.com>
References: <37UDjOGF9PZxUiP2BwkrfIKh82vQgdvA8pwxaln4pl8=.5f368aea-d8a2-4e4a-a6ae-4376e1f05c9b@github.com>
 <uVH-roGm09SLtu0SV6K_oadsB_NpmPw2V7DtLEu1qUY=.9963cf59-e7ea-498e-8f5d-47dc8fa95440@github.com>
 <ORxqaxpUaUXmz6N3cg0R5vYgFLswtxpi3BCh6xQF6tM=.1ffa8327-e143-4ef6-b479-53d2cd0451b9@github.com>
Message-ID: <oBvBwEYRlbD2_liqdooldaUfQBz1nPVJvk9K1KOXa-Q=.c521a5dd-4450-4e26-8479-3f8c3450fba7@github.com>

On Wed, 8 Feb 2023 09:13:37 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits:
>> 
>>  - Merge
>>  - Merge
>>  - Fix typos in comments
>>  - GetStackTrace.java test missing @requires vm.continuations
>>  - Initial commit
>
> test/jdk/java/lang/Thread/BuilderTest.java line 294:
> 
>> 292:     void testPriority3() {
>> 293:         Thread currentThread = Thread.currentThread();
>> 294:         assumeFalse(currentThread.isVirtual(), "Main test is a virtual thread");
> 
> Hello Alan, not specifically related to the changes in this PR, but should that message have been "Main thread ..." instead of "Main test ..."?

Same comment for test methods in `CustomScheduler`

-------------

PR: https://git.openjdk.org/jdk/pull/12426

From jpai at openjdk.org  Wed Feb  8 09:25:48 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 8 Feb 2023 09:25:48 GMT
Subject: RFR: 8301767: Convert virtual thread tests to JUnit [v2]
In-Reply-To: <uVH-roGm09SLtu0SV6K_oadsB_NpmPw2V7DtLEu1qUY=.9963cf59-e7ea-498e-8f5d-47dc8fa95440@github.com>
References: <37UDjOGF9PZxUiP2BwkrfIKh82vQgdvA8pwxaln4pl8=.5f368aea-d8a2-4e4a-a6ae-4376e1f05c9b@github.com>
 <uVH-roGm09SLtu0SV6K_oadsB_NpmPw2V7DtLEu1qUY=.9963cf59-e7ea-498e-8f5d-47dc8fa95440@github.com>
Message-ID: <ntD3tzvoYDf6d5ZL3okOnC6sfcZPnsyr41aRPH4CN0o=.4eb4bccf-caf4-47d8-8901-c9d4d4362434@github.com>

On Wed, 8 Feb 2023 08:14:33 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> The non-hotspot tests integrated with JEP 425/428 were mostly TestNG tests. We'd like to convert these JUnit in the main line in advance of other updates to these tests in 21.  The changes are mostly mechanical and trivial:
>> 
>> - BeforeClass/AfterClass changed to static BeforeAll/AfterAll methods
>> - Tests using data providers are changed to parameterized tests
>> - The order of the parameters to assertEquals are swapped so that the expected result is the first parameter
>> - Usages of expectThrows are changed to assertThrows
>> - Tests that threw SkipException are changed to the Assumptions API
>> 
>> There are a small number of drive-by changes to the tests, nothing significant, e.g.
>> 
>> - GetStackTrace and ParkWithFixedThreadPool changed from "@run testng" to "@run main" as they aren't TestNG tests.
>> - A few of the tests in StructuredTaskScopeTest for joinXXX are changed to use a CountDownLatch rather than sleeping, as the original tests weren't very robust.
>
> Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits:
> 
>  - Merge
>  - Merge
>  - Fix typos in comments
>  - GetStackTrace.java test missing @requires vm.continuations
>  - Initial commit

test/jdk/java/lang/Thread/UncaughtExceptionsTest.java line 30:

> 28: import org.junit.jupiter.api.Test;
> 29: import org.junit.jupiter.api.BeforeAll;
> 30: import org.junit.jupiter.api.AfterAll;

It looks like BeforeAll and AfterAll imports are unused in this test.

-------------

PR: https://git.openjdk.org/jdk/pull/12426

From jpai at openjdk.org  Wed Feb  8 09:35:45 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 8 Feb 2023 09:35:45 GMT
Subject: RFR: 8301767: Convert virtual thread tests to JUnit [v2]
In-Reply-To: <uVH-roGm09SLtu0SV6K_oadsB_NpmPw2V7DtLEu1qUY=.9963cf59-e7ea-498e-8f5d-47dc8fa95440@github.com>
References: <37UDjOGF9PZxUiP2BwkrfIKh82vQgdvA8pwxaln4pl8=.5f368aea-d8a2-4e4a-a6ae-4376e1f05c9b@github.com>
 <uVH-roGm09SLtu0SV6K_oadsB_NpmPw2V7DtLEu1qUY=.9963cf59-e7ea-498e-8f5d-47dc8fa95440@github.com>
Message-ID: <L60W-QEFW8rqFe7wDJgs5chNinnVgkCkjXH0DK4WH34=.4de50ddb-b11d-422e-bc96-a6fc0e00dd17@github.com>

On Wed, 8 Feb 2023 08:14:33 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> The non-hotspot tests integrated with JEP 425/428 were mostly TestNG tests. We'd like to convert these JUnit in the main line in advance of other updates to these tests in 21.  The changes are mostly mechanical and trivial:
>> 
>> - BeforeClass/AfterClass changed to static BeforeAll/AfterAll methods
>> - Tests using data providers are changed to parameterized tests
>> - The order of the parameters to assertEquals are swapped so that the expected result is the first parameter
>> - Usages of expectThrows are changed to assertThrows
>> - Tests that threw SkipException are changed to the Assumptions API
>> 
>> There are a small number of drive-by changes to the tests, nothing significant, e.g.
>> 
>> - GetStackTrace and ParkWithFixedThreadPool changed from "@run testng" to "@run main" as they aren't TestNG tests.
>> - A few of the tests in StructuredTaskScopeTest for joinXXX are changed to use a CountDownLatch rather than sleeping, as the original tests weren't very robust.
>
> Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits:
> 
>  - Merge
>  - Merge
>  - Fix typos in comments
>  - GetStackTrace.java test missing @requires vm.continuations
>  - Initial commit

test/jdk/java/lang/Thread/virtual/GetStackTrace.java line 31:

> 29:  * @enablePreview
> 30:  * @modules java.base/java.lang:+open
> 31:  * @run main GetStackTrace

That's interesting - so this test was marked as a testng test previously, but had not test methods in it. I had a look at the test run history of this one and I see that the test execution results in:

> java/lang/Thread/virtual/GetStackTrace.java
> Total tests run: 0, Passes: 0, Failures: 0, Skips: 0

I wonder if testng (and junit) can be configured to fail the test if no test methods were present, to flag such mistakes.

Keeping that aside, the change to make this `@run main` looks fine.

As for adding the `@requires vm.continuations`, I'm not familiar with its expectations. Looking at the test case, it just captures stacktraces using `Thread.getStackTrace()` and then just does some basic validation of those stacktrace elements. Do we use this `@requires vm.continuations` even in such tests?

-------------

PR: https://git.openjdk.org/jdk/pull/12426

From cstein at openjdk.org  Wed Feb  8 09:42:48 2023
From: cstein at openjdk.org (Christian Stein)
Date: Wed, 8 Feb 2023 09:42:48 GMT
Subject: RFR: 8301767: Convert virtual thread tests to JUnit [v2]
In-Reply-To: <L60W-QEFW8rqFe7wDJgs5chNinnVgkCkjXH0DK4WH34=.4de50ddb-b11d-422e-bc96-a6fc0e00dd17@github.com>
References: <37UDjOGF9PZxUiP2BwkrfIKh82vQgdvA8pwxaln4pl8=.5f368aea-d8a2-4e4a-a6ae-4376e1f05c9b@github.com>
 <uVH-roGm09SLtu0SV6K_oadsB_NpmPw2V7DtLEu1qUY=.9963cf59-e7ea-498e-8f5d-47dc8fa95440@github.com>
 <L60W-QEFW8rqFe7wDJgs5chNinnVgkCkjXH0DK4WH34=.4de50ddb-b11d-422e-bc96-a6fc0e00dd17@github.com>
Message-ID: <X2T458nbl6j97CLOuAUc8sytIPfAjVkjZWYTxEK-H1w=.b2cc8410-2245-4f6e-9dcf-5ebe6febeede@github.com>

On Wed, 8 Feb 2023 09:32:49 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> I wonder if testng (and junit) can be configured to fail the test if no test methods were present, to flag such mistakes.

JUnit's CLI tool has:

`--fail-if-no-tests     Fail and return exit status code 2 if no tests are found.`

We can add such a check into `jtreg`'s JUnit runner at
https://github.com/openjdk/jtreg/blob/524161b73dca250639ad3f00a42518e384276906/src/share/classes/com/sun/javatest/regtest/agent/JUnitRunner.java#L149-L151

-------------

PR: https://git.openjdk.org/jdk/pull/12426

From jpai at openjdk.org  Wed Feb  8 09:42:54 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 8 Feb 2023 09:42:54 GMT
Subject: RFR: 8301767: Convert virtual thread tests to JUnit [v2]
In-Reply-To: <uVH-roGm09SLtu0SV6K_oadsB_NpmPw2V7DtLEu1qUY=.9963cf59-e7ea-498e-8f5d-47dc8fa95440@github.com>
References: <37UDjOGF9PZxUiP2BwkrfIKh82vQgdvA8pwxaln4pl8=.5f368aea-d8a2-4e4a-a6ae-4376e1f05c9b@github.com>
 <uVH-roGm09SLtu0SV6K_oadsB_NpmPw2V7DtLEu1qUY=.9963cf59-e7ea-498e-8f5d-47dc8fa95440@github.com>
Message-ID: <Elipcpaj2eeNZPXIpFI1r4spLHR1fWUb8F7OHxKfyhQ=.028ac978-837c-432c-aac4-7435e87ecfdd@github.com>

On Wed, 8 Feb 2023 08:14:33 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> The non-hotspot tests integrated with JEP 425/428 were mostly TestNG tests. We'd like to convert these JUnit in the main line in advance of other updates to these tests in 21.  The changes are mostly mechanical and trivial:
>> 
>> - BeforeClass/AfterClass changed to static BeforeAll/AfterAll methods
>> - Tests using data providers are changed to parameterized tests
>> - The order of the parameters to assertEquals are swapped so that the expected result is the first parameter
>> - Usages of expectThrows are changed to assertThrows
>> - Tests that threw SkipException are changed to the Assumptions API
>> 
>> There are a small number of drive-by changes to the tests, nothing significant, e.g.
>> 
>> - GetStackTrace and ParkWithFixedThreadPool changed from "@run testng" to "@run main" as they aren't TestNG tests.
>> - A few of the tests in StructuredTaskScopeTest for joinXXX are changed to use a CountDownLatch rather than sleeping, as the original tests weren't very robust.
>
> Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits:
> 
>  - Merge
>  - Merge
>  - Fix typos in comments
>  - GetStackTrace.java test missing @requires vm.continuations
>  - Initial commit

test/jdk/java/lang/Thread/virtual/HoldsLock.java line 131:

> 129:                 assertEquals(vthread.getClass().getName(), info.getLockInfo().getClassName());
> 130:                 assertTrue(info.getLockInfo().getIdentityHashCode() == System.identityHashCode(vthread));
> 131:                 assertTrue(info.getLockOwnerId() == vthreadId);

Previously, before the change to these lines, in case of failure, the `assertEquals` would have printed even the incorrect/unexpected value in the log file/exception. Now with the usage of `assertTrue`, that information is lost from the failures. Do you think, in the context of this test, it would be worth to continue using assertEquals and just switch the param order to match junit expectations.

-------------

PR: https://git.openjdk.org/jdk/pull/12426

From qamai at openjdk.org  Wed Feb  8 09:48:46 2023
From: qamai at openjdk.org (Quan Anh Mai)
Date: Wed, 8 Feb 2023 09:48:46 GMT
Subject: RFR: 8301226: Add clamp() methods to java.lang.Math and to
 StrictMath [v2]
In-Reply-To: <B0MVO0tdv89nSvtjf17yQJRzLZIyB3Rvi2fvdfs1o10=.9f84433c-2ff5-49e1-bdc3-df1c68a72ad2@github.com>
References: <c7kJhZvT8oz5hScMxnWI23H7wjCaJ854ajjSRtxBnW4=.3f4e24ca-c608-4541-b80e-cf3452ec6400@github.com>
 <HD7wHqgfG1HUEElreURLgxBPOk9-R1jMiKNuquMvarE=.0f5a58cd-6faf-41db-87d8-5358f1251ab9@github.com>
 <jDUID4DZVg9PMYqC-QogTLTgI-JDctEjL26Z_VzWSH0=.5689e9c8-ced5-42ab-b773-b310cd9227e1@github.com>
 <qnUokZ-1TMMQGZ9iS7CxOB74udDSe_SQGpMoAESbKso=.5c62e6b4-5eaf-4974-8d40-529ec8a04cf0@github.com>
 <a6b2jZCBiX1fOyI-gWTu81vKWKAJ-FvjPCu2WfwYlqM=.38ce531a-f759-451f-bfaf-6c76c1631d46@github.com>
 <B0MVO0tdv89nSvtjf17yQJRzLZIyB3Rvi2fvdfs1o10=.9f84433c-2ff5-49e1-bdc3-df1c68a72ad2@github.com>
Message-ID: <D6quJ6ap6PTF8EGFgj2B_dIYEJ5-aN8Cp8RyH-idxZI=.60a5dd04-878b-43e3-916b-865417b5bf0f@github.com>

On Tue, 7 Feb 2023 13:30:24 GMT, Tagir F. Valeev <tvaleev at openjdk.org> wrote:

>> A?pure `int`?only overload doesn?t have?to?go through the?`int` ??`long` ??`int`?conversion.
>
> Is this a real problem?

This should not be a problem with C2, and with the lower compilation levels this insignificant impact seems to not justify adding an overload

-------------

PR: https://git.openjdk.org/jdk/pull/12428

From alanb at openjdk.org  Wed Feb  8 09:51:44 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 8 Feb 2023 09:51:44 GMT
Subject: RFR: 8301767: Convert virtual thread tests to JUnit [v2]
In-Reply-To: <oBvBwEYRlbD2_liqdooldaUfQBz1nPVJvk9K1KOXa-Q=.c521a5dd-4450-4e26-8479-3f8c3450fba7@github.com>
References: <37UDjOGF9PZxUiP2BwkrfIKh82vQgdvA8pwxaln4pl8=.5f368aea-d8a2-4e4a-a6ae-4376e1f05c9b@github.com>
 <uVH-roGm09SLtu0SV6K_oadsB_NpmPw2V7DtLEu1qUY=.9963cf59-e7ea-498e-8f5d-47dc8fa95440@github.com>
 <ORxqaxpUaUXmz6N3cg0R5vYgFLswtxpi3BCh6xQF6tM=.1ffa8327-e143-4ef6-b479-53d2cd0451b9@github.com>
 <oBvBwEYRlbD2_liqdooldaUfQBz1nPVJvk9K1KOXa-Q=.c521a5dd-4450-4e26-8479-3f8c3450fba7@github.com>
Message-ID: <Hx-ZBOj60zEPGka1-UHfE6S4Cp7botqKZz0qSPIXzp4=.2657065e-f1d8-4b18-9cc7-b4ac5e903521@github.com>

On Wed, 8 Feb 2023 09:22:36 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> test/jdk/java/lang/Thread/BuilderTest.java line 294:
>> 
>>> 292:     void testPriority3() {
>>> 293:         Thread currentThread = Thread.currentThread();
>>> 294:         assumeFalse(currentThread.isVirtual(), "Main test is a virtual thread");
>> 
>> Hello Alan, not specifically related to the changes in this PR, but should that message have been "Main thread ..." instead of "Main test ..."?
>
> Same comment for test methods in `CustomScheduler`

Well spotted. This was a find+replace change so I didn't notice that the original exception message had a typo.

-------------

PR: https://git.openjdk.org/jdk/pull/12426

From alanb at openjdk.org  Wed Feb  8 09:51:46 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 8 Feb 2023 09:51:46 GMT
Subject: RFR: 8301767: Convert virtual thread tests to JUnit [v2]
In-Reply-To: <X2T458nbl6j97CLOuAUc8sytIPfAjVkjZWYTxEK-H1w=.b2cc8410-2245-4f6e-9dcf-5ebe6febeede@github.com>
References: <37UDjOGF9PZxUiP2BwkrfIKh82vQgdvA8pwxaln4pl8=.5f368aea-d8a2-4e4a-a6ae-4376e1f05c9b@github.com>
 <uVH-roGm09SLtu0SV6K_oadsB_NpmPw2V7DtLEu1qUY=.9963cf59-e7ea-498e-8f5d-47dc8fa95440@github.com>
 <L60W-QEFW8rqFe7wDJgs5chNinnVgkCkjXH0DK4WH34=.4de50ddb-b11d-422e-bc96-a6fc0e00dd17@github.com>
 <X2T458nbl6j97CLOuAUc8sytIPfAjVkjZWYTxEK-H1w=.b2cc8410-2245-4f6e-9dcf-5ebe6febeede@github.com>
Message-ID: <3L-yZYrXApfYMYtQ5uBGVyrD9O5ExrY2MsgrG6pbEMQ=.d0e9d875-4e9e-46a7-8a90-9f15b6448d17@github.com>

On Wed, 8 Feb 2023 09:39:37 GMT, Christian Stein <cstein at openjdk.org> wrote:

>> test/jdk/java/lang/Thread/virtual/GetStackTrace.java line 31:
>> 
>>> 29:  * @enablePreview
>>> 30:  * @modules java.base/java.lang:+open
>>> 31:  * @run main GetStackTrace
>> 
>> That's interesting - so this test was marked as a testng test previously, but had not test methods in it. I had a look at the test run history of this one and I see that the test execution results in:
>> 
>>> java/lang/Thread/virtual/GetStackTrace.java
>>> Total tests run: 0, Passes: 0, Failures: 0, Skips: 0
>> 
>> I wonder if testng (and junit) can be configured to fail the test if no test methods were present, to flag such mistakes.
>> 
>> Keeping that aside, the change to make this `@run main` looks fine.
>> 
>> As for adding the `@requires vm.continuations`, I'm not familiar with its expectations. Looking at the test case, it just captures stacktraces using `Thread.getStackTrace()` and then just does some basic validation of those stacktrace elements. Do we use this `@requires vm.continuations` even in such tests?
>
>> I wonder if testng (and junit) can be configured to fail the test if no test methods were present, to flag such mistakes.
> 
> JUnit's CLI tool has:
> 
> `--fail-if-no-tests     Fail and return exit status code 2 if no tests are found.`
> 
> We can add such a check into `jtreg`'s JUnit runner at
> https://github.com/openjdk/jtreg/blob/524161b73dca250639ad3f00a42518e384276906/src/share/classes/com/sun/javatest/regtest/agent/JUnitRunner.java#L149-L151

> As for adding the `@requires vm.continuations`, I'm not familiar with its expectations. Looking at the test case, it just captures stacktraces using `Thread.getStackTrace()` and then just does some basic validation of those stacktrace elements. Do we use this `@requires vm.continuations` even in such tests?

Yes, it is needed as the alternative implementation of virtual threads (used on x86_32 and a few other ports) don't allow custom schedulers.

-------------

PR: https://git.openjdk.org/jdk/pull/12426

From jpai at openjdk.org  Wed Feb  8 09:51:50 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 8 Feb 2023 09:51:50 GMT
Subject: RFR: 8301767: Convert virtual thread tests to JUnit [v2]
In-Reply-To: <uVH-roGm09SLtu0SV6K_oadsB_NpmPw2V7DtLEu1qUY=.9963cf59-e7ea-498e-8f5d-47dc8fa95440@github.com>
References: <37UDjOGF9PZxUiP2BwkrfIKh82vQgdvA8pwxaln4pl8=.5f368aea-d8a2-4e4a-a6ae-4376e1f05c9b@github.com>
 <uVH-roGm09SLtu0SV6K_oadsB_NpmPw2V7DtLEu1qUY=.9963cf59-e7ea-498e-8f5d-47dc8fa95440@github.com>
Message-ID: <60s9cige1Vx5fbCW0HoSE6UbfTwn-lWYkvX9PLDLFt4=.5c5c67dd-b0bd-4fe8-86d2-e5d812436fb9@github.com>

On Wed, 8 Feb 2023 08:14:33 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> The non-hotspot tests integrated with JEP 425/428 were mostly TestNG tests. We'd like to convert these JUnit in the main line in advance of other updates to these tests in 21.  The changes are mostly mechanical and trivial:
>> 
>> - BeforeClass/AfterClass changed to static BeforeAll/AfterAll methods
>> - Tests using data providers are changed to parameterized tests
>> - The order of the parameters to assertEquals are swapped so that the expected result is the first parameter
>> - Usages of expectThrows are changed to assertThrows
>> - Tests that threw SkipException are changed to the Assumptions API
>> 
>> There are a small number of drive-by changes to the tests, nothing significant, e.g.
>> 
>> - GetStackTrace and ParkWithFixedThreadPool changed from "@run testng" to "@run main" as they aren't TestNG tests.
>> - A few of the tests in StructuredTaskScopeTest for joinXXX are changed to use a CountDownLatch rather than sleeping, as the original tests weren't very robust.
>
> Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits:
> 
>  - Merge
>  - Merge
>  - Fix typos in comments
>  - GetStackTrace.java test missing @requires vm.continuations
>  - Initial commit

test/jdk/java/lang/Thread/virtual/ThreadAPI.java line 82:

> 80:     @BeforeAll
> 81:     static void setup() throws Exception {
> 82:         ThreadFactory factory = Executors.defaultThreadFactory();

Unlike previously, this change now uses a `ThreadFactory` which creates non-daemon threads. Is that intentional?

-------------

PR: https://git.openjdk.org/jdk/pull/12426

From alanb at openjdk.org  Wed Feb  8 09:54:45 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 8 Feb 2023 09:54:45 GMT
Subject: RFR: 8301767: Convert virtual thread tests to JUnit [v2]
In-Reply-To: <60s9cige1Vx5fbCW0HoSE6UbfTwn-lWYkvX9PLDLFt4=.5c5c67dd-b0bd-4fe8-86d2-e5d812436fb9@github.com>
References: <37UDjOGF9PZxUiP2BwkrfIKh82vQgdvA8pwxaln4pl8=.5f368aea-d8a2-4e4a-a6ae-4376e1f05c9b@github.com>
 <uVH-roGm09SLtu0SV6K_oadsB_NpmPw2V7DtLEu1qUY=.9963cf59-e7ea-498e-8f5d-47dc8fa95440@github.com>
 <60s9cige1Vx5fbCW0HoSE6UbfTwn-lWYkvX9PLDLFt4=.5c5c67dd-b0bd-4fe8-86d2-e5d812436fb9@github.com>
Message-ID: <PyjsxQ6AWh5l7ErmTbt-qUNyeYPjLbo-p3D7N7o4zGo=.65eb199e-9adb-4499-84ca-eeef782275d8@github.com>

On Wed, 8 Feb 2023 09:49:17 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits:
>> 
>>  - Merge
>>  - Merge
>>  - Fix typos in comments
>>  - GetStackTrace.java test missing @requires vm.continuations
>>  - Initial commit
>
> test/jdk/java/lang/Thread/virtual/ThreadAPI.java line 82:
> 
>> 80:     @BeforeAll
>> 81:     static void setup() throws Exception {
>> 82:         ThreadFactory factory = Executors.defaultThreadFactory();
> 
> Unlike previously, this change now uses a `ThreadFactory` which creates non-daemon threads. Is that intentional?

It's not an issue. The `@AfterAll` finish method does the shutdown so it doesn't matter if the STPE threads are daemon or not.

-------------

PR: https://git.openjdk.org/jdk/pull/12426

From alanb at openjdk.org  Wed Feb  8 10:26:12 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 8 Feb 2023 10:26:12 GMT
Subject: RFR: 8301767: Convert virtual thread tests to JUnit [v3]
In-Reply-To: <37UDjOGF9PZxUiP2BwkrfIKh82vQgdvA8pwxaln4pl8=.5f368aea-d8a2-4e4a-a6ae-4376e1f05c9b@github.com>
References: <37UDjOGF9PZxUiP2BwkrfIKh82vQgdvA8pwxaln4pl8=.5f368aea-d8a2-4e4a-a6ae-4376e1f05c9b@github.com>
Message-ID: <cIruXOF-Q6fcx9ZYYBaM6yJlTxoCh-sAy5K0z7mJndU=.4f84f9e9-6e76-4b87-b460-9c15ca8f94a5@github.com>

> The non-hotspot tests integrated with JEP 425/428 were mostly TestNG tests. We'd like to convert these JUnit in the main line in advance of other updates to these tests in 21.  The changes are mostly mechanical and trivial:
> 
> - BeforeClass/AfterClass changed to static BeforeAll/AfterAll methods
> - Tests using data providers are changed to parameterized tests
> - The order of the parameters to assertEquals are swapped so that the expected result is the first parameter
> - Usages of expectThrows are changed to assertThrows
> - Tests that threw SkipException are changed to the Assumptions API
> 
> There are a small number of drive-by changes to the tests, nothing significant, e.g.
> 
> - GetStackTrace and ParkWithFixedThreadPool changed from "@run testng" to "@run main" as they aren't TestNG tests.
> - A few of the tests in StructuredTaskScopeTest for joinXXX are changed to use a CountDownLatch rather than sleeping, as the original tests weren't very robust.

Alan Bateman has updated the pull request incrementally with one additional commit since the last revision:

  Fix typo in assumption message

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12426/files
  - new: https://git.openjdk.org/jdk/pull/12426/files/7dc07c4b..75176342

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12426&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12426&range=01-02

  Stats: 6 lines in 3 files changed: 0 ins; 2 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/12426.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12426/head:pull/12426

PR: https://git.openjdk.org/jdk/pull/12426

From jpai at openjdk.org  Wed Feb  8 10:26:15 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 8 Feb 2023 10:26:15 GMT
Subject: RFR: 8301767: Convert virtual thread tests to JUnit [v2]
In-Reply-To: <uVH-roGm09SLtu0SV6K_oadsB_NpmPw2V7DtLEu1qUY=.9963cf59-e7ea-498e-8f5d-47dc8fa95440@github.com>
References: <37UDjOGF9PZxUiP2BwkrfIKh82vQgdvA8pwxaln4pl8=.5f368aea-d8a2-4e4a-a6ae-4376e1f05c9b@github.com>
 <uVH-roGm09SLtu0SV6K_oadsB_NpmPw2V7DtLEu1qUY=.9963cf59-e7ea-498e-8f5d-47dc8fa95440@github.com>
Message-ID: <oXcM_Fltsi1oxChITx4PhE_IBY8bN-PeduFear4gGDE=.1da4240d-678e-41a6-bf8a-96132831eba7@github.com>

On Wed, 8 Feb 2023 08:14:33 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> The non-hotspot tests integrated with JEP 425/428 were mostly TestNG tests. We'd like to convert these JUnit in the main line in advance of other updates to these tests in 21.  The changes are mostly mechanical and trivial:
>> 
>> - BeforeClass/AfterClass changed to static BeforeAll/AfterAll methods
>> - Tests using data providers are changed to parameterized tests
>> - The order of the parameters to assertEquals are swapped so that the expected result is the first parameter
>> - Usages of expectThrows are changed to assertThrows
>> - Tests that threw SkipException are changed to the Assumptions API
>> 
>> There are a small number of drive-by changes to the tests, nothing significant, e.g.
>> 
>> - GetStackTrace and ParkWithFixedThreadPool changed from "@run testng" to "@run main" as they aren't TestNG tests.
>> - A few of the tests in StructuredTaskScopeTest for joinXXX are changed to use a CountDownLatch rather than sleeping, as the original tests weren't very robust.
>
> Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits:
> 
>  - Merge
>  - Merge
>  - Fix typos in comments
>  - GetStackTrace.java test missing @requires vm.continuations
>  - Initial commit

test/jdk/jdk/incubator/concurrent/ScopedValue/ScopeValueAPI.java line 310:

> 308:             ScopedValue.where(name, null, () -> {
> 309:                 assertTrue(name.isBound());
> 310:                 assertTrue(name.get() == null);

Perhaps `assertNull(name.get())`?. Same on line 325.

-------------

PR: https://git.openjdk.org/jdk/pull/12426

From jpai at openjdk.org  Wed Feb  8 10:32:45 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 8 Feb 2023 10:32:45 GMT
Subject: RFR: 8301767: Convert virtual thread tests to JUnit [v2]
In-Reply-To: <uVH-roGm09SLtu0SV6K_oadsB_NpmPw2V7DtLEu1qUY=.9963cf59-e7ea-498e-8f5d-47dc8fa95440@github.com>
References: <37UDjOGF9PZxUiP2BwkrfIKh82vQgdvA8pwxaln4pl8=.5f368aea-d8a2-4e4a-a6ae-4376e1f05c9b@github.com>
 <uVH-roGm09SLtu0SV6K_oadsB_NpmPw2V7DtLEu1qUY=.9963cf59-e7ea-498e-8f5d-47dc8fa95440@github.com>
Message-ID: <u5_YHDGu-eiFXGelIbl_Aa130SIfzwvyrG2dp2q6Ao4=.954e07e1-c46d-4a9e-944b-704bb0e7540f@github.com>

On Wed, 8 Feb 2023 08:14:33 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> The non-hotspot tests integrated with JEP 425/428 were mostly TestNG tests. We'd like to convert these JUnit in the main line in advance of other updates to these tests in 21.  The changes are mostly mechanical and trivial:
>> 
>> - BeforeClass/AfterClass changed to static BeforeAll/AfterAll methods
>> - Tests using data providers are changed to parameterized tests
>> - The order of the parameters to assertEquals are swapped so that the expected result is the first parameter
>> - Usages of expectThrows are changed to assertThrows
>> - Tests that threw SkipException are changed to the Assumptions API
>> 
>> There are a small number of drive-by changes to the tests, nothing significant, e.g.
>> 
>> - GetStackTrace and ParkWithFixedThreadPool changed from "@run testng" to "@run main" as they aren't TestNG tests.
>> - A few of the tests in StructuredTaskScopeTest for joinXXX are changed to use a CountDownLatch rather than sleeping, as the original tests weren't very robust.
>
> Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits:
> 
>  - Merge
>  - Merge
>  - Fix typos in comments
>  - GetStackTrace.java test missing @requires vm.continuations
>  - Initial commit

test/jdk/jdk/internal/misc/ThreadFlock/ThreadFlockTest.java line 92:

> 90:             assertTrue(flock.name() == null);
> 91:             flock.close();
> 92:             assertTrue(flock.name() == null);  // after close

assertNull, here and line 90?

-------------

PR: https://git.openjdk.org/jdk/pull/12426

From jpai at openjdk.org  Wed Feb  8 10:39:45 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 8 Feb 2023 10:39:45 GMT
Subject: RFR: 8301767: Convert virtual thread tests to JUnit [v2]
In-Reply-To: <uVH-roGm09SLtu0SV6K_oadsB_NpmPw2V7DtLEu1qUY=.9963cf59-e7ea-498e-8f5d-47dc8fa95440@github.com>
References: <37UDjOGF9PZxUiP2BwkrfIKh82vQgdvA8pwxaln4pl8=.5f368aea-d8a2-4e4a-a6ae-4376e1f05c9b@github.com>
 <uVH-roGm09SLtu0SV6K_oadsB_NpmPw2V7DtLEu1qUY=.9963cf59-e7ea-498e-8f5d-47dc8fa95440@github.com>
Message-ID: <pRk9Bm5maTzevQy3-dF5KCc55GkwxBFSJW5MEELi8fg=.500f3452-e14e-49ce-845e-16ce5214afc4@github.com>

On Wed, 8 Feb 2023 08:14:33 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> The non-hotspot tests integrated with JEP 425/428 were mostly TestNG tests. We'd like to convert these JUnit in the main line in advance of other updates to these tests in 21.  The changes are mostly mechanical and trivial:
>> 
>> - BeforeClass/AfterClass changed to static BeforeAll/AfterAll methods
>> - Tests using data providers are changed to parameterized tests
>> - The order of the parameters to assertEquals are swapped so that the expected result is the first parameter
>> - Usages of expectThrows are changed to assertThrows
>> - Tests that threw SkipException are changed to the Assumptions API
>> 
>> There are a small number of drive-by changes to the tests, nothing significant, e.g.
>> 
>> - GetStackTrace and ParkWithFixedThreadPool changed from "@run testng" to "@run main" as they aren't TestNG tests.
>> - A few of the tests in StructuredTaskScopeTest for joinXXX are changed to use a CountDownLatch rather than sleeping, as the original tests weren't very robust.
>
> Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits:
> 
>  - Merge
>  - Merge
>  - Fix typos in comments
>  - GetStackTrace.java test missing @requires vm.continuations
>  - Initial commit

test/jdk/jdk/internal/misc/ThreadFlock/WithScopedValue.java line 48:

> 46: 
> 47:     private static Stream<ThreadFactory> factories() {
> 48:         return Stream.of(Thread.ofPlatform().factory(), Thread.ofVirtual().factory());

Previously, before this change, the data provided to the test methods, comprised of a virtual ThreadFactory and a `Executors.defaultThreadFactory()`. Is this switch to using a `Thread.ofPlatform().factory()` OK in the context of this test?

-------------

PR: https://git.openjdk.org/jdk/pull/12426

From asotona at openjdk.org  Wed Feb  8 10:40:34 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Wed, 8 Feb 2023 10:40:34 GMT
Subject: RFR: 8294982: Implementation of Classfile API [v14]
In-Reply-To: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
References: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
Message-ID: <UGEwpYPu7X9LadwlqPvS8FvvVngcwlBLjZE7j4iMxcQ=.fdc3b944-a490-43ba-b577-4ccbb2de41f7@github.com>

> This is root pull request with Classfile API implementation, tests and benchmarks initial drop into JDK.
> 
> Following pull requests consolidating JDK class files parsing, generating, and transforming ([JDK-8294957](https://bugs.openjdk.org/browse/JDK-8294957)) will chain to this one.
> 
> Classfile API development is tracked at:
> https://github.com/openjdk/jdk-sandbox/tree/classfile-api-branch
> 
> Development branch of consolidated JDK class files parsing, generating, and transforming is at:
> https://github.com/openjdk/jdk-sandbox/tree/classfile-api-dev-branch
> 
> Classfile API [JEP](https://bugs.openjdk.org/browse/JDK-8280389) and [online API documentation](https://htmlpreview.github.io/?https://raw.githubusercontent.com/openjdk/jdk-sandbox/classfile-api-javadoc-branch/doc/classfile-api/javadoc/java.base/jdk/internal/classfile/package-summary.html) is also available.
> 
> Please take you time to review this non-trivial JDK addition.
> 
> Thank you,
> Adam

Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:

  javadoc fixes

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10982/files
  - new: https://git.openjdk.org/jdk/pull/10982/files/1aabe0e3..df08b351

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10982&range=13
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10982&range=12-13

  Stats: 62 lines in 42 files changed: 11 ins; 1 del; 50 mod
  Patch: https://git.openjdk.org/jdk/pull/10982.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10982/head:pull/10982

PR: https://git.openjdk.org/jdk/pull/10982

From asotona at openjdk.org  Wed Feb  8 10:40:39 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Wed, 8 Feb 2023 10:40:39 GMT
Subject: RFR: 8294982: Implementation of Classfile API [v13]
In-Reply-To: <u6VmkXvghsyyf7qwyHyDpcqZ-wVCfFnZgOoB_wiz2-A=.ce2c44e1-81b0-4851-811c-5f4fd3fdda62@github.com>
References: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
 <Ej4u9wRtUuLS5LJhMkXwmown_MGuwR0gH9ruJ1A1g30=.f6405576-6655-4252-9135-ebc77765436e@github.com>
 <u6VmkXvghsyyf7qwyHyDpcqZ-wVCfFnZgOoB_wiz2-A=.ce2c44e1-81b0-4851-811c-5f4fd3fdda62@github.com>
Message-ID: <Yc73e5S4wD8hzguB0T7UQwGVEqofdiqguOlFAiSeBZE=.4e361b28-8a11-4dce-aa00-4e36d76802d8@github.com>

On Tue, 7 Feb 2023 15:59:04 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Adam Sotona has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - javadoc fixes
>>  - obsolete identifiers and unused imports cleanup
>>  - TypeAnnotation.TypePathComponent cleanup
>
> src/java.base/share/classes/jdk/internal/classfile/attribute/ModuleAttribute.java line 132:
> 
>> 130:     }
>> 131: 
>> 132:     static ModuleAttribute of(ModuleDesc moduleName,
> 
> Some missing javadoc in this class

Will fix it, thanks.

-------------

PR: https://git.openjdk.org/jdk/pull/10982

From redestad at openjdk.org  Wed Feb  8 10:44:12 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Wed, 8 Feb 2023 10:44:12 GMT
Subject: RFR: 8301958: Reduce Arrays.copyOf/-Range overheads [v8]
In-Reply-To: <2pdPoSHz2RJ7YDHOwOyszQMVv0v7FQFOwykfJ-za_e0=.cfe480da-a045-4b9a-bec7-7fffd0f47206@github.com>
References: <2pdPoSHz2RJ7YDHOwOyszQMVv0v7FQFOwykfJ-za_e0=.cfe480da-a045-4b9a-bec7-7fffd0f47206@github.com>
Message-ID: <WBMvCVZWPibvJp7wom55SrSn66h07Di48VJHlWLON_4=.e74133b2-e81e-46a6-876f-4ae112cd677e@github.com>

> This patch adds special-cases to `Arrays.copyOf` and `Arrays.copyOfRange` to clone arrays when `newLength` or range inputs span the input array. This helps eliminate range checks and has been verified to help various String operations. Example:
> 
> Baseline
> 
> Benchmark                                            (size)  Mode  Cnt   Score   Error  Units
> StringConstructor.newStringFromArray                      7  avgt   15  16.817 ? 0.369  ns/op
> StringConstructor.newStringFromArrayWithCharset           7  avgt   15  16.866 ? 0.449  ns/op
> StringConstructor.newStringFromArrayWithCharsetName       7  avgt   15  22.198 ? 0.396  ns/op
> 
> Patch: 
> 
> Benchmark                                            (size)  Mode  Cnt   Score   Error  Units
> StringConstructor.newStringFromArray                      7  avgt   15  14.666 ? 0.336  ns/op
> StringConstructor.newStringFromArrayWithCharset           7  avgt   15  14.582 ? 0.288  ns/op
> StringConstructor.newStringFromArrayWithCharsetName       7  avgt   15  20.339 ? 0.328  ns/op

Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:

  Err on the side of copyOf

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12453/files
  - new: https://git.openjdk.org/jdk/pull/12453/files/c906c730..85b50169

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12453&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12453&range=06-07

  Stats: 90 lines in 1 file changed: 56 ins; 23 del; 11 mod
  Patch: https://git.openjdk.org/jdk/pull/12453.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12453/head:pull/12453

PR: https://git.openjdk.org/jdk/pull/12453

From redestad at openjdk.org  Wed Feb  8 10:45:47 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Wed, 8 Feb 2023 10:45:47 GMT
Subject: RFR: 8301958: Reduce Arrays.copyOf/-Range overheads [v7]
In-Reply-To: <cEcoqLzuQ2goUGLKLd1HPqaJbPgpLIid7tWgv3HSQds=.c0a87a8c-3656-4a8e-b970-fe8298cd3ca2@github.com>
References: <2pdPoSHz2RJ7YDHOwOyszQMVv0v7FQFOwykfJ-za_e0=.cfe480da-a045-4b9a-bec7-7fffd0f47206@github.com>
 <n8n_xh_R8sORHd7q5kwEa0kRxoSgBvgaWe_qdliwFFw=.52872c7b-7cb6-4ea4-932f-5d4f57c515eb@github.com>
 <cEcoqLzuQ2goUGLKLd1HPqaJbPgpLIid7tWgv3HSQds=.c0a87a8c-3656-4a8e-b970-fe8298cd3ca2@github.com>
Message-ID: <3GZVAXD2hMxviZiSJEU4FdW03BpViN09Ze-zM5Zzp6o=.216c2906-5d1c-456e-91a8-30649564a53f@github.com>

On Wed, 8 Feb 2023 01:10:59 GMT, David Schlosnagle <duke at openjdk.org> wrote:

>> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Minimize, force inline, generalize
>
> src/java.base/share/classes/java/util/Arrays.java line 3594:
> 
>> 3592:     public static int[] copyOf(int[] original, int newLength) {
>> 3593:         if (newLength == original.length) {
>> 3594:             return original.clone();
> 
> I am curious about the use of `clone` for some primitive array types (`short[]`, `int[]`, `long[]`, `char[]`, `float[]`) and `copyOf` using `System.arraycopy` in other types (`byte[]`, `double[]`). Do these types optimize differently or hit different intrinsics depending on primitive type? Is there difference in array zeroing?
> 
> From a quick [JMH benchmark](https://gist.github.com/schlosna/975e26965ec822ad42034b3ea2b08676) `System.arraycopy` seems slightly better.

I went back and forth on this and also saw a small win using `arraycopy`, but the PR ended up in an inconsistent state with some using one and some using the other. While this discrepancy seem like something we should treat as a bug, I've arranged to use `copyOf` helper consistently for now.

-------------

PR: https://git.openjdk.org/jdk/pull/12453

From redestad at openjdk.org  Wed Feb  8 10:53:22 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Wed, 8 Feb 2023 10:53:22 GMT
Subject: RFR: 8301958: Reduce Arrays.copyOf/-Range overheads [v9]
In-Reply-To: <2pdPoSHz2RJ7YDHOwOyszQMVv0v7FQFOwykfJ-za_e0=.cfe480da-a045-4b9a-bec7-7fffd0f47206@github.com>
References: <2pdPoSHz2RJ7YDHOwOyszQMVv0v7FQFOwykfJ-za_e0=.cfe480da-a045-4b9a-bec7-7fffd0f47206@github.com>
Message-ID: <5cK3YK6OKgztMKSjd7gmp5ayTrlD9fzcsxTxjaJ1f40=.7b285e15-050e-4d2e-8479-e7b5b8cffcd9@github.com>

> This patch adds special-cases to `Arrays.copyOf` and `Arrays.copyOfRange` to clone arrays when `newLength` or range inputs span the input array. This helps eliminate range checks and has been verified to help various String operations. Example:
> 
> Baseline
> 
> Benchmark                                            (size)  Mode  Cnt   Score   Error  Units
> StringConstructor.newStringFromArray                      7  avgt   15  16.817 ? 0.369  ns/op
> StringConstructor.newStringFromArrayWithCharset           7  avgt   15  16.866 ? 0.449  ns/op
> StringConstructor.newStringFromArrayWithCharsetName       7  avgt   15  22.198 ? 0.396  ns/op
> 
> Patch: 
> 
> Benchmark                                            (size)  Mode  Cnt   Score   Error  Units
> StringConstructor.newStringFromArray                      7  avgt   15  14.666 ? 0.336  ns/op
> StringConstructor.newStringFromArrayWithCharset           7  avgt   15  14.582 ? 0.288  ns/op
> StringConstructor.newStringFromArrayWithCharsetName       7  avgt   15  20.339 ? 0.328  ns/op

Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:

  Add offset param to micro, reduce number of configurations and variants

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12453/files
  - new: https://git.openjdk.org/jdk/pull/12453/files/85b50169..350612d4

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12453&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12453&range=07-08

  Stats: 13 lines in 1 file changed: 6 ins; 4 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/12453.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12453/head:pull/12453

PR: https://git.openjdk.org/jdk/pull/12453

From redestad at openjdk.org  Wed Feb  8 10:53:22 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Wed, 8 Feb 2023 10:53:22 GMT
Subject: RFR: 8301958: Reduce Arrays.copyOf/-Range overheads [v7]
In-Reply-To: <TW-KNWkgAmEkbfbv8sKTukJ_3RsrqHcMaBNiyv7E6wY=.99f45046-eba2-481b-9a6e-e3302535d94a@github.com>
References: <2pdPoSHz2RJ7YDHOwOyszQMVv0v7FQFOwykfJ-za_e0=.cfe480da-a045-4b9a-bec7-7fffd0f47206@github.com>
 <n8n_xh_R8sORHd7q5kwEa0kRxoSgBvgaWe_qdliwFFw=.52872c7b-7cb6-4ea4-932f-5d4f57c515eb@github.com>
 <TW-KNWkgAmEkbfbv8sKTukJ_3RsrqHcMaBNiyv7E6wY=.99f45046-eba2-481b-9a6e-e3302535d94a@github.com>
Message-ID: <suQVHIpcZxC3NMx2WRaZ4mqwUNqyQSDFa4CRg5y9H8E=.065ebf54-1d4b-4239-90a2-19d7376f8b2a@github.com>

On Wed, 8 Feb 2023 03:38:24 GMT, David Schlosnagle <duke at openjdk.org> wrote:

>> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Minimize, force inline, generalize
>
> src/java.base/share/classes/java/util/Arrays.java line 4142:
> 
>> 4140:     private static double[] copyOfRangeGeneric(double[] original, int from, int to) {
>> 4141:         checkLength(from, to);
>> 4142:         int newLength = to - from;
> 
> Suggestion:
> 
>         int newLength = checkLength(from, to);

> I'm also curious if returning the new length from `checkLength` would be worthwhile

I had this arrangement earlier but saw no win from it. These helper methods will be aggressively inlined and the JIT sorts it out optimally, so I prefer to keep the `check` method zoomed in on its purpose

-------------

PR: https://git.openjdk.org/jdk/pull/12453

From redestad at openjdk.org  Wed Feb  8 10:53:23 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Wed, 8 Feb 2023 10:53:23 GMT
Subject: RFR: 8301958: Reduce Arrays.copyOf/-Range overheads [v7]
In-Reply-To: <4cuay6Q7tha4k6shmgdxHJf4f5MlsTqSZeq29w8MzP4=.310f087e-e09d-4a09-b9ae-afdf2d1f273c@github.com>
References: <2pdPoSHz2RJ7YDHOwOyszQMVv0v7FQFOwykfJ-za_e0=.cfe480da-a045-4b9a-bec7-7fffd0f47206@github.com>
 <n8n_xh_R8sORHd7q5kwEa0kRxoSgBvgaWe_qdliwFFw=.52872c7b-7cb6-4ea4-932f-5d4f57c515eb@github.com>
 <4cuay6Q7tha4k6shmgdxHJf4f5MlsTqSZeq29w8MzP4=.310f087e-e09d-4a09-b9ae-afdf2d1f273c@github.com>
Message-ID: <rZ4yYUWrY-t8MdDZ0JKEdgBebrj6GhLmt2immoZFgIs=.a50e08da-db84-4d9e-b521-d9a3814c2025@github.com>

On Wed, 8 Feb 2023 08:16:05 GMT, Francesco Nigro <duke at openjdk.org> wrote:

>> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Minimize, force inline, generalize
>
> test/micro/org/openjdk/bench/java/lang/StringConstructor.java line 40:
> 
>> 38: 
>> 39:   @Param({"0", "7", "64"})
>> 40:   public int size;
> 
> I suggest to add the param `offset` for future experiment: together with `perfasm` it helps to check how different stubs are used and emulate the different branches of the optimized code

Done

-------------

PR: https://git.openjdk.org/jdk/pull/12453

From asotona at openjdk.org  Wed Feb  8 11:03:01 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Wed, 8 Feb 2023 11:03:01 GMT
Subject: RFR: 8294982: Implementation of Classfile API [v13]
In-Reply-To: <u6VmkXvghsyyf7qwyHyDpcqZ-wVCfFnZgOoB_wiz2-A=.ce2c44e1-81b0-4851-811c-5f4fd3fdda62@github.com>
References: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
 <Ej4u9wRtUuLS5LJhMkXwmown_MGuwR0gH9ruJ1A1g30=.f6405576-6655-4252-9135-ebc77765436e@github.com>
 <u6VmkXvghsyyf7qwyHyDpcqZ-wVCfFnZgOoB_wiz2-A=.ce2c44e1-81b0-4851-811c-5f4fd3fdda62@github.com>
Message-ID: <p6l3I5tXbZ_TXPOqxMZatAOfGzzO3ym2zxFafKkKVDM=.dbf87106-bd11-4cc3-8ca9-9e6b8def0f6a@github.com>

On Tue, 7 Feb 2023 16:09:56 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Adam Sotona has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - javadoc fixes
>>  - obsolete identifiers and unused imports cleanup
>>  - TypeAnnotation.TypePathComponent cleanup
>
> src/java.base/share/classes/jdk/internal/classfile/attribute/StackMapTableAttribute.java line 68:
> 
>> 66:      * A simple stack value.
>> 67:      */
>> 68:     public enum SimpleVerificationTypeInfo implements VerificationTypeInfo {
> 
> I note that in this class we have made the decision to model all the innards (XYZInfo) as nested classes - while in all the other cases XYZInfo are toplevel types. Moving forward, we should pick something consistent.

Every case has been considered individually, evaluated on use cases and pros and cons have been weighted. Unified approach across the whole API would be nice, however not so simple and not the highest priority.

-------------

PR: https://git.openjdk.org/jdk/pull/10982

From dholmes at openjdk.org  Wed Feb  8 11:06:44 2023
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 8 Feb 2023 11:06:44 GMT
Subject: RFR: 8300139 : [AIX] Use pthreads to avoid JNI_createVM call from
 primordial thread
In-Reply-To: <qbwPBNdxzk4QmB9L6y2t-X6uYgAaPjzAEwYfs_5XV_0=.4ea982e6-30da-4219-b8ad-fa36690170b8@github.com>
References: <qbwPBNdxzk4QmB9L6y2t-X6uYgAaPjzAEwYfs_5XV_0=.4ea982e6-30da-4219-b8ad-fa36690170b8@github.com>
Message-ID: <RAb0nAe-w8ZiTSMnD-kcuaUrPRVqjZ4_LcQVFvgjMCE=.ece15779-afed-4cc2-a7bc-87b548d50f85@github.com>

On Tue, 31 Jan 2023 05:24:35 GMT, Varada M <duke at openjdk.org> wrote:

> 1. test/jdk/jni/nullCaller/NullCallerTest.java
> 2. test/jdk/java/lang/reflect/exeCallerAccessTest/CallerAccessTest.java
> 3. test/hotspot/jtreg/runtime/jni/CalleeSavedRegisters/FPRegs.java 
> 
>     The above tests were blocked on AIX [@require os.family != "aix"] because these tests are failing to call JNI_CreateJavaVM. This is solved by implementing JNI_CreateJavaVM call via POSIX threads. 
>    Similarly there are tests which are not blocked and still failing to call JNI_CreateJavaVM on AIX :
> 
> 4. test/hotspot/jtreg/runtime/jni/daemonDestroy/TestDaemonDestroy.java { PR : [12006](https://github.com/openjdk/jdk/pull/12006) }
> 5. test/lib-test/jdk/test/lib/process/TestNativeProcessBuilder.java 
> 
> The reported issue : [8300139](https://bugs.openjdk.org/browse/JDK-8300139l)

I hate to see the code duplication, but we don't have a sharing mechanism for the native parts of tests so that can't be helped.

Changes look good.

Please update the Oracle copyright lines so that the second year is 2023 if needed. Thanks.

-------------

Marked as reviewed by dholmes (Reviewer).

PR: https://git.openjdk.org/jdk/pull/12302

From mcimadamore at openjdk.org  Wed Feb  8 11:09:53 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 8 Feb 2023 11:09:53 GMT
Subject: RFR: 8294982: Implementation of Classfile API [v12]
In-Reply-To: <wxsAcKZwigc4sIUexg5m-6UlOg8ZHflccTs47FJCgdQ=.5613b95e-96b0-4ced-a587-ccca3f80595d@github.com>
References: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
 <Q4VeZ2yWAg85FqUDJa5hYq3jHty5H547gD0H-x3oIq0=.58d463a4-237a-4fee-bd0f-83262d49522a@github.com>
 <c022hrWNEHW76nhP_sXTQXCTjtL8jjM8r_yYv0IvbPI=.2a9cfbae-2fef-4cdb-8189-b869b1513fef@github.com>
 <FbFekphAbS5DQzn6B-uUHkX-2EF8Aq4NcijjMdlxAM0=.280a7529-4008-4539-9137-da7600e13eee@github.com>
 <kxds1bmvZ8TbtVK5iDx_hZtrqN3uywsa6GqumJ7RubE=.ffd151e4-a1ba-4018-914c-518fd122dd4f@github.com>
 <WxjOq5CRJ9OtviOIxDKH9C78bScpiGmkiBqVXLDddzU=.a5a85537-43e8-4cf4-b747-86b945999d71@github.com>
 <84RlLSIsacJTJVM-esvzoXnQ5rDEByog5b1ibFRJOE8=.05e8e7a7-2185-4e1c-b5b9-59ce3b3eea03@github.com>
 <sQwAa41mu1z226uzYIA2_v0tN8un257MDgc-WPO8SFY=.486c845c-5012-4291-bcd7-c7b0247e02dd@github.com>
 <wxsAcKZwigc4sIUexg5m-6UlOg8ZHflccTs47FJCgdQ=.5613b95e-96b0-4ced-a587-ccca3f80595d@github.com>
Message-ID: <_jsw8D5-esoFp7fGSZECKF8ccwrfikwjIprRrVdCOjo=.2d8cd9f6-9c6a-4726-bc90-a4c163e8dd67@github.com>

On Wed, 8 Feb 2023 07:24:05 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> **Specification:**
>> 
>> MethodSignature:
>> [TypeParameters] ( {JavaTypeSignature} ) Result {ThrowsSignature}
>> 
>> Result:
>> JavaTypeSignature 
>> VoidDescriptor
>> 
>> ThrowsSignature:
>> ^ ClassTypeSignature 
>> ^ TypeVariableSignature
>> 
>> 
>> 
>> **Reflect in API mapping:**
>> 
>>     public sealed interface ClassTypeSig
>>             extends RefTypeSig, ThrowableSig
>> 
>> and
>> 
>>     public sealed interface TypeVarSig
>>             extends RefTypeSig, ThrowableSig
>> 
>> and
>> 
>>     /**
>>      * @return method signature
>>      * @param typeParameters signatures for the type parameters
>>      * @param exceptions sigantures for the exceptions
>>      * @param result signature for the return type
>>      * @param arguments signatures for the method arguments
>>      */
>>     public static MethodSignature of(List<Signature.TypeParam> typeParameters,
>>                                      List<Signature.ThrowableSig> exceptions,
>>                                      Signature result,
>>                                      Signature... arguments) {
>> 
>> 
>> `Signature.ThrowableSig` is a `Signature` and it is a common super of `ClassTypeSig` and `TypeVarSig`.
>
> `TypeParam` is not a signature, because it simply is not a signature.
> Per spec:
> 
> TypeParameter:
> Identifier ClassBound {InterfaceBound}

> `Signature.ThrowableSig` is a `Signature` and it is a common super of `ClassTypeSig` and `TypeVarSig`.

I really don't follow here. ThrowableSig is a piece of a method signature, which starts with "^" and is followed by either a class or a typevar signature. You can never encounter it from the toplevel JavaTypeSignature production. It's ok (as I have said) to have a ThrowableSig element in the API to model the production, but that element should not be a subtype of Signature (at least not if Signature, as you claimed is meant to model the JavaTypeSignature production). That is, there's no "is a" relationship between JavaTypeSignature and ThrowableSig (at least not that I can see when looking at the productions).

-------------

PR: https://git.openjdk.org/jdk/pull/10982

From asotona at openjdk.org  Wed Feb  8 11:09:56 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Wed, 8 Feb 2023 11:09:56 GMT
Subject: RFR: 8294982: Implementation of Classfile API [v13]
In-Reply-To: <u6VmkXvghsyyf7qwyHyDpcqZ-wVCfFnZgOoB_wiz2-A=.ce2c44e1-81b0-4851-811c-5f4fd3fdda62@github.com>
References: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
 <Ej4u9wRtUuLS5LJhMkXwmown_MGuwR0gH9ruJ1A1g30=.f6405576-6655-4252-9135-ebc77765436e@github.com>
 <u6VmkXvghsyyf7qwyHyDpcqZ-wVCfFnZgOoB_wiz2-A=.ce2c44e1-81b0-4851-811c-5f4fd3fdda62@github.com>
Message-ID: <ubqEqa6BH65hdOBcovhGQACL7JtzTepvG57XeC7z0K4=.045606e5-9421-4d8f-8e7f-e6bd9f529e98@github.com>

On Tue, 7 Feb 2023 16:07:00 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Adam Sotona has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - javadoc fixes
>>  - obsolete identifiers and unused imports cleanup
>>  - TypeAnnotation.TypePathComponent cleanup
>
> src/java.base/share/classes/jdk/internal/classfile/attribute/NestMembersAttribute.java line 72:
> 
>> 70:      * @param nestMembers the member classes of the nest
>> 71:      */
>> 72:     static NestMembersAttribute ofSymbols(List<ClassDesc> nestMembers) {
> 
> I see that in some classes we use the `Symbols` prefix, in others we just use `of` - we should try to make the more consistent (in the future).

`ofSymbols` is an alternative to `of` when conflicting method parameters.
In such case `of` refers to CP entries and `ofSymbols` refer to independent symbols describing the objects, like for example `ClassDesc`, `MethodTypeDesc`, `PackageDesc`

-------------

PR: https://git.openjdk.org/jdk/pull/10982

From mcimadamore at openjdk.org  Wed Feb  8 11:18:52 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 8 Feb 2023 11:18:52 GMT
Subject: RFR: 8294982: Implementation of Classfile API [v13]
In-Reply-To: <ubqEqa6BH65hdOBcovhGQACL7JtzTepvG57XeC7z0K4=.045606e5-9421-4d8f-8e7f-e6bd9f529e98@github.com>
References: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
 <Ej4u9wRtUuLS5LJhMkXwmown_MGuwR0gH9ruJ1A1g30=.f6405576-6655-4252-9135-ebc77765436e@github.com>
 <u6VmkXvghsyyf7qwyHyDpcqZ-wVCfFnZgOoB_wiz2-A=.ce2c44e1-81b0-4851-811c-5f4fd3fdda62@github.com>
 <ubqEqa6BH65hdOBcovhGQACL7JtzTepvG57XeC7z0K4=.045606e5-9421-4d8f-8e7f-e6bd9f529e98@github.com>
Message-ID: <Jk3w1_xkaBE7C1tt8-1rH4svfdjuyIM3OsJDGQl9Pi4=.e93ed59e-c4a9-4566-aac2-79879bc66241@github.com>

On Wed, 8 Feb 2023 11:05:34 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> `ofSymbols` is an alternative to `of` when conflicting method parameters. In such case `of` refers to CP entries and `ofSymbols` refer to independent symbols describing the objects, like for example `ClassDesc`, `MethodTypeDesc`, `PackageDesc`

Yes, I was noting that some classes e.g. ModuleProvideInfo do not seem to follow this logic:


static ModuleProvideInfo of(ClassEntry provides, ClassEntry... providesWith) { ... }

static ModuleProvideInfo of(ClassDesc provides, List<ClassDesc> providesWith) { ... }

-------------

PR: https://git.openjdk.org/jdk/pull/10982

From mcimadamore at openjdk.org  Wed Feb  8 11:22:55 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 8 Feb 2023 11:22:55 GMT
Subject: RFR: 8294982: Implementation of Classfile API [v13]
In-Reply-To: <XmkS1CfKIATrXGdgIqZNmfY4LI3R3wBuTj903AkwkR0=.3787d0f1-f617-426d-95ae-ac736abc43ed@github.com>
References: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
 <Ej4u9wRtUuLS5LJhMkXwmown_MGuwR0gH9ruJ1A1g30=.f6405576-6655-4252-9135-ebc77765436e@github.com>
 <u6VmkXvghsyyf7qwyHyDpcqZ-wVCfFnZgOoB_wiz2-A=.ce2c44e1-81b0-4851-811c-5f4fd3fdda62@github.com>
 <XmkS1CfKIATrXGdgIqZNmfY4LI3R3wBuTj903AkwkR0=.3787d0f1-f617-426d-95ae-ac736abc43ed@github.com>
Message-ID: <Sxvu5MMpl41oP_h0CwnQ5y6H1zVyB9JRx3Qiq502Jfg=.6c7d2e51-5361-4d4e-98a0-769bd4c5b548@github.com>

On Wed, 8 Feb 2023 07:31:15 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> Any reference to an official specification of CharacterRangeInfo is appreciated. Thanks.

There's this - which points back to javac code :-)

https://github.com/jacoco/jacoco/wiki/CharacterRangeTable

-------------

PR: https://git.openjdk.org/jdk/pull/10982

From alanb at openjdk.org  Wed Feb  8 11:28:44 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 8 Feb 2023 11:28:44 GMT
Subject: RFR: 8301767: Convert virtual thread tests to JUnit [v2]
In-Reply-To: <pRk9Bm5maTzevQy3-dF5KCc55GkwxBFSJW5MEELi8fg=.500f3452-e14e-49ce-845e-16ce5214afc4@github.com>
References: <37UDjOGF9PZxUiP2BwkrfIKh82vQgdvA8pwxaln4pl8=.5f368aea-d8a2-4e4a-a6ae-4376e1f05c9b@github.com>
 <uVH-roGm09SLtu0SV6K_oadsB_NpmPw2V7DtLEu1qUY=.9963cf59-e7ea-498e-8f5d-47dc8fa95440@github.com>
 <pRk9Bm5maTzevQy3-dF5KCc55GkwxBFSJW5MEELi8fg=.500f3452-e14e-49ce-845e-16ce5214afc4@github.com>
Message-ID: <pIrSEwmja8aPlCL2-KA9Ls0HEH9MAgrYCB7LU1HxQeQ=.c9dd145e-7df0-425d-902e-4f3922c84bd3@github.com>

On Wed, 8 Feb 2023 10:37:16 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits:
>> 
>>  - Merge
>>  - Merge
>>  - Fix typos in comments
>>  - GetStackTrace.java test missing @requires vm.continuations
>>  - Initial commit
>
> test/jdk/jdk/internal/misc/ThreadFlock/WithScopedValue.java line 48:
> 
>> 46: 
>> 47:     private static Stream<ThreadFactory> factories() {
>> 48:         return Stream.of(Thread.ofPlatform().factory(), Thread.ofVirtual().factory());
> 
> Previously, before this change, the data provided to the test methods, comprised of a virtual ThreadFactory and a `Executors.defaultThreadFactory()`. Is this switch to using a `Thread.ofPlatform().factory()` OK in the context of this test?

The tests run with both platform and virtual threads, it doesn't matter if the ThreadFactory for platform threads is Thread.ofPlatform().factory() or Executors.defaultThreadFactory(). It is changed to be former so it's consistent with the other tests.

-------------

PR: https://git.openjdk.org/jdk/pull/12426

From duke at openjdk.org  Wed Feb  8 11:34:43 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Wed, 8 Feb 2023 11:34:43 GMT
Subject: RFR: 8301873: Avoid string decoding in ZipFile.Source.getEntryPos
 [v4]
In-Reply-To: <gfoFEViv2qZrDUuwbVWROrXkrVMoopJgIg0kdwm1kKg=.be54ea9c-b144-457c-8cb6-021be0ea8d75@github.com>
References: <FkmdspiHVjkAKFqm5kUgwaf55YH5cBbczS_3krqsdFs=.05eca901-f55f-47d9-b1bc-0cf2f5b87536@github.com>
 <QHObV5Qz9Ygw1cjIooMNFMcXEYlwXUrqpmzvzXeR9-A=.4282ffa4-e17c-4b98-be2f-6b01f8be214d@github.com>
 <gfoFEViv2qZrDUuwbVWROrXkrVMoopJgIg0kdwm1kKg=.be54ea9c-b144-457c-8cb6-021be0ea8d75@github.com>
Message-ID: <1bNNT76Wj-D4ogHSdNP_Wfamn_qcxptfYiStzfNNr5o=.e8231906-8eae-4d81-92c8-efa9ac20c517@github.com>

On Tue, 7 Feb 2023 22:52:13 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> Seems there's a possible real test failure lurking here, might be intermittent since it only showed on one platform:

Did you get this from GHA somehow? Do you happen to know the platform, timezone and encoding used?

-------------

PR: https://git.openjdk.org/jdk/pull/12290

From duke at openjdk.org  Wed Feb  8 11:35:44 2023
From: duke at openjdk.org (Varada M)
Date: Wed, 8 Feb 2023 11:35:44 GMT
Subject: RFR: 8300139 : [AIX] Use pthreads to avoid JNI_createVM call from
 primordial thread
In-Reply-To: <RAb0nAe-w8ZiTSMnD-kcuaUrPRVqjZ4_LcQVFvgjMCE=.ece15779-afed-4cc2-a7bc-87b548d50f85@github.com>
References: <qbwPBNdxzk4QmB9L6y2t-X6uYgAaPjzAEwYfs_5XV_0=.4ea982e6-30da-4219-b8ad-fa36690170b8@github.com>
 <RAb0nAe-w8ZiTSMnD-kcuaUrPRVqjZ4_LcQVFvgjMCE=.ece15779-afed-4cc2-a7bc-87b548d50f85@github.com>
Message-ID: <p3nx-DOcntTDgseXl1JaDF4795CS0xi_UlcisJGlfug=.04ac3f4c-fa58-44bf-ab01-e2ea82a94a1a@github.com>

On Wed, 8 Feb 2023 11:03:35 GMT, David Holmes <dholmes at openjdk.org> wrote:

> I hate to see the code duplication, but we don't have a sharing mechanism for the native parts of tests so that can't be helped.
> 
> Changes look good.
> 
> Please update the Oracle copyright lines so that the second year is 2023 if needed. Thanks.

Thanks @dholmes-ora . I will update Oracle copyright lines.

-------------

PR: https://git.openjdk.org/jdk/pull/12302

From alanb at openjdk.org  Wed Feb  8 11:39:49 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 8 Feb 2023 11:39:49 GMT
Subject: RFR: 8300139 : [AIX] Use pthreads to avoid JNI_createVM call from
 primordial thread
In-Reply-To: <qbwPBNdxzk4QmB9L6y2t-X6uYgAaPjzAEwYfs_5XV_0=.4ea982e6-30da-4219-b8ad-fa36690170b8@github.com>
References: <qbwPBNdxzk4QmB9L6y2t-X6uYgAaPjzAEwYfs_5XV_0=.4ea982e6-30da-4219-b8ad-fa36690170b8@github.com>
Message-ID: <idmR3T0nXkqVauxHs304f7CwlE2N41UGWVkLIKOE2Cg=.274ef41c-6414-4bfa-9bf8-a1bb7c9aa414@github.com>

On Tue, 31 Jan 2023 05:24:35 GMT, Varada M <duke at openjdk.org> wrote:

> 1. test/jdk/jni/nullCaller/NullCallerTest.java
> 2. test/jdk/java/lang/reflect/exeCallerAccessTest/CallerAccessTest.java
> 3. test/hotspot/jtreg/runtime/jni/CalleeSavedRegisters/FPRegs.java 
> 
>     The above tests were blocked on AIX [@require os.family != "aix"] because these tests are failing to call JNI_CreateJavaVM. This is solved by implementing JNI_CreateJavaVM call via POSIX threads. 
>    Similarly there are tests which are not blocked and still failing to call JNI_CreateJavaVM on AIX :
> 
> 4. test/hotspot/jtreg/runtime/jni/daemonDestroy/TestDaemonDestroy.java { PR : [12006](https://github.com/openjdk/jdk/pull/12006) }
> 5. test/lib-test/jdk/test/lib/process/TestNativeProcessBuilder.java 
> 
> The reported issue : [8300139](https://bugs.openjdk.org/browse/JDK-8300139l)

test/jdk/jni/nullCaller/exeNullCallerTest.cpp line 206:

> 204: #else
> 205:    run(&argv);
> 206: #endif //AIX

The tests in test/jdk use 4 space indent rather than 2. Otherwise the changes to these tests look okay, just a bit annoying to have the same #ifdef AIX ... #endif code copied into each test.

-------------

PR: https://git.openjdk.org/jdk/pull/12302

From jpai at openjdk.org  Wed Feb  8 11:53:43 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 8 Feb 2023 11:53:43 GMT
Subject: RFR: 8301767: Convert virtual thread tests to JUnit [v2]
In-Reply-To: <3L-yZYrXApfYMYtQ5uBGVyrD9O5ExrY2MsgrG6pbEMQ=.d0e9d875-4e9e-46a7-8a90-9f15b6448d17@github.com>
References: <37UDjOGF9PZxUiP2BwkrfIKh82vQgdvA8pwxaln4pl8=.5f368aea-d8a2-4e4a-a6ae-4376e1f05c9b@github.com>
 <uVH-roGm09SLtu0SV6K_oadsB_NpmPw2V7DtLEu1qUY=.9963cf59-e7ea-498e-8f5d-47dc8fa95440@github.com>
 <L60W-QEFW8rqFe7wDJgs5chNinnVgkCkjXH0DK4WH34=.4de50ddb-b11d-422e-bc96-a6fc0e00dd17@github.com>
 <X2T458nbl6j97CLOuAUc8sytIPfAjVkjZWYTxEK-H1w=.b2cc8410-2245-4f6e-9dcf-5ebe6febeede@github.com>
 <3L-yZYrXApfYMYtQ5uBGVyrD9O5ExrY2MsgrG6pbEMQ=.d0e9d875-4e9e-46a7-8a90-9f15b6448d17@github.com>
Message-ID: <XydoShVXrynsAMVfzSD-ZsQ7gujMO3g_XeDrFx1YxYQ=.30cdf3cd-e1be-4f3c-b155-8f6244779619@github.com>

On Wed, 8 Feb 2023 09:47:00 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> as the alternative implementation of virtual threads (used on x86_32 and a few other ports) don't allow custom schedulers.

Thank you for that detail.

-------------

PR: https://git.openjdk.org/jdk/pull/12426

From redestad at openjdk.org  Wed Feb  8 11:59:42 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Wed, 8 Feb 2023 11:59:42 GMT
Subject: RFR: 8301873: Avoid string decoding in ZipFile.Source.getEntryPos
 [v4]
In-Reply-To: <1bNNT76Wj-D4ogHSdNP_Wfamn_qcxptfYiStzfNNr5o=.e8231906-8eae-4d81-92c8-efa9ac20c517@github.com>
References: <FkmdspiHVjkAKFqm5kUgwaf55YH5cBbczS_3krqsdFs=.05eca901-f55f-47d9-b1bc-0cf2f5b87536@github.com>
 <QHObV5Qz9Ygw1cjIooMNFMcXEYlwXUrqpmzvzXeR9-A=.4282ffa4-e17c-4b98-be2f-6b01f8be214d@github.com>
 <gfoFEViv2qZrDUuwbVWROrXkrVMoopJgIg0kdwm1kKg=.be54ea9c-b144-457c-8cb6-021be0ea8d75@github.com>
 <1bNNT76Wj-D4ogHSdNP_Wfamn_qcxptfYiStzfNNr5o=.e8231906-8eae-4d81-92c8-efa9ac20c517@github.com>
Message-ID: <UBRlcezmIHLqIp6apGRLppHVfWvJf-kUarTYAsMOJcQ=.498910d2-9dc8-4eae-bdef-c8cf348bacda@github.com>

On Wed, 8 Feb 2023 11:32:02 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

> > Seems there's a possible real test failure lurking here, might be intermittent since it only showed on one platform:
> 
> Did you get this from GHA somehow? Do you happen to know the platform, timezone and encoding used?

Yes, clicked through the failing macosx-x64 test suite. Here's a link to the summary which has the failing test logs at the bottom: https://github.com/eirbjo/jdk/actions/runs/4114300244

-------------

PR: https://git.openjdk.org/jdk/pull/12290

From redestad at openjdk.org  Wed Feb  8 12:05:44 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Wed, 8 Feb 2023 12:05:44 GMT
Subject: RFR: 8301873: Avoid string decoding in ZipFile.Source.getEntryPos
 [v4]
In-Reply-To: <UBRlcezmIHLqIp6apGRLppHVfWvJf-kUarTYAsMOJcQ=.498910d2-9dc8-4eae-bdef-c8cf348bacda@github.com>
References: <FkmdspiHVjkAKFqm5kUgwaf55YH5cBbczS_3krqsdFs=.05eca901-f55f-47d9-b1bc-0cf2f5b87536@github.com>
 <QHObV5Qz9Ygw1cjIooMNFMcXEYlwXUrqpmzvzXeR9-A=.4282ffa4-e17c-4b98-be2f-6b01f8be214d@github.com>
 <gfoFEViv2qZrDUuwbVWROrXkrVMoopJgIg0kdwm1kKg=.be54ea9c-b144-457c-8cb6-021be0ea8d75@github.com>
 <1bNNT76Wj-D4ogHSdNP_Wfamn_qcxptfYiStzfNNr5o=.e8231906-8eae-4d81-92c8-efa9ac20c517@github.com>
 <UBRlcezmIHLqIp6apGRLppHVfWvJf-kUarTYAsMOJcQ=.498910d2-9dc8-4eae-bdef-c8cf348bacda@github.com>
Message-ID: <OaXd_OHymxHMJa-S72I90bx7zoDmrtkAFse9pp8I9z4=.cad478f4-41b6-41de-adcb-88b04235170e@github.com>

On Wed, 8 Feb 2023 11:57:16 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> > > Seems there's a possible real test failure lurking here, might be intermittent since it only showed on one platform:
> > 
> > 
> > Did you get this from GHA somehow? Do you happen to know the platform, timezone and encoding used?
> 
> Yes, clicked through the failing macosx-x64 test suite. Here's a link to the summary which has the failing test logs at the bottom: https://github.com/eirbjo/jdk/actions/runs/4114300244

Seems the failing assert is checking timestamps:

assertEquals((x.getTime() / 2000), y.getTime() / 2000);

... so maybe this is a rare intermittent issue. It's just very suspect though that it happens in the test you're changing.

-------------

PR: https://git.openjdk.org/jdk/pull/12290

From asotona at openjdk.org  Wed Feb  8 12:22:54 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Wed, 8 Feb 2023 12:22:54 GMT
Subject: RFR: 8294982: Implementation of Classfile API [v12]
In-Reply-To: <_jsw8D5-esoFp7fGSZECKF8ccwrfikwjIprRrVdCOjo=.2d8cd9f6-9c6a-4726-bc90-a4c163e8dd67@github.com>
References: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
 <Q4VeZ2yWAg85FqUDJa5hYq3jHty5H547gD0H-x3oIq0=.58d463a4-237a-4fee-bd0f-83262d49522a@github.com>
 <c022hrWNEHW76nhP_sXTQXCTjtL8jjM8r_yYv0IvbPI=.2a9cfbae-2fef-4cdb-8189-b869b1513fef@github.com>
 <FbFekphAbS5DQzn6B-uUHkX-2EF8Aq4NcijjMdlxAM0=.280a7529-4008-4539-9137-da7600e13eee@github.com>
 <kxds1bmvZ8TbtVK5iDx_hZtrqN3uywsa6GqumJ7RubE=.ffd151e4-a1ba-4018-914c-518fd122dd4f@github.com>
 <WxjOq5CRJ9OtviOIxDKH9C78bScpiGmkiBqVXLDddzU=.a5a85537-43e8-4cf4-b747-86b945999d71@github.com>
 <84RlLSIsacJTJVM-esvzoXnQ5rDEByog5b1ibFRJOE8=.05e8e7a7-2185-4e1c-b5b9-59ce3b3eea03@github.com>
 <sQwAa41mu1z226uzYIA2_v0tN8un257MDgc-WPO8SFY=.486c845c-5012-4291-bcd7-c7b0247e02dd@github.com>
 <wxsAcKZwigc4sIUexg5m-6UlOg8ZHflccTs47FJCgdQ=.5613b95e-96b0-4ced-a587-ccca3f80595d@github.com>
 <_jsw8D5-esoFp7fGSZECKF8ccwrfikwjIprRrVdCOjo=.2d8cd9f6-9c6a-4726-bc90-a4c163e8dd67@github.com>
Message-ID: <LICxfIJ0QVmRRY4NJPCW_Rp4o3qhyaMrrgWLV-S9jHI=.4f6b40d5-d25d-4035-8fa5-186b2c735606@github.com>

On Wed, 8 Feb 2023 11:07:08 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> `TypeParam` is not a signature, because it simply is not a signature.
>> Per spec:
>> 
>> TypeParameter:
>> Identifier ClassBound {InterfaceBound}
>
>> `Signature.ThrowableSig` is a `Signature` and it is a common super of `ClassTypeSig` and `TypeVarSig`.
> 
> I really don't follow here. ThrowableSig is a piece of a method signature, which starts with "^" and is followed by either a class or a typevar signature. You can never encounter it from the toplevel JavaTypeSignature production. It's ok (as I have said) to have a ThrowableSig element in the API to model the production, but that element should not be a subtype of Signature (at least not if Signature, as you claimed is meant to model the JavaTypeSignature production). That is, there's no "is a" relationship between JavaTypeSignature and ThrowableSig (at least not that I can see when looking at the productions).

OK, I see your point now, I'll fix it.
Thanks

-------------

PR: https://git.openjdk.org/jdk/pull/10982

From alanb at openjdk.org  Wed Feb  8 12:25:30 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 8 Feb 2023 12:25:30 GMT
Subject: RFR: 8301767: Convert virtual thread tests to JUnit [v4]
In-Reply-To: <37UDjOGF9PZxUiP2BwkrfIKh82vQgdvA8pwxaln4pl8=.5f368aea-d8a2-4e4a-a6ae-4376e1f05c9b@github.com>
References: <37UDjOGF9PZxUiP2BwkrfIKh82vQgdvA8pwxaln4pl8=.5f368aea-d8a2-4e4a-a6ae-4376e1f05c9b@github.com>
Message-ID: <aK7UhZmA39CX1XvdwYBpzknTtICsI_m7RGq6p6pBBdA=.be56bf29-bfb3-496c-a1da-50db5c895781@github.com>

> The non-hotspot tests integrated with JEP 425/428 were mostly TestNG tests. We'd like to convert these JUnit in the main line in advance of other updates to these tests in 21.  The changes are mostly mechanical and trivial:
> 
> - BeforeClass/AfterClass changed to static BeforeAll/AfterAll methods
> - Tests using data providers are changed to parameterized tests
> - The order of the parameters to assertEquals are swapped so that the expected result is the first parameter
> - Usages of expectThrows are changed to assertThrows
> - Tests that threw SkipException are changed to the Assumptions API
> 
> There are a small number of drive-by changes to the tests, nothing significant, e.g.
> 
> - GetStackTrace and ParkWithFixedThreadPool changed from "@run testng" to "@run main" as they aren't TestNG tests.
> - A few of the tests in StructuredTaskScopeTest for joinXXX are changed to use a CountDownLatch rather than sleeping, as the original tests weren't very robust.

Alan Bateman has updated the pull request incrementally with one additional commit since the last revision:

  Replace assertTrue(x == null) with assertNull(x)

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12426/files
  - new: https://git.openjdk.org/jdk/pull/12426/files/75176342..86af1887

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12426&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12426&range=02-03

  Stats: 47 lines in 6 files changed: 1 ins; 0 del; 46 mod
  Patch: https://git.openjdk.org/jdk/pull/12426.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12426/head:pull/12426

PR: https://git.openjdk.org/jdk/pull/12426

From dfuchs at openjdk.org  Wed Feb  8 12:25:42 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 8 Feb 2023 12:25:42 GMT
Subject: RFR: JDK-8301462: Convert Permission files to use lambda after
 JDK-8076596 [v2]
In-Reply-To: <pJX2oOarrhU6mm0oJY5pH7avyZlRmVnGQSulKKFA1dM=.fe116030-80ed-4b7f-9ed4-33dd04f2d4ab@github.com>
References: <HVWMALUhjljFTe0W9OlvK7CfpFgg4z3Um8V6ChTHA18=.cf1fb1d5-3594-4e97-beb6-144b6a726bf0@github.com>
 <pJX2oOarrhU6mm0oJY5pH7avyZlRmVnGQSulKKFA1dM=.fe116030-80ed-4b7f-9ed4-33dd04f2d4ab@github.com>
Message-ID: <zhgiz3QEdWcIY2Al969OS46ybPVs0wS8J5b_AXvD9Eg=.93acd381-bfac-4682-8dea-fcde4adad204@github.com>

On Wed, 8 Feb 2023 03:42:16 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> A trivial fix.   Convert the use of anonymous inner classes in a few Permission classes to lambdas to work around JDK-8076596, which has been resolved.
>
> Mandy Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update copyright end year

LGTM. I can't help noticing that the code for SocketPermission, PropertyPermission, and ServicePermission is almost identical. But there's not much we could do factorize that easily since the lambda requires access to private static method accessors: trying to factorize would probably add to the complexity instead of reducing it and impair readability.

-------------

Marked as reviewed by dfuchs (Reviewer).

PR: https://git.openjdk.org/jdk/pull/12463

From alanb at openjdk.org  Wed Feb  8 12:25:37 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 8 Feb 2023 12:25:37 GMT
Subject: RFR: 8301767: Convert virtual thread tests to JUnit [v2]
In-Reply-To: <Elipcpaj2eeNZPXIpFI1r4spLHR1fWUb8F7OHxKfyhQ=.028ac978-837c-432c-aac4-7435e87ecfdd@github.com>
References: <37UDjOGF9PZxUiP2BwkrfIKh82vQgdvA8pwxaln4pl8=.5f368aea-d8a2-4e4a-a6ae-4376e1f05c9b@github.com>
 <uVH-roGm09SLtu0SV6K_oadsB_NpmPw2V7DtLEu1qUY=.9963cf59-e7ea-498e-8f5d-47dc8fa95440@github.com>
 <Elipcpaj2eeNZPXIpFI1r4spLHR1fWUb8F7OHxKfyhQ=.028ac978-837c-432c-aac4-7435e87ecfdd@github.com>
Message-ID: <CIC1WkGt_mMOaWAd2Dp57x7jz8teQXznUYj4nSoTsNM=.590384c0-43c3-48ef-b8ef-319d4123012f@github.com>

On Wed, 8 Feb 2023 09:39:21 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits:
>> 
>>  - Merge
>>  - Merge
>>  - Fix typos in comments
>>  - GetStackTrace.java test missing @requires vm.continuations
>>  - Initial commit
>
> test/jdk/java/lang/Thread/virtual/HoldsLock.java line 131:
> 
>> 129:                 assertEquals(vthread.getClass().getName(), info.getLockInfo().getClassName());
>> 130:                 assertTrue(info.getLockInfo().getIdentityHashCode() == System.identityHashCode(vthread));
>> 131:                 assertTrue(info.getLockOwnerId() == vthreadId);
> 
> Previously, before the change to these lines, in case of failure, the `assertEquals` would have printed even the incorrect/unexpected value in the log file/exception. Now with the usage of `assertTrue`, that information is lost from the failures. Do you think, in the context of this test, it would be worth to continue using assertEquals and just switch the param order to match junit expectations.

We will be coming back to this test in the future (part of it is disabled) so we can re-visit this test at that time.

> Perhaps `assertNull(name.get())`?. Same on line 325.

Okay, we can do that, note that it impacts 45+ usages and I had hoped to avoid changing the tests too much.

-------------

PR: https://git.openjdk.org/jdk/pull/12426

From jpai at openjdk.org  Wed Feb  8 12:25:39 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 8 Feb 2023 12:25:39 GMT
Subject: RFR: 8301767: Convert virtual thread tests to JUnit [v2]
In-Reply-To: <CIC1WkGt_mMOaWAd2Dp57x7jz8teQXznUYj4nSoTsNM=.590384c0-43c3-48ef-b8ef-319d4123012f@github.com>
References: <37UDjOGF9PZxUiP2BwkrfIKh82vQgdvA8pwxaln4pl8=.5f368aea-d8a2-4e4a-a6ae-4376e1f05c9b@github.com>
 <uVH-roGm09SLtu0SV6K_oadsB_NpmPw2V7DtLEu1qUY=.9963cf59-e7ea-498e-8f5d-47dc8fa95440@github.com>
 <Elipcpaj2eeNZPXIpFI1r4spLHR1fWUb8F7OHxKfyhQ=.028ac978-837c-432c-aac4-7435e87ecfdd@github.com>
 <CIC1WkGt_mMOaWAd2Dp57x7jz8teQXznUYj4nSoTsNM=.590384c0-43c3-48ef-b8ef-319d4123012f@github.com>
Message-ID: <g0Crvt_GRhQfB20XlJ7HVF5D2rjArzAgbOPH-UAmzj4=.a4a38feb-edb4-43d9-82ed-c725573ad057@github.com>

On Wed, 8 Feb 2023 12:18:12 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> note that it impacts 45+ usages and I had hoped to avoid changing the tests too much.

I hadn't realized this construct was used in multiple other places. I see that you already fixed them in a newer commit in this PR; thank you.

-------------

PR: https://git.openjdk.org/jdk/pull/12426

From duke at openjdk.org  Wed Feb  8 12:26:46 2023
From: duke at openjdk.org (Varada M)
Date: Wed, 8 Feb 2023 12:26:46 GMT
Subject: RFR: 8300139 : [AIX] Use pthreads to avoid JNI_createVM call from
 primordial thread
In-Reply-To: <idmR3T0nXkqVauxHs304f7CwlE2N41UGWVkLIKOE2Cg=.274ef41c-6414-4bfa-9bf8-a1bb7c9aa414@github.com>
References: <qbwPBNdxzk4QmB9L6y2t-X6uYgAaPjzAEwYfs_5XV_0=.4ea982e6-30da-4219-b8ad-fa36690170b8@github.com>
 <idmR3T0nXkqVauxHs304f7CwlE2N41UGWVkLIKOE2Cg=.274ef41c-6414-4bfa-9bf8-a1bb7c9aa414@github.com>
Message-ID: <ADxZrlc2bdUTEOW0IZ0rwJ9GQun7qPUw5sJjD-p5RpY=.2cc02fff-6b02-468d-8dd0-0f2ed3eeedf3@github.com>

On Wed, 8 Feb 2023 11:37:14 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> 1. test/jdk/jni/nullCaller/NullCallerTest.java
>> 2. test/jdk/java/lang/reflect/exeCallerAccessTest/CallerAccessTest.java
>> 3. test/hotspot/jtreg/runtime/jni/CalleeSavedRegisters/FPRegs.java 
>> 
>>     The above tests were blocked on AIX [@require os.family != "aix"] because these tests are failing to call JNI_CreateJavaVM. This is solved by implementing JNI_CreateJavaVM call via POSIX threads. 
>>    Similarly there are tests which are not blocked and still failing to call JNI_CreateJavaVM on AIX :
>> 
>> 4. test/hotspot/jtreg/runtime/jni/daemonDestroy/TestDaemonDestroy.java { PR : [12006](https://github.com/openjdk/jdk/pull/12006) }
>> 5. test/lib-test/jdk/test/lib/process/TestNativeProcessBuilder.java 
>> 
>> The reported issue : [8300139](https://bugs.openjdk.org/browse/JDK-8300139l)
>
> test/jdk/jni/nullCaller/exeNullCallerTest.cpp line 206:
> 
>> 204: #else
>> 205:    run(&argv);
>> 206: #endif //AIX
> 
> The tests in test/jdk use 4 space indent rather than 2. Otherwise the changes to these tests look okay, just a bit annoying to have the same #ifdef AIX ... #endif code copied into each test.

Thank you @AlanBateman, I will update with the indentation fixes. [12006](https://github.com/openjdk/jdk/pull/12006) was a parent issue. I thought to make a PR [12302](https://github.com/openjdk/jdk/pull/12302) for other tests after the changes for PR [12006](https://github.com/openjdk/jdk/pull/12006) is accepted by the community.

-------------

PR: https://git.openjdk.org/jdk/pull/12302

From jpai at openjdk.org  Wed Feb  8 12:32:45 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 8 Feb 2023 12:32:45 GMT
Subject: RFR: 8301767: Convert virtual thread tests to JUnit [v2]
In-Reply-To: <CIC1WkGt_mMOaWAd2Dp57x7jz8teQXznUYj4nSoTsNM=.590384c0-43c3-48ef-b8ef-319d4123012f@github.com>
References: <37UDjOGF9PZxUiP2BwkrfIKh82vQgdvA8pwxaln4pl8=.5f368aea-d8a2-4e4a-a6ae-4376e1f05c9b@github.com>
 <uVH-roGm09SLtu0SV6K_oadsB_NpmPw2V7DtLEu1qUY=.9963cf59-e7ea-498e-8f5d-47dc8fa95440@github.com>
 <Elipcpaj2eeNZPXIpFI1r4spLHR1fWUb8F7OHxKfyhQ=.028ac978-837c-432c-aac4-7435e87ecfdd@github.com>
 <CIC1WkGt_mMOaWAd2Dp57x7jz8teQXznUYj4nSoTsNM=.590384c0-43c3-48ef-b8ef-319d4123012f@github.com>
Message-ID: <w0J-G-j-jphFNYAj8WD7LTGSm_rKJ31p05lHfBUB30I=.a8c108f8-cc75-4242-bf63-f87b5748ca9e@github.com>

On Wed, 8 Feb 2023 12:19:02 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> test/jdk/java/lang/Thread/virtual/HoldsLock.java line 131:
>> 
>>> 129:                 assertEquals(vthread.getClass().getName(), info.getLockInfo().getClassName());
>>> 130:                 assertTrue(info.getLockInfo().getIdentityHashCode() == System.identityHashCode(vthread));
>>> 131:                 assertTrue(info.getLockOwnerId() == vthreadId);
>> 
>> Previously, before the change to these lines, in case of failure, the `assertEquals` would have printed even the incorrect/unexpected value in the log file/exception. Now with the usage of `assertTrue`, that information is lost from the failures. Do you think, in the context of this test, it would be worth to continue using assertEquals and just switch the param order to match junit expectations.
>
> We will be coming back to this test in the future (part of it is disabled) so we can re-visit this test at that time.

That sounds fine to me.

-------------

PR: https://git.openjdk.org/jdk/pull/12426

From jpai at openjdk.org  Wed Feb  8 12:37:46 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 8 Feb 2023 12:37:46 GMT
Subject: RFR: 8301767: Convert virtual thread tests to JUnit [v4]
In-Reply-To: <aK7UhZmA39CX1XvdwYBpzknTtICsI_m7RGq6p6pBBdA=.be56bf29-bfb3-496c-a1da-50db5c895781@github.com>
References: <37UDjOGF9PZxUiP2BwkrfIKh82vQgdvA8pwxaln4pl8=.5f368aea-d8a2-4e4a-a6ae-4376e1f05c9b@github.com>
 <aK7UhZmA39CX1XvdwYBpzknTtICsI_m7RGq6p6pBBdA=.be56bf29-bfb3-496c-a1da-50db5c895781@github.com>
Message-ID: <y6BIxFJz7YUMAc9QVcOjULuYULIwfYgOUIE9nB5WHR0=.6db24067-2130-4e58-ad02-70b3eca01151@github.com>

On Wed, 8 Feb 2023 12:25:30 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> The non-hotspot tests integrated with JEP 425/428 were mostly TestNG tests. We'd like to convert these JUnit in the main line in advance of other updates to these tests in 21.  The changes are mostly mechanical and trivial:
>> 
>> - BeforeClass/AfterClass changed to static BeforeAll/AfterAll methods
>> - Tests using data providers are changed to parameterized tests
>> - The order of the parameters to assertEquals are swapped so that the expected result is the first parameter
>> - Usages of expectThrows are changed to assertThrows
>> - Tests that threw SkipException are changed to the Assumptions API
>> 
>> There are a small number of drive-by changes to the tests, nothing significant, e.g.
>> 
>> - GetStackTrace and ParkWithFixedThreadPool changed from "@run testng" to "@run main" as they aren't TestNG tests.
>> - A few of the tests in StructuredTaskScopeTest for joinXXX are changed to use a CountDownLatch rather than sleeping, as the original tests weren't very robust.
>
> Alan Bateman has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Replace assertTrue(x == null) with assertNull(x)

Thank you Alan for the changes. The latest version of this PR (commit 86af1887), looks fine to me.

-------------

Marked as reviewed by jpai (Reviewer).

PR: https://git.openjdk.org/jdk/pull/12426

From duke at openjdk.org  Wed Feb  8 13:11:25 2023
From: duke at openjdk.org (Varada M)
Date: Wed, 8 Feb 2023 13:11:25 GMT
Subject: RFR: 8300139 : [AIX] Use pthreads to avoid JNI_createVM call from
 primordial thread [v2]
In-Reply-To: <qbwPBNdxzk4QmB9L6y2t-X6uYgAaPjzAEwYfs_5XV_0=.4ea982e6-30da-4219-b8ad-fa36690170b8@github.com>
References: <qbwPBNdxzk4QmB9L6y2t-X6uYgAaPjzAEwYfs_5XV_0=.4ea982e6-30da-4219-b8ad-fa36690170b8@github.com>
Message-ID: <vu7c9WHMcCXtkghiBjXUnP3KUy6Xyh7lP7McKSnlJcY=.2e4bdce8-d4e3-4dd1-9fc3-1a27f089dd6f@github.com>

> 1. test/jdk/jni/nullCaller/NullCallerTest.java
> 2. test/jdk/java/lang/reflect/exeCallerAccessTest/CallerAccessTest.java
> 3. test/hotspot/jtreg/runtime/jni/CalleeSavedRegisters/FPRegs.java 
> 
>     The above tests were blocked on AIX [@require os.family != "aix"] because these tests are failing to call JNI_CreateJavaVM. This is solved by implementing JNI_CreateJavaVM call via POSIX threads. 
>    Similarly there are tests which are not blocked and still failing to call JNI_CreateJavaVM on AIX :
> 
> 4. test/hotspot/jtreg/runtime/jni/daemonDestroy/TestDaemonDestroy.java { PR : [12006](https://github.com/openjdk/jdk/pull/12006) }
> 5. test/lib-test/jdk/test/lib/process/TestNativeProcessBuilder.java 
> 
> The reported issue : [8300139](https://bugs.openjdk.org/browse/JDK-8300139l)

Varada M has updated the pull request incrementally with one additional commit since the last revision:

  Fixes

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12302/files
  - new: https://git.openjdk.org/jdk/pull/12302/files/52fa720a..d106745e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12302&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12302&range=00-01

  Stats: 42 lines in 5 files changed: 0 ins; 0 del; 42 mod
  Patch: https://git.openjdk.org/jdk/pull/12302.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12302/head:pull/12302

PR: https://git.openjdk.org/jdk/pull/12302

From duke at openjdk.org  Wed Feb  8 13:19:54 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Wed, 8 Feb 2023 13:19:54 GMT
Subject: RFR: 8301873: Avoid string decoding in ZipFile.Source.getEntryPos
 [v4]
In-Reply-To: <QHObV5Qz9Ygw1cjIooMNFMcXEYlwXUrqpmzvzXeR9-A=.4282ffa4-e17c-4b98-be2f-6b01f8be214d@github.com>
References: <FkmdspiHVjkAKFqm5kUgwaf55YH5cBbczS_3krqsdFs=.05eca901-f55f-47d9-b1bc-0cf2f5b87536@github.com>
 <QHObV5Qz9Ygw1cjIooMNFMcXEYlwXUrqpmzvzXeR9-A=.4282ffa4-e17c-4b98-be2f-6b01f8be214d@github.com>
Message-ID: <ZiZSExF0n_TO-Pitb5SHUT2Rl6PlF_E29Od8zVVOQNw=.d425aa3e-4b89-4848-a356-57d0faae8d7d@github.com>

On Tue, 7 Feb 2023 13:23:26 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

>> After finding a hash match, getEntryPos needs to compare the lookup name up to the encoded entry name in the CEN. This comparison is done by decoding the entry name into a String. The names can then be compared using the String API. This decoding step adds a significat cost to this method.
>> 
>> This PR suggest to update the string comparison such that in the common case where  both the lookup name and the entry name are encoded in ASCII-compatible UTF-8,  decoding can be avoided and the byte arrays can instead be compared direcly. 
>> 
>> ZipCoder is updated with a new method to compare a string with an encoded byte array range.  The default implementation decodes to string (like the current code), while the UTF-8 implementation uses JavaLangAccess.getBytesNoRepl to get the  bytes. Both methods thes uses Arrays.mismatch for comparison with or without matching trailing slashes. 
>> 
>> Additionally, this PR suggest to make the following updates to getEntryPos:
>> 
>> - The try/catch for IAE is redundant and can be safely removed. (initCEN already checks this and will throws IAE for invalid UTF-8). This seems to give a 3-4% speedup on micros)
>> - A new test InvalidBytesInEntryNameOrComment is a added to verify that initCEN does in fact reject invalid UTF-8 in CEN file names and comments. (I found no existing test coverage for this)
>> - The recursion when looking for "name/" matches is replaced with iteration. We keep track of any "name/" match and return it at the end of the search. (I feel this is easier to follow and it also gives a ~30% speedup for addSlash lookups with no regression on regular lookups)
>> 
>> (My though is that including these additional updates in this PR might reduce reviewer overhead given that it touches the exact same code. I might be wrong on this, please advise :)
>> 
>> I'm seeing a ~17% saving on the micro ZipFileGetEntry.getEntryHit (modified to use xalan.jar):
>> 
>> Baseline:
>> 
>> Benchmark                             (size)  Mode  Cnt    Score   Error  Units
>> ZipFileGetEntry.getEntryHit              512  avgt   15   74.941 ? 1.004  ns/op
>> ZipFileGetEntry.getEntryHit             1024  avgt   15   84.943 ? 1.320  ns/op
>> ZipFileGetEntry.getEntryHitUncached      512  avgt   15  120.371 ? 2.386  ns/op
>> ZipFileGetEntry.getEntryHitUncached     1024  avgt   15  126.128 ? 1.075  ns/op
>> ZipFileGetEntry.getEntryMiss             512  avgt   15   23.818 ? 0.838  ns/op
>> ZipFileGetEntry.getEntryMiss            1024  avgt   15   29.762 ? 5.998  ns/op
>> ZipFileGetEntry.getEntryMissUncached     512  avgt   15   59.405 ? 0.545  ns/op
>> ZipFileGetEntry.getEntryMissUncached    1024  avgt   15   71.840 ? 2.455  ns/op
>> ZipFileGetEntry.getEntrySlash            512  avgt   15  135.621 ? 4.341  ns/op
>> ZipFileGetEntry.getEntrySlash           1024  avgt   15  134.190 ? 2.141  ns/op
>> 
>> 
>> 
>> PR:
>> 
>> 
>> Benchmark                             (size)  Mode  Cnt    Score   Error  Units
>> ZipFileGetEntry.getEntryHit              512  avgt   15   62.267 ? 1.329  ns/op
>> ZipFileGetEntry.getEntryHit             1024  avgt   15   72.916 ? 2.428  ns/op
>> ZipFileGetEntry.getEntryHitUncached      512  avgt   15  101.630 ? 1.154  ns/op
>> ZipFileGetEntry.getEntryHitUncached     1024  avgt   15  113.161 ? 0.502  ns/op
>> ZipFileGetEntry.getEntryMiss             512  avgt   15   23.003 ? 1.191  ns/op
>> ZipFileGetEntry.getEntryMiss            1024  avgt   15   23.236 ? 1.114  ns/op
>> ZipFileGetEntry.getEntryMissUncached     512  avgt   15   56.781 ? 1.505  ns/op
>> ZipFileGetEntry.getEntryMissUncached    1024  avgt   15   67.767 ? 1.963  ns/op
>> ZipFileGetEntry.getEntrySlash            512  avgt   15   73.745 ? 2.717  ns/op
>> ZipFileGetEntry.getEntrySlash           1024  avgt   15   75.784 ? 1.051  ns/op
>> 
>> 
>> To assess the impact on startup/warmup, I made a main method class which measures the total time of calling ZipFile.getEntry for all entries in the 109 JAR file dependenies of spring-petclinic. The shows a nice improvement (time in micros):
>> 
>> 
>> Percentile Baseline Patch
>> 50?%          23155 21149
>> 75?%          23598 21454
>> 90?%          23989 21691
>> 95?%          24238 21973
>> 99?%          25270 22446
>> STDEV           792   549
>> Count           500   500
>
> Eirik Bjorsnos 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 'master' into getentrypos-prefixmatch
>  - Fix incorrect offset for the CEN "length of extra field". Fixed spelling of "invalid".
>  - Spelling fix in test data for non-ascii latin1 string
>  - Replace new shared secret with using getBytesNoRepl in UTF8ZipCoder.compare. Add a test case for UTF-8 encoded entry name which is latin1, but not ASCII
>  - Rename test to InvalidBytesInEntryNameOrComment
>  - Adjust whitespace
>  - Some minor improvements to code comments
>  - Micros seem to indicate that the range checks in Arrays.mismatch might have as much as 5% regression
>  - Move String/byte[] comparison into ZipCoder. Change the default implementation to decode to string for comparison instead of encoding to bytes, this seems safer. Revert some changes from previous commits to parameters in the hasTrailingSlash method.
>  - ByteBuffers for reading ZIP files must be little-endian
>  - ... and 10 more: https://git.openjdk.org/jdk/compare/4399bd8c...06047377

I have reproduced this by running testUnicodeManyEntries in a while loop. Smells of hash collisions or System.currentTimeMillis issues.

I'm marking this PR as draft while we investigate this issue.

-------------

PR: https://git.openjdk.org/jdk/pull/12290

From jpai at openjdk.org  Wed Feb  8 13:20:50 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 8 Feb 2023 13:20:50 GMT
Subject: RFR: 8293667: Align jlink's --compress option with jmod's
 --compress option [v5]
In-Reply-To: <A7oOY2Fsic1IQ-nBaDAmShi3CEV_5ZLfJ1BxOWqqhi4=.11e8c2c2-412d-4ee8-afbd-cdd05bc2a6a3@github.com>
References: <JWevwHuR2vF3k-JRxmTAxfNN6g-EBkgG2N9DHn4fkGY=.f9768dfd-cab4-49a9-83b9-d77a1572e917@github.com>
 <A7oOY2Fsic1IQ-nBaDAmShi3CEV_5ZLfJ1BxOWqqhi4=.11e8c2c2-412d-4ee8-afbd-cdd05bc2a6a3@github.com>
Message-ID: <O6GSVeJ1HY0GxCf_z94jb2bvwvxEW5y8Y47egQFHfjA=.6733557a-814d-4030-a2ca-35c290833b83@github.com>

On Mon, 6 Feb 2023 20:12:09 GMT, Ian Graves <igraves at openjdk.org> wrote:

>> This is an approach to adding a flag to jlink that will allow --compress to take the same types of arguments as jmod, thus bringing the two into alignment. This likely requires a CSR and a discussion on whether we should deprecate or simply remove the original numeric compression arguments.
>
> Ian Graves has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adding plugin type to force compact strings vs zip ordering

src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/CompactConstantPoolsPlugin.java line 2:

> 1: /*
> 2:  * Copyright (c) 2015, Oracle and/or its affiliates. All rights reserved.

Hello Ian, the copyright year here is incorrect.

-------------

PR: https://git.openjdk.org/jdk/pull/11617

From stuefe at openjdk.org  Wed Feb  8 13:24:50 2023
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Wed, 8 Feb 2023 13:24:50 GMT
Subject: RFR: 8300139 : [AIX] Use pthreads to avoid JNI_createVM call from
 primordial thread [v2]
In-Reply-To: <p3nx-DOcntTDgseXl1JaDF4795CS0xi_UlcisJGlfug=.04ac3f4c-fa58-44bf-ab01-e2ea82a94a1a@github.com>
References: <qbwPBNdxzk4QmB9L6y2t-X6uYgAaPjzAEwYfs_5XV_0=.4ea982e6-30da-4219-b8ad-fa36690170b8@github.com>
 <RAb0nAe-w8ZiTSMnD-kcuaUrPRVqjZ4_LcQVFvgjMCE=.ece15779-afed-4cc2-a7bc-87b548d50f85@github.com>
 <p3nx-DOcntTDgseXl1JaDF4795CS0xi_UlcisJGlfug=.04ac3f4c-fa58-44bf-ab01-e2ea82a94a1a@github.com>
Message-ID: <BoGCB6a25eosjSYXOa8e9Lw_d4Lp9f8iIyHdz3Gjl0g=.a7aa6f9a-21b2-4581-8389-480d966db25b@github.com>

On Wed, 8 Feb 2023 11:33:07 GMT, Varada M <duke at openjdk.org> wrote:

> I hate to see the code duplication, but we don't have a sharing mechanism for the native parts of tests so that can't be helped.

It may be interesting to invest some time to find out if the "don't start on primordial thread" rule still holds on modern AIX versions.

I added this rule 18 years ago with our original (internal) AIX port because - IIRC - we were unable to find out the stack dimensions of the primordial thread, and we could not place guard pages reliably. And maybe some other problems too; the primordial thread behaved a lot different from pthread back then.

Maybe modern AIX variants don't have that problem anymore. We could cut down all this coding.

Cheers, Thomas

-------------

PR: https://git.openjdk.org/jdk/pull/12302

From rgiulietti at openjdk.org  Wed Feb  8 13:28:43 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Wed, 8 Feb 2023 13:28:43 GMT
Subject: RFR: JDK-8301202: Port fdlibm log to Java
In-Reply-To: <t0yhKjTMAtSuAZjI0unvr73crUuYEM-2HQ8sUI2_sNU=.82036639-980d-46de-a201-3d85bd84563d@github.com>
References: <t0yhKjTMAtSuAZjI0unvr73crUuYEM-2HQ8sUI2_sNU=.82036639-980d-46de-a201-3d85bd84563d@github.com>
Message-ID: <5NVq9HFypHFwYUYC_OxAeUmvXkR2438ZNFMrC9oIO5g=.3f7c4499-cfd5-4522-b6c7-d5e2b2dc92f4@github.com>

On Wed, 8 Feb 2023 00:25:32 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Next up on the FDLIBM porting countdown, the log method.
> 
> Original C vs transliteration port:
> 
> 
> $ diff -w Log.c Log.translit.java 
> 1c1
> < /* __ieee754_log(x)
> ---
>>     /**
> 51,58c51,52
> < 
> < #include "fdlibm.h"
> < 
> < #ifdef __STDC__
> < static const double
> < #else
> < static double
> < #endif
> ---
>>     static class Log {
>>         private static final  double
> 70c64
> < static double zero   =  0.0;
> ---
>>         private static double zero   =  0.0;
> 72,78c66
> < #ifdef __STDC__
> <         double __ieee754_log(double x)
> < #else
> <         double __ieee754_log(x)
> <         double x;
> < #endif
> < {
> ---
>>         static double compute(double x) {
> 81c69
> <         unsigned lx;
> ---
>>             /*unsigned*/ int lx;
> 98c86,87
> <         __HI(x) = hx|(i^0x3ff00000);    /* normalize x or x/2 */
> ---
>>             // __HI(x) = hx|(i^0x3ff00000);    /* normalize x or x/2 */
>>             x =__HI(x, hx|(i^0x3ff00000));    /* normalize x or x/2 */
> 128a118
>>     }
> 
> 
> Transliteration port vs more idiomatic port:
> 
> 
> $ diff -w  Log.translit.java Log.fdlibm.java 
> 2c2
> <      * Return the logarithm of x
> ---
>>      * Return the (natural) logarithm of x
> 53,62c53,54
> <             ln2_hi  =  6.93147180369123816490e-01,  /* 3fe62e42 fee00000 */
> <             ln2_lo  =  1.90821492927058770002e-10,  /* 3dea39ef 35793c76 */
> <             two54   =  1.80143985094819840000e+16,  /* 43500000 00000000 */
> <             Lg1 = 6.666666666666735130e-01,  /* 3FE55555 55555593 */
> <             Lg2 = 3.999999999940941908e-01,  /* 3FD99999 9997FA04 */
> <             Lg3 = 2.857142874366239149e-01,  /* 3FD24924 94229359 */
> <             Lg4 = 2.222219843214978396e-01,  /* 3FCC71C5 1D8E78AF */
> <             Lg5 = 1.818357216161805012e-01,  /* 3FC74664 96CB03DE */
> <             Lg6 = 1.531383769920937332e-01,  /* 3FC39A09 D078C69F */
> <             Lg7 = 1.479819860511658591e-01;  /* 3FC2F112 DF3E5244 */
> ---
>>             ln2_hi = 0x1.62e42feep-1,       // 6.93147180369123816490e-01
>>             ln2_lo = 0x1.a39ef35793c76p-33, // 1.90821492927058770002e-10
> 64c56,64
> <         private static double zero   =  0.0;
> ---
>>             Lg1    = 0x1.5555555555593p-1,  // 6.666666666666735130e-01
>>             Lg2    = 0x1.999999997fa04p-2,  // 3.999999999940941908e-01
>>             Lg3    = 0x1.2492494229359p-2,  // 2.857142874366239149e-01
>>             Lg4    = 0x1.c71c51d8e78afp-3,  // 2.222219843214978396e-01
>>             Lg5    = 0x1.7466496cb03dep-3,  // 1.818357216161805012e-01
>>             Lg6    = 0x1.39a09d078c69fp-3,  // 1.531383769920937332e-01
>>             Lg7    = 0x1.2f112df3e5244p-3;  // 1.479819860511658591e-01
>> 
>>         private static final double zero = 0.0;
> 71,72c71,72
> <             hx = __HI(x);           /* high word of x */
> <             lx = __LO(x);           /* low  word of x */
> ---
>>             hx = __HI(x);           // high word of x
>>             lx = __LO(x);           // low  word of x
> 75,80c75,87
> <             if (hx < 0x00100000) {                  /* x < 2**-1022  */
> <                 if (((hx&0x7fffffff)|lx)==0)
> <                     return -two54/zero;             /* log(+-0)=-inf */
> <                 if (hx<0) return (x-x)/zero;        /* log(-#) = NaN */
> <                 k -= 54; x *= two54; /* subnormal number, scale up x */
> <                 hx = __HI(x);               /* high word of x */
> ---
>>             if (hx < 0x0010_0000) {                  // x < 2**-1022
>>                 if (((hx & 0x7fff_ffff) | lx) ==0) { // log(+-0) = -inf
>>                     return -TWO54/zero;
>>                 }
>>                 if (hx < 0) {                        // log(-#) = NaN
>>                     return (x - x)/zero;
>>                 }
>>                 k -= 54;
>>                 x *= TWO54;    // subnormal number, scale up x
>>                 hx = __HI(x);  // high word of x
>>             }
>>             if (hx >= 0x7ff0_0000) {
>>                 return x+x;
> 82d88
> <             if (hx >= 0x7ff00000) return x+x;
> 84,87c90,92
> <             hx &= 0x000fffff;
> <             i = (hx+0x95f64)&0x100000;
> <             // __HI(x) = hx|(i^0x3ff00000);    /* normalize x or x/2 */
> <             x =__HI(x, hx|(i^0x3ff00000));    /* normalize x or x/2 */
> ---
>>             hx &= 0x000f_ffff;
>>             i = (hx + 0x9_5f64) & 0x10_0000;
>>             x =__HI(x, hx|(i ^ 0x3ff0_0000));  // normalize x or x/2
> 90c95
> <             if((0x000fffff&(2+hx))<3) {     /* |f| < 2**-20 */
> ---
>>             if ((0x000f_ffff & (2 + hx)) < 3) {// |f| < 2**-20
> 92,93c97,102
> <                     if (k==0) return zero;
> <                     else {dk=(double)k; return dk*ln2_hi+dk*ln2_lo;}
> ---
>>                     if (k == 0) {
>>                         return zero;
>>                     } else {
>>                         dk = (double)k;
>>                         return dk*ln2_hi + dk*ln2_lo;
>>                     }
> 96,97c105,110
> <                 if(k==0) return f-R; else {dk=(double)k;
> <                     return dk*ln2_hi-((R-dk*ln2_lo)-f);}
> ---
>>                 if (k == 0) {
>>                     return f - R;
>>                 } else {
>>                     dk = (double)k;
>>                     return dk*ln2_hi - ((R - dk*ln2_lo) - f);
>>                 }
> 102c115
> <             i = hx-0x6147a;
> ---
>>             i = hx - 0x6_147a;
> 111c124,126
> <                 if(k==0) return f-(hfsq-s*(hfsq+R)); else
> ---
>>                 if (k == 0) {
>>                     return f-(hfsq-s*(hfsq+R));
>>                 } else {
> 112a128,131
>>                 }
>>             } else {
>>                 if (k == 0) {
>>                     return f - s*(f - R);
> 114d132
> <                 if(k==0) return f-s*(f-R); else
> 115a134
>>                 }
> 
> 
> The transliteration port passes the "exhausting" test of all float arguments when run against a JDK 20 build. The idiomatic port matches the transliteration port on the same test.

Both the transliteration as well as the more idiomatic versions LGTM.

There are only two decision points in the test, both powers of 2. Since there's an argument reduction step, maybe there are other good ones?

-------------

PR: https://git.openjdk.org/jdk/pull/12465

From jpai at openjdk.org  Wed Feb  8 13:29:47 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 8 Feb 2023 13:29:47 GMT
Subject: RFR: 8293667: Align jlink's --compress option with jmod's
 --compress option [v5]
In-Reply-To: <A7oOY2Fsic1IQ-nBaDAmShi3CEV_5ZLfJ1BxOWqqhi4=.11e8c2c2-412d-4ee8-afbd-cdd05bc2a6a3@github.com>
References: <JWevwHuR2vF3k-JRxmTAxfNN6g-EBkgG2N9DHn4fkGY=.f9768dfd-cab4-49a9-83b9-d77a1572e917@github.com>
 <A7oOY2Fsic1IQ-nBaDAmShi3CEV_5ZLfJ1BxOWqqhi4=.11e8c2c2-412d-4ee8-afbd-cdd05bc2a6a3@github.com>
Message-ID: <SFOPCZEMPecgMf3zdC9ESgWC4AkUxVDw1H0Q2yYnrug=.cecba3a6-4187-41bb-b898-312482076114@github.com>

On Mon, 6 Feb 2023 20:12:09 GMT, Ian Graves <igraves at openjdk.org> wrote:

>> This is an approach to adding a flag to jlink that will allow --compress to take the same types of arguments as jmod, thus bringing the two into alignment. This likely requires a CSR and a discussion on whether we should deprecate or simply remove the original numeric compression arguments.
>
> Ian Graves has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adding plugin type to force compact strings vs zip ordering

src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/CompactConstantPoolsPlugin.java line 44:

> 42: public final class CompactConstantPoolsPlugin extends AbstractPlugin implements ResourcePrevisitor {
> 43: 
> 44:     private static final String FILTER = "filter";

Should we perhaps just reference the already `public` `DefaultCompressPlugin.FILTER` field instead of redefining it here?

-------------

PR: https://git.openjdk.org/jdk/pull/11617

From asotona at openjdk.org  Wed Feb  8 13:47:59 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Wed, 8 Feb 2023 13:47:59 GMT
Subject: RFR: 8294982: Implementation of Classfile API [v12]
In-Reply-To: <LICxfIJ0QVmRRY4NJPCW_Rp4o3qhyaMrrgWLV-S9jHI=.4f6b40d5-d25d-4035-8fa5-186b2c735606@github.com>
References: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
 <Q4VeZ2yWAg85FqUDJa5hYq3jHty5H547gD0H-x3oIq0=.58d463a4-237a-4fee-bd0f-83262d49522a@github.com>
 <c022hrWNEHW76nhP_sXTQXCTjtL8jjM8r_yYv0IvbPI=.2a9cfbae-2fef-4cdb-8189-b869b1513fef@github.com>
 <FbFekphAbS5DQzn6B-uUHkX-2EF8Aq4NcijjMdlxAM0=.280a7529-4008-4539-9137-da7600e13eee@github.com>
 <kxds1bmvZ8TbtVK5iDx_hZtrqN3uywsa6GqumJ7RubE=.ffd151e4-a1ba-4018-914c-518fd122dd4f@github.com>
 <WxjOq5CRJ9OtviOIxDKH9C78bScpiGmkiBqVXLDddzU=.a5a85537-43e8-4cf4-b747-86b945999d71@github.com>
 <84RlLSIsacJTJVM-esvzoXnQ5rDEByog5b1ibFRJOE8=.05e8e7a7-2185-4e1c-b5b9-59ce3b3eea03@github.com>
 <sQwAa41mu1z226uzYIA2_v0tN8un257MDgc-WPO8SFY=.486c845c-5012-4291-bcd7-c7b0247e02dd@github.com>
 <wxsAcKZwigc4sIUexg5m-6UlOg8ZHflccTs47FJCgdQ=.5613b95e-96b0-4ced-a587-ccca3f80595d@github.com>
 <_jsw8D5-esoFp7fGSZECKF8ccwrfikwjIprRrVdCOjo=.2d8cd9f6-9c6a-4726-bc90-a4c163e8dd67@github.com>
 <LICxfIJ0QVmRRY4NJPCW_Rp4o3qhyaMrrgW
 LV-S9jHI=.4f6b40d5-d25d-4035-8fa5-186b2c735606@github.com>
Message-ID: <wzHOP5Fnj3FhcNs61TKxxBZ5R6fB-oky72z_hlf1Svk=.ed56a42f-cce6-415a-b93a-d39dee6adc78@github.com>

On Wed, 8 Feb 2023 12:19:35 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>>> `Signature.ThrowableSig` is a `Signature` and it is a common super of `ClassTypeSig` and `TypeVarSig`.
>> 
>> I really don't follow here. ThrowableSig is a piece of a method signature, which starts with "^" and is followed by either a class or a typevar signature. You can never encounter it from the toplevel JavaTypeSignature production. It's ok (as I have said) to have a ThrowableSig element in the API to model the production, but that element should not be a subtype of Signature (at least not if Signature, as you claimed is meant to model the JavaTypeSignature production). That is, there's no "is a" relationship between JavaTypeSignature and ThrowableSig (at least not that I can see when looking at the productions).
>
> OK, I see your point now, I'll fix it.
> Thanks

During the fix I found the definition that `ThrowableSig` (as a super-set of `ClassTypeSig` and `TypeVarSig`) IS `Signature` - that fact is critical for processing.
For example when `MethodSignature` is serialized `ThrowableSig::signatureString` is critical.
Or `ClassRemapper` depends on the inheritence:

signature.throwableSignatures().stream().map(this::mapSignature).toList()

however `mapSignature` could not be applied on `ThrowableSig` when it does not inherit from `Signature`.

-------------

PR: https://git.openjdk.org/jdk/pull/10982

From msheppar at openjdk.org  Wed Feb  8 13:52:45 2023
From: msheppar at openjdk.org (Mark Sheppard)
Date: Wed, 8 Feb 2023 13:52:45 GMT
Subject: RFR: 8301737:
 java/rmi/server/UnicastRemoteObject/serialFilter/FilterUROTest.java fail with
 -Xcomp [v3]
In-Reply-To: <zMo8OEhYAKUz5LWOssEWEUQDoySJo7hsL7_KAzfNU34=.2309b7bb-5e1d-47e8-b932-aedfbce71e5b@github.com>
References: <l5m5_9io2QMSFNY7dBHT3Nr2I9Er8wmd92Ze8FP-XE0=.a40d29be-77be-4719-a0a0-71d032eea1e5@github.com>
 <zMo8OEhYAKUz5LWOssEWEUQDoySJo7hsL7_KAzfNU34=.2309b7bb-5e1d-47e8-b932-aedfbce71e5b@github.com>
Message-ID: <6mUnOysU3i4kRlBOc5NQ0Lo4r5rpmefk-Rs0WhM4K64=.e9e50a1b-9665-4174-97ea-f75ab9323106@github.com>

On Tue, 7 Feb 2023 08:27:57 GMT, SUN Guoyun <duke at openjdk.org> wrote:

>> Hi all,
>> When -Xcomp be used, this testcase will use more codecaches, causing the GC to be triggered early, then causing this test failed on LoongArch64 architecture.
>> 
>> This PR fix the issue, Please help review it.
>> 
>> Thanks.
>
> SUN Guoyun has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8301737: java/rmi/server/UnicastRemoteObject/serialFilter/FilterUROTest.java fail with -Xcomp

This change seems to be a bit dubious, it may solve your observed issue, but could be masking a deeper issue within the GC or the code generated as a result the -Xcomp vm arg, or an issue within TestNg, or possibly some obscure issue in RMI.
As I understand it, in simple terms, an object instance is not available for GC until there are no references held to it i.e. when it is not reachable and all references have been discarded.
In this scenario the test method, useExportObject, holds a reference to a RemoteImpl impl which has the scope of the try block, that should be sufficient for it to retain its liveness for it to be still available when the client invokes the fliterCount method.

So maybe extend the scope of the variable by moving the declaration of the variable impl outside of the try block, it is still assigned within the try block, but now its scope is the full duration of the test method, and not just that of the try block. As such, it should only be available for GC when the test method completes and it goes out of scope.

-------------

PR: https://git.openjdk.org/jdk/pull/12399

From rriggs at openjdk.org  Wed Feb  8 14:31:48 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 8 Feb 2023 14:31:48 GMT
Subject: RFR: JDK-8301704: Shorten the number of GCs in UnloadingTest.java
 to verify a class loader not being unloaded
In-Reply-To: <bdUKXSHJGqFT5OdTZgU21MwCcuP9aAkg3lIP3WQbyJY=.c41376be-4fc1-409c-a2c1-42f1d0b30aba@github.com>
References: <bdUKXSHJGqFT5OdTZgU21MwCcuP9aAkg3lIP3WQbyJY=.c41376be-4fc1-409c-a2c1-42f1d0b30aba@github.com>
Message-ID: <pv0oEP5U-Co6zuGoifzHLQyETQwAN6NcHc6amVut1s0=.bc189d68-e1f8-42a5-9837-7175ba5aad21@github.com>

On Thu, 2 Feb 2023 20:09:22 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> `test/jdk/java/lang/invoke/defineHiddenClass/UnloadingTest.java` defines hidden classes and verify cases that a class loader is not unloaded using `ForceGC::wait`.    ForceGC::wait` defaults the timeout to 1000ms * jtreg timeout factor, which is designed to work well to expect an object being reclaimed, i.e. the boolean supplier returns true.   On the other hand, if the boolean supplier never returns true, the method returns after it timeouts which may be long depending on the timeout factor. 
> 
> This PR adds a variant of `ForceGC::wait` to take a timeout parameter and tests can specify the timeout to reduce the time it takes testing a strongly reachable object not being reclaimed.

test/lib/jdk/test/lib/util/ForceGC.java line 73:

> 71:      *     if did not complete after the specified waiting time.
> 72:      */
> 73:     public static boolean wait(BooleanSupplier booleanSupplier, long timeout) {

Can the method name be changed to make it clear the timeout is not scaled by the TIMEOUT factor.
(It would have been better if the original method name mentioned the timeout factor).
How about,  `waitNoMoreThan`.

-------------

PR: https://git.openjdk.org/jdk/pull/12392

From duke at openjdk.org  Wed Feb  8 14:59:51 2023
From: duke at openjdk.org (David Schlosnagle)
Date: Wed, 8 Feb 2023 14:59:51 GMT
Subject: RFR: 8301958: Reduce Arrays.copyOf/-Range overheads [v9]
In-Reply-To: <5cK3YK6OKgztMKSjd7gmp5ayTrlD9fzcsxTxjaJ1f40=.7b285e15-050e-4d2e-8479-e7b5b8cffcd9@github.com>
References: <2pdPoSHz2RJ7YDHOwOyszQMVv0v7FQFOwykfJ-za_e0=.cfe480da-a045-4b9a-bec7-7fffd0f47206@github.com>
 <5cK3YK6OKgztMKSjd7gmp5ayTrlD9fzcsxTxjaJ1f40=.7b285e15-050e-4d2e-8479-e7b5b8cffcd9@github.com>
Message-ID: <ApOJuXXUett3y1EOKJQZEWTaRlQMk3bBCouk3A07mVk=.ced5753d-1670-4fb0-bfec-7c76843b2bb7@github.com>

On Wed, 8 Feb 2023 10:53:22 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> This patch adds special-cases to `Arrays.copyOf` and `Arrays.copyOfRange` to clone arrays when `newLength` or range inputs span the input array. This helps eliminate range checks and has been verified to help various String operations. Example:
>> 
>> Baseline
>> 
>> Benchmark                                            (size)  Mode  Cnt   Score   Error  Units
>> StringConstructor.newStringFromArray                      7  avgt   15  16.817 ? 0.369  ns/op
>> StringConstructor.newStringFromArrayWithCharset           7  avgt   15  16.866 ? 0.449  ns/op
>> StringConstructor.newStringFromArrayWithCharsetName       7  avgt   15  22.198 ? 0.396  ns/op
>> 
>> Patch: 
>> 
>> Benchmark                                            (size)  Mode  Cnt   Score   Error  Units
>> StringConstructor.newStringFromArray                      7  avgt   15  14.666 ? 0.336  ns/op
>> StringConstructor.newStringFromArrayWithCharset           7  avgt   15  14.582 ? 0.288  ns/op
>> StringConstructor.newStringFromArrayWithCharsetName       7  avgt   15  20.339 ? 0.328  ns/op
>
> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add offset param to micro, reduce number of configurations and variants

Marked as reviewed by schlosna at github.com (no known OpenJDK username).

-------------

PR: https://git.openjdk.org/jdk/pull/12453

From alanb at openjdk.org  Wed Feb  8 15:00:06 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 8 Feb 2023 15:00:06 GMT
Subject: Integrated: 8301767: Convert virtual thread tests to JUnit
In-Reply-To: <37UDjOGF9PZxUiP2BwkrfIKh82vQgdvA8pwxaln4pl8=.5f368aea-d8a2-4e4a-a6ae-4376e1f05c9b@github.com>
References: <37UDjOGF9PZxUiP2BwkrfIKh82vQgdvA8pwxaln4pl8=.5f368aea-d8a2-4e4a-a6ae-4376e1f05c9b@github.com>
Message-ID: <8MoZw1JVFGXMlFsi6xdcio3G5iqxS_rvJh0EcOJOn6s=.ba9fbe0d-c465-4ab8-b5c2-40717efc089f@github.com>

On Sat, 4 Feb 2023 08:59:29 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> The non-hotspot tests integrated with JEP 425/428 were mostly TestNG tests. We'd like to convert these JUnit in the main line in advance of other updates to these tests in 21.  The changes are mostly mechanical and trivial:
> 
> - BeforeClass/AfterClass changed to static BeforeAll/AfterAll methods
> - Tests using data providers are changed to parameterized tests
> - The order of the parameters to assertEquals are swapped so that the expected result is the first parameter
> - Usages of expectThrows are changed to assertThrows
> - Tests that threw SkipException are changed to the Assumptions API
> 
> There are a small number of drive-by changes to the tests, nothing significant, e.g.
> 
> - GetStackTrace and ParkWithFixedThreadPool changed from "@run testng" to "@run main" as they aren't TestNG tests.
> - A few of the tests in StructuredTaskScopeTest for joinXXX are changed to use a CountDownLatch rather than sleeping, as the original tests weren't very robust.

This pull request has now been integrated.

Changeset: ecf21a9a
Author:    Alan Bateman <alanb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/ecf21a9a24d067725fda916ab197b5711c56a1d7
Stats:     1456 lines in 34 files changed: 204 ins; 79 del; 1173 mod

8301767: Convert virtual thread tests to JUnit

Reviewed-by: cstein, lancea, jpai

-------------

PR: https://git.openjdk.org/jdk/pull/12426

From duke at openjdk.org  Wed Feb  8 15:21:23 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Wed, 8 Feb 2023 15:21:23 GMT
Subject: RFR: 8301873: Avoid string decoding in ZipFile.Source.getEntryPos
 [v5]
In-Reply-To: <FkmdspiHVjkAKFqm5kUgwaf55YH5cBbczS_3krqsdFs=.05eca901-f55f-47d9-b1bc-0cf2f5b87536@github.com>
References: <FkmdspiHVjkAKFqm5kUgwaf55YH5cBbczS_3krqsdFs=.05eca901-f55f-47d9-b1bc-0cf2f5b87536@github.com>
Message-ID: <_24L8SrA8ejikdCKtYDEoX7kVmF5yJxyvC3dvEo9yeg=.300e1bf3-c213-4cd1-b52d-c98ae654c692@github.com>

> After finding a hash match, getEntryPos needs to compare the lookup name up to the encoded entry name in the CEN. This comparison is done by decoding the entry name into a String. The names can then be compared using the String API. This decoding step adds a significat cost to this method.
> 
> This PR suggest to update the string comparison such that in the common case where  both the lookup name and the entry name are encoded in ASCII-compatible UTF-8,  decoding can be avoided and the byte arrays can instead be compared direcly. 
> 
> ZipCoder is updated with a new method to compare a string with an encoded byte array range.  The default implementation decodes to string (like the current code), while the UTF-8 implementation uses JavaLangAccess.getBytesNoRepl to get the  bytes. Both methods thes uses Arrays.mismatch for comparison with or without matching trailing slashes. 
> 
> Additionally, this PR suggest to make the following updates to getEntryPos:
> 
> - The try/catch for IAE is redundant and can be safely removed. (initCEN already checks this and will throws IAE for invalid UTF-8). This seems to give a 3-4% speedup on micros)
> - A new test InvalidBytesInEntryNameOrComment is a added to verify that initCEN does in fact reject invalid UTF-8 in CEN file names and comments. (I found no existing test coverage for this)
> - The recursion when looking for "name/" matches is replaced with iteration. We keep track of any "name/" match and return it at the end of the search. (I feel this is easier to follow and it also gives a ~30% speedup for addSlash lookups with no regression on regular lookups)
> 
> (My though is that including these additional updates in this PR might reduce reviewer overhead given that it touches the exact same code. I might be wrong on this, please advise :)
> 
> I'm seeing a ~17% saving on the micro ZipFileGetEntry.getEntryHit (modified to use xalan.jar):
> 
> Baseline:
> 
> Benchmark                             (size)  Mode  Cnt    Score   Error  Units
> ZipFileGetEntry.getEntryHit              512  avgt   15   74.941 ? 1.004  ns/op
> ZipFileGetEntry.getEntryHit             1024  avgt   15   84.943 ? 1.320  ns/op
> ZipFileGetEntry.getEntryHitUncached      512  avgt   15  120.371 ? 2.386  ns/op
> ZipFileGetEntry.getEntryHitUncached     1024  avgt   15  126.128 ? 1.075  ns/op
> ZipFileGetEntry.getEntryMiss             512  avgt   15   23.818 ? 0.838  ns/op
> ZipFileGetEntry.getEntryMiss            1024  avgt   15   29.762 ? 5.998  ns/op
> ZipFileGetEntry.getEntryMissUncached     512  avgt   15   59.405 ? 0.545  ns/op
> ZipFileGetEntry.getEntryMissUncached    1024  avgt   15   71.840 ? 2.455  ns/op
> ZipFileGetEntry.getEntrySlash            512  avgt   15  135.621 ? 4.341  ns/op
> ZipFileGetEntry.getEntrySlash           1024  avgt   15  134.190 ? 2.141  ns/op
> 
> 
> 
> PR:
> 
> 
> Benchmark                             (size)  Mode  Cnt    Score   Error  Units
> ZipFileGetEntry.getEntryHit              512  avgt   15   62.267 ? 1.329  ns/op
> ZipFileGetEntry.getEntryHit             1024  avgt   15   72.916 ? 2.428  ns/op
> ZipFileGetEntry.getEntryHitUncached      512  avgt   15  101.630 ? 1.154  ns/op
> ZipFileGetEntry.getEntryHitUncached     1024  avgt   15  113.161 ? 0.502  ns/op
> ZipFileGetEntry.getEntryMiss             512  avgt   15   23.003 ? 1.191  ns/op
> ZipFileGetEntry.getEntryMiss            1024  avgt   15   23.236 ? 1.114  ns/op
> ZipFileGetEntry.getEntryMissUncached     512  avgt   15   56.781 ? 1.505  ns/op
> ZipFileGetEntry.getEntryMissUncached    1024  avgt   15   67.767 ? 1.963  ns/op
> ZipFileGetEntry.getEntrySlash            512  avgt   15   73.745 ? 2.717  ns/op
> ZipFileGetEntry.getEntrySlash           1024  avgt   15   75.784 ? 1.051  ns/op
> 
> 
> To assess the impact on startup/warmup, I made a main method class which measures the total time of calling ZipFile.getEntry for all entries in the 109 JAR file dependenies of spring-petclinic. The shows a nice improvement (time in micros):
> 
> 
> Percentile Baseline Patch
> 50?%          23155 21149
> 75?%          23598 21454
> 90?%          23989 21691
> 95?%          24238 21973
> 99?%          25270 22446
> STDEV           792   549
> Count           500   500

Eirik Bjorsnos has updated the pull request incrementally with one additional commit since the last revision:

  In the ZipCoder.compare base implementation, add check that the decoded name startsWith the search name. Add a test to TestZipFileEncodings which catches this regression by performing lookups on entries with matching hash codes and lengths.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12290/files
  - new: https://git.openjdk.org/jdk/pull/12290/files/06047377..f9285261

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12290&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12290&range=03-04

  Stats: 37 lines in 2 files changed: 34 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/12290.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12290/head:pull/12290

PR: https://git.openjdk.org/jdk/pull/12290

From duke at openjdk.org  Wed Feb  8 15:31:15 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Wed, 8 Feb 2023 15:31:15 GMT
Subject: RFR: 8301873: Avoid string decoding in ZipFile.Source.getEntryPos
 [v6]
In-Reply-To: <FkmdspiHVjkAKFqm5kUgwaf55YH5cBbczS_3krqsdFs=.05eca901-f55f-47d9-b1bc-0cf2f5b87536@github.com>
References: <FkmdspiHVjkAKFqm5kUgwaf55YH5cBbczS_3krqsdFs=.05eca901-f55f-47d9-b1bc-0cf2f5b87536@github.com>
Message-ID: <vTxPmgWhY7d0vEzsOz2UvKZFEX_gSfTKliIJ_I0uoiE=.8fc025cf-4711-4b63-ac34-e7cb903e0724@github.com>

> After finding a hash match, getEntryPos needs to compare the lookup name up to the encoded entry name in the CEN. This comparison is done by decoding the entry name into a String. The names can then be compared using the String API. This decoding step adds a significat cost to this method.
> 
> This PR suggest to update the string comparison such that in the common case where  both the lookup name and the entry name are encoded in ASCII-compatible UTF-8,  decoding can be avoided and the byte arrays can instead be compared direcly. 
> 
> ZipCoder is updated with a new method to compare a string with an encoded byte array range.  The default implementation decodes to string (like the current code), while the UTF-8 implementation uses JavaLangAccess.getBytesNoRepl to get the  bytes. Both methods thes uses Arrays.mismatch for comparison with or without matching trailing slashes. 
> 
> Additionally, this PR suggest to make the following updates to getEntryPos:
> 
> - The try/catch for IAE is redundant and can be safely removed. (initCEN already checks this and will throws IAE for invalid UTF-8). This seems to give a 3-4% speedup on micros)
> - A new test InvalidBytesInEntryNameOrComment is a added to verify that initCEN does in fact reject invalid UTF-8 in CEN file names and comments. (I found no existing test coverage for this)
> - The recursion when looking for "name/" matches is replaced with iteration. We keep track of any "name/" match and return it at the end of the search. (I feel this is easier to follow and it also gives a ~30% speedup for addSlash lookups with no regression on regular lookups)
> 
> (My though is that including these additional updates in this PR might reduce reviewer overhead given that it touches the exact same code. I might be wrong on this, please advise :)
> 
> I'm seeing a ~17% saving on the micro ZipFileGetEntry.getEntryHit (modified to use xalan.jar):
> 
> Baseline:
> 
> Benchmark                             (size)  Mode  Cnt    Score   Error  Units
> ZipFileGetEntry.getEntryHit              512  avgt   15   74.941 ? 1.004  ns/op
> ZipFileGetEntry.getEntryHit             1024  avgt   15   84.943 ? 1.320  ns/op
> ZipFileGetEntry.getEntryHitUncached      512  avgt   15  120.371 ? 2.386  ns/op
> ZipFileGetEntry.getEntryHitUncached     1024  avgt   15  126.128 ? 1.075  ns/op
> ZipFileGetEntry.getEntryMiss             512  avgt   15   23.818 ? 0.838  ns/op
> ZipFileGetEntry.getEntryMiss            1024  avgt   15   29.762 ? 5.998  ns/op
> ZipFileGetEntry.getEntryMissUncached     512  avgt   15   59.405 ? 0.545  ns/op
> ZipFileGetEntry.getEntryMissUncached    1024  avgt   15   71.840 ? 2.455  ns/op
> ZipFileGetEntry.getEntrySlash            512  avgt   15  135.621 ? 4.341  ns/op
> ZipFileGetEntry.getEntrySlash           1024  avgt   15  134.190 ? 2.141  ns/op
> 
> 
> 
> PR:
> 
> 
> Benchmark                             (size)  Mode  Cnt    Score   Error  Units
> ZipFileGetEntry.getEntryHit              512  avgt   15   62.267 ? 1.329  ns/op
> ZipFileGetEntry.getEntryHit             1024  avgt   15   72.916 ? 2.428  ns/op
> ZipFileGetEntry.getEntryHitUncached      512  avgt   15  101.630 ? 1.154  ns/op
> ZipFileGetEntry.getEntryHitUncached     1024  avgt   15  113.161 ? 0.502  ns/op
> ZipFileGetEntry.getEntryMiss             512  avgt   15   23.003 ? 1.191  ns/op
> ZipFileGetEntry.getEntryMiss            1024  avgt   15   23.236 ? 1.114  ns/op
> ZipFileGetEntry.getEntryMissUncached     512  avgt   15   56.781 ? 1.505  ns/op
> ZipFileGetEntry.getEntryMissUncached    1024  avgt   15   67.767 ? 1.963  ns/op
> ZipFileGetEntry.getEntrySlash            512  avgt   15   73.745 ? 2.717  ns/op
> ZipFileGetEntry.getEntrySlash           1024  avgt   15   75.784 ? 1.051  ns/op
> 
> 
> To assess the impact on startup/warmup, I made a main method class which measures the total time of calling ZipFile.getEntry for all entries in the 109 JAR file dependenies of spring-petclinic. The shows a nice improvement (time in micros):
> 
> 
> Percentile Baseline Patch
> 50?%          23155 21149
> 75?%          23598 21454
> 90?%          23989 21691
> 95?%          24238 21973
> 99?%          25270 22446
> STDEV           792   549
> Count           500   500

Eirik Bjorsnos has updated the pull request incrementally with one additional commit since the last revision:

  Align entry name whitespace

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12290/files
  - new: https://git.openjdk.org/jdk/pull/12290/files/f9285261..ac7c4c7a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12290&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12290&range=04-05

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/12290.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12290/head:pull/12290

PR: https://git.openjdk.org/jdk/pull/12290

From duke at openjdk.org  Wed Feb  8 15:31:19 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Wed, 8 Feb 2023 15:31:19 GMT
Subject: RFR: 8301873: Avoid string decoding in ZipFile.Source.getEntryPos
 [v5]
In-Reply-To: <_24L8SrA8ejikdCKtYDEoX7kVmF5yJxyvC3dvEo9yeg=.300e1bf3-c213-4cd1-b52d-c98ae654c692@github.com>
References: <FkmdspiHVjkAKFqm5kUgwaf55YH5cBbczS_3krqsdFs=.05eca901-f55f-47d9-b1bc-0cf2f5b87536@github.com>
 <_24L8SrA8ejikdCKtYDEoX7kVmF5yJxyvC3dvEo9yeg=.300e1bf3-c213-4cd1-b52d-c98ae654c692@github.com>
Message-ID: <PWw8k5a6EsJ2b1F-JYUvdfEqsS5vXEupzWSUjeoayzQ=.16839e7f-1431-4503-b7f9-8bad0a732584@github.com>

On Wed, 8 Feb 2023 15:21:23 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

>> After finding a hash match, getEntryPos needs to compare the lookup name up to the encoded entry name in the CEN. This comparison is done by decoding the entry name into a String. The names can then be compared using the String API. This decoding step adds a significat cost to this method.
>> 
>> This PR suggest to update the string comparison such that in the common case where  both the lookup name and the entry name are encoded in ASCII-compatible UTF-8,  decoding can be avoided and the byte arrays can instead be compared direcly. 
>> 
>> ZipCoder is updated with a new method to compare a string with an encoded byte array range.  The default implementation decodes to string (like the current code), while the UTF-8 implementation uses JavaLangAccess.getBytesNoRepl to get the  bytes. Both methods thes uses Arrays.mismatch for comparison with or without matching trailing slashes. 
>> 
>> Additionally, this PR suggest to make the following updates to getEntryPos:
>> 
>> - The try/catch for IAE is redundant and can be safely removed. (initCEN already checks this and will throws IAE for invalid UTF-8). This seems to give a 3-4% speedup on micros)
>> - A new test InvalidBytesInEntryNameOrComment is a added to verify that initCEN does in fact reject invalid UTF-8 in CEN file names and comments. (I found no existing test coverage for this)
>> - The recursion when looking for "name/" matches is replaced with iteration. We keep track of any "name/" match and return it at the end of the search. (I feel this is easier to follow and it also gives a ~30% speedup for addSlash lookups with no regression on regular lookups)
>> 
>> (My though is that including these additional updates in this PR might reduce reviewer overhead given that it touches the exact same code. I might be wrong on this, please advise :)
>> 
>> I'm seeing a ~17% saving on the micro ZipFileGetEntry.getEntryHit (modified to use xalan.jar):
>> 
>> Baseline:
>> 
>> Benchmark                             (size)  Mode  Cnt    Score   Error  Units
>> ZipFileGetEntry.getEntryHit              512  avgt   15   74.941 ? 1.004  ns/op
>> ZipFileGetEntry.getEntryHit             1024  avgt   15   84.943 ? 1.320  ns/op
>> ZipFileGetEntry.getEntryHitUncached      512  avgt   15  120.371 ? 2.386  ns/op
>> ZipFileGetEntry.getEntryHitUncached     1024  avgt   15  126.128 ? 1.075  ns/op
>> ZipFileGetEntry.getEntryMiss             512  avgt   15   23.818 ? 0.838  ns/op
>> ZipFileGetEntry.getEntryMiss            1024  avgt   15   29.762 ? 5.998  ns/op
>> ZipFileGetEntry.getEntryMissUncached     512  avgt   15   59.405 ? 0.545  ns/op
>> ZipFileGetEntry.getEntryMissUncached    1024  avgt   15   71.840 ? 2.455  ns/op
>> ZipFileGetEntry.getEntrySlash            512  avgt   15  135.621 ? 4.341  ns/op
>> ZipFileGetEntry.getEntrySlash           1024  avgt   15  134.190 ? 2.141  ns/op
>> 
>> 
>> 
>> PR:
>> 
>> 
>> Benchmark                             (size)  Mode  Cnt    Score   Error  Units
>> ZipFileGetEntry.getEntryHit              512  avgt   15   62.267 ? 1.329  ns/op
>> ZipFileGetEntry.getEntryHit             1024  avgt   15   72.916 ? 2.428  ns/op
>> ZipFileGetEntry.getEntryHitUncached      512  avgt   15  101.630 ? 1.154  ns/op
>> ZipFileGetEntry.getEntryHitUncached     1024  avgt   15  113.161 ? 0.502  ns/op
>> ZipFileGetEntry.getEntryMiss             512  avgt   15   23.003 ? 1.191  ns/op
>> ZipFileGetEntry.getEntryMiss            1024  avgt   15   23.236 ? 1.114  ns/op
>> ZipFileGetEntry.getEntryMissUncached     512  avgt   15   56.781 ? 1.505  ns/op
>> ZipFileGetEntry.getEntryMissUncached    1024  avgt   15   67.767 ? 1.963  ns/op
>> ZipFileGetEntry.getEntrySlash            512  avgt   15   73.745 ? 2.717  ns/op
>> ZipFileGetEntry.getEntrySlash           1024  avgt   15   75.784 ? 1.051  ns/op
>> 
>> 
>> To assess the impact on startup/warmup, I made a main method class which measures the total time of calling ZipFile.getEntry for all entries in the 109 JAR file dependenies of spring-petclinic. The shows a nice improvement (time in micros):
>> 
>> 
>> Percentile Baseline Patch
>> 50?%          23155 21149
>> 75?%          23598 21454
>> 90?%          23989 21691
>> 95?%          24238 21973
>> 99?%          25270 22446
>> STDEV           792   549
>> Count           500   500
>
> Eirik Bjorsnos has updated the pull request incrementally with one additional commit since the last revision:
> 
>   In the ZipCoder.compare base implementation, add check that the decoded name startsWith the search name. Add a test to TestZipFileEncodings which catches this regression by performing lookups on entries with matching hash codes and lengths.

I found the bug!

Turns out the entry.startsWith(name) check got lost when moving the slashMatch logic into ZipCoder.compare. This resulted in a possible false positive SLASH_MATCH for non-UTF ZIPs if two names have colliding hash codes AND equal lengths. This case is rare, so we are lucky that the TestZipFileEncodings found it in one of the runs!

The fix is to add back the startsWith check. I have also added a test to TestZipFileEncodings which reliably reproduces the issue using the names found from the analysis.

Thanks to @cl4es for identifying the failing test which I had noticed, but misinterpreted as an infra glitch.

-------------

PR: https://git.openjdk.org/jdk/pull/12290

From tsteele at openjdk.org  Wed Feb  8 15:56:48 2023
From: tsteele at openjdk.org (Tyler Steele)
Date: Wed, 8 Feb 2023 15:56:48 GMT
Subject: RFR: 8300139 : [AIX] Use pthreads to avoid JNI_createVM call from
 primordial thread [v2]
In-Reply-To: <vu7c9WHMcCXtkghiBjXUnP3KUy6Xyh7lP7McKSnlJcY=.2e4bdce8-d4e3-4dd1-9fc3-1a27f089dd6f@github.com>
References: <qbwPBNdxzk4QmB9L6y2t-X6uYgAaPjzAEwYfs_5XV_0=.4ea982e6-30da-4219-b8ad-fa36690170b8@github.com>
 <vu7c9WHMcCXtkghiBjXUnP3KUy6Xyh7lP7McKSnlJcY=.2e4bdce8-d4e3-4dd1-9fc3-1a27f089dd6f@github.com>
Message-ID: <QTwPdJwOHDusp2tHfO-PsEHvw9Ou73lYen6aAtntTsY=.663a0049-cde2-4d9d-b172-3ffc4019f026@github.com>

On Wed, 8 Feb 2023 13:11:25 GMT, Varada M <duke at openjdk.org> wrote:

>> 1. test/jdk/jni/nullCaller/NullCallerTest.java
>> 2. test/jdk/java/lang/reflect/exeCallerAccessTest/CallerAccessTest.java
>> 3. test/hotspot/jtreg/runtime/jni/CalleeSavedRegisters/FPRegs.java 
>> 
>>     The above tests were blocked on AIX [@require os.family != "aix"] because these tests are failing to call JNI_CreateJavaVM. This is solved by implementing JNI_CreateJavaVM call via POSIX threads. 
>>    Similarly there are tests which are not blocked and still failing to call JNI_CreateJavaVM on AIX :
>> 
>> 4. test/hotspot/jtreg/runtime/jni/daemonDestroy/TestDaemonDestroy.java { PR : [12006](https://github.com/openjdk/jdk/pull/12006) }
>> 5. test/lib-test/jdk/test/lib/process/TestNativeProcessBuilder.java 
>> 
>> The reported issue : [8300139](https://bugs.openjdk.org/browse/JDK-8300139l)
>
> Varada M has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixes

test/hotspot/jtreg/runtime/jni/CalleeSavedRegisters/FPRegs.java line 2:

> 1: /*
> 2:  * Copyright (c) 2021, 2023, Oracle and/or its affiliates. All rights reserved.

We shouldn't ever need to update the left (starting) year in this range; only the rightmost year should change. Please update this line to have the range `2016, 2023`.

-------------

PR: https://git.openjdk.org/jdk/pull/12302

From redestad at openjdk.org  Wed Feb  8 16:08:44 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Wed, 8 Feb 2023 16:08:44 GMT
Subject: RFR: 8301873: Avoid string decoding in ZipFile.Source.getEntryPos
 [v6]
In-Reply-To: <vTxPmgWhY7d0vEzsOz2UvKZFEX_gSfTKliIJ_I0uoiE=.8fc025cf-4711-4b63-ac34-e7cb903e0724@github.com>
References: <FkmdspiHVjkAKFqm5kUgwaf55YH5cBbczS_3krqsdFs=.05eca901-f55f-47d9-b1bc-0cf2f5b87536@github.com>
 <vTxPmgWhY7d0vEzsOz2UvKZFEX_gSfTKliIJ_I0uoiE=.8fc025cf-4711-4b63-ac34-e7cb903e0724@github.com>
Message-ID: <KNsiozMAEf3AY8ntZdW_MYeHyZOyguL9mzOuLi5VINg=.fe4a3a28-4d57-479d-beaf-7b27265c3cd2@github.com>

On Wed, 8 Feb 2023 15:31:15 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

>> After finding a hash match, getEntryPos needs to compare the lookup name up to the encoded entry name in the CEN. This comparison is done by decoding the entry name into a String. The names can then be compared using the String API. This decoding step adds a significat cost to this method.
>> 
>> This PR suggest to update the string comparison such that in the common case where  both the lookup name and the entry name are encoded in ASCII-compatible UTF-8,  decoding can be avoided and the byte arrays can instead be compared direcly. 
>> 
>> ZipCoder is updated with a new method to compare a string with an encoded byte array range.  The default implementation decodes to string (like the current code), while the UTF-8 implementation uses JavaLangAccess.getBytesNoRepl to get the  bytes. Both methods thes uses Arrays.mismatch for comparison with or without matching trailing slashes. 
>> 
>> Additionally, this PR suggest to make the following updates to getEntryPos:
>> 
>> - The try/catch for IAE is redundant and can be safely removed. (initCEN already checks this and will throws IAE for invalid UTF-8). This seems to give a 3-4% speedup on micros)
>> - A new test InvalidBytesInEntryNameOrComment is a added to verify that initCEN does in fact reject invalid UTF-8 in CEN file names and comments. (I found no existing test coverage for this)
>> - The recursion when looking for "name/" matches is replaced with iteration. We keep track of any "name/" match and return it at the end of the search. (I feel this is easier to follow and it also gives a ~30% speedup for addSlash lookups with no regression on regular lookups)
>> 
>> (My though is that including these additional updates in this PR might reduce reviewer overhead given that it touches the exact same code. I might be wrong on this, please advise :)
>> 
>> I'm seeing a ~17% saving on the micro ZipFileGetEntry.getEntryHit (modified to use xalan.jar):
>> 
>> Baseline:
>> 
>> Benchmark                             (size)  Mode  Cnt    Score   Error  Units
>> ZipFileGetEntry.getEntryHit              512  avgt   15   74.941 ? 1.004  ns/op
>> ZipFileGetEntry.getEntryHit             1024  avgt   15   84.943 ? 1.320  ns/op
>> ZipFileGetEntry.getEntryHitUncached      512  avgt   15  120.371 ? 2.386  ns/op
>> ZipFileGetEntry.getEntryHitUncached     1024  avgt   15  126.128 ? 1.075  ns/op
>> ZipFileGetEntry.getEntryMiss             512  avgt   15   23.818 ? 0.838  ns/op
>> ZipFileGetEntry.getEntryMiss            1024  avgt   15   29.762 ? 5.998  ns/op
>> ZipFileGetEntry.getEntryMissUncached     512  avgt   15   59.405 ? 0.545  ns/op
>> ZipFileGetEntry.getEntryMissUncached    1024  avgt   15   71.840 ? 2.455  ns/op
>> ZipFileGetEntry.getEntrySlash            512  avgt   15  135.621 ? 4.341  ns/op
>> ZipFileGetEntry.getEntrySlash           1024  avgt   15  134.190 ? 2.141  ns/op
>> 
>> 
>> 
>> PR:
>> 
>> 
>> Benchmark                             (size)  Mode  Cnt    Score   Error  Units
>> ZipFileGetEntry.getEntryHit              512  avgt   15   62.267 ? 1.329  ns/op
>> ZipFileGetEntry.getEntryHit             1024  avgt   15   72.916 ? 2.428  ns/op
>> ZipFileGetEntry.getEntryHitUncached      512  avgt   15  101.630 ? 1.154  ns/op
>> ZipFileGetEntry.getEntryHitUncached     1024  avgt   15  113.161 ? 0.502  ns/op
>> ZipFileGetEntry.getEntryMiss             512  avgt   15   23.003 ? 1.191  ns/op
>> ZipFileGetEntry.getEntryMiss            1024  avgt   15   23.236 ? 1.114  ns/op
>> ZipFileGetEntry.getEntryMissUncached     512  avgt   15   56.781 ? 1.505  ns/op
>> ZipFileGetEntry.getEntryMissUncached    1024  avgt   15   67.767 ? 1.963  ns/op
>> ZipFileGetEntry.getEntrySlash            512  avgt   15   73.745 ? 2.717  ns/op
>> ZipFileGetEntry.getEntrySlash           1024  avgt   15   75.784 ? 1.051  ns/op
>> 
>> 
>> To assess the impact on startup/warmup, I made a main method class which measures the total time of calling ZipFile.getEntry for all entries in the 109 JAR file dependenies of spring-petclinic. The shows a nice improvement (time in micros):
>> 
>> 
>> Percentile Baseline Patch
>> 50?%          23155 21149
>> 75?%          23598 21454
>> 90?%          23989 21691
>> 95?%          24238 21973
>> 99?%          25270 22446
>> STDEV           792   549
>> Count           500   500
>
> Eirik Bjorsnos has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Align entry name whitespace

Good! Would it be too much to ask for you to try and construct such a test for UTF-8 zip files, too?

-------------

PR: https://git.openjdk.org/jdk/pull/12290

From duke at openjdk.org  Wed Feb  8 16:13:48 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Wed, 8 Feb 2023 16:13:48 GMT
Subject: RFR: 8301873: Avoid string decoding in ZipFile.Source.getEntryPos
 [v6]
In-Reply-To: <vTxPmgWhY7d0vEzsOz2UvKZFEX_gSfTKliIJ_I0uoiE=.8fc025cf-4711-4b63-ac34-e7cb903e0724@github.com>
References: <FkmdspiHVjkAKFqm5kUgwaf55YH5cBbczS_3krqsdFs=.05eca901-f55f-47d9-b1bc-0cf2f5b87536@github.com>
 <vTxPmgWhY7d0vEzsOz2UvKZFEX_gSfTKliIJ_I0uoiE=.8fc025cf-4711-4b63-ac34-e7cb903e0724@github.com>
Message-ID: <AEoobdQsuST985cOZ8RUT3pvoXmpYSnqFd0lz4X51LU=.32bd787a-7ae7-4db4-8cfc-2f8f45de8b2f@github.com>

On Wed, 8 Feb 2023 15:31:15 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

>> After finding a hash match, getEntryPos needs to compare the lookup name up to the encoded entry name in the CEN. This comparison is done by decoding the entry name into a String. The names can then be compared using the String API. This decoding step adds a significat cost to this method.
>> 
>> This PR suggest to update the string comparison such that in the common case where  both the lookup name and the entry name are encoded in ASCII-compatible UTF-8,  decoding can be avoided and the byte arrays can instead be compared direcly. 
>> 
>> ZipCoder is updated with a new method to compare a string with an encoded byte array range.  The default implementation decodes to string (like the current code), while the UTF-8 implementation uses JavaLangAccess.getBytesNoRepl to get the  bytes. Both methods thes uses Arrays.mismatch for comparison with or without matching trailing slashes. 
>> 
>> Additionally, this PR suggest to make the following updates to getEntryPos:
>> 
>> - The try/catch for IAE is redundant and can be safely removed. (initCEN already checks this and will throws IAE for invalid UTF-8). This seems to give a 3-4% speedup on micros)
>> - A new test InvalidBytesInEntryNameOrComment is a added to verify that initCEN does in fact reject invalid UTF-8 in CEN file names and comments. (I found no existing test coverage for this)
>> - The recursion when looking for "name/" matches is replaced with iteration. We keep track of any "name/" match and return it at the end of the search. (I feel this is easier to follow and it also gives a ~30% speedup for addSlash lookups with no regression on regular lookups)
>> 
>> (My though is that including these additional updates in this PR might reduce reviewer overhead given that it touches the exact same code. I might be wrong on this, please advise :)
>> 
>> I'm seeing a ~17% saving on the micro ZipFileGetEntry.getEntryHit (modified to use xalan.jar):
>> 
>> Baseline:
>> 
>> Benchmark                             (size)  Mode  Cnt    Score   Error  Units
>> ZipFileGetEntry.getEntryHit              512  avgt   15   74.941 ? 1.004  ns/op
>> ZipFileGetEntry.getEntryHit             1024  avgt   15   84.943 ? 1.320  ns/op
>> ZipFileGetEntry.getEntryHitUncached      512  avgt   15  120.371 ? 2.386  ns/op
>> ZipFileGetEntry.getEntryHitUncached     1024  avgt   15  126.128 ? 1.075  ns/op
>> ZipFileGetEntry.getEntryMiss             512  avgt   15   23.818 ? 0.838  ns/op
>> ZipFileGetEntry.getEntryMiss            1024  avgt   15   29.762 ? 5.998  ns/op
>> ZipFileGetEntry.getEntryMissUncached     512  avgt   15   59.405 ? 0.545  ns/op
>> ZipFileGetEntry.getEntryMissUncached    1024  avgt   15   71.840 ? 2.455  ns/op
>> ZipFileGetEntry.getEntrySlash            512  avgt   15  135.621 ? 4.341  ns/op
>> ZipFileGetEntry.getEntrySlash           1024  avgt   15  134.190 ? 2.141  ns/op
>> 
>> 
>> 
>> PR:
>> 
>> 
>> Benchmark                             (size)  Mode  Cnt    Score   Error  Units
>> ZipFileGetEntry.getEntryHit              512  avgt   15   62.267 ? 1.329  ns/op
>> ZipFileGetEntry.getEntryHit             1024  avgt   15   72.916 ? 2.428  ns/op
>> ZipFileGetEntry.getEntryHitUncached      512  avgt   15  101.630 ? 1.154  ns/op
>> ZipFileGetEntry.getEntryHitUncached     1024  avgt   15  113.161 ? 0.502  ns/op
>> ZipFileGetEntry.getEntryMiss             512  avgt   15   23.003 ? 1.191  ns/op
>> ZipFileGetEntry.getEntryMiss            1024  avgt   15   23.236 ? 1.114  ns/op
>> ZipFileGetEntry.getEntryMissUncached     512  avgt   15   56.781 ? 1.505  ns/op
>> ZipFileGetEntry.getEntryMissUncached    1024  avgt   15   67.767 ? 1.963  ns/op
>> ZipFileGetEntry.getEntrySlash            512  avgt   15   73.745 ? 2.717  ns/op
>> ZipFileGetEntry.getEntrySlash           1024  avgt   15   75.784 ? 1.051  ns/op
>> 
>> 
>> To assess the impact on startup/warmup, I made a main method class which measures the total time of calling ZipFile.getEntry for all entries in the 109 JAR file dependenies of spring-petclinic. The shows a nice improvement (time in micros):
>> 
>> 
>> Percentile Baseline Patch
>> 50?%          23155 21149
>> 75?%          23598 21454
>> 90?%          23989 21691
>> 95?%          24238 21973
>> 99?%          25270 22446
>> STDEV           792   549
>> Count           500   500
>
> Eirik Bjorsnos has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Align entry name whitespace

It takes unicode-charsets as a DataProvider input parameter, so that should already be covered? Or did you mean something else?

-------------

PR: https://git.openjdk.org/jdk/pull/12290

From duke at openjdk.org  Wed Feb  8 16:36:16 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Wed, 8 Feb 2023 16:36:16 GMT
Subject: RFR: 8301873: Avoid string decoding in ZipFile.Source.getEntryPos
 [v7]
In-Reply-To: <FkmdspiHVjkAKFqm5kUgwaf55YH5cBbczS_3krqsdFs=.05eca901-f55f-47d9-b1bc-0cf2f5b87536@github.com>
References: <FkmdspiHVjkAKFqm5kUgwaf55YH5cBbczS_3krqsdFs=.05eca901-f55f-47d9-b1bc-0cf2f5b87536@github.com>
Message-ID: <CF983B0JFz9rFPwtQZ-C9QpBYlpm3pfOpvD9pSstLL0=.daf6286d-59d9-4450-aff8-ad003199bd50@github.com>

> After finding a hash match, getEntryPos needs to compare the lookup name up to the encoded entry name in the CEN. This comparison is done by decoding the entry name into a String. The names can then be compared using the String API. This decoding step adds a significat cost to this method.
> 
> This PR suggest to update the string comparison such that in the common case where  both the lookup name and the entry name are encoded in ASCII-compatible UTF-8,  decoding can be avoided and the byte arrays can instead be compared direcly. 
> 
> ZipCoder is updated with a new method to compare a string with an encoded byte array range.  The default implementation decodes to string (like the current code), while the UTF-8 implementation uses JavaLangAccess.getBytesNoRepl to get the  bytes. Both methods thes uses Arrays.mismatch for comparison with or without matching trailing slashes. 
> 
> Additionally, this PR suggest to make the following updates to getEntryPos:
> 
> - The try/catch for IAE is redundant and can be safely removed. (initCEN already checks this and will throws IAE for invalid UTF-8). This seems to give a 3-4% speedup on micros)
> - A new test InvalidBytesInEntryNameOrComment is a added to verify that initCEN does in fact reject invalid UTF-8 in CEN file names and comments. (I found no existing test coverage for this)
> - The recursion when looking for "name/" matches is replaced with iteration. We keep track of any "name/" match and return it at the end of the search. (I feel this is easier to follow and it also gives a ~30% speedup for addSlash lookups with no regression on regular lookups)
> 
> (My though is that including these additional updates in this PR might reduce reviewer overhead given that it touches the exact same code. I might be wrong on this, please advise :)
> 
> I'm seeing a ~17% saving on the micro ZipFileGetEntry.getEntryHit (modified to use xalan.jar):
> 
> Baseline:
> 
> Benchmark                             (size)  Mode  Cnt    Score   Error  Units
> ZipFileGetEntry.getEntryHit              512  avgt   15   74.941 ? 1.004  ns/op
> ZipFileGetEntry.getEntryHit             1024  avgt   15   84.943 ? 1.320  ns/op
> ZipFileGetEntry.getEntryHitUncached      512  avgt   15  120.371 ? 2.386  ns/op
> ZipFileGetEntry.getEntryHitUncached     1024  avgt   15  126.128 ? 1.075  ns/op
> ZipFileGetEntry.getEntryMiss             512  avgt   15   23.818 ? 0.838  ns/op
> ZipFileGetEntry.getEntryMiss            1024  avgt   15   29.762 ? 5.998  ns/op
> ZipFileGetEntry.getEntryMissUncached     512  avgt   15   59.405 ? 0.545  ns/op
> ZipFileGetEntry.getEntryMissUncached    1024  avgt   15   71.840 ? 2.455  ns/op
> ZipFileGetEntry.getEntrySlash            512  avgt   15  135.621 ? 4.341  ns/op
> ZipFileGetEntry.getEntrySlash           1024  avgt   15  134.190 ? 2.141  ns/op
> 
> 
> 
> PR:
> 
> 
> Benchmark                             (size)  Mode  Cnt    Score   Error  Units
> ZipFileGetEntry.getEntryHit              512  avgt   15   62.267 ? 1.329  ns/op
> ZipFileGetEntry.getEntryHit             1024  avgt   15   72.916 ? 2.428  ns/op
> ZipFileGetEntry.getEntryHitUncached      512  avgt   15  101.630 ? 1.154  ns/op
> ZipFileGetEntry.getEntryHitUncached     1024  avgt   15  113.161 ? 0.502  ns/op
> ZipFileGetEntry.getEntryMiss             512  avgt   15   23.003 ? 1.191  ns/op
> ZipFileGetEntry.getEntryMiss            1024  avgt   15   23.236 ? 1.114  ns/op
> ZipFileGetEntry.getEntryMissUncached     512  avgt   15   56.781 ? 1.505  ns/op
> ZipFileGetEntry.getEntryMissUncached    1024  avgt   15   67.767 ? 1.963  ns/op
> ZipFileGetEntry.getEntrySlash            512  avgt   15   73.745 ? 2.717  ns/op
> ZipFileGetEntry.getEntrySlash           1024  avgt   15   75.784 ? 1.051  ns/op
> 
> 
> To assess the impact on startup/warmup, I made a main method class which measures the total time of calling ZipFile.getEntry for all entries in the 109 JAR file dependenies of spring-petclinic. The shows a nice improvement (time in micros):
> 
> 
> Percentile Baseline Patch
> 50?%          23155 21149
> 75?%          23598 21454
> 90?%          23989 21691
> 95?%          24238 21973
> 99?%          25270 22446
> STDEV           792   549
> Count           500   500

Eirik Bjorsnos has updated the pull request incrementally with one additional commit since the last revision:

  Update the sameHashAndLengthDirLookup to use ASCII example colliding paths, allowing the test to run over all charsets

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12290/files
  - new: https://git.openjdk.org/jdk/pull/12290/files/ac7c4c7a..3cb77dba

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12290&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12290&range=05-06

  Stats: 13 lines in 1 file changed: 8 ins; 1 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/12290.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12290/head:pull/12290

PR: https://git.openjdk.org/jdk/pull/12290

From duke at openjdk.org  Wed Feb  8 16:37:45 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Wed, 8 Feb 2023 16:37:45 GMT
Subject: RFR: 8301873: Avoid string decoding in ZipFile.Source.getEntryPos
 [v6]
In-Reply-To: <vTxPmgWhY7d0vEzsOz2UvKZFEX_gSfTKliIJ_I0uoiE=.8fc025cf-4711-4b63-ac34-e7cb903e0724@github.com>
References: <FkmdspiHVjkAKFqm5kUgwaf55YH5cBbczS_3krqsdFs=.05eca901-f55f-47d9-b1bc-0cf2f5b87536@github.com>
 <vTxPmgWhY7d0vEzsOz2UvKZFEX_gSfTKliIJ_I0uoiE=.8fc025cf-4711-4b63-ac34-e7cb903e0724@github.com>
Message-ID: <ur4Jy5k_buUe0RYJ-5JMmJ42JWlpEYpZnIXzrqIjYxo=.641f67bf-fe3f-4e7b-87fc-4610f76d183e@github.com>

On Wed, 8 Feb 2023 15:31:15 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

>> After finding a hash match, getEntryPos needs to compare the lookup name up to the encoded entry name in the CEN. This comparison is done by decoding the entry name into a String. The names can then be compared using the String API. This decoding step adds a significat cost to this method.
>> 
>> This PR suggest to update the string comparison such that in the common case where  both the lookup name and the entry name are encoded in ASCII-compatible UTF-8,  decoding can be avoided and the byte arrays can instead be compared direcly. 
>> 
>> ZipCoder is updated with a new method to compare a string with an encoded byte array range.  The default implementation decodes to string (like the current code), while the UTF-8 implementation uses JavaLangAccess.getBytesNoRepl to get the  bytes. Both methods thes uses Arrays.mismatch for comparison with or without matching trailing slashes. 
>> 
>> Additionally, this PR suggest to make the following updates to getEntryPos:
>> 
>> - The try/catch for IAE is redundant and can be safely removed. (initCEN already checks this and will throws IAE for invalid UTF-8). This seems to give a 3-4% speedup on micros)
>> - A new test InvalidBytesInEntryNameOrComment is a added to verify that initCEN does in fact reject invalid UTF-8 in CEN file names and comments. (I found no existing test coverage for this)
>> - The recursion when looking for "name/" matches is replaced with iteration. We keep track of any "name/" match and return it at the end of the search. (I feel this is easier to follow and it also gives a ~30% speedup for addSlash lookups with no regression on regular lookups)
>> 
>> (My though is that including these additional updates in this PR might reduce reviewer overhead given that it touches the exact same code. I might be wrong on this, please advise :)
>> 
>> I'm seeing a ~17% saving on the micro ZipFileGetEntry.getEntryHit (modified to use xalan.jar):
>> 
>> Baseline:
>> 
>> Benchmark                             (size)  Mode  Cnt    Score   Error  Units
>> ZipFileGetEntry.getEntryHit              512  avgt   15   74.941 ? 1.004  ns/op
>> ZipFileGetEntry.getEntryHit             1024  avgt   15   84.943 ? 1.320  ns/op
>> ZipFileGetEntry.getEntryHitUncached      512  avgt   15  120.371 ? 2.386  ns/op
>> ZipFileGetEntry.getEntryHitUncached     1024  avgt   15  126.128 ? 1.075  ns/op
>> ZipFileGetEntry.getEntryMiss             512  avgt   15   23.818 ? 0.838  ns/op
>> ZipFileGetEntry.getEntryMiss            1024  avgt   15   29.762 ? 5.998  ns/op
>> ZipFileGetEntry.getEntryMissUncached     512  avgt   15   59.405 ? 0.545  ns/op
>> ZipFileGetEntry.getEntryMissUncached    1024  avgt   15   71.840 ? 2.455  ns/op
>> ZipFileGetEntry.getEntrySlash            512  avgt   15  135.621 ? 4.341  ns/op
>> ZipFileGetEntry.getEntrySlash           1024  avgt   15  134.190 ? 2.141  ns/op
>> 
>> 
>> 
>> PR:
>> 
>> 
>> Benchmark                             (size)  Mode  Cnt    Score   Error  Units
>> ZipFileGetEntry.getEntryHit              512  avgt   15   62.267 ? 1.329  ns/op
>> ZipFileGetEntry.getEntryHit             1024  avgt   15   72.916 ? 2.428  ns/op
>> ZipFileGetEntry.getEntryHitUncached      512  avgt   15  101.630 ? 1.154  ns/op
>> ZipFileGetEntry.getEntryHitUncached     1024  avgt   15  113.161 ? 0.502  ns/op
>> ZipFileGetEntry.getEntryMiss             512  avgt   15   23.003 ? 1.191  ns/op
>> ZipFileGetEntry.getEntryMiss            1024  avgt   15   23.236 ? 1.114  ns/op
>> ZipFileGetEntry.getEntryMissUncached     512  avgt   15   56.781 ? 1.505  ns/op
>> ZipFileGetEntry.getEntryMissUncached    1024  avgt   15   67.767 ? 1.963  ns/op
>> ZipFileGetEntry.getEntrySlash            512  avgt   15   73.745 ? 2.717  ns/op
>> ZipFileGetEntry.getEntrySlash           1024  avgt   15   75.784 ? 1.051  ns/op
>> 
>> 
>> To assess the impact on startup/warmup, I made a main method class which measures the total time of calling ZipFile.getEntry for all entries in the 109 JAR file dependenies of spring-petclinic. The shows a nice improvement (time in micros):
>> 
>> 
>> Percentile Baseline Patch
>> 50?%          23155 21149
>> 75?%          23598 21454
>> 90?%          23989 21691
>> 95?%          24238 21973
>> 99?%          25270 22446
>> STDEV           792   549
>> Count           500   500
>
> Eirik Bjorsnos has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Align entry name whitespace

I found the following ASCII, same length, hash code colliding dir names which we can use instead:


_____1637461950/
_____-408231241/


This allows the test to run with all charsets. Fails for all charsets expect UTF-8.

-------------

PR: https://git.openjdk.org/jdk/pull/12290

From bpb at openjdk.org  Wed Feb  8 17:06:45 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 8 Feb 2023 17:06:45 GMT
Subject: RFR: JDK-8301833: Add manual tests for FDLIBM porting
In-Reply-To: <wgghXoOC-eICroAklhQSO8UYEBvYHF_QHZ4C_1wnW0Q=.61574f1b-9c40-4c34-b234-502b95a99c8f@github.com>
References: <wgghXoOC-eICroAklhQSO8UYEBvYHF_QHZ4C_1wnW0Q=.61574f1b-9c40-4c34-b234-502b95a99c8f@github.com>
Message-ID: <RF0w6Cvm2hocVc90_IdRLgxJGdzmUuO9ARmdO6o8L08=.b2764a09-8bf9-4c83-a9b4-f76eae318f5e@github.com>

On Mon, 6 Feb 2023 01:50:55 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> To help add assurances that the main-line port of FDLIBM to Java is working correctly, added some long-running manual tests to probe that the transliteration port and the corresponding StrictMath method are in agreement on a large number of argument, say, all float values.
> 
> To test the transliteration port, this test can be run against a build where the JDK has *not* had the FDLIBM code used for StrictMath ported to Java.

test/jdk/java/lang/StrictMath/ExhaustingTests.java line 37:

> 35: import java.util.function.DoubleUnaryOperator;
> 36: 
> 37: public class ExhaustingTests {

Great name!

test/jdk/java/lang/StrictMath/ExhaustingTests.java line 57:

> 55:         long failures = 0;
> 56:         UnaryTestCase[] testCases = {
> 57:          // new UnaryTestCase("sqrt",  FdlibmTranslit::sqrt,  StrictMath::sqrt),

Maybe not include the TBD cases as part of this initial PR?

-------------

PR: https://git.openjdk.org/jdk/pull/12430

From bpb at openjdk.org  Wed Feb  8 17:09:46 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 8 Feb 2023 17:09:46 GMT
Subject: RFR: JDK-8301833: Add manual tests for FDLIBM porting
In-Reply-To: <wgghXoOC-eICroAklhQSO8UYEBvYHF_QHZ4C_1wnW0Q=.61574f1b-9c40-4c34-b234-502b95a99c8f@github.com>
References: <wgghXoOC-eICroAklhQSO8UYEBvYHF_QHZ4C_1wnW0Q=.61574f1b-9c40-4c34-b234-502b95a99c8f@github.com>
Message-ID: <CXogMUa8ML0q03IJ20khcMHzDIxIm5wMJlil1hmdFE0=.da31ffc6-3cbf-4f11-837e-154ca49c0fee@github.com>

On Mon, 6 Feb 2023 01:50:55 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> To help add assurances that the main-line port of FDLIBM to Java is working correctly, added some long-running manual tests to probe that the transliteration port and the corresponding StrictMath method are in agreement on a large number of argument, say, all float values.
> 
> To test the transliteration port, this test can be run against a build where the JDK has *not* had the FDLIBM code used for StrictMath ported to Java.

test/jdk/java/lang/StrictMath/FdlibmTranslit.java line 89:

> 87:     }
> 88: 
> 89:     public static double exp(double x) {

Perhaps leave out of this PR any `FdlibmTranslit` changes and later include `ExhaustingTest` changes in each separate PR for the functions being ported?

-------------

PR: https://git.openjdk.org/jdk/pull/12430

From redestad at openjdk.org  Wed Feb  8 17:14:49 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Wed, 8 Feb 2023 17:14:49 GMT
Subject: RFR: 8301873: Avoid string decoding in ZipFile.Source.getEntryPos
 [v7]
In-Reply-To: <CF983B0JFz9rFPwtQZ-C9QpBYlpm3pfOpvD9pSstLL0=.daf6286d-59d9-4450-aff8-ad003199bd50@github.com>
References: <FkmdspiHVjkAKFqm5kUgwaf55YH5cBbczS_3krqsdFs=.05eca901-f55f-47d9-b1bc-0cf2f5b87536@github.com>
 <CF983B0JFz9rFPwtQZ-C9QpBYlpm3pfOpvD9pSstLL0=.daf6286d-59d9-4450-aff8-ad003199bd50@github.com>
Message-ID: <UtYLuRh41GSxGd_bTdsRYI1xW9iRaC4sze06kZbOoVE=.51701b73-2223-45d9-96d6-62f718501b7d@github.com>

On Wed, 8 Feb 2023 16:36:16 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

>> After finding a hash match, getEntryPos needs to compare the lookup name up to the encoded entry name in the CEN. This comparison is done by decoding the entry name into a String. The names can then be compared using the String API. This decoding step adds a significat cost to this method.
>> 
>> This PR suggest to update the string comparison such that in the common case where  both the lookup name and the entry name are encoded in ASCII-compatible UTF-8,  decoding can be avoided and the byte arrays can instead be compared direcly. 
>> 
>> ZipCoder is updated with a new method to compare a string with an encoded byte array range.  The default implementation decodes to string (like the current code), while the UTF-8 implementation uses JavaLangAccess.getBytesNoRepl to get the  bytes. Both methods thes uses Arrays.mismatch for comparison with or without matching trailing slashes. 
>> 
>> Additionally, this PR suggest to make the following updates to getEntryPos:
>> 
>> - The try/catch for IAE is redundant and can be safely removed. (initCEN already checks this and will throws IAE for invalid UTF-8). This seems to give a 3-4% speedup on micros)
>> - A new test InvalidBytesInEntryNameOrComment is a added to verify that initCEN does in fact reject invalid UTF-8 in CEN file names and comments. (I found no existing test coverage for this)
>> - The recursion when looking for "name/" matches is replaced with iteration. We keep track of any "name/" match and return it at the end of the search. (I feel this is easier to follow and it also gives a ~30% speedup for addSlash lookups with no regression on regular lookups)
>> 
>> (My though is that including these additional updates in this PR might reduce reviewer overhead given that it touches the exact same code. I might be wrong on this, please advise :)
>> 
>> I'm seeing a ~17% saving on the micro ZipFileGetEntry.getEntryHit (modified to use xalan.jar):
>> 
>> Baseline:
>> 
>> Benchmark                             (size)  Mode  Cnt    Score   Error  Units
>> ZipFileGetEntry.getEntryHit              512  avgt   15   74.941 ? 1.004  ns/op
>> ZipFileGetEntry.getEntryHit             1024  avgt   15   84.943 ? 1.320  ns/op
>> ZipFileGetEntry.getEntryHitUncached      512  avgt   15  120.371 ? 2.386  ns/op
>> ZipFileGetEntry.getEntryHitUncached     1024  avgt   15  126.128 ? 1.075  ns/op
>> ZipFileGetEntry.getEntryMiss             512  avgt   15   23.818 ? 0.838  ns/op
>> ZipFileGetEntry.getEntryMiss            1024  avgt   15   29.762 ? 5.998  ns/op
>> ZipFileGetEntry.getEntryMissUncached     512  avgt   15   59.405 ? 0.545  ns/op
>> ZipFileGetEntry.getEntryMissUncached    1024  avgt   15   71.840 ? 2.455  ns/op
>> ZipFileGetEntry.getEntrySlash            512  avgt   15  135.621 ? 4.341  ns/op
>> ZipFileGetEntry.getEntrySlash           1024  avgt   15  134.190 ? 2.141  ns/op
>> 
>> 
>> 
>> PR:
>> 
>> 
>> Benchmark                             (size)  Mode  Cnt    Score   Error  Units
>> ZipFileGetEntry.getEntryHit              512  avgt   15   62.267 ? 1.329  ns/op
>> ZipFileGetEntry.getEntryHit             1024  avgt   15   72.916 ? 2.428  ns/op
>> ZipFileGetEntry.getEntryHitUncached      512  avgt   15  101.630 ? 1.154  ns/op
>> ZipFileGetEntry.getEntryHitUncached     1024  avgt   15  113.161 ? 0.502  ns/op
>> ZipFileGetEntry.getEntryMiss             512  avgt   15   23.003 ? 1.191  ns/op
>> ZipFileGetEntry.getEntryMiss            1024  avgt   15   23.236 ? 1.114  ns/op
>> ZipFileGetEntry.getEntryMissUncached     512  avgt   15   56.781 ? 1.505  ns/op
>> ZipFileGetEntry.getEntryMissUncached    1024  avgt   15   67.767 ? 1.963  ns/op
>> ZipFileGetEntry.getEntrySlash            512  avgt   15   73.745 ? 2.717  ns/op
>> ZipFileGetEntry.getEntrySlash           1024  avgt   15   75.784 ? 1.051  ns/op
>> 
>> 
>> To assess the impact on startup/warmup, I made a main method class which measures the total time of calling ZipFile.getEntry for all entries in the 109 JAR file dependenies of spring-petclinic. The shows a nice improvement (time in micros):
>> 
>> 
>> Percentile Baseline Patch
>> 50?%          23155 21149
>> 75?%          23598 21454
>> 90?%          23989 21691
>> 95?%          24238 21973
>> 99?%          25270 22446
>> STDEV           792   549
>> Count           500   500
>
> Eirik Bjorsnos has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update the sameHashAndLengthDirLookup to use ASCII example colliding paths, allowing the test to run over all charsets

Marked as reviewed by redestad (Reviewer).

Great! Extending coverage to provoke the issue on most charsets is good, and it should guard UTF-8 from regressing too - no?

-------------

PR: https://git.openjdk.org/jdk/pull/12290

From mullan at openjdk.org  Wed Feb  8 17:19:47 2023
From: mullan at openjdk.org (Sean Mullan)
Date: Wed, 8 Feb 2023 17:19:47 GMT
Subject: RFR: JDK-8301462: Convert Permission files to use lambda after
 JDK-8076596 [v2]
In-Reply-To: <pJX2oOarrhU6mm0oJY5pH7avyZlRmVnGQSulKKFA1dM=.fe116030-80ed-4b7f-9ed4-33dd04f2d4ab@github.com>
References: <HVWMALUhjljFTe0W9OlvK7CfpFgg4z3Um8V6ChTHA18=.cf1fb1d5-3594-4e97-beb6-144b6a726bf0@github.com>
 <pJX2oOarrhU6mm0oJY5pH7avyZlRmVnGQSulKKFA1dM=.fe116030-80ed-4b7f-9ed4-33dd04f2d4ab@github.com>
Message-ID: <NIFg7DQ_mPMwxcSTPevek9jhYkKB6Svo98Wa4HeP5U4=.234ed2cf-cae4-4f4d-817d-d94e4366656c@github.com>

On Wed, 8 Feb 2023 03:42:16 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> A trivial fix.   Convert the use of anonymous inner classes in a few Permission classes to lambdas to work around JDK-8076596, which has been resolved.
>
> Mandy Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update copyright end year

There's also one in `FilePermission.add()` that can be changed to use a lambda.

-------------

PR: https://git.openjdk.org/jdk/pull/12463

From duke at openjdk.org  Wed Feb  8 17:30:43 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Wed, 8 Feb 2023 17:30:43 GMT
Subject: RFR: 8301873: Avoid string decoding in ZipFile.Source.getEntryPos
 [v7]
In-Reply-To: <UtYLuRh41GSxGd_bTdsRYI1xW9iRaC4sze06kZbOoVE=.51701b73-2223-45d9-96d6-62f718501b7d@github.com>
References: <FkmdspiHVjkAKFqm5kUgwaf55YH5cBbczS_3krqsdFs=.05eca901-f55f-47d9-b1bc-0cf2f5b87536@github.com>
 <CF983B0JFz9rFPwtQZ-C9QpBYlpm3pfOpvD9pSstLL0=.daf6286d-59d9-4450-aff8-ad003199bd50@github.com>
 <UtYLuRh41GSxGd_bTdsRYI1xW9iRaC4sze06kZbOoVE=.51701b73-2223-45d9-96d6-62f718501b7d@github.com>
Message-ID: <aDHFmaqv42qeRmcp9e5-9ajabhwUNcl_e-sJXUvoVhA=.5a238942-0eab-4f6b-a53d-4d80101a3b7e@github.com>

On Wed, 8 Feb 2023 17:11:19 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> Great! Extending coverage to provoke the issue on most charsets is good, and it should guard UTF-8 from regressing too - no?

It also guards UTFZipCoder from this particular regression, yes.

-------------

PR: https://git.openjdk.org/jdk/pull/12290

From mchung at openjdk.org  Wed Feb  8 17:58:13 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Wed, 8 Feb 2023 17:58:13 GMT
Subject: RFR: JDK-8301462: Convert Permission files to use lambda after
 JDK-8076596 [v2]
In-Reply-To: <pJX2oOarrhU6mm0oJY5pH7avyZlRmVnGQSulKKFA1dM=.fe116030-80ed-4b7f-9ed4-33dd04f2d4ab@github.com>
References: <HVWMALUhjljFTe0W9OlvK7CfpFgg4z3Um8V6ChTHA18=.cf1fb1d5-3594-4e97-beb6-144b6a726bf0@github.com>
 <pJX2oOarrhU6mm0oJY5pH7avyZlRmVnGQSulKKFA1dM=.fe116030-80ed-4b7f-9ed4-33dd04f2d4ab@github.com>
Message-ID: <K3RW1It4GTRPCb9qfy8PVqB78BORzLeOYEqB3XWKPjU=.e8abf94e-c9b5-49db-a4d7-19e0f264a34f@github.com>

On Wed, 8 Feb 2023 03:42:16 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> A trivial fix.   Convert the use of anonymous inner classes in a few Permission classes to lambdas to work around JDK-8076596, which has been resolved.
>
> Mandy Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update copyright end year

Updated `FilePermissionCollection::add` to use lambda.

-------------

PR: https://git.openjdk.org/jdk/pull/12463

From mchung at openjdk.org  Wed Feb  8 17:58:12 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Wed, 8 Feb 2023 17:58:12 GMT
Subject: RFR: JDK-8301462: Convert Permission files to use lambda after
 JDK-8076596 [v3]
In-Reply-To: <HVWMALUhjljFTe0W9OlvK7CfpFgg4z3Um8V6ChTHA18=.cf1fb1d5-3594-4e97-beb6-144b6a726bf0@github.com>
References: <HVWMALUhjljFTe0W9OlvK7CfpFgg4z3Um8V6ChTHA18=.cf1fb1d5-3594-4e97-beb6-144b6a726bf0@github.com>
Message-ID: <3zcZe9XAcX58dk8lhaHt6rbVH5xeUdNvm9IY7E2NsCs=.e4878f30-ea16-4e56-a55e-1d66e064d230@github.com>

> A trivial fix.   Convert the use of anonymous inner classes in a few Permission classes to lambdas to work around JDK-8076596, which has been resolved.

Mandy Chung 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:

 - Update FilePermission::add to use lambda
 - Merge branch 'master' of https://github.com/openjdk/jdk into JDK-8301462
 - update copyright end year
 - JDK-8301462: Convert Permission files to use lambda after JDK-8076596

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12463/files
  - new: https://git.openjdk.org/jdk/pull/12463/files/627da759..a4d03d02

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12463&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12463&range=01-02

  Stats: 15980 lines in 457 files changed: 9564 ins; 3402 del; 3014 mod
  Patch: https://git.openjdk.org/jdk/pull/12463.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12463/head:pull/12463

PR: https://git.openjdk.org/jdk/pull/12463

From mullan at openjdk.org  Wed Feb  8 18:07:44 2023
From: mullan at openjdk.org (Sean Mullan)
Date: Wed, 8 Feb 2023 18:07:44 GMT
Subject: RFR: JDK-8301462: Convert Permission files to use lambda after
 JDK-8076596 [v3]
In-Reply-To: <3zcZe9XAcX58dk8lhaHt6rbVH5xeUdNvm9IY7E2NsCs=.e4878f30-ea16-4e56-a55e-1d66e064d230@github.com>
References: <HVWMALUhjljFTe0W9OlvK7CfpFgg4z3Um8V6ChTHA18=.cf1fb1d5-3594-4e97-beb6-144b6a726bf0@github.com>
 <3zcZe9XAcX58dk8lhaHt6rbVH5xeUdNvm9IY7E2NsCs=.e4878f30-ea16-4e56-a55e-1d66e064d230@github.com>
Message-ID: <TdW3moticMbV7_idodOFxMjXdceZBCT4_VDgUSVKc4M=.45e7eb1a-9afb-46fc-b1aa-ed5646fc2fa0@github.com>

On Wed, 8 Feb 2023 17:58:12 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> A trivial fix.   Convert the use of anonymous inner classes in a few Permission classes to lambdas to work around JDK-8076596, which has been resolved.
>
> Mandy Chung 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:
> 
>  - Update FilePermission::add to use lambda
>  - Merge branch 'master' of https://github.com/openjdk/jdk into JDK-8301462
>  - update copyright end year
>  - JDK-8301462: Convert Permission files to use lambda after JDK-8076596

Marked as reviewed by mullan (Reviewer).

Bug needs a `noreg` label.

-------------

PR: https://git.openjdk.org/jdk/pull/12463

From darcy at openjdk.org  Wed Feb  8 18:38:46 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 8 Feb 2023 18:38:46 GMT
Subject: RFR: JDK-8301444: Port fdlibm hyperbolic transcendental functions
 to Java [v3]
In-Reply-To: <MyH3dC3PiO1_qR9BoCMo3G-E-TfO4cwHdoC75iwTB5A=.dd75623a-6ae7-4ab0-b352-9b0e605102f6@github.com>
References: <_s8xnppoDTnAajAjlmfB-dX5DBdawUcSSPaGWGLzFBk=.cdbf468a-ace7-45e5-a25a-833c760b776c@github.com>
 <HoCaJ-zkReSJFfNp11mlphGXA2jVJLQW_hZisTm7bhE=.561a6b8c-69e8-439e-bbcb-e19286e313d5@github.com>
 <MyH3dC3PiO1_qR9BoCMo3G-E-TfO4cwHdoC75iwTB5A=.dd75623a-6ae7-4ab0-b352-9b0e605102f6@github.com>
Message-ID: <-UCygtAYXJCvT_-2lO-4v9exCW5hwIasaSGEOl7Pe-0=.d720415e-e098-46d1-bb20-1e98bbec1222@github.com>

On Tue, 7 Feb 2023 16:02:19 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Correct overflow limit in regression test.
>
> src/java.base/share/classes/java/lang/FdLibm.java line 1215:
> 
>> 1213:      *      only sinh(0)=0 is exact for finite x.
>> 1214:      */
>> 1215:     static class Sinh {
> 
> For clarity, should this not be declared `final`?

Hmm. Wouldn't hurt to do so.

I was thinking of making a pass over Fdlibm.java at some point to make sure the nested classes had package-level rather than public accessibility and that the classes had private constructors that threw an exception (to prevent instantiation).

-------------

PR: https://git.openjdk.org/jdk/pull/12429

From ihse at openjdk.org  Wed Feb  8 18:42:45 2023
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 8 Feb 2023 18:42:45 GMT
Subject: RFR: JDK-8301444: Port fdlibm hyperbolic transcendental functions
 to Java [v3]
In-Reply-To: <-UCygtAYXJCvT_-2lO-4v9exCW5hwIasaSGEOl7Pe-0=.d720415e-e098-46d1-bb20-1e98bbec1222@github.com>
References: <_s8xnppoDTnAajAjlmfB-dX5DBdawUcSSPaGWGLzFBk=.cdbf468a-ace7-45e5-a25a-833c760b776c@github.com>
 <HoCaJ-zkReSJFfNp11mlphGXA2jVJLQW_hZisTm7bhE=.561a6b8c-69e8-439e-bbcb-e19286e313d5@github.com>
 <MyH3dC3PiO1_qR9BoCMo3G-E-TfO4cwHdoC75iwTB5A=.dd75623a-6ae7-4ab0-b352-9b0e605102f6@github.com>
 <-UCygtAYXJCvT_-2lO-4v9exCW5hwIasaSGEOl7Pe-0=.d720415e-e098-46d1-bb20-1e98bbec1222@github.com>
Message-ID: <HjwUpx8IccO0zVtSAun5CnMvfIWjxH7_iGUKudYC0o8=.1441a777-6dd0-481d-9a41-4a07f500c4e4@github.com>

On Wed, 8 Feb 2023 18:35:51 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/FdLibm.java line 1215:
>> 
>>> 1213:      *      only sinh(0)=0 is exact for finite x.
>>> 1214:      */
>>> 1215:     static class Sinh {
>> 
>> For clarity, should this not be declared `final`?
>
> Hmm. Wouldn't hurt to do so.
> 
> I was thinking of making a pass over Fdlibm.java at some point to make sure the nested classes had package-level rather than public accessibility and that the classes had private constructors that threw an exception (to prevent instantiation).

It doesn't matter much. It was just a drive-by comment; I don't normally look at this part of the code but the PR title attracted my attention (it is not everyday you see hyperbolic transcendental PRs in the JDK), and when I skimmed through the code, some reflex part of my brain said "utility classes should be final".

-------------

PR: https://git.openjdk.org/jdk/pull/12429

From mchung at openjdk.org  Wed Feb  8 19:09:56 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Wed, 8 Feb 2023 19:09:56 GMT
Subject: Integrated: JDK-8301462: Convert Permission files to use lambda after
 JDK-8076596
In-Reply-To: <HVWMALUhjljFTe0W9OlvK7CfpFgg4z3Um8V6ChTHA18=.cf1fb1d5-3594-4e97-beb6-144b6a726bf0@github.com>
References: <HVWMALUhjljFTe0W9OlvK7CfpFgg4z3Um8V6ChTHA18=.cf1fb1d5-3594-4e97-beb6-144b6a726bf0@github.com>
Message-ID: <l3qiqASNhBGpwiyHc-1q5J5uL_zHU9UDu5DJX9luH0o=.213ec531-3d2b-45f1-8a83-1ffa8afbc7f9@github.com>

On Tue, 7 Feb 2023 22:25:43 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> A trivial fix.   Convert the use of anonymous inner classes in a few Permission classes to lambdas to work around JDK-8076596, which has been resolved.

This pull request has now been integrated.

Changeset: 10dd98d0
Author:    Mandy Chung <mchung at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/10dd98d0dd6aeb6f214999590ed19707a203f591
Stats:     98 lines in 5 files changed: 4 ins; 37 del; 57 mod

8301462: Convert Permission files to use lambda after JDK-8076596

Reviewed-by: jpai, dfuchs, mullan

-------------

PR: https://git.openjdk.org/jdk/pull/12463

From smarks at openjdk.org  Wed Feb  8 19:31:47 2023
From: smarks at openjdk.org (Stuart Marks)
Date: Wed, 8 Feb 2023 19:31:47 GMT
Subject: RFR: 8296935: Arrays.asList().set() with wrong types throws
 undocumented ArrayStoreException [v7]
In-Reply-To: <ZZurFel-Py9rfobJ9aOTKXiN91B7h72kQMFoZWTPvU0=.930c0c30-a314-4992-805b-95237333defd@github.com>
References: <9JFNgXqBSj9uR8vR9oIooJMxtf74y12L0-GbjOO7fJg=.769953c2-40f3-49c0-8598-ce940d2d95d4@github.com>
 <ZZurFel-Py9rfobJ9aOTKXiN91B7h72kQMFoZWTPvU0=.930c0c30-a314-4992-805b-95237333defd@github.com>
Message-ID: <rLYVL8Hj-XTyGIjn2kwwCNiZcjrQLnlxUvpZtUskCO4=.d615d171-4064-4c1f-bc06-529b431e3479@github.com>

On Mon, 23 Jan 2023 07:33:21 GMT, Tingjun Yuan <duke at openjdk.org> wrote:

>> Document `java.util.Arrays.asList` that the list will throw an `ArrayStoreException` when attempting to set an element with a wrong type.
>
> Tingjun Yuan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update `implSpec` and remove the docs of the impl.

I've added my recommended text for an apiNote as a comment in the bug report:

https://bugs.openjdk.org/browse/JDK-8296935?focusedCommentId=14555728&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14555728

Even though this is non-normative text, I'd say it still requires a CSR to document the decision that this issue is NOT a conformance issue. That is, even though the various List methods are documented to throw certain runtime exceptions in various circumstances, an implementation is permitted to throw other runtime exceptions without violating the specification. The flip side is that it's good practice for method specifications to specify what exceptions are thrown in what circumstances, but it's not required for them to specify all exceptions in all circumstances. Indeed, in this specific case, it seems unreasonable to add throwing of ArrayStoreException to all the List methods because of this one edge case of this particular implementation.

-------------

PR: https://git.openjdk.org/jdk/pull/12135

From darcy at openjdk.org  Wed Feb  8 19:44:06 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 8 Feb 2023 19:44:06 GMT
Subject: RFR: JDK-8301444: Port fdlibm hyperbolic transcendental functions
 to Java [v4]
In-Reply-To: <_s8xnppoDTnAajAjlmfB-dX5DBdawUcSSPaGWGLzFBk=.cdbf468a-ace7-45e5-a25a-833c760b776c@github.com>
References: <_s8xnppoDTnAajAjlmfB-dX5DBdawUcSSPaGWGLzFBk=.cdbf468a-ace7-45e5-a25a-833c760b776c@github.com>
Message-ID: <8b7sd9ZU1mcLOwuWyJFEU6cfyBlyeN0dIiXIzTIiJPA=.37d45489-31da-45c2-bfca-08b2b8ae122f@github.com>

> Initial pass of porting FDLIBM sinh/cosh/tanh to Java. I do intend to refactor the regression tests a bit to reduce duplication, but the actual ports should be ready for review.
> 
> Diff'ing the ports as before, original vs transliteration port:
> 
> 
> $ diff -w Hyperbolic.c Hyperbolic.translit.java
> 1c1
> < /* __ieee754_sinh(x)
> ---
>>     /**
> 17a18,19
>>     static class Sinh {
>>         private static final double one = 1.0, shuge = 1.0e307;
> 19,33c21
> < #include "fdlibm.h"
> < 
> < #ifdef __STDC__
> < static const double one = 1.0, shuge = 1.0e307;
> < #else
> < static double one = 1.0, shuge = 1.0e307;
> < #endif
> < 
> < #ifdef __STDC__
> <         double __ieee754_sinh(double x)
> < #else
> <         double __ieee754_sinh(x)
> <         double x;
> < #endif
> < {
> ---
>>         private static double compute(double x) {
> 36c24
> <         unsigned lx;
> ---
>>             /* unsigned */ int lx;
> 51c39
> <             t = expm1(fabs(x));
> ---
>>                 t = FdlibmTranslit.expm1(Math.abs(x));
> 57c45
> <         if (ix < 0x40862E42)  return h*__ieee754_exp(fabs(x));
> ---
>>             if (ix < 0x40862E42)  return h*StrictMath.exp(Math.abs(x)); // TODO switch to translit
> 60,62c48,52
> <         lx = *( (((*(unsigned*)&one)>>29)) + (unsigned*)&x);
> <         if (ix<0x408633CE || ((ix==0x408633ce)&&(lx<=(unsigned)0x8fb9f87d))) {
> <             w = __ieee754_exp(0.5*fabs(x));
> ---
>>             // lx = *( (((*(unsigned*)&one)>>29)) + (unsigned*)&x);
>>             // lx =  (((*(unsigned*)&one)>>29)) + (unsigned*)&x ;
>>             lx = __LO(x);
>>             if (ix<0x408633CE || ((ix==0x408633ce)&&(Long.compareUnsigned(lx, 0x8fb9f87d) <= 0 ))) {
>>                 w = StrictMath.exp(0.5*Math.abs(x)); // TODO switch to translit
> 70c60,62
> < /* __ieee754_cosh(x)
> ---
>>     }
>> 
>>     /**
> 90,105c82,84
> < 
> < #include "fdlibm.h"
> < 
> < #ifdef __STDC__
> < static const double one = 1.0, half=0.5, huge = 1.0e300;
> < #else
> < static double one = 1.0, half=0.5, huge = 1.0e300;
> < #endif
> < 
> < #ifdef __STDC__
> <         double __ieee754_cosh(double x)
> < #else
> <         double __ieee754_cosh(x)
> <         double x;
> < #endif
> < {
> ---
>>     static class Cosh {
>>         private static final double one = 1.0, half=0.5, huge = 1.0e300;
>>         private static double compute(double x) {
> 108c87
> <         unsigned lx;
> ---
>>             /*unsigned*/ int lx;
> 119c98
> <             t = expm1(fabs(x));
> ---
>>                 t = expm1(Math.abs(x));
> 127c106
> <                 t = __ieee754_exp(fabs(x));
> ---
>>                 t = StrictMath.exp(Math.abs(x)); // TODO switch to translit
> 132c111
> <         if (ix < 0x40862E42)  return half*__ieee754_exp(fabs(x));
> ---
>>             if (ix < 0x40862E42)  return half*StrictMath.exp(Math.abs(x)); // TODO switch to translit
> 135c114
> <         lx = *( (((*(unsigned*)&one)>>29)) + (unsigned*)&x);
> ---
>>             lx = __LO(x);
> 137,138c116,117
> <               ((ix==0x408633ce)&&(lx<=(unsigned)0x8fb9f87d))) {
> <             w = __ieee754_exp(half*fabs(x));
> ---
>>                 ((ix==0x408633ce)&&(Integer.compareUnsigned(lx, 0x8fb9f87d) <= 0))) {
>>                 w = StrictMath.exp(half*Math.abs(x)); // TODO switch to translit
> 146c125,127
> < /* Tanh(x)
> ---
>>     }
>> 
>>     /**
> 169,184c150,152
> < 
> < #include "fdlibm.h"
> < 
> < #ifdef __STDC__
> < static const double one=1.0, two=2.0, tiny = 1.0e-300;
> < #else
> < static double one=1.0, two=2.0, tiny = 1.0e-300;
> < #endif
> < 
> < #ifdef __STDC__
> <         double tanh(double x)
> < #else
> <         double tanh(x)
> <         double x;
> < #endif
> < {
> ---
>>     static class Tanh {
>>         private static final double one=1.0, two=2.0, tiny = 1.0e-300;
>>         static double compute(double x) {
> 203c171
> <                 t = expm1(two*fabs(x));
> ---
>>                     t = expm1(two*Math.abs(x));
> 206c174
> <                 t = expm1(-two*fabs(x));
> ---
>>                     t = expm1(-two*Math.abs(x));
> 214a183
>>     }
> 
> 
> Note that the original has a in-line version of the "__LO" macro rather than using the macro.
> 
> 
> And transliteration vs more idiomatic:
> 
> 
> $ diff -w Hyperbolic.translit.java Hyperbolic.fdlibm.java 
> 21c21
> <         private static double compute(double x) {
> ---
>>          static double compute(double x) {
> 26c26
> <             /* High word of |x|. */
> ---
>>             // High word of |x|
> 28c28
> <             ix = jx&0x7fffffff;
> ---
>>             ix = jx & 0x7fff_ffff;
> 30,31c30,33
> <             /* x is INF or NaN */
> <             if(ix>=0x7ff00000) return x+x;
> ---
>>             // x is INF or NaN
>>             if ( ix >= 0x7ff0_0000) {
>>                 return x + x;
>>             }
> 34,40c36,48
> <             if (jx<0) h = -h;
> <             /* |x| in [0,22], return sign(x)*0.5*(E+E/(E+1))) */
> <             if (ix < 0x40360000) {          /* |x|<22 */
> <                 if (ix<0x3e300000)          /* |x|<2**-28 */
> <                     if(shuge+x>one) return x;/* sinh(tiny) = tiny with inexact */
> <                 t = FdlibmTranslit.expm1(Math.abs(x));
> <                 if(ix<0x3ff00000) return h*(2.0*t-t*t/(t+one));
> ---
>>             if ( jx < 0) {
>>                 h = -h;
>>             }
>>             // |x| in [0,22], return sign(x)*0.5*(E+E/(E+1)))
>>             if (ix < 0x4036_0000) {          // |x| < 22
>>                 if (ix < 0x3e30_0000)        // |x| < 2**-28
>>                     if (shuge + x > one) {   // sinh(tiny) = tiny with inexact
>>                         return x;
>>                     }
>>                 t = StrictMath.expm1(Math.abs(x));
>>                 if (ix < 0x3ff0_0000) {
>>                     return h*(2.0 * t - t*t/(t + one));
>>                 }
> 44,45c52,55
> <             /* |x| in [22, log(maxdouble)] return 0.5*exp(|x|) */
> <             if (ix < 0x40862E42)  return h*StrictMath.exp(Math.abs(x)); // TODO switch to translit
> ---
>>             // |x| in [22, log(maxdouble)] return 0.5*exp(|x|)
>>             if (ix < 0x4086_2E42) {
>>                 return h*StrictMath.exp(Math.abs(x));
>>             }
> 47,49c57
> <             /* |x| in [log(maxdouble), overflowthresold] */
> <             // lx = *( (((*(unsigned*)&one)>>29)) + (unsigned*)&x);
> <             // lx =  (((*(unsigned*)&one)>>29)) + (unsigned*)&x ;
> ---
>>             // |x| in [log(maxdouble), overflowthresold]
> 51,52c59,62
> <             if (ix<0x408633CE || ((ix==0x408633ce)&&(Long.compareUnsigned(lx, 0x8fb9f87d) <= 0 ))) {
> <                 w = StrictMath.exp(0.5*Math.abs(x)); // TODO switch to translit
> ---
>>             if (ix < 0x4086_33CE ||
>>                 ((ix == 0x4086_33ce) &&
>>                  (Long.compareUnsigned(lx, 0x8fb9_f87d) <= 0 ))) {
>>                 w = StrictMath.exp(0.5 * Math.abs(x));
> 57c67
> <             /* |x| > overflowthresold, sinh(x) overflow */
> ---
>>             // |x| > overflowthresold, sinh(x) overflow
> 84c94
> <         private static double compute(double x) {
> ---
>>         static double compute(double x) {
> 89c99
> <             /* High word of |x|. */
> ---
>>             // High word of |x|
> 91c101
> <             ix &= 0x7fffffff;
> ---
>>             ix &= 0x7fff_ffff;
> 93,94c103,106
> <             /* x is INF or NaN */
> <             if(ix>=0x7ff00000) return x*x;
> ---
>>             // x is INF or NaN
>>             if (ix >= 0x7ff_00000) {
>>                 return x*x;
>>             }
> 96,98c108,110
> <             /* |x| in [0,0.5*ln2], return 1+expm1(|x|)^2/(2*exp(|x|)) */
> <             if(ix<0x3fd62e43) {
> <                 t = expm1(Math.abs(x));
> ---
>>             // |x| in [0,0.5*ln2], return 1+expm1(|x|)^2/(2*exp(|x|))
>>             if (ix < 0x3fd6_2e43) {
>>                 t = StrictMath.expm1(Math.abs(x));
> 100c112,114
> <                 if (ix<0x3c800000) return w;        /* cosh(tiny) = 1 */
> ---
>>                 if (ix < 0x3c80_0000) { // cosh(tiny) = 1
>>                     return w;
>>                 }
> 104,106c118,120
> <             /* |x| in [0.5*ln2,22], return (exp(|x|)+1/exp(|x|)/2; */
> <             if (ix < 0x40360000) {
> <                 t = StrictMath.exp(Math.abs(x)); // TODO switch to translit
> ---
>>             // |x| in [0.5*ln2, 22], return (exp(|x|) + 1/exp(|x|)/2
>>             if (ix < 0x4036_0000) {
>>                 t = StrictMath.exp(Math.abs(x));
> 110,111c124,127
> <             /* |x| in [22, log(maxdouble)] return half*exp(|x|) */
> <             if (ix < 0x40862E42)  return half*StrictMath.exp(Math.abs(x)); // TODO switch to translit
> ---
>>             // |x| in [22, log(maxdouble)] return half*exp(|x|)
>>             if (ix < 0x4086_2E42) {
>>                 return half*StrictMath.exp(Math.abs(x));
>>             }
> 113c129
> <             /* |x| in [log(maxdouble), overflowthresold] */
> ---
>>             // |x| in [log(maxdouble), overflowthresold]
> 115,117c131,134
> <             if (ix<0x408633CE ||
> <                 ((ix==0x408633ce)&&(Integer.compareUnsigned(lx, 0x8fb9f87d) <= 0))) {
> <                 w = StrictMath.exp(half*Math.abs(x)); // TODO switch to translit
> ---
>>             if (ix<0x4086_33CE ||
>>                 ((ix == 0x4086_33ce) &&
>>                  (Integer.compareUnsigned(lx, 0x8fb9_f87d) <= 0))) {
>>                 w = StrictMath.exp(half*Math.abs(x));
> 122c139
> <             /* |x| > overflowthresold, cosh(x) overflow */
> ---
>>             // |x| > overflowthresold, cosh(x) overflow
> 126d142
> < 
> 156c172
> <             /* High word of |x|. */
> ---
>>             // High word of |x|.
> 158c174
> <             ix = jx&0x7fffffff;
> ---
>>             ix = jx & 0x7fff_ffff;
> 160,163c176,182
> <             /* x is INF or NaN */
> <             if(ix>=0x7ff00000) {
> <                 if (jx>=0) return one/x+one;    /* tanh(+-inf)=+-1 */
> <                 else       return one/x-one;    /* tanh(NaN) = NaN */
> ---
>>             // x is INF or NaN
>>             if (ix >= 0x7ff0_0000) {
>>                 if (jx >= 0) {  // tanh(+-inf)=+-1
>>                     return one/x + one;
>>                 } else {        // tanh(NaN) = NaN
>>                     return one/x - one;
>>                 }
> 166,171c185,190
> <             /* |x| < 22 */
> <             if (ix < 0x40360000) {          /* |x|<22 */
> <                 if (ix<0x3c800000)          /* |x|<2**-55 */
> <                     return x*(one+x);       /* tanh(small) = small */
> <                 if (ix>=0x3ff00000) {       /* |x|>=1  */
> <                     t = expm1(two*Math.abs(x));
> ---
>>             // |x| < 22
>>             if (ix < 0x4036_0000) {          // |x| < 22
>>                 if (ix<0x3c80_0000)          // |x| < 2**-55
>>                     return x*(one + x);      // tanh(small) = small
>>                 if (ix>=0x3ff0_0000) {       // |x| >= 1
>>                     t = StrictMath.expm1(two*Math.abs(x));
> 174c193
> <                     t = expm1(-two*Math.abs(x));
> ---
>>                     t = StrictMath.expm1(-two*Math.abs(x));
> 177,179c196,197
> <                 /* |x| > 22, return +-1 */
> <             } else {
> <                 z = one - tiny;             /* raised inexact flag */
> ---
>>             } else { // |x| > 22, return +-1
>>                 z = one - tiny;             // raised inexact flag

Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:

  Respond to review feedback.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12429/files
  - new: https://git.openjdk.org/jdk/pull/12429/files/420f119d..3987146f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12429&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12429&range=02-03

  Stats: 22 lines in 2 files changed: 13 ins; 0 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/12429.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12429/head:pull/12429

PR: https://git.openjdk.org/jdk/pull/12429

From darcy at openjdk.org  Wed Feb  8 19:45:49 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 8 Feb 2023 19:45:49 GMT
Subject: RFR: JDK-8301444: Port fdlibm hyperbolic transcendental functions
 to Java [v3]
In-Reply-To: <HjwUpx8IccO0zVtSAun5CnMvfIWjxH7_iGUKudYC0o8=.1441a777-6dd0-481d-9a41-4a07f500c4e4@github.com>
References: <_s8xnppoDTnAajAjlmfB-dX5DBdawUcSSPaGWGLzFBk=.cdbf468a-ace7-45e5-a25a-833c760b776c@github.com>
 <HoCaJ-zkReSJFfNp11mlphGXA2jVJLQW_hZisTm7bhE=.561a6b8c-69e8-439e-bbcb-e19286e313d5@github.com>
 <MyH3dC3PiO1_qR9BoCMo3G-E-TfO4cwHdoC75iwTB5A=.dd75623a-6ae7-4ab0-b352-9b0e605102f6@github.com>
 <-UCygtAYXJCvT_-2lO-4v9exCW5hwIasaSGEOl7Pe-0=.d720415e-e098-46d1-bb20-1e98bbec1222@github.com>
 <HjwUpx8IccO0zVtSAun5CnMvfIWjxH7_iGUKudYC0o8=.1441a777-6dd0-481d-9a41-4a07f500c4e4@github.com>
Message-ID: <bG1wDDesfeacMVj_a3KyqFIPM7qPG-qT023Ozg16UEc=.31e8a120-6047-49c1-8102-959ab73d7e0d@github.com>

On Wed, 8 Feb 2023 18:39:42 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Hmm. Wouldn't hurt to do so.
>> 
>> I was thinking of making a pass over Fdlibm.java at some point to make sure the nested classes had package-level rather than public accessibility and that the classes had private constructors that threw an exception (to prevent instantiation).
>
> It doesn't matter much. It was just a drive-by comment; I don't normally look at this part of the code but the PR title attracted my attention (it is not everyday you see hyperbolic transcendental PRs in the JDK), and when I skimmed through the code, some reflex part of my brain said "utility classes should be final".

Changed the nested classes for the hyperbolic functions to be final and added a private constructor.

-------------

PR: https://git.openjdk.org/jdk/pull/12429

From darcy at openjdk.org  Wed Feb  8 19:51:19 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 8 Feb 2023 19:51:19 GMT
Subject: RFR: JDK-8301444: Port fdlibm hyperbolic transcendental functions
 to Java [v5]
In-Reply-To: <_s8xnppoDTnAajAjlmfB-dX5DBdawUcSSPaGWGLzFBk=.cdbf468a-ace7-45e5-a25a-833c760b776c@github.com>
References: <_s8xnppoDTnAajAjlmfB-dX5DBdawUcSSPaGWGLzFBk=.cdbf468a-ace7-45e5-a25a-833c760b776c@github.com>
Message-ID: <PZRaIrHDmCIEvvN4oMXWkCN03ToVecsK6CGGMZSiC_8=.8a2bb246-485d-48e6-b21f-fcd63d9df1fa@github.com>

> Initial pass of porting FDLIBM sinh/cosh/tanh to Java. I do intend to refactor the regression tests a bit to reduce duplication, but the actual ports should be ready for review.
> 
> Diff'ing the ports as before, original vs transliteration port:
> 
> 
> $ diff -w Hyperbolic.c Hyperbolic.translit.java
> 1c1
> < /* __ieee754_sinh(x)
> ---
>>     /**
> 17a18,19
>>     static class Sinh {
>>         private static final double one = 1.0, shuge = 1.0e307;
> 19,33c21
> < #include "fdlibm.h"
> < 
> < #ifdef __STDC__
> < static const double one = 1.0, shuge = 1.0e307;
> < #else
> < static double one = 1.0, shuge = 1.0e307;
> < #endif
> < 
> < #ifdef __STDC__
> <         double __ieee754_sinh(double x)
> < #else
> <         double __ieee754_sinh(x)
> <         double x;
> < #endif
> < {
> ---
>>         private static double compute(double x) {
> 36c24
> <         unsigned lx;
> ---
>>             /* unsigned */ int lx;
> 51c39
> <             t = expm1(fabs(x));
> ---
>>                 t = FdlibmTranslit.expm1(Math.abs(x));
> 57c45
> <         if (ix < 0x40862E42)  return h*__ieee754_exp(fabs(x));
> ---
>>             if (ix < 0x40862E42)  return h*StrictMath.exp(Math.abs(x)); // TODO switch to translit
> 60,62c48,52
> <         lx = *( (((*(unsigned*)&one)>>29)) + (unsigned*)&x);
> <         if (ix<0x408633CE || ((ix==0x408633ce)&&(lx<=(unsigned)0x8fb9f87d))) {
> <             w = __ieee754_exp(0.5*fabs(x));
> ---
>>             // lx = *( (((*(unsigned*)&one)>>29)) + (unsigned*)&x);
>>             // lx =  (((*(unsigned*)&one)>>29)) + (unsigned*)&x ;
>>             lx = __LO(x);
>>             if (ix<0x408633CE || ((ix==0x408633ce)&&(Long.compareUnsigned(lx, 0x8fb9f87d) <= 0 ))) {
>>                 w = StrictMath.exp(0.5*Math.abs(x)); // TODO switch to translit
> 70c60,62
> < /* __ieee754_cosh(x)
> ---
>>     }
>> 
>>     /**
> 90,105c82,84
> < 
> < #include "fdlibm.h"
> < 
> < #ifdef __STDC__
> < static const double one = 1.0, half=0.5, huge = 1.0e300;
> < #else
> < static double one = 1.0, half=0.5, huge = 1.0e300;
> < #endif
> < 
> < #ifdef __STDC__
> <         double __ieee754_cosh(double x)
> < #else
> <         double __ieee754_cosh(x)
> <         double x;
> < #endif
> < {
> ---
>>     static class Cosh {
>>         private static final double one = 1.0, half=0.5, huge = 1.0e300;
>>         private static double compute(double x) {
> 108c87
> <         unsigned lx;
> ---
>>             /*unsigned*/ int lx;
> 119c98
> <             t = expm1(fabs(x));
> ---
>>                 t = expm1(Math.abs(x));
> 127c106
> <                 t = __ieee754_exp(fabs(x));
> ---
>>                 t = StrictMath.exp(Math.abs(x)); // TODO switch to translit
> 132c111
> <         if (ix < 0x40862E42)  return half*__ieee754_exp(fabs(x));
> ---
>>             if (ix < 0x40862E42)  return half*StrictMath.exp(Math.abs(x)); // TODO switch to translit
> 135c114
> <         lx = *( (((*(unsigned*)&one)>>29)) + (unsigned*)&x);
> ---
>>             lx = __LO(x);
> 137,138c116,117
> <               ((ix==0x408633ce)&&(lx<=(unsigned)0x8fb9f87d))) {
> <             w = __ieee754_exp(half*fabs(x));
> ---
>>                 ((ix==0x408633ce)&&(Integer.compareUnsigned(lx, 0x8fb9f87d) <= 0))) {
>>                 w = StrictMath.exp(half*Math.abs(x)); // TODO switch to translit
> 146c125,127
> < /* Tanh(x)
> ---
>>     }
>> 
>>     /**
> 169,184c150,152
> < 
> < #include "fdlibm.h"
> < 
> < #ifdef __STDC__
> < static const double one=1.0, two=2.0, tiny = 1.0e-300;
> < #else
> < static double one=1.0, two=2.0, tiny = 1.0e-300;
> < #endif
> < 
> < #ifdef __STDC__
> <         double tanh(double x)
> < #else
> <         double tanh(x)
> <         double x;
> < #endif
> < {
> ---
>>     static class Tanh {
>>         private static final double one=1.0, two=2.0, tiny = 1.0e-300;
>>         static double compute(double x) {
> 203c171
> <                 t = expm1(two*fabs(x));
> ---
>>                     t = expm1(two*Math.abs(x));
> 206c174
> <                 t = expm1(-two*fabs(x));
> ---
>>                     t = expm1(-two*Math.abs(x));
> 214a183
>>     }
> 
> 
> Note that the original has a in-line version of the "__LO" macro rather than using the macro.
> 
> 
> And transliteration vs more idiomatic:
> 
> 
> $ diff -w Hyperbolic.translit.java Hyperbolic.fdlibm.java 
> 21c21
> <         private static double compute(double x) {
> ---
>>          static double compute(double x) {
> 26c26
> <             /* High word of |x|. */
> ---
>>             // High word of |x|
> 28c28
> <             ix = jx&0x7fffffff;
> ---
>>             ix = jx & 0x7fff_ffff;
> 30,31c30,33
> <             /* x is INF or NaN */
> <             if(ix>=0x7ff00000) return x+x;
> ---
>>             // x is INF or NaN
>>             if ( ix >= 0x7ff0_0000) {
>>                 return x + x;
>>             }
> 34,40c36,48
> <             if (jx<0) h = -h;
> <             /* |x| in [0,22], return sign(x)*0.5*(E+E/(E+1))) */
> <             if (ix < 0x40360000) {          /* |x|<22 */
> <                 if (ix<0x3e300000)          /* |x|<2**-28 */
> <                     if(shuge+x>one) return x;/* sinh(tiny) = tiny with inexact */
> <                 t = FdlibmTranslit.expm1(Math.abs(x));
> <                 if(ix<0x3ff00000) return h*(2.0*t-t*t/(t+one));
> ---
>>             if ( jx < 0) {
>>                 h = -h;
>>             }
>>             // |x| in [0,22], return sign(x)*0.5*(E+E/(E+1)))
>>             if (ix < 0x4036_0000) {          // |x| < 22
>>                 if (ix < 0x3e30_0000)        // |x| < 2**-28
>>                     if (shuge + x > one) {   // sinh(tiny) = tiny with inexact
>>                         return x;
>>                     }
>>                 t = StrictMath.expm1(Math.abs(x));
>>                 if (ix < 0x3ff0_0000) {
>>                     return h*(2.0 * t - t*t/(t + one));
>>                 }
> 44,45c52,55
> <             /* |x| in [22, log(maxdouble)] return 0.5*exp(|x|) */
> <             if (ix < 0x40862E42)  return h*StrictMath.exp(Math.abs(x)); // TODO switch to translit
> ---
>>             // |x| in [22, log(maxdouble)] return 0.5*exp(|x|)
>>             if (ix < 0x4086_2E42) {
>>                 return h*StrictMath.exp(Math.abs(x));
>>             }
> 47,49c57
> <             /* |x| in [log(maxdouble), overflowthresold] */
> <             // lx = *( (((*(unsigned*)&one)>>29)) + (unsigned*)&x);
> <             // lx =  (((*(unsigned*)&one)>>29)) + (unsigned*)&x ;
> ---
>>             // |x| in [log(maxdouble), overflowthresold]
> 51,52c59,62
> <             if (ix<0x408633CE || ((ix==0x408633ce)&&(Long.compareUnsigned(lx, 0x8fb9f87d) <= 0 ))) {
> <                 w = StrictMath.exp(0.5*Math.abs(x)); // TODO switch to translit
> ---
>>             if (ix < 0x4086_33CE ||
>>                 ((ix == 0x4086_33ce) &&
>>                  (Long.compareUnsigned(lx, 0x8fb9_f87d) <= 0 ))) {
>>                 w = StrictMath.exp(0.5 * Math.abs(x));
> 57c67
> <             /* |x| > overflowthresold, sinh(x) overflow */
> ---
>>             // |x| > overflowthresold, sinh(x) overflow
> 84c94
> <         private static double compute(double x) {
> ---
>>         static double compute(double x) {
> 89c99
> <             /* High word of |x|. */
> ---
>>             // High word of |x|
> 91c101
> <             ix &= 0x7fffffff;
> ---
>>             ix &= 0x7fff_ffff;
> 93,94c103,106
> <             /* x is INF or NaN */
> <             if(ix>=0x7ff00000) return x*x;
> ---
>>             // x is INF or NaN
>>             if (ix >= 0x7ff_00000) {
>>                 return x*x;
>>             }
> 96,98c108,110
> <             /* |x| in [0,0.5*ln2], return 1+expm1(|x|)^2/(2*exp(|x|)) */
> <             if(ix<0x3fd62e43) {
> <                 t = expm1(Math.abs(x));
> ---
>>             // |x| in [0,0.5*ln2], return 1+expm1(|x|)^2/(2*exp(|x|))
>>             if (ix < 0x3fd6_2e43) {
>>                 t = StrictMath.expm1(Math.abs(x));
> 100c112,114
> <                 if (ix<0x3c800000) return w;        /* cosh(tiny) = 1 */
> ---
>>                 if (ix < 0x3c80_0000) { // cosh(tiny) = 1
>>                     return w;
>>                 }
> 104,106c118,120
> <             /* |x| in [0.5*ln2,22], return (exp(|x|)+1/exp(|x|)/2; */
> <             if (ix < 0x40360000) {
> <                 t = StrictMath.exp(Math.abs(x)); // TODO switch to translit
> ---
>>             // |x| in [0.5*ln2, 22], return (exp(|x|) + 1/exp(|x|)/2
>>             if (ix < 0x4036_0000) {
>>                 t = StrictMath.exp(Math.abs(x));
> 110,111c124,127
> <             /* |x| in [22, log(maxdouble)] return half*exp(|x|) */
> <             if (ix < 0x40862E42)  return half*StrictMath.exp(Math.abs(x)); // TODO switch to translit
> ---
>>             // |x| in [22, log(maxdouble)] return half*exp(|x|)
>>             if (ix < 0x4086_2E42) {
>>                 return half*StrictMath.exp(Math.abs(x));
>>             }
> 113c129
> <             /* |x| in [log(maxdouble), overflowthresold] */
> ---
>>             // |x| in [log(maxdouble), overflowthresold]
> 115,117c131,134
> <             if (ix<0x408633CE ||
> <                 ((ix==0x408633ce)&&(Integer.compareUnsigned(lx, 0x8fb9f87d) <= 0))) {
> <                 w = StrictMath.exp(half*Math.abs(x)); // TODO switch to translit
> ---
>>             if (ix<0x4086_33CE ||
>>                 ((ix == 0x4086_33ce) &&
>>                  (Integer.compareUnsigned(lx, 0x8fb9_f87d) <= 0))) {
>>                 w = StrictMath.exp(half*Math.abs(x));
> 122c139
> <             /* |x| > overflowthresold, cosh(x) overflow */
> ---
>>             // |x| > overflowthresold, cosh(x) overflow
> 126d142
> < 
> 156c172
> <             /* High word of |x|. */
> ---
>>             // High word of |x|.
> 158c174
> <             ix = jx&0x7fffffff;
> ---
>>             ix = jx & 0x7fff_ffff;
> 160,163c176,182
> <             /* x is INF or NaN */
> <             if(ix>=0x7ff00000) {
> <                 if (jx>=0) return one/x+one;    /* tanh(+-inf)=+-1 */
> <                 else       return one/x-one;    /* tanh(NaN) = NaN */
> ---
>>             // x is INF or NaN
>>             if (ix >= 0x7ff0_0000) {
>>                 if (jx >= 0) {  // tanh(+-inf)=+-1
>>                     return one/x + one;
>>                 } else {        // tanh(NaN) = NaN
>>                     return one/x - one;
>>                 }
> 166,171c185,190
> <             /* |x| < 22 */
> <             if (ix < 0x40360000) {          /* |x|<22 */
> <                 if (ix<0x3c800000)          /* |x|<2**-55 */
> <                     return x*(one+x);       /* tanh(small) = small */
> <                 if (ix>=0x3ff00000) {       /* |x|>=1  */
> <                     t = expm1(two*Math.abs(x));
> ---
>>             // |x| < 22
>>             if (ix < 0x4036_0000) {          // |x| < 22
>>                 if (ix<0x3c80_0000)          // |x| < 2**-55
>>                     return x*(one + x);      // tanh(small) = small
>>                 if (ix>=0x3ff0_0000) {       // |x| >= 1
>>                     t = StrictMath.expm1(two*Math.abs(x));
> 174c193
> <                     t = expm1(-two*Math.abs(x));
> ---
>>                     t = StrictMath.expm1(-two*Math.abs(x));
> 177,179c196,197
> <                 /* |x| > 22, return +-1 */
> <             } else {
> <                 z = one - tiny;             /* raised inexact flag */
> ---
>>             } else { // |x| > 22, return +-1
>>                 z = one - tiny;             // raised inexact flag

Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:

  Add additional note.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12429/files
  - new: https://git.openjdk.org/jdk/pull/12429/files/3987146f..45d4247f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12429&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12429&range=03-04

  Stats: 3 lines in 1 file changed: 3 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/12429.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12429/head:pull/12429

PR: https://git.openjdk.org/jdk/pull/12429

From bchristi at openjdk.org  Wed Feb  8 19:55:51 2023
From: bchristi at openjdk.org (Brent Christian)
Date: Wed, 8 Feb 2023 19:55:51 GMT
Subject: RFR: 8283660: Convert
 com/sun/jndi/ldap/AbstractLdapNamingEnumeration.java finalizer to Cleaner
 [v16]
In-Reply-To: <eFt6SCXR1oCUa1Q2D7g8KIbx-_UsXJa5zU4xMvIjF8E=.e69adc7f-f489-4d77-917d-dfb4a0f73f27@github.com>
References: <anHLuO0INa29U7GueBX7ihMfveqROF8YXaT0KhPJjdQ=.1a650b8b-45fc-4142-96d4-25839a564b68@github.com>
 <eFt6SCXR1oCUa1Q2D7g8KIbx-_UsXJa5zU4xMvIjF8E=.e69adc7f-f489-4d77-917d-dfb4a0f73f27@github.com>
Message-ID: <h870qdSEHYRnk41w7QivldezK6H6fYX-VUoOoMeIb4w=.3f74ae1d-ea4a-4ef3-a84d-fd07b9ec8b4d@github.com>

On Fri, 22 Jul 2022 20:51:59 GMT, Brent Christian <bchristi at openjdk.org> wrote:

>> Please review this change to replace the finalizer in `AbstractLdapNamingEnumeration` with a Cleaner.
>> 
>> The pieces of state required for cleanup (`LdapCtx homeCtx`, `LdapResult res`, and `LdapClient enumClnt`) are moved to a static inner class . From there, the change is fairly mechanical.
>> 
>> Details of note: 
>> 1. Some operations need to change the state values (the update() method is probably the most interesting).
>> 2. Subclasses need to access `homeCtx`; I added a `homeCtx()` method to read `homeCtx` from the superclass's `state`.
>> 
>> The test case is based on a copy of `com/sun/jndi/ldap/blits/AddTests/AddNewEntry.java`. A more minimal test case might be possible, but this was done for expediency.
>> 
>> The test only confirms that the new Cleaner use does not keep the object reachable. It only tests `LdapSearchEnumeration` (not `LdapNamingEnumeration` or `LdapBindingEnumeration`, though all are subclasses of `AbstractLdapNamingEnumeration`). 
>> 
>> Thanks.
>
> Brent Christian has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove some more tabs

ever diligent,
"Are you still working on this?"
asks bridgekeeper bot

-------------

PR: https://git.openjdk.org/jdk/pull/8311

From darcy at openjdk.org  Wed Feb  8 20:28:45 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 8 Feb 2023 20:28:45 GMT
Subject: RFR: JDK-8301833: Add manual tests for FDLIBM porting
In-Reply-To: <CXogMUa8ML0q03IJ20khcMHzDIxIm5wMJlil1hmdFE0=.da31ffc6-3cbf-4f11-837e-154ca49c0fee@github.com>
References: <wgghXoOC-eICroAklhQSO8UYEBvYHF_QHZ4C_1wnW0Q=.61574f1b-9c40-4c34-b234-502b95a99c8f@github.com>
 <CXogMUa8ML0q03IJ20khcMHzDIxIm5wMJlil1hmdFE0=.da31ffc6-3cbf-4f11-837e-154ca49c0fee@github.com>
Message-ID: <PKMSP5bqBhIa7PgheCB6k0TC5kC_XpIcL_Vz9CVVZ6E=.98dd4036-19e3-4611-b9b9-89c711920fd4@github.com>

On Wed, 8 Feb 2023 17:07:22 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> To help add assurances that the main-line port of FDLIBM to Java is working correctly, added some long-running manual tests to probe that the transliteration port and the corresponding StrictMath method are in agreement on a large number of argument, say, all float values.
>> 
>> To test the transliteration port, this test can be run against a build where the JDK has *not* had the FDLIBM code used for StrictMath ported to Java.
>
> test/jdk/java/lang/StrictMath/FdlibmTranslit.java line 89:
> 
>> 87:     }
>> 88: 
>> 89:     public static double exp(double x) {
> 
> Perhaps leave out of this PR any `FdlibmTranslit` changes and later include `ExhaustingTest` changes in each separate PR for the functions being ported?

Okay; I'll roll the addition of the exp method into the PR for the hyperbolics since exp is used in the hyperbolics implementation.

-------------

PR: https://git.openjdk.org/jdk/pull/12430

From mchung at openjdk.org  Wed Feb  8 20:32:45 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Wed, 8 Feb 2023 20:32:45 GMT
Subject: RFR: JDK-8301704: Shorten the number of GCs in UnloadingTest.java
 to verify a class loader not being unloaded
In-Reply-To: <pv0oEP5U-Co6zuGoifzHLQyETQwAN6NcHc6amVut1s0=.bc189d68-e1f8-42a5-9837-7175ba5aad21@github.com>
References: <bdUKXSHJGqFT5OdTZgU21MwCcuP9aAkg3lIP3WQbyJY=.c41376be-4fc1-409c-a2c1-42f1d0b30aba@github.com>
 <pv0oEP5U-Co6zuGoifzHLQyETQwAN6NcHc6amVut1s0=.bc189d68-e1f8-42a5-9837-7175ba5aad21@github.com>
Message-ID: <EaQpeoVWeumHvfZJ8Fdem1Fw8ZWWv6NEhmhpSg5G74A=.47b7b77d-7423-4fdf-b9b3-6c430803fbba@github.com>

On Thu, 2 Feb 2023 22:19:07 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> `test/jdk/java/lang/invoke/defineHiddenClass/UnloadingTest.java` defines hidden classes and verify cases that a class loader is not unloaded using `ForceGC::wait`.    ForceGC::wait` defaults the timeout to 1000ms * jtreg timeout factor, which is designed to work well to expect an object being reclaimed, i.e. the boolean supplier returns true.   On the other hand, if the boolean supplier never returns true, the method returns after it timeouts which may be long depending on the timeout factor. 
>> 
>> This PR adds a variant of `ForceGC::wait` to take a timeout parameter and tests can specify the timeout to reduce the time it takes testing a strongly reachable object not being reclaimed.
>
> test/lib/jdk/test/lib/util/ForceGC.java line 73:
> 
>> 71:      *     if did not complete after the specified waiting time.
>> 72:      */
>> 73:     public static boolean wait(BooleanSupplier booleanSupplier, long timeout) {
> 
> Can the method name be changed to make it clear the timeout is not scaled by the TIMEOUT factor.
> (It would have been better if the original method name mentioned the timeout factor).
> How about,  `waitNoMoreThan`.

what about `waitFor`?

I also considered renaming the original method to something else to indicate that the timeout is scaled with jtreg timeout factor.   Now `wait(BooleanSupplier)` is equivalent to `wait` with timeout = 1000L * TIMEOUT_FACTOR) and the javadoc states the timeout, which seems okay to me.

-------------

PR: https://git.openjdk.org/jdk/pull/12392

From rriggs at openjdk.org  Wed Feb  8 20:45:43 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 8 Feb 2023 20:45:43 GMT
Subject: RFR: JDK-8301704: Shorten the number of GCs in UnloadingTest.java
 to verify a class loader not being unloaded
In-Reply-To: <EaQpeoVWeumHvfZJ8Fdem1Fw8ZWWv6NEhmhpSg5G74A=.47b7b77d-7423-4fdf-b9b3-6c430803fbba@github.com>
References: <bdUKXSHJGqFT5OdTZgU21MwCcuP9aAkg3lIP3WQbyJY=.c41376be-4fc1-409c-a2c1-42f1d0b30aba@github.com>
 <pv0oEP5U-Co6zuGoifzHLQyETQwAN6NcHc6amVut1s0=.bc189d68-e1f8-42a5-9837-7175ba5aad21@github.com>
 <EaQpeoVWeumHvfZJ8Fdem1Fw8ZWWv6NEhmhpSg5G74A=.47b7b77d-7423-4fdf-b9b3-6c430803fbba@github.com>
Message-ID: <udgYiBWpJbrPk0qsHvaYvKWhJGLAtLCwMwQJ3VwsUiM=.77151e0d-fbe2-4bc2-afe3-f7a92f9cf994@github.com>

On Wed, 8 Feb 2023 20:30:13 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> test/lib/jdk/test/lib/util/ForceGC.java line 73:
>> 
>>> 71:      *     if did not complete after the specified waiting time.
>>> 72:      */
>>> 73:     public static boolean wait(BooleanSupplier booleanSupplier, long timeout) {
>> 
>> Can the method name be changed to make it clear the timeout is not scaled by the TIMEOUT factor.
>> (It would have been better if the original method name mentioned the timeout factor).
>> How about,  `waitNoMoreThan`.
>
> what about `waitFor`?
> 
> I also considered renaming the original method to something else to indicate that the timeout is scaled with jtreg timeout factor.   Now `wait(BooleanSupplier)` is equivalent to `wait` with timeout = 1000L * TIMEOUT_FACTOR) and the javadoc states the timeout, which seems okay to me.

`waitFor` is fine, renaming the original method (and its uses) makes it higher overhead.

-------------

PR: https://git.openjdk.org/jdk/pull/12392

From darcy at openjdk.org  Wed Feb  8 20:51:19 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 8 Feb 2023 20:51:19 GMT
Subject: RFR: JDK-8301444: Port fdlibm hyperbolic transcendental functions
 to Java [v6]
In-Reply-To: <_s8xnppoDTnAajAjlmfB-dX5DBdawUcSSPaGWGLzFBk=.cdbf468a-ace7-45e5-a25a-833c760b776c@github.com>
References: <_s8xnppoDTnAajAjlmfB-dX5DBdawUcSSPaGWGLzFBk=.cdbf468a-ace7-45e5-a25a-833c760b776c@github.com>
Message-ID: <9zfV5nyplR4VhLq9m8GCpSD1o2YfJ_iV9YRpAxbypkQ=.a769e89c-03b5-4712-9d14-14d858f7772e@github.com>

> Initial pass of porting FDLIBM sinh/cosh/tanh to Java. I do intend to refactor the regression tests a bit to reduce duplication, but the actual ports should be ready for review.
> 
> Diff'ing the ports as before, original vs transliteration port:
> 
> 
> $ diff -w Hyperbolic.c Hyperbolic.translit.java
> 1c1
> < /* __ieee754_sinh(x)
> ---
>>     /**
> 17a18,19
>>     static class Sinh {
>>         private static final double one = 1.0, shuge = 1.0e307;
> 19,33c21
> < #include "fdlibm.h"
> < 
> < #ifdef __STDC__
> < static const double one = 1.0, shuge = 1.0e307;
> < #else
> < static double one = 1.0, shuge = 1.0e307;
> < #endif
> < 
> < #ifdef __STDC__
> <         double __ieee754_sinh(double x)
> < #else
> <         double __ieee754_sinh(x)
> <         double x;
> < #endif
> < {
> ---
>>         private static double compute(double x) {
> 36c24
> <         unsigned lx;
> ---
>>             /* unsigned */ int lx;
> 51c39
> <             t = expm1(fabs(x));
> ---
>>                 t = FdlibmTranslit.expm1(Math.abs(x));
> 57c45
> <         if (ix < 0x40862E42)  return h*__ieee754_exp(fabs(x));
> ---
>>             if (ix < 0x40862E42)  return h*StrictMath.exp(Math.abs(x)); // TODO switch to translit
> 60,62c48,52
> <         lx = *( (((*(unsigned*)&one)>>29)) + (unsigned*)&x);
> <         if (ix<0x408633CE || ((ix==0x408633ce)&&(lx<=(unsigned)0x8fb9f87d))) {
> <             w = __ieee754_exp(0.5*fabs(x));
> ---
>>             // lx = *( (((*(unsigned*)&one)>>29)) + (unsigned*)&x);
>>             // lx =  (((*(unsigned*)&one)>>29)) + (unsigned*)&x ;
>>             lx = __LO(x);
>>             if (ix<0x408633CE || ((ix==0x408633ce)&&(Long.compareUnsigned(lx, 0x8fb9f87d) <= 0 ))) {
>>                 w = StrictMath.exp(0.5*Math.abs(x)); // TODO switch to translit
> 70c60,62
> < /* __ieee754_cosh(x)
> ---
>>     }
>> 
>>     /**
> 90,105c82,84
> < 
> < #include "fdlibm.h"
> < 
> < #ifdef __STDC__
> < static const double one = 1.0, half=0.5, huge = 1.0e300;
> < #else
> < static double one = 1.0, half=0.5, huge = 1.0e300;
> < #endif
> < 
> < #ifdef __STDC__
> <         double __ieee754_cosh(double x)
> < #else
> <         double __ieee754_cosh(x)
> <         double x;
> < #endif
> < {
> ---
>>     static class Cosh {
>>         private static final double one = 1.0, half=0.5, huge = 1.0e300;
>>         private static double compute(double x) {
> 108c87
> <         unsigned lx;
> ---
>>             /*unsigned*/ int lx;
> 119c98
> <             t = expm1(fabs(x));
> ---
>>                 t = expm1(Math.abs(x));
> 127c106
> <                 t = __ieee754_exp(fabs(x));
> ---
>>                 t = StrictMath.exp(Math.abs(x)); // TODO switch to translit
> 132c111
> <         if (ix < 0x40862E42)  return half*__ieee754_exp(fabs(x));
> ---
>>             if (ix < 0x40862E42)  return half*StrictMath.exp(Math.abs(x)); // TODO switch to translit
> 135c114
> <         lx = *( (((*(unsigned*)&one)>>29)) + (unsigned*)&x);
> ---
>>             lx = __LO(x);
> 137,138c116,117
> <               ((ix==0x408633ce)&&(lx<=(unsigned)0x8fb9f87d))) {
> <             w = __ieee754_exp(half*fabs(x));
> ---
>>                 ((ix==0x408633ce)&&(Integer.compareUnsigned(lx, 0x8fb9f87d) <= 0))) {
>>                 w = StrictMath.exp(half*Math.abs(x)); // TODO switch to translit
> 146c125,127
> < /* Tanh(x)
> ---
>>     }
>> 
>>     /**
> 169,184c150,152
> < 
> < #include "fdlibm.h"
> < 
> < #ifdef __STDC__
> < static const double one=1.0, two=2.0, tiny = 1.0e-300;
> < #else
> < static double one=1.0, two=2.0, tiny = 1.0e-300;
> < #endif
> < 
> < #ifdef __STDC__
> <         double tanh(double x)
> < #else
> <         double tanh(x)
> <         double x;
> < #endif
> < {
> ---
>>     static class Tanh {
>>         private static final double one=1.0, two=2.0, tiny = 1.0e-300;
>>         static double compute(double x) {
> 203c171
> <                 t = expm1(two*fabs(x));
> ---
>>                     t = expm1(two*Math.abs(x));
> 206c174
> <                 t = expm1(-two*fabs(x));
> ---
>>                     t = expm1(-two*Math.abs(x));
> 214a183
>>     }
> 
> 
> Note that the original has a in-line version of the "__LO" macro rather than using the macro.
> 
> 
> And transliteration vs more idiomatic:
> 
> 
> $ diff -w Hyperbolic.translit.java Hyperbolic.fdlibm.java 
> 21c21
> <         private static double compute(double x) {
> ---
>>          static double compute(double x) {
> 26c26
> <             /* High word of |x|. */
> ---
>>             // High word of |x|
> 28c28
> <             ix = jx&0x7fffffff;
> ---
>>             ix = jx & 0x7fff_ffff;
> 30,31c30,33
> <             /* x is INF or NaN */
> <             if(ix>=0x7ff00000) return x+x;
> ---
>>             // x is INF or NaN
>>             if ( ix >= 0x7ff0_0000) {
>>                 return x + x;
>>             }
> 34,40c36,48
> <             if (jx<0) h = -h;
> <             /* |x| in [0,22], return sign(x)*0.5*(E+E/(E+1))) */
> <             if (ix < 0x40360000) {          /* |x|<22 */
> <                 if (ix<0x3e300000)          /* |x|<2**-28 */
> <                     if(shuge+x>one) return x;/* sinh(tiny) = tiny with inexact */
> <                 t = FdlibmTranslit.expm1(Math.abs(x));
> <                 if(ix<0x3ff00000) return h*(2.0*t-t*t/(t+one));
> ---
>>             if ( jx < 0) {
>>                 h = -h;
>>             }
>>             // |x| in [0,22], return sign(x)*0.5*(E+E/(E+1)))
>>             if (ix < 0x4036_0000) {          // |x| < 22
>>                 if (ix < 0x3e30_0000)        // |x| < 2**-28
>>                     if (shuge + x > one) {   // sinh(tiny) = tiny with inexact
>>                         return x;
>>                     }
>>                 t = StrictMath.expm1(Math.abs(x));
>>                 if (ix < 0x3ff0_0000) {
>>                     return h*(2.0 * t - t*t/(t + one));
>>                 }
> 44,45c52,55
> <             /* |x| in [22, log(maxdouble)] return 0.5*exp(|x|) */
> <             if (ix < 0x40862E42)  return h*StrictMath.exp(Math.abs(x)); // TODO switch to translit
> ---
>>             // |x| in [22, log(maxdouble)] return 0.5*exp(|x|)
>>             if (ix < 0x4086_2E42) {
>>                 return h*StrictMath.exp(Math.abs(x));
>>             }
> 47,49c57
> <             /* |x| in [log(maxdouble), overflowthresold] */
> <             // lx = *( (((*(unsigned*)&one)>>29)) + (unsigned*)&x);
> <             // lx =  (((*(unsigned*)&one)>>29)) + (unsigned*)&x ;
> ---
>>             // |x| in [log(maxdouble), overflowthresold]
> 51,52c59,62
> <             if (ix<0x408633CE || ((ix==0x408633ce)&&(Long.compareUnsigned(lx, 0x8fb9f87d) <= 0 ))) {
> <                 w = StrictMath.exp(0.5*Math.abs(x)); // TODO switch to translit
> ---
>>             if (ix < 0x4086_33CE ||
>>                 ((ix == 0x4086_33ce) &&
>>                  (Long.compareUnsigned(lx, 0x8fb9_f87d) <= 0 ))) {
>>                 w = StrictMath.exp(0.5 * Math.abs(x));
> 57c67
> <             /* |x| > overflowthresold, sinh(x) overflow */
> ---
>>             // |x| > overflowthresold, sinh(x) overflow
> 84c94
> <         private static double compute(double x) {
> ---
>>         static double compute(double x) {
> 89c99
> <             /* High word of |x|. */
> ---
>>             // High word of |x|
> 91c101
> <             ix &= 0x7fffffff;
> ---
>>             ix &= 0x7fff_ffff;
> 93,94c103,106
> <             /* x is INF or NaN */
> <             if(ix>=0x7ff00000) return x*x;
> ---
>>             // x is INF or NaN
>>             if (ix >= 0x7ff_00000) {
>>                 return x*x;
>>             }
> 96,98c108,110
> <             /* |x| in [0,0.5*ln2], return 1+expm1(|x|)^2/(2*exp(|x|)) */
> <             if(ix<0x3fd62e43) {
> <                 t = expm1(Math.abs(x));
> ---
>>             // |x| in [0,0.5*ln2], return 1+expm1(|x|)^2/(2*exp(|x|))
>>             if (ix < 0x3fd6_2e43) {
>>                 t = StrictMath.expm1(Math.abs(x));
> 100c112,114
> <                 if (ix<0x3c800000) return w;        /* cosh(tiny) = 1 */
> ---
>>                 if (ix < 0x3c80_0000) { // cosh(tiny) = 1
>>                     return w;
>>                 }
> 104,106c118,120
> <             /* |x| in [0.5*ln2,22], return (exp(|x|)+1/exp(|x|)/2; */
> <             if (ix < 0x40360000) {
> <                 t = StrictMath.exp(Math.abs(x)); // TODO switch to translit
> ---
>>             // |x| in [0.5*ln2, 22], return (exp(|x|) + 1/exp(|x|)/2
>>             if (ix < 0x4036_0000) {
>>                 t = StrictMath.exp(Math.abs(x));
> 110,111c124,127
> <             /* |x| in [22, log(maxdouble)] return half*exp(|x|) */
> <             if (ix < 0x40862E42)  return half*StrictMath.exp(Math.abs(x)); // TODO switch to translit
> ---
>>             // |x| in [22, log(maxdouble)] return half*exp(|x|)
>>             if (ix < 0x4086_2E42) {
>>                 return half*StrictMath.exp(Math.abs(x));
>>             }
> 113c129
> <             /* |x| in [log(maxdouble), overflowthresold] */
> ---
>>             // |x| in [log(maxdouble), overflowthresold]
> 115,117c131,134
> <             if (ix<0x408633CE ||
> <                 ((ix==0x408633ce)&&(Integer.compareUnsigned(lx, 0x8fb9f87d) <= 0))) {
> <                 w = StrictMath.exp(half*Math.abs(x)); // TODO switch to translit
> ---
>>             if (ix<0x4086_33CE ||
>>                 ((ix == 0x4086_33ce) &&
>>                  (Integer.compareUnsigned(lx, 0x8fb9_f87d) <= 0))) {
>>                 w = StrictMath.exp(half*Math.abs(x));
> 122c139
> <             /* |x| > overflowthresold, cosh(x) overflow */
> ---
>>             // |x| > overflowthresold, cosh(x) overflow
> 126d142
> < 
> 156c172
> <             /* High word of |x|. */
> ---
>>             // High word of |x|.
> 158c174
> <             ix = jx&0x7fffffff;
> ---
>>             ix = jx & 0x7fff_ffff;
> 160,163c176,182
> <             /* x is INF or NaN */
> <             if(ix>=0x7ff00000) {
> <                 if (jx>=0) return one/x+one;    /* tanh(+-inf)=+-1 */
> <                 else       return one/x-one;    /* tanh(NaN) = NaN */
> ---
>>             // x is INF or NaN
>>             if (ix >= 0x7ff0_0000) {
>>                 if (jx >= 0) {  // tanh(+-inf)=+-1
>>                     return one/x + one;
>>                 } else {        // tanh(NaN) = NaN
>>                     return one/x - one;
>>                 }
> 166,171c185,190
> <             /* |x| < 22 */
> <             if (ix < 0x40360000) {          /* |x|<22 */
> <                 if (ix<0x3c800000)          /* |x|<2**-55 */
> <                     return x*(one+x);       /* tanh(small) = small */
> <                 if (ix>=0x3ff00000) {       /* |x|>=1  */
> <                     t = expm1(two*Math.abs(x));
> ---
>>             // |x| < 22
>>             if (ix < 0x4036_0000) {          // |x| < 22
>>                 if (ix<0x3c80_0000)          // |x| < 2**-55
>>                     return x*(one + x);      // tanh(small) = small
>>                 if (ix>=0x3ff0_0000) {       // |x| >= 1
>>                     t = StrictMath.expm1(two*Math.abs(x));
> 174c193
> <                     t = expm1(-two*Math.abs(x));
> ---
>>                     t = StrictMath.expm1(-two*Math.abs(x));
> 177,179c196,197
> <                 /* |x| > 22, return +-1 */
> <             } else {
> <                 z = one - tiny;             /* raised inexact flag */
> ---
>>             } else { // |x| > 22, return +-1
>>                 z = one - tiny;             // raised inexact flag

Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:

  Improve exp usage.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12429/files
  - new: https://git.openjdk.org/jdk/pull/12429/files/45d4247f..19fe9857

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12429&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12429&range=04-05

  Stats: 23 lines in 3 files changed: 6 ins; 4 del; 13 mod
  Patch: https://git.openjdk.org/jdk/pull/12429.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12429/head:pull/12429

PR: https://git.openjdk.org/jdk/pull/12429

From smarks at openjdk.org  Wed Feb  8 20:54:53 2023
From: smarks at openjdk.org (Stuart Marks)
Date: Wed, 8 Feb 2023 20:54:53 GMT
Subject: RFR: 8283660: Convert
 com/sun/jndi/ldap/AbstractLdapNamingEnumeration.java finalizer to Cleaner
 [v16]
In-Reply-To: <eFt6SCXR1oCUa1Q2D7g8KIbx-_UsXJa5zU4xMvIjF8E=.e69adc7f-f489-4d77-917d-dfb4a0f73f27@github.com>
References: <anHLuO0INa29U7GueBX7ihMfveqROF8YXaT0KhPJjdQ=.1a650b8b-45fc-4142-96d4-25839a564b68@github.com>
 <eFt6SCXR1oCUa1Q2D7g8KIbx-_UsXJa5zU4xMvIjF8E=.e69adc7f-f489-4d77-917d-dfb4a0f73f27@github.com>
Message-ID: <QFQh88XW086YnGSN5ao-T72YXKA9PpwQBrjiy6dnToE=.7cbedbda-5943-48c9-b2a4-110e09693b47@github.com>

On Fri, 22 Jul 2022 20:51:59 GMT, Brent Christian <bchristi at openjdk.org> wrote:

>> Please review this change to replace the finalizer in `AbstractLdapNamingEnumeration` with a Cleaner.
>> 
>> The pieces of state required for cleanup (`LdapCtx homeCtx`, `LdapResult res`, and `LdapClient enumClnt`) are moved to a static inner class . From there, the change is fairly mechanical.
>> 
>> Details of note: 
>> 1. Some operations need to change the state values (the update() method is probably the most interesting).
>> 2. Subclasses need to access `homeCtx`; I added a `homeCtx()` method to read `homeCtx` from the superclass's `state`.
>> 
>> The test case is based on a copy of `com/sun/jndi/ldap/blits/AddTests/AddNewEntry.java`. A more minimal test case might be possible, but this was done for expediency.
>> 
>> The test only confirms that the new Cleaner use does not keep the object reachable. It only tests `LdapSearchEnumeration` (not `LdapNamingEnumeration` or `LdapBindingEnumeration`, though all are subclasses of `AbstractLdapNamingEnumeration`). 
>> 
>> Thanks.
>
> Brent Christian has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove some more tabs

Oh darn, looks like `Reference.reachabilityFence(this)` is broken!!

-------------

PR: https://git.openjdk.org/jdk/pull/8311

From dholmes at openjdk.org  Wed Feb  8 21:33:42 2023
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 8 Feb 2023 21:33:42 GMT
Subject: RFR: 8300139 : [AIX] Use pthreads to avoid JNI_createVM call from
 primordial thread [v2]
In-Reply-To: <vu7c9WHMcCXtkghiBjXUnP3KUy6Xyh7lP7McKSnlJcY=.2e4bdce8-d4e3-4dd1-9fc3-1a27f089dd6f@github.com>
References: <qbwPBNdxzk4QmB9L6y2t-X6uYgAaPjzAEwYfs_5XV_0=.4ea982e6-30da-4219-b8ad-fa36690170b8@github.com>
 <vu7c9WHMcCXtkghiBjXUnP3KUy6Xyh7lP7McKSnlJcY=.2e4bdce8-d4e3-4dd1-9fc3-1a27f089dd6f@github.com>
Message-ID: <EytMoEECi74JuG2MD6i79mz-m2o45-C5wB1PxkoKweU=.3335308c-0147-43df-8821-7b08c3aa11f8@github.com>

On Wed, 8 Feb 2023 13:11:25 GMT, Varada M <duke at openjdk.org> wrote:

>> 1. test/jdk/jni/nullCaller/NullCallerTest.java
>> 2. test/jdk/java/lang/reflect/exeCallerAccessTest/CallerAccessTest.java
>> 3. test/hotspot/jtreg/runtime/jni/CalleeSavedRegisters/FPRegs.java 
>> 
>>     The above tests were blocked on AIX [@require os.family != "aix"] because these tests are failing to call JNI_CreateJavaVM. This is solved by implementing JNI_CreateJavaVM call via POSIX threads. 
>>    Similarly there are tests which are not blocked and still failing to call JNI_CreateJavaVM on AIX :
>> 
>> 4. test/hotspot/jtreg/runtime/jni/daemonDestroy/TestDaemonDestroy.java { PR : [12006](https://github.com/openjdk/jdk/pull/12006) }
>> 5. test/lib-test/jdk/test/lib/process/TestNativeProcessBuilder.java 
>> 
>> The reported issue : [8300139](https://bugs.openjdk.org/browse/JDK-8300139l)
>
> Varada M has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixes

It just occurred to me that we may also need to update the test makefiles to link to libpthread for these modified tests?

-------------

PR: https://git.openjdk.org/jdk/pull/12302

From darcy at openjdk.org  Wed Feb  8 21:37:15 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 8 Feb 2023 21:37:15 GMT
Subject: RFR: JDK-8301202: Port fdlibm log to Java [v2]
In-Reply-To: <t0yhKjTMAtSuAZjI0unvr73crUuYEM-2HQ8sUI2_sNU=.82036639-980d-46de-a201-3d85bd84563d@github.com>
References: <t0yhKjTMAtSuAZjI0unvr73crUuYEM-2HQ8sUI2_sNU=.82036639-980d-46de-a201-3d85bd84563d@github.com>
Message-ID: <X7MZBHvvWw7e6CPWi0GgwrsL-PQIIHvTLr2EFcxa5EE=.281c3985-bab6-46c3-b0fb-a71250748441@github.com>

> Next up on the FDLIBM porting countdown, the log method.
> 
> Original C vs transliteration port:
> 
> 
> $ diff -w Log.c Log.translit.java 
> 1c1
> < /* __ieee754_log(x)
> ---
>>     /**
> 51,58c51,52
> < 
> < #include "fdlibm.h"
> < 
> < #ifdef __STDC__
> < static const double
> < #else
> < static double
> < #endif
> ---
>>     static class Log {
>>         private static final  double
> 70c64
> < static double zero   =  0.0;
> ---
>>         private static double zero   =  0.0;
> 72,78c66
> < #ifdef __STDC__
> <         double __ieee754_log(double x)
> < #else
> <         double __ieee754_log(x)
> <         double x;
> < #endif
> < {
> ---
>>         static double compute(double x) {
> 81c69
> <         unsigned lx;
> ---
>>             /*unsigned*/ int lx;
> 98c86,87
> <         __HI(x) = hx|(i^0x3ff00000);    /* normalize x or x/2 */
> ---
>>             // __HI(x) = hx|(i^0x3ff00000);    /* normalize x or x/2 */
>>             x =__HI(x, hx|(i^0x3ff00000));    /* normalize x or x/2 */
> 128a118
>>     }
> 
> 
> Transliteration port vs more idiomatic port:
> 
> 
> $ diff -w  Log.translit.java Log.fdlibm.java 
> 2c2
> <      * Return the logarithm of x
> ---
>>      * Return the (natural) logarithm of x
> 53,62c53,54
> <             ln2_hi  =  6.93147180369123816490e-01,  /* 3fe62e42 fee00000 */
> <             ln2_lo  =  1.90821492927058770002e-10,  /* 3dea39ef 35793c76 */
> <             two54   =  1.80143985094819840000e+16,  /* 43500000 00000000 */
> <             Lg1 = 6.666666666666735130e-01,  /* 3FE55555 55555593 */
> <             Lg2 = 3.999999999940941908e-01,  /* 3FD99999 9997FA04 */
> <             Lg3 = 2.857142874366239149e-01,  /* 3FD24924 94229359 */
> <             Lg4 = 2.222219843214978396e-01,  /* 3FCC71C5 1D8E78AF */
> <             Lg5 = 1.818357216161805012e-01,  /* 3FC74664 96CB03DE */
> <             Lg6 = 1.531383769920937332e-01,  /* 3FC39A09 D078C69F */
> <             Lg7 = 1.479819860511658591e-01;  /* 3FC2F112 DF3E5244 */
> ---
>>             ln2_hi = 0x1.62e42feep-1,       // 6.93147180369123816490e-01
>>             ln2_lo = 0x1.a39ef35793c76p-33, // 1.90821492927058770002e-10
> 64c56,64
> <         private static double zero   =  0.0;
> ---
>>             Lg1    = 0x1.5555555555593p-1,  // 6.666666666666735130e-01
>>             Lg2    = 0x1.999999997fa04p-2,  // 3.999999999940941908e-01
>>             Lg3    = 0x1.2492494229359p-2,  // 2.857142874366239149e-01
>>             Lg4    = 0x1.c71c51d8e78afp-3,  // 2.222219843214978396e-01
>>             Lg5    = 0x1.7466496cb03dep-3,  // 1.818357216161805012e-01
>>             Lg6    = 0x1.39a09d078c69fp-3,  // 1.531383769920937332e-01
>>             Lg7    = 0x1.2f112df3e5244p-3;  // 1.479819860511658591e-01
>> 
>>         private static final double zero = 0.0;
> 71,72c71,72
> <             hx = __HI(x);           /* high word of x */
> <             lx = __LO(x);           /* low  word of x */
> ---
>>             hx = __HI(x);           // high word of x
>>             lx = __LO(x);           // low  word of x
> 75,80c75,87
> <             if (hx < 0x00100000) {                  /* x < 2**-1022  */
> <                 if (((hx&0x7fffffff)|lx)==0)
> <                     return -two54/zero;             /* log(+-0)=-inf */
> <                 if (hx<0) return (x-x)/zero;        /* log(-#) = NaN */
> <                 k -= 54; x *= two54; /* subnormal number, scale up x */
> <                 hx = __HI(x);               /* high word of x */
> ---
>>             if (hx < 0x0010_0000) {                  // x < 2**-1022
>>                 if (((hx & 0x7fff_ffff) | lx) ==0) { // log(+-0) = -inf
>>                     return -TWO54/zero;
>>                 }
>>                 if (hx < 0) {                        // log(-#) = NaN
>>                     return (x - x)/zero;
>>                 }
>>                 k -= 54;
>>                 x *= TWO54;    // subnormal number, scale up x
>>                 hx = __HI(x);  // high word of x
>>             }
>>             if (hx >= 0x7ff0_0000) {
>>                 return x+x;
> 82d88
> <             if (hx >= 0x7ff00000) return x+x;
> 84,87c90,92
> <             hx &= 0x000fffff;
> <             i = (hx+0x95f64)&0x100000;
> <             // __HI(x) = hx|(i^0x3ff00000);    /* normalize x or x/2 */
> <             x =__HI(x, hx|(i^0x3ff00000));    /* normalize x or x/2 */
> ---
>>             hx &= 0x000f_ffff;
>>             i = (hx + 0x9_5f64) & 0x10_0000;
>>             x =__HI(x, hx|(i ^ 0x3ff0_0000));  // normalize x or x/2
> 90c95
> <             if((0x000fffff&(2+hx))<3) {     /* |f| < 2**-20 */
> ---
>>             if ((0x000f_ffff & (2 + hx)) < 3) {// |f| < 2**-20
> 92,93c97,102
> <                     if (k==0) return zero;
> <                     else {dk=(double)k; return dk*ln2_hi+dk*ln2_lo;}
> ---
>>                     if (k == 0) {
>>                         return zero;
>>                     } else {
>>                         dk = (double)k;
>>                         return dk*ln2_hi + dk*ln2_lo;
>>                     }
> 96,97c105,110
> <                 if(k==0) return f-R; else {dk=(double)k;
> <                     return dk*ln2_hi-((R-dk*ln2_lo)-f);}
> ---
>>                 if (k == 0) {
>>                     return f - R;
>>                 } else {
>>                     dk = (double)k;
>>                     return dk*ln2_hi - ((R - dk*ln2_lo) - f);
>>                 }
> 102c115
> <             i = hx-0x6147a;
> ---
>>             i = hx - 0x6_147a;
> 111c124,126
> <                 if(k==0) return f-(hfsq-s*(hfsq+R)); else
> ---
>>                 if (k == 0) {
>>                     return f-(hfsq-s*(hfsq+R));
>>                 } else {
> 112a128,131
>>                 }
>>             } else {
>>                 if (k == 0) {
>>                     return f - s*(f - R);
> 114d132
> <                 if(k==0) return f-s*(f-R); else
> 115a134
>>                 }
> 
> 
> The transliteration port passes the "exhausting" test of all float arguments when run against a JDK 20 build. The idiomatic port matches the transliteration port on the same test.

Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:

  Improve declarations of Log host classes.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12465/files
  - new: https://git.openjdk.org/jdk/pull/12465/files/6737e5d4..b7f0e8d2

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12465&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12465&range=00-01

  Stats: 8 lines in 2 files changed: 2 ins; 0 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/12465.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12465/head:pull/12465

PR: https://git.openjdk.org/jdk/pull/12465

From lancea at openjdk.org  Wed Feb  8 21:55:54 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Wed, 8 Feb 2023 21:55:54 GMT
Subject: [jdk20] RFR: 8301863: ObjectInputFilter example incorrectly calls
 rejectUndecidedClass [v2]
In-Reply-To: <Qu4md0CW6xzEabvMDqf2ZLwZw5dxQpP8NjGnfR5ejIw=.c22fe67a-fb68-41c2-9d0a-0ebbb8f0f60c@github.com>
References: <i0ZaWMa10jaiLQL21r8epcqXwsnnmMUhF-ilhTWERlQ=.2a911a8f-4606-403f-8eba-13146a829304@github.com>
 <Qu4md0CW6xzEabvMDqf2ZLwZw5dxQpP8NjGnfR5ejIw=.c22fe67a-fb68-41c2-9d0a-0ebbb8f0f60c@github.com>
Message-ID: <p3OWWiqlBTHZoqK4HziABFjuYwu8I62CBaWyp5aIndI=.a3616a2d-acd5-41db-af6b-b05a0e863e01@github.com>

On Mon, 6 Feb 2023 22:52:10 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> The example code in ObjectInputFilter for the FilterInThread filter factory does not do what is intended and is poorly described. Clarifies that the JVM-wide filter and the thread local filter are merged and will reject classes that are otherwise not accepted or rejected. If a stream specific filter is set and does not accept or reject a class, the combined filter is applied.
>> 
>> This is a doc-only change.
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8301863: ObjectInputFilter example incorrectly calls rejectUndecidedClass
>   Correct typo in prose.

Marked as reviewed by lancea (Reviewer).

-------------

PR: https://git.openjdk.org/jdk20/pull/121

From rriggs at openjdk.org  Wed Feb  8 22:12:43 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 8 Feb 2023 22:12:43 GMT
Subject: [jdk20] Integrated: 8301863: ObjectInputFilter example incorrectly
 calls rejectUndecidedClass
In-Reply-To: <i0ZaWMa10jaiLQL21r8epcqXwsnnmMUhF-ilhTWERlQ=.2a911a8f-4606-403f-8eba-13146a829304@github.com>
References: <i0ZaWMa10jaiLQL21r8epcqXwsnnmMUhF-ilhTWERlQ=.2a911a8f-4606-403f-8eba-13146a829304@github.com>
Message-ID: <H3S6g27Fi5h1jffUOZ1PhRDw0DWjxJotq-8LDtY1uZY=.65efd9e4-fac6-4715-852b-c74ceb6a166b@github.com>

On Mon, 6 Feb 2023 20:40:08 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> The example code in ObjectInputFilter for the FilterInThread filter factory does not do what is intended and is poorly described. Clarifies that the JVM-wide filter and the thread local filter are merged and will reject classes that are otherwise not accepted or rejected. If a stream specific filter is set and does not accept or reject a class, the combined filter is applied.
> 
> This is a doc-only change.

This pull request has now been integrated.

Changeset: 6f460e48
Author:    Roger Riggs <rriggs at openjdk.org>
URL:       https://git.openjdk.org/jdk20/commit/6f460e4885b274f01c9097f41a65c637654858ce
Stats:     20 lines in 1 file changed: 4 ins; 9 del; 7 mod

8301863: ObjectInputFilter example incorrectly calls rejectUndecidedClass

Reviewed-by: lancea

-------------

PR: https://git.openjdk.org/jdk20/pull/121

From igraves at openjdk.org  Wed Feb  8 23:07:14 2023
From: igraves at openjdk.org (Ian Graves)
Date: Wed, 8 Feb 2023 23:07:14 GMT
Subject: RFR: 8293667: Align jlink's --compress option with jmod's
 --compress option [v6]
In-Reply-To: <JWevwHuR2vF3k-JRxmTAxfNN6g-EBkgG2N9DHn4fkGY=.f9768dfd-cab4-49a9-83b9-d77a1572e917@github.com>
References: <JWevwHuR2vF3k-JRxmTAxfNN6g-EBkgG2N9DHn4fkGY=.f9768dfd-cab4-49a9-83b9-d77a1572e917@github.com>
Message-ID: <p5a-3JyPNAPcY5YrBuDGkX9bKNuiwp56QHf2oIInGnc=.ef123257-baf4-4b2c-835c-745bd9899ba7@github.com>

> This is an approach to adding a flag to jlink that will allow --compress to take the same types of arguments as jmod, thus bringing the two into alignment. This likely requires a CSR and a discussion on whether we should deprecate or simply remove the original numeric compression arguments.

Ian Graves has updated the pull request incrementally with one additional commit since the last revision:

  Fixing up resources

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/11617/files
  - new: https://git.openjdk.org/jdk/pull/11617/files/06f4b3c3..2af25227

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11617&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11617&range=04-05

  Stats: 8 lines in 1 file changed: 0 ins; 0 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/11617.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11617/head:pull/11617

PR: https://git.openjdk.org/jdk/pull/11617

From mchung at openjdk.org  Wed Feb  8 23:17:20 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Wed, 8 Feb 2023 23:17:20 GMT
Subject: RFR: JDK-8301704: Shorten the number of GCs in UnloadingTest.java
 to verify a class loader not being unloaded [v2]
In-Reply-To: <bdUKXSHJGqFT5OdTZgU21MwCcuP9aAkg3lIP3WQbyJY=.c41376be-4fc1-409c-a2c1-42f1d0b30aba@github.com>
References: <bdUKXSHJGqFT5OdTZgU21MwCcuP9aAkg3lIP3WQbyJY=.c41376be-4fc1-409c-a2c1-42f1d0b30aba@github.com>
Message-ID: <x8KtJC8CkYhY70cEKFGBpEzhIX31JSZDFlAbz0wqzIY=.80e07b98-948d-4bab-a0b9-208516d6cec6@github.com>

> `test/jdk/java/lang/invoke/defineHiddenClass/UnloadingTest.java` defines hidden classes and verify cases that a class loader is not unloaded using `ForceGC::wait`.    ForceGC::wait` defaults the timeout to 1000ms * jtreg timeout factor, which is designed to work well to expect an object being reclaimed, i.e. the boolean supplier returns true.   On the other hand, if the boolean supplier never returns true, the method returns after it timeouts which may be long depending on the timeout factor. 
> 
> This PR adds a variant of `ForceGC::wait` to take a timeout parameter and tests can specify the timeout to reduce the time it takes testing a strongly reachable object not being reclaimed.

Mandy Chung 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 JDK-8301704
 - Rename the new method to waitFor
 - JDK-8301704: Shorten the number of GCs in UnloadingTest.java to verify a strongly reachable object not being unloaded

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12392/files
  - new: https://git.openjdk.org/jdk/pull/12392/files/6c7d12c7..f67b60ad

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12392&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12392&range=00-01

  Stats: 11925 lines in 371 files changed: 7936 ins; 1454 del; 2535 mod
  Patch: https://git.openjdk.org/jdk/pull/12392.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12392/head:pull/12392

PR: https://git.openjdk.org/jdk/pull/12392

From rriggs at openjdk.org  Wed Feb  8 23:18:46 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 8 Feb 2023 23:18:46 GMT
Subject: RFR: JDK-8301704: Shorten the number of GCs in UnloadingTest.java
 to verify a class loader not being unloaded [v2]
In-Reply-To: <x8KtJC8CkYhY70cEKFGBpEzhIX31JSZDFlAbz0wqzIY=.80e07b98-948d-4bab-a0b9-208516d6cec6@github.com>
References: <bdUKXSHJGqFT5OdTZgU21MwCcuP9aAkg3lIP3WQbyJY=.c41376be-4fc1-409c-a2c1-42f1d0b30aba@github.com>
 <x8KtJC8CkYhY70cEKFGBpEzhIX31JSZDFlAbz0wqzIY=.80e07b98-948d-4bab-a0b9-208516d6cec6@github.com>
Message-ID: <8vzDR6NwvN7iieT84Qi-Eg4WwWPjc4paTggpw3i9oHI=.7a34e542-47e3-4db1-8a7b-f6233491ee4d@github.com>

On Wed, 8 Feb 2023 23:17:20 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> `test/jdk/java/lang/invoke/defineHiddenClass/UnloadingTest.java` defines hidden classes and verify cases that a class loader is not unloaded using `ForceGC::wait`.    ForceGC::wait` defaults the timeout to 1000ms * jtreg timeout factor, which is designed to work well to expect an object being reclaimed, i.e. the boolean supplier returns true.   On the other hand, if the boolean supplier never returns true, the method returns after it timeouts which may be long depending on the timeout factor. 
>> 
>> This PR adds a variant of `ForceGC::wait` to take a timeout parameter and tests can specify the timeout to reduce the time it takes testing a strongly reachable object not being reclaimed.
>
> Mandy Chung 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 JDK-8301704
>  - Rename the new method to waitFor
>  - JDK-8301704: Shorten the number of GCs in UnloadingTest.java to verify a strongly reachable object not being unloaded

LGTM

-------------

Marked as reviewed by rriggs (Reviewer).

PR: https://git.openjdk.org/jdk/pull/12392

From duke at openjdk.org  Wed Feb  8 23:33:20 2023
From: duke at openjdk.org (Tingjun Yuan)
Date: Wed, 8 Feb 2023 23:33:20 GMT
Subject: RFR: 8296935: Arrays.asList().set() with wrong types throws
 undocumented ArrayStoreException [v8]
In-Reply-To: <9JFNgXqBSj9uR8vR9oIooJMxtf74y12L0-GbjOO7fJg=.769953c2-40f3-49c0-8598-ce940d2d95d4@github.com>
References: <9JFNgXqBSj9uR8vR9oIooJMxtf74y12L0-GbjOO7fJg=.769953c2-40f3-49c0-8598-ce940d2d95d4@github.com>
Message-ID: <HvasxUr1OcjOvITT8vm-nBSSYXCRJIOVe5niJpsGT2U=.a092ea8d-a6f0-4c00-b934-b4030d1494fe@github.com>

> Document `java.util.Arrays.asList` that the list will throw an `ArrayStoreException` when attempting to set an element with a wrong type.

Tingjun Yuan has updated the pull request incrementally with one additional commit since the last revision:

  Update Arrays.java

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12135/files
  - new: https://git.openjdk.org/jdk/pull/12135/files/ae050ecc..84a6611a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12135&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12135&range=06-07

  Stats: 20 lines in 1 file changed: 15 ins; 0 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/12135.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12135/head:pull/12135

PR: https://git.openjdk.org/jdk/pull/12135

From duke at openjdk.org  Wed Feb  8 23:36:48 2023
From: duke at openjdk.org (Tingjun Yuan)
Date: Wed, 8 Feb 2023 23:36:48 GMT
Subject: RFR: 8296935: Arrays.asList().set() with wrong types throws
 undocumented ArrayStoreException [v8]
In-Reply-To: <HvasxUr1OcjOvITT8vm-nBSSYXCRJIOVe5niJpsGT2U=.a092ea8d-a6f0-4c00-b934-b4030d1494fe@github.com>
References: <9JFNgXqBSj9uR8vR9oIooJMxtf74y12L0-GbjOO7fJg=.769953c2-40f3-49c0-8598-ce940d2d95d4@github.com>
 <HvasxUr1OcjOvITT8vm-nBSSYXCRJIOVe5niJpsGT2U=.a092ea8d-a6f0-4c00-b934-b4030d1494fe@github.com>
Message-ID: <rv7uknWqe6ptzUXBtPKFc-83gpSEV_cP26xPQgsK0LE=.4fe5fed8-0c3c-467a-a21e-26349bd38cba@github.com>

On Wed, 8 Feb 2023 23:33:20 GMT, Tingjun Yuan <duke at openjdk.org> wrote:

>> Document `java.util.Arrays.asList` that the list will throw an `ArrayStoreException` when attempting to set an element with a wrong type.
>
> Tingjun Yuan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update Arrays.java

I've written a CSR report for this PR as below.  Could someone please help me to submit it to the JBS if it looks okay? Thank you!

---

**Compatibility Risk:** minimum

**Compatibility Risk Description:** No implementation is modified

## Summary

Document the current behavior of `java.util.Arrays.asList(Object...)` that it will throw an `ArrayStoreException` when an element of wrong type is trying to be set into the list.

## Problem

`java.util.Arrays.asList(Object...)` is a widely used method that wraps an object array into a `List`.  The specification of  methods `List.set` and `ListIterator.set` indicates that implementations should throw a `ClassCastException` when the class of the specified element prevents it from being added to this list. However when an application tries to store an element that is not compatible with the backing array component type via the returned list, an `ArrayStoreException` will be thrown instead of `ClassCastException`, which violates the `List` specification.

## Solution

Since this method is widely used, we do not change the current behavior. Instead, we document the current behavior of `java.util.Arrays.asList(Object...)` that it will throw an `ArrayStoreException` when an element of wrong type is trying to be set into the list.

## Specification

Add the following `@apiNote` section into the `java.util.Arrays.asList` specification:


     * @apiNote
     * The {@link List} returned by this method does not conform to the
     * specification for {@link List#set} and {@link ListIterator#set}.
     * It is possible for the type parameter {@code T} of the returned list
     * to differ from the array's component type. This can occur, for example,
     * if the array argument type has been upcast from its component type:
     *
     * {@snippet :
     *    String[] strings = new String[1];
     *    List<Object> objects = Arrays.asList((Object[])strings);
     * }
     *
     * Writing an element into the returned list may result in an
     * {@link ArrayStoreException} instead of {@link ClassCastException} being
     * thrown if the element is incompatible with the underlying array's
     * component type:
     *
     * {@snippet :
     *    objects.set(0, Integer.valueOf(0)); // throws ArrayStoreException
     * }

-------------

PR: https://git.openjdk.org/jdk/pull/12135

From mchung at openjdk.org  Thu Feb  9 00:40:49 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Thu, 9 Feb 2023 00:40:49 GMT
Subject: Integrated: JDK-8301704: Shorten the number of GCs in
 UnloadingTest.java to verify a class loader not being unloaded
In-Reply-To: <bdUKXSHJGqFT5OdTZgU21MwCcuP9aAkg3lIP3WQbyJY=.c41376be-4fc1-409c-a2c1-42f1d0b30aba@github.com>
References: <bdUKXSHJGqFT5OdTZgU21MwCcuP9aAkg3lIP3WQbyJY=.c41376be-4fc1-409c-a2c1-42f1d0b30aba@github.com>
Message-ID: <J_tS3pcgIVOU4wI8lfFdRzzdHlv03RrxAWHWe7glFk0=.8bc333dd-f5c9-461f-a612-db6716649d0e@github.com>

On Thu, 2 Feb 2023 20:09:22 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> `test/jdk/java/lang/invoke/defineHiddenClass/UnloadingTest.java` defines hidden classes and verify cases that a class loader is not unloaded using `ForceGC::wait`.    ForceGC::wait` defaults the timeout to 1000ms * jtreg timeout factor, which is designed to work well to expect an object being reclaimed, i.e. the boolean supplier returns true.   On the other hand, if the boolean supplier never returns true, the method returns after it timeouts which may be long depending on the timeout factor. 
> 
> This PR adds a variant of `ForceGC::wait` to take a timeout parameter and tests can specify the timeout to reduce the time it takes testing a strongly reachable object not being reclaimed.

This pull request has now been integrated.

Changeset: c8cc7b67
Author:    Mandy Chung <mchung at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/c8cc7b67dbb4633e365a5d6e44419775ebce9d4a
Stats:     36 lines in 2 files changed: 29 ins; 0 del; 7 mod

8301704: Shorten the number of GCs in UnloadingTest.java to verify a class loader not being unloaded

Reviewed-by: rriggs

-------------

PR: https://git.openjdk.org/jdk/pull/12392

From xgong at openjdk.org  Thu Feb  9 02:23:45 2023
From: xgong at openjdk.org (Xiaohong Gong)
Date: Thu, 9 Feb 2023 02:23:45 GMT
Subject: RFR: 8293198: [vectorapi] Improve the implementation of
 VectorMask.indexInRange() [v2]
In-Reply-To: <7BM1vdj6ShoztqsIgXgTjzVMTiZtdSCL8JqxwXz44Kw=.0f5a61df-4838-4043-8155-dc3ae45ca99b@github.com>
References: <fN58bi3n01tqWpG0-jjUPZQe8hmls2GQ5X3NL2o1RPg=.80e7965d-50af-4fac-bd7c-0a2b99cffe7e@github.com>
 <0dNCRVASsdME6qS79u5z7c6mikJs1jfucfo54lo71ik=.d8c2dc6e-bc60-499f-899c-880a2219b052@github.com>
 <7BM1vdj6ShoztqsIgXgTjzVMTiZtdSCL8JqxwXz44Kw=.0f5a61df-4838-4043-8155-dc3ae45ca99b@github.com>
Message-ID: <4Irze24k-ZXJ_i6qrMzPLctkprkbCIcZ1FQ7wTVDOms=.2cbbdc2f-51f7-4867-9e15-bd33d7e929ba@github.com>

On Mon, 6 Feb 2023 17:39:42 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>> Xiaohong Gong has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add smaller array size for benchmark tests
>
> I think it would be useful to adjust the naming and comments of some methods to make it clearer the method parameter constraints.
> 
> `indexInRange0Helper` is now called if the index is partially or totally out of range at the lower or upper ends and `indexInRange0` is called if partially or totally out of range at the upper end.
> e.g. a more literal naming could be:
> `AbstractMask::indexInRange0Helper` -> `AbstractMask::indexPartiallyInRangeHelper`
> `VectorSupport::indexInRange` -> VectorSupport::indexPartiallyInUpperRange`
> ?
> 
> IIUC the performance numbers show that when the array is not a multiple of the vector size there is still quite an impact overall to calling `VectorSupport::indexInRange` for the last loop iteration. I am guessing the overall loop shape is different which impacts other optimizations?
> 
> To do this more optimally likely requires a loop transformation where the last loop iteration is peeled off, but that's a harder transformation in one of the more complicated areas of C2 (although it already supports pre/post loop, so maybe its possible to leverage that?).

Hi @PaulSandoz ?all your comments have been addressed. Could you please take a look at it again? Thanks a lot!

-------------

PR: https://git.openjdk.org/jdk/pull/12064

From msheppar at openjdk.org  Thu Feb  9 02:51:43 2023
From: msheppar at openjdk.org (Mark Sheppard)
Date: Thu, 9 Feb 2023 02:51:43 GMT
Subject: RFR: 8301737:
 java/rmi/server/UnicastRemoteObject/serialFilter/FilterUROTest.java fail with
 -Xcomp [v3]
In-Reply-To: <zMo8OEhYAKUz5LWOssEWEUQDoySJo7hsL7_KAzfNU34=.2309b7bb-5e1d-47e8-b932-aedfbce71e5b@github.com>
References: <l5m5_9io2QMSFNY7dBHT3Nr2I9Er8wmd92Ze8FP-XE0=.a40d29be-77be-4719-a0a0-71d032eea1e5@github.com>
 <zMo8OEhYAKUz5LWOssEWEUQDoySJo7hsL7_KAzfNU34=.2309b7bb-5e1d-47e8-b932-aedfbce71e5b@github.com>
Message-ID: <GOFO2mat5EvwAwVkxrmYCytPyv5ouu4GUuJkqAOI2Oo=.f8a3672e-9718-456a-8caf-54c82645d6a7@github.com>

On Tue, 7 Feb 2023 08:27:57 GMT, SUN Guoyun <duke at openjdk.org> wrote:

>> Hi all,
>> When -Xcomp be used, this testcase will use more codecaches, causing the GC to be triggered early, then causing this test failed on LoongArch64 architecture.
>> 
>> This PR fix the issue, Please help review it.
>> 
>> Thanks.
>
> SUN Guoyun has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8301737: java/rmi/server/UnicastRemoteObject/serialFilter/FilterUROTest.java fail with -Xcomp

if this failure can be reproduced consistently, you could add the following properties to the run command of the test
-Dsun.rmi.runtime.logLevel=VERBOSE -Djava.rmi.server.logCalls=true -Dsun.rmi.server.logLevel=VERBOSE -Dsun.rmi.transport.logLevel=VERBOSE -Dsun.rmi.transport.tcp.logLevel=VERBOSE -Dsun.rmi.dgc.logLevel=VERBOSE
i.e.
@run testng/othervm -Dsun.rmi.runtime.logLevel=VERBOSE -Djava.rmi.server.logCalls=true -Dsun.rmi.server.logLevel=VERBOSE -Dsun.rmi.transport.logLevel=VERBOSE -Dsun.rmi.transport.tcp.logLevel=VERBOSE -Dsun.rmi.dgc.logLevel=VERBOSE FilterUROTes

these will produce log traces on stderr, which is recorded in the test's jtr file, and in the event of the failure occuring this trace might be useful in the diagnosis of the issue, for example, whether or not the removeTarget method is being invoked on the ObjectTable. You will see objects being added with trace such as:

FINER: MainThread: add object [0:0:0, 2]

FINER: MainThread: add object [-3d215748:18634027149:-7fff, 248225399703400139]

Feb 09, 2023 2:30:21 AM sun.rmi.transport.Transport exportObject
FINER: MainThread: add object [-3d215748:18634027149:-7ffd, 651168978636195090]

-------------

PR: https://git.openjdk.org/jdk/pull/12399

From jbhateja at openjdk.org  Thu Feb  9 05:16:46 2023
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Thu, 9 Feb 2023 05:16:46 GMT
Subject: RFR: JDK-8300808: Accelerate Base64 on x86 for AVX2 [v11]
In-Reply-To: <TAQjhBbKeWUHAAnpBx3Q1xtPA39-6Dlh_TWA4BIOyUw=.9233a61e-d595-45ac-be57-17976e4b629b@github.com>
References: <9zN3bjyMEikXYOlpjTy9_QPc-9usYiBJMUFdb-TaVrQ=.e8f65ce9-ac0f-4f8d-9c6b-b39ae1c26cd2@github.com>
 <PoM3RCbgsT0X64L1fHCggfoUZB4kNLCRz6kgU8u18Vw=.7754c1ba-ff32-4f2a-b991-3d042b2377d8@github.com>
 <TAQjhBbKeWUHAAnpBx3Q1xtPA39-6Dlh_TWA4BIOyUw=.9233a61e-d595-45ac-be57-17976e4b629b@github.com>
Message-ID: <rNYQkK8PAgX-QpFfR85NR7urgRnkx7yUDxiF6HylrRo=.bd71a8d1-82fb-451c-94cd-8bb28b0f0bd1@github.com>

On Tue, 7 Feb 2023 14:27:49 GMT, Scott Gibbons <duke at openjdk.org> wrote:

> @sviswa7 Can you please share the test(s) you used to determine the stated failures? I've run all of the tier1-3 tests in the suite with no failures. Plus, if what you say is true, then the same logic would apply for the non-URL case as well as it applies to 0x2F ('/') in the same manner as 0x5F ('_').
> 
> If your test(s) do indeed show the failure, we should probably add them to the test suite. Thanks.

Stub processes the input till last legal byte and falls over to java implementation for error handling, thus URL decoder will not find any anomaly on encountering characters ( _ or - ) in input sequence, the behavior will still be functionally correct. Problem will only show up in JMH micro as a perf degradation, our micro handles MIME and Base64 decoder can you kindly extend it for URL decoder with special characters in input sequence.

-------------

PR: https://git.openjdk.org/jdk/pull/12126

From darcy at openjdk.org  Thu Feb  9 06:46:17 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Thu, 9 Feb 2023 06:46:17 GMT
Subject: RFR: JDK-8301202: Port fdlibm log to Java [v3]
In-Reply-To: <t0yhKjTMAtSuAZjI0unvr73crUuYEM-2HQ8sUI2_sNU=.82036639-980d-46de-a201-3d85bd84563d@github.com>
References: <t0yhKjTMAtSuAZjI0unvr73crUuYEM-2HQ8sUI2_sNU=.82036639-980d-46de-a201-3d85bd84563d@github.com>
Message-ID: <m4vAdpkBQidw-0NRwuFenBJoCXBa0C1m6nWpRezocmo=.aef85774-0baf-46a2-86a9-89d100b3f7e9@github.com>

> Next up on the FDLIBM porting countdown, the log method.
> 
> Original C vs transliteration port:
> 
> 
> $ diff -w Log.c Log.translit.java 
> 1c1
> < /* __ieee754_log(x)
> ---
>>     /**
> 51,58c51,52
> < 
> < #include "fdlibm.h"
> < 
> < #ifdef __STDC__
> < static const double
> < #else
> < static double
> < #endif
> ---
>>     static class Log {
>>         private static final  double
> 70c64
> < static double zero   =  0.0;
> ---
>>         private static double zero   =  0.0;
> 72,78c66
> < #ifdef __STDC__
> <         double __ieee754_log(double x)
> < #else
> <         double __ieee754_log(x)
> <         double x;
> < #endif
> < {
> ---
>>         static double compute(double x) {
> 81c69
> <         unsigned lx;
> ---
>>             /*unsigned*/ int lx;
> 98c86,87
> <         __HI(x) = hx|(i^0x3ff00000);    /* normalize x or x/2 */
> ---
>>             // __HI(x) = hx|(i^0x3ff00000);    /* normalize x or x/2 */
>>             x =__HI(x, hx|(i^0x3ff00000));    /* normalize x or x/2 */
> 128a118
>>     }
> 
> 
> Transliteration port vs more idiomatic port:
> 
> 
> $ diff -w  Log.translit.java Log.fdlibm.java 
> 2c2
> <      * Return the logarithm of x
> ---
>>      * Return the (natural) logarithm of x
> 53,62c53,54
> <             ln2_hi  =  6.93147180369123816490e-01,  /* 3fe62e42 fee00000 */
> <             ln2_lo  =  1.90821492927058770002e-10,  /* 3dea39ef 35793c76 */
> <             two54   =  1.80143985094819840000e+16,  /* 43500000 00000000 */
> <             Lg1 = 6.666666666666735130e-01,  /* 3FE55555 55555593 */
> <             Lg2 = 3.999999999940941908e-01,  /* 3FD99999 9997FA04 */
> <             Lg3 = 2.857142874366239149e-01,  /* 3FD24924 94229359 */
> <             Lg4 = 2.222219843214978396e-01,  /* 3FCC71C5 1D8E78AF */
> <             Lg5 = 1.818357216161805012e-01,  /* 3FC74664 96CB03DE */
> <             Lg6 = 1.531383769920937332e-01,  /* 3FC39A09 D078C69F */
> <             Lg7 = 1.479819860511658591e-01;  /* 3FC2F112 DF3E5244 */
> ---
>>             ln2_hi = 0x1.62e42feep-1,       // 6.93147180369123816490e-01
>>             ln2_lo = 0x1.a39ef35793c76p-33, // 1.90821492927058770002e-10
> 64c56,64
> <         private static double zero   =  0.0;
> ---
>>             Lg1    = 0x1.5555555555593p-1,  // 6.666666666666735130e-01
>>             Lg2    = 0x1.999999997fa04p-2,  // 3.999999999940941908e-01
>>             Lg3    = 0x1.2492494229359p-2,  // 2.857142874366239149e-01
>>             Lg4    = 0x1.c71c51d8e78afp-3,  // 2.222219843214978396e-01
>>             Lg5    = 0x1.7466496cb03dep-3,  // 1.818357216161805012e-01
>>             Lg6    = 0x1.39a09d078c69fp-3,  // 1.531383769920937332e-01
>>             Lg7    = 0x1.2f112df3e5244p-3;  // 1.479819860511658591e-01
>> 
>>         private static final double zero = 0.0;
> 71,72c71,72
> <             hx = __HI(x);           /* high word of x */
> <             lx = __LO(x);           /* low  word of x */
> ---
>>             hx = __HI(x);           // high word of x
>>             lx = __LO(x);           // low  word of x
> 75,80c75,87
> <             if (hx < 0x00100000) {                  /* x < 2**-1022  */
> <                 if (((hx&0x7fffffff)|lx)==0)
> <                     return -two54/zero;             /* log(+-0)=-inf */
> <                 if (hx<0) return (x-x)/zero;        /* log(-#) = NaN */
> <                 k -= 54; x *= two54; /* subnormal number, scale up x */
> <                 hx = __HI(x);               /* high word of x */
> ---
>>             if (hx < 0x0010_0000) {                  // x < 2**-1022
>>                 if (((hx & 0x7fff_ffff) | lx) ==0) { // log(+-0) = -inf
>>                     return -TWO54/zero;
>>                 }
>>                 if (hx < 0) {                        // log(-#) = NaN
>>                     return (x - x)/zero;
>>                 }
>>                 k -= 54;
>>                 x *= TWO54;    // subnormal number, scale up x
>>                 hx = __HI(x);  // high word of x
>>             }
>>             if (hx >= 0x7ff0_0000) {
>>                 return x+x;
> 82d88
> <             if (hx >= 0x7ff00000) return x+x;
> 84,87c90,92
> <             hx &= 0x000fffff;
> <             i = (hx+0x95f64)&0x100000;
> <             // __HI(x) = hx|(i^0x3ff00000);    /* normalize x or x/2 */
> <             x =__HI(x, hx|(i^0x3ff00000));    /* normalize x or x/2 */
> ---
>>             hx &= 0x000f_ffff;
>>             i = (hx + 0x9_5f64) & 0x10_0000;
>>             x =__HI(x, hx|(i ^ 0x3ff0_0000));  // normalize x or x/2
> 90c95
> <             if((0x000fffff&(2+hx))<3) {     /* |f| < 2**-20 */
> ---
>>             if ((0x000f_ffff & (2 + hx)) < 3) {// |f| < 2**-20
> 92,93c97,102
> <                     if (k==0) return zero;
> <                     else {dk=(double)k; return dk*ln2_hi+dk*ln2_lo;}
> ---
>>                     if (k == 0) {
>>                         return zero;
>>                     } else {
>>                         dk = (double)k;
>>                         return dk*ln2_hi + dk*ln2_lo;
>>                     }
> 96,97c105,110
> <                 if(k==0) return f-R; else {dk=(double)k;
> <                     return dk*ln2_hi-((R-dk*ln2_lo)-f);}
> ---
>>                 if (k == 0) {
>>                     return f - R;
>>                 } else {
>>                     dk = (double)k;
>>                     return dk*ln2_hi - ((R - dk*ln2_lo) - f);
>>                 }
> 102c115
> <             i = hx-0x6147a;
> ---
>>             i = hx - 0x6_147a;
> 111c124,126
> <                 if(k==0) return f-(hfsq-s*(hfsq+R)); else
> ---
>>                 if (k == 0) {
>>                     return f-(hfsq-s*(hfsq+R));
>>                 } else {
> 112a128,131
>>                 }
>>             } else {
>>                 if (k == 0) {
>>                     return f - s*(f - R);
> 114d132
> <                 if(k==0) return f-s*(f-R); else
> 115a134
>>                 }
> 
> 
> The transliteration port passes the "exhausting" test of all float arguments when run against a JDK 20 build. The idiomatic port matches the transliteration port on the same test.

Joe Darcy has updated the pull request incrementally with two additional commits since the last revision:

 - Appease jcheck.
 - Add StrictMath.log vs Math.log differences.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12465/files
  - new: https://git.openjdk.org/jdk/pull/12465/files/b7f0e8d2..cafd1f1f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12465&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12465&range=01-02

  Stats: 102 lines in 2 files changed: 101 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/12465.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12465/head:pull/12465

PR: https://git.openjdk.org/jdk/pull/12465

From darcy at openjdk.org  Thu Feb  9 06:46:17 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Thu, 9 Feb 2023 06:46:17 GMT
Subject: RFR: JDK-8301202: Port fdlibm log to Java [v2]
In-Reply-To: <X7MZBHvvWw7e6CPWi0GgwrsL-PQIIHvTLr2EFcxa5EE=.281c3985-bab6-46c3-b0fb-a71250748441@github.com>
References: <t0yhKjTMAtSuAZjI0unvr73crUuYEM-2HQ8sUI2_sNU=.82036639-980d-46de-a201-3d85bd84563d@github.com>
 <X7MZBHvvWw7e6CPWi0GgwrsL-PQIIHvTLr2EFcxa5EE=.281c3985-bab6-46c3-b0fb-a71250748441@github.com>
Message-ID: <a_S4cKrJgmF6oLQMkVP3tkgWl0lcvlRKd7MvsKXw0pQ=.4d0f780b-3236-49f4-a66e-1fd5d2c5307a@github.com>

On Wed, 8 Feb 2023 21:37:15 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Next up on the FDLIBM porting countdown, the log method.
>> 
>> Original C vs transliteration port:
>> 
>> 
>> $ diff -w Log.c Log.translit.java 
>> 1c1
>> < /* __ieee754_log(x)
>> ---
>>>     /**
>> 51,58c51,52
>> < 
>> < #include "fdlibm.h"
>> < 
>> < #ifdef __STDC__
>> < static const double
>> < #else
>> < static double
>> < #endif
>> ---
>>>     static class Log {
>>>         private static final  double
>> 70c64
>> < static double zero   =  0.0;
>> ---
>>>         private static double zero   =  0.0;
>> 72,78c66
>> < #ifdef __STDC__
>> <         double __ieee754_log(double x)
>> < #else
>> <         double __ieee754_log(x)
>> <         double x;
>> < #endif
>> < {
>> ---
>>>         static double compute(double x) {
>> 81c69
>> <         unsigned lx;
>> ---
>>>             /*unsigned*/ int lx;
>> 98c86,87
>> <         __HI(x) = hx|(i^0x3ff00000);    /* normalize x or x/2 */
>> ---
>>>             // __HI(x) = hx|(i^0x3ff00000);    /* normalize x or x/2 */
>>>             x =__HI(x, hx|(i^0x3ff00000));    /* normalize x or x/2 */
>> 128a118
>>>     }
>> 
>> 
>> Transliteration port vs more idiomatic port:
>> 
>> 
>> $ diff -w  Log.translit.java Log.fdlibm.java 
>> 2c2
>> <      * Return the logarithm of x
>> ---
>>>      * Return the (natural) logarithm of x
>> 53,62c53,54
>> <             ln2_hi  =  6.93147180369123816490e-01,  /* 3fe62e42 fee00000 */
>> <             ln2_lo  =  1.90821492927058770002e-10,  /* 3dea39ef 35793c76 */
>> <             two54   =  1.80143985094819840000e+16,  /* 43500000 00000000 */
>> <             Lg1 = 6.666666666666735130e-01,  /* 3FE55555 55555593 */
>> <             Lg2 = 3.999999999940941908e-01,  /* 3FD99999 9997FA04 */
>> <             Lg3 = 2.857142874366239149e-01,  /* 3FD24924 94229359 */
>> <             Lg4 = 2.222219843214978396e-01,  /* 3FCC71C5 1D8E78AF */
>> <             Lg5 = 1.818357216161805012e-01,  /* 3FC74664 96CB03DE */
>> <             Lg6 = 1.531383769920937332e-01,  /* 3FC39A09 D078C69F */
>> <             Lg7 = 1.479819860511658591e-01;  /* 3FC2F112 DF3E5244 */
>> ---
>>>             ln2_hi = 0x1.62e42feep-1,       // 6.93147180369123816490e-01
>>>             ln2_lo = 0x1.a39ef35793c76p-33, // 1.90821492927058770002e-10
>> 64c56,64
>> <         private static double zero   =  0.0;
>> ---
>>>             Lg1    = 0x1.5555555555593p-1,  // 6.666666666666735130e-01
>>>             Lg2    = 0x1.999999997fa04p-2,  // 3.999999999940941908e-01
>>>             Lg3    = 0x1.2492494229359p-2,  // 2.857142874366239149e-01
>>>             Lg4    = 0x1.c71c51d8e78afp-3,  // 2.222219843214978396e-01
>>>             Lg5    = 0x1.7466496cb03dep-3,  // 1.818357216161805012e-01
>>>             Lg6    = 0x1.39a09d078c69fp-3,  // 1.531383769920937332e-01
>>>             Lg7    = 0x1.2f112df3e5244p-3;  // 1.479819860511658591e-01
>>> 
>>>         private static final double zero = 0.0;
>> 71,72c71,72
>> <             hx = __HI(x);           /* high word of x */
>> <             lx = __LO(x);           /* low  word of x */
>> ---
>>>             hx = __HI(x);           // high word of x
>>>             lx = __LO(x);           // low  word of x
>> 75,80c75,87
>> <             if (hx < 0x00100000) {                  /* x < 2**-1022  */
>> <                 if (((hx&0x7fffffff)|lx)==0)
>> <                     return -two54/zero;             /* log(+-0)=-inf */
>> <                 if (hx<0) return (x-x)/zero;        /* log(-#) = NaN */
>> <                 k -= 54; x *= two54; /* subnormal number, scale up x */
>> <                 hx = __HI(x);               /* high word of x */
>> ---
>>>             if (hx < 0x0010_0000) {                  // x < 2**-1022
>>>                 if (((hx & 0x7fff_ffff) | lx) ==0) { // log(+-0) = -inf
>>>                     return -TWO54/zero;
>>>                 }
>>>                 if (hx < 0) {                        // log(-#) = NaN
>>>                     return (x - x)/zero;
>>>                 }
>>>                 k -= 54;
>>>                 x *= TWO54;    // subnormal number, scale up x
>>>                 hx = __HI(x);  // high word of x
>>>             }
>>>             if (hx >= 0x7ff0_0000) {
>>>                 return x+x;
>> 82d88
>> <             if (hx >= 0x7ff00000) return x+x;
>> 84,87c90,92
>> <             hx &= 0x000fffff;
>> <             i = (hx+0x95f64)&0x100000;
>> <             // __HI(x) = hx|(i^0x3ff00000);    /* normalize x or x/2 */
>> <             x =__HI(x, hx|(i^0x3ff00000));    /* normalize x or x/2 */
>> ---
>>>             hx &= 0x000f_ffff;
>>>             i = (hx + 0x9_5f64) & 0x10_0000;
>>>             x =__HI(x, hx|(i ^ 0x3ff0_0000));  // normalize x or x/2
>> 90c95
>> <             if((0x000fffff&(2+hx))<3) {     /* |f| < 2**-20 */
>> ---
>>>             if ((0x000f_ffff & (2 + hx)) < 3) {// |f| < 2**-20
>> 92,93c97,102
>> <                     if (k==0) return zero;
>> <                     else {dk=(double)k; return dk*ln2_hi+dk*ln2_lo;}
>> ---
>>>                     if (k == 0) {
>>>                         return zero;
>>>                     } else {
>>>                         dk = (double)k;
>>>                         return dk*ln2_hi + dk*ln2_lo;
>>>                     }
>> 96,97c105,110
>> <                 if(k==0) return f-R; else {dk=(double)k;
>> <                     return dk*ln2_hi-((R-dk*ln2_lo)-f);}
>> ---
>>>                 if (k == 0) {
>>>                     return f - R;
>>>                 } else {
>>>                     dk = (double)k;
>>>                     return dk*ln2_hi - ((R - dk*ln2_lo) - f);
>>>                 }
>> 102c115
>> <             i = hx-0x6147a;
>> ---
>>>             i = hx - 0x6_147a;
>> 111c124,126
>> <                 if(k==0) return f-(hfsq-s*(hfsq+R)); else
>> ---
>>>                 if (k == 0) {
>>>                     return f-(hfsq-s*(hfsq+R));
>>>                 } else {
>> 112a128,131
>>>                 }
>>>             } else {
>>>                 if (k == 0) {
>>>                     return f - s*(f - R);
>> 114d132
>> <                 if(k==0) return f-s*(f-R); else
>> 115a134
>>>                 }
>> 
>> 
>> The transliteration port passes the "exhausting" test of all float arguments when run against a JDK 20 build. The idiomatic port matches the transliteration port on the same test.
>
> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Improve declarations of Log host classes.

Pushing an update with some testing improvements:
* Added a test in java/lang/Math to probe special cases of {Math, StrictMath}.log
* After probing more than 2 billion double numbers, found 5 where Math.log and StrictMath.log return a different answer in my development environment.

-------------

PR: https://git.openjdk.org/jdk/pull/12465

From duke at openjdk.org  Thu Feb  9 07:22:42 2023
From: duke at openjdk.org (SUN Guoyun)
Date: Thu, 9 Feb 2023 07:22:42 GMT
Subject: RFR: 8301737:
 java/rmi/server/UnicastRemoteObject/serialFilter/FilterUROTest.java fail with
 -Xcomp [v3]
In-Reply-To: <zMo8OEhYAKUz5LWOssEWEUQDoySJo7hsL7_KAzfNU34=.2309b7bb-5e1d-47e8-b932-aedfbce71e5b@github.com>
References: <l5m5_9io2QMSFNY7dBHT3Nr2I9Er8wmd92Ze8FP-XE0=.a40d29be-77be-4719-a0a0-71d032eea1e5@github.com>
 <zMo8OEhYAKUz5LWOssEWEUQDoySJo7hsL7_KAzfNU34=.2309b7bb-5e1d-47e8-b932-aedfbce71e5b@github.com>
Message-ID: <te1-eWfA6a8qPwv3_d1plWnFO9eHH_nX3zzgWsYzubc=.eddcfcca-7e85-452b-b7a8-f6f85524593e@github.com>

On Tue, 7 Feb 2023 08:27:57 GMT, SUN Guoyun <duke at openjdk.org> wrote:

>> Hi all,
>> When -Xcomp be used, this testcase will use more codecaches, causing the GC to be triggered early, then causing this test failed on LoongArch64 architecture.
>> 
>> This PR fix the issue, Please help review it.
>> 
>> Thanks.
>
> SUN Guoyun has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8301737: java/rmi/server/UnicastRemoteObject/serialFilter/FilterUROTest.java fail with -Xcomp

As you can guess, this could be a BUG in RMI framework, which has a WeakReference but not Strong-Reference var `weakImpl`, can be collected by GC in a timely manner. and there are three thread.

putTarget()         // exists in server thread
getTarget()         // exists in client thread
removeTarget()  // exists in reaper thread

So, if GC is triggered before client thread, then reaper thread must recycle impl and target. But I'm not sure what to do with variable `weakImpl` at the moment.
<pre><code class="java">
// src/java.rmi/share/classes/sun/rmi/transport/Target.java
 45 public final class Target {                                                     
 50     /** weak reference to remote object implementation */                       
 51     private final WeakRef weakImpl;   // Is it reasonable to modify it to a strong ref?
</code></pre>

-------------

PR: https://git.openjdk.org/jdk/pull/12399

From duke at openjdk.org  Thu Feb  9 07:25:44 2023
From: duke at openjdk.org (SUN Guoyun)
Date: Thu, 9 Feb 2023 07:25:44 GMT
Subject: RFR: 8301737:
 java/rmi/server/UnicastRemoteObject/serialFilter/FilterUROTest.java fail with
 -Xcomp [v3]
In-Reply-To: <zMo8OEhYAKUz5LWOssEWEUQDoySJo7hsL7_KAzfNU34=.2309b7bb-5e1d-47e8-b932-aedfbce71e5b@github.com>
References: <l5m5_9io2QMSFNY7dBHT3Nr2I9Er8wmd92Ze8FP-XE0=.a40d29be-77be-4719-a0a0-71d032eea1e5@github.com>
 <zMo8OEhYAKUz5LWOssEWEUQDoySJo7hsL7_KAzfNU34=.2309b7bb-5e1d-47e8-b932-aedfbce71e5b@github.com>
Message-ID: <KZ-z0YD3fRBjhu-svQet-aFSIs9_asBbkiOW-OV8Zmk=.46e9079d-2f61-48d1-b229-8ce70e8583c3@github.com>

On Tue, 7 Feb 2023 08:27:57 GMT, SUN Guoyun <duke at openjdk.org> wrote:

>> Hi all,
>> When -Xcomp be used, this testcase will use more codecaches, causing the GC to be triggered early, then causing this test failed on LoongArch64 architecture.
>> 
>> This PR fix the issue, Please help review it.
>> 
>> Thanks.
>
> SUN Guoyun has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8301737: java/rmi/server/UnicastRemoteObject/serialFilter/FilterUROTest.java fail with -Xcomp

I've tried the scenario `moving the declaration of the variable impl outside of the try block, it is still assigned within the try block,` you suggested and it doesn't fix the problem.

-------------

PR: https://git.openjdk.org/jdk/pull/12399

From jwilhelm at openjdk.org  Thu Feb  9 07:49:49 2023
From: jwilhelm at openjdk.org (Jesper Wilhelmsson)
Date: Thu, 9 Feb 2023 07:49:49 GMT
Subject: RFR: Merge jdk20
Message-ID: <FSx6A_Vz1okUT1ctC5bJP9l7E5fx-f2eltAgnJly1Zc=.1fb6f527-f4e3-4538-86da-21c44dd02a16@github.com>

Forwardport JDK 20 -> JDK 21

-------------

Commit messages:
 - Merge remote-tracking branch 'jdk20/master' into Merge_jdk20
 - 8301989: new javax.swing.text.DefaultCaret().setBlinkRate(N) results in NPE
 - 8301863: ObjectInputFilter example incorrectly calls rejectUndecidedClass

The merge commit only contains trivial merges, so no merge-specific webrevs have been generated.

Changes: https://git.openjdk.org/jdk/pull/12484/files
  Stats: 69 lines in 3 files changed: 50 ins; 9 del; 10 mod
  Patch: https://git.openjdk.org/jdk/pull/12484.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12484/head:pull/12484

PR: https://git.openjdk.org/jdk/pull/12484

From asotona at openjdk.org  Thu Feb  9 08:44:41 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Thu, 9 Feb 2023 08:44:41 GMT
Subject: RFR: 8294982: Implementation of Classfile API [v15]
In-Reply-To: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
References: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
Message-ID: <hr8eti6ytvV05JFRr5hYLWy7yBla9mpI8vKKfaaFR-k=.a92f7bea-6400-4f95-a40c-d57192013f19@github.com>

> This is root pull request with Classfile API implementation, tests and benchmarks initial drop into JDK.
> 
> Following pull requests consolidating JDK class files parsing, generating, and transforming ([JDK-8294957](https://bugs.openjdk.org/browse/JDK-8294957)) will chain to this one.
> 
> Classfile API development is tracked at:
> https://github.com/openjdk/jdk-sandbox/tree/classfile-api-branch
> 
> Development branch of consolidated JDK class files parsing, generating, and transforming is at:
> https://github.com/openjdk/jdk-sandbox/tree/classfile-api-dev-branch
> 
> Classfile API [JEP](https://bugs.openjdk.org/browse/JDK-8280389) and [online API documentation](https://htmlpreview.github.io/?https://raw.githubusercontent.com/openjdk/jdk-sandbox/classfile-api-javadoc-branch/doc/classfile-api/javadoc/java.base/jdk/internal/classfile/package-summary.html) is also available.
> 
> Please take you time to review this non-trivial JDK addition.
> 
> Thank you,
> Adam

Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:

  AttributeElement.Kind removal (#48)

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10982/files
  - new: https://git.openjdk.org/jdk/pull/10982/files/df08b351..753e6847

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10982&range=14
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10982&range=13-14

  Stats: 160 lines in 16 files changed: 0 ins; 89 del; 71 mod
  Patch: https://git.openjdk.org/jdk/pull/10982.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10982/head:pull/10982

PR: https://git.openjdk.org/jdk/pull/10982

From duke at openjdk.org  Thu Feb  9 08:48:17 2023
From: duke at openjdk.org (SUN Guoyun)
Date: Thu, 9 Feb 2023 08:48:17 GMT
Subject: RFR: 8301737:
 java/rmi/server/UnicastRemoteObject/serialFilter/FilterUROTest.java fail with
 -Xcomp [v4]
In-Reply-To: <l5m5_9io2QMSFNY7dBHT3Nr2I9Er8wmd92Ze8FP-XE0=.a40d29be-77be-4719-a0a0-71d032eea1e5@github.com>
References: <l5m5_9io2QMSFNY7dBHT3Nr2I9Er8wmd92Ze8FP-XE0=.a40d29be-77be-4719-a0a0-71d032eea1e5@github.com>
Message-ID: <LCJW-DKImXCmpxwBGKJPmSKAUnz9dHg-T09tqD9-SMU=.87d63cd0-6b22-4af8-9786-bd6c75d04ca2@github.com>

> Hi all,
> When -Xcomp be used, this testcase will use more codecaches, causing the GC to be triggered early, then causing this test failed on LoongArch64 architecture.
> 
> This PR fix the issue, Please help review it.
> 
> Thanks.

SUN Guoyun has updated the pull request incrementally with one additional commit since the last revision:

  8301737: java/rmi/server/UnicastRemoteObject/serialFilter/FilterUROTest.java fail with -Xcomp

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12399/files
  - new: https://git.openjdk.org/jdk/pull/12399/files/06559478..fff401e6

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12399&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12399&range=02-03

  Stats: 11 lines in 1 file changed: 1 ins; 8 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/12399.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12399/head:pull/12399

PR: https://git.openjdk.org/jdk/pull/12399

From asotona at openjdk.org  Thu Feb  9 08:48:54 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Thu, 9 Feb 2023 08:48:54 GMT
Subject: RFR: 8294982: Implementation of Classfile API [v13]
In-Reply-To: <Jk3w1_xkaBE7C1tt8-1rH4svfdjuyIM3OsJDGQl9Pi4=.e93ed59e-c4a9-4566-aac2-79879bc66241@github.com>
References: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
 <Ej4u9wRtUuLS5LJhMkXwmown_MGuwR0gH9ruJ1A1g30=.f6405576-6655-4252-9135-ebc77765436e@github.com>
 <u6VmkXvghsyyf7qwyHyDpcqZ-wVCfFnZgOoB_wiz2-A=.ce2c44e1-81b0-4851-811c-5f4fd3fdda62@github.com>
 <ubqEqa6BH65hdOBcovhGQACL7JtzTepvG57XeC7z0K4=.045606e5-9421-4d8f-8e7f-e6bd9f529e98@github.com>
 <Jk3w1_xkaBE7C1tt8-1rH4svfdjuyIM3OsJDGQl9Pi4=.e93ed59e-c4a9-4566-aac2-79879bc66241@github.com>
Message-ID: <0l15xDaAOrY1jj8o_GdY6kJFNLVzUEEFy2Versfm9vc=.107f83d9-6f72-43a4-99bd-4762c37d268e@github.com>

On Wed, 8 Feb 2023 11:16:14 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> `ofSymbols` is an alternative to `of` when conflicting method parameters.
>> In such case `of` refers to CP entries and `ofSymbols` refer to independent symbols describing the objects, like for example `ClassDesc`, `MethodTypeDesc`, `PackageDesc`
>
>> `ofSymbols` is an alternative to `of` when conflicting method parameters. In such case `of` refers to CP entries and `ofSymbols` refer to independent symbols describing the objects, like for example `ClassDesc`, `MethodTypeDesc`, `PackageDesc`
> 
> Yes, I was noting that some classes e.g. ModuleProvideInfo do not seem to follow this logic:
> 
> 
> static ModuleProvideInfo of(ClassEntry provides, ClassEntry... providesWith) { ... }
> 
> static ModuleProvideInfo of(ClassDesc provides, List<ClassDesc> providesWith) { ... }

Yes, the alternate `ofSymbols` is used only when there is a conflict, which is not the case of `ModuleProvideInfo` factory methods, there is differentiating first argument.
In case of var-args vs Lists - that is another topic with long history of search for the right balance.

-------------

PR: https://git.openjdk.org/jdk/pull/10982

From duke at openjdk.org  Thu Feb  9 09:48:46 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Thu, 9 Feb 2023 09:48:46 GMT
Subject: RFR: 8301873: Avoid string decoding in ZipFile.Source.getEntryPos
 [v7]
In-Reply-To: <CF983B0JFz9rFPwtQZ-C9QpBYlpm3pfOpvD9pSstLL0=.daf6286d-59d9-4450-aff8-ad003199bd50@github.com>
References: <FkmdspiHVjkAKFqm5kUgwaf55YH5cBbczS_3krqsdFs=.05eca901-f55f-47d9-b1bc-0cf2f5b87536@github.com>
 <CF983B0JFz9rFPwtQZ-C9QpBYlpm3pfOpvD9pSstLL0=.daf6286d-59d9-4450-aff8-ad003199bd50@github.com>
Message-ID: <8700MJpl3hpnrZX4oIKqAXbBNEd5LWXN8SNK3JSqDXs=.4cace602-d522-473a-b5e5-637405dba100@github.com>

On Wed, 8 Feb 2023 16:36:16 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

>> After finding a hash match, getEntryPos needs to compare the lookup name up to the encoded entry name in the CEN. This comparison is done by decoding the entry name into a String. The names can then be compared using the String API. This decoding step adds a significat cost to this method.
>> 
>> This PR suggest to update the string comparison such that in the common case where  both the lookup name and the entry name are encoded in ASCII-compatible UTF-8,  decoding can be avoided and the byte arrays can instead be compared direcly. 
>> 
>> ZipCoder is updated with a new method to compare a string with an encoded byte array range.  The default implementation decodes to string (like the current code), while the UTF-8 implementation uses JavaLangAccess.getBytesNoRepl to get the  bytes. Both methods thes uses Arrays.mismatch for comparison with or without matching trailing slashes. 
>> 
>> Additionally, this PR suggest to make the following updates to getEntryPos:
>> 
>> - The try/catch for IAE is redundant and can be safely removed. (initCEN already checks this and will throws IAE for invalid UTF-8). This seems to give a 3-4% speedup on micros)
>> - A new test InvalidBytesInEntryNameOrComment is a added to verify that initCEN does in fact reject invalid UTF-8 in CEN file names and comments. (I found no existing test coverage for this)
>> - The recursion when looking for "name/" matches is replaced with iteration. We keep track of any "name/" match and return it at the end of the search. (I feel this is easier to follow and it also gives a ~30% speedup for addSlash lookups with no regression on regular lookups)
>> 
>> (My though is that including these additional updates in this PR might reduce reviewer overhead given that it touches the exact same code. I might be wrong on this, please advise :)
>> 
>> I'm seeing a ~17% saving on the micro ZipFileGetEntry.getEntryHit (modified to use xalan.jar):
>> 
>> Baseline:
>> 
>> Benchmark                             (size)  Mode  Cnt    Score   Error  Units
>> ZipFileGetEntry.getEntryHit              512  avgt   15   74.941 ? 1.004  ns/op
>> ZipFileGetEntry.getEntryHit             1024  avgt   15   84.943 ? 1.320  ns/op
>> ZipFileGetEntry.getEntryHitUncached      512  avgt   15  120.371 ? 2.386  ns/op
>> ZipFileGetEntry.getEntryHitUncached     1024  avgt   15  126.128 ? 1.075  ns/op
>> ZipFileGetEntry.getEntryMiss             512  avgt   15   23.818 ? 0.838  ns/op
>> ZipFileGetEntry.getEntryMiss            1024  avgt   15   29.762 ? 5.998  ns/op
>> ZipFileGetEntry.getEntryMissUncached     512  avgt   15   59.405 ? 0.545  ns/op
>> ZipFileGetEntry.getEntryMissUncached    1024  avgt   15   71.840 ? 2.455  ns/op
>> ZipFileGetEntry.getEntrySlash            512  avgt   15  135.621 ? 4.341  ns/op
>> ZipFileGetEntry.getEntrySlash           1024  avgt   15  134.190 ? 2.141  ns/op
>> 
>> 
>> 
>> PR:
>> 
>> 
>> Benchmark                             (size)  Mode  Cnt    Score   Error  Units
>> ZipFileGetEntry.getEntryHit              512  avgt   15   62.267 ? 1.329  ns/op
>> ZipFileGetEntry.getEntryHit             1024  avgt   15   72.916 ? 2.428  ns/op
>> ZipFileGetEntry.getEntryHitUncached      512  avgt   15  101.630 ? 1.154  ns/op
>> ZipFileGetEntry.getEntryHitUncached     1024  avgt   15  113.161 ? 0.502  ns/op
>> ZipFileGetEntry.getEntryMiss             512  avgt   15   23.003 ? 1.191  ns/op
>> ZipFileGetEntry.getEntryMiss            1024  avgt   15   23.236 ? 1.114  ns/op
>> ZipFileGetEntry.getEntryMissUncached     512  avgt   15   56.781 ? 1.505  ns/op
>> ZipFileGetEntry.getEntryMissUncached    1024  avgt   15   67.767 ? 1.963  ns/op
>> ZipFileGetEntry.getEntrySlash            512  avgt   15   73.745 ? 2.717  ns/op
>> ZipFileGetEntry.getEntrySlash           1024  avgt   15   75.784 ? 1.051  ns/op
>> 
>> 
>> To assess the impact on startup/warmup, I made a main method class which measures the total time of calling ZipFile.getEntry for all entries in the 109 JAR file dependenies of spring-petclinic. The shows a nice improvement (time in micros):
>> 
>> 
>> Percentile Baseline Patch
>> 50?%          23155 21149
>> 75?%          23598 21454
>> 90?%          23989 21691
>> 95?%          24238 21973
>> 99?%          25270 22446
>> STDEV           792   549
>> Count           500   500
>
> Eirik Bjorsnos has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update the sameHashAndLengthDirLookup to use ASCII example colliding paths, allowing the test to run over all charsets

A somewhat unrelated observation:

If String had a mismatch method, this last regression would probably not have been introduced, since the logic would align better with UTF8ZipCoder which used Arrays.mismatch.

Also, it could help performance since ZipCoder.compare now needs to do back-to-back equals and startsWith over mostly the same bytes.

-------------

PR: https://git.openjdk.org/jdk/pull/12290

From msheppar at openjdk.org  Thu Feb  9 10:06:43 2023
From: msheppar at openjdk.org (Mark Sheppard)
Date: Thu, 9 Feb 2023 10:06:43 GMT
Subject: RFR: 8301737:
 java/rmi/server/UnicastRemoteObject/serialFilter/FilterUROTest.java fail with
 -Xcomp [v4]
In-Reply-To: <LCJW-DKImXCmpxwBGKJPmSKAUnz9dHg-T09tqD9-SMU=.87d63cd0-6b22-4af8-9786-bd6c75d04ca2@github.com>
References: <l5m5_9io2QMSFNY7dBHT3Nr2I9Er8wmd92Ze8FP-XE0=.a40d29be-77be-4719-a0a0-71d032eea1e5@github.com>
 <LCJW-DKImXCmpxwBGKJPmSKAUnz9dHg-T09tqD9-SMU=.87d63cd0-6b22-4af8-9786-bd6c75d04ca2@github.com>
Message-ID: <59GzvjRXFzuF12Wf9sfgITwD8KQ-kxDuNZQz6XFLel0=.0aca5149-c0a9-4a7c-afa0-10167dae9c69@github.com>

On Thu, 9 Feb 2023 08:48:17 GMT, SUN Guoyun <duke at openjdk.org> wrote:

>> Hi all,
>> When -Xcomp be used, this testcase will use more codecaches, causing the GC to be triggered early, then causing this test failed on LoongArch64 architecture.
>> 
>> This PR fix the issue, Please help review it.
>> 
>> Thanks.
>
> SUN Guoyun has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8301737: java/rmi/server/UnicastRemoteObject/serialFilter/FilterUROTest.java fail with -Xcomp

ok thanks for the feedback and trying my suggestion. I would put a D in front of GC. The issue relates to the DGC in RMI, and it is possible that a race condition could occur in the test.
If you add -Dsun.rmi.dgc.logLevel=VERBOSE as follows and execute the test this should generate some informative trace

@run testng/othervm -Dsun.rmi.dgc.logLevel=VERBOSE FilterUROTest

generates trace as follows:

Feb 09, 2023 9:50:57 AM sun.rmi.transport.Target pinImpl
FINER: MainThread: strongRef = sun.rmi.transport.DGCImpl at 7cbf0dfe
Feb 09, 2023 9:50:57 AM sun.rmi.transport.DGCImpl$2 run
FINER: MainThread: add object [0:0:0, 2]
Feb 09, 2023 9:50:57 AM sun.rmi.transport.Transport exportObject
FINER: MainThread: add object [62fd29ac:1863595d6b8:-7fff, 5531192820167141595]
Feb 09, 2023 9:50:58 AM sun.rmi.transport.Transport exportObject
FINER: MainThread: add object [62fd29ac:1863595d6b8:-7ffd, 8746623791996069441]
Feb 09, 2023 9:50:58 AM sun.rmi.transport.ObjectTable$Reaper run       ************* REAPER RUNNING
FINER: RMI Reaper: remove object [62fd29ac:1863595d6b8:-7fff, 5531192820167141595]  ***** obj removed
Feb 09, 2023 9:50:58 AM sun.rmi.transport.Transport exportObject
FINER: MainThread: add object [62fd29ac:1863595d6b8:-7ffb, 1056299151672018720]
Feb 09, 2023 9:50:58 AM sun.rmi.transport.Transport exportObject
FINER: MainThread: add object [62fd29ac:1863595d6b8:-7ff9, 8876407693706706001]
Feb 09, 2023 9:50:58 AM sun.rmi.transport.Transport exportObject
FINER: MainThread: add object [62fd29ac:1863595d6b8:-7ff7, -7965896295360386187]
Feb 09, 2023 9:50:58 AM sun.rmi.transport.Transport exportObject
FINER: MainThread: add object [62fd29ac:1863595d6b8:-7ff5, -7624739283438349379]
Feb 09, 2023 9:50:58 AM sun.rmi.transport.Transport exportObject
FINER: MainThread: add object [62fd29ac:1863595d6b8:-7ff3, 7826842570026353870]
Feb 09, 2023 9:50:58 AM sun.rmi.transport.Transport exportObject
FINER: MainThread: add object [62fd29ac:1863595d6b8:-7ff1, 2393465261706369534]
Feb 09, 2023 9:50:58 AM sun.rmi.transport.Transport exportObject
FINER: MainThread: add object [62fd29ac:1863595d6b8:-7fef, -1516555594713694850]
Feb 09, 2023 9:50:58 AM sun.rmi.transport.Transport exportObject
FINER: MainThread: add object [62fd29ac:1863595d6b8:-7fed, 2782915653950164382]
STATUS:Passed.

-------------

PR: https://git.openjdk.org/jdk/pull/12399

From redestad at openjdk.org  Thu Feb  9 10:07:48 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Thu, 9 Feb 2023 10:07:48 GMT
Subject: RFR: 8301873: Avoid string decoding in ZipFile.Source.getEntryPos
 [v7]
In-Reply-To: <CF983B0JFz9rFPwtQZ-C9QpBYlpm3pfOpvD9pSstLL0=.daf6286d-59d9-4450-aff8-ad003199bd50@github.com>
References: <FkmdspiHVjkAKFqm5kUgwaf55YH5cBbczS_3krqsdFs=.05eca901-f55f-47d9-b1bc-0cf2f5b87536@github.com>
 <CF983B0JFz9rFPwtQZ-C9QpBYlpm3pfOpvD9pSstLL0=.daf6286d-59d9-4450-aff8-ad003199bd50@github.com>
Message-ID: <VYqYVkfokdGFn2g4AASmcf05PXYviK6mumcx1XYWbO4=.faa97241-953e-4ff9-8a4b-2d6f52585b28@github.com>

On Wed, 8 Feb 2023 16:36:16 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

>> After finding a hash match, getEntryPos needs to compare the lookup name up to the encoded entry name in the CEN. This comparison is done by decoding the entry name into a String. The names can then be compared using the String API. This decoding step adds a significat cost to this method.
>> 
>> This PR suggest to update the string comparison such that in the common case where  both the lookup name and the entry name are encoded in ASCII-compatible UTF-8,  decoding can be avoided and the byte arrays can instead be compared direcly. 
>> 
>> ZipCoder is updated with a new method to compare a string with an encoded byte array range.  The default implementation decodes to string (like the current code), while the UTF-8 implementation uses JavaLangAccess.getBytesNoRepl to get the  bytes. Both methods thes uses Arrays.mismatch for comparison with or without matching trailing slashes. 
>> 
>> Additionally, this PR suggest to make the following updates to getEntryPos:
>> 
>> - The try/catch for IAE is redundant and can be safely removed. (initCEN already checks this and will throws IAE for invalid UTF-8). This seems to give a 3-4% speedup on micros)
>> - A new test InvalidBytesInEntryNameOrComment is a added to verify that initCEN does in fact reject invalid UTF-8 in CEN file names and comments. (I found no existing test coverage for this)
>> - The recursion when looking for "name/" matches is replaced with iteration. We keep track of any "name/" match and return it at the end of the search. (I feel this is easier to follow and it also gives a ~30% speedup for addSlash lookups with no regression on regular lookups)
>> 
>> (My though is that including these additional updates in this PR might reduce reviewer overhead given that it touches the exact same code. I might be wrong on this, please advise :)
>> 
>> I'm seeing a ~17% saving on the micro ZipFileGetEntry.getEntryHit (modified to use xalan.jar):
>> 
>> Baseline:
>> 
>> Benchmark                             (size)  Mode  Cnt    Score   Error  Units
>> ZipFileGetEntry.getEntryHit              512  avgt   15   74.941 ? 1.004  ns/op
>> ZipFileGetEntry.getEntryHit             1024  avgt   15   84.943 ? 1.320  ns/op
>> ZipFileGetEntry.getEntryHitUncached      512  avgt   15  120.371 ? 2.386  ns/op
>> ZipFileGetEntry.getEntryHitUncached     1024  avgt   15  126.128 ? 1.075  ns/op
>> ZipFileGetEntry.getEntryMiss             512  avgt   15   23.818 ? 0.838  ns/op
>> ZipFileGetEntry.getEntryMiss            1024  avgt   15   29.762 ? 5.998  ns/op
>> ZipFileGetEntry.getEntryMissUncached     512  avgt   15   59.405 ? 0.545  ns/op
>> ZipFileGetEntry.getEntryMissUncached    1024  avgt   15   71.840 ? 2.455  ns/op
>> ZipFileGetEntry.getEntrySlash            512  avgt   15  135.621 ? 4.341  ns/op
>> ZipFileGetEntry.getEntrySlash           1024  avgt   15  134.190 ? 2.141  ns/op
>> 
>> 
>> 
>> PR:
>> 
>> 
>> Benchmark                             (size)  Mode  Cnt    Score   Error  Units
>> ZipFileGetEntry.getEntryHit              512  avgt   15   62.267 ? 1.329  ns/op
>> ZipFileGetEntry.getEntryHit             1024  avgt   15   72.916 ? 2.428  ns/op
>> ZipFileGetEntry.getEntryHitUncached      512  avgt   15  101.630 ? 1.154  ns/op
>> ZipFileGetEntry.getEntryHitUncached     1024  avgt   15  113.161 ? 0.502  ns/op
>> ZipFileGetEntry.getEntryMiss             512  avgt   15   23.003 ? 1.191  ns/op
>> ZipFileGetEntry.getEntryMiss            1024  avgt   15   23.236 ? 1.114  ns/op
>> ZipFileGetEntry.getEntryMissUncached     512  avgt   15   56.781 ? 1.505  ns/op
>> ZipFileGetEntry.getEntryMissUncached    1024  avgt   15   67.767 ? 1.963  ns/op
>> ZipFileGetEntry.getEntrySlash            512  avgt   15   73.745 ? 2.717  ns/op
>> ZipFileGetEntry.getEntrySlash           1024  avgt   15   75.784 ? 1.051  ns/op
>> 
>> 
>> To assess the impact on startup/warmup, I made a main method class which measures the total time of calling ZipFile.getEntry for all entries in the 109 JAR file dependenies of spring-petclinic. The shows a nice improvement (time in micros):
>> 
>> 
>> Percentile Baseline Patch
>> 50?%          23155 21149
>> 75?%          23598 21454
>> 90?%          23989 21691
>> 95?%          24238 21973
>> 99?%          25270 22446
>> STDEV           792   549
>> Count           500   500
>
> Eirik Bjorsnos has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update the sameHashAndLengthDirLookup to use ASCII example colliding paths, allowing the test to run over all charsets

You could skip the `equals`:

        if (decoded.startsWith(str)) {
            if (decoded.length() == str.length()) {
                return Comparison.EXACT_MATCH;
            } else if (addSlash
                && decoded.length() == str.length() + 1
                && decoded.endsWith("/") ) {
                return Comparison.SLASH_MATCH;
            }
        }
        return Comparison.NO_MATCH;

Should be a win and avoids the need for a new mismatch method here.

-------------

PR: https://git.openjdk.org/jdk/pull/12290

From eirbjo at gmail.com  Thu Feb  9 10:17:51 2023
From: eirbjo at gmail.com (=?UTF-8?B?RWlyaWsgQmrDuHJzbsO4cw==?=)
Date: Thu, 9 Feb 2023 11:17:51 +0100
Subject: Incorrect capitalization in Arrays.compare and Arrays.mismatch
 Javadocs
Message-ID: <CA+pBWhuY5bbPYgjhAk-9-A3zyC5pGjvoEiso9LH=dARhKQ=nZA@mail.gmail.com>

Please review this documentation-only change which fixes incorrect
capitalization when referencing "aToIndex" and "bToIndex" in the Javadocs
of Arrays.compare and Arrays.mismatch.

https://github.com/openjdk/jdk/pull/12488

Thanks,
Eirik.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20230209/296f91e6/attachment.htm>

From duke at openjdk.org  Thu Feb  9 10:57:41 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Thu, 9 Feb 2023 10:57:41 GMT
Subject: RFR: 8301873: Avoid string decoding in ZipFile.Source.getEntryPos
 [v7]
In-Reply-To: <VYqYVkfokdGFn2g4AASmcf05PXYviK6mumcx1XYWbO4=.faa97241-953e-4ff9-8a4b-2d6f52585b28@github.com>
References: <FkmdspiHVjkAKFqm5kUgwaf55YH5cBbczS_3krqsdFs=.05eca901-f55f-47d9-b1bc-0cf2f5b87536@github.com>
 <CF983B0JFz9rFPwtQZ-C9QpBYlpm3pfOpvD9pSstLL0=.daf6286d-59d9-4450-aff8-ad003199bd50@github.com>
 <VYqYVkfokdGFn2g4AASmcf05PXYviK6mumcx1XYWbO4=.faa97241-953e-4ff9-8a4b-2d6f52585b28@github.com>
Message-ID: <cNwIsLK6USpmJJkzT0KSthOWThf0Rak10tL0F5oyBDU=.3effe77a-2d59-4880-aac2-7929ada1da6c@github.com>

On Thu, 9 Feb 2023 10:05:06 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> Should be a win and avoids the need for a new mismatch method here.

Interestingly, this is not a win:

PR:


Benchmark                             (size)  Mode  Cnt    Score   Error  Units
ZipFileGetEntry.getEntryHit              512  avgt   15   73.633 ? 4.349  ns/op
ZipFileGetEntry.getEntryHit             1024  avgt   15   74.477 ? 1.667  ns/op
ZipFileGetEntry.getEntryHitUncached      512  avgt   15  108.352 ? 1.598  ns/op
ZipFileGetEntry.getEntryHitUncached     1024  avgt   15  110.425 ? 1.867  ns/op
ZipFileGetEntry.getEntryMiss             512  avgt   15   21.921 ? 0.251  ns/op
ZipFileGetEntry.getEntryMiss            1024  avgt   15   22.836 ? 0.279  ns/op
ZipFileGetEntry.getEntryMissUncached     512  avgt   15   51.890 ? 2.289  ns/op
ZipFileGetEntry.getEntryMissUncached    1024  avgt   15   56.722 ? 0.701  ns/op


Claes:


BBenchmark                             (size)  Mode  Cnt    Score   Error  Units
ZipFileGetEntry.getEntryHit              512  avgt   15   84.518 ? 4.440  ns/op
ZipFileGetEntry.getEntryHit             1024  avgt   15   85.359 ? 1.484  ns/op
ZipFileGetEntry.getEntryHitUncached      512  avgt   15  117.003 ? 1.481  ns/op
ZipFileGetEntry.getEntryHitUncached     1024  avgt   15  119.026 ? 1.073  ns/op
ZipFileGetEntry.getEntryMiss             512  avgt   15   22.027 ? 0.188  ns/op
ZipFileGetEntry.getEntryMiss            1024  avgt   15   22.929 ? 0.282  ns/op
ZipFileGetEntry.getEntryMissUncached     512  avgt   15   52.513 ? 1.859  ns/op
ZipFileGetEntry.getEntryMissUncached    1024  avgt   15   56.425 ? 0.699  ns/op


(I forced ZipCoder.compare here by simply removing UTFZipCoder.compare)

-------------

PR: https://git.openjdk.org/jdk/pull/12290

From duke at openjdk.org  Thu Feb  9 11:06:43 2023
From: duke at openjdk.org (Varada M)
Date: Thu, 9 Feb 2023 11:06:43 GMT
Subject: RFR: 8300139 : [AIX] Use pthreads to avoid JNI_createVM call from
 primordial thread [v2]
In-Reply-To: <EytMoEECi74JuG2MD6i79mz-m2o45-C5wB1PxkoKweU=.3335308c-0147-43df-8821-7b08c3aa11f8@github.com>
References: <qbwPBNdxzk4QmB9L6y2t-X6uYgAaPjzAEwYfs_5XV_0=.4ea982e6-30da-4219-b8ad-fa36690170b8@github.com>
 <vu7c9WHMcCXtkghiBjXUnP3KUy6Xyh7lP7McKSnlJcY=.2e4bdce8-d4e3-4dd1-9fc3-1a27f089dd6f@github.com>
 <EytMoEECi74JuG2MD6i79mz-m2o45-C5wB1PxkoKweU=.3335308c-0147-43df-8821-7b08c3aa11f8@github.com>
Message-ID: <-t5m5emOq8DlWCsigyaoovNvFq7hMVbFM-oD5TG5_uU=.55cede30-8ac6-46c1-96e8-b0f64052ccd9@github.com>

On Wed, 8 Feb 2023 21:30:29 GMT, David Holmes <dholmes at openjdk.org> wrote:

> It just occurred to me that we may also need to update the test makefiles to link to libpthread for these modified tests?


Running test 'jtreg:test/hotspot/jtreg/runtime/jni/CalleeSavedRegisters/FPRegs.java'
Passed: runtime/jni/CalleeSavedRegisters/FPRegs.java
Test results: passed: 1

Running test 'jtreg:test/jdk/java/lang/reflect/exeCallerAccessTest/CallerAccessTest.java'
Passed: java/lang/reflect/exeCallerAccessTest/CallerAccessTest.java
Test results: passed: 1

Running test 'jtreg:test/jdk/jni/nullCaller/NullCallerTest.java'
Passed: jni/nullCaller/NullCallerTest.java
Test results: passed: 1

Running test 'jtreg:test/lib-test/jdk/test/lib/process/TestNativeProcessBuilder.java'
Passed: jdk/test/lib/process/TestNativeProcessBuilder.java
Test results: passed: 1



These tests is passing without adding lpthread in JtregNativeHotspot.gmk. Do I need to update the makefile?

-------------

PR: https://git.openjdk.org/jdk/pull/12302

From redestad at openjdk.org  Thu Feb  9 11:09:44 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Thu, 9 Feb 2023 11:09:44 GMT
Subject: RFR: 8301873: Avoid string decoding in ZipFile.Source.getEntryPos
 [v7]
In-Reply-To: <CF983B0JFz9rFPwtQZ-C9QpBYlpm3pfOpvD9pSstLL0=.daf6286d-59d9-4450-aff8-ad003199bd50@github.com>
References: <FkmdspiHVjkAKFqm5kUgwaf55YH5cBbczS_3krqsdFs=.05eca901-f55f-47d9-b1bc-0cf2f5b87536@github.com>
 <CF983B0JFz9rFPwtQZ-C9QpBYlpm3pfOpvD9pSstLL0=.daf6286d-59d9-4450-aff8-ad003199bd50@github.com>
Message-ID: <ob_KY7FtN8gsmDmqGeCDDhIQPy7fjBkJK_soDTrN3Mo=.1612a35c-3088-4f06-b64b-f5113c90f673@github.com>

On Wed, 8 Feb 2023 16:36:16 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

>> After finding a hash match, getEntryPos needs to compare the lookup name up to the encoded entry name in the CEN. This comparison is done by decoding the entry name into a String. The names can then be compared using the String API. This decoding step adds a significat cost to this method.
>> 
>> This PR suggest to update the string comparison such that in the common case where  both the lookup name and the entry name are encoded in ASCII-compatible UTF-8,  decoding can be avoided and the byte arrays can instead be compared direcly. 
>> 
>> ZipCoder is updated with a new method to compare a string with an encoded byte array range.  The default implementation decodes to string (like the current code), while the UTF-8 implementation uses JavaLangAccess.getBytesNoRepl to get the  bytes. Both methods thes uses Arrays.mismatch for comparison with or without matching trailing slashes. 
>> 
>> Additionally, this PR suggest to make the following updates to getEntryPos:
>> 
>> - The try/catch for IAE is redundant and can be safely removed. (initCEN already checks this and will throws IAE for invalid UTF-8). This seems to give a 3-4% speedup on micros)
>> - A new test InvalidBytesInEntryNameOrComment is a added to verify that initCEN does in fact reject invalid UTF-8 in CEN file names and comments. (I found no existing test coverage for this)
>> - The recursion when looking for "name/" matches is replaced with iteration. We keep track of any "name/" match and return it at the end of the search. (I feel this is easier to follow and it also gives a ~30% speedup for addSlash lookups with no regression on regular lookups)
>> 
>> (My though is that including these additional updates in this PR might reduce reviewer overhead given that it touches the exact same code. I might be wrong on this, please advise :)
>> 
>> I'm seeing a ~17% saving on the micro ZipFileGetEntry.getEntryHit (modified to use xalan.jar):
>> 
>> Baseline:
>> 
>> Benchmark                             (size)  Mode  Cnt    Score   Error  Units
>> ZipFileGetEntry.getEntryHit              512  avgt   15   74.941 ? 1.004  ns/op
>> ZipFileGetEntry.getEntryHit             1024  avgt   15   84.943 ? 1.320  ns/op
>> ZipFileGetEntry.getEntryHitUncached      512  avgt   15  120.371 ? 2.386  ns/op
>> ZipFileGetEntry.getEntryHitUncached     1024  avgt   15  126.128 ? 1.075  ns/op
>> ZipFileGetEntry.getEntryMiss             512  avgt   15   23.818 ? 0.838  ns/op
>> ZipFileGetEntry.getEntryMiss            1024  avgt   15   29.762 ? 5.998  ns/op
>> ZipFileGetEntry.getEntryMissUncached     512  avgt   15   59.405 ? 0.545  ns/op
>> ZipFileGetEntry.getEntryMissUncached    1024  avgt   15   71.840 ? 2.455  ns/op
>> ZipFileGetEntry.getEntrySlash            512  avgt   15  135.621 ? 4.341  ns/op
>> ZipFileGetEntry.getEntrySlash           1024  avgt   15  134.190 ? 2.141  ns/op
>> 
>> 
>> 
>> PR:
>> 
>> 
>> Benchmark                             (size)  Mode  Cnt    Score   Error  Units
>> ZipFileGetEntry.getEntryHit              512  avgt   15   62.267 ? 1.329  ns/op
>> ZipFileGetEntry.getEntryHit             1024  avgt   15   72.916 ? 2.428  ns/op
>> ZipFileGetEntry.getEntryHitUncached      512  avgt   15  101.630 ? 1.154  ns/op
>> ZipFileGetEntry.getEntryHitUncached     1024  avgt   15  113.161 ? 0.502  ns/op
>> ZipFileGetEntry.getEntryMiss             512  avgt   15   23.003 ? 1.191  ns/op
>> ZipFileGetEntry.getEntryMiss            1024  avgt   15   23.236 ? 1.114  ns/op
>> ZipFileGetEntry.getEntryMissUncached     512  avgt   15   56.781 ? 1.505  ns/op
>> ZipFileGetEntry.getEntryMissUncached    1024  avgt   15   67.767 ? 1.963  ns/op
>> ZipFileGetEntry.getEntrySlash            512  avgt   15   73.745 ? 2.717  ns/op
>> ZipFileGetEntry.getEntrySlash           1024  avgt   15   75.784 ? 1.051  ns/op
>> 
>> 
>> To assess the impact on startup/warmup, I made a main method class which measures the total time of calling ZipFile.getEntry for all entries in the 109 JAR file dependenies of spring-petclinic. The shows a nice improvement (time in micros):
>> 
>> 
>> Percentile Baseline Patch
>> 50?%          23155 21149
>> 75?%          23598 21454
>> 90?%          23989 21691
>> 95?%          24238 21973
>> 99?%          25270 22446
>> STDEV           792   549
>> Count           500   500
>
> Eirik Bjorsnos has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update the sameHashAndLengthDirLookup to use ASCII example colliding paths, allowing the test to run over all charsets

Oh -- fun! Perhaps `startsWith` doesn't take advantage of the optimized intrinsic for `equals`. 

Could be interesting to see if special-casing `startsWith` to call `equals` when possible would help:

diff --git a/src/java.base/share/classes/java/lang/String.java b/src/java.base/share/classes/java/lang/String.java
index 1897a06cd60..5a4fc200344 100644
--- a/src/java.base/share/classes/java/lang/String.java
+++ b/src/java.base/share/classes/java/lang/String.java
@@ -2267,6 +2267,9 @@ public final class String
      */
     public boolean startsWith(String prefix, int toffset) {
         // Note: toffset might be near -1>>>1.
+        if (toffset == 0 && length() == prefix.length()) {
+            return equals(prefix);
+        }
         if (toffset < 0 || toffset > length() - prefix.length()) {
             return false;
         }
         ```

-------------

PR: https://git.openjdk.org/jdk/pull/12290

From duke at openjdk.org  Thu Feb  9 11:17:54 2023
From: duke at openjdk.org (Varada M)
Date: Thu, 9 Feb 2023 11:17:54 GMT
Subject: RFR: 8300139 : [AIX] Use pthreads to avoid JNI_createVM call from
 primordial thread [v3]
In-Reply-To: <qbwPBNdxzk4QmB9L6y2t-X6uYgAaPjzAEwYfs_5XV_0=.4ea982e6-30da-4219-b8ad-fa36690170b8@github.com>
References: <qbwPBNdxzk4QmB9L6y2t-X6uYgAaPjzAEwYfs_5XV_0=.4ea982e6-30da-4219-b8ad-fa36690170b8@github.com>
Message-ID: <7NSCfG4cqgmi4DdQlYgROali8O23k-6POdWORkYsagM=.d788d6ea-c9e9-415f-8b33-5f042c38928b@github.com>

> 1. test/jdk/jni/nullCaller/NullCallerTest.java
> 2. test/jdk/java/lang/reflect/exeCallerAccessTest/CallerAccessTest.java
> 3. test/hotspot/jtreg/runtime/jni/CalleeSavedRegisters/FPRegs.java 
> 
>     The above tests were blocked on AIX [@require os.family != "aix"] because these tests are failing to call JNI_CreateJavaVM. This is solved by implementing JNI_CreateJavaVM call via POSIX threads. 
>    Similarly there are tests which are not blocked and still failing to call JNI_CreateJavaVM on AIX :
> 
> 4. test/hotspot/jtreg/runtime/jni/daemonDestroy/TestDaemonDestroy.java { PR : [12006](https://github.com/openjdk/jdk/pull/12006) }
> 5. test/lib-test/jdk/test/lib/process/TestNativeProcessBuilder.java 
> 
> The reported issue : [8300139](https://bugs.openjdk.org/browse/JDK-8300139l)

Varada M has updated the pull request incrementally with one additional commit since the last revision:

  Fixes

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12302/files
  - new: https://git.openjdk.org/jdk/pull/12302/files/d106745e..87e6cfba

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12302&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12302&range=01-02

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/12302.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12302/head:pull/12302

PR: https://git.openjdk.org/jdk/pull/12302

From duke at openjdk.org  Thu Feb  9 11:17:57 2023
From: duke at openjdk.org (Varada M)
Date: Thu, 9 Feb 2023 11:17:57 GMT
Subject: RFR: 8300139 : [AIX] Use pthreads to avoid JNI_createVM call from
 primordial thread [v2]
In-Reply-To: <QTwPdJwOHDusp2tHfO-PsEHvw9Ou73lYen6aAtntTsY=.663a0049-cde2-4d9d-b172-3ffc4019f026@github.com>
References: <qbwPBNdxzk4QmB9L6y2t-X6uYgAaPjzAEwYfs_5XV_0=.4ea982e6-30da-4219-b8ad-fa36690170b8@github.com>
 <vu7c9WHMcCXtkghiBjXUnP3KUy6Xyh7lP7McKSnlJcY=.2e4bdce8-d4e3-4dd1-9fc3-1a27f089dd6f@github.com>
 <QTwPdJwOHDusp2tHfO-PsEHvw9Ou73lYen6aAtntTsY=.663a0049-cde2-4d9d-b172-3ffc4019f026@github.com>
Message-ID: <jzYIe3Os1xtsHfsg98QUYX4AEtP48Ocglql7vnCpUkc=.42181c48-7f86-4a2d-8d40-ac80e363ccc3@github.com>

On Wed, 8 Feb 2023 15:53:52 GMT, Tyler Steele <tsteele at openjdk.org> wrote:

>> Varada M has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fixes
>
> test/hotspot/jtreg/runtime/jni/CalleeSavedRegisters/FPRegs.java line 2:
> 
>> 1: /*
>> 2:  * Copyright (c) 2021, 2023, Oracle and/or its affiliates. All rights reserved.
> 
> We shouldn't ever need to update the left (starting) year in this range; only the rightmost year should change. Please update this line to have the range `2016, 2023`.

Thank you @backwaterred. I have updated.

-------------

PR: https://git.openjdk.org/jdk/pull/12302

From duke at openjdk.org  Thu Feb  9 11:20:43 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Thu, 9 Feb 2023 11:20:43 GMT
Subject: RFR: 8301873: Avoid string decoding in ZipFile.Source.getEntryPos
 [v7]
In-Reply-To: <ob_KY7FtN8gsmDmqGeCDDhIQPy7fjBkJK_soDTrN3Mo=.1612a35c-3088-4f06-b64b-f5113c90f673@github.com>
References: <FkmdspiHVjkAKFqm5kUgwaf55YH5cBbczS_3krqsdFs=.05eca901-f55f-47d9-b1bc-0cf2f5b87536@github.com>
 <CF983B0JFz9rFPwtQZ-C9QpBYlpm3pfOpvD9pSstLL0=.daf6286d-59d9-4450-aff8-ad003199bd50@github.com>
 <ob_KY7FtN8gsmDmqGeCDDhIQPy7fjBkJK_soDTrN3Mo=.1612a35c-3088-4f06-b64b-f5113c90f673@github.com>
Message-ID: <HZZmFp8CQ64Esbj3xM6qHHMxppew5KZbBsg9KjcOqMs=.48840cb5-be37-49fe-aab5-7fcb1ebca9b3@github.com>

On Thu, 9 Feb 2023 11:07:17 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> Could be interesting to see if special-casing `startsWith` to call `equals` when possible would help:

It helps... a lot!


Benchmark                             (size)  Mode  Cnt    Score   Error  Units
ZipFileGetEntry.getEntryHit              512  avgt   15   72.800 ? 3.426  ns/op
ZipFileGetEntry.getEntryHit             1024  avgt   15   73.434 ? 0.671  ns/op
ZipFileGetEntry.getEntryHitUncached      512  avgt   15  107.538 ? 1.309  ns/op
ZipFileGetEntry.getEntryHitUncached     1024  avgt   15  110.775 ? 2.252  ns/op
ZipFileGetEntry.getEntryMiss             512  avgt   15   22.022 ? 0.170  ns/op
ZipFileGetEntry.getEntryMiss            1024  avgt   15   23.242 ? 1.569  ns/op
ZipFileGetEntry.getEntryMissUncached     512  avgt   15   50.946 ? 0.458  ns/op
ZipFileGetEntry.getEntryMissUncached    1024  avgt   15   57.856 ? 3.021  ns/op

-------------

PR: https://git.openjdk.org/jdk/pull/12290

From duke at openjdk.org  Thu Feb  9 11:24:43 2023
From: duke at openjdk.org (SUN Guoyun)
Date: Thu, 9 Feb 2023 11:24:43 GMT
Subject: RFR: 8301737:
 java/rmi/server/UnicastRemoteObject/serialFilter/FilterUROTest.java fail with
 -Xcomp [v4]
In-Reply-To: <LCJW-DKImXCmpxwBGKJPmSKAUnz9dHg-T09tqD9-SMU=.87d63cd0-6b22-4af8-9786-bd6c75d04ca2@github.com>
References: <l5m5_9io2QMSFNY7dBHT3Nr2I9Er8wmd92Ze8FP-XE0=.a40d29be-77be-4719-a0a0-71d032eea1e5@github.com>
 <LCJW-DKImXCmpxwBGKJPmSKAUnz9dHg-T09tqD9-SMU=.87d63cd0-6b22-4af8-9786-bd6c75d04ca2@github.com>
Message-ID: <zH0mGZmHVHF__mSFgpq_xznez4gIfgFkhpMRPwxzv4U=.79a98592-abc9-42c7-809d-0f3d08c315c1@github.com>

On Thu, 9 Feb 2023 08:48:17 GMT, SUN Guoyun <duke at openjdk.org> wrote:

>> Hi all,
>> When -Xcomp be used, this testcase will use more codecaches, causing the GC to be triggered early, then causing this test failed on LoongArch64 architecture.
>> 
>> This PR fix the issue, Please help review it.
>> 
>> Thanks.
>
> SUN Guoyun has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8301737: java/rmi/server/UnicastRemoteObject/serialFilter/FilterUROTest.java fail with -Xcomp

After `-Dsun.rmi.dgc.logLevel=VERBOSE`, test run passed. I don't understand why, you know?

-------------

PR: https://git.openjdk.org/jdk/pull/12399

From duke at openjdk.org  Thu Feb  9 11:35:47 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Thu, 9 Feb 2023 11:35:47 GMT
Subject: RFR: 8301873: Avoid string decoding in ZipFile.Source.getEntryPos
 [v7]
In-Reply-To: <HZZmFp8CQ64Esbj3xM6qHHMxppew5KZbBsg9KjcOqMs=.48840cb5-be37-49fe-aab5-7fcb1ebca9b3@github.com>
References: <FkmdspiHVjkAKFqm5kUgwaf55YH5cBbczS_3krqsdFs=.05eca901-f55f-47d9-b1bc-0cf2f5b87536@github.com>
 <CF983B0JFz9rFPwtQZ-C9QpBYlpm3pfOpvD9pSstLL0=.daf6286d-59d9-4450-aff8-ad003199bd50@github.com>
 <ob_KY7FtN8gsmDmqGeCDDhIQPy7fjBkJK_soDTrN3Mo=.1612a35c-3088-4f06-b64b-f5113c90f673@github.com>
 <HZZmFp8CQ64Esbj3xM6qHHMxppew5KZbBsg9KjcOqMs=.48840cb5-be37-49fe-aab5-7fcb1ebca9b3@github.com>
Message-ID: <wXfgzL7CpzcCCJz2VjqcAwyB40ird4usIXR9nnObsaE=.b2714767-491c-4b13-888e-903ffbee507b@github.com>

On Thu, 9 Feb 2023 11:17:54 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

> It helps... a lot!

I guess an update to String.startsWith should be handled separately from this PR.

If startsWith will be optimized, then I'm happy to update this PR to use startsWith as you suggested. Then ZipCoder will speed up for free with any later startsWith optimization.

-------------

PR: https://git.openjdk.org/jdk/pull/12290

From stuefe at openjdk.org  Thu Feb  9 11:35:55 2023
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Thu, 9 Feb 2023 11:35:55 GMT
Subject: RFR: 8300139 : [AIX] Use pthreads to avoid JNI_createVM call from
 primordial thread [v3]
In-Reply-To: <7NSCfG4cqgmi4DdQlYgROali8O23k-6POdWORkYsagM=.d788d6ea-c9e9-415f-8b33-5f042c38928b@github.com>
References: <qbwPBNdxzk4QmB9L6y2t-X6uYgAaPjzAEwYfs_5XV_0=.4ea982e6-30da-4219-b8ad-fa36690170b8@github.com>
 <7NSCfG4cqgmi4DdQlYgROali8O23k-6POdWORkYsagM=.d788d6ea-c9e9-415f-8b33-5f042c38928b@github.com>
Message-ID: <jT51_OtLa2h8OS1BKl7JJP_VAZgMC_J6Tg8R3ITJSFs=.a5e19609-fd24-4e0f-9864-6742ad70c8ef@github.com>

On Thu, 9 Feb 2023 11:17:54 GMT, Varada M <duke at openjdk.org> wrote:

>> 1. test/jdk/jni/nullCaller/NullCallerTest.java
>> 2. test/jdk/java/lang/reflect/exeCallerAccessTest/CallerAccessTest.java
>> 3. test/hotspot/jtreg/runtime/jni/CalleeSavedRegisters/FPRegs.java 
>> 
>>     The above tests were blocked on AIX [@require os.family != "aix"] because these tests are failing to call JNI_CreateJavaVM. This is solved by implementing JNI_CreateJavaVM call via POSIX threads. 
>>    Similarly there are tests which are not blocked and still failing to call JNI_CreateJavaVM on AIX :
>> 
>> 4. test/hotspot/jtreg/runtime/jni/daemonDestroy/TestDaemonDestroy.java { PR : [12006](https://github.com/openjdk/jdk/pull/12006) }
>> 5. test/lib-test/jdk/test/lib/process/TestNativeProcessBuilder.java 
>> 
>> The reported issue : [8300139](https://bugs.openjdk.org/browse/JDK-8300139l)
>
> Varada M has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixes

Small nits remain, nothing major.

test/hotspot/jtreg/runtime/jni/CalleeSavedRegisters/FPRegs.java line 28:

> 26:  * @test
> 27:  * @bug 8067744
> 28:  * @comment Test uses custom launcher that starts VM in primordial thread. This is

Please remove outdated comment

test/hotspot/jtreg/runtime/jni/CalleeSavedRegisters/exeFPRegs.c line 113:

> 111:      int argc;
> 112:      char **argv;
> 113: } args_list;

Please keep indentation consistent; part of the program uses 2, part 4

test/hotspot/jtreg/runtime/jni/CalleeSavedRegisters/exeFPRegs.c line 115:

> 113: } args_list;
> 114: 
> 115: void* run(void* argp){

Please make static; no need to export this from the compilation unit.

test/jdk/java/lang/reflect/exeCallerAccessTest/CallerAccessTest.java line 29:

> 27:  * @bug 8221530 8221642
> 28:  * @summary Test uses custom launcher that starts VM using JNI that verifies
> 29:  *          reflection API with null caller class

Comment outdated (just remove)

test/jdk/java/lang/reflect/exeCallerAccessTest/exeCallerAccessTest.c line 48:

> 46: int checkAccess(JNIEnv *env, char* declaringClass_name, char* field_name, jboolean canAccess);
> 47: 
> 48: void* run(void* argp){

static

test/jdk/java/lang/reflect/exeCallerAccessTest/exeCallerAccessTest.c line 243:

> 241: }
> 242: 
> 243: int main(int argc, char *argv[]){

space after )

test/jdk/jni/nullCaller/exeNullCallerTest.cpp line 159:

> 157: }
> 158: 
> 159: int main(int argc, char** args) {

static, and space

test/jdk/jni/nullCaller/exeNullCallerTest.cpp line 190:

> 188: }
> 189: 
> 190: int main(int argc, char *argv[]){

space

test/lib-test/jdk/test/lib/process/exejvm-test-launcher.c line 31:

> 29: #endif //AIX
> 30: 
> 31: void* run(void *arg){

space

-------------

PR: https://git.openjdk.org/jdk/pull/12302

From stuefe at openjdk.org  Thu Feb  9 11:35:57 2023
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Thu, 9 Feb 2023 11:35:57 GMT
Subject: RFR: 8300139 : [AIX] Use pthreads to avoid JNI_createVM call from
 primordial thread [v3]
In-Reply-To: <jT51_OtLa2h8OS1BKl7JJP_VAZgMC_J6Tg8R3ITJSFs=.a5e19609-fd24-4e0f-9864-6742ad70c8ef@github.com>
References: <qbwPBNdxzk4QmB9L6y2t-X6uYgAaPjzAEwYfs_5XV_0=.4ea982e6-30da-4219-b8ad-fa36690170b8@github.com>
 <7NSCfG4cqgmi4DdQlYgROali8O23k-6POdWORkYsagM=.d788d6ea-c9e9-415f-8b33-5f042c38928b@github.com>
 <jT51_OtLa2h8OS1BKl7JJP_VAZgMC_J6Tg8R3ITJSFs=.a5e19609-fd24-4e0f-9864-6742ad70c8ef@github.com>
Message-ID: <YObeQECBiJmzKaktKip4me5a-EEiCD8Kn6F1iUFBsow=.18d69839-53d8-46e1-86b8-e74261ea9433@github.com>

On Thu, 9 Feb 2023 11:28:47 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Varada M has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fixes
>
> test/jdk/java/lang/reflect/exeCallerAccessTest/exeCallerAccessTest.c line 48:
> 
>> 46: int checkAccess(JNIEnv *env, char* declaringClass_name, char* field_name, jboolean canAccess);
>> 47: 
>> 48: void* run(void* argp){
> 
> static

And pls add space after bracket.

-------------

PR: https://git.openjdk.org/jdk/pull/12302

From duke at openjdk.org  Thu Feb  9 11:46:59 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Thu, 9 Feb 2023 11:46:59 GMT
Subject: RFR: 8301873: Avoid string decoding in ZipFile.Source.getEntryPos
 [v8]
In-Reply-To: <FkmdspiHVjkAKFqm5kUgwaf55YH5cBbczS_3krqsdFs=.05eca901-f55f-47d9-b1bc-0cf2f5b87536@github.com>
References: <FkmdspiHVjkAKFqm5kUgwaf55YH5cBbczS_3krqsdFs=.05eca901-f55f-47d9-b1bc-0cf2f5b87536@github.com>
Message-ID: <QcfYEGkvkWVpructcsBm1Jl9Zuh6FRQ9kRmqSEmeAWc=.06abeef6-1c73-4332-99d0-112c0822b1ba@github.com>

> After finding a hash match, getEntryPos needs to compare the lookup name up to the encoded entry name in the CEN. This comparison is done by decoding the entry name into a String. The names can then be compared using the String API. This decoding step adds a significat cost to this method.
> 
> This PR suggest to update the string comparison such that in the common case where  both the lookup name and the entry name are encoded in ASCII-compatible UTF-8,  decoding can be avoided and the byte arrays can instead be compared direcly. 
> 
> ZipCoder is updated with a new method to compare a string with an encoded byte array range.  The default implementation decodes to string (like the current code), while the UTF-8 implementation uses JavaLangAccess.getBytesNoRepl to get the  bytes. Both methods thes uses Arrays.mismatch for comparison with or without matching trailing slashes. 
> 
> Additionally, this PR suggest to make the following updates to getEntryPos:
> 
> - The try/catch for IAE is redundant and can be safely removed. (initCEN already checks this and will throws IAE for invalid UTF-8). This seems to give a 3-4% speedup on micros)
> - A new test InvalidBytesInEntryNameOrComment is a added to verify that initCEN does in fact reject invalid UTF-8 in CEN file names and comments. (I found no existing test coverage for this)
> - The recursion when looking for "name/" matches is replaced with iteration. We keep track of any "name/" match and return it at the end of the search. (I feel this is easier to follow and it also gives a ~30% speedup for addSlash lookups with no regression on regular lookups)
> 
> (My though is that including these additional updates in this PR might reduce reviewer overhead given that it touches the exact same code. I might be wrong on this, please advise :)
> 
> I'm seeing a ~17% saving on the micro ZipFileGetEntry.getEntryHit (modified to use xalan.jar):
> 
> Baseline:
> 
> Benchmark                             (size)  Mode  Cnt    Score   Error  Units
> ZipFileGetEntry.getEntryHit              512  avgt   15   74.941 ? 1.004  ns/op
> ZipFileGetEntry.getEntryHit             1024  avgt   15   84.943 ? 1.320  ns/op
> ZipFileGetEntry.getEntryHitUncached      512  avgt   15  120.371 ? 2.386  ns/op
> ZipFileGetEntry.getEntryHitUncached     1024  avgt   15  126.128 ? 1.075  ns/op
> ZipFileGetEntry.getEntryMiss             512  avgt   15   23.818 ? 0.838  ns/op
> ZipFileGetEntry.getEntryMiss            1024  avgt   15   29.762 ? 5.998  ns/op
> ZipFileGetEntry.getEntryMissUncached     512  avgt   15   59.405 ? 0.545  ns/op
> ZipFileGetEntry.getEntryMissUncached    1024  avgt   15   71.840 ? 2.455  ns/op
> ZipFileGetEntry.getEntrySlash            512  avgt   15  135.621 ? 4.341  ns/op
> ZipFileGetEntry.getEntrySlash           1024  avgt   15  134.190 ? 2.141  ns/op
> 
> 
> 
> PR:
> 
> 
> Benchmark                             (size)  Mode  Cnt    Score   Error  Units
> ZipFileGetEntry.getEntryHit              512  avgt   15   62.267 ? 1.329  ns/op
> ZipFileGetEntry.getEntryHit             1024  avgt   15   72.916 ? 2.428  ns/op
> ZipFileGetEntry.getEntryHitUncached      512  avgt   15  101.630 ? 1.154  ns/op
> ZipFileGetEntry.getEntryHitUncached     1024  avgt   15  113.161 ? 0.502  ns/op
> ZipFileGetEntry.getEntryMiss             512  avgt   15   23.003 ? 1.191  ns/op
> ZipFileGetEntry.getEntryMiss            1024  avgt   15   23.236 ? 1.114  ns/op
> ZipFileGetEntry.getEntryMissUncached     512  avgt   15   56.781 ? 1.505  ns/op
> ZipFileGetEntry.getEntryMissUncached    1024  avgt   15   67.767 ? 1.963  ns/op
> ZipFileGetEntry.getEntrySlash            512  avgt   15   73.745 ? 2.717  ns/op
> ZipFileGetEntry.getEntrySlash           1024  avgt   15   75.784 ? 1.051  ns/op
> 
> 
> To assess the impact on startup/warmup, I made a main method class which measures the total time of calling ZipFile.getEntry for all entries in the 109 JAR file dependenies of spring-petclinic. The shows a nice improvement (time in micros):
> 
> 
> Percentile Baseline Patch
> 50?%          23155 21149
> 75?%          23598 21454
> 90?%          23989 21691
> 95?%          24238 21973
> 99?%          25270 22446
> STDEV           792   549
> Count           500   500

Eirik Bjorsnos has updated the pull request incrementally with one additional commit since the last revision:

  Moving startsWith check first to avoid back-to-back equals,startsWith calls

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12290/files
  - new: https://git.openjdk.org/jdk/pull/12290/files/3cb77dba..427ad671

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12290&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12290&range=06-07

  Stats: 12 lines in 1 file changed: 5 ins; 2 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/12290.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12290/head:pull/12290

PR: https://git.openjdk.org/jdk/pull/12290

From redestad at openjdk.org  Thu Feb  9 11:47:03 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Thu, 9 Feb 2023 11:47:03 GMT
Subject: RFR: 8301873: Avoid string decoding in ZipFile.Source.getEntryPos
 [v7]
In-Reply-To: <CF983B0JFz9rFPwtQZ-C9QpBYlpm3pfOpvD9pSstLL0=.daf6286d-59d9-4450-aff8-ad003199bd50@github.com>
References: <FkmdspiHVjkAKFqm5kUgwaf55YH5cBbczS_3krqsdFs=.05eca901-f55f-47d9-b1bc-0cf2f5b87536@github.com>
 <CF983B0JFz9rFPwtQZ-C9QpBYlpm3pfOpvD9pSstLL0=.daf6286d-59d9-4450-aff8-ad003199bd50@github.com>
Message-ID: <zh4bPYEJKuuwY0SfsnvunqNS_zKn-3syD-m1u_E2ObQ=.55214e8b-4d50-4f44-abdd-1e8e9e2f9275@github.com>

On Wed, 8 Feb 2023 16:36:16 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

>> After finding a hash match, getEntryPos needs to compare the lookup name up to the encoded entry name in the CEN. This comparison is done by decoding the entry name into a String. The names can then be compared using the String API. This decoding step adds a significat cost to this method.
>> 
>> This PR suggest to update the string comparison such that in the common case where  both the lookup name and the entry name are encoded in ASCII-compatible UTF-8,  decoding can be avoided and the byte arrays can instead be compared direcly. 
>> 
>> ZipCoder is updated with a new method to compare a string with an encoded byte array range.  The default implementation decodes to string (like the current code), while the UTF-8 implementation uses JavaLangAccess.getBytesNoRepl to get the  bytes. Both methods thes uses Arrays.mismatch for comparison with or without matching trailing slashes. 
>> 
>> Additionally, this PR suggest to make the following updates to getEntryPos:
>> 
>> - The try/catch for IAE is redundant and can be safely removed. (initCEN already checks this and will throws IAE for invalid UTF-8). This seems to give a 3-4% speedup on micros)
>> - A new test InvalidBytesInEntryNameOrComment is a added to verify that initCEN does in fact reject invalid UTF-8 in CEN file names and comments. (I found no existing test coverage for this)
>> - The recursion when looking for "name/" matches is replaced with iteration. We keep track of any "name/" match and return it at the end of the search. (I feel this is easier to follow and it also gives a ~30% speedup for addSlash lookups with no regression on regular lookups)
>> 
>> (My though is that including these additional updates in this PR might reduce reviewer overhead given that it touches the exact same code. I might be wrong on this, please advise :)
>> 
>> I'm seeing a ~17% saving on the micro ZipFileGetEntry.getEntryHit (modified to use xalan.jar):
>> 
>> Baseline:
>> 
>> Benchmark                             (size)  Mode  Cnt    Score   Error  Units
>> ZipFileGetEntry.getEntryHit              512  avgt   15   74.941 ? 1.004  ns/op
>> ZipFileGetEntry.getEntryHit             1024  avgt   15   84.943 ? 1.320  ns/op
>> ZipFileGetEntry.getEntryHitUncached      512  avgt   15  120.371 ? 2.386  ns/op
>> ZipFileGetEntry.getEntryHitUncached     1024  avgt   15  126.128 ? 1.075  ns/op
>> ZipFileGetEntry.getEntryMiss             512  avgt   15   23.818 ? 0.838  ns/op
>> ZipFileGetEntry.getEntryMiss            1024  avgt   15   29.762 ? 5.998  ns/op
>> ZipFileGetEntry.getEntryMissUncached     512  avgt   15   59.405 ? 0.545  ns/op
>> ZipFileGetEntry.getEntryMissUncached    1024  avgt   15   71.840 ? 2.455  ns/op
>> ZipFileGetEntry.getEntrySlash            512  avgt   15  135.621 ? 4.341  ns/op
>> ZipFileGetEntry.getEntrySlash           1024  avgt   15  134.190 ? 2.141  ns/op
>> 
>> 
>> 
>> PR:
>> 
>> 
>> Benchmark                             (size)  Mode  Cnt    Score   Error  Units
>> ZipFileGetEntry.getEntryHit              512  avgt   15   62.267 ? 1.329  ns/op
>> ZipFileGetEntry.getEntryHit             1024  avgt   15   72.916 ? 2.428  ns/op
>> ZipFileGetEntry.getEntryHitUncached      512  avgt   15  101.630 ? 1.154  ns/op
>> ZipFileGetEntry.getEntryHitUncached     1024  avgt   15  113.161 ? 0.502  ns/op
>> ZipFileGetEntry.getEntryMiss             512  avgt   15   23.003 ? 1.191  ns/op
>> ZipFileGetEntry.getEntryMiss            1024  avgt   15   23.236 ? 1.114  ns/op
>> ZipFileGetEntry.getEntryMissUncached     512  avgt   15   56.781 ? 1.505  ns/op
>> ZipFileGetEntry.getEntryMissUncached    1024  avgt   15   67.767 ? 1.963  ns/op
>> ZipFileGetEntry.getEntrySlash            512  avgt   15   73.745 ? 2.717  ns/op
>> ZipFileGetEntry.getEntrySlash           1024  avgt   15   75.784 ? 1.051  ns/op
>> 
>> 
>> To assess the impact on startup/warmup, I made a main method class which measures the total time of calling ZipFile.getEntry for all entries in the 109 JAR file dependenies of spring-petclinic. The shows a nice improvement (time in micros):
>> 
>> 
>> Percentile Baseline Patch
>> 50?%          23155 21149
>> 75?%          23598 21454
>> 90?%          23989 21691
>> 95?%          24238 21973
>> 99?%          25270 22446
>> STDEV           792   549
>> Count           500   500
>
> Eirik Bjorsnos has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update the sameHashAndLengthDirLookup to use ASCII example colliding paths, allowing the test to run over all charsets

Yes, I'll file a PR to see if we can make `startsWith` a bit sharper. In addition to - or instead of - an `equals` shortcut then if coders are the same we could use `ArraysSupport.mismatch` which should get similar speed and help more generally.

-------------

PR: https://git.openjdk.org/jdk/pull/12290

From duke at openjdk.org  Thu Feb  9 11:49:44 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Thu, 9 Feb 2023 11:49:44 GMT
Subject: RFR: 8301873: Avoid string decoding in ZipFile.Source.getEntryPos
 [v7]
In-Reply-To: <zh4bPYEJKuuwY0SfsnvunqNS_zKn-3syD-m1u_E2ObQ=.55214e8b-4d50-4f44-abdd-1e8e9e2f9275@github.com>
References: <FkmdspiHVjkAKFqm5kUgwaf55YH5cBbczS_3krqsdFs=.05eca901-f55f-47d9-b1bc-0cf2f5b87536@github.com>
 <CF983B0JFz9rFPwtQZ-C9QpBYlpm3pfOpvD9pSstLL0=.daf6286d-59d9-4450-aff8-ad003199bd50@github.com>
 <zh4bPYEJKuuwY0SfsnvunqNS_zKn-3syD-m1u_E2ObQ=.55214e8b-4d50-4f44-abdd-1e8e9e2f9275@github.com>
Message-ID: <oUVRygqci4pYyTmdVQA64YlkE-gV1VlGR0uTXGo10_g=.08da16a9-64b6-4ed9-bdbd-3748a6733753@github.com>

On Thu, 9 Feb 2023 11:39:18 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> Yes, I'll file a PR to see if we can make `startsWith` a bit sharper

Thanks! I pushed the change to ZipCoder.compare.

> In addition to - or instead of - an `equals` shortcut then if coders are the same we could use `ArraysSupport.mismatch` which should get similar speed and help more generally.

..and if String had (an optimized) mismatch method, then I bet all or most of the comparison methods (equals, compareTo, endsWith, startsWith, regionMatches) could delegate to that  :-)

-------------

PR: https://git.openjdk.org/jdk/pull/12290

From jwilhelm at openjdk.org  Thu Feb  9 12:02:54 2023
From: jwilhelm at openjdk.org (Jesper Wilhelmsson)
Date: Thu, 9 Feb 2023 12:02:54 GMT
Subject: Integrated: Merge jdk20
In-Reply-To: <FSx6A_Vz1okUT1ctC5bJP9l7E5fx-f2eltAgnJly1Zc=.1fb6f527-f4e3-4538-86da-21c44dd02a16@github.com>
References: <FSx6A_Vz1okUT1ctC5bJP9l7E5fx-f2eltAgnJly1Zc=.1fb6f527-f4e3-4538-86da-21c44dd02a16@github.com>
Message-ID: <GtgM6SXWQ2Sys3OsECMGaxD59trDmKT-PLt0JZ1dcdI=.3124732a-7e60-42c0-9176-6e40c0d4ec55@github.com>

On Thu, 9 Feb 2023 07:43:28 GMT, Jesper Wilhelmsson <jwilhelm at openjdk.org> wrote:

> Forwardport JDK 20 -> JDK 21

This pull request has now been integrated.

Changeset: af8973dc
Author:    Jesper Wilhelmsson <jwilhelm at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/af8973dc509c1f326223e3ffd1773c9e930141d8
Stats:     69 lines in 3 files changed: 50 ins; 9 del; 10 mod

Merge

-------------

PR: https://git.openjdk.org/jdk/pull/12484

From duke at openjdk.org  Thu Feb  9 12:07:04 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Thu, 9 Feb 2023 12:07:04 GMT
Subject: RFR: 8301873: Avoid string decoding in ZipFile.Source.getEntryPos
 [v9]
In-Reply-To: <FkmdspiHVjkAKFqm5kUgwaf55YH5cBbczS_3krqsdFs=.05eca901-f55f-47d9-b1bc-0cf2f5b87536@github.com>
References: <FkmdspiHVjkAKFqm5kUgwaf55YH5cBbczS_3krqsdFs=.05eca901-f55f-47d9-b1bc-0cf2f5b87536@github.com>
Message-ID: <p2-revzHDap8mmK22cZnmfocoxjzMZgOWsQX2p8iLYo=.2f9cfa42-46ca-4527-9b4a-103dd06fcdc3@github.com>

> After finding a hash match, getEntryPos needs to compare the lookup name up to the encoded entry name in the CEN. This comparison is done by decoding the entry name into a String. The names can then be compared using the String API. This decoding step adds a significat cost to this method.
> 
> This PR suggest to update the string comparison such that in the common case where  both the lookup name and the entry name are encoded in ASCII-compatible UTF-8,  decoding can be avoided and the byte arrays can instead be compared direcly. 
> 
> ZipCoder is updated with a new method to compare a string with an encoded byte array range.  The default implementation decodes to string (like the current code), while the UTF-8 implementation uses JavaLangAccess.getBytesNoRepl to get the  bytes. Both methods thes uses Arrays.mismatch for comparison with or without matching trailing slashes. 
> 
> Additionally, this PR suggest to make the following updates to getEntryPos:
> 
> - The try/catch for IAE is redundant and can be safely removed. (initCEN already checks this and will throws IAE for invalid UTF-8). This seems to give a 3-4% speedup on micros)
> - A new test InvalidBytesInEntryNameOrComment is a added to verify that initCEN does in fact reject invalid UTF-8 in CEN file names and comments. (I found no existing test coverage for this)
> - The recursion when looking for "name/" matches is replaced with iteration. We keep track of any "name/" match and return it at the end of the search. (I feel this is easier to follow and it also gives a ~30% speedup for addSlash lookups with no regression on regular lookups)
> 
> (My though is that including these additional updates in this PR might reduce reviewer overhead given that it touches the exact same code. I might be wrong on this, please advise :)
> 
> I'm seeing a ~17% saving on the micro ZipFileGetEntry.getEntryHit (modified to use xalan.jar):
> 
> Baseline:
> 
> Benchmark                             (size)  Mode  Cnt    Score   Error  Units
> ZipFileGetEntry.getEntryHit              512  avgt   15   74.941 ? 1.004  ns/op
> ZipFileGetEntry.getEntryHit             1024  avgt   15   84.943 ? 1.320  ns/op
> ZipFileGetEntry.getEntryHitUncached      512  avgt   15  120.371 ? 2.386  ns/op
> ZipFileGetEntry.getEntryHitUncached     1024  avgt   15  126.128 ? 1.075  ns/op
> ZipFileGetEntry.getEntryMiss             512  avgt   15   23.818 ? 0.838  ns/op
> ZipFileGetEntry.getEntryMiss            1024  avgt   15   29.762 ? 5.998  ns/op
> ZipFileGetEntry.getEntryMissUncached     512  avgt   15   59.405 ? 0.545  ns/op
> ZipFileGetEntry.getEntryMissUncached    1024  avgt   15   71.840 ? 2.455  ns/op
> ZipFileGetEntry.getEntrySlash            512  avgt   15  135.621 ? 4.341  ns/op
> ZipFileGetEntry.getEntrySlash           1024  avgt   15  134.190 ? 2.141  ns/op
> 
> 
> 
> PR:
> 
> 
> Benchmark                             (size)  Mode  Cnt    Score   Error  Units
> ZipFileGetEntry.getEntryHit              512  avgt   15   62.267 ? 1.329  ns/op
> ZipFileGetEntry.getEntryHit             1024  avgt   15   72.916 ? 2.428  ns/op
> ZipFileGetEntry.getEntryHitUncached      512  avgt   15  101.630 ? 1.154  ns/op
> ZipFileGetEntry.getEntryHitUncached     1024  avgt   15  113.161 ? 0.502  ns/op
> ZipFileGetEntry.getEntryMiss             512  avgt   15   23.003 ? 1.191  ns/op
> ZipFileGetEntry.getEntryMiss            1024  avgt   15   23.236 ? 1.114  ns/op
> ZipFileGetEntry.getEntryMissUncached     512  avgt   15   56.781 ? 1.505  ns/op
> ZipFileGetEntry.getEntryMissUncached    1024  avgt   15   67.767 ? 1.963  ns/op
> ZipFileGetEntry.getEntrySlash            512  avgt   15   73.745 ? 2.717  ns/op
> ZipFileGetEntry.getEntrySlash           1024  avgt   15   75.784 ? 1.051  ns/op
> 
> 
> To assess the impact on startup/warmup, I made a main method class which measures the total time of calling ZipFile.getEntry for all entries in the 109 JAR file dependenies of spring-petclinic. The shows a nice improvement (time in micros):
> 
> 
> Percentile Baseline Patch
> 50?%          23155 21149
> 75?%          23598 21454
> 90?%          23989 21691
> 95?%          24238 21973
> 99?%          25270 22446
> STDEV           792   549
> Count           500   500

Eirik Bjorsnos has updated the pull request incrementally with one additional commit since the last revision:

  Revert accidental removal of UTF8ZipCoder.compare

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12290/files
  - new: https://git.openjdk.org/jdk/pull/12290/files/427ad671..d94cbe38

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12290&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12290&range=07-08

  Stats: 3 lines in 1 file changed: 0 ins; 3 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/12290.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12290/head:pull/12290

PR: https://git.openjdk.org/jdk/pull/12290

From duke at openjdk.org  Thu Feb  9 12:10:44 2023
From: duke at openjdk.org (SUN Guoyun)
Date: Thu, 9 Feb 2023 12:10:44 GMT
Subject: RFR: 8301737:
 java/rmi/server/UnicastRemoteObject/serialFilter/FilterUROTest.java fail with
 -Xcomp [v4]
In-Reply-To: <LCJW-DKImXCmpxwBGKJPmSKAUnz9dHg-T09tqD9-SMU=.87d63cd0-6b22-4af8-9786-bd6c75d04ca2@github.com>
References: <l5m5_9io2QMSFNY7dBHT3Nr2I9Er8wmd92Ze8FP-XE0=.a40d29be-77be-4719-a0a0-71d032eea1e5@github.com>
 <LCJW-DKImXCmpxwBGKJPmSKAUnz9dHg-T09tqD9-SMU=.87d63cd0-6b22-4af8-9786-bd6c75d04ca2@github.com>
Message-ID: <XJCRIMFhp4AtggcrteodCj2HlmKO8EsXNO1OZHuT4DY=.84f751a2-7bd2-4a90-a497-f3468e7541e6@github.com>

On Thu, 9 Feb 2023 08:48:17 GMT, SUN Guoyun <duke at openjdk.org> wrote:

>> Hi all,
>> When -Xcomp be used, this testcase will use more codecaches, causing the GC to be triggered early, then causing this test failed on LoongArch64 architecture.
>> 
>> This PR fix the issue, Please help review it.
>> 
>> Thanks.
>
> SUN Guoyun has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8301737: java/rmi/server/UnicastRemoteObject/serialFilter/FilterUROTest.java fail with -Xcomp

I adjusted the parameters appropriately to `-Xcomp -Dsun.rmi.dgc.logLevel=VERBOSE -XX:ReservedCodeCacheSize=160m` and was able to reproduce the error I found earlier.

STDERR:
Feb 09, 2023 7:59:32 PM sun.rmi.transport.Target pinImpl
FINER: MainThread: strongRef = sun.rmi.transport.DGCImpl at 3088ba53
Feb 09, 2023 7:59:37 PM sun.rmi.transport.DGCImpl$2 run
FINER: MainThread: add object [0:0:0, 2]
Feb 09, 2023 7:59:37 PM sun.rmi.transport.Transport exportObject
FINER: MainThread: add object [697a7a97:186360b89cf:-7fff, -7341913114514311741]
Feb 09, 2023 7:59:38 PM sun.rmi.transport.ObjectTable$Reaper run
FINER: RMI Reaper: remove object [697a7a97:186360b89cf:-7fff, -7341913114514311741]
java.rmi.NoSuchObjectException: no such object in table

-------------

PR: https://git.openjdk.org/jdk/pull/12399

From msheppar at openjdk.org  Thu Feb  9 12:31:43 2023
From: msheppar at openjdk.org (Mark Sheppard)
Date: Thu, 9 Feb 2023 12:31:43 GMT
Subject: RFR: 8301737:
 java/rmi/server/UnicastRemoteObject/serialFilter/FilterUROTest.java fail with
 -Xcomp [v4]
In-Reply-To: <LCJW-DKImXCmpxwBGKJPmSKAUnz9dHg-T09tqD9-SMU=.87d63cd0-6b22-4af8-9786-bd6c75d04ca2@github.com>
References: <l5m5_9io2QMSFNY7dBHT3Nr2I9Er8wmd92Ze8FP-XE0=.a40d29be-77be-4719-a0a0-71d032eea1e5@github.com>
 <LCJW-DKImXCmpxwBGKJPmSKAUnz9dHg-T09tqD9-SMU=.87d63cd0-6b22-4af8-9786-bd6c75d04ca2@github.com>
Message-ID: <nxrYlDATz_kf5smesGbpXkPEjEaR8eMzC068A6bC25I=.00031471-e6f1-4ebf-9cd1-cd29940bffb3@github.com>

On Thu, 9 Feb 2023 08:48:17 GMT, SUN Guoyun <duke at openjdk.org> wrote:

>> Hi all,
>> When -Xcomp be used, this testcase will use more codecaches, causing the GC to be triggered early, then causing this test failed on LoongArch64 architecture.
>> 
>> This PR fix the issue, Please help review it.
>> 
>> Thanks.
>
> SUN Guoyun has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8301737: java/rmi/server/UnicastRemoteObject/serialFilter/FilterUROTest.java fail with -Xcomp

As you have shown moving the impl to a member variable of the test, allows the test to pass and means that when the reaper runs it doesn't find a weak reference for the RemoteImpl. We can see this in trace below ... there are no remove call on ObjectTable

Feb 09, 2023 12:03:13 PM sun.rmi.transport.Target pinImpl
FINER: MainThread: strongRef = sun.rmi.transport.DGCImpl at 7cbf0dfe
Feb 09, 2023 12:03:13 PM sun.rmi.transport.DGCImpl$2 run
FINER: MainThread: add object [0:0:0, 2]
Feb 09, 2023 12:03:13 PM sun.rmi.transport.Transport exportObject
FINER: MainThread: add object [e560232:186360eee7e:-7fff, -828094982909796927]
Feb 09, 2023 12:03:13 PM sun.rmi.transport.Transport exportObject
FINER: MainThread: add object [e560232:186360eee7e:-7ffd, 1016769954862579574]
Feb 09, 2023 12:03:13 PM sun.rmi.transport.Transport exportObject
FINER: MainThread: add object [e560232:186360eee7e:-7ffb, 5046449780262743815]
Feb 09, 2023 12:03:13 PM sun.rmi.transport.Transport exportObject
FINER: MainThread: add object [e560232:186360eee7e:-7ff9, -5609899494232426191]
Feb 09, 2023 12:03:13 PM sun.rmi.transport.Transport exportObject
FINER: MainThread: add object [e560232:186360eee7e:-7ff7, -3723530497788482934]
Feb 09, 2023 12:03:13 PM sun.rmi.transport.Transport exportObject
FINER: MainThread: add object [e560232:186360eee7e:-7ff5, 26547078264881776]
Feb 09, 2023 12:03:13 PM sun.rmi.transport.Transport exportObject
FINER: MainThread: add object [e560232:186360eee7e:-7ff3, 893326842025149942]
Feb 09, 2023 12:03:13 PM sun.rmi.transport.Transport exportObject
FINER: MainThread: add object [e560232:186360eee7e:-7ff1, -5974039217477050622]
Feb 09, 2023 12:03:13 PM sun.rmi.transport.Transport exportObject
FINER: MainThread: add object [e560232:186360eee7e:-7fef, -8933988202720453193]
Feb 09, 2023 12:03:13 PM sun.rmi.transport.Transport exportObject
FINER: MainThread: add object [e560232:186360eee7e:-7fed, -3244609101583748901]
STATUS:Passed.


I have an instrumented build and we can see that the Reaper's  reapQueue is empty, no weak refreences, when it runs first time

ObjectTable::incrementKeepAliveCount Reaper Thread started 
ObjectTable::Reaper::run ENTER thread Thread[#23,RMI Reaper,5,system]
ObjectTable::Reaper::run check reapQueue Thread[#23,RMI Reaper,5,system]
ObjectTable::incrementKeepAliveCount gcInterval == 3600000


> After `-Dsun.rmi.dgc.logLevel=VERBOSE`, test run passed. I don't understand why, you know?

as it's a subtle race condition within the test, the logging can delay when the removal event happens

If declaring impl as a member variable works, and mitigates the failure, then that's a reasonable work around ... I expect Roger will comment on this further.

-------------

PR: https://git.openjdk.org/jdk/pull/12399

From duke at openjdk.org  Thu Feb  9 12:46:51 2023
From: duke at openjdk.org (SUN Guoyun)
Date: Thu, 9 Feb 2023 12:46:51 GMT
Subject: RFR: 8301737:
 java/rmi/server/UnicastRemoteObject/serialFilter/FilterUROTest.java fail with
 -Xcomp [v4]
In-Reply-To: <LCJW-DKImXCmpxwBGKJPmSKAUnz9dHg-T09tqD9-SMU=.87d63cd0-6b22-4af8-9786-bd6c75d04ca2@github.com>
References: <l5m5_9io2QMSFNY7dBHT3Nr2I9Er8wmd92Ze8FP-XE0=.a40d29be-77be-4719-a0a0-71d032eea1e5@github.com>
 <LCJW-DKImXCmpxwBGKJPmSKAUnz9dHg-T09tqD9-SMU=.87d63cd0-6b22-4af8-9786-bd6c75d04ca2@github.com>
Message-ID: <FX8D2HHGfX3FdM6SnrJHioWwoWNasF7rUX3nTVuIPsw=.998aeb7a-5ed6-4980-ada2-cc07b19b3126@github.com>

On Thu, 9 Feb 2023 08:48:17 GMT, SUN Guoyun <duke at openjdk.org> wrote:

>> Hi all,
>> When -Xcomp be used, this testcase will use more codecaches, causing the GC to be triggered early, then causing this test failed on LoongArch64 architecture.
>> 
>> This PR fix the issue, Please help review it.
>> 
>> Thanks.
>
> SUN Guoyun has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8301737: java/rmi/server/UnicastRemoteObject/serialFilter/FilterUROTest.java fail with -Xcomp

Thanks for your clear explanation.

-------------

PR: https://git.openjdk.org/jdk/pull/12399

From mcimadamore at openjdk.org  Thu Feb  9 12:47:52 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 9 Feb 2023 12:47:52 GMT
Subject: RFR: 8294982: Implementation of Classfile API [v12]
In-Reply-To: <wzHOP5Fnj3FhcNs61TKxxBZ5R6fB-oky72z_hlf1Svk=.ed56a42f-cce6-415a-b93a-d39dee6adc78@github.com>
References: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
 <Q4VeZ2yWAg85FqUDJa5hYq3jHty5H547gD0H-x3oIq0=.58d463a4-237a-4fee-bd0f-83262d49522a@github.com>
 <c022hrWNEHW76nhP_sXTQXCTjtL8jjM8r_yYv0IvbPI=.2a9cfbae-2fef-4cdb-8189-b869b1513fef@github.com>
 <FbFekphAbS5DQzn6B-uUHkX-2EF8Aq4NcijjMdlxAM0=.280a7529-4008-4539-9137-da7600e13eee@github.com>
 <kxds1bmvZ8TbtVK5iDx_hZtrqN3uywsa6GqumJ7RubE=.ffd151e4-a1ba-4018-914c-518fd122dd4f@github.com>
 <WxjOq5CRJ9OtviOIxDKH9C78bScpiGmkiBqVXLDddzU=.a5a85537-43e8-4cf4-b747-86b945999d71@github.com>
 <84RlLSIsacJTJVM-esvzoXnQ5rDEByog5b1ibFRJOE8=.05e8e7a7-2185-4e1c-b5b9-59ce3b3eea03@github.com>
 <sQwAa41mu1z226uzYIA2_v0tN8un257MDgc-WPO8SFY=.486c845c-5012-4291-bcd7-c7b0247e02dd@github.com>
 <wxsAcKZwigc4sIUexg5m-6UlOg8ZHflccTs47FJCgdQ=.5613b95e-96b0-4ced-a587-ccca3f80595d@github.com>
 <_jsw8D5-esoFp7fGSZECKF8ccwrfikwjIprRrVdCOjo=.2d8cd9f6-9c6a-4726-bc90-a4c163e8dd67@github.com>
 <LICxfIJ0QVmRRY4NJPCW_Rp4o3qhyaMrrgW
 LV-S9jHI=.4f6b40d5-d25d-4035-8fa5-186b2c735606@github.com>
 <wzHOP5Fnj3FhcNs61TKxxBZ5R6fB-oky72z_hlf1Svk=.ed56a42f-cce6-415a-b93a-d39dee6adc78@github.com>
Message-ID: <hhnDQ3Sx7BiJ05Jt32dwEKi93Rs1rkxi_kTbfJH93oI=.ace5a7f6-8ba4-42cc-9046-8ac190b12866@github.com>

On Wed, 8 Feb 2023 13:44:13 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> OK, I see your point now, I'll fix it.
>> Thanks
>
> During the fix I found the definition that `ThrowableSig` (as a super-set of `ClassTypeSig` and `TypeVarSig`) IS `Signature` - that fact is critical for processing.
> For example when `MethodSignature` is serialized `ThrowableSig::signatureString` is critical.
> Or `ClassRemapper` depends on the inheritence:
> 
> signature.throwableSignatures().stream().map(this::mapSignature).toList()
> 
> however `mapSignature` could not be applied on `ThrowableSig` when it does not inherit from `Signature`.

I think I also see where the current hierarchy comes from - e.g. while `ThrowableSig` is a part of a method signature, it is indeed used by the production to specify a set of signatures that belong to that set. Thanks for the patience.

-------------

PR: https://git.openjdk.org/jdk/pull/10982

From redestad at openjdk.org  Thu Feb  9 13:08:43 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Thu, 9 Feb 2023 13:08:43 GMT
Subject: RFR: 8301873: Avoid string decoding in ZipFile.Source.getEntryPos
 [v7]
In-Reply-To: <oUVRygqci4pYyTmdVQA64YlkE-gV1VlGR0uTXGo10_g=.08da16a9-64b6-4ed9-bdbd-3748a6733753@github.com>
References: <FkmdspiHVjkAKFqm5kUgwaf55YH5cBbczS_3krqsdFs=.05eca901-f55f-47d9-b1bc-0cf2f5b87536@github.com>
 <CF983B0JFz9rFPwtQZ-C9QpBYlpm3pfOpvD9pSstLL0=.daf6286d-59d9-4450-aff8-ad003199bd50@github.com>
 <zh4bPYEJKuuwY0SfsnvunqNS_zKn-3syD-m1u_E2ObQ=.55214e8b-4d50-4f44-abdd-1e8e9e2f9275@github.com>
 <oUVRygqci4pYyTmdVQA64YlkE-gV1VlGR0uTXGo10_g=.08da16a9-64b6-4ed9-bdbd-3748a6733753@github.com>
Message-ID: <JHZlRN3wF3Fvkgp9iRG9qE-Y7YOzSFKGoz_3QT8Qr8M=.b2d92463-1ebd-4131-b08a-f48fe855e940@github.com>

On Thu, 9 Feb 2023 11:46:42 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

> > In addition to - or instead of - an `equals` shortcut then if coders are the same we could use `ArraysSupport.mismatch` which should get similar speed and help more generally.
> 
> ..and if String had (an optimized) mismatch method, then I bet all or most of the comparison methods (equals, compareTo, endsWith, startsWith, regionMatches) could delegate to that :-)

A private mismatch method might make sense. A public method would require making a stronger case, I think, e.g. showing use cases a mismatcher would solve (elegantly, performantly) that can't be expressed with existing methods.

-------------

PR: https://git.openjdk.org/jdk/pull/12290

From pminborg at openjdk.org  Thu Feb  9 13:39:20 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 9 Feb 2023 13:39:20 GMT
Subject: RFR: 8301552: Use AtomicReferenceArray for caching instead of CHM
 in ZoneOffset [v7]
In-Reply-To: <b228oWPoEJf0lfGgIVXwmo1mATeKWRTivuJ2PbgwAmI=.465a4f9b-7a4b-4bbb-9f94-66d1d889a072@github.com>
References: <b228oWPoEJf0lfGgIVXwmo1mATeKWRTivuJ2PbgwAmI=.465a4f9b-7a4b-4bbb-9f94-66d1d889a072@github.com>
Message-ID: <wHIb6FlXPGwkt5rdXpUGzDT6OUAqgeJc6twV6PFZ65I=.b2fbaa37-a328-4930-9df5-94f2d832c83e@github.com>

> `ZoneOffset` instances are cached by the `ZoneOffset` class itself for values in the range [-18h, 18h] for each second that is on an even quarter of an hour (i.e. at most 2*18*4+1 = 145 values). 
> 
> Instead of using a `ConcurrentHashMap` for caching instanced, we could instead use an `AtomicReferenceArray` with direct slot value access for said even seconds. This will improve performance and reduce the number of object even though the backing array will go from an initial 32 in the CHM to an initial/final 145 in the ARA. The CHM will contain much more objects and array slots for typical numbers of entries in the cache and will compute hash/bucket/collision on the hot code path for each cache access.

Per Minborg has updated the pull request incrementally with one additional commit since the last revision:

  Add a generic LazyReferenceArray

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12346/files
  - new: https://git.openjdk.org/jdk/pull/12346/files/1cd2b406..b89a9aae

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12346&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12346&range=05-06

  Stats: 305 lines in 4 files changed: 275 ins; 19 del; 11 mod
  Patch: https://git.openjdk.org/jdk/pull/12346.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12346/head:pull/12346

PR: https://git.openjdk.org/jdk/pull/12346

From duke at openjdk.org  Thu Feb  9 13:46:05 2023
From: duke at openjdk.org (Varada M)
Date: Thu, 9 Feb 2023 13:46:05 GMT
Subject: RFR: 8300139 : [AIX] Use pthreads to avoid JNI_createVM call from
 primordial thread [v4]
In-Reply-To: <qbwPBNdxzk4QmB9L6y2t-X6uYgAaPjzAEwYfs_5XV_0=.4ea982e6-30da-4219-b8ad-fa36690170b8@github.com>
References: <qbwPBNdxzk4QmB9L6y2t-X6uYgAaPjzAEwYfs_5XV_0=.4ea982e6-30da-4219-b8ad-fa36690170b8@github.com>
Message-ID: <5Swts2qP-_tCVVWfSYWyFDWM-dEdF_2bs7WXVEBuD3Y=.a3a25f89-1d21-4490-bb48-de81f65245df@github.com>

> 1. test/jdk/jni/nullCaller/NullCallerTest.java
> 2. test/jdk/java/lang/reflect/exeCallerAccessTest/CallerAccessTest.java
> 3. test/hotspot/jtreg/runtime/jni/CalleeSavedRegisters/FPRegs.java 
> 
>     The above tests were blocked on AIX [@require os.family != "aix"] because these tests are failing to call JNI_CreateJavaVM. This is solved by implementing JNI_CreateJavaVM call via POSIX threads. 
>    Similarly there are tests which are not blocked and still failing to call JNI_CreateJavaVM on AIX :
> 
> 4. test/hotspot/jtreg/runtime/jni/daemonDestroy/TestDaemonDestroy.java { PR : [12006](https://github.com/openjdk/jdk/pull/12006) }
> 5. test/lib-test/jdk/test/lib/process/TestNativeProcessBuilder.java 
> 
> The reported issue : [8300139](https://bugs.openjdk.org/browse/JDK-8300139l)

Varada M has updated the pull request incrementally with one additional commit since the last revision:

  Fixes

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12302/files
  - new: https://git.openjdk.org/jdk/pull/12302/files/87e6cfba..32614a2c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12302&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12302&range=02-03

  Stats: 29 lines in 6 files changed: 0 ins; 4 del; 25 mod
  Patch: https://git.openjdk.org/jdk/pull/12302.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12302/head:pull/12302

PR: https://git.openjdk.org/jdk/pull/12302

From pminborg at openjdk.org  Thu Feb  9 13:46:14 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 9 Feb 2023 13:46:14 GMT
Subject: RFR: 8301552: Use AtomicReferenceArray for caching instead of CHM
 in ZoneOffset [v8]
In-Reply-To: <b228oWPoEJf0lfGgIVXwmo1mATeKWRTivuJ2PbgwAmI=.465a4f9b-7a4b-4bbb-9f94-66d1d889a072@github.com>
References: <b228oWPoEJf0lfGgIVXwmo1mATeKWRTivuJ2PbgwAmI=.465a4f9b-7a4b-4bbb-9f94-66d1d889a072@github.com>
Message-ID: <ESUpuSgjM_9ocUr1O_7tjY-Pf2sps17BX69XpDtwoEg=.c93d0dbb-372f-4827-8239-cca058a8bf48@github.com>

> `ZoneOffset` instances are cached by the `ZoneOffset` class itself for values in the range [-18h, 18h] for each second that is on an even quarter of an hour (i.e. at most 2*18*4+1 = 145 values). 
> 
> Instead of using a `ConcurrentHashMap` for caching instanced, we could instead use an `AtomicReferenceArray` with direct slot value access for said even seconds. This will improve performance and reduce the number of object even though the backing array will go from an initial 32 in the CHM to an initial/final 145 in the ARA. The CHM will contain much more objects and array slots for typical numbers of entries in the cache and will compute hash/bucket/collision on the hot code path for each cache access.

Per Minborg has updated the pull request incrementally with three additional commits since the last revision:

 - Remove unused setup method
 - Rename method in test
 - Add copyright header

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12346/files
  - new: https://git.openjdk.org/jdk/pull/12346/files/b89a9aae..29674b14

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12346&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12346&range=06-07

  Stats: 32 lines in 3 files changed: 23 ins; 8 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/12346.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12346/head:pull/12346

PR: https://git.openjdk.org/jdk/pull/12346

From duke at openjdk.org  Thu Feb  9 13:46:08 2023
From: duke at openjdk.org (Varada M)
Date: Thu, 9 Feb 2023 13:46:08 GMT
Subject: RFR: 8300139 : [AIX] Use pthreads to avoid JNI_createVM call from
 primordial thread [v4]
In-Reply-To: <jT51_OtLa2h8OS1BKl7JJP_VAZgMC_J6Tg8R3ITJSFs=.a5e19609-fd24-4e0f-9864-6742ad70c8ef@github.com>
References: <qbwPBNdxzk4QmB9L6y2t-X6uYgAaPjzAEwYfs_5XV_0=.4ea982e6-30da-4219-b8ad-fa36690170b8@github.com>
 <7NSCfG4cqgmi4DdQlYgROali8O23k-6POdWORkYsagM=.d788d6ea-c9e9-415f-8b33-5f042c38928b@github.com>
 <jT51_OtLa2h8OS1BKl7JJP_VAZgMC_J6Tg8R3ITJSFs=.a5e19609-fd24-4e0f-9864-6742ad70c8ef@github.com>
Message-ID: <V57FiT5MHqO-GOXm70GusdFFWDP89UQ05JycfxK1yjU=.715905fc-99b7-424c-afdd-ccbcf1ef9c7a@github.com>

On Thu, 9 Feb 2023 11:30:11 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Varada M has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fixes
>
> test/jdk/jni/nullCaller/exeNullCallerTest.cpp line 159:
> 
>> 157: }
>> 158: 
>> 159: int main(int argc, char** args) {
> 
> static, and space

Thanks @tstuefe . I have made changes.

-------------

PR: https://git.openjdk.org/jdk/pull/12302

From stuefe at openjdk.org  Thu Feb  9 14:07:49 2023
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Thu, 9 Feb 2023 14:07:49 GMT
Subject: RFR: 8300139 : [AIX] Use pthreads to avoid JNI_createVM call from
 primordial thread [v4]
In-Reply-To: <5Swts2qP-_tCVVWfSYWyFDWM-dEdF_2bs7WXVEBuD3Y=.a3a25f89-1d21-4490-bb48-de81f65245df@github.com>
References: <qbwPBNdxzk4QmB9L6y2t-X6uYgAaPjzAEwYfs_5XV_0=.4ea982e6-30da-4219-b8ad-fa36690170b8@github.com>
 <5Swts2qP-_tCVVWfSYWyFDWM-dEdF_2bs7WXVEBuD3Y=.a3a25f89-1d21-4490-bb48-de81f65245df@github.com>
Message-ID: <4hZdkUvIpf1uXikEyAWnEMfMPAXGltemsTz5um8Idbw=.73b0a325-9be7-4856-812e-69bb02db1c2e@github.com>

On Thu, 9 Feb 2023 13:46:05 GMT, Varada M <duke at openjdk.org> wrote:

>> 1. test/jdk/jni/nullCaller/NullCallerTest.java
>> 2. test/jdk/java/lang/reflect/exeCallerAccessTest/CallerAccessTest.java
>> 3. test/hotspot/jtreg/runtime/jni/CalleeSavedRegisters/FPRegs.java 
>> 
>>     The above tests were blocked on AIX [@require os.family != "aix"] because these tests are failing to call JNI_CreateJavaVM. This is solved by implementing JNI_CreateJavaVM call via POSIX threads. 
>>    Similarly there are tests which are not blocked and still failing to call JNI_CreateJavaVM on AIX :
>> 
>> 4. test/hotspot/jtreg/runtime/jni/daemonDestroy/TestDaemonDestroy.java { PR : [12006](https://github.com/openjdk/jdk/pull/12006) }
>> 5. test/lib-test/jdk/test/lib/process/TestNativeProcessBuilder.java 
>> 
>> The reported issue : [8300139](https://bugs.openjdk.org/browse/JDK-8300139l)
>
> Varada M has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixes

Looks good to me. Thanks.

-------------

Marked as reviewed by stuefe (Reviewer).

PR: https://git.openjdk.org/jdk/pull/12302

From mcimadamore at openjdk.org  Thu Feb  9 14:15:09 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 9 Feb 2023 14:15:09 GMT
Subject: RFR: 8294982: Implementation of Classfile API [v15]
In-Reply-To: <hr8eti6ytvV05JFRr5hYLWy7yBla9mpI8vKKfaaFR-k=.a92f7bea-6400-4f95-a40c-d57192013f19@github.com>
References: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
 <hr8eti6ytvV05JFRr5hYLWy7yBla9mpI8vKKfaaFR-k=.a92f7bea-6400-4f95-a40c-d57192013f19@github.com>
Message-ID: <hUvPqC4427nX8mcEcC5Tr90RFXAtmNigTxexY_Ujf04=.55b5e41d-afa7-4220-b13f-6fb0dd25dd0e@github.com>

On Thu, 9 Feb 2023 08:44:41 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> This is root pull request with Classfile API implementation, tests and benchmarks initial drop into JDK.
>> 
>> Following pull requests consolidating JDK class files parsing, generating, and transforming ([JDK-8294957](https://bugs.openjdk.org/browse/JDK-8294957)) will chain to this one.
>> 
>> Classfile API development is tracked at:
>> https://github.com/openjdk/jdk-sandbox/tree/classfile-api-branch
>> 
>> Development branch of consolidated JDK class files parsing, generating, and transforming is at:
>> https://github.com/openjdk/jdk-sandbox/tree/classfile-api-dev-branch
>> 
>> Classfile API [JEP](https://bugs.openjdk.org/browse/JDK-8280389) and [online API documentation](https://htmlpreview.github.io/?https://raw.githubusercontent.com/openjdk/jdk-sandbox/classfile-api-javadoc-branch/doc/classfile-api/javadoc/java.base/jdk/internal/classfile/package-summary.html) is also available.
>> 
>> Please take you time to review this non-trivial JDK addition.
>> 
>> Thank you,
>> Adam
>
> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
> 
>   AttributeElement.Kind removal (#48)

src/java.base/share/classes/jdk/internal/classfile/Classfile.java line 66:

> 64:      * @param <V> the type of the optional value
> 65:      */
> 66:     public sealed interface Option<V> permits Options.OptionValue {

After looking more at the usages of Options it is not clear to me as to why generics are needed. Lookup is always performed using a non-generic Option.Key - so the API code has to be unchecked anyway. In fact, I'm not even sure you need a `value()` method. When looking at usages, Option is mostly something you create when you need to pass it to something else (e.g. a constant pool, etc.). Since the client has created the option, it is not clear to me that the client has a need to access the option value (which the API implementation can access internally by other means).

src/java.base/share/classes/jdk/internal/classfile/constantpool/AnnotationConstantValueEntry.java line 33:

> 31:  * which includes the four kinds of primitive constants, and UTF8 constants.
> 32:  */
> 33: public sealed interface AnnotationConstantValueEntry extends PoolEntry

Should this extend LoadableConstantEntry (and restrict it more) ?

src/java.base/share/classes/jdk/internal/classfile/constantpool/ClassEntry.java line 80:

> 78:      * Return a List composed by appending the additions to the base list.
> 79:      * @param base The base elements for the list, must not include null
> 80:      * @param additions The ClassEntrys to add to the list, must not include null

Perhaps we should use `{@code}` or {@link}` to surround type names (here and elsewhere). `ClassEntrys` looks particularly odd :-)

src/java.base/share/classes/jdk/internal/classfile/constantpool/ConstantPool.java line 76:

> 74:      *              entry
> 75:      */
> 76:     BootstrapMethodEntry bootstrapMethodEntry(int index);

I note some inconsistency in naming - e.g. is `ByIndex` really needed, or a letfover to distinguish between different access modes (which are no longer there, it seems) ?

src/java.base/share/classes/jdk/internal/classfile/constantpool/ConstantPoolBuilder.java line 98:

> 96:     <T> T optionValue(Classfile.Option.Key option);
> 97: 
> 98:     boolean canWriteDirect(ConstantPool constantPool);

Missing javadoc in these two methods.

src/java.base/share/classes/jdk/internal/classfile/constantpool/ConstantPoolBuilder.java line 187:

> 185:      * {@return A {@link ModuleEntry} describing the module whose name
> 186:      * is encoded in the provided {@linkplain Utf8Entry}}
> 187:      * If a Module entry in the pool already describes this class,

(Here and elsewhere) - Module is capitalized. Either you use a lower case name, or you use a capital name, to refer to `ModuleEntry`, or `CONSTANT_Module_info` - e.g. a standalone `Module` with capital `M` is not a concept in this API. (personally I think lower case is just fine).

src/java.base/share/classes/jdk/internal/classfile/constantpool/ConstantPoolBuilder.java line 537:

> 535:      * @param <T> the type of the entry
> 536:      */
> 537:     <T extends PoolEntry> T maybeClone(T entry);

This feels a more primitive operation than the name suggests. Have you considered making ConstantPool extend Consumer<PoolEntry> and call this "accept" ?

src/java.base/share/classes/jdk/internal/classfile/constantpool/MemberRefEntry.java line 62:

> 60:      * {@return whether this member is a method}
> 61:      */
> 62:     boolean isMethod();

this seems surprising - after all we have separate types for methods/fields.

src/java.base/share/classes/jdk/internal/classfile/constantpool/MemberRefEntry.java line 67:

> 65:      * {@return whether this member is an interface method}
> 66:      */
> 67:     boolean isInterface();

I'd prefer to see this to `MethodRefEntry`. But again, there's an entry for interface methods, so not sure how much this is needed.

src/java.base/share/classes/jdk/internal/classfile/constantpool/MethodHandleEntry.java line 40:

> 38: 
> 39:     /**
> 40:      * {@return the reference kind of this method handle}

Where are the constants that can be used to decode the MH kind? Perhaps a reference from the javadoc could be helpful.

src/java.base/share/classes/jdk/internal/classfile/constantpool/PoolEntry.java line 55:

> 53:      * {@return the number of constant pool slots this entry consumes}
> 54:      */
> 55:     int poolEntries();

maybe `width` ?

src/java.base/share/classes/jdk/internal/classfile/constantpool/Utf8Entry.java line 47:

> 45:      * @param s the string to compare to
> 46:      */
> 47:     boolean equalsString(String s);

Whatif the provided string contains character that are not representable in Utf8? Should we throw (e.g. `IllegalArgumentException`) ?

-------------

PR: https://git.openjdk.org/jdk/pull/10982

From mcimadamore at openjdk.org  Thu Feb  9 14:15:11 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 9 Feb 2023 14:15:11 GMT
Subject: RFR: 8294982: Implementation of Classfile API [v15]
In-Reply-To: <hUvPqC4427nX8mcEcC5Tr90RFXAtmNigTxexY_Ujf04=.55b5e41d-afa7-4220-b13f-6fb0dd25dd0e@github.com>
References: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
 <hr8eti6ytvV05JFRr5hYLWy7yBla9mpI8vKKfaaFR-k=.a92f7bea-6400-4f95-a40c-d57192013f19@github.com>
 <hUvPqC4427nX8mcEcC5Tr90RFXAtmNigTxexY_Ujf04=.55b5e41d-afa7-4220-b13f-6fb0dd25dd0e@github.com>
Message-ID: <FsYcFKipqkTseekaQt-gHYX4NIlKc4im1XkfgyZJta4=.f3a496fc-8ec1-4f4c-b89b-449fb2c92f17@github.com>

On Thu, 9 Feb 2023 12:57:19 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   AttributeElement.Kind removal (#48)
>
> src/java.base/share/classes/jdk/internal/classfile/constantpool/ClassEntry.java line 80:
> 
>> 78:      * Return a List composed by appending the additions to the base list.
>> 79:      * @param base The base elements for the list, must not include null
>> 80:      * @param additions The ClassEntrys to add to the list, must not include null
> 
> Perhaps we should use `{@code}` or {@link}` to surround type names (here and elsewhere). `ClassEntrys` looks particularly odd :-)

It is odd to see what is essentially a list append operation in here. IMHO, these helper methods, if needed (I couldn't find uses in the JDK), should probably be added to Collections (which probably means in the jdktypes package for now) - as I don't see anything really ClassEntry/ClassDesc specific about them.

-------------

PR: https://git.openjdk.org/jdk/pull/10982

From pminborg at openjdk.org  Thu Feb  9 15:05:13 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 9 Feb 2023 15:05:13 GMT
Subject: RFR: 8301578: Perform output outside synchronization in
 Module.class [v4]
In-Reply-To: <AXAsqyTdLlz7c_RI-soi4AmkqJDG-laNLbzTVxnmbZU=.35fd56bf-abd5-4aa3-aaee-8a9f7f11eb0a@github.com>
References: <AXAsqyTdLlz7c_RI-soi4AmkqJDG-laNLbzTVxnmbZU=.35fd56bf-abd5-4aa3-aaee-8a9f7f11eb0a@github.com>
Message-ID: <uJu2J6fQYuoHiZ8-c57a1jLx82An05ZThxe3Nj_46ZA=.81c8f323-fa0e-43a9-80df-9b03ce273111@github.com>

> This PR proposed to reduce contention in synchronized methods mainly by doing I/O operations outside synch blocks.

Per Minborg has updated the pull request incrementally with one additional commit since the last revision:

  Use Unsafe instead of synchronized

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12193/files
  - new: https://git.openjdk.org/jdk/pull/12193/files/b0aeb64b..11db7d10

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12193&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12193&range=02-03

  Stats: 65 lines in 1 file changed: 18 ins; 22 del; 25 mod
  Patch: https://git.openjdk.org/jdk/pull/12193.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12193/head:pull/12193

PR: https://git.openjdk.org/jdk/pull/12193

From pminborg at openjdk.org  Thu Feb  9 15:05:30 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 9 Feb 2023 15:05:30 GMT
Subject: RFR: 8301578: Perform output outside synchronization in
 Module.class [v3]
In-Reply-To: <yUInbpslOJ5zBLati4j-6FdJcnJvcdkUcG-5eG_7Aws=.1235e39e-ae82-482a-bcbc-ae355b52af55@github.com>
References: <AXAsqyTdLlz7c_RI-soi4AmkqJDG-laNLbzTVxnmbZU=.35fd56bf-abd5-4aa3-aaee-8a9f7f11eb0a@github.com>
 <yUInbpslOJ5zBLati4j-6FdJcnJvcdkUcG-5eG_7Aws=.1235e39e-ae82-482a-bcbc-ae355b52af55@github.com>
Message-ID: <lg8xHGRhcXkseDgj4_8pPN42Zv5xMINBG4d3VEjdaqE=.c2219cc5-9efa-4708-af92-32fc618fa21c@github.com>

On Wed, 1 Feb 2023 08:51:16 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR proposed to reduce contention in synchronized methods mainly by doing I/O operations outside synch blocks.
>
> Per Minborg has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Revert benchmark change
>  - Fix typo
>  - Use another type of comment

By putting `Unsafe` in an inner class, we are able to avoid circular initializer dependencies and I have been able to rewrite  `enableNativeAccess` access so it is completely lock-free.

-------------

PR: https://git.openjdk.org/jdk/pull/12193

From mcimadamore at openjdk.org  Thu Feb  9 15:10:37 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 9 Feb 2023 15:10:37 GMT
Subject: RFR: 8294982: Implementation of Classfile API [v15]
In-Reply-To: <hr8eti6ytvV05JFRr5hYLWy7yBla9mpI8vKKfaaFR-k=.a92f7bea-6400-4f95-a40c-d57192013f19@github.com>
References: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
 <hr8eti6ytvV05JFRr5hYLWy7yBla9mpI8vKKfaaFR-k=.a92f7bea-6400-4f95-a40c-d57192013f19@github.com>
Message-ID: <scAqAuD2wQBhQdg_N1e5PPRJkmhwgCW-Mp__BajTxsw=.c73a8812-926e-4bf0-8e8f-7589a809b173@github.com>

On Thu, 9 Feb 2023 08:44:41 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> This is root pull request with Classfile API implementation, tests and benchmarks initial drop into JDK.
>> 
>> Following pull requests consolidating JDK class files parsing, generating, and transforming ([JDK-8294957](https://bugs.openjdk.org/browse/JDK-8294957)) will chain to this one.
>> 
>> Classfile API development is tracked at:
>> https://github.com/openjdk/jdk-sandbox/tree/classfile-api-branch
>> 
>> Development branch of consolidated JDK class files parsing, generating, and transforming is at:
>> https://github.com/openjdk/jdk-sandbox/tree/classfile-api-dev-branch
>> 
>> Classfile API [JEP](https://bugs.openjdk.org/browse/JDK-8280389) and [online API documentation](https://htmlpreview.github.io/?https://raw.githubusercontent.com/openjdk/jdk-sandbox/classfile-api-javadoc-branch/doc/classfile-api/javadoc/java.base/jdk/internal/classfile/package-summary.html) is also available.
>> 
>> Please take you time to review this non-trivial JDK addition.
>> 
>> Thank you,
>> Adam
>
> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
> 
>   AttributeElement.Kind removal (#48)

src/java.base/share/classes/jdk/internal/classfile/instruction/CharacterRange.java line 47:

> 45:      * {@return the start of the instruction range}
> 46:      */
> 47:     Label startScope();

I noticed that this pattern of start/endScope is here, but also in ExceptionCatch, LocalVariable and LocalVariableType. Consider using a common interface for "instructions that are associated with a range".

src/java.base/share/classes/jdk/internal/classfile/instruction/CharacterRange.java line 60:

> 58:      * viewed as an array of (possibly multi-byte) characters.
> 59:      */
> 60:     int characterRangeStart();

Not sure if this belongs here - e.g. it seems to me that `characterRangeStart` is less useful than the labels. But I'm not super expert on how this code element might be used.

src/java.base/share/classes/jdk/internal/classfile/instruction/ConstantInstruction.java line 63:

> 61:      * aload_0}).
> 62:      */
> 63:     sealed interface IntrinsicConstantInstruction extends ConstantInstruction

I'm not super sure of the fine-grained distinction here. The constant pool variant is interesting (as you can ask for the associated constant entry) - but the distinction between intrinsics vs. argument seems rather weak.

src/java.base/share/classes/jdk/internal/classfile/instruction/InvokeInstruction.java line 60:

> 58:      * {@return whether the class holding the method is an interface}
> 59:      */
> 60:     boolean isInterface();

This can also be tested with pattern matching on the MemberRefEntry?

src/java.base/share/classes/jdk/internal/classfile/instruction/MonitorInstruction.java line 48:

> 46:      *           which must be of kind {@link Opcode.Kind#MONITOR}
> 47:      */
> 48:     static MonitorInstruction of(Opcode op) {

There are only two cases here - perhaps also offer factories for monitor enter/exit? Or is creating instruction models a rare operation (e.g. because when adapting you always also have a CodeBuilder which has the user-friendly methods?)

src/java.base/share/classes/jdk/internal/classfile/instruction/TypeCheckInstruction.java line 39:

> 37: 
> 38: /**
> 39:  * Models an {@code instanceof} or {@code checkcast} instruction in the {@code

This seems to model both `instanceof` and `checkcast`. The latter seems to overlap partially with `ConvertInstruction`.

-------------

PR: https://git.openjdk.org/jdk/pull/10982

From simonis at openjdk.org  Thu Feb  9 15:27:49 2023
From: simonis at openjdk.org (Volker Simonis)
Date: Thu, 9 Feb 2023 15:27:49 GMT
Subject: RFR: 8302154: Hidden classes created by LambdaMetaFactory can't be
 unloaded
Message-ID: <YoZauVv8zvhdUw-LD25LrsMDItFbg3aXPU3deXwwFdQ=.c2839dea-12e5-4e0e-9579-eac9d8503932@github.com>

Prior to [JDK-8239384](https://bugs.openjdk.org/browse/JDK-8239384)/[JDK-8238358](https://bugs.openjdk.org/browse/JDK-8238358) LambdaMetaFactory has created VM-anonymous classes which could easily be unloaded once they were not referenced any more. Starting with JDK 15 and the new "hidden class" based implementation, this is not the case any more, because the hidden classes will be strongly tied to their defining class loader. If this is the default application class loader, these hidden classes can never be unloaded which can easily lead to Metaspace exhaustion (see the [test case in the JBS issue](https://bugs.openjdk.org/secure/attachment/102601/LambdaClassLeak.java)). This is a regression compared to previous JDK versions which some of our applications have been affected from when migrating to JDK 17.

The reason why the newly created hidden classes are strongly linked to their defining class loader is not clear to me. JDK-8239384 mentions it as an "implementation detail":

> *4. the lambda proxy class has the strong relationship with the class loader (that will share the VM metaspace for its defining loader - implementation details)*

>From my current understanding the strong link between a hidden class created by `LambdaMetaFactory` and its defining class loader is not strictly required. In order to prevent potential OOMs and fix the regression compared the JDK 14 and earlier I propose to create these hidden classes without the `STRONG` option.

I'll be happy to add the test case as JTreg test to this PR if you think that would be useful.

-------------

Commit messages:
 - 8302154: Hidden classes created by LambdaMetaFactory can't be unloaded

Changes: https://git.openjdk.org/jdk/pull/12493/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12493&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8302154
  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/12493.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12493/head:pull/12493

PR: https://git.openjdk.org/jdk/pull/12493

From alanb at openjdk.org  Thu Feb  9 15:29:22 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 9 Feb 2023 15:29:22 GMT
Subject: RFR: 8301578: Perform output outside synchronization in
 Module.class [v4]
In-Reply-To: <uJu2J6fQYuoHiZ8-c57a1jLx82An05ZThxe3Nj_46ZA=.81c8f323-fa0e-43a9-80df-9b03ce273111@github.com>
References: <AXAsqyTdLlz7c_RI-soi4AmkqJDG-laNLbzTVxnmbZU=.35fd56bf-abd5-4aa3-aaee-8a9f7f11eb0a@github.com>
 <uJu2J6fQYuoHiZ8-c57a1jLx82An05ZThxe3Nj_46ZA=.81c8f323-fa0e-43a9-80df-9b03ce273111@github.com>
Message-ID: <zoTJXUR-RPc1uoufixghmex72zYJuIkE0yee4g6EiB4=.f1dd0506-4a48-42cb-8ed3-41b134170000@github.com>

On Thu, 9 Feb 2023 15:05:13 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR proposed to reduce contention in synchronized methods mainly by doing I/O operations outside synch blocks.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use Unsafe instead of synchronized

src/java.base/share/classes/java/lang/Module.java line 120:

> 118:     // memory semantics that preserves ordering and visibility across threads.
> 119:     //
> 120:     // Used reflectively via Unsafe

I assume L119-120 can be removed.

src/java.base/share/classes/java/lang/Module.java line 132:

> 130:            ClassLoader loader,
> 131:            ModuleDescriptor descriptor,
> 132:            URI uri) {

This seems a spurious edit, not sure if you meant to change it.

src/java.base/share/classes/java/lang/Module.java line 209:

> 207:      *
> 208:      * @return The class loader for this module
> 209:      * @throws SecurityException If denied by the security manager

The exception messages are aligned under the exceptions in this class so I assume you didn't mean to change this.

src/java.base/share/classes/java/lang/Module.java line 233:

> 231:      * Returns the module layer that contains this module or {@code null} if
> 232:      * this module is not in a module layer.
> 233:      * <p>

This will break up the first paragraph, I don't think this PR should be changing that.

src/java.base/share/classes/java/lang/Module.java line 286:

> 284: 
> 285:         private static final Unsafe UNSAFE = Unsafe.getUnsafe();
> 286:         private static final long FIELD_OFFSET = UNSAFE.objectFieldOffset(Module.class, "enableNativeAccess");

Using Unsafe and CAS'ing the enableNativeAccess field looks okay.  The name "AccessHolder" looks too general here as there is a lot of access going on in this class, maybe NativeAccessHolder will work.

It would be good if you could try to keep changes to this code consistent with the existing style if possible. In this case, the other inner class uses /** .. */ style comment for the class description. I think would I put the constants at the top of the this class.

-------------

PR: https://git.openjdk.org/jdk/pull/12193

From jvernee at openjdk.org  Thu Feb  9 15:50:38 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Thu, 9 Feb 2023 15:50:38 GMT
Subject: RFR: 8302154: Hidden classes created by LambdaMetaFactory can't be
 unloaded
In-Reply-To: <YoZauVv8zvhdUw-LD25LrsMDItFbg3aXPU3deXwwFdQ=.c2839dea-12e5-4e0e-9579-eac9d8503932@github.com>
References: <YoZauVv8zvhdUw-LD25LrsMDItFbg3aXPU3deXwwFdQ=.c2839dea-12e5-4e0e-9579-eac9d8503932@github.com>
Message-ID: <Lk_jvHVjDDxNJZkJKzeIA-flc0ze6KCT9tH8Jz-y-rw=.8c408829-44f6-4e19-88a3-29f29e7d9a2a@github.com>

On Thu, 9 Feb 2023 15:20:23 GMT, Volker Simonis <simonis at openjdk.org> wrote:

> Prior to [JDK-8239384](https://bugs.openjdk.org/browse/JDK-8239384)/[JDK-8238358](https://bugs.openjdk.org/browse/JDK-8238358) LambdaMetaFactory has created VM-anonymous classes which could easily be unloaded once they were not referenced any more. Starting with JDK 15 and the new "hidden class" based implementation, this is not the case any more, because the hidden classes will be strongly tied to their defining class loader. If this is the default application class loader, these hidden classes can never be unloaded which can easily lead to Metaspace exhaustion (see the [test case in the JBS issue](https://bugs.openjdk.org/secure/attachment/102601/LambdaClassLeak.java)). This is a regression compared to previous JDK versions which some of our applications have been affected from when migrating to JDK 17.
> 
> The reason why the newly created hidden classes are strongly linked to their defining class loader is not clear to me. JDK-8239384 mentions it as an "implementation detail":
> 
>> *4. the lambda proxy class has the strong relationship with the class loader (that will share the VM metaspace for its defining loader - implementation details)*
> 
> From my current understanding the strong link between a hidden class created by `LambdaMetaFactory` and its defining class loader is not strictly required. In order to prevent potential OOMs and fix the regression compared the JDK 14 and earlier I propose to create these hidden classes without the `STRONG` option.
> 
> I'll be happy to add the test case as JTreg test to this PR if you think that would be useful.

Your analysis in the JBS issue seems reasonable, but I'll wait for Mandy to respond here.

I looked at the original PR and don't see a discussion of `STRONG` there, but I very vaguely remember it being talked about as being needed to fix a latent issue (I don't remember the details though).

src/java.base/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java line 383:

> 381:             if (useImplMethodHandle) {
> 382:                 lookup = caller.defineHiddenClassWithClassData(classBytes, implementation, !disableEagerInitialization,
> 383:                                                                NESTMATE, STRONG);

Please remove the import for this constant as well. It seems to be unused now.

-------------

PR: https://git.openjdk.org/jdk/pull/12493

From pminborg at openjdk.org  Thu Feb  9 16:30:45 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 9 Feb 2023 16:30:45 GMT
Subject: RFR: 8301578: Perform output outside synchronization in
 Module.class [v4]
In-Reply-To: <zoTJXUR-RPc1uoufixghmex72zYJuIkE0yee4g6EiB4=.f1dd0506-4a48-42cb-8ed3-41b134170000@github.com>
References: <AXAsqyTdLlz7c_RI-soi4AmkqJDG-laNLbzTVxnmbZU=.35fd56bf-abd5-4aa3-aaee-8a9f7f11eb0a@github.com>
 <uJu2J6fQYuoHiZ8-c57a1jLx82An05ZThxe3Nj_46ZA=.81c8f323-fa0e-43a9-80df-9b03ce273111@github.com>
 <zoTJXUR-RPc1uoufixghmex72zYJuIkE0yee4g6EiB4=.f1dd0506-4a48-42cb-8ed3-41b134170000@github.com>
Message-ID: <F3ShQckv90IR2CiS42Cse46y7LluSewwPPCTjhHRR-I=.e716b0e6-637b-4cb3-ae59-d4e49ac1ff96@github.com>

On Thu, 9 Feb 2023 15:19:38 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Use Unsafe instead of synchronized
>
> src/java.base/share/classes/java/lang/Module.java line 120:
> 
>> 118:     // memory semantics that preserves ordering and visibility across threads.
>> 119:     //
>> 120:     // Used reflectively via Unsafe
> 
> I assume L119-120 can be removed.

The reson for the L119-120 comments is to make it easier to understand why we are declaring a variable that does not appear to be used. But maybe there is a better way to do that?

-------------

PR: https://git.openjdk.org/jdk/pull/12193

From pminborg at openjdk.org  Thu Feb  9 16:40:15 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 9 Feb 2023 16:40:15 GMT
Subject: RFR: 8301578: Perform output outside synchronization in
 Module.class [v5]
In-Reply-To: <AXAsqyTdLlz7c_RI-soi4AmkqJDG-laNLbzTVxnmbZU=.35fd56bf-abd5-4aa3-aaee-8a9f7f11eb0a@github.com>
References: <AXAsqyTdLlz7c_RI-soi4AmkqJDG-laNLbzTVxnmbZU=.35fd56bf-abd5-4aa3-aaee-8a9f7f11eb0a@github.com>
Message-ID: <Z9NtFCseeoT60WE0GV-ITHg4QL-_flhFd0pg310yM3k=.6817a2c8-0455-4e82-b183-97c3f22ca51f@github.com>

> This PR proposed to reduce contention in synchronized methods mainly by doing I/O operations outside synch blocks.

Per Minborg has updated the pull request incrementally with two additional commits since the last revision:

 - Fix things from PR comments
 - Undo unintended changes

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12193/files
  - new: https://git.openjdk.org/jdk/pull/12193/files/11db7d10..344d47e0

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12193&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12193&range=03-04

  Stats: 16 lines in 1 file changed: 4 ins; 0 del; 12 mod
  Patch: https://git.openjdk.org/jdk/pull/12193.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12193/head:pull/12193

PR: https://git.openjdk.org/jdk/pull/12193

From pminborg at openjdk.org  Thu Feb  9 16:46:08 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 9 Feb 2023 16:46:08 GMT
Subject: RFR: 8301578: Perform output outside synchronization in
 Module.class [v6]
In-Reply-To: <AXAsqyTdLlz7c_RI-soi4AmkqJDG-laNLbzTVxnmbZU=.35fd56bf-abd5-4aa3-aaee-8a9f7f11eb0a@github.com>
References: <AXAsqyTdLlz7c_RI-soi4AmkqJDG-laNLbzTVxnmbZU=.35fd56bf-abd5-4aa3-aaee-8a9f7f11eb0a@github.com>
Message-ID: <JFnt4EFnWUDc8V39zF5a3vaKB2ywT18ir8smZ7O_XYM=.61576e58-bc97-4589-a4af-30a12213d61a@github.com>

> This PR proposed to reduce contention in synchronized methods mainly by doing I/O operations outside synch blocks.

Per Minborg has updated the pull request incrementally with one additional commit since the last revision:

  Undo more unintended edits

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12193/files
  - new: https://git.openjdk.org/jdk/pull/12193/files/344d47e0..dfa24226

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12193&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12193&range=04-05

  Stats: 4 lines in 1 file changed: 3 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/12193.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12193/head:pull/12193

PR: https://git.openjdk.org/jdk/pull/12193

From rriggs at openjdk.org  Thu Feb  9 16:57:45 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 9 Feb 2023 16:57:45 GMT
Subject: RFR: 8301737:
 java/rmi/server/UnicastRemoteObject/serialFilter/FilterUROTest.java fail with
 -Xcomp [v4]
In-Reply-To: <LCJW-DKImXCmpxwBGKJPmSKAUnz9dHg-T09tqD9-SMU=.87d63cd0-6b22-4af8-9786-bd6c75d04ca2@github.com>
References: <l5m5_9io2QMSFNY7dBHT3Nr2I9Er8wmd92Ze8FP-XE0=.a40d29be-77be-4719-a0a0-71d032eea1e5@github.com>
 <LCJW-DKImXCmpxwBGKJPmSKAUnz9dHg-T09tqD9-SMU=.87d63cd0-6b22-4af8-9786-bd6c75d04ca2@github.com>
Message-ID: <SOPGLzpZBUGbPSkPMAau9HBPyZqXmmSrMefI9to2QBs=.e12f920b-1709-47d4-bf2c-7f9000133193@github.com>

On Thu, 9 Feb 2023 08:48:17 GMT, SUN Guoyun <duke at openjdk.org> wrote:

>> Hi all,
>> When -Xcomp be used, this testcase will use more codecaches, causing the GC to be triggered early, then causing this test failed on LoongArch64 architecture.
>> 
>> This PR fix the issue, Please help review it.
>> 
>> Thanks.
>
> SUN Guoyun has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8301737: java/rmi/server/UnicastRemoteObject/serialFilter/FilterUROTest.java fail with -Xcomp

Changes requested by rriggs (Reviewer).

test/jdk/java/rmi/server/UnicastRemoteObject/serialFilter/FilterUROTest.java line 74:

> 72:     public void useExportObject(String name, Object obj, int expectedFilterCount) throws RemoteException {
> 73:         try {
> 74:             impl = RemoteImpl.create();

I'd prefer to use  ReachabilityFence at the end of the try block to keep the nested scoping.
```Reference.reachabilityFence(impl);```

-------------

PR: https://git.openjdk.org/jdk/pull/12399

From simonis at openjdk.org  Thu Feb  9 17:02:55 2023
From: simonis at openjdk.org (Volker Simonis)
Date: Thu, 9 Feb 2023 17:02:55 GMT
Subject: RFR: 8302154: Hidden classes created by LambdaMetaFactory can't be
 unloaded
In-Reply-To: <Lk_jvHVjDDxNJZkJKzeIA-flc0ze6KCT9tH8Jz-y-rw=.8c408829-44f6-4e19-88a3-29f29e7d9a2a@github.com>
References: <YoZauVv8zvhdUw-LD25LrsMDItFbg3aXPU3deXwwFdQ=.c2839dea-12e5-4e0e-9579-eac9d8503932@github.com>
 <Lk_jvHVjDDxNJZkJKzeIA-flc0ze6KCT9tH8Jz-y-rw=.8c408829-44f6-4e19-88a3-29f29e7d9a2a@github.com>
Message-ID: <ErW7tebOyvv-xTMmg2XKakKUjjFmfctfj7tDmRy92RM=.024f3f47-6783-4bb2-b005-bbde1c7a2237@github.com>

On Thu, 9 Feb 2023 15:45:35 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Prior to [JDK-8239384](https://bugs.openjdk.org/browse/JDK-8239384)/[JDK-8238358](https://bugs.openjdk.org/browse/JDK-8238358) LambdaMetaFactory has created VM-anonymous classes which could easily be unloaded once they were not referenced any more. Starting with JDK 15 and the new "hidden class" based implementation, this is not the case any more, because the hidden classes will be strongly tied to their defining class loader. If this is the default application class loader, these hidden classes can never be unloaded which can easily lead to Metaspace exhaustion (see the [test case in the JBS issue](https://bugs.openjdk.org/secure/attachment/102601/LambdaClassLeak.java)). This is a regression compared to previous JDK versions which some of our applications have been affected from when migrating to JDK 17.
>> 
>> The reason why the newly created hidden classes are strongly linked to their defining class loader is not clear to me. JDK-8239384 mentions it as an "implementation detail":
>> 
>>> *4. the lambda proxy class has the strong relationship with the class loader (that will share the VM metaspace for its defining loader - implementation details)*
>> 
>> From my current understanding the strong link between a hidden class created by `LambdaMetaFactory` and its defining class loader is not strictly required. In order to prevent potential OOMs and fix the regression compared the JDK 14 and earlier I propose to create these hidden classes without the `STRONG` option.
>> 
>> I'll be happy to add the test case as JTreg test to this PR if you think that would be useful.
>
> src/java.base/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java line 383:
> 
>> 381:             if (useImplMethodHandle) {
>> 382:                 lookup = caller.defineHiddenClassWithClassData(classBytes, implementation, !disableEagerInitialization,
>> 383:                                                                NESTMATE, STRONG);
> 
> Please remove the import for this constant as well. It seems to be unused now.

Will do (and will updated the copyright year as well :)

-------------

PR: https://git.openjdk.org/jdk/pull/12493

From simonis at openjdk.org  Thu Feb  9 17:06:50 2023
From: simonis at openjdk.org (Volker Simonis)
Date: Thu, 9 Feb 2023 17:06:50 GMT
Subject: RFR: 8302154: Hidden classes created by LambdaMetaFactory can't be
 unloaded
In-Reply-To: <Lk_jvHVjDDxNJZkJKzeIA-flc0ze6KCT9tH8Jz-y-rw=.8c408829-44f6-4e19-88a3-29f29e7d9a2a@github.com>
References: <YoZauVv8zvhdUw-LD25LrsMDItFbg3aXPU3deXwwFdQ=.c2839dea-12e5-4e0e-9579-eac9d8503932@github.com>
 <Lk_jvHVjDDxNJZkJKzeIA-flc0ze6KCT9tH8Jz-y-rw=.8c408829-44f6-4e19-88a3-29f29e7d9a2a@github.com>
Message-ID: <uNoNuGEMx_T5NeE5-EsWxNU4Vt1crHZFHaiH-FDanBM=.364a2a1e-8d16-4b1b-85b5-0337fdf01489@github.com>

On Thu, 9 Feb 2023 15:47:31 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

> Your analysis in the JBS issue seems reasonable, but I'll wait for Mandy to respond here.
> 
> I looked at the original PR and don't see a discussion of `STRONG` there, but I very vaguely remember it being talked about as being needed to fix a latent issue (I don't remember the details though).

Hi Jorn,

thanks for your quick response. I'd definitely want to hear Mandy's opinion on this as well :)

It also looks like the debug builds are running into an assertion during archiving. Currently looking into that as well...

-------------

PR: https://git.openjdk.org/jdk/pull/12493

From asotona at openjdk.org  Thu Feb  9 17:21:01 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Thu, 9 Feb 2023 17:21:01 GMT
Subject: RFR: 8294982: Implementation of Classfile API [v12]
In-Reply-To: <WWAU3RkvjyiU0BobfO36OiaiYdtGdybXshpWKHc5AIg=.aacaf93c-95ab-433e-82a0-d6d62d92acc1@github.com>
References: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
 <Q4VeZ2yWAg85FqUDJa5hYq3jHty5H547gD0H-x3oIq0=.58d463a4-237a-4fee-bd0f-83262d49522a@github.com>
 <c022hrWNEHW76nhP_sXTQXCTjtL8jjM8r_yYv0IvbPI=.2a9cfbae-2fef-4cdb-8189-b869b1513fef@github.com>
 <rzZgV5Ffapr1PM-e0qssZQwGCRGpcP9jv3Ua4aUY-TQ=.2540b2e9-cc38-4dfc-9f24-a31bb1b242e9@github.com>
 <WWAU3RkvjyiU0BobfO36OiaiYdtGdybXshpWKHc5AIg=.aacaf93c-95ab-433e-82a0-d6d62d92acc1@github.com>
Message-ID: <5B3FXXL7MPnEnBSe3bwnW9muJJonF4Q6F16SlstP1Sc=.801dccb6-2a93-4f47-bc02-58d8f2d6aa26@github.com>

On Tue, 7 Feb 2023 11:48:52 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Yes, performance is the main reason.
>> I'll note to do a fresh differential performance benchmarks with a HashMap.
>
> thanks

I tried HashMap with String keys and it cause performance regressions, however with Utf8Entry initialized with raw Attribute name as the HashMap key - there are no performance regressions.
I'm going to push a patch removing all the manually computed HASH_ values and fragile inlined HashMap implementation.

-------------

PR: https://git.openjdk.org/jdk/pull/10982

From duke at openjdk.org  Thu Feb  9 17:29:05 2023
From: duke at openjdk.org (Scott Gibbons)
Date: Thu, 9 Feb 2023 17:29:05 GMT
Subject: RFR: JDK-8300808: Accelerate Base64 on x86 for AVX2 [v14]
In-Reply-To: <9zN3bjyMEikXYOlpjTy9_QPc-9usYiBJMUFdb-TaVrQ=.e8f65ce9-ac0f-4f8d-9c6b-b39ae1c26cd2@github.com>
References: <9zN3bjyMEikXYOlpjTy9_QPc-9usYiBJMUFdb-TaVrQ=.e8f65ce9-ac0f-4f8d-9c6b-b39ae1c26cd2@github.com>
Message-ID: <39P258Jz047UViDIsbxOSfuWNeQqkz_d3hywAObylWc=.33deebd9-d760-4ba8-8a0d-2f59f260e4bc@github.com>

> Added code for Base64 acceleration (encode and decode) which will accelerate ~4x for AVX2 platforms.
> 
> Encode performance:
> **Old:**
> 
> Benchmark                      (maxNumBytes)   Mode  Cnt     Score   Error   Units
> Base64Encode.testBase64Encode           1024  thrpt    3  4309.439 ? 2.632  ops/ms
> 
> 
> **New:**
> 
> Benchmark                      (maxNumBytes)   Mode  Cnt      Score     Error   Units
> Base64Encode.testBase64Encode           1024  thrpt    3  24211.397 ? 102.026  ops/ms
> 
> 
> Decode performance:
> **Old:**
> 
> Benchmark                      (errorIndex)  (lineSize)  (maxNumBytes)   Mode  Cnt     Score    Error   Units
> Base64Decode.testBase64Decode           144           4           1024  thrpt    3  3961.768 ? 93.409  ops/ms
> 
> **New:**
> Benchmark                      (errorIndex)  (lineSize)  (maxNumBytes)   Mode  Cnt      Score    Error   Units
> Base64Decode.testBase64Decode           144           4           1024  thrpt    3  14738.051 ? 24.383  ops/ms

Scott Gibbons has updated the pull request incrementally with one additional commit since the last revision:

  Re-name tables; save some space

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12126/files
  - new: https://git.openjdk.org/jdk/pull/12126/files/d174c43f..cc1bce1e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12126&range=13
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12126&range=12-13

  Stats: 52 lines in 4 files changed: 13 ins; 19 del; 20 mod
  Patch: https://git.openjdk.org/jdk/pull/12126.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12126/head:pull/12126

PR: https://git.openjdk.org/jdk/pull/12126

From asotona at openjdk.org  Thu Feb  9 17:44:29 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Thu, 9 Feb 2023 17:44:29 GMT
Subject: RFR: 8294982: Implementation of Classfile API [v16]
In-Reply-To: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
References: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
Message-ID: <pzLTfi1vjNq5DFqWIMCY-G_TjdjH6Cj23vdgRg6WNY8=.9f57283e-7869-4066-bd20-b780af8e2d34@github.com>

> This is root pull request with Classfile API implementation, tests and benchmarks initial drop into JDK.
> 
> Following pull requests consolidating JDK class files parsing, generating, and transforming ([JDK-8294957](https://bugs.openjdk.org/browse/JDK-8294957)) will chain to this one.
> 
> Classfile API development is tracked at:
> https://github.com/openjdk/jdk-sandbox/tree/classfile-api-branch
> 
> Development branch of consolidated JDK class files parsing, generating, and transforming is at:
> https://github.com/openjdk/jdk-sandbox/tree/classfile-api-dev-branch
> 
> Classfile API [JEP](https://bugs.openjdk.org/browse/JDK-8280389) and [online API documentation](https://htmlpreview.github.io/?https://raw.githubusercontent.com/openjdk/jdk-sandbox/classfile-api-javadoc-branch/doc/classfile-api/javadoc/java.base/jdk/internal/classfile/package-summary.html) is also available.
> 
> Please take you time to review this non-trivial JDK addition.
> 
> Thank you,
> Adam

Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:

  Proprietary hash-based mapping in Attributes replaced with HashMap using raw Utf8Entry keys

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10982/files
  - new: https://git.openjdk.org/jdk/pull/10982/files/753e6847..ec6829e9

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10982&range=15
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10982&range=14-15

  Stats: 221 lines in 3 files changed: 27 ins; 158 del; 36 mod
  Patch: https://git.openjdk.org/jdk/pull/10982.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10982/head:pull/10982

PR: https://git.openjdk.org/jdk/pull/10982

From mchung at openjdk.org  Thu Feb  9 17:44:48 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Thu, 9 Feb 2023 17:44:48 GMT
Subject: RFR: 8302154: Hidden classes created by LambdaMetaFactory can't be
 unloaded
In-Reply-To: <YoZauVv8zvhdUw-LD25LrsMDItFbg3aXPU3deXwwFdQ=.c2839dea-12e5-4e0e-9579-eac9d8503932@github.com>
References: <YoZauVv8zvhdUw-LD25LrsMDItFbg3aXPU3deXwwFdQ=.c2839dea-12e5-4e0e-9579-eac9d8503932@github.com>
Message-ID: <5fF-1uaUh_LuoXYQLj7ocAGtgFM-yVs8SvXn2yu_h98=.56156ebf-07e8-45db-b278-aba06690fd77@github.com>

On Thu, 9 Feb 2023 15:20:23 GMT, Volker Simonis <simonis at openjdk.org> wrote:

> 4. the lambda proxy class has the strong relationship with the class loader (that will share the VM metaspace for its defining loader - implementation details)

A lambda proxy class is the implementation of the lambda/method reference in class `C` and it's logical part of class `C` and therefore it has a strong relationship with the class loader.

The VM implementation creates one `ClassLoaderData` in the metaspace space for each "weak" hidden class, i.e. it consumes more C heap memory.  If a hidden class has a strong relationship with its defining loader, it should keep it strong.

-------------

PR: https://git.openjdk.org/jdk/pull/12493

From mchung at openjdk.org  Thu Feb  9 18:06:50 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Thu, 9 Feb 2023 18:06:50 GMT
Subject: RFR: 8302154: Hidden classes created by LambdaMetaFactory can't be
 unloaded
In-Reply-To: <YoZauVv8zvhdUw-LD25LrsMDItFbg3aXPU3deXwwFdQ=.c2839dea-12e5-4e0e-9579-eac9d8503932@github.com>
References: <YoZauVv8zvhdUw-LD25LrsMDItFbg3aXPU3deXwwFdQ=.c2839dea-12e5-4e0e-9579-eac9d8503932@github.com>
Message-ID: <qFGPOZDaVdukyOOedwjA1t-Kk-7qUf9uELNYW-ZB_Lw=.a083b2c7-aad5-4957-bbb1-56337137fc7c@github.com>

On Thu, 9 Feb 2023 15:20:23 GMT, Volker Simonis <simonis at openjdk.org> wrote:

> Prior to [JDK-8239384](https://bugs.openjdk.org/browse/JDK-8239384)/[JDK-8238358](https://bugs.openjdk.org/browse/JDK-8238358) LambdaMetaFactory has created VM-anonymous classes which could easily be unloaded once they were not referenced any more. Starting with JDK 15 and the new "hidden class" based implementation, this is not the case any more, because the hidden classes will be strongly tied to their defining class loader. If this is the default application class loader, these hidden classes can never be unloaded which can easily lead to Metaspace exhaustion (see the [test case in the JBS issue](https://bugs.openjdk.org/secure/attachment/102601/LambdaClassLeak.java)). This is a regression compared to previous JDK versions which some of our applications have been affected from when migrating to JDK 17.
> 
> The reason why the newly created hidden classes are strongly linked to their defining class loader is not clear to me. JDK-8239384 mentions it as an "implementation detail":
> 
>> *4. the lambda proxy class has the strong relationship with the class loader (that will share the VM metaspace for its defining loader - implementation details)*
> 
> From my current understanding the strong link between a hidden class created by `LambdaMetaFactory` and its defining class loader is not strictly required. In order to prevent potential OOMs and fix the regression compared the JDK 14 and earlier I propose to create these hidden classes without the `STRONG` option.
> 
> I'll be happy to add the test case as JTreg test to this PR if you think that would be useful.

I need to look into this closer.  

The other part related the implementation is about `invokedynamic`  and `cpCache` reference that I'm consulting with @coleenp to determine if the lambda proxy classes should be kept weak.

-------------

PR: https://git.openjdk.org/jdk/pull/12493

From duke at openjdk.org  Thu Feb  9 18:08:15 2023
From: duke at openjdk.org (Scott Gibbons)
Date: Thu, 9 Feb 2023 18:08:15 GMT
Subject: RFR: JDK-8300808: Accelerate Base64 on x86 for AVX2 [v15]
In-Reply-To: <9zN3bjyMEikXYOlpjTy9_QPc-9usYiBJMUFdb-TaVrQ=.e8f65ce9-ac0f-4f8d-9c6b-b39ae1c26cd2@github.com>
References: <9zN3bjyMEikXYOlpjTy9_QPc-9usYiBJMUFdb-TaVrQ=.e8f65ce9-ac0f-4f8d-9c6b-b39ae1c26cd2@github.com>
Message-ID: <TmYLe9RCiAqtfuyjU77R-faEEVpfmmUoQ89oyBCcEmM=.c6d2d68b-c37d-4c78-a8e4-af4b48df91a5@github.com>

> Added code for Base64 acceleration (encode and decode) which will accelerate ~4x for AVX2 platforms.
> 
> Encode performance:
> **Old:**
> 
> Benchmark                      (maxNumBytes)   Mode  Cnt     Score   Error   Units
> Base64Encode.testBase64Encode           1024  thrpt    3  4309.439 ? 2.632  ops/ms
> 
> 
> **New:**
> 
> Benchmark                      (maxNumBytes)   Mode  Cnt      Score     Error   Units
> Base64Encode.testBase64Encode           1024  thrpt    3  24211.397 ? 102.026  ops/ms
> 
> 
> Decode performance:
> **Old:**
> 
> Benchmark                      (errorIndex)  (lineSize)  (maxNumBytes)   Mode  Cnt     Score    Error   Units
> Base64Decode.testBase64Decode           144           4           1024  thrpt    3  3961.768 ? 93.409  ops/ms
> 
> **New:**
> Benchmark                      (errorIndex)  (lineSize)  (maxNumBytes)   Mode  Cnt      Score    Error   Units
> Base64Decode.testBase64Decode           144           4           1024  thrpt    3  14738.051 ? 24.383  ops/ms

Scott Gibbons has updated the pull request incrementally with one additional commit since the last revision:

  Add URL to microbenchmark

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12126/files
  - new: https://git.openjdk.org/jdk/pull/12126/files/cc1bce1e..424b40d7

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12126&range=14
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12126&range=13-14

  Stats: 38 lines in 1 file changed: 33 ins; 1 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/12126.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12126/head:pull/12126

PR: https://git.openjdk.org/jdk/pull/12126

From simonis at openjdk.org  Thu Feb  9 18:11:18 2023
From: simonis at openjdk.org (Volker Simonis)
Date: Thu, 9 Feb 2023 18:11:18 GMT
Subject: RFR: 8302154: Hidden classes created by LambdaMetaFactory can't be
 unloaded [v2]
In-Reply-To: <YoZauVv8zvhdUw-LD25LrsMDItFbg3aXPU3deXwwFdQ=.c2839dea-12e5-4e0e-9579-eac9d8503932@github.com>
References: <YoZauVv8zvhdUw-LD25LrsMDItFbg3aXPU3deXwwFdQ=.c2839dea-12e5-4e0e-9579-eac9d8503932@github.com>
Message-ID: <gKoLpwlXDxp2uaSKSkMArJl1Ym9VX1hoDFqQTTUpk8w=.e1dce669-5a42-4b66-ac4b-205718c8eb81@github.com>

> Prior to [JDK-8239384](https://bugs.openjdk.org/browse/JDK-8239384)/[JDK-8238358](https://bugs.openjdk.org/browse/JDK-8238358) LambdaMetaFactory has created VM-anonymous classes which could easily be unloaded once they were not referenced any more. Starting with JDK 15 and the new "hidden class" based implementation, this is not the case any more, because the hidden classes will be strongly tied to their defining class loader. If this is the default application class loader, these hidden classes can never be unloaded which can easily lead to Metaspace exhaustion (see the [test case in the JBS issue](https://bugs.openjdk.org/secure/attachment/102601/LambdaClassLeak.java)). This is a regression compared to previous JDK versions which some of our applications have been affected from when migrating to JDK 17.
> 
> The reason why the newly created hidden classes are strongly linked to their defining class loader is not clear to me. JDK-8239384 mentions it as an "implementation detail":
> 
>> *4. the lambda proxy class has the strong relationship with the class loader (that will share the VM metaspace for its defining loader - implementation details)*
> 
> From my current understanding the strong link between a hidden class created by `LambdaMetaFactory` and its defining class loader is not strictly required. In order to prevent potential OOMs and fix the regression compared the JDK 14 and earlier I propose to create these hidden classes without the `STRONG` option.
> 
> I'll be happy to add the test case as JTreg test to this PR if you think that would be useful.

Volker Simonis has updated the pull request incrementally with two additional commits since the last revision:

 - Remove assertions which insist on Lambda proxy classes being strongly linked to their class loader
 - Removed unused import of STRONG und updated copyright year

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12493/files
  - new: https://git.openjdk.org/jdk/pull/12493/files/6814268a..7b2cc3eb

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12493&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12493&range=00-01

  Stats: 5 lines in 3 files changed: 0 ins; 3 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/12493.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12493/head:pull/12493

PR: https://git.openjdk.org/jdk/pull/12493

From asotona at openjdk.org  Thu Feb  9 18:35:50 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Thu, 9 Feb 2023 18:35:50 GMT
Subject: RFR: 8294961: java.base java.lang.reflect.ProxyGenerator uses ASM
 to generate proxy classes [v2]
In-Reply-To: <sSGmswappyrpfAAIJsyfQ_zjusccyLc3mzXWYjp596M=.08e13292-d0de-46f4-9fa5-e398f0838fb9@github.com>
References: <rqqi61cKbJ8TjDVSzsjh6BVXjF1ZxL2ZFHheuXzL5E8=.bd1f1a2c-6f35-4180-a0a5-8a6e3cb93e75@github.com>
 <pllZmQlszffAmAiq-P45e6FyZkNbRTp1VbIbUe29xo8=.449d0bfc-a712-484a-8aee-0140a054b2d6@github.com>
 <sSGmswappyrpfAAIJsyfQ_zjusccyLc3mzXWYjp596M=.08e13292-d0de-46f4-9fa5-e398f0838fb9@github.com>
Message-ID: <5GCG0mPZYECOhlNaMb8yTCfC3b90ilTPd89cqdGH3Pw=.3987e2b5-cd33-45e7-9556-282fc0cfb01b@github.com>

On Wed, 8 Feb 2023 00:38:23 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> 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 four additional commits since the last revision:
>> 
>>  - j.l.r.ProxyGenerator fix - Classfile API moved under jdk.internal.classfile package
>>  - Merge branch 'JDK-8294982' into JDK-8294961
>>  - Merge branch 'JDK-8294982' into JDK-8294961
>>  - 8294961: java.base java.lang.reflect.ProxyGenerator uses ASM to generate proxy classes
>
> This looks good in general.   I like this, easy to use, easy to read and understand and greatly simplified.
> 
> Reviewing this is one easy way to study the ClassFile API.

@mlchung Thanks for the review and for the patch provided, I've applied it and going to push.
Thanks!

-------------

PR: https://git.openjdk.org/jdk/pull/10991

From asotona at openjdk.org  Thu Feb  9 18:48:19 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Thu, 9 Feb 2023 18:48:19 GMT
Subject: RFR: 8294961: java.base java.lang.reflect.ProxyGenerator uses ASM
 to generate proxy classes [v3]
In-Reply-To: <rqqi61cKbJ8TjDVSzsjh6BVXjF1ZxL2ZFHheuXzL5E8=.bd1f1a2c-6f35-4180-a0a5-8a6e3cb93e75@github.com>
References: <rqqi61cKbJ8TjDVSzsjh6BVXjF1ZxL2ZFHheuXzL5E8=.bd1f1a2c-6f35-4180-a0a5-8a6e3cb93e75@github.com>
Message-ID: <6MQUzvBb7NdEBp2zu0FjIRVWNYw9INz7yXbqAAZU-vo=.c6a832a8-248f-4c5b-a36e-8b18f6c5a0b7@github.com>

> java.base java.lang.reflect.ProxyGenerator uses ASM to generate proxy classes and this patch converts it to use Classfile API.
> 
> This pull request suppose to chain on the 8294982: Implementation of Classfile API https://github.com/openjdk/jdk/pull/10982
> 
> 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 six additional commits since the last revision:

 - j.l.r.ProxyGenerator improvements
   Author: Mandy Chung <mchung at openjdk.org>
 - Merge branch 'JDK-8294982' into JDK-8294961
 - j.l.r.ProxyGenerator fix - Classfile API moved under jdk.internal.classfile package
 - Merge branch 'JDK-8294982' into JDK-8294961
 - Merge branch 'JDK-8294982' into JDK-8294961
 - 8294961: java.base java.lang.reflect.ProxyGenerator uses ASM to generate proxy classes

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10991/files
  - new: https://git.openjdk.org/jdk/pull/10991/files/c242a4a2..9d671a04

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10991&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10991&range=01-02

  Stats: 499 lines in 65 files changed: 51 ins; 258 del; 190 mod
  Patch: https://git.openjdk.org/jdk/pull/10991.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10991/head:pull/10991

PR: https://git.openjdk.org/jdk/pull/10991

From asotona at openjdk.org  Thu Feb  9 18:48:22 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Thu, 9 Feb 2023 18:48:22 GMT
Subject: RFR: 8294961: java.base java.lang.reflect.ProxyGenerator uses ASM
 to generate proxy classes [v2]
In-Reply-To: <sSGmswappyrpfAAIJsyfQ_zjusccyLc3mzXWYjp596M=.08e13292-d0de-46f4-9fa5-e398f0838fb9@github.com>
References: <rqqi61cKbJ8TjDVSzsjh6BVXjF1ZxL2ZFHheuXzL5E8=.bd1f1a2c-6f35-4180-a0a5-8a6e3cb93e75@github.com>
 <pllZmQlszffAmAiq-P45e6FyZkNbRTp1VbIbUe29xo8=.449d0bfc-a712-484a-8aee-0140a054b2d6@github.com>
 <sSGmswappyrpfAAIJsyfQ_zjusccyLc3mzXWYjp596M=.08e13292-d0de-46f4-9fa5-e398f0838fb9@github.com>
Message-ID: <xtJk4stDaK9OGHRVmoMojppQoejVR4Ob3Dacp_AygIo=.9493b241-a627-4c60-940f-83753630edaf@github.com>

On Wed, 8 Feb 2023 00:37:57 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> 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 four additional commits since the last revision:
>> 
>>  - j.l.r.ProxyGenerator fix - Classfile API moved under jdk.internal.classfile package
>>  - Merge branch 'JDK-8294982' into JDK-8294961
>>  - Merge branch 'JDK-8294982' into JDK-8294961
>>  - 8294961: java.base java.lang.reflect.ProxyGenerator uses ASM to generate proxy classes
>
> src/java.base/share/classes/java/lang/reflect/ProxyGenerator.java line 423:
> 
>> 421:     private byte[] generateClassFile() {
>> 422:         var localCache = new HashMap<ClassDesc, ClassHierarchyResolver.ClassHierarchyInfo>();
>> 423:         return Classfile.build(classDesc, List.of(Classfile.Option.classHierarchyResolver(classDesc ->
> 
> How/when is `ClassHierarchyResolver` being called?   I didn't dig deeper.

`ClassHierarchyResolver` is used for stack maps generation in situations when it is not clear if the given type is class or interface and to resolve class hierarchy (parent - child relations and common parent).
Classfile API is not using class loaders by default (In contrast to ASM library) and there are alternative ways how to provide required info. However in this situation is class hierarchy resolution asking provided class loader.

-------------

PR: https://git.openjdk.org/jdk/pull/10991

From dholmes at openjdk.org  Thu Feb  9 22:13:51 2023
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 9 Feb 2023 22:13:51 GMT
Subject: RFR: 8300139 : [AIX] Use pthreads to avoid JNI_createVM call from
 primordial thread [v2]
In-Reply-To: <-t5m5emOq8DlWCsigyaoovNvFq7hMVbFM-oD5TG5_uU=.55cede30-8ac6-46c1-96e8-b0f64052ccd9@github.com>
References: <qbwPBNdxzk4QmB9L6y2t-X6uYgAaPjzAEwYfs_5XV_0=.4ea982e6-30da-4219-b8ad-fa36690170b8@github.com>
 <vu7c9WHMcCXtkghiBjXUnP3KUy6Xyh7lP7McKSnlJcY=.2e4bdce8-d4e3-4dd1-9fc3-1a27f089dd6f@github.com>
 <EytMoEECi74JuG2MD6i79mz-m2o45-C5wB1PxkoKweU=.3335308c-0147-43df-8821-7b08c3aa11f8@github.com>
 <-t5m5emOq8DlWCsigyaoovNvFq7hMVbFM-oD5TG5_uU=.55cede30-8ac6-46c1-96e8-b0f64052ccd9@github.com>
Message-ID: <ADdToS6Kc9W6qyOc54IpIHoDoIO93YO_oEHFubQeePs=.41a23ecd-e836-459b-a630-bc6b7728a0e5@github.com>

On Thu, 9 Feb 2023 11:03:44 GMT, Varada M <duke at openjdk.org> wrote:

> These tests is passing without adding lpthread in JtregNativeHotspot.gmk. Do I need to update the makefile?

I'm somewhat surprised that the tests pass without explicit linkage, but perhaps libpthread is a default on AIX. If things are working in your AIX testing then that is fine.

-------------

PR: https://git.openjdk.org/jdk/pull/12302

From lancea at openjdk.org  Thu Feb  9 22:14:43 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Thu, 9 Feb 2023 22:14:43 GMT
Subject: RFR: 8301269: Update Commons BCEL to Version 6.7.0
In-Reply-To: <0RNjHfl4qXA0zwLZz10RDxolN96AdrScP27KS1bsT6A=.74cd0696-d037-405d-97eb-be3cbf1e849b@github.com>
References: <0RNjHfl4qXA0zwLZz10RDxolN96AdrScP27KS1bsT6A=.74cd0696-d037-405d-97eb-be3cbf1e849b@github.com>
Message-ID: <9I0UloJeazJK65Y65Aixf3_AF3uUeaQnweP6LbClITM=.d16b0f57-e8a8-4cec-b6a0-8cce6d523d26@github.com>

On Wed, 8 Feb 2023 00:15:27 GMT, Joe Wang <joehw at openjdk.org> wrote:

> Update Commons BCEL in the JDK from 6.5.0 to 6.7.0. 
> 
> 1. Improvement
>    Code modernization (using relatively more modern language features), normalization (such as naming), javadocs, cleanup and minor improvements made up most of the changes. These changes do not change how BCEL works for the XSLT function in the JDK. Many of the changes unfortunately created long lines, for example merging multiple lines into a single long line, not what we would like to have in the JDK, but I have to leave them as they are so that they don't show up as changes in future updates. 
> 
> 2. Exclusions
>    As it has always been, the focus of the BCEL component is to satisfy the needs for the XSLT functionality. Classes not needed for the JDK are excluded as it has been done previously, this is especially true in the util package. The verifier package is also excluded. Methods and sources that have dependencies on the excluded classes are either removed or modified.
> 
> 3. Deprecation and Warnings
>    
>    Deprecated classes and contents relying on them are removed or modified to use proper methods without changing the functionality. Deprecated fields in the original source were changed to private ones in previous update in the JDK, however, since the update process applies sources from the upstream again, they were reverted back. In order to not have to go through them on every update, I'll keep the original source this time. 
> 
>     Warnings were one of the main reasons for the changes made to the original source. It has been done in the previous update. In this update, many of the previous JDK fixes on warnings have already been addressed in the upstream source as the result of item 1, thus lessoned the needs to reapply the warning patches. Fixed the rest of warnings as they showed up during build.
> 
> 4. Note that JRocket specific patches are not in the current code base.
> 
> 5. Test
>     Tier2 tests passed.
>     JCK XML tests passed.

Hi Joe,

This looks good to me based on my pass through

-------------

Marked as reviewed by lancea (Reviewer).

PR: https://git.openjdk.org/jdk/pull/12464

From duke at openjdk.org  Thu Feb  9 22:18:47 2023
From: duke at openjdk.org (Scott Gibbons)
Date: Thu, 9 Feb 2023 22:18:47 GMT
Subject: RFR: JDK-8300808: Accelerate Base64 on x86 for AVX2 [v15]
In-Reply-To: <TmYLe9RCiAqtfuyjU77R-faEEVpfmmUoQ89oyBCcEmM=.c6d2d68b-c37d-4c78-a8e4-af4b48df91a5@github.com>
References: <9zN3bjyMEikXYOlpjTy9_QPc-9usYiBJMUFdb-TaVrQ=.e8f65ce9-ac0f-4f8d-9c6b-b39ae1c26cd2@github.com>
 <TmYLe9RCiAqtfuyjU77R-faEEVpfmmUoQ89oyBCcEmM=.c6d2d68b-c37d-4c78-a8e4-af4b48df91a5@github.com>
Message-ID: <4lZwMmKcs_TZPuWDJya9RPHxq72TaOd5VPrgM-4JjFI=.de1df5bc-e73e-4b31-be0c-a0f80ed8c874@github.com>

On Thu, 9 Feb 2023 18:08:15 GMT, Scott Gibbons <duke at openjdk.org> wrote:

>> Added code for Base64 acceleration (encode and decode) which will accelerate ~4x for AVX2 platforms.
>> 
>> Encode performance:
>> **Old:**
>> 
>> Benchmark                      (maxNumBytes)   Mode  Cnt     Score   Error   Units
>> Base64Encode.testBase64Encode           1024  thrpt    3  4309.439 ? 2.632  ops/ms
>> 
>> 
>> **New:**
>> 
>> Benchmark                      (maxNumBytes)   Mode  Cnt      Score     Error   Units
>> Base64Encode.testBase64Encode           1024  thrpt    3  24211.397 ? 102.026  ops/ms
>> 
>> 
>> Decode performance:
>> **Old:**
>> 
>> Benchmark                      (errorIndex)  (lineSize)  (maxNumBytes)   Mode  Cnt     Score    Error   Units
>> Base64Decode.testBase64Decode           144           4           1024  thrpt    3  3961.768 ? 93.409  ops/ms
>> 
>> **New:**
>> Benchmark                      (errorIndex)  (lineSize)  (maxNumBytes)   Mode  Cnt      Score    Error   Units
>> Base64Decode.testBase64Decode           144           4           1024  thrpt    3  14738.051 ? 24.383  ops/ms
>
> Scott Gibbons has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add URL to microbenchmark

@cl4es @sviswa7 @jatin-bhateja I believe I've addressed all of your concerns - thank you all for the reviews.  Please review when you can.  Thanks!

-------------

PR: https://git.openjdk.org/jdk/pull/12126

From psandoz at openjdk.org  Thu Feb  9 23:17:46 2023
From: psandoz at openjdk.org (Paul Sandoz)
Date: Thu, 9 Feb 2023 23:17:46 GMT
Subject: RFR: 8293198: [vectorapi] Improve the implementation of
 VectorMask.indexInRange() [v3]
In-Reply-To: <LkFyD4yv4dzpVbmsZEINxFyqWLrBFYDXoXFVcyBVR2g=.e333fbd3-6c4c-43f7-860b-136bf247488a@github.com>
References: <fN58bi3n01tqWpG0-jjUPZQe8hmls2GQ5X3NL2o1RPg=.80e7965d-50af-4fac-bd7c-0a2b99cffe7e@github.com>
 <LkFyD4yv4dzpVbmsZEINxFyqWLrBFYDXoXFVcyBVR2g=.e333fbd3-6c4c-43f7-860b-136bf247488a@github.com>
Message-ID: <-7PQS73PHFuI2hrnxFuMGU2jbUBOYVsUS51JQwXCddQ=.d3c0b385-9bda-4f31-b22c-e5bfa1f9aeda@github.com>

On Tue, 7 Feb 2023 09:51:19 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

>> The Vector API `"indexInRange(int offset, int limit)"` is used
>> to compute a vector mask whose lanes are set to true if the
>> index of the lane is inside the range specified by the `"offset"`
>> and `"limit"` arguments, otherwise the lanes are set to false.
>> 
>> There are two special cases for this API:
>>  1) If `"offset >= 0 && offset >= limit"`, all the lanes of the
>> generated mask are false.
>>  2) If` "offset >= 0 && limit - offset >= vlength"`, all the
>> lanes of the generated mask are true. Note that `"vlength"` is
>> the number of vector lanes.
>> 
>> For such special cases, we can simply use `"maskAll(false|true)"`
>> to implement the API. Otherwise, the original comparison with
>> `"iota" `vector is needed. And for further optimization, we have
>> optimal instruction supported by SVE (i.e. whilelo [1]), which
>> can implement the API directly if the `"offset >= 0"`.
>> 
>> As a summary, to optimize the API, we can use the if-else branches
>> to handle the specific cases in java level and intrinsify the
>> remaining case by C2 compiler:
>> 
>> 
>>   public VectorMask<E> indexInRange(int offset, int limit) {
>>       if (offset < 0) {
>>           return this.and(indexInRange0Helper(offset, limit));
>>       } else if (offset >= limit) {
>>           return this.and(vectorSpecies().maskAll(false));
>>       } else if (limit - offset >= length()) {
>>           return this.and(vectorSpecies().maskAll(true));
>>       }
>>       return this.and(indexInRange0(offset, limit));
>>  }
>> 
>> 
>> The last part (i.e. `"indexInRange0"`) in the above implementation
>> is expected to be intrinsified by C2 compiler if the necessary IRs
>> are supported. Otherwise, it will fall back to the original API
>> implementation (i.e. `"indexInRange0Helper"`). Regarding to the
>> intrinsifaction, the compiler will generate `"VectorMaskGen"` IR
>> with "limit - offset" as the input if the current platform supports
>> it. Otherwise, it generates `"VectorLoadConst + VectorMaskCmp"` based
>> on `"iota < limit - offset"`.
>> 
>> For the following java code which uses `"indexInRange"`:
>> 
>> 
>> static final VectorSpecies<Double> SPECIES =
>>                                    DoubleVector.SPECIES_PREFERRED;
>> static final int LENGTH = 1027;
>> 
>> public static double[] da;
>> public static double[] db;
>> public static double[] dc;
>> 
>> private static void func() {
>>     for (int i = 0; i < LENGTH; i += SPECIES.length()) {
>>         var m = SPECIES.indexInRange(i, LENGTH);
>>         var av = DoubleVector.fromArray(SPECIES, da, i, m);
>>         av.lanewise(VectorOperators.NEG).intoArray(dc, i, m);
>>     }
>> }
>> 
>> 
>> The core code generated with SVE 256-bit vector size is:
>> 
>> 
>>   ptrue   p2.d                  ; maskAll(true)
>>   ...
>> LOOP:
>>   ...
>>   sub     w11, w13, w14         ; limit - offset
>>   cmp     w14, w13
>>   b.cs    LABEL-1               ; if (offset >= limit) => uncommon-trap
>>   cmp     w11, #0x4
>>   b.lt    LABEL-2               ; if (limit - offset < vlength)
>>   mov     p1.b, p2.b
>> LABEL-3:
>>   ld1d    {z16.d}, p1/z, [x10]  ; load vector masked
>>   ...
>>   cmp     w14, w29
>>   b.cc    LOOP
>>   ...
>> LABEL-2:
>>   whilelo p1.d, x16, x10        ; VectorMaskGen
>>   ...
>>   b       LABEL-3
>>   ...
>> LABEL-1:
>>   uncommon-trap
>> 
>> 
>> Please note that if the array size `LENGTH` is aligned with
>> the vector size 256 (i.e. `LENGTH = 1024`), the branch "LABEL-2"
>> will be optimized out by compiler and it becomes another
>> uncommon-trap.
>> 
>> For NEON, the main CFG is the same with above. But the compiler
>> intrinsification is different. Here is the code:
>> 
>> 
>>   sub     x10, x10, x12          ; limit - offset
>>   scvtf   d16, x10
>>   dup     v16.2d, v16.d[0]       ; replicateD
>> 
>>   mov     x8, #0xd8d0
>>   movk    x8, #0x84cb, lsl #16
>>   movk    x8, #0xffff, lsl #32
>>   ldr     q17, [x8], #0          ; load the "iota" const vector
>>   fcmgt   v18.2d, v16.2d, v17.2d ; mask = iota < limit - offset
>> 
>> 
>> Here is the performance data of the new added benchmark on an ARM
>> SVE 256-bit platform:
>> 
>> 
>> Benchmark                               (size)  Before    After   Units
>> IndexInRangeBenchmark.byteIndexInRange   1024 11203.697 41404.431 ops/ms
>> IndexInRangeBenchmark.byteIndexInRange   1027  2365.920  8747.004 ops/ms
>> IndexInRangeBenchmark.doubleIndexInRange 1024  1227.505  6092.194 ops/ms
>> IndexInRangeBenchmark.doubleIndexInRange 1027   351.215  1156.683 ops/ms
>> IndexInRangeBenchmark.floatIndexInRange  1024  1468.876 11032.580 ops/ms
>> IndexInRangeBenchmark.floatIndexInRange  1027   699.645  2439.671 ops/ms
>> IndexInRangeBenchmark.intIndexInRange    1024  2842.187 11903.544 ops/ms
>> IndexInRangeBenchmark.intIndexInRange    1027   689.866  2547.424 ops/ms
>> IndexInRangeBenchmark.longIndexInRange   1024  1394.135  5902.973 ops/ms
>> IndexInRangeBenchmark.longIndexInRange   1027   355.621  1189.458 ops/ms
>> IndexInRangeBenchmark.shortIndexInRange  1024  5521.468 21578.340 ops/ms
>> IndexInRangeBenchmark.shortIndexInRange  1027  1264.816  4640.504 ops/ms
>> 
>> 
>> And the performance data with ARM NEON:
>> 
>> 
>> Benchmark                               (size)  Before    After   Units
>> IndexInRangeBenchmark.byteIndexInRange   1024  4026.548 15562.880 ops/ms
>> IndexInRangeBenchmark.byteIndexInRange   1027   305.314   576.559 ops/ms
>> IndexInRangeBenchmark.doubleIndexInRange 1024   289.224  2244.080 ops/ms
>> IndexInRangeBenchmark.doubleIndexInRange 1027    39.740    76.499 ops/ms
>> IndexInRangeBenchmark.floatIndexInRange  1024   675.264  4457.470 ops/ms
>> IndexInRangeBenchmark.floatIndexInRange  1027    79.918   144.952 ops/ms
>> IndexInRangeBenchmark.intIndexInRange    1024   740.139  4014.583 ops/ms
>> IndexInRangeBenchmark.intIndexInRange    1027    78.608   147.903 ops/ms
>> IndexInRangeBenchmark.longIndexInRange   1024   400.683  2209.551 ops/ms
>> IndexInRangeBenchmark.longIndexInRange   1027    41.146    69.599 ops/ms
>> IndexInRangeBenchmark.shortIndexInRange  1024  1821.736  8153.546 ops/ms
>> IndexInRangeBenchmark.shortIndexInRange  1027   158.810   243.205 ops/ms
>> 
>> 
>> The performance improves about `3.5x ~ 7.5x` on the vector size aligned
>> (1024 size) benchmarks both with NEON and SVE. And it improves about
>> `3.5x/1.8x` on the vector size not aligned (1027 size) benchmarks with
>> SVE/NEON respectively. We can also observe the similar improvement on
>> the x86 platforms.
>> 
>> [1] https://developer.arm.com/documentation/ddi0596/2020-12/SVE-Instructions/WHILELO--While-incrementing-unsigned-scalar-lower-than-scalar-
>
> Xiaohong Gong has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rename the indexInRange API and simply the benchmarks

Looks good.

-------------

Marked as reviewed by psandoz (Reviewer).

PR: https://git.openjdk.org/jdk/pull/12064

From xgong at openjdk.org  Fri Feb 10 01:36:06 2023
From: xgong at openjdk.org (Xiaohong Gong)
Date: Fri, 10 Feb 2023 01:36:06 GMT
Subject: RFR: 8293198: [vectorapi] Improve the implementation of
 VectorMask.indexInRange() [v2]
In-Reply-To: <7BM1vdj6ShoztqsIgXgTjzVMTiZtdSCL8JqxwXz44Kw=.0f5a61df-4838-4043-8155-dc3ae45ca99b@github.com>
References: <fN58bi3n01tqWpG0-jjUPZQe8hmls2GQ5X3NL2o1RPg=.80e7965d-50af-4fac-bd7c-0a2b99cffe7e@github.com>
 <0dNCRVASsdME6qS79u5z7c6mikJs1jfucfo54lo71ik=.d8c2dc6e-bc60-499f-899c-880a2219b052@github.com>
 <7BM1vdj6ShoztqsIgXgTjzVMTiZtdSCL8JqxwXz44Kw=.0f5a61df-4838-4043-8155-dc3ae45ca99b@github.com>
Message-ID: <hGLbUDzQa47q-ZxKZ3BJhuMqlITi4XjZf1WwYDySjCU=.7078913e-ac7e-4249-ab24-81b5e54a5926@github.com>

On Mon, 6 Feb 2023 17:39:42 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>> Xiaohong Gong has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add smaller array size for benchmark tests
>
> I think it would be useful to adjust the naming and comments of some methods to make it clearer the method parameter constraints.
> 
> `indexInRange0Helper` is now called if the index is partially or totally out of range at the lower or upper ends and `indexInRange0` is called if partially or totally out of range at the upper end.
> e.g. a more literal naming could be:
> `AbstractMask::indexInRange0Helper` -> `AbstractMask::indexPartiallyInRangeHelper`
> `VectorSupport::indexInRange` -> VectorSupport::indexPartiallyInUpperRange`
> ?
> 
> IIUC the performance numbers show that when the array is not a multiple of the vector size there is still quite an impact overall to calling `VectorSupport::indexInRange` for the last loop iteration. I am guessing the overall loop shape is different which impacts other optimizations?
> 
> To do this more optimally likely requires a loop transformation where the last loop iteration is peeled off, but that's a harder transformation in one of the more complicated areas of C2 (although it already supports pre/post loop, so maybe its possible to leverage that?).

Thanks for the review @PaulSandoz !

-------------

PR: https://git.openjdk.org/jdk/pull/12064

From xgong at openjdk.org  Fri Feb 10 01:36:08 2023
From: xgong at openjdk.org (Xiaohong Gong)
Date: Fri, 10 Feb 2023 01:36:08 GMT
Subject: Integrated: 8293198: [vectorapi] Improve the implementation of
 VectorMask.indexInRange()
In-Reply-To: <fN58bi3n01tqWpG0-jjUPZQe8hmls2GQ5X3NL2o1RPg=.80e7965d-50af-4fac-bd7c-0a2b99cffe7e@github.com>
References: <fN58bi3n01tqWpG0-jjUPZQe8hmls2GQ5X3NL2o1RPg=.80e7965d-50af-4fac-bd7c-0a2b99cffe7e@github.com>
Message-ID: <4pIoGiLwVQS6-V5x59NWH2uMD3v1SGHQ_zDyNmljid4=.27436af8-b542-428b-b7e1-76a219094742@github.com>

On Wed, 18 Jan 2023 08:58:42 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

> The Vector API `"indexInRange(int offset, int limit)"` is used
> to compute a vector mask whose lanes are set to true if the
> index of the lane is inside the range specified by the `"offset"`
> and `"limit"` arguments, otherwise the lanes are set to false.
> 
> There are two special cases for this API:
>  1) If `"offset >= 0 && offset >= limit"`, all the lanes of the
> generated mask are false.
>  2) If` "offset >= 0 && limit - offset >= vlength"`, all the
> lanes of the generated mask are true. Note that `"vlength"` is
> the number of vector lanes.
> 
> For such special cases, we can simply use `"maskAll(false|true)"`
> to implement the API. Otherwise, the original comparison with
> `"iota" `vector is needed. And for further optimization, we have
> optimal instruction supported by SVE (i.e. whilelo [1]), which
> can implement the API directly if the `"offset >= 0"`.
> 
> As a summary, to optimize the API, we can use the if-else branches
> to handle the specific cases in java level and intrinsify the
> remaining case by C2 compiler:
> 
> 
>   public VectorMask<E> indexInRange(int offset, int limit) {
>       if (offset < 0) {
>           return this.and(indexInRange0Helper(offset, limit));
>       } else if (offset >= limit) {
>           return this.and(vectorSpecies().maskAll(false));
>       } else if (limit - offset >= length()) {
>           return this.and(vectorSpecies().maskAll(true));
>       }
>       return this.and(indexInRange0(offset, limit));
>  }
> 
> 
> The last part (i.e. `"indexInRange0"`) in the above implementation
> is expected to be intrinsified by C2 compiler if the necessary IRs
> are supported. Otherwise, it will fall back to the original API
> implementation (i.e. `"indexInRange0Helper"`). Regarding to the
> intrinsifaction, the compiler will generate `"VectorMaskGen"` IR
> with "limit - offset" as the input if the current platform supports
> it. Otherwise, it generates `"VectorLoadConst + VectorMaskCmp"` based
> on `"iota < limit - offset"`.
> 
> For the following java code which uses `"indexInRange"`:
> 
> 
> static final VectorSpecies<Double> SPECIES =
>                                    DoubleVector.SPECIES_PREFERRED;
> static final int LENGTH = 1027;
> 
> public static double[] da;
> public static double[] db;
> public static double[] dc;
> 
> private static void func() {
>     for (int i = 0; i < LENGTH; i += SPECIES.length()) {
>         var m = SPECIES.indexInRange(i, LENGTH);
>         var av = DoubleVector.fromArray(SPECIES, da, i, m);
>         av.lanewise(VectorOperators.NEG).intoArray(dc, i, m);
>     }
> }
> 
> 
> The core code generated with SVE 256-bit vector size is:
> 
> 
>   ptrue   p2.d                  ; maskAll(true)
>   ...
> LOOP:
>   ...
>   sub     w11, w13, w14         ; limit - offset
>   cmp     w14, w13
>   b.cs    LABEL-1               ; if (offset >= limit) => uncommon-trap
>   cmp     w11, #0x4
>   b.lt    LABEL-2               ; if (limit - offset < vlength)
>   mov     p1.b, p2.b
> LABEL-3:
>   ld1d    {z16.d}, p1/z, [x10]  ; load vector masked
>   ...
>   cmp     w14, w29
>   b.cc    LOOP
>   ...
> LABEL-2:
>   whilelo p1.d, x16, x10        ; VectorMaskGen
>   ...
>   b       LABEL-3
>   ...
> LABEL-1:
>   uncommon-trap
> 
> 
> Please note that if the array size `LENGTH` is aligned with
> the vector size 256 (i.e. `LENGTH = 1024`), the branch "LABEL-2"
> will be optimized out by compiler and it becomes another
> uncommon-trap.
> 
> For NEON, the main CFG is the same with above. But the compiler
> intrinsification is different. Here is the code:
> 
> 
>   sub     x10, x10, x12          ; limit - offset
>   scvtf   d16, x10
>   dup     v16.2d, v16.d[0]       ; replicateD
> 
>   mov     x8, #0xd8d0
>   movk    x8, #0x84cb, lsl #16
>   movk    x8, #0xffff, lsl #32
>   ldr     q17, [x8], #0          ; load the "iota" const vector
>   fcmgt   v18.2d, v16.2d, v17.2d ; mask = iota < limit - offset
> 
> 
> Here is the performance data of the new added benchmark on an ARM
> SVE 256-bit platform:
> 
> 
> Benchmark                               (size)  Before    After   Units
> IndexInRangeBenchmark.byteIndexInRange   1024 11203.697 41404.431 ops/ms
> IndexInRangeBenchmark.byteIndexInRange   1027  2365.920  8747.004 ops/ms
> IndexInRangeBenchmark.doubleIndexInRange 1024  1227.505  6092.194 ops/ms
> IndexInRangeBenchmark.doubleIndexInRange 1027   351.215  1156.683 ops/ms
> IndexInRangeBenchmark.floatIndexInRange  1024  1468.876 11032.580 ops/ms
> IndexInRangeBenchmark.floatIndexInRange  1027   699.645  2439.671 ops/ms
> IndexInRangeBenchmark.intIndexInRange    1024  2842.187 11903.544 ops/ms
> IndexInRangeBenchmark.intIndexInRange    1027   689.866  2547.424 ops/ms
> IndexInRangeBenchmark.longIndexInRange   1024  1394.135  5902.973 ops/ms
> IndexInRangeBenchmark.longIndexInRange   1027   355.621  1189.458 ops/ms
> IndexInRangeBenchmark.shortIndexInRange  1024  5521.468 21578.340 ops/ms
> IndexInRangeBenchmark.shortIndexInRange  1027  1264.816  4640.504 ops/ms
> 
> 
> And the performance data with ARM NEON:
> 
> 
> Benchmark                               (size)  Before    After   Units
> IndexInRangeBenchmark.byteIndexInRange   1024  4026.548 15562.880 ops/ms
> IndexInRangeBenchmark.byteIndexInRange   1027   305.314   576.559 ops/ms
> IndexInRangeBenchmark.doubleIndexInRange 1024   289.224  2244.080 ops/ms
> IndexInRangeBenchmark.doubleIndexInRange 1027    39.740    76.499 ops/ms
> IndexInRangeBenchmark.floatIndexInRange  1024   675.264  4457.470 ops/ms
> IndexInRangeBenchmark.floatIndexInRange  1027    79.918   144.952 ops/ms
> IndexInRangeBenchmark.intIndexInRange    1024   740.139  4014.583 ops/ms
> IndexInRangeBenchmark.intIndexInRange    1027    78.608   147.903 ops/ms
> IndexInRangeBenchmark.longIndexInRange   1024   400.683  2209.551 ops/ms
> IndexInRangeBenchmark.longIndexInRange   1027    41.146    69.599 ops/ms
> IndexInRangeBenchmark.shortIndexInRange  1024  1821.736  8153.546 ops/ms
> IndexInRangeBenchmark.shortIndexInRange  1027   158.810   243.205 ops/ms
> 
> 
> The performance improves about `3.5x ~ 7.5x` on the vector size aligned
> (1024 size) benchmarks both with NEON and SVE. And it improves about
> `3.5x/1.8x` on the vector size not aligned (1027 size) benchmarks with
> SVE/NEON respectively. We can also observe the similar improvement on
> the x86 platforms.
> 
> [1] https://developer.arm.com/documentation/ddi0596/2020-12/SVE-Instructions/WHILELO--While-incrementing-unsigned-scalar-lower-than-scalar-

This pull request has now been integrated.

Changeset: e245620f
Author:    Xiaohong Gong <xgong at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/e245620f6f6a836aef8ddef9f699cc540f2a5eb6
Stats:     630 lines in 41 files changed: 590 ins; 0 del; 40 mod

8293198: [vectorapi] Improve the implementation of VectorMask.indexInRange()

Reviewed-by: jbhateja, qamai, psandoz

-------------

PR: https://git.openjdk.org/jdk/pull/12064

From duke at openjdk.org  Fri Feb 10 01:55:45 2023
From: duke at openjdk.org (SUN Guoyun)
Date: Fri, 10 Feb 2023 01:55:45 GMT
Subject: RFR: 8301737:
 java/rmi/server/UnicastRemoteObject/serialFilter/FilterUROTest.java fail with
 -Xcomp [v4]
In-Reply-To: <SOPGLzpZBUGbPSkPMAau9HBPyZqXmmSrMefI9to2QBs=.e12f920b-1709-47d4-bf2c-7f9000133193@github.com>
References: <l5m5_9io2QMSFNY7dBHT3Nr2I9Er8wmd92Ze8FP-XE0=.a40d29be-77be-4719-a0a0-71d032eea1e5@github.com>
 <LCJW-DKImXCmpxwBGKJPmSKAUnz9dHg-T09tqD9-SMU=.87d63cd0-6b22-4af8-9786-bd6c75d04ca2@github.com>
 <SOPGLzpZBUGbPSkPMAau9HBPyZqXmmSrMefI9to2QBs=.e12f920b-1709-47d4-bf2c-7f9000133193@github.com>
Message-ID: <gTcBBWD-thGNqohbIKYbdoGMkFzU1qo-2UaWF9SNmX4=.c75d6fdf-0a12-45aa-84c2-0bdc016160f6@github.com>

On Thu, 9 Feb 2023 16:54:42 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> SUN Guoyun has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8301737: java/rmi/server/UnicastRemoteObject/serialFilter/FilterUROTest.java fail with -Xcomp
>
> test/jdk/java/rmi/server/UnicastRemoteObject/serialFilter/FilterUROTest.java line 74:
> 
>> 72:     public void useExportObject(String name, Object obj, int expectedFilterCount) throws RemoteException {
>> 73:         try {
>> 74:             impl = RemoteImpl.create();
> 
> I'd prefer to use  ReachabilityFence at the end of the try block to keep the nested scoping.
> ```Reference.reachabilityFence(impl);```

I just tested it and it really be OK, I'll submit a new commit.

-------------

PR: https://git.openjdk.org/jdk/pull/12399

From bpb at openjdk.org  Fri Feb 10 02:19:30 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 10 Feb 2023 02:19:30 GMT
Subject: RFR: 6595142: (spec) ByteArrayInputStream treats bytes, not characters
Message-ID: <IvwxlmqkKQxgi2TFf0vsWOiMavibGRd1upe_P4DGx5I=.50fca19b-9450-4548-94bb-71e9ca323cb0@github.com>

Replace the two occurrences of `character` with `byte`.

-------------

Commit messages:
 - 6595142: (spec) ByteArrayInputStream treats bytes, not characters

Changes: https://git.openjdk.org/jdk/pull/12505/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12505&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-6595142
  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/12505.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12505/head:pull/12505

PR: https://git.openjdk.org/jdk/pull/12505

From duke at openjdk.org  Fri Feb 10 03:03:07 2023
From: duke at openjdk.org (SUN Guoyun)
Date: Fri, 10 Feb 2023 03:03:07 GMT
Subject: RFR: 8301737:
 java/rmi/server/UnicastRemoteObject/serialFilter/FilterUROTest.java fail with
 -Xcomp [v5]
In-Reply-To: <l5m5_9io2QMSFNY7dBHT3Nr2I9Er8wmd92Ze8FP-XE0=.a40d29be-77be-4719-a0a0-71d032eea1e5@github.com>
References: <l5m5_9io2QMSFNY7dBHT3Nr2I9Er8wmd92Ze8FP-XE0=.a40d29be-77be-4719-a0a0-71d032eea1e5@github.com>
Message-ID: <LK2KMuqdCPMIELIX5aCwW_T8xQoZPF0j378ZfNG0pJQ=.a2b89691-508d-41f4-ba6d-ee4aebde3624@github.com>

> Hi all,
> When -Xcomp be used, this testcase will use more codecaches, causing the GC to be triggered early, then causing this test failed on LoongArch64 architecture.
> 
> This PR fix the issue, Please help review it.
> 
> Thanks.

SUN Guoyun has updated the pull request incrementally with two additional commits since the last revision:

 - 8301737: java/rmi/server/UnicastRemoteObject/serialFilter/FilterUROTest.java fail with -Xcomp
 - 8301737: java/rmi/server/UnicastRemoteObject/serialFilter/FilterUROTest.java fail with -Xcomp

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12399/files
  - new: https://git.openjdk.org/jdk/pull/12399/files/fff401e6..29cce1d9

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12399&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12399&range=03-04

  Stats: 6 lines in 1 file changed: 3 ins; 1 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/12399.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12399/head:pull/12399

PR: https://git.openjdk.org/jdk/pull/12399

From alanb at openjdk.org  Fri Feb 10 07:27:42 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 10 Feb 2023 07:27:42 GMT
Subject: RFR: 6595142: (spec) ByteArrayInputStream treats bytes,
 not characters
In-Reply-To: <IvwxlmqkKQxgi2TFf0vsWOiMavibGRd1upe_P4DGx5I=.50fca19b-9450-4548-94bb-71e9ca323cb0@github.com>
References: <IvwxlmqkKQxgi2TFf0vsWOiMavibGRd1upe_P4DGx5I=.50fca19b-9450-4548-94bb-71e9ca323cb0@github.com>
Message-ID: <C6tEWL6LtrOQdCdqWSrgS-fbDJDCveiJarXjrsroJCY=.336a2a07-a622-4f6a-877d-452a28b9d2ff@github.com>

On Fri, 10 Feb 2023 02:11:35 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Replace the two occurrences of `character` with `byte`.

Looks okay, I assume you've done a wider search to see if there are any more.

-------------

Marked as reviewed by alanb (Reviewer).

PR: https://git.openjdk.org/jdk/pull/12505

From djelinski at openjdk.org  Fri Feb 10 08:50:42 2023
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Fri, 10 Feb 2023 08:50:42 GMT
Subject: RFR: 6595142: (spec) ByteArrayInputStream treats bytes,
 not characters
In-Reply-To: <IvwxlmqkKQxgi2TFf0vsWOiMavibGRd1upe_P4DGx5I=.50fca19b-9450-4548-94bb-71e9ca323cb0@github.com>
References: <IvwxlmqkKQxgi2TFf0vsWOiMavibGRd1upe_P4DGx5I=.50fca19b-9450-4548-94bb-71e9ca323cb0@github.com>
Message-ID: <ZdpRfxiDeqRk740EziBuoVmVlw5EbSYXO8H7jaSvbEA=.eda43f49-57c2-4bbe-8279-81e1420284dc@github.com>

On Fri, 10 Feb 2023 02:11:35 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Replace the two occurrences of `character` with `byte`.

There are similar incorrect comments in SequenceInputStream and BufferedInputStream. There could be others, but "character" is a very popular word, so they are hard to spot.

-------------

PR: https://git.openjdk.org/jdk/pull/12505

From alanb at openjdk.org  Fri Feb 10 08:56:46 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 10 Feb 2023 08:56:46 GMT
Subject: RFR: 8301578: Perform output outside synchronization in
 Module.class [v6]
In-Reply-To: <JFnt4EFnWUDc8V39zF5a3vaKB2ywT18ir8smZ7O_XYM=.61576e58-bc97-4589-a4af-30a12213d61a@github.com>
References: <AXAsqyTdLlz7c_RI-soi4AmkqJDG-laNLbzTVxnmbZU=.35fd56bf-abd5-4aa3-aaee-8a9f7f11eb0a@github.com>
 <JFnt4EFnWUDc8V39zF5a3vaKB2ywT18ir8smZ7O_XYM=.61576e58-bc97-4589-a4af-30a12213d61a@github.com>
Message-ID: <vZBqlbw2p5vs4U35BnlH6_cdX58fraRD506suP5Q0TA=.4e893642-fd9d-46d1-a233-7e9624668293@github.com>

On Thu, 9 Feb 2023 16:46:08 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR proposed to reduce contention in synchronized methods mainly by doing I/O operations outside synch blocks.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Undo more unintended edits

I think this is a good cleanup overall.

src/java.base/share/classes/java/lang/Module.java line 288:

> 286:      * in the outer Module class as that would create a circular initializer dependency.
> 287:      */
> 288:     private static final class EnableNativeAccessHandler {

I see this has been renamed EnableNativeAccessHandler, maybe drop "Handler" as it just sets the enableNativeAccess bit, nothing more.

-------------

PR: https://git.openjdk.org/jdk/pull/12193

From alanb at openjdk.org  Fri Feb 10 08:56:48 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 10 Feb 2023 08:56:48 GMT
Subject: RFR: 8301578: Perform output outside synchronization in
 Module.class [v4]
In-Reply-To: <F3ShQckv90IR2CiS42Cse46y7LluSewwPPCTjhHRR-I=.e716b0e6-637b-4cb3-ae59-d4e49ac1ff96@github.com>
References: <AXAsqyTdLlz7c_RI-soi4AmkqJDG-laNLbzTVxnmbZU=.35fd56bf-abd5-4aa3-aaee-8a9f7f11eb0a@github.com>
 <uJu2J6fQYuoHiZ8-c57a1jLx82An05ZThxe3Nj_46ZA=.81c8f323-fa0e-43a9-80df-9b03ce273111@github.com>
 <zoTJXUR-RPc1uoufixghmex72zYJuIkE0yee4g6EiB4=.f1dd0506-4a48-42cb-8ed3-41b134170000@github.com>
 <F3ShQckv90IR2CiS42Cse46y7LluSewwPPCTjhHRR-I=.e716b0e6-637b-4cb3-ae59-d4e49ac1ff96@github.com>
Message-ID: <eIDgo2qhTx44oCd4nM8mfSxfVaNAKbYPReirLG2A-SM=.4ce88133-8079-4dc9-9abf-f6c94219958b@github.com>

On Thu, 9 Feb 2023 16:27:34 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/Module.java line 120:
>> 
>>> 118:     // memory semantics that preserves ordering and visibility across threads.
>>> 119:     //
>>> 120:     // Used reflectively via Unsafe
>> 
>> I assume L119-120 can be removed.
>
> The reson for the L119-120 comments is to make it easier to understand why we are declaring a variable that does not appear to be used. But maybe there is a better way to do that?

The comment at L117-118 already explains that it's accessed with Unsafe so I don't think we need any more than that. The IDE may suggest the field is unused but if anyone removes it then it will break the JDK build/startup. Same thing many other areas where Unsafe or VarHandles are used. So I don't think we should be too concerned about and the comments at L116-118 are more than enough.

-------------

PR: https://git.openjdk.org/jdk/pull/12193

From pminborg at openjdk.org  Fri Feb 10 09:11:22 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Fri, 10 Feb 2023 09:11:22 GMT
Subject: RFR: 8301578: Perform output outside synchronization in
 Module.class [v7]
In-Reply-To: <AXAsqyTdLlz7c_RI-soi4AmkqJDG-laNLbzTVxnmbZU=.35fd56bf-abd5-4aa3-aaee-8a9f7f11eb0a@github.com>
References: <AXAsqyTdLlz7c_RI-soi4AmkqJDG-laNLbzTVxnmbZU=.35fd56bf-abd5-4aa3-aaee-8a9f7f11eb0a@github.com>
Message-ID: <wWYWYttdDBYcE4Inr5nkubTYBGQPeSKZSwJRDo9C1MM=.0d74b09f-fed0-48fd-88a7-aba92e6534b2@github.com>

> This PR proposed to reduce contention in synchronized methods mainly by doing I/O operations outside synch blocks.

Per Minborg has updated the pull request incrementally with one additional commit since the last revision:

  Remove comment and rename class

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12193/files
  - new: https://git.openjdk.org/jdk/pull/12193/files/dfa24226..29afac8f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12193&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12193&range=05-06

  Stats: 9 lines in 1 file changed: 0 ins; 2 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/12193.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12193/head:pull/12193

PR: https://git.openjdk.org/jdk/pull/12193

From alanb at openjdk.org  Fri Feb 10 09:30:47 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 10 Feb 2023 09:30:47 GMT
Subject: RFR: 8301578: Perform output outside synchronization in
 Module.class [v7]
In-Reply-To: <wWYWYttdDBYcE4Inr5nkubTYBGQPeSKZSwJRDo9C1MM=.0d74b09f-fed0-48fd-88a7-aba92e6534b2@github.com>
References: <AXAsqyTdLlz7c_RI-soi4AmkqJDG-laNLbzTVxnmbZU=.35fd56bf-abd5-4aa3-aaee-8a9f7f11eb0a@github.com>
 <wWYWYttdDBYcE4Inr5nkubTYBGQPeSKZSwJRDo9C1MM=.0d74b09f-fed0-48fd-88a7-aba92e6534b2@github.com>
Message-ID: <c6Okqyxuw5oj6GABgzzrz0C33ggD67YoCXOuK4d4sX4=.ba07bd3b-1dad-482a-a262-d6df21328e49@github.com>

On Fri, 10 Feb 2023 09:11:22 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR proposed to reduce contention in synchronized methods mainly by doing I/O operations outside synch blocks.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove comment and rename class

Marked as reviewed by alanb (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/12193

From duke at openjdk.org  Fri Feb 10 10:07:41 2023
From: duke at openjdk.org (Xiaowei Lu)
Date: Fri, 10 Feb 2023 10:07:41 GMT
Subject: RFR: 8302204: Optimize BigDecimal.divide
Message-ID: <rUC0Dh_-1E0PZNJwM0GRH1KPu6prPotT-oeDTUdqjI4=.a8f7d3b7-a0f2-45a0-ae01-f37ef108d18f@github.com>

[JDK-8269667](https://bugs.openjdk.org/browse/JDK-8269667) has uncovered the poor performance of BigDecimal.divide under certain circumstance.

We confront similar situations when benchmarking Spark3 on TPC-DS test kit. According to the flame-graph below, it is StripZeros that spends most of the time of BigDecimal.divide. Hence we propose this patch to optimize stripping zeros.
![?? 1](https://user-images.githubusercontent.com/39413832/218062061-53cd0220-776e-4b72-8b9a-6b0f11707986.png)

Currently, createAndStripZerosToMatchScale() is performed linearly. That is, the target value is parsed from back to front, each time stripping out single ?0?. To optimize, we can adopt the method of binary search. That is, each time we try to strip out ${scale/2} ?0?s. 

The performance looks good. Therotically, time complexity of our method is O(log n), while the current one is O(n). In practice, benchmarks on Spark3 show that 1/3 less time (102s->68s) is spent on TPC-DS query4. We also runs Jtreg and JCK to check correctness, and it seems fine.

More about environment: 
we run Spark3.3.0 on Openjdk11, but it seems jdk version doesn?t have much impact on BigDecimal. Spark cluster consists of a main node and 2 core nodes, each has 4cores, 16g memory and 4x500GB storage.

-------------

Commit messages:
 - 8302204: Optimize BigDecimal.divide

Changes: https://git.openjdk.org/jdk/pull/12509/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12509&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8302204
  Stats: 26 lines in 1 file changed: 26 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/12509.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12509/head:pull/12509

PR: https://git.openjdk.org/jdk/pull/12509

From asotona at openjdk.org  Fri Feb 10 11:01:58 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Fri, 10 Feb 2023 11:01:58 GMT
Subject: RFR: 8294982: Implementation of Classfile API [v12]
In-Reply-To: <8tqh8yQ47KA2UrWlPItUcFMQ97uvNXCiCJUj-PDksJo=.c9e71d26-15ef-4915-8317-651337a23af9@github.com>
References: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
 <Q4VeZ2yWAg85FqUDJa5hYq3jHty5H547gD0H-x3oIq0=.58d463a4-237a-4fee-bd0f-83262d49522a@github.com>
 <c022hrWNEHW76nhP_sXTQXCTjtL8jjM8r_yYv0IvbPI=.2a9cfbae-2fef-4cdb-8189-b869b1513fef@github.com>
 <8tqh8yQ47KA2UrWlPItUcFMQ97uvNXCiCJUj-PDksJo=.c9e71d26-15ef-4915-8317-651337a23af9@github.com>
Message-ID: <IyFnpQ21meJtQ0tROFwhc4AZ2txzDXOQSLgn6XMqwg4=.8994fb5e-666b-4d58-883f-2b8844ba8843@github.com>

On Mon, 6 Feb 2023 14:13:36 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/classfile/BufWriter.java line 40:
>> 
>>> 38:  * to the end of the buffer, as well as to create constant pool entries.
>>> 39:  */
>>> 40: public sealed interface BufWriter
>> 
>> What is the relationship between this and ClassReader? Is one the dual of the other - e.g. is the intended use for BufWriter to write custom attributes, whereas ClassReader reads custom attributes?
>
> Yes, it is an exposure of low-level API to support custom attributes.

I see this topic has moved to classfile-api-dev mailing list.

-------------

PR: https://git.openjdk.org/jdk/pull/10982

From asotona at openjdk.org  Fri Feb 10 11:02:01 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Fri, 10 Feb 2023 11:02:01 GMT
Subject: RFR: 8294982: Implementation of Classfile API [v12]
In-Reply-To: <hhnDQ3Sx7BiJ05Jt32dwEKi93Rs1rkxi_kTbfJH93oI=.ace5a7f6-8ba4-42cc-9046-8ac190b12866@github.com>
References: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
 <Q4VeZ2yWAg85FqUDJa5hYq3jHty5H547gD0H-x3oIq0=.58d463a4-237a-4fee-bd0f-83262d49522a@github.com>
 <c022hrWNEHW76nhP_sXTQXCTjtL8jjM8r_yYv0IvbPI=.2a9cfbae-2fef-4cdb-8189-b869b1513fef@github.com>
 <FbFekphAbS5DQzn6B-uUHkX-2EF8Aq4NcijjMdlxAM0=.280a7529-4008-4539-9137-da7600e13eee@github.com>
 <kxds1bmvZ8TbtVK5iDx_hZtrqN3uywsa6GqumJ7RubE=.ffd151e4-a1ba-4018-914c-518fd122dd4f@github.com>
 <WxjOq5CRJ9OtviOIxDKH9C78bScpiGmkiBqVXLDddzU=.a5a85537-43e8-4cf4-b747-86b945999d71@github.com>
 <84RlLSIsacJTJVM-esvzoXnQ5rDEByog5b1ibFRJOE8=.05e8e7a7-2185-4e1c-b5b9-59ce3b3eea03@github.com>
 <sQwAa41mu1z226uzYIA2_v0tN8un257MDgc-WPO8SFY=.486c845c-5012-4291-bcd7-c7b0247e02dd@github.com>
 <wxsAcKZwigc4sIUexg5m-6UlOg8ZHflccTs47FJCgdQ=.5613b95e-96b0-4ced-a587-ccca3f80595d@github.com>
 <_jsw8D5-esoFp7fGSZECKF8ccwrfikwjIprRrVdCOjo=.2d8cd9f6-9c6a-4726-bc90-a4c163e8dd67@github.com>
 <LICxfIJ0QVmRRY4NJPCW_Rp4o3qhyaMrrgW
 LV-S9jHI=.4f6b40d5-d25d-4035-8fa5-186b2c735606@github.com>
 <wzHOP5Fnj3FhcNs61TKxxBZ5R6fB-oky72z_hlf1Svk=.ed56a42f-cce6-415a-b93a-d39dee6adc78@github.com>
 <hhnDQ3Sx7BiJ05Jt32dwEKi93Rs1rkxi_kTbfJH93oI=.ace5a7f6-8ba4-42cc-9046-8ac190b12866@github.com>
Message-ID: <AouWiBKLOhQJIKKQDzw0S3E1ON8Z9y7HFso4xL02-t8=.d880c319-dca6-44f6-aa7e-ed53fe8b17ca@github.com>

On Thu, 9 Feb 2023 12:45:27 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> During the fix I found the definition that `ThrowableSig` (as a super-set of `ClassTypeSig` and `TypeVarSig`) IS `Signature` - that fact is critical for processing.
>> For example when `MethodSignature` is serialized `ThrowableSig::signatureString` is critical.
>> Or `ClassRemapper` depends on the inheritence:
>> 
>> signature.throwableSignatures().stream().map(this::mapSignature).toList()
>> 
>> however `mapSignature` could not be applied on `ThrowableSig` when it does not inherit from `Signature`.
>
> I think I also see where the current hierarchy comes from - e.g. while `ThrowableSig` is a part of a method signature, it is indeed used by the production to specify a set of signatures that belong to that set. Thanks for the patience.

No problem, I had to remind myself all the reasons why does it look like Rubik's cube :)

-------------

PR: https://git.openjdk.org/jdk/pull/10982

From asotona at openjdk.org  Fri Feb 10 11:06:57 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Fri, 10 Feb 2023 11:06:57 GMT
Subject: RFR: 8294982: Implementation of Classfile API [v13]
In-Reply-To: <Sxvu5MMpl41oP_h0CwnQ5y6H1zVyB9JRx3Qiq502Jfg=.6c7d2e51-5361-4d4e-98a0-769bd4c5b548@github.com>
References: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
 <Ej4u9wRtUuLS5LJhMkXwmown_MGuwR0gH9ruJ1A1g30=.f6405576-6655-4252-9135-ebc77765436e@github.com>
 <u6VmkXvghsyyf7qwyHyDpcqZ-wVCfFnZgOoB_wiz2-A=.ce2c44e1-81b0-4851-811c-5f4fd3fdda62@github.com>
 <XmkS1CfKIATrXGdgIqZNmfY4LI3R3wBuTj903AkwkR0=.3787d0f1-f617-426d-95ae-ac736abc43ed@github.com>
 <Sxvu5MMpl41oP_h0CwnQ5y6H1zVyB9JRx3Qiq502Jfg=.6c7d2e51-5361-4d4e-98a0-769bd4c5b548@github.com>
Message-ID: <fWqWbxdUzk-p2NPgD4au1yK6PZwjgw7BFgiF4xPVlo0=.017a1b66-f7ce-4302-ae3c-546aa1c29b07@github.com>

On Wed, 8 Feb 2023 11:19:32 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Any reference to an official specification of CharacterRangeInfo is appreciated.
>> Thanks.
>
>> Any reference to an official specification of CharacterRangeInfo is appreciated. Thanks.
> 
> There's this - which points back to javac code :-)
> 
> https://github.com/jacoco/jacoco/wiki/CharacterRangeTable

Unfortunately I don't have enough information to provide static helpers.

-------------

PR: https://git.openjdk.org/jdk/pull/10982

From asotona at openjdk.org  Fri Feb 10 11:07:02 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Fri, 10 Feb 2023 11:07:02 GMT
Subject: RFR: 8294982: Implementation of Classfile API [v13]
In-Reply-To: <u6VmkXvghsyyf7qwyHyDpcqZ-wVCfFnZgOoB_wiz2-A=.ce2c44e1-81b0-4851-811c-5f4fd3fdda62@github.com>
References: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
 <Ej4u9wRtUuLS5LJhMkXwmown_MGuwR0gH9ruJ1A1g30=.f6405576-6655-4252-9135-ebc77765436e@github.com>
 <u6VmkXvghsyyf7qwyHyDpcqZ-wVCfFnZgOoB_wiz2-A=.ce2c44e1-81b0-4851-811c-5f4fd3fdda62@github.com>
Message-ID: <NBSJ_Jl4C2jrK7fT8udubne73Fr19mQZU6eRFHsYmIU=.16038547-5c8f-4e46-bb5a-8dc2aeb866b2@github.com>

On Tue, 7 Feb 2023 16:04:07 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Adam Sotona has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - javadoc fixes
>>  - obsolete identifiers and unused imports cleanup
>>  - TypeAnnotation.TypePathComponent cleanup
>
> src/java.base/share/classes/jdk/internal/classfile/attribute/ModuleExportInfo.java line 107:
> 
>> 105:      * @param exportsTo the modules to which this package is exported
>> 106:      */
>> 107:     static ModuleExportInfo of(PackageEntry exports,
> 
> (Here and elsewhere) - should there be factories also taking a PackageDesc (which seems to be an extension of the ClassDesc API, but for packages) ?

yes, they are missing, I'm working on it.

-------------

PR: https://git.openjdk.org/jdk/pull/10982

From asotona at openjdk.org  Fri Feb 10 11:15:01 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Fri, 10 Feb 2023 11:15:01 GMT
Subject: RFR: 8294982: Implementation of Classfile API [v15]
In-Reply-To: <hUvPqC4427nX8mcEcC5Tr90RFXAtmNigTxexY_Ujf04=.55b5e41d-afa7-4220-b13f-6fb0dd25dd0e@github.com>
References: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
 <hr8eti6ytvV05JFRr5hYLWy7yBla9mpI8vKKfaaFR-k=.a92f7bea-6400-4f95-a40c-d57192013f19@github.com>
 <hUvPqC4427nX8mcEcC5Tr90RFXAtmNigTxexY_Ujf04=.55b5e41d-afa7-4220-b13f-6fb0dd25dd0e@github.com>
Message-ID: <C-fd3WUG0sCiQVVFekGvM1JKgjN5PdkxmCIifWdrGFw=.7fb95367-0539-4b8b-98d4-2a50c5058e57@github.com>

On Thu, 9 Feb 2023 13:03:46 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   AttributeElement.Kind removal (#48)
>
> src/java.base/share/classes/jdk/internal/classfile/constantpool/AnnotationConstantValueEntry.java line 33:
> 
>> 31:  * which includes the four kinds of primitive constants, and UTF8 constants.
>> 32:  */
>> 33: public sealed interface AnnotationConstantValueEntry extends PoolEntry
> 
> Should this extend LoadableConstantEntry (and restrict it more) ?

`LoadableConstantEntry` and `AnnotationConstantValueEntry` are just partially overlapping according to the spec.
The biggest difference (and source of confusion) is that `StringEntry` is `LoadableConstantEntry`, however not `AnnotationConstantValueEntry` and `Utf8Entry` is `AnnotationConstantValueEntry`, however not `LoadableConstantEntry`.

-------------

PR: https://git.openjdk.org/jdk/pull/10982

From asotona at openjdk.org  Fri Feb 10 11:20:57 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Fri, 10 Feb 2023 11:20:57 GMT
Subject: RFR: 8294982: Implementation of Classfile API [v15]
In-Reply-To: <hUvPqC4427nX8mcEcC5Tr90RFXAtmNigTxexY_Ujf04=.55b5e41d-afa7-4220-b13f-6fb0dd25dd0e@github.com>
References: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
 <hr8eti6ytvV05JFRr5hYLWy7yBla9mpI8vKKfaaFR-k=.a92f7bea-6400-4f95-a40c-d57192013f19@github.com>
 <hUvPqC4427nX8mcEcC5Tr90RFXAtmNigTxexY_Ujf04=.55b5e41d-afa7-4220-b13f-6fb0dd25dd0e@github.com>
Message-ID: <6gCIlUafIspeaYjIs6AlFuRqJtUsuOqjKOSDBs8kYV4=.14b51d52-5b74-4918-a3ab-a7fda35a723b@github.com>

On Thu, 9 Feb 2023 14:11:36 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   AttributeElement.Kind removal (#48)
>
> src/java.base/share/classes/jdk/internal/classfile/constantpool/Utf8Entry.java line 47:
> 
>> 45:      * @param s the string to compare to
>> 46:      */
>> 47:     boolean equalsString(String s);
> 
> Whatif the provided string contains character that are not representable in Utf8? Should we throw (e.g. `IllegalArgumentException`) ?

I would rather expect `false` value returned, however this case is probably not covered by tests.

> src/java.base/share/classes/jdk/internal/classfile/instruction/CharacterRange.java line 60:
> 
>> 58:      * viewed as an array of (possibly multi-byte) characters.
>> 59:      */
>> 60:     int characterRangeStart();
> 
> Not sure if this belongs here - e.g. it seems to me that `characterRangeStart` is less useful than the labels. But I'm not super expert on how this code element might be used.

It is character range within the source code, not the bytecode.

-------------

PR: https://git.openjdk.org/jdk/pull/10982

From asotona at openjdk.org  Fri Feb 10 11:29:56 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Fri, 10 Feb 2023 11:29:56 GMT
Subject: RFR: 8294982: Implementation of Classfile API [v15]
In-Reply-To: <scAqAuD2wQBhQdg_N1e5PPRJkmhwgCW-Mp__BajTxsw=.c73a8812-926e-4bf0-8e8f-7589a809b173@github.com>
References: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
 <hr8eti6ytvV05JFRr5hYLWy7yBla9mpI8vKKfaaFR-k=.a92f7bea-6400-4f95-a40c-d57192013f19@github.com>
 <scAqAuD2wQBhQdg_N1e5PPRJkmhwgCW-Mp__BajTxsw=.c73a8812-926e-4bf0-8e8f-7589a809b173@github.com>
Message-ID: <zl4ItbIt1wr2_QaGpv2FYj9yaLrhfrtfNYZvZKa9su8=.767de808-a449-4683-9580-7b8351583aea@github.com>

On Thu, 9 Feb 2023 15:01:03 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   AttributeElement.Kind removal (#48)
>
> src/java.base/share/classes/jdk/internal/classfile/instruction/MonitorInstruction.java line 48:
> 
>> 46:      *           which must be of kind {@link Opcode.Kind#MONITOR}
>> 47:      */
>> 48:     static MonitorInstruction of(Opcode op) {
> 
> There are only two cases here - perhaps also offer factories for monitor enter/exit? Or is creating instruction models a rare operation (e.g. because when adapting you always also have a CodeBuilder which has the user-friendly methods?)

Each of the approaches server different purposes. `CodeBuilder` with user-friendly methods is my first choice when typing code from scratch, however in transformations you usually start with a pattern switch and it is a Classfile API "standard" to find relevant factory methods in each `Instruction` sub-type.

-------------

PR: https://git.openjdk.org/jdk/pull/10982

From duke at openjdk.org  Fri Feb 10 12:12:19 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Fri, 10 Feb 2023 12:12:19 GMT
Subject: RFR: 8302214: Typo in javadoc of Arrays.compare and Arrays.mismatch
Message-ID: <NC9N8WA8eqcmgwep2tqJaD5rruWOHwWxbbYCd4XsdRk=.aa39a6a4-396b-4fac-a408-3e0c04fc140c@github.com>

The Javadocs of Arrays.compare and Arrays.mismatch uses the incorrect capitalization `atoIndex` and `btoIndex` when referencing the corresponding `aToIndex` and `bToIndex` parameters.

Sample:


* specified ranges [{@code aFromIndex}, {@code atoIndex}) and
* [{@code bFromIndex}, {@code btoIndex}) respectively:


This PR changes the capitalization to `aToIndex` and `bToIndex`. This change was performed using case-sensitive search / replace in an IDE.

-------------

Commit messages:
 - Fix incorrect capitalization of aToIndex, bToIndex in Arrays.mismatch and Arrays.compare Javadocs

Changes: https://git.openjdk.org/jdk/pull/12488/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12488&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8302214
  Stats: 58 lines in 1 file changed: 0 ins; 0 del; 58 mod
  Patch: https://git.openjdk.org/jdk/pull/12488.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12488/head:pull/12488

PR: https://git.openjdk.org/jdk/pull/12488

From jpai at openjdk.org  Fri Feb 10 12:12:19 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 10 Feb 2023 12:12:19 GMT
Subject: RFR: 8302214: Typo in javadoc of Arrays.compare and
 Arrays.mismatch
In-Reply-To: <NC9N8WA8eqcmgwep2tqJaD5rruWOHwWxbbYCd4XsdRk=.aa39a6a4-396b-4fac-a408-3e0c04fc140c@github.com>
References: <NC9N8WA8eqcmgwep2tqJaD5rruWOHwWxbbYCd4XsdRk=.aa39a6a4-396b-4fac-a408-3e0c04fc140c@github.com>
Message-ID: <3ugp1dByE8_Vqgm3tDWwdmJp-ghljTlQWRI4sLLnLHk=.15db2750-539d-4e21-8a8f-33745dee69bd@github.com>

On Thu, 9 Feb 2023 10:13:03 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

> The Javadocs of Arrays.compare and Arrays.mismatch uses the incorrect capitalization `atoIndex` and `btoIndex` when referencing the corresponding `aToIndex` and `bToIndex` parameters.
> 
> Sample:
> 
> 
> * specified ranges [{@code aFromIndex}, {@code atoIndex}) and
> * [{@code bFromIndex}, {@code btoIndex}) respectively:
> 
> 
> This PR changes the capitalization to `aToIndex` and `bToIndex`. This change was performed using case-sensitive search / replace in an IDE.

Hello Eirik, I've create a JBS issue to track this change https://bugs.openjdk.org/browse/JDK-8302214. Please update the title of this PR to `8302214: Typo in javadoc of Arrays.compare and Arrays.mismatch`, so that it triggers the official review process.

-------------

PR: https://git.openjdk.org/jdk/pull/12488

From duke at openjdk.org  Fri Feb 10 12:12:19 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Fri, 10 Feb 2023 12:12:19 GMT
Subject: RFR: 8302214: Typo in javadoc of Arrays.compare and
 Arrays.mismatch
In-Reply-To: <3ugp1dByE8_Vqgm3tDWwdmJp-ghljTlQWRI4sLLnLHk=.15db2750-539d-4e21-8a8f-33745dee69bd@github.com>
References: <NC9N8WA8eqcmgwep2tqJaD5rruWOHwWxbbYCd4XsdRk=.aa39a6a4-396b-4fac-a408-3e0c04fc140c@github.com>
 <3ugp1dByE8_Vqgm3tDWwdmJp-ghljTlQWRI4sLLnLHk=.15db2750-539d-4e21-8a8f-33745dee69bd@github.com>
Message-ID: <Q1Sj2nK0XOeUEm5emmKZMDj1VG-u_PSUF5CIwjCfvKM=.f9827198-4b64-43a7-b0f6-8f88df8d0409@github.com>

On Fri, 10 Feb 2023 12:04:01 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Hello Eirik, I've create a JBS issue to track this change https://bugs.openjdk.org/browse/JDK-8302214. 

Thanks, title changed!

-------------

PR: https://git.openjdk.org/jdk/pull/12488

From msheppar at openjdk.org  Fri Feb 10 12:16:44 2023
From: msheppar at openjdk.org (Mark Sheppard)
Date: Fri, 10 Feb 2023 12:16:44 GMT
Subject: RFR: 8301737:
 java/rmi/server/UnicastRemoteObject/serialFilter/FilterUROTest.java fail with
 -Xcomp [v4]
In-Reply-To: <gTcBBWD-thGNqohbIKYbdoGMkFzU1qo-2UaWF9SNmX4=.c75d6fdf-0a12-45aa-84c2-0bdc016160f6@github.com>
References: <l5m5_9io2QMSFNY7dBHT3Nr2I9Er8wmd92Ze8FP-XE0=.a40d29be-77be-4719-a0a0-71d032eea1e5@github.com>
 <LCJW-DKImXCmpxwBGKJPmSKAUnz9dHg-T09tqD9-SMU=.87d63cd0-6b22-4af8-9786-bd6c75d04ca2@github.com>
 <SOPGLzpZBUGbPSkPMAau9HBPyZqXmmSrMefI9to2QBs=.e12f920b-1709-47d4-bf2c-7f9000133193@github.com>
 <gTcBBWD-thGNqohbIKYbdoGMkFzU1qo-2UaWF9SNmX4=.c75d6fdf-0a12-45aa-84c2-0bdc016160f6@github.com>
Message-ID: <hSA4REOl1gTAfzJW90_Q2eXBMTeGBpNltHKh-32QNmM=.0b83f030-04e6-4e95-b6a6-dae0fd499477@github.com>

On Fri, 10 Feb 2023 01:53:18 GMT, SUN Guoyun <duke at openjdk.org> wrote:

>> test/jdk/java/rmi/server/UnicastRemoteObject/serialFilter/FilterUROTest.java line 74:
>> 
>>> 72:     public void useExportObject(String name, Object obj, int expectedFilterCount) throws RemoteException {
>>> 73:         try {
>>> 74:             impl = RemoteImpl.create();
>> 
>> I'd prefer to use  ReachabilityFence at the end of the try block to keep the nested scoping.
>> ```Reference.reachabilityFence(impl);```
>
> I just tested it and it really be OK, I'll submit a new commit.

yes, this mitigates the issue within the test,  and alls good.
BUT it still leave an open question as to why the behaviour of the test is different for the -Xcomp mode and the interpretative mode?
I think it would be reasonable to expect both modes to behave the same. As such, that the compile mode should generate a fence or whatever to guarantee that the impl remain a strong reference until it goes out of scope at the end of the try block ?
Thus is the case in non -Xcomp mode, but in -Xcomp the status of the impl reference is accelerate to to being unreachable and a candidate for garbage collection ?
Is it not a hotspot compiler issue or the component area responsible for -Xcomp ?

-------------

PR: https://git.openjdk.org/jdk/pull/12399

From alanb at openjdk.org  Fri Feb 10 13:29:46 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 10 Feb 2023 13:29:46 GMT
Subject: RFR: 8297632: InputStream.transferTo() method should specify what
 the return value should be when the number of bytes transfered is
 larger than Long.MAX_VALUE [v6]
In-Reply-To: <v_KgToOO76ZvAmeGRMZ03QVLzO13iXAQZ6DGFSyfpA0=.c3aa2d43-3019-40d4-baf0-033a20c98bc4@github.com>
References: <T38kO1hcz3rhpqOOPYmoPl1TlRORJBifQWtXLl10x8Y=.595338d3-df98-4202-95b5-eda88a4ed0a2@github.com>
 <v_KgToOO76ZvAmeGRMZ03QVLzO13iXAQZ6DGFSyfpA0=.c3aa2d43-3019-40d4-baf0-033a20c98bc4@github.com>
Message-ID: <Lh5xk1qRWDH_xuolhow6Oxea_uwmdnZnz6fELZGtcb0=.71a32cb4-a882-426c-90cb-a09e835a82a5@github.com>

On Tue, 7 Feb 2023 16:40:06 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> `java.io.InputStream::transferTo` could conceivably return a negative value if the count of bytes transferred overflows a `long`. Modify the method to limit the number of bytes transferred to `Long.MAX_VALUE` per invocation.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8297632: Increment recent copyright year to 2023

This version looks okay.

src/java.base/share/classes/java/io/SequenceInputStream.java line 249:

> 247:                 } catch (ArithmeticException ignore) {
> 248:                     return Long.MAX_VALUE;
> 249:                 }

This one could check if c < Long.MAX_VALUE like the other implementations, if only for consistency. c could be renamed to transferred too.

-------------

Marked as reviewed by alanb (Reviewer).

PR: https://git.openjdk.org/jdk/pull/11403

From jlaskey at openjdk.org  Fri Feb 10 13:37:37 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Fri, 10 Feb 2023 13:37:37 GMT
Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates
 (Preview) [v35]
In-Reply-To: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
Message-ID: <qigcd9_Ho_hqmU70v4acg_P88mhLEFg3F95h8YcLEOM=.0fc23f0f-9fbb-4533-a25c-a26e9d3b9a07@github.com>

> Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12).

Jim Laskey 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 branch 'master' into 8285932
 - Update to JDK 21
 - Merge branch 'master' into 8285932
 - Merge branch 'master' into 8285932
 - FormatProcessor changes
 - Update @since
 - Requested changes #12
 - Seal Digits
 - Requested changes #11
 - Typo
 - ... and 40 more: https://git.openjdk.org/jdk/compare/c8ace482...264120a9

-------------

Changes: https://git.openjdk.org/jdk/pull/10889/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=34
  Stats: 9519 lines in 81 files changed: 9356 ins; 28 del; 135 mod
  Patch: https://git.openjdk.org/jdk/pull/10889.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10889/head:pull/10889

PR: https://git.openjdk.org/jdk/pull/10889

From pminborg at openjdk.org  Fri Feb 10 13:49:54 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Fri, 10 Feb 2023 13:49:54 GMT
Subject: Integrated: 8301578: Perform output outside synchronization in
 Module.class
In-Reply-To: <AXAsqyTdLlz7c_RI-soi4AmkqJDG-laNLbzTVxnmbZU=.35fd56bf-abd5-4aa3-aaee-8a9f7f11eb0a@github.com>
References: <AXAsqyTdLlz7c_RI-soi4AmkqJDG-laNLbzTVxnmbZU=.35fd56bf-abd5-4aa3-aaee-8a9f7f11eb0a@github.com>
Message-ID: <vOgutJ44W4uYwAZROM9Q5fIQQWk_uDE8mkLqH1wYNOE=.20309b44-d562-456d-a535-82a3db391c8b@github.com>

On Wed, 25 Jan 2023 12:26:26 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR proposed to reduce contention in synchronized methods mainly by doing I/O operations outside synch blocks.

This pull request has now been integrated.

Changeset: c25b4f46
Author:    Per Minborg <pminborg at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/c25b4f461968503888124c6fd5cd6e788617ec3f
Stats:     60 lines in 1 file changed: 24 ins; 18 del; 18 mod

8301578: Perform output outside synchronization in Module.class

Reviewed-by: alanb

-------------

PR: https://git.openjdk.org/jdk/pull/12193

From alanb at openjdk.org  Fri Feb 10 13:53:47 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 10 Feb 2023 13:53:47 GMT
Subject: RFR: 8298619: java/io/File/GetXSpace.java is failing
In-Reply-To: <6LnAAIclo5mZZgba4XUSTSc72vyNrBinzUlO9-kJXbU=.fe0c5e94-9e36-4484-b8e7-0f19cb10cb05@github.com>
References: <6LnAAIclo5mZZgba4XUSTSc72vyNrBinzUlO9-kJXbU=.fe0c5e94-9e36-4484-b8e7-0f19cb10cb05@github.com>
Message-ID: <DTNziTj7KbkeG3LvpMREAi9WP9XRczQUdP_1-XTvp2c=.b9b78dec-3879-4626-9174-306e57ce83a4@github.com>

On Fri, 3 Feb 2023 02:02:39 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Modify the `Space` instances used for size comparison to be created with total number of bytes derived from the Windows `diskFree` utility instead of Cygwin?s `df`.

test/jdk/java/io/File/GetXSpace.java line 152:

> 150:     }
> 151: 
> 152:     private static String getCallerTotalSpace(String name) throws IOException {

It seems a bit fragile to be parsing the output of `fsutil volume diskFree` as the output seems to vary by Windows releases and maybe configuration. So minimally, I think it should be changed to use ProcessTools so that the command and the output show up in the .jtr file.

In passing, you might want to choose a different method name to make it clearer what it does, maybe volumeDiskFree?

-------------

PR: https://git.openjdk.org/jdk/pull/12397

From jlaskey at openjdk.org  Fri Feb 10 14:27:17 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Fri, 10 Feb 2023 14:27:17 GMT
Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates
 (Preview) [v36]
In-Reply-To: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
Message-ID: <c3fzYf65-ppnmsSbC41mQMcksftq44h6USI6Jio0KSI=.2ba0037e-8a70-4420-8810-606b823e40bd@github.com>

> Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12).

Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:

  Bring up to date

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10889/files
  - new: https://git.openjdk.org/jdk/pull/10889/files/264120a9..665cded9

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=35
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=34-35

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/10889.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10889/head:pull/10889

PR: https://git.openjdk.org/jdk/pull/10889

From bpb at openjdk.org  Fri Feb 10 16:48:08 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 10 Feb 2023 16:48:08 GMT
Subject: RFR: 6595142: (spec) ByteArrayInputStream treats bytes,
 not characters [v2]
In-Reply-To: <IvwxlmqkKQxgi2TFf0vsWOiMavibGRd1upe_P4DGx5I=.50fca19b-9450-4548-94bb-71e9ca323cb0@github.com>
References: <IvwxlmqkKQxgi2TFf0vsWOiMavibGRd1upe_P4DGx5I=.50fca19b-9450-4548-94bb-71e9ca323cb0@github.com>
Message-ID: <OoGZNDpFTJ5OgcgwA2XQBLT9VCCGi25NEqtArGNPrN8=.9fc8d5cf-6f06-4b9f-b54a-2813ee619334@github.com>

> Replace the two occurrences of `character` with `byte`.

Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:

  6595142: Refer to bytes, not characters in BufferedInputStream and SequenceInputStream

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12505/files
  - new: https://git.openjdk.org/jdk/pull/12505/files/b4e6bf83..7868641a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12505&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12505&range=00-01

  Stats: 5 lines in 2 files changed: 0 ins; 0 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/12505.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12505/head:pull/12505

PR: https://git.openjdk.org/jdk/pull/12505

From bpb at openjdk.org  Fri Feb 10 16:48:11 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 10 Feb 2023 16:48:11 GMT
Subject: RFR: 6595142: (spec) ByteArrayInputStream treats bytes,
 not characters
In-Reply-To: <ZdpRfxiDeqRk740EziBuoVmVlw5EbSYXO8H7jaSvbEA=.eda43f49-57c2-4bbe-8279-81e1420284dc@github.com>
References: <IvwxlmqkKQxgi2TFf0vsWOiMavibGRd1upe_P4DGx5I=.50fca19b-9450-4548-94bb-71e9ca323cb0@github.com>
 <ZdpRfxiDeqRk740EziBuoVmVlw5EbSYXO8H7jaSvbEA=.eda43f49-57c2-4bbe-8279-81e1420284dc@github.com>
Message-ID: <EYQfp46fTvqt68UV4jPGDgMRlbvB_WAgUXEQKNTt3zk=.c83ddc4c-c473-458a-ac3b-85d7cbc0e9a5@github.com>

On Fri, 10 Feb 2023 08:47:58 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> There are similar incorrect comments in SequenceInputStream and BufferedInputStream. There could be others, but "character" is a very popular word, so they are hard to spot.

Thanks for spotting these. Fixed in 7868641a2c9558e66b51c40b49031095317c3a48.

-------------

PR: https://git.openjdk.org/jdk/pull/12505

From bpb at openjdk.org  Fri Feb 10 16:48:13 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 10 Feb 2023 16:48:13 GMT
Subject: RFR: 6595142: (spec) ByteArrayInputStream treats bytes,
 not characters [v2]
In-Reply-To: <C6tEWL6LtrOQdCdqWSrgS-fbDJDCveiJarXjrsroJCY=.336a2a07-a622-4f6a-877d-452a28b9d2ff@github.com>
References: <IvwxlmqkKQxgi2TFf0vsWOiMavibGRd1upe_P4DGx5I=.50fca19b-9450-4548-94bb-71e9ca323cb0@github.com>
 <C6tEWL6LtrOQdCdqWSrgS-fbDJDCveiJarXjrsroJCY=.336a2a07-a622-4f6a-877d-452a28b9d2ff@github.com>
Message-ID: <GrWL4YTrCuOTA7L9cItEh-T8JACWe_5p-x-RV3T7eSc=.33defaa9-5a0b-4594-922a-326c288d146e@github.com>

On Fri, 10 Feb 2023 07:25:11 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> Looks okay, I assume you've done a wider search to see if there are any more.

I missed the ones that @djelinski spotted. I rescanned `java.io` and don't see any others. Those two are fixed by 7868641a2c9558e66b51c40b49031095317c3a48.

-------------

PR: https://git.openjdk.org/jdk/pull/12505

From alanb at openjdk.org  Fri Feb 10 17:02:56 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 10 Feb 2023 17:02:56 GMT
Subject: RFR: 8301958: Reduce Arrays.copyOf/-Range overheads [v9]
In-Reply-To: <5cK3YK6OKgztMKSjd7gmp5ayTrlD9fzcsxTxjaJ1f40=.7b285e15-050e-4d2e-8479-e7b5b8cffcd9@github.com>
References: <2pdPoSHz2RJ7YDHOwOyszQMVv0v7FQFOwykfJ-za_e0=.cfe480da-a045-4b9a-bec7-7fffd0f47206@github.com>
 <5cK3YK6OKgztMKSjd7gmp5ayTrlD9fzcsxTxjaJ1f40=.7b285e15-050e-4d2e-8479-e7b5b8cffcd9@github.com>
Message-ID: <k9CjsNEerlyT0q-graZLXKTGsnqiDhWupy3-qD1pRWk=.31591def-5138-4f5a-b794-3231853d4bd8@github.com>

On Wed, 8 Feb 2023 10:53:22 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> This patch adds special-cases to `Arrays.copyOf` and `Arrays.copyOfRange` to copy arrays more efficiently when exactly the whole input array is to be copied. This helps eliminate range checks and has been verified to help various String operations. Example:
>> 
>> Baseline
>> 
>> Benchmark                                            (size)  Mode  Cnt   Score   Error  Units
>> StringConstructor.newStringFromArray                      7  avgt   15  16.817 ? 0.369  ns/op
>> StringConstructor.newStringFromArrayWithCharset           7  avgt   15  16.866 ? 0.449  ns/op
>> StringConstructor.newStringFromArrayWithCharsetName       7  avgt   15  22.198 ? 0.396  ns/op
>> 
>> Patch: 
>> 
>> Benchmark                                            (size)  Mode  Cnt   Score   Error  Units
>> StringConstructor.newStringFromArray                      7  avgt   15  14.666 ? 0.336  ns/op
>> StringConstructor.newStringFromArrayWithCharset           7  avgt   15  14.582 ? 0.288  ns/op
>> StringConstructor.newStringFromArrayWithCharsetName       7  avgt   15  20.339 ? 0.328  ns/op
>
> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add offset param to micro, reduce number of configurations and variants

The nudge from John and others to move this to Arrays.copyOf is much better. It looks good.

We may have to come back to the SB::toLength issue from the original proposal.

src/java.base/share/classes/java/util/Arrays.java line 29:

> 27: 
> 28: import jdk.internal.util.ArraysSupport;
> 29: import jdk.internal.util.Preconditions;

I don't think Preconditions is needed now.

src/java.base/share/classes/java/util/Arrays.java line 3909:

> 3907: 
> 3908:     @ForceInline
> 3909:     private static byte[] copyOfRangeGeneric(byte[] original, int from, int to) {

Maybe copyOfRange{Short,Int,Long,...} might be better than a "Generic" suffix.

-------------

Marked as reviewed by alanb (Reviewer).

PR: https://git.openjdk.org/jdk/pull/12453

From alanb at openjdk.org  Fri Feb 10 17:04:11 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 10 Feb 2023 17:04:11 GMT
Subject: RFR: 6595142: (spec) ByteArrayInputStream treats bytes,
 not characters [v2]
In-Reply-To: <OoGZNDpFTJ5OgcgwA2XQBLT9VCCGi25NEqtArGNPrN8=.9fc8d5cf-6f06-4b9f-b54a-2813ee619334@github.com>
References: <IvwxlmqkKQxgi2TFf0vsWOiMavibGRd1upe_P4DGx5I=.50fca19b-9450-4548-94bb-71e9ca323cb0@github.com>
 <OoGZNDpFTJ5OgcgwA2XQBLT9VCCGi25NEqtArGNPrN8=.9fc8d5cf-6f06-4b9f-b54a-2813ee619334@github.com>
Message-ID: <LMvorXC-Bz6XOjNLm4DXgl6cYa8Y7enymcQ5Cggpmvw=.cad617d0-b690-4b5c-bda5-aaeed4aac7c4@github.com>

On Fri, 10 Feb 2023 16:48:08 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Replace the two occurrences of `character` with `byte`.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   6595142: Refer to bytes, not characters in BufferedInputStream and SequenceInputStream

Marked as reviewed by alanb (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/12505

From rriggs at openjdk.org  Fri Feb 10 17:04:11 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 10 Feb 2023 17:04:11 GMT
Subject: RFR: 8301737:
 java/rmi/server/UnicastRemoteObject/serialFilter/FilterUROTest.java fail with
 -Xcomp [v5]
In-Reply-To: <LK2KMuqdCPMIELIX5aCwW_T8xQoZPF0j378ZfNG0pJQ=.a2b89691-508d-41f4-ba6d-ee4aebde3624@github.com>
References: <l5m5_9io2QMSFNY7dBHT3Nr2I9Er8wmd92Ze8FP-XE0=.a40d29be-77be-4719-a0a0-71d032eea1e5@github.com>
 <LK2KMuqdCPMIELIX5aCwW_T8xQoZPF0j378ZfNG0pJQ=.a2b89691-508d-41f4-ba6d-ee4aebde3624@github.com>
Message-ID: <JqZ3SHiQJnaU9FTpIAdo7lJ5Dwe-eplPYdAXTRAkMH0=.91554022-4b6a-451b-a705-62094ef0a01e@github.com>

On Fri, 10 Feb 2023 03:03:07 GMT, SUN Guoyun <duke at openjdk.org> wrote:

>> Hi all,
>> When -Xcomp be used, this testcase will use more codecaches, causing the GC to be triggered early, then causing this test failed on LoongArch64 architecture.
>> 
>> This PR fix the issue, Please help review it.
>> 
>> Thanks.
>
> SUN Guoyun has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - 8301737: java/rmi/server/UnicastRemoteObject/serialFilter/FilterUROTest.java fail with -Xcomp
>  - 8301737: java/rmi/server/UnicastRemoteObject/serialFilter/FilterUROTest.java fail with -Xcomp

LGTM

-------------

Marked as reviewed by rriggs (Reviewer).

PR: https://git.openjdk.org/jdk/pull/12399

From rriggs at openjdk.org  Fri Feb 10 17:04:14 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 10 Feb 2023 17:04:14 GMT
Subject: RFR: 8301737:
 java/rmi/server/UnicastRemoteObject/serialFilter/FilterUROTest.java fail with
 -Xcomp [v4]
In-Reply-To: <hSA4REOl1gTAfzJW90_Q2eXBMTeGBpNltHKh-32QNmM=.0b83f030-04e6-4e95-b6a6-dae0fd499477@github.com>
References: <l5m5_9io2QMSFNY7dBHT3Nr2I9Er8wmd92Ze8FP-XE0=.a40d29be-77be-4719-a0a0-71d032eea1e5@github.com>
 <LCJW-DKImXCmpxwBGKJPmSKAUnz9dHg-T09tqD9-SMU=.87d63cd0-6b22-4af8-9786-bd6c75d04ca2@github.com>
 <SOPGLzpZBUGbPSkPMAau9HBPyZqXmmSrMefI9to2QBs=.e12f920b-1709-47d4-bf2c-7f9000133193@github.com>
 <gTcBBWD-thGNqohbIKYbdoGMkFzU1qo-2UaWF9SNmX4=.c75d6fdf-0a12-45aa-84c2-0bdc016160f6@github.com>
 <hSA4REOl1gTAfzJW90_Q2eXBMTeGBpNltHKh-32QNmM=.0b83f030-04e6-4e95-b6a6-dae0fd499477@github.com>
Message-ID: <l9XuFEAacl2ckb8cGY0XWH89c0eWvuzfFceqrLueWhY=.a3f8a919-1669-420c-9981-150e97adbc4a@github.com>

On Fri, 10 Feb 2023 12:13:13 GMT, Mark Sheppard <msheppar at openjdk.org> wrote:

>> I just tested it and it really be OK, I'll submit a new commit.
>
> yes, this mitigates the issue within the test,  and alls good.
> BUT it still leave an open question as to why the behaviour of the test is different for the -Xcomp mode and the interpretative mode?
> I think it would be reasonable to expect both modes to behave the same. As such, that the compile mode should generate a fence or whatever to guarantee that the impl remain a strong reference until it goes out of scope at the end of the try block ?
> This is the case in non -Xcomp mode, but in -Xcomp the status of the impl reference is accelerate to to being unreachable and a candidate for garbage collection ?
> Is it not a hotspot compiler issue or the component area responsible for -Xcomp ?

@msheppar It depends on the timing of GC and the unpredictable interactions between the compiler and gc.
If gc is particularly aggressive (as may be stimulated by -Xcomp), it may determine that the impl is no longer referenced even though it seems to be in the middle of the method.

-------------

PR: https://git.openjdk.org/jdk/pull/12399

From jlaskey at openjdk.org  Fri Feb 10 17:07:24 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Fri, 10 Feb 2023 17:07:24 GMT
Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates
 (Preview) [v37]
In-Reply-To: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
Message-ID: <3Cffq9T2VOO7KsFUbANnyixAkxi4Ztlojk9voEvmF1I=.2ed8c2bf-e704-4661-9185-102ac3f15e7a@github.com>

> Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12).

Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:

  CSR review

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10889/files
  - new: https://git.openjdk.org/jdk/pull/10889/files/665cded9..8f5ad0a4

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=36
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=35-36

  Stats: 65 lines in 6 files changed: 55 ins; 0 del; 10 mod
  Patch: https://git.openjdk.org/jdk/pull/10889.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10889/head:pull/10889

PR: https://git.openjdk.org/jdk/pull/10889

From jlaskey at openjdk.org  Fri Feb 10 17:09:18 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Fri, 10 Feb 2023 17:09:18 GMT
Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates
 (Preview) [v38]
In-Reply-To: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
Message-ID: <eezyAvzaM0LdNnfM45CuWMrKf7UHrz2pihbMsQeGL3Q=.9ae6c576-ddcb-4129-ab33-2019ebbadbf3@github.com>

> Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12).

Jim Laskey has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 53 commits:

 - Merge branch 'master' into 8285932
 - CSR review
 - Bring up to date
 - Merge branch 'master' into 8285932
 - Update to JDK 21
 - Merge branch 'master' into 8285932
 - Merge branch 'master' into 8285932
 - FormatProcessor changes
 - Update @since
 - Requested changes #12
 - ... and 43 more: https://git.openjdk.org/jdk/compare/4539899c...5fab46c1

-------------

Changes: https://git.openjdk.org/jdk/pull/10889/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=37
  Stats: 9576 lines in 81 files changed: 9411 ins; 28 del; 137 mod
  Patch: https://git.openjdk.org/jdk/pull/10889.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10889/head:pull/10889

PR: https://git.openjdk.org/jdk/pull/10889

From bpb at openjdk.org  Fri Feb 10 17:13:12 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 10 Feb 2023 17:13:12 GMT
Subject: RFR: 8298619: java/io/File/GetXSpace.java is failing
In-Reply-To: <DTNziTj7KbkeG3LvpMREAi9WP9XRczQUdP_1-XTvp2c=.b9b78dec-3879-4626-9174-306e57ce83a4@github.com>
References: <6LnAAIclo5mZZgba4XUSTSc72vyNrBinzUlO9-kJXbU=.fe0c5e94-9e36-4484-b8e7-0f19cb10cb05@github.com>
 <DTNziTj7KbkeG3LvpMREAi9WP9XRczQUdP_1-XTvp2c=.b9b78dec-3879-4626-9174-306e57ce83a4@github.com>
Message-ID: <134wQrl9F4McK30DN1EvRTuqCx-WDMTgym1traoL8fI=.1247d3ff-0413-415a-9f3f-6a30b59f62d5@github.com>

On Fri, 10 Feb 2023 13:51:24 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> It seems a bit fragile to be parsing the output of `fsutil volume diskFree` as the output seems to vary by Windows releases and maybe configuration. So minimally, I think it should be changed to use ProcessTools so that the command and the output show up in the .jtr file.
> 
> In passing, you might want to choose a different method name to make it clearer what it does, maybe volumeDiskFree?

Another possibility would be to add a native method to the test itself to invoke [GetDiskSpaceInformationW](https://learn.microsoft.com/en-us/windows/win32/api/fileapi/nf-fileapi-getdiskspaceinformationw) to obtain the value of `CallerTotalAllocationUnits` (in bytes) from the [DISK_SPACE_INFORMATION](https://learn.microsoft.com/en-us/windows/win32/api/fileapi/ns-fileapi-disk_space_information) structure.

-------------

PR: https://git.openjdk.org/jdk/pull/12397

From mcimadamore at openjdk.org  Fri Feb 10 17:16:14 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 10 Feb 2023 17:16:14 GMT
Subject: RFR: 8294982: Implementation of Classfile API [v15]
In-Reply-To: <C-fd3WUG0sCiQVVFekGvM1JKgjN5PdkxmCIifWdrGFw=.7fb95367-0539-4b8b-98d4-2a50c5058e57@github.com>
References: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
 <hr8eti6ytvV05JFRr5hYLWy7yBla9mpI8vKKfaaFR-k=.a92f7bea-6400-4f95-a40c-d57192013f19@github.com>
 <hUvPqC4427nX8mcEcC5Tr90RFXAtmNigTxexY_Ujf04=.55b5e41d-afa7-4220-b13f-6fb0dd25dd0e@github.com>
 <C-fd3WUG0sCiQVVFekGvM1JKgjN5PdkxmCIifWdrGFw=.7fb95367-0539-4b8b-98d4-2a50c5058e57@github.com>
Message-ID: <EeI_pmAHhHpCjUqBJ_pf0Pof4Wb4VGa9sSu9K9yFwJI=.4b5f50be-50b9-44e3-8c90-04651d888571@github.com>

On Fri, 10 Feb 2023 11:12:25 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/classfile/constantpool/AnnotationConstantValueEntry.java line 33:
>> 
>>> 31:  * which includes the four kinds of primitive constants, and UTF8 constants.
>>> 32:  */
>>> 33: public sealed interface AnnotationConstantValueEntry extends PoolEntry
>> 
>> Should this extend LoadableConstantEntry (and restrict it more) ?
>
> `LoadableConstantEntry` and `AnnotationConstantValueEntry` are just partially overlapping according to the spec.
> The biggest difference (and source of confusion) is that `StringEntry` is `LoadableConstantEntry`, however not `AnnotationConstantValueEntry` and `Utf8Entry` is `AnnotationConstantValueEntry`, however not `LoadableConstantEntry`.

Ugh - you are right of course!

>> src/java.base/share/classes/jdk/internal/classfile/instruction/CharacterRange.java line 60:
>> 
>>> 58:      * viewed as an array of (possibly multi-byte) characters.
>>> 59:      */
>>> 60:     int characterRangeStart();
>> 
>> Not sure if this belongs here - e.g. it seems to me that `characterRangeStart` is less useful than the labels. But I'm not super expert on how this code element might be used.
>
> It is character range within the source code, not the bytecode.

I see - I was probably confusing myself (I wonder if the method names played some part in that)

-------------

PR: https://git.openjdk.org/jdk/pull/10982

From jlaskey at openjdk.org  Fri Feb 10 17:32:00 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Fri, 10 Feb 2023 17:32:00 GMT
Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates
 (Preview) [v39]
In-Reply-To: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
Message-ID: <tspvAWdHSt6tqlq1TtiLVEO2YywIAJaJWd19gMYsIm4=.6cf6fe32-6d09-46c9-af60-fb334f6cfdb7@github.com>

> Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12).

Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:

  Minor correction to javadoc

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10889/files
  - new: https://git.openjdk.org/jdk/pull/10889/files/5fab46c1..5a031bda

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=38
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=37-38

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/10889.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10889/head:pull/10889

PR: https://git.openjdk.org/jdk/pull/10889

From iklam at openjdk.org  Fri Feb 10 17:32:10 2023
From: iklam at openjdk.org (Ioi Lam)
Date: Fri, 10 Feb 2023 17:32:10 GMT
Subject: RFR: 8302154: Hidden classes created by LambdaMetaFactory can't be
 unloaded [v2]
In-Reply-To: <gKoLpwlXDxp2uaSKSkMArJl1Ym9VX1hoDFqQTTUpk8w=.e1dce669-5a42-4b66-ac4b-205718c8eb81@github.com>
References: <YoZauVv8zvhdUw-LD25LrsMDItFbg3aXPU3deXwwFdQ=.c2839dea-12e5-4e0e-9579-eac9d8503932@github.com>
 <gKoLpwlXDxp2uaSKSkMArJl1Ym9VX1hoDFqQTTUpk8w=.e1dce669-5a42-4b66-ac4b-205718c8eb81@github.com>
Message-ID: <jgxD2XApQjA92I_bzUejeTvyPjD6YWuVniri4LftYEQ=.5c3ff453-b8d0-4298-ae29-1602ac80e257@github.com>

On Thu, 9 Feb 2023 18:11:18 GMT, Volker Simonis <simonis at openjdk.org> wrote:

>> Prior to [JDK-8239384](https://bugs.openjdk.org/browse/JDK-8239384)/[JDK-8238358](https://bugs.openjdk.org/browse/JDK-8238358) LambdaMetaFactory has created VM-anonymous classes which could easily be unloaded once they were not referenced any more. Starting with JDK 15 and the new "hidden class" based implementation, this is not the case any more, because the hidden classes will be strongly tied to their defining class loader. If this is the default application class loader, these hidden classes can never be unloaded which can easily lead to Metaspace exhaustion (see the [test case in the JBS issue](https://bugs.openjdk.org/secure/attachment/102601/LambdaClassLeak.java)). This is a regression compared to previous JDK versions which some of our applications have been affected from when migrating to JDK 17.
>> 
>> The reason why the newly created hidden classes are strongly linked to their defining class loader is not clear to me. JDK-8239384 mentions it as an "implementation detail":
>> 
>>> *4. the lambda proxy class has the strong relationship with the class loader (that will share the VM metaspace for its defining loader - implementation details)*
>> 
>> From my current understanding the strong link between a hidden class created by `LambdaMetaFactory` and its defining class loader is not strictly required. In order to prevent potential OOMs and fix the regression compared the JDK 14 and earlier I propose to create these hidden classes without the `STRONG` option.
>> 
>> I'll be happy to add the test case as JTreg test to this PR if you think that would be useful.
>
> Volker Simonis has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Remove assertions which insist on Lambda proxy classes being strongly linked to their class loader
>  - Removed unused import of STRONG und updated copyright year

Even in JDK 11, a lambda proxy classes that's referenced by the cpCache (i.e., from a resolved invokedynamic instruction associated with a lamda expression) is always kept alive. See test below.

So if I understand correctly, this patch will not affect lamda expressions in Java source code. It affects only direct calls to `LambdaMetafactory.metafactory()`. Is this correct?


public class LambdaGC {
    public static void main(String[] args) throws Throwable  {
      System.out.println("Entering LambdaGC");
      doit(() -> {
          Thread.dumpStack();
      });
      for (int i = 0; i < 10; i++) {
            System.gc();
      }
      System.out.println("Finish LambdaGC");
    }
    static void doit(Runnable r) {
        r.run();
    }
}

$ java11 -cp . -XX:+UnlockDiagnosticVMOptions -XX:+ShowHiddenFrames -Xlog:class+load -Xlog:class+unload LambdaGC | grep LambdaGC
[0.022s][info][class,load] LambdaGC source: file:/jdk3/tmp/
Entering LambdaGC
[0.024s][info][class,load] LambdaGC$$Lambda$1/0x0000000840060840 source: LambdaGC
java.lang.Exception: Stack trace
	at java.base/java.lang.Thread.dumpStack(Thread.java:1387)
	at LambdaGC.lambda$main$0(LambdaGC.java:5)
	at LambdaGC$$Lambda$1/0x0000000840060840.run(<Unknown>:1000000)
	at LambdaGC.doit(LambdaGC.java:13)
	at LambdaGC.main(LambdaGC.java:4)
Finish LambdaGC

-------------

PR: https://git.openjdk.org/jdk/pull/12493

From bpb at openjdk.org  Fri Feb 10 17:38:51 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 10 Feb 2023 17:38:51 GMT
Subject: RFR: 8297632: InputStream.transferTo() method should specify what
 the return value should be when the number of bytes transfered is
 larger than Long.MAX_VALUE [v7]
In-Reply-To: <T38kO1hcz3rhpqOOPYmoPl1TlRORJBifQWtXLl10x8Y=.595338d3-df98-4202-95b5-eda88a4ed0a2@github.com>
References: <T38kO1hcz3rhpqOOPYmoPl1TlRORJBifQWtXLl10x8Y=.595338d3-df98-4202-95b5-eda88a4ed0a2@github.com>
Message-ID: <_9WmGHHPiqNaJ2l5vg1qvYvgj9rTKtnYYLt7Gi2x2uQ=.d56479a0-8948-4f76-9e7a-f9661766a281@github.com>

> `java.io.InputStream::transferTo` could conceivably return a negative value if the count of bytes transferred overflows a `long`. Modify the method to limit the number of bytes transferred to `Long.MAX_VALUE` per invocation.

Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:

  8297632: Align SequenceInputStream style with other changes in patch

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/11403/files
  - new: https://git.openjdk.org/jdk/pull/11403/files/b1cd84ec..6bdf3220

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11403&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11403&range=05-06

  Stats: 8 lines in 1 file changed: 2 ins; 0 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/11403.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11403/head:pull/11403

PR: https://git.openjdk.org/jdk/pull/11403

From bpb at openjdk.org  Fri Feb 10 17:38:55 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 10 Feb 2023 17:38:55 GMT
Subject: RFR: 8297632: InputStream.transferTo() method should specify what
 the return value should be when the number of bytes transfered is
 larger than Long.MAX_VALUE [v6]
In-Reply-To: <Lh5xk1qRWDH_xuolhow6Oxea_uwmdnZnz6fELZGtcb0=.71a32cb4-a882-426c-90cb-a09e835a82a5@github.com>
References: <T38kO1hcz3rhpqOOPYmoPl1TlRORJBifQWtXLl10x8Y=.595338d3-df98-4202-95b5-eda88a4ed0a2@github.com>
 <v_KgToOO76ZvAmeGRMZ03QVLzO13iXAQZ6DGFSyfpA0=.c3aa2d43-3019-40d4-baf0-033a20c98bc4@github.com>
 <Lh5xk1qRWDH_xuolhow6Oxea_uwmdnZnz6fELZGtcb0=.71a32cb4-a882-426c-90cb-a09e835a82a5@github.com>
Message-ID: <C12spn86JV9kNvyjHlphxHKwXNexL70-9qVR2ikPboc=.38f62eca-6031-4216-9c78-4b1b56508a5b@github.com>

On Fri, 10 Feb 2023 13:25:29 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8297632: Increment recent copyright year to 2023
>
> src/java.base/share/classes/java/io/SequenceInputStream.java line 249:
> 
>> 247:                 } catch (ArithmeticException ignore) {
>> 248:                     return Long.MAX_VALUE;
>> 249:                 }
> 
> This one could check if c < Long.MAX_VALUE like the other implementations, if only for consistency. c could be renamed to transferred too.

So changed in 6bdf3220c70e120e8dad552e177dc80f34495c73.

-------------

PR: https://git.openjdk.org/jdk/pull/11403

From alanb at openjdk.org  Fri Feb 10 17:44:45 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 10 Feb 2023 17:44:45 GMT
Subject: RFR: 8297632: InputStream.transferTo() method should specify what
 the return value should be when the number of bytes transfered is
 larger than Long.MAX_VALUE [v7]
In-Reply-To: <_9WmGHHPiqNaJ2l5vg1qvYvgj9rTKtnYYLt7Gi2x2uQ=.d56479a0-8948-4f76-9e7a-f9661766a281@github.com>
References: <T38kO1hcz3rhpqOOPYmoPl1TlRORJBifQWtXLl10x8Y=.595338d3-df98-4202-95b5-eda88a4ed0a2@github.com>
 <_9WmGHHPiqNaJ2l5vg1qvYvgj9rTKtnYYLt7Gi2x2uQ=.d56479a0-8948-4f76-9e7a-f9661766a281@github.com>
Message-ID: <DkxPNzKp40zIp0HKo8BGvE7IFexn5fdlF66ROc7szbI=.38c27ac1-d28d-4942-8e6e-22ba2a38f668@github.com>

On Fri, 10 Feb 2023 17:38:51 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> `java.io.InputStream::transferTo` could conceivably return a negative value if the count of bytes transferred overflows a `long`. Modify the method to limit the number of bytes transferred to `Long.MAX_VALUE` per invocation.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8297632: Align SequenceInputStream style with other changes in patch

Marked as reviewed by alanb (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/11403

From msheppar at openjdk.org  Fri Feb 10 17:53:46 2023
From: msheppar at openjdk.org (Mark Sheppard)
Date: Fri, 10 Feb 2023 17:53:46 GMT
Subject: RFR: 8301737:
 java/rmi/server/UnicastRemoteObject/serialFilter/FilterUROTest.java fail with
 -Xcomp [v4]
In-Reply-To: <l9XuFEAacl2ckb8cGY0XWH89c0eWvuzfFceqrLueWhY=.a3f8a919-1669-420c-9981-150e97adbc4a@github.com>
References: <l5m5_9io2QMSFNY7dBHT3Nr2I9Er8wmd92Ze8FP-XE0=.a40d29be-77be-4719-a0a0-71d032eea1e5@github.com>
 <LCJW-DKImXCmpxwBGKJPmSKAUnz9dHg-T09tqD9-SMU=.87d63cd0-6b22-4af8-9786-bd6c75d04ca2@github.com>
 <SOPGLzpZBUGbPSkPMAau9HBPyZqXmmSrMefI9to2QBs=.e12f920b-1709-47d4-bf2c-7f9000133193@github.com>
 <gTcBBWD-thGNqohbIKYbdoGMkFzU1qo-2UaWF9SNmX4=.c75d6fdf-0a12-45aa-84c2-0bdc016160f6@github.com>
 <hSA4REOl1gTAfzJW90_Q2eXBMTeGBpNltHKh-32QNmM=.0b83f030-04e6-4e95-b6a6-dae0fd499477@github.com>
 <l9XuFEAacl2ckb8cGY0XWH89c0eWvuzfFceqrLueWhY=.a3f8a919-1669-420c-9981-150e97adbc4a@github.com>
Message-ID: <olhtDpBVprqLYlQTeMIzvP6WXvwn2fPovBHIAjG0heM=.d49ec530-68bb-4e6d-af51-130e4ea7cfa7@github.com>

On Fri, 10 Feb 2023 17:00:47 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> yes, this mitigates the issue within the test,  and alls good.
>> BUT it still leave an open question as to why the behaviour of the test is different for the -Xcomp mode and the interpretative mode?
>> I think it would be reasonable to expect both modes to behave the same. As such, that the compile mode should generate a fence or whatever to guarantee that the impl remain a strong reference until it goes out of scope at the end of the try block ?
>> This is the case in non -Xcomp mode, but in -Xcomp the status of the impl reference is accelerate to to being unreachable and a candidate for garbage collection ?
>> Is it not a hotspot compiler issue or the component area responsible for -Xcomp ?
>
> @msheppar It depends on the timing of GC and the unpredictable interactions between the compiler and gc.
> If gc is particularly aggressive (as may be stimulated by -Xcomp), it may determine that the impl is no longer referenced even though it seems to be in the middle of the method.

Would this behaviour be covered by the JLS and JVM specs ?

-------------

PR: https://git.openjdk.org/jdk/pull/12399

From lujaniuk at openjdk.org  Fri Feb 10 18:26:23 2023
From: lujaniuk at openjdk.org (Ludvig Janiuk)
Date: Fri, 10 Feb 2023 18:26:23 GMT
Subject: RFR: 8302226 failure_handler native.core should wait for coredump to
 finish on linux
Message-ID: <5k6enBnRlLOZsW9Dp3NWLwiw-JeURwl-9omJht157vY=.dc8401f6-5b3d-4997-aee2-0003b1a01ab9@github.com>

Update open/test/failure_handler/src/share/conf/linux.properties to handle core dumps more correctly.

-------------

Commit messages:
 - 8302226 failure_handler native.core should wait for coredump to finish on linux

Changes: https://git.openjdk.org/jdk/pull/12515/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12515&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8302226
  Stats: 5 lines in 1 file changed: 3 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/12515.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12515/head:pull/12515

PR: https://git.openjdk.org/jdk/pull/12515

From jbhateja at openjdk.org  Fri Feb 10 18:32:46 2023
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Fri, 10 Feb 2023 18:32:46 GMT
Subject: RFR: JDK-8300808: Accelerate Base64 on x86 for AVX2 [v15]
In-Reply-To: <TmYLe9RCiAqtfuyjU77R-faEEVpfmmUoQ89oyBCcEmM=.c6d2d68b-c37d-4c78-a8e4-af4b48df91a5@github.com>
References: <9zN3bjyMEikXYOlpjTy9_QPc-9usYiBJMUFdb-TaVrQ=.e8f65ce9-ac0f-4f8d-9c6b-b39ae1c26cd2@github.com>
 <TmYLe9RCiAqtfuyjU77R-faEEVpfmmUoQ89oyBCcEmM=.c6d2d68b-c37d-4c78-a8e4-af4b48df91a5@github.com>
Message-ID: <EYs8DMENVm7TBmxl2JWR2smkXGbFw1c9YH1YSP5409w=.751146cd-a54d-4e08-92e2-f9814ce3f132@github.com>

On Thu, 9 Feb 2023 18:08:15 GMT, Scott Gibbons <duke at openjdk.org> wrote:

>> Added code for Base64 acceleration (encode and decode) which will accelerate ~4x for AVX2 platforms.
>> 
>> Encode performance:
>> **Old:**
>> 
>> Benchmark                      (maxNumBytes)   Mode  Cnt     Score   Error   Units
>> Base64Encode.testBase64Encode           1024  thrpt    3  4309.439 ? 2.632  ops/ms
>> 
>> 
>> **New:**
>> 
>> Benchmark                      (maxNumBytes)   Mode  Cnt      Score     Error   Units
>> Base64Encode.testBase64Encode           1024  thrpt    3  24211.397 ? 102.026  ops/ms
>> 
>> 
>> Decode performance:
>> **Old:**
>> 
>> Benchmark                      (errorIndex)  (lineSize)  (maxNumBytes)   Mode  Cnt     Score    Error   Units
>> Base64Decode.testBase64Decode           144           4           1024  thrpt    3  3961.768 ? 93.409  ops/ms
>> 
>> **New:**
>> Benchmark                      (errorIndex)  (lineSize)  (maxNumBytes)   Mode  Cnt      Score    Error   Units
>> Base64Decode.testBase64Decode           144           4           1024  thrpt    3  14738.051 ? 24.383  ops/ms
>
> Scott Gibbons has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add URL to microbenchmark

Thanks @asgibbons.

-------------

Marked as reviewed by jbhateja (Reviewer).

PR: https://git.openjdk.org/jdk/pull/12126

From duke at openjdk.org  Fri Feb 10 18:42:55 2023
From: duke at openjdk.org (duke)
Date: Fri, 10 Feb 2023 18:42:55 GMT
Subject: Withdrawn: 8298638: Cleanup of unix java_md.c for better re-exec
 handling
In-Reply-To: <UqitH23_LetW3nTGVU_7m5SxPsrpMojdrdYOOnWeZFI=.bc783eec-1c8d-4b80-9ef4-d92cb4131825@github.com>
References: <UqitH23_LetW3nTGVU_7m5SxPsrpMojdrdYOOnWeZFI=.bc783eec-1c8d-4b80-9ef4-d92cb4131825@github.com>
Message-ID: <n4v5wQcKAOV9wvzo-H0mRGcVLizRRH_VPZ4cuOjldIs=.c638745f-84cf-4acf-b4b8-44aff70ac414@github.com>

On Tue, 13 Dec 2022 09:32:11 GMT, Dmitry Samersoff <dsamersoff at openjdk.org> wrote:

> Move "unix" java_md.c cleanup, which is the prerequisites for the fix for JDK-8293806 (PR https://github.com/openjdk/jdk/pull/11538), to a separate PR.
> 
> @AlanBateman, @dholmes-ora please, take a look to the changes.

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/11645

From mchung at openjdk.org  Fri Feb 10 19:03:45 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Fri, 10 Feb 2023 19:03:45 GMT
Subject: RFR: 8302154: Hidden classes created by LambdaMetaFactory can't be
 unloaded [v2]
In-Reply-To: <jgxD2XApQjA92I_bzUejeTvyPjD6YWuVniri4LftYEQ=.5c3ff453-b8d0-4298-ae29-1602ac80e257@github.com>
References: <YoZauVv8zvhdUw-LD25LrsMDItFbg3aXPU3deXwwFdQ=.c2839dea-12e5-4e0e-9579-eac9d8503932@github.com>
 <gKoLpwlXDxp2uaSKSkMArJl1Ym9VX1hoDFqQTTUpk8w=.e1dce669-5a42-4b66-ac4b-205718c8eb81@github.com>
 <jgxD2XApQjA92I_bzUejeTvyPjD6YWuVniri4LftYEQ=.5c3ff453-b8d0-4298-ae29-1602ac80e257@github.com>
Message-ID: <6ILJ5r3w184aCx2hNc7k-khRUpF6tgzmjAr6mubrXfk=.90bda6f0-274e-4631-be22-503e5c954ff6@github.com>

On Fri, 10 Feb 2023 17:29:37 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> Even in JDK 11, a lambda proxy classes that's referenced by the cpCache (i.e., from a resolved invokedynamic instruction associated with a lamda expression) is always kept alive. 

Thanks @iklam.   That's exactly what I am trying to confirm.

-------------

PR: https://git.openjdk.org/jdk/pull/12493

From simonis at openjdk.org  Fri Feb 10 19:03:47 2023
From: simonis at openjdk.org (Volker Simonis)
Date: Fri, 10 Feb 2023 19:03:47 GMT
Subject: RFR: 8302154: Hidden classes created by LambdaMetaFactory can't be
 unloaded [v2]
In-Reply-To: <jgxD2XApQjA92I_bzUejeTvyPjD6YWuVniri4LftYEQ=.5c3ff453-b8d0-4298-ae29-1602ac80e257@github.com>
References: <YoZauVv8zvhdUw-LD25LrsMDItFbg3aXPU3deXwwFdQ=.c2839dea-12e5-4e0e-9579-eac9d8503932@github.com>
 <gKoLpwlXDxp2uaSKSkMArJl1Ym9VX1hoDFqQTTUpk8w=.e1dce669-5a42-4b66-ac4b-205718c8eb81@github.com>
 <jgxD2XApQjA92I_bzUejeTvyPjD6YWuVniri4LftYEQ=.5c3ff453-b8d0-4298-ae29-1602ac80e257@github.com>
Message-ID: <80S5iALXtwJyXDKAqu3ecLSY3FePCHYr_Vez_uoRs4Y=.c0256514-454b-4744-98f2-9d9106e981c4@github.com>

On Fri, 10 Feb 2023 17:29:37 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> Volker Simonis has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Remove assertions which insist on Lambda proxy classes being strongly linked to their class loader
>>  - Removed unused import of STRONG und updated copyright year
>
> Even in JDK 11, a lambda proxy classes that's referenced by the cpCache (i.e., from a resolved invokedynamic instruction associated with a lamda expression) is always kept alive. See test below.
> 
> So if I understand correctly, this patch will not affect lamda expressions in Java source code. It affects only direct calls to `LambdaMetafactory.metafactory()`. Is this correct?
> 
> 
> public class LambdaGC {
>     public static void main(String[] args) throws Throwable  {
>       System.out.println("Entering LambdaGC");
>       doit(() -> {
>           Thread.dumpStack();
>       });
>       for (int i = 0; i < 10; i++) {
>             System.gc();
>       }
>       System.out.println("Finish LambdaGC");
>     }
>     static void doit(Runnable r) {
>         r.run();
>     }
> }
> 
> $ java11 -cp . -XX:+UnlockDiagnosticVMOptions -XX:+ShowHiddenFrames -Xlog:class+load -Xlog:class+unload LambdaGC | grep LambdaGC
> [0.022s][info][class,load] LambdaGC source: file:/jdk3/tmp/
> Entering LambdaGC
> [0.024s][info][class,load] LambdaGC$$Lambda$1/0x0000000840060840 source: LambdaGC
> java.lang.Exception: Stack trace
> 	at java.base/java.lang.Thread.dumpStack(Thread.java:1387)
> 	at LambdaGC.lambda$main$0(LambdaGC.java:5)
> 	at LambdaGC$$Lambda$1/0x0000000840060840.run(<Unknown>:1000000)
> 	at LambdaGC.doit(LambdaGC.java:13)
> 	at LambdaGC.main(LambdaGC.java:4)
> Finish LambdaGC

@iklam, I think your understanding is correct. While the bootstrap methods for Java Lambdas do call `LambdaMetafactory.metafactory()`, they store the resulting call site (for Lambdas a `BoundMethodHandle`) in the appendix slot of the constant pool cache entry of the invokedynamic bytecode. The `BoundMethodHandle` contains a reference to an instance of the generated lambda form (i.e. in your example `LambdaGC$$Lambda$1`). This is enough in order to keep `LambdaGC$$Lambda$1` alive and prevent its unloading.

Until now, `LambdaGC$$Lambda$1` was also strongly linked to its defining class loader, but I don't think that's necessary to keep it alive (because it is referenced from the call site which is referenced from the constant pool cache).

Running your example with `-Xlog:indy+methodhandles=debug` confirms this:

set_method_handle bc=186 appendix=0x000000062b821838 method=0x00000008000c7698 (local signature)
{method}
 - this oop:          0x00000008000c7698
 - method holder:     'java/lang/invoke/Invokers$Holder'
 ...
appendix: java.lang.invoke.BoundMethodHandle$Species_L 
 {0x000000062b821838} - klass: 'java/lang/invoke/BoundMethodHandle$Species_L'
  - ---- fields (total size 5 words):
  ...
  - final 'argL0' 'Ljava/lang/Object;' @32  a 'LambdaGC$$Lambda$1+0x0000000801000400'{0x000000062b81e080} (0xc5703c10)

-------------

PR: https://git.openjdk.org/jdk/pull/12493

From mchung at openjdk.org  Fri Feb 10 19:29:47 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Fri, 10 Feb 2023 19:29:47 GMT
Subject: RFR: 8302154: Hidden classes created by LambdaMetaFactory can't be
 unloaded [v2]
In-Reply-To: <80S5iALXtwJyXDKAqu3ecLSY3FePCHYr_Vez_uoRs4Y=.c0256514-454b-4744-98f2-9d9106e981c4@github.com>
References: <YoZauVv8zvhdUw-LD25LrsMDItFbg3aXPU3deXwwFdQ=.c2839dea-12e5-4e0e-9579-eac9d8503932@github.com>
 <gKoLpwlXDxp2uaSKSkMArJl1Ym9VX1hoDFqQTTUpk8w=.e1dce669-5a42-4b66-ac4b-205718c8eb81@github.com>
 <jgxD2XApQjA92I_bzUejeTvyPjD6YWuVniri4LftYEQ=.5c3ff453-b8d0-4298-ae29-1602ac80e257@github.com>
 <80S5iALXtwJyXDKAqu3ecLSY3FePCHYr_Vez_uoRs4Y=.c0256514-454b-4744-98f2-9d9106e981c4@github.com>
Message-ID: <QNncaw_ixhvpmtI0dj5U_qZZHX7WnzXC7mvjHBb6tS8=.e97ae1e4-63fb-4ddb-9982-4972d2b45892@github.com>

On Fri, 10 Feb 2023 19:00:53 GMT, Volker Simonis <simonis at openjdk.org> wrote:

> LambdaGC$$Lambda$1 was also strongly linked to its defining class loader, but I don't think that's necessary to keep it alive (because it is referenced from the call site which is referenced from the constant pool cache).

True but it was decided at that time for JEP 371 to make it strong so that the lambda proxy classes will share the same `ClassLoaderData` metaspace as other classes defined by the same loader.   This reduces the memory footprint consumption.

The question is:  what are the use cases for direct call to `LambdaMetafactory` that existing applications depend on?

-------------

PR: https://git.openjdk.org/jdk/pull/12493

From bpb at openjdk.org  Fri Feb 10 19:46:53 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 10 Feb 2023 19:46:53 GMT
Subject: Integrated: 6595142: (spec) ByteArrayInputStream treats bytes,
 not characters
In-Reply-To: <IvwxlmqkKQxgi2TFf0vsWOiMavibGRd1upe_P4DGx5I=.50fca19b-9450-4548-94bb-71e9ca323cb0@github.com>
References: <IvwxlmqkKQxgi2TFf0vsWOiMavibGRd1upe_P4DGx5I=.50fca19b-9450-4548-94bb-71e9ca323cb0@github.com>
Message-ID: <dN86vW7Xm7XT1Ku4sB1ssWz1Lt8BcJ6fBvw9s6rzTz4=.799c968b-3669-4b23-b269-40478552f595@github.com>

On Fri, 10 Feb 2023 02:11:35 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Replace the two occurrences of `character` with `byte`.

This pull request has now been integrated.

Changeset: 57798dd4
Author:    Brian Burkhalter <bpb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/57798dd4394cea14ac64fc839b81e9e5bae0a80e
Stats:     7 lines in 3 files changed: 0 ins; 0 del; 7 mod

6595142: (spec) ByteArrayInputStream treats bytes, not characters

Reviewed-by: alanb

-------------

PR: https://git.openjdk.org/jdk/pull/12505

From rriggs at openjdk.org  Fri Feb 10 20:20:46 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 10 Feb 2023 20:20:46 GMT
Subject: RFR: 8301737:
 java/rmi/server/UnicastRemoteObject/serialFilter/FilterUROTest.java fail with
 -Xcomp [v4]
In-Reply-To: <olhtDpBVprqLYlQTeMIzvP6WXvwn2fPovBHIAjG0heM=.d49ec530-68bb-4e6d-af51-130e4ea7cfa7@github.com>
References: <l5m5_9io2QMSFNY7dBHT3Nr2I9Er8wmd92Ze8FP-XE0=.a40d29be-77be-4719-a0a0-71d032eea1e5@github.com>
 <LCJW-DKImXCmpxwBGKJPmSKAUnz9dHg-T09tqD9-SMU=.87d63cd0-6b22-4af8-9786-bd6c75d04ca2@github.com>
 <SOPGLzpZBUGbPSkPMAau9HBPyZqXmmSrMefI9to2QBs=.e12f920b-1709-47d4-bf2c-7f9000133193@github.com>
 <gTcBBWD-thGNqohbIKYbdoGMkFzU1qo-2UaWF9SNmX4=.c75d6fdf-0a12-45aa-84c2-0bdc016160f6@github.com>
 <hSA4REOl1gTAfzJW90_Q2eXBMTeGBpNltHKh-32QNmM=.0b83f030-04e6-4e95-b6a6-dae0fd499477@github.com>
 <l9XuFEAacl2ckb8cGY0XWH89c0eWvuzfFceqrLueWhY=.a3f8a919-1669-420c-9981-150e97adbc4a@github.com>
 <olhtDpBVprqLYlQTeMIzvP6WXvwn2fPovBHIAjG0heM=.d49ec530-68bb-4e6d-af51-130e4ea7cfa7@github.com>
Message-ID: <AJfgio9g2UGsd_bqWMv_KxU0MvaluEBNYzd-QNqc2Bo=.d50d3098-3afa-43c8-a75b-a3221cdf49e0@github.com>

On Fri, 10 Feb 2023 17:50:40 GMT, Mark Sheppard <msheppar at openjdk.org> wrote:

>> @msheppar It depends on the timing of GC and the unpredictable interactions between the compiler and gc.
>> If gc is particularly aggressive (as may be stimulated by -Xcomp), it may determine that the impl is no longer referenced even though it seems to be in the middle of the method.
>
> Would this behaviour be covered by the JLS and JVM specs ?

The JLS and JVMS specs do not constrain the implementation of GC.
The reachabilityFence() was introduced in JDK 9 by https://bugs.openjdk.org/browse/JDK-8133348.

-------------

PR: https://git.openjdk.org/jdk/pull/12399

From rriggs at openjdk.org  Fri Feb 10 21:21:01 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 10 Feb 2023 21:21:01 GMT
Subject: RFR: 8301627: System.exit and Runtime.exit debug logging
Message-ID: <OzJeJH5yxolKPChcUisqtzGYF_MU3oOJdx6HPhsXjBw=.15eefe39-efe1-433e-a6ac-02b4a730f264@github.com>

It can be difficult to find the cause of calls to `java.lang.System.exit(status)` and `Runtime.exit(status)` because the Java runtime exits.
The status value and stack trace are logged using the System Logger named `java.lang.Runtime` with message level `System.Logger.Level.DEBUG`.

-------------

Commit messages:
 - Locate the System logger before taking the shutdown lock
 - Add logging of calls to Runtime.exit to the system logger "java.lang.Runtime".

Changes: https://git.openjdk.org/jdk/pull/12517/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12517&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8301627
  Stats: 139 lines in 4 files changed: 139 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/12517.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12517/head:pull/12517

PR: https://git.openjdk.org/jdk/pull/12517

From rriggs at openjdk.org  Fri Feb 10 21:21:29 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 10 Feb 2023 21:21:29 GMT
Subject: RFR: 8301552: Use AtomicReferenceArray for caching instead of CHM
 in ZoneOffset [v8]
In-Reply-To: <ESUpuSgjM_9ocUr1O_7tjY-Pf2sps17BX69XpDtwoEg=.c93d0dbb-372f-4827-8239-cca058a8bf48@github.com>
References: <b228oWPoEJf0lfGgIVXwmo1mATeKWRTivuJ2PbgwAmI=.465a4f9b-7a4b-4bbb-9f94-66d1d889a072@github.com>
 <ESUpuSgjM_9ocUr1O_7tjY-Pf2sps17BX69XpDtwoEg=.c93d0dbb-372f-4827-8239-cca058a8bf48@github.com>
Message-ID: <w4WE_O-wVPplgXgj6hKwPedR7OAMqvjN1mqORLTB4wE=.73d2df75-4216-4128-9db1-d08b4bd9c6a9@github.com>

On Thu, 9 Feb 2023 13:46:14 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> `ZoneOffset` instances are cached by the `ZoneOffset` class itself for values in the range [-18h, 18h] for each second that is on an even quarter of an hour (i.e. at most 2*18*4+1 = 145 values). 
>> 
>> Instead of using a `ConcurrentHashMap` for caching instanced, we could instead use an `AtomicReferenceArray` with direct slot value access for said even seconds. This will improve performance and reduce the number of object even though the backing array will go from an initial 32 in the CHM to an initial/final 145 in the ARA. The CHM will contain much more objects and array slots for typical numbers of entries in the cache and will compute hash/bucket/collision on the hot code path for each cache access.
>
> Per Minborg has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Remove unused setup method
>  - Rename method in test
>  - Add copyright header

Another musing related to ZoneOffset; it would be desirable if ZoneOffset was a value class (forward looking to the Valhalla project) for performance reasons, meaning immutable and without identity.
Currently, it is "value-based", intending to be immutable, but it has a mutable field that caches the ZoneRules.
At some point, it may be desirable to refactor the implementation to avoid the mutable field.

-------------

PR: https://git.openjdk.org/jdk/pull/12346

From darcy at openjdk.org  Fri Feb 10 21:54:07 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 10 Feb 2023 21:54:07 GMT
Subject: RFR: JDK-8301833: Add manual tests for FDLIBM porting [v2]
In-Reply-To: <wgghXoOC-eICroAklhQSO8UYEBvYHF_QHZ4C_1wnW0Q=.61574f1b-9c40-4c34-b234-502b95a99c8f@github.com>
References: <wgghXoOC-eICroAklhQSO8UYEBvYHF_QHZ4C_1wnW0Q=.61574f1b-9c40-4c34-b234-502b95a99c8f@github.com>
Message-ID: <yKirJxDRbP_0EUoMcUwJKbt-7D3UpZgy60to8E66h9c=.6ba1c2c0-aeec-48b7-87b1-96f01ba5607c@github.com>

> To help add assurances that the main-line port of FDLIBM to Java is working correctly, added some long-running manual tests to probe that the transliteration port and the corresponding StrictMath method are in agreement on a large number of argument, say, all float values.
> 
> To test the transliteration port, this test can be run against a build where the JDK has *not* had the FDLIBM code used for StrictMath ported to Java.

Joe Darcy 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:

 - Update test.
 - Merge branch 'master' into JDK-8301833
 - Added trailing line terminator.
 - JDK-8301833: Add manual tests for FDLIBM porting

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12430/files
  - new: https://git.openjdk.org/jdk/pull/12430/files/af25e0b7..89c4c658

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12430&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12430&range=00-01

  Stats: 13880 lines in 599 files changed: 8344 ins; 1200 del; 4336 mod
  Patch: https://git.openjdk.org/jdk/pull/12430.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12430/head:pull/12430

PR: https://git.openjdk.org/jdk/pull/12430

From darcy at openjdk.org  Fri Feb 10 22:04:47 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 10 Feb 2023 22:04:47 GMT
Subject: RFR: JDK-8301833: Add manual tests for FDLIBM porting [v2]
In-Reply-To: <yKirJxDRbP_0EUoMcUwJKbt-7D3UpZgy60to8E66h9c=.6ba1c2c0-aeec-48b7-87b1-96f01ba5607c@github.com>
References: <wgghXoOC-eICroAklhQSO8UYEBvYHF_QHZ4C_1wnW0Q=.61574f1b-9c40-4c34-b234-502b95a99c8f@github.com>
 <yKirJxDRbP_0EUoMcUwJKbt-7D3UpZgy60to8E66h9c=.6ba1c2c0-aeec-48b7-87b1-96f01ba5607c@github.com>
Message-ID: <-W8zxL498_J5a8SegcPKhi0YD2jUtM5VubnQWFhp4G8=.2283fad4-57aa-48b7-871d-b769e8ce1c91@github.com>

On Fri, 10 Feb 2023 21:54:07 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> To help add assurances that the main-line port of FDLIBM to Java is working correctly, added some long-running manual tests to probe that the transliteration port and the corresponding StrictMath method are in agreement on a large number of argument, say, all float values.
>> 
>> To test the transliteration port, this test can be run against a build where the JDK has *not* had the FDLIBM code used for StrictMath ported to Java.
>
> Joe Darcy 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:
> 
>  - Update test.
>  - Merge branch 'master' into JDK-8301833
>  - Added trailing line terminator.
>  - JDK-8301833: Add manual tests for FDLIBM porting

Changed to the tests to by default just check every 1024th float value, which puts running the test into the usual tier 1 test time guidelines. Dedicated math library work can temporarily dial up the testing density for particular efforts.

-------------

PR: https://git.openjdk.org/jdk/pull/12430

From forax at univ-mlv.fr  Fri Feb 10 22:18:47 2023
From: forax at univ-mlv.fr (Remi Forax)
Date: Fri, 10 Feb 2023 23:18:47 +0100 (CET)
Subject: RFR: 8302154: Hidden classes created by LambdaMetaFactory can't
 be unloaded [v2]
In-Reply-To: <80S5iALXtwJyXDKAqu3ecLSY3FePCHYr_Vez_uoRs4Y=.c0256514-454b-4744-98f2-9d9106e981c4@github.com>
References: <YoZauVv8zvhdUw-LD25LrsMDItFbg3aXPU3deXwwFdQ=.c2839dea-12e5-4e0e-9579-eac9d8503932@github.com>
 <gKoLpwlXDxp2uaSKSkMArJl1Ym9VX1hoDFqQTTUpk8w=.e1dce669-5a42-4b66-ac4b-205718c8eb81@github.com>
 <jgxD2XApQjA92I_bzUejeTvyPjD6YWuVniri4LftYEQ=.5c3ff453-b8d0-4298-ae29-1602ac80e257@github.com>
 <80S5iALXtwJyXDKAqu3ecLSY3FePCHYr_Vez_uoRs4Y=.c0256514-454b-4744-98f2-9d9106e981c4@github.com>
Message-ID: <1628065858.20125180.1676067527849.JavaMail.zimbra@u-pem.fr>

----- Original Message -----
> From: "Volker Simonis" <simonis at openjdk.org>
> To: "core-libs-dev" <core-libs-dev at openjdk.org>, "hotspot-dev" <hotspot-dev at openjdk.org>
> Sent: Friday, February 10, 2023 8:03:47 PM
> Subject: Re: RFR: 8302154: Hidden classes created by LambdaMetaFactory can't be unloaded [v2]

> On Fri, 10 Feb 2023 17:29:37 GMT, Ioi Lam <iklam at openjdk.org> wrote:
> 
>>> Volker Simonis has updated the pull request incrementally with two additional
>>> commits since the last revision:
>>> 
>>>  - Remove assertions which insist on Lambda proxy classes being strongly linked
>>>  to their class loader
>>>  - Removed unused import of STRONG und updated copyright year
>>
>> Even in JDK 11, a lambda proxy classes that's referenced by the cpCache (i.e.,
>> from a resolved invokedynamic instruction associated with a lamda expression)
>> is always kept alive. See test below.
>> 
>> So if I understand correctly, this patch will not affect lamda expressions in
>> Java source code. It affects only direct calls to
>> `LambdaMetafactory.metafactory()`. Is this correct?
>> 
>> 
>> public class LambdaGC {
>>     public static void main(String[] args) throws Throwable  {
>>       System.out.println("Entering LambdaGC");
>>       doit(() -> {
>>           Thread.dumpStack();
>>       });
>>       for (int i = 0; i < 10; i++) {
>>             System.gc();
>>       }
>>       System.out.println("Finish LambdaGC");
>>     }
>>     static void doit(Runnable r) {
>>         r.run();
>>     }
>> }
>> 
>> $ java11 -cp . -XX:+UnlockDiagnosticVMOptions -XX:+ShowHiddenFrames
>> -Xlog:class+load -Xlog:class+unload LambdaGC | grep LambdaGC
>> [0.022s][info][class,load] LambdaGC source: file:/jdk3/tmp/
>> Entering LambdaGC
>> [0.024s][info][class,load] LambdaGC$$Lambda$1/0x0000000840060840 source:
>> LambdaGC
>> java.lang.Exception: Stack trace
>> 	at java.base/java.lang.Thread.dumpStack(Thread.java:1387)
>> 	at LambdaGC.lambda$main$0(LambdaGC.java:5)
>> 	at LambdaGC$$Lambda$1/0x0000000840060840.run(<Unknown>:1000000)
>> 	at LambdaGC.doit(LambdaGC.java:13)
>> 	at LambdaGC.main(LambdaGC.java:4)
>> Finish LambdaGC
> 
> @iklam, I think your understanding is correct. While the bootstrap methods for
> Java Lambdas do call `LambdaMetafactory.metafactory()`, they store the
> resulting call site (for Lambdas a `BoundMethodHandle`) in the appendix slot of
> the constant pool cache entry of the invokedynamic bytecode. The
> `BoundMethodHandle` contains a reference to an instance of the generated lambda
> form (i.e. in your example `LambdaGC$$Lambda$1`). This is enough in order to
> keep `LambdaGC$$Lambda$1` alive and prevent its unloading.
> 
> Until now, `LambdaGC$$Lambda$1` was also strongly linked to its defining class
> loader, but I don't think that's necessary to keep it alive (because it is
> referenced from the call site which is referenced from the constant pool
> cache).
> 
> Running your example with `-Xlog:indy+methodhandles=debug` confirms this:
> 
> set_method_handle bc=186 appendix=0x000000062b821838 method=0x00000008000c7698
> (local signature)
> {method}
> - this oop:          0x00000008000c7698
> - method holder:     'java/lang/invoke/Invokers$Holder'
> ...
> appendix: java.lang.invoke.BoundMethodHandle$Species_L
> {0x000000062b821838} - klass: 'java/lang/invoke/BoundMethodHandle$Species_L'
>  - ---- fields (total size 5 words):
>  ...
>  - final 'argL0' 'Ljava/lang/Object;' @32  a
>  'LambdaGC$$Lambda$1+0x0000000801000400'{0x000000062b81e080} (0xc5703c10)

Hi Volker,
the main issue if the link is not STRONG is that the VM creates one classloader data per lambda as Mandy said, if you have a library full of lambdas, this will consume a lot of C memory which is always hard to to diagnose.

I remember people from RedHat reverting a library code that was 'lambdaified' because of that.

So it's a kind of pick your poison situation and i believe the current tradeoff, you need a classloader if you want to unload something (classes or lambdas) vs you may consume too much off heap memory is the good one.

regards,
R?mi 

> 
> -------------
> 
> PR: https://git.openjdk.org/jdk/pull/12493

R?mi

From bpb at openjdk.org  Fri Feb 10 22:37:30 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 10 Feb 2023 22:37:30 GMT
Subject: RFR: JDK-8301833: Add manual tests for FDLIBM porting [v2]
In-Reply-To: <yKirJxDRbP_0EUoMcUwJKbt-7D3UpZgy60to8E66h9c=.6ba1c2c0-aeec-48b7-87b1-96f01ba5607c@github.com>
References: <wgghXoOC-eICroAklhQSO8UYEBvYHF_QHZ4C_1wnW0Q=.61574f1b-9c40-4c34-b234-502b95a99c8f@github.com>
 <yKirJxDRbP_0EUoMcUwJKbt-7D3UpZgy60to8E66h9c=.6ba1c2c0-aeec-48b7-87b1-96f01ba5607c@github.com>
Message-ID: <1zO3qNvP4VabATZtAcj9yHmdhPs0OCFos2zOLzClhvc=.e022de82-072e-4c78-bd9a-15f32938f712@github.com>

On Fri, 10 Feb 2023 21:54:07 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> To help add assurances that the main-line port of FDLIBM to Java is working correctly, added some long-running manual tests to probe that the transliteration port and the corresponding StrictMath method are in agreement on a large number of argument, say, all float values.
>> 
>> To test the transliteration port, this test can be run against a build where the JDK has *not* had the FDLIBM code used for StrictMath ported to Java.
>
> Joe Darcy 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:
> 
>  - Update test.
>  - Merge branch 'master' into JDK-8301833
>  - Added trailing line terminator.
>  - JDK-8301833: Add manual tests for FDLIBM porting

This look reasonable.

-------------

PR: https://git.openjdk.org/jdk/pull/12430

From joehw at openjdk.org  Fri Feb 10 22:48:24 2023
From: joehw at openjdk.org (Joe Wang)
Date: Fri, 10 Feb 2023 22:48:24 GMT
Subject: RFR: 8301269: Update Commons BCEL to Version 6.7.0 [v2]
In-Reply-To: <0RNjHfl4qXA0zwLZz10RDxolN96AdrScP27KS1bsT6A=.74cd0696-d037-405d-97eb-be3cbf1e849b@github.com>
References: <0RNjHfl4qXA0zwLZz10RDxolN96AdrScP27KS1bsT6A=.74cd0696-d037-405d-97eb-be3cbf1e849b@github.com>
Message-ID: <hjpgziGtsQQeLFl1J4X2IFEJc4K1e-XzepdCt-e-FIs=.f1d8e20a-1a7b-4a5d-9e18-55d2647445fb@github.com>

> Update Commons BCEL in the JDK from 6.5.0 to 6.7.0. 
> 
> 1. Improvement
>    Code modernization (using relatively more modern language features), normalization (such as naming), javadocs, cleanup and minor improvements made up most of the changes. These changes do not change how BCEL works for the XSLT function in the JDK. Many of the changes unfortunately created long lines, for example merging multiple lines into a single long line, not what we would like to have in the JDK, but I have to leave them as they are so that they don't show up as changes in future updates. 
> 
> 2. Exclusions
>    As it has always been, the focus of the BCEL component is to satisfy the needs for the XSLT functionality. Classes not needed for the JDK are excluded as it has been done previously, this is especially true in the util package. The verifier package is also excluded. Methods and sources that have dependencies on the excluded classes are either removed or modified.
> 
> 3. Deprecation and Warnings
>    
>    Deprecated classes and contents relying on them are removed or modified to use proper methods without changing the functionality. Deprecated fields in the original source were changed to private ones in previous update in the JDK, however, since the update process applies sources from the upstream again, they were reverted back. In order to not have to go through them on every update, I'll keep the original source this time. 
> 
>     Warnings were one of the main reasons for the changes made to the original source. It has been done in the previous update. In this update, many of the previous JDK fixes on warnings have already been addressed in the upstream source as the result of item 1, thus lessoned the needs to reapply the warning patches. Fixed the rest of warnings as they showed up during build.
> 
> 4. Note that JRocket specific patches are not in the current code base.
> 
> 5. Test
>     Tier2 tests passed.
>     JCK XML tests passed.

Joe Wang has updated the pull request incrementally with one additional commit since the last revision:

  update the date of md file

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12464/files
  - new: https://git.openjdk.org/jdk/pull/12464/files/e76ba5fd..74ba5e3a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12464&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12464&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/12464.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12464/head:pull/12464

PR: https://git.openjdk.org/jdk/pull/12464

From lancea at openjdk.org  Fri Feb 10 23:03:26 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Fri, 10 Feb 2023 23:03:26 GMT
Subject: RFR: 8301269: Update Commons BCEL to Version 6.7.0 [v2]
In-Reply-To: <hjpgziGtsQQeLFl1J4X2IFEJc4K1e-XzepdCt-e-FIs=.f1d8e20a-1a7b-4a5d-9e18-55d2647445fb@github.com>
References: <0RNjHfl4qXA0zwLZz10RDxolN96AdrScP27KS1bsT6A=.74cd0696-d037-405d-97eb-be3cbf1e849b@github.com>
 <hjpgziGtsQQeLFl1J4X2IFEJc4K1e-XzepdCt-e-FIs=.f1d8e20a-1a7b-4a5d-9e18-55d2647445fb@github.com>
Message-ID: <2HWXkQ4ZSmj9czbFbzjF8XTibNO7cy8wWrEpTYAOb6I=.c40f9dfb-8bfe-4c46-a6ac-89f863dc59f2@github.com>

On Fri, 10 Feb 2023 22:48:24 GMT, Joe Wang <joehw at openjdk.org> wrote:

>> Update Commons BCEL in the JDK from 6.5.0 to 6.7.0. 
>> 
>> 1. Improvement
>>    Code modernization (using relatively more modern language features), normalization (such as naming), javadocs, cleanup and minor improvements made up most of the changes. These changes do not change how BCEL works for the XSLT function in the JDK. Many of the changes unfortunately created long lines, for example merging multiple lines into a single long line, not what we would like to have in the JDK, but I have to leave them as they are so that they don't show up as changes in future updates. 
>> 
>> 2. Exclusions
>>    As it has always been, the focus of the BCEL component is to satisfy the needs for the XSLT functionality. Classes not needed for the JDK are excluded as it has been done previously, this is especially true in the util package. The verifier package is also excluded. Methods and sources that have dependencies on the excluded classes are either removed or modified.
>> 
>> 3. Deprecation and Warnings
>>    
>>    Deprecated classes and contents relying on them are removed or modified to use proper methods without changing the functionality. Deprecated fields in the original source were changed to private ones in previous update in the JDK, however, since the update process applies sources from the upstream again, they were reverted back. In order to not have to go through them on every update, I'll keep the original source this time. 
>> 
>>     Warnings were one of the main reasons for the changes made to the original source. It has been done in the previous update. In this update, many of the previous JDK fixes on warnings have already been addressed in the upstream source as the result of item 1, thus lessoned the needs to reapply the warning patches. Fixed the rest of warnings as they showed up during build.
>> 
>> 4. Note that JRocket specific patches are not in the current code base.
>> 
>> 5. Test
>>     Tier2 tests passed.
>>     JCK XML tests passed.
>
> Joe Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update the date of md file

Marked as reviewed by lancea (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/12464

From redestad at openjdk.org  Fri Feb 10 23:21:42 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Fri, 10 Feb 2023 23:21:42 GMT
Subject: RFR: JDK-8300808: Accelerate Base64 on x86 for AVX2 [v15]
In-Reply-To: <TmYLe9RCiAqtfuyjU77R-faEEVpfmmUoQ89oyBCcEmM=.c6d2d68b-c37d-4c78-a8e4-af4b48df91a5@github.com>
References: <9zN3bjyMEikXYOlpjTy9_QPc-9usYiBJMUFdb-TaVrQ=.e8f65ce9-ac0f-4f8d-9c6b-b39ae1c26cd2@github.com>
 <TmYLe9RCiAqtfuyjU77R-faEEVpfmmUoQ89oyBCcEmM=.c6d2d68b-c37d-4c78-a8e4-af4b48df91a5@github.com>
Message-ID: <ehO2yEksveYBx5vw4CknkfvlOBavIqt9y4FjqwcqWeU=.a8f22610-de5a-4ffc-bb81-b6d9557965cc@github.com>

On Thu, 9 Feb 2023 18:08:15 GMT, Scott Gibbons <duke at openjdk.org> wrote:

>> Added code for Base64 acceleration (encode and decode) which will accelerate ~4x for AVX2 platforms.
>> 
>> Encode performance:
>> **Old:**
>> 
>> Benchmark                      (maxNumBytes)   Mode  Cnt     Score   Error   Units
>> Base64Encode.testBase64Encode           1024  thrpt    3  4309.439 ? 2.632  ops/ms
>> 
>> 
>> **New:**
>> 
>> Benchmark                      (maxNumBytes)   Mode  Cnt      Score     Error   Units
>> Base64Encode.testBase64Encode           1024  thrpt    3  24211.397 ? 102.026  ops/ms
>> 
>> 
>> Decode performance:
>> **Old:**
>> 
>> Benchmark                      (errorIndex)  (lineSize)  (maxNumBytes)   Mode  Cnt     Score    Error   Units
>> Base64Decode.testBase64Decode           144           4           1024  thrpt    3  3961.768 ? 93.409  ops/ms
>> 
>> **New:**
>> Benchmark                      (errorIndex)  (lineSize)  (maxNumBytes)   Mode  Cnt      Score    Error   Units
>> Base64Decode.testBase64Decode           144           4           1024  thrpt    3  14738.051 ? 24.383  ops/ms
>
> Scott Gibbons has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add URL to microbenchmark

Marked as reviewed by redestad (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/12126

From bpb at openjdk.org  Sat Feb 11 00:21:29 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Sat, 11 Feb 2023 00:21:29 GMT
Subject: RFR: JDK-8301202: Port fdlibm log to Java [v3]
In-Reply-To: <m4vAdpkBQidw-0NRwuFenBJoCXBa0C1m6nWpRezocmo=.aef85774-0baf-46a2-86a9-89d100b3f7e9@github.com>
References: <t0yhKjTMAtSuAZjI0unvr73crUuYEM-2HQ8sUI2_sNU=.82036639-980d-46de-a201-3d85bd84563d@github.com>
 <m4vAdpkBQidw-0NRwuFenBJoCXBa0C1m6nWpRezocmo=.aef85774-0baf-46a2-86a9-89d100b3f7e9@github.com>
Message-ID: <pYVxBERW6jNyNGzEQkKDFp5DS1MTIp8oRKZzCupTlKQ=.c5a24aad-ca06-4d19-bd25-dca123ff3e51@github.com>

On Thu, 9 Feb 2023 06:46:17 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Next up on the FDLIBM porting countdown, the log method.
>> 
>> Original C vs transliteration port:
>> 
>> 
>> $ diff -w Log.c Log.translit.java 
>> 1c1
>> < /* __ieee754_log(x)
>> ---
>>>     /**
>> 51,58c51,52
>> < 
>> < #include "fdlibm.h"
>> < 
>> < #ifdef __STDC__
>> < static const double
>> < #else
>> < static double
>> < #endif
>> ---
>>>     static class Log {
>>>         private static final  double
>> 70c64
>> < static double zero   =  0.0;
>> ---
>>>         private static double zero   =  0.0;
>> 72,78c66
>> < #ifdef __STDC__
>> <         double __ieee754_log(double x)
>> < #else
>> <         double __ieee754_log(x)
>> <         double x;
>> < #endif
>> < {
>> ---
>>>         static double compute(double x) {
>> 81c69
>> <         unsigned lx;
>> ---
>>>             /*unsigned*/ int lx;
>> 98c86,87
>> <         __HI(x) = hx|(i^0x3ff00000);    /* normalize x or x/2 */
>> ---
>>>             // __HI(x) = hx|(i^0x3ff00000);    /* normalize x or x/2 */
>>>             x =__HI(x, hx|(i^0x3ff00000));    /* normalize x or x/2 */
>> 128a118
>>>     }
>> 
>> 
>> Transliteration port vs more idiomatic port:
>> 
>> 
>> $ diff -w  Log.translit.java Log.fdlibm.java 
>> 2c2
>> <      * Return the logarithm of x
>> ---
>>>      * Return the (natural) logarithm of x
>> 53,62c53,54
>> <             ln2_hi  =  6.93147180369123816490e-01,  /* 3fe62e42 fee00000 */
>> <             ln2_lo  =  1.90821492927058770002e-10,  /* 3dea39ef 35793c76 */
>> <             two54   =  1.80143985094819840000e+16,  /* 43500000 00000000 */
>> <             Lg1 = 6.666666666666735130e-01,  /* 3FE55555 55555593 */
>> <             Lg2 = 3.999999999940941908e-01,  /* 3FD99999 9997FA04 */
>> <             Lg3 = 2.857142874366239149e-01,  /* 3FD24924 94229359 */
>> <             Lg4 = 2.222219843214978396e-01,  /* 3FCC71C5 1D8E78AF */
>> <             Lg5 = 1.818357216161805012e-01,  /* 3FC74664 96CB03DE */
>> <             Lg6 = 1.531383769920937332e-01,  /* 3FC39A09 D078C69F */
>> <             Lg7 = 1.479819860511658591e-01;  /* 3FC2F112 DF3E5244 */
>> ---
>>>             ln2_hi = 0x1.62e42feep-1,       // 6.93147180369123816490e-01
>>>             ln2_lo = 0x1.a39ef35793c76p-33, // 1.90821492927058770002e-10
>> 64c56,64
>> <         private static double zero   =  0.0;
>> ---
>>>             Lg1    = 0x1.5555555555593p-1,  // 6.666666666666735130e-01
>>>             Lg2    = 0x1.999999997fa04p-2,  // 3.999999999940941908e-01
>>>             Lg3    = 0x1.2492494229359p-2,  // 2.857142874366239149e-01
>>>             Lg4    = 0x1.c71c51d8e78afp-3,  // 2.222219843214978396e-01
>>>             Lg5    = 0x1.7466496cb03dep-3,  // 1.818357216161805012e-01
>>>             Lg6    = 0x1.39a09d078c69fp-3,  // 1.531383769920937332e-01
>>>             Lg7    = 0x1.2f112df3e5244p-3;  // 1.479819860511658591e-01
>>> 
>>>         private static final double zero = 0.0;
>> 71,72c71,72
>> <             hx = __HI(x);           /* high word of x */
>> <             lx = __LO(x);           /* low  word of x */
>> ---
>>>             hx = __HI(x);           // high word of x
>>>             lx = __LO(x);           // low  word of x
>> 75,80c75,87
>> <             if (hx < 0x00100000) {                  /* x < 2**-1022  */
>> <                 if (((hx&0x7fffffff)|lx)==0)
>> <                     return -two54/zero;             /* log(+-0)=-inf */
>> <                 if (hx<0) return (x-x)/zero;        /* log(-#) = NaN */
>> <                 k -= 54; x *= two54; /* subnormal number, scale up x */
>> <                 hx = __HI(x);               /* high word of x */
>> ---
>>>             if (hx < 0x0010_0000) {                  // x < 2**-1022
>>>                 if (((hx & 0x7fff_ffff) | lx) ==0) { // log(+-0) = -inf
>>>                     return -TWO54/zero;
>>>                 }
>>>                 if (hx < 0) {                        // log(-#) = NaN
>>>                     return (x - x)/zero;
>>>                 }
>>>                 k -= 54;
>>>                 x *= TWO54;    // subnormal number, scale up x
>>>                 hx = __HI(x);  // high word of x
>>>             }
>>>             if (hx >= 0x7ff0_0000) {
>>>                 return x+x;
>> 82d88
>> <             if (hx >= 0x7ff00000) return x+x;
>> 84,87c90,92
>> <             hx &= 0x000fffff;
>> <             i = (hx+0x95f64)&0x100000;
>> <             // __HI(x) = hx|(i^0x3ff00000);    /* normalize x or x/2 */
>> <             x =__HI(x, hx|(i^0x3ff00000));    /* normalize x or x/2 */
>> ---
>>>             hx &= 0x000f_ffff;
>>>             i = (hx + 0x9_5f64) & 0x10_0000;
>>>             x =__HI(x, hx|(i ^ 0x3ff0_0000));  // normalize x or x/2
>> 90c95
>> <             if((0x000fffff&(2+hx))<3) {     /* |f| < 2**-20 */
>> ---
>>>             if ((0x000f_ffff & (2 + hx)) < 3) {// |f| < 2**-20
>> 92,93c97,102
>> <                     if (k==0) return zero;
>> <                     else {dk=(double)k; return dk*ln2_hi+dk*ln2_lo;}
>> ---
>>>                     if (k == 0) {
>>>                         return zero;
>>>                     } else {
>>>                         dk = (double)k;
>>>                         return dk*ln2_hi + dk*ln2_lo;
>>>                     }
>> 96,97c105,110
>> <                 if(k==0) return f-R; else {dk=(double)k;
>> <                     return dk*ln2_hi-((R-dk*ln2_lo)-f);}
>> ---
>>>                 if (k == 0) {
>>>                     return f - R;
>>>                 } else {
>>>                     dk = (double)k;
>>>                     return dk*ln2_hi - ((R - dk*ln2_lo) - f);
>>>                 }
>> 102c115
>> <             i = hx-0x6147a;
>> ---
>>>             i = hx - 0x6_147a;
>> 111c124,126
>> <                 if(k==0) return f-(hfsq-s*(hfsq+R)); else
>> ---
>>>                 if (k == 0) {
>>>                     return f-(hfsq-s*(hfsq+R));
>>>                 } else {
>> 112a128,131
>>>                 }
>>>             } else {
>>>                 if (k == 0) {
>>>                     return f - s*(f - R);
>> 114d132
>> <                 if(k==0) return f-s*(f-R); else
>> 115a134
>>>                 }
>> 
>> 
>> The transliteration port passes the "exhausting" test of all float arguments when run against a JDK 20 build. The idiomatic port matches the transliteration port on the same test.
>
> Joe Darcy has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Appease jcheck.
>  - Add StrictMath.log vs Math.log differences.

Looks fine.

-------------

Marked as reviewed by bpb (Reviewer).

PR: https://git.openjdk.org/jdk/pull/12465

From bpb at openjdk.org  Sat Feb 11 00:23:28 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Sat, 11 Feb 2023 00:23:28 GMT
Subject: RFR: JDK-8301833: Add manual tests for FDLIBM porting [v2]
In-Reply-To: <yKirJxDRbP_0EUoMcUwJKbt-7D3UpZgy60to8E66h9c=.6ba1c2c0-aeec-48b7-87b1-96f01ba5607c@github.com>
References: <wgghXoOC-eICroAklhQSO8UYEBvYHF_QHZ4C_1wnW0Q=.61574f1b-9c40-4c34-b234-502b95a99c8f@github.com>
 <yKirJxDRbP_0EUoMcUwJKbt-7D3UpZgy60to8E66h9c=.6ba1c2c0-aeec-48b7-87b1-96f01ba5607c@github.com>
Message-ID: <XwIGU8RTgu_uDrc_7ODufnddp85v2JUq_4wDen_tS5M=.e674e1b5-8209-4b7c-8129-8a0917b4afa2@github.com>

On Fri, 10 Feb 2023 21:54:07 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> To help add assurances that the main-line port of FDLIBM to Java is working correctly, added some long-running manual tests to probe that the transliteration port and the corresponding StrictMath method are in agreement on a large number of argument, say, all float values.
>> 
>> To test the transliteration port, this test can be run against a build where the JDK has *not* had the FDLIBM code used for StrictMath ported to Java.
>
> Joe Darcy 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:
> 
>  - Update test.
>  - Merge branch 'master' into JDK-8301833
>  - Added trailing line terminator.
>  - JDK-8301833: Add manual tests for FDLIBM porting

This looks all right.

-------------

Marked as reviewed by bpb (Reviewer).

PR: https://git.openjdk.org/jdk/pull/12430

From darcy at openjdk.org  Sat Feb 11 02:19:51 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Sat, 11 Feb 2023 02:19:51 GMT
Subject: RFR: JDK-8301202: Port fdlibm log to Java [v4]
In-Reply-To: <t0yhKjTMAtSuAZjI0unvr73crUuYEM-2HQ8sUI2_sNU=.82036639-980d-46de-a201-3d85bd84563d@github.com>
References: <t0yhKjTMAtSuAZjI0unvr73crUuYEM-2HQ8sUI2_sNU=.82036639-980d-46de-a201-3d85bd84563d@github.com>
Message-ID: <rrzF3_MzaLx2fqXWpYAR3p1U5hCRlq5bZMyWrMAER70=.e6e3b255-913a-4312-bdf1-7f118fe1b1d3@github.com>

> Next up on the FDLIBM porting countdown, the log method.
> 
> Original C vs transliteration port:
> 
> 
> $ diff -w Log.c Log.translit.java 
> 1c1
> < /* __ieee754_log(x)
> ---
>>     /**
> 51,58c51,52
> < 
> < #include "fdlibm.h"
> < 
> < #ifdef __STDC__
> < static const double
> < #else
> < static double
> < #endif
> ---
>>     static class Log {
>>         private static final  double
> 70c64
> < static double zero   =  0.0;
> ---
>>         private static double zero   =  0.0;
> 72,78c66
> < #ifdef __STDC__
> <         double __ieee754_log(double x)
> < #else
> <         double __ieee754_log(x)
> <         double x;
> < #endif
> < {
> ---
>>         static double compute(double x) {
> 81c69
> <         unsigned lx;
> ---
>>             /*unsigned*/ int lx;
> 98c86,87
> <         __HI(x) = hx|(i^0x3ff00000);    /* normalize x or x/2 */
> ---
>>             // __HI(x) = hx|(i^0x3ff00000);    /* normalize x or x/2 */
>>             x =__HI(x, hx|(i^0x3ff00000));    /* normalize x or x/2 */
> 128a118
>>     }
> 
> 
> Transliteration port vs more idiomatic port:
> 
> 
> $ diff -w  Log.translit.java Log.fdlibm.java 
> 2c2
> <      * Return the logarithm of x
> ---
>>      * Return the (natural) logarithm of x
> 53,62c53,54
> <             ln2_hi  =  6.93147180369123816490e-01,  /* 3fe62e42 fee00000 */
> <             ln2_lo  =  1.90821492927058770002e-10,  /* 3dea39ef 35793c76 */
> <             two54   =  1.80143985094819840000e+16,  /* 43500000 00000000 */
> <             Lg1 = 6.666666666666735130e-01,  /* 3FE55555 55555593 */
> <             Lg2 = 3.999999999940941908e-01,  /* 3FD99999 9997FA04 */
> <             Lg3 = 2.857142874366239149e-01,  /* 3FD24924 94229359 */
> <             Lg4 = 2.222219843214978396e-01,  /* 3FCC71C5 1D8E78AF */
> <             Lg5 = 1.818357216161805012e-01,  /* 3FC74664 96CB03DE */
> <             Lg6 = 1.531383769920937332e-01,  /* 3FC39A09 D078C69F */
> <             Lg7 = 1.479819860511658591e-01;  /* 3FC2F112 DF3E5244 */
> ---
>>             ln2_hi = 0x1.62e42feep-1,       // 6.93147180369123816490e-01
>>             ln2_lo = 0x1.a39ef35793c76p-33, // 1.90821492927058770002e-10
> 64c56,64
> <         private static double zero   =  0.0;
> ---
>>             Lg1    = 0x1.5555555555593p-1,  // 6.666666666666735130e-01
>>             Lg2    = 0x1.999999997fa04p-2,  // 3.999999999940941908e-01
>>             Lg3    = 0x1.2492494229359p-2,  // 2.857142874366239149e-01
>>             Lg4    = 0x1.c71c51d8e78afp-3,  // 2.222219843214978396e-01
>>             Lg5    = 0x1.7466496cb03dep-3,  // 1.818357216161805012e-01
>>             Lg6    = 0x1.39a09d078c69fp-3,  // 1.531383769920937332e-01
>>             Lg7    = 0x1.2f112df3e5244p-3;  // 1.479819860511658591e-01
>> 
>>         private static final double zero = 0.0;
> 71,72c71,72
> <             hx = __HI(x);           /* high word of x */
> <             lx = __LO(x);           /* low  word of x */
> ---
>>             hx = __HI(x);           // high word of x
>>             lx = __LO(x);           // low  word of x
> 75,80c75,87
> <             if (hx < 0x00100000) {                  /* x < 2**-1022  */
> <                 if (((hx&0x7fffffff)|lx)==0)
> <                     return -two54/zero;             /* log(+-0)=-inf */
> <                 if (hx<0) return (x-x)/zero;        /* log(-#) = NaN */
> <                 k -= 54; x *= two54; /* subnormal number, scale up x */
> <                 hx = __HI(x);               /* high word of x */
> ---
>>             if (hx < 0x0010_0000) {                  // x < 2**-1022
>>                 if (((hx & 0x7fff_ffff) | lx) ==0) { // log(+-0) = -inf
>>                     return -TWO54/zero;
>>                 }
>>                 if (hx < 0) {                        // log(-#) = NaN
>>                     return (x - x)/zero;
>>                 }
>>                 k -= 54;
>>                 x *= TWO54;    // subnormal number, scale up x
>>                 hx = __HI(x);  // high word of x
>>             }
>>             if (hx >= 0x7ff0_0000) {
>>                 return x+x;
> 82d88
> <             if (hx >= 0x7ff00000) return x+x;
> 84,87c90,92
> <             hx &= 0x000fffff;
> <             i = (hx+0x95f64)&0x100000;
> <             // __HI(x) = hx|(i^0x3ff00000);    /* normalize x or x/2 */
> <             x =__HI(x, hx|(i^0x3ff00000));    /* normalize x or x/2 */
> ---
>>             hx &= 0x000f_ffff;
>>             i = (hx + 0x9_5f64) & 0x10_0000;
>>             x =__HI(x, hx|(i ^ 0x3ff0_0000));  // normalize x or x/2
> 90c95
> <             if((0x000fffff&(2+hx))<3) {     /* |f| < 2**-20 */
> ---
>>             if ((0x000f_ffff & (2 + hx)) < 3) {// |f| < 2**-20
> 92,93c97,102
> <                     if (k==0) return zero;
> <                     else {dk=(double)k; return dk*ln2_hi+dk*ln2_lo;}
> ---
>>                     if (k == 0) {
>>                         return zero;
>>                     } else {
>>                         dk = (double)k;
>>                         return dk*ln2_hi + dk*ln2_lo;
>>                     }
> 96,97c105,110
> <                 if(k==0) return f-R; else {dk=(double)k;
> <                     return dk*ln2_hi-((R-dk*ln2_lo)-f);}
> ---
>>                 if (k == 0) {
>>                     return f - R;
>>                 } else {
>>                     dk = (double)k;
>>                     return dk*ln2_hi - ((R - dk*ln2_lo) - f);
>>                 }
> 102c115
> <             i = hx-0x6147a;
> ---
>>             i = hx - 0x6_147a;
> 111c124,126
> <                 if(k==0) return f-(hfsq-s*(hfsq+R)); else
> ---
>>                 if (k == 0) {
>>                     return f-(hfsq-s*(hfsq+R));
>>                 } else {
> 112a128,131
>>                 }
>>             } else {
>>                 if (k == 0) {
>>                     return f - s*(f - R);
> 114d132
> <                 if(k==0) return f-s*(f-R); else
> 115a134
>>                 }
> 
> 
> The transliteration port passes the "exhausting" test of all float arguments when run against a JDK 20 build. The idiomatic port matches the transliteration port on the same test.

Joe Darcy 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:

 - Call out to FDLIBM log from StrictMath.
 - Merge branch 'master' into JDK-8301202
 - Appease jcheck.
 - Add StrictMath.log vs Math.log differences.
 - Improve declarations of Log host classes.
 - Appease jcheck.
 - Preliminary version of regression test.
 - Switch to hex literals.
 - JDK-8301202: Port fdlibm log to Java

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12465/files
  - new: https://git.openjdk.org/jdk/pull/12465/files/cafd1f1f..277f1b2d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12465&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12465&range=02-03

  Stats: 13817 lines in 598 files changed: 8309 ins; 1195 del; 4313 mod
  Patch: https://git.openjdk.org/jdk/pull/12465.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12465/head:pull/12465

PR: https://git.openjdk.org/jdk/pull/12465

From darcy at openjdk.org  Sat Feb 11 02:19:53 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Sat, 11 Feb 2023 02:19:53 GMT
Subject: Integrated: JDK-8301202: Port fdlibm log to Java
In-Reply-To: <t0yhKjTMAtSuAZjI0unvr73crUuYEM-2HQ8sUI2_sNU=.82036639-980d-46de-a201-3d85bd84563d@github.com>
References: <t0yhKjTMAtSuAZjI0unvr73crUuYEM-2HQ8sUI2_sNU=.82036639-980d-46de-a201-3d85bd84563d@github.com>
Message-ID: <bjWav8f2-fQxm965o8L10E7tF1S8gaYJUn0dutm8kCE=.bb85bed4-c525-4d72-9e96-3f92fd8cab92@github.com>

On Wed, 8 Feb 2023 00:25:32 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Next up on the FDLIBM porting countdown, the log method.
> 
> Original C vs transliteration port:
> 
> 
> $ diff -w Log.c Log.translit.java 
> 1c1
> < /* __ieee754_log(x)
> ---
>>     /**
> 51,58c51,52
> < 
> < #include "fdlibm.h"
> < 
> < #ifdef __STDC__
> < static const double
> < #else
> < static double
> < #endif
> ---
>>     static class Log {
>>         private static final  double
> 70c64
> < static double zero   =  0.0;
> ---
>>         private static double zero   =  0.0;
> 72,78c66
> < #ifdef __STDC__
> <         double __ieee754_log(double x)
> < #else
> <         double __ieee754_log(x)
> <         double x;
> < #endif
> < {
> ---
>>         static double compute(double x) {
> 81c69
> <         unsigned lx;
> ---
>>             /*unsigned*/ int lx;
> 98c86,87
> <         __HI(x) = hx|(i^0x3ff00000);    /* normalize x or x/2 */
> ---
>>             // __HI(x) = hx|(i^0x3ff00000);    /* normalize x or x/2 */
>>             x =__HI(x, hx|(i^0x3ff00000));    /* normalize x or x/2 */
> 128a118
>>     }
> 
> 
> Transliteration port vs more idiomatic port:
> 
> 
> $ diff -w  Log.translit.java Log.fdlibm.java 
> 2c2
> <      * Return the logarithm of x
> ---
>>      * Return the (natural) logarithm of x
> 53,62c53,54
> <             ln2_hi  =  6.93147180369123816490e-01,  /* 3fe62e42 fee00000 */
> <             ln2_lo  =  1.90821492927058770002e-10,  /* 3dea39ef 35793c76 */
> <             two54   =  1.80143985094819840000e+16,  /* 43500000 00000000 */
> <             Lg1 = 6.666666666666735130e-01,  /* 3FE55555 55555593 */
> <             Lg2 = 3.999999999940941908e-01,  /* 3FD99999 9997FA04 */
> <             Lg3 = 2.857142874366239149e-01,  /* 3FD24924 94229359 */
> <             Lg4 = 2.222219843214978396e-01,  /* 3FCC71C5 1D8E78AF */
> <             Lg5 = 1.818357216161805012e-01,  /* 3FC74664 96CB03DE */
> <             Lg6 = 1.531383769920937332e-01,  /* 3FC39A09 D078C69F */
> <             Lg7 = 1.479819860511658591e-01;  /* 3FC2F112 DF3E5244 */
> ---
>>             ln2_hi = 0x1.62e42feep-1,       // 6.93147180369123816490e-01
>>             ln2_lo = 0x1.a39ef35793c76p-33, // 1.90821492927058770002e-10
> 64c56,64
> <         private static double zero   =  0.0;
> ---
>>             Lg1    = 0x1.5555555555593p-1,  // 6.666666666666735130e-01
>>             Lg2    = 0x1.999999997fa04p-2,  // 3.999999999940941908e-01
>>             Lg3    = 0x1.2492494229359p-2,  // 2.857142874366239149e-01
>>             Lg4    = 0x1.c71c51d8e78afp-3,  // 2.222219843214978396e-01
>>             Lg5    = 0x1.7466496cb03dep-3,  // 1.818357216161805012e-01
>>             Lg6    = 0x1.39a09d078c69fp-3,  // 1.531383769920937332e-01
>>             Lg7    = 0x1.2f112df3e5244p-3;  // 1.479819860511658591e-01
>> 
>>         private static final double zero = 0.0;
> 71,72c71,72
> <             hx = __HI(x);           /* high word of x */
> <             lx = __LO(x);           /* low  word of x */
> ---
>>             hx = __HI(x);           // high word of x
>>             lx = __LO(x);           // low  word of x
> 75,80c75,87
> <             if (hx < 0x00100000) {                  /* x < 2**-1022  */
> <                 if (((hx&0x7fffffff)|lx)==0)
> <                     return -two54/zero;             /* log(+-0)=-inf */
> <                 if (hx<0) return (x-x)/zero;        /* log(-#) = NaN */
> <                 k -= 54; x *= two54; /* subnormal number, scale up x */
> <                 hx = __HI(x);               /* high word of x */
> ---
>>             if (hx < 0x0010_0000) {                  // x < 2**-1022
>>                 if (((hx & 0x7fff_ffff) | lx) ==0) { // log(+-0) = -inf
>>                     return -TWO54/zero;
>>                 }
>>                 if (hx < 0) {                        // log(-#) = NaN
>>                     return (x - x)/zero;
>>                 }
>>                 k -= 54;
>>                 x *= TWO54;    // subnormal number, scale up x
>>                 hx = __HI(x);  // high word of x
>>             }
>>             if (hx >= 0x7ff0_0000) {
>>                 return x+x;
> 82d88
> <             if (hx >= 0x7ff00000) return x+x;
> 84,87c90,92
> <             hx &= 0x000fffff;
> <             i = (hx+0x95f64)&0x100000;
> <             // __HI(x) = hx|(i^0x3ff00000);    /* normalize x or x/2 */
> <             x =__HI(x, hx|(i^0x3ff00000));    /* normalize x or x/2 */
> ---
>>             hx &= 0x000f_ffff;
>>             i = (hx + 0x9_5f64) & 0x10_0000;
>>             x =__HI(x, hx|(i ^ 0x3ff0_0000));  // normalize x or x/2
> 90c95
> <             if((0x000fffff&(2+hx))<3) {     /* |f| < 2**-20 */
> ---
>>             if ((0x000f_ffff & (2 + hx)) < 3) {// |f| < 2**-20
> 92,93c97,102
> <                     if (k==0) return zero;
> <                     else {dk=(double)k; return dk*ln2_hi+dk*ln2_lo;}
> ---
>>                     if (k == 0) {
>>                         return zero;
>>                     } else {
>>                         dk = (double)k;
>>                         return dk*ln2_hi + dk*ln2_lo;
>>                     }
> 96,97c105,110
> <                 if(k==0) return f-R; else {dk=(double)k;
> <                     return dk*ln2_hi-((R-dk*ln2_lo)-f);}
> ---
>>                 if (k == 0) {
>>                     return f - R;
>>                 } else {
>>                     dk = (double)k;
>>                     return dk*ln2_hi - ((R - dk*ln2_lo) - f);
>>                 }
> 102c115
> <             i = hx-0x6147a;
> ---
>>             i = hx - 0x6_147a;
> 111c124,126
> <                 if(k==0) return f-(hfsq-s*(hfsq+R)); else
> ---
>>                 if (k == 0) {
>>                     return f-(hfsq-s*(hfsq+R));
>>                 } else {
> 112a128,131
>>                 }
>>             } else {
>>                 if (k == 0) {
>>                     return f - s*(f - R);
> 114d132
> <                 if(k==0) return f-s*(f-R); else
> 115a134
>>                 }
> 
> 
> The transliteration port passes the "exhausting" test of all float arguments when run against a JDK 20 build. The idiomatic port matches the transliteration port on the same test.

This pull request has now been integrated.

Changeset: 919a6da2
Author:    Joe Darcy <darcy at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/919a6da2a74d0a57e691a9815c35a16fc7645784
Stats:     498 lines in 5 files changed: 496 ins; 0 del; 2 mod

8301202: Port fdlibm log to Java

Reviewed-by: bpb

-------------

PR: https://git.openjdk.org/jdk/pull/12465

From darcy at openjdk.org  Sat Feb 11 02:56:51 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Sat, 11 Feb 2023 02:56:51 GMT
Subject: RFR: JDK-8301444: Port fdlibm hyperbolic transcendental functions
 to Java [v7]
In-Reply-To: <_s8xnppoDTnAajAjlmfB-dX5DBdawUcSSPaGWGLzFBk=.cdbf468a-ace7-45e5-a25a-833c760b776c@github.com>
References: <_s8xnppoDTnAajAjlmfB-dX5DBdawUcSSPaGWGLzFBk=.cdbf468a-ace7-45e5-a25a-833c760b776c@github.com>
Message-ID: <cGnMdkvx8TMHPqLdi0feyhPfcp31LnSVf6cbjjuil4I=.5b6e89d0-df7d-42ae-bd4d-f1d0b500456b@github.com>

> Initial pass of porting FDLIBM sinh/cosh/tanh to Java. I do intend to refactor the regression tests a bit to reduce duplication, but the actual ports should be ready for review.
> 
> Diff'ing the ports as before, original vs transliteration port:
> 
> 
> $ diff -w Hyperbolic.c Hyperbolic.translit.java
> 1c1
> < /* __ieee754_sinh(x)
> ---
>>     /**
> 17a18,19
>>     static class Sinh {
>>         private static final double one = 1.0, shuge = 1.0e307;
> 19,33c21
> < #include "fdlibm.h"
> < 
> < #ifdef __STDC__
> < static const double one = 1.0, shuge = 1.0e307;
> < #else
> < static double one = 1.0, shuge = 1.0e307;
> < #endif
> < 
> < #ifdef __STDC__
> <         double __ieee754_sinh(double x)
> < #else
> <         double __ieee754_sinh(x)
> <         double x;
> < #endif
> < {
> ---
>>         private static double compute(double x) {
> 36c24
> <         unsigned lx;
> ---
>>             /* unsigned */ int lx;
> 51c39
> <             t = expm1(fabs(x));
> ---
>>                 t = FdlibmTranslit.expm1(Math.abs(x));
> 57c45
> <         if (ix < 0x40862E42)  return h*__ieee754_exp(fabs(x));
> ---
>>             if (ix < 0x40862E42)  return h*StrictMath.exp(Math.abs(x)); // TODO switch to translit
> 60,62c48,52
> <         lx = *( (((*(unsigned*)&one)>>29)) + (unsigned*)&x);
> <         if (ix<0x408633CE || ((ix==0x408633ce)&&(lx<=(unsigned)0x8fb9f87d))) {
> <             w = __ieee754_exp(0.5*fabs(x));
> ---
>>             // lx = *( (((*(unsigned*)&one)>>29)) + (unsigned*)&x);
>>             // lx =  (((*(unsigned*)&one)>>29)) + (unsigned*)&x ;
>>             lx = __LO(x);
>>             if (ix<0x408633CE || ((ix==0x408633ce)&&(Long.compareUnsigned(lx, 0x8fb9f87d) <= 0 ))) {
>>                 w = StrictMath.exp(0.5*Math.abs(x)); // TODO switch to translit
> 70c60,62
> < /* __ieee754_cosh(x)
> ---
>>     }
>> 
>>     /**
> 90,105c82,84
> < 
> < #include "fdlibm.h"
> < 
> < #ifdef __STDC__
> < static const double one = 1.0, half=0.5, huge = 1.0e300;
> < #else
> < static double one = 1.0, half=0.5, huge = 1.0e300;
> < #endif
> < 
> < #ifdef __STDC__
> <         double __ieee754_cosh(double x)
> < #else
> <         double __ieee754_cosh(x)
> <         double x;
> < #endif
> < {
> ---
>>     static class Cosh {
>>         private static final double one = 1.0, half=0.5, huge = 1.0e300;
>>         private static double compute(double x) {
> 108c87
> <         unsigned lx;
> ---
>>             /*unsigned*/ int lx;
> 119c98
> <             t = expm1(fabs(x));
> ---
>>                 t = expm1(Math.abs(x));
> 127c106
> <                 t = __ieee754_exp(fabs(x));
> ---
>>                 t = StrictMath.exp(Math.abs(x)); // TODO switch to translit
> 132c111
> <         if (ix < 0x40862E42)  return half*__ieee754_exp(fabs(x));
> ---
>>             if (ix < 0x40862E42)  return half*StrictMath.exp(Math.abs(x)); // TODO switch to translit
> 135c114
> <         lx = *( (((*(unsigned*)&one)>>29)) + (unsigned*)&x);
> ---
>>             lx = __LO(x);
> 137,138c116,117
> <               ((ix==0x408633ce)&&(lx<=(unsigned)0x8fb9f87d))) {
> <             w = __ieee754_exp(half*fabs(x));
> ---
>>                 ((ix==0x408633ce)&&(Integer.compareUnsigned(lx, 0x8fb9f87d) <= 0))) {
>>                 w = StrictMath.exp(half*Math.abs(x)); // TODO switch to translit
> 146c125,127
> < /* Tanh(x)
> ---
>>     }
>> 
>>     /**
> 169,184c150,152
> < 
> < #include "fdlibm.h"
> < 
> < #ifdef __STDC__
> < static const double one=1.0, two=2.0, tiny = 1.0e-300;
> < #else
> < static double one=1.0, two=2.0, tiny = 1.0e-300;
> < #endif
> < 
> < #ifdef __STDC__
> <         double tanh(double x)
> < #else
> <         double tanh(x)
> <         double x;
> < #endif
> < {
> ---
>>     static class Tanh {
>>         private static final double one=1.0, two=2.0, tiny = 1.0e-300;
>>         static double compute(double x) {
> 203c171
> <                 t = expm1(two*fabs(x));
> ---
>>                     t = expm1(two*Math.abs(x));
> 206c174
> <                 t = expm1(-two*fabs(x));
> ---
>>                     t = expm1(-two*Math.abs(x));
> 214a183
>>     }
> 
> 
> Note that the original has a in-line version of the "__LO" macro rather than using the macro.
> 
> 
> And transliteration vs more idiomatic:
> 
> 
> $ diff -w Hyperbolic.translit.java Hyperbolic.fdlibm.java 
> 21c21
> <         private static double compute(double x) {
> ---
>>          static double compute(double x) {
> 26c26
> <             /* High word of |x|. */
> ---
>>             // High word of |x|
> 28c28
> <             ix = jx&0x7fffffff;
> ---
>>             ix = jx & 0x7fff_ffff;
> 30,31c30,33
> <             /* x is INF or NaN */
> <             if(ix>=0x7ff00000) return x+x;
> ---
>>             // x is INF or NaN
>>             if ( ix >= 0x7ff0_0000) {
>>                 return x + x;
>>             }
> 34,40c36,48
> <             if (jx<0) h = -h;
> <             /* |x| in [0,22], return sign(x)*0.5*(E+E/(E+1))) */
> <             if (ix < 0x40360000) {          /* |x|<22 */
> <                 if (ix<0x3e300000)          /* |x|<2**-28 */
> <                     if(shuge+x>one) return x;/* sinh(tiny) = tiny with inexact */
> <                 t = FdlibmTranslit.expm1(Math.abs(x));
> <                 if(ix<0x3ff00000) return h*(2.0*t-t*t/(t+one));
> ---
>>             if ( jx < 0) {
>>                 h = -h;
>>             }
>>             // |x| in [0,22], return sign(x)*0.5*(E+E/(E+1)))
>>             if (ix < 0x4036_0000) {          // |x| < 22
>>                 if (ix < 0x3e30_0000)        // |x| < 2**-28
>>                     if (shuge + x > one) {   // sinh(tiny) = tiny with inexact
>>                         return x;
>>                     }
>>                 t = StrictMath.expm1(Math.abs(x));
>>                 if (ix < 0x3ff0_0000) {
>>                     return h*(2.0 * t - t*t/(t + one));
>>                 }
> 44,45c52,55
> <             /* |x| in [22, log(maxdouble)] return 0.5*exp(|x|) */
> <             if (ix < 0x40862E42)  return h*StrictMath.exp(Math.abs(x)); // TODO switch to translit
> ---
>>             // |x| in [22, log(maxdouble)] return 0.5*exp(|x|)
>>             if (ix < 0x4086_2E42) {
>>                 return h*StrictMath.exp(Math.abs(x));
>>             }
> 47,49c57
> <             /* |x| in [log(maxdouble), overflowthresold] */
> <             // lx = *( (((*(unsigned*)&one)>>29)) + (unsigned*)&x);
> <             // lx =  (((*(unsigned*)&one)>>29)) + (unsigned*)&x ;
> ---
>>             // |x| in [log(maxdouble), overflowthresold]
> 51,52c59,62
> <             if (ix<0x408633CE || ((ix==0x408633ce)&&(Long.compareUnsigned(lx, 0x8fb9f87d) <= 0 ))) {
> <                 w = StrictMath.exp(0.5*Math.abs(x)); // TODO switch to translit
> ---
>>             if (ix < 0x4086_33CE ||
>>                 ((ix == 0x4086_33ce) &&
>>                  (Long.compareUnsigned(lx, 0x8fb9_f87d) <= 0 ))) {
>>                 w = StrictMath.exp(0.5 * Math.abs(x));
> 57c67
> <             /* |x| > overflowthresold, sinh(x) overflow */
> ---
>>             // |x| > overflowthresold, sinh(x) overflow
> 84c94
> <         private static double compute(double x) {
> ---
>>         static double compute(double x) {
> 89c99
> <             /* High word of |x|. */
> ---
>>             // High word of |x|
> 91c101
> <             ix &= 0x7fffffff;
> ---
>>             ix &= 0x7fff_ffff;
> 93,94c103,106
> <             /* x is INF or NaN */
> <             if(ix>=0x7ff00000) return x*x;
> ---
>>             // x is INF or NaN
>>             if (ix >= 0x7ff_00000) {
>>                 return x*x;
>>             }
> 96,98c108,110
> <             /* |x| in [0,0.5*ln2], return 1+expm1(|x|)^2/(2*exp(|x|)) */
> <             if(ix<0x3fd62e43) {
> <                 t = expm1(Math.abs(x));
> ---
>>             // |x| in [0,0.5*ln2], return 1+expm1(|x|)^2/(2*exp(|x|))
>>             if (ix < 0x3fd6_2e43) {
>>                 t = StrictMath.expm1(Math.abs(x));
> 100c112,114
> <                 if (ix<0x3c800000) return w;        /* cosh(tiny) = 1 */
> ---
>>                 if (ix < 0x3c80_0000) { // cosh(tiny) = 1
>>                     return w;
>>                 }
> 104,106c118,120
> <             /* |x| in [0.5*ln2,22], return (exp(|x|)+1/exp(|x|)/2; */
> <             if (ix < 0x40360000) {
> <                 t = StrictMath.exp(Math.abs(x)); // TODO switch to translit
> ---
>>             // |x| in [0.5*ln2, 22], return (exp(|x|) + 1/exp(|x|)/2
>>             if (ix < 0x4036_0000) {
>>                 t = StrictMath.exp(Math.abs(x));
> 110,111c124,127
> <             /* |x| in [22, log(maxdouble)] return half*exp(|x|) */
> <             if (ix < 0x40862E42)  return half*StrictMath.exp(Math.abs(x)); // TODO switch to translit
> ---
>>             // |x| in [22, log(maxdouble)] return half*exp(|x|)
>>             if (ix < 0x4086_2E42) {
>>                 return half*StrictMath.exp(Math.abs(x));
>>             }
> 113c129
> <             /* |x| in [log(maxdouble), overflowthresold] */
> ---
>>             // |x| in [log(maxdouble), overflowthresold]
> 115,117c131,134
> <             if (ix<0x408633CE ||
> <                 ((ix==0x408633ce)&&(Integer.compareUnsigned(lx, 0x8fb9f87d) <= 0))) {
> <                 w = StrictMath.exp(half*Math.abs(x)); // TODO switch to translit
> ---
>>             if (ix<0x4086_33CE ||
>>                 ((ix == 0x4086_33ce) &&
>>                  (Integer.compareUnsigned(lx, 0x8fb9_f87d) <= 0))) {
>>                 w = StrictMath.exp(half*Math.abs(x));
> 122c139
> <             /* |x| > overflowthresold, cosh(x) overflow */
> ---
>>             // |x| > overflowthresold, cosh(x) overflow
> 126d142
> < 
> 156c172
> <             /* High word of |x|. */
> ---
>>             // High word of |x|.
> 158c174
> <             ix = jx&0x7fffffff;
> ---
>>             ix = jx & 0x7fff_ffff;
> 160,163c176,182
> <             /* x is INF or NaN */
> <             if(ix>=0x7ff00000) {
> <                 if (jx>=0) return one/x+one;    /* tanh(+-inf)=+-1 */
> <                 else       return one/x-one;    /* tanh(NaN) = NaN */
> ---
>>             // x is INF or NaN
>>             if (ix >= 0x7ff0_0000) {
>>                 if (jx >= 0) {  // tanh(+-inf)=+-1
>>                     return one/x + one;
>>                 } else {        // tanh(NaN) = NaN
>>                     return one/x - one;
>>                 }
> 166,171c185,190
> <             /* |x| < 22 */
> <             if (ix < 0x40360000) {          /* |x|<22 */
> <                 if (ix<0x3c800000)          /* |x|<2**-55 */
> <                     return x*(one+x);       /* tanh(small) = small */
> <                 if (ix>=0x3ff00000) {       /* |x|>=1  */
> <                     t = expm1(two*Math.abs(x));
> ---
>>             // |x| < 22
>>             if (ix < 0x4036_0000) {          // |x| < 22
>>                 if (ix<0x3c80_0000)          // |x| < 2**-55
>>                     return x*(one + x);      // tanh(small) = small
>>                 if (ix>=0x3ff0_0000) {       // |x| >= 1
>>                     t = StrictMath.expm1(two*Math.abs(x));
> 174c193
> <                     t = expm1(-two*Math.abs(x));
> ---
>>                     t = StrictMath.expm1(-two*Math.abs(x));
> 177,179c196,197
> <                 /* |x| > 22, return +-1 */
> <             } else {
> <                 z = one - tiny;             /* raised inexact flag */
> ---
>>             } else { // |x| > 22, return +-1
>>                 z = one - tiny;             // raised inexact flag

Joe Darcy 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 'master' into JDK-8301444
 - Improve exp usage.
 - Add additional note.
 - Respond to review feedback.
 - Correct overflow limit in regression test.
 - Two more spacing fixes.
 - Implement spacing improvements from code review comments.
 - JDK-8301444: Port fdlibm hyperbolic transcendental functions to Java

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12429/files
  - new: https://git.openjdk.org/jdk/pull/12429/files/19fe9857..5a295967

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12429&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12429&range=05-06

  Stats: 14401 lines in 604 files changed: 8821 ins; 1196 del; 4384 mod
  Patch: https://git.openjdk.org/jdk/pull/12429.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12429/head:pull/12429

PR: https://git.openjdk.org/jdk/pull/12429

From darcy at openjdk.org  Sat Feb 11 03:04:51 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Sat, 11 Feb 2023 03:04:51 GMT
Subject: RFR: JDK-8301833: Add wide-ranging tests for FDLIBM porting [v3]
In-Reply-To: <wgghXoOC-eICroAklhQSO8UYEBvYHF_QHZ4C_1wnW0Q=.61574f1b-9c40-4c34-b234-502b95a99c8f@github.com>
References: <wgghXoOC-eICroAklhQSO8UYEBvYHF_QHZ4C_1wnW0Q=.61574f1b-9c40-4c34-b234-502b95a99c8f@github.com>
Message-ID: <wcQzv2zqfxXZ5HU5C-_ORlyQOegfREmknU6ShqYgQts=.4f1821f2-0dc6-480e-82f7-4a10e5402f1b@github.com>

> To help add assurances that the main-line port of FDLIBM to Java is working correctly, added some long-running manual tests to probe that the transliteration port and the corresponding StrictMath method are in agreement on a large number of argument, say, all float values.
> 
> To test the transliteration port, this test can be run against a build where the JDK has *not* had the FDLIBM code used for StrictMath ported to Java.

Joe Darcy 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:

 - Include log testing.
 - Merge branch 'master' into JDK-8301833
 - Update test.
 - Merge branch 'master' into JDK-8301833
 - Added trailing line terminator.
 - JDK-8301833: Add manual tests for FDLIBM porting

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12430/files
  - new: https://git.openjdk.org/jdk/pull/12430/files/89c4c658..b5f22449

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12430&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12430&range=01-02

  Stats: 583 lines in 7 files changed: 513 ins; 0 del; 70 mod
  Patch: https://git.openjdk.org/jdk/pull/12430.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12430/head:pull/12430

PR: https://git.openjdk.org/jdk/pull/12430

From stuefe at openjdk.org  Sat Feb 11 06:34:27 2023
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Sat, 11 Feb 2023 06:34:27 GMT
Subject: RFR: 8302154: Hidden classes created by LambdaMetaFactory can't be
 unloaded [v2]
In-Reply-To: <80S5iALXtwJyXDKAqu3ecLSY3FePCHYr_Vez_uoRs4Y=.c0256514-454b-4744-98f2-9d9106e981c4@github.com>
References: <YoZauVv8zvhdUw-LD25LrsMDItFbg3aXPU3deXwwFdQ=.c2839dea-12e5-4e0e-9579-eac9d8503932@github.com>
 <gKoLpwlXDxp2uaSKSkMArJl1Ym9VX1hoDFqQTTUpk8w=.e1dce669-5a42-4b66-ac4b-205718c8eb81@github.com>
 <jgxD2XApQjA92I_bzUejeTvyPjD6YWuVniri4LftYEQ=.5c3ff453-b8d0-4298-ae29-1602ac80e257@github.com>
 <80S5iALXtwJyXDKAqu3ecLSY3FePCHYr_Vez_uoRs4Y=.c0256514-454b-4744-98f2-9d9106e981c4@github.com>
Message-ID: <6YJK-1ezod9M_aR4bHS6Mesll8QWNjpDXmFj1YA42B0=.c363a6e1-b9e1-4f9c-8711-3f8fc0cf2d14@github.com>

On Fri, 10 Feb 2023 19:00:53 GMT, Volker Simonis <simonis at openjdk.org> wrote:

>> Even in JDK 11, a lambda proxy classes that's referenced by the cpCache (i.e., from a resolved invokedynamic instruction associated with a lamda expression) is always kept alive. See test below.
>> 
>> So if I understand correctly, this patch will not affect lamda expressions in Java source code. It affects only direct calls to `LambdaMetafactory.metafactory()`. Is this correct?
>> 
>> 
>> public class LambdaGC {
>>     public static void main(String[] args) throws Throwable  {
>>       System.out.println("Entering LambdaGC");
>>       doit(() -> {
>>           Thread.dumpStack();
>>       });
>>       for (int i = 0; i < 10; i++) {
>>             System.gc();
>>       }
>>       System.out.println("Finish LambdaGC");
>>     }
>>     static void doit(Runnable r) {
>>         r.run();
>>     }
>> }
>> 
>> $ java11 -cp . -XX:+UnlockDiagnosticVMOptions -XX:+ShowHiddenFrames -Xlog:class+load -Xlog:class+unload LambdaGC | grep LambdaGC
>> [0.022s][info][class,load] LambdaGC source: file:/jdk3/tmp/
>> Entering LambdaGC
>> [0.024s][info][class,load] LambdaGC$$Lambda$1/0x0000000840060840 source: LambdaGC
>> java.lang.Exception: Stack trace
>> 	at java.base/java.lang.Thread.dumpStack(Thread.java:1387)
>> 	at LambdaGC.lambda$main$0(LambdaGC.java:5)
>> 	at LambdaGC$$Lambda$1/0x0000000840060840.run(<Unknown>:1000000)
>> 	at LambdaGC.doit(LambdaGC.java:13)
>> 	at LambdaGC.main(LambdaGC.java:4)
>> Finish LambdaGC
>
> @iklam, I think your understanding is correct. While the bootstrap methods for Java Lambdas do call `LambdaMetafactory.metafactory()`, they store the resulting call site (for Lambdas a `BoundMethodHandle`) in the appendix slot of the constant pool cache entry of the invokedynamic bytecode. The `BoundMethodHandle` contains a reference to an instance of the generated lambda form (i.e. in your example `LambdaGC$$Lambda$1`). This is enough in order to keep `LambdaGC$$Lambda$1` alive and prevent its unloading.
> 
> Until now, `LambdaGC$$Lambda$1` was also strongly linked to its defining class loader, but I don't think that's necessary to keep it alive (because it is referenced from the call site which is referenced from the constant pool cache).
> 
> Running your example with `-Xlog:indy+methodhandles=debug` confirms this:
> 
> set_method_handle bc=186 appendix=0x000000062b821838 method=0x00000008000c7698 (local signature)
> {method}
>  - this oop:          0x00000008000c7698
>  - method holder:     'java/lang/invoke/Invokers$Holder'
>  ...
> appendix: java.lang.invoke.BoundMethodHandle$Species_L 
>  {0x000000062b821838} - klass: 'java/lang/invoke/BoundMethodHandle$Species_L'
>   - ---- fields (total size 5 words):
>   ...
>   - final 'argL0' 'Ljava/lang/Object;' @32  a 'LambdaGC$$Lambda$1+0x0000000801000400'{0x000000062b81e080} (0xc5703c10)

@simonis This may be a stupid question, but how exactly does your patch help with Metaspace consumption? I mean, how is the deallocation path with the patch now?

We still have the CLD loaded by the BootClassLoader, right? So it is still living in the metaspace arena of the bootclassloader, even if the Lambda class itself is collected earlier. How is this memory freed or reused?

If there were a way to prematurely collect its metadata via Metaspace::deallocate, then it could be reused at least by the bootloader itself. But I don't see it.

-----

>True but it was decided at that time for JEP 371 to make it strong so that the lambda proxy classes will share the same ClassLoaderData metaspace as other classes defined by the same loader. This reduces the memory footprint consumption.

Expanding on what @mlchung wrote, this has been a nice effect of JEP 371. Metaspace intra-chunk fragmentation went down since all these pesky little CLDs went away. It also saved some C-heap as a side effect for the CLDs itself.

Example, committed metaspace for 100k lambdas:
JDK11: 271MB
JDK15: (+JEP371): 221MB
JDK17: (+JEP371 +JEP387): 189MB

-------------

PR: https://git.openjdk.org/jdk/pull/12493

From skuksenko at openjdk.org  Sat Feb 11 16:06:25 2023
From: skuksenko at openjdk.org (Sergey Kuksenko)
Date: Sat, 11 Feb 2023 16:06:25 GMT
Subject: RFR: 8302204: Optimize BigDecimal.divide
In-Reply-To: <rUC0Dh_-1E0PZNJwM0GRH1KPu6prPotT-oeDTUdqjI4=.a8f7d3b7-a0f2-45a0-ae01-f37ef108d18f@github.com>
References: <rUC0Dh_-1E0PZNJwM0GRH1KPu6prPotT-oeDTUdqjI4=.a8f7d3b7-a0f2-45a0-ae01-f37ef108d18f@github.com>
Message-ID: <_6xQn0WEbeyiuMwLLvjMSslSJvYSN7SHMtXCrwCKsMQ=.b3891220-dcea-4ceb-ac97-647b15b98f38@github.com>

On Fri, 10 Feb 2023 10:00:05 GMT, Xiaowei Lu <duke at openjdk.org> wrote:

> [JDK-8269667](https://bugs.openjdk.org/browse/JDK-8269667) has uncovered the poor performance of BigDecimal.divide under certain circumstance.
> 
> We confront similar situations when benchmarking Spark3 on TPC-DS test kit. According to the flame-graph below, it is StripZeros that spends most of the time of BigDecimal.divide. Hence we propose this patch to optimize stripping zeros.
> ![?? 1](https://user-images.githubusercontent.com/39413832/218062061-53cd0220-776e-4b72-8b9a-6b0f11707986.png)
> 
> Currently, createAndStripZerosToMatchScale() is performed linearly. That is, the target value is parsed from back to front, each time stripping out single ?0?. To optimize, we can adopt the method of binary search. That is, each time we try to strip out ${scale/2} ?0?s. 
> 
> The performance looks good. Therotically, time complexity of our method is O(log n), while the current one is O(n). In practice, benchmarks on Spark3 show that 1/3 less time (102s->68s) is spent on TPC-DS query4. We also runs Jtreg and JCK to check correctness, and it seems fine.
> 
> More about environment: 
> we run Spark3.3.0 on Openjdk11, but it seems jdk version doesn?t have much impact on BigDecimal. Spark cluster consists of a main node and 2 core nodes, each has 4cores, 16g memory and 4x500GB storage.

"The performance looks good." - Could you support this statement with some benchmark results?
Thank you.

-------------

PR: https://git.openjdk.org/jdk/pull/12509

From duke at openjdk.org  Sat Feb 11 16:56:33 2023
From: duke at openjdk.org (SUN Guoyun)
Date: Sat, 11 Feb 2023 16:56:33 GMT
Subject: Integrated: 8301737:
 java/rmi/server/UnicastRemoteObject/serialFilter/FilterUROTest.java fail with
 -Xcomp
In-Reply-To: <l5m5_9io2QMSFNY7dBHT3Nr2I9Er8wmd92Ze8FP-XE0=.a40d29be-77be-4719-a0a0-71d032eea1e5@github.com>
References: <l5m5_9io2QMSFNY7dBHT3Nr2I9Er8wmd92Ze8FP-XE0=.a40d29be-77be-4719-a0a0-71d032eea1e5@github.com>
Message-ID: <JF2g51lUffh-LYxfVXxlSpf5UWiwajVDHRC50AbcRqQ=.54eaf9ce-5dae-4a29-abf1-2cadfc42e278@github.com>

On Fri, 3 Feb 2023 03:52:39 GMT, SUN Guoyun <duke at openjdk.org> wrote:

> Hi all,
> When -Xcomp be used, this testcase will use more codecaches, causing the GC to be triggered early, then causing this test failed on LoongArch64 architecture.
> 
> This PR fix the issue, Please help review it.
> 
> Thanks.

This pull request has now been integrated.

Changeset: 6f9f2b5d
Author:    sunguoyun <sunguoyun at loongson.cn>
Committer: Roger Riggs <rriggs at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/6f9f2b5d379315b6452718ccd7c5c953a6eff5d4
Stats:     3 lines in 1 file changed: 3 ins; 0 del; 0 mod

8301737: java/rmi/server/UnicastRemoteObject/serialFilter/FilterUROTest.java fail with -Xcomp

Reviewed-by: rriggs

-------------

PR: https://git.openjdk.org/jdk/pull/12399

From jlaskey at openjdk.org  Sat Feb 11 17:49:49 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Sat, 11 Feb 2023 17:49:49 GMT
Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates
 (Preview) [v40]
In-Reply-To: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
Message-ID: <rQog4uNSJmI3BjY7WzAKDkZPttL5RWlJDPPcKwec9aE=.3d2799ca-a8d2-4401-9b05-e6560da18cac@github.com>

> Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12).

Jim Laskey has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 55 commits:

 - Merge branch 'master' into 8285932
 - Minor correction to javadoc
 - Merge branch 'master' into 8285932
 - CSR review
 - Bring up to date
 - Merge branch 'master' into 8285932
 - Update to JDK 21
 - Merge branch 'master' into 8285932
 - Merge branch 'master' into 8285932
 - FormatProcessor changes
 - ... and 45 more: https://git.openjdk.org/jdk/compare/6f9f2b5d...95d219af

-------------

Changes: https://git.openjdk.org/jdk/pull/10889/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=39
  Stats: 9492 lines in 81 files changed: 9394 ins; 28 del; 70 mod
  Patch: https://git.openjdk.org/jdk/pull/10889.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10889/head:pull/10889

PR: https://git.openjdk.org/jdk/pull/10889

From joehw at openjdk.org  Sat Feb 11 22:36:37 2023
From: joehw at openjdk.org (Joe Wang)
Date: Sat, 11 Feb 2023 22:36:37 GMT
Subject: Integrated: 8301269: Update Commons BCEL to Version 6.7.0
In-Reply-To: <0RNjHfl4qXA0zwLZz10RDxolN96AdrScP27KS1bsT6A=.74cd0696-d037-405d-97eb-be3cbf1e849b@github.com>
References: <0RNjHfl4qXA0zwLZz10RDxolN96AdrScP27KS1bsT6A=.74cd0696-d037-405d-97eb-be3cbf1e849b@github.com>
Message-ID: <hnVrhormPxQ95l8Csl8Aa6nxREOWFaU0cZuDcnLVY-8=.a243a4d6-2c9f-4999-b98b-8ba9019f66cd@github.com>

On Wed, 8 Feb 2023 00:15:27 GMT, Joe Wang <joehw at openjdk.org> wrote:

> Update Commons BCEL in the JDK from 6.5.0 to 6.7.0. 
> 
> 1. Improvement
>    Code modernization (using relatively more modern language features), normalization (such as naming), javadocs, cleanup and minor improvements made up most of the changes. These changes do not change how BCEL works for the XSLT function in the JDK. Many of the changes unfortunately created long lines, for example merging multiple lines into a single long line, not what we would like to have in the JDK, but I have to leave them as they are so that they don't show up as changes in future updates. 
> 
> 2. Exclusions
>    As it has always been, the focus of the BCEL component is to satisfy the needs for the XSLT functionality. Classes not needed for the JDK are excluded as it has been done previously, this is especially true in the util package. The verifier package is also excluded. Methods and sources that have dependencies on the excluded classes are either removed or modified.
> 
> 3. Deprecation and Warnings
>    
>    Deprecated classes and contents relying on them are removed or modified to use proper methods without changing the functionality. Deprecated fields in the original source were changed to private ones in previous update in the JDK, however, since the update process applies sources from the upstream again, they were reverted back. In order to not have to go through them on every update, I'll keep the original source this time. 
> 
>     Warnings were one of the main reasons for the changes made to the original source. It has been done in the previous update. In this update, many of the previous JDK fixes on warnings have already been addressed in the upstream source as the result of item 1, thus lessoned the needs to reapply the warning patches. Fixed the rest of warnings as they showed up during build.
> 
> 4. Note that JRocket specific patches are not in the current code base.
> 
> 5. Test
>     Tier2 tests passed.
>     JCK XML tests passed.

This pull request has now been integrated.

Changeset: 6a44120a
Author:    Joe Wang <joehw at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/6a44120a16d0f06b4ed9f0ebf6b0919da7070287
Stats:     30511 lines in 334 files changed: 9313 ins; 10828 del; 10370 mod

8301269: Update Commons BCEL to Version 6.7.0

Reviewed-by: lancea

-------------

PR: https://git.openjdk.org/jdk/pull/12464

From alanb at openjdk.org  Sun Feb 12 08:50:30 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Sun, 12 Feb 2023 08:50:30 GMT
Subject: RFR: JDK-8301833: Add wide-ranging tests for FDLIBM porting [v3]
In-Reply-To: <wcQzv2zqfxXZ5HU5C-_ORlyQOegfREmknU6ShqYgQts=.4f1821f2-0dc6-480e-82f7-4a10e5402f1b@github.com>
References: <wgghXoOC-eICroAklhQSO8UYEBvYHF_QHZ4C_1wnW0Q=.61574f1b-9c40-4c34-b234-502b95a99c8f@github.com>
 <wcQzv2zqfxXZ5HU5C-_ORlyQOegfREmknU6ShqYgQts=.4f1821f2-0dc6-480e-82f7-4a10e5402f1b@github.com>
Message-ID: <QJxlOAx9IbSgoFXQ0z3PN5aqBTXecb2meBD0mQl1iQI=.a5c33681-2bae-4d60-8e59-129c02658427@github.com>

On Sat, 11 Feb 2023 03:04:51 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> To help add assurances that the main-line port of FDLIBM to Java is working correctly, added some long-running manual tests to probe that the transliteration port and the corresponding StrictMath method are in agreement on a large number of argument, say, all float values.
>> 
>> To test the transliteration port, this test can be run against a build where the JDK has *not* had the FDLIBM code used for StrictMath ported to Java.
>
> Joe Darcy 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:
> 
>  - Include log testing.
>  - Merge branch 'master' into JDK-8301833
>  - Update test.
>  - Merge branch 'master' into JDK-8301833
>  - Added trailing line terminator.
>  - JDK-8301833: Add manual tests for FDLIBM porting

The move to make this an automated tests and test every 1024th float is good.

-------------

Marked as reviewed by alanb (Reviewer).

PR: https://git.openjdk.org/jdk/pull/12430

From alanb at openjdk.org  Sun Feb 12 09:24:27 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Sun, 12 Feb 2023 09:24:27 GMT
Subject: RFR: 8300819: -Dfile.encoding=Cp943C option does not work as
 expected since jdk18 [v2]
In-Reply-To: <GB9IC03qS7HSGqP17sdu2qRK62ypV5FXYer6Ql44h2w=.9d2ac382-3ddf-4d38-baae-dc6fa936f0af@github.com>
References: <e0lHdFW5cwElhb81t2f3oFbWdlqeAMwI_nMwaqIxSd4=.0513038a-d43f-4924-bb01-ec9b71b0633b@github.com>
 <GB9IC03qS7HSGqP17sdu2qRK62ypV5FXYer6Ql44h2w=.9d2ac382-3ddf-4d38-baae-dc6fa936f0af@github.com>
Message-ID: <gFWJveS9adTzIuxsMxpH3OFqgLCgYR9t5ODcDbRnvEI=.bc388cc2-253f-441a-ac2a-5a8f8a722a8b@github.com>

On Sun, 22 Jan 2023 23:17:10 GMT, Ichiroh Takiguchi <itakiguchi at openjdk.org> wrote:

>> On jdk17, following testcase works fine on Linux platform.
>> 
>> Testcase
>> 
>> $ cat cstest1.java
>> import java.nio.charset.*;
>> 
>> public class cstest1 {
>>   public static void main(String[] args) throws Exception {
>>     Charset cs = Charset.defaultCharset();
>>     System.out.println(cs + ", " + cs.getClass() + ", " + cs.getClass().getModule());
>>   }
>> }
>> 
>> 
>> $ ~/jdk-17.0.6+10/bin/java -Dfile.encoding=Cp943C -showversion cstest1
>> openjdk version "17.0.6" 2023-01-17
>> OpenJDK Runtime Environment Temurin-17.0.6+10 (build 17.0.6+10)
>> OpenJDK 64-Bit Server VM Temurin-17.0.6+10 (build 17.0.6+10, mixed mode, sharing)
>> x-IBM943C, class sun.nio.cs.ext.IBM943C, module jdk.charsets
>> 
>> 
>> But it does not work as expected on jdk18 and jdk21b06
>> 
>> $ ~/jdk-18.0.2.1+1/bin/java -Dfile.encoding=Cp943C -showversion cstest1
>> openjdk version "18.0.2.1" 2022-08-18
>> OpenJDK Runtime Environment Temurin-18.0.2.1+1 (build 18.0.2.1+1)
>> OpenJDK 64-Bit Server VM Temurin-18.0.2.1+1 (build 18.0.2.1+1, mixed mode, sharing)
>> UTF-8, class sun.nio.cs.UTF_8, module java.base
>> $ ~/jdk-21/bin/java -Dfile.encoding=Cp943C -showversion cstest1
>> openjdk version "21-ea" 2023-09-19
>> OpenJDK Runtime Environment (build 21-ea+6-365)
>> OpenJDK 64-Bit Server VM (build 21-ea+6-365, mixed mode, sharing)
>> UTF-8, class sun.nio.cs.UTF_8, module java.base
>> 
>> 
>> Fixed result is as follows:
>> 
>> $ java -Dfile.encoding=Cp943C -showversion PrintDefaultCharset
>> openjdk version "21-internal" 2023-09-19
>> OpenJDK Runtime Environment (build 21-internal-adhoc.jdktest.jdk)
>> OpenJDK 64-Bit Server VM (build 21-internal-adhoc.jdktest.jdk, mixed mode, sharing)
>> x-IBM943C
>
> Ichiroh Takiguchi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8300819: -Dfile.encoding=Cp943C option does not work as expected since jdk18

I think this PR can be closed as the default charset must be in java.base.

-------------

PR: https://git.openjdk.org/jdk/pull/12132

From alanb at openjdk.org  Sun Feb 12 09:37:26 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Sun, 12 Feb 2023 09:37:26 GMT
Subject: RFR: 8298619: java/io/File/GetXSpace.java is failing
In-Reply-To: <134wQrl9F4McK30DN1EvRTuqCx-WDMTgym1traoL8fI=.1247d3ff-0413-415a-9f3f-6a30b59f62d5@github.com>
References: <6LnAAIclo5mZZgba4XUSTSc72vyNrBinzUlO9-kJXbU=.fe0c5e94-9e36-4484-b8e7-0f19cb10cb05@github.com>
 <DTNziTj7KbkeG3LvpMREAi9WP9XRczQUdP_1-XTvp2c=.b9b78dec-3879-4626-9174-306e57ce83a4@github.com>
 <134wQrl9F4McK30DN1EvRTuqCx-WDMTgym1traoL8fI=.1247d3ff-0413-415a-9f3f-6a30b59f62d5@github.com>
Message-ID: <Kia7JD1spnBOVIg-KuMO17m5UJClbL8R1SivnOyx8_0=.3950cd71-ce62-47ca-9ac6-0d16071567e3@github.com>

On Fri, 10 Feb 2023 17:10:46 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Another possibility would be to add a native method to the test itself to invoke [GetDiskSpaceInformationW](https://learn.microsoft.com/en-us/windows/win32/api/fileapi/nf-fileapi-getdiskspaceinformationw) to obtain the value of `CallerTotalAllocationUnits` (in bytes) from the [DISK_SPACE_INFORMATION](https://learn.microsoft.com/en-us/windows/win32/api/fileapi/ns-fileapi-disk_space_information) structure.

That would be more reliable than parsing the output of `fsutil volume` so worth trying. You might have to dig into which of these win32 works with quotas as that seems to be part of the issue. The JDK uses GetDiskFreeSpaceExW. Also this test might have to do a few iterations so that it captures free space info while the system is in quiescence - I suspect some of the reliability issues has been concurrent activity that changes the volume space usage significantly while this test is running.

-------------

PR: https://git.openjdk.org/jdk/pull/12397

From darcy at openjdk.org  Sun Feb 12 17:48:39 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Sun, 12 Feb 2023 17:48:39 GMT
Subject: Integrated: JDK-8301833: Add wide-ranging tests for FDLIBM porting
In-Reply-To: <wgghXoOC-eICroAklhQSO8UYEBvYHF_QHZ4C_1wnW0Q=.61574f1b-9c40-4c34-b234-502b95a99c8f@github.com>
References: <wgghXoOC-eICroAklhQSO8UYEBvYHF_QHZ4C_1wnW0Q=.61574f1b-9c40-4c34-b234-502b95a99c8f@github.com>
Message-ID: <9LSvoWRpVOYGLF-g8W9o6Rs32abgR9RaVMhMzsZpyjI=.95216b1c-33fb-42c7-a08e-ff35009d8adb@github.com>

On Mon, 6 Feb 2023 01:50:55 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> To help add assurances that the main-line port of FDLIBM to Java is working correctly, added some long-running manual tests to probe that the transliteration port and the corresponding StrictMath method are in agreement on a large number of argument, say, all float values.
> 
> To test the transliteration port, this test can be run against a build where the JDK has *not* had the FDLIBM code used for StrictMath ported to Java.

This pull request has now been integrated.

Changeset: 8049e59a
Author:    Joe Darcy <darcy at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/8049e59a5c5ab5bd2055face6df02445859335ca
Stats:     169 lines in 1 file changed: 169 ins; 0 del; 0 mod

8301833: Add wide-ranging tests for FDLIBM porting

Reviewed-by: bpb, alanb

-------------

PR: https://git.openjdk.org/jdk/pull/12430

From alanb at openjdk.org  Sun Feb 12 18:18:26 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Sun, 12 Feb 2023 18:18:26 GMT
Subject: RFR: 8301627: System.exit and Runtime.exit debug logging
In-Reply-To: <OzJeJH5yxolKPChcUisqtzGYF_MU3oOJdx6HPhsXjBw=.15eefe39-efe1-433e-a6ac-02b4a730f264@github.com>
References: <OzJeJH5yxolKPChcUisqtzGYF_MU3oOJdx6HPhsXjBw=.15eefe39-efe1-433e-a6ac-02b4a730f264@github.com>
Message-ID: <2zbWTodXVENcsxo-J5IcBLxQoHqnIdtmB4TnV5w7Uag=.d4aa5964-5e0e-41b5-b6f9-39f4edb1b2b4@github.com>

On Fri, 10 Feb 2023 20:33:39 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> It can be difficult to find the cause of calls to `java.lang.System.exit(status)` and `Runtime.exit(status)` because the Java runtime exits.
> The status value and stack trace are logged using the System Logger named `java.lang.Runtime` with message level `System.Logger.Level.DEBUG`.

src/java.base/share/classes/java/lang/Shutdown.java line 162:

> 160:      * If the system logger {@code java.lang.Runtime} is enabled for logging level DEBUG/FINE
> 161:      * the stack trace of the call to {@code Runtime.exit()} or {@code System.exit()}
> 162:      * is logged.

Shutdown is not a public class so this impNote won't appear in the APIs docs. Should it move to Runtime.exit and System.exit?  If it moved to a public API then "system logger" could link to System.Logger. Also would it be more correct to say "a system logger named "java.lang.Runtime" is enabled for logging levels DEBUG or FINE"?

-------------

PR: https://git.openjdk.org/jdk/pull/12517

From alanb at openjdk.org  Sun Feb 12 18:33:28 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Sun, 12 Feb 2023 18:33:28 GMT
Subject: RFR: 8301627: System.exit and Runtime.exit debug logging
In-Reply-To: <OzJeJH5yxolKPChcUisqtzGYF_MU3oOJdx6HPhsXjBw=.15eefe39-efe1-433e-a6ac-02b4a730f264@github.com>
References: <OzJeJH5yxolKPChcUisqtzGYF_MU3oOJdx6HPhsXjBw=.15eefe39-efe1-433e-a6ac-02b4a730f264@github.com>
Message-ID: <_GUTHwvRBNvKqfa5pF_wRjqPo18lfZBGbbOJi_4rpgw=.47dc28aa-b33d-4de9-be3e-240c1321ae4b@github.com>

On Fri, 10 Feb 2023 20:33:39 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> It can be difficult to find the cause of calls to `java.lang.System.exit(status)` and `Runtime.exit(status)` because the Java runtime exits.
> The status value and stack trace are logged using the System Logger named `java.lang.Runtime` with message level `System.Logger.Level.DEBUG`.

test/jdk/java/lang/runtime/RuntimeExitLogTest.java line 89:

> 87:         }
> 88:         cmd.add(this.getClass().getName());
> 89:         cmd.add(Integer.toString(status));

Another possibility for testing this is to launch with ` --limit-modules java.base -Djdk.system.logger.level=DEBUG` to use the simple console implementation that is in java.base and avoid needing properties files for j.u.logging. Just mentioning is an option to make it simple.

-------------

PR: https://git.openjdk.org/jdk/pull/12517

From darcy at openjdk.org  Sun Feb 12 19:30:09 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Sun, 12 Feb 2023 19:30:09 GMT
Subject: RFR: JDK-8301444: Port fdlibm hyperbolic transcendental functions
 to Java [v8]
In-Reply-To: <_s8xnppoDTnAajAjlmfB-dX5DBdawUcSSPaGWGLzFBk=.cdbf468a-ace7-45e5-a25a-833c760b776c@github.com>
References: <_s8xnppoDTnAajAjlmfB-dX5DBdawUcSSPaGWGLzFBk=.cdbf468a-ace7-45e5-a25a-833c760b776c@github.com>
Message-ID: <KKTgxck0k8-3zjmnTV14lFaPMivEUCLBhSjGqdlb_hA=.dae3b681-c0b3-48e4-9af7-2a6a519a7a37@github.com>

> Initial pass of porting FDLIBM sinh/cosh/tanh to Java. I do intend to refactor the regression tests a bit to reduce duplication, but the actual ports should be ready for review.
> 
> Diff'ing the ports as before, original vs transliteration port:
> 
> 
> $ diff -w Hyperbolic.c Hyperbolic.translit.java
> 1c1
> < /* __ieee754_sinh(x)
> ---
>>     /**
> 17a18,19
>>     static class Sinh {
>>         private static final double one = 1.0, shuge = 1.0e307;
> 19,33c21
> < #include "fdlibm.h"
> < 
> < #ifdef __STDC__
> < static const double one = 1.0, shuge = 1.0e307;
> < #else
> < static double one = 1.0, shuge = 1.0e307;
> < #endif
> < 
> < #ifdef __STDC__
> <         double __ieee754_sinh(double x)
> < #else
> <         double __ieee754_sinh(x)
> <         double x;
> < #endif
> < {
> ---
>>         private static double compute(double x) {
> 36c24
> <         unsigned lx;
> ---
>>             /* unsigned */ int lx;
> 51c39
> <             t = expm1(fabs(x));
> ---
>>                 t = FdlibmTranslit.expm1(Math.abs(x));
> 57c45
> <         if (ix < 0x40862E42)  return h*__ieee754_exp(fabs(x));
> ---
>>             if (ix < 0x40862E42)  return h*StrictMath.exp(Math.abs(x)); // TODO switch to translit
> 60,62c48,52
> <         lx = *( (((*(unsigned*)&one)>>29)) + (unsigned*)&x);
> <         if (ix<0x408633CE || ((ix==0x408633ce)&&(lx<=(unsigned)0x8fb9f87d))) {
> <             w = __ieee754_exp(0.5*fabs(x));
> ---
>>             // lx = *( (((*(unsigned*)&one)>>29)) + (unsigned*)&x);
>>             // lx =  (((*(unsigned*)&one)>>29)) + (unsigned*)&x ;
>>             lx = __LO(x);
>>             if (ix<0x408633CE || ((ix==0x408633ce)&&(Long.compareUnsigned(lx, 0x8fb9f87d) <= 0 ))) {
>>                 w = StrictMath.exp(0.5*Math.abs(x)); // TODO switch to translit
> 70c60,62
> < /* __ieee754_cosh(x)
> ---
>>     }
>> 
>>     /**
> 90,105c82,84
> < 
> < #include "fdlibm.h"
> < 
> < #ifdef __STDC__
> < static const double one = 1.0, half=0.5, huge = 1.0e300;
> < #else
> < static double one = 1.0, half=0.5, huge = 1.0e300;
> < #endif
> < 
> < #ifdef __STDC__
> <         double __ieee754_cosh(double x)
> < #else
> <         double __ieee754_cosh(x)
> <         double x;
> < #endif
> < {
> ---
>>     static class Cosh {
>>         private static final double one = 1.0, half=0.5, huge = 1.0e300;
>>         private static double compute(double x) {
> 108c87
> <         unsigned lx;
> ---
>>             /*unsigned*/ int lx;
> 119c98
> <             t = expm1(fabs(x));
> ---
>>                 t = expm1(Math.abs(x));
> 127c106
> <                 t = __ieee754_exp(fabs(x));
> ---
>>                 t = StrictMath.exp(Math.abs(x)); // TODO switch to translit
> 132c111
> <         if (ix < 0x40862E42)  return half*__ieee754_exp(fabs(x));
> ---
>>             if (ix < 0x40862E42)  return half*StrictMath.exp(Math.abs(x)); // TODO switch to translit
> 135c114
> <         lx = *( (((*(unsigned*)&one)>>29)) + (unsigned*)&x);
> ---
>>             lx = __LO(x);
> 137,138c116,117
> <               ((ix==0x408633ce)&&(lx<=(unsigned)0x8fb9f87d))) {
> <             w = __ieee754_exp(half*fabs(x));
> ---
>>                 ((ix==0x408633ce)&&(Integer.compareUnsigned(lx, 0x8fb9f87d) <= 0))) {
>>                 w = StrictMath.exp(half*Math.abs(x)); // TODO switch to translit
> 146c125,127
> < /* Tanh(x)
> ---
>>     }
>> 
>>     /**
> 169,184c150,152
> < 
> < #include "fdlibm.h"
> < 
> < #ifdef __STDC__
> < static const double one=1.0, two=2.0, tiny = 1.0e-300;
> < #else
> < static double one=1.0, two=2.0, tiny = 1.0e-300;
> < #endif
> < 
> < #ifdef __STDC__
> <         double tanh(double x)
> < #else
> <         double tanh(x)
> <         double x;
> < #endif
> < {
> ---
>>     static class Tanh {
>>         private static final double one=1.0, two=2.0, tiny = 1.0e-300;
>>         static double compute(double x) {
> 203c171
> <                 t = expm1(two*fabs(x));
> ---
>>                     t = expm1(two*Math.abs(x));
> 206c174
> <                 t = expm1(-two*fabs(x));
> ---
>>                     t = expm1(-two*Math.abs(x));
> 214a183
>>     }
> 
> 
> Note that the original has a in-line version of the "__LO" macro rather than using the macro.
> 
> 
> And transliteration vs more idiomatic:
> 
> 
> $ diff -w Hyperbolic.translit.java Hyperbolic.fdlibm.java 
> 21c21
> <         private static double compute(double x) {
> ---
>>          static double compute(double x) {
> 26c26
> <             /* High word of |x|. */
> ---
>>             // High word of |x|
> 28c28
> <             ix = jx&0x7fffffff;
> ---
>>             ix = jx & 0x7fff_ffff;
> 30,31c30,33
> <             /* x is INF or NaN */
> <             if(ix>=0x7ff00000) return x+x;
> ---
>>             // x is INF or NaN
>>             if ( ix >= 0x7ff0_0000) {
>>                 return x + x;
>>             }
> 34,40c36,48
> <             if (jx<0) h = -h;
> <             /* |x| in [0,22], return sign(x)*0.5*(E+E/(E+1))) */
> <             if (ix < 0x40360000) {          /* |x|<22 */
> <                 if (ix<0x3e300000)          /* |x|<2**-28 */
> <                     if(shuge+x>one) return x;/* sinh(tiny) = tiny with inexact */
> <                 t = FdlibmTranslit.expm1(Math.abs(x));
> <                 if(ix<0x3ff00000) return h*(2.0*t-t*t/(t+one));
> ---
>>             if ( jx < 0) {
>>                 h = -h;
>>             }
>>             // |x| in [0,22], return sign(x)*0.5*(E+E/(E+1)))
>>             if (ix < 0x4036_0000) {          // |x| < 22
>>                 if (ix < 0x3e30_0000)        // |x| < 2**-28
>>                     if (shuge + x > one) {   // sinh(tiny) = tiny with inexact
>>                         return x;
>>                     }
>>                 t = StrictMath.expm1(Math.abs(x));
>>                 if (ix < 0x3ff0_0000) {
>>                     return h*(2.0 * t - t*t/(t + one));
>>                 }
> 44,45c52,55
> <             /* |x| in [22, log(maxdouble)] return 0.5*exp(|x|) */
> <             if (ix < 0x40862E42)  return h*StrictMath.exp(Math.abs(x)); // TODO switch to translit
> ---
>>             // |x| in [22, log(maxdouble)] return 0.5*exp(|x|)
>>             if (ix < 0x4086_2E42) {
>>                 return h*StrictMath.exp(Math.abs(x));
>>             }
> 47,49c57
> <             /* |x| in [log(maxdouble), overflowthresold] */
> <             // lx = *( (((*(unsigned*)&one)>>29)) + (unsigned*)&x);
> <             // lx =  (((*(unsigned*)&one)>>29)) + (unsigned*)&x ;
> ---
>>             // |x| in [log(maxdouble), overflowthresold]
> 51,52c59,62
> <             if (ix<0x408633CE || ((ix==0x408633ce)&&(Long.compareUnsigned(lx, 0x8fb9f87d) <= 0 ))) {
> <                 w = StrictMath.exp(0.5*Math.abs(x)); // TODO switch to translit
> ---
>>             if (ix < 0x4086_33CE ||
>>                 ((ix == 0x4086_33ce) &&
>>                  (Long.compareUnsigned(lx, 0x8fb9_f87d) <= 0 ))) {
>>                 w = StrictMath.exp(0.5 * Math.abs(x));
> 57c67
> <             /* |x| > overflowthresold, sinh(x) overflow */
> ---
>>             // |x| > overflowthresold, sinh(x) overflow
> 84c94
> <         private static double compute(double x) {
> ---
>>         static double compute(double x) {
> 89c99
> <             /* High word of |x|. */
> ---
>>             // High word of |x|
> 91c101
> <             ix &= 0x7fffffff;
> ---
>>             ix &= 0x7fff_ffff;
> 93,94c103,106
> <             /* x is INF or NaN */
> <             if(ix>=0x7ff00000) return x*x;
> ---
>>             // x is INF or NaN
>>             if (ix >= 0x7ff_00000) {
>>                 return x*x;
>>             }
> 96,98c108,110
> <             /* |x| in [0,0.5*ln2], return 1+expm1(|x|)^2/(2*exp(|x|)) */
> <             if(ix<0x3fd62e43) {
> <                 t = expm1(Math.abs(x));
> ---
>>             // |x| in [0,0.5*ln2], return 1+expm1(|x|)^2/(2*exp(|x|))
>>             if (ix < 0x3fd6_2e43) {
>>                 t = StrictMath.expm1(Math.abs(x));
> 100c112,114
> <                 if (ix<0x3c800000) return w;        /* cosh(tiny) = 1 */
> ---
>>                 if (ix < 0x3c80_0000) { // cosh(tiny) = 1
>>                     return w;
>>                 }
> 104,106c118,120
> <             /* |x| in [0.5*ln2,22], return (exp(|x|)+1/exp(|x|)/2; */
> <             if (ix < 0x40360000) {
> <                 t = StrictMath.exp(Math.abs(x)); // TODO switch to translit
> ---
>>             // |x| in [0.5*ln2, 22], return (exp(|x|) + 1/exp(|x|)/2
>>             if (ix < 0x4036_0000) {
>>                 t = StrictMath.exp(Math.abs(x));
> 110,111c124,127
> <             /* |x| in [22, log(maxdouble)] return half*exp(|x|) */
> <             if (ix < 0x40862E42)  return half*StrictMath.exp(Math.abs(x)); // TODO switch to translit
> ---
>>             // |x| in [22, log(maxdouble)] return half*exp(|x|)
>>             if (ix < 0x4086_2E42) {
>>                 return half*StrictMath.exp(Math.abs(x));
>>             }
> 113c129
> <             /* |x| in [log(maxdouble), overflowthresold] */
> ---
>>             // |x| in [log(maxdouble), overflowthresold]
> 115,117c131,134
> <             if (ix<0x408633CE ||
> <                 ((ix==0x408633ce)&&(Integer.compareUnsigned(lx, 0x8fb9f87d) <= 0))) {
> <                 w = StrictMath.exp(half*Math.abs(x)); // TODO switch to translit
> ---
>>             if (ix<0x4086_33CE ||
>>                 ((ix == 0x4086_33ce) &&
>>                  (Integer.compareUnsigned(lx, 0x8fb9_f87d) <= 0))) {
>>                 w = StrictMath.exp(half*Math.abs(x));
> 122c139
> <             /* |x| > overflowthresold, cosh(x) overflow */
> ---
>>             // |x| > overflowthresold, cosh(x) overflow
> 126d142
> < 
> 156c172
> <             /* High word of |x|. */
> ---
>>             // High word of |x|.
> 158c174
> <             ix = jx&0x7fffffff;
> ---
>>             ix = jx & 0x7fff_ffff;
> 160,163c176,182
> <             /* x is INF or NaN */
> <             if(ix>=0x7ff00000) {
> <                 if (jx>=0) return one/x+one;    /* tanh(+-inf)=+-1 */
> <                 else       return one/x-one;    /* tanh(NaN) = NaN */
> ---
>>             // x is INF or NaN
>>             if (ix >= 0x7ff0_0000) {
>>                 if (jx >= 0) {  // tanh(+-inf)=+-1
>>                     return one/x + one;
>>                 } else {        // tanh(NaN) = NaN
>>                     return one/x - one;
>>                 }
> 166,171c185,190
> <             /* |x| < 22 */
> <             if (ix < 0x40360000) {          /* |x|<22 */
> <                 if (ix<0x3c800000)          /* |x|<2**-55 */
> <                     return x*(one+x);       /* tanh(small) = small */
> <                 if (ix>=0x3ff00000) {       /* |x|>=1  */
> <                     t = expm1(two*Math.abs(x));
> ---
>>             // |x| < 22
>>             if (ix < 0x4036_0000) {          // |x| < 22
>>                 if (ix<0x3c80_0000)          // |x| < 2**-55
>>                     return x*(one + x);      // tanh(small) = small
>>                 if (ix>=0x3ff0_0000) {       // |x| >= 1
>>                     t = StrictMath.expm1(two*Math.abs(x));
> 174c193
> <                     t = expm1(-two*Math.abs(x));
> ---
>>                     t = StrictMath.expm1(-two*Math.abs(x));
> 177,179c196,197
> <                 /* |x| > 22, return +-1 */
> <             } else {
> <                 z = one - tiny;             /* raised inexact flag */
> ---
>>             } else { // |x| > 22, return +-1
>>                 z = one - tiny;             // raised inexact flag

Joe Darcy 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 exhausting test coverage.
 - Merge branch 'master' into JDK-8301444
 - Merge branch 'master' into JDK-8301444
 - Improve exp usage.
 - Add additional note.
 - Respond to review feedback.
 - Correct overflow limit in regression test.
 - Two more spacing fixes.
 - Implement spacing improvements from code review comments.
 - JDK-8301444: Port fdlibm hyperbolic transcendental functions to Java

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12429/files
  - new: https://git.openjdk.org/jdk/pull/12429/files/5a295967..923c2b3a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12429&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12429&range=06-07

  Stats: 30692 lines in 339 files changed: 9488 ins; 10830 del; 10374 mod
  Patch: https://git.openjdk.org/jdk/pull/12429.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12429/head:pull/12429

PR: https://git.openjdk.org/jdk/pull/12429

From darcy at openjdk.org  Sun Feb 12 20:34:06 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Sun, 12 Feb 2023 20:34:06 GMT
Subject: RFR: JDK-8301444: Port fdlibm hyperbolic transcendental functions
 to Java [v9]
In-Reply-To: <_s8xnppoDTnAajAjlmfB-dX5DBdawUcSSPaGWGLzFBk=.cdbf468a-ace7-45e5-a25a-833c760b776c@github.com>
References: <_s8xnppoDTnAajAjlmfB-dX5DBdawUcSSPaGWGLzFBk=.cdbf468a-ace7-45e5-a25a-833c760b776c@github.com>
Message-ID: <cBys5L3ZFx3G8VaXO6YDbjUv5LGD8_cJ8oXfBBDBwN4=.0faf2ad7-ebfa-422d-9413-bff7ebbd807f@github.com>

> Initial pass of porting FDLIBM sinh/cosh/tanh to Java. I do intend to refactor the regression tests a bit to reduce duplication, but the actual ports should be ready for review.
> 
> Diff'ing the ports as before, original vs transliteration port:
> 
> 
> $ diff -w Hyperbolic.c Hyperbolic.translit.java
> 1c1
> < /* __ieee754_sinh(x)
> ---
>>     /**
> 17a18,19
>>     static class Sinh {
>>         private static final double one = 1.0, shuge = 1.0e307;
> 19,33c21
> < #include "fdlibm.h"
> < 
> < #ifdef __STDC__
> < static const double one = 1.0, shuge = 1.0e307;
> < #else
> < static double one = 1.0, shuge = 1.0e307;
> < #endif
> < 
> < #ifdef __STDC__
> <         double __ieee754_sinh(double x)
> < #else
> <         double __ieee754_sinh(x)
> <         double x;
> < #endif
> < {
> ---
>>         private static double compute(double x) {
> 36c24
> <         unsigned lx;
> ---
>>             /* unsigned */ int lx;
> 51c39
> <             t = expm1(fabs(x));
> ---
>>                 t = FdlibmTranslit.expm1(Math.abs(x));
> 57c45
> <         if (ix < 0x40862E42)  return h*__ieee754_exp(fabs(x));
> ---
>>             if (ix < 0x40862E42)  return h*StrictMath.exp(Math.abs(x)); // TODO switch to translit
> 60,62c48,52
> <         lx = *( (((*(unsigned*)&one)>>29)) + (unsigned*)&x);
> <         if (ix<0x408633CE || ((ix==0x408633ce)&&(lx<=(unsigned)0x8fb9f87d))) {
> <             w = __ieee754_exp(0.5*fabs(x));
> ---
>>             // lx = *( (((*(unsigned*)&one)>>29)) + (unsigned*)&x);
>>             // lx =  (((*(unsigned*)&one)>>29)) + (unsigned*)&x ;
>>             lx = __LO(x);
>>             if (ix<0x408633CE || ((ix==0x408633ce)&&(Long.compareUnsigned(lx, 0x8fb9f87d) <= 0 ))) {
>>                 w = StrictMath.exp(0.5*Math.abs(x)); // TODO switch to translit
> 70c60,62
> < /* __ieee754_cosh(x)
> ---
>>     }
>> 
>>     /**
> 90,105c82,84
> < 
> < #include "fdlibm.h"
> < 
> < #ifdef __STDC__
> < static const double one = 1.0, half=0.5, huge = 1.0e300;
> < #else
> < static double one = 1.0, half=0.5, huge = 1.0e300;
> < #endif
> < 
> < #ifdef __STDC__
> <         double __ieee754_cosh(double x)
> < #else
> <         double __ieee754_cosh(x)
> <         double x;
> < #endif
> < {
> ---
>>     static class Cosh {
>>         private static final double one = 1.0, half=0.5, huge = 1.0e300;
>>         private static double compute(double x) {
> 108c87
> <         unsigned lx;
> ---
>>             /*unsigned*/ int lx;
> 119c98
> <             t = expm1(fabs(x));
> ---
>>                 t = expm1(Math.abs(x));
> 127c106
> <                 t = __ieee754_exp(fabs(x));
> ---
>>                 t = StrictMath.exp(Math.abs(x)); // TODO switch to translit
> 132c111
> <         if (ix < 0x40862E42)  return half*__ieee754_exp(fabs(x));
> ---
>>             if (ix < 0x40862E42)  return half*StrictMath.exp(Math.abs(x)); // TODO switch to translit
> 135c114
> <         lx = *( (((*(unsigned*)&one)>>29)) + (unsigned*)&x);
> ---
>>             lx = __LO(x);
> 137,138c116,117
> <               ((ix==0x408633ce)&&(lx<=(unsigned)0x8fb9f87d))) {
> <             w = __ieee754_exp(half*fabs(x));
> ---
>>                 ((ix==0x408633ce)&&(Integer.compareUnsigned(lx, 0x8fb9f87d) <= 0))) {
>>                 w = StrictMath.exp(half*Math.abs(x)); // TODO switch to translit
> 146c125,127
> < /* Tanh(x)
> ---
>>     }
>> 
>>     /**
> 169,184c150,152
> < 
> < #include "fdlibm.h"
> < 
> < #ifdef __STDC__
> < static const double one=1.0, two=2.0, tiny = 1.0e-300;
> < #else
> < static double one=1.0, two=2.0, tiny = 1.0e-300;
> < #endif
> < 
> < #ifdef __STDC__
> <         double tanh(double x)
> < #else
> <         double tanh(x)
> <         double x;
> < #endif
> < {
> ---
>>     static class Tanh {
>>         private static final double one=1.0, two=2.0, tiny = 1.0e-300;
>>         static double compute(double x) {
> 203c171
> <                 t = expm1(two*fabs(x));
> ---
>>                     t = expm1(two*Math.abs(x));
> 206c174
> <                 t = expm1(-two*fabs(x));
> ---
>>                     t = expm1(-two*Math.abs(x));
> 214a183
>>     }
> 
> 
> Note that the original has a in-line version of the "__LO" macro rather than using the macro.
> 
> 
> And transliteration vs more idiomatic:
> 
> 
> $ diff -w Hyperbolic.translit.java Hyperbolic.fdlibm.java 
> 21c21
> <         private static double compute(double x) {
> ---
>>          static double compute(double x) {
> 26c26
> <             /* High word of |x|. */
> ---
>>             // High word of |x|
> 28c28
> <             ix = jx&0x7fffffff;
> ---
>>             ix = jx & 0x7fff_ffff;
> 30,31c30,33
> <             /* x is INF or NaN */
> <             if(ix>=0x7ff00000) return x+x;
> ---
>>             // x is INF or NaN
>>             if ( ix >= 0x7ff0_0000) {
>>                 return x + x;
>>             }
> 34,40c36,48
> <             if (jx<0) h = -h;
> <             /* |x| in [0,22], return sign(x)*0.5*(E+E/(E+1))) */
> <             if (ix < 0x40360000) {          /* |x|<22 */
> <                 if (ix<0x3e300000)          /* |x|<2**-28 */
> <                     if(shuge+x>one) return x;/* sinh(tiny) = tiny with inexact */
> <                 t = FdlibmTranslit.expm1(Math.abs(x));
> <                 if(ix<0x3ff00000) return h*(2.0*t-t*t/(t+one));
> ---
>>             if ( jx < 0) {
>>                 h = -h;
>>             }
>>             // |x| in [0,22], return sign(x)*0.5*(E+E/(E+1)))
>>             if (ix < 0x4036_0000) {          // |x| < 22
>>                 if (ix < 0x3e30_0000)        // |x| < 2**-28
>>                     if (shuge + x > one) {   // sinh(tiny) = tiny with inexact
>>                         return x;
>>                     }
>>                 t = StrictMath.expm1(Math.abs(x));
>>                 if (ix < 0x3ff0_0000) {
>>                     return h*(2.0 * t - t*t/(t + one));
>>                 }
> 44,45c52,55
> <             /* |x| in [22, log(maxdouble)] return 0.5*exp(|x|) */
> <             if (ix < 0x40862E42)  return h*StrictMath.exp(Math.abs(x)); // TODO switch to translit
> ---
>>             // |x| in [22, log(maxdouble)] return 0.5*exp(|x|)
>>             if (ix < 0x4086_2E42) {
>>                 return h*StrictMath.exp(Math.abs(x));
>>             }
> 47,49c57
> <             /* |x| in [log(maxdouble), overflowthresold] */
> <             // lx = *( (((*(unsigned*)&one)>>29)) + (unsigned*)&x);
> <             // lx =  (((*(unsigned*)&one)>>29)) + (unsigned*)&x ;
> ---
>>             // |x| in [log(maxdouble), overflowthresold]
> 51,52c59,62
> <             if (ix<0x408633CE || ((ix==0x408633ce)&&(Long.compareUnsigned(lx, 0x8fb9f87d) <= 0 ))) {
> <                 w = StrictMath.exp(0.5*Math.abs(x)); // TODO switch to translit
> ---
>>             if (ix < 0x4086_33CE ||
>>                 ((ix == 0x4086_33ce) &&
>>                  (Long.compareUnsigned(lx, 0x8fb9_f87d) <= 0 ))) {
>>                 w = StrictMath.exp(0.5 * Math.abs(x));
> 57c67
> <             /* |x| > overflowthresold, sinh(x) overflow */
> ---
>>             // |x| > overflowthresold, sinh(x) overflow
> 84c94
> <         private static double compute(double x) {
> ---
>>         static double compute(double x) {
> 89c99
> <             /* High word of |x|. */
> ---
>>             // High word of |x|
> 91c101
> <             ix &= 0x7fffffff;
> ---
>>             ix &= 0x7fff_ffff;
> 93,94c103,106
> <             /* x is INF or NaN */
> <             if(ix>=0x7ff00000) return x*x;
> ---
>>             // x is INF or NaN
>>             if (ix >= 0x7ff_00000) {
>>                 return x*x;
>>             }
> 96,98c108,110
> <             /* |x| in [0,0.5*ln2], return 1+expm1(|x|)^2/(2*exp(|x|)) */
> <             if(ix<0x3fd62e43) {
> <                 t = expm1(Math.abs(x));
> ---
>>             // |x| in [0,0.5*ln2], return 1+expm1(|x|)^2/(2*exp(|x|))
>>             if (ix < 0x3fd6_2e43) {
>>                 t = StrictMath.expm1(Math.abs(x));
> 100c112,114
> <                 if (ix<0x3c800000) return w;        /* cosh(tiny) = 1 */
> ---
>>                 if (ix < 0x3c80_0000) { // cosh(tiny) = 1
>>                     return w;
>>                 }
> 104,106c118,120
> <             /* |x| in [0.5*ln2,22], return (exp(|x|)+1/exp(|x|)/2; */
> <             if (ix < 0x40360000) {
> <                 t = StrictMath.exp(Math.abs(x)); // TODO switch to translit
> ---
>>             // |x| in [0.5*ln2, 22], return (exp(|x|) + 1/exp(|x|)/2
>>             if (ix < 0x4036_0000) {
>>                 t = StrictMath.exp(Math.abs(x));
> 110,111c124,127
> <             /* |x| in [22, log(maxdouble)] return half*exp(|x|) */
> <             if (ix < 0x40862E42)  return half*StrictMath.exp(Math.abs(x)); // TODO switch to translit
> ---
>>             // |x| in [22, log(maxdouble)] return half*exp(|x|)
>>             if (ix < 0x4086_2E42) {
>>                 return half*StrictMath.exp(Math.abs(x));
>>             }
> 113c129
> <             /* |x| in [log(maxdouble), overflowthresold] */
> ---
>>             // |x| in [log(maxdouble), overflowthresold]
> 115,117c131,134
> <             if (ix<0x408633CE ||
> <                 ((ix==0x408633ce)&&(Integer.compareUnsigned(lx, 0x8fb9f87d) <= 0))) {
> <                 w = StrictMath.exp(half*Math.abs(x)); // TODO switch to translit
> ---
>>             if (ix<0x4086_33CE ||
>>                 ((ix == 0x4086_33ce) &&
>>                  (Integer.compareUnsigned(lx, 0x8fb9_f87d) <= 0))) {
>>                 w = StrictMath.exp(half*Math.abs(x));
> 122c139
> <             /* |x| > overflowthresold, cosh(x) overflow */
> ---
>>             // |x| > overflowthresold, cosh(x) overflow
> 126d142
> < 
> 156c172
> <             /* High word of |x|. */
> ---
>>             // High word of |x|.
> 158c174
> <             ix = jx&0x7fffffff;
> ---
>>             ix = jx & 0x7fff_ffff;
> 160,163c176,182
> <             /* x is INF or NaN */
> <             if(ix>=0x7ff00000) {
> <                 if (jx>=0) return one/x+one;    /* tanh(+-inf)=+-1 */
> <                 else       return one/x-one;    /* tanh(NaN) = NaN */
> ---
>>             // x is INF or NaN
>>             if (ix >= 0x7ff0_0000) {
>>                 if (jx >= 0) {  // tanh(+-inf)=+-1
>>                     return one/x + one;
>>                 } else {        // tanh(NaN) = NaN
>>                     return one/x - one;
>>                 }
> 166,171c185,190
> <             /* |x| < 22 */
> <             if (ix < 0x40360000) {          /* |x|<22 */
> <                 if (ix<0x3c800000)          /* |x|<2**-55 */
> <                     return x*(one+x);       /* tanh(small) = small */
> <                 if (ix>=0x3ff00000) {       /* |x|>=1  */
> <                     t = expm1(two*Math.abs(x));
> ---
>>             // |x| < 22
>>             if (ix < 0x4036_0000) {          // |x| < 22
>>                 if (ix<0x3c80_0000)          // |x| < 2**-55
>>                     return x*(one + x);      // tanh(small) = small
>>                 if (ix>=0x3ff0_0000) {       // |x| >= 1
>>                     t = StrictMath.expm1(two*Math.abs(x));
> 174c193
> <                     t = expm1(-two*Math.abs(x));
> ---
>>                     t = StrictMath.expm1(-two*Math.abs(x));
> 177,179c196,197
> <                 /* |x| > 22, return +-1 */
> <             } else {
> <                 z = one - tiny;             /* raised inexact flag */
> ---
>>             } else { // |x| > 22, return +-1
>>                 z = one - tiny;             // raised inexact flag

Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:

  Remove unnecessary semicolons.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12429/files
  - new: https://git.openjdk.org/jdk/pull/12429/files/923c2b3a..e75cfbb8

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12429&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12429&range=07-08

  Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/12429.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12429/head:pull/12429

PR: https://git.openjdk.org/jdk/pull/12429

From duke at openjdk.org  Mon Feb 13 03:05:53 2023
From: duke at openjdk.org (Xiaowei Lu)
Date: Mon, 13 Feb 2023 03:05:53 GMT
Subject: RFR: 8302204: Optimize BigDecimal.divide
In-Reply-To: <_6xQn0WEbeyiuMwLLvjMSslSJvYSN7SHMtXCrwCKsMQ=.b3891220-dcea-4ceb-ac97-647b15b98f38@github.com>
References: <rUC0Dh_-1E0PZNJwM0GRH1KPu6prPotT-oeDTUdqjI4=.a8f7d3b7-a0f2-45a0-ae01-f37ef108d18f@github.com>
 <_6xQn0WEbeyiuMwLLvjMSslSJvYSN7SHMtXCrwCKsMQ=.b3891220-dcea-4ceb-ac97-647b15b98f38@github.com>
Message-ID: <oHrsM8uTOEEp2U6isQiFuRfZ3vOSFU9EW37WJnS0jWk=.5be51959-b826-45f5-ac76-1636ae393a58@github.com>

On Sat, 11 Feb 2023 16:03:24 GMT, Sergey Kuksenko <skuksenko at openjdk.org> wrote:

> "The performance looks good." - Could you support this statement with some benchmark results? Thank you.

Hi, here is a detailed result
1. I have run the benchmark in [JDK-8269667](https://bugs.openjdk.org/browse/JDK-8269667), which calculates 1/2, 1/3 ... to 1/100. From the result, we can see nearly 3x faster when the remainder is zero, and no obvious difference when it's not zero. This is consistent with our estimation, since stripping zeros is needed only when the remainder is zero.
before optimization 

    2       3423ms
    3        149ms
    4       3794ms
    5       3931ms
    6        175ms
    7        160ms
    8       3814ms
    9        159ms
   10       3669ms
   11        198ms
   12        183ms
   13        195ms
   14        215ms
   15        197ms
   16       4064ms
   17        184ms
   18        198ms
   19        199ms
   20       4500ms
   21        203ms
   22        188ms
   23        205ms
   24        218ms
   25       4337ms
   26        187ms
   27        189ms
   28        208ms
   29        193ms
   30        194ms
   31        201ms
   32       4029ms
   33        192ms
   34        205ms
   35        204ms
   36        201ms
   37        188ms
   38        188ms
   39        201ms
   40       4179ms
   41        200ms
   42        199ms
   43        187ms
   44        240ms
   45        184ms
   46        199ms
   47        187ms
   48        187ms
   49        196ms
   50       4257ms
   51        187ms
   52        187ms
   53        184ms
   54        196ms
   55        187ms
   56        199ms
   57        198ms
   58        184ms
   59        197ms
   60        200ms
   61        187ms
   62        187ms
   63        196ms
   64       3874ms
   65        187ms
   66        184ms
   67        189ms
   68        200ms
   69        200ms
   70        187ms
   71        197ms
   72        197ms
   73        187ms
   74        200ms
   75        186ms
   76        185ms
   77        197ms
   78        199ms
   79        187ms
   80       4063ms
   81        188ms
   82        199ms
   83        197ms
   84        202ms
   85        188ms
   86        188ms
   87        184ms
   88        185ms
   89        188ms
   90        188ms
   91        202ms
   92        185ms
   93        185ms
   94        202ms
   95        201ms
   96        200ms
   97        197ms
   98        198ms
   99        189ms
  100       4472ms


after optimization 

    2       1308ms
    3        146ms
    4       1117ms
    5       1249ms
    6        174ms
    7        160ms
    8       1014ms
    9        165ms
   10       1394ms
   11        199ms
   12        191ms
   13        204ms
   14        192ms
   15        198ms
   16       1261ms
   17        172ms
   18        185ms
   19        185ms
   20       1223ms
   21        184ms
   22        172ms
   23        184ms
   24        189ms
   25       1227ms
   26        178ms
   27        177ms
   28        188ms
   29        177ms
   30        177ms
   31        189ms
   32        961ms
   33        176ms
   34        185ms
   35        185ms
   36        184ms
   37        172ms
   38        172ms
   39        185ms
   40       1127ms
   41        189ms
   42        189ms
   43        175ms
   44        188ms
   45        176ms
   46        190ms
   47        177ms
   48        175ms
   49        189ms
   50       1222ms
   51        176ms
   52        176ms
   53        173ms
   54        185ms
   55        175ms
   56        185ms
   57        186ms
   58        172ms
   59        185ms
   60        185ms
   61        176ms
   62        176ms
   63        189ms
   64       1339ms
   65        175ms
   66        176ms
   67        176ms
   68        188ms
   69        189ms
   70        175ms
   71        188ms
   72        189ms
   73        172ms
   74        184ms
   75        172ms
   76        172ms
   77        184ms
   78        184ms
   79        172ms
   80       1275ms
   81        172ms
   82        190ms
   83        189ms
   84        189ms
   85        176ms
   86        177ms
   87        176ms
   88        177ms
   89        177ms
   90        172ms
   91        185ms
   92        173ms
   93        171ms
   94        185ms
   95        185ms
   96        185ms
   97        183ms
   98        189ms
   99        233ms
  100       1200ms


2. Also the benchmark TPC-DS has been run on Spark3. TPC-DS has 99 SQL queries, the 4th of which spends a lot of time calculating decimals. We have collected time assumptions in each query and found out 1/3 less time spent on query4, with other queries nearly the same. 
before optimization 

[AUTO-RESULT] query1=14s
[AUTO-RESULT] query2=21s
[AUTO-RESULT] query3=6s
**[AUTO-RESULT] query4=102s**
[AUTO-RESULT] query5=32s
[AUTO-RESULT] query6=7s
[AUTO-RESULT] query7=7s
[AUTO-RESULT] query8=7s
[AUTO-RESULT] query9=28s
[AUTO-RESULT] query10=15s
[AUTO-RESULT] query11=35s
[AUTO-RESULT] query12=6s
[AUTO-RESULT] query13=8s
[AUTO-RESULT] query14=118s
[AUTO-RESULT] query15=7s
[AUTO-RESULT] query16=36s
[AUTO-RESULT] query17=19s
[AUTO-RESULT] query18=10s
[AUTO-RESULT] query19=6s
[AUTO-RESULT] query20=6s
[AUTO-RESULT] query21=4s
[AUTO-RESULT] query22=6s
[AUTO-RESULT] query23=127s
[AUTO-RESULT] query24=48s
[AUTO-RESULT] query25=15s
[AUTO-RESULT] query26=8s
[AUTO-RESULT] query27=7s
[AUTO-RESULT] query28=34s
[AUTO-RESULT] query29=20s
[AUTO-RESULT] query30=10s
[AUTO-RESULT] query31=16s
[AUTO-RESULT] query32=6s
[AUTO-RESULT] query33=12s
[AUTO-RESULT] query34=8s
[AUTO-RESULT] query35=34s
[AUTO-RESULT] query36=7s
[AUTO-RESULT] query37=9s
[AUTO-RESULT] query38=19s
[AUTO-RESULT] query39=9s
[AUTO-RESULT] query40=13s
[AUTO-RESULT] query41=2s
[AUTO-RESULT] query42=5s
[AUTO-RESULT] query43=7s
[AUTO-RESULT] query44=14s
[AUTO-RESULT] query45=8s
[AUTO-RESULT] query46=8s
[AUTO-RESULT] query47=14s
[AUTO-RESULT] query48=9s
[AUTO-RESULT] query49=28s
[AUTO-RESULT] query50=15s
[AUTO-RESULT] query51=25s
[AUTO-RESULT] query52=5s
[AUTO-RESULT] query53=7s
[AUTO-RESULT] query54=14s
[AUTO-RESULT] query55=5s
[AUTO-RESULT] query56=12s
[AUTO-RESULT] query57=12s
[AUTO-RESULT] query58=12s
[AUTO-RESULT] query59=14s
[AUTO-RESULT] query60=12s
[AUTO-RESULT] query61=8s
[AUTO-RESULT] query62=9s
[AUTO-RESULT] query63=6s
[AUTO-RESULT] query64=81s
[AUTO-RESULT] query65=17s
[AUTO-RESULT] query66=14s
[AUTO-RESULT] query67=53s
[AUTO-RESULT] query68=6s
[AUTO-RESULT] query69=14s
[AUTO-RESULT] query70=10s
[AUTO-RESULT] query71=13s
[AUTO-RESULT] query72=43s
[AUTO-RESULT] query73=6s
[AUTO-RESULT] query74=27s
[AUTO-RESULT] query75=49s
[AUTO-RESULT] query76=21s
[AUTO-RESULT] query77=22s
[AUTO-RESULT] query78=69s
[AUTO-RESULT] query79=7s
[AUTO-RESULT] query80=34s
[AUTO-RESULT] query81=10s
[AUTO-RESULT] query82=9s
[AUTO-RESULT] query83=13s
[AUTO-RESULT] query84=7s
[AUTO-RESULT] query85=15s
[AUTO-RESULT] query86=6s
[AUTO-RESULT] query87=21s
[AUTO-RESULT] query88=31s
[AUTO-RESULT] query89=8s
[AUTO-RESULT] query90=10s
[AUTO-RESULT] query91=7s
[AUTO-RESULT] query92=6s
[AUTO-RESULT] query93=19s
[AUTO-RESULT] query94=24s
[AUTO-RESULT] query95=92s
[AUTO-RESULT] query96=9s
[AUTO-RESULT] query97=26s
[AUTO-RESULT] query98=6s
[AUTO-RESULT] query99=10s
[AUTO-RESULT] QueryTotal=1968s


after optimization 

[AUTO-RESULT] query1=13s
[AUTO-RESULT] query2=20s
[AUTO-RESULT] query3=6s
**[AUTO-RESULT] query4=68s**
[AUTO-RESULT] query5=33s
[AUTO-RESULT] query6=7s
[AUTO-RESULT] query7=8s
[AUTO-RESULT] query8=7s
[AUTO-RESULT] query9=28s
[AUTO-RESULT] query10=15s
[AUTO-RESULT] query11=32s
[AUTO-RESULT] query12=6s
[AUTO-RESULT] query13=9s
[AUTO-RESULT] query14=117s
[AUTO-RESULT] query15=8s
[AUTO-RESULT] query16=34s
[AUTO-RESULT] query17=18s
[AUTO-RESULT] query18=10s
[AUTO-RESULT] query19=6s
[AUTO-RESULT] query20=6s
[AUTO-RESULT] query21=4s
[AUTO-RESULT] query22=6s
[AUTO-RESULT] query23=127s
[AUTO-RESULT] query24=48s
[AUTO-RESULT] query25=15s
[AUTO-RESULT] query26=9s
[AUTO-RESULT] query27=7s
[AUTO-RESULT] query28=33s
[AUTO-RESULT] query29=21s
[AUTO-RESULT] query30=9s
[AUTO-RESULT] query31=16s
[AUTO-RESULT] query32=7s
[AUTO-RESULT] query33=12s
[AUTO-RESULT] query34=7s
[AUTO-RESULT] query35=34s
[AUTO-RESULT] query36=8s
[AUTO-RESULT] query37=9s
[AUTO-RESULT] query38=19s
[AUTO-RESULT] query39=9s
[AUTO-RESULT] query40=13s
[AUTO-RESULT] query41=2s
[AUTO-RESULT] query42=5s
[AUTO-RESULT] query43=7s
[AUTO-RESULT] query44=14s
[AUTO-RESULT] query45=7s
[AUTO-RESULT] query46=8s
[AUTO-RESULT] query47=14s
[AUTO-RESULT] query48=9s
[AUTO-RESULT] query49=29s
[AUTO-RESULT] query50=15s
[AUTO-RESULT] query51=25s
[AUTO-RESULT] query52=5s
[AUTO-RESULT] query53=7s
[AUTO-RESULT] query54=15s
[AUTO-RESULT] query55=5s
[AUTO-RESULT] query56=12s
[AUTO-RESULT] query57=12s
[AUTO-RESULT] query58=12s
[AUTO-RESULT] query59=14s
[AUTO-RESULT] query60=12s
[AUTO-RESULT] query61=7s
[AUTO-RESULT] query62=10s
[AUTO-RESULT] query63=6s
[AUTO-RESULT] query64=83s
[AUTO-RESULT] query65=17s
[AUTO-RESULT] query66=14s
[AUTO-RESULT] query67=52s
[AUTO-RESULT] query68=7s
[AUTO-RESULT] query69=14s
[AUTO-RESULT] query70=10s
[AUTO-RESULT] query71=12s
[AUTO-RESULT] query72=43s
[AUTO-RESULT] query73=6s
[AUTO-RESULT] query74=27s
[AUTO-RESULT] query75=48s
[AUTO-RESULT] query76=21s
[AUTO-RESULT] query77=22s
[AUTO-RESULT] query78=69s
[AUTO-RESULT] query79=7s
[AUTO-RESULT] query80=36s
[AUTO-RESULT] query81=10s
[AUTO-RESULT] query82=9s
[AUTO-RESULT] query83=12s
[AUTO-RESULT] query84=7s
[AUTO-RESULT] query85=15s
[AUTO-RESULT] query86=7s
[AUTO-RESULT] query87=19s
[AUTO-RESULT] query88=33s
[AUTO-RESULT] query89=7s
[AUTO-RESULT] query90=10s
[AUTO-RESULT] query91=8s
[AUTO-RESULT] query92=6s
[AUTO-RESULT] query93=20s
[AUTO-RESULT] query94=24s
[AUTO-RESULT] query95=91s
[AUTO-RESULT] query96=9s
[AUTO-RESULT] query97=26s
[AUTO-RESULT] query98=7s
[AUTO-RESULT] query99=10s
[AUTO-RESULT] QueryTotal=1934s


If there is more benchmark for BigDecimal, I am glad to give it a try.
Thank you.

-------------

PR: https://git.openjdk.org/jdk/pull/12509

From skuksenko at openjdk.org  Mon Feb 13 03:56:26 2023
From: skuksenko at openjdk.org (Sergey Kuksenko)
Date: Mon, 13 Feb 2023 03:56:26 GMT
Subject: RFR: 8302204: Optimize BigDecimal.divide
In-Reply-To: <rUC0Dh_-1E0PZNJwM0GRH1KPu6prPotT-oeDTUdqjI4=.a8f7d3b7-a0f2-45a0-ae01-f37ef108d18f@github.com>
References: <rUC0Dh_-1E0PZNJwM0GRH1KPu6prPotT-oeDTUdqjI4=.a8f7d3b7-a0f2-45a0-ae01-f37ef108d18f@github.com>
Message-ID: <taxudZO1U-yPbYXBxD8SI-6M3U7utsiVOz-eLfaCw6g=.5de89d56-78ea-446f-89e4-5908f722d37d@github.com>

On Fri, 10 Feb 2023 10:00:05 GMT, Xiaowei Lu <duke at openjdk.org> wrote:

> [JDK-8269667](https://bugs.openjdk.org/browse/JDK-8269667) has uncovered the poor performance of BigDecimal.divide under certain circumstance.
> 
> We confront similar situations when benchmarking Spark3 on TPC-DS test kit. According to the flame-graph below, it is StripZeros that spends most of the time of BigDecimal.divide. Hence we propose this patch to optimize stripping zeros.
> ![?? 1](https://user-images.githubusercontent.com/39413832/218062061-53cd0220-776e-4b72-8b9a-6b0f11707986.png)
> 
> Currently, createAndStripZerosToMatchScale() is performed linearly. That is, the target value is parsed from back to front, each time stripping out single ?0?. To optimize, we can adopt the method of binary search. That is, each time we try to strip out ${scale/2} ?0?s. 
> 
> The performance looks good. Therotically, time complexity of our method is O(log n), while the current one is O(n). In practice, benchmarks on Spark3 show that 1/3 less time (102s->68s) is spent on TPC-DS query4. We also runs Jtreg and JCK to check correctness, and it seems fine.
> 
> More about environment: 
> we run Spark3.3.0 on Openjdk11, but it seems jdk version doesn?t have much impact on BigDecimal. Spark cluster consists of a main node and 2 core nodes, each has 4cores, 16g memory and 4x500GB storage.

As for TPC-DS
[AUTO-RESULT] QueryTotal=1968s      vs      [AUTO-RESULT] QueryTotal=1934s
that gives ~1.7% of performance difference. 
Are you sure that this small diff is a real diff, but not run-to-run variance?

-------------

PR: https://git.openjdk.org/jdk/pull/12509

From lowasser at google.com  Mon Feb 13 03:59:14 2023
From: lowasser at google.com (Louis Wasserman)
Date: Sun, 12 Feb 2023 19:59:14 -0800
Subject: RFR: 8302204: Optimize BigDecimal.divide
In-Reply-To: <taxudZO1U-yPbYXBxD8SI-6M3U7utsiVOz-eLfaCw6g=.5de89d56-78ea-446f-89e4-5908f722d37d@github.com>
References: <rUC0Dh_-1E0PZNJwM0GRH1KPu6prPotT-oeDTUdqjI4=.a8f7d3b7-a0f2-45a0-ae01-f37ef108d18f@github.com>
 <taxudZO1U-yPbYXBxD8SI-6M3U7utsiVOz-eLfaCw6g=.5de89d56-78ea-446f-89e4-5908f722d37d@github.com>
Message-ID: <CAGB9EW-9XZTZaXf0cSK15vygiF1QwjdGoOk2ie76BYzHgcCAhA@mail.gmail.com>

Could you do that benchmark with e.g. JMH rather than taking the difference
of System.currentTimeMillis?  That would probably make it easier to read
and trust the results.

On Sun, Feb 12, 2023, 7:56 PM Sergey Kuksenko <skuksenko at openjdk.org> wrote:

> On Fri, 10 Feb 2023 10:00:05 GMT, Xiaowei Lu <duke at openjdk.org> wrote:
>
> > [JDK-8269667](https://bugs.openjdk.org/browse/JDK-8269667) has
> uncovered the poor performance of BigDecimal.divide under certain
> circumstance.
> >
> > We confront similar situations when benchmarking Spark3 on TPC-DS test
> kit. According to the flame-graph below, it is StripZeros that spends most
> of the time of BigDecimal.divide. Hence we propose this patch to optimize
> stripping zeros.
> > ![?? 1](
> https://user-images.githubusercontent.com/39413832/218062061-53cd0220-776e-4b72-8b9a-6b0f11707986.png
> )
> >
> > Currently, createAndStripZerosToMatchScale() is performed linearly. That
> is, the target value is parsed from back to front, each time stripping out
> single ?0?. To optimize, we can adopt the method of binary search. That is,
> each time we try to strip out ${scale/2} ?0?s.
> >
> > The performance looks good. Therotically, time complexity of our method
> is O(log n), while the current one is O(n). In practice, benchmarks on
> Spark3 show that 1/3 less time (102s->68s) is spent on TPC-DS query4. We
> also runs Jtreg and JCK to check correctness, and it seems fine.
> >
> > More about environment:
> > we run Spark3.3.0 on Openjdk11, but it seems jdk version doesn?t have
> much impact on BigDecimal. Spark cluster consists of a main node and 2 core
> nodes, each has 4cores, 16g memory and 4x500GB storage.
>
> As for TPC-DS
> [AUTO-RESULT] QueryTotal=1968s      vs      [AUTO-RESULT] QueryTotal=1934s
> that gives ~1.7% of performance difference.
> Are you sure that this small diff is a real diff, but not run-to-run
> variance?
>
> -------------
>
> PR: https://git.openjdk.org/jdk/pull/12509
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20230212/a0de161d/attachment.htm>

From duke at openjdk.org  Mon Feb 13 05:02:27 2023
From: duke at openjdk.org (Xiaowei Lu)
Date: Mon, 13 Feb 2023 05:02:27 GMT
Subject: RFR: 8302204: Optimize BigDecimal.divide
In-Reply-To: <taxudZO1U-yPbYXBxD8SI-6M3U7utsiVOz-eLfaCw6g=.5de89d56-78ea-446f-89e4-5908f722d37d@github.com>
References: <rUC0Dh_-1E0PZNJwM0GRH1KPu6prPotT-oeDTUdqjI4=.a8f7d3b7-a0f2-45a0-ae01-f37ef108d18f@github.com>
 <taxudZO1U-yPbYXBxD8SI-6M3U7utsiVOz-eLfaCw6g=.5de89d56-78ea-446f-89e4-5908f722d37d@github.com>
Message-ID: <9W5qzC1UWLh2hp2xtgSlYtVx4jleUdXfTN-jdDBibp0=.651ec106-dc34-4df3-8319-03146c22a0c4@github.com>

On Mon, 13 Feb 2023 03:54:07 GMT, Sergey Kuksenko <skuksenko at openjdk.org> wrote:

> As for TPC-DS [AUTO-RESULT] QueryTotal=1968s vs [AUTO-RESULT] QueryTotal=1934s that gives ~1.7% of performance difference. Are you sure that this small diff is a real diff, but not run-to-run variance?

These queries are separate and independent. We can even config TPC-DS to run query4 alone and the result is 100s vs 71s. The other queries don't have much to do with decimals. So if you look at the total time, yes there is just a slight diff, because only query4 is impacted by our optimization. But if you just look at query4, the acceleration is shown consistently, we have seen data like 102s->68s, 100s->71s.

-------------

PR: https://git.openjdk.org/jdk/pull/12509

From jpai at openjdk.org  Mon Feb 13 06:25:26 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 13 Feb 2023 06:25:26 GMT
Subject: RFR: 8302214: Typo in javadoc of Arrays.compare and
 Arrays.mismatch
In-Reply-To: <NC9N8WA8eqcmgwep2tqJaD5rruWOHwWxbbYCd4XsdRk=.aa39a6a4-396b-4fac-a408-3e0c04fc140c@github.com>
References: <NC9N8WA8eqcmgwep2tqJaD5rruWOHwWxbbYCd4XsdRk=.aa39a6a4-396b-4fac-a408-3e0c04fc140c@github.com>
Message-ID: <QvEhQeX1Av0k0HZSRmKtJ_kDsjSgQ7l4raZ6w6jBFFw=.2ce6a21b-5c5f-4d53-a592-e82afb96607f@github.com>

On Thu, 9 Feb 2023 10:13:03 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

> The Javadocs of Arrays.compare and Arrays.mismatch uses the incorrect capitalization `atoIndex` and `btoIndex` when referencing the corresponding `aToIndex` and `bToIndex` parameters.
> 
> Sample:
> 
> 
> * specified ranges [{@code aFromIndex}, {@code atoIndex}) and
> * [{@code bFromIndex}, {@code btoIndex}) respectively:
> 
> 
> This PR changes the capitalization to `aToIndex` and `bToIndex`. This change was performed using case-sensitive search / replace in an IDE.

The changes look fine to me.

-------------

Marked as reviewed by jpai (Reviewer).

PR: https://git.openjdk.org/jdk/pull/12488

From redestad at openjdk.org  Mon Feb 13 09:59:52 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Mon, 13 Feb 2023 09:59:52 GMT
Subject: RFR: 8301958: Reduce Arrays.copyOf/-Range overheads [v10]
In-Reply-To: <2pdPoSHz2RJ7YDHOwOyszQMVv0v7FQFOwykfJ-za_e0=.cfe480da-a045-4b9a-bec7-7fffd0f47206@github.com>
References: <2pdPoSHz2RJ7YDHOwOyszQMVv0v7FQFOwykfJ-za_e0=.cfe480da-a045-4b9a-bec7-7fffd0f47206@github.com>
Message-ID: <0CS72UlGjDn0Wel_aYv6X7O6siPVGeSn9-jzDxxkMn4=.c9483a26-3cd6-4b63-9c30-765190a784e3@github.com>

> This patch adds special-cases to `Arrays.copyOf` and `Arrays.copyOfRange` to copy arrays more efficiently when exactly the whole input array is to be copied. This helps eliminate range checks and has been verified to help various String operations. Example:
> 
> Baseline
> 
> Benchmark                                            (size)  Mode  Cnt   Score   Error  Units
> StringConstructor.newStringFromArray                      7  avgt   15  16.817 ? 0.369  ns/op
> StringConstructor.newStringFromArrayWithCharset           7  avgt   15  16.866 ? 0.449  ns/op
> StringConstructor.newStringFromArrayWithCharsetName       7  avgt   15  22.198 ? 0.396  ns/op
> 
> Patch: 
> 
> Benchmark                                            (size)  Mode  Cnt   Score   Error  Units
> StringConstructor.newStringFromArray                      7  avgt   15  14.666 ? 0.336  ns/op
> StringConstructor.newStringFromArrayWithCharset           7  avgt   15  14.582 ? 0.288  ns/op
> StringConstructor.newStringFromArrayWithCharsetName       7  avgt   15  20.339 ? 0.328  ns/op

Claes Redestad 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/12453/files
  - new: https://git.openjdk.org/jdk/pull/12453/files/350612d4..1031dd85

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12453&range=09
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12453&range=08-09

  Stats: 31 lines in 1 file changed: 7 ins; 8 del; 16 mod
  Patch: https://git.openjdk.org/jdk/pull/12453.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12453/head:pull/12453

PR: https://git.openjdk.org/jdk/pull/12453

From redestad at openjdk.org  Mon Feb 13 10:12:14 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Mon, 13 Feb 2023 10:12:14 GMT
Subject: RFR: 8302163: Speed up various String comparison methods with
 ArraysSupport.mismatch
Message-ID: <geAF-Q1dnCoJ0vCqMNHXXziVGii47nOkfyw5RTL_Wb0=.79392f23-0846-4e04-8b19-87289c3bf49f@github.com>

We can improve various String methods such as `startsWith`, `endsWith` and `regionMatches` by leveraging the intrinsified mismatch methods in `ArraysSupport`.

-------------

Commit messages:
 - Remove overlapping micros, extend testing to endsWith, regionCI and some minor improvements to String::regionMatches
 - Expand micro coverage
 - Add micro from @eirbjo
 - Revert UTF16.compareValues
 - Add a few micros, apply optimization to StringUTF16.compareValues
 - Speed up various String comparison methods with ArraysSupport.mismatch

Changes: https://git.openjdk.org/jdk/pull/12528/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12528&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8302163
  Stats: 170 lines in 5 files changed: 105 ins; 44 del; 21 mod
  Patch: https://git.openjdk.org/jdk/pull/12528.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12528/head:pull/12528

PR: https://git.openjdk.org/jdk/pull/12528

From redestad at openjdk.org  Mon Feb 13 10:12:15 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Mon, 13 Feb 2023 10:12:15 GMT
Subject: RFR: 8302163: Speed up various String comparison methods with
 ArraysSupport.mismatch
In-Reply-To: <geAF-Q1dnCoJ0vCqMNHXXziVGii47nOkfyw5RTL_Wb0=.79392f23-0846-4e04-8b19-87289c3bf49f@github.com>
References: <geAF-Q1dnCoJ0vCqMNHXXziVGii47nOkfyw5RTL_Wb0=.79392f23-0846-4e04-8b19-87289c3bf49f@github.com>
Message-ID: <-FZWPrNJzLpZZILVDDKW3pgCGlY1qW8q5RdYB9vWcpw=.5e2ebe71-c740-42cb-aa25-06446adb1d1a@github.com>

On Mon, 13 Feb 2023 09:59:24 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> We can improve various String methods such as `startsWith`, `endsWith` and `regionMatches` by leveraging the intrinsified mismatch methods in `ArraysSupport`.

Microbenchmarking shows decent improvements on small data, scaling up to some impressive gains on large inputs when vectorization kicks in (~41x on regionMatches for size = 1024 on my x64 sandybridge setup, ~34x on m1 in the same config)

macosx-aarch64, m1, 21-b9:

Benchmark                             (size)  (utf16)  Mode  Cnt     Score    Error  Units
StringComparisons.endsWith                 6     true  avgt   15     5,949 ?  0,051  ns/op
StringComparisons.endsWith                 6    false  avgt   15     4,063 ?  0,038  ns/op
StringComparisons.endsWith                15     true  avgt   15    10,758 ?  0,132  ns/op
StringComparisons.endsWith                15    false  avgt   15     6,487 ?  0,052  ns/op
StringComparisons.endsWith              1024     true  avgt   15   653,750 ?  2,835  ns/op
StringComparisons.endsWith              1024    false  avgt   15   314,219 ?  1,264  ns/op
StringComparisons.regionMatches            6     true  avgt   15    12,460 ?  0,043  ns/op
StringComparisons.regionMatches            6    false  avgt   15     6,647 ?  0,026  ns/op
StringComparisons.regionMatches           15     true  avgt   15    30,502 ?  0,193  ns/op
StringComparisons.regionMatches           15    false  avgt   15    15,073 ?  0,030  ns/op
StringComparisons.regionMatches         1024     true  avgt   15  2147,480 ?  4,622  ns/op
StringComparisons.regionMatches         1024    false  avgt   15  1068,787 ? 14,098  ns/op
StringComparisons.regionMatchesCI          6     true  avgt   15    11,680 ?  0,106  ns/op
StringComparisons.regionMatchesCI          6    false  avgt   15     4,577 ?  0,101  ns/op
StringComparisons.regionMatchesCI         15     true  avgt   15    14,422 ?  0,132  ns/op
StringComparisons.regionMatchesCI         15    false  avgt   15     6,904 ?  0,124  ns/op
StringComparisons.regionMatchesCI       1024     true  avgt   15   273,810 ?  3,446  ns/op
StringComparisons.regionMatchesCI       1024    false  avgt   15   226,040 ?  2,886  ns/op
StringComparisons.regionMatchesRange       6     true  avgt   15    11,896 ?  0,110  ns/op
StringComparisons.regionMatchesRange       6    false  avgt   15     6,044 ?  0,034  ns/op
StringComparisons.regionMatchesRange      15     true  avgt   15    29,508 ?  0,093  ns/op
StringComparisons.regionMatchesRange      15    false  avgt   15    14,336 ?  0,020  ns/op
StringComparisons.regionMatchesRange    1024     true  avgt   15  2187,600 ? 80,285  ns/op
StringComparisons.regionMatchesRange    1024    false  avgt   15  1105,813 ? 28,260  ns/op
StringComparisons.startsWith               6     true  avgt   15     5,315 ?  0,087  ns/op
StringComparisons.startsWith               6    false  avgt   15     3,588 ?  0,020  ns/op
StringComparisons.startsWith              15     true  avgt   15     9,823 ?  0,144  ns/op
StringComparisons.startsWith              15    false  avgt   15     5,963 ?  0,253  ns/op
StringComparisons.startsWith            1024     true  avgt   15   441,854 ?  9,295  ns/op
StringComparisons.startsWith            1024    false  avgt   15   224,386 ?  6,876  ns/op


macosx-aarch64. m1, patched:

Benchmark                             (size)  (utf16)  Mode  Cnt    Score    Error  Units
StringComparisons.endsWith                 6     true  avgt   15    3,185 ?  0,063  ns/op
StringComparisons.endsWith                 6    false  avgt   15    4,507 ?  0,447  ns/op
StringComparisons.endsWith                15     true  avgt   15    6,097 ?  0,142  ns/op
StringComparisons.endsWith                15    false  avgt   15    5,736 ?  0,025  ns/op
StringComparisons.endsWith              1024     true  avgt   15   60,283 ?  4,109  ns/op
StringComparisons.endsWith              1024    false  avgt   15   31,011 ?  0,080  ns/op
StringComparisons.regionMatches            6     true  avgt   15    3,993 ?  0,063  ns/op
StringComparisons.regionMatches            6    false  avgt   15    4,836 ?  0,474  ns/op
StringComparisons.regionMatches           15     true  avgt   15    3,641 ?  0,012  ns/op
StringComparisons.regionMatches           15    false  avgt   15    2,849 ?  0,065  ns/op
StringComparisons.regionMatches         1024     true  avgt   15   57,739 ?  0,748  ns/op
StringComparisons.regionMatches         1024    false  avgt   15   30,943 ?  0,423  ns/op
StringComparisons.regionMatchesCI          6     true  avgt   15   11,729 ?  0,142  ns/op
StringComparisons.regionMatchesCI          6    false  avgt   15    4,562 ?  0,125  ns/op
StringComparisons.regionMatchesCI         15     true  avgt   15   14,611 ?  0,227  ns/op
StringComparisons.regionMatchesCI         15    false  avgt   15    6,970 ?  0,083  ns/op
StringComparisons.regionMatchesCI       1024     true  avgt   15  273,476 ?  1,789  ns/op
StringComparisons.regionMatchesCI       1024    false  avgt   15  227,503 ?  3,547  ns/op
StringComparisons.regionMatchesRange       6     true  avgt   15    3,485 ?  0,035  ns/op
StringComparisons.regionMatchesRange       6    false  avgt   15    4,640 ?  0,050  ns/op
StringComparisons.regionMatchesRange      15     true  avgt   15    6,121 ?  0,087  ns/op
StringComparisons.regionMatchesRange      15    false  avgt   15    5,784 ?  0,080  ns/op
StringComparisons.regionMatchesRange    1024     true  avgt   15   58,403 ?  0,876  ns/op
StringComparisons.regionMatchesRange    1024    false  avgt   15   36,500 ? 11,264  ns/op
StringComparisons.startsWith               6     true  avgt   15    3,225 ?  0,255  ns/op
StringComparisons.startsWith               6    false  avgt   15    4,577 ?  0,684  ns/op
StringComparisons.startsWith              15     true  avgt   15    7,586 ?  4,402  ns/op
StringComparisons.startsWith              15    false  avgt   15    6,295 ?  1,402  ns/op
StringComparisons.startsWith            1024     true  avgt   15   76,536 ? 16,461  ns/op
StringComparisons.startsWith            1024    false  avgt   15   30,523 ?  0,359  ns/op


linux-x64 sandybridge, 21-b9:

Benchmark                             (size)  (utf16)  Mode  Cnt     Score    Error  Units
StringComparisons.endsWith                 6     true  avgt   15    12.382 ?  0.014  ns/op
StringComparisons.endsWith                 6    false  avgt   15     9.975 ?  0.012  ns/op
StringComparisons.endsWith                15     true  avgt   15    18.679 ?  0.028  ns/op
StringComparisons.endsWith                15    false  avgt   15    13.133 ?  0.116  ns/op
StringComparisons.endsWith              1024     true  avgt   15   819.007 ?  5.523  ns/op
StringComparisons.endsWith              1024    false  avgt   15   415.061 ?  0.962  ns/op
StringComparisons.regionMatches            6     true  avgt   15    17.363 ?  0.155  ns/op
StringComparisons.regionMatches            6    false  avgt   15    10.722 ?  0.072  ns/op
StringComparisons.regionMatches           15     true  avgt   15    37.202 ?  0.321  ns/op
StringComparisons.regionMatches           15    false  avgt   15    21.128 ?  0.164  ns/op
StringComparisons.regionMatches         1024     true  avgt   15  2265.847 ?  2.668  ns/op
StringComparisons.regionMatches         1024    false  avgt   15  1305.184 ? 11.794  ns/op
StringComparisons.regionMatchesCI          6     true  avgt   15    24.403 ?  0.367  ns/op
StringComparisons.regionMatchesCI          6    false  avgt   15     9.521 ?  0.015  ns/op
StringComparisons.regionMatchesCI         15     true  avgt   15    27.650 ?  0.033  ns/op
StringComparisons.regionMatchesCI         15    false  avgt   15    12.082 ?  0.130  ns/op
StringComparisons.regionMatchesCI       1024     true  avgt   15   514.851 ?  5.818  ns/op
StringComparisons.regionMatchesCI       1024    false  avgt   15   351.532 ?  4.147  ns/op
StringComparisons.regionMatchesRange       6     true  avgt   15    18.227 ?  0.017  ns/op
StringComparisons.regionMatchesRange       6    false  avgt   15    10.128 ?  0.015  ns/op
StringComparisons.regionMatchesRange      15     true  avgt   15    40.924 ?  0.305  ns/op
StringComparisons.regionMatchesRange      15    false  avgt   15    20.476 ?  0.177  ns/op
StringComparisons.regionMatchesRange    1024     true  avgt   15  2267.800 ?  3.280  ns/op
StringComparisons.regionMatchesRange    1024    false  avgt   15  1139.950 ?  1.222  ns/op
StringComparisons.startsWith               6     true  avgt   15    10.095 ?  0.044  ns/op
StringComparisons.startsWith               6    false  avgt   15     8.908 ?  0.319  ns/op
StringComparisons.startsWith              15     true  avgt   15    16.406 ?  0.017  ns/op
StringComparisons.startsWith              15    false  avgt   15    10.964 ?  0.077  ns/op
StringComparisons.startsWith            1024     true  avgt   15   670.043 ?  5.107  ns/op
StringComparisons.startsWith            1024    false  avgt   15   346.972 ?  0.373  ns/op


linux-x64 sandybridge, patched:

Benchmark                             (size)  (utf16)  Mode  Cnt    Score   Error  Units
StringComparisons.endsWith                 6     true  avgt   15    8.439 ? 0.010  ns/op
StringComparisons.endsWith                 6    false  avgt   15   11.341 ? 0.125  ns/op
StringComparisons.endsWith                15     true  avgt   15   10.932 ? 0.135  ns/op
StringComparisons.endsWith                15    false  avgt   15   10.704 ? 0.143  ns/op
StringComparisons.endsWith              1024     true  avgt   15   69.427 ? 7.376  ns/op
StringComparisons.endsWith              1024    false  avgt   15   40.248 ? 0.661  ns/op
StringComparisons.regionMatches            6     true  avgt   15    8.397 ? 0.010  ns/op
StringComparisons.regionMatches            6    false  avgt   15    9.813 ? 0.064  ns/op
StringComparisons.regionMatches           15     true  avgt   15    8.468 ? 0.105  ns/op
StringComparisons.regionMatches           15    false  avgt   15    8.082 ? 0.181  ns/op
StringComparisons.regionMatches         1024     true  avgt   15   64.316 ? 0.643  ns/op
StringComparisons.regionMatches         1024    false  avgt   15   31.500 ? 0.483  ns/op
StringComparisons.regionMatchesCI          6     true  avgt   15   24.199 ? 0.017  ns/op
StringComparisons.regionMatchesCI          6    false  avgt   15    9.521 ? 0.009  ns/op
StringComparisons.regionMatchesCI         15     true  avgt   15   27.656 ? 0.037  ns/op
StringComparisons.regionMatchesCI         15    false  avgt   15   12.047 ? 0.019  ns/op
StringComparisons.regionMatchesCI       1024     true  avgt   15  513.828 ? 4.221  ns/op
StringComparisons.regionMatchesCI       1024    false  avgt   15  349.885 ? 0.455  ns/op
StringComparisons.regionMatchesRange       6     true  avgt   15    9.771 ? 0.215  ns/op
StringComparisons.regionMatchesRange       6    false  avgt   15   10.190 ? 0.012  ns/op
StringComparisons.regionMatchesRange      15     true  avgt   15   11.352 ? 0.267  ns/op
StringComparisons.regionMatchesRange      15    false  avgt   15   10.617 ? 0.012  ns/op
StringComparisons.regionMatchesRange    1024     true  avgt   15   66.727 ? 2.732  ns/op
StringComparisons.regionMatchesRange    1024    false  avgt   15   43.148 ? 7.262  ns/op
StringComparisons.startsWith               6     true  avgt   15    8.525 ? 0.010  ns/op
StringComparisons.startsWith               6    false  avgt   15    8.792 ? 0.025  ns/op
StringComparisons.startsWith              15     true  avgt   15   10.600 ? 0.564  ns/op
StringComparisons.startsWith              15    false  avgt   15   10.538 ? 0.645  ns/op
StringComparisons.startsWith            1024     true  avgt   15   61.118 ? 5.143  ns/op
StringComparisons.startsWith            1024    false  avgt   15   40.171 ? 0.576  ns/op

-------------

PR: https://git.openjdk.org/jdk/pull/12528

From lujaniuk at openjdk.org  Mon Feb 13 10:21:05 2023
From: lujaniuk at openjdk.org (Ludvig Janiuk)
Date: Mon, 13 Feb 2023 10:21:05 GMT
Subject: RFR: 8302226 failure_handler native.core should wait for coredump
 to finish [v2]
In-Reply-To: <5k6enBnRlLOZsW9Dp3NWLwiw-JeURwl-9omJht157vY=.dc8401f6-5b3d-4997-aee2-0003b1a01ab9@github.com>
References: <5k6enBnRlLOZsW9Dp3NWLwiw-JeURwl-9omJht157vY=.dc8401f6-5b3d-4997-aee2-0003b1a01ab9@github.com>
Message-ID: <2-fRnycvALxQrNO1Pw0oh0MUU8Xb3_4xmjSwI6PQzBM=.77e0dabf-82ed-4a6e-ad71-809a96939b82@github.com>

> Update open/test/failure_handler/src/share/conf/linux.properties to handle core dumps more correctly.

Ludvig Janiuk has updated the pull request incrementally with one additional commit since the last revision:

  add mac

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12515/files
  - new: https://git.openjdk.org/jdk/pull/12515/files/9c79974a..8f4026f6

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12515&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12515&range=00-01

  Stats: 5 lines in 1 file changed: 3 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/12515.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12515/head:pull/12515

PR: https://git.openjdk.org/jdk/pull/12515

From lbourges at openjdk.org  Mon Feb 13 10:47:27 2023
From: lbourges at openjdk.org (Laurent =?UTF-8?B?Qm91cmfDqHM=?=)
Date: Mon, 13 Feb 2023 10:47:27 GMT
Subject: RFR: 8302163: Speed up various String comparison methods with
 ArraysSupport.mismatch
In-Reply-To: <geAF-Q1dnCoJ0vCqMNHXXziVGii47nOkfyw5RTL_Wb0=.79392f23-0846-4e04-8b19-87289c3bf49f@github.com>
References: <geAF-Q1dnCoJ0vCqMNHXXziVGii47nOkfyw5RTL_Wb0=.79392f23-0846-4e04-8b19-87289c3bf49f@github.com>
Message-ID: <QexAq4qBJuyYWc2wRW0i9MtVzVyyYFOBPCkYF97NAXY=.b9d5a998-2b82-464c-84cb-bd3264cc74b4@github.com>

On Mon, 13 Feb 2023 09:59:24 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> We can improve various String methods such as `startsWith`, `endsWith` and `regionMatches` by leveraging the intrinsified mismatch methods in `ArraysSupport`.

Amazing gains!
Congratulations

-------------

PR: https://git.openjdk.org/jdk/pull/12528

From dfuchs at openjdk.org  Mon Feb 13 11:06:30 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 13 Feb 2023 11:06:30 GMT
Subject: RFR: 8301627: System.exit and Runtime.exit debug logging
In-Reply-To: <2zbWTodXVENcsxo-J5IcBLxQoHqnIdtmB4TnV5w7Uag=.d4aa5964-5e0e-41b5-b6f9-39f4edb1b2b4@github.com>
References: <OzJeJH5yxolKPChcUisqtzGYF_MU3oOJdx6HPhsXjBw=.15eefe39-efe1-433e-a6ac-02b4a730f264@github.com>
 <2zbWTodXVENcsxo-J5IcBLxQoHqnIdtmB4TnV5w7Uag=.d4aa5964-5e0e-41b5-b6f9-39f4edb1b2b4@github.com>
Message-ID: <fpoG44CoHxj8JXmx6ry-xdQK2HFfj02RBdT3S9NrIs0=.cdf07271-43a0-4fc4-a10e-545ed4e92492@github.com>

On Sun, 12 Feb 2023 18:15:25 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> It can be difficult to find the cause of calls to `java.lang.System.exit(status)` and `Runtime.exit(status)` because the Java runtime exits.
>> The status value and stack trace are logged using the System Logger named `java.lang.Runtime` with message level `System.Logger.Level.DEBUG`.
>
> src/java.base/share/classes/java/lang/Shutdown.java line 162:
> 
>> 160:      * If the system logger {@code java.lang.Runtime} is enabled for logging level DEBUG/FINE
>> 161:      * the stack trace of the call to {@code Runtime.exit()} or {@code System.exit()}
>> 162:      * is logged.
> 
> Shutdown is not a public class so this impNote won't appear in the APIs docs. Should it move to Runtime.exit and System.exit?  If it moved to a public API then "system logger" could link to System.Logger. Also would it be more correct to say "a system logger named "java.lang.Runtime" is enabled for logging levels DEBUG or FINE"?

FINE is not a level supported by the System.Logger, it is the level to which DEBUG is mapped when the backend is java.util.logging. I suggest to remove FINE from this description and add an `{@link Loger.Level#DEBUG DEBUG}` around DEBUG.

> test/jdk/java/lang/runtime/RuntimeExitLogTest.java line 89:
> 
>> 87:         }
>> 88:         cmd.add(this.getClass().getName());
>> 89:         cmd.add(Integer.toString(status));
> 
> Another possibility for testing this is to launch with ` --limit-modules java.base -Djdk.system.logger.level=DEBUG` to use the simple console implementation that is in java.base and avoid needing properties files for j.u.logging. Just mentioning is an option to make it simple.

Good point - though maybe both configurations should be tested. The j.u.l.LogManager registers some shutdown hook so I believe it's important to test with j.u.l present too.

-------------

PR: https://git.openjdk.org/jdk/pull/12517

From duke at openjdk.org  Mon Feb 13 11:15:40 2023
From: duke at openjdk.org (Varada M)
Date: Mon, 13 Feb 2023 11:15:40 GMT
Subject: Integrated: 8300139 : [AIX] Use pthreads to avoid JNI_createVM call
 from primordial thread
In-Reply-To: <qbwPBNdxzk4QmB9L6y2t-X6uYgAaPjzAEwYfs_5XV_0=.4ea982e6-30da-4219-b8ad-fa36690170b8@github.com>
References: <qbwPBNdxzk4QmB9L6y2t-X6uYgAaPjzAEwYfs_5XV_0=.4ea982e6-30da-4219-b8ad-fa36690170b8@github.com>
Message-ID: <MF6hrR9Fiv5VCsm3G0QXOrxOLenfTzPElgnTG6An__E=.569f9bc9-c172-4d95-86ad-a25cd3dc47ba@github.com>

On Tue, 31 Jan 2023 05:24:35 GMT, Varada M <duke at openjdk.org> wrote:

> 1. test/jdk/jni/nullCaller/NullCallerTest.java
> 2. test/jdk/java/lang/reflect/exeCallerAccessTest/CallerAccessTest.java
> 3. test/hotspot/jtreg/runtime/jni/CalleeSavedRegisters/FPRegs.java 
> 
>     The above tests were blocked on AIX [@require os.family != "aix"] because these tests are failing to call JNI_CreateJavaVM. This is solved by implementing JNI_CreateJavaVM call via POSIX threads. 
>    Similarly there are tests which are not blocked and still failing to call JNI_CreateJavaVM on AIX :
> 
> 4. test/hotspot/jtreg/runtime/jni/daemonDestroy/TestDaemonDestroy.java { PR : [12006](https://github.com/openjdk/jdk/pull/12006) }
> 5. test/lib-test/jdk/test/lib/process/TestNativeProcessBuilder.java 
> 
> The reported issue : [8300139](https://bugs.openjdk.org/browse/JDK-8300139l)

This pull request has now been integrated.

Changeset: cb810730
Author:    Varada M <mvarada2000 at gmail.com>
Committer: Thomas Stuefe <stuefe at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/cb8107303ed0563e06b1e2009d521869f4ca21e8
Stats:     129 lines in 7 files changed: 88 ins; 12 del; 29 mod

8300139: [AIX] Use pthreads to avoid JNI_createVM call from primordial thread

Reviewed-by: dholmes, stuefe

-------------

PR: https://git.openjdk.org/jdk/pull/12302

From alanb at openjdk.org  Mon Feb 13 11:20:38 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 13 Feb 2023 11:20:38 GMT
Subject: RFR: 8301958: Reduce Arrays.copyOf/-Range overheads [v10]
In-Reply-To: <0CS72UlGjDn0Wel_aYv6X7O6siPVGeSn9-jzDxxkMn4=.c9483a26-3cd6-4b63-9c30-765190a784e3@github.com>
References: <2pdPoSHz2RJ7YDHOwOyszQMVv0v7FQFOwykfJ-za_e0=.cfe480da-a045-4b9a-bec7-7fffd0f47206@github.com>
 <0CS72UlGjDn0Wel_aYv6X7O6siPVGeSn9-jzDxxkMn4=.c9483a26-3cd6-4b63-9c30-765190a784e3@github.com>
Message-ID: <U8ig6AYqV7Xob4AbQQES2rqq9KTMfCefMkWqZl_YBtw=.48cd5db6-73ef-481f-b790-dd8f6cb68434@github.com>

On Mon, 13 Feb 2023 09:59:52 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> This patch adds special-cases to `Arrays.copyOf` and `Arrays.copyOfRange` to copy arrays more efficiently when exactly the whole input array is to be copied. This helps eliminate range checks and has been verified to help various String operations. Example:
>> 
>> Baseline
>> 
>> Benchmark                                            (size)  Mode  Cnt   Score   Error  Units
>> StringConstructor.newStringFromArray                      7  avgt   15  16.817 ? 0.369  ns/op
>> StringConstructor.newStringFromArrayWithCharset           7  avgt   15  16.866 ? 0.449  ns/op
>> StringConstructor.newStringFromArrayWithCharsetName       7  avgt   15  22.198 ? 0.396  ns/op
>> 
>> Patch: 
>> 
>> Benchmark                                            (size)  Mode  Cnt   Score   Error  Units
>> StringConstructor.newStringFromArray                      7  avgt   15  14.666 ? 0.336  ns/op
>> StringConstructor.newStringFromArrayWithCharset           7  avgt   15  14.582 ? 0.288  ns/op
>> StringConstructor.newStringFromArrayWithCharsetName       7  avgt   15  20.339 ? 0.328  ns/op
>
> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address review comments

Marked as reviewed by alanb (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/12453

From redestad at openjdk.org  Mon Feb 13 11:20:40 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Mon, 13 Feb 2023 11:20:40 GMT
Subject: Integrated: 8301958: Reduce Arrays.copyOf/-Range overheads
In-Reply-To: <2pdPoSHz2RJ7YDHOwOyszQMVv0v7FQFOwykfJ-za_e0=.cfe480da-a045-4b9a-bec7-7fffd0f47206@github.com>
References: <2pdPoSHz2RJ7YDHOwOyszQMVv0v7FQFOwykfJ-za_e0=.cfe480da-a045-4b9a-bec7-7fffd0f47206@github.com>
Message-ID: <NS3Gid-k3h2sr8MZ52mBuTe3U743Na-vkHjtgC3Dny8=.de2bcf26-24d1-488f-bca7-52de0a6830f9@github.com>

On Tue, 7 Feb 2023 13:30:35 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> This patch adds special-cases to `Arrays.copyOf` and `Arrays.copyOfRange` to copy arrays more efficiently when exactly the whole input array is to be copied. This helps eliminate range checks and has been verified to help various String operations. Example:
> 
> Baseline
> 
> Benchmark                                            (size)  Mode  Cnt   Score   Error  Units
> StringConstructor.newStringFromArray                      7  avgt   15  16.817 ? 0.369  ns/op
> StringConstructor.newStringFromArrayWithCharset           7  avgt   15  16.866 ? 0.449  ns/op
> StringConstructor.newStringFromArrayWithCharsetName       7  avgt   15  22.198 ? 0.396  ns/op
> 
> Patch: 
> 
> Benchmark                                            (size)  Mode  Cnt   Score   Error  Units
> StringConstructor.newStringFromArray                      7  avgt   15  14.666 ? 0.336  ns/op
> StringConstructor.newStringFromArrayWithCharset           7  avgt   15  14.582 ? 0.288  ns/op
> StringConstructor.newStringFromArrayWithCharsetName       7  avgt   15  20.339 ? 0.328  ns/op

This pull request has now been integrated.

Changeset: 1f9c110c
Author:    Claes Redestad <redestad at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/1f9c110c1f9ea6f5c3621a25692ce9d7abf245d4
Stats:     209 lines in 2 files changed: 179 ins; 21 del; 9 mod

8301958: Reduce Arrays.copyOf/-Range overheads

Reviewed-by: alanb, smarks

-------------

PR: https://git.openjdk.org/jdk/pull/12453

From redestad at openjdk.org  Mon Feb 13 11:20:38 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Mon, 13 Feb 2023 11:20:38 GMT
Subject: RFR: 8301958: Reduce Arrays.copyOf/-Range overheads [v10]
In-Reply-To: <0CS72UlGjDn0Wel_aYv6X7O6siPVGeSn9-jzDxxkMn4=.c9483a26-3cd6-4b63-9c30-765190a784e3@github.com>
References: <2pdPoSHz2RJ7YDHOwOyszQMVv0v7FQFOwykfJ-za_e0=.cfe480da-a045-4b9a-bec7-7fffd0f47206@github.com>
 <0CS72UlGjDn0Wel_aYv6X7O6siPVGeSn9-jzDxxkMn4=.c9483a26-3cd6-4b63-9c30-765190a784e3@github.com>
Message-ID: <66fmjOkSa2Jh9SMguxzJUI0k2ucsndLE4Jc8KkSCZs4=.5612aa6c-13c7-4047-a4c9-bf6d87c68c48@github.com>

On Mon, 13 Feb 2023 09:59:52 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> This patch adds special-cases to `Arrays.copyOf` and `Arrays.copyOfRange` to copy arrays more efficiently when exactly the whole input array is to be copied. This helps eliminate range checks and has been verified to help various String operations. Example:
>> 
>> Baseline
>> 
>> Benchmark                                            (size)  Mode  Cnt   Score   Error  Units
>> StringConstructor.newStringFromArray                      7  avgt   15  16.817 ? 0.369  ns/op
>> StringConstructor.newStringFromArrayWithCharset           7  avgt   15  16.866 ? 0.449  ns/op
>> StringConstructor.newStringFromArrayWithCharsetName       7  avgt   15  22.198 ? 0.396  ns/op
>> 
>> Patch: 
>> 
>> Benchmark                                            (size)  Mode  Cnt   Score   Error  Units
>> StringConstructor.newStringFromArray                      7  avgt   15  14.666 ? 0.336  ns/op
>> StringConstructor.newStringFromArrayWithCharset           7  avgt   15  14.582 ? 0.288  ns/op
>> StringConstructor.newStringFromArrayWithCharsetName       7  avgt   15  20.339 ? 0.328  ns/op
>
> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address review comments

Thanks for reviewng!

I've filed https://bugs.openjdk.org/browse/JDK-8302315 to investigate the clone/arraycopy performance discrepancy. Ideally we should be able to just do `array.clone()` here and get optimal performance with less code.

-------------

PR: https://git.openjdk.org/jdk/pull/12453

From duke at openjdk.org  Mon Feb 13 11:24:26 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Mon, 13 Feb 2023 11:24:26 GMT
Subject: RFR: 8302163: Speed up various String comparison methods with
 ArraysSupport.mismatch
In-Reply-To: <geAF-Q1dnCoJ0vCqMNHXXziVGii47nOkfyw5RTL_Wb0=.79392f23-0846-4e04-8b19-87289c3bf49f@github.com>
References: <geAF-Q1dnCoJ0vCqMNHXXziVGii47nOkfyw5RTL_Wb0=.79392f23-0846-4e04-8b19-87289c3bf49f@github.com>
Message-ID: <tZikl9nZ3Br_g5cKu0qyGkxRDCtskJ3CHSVMCbhwBNw=.8aa830b0-870a-4936-825b-b39b67595418@github.com>

On Mon, 13 Feb 2023 09:59:24 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> We can improve various String methods such as `startsWith`, `endsWith` and `regionMatches` by leveraging the intrinsified mismatch methods in `ArraysSupport`.

` cat PR >> https://cl4es.github.io/`

-------------

PR: https://git.openjdk.org/jdk/pull/12528

From tvaleev at openjdk.org  Mon Feb 13 13:00:31 2023
From: tvaleev at openjdk.org (Tagir F. Valeev)
Date: Mon, 13 Feb 2023 13:00:31 GMT
Subject: RFR: 8301226: Add clamp() methods to java.lang.Math and to
 StrictMath [v8]
In-Reply-To: <-RM6Jh13GZ4ZSt1qMwNp8Wb26qjGphOY89TaGenMzkM=.a04659cd-9f11-4af8-a53c-98d9ff837198@github.com>
References: <c7kJhZvT8oz5hScMxnWI23H7wjCaJ854ajjSRtxBnW4=.3f4e24ca-c608-4541-b80e-cf3452ec6400@github.com>
 <-RM6Jh13GZ4ZSt1qMwNp8Wb26qjGphOY89TaGenMzkM=.a04659cd-9f11-4af8-a53c-98d9ff837198@github.com>
Message-ID: <_sxfFCnYV9J7kcuKn8NCLgTLfUvOLfjGxsszWg5S_vE=.d5c053ea-1b0d-4afb-b241-6dd93f2332f8@github.com>

On Tue, 7 Feb 2023 12:53:25 GMT, Tagir F. Valeev <tvaleev at openjdk.org> wrote:

>> clamp() methods added to Math and StrictMath
>> 
>> `int clamp(long, int, int)` is somewhat different, as it accepts a `long` value and safely clamps it to an `int` range. Other overloads work with a particular type (long, float and double). Using similar approach in other cases (e.g. `float clamp(double, float, float)`) may cause accidental precision loss even if the value is within range, so I decided to avoid this.
>> 
>> In all cases, `max >= min` precondition should met. For double and float we additionally order `-0.0 < 0.0`, similarly to what Math.max or Double.compare do. In double and float overloads I try to keep at most one arg-check comparison on common path, so the order of checks might look unusual.
>> 
>> For tests, I noticed that tests in java/lang/Math don't use any testing framework (even newer tests), so I somehow mimic the approach of neighbour tests.
>
> Tagir F. Valeev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Comments in tests

Gentle ping: please review this pull request. CSR is already approved. Thank you.

-------------

PR: https://git.openjdk.org/jdk/pull/12428

From sgehwolf at openjdk.org  Mon Feb 13 14:20:07 2023
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Mon, 13 Feb 2023 14:20:07 GMT
Subject: RFR: 8302325: Wrong comment in
 java.base/share/native/libjimage/imageFile.hpp
Message-ID: <ThM7YJ5rlOnQWHBmPQGzPcQ-vrBiR_-OgJL46jeJIV8=.0e736e79-1fe3-40bb-8702-165028592e1c@github.com>

Could I please get a review of this trivial comment-only change? `imageFile.hpp`
describes some properties of the jimage file `lib/modules`. However, I don't think
the comment example matches current code in the JDK. [`ATTRIBUTE_OFFSET`](https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/jdk/internal/jimage/ImageLocation.java#L44) get
written to the image file with value `0x05` while the comment mentions it gets
written as `0x04`. I propose to fix the comment so that it matches the code.

In passing, I've also fixed a comment related to `ATTRIBUTE_END`. I think the point
being made there is about byte values of `[0x01..0x07]`, all would represent
`ATTRIBUTE_END`, as the upper `5` bits would be `0`. Therefore, byte `0x01` would equally
represent `ATTRIBUTE_END` as would `0x00` and `0x07` or any value in between.

Thoughts?

-------------

Commit messages:
 - 8302325: Wrong comment in java.base/share/native/libjimage/imageFile.hpp

Changes: https://git.openjdk.org/jdk/pull/12533/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12533&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8302325
  Stats: 4 lines in 2 files changed: 0 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/12533.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12533/head:pull/12533

PR: https://git.openjdk.org/jdk/pull/12533

From stsypanov at openjdk.org  Mon Feb 13 15:11:25 2023
From: stsypanov at openjdk.org (Sergey Tsypanov)
Date: Mon, 13 Feb 2023 15:11:25 GMT
Subject: RFR: 8302163: Speed up various String comparison methods with
 ArraysSupport.mismatch
In-Reply-To: <geAF-Q1dnCoJ0vCqMNHXXziVGii47nOkfyw5RTL_Wb0=.79392f23-0846-4e04-8b19-87289c3bf49f@github.com>
References: <geAF-Q1dnCoJ0vCqMNHXXziVGii47nOkfyw5RTL_Wb0=.79392f23-0846-4e04-8b19-87289c3bf49f@github.com>
Message-ID: <MMV-ncCCcelHYBny_tpqdj5Jpx7HEiTZlFdvv2rSPk4=.fcc764fa-90a0-4b93-8277-52bd2143e63d@github.com>

On Mon, 13 Feb 2023 09:59:24 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> We can improve various String methods such as `startsWith`, `endsWith` and `regionMatches` by leveraging the intrinsified mismatch methods in `ArraysSupport`.

Looks simple and harmless.

-------------

Marked as reviewed by stsypanov (Author).

PR: https://git.openjdk.org/jdk/pull/12528

From rriggs at openjdk.org  Mon Feb 13 15:37:29 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 13 Feb 2023 15:37:29 GMT
Subject: RFR: 8302163: Speed up various String comparison methods with
 ArraysSupport.mismatch
In-Reply-To: <geAF-Q1dnCoJ0vCqMNHXXziVGii47nOkfyw5RTL_Wb0=.79392f23-0846-4e04-8b19-87289c3bf49f@github.com>
References: <geAF-Q1dnCoJ0vCqMNHXXziVGii47nOkfyw5RTL_Wb0=.79392f23-0846-4e04-8b19-87289c3bf49f@github.com>
Message-ID: <0m2M-de-I3pb0jXX_NcEfvaFUwrTzolcAf992np35V0=.d452ffec-a072-4246-bb14-9ebe39ca9a02@github.com>

On Mon, 13 Feb 2023 09:59:24 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> We can improve various String methods such as `startsWith`, `endsWith` and `regionMatches` by leveraging the intrinsified mismatch methods in `ArraysSupport`.

Look good.

-------------

Marked as reviewed by rriggs (Reviewer).

PR: https://git.openjdk.org/jdk/pull/12528

From alanb at openjdk.org  Mon Feb 13 16:01:27 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 13 Feb 2023 16:01:27 GMT
Subject: RFR: 8302163: Speed up various String comparison methods with
 ArraysSupport.mismatch
In-Reply-To: <geAF-Q1dnCoJ0vCqMNHXXziVGii47nOkfyw5RTL_Wb0=.79392f23-0846-4e04-8b19-87289c3bf49f@github.com>
References: <geAF-Q1dnCoJ0vCqMNHXXziVGii47nOkfyw5RTL_Wb0=.79392f23-0846-4e04-8b19-87289c3bf49f@github.com>
Message-ID: <ZxH0JLFLLn00kgSubyElp2NBUlwrLnDeeKU9-dA1LQA=.6b661583-5d7c-4094-b5a5-894844c3d436@github.com>

On Mon, 13 Feb 2023 09:59:24 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> We can improve various String methods such as `startsWith`, `endsWith` and `regionMatches` by leveraging the intrinsified mismatch methods in `ArraysSupport`.

src/java.base/share/classes/java/lang/String.java line 2272:

> 2270:             toffset <<= coder;
> 2271:             return ArraysSupport.mismatch(ta, toffset,
> 2272:                     pa, 0, pc) < 0;

`offset <<= coder` is only obvious if the reader knows the value of LATIN1, maybe it would be simpler to read if you kept "int to"?

-------------

PR: https://git.openjdk.org/jdk/pull/12528

From redestad at openjdk.org  Mon Feb 13 16:10:14 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Mon, 13 Feb 2023 16:10:14 GMT
Subject: RFR: 8302163: Speed up various String comparison methods with
 ArraysSupport.mismatch [v2]
In-Reply-To: <geAF-Q1dnCoJ0vCqMNHXXziVGii47nOkfyw5RTL_Wb0=.79392f23-0846-4e04-8b19-87289c3bf49f@github.com>
References: <geAF-Q1dnCoJ0vCqMNHXXziVGii47nOkfyw5RTL_Wb0=.79392f23-0846-4e04-8b19-87289c3bf49f@github.com>
Message-ID: <sLJArQhn8qKv67Op1gS-WMAnsXTJBqR_qWbdzApxOLc=.d225ea1e-1039-4492-877d-ede8b5a122b3@github.com>

> We can improve various String methods such as `startsWith`, `endsWith` and `regionMatches` by leveraging the intrinsified mismatch methods in `ArraysSupport`.

Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:

  Clarify coder shift in startsWith

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12528/files
  - new: https://git.openjdk.org/jdk/pull/12528/files/6cac333d..b63954bf

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12528&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12528&range=00-01

  Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/12528.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12528/head:pull/12528

PR: https://git.openjdk.org/jdk/pull/12528

From duke at openjdk.org  Mon Feb 13 16:46:30 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Mon, 13 Feb 2023 16:46:30 GMT
Subject: RFR: 8302163: Speed up various String comparison methods with
 ArraysSupport.mismatch [v2]
In-Reply-To: <sLJArQhn8qKv67Op1gS-WMAnsXTJBqR_qWbdzApxOLc=.d225ea1e-1039-4492-877d-ede8b5a122b3@github.com>
References: <geAF-Q1dnCoJ0vCqMNHXXziVGii47nOkfyw5RTL_Wb0=.79392f23-0846-4e04-8b19-87289c3bf49f@github.com>
 <sLJArQhn8qKv67Op1gS-WMAnsXTJBqR_qWbdzApxOLc=.d225ea1e-1039-4492-877d-ede8b5a122b3@github.com>
Message-ID: <xWaMFUc2e0SIQkuEzsV_pAAMvhXJn39gRLP1yDKLDHM=.58cc1b3f-6d38-4b66-be5a-e4ddc8502ad5@github.com>

On Mon, 13 Feb 2023 16:10:14 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> We can improve various String methods such as `startsWith`, `endsWith` and `regionMatches` by leveraging the intrinsified mismatch methods in `ArraysSupport`.
>
> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Clarify coder shift in startsWith

Case-insensitive regionMatches could be improved by using ArraysSupport.mismatch to skip over long common substrings:

PR:


Benchmark                          (size)  (utf16)  Mode  Cnt    Score   Error  Units
StringComparisons.regionMatchesCI       6    false  avgt   15    8.248 ? 0.427  ns/op
StringComparisons.regionMatchesCI      15    false  avgt   15   11.408 ? 0.429  ns/op
StringComparisons.regionMatchesCI    1024    false  avgt   15  328.796 ? 7.191  ns/op


Arrays.mismatch:

Benchmark                          (size)  (utf16)  Mode  Cnt   Score   Error  Units
StringComparisons.regionMatchesCI       6    false  avgt   15  10.608 ? 0.302  ns/op
StringComparisons.regionMatchesCI      15    false  avgt   15   8.772 ? 0.347  ns/op
StringComparisons.regionMatchesCI    1024    false  avgt   15  31.070 ? 1.783  ns/op


Patch on top of your PR:


Index: src/java.base/share/classes/java/lang/StringLatin1.java
IDEA additional info:
Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP
<+>UTF-8
===================================================================
diff --git a/src/java.base/share/classes/java/lang/StringLatin1.java b/src/java.base/share/classes/java/lang/StringLatin1.java
--- a/src/java.base/share/classes/java/lang/StringLatin1.java	(revision 6cac333d8f9f34e16168447c60f28a6b0d31623f)
+++ b/src/java.base/share/classes/java/lang/StringLatin1.java	(date 1676305817928)
@@ -384,6 +384,14 @@
                                           byte[] other, int ooffset, int len) {
         int last = toffset + len;
         while (toffset < last) {
+            int mismatch = ArraysSupport.mismatch(value, toffset, other, ooffset, len);
+            if (mismatch == -1) {
+                return true;
+            } else {
+                toffset += mismatch;
+                ooffset += mismatch;
+                len -= mismatch + 1;
+            }
             char c1 = (char)(value[toffset++] & 0xff);
             char c2 = (char)(other[ooffset++] & 0xff);
             if (c1 == c2) {
Index: test/micro/org/openjdk/bench/java/lang/StringComparisons.java
IDEA additional info:
Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP
<+>UTF-8
===================================================================
diff --git a/test/micro/org/openjdk/bench/java/lang/StringComparisons.java b/test/micro/org/openjdk/bench/java/lang/StringComparisons.java
--- a/test/micro/org/openjdk/bench/java/lang/StringComparisons.java	(revision 6cac333d8f9f34e16168447c60f28a6b0d31623f)
+++ b/test/micro/org/openjdk/bench/java/lang/StringComparisons.java	(date 1676305817914)
@@ -49,6 +49,7 @@
     public String endsWithA;
     public String endsWithB;
     public String startsWithA;
+    public String endsWitha;
 
     @Setup
     public void setup() {
@@ -56,6 +57,7 @@
         string = c.repeat(size);
         equalString = c.repeat(size);
         endsWithA = c.repeat(size).concat("A");
+        endsWitha = c.repeat(size).concat("a");
         endsWithB = c.repeat(size).concat("B");
         startsWithA = "A" + (c.repeat(size));
     }
@@ -75,6 +77,11 @@
         return endsWithA.regionMatches(0, endsWithB, 0, endsWithB.length());
     }
 
+    @Benchmark
+    public boolean regionMatchesIC() {
+        return endsWithA.regionMatches(true,0, endsWitha, 0, endsWitha.length());
+    }
+
     @Benchmark
     public boolean regionMatchesRange() {
         return startsWithA.regionMatches(1, endsWithB, 0, endsWithB.length() - 1);

-------------

PR: https://git.openjdk.org/jdk/pull/12528

From qamai at openjdk.org  Mon Feb 13 16:53:28 2023
From: qamai at openjdk.org (Quan Anh Mai)
Date: Mon, 13 Feb 2023 16:53:28 GMT
Subject: RFR: 8301226: Add clamp() methods to java.lang.Math and to
 StrictMath [v8]
In-Reply-To: <-RM6Jh13GZ4ZSt1qMwNp8Wb26qjGphOY89TaGenMzkM=.a04659cd-9f11-4af8-a53c-98d9ff837198@github.com>
References: <c7kJhZvT8oz5hScMxnWI23H7wjCaJ854ajjSRtxBnW4=.3f4e24ca-c608-4541-b80e-cf3452ec6400@github.com>
 <-RM6Jh13GZ4ZSt1qMwNp8Wb26qjGphOY89TaGenMzkM=.a04659cd-9f11-4af8-a53c-98d9ff837198@github.com>
Message-ID: <w2xibxq2s4ymYD6ON192xRdx5izEZtnR0PGE-cp2Jno=.f5a5279a-e55a-4364-8c68-e684dd3b79c5@github.com>

On Tue, 7 Feb 2023 12:53:25 GMT, Tagir F. Valeev <tvaleev at openjdk.org> wrote:

>> clamp() methods added to Math and StrictMath
>> 
>> `int clamp(long, int, int)` is somewhat different, as it accepts a `long` value and safely clamps it to an `int` range. Other overloads work with a particular type (long, float and double). Using similar approach in other cases (e.g. `float clamp(double, float, float)`) may cause accidental precision loss even if the value is within range, so I decided to avoid this.
>> 
>> In all cases, `max >= min` precondition should met. For double and float we additionally order `-0.0 < 0.0`, similarly to what Math.max or Double.compare do. In double and float overloads I try to keep at most one arg-check comparison on common path, so the order of checks might look unusual.
>> 
>> For tests, I noticed that tests in java/lang/Math don't use any testing framework (even newer tests), so I somehow mimic the approach of neighbour tests.
>
> Tagir F. Valeev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Comments in tests

Marked as reviewed by qamai (Committer).

-------------

PR: https://git.openjdk.org/jdk/pull/12428

From alanb at openjdk.org  Mon Feb 13 16:59:30 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 13 Feb 2023 16:59:30 GMT
Subject: RFR: 8302163: Speed up various String comparison methods with
 ArraysSupport.mismatch [v2]
In-Reply-To: <sLJArQhn8qKv67Op1gS-WMAnsXTJBqR_qWbdzApxOLc=.d225ea1e-1039-4492-877d-ede8b5a122b3@github.com>
References: <geAF-Q1dnCoJ0vCqMNHXXziVGii47nOkfyw5RTL_Wb0=.79392f23-0846-4e04-8b19-87289c3bf49f@github.com>
 <sLJArQhn8qKv67Op1gS-WMAnsXTJBqR_qWbdzApxOLc=.d225ea1e-1039-4492-877d-ede8b5a122b3@github.com>
Message-ID: <a2qFEOsTbcBMvKv1zpJ9ZKxhVldcQ335EdpWUqK9OyQ=.78f4274b-f7f8-42ac-a302-d4eb43c91661@github.com>

On Mon, 13 Feb 2023 16:10:14 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> We can improve various String methods such as `startsWith`, `endsWith` and `regionMatches` by leveraging the intrinsified mismatch methods in `ArraysSupport`.
>
> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Clarify coder shift in startsWith

Marked as reviewed by alanb (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/12528

From qamai at openjdk.org  Mon Feb 13 17:07:31 2023
From: qamai at openjdk.org (Quan Anh Mai)
Date: Mon, 13 Feb 2023 17:07:31 GMT
Subject: RFR: 8301226: Add clamp() methods to java.lang.Math and to
 StrictMath [v8]
In-Reply-To: <-RM6Jh13GZ4ZSt1qMwNp8Wb26qjGphOY89TaGenMzkM=.a04659cd-9f11-4af8-a53c-98d9ff837198@github.com>
References: <c7kJhZvT8oz5hScMxnWI23H7wjCaJ854ajjSRtxBnW4=.3f4e24ca-c608-4541-b80e-cf3452ec6400@github.com>
 <-RM6Jh13GZ4ZSt1qMwNp8Wb26qjGphOY89TaGenMzkM=.a04659cd-9f11-4af8-a53c-98d9ff837198@github.com>
Message-ID: <Cqiv4Flxd7Dyt7FP0syj0b6jIW9J-m68YLwZF10YLd4=.e1389720-7b89-481d-be9c-fa43d3d7c236@github.com>

On Tue, 7 Feb 2023 12:53:25 GMT, Tagir F. Valeev <tvaleev at openjdk.org> wrote:

>> clamp() methods added to Math and StrictMath
>> 
>> `int clamp(long, int, int)` is somewhat different, as it accepts a `long` value and safely clamps it to an `int` range. Other overloads work with a particular type (long, float and double). Using similar approach in other cases (e.g. `float clamp(double, float, float)`) may cause accidental precision loss even if the value is within range, so I decided to avoid this.
>> 
>> In all cases, `max >= min` precondition should met. For double and float we additionally order `-0.0 < 0.0`, similarly to what Math.max or Double.compare do. In double and float overloads I try to keep at most one arg-check comparison on common path, so the order of checks might look unusual.
>> 
>> For tests, I noticed that tests in java/lang/Math don't use any testing framework (even newer tests), so I somehow mimic the approach of neighbour tests.
>
> Tagir F. Valeev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Comments in tests

Just a small point:

> Using similar approach in other cases (e.g. `float clamp(double, float, float))` may cause accidental precision loss even if the value is within range

May I ask at which values of the parameters does this occur? AFAIU, every `float` may be represented exactly by a `double`, which is the same situation with `long` and `int`.

-------------

PR: https://git.openjdk.org/jdk/pull/12428

From rgiulietti at openjdk.org  Mon Feb 13 17:14:34 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Mon, 13 Feb 2023 17:14:34 GMT
Subject: RFR: 8301226: Add clamp() methods to java.lang.Math and to
 StrictMath [v8]
In-Reply-To: <Cqiv4Flxd7Dyt7FP0syj0b6jIW9J-m68YLwZF10YLd4=.e1389720-7b89-481d-be9c-fa43d3d7c236@github.com>
References: <c7kJhZvT8oz5hScMxnWI23H7wjCaJ854ajjSRtxBnW4=.3f4e24ca-c608-4541-b80e-cf3452ec6400@github.com>
 <-RM6Jh13GZ4ZSt1qMwNp8Wb26qjGphOY89TaGenMzkM=.a04659cd-9f11-4af8-a53c-98d9ff837198@github.com>
 <Cqiv4Flxd7Dyt7FP0syj0b6jIW9J-m68YLwZF10YLd4=.e1389720-7b89-481d-be9c-fa43d3d7c236@github.com>
Message-ID: <mPaMhhI-ZtOz2-CjuzhdXSzT2eMnPyhOxKJ_2XtfdnI=.3a4c64a3-769e-4a91-b5fb-f86a762b85e7@github.com>

On Mon, 13 Feb 2023 17:05:06 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

>> Tagir F. Valeev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Comments in tests
>
> Just a small point:
> 
>> Using similar approach in other cases (e.g. `float clamp(double, float, float))` may cause accidental precision loss even if the value is within range
> 
> May I ask at which values of the parameters does this occur? AFAIU, every `float` may be represented exactly by a `double`, which is the same situation with `long` and `int`.

@merykitty That clamp method would round a `double` to a `float`, an accidental precision loss.

-------------

PR: https://git.openjdk.org/jdk/pull/12428

From qamai at openjdk.org  Mon Feb 13 17:14:36 2023
From: qamai at openjdk.org (Quan Anh Mai)
Date: Mon, 13 Feb 2023 17:14:36 GMT
Subject: RFR: 8301226: Add clamp() methods to java.lang.Math and to
 StrictMath [v8]
In-Reply-To: <-RM6Jh13GZ4ZSt1qMwNp8Wb26qjGphOY89TaGenMzkM=.a04659cd-9f11-4af8-a53c-98d9ff837198@github.com>
References: <c7kJhZvT8oz5hScMxnWI23H7wjCaJ854ajjSRtxBnW4=.3f4e24ca-c608-4541-b80e-cf3452ec6400@github.com>
 <-RM6Jh13GZ4ZSt1qMwNp8Wb26qjGphOY89TaGenMzkM=.a04659cd-9f11-4af8-a53c-98d9ff837198@github.com>
Message-ID: <ZbZ6Y9solR2_Ge54ynR9PN6oSwI4_tD3d1zfCd69E2I=.6e28079d-d322-42f2-864b-a23d9843d32f@github.com>

On Tue, 7 Feb 2023 12:53:25 GMT, Tagir F. Valeev <tvaleev at openjdk.org> wrote:

>> clamp() methods added to Math and StrictMath
>> 
>> `int clamp(long, int, int)` is somewhat different, as it accepts a `long` value and safely clamps it to an `int` range. Other overloads work with a particular type (long, float and double). Using similar approach in other cases (e.g. `float clamp(double, float, float)`) may cause accidental precision loss even if the value is within range, so I decided to avoid this.
>> 
>> In all cases, `max >= min` precondition should met. For double and float we additionally order `-0.0 < 0.0`, similarly to what Math.max or Double.compare do. In double and float overloads I try to keep at most one arg-check comparison on common path, so the order of checks might look unusual.
>> 
>> For tests, I noticed that tests in java/lang/Math don't use any testing framework (even newer tests), so I somehow mimic the approach of neighbour tests.
>
> Tagir F. Valeev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Comments in tests

Ah yes that's my bad

-------------

PR: https://git.openjdk.org/jdk/pull/12428

From sgehwolf at openjdk.org  Mon Feb 13 17:20:11 2023
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Mon, 13 Feb 2023 17:20:11 GMT
Subject: RFR: 8302337: JDK crashes if lib/modules contains non-zero byte
 containing ATTRIBUTE_END
Message-ID: <6FhVbMx6rkuODI7UDEQANI40yFzovg4pIlqXXPB2yRE=.5a1ed241-6da7-403a-a74b-2c315e94beae@github.com>

The `jimage` location attributes are terminated with `ATTRIBUTE_END`-kinds. However,
the byte containing `ATTRIBUTE_END` (most significant 5 bits, represent `kind`), might
be non-zero in the lower 3 bits (values up to `0x07` represent `ATTRIBUTE_END`). The JDK code
handles this case correctly in [`ImageLocation.decompress()`](https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/jdk/internal/jimage/ImageLocation.java#L69..L71). However, the `libjimage`
code in `java.base` doesn't. That can lead to segfaults reading random bytes and offsets.

I propose to break the loop if `ATTRIBUTE_END` is being encountered so that reading stops.

Testing:
 - [x] `test/jdk/tools/jimage` and `test/jdk/jdk/internal/jimage` tests.
 - [x] Manual testing with a patched JDK to write non-zero bytes containing `ATTRIBUTE_END` into the jimage. Segfaults before, runs fine after.
 - [ ] GHA. In progress.

Thoughts?

-------------

Commit messages:
 - 8302337: JDK crashes if lib/modules contains non-zero ATTRIBUTE_END bytes

Changes: https://git.openjdk.org/jdk/pull/12539/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12539&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8302337
  Stats: 3 lines in 1 file changed: 3 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/12539.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12539/head:pull/12539

PR: https://git.openjdk.org/jdk/pull/12539

From enikitin at openjdk.org  Mon Feb 13 17:49:33 2023
From: enikitin at openjdk.org (Evgeny Nikitin)
Date: Mon, 13 Feb 2023 17:49:33 GMT
Subject: RFR: 8302267: [jittester] Improve separation of test generation and
 execution
Message-ID: <yHw6Lto-nJtPP61cZLDF354osHA-ioeq7_lgpefLvog=.6de22e18-0613-4ffb-a753-b66b95e9d52b@github.com>

Please review a set of improvements that should improve working with other fuzzing generators and usage of JitTesterDriver with tests generated not by the JITTester:

- Provide better separation of individual test generation from java file writing, compiling, executing, etc.;
- Introduce distinct Phases of the generation process (Generation, Compilation, GoldRun and VerificationRun);
- Extract JItTesterDriver headers generation so that it would be possible to provide other header generators;
- Introduce error tolerance to not get distracted by OOMEs, intrinsics missing in the compiled code, etc.;
- Make it possible to specify time limit for an individual test generation;
- Give better control over temp/workdir creation and cleaning;
- Unify external process running;
- Introduce UTF-8 support in external processes' output and human-readable escaping of it;

-------------

Commit messages:
 - Remove tabs from a test to silence jcheck
 - 8302267: [jittester] Improve separation of test generation and execution

Changes: https://git.openjdk.org/jdk/pull/12527/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12527&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8302267
  Stats: 1044 lines in 14 files changed: 834 ins; 161 del; 49 mod
  Patch: https://git.openjdk.org/jdk/pull/12527.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12527/head:pull/12527

PR: https://git.openjdk.org/jdk/pull/12527

From duke at openjdk.org  Mon Feb 13 17:53:28 2023
From: duke at openjdk.org (Scott Gibbons)
Date: Mon, 13 Feb 2023 17:53:28 GMT
Subject: RFR: JDK-8300808: Accelerate Base64 on x86 for AVX2 [v15]
In-Reply-To: <ehO2yEksveYBx5vw4CknkfvlOBavIqt9y4FjqwcqWeU=.a8f22610-de5a-4ffc-bb81-b6d9557965cc@github.com>
References: <9zN3bjyMEikXYOlpjTy9_QPc-9usYiBJMUFdb-TaVrQ=.e8f65ce9-ac0f-4f8d-9c6b-b39ae1c26cd2@github.com>
 <TmYLe9RCiAqtfuyjU77R-faEEVpfmmUoQ89oyBCcEmM=.c6d2d68b-c37d-4c78-a8e4-af4b48df91a5@github.com>
 <ehO2yEksveYBx5vw4CknkfvlOBavIqt9y4FjqwcqWeU=.a8f22610-de5a-4ffc-bb81-b6d9557965cc@github.com>
Message-ID: <iLAw5PPpyj42IduasEaUrDpG46MatI0C0qwYJH4R0gA=.cbc612f5-1235-4495-a6d6-f6293db0d795@github.com>

On Fri, 10 Feb 2023 23:18:47 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> Scott Gibbons has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add URL to microbenchmark
>
> Marked as reviewed by redestad (Reviewer).

@cl4es Can you please initiate the in-depth testing required for this fix?  Thanks.

-------------

PR: https://git.openjdk.org/jdk/pull/12126

From stuefe at openjdk.org  Mon Feb 13 17:58:28 2023
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Mon, 13 Feb 2023 17:58:28 GMT
Subject: RFR: 8302337: JDK crashes if lib/modules contains non-zero byte
 containing ATTRIBUTE_END
In-Reply-To: <6FhVbMx6rkuODI7UDEQANI40yFzovg4pIlqXXPB2yRE=.5a1ed241-6da7-403a-a74b-2c315e94beae@github.com>
References: <6FhVbMx6rkuODI7UDEQANI40yFzovg4pIlqXXPB2yRE=.5a1ed241-6da7-403a-a74b-2c315e94beae@github.com>
Message-ID: <MGmMMjzuDxGpuFE5n-jZaGltA4t7D_RT-dTY-_mKWNI=.60433fd8-833c-46b7-b0fa-011b83cfe0f3@github.com>

On Mon, 13 Feb 2023 16:57:17 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

> The `jimage` location attributes are terminated with `ATTRIBUTE_END`-kinds. However,
> the byte containing `ATTRIBUTE_END` (most significant 5 bits, represent `kind`), might
> be non-zero in the lower 3 bits (values up to `0x07` represent `ATTRIBUTE_END`). The JDK code
> handles this case correctly in [`ImageLocation.decompress()`](https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/jdk/internal/jimage/ImageLocation.java#L69..L71). However, the `libjimage`
> code in `java.base` doesn't. That can lead to segfaults reading random bytes and offsets.
> 
> I propose to break the loop if `ATTRIBUTE_END` is being encountered so that reading stops.
> 
> Testing:
>  - [x] `test/jdk/tools/jimage` and `test/jdk/jdk/internal/jimage` tests.
>  - [x] Manual testing with a patched JDK to write non-zero bytes containing `ATTRIBUTE_END` into the jimage. Segfaults before, runs fine after.
>  - [ ] GHA. In progress.
> 
> Thoughts?

Your patch looks fine to me. Actually slightly clearer to the casual reader than the comparison <=7 the JDK does.

The (preexisting) loop condition is weird; when would data ever become NULL?

src/java.base/share/native/libjimage/imageFile.cpp line 132:

> 130:         // Extract kind from header byte.
> 131:         u1 kind = attribute_kind(byte);
> 132:         assert(kind < ATTRIBUTE_COUNT && "invalid image location attribute");

Not your patch, but the assert is superfluous since attribute_kind already asserts.

-------------

Marked as reviewed by stuefe (Reviewer).

PR: https://git.openjdk.org/jdk/pull/12539

From duke at openjdk.org  Mon Feb 13 17:58:30 2023
From: duke at openjdk.org (Andriy Plokhotnyuk)
Date: Mon, 13 Feb 2023 17:58:30 GMT
Subject: RFR: 8205592: BigDecimal.doubleValue() is depressingly slow
In-Reply-To: <woN4p8g3qytJ3ZPsEBZ2b32O7RGZuA_ohsLKgTACbQY=.8932977c-dba0-4a6e-87f9-bd5304b7e3fc@github.com>
References: <XpbHjLD13akVXWMOh0CVfH3ZjWeWLzMenrJ0UxjMO5I=.03ec2741-0762-459d-b27a-3cc022a48a19@github.com>
 <woN4p8g3qytJ3ZPsEBZ2b32O7RGZuA_ohsLKgTACbQY=.8932977c-dba0-4a6e-87f9-bd5304b7e3fc@github.com>
Message-ID: <6149HcCGk_0tA_3-3Fv7hl5w1CpN7GlySn8DpYwzGI4=.70308bfc-5767-4fa1-ab2d-a3cc1855a39f@github.com>

On Tue, 31 Jan 2023 13:39:46 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> A reimplementation of `BigDecimal.[double|float]Value()` to enhance performance, avoiding an intermediate string and its subsequent parsing on the slow path.
>
> This PR is waiting for a review

@rgiulietti Thanks for keeping making JDK faster!

I have a couple of review comments:

#### 1) For the line https://github.com/openjdk/jdk/pull/9410/files#diff-94d400b99466045dd76001c37eada6b24d086d8d115b49c439752bbceb233772L3746

It seems that removing this check for 22-bit number introduces an extra rounding error.

Please consider just increasing the constant up to `1L << 32` and using `DOUBLE_10_POW` instead of `FLOAT_10_POW`.

Bellow are REPL expressions that illustrate my thoughts (sorry for using Scala):

$ scala
Welcome to Scala 3.2.0 (17.0.5, Java OpenJDK 64-Bit Server VM).
Type in expressions for evaluation. Or try :help.
                                                                                                                                                                                                                   
scala> new java.math.BigDecimal("167772170E-1").floatValue
val res0: Float = 1.6777216E7
                                                                                                                                                                                                                   
scala> 167772170E-1f
val res1: Float = 1.6777216E7
                                                                                                                                                                                                                   
scala> 167772170 / 10.0f
val res2: Float = 1.6777218E7

scala> (167772170 / 10.0).toFloat
val res3: Float = 1.6777216E7

#### 2) For the line: https://github.com/openjdk/jdk/pull/9410/files#diff-94d400b99466045dd76001c37eada6b24d086d8d115b49c439752bbceb233772L3791

It seems that removing this check for 52-bit number introduces an extra rounding error:

$ scala
Welcome to Scala 3.2.0 (17.0.6, Java OpenJDK 64-Bit Server VM).
Type in expressions for evaluation. Or try :help.

scala> new java.math.BigDecimal("90071992547409930E-1").doubleValue
val res0: Double = 9.007199254740992E15
                                                                                                                                                                                                                   
scala> 90071992547409930E-1
val res1: Double = 9.007199254740992E15
                                                                                                                                                                                                                   
scala> 90071992547409930L / 10.0
val res2: Double = 9.007199254740994E15

#### 3) For the line: https://github.com/openjdk/jdk/pull/9410/files#diff-94d400b99466045dd76001c37eada6b24d086d8d115b49c439752bbceb233772L3800
Here before falling back to the costly fallback with big number operations we can [get a number of digits in intCompact](https://github.com/plokhotnyuk/jsoniter-scala/blob/6f702ce5cae05df91b5aa6e4bd61acdf43bf18f6/jsoniter-scala-core/jvm/src/main/scala/com/github/plokhotnyuk/jsoniter_scala/core/JsonWriter.scala#L1930) and use [a trick with two multiplications](https://github.com/plokhotnyuk/jsoniter-scala/blob/6f702ce5cae05df91b5aa6e4bd61acdf43bf18f6/jsoniter-scala-core/jvm/src/main/scala/com/github/plokhotnyuk/jsoniter_scala/core/JsonReader.scala#L1459)

-------------

PR: https://git.openjdk.org/jdk/pull/9410

From mchung at openjdk.org  Mon Feb 13 19:43:36 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Mon, 13 Feb 2023 19:43:36 GMT
Subject: RFR: 8302260: VarHandle.describeConstable() fails to return a nominal
 descriptor for static public fields
Message-ID: <fPx38HtLOHB5dvr9_Z2wFKYKLNsjFIIwExNreo3pHxw=.53c3792d-db7b-42d6-b858-5c3062a57a4f@github.com>

I overlooked in the fix for JDK-8297757 that it should have passed the declaring class of the static fields rather than the reference class passed to `Lookup::findStaticVarHandle`.

-------------

Commit messages:
 - 8302260: VarHandle.describeConstable() fails to return a nominal descriptor for static public fields

Changes: https://git.openjdk.org/jdk/pull/12543/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12543&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8302260
  Stats: 231 lines in 7 files changed: 190 ins; 0 del; 41 mod
  Patch: https://git.openjdk.org/jdk/pull/12543.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12543/head:pull/12543

PR: https://git.openjdk.org/jdk/pull/12543

From jlaskey at openjdk.org  Mon Feb 13 19:49:29 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Mon, 13 Feb 2023 19:49:29 GMT
Subject: RFR: 8302337: JDK crashes if lib/modules contains non-zero byte
 containing ATTRIBUTE_END
In-Reply-To: <6FhVbMx6rkuODI7UDEQANI40yFzovg4pIlqXXPB2yRE=.5a1ed241-6da7-403a-a74b-2c315e94beae@github.com>
References: <6FhVbMx6rkuODI7UDEQANI40yFzovg4pIlqXXPB2yRE=.5a1ed241-6da7-403a-a74b-2c315e94beae@github.com>
Message-ID: <cZ1OzsUlkkJnPGe0xTTeAfT9wX15kq9paVLBdljJOVU=.97fb9fd5-d961-49e0-b29b-b0904f144bc8@github.com>

On Mon, 13 Feb 2023 16:57:17 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

> The `jimage` location attributes are terminated with `ATTRIBUTE_END`-kinds. However,
> the byte containing `ATTRIBUTE_END` (most significant 5 bits, represent `kind`), might
> be non-zero in the lower 3 bits (values up to `0x07` represent `ATTRIBUTE_END`). The JDK code
> handles this case correctly in [`ImageLocation.decompress()`](https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/jdk/internal/jimage/ImageLocation.java#L69..L71). However, the `libjimage`
> code in `java.base` doesn't. That can lead to segfaults reading random bytes and offsets.
> 
> I propose to break the loop if `ATTRIBUTE_END` is being encountered so that reading stops.
> 
> Testing:
>  - [x] `test/jdk/tools/jimage` and `test/jdk/jdk/internal/jimage` tests.
>  - [x] Manual testing with a patched JDK to write non-zero bytes containing `ATTRIBUTE_END` into the jimage. Segfaults before, runs fine after.
>  - [ ] GHA. In progress.
> 
> Thoughts?

LGTM

-------------

Marked as reviewed by jlaskey (Reviewer).

PR: https://git.openjdk.org/jdk/pull/12539

From alanb at openjdk.org  Mon Feb 13 19:53:26 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 13 Feb 2023 19:53:26 GMT
Subject: RFR: 8302337: JDK crashes if lib/modules contains non-zero byte
 containing ATTRIBUTE_END
In-Reply-To: <6FhVbMx6rkuODI7UDEQANI40yFzovg4pIlqXXPB2yRE=.5a1ed241-6da7-403a-a74b-2c315e94beae@github.com>
References: <6FhVbMx6rkuODI7UDEQANI40yFzovg4pIlqXXPB2yRE=.5a1ed241-6da7-403a-a74b-2c315e94beae@github.com>
Message-ID: <_CWXtQeW6BSDDDbMfJGm85_rYuX7mmsWip8th6JT7E8=.69ae1a60-bb36-4196-8199-2a5cf5f2d121@github.com>

On Mon, 13 Feb 2023 16:57:17 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

> The `jimage` location attributes are terminated with `ATTRIBUTE_END`-kinds. However,
> the byte containing `ATTRIBUTE_END` (most significant 5 bits, represent `kind`), might
> be non-zero in the lower 3 bits (values up to `0x07` represent `ATTRIBUTE_END`). The JDK code
> handles this case correctly in [`ImageLocation.decompress()`](https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/jdk/internal/jimage/ImageLocation.java#L69..L71). However, the `libjimage`
> code in `java.base` doesn't. That can lead to segfaults reading random bytes and offsets.
> 
> I propose to break the loop if `ATTRIBUTE_END` is being encountered so that reading stops.
> 
> Testing:
>  - [x] `test/jdk/tools/jimage` and `test/jdk/jdk/internal/jimage` tests.
>  - [x] Manual testing with a patched JDK to write non-zero bytes containing `ATTRIBUTE_END` into the jimage. Segfaults before, runs fine after.
>  - [ ] GHA. In progress.
> 
> Thoughts?

Marked as reviewed by alanb (Reviewer).

The change looks good, I'm just curious whether you observed a crash or whether this was noticed by inspection.

-------------

PR: https://git.openjdk.org/jdk/pull/12539

From rgiulietti at openjdk.org  Mon Feb 13 20:08:31 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Mon, 13 Feb 2023 20:08:31 GMT
Subject: RFR: 8205592: BigDecimal.doubleValue() is depressingly slow
In-Reply-To: <6149HcCGk_0tA_3-3Fv7hl5w1CpN7GlySn8DpYwzGI4=.70308bfc-5767-4fa1-ab2d-a3cc1855a39f@github.com>
References: <XpbHjLD13akVXWMOh0CVfH3ZjWeWLzMenrJ0UxjMO5I=.03ec2741-0762-459d-b27a-3cc022a48a19@github.com>
 <woN4p8g3qytJ3ZPsEBZ2b32O7RGZuA_ohsLKgTACbQY=.8932977c-dba0-4a6e-87f9-bd5304b7e3fc@github.com>
 <6149HcCGk_0tA_3-3Fv7hl5w1CpN7GlySn8DpYwzGI4=.70308bfc-5767-4fa1-ab2d-a3cc1855a39f@github.com>
Message-ID: <3ip7g1h3VLK-iQ48UZHQfEPqoZmwq3mSFhRhMwqZcg8=.7ba86b6f-3322-415c-9cc5-6c861680168b@github.com>

On Mon, 13 Feb 2023 17:53:46 GMT, Andriy Plokhotnyuk <duke at openjdk.org> wrote:

>> This PR is waiting for a review
>
> @rgiulietti Thanks for keeping making JDK faster!
> 
> I have a couple of review comments:
> 
> #### 1) For the line https://github.com/openjdk/jdk/pull/9410/files#diff-94d400b99466045dd76001c37eada6b24d086d8d115b49c439752bbceb233772L3746
> 
> It seems that removing this check for 22-bit number introduces an extra rounding error.
> 
> Please consider just increasing the constant up to `1L << 32` and using `DOUBLE_10_POW` instead of `FLOAT_10_POW`.
> 
> Bellow are REPL expressions that illustrate my thoughts (sorry for using Scala):
> 
> $ scala
> Welcome to Scala 3.2.0 (17.0.5, Java OpenJDK 64-Bit Server VM).
> Type in expressions for evaluation. Or try :help.
>                                                                                                                                                                                                                    
> scala> new java.math.BigDecimal("167772170E-1").floatValue
> val res0: Float = 1.6777216E7
>                                                                                                                                                                                                                    
> scala> 167772170E-1f
> val res1: Float = 1.6777216E7
>                                                                                                                                                                                                                    
> scala> 167772170 / 10.0f
> val res2: Float = 1.6777218E7
> 
> scala> (167772170 / 10.0).toFloat
> val res3: Float = 1.6777216E7
> 
> #### 2) For the line: https://github.com/openjdk/jdk/pull/9410/files#diff-94d400b99466045dd76001c37eada6b24d086d8d115b49c439752bbceb233772L3791
> 
> It seems that removing this check for 52-bit number introduces an extra rounding error:
> 
> $ scala
> Welcome to Scala 3.2.0 (17.0.6, Java OpenJDK 64-Bit Server VM).
> Type in expressions for evaluation. Or try :help.
> 
> scala> new java.math.BigDecimal("90071992547409930E-1").doubleValue
> val res0: Double = 9.007199254740992E15
>                                                                                                                                                                                                                    
> scala> 90071992547409930E-1
> val res1: Double = 9.007199254740992E15
>                                                                                                                                                                                                                    
> scala> 90071992547409930L / 10.0
> val res2: Double = 9.007199254740994E15
> 
> #### 3) For the line: https://github.com/openjdk/jdk/pull/9410/files#diff-94d400b99466045dd76001c37eada6b24d086d8d115b49c439752bbceb233772L3800
> Here before falling back to the costly fallback with big number operations we can [get a number of digits in intCompact](https://github.com/plokhotnyuk/jsoniter-scala/blob/6f702ce5cae05df91b5aa6e4bd61acdf43bf18f6/jsoniter-scala-core/jvm/src/main/scala/com/github/plokhotnyuk/jsoniter_scala/core/JsonWriter.scala#L1930) and use [a trick with two multiplications](https://github.com/plokhotnyuk/jsoniter-scala/blob/6f702ce5cae05df91b5aa6e4bd61acdf43bf18f6/jsoniter-scala-core/jvm/src/main/scala/com/github/plokhotnyuk/jsoniter_scala/core/JsonReader.scala#L1459)

@plokhotnyuk 

The expression `new java.math.BigDecimal("90071992547409930E-1").doubleValue()` would be processed by the proposed code as follows.

We have:
`intCompact = 90071992547409930L`
`scale = 1`

L.3838 sets `v == 9.007199254740994E16`
The test `(long) v == intCompact` on L. 3848 fails, so the fast path is not executed.
The slow path then ensures that the conversion is affected by at most one rounding error.

On the other hand, the expression
`scala> 90071992547409930L / 10.0`
is subject to two rounding errors, but it i executed neither by the current nor by the proposed code.

A similar analysis holds for the `float` example.

As for the last paragraph, I'll have to have a deeper look. Stay tuned ;-)

-------------

PR: https://git.openjdk.org/jdk/pull/9410

From psandoz at openjdk.org  Mon Feb 13 20:35:27 2023
From: psandoz at openjdk.org (Paul Sandoz)
Date: Mon, 13 Feb 2023 20:35:27 GMT
Subject: RFR: 8302260: VarHandle.describeConstable() fails to return a
 nominal descriptor for static public fields
In-Reply-To: <fPx38HtLOHB5dvr9_Z2wFKYKLNsjFIIwExNreo3pHxw=.53c3792d-db7b-42d6-b858-5c3062a57a4f@github.com>
References: <fPx38HtLOHB5dvr9_Z2wFKYKLNsjFIIwExNreo3pHxw=.53c3792d-db7b-42d6-b858-5c3062a57a4f@github.com>
Message-ID: <KWaqUQgV12d_U4SL25pHgIClM2HIngUrSnG2Hxs1-yE=.7d8eab5f-7f28-43b7-a20b-e0d6d8c9f1f8@github.com>

On Mon, 13 Feb 2023 19:35:52 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> I overlooked in the fix for JDK-8297757 that it should have passed the declaring class of the static fields rather than the reference class passed to `Lookup::findStaticVarHandle`.

Doh! I think the previous fix may have also result in an InternalError in some cases? since the field may not be found from the declaring class in `VarHandles::getStaticFieldFromBaseAndOffset`?

-------------

PR: https://git.openjdk.org/jdk/pull/12543

From lancea at openjdk.org  Mon Feb 13 21:25:38 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Mon, 13 Feb 2023 21:25:38 GMT
Subject: RFR: 8301873: Avoid string decoding in ZipFile.Source.getEntryPos
 [v9]
In-Reply-To: <p2-revzHDap8mmK22cZnmfocoxjzMZgOWsQX2p8iLYo=.2f9cfa42-46ca-4527-9b4a-103dd06fcdc3@github.com>
References: <FkmdspiHVjkAKFqm5kUgwaf55YH5cBbczS_3krqsdFs=.05eca901-f55f-47d9-b1bc-0cf2f5b87536@github.com>
 <p2-revzHDap8mmK22cZnmfocoxjzMZgOWsQX2p8iLYo=.2f9cfa42-46ca-4527-9b4a-103dd06fcdc3@github.com>
Message-ID: <3fZ6eVyW0fQ2QLZhOG5PyO5nBQ0CqlWt1p41Y2Xtjd4=.2acab1ed-7086-4030-869f-b324b640ea77@github.com>

On Thu, 9 Feb 2023 12:07:04 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

>> After finding a hash match, getEntryPos needs to compare the lookup name up to the encoded entry name in the CEN. This comparison is done by decoding the entry name into a String. The names can then be compared using the String API. This decoding step adds a significat cost to this method.
>> 
>> This PR suggest to update the string comparison such that in the common case where  both the lookup name and the entry name are encoded in ASCII-compatible UTF-8,  decoding can be avoided and the byte arrays can instead be compared direcly. 
>> 
>> ZipCoder is updated with a new method to compare a string with an encoded byte array range.  The default implementation decodes to string (like the current code), while the UTF-8 implementation uses JavaLangAccess.getBytesNoRepl to get the  bytes. Both methods thes uses Arrays.mismatch for comparison with or without matching trailing slashes. 
>> 
>> Additionally, this PR suggest to make the following updates to getEntryPos:
>> 
>> - The try/catch for IAE is redundant and can be safely removed. (initCEN already checks this and will throws IAE for invalid UTF-8). This seems to give a 3-4% speedup on micros)
>> - A new test InvalidBytesInEntryNameOrComment is a added to verify that initCEN does in fact reject invalid UTF-8 in CEN file names and comments. (I found no existing test coverage for this)
>> - The recursion when looking for "name/" matches is replaced with iteration. We keep track of any "name/" match and return it at the end of the search. (I feel this is easier to follow and it also gives a ~30% speedup for addSlash lookups with no regression on regular lookups)
>> 
>> (My though is that including these additional updates in this PR might reduce reviewer overhead given that it touches the exact same code. I might be wrong on this, please advise :)
>> 
>> I'm seeing a ~17% saving on the micro ZipFileGetEntry.getEntryHit (modified to use xalan.jar):
>> 
>> Baseline:
>> 
>> Benchmark                             (size)  Mode  Cnt    Score   Error  Units
>> ZipFileGetEntry.getEntryHit              512  avgt   15   74.941 ? 1.004  ns/op
>> ZipFileGetEntry.getEntryHit             1024  avgt   15   84.943 ? 1.320  ns/op
>> ZipFileGetEntry.getEntryHitUncached      512  avgt   15  120.371 ? 2.386  ns/op
>> ZipFileGetEntry.getEntryHitUncached     1024  avgt   15  126.128 ? 1.075  ns/op
>> ZipFileGetEntry.getEntryMiss             512  avgt   15   23.818 ? 0.838  ns/op
>> ZipFileGetEntry.getEntryMiss            1024  avgt   15   29.762 ? 5.998  ns/op
>> ZipFileGetEntry.getEntryMissUncached     512  avgt   15   59.405 ? 0.545  ns/op
>> ZipFileGetEntry.getEntryMissUncached    1024  avgt   15   71.840 ? 2.455  ns/op
>> ZipFileGetEntry.getEntrySlash            512  avgt   15  135.621 ? 4.341  ns/op
>> ZipFileGetEntry.getEntrySlash           1024  avgt   15  134.190 ? 2.141  ns/op
>> 
>> 
>> 
>> PR:
>> 
>> 
>> Benchmark                             (size)  Mode  Cnt    Score   Error  Units
>> ZipFileGetEntry.getEntryHit              512  avgt   15   62.267 ? 1.329  ns/op
>> ZipFileGetEntry.getEntryHit             1024  avgt   15   72.916 ? 2.428  ns/op
>> ZipFileGetEntry.getEntryHitUncached      512  avgt   15  101.630 ? 1.154  ns/op
>> ZipFileGetEntry.getEntryHitUncached     1024  avgt   15  113.161 ? 0.502  ns/op
>> ZipFileGetEntry.getEntryMiss             512  avgt   15   23.003 ? 1.191  ns/op
>> ZipFileGetEntry.getEntryMiss            1024  avgt   15   23.236 ? 1.114  ns/op
>> ZipFileGetEntry.getEntryMissUncached     512  avgt   15   56.781 ? 1.505  ns/op
>> ZipFileGetEntry.getEntryMissUncached    1024  avgt   15   67.767 ? 1.963  ns/op
>> ZipFileGetEntry.getEntrySlash            512  avgt   15   73.745 ? 2.717  ns/op
>> ZipFileGetEntry.getEntrySlash           1024  avgt   15   75.784 ? 1.051  ns/op
>> 
>> 
>> To assess the impact on startup/warmup, I made a main method class which measures the total time of calling ZipFile.getEntry for all entries in the 109 JAR file dependenies of spring-petclinic. The shows a nice improvement (time in micros):
>> 
>> 
>> Percentile Baseline Patch
>> 50?%          23155 21149
>> 75?%          23598 21454
>> 90?%          23989 21691
>> 95?%          24238 21973
>> 99?%          25270 22446
>> STDEV           792   549
>> Count           500   500
>
> Eirik Bjorsnos has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert accidental removal of UTF8ZipCoder.compare

Thank you Eirik for your efforts here.  I am running your latest changes through our internal Mach5 systems.

Additional comments below which are meant to add clarity for future maintainers

src/java.base/share/classes/java/util/zip/ZipCoder.java line 66:

> 64:         NO_MATCH
> 65:     }
> 66: 

Please add a comment indicating what the values mean

src/java.base/share/classes/java/util/zip/ZipCoder.java line 210:

> 208:      * is known and matches the charset of this ZipCoder.
> 209:      */
> 210:     Comparison compare(String str, byte[] b, int off, int len, boolean addSlash) {

If you could add an `@param` comments, that would be awesome ?

src/java.base/share/classes/java/util/zip/ZipFile.java line 1665:

> 1663:             }
> 1664:             // No exact match found, will return either slashMatch or -1
> 1665:             return slashMatch;

This gets a bit confusing as we return `pos` when we have an exact match so it would be helpful to had more clarity via additional comments(it might not have been clear with the previous comments but I think if we are going to add `slashMatch` we should take the time to beef up the comments

test/jdk/java/util/zip/ZipFile/InvalidBytesInEntryNameOrComment.java line 90:

> 88:             expectedExceptionsMessageRegExp = BAD_ENTRY_NAME_OR_COMMENT)
> 89:     public void shouldRejectInvalidName() throws IOException {
> 90:         try (ZipFile zf = new ZipFile(invalidName.toFile())) {

If you could please convert to use `expectThrows` to get to validate the message name

test/jdk/java/util/zip/ZipFile/TestZipFileEncodings.java line 127:

> 125:     }
> 126: 
> 127:     @Test

Please add a comment introducing the test

test/jdk/java/util/zip/ZipFile/TestZipFileEncodings.java line 143:

> 141:         }
> 142:     }
> 143:     @Test(dataProvider = "all-charsets")

Please add a comment introducing the test

test/jdk/java/util/zip/ZipFile/TestZipFileEncodings.java line 307:

> 305:                 ze.setCrc(crc.getValue());
> 306:             }
> 307:             ze.setTime(1675862371399L);

Please add a comment indicating what the time is

-------------

PR: https://git.openjdk.org/jdk/pull/12290

From mchung at openjdk.org  Mon Feb 13 21:42:26 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Mon, 13 Feb 2023 21:42:26 GMT
Subject: RFR: 8302260: VarHandle.describeConstable() fails to return a
 nominal descriptor for static public fields
In-Reply-To: <fPx38HtLOHB5dvr9_Z2wFKYKLNsjFIIwExNreo3pHxw=.53c3792d-db7b-42d6-b858-5c3062a57a4f@github.com>
References: <fPx38HtLOHB5dvr9_Z2wFKYKLNsjFIIwExNreo3pHxw=.53c3792d-db7b-42d6-b858-5c3062a57a4f@github.com>
Message-ID: <ONuxPJUx6IkMxoK5fSkKsjFiGE_R-27Va7Va9Xxl5QQ=.4dfea640-e093-41a0-910b-bf9b7571d94c@github.com>

On Mon, 13 Feb 2023 19:35:52 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> I overlooked in the fix for JDK-8297757 that it should have passed the declaring class of the static fields rather than the reference class passed to `Lookup::findStaticVarHandle`.

`InternalError` is thrown if the field is not found as it's not declared in `refc`.  Or if the field is declared in the superclass or superinterface and just happens to find a field at the same offset in `refc`, a wrong `VarHandleDesc` is produced.

-------------

PR: https://git.openjdk.org/jdk/pull/12543

From mchung at openjdk.org  Mon Feb 13 22:12:04 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Mon, 13 Feb 2023 22:12:04 GMT
Subject: RFR: JDK-8301460: Clean up LambdaForm to reference BasicType enums
 directly
Message-ID: <yoiVWrNeX6OjlT-iQjAo6SoQWCZi-gcPlWUjK8YZoqc=.61908404-3f28-45cb-a351-aa315924b6c3@github.com>

`LambdaForm` declares int constants for `BasicType::ordinal` to workaround JDK-8161245.   Now these int constants are no longer needed.    This removes these int constants and reference `BasicType` enums directly.

-------------

Commit messages:
 - JDK-8301460: Code in LambdaForm.java still refers to resolved JDK-8161245

Changes: https://git.openjdk.org/jdk/pull/12546/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12546&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8301460
  Stats: 29 lines in 3 files changed: 9 ins; 10 del; 10 mod
  Patch: https://git.openjdk.org/jdk/pull/12546.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12546/head:pull/12546

PR: https://git.openjdk.org/jdk/pull/12546

From darcy at openjdk.org  Mon Feb 13 22:18:10 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Mon, 13 Feb 2023 22:18:10 GMT
Subject: RFR: JDK-8302026: Port fdlibm inverse trig functions (asin, acos,
 atan) to Java
Message-ID: <4gBqg3J25LASN6tnRwZ22S3YlUHQrypgvZqynfKd3Os=.3a5e618f-b7eb-4978-a6ab-f1b30c793fb4@github.com>

Proceeding down the line of FDLIBM functions to be ported, next up are asin, acos, and atan.

Diffs of the various versions will follow in a separate message.

There were no unusual coding idioms encountered in porting these methods.

-------------

Commit messages:
 - Appease jcheck.
 - Add regression test.
 - Switch to hex literals, misc. updates.
 - Update exhausting tests.
 - Merge branch 'master' into JDK-8302026
 - Reformat test.
 - Merge branch 'master' into JDK-8302026
 - JDK-8302026: Port fdlibm inverse trig functions (asin, acos, atan) to Java

Changes: https://git.openjdk.org/jdk/pull/12545/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12545&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8302026
  Stats: 1041 lines in 6 files changed: 1034 ins; 0 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/12545.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12545/head:pull/12545

PR: https://git.openjdk.org/jdk/pull/12545

From darcy at openjdk.org  Mon Feb 13 22:18:11 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Mon, 13 Feb 2023 22:18:11 GMT
Subject: RFR: JDK-8302026: Port fdlibm inverse trig functions (asin, acos, 
 atan) to Java
In-Reply-To: <4gBqg3J25LASN6tnRwZ22S3YlUHQrypgvZqynfKd3Os=.3a5e618f-b7eb-4978-a6ab-f1b30c793fb4@github.com>
References: <4gBqg3J25LASN6tnRwZ22S3YlUHQrypgvZqynfKd3Os=.3a5e618f-b7eb-4978-a6ab-f1b30c793fb4@github.com>
Message-ID: <kBROddBYXkl9S6kGoK8AYgWmsls5n9R_gyEmvY1fsTs=.733644b4-3a1d-43ae-bab8-5f06e5ad2ee5@github.com>

On Mon, 13 Feb 2023 22:03:14 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Proceeding down the line of FDLIBM functions to be ported, next up are asin, acos, and atan.
> 
> Diffs of the various versions will follow in a separate message.
> 
> There were no unusual coding idioms encountered in porting these methods.

Original C vs transliteration port:


$ diff -w InverseTrig.c  InverseTrig.translit.java  
1c1,2
< /* __ieee754_asin(x)
---
>     /** Returns the arcsine of x.
>      *
30,38c31,32
< 
< 
< #include "fdlibm.h"
< 
< #ifdef __STDC__
< static const double
< #else
< static double
< #endif
---
>     static class Asin {
>         private static final double
56,62c50
< #ifdef __STDC__
<         double __ieee754_asin(double x)
< #else
<         double __ieee754_asin(x)
<         double x;
< #endif
< {
---
>         static double compute(double x) {
83c71
<         w = one-fabs(x);
---
>             w = one-Math.abs(x);
87c75
<         s = sqrt(t);
---
>             s = Math.sqrt(t);
93c81,82
<             __LO(w) = 0;
---
>                 // __LO(w) = 0;
>                 w  = __LO(w, 0);
102c91,93
< /* __ieee754_acos(x)
---
>     }
> 
>     /** Returns the arccosine of x.
125,132c116,117
< 
< #include "fdlibm.h"
< 
< #ifdef __STDC__
< static const double
< #else
< static double
< #endif
---
>     static class Acos {
>         private static final double
148,154c133
< #ifdef __STDC__
<         double __ieee754_acos(double x)
< #else
<         double __ieee754_acos(x)
<         double x;
< #endif
< {
---
>         static double compute(double x) {
177c156
<             s = sqrt(z);
---
>                 s = Math.sqrt(z);
183c162
<             s = sqrt(z);
---
>                 s = Math.sqrt(z);
185c164,165
<             __LO(df) = 0;
---
>                 // __LO(df) = 0;
>                 df = __LO(df, 0);
194c174,176
< /* atan(x)
---
>     }
> 
>     /* Returns the arctangent of x.
213,220c195,196
< 
< #include "fdlibm.h"
< 
< #ifdef __STDC__
< static const double atanhi[] = {
< #else
< static double atanhi[] = {
< #endif
---
>     static class Atan {
>         private static final double atanhi[] = {
227,231c203
< #ifdef __STDC__
< static const double atanlo[] = {
< #else
< static double atanlo[] = {
< #endif
---
>         private static final double atanlo[] = {
238,242c210
< #ifdef __STDC__
< static const double aT[] = {
< #else
< static double aT[] = {
< #endif
---
>         private static final double aT[] = {
256,260c224
< #ifdef __STDC__
<         static const double
< #else
<         static double
< #endif
---
>         private static final double
264,270c228
< #ifdef __STDC__
<         double atan(double x)
< #else
<         double atan(x)
<         double x;
< #endif
< {
---
>         static double compute(double x) {
288c246
<         x = fabs(x);
---
>                 x = Math.abs(x);
313a272
>     }


Transliteration port vs more idiomatic port:


$ diff -w  InverseTrig.translit.java  InverseTrig.fdlibm.java 
31a32,33
>         private Asin() {throw new UnsupportedOperationException();}
> 
33,48c35,48
<             one =  1.00000000000000000000e+00, /* 0x3FF00000, 0x00000000 */
<             huge =  1.000e+300,
<             pio2_hi =  1.57079632679489655800e+00, /* 0x3FF921FB, 0x54442D18 */
<             pio2_lo =  6.12323399573676603587e-17, /* 0x3C91A626, 0x33145C07 */
<             pio4_hi =  7.85398163397448278999e-01, /* 0x3FE921FB, 0x54442D18 */
<         /* coefficient for R(x^2) */
<             pS0 =  1.66666666666666657415e-01, /* 0x3FC55555, 0x55555555 */
<             pS1 = -3.25565818622400915405e-01, /* 0xBFD4D612, 0x03EB6F7D */
<             pS2 =  2.01212532134862925881e-01, /* 0x3FC9C155, 0x0E884455 */
<             pS3 = -4.00555345006794114027e-02, /* 0xBFA48228, 0xB5688F3B */
<             pS4 =  7.91534994289814532176e-04, /* 0x3F49EFE0, 0x7501B288 */
<             pS5 =  3.47933107596021167570e-05, /* 0x3F023DE1, 0x0DFDF709 */
<             qS1 = -2.40339491173441421878e+00, /* 0xC0033A27, 0x1C8A2D4B */
<             qS2 =  2.02094576023350569471e+00, /* 0x40002AE5, 0x9C598AC8 */
<             qS3 = -6.88283971605453293030e-01, /* 0xBFE6066C, 0x1B8D0159 */
<             qS4 =  7.70381505559019352791e-02; /* 0x3FB3B8C5, 0xB12E9282 */
---
>             pio2_hi = 0x1.921fb54442d18p0,   //  1.57079632679489655800e+00
>             pio2_lo = 0x1.1a62633145c07p-54, //  6.12323399573676603587e-17
>             pio4_hi = 0x1.921fb54442d18p-1,  //  7.85398163397448278999e-01
>         // coefficient for R(x^2)
>             pS0 =  0x1.5555555555555p-3,     //  1.66666666666666657415e-01
>             pS1 = -0x1.4d61203eb6f7dp-2,     // -3.25565818622400915405e-01
>             pS2 =  0x1.9c1550e884455p-3,     //  2.01212532134862925881e-01
>             pS3 = -0x1.48228b5688f3bp-5,     // -4.00555345006794114027e-02
>             pS4 =  0x1.9efe07501b288p-11,    //  7.91534994289814532176e-04
>             pS5 =  0x1.23de10dfdf709p-15,    //  3.47933107596021167570e-05
>             qS1 = -0x1.33a271c8a2d4bp1,      // -2.40339491173441421878e+00
>             qS2 =  0x1.02ae59c598ac8p1,      //  2.02094576023350569471e+00
>             qS3 = -0x1.6066c1b8d0159p-1,     // -6.88283971605453293030e-01
>             qS4 =  0x1.3b8c5b12e9282p-4;     //  7.70381505559019352791e-02
54,57c54,57
<             ix = hx&0x7fffffff;
<             if(ix>= 0x3ff00000) {           /* |x|>= 1 */
<                 if(((ix-0x3ff00000)|__LO(x))==0)
<                     /* asin(1)=+-pi/2 with inexact */
---
>             ix = hx & 0x7fff_ffff;
>             if (ix >= 0x3ff0_0000) {           // |x| >= 1
>                 if(((ix - 0x3ff0_0000) | __LO(x)) == 0) {
>                     // asin(1) = +-pi/2 with inexact
59,63c59,66
<                 return (x-x)/(x-x);         /* asin(|x|>1) is NaN */
<             } else if (ix<0x3fe00000) {     /* |x|<0.5 */
<                 if(ix<0x3e400000) {         /* if |x| < 2**-27 */
<                     if(huge+x>one) return x;/* return x with inexact if x!=0*/
<                 } else
---
>                 }
>                 return (x - x)/(x - x);         // asin(|x| > 1) is NaN
>             } else if (ix < 0x3fe0_0000) {     // |x| < 0.5
>                 if (ix < 0x3e40_0000) {        // if |x| < 2**-27
>                     if (HUGE + x > 1.0) {// return x with inexact if x != 0
>                         return x;
>                     }
>                 } else {
64a68
>                 }
66c70
<                 q = one+t*(qS1+t*(qS2+t*(qS3+t*qS4)));
---
>                 q = 1.0 + t*(qS1 + t*(qS2 + t*(qS3 + t*qS4)));
70,71c74,75
<             /* 1> |x|>= 0.5 */
<             w = one-Math.abs(x);
---
>             // 1 > |x| >= 0.5
>             w = 1.0 - Math.abs(x);
74c78
<             q = one+t*(qS1+t*(qS2+t*(qS3+t*qS4)));
---
>             q = 1.0 + t*(qS1 + t*(qS2 + t*(qS3 + t*qS4)));
76c80
<             if(ix>=0x3FEF3333) {    /* if |x| > 0.975 */
---
>             if (ix >= 0x3FEF_3333) {    // if |x| > 0.975
81d84
<                 // __LO(w) = 0;
89c92
<             if(hx>0) return t; else return -t;
---
>             return (hx > 0) ? t : -t;
116a120,121
>         private Acos() {throw new UnsupportedOperationException();}
> 
118,131c123,134
<             one=  1.00000000000000000000e+00, /* 0x3FF00000, 0x00000000 */
<             pi =  3.14159265358979311600e+00, /* 0x400921FB, 0x54442D18 */
<             pio2_hi =  1.57079632679489655800e+00, /* 0x3FF921FB, 0x54442D18 */
<             pio2_lo =  6.12323399573676603587e-17, /* 0x3C91A626, 0x33145C07 */
<             pS0 =  1.66666666666666657415e-01, /* 0x3FC55555, 0x55555555 */
<             pS1 = -3.25565818622400915405e-01, /* 0xBFD4D612, 0x03EB6F7D */
<             pS2 =  2.01212532134862925881e-01, /* 0x3FC9C155, 0x0E884455 */
<             pS3 = -4.00555345006794114027e-02, /* 0xBFA48228, 0xB5688F3B */
<             pS4 =  7.91534994289814532176e-04, /* 0x3F49EFE0, 0x7501B288 */
<             pS5 =  3.47933107596021167570e-05, /* 0x3F023DE1, 0x0DFDF709 */
<             qS1 = -2.40339491173441421878e+00, /* 0xC0033A27, 0x1C8A2D4B */
<             qS2 =  2.02094576023350569471e+00, /* 0x40002AE5, 0x9C598AC8 */
<             qS3 = -6.88283971605453293030e-01, /* 0xBFE6066C, 0x1B8D0159 */
<             qS4 =  7.70381505559019352791e-02; /* 0x3FB3B8C5, 0xB12E9282 */
---
>             pio2_hi =  0x1.921fb54442d18p0,   //  1.57079632679489655800e+00
>             pio2_lo =  0x1.1a62633145c07p-54, //  6.12323399573676603587e-17
>             pS0     =  0x1.5555555555555p-3,  //  1.66666666666666657415e-01
>             pS1     = -0x1.4d61203eb6f7dp-2,  // -3.25565818622400915405e-01
>             pS2     =  0x1.9c1550e884455p-3,  //  2.01212532134862925881e-01
>             pS3     = -0x1.48228b5688f3bp-5,  // -4.00555345006794114027e-02
>             pS4     =  0x1.9efe07501b288p-11, //  7.91534994289814532176e-04
>             pS5     =  0x1.23de10dfdf709p-15, //  3.47933107596021167570e-05
>             qS1     = -0x1.33a271c8a2d4bp1,   // -2.40339491173441421878e+00
>             qS2     =  0x1.02ae59c598ac8p1,   //  2.02094576023350569471e+00
>             qS3     = -0x1.6066c1b8d0159p-1,  // -6.88283971605453293030e-01
>             qS4     =  0x1.3b8c5b12e9282p-4;  //  7.70381505559019352791e-02
137,141c140,147
<             ix = hx&0x7fffffff;
<             if(ix>=0x3ff00000) {    /* |x| >= 1 */
<                 if(((ix-0x3ff00000)|__LO(x))==0) {  /* |x|==1 */
<                     if(hx>0) return 0.0;            /* acos(1) = 0  */
<                     else return pi+2.0*pio2_lo;     /* acos(-1)= pi */
---
>             ix = hx & 0x7fff_ffff;
>             if (ix >= 0x3ff0_0000) {    // |x| >= 1
>                 if (((ix - 0x3ff0_0000) | __LO(x)) == 0) {  // |x| == 1
>                     if (hx > 0) {// acos(1) = 0
>                         return 0.0;
>                     }else {       // acos(-1)= pi
>                         return Math.PI + 2.0*pio2_lo;
>                     }
143c149,153
<                 return (x-x)/(x-x);         /* acos(|x|>1) is NaN */
---
>                 return (x-x)/(x-x);         // acos(|x| > 1) is NaN
>             }
>             if (ix < 0x3fe0_0000) {     // |x| < 0.5
>                 if (ix <= 0x3c60_0000) {  // if |x| < 2**-57
>                     return pio2_hi + pio2_lo;
145,146d154
<             if(ix<0x3fe00000) {     /* |x| < 0.5 */
<                 if(ix<=0x3c600000) return pio2_hi+pio2_lo;/*if|x|<2**-57*/
149c157
<                 q = one+z*(qS1+z*(qS2+z*(qS3+z*qS4)));
---
>                 q = 1.0 + z*(qS1 + z*(qS2 + z*(qS3 + z*qS4)));
152,153c160,161
<             } else  if (hx<0) {             /* x < -0.5 */
<                 z = (one+x)*0.5;
---
>             } else if (hx < 0) {             // x < -0.5
>                 z = (1.0 + x)*0.5;
155c163
<                 q = one+z*(qS1+z*(qS2+z*(qS3+z*qS4)));
---
>                 q = 1.0 + z*(qS1 + z*(qS2 + z*(qS3 + z*qS4)));
159,161c167,169
<                 return pi - 2.0*(s+w);
<             } else {                        /* x > 0.5 */
<                 z = (one-x)*0.5;
---
>                 return Math.PI - 2.0*(s+w);
>             } else {                        // x > 0.5
>                 z = (1.0 - x)*0.5;
164d171
<                 // __LO(df) = 0;
168c175
<                 q = one+z*(qS1+z*(qS2+z*(qS3+z*qS4)));
---
>                 q = 1.0 + z*(qS1 + z*(qS2 + z*(qS3 + z*qS4)));
195a203,204
>         private Atan() {throw new UnsupportedOperationException();}
> 
197,200c206,209
<             4.63647609000806093515e-01, /* atan(0.5)hi 0x3FDDAC67, 0x0561BB4F */
<             7.85398163397448278999e-01, /* atan(1.0)hi 0x3FE921FB, 0x54442D18 */
<             9.82793723247329054082e-01, /* atan(1.5)hi 0x3FEF730B, 0xD281F69B */
<             1.57079632679489655800e+00, /* atan(inf)hi 0x3FF921FB, 0x54442D18 */
---
>             0x1.dac670561bb4fp-2,  // atan(0.5)hi 4.63647609000806093515e-01
>             0x1.921fb54442d18p-1,  // atan(1.0)hi 7.85398163397448278999e-01
>             0x1.f730bd281f69bp-1,  // atan(1.5)hi 9.82793723247329054082e-01
>             0x1.921fb54442d18p0,   // atan(inf)hi 1.57079632679489655800e+00
204,207c213,216
<             2.26987774529616870924e-17, /* atan(0.5)lo 0x3C7A2B7F, 0x222F65E2 */
<             3.06161699786838301793e-17, /* atan(1.0)lo 0x3C81A626, 0x33145C07 */
<             1.39033110312309984516e-17, /* atan(1.5)lo 0x3C700788, 0x7AF0CBBD */
<             6.12323399573676603587e-17, /* atan(inf)lo 0x3C91A626, 0x33145C07 */
---
>             0x1.a2b7f222f65e2p-56, // atan(0.5)lo 2.26987774529616870924e-17
>             0x1.1a62633145c07p-55, // atan(1.0)lo 3.06161699786838301793e-17
>             0x1.007887af0cbbdp-56, // atan(1.5)lo 1.39033110312309984516e-17
>             0x1.1a62633145c07p-54, // atan(inf)lo 6.12323399573676603587e-17
211,221c220,230
<              3.33333333333329318027e-01, /* 0x3FD55555, 0x5555550D */
<             -1.99999999998764832476e-01, /* 0xBFC99999, 0x9998EBC4 */
<              1.42857142725034663711e-01, /* 0x3FC24924, 0x920083FF */
<             -1.11111104054623557880e-01, /* 0xBFBC71C6, 0xFE231671 */
<              9.09088713343650656196e-02, /* 0x3FB745CD, 0xC54C206E */
<             -7.69187620504482999495e-02, /* 0xBFB3B0F2, 0xAF749A6D */
<              6.66107313738753120669e-02, /* 0x3FB10D66, 0xA0D03D51 */
<             -5.83357013379057348645e-02, /* 0xBFADDE2D, 0x52DEFD9A */
<              4.97687799461593236017e-02, /* 0x3FA97B4B, 0x24760DEB */
<             -3.65315727442169155270e-02, /* 0xBFA2B444, 0x2C6A6C2F */
<              1.62858201153657823623e-02, /* 0x3F90AD3A, 0xE322DA11 */
---
>              0x1.555555555550dp-2, //  3.33333333333329318027e-01
>             -0x1.999999998ebc4p-3, // -1.99999999998764832476e-01
>              0x1.24924920083ffp-3, //  1.42857142725034663711e-01
>             -0x1.c71c6fe231671p-4, // -1.11111104054623557880e-01
>              0x1.745cdc54c206ep-4, //  9.09088713343650656196e-02
>             -0x1.3b0f2af749a6dp-4, // -7.69187620504482999495e-02
>              0x1.10d66a0d03d51p-4, //  6.66107313738753120669e-02
>             -0x1.dde2d52defd9ap-5, // -5.83357013379057348645e-02
>              0x1.97b4b24760debp-5, //  4.97687799461593236017e-02
>             -0x1.2b4442c6a6c2fp-5, // -3.65315727442169155270e-02
>              0x1.0ad3ae322da11p-6, //  1.62858201153657823623e-02
224,227d232
<         private static final double
<             one   = 1.0,
<             huge   = 1.0e300;
< 
233,242c238,253
<             ix = hx&0x7fffffff;
<             if(ix>=0x44100000) {    /* if |x| >= 2^66 */
<                 if(ix>0x7ff00000||
<                    (ix==0x7ff00000&&(__LO(x)!=0)))
<                     return x+x;             /* NaN */
<                 if(hx>0) return  atanhi[3]+atanlo[3];
<                 else     return -atanhi[3]-atanlo[3];
<             } if (ix < 0x3fdc0000) {        /* |x| < 0.4375 */
<                 if (ix < 0x3e200000) {      /* |x| < 2^-29 */
<                     if(huge+x>one) return x;        /* raise inexact */
---
>             ix = hx & 0x7fff_ffff;
>             if (ix >= 0x4410_0000) {    // if |x| >= 2^66
>                 if (ix > 0x7ff0_0000 ||
>                     (ix == 0x7ff0_0000 && (__LO(x) != 0))) {
>                     return x+x;             // NaN
>                 }
>                 if (hx > 0) {
>                     return atanhi[3] + atanlo[3];
>                 } else {
>                     return -atanhi[3] - atanlo[3];
>                 }
>             } if (ix < 0x3fdc_0000) {        // |x| < 0.4375
>                 if (ix < 0x3e20_0000) {      // |x| < 2^-29
>                     if (HUGE + x > 1.0) { // raise inexact
>                         return x;
>                     }
247,251c258,264
<                 if (ix < 0x3ff30000) {          /* |x| < 1.1875 */
<                     if (ix < 0x3fe60000) {      /* 7/16 <=|x|<11/16 */
<                         id = 0; x = (2.0*x-one)/(2.0+x);
<                     } else {                    /* 11/16<=|x|< 19/16 */
<                         id = 1; x  = (x-one)/(x+one);
---
>                 if (ix < 0x3ff3_0000) {         // |x| < 1.1875
>                     if (ix < 0x3fe60000) {      // 7/16 <= |x| < 11/16
>                         id = 0;
>                         x = (2.0*x - 1.0)/(2.0 + x);
>                     } else {                    // 11/16 <= |x| < 19/16
>                         id = 1;
>                         x  = (x - 1.0)/(x + 1.0);
254,257c267,273
<                     if (ix < 0x40038000) {      /* |x| < 2.4375 */
<                         id = 2; x  = (x-1.5)/(one+1.5*x);
<                     } else {                    /* 2.4375 <= |x| < 2^66 */
<                         id = 3; x  = -1.0/x;
---
>                     if (ix < 0x4003_8000) {      // |x| < 2.4375
>                         id = 2;
>                         x  = (x - 1.5)/(1.0 + 1.5*x);
>                     } else {                    // 2.4375 <= |x| < 2^66
>                         id = 3;
>                         x  = -1.0/x;
>                     }
259,260c275,276
<                 }}
<             /* end of argument reduction */
---
>             }
>             // end of argument reduction
263c279
<             /* break sum from i=0 to 10 aT[i]z**(i+1) into odd and even poly */
---
>             // break sum from i=0 to 10 aT[i]z**(i+1) into odd and even poly
266,267c282,284
<             if (id<0) return x - x*(s1+s2);
<             else {
---
>             if (id < 0) {
>                 return x - x*(s1 + s2);
>             } else {

-------------

PR: https://git.openjdk.org/jdk/pull/12545

From darcy at openjdk.org  Mon Feb 13 22:21:27 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Mon, 13 Feb 2023 22:21:27 GMT
Subject: RFR: JDK-8302026: Port fdlibm inverse trig functions (asin, acos, 
 atan) to Java
In-Reply-To: <4gBqg3J25LASN6tnRwZ22S3YlUHQrypgvZqynfKd3Os=.3a5e618f-b7eb-4978-a6ab-f1b30c793fb4@github.com>
References: <4gBqg3J25LASN6tnRwZ22S3YlUHQrypgvZqynfKd3Os=.3a5e618f-b7eb-4978-a6ab-f1b30c793fb4@github.com>
Message-ID: <sNEmOd3Zm20OrFyIq8OZeTvEw2uLuVtLmi_vSKOhtW8=.90ac7f43-70e1-49d0-9445-70af463fb1dc@github.com>

On Mon, 13 Feb 2023 22:03:14 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Proceeding down the line of FDLIBM functions to be ported, next up are asin, acos, and atan.
> 
> Diffs of the various versions will follow in a separate message.
> 
> There were no unusual coding idioms encountered in porting these methods.

> Proceeding down the line of FDLIBM functions to be ported, next up are asin, acos, and atan.
> 
> Diffs of the various versions will follow in a separate message.
> 
> There were no unusual coding idioms encountered in porting these methods.
> ### Progress
> 
>     * [ ]  Change must be properly reviewed (1 review required, with at least 1 [Reviewer](https://openjdk.org/bylaws#reviewer))
> 
>     * [x]  Change must not contain extraneous whitespace
> 
>     * [x]  Commit message must refer to an issue
> 
> 
> ### Issue
> 
>     * [JDK-8302026](https://bugs.openjdk.org/browse/JDK-8302026): Port fdlibm inverse trig functions (asin, acos, atan) to Java
> 
> 
> ### Reviewing
> Using `git`
> Using Skara CLI tools
> Using diff file

PS In one-off local testing, testing all float arguments for acos/asin/atan passed when run against both JDK 20 and JDK 21, increasing confidence that both the transliteration port is equivalent to the original C code and that the idiomatic port is equivalent to the transliteration one.

-------------

PR: https://git.openjdk.org/jdk/pull/12545

From darcy at openjdk.org  Mon Feb 13 22:48:31 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Mon, 13 Feb 2023 22:48:31 GMT
Subject: RFR: 8301226: Add clamp() methods to java.lang.Math and to
 StrictMath [v8]
In-Reply-To: <-RM6Jh13GZ4ZSt1qMwNp8Wb26qjGphOY89TaGenMzkM=.a04659cd-9f11-4af8-a53c-98d9ff837198@github.com>
References: <c7kJhZvT8oz5hScMxnWI23H7wjCaJ854ajjSRtxBnW4=.3f4e24ca-c608-4541-b80e-cf3452ec6400@github.com>
 <-RM6Jh13GZ4ZSt1qMwNp8Wb26qjGphOY89TaGenMzkM=.a04659cd-9f11-4af8-a53c-98d9ff837198@github.com>
Message-ID: <mYAaSKPJearx1P5CmrfnG74BdmsnUZZO_fy3Mbvn3kU=.8d23623f-4fb9-4598-ad03-b3090d71ed54@github.com>

On Tue, 7 Feb 2023 12:53:25 GMT, Tagir F. Valeev <tvaleev at openjdk.org> wrote:

>> clamp() methods added to Math and StrictMath
>> 
>> `int clamp(long, int, int)` is somewhat different, as it accepts a `long` value and safely clamps it to an `int` range. Other overloads work with a particular type (long, float and double). Using similar approach in other cases (e.g. `float clamp(double, float, float)`) may cause accidental precision loss even if the value is within range, so I decided to avoid this.
>> 
>> In all cases, `max >= min` precondition should met. For double and float we additionally order `-0.0 < 0.0`, similarly to what Math.max or Double.compare do. In double and float overloads I try to keep at most one arg-check comparison on common path, so the order of checks might look unusual.
>> 
>> For tests, I noticed that tests in java/lang/Math don't use any testing framework (even newer tests), so I somehow mimic the approach of neighbour tests.
>
> Tagir F. Valeev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Comments in tests

Marked as reviewed by darcy (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/12428

From rriggs at openjdk.org  Mon Feb 13 23:42:39 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 13 Feb 2023 23:42:39 GMT
Subject: RFR: 8301627: System.exit and Runtime.exit debug logging [v2]
In-Reply-To: <OzJeJH5yxolKPChcUisqtzGYF_MU3oOJdx6HPhsXjBw=.15eefe39-efe1-433e-a6ac-02b4a730f264@github.com>
References: <OzJeJH5yxolKPChcUisqtzGYF_MU3oOJdx6HPhsXjBw=.15eefe39-efe1-433e-a6ac-02b4a730f264@github.com>
Message-ID: <XbYJc8n5MDfxqtgGY0huFs8G5p7vHjXOv0kSTPAHUTE=.8ea97fd1-fede-4d2c-8fe3-0bef7a2132aa@github.com>

> It can be difficult to find the cause of calls to `java.lang.System.exit(status)` and `Runtime.exit(status)` because the Java runtime exits.
> The status value and stack trace are logged using the System Logger named `java.lang.Runtime` with message level `System.Logger.Level.DEBUG`.

Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:

  Added try/catch around lookup of logger so exceptions do not prevent System.exit.
  Added test case with console logger (when java.util.logging) not present.
  Removed @implNote tag its not appropriate in implementation javadoc.
  Still looking into when and where the log configuration should be described.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12517/files
  - new: https://git.openjdk.org/jdk/pull/12517/files/7f149916..76c4d61f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12517&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12517&range=00-01

  Stats: 26 lines in 2 files changed: 14 ins; 3 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/12517.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12517/head:pull/12517

PR: https://git.openjdk.org/jdk/pull/12517

From sviswanathan at openjdk.org  Tue Feb 14 02:00:58 2023
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Tue, 14 Feb 2023 02:00:58 GMT
Subject: RFR: JDK-8300808: Accelerate Base64 on x86 for AVX2 [v15]
In-Reply-To: <TmYLe9RCiAqtfuyjU77R-faEEVpfmmUoQ89oyBCcEmM=.c6d2d68b-c37d-4c78-a8e4-af4b48df91a5@github.com>
References: <9zN3bjyMEikXYOlpjTy9_QPc-9usYiBJMUFdb-TaVrQ=.e8f65ce9-ac0f-4f8d-9c6b-b39ae1c26cd2@github.com>
 <TmYLe9RCiAqtfuyjU77R-faEEVpfmmUoQ89oyBCcEmM=.c6d2d68b-c37d-4c78-a8e4-af4b48df91a5@github.com>
Message-ID: <4LXDemRbOxX-JiiDgh14WTZ9mc5VwbRLz4KjfxS29Cw=.9c16ea8e-dd1c-4aa3-a6f1-4736f3515edb@github.com>

On Thu, 9 Feb 2023 18:08:15 GMT, Scott Gibbons <sgibbons at openjdk.org> wrote:

>> Added code for Base64 acceleration (encode and decode) which will accelerate ~4x for AVX2 platforms.
>> 
>> Encode performance:
>> **Old:**
>> 
>> Benchmark                      (maxNumBytes)   Mode  Cnt     Score   Error   Units
>> Base64Encode.testBase64Encode           1024  thrpt    3  4309.439 ? 2.632  ops/ms
>> 
>> 
>> **New:**
>> 
>> Benchmark                      (maxNumBytes)   Mode  Cnt      Score     Error   Units
>> Base64Encode.testBase64Encode           1024  thrpt    3  24211.397 ? 102.026  ops/ms
>> 
>> 
>> Decode performance:
>> **Old:**
>> 
>> Benchmark                      (errorIndex)  (lineSize)  (maxNumBytes)   Mode  Cnt     Score    Error   Units
>> Base64Decode.testBase64Decode           144           4           1024  thrpt    3  3961.768 ? 93.409  ops/ms
>> 
>> **New:**
>> Benchmark                      (errorIndex)  (lineSize)  (maxNumBytes)   Mode  Cnt      Score    Error   Units
>> Base64Decode.testBase64Decode           144           4           1024  thrpt    3  14738.051 ? 24.383  ops/ms
>
> Scott Gibbons has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add URL to microbenchmark

src/hotspot/cpu/x86/stubGenerator_x86_64.cpp line 2399:

> 2397:      VM_Version::supports_avx512bw()) {
> 2398:     __ cmpl(length, 31);     // 32-bytes is break-even for AVX-512
> 2399:     __ jcc(Assembler::lessEqual, L_bruteForce);

The avx2 code needs the length to be atleast 0x2c (44) bytes. We could directly go to non-avx code instead of L_bruteForce here. We will save one subtract/branch.

src/hotspot/cpu/x86/stubGenerator_x86_64.cpp line 2658:

> 2656:     // Check for buffer too small (for algorithm)
> 2657:     __ subl(length, 0x2c);
> 2658:     __ jcc(Assembler::lessEqual, L_tailProc);

This could be Assembler::less instead of Assembler::lessEqual.

src/hotspot/cpu/x86/stubGenerator_x86_64.cpp line 2699:

> 2697:     __ addptr(dest, 0x18);
> 2698:     __ subl(length, 0x20);
> 2699:     __ jcc(Assembler::lessEqual, L_tailProc);

This could be Assembler::less instead of Assembler::lessEqual.

-------------

PR: https://git.openjdk.org/jdk/pull/12126

From duke at openjdk.org  Tue Feb 14 02:32:49 2023
From: duke at openjdk.org (Amit Kumar)
Date: Tue, 14 Feb 2023 02:32:49 GMT
Subject: RFR: 8299748: java/util/zip/Deinflate.java failing on s390x
In-Reply-To: <p1li8W4D2kYNZlxTOyvlqVrZWOjGbh6g1JfG6eHxAmE=.389b076c-0943-4cfd-af82-f24a56d1ac61@github.com>
References: <Usxi4wE5GSHHv-cKPfW6OXylhieAypbsidUX_Jo6FSQ=.34104cf0-2243-478f-86ce-9a91905c6755@github.com>
 <nN80i01pPGVl8QlQ09eEEEeFTz5z2hpM6udh2bNJwpU=.925ff5c6-586b-4262-bcd0-fd67d44cfde2@github.com>
 <jyL7HTlmcVxDKffdPqij6GNM0ePfzVxlypfy3hTtOAM=.3347a8dd-4722-4b79-b93e-b20892901c6b@github.com>
 <2eqxeIzcejWahzfAMe-czlbIQ96bV8s_RIkXQsXMtsY=.b329489c-40fc-4e91-9e30-10a3df53711e@github.com>
 <p1li8W4D2kYNZlxTOyvlqVrZWOjGbh6g1JfG6eHxAmE=.389b076c-0943-4cfd-af82-f24a56d1ac61@github.com>
Message-ID: <qtcABvAb_gSvo_WdBtKzCmOojRvOq-GB4z0oHcIZJJ4=.c0912c6f-c5b4-4b36-9c9b-153ea48d071f@github.com>

On Tue, 7 Feb 2023 07:07:54 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>>> Hi @AlanBateman ,
>>> with latest changes (doing inflate/deinflate) test passes over s390 and x86 as well. Please take a look now.
>> 
>> Good. One thing to try is to just deflate/inflate into out1/out2, no need for the intermediate BAOS, try this:
>> 
>> 
>> --- a/test/jdk/java/util/zip/DeInflate.java
>> +++ b/test/jdk/java/util/zip/DeInflate.java
>> @@ -1,5 +1,5 @@
>>  /*
>> - * Copyright (c) 2011, 2018, Oracle and/or its affiliates. All rights reserved.
>> + * Copyright (c) 2011, 2023, Oracle and/or its affiliates. All rights reserved.
>>   * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>>   *
>>   * This code is free software; you can redistribute it and/or modify it
>> @@ -127,11 +127,25 @@ public class DeInflate {
>>  
>>          def.setInput(in, 0, len);
>>          def.finish();
>> -        int m = def.deflate(out1);
>> +        int m = 0;
>> +        while (!def.finished()) {
>> +            int remaining = out1.length - m;
>> +            if (remaining == 0) {
>> +                throw new RuntimeException("out1 is small");
>> +            }
>> +            m += def.deflate(out1, m, remaining);
>> +        }
>>  
>>          Inflater inf = new Inflater(nowrap);
>>          inf.setInput(out1, 0, m);
>> -        int n = inf.inflate(out2);
>> +        int n = 0;
>> +        while (!inf.finished()) {
>> +            int remaining = out2.length - n;
>> +            if (remaining == 0) {
>> +                throw new RuntimeException("out2 is small");
>> +            }
>> +            n += inf.inflate(out2, n, remaining);
>> +        }
>>  
>>          if (n != len ||
>>              !Arrays.equals(Arrays.copyOf(in, len), Arrays.copyOf(out2, len)) ||
>
>> @AlanBateman should we proceed with the current changes then ?
> 
> The BAOS in your current proposal shouldn't be needed so I suspect there is something else "interesting" with this zlib implementation.  For the patch above, can you remove the checking for remaining == 0 and print out the value from deflate at each iterate of the loop. I'm wondering if it returns 0 before def.finished() returns true.

Hi @AlanBateman, what should be our next step for this PR :)

-------------

PR: https://git.openjdk.org/jdk/pull/12283

From skuksenko at openjdk.org  Tue Feb 14 03:22:43 2023
From: skuksenko at openjdk.org (Sergey Kuksenko)
Date: Tue, 14 Feb 2023 03:22:43 GMT
Subject: RFR: 8302204: Optimize BigDecimal.divide
In-Reply-To: <rUC0Dh_-1E0PZNJwM0GRH1KPu6prPotT-oeDTUdqjI4=.a8f7d3b7-a0f2-45a0-ae01-f37ef108d18f@github.com>
References: <rUC0Dh_-1E0PZNJwM0GRH1KPu6prPotT-oeDTUdqjI4=.a8f7d3b7-a0f2-45a0-ae01-f37ef108d18f@github.com>
Message-ID: <LsBjupG20ZvkAuKI-gFAPtdg3-glOkS2wAy15hRa-BM=.76ada238-5727-4975-898e-ed6cbadd6203@github.com>

On Fri, 10 Feb 2023 10:00:05 GMT, Xiaowei Lu <duke at openjdk.org> wrote:

> [JDK-8269667](https://bugs.openjdk.org/browse/JDK-8269667) has uncovered the poor performance of BigDecimal.divide under certain circumstance.
> 
> We confront similar situations when benchmarking Spark3 on TPC-DS test kit. According to the flame-graph below, it is StripZeros that spends most of the time of BigDecimal.divide. Hence we propose this patch to optimize stripping zeros.
> ![?? 1](https://user-images.githubusercontent.com/39413832/218062061-53cd0220-776e-4b72-8b9a-6b0f11707986.png)
> 
> Currently, createAndStripZerosToMatchScale() is performed linearly. That is, the target value is parsed from back to front, each time stripping out single ?0?. To optimize, we can adopt the method of binary search. That is, each time we try to strip out ${scale/2} ?0?s. 
> 
> The performance looks good. Therotically, time complexity of our method is O(log n), while the current one is O(n). In practice, benchmarks on Spark3 show that 1/3 less time (102s->68s) is spent on TPC-DS query4. We also runs Jtreg and JCK to check correctness, and it seems fine.
> 
> More about environment: 
> we run Spark3.3.0 on Openjdk11, but it seems jdk version doesn?t have much impact on BigDecimal. Spark cluster consists of a main node and 2 core nodes, each has 4cores, 16g memory and 4x500GB storage.

The pr looks promising in terms of performance.
What makes sense to do:

*)  Don't rely on external benchmarks. It's fine if such exists, but anyway set of microbenchmarks (using JMH) will be much better. More clear, readable results, etc. E.g., it may show that other operations (for example, sqrt) were speeded up too.

*) Find boundaries. 
"divideAndRemainder(bigTenToThe(scaleStep))" may produce non-zero reminder. Find conditions when it happens. How big is performance regression in such cases?

Some other optimizations:
*)
Current code checks only the lowest bit (odd or even) to cut off indivisible cases.
Making "divideAndRemainder(bigTenToThe(scaleStep))"  - you make check scaleStep lowest bits to do cut off. See "BigInteger.getLowestSetBit()"

*)
BigInteger division by int value is faster. It's a special case. What is faster, doing the single division by bigTenToThe(scaleStep) or doing several divisions (split scaleStep to fit into int)? Exploration is required.

-------------

PR: https://git.openjdk.org/jdk/pull/12509

From duke at openjdk.org  Tue Feb 14 04:48:43 2023
From: duke at openjdk.org (Xiaowei Lu)
Date: Tue, 14 Feb 2023 04:48:43 GMT
Subject: RFR: 8302204: Optimize BigDecimal.divide
In-Reply-To: <rUC0Dh_-1E0PZNJwM0GRH1KPu6prPotT-oeDTUdqjI4=.a8f7d3b7-a0f2-45a0-ae01-f37ef108d18f@github.com>
References: <rUC0Dh_-1E0PZNJwM0GRH1KPu6prPotT-oeDTUdqjI4=.a8f7d3b7-a0f2-45a0-ae01-f37ef108d18f@github.com>
Message-ID: <l3PjcYg_yEGEOSz6VYIpGzkFnocWP28BG_m7cgUUjZg=.ad971afc-1d55-403c-ab8b-a1e8275a8e57@github.com>

On Fri, 10 Feb 2023 10:00:05 GMT, Xiaowei Lu <duke at openjdk.org> wrote:

> [JDK-8269667](https://bugs.openjdk.org/browse/JDK-8269667) has uncovered the poor performance of BigDecimal.divide under certain circumstance.
> 
> We confront similar situations when benchmarking Spark3 on TPC-DS test kit. According to the flame-graph below, it is StripZeros that spends most of the time of BigDecimal.divide. Hence we propose this patch to optimize stripping zeros.
> ![?? 1](https://user-images.githubusercontent.com/39413832/218062061-53cd0220-776e-4b72-8b9a-6b0f11707986.png)
> 
> Currently, createAndStripZerosToMatchScale() is performed linearly. That is, the target value is parsed from back to front, each time stripping out single ?0?. To optimize, we can adopt the method of binary search. That is, each time we try to strip out ${scale/2} ?0?s. 
> 
> The performance looks good. Therotically, time complexity of our method is O(log n), while the current one is O(n). In practice, benchmarks on Spark3 show that 1/3 less time (102s->68s) is spent on TPC-DS query4. We also runs Jtreg and JCK to check correctness, and it seems fine.
> 
> More about environment: 
> we run Spark3.3.0 on Openjdk11, but it seems jdk version doesn?t have much impact on BigDecimal. Spark cluster consists of a main node and 2 core nodes, each has 4cores, 16g memory and 4x500GB storage.

> _Mailing list message from [Louis Wasserman](mailto:lowasser at google.com) on [core-libs-dev](mailto:core-libs-dev at mail.openjdk.org):_
> 
> Could you do that benchmark with e.g. JMH rather than taking the difference of System.currentTimeMillis? That would probably make it easier to read and trust the results.
> 
> On Sun, Feb 12, 2023, 7:56 PM Sergey Kuksenko <skuksenko at openjdk.org> wrote:
> 
> -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20230212/a0de161d/attachment.htm>

Sure. I have written a microbenchmark using JMH and it shows

before optimization 
DecimalBenchmark.divide_by_2         thrpt    5   334549.891 ?  3028.946  ops/s
DecimalBenchmark.divide_by_2_to_100  thrpt    5    15874.537 ?    38.942  ops/s
DecimalBenchmark.divide_by_3         thrpt    5  6190583.950 ? 91116.750  ops/s

after optimization 
DecimalBenchmark.divide_by_2         thrpt    5  1479106.480 ?  5950.440  ops/s
DecimalBenchmark.divide_by_2_to_100  thrpt    5    32730.634 ?    81.891  ops/s
DecimalBenchmark.divide_by_3         thrpt    5  6233700.252 ? 21043.571  ops/s


The following is the benchmark code

@State(Scope.Benchmark)
@BenchmarkMode(Mode.Throughput)
@Warmup(iterations = 5, time = 10)
@Measurement(iterations = 5, time = 10)
@Fork(value = 1)
public class DecimalBenchmark {
    private static final MathContext mc = new MathContext(38, RoundingMode.HALF_UP);

    @Benchmark
    public void divide_by_2_to_100() {
        for(long i = 2; i <= 100; i++) {
            BigDecimal divisor = BigDecimal.valueOf(i);
            BigDecimal.ONE.divide(divisor, mc);
        }
    }

    @Benchmark
    public void divide_by_2() {
        BigDecimal.ONE.divide(BigDecimal.valueOf(2L), mc);
    }

    @Benchmark
    public void divide_by_3() {
        BigDecimal.ONE.divide(BigDecimal.valueOf(3L), mc);
    }
}

-------------

PR: https://git.openjdk.org/jdk/pull/12509

From duke at openjdk.org  Tue Feb 14 04:51:41 2023
From: duke at openjdk.org (Xiaowei Lu)
Date: Tue, 14 Feb 2023 04:51:41 GMT
Subject: RFR: 8302204: Optimize BigDecimal.divide
In-Reply-To: <LsBjupG20ZvkAuKI-gFAPtdg3-glOkS2wAy15hRa-BM=.76ada238-5727-4975-898e-ed6cbadd6203@github.com>
References: <rUC0Dh_-1E0PZNJwM0GRH1KPu6prPotT-oeDTUdqjI4=.a8f7d3b7-a0f2-45a0-ae01-f37ef108d18f@github.com>
 <LsBjupG20ZvkAuKI-gFAPtdg3-glOkS2wAy15hRa-BM=.76ada238-5727-4975-898e-ed6cbadd6203@github.com>
Message-ID: <uPa3KZYwKdQeJpnSGCZoLYg7haPNZAibGrwH10PxUrw=.025a1629-59b3-4a3f-9063-600f38040280@github.com>

On Tue, 14 Feb 2023 03:20:14 GMT, Sergey Kuksenko <skuksenko at openjdk.org> wrote:

> The pr looks promising in terms of performance. What makes sense to do:
> 
> *) Don't rely on external benchmarks. It's fine if such exists, but anyway set of microbenchmarks (using JMH) will be much better. More clear, readable results, etc. E.g., it may show that other operations (for example, sqrt) were speeded up too.
> 
> *) Find boundaries. "divideAndRemainder(bigTenToThe(scaleStep))" may produce non-zero reminder. Find conditions when it happens. How big is performance regression in such cases?
> 
> Some other optimizations: *) Current code checks only the lowest bit (odd or even) to cut off indivisible cases. Making "divideAndRemainder(bigTenToThe(scaleStep))" - you make check scaleStep lowest bits to do cut off. See "BigInteger.getLowestSetBit()"
> 
> *) BigInteger division by int value is faster. It's a special case. What is faster, doing the single division by bigTenToThe(scaleStep) or doing several divisions (split scaleStep to fit into int)? Exploration is required.

Good idea! Thanks.
I will look into such cases and try to explore more.

-------------

PR: https://git.openjdk.org/jdk/pull/12509

From tvaleev at openjdk.org  Tue Feb 14 05:42:02 2023
From: tvaleev at openjdk.org (Tagir F. Valeev)
Date: Tue, 14 Feb 2023 05:42:02 GMT
Subject: Integrated: 8301226: Add clamp() methods to java.lang.Math and to
 StrictMath
In-Reply-To: <c7kJhZvT8oz5hScMxnWI23H7wjCaJ854ajjSRtxBnW4=.3f4e24ca-c608-4541-b80e-cf3452ec6400@github.com>
References: <c7kJhZvT8oz5hScMxnWI23H7wjCaJ854ajjSRtxBnW4=.3f4e24ca-c608-4541-b80e-cf3452ec6400@github.com>
Message-ID: <N-XW5HvjkR3ll7mBLDH7aN7MXEZfp8A5gvou6Hz5NQw=.06c0ac6b-d224-452f-b6cc-35b94608e461@github.com>

On Sat, 4 Feb 2023 13:24:11 GMT, Tagir F. Valeev <tvaleev at openjdk.org> wrote:

> clamp() methods added to Math and StrictMath
> 
> `int clamp(long, int, int)` is somewhat different, as it accepts a `long` value and safely clamps it to an `int` range. Other overloads work with a particular type (long, float and double). Using similar approach in other cases (e.g. `float clamp(double, float, float)`) may cause accidental precision loss even if the value is within range, so I decided to avoid this.
> 
> In all cases, `max >= min` precondition should met. For double and float we additionally order `-0.0 < 0.0`, similarly to what Math.max or Double.compare do. In double and float overloads I try to keep at most one arg-check comparison on common path, so the order of checks might look unusual.
> 
> For tests, I noticed that tests in java/lang/Math don't use any testing framework (even newer tests), so I somehow mimic the approach of neighbour tests.

This pull request has now been integrated.

Changeset: 94e7cc85
Author:    Tagir F. Valeev <tvaleev at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/94e7cc8587356988e713d23d1653bdd5c43fb3f1
Stats:     500 lines in 3 files changed: 499 ins; 0 del; 1 mod

8301226: Add clamp() methods to java.lang.Math and to StrictMath

Reviewed-by: qamai, darcy

-------------

PR: https://git.openjdk.org/jdk/pull/12428

From duke at openjdk.org  Tue Feb 14 07:01:53 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Tue, 14 Feb 2023 07:01:53 GMT
Subject: Integrated: 8302214: Typo in javadoc of Arrays.compare and
 Arrays.mismatch
In-Reply-To: <NC9N8WA8eqcmgwep2tqJaD5rruWOHwWxbbYCd4XsdRk=.aa39a6a4-396b-4fac-a408-3e0c04fc140c@github.com>
References: <NC9N8WA8eqcmgwep2tqJaD5rruWOHwWxbbYCd4XsdRk=.aa39a6a4-396b-4fac-a408-3e0c04fc140c@github.com>
Message-ID: <kXAS-onnL-r0BjzLqhr4QtbXpUUGj7gM74acMok6DU8=.2680fa3a-22c8-428d-9868-c255361629cd@github.com>

On Thu, 9 Feb 2023 10:13:03 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

> The Javadocs of Arrays.compare and Arrays.mismatch uses the incorrect capitalization `atoIndex` and `btoIndex` when referencing the corresponding `aToIndex` and `bToIndex` parameters.
> 
> Sample:
> 
> 
> * specified ranges [{@code aFromIndex}, {@code atoIndex}) and
> * [{@code bFromIndex}, {@code btoIndex}) respectively:
> 
> 
> This PR changes the capitalization to `aToIndex` and `bToIndex`. This change was performed using case-sensitive search / replace in an IDE.

This pull request has now been integrated.

Changeset: d782125c
Author:    Eirik Bjorsnos <eirbjo at gmail.com>
Committer: Jaikiran Pai <jpai at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/d782125c8f3bfe087269e4430dd12328d8cc77f8
Stats:     58 lines in 1 file changed: 0 ins; 0 del; 58 mod

8302214: Typo in javadoc of Arrays.compare and Arrays.mismatch

Reviewed-by: jpai

-------------

PR: https://git.openjdk.org/jdk/pull/12488

From lbourges at openjdk.org  Tue Feb 14 07:14:53 2023
From: lbourges at openjdk.org (Laurent =?UTF-8?B?Qm91cmfDqHM=?=)
Date: Tue, 14 Feb 2023 07:14:53 GMT
Subject: RFR: JDK-8266431: Dual-Pivot Quicksort improvements (Radix sort)
 [v18]
In-Reply-To: <v1aeO-1p-DSSHsJGRrHYRRFDggX3Q65HAtrHaRd9hEo=.1dd0c76b-ea4f-47f6-8454-dc8ed96fd2cd@github.com>
References: <8CwTPTO3LHUzkcn1tznXnWv3j7mKevPTrJCEDbBwAA8=.0347ef73-b94d-46a3-a768-b796082c832d@github.com>
 <v1aeO-1p-DSSHsJGRrHYRRFDggX3Q65HAtrHaRd9hEo=.1dd0c76b-ea4f-47f6-8454-dc8ed96fd2cd@github.com>
Message-ID: <b2cuJoEEClRDJGkiW7F_boE2ltU0fZLTgem-Y4tDQBg=.0c09f693-6e0f-4b79-961a-0b40a0e3f13b@github.com>

On Wed, 9 Nov 2022 21:06:50 GMT, iaroslavski <duke at openjdk.org> wrote:

>> Sorting:
>> 
>> - adopt radix sort for sequential and parallel sorts on int/long/float/double arrays (almost random and length > 6K)
>> - fix tryMergeRuns() to better handle case when the last run is a single element
>> - minor javadoc and comment changes
>> 
>> Testing:
>> - add new data inputs in tests for sorting
>> - add min/max/infinity values to float/double testing
>> - add tests for radix sort
>
> iaroslavski has updated the pull request incrementally with one additional commit since the last revision:
> 
>   JDK-8266431: Dual-Pivot Quicksort improvements (Radix sort)
>   
>   * Fixed microbenchmarking tests

I am currently preparing my PR against latest jdk to start an official review...

-------------

PR: https://git.openjdk.org/jdk/pull/3938

From alanb at openjdk.org  Tue Feb 14 07:47:43 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 14 Feb 2023 07:47:43 GMT
Subject: RFR: 8301627: System.exit and Runtime.exit debug logging [v2]
In-Reply-To: <fpoG44CoHxj8JXmx6ry-xdQK2HFfj02RBdT3S9NrIs0=.cdf07271-43a0-4fc4-a10e-545ed4e92492@github.com>
References: <OzJeJH5yxolKPChcUisqtzGYF_MU3oOJdx6HPhsXjBw=.15eefe39-efe1-433e-a6ac-02b4a730f264@github.com>
 <2zbWTodXVENcsxo-J5IcBLxQoHqnIdtmB4TnV5w7Uag=.d4aa5964-5e0e-41b5-b6f9-39f4edb1b2b4@github.com>
 <fpoG44CoHxj8JXmx6ry-xdQK2HFfj02RBdT3S9NrIs0=.cdf07271-43a0-4fc4-a10e-545ed4e92492@github.com>
Message-ID: <-9o7wGKkaBfP4CC_Hq0pkq5GxWBmPNgloyCsC_J5198=.b02971fc-2d28-4c9c-8450-9b626371e5bc@github.com>

On Mon, 13 Feb 2023 10:57:35 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/Shutdown.java line 162:
>> 
>>> 160:      * If the system logger {@code java.lang.Runtime} is enabled for logging level DEBUG/FINE
>>> 161:      * the stack trace of the call to {@code Runtime.exit()} or {@code System.exit()}
>>> 162:      * is logged.
>> 
>> Shutdown is not a public class so this impNote won't appear in the APIs docs. Should it move to Runtime.exit and System.exit?  If it moved to a public API then "system logger" could link to System.Logger. Also would it be more correct to say "a system logger named "java.lang.Runtime" is enabled for logging level DEBUG"?
>
> FINE is not a level supported by the System.Logger, it is the level to which DEBUG is mapped when the backend is java.util.logging. I suggest to remove FINE from this description and add an `{@link Loger.Level#DEBUG DEBUG}` around DEBUG.

Roger has updated this but it's still a comment on a non-public class. I think the main question here is whether there should be a note in the System.exit and Runtime.exit to document that these methods log? If not, will it be documented anywhere, maybe a troubleshooting guide to help track down what/who is calling System.exit?

-------------

PR: https://git.openjdk.org/jdk/pull/12517

From lbourges at openjdk.org  Tue Feb 14 07:51:55 2023
From: lbourges at openjdk.org (Laurent =?UTF-8?B?Qm91cmfDqHM=?=)
Date: Tue, 14 Feb 2023 07:51:55 GMT
Subject: RFR: 8301226: Add clamp() methods to java.lang.Math and to
 StrictMath [v8]
In-Reply-To: <-RM6Jh13GZ4ZSt1qMwNp8Wb26qjGphOY89TaGenMzkM=.a04659cd-9f11-4af8-a53c-98d9ff837198@github.com>
References: <c7kJhZvT8oz5hScMxnWI23H7wjCaJ854ajjSRtxBnW4=.3f4e24ca-c608-4541-b80e-cf3452ec6400@github.com>
 <-RM6Jh13GZ4ZSt1qMwNp8Wb26qjGphOY89TaGenMzkM=.a04659cd-9f11-4af8-a53c-98d9ff837198@github.com>
Message-ID: <hv1q439yUWjnJP9zPZZVCS-1AkJQQbiTGsBfLsbdp-g=.0cd0b37b-ba2f-4442-8c41-587cce2a69c6@github.com>

On Tue, 7 Feb 2023 12:53:25 GMT, Tagir F. Valeev <tvaleev at openjdk.org> wrote:

>> clamp() methods added to Math and StrictMath
>> 
>> `int clamp(long, int, int)` is somewhat different, as it accepts a `long` value and safely clamps it to an `int` range. Other overloads work with a particular type (long, float and double). Using similar approach in other cases (e.g. `float clamp(double, float, float)`) may cause accidental precision loss even if the value is within range, so I decided to avoid this.
>> 
>> In all cases, `max >= min` precondition should met. For double and float we additionally order `-0.0 < 0.0`, similarly to what Math.max or Double.compare do. In double and float overloads I try to keep at most one arg-check comparison on common path, so the order of checks might look unusual.
>> 
>> For tests, I noticed that tests in java/lang/Math don't use any testing framework (even newer tests), so I somehow mimic the approach of neighbour tests.
>
> Tagir F. Valeev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Comments in tests

Is it ever possible to optimize clamp() impl ?
I suppose 2 if conditions can be simplified:
????????return?(int)?Math.min(max,?Math.max(value,?min));
Maybe hotspot c2 can deduce it or using intrinsics:
If value<=min:
  return min
If value>=max:
  return max
return value
(NaN compatible=>NaN)

-------------

PR: https://git.openjdk.org/jdk/pull/12428

From duke at openjdk.org  Tue Feb 14 08:04:47 2023
From: duke at openjdk.org (Andriy Plokhotnyuk)
Date: Tue, 14 Feb 2023 08:04:47 GMT
Subject: RFR: 8205592: BigDecimal.doubleValue() is depressingly slow
In-Reply-To: <XpbHjLD13akVXWMOh0CVfH3ZjWeWLzMenrJ0UxjMO5I=.03ec2741-0762-459d-b27a-3cc022a48a19@github.com>
References: <XpbHjLD13akVXWMOh0CVfH3ZjWeWLzMenrJ0UxjMO5I=.03ec2741-0762-459d-b27a-3cc022a48a19@github.com>
Message-ID: <C_RUmXLqH-qrTwIQOb_qSS7JMw-LF66lnVPsHMfMV_A=.29c2a24b-1879-49f0-86fa-39150ff9b29c@github.com>

On Thu, 7 Jul 2022 15:20:32 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

> A reimplementation of `BigDecimal.[double|float]Value()` to enhance performance, avoiding an intermediate string and its subsequent parsing on the slow path.

Sorry, I failed to recognize those checks two times :)

How about adding [this moderate path](https://github.com/plokhotnyuk/jsoniter-scala/blob/6f702ce5cae05df91b5aa6e4bd61acdf43bf18f6/jsoniter-scala-core/jvm/src/main/scala/com/github/plokhotnyuk/jsoniter_scala/core/JsonReader.scala#L1467-L1498)?

Also, I think it worth do be reused for regular parsing of double and float values from string.

-------------

PR: https://git.openjdk.org/jdk/pull/9410

From duke at openjdk.org  Tue Feb 14 08:34:15 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Tue, 14 Feb 2023 08:34:15 GMT
Subject: RFR: 8301873: Avoid string decoding in ZipFile.Source.getEntryPos
 [v10]
In-Reply-To: <FkmdspiHVjkAKFqm5kUgwaf55YH5cBbczS_3krqsdFs=.05eca901-f55f-47d9-b1bc-0cf2f5b87536@github.com>
References: <FkmdspiHVjkAKFqm5kUgwaf55YH5cBbczS_3krqsdFs=.05eca901-f55f-47d9-b1bc-0cf2f5b87536@github.com>
Message-ID: <yROFGpFoZeG5UrTg-GozeIlF39x2ykhGBNwh_Y7Oz-s=.edc0f431-e20c-4b51-a9cc-f1c3c40547d3@github.com>

> After finding a hash match, getEntryPos needs to compare the lookup name up to the encoded entry name in the CEN. This comparison is done by decoding the entry name into a String. The names can then be compared using the String API. This decoding step adds a significat cost to this method.
> 
> This PR suggest to update the string comparison such that in the common case where  both the lookup name and the entry name are encoded in ASCII-compatible UTF-8,  decoding can be avoided and the byte arrays can instead be compared direcly. 
> 
> ZipCoder is updated with a new method to compare a string with an encoded byte array range.  The default implementation decodes to string (like the current code), while the UTF-8 implementation uses JavaLangAccess.getBytesNoRepl to get the  bytes. Both methods thes uses Arrays.mismatch for comparison with or without matching trailing slashes. 
> 
> Additionally, this PR suggest to make the following updates to getEntryPos:
> 
> - The try/catch for IAE is redundant and can be safely removed. (initCEN already checks this and will throws IAE for invalid UTF-8). This seems to give a 3-4% speedup on micros)
> - A new test InvalidBytesInEntryNameOrComment is a added to verify that initCEN does in fact reject invalid UTF-8 in CEN file names and comments. (I found no existing test coverage for this)
> - The recursion when looking for "name/" matches is replaced with iteration. We keep track of any "name/" match and return it at the end of the search. (I feel this is easier to follow and it also gives a ~30% speedup for addSlash lookups with no regression on regular lookups)
> 
> (My though is that including these additional updates in this PR might reduce reviewer overhead given that it touches the exact same code. I might be wrong on this, please advise :)
> 
> I'm seeing a ~17% saving on the micro ZipFileGetEntry.getEntryHit (modified to use xalan.jar):
> 
> Baseline:
> 
> Benchmark                             (size)  Mode  Cnt    Score   Error  Units
> ZipFileGetEntry.getEntryHit              512  avgt   15   74.941 ? 1.004  ns/op
> ZipFileGetEntry.getEntryHit             1024  avgt   15   84.943 ? 1.320  ns/op
> ZipFileGetEntry.getEntryHitUncached      512  avgt   15  120.371 ? 2.386  ns/op
> ZipFileGetEntry.getEntryHitUncached     1024  avgt   15  126.128 ? 1.075  ns/op
> ZipFileGetEntry.getEntryMiss             512  avgt   15   23.818 ? 0.838  ns/op
> ZipFileGetEntry.getEntryMiss            1024  avgt   15   29.762 ? 5.998  ns/op
> ZipFileGetEntry.getEntryMissUncached     512  avgt   15   59.405 ? 0.545  ns/op
> ZipFileGetEntry.getEntryMissUncached    1024  avgt   15   71.840 ? 2.455  ns/op
> ZipFileGetEntry.getEntrySlash            512  avgt   15  135.621 ? 4.341  ns/op
> ZipFileGetEntry.getEntrySlash           1024  avgt   15  134.190 ? 2.141  ns/op
> 
> 
> 
> PR:
> 
> 
> Benchmark                             (size)  Mode  Cnt    Score   Error  Units
> ZipFileGetEntry.getEntryHit              512  avgt   15   62.267 ? 1.329  ns/op
> ZipFileGetEntry.getEntryHit             1024  avgt   15   72.916 ? 2.428  ns/op
> ZipFileGetEntry.getEntryHitUncached      512  avgt   15  101.630 ? 1.154  ns/op
> ZipFileGetEntry.getEntryHitUncached     1024  avgt   15  113.161 ? 0.502  ns/op
> ZipFileGetEntry.getEntryMiss             512  avgt   15   23.003 ? 1.191  ns/op
> ZipFileGetEntry.getEntryMiss            1024  avgt   15   23.236 ? 1.114  ns/op
> ZipFileGetEntry.getEntryMissUncached     512  avgt   15   56.781 ? 1.505  ns/op
> ZipFileGetEntry.getEntryMissUncached    1024  avgt   15   67.767 ? 1.963  ns/op
> ZipFileGetEntry.getEntrySlash            512  avgt   15   73.745 ? 2.717  ns/op
> ZipFileGetEntry.getEntrySlash           1024  avgt   15   75.784 ? 1.051  ns/op
> 
> 
> To assess the impact on startup/warmup, I made a main method class which measures the total time of calling ZipFile.getEntry for all entries in the 109 JAR file dependenies of spring-petclinic. The shows a nice improvement (time in micros):
> 
> 
> Percentile Baseline Patch
> 50?%          23155 21149
> 75?%          23598 21454
> 90?%          23989 21691
> 95?%          24238 21973
> 99?%          25270 22446
> STDEV           792   549
> Count           500   500

Eirik Bjorsnos has updated the pull request incrementally with one additional commit since the last revision:

  Improve documentation of ZipCoder.compare and the Comparison enum values. Describe rationale for the tests added to TestZipFileEncodings. Revert unintended change in setTime in TestZipFileEncodings. Rename Comparison.SLASH_MATCH to DIRECTORY_MATCH.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12290/files
  - new: https://git.openjdk.org/jdk/pull/12290/files/d94cbe38..a633d270

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12290&range=09
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12290&range=08-09

  Stats: 98 lines in 3 files changed: 68 ins; 4 del; 26 mod
  Patch: https://git.openjdk.org/jdk/pull/12290.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12290/head:pull/12290

PR: https://git.openjdk.org/jdk/pull/12290

From duke at openjdk.org  Tue Feb 14 08:45:47 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Tue, 14 Feb 2023 08:45:47 GMT
Subject: RFR: 8301873: Avoid string decoding in ZipFile.Source.getEntryPos
 [v10]
In-Reply-To: <yROFGpFoZeG5UrTg-GozeIlF39x2ykhGBNwh_Y7Oz-s=.edc0f431-e20c-4b51-a9cc-f1c3c40547d3@github.com>
References: <FkmdspiHVjkAKFqm5kUgwaf55YH5cBbczS_3krqsdFs=.05eca901-f55f-47d9-b1bc-0cf2f5b87536@github.com>
 <yROFGpFoZeG5UrTg-GozeIlF39x2ykhGBNwh_Y7Oz-s=.edc0f431-e20c-4b51-a9cc-f1c3c40547d3@github.com>
Message-ID: <bH2CPdJ6FKxAoMG4pf05RqRqx1_NeJIzFLc1aEmjh0w=.95ac32d9-65a6-41e0-a247-d28ae1b7a384@github.com>

On Tue, 14 Feb 2023 08:34:15 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

>> After finding a hash match, getEntryPos needs to compare the lookup name up to the encoded entry name in the CEN. This comparison is done by decoding the entry name into a String. The names can then be compared using the String API. This decoding step adds a significat cost to this method.
>> 
>> This PR suggest to update the string comparison such that in the common case where  both the lookup name and the entry name are encoded in ASCII-compatible UTF-8,  decoding can be avoided and the byte arrays can instead be compared direcly. 
>> 
>> ZipCoder is updated with a new method to compare a string with an encoded byte array range.  The default implementation decodes to string (like the current code), while the UTF-8 implementation uses JavaLangAccess.getBytesNoRepl to get the  bytes. Both methods thes uses Arrays.mismatch for comparison with or without matching trailing slashes. 
>> 
>> Additionally, this PR suggest to make the following updates to getEntryPos:
>> 
>> - The try/catch for IAE is redundant and can be safely removed. (initCEN already checks this and will throws IAE for invalid UTF-8). This seems to give a 3-4% speedup on micros)
>> - A new test InvalidBytesInEntryNameOrComment is a added to verify that initCEN does in fact reject invalid UTF-8 in CEN file names and comments. (I found no existing test coverage for this)
>> - The recursion when looking for "name/" matches is replaced with iteration. We keep track of any "name/" match and return it at the end of the search. (I feel this is easier to follow and it also gives a ~30% speedup for addSlash lookups with no regression on regular lookups)
>> 
>> (My though is that including these additional updates in this PR might reduce reviewer overhead given that it touches the exact same code. I might be wrong on this, please advise :)
>> 
>> I'm seeing a ~17% saving on the micro ZipFileGetEntry.getEntryHit (modified to use xalan.jar):
>> 
>> Baseline:
>> 
>> Benchmark                             (size)  Mode  Cnt    Score   Error  Units
>> ZipFileGetEntry.getEntryHit              512  avgt   15   74.941 ? 1.004  ns/op
>> ZipFileGetEntry.getEntryHit             1024  avgt   15   84.943 ? 1.320  ns/op
>> ZipFileGetEntry.getEntryHitUncached      512  avgt   15  120.371 ? 2.386  ns/op
>> ZipFileGetEntry.getEntryHitUncached     1024  avgt   15  126.128 ? 1.075  ns/op
>> ZipFileGetEntry.getEntryMiss             512  avgt   15   23.818 ? 0.838  ns/op
>> ZipFileGetEntry.getEntryMiss            1024  avgt   15   29.762 ? 5.998  ns/op
>> ZipFileGetEntry.getEntryMissUncached     512  avgt   15   59.405 ? 0.545  ns/op
>> ZipFileGetEntry.getEntryMissUncached    1024  avgt   15   71.840 ? 2.455  ns/op
>> ZipFileGetEntry.getEntrySlash            512  avgt   15  135.621 ? 4.341  ns/op
>> ZipFileGetEntry.getEntrySlash           1024  avgt   15  134.190 ? 2.141  ns/op
>> 
>> 
>> 
>> PR:
>> 
>> 
>> Benchmark                             (size)  Mode  Cnt    Score   Error  Units
>> ZipFileGetEntry.getEntryHit              512  avgt   15   62.267 ? 1.329  ns/op
>> ZipFileGetEntry.getEntryHit             1024  avgt   15   72.916 ? 2.428  ns/op
>> ZipFileGetEntry.getEntryHitUncached      512  avgt   15  101.630 ? 1.154  ns/op
>> ZipFileGetEntry.getEntryHitUncached     1024  avgt   15  113.161 ? 0.502  ns/op
>> ZipFileGetEntry.getEntryMiss             512  avgt   15   23.003 ? 1.191  ns/op
>> ZipFileGetEntry.getEntryMiss            1024  avgt   15   23.236 ? 1.114  ns/op
>> ZipFileGetEntry.getEntryMissUncached     512  avgt   15   56.781 ? 1.505  ns/op
>> ZipFileGetEntry.getEntryMissUncached    1024  avgt   15   67.767 ? 1.963  ns/op
>> ZipFileGetEntry.getEntrySlash            512  avgt   15   73.745 ? 2.717  ns/op
>> ZipFileGetEntry.getEntrySlash           1024  avgt   15   75.784 ? 1.051  ns/op
>> 
>> 
>> To assess the impact on startup/warmup, I made a main method class which measures the total time of calling ZipFile.getEntry for all entries in the 109 JAR file dependenies of spring-petclinic. The shows a nice improvement (time in micros):
>> 
>> 
>> Percentile Baseline Patch
>> 50?%          23155 21149
>> 75?%          23598 21454
>> 90?%          23989 21691
>> 95?%          24238 21973
>> 99?%          25270 22446
>> STDEV           792   549
>> Count           500   500
>
> Eirik Bjorsnos has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Improve documentation of ZipCoder.compare and the Comparison enum values. Describe rationale for the tests added to TestZipFileEncodings. Revert unintended change in setTime in TestZipFileEncodings. Rename Comparison.SLASH_MATCH to DIRECTORY_MATCH.

Thanks for your thorough and helpful review, Lance.

-------------

PR: https://git.openjdk.org/jdk/pull/12290

From duke at openjdk.org  Tue Feb 14 08:45:55 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Tue, 14 Feb 2023 08:45:55 GMT
Subject: RFR: 8301873: Avoid string decoding in ZipFile.Source.getEntryPos
 [v9]
In-Reply-To: <3fZ6eVyW0fQ2QLZhOG5PyO5nBQ0CqlWt1p41Y2Xtjd4=.2acab1ed-7086-4030-869f-b324b640ea77@github.com>
References: <FkmdspiHVjkAKFqm5kUgwaf55YH5cBbczS_3krqsdFs=.05eca901-f55f-47d9-b1bc-0cf2f5b87536@github.com>
 <p2-revzHDap8mmK22cZnmfocoxjzMZgOWsQX2p8iLYo=.2f9cfa42-46ca-4527-9b4a-103dd06fcdc3@github.com>
 <3fZ6eVyW0fQ2QLZhOG5PyO5nBQ0CqlWt1p41Y2Xtjd4=.2acab1ed-7086-4030-869f-b324b640ea77@github.com>
Message-ID: <I2uk-mq607dC7enbmnLPjtnv8dIo6ibbKcPnhijlS0M=.e1cbbdda-c8ac-4ad8-bc41-2a3398e95d82@github.com>

On Mon, 13 Feb 2023 20:00:51 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> Eirik Bjorsnos has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Revert accidental removal of UTF8ZipCoder.compare
>
> src/java.base/share/classes/java/util/zip/ZipCoder.java line 66:
> 
>> 64:         NO_MATCH
>> 65:     }
>> 66: 
> 
> Please add a comment indicating what the values mean

I added comments to the enum and each of the values.

> src/java.base/share/classes/java/util/zip/ZipCoder.java line 210:
> 
>> 208:      * is known and matches the charset of this ZipCoder.
>> 209:      */
>> 210:     Comparison compare(String str, byte[] b, int off, int len, boolean addSlash) {
> 
> If you could add an `@param` comments, that would be awesome ?

I improved the Javadoc of this method and added `@param` comments.

> src/java.base/share/classes/java/util/zip/ZipFile.java line 1665:
> 
>> 1663:             }
>> 1664:             // No exact match found, will return either slashMatch or -1
>> 1665:             return slashMatch;
> 
> This gets a bit confusing as we return `pos` when we have an exact match so it would be helpful to had more clarity via additional comments(it might not have been clear with the previous comments but I think if we are going to add `slashMatch` we should take the time to beef up the comments

The dual-modality of this method certainly allows for some head-scratch trying to find a succinct way to describe its logic. I have made an attempt to improve it, but I'm sure it could be even better.

The `slashPos` name was probably ok as a local variable, but now that it is part of the contract of ZipCoder.compare, I think it helps to rename the enum value to `DIRECTORY_NAME` and update `slashPos` to `dirPos` accordingly. 

Do you have any suggestions on how to improve the comments in the last version?

> test/jdk/java/util/zip/ZipFile/TestZipFileEncodings.java line 127:
> 
>> 125:     }
>> 126: 
>> 127:     @Test
> 
> Please add a comment introducing the test

I described the rationale of adding this test in a comment.

> test/jdk/java/util/zip/ZipFile/TestZipFileEncodings.java line 143:
> 
>> 141:         }
>> 142:     }
>> 143:     @Test(dataProvider = "all-charsets")
> 
> Please add a comment introducing the test

I described the rationale of adding this test in a comment.

> test/jdk/java/util/zip/ZipFile/TestZipFileEncodings.java line 307:
> 
>> 305:                 ze.setCrc(crc.getValue());
>> 306:             }
>> 307:             ze.setTime(1675862371399L);
> 
> Please add a comment indicating what the time is

This change was accidentaly introduced, I have reverted it. Good catch.

-------------

PR: https://git.openjdk.org/jdk/pull/12290

From duke at openjdk.org  Tue Feb 14 08:49:46 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Tue, 14 Feb 2023 08:49:46 GMT
Subject: RFR: 8301873: Avoid string decoding in ZipFile.Source.getEntryPos
 [v9]
In-Reply-To: <3fZ6eVyW0fQ2QLZhOG5PyO5nBQ0CqlWt1p41Y2Xtjd4=.2acab1ed-7086-4030-869f-b324b640ea77@github.com>
References: <FkmdspiHVjkAKFqm5kUgwaf55YH5cBbczS_3krqsdFs=.05eca901-f55f-47d9-b1bc-0cf2f5b87536@github.com>
 <p2-revzHDap8mmK22cZnmfocoxjzMZgOWsQX2p8iLYo=.2f9cfa42-46ca-4527-9b4a-103dd06fcdc3@github.com>
 <3fZ6eVyW0fQ2QLZhOG5PyO5nBQ0CqlWt1p41Y2Xtjd4=.2acab1ed-7086-4030-869f-b324b640ea77@github.com>
Message-ID: <JZnpNuDyzOuST2FenNqvlLCRH-mhjTJRrynIXNpXG6s=.73106c41-38d5-4156-8e1b-4a86c52d030d@github.com>

On Mon, 13 Feb 2023 20:20:22 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> Eirik Bjorsnos has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Revert accidental removal of UTF8ZipCoder.compare
>
> test/jdk/java/util/zip/ZipFile/InvalidBytesInEntryNameOrComment.java line 90:
> 
>> 88:             expectedExceptionsMessageRegExp = BAD_ENTRY_NAME_OR_COMMENT)
>> 89:     public void shouldRejectInvalidName() throws IOException {
>> 90:         try (ZipFile zf = new ZipFile(invalidName.toFile())) {
> 
> If you could please convert to use `expectThrows` to get to validate the message name

The message is already validated using `expectedExceptionsMessageRegExp` in the `@Test` annotation.

Would you prefer if I use expectThrows instead, or perhaps inline the `BAD_ENTRY_NAME_OR_COMMENT` constant as a literal?

-------------

PR: https://git.openjdk.org/jdk/pull/12290

From duke at openjdk.org  Tue Feb 14 09:01:12 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Tue, 14 Feb 2023 09:01:12 GMT
Subject: RFR: 8301873: Avoid string decoding in ZipFile.Source.getEntryPos
 [v11]
In-Reply-To: <FkmdspiHVjkAKFqm5kUgwaf55YH5cBbczS_3krqsdFs=.05eca901-f55f-47d9-b1bc-0cf2f5b87536@github.com>
References: <FkmdspiHVjkAKFqm5kUgwaf55YH5cBbczS_3krqsdFs=.05eca901-f55f-47d9-b1bc-0cf2f5b87536@github.com>
Message-ID: <lm-RQtUTEAXqTk0NgaY1RkxhdbtL9WPsqIojyRS6-w0=.23038e9e-eadd-42c3-911e-ec858e168e16@github.com>

> After finding a hash match, getEntryPos needs to compare the lookup name up to the encoded entry name in the CEN. This comparison is done by decoding the entry name into a String. The names can then be compared using the String API. This decoding step adds a significat cost to this method.
> 
> This PR suggest to update the string comparison such that in the common case where  both the lookup name and the entry name are encoded in ASCII-compatible UTF-8,  decoding can be avoided and the byte arrays can instead be compared direcly. 
> 
> ZipCoder is updated with a new method to compare a string with an encoded byte array range.  The default implementation decodes to string (like the current code), while the UTF-8 implementation uses JavaLangAccess.getBytesNoRepl to get the  bytes. Both methods thes uses Arrays.mismatch for comparison with or without matching trailing slashes. 
> 
> Additionally, this PR suggest to make the following updates to getEntryPos:
> 
> - The try/catch for IAE is redundant and can be safely removed. (initCEN already checks this and will throws IAE for invalid UTF-8). This seems to give a 3-4% speedup on micros)
> - A new test InvalidBytesInEntryNameOrComment is a added to verify that initCEN does in fact reject invalid UTF-8 in CEN file names and comments. (I found no existing test coverage for this)
> - The recursion when looking for "name/" matches is replaced with iteration. We keep track of any "name/" match and return it at the end of the search. (I feel this is easier to follow and it also gives a ~30% speedup for addSlash lookups with no regression on regular lookups)
> 
> (My though is that including these additional updates in this PR might reduce reviewer overhead given that it touches the exact same code. I might be wrong on this, please advise :)
> 
> I'm seeing a ~17% saving on the micro ZipFileGetEntry.getEntryHit (modified to use xalan.jar):
> 
> Baseline:
> 
> Benchmark                             (size)  Mode  Cnt    Score   Error  Units
> ZipFileGetEntry.getEntryHit              512  avgt   15   74.941 ? 1.004  ns/op
> ZipFileGetEntry.getEntryHit             1024  avgt   15   84.943 ? 1.320  ns/op
> ZipFileGetEntry.getEntryHitUncached      512  avgt   15  120.371 ? 2.386  ns/op
> ZipFileGetEntry.getEntryHitUncached     1024  avgt   15  126.128 ? 1.075  ns/op
> ZipFileGetEntry.getEntryMiss             512  avgt   15   23.818 ? 0.838  ns/op
> ZipFileGetEntry.getEntryMiss            1024  avgt   15   29.762 ? 5.998  ns/op
> ZipFileGetEntry.getEntryMissUncached     512  avgt   15   59.405 ? 0.545  ns/op
> ZipFileGetEntry.getEntryMissUncached    1024  avgt   15   71.840 ? 2.455  ns/op
> ZipFileGetEntry.getEntrySlash            512  avgt   15  135.621 ? 4.341  ns/op
> ZipFileGetEntry.getEntrySlash           1024  avgt   15  134.190 ? 2.141  ns/op
> 
> 
> 
> PR:
> 
> 
> Benchmark                             (size)  Mode  Cnt    Score   Error  Units
> ZipFileGetEntry.getEntryHit              512  avgt   15   62.267 ? 1.329  ns/op
> ZipFileGetEntry.getEntryHit             1024  avgt   15   72.916 ? 2.428  ns/op
> ZipFileGetEntry.getEntryHitUncached      512  avgt   15  101.630 ? 1.154  ns/op
> ZipFileGetEntry.getEntryHitUncached     1024  avgt   15  113.161 ? 0.502  ns/op
> ZipFileGetEntry.getEntryMiss             512  avgt   15   23.003 ? 1.191  ns/op
> ZipFileGetEntry.getEntryMiss            1024  avgt   15   23.236 ? 1.114  ns/op
> ZipFileGetEntry.getEntryMissUncached     512  avgt   15   56.781 ? 1.505  ns/op
> ZipFileGetEntry.getEntryMissUncached    1024  avgt   15   67.767 ? 1.963  ns/op
> ZipFileGetEntry.getEntrySlash            512  avgt   15   73.745 ? 2.717  ns/op
> ZipFileGetEntry.getEntrySlash           1024  avgt   15   75.784 ? 1.051  ns/op
> 
> 
> To assess the impact on startup/warmup, I made a main method class which measures the total time of calling ZipFile.getEntry for all entries in the 109 JAR file dependenies of spring-petclinic. The shows a nice improvement (time in micros):
> 
> 
> Percentile Baseline Patch
> 50?%          23155 21149
> 75?%          23598 21454
> 90?%          23989 21691
> 95?%          24238 21973
> 99?%          25270 22446
> STDEV           792   549
> Count           500   500

Eirik Bjorsnos has updated the pull request incrementally with one additional commit since the last revision:

  Remove accidentally introduced trailing whitespace

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12290/files
  - new: https://git.openjdk.org/jdk/pull/12290/files/a633d270..21cdb732

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12290&range=10
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12290&range=09-10

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/12290.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12290/head:pull/12290

PR: https://git.openjdk.org/jdk/pull/12290

From redestad at openjdk.org  Tue Feb 14 09:21:42 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Tue, 14 Feb 2023 09:21:42 GMT
Subject: RFR: 8302163: Speed up various String comparison methods with
 ArraysSupport.mismatch [v2]
In-Reply-To: <xWaMFUc2e0SIQkuEzsV_pAAMvhXJn39gRLP1yDKLDHM=.58cc1b3f-6d38-4b66-be5a-e4ddc8502ad5@github.com>
References: <geAF-Q1dnCoJ0vCqMNHXXziVGii47nOkfyw5RTL_Wb0=.79392f23-0846-4e04-8b19-87289c3bf49f@github.com>
 <sLJArQhn8qKv67Op1gS-WMAnsXTJBqR_qWbdzApxOLc=.d225ea1e-1039-4492-877d-ede8b5a122b3@github.com>
 <xWaMFUc2e0SIQkuEzsV_pAAMvhXJn39gRLP1yDKLDHM=.58cc1b3f-6d38-4b66-be5a-e4ddc8502ad5@github.com>
Message-ID: <S_QL2ImWzqWbmGNRKo6E-Fhk7rmawmjMucoPgBkYhEA=.a5ad5146-1349-44d6-b5ab-e0cd06cc16bc@github.com>

On Mon, 13 Feb 2023 16:43:12 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

> Case-insensitive regionMatches could be improved by using ArraysSupport.mismatch to skip over long common substrings:

I considered this but saw regressions similar to what you're getting for size = 6 and backed off. I think this might be a good future enhancement, with some care, but didn't want to encumber this RFE with a case that regresses small inputs (which tend to be more common in actual applications).

In similar constructs we have avoided doing the vectorized call in a loop since this could regress worst case inputs severely (an adversary example might be something like `regionMatches(true, "aaaaaaaaaaaaaaaaaaaaaa", 0, "aAaAaAaAaAaAaAa", 0, 15)` which will call mismatch 8 times on 15 byte of input).

-------------

PR: https://git.openjdk.org/jdk/pull/12528

From sgehwolf at openjdk.org  Tue Feb 14 09:25:42 2023
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Tue, 14 Feb 2023 09:25:42 GMT
Subject: RFR: 8302337: JDK crashes if lib/modules contains non-zero byte
 containing ATTRIBUTE_END
In-Reply-To: <_CWXtQeW6BSDDDbMfJGm85_rYuX7mmsWip8th6JT7E8=.69ae1a60-bb36-4196-8199-2a5cf5f2d121@github.com>
References: <6FhVbMx6rkuODI7UDEQANI40yFzovg4pIlqXXPB2yRE=.5a1ed241-6da7-403a-a74b-2c315e94beae@github.com>
 <_CWXtQeW6BSDDDbMfJGm85_rYuX7mmsWip8th6JT7E8=.69ae1a60-bb36-4196-8199-2a5cf5f2d121@github.com>
Message-ID: <1Ed7b75TCsHgFFqrANrcuaFjz6uIAP1xT1Fbtv1j9tw=.9b29b5ac-067e-4a8b-a640-4d2962c74a7c@github.com>

On Mon, 13 Feb 2023 19:50:24 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> The change looks good, I'm just curious whether you observed a crash or whether this was noticed by inspection.

Noticed by exploration. Changed the java code on the jlink side and observed the crash.

-------------

PR: https://git.openjdk.org/jdk/pull/12539

From sgehwolf at openjdk.org  Tue Feb 14 09:25:44 2023
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Tue, 14 Feb 2023 09:25:44 GMT
Subject: RFR: 8302337: JDK crashes if lib/modules contains non-zero byte
 containing ATTRIBUTE_END
In-Reply-To: <6FhVbMx6rkuODI7UDEQANI40yFzovg4pIlqXXPB2yRE=.5a1ed241-6da7-403a-a74b-2c315e94beae@github.com>
References: <6FhVbMx6rkuODI7UDEQANI40yFzovg4pIlqXXPB2yRE=.5a1ed241-6da7-403a-a74b-2c315e94beae@github.com>
Message-ID: <6dyUD48hlQo1Ns2X6B3aCIxV_qXKef-JPwCdh8pO_YI=.b3da4444-2379-4152-b70d-fe5063a01f10@github.com>

On Mon, 13 Feb 2023 16:57:17 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

> The `jimage` location attributes are terminated with `ATTRIBUTE_END`-kinds. However,
> the byte containing `ATTRIBUTE_END` (most significant 5 bits, represent `kind`), might
> be non-zero in the lower 3 bits (values up to `0x07` represent `ATTRIBUTE_END`). The JDK code
> handles this case correctly in [`ImageLocation.decompress()`](https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/jdk/internal/jimage/ImageLocation.java#L69..L71). However, the `libjimage`
> code in `java.base` doesn't. That can lead to segfaults reading random bytes and offsets.
> 
> I propose to break the loop if `ATTRIBUTE_END` is being encountered so that reading stops.
> 
> Testing:
>  - [x] `test/jdk/tools/jimage` and `test/jdk/jdk/internal/jimage` tests.
>  - [x] Manual testing with a patched JDK to write non-zero bytes containing `ATTRIBUTE_END` into the jimage. Segfaults before, runs fine after.
>  - [x] GHA.
> 
> Thoughts?

Thanks for the reviews!

-------------

PR: https://git.openjdk.org/jdk/pull/12539

From sgehwolf at openjdk.org  Tue Feb 14 09:30:57 2023
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Tue, 14 Feb 2023 09:30:57 GMT
Subject: Integrated: 8302337: JDK crashes if lib/modules contains non-zero byte
 containing ATTRIBUTE_END
In-Reply-To: <6FhVbMx6rkuODI7UDEQANI40yFzovg4pIlqXXPB2yRE=.5a1ed241-6da7-403a-a74b-2c315e94beae@github.com>
References: <6FhVbMx6rkuODI7UDEQANI40yFzovg4pIlqXXPB2yRE=.5a1ed241-6da7-403a-a74b-2c315e94beae@github.com>
Message-ID: <tWDYZ4kaqcaIGbheWq74pib0-JFqDNNmUbiPcZsX6EI=.a7ef5ba0-8a32-4346-b94e-81718fd91590@github.com>

On Mon, 13 Feb 2023 16:57:17 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

> The `jimage` location attributes are terminated with `ATTRIBUTE_END`-kinds. However,
> the byte containing `ATTRIBUTE_END` (most significant 5 bits, represent `kind`), might
> be non-zero in the lower 3 bits (values up to `0x07` represent `ATTRIBUTE_END`). The JDK code
> handles this case correctly in [`ImageLocation.decompress()`](https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/jdk/internal/jimage/ImageLocation.java#L69..L71). However, the `libjimage`
> code in `java.base` doesn't. That can lead to segfaults reading random bytes and offsets.
> 
> I propose to break the loop if `ATTRIBUTE_END` is being encountered so that reading stops.
> 
> Testing:
>  - [x] `test/jdk/tools/jimage` and `test/jdk/jdk/internal/jimage` tests.
>  - [x] Manual testing with a patched JDK to write non-zero bytes containing `ATTRIBUTE_END` into the jimage. Segfaults before, runs fine after.
>  - [x] GHA.
> 
> Thoughts?

This pull request has now been integrated.

Changeset: ee5f6e15
Author:    Severin Gehwolf <sgehwolf at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/ee5f6e156de0fd3d78adf60951866f43c492725b
Stats:     3 lines in 1 file changed: 3 ins; 0 del; 0 mod

8302337: JDK crashes if lib/modules contains non-zero byte containing ATTRIBUTE_END

Reviewed-by: stuefe, jlaskey, alanb

-------------

PR: https://git.openjdk.org/jdk/pull/12539

From alanb at openjdk.org  Tue Feb 14 10:43:43 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 14 Feb 2023 10:43:43 GMT
Subject: RFR: 8302325: Wrong comment in
 java.base/share/native/libjimage/imageFile.hpp
In-Reply-To: <ThM7YJ5rlOnQWHBmPQGzPcQ-vrBiR_-OgJL46jeJIV8=.0e736e79-1fe3-40bb-8702-165028592e1c@github.com>
References: <ThM7YJ5rlOnQWHBmPQGzPcQ-vrBiR_-OgJL46jeJIV8=.0e736e79-1fe3-40bb-8702-165028592e1c@github.com>
Message-ID: <alhQYjnBkQR096TA7K9a3ccAfLEeDmpb2sbO4qogaxQ=.eea928e7-d61e-4387-ba33-9ca2e4d36692@github.com>

On Mon, 13 Feb 2023 14:12:15 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

> Could I please get a review of this trivial comment-only change? `imageFile.hpp`
> describes some properties of the jimage file `lib/modules`. However, I don't think
> the comment example matches current code in the JDK. [`ATTRIBUTE_OFFSET`](https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/jdk/internal/jimage/ImageLocation.java#L44) get
> written to the image file with value `0x05` while the comment mentions it gets
> written as `0x04`. I propose to fix the comment so that it matches the code.
> 
> In passing, I've also fixed a comment related to `ATTRIBUTE_END`. I think the point
> being made there is about byte values of `[0x01..0x07]`, all would represent
> `ATTRIBUTE_END`, as the upper `5` bits would be `0`. Therefore, byte `0x01` would equally
> represent `ATTRIBUTE_END` as would `0x00` and `0x07` or any value in between.
> 
> Thoughts?

kind = 5 looks right.  

Can you update the end date of the copyright headers as this is the first change in 2023. imageFile.cpp by missed by the other change so it could be done here too.

-------------

Marked as reviewed by alanb (Reviewer).

PR: https://git.openjdk.org/jdk/pull/12533

From redestad at openjdk.org  Tue Feb 14 10:48:43 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Tue, 14 Feb 2023 10:48:43 GMT
Subject: RFR: JDK-8300808: Accelerate Base64 on x86 for AVX2 [v15]
In-Reply-To: <ehO2yEksveYBx5vw4CknkfvlOBavIqt9y4FjqwcqWeU=.a8f22610-de5a-4ffc-bb81-b6d9557965cc@github.com>
References: <9zN3bjyMEikXYOlpjTy9_QPc-9usYiBJMUFdb-TaVrQ=.e8f65ce9-ac0f-4f8d-9c6b-b39ae1c26cd2@github.com>
 <TmYLe9RCiAqtfuyjU77R-faEEVpfmmUoQ89oyBCcEmM=.c6d2d68b-c37d-4c78-a8e4-af4b48df91a5@github.com>
 <ehO2yEksveYBx5vw4CknkfvlOBavIqt9y4FjqwcqWeU=.a8f22610-de5a-4ffc-bb81-b6d9557965cc@github.com>
Message-ID: <iNbfCRnFcg0P8SB-QTQ1M0uJLQY9j3Dnvtqk2AQRzZI=.e70d419d-edae-41ef-9031-b87a23fb1040@github.com>

On Fri, 10 Feb 2023 23:18:47 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> Scott Gibbons has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add URL to microbenchmark
>
> Marked as reviewed by redestad (Reviewer).

> @cl4es Can you please initiate the in-depth testing required for this fix? Thanks.

I've checked out the sources and fired off a sanity run of the first couple of tiers. Holding off on testing higher tiers until @sviswa7's concerns has been resolved.

-------------

PR: https://git.openjdk.org/jdk/pull/12126

From jvernee at openjdk.org  Tue Feb 14 10:57:42 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Tue, 14 Feb 2023 10:57:42 GMT
Subject: RFR: JDK-8301460: Clean up LambdaForm to reference BasicType enums
 directly
In-Reply-To: <yoiVWrNeX6OjlT-iQjAo6SoQWCZi-gcPlWUjK8YZoqc=.61908404-3f28-45cb-a351-aa315924b6c3@github.com>
References: <yoiVWrNeX6OjlT-iQjAo6SoQWCZi-gcPlWUjK8YZoqc=.61908404-3f28-45cb-a351-aa315924b6c3@github.com>
Message-ID: <XzzDPVE7xJjcLYIuAF0mJg_IcHj5GHhE5-cjoW55T5U=.ec648437-ff3a-44c8-bcad-82dd269a5a81@github.com>

On Mon, 13 Feb 2023 22:05:15 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> `LambdaForm` declares int constants for `BasicType::ordinal` to workaround JDK-8161245.   Now these int constants are no longer needed.    This removes these int constants and reference `BasicType` enums directly.

src/java.base/share/classes/java/lang/invoke/BoundMethodHandle.java line 371:

> 369:             extensions[typeNum] = sd;
> 370:             return sd;
> 371:         }

I suggest changing the existing overload to delegate to this one with `BasicType.basicType(typeNum)` as the argument. (or to use some other way to reduce the duplication)

-------------

PR: https://git.openjdk.org/jdk/pull/12546

From stsypanov at openjdk.org  Tue Feb 14 11:19:43 2023
From: stsypanov at openjdk.org (Sergey Tsypanov)
Date: Tue, 14 Feb 2023 11:19:43 GMT
Subject: RFR: JDK-8301460: Clean up LambdaForm to reference BasicType enums
 directly
In-Reply-To: <yoiVWrNeX6OjlT-iQjAo6SoQWCZi-gcPlWUjK8YZoqc=.61908404-3f28-45cb-a351-aa315924b6c3@github.com>
References: <yoiVWrNeX6OjlT-iQjAo6SoQWCZi-gcPlWUjK8YZoqc=.61908404-3f28-45cb-a351-aa315924b6c3@github.com>
Message-ID: <_6BI2LuBswWyn2rM4lMQOCQsT4vRxWbpWj0TylgE8U8=.ce889389-3f4b-4ef8-93a3-64db0f88cf1c@github.com>

On Mon, 13 Feb 2023 22:05:15 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> `LambdaForm` declares int constants for `BasicType::ordinal` to workaround JDK-8161245.   Now these int constants are no longer needed.    This removes these int constants and reference `BasicType` enums directly.

src/java.base/share/classes/java/lang/invoke/BoundMethodHandle.java line 368:

> 366:             SpeciesData sd = extensions[typeNum];
> 367:             if (sd != null)  return sd;
> 368:             sd = SPECIALIZER.findSpecies(key() + basicType.basicTypeChar());

As soon as this is `java.base` I suggest to replace `key() + basicType.basicTypeChar()` with `key().concat(String.valueOf(basicType.basicTypeChar()))` to prevent `StringBuilder` allocation and `append()` chaining.

-------------

PR: https://git.openjdk.org/jdk/pull/12546

From lancea at openjdk.org  Tue Feb 14 11:24:48 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Tue, 14 Feb 2023 11:24:48 GMT
Subject: RFR: 8301873: Avoid string decoding in ZipFile.Source.getEntryPos
 [v9]
In-Reply-To: <JZnpNuDyzOuST2FenNqvlLCRH-mhjTJRrynIXNpXG6s=.73106c41-38d5-4156-8e1b-4a86c52d030d@github.com>
References: <FkmdspiHVjkAKFqm5kUgwaf55YH5cBbczS_3krqsdFs=.05eca901-f55f-47d9-b1bc-0cf2f5b87536@github.com>
 <p2-revzHDap8mmK22cZnmfocoxjzMZgOWsQX2p8iLYo=.2f9cfa42-46ca-4527-9b4a-103dd06fcdc3@github.com>
 <3fZ6eVyW0fQ2QLZhOG5PyO5nBQ0CqlWt1p41Y2Xtjd4=.2acab1ed-7086-4030-869f-b324b640ea77@github.com>
 <JZnpNuDyzOuST2FenNqvlLCRH-mhjTJRrynIXNpXG6s=.73106c41-38d5-4156-8e1b-4a86c52d030d@github.com>
Message-ID: <hT1xmxAHP7Rg53Tf_XhCABe-gNiaE2CaqoTwYSAAsZw=.fe11d665-0206-4457-8c64-2665e388219c@github.com>

On Tue, 14 Feb 2023 08:47:15 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

>> test/jdk/java/util/zip/ZipFile/InvalidBytesInEntryNameOrComment.java line 90:
>> 
>>> 88:             expectedExceptionsMessageRegExp = BAD_ENTRY_NAME_OR_COMMENT)
>>> 89:     public void shouldRejectInvalidName() throws IOException {
>>> 90:         try (ZipFile zf = new ZipFile(invalidName.toFile())) {
>> 
>> If you could please convert to use `expectThrows` to get to validate the message name
>
> The message is already validated using `expectedExceptionsMessageRegExp` in the `@Test` annotation.
> 
> Would you prefer if I use expectThrows instead, or perhaps inline the `BAD_ENTRY_NAME_OR_COMMENT` constant as a literal?

Sorry if this was not clear,  we have gone away from using the annotation element `exepectedExceptions` for new and updated tests and  have tried to standardize on `assertThrows` and  `expectThrows` instead which is the basis for my suggestion.


Thank you for your other updates.  I will go through them later today

-------------

PR: https://git.openjdk.org/jdk/pull/12290

From duke at openjdk.org  Tue Feb 14 11:49:23 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Tue, 14 Feb 2023 11:49:23 GMT
Subject: RFR: 8301873: Avoid string decoding in ZipFile.Source.getEntryPos
 [v12]
In-Reply-To: <FkmdspiHVjkAKFqm5kUgwaf55YH5cBbczS_3krqsdFs=.05eca901-f55f-47d9-b1bc-0cf2f5b87536@github.com>
References: <FkmdspiHVjkAKFqm5kUgwaf55YH5cBbczS_3krqsdFs=.05eca901-f55f-47d9-b1bc-0cf2f5b87536@github.com>
Message-ID: <Jm8UwXfOkwCmOyEgHBg1TdID9KsbFNVnqfRwKwkKmQE=.cc5bdbe5-0724-4562-b6b1-ab11ce587580@github.com>

> After finding a hash match, getEntryPos needs to compare the lookup name up to the encoded entry name in the CEN. This comparison is done by decoding the entry name into a String. The names can then be compared using the String API. This decoding step adds a significat cost to this method.
> 
> This PR suggest to update the string comparison such that in the common case where  both the lookup name and the entry name are encoded in ASCII-compatible UTF-8,  decoding can be avoided and the byte arrays can instead be compared direcly. 
> 
> ZipCoder is updated with a new method to compare a string with an encoded byte array range.  The default implementation decodes to string (like the current code), while the UTF-8 implementation uses JavaLangAccess.getBytesNoRepl to get the  bytes. Both methods thes uses Arrays.mismatch for comparison with or without matching trailing slashes. 
> 
> Additionally, this PR suggest to make the following updates to getEntryPos:
> 
> - The try/catch for IAE is redundant and can be safely removed. (initCEN already checks this and will throws IAE for invalid UTF-8). This seems to give a 3-4% speedup on micros)
> - A new test InvalidBytesInEntryNameOrComment is a added to verify that initCEN does in fact reject invalid UTF-8 in CEN file names and comments. (I found no existing test coverage for this)
> - The recursion when looking for "name/" matches is replaced with iteration. We keep track of any "name/" match and return it at the end of the search. (I feel this is easier to follow and it also gives a ~30% speedup for addSlash lookups with no regression on regular lookups)
> 
> (My though is that including these additional updates in this PR might reduce reviewer overhead given that it touches the exact same code. I might be wrong on this, please advise :)
> 
> I'm seeing a ~17% saving on the micro ZipFileGetEntry.getEntryHit (modified to use xalan.jar):
> 
> Baseline:
> 
> Benchmark                             (size)  Mode  Cnt    Score   Error  Units
> ZipFileGetEntry.getEntryHit              512  avgt   15   74.941 ? 1.004  ns/op
> ZipFileGetEntry.getEntryHit             1024  avgt   15   84.943 ? 1.320  ns/op
> ZipFileGetEntry.getEntryHitUncached      512  avgt   15  120.371 ? 2.386  ns/op
> ZipFileGetEntry.getEntryHitUncached     1024  avgt   15  126.128 ? 1.075  ns/op
> ZipFileGetEntry.getEntryMiss             512  avgt   15   23.818 ? 0.838  ns/op
> ZipFileGetEntry.getEntryMiss            1024  avgt   15   29.762 ? 5.998  ns/op
> ZipFileGetEntry.getEntryMissUncached     512  avgt   15   59.405 ? 0.545  ns/op
> ZipFileGetEntry.getEntryMissUncached    1024  avgt   15   71.840 ? 2.455  ns/op
> ZipFileGetEntry.getEntrySlash            512  avgt   15  135.621 ? 4.341  ns/op
> ZipFileGetEntry.getEntrySlash           1024  avgt   15  134.190 ? 2.141  ns/op
> 
> 
> 
> PR:
> 
> 
> Benchmark                             (size)  Mode  Cnt    Score   Error  Units
> ZipFileGetEntry.getEntryHit              512  avgt   15   62.267 ? 1.329  ns/op
> ZipFileGetEntry.getEntryHit             1024  avgt   15   72.916 ? 2.428  ns/op
> ZipFileGetEntry.getEntryHitUncached      512  avgt   15  101.630 ? 1.154  ns/op
> ZipFileGetEntry.getEntryHitUncached     1024  avgt   15  113.161 ? 0.502  ns/op
> ZipFileGetEntry.getEntryMiss             512  avgt   15   23.003 ? 1.191  ns/op
> ZipFileGetEntry.getEntryMiss            1024  avgt   15   23.236 ? 1.114  ns/op
> ZipFileGetEntry.getEntryMissUncached     512  avgt   15   56.781 ? 1.505  ns/op
> ZipFileGetEntry.getEntryMissUncached    1024  avgt   15   67.767 ? 1.963  ns/op
> ZipFileGetEntry.getEntrySlash            512  avgt   15   73.745 ? 2.717  ns/op
> ZipFileGetEntry.getEntrySlash           1024  avgt   15   75.784 ? 1.051  ns/op
> 
> 
> To assess the impact on startup/warmup, I made a main method class which measures the total time of calling ZipFile.getEntry for all entries in the 109 JAR file dependenies of spring-petclinic. The shows a nice improvement (time in micros):
> 
> 
> Percentile Baseline Patch
> 50?%          23155 21149
> 75?%          23598 21454
> 90?%          23989 21691
> 95?%          24238 21973
> 99?%          25270 22446
> STDEV           792   549
> Count           500   500

Eirik Bjorsnos has updated the pull request incrementally with one additional commit since the last revision:

  Prefer expectThrows with asserts over test annotation regex

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12290/files
  - new: https://git.openjdk.org/jdk/pull/12290/files/21cdb732..4981abd3

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12290&range=11
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12290&range=10-11

  Stats: 18 lines in 1 file changed: 7 ins; 1 del; 10 mod
  Patch: https://git.openjdk.org/jdk/pull/12290.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12290/head:pull/12290

PR: https://git.openjdk.org/jdk/pull/12290

From alanb at openjdk.org  Tue Feb 14 12:40:47 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 14 Feb 2023 12:40:47 GMT
Subject: RFR: 8302260: VarHandle.describeConstable() fails to return a
 nominal descriptor for static public fields
In-Reply-To: <fPx38HtLOHB5dvr9_Z2wFKYKLNsjFIIwExNreo3pHxw=.53c3792d-db7b-42d6-b858-5c3062a57a4f@github.com>
References: <fPx38HtLOHB5dvr9_Z2wFKYKLNsjFIIwExNreo3pHxw=.53c3792d-db7b-42d6-b858-5c3062a57a4f@github.com>
Message-ID: <-aAKWBPmj2jLTlH3RqadM3Fjtg3OpNYSdc2eRYcR5-4=.2da80233-85e3-4e38-8220-984fc2623a99@github.com>

On Mon, 13 Feb 2023 19:35:52 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> I overlooked in the fix for JDK-8297757 that it should have passed the declaring class of the static fields rather than the reference class passed to `Lookup::findStaticVarHandle`.

Looks right and you've added good test coverage.

test/jdk/java/lang/invoke/VarHandles/describeConstable/DescribeConstableTest.java line 53:

> 51:                 // resolved to the one defined in the direct superinterface of C
> 52:                 Arguments.of(p.C.class, "stringField", String.class, p.I.class, "I"),
> 53:                 Arguments.of(p.C.class, "longField", long.class, p.I.class, 10L),

This looks right - when not declared in p.C, it should look next in the direct superinterfaces before looking in the super classes.

-------------

Marked as reviewed by alanb (Reviewer).

PR: https://git.openjdk.org/jdk/pull/12543

From dfuchs at openjdk.org  Tue Feb 14 13:13:44 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 14 Feb 2023 13:13:44 GMT
Subject: RFR: 8301627: System.exit and Runtime.exit debug logging [v2]
In-Reply-To: <-9o7wGKkaBfP4CC_Hq0pkq5GxWBmPNgloyCsC_J5198=.b02971fc-2d28-4c9c-8450-9b626371e5bc@github.com>
References: <OzJeJH5yxolKPChcUisqtzGYF_MU3oOJdx6HPhsXjBw=.15eefe39-efe1-433e-a6ac-02b4a730f264@github.com>
 <2zbWTodXVENcsxo-J5IcBLxQoHqnIdtmB4TnV5w7Uag=.d4aa5964-5e0e-41b5-b6f9-39f4edb1b2b4@github.com>
 <fpoG44CoHxj8JXmx6ry-xdQK2HFfj02RBdT3S9NrIs0=.cdf07271-43a0-4fc4-a10e-545ed4e92492@github.com>
 <-9o7wGKkaBfP4CC_Hq0pkq5GxWBmPNgloyCsC_J5198=.b02971fc-2d28-4c9c-8450-9b626371e5bc@github.com>
Message-ID: <gc5GudGVxSv91oWgw0xMp8CWmJ1Xk2PNm0H7jK0FDXM=.e4d91043-d905-46db-9da9-917cec7c9787@github.com>

On Tue, 14 Feb 2023 07:45:07 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> FINE is not a level supported by the System.Logger, it is the level to which DEBUG is mapped when the backend is java.util.logging. I suggest to remove FINE from this description and add an `{@link Loger.Level#DEBUG DEBUG}` around DEBUG.
>
> Roger has updated this but it's still a comment on a non-public class. I think the main question here is whether there should be a note in the System.exit and Runtime.exit to document that these methods log? If not, will it be documented anywhere, maybe a troubleshooting guide to help track down what/who is calling System.exit?

Another way to document that could be to add the commented logger name, and  a comment, to https://github.com/openjdk/jdk/blob/master/src/java.logging/share/conf/logging.properties 
A new section at the end with some explanation on what this logger prints and how to enable it - with the appropriate wording to make it clear that it's JDK-implementation specific and not part of the spec.

-------------

PR: https://git.openjdk.org/jdk/pull/12517

From rgiulietti at openjdk.org  Tue Feb 14 13:16:43 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Tue, 14 Feb 2023 13:16:43 GMT
Subject: RFR: JDK-8302026: Port fdlibm inverse trig functions (asin, acos, 
 atan) to Java
In-Reply-To: <4gBqg3J25LASN6tnRwZ22S3YlUHQrypgvZqynfKd3Os=.3a5e618f-b7eb-4978-a6ab-f1b30c793fb4@github.com>
References: <4gBqg3J25LASN6tnRwZ22S3YlUHQrypgvZqynfKd3Os=.3a5e618f-b7eb-4978-a6ab-f1b30c793fb4@github.com>
Message-ID: <dGiCN-ktIj4Ubs0J7i5CKxIO4jvU9Jh5EFMKL8hIkgw=.50e69824-bfc1-4e2a-b79e-ea15f3eea423@github.com>

On Mon, 13 Feb 2023 22:03:14 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Proceeding down the line of FDLIBM functions to be ported, next up are asin, acos, and atan.
> 
> Diffs of the various versions will follow in a separate message.
> 
> There were no unusual coding idioms encountered in porting these methods.

Otherwise LGTM

test/jdk/java/lang/StrictMath/InverseTrigTests.java line 96:

> 94: 
> 95:                0.975,
> 96:               -0.975,

I think other decision points for asin are 2**-27 and -2**-27 (0x1p-27 and -0x1p-27)

-------------

PR: https://git.openjdk.org/jdk/pull/12545

From sgehwolf at openjdk.org  Tue Feb 14 14:00:45 2023
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Tue, 14 Feb 2023 14:00:45 GMT
Subject: RFR: 8302325: Wrong comment in
 java.base/share/native/libjimage/imageFile.hpp
In-Reply-To: <alhQYjnBkQR096TA7K9a3ccAfLEeDmpb2sbO4qogaxQ=.eea928e7-d61e-4387-ba33-9ca2e4d36692@github.com>
References: <ThM7YJ5rlOnQWHBmPQGzPcQ-vrBiR_-OgJL46jeJIV8=.0e736e79-1fe3-40bb-8702-165028592e1c@github.com>
 <alhQYjnBkQR096TA7K9a3ccAfLEeDmpb2sbO4qogaxQ=.eea928e7-d61e-4387-ba33-9ca2e4d36692@github.com>
Message-ID: <9AHmwdai9fhlrPkre39xWKeoOOGxREeN4Nd-5BePiKA=.b405a54d-e3f2-4d5a-900f-df749bf03fe7@github.com>

On Tue, 14 Feb 2023 10:40:31 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> Can you update the end date of the copyright headers as this is the first change in 2023. imageFile.cpp by missed by the other change so it could be done here too.

Absolutely! Thanks for the review.

-------------

PR: https://git.openjdk.org/jdk/pull/12533

From rgiulietti at openjdk.org  Tue Feb 14 14:10:02 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Tue, 14 Feb 2023 14:10:02 GMT
Subject: RFR: 8205592: BigDecimal.doubleValue() is depressingly slow
In-Reply-To: <C_RUmXLqH-qrTwIQOb_qSS7JMw-LF66lnVPsHMfMV_A=.29c2a24b-1879-49f0-86fa-39150ff9b29c@github.com>
References: <XpbHjLD13akVXWMOh0CVfH3ZjWeWLzMenrJ0UxjMO5I=.03ec2741-0762-459d-b27a-3cc022a48a19@github.com>
 <C_RUmXLqH-qrTwIQOb_qSS7JMw-LF66lnVPsHMfMV_A=.29c2a24b-1879-49f0-86fa-39150ff9b29c@github.com>
Message-ID: <jYO06nlR_3xtNyUrSd-mJFuLutahDwanEi95Zm-rbuY=.d79c1ec7-dd19-45bc-9833-40fa05e5a0b4@github.com>

On Tue, 14 Feb 2023 08:02:08 GMT, Andriy Plokhotnyuk <duke at openjdk.org> wrote:

>> A reimplementation of `BigDecimal.[double|float]Value()` to enhance performance, avoiding an intermediate string and its subsequent parsing on the slow path.
>
> Sorry, I overlooked those checks two times :)
> 
> How about adding a moderate path like [this](https://github.com/plokhotnyuk/jsoniter-scala/blob/6f702ce5cae05df91b5aa6e4bd61acdf43bf18f6/jsoniter-scala-core/jvm/src/main/scala/com/github/plokhotnyuk/jsoniter_scala/core/JsonReader.scala#L1467-L1498)?
> 
> I think it worth do be reused for regular parsing of `double` and `float` values from `String`.

@plokhotnyuk The main goal of this PR is to avoid generating a string and parse it, as it happens in the current implementation. The fact that it results in being faster is only a welcome byproduct.

The proposed patch for `doubleValue()` is only about 40 lines of code, not counting `}`-only lines and the _extensive comments_ explaining the details for the benefit of both reviewers and maintainers. Shorter, documented code has a higher chance to be correct and understood. It also contributes to simpler and quicker reviewing.

Adding the "moderate path" to this patch would increase the code size considerably. Moreover, I would have to invest time to understand the dense, uncommented code and convince myself and the reviewers that it is correct. I would also have to setup benchmarks to measure the overall benefits of adding it to the proposed patch. And add specific tests to cover the path.

Before that, I would prefer for this patch to be first reviewed as it is (with possible corrections). I hope to have time to invest into your proposals _once_ this PR is integrated into mainline. Thanks for your patience.

-------------

PR: https://git.openjdk.org/jdk/pull/9410

From rrich at openjdk.org  Tue Feb 14 14:22:32 2023
From: rrich at openjdk.org (Richard Reingruber)
Date: Tue, 14 Feb 2023 14:22:32 GMT
Subject: RFR: 8302158: PPC: test/jdk/jdk/internal/vm/Continuation/Fuzz.java:
 AssertionError: res: false shouldPin: false
Message-ID: <G-cEPYqp6JlMkj9qo0S9HuNXRiuROZ7q69FQYIsDewM=.d20f3ee3-ed25-4bd3-93cd-2a55faa515d3@github.com>

This fixes the linked issue by trimming the caller of a frame to be deoptimized back to its `unextended_sp` iff it is compiled. The creation of the section `dead after deoptimization` shown in the attachment [yield_after_deopt_failure.log](https://bugs.openjdk.org/secure/attachment/102602/yield_after_deopt_failure.log) is prevented by this.

A new mode is added to the test BasicExt.java where all frames are deoptimized after a yield operation. The issue can be deterministically reproduced with the new mode. It's not worth to execute all test cases with the new mode though. Instead `ContinuationCompiledFramesWithStackArgs_3c4` is always executed a 2nd time in this mode.

Before this BasicExt.java was refactored for better argument processing and representation of the test modes.
Also the try-catch-clause in the main method had to be changed to rethrow the caught exception because without this the test would have succeeded.

Testing: jtreg tests tier 1-4 on standard platforms and also on ppc64le.

-------------

Commit messages:
 - Trimm compiled caller of deoptee to unextended sp
 - Deoptimize after yield
 - BasicExt.java test: use enums for parameters
 - BasicExt.java test: rethrow caught exception to indicate failure

Changes: https://git.openjdk.org/jdk/pull/12557/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12557&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8302158
  Stats: 203 lines in 3 files changed: 148 ins; 13 del; 42 mod
  Patch: https://git.openjdk.org/jdk/pull/12557.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12557/head:pull/12557

PR: https://git.openjdk.org/jdk/pull/12557

From duke at openjdk.org  Tue Feb 14 14:44:06 2023
From: duke at openjdk.org (Andriy Plokhotnyuk)
Date: Tue, 14 Feb 2023 14:44:06 GMT
Subject: RFR: 8205592: BigDecimal.doubleValue() is depressingly slow
In-Reply-To: <jYO06nlR_3xtNyUrSd-mJFuLutahDwanEi95Zm-rbuY=.d79c1ec7-dd19-45bc-9833-40fa05e5a0b4@github.com>
References: <XpbHjLD13akVXWMOh0CVfH3ZjWeWLzMenrJ0UxjMO5I=.03ec2741-0762-459d-b27a-3cc022a48a19@github.com>
 <C_RUmXLqH-qrTwIQOb_qSS7JMw-LF66lnVPsHMfMV_A=.29c2a24b-1879-49f0-86fa-39150ff9b29c@github.com>
 <jYO06nlR_3xtNyUrSd-mJFuLutahDwanEi95Zm-rbuY=.d79c1ec7-dd19-45bc-9833-40fa05e5a0b4@github.com>
Message-ID: <Z6JH-UqDghxdLRoDmKxvu8KyHwHDOFTr6e3LFTJy7W8=.0037cf98-4a4f-4559-b986-a18495468ae3@github.com>

On Tue, 14 Feb 2023 14:07:22 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> Sorry, I overlooked those checks two times :)
>> 
>> How about adding a moderate path like [this](https://github.com/plokhotnyuk/jsoniter-scala/blob/6f702ce5cae05df91b5aa6e4bd61acdf43bf18f6/jsoniter-scala-core/jvm/src/main/scala/com/github/plokhotnyuk/jsoniter_scala/core/JsonReader.scala#L1467-L1498)?
>> 
>> I think it worth do be reused for regular parsing of `double` and `float` values from `String`.
>
> @plokhotnyuk The main goal of this PR is to avoid generating a string and parse it, as it happens in the current implementation. The fact that it results in being faster is only a welcome byproduct.
> 
> The proposed patch for `doubleValue()` is only about 40 lines of code, not counting `}`-only lines and the _extensive comments_ explaining the details for the benefit of both reviewers and maintainers. Shorter, documented code has a higher chance to be correct and understood. It also contributes to simpler and quicker reviewing.
> 
> Adding the "moderate path" to this patch would increase the code size considerably. Moreover, I would have to invest time to understand the dense, uncommented code and convince myself and the reviewers that it is correct. I would also have to setup benchmarks to measure the overall benefits of adding it to the proposed patch. And add specific tests to cover the path.
> 
> Before that, I would prefer for this patch to be first reviewed as it is (with possible corrections). I hope to have time to invest into your proposals _once_ this PR is integrated into mainline. Thanks for your patience.

@rgiulietti Thanks for the explanation!

I wish faster reviews of all your PRs!

I bet that investigation of the moderate path will pay itself when that path will be reused for improving `java.lang.Double.parseDouble` and `java.lang.Float.parseFloat` methods. 

You can roughly estimate the moderate path speed up comparing the throughput of `borer` and `jsoniterScala` in the following chart. Both of them use the same fast path and fallback to `java.lang.Double.parseDouble`, the difference is that `jsoniterScala` (and `smithy4sJson` that is based on it) adds using of the moderate path:

![image](https://user-images.githubusercontent.com/890289/218768844-86d53c5f-2b4e-4326-80ae-b6301ee3c67f.png)

BTW, the `jacksonScala` uses a Java port of Daniel Lemire's [fast_float](https://github.com/fastfloat/fast_float) project.

-------------

PR: https://git.openjdk.org/jdk/pull/9410

From sgehwolf at openjdk.org  Tue Feb 14 14:46:58 2023
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Tue, 14 Feb 2023 14:46:58 GMT
Subject: RFR: 8302325: Wrong comment in
 java.base/share/native/libjimage/imageFile.hpp [v2]
In-Reply-To: <ThM7YJ5rlOnQWHBmPQGzPcQ-vrBiR_-OgJL46jeJIV8=.0e736e79-1fe3-40bb-8702-165028592e1c@github.com>
References: <ThM7YJ5rlOnQWHBmPQGzPcQ-vrBiR_-OgJL46jeJIV8=.0e736e79-1fe3-40bb-8702-165028592e1c@github.com>
Message-ID: <0zF_Y3qKCBInYGcvZGallODqvrY4Dg92Wxv8AU8Apio=.ae890b59-6a2a-4bcd-adbc-2468e76dc631@github.com>

> Could I please get a review of this trivial comment-only change? `imageFile.hpp`
> describes some properties of the jimage file `lib/modules`. However, I don't think
> the comment example matches current code in the JDK. [`ATTRIBUTE_OFFSET`](https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/jdk/internal/jimage/ImageLocation.java#L44) get
> written to the image file with value `0x05` while the comment mentions it gets
> written as `0x04`. I propose to fix the comment so that it matches the code.
> 
> In passing, I've also fixed a comment related to `ATTRIBUTE_END`. I think the point
> being made there is about byte values of `[0x01..0x07]`, all would represent
> `ATTRIBUTE_END`, as the upper `5` bits would be `0`. Therefore, byte `0x01` would equally
> represent `ATTRIBUTE_END` as would `0x00` and `0x07` or any value in between.
> 
> 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 three additional commits since the last revision:

 - Merge branch 'master' into jdk-8302325-imageFile
 - Copyright dates updated.
 - 8302325: Wrong comment in java.base/share/native/libjimage/imageFile.hpp

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12533/files
  - new: https://git.openjdk.org/jdk/pull/12533/files/bce5bb55..94b3d7e7

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12533&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12533&range=00-01

  Stats: 61035 lines in 1315 files changed: 25365 ins; 16637 del; 19033 mod
  Patch: https://git.openjdk.org/jdk/pull/12533.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12533/head:pull/12533

PR: https://git.openjdk.org/jdk/pull/12533

From sgehwolf at openjdk.org  Tue Feb 14 15:11:14 2023
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Tue, 14 Feb 2023 15:11:14 GMT
Subject: RFR: 8302325: Wrong comment in
 java.base/share/native/libjimage/imageFile.hpp [v2]
In-Reply-To: <alhQYjnBkQR096TA7K9a3ccAfLEeDmpb2sbO4qogaxQ=.eea928e7-d61e-4387-ba33-9ca2e4d36692@github.com>
References: <ThM7YJ5rlOnQWHBmPQGzPcQ-vrBiR_-OgJL46jeJIV8=.0e736e79-1fe3-40bb-8702-165028592e1c@github.com>
 <alhQYjnBkQR096TA7K9a3ccAfLEeDmpb2sbO4qogaxQ=.eea928e7-d61e-4387-ba33-9ca2e4d36692@github.com>
Message-ID: <-O3D1wFtJ7hYJXCEqbTBrdZqCKxx2Oatb0vUXQx9ea8=.efa041d9-033c-4296-b844-55d1901870a6@github.com>

On Tue, 14 Feb 2023 10:40:31 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Severin Gehwolf has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
>> 
>>  - Merge branch 'master' into jdk-8302325-imageFile
>>  - Copyright dates updated.
>>  - 8302325: Wrong comment in java.base/share/native/libjimage/imageFile.hpp
>
> kind = 5 looks right.  
> 
> Can you update the end date of the copyright headers as this is the first change in 2023. imageFile.cpp by missed by the other change so it could be done here too.

@AlanBateman Is that what you meant?

-------------

PR: https://git.openjdk.org/jdk/pull/12533

From sgibbons at openjdk.org  Tue Feb 14 15:11:45 2023
From: sgibbons at openjdk.org (Scott Gibbons)
Date: Tue, 14 Feb 2023 15:11:45 GMT
Subject: RFR: JDK-8300808: Accelerate Base64 on x86 for AVX2 [v16]
In-Reply-To: <9zN3bjyMEikXYOlpjTy9_QPc-9usYiBJMUFdb-TaVrQ=.e8f65ce9-ac0f-4f8d-9c6b-b39ae1c26cd2@github.com>
References: <9zN3bjyMEikXYOlpjTy9_QPc-9usYiBJMUFdb-TaVrQ=.e8f65ce9-ac0f-4f8d-9c6b-b39ae1c26cd2@github.com>
Message-ID: <KUgZFWyuHNuqK2c1rGo6_sWV0uAaHtRziQIi33UYkEU=.8a6c0b51-c247-4a71-a992-19455205b395@github.com>

> Added code for Base64 acceleration (encode and decode) which will accelerate ~4x for AVX2 platforms.
> 
> Encode performance:
> **Old:**
> 
> Benchmark                      (maxNumBytes)   Mode  Cnt     Score   Error   Units
> Base64Encode.testBase64Encode           1024  thrpt    3  4309.439 ? 2.632  ops/ms
> 
> 
> **New:**
> 
> Benchmark                      (maxNumBytes)   Mode  Cnt      Score     Error   Units
> Base64Encode.testBase64Encode           1024  thrpt    3  24211.397 ? 102.026  ops/ms
> 
> 
> Decode performance:
> **Old:**
> 
> Benchmark                      (errorIndex)  (lineSize)  (maxNumBytes)   Mode  Cnt     Score    Error   Units
> Base64Decode.testBase64Decode           144           4           1024  thrpt    3  3961.768 ? 93.409  ops/ms
> 
> **New:**
> Benchmark                      (errorIndex)  (lineSize)  (maxNumBytes)   Mode  Cnt      Score    Error   Units
> Base64Decode.testBase64Decode           144           4           1024  thrpt    3  14738.051 ? 24.383  ops/ms

Scott Gibbons has updated the pull request incrementally with one additional commit since the last revision:

  Branch around for very small buffers

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12126/files
  - new: https://git.openjdk.org/jdk/pull/12126/files/424b40d7..5077b4e8

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12126&range=15
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12126&range=14-15

  Stats: 11 lines in 1 file changed: 5 ins; 3 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/12126.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12126/head:pull/12126

PR: https://git.openjdk.org/jdk/pull/12126

From sgibbons at openjdk.org  Tue Feb 14 15:11:53 2023
From: sgibbons at openjdk.org (Scott Gibbons)
Date: Tue, 14 Feb 2023 15:11:53 GMT
Subject: RFR: JDK-8300808: Accelerate Base64 on x86 for AVX2 [v15]
In-Reply-To: <4LXDemRbOxX-JiiDgh14WTZ9mc5VwbRLz4KjfxS29Cw=.9c16ea8e-dd1c-4aa3-a6f1-4736f3515edb@github.com>
References: <9zN3bjyMEikXYOlpjTy9_QPc-9usYiBJMUFdb-TaVrQ=.e8f65ce9-ac0f-4f8d-9c6b-b39ae1c26cd2@github.com>
 <TmYLe9RCiAqtfuyjU77R-faEEVpfmmUoQ89oyBCcEmM=.c6d2d68b-c37d-4c78-a8e4-af4b48df91a5@github.com>
 <4LXDemRbOxX-JiiDgh14WTZ9mc5VwbRLz4KjfxS29Cw=.9c16ea8e-dd1c-4aa3-a6f1-4736f3515edb@github.com>
Message-ID: <-cgyVapky014oQOVjAUNJKLMXsppjXLvP4KiglJzKo4=.4818efca-5200-48fa-81ec-f6a812c5dc8e@github.com>

On Tue, 14 Feb 2023 01:48:37 GMT, Sandhya Viswanathan <sviswanathan at openjdk.org> wrote:

>> Scott Gibbons has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add URL to microbenchmark
>
> src/hotspot/cpu/x86/stubGenerator_x86_64.cpp line 2399:
> 
>> 2397:      VM_Version::supports_avx512bw()) {
>> 2398:     __ cmpl(length, 31);     // 32-bytes is break-even for AVX-512
>> 2399:     __ jcc(Assembler::lessEqual, L_bruteForce);
> 
> The avx2 code needs the length to be atleast 0x2c (44) bytes. We could directly go to non-avx code instead of L_bruteForce here. We will save one subtract/branch.

Done.

> src/hotspot/cpu/x86/stubGenerator_x86_64.cpp line 2658:
> 
>> 2656:     // Check for buffer too small (for algorithm)
>> 2657:     __ subl(length, 0x2c);
>> 2658:     __ jcc(Assembler::lessEqual, L_tailProc);
> 
> This could be Assembler::less instead of Assembler::lessEqual.

Why?  There is no performance difference and the intent is clear.  Is this just a "style" thing?

> src/hotspot/cpu/x86/stubGenerator_x86_64.cpp line 2699:
> 
>> 2697:     __ addptr(dest, 0x18);
>> 2698:     __ subl(length, 0x20);
>> 2699:     __ jcc(Assembler::lessEqual, L_tailProc);
> 
> This could be Assembler::less instead of Assembler::lessEqual.

Why?  There is no performance difference and the intent is clear.  Is this just a "style" thing?

-------------

PR: https://git.openjdk.org/jdk/pull/12126

From redestad at openjdk.org  Tue Feb 14 15:22:08 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Tue, 14 Feb 2023 15:22:08 GMT
Subject: RFR: JDK-8300808: Accelerate Base64 on x86 for AVX2 [v15]
In-Reply-To: <-cgyVapky014oQOVjAUNJKLMXsppjXLvP4KiglJzKo4=.4818efca-5200-48fa-81ec-f6a812c5dc8e@github.com>
References: <9zN3bjyMEikXYOlpjTy9_QPc-9usYiBJMUFdb-TaVrQ=.e8f65ce9-ac0f-4f8d-9c6b-b39ae1c26cd2@github.com>
 <TmYLe9RCiAqtfuyjU77R-faEEVpfmmUoQ89oyBCcEmM=.c6d2d68b-c37d-4c78-a8e4-af4b48df91a5@github.com>
 <4LXDemRbOxX-JiiDgh14WTZ9mc5VwbRLz4KjfxS29Cw=.9c16ea8e-dd1c-4aa3-a6f1-4736f3515edb@github.com>
 <-cgyVapky014oQOVjAUNJKLMXsppjXLvP4KiglJzKo4=.4818efca-5200-48fa-81ec-f6a812c5dc8e@github.com>
Message-ID: <J0sbVbTduhigUOziSshLGjoRYzPFy6fZtuf7_Vq7j8I=.5b6a6e42-fc3c-4895-ae8f-1fe7e4c28e29@github.com>

On Tue, 14 Feb 2023 15:03:50 GMT, Scott Gibbons <sgibbons at openjdk.org> wrote:

>> src/hotspot/cpu/x86/stubGenerator_x86_64.cpp line 2699:
>> 
>>> 2697:     __ addptr(dest, 0x18);
>>> 2698:     __ subl(length, 0x20);
>>> 2699:     __ jcc(Assembler::lessEqual, L_tailProc);
>> 
>> This could be Assembler::less instead of Assembler::lessEqual.
>
> Why?  There is no performance difference and the intent is clear.  Is this just a "style" thing?

I think with `lessEqual` we'll jump to `L_tailProc` for the final 32-byte chunk in inputs that are divisible by 32 (starting from 64), no? Using `less` avoids that, while not affecting performance of any other inputs.

-------------

PR: https://git.openjdk.org/jdk/pull/12126

From bpb at openjdk.org  Tue Feb 14 16:34:00 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 14 Feb 2023 16:34:00 GMT
Subject: Integrated: 8297632: InputStream.transferTo() method should specify
 what the return value should be when the number of bytes transfered is larger
 than Long.MAX_VALUE
In-Reply-To: <T38kO1hcz3rhpqOOPYmoPl1TlRORJBifQWtXLl10x8Y=.595338d3-df98-4202-95b5-eda88a4ed0a2@github.com>
References: <T38kO1hcz3rhpqOOPYmoPl1TlRORJBifQWtXLl10x8Y=.595338d3-df98-4202-95b5-eda88a4ed0a2@github.com>
Message-ID: <rgEK5LxkhgaTqxNbNBI0EcY2jeqDwV6-Sxr_U-TgK80=.08b6910b-908f-43ba-b4c1-dbc1a0441de5@github.com>

On Tue, 29 Nov 2022 00:56:58 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> `java.io.InputStream::transferTo` could conceivably return a negative value if the count of bytes transferred overflows a `long`. Modify the method to limit the number of bytes transferred to `Long.MAX_VALUE` per invocation.

This pull request has now been integrated.

Changeset: 5b2d4301
Author:    Brian Burkhalter <bpb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/5b2d430131e8e5f6e91d449dab84b99ef6f1c880
Stats:     52 lines in 7 files changed: 39 ins; 0 del; 13 mod

8297632: InputStream.transferTo() method should specify what the return value should be when the number of bytes transfered is larger than Long.MAX_VALUE

Reviewed-by: alanb, lancea

-------------

PR: https://git.openjdk.org/jdk/pull/11403

From bpb at openjdk.org  Tue Feb 14 16:34:49 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 14 Feb 2023 16:34:49 GMT
Subject: RFR: 8298619: java/io/File/GetXSpace.java is failing
In-Reply-To: <Kia7JD1spnBOVIg-KuMO17m5UJClbL8R1SivnOyx8_0=.3950cd71-ce62-47ca-9ac6-0d16071567e3@github.com>
References: <6LnAAIclo5mZZgba4XUSTSc72vyNrBinzUlO9-kJXbU=.fe0c5e94-9e36-4484-b8e7-0f19cb10cb05@github.com>
 <DTNziTj7KbkeG3LvpMREAi9WP9XRczQUdP_1-XTvp2c=.b9b78dec-3879-4626-9174-306e57ce83a4@github.com>
 <134wQrl9F4McK30DN1EvRTuqCx-WDMTgym1traoL8fI=.1247d3ff-0413-415a-9f3f-6a30b59f62d5@github.com>
 <Kia7JD1spnBOVIg-KuMO17m5UJClbL8R1SivnOyx8_0=.3950cd71-ce62-47ca-9ac6-0d16071567e3@github.com>
Message-ID: <N2rOY286-pmyGS6g6R_EddIeBAj-cdStUNRMGwvh6tc=.06ec461d-2868-4de0-a0b0-a8e86709ba98@github.com>

On Sun, 12 Feb 2023 09:34:37 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>>> It seems a bit fragile to be parsing the output of `fsutil volume diskFree` as the output seems to vary by Windows releases and maybe configuration. So minimally, I think it should be changed to use ProcessTools so that the command and the output show up in the .jtr file.
>>> 
>>> In passing, you might want to choose a different method name to make it clearer what it does, maybe volumeDiskFree?
>> 
>> Another possibility would be to add a native method to the test itself to invoke [GetDiskSpaceInformationW](https://learn.microsoft.com/en-us/windows/win32/api/fileapi/nf-fileapi-getdiskspaceinformationw) to obtain the value of `CallerTotalAllocationUnits` (in bytes) from the [DISK_SPACE_INFORMATION](https://learn.microsoft.com/en-us/windows/win32/api/fileapi/ns-fileapi-disk_space_information) structure.
>
>> Another possibility would be to add a native method to the test itself to invoke [GetDiskSpaceInformationW](https://learn.microsoft.com/en-us/windows/win32/api/fileapi/nf-fileapi-getdiskspaceinformationw) to obtain the value of `CallerTotalAllocationUnits` (in bytes) from the [DISK_SPACE_INFORMATION](https://learn.microsoft.com/en-us/windows/win32/api/fileapi/ns-fileapi-disk_space_information) structure.
> 
> That would be more reliable than parsing the output of `fsutil volume` so worth trying. You might have to dig into which of these win32 works with quotas as that seems to be part of the issue. The JDK uses GetDiskFreeSpaceExW. Also this test might have to do a few iterations so that it captures free space info while the system is in quiescence - I suspect some of the reliability issues has been concurrent activity that changes the volume space usage significantly while this test is running.

There has definitely been a problem with quotas on Windows. I set up quotas on actual Windows 11 hardware and replicated the same failure. I am not sure how much lack of system quiescence is to blame, but there would be no harm in building in some robustness for lack of quiescence while we're at it.

-------------

PR: https://git.openjdk.org/jdk/pull/12397

From alanb at openjdk.org  Tue Feb 14 16:35:54 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 14 Feb 2023 16:35:54 GMT
Subject: RFR: 8302325: Wrong comment in
 java.base/share/native/libjimage/imageFile.hpp [v2]
In-Reply-To: <alhQYjnBkQR096TA7K9a3ccAfLEeDmpb2sbO4qogaxQ=.eea928e7-d61e-4387-ba33-9ca2e4d36692@github.com>
References: <ThM7YJ5rlOnQWHBmPQGzPcQ-vrBiR_-OgJL46jeJIV8=.0e736e79-1fe3-40bb-8702-165028592e1c@github.com>
 <alhQYjnBkQR096TA7K9a3ccAfLEeDmpb2sbO4qogaxQ=.eea928e7-d61e-4387-ba33-9ca2e4d36692@github.com>
Message-ID: <FXbapVuzQqXuGwtQs6gGK065l1l5LbzJylmgZzYo56k=.b38a1d67-e14a-4896-ae05-a601ab2a9602@github.com>

On Tue, 14 Feb 2023 10:40:31 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Severin Gehwolf has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
>> 
>>  - Merge branch 'master' into jdk-8302325-imageFile
>>  - Copyright dates updated.
>>  - 8302325: Wrong comment in java.base/share/native/libjimage/imageFile.hpp
>
> kind = 5 looks right.  
> 
> Can you update the end date of the copyright headers as this is the first change in 2023. imageFile.cpp by missed by the other change so it could be done here too.

> @AlanBateman Is that what you meant?

Yes, thanks. The other one that needs update is PerfectHashBuilder.java.

-------------

PR: https://git.openjdk.org/jdk/pull/12533

From rriggs at openjdk.org  Tue Feb 14 16:46:29 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 14 Feb 2023 16:46:29 GMT
Subject: RFR: 8301627: System.exit and Runtime.exit debug logging [v3]
In-Reply-To: <OzJeJH5yxolKPChcUisqtzGYF_MU3oOJdx6HPhsXjBw=.15eefe39-efe1-433e-a6ac-02b4a730f264@github.com>
References: <OzJeJH5yxolKPChcUisqtzGYF_MU3oOJdx6HPhsXjBw=.15eefe39-efe1-433e-a6ac-02b4a730f264@github.com>
Message-ID: <vI-DHj58pSMPHBH7sIJoes0lD5KjjbOHyqWASeS4NTo=.dcfd114c-9154-4ee9-ac5d-8bfcfc53b60e@github.com>

> It can be difficult to find the cause of calls to `java.lang.System.exit(status)` and `Runtime.exit(status)` because the Java runtime exits.
> The status value and stack trace are logged using the System Logger named `java.lang.Runtime` with message level `System.Logger.Level.DEBUG`.

Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:

  Add an @implNote to Runtime.exit to describe the java.lang.Runtime logging.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12517/files
  - new: https://git.openjdk.org/jdk/pull/12517/files/76c4d61f..a8eca9e5

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12517&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12517&range=01-02

  Stats: 32 lines in 2 files changed: 18 ins; 12 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/12517.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12517/head:pull/12517

PR: https://git.openjdk.org/jdk/pull/12517

From jlaskey at openjdk.org  Tue Feb 14 16:50:48 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Tue, 14 Feb 2023 16:50:48 GMT
Subject: RFR: 8302325: Wrong comment in
 java.base/share/native/libjimage/imageFile.hpp [v2]
In-Reply-To: <0zF_Y3qKCBInYGcvZGallODqvrY4Dg92Wxv8AU8Apio=.ae890b59-6a2a-4bcd-adbc-2468e76dc631@github.com>
References: <ThM7YJ5rlOnQWHBmPQGzPcQ-vrBiR_-OgJL46jeJIV8=.0e736e79-1fe3-40bb-8702-165028592e1c@github.com>
 <0zF_Y3qKCBInYGcvZGallODqvrY4Dg92Wxv8AU8Apio=.ae890b59-6a2a-4bcd-adbc-2468e76dc631@github.com>
Message-ID: <Moj7l-YwlkynDpmUvceQGSRGGq-oOZIeY8OXCbtjWj8=.35575857-dca1-4a3e-8287-c7a25483d390@github.com>

On Tue, 14 Feb 2023 14:46:58 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> Could I please get a review of this trivial comment-only change? `imageFile.hpp`
>> describes some properties of the jimage file `lib/modules`. However, I don't think
>> the comment example matches current code in the JDK. [`ATTRIBUTE_OFFSET`](https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/jdk/internal/jimage/ImageLocation.java#L44) get
>> written to the image file with value `0x05` while the comment mentions it gets
>> written as `0x04`. I propose to fix the comment so that it matches the code.
>> 
>> In passing, I've also fixed a comment related to `ATTRIBUTE_END`. I think the point
>> being made there is about byte values of `[0x01..0x07]`, all would represent
>> `ATTRIBUTE_END`, as the upper `5` bits would be `0`. Therefore, byte `0x01` would equally
>> represent `ATTRIBUTE_END` as would `0x00` and `0x07` or any value in between.
>> 
>> 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 three additional commits since the last revision:
> 
>  - Merge branch 'master' into jdk-8302325-imageFile
>  - Copyright dates updated.
>  - 8302325: Wrong comment in java.base/share/native/libjimage/imageFile.hpp

Changes requested by jlaskey (Reviewer).

src/java.base/share/native/libjimage/imageFile.hpp line 218:

> 216: // Notes:
> 217: //  - Even though ATTRIBUTE_END is used to mark the end of the attribute stream,
> 218: //      streams will contain non-zero byte values to represent lesser significant bits.

This change is not correct. Maybe it is badly worded but the point is that **zeroes can** occur in the stream so testing for zero is insufficient.

src/jdk.jlink/share/classes/jdk/tools/jlink/internal/PerfectHashBuilder.java line 249:

> 247:                     // Attempt to pack entries until no collisions occur.
> 248:                     if (!collidedEntries(bucket, count)) {
> 249:                         // Failed to pack. Need to grow table.

Change copyright date to mark this change.

-------------

PR: https://git.openjdk.org/jdk/pull/12533

From sgehwolf at openjdk.org  Tue Feb 14 17:01:45 2023
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Tue, 14 Feb 2023 17:01:45 GMT
Subject: RFR: 8302325: Wrong comment in
 java.base/share/native/libjimage/imageFile.hpp [v2]
In-Reply-To: <Moj7l-YwlkynDpmUvceQGSRGGq-oOZIeY8OXCbtjWj8=.35575857-dca1-4a3e-8287-c7a25483d390@github.com>
References: <ThM7YJ5rlOnQWHBmPQGzPcQ-vrBiR_-OgJL46jeJIV8=.0e736e79-1fe3-40bb-8702-165028592e1c@github.com>
 <0zF_Y3qKCBInYGcvZGallODqvrY4Dg92Wxv8AU8Apio=.ae890b59-6a2a-4bcd-adbc-2468e76dc631@github.com>
 <Moj7l-YwlkynDpmUvceQGSRGGq-oOZIeY8OXCbtjWj8=.35575857-dca1-4a3e-8287-c7a25483d390@github.com>
Message-ID: <wfvKCz9azB8pKXEQehLENPY2Kz3Y6D625LzAzKJj2hs=.70741c0e-3df9-4eb6-815b-bac29d88426b@github.com>

On Tue, 14 Feb 2023 16:47:15 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> Severin Gehwolf has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
>> 
>>  - Merge branch 'master' into jdk-8302325-imageFile
>>  - Copyright dates updated.
>>  - 8302325: Wrong comment in java.base/share/native/libjimage/imageFile.hpp
>
> src/java.base/share/native/libjimage/imageFile.hpp line 218:
> 
>> 216: // Notes:
>> 217: //  - Even though ATTRIBUTE_END is used to mark the end of the attribute stream,
>> 218: //      streams will contain non-zero byte values to represent lesser significant bits.
> 
> This change is not correct. Maybe it is badly worded but the point is that **zeroes can** occur in the stream so testing for zero is insufficient.

@JimLaskey OK. Perhaps we can be clearer what is meant here exactly. I was having a hard time deciphering this. It does say `stream will contain zero byte values to represent lesser significant bits`. **What** are "byte values to represent lesser significant bits"?

-------------

PR: https://git.openjdk.org/jdk/pull/12533

From sgehwolf at openjdk.org  Tue Feb 14 17:14:46 2023
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Tue, 14 Feb 2023 17:14:46 GMT
Subject: RFR: 8302325: Wrong comment in
 java.base/share/native/libjimage/imageFile.hpp [v2]
In-Reply-To: <wfvKCz9azB8pKXEQehLENPY2Kz3Y6D625LzAzKJj2hs=.70741c0e-3df9-4eb6-815b-bac29d88426b@github.com>
References: <ThM7YJ5rlOnQWHBmPQGzPcQ-vrBiR_-OgJL46jeJIV8=.0e736e79-1fe3-40bb-8702-165028592e1c@github.com>
 <0zF_Y3qKCBInYGcvZGallODqvrY4Dg92Wxv8AU8Apio=.ae890b59-6a2a-4bcd-adbc-2468e76dc631@github.com>
 <Moj7l-YwlkynDpmUvceQGSRGGq-oOZIeY8OXCbtjWj8=.35575857-dca1-4a3e-8287-c7a25483d390@github.com>
 <wfvKCz9azB8pKXEQehLENPY2Kz3Y6D625LzAzKJj2hs=.70741c0e-3df9-4eb6-815b-bac29d88426b@github.com>
Message-ID: <gfD6yOREV2S5SpqB1pKRHVF8ALP2Vxvrod6xpuX3w1g=.1a3c6386-61a8-4dee-a0d5-bb4bc5a9bcc1@github.com>

On Tue, 14 Feb 2023 16:59:03 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> src/java.base/share/native/libjimage/imageFile.hpp line 218:
>> 
>>> 216: // Notes:
>>> 217: //  - Even though ATTRIBUTE_END is used to mark the end of the attribute stream,
>>> 218: //      streams will contain non-zero byte values to represent lesser significant bits.
>> 
>> This change is not correct. Maybe it is badly worded but the point is that **zeroes can** occur in the stream so testing for zero is insufficient.
>
> @JimLaskey OK. Perhaps we can be clearer what is meant here exactly. I was having a hard time deciphering this. It does say `stream will contain zero byte values to represent lesser significant bits`. **What** are "byte values to represent lesser significant bits"?

To me it sounded like it wanted to say: Since the `ATTRIBUTE_END` isn't a full byte (only 5 bits in a byte), it might be represented as a non-zero value. For example a byte containing `0x07` would equally be `ATTRIBUTE_END` as would a zero byte or a `0x01` byte. `ATTRIBUTE_END` is a `kind` which is encoded with the *most* significant `5` bits. Yet, `ATTRIBUTE_END` isn't a full byte. The least significant `3` bits in the byte represent the `length - 1` - of bytes - in the attribute stream for offset values. That, to me, also would suggest that comparing it to a zero byte value is not sufficient to detect `ATTRIBUTE_END`.

-------------

PR: https://git.openjdk.org/jdk/pull/12533

From dfuchs at openjdk.org  Tue Feb 14 17:18:46 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 14 Feb 2023 17:18:46 GMT
Subject: RFR: 8301627: System.exit and Runtime.exit debug logging [v3]
In-Reply-To: <vI-DHj58pSMPHBH7sIJoes0lD5KjjbOHyqWASeS4NTo=.dcfd114c-9154-4ee9-ac5d-8bfcfc53b60e@github.com>
References: <OzJeJH5yxolKPChcUisqtzGYF_MU3oOJdx6HPhsXjBw=.15eefe39-efe1-433e-a6ac-02b4a730f264@github.com>
 <vI-DHj58pSMPHBH7sIJoes0lD5KjjbOHyqWASeS4NTo=.dcfd114c-9154-4ee9-ac5d-8bfcfc53b60e@github.com>
Message-ID: <tHM9k0u6Atx3SWb_22prNoXjAy26sEPwpleoVSDbZAA=.f9179824-2e0a-4a46-a262-a32f182bcc6e@github.com>

On Tue, 14 Feb 2023 16:46:29 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> It can be difficult to find the cause of calls to `java.lang.System.exit(status)` and `Runtime.exit(status)` because the Java runtime exits.
>> The status value and stack trace are logged using the System Logger named `java.lang.Runtime` with message level `System.Logger.Level.DEBUG`.
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add an @implNote to Runtime.exit to describe the java.lang.Runtime logging.

src/java.base/share/classes/java/lang/Runtime.java line 160:

> 158:      *
> 159:      * @implNote
> 160:      * If the {@link System.Logger#getLogger(String) System.Logger.getLogger("java.lang.Runtime")}

The link looks wrong to me:
Suggestion:

     * If the {@link System#getLogger(String) System.getLogger("java.lang.Runtime")}

See https://docs.oracle.com/en/java/javase/19/docs/api/java.base/java/lang/System.html#getLogger(java.lang.String)

-------------

PR: https://git.openjdk.org/jdk/pull/12517

From jlaskey at openjdk.org  Tue Feb 14 17:20:45 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Tue, 14 Feb 2023 17:20:45 GMT
Subject: RFR: 8302325: Wrong comment in
 java.base/share/native/libjimage/imageFile.hpp [v2]
In-Reply-To: <0zF_Y3qKCBInYGcvZGallODqvrY4Dg92Wxv8AU8Apio=.ae890b59-6a2a-4bcd-adbc-2468e76dc631@github.com>
References: <ThM7YJ5rlOnQWHBmPQGzPcQ-vrBiR_-OgJL46jeJIV8=.0e736e79-1fe3-40bb-8702-165028592e1c@github.com>
 <0zF_Y3qKCBInYGcvZGallODqvrY4Dg92Wxv8AU8Apio=.ae890b59-6a2a-4bcd-adbc-2468e76dc631@github.com>
Message-ID: <XvL64KWcP3YU9WFR08DO3TeRp4JLfaJ36gJm7Y6vVfA=.3e254b38-aedd-4733-b225-010e8d09ae5d@github.com>

On Tue, 14 Feb 2023 14:46:58 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> Could I please get a review of this trivial comment-only change? `imageFile.hpp`
>> describes some properties of the jimage file `lib/modules`. However, I don't think
>> the comment example matches current code in the JDK. [`ATTRIBUTE_OFFSET`](https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/jdk/internal/jimage/ImageLocation.java#L44) get
>> written to the image file with value `0x05` while the comment mentions it gets
>> written as `0x04`. I propose to fix the comment so that it matches the code.
>> 
>> In passing, I've also fixed a comment related to `ATTRIBUTE_END`. I think the point
>> being made there is about byte values of `[0x01..0x07]`, all would represent
>> `ATTRIBUTE_END`, as the upper `5` bits would be `0`. Therefore, byte `0x01` would equally
>> represent `ATTRIBUTE_END` as would `0x00` and `0x07` or any value in between.
>> 
>> 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 three additional commits since the last revision:
> 
>  - Merge branch 'master' into jdk-8302325-imageFile
>  - Copyright dates updated.
>  - 8302325: Wrong comment in java.base/share/native/libjimage/imageFile.hpp

Changes requested by jlaskey (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/12533

From jlaskey at openjdk.org  Tue Feb 14 17:20:48 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Tue, 14 Feb 2023 17:20:48 GMT
Subject: RFR: 8302325: Wrong comment in
 java.base/share/native/libjimage/imageFile.hpp [v2]
In-Reply-To: <gfD6yOREV2S5SpqB1pKRHVF8ALP2Vxvrod6xpuX3w1g=.1a3c6386-61a8-4dee-a0d5-bb4bc5a9bcc1@github.com>
References: <ThM7YJ5rlOnQWHBmPQGzPcQ-vrBiR_-OgJL46jeJIV8=.0e736e79-1fe3-40bb-8702-165028592e1c@github.com>
 <0zF_Y3qKCBInYGcvZGallODqvrY4Dg92Wxv8AU8Apio=.ae890b59-6a2a-4bcd-adbc-2468e76dc631@github.com>
 <Moj7l-YwlkynDpmUvceQGSRGGq-oOZIeY8OXCbtjWj8=.35575857-dca1-4a3e-8287-c7a25483d390@github.com>
 <wfvKCz9azB8pKXEQehLENPY2Kz3Y6D625LzAzKJj2hs=.70741c0e-3df9-4eb6-815b-bac29d88426b@github.com>
 <gfD6yOREV2S5SpqB1pKRHVF8ALP2Vxvrod6xpuX3w1g=.1a3c6386-61a8-4dee-a0d5-bb4bc5a9bcc1@github.com>
Message-ID: <9EvvOh9NNi5vxFplOrM-ieZBovV425oafshMqnX3uh4=.ac3cbb0e-6135-4514-9ca1-cea0cad87f74@github.com>

On Tue, 14 Feb 2023 17:10:32 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> @JimLaskey OK. Perhaps we can be clearer what is meant here exactly. I was having a hard time deciphering this. It does say `stream will contain zero byte values to represent lesser significant bits`. **What** are "byte values to represent lesser significant bits"?
>
> To me it sounded like it wanted to say: Since the `ATTRIBUTE_END` isn't a full byte (only 5 bits in a byte), it might be represented as a non-zero value. For example a byte containing `0x07` would equally be `ATTRIBUTE_END` as would a zero byte or a `0x01` byte. `ATTRIBUTE_END` is a `kind` which is encoded with the *most* significant `5` bits. Yet, `ATTRIBUTE_END` isn't a full byte. The least significant `3` bits in the byte represent the `length - 1` - of bytes - in the attribute stream for offset values. That, to me, also would suggest that comparing it to a zero byte value is not sufficient to detect `ATTRIBUTE_END`.

I meant that an attribute can have zeros in the non-header portion of the attribute data.

-------------

PR: https://git.openjdk.org/jdk/pull/12533

From eirbjo at gmail.com  Tue Feb 14 17:49:31 2023
From: eirbjo at gmail.com (=?UTF-8?B?RWlyaWsgQmrDuHJzbsO4cw==?=)
Date: Tue, 14 Feb 2023 18:49:31 +0100
Subject: Convert CorruptedZipFiles to testNG
Message-ID: <CA+pBWhvKb6ayJehknmAwFjT-fYMGUxy9Owq=ZxtukifGGRpCbA@mail.gmail.com>

Hi!

CorruptedZipFiles could benefit from some modernization and a conversion to
testNG:

https://github.com/openjdk/jdk/pull/12563

Thanks,
Eirik.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20230214/7b155ac7/attachment-0001.htm>

From sviswanathan at openjdk.org  Tue Feb 14 17:55:44 2023
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Tue, 14 Feb 2023 17:55:44 GMT
Subject: RFR: JDK-8300808: Accelerate Base64 on x86 for AVX2 [v15]
In-Reply-To: <-cgyVapky014oQOVjAUNJKLMXsppjXLvP4KiglJzKo4=.4818efca-5200-48fa-81ec-f6a812c5dc8e@github.com>
References: <9zN3bjyMEikXYOlpjTy9_QPc-9usYiBJMUFdb-TaVrQ=.e8f65ce9-ac0f-4f8d-9c6b-b39ae1c26cd2@github.com>
 <TmYLe9RCiAqtfuyjU77R-faEEVpfmmUoQ89oyBCcEmM=.c6d2d68b-c37d-4c78-a8e4-af4b48df91a5@github.com>
 <4LXDemRbOxX-JiiDgh14WTZ9mc5VwbRLz4KjfxS29Cw=.9c16ea8e-dd1c-4aa3-a6f1-4736f3515edb@github.com>
 <-cgyVapky014oQOVjAUNJKLMXsppjXLvP4KiglJzKo4=.4818efca-5200-48fa-81ec-f6a812c5dc8e@github.com>
Message-ID: <SiwjQM1zOKbgoHoHNREuCXOx-eWBCRrQuj4nGcekhIo=.1267124d-08c6-48b2-82a3-c46d84399662@github.com>

On Tue, 14 Feb 2023 15:03:49 GMT, Scott Gibbons <sgibbons at openjdk.org> wrote:

>> src/hotspot/cpu/x86/stubGenerator_x86_64.cpp line 2658:
>> 
>>> 2656:     // Check for buffer too small (for algorithm)
>>> 2657:     __ subl(length, 0x2c);
>>> 2658:     __ jcc(Assembler::lessEqual, L_tailProc);
>> 
>> This could be Assembler::less instead of Assembler::lessEqual.
>
> Why?  There is no performance difference and the intent is clear.  Is this just a "style" thing?

The thought is that when the length is equal to 44 bytes, we could do the vector loop once before tail processing. The rest of the logic seems to allow that. 44 bytes of base64 -> 33 bytes decoded. So a 32 byte write in vector loop would still be ok and we wont be writing beyond.

-------------

PR: https://git.openjdk.org/jdk/pull/12126

From sviswanathan at openjdk.org  Tue Feb 14 17:55:46 2023
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Tue, 14 Feb 2023 17:55:46 GMT
Subject: RFR: JDK-8300808: Accelerate Base64 on x86 for AVX2 [v15]
In-Reply-To: <J0sbVbTduhigUOziSshLGjoRYzPFy6fZtuf7_Vq7j8I=.5b6a6e42-fc3c-4895-ae8f-1fe7e4c28e29@github.com>
References: <9zN3bjyMEikXYOlpjTy9_QPc-9usYiBJMUFdb-TaVrQ=.e8f65ce9-ac0f-4f8d-9c6b-b39ae1c26cd2@github.com>
 <TmYLe9RCiAqtfuyjU77R-faEEVpfmmUoQ89oyBCcEmM=.c6d2d68b-c37d-4c78-a8e4-af4b48df91a5@github.com>
 <4LXDemRbOxX-JiiDgh14WTZ9mc5VwbRLz4KjfxS29Cw=.9c16ea8e-dd1c-4aa3-a6f1-4736f3515edb@github.com>
 <-cgyVapky014oQOVjAUNJKLMXsppjXLvP4KiglJzKo4=.4818efca-5200-48fa-81ec-f6a812c5dc8e@github.com>
 <J0sbVbTduhigUOziSshLGjoRYzPFy6fZtuf7_Vq7j8I=.5b6a6e42-fc3c-4895-ae8f-1fe7e4c28e29@github.com>
Message-ID: <FMZeWo2v4kUpPOqPZHIBdctopU9ia7vRqjYyZaTnsNw=.72fa3af1-b8fb-4f80-b72b-430be1599877@github.com>

On Tue, 14 Feb 2023 15:19:34 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> Why?  There is no performance difference and the intent is clear.  Is this just a "style" thing?
>
> I think with `lessEqual` we'll jump to `L_tailProc` for the final 32-byte chunk in inputs that are divisible by 32 (starting from 64), no? Using `less` avoids that, while not affecting performance of any other inputs.

As Claes mentioned, this would allow us to do one more iteration of vector loop.

-------------

PR: https://git.openjdk.org/jdk/pull/12126

From sgehwolf at openjdk.org  Tue Feb 14 18:04:43 2023
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Tue, 14 Feb 2023 18:04:43 GMT
Subject: RFR: 8302325: Wrong comment in
 java.base/share/native/libjimage/imageFile.hpp [v2]
In-Reply-To: <9EvvOh9NNi5vxFplOrM-ieZBovV425oafshMqnX3uh4=.ac3cbb0e-6135-4514-9ca1-cea0cad87f74@github.com>
References: <ThM7YJ5rlOnQWHBmPQGzPcQ-vrBiR_-OgJL46jeJIV8=.0e736e79-1fe3-40bb-8702-165028592e1c@github.com>
 <0zF_Y3qKCBInYGcvZGallODqvrY4Dg92Wxv8AU8Apio=.ae890b59-6a2a-4bcd-adbc-2468e76dc631@github.com>
 <Moj7l-YwlkynDpmUvceQGSRGGq-oOZIeY8OXCbtjWj8=.35575857-dca1-4a3e-8287-c7a25483d390@github.com>
 <wfvKCz9azB8pKXEQehLENPY2Kz3Y6D625LzAzKJj2hs=.70741c0e-3df9-4eb6-815b-bac29d88426b@github.com>
 <gfD6yOREV2S5SpqB1pKRHVF8ALP2Vxvrod6xpuX3w1g=.1a3c6386-61a8-4dee-a0d5-bb4bc5a9bcc1@github.com>
 <9EvvOh9NNi5vxFplOrM-ieZBovV425oafshMqnX3uh4=.ac3cbb0e-6135-4514-9ca1-cea0cad87f74@github.com>
Message-ID: <rgIjn0y3vaPJ1mJFVdjtKqvzl6bi9xDH748JMwuMgl0=.75516b1e-7d36-4176-9bfd-4b3b01566ce0@github.com>

On Tue, 14 Feb 2023 17:17:53 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> To me it sounded like it wanted to say: Since the `ATTRIBUTE_END` isn't a full byte (only 5 bits in a byte), it might be represented as a non-zero value. For example a byte containing `0x07` would equally be `ATTRIBUTE_END` as would a zero byte or a `0x01` byte. `ATTRIBUTE_END` is a `kind` which is encoded with the *most* significant `5` bits. Yet, `ATTRIBUTE_END` isn't a full byte. The least significant `3` bits in the byte represent the `length - 1` - of bytes - in the attribute stream for offset values. That, to me, also would suggest that comparing it to a zero byte value is not sufficient to detect `ATTRIBUTE_END`.
>
> I meant that an attribute can have zeros in the non-header portion of the attribute data.

Got it. How about we change this comment from:

//  - Even though ATTRIBUTE_END is used to mark the end of the attribute stream,
//      streams will contain zero byte values to represent lesser significant bits.
//      Thus, detecting a zero byte is not sufficient to detect the end of an attribute
//      stream.


to:

//  - Even though ATTRIBUTE_END (which might be encoded as a zero byte) is used to
//      mark the end of the attribute stream, streams will contain zero byte values in the
//      non-header portion of the attribute data. Thus, detecting a zero byte is not
//      sufficient to detect the end of an attribute stream.


? The phrase "to represent lesser significant bits" and mention of `ATTRIBUTE_END` is throwing me off.

-------------

PR: https://git.openjdk.org/jdk/pull/12533

From rriggs at openjdk.org  Tue Feb 14 18:07:45 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 14 Feb 2023 18:07:45 GMT
Subject: RFR: 8301627: System.exit and Runtime.exit debug logging [v3]
In-Reply-To: <tHM9k0u6Atx3SWb_22prNoXjAy26sEPwpleoVSDbZAA=.f9179824-2e0a-4a46-a262-a32f182bcc6e@github.com>
References: <OzJeJH5yxolKPChcUisqtzGYF_MU3oOJdx6HPhsXjBw=.15eefe39-efe1-433e-a6ac-02b4a730f264@github.com>
 <vI-DHj58pSMPHBH7sIJoes0lD5KjjbOHyqWASeS4NTo=.dcfd114c-9154-4ee9-ac5d-8bfcfc53b60e@github.com>
 <tHM9k0u6Atx3SWb_22prNoXjAy26sEPwpleoVSDbZAA=.f9179824-2e0a-4a46-a262-a32f182bcc6e@github.com>
Message-ID: <_aVWILKpKlRq3uxRqpdtX3dK7ssAYSZPrsgt5iIP6jw=.63658a0e-a630-4060-aa21-1135adfd644b@github.com>

On Tue, 14 Feb 2023 17:15:28 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add an @implNote to Runtime.exit to describe the java.lang.Runtime logging.
>
> src/java.base/share/classes/java/lang/Runtime.java line 160:
> 
>> 158:      *
>> 159:      * @implNote
>> 160:      * If the {@link System.Logger#getLogger(String) System.Logger.getLogger("java.lang.Runtime")}
> 
> The link looks wrong to me:
> Suggestion:
> 
>      * If the {@link System#getLogger(String) System.getLogger("java.lang.Runtime")}
> 
> See https://docs.oracle.com/en/java/javase/19/docs/api/java.base/java/lang/System.html#getLogger(java.lang.String)

yep, will fix.  Oddly, the link worked. Thanks

-------------

PR: https://git.openjdk.org/jdk/pull/12517

From jlaskey at openjdk.org  Tue Feb 14 18:12:44 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Tue, 14 Feb 2023 18:12:44 GMT
Subject: RFR: 8302325: Wrong comment in
 java.base/share/native/libjimage/imageFile.hpp [v2]
In-Reply-To: <rgIjn0y3vaPJ1mJFVdjtKqvzl6bi9xDH748JMwuMgl0=.75516b1e-7d36-4176-9bfd-4b3b01566ce0@github.com>
References: <ThM7YJ5rlOnQWHBmPQGzPcQ-vrBiR_-OgJL46jeJIV8=.0e736e79-1fe3-40bb-8702-165028592e1c@github.com>
 <0zF_Y3qKCBInYGcvZGallODqvrY4Dg92Wxv8AU8Apio=.ae890b59-6a2a-4bcd-adbc-2468e76dc631@github.com>
 <Moj7l-YwlkynDpmUvceQGSRGGq-oOZIeY8OXCbtjWj8=.35575857-dca1-4a3e-8287-c7a25483d390@github.com>
 <wfvKCz9azB8pKXEQehLENPY2Kz3Y6D625LzAzKJj2hs=.70741c0e-3df9-4eb6-815b-bac29d88426b@github.com>
 <gfD6yOREV2S5SpqB1pKRHVF8ALP2Vxvrod6xpuX3w1g=.1a3c6386-61a8-4dee-a0d5-bb4bc5a9bcc1@github.com>
 <9EvvOh9NNi5vxFplOrM-ieZBovV425oafshMqnX3uh4=.ac3cbb0e-6135-4514-9ca1-cea0cad87f74@github.com>
 <rgIjn0y3vaPJ1mJFVdjtKqvzl6bi9xDH748JMwuMgl0=.75516b1e-7d36-4176-9bfd-4b3b01566ce0@github.com>
Message-ID: <x8ZQ5p2o_WWfwLsZGO5hmanawwsLZ_6fPiXtdMR44z4=.76bfb685-f4a5-4067-a0b3-b82f6b96fc6f@github.com>

On Tue, 14 Feb 2023 18:01:44 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> I meant that an attribute can have zeros in the non-header portion of the attribute data.
>
> Got it. How about we change this comment from:
> 
> //  - Even though ATTRIBUTE_END is used to mark the end of the attribute stream,
> //      streams will contain zero byte values to represent lesser significant bits.
> //      Thus, detecting a zero byte is not sufficient to detect the end of an attribute
> //      stream.
> 
> 
> to:
> 
> //  - Even though ATTRIBUTE_END (which might be encoded as a zero byte) is used to
> //      mark the end of the attribute stream, streams will contain zero byte values in the
> //      non-header portion of the attribute data. Thus, detecting a zero byte is not
> //      sufficient to detect the end of an attribute stream.
> 
> 
> ? The phrase "to represent lesser significant bits" and mention of `ATTRIBUTE_END` is throwing me off.

Sounds good to me.

-------------

PR: https://git.openjdk.org/jdk/pull/12533

From sgibbons at openjdk.org  Tue Feb 14 18:22:32 2023
From: sgibbons at openjdk.org (Scott Gibbons)
Date: Tue, 14 Feb 2023 18:22:32 GMT
Subject: RFR: JDK-8300808: Accelerate Base64 on x86 for AVX2 [v17]
In-Reply-To: <9zN3bjyMEikXYOlpjTy9_QPc-9usYiBJMUFdb-TaVrQ=.e8f65ce9-ac0f-4f8d-9c6b-b39ae1c26cd2@github.com>
References: <9zN3bjyMEikXYOlpjTy9_QPc-9usYiBJMUFdb-TaVrQ=.e8f65ce9-ac0f-4f8d-9c6b-b39ae1c26cd2@github.com>
Message-ID: <pyveG7K_dGLMW9GwPkDJlP8UImU6fxTGbeKsP1ybaxk=.028a7a9b-1f79-43b9-baaa-bcae56f97e69@github.com>

> Added code for Base64 acceleration (encode and decode) which will accelerate ~4x for AVX2 platforms.
> 
> Encode performance:
> **Old:**
> 
> Benchmark                      (maxNumBytes)   Mode  Cnt     Score   Error   Units
> Base64Encode.testBase64Encode           1024  thrpt    3  4309.439 ? 2.632  ops/ms
> 
> 
> **New:**
> 
> Benchmark                      (maxNumBytes)   Mode  Cnt      Score     Error   Units
> Base64Encode.testBase64Encode           1024  thrpt    3  24211.397 ? 102.026  ops/ms
> 
> 
> Decode performance:
> **Old:**
> 
> Benchmark                      (errorIndex)  (lineSize)  (maxNumBytes)   Mode  Cnt     Score    Error   Units
> Base64Decode.testBase64Decode           144           4           1024  thrpt    3  3961.768 ? 93.409  ops/ms
> 
> **New:**
> Benchmark                      (errorIndex)  (lineSize)  (maxNumBytes)   Mode  Cnt      Score    Error   Units
> Base64Decode.testBase64Decode           144           4           1024  thrpt    3  14738.051 ? 24.383  ops/ms

Scott Gibbons has updated the pull request incrementally with one additional commit since the last revision:

  Last of review comments

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12126/files
  - new: https://git.openjdk.org/jdk/pull/12126/files/5077b4e8..2adaa5da

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12126&range=16
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12126&range=15-16

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/12126.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12126/head:pull/12126

PR: https://git.openjdk.org/jdk/pull/12126

From rriggs at openjdk.org  Tue Feb 14 18:56:29 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 14 Feb 2023 18:56:29 GMT
Subject: RFR: 8301627: System.exit and Runtime.exit debug logging [v4]
In-Reply-To: <OzJeJH5yxolKPChcUisqtzGYF_MU3oOJdx6HPhsXjBw=.15eefe39-efe1-433e-a6ac-02b4a730f264@github.com>
References: <OzJeJH5yxolKPChcUisqtzGYF_MU3oOJdx6HPhsXjBw=.15eefe39-efe1-433e-a6ac-02b4a730f264@github.com>
Message-ID: <S8S5gyxRG8WS_GbA0zrJPhXIxv6yReejyxgfc_FqBBQ=.eb6b1794-0f21-4292-ac7a-34e7d001f6b1@github.com>

> It can be difficult to find the cause of calls to `java.lang.System.exit(status)` and `Runtime.exit(status)` because the Java runtime exits.
> The status value and stack trace are logged using the System Logger named `java.lang.Runtime` with message level `System.Logger.Level.DEBUG`.

Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:

  Correct System.getLogger link

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12517/files
  - new: https://git.openjdk.org/jdk/pull/12517/files/a8eca9e5..60123543

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12517&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12517&range=02-03

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/12517.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12517/head:pull/12517

PR: https://git.openjdk.org/jdk/pull/12517

From sviswanathan at openjdk.org  Tue Feb 14 19:00:46 2023
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Tue, 14 Feb 2023 19:00:46 GMT
Subject: RFR: JDK-8300808: Accelerate Base64 on x86 for AVX2 [v17]
In-Reply-To: <pyveG7K_dGLMW9GwPkDJlP8UImU6fxTGbeKsP1ybaxk=.028a7a9b-1f79-43b9-baaa-bcae56f97e69@github.com>
References: <9zN3bjyMEikXYOlpjTy9_QPc-9usYiBJMUFdb-TaVrQ=.e8f65ce9-ac0f-4f8d-9c6b-b39ae1c26cd2@github.com>
 <pyveG7K_dGLMW9GwPkDJlP8UImU6fxTGbeKsP1ybaxk=.028a7a9b-1f79-43b9-baaa-bcae56f97e69@github.com>
Message-ID: <IbWmUx7TNNGA9sWiGXjQo3IF_XzdS3gMK34t88rXGi4=.ee1cee54-2519-4c92-adb0-3b4077b927a9@github.com>

On Tue, 14 Feb 2023 18:22:32 GMT, Scott Gibbons <sgibbons at openjdk.org> wrote:

>> Added code for Base64 acceleration (encode and decode) which will accelerate ~4x for AVX2 platforms.
>> 
>> Encode performance:
>> **Old:**
>> 
>> Benchmark                      (maxNumBytes)   Mode  Cnt     Score   Error   Units
>> Base64Encode.testBase64Encode           1024  thrpt    3  4309.439 ? 2.632  ops/ms
>> 
>> 
>> **New:**
>> 
>> Benchmark                      (maxNumBytes)   Mode  Cnt      Score     Error   Units
>> Base64Encode.testBase64Encode           1024  thrpt    3  24211.397 ? 102.026  ops/ms
>> 
>> 
>> Decode performance:
>> **Old:**
>> 
>> Benchmark                      (errorIndex)  (lineSize)  (maxNumBytes)   Mode  Cnt     Score    Error   Units
>> Base64Decode.testBase64Decode           144           4           1024  thrpt    3  3961.768 ? 93.409  ops/ms
>> 
>> **New:**
>> Benchmark                      (errorIndex)  (lineSize)  (maxNumBytes)   Mode  Cnt      Score    Error   Units
>> Base64Decode.testBase64Decode           144           4           1024  thrpt    3  14738.051 ? 24.383  ops/ms
>
> Scott Gibbons has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Last of review comments

Looks good to me.

-------------

Marked as reviewed by sviswanathan (Reviewer).

PR: https://git.openjdk.org/jdk/pull/12126

From smarks at openjdk.org  Tue Feb 14 19:05:46 2023
From: smarks at openjdk.org (Stuart Marks)
Date: Tue, 14 Feb 2023 19:05:46 GMT
Subject: RFR: 8301627: System.exit and Runtime.exit debug logging [v4]
In-Reply-To: <S8S5gyxRG8WS_GbA0zrJPhXIxv6yReejyxgfc_FqBBQ=.eb6b1794-0f21-4292-ac7a-34e7d001f6b1@github.com>
References: <OzJeJH5yxolKPChcUisqtzGYF_MU3oOJdx6HPhsXjBw=.15eefe39-efe1-433e-a6ac-02b4a730f264@github.com>
 <S8S5gyxRG8WS_GbA0zrJPhXIxv6yReejyxgfc_FqBBQ=.eb6b1794-0f21-4292-ac7a-34e7d001f6b1@github.com>
Message-ID: <UeWqWTWg1dZgVBjyqz6bvI6K1XM-ghRM_IiJ0Bt5qH0=.5aa17ff2-196b-4dc9-9175-602f32ebc9c2@github.com>

On Tue, 14 Feb 2023 18:56:29 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> It can be difficult to find the cause of calls to `java.lang.System.exit(status)` and `Runtime.exit(status)` because the Java runtime exits.
>> The status value and stack trace are logged using the System Logger named `java.lang.Runtime` with message level `System.Logger.Level.DEBUG`.
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Correct System.getLogger link

src/java.base/share/classes/java/lang/Shutdown.java line 168:

> 166:                 Throwable throwable = new Throwable("Runtime.exit(" + status + ")");
> 167:                 log.log(System.Logger.Level.DEBUG, "Runtime.exit() called with status: " + status,
> 168:                         throwable);

I'd put a try/catch around the actual logging of the message, to avoid a situation where an error in the logger handler prevents the system from being shut down.

-------------

PR: https://git.openjdk.org/jdk/pull/12517

From sgehwolf at openjdk.org  Tue Feb 14 19:30:19 2023
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Tue, 14 Feb 2023 19:30:19 GMT
Subject: RFR: 8302325: Wrong comment in
 java.base/share/native/libjimage/imageFile.hpp [v3]
In-Reply-To: <ThM7YJ5rlOnQWHBmPQGzPcQ-vrBiR_-OgJL46jeJIV8=.0e736e79-1fe3-40bb-8702-165028592e1c@github.com>
References: <ThM7YJ5rlOnQWHBmPQGzPcQ-vrBiR_-OgJL46jeJIV8=.0e736e79-1fe3-40bb-8702-165028592e1c@github.com>
Message-ID: <Fjsgyb1HcvileyovnmBohpDdwG8TB7AEz9fw0DdiR2s=.3554befb-5569-4509-ad48-9e08ec69fe2c@github.com>

> Could I please get a review of this trivial comment-only change? `imageFile.hpp`
> describes some properties of the jimage file `lib/modules`. However, I don't think
> the comment example matches current code in the JDK. [`ATTRIBUTE_OFFSET`](https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/jdk/internal/jimage/ImageLocation.java#L44) get
> written to the image file with value `0x05` while the comment mentions it gets
> written as `0x04`. I propose to fix the comment so that it matches the code.
> 
> In passing, I've also fixed a comment related to `ATTRIBUTE_END`. I think the point
> being made there is about byte values of `[0x01..0x07]`, all would represent
> `ATTRIBUTE_END`, as the upper `5` bits would be `0`. Therefore, byte `0x01` would equally
> represent `ATTRIBUTE_END` as would `0x00` and `0x07` or any value in between.
> 
> Thoughts?

Severin Gehwolf has updated the pull request incrementally with three additional commits since the last revision:

 - Another fixup.
 - Correct comment in imageFile.hpp
 - Copyright update in PerfectHashBuilder

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12533/files
  - new: https://git.openjdk.org/jdk/pull/12533/files/94b3d7e7..4cb81b43

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12533&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12533&range=01-02

  Stats: 5 lines in 2 files changed: 0 ins; 0 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/12533.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12533/head:pull/12533

PR: https://git.openjdk.org/jdk/pull/12533

From sgehwolf at openjdk.org  Tue Feb 14 19:30:21 2023
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Tue, 14 Feb 2023 19:30:21 GMT
Subject: RFR: 8302325: Wrong comment in
 java.base/share/native/libjimage/imageFile.hpp [v2]
In-Reply-To: <XvL64KWcP3YU9WFR08DO3TeRp4JLfaJ36gJm7Y6vVfA=.3e254b38-aedd-4733-b225-010e8d09ae5d@github.com>
References: <ThM7YJ5rlOnQWHBmPQGzPcQ-vrBiR_-OgJL46jeJIV8=.0e736e79-1fe3-40bb-8702-165028592e1c@github.com>
 <0zF_Y3qKCBInYGcvZGallODqvrY4Dg92Wxv8AU8Apio=.ae890b59-6a2a-4bcd-adbc-2468e76dc631@github.com>
 <XvL64KWcP3YU9WFR08DO3TeRp4JLfaJ36gJm7Y6vVfA=.3e254b38-aedd-4733-b225-010e8d09ae5d@github.com>
Message-ID: <InU8g0QggOYglrfEzFcFNgNObn8dnA8ThVTW7_89Wq4=.e882f658-86ab-49e4-a72a-eaddc93bca45@github.com>

On Tue, 14 Feb 2023 17:18:00 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> Severin Gehwolf has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
>> 
>>  - Merge branch 'master' into jdk-8302325-imageFile
>>  - Copyright dates updated.
>>  - 8302325: Wrong comment in java.base/share/native/libjimage/imageFile.hpp
>
> Changes requested by jlaskey (Reviewer).

@JimLaskey How does this look to you now?

> src/jdk.jlink/share/classes/jdk/tools/jlink/internal/PerfectHashBuilder.java line 249:
> 
>> 247:                     // Attempt to pack entries until no collisions occur.
>> 248:                     if (!collidedEntries(bucket, count)) {
>> 249:                         // Failed to pack. Need to grow table.
> 
> Change copyright date to mark this change.

Fixed.

-------------

PR: https://git.openjdk.org/jdk/pull/12533

From mchung at openjdk.org  Tue Feb 14 19:30:27 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Tue, 14 Feb 2023 19:30:27 GMT
Subject: RFR: JDK-8301460: Clean up LambdaForm to reference BasicType enums
 directly [v2]
In-Reply-To: <yoiVWrNeX6OjlT-iQjAo6SoQWCZi-gcPlWUjK8YZoqc=.61908404-3f28-45cb-a351-aa315924b6c3@github.com>
References: <yoiVWrNeX6OjlT-iQjAo6SoQWCZi-gcPlWUjK8YZoqc=.61908404-3f28-45cb-a351-aa315924b6c3@github.com>
Message-ID: <ZFESeRXDxn2FPvocPwlgaAZe27VKpvit0dGup96GXBU=.be063990-b594-414e-88bf-f1cb0c1944cd@github.com>

> `LambdaForm` declares int constants for `BasicType::ordinal` to workaround JDK-8161245.   Now these int constants are no longer needed.    This removes these int constants and reference `BasicType` enums directly.

Mandy Chung 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 JDK-8301460
 - further clean up
 - JDK-8301460: Code in LambdaForm.java still refers to resolved JDK-8161245

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12546/files
  - new: https://git.openjdk.org/jdk/pull/12546/files/029effa0..75f07dea

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12546&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12546&range=00-01

  Stats: 57732 lines in 1241 files changed: 24871 ins; 16438 del; 16423 mod
  Patch: https://git.openjdk.org/jdk/pull/12546.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12546/head:pull/12546

PR: https://git.openjdk.org/jdk/pull/12546

From sgehwolf at openjdk.org  Tue Feb 14 19:30:21 2023
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Tue, 14 Feb 2023 19:30:21 GMT
Subject: RFR: 8302325: Wrong comment in
 java.base/share/native/libjimage/imageFile.hpp [v2]
In-Reply-To: <x8ZQ5p2o_WWfwLsZGO5hmanawwsLZ_6fPiXtdMR44z4=.76bfb685-f4a5-4067-a0b3-b82f6b96fc6f@github.com>
References: <ThM7YJ5rlOnQWHBmPQGzPcQ-vrBiR_-OgJL46jeJIV8=.0e736e79-1fe3-40bb-8702-165028592e1c@github.com>
 <0zF_Y3qKCBInYGcvZGallODqvrY4Dg92Wxv8AU8Apio=.ae890b59-6a2a-4bcd-adbc-2468e76dc631@github.com>
 <Moj7l-YwlkynDpmUvceQGSRGGq-oOZIeY8OXCbtjWj8=.35575857-dca1-4a3e-8287-c7a25483d390@github.com>
 <wfvKCz9azB8pKXEQehLENPY2Kz3Y6D625LzAzKJj2hs=.70741c0e-3df9-4eb6-815b-bac29d88426b@github.com>
 <gfD6yOREV2S5SpqB1pKRHVF8ALP2Vxvrod6xpuX3w1g=.1a3c6386-61a8-4dee-a0d5-bb4bc5a9bcc1@github.com>
 <9EvvOh9NNi5vxFplOrM-ieZBovV425oafshMqnX3uh4=.ac3cbb0e-6135-4514-9ca1-cea0cad87f74@github.com>
 <rgIjn0y3vaPJ1mJFVdjtKqvzl6bi9xDH748JMwuMgl0=.75516b1e-7d36-4176-9bfd-4b3b01566ce0@github.com>
 <x8ZQ5p2o_WWfwLsZGO5hmanawwsLZ_6fPiXtdMR44z4=.76bfb685-f4a5-4067-a0b3-b82f6b96fc6f@github.com>
Message-ID: <EtivZ281Lo9EJSS-EkAsVDUAH5dsW31jbmHXVwft0O8=.ee69a3c6-e3be-41e7-adf7-9970c1a882f2@github.com>

On Tue, 14 Feb 2023 18:10:11 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> Got it. How about we change this comment from:
>> 
>> //  - Even though ATTRIBUTE_END is used to mark the end of the attribute stream,
>> //      streams will contain zero byte values to represent lesser significant bits.
>> //      Thus, detecting a zero byte is not sufficient to detect the end of an attribute
>> //      stream.
>> 
>> 
>> to:
>> 
>> //  - Even though ATTRIBUTE_END (which might be encoded as a zero byte) is used to
>> //      mark the end of the attribute stream, streams will contain zero byte values in the
>> //      non-header portion of the attribute data. Thus, detecting a zero byte is not
>> //      sufficient to detect the end of an attribute stream.
>> 
>> 
>> ? The phrase "to represent lesser significant bits" and mention of `ATTRIBUTE_END` is throwing me off.
>
> Sounds good to me.

Thanks, updated.

-------------

PR: https://git.openjdk.org/jdk/pull/12533

From mchung at openjdk.org  Tue Feb 14 19:36:45 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Tue, 14 Feb 2023 19:36:45 GMT
Subject: RFR: JDK-8301460: Clean up LambdaForm to reference BasicType enums
 directly [v2]
In-Reply-To: <_6BI2LuBswWyn2rM4lMQOCQsT4vRxWbpWj0TylgE8U8=.ce889389-3f4b-4ef8-93a3-64db0f88cf1c@github.com>
References: <yoiVWrNeX6OjlT-iQjAo6SoQWCZi-gcPlWUjK8YZoqc=.61908404-3f28-45cb-a351-aa315924b6c3@github.com>
 <_6BI2LuBswWyn2rM4lMQOCQsT4vRxWbpWj0TylgE8U8=.ce889389-3f4b-4ef8-93a3-64db0f88cf1c@github.com>
Message-ID: <7PeYifl9OFow9oW4zcmplEYg1rHRTRhsopHhS0fqLxk=.cbab76ee-a55f-4d26-8e60-8d71285bb60f@github.com>

On Tue, 14 Feb 2023 11:16:26 GMT, Sergey Tsypanov <stsypanov at openjdk.org> wrote:

>> Mandy Chung 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 JDK-8301460
>>  - further clean up
>>  - JDK-8301460: Code in LambdaForm.java still refers to resolved JDK-8161245
>
> src/java.base/share/classes/java/lang/invoke/BoundMethodHandle.java line 368:
> 
>> 366:             SpeciesData sd = extensions[typeNum];
>> 367:             if (sd != null)  return sd;
>> 368:             sd = SPECIALIZER.findSpecies(key() + basicType.basicTypeChar());
> 
> As soon as this is `java.base` I suggest to replace `key() + basicType.basicTypeChar()` with `key().concat(String.valueOf(basicType.basicTypeChar()))` to prevent `StringBuilder` allocation and `append()` chaining.

There are only 5 elements in `extensions` arrays for 5 `BasicType`.  I don't think this overhead is significant.

-------------

PR: https://git.openjdk.org/jdk/pull/12546

From mchung at openjdk.org  Tue Feb 14 19:36:48 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Tue, 14 Feb 2023 19:36:48 GMT
Subject: RFR: JDK-8301460: Clean up LambdaForm to reference BasicType enums
 directly [v2]
In-Reply-To: <XzzDPVE7xJjcLYIuAF0mJg_IcHj5GHhE5-cjoW55T5U=.ec648437-ff3a-44c8-bcad-82dd269a5a81@github.com>
References: <yoiVWrNeX6OjlT-iQjAo6SoQWCZi-gcPlWUjK8YZoqc=.61908404-3f28-45cb-a351-aa315924b6c3@github.com>
 <XzzDPVE7xJjcLYIuAF0mJg_IcHj5GHhE5-cjoW55T5U=.ec648437-ff3a-44c8-bcad-82dd269a5a81@github.com>
Message-ID: <noclBxxlsvnn2qTI9nL8JVkX3McP0_NNetv9ogNtugU=.56360115-543e-4b51-90a9-a7d1c6a5ef1d@github.com>

On Tue, 14 Feb 2023 10:50:12 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Mandy Chung 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 JDK-8301460
>>  - further clean up
>>  - JDK-8301460: Code in LambdaForm.java still refers to resolved JDK-8161245
>
> src/java.base/share/classes/java/lang/invoke/BoundMethodHandle.java line 371:
> 
>> 369:             extensions[typeNum] = sd;
>> 370:             return sd;
>> 371:         }
> 
> I suggest changing the existing overload to delegate to this one with `BasicType.basicType(typeNum)` as the argument. (or to use some other way to reduce the duplication)

I further cleaned this up.  `extendWith(byte typeNum)` is now removed.

-------------

PR: https://git.openjdk.org/jdk/pull/12546

From duke at openjdk.org  Tue Feb 14 20:00:54 2023
From: duke at openjdk.org (Karl T)
Date: Tue, 14 Feb 2023 20:00:54 GMT
Subject: RFR: 8301226: Add clamp() methods to java.lang.Math and to
 StrictMath [v8]
In-Reply-To: <-RM6Jh13GZ4ZSt1qMwNp8Wb26qjGphOY89TaGenMzkM=.a04659cd-9f11-4af8-a53c-98d9ff837198@github.com>
References: <c7kJhZvT8oz5hScMxnWI23H7wjCaJ854ajjSRtxBnW4=.3f4e24ca-c608-4541-b80e-cf3452ec6400@github.com>
 <-RM6Jh13GZ4ZSt1qMwNp8Wb26qjGphOY89TaGenMzkM=.a04659cd-9f11-4af8-a53c-98d9ff837198@github.com>
Message-ID: <uqD9ci2PCCntLqba8Hz0jrAL4FaRhGIq-TEMUayyHdI=.0e9509d1-484e-476f-8623-6b218c0cf1e9@github.com>

On Tue, 7 Feb 2023 12:53:25 GMT, Tagir F. Valeev <tvaleev at openjdk.org> wrote:

>> clamp() methods added to Math and StrictMath
>> 
>> `int clamp(long, int, int)` is somewhat different, as it accepts a `long` value and safely clamps it to an `int` range. Other overloads work with a particular type (long, float and double). Using similar approach in other cases (e.g. `float clamp(double, float, float)`) may cause accidental precision loss even if the value is within range, so I decided to avoid this.
>> 
>> In all cases, `max >= min` precondition should met. For double and float we additionally order `-0.0 < 0.0`, similarly to what Math.max or Double.compare do. In double and float overloads I try to keep at most one arg-check comparison on common path, so the order of checks might look unusual.
>> 
>> For tests, I noticed that tests in java/lang/Math don't use any testing framework (even newer tests), so I somehow mimic the approach of neighbour tests.
>
> Tagir F. Valeev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Comments in tests

Regarding the asymmetric `int clamp( long value, int min, int max )` method:
I understand the idea behind using `long`, but IMHO there is a good reason to use `int`instead.
When using the `var` keyword, it could easy result in unwanted type change from `long` to `int`.

E.g. following simple code unexpectedly changes the type from `long` to `int`:
~~~java
var longValue = 1234L;
var intValue = Math.clamp( longValue, 0, 100 );
~~~

When doing the same with `Math.min()` and `max()`, it does **not change type**:
~~~java
var longValue2 = Math.min( 100, Math.max( longValue, 0 ) );
~~~

If you don't want that type change, it is required to pass a long min or max value:
~~~java
var longValue = 1234L;
var longValue2 = Math.clamp( longValue, 0L, 100 );
~~~

This is confusing, isn't it?

The idea behind using `long` as first parameter is "This allows to use method to safely cast long value to int" (from javadoc).
But if changing to `int clamp( int value, int min, int max )`, safely casting long to int is still possible by passing int values to min and max an casting the result to int. E.g.:

~~~java
int a = (int) Math.clamp( longValue, 0, 100 );
~~~

Also not sure whether the idea behind clamp is to provide a mechanism for safe casting...

IMHO the benefit of "safe casting long to int" is very low compared to the risk of unwanted type change when using `var` keyword.

-------------

PR: https://git.openjdk.org/jdk/pull/12428

From alanb at openjdk.org  Tue Feb 14 20:11:41 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 14 Feb 2023 20:11:41 GMT
Subject: RFR: 8299748: java/util/zip/Deinflate.java failing on s390x
In-Reply-To: <p1li8W4D2kYNZlxTOyvlqVrZWOjGbh6g1JfG6eHxAmE=.389b076c-0943-4cfd-af82-f24a56d1ac61@github.com>
References: <Usxi4wE5GSHHv-cKPfW6OXylhieAypbsidUX_Jo6FSQ=.34104cf0-2243-478f-86ce-9a91905c6755@github.com>
 <nN80i01pPGVl8QlQ09eEEEeFTz5z2hpM6udh2bNJwpU=.925ff5c6-586b-4262-bcd0-fd67d44cfde2@github.com>
 <jyL7HTlmcVxDKffdPqij6GNM0ePfzVxlypfy3hTtOAM=.3347a8dd-4722-4b79-b93e-b20892901c6b@github.com>
 <2eqxeIzcejWahzfAMe-czlbIQ96bV8s_RIkXQsXMtsY=.b329489c-40fc-4e91-9e30-10a3df53711e@github.com>
 <p1li8W4D2kYNZlxTOyvlqVrZWOjGbh6g1JfG6eHxAmE=.389b076c-0943-4cfd-af82-f24a56d1ac61@github.com>
Message-ID: <mViUt9K-2zX1iclGWss9oGHP1HM3Xigq3ZAI-ZYV9Ww=.851a49c3-c57c-46d7-9b6b-db5ffda2daf1@github.com>

On Tue, 7 Feb 2023 07:07:54 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>>> Hi @AlanBateman ,
>>> with latest changes (doing inflate/deinflate) test passes over s390 and x86 as well. Please take a look now.
>> 
>> Good. One thing to try is to just deflate/inflate into out1/out2, no need for the intermediate BAOS, try this:
>> 
>> 
>> --- a/test/jdk/java/util/zip/DeInflate.java
>> +++ b/test/jdk/java/util/zip/DeInflate.java
>> @@ -1,5 +1,5 @@
>>  /*
>> - * Copyright (c) 2011, 2018, Oracle and/or its affiliates. All rights reserved.
>> + * Copyright (c) 2011, 2023, Oracle and/or its affiliates. All rights reserved.
>>   * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>>   *
>>   * This code is free software; you can redistribute it and/or modify it
>> @@ -127,11 +127,19 @@ public class DeInflate {
>>  
>>          def.setInput(in, 0, len);
>>          def.finish();
>> -        int m = def.deflate(out1);
>> +        int m = 0;
>> +        while (!def.finished()) {
>> +            int remaining = out1.length - m;
>> +            m += def.deflate(out1, m, remaining);
>> +        }
>>  
>>          Inflater inf = new Inflater(nowrap);
>>          inf.setInput(out1, 0, m);
>> -        int n = inf.inflate(out2);
>> +        int n = 0;
>> +        while (!inf.finished()) {
>> +            int remaining = out2.length - n;
>> +            n += inf.inflate(out2, n, remaining);
>> +        }
>>  
>>          if (n != len ||
>>              !Arrays.equals(Arrays.copyOf(in, len), Arrays.copyOf(out2, len)) ||
>
>> @AlanBateman should we proceed with the current changes then ?
> 
> The BAOS in your current proposal shouldn't be needed so I suspect there is something else "interesting" with this zlib implementation.  For the patch above, can you remove the checking for remaining == 0 and print out the value from deflate at each iterate of the loop. I'm wondering if it returns 0 before def.finished() returns true.

> Hi @AlanBateman, what should be our next step for this PR :)

I don't think we have a good handle on the issue. It's clear that this zlib implementation is a bit different but I'm concerned that your proposed change to the test is masking an issue. I say this because the `check` method is changed to not use the out1 and out2 as the test intended. I'm also concerned that the code fragment you pasted may be the combination of two patches, I can't otherwise explain the ArrayIndexOutOfBoundsException you reported. Would it be possible to re-run with the follow change as I'm like to see again what the failure is:


--- a/test/jdk/java/util/zip/DeInflate.java
+++ b/test/jdk/java/util/zip/DeInflate.java
@@ -1,5 +1,5 @@
 /*
- * Copyright (c) 2011, 2018, Oracle and/or its affiliates. All rights reserved.
+ * Copyright (c) 2011, 2023, Oracle and/or its affiliates. All rights reserved.
  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
  *
  * This code is free software; you can redistribute it and/or modify it
@@ -127,11 +127,19 @@ public class DeInflate {
 
         def.setInput(in, 0, len);
         def.finish();
-        int m = def.deflate(out1);
+        int m = 0;
+        while (!def.finished()) {
+            int remaining = out1.length - m;
+            m += def.deflate(out1, m, remaining);
+        }
 
         Inflater inf = new Inflater(nowrap);
         inf.setInput(out1, 0, m);
-        int n = inf.inflate(out2);
+        int n = 0;
+        while (!inf.finished()) {
+            int remaining = out2.length - n;
+            n += inf.inflate(out2, n, remaining);
+        }
 
         if (n != len ||
             !Arrays.equals(Arrays.copyOf(in, len), Arrays.copyOf(out2, len)) ||

-------------

PR: https://git.openjdk.org/jdk/pull/12283

From tvaleev at openjdk.org  Tue Feb 14 20:15:55 2023
From: tvaleev at openjdk.org (Tagir F. Valeev)
Date: Tue, 14 Feb 2023 20:15:55 GMT
Subject: RFR: 8301226: Add clamp() methods to java.lang.Math and to
 StrictMath [v8]
In-Reply-To: <-RM6Jh13GZ4ZSt1qMwNp8Wb26qjGphOY89TaGenMzkM=.a04659cd-9f11-4af8-a53c-98d9ff837198@github.com>
References: <c7kJhZvT8oz5hScMxnWI23H7wjCaJ854ajjSRtxBnW4=.3f4e24ca-c608-4541-b80e-cf3452ec6400@github.com>
 <-RM6Jh13GZ4ZSt1qMwNp8Wb26qjGphOY89TaGenMzkM=.a04659cd-9f11-4af8-a53c-98d9ff837198@github.com>
Message-ID: <QiIAxe1awOjGgS2kyV8MGMz1rlZcqCLklXDgiYDehoM=.97ee5df2-da3b-4dce-8092-be0a1b24496e@github.com>

On Tue, 7 Feb 2023 12:53:25 GMT, Tagir F. Valeev <tvaleev at openjdk.org> wrote:

>> clamp() methods added to Math and StrictMath
>> 
>> `int clamp(long, int, int)` is somewhat different, as it accepts a `long` value and safely clamps it to an `int` range. Other overloads work with a particular type (long, float and double). Using similar approach in other cases (e.g. `float clamp(double, float, float)`) may cause accidental precision loss even if the value is within range, so I decided to avoid this.
>> 
>> In all cases, `max >= min` precondition should met. For double and float we additionally order `-0.0 < 0.0`, similarly to what Math.max or Double.compare do. In double and float overloads I try to keep at most one arg-check comparison on common path, so the order of checks might look unusual.
>> 
>> For tests, I noticed that tests in java/lang/Math don't use any testing framework (even newer tests), so I somehow mimic the approach of neighbour tests.
>
> Tagir F. Valeev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Comments in tests

I would not use `var` with primitive types. You win nothing but may add confusion, as your samples show. There are many cases when implicit type conversion is performed with numeric types, and using `var` could be indeed confusing.

In this particular case, you lose nothing, as even if the resulting variable is unexpectedly `int`, you don't lose precision and you don't overflow. If you need to pass it somewhere where `long` is expected, it will be widened without any effort from your side. When you use `var`, you're saying that the type is not that important, and it indeed is. Finally, I find it extremely strange to use `var` to hide the type and name the variable as `longValue2`, encoding the type inside variable name. If the type is important, why don't use an explicit type declaration?

-------------

PR: https://git.openjdk.org/jdk/pull/12428

From mchung at openjdk.org  Tue Feb 14 20:22:44 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Tue, 14 Feb 2023 20:22:44 GMT
Subject: RFR: 8293667: Align jlink's --compress option with jmod's
 --compress option [v6]
In-Reply-To: <p5a-3JyPNAPcY5YrBuDGkX9bKNuiwp56QHf2oIInGnc=.ef123257-baf4-4b2c-835c-745bd9899ba7@github.com>
References: <JWevwHuR2vF3k-JRxmTAxfNN6g-EBkgG2N9DHn4fkGY=.f9768dfd-cab4-49a9-83b9-d77a1572e917@github.com>
 <p5a-3JyPNAPcY5YrBuDGkX9bKNuiwp56QHf2oIInGnc=.ef123257-baf4-4b2c-835c-745bd9899ba7@github.com>
Message-ID: <vyutVhxGNbq9_B4NvgmAGqBKXNyG46AUlMGb68BG47k=.61d35f0b-a89c-412e-88e9-57d592db384f@github.com>

On Wed, 8 Feb 2023 23:07:14 GMT, Ian Graves <igraves at openjdk.org> wrote:

>> This is an approach to adding a flag to jlink that will allow --compress to take the same types of arguments as jmod, thus bringing the two into alignment. This likely requires a CSR and a discussion on whether we should deprecate or simply remove the original numeric compression arguments.
>
> Ian Graves has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixing up resources

src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/CompactConstantPoolsPlugin.java line 48:

> 46: 
> 47:     public CompactConstantPoolsPlugin() {
> 48:         super("compact-constant-pools");

This plugin needs a better option name.   Maybe `--share-utf8-entries`?

I also wonder if anyone really uses this plugin.  It writes the shared UTF8 strings into the jimage.  It incurs overhead in reconstructing the constant pool when loading classes.    So I wonder if we just drop this plugin - @AlanBateman, @igraves what do you think?

-------------

PR: https://git.openjdk.org/jdk/pull/11617

From duke at openjdk.org  Tue Feb 14 20:25:54 2023
From: duke at openjdk.org (Karl T)
Date: Tue, 14 Feb 2023 20:25:54 GMT
Subject: RFR: 8301226: Add clamp() methods to java.lang.Math and to
 StrictMath [v8]
In-Reply-To: <QiIAxe1awOjGgS2kyV8MGMz1rlZcqCLklXDgiYDehoM=.97ee5df2-da3b-4dce-8092-be0a1b24496e@github.com>
References: <c7kJhZvT8oz5hScMxnWI23H7wjCaJ854ajjSRtxBnW4=.3f4e24ca-c608-4541-b80e-cf3452ec6400@github.com>
 <-RM6Jh13GZ4ZSt1qMwNp8Wb26qjGphOY89TaGenMzkM=.a04659cd-9f11-4af8-a53c-98d9ff837198@github.com>
 <QiIAxe1awOjGgS2kyV8MGMz1rlZcqCLklXDgiYDehoM=.97ee5df2-da3b-4dce-8092-be0a1b24496e@github.com>
Message-ID: <vWi-H25zJ1WMHMQlD7MMu2o9Yq3GSUGlD02nrf1CAzs=.d708f2cf-5eb9-4855-b1cd-f2bfc6426711@github.com>

On Tue, 14 Feb 2023 20:13:03 GMT, Tagir F. Valeev <tvaleev at openjdk.org> wrote:

> Finally, I find it extremely strange to use var to hide the type and name the variable as `longValue2`, encoding the type inside variable name.

This is just an example name to document the type of the var for this post. ?

-------------

PR: https://git.openjdk.org/jdk/pull/12428

From jlaskey at openjdk.org  Tue Feb 14 20:36:45 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Tue, 14 Feb 2023 20:36:45 GMT
Subject: RFR: 8302325: Wrong comment in
 java.base/share/native/libjimage/imageFile.hpp [v3]
In-Reply-To: <Fjsgyb1HcvileyovnmBohpDdwG8TB7AEz9fw0DdiR2s=.3554befb-5569-4509-ad48-9e08ec69fe2c@github.com>
References: <ThM7YJ5rlOnQWHBmPQGzPcQ-vrBiR_-OgJL46jeJIV8=.0e736e79-1fe3-40bb-8702-165028592e1c@github.com>
 <Fjsgyb1HcvileyovnmBohpDdwG8TB7AEz9fw0DdiR2s=.3554befb-5569-4509-ad48-9e08ec69fe2c@github.com>
Message-ID: <b4fURAg81hBawknKOGWB5oPFH05xfGjkivTJV4_jmgU=.aedfabba-93ec-4c12-9397-7786f1771716@github.com>

On Tue, 14 Feb 2023 19:30:19 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> Could I please get a review of this trivial comment-only change? `imageFile.hpp`
>> describes some properties of the jimage file `lib/modules`. However, I don't think
>> the comment example matches current code in the JDK. [`ATTRIBUTE_OFFSET`](https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/jdk/internal/jimage/ImageLocation.java#L44) get
>> written to the image file with value `0x05` while the comment mentions it gets
>> written as `0x04`. I propose to fix the comment so that it matches the code.
>> 
>> In passing, I've also fixed a comment related to `ATTRIBUTE_END`. I think the point
>> being made there is about byte values of `[0x01..0x07]`, all would represent
>> `ATTRIBUTE_END`, as the upper `5` bits would be `0`. Therefore, byte `0x01` would equally
>> represent `ATTRIBUTE_END` as would `0x00` and `0x07` or any value in between.
>> 
>> Thoughts?
>
> Severin Gehwolf has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Another fixup.
>  - Correct comment in imageFile.hpp
>  - Copyright update in PerfectHashBuilder

LGTM

src/java.base/share/native/libjimage/imageFile.hpp line 217:

> 215: //
> 216: // Notes:
> 217: //  - Even though ATTRIBUTE_END (which might be encoded with a zero byte) is used to

good

-------------

Marked as reviewed by jlaskey (Reviewer).

PR: https://git.openjdk.org/jdk/pull/12533

From psandoz at openjdk.org  Tue Feb 14 20:57:41 2023
From: psandoz at openjdk.org (Paul Sandoz)
Date: Tue, 14 Feb 2023 20:57:41 GMT
Subject: RFR: 8302260: VarHandle.describeConstable() fails to return a
 nominal descriptor for static public fields
In-Reply-To: <fPx38HtLOHB5dvr9_Z2wFKYKLNsjFIIwExNreo3pHxw=.53c3792d-db7b-42d6-b858-5c3062a57a4f@github.com>
References: <fPx38HtLOHB5dvr9_Z2wFKYKLNsjFIIwExNreo3pHxw=.53c3792d-db7b-42d6-b858-5c3062a57a4f@github.com>
Message-ID: <gteYRi3wXp_P4N63oAIDlwjKE3Ay7SXB3gGysoxaBCw=.4bf4fa7e-7882-4e0b-a033-8a5e61679a06@github.com>

On Mon, 13 Feb 2023 19:35:52 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> I overlooked in the fix for JDK-8297757 that it should have passed the declaring class of the static fields rather than the reference class passed to `Lookup::findStaticVarHandle`.

Marked as reviewed by psandoz (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/12543

From duke at openjdk.org  Tue Feb 14 21:07:56 2023
From: duke at openjdk.org (Karl T)
Date: Tue, 14 Feb 2023 21:07:56 GMT
Subject: RFR: 8301226: Add clamp() methods to java.lang.Math and to
 StrictMath [v8]
In-Reply-To: <-RM6Jh13GZ4ZSt1qMwNp8Wb26qjGphOY89TaGenMzkM=.a04659cd-9f11-4af8-a53c-98d9ff837198@github.com>
References: <c7kJhZvT8oz5hScMxnWI23H7wjCaJ854ajjSRtxBnW4=.3f4e24ca-c608-4541-b80e-cf3452ec6400@github.com>
 <-RM6Jh13GZ4ZSt1qMwNp8Wb26qjGphOY89TaGenMzkM=.a04659cd-9f11-4af8-a53c-98d9ff837198@github.com>
Message-ID: <9HTbl11CgEreuDsfvcxZMXaxIsQxlwLw9Gvefn0i_4s=.d818d5a0-1015-4730-9309-b286a19751c1@github.com>

On Tue, 7 Feb 2023 12:53:25 GMT, Tagir F. Valeev <tvaleev at openjdk.org> wrote:

>> clamp() methods added to Math and StrictMath
>> 
>> `int clamp(long, int, int)` is somewhat different, as it accepts a `long` value and safely clamps it to an `int` range. Other overloads work with a particular type (long, float and double). Using similar approach in other cases (e.g. `float clamp(double, float, float)`) may cause accidental precision loss even if the value is within range, so I decided to avoid this.
>> 
>> In all cases, `max >= min` precondition should met. For double and float we additionally order `-0.0 < 0.0`, similarly to what Math.max or Double.compare do. In double and float overloads I try to keep at most one arg-check comparison on common path, so the order of checks might look unusual.
>> 
>> For tests, I noticed that tests in java/lang/Math don't use any testing framework (even newer tests), so I somehow mimic the approach of neighbour tests.
>
> Tagir F. Valeev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Comments in tests

I agree that using `var` for primitive types is maybe not the best idea, but there are thousands (or millions) of Java developers out there doing such things.
Personally, I rarely use the `var` keyword because I still prefer explicit types.

> In this particular case, you lose nothing, as even if the resulting variable is unexpectedly int, you don't lose precision and you don't overflow.

Well there is a overflow risk if calculations are done.
Here is some "dummy" code that demonstrates an int overflow:

~~~java
var a = 1234L;
var b = Math.clamp( a, 0, 100 );
var c = b * 2_000_000_000;
System.out.println( c );
~~~

With `int clamp( long value, int min, int max )`, this outputs `-1863462912`. (int overflow)
But with `int clamp( int value, int min, int max )`, this outputs `200000000000`.

Still think that the API would be cleaner with `int clamp( int value, int min, int max )` ?

-------------

PR: https://git.openjdk.org/jdk/pull/12428

From mchung at openjdk.org  Tue Feb 14 21:18:50 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Tue, 14 Feb 2023 21:18:50 GMT
Subject: Integrated: 8302260: VarHandle.describeConstable() fails to return a
 nominal descriptor for static public fields
In-Reply-To: <fPx38HtLOHB5dvr9_Z2wFKYKLNsjFIIwExNreo3pHxw=.53c3792d-db7b-42d6-b858-5c3062a57a4f@github.com>
References: <fPx38HtLOHB5dvr9_Z2wFKYKLNsjFIIwExNreo3pHxw=.53c3792d-db7b-42d6-b858-5c3062a57a4f@github.com>
Message-ID: <d3GCUJ1pGiOfl00ru4-nZvPSJ_Qg45eSLeTpocqWxY4=.fd851374-ac4d-431a-bcf2-317abb23ebd4@github.com>

On Mon, 13 Feb 2023 19:35:52 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> I overlooked in the fix for JDK-8297757 that it should have passed the declaring class of the static fields rather than the reference class passed to `Lookup::findStaticVarHandle`.

This pull request has now been integrated.

Changeset: 9c202a5a
Author:    Mandy Chung <mchung at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/9c202a5a8fc5b0f334ea72487d079af7da275693
Stats:     231 lines in 7 files changed: 190 ins; 0 del; 41 mod

8302260: VarHandle.describeConstable() fails to return a nominal descriptor for static public fields

Reviewed-by: alanb, psandoz

-------------

PR: https://git.openjdk.org/jdk/pull/12543

From redestad at openjdk.org  Tue Feb 14 22:44:43 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Tue, 14 Feb 2023 22:44:43 GMT
Subject: RFR: JDK-8300808: Accelerate Base64 on x86 for AVX2 [v17]
In-Reply-To: <pyveG7K_dGLMW9GwPkDJlP8UImU6fxTGbeKsP1ybaxk=.028a7a9b-1f79-43b9-baaa-bcae56f97e69@github.com>
References: <9zN3bjyMEikXYOlpjTy9_QPc-9usYiBJMUFdb-TaVrQ=.e8f65ce9-ac0f-4f8d-9c6b-b39ae1c26cd2@github.com>
 <pyveG7K_dGLMW9GwPkDJlP8UImU6fxTGbeKsP1ybaxk=.028a7a9b-1f79-43b9-baaa-bcae56f97e69@github.com>
Message-ID: <2s_1x1gYW-OGAW6s4Cpx1xDwQeqxFfQY1x9WKx0WPzY=.46b006eb-3743-4516-afb7-e08102100432@github.com>

On Tue, 14 Feb 2023 18:22:32 GMT, Scott Gibbons <sgibbons at openjdk.org> wrote:

>> Added code for Base64 acceleration (encode and decode) which will accelerate ~4x for AVX2 platforms.
>> 
>> Encode performance:
>> **Old:**
>> 
>> Benchmark                      (maxNumBytes)   Mode  Cnt     Score   Error   Units
>> Base64Encode.testBase64Encode           1024  thrpt    3  4309.439 ? 2.632  ops/ms
>> 
>> 
>> **New:**
>> 
>> Benchmark                      (maxNumBytes)   Mode  Cnt      Score     Error   Units
>> Base64Encode.testBase64Encode           1024  thrpt    3  24211.397 ? 102.026  ops/ms
>> 
>> 
>> Decode performance:
>> **Old:**
>> 
>> Benchmark                      (errorIndex)  (lineSize)  (maxNumBytes)   Mode  Cnt     Score    Error   Units
>> Base64Decode.testBase64Decode           144           4           1024  thrpt    3  3961.768 ? 93.409  ops/ms
>> 
>> **New:**
>> Benchmark                      (errorIndex)  (lineSize)  (maxNumBytes)   Mode  Cnt      Score    Error   Units
>> Base64Decode.testBase64Decode           144           4           1024  thrpt    3  14738.051 ? 24.383  ops/ms
>
> Scott Gibbons has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Last of review comments

I've started tier1-5 testing internally. Will let you know if we find any issues.

-------------

PR: https://git.openjdk.org/jdk/pull/12126

From sviswanathan at openjdk.org  Tue Feb 14 22:49:46 2023
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Tue, 14 Feb 2023 22:49:46 GMT
Subject: RFR: JDK-8300808: Accelerate Base64 on x86 for AVX2 [v17]
In-Reply-To: <2s_1x1gYW-OGAW6s4Cpx1xDwQeqxFfQY1x9WKx0WPzY=.46b006eb-3743-4516-afb7-e08102100432@github.com>
References: <9zN3bjyMEikXYOlpjTy9_QPc-9usYiBJMUFdb-TaVrQ=.e8f65ce9-ac0f-4f8d-9c6b-b39ae1c26cd2@github.com>
 <pyveG7K_dGLMW9GwPkDJlP8UImU6fxTGbeKsP1ybaxk=.028a7a9b-1f79-43b9-baaa-bcae56f97e69@github.com>
 <2s_1x1gYW-OGAW6s4Cpx1xDwQeqxFfQY1x9WKx0WPzY=.46b006eb-3743-4516-afb7-e08102100432@github.com>
Message-ID: <61Kh7tlZRZQOK_58qHyZPtU5u9BCFQ_qhfWa60E7ibs=.45dfeea1-f1a3-46b2-9d4b-47fd7b6d3f38@github.com>

On Tue, 14 Feb 2023 22:41:47 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> Scott Gibbons has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Last of review comments
>
> I've started tier1-5 testing internally. Will let you know if we find any issues.

Thanks a lot @cl4es for doing the tests for this PR.

-------------

PR: https://git.openjdk.org/jdk/pull/12126

From jvernee at openjdk.org  Tue Feb 14 22:49:46 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Tue, 14 Feb 2023 22:49:46 GMT
Subject: RFR: JDK-8301460: Clean up LambdaForm to reference BasicType enums
 directly [v2]
In-Reply-To: <ZFESeRXDxn2FPvocPwlgaAZe27VKpvit0dGup96GXBU=.be063990-b594-414e-88bf-f1cb0c1944cd@github.com>
References: <yoiVWrNeX6OjlT-iQjAo6SoQWCZi-gcPlWUjK8YZoqc=.61908404-3f28-45cb-a351-aa315924b6c3@github.com>
 <ZFESeRXDxn2FPvocPwlgaAZe27VKpvit0dGup96GXBU=.be063990-b594-414e-88bf-f1cb0c1944cd@github.com>
Message-ID: <jemt6r_y6R64UtIoDMkGv-yRBhj8B4NCuahzCc9RPW4=.7bcece41-dcb0-42c2-8b6d-a8dc6b2e111c@github.com>

On Tue, 14 Feb 2023 19:30:27 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> `LambdaForm` declares int constants for `BasicType::ordinal` to workaround JDK-8161245.   Now these int constants are no longer needed.    This removes these int constants and reference `BasicType` enums directly.
>
> Mandy Chung 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 JDK-8301460
>  - further clean up
>  - JDK-8301460: Code in LambdaForm.java still refers to resolved JDK-8161245

Marked as reviewed by jvernee (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/12546

From duke at openjdk.org  Tue Feb 14 23:13:45 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Tue, 14 Feb 2023 23:13:45 GMT
Subject: RFR: 8301873: Avoid string decoding in ZipFile.Source.getEntryPos
 [v9]
In-Reply-To: <hT1xmxAHP7Rg53Tf_XhCABe-gNiaE2CaqoTwYSAAsZw=.fe11d665-0206-4457-8c64-2665e388219c@github.com>
References: <FkmdspiHVjkAKFqm5kUgwaf55YH5cBbczS_3krqsdFs=.05eca901-f55f-47d9-b1bc-0cf2f5b87536@github.com>
 <p2-revzHDap8mmK22cZnmfocoxjzMZgOWsQX2p8iLYo=.2f9cfa42-46ca-4527-9b4a-103dd06fcdc3@github.com>
 <3fZ6eVyW0fQ2QLZhOG5PyO5nBQ0CqlWt1p41Y2Xtjd4=.2acab1ed-7086-4030-869f-b324b640ea77@github.com>
 <JZnpNuDyzOuST2FenNqvlLCRH-mhjTJRrynIXNpXG6s=.73106c41-38d5-4156-8e1b-4a86c52d030d@github.com>
 <hT1xmxAHP7Rg53Tf_XhCABe-gNiaE2CaqoTwYSAAsZw=.fe11d665-0206-4457-8c64-2665e388219c@github.com>
Message-ID: <OW9pogQH8RHKn0yMHvpI6xgaXM_RZQ0aHS76kiCLvJA=.c0ef684d-433f-4cc7-88c5-7aa9061a3ca7@github.com>

On Tue, 14 Feb 2023 11:21:36 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> The message is already validated using `expectedExceptionsMessageRegExp` in the `@Test` annotation.
>> 
>> Would you prefer if I use expectThrows instead, or perhaps inline the `BAD_ENTRY_NAME_OR_COMMENT` constant as a literal?
>
> Sorry if this was not clear,  we have gone away from using the annotation element `exepectedExceptions` for new and updated tests and  have tried to standardize on `assertThrows` and  `expectThrows` instead which is the basis for my suggestion.
> 
> 
> Thank you for your other updates.  I will go through them later today

No worries, this makes sense. Updated to expectThrows with assertEquals.

-------------

PR: https://git.openjdk.org/jdk/pull/12290

From lancea at openjdk.org  Tue Feb 14 23:21:45 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Tue, 14 Feb 2023 23:21:45 GMT
Subject: RFR: 8301873: Avoid string decoding in ZipFile.Source.getEntryPos
 [v12]
In-Reply-To: <Jm8UwXfOkwCmOyEgHBg1TdID9KsbFNVnqfRwKwkKmQE=.cc5bdbe5-0724-4562-b6b1-ab11ce587580@github.com>
References: <FkmdspiHVjkAKFqm5kUgwaf55YH5cBbczS_3krqsdFs=.05eca901-f55f-47d9-b1bc-0cf2f5b87536@github.com>
 <Jm8UwXfOkwCmOyEgHBg1TdID9KsbFNVnqfRwKwkKmQE=.cc5bdbe5-0724-4562-b6b1-ab11ce587580@github.com>
Message-ID: <u-HyL-nwKSkC6ncp-Iug9TukKdw6Lzwbpw-9OIElPx8=.e7b40009-b4a7-4384-995b-21367162935b@github.com>

On Tue, 14 Feb 2023 11:49:23 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

>> After finding a hash match, getEntryPos needs to compare the lookup name up to the encoded entry name in the CEN. This comparison is done by decoding the entry name into a String. The names can then be compared using the String API. This decoding step adds a significat cost to this method.
>> 
>> This PR suggest to update the string comparison such that in the common case where  both the lookup name and the entry name are encoded in ASCII-compatible UTF-8,  decoding can be avoided and the byte arrays can instead be compared direcly. 
>> 
>> ZipCoder is updated with a new method to compare a string with an encoded byte array range.  The default implementation decodes to string (like the current code), while the UTF-8 implementation uses JavaLangAccess.getBytesNoRepl to get the  bytes. Both methods thes uses Arrays.mismatch for comparison with or without matching trailing slashes. 
>> 
>> Additionally, this PR suggest to make the following updates to getEntryPos:
>> 
>> - The try/catch for IAE is redundant and can be safely removed. (initCEN already checks this and will throws IAE for invalid UTF-8). This seems to give a 3-4% speedup on micros)
>> - A new test InvalidBytesInEntryNameOrComment is a added to verify that initCEN does in fact reject invalid UTF-8 in CEN file names and comments. (I found no existing test coverage for this)
>> - The recursion when looking for "name/" matches is replaced with iteration. We keep track of any "name/" match and return it at the end of the search. (I feel this is easier to follow and it also gives a ~30% speedup for addSlash lookups with no regression on regular lookups)
>> 
>> (My though is that including these additional updates in this PR might reduce reviewer overhead given that it touches the exact same code. I might be wrong on this, please advise :)
>> 
>> I'm seeing a ~17% saving on the micro ZipFileGetEntry.getEntryHit (modified to use xalan.jar):
>> 
>> Baseline:
>> 
>> Benchmark                             (size)  Mode  Cnt    Score   Error  Units
>> ZipFileGetEntry.getEntryHit              512  avgt   15   74.941 ? 1.004  ns/op
>> ZipFileGetEntry.getEntryHit             1024  avgt   15   84.943 ? 1.320  ns/op
>> ZipFileGetEntry.getEntryHitUncached      512  avgt   15  120.371 ? 2.386  ns/op
>> ZipFileGetEntry.getEntryHitUncached     1024  avgt   15  126.128 ? 1.075  ns/op
>> ZipFileGetEntry.getEntryMiss             512  avgt   15   23.818 ? 0.838  ns/op
>> ZipFileGetEntry.getEntryMiss            1024  avgt   15   29.762 ? 5.998  ns/op
>> ZipFileGetEntry.getEntryMissUncached     512  avgt   15   59.405 ? 0.545  ns/op
>> ZipFileGetEntry.getEntryMissUncached    1024  avgt   15   71.840 ? 2.455  ns/op
>> ZipFileGetEntry.getEntrySlash            512  avgt   15  135.621 ? 4.341  ns/op
>> ZipFileGetEntry.getEntrySlash           1024  avgt   15  134.190 ? 2.141  ns/op
>> 
>> 
>> 
>> PR:
>> 
>> 
>> Benchmark                             (size)  Mode  Cnt    Score   Error  Units
>> ZipFileGetEntry.getEntryHit              512  avgt   15   62.267 ? 1.329  ns/op
>> ZipFileGetEntry.getEntryHit             1024  avgt   15   72.916 ? 2.428  ns/op
>> ZipFileGetEntry.getEntryHitUncached      512  avgt   15  101.630 ? 1.154  ns/op
>> ZipFileGetEntry.getEntryHitUncached     1024  avgt   15  113.161 ? 0.502  ns/op
>> ZipFileGetEntry.getEntryMiss             512  avgt   15   23.003 ? 1.191  ns/op
>> ZipFileGetEntry.getEntryMiss            1024  avgt   15   23.236 ? 1.114  ns/op
>> ZipFileGetEntry.getEntryMissUncached     512  avgt   15   56.781 ? 1.505  ns/op
>> ZipFileGetEntry.getEntryMissUncached    1024  avgt   15   67.767 ? 1.963  ns/op
>> ZipFileGetEntry.getEntrySlash            512  avgt   15   73.745 ? 2.717  ns/op
>> ZipFileGetEntry.getEntrySlash           1024  avgt   15   75.784 ? 1.051  ns/op
>> 
>> 
>> To assess the impact on startup/warmup, I made a main method class which measures the total time of calling ZipFile.getEntry for all entries in the 109 JAR file dependenies of spring-petclinic. The shows a nice improvement (time in micros):
>> 
>> 
>> Percentile Baseline Patch
>> 50?%          23155 21149
>> 75?%          23598 21454
>> 90?%          23989 21691
>> 95?%          24238 21973
>> 99?%          25270 22446
>> STDEV           792   549
>> Count           500   500
>
> Eirik Bjorsnos has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Prefer expectThrows with asserts over test annotation regex

Thank you Eirik,  it looks much better.

I will kick off another run tomorrow and make another  pass as it has been a long day  :-)

Thank you again for your work here to improve the Zip code base

test/jdk/java/util/zip/ZipFile/InvalidBytesInEntryNameOrComment.java line 91:

> 89:     public void shouldRejectInvalidName() throws IOException {
> 90:         ZipException ex = expectThrows(ZipException.class, () -> {
> 91:             openZipFile(invalidName);

You could just do


ZipException ex = expectThrows(ZipException.class, () -> {
             new ZipFile(invalidName.toFile())
});

versus adding _openZipFile()_

-------------

PR: https://git.openjdk.org/jdk/pull/12290

From darcy at openjdk.org  Wed Feb 15 00:00:23 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 15 Feb 2023 00:00:23 GMT
Subject: RFR: JDK-8301444: Port fdlibm hyperbolic transcendental functions
 to Java [v10]
In-Reply-To: <_s8xnppoDTnAajAjlmfB-dX5DBdawUcSSPaGWGLzFBk=.cdbf468a-ace7-45e5-a25a-833c760b776c@github.com>
References: <_s8xnppoDTnAajAjlmfB-dX5DBdawUcSSPaGWGLzFBk=.cdbf468a-ace7-45e5-a25a-833c760b776c@github.com>
Message-ID: <yS8UAPEUpV0ZeFNcpcsWsoEuQEnvqgLnXq88Rcbh3QQ=.b872213f-077c-405b-aed6-70c6e1535470@github.com>

> Initial pass of porting FDLIBM sinh/cosh/tanh to Java. I do intend to refactor the regression tests a bit to reduce duplication, but the actual ports should be ready for review.
> 
> Diff'ing the ports as before, original vs transliteration port:
> 
> 
> $ diff -w Hyperbolic.c Hyperbolic.translit.java
> 1c1
> < /* __ieee754_sinh(x)
> ---
>>     /**
> 17a18,19
>>     static class Sinh {
>>         private static final double one = 1.0, shuge = 1.0e307;
> 19,33c21
> < #include "fdlibm.h"
> < 
> < #ifdef __STDC__
> < static const double one = 1.0, shuge = 1.0e307;
> < #else
> < static double one = 1.0, shuge = 1.0e307;
> < #endif
> < 
> < #ifdef __STDC__
> <         double __ieee754_sinh(double x)
> < #else
> <         double __ieee754_sinh(x)
> <         double x;
> < #endif
> < {
> ---
>>         private static double compute(double x) {
> 36c24
> <         unsigned lx;
> ---
>>             /* unsigned */ int lx;
> 51c39
> <             t = expm1(fabs(x));
> ---
>>                 t = FdlibmTranslit.expm1(Math.abs(x));
> 57c45
> <         if (ix < 0x40862E42)  return h*__ieee754_exp(fabs(x));
> ---
>>             if (ix < 0x40862E42)  return h*StrictMath.exp(Math.abs(x)); // TODO switch to translit
> 60,62c48,52
> <         lx = *( (((*(unsigned*)&one)>>29)) + (unsigned*)&x);
> <         if (ix<0x408633CE || ((ix==0x408633ce)&&(lx<=(unsigned)0x8fb9f87d))) {
> <             w = __ieee754_exp(0.5*fabs(x));
> ---
>>             // lx = *( (((*(unsigned*)&one)>>29)) + (unsigned*)&x);
>>             // lx =  (((*(unsigned*)&one)>>29)) + (unsigned*)&x ;
>>             lx = __LO(x);
>>             if (ix<0x408633CE || ((ix==0x408633ce)&&(Long.compareUnsigned(lx, 0x8fb9f87d) <= 0 ))) {
>>                 w = StrictMath.exp(0.5*Math.abs(x)); // TODO switch to translit
> 70c60,62
> < /* __ieee754_cosh(x)
> ---
>>     }
>> 
>>     /**
> 90,105c82,84
> < 
> < #include "fdlibm.h"
> < 
> < #ifdef __STDC__
> < static const double one = 1.0, half=0.5, huge = 1.0e300;
> < #else
> < static double one = 1.0, half=0.5, huge = 1.0e300;
> < #endif
> < 
> < #ifdef __STDC__
> <         double __ieee754_cosh(double x)
> < #else
> <         double __ieee754_cosh(x)
> <         double x;
> < #endif
> < {
> ---
>>     static class Cosh {
>>         private static final double one = 1.0, half=0.5, huge = 1.0e300;
>>         private static double compute(double x) {
> 108c87
> <         unsigned lx;
> ---
>>             /*unsigned*/ int lx;
> 119c98
> <             t = expm1(fabs(x));
> ---
>>                 t = expm1(Math.abs(x));
> 127c106
> <                 t = __ieee754_exp(fabs(x));
> ---
>>                 t = StrictMath.exp(Math.abs(x)); // TODO switch to translit
> 132c111
> <         if (ix < 0x40862E42)  return half*__ieee754_exp(fabs(x));
> ---
>>             if (ix < 0x40862E42)  return half*StrictMath.exp(Math.abs(x)); // TODO switch to translit
> 135c114
> <         lx = *( (((*(unsigned*)&one)>>29)) + (unsigned*)&x);
> ---
>>             lx = __LO(x);
> 137,138c116,117
> <               ((ix==0x408633ce)&&(lx<=(unsigned)0x8fb9f87d))) {
> <             w = __ieee754_exp(half*fabs(x));
> ---
>>                 ((ix==0x408633ce)&&(Integer.compareUnsigned(lx, 0x8fb9f87d) <= 0))) {
>>                 w = StrictMath.exp(half*Math.abs(x)); // TODO switch to translit
> 146c125,127
> < /* Tanh(x)
> ---
>>     }
>> 
>>     /**
> 169,184c150,152
> < 
> < #include "fdlibm.h"
> < 
> < #ifdef __STDC__
> < static const double one=1.0, two=2.0, tiny = 1.0e-300;
> < #else
> < static double one=1.0, two=2.0, tiny = 1.0e-300;
> < #endif
> < 
> < #ifdef __STDC__
> <         double tanh(double x)
> < #else
> <         double tanh(x)
> <         double x;
> < #endif
> < {
> ---
>>     static class Tanh {
>>         private static final double one=1.0, two=2.0, tiny = 1.0e-300;
>>         static double compute(double x) {
> 203c171
> <                 t = expm1(two*fabs(x));
> ---
>>                     t = expm1(two*Math.abs(x));
> 206c174
> <                 t = expm1(-two*fabs(x));
> ---
>>                     t = expm1(-two*Math.abs(x));
> 214a183
>>     }
> 
> 
> Note that the original has a in-line version of the "__LO" macro rather than using the macro.
> 
> 
> And transliteration vs more idiomatic:
> 
> 
> $ diff -w Hyperbolic.translit.java Hyperbolic.fdlibm.java 
> 21c21
> <         private static double compute(double x) {
> ---
>>          static double compute(double x) {
> 26c26
> <             /* High word of |x|. */
> ---
>>             // High word of |x|
> 28c28
> <             ix = jx&0x7fffffff;
> ---
>>             ix = jx & 0x7fff_ffff;
> 30,31c30,33
> <             /* x is INF or NaN */
> <             if(ix>=0x7ff00000) return x+x;
> ---
>>             // x is INF or NaN
>>             if ( ix >= 0x7ff0_0000) {
>>                 return x + x;
>>             }
> 34,40c36,48
> <             if (jx<0) h = -h;
> <             /* |x| in [0,22], return sign(x)*0.5*(E+E/(E+1))) */
> <             if (ix < 0x40360000) {          /* |x|<22 */
> <                 if (ix<0x3e300000)          /* |x|<2**-28 */
> <                     if(shuge+x>one) return x;/* sinh(tiny) = tiny with inexact */
> <                 t = FdlibmTranslit.expm1(Math.abs(x));
> <                 if(ix<0x3ff00000) return h*(2.0*t-t*t/(t+one));
> ---
>>             if ( jx < 0) {
>>                 h = -h;
>>             }
>>             // |x| in [0,22], return sign(x)*0.5*(E+E/(E+1)))
>>             if (ix < 0x4036_0000) {          // |x| < 22
>>                 if (ix < 0x3e30_0000)        // |x| < 2**-28
>>                     if (shuge + x > one) {   // sinh(tiny) = tiny with inexact
>>                         return x;
>>                     }
>>                 t = StrictMath.expm1(Math.abs(x));
>>                 if (ix < 0x3ff0_0000) {
>>                     return h*(2.0 * t - t*t/(t + one));
>>                 }
> 44,45c52,55
> <             /* |x| in [22, log(maxdouble)] return 0.5*exp(|x|) */
> <             if (ix < 0x40862E42)  return h*StrictMath.exp(Math.abs(x)); // TODO switch to translit
> ---
>>             // |x| in [22, log(maxdouble)] return 0.5*exp(|x|)
>>             if (ix < 0x4086_2E42) {
>>                 return h*StrictMath.exp(Math.abs(x));
>>             }
> 47,49c57
> <             /* |x| in [log(maxdouble), overflowthresold] */
> <             // lx = *( (((*(unsigned*)&one)>>29)) + (unsigned*)&x);
> <             // lx =  (((*(unsigned*)&one)>>29)) + (unsigned*)&x ;
> ---
>>             // |x| in [log(maxdouble), overflowthresold]
> 51,52c59,62
> <             if (ix<0x408633CE || ((ix==0x408633ce)&&(Long.compareUnsigned(lx, 0x8fb9f87d) <= 0 ))) {
> <                 w = StrictMath.exp(0.5*Math.abs(x)); // TODO switch to translit
> ---
>>             if (ix < 0x4086_33CE ||
>>                 ((ix == 0x4086_33ce) &&
>>                  (Long.compareUnsigned(lx, 0x8fb9_f87d) <= 0 ))) {
>>                 w = StrictMath.exp(0.5 * Math.abs(x));
> 57c67
> <             /* |x| > overflowthresold, sinh(x) overflow */
> ---
>>             // |x| > overflowthresold, sinh(x) overflow
> 84c94
> <         private static double compute(double x) {
> ---
>>         static double compute(double x) {
> 89c99
> <             /* High word of |x|. */
> ---
>>             // High word of |x|
> 91c101
> <             ix &= 0x7fffffff;
> ---
>>             ix &= 0x7fff_ffff;
> 93,94c103,106
> <             /* x is INF or NaN */
> <             if(ix>=0x7ff00000) return x*x;
> ---
>>             // x is INF or NaN
>>             if (ix >= 0x7ff_00000) {
>>                 return x*x;
>>             }
> 96,98c108,110
> <             /* |x| in [0,0.5*ln2], return 1+expm1(|x|)^2/(2*exp(|x|)) */
> <             if(ix<0x3fd62e43) {
> <                 t = expm1(Math.abs(x));
> ---
>>             // |x| in [0,0.5*ln2], return 1+expm1(|x|)^2/(2*exp(|x|))
>>             if (ix < 0x3fd6_2e43) {
>>                 t = StrictMath.expm1(Math.abs(x));
> 100c112,114
> <                 if (ix<0x3c800000) return w;        /* cosh(tiny) = 1 */
> ---
>>                 if (ix < 0x3c80_0000) { // cosh(tiny) = 1
>>                     return w;
>>                 }
> 104,106c118,120
> <             /* |x| in [0.5*ln2,22], return (exp(|x|)+1/exp(|x|)/2; */
> <             if (ix < 0x40360000) {
> <                 t = StrictMath.exp(Math.abs(x)); // TODO switch to translit
> ---
>>             // |x| in [0.5*ln2, 22], return (exp(|x|) + 1/exp(|x|)/2
>>             if (ix < 0x4036_0000) {
>>                 t = StrictMath.exp(Math.abs(x));
> 110,111c124,127
> <             /* |x| in [22, log(maxdouble)] return half*exp(|x|) */
> <             if (ix < 0x40862E42)  return half*StrictMath.exp(Math.abs(x)); // TODO switch to translit
> ---
>>             // |x| in [22, log(maxdouble)] return half*exp(|x|)
>>             if (ix < 0x4086_2E42) {
>>                 return half*StrictMath.exp(Math.abs(x));
>>             }
> 113c129
> <             /* |x| in [log(maxdouble), overflowthresold] */
> ---
>>             // |x| in [log(maxdouble), overflowthresold]
> 115,117c131,134
> <             if (ix<0x408633CE ||
> <                 ((ix==0x408633ce)&&(Integer.compareUnsigned(lx, 0x8fb9f87d) <= 0))) {
> <                 w = StrictMath.exp(half*Math.abs(x)); // TODO switch to translit
> ---
>>             if (ix<0x4086_33CE ||
>>                 ((ix == 0x4086_33ce) &&
>>                  (Integer.compareUnsigned(lx, 0x8fb9_f87d) <= 0))) {
>>                 w = StrictMath.exp(half*Math.abs(x));
> 122c139
> <             /* |x| > overflowthresold, cosh(x) overflow */
> ---
>>             // |x| > overflowthresold, cosh(x) overflow
> 126d142
> < 
> 156c172
> <             /* High word of |x|. */
> ---
>>             // High word of |x|.
> 158c174
> <             ix = jx&0x7fffffff;
> ---
>>             ix = jx & 0x7fff_ffff;
> 160,163c176,182
> <             /* x is INF or NaN */
> <             if(ix>=0x7ff00000) {
> <                 if (jx>=0) return one/x+one;    /* tanh(+-inf)=+-1 */
> <                 else       return one/x-one;    /* tanh(NaN) = NaN */
> ---
>>             // x is INF or NaN
>>             if (ix >= 0x7ff0_0000) {
>>                 if (jx >= 0) {  // tanh(+-inf)=+-1
>>                     return one/x + one;
>>                 } else {        // tanh(NaN) = NaN
>>                     return one/x - one;
>>                 }
> 166,171c185,190
> <             /* |x| < 22 */
> <             if (ix < 0x40360000) {          /* |x|<22 */
> <                 if (ix<0x3c800000)          /* |x|<2**-55 */
> <                     return x*(one+x);       /* tanh(small) = small */
> <                 if (ix>=0x3ff00000) {       /* |x|>=1  */
> <                     t = expm1(two*Math.abs(x));
> ---
>>             // |x| < 22
>>             if (ix < 0x4036_0000) {          // |x| < 22
>>                 if (ix<0x3c80_0000)          // |x| < 2**-55
>>                     return x*(one + x);      // tanh(small) = small
>>                 if (ix>=0x3ff0_0000) {       // |x| >= 1
>>                     t = StrictMath.expm1(two*Math.abs(x));
> 174c193
> <                     t = expm1(-two*Math.abs(x));
> ---
>>                     t = StrictMath.expm1(-two*Math.abs(x));
> 177,179c196,197
> <                 /* |x| > 22, return +-1 */
> <             } else {
> <                 z = one - tiny;             /* raised inexact flag */
> ---
>>             } else { // |x| > 22, return +-1
>>                 z = one - tiny;             // raised inexact flag

Joe Darcy has updated the pull request incrementally with two additional commits since the last revision:

 - Refactor regression test.
 - Small refactorings in Fdlibm.java

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12429/files
  - new: https://git.openjdk.org/jdk/pull/12429/files/e75cfbb8..32aee21f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12429&range=09
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12429&range=08-09

  Stats: 231 lines in 2 files changed: 39 ins; 86 del; 106 mod
  Patch: https://git.openjdk.org/jdk/pull/12429.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12429/head:pull/12429

PR: https://git.openjdk.org/jdk/pull/12429

From darcy at openjdk.org  Wed Feb 15 01:13:16 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 15 Feb 2023 01:13:16 GMT
Subject: RFR: JDK-8302026: Port fdlibm inverse trig functions (asin, acos, 
 atan) to Java [v2]
In-Reply-To: <4gBqg3J25LASN6tnRwZ22S3YlUHQrypgvZqynfKd3Os=.3a5e618f-b7eb-4978-a6ab-f1b30c793fb4@github.com>
References: <4gBqg3J25LASN6tnRwZ22S3YlUHQrypgvZqynfKd3Os=.3a5e618f-b7eb-4978-a6ab-f1b30c793fb4@github.com>
Message-ID: <nye6hmaxdoxF9Nt1dSPooEOZcFrf7RqTtm-pNj6llQk=.bfb8bdbf-5679-4e53-89d2-42230607ba2f@github.com>

> Proceeding down the line of FDLIBM functions to be ported, next up are asin, acos, and atan.
> 
> Diffs of the various versions will follow in a separate message.
> 
> There were no unusual coding idioms encountered in porting these methods.

Joe Darcy has updated the pull request incrementally with two additional commits since the last revision:

 - Add asin test case.
 - Refactor regression tests.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12545/files
  - new: https://git.openjdk.org/jdk/pull/12545/files/688f44ba..e8195463

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12545&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12545&range=00-01

  Stats: 176 lines in 1 file changed: 34 ins; 82 del; 60 mod
  Patch: https://git.openjdk.org/jdk/pull/12545.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12545/head:pull/12545

PR: https://git.openjdk.org/jdk/pull/12545

From duke at openjdk.org  Wed Feb 15 02:27:42 2023
From: duke at openjdk.org (Amit Kumar)
Date: Wed, 15 Feb 2023 02:27:42 GMT
Subject: RFR: 8299748: java/util/zip/Deinflate.java failing on s390x
In-Reply-To: <mViUt9K-2zX1iclGWss9oGHP1HM3Xigq3ZAI-ZYV9Ww=.851a49c3-c57c-46d7-9b6b-db5ffda2daf1@github.com>
References: <Usxi4wE5GSHHv-cKPfW6OXylhieAypbsidUX_Jo6FSQ=.34104cf0-2243-478f-86ce-9a91905c6755@github.com>
 <nN80i01pPGVl8QlQ09eEEEeFTz5z2hpM6udh2bNJwpU=.925ff5c6-586b-4262-bcd0-fd67d44cfde2@github.com>
 <jyL7HTlmcVxDKffdPqij6GNM0ePfzVxlypfy3hTtOAM=.3347a8dd-4722-4b79-b93e-b20892901c6b@github.com>
 <2eqxeIzcejWahzfAMe-czlbIQ96bV8s_RIkXQsXMtsY=.b329489c-40fc-4e91-9e30-10a3df53711e@github.com>
 <p1li8W4D2kYNZlxTOyvlqVrZWOjGbh6g1JfG6eHxAmE=.389b076c-0943-4cfd-af82-f24a56d1ac61@github.com>
 <mViUt9K-2zX1iclGWss9oGHP1HM3Xigq3ZAI-ZYV9Ww=.851a49c3-c57c-46d7-9b6b-db5ffda2daf1@github.com>
Message-ID: <_SfmRrzgThXEqx714Hx-z6hyhJedR_j3KqryCcZ7Ks8=.1b7b7dc6-927e-42ce-b659-23c5c9f603c0@github.com>

On Tue, 14 Feb 2023 20:08:47 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>I don't think we have a good handle on the issue. It's clear that this zlib implementation is a bit different but I'm concerned that your proposed change to the test is masking an issue. I say this because the check method is changed to not use the out1 and out2 as the test intended. I'm also concerned that the code fragment you pasted may be the combination of two patches, I can't otherwise explain the ArrayIndexOutOfBoundsException you reported. Would it be possible to re-run with the follow change as I'm like to see again what the failure is:

After reverting all of my changes, I applied your patch and I got time limit error, probably because of some inf-loop ?


result: Error. Agent error: java.lang.Exception: Agent 2 timed out with a timeout of 480 seconds; check console log for any additional details

-------------

PR: https://git.openjdk.org/jdk/pull/12283

From asotona at openjdk.org  Wed Feb 15 07:56:56 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Wed, 15 Feb 2023 07:56:56 GMT
Subject: RFR: 8294982: Implementation of Classfile API [v15]
In-Reply-To: <hUvPqC4427nX8mcEcC5Tr90RFXAtmNigTxexY_Ujf04=.55b5e41d-afa7-4220-b13f-6fb0dd25dd0e@github.com>
References: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
 <hr8eti6ytvV05JFRr5hYLWy7yBla9mpI8vKKfaaFR-k=.a92f7bea-6400-4f95-a40c-d57192013f19@github.com>
 <hUvPqC4427nX8mcEcC5Tr90RFXAtmNigTxexY_Ujf04=.55b5e41d-afa7-4220-b13f-6fb0dd25dd0e@github.com>
Message-ID: <PXo9fJmIfK6sTlkbwWJuLz9kszQ1KSGu89wPLhMUuTw=.7ab33ee2-61a4-41c3-8038-4f97857cfc6a@github.com>

On Thu, 9 Feb 2023 12:54:42 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   AttributeElement.Kind removal (#48)
>
> src/java.base/share/classes/jdk/internal/classfile/constantpool/ConstantPool.java line 76:
> 
>> 74:      *              entry
>> 75:      */
>> 76:     BootstrapMethodEntry bootstrapMethodEntry(int index);
> 
> I note some inconsistency in naming - e.g. is `ByIndex` really needed, or a letfover to distinguish between different access modes (which are no longer there, it seems) ?

Yes, there are low-level use cases requiring to operate by index, for example javap.

-------------

PR: https://git.openjdk.org/jdk/pull/10982

From asotona at openjdk.org  Wed Feb 15 08:11:56 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Wed, 15 Feb 2023 08:11:56 GMT
Subject: RFR: 8294982: Implementation of Classfile API [v15]
In-Reply-To: <FsYcFKipqkTseekaQt-gHYX4NIlKc4im1XkfgyZJta4=.f3a496fc-8ec1-4f4c-b89b-449fb2c92f17@github.com>
References: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
 <hr8eti6ytvV05JFRr5hYLWy7yBla9mpI8vKKfaaFR-k=.a92f7bea-6400-4f95-a40c-d57192013f19@github.com>
 <hUvPqC4427nX8mcEcC5Tr90RFXAtmNigTxexY_Ujf04=.55b5e41d-afa7-4220-b13f-6fb0dd25dd0e@github.com>
 <FsYcFKipqkTseekaQt-gHYX4NIlKc4im1XkfgyZJta4=.f3a496fc-8ec1-4f4c-b89b-449fb2c92f17@github.com>
Message-ID: <8KL3-QT9rm0VE6ceu07WBuNt_UHj2cGNumLRzazxCKM=.f6b60cc7-427d-4958-a3a1-2a31e925e9f1@github.com>

On Thu, 9 Feb 2023 13:01:57 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/classfile/constantpool/ClassEntry.java line 80:
>> 
>>> 78:      * Return a List composed by appending the additions to the base list.
>>> 79:      * @param base The base elements for the list, must not include null
>>> 80:      * @param additions The ClassEntrys to add to the list, must not include null
>> 
>> Perhaps we should use `{@code}` or {@link}` to surround type names (here and elsewhere). `ClassEntrys` looks particularly odd :-)
>
> It is odd to see what is essentially a list append operation in here. IMHO, these helper methods, if needed (I couldn't find uses in the JDK), should probably be added to Collections (which probably means in the jdktypes package for now) - as I don't see anything really ClassEntry/ClassDesc specific about them.

I'll make a note to deeply review javadoc for types and to wrap them, thanks.

As for the List combining methods, they had been proposed, discussed and approved here:
https://github.com/openjdk/jdk-sandbox/pull/35
Feel free to re-open the discussion on mailing list, maybe we can address them better now.
However there is no general contract between "entries" and "symbols" yet, so such methods could be declared generic.

-------------

PR: https://git.openjdk.org/jdk/pull/10982

From alanb at openjdk.org  Wed Feb 15 08:18:46 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 15 Feb 2023 08:18:46 GMT
Subject: RFR: 8299748: java/util/zip/Deinflate.java failing on s390x
In-Reply-To: <_SfmRrzgThXEqx714Hx-z6hyhJedR_j3KqryCcZ7Ks8=.1b7b7dc6-927e-42ce-b659-23c5c9f603c0@github.com>
References: <Usxi4wE5GSHHv-cKPfW6OXylhieAypbsidUX_Jo6FSQ=.34104cf0-2243-478f-86ce-9a91905c6755@github.com>
 <nN80i01pPGVl8QlQ09eEEEeFTz5z2hpM6udh2bNJwpU=.925ff5c6-586b-4262-bcd0-fd67d44cfde2@github.com>
 <jyL7HTlmcVxDKffdPqij6GNM0ePfzVxlypfy3hTtOAM=.3347a8dd-4722-4b79-b93e-b20892901c6b@github.com>
 <2eqxeIzcejWahzfAMe-czlbIQ96bV8s_RIkXQsXMtsY=.b329489c-40fc-4e91-9e30-10a3df53711e@github.com>
 <p1li8W4D2kYNZlxTOyvlqVrZWOjGbh6g1JfG6eHxAmE=.389b076c-0943-4cfd-af82-f24a56d1ac61@github.com>
 <mViUt9K-2zX1iclGWss9oGHP1HM3Xigq3ZAI-ZYV9Ww=.851a49c3-c57c-46d7-9b6b-db5ffda2daf1@github.com>
 <_SfmRrzgThXEqx714Hx-z6hyhJedR_j3KqryCcZ7Ks8=.1b7b7dc6-927e-42ce-b659-23c5c9f603c0@github.com>
Message-ID: <qwjoHqgbDmbLmBVNyUmOUPlt7MQzSNnD8FBEYTMhgNg=.2a376dd3-9192-4acb-b3e3-f470991706eb@github.com>

On Wed, 15 Feb 2023 02:25:00 GMT, Amit Kumar <duke at openjdk.org> wrote:

> After reverting all of my changes, I applied your patch and I got time limit error, probably because of some inf-loop ?
> 
> ```
> result: Error. Agent error: java.lang.Exception: Agent 2 timed out with a timeout of 480 seconds; check console log for any additional details
> ```

Yes, it seems the deflate or inflate loop doesn't terminate as finished doesn't change to true or no space available in the buffer. I assume you can quickly check which loop, I suspect it's the deflate loop based of the previous comments/experiments.

Your initial proposal was to increase the size of out1 but I can't see any cases in this test where the deflate fills out1 completely. Additionally, when you initially tried the patch to replace deflate with a loop, it failed with "out1 is too small" which is very surprising, it hints that Deflater::finished is not returning true when the input has been consumed. You might have to dig into this more to see if there is a bug in this area to explain it.

For inflate, the i == 0 case (in main) will cause inflate to fill out2 completely. This is the most likely case to loop if there was a bug somewhere.

-------------

PR: https://git.openjdk.org/jdk/pull/12283

From asotona at openjdk.org  Wed Feb 15 08:22:58 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Wed, 15 Feb 2023 08:22:58 GMT
Subject: RFR: 8294982: Implementation of Classfile API [v15]
In-Reply-To: <hUvPqC4427nX8mcEcC5Tr90RFXAtmNigTxexY_Ujf04=.55b5e41d-afa7-4220-b13f-6fb0dd25dd0e@github.com>
References: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
 <hr8eti6ytvV05JFRr5hYLWy7yBla9mpI8vKKfaaFR-k=.a92f7bea-6400-4f95-a40c-d57192013f19@github.com>
 <hUvPqC4427nX8mcEcC5Tr90RFXAtmNigTxexY_Ujf04=.55b5e41d-afa7-4220-b13f-6fb0dd25dd0e@github.com>
Message-ID: <WjPpEjQMu0JRMC50Ah6GbGziijbdSSS_EUGbSJ_gH2I=.bafee453-7bfc-444d-93eb-8d3b9258a2fd@github.com>

On Thu, 9 Feb 2023 14:01:10 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   AttributeElement.Kind removal (#48)
>
> src/java.base/share/classes/jdk/internal/classfile/constantpool/ConstantPoolBuilder.java line 537:
> 
>> 535:      * @param <T> the type of the entry
>> 536:      */
>> 537:     <T extends PoolEntry> T maybeClone(T entry);
> 
> This feels a more primitive operation than the name suggests. Have you considered making ConstantPool extend Consumer<PoolEntry> and call this "accept" ?

I'm not quite sure what exactly do you propose.
`ConstantPool` should not accept anything as it is read-only, so "accept" would be confusing.
`ConstantPoolBuilder::maybeClone` is rather a `Function`, where the name might be changed to `ConstantPoolBuilder::apply`.
However there are so many "accepts" and "applies" across the API, that reducing API verbosity to just these functional terms might significantly decrease readability.

-------------

PR: https://git.openjdk.org/jdk/pull/10982

From asotona at openjdk.org  Wed Feb 15 08:29:59 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Wed, 15 Feb 2023 08:29:59 GMT
Subject: RFR: 8294982: Implementation of Classfile API [v15]
In-Reply-To: <hUvPqC4427nX8mcEcC5Tr90RFXAtmNigTxexY_Ujf04=.55b5e41d-afa7-4220-b13f-6fb0dd25dd0e@github.com>
References: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
 <hr8eti6ytvV05JFRr5hYLWy7yBla9mpI8vKKfaaFR-k=.a92f7bea-6400-4f95-a40c-d57192013f19@github.com>
 <hUvPqC4427nX8mcEcC5Tr90RFXAtmNigTxexY_Ujf04=.55b5e41d-afa7-4220-b13f-6fb0dd25dd0e@github.com>
Message-ID: <sl0obxW3t2tdKsfPz_nvmkaiLFlI94m267mFJ6Hmevo=.fb83703e-f78f-41b9-8f74-14f4d2a45bed@github.com>

On Thu, 9 Feb 2023 13:10:43 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   AttributeElement.Kind removal (#48)
>
> src/java.base/share/classes/jdk/internal/classfile/constantpool/ConstantPoolBuilder.java line 98:
> 
>> 96:     <T> T optionValue(Classfile.Option.Key option);
>> 97: 
>> 98:     boolean canWriteDirect(ConstantPool constantPool);
> 
> Missing javadoc in these two methods.

Will fix it, thanks.

> src/java.base/share/classes/jdk/internal/classfile/constantpool/ConstantPoolBuilder.java line 187:
> 
>> 185:      * {@return A {@link ModuleEntry} describing the module whose name
>> 186:      * is encoded in the provided {@linkplain Utf8Entry}}
>> 187:      * If a Module entry in the pool already describes this class,
> 
> (Here and elsewhere) - Module is capitalized. Either you use a lower case name, or you use a capital name, to refer to `ModuleEntry`, or `CONSTANT_Module_info` - e.g. a standalone `Module` with capital `M` is not a concept in this API. (personally I think lower case is just fine).

Will fix it, thanks.

-------------

PR: https://git.openjdk.org/jdk/pull/10982

From redestad at openjdk.org  Wed Feb 15 09:29:55 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Wed, 15 Feb 2023 09:29:55 GMT
Subject: RFR: JDK-8300808: Accelerate Base64 on x86 for AVX2 [v17]
In-Reply-To: <pyveG7K_dGLMW9GwPkDJlP8UImU6fxTGbeKsP1ybaxk=.028a7a9b-1f79-43b9-baaa-bcae56f97e69@github.com>
References: <9zN3bjyMEikXYOlpjTy9_QPc-9usYiBJMUFdb-TaVrQ=.e8f65ce9-ac0f-4f8d-9c6b-b39ae1c26cd2@github.com>
 <pyveG7K_dGLMW9GwPkDJlP8UImU6fxTGbeKsP1ybaxk=.028a7a9b-1f79-43b9-baaa-bcae56f97e69@github.com>
Message-ID: <jevK4FawX9X591HQMC5e0HmXyEzGW8GjcrK3M8S4PTs=.9200d404-c860-44c3-8bdb-76ecf9b389de@github.com>

On Tue, 14 Feb 2023 18:22:32 GMT, Scott Gibbons <sgibbons at openjdk.org> wrote:

>> Added code for Base64 acceleration (encode and decode) which will accelerate ~4x for AVX2 platforms.
>> 
>> Encode performance:
>> **Old:**
>> 
>> Benchmark                      (maxNumBytes)   Mode  Cnt     Score   Error   Units
>> Base64Encode.testBase64Encode           1024  thrpt    3  4309.439 ? 2.632  ops/ms
>> 
>> 
>> **New:**
>> 
>> Benchmark                      (maxNumBytes)   Mode  Cnt      Score     Error   Units
>> Base64Encode.testBase64Encode           1024  thrpt    3  24211.397 ? 102.026  ops/ms
>> 
>> 
>> Decode performance:
>> **Old:**
>> 
>> Benchmark                      (errorIndex)  (lineSize)  (maxNumBytes)   Mode  Cnt     Score    Error   Units
>> Base64Decode.testBase64Decode           144           4           1024  thrpt    3  3961.768 ? 93.409  ops/ms
>> 
>> **New:**
>> Benchmark                      (errorIndex)  (lineSize)  (maxNumBytes)   Mode  Cnt      Score    Error   Units
>> Base64Decode.testBase64Decode           144           4           1024  thrpt    3  14738.051 ? 24.383  ops/ms
>
> Scott Gibbons has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Last of review comments

No problem! Testing looks good.

-------------

PR: https://git.openjdk.org/jdk/pull/12126

From sgibbons at openjdk.org  Wed Feb 15 09:29:57 2023
From: sgibbons at openjdk.org (Scott Gibbons)
Date: Wed, 15 Feb 2023 09:29:57 GMT
Subject: Integrated: JDK-8300808: Accelerate Base64 on x86 for AVX2
In-Reply-To: <9zN3bjyMEikXYOlpjTy9_QPc-9usYiBJMUFdb-TaVrQ=.e8f65ce9-ac0f-4f8d-9c6b-b39ae1c26cd2@github.com>
References: <9zN3bjyMEikXYOlpjTy9_QPc-9usYiBJMUFdb-TaVrQ=.e8f65ce9-ac0f-4f8d-9c6b-b39ae1c26cd2@github.com>
Message-ID: <fpHqCN5oC7XD-9kNVmbaMeja3B8Teg7XubS6FCD3HoM=.c97414eb-32ed-4637-9fca-e75ebe37ca28@github.com>

On Sat, 21 Jan 2023 00:15:10 GMT, Scott Gibbons <sgibbons at openjdk.org> wrote:

> Added code for Base64 acceleration (encode and decode) which will accelerate ~4x for AVX2 platforms.
> 
> Encode performance:
> **Old:**
> 
> Benchmark                      (maxNumBytes)   Mode  Cnt     Score   Error   Units
> Base64Encode.testBase64Encode           1024  thrpt    3  4309.439 ? 2.632  ops/ms
> 
> 
> **New:**
> 
> Benchmark                      (maxNumBytes)   Mode  Cnt      Score     Error   Units
> Base64Encode.testBase64Encode           1024  thrpt    3  24211.397 ? 102.026  ops/ms
> 
> 
> Decode performance:
> **Old:**
> 
> Benchmark                      (errorIndex)  (lineSize)  (maxNumBytes)   Mode  Cnt     Score    Error   Units
> Base64Decode.testBase64Decode           144           4           1024  thrpt    3  3961.768 ? 93.409  ops/ms
> 
> **New:**
> Benchmark                      (errorIndex)  (lineSize)  (maxNumBytes)   Mode  Cnt      Score    Error   Units
> Base64Decode.testBase64Decode           144           4           1024  thrpt    3  14738.051 ? 24.383  ops/ms

This pull request has now been integrated.

Changeset: 33bec207
Author:    Scott Gibbons <sgibbons at openjdk.org>
Committer: Claes Redestad <redestad at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/33bec207103acd520eb99afb093cfafa44aecfda
Stats:     234 lines in 7 files changed: 208 ins; 5 del; 21 mod

8300808: Accelerate Base64 on x86 for AVX2

Reviewed-by: jbhateja, redestad, sviswanathan

-------------

PR: https://git.openjdk.org/jdk/pull/12126

From asotona at openjdk.org  Wed Feb 15 09:53:01 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Wed, 15 Feb 2023 09:53:01 GMT
Subject: RFR: 8294982: Implementation of Classfile API [v15]
In-Reply-To: <hUvPqC4427nX8mcEcC5Tr90RFXAtmNigTxexY_Ujf04=.55b5e41d-afa7-4220-b13f-6fb0dd25dd0e@github.com>
References: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
 <hr8eti6ytvV05JFRr5hYLWy7yBla9mpI8vKKfaaFR-k=.a92f7bea-6400-4f95-a40c-d57192013f19@github.com>
 <hUvPqC4427nX8mcEcC5Tr90RFXAtmNigTxexY_Ujf04=.55b5e41d-afa7-4220-b13f-6fb0dd25dd0e@github.com>
Message-ID: <uwS4lAi9bPpXub-KbDvu2-VAsFDweNW0P7eYG-Ky0bg=.5c818fa2-5b79-4dc5-be71-8c3e965ab435@github.com>

On Thu, 9 Feb 2023 13:17:30 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   AttributeElement.Kind removal (#48)
>
> src/java.base/share/classes/jdk/internal/classfile/Classfile.java line 66:
> 
>> 64:      * @param <V> the type of the optional value
>> 65:      */
>> 66:     public sealed interface Option<V> permits Options.OptionValue {
> 
> After looking more at the usages of Options it is not clear to me as to why generics are needed. Lookup is always performed using a non-generic Option.Key - so the API code has to be unchecked anyway. In fact, I'm not even sure you need a `value()` method. When looking at usages, Option is mostly something you create when you need to pass it to something else (e.g. a constant pool, etc.). Since the client has created the option, it is not clear to me that the client has a need to access the option value (which the API implementation can access internally by other means).

You are right, I've tried to remove generics from `Option` and `Option::value` method and it didn't have any impact on any use case we have.
All access to the `Option` value is done through `ClassReader::optionValue` or `ConstantPoolBuilder::optionValue`, there was no use of `Option::value` at all.
I think it is valuable API cleanup, thanks!

-------------

PR: https://git.openjdk.org/jdk/pull/10982

From sgehwolf at openjdk.org  Wed Feb 15 09:54:47 2023
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Wed, 15 Feb 2023 09:54:47 GMT
Subject: RFR: 8302325: Wrong comment in
 java.base/share/native/libjimage/imageFile.hpp [v3]
In-Reply-To: <Fjsgyb1HcvileyovnmBohpDdwG8TB7AEz9fw0DdiR2s=.3554befb-5569-4509-ad48-9e08ec69fe2c@github.com>
References: <ThM7YJ5rlOnQWHBmPQGzPcQ-vrBiR_-OgJL46jeJIV8=.0e736e79-1fe3-40bb-8702-165028592e1c@github.com>
 <Fjsgyb1HcvileyovnmBohpDdwG8TB7AEz9fw0DdiR2s=.3554befb-5569-4509-ad48-9e08ec69fe2c@github.com>
Message-ID: <A-mSFNYEOu1aMBggSPKViYPPPvTqvEP7wj0dGMLUUXc=.195bd1de-7de4-411d-9ec1-ac5e3df713a5@github.com>

On Tue, 14 Feb 2023 19:30:19 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> Could I please get a review of this trivial comment-only change? `imageFile.hpp`
>> describes some properties of the jimage file `lib/modules`. However, I don't think
>> the comment example matches current code in the JDK. [`ATTRIBUTE_OFFSET`](https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/jdk/internal/jimage/ImageLocation.java#L44) get
>> written to the image file with value `0x05` while the comment mentions it gets
>> written as `0x04`. I propose to fix the comment so that it matches the code.
>> 
>> In passing, I've also fixed a comment related to `ATTRIBUTE_END`. I think the point
>> being made there is about byte values of `[0x01..0x07]`, all would represent
>> `ATTRIBUTE_END`, as the upper `5` bits would be `0`. Therefore, byte `0x01` would equally
>> represent `ATTRIBUTE_END` as would `0x00` and `0x07` or any value in between.
>> 
>> Thoughts?
>
> Severin Gehwolf has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Another fixup.
>  - Correct comment in imageFile.hpp
>  - Copyright update in PerfectHashBuilder

Thanks for the reviews!

-------------

PR: https://git.openjdk.org/jdk/pull/12533

From duke at openjdk.org  Wed Feb 15 09:55:36 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Wed, 15 Feb 2023 09:55:36 GMT
Subject: RFR: 8301873: Avoid string decoding in ZipFile.Source.getEntryPos
 [v13]
In-Reply-To: <FkmdspiHVjkAKFqm5kUgwaf55YH5cBbczS_3krqsdFs=.05eca901-f55f-47d9-b1bc-0cf2f5b87536@github.com>
References: <FkmdspiHVjkAKFqm5kUgwaf55YH5cBbczS_3krqsdFs=.05eca901-f55f-47d9-b1bc-0cf2f5b87536@github.com>
Message-ID: <m_QdbKFg_P5Xau4LSMHbYmd3MHF8vi8VbJCRmO2Zml4=.afba0ee0-10b2-471f-913e-c203f49c336e@github.com>

> After finding a hash match, getEntryPos needs to compare the lookup name up to the encoded entry name in the CEN. This comparison is done by decoding the entry name into a String. The names can then be compared using the String API. This decoding step adds a significat cost to this method.
> 
> This PR suggest to update the string comparison such that in the common case where  both the lookup name and the entry name are encoded in ASCII-compatible UTF-8,  decoding can be avoided and the byte arrays can instead be compared direcly. 
> 
> ZipCoder is updated with a new method to compare a string with an encoded byte array range.  The default implementation decodes to string (like the current code), while the UTF-8 implementation uses JavaLangAccess.getBytesNoRepl to get the  bytes. Both methods thes uses Arrays.mismatch for comparison with or without matching trailing slashes. 
> 
> Additionally, this PR suggest to make the following updates to getEntryPos:
> 
> - The try/catch for IAE is redundant and can be safely removed. (initCEN already checks this and will throws IAE for invalid UTF-8). This seems to give a 3-4% speedup on micros)
> - A new test InvalidBytesInEntryNameOrComment is a added to verify that initCEN does in fact reject invalid UTF-8 in CEN file names and comments. (I found no existing test coverage for this)
> - The recursion when looking for "name/" matches is replaced with iteration. We keep track of any "name/" match and return it at the end of the search. (I feel this is easier to follow and it also gives a ~30% speedup for addSlash lookups with no regression on regular lookups)
> 
> (My though is that including these additional updates in this PR might reduce reviewer overhead given that it touches the exact same code. I might be wrong on this, please advise :)
> 
> I'm seeing a ~17% saving on the micro ZipFileGetEntry.getEntryHit (modified to use xalan.jar):
> 
> Baseline:
> 
> Benchmark                             (size)  Mode  Cnt    Score   Error  Units
> ZipFileGetEntry.getEntryHit              512  avgt   15   74.941 ? 1.004  ns/op
> ZipFileGetEntry.getEntryHit             1024  avgt   15   84.943 ? 1.320  ns/op
> ZipFileGetEntry.getEntryHitUncached      512  avgt   15  120.371 ? 2.386  ns/op
> ZipFileGetEntry.getEntryHitUncached     1024  avgt   15  126.128 ? 1.075  ns/op
> ZipFileGetEntry.getEntryMiss             512  avgt   15   23.818 ? 0.838  ns/op
> ZipFileGetEntry.getEntryMiss            1024  avgt   15   29.762 ? 5.998  ns/op
> ZipFileGetEntry.getEntryMissUncached     512  avgt   15   59.405 ? 0.545  ns/op
> ZipFileGetEntry.getEntryMissUncached    1024  avgt   15   71.840 ? 2.455  ns/op
> ZipFileGetEntry.getEntrySlash            512  avgt   15  135.621 ? 4.341  ns/op
> ZipFileGetEntry.getEntrySlash           1024  avgt   15  134.190 ? 2.141  ns/op
> 
> 
> 
> PR:
> 
> 
> Benchmark                             (size)  Mode  Cnt    Score   Error  Units
> ZipFileGetEntry.getEntryHit              512  avgt   15   62.267 ? 1.329  ns/op
> ZipFileGetEntry.getEntryHit             1024  avgt   15   72.916 ? 2.428  ns/op
> ZipFileGetEntry.getEntryHitUncached      512  avgt   15  101.630 ? 1.154  ns/op
> ZipFileGetEntry.getEntryHitUncached     1024  avgt   15  113.161 ? 0.502  ns/op
> ZipFileGetEntry.getEntryMiss             512  avgt   15   23.003 ? 1.191  ns/op
> ZipFileGetEntry.getEntryMiss            1024  avgt   15   23.236 ? 1.114  ns/op
> ZipFileGetEntry.getEntryMissUncached     512  avgt   15   56.781 ? 1.505  ns/op
> ZipFileGetEntry.getEntryMissUncached    1024  avgt   15   67.767 ? 1.963  ns/op
> ZipFileGetEntry.getEntrySlash            512  avgt   15   73.745 ? 2.717  ns/op
> ZipFileGetEntry.getEntrySlash           1024  avgt   15   75.784 ? 1.051  ns/op
> 
> 
> To assess the impact on startup/warmup, I made a main method class which measures the total time of calling ZipFile.getEntry for all entries in the 109 JAR file dependenies of spring-petclinic. The shows a nice improvement (time in micros):
> 
> 
> Percentile Baseline Patch
> 50?%          23155 21149
> 75?%          23598 21454
> 90?%          23989 21691
> 95?%          24238 21973
> 99?%          25270 22446
> STDEV           792   549
> Count           500   500

Eirik Bjorsnos has updated the pull request incrementally with one additional commit since the last revision:

  Inline openZipFile and remove TwR

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12290/files
  - new: https://git.openjdk.org/jdk/pull/12290/files/4981abd3..49ad8d35

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12290&range=12
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12290&range=11-12

  Stats: 7 lines in 1 file changed: 0 ins; 5 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/12290.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12290/head:pull/12290

PR: https://git.openjdk.org/jdk/pull/12290

From sgehwolf at openjdk.org  Wed Feb 15 09:57:55 2023
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Wed, 15 Feb 2023 09:57:55 GMT
Subject: Integrated: 8302325: Wrong comment in
 java.base/share/native/libjimage/imageFile.hpp
In-Reply-To: <ThM7YJ5rlOnQWHBmPQGzPcQ-vrBiR_-OgJL46jeJIV8=.0e736e79-1fe3-40bb-8702-165028592e1c@github.com>
References: <ThM7YJ5rlOnQWHBmPQGzPcQ-vrBiR_-OgJL46jeJIV8=.0e736e79-1fe3-40bb-8702-165028592e1c@github.com>
Message-ID: <YqwLI0YDT6oB4zk5U2RhvhPYGVG-RR4MNSRfGe4gCMw=.a9c22c88-4227-41b5-9f87-1f6b972aae4b@github.com>

On Mon, 13 Feb 2023 14:12:15 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

> Could I please get a review of this trivial comment-only change? `imageFile.hpp`
> describes some properties of the jimage file `lib/modules`. However, I don't think
> the comment example matches current code in the JDK. [`ATTRIBUTE_OFFSET`](https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/jdk/internal/jimage/ImageLocation.java#L44) get
> written to the image file with value `0x05` while the comment mentions it gets
> written as `0x04`. I propose to fix the comment so that it matches the code.
> 
> In passing, I've also fixed a comment related to `ATTRIBUTE_END`. I think the point
> being made there is about byte values of `[0x01..0x07]`, all would represent
> `ATTRIBUTE_END`, as the upper `5` bits would be `0`. Therefore, byte `0x01` would equally
> represent `ATTRIBUTE_END` as would `0x00` and `0x07` or any value in between.
> 
> Thoughts?

This pull request has now been integrated.

Changeset: 11194e8b
Author:    Severin Gehwolf <sgehwolf at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/11194e8b825ad2688f4ede35fdadb69d74c7a5f4
Stats:     10 lines in 3 files changed: 0 ins; 0 del; 10 mod

8302325: Wrong comment in java.base/share/native/libjimage/imageFile.hpp

Reviewed-by: alanb, jlaskey

-------------

PR: https://git.openjdk.org/jdk/pull/12533

From duke at openjdk.org  Wed Feb 15 09:57:55 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Wed, 15 Feb 2023 09:57:55 GMT
Subject: RFR: 8301873: Avoid string decoding in ZipFile.Source.getEntryPos
 [v12]
In-Reply-To: <u-HyL-nwKSkC6ncp-Iug9TukKdw6Lzwbpw-9OIElPx8=.e7b40009-b4a7-4384-995b-21367162935b@github.com>
References: <FkmdspiHVjkAKFqm5kUgwaf55YH5cBbczS_3krqsdFs=.05eca901-f55f-47d9-b1bc-0cf2f5b87536@github.com>
 <Jm8UwXfOkwCmOyEgHBg1TdID9KsbFNVnqfRwKwkKmQE=.cc5bdbe5-0724-4562-b6b1-ab11ce587580@github.com>
 <u-HyL-nwKSkC6ncp-Iug9TukKdw6Lzwbpw-9OIElPx8=.e7b40009-b4a7-4384-995b-21367162935b@github.com>
Message-ID: <rclov7EzAK0x14CjBCICkGmUcdyRO04YpTdCIz3FxLo=.22860aae-623c-4414-a7a4-af4348436772@github.com>

On Tue, 14 Feb 2023 23:12:38 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> Eirik Bjorsnos has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Prefer expectThrows with asserts over test annotation regex
>
> test/jdk/java/util/zip/ZipFile/InvalidBytesInEntryNameOrComment.java line 91:
> 
>> 89:     public void shouldRejectInvalidName() throws IOException {
>> 90:         ZipException ex = expectThrows(ZipException.class, () -> {
>> 91:             openZipFile(invalidName);
> 
> You could just do
> 
> 
> ZipException ex = expectThrows(ZipException.class, () -> {
>              new ZipFile(invalidName.toFile())
> });
> 
> versus adding _openZipFile()_

The habit of opening resources in a TwR is hard to break, but I guess it's ok for a test like this. I have inlined the method and removed the TwR.

-------------

PR: https://git.openjdk.org/jdk/pull/12290

From asotona at openjdk.org  Wed Feb 15 10:12:00 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Wed, 15 Feb 2023 10:12:00 GMT
Subject: RFR: 8294982: Implementation of Classfile API [v17]
In-Reply-To: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
References: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
Message-ID: <BImLG8Uet-vMhECdS5bPvUsZ1_Xcv_ntNqKra0-fHc0=.3876b159-e703-4142-a12c-5c547fa04c76@github.com>

> This is root pull request with Classfile API implementation, tests and benchmarks initial drop into JDK.
> 
> Following pull requests consolidating JDK class files parsing, generating, and transforming ([JDK-8294957](https://bugs.openjdk.org/browse/JDK-8294957)) will chain to this one.
> 
> Classfile API development is tracked at:
> https://github.com/openjdk/jdk-sandbox/tree/classfile-api-branch
> 
> Development branch of consolidated JDK class files parsing, generating, and transforming is at:
> https://github.com/openjdk/jdk-sandbox/tree/classfile-api-dev-branch
> 
> Classfile API [JEP](https://bugs.openjdk.org/browse/JDK-8280389) and [online API documentation](https://htmlpreview.github.io/?https://raw.githubusercontent.com/openjdk/jdk-sandbox/classfile-api-javadoc-branch/doc/classfile-api/javadoc/java.base/jdk/internal/classfile/package-summary.html) is also available.
> 
> Please take you time to review this non-trivial JDK addition.
> 
> Thank you,
> Adam

Adam Sotona has updated the pull request incrementally with two additional commits since the last revision:

 - removed generics from Classfile.Option
 - Javadoc fixes

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10982/files
  - new: https://git.openjdk.org/jdk/pull/10982/files/ec6829e9..673887ab

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10982&range=16
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10982&range=15-16

  Stats: 78 lines in 10 files changed: 15 ins; 4 del; 59 mod
  Patch: https://git.openjdk.org/jdk/pull/10982.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10982/head:pull/10982

PR: https://git.openjdk.org/jdk/pull/10982

From duke at openjdk.org  Wed Feb 15 10:13:51 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Wed, 15 Feb 2023 10:13:51 GMT
Subject: RFR: 8301873: Avoid string decoding in ZipFile.Source.getEntryPos
 [v14]
In-Reply-To: <FkmdspiHVjkAKFqm5kUgwaf55YH5cBbczS_3krqsdFs=.05eca901-f55f-47d9-b1bc-0cf2f5b87536@github.com>
References: <FkmdspiHVjkAKFqm5kUgwaf55YH5cBbczS_3krqsdFs=.05eca901-f55f-47d9-b1bc-0cf2f5b87536@github.com>
Message-ID: <aUBsP2Q6WMHpdopp7xIcdJW0OlR2CW8vUru8rM4Yw-s=.34631bad-8389-4892-b9aa-831f7ec80dab@github.com>

> After finding a hash match, getEntryPos needs to compare the lookup name up to the encoded entry name in the CEN. This comparison is done by decoding the entry name into a String. The names can then be compared using the String API. This decoding step adds a significat cost to this method.
> 
> This PR suggest to update the string comparison such that in the common case where  both the lookup name and the entry name are encoded in ASCII-compatible UTF-8,  decoding can be avoided and the byte arrays can instead be compared direcly. 
> 
> ZipCoder is updated with a new method to compare a string with an encoded byte array range.  The default implementation decodes to string (like the current code), while the UTF-8 implementation uses JavaLangAccess.getBytesNoRepl to get the  bytes. Both methods thes uses Arrays.mismatch for comparison with or without matching trailing slashes. 
> 
> Additionally, this PR suggest to make the following updates to getEntryPos:
> 
> - The try/catch for IAE is redundant and can be safely removed. (initCEN already checks this and will throws IAE for invalid UTF-8). This seems to give a 3-4% speedup on micros)
> - A new test InvalidBytesInEntryNameOrComment is a added to verify that initCEN does in fact reject invalid UTF-8 in CEN file names and comments. (I found no existing test coverage for this)
> - The recursion when looking for "name/" matches is replaced with iteration. We keep track of any "name/" match and return it at the end of the search. (I feel this is easier to follow and it also gives a ~30% speedup for addSlash lookups with no regression on regular lookups)
> 
> (My though is that including these additional updates in this PR might reduce reviewer overhead given that it touches the exact same code. I might be wrong on this, please advise :)
> 
> I'm seeing a ~17% saving on the micro ZipFileGetEntry.getEntryHit (modified to use xalan.jar):
> 
> Baseline:
> 
> Benchmark                             (size)  Mode  Cnt    Score   Error  Units
> ZipFileGetEntry.getEntryHit              512  avgt   15   74.941 ? 1.004  ns/op
> ZipFileGetEntry.getEntryHit             1024  avgt   15   84.943 ? 1.320  ns/op
> ZipFileGetEntry.getEntryHitUncached      512  avgt   15  120.371 ? 2.386  ns/op
> ZipFileGetEntry.getEntryHitUncached     1024  avgt   15  126.128 ? 1.075  ns/op
> ZipFileGetEntry.getEntryMiss             512  avgt   15   23.818 ? 0.838  ns/op
> ZipFileGetEntry.getEntryMiss            1024  avgt   15   29.762 ? 5.998  ns/op
> ZipFileGetEntry.getEntryMissUncached     512  avgt   15   59.405 ? 0.545  ns/op
> ZipFileGetEntry.getEntryMissUncached    1024  avgt   15   71.840 ? 2.455  ns/op
> ZipFileGetEntry.getEntrySlash            512  avgt   15  135.621 ? 4.341  ns/op
> ZipFileGetEntry.getEntrySlash           1024  avgt   15  134.190 ? 2.141  ns/op
> 
> 
> 
> PR:
> 
> 
> Benchmark                             (size)  Mode  Cnt    Score   Error  Units
> ZipFileGetEntry.getEntryHit              512  avgt   15   62.267 ? 1.329  ns/op
> ZipFileGetEntry.getEntryHit             1024  avgt   15   72.916 ? 2.428  ns/op
> ZipFileGetEntry.getEntryHitUncached      512  avgt   15  101.630 ? 1.154  ns/op
> ZipFileGetEntry.getEntryHitUncached     1024  avgt   15  113.161 ? 0.502  ns/op
> ZipFileGetEntry.getEntryMiss             512  avgt   15   23.003 ? 1.191  ns/op
> ZipFileGetEntry.getEntryMiss            1024  avgt   15   23.236 ? 1.114  ns/op
> ZipFileGetEntry.getEntryMissUncached     512  avgt   15   56.781 ? 1.505  ns/op
> ZipFileGetEntry.getEntryMissUncached    1024  avgt   15   67.767 ? 1.963  ns/op
> ZipFileGetEntry.getEntrySlash            512  avgt   15   73.745 ? 2.717  ns/op
> ZipFileGetEntry.getEntrySlash           1024  avgt   15   75.784 ? 1.051  ns/op
> 
> 
> To assess the impact on startup/warmup, I made a main method class which measures the total time of calling ZipFile.getEntry for all entries in the 109 JAR file dependenies of spring-petclinic. The shows a nice improvement (time in micros):
> 
> 
> Percentile Baseline Patch
> 50?%          23155 21149
> 75?%          23598 21454
> 90?%          23989 21691
> 95?%          24238 21973
> 99?%          25270 22446
> STDEV           792   549
> Count           500   500

Eirik Bjorsnos has updated the pull request incrementally with one additional commit since the last revision:

  Update javadocs for ZipCoder.Comparison to first clarify that the "encoded string" refers to those found in the CEN byte array and to use the term "the encoded string" instead of the more convoluted "the string encoded in the byte array".

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12290/files
  - new: https://git.openjdk.org/jdk/pull/12290/files/49ad8d35..9b83002a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12290&range=13
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12290&range=12-13

  Stats: 10 lines in 1 file changed: 0 ins; 2 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/12290.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12290/head:pull/12290

PR: https://git.openjdk.org/jdk/pull/12290

From lancea at openjdk.org  Wed Feb 15 11:35:48 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Wed, 15 Feb 2023 11:35:48 GMT
Subject: RFR: 8301873: Avoid string decoding in ZipFile.Source.getEntryPos
 [v12]
In-Reply-To: <rclov7EzAK0x14CjBCICkGmUcdyRO04YpTdCIz3FxLo=.22860aae-623c-4414-a7a4-af4348436772@github.com>
References: <FkmdspiHVjkAKFqm5kUgwaf55YH5cBbczS_3krqsdFs=.05eca901-f55f-47d9-b1bc-0cf2f5b87536@github.com>
 <Jm8UwXfOkwCmOyEgHBg1TdID9KsbFNVnqfRwKwkKmQE=.cc5bdbe5-0724-4562-b6b1-ab11ce587580@github.com>
 <u-HyL-nwKSkC6ncp-Iug9TukKdw6Lzwbpw-9OIElPx8=.e7b40009-b4a7-4384-995b-21367162935b@github.com>
 <rclov7EzAK0x14CjBCICkGmUcdyRO04YpTdCIz3FxLo=.22860aae-623c-4414-a7a4-af4348436772@github.com>
Message-ID: <ctLS4d0pc7vDoM_iTDNcTjjfJ-u2hS9_nRcWRwJC32c=.5e2e8486-233a-44c2-90ae-f461a485b1b4@github.com>

On Wed, 15 Feb 2023 09:55:04 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

> The habit of opening resources in a TwR is hard to break, but I guess it's ok for a test like this. I have inlined the method and removed the TwR.

Agree, thanks for addressing the suggestion as it makes the test cleaner given expects/assertThrows should  react to the Exception being thrown by `new ZipFile(...)`

-------------

PR: https://git.openjdk.org/jdk/pull/12290

From duke at openjdk.org  Wed Feb 15 11:44:17 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Wed, 15 Feb 2023 11:44:17 GMT
Subject: RFR: 8301873: Avoid string decoding in ZipFile.Source.getEntryPos
 [v15]
In-Reply-To: <FkmdspiHVjkAKFqm5kUgwaf55YH5cBbczS_3krqsdFs=.05eca901-f55f-47d9-b1bc-0cf2f5b87536@github.com>
References: <FkmdspiHVjkAKFqm5kUgwaf55YH5cBbczS_3krqsdFs=.05eca901-f55f-47d9-b1bc-0cf2f5b87536@github.com>
Message-ID: <2Ab-zkCiRlWL6S2TCDzeauJfvacWxgFlC0LpLmeUVhA=.6ff1c130-8e83-4b41-b1bb-9741d068664b@github.com>

> After finding a hash match, getEntryPos needs to compare the lookup name up to the encoded entry name in the CEN. This comparison is done by decoding the entry name into a String. The names can then be compared using the String API. This decoding step adds a significat cost to this method.
> 
> This PR suggest to update the string comparison such that in the common case where  both the lookup name and the entry name are encoded in ASCII-compatible UTF-8,  decoding can be avoided and the byte arrays can instead be compared direcly. 
> 
> ZipCoder is updated with a new method to compare a string with an encoded byte array range.  The default implementation decodes to string (like the current code), while the UTF-8 implementation uses JavaLangAccess.getBytesNoRepl to get the  bytes. Both methods thes uses Arrays.mismatch for comparison with or without matching trailing slashes. 
> 
> Additionally, this PR suggest to make the following updates to getEntryPos:
> 
> - The try/catch for IAE is redundant and can be safely removed. (initCEN already checks this and will throws IAE for invalid UTF-8). This seems to give a 3-4% speedup on micros)
> - A new test InvalidBytesInEntryNameOrComment is a added to verify that initCEN does in fact reject invalid UTF-8 in CEN file names and comments. (I found no existing test coverage for this)
> - The recursion when looking for "name/" matches is replaced with iteration. We keep track of any "name/" match and return it at the end of the search. (I feel this is easier to follow and it also gives a ~30% speedup for addSlash lookups with no regression on regular lookups)
> 
> (My though is that including these additional updates in this PR might reduce reviewer overhead given that it touches the exact same code. I might be wrong on this, please advise :)
> 
> I'm seeing a ~17% saving on the micro ZipFileGetEntry.getEntryHit (modified to use xalan.jar):
> 
> Baseline:
> 
> Benchmark                             (size)  Mode  Cnt    Score   Error  Units
> ZipFileGetEntry.getEntryHit              512  avgt   15   74.941 ? 1.004  ns/op
> ZipFileGetEntry.getEntryHit             1024  avgt   15   84.943 ? 1.320  ns/op
> ZipFileGetEntry.getEntryHitUncached      512  avgt   15  120.371 ? 2.386  ns/op
> ZipFileGetEntry.getEntryHitUncached     1024  avgt   15  126.128 ? 1.075  ns/op
> ZipFileGetEntry.getEntryMiss             512  avgt   15   23.818 ? 0.838  ns/op
> ZipFileGetEntry.getEntryMiss            1024  avgt   15   29.762 ? 5.998  ns/op
> ZipFileGetEntry.getEntryMissUncached     512  avgt   15   59.405 ? 0.545  ns/op
> ZipFileGetEntry.getEntryMissUncached    1024  avgt   15   71.840 ? 2.455  ns/op
> ZipFileGetEntry.getEntrySlash            512  avgt   15  135.621 ? 4.341  ns/op
> ZipFileGetEntry.getEntrySlash           1024  avgt   15  134.190 ? 2.141  ns/op
> 
> 
> 
> PR:
> 
> 
> Benchmark                             (size)  Mode  Cnt    Score   Error  Units
> ZipFileGetEntry.getEntryHit              512  avgt   15   62.267 ? 1.329  ns/op
> ZipFileGetEntry.getEntryHit             1024  avgt   15   72.916 ? 2.428  ns/op
> ZipFileGetEntry.getEntryHitUncached      512  avgt   15  101.630 ? 1.154  ns/op
> ZipFileGetEntry.getEntryHitUncached     1024  avgt   15  113.161 ? 0.502  ns/op
> ZipFileGetEntry.getEntryMiss             512  avgt   15   23.003 ? 1.191  ns/op
> ZipFileGetEntry.getEntryMiss            1024  avgt   15   23.236 ? 1.114  ns/op
> ZipFileGetEntry.getEntryMissUncached     512  avgt   15   56.781 ? 1.505  ns/op
> ZipFileGetEntry.getEntryMissUncached    1024  avgt   15   67.767 ? 1.963  ns/op
> ZipFileGetEntry.getEntrySlash            512  avgt   15   73.745 ? 2.717  ns/op
> ZipFileGetEntry.getEntrySlash           1024  avgt   15   75.784 ? 1.051  ns/op
> 
> 
> To assess the impact on startup/warmup, I made a main method class which measures the total time of calling ZipFile.getEntry for all entries in the 109 JAR file dependenies of spring-petclinic. The shows a nice improvement (time in micros):
> 
> 
> Percentile Baseline Patch
> 50?%          23155 21149
> 75?%          23598 21454
> 90?%          23989 21691
> 95?%          24238 21973
> 99?%          25270 22446
> STDEV           792   549
> Count           500   500

Eirik Bjorsnos has updated the pull request incrementally with one additional commit since the last revision:

  Fix a regression where the invalidName was tested instead of comment in the invalid comment test

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12290/files
  - new: https://git.openjdk.org/jdk/pull/12290/files/9b83002a..08160a1a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12290&range=14
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12290&range=13-14

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/12290.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12290/head:pull/12290

PR: https://git.openjdk.org/jdk/pull/12290

From duke at openjdk.org  Wed Feb 15 11:44:17 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Wed, 15 Feb 2023 11:44:17 GMT
Subject: RFR: 8301873: Avoid string decoding in ZipFile.Source.getEntryPos
 [v12]
In-Reply-To: <ctLS4d0pc7vDoM_iTDNcTjjfJ-u2hS9_nRcWRwJC32c=.5e2e8486-233a-44c2-90ae-f461a485b1b4@github.com>
References: <FkmdspiHVjkAKFqm5kUgwaf55YH5cBbczS_3krqsdFs=.05eca901-f55f-47d9-b1bc-0cf2f5b87536@github.com>
 <Jm8UwXfOkwCmOyEgHBg1TdID9KsbFNVnqfRwKwkKmQE=.cc5bdbe5-0724-4562-b6b1-ab11ce587580@github.com>
 <u-HyL-nwKSkC6ncp-Iug9TukKdw6Lzwbpw-9OIElPx8=.e7b40009-b4a7-4384-995b-21367162935b@github.com>
 <rclov7EzAK0x14CjBCICkGmUcdyRO04YpTdCIz3FxLo=.22860aae-623c-4414-a7a4-af4348436772@github.com>
 <ctLS4d0pc7vDoM_iTDNcTjjfJ-u2hS9_nRcWRwJC32c=.5e2e8486-233a-44c2-90ae-f461a485b1b4@github.com>
Message-ID: <e49_4WJW4mV6ydPudH6DeMvcuUCBAUNFSYlJM77COWo=.5bfbf250-bfa6-45e5-943b-cf684d8359a2@github.com>

On Wed, 15 Feb 2023 11:32:32 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> The habit of opening resources in a TwR is hard to break, but I guess it's ok for a test like this. I have inlined the method and removed the TwR.
>
>> The habit of opening resources in a TwR is hard to break, but I guess it's ok for a test like this. I have inlined the method and removed the TwR.
> 
> Agree, thanks for addressing the suggestion as it makes the test cleaner given expects/assertThrows should  react to the Exception being thrown by `new ZipFile(...)`

My inlining accidentally made the shouldRejectInvalidComment test the invalid name file. Fixed with last commit.

-------------

PR: https://git.openjdk.org/jdk/pull/12290

From goetz at openjdk.org  Wed Feb 15 12:38:41 2023
From: goetz at openjdk.org (Goetz Lindenmaier)
Date: Wed, 15 Feb 2023 12:38:41 GMT
Subject: RFR: 8302158: PPC:
 test/jdk/jdk/internal/vm/Continuation/Fuzz.java: AssertionError: res: false
 shouldPin: false
In-Reply-To: <G-cEPYqp6JlMkj9qo0S9HuNXRiuROZ7q69FQYIsDewM=.d20f3ee3-ed25-4bd3-93cd-2a55faa515d3@github.com>
References: <G-cEPYqp6JlMkj9qo0S9HuNXRiuROZ7q69FQYIsDewM=.d20f3ee3-ed25-4bd3-93cd-2a55faa515d3@github.com>
Message-ID: <yILfzeqXkCcXs_zNtroZgfvvDry95Weea8kh2nrmg3U=.a7b275c6-1f1f-40a6-8d22-30f5f45d85cf@github.com>

On Tue, 14 Feb 2023 14:10:08 GMT, Richard Reingruber <rrich at openjdk.org> wrote:

> This fixes the linked issue by trimming the caller of a frame to be deoptimized back to its `unextended_sp` iff it is compiled. The creation of the section `dead after deoptimization` shown in the attachment [yield_after_deopt_failure.log](https://bugs.openjdk.org/secure/attachment/102602/yield_after_deopt_failure.log) is prevented by this.
> 
> A new mode is added to the test BasicExt.java where all frames are deoptimized after a yield operation. The issue can be deterministically reproduced with the new mode. It's not worth to execute all test cases with the new mode though. Instead `ContinuationCompiledFramesWithStackArgs_3c4` is always executed a 2nd time in this mode.
> 
> Before this BasicExt.java was refactored for better argument processing and representation of the test modes.
> Also the try-catch-clause in the main method had to be changed to rethrow the caught exception because without this the test would have succeeded.
> 
> Testing: jtreg tests tier 1-4 on standard platforms and also on ppc64le.

LGTM

src/hotspot/cpu/ppc/sharedRuntime_ppc.cpp line 3094:

> 3092: 
> 3093:   // Freezing continuation frames requires that the caller is trimmed to unextended sp if compiled.
> 3094:   Register caller_sp = R23_tmp3;

Can the caller be interpreted? I.e., not compiled?
Then it might be helpful to comment like
// If not compiled this contains sp() resulting in a resize of 0.

-------------

Marked as reviewed by goetz (Reviewer).

PR: https://git.openjdk.org/jdk/pull/12557

From asotona at openjdk.org  Wed Feb 15 12:43:41 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Wed, 15 Feb 2023 12:43:41 GMT
Subject: RFR: 8294982: Implementation of Classfile API [v18]
In-Reply-To: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
References: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
Message-ID: <D2hQAGJG72OP1HAHHQ-EQZku4l6bkDgtaYHqzyxQjJA=.4f3eb47b-0d20-4358-943c-cccfac02a31d@github.com>

> This is root pull request with Classfile API implementation, tests and benchmarks initial drop into JDK.
> 
> Following pull requests consolidating JDK class files parsing, generating, and transforming ([JDK-8294957](https://bugs.openjdk.org/browse/JDK-8294957)) will chain to this one.
> 
> Classfile API development is tracked at:
> https://github.com/openjdk/jdk-sandbox/tree/classfile-api-branch
> 
> Development branch of consolidated JDK class files parsing, generating, and transforming is at:
> https://github.com/openjdk/jdk-sandbox/tree/classfile-api-dev-branch
> 
> Classfile API [JEP](https://bugs.openjdk.org/browse/JDK-8280389) and [online API documentation](https://htmlpreview.github.io/?https://raw.githubusercontent.com/openjdk/jdk-sandbox/classfile-api-javadoc-branch/doc/classfile-api/javadoc/java.base/jdk/internal/classfile/package-summary.html) is also available.
> 
> Please take you time to review this non-trivial JDK addition.
> 
> Thank you,
> Adam

Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:

  added missing factory methods to ModuleExportInfo and ModuleOpenInfo

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10982/files
  - new: https://git.openjdk.org/jdk/pull/10982/files/673887ab..bb295b53

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10982&range=17
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10982&range=16-17

  Stats: 113 lines in 3 files changed: 113 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/10982.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10982/head:pull/10982

PR: https://git.openjdk.org/jdk/pull/10982

From asotona at openjdk.org  Wed Feb 15 14:12:13 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Wed, 15 Feb 2023 14:12:13 GMT
Subject: RFR: 8294982: Implementation of Classfile API [v15]
In-Reply-To: <scAqAuD2wQBhQdg_N1e5PPRJkmhwgCW-Mp__BajTxsw=.c73a8812-926e-4bf0-8e8f-7589a809b173@github.com>
References: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
 <hr8eti6ytvV05JFRr5hYLWy7yBla9mpI8vKKfaaFR-k=.a92f7bea-6400-4f95-a40c-d57192013f19@github.com>
 <scAqAuD2wQBhQdg_N1e5PPRJkmhwgCW-Mp__BajTxsw=.c73a8812-926e-4bf0-8e8f-7589a809b173@github.com>
Message-ID: <k1gsOcFRe-z6bT8ru55uLduJG3ZL1yW2bfFCtHCugxo=.700a49d0-df6e-4a15-866f-91dfbc5975c5@github.com>

On Thu, 9 Feb 2023 15:07:01 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   AttributeElement.Kind removal (#48)
>
> src/java.base/share/classes/jdk/internal/classfile/instruction/TypeCheckInstruction.java line 39:
> 
>> 37: 
>> 38: /**
>> 39:  * Models an {@code instanceof} or {@code checkcast} instruction in the {@code
> 
> This seems to model both `instanceof` and `checkcast`. The latter seems to overlap partially with `ConvertInstruction`.

`instanceof` and `checkcast` are both very similar type checking instructions. They have the same length, the same format, the same specification of the instruction parameters and almost the same behaviour.
All members of `ConvertInstruction` have no instruction parameters and source and target of conversion is identified from the opcode. Also the instructions do conversions and not type checking.
I don't see any averlap.

-------------

PR: https://git.openjdk.org/jdk/pull/10982

From asotona at openjdk.org  Wed Feb 15 14:15:39 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Wed, 15 Feb 2023 14:15:39 GMT
Subject: RFR: 8294982: Implementation of Classfile API [v15]
In-Reply-To: <scAqAuD2wQBhQdg_N1e5PPRJkmhwgCW-Mp__BajTxsw=.c73a8812-926e-4bf0-8e8f-7589a809b173@github.com>
References: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
 <hr8eti6ytvV05JFRr5hYLWy7yBla9mpI8vKKfaaFR-k=.a92f7bea-6400-4f95-a40c-d57192013f19@github.com>
 <scAqAuD2wQBhQdg_N1e5PPRJkmhwgCW-Mp__BajTxsw=.c73a8812-926e-4bf0-8e8f-7589a809b173@github.com>
Message-ID: <bdK2KXUQ_Do6CM-DG67hB5boHppibz_pnKOXyAYMSs4=.026ecfa5-edd1-4865-b8dc-7fdbc897c416@github.com>

On Thu, 9 Feb 2023 14:24:58 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   AttributeElement.Kind removal (#48)
>
> src/java.base/share/classes/jdk/internal/classfile/instruction/ConstantInstruction.java line 63:
> 
>> 61:      * aload_0}).
>> 62:      */
>> 63:     sealed interface IntrinsicConstantInstruction extends ConstantInstruction
> 
> I'm not super sure of the fine-grained distinction here. The constant pool variant is interesting (as you can ask for the associated constant entry) - but the distinction between intrinsics vs. argument seems rather weak.

They significantly differ in instruction formats and instruction format distinction is critical for some use cases.

-------------

PR: https://git.openjdk.org/jdk/pull/10982

From asotona at openjdk.org  Wed Feb 15 14:27:28 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Wed, 15 Feb 2023 14:27:28 GMT
Subject: RFR: 8294982: Implementation of Classfile API [v15]
In-Reply-To: <scAqAuD2wQBhQdg_N1e5PPRJkmhwgCW-Mp__BajTxsw=.c73a8812-926e-4bf0-8e8f-7589a809b173@github.com>
References: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
 <hr8eti6ytvV05JFRr5hYLWy7yBla9mpI8vKKfaaFR-k=.a92f7bea-6400-4f95-a40c-d57192013f19@github.com>
 <scAqAuD2wQBhQdg_N1e5PPRJkmhwgCW-Mp__BajTxsw=.c73a8812-926e-4bf0-8e8f-7589a809b173@github.com>
Message-ID: <PXzUXkDRw2F23g7ctTgVM7B_mXkSFoz_qpSPF_TEm84=.c09e2fcd-066f-4d96-9d0a-0d7f6320326e@github.com>

On Thu, 9 Feb 2023 14:18:56 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   AttributeElement.Kind removal (#48)
>
> src/java.base/share/classes/jdk/internal/classfile/instruction/CharacterRange.java line 47:
> 
>> 45:      * {@return the start of the instruction range}
>> 46:      */
>> 47:     Label startScope();
> 
> I noticed that this pattern of start/endScope is here, but also in ExceptionCatch, LocalVariable and LocalVariableType. Consider using a common interface for "instructions that are associated with a range".

That is interesting RFE, thanks.

> src/java.base/share/classes/jdk/internal/classfile/instruction/InvokeInstruction.java line 60:
> 
>> 58:      * {@return whether the class holding the method is an interface}
>> 59:      */
>> 60:     boolean isInterface();
> 
> This can also be tested with pattern matching on the MemberRefEntry?

Unfortunately the distinction is dynamic. As of my imagination pattern matching is not the best to model interface distinction of `InvokeInstruction`.

-------------

PR: https://git.openjdk.org/jdk/pull/10982

From asotona at openjdk.org  Wed Feb 15 14:48:23 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Wed, 15 Feb 2023 14:48:23 GMT
Subject: RFR: 8294982: Implementation of Classfile API [v15]
In-Reply-To: <hUvPqC4427nX8mcEcC5Tr90RFXAtmNigTxexY_Ujf04=.55b5e41d-afa7-4220-b13f-6fb0dd25dd0e@github.com>
References: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
 <hr8eti6ytvV05JFRr5hYLWy7yBla9mpI8vKKfaaFR-k=.a92f7bea-6400-4f95-a40c-d57192013f19@github.com>
 <hUvPqC4427nX8mcEcC5Tr90RFXAtmNigTxexY_Ujf04=.55b5e41d-afa7-4220-b13f-6fb0dd25dd0e@github.com>
Message-ID: <AlXHJrPQTNZLumUXhMQevc7Yk51W4pvWDsarWCe-NmU=.3c2573c2-03eb-43f2-9b85-ce607695208d@github.com>

On Thu, 9 Feb 2023 14:04:22 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   AttributeElement.Kind removal (#48)
>
> src/java.base/share/classes/jdk/internal/classfile/constantpool/MemberRefEntry.java line 62:
> 
>> 60:      * {@return whether this member is a method}
>> 61:      */
>> 62:     boolean isMethod();
> 
> this seems surprising - after all we have separate types for methods/fields.

I'll look at it - if still needed or just a relic.

-------------

PR: https://git.openjdk.org/jdk/pull/10982

From igraves at openjdk.org  Wed Feb 15 14:59:32 2023
From: igraves at openjdk.org (Ian Graves)
Date: Wed, 15 Feb 2023 14:59:32 GMT
Subject: RFR: 8293667: Align jlink's --compress option with jmod's
 --compress option [v6]
In-Reply-To: <vyutVhxGNbq9_B4NvgmAGqBKXNyG46AUlMGb68BG47k=.61d35f0b-a89c-412e-88e9-57d592db384f@github.com>
References: <JWevwHuR2vF3k-JRxmTAxfNN6g-EBkgG2N9DHn4fkGY=.f9768dfd-cab4-49a9-83b9-d77a1572e917@github.com>
 <p5a-3JyPNAPcY5YrBuDGkX9bKNuiwp56QHf2oIInGnc=.ef123257-baf4-4b2c-835c-745bd9899ba7@github.com>
 <vyutVhxGNbq9_B4NvgmAGqBKXNyG46AUlMGb68BG47k=.61d35f0b-a89c-412e-88e9-57d592db384f@github.com>
Message-ID: <NrBsTNLHMOGqYjlbVibWs7STrGzOn4KDyxdqm9U0EYA=.9b458286-46e8-4351-849a-32430a727edf@github.com>

On Tue, 14 Feb 2023 20:20:03 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> Ian Graves has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fixing up resources
>
> src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/CompactConstantPoolsPlugin.java line 48:
> 
>> 46: 
>> 47:     public CompactConstantPoolsPlugin() {
>> 48:         super("compact-constant-pools");
> 
> This plugin needs a better option name.   Maybe `--share-utf8-entries`?
> 
> I also wonder if anyone really uses this plugin.  It writes the shared UTF8 strings into the jimage.  It incurs overhead in reconstructing the constant pool when loading classes.    So I wonder if we just drop this plugin - @AlanBateman, @igraves what do you think?

I think that deprecating the entire plugin could be appropriate, given the overhead, unless there's some performance data to the contrary. I haven't seen much in favor of keeping it, but I do think that breaking it apart from zip before deprecating it is also fine.

-------------

PR: https://git.openjdk.org/jdk/pull/11617

From mdoerr at openjdk.org  Wed Feb 15 15:00:35 2023
From: mdoerr at openjdk.org (Martin Doerr)
Date: Wed, 15 Feb 2023 15:00:35 GMT
Subject: RFR: 8302158: PPC:
 test/jdk/jdk/internal/vm/Continuation/Fuzz.java: AssertionError: res: false
 shouldPin: false
In-Reply-To: <G-cEPYqp6JlMkj9qo0S9HuNXRiuROZ7q69FQYIsDewM=.d20f3ee3-ed25-4bd3-93cd-2a55faa515d3@github.com>
References: <G-cEPYqp6JlMkj9qo0S9HuNXRiuROZ7q69FQYIsDewM=.d20f3ee3-ed25-4bd3-93cd-2a55faa515d3@github.com>
Message-ID: <JLEGikuYY3E9ibksMGAParEvkGmjfdpBJbnDrWcPhDk=.13c21592-fb68-4481-852c-d8025340b594@github.com>

On Tue, 14 Feb 2023 14:10:08 GMT, Richard Reingruber <rrich at openjdk.org> wrote:

> This fixes the linked issue by trimming the caller of a frame to be deoptimized back to its `unextended_sp` iff it is compiled. The creation of the section `dead after deoptimization` shown in the attachment [yield_after_deopt_failure.log](https://bugs.openjdk.org/secure/attachment/102602/yield_after_deopt_failure.log) is prevented by this.
> 
> A new mode is added to the test BasicExt.java where all frames are deoptimized after a yield operation. The issue can be deterministically reproduced with the new mode. It's not worth to execute all test cases with the new mode though. Instead `ContinuationCompiledFramesWithStackArgs_3c4` is always executed a 2nd time in this mode.
> 
> Before this BasicExt.java was refactored for better argument processing and representation of the test modes.
> Also the try-catch-clause in the main method had to be changed to rethrow the caught exception because without this the test would have succeeded.
> 
> Testing: jtreg tests tier 1-4 on standard platforms and also on ppc64le.

LGTM. Thanks for fixing!

src/hotspot/cpu/ppc/frame_ppc.cpp line 424:

> 422: 
> 423: intptr_t *frame::initial_deoptimization_info() {
> 424:   // `this` is the caller of the deoptee. We want to trimm it, if compiled, to

I believe "to trim" should contain only one 'm' in English.

-------------

Marked as reviewed by mdoerr (Reviewer).

PR: https://git.openjdk.org/jdk/pull/12557

From asotona at openjdk.org  Wed Feb 15 15:22:25 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Wed, 15 Feb 2023 15:22:25 GMT
Subject: RFR: 8294982: Implementation of Classfile API [v15]
In-Reply-To: <AlXHJrPQTNZLumUXhMQevc7Yk51W4pvWDsarWCe-NmU=.3c2573c2-03eb-43f2-9b85-ce607695208d@github.com>
References: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
 <hr8eti6ytvV05JFRr5hYLWy7yBla9mpI8vKKfaaFR-k=.a92f7bea-6400-4f95-a40c-d57192013f19@github.com>
 <hUvPqC4427nX8mcEcC5Tr90RFXAtmNigTxexY_Ujf04=.55b5e41d-afa7-4220-b13f-6fb0dd25dd0e@github.com>
 <AlXHJrPQTNZLumUXhMQevc7Yk51W4pvWDsarWCe-NmU=.3c2573c2-03eb-43f2-9b85-ce607695208d@github.com>
Message-ID: <0cxv9q54041aXExLC6lQgy5m4tsIRIA51x4OLx-dBdk=.b799739b-d6dc-4a94-9d46-dd3167f2f36c@github.com>

On Wed, 15 Feb 2023 14:45:32 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/classfile/constantpool/MemberRefEntry.java line 62:
>> 
>>> 60:      * {@return whether this member is a method}
>>> 61:      */
>>> 62:     boolean isMethod();
>> 
>> this seems surprising - after all we have separate types for methods/fields.
>
> I'll look at it - if still needed or just a relic.

Yes, it is possible to remove this method completely.

-------------

PR: https://git.openjdk.org/jdk/pull/10982

From asotona at openjdk.org  Wed Feb 15 15:25:41 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Wed, 15 Feb 2023 15:25:41 GMT
Subject: RFR: 8294982: Implementation of Classfile API [v15]
In-Reply-To: <hUvPqC4427nX8mcEcC5Tr90RFXAtmNigTxexY_Ujf04=.55b5e41d-afa7-4220-b13f-6fb0dd25dd0e@github.com>
References: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
 <hr8eti6ytvV05JFRr5hYLWy7yBla9mpI8vKKfaaFR-k=.a92f7bea-6400-4f95-a40c-d57192013f19@github.com>
 <hUvPqC4427nX8mcEcC5Tr90RFXAtmNigTxexY_Ujf04=.55b5e41d-afa7-4220-b13f-6fb0dd25dd0e@github.com>
Message-ID: <JFTVXJrIyV4JzpvC7Qxa6Qo19lPc3DppvCFNY4J8L_E=.02fd2bcd-a751-4ca3-ad36-0a43f1e5a0c4@github.com>

On Thu, 9 Feb 2023 14:05:10 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   AttributeElement.Kind removal (#48)
>
> src/java.base/share/classes/jdk/internal/classfile/constantpool/MemberRefEntry.java line 67:
> 
>> 65:      * {@return whether this member is an interface method}
>> 66:      */
>> 67:     boolean isInterface();
> 
> I'd prefer to see this to `MethodRefEntry`. But again, there's an entry for interface methods, so not sure how much this is needed.

The same as above, it is possible to remove it and the two use cases (in `ConcreteMethodHandleEntry::asSymbol` and `ClassPrinterImpl`) replace with `instanceof InterfaceMethodRefEntry`.
Thanks!

-------------

PR: https://git.openjdk.org/jdk/pull/10982

From asotona at openjdk.org  Wed Feb 15 15:31:24 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Wed, 15 Feb 2023 15:31:24 GMT
Subject: RFR: 8294982: Implementation of Classfile API [v19]
In-Reply-To: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
References: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
Message-ID: <4tbi7L_lSPBugs7uv61dd44v7FWSARbLmu6CTocvytY=.51b7da25-81d1-4944-b297-29ef9ab36795@github.com>

> This is root pull request with Classfile API implementation, tests and benchmarks initial drop into JDK.
> 
> Following pull requests consolidating JDK class files parsing, generating, and transforming ([JDK-8294957](https://bugs.openjdk.org/browse/JDK-8294957)) will chain to this one.
> 
> Classfile API development is tracked at:
> https://github.com/openjdk/jdk-sandbox/tree/classfile-api-branch
> 
> Development branch of consolidated JDK class files parsing, generating, and transforming is at:
> https://github.com/openjdk/jdk-sandbox/tree/classfile-api-dev-branch
> 
> Classfile API [JEP](https://bugs.openjdk.org/browse/JDK-8280389) and [online API documentation](https://htmlpreview.github.io/?https://raw.githubusercontent.com/openjdk/jdk-sandbox/classfile-api-javadoc-branch/doc/classfile-api/javadoc/java.base/jdk/internal/classfile/package-summary.html) is also available.
> 
> Please take you time to review this non-trivial JDK addition.
> 
> Thank you,
> Adam

Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:

  removal of MemberRefEntry::isMethod and ::isInterface

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10982/files
  - new: https://git.openjdk.org/jdk/pull/10982/files/bb295b53..dbb9e46a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10982&range=18
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10982&range=17-18

  Stats: 45 lines in 3 files changed: 0 ins; 42 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/10982.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10982/head:pull/10982

PR: https://git.openjdk.org/jdk/pull/10982

From raffaello.giulietti at oracle.com  Wed Feb 15 15:47:00 2023
From: raffaello.giulietti at oracle.com (Raffaello Giulietti)
Date: Wed, 15 Feb 2023 15:47:00 +0000
Subject: 8302590: Add String.indexOf(int ch, int fromIndex, int toIndex)
Message-ID: <BY5PR10MB4002F07F93E62312C95A419487A39@BY5PR10MB4002.namprd10.prod.outlook.com>

Hello,

Currently `String` does not expose a method `indexOf(int ch, int fromIndex, int toIndex)`, where the 3rd parameter limits the search to positions up to it (exclusive). JBS issue [1] has been filed as an ?Enhancement? to add it to the codebase.

Before preparing a PR and a CSR, I would like to gather opinions and suggestions.

Greetings
Raffaello

----

[1] https://bugs.openjdk.org/browse/JDK-8302590

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20230215/438c42c5/attachment-0001.htm>

From roger.riggs at oracle.com  Wed Feb 15 17:03:29 2023
From: roger.riggs at oracle.com (Roger Riggs)
Date: Wed, 15 Feb 2023 12:03:29 -0500
Subject: 8302590: Add String.indexOf(int ch, int fromIndex, int toIndex)
In-Reply-To: <BY5PR10MB4002F07F93E62312C95A419487A39@BY5PR10MB4002.namprd10.prod.outlook.com>
References: <BY5PR10MB4002F07F93E62312C95A419487A39@BY5PR10MB4002.namprd10.prod.outlook.com>
Message-ID: <e3b2723b-5b64-19d5-35be-3468da8fc692@oracle.com>

Hi Raffaello,

What's the use case, can you give an example?

Seems reasonable; would you also add `lastIndexOf(int ch, int fromIndex, 
int toIndex)`?
Not intrinsified, but for symmetry.

Regards, Roger

On 2/15/23 10:47 AM, Raffaello Giulietti wrote:
>
> Hello,
>
> Currently `String` does not expose a method `indexOf(int ch, int 
> fromIndex, int toIndex)`, where the 3^rd parameter limits the search 
> to positions up to it (exclusive). JBS issue [1] has been filed as an 
> ?Enhancement? to add it to the codebase.
>
> Before preparing a PR and a CSR, I would like to gather opinions and 
> suggestions.
>
> Greetings
>
> Raffaello
>
> ----
>
> [1] https://bugs.openjdk.org/browse/JDK-8302590
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20230215/3bad7334/attachment.htm>

From duke at openjdk.org  Wed Feb 15 17:08:55 2023
From: duke at openjdk.org (David M. Lloyd)
Date: Wed, 15 Feb 2023 17:08:55 GMT
Subject: RFR: 8292914: Introduce a system property that enables stable
 names for lambda proxy classes [v7]
In-Reply-To: <suniyTACMBrKty-xNRWXFtaXRS5TguagZGHWqYbHzlk=.d965d64e-6daa-4844-a2af-0959045ad9e5@github.com>
References: <pYF675FND8BK8SUHFnvstPMcoKTcW81zs7yGCli5Mxo=.aac8b180-6101-4320-aa73-7e640952afaf@github.com>
 <suniyTACMBrKty-xNRWXFtaXRS5TguagZGHWqYbHzlk=.d965d64e-6daa-4844-a2af-0959045ad9e5@github.com>
Message-ID: <njn_XSSeJJCyyd--IPvAB60BPz5SMozjYuKthO8LCFM=.ad437cfd-69d3-40f8-9a83-41689cb2aca7@github.com>

On Mon, 21 Nov 2022 16:46:43 GMT, Strahinja Stanojevic <duke at openjdk.org> wrote:

>> This PR introduces an option to output stable names for the lambda classes in the JDK. A stable name consists of two parts: The first part is the predefined value `$$Lambda$` appended to the lambda capturing class, and the second is a 64-bit hash part of the name. Thus, it looks like `lambdaCapturingClass$$Lambda$hashValue`.
>> Parameters used to create a stable hash are a superset of the parameters used for lambda class archiving when the CDS dumping option is enabled. During this process, all the mutual parameters are in the same form as they are in the low-level implementation (`SystemDictionaryShared::add_lambda_proxy_class`) of the archiving process.
>> We decided to use a well-specified `CRC32` algorithm from the standard Java library. We created two 32-bit hashes from the parameters used to create stable names. Then, we combined those two 32-bit hashes into one 64-bit hash value.
>> We chose `CRC32` because it is a well-specified hash function, and we don't need to write additional code in the JDK. `SHA-256, MD5`, and all other hash functions that rely on `MessageDigest` use lambdas in the implementation, so they are unsuitable for our purpose. We also considered a few different hash functions with a low collision rate. All these functions would require at least 100 lines of additional code in the JDK. The best alternative we found is 64-bit` MurmurHash2`: https://commons.apache.org/proper/commons-codec/jacoco/org.apache.commons.codec.digest/MurmurHash2.java.html.  In case adding a new hash implementation (e.g., Murmur2) to the JDK is preferred, this PR can be easily modified.
>> We found the post (https://softwareengineering.stackexchange.com/questions/49550/which-hashing-algorithm-is-best-for-uniqueness-and-speed/145633#145633) that compares different hash functions.
>> We also tested the `CRC32` hash function against half a billion generated strings, and there were no collisions. Note that the capturing-class name is also part of the lambda class name, so the potential collisions can only appear in a single class. Thus, we do not expect to have name collisions due to a relatively low number of lambdas per class. Every tool that uses this feature should handle potential collisions on its own.  
>> We found an overall approximation of the collision rate too. You can find it here: https://preshing.com/20110504/hash-collision-probabilities/.
>> 
>> JDK currently adds an atomic integer after `$$Lambda$`, and the names of the lambdas depend on the creation order. In the `TestStableLambdaNames`, we generate all the lambdas two times. In the first run, the method createPlainLambdas generate the following lambdas:
>> 
>> - TestStableLambdaNames$$Lambda$1/0x0000000800c00400
>> - TestStableLambdaNames$$Lambda$2/0x0000000800c01800
>> - TestStableLambdaNames$$Lambda$3/0x0000000800c01a38
>> The same method in the second run generates lambdas with different names:
>> - TestStableLambdaNames$$Lambda$1471/0x0000000800d10000
>> - TestStableLambdaNames$$Lambda$1472/0x0000000800d10238
>> - TestStableLambdaNames$$Lambda$1473/0x0000000800d10470
>> 
>> If we use the introduced flag, generated lambdas are:
>> - TestStableLambdaNames$$Lambda$65ba26bbc6c7500d/0x0000000800c00400
>> - TestStableLambdaNames$$Lambda$1569c8c4abe3ab18/0x0000000800c01800
>> - TestStableLambdaNames$$Lambda$493c0ecaaf682428/0x0000000800c01a38
>> In the second run of the method, generated lambdas are:
>> - TestStableLambdaNames$$Lambda$65ba26bbc6c7500d/0x0000000800d10000
>> - TestStableLambdaNames$$Lambda$1569c8c4abe3ab18/0x0000000800d10238
>> - TestStableLambdaNames$$Lambda$493c0ecaaf682428/0x0000000800d10470
>> 
>> We can see that the introduced hash value does not change between two calls of the method `createPlainLambdas`. That was not the case in the JDK run without this change. Those lambdas are extracted directly from the test.
>
> Strahinja Stanojevic has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove address from lambda class names in test on the 32-bit architecture too

Looking at the code for `InnerClassLambdaMetafactory`, I don't think that the numerical suffix is necessary _at all_. These lambda classes are defined as _hidden_ classes, in which case the class is already created with a unique "name" (in the form of a suffix comprising `/` and some unique identifying digits).

>From my own experiments, I simply removed the counter altogether and everything continues to work with the classes simply being named `xxx/xxx/Xxx$$Lambda`. So perhaps the entire mechanism (which consists of ` + counter.incrementAndGet()` within `InnerClassLambdaMetafactory#lambdaClassName`) is unneeded?

I'll also add this comment on to the original issue as well.

-------------

PR: https://git.openjdk.org/jdk/pull/10024

From duke at openjdk.org  Wed Feb 15 17:39:18 2023
From: duke at openjdk.org (David M. Lloyd)
Date: Wed, 15 Feb 2023 17:39:18 GMT
Subject: RFR: 8292914: Drop the counter from lambda class names
Message-ID: <GgLfH-ueBQqT-Mfk1mKpKFAt8fYqyjfVJ9lmlsBsCbo=.8dd5b3b4-4e84-4970-9179-1c0399b30edc@github.com>

The class generated for lambda proxies is now defined as a hidden class. This means that the counter, which was used to ensure a unique class name and avoid clashes, is now redundant. In addition to performing redundant work, this also impacts build reproducibility for native image generators which might already have a strategy to cope with hidden classes but cannot cope with indeterminate definition order for lambda proxy classes.

This solves JDK-8292914 by making lambda proxy names always be stable without any configuration needed. This would also replace #10024.

-------------

Commit messages:
 - 8292914: Drop the counter from lambda class names

Changes: https://git.openjdk.org/jdk/pull/12579/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12579&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8292914
  Stats: 4 lines in 1 file changed: 0 ins; 3 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/12579.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12579/head:pull/12579

PR: https://git.openjdk.org/jdk/pull/12579

From raffaello.giulietti at oracle.com  Wed Feb 15 17:58:38 2023
From: raffaello.giulietti at oracle.com (Raffaello Giulietti)
Date: Wed, 15 Feb 2023 17:58:38 +0000
Subject: 8302590: Add String.indexOf(int ch, int fromIndex, int toIndex)
In-Reply-To: <e3b2723b-5b64-19d5-35be-3468da8fc692@oracle.com>
References: <BY5PR10MB4002F07F93E62312C95A419487A39@BY5PR10MB4002.namprd10.prod.outlook.com>
 <e3b2723b-5b64-19d5-35be-3468da8fc692@oracle.com>
Message-ID: <BY5PR10MB4002342C319BD68DADD4821787A39@BY5PR10MB4002.namprd10.prod.outlook.com>

Thanks Roger.

Let's say you have a `String` that is structured in lines, and for each line you need to count the occurrences (0 or more) of some character.
A way to process a line is to first search for the next '\n' from the current position, then to seach for that character starting from the same position but limiting the search up to the position of the '\n', update the current position after the character, iterate.
You then advance to the next line and repeat the above.

There are other ways to achieve the same result, but they are probably either more complicated or less efficient.

I?m proposing this addition because very similar, non-public methods already exist in the codebase, and which are already used to implement `indexOf()`.



As for `lastIndexOf()`, in the forward search it's natural to have `toIndex` excluded from the search. There are many instance of right-open ranges [`fromIndex`, `toIndex`) in the codebase, so the proposal is to adopt this convention for `indexOf(ch, fromIndex, toIndex)`.

For a backward search, however, this is less natural. The non-obvious part is to assign natural semantics to `toIndex` for `lastIndexOf(ch, fromIndex, toIndex)`. Currently, `lastIndexOf(ch, fromIndex)` operates in the closed range of indices [`0`, `fromIndex`].
Should the range be closed [`toIndex`, `fromIndex`] or the left-open (`toIndex`, `fromIndex`]? Should `lastIndexOf(ch, fromIndex)` be seen as an abbreviation for `lastIndexOf(ch, fromIndex, 0)` or for `lastIndexOf(ch, fromIndex, -1)`?

Once there's consensus about this aspect, I can of course add `lastIndexOf(ch, fromIndex, toIndex)` as well.



From: core-libs-dev <core-libs-dev-retn at openjdk.org> on behalf of Roger Riggs <roger.riggs at oracle.com>
Date: Wednesday, 15 February 2023 at 18:03
To: core-libs-dev at openjdk.org <core-libs-dev at openjdk.org>
Subject: Re: 8302590: Add String.indexOf(int ch, int fromIndex, int toIndex)
Hi Raffaello,

What's the use case, can you give an example?

Seems reasonable; would you also add `lastIndexOf(int ch, int fromIndex, int toIndex)`?
Not intrinsified, but for symmetry.

Regards, Roger
On 2/15/23 10:47 AM, Raffaello Giulietti wrote:
Hello,

Currently `String` does not expose a method `indexOf(int ch, int fromIndex, int toIndex)`, where the 3rd parameter limits the search to positions up to it (exclusive). JBS issue [1] has been filed as an ?Enhancement? to add it to the codebase.

Before preparing a PR and a CSR, I would like to gather opinions and suggestions.

Greetings
Raffaello

----

[1] https://bugs.openjdk.org/browse/JDK-8302590


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20230215/2bef8a0b/attachment.htm>

From mchung at openjdk.org  Wed Feb 15 18:20:43 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Wed, 15 Feb 2023 18:20:43 GMT
Subject: RFR: 8292914: Drop the counter from lambda class names
In-Reply-To: <GgLfH-ueBQqT-Mfk1mKpKFAt8fYqyjfVJ9lmlsBsCbo=.8dd5b3b4-4e84-4970-9179-1c0399b30edc@github.com>
References: <GgLfH-ueBQqT-Mfk1mKpKFAt8fYqyjfVJ9lmlsBsCbo=.8dd5b3b4-4e84-4970-9179-1c0399b30edc@github.com>
Message-ID: <qDPGf4iv3s8FEKVUqXJTIEnRPeclk00aR8ZARJ9KjWM=.d44271ca-998f-4edb-9e3d-8111a0e3d701@github.com>

On Wed, 15 Feb 2023 17:32:38 GMT, David M. Lloyd <duke at openjdk.org> wrote:

> The class generated for lambda proxies is now defined as a hidden class. This means that the counter, which was used to ensure a unique class name and avoid clashes, is now redundant. In addition to performing redundant work, this also impacts build reproducibility for native image generators which might already have a strategy to cope with hidden classes but cannot cope with indeterminate definition order for lambda proxy classes.
> 
> This solves JDK-8292914 by making lambda proxy names always be stable without any configuration needed. This would also replace #10024.

While the counter is not strictly needed, it's very important for diagnosability.

-------------

PR: https://git.openjdk.org/jdk/pull/12579

From mchung at openjdk.org  Wed Feb 15 18:25:43 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Wed, 15 Feb 2023 18:25:43 GMT
Subject: RFR: 8293667: Align jlink's --compress option with jmod's
 --compress option [v6]
In-Reply-To: <NrBsTNLHMOGqYjlbVibWs7STrGzOn4KDyxdqm9U0EYA=.9b458286-46e8-4351-849a-32430a727edf@github.com>
References: <JWevwHuR2vF3k-JRxmTAxfNN6g-EBkgG2N9DHn4fkGY=.f9768dfd-cab4-49a9-83b9-d77a1572e917@github.com>
 <p5a-3JyPNAPcY5YrBuDGkX9bKNuiwp56QHf2oIInGnc=.ef123257-baf4-4b2c-835c-745bd9899ba7@github.com>
 <vyutVhxGNbq9_B4NvgmAGqBKXNyG46AUlMGb68BG47k=.61d35f0b-a89c-412e-88e9-57d592db384f@github.com>
 <NrBsTNLHMOGqYjlbVibWs7STrGzOn4KDyxdqm9U0EYA=.9b458286-46e8-4351-849a-32430a727edf@github.com>
Message-ID: <LRCKtKBXaKY-dH_80bXaYFC1K2ykzc4JmmaTA3G04pE=.3e386f9f-d82d-497b-a2be-55ae574506d9@github.com>

On Wed, 15 Feb 2023 14:56:27 GMT, Ian Graves <igraves at openjdk.org> wrote:

>> src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/CompactConstantPoolsPlugin.java line 48:
>> 
>>> 46: 
>>> 47:     public CompactConstantPoolsPlugin() {
>>> 48:         super("compact-constant-pools");
>> 
>> This plugin needs a better option name.   Maybe `--share-utf8-entries`?
>> 
>> I also wonder if anyone really uses this plugin.  It writes the shared UTF8 strings into the jimage.  It incurs overhead in reconstructing the constant pool when loading classes.    So I wonder if we just drop this plugin - @AlanBateman, @igraves what do you think?
>
> I think that deprecating the entire plugin could be appropriate, given the overhead, unless there's some performance data to the contrary. I haven't seen much in favor of keeping it, but I do think that breaking it apart from zip before deprecating it is also fine.

If we are planning to drop this, we will not need to introduce a new plugin option but instead states that `--compress 1` will be deprecated and removed in a future release.

-------------

PR: https://git.openjdk.org/jdk/pull/11617

From duke at openjdk.org  Wed Feb 15 18:29:41 2023
From: duke at openjdk.org (David M. Lloyd)
Date: Wed, 15 Feb 2023 18:29:41 GMT
Subject: RFR: 8292914: Drop the counter from lambda class names
In-Reply-To: <GgLfH-ueBQqT-Mfk1mKpKFAt8fYqyjfVJ9lmlsBsCbo=.8dd5b3b4-4e84-4970-9179-1c0399b30edc@github.com>
References: <GgLfH-ueBQqT-Mfk1mKpKFAt8fYqyjfVJ9lmlsBsCbo=.8dd5b3b4-4e84-4970-9179-1c0399b30edc@github.com>
Message-ID: <E-SYT44wcKyKtvkW7GorT99tPAq5szrQovu8Q4eDF9M=.72d5e608-b6db-4387-be49-371edfb45ae0@github.com>

On Wed, 15 Feb 2023 17:32:38 GMT, David M. Lloyd <duke at openjdk.org> wrote:

> The class generated for lambda proxies is now defined as a hidden class. This means that the counter, which was used to ensure a unique class name and avoid clashes, is now redundant. In addition to performing redundant work, this also impacts build reproducibility for native image generators which might already have a strategy to cope with hidden classes but cannot cope with indeterminate definition order for lambda proxy classes.
> 
> This solves JDK-8292914 by making lambda proxy names always be stable without any configuration needed. This would also replace #10024.

Do you have an example? Could the hidden class identifier be used for this purpose instead?

-------------

PR: https://git.openjdk.org/jdk/pull/12579

From mchung at openjdk.org  Wed Feb 15 18:33:01 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Wed, 15 Feb 2023 18:33:01 GMT
Subject: Integrated: JDK-8301460: Clean up LambdaForm to reference BasicType
 enums directly
In-Reply-To: <yoiVWrNeX6OjlT-iQjAo6SoQWCZi-gcPlWUjK8YZoqc=.61908404-3f28-45cb-a351-aa315924b6c3@github.com>
References: <yoiVWrNeX6OjlT-iQjAo6SoQWCZi-gcPlWUjK8YZoqc=.61908404-3f28-45cb-a351-aa315924b6c3@github.com>
Message-ID: <E8wEE6qWAv_brbrpTgy5_4lv44ivhHSfRjKgdbvlQD8=.4e58dfb7-7106-4e65-a4c4-e4264c3947fa@github.com>

On Mon, 13 Feb 2023 22:05:15 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> `LambdaForm` declares int constants for `BasicType::ordinal` to workaround JDK-8161245.   Now these int constants are no longer needed.    This removes these int constants and reference `BasicType` enums directly.

This pull request has now been integrated.

Changeset: 50dcc2ae
Author:    Mandy Chung <mchung at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/50dcc2aec5b16c0826e27d58e49a7f55a5f5ad38
Stats:     25 lines in 4 files changed: 1 ins; 10 del; 14 mod

8301460: Clean up LambdaForm to reference BasicType enums directly

Reviewed-by: jvernee

-------------

PR: https://git.openjdk.org/jdk/pull/12546

From mchung at openjdk.org  Wed Feb 15 18:34:41 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Wed, 15 Feb 2023 18:34:41 GMT
Subject: RFR: 8292914: Drop the counter from lambda class names
In-Reply-To: <GgLfH-ueBQqT-Mfk1mKpKFAt8fYqyjfVJ9lmlsBsCbo=.8dd5b3b4-4e84-4970-9179-1c0399b30edc@github.com>
References: <GgLfH-ueBQqT-Mfk1mKpKFAt8fYqyjfVJ9lmlsBsCbo=.8dd5b3b4-4e84-4970-9179-1c0399b30edc@github.com>
Message-ID: <GYE-KZUqt6hWkUC-KHrt4X0cCFSuzKDVyQmFAxo9FPc=.26dbc76f-4458-489f-abae-c29c06ce166f@github.com>

On Wed, 15 Feb 2023 17:32:38 GMT, David M. Lloyd <duke at openjdk.org> wrote:

> The class generated for lambda proxies is now defined as a hidden class. This means that the counter, which was used to ensure a unique class name and avoid clashes, is now redundant. In addition to performing redundant work, this also impacts build reproducibility for native image generators which might already have a strategy to cope with hidden classes but cannot cope with indeterminate definition order for lambda proxy classes.
> 
> This solves JDK-8292914 by making lambda proxy names always be stable without any configuration needed. This would also replace #10024.

we want the generated classes to be dumped for debugging before the hidden class is defined e.g. to troubleshoot class loading issue (see  `-Djdk.internal.lambda.dumpProxyClasses=<path>` system property)

-------------

PR: https://git.openjdk.org/jdk/pull/12579

From igraves at openjdk.org  Wed Feb 15 18:52:47 2023
From: igraves at openjdk.org (Ian Graves)
Date: Wed, 15 Feb 2023 18:52:47 GMT
Subject: RFR: 8293667: Align jlink's --compress option with jmod's
 --compress option [v6]
In-Reply-To: <LRCKtKBXaKY-dH_80bXaYFC1K2ykzc4JmmaTA3G04pE=.3e386f9f-d82d-497b-a2be-55ae574506d9@github.com>
References: <JWevwHuR2vF3k-JRxmTAxfNN6g-EBkgG2N9DHn4fkGY=.f9768dfd-cab4-49a9-83b9-d77a1572e917@github.com>
 <p5a-3JyPNAPcY5YrBuDGkX9bKNuiwp56QHf2oIInGnc=.ef123257-baf4-4b2c-835c-745bd9899ba7@github.com>
 <vyutVhxGNbq9_B4NvgmAGqBKXNyG46AUlMGb68BG47k=.61d35f0b-a89c-412e-88e9-57d592db384f@github.com>
 <NrBsTNLHMOGqYjlbVibWs7STrGzOn4KDyxdqm9U0EYA=.9b458286-46e8-4351-849a-32430a727edf@github.com>
 <LRCKtKBXaKY-dH_80bXaYFC1K2ykzc4JmmaTA3G04pE=.3e386f9f-d82d-497b-a2be-55ae574506d9@github.com>
Message-ID: <6Oxe83ZMKel9zV-aZpgQrE2WMDcx_oI4lZX7JIxgYDU=.7735bdca-7761-4d6f-b843-3b8c0e082ba8@github.com>

On Wed, 15 Feb 2023 18:23:02 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> I think that deprecating the entire plugin could be appropriate, given the overhead, unless there's some performance data to the contrary. I haven't seen much in favor of keeping it, but I do think that breaking it apart from zip before deprecating it is also fine.
>
> If we are planning to drop this, we will not need to introduce a new plugin option but instead states that `--compress 1` will be deprecated and removed in a future release.

That makes sense to me. May want @AlanBateman's opinion before final action.

-------------

PR: https://git.openjdk.org/jdk/pull/11617

From briangoetz at openjdk.org  Wed Feb 15 19:12:53 2023
From: briangoetz at openjdk.org (Brian Goetz)
Date: Wed, 15 Feb 2023 19:12:53 GMT
Subject: RFR: 8292914: Drop the counter from lambda class names
In-Reply-To: <GgLfH-ueBQqT-Mfk1mKpKFAt8fYqyjfVJ9lmlsBsCbo=.8dd5b3b4-4e84-4970-9179-1c0399b30edc@github.com>
References: <GgLfH-ueBQqT-Mfk1mKpKFAt8fYqyjfVJ9lmlsBsCbo=.8dd5b3b4-4e84-4970-9179-1c0399b30edc@github.com>
Message-ID: <teYv_fNHNmPPO1QiuxEHqshxsiJtdBzMhdnAXDzY_Ek=.bc94da5c-5d93-4f3f-a8ed-2341bcc76e35@github.com>

On Wed, 15 Feb 2023 17:32:38 GMT, David M. Lloyd <duke at openjdk.org> wrote:

> The class generated for lambda proxies is now defined as a hidden class. This means that the counter, which was used to ensure a unique class name and avoid clashes, is now redundant. In addition to performing redundant work, this also impacts build reproducibility for native image generators which might already have a strategy to cope with hidden classes but cannot cope with indeterminate definition order for lambda proxy classes.
> 
> This solves JDK-8292914 by making lambda proxy names always be stable without any configuration needed. This would also replace #10024.

While I agree with your assessment that this is a much less intrusive solution to JDK-8292914 than the proposed system property, I also take Mandy's concern seriously here.  

I suspect that as Leyden progresses, there will be multiple issues we may want to consider in various bootstrap implementations to make them more amenable to time-shifting.  I propose that we leave this PR on the table to be considered when we take up the issue more holistically, rather than doing it in bits and pieces?

-------------

PR: https://git.openjdk.org/jdk/pull/12579

From duke at openjdk.org  Wed Feb 15 20:28:54 2023
From: duke at openjdk.org (David M. Lloyd)
Date: Wed, 15 Feb 2023 20:28:54 GMT
Subject: RFR: 8292914: Drop the counter from lambda class names
In-Reply-To: <GgLfH-ueBQqT-Mfk1mKpKFAt8fYqyjfVJ9lmlsBsCbo=.8dd5b3b4-4e84-4970-9179-1c0399b30edc@github.com>
References: <GgLfH-ueBQqT-Mfk1mKpKFAt8fYqyjfVJ9lmlsBsCbo=.8dd5b3b4-4e84-4970-9179-1c0399b30edc@github.com>
Message-ID: <UCz4eO5vgfIQxsU37p3oCxdP3-Y8E1f93kxh_MITNUA=.6db8328e-42a8-43b1-a4e0-53a77b4ef012@github.com>

On Wed, 15 Feb 2023 17:32:38 GMT, David M. Lloyd <duke at openjdk.org> wrote:

> The class generated for lambda proxies is now defined as a hidden class. This means that the counter, which was used to ensure a unique class name and avoid clashes, is now redundant. In addition to performing redundant work, this also impacts build reproducibility for native image generators which might already have a strategy to cope with hidden classes but cannot cope with indeterminate definition order for lambda proxy classes.
> 
> This solves JDK-8292914 by making lambda proxy names always be stable without any configuration needed. This would also replace #10024.

Sure, that's fine. I think debugging is a totally valid consideration; in fact it might be nice to have a broader facility for dumping of any hidden class (maybe that's what you are alluding to). But if you think it's best to wait then I won't pursue it further at this time.

-------------

PR: https://git.openjdk.org/jdk/pull/12579

From rrich at openjdk.org  Wed Feb 15 20:30:00 2023
From: rrich at openjdk.org (Richard Reingruber)
Date: Wed, 15 Feb 2023 20:30:00 GMT
Subject: RFR: 8302158: PPC:
 test/jdk/jdk/internal/vm/Continuation/Fuzz.java: AssertionError: res: false
 shouldPin: false [v2]
In-Reply-To: <G-cEPYqp6JlMkj9qo0S9HuNXRiuROZ7q69FQYIsDewM=.d20f3ee3-ed25-4bd3-93cd-2a55faa515d3@github.com>
References: <G-cEPYqp6JlMkj9qo0S9HuNXRiuROZ7q69FQYIsDewM=.d20f3ee3-ed25-4bd3-93cd-2a55faa515d3@github.com>
Message-ID: <MmOeDc2ETuOsVcS-R-noo92M35DdOLpbOapofWah5Mg=.051144c9-71c6-48bc-8017-477894177ce0@github.com>

> This fixes the linked issue by trimming the caller of a frame to be deoptimized back to its `unextended_sp` iff it is compiled. The creation of the section `dead after deoptimization` shown in the attachment [yield_after_deopt_failure.log](https://bugs.openjdk.org/secure/attachment/102602/yield_after_deopt_failure.log) is prevented by this.
> 
> A new mode is added to the test BasicExt.java where all frames are deoptimized after a yield operation. The issue can be deterministically reproduced with the new mode. It's not worth to execute all test cases with the new mode though. Instead `ContinuationCompiledFramesWithStackArgs_3c4` is always executed a 2nd time in this mode.
> 
> Before this BasicExt.java was refactored for better argument processing and representation of the test modes.
> Also the try-catch-clause in the main method had to be changed to rethrow the caught exception because without this the test would have succeeded.
> 
> Testing: jtreg tests tier 1-4 on standard platforms and also on ppc64le.

Richard Reingruber has updated the pull request incrementally with three additional commits since the last revision:

 - Improve comment
 - Improve comment
 - Spelling

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12557/files
  - new: https://git.openjdk.org/jdk/pull/12557/files/7ca17977..9d647388

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12557&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12557&range=00-01

  Stats: 5 lines in 2 files changed: 4 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/12557.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12557/head:pull/12557

PR: https://git.openjdk.org/jdk/pull/12557

From rrich at openjdk.org  Wed Feb 15 20:30:22 2023
From: rrich at openjdk.org (Richard Reingruber)
Date: Wed, 15 Feb 2023 20:30:22 GMT
Subject: RFR: 8302158: PPC:
 test/jdk/jdk/internal/vm/Continuation/Fuzz.java: AssertionError: res: false
 shouldPin: false [v2]
In-Reply-To: <yILfzeqXkCcXs_zNtroZgfvvDry95Weea8kh2nrmg3U=.a7b275c6-1f1f-40a6-8d22-30f5f45d85cf@github.com>
References: <G-cEPYqp6JlMkj9qo0S9HuNXRiuROZ7q69FQYIsDewM=.d20f3ee3-ed25-4bd3-93cd-2a55faa515d3@github.com>
 <yILfzeqXkCcXs_zNtroZgfvvDry95Weea8kh2nrmg3U=.a7b275c6-1f1f-40a6-8d22-30f5f45d85cf@github.com>
Message-ID: <xuLzxH3yJAvVoaHov6RTdrB-ZwRBrA6GpsyKNDPDMgg=.73ce6e97-30e0-465a-9222-f1dd78293102@github.com>

On Wed, 15 Feb 2023 12:35:52 GMT, Goetz Lindenmaier <goetz at openjdk.org> wrote:

>> Richard Reingruber has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - Improve comment
>>  - Improve comment
>>  - Spelling
>
> src/hotspot/cpu/ppc/sharedRuntime_ppc.cpp line 3094:
> 
>> 3092: 
>> 3093:   // Freezing continuation frames requires that the caller is trimmed to unextended sp if compiled.
>> 3094:   Register caller_sp = R23_tmp3;
> 
> Can the caller be interpreted? I.e., not compiled?
> Then it might be helpful to comment like
> // If not compiled this contains sp() resulting in a resize of 0.

Yes it can be interpreted. I've extended the comment for this case.

-------------

PR: https://git.openjdk.org/jdk/pull/12557

From briangoetz at openjdk.org  Wed Feb 15 20:34:23 2023
From: briangoetz at openjdk.org (Brian Goetz)
Date: Wed, 15 Feb 2023 20:34:23 GMT
Subject: RFR: 8292914: Introduce a system property that enables stable
 names for lambda proxy classes [v7]
In-Reply-To: <suniyTACMBrKty-xNRWXFtaXRS5TguagZGHWqYbHzlk=.d965d64e-6daa-4844-a2af-0959045ad9e5@github.com>
References: <pYF675FND8BK8SUHFnvstPMcoKTcW81zs7yGCli5Mxo=.aac8b180-6101-4320-aa73-7e640952afaf@github.com>
 <suniyTACMBrKty-xNRWXFtaXRS5TguagZGHWqYbHzlk=.d965d64e-6daa-4844-a2af-0959045ad9e5@github.com>
Message-ID: <rK_umEglSEjyEjAgxHfww3PSisFb7t92T3qhbs1DGv0=.9fa7902d-cb66-4ac9-a55b-a24b3de27b49@github.com>

On Mon, 21 Nov 2022 16:46:43 GMT, Strahinja Stanojevic <duke at openjdk.org> wrote:

>> This PR introduces an option to output stable names for the lambda classes in the JDK. A stable name consists of two parts: The first part is the predefined value `$$Lambda$` appended to the lambda capturing class, and the second is a 64-bit hash part of the name. Thus, it looks like `lambdaCapturingClass$$Lambda$hashValue`.
>> Parameters used to create a stable hash are a superset of the parameters used for lambda class archiving when the CDS dumping option is enabled. During this process, all the mutual parameters are in the same form as they are in the low-level implementation (`SystemDictionaryShared::add_lambda_proxy_class`) of the archiving process.
>> We decided to use a well-specified `CRC32` algorithm from the standard Java library. We created two 32-bit hashes from the parameters used to create stable names. Then, we combined those two 32-bit hashes into one 64-bit hash value.
>> We chose `CRC32` because it is a well-specified hash function, and we don't need to write additional code in the JDK. `SHA-256, MD5`, and all other hash functions that rely on `MessageDigest` use lambdas in the implementation, so they are unsuitable for our purpose. We also considered a few different hash functions with a low collision rate. All these functions would require at least 100 lines of additional code in the JDK. The best alternative we found is 64-bit` MurmurHash2`: https://commons.apache.org/proper/commons-codec/jacoco/org.apache.commons.codec.digest/MurmurHash2.java.html.  In case adding a new hash implementation (e.g., Murmur2) to the JDK is preferred, this PR can be easily modified.
>> We found the post (https://softwareengineering.stackexchange.com/questions/49550/which-hashing-algorithm-is-best-for-uniqueness-and-speed/145633#145633) that compares different hash functions.
>> We also tested the `CRC32` hash function against half a billion generated strings, and there were no collisions. Note that the capturing-class name is also part of the lambda class name, so the potential collisions can only appear in a single class. Thus, we do not expect to have name collisions due to a relatively low number of lambdas per class. Every tool that uses this feature should handle potential collisions on its own.  
>> We found an overall approximation of the collision rate too. You can find it here: https://preshing.com/20110504/hash-collision-probabilities/.
>> 
>> JDK currently adds an atomic integer after `$$Lambda$`, and the names of the lambdas depend on the creation order. In the `TestStableLambdaNames`, we generate all the lambdas two times. In the first run, the method createPlainLambdas generate the following lambdas:
>> 
>> - TestStableLambdaNames$$Lambda$1/0x0000000800c00400
>> - TestStableLambdaNames$$Lambda$2/0x0000000800c01800
>> - TestStableLambdaNames$$Lambda$3/0x0000000800c01a38
>> The same method in the second run generates lambdas with different names:
>> - TestStableLambdaNames$$Lambda$1471/0x0000000800d10000
>> - TestStableLambdaNames$$Lambda$1472/0x0000000800d10238
>> - TestStableLambdaNames$$Lambda$1473/0x0000000800d10470
>> 
>> If we use the introduced flag, generated lambdas are:
>> - TestStableLambdaNames$$Lambda$65ba26bbc6c7500d/0x0000000800c00400
>> - TestStableLambdaNames$$Lambda$1569c8c4abe3ab18/0x0000000800c01800
>> - TestStableLambdaNames$$Lambda$493c0ecaaf682428/0x0000000800c01a38
>> In the second run of the method, generated lambdas are:
>> - TestStableLambdaNames$$Lambda$65ba26bbc6c7500d/0x0000000800d10000
>> - TestStableLambdaNames$$Lambda$1569c8c4abe3ab18/0x0000000800d10238
>> - TestStableLambdaNames$$Lambda$493c0ecaaf682428/0x0000000800d10470
>> 
>> We can see that the introduced hash value does not change between two calls of the method `createPlainLambdas`. That was not the case in the JDK run without this change. Those lambdas are extracted directly from the test.
>
> Strahinja Stanojevic has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove address from lambda class names in test on the 32-bit architecture too

David Llloyd's proposed solution is dramatically less intrusive, so it should be preferred over the one here.

-------------

PR: https://git.openjdk.org/jdk/pull/10024

From duke at openjdk.org  Wed Feb 15 20:53:02 2023
From: duke at openjdk.org (David M. Lloyd)
Date: Wed, 15 Feb 2023 20:53:02 GMT
Subject: RFR: 8292914: Drop the counter from lambda class names
In-Reply-To: <GgLfH-ueBQqT-Mfk1mKpKFAt8fYqyjfVJ9lmlsBsCbo=.8dd5b3b4-4e84-4970-9179-1c0399b30edc@github.com>
References: <GgLfH-ueBQqT-Mfk1mKpKFAt8fYqyjfVJ9lmlsBsCbo=.8dd5b3b4-4e84-4970-9179-1c0399b30edc@github.com>
Message-ID: <IS0PgskUgbZIrx6gRiUbZnJ0mjCrea8DsEXeY8k0jzg=.bf481705-b621-4fe2-b16a-f6223c74c8fa@github.com>

On Wed, 15 Feb 2023 17:32:38 GMT, David M. Lloyd <duke at openjdk.org> wrote:

> The class generated for lambda proxies is now defined as a hidden class. This means that the counter, which was used to ensure a unique class name and avoid clashes, is now redundant. In addition to performing redundant work, this also impacts build reproducibility for native image generators which might already have a strategy to cope with hidden classes but cannot cope with indeterminate definition order for lambda proxy classes.
> 
> This solves JDK-8292914 by making lambda proxy names always be stable without any configuration needed. This would also replace #10024.

(On the debugability topic) I had thought to change the lambda class dumping code so that it would dump the class bytes *after* the class was defined (to capture the unique hidden class name completely). But this would exclude the case where the class would fail to be defined, which would probably undermine some significant percentage of the cases where you'd want a dump in the first place. Maybe in this case, since the class name would never appear in any stack trace anyway (and thus there is nothing to actually correlate), it could be dumped with a separate counter like `..Lambda$$-error1.class` or something?

-------------

PR: https://git.openjdk.org/jdk/pull/12579

From briangoetz at openjdk.org  Wed Feb 15 21:02:37 2023
From: briangoetz at openjdk.org (Brian Goetz)
Date: Wed, 15 Feb 2023 21:02:37 GMT
Subject: RFR: 8292914: Drop the counter from lambda class names
In-Reply-To: <IS0PgskUgbZIrx6gRiUbZnJ0mjCrea8DsEXeY8k0jzg=.bf481705-b621-4fe2-b16a-f6223c74c8fa@github.com>
References: <GgLfH-ueBQqT-Mfk1mKpKFAt8fYqyjfVJ9lmlsBsCbo=.8dd5b3b4-4e84-4970-9179-1c0399b30edc@github.com>
 <IS0PgskUgbZIrx6gRiUbZnJ0mjCrea8DsEXeY8k0jzg=.bf481705-b621-4fe2-b16a-f6223c74c8fa@github.com>
Message-ID: <hFXo1xTKYCZb93Ba-KJeWLowVFw5OF6d23PV1zkAZJA=.c967aa8b-94e7-47ae-9ecb-a375a2669913@github.com>

On Wed, 15 Feb 2023 20:46:47 GMT, David M. Lloyd <duke at openjdk.org> wrote:

>> The class generated for lambda proxies is now defined as a hidden class. This means that the counter, which was used to ensure a unique class name and avoid clashes, is now redundant. In addition to performing redundant work, this also impacts build reproducibility for native image generators which might already have a strategy to cope with hidden classes but cannot cope with indeterminate definition order for lambda proxy classes.
>> 
>> This solves JDK-8292914 by making lambda proxy names always be stable without any configuration needed. This would also replace #10024.
>
> (On the debugability topic) I had thought to change the lambda class dumping code so that it would dump the class bytes *after* the class was defined (to capture the unique hidden class name completely). But this would exclude the case where the class would fail to be defined, which would probably undermine some significant percentage of the cases where you'd want a dump in the first place. Maybe in this case, since the class name would never appear in any stack trace anyway (and thus there is nothing to actually correlate), it could be dumped with a separate counter like `..Lambda$$-error1.class` or something?

@dmlloyd Exactly so.  The dumping is most useful in debugging cases where there are weird issues with access control or verification, or bugs in LMF that might cause errors on load.  I remember before we put the counter in, being bitten by "the first dumped $Lambda$blarg class file was overwrittten by the second, and I couldn't find the bug because it was in the first one, but I didn't realize there were two."  So the counter actually did pay its way at least once.  

That said, I do think the filename conflict was the main reason we needed it, and there are other ways to disambiguate file names.  In fact, it might be even better if we constructed the file name as "$timestamp-$classname$", so that (a) they would sort and you could find the most recent ones easily, and (b) dumps from later runs would not clobber dumps from previous runs.  I think that would also solve @mlchung 's concerns?

-------------

PR: https://git.openjdk.org/jdk/pull/12579

From igraves at openjdk.org  Wed Feb 15 21:40:45 2023
From: igraves at openjdk.org (Ian Graves)
Date: Wed, 15 Feb 2023 21:40:45 GMT
Subject: RFR: 8293667: Align jlink's --compress option with jmod's
 --compress option [v7]
In-Reply-To: <JWevwHuR2vF3k-JRxmTAxfNN6g-EBkgG2N9DHn4fkGY=.f9768dfd-cab4-49a9-83b9-d77a1572e917@github.com>
References: <JWevwHuR2vF3k-JRxmTAxfNN6g-EBkgG2N9DHn4fkGY=.f9768dfd-cab4-49a9-83b9-d77a1572e917@github.com>
Message-ID: <P-3rkhcQ1MXW2AstCNk_E6GlVoXTIIcfCvnmDgr-X_k=.f310559e-3f86-48bc-9634-88124305f03a@github.com>

> This is an approach to adding a flag to jlink that will allow --compress to take the same types of arguments as jmod, thus bringing the two into alignment. This likely requires a CSR and a discussion on whether we should deprecate or simply remove the original numeric compression arguments.

Ian Graves has updated the pull request incrementally with three additional commits since the last revision:

 - Removing string compression plugin
 - Fixing errant compact-constant-pools
 - ShareUTF8Entries update

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/11617/files
  - new: https://git.openjdk.org/jdk/pull/11617/files/2af25227..92416003

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11617&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11617&range=05-06

  Stats: 377 lines in 4 files changed: 0 ins; 373 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/11617.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11617/head:pull/11617

PR: https://git.openjdk.org/jdk/pull/11617

From bpb at openjdk.org  Wed Feb 15 21:43:19 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 15 Feb 2023 21:43:19 GMT
Subject: RFR: JDK-8302026: Port fdlibm inverse trig functions (asin, acos, 
 atan) to Java [v2]
In-Reply-To: <nye6hmaxdoxF9Nt1dSPooEOZcFrf7RqTtm-pNj6llQk=.bfb8bdbf-5679-4e53-89d2-42230607ba2f@github.com>
References: <4gBqg3J25LASN6tnRwZ22S3YlUHQrypgvZqynfKd3Os=.3a5e618f-b7eb-4978-a6ab-f1b30c793fb4@github.com>
 <nye6hmaxdoxF9Nt1dSPooEOZcFrf7RqTtm-pNj6llQk=.bfb8bdbf-5679-4e53-89d2-42230607ba2f@github.com>
Message-ID: <Jtz05jTOJB3EfWQALhgcsmIOAqP2HCyQJZRekW2h3mg=.d6f712d3-8270-4c41-93e6-5ac5896ad0aa@github.com>

On Wed, 15 Feb 2023 01:13:16 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Proceeding down the line of FDLIBM functions to be ported, next up are asin, acos, and atan.
>> 
>> Diffs of the various versions will follow in a separate message.
>> 
>> There were no unusual coding idioms encountered in porting these methods.
>
> Joe Darcy has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Add asin test case.
>  - Refactor regression tests.

Looks fine.

-------------

Marked as reviewed by bpb (Reviewer).

PR: https://git.openjdk.org/jdk/pull/12545

From redestad at openjdk.org  Wed Feb 15 21:55:46 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Wed, 15 Feb 2023 21:55:46 GMT
Subject: RFR: 8302163: Speed up various String comparison methods with
 ArraysSupport.mismatch [v2]
In-Reply-To: <sLJArQhn8qKv67Op1gS-WMAnsXTJBqR_qWbdzApxOLc=.d225ea1e-1039-4492-877d-ede8b5a122b3@github.com>
References: <geAF-Q1dnCoJ0vCqMNHXXziVGii47nOkfyw5RTL_Wb0=.79392f23-0846-4e04-8b19-87289c3bf49f@github.com>
 <sLJArQhn8qKv67Op1gS-WMAnsXTJBqR_qWbdzApxOLc=.d225ea1e-1039-4492-877d-ede8b5a122b3@github.com>
Message-ID: <_1SZugpiGox9wsbOdDSmJVIm9BVBjkSeR9Qn20Qsag0=.3b9fa64b-1e96-47b2-a758-7b0b456904df@github.com>

On Mon, 13 Feb 2023 16:10:14 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> We can improve various String methods such as `startsWith`, `endsWith` and `regionMatches` by leveraging the intrinsified mismatch methods in `ArraysSupport`.
>
> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Clarify coder shift in startsWith

Thanks for reviewing!

-------------

PR: https://git.openjdk.org/jdk/pull/12528

From redestad at openjdk.org  Wed Feb 15 21:55:48 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Wed, 15 Feb 2023 21:55:48 GMT
Subject: Integrated: 8302163: Speed up various String comparison methods with
 ArraysSupport.mismatch
In-Reply-To: <geAF-Q1dnCoJ0vCqMNHXXziVGii47nOkfyw5RTL_Wb0=.79392f23-0846-4e04-8b19-87289c3bf49f@github.com>
References: <geAF-Q1dnCoJ0vCqMNHXXziVGii47nOkfyw5RTL_Wb0=.79392f23-0846-4e04-8b19-87289c3bf49f@github.com>
Message-ID: <1Vt85DWzxsDeIAP7zMJBQtzFnquOTUOFCxXYWI_SouU=.d2dcd8c5-9960-4945-b7e9-f43eddea667b@github.com>

On Mon, 13 Feb 2023 09:59:24 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> We can improve various String methods such as `startsWith`, `endsWith` and `regionMatches` by leveraging the intrinsified mismatch methods in `ArraysSupport`.

This pull request has now been integrated.

Changeset: 861e3020
Author:    Claes Redestad <redestad at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/861e302011bb3aaf0c8431c121b58a57b78481e3
Stats:     171 lines in 5 files changed: 107 ins; 44 del; 20 mod

8302163: Speed up various String comparison methods with ArraysSupport.mismatch

Reviewed-by: stsypanov, rriggs, alanb

-------------

PR: https://git.openjdk.org/jdk/pull/12528

From darcy at openjdk.org  Wed Feb 15 22:07:54 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 15 Feb 2023 22:07:54 GMT
Subject: RFR: JDK-8302026: Port fdlibm inverse trig functions (asin, acos, 
 atan) to Java [v3]
In-Reply-To: <4gBqg3J25LASN6tnRwZ22S3YlUHQrypgvZqynfKd3Os=.3a5e618f-b7eb-4978-a6ab-f1b30c793fb4@github.com>
References: <4gBqg3J25LASN6tnRwZ22S3YlUHQrypgvZqynfKd3Os=.3a5e618f-b7eb-4978-a6ab-f1b30c793fb4@github.com>
Message-ID: <lWVF7tIEPtMNn6d-Vm0cIXTtj-6obV-LJ_sFlmcTUyg=.252321d3-03d8-4b7b-b90b-c5d197a426d9@github.com>

> Proceeding down the line of FDLIBM functions to be ported, next up are asin, acos, and atan.
> 
> Diffs of the various versions will follow in a separate message.
> 
> There were no unusual coding idioms encountered in porting these methods.

Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:

  Include bug number in test.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12545/files
  - new: https://git.openjdk.org/jdk/pull/12545/files/e8195463..6c2a70af

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12545&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12545&range=01-02

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/12545.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12545/head:pull/12545

PR: https://git.openjdk.org/jdk/pull/12545

From duke at openjdk.org  Wed Feb 15 22:44:21 2023
From: duke at openjdk.org (David M. Lloyd)
Date: Wed, 15 Feb 2023 22:44:21 GMT
Subject: RFR: 8292914: Drop the counter from lambda class names [v2]
In-Reply-To: <GgLfH-ueBQqT-Mfk1mKpKFAt8fYqyjfVJ9lmlsBsCbo=.8dd5b3b4-4e84-4970-9179-1c0399b30edc@github.com>
References: <GgLfH-ueBQqT-Mfk1mKpKFAt8fYqyjfVJ9lmlsBsCbo=.8dd5b3b4-4e84-4970-9179-1c0399b30edc@github.com>
Message-ID: <TCfh3G-7r58qBb-XFaJS4ChtJhyexEcW0JQ_vjYsRaE=.1e37c994-fd92-470e-ac53-ba4da595b345@github.com>

> The class generated for lambda proxies is now defined as a hidden class. This means that the counter, which was used to ensure a unique class name and avoid clashes, is now redundant. In addition to performing redundant work, this also impacts build reproducibility for native image generators which might already have a strategy to cope with hidden classes but cannot cope with indeterminate definition order for lambda proxy classes.
> 
> This solves JDK-8292914 by making lambda proxy names always be stable without any configuration needed. This would also replace #10024.

David M. Lloyd has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:

  8292914: Drop the counter from lambda class names
  
  The class generated for lambda proxies is now defined as a hidden class. This means that the counter, which was used to ensure a unique class name and avoid clashes, is now redundant. In addition to performing redundant work, this also impacts build reproducibility for native image generators which might already have a strategy to cope with hidden classes but cannot cope with indeterminate definition order for lambda proxy classes.
  
  Additionally, the lambda proxy class dumper is enhanced to prepend a raw timestamp before the filename.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12579/files
  - new: https://git.openjdk.org/jdk/pull/12579/files/5ab516a5..0e109beb

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12579&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12579&range=00-01

  Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/12579.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12579/head:pull/12579

PR: https://git.openjdk.org/jdk/pull/12579

From darcy at openjdk.org  Wed Feb 15 22:44:40 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 15 Feb 2023 22:44:40 GMT
Subject: RFR: JDK-8301444: Port fdlibm hyperbolic transcendental functions
 to Java [v11]
In-Reply-To: <_s8xnppoDTnAajAjlmfB-dX5DBdawUcSSPaGWGLzFBk=.cdbf468a-ace7-45e5-a25a-833c760b776c@github.com>
References: <_s8xnppoDTnAajAjlmfB-dX5DBdawUcSSPaGWGLzFBk=.cdbf468a-ace7-45e5-a25a-833c760b776c@github.com>
Message-ID: <iExziGQ9TM4S7gQ57H1fIF-bjSGeoIOEupjqJtjENc4=.e7d3729f-4e19-42ad-9fdb-10467477d3a8@github.com>

> Initial pass of porting FDLIBM sinh/cosh/tanh to Java. I do intend to refactor the regression tests a bit to reduce duplication, but the actual ports should be ready for review.
> 
> Diff'ing the ports as before, original vs transliteration port:
> 
> 
> $ diff -w Hyperbolic.c Hyperbolic.translit.java
> 1c1
> < /* __ieee754_sinh(x)
> ---
>>     /**
> 17a18,19
>>     static class Sinh {
>>         private static final double one = 1.0, shuge = 1.0e307;
> 19,33c21
> < #include "fdlibm.h"
> < 
> < #ifdef __STDC__
> < static const double one = 1.0, shuge = 1.0e307;
> < #else
> < static double one = 1.0, shuge = 1.0e307;
> < #endif
> < 
> < #ifdef __STDC__
> <         double __ieee754_sinh(double x)
> < #else
> <         double __ieee754_sinh(x)
> <         double x;
> < #endif
> < {
> ---
>>         private static double compute(double x) {
> 36c24
> <         unsigned lx;
> ---
>>             /* unsigned */ int lx;
> 51c39
> <             t = expm1(fabs(x));
> ---
>>                 t = FdlibmTranslit.expm1(Math.abs(x));
> 57c45
> <         if (ix < 0x40862E42)  return h*__ieee754_exp(fabs(x));
> ---
>>             if (ix < 0x40862E42)  return h*StrictMath.exp(Math.abs(x)); // TODO switch to translit
> 60,62c48,52
> <         lx = *( (((*(unsigned*)&one)>>29)) + (unsigned*)&x);
> <         if (ix<0x408633CE || ((ix==0x408633ce)&&(lx<=(unsigned)0x8fb9f87d))) {
> <             w = __ieee754_exp(0.5*fabs(x));
> ---
>>             // lx = *( (((*(unsigned*)&one)>>29)) + (unsigned*)&x);
>>             // lx =  (((*(unsigned*)&one)>>29)) + (unsigned*)&x ;
>>             lx = __LO(x);
>>             if (ix<0x408633CE || ((ix==0x408633ce)&&(Long.compareUnsigned(lx, 0x8fb9f87d) <= 0 ))) {
>>                 w = StrictMath.exp(0.5*Math.abs(x)); // TODO switch to translit
> 70c60,62
> < /* __ieee754_cosh(x)
> ---
>>     }
>> 
>>     /**
> 90,105c82,84
> < 
> < #include "fdlibm.h"
> < 
> < #ifdef __STDC__
> < static const double one = 1.0, half=0.5, huge = 1.0e300;
> < #else
> < static double one = 1.0, half=0.5, huge = 1.0e300;
> < #endif
> < 
> < #ifdef __STDC__
> <         double __ieee754_cosh(double x)
> < #else
> <         double __ieee754_cosh(x)
> <         double x;
> < #endif
> < {
> ---
>>     static class Cosh {
>>         private static final double one = 1.0, half=0.5, huge = 1.0e300;
>>         private static double compute(double x) {
> 108c87
> <         unsigned lx;
> ---
>>             /*unsigned*/ int lx;
> 119c98
> <             t = expm1(fabs(x));
> ---
>>                 t = expm1(Math.abs(x));
> 127c106
> <                 t = __ieee754_exp(fabs(x));
> ---
>>                 t = StrictMath.exp(Math.abs(x)); // TODO switch to translit
> 132c111
> <         if (ix < 0x40862E42)  return half*__ieee754_exp(fabs(x));
> ---
>>             if (ix < 0x40862E42)  return half*StrictMath.exp(Math.abs(x)); // TODO switch to translit
> 135c114
> <         lx = *( (((*(unsigned*)&one)>>29)) + (unsigned*)&x);
> ---
>>             lx = __LO(x);
> 137,138c116,117
> <               ((ix==0x408633ce)&&(lx<=(unsigned)0x8fb9f87d))) {
> <             w = __ieee754_exp(half*fabs(x));
> ---
>>                 ((ix==0x408633ce)&&(Integer.compareUnsigned(lx, 0x8fb9f87d) <= 0))) {
>>                 w = StrictMath.exp(half*Math.abs(x)); // TODO switch to translit
> 146c125,127
> < /* Tanh(x)
> ---
>>     }
>> 
>>     /**
> 169,184c150,152
> < 
> < #include "fdlibm.h"
> < 
> < #ifdef __STDC__
> < static const double one=1.0, two=2.0, tiny = 1.0e-300;
> < #else
> < static double one=1.0, two=2.0, tiny = 1.0e-300;
> < #endif
> < 
> < #ifdef __STDC__
> <         double tanh(double x)
> < #else
> <         double tanh(x)
> <         double x;
> < #endif
> < {
> ---
>>     static class Tanh {
>>         private static final double one=1.0, two=2.0, tiny = 1.0e-300;
>>         static double compute(double x) {
> 203c171
> <                 t = expm1(two*fabs(x));
> ---
>>                     t = expm1(two*Math.abs(x));
> 206c174
> <                 t = expm1(-two*fabs(x));
> ---
>>                     t = expm1(-two*Math.abs(x));
> 214a183
>>     }
> 
> 
> Note that the original has a in-line version of the "__LO" macro rather than using the macro.
> 
> 
> And transliteration vs more idiomatic:
> 
> 
> $ diff -w Hyperbolic.translit.java Hyperbolic.fdlibm.java 
> 21c21
> <         private static double compute(double x) {
> ---
>>          static double compute(double x) {
> 26c26
> <             /* High word of |x|. */
> ---
>>             // High word of |x|
> 28c28
> <             ix = jx&0x7fffffff;
> ---
>>             ix = jx & 0x7fff_ffff;
> 30,31c30,33
> <             /* x is INF or NaN */
> <             if(ix>=0x7ff00000) return x+x;
> ---
>>             // x is INF or NaN
>>             if ( ix >= 0x7ff0_0000) {
>>                 return x + x;
>>             }
> 34,40c36,48
> <             if (jx<0) h = -h;
> <             /* |x| in [0,22], return sign(x)*0.5*(E+E/(E+1))) */
> <             if (ix < 0x40360000) {          /* |x|<22 */
> <                 if (ix<0x3e300000)          /* |x|<2**-28 */
> <                     if(shuge+x>one) return x;/* sinh(tiny) = tiny with inexact */
> <                 t = FdlibmTranslit.expm1(Math.abs(x));
> <                 if(ix<0x3ff00000) return h*(2.0*t-t*t/(t+one));
> ---
>>             if ( jx < 0) {
>>                 h = -h;
>>             }
>>             // |x| in [0,22], return sign(x)*0.5*(E+E/(E+1)))
>>             if (ix < 0x4036_0000) {          // |x| < 22
>>                 if (ix < 0x3e30_0000)        // |x| < 2**-28
>>                     if (shuge + x > one) {   // sinh(tiny) = tiny with inexact
>>                         return x;
>>                     }
>>                 t = StrictMath.expm1(Math.abs(x));
>>                 if (ix < 0x3ff0_0000) {
>>                     return h*(2.0 * t - t*t/(t + one));
>>                 }
> 44,45c52,55
> <             /* |x| in [22, log(maxdouble)] return 0.5*exp(|x|) */
> <             if (ix < 0x40862E42)  return h*StrictMath.exp(Math.abs(x)); // TODO switch to translit
> ---
>>             // |x| in [22, log(maxdouble)] return 0.5*exp(|x|)
>>             if (ix < 0x4086_2E42) {
>>                 return h*StrictMath.exp(Math.abs(x));
>>             }
> 47,49c57
> <             /* |x| in [log(maxdouble), overflowthresold] */
> <             // lx = *( (((*(unsigned*)&one)>>29)) + (unsigned*)&x);
> <             // lx =  (((*(unsigned*)&one)>>29)) + (unsigned*)&x ;
> ---
>>             // |x| in [log(maxdouble), overflowthresold]
> 51,52c59,62
> <             if (ix<0x408633CE || ((ix==0x408633ce)&&(Long.compareUnsigned(lx, 0x8fb9f87d) <= 0 ))) {
> <                 w = StrictMath.exp(0.5*Math.abs(x)); // TODO switch to translit
> ---
>>             if (ix < 0x4086_33CE ||
>>                 ((ix == 0x4086_33ce) &&
>>                  (Long.compareUnsigned(lx, 0x8fb9_f87d) <= 0 ))) {
>>                 w = StrictMath.exp(0.5 * Math.abs(x));
> 57c67
> <             /* |x| > overflowthresold, sinh(x) overflow */
> ---
>>             // |x| > overflowthresold, sinh(x) overflow
> 84c94
> <         private static double compute(double x) {
> ---
>>         static double compute(double x) {
> 89c99
> <             /* High word of |x|. */
> ---
>>             // High word of |x|
> 91c101
> <             ix &= 0x7fffffff;
> ---
>>             ix &= 0x7fff_ffff;
> 93,94c103,106
> <             /* x is INF or NaN */
> <             if(ix>=0x7ff00000) return x*x;
> ---
>>             // x is INF or NaN
>>             if (ix >= 0x7ff_00000) {
>>                 return x*x;
>>             }
> 96,98c108,110
> <             /* |x| in [0,0.5*ln2], return 1+expm1(|x|)^2/(2*exp(|x|)) */
> <             if(ix<0x3fd62e43) {
> <                 t = expm1(Math.abs(x));
> ---
>>             // |x| in [0,0.5*ln2], return 1+expm1(|x|)^2/(2*exp(|x|))
>>             if (ix < 0x3fd6_2e43) {
>>                 t = StrictMath.expm1(Math.abs(x));
> 100c112,114
> <                 if (ix<0x3c800000) return w;        /* cosh(tiny) = 1 */
> ---
>>                 if (ix < 0x3c80_0000) { // cosh(tiny) = 1
>>                     return w;
>>                 }
> 104,106c118,120
> <             /* |x| in [0.5*ln2,22], return (exp(|x|)+1/exp(|x|)/2; */
> <             if (ix < 0x40360000) {
> <                 t = StrictMath.exp(Math.abs(x)); // TODO switch to translit
> ---
>>             // |x| in [0.5*ln2, 22], return (exp(|x|) + 1/exp(|x|)/2
>>             if (ix < 0x4036_0000) {
>>                 t = StrictMath.exp(Math.abs(x));
> 110,111c124,127
> <             /* |x| in [22, log(maxdouble)] return half*exp(|x|) */
> <             if (ix < 0x40862E42)  return half*StrictMath.exp(Math.abs(x)); // TODO switch to translit
> ---
>>             // |x| in [22, log(maxdouble)] return half*exp(|x|)
>>             if (ix < 0x4086_2E42) {
>>                 return half*StrictMath.exp(Math.abs(x));
>>             }
> 113c129
> <             /* |x| in [log(maxdouble), overflowthresold] */
> ---
>>             // |x| in [log(maxdouble), overflowthresold]
> 115,117c131,134
> <             if (ix<0x408633CE ||
> <                 ((ix==0x408633ce)&&(Integer.compareUnsigned(lx, 0x8fb9f87d) <= 0))) {
> <                 w = StrictMath.exp(half*Math.abs(x)); // TODO switch to translit
> ---
>>             if (ix<0x4086_33CE ||
>>                 ((ix == 0x4086_33ce) &&
>>                  (Integer.compareUnsigned(lx, 0x8fb9_f87d) <= 0))) {
>>                 w = StrictMath.exp(half*Math.abs(x));
> 122c139
> <             /* |x| > overflowthresold, cosh(x) overflow */
> ---
>>             // |x| > overflowthresold, cosh(x) overflow
> 126d142
> < 
> 156c172
> <             /* High word of |x|. */
> ---
>>             // High word of |x|.
> 158c174
> <             ix = jx&0x7fffffff;
> ---
>>             ix = jx & 0x7fff_ffff;
> 160,163c176,182
> <             /* x is INF or NaN */
> <             if(ix>=0x7ff00000) {
> <                 if (jx>=0) return one/x+one;    /* tanh(+-inf)=+-1 */
> <                 else       return one/x-one;    /* tanh(NaN) = NaN */
> ---
>>             // x is INF or NaN
>>             if (ix >= 0x7ff0_0000) {
>>                 if (jx >= 0) {  // tanh(+-inf)=+-1
>>                     return one/x + one;
>>                 } else {        // tanh(NaN) = NaN
>>                     return one/x - one;
>>                 }
> 166,171c185,190
> <             /* |x| < 22 */
> <             if (ix < 0x40360000) {          /* |x|<22 */
> <                 if (ix<0x3c800000)          /* |x|<2**-55 */
> <                     return x*(one+x);       /* tanh(small) = small */
> <                 if (ix>=0x3ff00000) {       /* |x|>=1  */
> <                     t = expm1(two*Math.abs(x));
> ---
>>             // |x| < 22
>>             if (ix < 0x4036_0000) {          // |x| < 22
>>                 if (ix<0x3c80_0000)          // |x| < 2**-55
>>                     return x*(one + x);      // tanh(small) = small
>>                 if (ix>=0x3ff0_0000) {       // |x| >= 1
>>                     t = StrictMath.expm1(two*Math.abs(x));
> 174c193
> <                     t = expm1(-two*Math.abs(x));
> ---
>>                     t = StrictMath.expm1(-two*Math.abs(x));
> 177,179c196,197
> <                 /* |x| > 22, return +-1 */
> <             } else {
> <                 z = one - tiny;             /* raised inexact flag */
> ---
>>             } else { // |x| > 22, return +-1
>>                 z = one - tiny;             // raised inexact flag

Joe Darcy 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 JDK-8301444
 - Refactor regression test.
 - Small refactorings in Fdlibm.java
 - Remove unnecessary semicolons.
 - Add exhausting test coverage.
 - Merge branch 'master' into JDK-8301444
 - Merge branch 'master' into JDK-8301444
 - Improve exp usage.
 - Add additional note.
 - Respond to review feedback.
 - ... and 4 more: https://git.openjdk.org/jdk/compare/3ba15608...3c4e1812

-------------

Changes: https://git.openjdk.org/jdk/pull/12429/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12429&range=10
  Stats: 675 lines in 6 files changed: 625 ins; 19 del; 31 mod
  Patch: https://git.openjdk.org/jdk/pull/12429.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12429/head:pull/12429

PR: https://git.openjdk.org/jdk/pull/12429

From darcy at openjdk.org  Wed Feb 15 22:48:46 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 15 Feb 2023 22:48:46 GMT
Subject: Integrated: JDK-8302026: Port fdlibm inverse trig functions (asin,
 acos, atan) to Java
In-Reply-To: <4gBqg3J25LASN6tnRwZ22S3YlUHQrypgvZqynfKd3Os=.3a5e618f-b7eb-4978-a6ab-f1b30c793fb4@github.com>
References: <4gBqg3J25LASN6tnRwZ22S3YlUHQrypgvZqynfKd3Os=.3a5e618f-b7eb-4978-a6ab-f1b30c793fb4@github.com>
Message-ID: <qsXd_D-6YyvTjDKBLgT-YPLtHiPy4dadkFvNoJez2Gg=.4392821f-8996-4ce4-955b-e8d91d6d5844@github.com>

On Mon, 13 Feb 2023 22:03:14 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Proceeding down the line of FDLIBM functions to be ported, next up are asin, acos, and atan.
> 
> Diffs of the various versions will follow in a separate message.
> 
> There were no unusual coding idioms encountered in porting these methods.

This pull request has now been integrated.

Changeset: 3ba15608
Author:    Joe Darcy <darcy at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/3ba156082b73c4a8e9d890a57a42fb68df2bf98f
Stats:     994 lines in 6 files changed: 986 ins; 0 del; 8 mod

8302026: Port fdlibm inverse trig functions (asin, acos, atan) to Java

Reviewed-by: bpb

-------------

PR: https://git.openjdk.org/jdk/pull/12545

From mchung at openjdk.org  Wed Feb 15 22:55:16 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Wed, 15 Feb 2023 22:55:16 GMT
Subject: RFR: 8292914: Drop the counter from lambda class names [v2]
In-Reply-To: <TCfh3G-7r58qBb-XFaJS4ChtJhyexEcW0JQ_vjYsRaE=.1e37c994-fd92-470e-ac53-ba4da595b345@github.com>
References: <GgLfH-ueBQqT-Mfk1mKpKFAt8fYqyjfVJ9lmlsBsCbo=.8dd5b3b4-4e84-4970-9179-1c0399b30edc@github.com>
 <TCfh3G-7r58qBb-XFaJS4ChtJhyexEcW0JQ_vjYsRaE=.1e37c994-fd92-470e-ac53-ba4da595b345@github.com>
Message-ID: <_mW2VdU_jkI2y6iuB4FvV5vmPQGhJlSLXEdojnYlZEw=.4ea49ff0-3c0f-4cb2-933b-b3182891114c@github.com>

On Wed, 15 Feb 2023 22:44:21 GMT, David M. Lloyd <duke at openjdk.org> wrote:

>> The class generated for lambda proxies is now defined as a hidden class. This means that the counter, which was used to ensure a unique class name and avoid clashes, is now redundant. In addition to performing redundant work, this also impacts build reproducibility for native image generators which might already have a strategy to cope with hidden classes but cannot cope with indeterminate definition order for lambda proxy classes.
>> 
>> This solves JDK-8292914 by making lambda proxy names always be stable without any configuration needed. This would also replace #10024.
>
> David M. Lloyd has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:
> 
>   8292914: Drop the counter from lambda class names
>   
>   The class generated for lambda proxies is now defined as a hidden class. This means that the counter, which was used to ensure a unique class name and avoid clashes, is now redundant. In addition to performing redundant work, this also impacts build reproducibility for native image generators which might already have a strategy to cope with hidden classes but cannot cope with indeterminate definition order for lambda proxy classes.
>   
>   Additionally, the lambda proxy class dumper is enhanced to prepend a raw timestamp before the filename.

This would address my concern.  If the hidden class was defined successfully, use the hidden class name as the filename;  otherwise, construct the file name a different counter - I also like Brian's suggestion "$timestamp-$classname$" for the reasons he noted.

Note that the hidden class name returned by `Class::getName` is `p.Foo$Lambda$$  + "/" + <suffix>`.   When dumping to a file, the pathname should be `p/Foo$Lambda$$.<suffix>` matching the type descriptor (converting '/' to '.').

-------------

PR: https://git.openjdk.org/jdk/pull/12579

From duke at openjdk.org  Wed Feb 15 23:13:12 2023
From: duke at openjdk.org (David M. Lloyd)
Date: Wed, 15 Feb 2023 23:13:12 GMT
Subject: RFR: 8292914: Drop the counter from lambda class names [v2]
In-Reply-To: <TCfh3G-7r58qBb-XFaJS4ChtJhyexEcW0JQ_vjYsRaE=.1e37c994-fd92-470e-ac53-ba4da595b345@github.com>
References: <GgLfH-ueBQqT-Mfk1mKpKFAt8fYqyjfVJ9lmlsBsCbo=.8dd5b3b4-4e84-4970-9179-1c0399b30edc@github.com>
 <TCfh3G-7r58qBb-XFaJS4ChtJhyexEcW0JQ_vjYsRaE=.1e37c994-fd92-470e-ac53-ba4da595b345@github.com>
Message-ID: <NPLcbwmVWKMhP_RDwOkW_UgztTgvv6vUg2Hsrz9URKE=.09a73015-9135-49cf-9410-cc1e7220c984@github.com>

On Wed, 15 Feb 2023 22:44:21 GMT, David M. Lloyd <duke at openjdk.org> wrote:

>> The class generated for lambda proxies is now defined as a hidden class. This means that the counter, which was used to ensure a unique class name and avoid clashes, is now redundant. In addition to performing redundant work, this also impacts build reproducibility for native image generators which might already have a strategy to cope with hidden classes but cannot cope with indeterminate definition order for lambda proxy classes.
>> 
>> This solves JDK-8292914 by making lambda proxy names always be stable without any configuration needed. This would also replace #10024.
>
> David M. Lloyd has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:
> 
>   8292914: Drop the counter from lambda class names
>   
>   The class generated for lambda proxies is now defined as a hidden class. This means that the counter, which was used to ensure a unique class name and avoid clashes, is now redundant. In addition to performing redundant work, this also impacts build reproducibility for native image generators which might already have a strategy to cope with hidden classes but cannot cope with indeterminate definition order for lambda proxy classes.
>   
>   Additionally, the lambda proxy class dumper is enhanced to prepend a raw timestamp before the filename.

It looks like just prepending a timestamp is not exactly ideal since it would put it before the first directory segment of the path. So, I'm looking at wedging it in before the last segment. Also, I'm just using a raw timestamp value, because the date formatting infrastructure relies on lambdas.

-------------

PR: https://git.openjdk.org/jdk/pull/12579

From duke at openjdk.org  Wed Feb 15 23:23:22 2023
From: duke at openjdk.org (David M. Lloyd)
Date: Wed, 15 Feb 2023 23:23:22 GMT
Subject: RFR: 8292914: Drop the counter from lambda class names [v3]
In-Reply-To: <GgLfH-ueBQqT-Mfk1mKpKFAt8fYqyjfVJ9lmlsBsCbo=.8dd5b3b4-4e84-4970-9179-1c0399b30edc@github.com>
References: <GgLfH-ueBQqT-Mfk1mKpKFAt8fYqyjfVJ9lmlsBsCbo=.8dd5b3b4-4e84-4970-9179-1c0399b30edc@github.com>
Message-ID: <Z-eLHzIY9JRIo5cva_M92DkZX7qT871cCzW2q3xWdKI=.b996b8c4-5105-4099-83c2-b29907995540@github.com>

> The class generated for lambda proxies is now defined as a hidden class. This means that the counter, which was used to ensure a unique class name and avoid clashes, is now redundant. In addition to performing redundant work, this also impacts build reproducibility for native image generators which might already have a strategy to cope with hidden classes but cannot cope with indeterminate definition order for lambda proxy classes.
> 
> This solves JDK-8292914 by making lambda proxy names always be stable without any configuration needed. This would also replace #10024.

David M. Lloyd has updated the pull request incrementally with two additional commits since the last revision:

 - Import
 - Beter timestamp placement

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12579/files
  - new: https://git.openjdk.org/jdk/pull/12579/files/0e109beb..85620a44

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12579&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12579&range=01-02

  Stats: 8 lines in 2 files changed: 4 ins; 2 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/12579.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12579/head:pull/12579

PR: https://git.openjdk.org/jdk/pull/12579

From duke at openjdk.org  Thu Feb 16 01:42:16 2023
From: duke at openjdk.org (David M. Lloyd)
Date: Thu, 16 Feb 2023 01:42:16 GMT
Subject: RFR: 8292914: Drop the counter from lambda class names [v4]
In-Reply-To: <GgLfH-ueBQqT-Mfk1mKpKFAt8fYqyjfVJ9lmlsBsCbo=.8dd5b3b4-4e84-4970-9179-1c0399b30edc@github.com>
References: <GgLfH-ueBQqT-Mfk1mKpKFAt8fYqyjfVJ9lmlsBsCbo=.8dd5b3b4-4e84-4970-9179-1c0399b30edc@github.com>
Message-ID: <NtA7-4LZQtr2JwdCmWgzHP9I-eV6k2bWRRxHcH6ENMo=.72d26ca4-cda5-481d-92d1-59265044f030@github.com>

> The class generated for lambda proxies is now defined as a hidden class. This means that the counter, which was used to ensure a unique class name and avoid clashes, is now redundant. In addition to performing redundant work, this also impacts build reproducibility for native image generators which might already have a strategy to cope with hidden classes but cannot cope with indeterminate definition order for lambda proxy classes.
> 
> This solves JDK-8292914 by making lambda proxy names always be stable without any configuration needed. This would also replace #10024.

David M. Lloyd has updated the pull request incrementally with two additional commits since the last revision:

 - Fix LambdaAsm test
 - Fix stack walker test

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12579/files
  - new: https://git.openjdk.org/jdk/pull/12579/files/85620a44..d56b77a2

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12579&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12579&range=02-03

  Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/12579.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12579/head:pull/12579

PR: https://git.openjdk.org/jdk/pull/12579

From igraves at openjdk.org  Thu Feb 16 03:35:31 2023
From: igraves at openjdk.org (Ian Graves)
Date: Thu, 16 Feb 2023 03:35:31 GMT
Subject: RFR: 8293667: Align jlink's --compress option with jmod's
 --compress option [v8]
In-Reply-To: <JWevwHuR2vF3k-JRxmTAxfNN6g-EBkgG2N9DHn4fkGY=.f9768dfd-cab4-49a9-83b9-d77a1572e917@github.com>
References: <JWevwHuR2vF3k-JRxmTAxfNN6g-EBkgG2N9DHn4fkGY=.f9768dfd-cab4-49a9-83b9-d77a1572e917@github.com>
Message-ID: <4BYAhi9LFmHwShwCV1Ii5hDxneje8QdlppEJI8_W4hw=.8fc71e0e-404e-47c9-8b58-c95fd9954698@github.com>

> This is an approach to adding a flag to jlink that will allow --compress to take the same types of arguments as jmod, thus bringing the two into alignment. This likely requires a CSR and a discussion on whether we should deprecate or simply remove the original numeric compression arguments.

Ian Graves has updated the pull request incrementally with one additional commit since the last revision:

  Updating properties

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/11617/files
  - new: https://git.openjdk.org/jdk/pull/11617/files/92416003..c9f4f32b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11617&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11617&range=06-07

  Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/11617.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11617/head:pull/11617

PR: https://git.openjdk.org/jdk/pull/11617

From smarks at openjdk.org  Thu Feb 16 04:41:38 2023
From: smarks at openjdk.org (Stuart Marks)
Date: Thu, 16 Feb 2023 04:41:38 GMT
Subject: RFR: 8296935: Arrays.asList().set() with wrong types throws
 undocumented ArrayStoreException [v8]
In-Reply-To: <rv7uknWqe6ptzUXBtPKFc-83gpSEV_cP26xPQgsK0LE=.4fe5fed8-0c3c-467a-a21e-26349bd38cba@github.com>
References: <9JFNgXqBSj9uR8vR9oIooJMxtf74y12L0-GbjOO7fJg=.769953c2-40f3-49c0-8598-ce940d2d95d4@github.com>
 <HvasxUr1OcjOvITT8vm-nBSSYXCRJIOVe5niJpsGT2U=.a092ea8d-a6f0-4c00-b934-b4030d1494fe@github.com>
 <rv7uknWqe6ptzUXBtPKFc-83gpSEV_cP26xPQgsK0LE=.4fe5fed8-0c3c-467a-a21e-26349bd38cba@github.com>
Message-ID: <jkYnEiUUzkKZApprSxyq9KXj2SG-C5srT9YATYEsROE=.8a67ce2e-f9bc-4af4-9cb7-87d54e808131@github.com>

On Wed, 8 Feb 2023 23:33:57 GMT, Tingjun Yuan <duke at openjdk.org> wrote:

>> Tingjun Yuan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update Arrays.java
>
> I've written a CSR report for this PR as below.  Could someone please help me to submit it to the JBS if it looks okay? Thank you!
> 
> ---
> 
> **Compatibility Risk:** minimum
> 
> **Compatibility Risk Description:** No implementation is modified
> 
> ## Summary
> 
> Document the current behavior of `java.util.Arrays.asList(Object...)` that it will throw an `ArrayStoreException` when an element of wrong type is trying to be set into the list.
> 
> ## Problem
> 
> `java.util.Arrays.asList(Object...)` is a widely used method that wraps an object array into a mutable `List`.  The specification of  methods `List.set` and `ListIterator.set` indicates that implementations should throw a `ClassCastException` when the class of the specified element prevents it from being added to this list. However when an application tries to store an element that is not compatible with the backing array component type via the returned list, an `ArrayStoreException` will be thrown instead of `ClassCastException`, which violates the `List` specification.
> 
> ## Solution
> 
> Since this method is widely used, we do not change the current behavior. Instead, we document the current behavior of `java.util.Arrays.asList(Object...)` that it will throw an `ArrayStoreException` when an element of wrong type is trying to be set into the list.
> 
> ## Specification
> 
> Add the following `@apiNote` section into the `java.util.Arrays.asList` specification:
> 
> 
>      * @apiNote
>      * The {@link List} returned by this method does not conform to the
>      * specification for {@link List#set} and {@link ListIterator#set}.
>      * It is possible for the type parameter {@code T} of the returned list
>      * to differ from the array's component type. This can occur, for example,
>      * if the array argument type has been upcast from its component type:
>      *
>      * {@snippet :
>      *    String[] strings = new String[1];
>      *    List<Object> objects = Arrays.asList((Object[])strings);
>      * }
>      *
>      * Writing an element into the returned list may result in an
>      * {@link ArrayStoreException} instead of {@link ClassCastException} being
>      * thrown if the element is incompatible with the underlying array's
>      * component type:
>      *
>      * {@snippet :
>      *    objects.set(0, Integer.valueOf(0)); // throws ArrayStoreException
>      * }

@yuantj 

The proposed change needs additional editing. In particular, the issue is not about conformance. I'd need to suggest changes that you'd apply, in order to get the text in the change to match what I'm essentially writing myself. In addition, CSR also needs quite a bit of editing, which I'd write myself anyway. Thus I don't think it's worth continuing with this PR. Thanks for your efforts, though, in raising the issue and attempting to address it.

The main point is that this isn't a spec violation, and if it were, one part of the specification can't "note" itself out of conforming to another part of the specification. The issue is really a clarification that some implementations might throw exceptions beyond those explicitly listed in the interface.

-------------

PR: https://git.openjdk.org/jdk/pull/12135

From duke at openjdk.org  Thu Feb 16 04:49:13 2023
From: duke at openjdk.org (Tingjun Yuan)
Date: Thu, 16 Feb 2023 04:49:13 GMT
Subject: RFR: 8296935: Arrays.asList().set() with wrong types throws
 undocumented ArrayStoreException [v8]
In-Reply-To: <jkYnEiUUzkKZApprSxyq9KXj2SG-C5srT9YATYEsROE=.8a67ce2e-f9bc-4af4-9cb7-87d54e808131@github.com>
References: <9JFNgXqBSj9uR8vR9oIooJMxtf74y12L0-GbjOO7fJg=.769953c2-40f3-49c0-8598-ce940d2d95d4@github.com>
 <HvasxUr1OcjOvITT8vm-nBSSYXCRJIOVe5niJpsGT2U=.a092ea8d-a6f0-4c00-b934-b4030d1494fe@github.com>
 <rv7uknWqe6ptzUXBtPKFc-83gpSEV_cP26xPQgsK0LE=.4fe5fed8-0c3c-467a-a21e-26349bd38cba@github.com>
 <jkYnEiUUzkKZApprSxyq9KXj2SG-C5srT9YATYEsROE=.8a67ce2e-f9bc-4af4-9cb7-87d54e808131@github.com>
Message-ID: <amycubSlb9pJ9_Hj9SvqBSfKrkSYbpoi9PJO_mYJlnU=.714287a9-2c57-4113-9b27-29fd62af4f64@github.com>

On Thu, 16 Feb 2023 04:39:20 GMT, Stuart Marks <smarks at openjdk.org> wrote:

>> I've written a CSR report for this PR as below.  Could someone please help me to submit it to the JBS if it looks okay? Thank you!
>> 
>> ---
>> 
>> **Compatibility Risk:** minimum
>> 
>> **Compatibility Risk Description:** No implementation is modified
>> 
>> ## Summary
>> 
>> Document the current behavior of `java.util.Arrays.asList(Object...)` that it will throw an `ArrayStoreException` when an element of wrong type is trying to be set into the list.
>> 
>> ## Problem
>> 
>> `java.util.Arrays.asList(Object...)` is a widely used method that wraps an object array into a mutable `List`.  The specification of  methods `List.set` and `ListIterator.set` indicates that implementations should throw a `ClassCastException` when the class of the specified element prevents it from being added to this list. However when an application tries to store an element that is not compatible with the backing array component type via the returned list, an `ArrayStoreException` will be thrown instead of `ClassCastException`, which violates the `List` specification.
>> 
>> ## Solution
>> 
>> Since this method is widely used, we do not change the current behavior. Instead, we document the current behavior of `java.util.Arrays.asList(Object...)` that it will throw an `ArrayStoreException` when an element of wrong type is trying to be set into the list.
>> 
>> ## Specification
>> 
>> Add the following `@apiNote` section into the `java.util.Arrays.asList` specification:
>> 
>> 
>>      * @apiNote
>>      * The {@link List} returned by this method does not conform to the
>>      * specification for {@link List#set} and {@link ListIterator#set}.
>>      * It is possible for the type parameter {@code T} of the returned list
>>      * to differ from the array's component type. This can occur, for example,
>>      * if the array argument type has been upcast from its component type:
>>      *
>>      * {@snippet :
>>      *    String[] strings = new String[1];
>>      *    List<Object> objects = Arrays.asList((Object[])strings);
>>      * }
>>      *
>>      * Writing an element into the returned list may result in an
>>      * {@link ArrayStoreException} instead of {@link ClassCastException} being
>>      * thrown if the element is incompatible with the underlying array's
>>      * component type:
>>      *
>>      * {@snippet :
>>      *    objects.set(0, Integer.valueOf(0)); // throws ArrayStoreException
>>      * }
>
> @yuantj 
> 
> The proposed change needs additional editing. In particular, the issue is not about conformance. I'd need to suggest changes that you'd apply, in order to get the text in the change to match what I'm essentially writing myself. In addition, CSR also needs quite a bit of editing, which I'd write myself anyway. Thus I don't think it's worth continuing with this PR. Thanks for your efforts, though, in raising the issue and attempting to address it.
> 
> The main point is that this isn't a spec violation, and if it were, one part of the specification can't "note" itself out of conforming to another part of the specification. The issue is really a clarification that some implementations might throw exceptions beyond those explicitly listed in the interface.

@stuart-marks Okay, I got it. Thanks for your reviewing anyway. Going to close this PR.

-------------

PR: https://git.openjdk.org/jdk/pull/12135

From duke at openjdk.org  Thu Feb 16 04:49:15 2023
From: duke at openjdk.org (Tingjun Yuan)
Date: Thu, 16 Feb 2023 04:49:15 GMT
Subject: Withdrawn: 8296935: Arrays.asList().set() with wrong types throws
 undocumented ArrayStoreException
In-Reply-To: <9JFNgXqBSj9uR8vR9oIooJMxtf74y12L0-GbjOO7fJg=.769953c2-40f3-49c0-8598-ce940d2d95d4@github.com>
References: <9JFNgXqBSj9uR8vR9oIooJMxtf74y12L0-GbjOO7fJg=.769953c2-40f3-49c0-8598-ce940d2d95d4@github.com>
Message-ID: <YEDNrShQjY3gfRKo5xc85Uqls118AeSXKo3d1RJXDWM=.a5e9a710-7e69-4156-8ae1-7e9be64dbd92@github.com>

On Mon, 23 Jan 2023 02:35:19 GMT, Tingjun Yuan <duke at openjdk.org> wrote:

> Document `java.util.Arrays.asList` that the list will throw an `ArrayStoreException` when attempting to set an element with a wrong type.

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/12135

From duke at openjdk.org  Thu Feb 16 05:35:26 2023
From: duke at openjdk.org (Amit Kumar)
Date: Thu, 16 Feb 2023 05:35:26 GMT
Subject: RFR: 8299748: java/util/zip/Deinflate.java failing on s390x
In-Reply-To: <qwjoHqgbDmbLmBVNyUmOUPlt7MQzSNnD8FBEYTMhgNg=.2a376dd3-9192-4acb-b3e3-f470991706eb@github.com>
References: <Usxi4wE5GSHHv-cKPfW6OXylhieAypbsidUX_Jo6FSQ=.34104cf0-2243-478f-86ce-9a91905c6755@github.com>
 <nN80i01pPGVl8QlQ09eEEEeFTz5z2hpM6udh2bNJwpU=.925ff5c6-586b-4262-bcd0-fd67d44cfde2@github.com>
 <jyL7HTlmcVxDKffdPqij6GNM0ePfzVxlypfy3hTtOAM=.3347a8dd-4722-4b79-b93e-b20892901c6b@github.com>
 <2eqxeIzcejWahzfAMe-czlbIQ96bV8s_RIkXQsXMtsY=.b329489c-40fc-4e91-9e30-10a3df53711e@github.com>
 <p1li8W4D2kYNZlxTOyvlqVrZWOjGbh6g1JfG6eHxAmE=.389b076c-0943-4cfd-af82-f24a56d1ac61@github.com>
 <mViUt9K-2zX1iclGWss9oGHP1HM3Xigq3ZAI-ZYV9Ww=.851a49c3-c57c-46d7-9b6b-db5ffda2daf1@github.com>
 <_SfmRrzgThXEqx714Hx-z6hyhJedR_j3KqryCcZ7Ks8=.1b7b7dc6-927e-42ce-b659-23c5c9f603c0@github.com>
 <qwjoHqgbDmbLmBVNyUmOUPlt7MQzSNnD8FBEYTMhgNg=.2a376dd3-9192-4acb-b3e3-f470991706eb@github.com>
Message-ID: <_Q8SmfDM6g63NP7vBn9As_n_X6ejp_W08o9lbmlUq3I=.0967d833-b2a0-498b-ba44-22be4ecd95ff@github.com>

On Wed, 15 Feb 2023 08:15:28 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>I assume you can quickly check which loop, I suspect it's the deflate loop based of the previous comments/experiments.

Both of loop's are  inf-loops with this change. If somehow I terminate the first loop then second goes into infinite state. 

>Your initial proposal was to increase the size of out1 but I can't see any cases in this test where the deflate fills out1 completely.

Alan Here are some stats (after increasing the `out1` size with a factor of 32), where I was looking for `what size of array do we need to store compressed data` and `array capacity we have`: 

Capacity with out1 * 32: 557056 <-> Buffer we need 552981
Capacity with out1 * 32: 557056 <-> Buffer we need 552975

Initial size of `out1`:  525312

As you can see, the size of out1 is insufficient for the s390x. That's why I proposed the fix to increase the buffer size. 
Because the compressor is not deterministic, I don't want to be byte-perfect, so I changed the multiplier to `64` to leave some extra space here.

-------------

PR: https://git.openjdk.org/jdk/pull/12283

From mdoerr at openjdk.org  Thu Feb 16 06:02:28 2023
From: mdoerr at openjdk.org (Martin Doerr)
Date: Thu, 16 Feb 2023 06:02:28 GMT
Subject: RFR: 8302158: PPC:
 test/jdk/jdk/internal/vm/Continuation/Fuzz.java: AssertionError: res: false
 shouldPin: false [v2]
In-Reply-To: <MmOeDc2ETuOsVcS-R-noo92M35DdOLpbOapofWah5Mg=.051144c9-71c6-48bc-8017-477894177ce0@github.com>
References: <G-cEPYqp6JlMkj9qo0S9HuNXRiuROZ7q69FQYIsDewM=.d20f3ee3-ed25-4bd3-93cd-2a55faa515d3@github.com>
 <MmOeDc2ETuOsVcS-R-noo92M35DdOLpbOapofWah5Mg=.051144c9-71c6-48bc-8017-477894177ce0@github.com>
Message-ID: <5AzezQ8wN3nMxXccPmkQCEGjPHomkmXFOqjfXoMKWv8=.87f1eb49-25a9-4945-b6d4-4ae148205b0d@github.com>

On Wed, 15 Feb 2023 20:30:00 GMT, Richard Reingruber <rrich at openjdk.org> wrote:

>> This fixes the linked issue by trimming the caller of a frame to be deoptimized back to its `unextended_sp` iff it is compiled. The creation of the section `dead after deoptimization` shown in the attachment [yield_after_deopt_failure.log](https://bugs.openjdk.org/secure/attachment/102602/yield_after_deopt_failure.log) is prevented by this.
>> 
>> A new mode is added to the test BasicExt.java where all frames are deoptimized after a yield operation. The issue can be deterministically reproduced with the new mode. It's not worth to execute all test cases with the new mode though. Instead `ContinuationCompiledFramesWithStackArgs_3c4` is always executed a 2nd time in this mode.
>> 
>> Before this BasicExt.java was refactored for better argument processing and representation of the test modes.
>> Also the try-catch-clause in the main method had to be changed to rethrow the caught exception because without this the test would have succeeded.
>> 
>> Testing: jtreg tests tier 1-4 on standard platforms and also on ppc64le.
>
> Richard Reingruber has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Improve comment
>  - Improve comment
>  - Spelling

Thanks!

-------------

Marked as reviewed by mdoerr (Reviewer).

PR: https://git.openjdk.org/jdk/pull/12557

From iklam at openjdk.org  Thu Feb 16 06:52:27 2023
From: iklam at openjdk.org (Ioi Lam)
Date: Thu, 16 Feb 2023 06:52:27 GMT
Subject: RFR: 8292914: Drop the counter from lambda class names [v4]
In-Reply-To: <NtA7-4LZQtr2JwdCmWgzHP9I-eV6k2bWRRxHcH6ENMo=.72d26ca4-cda5-481d-92d1-59265044f030@github.com>
References: <GgLfH-ueBQqT-Mfk1mKpKFAt8fYqyjfVJ9lmlsBsCbo=.8dd5b3b4-4e84-4970-9179-1c0399b30edc@github.com>
 <NtA7-4LZQtr2JwdCmWgzHP9I-eV6k2bWRRxHcH6ENMo=.72d26ca4-cda5-481d-92d1-59265044f030@github.com>
Message-ID: <36KRRGjVKDrf83i_S_S4oYgHR9g8h9sXs90pLJ5Gp28=.533e1620-680a-44cd-b466-b31ccf1d3958@github.com>

On Thu, 16 Feb 2023 01:42:16 GMT, David M. Lloyd <duke at openjdk.org> wrote:

>> The class generated for lambda proxies is now defined as a hidden class. This means that the counter, which was used to ensure a unique class name and avoid clashes, is now redundant. In addition to performing redundant work, this also impacts build reproducibility for native image generators which might already have a strategy to cope with hidden classes but cannot cope with indeterminate definition order for lambda proxy classes.
>> 
>> This solves JDK-8292914 by making lambda proxy names always be stable without any configuration needed. This would also replace #10024.
>
> David M. Lloyd has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Fix LambdaAsm test
>  - Fix stack walker test

For debugging, the `-Djava.lang.invoke.MethodHandle.DUMP_CLASS_FILES=true`  property addes a unique suffix to the generated `LambdaForm$MH` classes.

https://github.com/openjdk/jdk/blob/1480d418e3b7d1f36ace24a043a273fca446eefa/src/java.base/share/classes/java/lang/invoke/InvokerBytecodeGenerator.java#L128-L130

So for Lambda proxy classes, instead of inventing a new way of unique class names, perhaps we can use the existing AtomicInteger counter only when `-Djdk.internal.lambda.dumpProxyClasses=` is specified?

-------------

PR: https://git.openjdk.org/jdk/pull/12579

From asotona at openjdk.org  Thu Feb 16 09:42:43 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Thu, 16 Feb 2023 09:42:43 GMT
Subject: RFR: 8294982: Implementation of Classfile API [v15]
In-Reply-To: <6gCIlUafIspeaYjIs6AlFuRqJtUsuOqjKOSDBs8kYV4=.14b51d52-5b74-4918-a3ab-a7fda35a723b@github.com>
References: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
 <hr8eti6ytvV05JFRr5hYLWy7yBla9mpI8vKKfaaFR-k=.a92f7bea-6400-4f95-a40c-d57192013f19@github.com>
 <hUvPqC4427nX8mcEcC5Tr90RFXAtmNigTxexY_Ujf04=.55b5e41d-afa7-4220-b13f-6fb0dd25dd0e@github.com>
 <6gCIlUafIspeaYjIs6AlFuRqJtUsuOqjKOSDBs8kYV4=.14b51d52-5b74-4918-a3ab-a7fda35a723b@github.com>
Message-ID: <EWWS88WJjgidmXnYYHv-wKa-U1ufSPKcDvJT8hMyxI8=.40faf7c6-daa7-44cf-9d07-f1bcceb4131b@github.com>

On Fri, 10 Feb 2023 11:16:22 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/classfile/constantpool/Utf8Entry.java line 47:
>> 
>>> 45:      * @param s the string to compare to
>>> 46:      */
>>> 47:     boolean equalsString(String s);
>> 
>> Whatif the provided string contains character that are not representable in Utf8? Should we throw (e.g. `IllegalArgumentException`) ?
>
> I would rather expect `false` value returned, however this case is probably not covered by tests.

You almost got me, I had to think about it for a while :) 
Any String is always representable in Utf8 (or modified Utf8 used in classfile).
It is completely valid to store even 4-byte Unicode characters in Utf8Entry and match them with (Utf16 encoded) String. I'll add such String to the existing test.

-------------

PR: https://git.openjdk.org/jdk/pull/10982

From mcimadamore at openjdk.org  Thu Feb 16 10:27:44 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 16 Feb 2023 10:27:44 GMT
Subject: RFR: 8294982: Implementation of Classfile API [v15]
In-Reply-To: <WjPpEjQMu0JRMC50Ah6GbGziijbdSSS_EUGbSJ_gH2I=.bafee453-7bfc-444d-93eb-8d3b9258a2fd@github.com>
References: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
 <hr8eti6ytvV05JFRr5hYLWy7yBla9mpI8vKKfaaFR-k=.a92f7bea-6400-4f95-a40c-d57192013f19@github.com>
 <hUvPqC4427nX8mcEcC5Tr90RFXAtmNigTxexY_Ujf04=.55b5e41d-afa7-4220-b13f-6fb0dd25dd0e@github.com>
 <WjPpEjQMu0JRMC50Ah6GbGziijbdSSS_EUGbSJ_gH2I=.bafee453-7bfc-444d-93eb-8d3b9258a2fd@github.com>
Message-ID: <CXD_fqRhrtJW65rK0-TQaDVNIS3EGBXMZIQgKFrkQv0=.4d4b2608-ce7e-407b-9d88-2f4e9654e672@github.com>

On Wed, 15 Feb 2023 08:20:19 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/classfile/constantpool/ConstantPoolBuilder.java line 537:
>> 
>>> 535:      * @param <T> the type of the entry
>>> 536:      */
>>> 537:     <T extends PoolEntry> T maybeClone(T entry);
>> 
>> This feels a more primitive operation than the name suggests. Have you considered making ConstantPool extend Consumer<PoolEntry> and call this "accept" ?
>
> I'm not quite sure what exactly do you propose.
> `ConstantPool` should not accept anything as it is read-only, so "accept" would be confusing.
> `ConstantPoolBuilder::maybeClone` is rather a `Function`, where the name might be changed to `ConstantPoolBuilder::apply`.
> However there are so many "accepts" and "applies" across the API, that reducing API verbosity to just these functional terms might significantly decrease readability.

As I read the javadoc (I have not looked at impl yet), this method can effectively be used to add an entry to the constant pool (if the entry does not yet exist - in which case existing entry is returned).

After having looked at the implementation a bit, I think my assumption is correct - e.g. when calling `getfield` on a code builder, the FieldRef passed to the code builder is added to the constant pool using `maybeClone`.

So, in my mind at least, this `maybeClone` is the main avenue by which new constant pool entries are added. In builders we have a `with` method - I think a `with` method would also be ok here, given what the method does (ok, there is the wrinkle that, if the entry already exists it is not added, but that seems more of an optimization to avoid duplicates).

-------------

PR: https://git.openjdk.org/jdk/pull/10982

From asotona at openjdk.org  Thu Feb 16 10:41:33 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Thu, 16 Feb 2023 10:41:33 GMT
Subject: RFR: 8294982: Implementation of Classfile API [v20]
In-Reply-To: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
References: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
Message-ID: <Gluemo5fFOPx_G6KtSgHxWEmiv3FFSTlxRHtc6ZPTuc=.6a2b6930-c7fd-4734-b21b-d2ccec1dabcf@github.com>

> This is root pull request with Classfile API implementation, tests and benchmarks initial drop into JDK.
> 
> Following pull requests consolidating JDK class files parsing, generating, and transforming ([JDK-8294957](https://bugs.openjdk.org/browse/JDK-8294957)) will chain to this one.
> 
> Classfile API development is tracked at:
> https://github.com/openjdk/jdk-sandbox/tree/classfile-api-branch
> 
> Development branch of consolidated JDK class files parsing, generating, and transforming is at:
> https://github.com/openjdk/jdk-sandbox/tree/classfile-api-dev-branch
> 
> Classfile API [JEP](https://bugs.openjdk.org/browse/JDK-8280389) and [online API documentation](https://htmlpreview.github.io/?https://raw.githubusercontent.com/openjdk/jdk-sandbox/classfile-api-javadoc-branch/doc/classfile-api/javadoc/java.base/jdk/internal/classfile/package-summary.html) is also available.
> 
> Please take you time to review this non-trivial JDK addition.
> 
> Thank you,
> Adam

Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:

  added 4-byte Unicode text to Utf8EntryTest

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10982/files
  - new: https://git.openjdk.org/jdk/pull/10982/files/dbb9e46a..7a45ebd3

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10982&range=19
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10982&range=18-19

  Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/10982.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10982/head:pull/10982

PR: https://git.openjdk.org/jdk/pull/10982

From asotona at openjdk.org  Thu Feb 16 10:51:42 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Thu, 16 Feb 2023 10:51:42 GMT
Subject: RFR: 8294982: Implementation of Classfile API [v15]
In-Reply-To: <CXD_fqRhrtJW65rK0-TQaDVNIS3EGBXMZIQgKFrkQv0=.4d4b2608-ce7e-407b-9d88-2f4e9654e672@github.com>
References: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
 <hr8eti6ytvV05JFRr5hYLWy7yBla9mpI8vKKfaaFR-k=.a92f7bea-6400-4f95-a40c-d57192013f19@github.com>
 <hUvPqC4427nX8mcEcC5Tr90RFXAtmNigTxexY_Ujf04=.55b5e41d-afa7-4220-b13f-6fb0dd25dd0e@github.com>
 <WjPpEjQMu0JRMC50Ah6GbGziijbdSSS_EUGbSJ_gH2I=.bafee453-7bfc-444d-93eb-8d3b9258a2fd@github.com>
 <CXD_fqRhrtJW65rK0-TQaDVNIS3EGBXMZIQgKFrkQv0=.4d4b2608-ce7e-407b-9d88-2f4e9654e672@github.com>
Message-ID: <3HZ_jmmtzk1RUgiUGwGudTaqvzEbFkla14T4EDKSjxU=.1fd22057-627c-42df-80a1-1c7c37486c4c@github.com>

On Thu, 16 Feb 2023 10:25:04 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> I'm not quite sure what exactly do you propose.
>> `ConstantPool` should not accept anything as it is read-only, so "accept" would be confusing.
>> `ConstantPoolBuilder::maybeClone` is rather a `Function`, where the name might be changed to `ConstantPoolBuilder::apply`.
>> However there are so many "accepts" and "applies" across the API, that reducing API verbosity to just these functional terms might significantly decrease readability.
>
> As I read the javadoc (I have not looked at impl yet), this method can effectively be used to add an entry to the constant pool (if the entry does not yet exist - in which case existing entry is returned).
> 
> After having looked at the implementation a bit, I think my assumption is correct - e.g. when calling `getfield` on a code builder, the FieldRef passed to the code builder is added to the constant pool using `maybeClone`.
> 
> So, in my mind at least, this `maybeClone` is the main avenue by which new constant pool entries are added. In builders we have a `with` method - I think a `with` method would also be ok here, given what the method does (ok, there is the wrinkle that, if the entry already exists it is not added, but that seems more of an optimization to avoid duplicates).

The main difference is that if the given entry is not directly applicable (when it comes from 3rd constant pool or when the pool is not shared during transformation) - a new or matching entry to the target pool is returned.
This is not a builder pattern, this is projection of an entry to the target CP and it also prevents duplicates.

-------------

PR: https://git.openjdk.org/jdk/pull/10982

From asotona at openjdk.org  Thu Feb 16 10:51:42 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Thu, 16 Feb 2023 10:51:42 GMT
Subject: RFR: 8294982: Implementation of Classfile API [v15]
In-Reply-To: <3HZ_jmmtzk1RUgiUGwGudTaqvzEbFkla14T4EDKSjxU=.1fd22057-627c-42df-80a1-1c7c37486c4c@github.com>
References: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
 <hr8eti6ytvV05JFRr5hYLWy7yBla9mpI8vKKfaaFR-k=.a92f7bea-6400-4f95-a40c-d57192013f19@github.com>
 <hUvPqC4427nX8mcEcC5Tr90RFXAtmNigTxexY_Ujf04=.55b5e41d-afa7-4220-b13f-6fb0dd25dd0e@github.com>
 <WjPpEjQMu0JRMC50Ah6GbGziijbdSSS_EUGbSJ_gH2I=.bafee453-7bfc-444d-93eb-8d3b9258a2fd@github.com>
 <CXD_fqRhrtJW65rK0-TQaDVNIS3EGBXMZIQgKFrkQv0=.4d4b2608-ce7e-407b-9d88-2f4e9654e672@github.com>
 <3HZ_jmmtzk1RUgiUGwGudTaqvzEbFkla14T4EDKSjxU=.1fd22057-627c-42df-80a1-1c7c37486c4c@github.com>
Message-ID: <AJgsunTEzUuzgdTQKiSBTXDrhs5_MmqNZWnSURk61AE=.b8e71cb6-1ccb-49f3-afda-d2a98f4ec701@github.com>

On Thu, 16 Feb 2023 10:46:23 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> As I read the javadoc (I have not looked at impl yet), this method can effectively be used to add an entry to the constant pool (if the entry does not yet exist - in which case existing entry is returned).
>> 
>> After having looked at the implementation a bit, I think my assumption is correct - e.g. when calling `getfield` on a code builder, the FieldRef passed to the code builder is added to the constant pool using `maybeClone`.
>> 
>> So, in my mind at least, this `maybeClone` is the main avenue by which new constant pool entries are added. In builders we have a `with` method - I think a `with` method would also be ok here, given what the method does (ok, there is the wrinkle that, if the entry already exists it is not added, but that seems more of an optimization to avoid duplicates).
>
> The main difference is that if the given entry is not directly applicable (when it comes from 3rd constant pool or when the pool is not shared during transformation) - a new or matching entry to the target pool is returned.
> This is not a builder pattern, this is projection of an entry to the target CP and it also prevents duplicates.

`maybeClone` is not the main avenue, it is rather a helper method and I'll look at details if it is necessary too expose it.

-------------

PR: https://git.openjdk.org/jdk/pull/10982

From mcimadamore at openjdk.org  Thu Feb 16 11:38:57 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 16 Feb 2023 11:38:57 GMT
Subject: RFR: 8294982: Implementation of Classfile API [v20]
In-Reply-To: <Gluemo5fFOPx_G6KtSgHxWEmiv3FFSTlxRHtc6ZPTuc=.6a2b6930-c7fd-4734-b21b-d2ccec1dabcf@github.com>
References: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
 <Gluemo5fFOPx_G6KtSgHxWEmiv3FFSTlxRHtc6ZPTuc=.6a2b6930-c7fd-4734-b21b-d2ccec1dabcf@github.com>
Message-ID: <Qn0tRwNM_VFrkCYp8klyMMUJRCUoB0muZ9E-UkUK8R4=.12a8c8b2-48cc-4ffe-b11e-0180c60bd4bf@github.com>

On Thu, 16 Feb 2023 10:41:33 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> This is root pull request with Classfile API implementation, tests and benchmarks initial drop into JDK.
>> 
>> Following pull requests consolidating JDK class files parsing, generating, and transforming ([JDK-8294957](https://bugs.openjdk.org/browse/JDK-8294957)) will chain to this one.
>> 
>> Classfile API development is tracked at:
>> https://github.com/openjdk/jdk-sandbox/tree/classfile-api-branch
>> 
>> Development branch of consolidated JDK class files parsing, generating, and transforming is at:
>> https://github.com/openjdk/jdk-sandbox/tree/classfile-api-dev-branch
>> 
>> Classfile API [JEP](https://bugs.openjdk.org/browse/JDK-8280389) and [online API documentation](https://htmlpreview.github.io/?https://raw.githubusercontent.com/openjdk/jdk-sandbox/classfile-api-javadoc-branch/doc/classfile-api/javadoc/java.base/jdk/internal/classfile/package-summary.html) is also available.
>> 
>> Please take you time to review this non-trivial JDK addition.
>> 
>> Thank you,
>> Adam
>
> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
> 
>   added 4-byte Unicode text to Utf8EntryTest

src/java.base/share/classes/jdk/internal/classfile/components/ClassPrinter.java line 93:

> 91:          * @return name of the node
> 92:          */
> 93:         public ConstantDesc name();

Not sure about the ConstantDesc here. Why is it better than String?

src/java.base/share/classes/jdk/internal/classfile/components/ClassPrinter.java line 105:

> 103:          * @param out consumer of the printed fragments
> 104:          */
> 105:         default public void toJson(Consumer<String> out) {

there are some `public` modifiers here which can be omitted

src/java.base/share/classes/jdk/internal/classfile/components/ClassPrinter.java line 140:

> 138: 
> 139:     /**
> 140:      * A tree node holding {@link List} of nested nodes.

It would perhaps be beneficial to have little examples of what these different nodes are used for. I had to look at `ClassPrinterImpl` to get some idea.

src/java.base/share/classes/jdk/internal/classfile/components/ClassRemapper.java line 93:

> 91: 
> 92: /**
> 93:  * ClassRemapper is a {@link jdk.internal.classfile.ClassTransform}, {@link jdk.internal.classfile.FieldTransform},

Maybe wrap occurrences of `ClassRemapper` with `{@code}` (here and elsewhere)

src/java.base/share/classes/jdk/internal/classfile/components/ClassRemapper.java line 168:

> 166:         public void accept(ClassBuilder clb, ClassElement cle) {
> 167:             switch (cle) {
> 168:                 case FieldModel fm ->

What about NestMembers, NestHost, PermittedSubclasses (and probably others) ?

src/java.base/share/classes/jdk/internal/classfile/components/ClassRemapper.java line 306:

> 304: 
> 305:         ClassSignature mapClassSignature(ClassSignature signature) {
> 306:             return ClassSignature.of(signature.typeParameters(),

Should type parameters also be mapped? (as they might have class bounds). Both here and in `mapMethodSignature`.

src/java.base/share/classes/jdk/internal/classfile/components/CodeLocalsShifter.java line 43:

> 41: 
> 42: /**
> 43:  * CodeLocalsShifter is a {@link jdk.internal.classfile.CodeTransform} shifting locals to

Missing `{@code}` (here and elsewhere)

src/java.base/share/classes/jdk/internal/classfile/components/CodeRelabeler.java line 43:

> 41: 
> 42: /**
> 43:  * CodeRelabeler is a {@link jdk.internal.classfile.CodeTransform} replacing all occurences

Suggestion:

 * CodeRelabeler is a {@link jdk.internal.classfile.CodeTransform} replacing all occurrences

src/java.base/share/classes/jdk/internal/classfile/components/CodeStackTracker.java line 43:

> 41: 
> 42: /**
> 43:  * CodeStackTracker is a {@link jdk.internal.classfile.CodeTransform} synchronously tracking

Not sure what is meant by `synchronously`

src/java.base/share/classes/jdk/internal/classfile/components/CodeStackTracker.java line 53:

> 51:  *         trackedBuilder.aload(0);
> 52:  *         trackedBuilder.lconst_0();
> 53:  *         trackedBuilder.ifThen(...

missing closed parens?

src/java.base/share/classes/jdk/internal/classfile/components/CodeStackTracker.java line 77:

> 75:       *
> 76:       * Temporary unknown stack content can be recovered by binding of a {@linkplain Label} used as
> 77:       * target of a branch instruction from existing code with known Stack (forward branch target),

Suggestion:

      * target of a branch instruction from existing code with known stack (forward branch target),

src/java.base/share/classes/jdk/internal/classfile/components/CodeStackTracker.java line 86:

> 84:     /**
> 85:       * Returns tracked max stack size.
> 86:       * Returns an empty {@linkplain Optional} when Max stack size tracking has been lost.

Suggestion:

      * Returns an empty {@linkplain Optional} when max stack size tracking has been lost.

src/java.base/share/classes/jdk/internal/classfile/components/package-info.java line 97:

> 95:  * {@snippet lang="java" class="PackageSnippets" region="classInstrumentation"}
> 96:  */
> 97: package jdk.internal.classfile.components;

watch out for newline

src/java.base/share/classes/jdk/internal/classfile/impl/ClassPrinterImpl.java line 563:

> 561:                       list("attributes", "attribute", clm.attributes().stream().map(Attribute::attributeName)))
> 562:                 .with(constantPoolToTree(clm.constantPool(), verbosity))
> 563:                 .with(attributesToTree(clm.attributes(), verbosity))

Is this ok? It seems we also add class attributes in the map node (see "attributes" map node).

src/java.base/share/classes/jdk/internal/classfile/impl/ClassPrinterImpl.java line 745:

> 743:                     list("stack", "item", Stream.of())));
> 744:             }
> 745:             var excHandlers = com.exceptionHandlers().stream().map(exc -> new ExceptionHandler(com.labelToBci(exc.tryStart()), com.labelToBci(exc.tryEnd()), com.labelToBci(exc.handler()), exc.catchType().map(ct -> ct.name().stringValue()).orElse(null))).toList();

Watch out for very long lines

-------------

PR: https://git.openjdk.org/jdk/pull/10982

From mcimadamore at openjdk.org  Thu Feb 16 11:38:58 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 16 Feb 2023 11:38:58 GMT
Subject: RFR: 8294982: Implementation of Classfile API [v20]
In-Reply-To: <Qn0tRwNM_VFrkCYp8klyMMUJRCUoB0muZ9E-UkUK8R4=.12a8c8b2-48cc-4ffe-b11e-0180c60bd4bf@github.com>
References: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
 <Gluemo5fFOPx_G6KtSgHxWEmiv3FFSTlxRHtc6ZPTuc=.6a2b6930-c7fd-4734-b21b-d2ccec1dabcf@github.com>
 <Qn0tRwNM_VFrkCYp8klyMMUJRCUoB0muZ9E-UkUK8R4=.12a8c8b2-48cc-4ffe-b11e-0180c60bd4bf@github.com>
Message-ID: <oYaLdiYyDVuK_MQipb_p3HpgH_p6xBZByVeG33jPYps=.2282798d-f696-4139-88a5-bbf0f3274ac5@github.com>

On Thu, 16 Feb 2023 11:27:18 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   added 4-byte Unicode text to Utf8EntryTest
>
> src/java.base/share/classes/jdk/internal/classfile/components/CodeRelabeler.java line 43:
> 
>> 41: 
>> 42: /**
>> 43:  * CodeRelabeler is a {@link jdk.internal.classfile.CodeTransform} replacing all occurences
> 
> Suggestion:
> 
>  * CodeRelabeler is a {@link jdk.internal.classfile.CodeTransform} replacing all occurrences

Might want to use `{@code}` (here and elsewhere)

> src/java.base/share/classes/jdk/internal/classfile/components/CodeStackTracker.java line 43:
> 
>> 41: 
>> 42: /**
>> 43:  * CodeStackTracker is a {@link jdk.internal.classfile.CodeTransform} synchronously tracking
> 
> Not sure what is meant by `synchronously`

Might want to use `{@code}` (here and elsewhere)

-------------

PR: https://git.openjdk.org/jdk/pull/10982

From duke at openjdk.org  Thu Feb 16 12:18:44 2023
From: duke at openjdk.org (Jens Lidestrom)
Date: Thu, 16 Feb 2023 12:18:44 GMT
Subject: RFR: 8294982: Implementation of Classfile API [v20]
In-Reply-To: <Gluemo5fFOPx_G6KtSgHxWEmiv3FFSTlxRHtc6ZPTuc=.6a2b6930-c7fd-4734-b21b-d2ccec1dabcf@github.com>
References: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
 <Gluemo5fFOPx_G6KtSgHxWEmiv3FFSTlxRHtc6ZPTuc=.6a2b6930-c7fd-4734-b21b-d2ccec1dabcf@github.com>
Message-ID: <XdPsRS7sN9MC3gcIyTcIN3BhhfrgSjSZYnq1jC_pqc0=.aad91048-53be-4f19-a7fd-ed4e41ad5deb@github.com>

On Thu, 16 Feb 2023 10:41:33 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> This is root pull request with Classfile API implementation, tests and benchmarks initial drop into JDK.
>> 
>> Following pull requests consolidating JDK class files parsing, generating, and transforming ([JDK-8294957](https://bugs.openjdk.org/browse/JDK-8294957)) will chain to this one.
>> 
>> Classfile API development is tracked at:
>> https://github.com/openjdk/jdk-sandbox/tree/classfile-api-branch
>> 
>> Development branch of consolidated JDK class files parsing, generating, and transforming is at:
>> https://github.com/openjdk/jdk-sandbox/tree/classfile-api-dev-branch
>> 
>> Classfile API [JEP](https://bugs.openjdk.org/browse/JDK-8280389) and [online API documentation](https://htmlpreview.github.io/?https://raw.githubusercontent.com/openjdk/jdk-sandbox/classfile-api-javadoc-branch/doc/classfile-api/javadoc/java.base/jdk/internal/classfile/package-summary.html) is also available.
>> 
>> Please take you time to review this non-trivial JDK addition.
>> 
>> Thank you,
>> Adam
>
> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
> 
>   added 4-byte Unicode text to Utf8EntryTest

src/java.base/share/classes/jdk/internal/classfile/constantpool/ConstantPoolBuilder.java line 96:

> 94:      * @param <T> the type of the option value
> 95:      */
> 96:     <T> T optionValue(Classfile.Option.Key option);

This unconstrained type parameter will result in and implicit conversion to any type that the caller assigns it to, which might result in a `ClassCastException` if the caller gets the type wrong.

Is that intentional?

Alternative solutions: 

* Convert `Key` to an ordinary class or sealed interface, and add a type parameter to it, for the value type.
* Add a parameter the the method of type `Class<T>`.

-------------

PR: https://git.openjdk.org/jdk/pull/10982

From duke at openjdk.org  Thu Feb 16 12:44:27 2023
From: duke at openjdk.org (David M. Lloyd)
Date: Thu, 16 Feb 2023 12:44:27 GMT
Subject: RFR: 8292914: Drop the counter from lambda class names [v4]
In-Reply-To: <NtA7-4LZQtr2JwdCmWgzHP9I-eV6k2bWRRxHcH6ENMo=.72d26ca4-cda5-481d-92d1-59265044f030@github.com>
References: <GgLfH-ueBQqT-Mfk1mKpKFAt8fYqyjfVJ9lmlsBsCbo=.8dd5b3b4-4e84-4970-9179-1c0399b30edc@github.com>
 <NtA7-4LZQtr2JwdCmWgzHP9I-eV6k2bWRRxHcH6ENMo=.72d26ca4-cda5-481d-92d1-59265044f030@github.com>
Message-ID: <QDDNRz5hAZBvFnIc01wMCPtZ7DvBERUJl5GaTbWBreg=.d44c1781-d8c7-4365-9b9b-ebdabf87b5ac@github.com>

On Thu, 16 Feb 2023 01:42:16 GMT, David M. Lloyd <duke at openjdk.org> wrote:

>> The class generated for lambda proxies is now defined as a hidden class. This means that the counter, which was used to ensure a unique class name and avoid clashes, is now redundant. In addition to performing redundant work, this also impacts build reproducibility for native image generators which might already have a strategy to cope with hidden classes but cannot cope with indeterminate definition order for lambda proxy classes.
>> 
>> This solves JDK-8292914 by making lambda proxy names always be stable without any configuration needed. This would also replace #10024.
>
> David M. Lloyd has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Fix LambdaAsm test
>  - Fix stack walker test

I definitely don't like that there is a map... maybe it'd be better to change the MH dumper to use the time stamp scheme instead? (In a separate change?)

-------------

PR: https://git.openjdk.org/jdk/pull/12579

From mcimadamore at openjdk.org  Thu Feb 16 12:58:54 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 16 Feb 2023 12:58:54 GMT
Subject: RFR: 8294982: Implementation of Classfile API [v20]
In-Reply-To: <Gluemo5fFOPx_G6KtSgHxWEmiv3FFSTlxRHtc6ZPTuc=.6a2b6930-c7fd-4734-b21b-d2ccec1dabcf@github.com>
References: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
 <Gluemo5fFOPx_G6KtSgHxWEmiv3FFSTlxRHtc6ZPTuc=.6a2b6930-c7fd-4734-b21b-d2ccec1dabcf@github.com>
Message-ID: <K6w7vBBPpKz30feZIbgFNfjMhIFfle8RT87XgCYyCjw=.1fc7973b-529e-482d-a459-ac02b66e9901@github.com>

On Thu, 16 Feb 2023 10:41:33 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> This is root pull request with Classfile API implementation, tests and benchmarks initial drop into JDK.
>> 
>> Following pull requests consolidating JDK class files parsing, generating, and transforming ([JDK-8294957](https://bugs.openjdk.org/browse/JDK-8294957)) will chain to this one.
>> 
>> Classfile API development is tracked at:
>> https://github.com/openjdk/jdk-sandbox/tree/classfile-api-branch
>> 
>> Development branch of consolidated JDK class files parsing, generating, and transforming is at:
>> https://github.com/openjdk/jdk-sandbox/tree/classfile-api-dev-branch
>> 
>> Classfile API [JEP](https://bugs.openjdk.org/browse/JDK-8280389) and [online API documentation](https://htmlpreview.github.io/?https://raw.githubusercontent.com/openjdk/jdk-sandbox/classfile-api-javadoc-branch/doc/classfile-api/javadoc/java.base/jdk/internal/classfile/package-summary.html) is also available.
>> 
>> Please take you time to review this non-trivial JDK addition.
>> 
>> Thank you,
>> Adam
>
> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
> 
>   added 4-byte Unicode text to Utf8EntryTest

src/java.base/share/classes/jdk/internal/classfile/impl/BoundAttribute.java line 49:

> 47:  * BoundAttribute
> 48:  */
> 49: public abstract sealed class BoundAttribute<T extends Attribute<T>>

Understanding checkpoint: there are two variant of most of the elements: an *unbound* form and a *bound* form. The former is what you get by constructing the element from scratch using a factory. The latter is what you get when the element is read from the classfile.

Since bound elements have a reference to real "bytes" in some classfile, this distinction allows the implementation to speed up the writing of the element contents to the class buffer - that is, writing an unbound element goes through a "slow path" which involves constant pool entry creation, etc. For bound elements, we can, at least in some cases (e.g. when the builder supports direct writing) just copy the underlying bytes to the target buffer.

src/java.base/share/classes/jdk/internal/classfile/impl/EntryMap.java line 30:

> 28:  * An open-chain multimap used to map nonzero hashes to indexes (of either CP
> 29:  * elements or BSM entries).  Code transformed from public domain implementation
> 30:  * (http://java-performance.info/implementing-world-fastest-java-int-to-int-hash-map/).

Could not open this link - seems to redirect to main page

src/java.base/share/classes/jdk/internal/classfile/impl/EntryMap.java line 192:

> 190:         return (int)s;
> 191:     }
> 192: }

Watch for newlines

src/java.base/share/classes/jdk/internal/classfile/impl/SplitConstantPool.java line 83:

> 81:  * ConstantPool.
> 82:  */
> 83: public final class SplitConstantPool implements ConstantPoolBuilder {

Not sure the "Split" prefix carries any meaning? (perhaps a leftover from previous iterations?)

src/java.base/share/classes/jdk/internal/classfile/impl/SplitConstantPool.java line 217:

> 215:                 }
> 216:             };
> 217:             // Doing a full scan here yields fall-off-the-cliff performance results,

Understanding checkpoint: the parent is a class reader, which holds some class bytes. The class reader is set up in a way that constant pool entries are read "on-demand" - that is, if I ask the class reader "give me CP entry 42", the classreader will only build that entry (assuming 42 is a valid index) and give me back that entry. Also, the class reader will save the read constant in an internal array, to avoid re-reading the classfile bytes multiple times.

So, what this code here does is: when we create an entry map, we populate the map with the entries from the parent reader - but we only add entries that were already looked up (e.g. we do not bother reading _all_ entries, and adding all of them to the entry map).

But, when `findEntry` is called, if we see that we can't find the entry, and we know that there might be constant pool entries from the parent reader still unread, we force a full scan of the parent reader pool and try again.

Correct?

src/java.base/share/classes/jdk/internal/classfile/impl/SplitConstantPool.java line 271:

> 269: 
> 270:     private <E extends PoolEntry> E internalAdd(E cpi, int hash) {
> 271:         int newIndex = size-parentSize;

I'm not sure I get this. The new entry is constructed with an index set to the pool size. That said, when we build the entry we don't yet know if the entry is already in the pool. The EntryMap data structure seems to have logic to detect duplicates (e.g. adding an already added entry is a no-op) - but this method seems to (a) add the CP entry to the `newEntries` array anyway and (b) happily return the entry with the index set to the pool size (which might, or might not, be the correct final index). What am I missing?

src/java.base/share/classes/jdk/internal/classfile/impl/TargetInfoImpl.java line 34:

> 32: 
> 33: /**
> 34:  *

Empty javadoc?

src/java.base/share/classes/jdk/internal/classfile/impl/TemporaryConstantPool.java line 60:

> 58:     private static final Options options = new Options(Collections.emptyList());
> 59: 
> 60:     private TemporaryConstantPool() {};

If I understand correctly, this constant pool is just "fake" in the sense that it's a builder which creates constant pool entries w/o storing them anywhere. This seems to be used in places where e.g. we need to convert a ClassDesc to a ClassEntry, probably so that the implementation of e.g. attributes can be defined in terms of constant pool entries, even when "unbounded". E.g. this is a trick which avoids having completely different representations for bound and unbound elements - correct?

-------------

PR: https://git.openjdk.org/jdk/pull/10982

From mcimadamore at openjdk.org  Thu Feb 16 12:58:56 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 16 Feb 2023 12:58:56 GMT
Subject: RFR: 8294982: Implementation of Classfile API [v20]
In-Reply-To: <K6w7vBBPpKz30feZIbgFNfjMhIFfle8RT87XgCYyCjw=.1fc7973b-529e-482d-a459-ac02b66e9901@github.com>
References: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
 <Gluemo5fFOPx_G6KtSgHxWEmiv3FFSTlxRHtc6ZPTuc=.6a2b6930-c7fd-4734-b21b-d2ccec1dabcf@github.com>
 <K6w7vBBPpKz30feZIbgFNfjMhIFfle8RT87XgCYyCjw=.1fc7973b-529e-482d-a459-ac02b66e9901@github.com>
Message-ID: <pcDodfQdDJtkKPXj0UcDAk4qWFbMvUuYLomzuvJor1E=.9fe5504c-ee1c-41a1-822b-2b1244699bf7@github.com>

On Thu, 16 Feb 2023 12:46:09 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   added 4-byte Unicode text to Utf8EntryTest
>
> src/java.base/share/classes/jdk/internal/classfile/impl/SplitConstantPool.java line 271:
> 
>> 269: 
>> 270:     private <E extends PoolEntry> E internalAdd(E cpi, int hash) {
>> 271:         int newIndex = size-parentSize;
> 
> I'm not sure I get this. The new entry is constructed with an index set to the pool size. That said, when we build the entry we don't yet know if the entry is already in the pool. The EntryMap data structure seems to have logic to detect duplicates (e.g. adding an already added entry is a no-op) - but this method seems to (a) add the CP entry to the `newEntries` array anyway and (b) happily return the entry with the index set to the pool size (which might, or might not, be the correct final index). What am I missing?

Nevermind - this method is only called if the entry is not found (using `findEntry`) :-)

-------------

PR: https://git.openjdk.org/jdk/pull/10982

From duke at openjdk.org  Thu Feb 16 14:06:54 2023
From: duke at openjdk.org (David M. Lloyd)
Date: Thu, 16 Feb 2023 14:06:54 GMT
Subject: RFR: 8292914: Drop the counter from lambda class names [v5]
In-Reply-To: <GgLfH-ueBQqT-Mfk1mKpKFAt8fYqyjfVJ9lmlsBsCbo=.8dd5b3b4-4e84-4970-9179-1c0399b30edc@github.com>
References: <GgLfH-ueBQqT-Mfk1mKpKFAt8fYqyjfVJ9lmlsBsCbo=.8dd5b3b4-4e84-4970-9179-1c0399b30edc@github.com>
Message-ID: <ug5D-IcPm0nTq7aJbugu8IiRgNutvihiUagxsDRFFKs=.4697dfe0-bbab-401d-91e7-2ec84eecce97@github.com>

> The class generated for lambda proxies is now defined as a hidden class. This means that the counter, which was used to ensure a unique class name and avoid clashes, is now redundant. In addition to performing redundant work, this also impacts build reproducibility for native image generators which might already have a strategy to cope with hidden classes but cannot cope with indeterminate definition order for lambda proxy classes.
> 
> This solves JDK-8292914 by making lambda proxy names always be stable without any configuration needed. This would also replace #10024.

David M. Lloyd has updated the pull request incrementally with one additional commit since the last revision:

  Use `Instant.now()` for more precise timestamps.
  
  Using `currentTimeMillis` is imprecise enough that tests may sporadically fail if two lambda classes from the same lambda class are dumped within 1ms of one another. `Instant.now()` is much more precise and also sorts nicely.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12579/files
  - new: https://git.openjdk.org/jdk/pull/12579/files/d56b77a2..c73442b2

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12579&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12579&range=03-04

  Stats: 3 lines in 1 file changed: 1 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/12579.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12579/head:pull/12579

PR: https://git.openjdk.org/jdk/pull/12579

From duke at openjdk.org  Thu Feb 16 14:45:13 2023
From: duke at openjdk.org (Rich DiCroce)
Date: Thu, 16 Feb 2023 14:45:13 GMT
Subject: RFR: 8302659: Modernize Windows native code for NetworkInterface
Message-ID: <44bJpV9Ik-SpmLh9RQ-fw4ctucRghAQKkO8nPPO3-eY=.e7054dc8-a959-47dd-a3b7-8764730e59d7@github.com>

Improves performance and correctness, as discussed on the net-dev mailing list.

-------------

Commit messages:
 - Fix whitespace issues
 - Remove executable bit from NetworkInterface.c
 - Rewrite Windows native code for NetworkInterface to improve performance and correctness

Changes: https://git.openjdk.org/jdk/pull/12593/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12593&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8302659
  Stats: 2347 lines in 5 files changed: 302 ins; 1803 del; 242 mod
  Patch: https://git.openjdk.org/jdk/pull/12593.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12593/head:pull/12593

PR: https://git.openjdk.org/jdk/pull/12593

From dfuchs at openjdk.org  Thu Feb 16 14:45:13 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 16 Feb 2023 14:45:13 GMT
Subject: RFR: 8302659: Modernize Windows native code for NetworkInterface
In-Reply-To: <44bJpV9Ik-SpmLh9RQ-fw4ctucRghAQKkO8nPPO3-eY=.e7054dc8-a959-47dd-a3b7-8764730e59d7@github.com>
References: <44bJpV9Ik-SpmLh9RQ-fw4ctucRghAQKkO8nPPO3-eY=.e7054dc8-a959-47dd-a3b7-8764730e59d7@github.com>
Message-ID: <22xuSAye4wy4y4o4P8M87xa4-3zuFUclmsdB-RiJ-zI=.10ef14d4-a536-47c3-91f6-d43456a63b65@github.com>

On Thu, 16 Feb 2023 14:32:15 GMT, Rich DiCroce <duke at openjdk.org> wrote:

> Improves performance and correctness, as discussed on the net-dev mailing list.

FWIW - there is a perl script located in `make/scripts/normalizer.pl` that can be run on modified sources to fix up whitespace  and CRLF issues when jcheck complains.

-------------

PR: https://git.openjdk.org/jdk/pull/12593

From duke at openjdk.org  Thu Feb 16 14:51:14 2023
From: duke at openjdk.org (Viktor Klang)
Date: Thu, 16 Feb 2023 14:51:14 GMT
Subject: RFR: JDK-8302666: Replace CHM with VarHandle in ForeachOrderedTask
Message-ID: <HAgE8xmpZT_2-b5ZDr8TgJNgjhVb3D4ZS3sQqA7c6Mo=.389fa590-681c-44a9-9823-8f70a6129797@github.com>

I noticed when looking at the code that there was no real need to use a CHM to perform the tracking of activation in an ordered fashion on ForEachOrderedTask, but instead a VarHandle can be used, reducing allocations and indirection.

-------------

Commit messages:
 - JDK-8302666: Replace CHM with VarHandle in ForeachOrderedTask

Changes: https://git.openjdk.org/jdk/pull/12320/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12320&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8302666
  Stats: 25 lines in 1 file changed: 17 ins; 5 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/12320.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12320/head:pull/12320

PR: https://git.openjdk.org/jdk/pull/12320

From mcimadamore at openjdk.org  Thu Feb 16 15:03:58 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 16 Feb 2023 15:03:58 GMT
Subject: RFR: 8294982: Implementation of Classfile API [v20]
In-Reply-To: <Gluemo5fFOPx_G6KtSgHxWEmiv3FFSTlxRHtc6ZPTuc=.6a2b6930-c7fd-4734-b21b-d2ccec1dabcf@github.com>
References: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
 <Gluemo5fFOPx_G6KtSgHxWEmiv3FFSTlxRHtc6ZPTuc=.6a2b6930-c7fd-4734-b21b-d2ccec1dabcf@github.com>
Message-ID: <01V72lRVYH7rB1NrPpkVKhvj1mksmrelMMTMrHFQ2hk=.4b2c22f3-d9c6-4778-be53-1fb055969f6a@github.com>

On Thu, 16 Feb 2023 10:41:33 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> This is root pull request with Classfile API implementation, tests and benchmarks initial drop into JDK.
>> 
>> Following pull requests consolidating JDK class files parsing, generating, and transforming ([JDK-8294957](https://bugs.openjdk.org/browse/JDK-8294957)) will chain to this one.
>> 
>> Classfile API development is tracked at:
>> https://github.com/openjdk/jdk-sandbox/tree/classfile-api-branch
>> 
>> Development branch of consolidated JDK class files parsing, generating, and transforming is at:
>> https://github.com/openjdk/jdk-sandbox/tree/classfile-api-dev-branch
>> 
>> Classfile API [JEP](https://bugs.openjdk.org/browse/JDK-8280389) and [online API documentation](https://htmlpreview.github.io/?https://raw.githubusercontent.com/openjdk/jdk-sandbox/classfile-api-javadoc-branch/doc/classfile-api/javadoc/java.base/jdk/internal/classfile/package-summary.html) is also available.
>> 
>> Please take you time to review this non-trivial JDK addition.
>> 
>> Thank you,
>> Adam
>
> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
> 
>   added 4-byte Unicode text to Utf8EntryTest

src/java.base/share/classes/jdk/internal/classfile/constantpool/ConstantPoolBuilder.java line 75:

> 73:     static ConstantPoolBuilder of(ClassModel classModel) {
> 74:         ClassReader reader = (ClassReader) classModel.constantPool();
> 75:         return reader.optionValue(Classfile.Option.Key.CP_SHARING)

Question: the fact that, when transforming, the new constant pool is the same as the old one, plus some "appended" entries at the end, is a pretty crucial property to ensure that existing code that is not transformed (e.g. unknown attributes) remains legal after transformation. But it seems that, if the `CP_SHARING` option is not passed, we build a brand new constant pool, in which case there's no guarantee that old indices will still point to the same position. Doesn't that lead to issue with unknown attributes?

I guess my question is: shouldn't the semantics properties/guarantees of a classfile transform be specified regardless of the options being passed in? E.g. it's ok if using different options ends up with different performance model, but I'm a bit worried if options can affect correctness of the transform?

src/java.base/share/classes/jdk/internal/classfile/impl/AttributeHolder.java line 38:

> 36:     private final List<Attribute<?>> attributes = new ArrayList<>();
> 37: 
> 38:     public AttributeHolder() {

default constructor

src/java.base/share/classes/jdk/internal/classfile/impl/BytecodeHelpers.java line 54:

> 52:  */
> 53: public class BytecodeHelpers {
> 54: //    public static Map<ConstantDesc, Opcode> constantsToOpcodes = new HashMap<>(16);

Should this be removed?

src/java.base/share/classes/jdk/internal/classfile/impl/BytecodeHelpers.java line 56:

> 54: //    public static Map<ConstantDesc, Opcode> constantsToOpcodes = new HashMap<>(16);
> 55: 
> 56:     public BytecodeHelpers() {

Should this also be removed (same as default constructor) ?

src/java.base/share/classes/jdk/internal/classfile/impl/ChainedFieldBuilder.java line 48:

> 46:         this.consumer = consumer;
> 47:         FieldBuilder b = downstream;
> 48:         while (b instanceof ChainedFieldBuilder cb)

I'm probably missing something - but if `b` is another chained builder, instead of using a loop, can't we just skip to its  `terminal` field? Also, the `downstream` field seems unused. (same considerations apply for `ChainedMethodBuilder` and `ChainedClassBuilder`).

I note that `NonTerminalCodeBuilder` seems to be already doing what I suggest here (e.g. skip to `terminal`).

src/java.base/share/classes/jdk/internal/classfile/impl/ConcreteEntry.java line 58:

> 56: import jdk.internal.classfile.jdktypes.PackageDesc;
> 57: 
> 58: public abstract sealed class ConcreteEntry {

Why the name `concrete` ? Am I missing something (e.g. existence of "non-concrete" pool entries?)

src/java.base/share/classes/jdk/internal/classfile/impl/DirectCodeBuilder.java line 649:

> 647:             if (parentMap == null)
> 648:                 parentMap = new IdentityHashMap<>();
> 649:             int[] table = parentMap.computeIfAbsent(parent, new Function<CodeAttribute, int[]>() {

Can use a lambda here?

src/java.base/share/classes/jdk/internal/classfile/impl/DirectCodeBuilder.java line 658:

> 656:             mruParent = parent;
> 657:             mruParentTable = table;
> 658:             return mruParentTable[lab.getContextInfo()] - 1;

Am I correct that this code can misbehave e.g. if `computeIfAbsent` ends up creating a brand new `table` array - in which case, all array elements are set to `0` - meaning we end up returning `-1`. Is that what we want?

src/java.base/share/classes/jdk/internal/classfile/impl/InstructionData.java line 47:

> 45:  * InstructionData
> 46:  */
> 47: public class InstructionData {

As CodeImpl seems to be the only client of this, I wonder if we could move the static cache in there?

src/java.base/share/classes/jdk/internal/classfile/impl/LabelImpl.java line 65:

> 63: 
> 64:     public int getContextInfo() {
> 65:         return contextInfo;

This seems to be the BCI - should we change names to reflect that? (`contextInfo` seems very vague)

src/java.base/share/classes/jdk/internal/classfile/impl/TransformImpl.java line 51:

> 49:  * TransformImpl
> 50:  */
> 51: public class TransformImpl {

Understanding check: a transform implementation is made up of two runnable (start/end handlers) and a consumer. The consumer can be used e.g. to iterate and transform all the contents of a compound element (e.g. all the instruction in a code attribute).

User-defined transforms can be "resolved" that is, we can "bind" them to a specific builder, which effectively turns them into consumers (and into a concrete transform implementation that can be used).

When two transforms T1 and T2 are composed (so that T1 runs before T2), we need to implement the `resolve` method of the resulting transform so that:
* We resolve T2 against the provided builder - this gives us a "downstream" consumer;
* We create a new "chained" builder which wraps the provided builder, and whose `with` method calls the downstream consumer;
* We then resolve T1 against the chained builder, and return the resulting consumer

This means that when we call `accept` on the resulting consumer, we will transform (using T1) and call `with` (passing the transformed element)  on the chained builder, which will end up calling `accept` on the downstream consumer, which will apply T2 and finally add the resulting element to the provided builder.

Correct? (Phew)

-------------

PR: https://git.openjdk.org/jdk/pull/10982

From pminborg at openjdk.org  Thu Feb 16 15:04:34 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 16 Feb 2023 15:04:34 GMT
Subject: RFR: JDK-8302666: Replace CHM with VarHandle in ForeachOrderedTask
In-Reply-To: <HAgE8xmpZT_2-b5ZDr8TgJNgjhVb3D4ZS3sQqA7c6Mo=.389fa590-681c-44a9-9823-8f70a6129797@github.com>
References: <HAgE8xmpZT_2-b5ZDr8TgJNgjhVb3D4ZS3sQqA7c6Mo=.389fa590-681c-44a9-9823-8f70a6129797@github.com>
Message-ID: <ibMOMTroJF84eihZpvZLXUGe3dYmhro9X5-0nV6D1q4=.1fd41eec-bc1e-432b-b297-8a0567e7f126@github.com>

On Tue, 31 Jan 2023 10:57:58 GMT, Viktor Klang <duke at openjdk.org> wrote:

> I noticed when looking at the code that there was no real need to use a CHM to perform the tracking of activation in an ordered fashion on ForEachOrderedTask, but instead a VarHandle can be used, reducing allocations and indirection.

src/java.base/share/classes/java/util/stream/ForEachOps.java line 372:

> 370:         private Node<T> node;
> 371: 
> 372:         @SuppressWarnings("unused") private volatile ForEachOrderedTask<S, T> next; // Only accessed through the NEXT VarHandle

I think the variable can be declared without `volatile` as the operations on the `VarHandle` will determine the memory semantics used regardless? So, the `NEXT.set()` at L431 might also be replaced with `NEXT.setVolatile()`

-------------

PR: https://git.openjdk.org/jdk/pull/12320

From jwaters at openjdk.org  Thu Feb 16 15:10:12 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Thu, 16 Feb 2023 15:10:12 GMT
Subject: RFR: 8302667: Improve message format when failing to load symbols or
 libraries
Message-ID: <tu4ol4DO1PeplhgjhkYpXLwES142ztBXsM43uQO_CNE=.bfca85a4-2323-487d-9261-964671e00bf3@github.com>

DLL_ERROR4 is a macro expanding to an error message when a failure to load a generic item (shared libraries or an exported symbol from said libraries for example) occurs. "Error: loading:" is not a very pretty message, so this small change results in "Error: Failed to load %s" instead, which looks better and also means the message makes more sense if we want to append a reason behind as well, such as "Error: Failed to load libjvm.so because xxx"

-------------

Commit messages:
 - Error: Failed to load

Changes: https://git.openjdk.org/jdk/pull/12596/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12596&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8302667
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/12596.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12596/head:pull/12596

PR: https://git.openjdk.org/jdk/pull/12596

From duke at openjdk.org  Thu Feb 16 15:19:28 2023
From: duke at openjdk.org (Viktor Klang)
Date: Thu, 16 Feb 2023 15:19:28 GMT
Subject: RFR: JDK-8302666: Replace CHM with VarHandle in ForeachOrderedTask
In-Reply-To: <ibMOMTroJF84eihZpvZLXUGe3dYmhro9X5-0nV6D1q4=.1fd41eec-bc1e-432b-b297-8a0567e7f126@github.com>
References: <HAgE8xmpZT_2-b5ZDr8TgJNgjhVb3D4ZS3sQqA7c6Mo=.389fa590-681c-44a9-9823-8f70a6129797@github.com>
 <ibMOMTroJF84eihZpvZLXUGe3dYmhro9X5-0nV6D1q4=.1fd41eec-bc1e-432b-b297-8a0567e7f126@github.com>
Message-ID: <sTSyq4-pE6IN_u2yipiLQ8cEgZ_9bitcmioGfSxfA1A=.5b2a7a20-bea3-4211-a7cd-fbed0300f707@github.com>

On Thu, 16 Feb 2023 15:01:34 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> I noticed when looking at the code that there was no real need to use a CHM to perform the tracking of activation in an ordered fashion on ForEachOrderedTask, but instead a VarHandle can be used, reducing allocations and indirection.
>
> src/java.base/share/classes/java/util/stream/ForEachOps.java line 372:
> 
>> 370:         private Node<T> node;
>> 371: 
>> 372:         @SuppressWarnings("unused") private volatile ForEachOrderedTask<S, T> next; // Only accessed through the NEXT VarHandle
> 
> I think the variable can be declared without `volatile` as the operations on the `VarHandle` will determine the memory semantics used regardless? So, the `NEXT.set()` at L431 might also be replaced with `NEXT.setVolatile()`

@minborg Good point. Reference here:

"Access modes will override any memory ordering effects specified at the declaration site of a variable. For example, a VarHandle accessing a field using the get access mode will access the field as specified by its access mode even if that field is declared volatile. When mixed access is performed extreme care should be taken since the Java Memory Model may permit surprising results. " - https://docs.oracle.com/en/java/javase/19/docs/api/java.base/java/lang/invoke/VarHandle.html

@minborg To clarify, I intended to do a plain write since safe publishing will be done by `fork()`

-------------

PR: https://git.openjdk.org/jdk/pull/12320

From rgiulietti at openjdk.org  Thu Feb 16 16:54:27 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Thu, 16 Feb 2023 16:54:27 GMT
Subject: RFR: 8302204: Optimize BigDecimal.divide
In-Reply-To: <rUC0Dh_-1E0PZNJwM0GRH1KPu6prPotT-oeDTUdqjI4=.a8f7d3b7-a0f2-45a0-ae01-f37ef108d18f@github.com>
References: <rUC0Dh_-1E0PZNJwM0GRH1KPu6prPotT-oeDTUdqjI4=.a8f7d3b7-a0f2-45a0-ae01-f37ef108d18f@github.com>
Message-ID: <33muq0xW2ZRW13PAjRpOFAMFC2e1iZ_pR_4SXupx7pk=.02db719e-4919-43b8-a6ca-b87e115007f9@github.com>

On Fri, 10 Feb 2023 10:00:05 GMT, Xiaowei Lu <duke at openjdk.org> wrote:

> [JDK-8269667](https://bugs.openjdk.org/browse/JDK-8269667) has uncovered the poor performance of BigDecimal.divide under certain circumstance.
> 
> We confront similar situations when benchmarking Spark3 on TPC-DS test kit. According to the flame-graph below, it is StripZeros that spends most of the time of BigDecimal.divide. Hence we propose this patch to optimize stripping zeros.
> ![?? 1](https://user-images.githubusercontent.com/39413832/218062061-53cd0220-776e-4b72-8b9a-6b0f11707986.png)
> 
> Currently, createAndStripZerosToMatchScale() is performed linearly. That is, the target value is parsed from back to front, each time stripping out single ?0?. To optimize, we can adopt the method of binary search. That is, each time we try to strip out ${scale/2} ?0?s. 
> 
> The performance looks good. Therotically, time complexity of our method is O(log n), while the current one is O(n). In practice, benchmarks on Spark3 show that 1/3 less time (102s->68s) is spent on TPC-DS query4. We also runs Jtreg and JCK to check correctness, and it seems fine.
> 
> More about environment: 
> we run Spark3.3.0 on Openjdk11, but it seems jdk version doesn?t have much impact on BigDecimal. Spark cluster consists of a main node and 2 core nodes, each has 4cores, 16g memory and 4x500GB storage.

After making sure that `intVal` is even, and before attempting a division by a power of 10, it might help to check if 5 divides `intVal` in the first place. If it doesn't, there no point in performing the division.

It can be shown that 5 divides `intVal` if and only if it divides the `long` sum of all `int`s in the `mag` array of `intVal`.

I didn't try out if this contributes to improve the overall performance, but it might be worth giving a try.

-------------

PR: https://git.openjdk.org/jdk/pull/12509

From mullan at openjdk.org  Thu Feb 16 16:55:35 2023
From: mullan at openjdk.org (Sean Mullan)
Date: Thu, 16 Feb 2023 16:55:35 GMT
Subject: RFR: 8301627: System.exit and Runtime.exit debug logging [v4]
In-Reply-To: <S8S5gyxRG8WS_GbA0zrJPhXIxv6yReejyxgfc_FqBBQ=.eb6b1794-0f21-4292-ac7a-34e7d001f6b1@github.com>
References: <OzJeJH5yxolKPChcUisqtzGYF_MU3oOJdx6HPhsXjBw=.15eefe39-efe1-433e-a6ac-02b4a730f264@github.com>
 <S8S5gyxRG8WS_GbA0zrJPhXIxv6yReejyxgfc_FqBBQ=.eb6b1794-0f21-4292-ac7a-34e7d001f6b1@github.com>
Message-ID: <urHmEdJ8jXZQNdL6FiTKipTl3QTmtOg5N9af7CFIam0=.87e18e2e-64bb-48e2-8411-56c27baf0bae@github.com>

On Tue, 14 Feb 2023 18:56:29 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> It can be difficult to find the cause of calls to `java.lang.System.exit(status)` and `Runtime.exit(status)` because the Java runtime exits.
>> The status value and stack trace are logged using the System Logger named `java.lang.Runtime` with message level `System.Logger.Level.DEBUG`.
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Correct System.getLogger link

src/java.base/share/classes/java/lang/Runtime.java line 160:

> 158:      *
> 159:      * @implNote
> 160:      * If the {@link System#getLogger(String) System.getLogger("java.lang.Runtime")}

It may read better to use a textual description for the link, like "the system logger for `java.lang.Runtime`".

src/java.base/share/classes/java/lang/Runtime.java line 161:

> 159:      * @implNote
> 160:      * If the {@link System#getLogger(String) System.getLogger("java.lang.Runtime")}
> 161:      * is enabled for logging level {@link System.Logger.Level#DEBUG Level.DEBUG} the stack trace

"with logging level"?

-------------

PR: https://git.openjdk.org/jdk/pull/12517

From psandoz at openjdk.org  Thu Feb 16 17:13:29 2023
From: psandoz at openjdk.org (Paul Sandoz)
Date: Thu, 16 Feb 2023 17:13:29 GMT
Subject: RFR: JDK-8302666: Replace CHM with VarHandle in ForeachOrderedTask
In-Reply-To: <HAgE8xmpZT_2-b5ZDr8TgJNgjhVb3D4ZS3sQqA7c6Mo=.389fa590-681c-44a9-9823-8f70a6129797@github.com>
References: <HAgE8xmpZT_2-b5ZDr8TgJNgjhVb3D4ZS3sQqA7c6Mo=.389fa590-681c-44a9-9823-8f70a6129797@github.com>
Message-ID: <Cgw-lNDkAD_TkUSehGq35yzULSGMA54hoT6jiKNFWjk=.1b1f80bb-be96-45b2-995b-1f61c21187b1@github.com>

On Tue, 31 Jan 2023 10:57:58 GMT, Viktor Klang <duke at openjdk.org> wrote:

> I noticed when looking at the code that there was no real need to use a CHM to perform the tracking of activation in an ordered fashion on ForEachOrderedTask, but instead a VarHandle can be used, reducing allocations and indirection.

src/java.base/share/classes/java/util/stream/ForEachOps.java line 431:

> 429:                 // leftChild and rightChild were just created and not fork():ed
> 430:                 // yet so no need for a volatile write
> 431:                 NEXT.set(leftChild, rightChild);

Make `next` a plain field and shuffle up the assignment (`leftChild.next = rightChild`) to occur immediately after construction of the right child task? (FWIW `addToPendingCount` operates on a volatile field of `CountedCompleter`).

-------------

PR: https://git.openjdk.org/jdk/pull/12320

From rgiulietti at openjdk.org  Thu Feb 16 17:27:26 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Thu, 16 Feb 2023 17:27:26 GMT
Subject: RFR: 8302590: Add String.indexOf(int ch, int fromIndex, int toIndex)
Message-ID: <uQ65oRaVDfpzm9bYRuo_MvSuZIdepicE3GnB3Omyngs=.fc23545b-141a-47e5-8a6a-aa28ae1375e5@github.com>

Add an `indexOf()` variant allowing to specify both a lower and an upper bound on the search.

-------------

Commit messages:
 - 8302590: Add String.indexOf(int ch, int fromIndex, int toIndex)

Changes: https://git.openjdk.org/jdk/pull/12600/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12600&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8302590
  Stats: 245 lines in 4 files changed: 218 ins; 2 del; 25 mod
  Patch: https://git.openjdk.org/jdk/pull/12600.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12600/head:pull/12600

PR: https://git.openjdk.org/jdk/pull/12600

From duke at openjdk.org  Thu Feb 16 17:32:27 2023
From: duke at openjdk.org (Andriy Plokhotnyuk)
Date: Thu, 16 Feb 2023 17:32:27 GMT
Subject: RFR: 8302204: Optimize BigDecimal.divide
In-Reply-To: <33muq0xW2ZRW13PAjRpOFAMFC2e1iZ_pR_4SXupx7pk=.02db719e-4919-43b8-a6ca-b87e115007f9@github.com>
References: <rUC0Dh_-1E0PZNJwM0GRH1KPu6prPotT-oeDTUdqjI4=.a8f7d3b7-a0f2-45a0-ae01-f37ef108d18f@github.com>
 <33muq0xW2ZRW13PAjRpOFAMFC2e1iZ_pR_4SXupx7pk=.02db719e-4919-43b8-a6ca-b87e115007f9@github.com>
Message-ID: <yjoqpAK2jp9YWF37NmvEIL3svGo_bW-LokxNaBTGTqY=.5d1982f5-a7ee-4037-8155-82a3cb31edc3@github.com>

On Thu, 16 Feb 2023 16:51:43 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

> After making sure that `intVal` is even, and before attempting a division by a power of 10, it might help to check if 5 divides `intVal` in the first place. If it doesn't, there no point in performing the division.
> 
> It can be shown that 5 divides `intVal` if and only if it divides the `long` sum of all `int`s in the `mag` array of `intVal`.
> 
> I didn't try out if this contributes to improve the overall performance, but it might be worth giving a try.

[Here](https://github.com/plokhotnyuk/jsoniter-scala/commit/a92a4a6dbf3a51320c677e812d3495f1fa78255a#diff-4e32fbdaa814b6b0b8e22a1b1440bb2928e50a6e1482e0d56c08d606812b625bL1971) is the Scala function that tests divisibility by 5 for a positive `Long` value efficiently with minimum multiplication operations and can be easily adopted for Java.

-------------

PR: https://git.openjdk.org/jdk/pull/12509

From rgiulietti at openjdk.org  Thu Feb 16 17:33:26 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Thu, 16 Feb 2023 17:33:26 GMT
Subject: RFR: 8302590: Add String.indexOf(int ch, int fromIndex,
 int toIndex)
In-Reply-To: <uQ65oRaVDfpzm9bYRuo_MvSuZIdepicE3GnB3Omyngs=.fc23545b-141a-47e5-8a6a-aa28ae1375e5@github.com>
References: <uQ65oRaVDfpzm9bYRuo_MvSuZIdepicE3GnB3Omyngs=.fc23545b-141a-47e5-8a6a-aa28ae1375e5@github.com>
Message-ID: <7_xR72wJDaTIp7BiN1EV9DY2lD2yaDDHgWvVLXRJ-Qc=.11db0f7f-d91b-4f65-9e4d-9150d489e630@github.com>

On Thu, 16 Feb 2023 17:16:35 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

> Add an `indexOf()` variant allowing to specify both a lower and an upper bound on the search.

The underlying functionality is already present in non-publicly accessible methods. These are intrinsified, leveraging SIMD instructions where available.

This PR proposed to add a public API point to the underlying methods.

-------------

PR: https://git.openjdk.org/jdk/pull/12600

From lancea at openjdk.org  Thu Feb 16 18:05:35 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Thu, 16 Feb 2023 18:05:35 GMT
Subject: RFR: 8301873: Avoid string decoding in ZipFile.Source.getEntryPos
 [v15]
In-Reply-To: <2Ab-zkCiRlWL6S2TCDzeauJfvacWxgFlC0LpLmeUVhA=.6ff1c130-8e83-4b41-b1bb-9741d068664b@github.com>
References: <FkmdspiHVjkAKFqm5kUgwaf55YH5cBbczS_3krqsdFs=.05eca901-f55f-47d9-b1bc-0cf2f5b87536@github.com>
 <2Ab-zkCiRlWL6S2TCDzeauJfvacWxgFlC0LpLmeUVhA=.6ff1c130-8e83-4b41-b1bb-9741d068664b@github.com>
Message-ID: <43GNnUEnJ94Y37Gj0M4EGqG3nZbZ7WNI_rRKndcEFCM=.a9c77260-c719-4a0d-8c6f-7162551d05a1@github.com>

On Wed, 15 Feb 2023 11:44:17 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

>> After finding a hash match, getEntryPos needs to compare the lookup name up to the encoded entry name in the CEN. This comparison is done by decoding the entry name into a String. The names can then be compared using the String API. This decoding step adds a significat cost to this method.
>> 
>> This PR suggest to update the string comparison such that in the common case where  both the lookup name and the entry name are encoded in ASCII-compatible UTF-8,  decoding can be avoided and the byte arrays can instead be compared direcly. 
>> 
>> ZipCoder is updated with a new method to compare a string with an encoded byte array range.  The default implementation decodes to string (like the current code), while the UTF-8 implementation uses JavaLangAccess.getBytesNoRepl to get the  bytes. Both methods thes uses Arrays.mismatch for comparison with or without matching trailing slashes. 
>> 
>> Additionally, this PR suggest to make the following updates to getEntryPos:
>> 
>> - The try/catch for IAE is redundant and can be safely removed. (initCEN already checks this and will throws IAE for invalid UTF-8). This seems to give a 3-4% speedup on micros)
>> - A new test InvalidBytesInEntryNameOrComment is a added to verify that initCEN does in fact reject invalid UTF-8 in CEN file names and comments. (I found no existing test coverage for this)
>> - The recursion when looking for "name/" matches is replaced with iteration. We keep track of any "name/" match and return it at the end of the search. (I feel this is easier to follow and it also gives a ~30% speedup for addSlash lookups with no regression on regular lookups)
>> 
>> (My though is that including these additional updates in this PR might reduce reviewer overhead given that it touches the exact same code. I might be wrong on this, please advise :)
>> 
>> I'm seeing a ~17% saving on the micro ZipFileGetEntry.getEntryHit (modified to use xalan.jar):
>> 
>> Baseline:
>> 
>> Benchmark                             (size)  Mode  Cnt    Score   Error  Units
>> ZipFileGetEntry.getEntryHit              512  avgt   15   74.941 ? 1.004  ns/op
>> ZipFileGetEntry.getEntryHit             1024  avgt   15   84.943 ? 1.320  ns/op
>> ZipFileGetEntry.getEntryHitUncached      512  avgt   15  120.371 ? 2.386  ns/op
>> ZipFileGetEntry.getEntryHitUncached     1024  avgt   15  126.128 ? 1.075  ns/op
>> ZipFileGetEntry.getEntryMiss             512  avgt   15   23.818 ? 0.838  ns/op
>> ZipFileGetEntry.getEntryMiss            1024  avgt   15   29.762 ? 5.998  ns/op
>> ZipFileGetEntry.getEntryMissUncached     512  avgt   15   59.405 ? 0.545  ns/op
>> ZipFileGetEntry.getEntryMissUncached    1024  avgt   15   71.840 ? 2.455  ns/op
>> ZipFileGetEntry.getEntrySlash            512  avgt   15  135.621 ? 4.341  ns/op
>> ZipFileGetEntry.getEntrySlash           1024  avgt   15  134.190 ? 2.141  ns/op
>> 
>> 
>> 
>> PR:
>> 
>> 
>> Benchmark                             (size)  Mode  Cnt    Score   Error  Units
>> ZipFileGetEntry.getEntryHit              512  avgt   15   62.267 ? 1.329  ns/op
>> ZipFileGetEntry.getEntryHit             1024  avgt   15   72.916 ? 2.428  ns/op
>> ZipFileGetEntry.getEntryHitUncached      512  avgt   15  101.630 ? 1.154  ns/op
>> ZipFileGetEntry.getEntryHitUncached     1024  avgt   15  113.161 ? 0.502  ns/op
>> ZipFileGetEntry.getEntryMiss             512  avgt   15   23.003 ? 1.191  ns/op
>> ZipFileGetEntry.getEntryMiss            1024  avgt   15   23.236 ? 1.114  ns/op
>> ZipFileGetEntry.getEntryMissUncached     512  avgt   15   56.781 ? 1.505  ns/op
>> ZipFileGetEntry.getEntryMissUncached    1024  avgt   15   67.767 ? 1.963  ns/op
>> ZipFileGetEntry.getEntrySlash            512  avgt   15   73.745 ? 2.717  ns/op
>> ZipFileGetEntry.getEntrySlash           1024  avgt   15   75.784 ? 1.051  ns/op
>> 
>> 
>> To assess the impact on startup/warmup, I made a main method class which measures the total time of calling ZipFile.getEntry for all entries in the 109 JAR file dependenies of spring-petclinic. The shows a nice improvement (time in micros):
>> 
>> 
>> Percentile Baseline Patch
>> 50?%          23155 21149
>> 75?%          23598 21454
>> 90?%          23989 21691
>> 95?%          24238 21973
>> 99?%          25270 22446
>> STDEV           792   549
>> Count           500   500
>
> Eirik Bjorsnos has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix a regression where the invalidName was tested instead of comment in the invalid comment test

As soon as my last set of Mach5 runs complete I will approve this change.  The JCK tests in this area also look good.

-------------

PR: https://git.openjdk.org/jdk/pull/12290

From rgiulietti at openjdk.org  Thu Feb 16 18:10:28 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Thu, 16 Feb 2023 18:10:28 GMT
Subject: RFR: 8302204: Optimize BigDecimal.divide
In-Reply-To: <33muq0xW2ZRW13PAjRpOFAMFC2e1iZ_pR_4SXupx7pk=.02db719e-4919-43b8-a6ca-b87e115007f9@github.com>
References: <rUC0Dh_-1E0PZNJwM0GRH1KPu6prPotT-oeDTUdqjI4=.a8f7d3b7-a0f2-45a0-ae01-f37ef108d18f@github.com>
 <33muq0xW2ZRW13PAjRpOFAMFC2e1iZ_pR_4SXupx7pk=.02db719e-4919-43b8-a6ca-b87e115007f9@github.com>
Message-ID: <BBWxPnPf_dJKiUgaNHbKbP6xebNcwiiGJL6Yq2rYUNk=.07031895-dce1-45ec-a336-05919f7f6367@github.com>

On Thu, 16 Feb 2023 16:51:43 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

> It can be shown that 5 divides `intVal` if and only if it divides the `long` sum of all `int`s in the mag array of `intVal`.

More precisely, the sum must be computed over the `mag` elements taken as _unsigned_ values:
`sum += mag[i] & 0xffff_ffffL`

-------------

PR: https://git.openjdk.org/jdk/pull/12509

From duke at openjdk.org  Thu Feb 16 18:51:29 2023
From: duke at openjdk.org (David M. Lloyd)
Date: Thu, 16 Feb 2023 18:51:29 GMT
Subject: RFR: 8292914: Drop the counter from lambda class names [v5]
In-Reply-To: <ug5D-IcPm0nTq7aJbugu8IiRgNutvihiUagxsDRFFKs=.4697dfe0-bbab-401d-91e7-2ec84eecce97@github.com>
References: <GgLfH-ueBQqT-Mfk1mKpKFAt8fYqyjfVJ9lmlsBsCbo=.8dd5b3b4-4e84-4970-9179-1c0399b30edc@github.com>
 <ug5D-IcPm0nTq7aJbugu8IiRgNutvihiUagxsDRFFKs=.4697dfe0-bbab-401d-91e7-2ec84eecce97@github.com>
Message-ID: <EY6FbHyeQmE2TmGXXYkCOIGlubG5-rsfU0ZYnt0rmi4=.04459396-873d-4eae-8892-a44ef07f6986@github.com>

On Thu, 16 Feb 2023 14:06:54 GMT, David M. Lloyd <duke at openjdk.org> wrote:

>> The class generated for lambda proxies is now defined as a hidden class. This means that the counter, which was used to ensure a unique class name and avoid clashes, is now redundant. In addition to performing redundant work, this also impacts build reproducibility for native image generators which might already have a strategy to cope with hidden classes but cannot cope with indeterminate definition order for lambda proxy classes.
>> 
>> This solves JDK-8292914 by making lambda proxy names always be stable without any configuration needed. This would also replace #10024.
>
> David M. Lloyd has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use `Instant.now()` for more precise timestamps.
>   
>   Using `currentTimeMillis` is imprecise enough that tests may sporadically fail if two lambda classes from the same lambda class are dumped within 1ms of one another. `Instant.now()` is much more precise and also sorts nicely.

I can't say for certain (since I don't have a Windows environment I can test on) but I believe that the timestamp resolution on Windows may be too low for the timestamp approach to work (at least by itself).

I guess next I'll try out the approach similar to the one suggested by @iklam. Though maybe instead of a `Map` I'll use a `ClassValue` to retain an `AtomicInteger` instance for the per-class counter.

-------------

PR: https://git.openjdk.org/jdk/pull/12579

From iklam at openjdk.org  Thu Feb 16 19:21:31 2023
From: iklam at openjdk.org (Ioi Lam)
Date: Thu, 16 Feb 2023 19:21:31 GMT
Subject: RFR: 8292914: Drop the counter from lambda class names [v5]
In-Reply-To: <ug5D-IcPm0nTq7aJbugu8IiRgNutvihiUagxsDRFFKs=.4697dfe0-bbab-401d-91e7-2ec84eecce97@github.com>
References: <GgLfH-ueBQqT-Mfk1mKpKFAt8fYqyjfVJ9lmlsBsCbo=.8dd5b3b4-4e84-4970-9179-1c0399b30edc@github.com>
 <ug5D-IcPm0nTq7aJbugu8IiRgNutvihiUagxsDRFFKs=.4697dfe0-bbab-401d-91e7-2ec84eecce97@github.com>
Message-ID: <ytPJx_mfI7E28XFBEKd-T6NL3OliGpUnYcD6zVKE2SM=.0266c864-3e2b-4f2b-98a9-ade0c630ce63@github.com>

On Thu, 16 Feb 2023 14:06:54 GMT, David M. Lloyd <duke at openjdk.org> wrote:

>> The class generated for lambda proxies is now defined as a hidden class. This means that the counter, which was used to ensure a unique class name and avoid clashes, is now redundant. In addition to performing redundant work, this also impacts build reproducibility for native image generators which might already have a strategy to cope with hidden classes but cannot cope with indeterminate definition order for lambda proxy classes.
>> 
>> This solves JDK-8292914 by making lambda proxy names always be stable without any configuration needed. This would also replace #10024.
>
> David M. Lloyd has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use `Instant.now()` for more precise timestamps.
>   
>   Using `currentTimeMillis` is imprecise enough that tests may sporadically fail if two lambda classes from the same lambda class are dumped within 1ms of one another. `Instant.now()` is much more precise and also sorts nicely.

Sorry, to be clear, I am not suggesting using a map for the proxy classes.

Instead, we should keep the existing logic that uses an AtomicInteger, but do this only when `-Djdk.internal.lambda.dumpProxyClasses=` is specified. That would be minimal change and we know it will surely work for people who are currently using this debugging property.

-------------

PR: https://git.openjdk.org/jdk/pull/12579

From mchung at openjdk.org  Thu Feb 16 19:23:36 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Thu, 16 Feb 2023 19:23:36 GMT
Subject: RFR: 8293667: Align jlink's --compress option with jmod's
 --compress option [v8]
In-Reply-To: <4BYAhi9LFmHwShwCV1Ii5hDxneje8QdlppEJI8_W4hw=.8fc71e0e-404e-47c9-8b58-c95fd9954698@github.com>
References: <JWevwHuR2vF3k-JRxmTAxfNN6g-EBkgG2N9DHn4fkGY=.f9768dfd-cab4-49a9-83b9-d77a1572e917@github.com>
 <4BYAhi9LFmHwShwCV1Ii5hDxneje8QdlppEJI8_W4hw=.8fc71e0e-404e-47c9-8b58-c95fd9954698@github.com>
Message-ID: <qBrZqQ00Jbn2kLgmrjki74gnRTigK0pr_77qpAjRGTw=.ed2ae7d9-5274-4b3f-b374-aee239ec80c0@github.com>

On Thu, 16 Feb 2023 03:35:31 GMT, Ian Graves <igraves at openjdk.org> wrote:

>> This is an approach to adding a flag to jlink that will allow --compress to take the same types of arguments as jmod, thus bringing the two into alignment. This likely requires a CSR and a discussion on whether we should deprecate or simply remove the original numeric compression arguments.
>
> Ian Graves has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updating properties

src/jdk.jlink/share/classes/jdk/tools/jlink/internal/ImagePluginConfiguration.java line 57:

> 55:         CATEGORIES_ORDER.add(Category.SORTER);
> 56:         CATEGORIES_ORDER.add(Category.METAINFO_ADDER);
> 57:         CATEGORIES_ORDER.add(Category.IMAGE_TRANSFORMER);

This change is no longer needed?

src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/DefaultCompressPlugin.java line 102:

> 100:                     break;
> 101:                 case LEVEL_2:
> 102:                     zip = new ZipPlugin(resFilter);

For old values (0, 1, 2), jlink should emit a warning message that that value is deprecated and will be removed in a future release.

src/jdk.jlink/share/classes/jdk/tools/jlink/plugin/Plugin.java line 66:

> 64:         PACKAGER("PACKAGER"),
> 65: 
> 66:         IMAGE_TRANSFORMER("IMAGE_TRANSFORMER");

No longer needed.

src/jdk.jlink/share/classes/jdk/tools/jlink/resources/plugins.properties line 62:

> 60: \  --class-for-name          Class optimization: convert Class.forName calls to constant loads.
> 61: 
> 62: compress.argument=<0|1|2|zip-[0-9]>[:filter=<pattern-list>]

Suggest to just show the new values.

Suggestion:

compress.argument=<zip-[0-9]>[:filter=<pattern-list>]

src/jdk.jlink/share/classes/jdk/tools/jlink/resources/plugins.properties line 70:

> 68: compression, and zip-9 provides the\n\
> 69: best compression. Default is zip-6.\n\
> 70: Deprecated values to be removed in a future release:\n\

Suggestion:

Compression to use in compressing resources.


`compress.description` is just the description of the plugin.   `compress.usage` shows the accepted values.

src/jdk.jlink/share/classes/jdk/tools/jlink/resources/plugins.properties line 84:

> 82: \                            0:  No compression. Equivalent to zip-0.\n\
> 83: \                            1:  Constant string sharing\n\
> 84: \                            2:  Equivalent to zip-6.

I think it's adequate for the `--help` output to show the deprecated values.  This `compress.usage` can simply show the new values.

Suggestion:

\  --compress <compress>     Compression to use in compressing resources.\n\
\                            Accepted values are:\n\
\                            zip-[0-9], where zip-0 provides no compression,\n\
\                            and zip-9 provides the best compression.\n\
\                            Default is zip-6.

-------------

PR: https://git.openjdk.org/jdk/pull/11617

From duke at openjdk.org  Thu Feb 16 19:30:33 2023
From: duke at openjdk.org (David M. Lloyd)
Date: Thu, 16 Feb 2023 19:30:33 GMT
Subject: RFR: 8292914: Drop the counter from lambda class names [v5]
In-Reply-To: <ug5D-IcPm0nTq7aJbugu8IiRgNutvihiUagxsDRFFKs=.4697dfe0-bbab-401d-91e7-2ec84eecce97@github.com>
References: <GgLfH-ueBQqT-Mfk1mKpKFAt8fYqyjfVJ9lmlsBsCbo=.8dd5b3b4-4e84-4970-9179-1c0399b30edc@github.com>
 <ug5D-IcPm0nTq7aJbugu8IiRgNutvihiUagxsDRFFKs=.4697dfe0-bbab-401d-91e7-2ec84eecce97@github.com>
Message-ID: <N9ltRUO_SyuVBEemF5TMKgup-6A-F5fRGvUna9cNAFA=.90fb83b9-6938-4146-885b-0082f6f224b6@github.com>

On Thu, 16 Feb 2023 14:06:54 GMT, David M. Lloyd <duke at openjdk.org> wrote:

>> The class generated for lambda proxies is now defined as a hidden class. This means that the counter, which was used to ensure a unique class name and avoid clashes, is now redundant. In addition to performing redundant work, this also impacts build reproducibility for native image generators which might already have a strategy to cope with hidden classes but cannot cope with indeterminate definition order for lambda proxy classes.
>> 
>> This solves JDK-8292914 by making lambda proxy names always be stable without any configuration needed. This would also replace #10024.
>
> David M. Lloyd has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use `Instant.now()` for more precise timestamps.
>   
>   Using `currentTimeMillis` is imprecise enough that tests may sporadically fail if two lambda classes from the same lambda class are dumped within 1ms of one another. `Instant.now()` is much more precise and also sorts nicely.

OK, sure, that'll work. ?

-------------

PR: https://git.openjdk.org/jdk/pull/12579

From duke at openjdk.org  Thu Feb 16 19:35:54 2023
From: duke at openjdk.org (David M. Lloyd)
Date: Thu, 16 Feb 2023 19:35:54 GMT
Subject: RFR: 8292914: Drop the counter from lambda class names [v6]
In-Reply-To: <GgLfH-ueBQqT-Mfk1mKpKFAt8fYqyjfVJ9lmlsBsCbo=.8dd5b3b4-4e84-4970-9179-1c0399b30edc@github.com>
References: <GgLfH-ueBQqT-Mfk1mKpKFAt8fYqyjfVJ9lmlsBsCbo=.8dd5b3b4-4e84-4970-9179-1c0399b30edc@github.com>
Message-ID: <zlDm2W50G6NgRkzmgEpX6MTVs3XyYMnY3tN1YnObWUA=.03a3d8d7-4d20-4fc6-8028-b20a8603b0a6@github.com>

> The class generated for lambda proxies is now defined as a hidden class. This means that the counter, which was used to ensure a unique class name and avoid clashes, is now redundant. In addition to performing redundant work, this also impacts build reproducibility for native image generators which might already have a strategy to cope with hidden classes but cannot cope with indeterminate definition order for lambda proxy classes.
> 
> This solves JDK-8292914 by making lambda proxy names always be stable without any configuration needed. This would also replace #10024.

David M. Lloyd has updated the pull request incrementally with one additional commit since the last revision:

  Use a unique index for the dumped lambda class instead of a time stamp

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12579/files
  - new: https://git.openjdk.org/jdk/pull/12579/files/c73442b2..e9d1d7f2

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12579&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12579&range=04-05

  Stats: 15 lines in 3 files changed: 3 ins; 7 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/12579.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12579/head:pull/12579

PR: https://git.openjdk.org/jdk/pull/12579

From darcy at openjdk.org  Thu Feb 16 19:38:04 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Thu, 16 Feb 2023 19:38:04 GMT
Subject: RFR: JDK-8302028: Port fdlibm atan2 to Java
Message-ID: <xl79M-V4_2t49GuCudJHQBaJjAcwWl9f2Bv19RbAmdo=.b9c97066-8cf4-4569-8b4b-8b4874e23833@github.com>

Working down the porting list, next stop, atan2.

-------------

Commit messages:
 - JDK-8302028: Port fdlibm atan2 to Java

Changes: https://git.openjdk.org/jdk/pull/12608/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12608&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8302028
  Stats: 588 lines in 5 files changed: 571 ins; 8 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/12608.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12608/head:pull/12608

PR: https://git.openjdk.org/jdk/pull/12608

From darcy at openjdk.org  Thu Feb 16 19:38:04 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Thu, 16 Feb 2023 19:38:04 GMT
Subject: RFR: JDK-8302028: Port fdlibm atan2 to Java
In-Reply-To: <xl79M-V4_2t49GuCudJHQBaJjAcwWl9f2Bv19RbAmdo=.b9c97066-8cf4-4569-8b4b-8b4874e23833@github.com>
References: <xl79M-V4_2t49GuCudJHQBaJjAcwWl9f2Bv19RbAmdo=.b9c97066-8cf4-4569-8b4b-8b4874e23833@github.com>
Message-ID: <_m6BTSlfjG2zqYUh_6T2aVEGgoOwx4kBlIaCfCsQ868=.19d39fa1-afe0-40e5-aac2-c2ff60c85d01@github.com>

On Thu, 16 Feb 2023 19:30:06 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Working down the porting list, next stop, atan2.

Diffs of the various ports, starting with the original C vs the transliteration port:


$ diff -w Atan2.c Atan2.translit.java 
1c1,4
< /* __ieee754_atan2(y,x)
---
>     /**
>      * Returns the angle theta from the conversion of rectangular
>      * coordinates (x, y) to polar coordinates (r, theta).
>      *
27,34c30,31
< 
< #include "fdlibm.h"
< 
< #ifdef __STDC__
< static const double
< #else
< static double
< #endif
---
>     static class Atan2 {
>         private static final double
42,48c39
< #ifdef __STDC__
<         double __ieee754_atan2(double y, double x)
< #else
<         double __ieee754_atan2(y,x)
<         double  y,x;
< #endif
< {
---
>         static double compute(double y, double x) {
51c42
<         unsigned lx,ly;
---
>             /*unsigned*/ int lx,ly;
100c91
<         else z=atan(fabs(y/x));         /* safe to do y/x */
---
>             else z=atan(Math.abs(y/x));         /* safe to do y/x */
103c94,96
<             case 1: __HI(z) ^= 0x80000000;
---
>             case 1: 
>                 // original:__HI(z) ^= 0x80000000;
>                 z = __HI(z, __HI(x) ^ 0x80000000);
109a103
>     }


And the transliteration vs the more idiomatic port:


$ diff -w Atan2.translit.java Atan2.fdlibm.java 
30a31,32
>         private Atan2() {throw new UnsupportedOperationException();}
> 
33,37c35,37
<             zero  = 0.0,
<             pi_o_4  = 7.8539816339744827900E-01, /* 0x3FE921FB, 0x54442D18 */
<             pi_o_2  = 1.5707963267948965580E+00, /* 0x3FF921FB, 0x54442D18 */
<             pi      = 3.1415926535897931160E+00, /* 0x400921FB, 0x54442D18 */
<             pi_lo   = 1.2246467991473531772E-16; /* 0x3CA1A626, 0x33145C07 */
---
>             pi_o_4  = 0x1.921fb54442d18p-1,  // 7.8539816339744827900E-01
>             pi_o_2  = 0x1.921fb54442d18p0,   // 1.5707963267948965580E+00
>             pi_lo   = 0x1.1a62633145c07p-53; // 1.2246467991473531772E-16
44c44,45
<             hx = __HI(x); ix = hx&0x7fffffff;
---
>             hx = __HI(x);
>             ix = hx & 0x7fff_ffff;
46c47,48
<             hy = __HI(y); iy = hy&0x7fffffff;
---
>             hy = __HI(y);
>             iy = hy&0x7fff_ffff;
48,49c50,51
<             if(((ix|((lx|-lx)>>31))>0x7ff00000)||
<                ((iy|((ly|-ly)>>31))>0x7ff00000))    /* x or y is NaN */
---
>             if (((ix | ((lx | -lx) >> 31)) > 0x7ff0_0000)||
>                 ((iy |((ly | - ly) >> 31)) > 0x7ff0_0000))    // x or y is NaN
51,52c53,55
<             if(((hx-0x3ff00000)|lx)==0) return atan(y);   /* x=1.0 */
<             m = ((hy>>31)&1)|((hx>>30)&2);  /* 2*sign(x)+sign(y) */
---
>             if (((hx - 0x3ff0_0000) | lx) == 0) // x = 1.0
>                 return StrictMath.atan(y);
>             m = ((hy >> 31) & 1)|((hx >> 30) & 2);  // 2*sign(x) + sign(y)
54c57
<             /* when y = 0 */
---
>             // when y = 0
56,73c59,67
<                 switch(m) {
<                 case 0:
<                 case 1: return y;       /* atan(+-0,+anything)=+-0 */
<                 case 2: return  pi+tiny;/* atan(+0,-anything) = pi */
<                 case 3: return -pi-tiny;/* atan(-0,-anything) =-pi */
<                 }
<             }
<             /* when x = 0 */
<             if((ix|lx)==0) return (hy<0)?  -pi_o_2-tiny: pi_o_2+tiny;
< 
<             /* when x is INF */
<             if(ix==0x7ff00000) {
<                 if(iy==0x7ff00000) {
<                     switch(m) {
<                     case 0: return  pi_o_4+tiny;/* atan(+INF,+INF) */
<                     case 1: return -pi_o_4-tiny;/* atan(-INF,+INF) */
<                     case 2: return  3.0*pi_o_4+tiny;/*atan(+INF,-INF)*/
<                     case 3: return -3.0*pi_o_4-tiny;/*atan(-INF,-INF)*/
---
>                 return switch(m) {
>                 case 0, 1 ->  y;              // atan(+/-0, +anything)  = +/-0
>                 case 2    ->  Math.PI + tiny; // atan(+0,   -anything)  =  pi
>                 default   -> -Math.PI - tiny; // atan(-0,   -anything)  = -pi
>                 };
>             }
>             // when x = 0
>             if ((ix | lx) == 0) {
>                 return (hy < 0)?  -pi_o_2 - tiny : pi_o_2 + tiny;
74a69,78
> 
>             // when x is INF
>             if (ix == 0x7ff0_0000) {
>                 if (iy == 0x7ff0_0000) {
>                     return switch(m) {
>                     case 0  ->  pi_o_4 + tiny;      // atan(+INF, +INF)
>                     case 1  -> -pi_o_4 - tiny;      // atan(-INF, +INF)
>                     case 2  ->  3.0*pi_o_4 + tiny;  // atan(+INF, -INF)
>                     default -> -3.0*pi_o_4 - tiny;  // atan(-INF, -INF)
>                     };
76,80c80,85
<                     switch(m) {
<                     case 0: return  zero  ;     /* atan(+...,+INF) */
<                     case 1: return -1.0*zero  ; /* atan(-...,+INF) */
<                     case 2: return  pi+tiny  ;  /* atan(+...,-INF) */
<                     case 3: return -pi-tiny  ;  /* atan(-...,-INF) */
---
>                     return switch(m) {
>                     case 0  ->  0.0;                // atan(+..., +INF)
>                     case 1  -> -0.0;                // atan(-..., +INF)
>                     case 2  ->  Math.PI + tiny;     // atan(+..., -INF)
>                     default -> -Math.PI - tiny;     // atan(-..., -INF)
>                     };
82a88,90
>             // when y is INF
>             if (iy == 0x7ff0_0000) {
>                 return (hy < 0)? -pi_o_2 - tiny : pi_o_2 + tiny;
84,85d91
<             /* when y is INF */
<             if(iy==0x7ff00000) return (hy<0)? -pi_o_2-tiny: pi_o_2+tiny;
87c93
<             /* compute y/x */
---
>             // compute y/x
89,101c95,107
<             if(k > 60) z=pi_o_2+0.5*pi_lo;  /* |y/x| >  2**60 */
<             else if(hx<0&&k<-60) z=0.0;     /* |y|/x < -2**60 */
<             else z=atan(Math.abs(y/x));         /* safe to do y/x */
<             switch (m) {
<             case 0: return       z  ;   /* atan(+,+) */
<             case 1: 
<                 // original:__HI(z) ^= 0x80000000;
<                 z = __HI(z, __HI(x) ^ 0x80000000);
<                 return       z  ;   /* atan(-,+) */
<             case 2: return  pi-(z-pi_lo);/* atan(+,-) */
<             default: /* case 3 */
<                 return  (z-pi_lo)-pi;/* atan(-,-) */
<             }
---
>             if (k > 60) {   // |y/x| >  2**60
>                 z = pi_o_2+0.5*pi_lo;
>             } else if (hx < 0 && k < -60) { // |y|/x < -2**60
>                 z = 0.0;
>             } else { // safe to do y/x
>                 z = StrictMath.atan(Math.abs(y/x));
>             }
>             return switch (m) {
>             case 0  ->  z;                    // atan(+, +)
>             case 1  -> -z;                    // atan(-, +)
>             case 2  -> Math.PI - (z - pi_lo); // atan(+, -)
>             default -> (z - pi_lo) - Math.PI; // atan(-, -), case 3
>             };


A few notes: I decided to use expression switches, but that is not necessary. Also, in the final switch I used "-z" as a more direct idiom to negate z than the form in the original fdlibm.

-------------

PR: https://git.openjdk.org/jdk/pull/12608

From duke at openjdk.org  Thu Feb 16 19:47:29 2023
From: duke at openjdk.org (Viktor Klang)
Date: Thu, 16 Feb 2023 19:47:29 GMT
Subject: RFR: JDK-8302666: Replace CHM with VarHandle in ForeachOrderedTask
In-Reply-To: <Cgw-lNDkAD_TkUSehGq35yzULSGMA54hoT6jiKNFWjk=.1b1f80bb-be96-45b2-995b-1f61c21187b1@github.com>
References: <HAgE8xmpZT_2-b5ZDr8TgJNgjhVb3D4ZS3sQqA7c6Mo=.389fa590-681c-44a9-9823-8f70a6129797@github.com>
 <Cgw-lNDkAD_TkUSehGq35yzULSGMA54hoT6jiKNFWjk=.1b1f80bb-be96-45b2-995b-1f61c21187b1@github.com>
Message-ID: <Xwk3XgU2boNqaROJFPVpvCJ39XgJqvoPIiRwcHcVha8=.91288345-f142-4a4d-ae31-d6df9c9e5754@github.com>

On Thu, 16 Feb 2023 17:10:17 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>> I noticed when looking at the code that there was no real need to use a CHM to perform the tracking of activation in an ordered fashion on ForEachOrderedTask, but instead a VarHandle can be used, reducing allocations and indirection.
>
> src/java.base/share/classes/java/util/stream/ForEachOps.java line 431:
> 
>> 429:                 // leftChild and rightChild were just created and not fork():ed
>> 430:                 // yet so no need for a volatile write
>> 431:                 NEXT.set(leftChild, rightChild);
> 
> Make `next` a plain field and shuffle up the assignment (`leftChild.next = rightChild`) to occur immediately after construction of the right child task? (FWIW `addToPendingCount` operates on a volatile field of `CountedCompleter`).

@PaulSandoz I'm usually a bit weary of piggybacking if it is not done on the same object, as future reorderings of the code might break that assumption. I wouldn't want to break anything silently so I made a rather conservative change. On which side should I err? :)

-------------

PR: https://git.openjdk.org/jdk/pull/12320

From duke at openjdk.org  Thu Feb 16 19:47:32 2023
From: duke at openjdk.org (ExE Boss)
Date: Thu, 16 Feb 2023 19:47:32 GMT
Subject: RFR: 8292914: Drop the counter from lambda class names [v6]
In-Reply-To: <zlDm2W50G6NgRkzmgEpX6MTVs3XyYMnY3tN1YnObWUA=.03a3d8d7-4d20-4fc6-8028-b20a8603b0a6@github.com>
References: <GgLfH-ueBQqT-Mfk1mKpKFAt8fYqyjfVJ9lmlsBsCbo=.8dd5b3b4-4e84-4970-9179-1c0399b30edc@github.com>
 <zlDm2W50G6NgRkzmgEpX6MTVs3XyYMnY3tN1YnObWUA=.03a3d8d7-4d20-4fc6-8028-b20a8603b0a6@github.com>
Message-ID: <MJ_UIR-6jJ9IqFPL9KqiZtnZKg1D-WRYVpPdYShvm7Y=.62eb1a11-52c2-4c6a-a3a7-9716d7daaf86@github.com>

On Thu, 16 Feb 2023 19:35:54 GMT, David M. Lloyd <duke at openjdk.org> wrote:

>> The class generated for lambda proxies is now defined as a hidden class. This means that the counter, which was used to ensure a unique class name and avoid clashes, is now redundant. In addition to performing redundant work, this also impacts build reproducibility for native image generators which might already have a strategy to cope with hidden classes but cannot cope with indeterminate definition order for lambda proxy classes.
>> 
>> This solves JDK-8292914 by making lambda proxy names always be stable without any configuration needed. This would also replace #10024.
>
> David M. Lloyd has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use a unique index for the dumped lambda class instead of a time stamp

src/java.base/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java line 208:

> 206:             name = name.replace('/', '_');
> 207:         }
> 208:         return name.replace('.', '/') + "$$Lambda$";

Using?`String::concat` uses?the?same code?path as?indy?based String?concatenation[^1].
Suggestion:

        return name.replace('.', '/').concat("$$Lambda");


[^1]: The?JDK?uses `StringBuilder`?based String?concatenation:
https://github.com/openjdk/jdk/blob/a39cf2e3b242298fbf5fafdb8aa9b5d4562061ef/make/modules/java.base/Java.gmk#L28

src/java.base/share/classes/java/lang/invoke/ProxyClassesDumper.java line 103:

> 101:         final int len = className.length();
> 102:         // add some padding to `len` for the index
> 103:         StringBuilder sb = new StringBuilder(len + 5);

Suggestion:

        StringBuilder sb = new StringBuilder(len + 6);

src/java.base/share/classes/java/lang/invoke/ProxyClassesDumper.java line 124:

> 122:             }
> 123:         }
> 124:         sb.append(counter.incrementAndGet());

Suggestion:

        sb.append('$').append(counter.incrementAndGet());

-------------

PR: https://git.openjdk.org/jdk/pull/12579

From igraves at openjdk.org  Thu Feb 16 20:02:31 2023
From: igraves at openjdk.org (Ian Graves)
Date: Thu, 16 Feb 2023 20:02:31 GMT
Subject: RFR: 8293667: Align jlink's --compress option with jmod's
 --compress option [v8]
In-Reply-To: <qBrZqQ00Jbn2kLgmrjki74gnRTigK0pr_77qpAjRGTw=.ed2ae7d9-5274-4b3f-b374-aee239ec80c0@github.com>
References: <JWevwHuR2vF3k-JRxmTAxfNN6g-EBkgG2N9DHn4fkGY=.f9768dfd-cab4-49a9-83b9-d77a1572e917@github.com>
 <4BYAhi9LFmHwShwCV1Ii5hDxneje8QdlppEJI8_W4hw=.8fc71e0e-404e-47c9-8b58-c95fd9954698@github.com>
 <qBrZqQ00Jbn2kLgmrjki74gnRTigK0pr_77qpAjRGTw=.ed2ae7d9-5274-4b3f-b374-aee239ec80c0@github.com>
Message-ID: <Soig0sJ3yO420T3bOle6Eqxjwn9vXPderSjxkDD9IY4=.381f4765-c907-4976-97af-7210f1f3fe12@github.com>

On Thu, 16 Feb 2023 19:08:39 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> Ian Graves has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Updating properties
>
> src/jdk.jlink/share/classes/jdk/tools/jlink/internal/ImagePluginConfiguration.java line 57:
> 
>> 55:         CATEGORIES_ORDER.add(Category.SORTER);
>> 56:         CATEGORIES_ORDER.add(Category.METAINFO_ADDER);
>> 57:         CATEGORIES_ORDER.add(Category.IMAGE_TRANSFORMER);
> 
> This change is no longer needed?

Thanks

-------------

PR: https://git.openjdk.org/jdk/pull/11617

From duke at openjdk.org  Thu Feb 16 20:05:29 2023
From: duke at openjdk.org (David M. Lloyd)
Date: Thu, 16 Feb 2023 20:05:29 GMT
Subject: RFR: 8292914: Drop the counter from lambda class names [v6]
In-Reply-To: <MJ_UIR-6jJ9IqFPL9KqiZtnZKg1D-WRYVpPdYShvm7Y=.62eb1a11-52c2-4c6a-a3a7-9716d7daaf86@github.com>
References: <GgLfH-ueBQqT-Mfk1mKpKFAt8fYqyjfVJ9lmlsBsCbo=.8dd5b3b4-4e84-4970-9179-1c0399b30edc@github.com>
 <zlDm2W50G6NgRkzmgEpX6MTVs3XyYMnY3tN1YnObWUA=.03a3d8d7-4d20-4fc6-8028-b20a8603b0a6@github.com>
 <MJ_UIR-6jJ9IqFPL9KqiZtnZKg1D-WRYVpPdYShvm7Y=.62eb1a11-52c2-4c6a-a3a7-9716d7daaf86@github.com>
Message-ID: <QdLVD35_eLVsA_nbpnGwRKcSR08HwCDpFAK3WpmiIUU=.3dd5ef57-0c63-4d0d-8fe6-cb924a5c2a9f@github.com>

On Thu, 16 Feb 2023 19:37:18 GMT, ExE Boss <duke at openjdk.org> wrote:

>> David M. Lloyd has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Use a unique index for the dumped lambda class instead of a time stamp
>
> src/java.base/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java line 208:
> 
>> 206:             name = name.replace('/', '_');
>> 207:         }
>> 208:         return name.replace('.', '/') + "$$Lambda$";
> 
> Using?`String::concat` uses?the?same code?path as?indy?based String?concatenation[^1].
> Suggestion:
> 
>         return name.replace('.', '/').concat("$$Lambda");
> 
> 
> [^1]: The?JDK?uses `StringBuilder`?based String?concatenation:
> https://github.com/openjdk/jdk/blob/a39cf2e3b242298fbf5fafdb8aa9b5d4562061ef/make/modules/java.base/Java.gmk#L28

The original code used `+` so I assume it's not a problem here... but if I'm wrong, wouldn't it be better to migrate from `+` to `concat` in a separate change?

> src/java.base/share/classes/java/lang/invoke/ProxyClassesDumper.java line 103:
> 
>> 101:         final int len = className.length();
>> 102:         // add some padding to `len` for the index
>> 103:         StringBuilder sb = new StringBuilder(len + 5);
> 
> Suggestion:
> 
>         StringBuilder sb = new StringBuilder(len + 6);

The index is unlikely to be more than 5 digits (pulled out of a hat really) for most applications I would think; is there something I overlooked here?

> src/java.base/share/classes/java/lang/invoke/ProxyClassesDumper.java line 124:
> 
>> 122:             }
>> 123:         }
>> 124:         sb.append(counter.incrementAndGet());
> 
> Suggestion:
> 
>         sb.append('$').append(counter.incrementAndGet());

The Lamdba class name already ends in `$` - is there a reason we'd need a second one when dumping?

-------------

PR: https://git.openjdk.org/jdk/pull/12579

From rriggs at openjdk.org  Thu Feb 16 20:58:27 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 16 Feb 2023 20:58:27 GMT
Subject: RFR: 8301627: System.exit and Runtime.exit debug logging [v4]
In-Reply-To: <gc5GudGVxSv91oWgw0xMp8CWmJ1Xk2PNm0H7jK0FDXM=.e4d91043-d905-46db-9da9-917cec7c9787@github.com>
References: <OzJeJH5yxolKPChcUisqtzGYF_MU3oOJdx6HPhsXjBw=.15eefe39-efe1-433e-a6ac-02b4a730f264@github.com>
 <2zbWTodXVENcsxo-J5IcBLxQoHqnIdtmB4TnV5w7Uag=.d4aa5964-5e0e-41b5-b6f9-39f4edb1b2b4@github.com>
 <fpoG44CoHxj8JXmx6ry-xdQK2HFfj02RBdT3S9NrIs0=.cdf07271-43a0-4fc4-a10e-545ed4e92492@github.com>
 <-9o7wGKkaBfP4CC_Hq0pkq5GxWBmPNgloyCsC_J5198=.b02971fc-2d28-4c9c-8450-9b626371e5bc@github.com>
 <gc5GudGVxSv91oWgw0xMp8CWmJ1Xk2PNm0H7jK0FDXM=.e4d91043-d905-46db-9da9-917cec7c9787@github.com>
Message-ID: <iIbXgFYXrjI7FvakHjXhWbUsvGEnMmNfYKvr9j_AJME=.b7c4dec7-147f-4819-bb81-9f73ef522883@github.com>

On Tue, 14 Feb 2023 13:10:41 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Roger has updated this but it's still a comment on a non-public class. I think the main question here is whether there should be a note in the System.exit and Runtime.exit to document that these methods log? If not, will it be documented anywhere, maybe a troubleshooting guide to help track down what/who is calling System.exit?
>
> Another way to document that could be to add the commented logger name, and  a comment, to https://github.com/openjdk/jdk/blob/master/src/java.logging/share/conf/logging.properties 
> A new section at the end with some explanation on what this logger prints and how to enable it - with the appropriate wording to make it clear that it's JDK-implementation specific and not part of the spec.

I opted to add an @implNote in java.lang.Runtime.exit(). And create the corresponding CSR.

-------------

PR: https://git.openjdk.org/jdk/pull/12517

From rriggs at openjdk.org  Thu Feb 16 20:58:29 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 16 Feb 2023 20:58:29 GMT
Subject: RFR: 8301627: System.exit and Runtime.exit debug logging [v4]
In-Reply-To: <fpoG44CoHxj8JXmx6ry-xdQK2HFfj02RBdT3S9NrIs0=.cdf07271-43a0-4fc4-a10e-545ed4e92492@github.com>
References: <OzJeJH5yxolKPChcUisqtzGYF_MU3oOJdx6HPhsXjBw=.15eefe39-efe1-433e-a6ac-02b4a730f264@github.com>
 <2zbWTodXVENcsxo-J5IcBLxQoHqnIdtmB4TnV5w7Uag=.d4aa5964-5e0e-41b5-b6f9-39f4edb1b2b4@github.com>
 <fpoG44CoHxj8JXmx6ry-xdQK2HFfj02RBdT3S9NrIs0=.cdf07271-43a0-4fc4-a10e-545ed4e92492@github.com>
Message-ID: <kQJivLrZzHovSdfxB8lZa5gCtsJlnAwXreoeOLZfD8A=.3487a6d9-4432-42ca-b71a-0642efc82601@github.com>

On Mon, 13 Feb 2023 11:02:14 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> test/jdk/java/lang/runtime/RuntimeExitLogTest.java line 89:
>> 
>>> 87:         }
>>> 88:         cmd.add(this.getClass().getName());
>>> 89:         cmd.add(Integer.toString(status));
>> 
>> Another possibility for testing this is to launch with ` --limit-modules java.base -Djdk.system.logger.level=DEBUG` to use the simple console implementation that is in java.base and avoid needing properties files for j.u.logging. Just mentioning is an option to make it simple.
>
> Good point - though maybe both configurations should be tested. The j.u.l.LogManager registers some shutdown hook so I believe it's important to test with j.u.l present too.

Added a test of the console config with --limit-modules as suggested.

-------------

PR: https://git.openjdk.org/jdk/pull/12517

From rriggs at openjdk.org  Thu Feb 16 21:05:29 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 16 Feb 2023 21:05:29 GMT
Subject: RFR: 8301627: System.exit and Runtime.exit debug logging [v4]
In-Reply-To: <urHmEdJ8jXZQNdL6FiTKipTl3QTmtOg5N9af7CFIam0=.87e18e2e-64bb-48e2-8411-56c27baf0bae@github.com>
References: <OzJeJH5yxolKPChcUisqtzGYF_MU3oOJdx6HPhsXjBw=.15eefe39-efe1-433e-a6ac-02b4a730f264@github.com>
 <S8S5gyxRG8WS_GbA0zrJPhXIxv6yReejyxgfc_FqBBQ=.eb6b1794-0f21-4292-ac7a-34e7d001f6b1@github.com>
 <urHmEdJ8jXZQNdL6FiTKipTl3QTmtOg5N9af7CFIam0=.87e18e2e-64bb-48e2-8411-56c27baf0bae@github.com>
Message-ID: <juwbKEW4d_sFddVzJKg2CHdEvQu_lDyBQYf0KFfdhb0=.c7e05ffd-abb7-4b43-ad69-e8ee3c5e8699@github.com>

On Thu, 16 Feb 2023 16:52:14 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Correct System.getLogger link
>
> src/java.base/share/classes/java/lang/Runtime.java line 160:
> 
>> 158:      *
>> 159:      * @implNote
>> 160:      * If the {@link System#getLogger(String) System.getLogger("java.lang.Runtime")}
> 
> It may read better to use a textual description for the link, like "the system logger for `java.lang.Runtime`".

ok, will fix.

-------------

PR: https://git.openjdk.org/jdk/pull/12517

From rriggs at openjdk.org  Thu Feb 16 21:05:30 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 16 Feb 2023 21:05:30 GMT
Subject: RFR: 8301627: System.exit and Runtime.exit debug logging [v4]
In-Reply-To: <UeWqWTWg1dZgVBjyqz6bvI6K1XM-ghRM_IiJ0Bt5qH0=.5aa17ff2-196b-4dc9-9175-602f32ebc9c2@github.com>
References: <OzJeJH5yxolKPChcUisqtzGYF_MU3oOJdx6HPhsXjBw=.15eefe39-efe1-433e-a6ac-02b4a730f264@github.com>
 <S8S5gyxRG8WS_GbA0zrJPhXIxv6yReejyxgfc_FqBBQ=.eb6b1794-0f21-4292-ac7a-34e7d001f6b1@github.com>
 <UeWqWTWg1dZgVBjyqz6bvI6K1XM-ghRM_IiJ0Bt5qH0=.5aa17ff2-196b-4dc9-9175-602f32ebc9c2@github.com>
Message-ID: <pcKSNNs_4UH8lMzyajVN1Zna1128iHSiwtnclVSB1Cw=.5b5cd29d-950e-4928-a3c1-671d5634a950@github.com>

On Tue, 14 Feb 2023 19:02:52 GMT, Stuart Marks <smarks at openjdk.org> wrote:

>> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Correct System.getLogger link
>
> src/java.base/share/classes/java/lang/Shutdown.java line 168:
> 
>> 166:                 Throwable throwable = new Throwable("Runtime.exit(" + status + ")");
>> 167:                 log.log(System.Logger.Level.DEBUG, "Runtime.exit() called with status: " + status,
>> 168:                         throwable);
> 
> I'd put a try/catch around the actual logging of the message, to avoid a situation where an error in the logger handler prevents the system from being shut down.

If there is an error in the logging, it should not be hidden so it can be fixed by the developer or logging configuration.
A mis-configured or malfunctioning logging system might hide more than just this particular case.

-------------

PR: https://git.openjdk.org/jdk/pull/12517

From rriggs at openjdk.org  Thu Feb 16 21:53:00 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 16 Feb 2023 21:53:00 GMT
Subject: RFR: 8301627: System.exit and Runtime.exit debug logging [v5]
In-Reply-To: <OzJeJH5yxolKPChcUisqtzGYF_MU3oOJdx6HPhsXjBw=.15eefe39-efe1-433e-a6ac-02b4a730f264@github.com>
References: <OzJeJH5yxolKPChcUisqtzGYF_MU3oOJdx6HPhsXjBw=.15eefe39-efe1-433e-a6ac-02b4a730f264@github.com>
Message-ID: <-WX4sORgC6ML_rXmQLArPbpKD0qFVDUtUwdHkOmSShQ=.c1e1666d-8a6e-412f-829a-f251abb853a6@github.com>

> It can be difficult to find the cause of calls to `java.lang.System.exit(status)` and `Runtime.exit(status)` because the Java runtime exits.
> The status value and stack trace are logged using the System Logger named `java.lang.Runtime` with message level `System.Logger.Level.DEBUG`.

Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:

  Improve implNote for Runtime.exit() with review suggestions.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12517/files
  - new: https://git.openjdk.org/jdk/pull/12517/files/60123543..a31645c1

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12517&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12517&range=03-04

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/12517.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12517/head:pull/12517

PR: https://git.openjdk.org/jdk/pull/12517

From bpb at openjdk.org  Thu Feb 16 23:10:43 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 16 Feb 2023 23:10:43 GMT
Subject: RFR: JDK-8302028: Port fdlibm atan2 to Java
In-Reply-To: <xl79M-V4_2t49GuCudJHQBaJjAcwWl9f2Bv19RbAmdo=.b9c97066-8cf4-4569-8b4b-8b4874e23833@github.com>
References: <xl79M-V4_2t49GuCudJHQBaJjAcwWl9f2Bv19RbAmdo=.b9c97066-8cf4-4569-8b4b-8b4874e23833@github.com>
Message-ID: <NFCspFqCUeUW8w0P6bcYLvxtoIyGRcU02UFPVqIhh1o=.3d935a63-dcdd-4f6d-ab63-4767c03aadc0@github.com>

On Thu, 16 Feb 2023 19:30:06 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Working down the porting list, next stop, atan2.

The port looks reasonable to me.

-------------

PR: https://git.openjdk.org/jdk/pull/12608

From duke at openjdk.org  Thu Feb 16 23:10:48 2023
From: duke at openjdk.org (ExE Boss)
Date: Thu, 16 Feb 2023 23:10:48 GMT
Subject: RFR: 8292914: Drop the counter from lambda class names [v6]
In-Reply-To: <QdLVD35_eLVsA_nbpnGwRKcSR08HwCDpFAK3WpmiIUU=.3dd5ef57-0c63-4d0d-8fe6-cb924a5c2a9f@github.com>
References: <GgLfH-ueBQqT-Mfk1mKpKFAt8fYqyjfVJ9lmlsBsCbo=.8dd5b3b4-4e84-4970-9179-1c0399b30edc@github.com>
 <zlDm2W50G6NgRkzmgEpX6MTVs3XyYMnY3tN1YnObWUA=.03a3d8d7-4d20-4fc6-8028-b20a8603b0a6@github.com>
 <MJ_UIR-6jJ9IqFPL9KqiZtnZKg1D-WRYVpPdYShvm7Y=.62eb1a11-52c2-4c6a-a3a7-9716d7daaf86@github.com>
 <QdLVD35_eLVsA_nbpnGwRKcSR08HwCDpFAK3WpmiIUU=.3dd5ef57-0c63-4d0d-8fe6-cb924a5c2a9f@github.com>
Message-ID: <RwiiUOJW9UgONuVzMU-Pyh5VSnA7tIwlr4-9_T_tE_0=.4c02d654-7760-4e91-b11e-f5cf9ba484ac@github.com>

On Thu, 16 Feb 2023 20:02:36 GMT, David M. Lloyd <duke at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/invoke/ProxyClassesDumper.java line 124:
>> 
>>> 122:             }
>>> 123:         }
>>> 124:         sb.append(counter.incrementAndGet());
>> 
>> Suggestion:
>> 
>>         sb.append('$').append(counter.incrementAndGet());
>
> The Lamdba class name already ends in `$` - is there a reason we'd need a second one when dumping?

I?suggested removing?it?in: https://github.com/openjdk/jdk/pull/12579#discussion_r1108941733

-------------

PR: https://git.openjdk.org/jdk/pull/12579

From bpb at openjdk.org  Thu Feb 16 23:12:08 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 16 Feb 2023 23:12:08 GMT
Subject: RFR: JDK-8301444: Port fdlibm hyperbolic transcendental functions
 to Java [v11]
In-Reply-To: <iExziGQ9TM4S7gQ57H1fIF-bjSGeoIOEupjqJtjENc4=.e7d3729f-4e19-42ad-9fdb-10467477d3a8@github.com>
References: <_s8xnppoDTnAajAjlmfB-dX5DBdawUcSSPaGWGLzFBk=.cdbf468a-ace7-45e5-a25a-833c760b776c@github.com>
 <iExziGQ9TM4S7gQ57H1fIF-bjSGeoIOEupjqJtjENc4=.e7d3729f-4e19-42ad-9fdb-10467477d3a8@github.com>
Message-ID: <J1QQLwuHSP_siGV19nqfRgC1s4JWr3xvOImAOuNX8lQ=.07fc61c6-66b0-470c-b8c6-4b2b986eb338@github.com>

On Wed, 15 Feb 2023 22:44:40 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Initial pass of porting FDLIBM sinh/cosh/tanh to Java. I do intend to refactor the regression tests a bit to reduce duplication, but the actual ports should be ready for review.
>> 
>> Diff'ing the ports as before, original vs transliteration port:
>> 
>> 
>> $ diff -w Hyperbolic.c Hyperbolic.translit.java
>> 1c1
>> < /* __ieee754_sinh(x)
>> ---
>>>     /**
>> 17a18,19
>>>     static class Sinh {
>>>         private static final double one = 1.0, shuge = 1.0e307;
>> 19,33c21
>> < #include "fdlibm.h"
>> < 
>> < #ifdef __STDC__
>> < static const double one = 1.0, shuge = 1.0e307;
>> < #else
>> < static double one = 1.0, shuge = 1.0e307;
>> < #endif
>> < 
>> < #ifdef __STDC__
>> <         double __ieee754_sinh(double x)
>> < #else
>> <         double __ieee754_sinh(x)
>> <         double x;
>> < #endif
>> < {
>> ---
>>>         private static double compute(double x) {
>> 36c24
>> <         unsigned lx;
>> ---
>>>             /* unsigned */ int lx;
>> 51c39
>> <             t = expm1(fabs(x));
>> ---
>>>                 t = FdlibmTranslit.expm1(Math.abs(x));
>> 57c45
>> <         if (ix < 0x40862E42)  return h*__ieee754_exp(fabs(x));
>> ---
>>>             if (ix < 0x40862E42)  return h*StrictMath.exp(Math.abs(x)); // TODO switch to translit
>> 60,62c48,52
>> <         lx = *( (((*(unsigned*)&one)>>29)) + (unsigned*)&x);
>> <         if (ix<0x408633CE || ((ix==0x408633ce)&&(lx<=(unsigned)0x8fb9f87d))) {
>> <             w = __ieee754_exp(0.5*fabs(x));
>> ---
>>>             // lx = *( (((*(unsigned*)&one)>>29)) + (unsigned*)&x);
>>>             // lx =  (((*(unsigned*)&one)>>29)) + (unsigned*)&x ;
>>>             lx = __LO(x);
>>>             if (ix<0x408633CE || ((ix==0x408633ce)&&(Long.compareUnsigned(lx, 0x8fb9f87d) <= 0 ))) {
>>>                 w = StrictMath.exp(0.5*Math.abs(x)); // TODO switch to translit
>> 70c60,62
>> < /* __ieee754_cosh(x)
>> ---
>>>     }
>>> 
>>>     /**
>> 90,105c82,84
>> < 
>> < #include "fdlibm.h"
>> < 
>> < #ifdef __STDC__
>> < static const double one = 1.0, half=0.5, huge = 1.0e300;
>> < #else
>> < static double one = 1.0, half=0.5, huge = 1.0e300;
>> < #endif
>> < 
>> < #ifdef __STDC__
>> <         double __ieee754_cosh(double x)
>> < #else
>> <         double __ieee754_cosh(x)
>> <         double x;
>> < #endif
>> < {
>> ---
>>>     static class Cosh {
>>>         private static final double one = 1.0, half=0.5, huge = 1.0e300;
>>>         private static double compute(double x) {
>> 108c87
>> <         unsigned lx;
>> ---
>>>             /*unsigned*/ int lx;
>> 119c98
>> <             t = expm1(fabs(x));
>> ---
>>>                 t = expm1(Math.abs(x));
>> 127c106
>> <                 t = __ieee754_exp(fabs(x));
>> ---
>>>                 t = StrictMath.exp(Math.abs(x)); // TODO switch to translit
>> 132c111
>> <         if (ix < 0x40862E42)  return half*__ieee754_exp(fabs(x));
>> ---
>>>             if (ix < 0x40862E42)  return half*StrictMath.exp(Math.abs(x)); // TODO switch to translit
>> 135c114
>> <         lx = *( (((*(unsigned*)&one)>>29)) + (unsigned*)&x);
>> ---
>>>             lx = __LO(x);
>> 137,138c116,117
>> <               ((ix==0x408633ce)&&(lx<=(unsigned)0x8fb9f87d))) {
>> <             w = __ieee754_exp(half*fabs(x));
>> ---
>>>                 ((ix==0x408633ce)&&(Integer.compareUnsigned(lx, 0x8fb9f87d) <= 0))) {
>>>                 w = StrictMath.exp(half*Math.abs(x)); // TODO switch to translit
>> 146c125,127
>> < /* Tanh(x)
>> ---
>>>     }
>>> 
>>>     /**
>> 169,184c150,152
>> < 
>> < #include "fdlibm.h"
>> < 
>> < #ifdef __STDC__
>> < static const double one=1.0, two=2.0, tiny = 1.0e-300;
>> < #else
>> < static double one=1.0, two=2.0, tiny = 1.0e-300;
>> < #endif
>> < 
>> < #ifdef __STDC__
>> <         double tanh(double x)
>> < #else
>> <         double tanh(x)
>> <         double x;
>> < #endif
>> < {
>> ---
>>>     static class Tanh {
>>>         private static final double one=1.0, two=2.0, tiny = 1.0e-300;
>>>         static double compute(double x) {
>> 203c171
>> <                 t = expm1(two*fabs(x));
>> ---
>>>                     t = expm1(two*Math.abs(x));
>> 206c174
>> <                 t = expm1(-two*fabs(x));
>> ---
>>>                     t = expm1(-two*Math.abs(x));
>> 214a183
>>>     }
>> 
>> 
>> Note that the original has a in-line version of the "__LO" macro rather than using the macro.
>> 
>> 
>> And transliteration vs more idiomatic:
>> 
>> 
>> $ diff -w Hyperbolic.translit.java Hyperbolic.fdlibm.java 
>> 21c21
>> <         private static double compute(double x) {
>> ---
>>>          static double compute(double x) {
>> 26c26
>> <             /* High word of |x|. */
>> ---
>>>             // High word of |x|
>> 28c28
>> <             ix = jx&0x7fffffff;
>> ---
>>>             ix = jx & 0x7fff_ffff;
>> 30,31c30,33
>> <             /* x is INF or NaN */
>> <             if(ix>=0x7ff00000) return x+x;
>> ---
>>>             // x is INF or NaN
>>>             if ( ix >= 0x7ff0_0000) {
>>>                 return x + x;
>>>             }
>> 34,40c36,48
>> <             if (jx<0) h = -h;
>> <             /* |x| in [0,22], return sign(x)*0.5*(E+E/(E+1))) */
>> <             if (ix < 0x40360000) {          /* |x|<22 */
>> <                 if (ix<0x3e300000)          /* |x|<2**-28 */
>> <                     if(shuge+x>one) return x;/* sinh(tiny) = tiny with inexact */
>> <                 t = FdlibmTranslit.expm1(Math.abs(x));
>> <                 if(ix<0x3ff00000) return h*(2.0*t-t*t/(t+one));
>> ---
>>>             if ( jx < 0) {
>>>                 h = -h;
>>>             }
>>>             // |x| in [0,22], return sign(x)*0.5*(E+E/(E+1)))
>>>             if (ix < 0x4036_0000) {          // |x| < 22
>>>                 if (ix < 0x3e30_0000)        // |x| < 2**-28
>>>                     if (shuge + x > one) {   // sinh(tiny) = tiny with inexact
>>>                         return x;
>>>                     }
>>>                 t = StrictMath.expm1(Math.abs(x));
>>>                 if (ix < 0x3ff0_0000) {
>>>                     return h*(2.0 * t - t*t/(t + one));
>>>                 }
>> 44,45c52,55
>> <             /* |x| in [22, log(maxdouble)] return 0.5*exp(|x|) */
>> <             if (ix < 0x40862E42)  return h*StrictMath.exp(Math.abs(x)); // TODO switch to translit
>> ---
>>>             // |x| in [22, log(maxdouble)] return 0.5*exp(|x|)
>>>             if (ix < 0x4086_2E42) {
>>>                 return h*StrictMath.exp(Math.abs(x));
>>>             }
>> 47,49c57
>> <             /* |x| in [log(maxdouble), overflowthresold] */
>> <             // lx = *( (((*(unsigned*)&one)>>29)) + (unsigned*)&x);
>> <             // lx =  (((*(unsigned*)&one)>>29)) + (unsigned*)&x ;
>> ---
>>>             // |x| in [log(maxdouble), overflowthresold]
>> 51,52c59,62
>> <             if (ix<0x408633CE || ((ix==0x408633ce)&&(Long.compareUnsigned(lx, 0x8fb9f87d) <= 0 ))) {
>> <                 w = StrictMath.exp(0.5*Math.abs(x)); // TODO switch to translit
>> ---
>>>             if (ix < 0x4086_33CE ||
>>>                 ((ix == 0x4086_33ce) &&
>>>                  (Long.compareUnsigned(lx, 0x8fb9_f87d) <= 0 ))) {
>>>                 w = StrictMath.exp(0.5 * Math.abs(x));
>> 57c67
>> <             /* |x| > overflowthresold, sinh(x) overflow */
>> ---
>>>             // |x| > overflowthresold, sinh(x) overflow
>> 84c94
>> <         private static double compute(double x) {
>> ---
>>>         static double compute(double x) {
>> 89c99
>> <             /* High word of |x|. */
>> ---
>>>             // High word of |x|
>> 91c101
>> <             ix &= 0x7fffffff;
>> ---
>>>             ix &= 0x7fff_ffff;
>> 93,94c103,106
>> <             /* x is INF or NaN */
>> <             if(ix>=0x7ff00000) return x*x;
>> ---
>>>             // x is INF or NaN
>>>             if (ix >= 0x7ff_00000) {
>>>                 return x*x;
>>>             }
>> 96,98c108,110
>> <             /* |x| in [0,0.5*ln2], return 1+expm1(|x|)^2/(2*exp(|x|)) */
>> <             if(ix<0x3fd62e43) {
>> <                 t = expm1(Math.abs(x));
>> ---
>>>             // |x| in [0,0.5*ln2], return 1+expm1(|x|)^2/(2*exp(|x|))
>>>             if (ix < 0x3fd6_2e43) {
>>>                 t = StrictMath.expm1(Math.abs(x));
>> 100c112,114
>> <                 if (ix<0x3c800000) return w;        /* cosh(tiny) = 1 */
>> ---
>>>                 if (ix < 0x3c80_0000) { // cosh(tiny) = 1
>>>                     return w;
>>>                 }
>> 104,106c118,120
>> <             /* |x| in [0.5*ln2,22], return (exp(|x|)+1/exp(|x|)/2; */
>> <             if (ix < 0x40360000) {
>> <                 t = StrictMath.exp(Math.abs(x)); // TODO switch to translit
>> ---
>>>             // |x| in [0.5*ln2, 22], return (exp(|x|) + 1/exp(|x|)/2
>>>             if (ix < 0x4036_0000) {
>>>                 t = StrictMath.exp(Math.abs(x));
>> 110,111c124,127
>> <             /* |x| in [22, log(maxdouble)] return half*exp(|x|) */
>> <             if (ix < 0x40862E42)  return half*StrictMath.exp(Math.abs(x)); // TODO switch to translit
>> ---
>>>             // |x| in [22, log(maxdouble)] return half*exp(|x|)
>>>             if (ix < 0x4086_2E42) {
>>>                 return half*StrictMath.exp(Math.abs(x));
>>>             }
>> 113c129
>> <             /* |x| in [log(maxdouble), overflowthresold] */
>> ---
>>>             // |x| in [log(maxdouble), overflowthresold]
>> 115,117c131,134
>> <             if (ix<0x408633CE ||
>> <                 ((ix==0x408633ce)&&(Integer.compareUnsigned(lx, 0x8fb9f87d) <= 0))) {
>> <                 w = StrictMath.exp(half*Math.abs(x)); // TODO switch to translit
>> ---
>>>             if (ix<0x4086_33CE ||
>>>                 ((ix == 0x4086_33ce) &&
>>>                  (Integer.compareUnsigned(lx, 0x8fb9_f87d) <= 0))) {
>>>                 w = StrictMath.exp(half*Math.abs(x));
>> 122c139
>> <             /* |x| > overflowthresold, cosh(x) overflow */
>> ---
>>>             // |x| > overflowthresold, cosh(x) overflow
>> 126d142
>> < 
>> 156c172
>> <             /* High word of |x|. */
>> ---
>>>             // High word of |x|.
>> 158c174
>> <             ix = jx&0x7fffffff;
>> ---
>>>             ix = jx & 0x7fff_ffff;
>> 160,163c176,182
>> <             /* x is INF or NaN */
>> <             if(ix>=0x7ff00000) {
>> <                 if (jx>=0) return one/x+one;    /* tanh(+-inf)=+-1 */
>> <                 else       return one/x-one;    /* tanh(NaN) = NaN */
>> ---
>>>             // x is INF or NaN
>>>             if (ix >= 0x7ff0_0000) {
>>>                 if (jx >= 0) {  // tanh(+-inf)=+-1
>>>                     return one/x + one;
>>>                 } else {        // tanh(NaN) = NaN
>>>                     return one/x - one;
>>>                 }
>> 166,171c185,190
>> <             /* |x| < 22 */
>> <             if (ix < 0x40360000) {          /* |x|<22 */
>> <                 if (ix<0x3c800000)          /* |x|<2**-55 */
>> <                     return x*(one+x);       /* tanh(small) = small */
>> <                 if (ix>=0x3ff00000) {       /* |x|>=1  */
>> <                     t = expm1(two*Math.abs(x));
>> ---
>>>             // |x| < 22
>>>             if (ix < 0x4036_0000) {          // |x| < 22
>>>                 if (ix<0x3c80_0000)          // |x| < 2**-55
>>>                     return x*(one + x);      // tanh(small) = small
>>>                 if (ix>=0x3ff0_0000) {       // |x| >= 1
>>>                     t = StrictMath.expm1(two*Math.abs(x));
>> 174c193
>> <                     t = expm1(-two*Math.abs(x));
>> ---
>>>                     t = StrictMath.expm1(-two*Math.abs(x));
>> 177,179c196,197
>> <                 /* |x| > 22, return +-1 */
>> <             } else {
>> <                 z = one - tiny;             /* raised inexact flag */
>> ---
>>>             } else { // |x| > 22, return +-1
>>>                 z = one - tiny;             // raised inexact flag
>
> Joe Darcy 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 JDK-8301444
>  - Refactor regression test.
>  - Small refactorings in Fdlibm.java
>  - Remove unnecessary semicolons.
>  - Add exhausting test coverage.
>  - Merge branch 'master' into JDK-8301444
>  - Merge branch 'master' into JDK-8301444
>  - Improve exp usage.
>  - Add additional note.
>  - Respond to review feedback.
>  - ... and 4 more: https://git.openjdk.org/jdk/compare/3ba15608...3c4e1812

Approved.

-------------

Marked as reviewed by bpb (Reviewer).

PR: https://git.openjdk.org/jdk/pull/12429

From psandoz at openjdk.org  Thu Feb 16 23:12:34 2023
From: psandoz at openjdk.org (Paul Sandoz)
Date: Thu, 16 Feb 2023 23:12:34 GMT
Subject: RFR: JDK-8302666: Replace CHM with VarHandle in ForeachOrderedTask
In-Reply-To: <Xwk3XgU2boNqaROJFPVpvCJ39XgJqvoPIiRwcHcVha8=.91288345-f142-4a4d-ae31-d6df9c9e5754@github.com>
References: <HAgE8xmpZT_2-b5ZDr8TgJNgjhVb3D4ZS3sQqA7c6Mo=.389fa590-681c-44a9-9823-8f70a6129797@github.com>
 <Cgw-lNDkAD_TkUSehGq35yzULSGMA54hoT6jiKNFWjk=.1b1f80bb-be96-45b2-995b-1f61c21187b1@github.com>
 <Xwk3XgU2boNqaROJFPVpvCJ39XgJqvoPIiRwcHcVha8=.91288345-f142-4a4d-ae31-d6df9c9e5754@github.com>
Message-ID: <WuLdW53Fz4HdtzyaUlAdrOx8pwk_1MxuAFiYV9mJyUk=.81e9a8a0-78b1-474f-9444-fba99d90d0c5@github.com>

On Thu, 16 Feb 2023 19:44:35 GMT, Viktor Klang <duke at openjdk.org> wrote:

>> src/java.base/share/classes/java/util/stream/ForEachOps.java line 431:
>> 
>>> 429:                 // leftChild and rightChild were just created and not fork():ed
>>> 430:                 // yet so no need for a volatile write
>>> 431:                 NEXT.set(leftChild, rightChild);
>> 
>> Make `next` a plain field and shuffle up the assignment (`leftChild.next = rightChild`) to occur immediately after construction of the right child task? (FWIW `addToPendingCount` operates on a volatile field of `CountedCompleter`).
>
> @PaulSandoz I'm usually a bit weary of piggybacking if it is not done on the same object, as future reorderings of the code might break that assumption. I wouldn't want to break anything silently so I made a rather conservative change. On which side should I err? :)

Since as you have said the left and right nodes have yet to be "published" (outside of their little nest) I think it should be fine to move it above and next to the constructions.
(Also since `addToPendingCount` has volatile write semantics, via it's getAndSet, the plain write should not float below that call if that really matters, and its hard to see the code radically changing in this regard unless there is a major rewrite than i guess it all has to be carefully rethought.)

-------------

PR: https://git.openjdk.org/jdk/pull/12320

From igraves at openjdk.org  Thu Feb 16 23:15:38 2023
From: igraves at openjdk.org (Ian Graves)
Date: Thu, 16 Feb 2023 23:15:38 GMT
Subject: RFR: 8293667: Align jlink's --compress option with jmod's
 --compress option [v9]
In-Reply-To: <JWevwHuR2vF3k-JRxmTAxfNN6g-EBkgG2N9DHn4fkGY=.f9768dfd-cab4-49a9-83b9-d77a1572e917@github.com>
References: <JWevwHuR2vF3k-JRxmTAxfNN6g-EBkgG2N9DHn4fkGY=.f9768dfd-cab4-49a9-83b9-d77a1572e917@github.com>
Message-ID: <OjnRaZmWra2iE7PXRJG6PRB2p0lLVsgsGsWdV1pufUA=.f1bb8159-f38a-48e4-907f-e82e1b1c4a9f@github.com>

> This is an approach to adding a flag to jlink that will allow --compress to take the same types of arguments as jmod, thus bringing the two into alignment. This likely requires a CSR and a discussion on whether we should deprecate or simply remove the original numeric compression arguments.

Ian Graves has updated the pull request incrementally with one additional commit since the last revision:

  Additional updates

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/11617/files
  - new: https://git.openjdk.org/jdk/pull/11617/files/c9f4f32b..a9a4d4f0

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11617&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11617&range=07-08

  Stats: 27 lines in 4 files changed: 6 ins; 16 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/11617.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11617/head:pull/11617

PR: https://git.openjdk.org/jdk/pull/11617

From mchung at openjdk.org  Thu Feb 16 23:15:53 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Thu, 16 Feb 2023 23:15:53 GMT
Subject: RFR: 8293667: Align jlink's --compress option with jmod's
 --compress option [v9]
In-Reply-To: <OjnRaZmWra2iE7PXRJG6PRB2p0lLVsgsGsWdV1pufUA=.f1bb8159-f38a-48e4-907f-e82e1b1c4a9f@github.com>
References: <JWevwHuR2vF3k-JRxmTAxfNN6g-EBkgG2N9DHn4fkGY=.f9768dfd-cab4-49a9-83b9-d77a1572e917@github.com>
 <OjnRaZmWra2iE7PXRJG6PRB2p0lLVsgsGsWdV1pufUA=.f1bb8159-f38a-48e4-907f-e82e1b1c4a9f@github.com>
Message-ID: <KROkvc-sXqvRTusiF06EHqrbW0pt7yoQN6oB6TkCpPI=.de6cdbf2-adc1-41df-809c-82ba164330bd@github.com>

On Thu, 16 Feb 2023 23:07:13 GMT, Ian Graves <igraves at openjdk.org> wrote:

>> This is an approach to adding a flag to jlink that will allow --compress to take the same types of arguments as jmod, thus bringing the two into alignment. This likely requires a CSR and a discussion on whether we should deprecate or simply remove the original numeric compression arguments.
>
> Ian Graves has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Additional updates

This change also impacts runtime.  Is it possible to add a test that runs jlink to create a custom image that uses some compression level and run the compressed resources in the custom image.

src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/DefaultCompressPlugin.java line 95:

> 93:             switch (level) {
> 94:                 case LEVEL_0:
> 95:                     System.err.println("warning - the \"0\" value for --compress has been deprecated and " +

I expect this be a localized message, e.g. add to plugins.properties.   You can call AbstractPlugin::getMessage` to get the message from the resource bundle.  This one should be consistent with the existing convention but unfortunately the existing warning messages are not consistent - prefixing with "Warning:" or "WARNING:".

-------------

PR: https://git.openjdk.org/jdk/pull/11617

From igraves at openjdk.org  Thu Feb 16 23:16:06 2023
From: igraves at openjdk.org (Ian Graves)
Date: Thu, 16 Feb 2023 23:16:06 GMT
Subject: RFR: 8293667: Align jlink's --compress option with jmod's
 --compress option
In-Reply-To: <7azCDfhh8pLeQtPfhvwoiUrNF0QlnjP7NuVkoKJurYs=.0e7d23a0-554c-49d0-99c1-adc71f9046f7@github.com>
References: <JWevwHuR2vF3k-JRxmTAxfNN6g-EBkgG2N9DHn4fkGY=.f9768dfd-cab4-49a9-83b9-d77a1572e917@github.com>
 <3qBQbDWN99tyr32fbrT86WixwxSPzA235ISVqt70f5I=.b6202387-ed59-4124-809e-58771ed5bffa@github.com>
 <7azCDfhh8pLeQtPfhvwoiUrNF0QlnjP7NuVkoKJurYs=.0e7d23a0-554c-49d0-99c1-adc71f9046f7@github.com>
Message-ID: <otJQr1k-cHrDZ7kE2jGIJMbsNKIEhNeN0an6wRPA5Z8=.f1ad858c-9774-4fec-bcf5-c050c0c63683@github.com>

On Mon, 9 Jan 2023 21:38:59 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> I skimmed through this (not a detailed review) and I think it's mostly okay. It's --compress 0 and 2 that should be listed as deprecated as --compress 1 is string sharing rather than zip compression.
>
>> I skimmed through this (not a detailed review) and I think it's mostly okay. It's --compress 0 and 2 that should be listed as deprecated as --compress 1 is string sharing rather than zip compression.
> 
> I also think it's good to deprecate the old values.   I think we can separate the StringSharingPlugin as a separate plugin option (e.g. `--compact-constant-pools`) and deprecate --compress 1 as well.   Something like this:
> 
> 
>   --compress <compress>               Compression to use in compressing resources:
>                                         Accepted values are:  
>                                         zip-[0-9], where zip-0 provides no  
>                                         compression, and zip-9 provides the 
>                                         best compression. Default is zip-6.
>                                         Deprecated values:
>                                         0:  No compression. Equivalent to zip-0.
>                                         1:  Equivalent to --compact-constant-pools
>                                         2:  Equivalent to zip-6.

Added additional changes per @mlchung 's suggestions. Thanks!

-------------

PR: https://git.openjdk.org/jdk/pull/11617

From mchung at openjdk.org  Thu Feb 16 23:16:17 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Thu, 16 Feb 2023 23:16:17 GMT
Subject: RFR: 8293667: Align jlink's --compress option with jmod's
 --compress option [v2]
In-Reply-To: <90W6AVU6RNPg3e3UgscPlDJGT2rUaVkduOmuoI8pOJU=.c35ea283-c399-4fda-9e60-3a1b679791ec@github.com>
References: <JWevwHuR2vF3k-JRxmTAxfNN6g-EBkgG2N9DHn4fkGY=.f9768dfd-cab4-49a9-83b9-d77a1572e917@github.com>
 <L0YQ-HpkzstQ-kaNwoO3BxLqgcluDK5Lzt8R9c9ZGSs=.637129c6-047c-4197-8ed2-70d0a203ec90@github.com>
 <z4Lh3mo4wSeVY8LS-NSPsEdCKnBGNmzBkIRKtpecQl8=.4ff4a5d7-b50f-42a7-9e40-6bd71d37da79@github.com>
 <90W6AVU6RNPg3e3UgscPlDJGT2rUaVkduOmuoI8pOJU=.c35ea283-c399-4fda-9e60-3a1b679791ec@github.com>
Message-ID: <WrMY2LsSoiNiZwxPymGn5TDhns5FRyoMUkb1NDqPTkg=.8411c497-47f8-4834-aeda-ff746024a106@github.com>

On Thu, 15 Dec 2022 07:31:05 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> test/jdk/tools/jlink/plugins/CompressorPluginTest.java line 153:
>> 
>>> 151:         Properties optionsZip0 = new Properties();
>>> 152:         DefaultCompressPlugin compressPluginZip0 = new DefaultCompressPlugin();
>>> 153:         options0.setProperty(compressPluginZip0.getName(), "zip-0");
>> 
>> I suspect this supposed to be `optionsZip0.setProperty(....)` instead of `options0.setProperty(....)`?
>
> I think, there's also a typo in the next line:
> 
> checkCompress(classes, compressPlugin,
> 
> should have been:
> 
> checkCompress(classes, compressPluginZip0,
> 
> I haven't yet looked at the existing test code in `checkCompress` method, but it might need a closer look as to why this test passed. I would have expected it to fail due to the typos.

@jaikiran is right.  This test is to set up `optionsZip0` and `compressPluginZip0` to verify `zip-0`.

-------------

PR: https://git.openjdk.org/jdk/pull/11617

From mchung at openjdk.org  Thu Feb 16 23:16:37 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Thu, 16 Feb 2023 23:16:37 GMT
Subject: RFR: 8293667: Align jlink's --compress option with jmod's
 --compress option [v2]
In-Reply-To: <z4Lh3mo4wSeVY8LS-NSPsEdCKnBGNmzBkIRKtpecQl8=.4ff4a5d7-b50f-42a7-9e40-6bd71d37da79@github.com>
References: <JWevwHuR2vF3k-JRxmTAxfNN6g-EBkgG2N9DHn4fkGY=.f9768dfd-cab4-49a9-83b9-d77a1572e917@github.com>
 <L0YQ-HpkzstQ-kaNwoO3BxLqgcluDK5Lzt8R9c9ZGSs=.637129c6-047c-4197-8ed2-70d0a203ec90@github.com>
 <z4Lh3mo4wSeVY8LS-NSPsEdCKnBGNmzBkIRKtpecQl8=.4ff4a5d7-b50f-42a7-9e40-6bd71d37da79@github.com>
Message-ID: <gc2TXvxMySsokg_xPmxD0SiIuLqOgpMSZuDTUjnBV-4=.45e5289a-ad87-4f18-bf19-d391161fb122@github.com>

On Thu, 15 Dec 2022 07:02:37 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Ian Graves has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Swapping deprecations in properties
>
> test/jdk/tools/jlink/plugins/CompressorPluginTest.java line 203:
> 
>> 201:             if (e.getMessage().contains("Invalid compression level")) {
>> 202:                 return;
>> 203:             }
> 
> Should we print the stacktrace if the message is not the one we expect, to help debug any failures? Or perhaps rethrow the exception to cause the test to fail?

if it matches the expected message, it's okay not to print the stacktrace.  If it does not match, this can simply rethrow instead of line 206 throwing a new exception IMO.

-------------

PR: https://git.openjdk.org/jdk/pull/11617

From duke at openjdk.org  Thu Feb 16 23:26:22 2023
From: duke at openjdk.org (David M. Lloyd)
Date: Thu, 16 Feb 2023 23:26:22 GMT
Subject: RFR: 8292914: Drop the counter from lambda class names [v6]
In-Reply-To: <RwiiUOJW9UgONuVzMU-Pyh5VSnA7tIwlr4-9_T_tE_0=.4c02d654-7760-4e91-b11e-f5cf9ba484ac@github.com>
References: <GgLfH-ueBQqT-Mfk1mKpKFAt8fYqyjfVJ9lmlsBsCbo=.8dd5b3b4-4e84-4970-9179-1c0399b30edc@github.com>
 <zlDm2W50G6NgRkzmgEpX6MTVs3XyYMnY3tN1YnObWUA=.03a3d8d7-4d20-4fc6-8028-b20a8603b0a6@github.com>
 <MJ_UIR-6jJ9IqFPL9KqiZtnZKg1D-WRYVpPdYShvm7Y=.62eb1a11-52c2-4c6a-a3a7-9716d7daaf86@github.com>
 <QdLVD35_eLVsA_nbpnGwRKcSR08HwCDpFAK3WpmiIUU=.3dd5ef57-0c63-4d0d-8fe6-cb924a5c2a9f@github.com>
 <RwiiUOJW9UgONuVzMU-Pyh5VSnA7tIwlr4-9_T_tE_0=.4c02d654-7760-4e91-b11e-f5cf9ba484ac@github.com>
Message-ID: <VV7ciKQAD-9KMX4zNqFa-HiOM-2cZHtUM7OLJG9o6dc=.6e354745-0fe5-4c95-97da-21e53e920c19@github.com>

On Thu, 16 Feb 2023 22:23:09 GMT, ExE Boss <duke at openjdk.org> wrote:

>> The Lamdba class name already ends in `$` - is there a reason we'd need a second one when dumping?
>
> I?suggested removing?it?in: https://github.com/openjdk/jdk/pull/12579#discussion_r1108941733

Ah I missed that. Sure, I guess that's fine.

-------------

PR: https://git.openjdk.org/jdk/pull/12579

From mchung at openjdk.org  Fri Feb 17 03:10:09 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Fri, 17 Feb 2023 03:10:09 GMT
Subject: RFR: 8292914: Drop the counter from lambda class names [v6]
In-Reply-To: <zlDm2W50G6NgRkzmgEpX6MTVs3XyYMnY3tN1YnObWUA=.03a3d8d7-4d20-4fc6-8028-b20a8603b0a6@github.com>
References: <GgLfH-ueBQqT-Mfk1mKpKFAt8fYqyjfVJ9lmlsBsCbo=.8dd5b3b4-4e84-4970-9179-1c0399b30edc@github.com>
 <zlDm2W50G6NgRkzmgEpX6MTVs3XyYMnY3tN1YnObWUA=.03a3d8d7-4d20-4fc6-8028-b20a8603b0a6@github.com>
Message-ID: <QmD1r95Ztib9LqUzkJa6MBeZvgR95EXWBIpsgQt38qg=.7c466759-3ce1-4aa1-b2b4-571cad5c70d3@github.com>

On Thu, 16 Feb 2023 19:35:54 GMT, David M. Lloyd <duke at openjdk.org> wrote:

>> The class generated for lambda proxies is now defined as a hidden class. This means that the counter, which was used to ensure a unique class name and avoid clashes, is now redundant. In addition to performing redundant work, this also impacts build reproducibility for native image generators which might already have a strategy to cope with hidden classes but cannot cope with indeterminate definition order for lambda proxy classes.
>> 
>> This solves JDK-8292914 by making lambda proxy names always be stable without any configuration needed. This would also replace #10024.
>
> David M. Lloyd has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use a unique index for the dumped lambda class instead of a time stamp

`this_class` in the classbyte is shown in the VM logging (`-Xlog:class+nestmates=debug`).  It'd be helpful if it can easily correlate to the dumped file.   For example, 3 lambda proxy classes of the same name of `this_class` but they are unique hidden classes.


0.058s][info ][class,nestmates] LookupDefineClass: jdk/internal/module/DefaultRoots$$Lambda$ - with dynamic nest-host jdk.internal.module.DefaultRoots, hidden, strong, with vm annotations
[0.058s][debug][class,nestmates] Dynamic nestmate: java.base/jdk.internal.module.DefaultRoots$$Lambda$/0x000000080000a970, nest_host jdk.internal.module.DefaultRoots, is hidden
[0.062s][info ][class,nestmates] LookupDefineClass: jdk/internal/module/DefaultRoots$$Lambda$ - with dynamic nest-host jdk.internal.module.DefaultRoots, hidden, strong, with vm annotations
[0.062s][debug][class,nestmates] Dynamic nestmate: java.base/jdk.internal.module.DefaultRoots$$Lambda$/0x000000080000b998, nest_host jdk.internal.module.DefaultRoots, is hidden
[0.068s][info ][class,nestmates] LookupDefineClass: jdk/internal/module/DefaultRoots$$Lambda$ - with dynamic nest-host jdk.internal.module.DefaultRoots, hidden, strong, with vm annotations
[0.068s][debug][class,nestmates] Dynamic nestmate: java.base/jdk.internal.module.DefaultRoots$$Lambda$/0x000000080000c0b0, nest_host jdk.internal.module.DefaultRoots, is hidden


What about keeping your original idea - the filename matching the hidden class name if successfully defined.   If it fails at `defineHiddenClass` time, use `lambdaClassName` + counter? 

Also, `test/jdk/java/lang/StackWalker/VerifyStackTrace.java` tests need update because of the lambda proxy class name change.

-------------

PR: https://git.openjdk.org/jdk/pull/12579

From igraves at openjdk.org  Fri Feb 17 03:13:31 2023
From: igraves at openjdk.org (Ian Graves)
Date: Fri, 17 Feb 2023 03:13:31 GMT
Subject: RFR: 8293667: Align jlink's --compress option with jmod's
 --compress option [v5]
In-Reply-To: <SFOPCZEMPecgMf3zdC9ESgWC4AkUxVDw1H0Q2yYnrug=.cecba3a6-4187-41bb-b898-312482076114@github.com>
References: <JWevwHuR2vF3k-JRxmTAxfNN6g-EBkgG2N9DHn4fkGY=.f9768dfd-cab4-49a9-83b9-d77a1572e917@github.com>
 <A7oOY2Fsic1IQ-nBaDAmShi3CEV_5ZLfJ1BxOWqqhi4=.11e8c2c2-412d-4ee8-afbd-cdd05bc2a6a3@github.com>
 <SFOPCZEMPecgMf3zdC9ESgWC4AkUxVDw1H0Q2yYnrug=.cecba3a6-4187-41bb-b898-312482076114@github.com>
Message-ID: <AFAhyxHyRWRjIZgNoJIuLKwR455wchCIVl2golV71TA=.8b24fa7d-d18e-483e-adc4-27f3832521c6@github.com>

On Wed, 8 Feb 2023 13:27:09 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Ian Graves has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Adding plugin type to force compact strings vs zip ordering
>
> src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/CompactConstantPoolsPlugin.java line 44:
> 
>> 42: public final class CompactConstantPoolsPlugin extends AbstractPlugin implements ResourcePrevisitor {
>> 43: 
>> 44:     private static final String FILTER = "filter";
> 
> Should we perhaps just reference the already `public` `DefaultCompressPlugin.FILTER` field instead of redefining it here?

Good catch. Test is removed but appreciate it!

-------------

PR: https://git.openjdk.org/jdk/pull/11617

From igraves at openjdk.org  Fri Feb 17 03:13:59 2023
From: igraves at openjdk.org (Ian Graves)
Date: Fri, 17 Feb 2023 03:13:59 GMT
Subject: RFR: 8293667: Align jlink's --compress option with jmod's
 --compress option [v9]
In-Reply-To: <KROkvc-sXqvRTusiF06EHqrbW0pt7yoQN6oB6TkCpPI=.de6cdbf2-adc1-41df-809c-82ba164330bd@github.com>
References: <JWevwHuR2vF3k-JRxmTAxfNN6g-EBkgG2N9DHn4fkGY=.f9768dfd-cab4-49a9-83b9-d77a1572e917@github.com>
 <OjnRaZmWra2iE7PXRJG6PRB2p0lLVsgsGsWdV1pufUA=.f1bb8159-f38a-48e4-907f-e82e1b1c4a9f@github.com>
 <KROkvc-sXqvRTusiF06EHqrbW0pt7yoQN6oB6TkCpPI=.de6cdbf2-adc1-41df-809c-82ba164330bd@github.com>
Message-ID: <bs9YRJU8DGv8A7iF8yLGSC6Oi86QJVH6j8xbmp6bW1s=.7c8bee30-955a-4cc7-ac67-e8b390d85bad@github.com>

On Thu, 16 Feb 2023 23:04:30 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> Ian Graves has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Additional updates
>
> src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/DefaultCompressPlugin.java line 95:
> 
>> 93:             switch (level) {
>> 94:                 case LEVEL_0:
>> 95:                     System.err.println("warning - the \"0\" value for --compress has been deprecated and " +
> 
> I expect this be a localized message, e.g. add to plugins.properties.   You can call `AbstractPlugin::getMessage` to get the message from the resource bundle.  This one should be consistent with the existing convention but unfortunately the existing warning messages are not consistent - prefixing with "Warning:" or "WARNING:".

Thanks. I note that there is a non-localized warning done this way elsewhere in jlink. May need to make a bug to localize this.

-------------

PR: https://git.openjdk.org/jdk/pull/11617

From mchung at openjdk.org  Fri Feb 17 03:14:05 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Fri, 17 Feb 2023 03:14:05 GMT
Subject: RFR: 8293667: Align jlink's --compress option with jmod's
 --compress option [v9]
In-Reply-To: <bs9YRJU8DGv8A7iF8yLGSC6Oi86QJVH6j8xbmp6bW1s=.7c8bee30-955a-4cc7-ac67-e8b390d85bad@github.com>
References: <JWevwHuR2vF3k-JRxmTAxfNN6g-EBkgG2N9DHn4fkGY=.f9768dfd-cab4-49a9-83b9-d77a1572e917@github.com>
 <OjnRaZmWra2iE7PXRJG6PRB2p0lLVsgsGsWdV1pufUA=.f1bb8159-f38a-48e4-907f-e82e1b1c4a9f@github.com>
 <KROkvc-sXqvRTusiF06EHqrbW0pt7yoQN6oB6TkCpPI=.de6cdbf2-adc1-41df-809c-82ba164330bd@github.com>
 <bs9YRJU8DGv8A7iF8yLGSC6Oi86QJVH6j8xbmp6bW1s=.7c8bee30-955a-4cc7-ac67-e8b390d85bad@github.com>
Message-ID: <5lpo7qc_k7lh5RjNirI1ecqGdaaS25jMORgspMjW6pw=.8a40dc0a-26a6-492b-ace7-32fd5adf40ae@github.com>

On Fri, 17 Feb 2023 01:56:21 GMT, Ian Graves <igraves at openjdk.org> wrote:

>> src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/DefaultCompressPlugin.java line 95:
>> 
>>> 93:             switch (level) {
>>> 94:                 case LEVEL_0:
>>> 95:                     System.err.println("warning - the \"0\" value for --compress has been deprecated and " +
>> 
>> I expect this be a localized message, e.g. add to plugins.properties.   You can call `AbstractPlugin::getMessage` to get the message from the resource bundle.  This one should be consistent with the existing convention but unfortunately the existing warning messages are not consistent - prefixing with "Warning:" or "WARNING:".
>
> Thanks. I note that there is a non-localized warning done this way elsewhere in jlink. May need to make a bug to localize this.

I prefer this one should use the localized message.  The other ones should be followed up in a separate bug as they are unrelated to this one.

-------------

PR: https://git.openjdk.org/jdk/pull/11617

From duke at openjdk.org  Fri Feb 17 03:15:56 2023
From: duke at openjdk.org (SUN Guoyun)
Date: Fri, 17 Feb 2023 03:15:56 GMT
Subject: RFR: 8276799: Implementation of JEP 422: Linux/RISC-V Port [v5]
In-Reply-To: <ybE2QYYZQ6GU7o67rW5rpgA3JGxULHDGlTUTi-2cky8=.488673b2-40fe-49d3-9076-ac4c2b10efe0@github.com>
References: <U63ZsjFbn1joXn0DetupOhRJ6JHRe0MElXMuJzST7gI=.0f7c3d12-bad0-4706-92a8-139bf33dd8ba@github.com>
 <ybE2QYYZQ6GU7o67rW5rpgA3JGxULHDGlTUTi-2cky8=.488673b2-40fe-49d3-9076-ac4c2b10efe0@github.com>
Message-ID: <vx8i_CIWT4jzEeeaayICiQ31DbtvF76qnu5_ttCyXg8=.c09d6ef0-d343-49b0-b0fb-92a50f8d2f0f@github.com>

On Thu, 24 Mar 2022 07:01:43 GMT, Fei Yang <fyang at openjdk.org> wrote:

>> This PR implements JEP 422: Linux/RISC-V Port [1].
>> The PR starts as a squashed merge of the https://openjdk.java.net/projects/riscv-port branch.
>> 
>> This has been tested with jtreg tier{1,2,3,4} and jcstress on HiFive Unmatched board. Dacapo, SPECjbb2015 and SPECjvm2008 benchmark tests are also carried out regularly. So it should be good enough to run most Java programs.
>> 
>> [1] https://openjdk.java.net/jeps/422
>
> Fei Yang 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:
> 
>  - Merge remote-tracking branch 'upstream/master' into JDK-8276799
>  - Fix copyright header
>  - Address review comments
>  - Merge remote-tracking branch 'upstream/master' into JDK-8276799
>  - 8276799: Implementation of JEP 422: Linux/RISC-V Port

src/hotspot/cpu/riscv/riscv.ad line 8758:

> 8756: %{
> 8757:   // Same match rule as `far_cmpU_loop'.
> 8758:   match(CountedLoopEnd cmp (CmpU op1 op2));

Which testcases can test this instruct and the following instructs?
match(CountedLoopEnd cmp (CmpP op1 op2));
match(CountedLoopEnd cmp (CmpN op1 op2));
match(CountedLoopEnd cmp (CmpF op1 op2));
match(CountedLoopEnd cmp (CmpD op1 op2));

 I suspect this instruction is useless.

-------------

PR: https://git.openjdk.org/jdk/pull/6294

From darcy at openjdk.org  Fri Feb 17 03:25:11 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 17 Feb 2023 03:25:11 GMT
Subject: Integrated: JDK-8301444: Port fdlibm hyperbolic transcendental
 functions to Java
In-Reply-To: <_s8xnppoDTnAajAjlmfB-dX5DBdawUcSSPaGWGLzFBk=.cdbf468a-ace7-45e5-a25a-833c760b776c@github.com>
References: <_s8xnppoDTnAajAjlmfB-dX5DBdawUcSSPaGWGLzFBk=.cdbf468a-ace7-45e5-a25a-833c760b776c@github.com>
Message-ID: <kS-u_uZI8N7BBB9jRzlPQO2TXj3SwWz1L2OKdaFQtVM=.6c491192-2ec1-4255-b450-6047b8543d71@github.com>

On Sun, 5 Feb 2023 03:05:55 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Initial pass of porting FDLIBM sinh/cosh/tanh to Java. I do intend to refactor the regression tests a bit to reduce duplication, but the actual ports should be ready for review.
> 
> Diff'ing the ports as before, original vs transliteration port:
> 
> 
> $ diff -w Hyperbolic.c Hyperbolic.translit.java
> 1c1
> < /* __ieee754_sinh(x)
> ---
>>     /**
> 17a18,19
>>     static class Sinh {
>>         private static final double one = 1.0, shuge = 1.0e307;
> 19,33c21
> < #include "fdlibm.h"
> < 
> < #ifdef __STDC__
> < static const double one = 1.0, shuge = 1.0e307;
> < #else
> < static double one = 1.0, shuge = 1.0e307;
> < #endif
> < 
> < #ifdef __STDC__
> <         double __ieee754_sinh(double x)
> < #else
> <         double __ieee754_sinh(x)
> <         double x;
> < #endif
> < {
> ---
>>         private static double compute(double x) {
> 36c24
> <         unsigned lx;
> ---
>>             /* unsigned */ int lx;
> 51c39
> <             t = expm1(fabs(x));
> ---
>>                 t = FdlibmTranslit.expm1(Math.abs(x));
> 57c45
> <         if (ix < 0x40862E42)  return h*__ieee754_exp(fabs(x));
> ---
>>             if (ix < 0x40862E42)  return h*StrictMath.exp(Math.abs(x)); // TODO switch to translit
> 60,62c48,52
> <         lx = *( (((*(unsigned*)&one)>>29)) + (unsigned*)&x);
> <         if (ix<0x408633CE || ((ix==0x408633ce)&&(lx<=(unsigned)0x8fb9f87d))) {
> <             w = __ieee754_exp(0.5*fabs(x));
> ---
>>             // lx = *( (((*(unsigned*)&one)>>29)) + (unsigned*)&x);
>>             // lx =  (((*(unsigned*)&one)>>29)) + (unsigned*)&x ;
>>             lx = __LO(x);
>>             if (ix<0x408633CE || ((ix==0x408633ce)&&(Long.compareUnsigned(lx, 0x8fb9f87d) <= 0 ))) {
>>                 w = StrictMath.exp(0.5*Math.abs(x)); // TODO switch to translit
> 70c60,62
> < /* __ieee754_cosh(x)
> ---
>>     }
>> 
>>     /**
> 90,105c82,84
> < 
> < #include "fdlibm.h"
> < 
> < #ifdef __STDC__
> < static const double one = 1.0, half=0.5, huge = 1.0e300;
> < #else
> < static double one = 1.0, half=0.5, huge = 1.0e300;
> < #endif
> < 
> < #ifdef __STDC__
> <         double __ieee754_cosh(double x)
> < #else
> <         double __ieee754_cosh(x)
> <         double x;
> < #endif
> < {
> ---
>>     static class Cosh {
>>         private static final double one = 1.0, half=0.5, huge = 1.0e300;
>>         private static double compute(double x) {
> 108c87
> <         unsigned lx;
> ---
>>             /*unsigned*/ int lx;
> 119c98
> <             t = expm1(fabs(x));
> ---
>>                 t = expm1(Math.abs(x));
> 127c106
> <                 t = __ieee754_exp(fabs(x));
> ---
>>                 t = StrictMath.exp(Math.abs(x)); // TODO switch to translit
> 132c111
> <         if (ix < 0x40862E42)  return half*__ieee754_exp(fabs(x));
> ---
>>             if (ix < 0x40862E42)  return half*StrictMath.exp(Math.abs(x)); // TODO switch to translit
> 135c114
> <         lx = *( (((*(unsigned*)&one)>>29)) + (unsigned*)&x);
> ---
>>             lx = __LO(x);
> 137,138c116,117
> <               ((ix==0x408633ce)&&(lx<=(unsigned)0x8fb9f87d))) {
> <             w = __ieee754_exp(half*fabs(x));
> ---
>>                 ((ix==0x408633ce)&&(Integer.compareUnsigned(lx, 0x8fb9f87d) <= 0))) {
>>                 w = StrictMath.exp(half*Math.abs(x)); // TODO switch to translit
> 146c125,127
> < /* Tanh(x)
> ---
>>     }
>> 
>>     /**
> 169,184c150,152
> < 
> < #include "fdlibm.h"
> < 
> < #ifdef __STDC__
> < static const double one=1.0, two=2.0, tiny = 1.0e-300;
> < #else
> < static double one=1.0, two=2.0, tiny = 1.0e-300;
> < #endif
> < 
> < #ifdef __STDC__
> <         double tanh(double x)
> < #else
> <         double tanh(x)
> <         double x;
> < #endif
> < {
> ---
>>     static class Tanh {
>>         private static final double one=1.0, two=2.0, tiny = 1.0e-300;
>>         static double compute(double x) {
> 203c171
> <                 t = expm1(two*fabs(x));
> ---
>>                     t = expm1(two*Math.abs(x));
> 206c174
> <                 t = expm1(-two*fabs(x));
> ---
>>                     t = expm1(-two*Math.abs(x));
> 214a183
>>     }
> 
> 
> Note that the original has a in-line version of the "__LO" macro rather than using the macro.
> 
> 
> And transliteration vs more idiomatic:
> 
> 
> $ diff -w Hyperbolic.translit.java Hyperbolic.fdlibm.java 
> 21c21
> <         private static double compute(double x) {
> ---
>>          static double compute(double x) {
> 26c26
> <             /* High word of |x|. */
> ---
>>             // High word of |x|
> 28c28
> <             ix = jx&0x7fffffff;
> ---
>>             ix = jx & 0x7fff_ffff;
> 30,31c30,33
> <             /* x is INF or NaN */
> <             if(ix>=0x7ff00000) return x+x;
> ---
>>             // x is INF or NaN
>>             if ( ix >= 0x7ff0_0000) {
>>                 return x + x;
>>             }
> 34,40c36,48
> <             if (jx<0) h = -h;
> <             /* |x| in [0,22], return sign(x)*0.5*(E+E/(E+1))) */
> <             if (ix < 0x40360000) {          /* |x|<22 */
> <                 if (ix<0x3e300000)          /* |x|<2**-28 */
> <                     if(shuge+x>one) return x;/* sinh(tiny) = tiny with inexact */
> <                 t = FdlibmTranslit.expm1(Math.abs(x));
> <                 if(ix<0x3ff00000) return h*(2.0*t-t*t/(t+one));
> ---
>>             if ( jx < 0) {
>>                 h = -h;
>>             }
>>             // |x| in [0,22], return sign(x)*0.5*(E+E/(E+1)))
>>             if (ix < 0x4036_0000) {          // |x| < 22
>>                 if (ix < 0x3e30_0000)        // |x| < 2**-28
>>                     if (shuge + x > one) {   // sinh(tiny) = tiny with inexact
>>                         return x;
>>                     }
>>                 t = StrictMath.expm1(Math.abs(x));
>>                 if (ix < 0x3ff0_0000) {
>>                     return h*(2.0 * t - t*t/(t + one));
>>                 }
> 44,45c52,55
> <             /* |x| in [22, log(maxdouble)] return 0.5*exp(|x|) */
> <             if (ix < 0x40862E42)  return h*StrictMath.exp(Math.abs(x)); // TODO switch to translit
> ---
>>             // |x| in [22, log(maxdouble)] return 0.5*exp(|x|)
>>             if (ix < 0x4086_2E42) {
>>                 return h*StrictMath.exp(Math.abs(x));
>>             }
> 47,49c57
> <             /* |x| in [log(maxdouble), overflowthresold] */
> <             // lx = *( (((*(unsigned*)&one)>>29)) + (unsigned*)&x);
> <             // lx =  (((*(unsigned*)&one)>>29)) + (unsigned*)&x ;
> ---
>>             // |x| in [log(maxdouble), overflowthresold]
> 51,52c59,62
> <             if (ix<0x408633CE || ((ix==0x408633ce)&&(Long.compareUnsigned(lx, 0x8fb9f87d) <= 0 ))) {
> <                 w = StrictMath.exp(0.5*Math.abs(x)); // TODO switch to translit
> ---
>>             if (ix < 0x4086_33CE ||
>>                 ((ix == 0x4086_33ce) &&
>>                  (Long.compareUnsigned(lx, 0x8fb9_f87d) <= 0 ))) {
>>                 w = StrictMath.exp(0.5 * Math.abs(x));
> 57c67
> <             /* |x| > overflowthresold, sinh(x) overflow */
> ---
>>             // |x| > overflowthresold, sinh(x) overflow
> 84c94
> <         private static double compute(double x) {
> ---
>>         static double compute(double x) {
> 89c99
> <             /* High word of |x|. */
> ---
>>             // High word of |x|
> 91c101
> <             ix &= 0x7fffffff;
> ---
>>             ix &= 0x7fff_ffff;
> 93,94c103,106
> <             /* x is INF or NaN */
> <             if(ix>=0x7ff00000) return x*x;
> ---
>>             // x is INF or NaN
>>             if (ix >= 0x7ff_00000) {
>>                 return x*x;
>>             }
> 96,98c108,110
> <             /* |x| in [0,0.5*ln2], return 1+expm1(|x|)^2/(2*exp(|x|)) */
> <             if(ix<0x3fd62e43) {
> <                 t = expm1(Math.abs(x));
> ---
>>             // |x| in [0,0.5*ln2], return 1+expm1(|x|)^2/(2*exp(|x|))
>>             if (ix < 0x3fd6_2e43) {
>>                 t = StrictMath.expm1(Math.abs(x));
> 100c112,114
> <                 if (ix<0x3c800000) return w;        /* cosh(tiny) = 1 */
> ---
>>                 if (ix < 0x3c80_0000) { // cosh(tiny) = 1
>>                     return w;
>>                 }
> 104,106c118,120
> <             /* |x| in [0.5*ln2,22], return (exp(|x|)+1/exp(|x|)/2; */
> <             if (ix < 0x40360000) {
> <                 t = StrictMath.exp(Math.abs(x)); // TODO switch to translit
> ---
>>             // |x| in [0.5*ln2, 22], return (exp(|x|) + 1/exp(|x|)/2
>>             if (ix < 0x4036_0000) {
>>                 t = StrictMath.exp(Math.abs(x));
> 110,111c124,127
> <             /* |x| in [22, log(maxdouble)] return half*exp(|x|) */
> <             if (ix < 0x40862E42)  return half*StrictMath.exp(Math.abs(x)); // TODO switch to translit
> ---
>>             // |x| in [22, log(maxdouble)] return half*exp(|x|)
>>             if (ix < 0x4086_2E42) {
>>                 return half*StrictMath.exp(Math.abs(x));
>>             }
> 113c129
> <             /* |x| in [log(maxdouble), overflowthresold] */
> ---
>>             // |x| in [log(maxdouble), overflowthresold]
> 115,117c131,134
> <             if (ix<0x408633CE ||
> <                 ((ix==0x408633ce)&&(Integer.compareUnsigned(lx, 0x8fb9f87d) <= 0))) {
> <                 w = StrictMath.exp(half*Math.abs(x)); // TODO switch to translit
> ---
>>             if (ix<0x4086_33CE ||
>>                 ((ix == 0x4086_33ce) &&
>>                  (Integer.compareUnsigned(lx, 0x8fb9_f87d) <= 0))) {
>>                 w = StrictMath.exp(half*Math.abs(x));
> 122c139
> <             /* |x| > overflowthresold, cosh(x) overflow */
> ---
>>             // |x| > overflowthresold, cosh(x) overflow
> 126d142
> < 
> 156c172
> <             /* High word of |x|. */
> ---
>>             // High word of |x|.
> 158c174
> <             ix = jx&0x7fffffff;
> ---
>>             ix = jx & 0x7fff_ffff;
> 160,163c176,182
> <             /* x is INF or NaN */
> <             if(ix>=0x7ff00000) {
> <                 if (jx>=0) return one/x+one;    /* tanh(+-inf)=+-1 */
> <                 else       return one/x-one;    /* tanh(NaN) = NaN */
> ---
>>             // x is INF or NaN
>>             if (ix >= 0x7ff0_0000) {
>>                 if (jx >= 0) {  // tanh(+-inf)=+-1
>>                     return one/x + one;
>>                 } else {        // tanh(NaN) = NaN
>>                     return one/x - one;
>>                 }
> 166,171c185,190
> <             /* |x| < 22 */
> <             if (ix < 0x40360000) {          /* |x|<22 */
> <                 if (ix<0x3c800000)          /* |x|<2**-55 */
> <                     return x*(one+x);       /* tanh(small) = small */
> <                 if (ix>=0x3ff00000) {       /* |x|>=1  */
> <                     t = expm1(two*Math.abs(x));
> ---
>>             // |x| < 22
>>             if (ix < 0x4036_0000) {          // |x| < 22
>>                 if (ix<0x3c80_0000)          // |x| < 2**-55
>>                     return x*(one + x);      // tanh(small) = small
>>                 if (ix>=0x3ff0_0000) {       // |x| >= 1
>>                     t = StrictMath.expm1(two*Math.abs(x));
> 174c193
> <                     t = expm1(-two*Math.abs(x));
> ---
>>                     t = StrictMath.expm1(-two*Math.abs(x));
> 177,179c196,197
> <                 /* |x| > 22, return +-1 */
> <             } else {
> <                 z = one - tiny;             /* raised inexact flag */
> ---
>>             } else { // |x| > 22, return +-1
>>                 z = one - tiny;             // raised inexact flag

This pull request has now been integrated.

Changeset: 655a7127
Author:    Joe Darcy <darcy at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/655a71277dd9a01913f29dad4ca57c43e4eab174
Stats:     675 lines in 6 files changed: 625 ins; 19 del; 31 mod

8301444: Port fdlibm hyperbolic transcendental functions to Java

Reviewed-by: bpb

-------------

PR: https://git.openjdk.org/jdk/pull/12429

From darcy at openjdk.org  Fri Feb 17 04:18:30 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 17 Feb 2023 04:18:30 GMT
Subject: RFR: JDK-8302028: Port fdlibm atan2 to Java [v2]
In-Reply-To: <xl79M-V4_2t49GuCudJHQBaJjAcwWl9f2Bv19RbAmdo=.b9c97066-8cf4-4569-8b4b-8b4874e23833@github.com>
References: <xl79M-V4_2t49GuCudJHQBaJjAcwWl9f2Bv19RbAmdo=.b9c97066-8cf4-4569-8b4b-8b4874e23833@github.com>
Message-ID: <TMI7ZKI2Qc9DL_wLKNwMXAtu7hstoL-mrZjEIsv-MT0=.dace04d5-ec7e-40c2-b540-4e1f5e68bd38@github.com>

> Working down the porting list, next stop, atan2.

Joe Darcy 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:

 - Update regression test.
 - Merge branch 'master' into JDK-8302028
 - JDK-8302028: Port fdlibm atan2 to Java

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12608/files
  - new: https://git.openjdk.org/jdk/pull/12608/files/b176f4de..8b71e186

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12608&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12608&range=00-01

  Stats: 3855 lines in 135 files changed: 2428 ins; 1002 del; 425 mod
  Patch: https://git.openjdk.org/jdk/pull/12608.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12608/head:pull/12608

PR: https://git.openjdk.org/jdk/pull/12608

From duke at openjdk.org  Fri Feb 17 04:43:00 2023
From: duke at openjdk.org (Xiaowei Lu)
Date: Fri, 17 Feb 2023 04:43:00 GMT
Subject: RFR: 8302204: Optimize BigDecimal.divide [v2]
In-Reply-To: <rUC0Dh_-1E0PZNJwM0GRH1KPu6prPotT-oeDTUdqjI4=.a8f7d3b7-a0f2-45a0-ae01-f37ef108d18f@github.com>
References: <rUC0Dh_-1E0PZNJwM0GRH1KPu6prPotT-oeDTUdqjI4=.a8f7d3b7-a0f2-45a0-ae01-f37ef108d18f@github.com>
Message-ID: <RmxcdUCqazQtulk5M7nAuwuwGPHcsILq_y2cYSUJliw=.0806795b-00ed-434c-beae-f301b293729b@github.com>

> [JDK-8269667](https://bugs.openjdk.org/browse/JDK-8269667) has uncovered the poor performance of BigDecimal.divide under certain circumstance.
> 
> We confront similar situations when benchmarking Spark3 on TPC-DS test kit. According to the flame-graph below, it is StripZeros that spends most of the time of BigDecimal.divide. Hence we propose this patch to optimize stripping zeros.
> ![?? 1](https://user-images.githubusercontent.com/39413832/218062061-53cd0220-776e-4b72-8b9a-6b0f11707986.png)
> 
> Currently, createAndStripZerosToMatchScale() is performed linearly. That is, the target value is parsed from back to front, each time stripping out single ?0?. To optimize, we can adopt the method of binary search. That is, each time we try to strip out ${scale/2} ?0?s. 
> 
> The performance looks good. Therotically, time complexity of our method is O(log n), while the current one is O(n). In practice, benchmarks on Spark3 show that 1/3 less time (102s->68s) is spent on TPC-DS query4. We also runs Jtreg and JCK to check correctness, and it seems fine.
> 
> More about environment: 
> we run Spark3.3.0 on Openjdk11, but it seems jdk version doesn?t have much impact on BigDecimal. Spark cluster consists of a main node and 2 core nodes, each has 4cores, 16g memory and 4x500GB storage.

Xiaowei Lu has updated the pull request incrementally with one additional commit since the last revision:

  check lowest n bits instead of single one

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12509/files
  - new: https://git.openjdk.org/jdk/pull/12509/files/8aefac3e..35e08969

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12509&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12509&range=00-01

  Stats: 14 lines in 1 file changed: 3 ins; 2 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/12509.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12509/head:pull/12509

PR: https://git.openjdk.org/jdk/pull/12509

From duke at openjdk.org  Fri Feb 17 04:43:01 2023
From: duke at openjdk.org (Xiaowei Lu)
Date: Fri, 17 Feb 2023 04:43:01 GMT
Subject: RFR: 8302204: Optimize BigDecimal.divide
In-Reply-To: <uPa3KZYwKdQeJpnSGCZoLYg7haPNZAibGrwH10PxUrw=.025a1629-59b3-4a3f-9063-600f38040280@github.com>
References: <rUC0Dh_-1E0PZNJwM0GRH1KPu6prPotT-oeDTUdqjI4=.a8f7d3b7-a0f2-45a0-ae01-f37ef108d18f@github.com>
 <LsBjupG20ZvkAuKI-gFAPtdg3-glOkS2wAy15hRa-BM=.76ada238-5727-4975-898e-ed6cbadd6203@github.com>
 <uPa3KZYwKdQeJpnSGCZoLYg7haPNZAibGrwH10PxUrw=.025a1629-59b3-4a3f-9063-600f38040280@github.com>
Message-ID: <RwUWL0wF8E-7k-E3nW3B9fpCrfhXZPfGZbV9-JjTuFM=.6d554a56-7234-4812-8746-f06d10e59e5c@github.com>

On Tue, 14 Feb 2023 04:48:43 GMT, Xiaowei Lu <duke at openjdk.org> wrote:

> The pr looks promising in terms of performance. What makes sense to do:
> 
> *) Don't rely on external benchmarks. It's fine if such exists, but anyway set of microbenchmarks (using JMH) will be much better. More clear, readable results, etc. E.g., it may show that other operations (for example, sqrt) were speeded up too.
> 
> *) Find boundaries. "divideAndRemainder(bigTenToThe(scaleStep))" may produce non-zero reminder. Find conditions when it happens. How big is performance regression in such cases?
> 
> Some other optimizations: *) Current code checks only the lowest bit (odd or even) to cut off indivisible cases. Making "divideAndRemainder(bigTenToThe(scaleStep))" - you make check scaleStep lowest bits to do cut off. See "BigInteger.getLowestSetBit()"
> 
> *) BigInteger division by int value is faster. It's a special case. What is faster, doing the single division by bigTenToThe(scaleStep) or doing several divisions (split scaleStep to fit into int)? Exploration is required.

Hi. Here are some updates.
About the two optimizations you suggest.
1. Check scaleStep lowest bits is way better than only checking the lowest bit. This is indeed a good idea and I have committed this change.
2. As for doing several divisions instead of single division, it seems this method will decrease performance by about 5%. The reason, I guess, may be that division by int isn't as fast as we expected. The following is benchmark result.

doing several divisions 
DecimalBenchmark.divide_by_2         thrpt    5  1239304.846 ? 29436.222  ops/s
DecimalBenchmark.divide_by_2_to_100  thrpt    5    31218.635 ?   210.539  ops/s
DecimalBenchmark.divide_by_3         thrpt    5  6296749.157 ? 86503.717  ops/s

doing single division by bigTenToThe(scaleStep)
DecimalBenchmark.divide_by_2         thrpt    5  1480401.113 ?   8337.892  ops/s
DecimalBenchmark.divide_by_2_to_100  thrpt    5    33143.697 ?    152.598  ops/s
DecimalBenchmark.divide_by_3         thrpt    5  6188186.598 ? 341272.484  ops/s

The following is how I split scaleStep into int to do such divisions.

    private static BigInteger[] divideByPowerTen(BigInteger intVal, int n) {
        // guarantee n > 0
        int INT_MAX_POWER_OF_TEN = 9; // 10^9 is the max ten power which can be contained in an int
        BigInteger qr[];
        BigInteger dividend = intVal;

        // Split n into int value to accelerate the following division.
        do {
            int step = Math.min(INT_MAX_POWER_OF_TEN, n);
            qr = dividend.divideAndRemainder(BIG_TEN_POWERS_TABLE[step]);
            if (qr[1].signum() != 0) {
                break;
            } else {
                n -= step;
                dividend = qr[0];
            }
        } while (n > 0);
        return qr;
    }

-------------

PR: https://git.openjdk.org/jdk/pull/12509

From duke at openjdk.org  Fri Feb 17 04:43:01 2023
From: duke at openjdk.org (Xiaowei Lu)
Date: Fri, 17 Feb 2023 04:43:01 GMT
Subject: RFR: 8302204: Optimize BigDecimal.divide
In-Reply-To: <RwUWL0wF8E-7k-E3nW3B9fpCrfhXZPfGZbV9-JjTuFM=.6d554a56-7234-4812-8746-f06d10e59e5c@github.com>
References: <rUC0Dh_-1E0PZNJwM0GRH1KPu6prPotT-oeDTUdqjI4=.a8f7d3b7-a0f2-45a0-ae01-f37ef108d18f@github.com>
 <LsBjupG20ZvkAuKI-gFAPtdg3-glOkS2wAy15hRa-BM=.76ada238-5727-4975-898e-ed6cbadd6203@github.com>
 <uPa3KZYwKdQeJpnSGCZoLYg7haPNZAibGrwH10PxUrw=.025a1629-59b3-4a3f-9063-600f38040280@github.com>
 <RwUWL0wF8E-7k-E3nW3B9fpCrfhXZPfGZbV9-JjTuFM=.6d554a56-7234-4812-8746-f06d10e59e5c@github.com>
Message-ID: <LkkyjNj4sUgnvHfqE4d4r2JDeItOYsNtdMr-C8Ah5K4=.cb44c868-6d15-4cae-976c-77e4a368358e@github.com>

On Fri, 17 Feb 2023 04:36:08 GMT, Xiaowei Lu <duke at openjdk.org> wrote:

> The pr looks promising in terms of performance. What makes sense to do:
> 
> *) Don't rely on external benchmarks. It's fine if such exists, but anyway set of microbenchmarks (using JMH) will be much better. More clear, readable results, etc. E.g., it may show that other operations (for example, sqrt) were speeded up too.
> 
> *) Find boundaries. "divideAndRemainder(bigTenToThe(scaleStep))" may produce non-zero reminder. Find conditions when it happens. How big is performance regression in such cases?
> 
> Some other optimizations: *) Current code checks only the lowest bit (odd or even) to cut off indivisible cases. Making "divideAndRemainder(bigTenToThe(scaleStep))" - you make check scaleStep lowest bits to do cut off. See "BigInteger.getLowestSetBit()"
> 
> *) BigInteger division by int value is faster. It's a special case. What is faster, doing the single division by bigTenToThe(scaleStep) or doing several divisions (split scaleStep to fit into int)? Exploration is required.

About the boundaries you have mentioned.
In short, such perf regression cases are rare, and our optimization shows 5% regression in that case.

As you said, "divideAndRemainder(bigTenToThe(scaleStep))" may produce non-zero remainder. To make it happen, we need a big scaleStep with a small number of trailing zeros of intVal. Since scaleStep=scale-preferredScale, and preferredScale = dividend.scale() - divisor.scale(), we intend for a small scale for dividend and a big scale for divisor. Meanwhile, the division should produce zero remainder.
We managed to find one case: 1/2^n. The remainder is always zero and scaleStep is Big enough.

Take the following for example

MathContext mc = new MathContext(36, RoundingMode.HALF_UP);
BigDecimal divisor = BigDecimal.valueOf((long)1<<50);
BigDecimal.ONE.divide(divisor, mc);

In zero stripping, intVal is ``888178419700125232338905334472656250``, scale is ``51`` and preferredScale is ``0``.
Without our optimization, only one division is needed since intVal has just one trailing zero.
With out optimization, scaleStep will firstly try 25, then fail, then try 12 and fail, then try 6 and fail??Just like the worst case of binary search.

We extend this case to 1/2^n(n in [50, 60)), and we see about 5% regression.

@Benchmark
public void worst_case() {
    // precision of MathContext is carefully designed to make quotient have few trailing zeros.(Up to 4)
    MathContext mc1 = new MathContext(38, RoundingMode.HALF_UP);
    for(long i = 50; i < 55; i++) {
        BigDecimal divisor1 = BigDecimal.valueOf((long)1<<i);
        BigDecimal.ONE.divide(divisor1, mc1);
    }
    MathContext mc2 = new MathContext(42, RoundingMode.HALF_UP);
    for(long j = 55; j < 60; j++) {
        BigDecimal divisor2 = BigDecimal.valueOf((long)1<<j);
        BigDecimal.ONE.divide(divisor2, mc2);
    }
}

Before Optimization 
Benchmark                      Mode  Cnt       Score      Error  Units
DecimalBenchmark.worst_case  thrpt    5  212396.544 ? 4124.663  ops/s

After Optimization
Benchmark                      Mode  Cnt       Score     Error  Units
DecimalBenchmark.worst_case  thrpt    5  204978.953 ? 232.510  ops/s

-------------

PR: https://git.openjdk.org/jdk/pull/12509

From duke at openjdk.org  Fri Feb 17 04:45:26 2023
From: duke at openjdk.org (Xiaowei Lu)
Date: Fri, 17 Feb 2023 04:45:26 GMT
Subject: RFR: 8302204: Optimize BigDecimal.divide
In-Reply-To: <33muq0xW2ZRW13PAjRpOFAMFC2e1iZ_pR_4SXupx7pk=.02db719e-4919-43b8-a6ca-b87e115007f9@github.com>
References: <rUC0Dh_-1E0PZNJwM0GRH1KPu6prPotT-oeDTUdqjI4=.a8f7d3b7-a0f2-45a0-ae01-f37ef108d18f@github.com>
 <33muq0xW2ZRW13PAjRpOFAMFC2e1iZ_pR_4SXupx7pk=.02db719e-4919-43b8-a6ca-b87e115007f9@github.com>
Message-ID: <M0Ns-XC0XrTfVXh_4uRgLefHZDnNtcmjUyqBtQ_qArA=.d36c40c0-441c-4609-a0e5-ed5e84c49f77@github.com>

On Thu, 16 Feb 2023 16:51:43 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

> After making sure that `intVal` is even, and before attempting a division by a power of 10, it might help to check if 5 divides `intVal` in the first place. If it doesn't, there no point in performing the division.
> 
> It can be shown that 5 divides `intVal` if and only if it divides the `long` sum of all `int`s in the `mag` array of `intVal`.
> 
> I didn't try out if this contributes to improve the overall performance, but it might be worth giving a try.

Thanks for your suggestion. I will give it a try

-------------

PR: https://git.openjdk.org/jdk/pull/12509

From alanb at openjdk.org  Fri Feb 17 07:52:19 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 17 Feb 2023 07:52:19 GMT
Subject: RFR: 8301627: System.exit and Runtime.exit debug logging [v5]
In-Reply-To: <-WX4sORgC6ML_rXmQLArPbpKD0qFVDUtUwdHkOmSShQ=.c1e1666d-8a6e-412f-829a-f251abb853a6@github.com>
References: <OzJeJH5yxolKPChcUisqtzGYF_MU3oOJdx6HPhsXjBw=.15eefe39-efe1-433e-a6ac-02b4a730f264@github.com>
 <-WX4sORgC6ML_rXmQLArPbpKD0qFVDUtUwdHkOmSShQ=.c1e1666d-8a6e-412f-829a-f251abb853a6@github.com>
Message-ID: <rRRpsdK-9ODfmcIXOJvV6bQt5imHiLXjg4zJmiCWZSA=.e9127bda-35ed-49d0-981b-f7562065ecdc@github.com>

On Thu, 16 Feb 2023 21:53:00 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> It can be difficult to find the cause of calls to `java.lang.System.exit(status)` and `Runtime.exit(status)` because the Java runtime exits.
>> The status value and stack trace are logged using the System Logger named `java.lang.Runtime` with message level `System.Logger.Level.DEBUG`.
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Improve implNote for Runtime.exit() with review suggestions.

I see the test is added to test/jdk/java/lang/runtime but that is the tests for java.lang.runtime. The tests for java.lang.Runtime were moved to  test/jdk/java/lang/RuntimeTests at some point. So I think the new test should move there.

src/java.base/share/classes/java/lang/Runtime.java line 162:

> 160:      * If the {@link System#getLogger(String) the system logger} for {@code java.lang.Runtime}
> 161:      * is enabled with logging level {@link System.Logger.Level#DEBUG Level.DEBUG} the stack trace
> 162:      * of the call to {@code Runtime.exit()} is logged.

Have you ruled out adding the implNote to System.exit too? Asking as I suspect it's more likely to be read there.

src/java.base/share/classes/java/lang/Shutdown.java line 178:

> 176:     // Locate and return the logger for Shutdown.exit, if it is functional and DEBUG enabled.
> 177:     // Exceptions should not prevent System.exit; the exception is printed and otherwise ignored.
> 178:     private static System.Logger getRuntimeExitLogger() {

The method descriptions in this this class use /* .. */ style so probably best to keep it consistent if you.

-------------

PR: https://git.openjdk.org/jdk/pull/12517

From duke at openjdk.org  Fri Feb 17 09:01:14 2023
From: duke at openjdk.org (Xiaowei Lu)
Date: Fri, 17 Feb 2023 09:01:14 GMT
Subject: RFR: 8302204: Optimize BigDecimal.divide
In-Reply-To: <M0Ns-XC0XrTfVXh_4uRgLefHZDnNtcmjUyqBtQ_qArA=.d36c40c0-441c-4609-a0e5-ed5e84c49f77@github.com>
References: <rUC0Dh_-1E0PZNJwM0GRH1KPu6prPotT-oeDTUdqjI4=.a8f7d3b7-a0f2-45a0-ae01-f37ef108d18f@github.com>
 <33muq0xW2ZRW13PAjRpOFAMFC2e1iZ_pR_4SXupx7pk=.02db719e-4919-43b8-a6ca-b87e115007f9@github.com>
 <M0Ns-XC0XrTfVXh_4uRgLefHZDnNtcmjUyqBtQ_qArA=.d36c40c0-441c-4609-a0e5-ed5e84c49f77@github.com>
Message-ID: <BRkM6aFrRPiaBHH-qBGTlRUnFqfyP1oY719xN5_hCLU=.3b6adaff-ee4b-4ba3-b28b-46bea061f0b0@github.com>

On Fri, 17 Feb 2023 04:42:50 GMT, Xiaowei Lu <duke at openjdk.org> wrote:

> After making sure that `intVal` is even, and before attempting a division by a power of 10, it might help to check if 5 divides `intVal` in the first place. If it doesn't, there no point in performing the division.
> 
> It can be shown that 5 divides `intVal` if and only if it divides the `long` sum of all `int`s in the `mag` array of `intVal`.
> 
> I didn't try out if this contributes to improve the overall performance, but it might be worth giving a try.

Unfortunately, it seems this division by 5 doesn't give an obvious performance improvement. Maybe previous lowest bit check has filtered some cases.

-------------

PR: https://git.openjdk.org/jdk/pull/12509

From alanb at openjdk.org  Fri Feb 17 09:04:15 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 17 Feb 2023 09:04:15 GMT
Subject: RFR: 8299748: java/util/zip/Deinflate.java failing on s390x
In-Reply-To: <_Q8SmfDM6g63NP7vBn9As_n_X6ejp_W08o9lbmlUq3I=.0967d833-b2a0-498b-ba44-22be4ecd95ff@github.com>
References: <Usxi4wE5GSHHv-cKPfW6OXylhieAypbsidUX_Jo6FSQ=.34104cf0-2243-478f-86ce-9a91905c6755@github.com>
 <nN80i01pPGVl8QlQ09eEEEeFTz5z2hpM6udh2bNJwpU=.925ff5c6-586b-4262-bcd0-fd67d44cfde2@github.com>
 <jyL7HTlmcVxDKffdPqij6GNM0ePfzVxlypfy3hTtOAM=.3347a8dd-4722-4b79-b93e-b20892901c6b@github.com>
 <2eqxeIzcejWahzfAMe-czlbIQ96bV8s_RIkXQsXMtsY=.b329489c-40fc-4e91-9e30-10a3df53711e@github.com>
 <p1li8W4D2kYNZlxTOyvlqVrZWOjGbh6g1JfG6eHxAmE=.389b076c-0943-4cfd-af82-f24a56d1ac61@github.com>
 <mViUt9K-2zX1iclGWss9oGHP1HM3Xigq3ZAI-ZYV9Ww=.851a49c3-c57c-46d7-9b6b-db5ffda2daf1@github.com>
 <_SfmRrzgThXEqx714Hx-z6hyhJedR_j3KqryCcZ7Ks8=.1b7b7dc6-927e-42ce-b659-23c5c9f603c0@github.com>
 <qwjoHqgbDmbLmBVNyUmOUPlt7MQzSNnD8FBEYTMhgNg=.2a376dd3-9192-4acb-b3e3-f470991706eb@github.com>
 <_Q8SmfDM6g63NP7vBn9As_n_X6ejp_W08o9lbmlUq3I=.0967d833-b2a0-498b-ba44-22be4ecd95ff@github.com>
Message-ID: <gc-FYHxnm-Hn03BxLM-BrP6ZbmIQlfSkhirFoJwz2q0=.da433d42-c36f-413f-ba1e-e00e4bfd2fb3@github.com>

On Thu, 16 Feb 2023 05:32:26 GMT, Amit Kumar <duke at openjdk.org> wrote:

> As you can see, the size of out1 is insufficient for the s390x. That's why I proposed the fix to increase the buffer size. Because the compressor is not deterministic, I don't want to be byte-perfect, so I changed the multiplier to `64` to leave 
some extra space here.

I've re-read the discussion and I don't think the real issue is clear at this time. Can you check if it only needs additional space for the DEFAULT_COMPRESSION level, maybe change the loop to only test levels 0-9 and see if it passes?

On determinism, then the test fills dataIn will random byte values, and the input length will be some random length up to dataIn.length, but otherwise I don't see anything that should cause the failure you are seeing.

-------------

PR: https://git.openjdk.org/jdk/pull/12283

From asotona at openjdk.org  Fri Feb 17 09:04:24 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Fri, 17 Feb 2023 09:04:24 GMT
Subject: RFR: 8294982: Implementation of Classfile API [v21]
In-Reply-To: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
References: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
Message-ID: <fcRYRRzJqPWm4kqsi45iMDVs_Cs30WGIjyFtFby44wU=.fd00552f-d34f-4bda-9d49-ddda4643da2e@github.com>

> This is root pull request with Classfile API implementation, tests and benchmarks initial drop into JDK.
> 
> Following pull requests consolidating JDK class files parsing, generating, and transforming ([JDK-8294957](https://bugs.openjdk.org/browse/JDK-8294957)) will chain to this one.
> 
> Classfile API development is tracked at:
> https://github.com/openjdk/jdk-sandbox/tree/classfile-api-branch
> 
> Development branch of consolidated JDK class files parsing, generating, and transforming is at:
> https://github.com/openjdk/jdk-sandbox/tree/classfile-api-dev-branch
> 
> Classfile API [JEP](https://bugs.openjdk.org/browse/JDK-8280389) and [online API documentation](https://htmlpreview.github.io/?https://raw.githubusercontent.com/openjdk/jdk-sandbox/classfile-api-javadoc-branch/doc/classfile-api/javadoc/java.base/jdk/internal/classfile/package-summary.html) is also available.
> 
> Please take you time to review this non-trivial JDK addition.
> 
> Thank you,
> Adam

Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:

  Option keys and values accessing pulled from API to implementation

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10982/files
  - new: https://git.openjdk.org/jdk/pull/10982/files/7a45ebd3..4d70fc2f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10982&range=20
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10982&range=19-20

  Stats: 129 lines in 26 files changed: 8 ins; 58 del; 63 mod
  Patch: https://git.openjdk.org/jdk/pull/10982.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10982/head:pull/10982

PR: https://git.openjdk.org/jdk/pull/10982

From asotona at openjdk.org  Fri Feb 17 09:15:39 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Fri, 17 Feb 2023 09:15:39 GMT
Subject: RFR: 8294982: Implementation of Classfile API [v20]
In-Reply-To: <Qn0tRwNM_VFrkCYp8klyMMUJRCUoB0muZ9E-UkUK8R4=.12a8c8b2-48cc-4ffe-b11e-0180c60bd4bf@github.com>
References: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
 <Gluemo5fFOPx_G6KtSgHxWEmiv3FFSTlxRHtc6ZPTuc=.6a2b6930-c7fd-4734-b21b-d2ccec1dabcf@github.com>
 <Qn0tRwNM_VFrkCYp8klyMMUJRCUoB0muZ9E-UkUK8R4=.12a8c8b2-48cc-4ffe-b11e-0180c60bd4bf@github.com>
Message-ID: <xPfx_58QY7Q6bS96T1DgNiucx7Ks4urjMC4BxbjoN8A=.cb40548a-e80b-4948-8e94-310c922a3a66@github.com>

On Thu, 16 Feb 2023 10:56:57 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   added 4-byte Unicode text to Utf8EntryTest
>
> src/java.base/share/classes/jdk/internal/classfile/components/ClassPrinter.java line 93:
> 
>> 91:          * @return name of the node
>> 92:          */
>> 93:         public ConstantDesc name();
> 
> Not sure about the ConstantDesc here. Why is it better than String?

Type information allows nice rendering for some types in some structured text formats, while `ConstantDesc::toString` is a fallback.

-------------

PR: https://git.openjdk.org/jdk/pull/10982

From asotona at openjdk.org  Fri Feb 17 09:27:39 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Fri, 17 Feb 2023 09:27:39 GMT
Subject: RFR: 8294982: Implementation of Classfile API [v20]
In-Reply-To: <Qn0tRwNM_VFrkCYp8klyMMUJRCUoB0muZ9E-UkUK8R4=.12a8c8b2-48cc-4ffe-b11e-0180c60bd4bf@github.com>
References: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
 <Gluemo5fFOPx_G6KtSgHxWEmiv3FFSTlxRHtc6ZPTuc=.6a2b6930-c7fd-4734-b21b-d2ccec1dabcf@github.com>
 <Qn0tRwNM_VFrkCYp8klyMMUJRCUoB0muZ9E-UkUK8R4=.12a8c8b2-48cc-4ffe-b11e-0180c60bd4bf@github.com>
Message-ID: <1G9rLfYBxfxcwmzgd7VDXnTfrW252lIui-9sWVAAhn0=.d3e5b0e6-66cc-4322-ae31-282954e9d3ca@github.com>

On Thu, 16 Feb 2023 11:00:48 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   added 4-byte Unicode text to Utf8EntryTest
>
> src/java.base/share/classes/jdk/internal/classfile/impl/ClassPrinterImpl.java line 563:
> 
>> 561:                       list("attributes", "attribute", clm.attributes().stream().map(Attribute::attributeName)))
>> 562:                 .with(constantPoolToTree(clm.constantPool(), verbosity))
>> 563:                 .with(attributesToTree(clm.attributes(), verbosity))
> 
> Is this ok? It seems we also add class attributes in the map node (see "attributes" map node).

Yes, the print structure does not exactly correspond to the Classfile API architecture, but rather to the classfile physical structure and it is partly similar to `javap` output.
The common tree structure has been reverse-designed from the desired visual representations in all supported text formats and in all verbosity levels.

> src/java.base/share/classes/jdk/internal/classfile/impl/SplitConstantPool.java line 83:
> 
>> 81:  * ConstantPool.
>> 82:  */
>> 83: public final class SplitConstantPool implements ConstantPoolBuilder {
> 
> Not sure the "Split" prefix carries any meaning? (perhaps a leftover from previous iterations?)

The "Split" represent a division between the original read-only constant pool and the new part with additional CP entries.

> src/java.base/share/classes/jdk/internal/classfile/impl/TemporaryConstantPool.java line 60:
> 
>> 58:     private static final Options options = new Options(Collections.emptyList());
>> 59: 
>> 60:     private TemporaryConstantPool() {};
> 
> If I understand correctly, this constant pool is just "fake" in the sense that it's a builder which creates constant pool entries w/o storing them anywhere. This seems to be used in places where e.g. we need to convert a ClassDesc to a ClassEntry, probably so that the implementation of e.g. attributes can be defined in terms of constant pool entries, even when "unbounded". E.g. this is a trick which avoids having completely different representations for bound and unbound elements - correct?

Yes, exactly :)

-------------

PR: https://git.openjdk.org/jdk/pull/10982

From asotona at openjdk.org  Fri Feb 17 09:33:44 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Fri, 17 Feb 2023 09:33:44 GMT
Subject: RFR: 8294982: Implementation of Classfile API [v20]
In-Reply-To: <01V72lRVYH7rB1NrPpkVKhvj1mksmrelMMTMrHFQ2hk=.4b2c22f3-d9c6-4778-be53-1fb055969f6a@github.com>
References: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
 <Gluemo5fFOPx_G6KtSgHxWEmiv3FFSTlxRHtc6ZPTuc=.6a2b6930-c7fd-4734-b21b-d2ccec1dabcf@github.com>
 <01V72lRVYH7rB1NrPpkVKhvj1mksmrelMMTMrHFQ2hk=.4b2c22f3-d9c6-4778-be53-1fb055969f6a@github.com>
Message-ID: <nrZU8-0YNLR3zAiaiq60Uh-w53ekdwdvcHkZtzj-10I=.618b22fd-a859-496c-aa81-2eca315d63c3@github.com>

On Thu, 16 Feb 2023 14:24:21 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   added 4-byte Unicode text to Utf8EntryTest
>
> src/java.base/share/classes/jdk/internal/classfile/impl/DirectCodeBuilder.java line 649:
> 
>> 647:             if (parentMap == null)
>> 648:                 parentMap = new IdentityHashMap<>();
>> 649:             int[] table = parentMap.computeIfAbsent(parent, new Function<CodeAttribute, int[]>() {
> 
> Can use a lambda here?

I'll have to add relevant comment here.
There are many places in the Classfile API, which are on critical JDK bootstrap path in the follow-up integrations and using lambdas or method references would cause stack overflow during JDK bootstrap.
Using other words - these fragments cannot use lambdas as they suppose to generate lambdas for JDK ;)

-------------

PR: https://git.openjdk.org/jdk/pull/10982

From asotona at openjdk.org  Fri Feb 17 09:38:36 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Fri, 17 Feb 2023 09:38:36 GMT
Subject: RFR: 8294982: Implementation of Classfile API [v20]
In-Reply-To: <XdPsRS7sN9MC3gcIyTcIN3BhhfrgSjSZYnq1jC_pqc0=.aad91048-53be-4f19-a7fd-ed4e41ad5deb@github.com>
References: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
 <Gluemo5fFOPx_G6KtSgHxWEmiv3FFSTlxRHtc6ZPTuc=.6a2b6930-c7fd-4734-b21b-d2ccec1dabcf@github.com>
 <XdPsRS7sN9MC3gcIyTcIN3BhhfrgSjSZYnq1jC_pqc0=.aad91048-53be-4f19-a7fd-ed4e41ad5deb@github.com>
Message-ID: <wZVyue5fQUUk7x0iSQ_jo5cYsWdNUkU3HZLuquJtz60=.1a6e9c36-0c55-4305-9f6c-653c7f9f8bb8@github.com>

On Thu, 16 Feb 2023 12:11:06 GMT, Jens Lidestrom <duke at openjdk.org> wrote:

>> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   added 4-byte Unicode text to Utf8EntryTest
>
> src/java.base/share/classes/jdk/internal/classfile/constantpool/ConstantPoolBuilder.java line 96:
> 
>> 94:      * @param <T> the type of the option value
>> 95:      */
>> 96:     <T> T optionValue(Classfile.Option.Key option);
> 
> This unconstrained type parameter will result in and implicit conversion to any type that the caller assigns it to, which might result in a `ClassCastException` if the caller gets the type wrong.
> 
> Is this intentional?
> 
> The same idiom is used in a few other places in the code.
> 
> Alternative solutions: 
> 
> * Convert `Key` to an ordinary class or sealed interface, and add a type parameter to it, for the value type. (Enums unfortunately don't support type parameters.)
> * Add a parameter the the method of type `Class<T>`.

Thanks for pointing it out.
I've re-visited the API re-accessing already provided options and found no relevant use case.
This method (and similar on other places), plus the `Classfile.Option.Key` will be pulled from API to the implementation.
Please let us know if there is a need to read option values from user perspective.

-------------

PR: https://git.openjdk.org/jdk/pull/10982

From redestad at openjdk.org  Fri Feb 17 10:23:52 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Fri, 17 Feb 2023 10:23:52 GMT
Subject: RFR: 8302315: Examine cost of clone of primitive arrays compared to
 arraycopy
Message-ID: <-mibOqDijYlnk44SsmO1vIsq4lWIQYQIEhIE686C3wE=.ef8847ee-90b6-4080-8532-e9783b22901d@github.com>

During work on #12453 @schlosna reported that `array.clone()` might underperform `System.arraycopy` in microbenchmarks and I opted to go with `arraycopy` throughout while investigating.

Testing on x86 (SandyBridge, AVX2) I observe no difference at all between the setups. On aarch the only difference I can observe is that arraycopy seem curiously slow for input size = 0, otherwise no statistically significant difference. All tests ran on builds from JDK mainline and 21-b9.

Since the reported difference was small and mostly visible on very large arrays I conclude that the maintainability win we get from using `clone()` is preferable. I've added the microbenchmark provided by @schlosna here.

-------------

Commit messages:
 - Examine arraycopy vs clone

Changes: https://git.openjdk.org/jdk/pull/12613/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12613&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8302315
  Stats: 163 lines in 2 files changed: 92 ins; 55 del; 16 mod
  Patch: https://git.openjdk.org/jdk/pull/12613.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12613/head:pull/12613

PR: https://git.openjdk.org/jdk/pull/12613

From redestad at openjdk.org  Fri Feb 17 10:23:53 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Fri, 17 Feb 2023 10:23:53 GMT
Subject: RFR: 8302315: Examine cost of clone of primitive arrays compared
 to arraycopy
In-Reply-To: <-mibOqDijYlnk44SsmO1vIsq4lWIQYQIEhIE686C3wE=.ef8847ee-90b6-4080-8532-e9783b22901d@github.com>
References: <-mibOqDijYlnk44SsmO1vIsq4lWIQYQIEhIE686C3wE=.ef8847ee-90b6-4080-8532-e9783b22901d@github.com>
Message-ID: <tAwEWQ1tgsoabkq-BgYEs-RmlyAa4JXd3opSl2685hY=.7cc8513c-431d-49bb-b18f-4e4ba242899b@github.com>

On Fri, 17 Feb 2023 09:58:54 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> During work on #12453 @schlosna reported that `array.clone()` might underperform `System.arraycopy` in microbenchmarks and I opted to go with `arraycopy` throughout while investigating.
> 
> Testing on x86 (SandyBridge, AVX2) I observe no difference at all between the setups. On aarch the only difference I can observe is that arraycopy seem curiously slow for input size = 0, otherwise no statistically significant difference. All tests ran on builds from JDK mainline and 21-b9.
> 
> Since the reported difference was small and mostly visible on very large arrays I conclude that the maintainability win we get from using `clone()` is preferable. I've added the microbenchmark provided by @schlosna here.

osx-aarch64:

Benchmark                 (size)  Mode  Cnt    Score   Error  Units
ArrayClone.byteArraycopy       0  avgt   15    9,517 ? 1,272  ns/op
ArrayClone.byteArraycopy      10  avgt   15    5,933 ? 0,314  ns/op
ArrayClone.byteArraycopy     100  avgt   15    4,802 ? 0,234  ns/op
ArrayClone.byteArraycopy    1000  avgt   15   24,671 ? 0,437  ns/op
ArrayClone.byteClone           0  avgt   15    2,417 ? 0,016  ns/op
ArrayClone.byteClone          10  avgt   15    2,924 ? 0,027  ns/op
ArrayClone.byteClone         100  avgt   15    4,563 ? 0,050  ns/op
ArrayClone.byteClone        1000  avgt   15   24,737 ? 0,262  ns/op
ArrayClone.intArraycopy        0  avgt   15    8,156 ? 2,148  ns/op
ArrayClone.intArraycopy       10  avgt   15    3,646 ? 0,025  ns/op
ArrayClone.intArraycopy      100  avgt   15   11,430 ? 0,087  ns/op
ArrayClone.intArraycopy     1000  avgt   15  106,174 ? 0,721  ns/op
ArrayClone.intClone            0  avgt   15    2,455 ? 0,159  ns/op
ArrayClone.intClone           10  avgt   15    3,621 ? 0,013  ns/op
ArrayClone.intClone          100  avgt   15   11,648 ? 0,454  ns/op
ArrayClone.intClone         1000  avgt   15  106,469 ? 1,295  ns/op


linux-x64, sandybridge, avx2:

Benchmark                 (size)  Mode  Cnt    Score    Error  Units
ArrayClone.byteArraycopy       0  avgt   15    3.321 ?  0.194  ns/op
ArrayClone.byteArraycopy      10  avgt   15    6.953 ?  0.329  ns/op
ArrayClone.byteArraycopy     100  avgt   15   13.490 ?  0.595  ns/op
ArrayClone.byteArraycopy    1000  avgt   15  150.201 ?  3.451  ns/op
ArrayClone.byteClone           0  avgt   15    5.431 ?  0.252  ns/op
ArrayClone.byteClone          10  avgt   15    6.370 ?  0.329  ns/op
ArrayClone.byteClone         100  avgt   15   13.561 ?  0.633  ns/op
ArrayClone.byteClone        1000  avgt   15  150.300 ?  5.318  ns/op
ArrayClone.intArraycopy        0  avgt   15    3.297 ?  0.226  ns/op
ArrayClone.intArraycopy       10  avgt   15    7.171 ?  0.354  ns/op
ArrayClone.intArraycopy      100  avgt   15   60.863 ?  1.580  ns/op
ArrayClone.intArraycopy     1000  avgt   15  557.770 ? 15.107  ns/op
ArrayClone.intClone            0  avgt   15    5.373 ?  0.225  ns/op
ArrayClone.intClone           10  avgt   15    6.965 ?  0.293  ns/op
ArrayClone.intClone          100  avgt   15   61.696 ?  1.983  ns/op
ArrayClone.intClone         1000  avgt   15  552.809 ? 14.358  ns/op

-------------

PR: https://git.openjdk.org/jdk/pull/12613

From jlahoda at openjdk.org  Fri Feb 17 10:36:56 2023
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Fri, 17 Feb 2023 10:36:56 GMT
Subject: RFR: 8297587: Upgrade JLine to 3.22.0
Message-ID: <Y2xdMkQ3uIpXOWBKdAlVyEiGEmDF4YsAWqV0Tf_dp9A=.200485d2-cc87-41bf-86dc-ad85c25d4f0e@github.com>

This is a proposal to upgrade the JLine inside JDK to 3.22.0. It was done by:
-for shared/classes, taking a diff between JLine 3.20.0 and the existing JDK version, copying the JLine 3.22.0 into the JDK, repackaing, re-appling the patch (including trailing space removal, UTF-8 characters replacement, addition of inputStreamWrapper), and adjusting TerminalProvider
-for Windows, mostly copying the JLine 3.22.0 code into the JDK, and adjusting based on old changes

-------------

Commit messages:
 - 8297587: Upgrade JLine to 3.22.0

Changes: https://git.openjdk.org/jdk/pull/12614/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12614&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8297587
  Stats: 1763 lines in 54 files changed: 1055 ins; 452 del; 256 mod
  Patch: https://git.openjdk.org/jdk/pull/12614.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12614/head:pull/12614

PR: https://git.openjdk.org/jdk/pull/12614

From duke at openjdk.org  Fri Feb 17 10:43:55 2023
From: duke at openjdk.org (Vojin Jovanovic)
Date: Fri, 17 Feb 2023 10:43:55 GMT
Subject: RFR: 8292914: Drop the counter from lambda class names [v6]
In-Reply-To: <zlDm2W50G6NgRkzmgEpX6MTVs3XyYMnY3tN1YnObWUA=.03a3d8d7-4d20-4fc6-8028-b20a8603b0a6@github.com>
References: <GgLfH-ueBQqT-Mfk1mKpKFAt8fYqyjfVJ9lmlsBsCbo=.8dd5b3b4-4e84-4970-9179-1c0399b30edc@github.com>
 <zlDm2W50G6NgRkzmgEpX6MTVs3XyYMnY3tN1YnObWUA=.03a3d8d7-4d20-4fc6-8028-b20a8603b0a6@github.com>
Message-ID: <cs--3tpi39OgSQXg3zGOG0-q9RVqFBEdkXF4aZV2a3k=.18479ad3-5a7c-4f05-9364-3fc481f6125d@github.com>

On Thu, 16 Feb 2023 19:35:54 GMT, David M. Lloyd <duke at openjdk.org> wrote:

>> The class generated for lambda proxies is now defined as a hidden class. This means that the counter, which was used to ensure a unique class name and avoid clashes, is now redundant. In addition to performing redundant work, this also impacts build reproducibility for native image generators which might already have a strategy to cope with hidden classes but cannot cope with indeterminate definition order for lambda proxy classes.
>> 
>> This solves JDK-8292914 by making lambda proxy names always be stable without any configuration needed. This would also replace #10024.
>
> David M. Lloyd has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use a unique index for the dumped lambda class instead of a time stamp

This proposal is appealing for its simplicity, however, there are points from [JDK-8292914](https://bugs.openjdk.org/browse/JDK-8292914) that it does not address:
1. *To register lambda classes for serialization*. In this case, the agent run would register all lambdas from the capturing class for serialization: there would be no identifier to distinguish one lambda from another. 
2. *For reproducible builds*. This PR makes a small step towards reproducible builds, however, it complicates the implementation on the Native Image side significantly. Now, as each class needs a unique name, we must create the unique (and stable) lambda-proxy name for all lambdas within a capturing class. This is hard with parallel static analysis as methods are discovered concurrently, and hence non-deterministically. When we discover a class, we would need to find all of its captured lambdas, then perform a deterministic traversal of the class' bytecode in order to give lambda-proxies a stable name. For such an implementation we don't even need this PR as we can simply strip the sequence number from the name and invent a new one. 
3. *To collect profiles of lambda methods for profile-guided optimizations*. With all captured lambdas having the same name, we would get polluted profiles and lose on performance.
4. *To reflectively access lambdas*. Again we would not be able to distinguish between lambdas in the same capturing class and hence we would get imprecise reflection registration.

@dmlloyd Maybe I am missing something, but I don't understand how does this PR make the builds more reproducible?

-------------

PR: https://git.openjdk.org/jdk/pull/12579

From duke at openjdk.org  Fri Feb 17 11:39:21 2023
From: duke at openjdk.org (Viktor Klang)
Date: Fri, 17 Feb 2023 11:39:21 GMT
Subject: RFR: JDK-8302666: Replace CHM with VarHandle in ForeachOrderedTask
 [v2]
In-Reply-To: <HAgE8xmpZT_2-b5ZDr8TgJNgjhVb3D4ZS3sQqA7c6Mo=.389fa590-681c-44a9-9823-8f70a6129797@github.com>
References: <HAgE8xmpZT_2-b5ZDr8TgJNgjhVb3D4ZS3sQqA7c6Mo=.389fa590-681c-44a9-9823-8f70a6129797@github.com>
Message-ID: <fLSt64PoI3s47g0BLWPMUkim0lmnuZ6wxoBJZppqgqg=.36deb86f-2998-490d-9e29-903e142c72d1@github.com>

> I noticed when looking at the code that there was no real need to use a CHM to perform the tracking of activation in an ordered fashion on ForEachOrderedTask, but instead a VarHandle can be used, reducing allocations and indirection.

Viktor Klang has updated the pull request incrementally with one additional commit since the last revision:

  Write the initial value of the next reference without using the VarHandle

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12320/files
  - new: https://git.openjdk.org/jdk/pull/12320/files/d07190ab..3b38f942

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12320&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12320&range=00-01

  Stats: 8 lines in 1 file changed: 4 ins; 3 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/12320.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12320/head:pull/12320

PR: https://git.openjdk.org/jdk/pull/12320

From duke at openjdk.org  Fri Feb 17 11:39:22 2023
From: duke at openjdk.org (Viktor Klang)
Date: Fri, 17 Feb 2023 11:39:22 GMT
Subject: RFR: JDK-8302666: Replace CHM with VarHandle in ForeachOrderedTask
 [v2]
In-Reply-To: <WuLdW53Fz4HdtzyaUlAdrOx8pwk_1MxuAFiYV9mJyUk=.81e9a8a0-78b1-474f-9444-fba99d90d0c5@github.com>
References: <HAgE8xmpZT_2-b5ZDr8TgJNgjhVb3D4ZS3sQqA7c6Mo=.389fa590-681c-44a9-9823-8f70a6129797@github.com>
 <Cgw-lNDkAD_TkUSehGq35yzULSGMA54hoT6jiKNFWjk=.1b1f80bb-be96-45b2-995b-1f61c21187b1@github.com>
 <Xwk3XgU2boNqaROJFPVpvCJ39XgJqvoPIiRwcHcVha8=.91288345-f142-4a4d-ae31-d6df9c9e5754@github.com>
 <WuLdW53Fz4HdtzyaUlAdrOx8pwk_1MxuAFiYV9mJyUk=.81e9a8a0-78b1-474f-9444-fba99d90d0c5@github.com>
Message-ID: <9uNeb6gBPh5KbGleL9QFOIYeci7JeGKL8OKdQqN0gJc=.db07b49f-a9e1-4fd3-9e17-e501493ae89c@github.com>

On Thu, 16 Feb 2023 22:01:01 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>> @PaulSandoz I'm usually a bit weary of piggybacking if it is not done on the same object, as future reorderings of the code might break that assumption. I wouldn't want to break anything silently so I made a rather conservative change. On which side should I err? :)
>
> Since as you have said the left and right nodes have yet to be "published" (outside of their little nest) I think it should be fine to move it above and next to the constructions.
> (Also since `addToPendingCount` has volatile write semantics, via it's getAndSet, the plain write should not float below that call if that really matters, and its hard to see the code radically changing in this regard unless there is a major rewrite than i guess it all has to be carefully rethought.)

@PaulSandoz Sold! Making the changes :)

@PaulSandoz Done!

-------------

PR: https://git.openjdk.org/jdk/pull/12320

From asotona at openjdk.org  Fri Feb 17 11:46:54 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Fri, 17 Feb 2023 11:46:54 GMT
Subject: RFR: 8294982: Implementation of Classfile API [v22]
In-Reply-To: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
References: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
Message-ID: <B3aI0vwyuZtX_GIQTL4ijhBzuHCY-WZOBoXb2TbSHTw=.ee3b2301-b981-4e12-a09b-afd6ebb014f2@github.com>

> This is root pull request with Classfile API implementation, tests and benchmarks initial drop into JDK.
> 
> Following pull requests consolidating JDK class files parsing, generating, and transforming ([JDK-8294957](https://bugs.openjdk.org/browse/JDK-8294957)) will chain to this one.
> 
> Classfile API development is tracked at:
> https://github.com/openjdk/jdk-sandbox/tree/classfile-api-branch
> 
> Development branch of consolidated JDK class files parsing, generating, and transforming is at:
> https://github.com/openjdk/jdk-sandbox/tree/classfile-api-dev-branch
> 
> Classfile API [JEP](https://bugs.openjdk.org/browse/JDK-8280389) and [online API documentation](https://htmlpreview.github.io/?https://raw.githubusercontent.com/openjdk/jdk-sandbox/classfile-api-javadoc-branch/doc/classfile-api/javadoc/java.base/jdk/internal/classfile/package-summary.html) is also available.
> 
> Please take you time to review this non-trivial JDK addition.
> 
> Thank you,
> Adam

Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:

  removed PoolEntry::clone and ConstantPoolBuilder::maybeClone from API

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10982/files
  - new: https://git.openjdk.org/jdk/pull/10982/files/4d70fc2f..15b69a4c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10982&range=21
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10982&range=20-21

  Stats: 59 lines in 9 files changed: 10 ins; 39 del; 10 mod
  Patch: https://git.openjdk.org/jdk/pull/10982.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10982/head:pull/10982

PR: https://git.openjdk.org/jdk/pull/10982

From asotona at openjdk.org  Fri Feb 17 11:46:58 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Fri, 17 Feb 2023 11:46:58 GMT
Subject: RFR: 8294982: Implementation of Classfile API [v15]
In-Reply-To: <AJgsunTEzUuzgdTQKiSBTXDrhs5_MmqNZWnSURk61AE=.b8e71cb6-1ccb-49f3-afda-d2a98f4ec701@github.com>
References: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
 <hr8eti6ytvV05JFRr5hYLWy7yBla9mpI8vKKfaaFR-k=.a92f7bea-6400-4f95-a40c-d57192013f19@github.com>
 <hUvPqC4427nX8mcEcC5Tr90RFXAtmNigTxexY_Ujf04=.55b5e41d-afa7-4220-b13f-6fb0dd25dd0e@github.com>
 <WjPpEjQMu0JRMC50Ah6GbGziijbdSSS_EUGbSJ_gH2I=.bafee453-7bfc-444d-93eb-8d3b9258a2fd@github.com>
 <CXD_fqRhrtJW65rK0-TQaDVNIS3EGBXMZIQgKFrkQv0=.4d4b2608-ce7e-407b-9d88-2f4e9654e672@github.com>
 <3HZ_jmmtzk1RUgiUGwGudTaqvzEbFkla14T4EDKSjxU=.1fd22057-627c-42df-80a1-1c7c37486c4c@github.com>
 <AJgsunTEzUuzgdTQKiSBTXDrhs5_MmqNZWnSURk61AE=.b8e71cb6-1ccb-49f3-afda-d2a98f4ec701@github.com>
Message-ID: <tA0IGrEw21mC9OLiLyKjXtEif0OkVmTojTosrj3NQnY=.e1046af4-33d1-4141-b225-92778df56895@github.com>

On Thu, 16 Feb 2023 10:48:49 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> The main difference is that if the given entry is not directly applicable (when it comes from 3rd constant pool or when the pool is not shared during transformation) - a new or matching entry to the target pool is returned.
>> This is not a builder pattern, this is projection of an entry to the target CP and it also prevents duplicates.
>
> `maybeClone` is not the main avenue, it is rather a helper method and I'll look at details if it is necessary too expose it.

`ConstantPoolBuilder::maybeClone` and `PoolEntry::clone` have been pulled from API to implementation

-------------

PR: https://git.openjdk.org/jdk/pull/10982

From jpai at openjdk.org  Fri Feb 17 12:03:54 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 17 Feb 2023 12:03:54 GMT
Subject: RFR: 8302664: Fix several incorrect usages of
 Preconditions.checkFromIndexSize
Message-ID: <OGxWiIU0cyZnhxHVLd-ulwHSuuV4OEc9GtLBUjZDGfM=.f2d0cdb7-17b2-4c7d-9490-12d95e7352c4@github.com>

Can I please get a review of this change which fixes the usage of `Preconditions.checkFromIndexSize`? This addresses https://bugs.openjdk.org/browse/JDK-8302664.

There was an oversight when these changes were introduced in https://github.com/openjdk/jdk/pull/4507. I have now gone through that patch again to make sure the relevant places where this fix is needed has been addressed in this current PR.

I have also looked into other changes in that PR, just to be sure that there aren't any similar fixes needed for other method calls that were introduced in it - they all look fine.

tier1,tier2 and tier3 testing with this change passed successfully. I thought (and experimented a bit) to add new tests for Deflater/Inflater to catch these byte array indexing issues, but it wasn't straight forward and I would have to write the entire inflate/deflate test just to verify this issue. So I decided to leave out new tests for now in this PR.

-------------

Commit messages:
 - 8302664: Fix several incorrect usages of Preconditions.checkFromIndexSize

Changes: https://git.openjdk.org/jdk/pull/12595/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12595&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8302664
  Stats: 19 lines in 8 files changed: 0 ins; 0 del; 19 mod
  Patch: https://git.openjdk.org/jdk/pull/12595.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12595/head:pull/12595

PR: https://git.openjdk.org/jdk/pull/12595

From djelinski at openjdk.org  Fri Feb 17 12:23:24 2023
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Fri, 17 Feb 2023 12:23:24 GMT
Subject: RFR: 8302664: Fix several incorrect usages of
 Preconditions.checkFromIndexSize
In-Reply-To: <OGxWiIU0cyZnhxHVLd-ulwHSuuV4OEc9GtLBUjZDGfM=.f2d0cdb7-17b2-4c7d-9490-12d95e7352c4@github.com>
References: <OGxWiIU0cyZnhxHVLd-ulwHSuuV4OEc9GtLBUjZDGfM=.f2d0cdb7-17b2-4c7d-9490-12d95e7352c4@github.com>
Message-ID: <AdJx5eUj5xdo9pNnxZuGFtNqM8wRt3WM56jTID-vQGw=.afdc7c0c-9ec3-46aa-81c7-49113b2d8ec2@github.com>

On Thu, 16 Feb 2023 14:42:52 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change which fixes the usage of `Preconditions.checkFromIndexSize`? This addresses https://bugs.openjdk.org/browse/JDK-8302664.
> 
> There was an oversight when these changes were introduced in https://github.com/openjdk/jdk/pull/4507. I have now gone through that patch again to make sure the relevant places where this fix is needed has been addressed in this current PR.
> 
> I have also looked into other changes in that PR, just to be sure that there aren't any similar fixes needed for other method calls that were introduced in it - they all look fine.
> 
> tier1,tier2 and tier3 testing with this change passed successfully. I thought (and experimented a bit) to add new tests for Deflater/Inflater to catch these byte array indexing issues, but it wasn't straight forward and I would have to write the entire inflate/deflate test just to verify this issue. So I decided to leave out new tests for now in this PR.

As far as I could tell, this only changes the generated exception message. The condition is (off+len<=size), so the exception will be thrown on the same input as before.

LGTM.

-------------

Marked as reviewed by djelinski (Committer).

PR: https://git.openjdk.org/jdk/pull/12595

From dfuchs at openjdk.org  Fri Feb 17 13:12:50 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 17 Feb 2023 13:12:50 GMT
Subject: RFR: 8302664: Fix several incorrect usages of
 Preconditions.checkFromIndexSize
In-Reply-To: <OGxWiIU0cyZnhxHVLd-ulwHSuuV4OEc9GtLBUjZDGfM=.f2d0cdb7-17b2-4c7d-9490-12d95e7352c4@github.com>
References: <OGxWiIU0cyZnhxHVLd-ulwHSuuV4OEc9GtLBUjZDGfM=.f2d0cdb7-17b2-4c7d-9490-12d95e7352c4@github.com>
Message-ID: <Z7g4goLvmpP3PhLI8bwd189nEwQwR1ZkwjKcluw0JrE=.ac578c4e-0d64-4ae6-8c98-ea59e2a65806@github.com>

On Thu, 16 Feb 2023 14:42:52 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change which fixes the usage of `Preconditions.checkFromIndexSize`? This addresses https://bugs.openjdk.org/browse/JDK-8302664.
> 
> There was an oversight when these changes were introduced in https://github.com/openjdk/jdk/pull/4507. I have now gone through that patch again to make sure the relevant places where this fix is needed has been addressed in this current PR.
> 
> I have also looked into other changes in that PR, just to be sure that there aren't any similar fixes needed for other method calls that were introduced in it - they all look fine.
> 
> tier1,tier2 and tier3 testing with this change passed successfully. I thought (and experimented a bit) to add new tests for Deflater/Inflater to catch these byte array indexing issues, but it wasn't straight forward and I would have to write the entire inflate/deflate test just to verify this issue. So I decided to leave out new tests for now in this PR.

As Daniel noted the computation is symmetrical which explains why it worked. But passing inverted parameters was confusing. LGTM2.

-------------

Marked as reviewed by dfuchs (Reviewer).

PR: https://git.openjdk.org/jdk/pull/12595

From dfuchs at openjdk.org  Fri Feb 17 13:14:50 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 17 Feb 2023 13:14:50 GMT
Subject: RFR: 8298939: Refactor
 open/test/jdk/javax/rmi/ssl/SSLSocketParametersTest.sh to jtreg java test [v3]
In-Reply-To: <y65OxkcJ9OlzgC1Q-o62zILzqMIQA9SQk_pg6zdpe7U=.d7745cdf-f803-45bd-a3fb-8d6bb146c2c2@github.com>
References: <VC_ou2XS44PtyTfwXw0VZRtXcHEbXImlLZKniIPRqOw=.7d10a168-77f8-4552-97a3-8b2570e3fe29@github.com>
 <y65OxkcJ9OlzgC1Q-o62zILzqMIQA9SQk_pg6zdpe7U=.d7745cdf-f803-45bd-a3fb-8d6bb146c2c2@github.com>
Message-ID: <tpH8i7KB0C0mfbSnKPjs_CdvuAG0wbhtQTHO3newUug=.40ae3fe5-93c4-47e9-a1ce-58156a6c43e0@github.com>

On Tue, 7 Feb 2023 20:38:40 GMT, Matthew Donovan <duke at openjdk.org> wrote:

>> Removed SSLSocketParametersTest.sh script (which just called a Java file) and configured the java code to run directly with jtreg
>
> Matthew Donovan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   added exceptions for cases 4 and 5

Thanks for the update. I believe this looks good, but it would be nice to get @stuart-marks or @RogerRiggs approval before integrating.

-------------

Marked as reviewed by dfuchs (Reviewer).

PR: https://git.openjdk.org/jdk/pull/11910

From rrich at openjdk.org  Fri Feb 17 13:25:57 2023
From: rrich at openjdk.org (Richard Reingruber)
Date: Fri, 17 Feb 2023 13:25:57 GMT
Subject: RFR: 8302158: PPC:
 test/jdk/jdk/internal/vm/Continuation/Fuzz.java: AssertionError: res: false
 shouldPin: false [v2]
In-Reply-To: <MmOeDc2ETuOsVcS-R-noo92M35DdOLpbOapofWah5Mg=.051144c9-71c6-48bc-8017-477894177ce0@github.com>
References: <G-cEPYqp6JlMkj9qo0S9HuNXRiuROZ7q69FQYIsDewM=.d20f3ee3-ed25-4bd3-93cd-2a55faa515d3@github.com>
 <MmOeDc2ETuOsVcS-R-noo92M35DdOLpbOapofWah5Mg=.051144c9-71c6-48bc-8017-477894177ce0@github.com>
Message-ID: <p9XD2yZM_KoI_iDaMpTbSypVGUZh8pL7FsjOykYT_38=.71405537-4324-4c8e-9611-c2741dddf380@github.com>

On Wed, 15 Feb 2023 20:30:00 GMT, Richard Reingruber <rrich at openjdk.org> wrote:

>> This fixes the linked issue by trimming the caller of a frame to be deoptimized back to its `unextended_sp` iff it is compiled. The creation of the section `dead after deoptimization` shown in the attachment [yield_after_deopt_failure.log](https://bugs.openjdk.org/secure/attachment/102602/yield_after_deopt_failure.log) is prevented by this.
>> 
>> A new mode is added to the test BasicExt.java where all frames are deoptimized after a yield operation. The issue can be deterministically reproduced with the new mode. It's not worth to execute all test cases with the new mode though. Instead `ContinuationCompiledFramesWithStackArgs_3c4` is always executed a 2nd time in this mode.
>> 
>> Before this BasicExt.java was refactored for better argument processing and representation of the test modes.
>> Also the try-catch-clause in the main method had to be changed to rethrow the caught exception because without this the test would have succeeded.
>> 
>> Testing: jtreg tests tier 1-4 on standard platforms and also on ppc64le.
>
> Richard Reingruber has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Improve comment
>  - Improve comment
>  - Spelling

Thanks for the reviews!

-------------

PR: https://git.openjdk.org/jdk/pull/12557

From asotona at openjdk.org  Fri Feb 17 13:25:52 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Fri, 17 Feb 2023 13:25:52 GMT
Subject: RFR: 8294982: Implementation of Classfile API [v23]
In-Reply-To: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
References: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
Message-ID: <wshKgaF_Q9nQz9zd4f0sjt-yf_YDkmAy2I9USi_P8bI=.3d0f930d-08f0-47c1-a239-7f6009c41c27@github.com>

> This is root pull request with Classfile API implementation, tests and benchmarks initial drop into JDK.
> 
> Following pull requests consolidating JDK class files parsing, generating, and transforming ([JDK-8294957](https://bugs.openjdk.org/browse/JDK-8294957)) will chain to this one.
> 
> Classfile API development is tracked at:
> https://github.com/openjdk/jdk-sandbox/tree/classfile-api-branch
> 
> Development branch of consolidated JDK class files parsing, generating, and transforming is at:
> https://github.com/openjdk/jdk-sandbox/tree/classfile-api-dev-branch
> 
> Classfile API [JEP](https://bugs.openjdk.org/browse/JDK-8280389) and [online API documentation](https://htmlpreview.github.io/?https://raw.githubusercontent.com/openjdk/jdk-sandbox/classfile-api-javadoc-branch/doc/classfile-api/javadoc/java.base/jdk/internal/classfile/package-summary.html) is also available.
> 
> Please take you time to review this non-trivial JDK addition.
> 
> Thank you,
> Adam

Adam Sotona has updated the pull request incrementally with two additional commits since the last revision:

 - javadoc fix
 - renamed PoolEntry::poolEntries to ::width

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10982/files
  - new: https://git.openjdk.org/jdk/pull/10982/files/15b69a4c..1bf62016

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10982&range=22
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10982&range=21-22

  Stats: 14 lines in 7 files changed: 1 ins; 0 del; 13 mod
  Patch: https://git.openjdk.org/jdk/pull/10982.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10982/head:pull/10982

PR: https://git.openjdk.org/jdk/pull/10982

From asotona at openjdk.org  Fri Feb 17 13:26:50 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Fri, 17 Feb 2023 13:26:50 GMT
Subject: RFR: 8294982: Implementation of Classfile API [v15]
In-Reply-To: <hUvPqC4427nX8mcEcC5Tr90RFXAtmNigTxexY_Ujf04=.55b5e41d-afa7-4220-b13f-6fb0dd25dd0e@github.com>
References: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
 <hr8eti6ytvV05JFRr5hYLWy7yBla9mpI8vKKfaaFR-k=.a92f7bea-6400-4f95-a40c-d57192013f19@github.com>
 <hUvPqC4427nX8mcEcC5Tr90RFXAtmNigTxexY_Ujf04=.55b5e41d-afa7-4220-b13f-6fb0dd25dd0e@github.com>
Message-ID: <uRqvNOIr4t5EwOCfnTz6c-cWmL3iUOtlk3cvMEdqy60=.0e4955c3-e9b8-4602-b714-d76a703ab323@github.com>

On Thu, 9 Feb 2023 14:07:32 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   AttributeElement.Kind removal (#48)
>
> src/java.base/share/classes/jdk/internal/classfile/constantpool/MethodHandleEntry.java line 40:
> 
>> 38: 
>> 39:     /**
>> 40:      * {@return the reference kind of this method handle}
> 
> Where are the constants that can be used to decode the MH kind? Perhaps a reference from the javadoc could be helpful.

Fixed, thanks.

> src/java.base/share/classes/jdk/internal/classfile/constantpool/PoolEntry.java line 55:
> 
>> 53:      * {@return the number of constant pool slots this entry consumes}
>> 54:      */
>> 55:     int poolEntries();
> 
> maybe `width` ?

Yes, it sounds better. Fixed, thanks.

-------------

PR: https://git.openjdk.org/jdk/pull/10982

From alanb at openjdk.org  Fri Feb 17 13:38:27 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 17 Feb 2023 13:38:27 GMT
Subject: RFR: 8302664: Fix several incorrect usages of
 Preconditions.checkFromIndexSize
In-Reply-To: <OGxWiIU0cyZnhxHVLd-ulwHSuuV4OEc9GtLBUjZDGfM=.f2d0cdb7-17b2-4c7d-9490-12d95e7352c4@github.com>
References: <OGxWiIU0cyZnhxHVLd-ulwHSuuV4OEc9GtLBUjZDGfM=.f2d0cdb7-17b2-4c7d-9490-12d95e7352c4@github.com>
Message-ID: <Qxe0NasER1twnBSN6DAT8iTPLwxan0fgXsawuXLYIas=.7949dde1-2510-45b1-8dc8-0f788fb7a4df@github.com>

On Thu, 16 Feb 2023 14:42:52 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change which fixes the usage of `Preconditions.checkFromIndexSize`? This addresses https://bugs.openjdk.org/browse/JDK-8302664.
> 
> There was an oversight when these changes were introduced in https://github.com/openjdk/jdk/pull/4507. I have now gone through that patch again to make sure the relevant places where this fix is needed has been addressed in this current PR.
> 
> I have also looked into other changes in that PR, just to be sure that there aren't any similar fixes needed for other method calls that were introduced in it - they all look fine.
> 
> tier1,tier2 and tier3 testing with this change passed successfully. I thought (and experimented a bit) to add new tests for Deflater/Inflater to catch these byte array indexing issues, but it wasn't straight forward and I would have to write the entire inflate/deflate test just to verify this issue. So I decided to leave out new tests for now in this PR.

It's easy to get the parameters wrong to these methods but if the fromIndex and size are mixed up then it should just impact the exception message.

-------------

Marked as reviewed by alanb (Reviewer).

PR: https://git.openjdk.org/jdk/pull/12595

From rrich at openjdk.org  Fri Feb 17 13:43:27 2023
From: rrich at openjdk.org (Richard Reingruber)
Date: Fri, 17 Feb 2023 13:43:27 GMT
Subject: Integrated: 8302158: PPC:
 test/jdk/jdk/internal/vm/Continuation/Fuzz.java: AssertionError: res: false
 shouldPin: false
In-Reply-To: <G-cEPYqp6JlMkj9qo0S9HuNXRiuROZ7q69FQYIsDewM=.d20f3ee3-ed25-4bd3-93cd-2a55faa515d3@github.com>
References: <G-cEPYqp6JlMkj9qo0S9HuNXRiuROZ7q69FQYIsDewM=.d20f3ee3-ed25-4bd3-93cd-2a55faa515d3@github.com>
Message-ID: <EbSeI16vIF8Vbg32hxXWSbLkMBJzvLOK6XnNEb1_nes=.8b567269-29e8-42c2-ab07-641091ccc3ee@github.com>

On Tue, 14 Feb 2023 14:10:08 GMT, Richard Reingruber <rrich at openjdk.org> wrote:

> This fixes the linked issue by trimming the caller of a frame to be deoptimized back to its `unextended_sp` iff it is compiled. The creation of the section `dead after deoptimization` shown in the attachment [yield_after_deopt_failure.log](https://bugs.openjdk.org/secure/attachment/102602/yield_after_deopt_failure.log) is prevented by this.
> 
> A new mode is added to the test BasicExt.java where all frames are deoptimized after a yield operation. The issue can be deterministically reproduced with the new mode. It's not worth to execute all test cases with the new mode though. Instead `ContinuationCompiledFramesWithStackArgs_3c4` is always executed a 2nd time in this mode.
> 
> Before this BasicExt.java was refactored for better argument processing and representation of the test modes.
> Also the try-catch-clause in the main method had to be changed to rethrow the caught exception because without this the test would have succeeded.
> 
> Testing: jtreg tests tier 1-4 on standard platforms and also on ppc64le.

This pull request has now been integrated.

Changeset: b8c9d6cd
Author:    Richard Reingruber <rrich at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/b8c9d6cdf60ea5e680eb00d5c01a1c4d2ed04006
Stats:     207 lines in 3 files changed: 152 ins; 13 del; 42 mod

8302158: PPC: test/jdk/jdk/internal/vm/Continuation/Fuzz.java: AssertionError: res: false shouldPin: false

Reviewed-by: goetz, mdoerr

-------------

PR: https://git.openjdk.org/jdk/pull/12557

From duke at openjdk.org  Fri Feb 17 13:54:50 2023
From: duke at openjdk.org (David M. Lloyd)
Date: Fri, 17 Feb 2023 13:54:50 GMT
Subject: RFR: 8292914: Drop the counter from lambda class names [v6]
In-Reply-To: <zlDm2W50G6NgRkzmgEpX6MTVs3XyYMnY3tN1YnObWUA=.03a3d8d7-4d20-4fc6-8028-b20a8603b0a6@github.com>
References: <GgLfH-ueBQqT-Mfk1mKpKFAt8fYqyjfVJ9lmlsBsCbo=.8dd5b3b4-4e84-4970-9179-1c0399b30edc@github.com>
 <zlDm2W50G6NgRkzmgEpX6MTVs3XyYMnY3tN1YnObWUA=.03a3d8d7-4d20-4fc6-8028-b20a8603b0a6@github.com>
Message-ID: <ap_cLtCb41KZdWeYErFfMlRG4GOxlHq6TV3hYpHX4zk=.e63d0d35-6c79-4927-b463-94c768c92f84@github.com>

On Thu, 16 Feb 2023 19:35:54 GMT, David M. Lloyd <duke at openjdk.org> wrote:

>> The class generated for lambda proxies is now defined as a hidden class. This means that the counter, which was used to ensure a unique class name and avoid clashes, is now redundant. In addition to performing redundant work, this also impacts build reproducibility for native image generators which might already have a strategy to cope with hidden classes but cannot cope with indeterminate definition order for lambda proxy classes.
>> 
>> This solves JDK-8292914 by making lambda proxy names always be stable without any configuration needed. This would also replace #10024.
>
> David M. Lloyd has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use a unique index for the dumped lambda class instead of a time stamp

> This proposal is appealing for its simplicity, however, there are points from [JDK-8292914](https://bugs.openjdk.org/browse/JDK-8292914) that it does not address:
> 
> 1. _To register lambda classes for serialization_. In this case, the agent run would register all lambdas from the capturing class for serialization: there would be no identifier to distinguish one lambda from another.

In the serialized lambda representation, the lambda proxy class name should not have any part to play at all, since it's all handled using `SerializedLambda` and the generated `$deserializeLambda$` method. Right?

> 2. _For reproducible builds_. This PR makes a small step towards reproducible builds, however, it complicates the implementation on the Native Image side significantly. Now, as each class needs a unique name, we must create the unique (and stable) lambda-proxy name for all lambdas within a capturing class. This is hard with parallel static analysis as methods are discovered concurrently, and hence non-deterministically. When we discover a class, we would need to find all of its captured lambdas, then perform a deterministic traversal of the class' bytecode in order to give lambda-proxies a stable name. For such an implementation we don't even need this PR as we can simply strip the sequence number from the name and invent a new one.

This isn't just a problem for lambda proxies. All hidden classes in fact share this common challenge; the defined class name is not sufficient to identify the class because any number of hidden classes may have the same base name. In qbicc, we now compute the hidden class's unique sub-identifier using a cryptographic hash function over the body of the class. This helps reproducibility for us since the same object file name (and symbol names) will always be generated for the same input class bytes. And it works not just for lambda proxies, but also lambda forms and method handle/direct method handle classes, as well as user-defined hidden classes.

> 3. _To collect profiles of lambda methods for profile-guided optimizations_. With all captured lambdas having the same name, we would get polluted profiles and lose on performance.

These classes are hidden classes, and the problem applies broadly to that case; so, if you want to have accurate profiles, you *must* have a reproducible sub-identifier for *every* hidden class, otherwise you'll have the same problem all over again.

> 4. _To reflectively access lambdas_. Again we would not be able to distinguish between lambdas in the same capturing class and hence we would get imprecise reflection registration.

The same thing applies, I think. You need to solve this problem for *all* hidden classes, not just lambda proxies. And by solving the problem for hidden classes, you only need the solution in one place; having an additional scheme for lambda proxies will only introduce problems at this point.

> @dmlloyd Maybe I am missing something, but I don't understand how does this PR make the builds more reproducible?

Given that a reproducibility solution must exist for native image generators which gives stable identifiers to all hidden classes (not just lambda proxies), removing sequence numbers from hidden class generation is what actually would allow such a solution to work. Having an unpredictable sequence number in the class name means that each time the class is built, it may have different content (and this, in our case at least, a different cryptographic hash). So to prevent lambda proxy generation from undermining general reproducibility of hidden classes, the simplest solution is to always use the same base name. Thus, removing the sequence number (as done in this PR) enables reproducibility.

Incidentally, through this scheme I discovered that there are multiple cases where the JDK will define more than one identical class, for lambda proxies and for method handles at least, which have the same content. There could be an optimization opportunity there (or more than one).

-------------

PR: https://git.openjdk.org/jdk/pull/12579

From jwaters at openjdk.org  Fri Feb 17 14:08:34 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Fri, 17 Feb 2023 14:08:34 GMT
Subject: RFR: 8302667: Improve message format when failing to load symbols
 or libraries [v2]
In-Reply-To: <tu4ol4DO1PeplhgjhkYpXLwES142ztBXsM43uQO_CNE=.bfca85a4-2323-487d-9261-964671e00bf3@github.com>
References: <tu4ol4DO1PeplhgjhkYpXLwES142ztBXsM43uQO_CNE=.bfca85a4-2323-487d-9261-964671e00bf3@github.com>
Message-ID: <B-eIiBotI3cwCwWY5r2xYPlHfnV4dKJIHJdwg-hbDeQ=.ff83dbdf-e456-48b7-aa7f-e8cf75f71b5a@github.com>

> DLL_ERROR4 is a macro expanding to an error message when a failure to load a generic item (shared libraries or an exported symbol from said libraries for example) occurs. "Error: loading:" is not a very pretty message, so this small change results in "Error: Failed to load %s" instead, which looks better and also means the message makes more sense if we want to append a reason behind as well, such as "Error: Failed to load libjvm.so because xxx"

Julian Waters 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 'openjdk:master' into patch-6
 - Error: Failed to load

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12596/files
  - new: https://git.openjdk.org/jdk/pull/12596/files/43afc03a..5f4370f8

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12596&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12596&range=00-01

  Stats: 4003 lines in 132 files changed: 2148 ins; 635 del; 1220 mod
  Patch: https://git.openjdk.org/jdk/pull/12596.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12596/head:pull/12596

PR: https://git.openjdk.org/jdk/pull/12596

From erikj at openjdk.org  Fri Feb 17 14:29:50 2023
From: erikj at openjdk.org (Erik Joelsson)
Date: Fri, 17 Feb 2023 14:29:50 GMT
Subject: RFR: 8302226 failure_handler native.core should wait for coredump
 to finish [v2]
In-Reply-To: <2-fRnycvALxQrNO1Pw0oh0MUU8Xb3_4xmjSwI6PQzBM=.77e0dabf-82ed-4a6e-ad71-809a96939b82@github.com>
References: <5k6enBnRlLOZsW9Dp3NWLwiw-JeURwl-9omJht157vY=.dc8401f6-5b3d-4997-aee2-0003b1a01ab9@github.com>
 <2-fRnycvALxQrNO1Pw0oh0MUU8Xb3_4xmjSwI6PQzBM=.77e0dabf-82ed-4a6e-ad71-809a96939b82@github.com>
Message-ID: <RAve0WwTIc6wn5J3YGqideJcM8WeU5y6nQLzJVvcut8=.e053bc8a-8832-4fbb-bcc6-c9af86d90dd0@github.com>

On Mon, 13 Feb 2023 10:21:05 GMT, Ludvig Janiuk <lujaniuk at openjdk.org> wrote:

>> Update open/test/failure_handler/src/share/conf/(linux,mac).properties to handle core dumps more correctly.
>
> Ludvig Janiuk has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add mac

Marked as reviewed by erikj (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/12515

From rgiulietti at openjdk.org  Fri Feb 17 14:31:20 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Fri, 17 Feb 2023 14:31:20 GMT
Subject: RFR: JDK-8302028: Port fdlibm atan2 to Java [v2]
In-Reply-To: <TMI7ZKI2Qc9DL_wLKNwMXAtu7hstoL-mrZjEIsv-MT0=.dace04d5-ec7e-40c2-b540-4e1f5e68bd38@github.com>
References: <xl79M-V4_2t49GuCudJHQBaJjAcwWl9f2Bv19RbAmdo=.b9c97066-8cf4-4569-8b4b-8b4874e23833@github.com>
 <TMI7ZKI2Qc9DL_wLKNwMXAtu7hstoL-mrZjEIsv-MT0=.dace04d5-ec7e-40c2-b540-4e1f5e68bd38@github.com>
Message-ID: <FSMfXwXXxe2sBtxB5J641Hh9o8WKPX2k7-n2bpOhrWU=.e8281db1-ecc4-43e0-bbe2-1c419e1111f0@github.com>

On Fri, 17 Feb 2023 04:18:30 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Working down the porting list, next stop, atan2.
>
> Joe Darcy 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:
> 
>  - Update regression test.
>  - Merge branch 'master' into JDK-8302028
>  - JDK-8302028: Port fdlibm atan2 to Java

src/java.base/share/classes/java/lang/FdLibm.java line 447:

> 445:             ly = __LO(y);
> 446:             if (((ix | ((lx | -lx) >> 31)) > 0x7ff0_0000)||
> 447:                 ((iy |((ly | - ly) >> 31)) > 0x7ff0_0000))    // x or y is NaN

I think that `>> 31` must be replaced by `>>> 31`.

src/java.base/share/classes/java/lang/FdLibm.java line 458:

> 456:                 case 0, 1 ->  y;              // atan(+/-0, +anything)  = +/-0
> 457:                 case 2    ->  Math.PI + tiny; // atan(+0,   -anything)  =  pi
> 458:                 default   -> -Math.PI - tiny; // atan(-0,   -anything)  = -pi

The original switch statement and this switch expression are semantically equivalent only because of our knowledge that `m` can only assume values 0, 1, 2, or 3. This requires more reasoning than a more verbatim copy of the original statement. Not sure if it is worth.

The same holds for the switch expressions below.

test/jdk/java/lang/Math/Atan2Tests.java line 214:

> 212:             /*
> 213:              * If both arguments are negative infinity, then the result is the
> 214:              * double value closest to -3*pi/4.

Perhaps add a note explaining that high precision computation shows that `-3*PI/4.0` is indeed the `double` closest to -3*pi/4.
Since `PI` is an approximation in the first place, and since there are other two operations (in particular, the multiplication by 3), the claim is not evident.

test/jdk/java/lang/StrictMath/FdlibmTranslit.java line 451:

> 449:             ly = __LO(y);
> 450:             if(((ix|((lx|-lx)>>31))>0x7ff00000)||
> 451:                ((iy|((ly|-ly)>>31))>0x7ff00000))    /* x or y is NaN */

I think that `>>31` must be replaced by `>>>31`.

test/jdk/java/lang/StrictMath/FdlibmTranslit.java line 480:

> 478:                     switch(m) {
> 479:                     case 0: return  zero  ;     /* atan(+...,+INF) */
> 480:                     case 1: return -1.0*zero  ; /* atan(-...,+INF) */

The file in the [netlib repo](https://netlib.org/fdlibm/e_atan2.c) has `-zero` rather than `-1.0*zero`.

-------------

PR: https://git.openjdk.org/jdk/pull/12608

From lujaniuk at openjdk.org  Fri Feb 17 15:11:51 2023
From: lujaniuk at openjdk.org (Ludvig Janiuk)
Date: Fri, 17 Feb 2023 15:11:51 GMT
Subject: Integrated: 8302226 failure_handler native.core should wait for
 coredump to finish
In-Reply-To: <5k6enBnRlLOZsW9Dp3NWLwiw-JeURwl-9omJht157vY=.dc8401f6-5b3d-4997-aee2-0003b1a01ab9@github.com>
References: <5k6enBnRlLOZsW9Dp3NWLwiw-JeURwl-9omJht157vY=.dc8401f6-5b3d-4997-aee2-0003b1a01ab9@github.com>
Message-ID: <JTcs0_D8kIKIwWRrQAB8CQx_OWmbcm6B6PlwmTP_cH4=.8130fc9b-4ee7-4542-95f0-e7549f37bed7@github.com>

On Fri, 10 Feb 2023 18:19:01 GMT, Ludvig Janiuk <lujaniuk at openjdk.org> wrote:

> Update open/test/failure_handler/src/share/conf/(linux,mac).properties to handle core dumps more correctly.

This pull request has now been integrated.

Changeset: 6120319a
Author:    Ludvig Janiuk <lujaniuk at openjdk.org>
Committer: Erik Joelsson <erikj at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/6120319afdba98b5ff547b870a0260479e8b683c
Stats:     10 lines in 2 files changed: 6 ins; 0 del; 4 mod

8302226: failure_handler native.core should wait for coredump to finish

Reviewed-by: erikj

-------------

PR: https://git.openjdk.org/jdk/pull/12515

From rgiulietti at openjdk.org  Fri Feb 17 15:35:23 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Fri, 17 Feb 2023 15:35:23 GMT
Subject: RFR: 8302204: Optimize BigDecimal.divide
In-Reply-To: <BRkM6aFrRPiaBHH-qBGTlRUnFqfyP1oY719xN5_hCLU=.3b6adaff-ee4b-4ba3-b28b-46bea061f0b0@github.com>
References: <rUC0Dh_-1E0PZNJwM0GRH1KPu6prPotT-oeDTUdqjI4=.a8f7d3b7-a0f2-45a0-ae01-f37ef108d18f@github.com>
 <33muq0xW2ZRW13PAjRpOFAMFC2e1iZ_pR_4SXupx7pk=.02db719e-4919-43b8-a6ca-b87e115007f9@github.com>
 <M0Ns-XC0XrTfVXh_4uRgLefHZDnNtcmjUyqBtQ_qArA=.d36c40c0-441c-4609-a0e5-ed5e84c49f77@github.com>
 <BRkM6aFrRPiaBHH-qBGTlRUnFqfyP1oY719xN5_hCLU=.3b6adaff-ee4b-4ba3-b28b-46bea061f0b0@github.com>
Message-ID: <uozQ5DUUVPEMu5ZnuiA_fxb2Qo3TU3jHRQafwminiyg=.e7c0a9bf-0f8e-4ec5-996c-81b7cd9e5699@github.com>

On Fri, 17 Feb 2023 08:58:13 GMT, Xiaowei Lu <duke at openjdk.org> wrote:

> > After making sure that `intVal` is even, and before attempting a division by a power of 10, it might help to check if 5 divides `intVal` in the first place. If it doesn't, there no point in performing the division.
> > It can be shown that 5 divides `intVal` if and only if it divides the `long` sum of all `int`s in the `mag` array of `intVal`.
> > I didn't try out if this contributes to improve the overall performance, but it might be worth giving a try.
> 
> Unfortunately, it seems this division by 5 doesn't give an obvious performance improvement. Maybe previous lowest bit check has filtered some cases.

Thanks for trying out.

-------------

PR: https://git.openjdk.org/jdk/pull/12509

From duke at openjdk.org  Fri Feb 17 15:35:24 2023
From: duke at openjdk.org (Vojin Jovanovic)
Date: Fri, 17 Feb 2023 15:35:24 GMT
Subject: RFR: 8292914: Drop the counter from lambda class names [v6]
In-Reply-To: <zlDm2W50G6NgRkzmgEpX6MTVs3XyYMnY3tN1YnObWUA=.03a3d8d7-4d20-4fc6-8028-b20a8603b0a6@github.com>
References: <GgLfH-ueBQqT-Mfk1mKpKFAt8fYqyjfVJ9lmlsBsCbo=.8dd5b3b4-4e84-4970-9179-1c0399b30edc@github.com>
 <zlDm2W50G6NgRkzmgEpX6MTVs3XyYMnY3tN1YnObWUA=.03a3d8d7-4d20-4fc6-8028-b20a8603b0a6@github.com>
Message-ID: <KUfH-M4rLZZgA3XuId4y6qSmhCC8JGzLj8aadcH0mFc=.b98e2ca6-2a59-47a6-98f7-933494dbf8b9@github.com>

On Thu, 16 Feb 2023 19:35:54 GMT, David M. Lloyd <duke at openjdk.org> wrote:

>> The class generated for lambda proxies is now defined as a hidden class. This means that the counter, which was used to ensure a unique class name and avoid clashes, is now redundant. In addition to performing redundant work, this also impacts build reproducibility for native image generators which might already have a strategy to cope with hidden classes but cannot cope with indeterminate definition order for lambda proxy classes.
>> 
>> This solves JDK-8292914 by making lambda proxy names always be stable without any configuration needed. This would also replace #10024.
>
> David M. Lloyd has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use a unique index for the dumped lambda class instead of a time stamp

We didn't use the cryptographic hash as it is not resilient to the changes that happen to the bytecode generators of hidden classes. If anything in the bytecode generation (e.g., in `InnerClassLambdaMetafactory`) changes, the hashes stored in the metadata files will not be valid anymore. The prime example of this is the change in the class version between different JDKs. This makes [reachability metadata](https://www.graalvm.org/22.2/reference-manual/native-image/metadata/) useless across different versions of the JDK. This is especially problematic for cases such as:

  https://github.com/oracle/graalvm-reachability-metadata

Given lambdas are in almost every stack trace, it is good for debugging that their names are clearly distinguishable. Adding a stable and unique hash to the lambda name as in #10024 does that and does not conflict with computing the cryptographic hash if it is needed by `qbicc`. I would argue that #10024 improves the debugging experience, especially in multi-threaded environments where lambda names can be unstable with the current scheme.

-------------

PR: https://git.openjdk.org/jdk/pull/12579

From rriggs at openjdk.org  Fri Feb 17 15:35:50 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 17 Feb 2023 15:35:50 GMT
Subject: RFR: 8298939: Refactor
 open/test/jdk/javax/rmi/ssl/SSLSocketParametersTest.sh to jtreg java test [v3]
In-Reply-To: <y65OxkcJ9OlzgC1Q-o62zILzqMIQA9SQk_pg6zdpe7U=.d7745cdf-f803-45bd-a3fb-8d6bb146c2c2@github.com>
References: <VC_ou2XS44PtyTfwXw0VZRtXcHEbXImlLZKniIPRqOw=.7d10a168-77f8-4552-97a3-8b2570e3fe29@github.com>
 <y65OxkcJ9OlzgC1Q-o62zILzqMIQA9SQk_pg6zdpe7U=.d7745cdf-f803-45bd-a3fb-8d6bb146c2c2@github.com>
Message-ID: <VhLDvwJ54UU63L4emLdpQvO425M03Mp8FPoUzU4iusQ=.218d2b73-c6dc-4e22-b62d-b36e3a411898@github.com>

On Tue, 7 Feb 2023 20:38:40 GMT, Matthew Donovan <duke at openjdk.org> wrote:

>> Removed SSLSocketParametersTest.sh script (which just called a Java file) and configured the java code to run directly with jtreg
>
> Matthew Donovan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   added exceptions for cases 4 and 5

Changes requested by rriggs (Reviewer).

test/jdk/javax/rmi/ssl/SSLSocketParametersTest.java line 34:

> 32:  * @run main/othervm SSLSocketParametersTest 5
> 33:  * @run main/othervm SSLSocketParametersTest 6
> 34:  * @run main/othervm SSLSocketParametersTest 7

Is a fresh VM needed for each of these tests?
>From a naive point of view it appears that 1, 2, 3, 4, 6, 7 use the same system properties.
The tests would complete more quickly if they could run the compatible tests in a single VM.
Perhaps main() could iterate over the args[n] and run the corresponding test.

test/jdk/javax/rmi/ssl/SSLSocketParametersTest.java line 168:

> 166:     public void runTest(String[] args) {
> 167: 
> 168:         int test = Integer.parseInt(args[0]);

Move the parseInt to main() and call runTest with the test number.

test/jdk/javax/rmi/ssl/SSLSocketParametersTest.java line 261:

> 259:             }
> 260:             break;
> 261:         default:

The default should be retained to produce an error.

-------------

PR: https://git.openjdk.org/jdk/pull/11910

From rriggs at openjdk.org  Fri Feb 17 16:37:20 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 17 Feb 2023 16:37:20 GMT
Subject: RFR: 8301627: System.exit and Runtime.exit debug logging [v5]
In-Reply-To: <rRRpsdK-9ODfmcIXOJvV6bQt5imHiLXjg4zJmiCWZSA=.e9127bda-35ed-49d0-981b-f7562065ecdc@github.com>
References: <OzJeJH5yxolKPChcUisqtzGYF_MU3oOJdx6HPhsXjBw=.15eefe39-efe1-433e-a6ac-02b4a730f264@github.com>
 <-WX4sORgC6ML_rXmQLArPbpKD0qFVDUtUwdHkOmSShQ=.c1e1666d-8a6e-412f-829a-f251abb853a6@github.com>
 <rRRpsdK-9ODfmcIXOJvV6bQt5imHiLXjg4zJmiCWZSA=.e9127bda-35ed-49d0-981b-f7562065ecdc@github.com>
Message-ID: <bXH6heRFzX2THfpwPqiIcbsisLtF9ly0l8h9Zo1qBks=.1e1c984f-291c-41c5-a909-cf09acc26432@github.com>

On Fri, 17 Feb 2023 07:48:41 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Improve implNote for Runtime.exit() with review suggestions.
>
> src/java.base/share/classes/java/lang/Runtime.java line 162:
> 
>> 160:      * If the {@link System#getLogger(String) the system logger} for {@code java.lang.Runtime}
>> 161:      * is enabled with logging level {@link System.Logger.Level#DEBUG Level.DEBUG} the stack trace
>> 162:      * of the call to {@code Runtime.exit()} is logged.
> 
> Have you ruled out adding the implNote to System.exit too? Asking as I suspect it's more likely to be read there.

I'll add an implNote to System.exit, and update the CSR.

     * @implNote
     * The initiation of the shutdown sequence is logged by {@link Runtime#exit(int)}.

-------------

PR: https://git.openjdk.org/jdk/pull/12517

From psandoz at openjdk.org  Fri Feb 17 16:58:50 2023
From: psandoz at openjdk.org (Paul Sandoz)
Date: Fri, 17 Feb 2023 16:58:50 GMT
Subject: RFR: JDK-8302666: Replace CHM with VarHandle in ForeachOrderedTask
 [v2]
In-Reply-To: <fLSt64PoI3s47g0BLWPMUkim0lmnuZ6wxoBJZppqgqg=.36deb86f-2998-490d-9e29-903e142c72d1@github.com>
References: <HAgE8xmpZT_2-b5ZDr8TgJNgjhVb3D4ZS3sQqA7c6Mo=.389fa590-681c-44a9-9823-8f70a6129797@github.com>
 <fLSt64PoI3s47g0BLWPMUkim0lmnuZ6wxoBJZppqgqg=.36deb86f-2998-490d-9e29-903e142c72d1@github.com>
Message-ID: <8S7Q0oMLcMo96x4Al5iiUspFDcgqk_tRavYCoDM1cbs=.0a3ccbe9-e199-4dbb-a1c1-252b4e906b86@github.com>

On Fri, 17 Feb 2023 11:39:21 GMT, Viktor Klang <duke at openjdk.org> wrote:

>> I noticed when looking at the code that there was no real need to use a CHM to perform the tracking of activation in an ordered fashion on ForEachOrderedTask, but instead a VarHandle can be used, reducing allocations and indirection.
>
> Viktor Klang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Write the initial value of the next reference without using the VarHandle

That's a nice find, looks good. (Update the year in the copyright header.)

-------------

Marked as reviewed by psandoz (Reviewer).

PR: https://git.openjdk.org/jdk/pull/12320

From duke at openjdk.org  Fri Feb 17 17:02:56 2023
From: duke at openjdk.org (David M. Lloyd)
Date: Fri, 17 Feb 2023 17:02:56 GMT
Subject: RFR: 8292914: Drop the counter from lambda class names [v7]
In-Reply-To: <GgLfH-ueBQqT-Mfk1mKpKFAt8fYqyjfVJ9lmlsBsCbo=.8dd5b3b4-4e84-4970-9179-1c0399b30edc@github.com>
References: <GgLfH-ueBQqT-Mfk1mKpKFAt8fYqyjfVJ9lmlsBsCbo=.8dd5b3b4-4e84-4970-9179-1c0399b30edc@github.com>
Message-ID: <LD0ptmc9Kyx7RSlc32XYCCarGaYR7mU3xl8Fe01Og6A=.07c7a0b7-8317-4a2d-a1b8-6772f179ed18@github.com>

> The class generated for lambda proxies is now defined as a hidden class. This means that the counter, which was used to ensure a unique class name and avoid clashes, is now redundant. In addition to performing redundant work, this also impacts build reproducibility for native image generators which might already have a strategy to cope with hidden classes but cannot cope with indeterminate definition order for lambda proxy classes.
> 
> This solves JDK-8292914 by making lambda proxy names always be stable without any configuration needed. This would also replace #10024.

David M. Lloyd has updated the pull request incrementally with one additional commit since the last revision:

  Updated to use hidden class suffix for dumps when possible, else use the counter with a `failed` suffix. Also, remove the extra trailing `$` from the lambda class name and update tests accordingly.
  
  This combines the suggestions made by @mlchung and @ExE-Boss and hopefully will resolve the Windows testing issue.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12579/files
  - new: https://git.openjdk.org/jdk/pull/12579/files/e9d1d7f2..a9d0acc3

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12579&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12579&range=05-06

  Stats: 63 lines in 4 files changed: 34 ins; 16 del; 13 mod
  Patch: https://git.openjdk.org/jdk/pull/12579.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12579/head:pull/12579

PR: https://git.openjdk.org/jdk/pull/12579

From iklam at openjdk.org  Fri Feb 17 17:09:24 2023
From: iklam at openjdk.org (Ioi Lam)
Date: Fri, 17 Feb 2023 17:09:24 GMT
Subject: RFR: 8292914: Drop the counter from lambda class names [v6]
In-Reply-To: <zlDm2W50G6NgRkzmgEpX6MTVs3XyYMnY3tN1YnObWUA=.03a3d8d7-4d20-4fc6-8028-b20a8603b0a6@github.com>
References: <GgLfH-ueBQqT-Mfk1mKpKFAt8fYqyjfVJ9lmlsBsCbo=.8dd5b3b4-4e84-4970-9179-1c0399b30edc@github.com>
 <zlDm2W50G6NgRkzmgEpX6MTVs3XyYMnY3tN1YnObWUA=.03a3d8d7-4d20-4fc6-8028-b20a8603b0a6@github.com>
Message-ID: <meQGU-exhVCALv6DeFkF_5ZhXGWZec47Eoxw9SvAg24=.5c8a9da0-63dc-468b-843f-9dcd46815208@github.com>

On Thu, 16 Feb 2023 19:35:54 GMT, David M. Lloyd <duke at openjdk.org> wrote:

>> The class generated for lambda proxies is now defined as a hidden class. This means that the counter, which was used to ensure a unique class name and avoid clashes, is now redundant. In addition to performing redundant work, this also impacts build reproducibility for native image generators which might already have a strategy to cope with hidden classes but cannot cope with indeterminate definition order for lambda proxy classes.
>> 
>> This solves JDK-8292914 by making lambda proxy names always be stable without any configuration needed. This would also replace #10024.
>
> David M. Lloyd has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use a unique index for the dumped lambda class instead of a time stamp

Java doesn't guarantee to use unique names even for "regular" classes. You can use two class loaders that load two completely different classes with the exact same name.

How does Graal and qbicc handle this?

-------------

PR: https://git.openjdk.org/jdk/pull/12579

From duke at openjdk.org  Fri Feb 17 17:09:26 2023
From: duke at openjdk.org (David M. Lloyd)
Date: Fri, 17 Feb 2023 17:09:26 GMT
Subject: RFR: 8292914: Drop the counter from lambda class names [v6]
In-Reply-To: <KUfH-M4rLZZgA3XuId4y6qSmhCC8JGzLj8aadcH0mFc=.b98e2ca6-2a59-47a6-98f7-933494dbf8b9@github.com>
References: <GgLfH-ueBQqT-Mfk1mKpKFAt8fYqyjfVJ9lmlsBsCbo=.8dd5b3b4-4e84-4970-9179-1c0399b30edc@github.com>
 <zlDm2W50G6NgRkzmgEpX6MTVs3XyYMnY3tN1YnObWUA=.03a3d8d7-4d20-4fc6-8028-b20a8603b0a6@github.com>
 <KUfH-M4rLZZgA3XuId4y6qSmhCC8JGzLj8aadcH0mFc=.b98e2ca6-2a59-47a6-98f7-933494dbf8b9@github.com>
Message-ID: <bw1hPCKfhIQeQc_p60Rn88qRmtJ79Z3Jpp1n7Mx2RjE=.32f252cf-e41a-4415-9b46-fbdc8803cf0c@github.com>

On Fri, 17 Feb 2023 15:18:25 GMT, Vojin Jovanovic <duke at openjdk.org> wrote:

> We didn't use the cryptographic hash as it is not resilient to the changes that happen to the bytecode generators of hidden classes. If anything in the bytecode generation (e.g., in `InnerClassLambdaMetafactory`) changes, the hashes stored in the metadata files will not be valid anymore. The prime example of this is the change in the class version between different JDKs. This makes [reachability metadata](https://www.graalvm.org/22.2/reference-manual/native-image/metadata/) useless across different versions of the JDK. This is especially problematic for cases such as:
> 
> https://github.com/oracle/graalvm-reachability-metadata

That's fair, we don't try to retain reachability metadata for lambda (or any other hidden) classes. And we would discard any persistent data (reachability, profiling, etc.) anyway if the class changed, since it is hard to determine whether the change would invalidate whatever data we would retain about that class.

> Given lambdas are in almost every stack trace, it is good for debugging that their names are clearly distinguishable. Adding a stable and unique hash to the lambda name as in #10024 does that and does not conflict with computing the cryptographic hash if it is needed by `qbicc`.

It seems to me that the hidden class suffix suffices for this as well as anything else, but I might just be strange. ?

> I would argue that #10024 improves the debugging experience, especially in multi-threaded environments where lambda names can be unstable with the current scheme.

I don't think that this change would rule out a change like #10024 (in my mind anyway). But, like I said I think that the problem of hidden classes has to be solved broadly anyway so a change like this at least gets us part of the way there.

-------------

PR: https://git.openjdk.org/jdk/pull/12579

From duke at openjdk.org  Fri Feb 17 17:09:26 2023
From: duke at openjdk.org (David M. Lloyd)
Date: Fri, 17 Feb 2023 17:09:26 GMT
Subject: RFR: 8292914: Drop the counter from lambda class names [v6]
In-Reply-To: <meQGU-exhVCALv6DeFkF_5ZhXGWZec47Eoxw9SvAg24=.5c8a9da0-63dc-468b-843f-9dcd46815208@github.com>
References: <GgLfH-ueBQqT-Mfk1mKpKFAt8fYqyjfVJ9lmlsBsCbo=.8dd5b3b4-4e84-4970-9179-1c0399b30edc@github.com>
 <zlDm2W50G6NgRkzmgEpX6MTVs3XyYMnY3tN1YnObWUA=.03a3d8d7-4d20-4fc6-8028-b20a8603b0a6@github.com>
 <meQGU-exhVCALv6DeFkF_5ZhXGWZec47Eoxw9SvAg24=.5c8a9da0-63dc-468b-843f-9dcd46815208@github.com>
Message-ID: <IsXSpZ3uF9NmX7G8jKCBvww8Fv7c1v-1PezxHWfsu5Y=.70e964e6-8757-47bf-91e4-6d155af98fc2@github.com>

On Fri, 17 Feb 2023 16:55:28 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> Java doesn't guarantee to use unique names even for "regular" classes. You can use two class loaders that load two completely different classes with the exact same name.
> 
> How does Graal and qbicc handle this?

In qbicc, we keep separate symbol, object file, and subdirectory names by class loader, and we use various schemes to try to derive a stable and comprehensible identifier from a given class loader (the simplest being the class loader's name, if it is unique). It's not a perfect solution by any means, but it's "good enough" for our use case at present.

-------------

PR: https://git.openjdk.org/jdk/pull/12579

From mchung at openjdk.org  Fri Feb 17 17:25:35 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Fri, 17 Feb 2023 17:25:35 GMT
Subject: RFR: 8302667: Improve message format when failing to load symbols
 or libraries [v2]
In-Reply-To: <B-eIiBotI3cwCwWY5r2xYPlHfnV4dKJIHJdwg-hbDeQ=.ff83dbdf-e456-48b7-aa7f-e8cf75f71b5a@github.com>
References: <tu4ol4DO1PeplhgjhkYpXLwES142ztBXsM43uQO_CNE=.bfca85a4-2323-487d-9261-964671e00bf3@github.com>
 <B-eIiBotI3cwCwWY5r2xYPlHfnV4dKJIHJdwg-hbDeQ=.ff83dbdf-e456-48b7-aa7f-e8cf75f71b5a@github.com>
Message-ID: <kZU8OxHl57JAzRBAtLeWjI-MfOnpKtjE0z32sUSHIX8=.aad0c2ef-434a-4a05-86fa-991486f74be1@github.com>

On Fri, 17 Feb 2023 14:08:34 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> DLL_ERROR4 is a macro expanding to an error message when a failure to load a generic item (shared libraries or an exported symbol from said libraries for example) occurs. "Error: loading:" is not a very pretty message, so this small change results in "Error: Failed to load %s" instead, which looks better and also means the message makes more sense if we want to append a reason behind as well, such as "Error: Failed to load libjvm.so because xxx"
>
> Julian Waters 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 'openjdk:master' into patch-6
>  - Error: Failed to load

This change is fine.   

`expandArgFile` reports `DLL_ERROR4` when it fails to read `@arg-file` which is unrelated to shared libraries.   Would you mind also adding `ARG_ERROR18` to replace `DLL_ERROR4`?

-------------

PR: https://git.openjdk.org/jdk/pull/12596

From mcimadamore at openjdk.org  Fri Feb 17 17:25:55 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 17 Feb 2023 17:25:55 GMT
Subject: RFR: 8294982: Implementation of Classfile API [v20]
In-Reply-To: <1G9rLfYBxfxcwmzgd7VDXnTfrW252lIui-9sWVAAhn0=.d3e5b0e6-66cc-4322-ae31-282954e9d3ca@github.com>
References: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
 <Gluemo5fFOPx_G6KtSgHxWEmiv3FFSTlxRHtc6ZPTuc=.6a2b6930-c7fd-4734-b21b-d2ccec1dabcf@github.com>
 <Qn0tRwNM_VFrkCYp8klyMMUJRCUoB0muZ9E-UkUK8R4=.12a8c8b2-48cc-4ffe-b11e-0180c60bd4bf@github.com>
 <1G9rLfYBxfxcwmzgd7VDXnTfrW252lIui-9sWVAAhn0=.d3e5b0e6-66cc-4322-ae31-282954e9d3ca@github.com>
Message-ID: <9Q436PkBJ4HIYF1ZSYJz_gEL3A1qfpjZKWKc82NVD6k=.7ce49423-395b-430a-9aa5-111106b77937@github.com>

On Fri, 17 Feb 2023 09:20:21 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/classfile/impl/ClassPrinterImpl.java line 563:
>> 
>>> 561:                       list("attributes", "attribute", clm.attributes().stream().map(Attribute::attributeName)))
>>> 562:                 .with(constantPoolToTree(clm.constantPool(), verbosity))
>>> 563:                 .with(attributesToTree(clm.attributes(), verbosity))
>> 
>> Is this ok? It seems we also add class attributes in the map node (see "attributes" map node).
>
> Yes, the print structure does not exactly correspond to the Classfile API architecture, but rather to the classfile physical structure and it is partly similar to `javap` output.
> The common tree structure has been reverse-designed from the desired visual representations in all supported text formats and in all verbosity levels.

Not sure I get this. It seems to me that the same attributes are being printed twice. But, perhaps, the first pass only creates a list with the attribute _names_ and then there is a later pass which print the attributes in full?

>> src/java.base/share/classes/jdk/internal/classfile/impl/DirectCodeBuilder.java line 649:
>> 
>>> 647:             if (parentMap == null)
>>> 648:                 parentMap = new IdentityHashMap<>();
>>> 649:             int[] table = parentMap.computeIfAbsent(parent, new Function<CodeAttribute, int[]>() {
>> 
>> Can use a lambda here?
>
> I'll have to add relevant comment here.
> There are many places in the Classfile API, which are on critical JDK bootstrap path in the follow-up integrations and using lambdas or method references would cause stack overflow during JDK bootstrap.
> Using other words - these fragments cannot use lambdas as they suppose to generate lambdas for JDK ;)

I suspect that was the case :-)

-------------

PR: https://git.openjdk.org/jdk/pull/10982

From rriggs at openjdk.org  Fri Feb 17 17:27:50 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 17 Feb 2023 17:27:50 GMT
Subject: RFR: 8301627: System.exit and Runtime.exit debug logging [v6]
In-Reply-To: <OzJeJH5yxolKPChcUisqtzGYF_MU3oOJdx6HPhsXjBw=.15eefe39-efe1-433e-a6ac-02b4a730f264@github.com>
References: <OzJeJH5yxolKPChcUisqtzGYF_MU3oOJdx6HPhsXjBw=.15eefe39-efe1-433e-a6ac-02b4a730f264@github.com>
Message-ID: <rtvSaGTGh2k6ueBg5TPNkXlBtWcKSlK-9cVFQX2zRpI=.1e076983-271e-4321-bc6a-e1b765c97803@github.com>

> It can be difficult to find the cause of calls to `java.lang.System.exit(status)` and `Runtime.exit(status)` because the Java runtime exits.
> The status value and stack trace are logged using the System Logger named `java.lang.Runtime` with message level `System.Logger.Level.DEBUG`.

Roger Riggs 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:

 - Move test to the java/lang/RuntimeTests directory.
   Added implNote to System.exit.
   A few javadoc updates for review comments.
 - Merge branch 'master' into 8301627-log-system-exit
 - Improve implNote for Runtime.exit() with review suggestions.
 - Correct System.getLogger link
 - Add an @implNote to Runtime.exit to describe the java.lang.Runtime logging.
 - Added try/catch around lookup of logger so exceptions do not prevent System.exit.
   Added test case with console logger (when java.util.logging) not present.
   Removed @implNote tag its not appropriate in implementation javadoc.
   Still looking into when and where the log configuration should be described.
 - Locate the System logger before taking the shutdown lock
 - Add logging of calls to Runtime.exit to the system logger "java.lang.Runtime".

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12517/files
  - new: https://git.openjdk.org/jdk/pull/12517/files/a31645c1..3dc13135

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12517&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12517&range=04-05

  Stats: 48694 lines in 1053 files changed: 18511 ins; 14817 del; 15366 mod
  Patch: https://git.openjdk.org/jdk/pull/12517.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12517/head:pull/12517

PR: https://git.openjdk.org/jdk/pull/12517

From eirbjo at gmail.com  Fri Feb 17 17:38:46 2023
From: eirbjo at gmail.com (=?UTF-8?B?RWlyaWsgQmrDuHJzbsO4cw==?=)
Date: Fri, 17 Feb 2023 18:38:46 +0100
Subject: Speed up latin1 case folding
Message-ID: <CA+pBWhs6e6hD=Vwb7LuS86kXM0fHTZXohXUBLLaUmap_Crt3jg@mail.gmail.com>

Hi,

The following PR suggests we can speed up Character.toUpperCase and
Character.toLowerCase for latin1 code points by applying 'the oldest ASCII
trick in the book':

https://github.com/openjdk/jdk/pull/12623

Thanks,
Eirik.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20230217/e37d716f/attachment.htm>

From alanb at openjdk.org  Fri Feb 17 18:12:01 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 17 Feb 2023 18:12:01 GMT
Subject: RFR: 8301627: System.exit and Runtime.exit debug logging [v6]
In-Reply-To: <rtvSaGTGh2k6ueBg5TPNkXlBtWcKSlK-9cVFQX2zRpI=.1e076983-271e-4321-bc6a-e1b765c97803@github.com>
References: <OzJeJH5yxolKPChcUisqtzGYF_MU3oOJdx6HPhsXjBw=.15eefe39-efe1-433e-a6ac-02b4a730f264@github.com>
 <rtvSaGTGh2k6ueBg5TPNkXlBtWcKSlK-9cVFQX2zRpI=.1e076983-271e-4321-bc6a-e1b765c97803@github.com>
Message-ID: <NZUf5Vin7ZpAYTnU6lsU-XPjYXpEDybtNNRQdB27ioI=.97259a65-41a5-4e47-9b66-429a09e66bf7@github.com>

On Fri, 17 Feb 2023 17:27:50 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> It can be difficult to find the cause of calls to `java.lang.System.exit(status)` and `Runtime.exit(status)` because the Java runtime exits.
>> The status value and stack trace are logged using the System Logger named `java.lang.Runtime` with message level `System.Logger.Level.DEBUG`.
>
> Roger Riggs 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:
> 
>  - Move test to the java/lang/RuntimeTests directory.
>    Added implNote to System.exit.
>    A few javadoc updates for review comments.
>  - Merge branch 'master' into 8301627-log-system-exit
>  - Improve implNote for Runtime.exit() with review suggestions.
>  - Correct System.getLogger link
>  - Add an @implNote to Runtime.exit to describe the java.lang.Runtime logging.
>  - Added try/catch around lookup of logger so exceptions do not prevent System.exit.
>    Added test case with console logger (when java.util.logging) not present.
>    Removed @implNote tag its not appropriate in implementation javadoc.
>    Still looking into when and where the log configuration should be described.
>  - Locate the System logger before taking the shutdown lock
>  - Add logging of calls to Runtime.exit to the system logger "java.lang.Runtime".

Marked as reviewed by alanb (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/12517

From iklam at openjdk.org  Fri Feb 17 18:11:57 2023
From: iklam at openjdk.org (Ioi Lam)
Date: Fri, 17 Feb 2023 18:11:57 GMT
Subject: RFR: 8292914: Drop the counter from lambda class names [v7]
In-Reply-To: <LD0ptmc9Kyx7RSlc32XYCCarGaYR7mU3xl8Fe01Og6A=.07c7a0b7-8317-4a2d-a1b8-6772f179ed18@github.com>
References: <GgLfH-ueBQqT-Mfk1mKpKFAt8fYqyjfVJ9lmlsBsCbo=.8dd5b3b4-4e84-4970-9179-1c0399b30edc@github.com>
 <LD0ptmc9Kyx7RSlc32XYCCarGaYR7mU3xl8Fe01Og6A=.07c7a0b7-8317-4a2d-a1b8-6772f179ed18@github.com>
Message-ID: <UTINpKQfys8OK4A--6kqdNbSgQjoREP-9yJDd9QydHY=.b2804285-cc59-4d33-8592-934db09bdfd7@github.com>

On Fri, 17 Feb 2023 17:02:56 GMT, David M. Lloyd <duke at openjdk.org> wrote:

>> The class generated for lambda proxies is now defined as a hidden class. This means that the counter, which was used to ensure a unique class name and avoid clashes, is now redundant. In addition to performing redundant work, this also impacts build reproducibility for native image generators which might already have a strategy to cope with hidden classes but cannot cope with indeterminate definition order for lambda proxy classes.
>> 
>> This solves JDK-8292914 by making lambda proxy names always be stable without any configuration needed. This would also replace #10024.
>
> David M. Lloyd has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updated to use hidden class suffix for dumps when possible, else use the counter with a `failed` suffix. Also, remove the extra trailing `$` from the lambda class name and update tests accordingly.
>   
>   This combines the suggestions made by @mlchung and @ExE-Boss and hopefully will resolve the Windows testing issue.

If you really want a stable name, an alternative approach is to walk the stack and find the caller of `LambdaMetafactory.metafactory` and get the constant pool index of the invokedynamic instruction. (This probably needs to be done with a native method).

Javac uses a unique CP index for each call site (15 vs 23 in the following example).


class Test {
    static void f1() {
        doit(() -> foo());
    }
    static void f2() {
        doit(() -> foo());
    }
    ....
}

$ javap -c -v Test.class

  static void f1();
    Code:
         0: invokedynamic #15,  0             // InvokeDynamic #0:run:()Ljava/lang/Runnable;
         5: invokestatic  #19                 // Method doit:(Ljava/lang/Runnable;)V
         8: return

  static void f2();
      stack=1, locals=0, args_size=0
         0: invokedynamic #23,  0             // InvokeDynamic #1:run:()Ljava/lang/Runnable;
         5: invokestatic  #19                 // Method doit:(Ljava/lang/Runnable;)V
         8: return

-------------

PR: https://git.openjdk.org/jdk/pull/12579

From briangoetz at openjdk.org  Fri Feb 17 18:12:03 2023
From: briangoetz at openjdk.org (Brian Goetz)
Date: Fri, 17 Feb 2023 18:12:03 GMT
Subject: RFR: 8292914: Drop the counter from lambda class names [v7]
In-Reply-To: <LD0ptmc9Kyx7RSlc32XYCCarGaYR7mU3xl8Fe01Og6A=.07c7a0b7-8317-4a2d-a1b8-6772f179ed18@github.com>
References: <GgLfH-ueBQqT-Mfk1mKpKFAt8fYqyjfVJ9lmlsBsCbo=.8dd5b3b4-4e84-4970-9179-1c0399b30edc@github.com>
 <LD0ptmc9Kyx7RSlc32XYCCarGaYR7mU3xl8Fe01Og6A=.07c7a0b7-8317-4a2d-a1b8-6772f179ed18@github.com>
Message-ID: <lGsfKVjXDdLHKr3RZ3cM78yM-bKuRnuHlE5VAArpzUI=.f4df673e-772d-4d6c-bb41-d349bf8f0fd6@github.com>

On Fri, 17 Feb 2023 17:02:56 GMT, David M. Lloyd <duke at openjdk.org> wrote:

>> The class generated for lambda proxies is now defined as a hidden class. This means that the counter, which was used to ensure a unique class name and avoid clashes, is now redundant. In addition to performing redundant work, this also impacts build reproducibility for native image generators which might already have a strategy to cope with hidden classes but cannot cope with indeterminate definition order for lambda proxy classes.
>> 
>> This solves JDK-8292914 by making lambda proxy names always be stable without any configuration needed. This would also replace #10024.
>
> David M. Lloyd has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updated to use hidden class suffix for dumps when possible, else use the counter with a `failed` suffix. Also, remove the extra trailing `$` from the lambda class name and update tests accordingly.
>   
>   This combines the suggestions made by @mlchung and @ExE-Boss and hopefully will resolve the Windows testing issue.

On 2/17/2023 12:50 PM, Ioi Lam wrote:
>
> If you really want a stable name, an alternative approach is to walk 
> the stack and find the caller of |LambdaMetafactory.metafactory| and 
> get the constant pool index of the invokedynamic instruction. (This 
> probably needs to be done with a native method).
>
> Javac uses a unique CP index for each call site (15 vs 23 in the 
> following example).
>

This is actually no longer true.? Liam @ Google did a "lambda 
deduplication" where multiple identical lambdas in a compilation unit 
are folded to a single index in the BSM, which can be used by multiple 
capturing indys.

-------------

PR: https://git.openjdk.org/jdk/pull/12579

From darcy at openjdk.org  Fri Feb 17 19:15:30 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 17 Feb 2023 19:15:30 GMT
Subject: RFR: JDK-8302028: Port fdlibm atan2 to Java [v2]
In-Reply-To: <FSMfXwXXxe2sBtxB5J641Hh9o8WKPX2k7-n2bpOhrWU=.e8281db1-ecc4-43e0-bbe2-1c419e1111f0@github.com>
References: <xl79M-V4_2t49GuCudJHQBaJjAcwWl9f2Bv19RbAmdo=.b9c97066-8cf4-4569-8b4b-8b4874e23833@github.com>
 <TMI7ZKI2Qc9DL_wLKNwMXAtu7hstoL-mrZjEIsv-MT0=.dace04d5-ec7e-40c2-b540-4e1f5e68bd38@github.com>
 <FSMfXwXXxe2sBtxB5J641Hh9o8WKPX2k7-n2bpOhrWU=.e8281db1-ecc4-43e0-bbe2-1c419e1111f0@github.com>
Message-ID: <zdHI7yj7b9mZKZnPnd-m2n_2a45ZlQiTbsFwqcP6t50=.c0041d60-2ce6-42c2-b00c-6d7f66698afd@github.com>

On Fri, 17 Feb 2023 13:48:32 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> Joe Darcy 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:
>> 
>>  - Update regression test.
>>  - Merge branch 'master' into JDK-8302028
>>  - JDK-8302028: Port fdlibm atan2 to Java
>
> test/jdk/java/lang/StrictMath/FdlibmTranslit.java line 480:
> 
>> 478:                     switch(m) {
>> 479:                     case 0: return  zero  ;     /* atan(+...,+INF) */
>> 480:                     case 1: return -1.0*zero  ; /* atan(-...,+INF) */
> 
> The file in the [netlib repo](https://netlib.org/fdlibm/e_atan2.c) has `-zero` rather than `-1.0*zero`.

Yes; well-observed -- that change was made back in the JDK's copy of FDLIBM back in JDK 5.0 to contend with bugs in C compilers, JDK-4984407.

-------------

PR: https://git.openjdk.org/jdk/pull/12608

From smarks at openjdk.org  Fri Feb 17 19:35:28 2023
From: smarks at openjdk.org (Stuart Marks)
Date: Fri, 17 Feb 2023 19:35:28 GMT
Subject: RFR: 8298939: Refactor
 open/test/jdk/javax/rmi/ssl/SSLSocketParametersTest.sh to jtreg java test [v3]
In-Reply-To: <y65OxkcJ9OlzgC1Q-o62zILzqMIQA9SQk_pg6zdpe7U=.d7745cdf-f803-45bd-a3fb-8d6bb146c2c2@github.com>
References: <VC_ou2XS44PtyTfwXw0VZRtXcHEbXImlLZKniIPRqOw=.7d10a168-77f8-4552-97a3-8b2570e3fe29@github.com>
 <y65OxkcJ9OlzgC1Q-o62zILzqMIQA9SQk_pg6zdpe7U=.d7745cdf-f803-45bd-a3fb-8d6bb146c2c2@github.com>
Message-ID: <9r-bLTPN386eFb7438VgALrjLfRcwjfoO2f5RTjabYQ=.78a0192a-3738-4d0b-ae89-cc1f3e635690@github.com>

On Tue, 7 Feb 2023 20:38:40 GMT, Matthew Donovan <duke at openjdk.org> wrote:

>> Removed SSLSocketParametersTest.sh script (which just called a Java file) and configured the java code to run directly with jtreg
>
> Matthew Donovan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   added exceptions for cases 4 and 5

test/jdk/javax/rmi/ssl/SSLSocketParametersTest.java line 163:

> 161:                 }
> 162:             }
> 163:         }

It looks like this finally-block is intended to unexport any exported RMI service, which will let the JVM exit. However, this is somewhat fragile. If the unexportObject() call fails with some other exception, the object might remain exported, and the JVM will hang indefinitely. (This has historically been a problem with RMI tests.)

Since the original version of the test ran each case in a separate JVM, I think it's ok to continue to do the same. The old version of the test called System.exit() along most code paths. It's somewhat odd that exit wasn't called along all code paths. Perhaps those code paths weren't taken, or if they were, the JVM exited of its own accord. In any case, I'd suggest ensuring that exit() is called along all code paths (success and failure) and keeping separate `@run main/othervm` lines in the header to run each case in its own JVM. This is at least equivalent to what the shell script based test was doing.

As an optimization, it might be reasonable to try to run some subset of the tests in a single JVM. They can't all be run in the same JVM though, because of system properties, so this would require some complexity to support running some cases in the same JVM and some in separate JVMs. It's not clear to me whether that's warranted.

-------------

PR: https://git.openjdk.org/jdk/pull/11910

From darcy at openjdk.org  Fri Feb 17 19:36:13 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 17 Feb 2023 19:36:13 GMT
Subject: RFR: JDK-8302028: Port fdlibm atan2 to Java [v2]
In-Reply-To: <FSMfXwXXxe2sBtxB5J641Hh9o8WKPX2k7-n2bpOhrWU=.e8281db1-ecc4-43e0-bbe2-1c419e1111f0@github.com>
References: <xl79M-V4_2t49GuCudJHQBaJjAcwWl9f2Bv19RbAmdo=.b9c97066-8cf4-4569-8b4b-8b4874e23833@github.com>
 <TMI7ZKI2Qc9DL_wLKNwMXAtu7hstoL-mrZjEIsv-MT0=.dace04d5-ec7e-40c2-b540-4e1f5e68bd38@github.com>
 <FSMfXwXXxe2sBtxB5J641Hh9o8WKPX2k7-n2bpOhrWU=.e8281db1-ecc4-43e0-bbe2-1c419e1111f0@github.com>
Message-ID: <de6qDGg8k_5fRMfIeec1HAwTCLu430OMQ9Tj23YK2SU=.0c44e378-25f5-496b-a1f0-630e8ef6072a@github.com>

On Fri, 17 Feb 2023 14:02:35 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> Joe Darcy 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:
>> 
>>  - Update regression test.
>>  - Merge branch 'master' into JDK-8302028
>>  - JDK-8302028: Port fdlibm atan2 to Java
>
> src/java.base/share/classes/java/lang/FdLibm.java line 458:
> 
>> 456:                 case 0, 1 ->  y;              // atan(+/-0, +anything)  = +/-0
>> 457:                 case 2    ->  Math.PI + tiny; // atan(+0,   -anything)  =  pi
>> 458:                 default   -> -Math.PI - tiny; // atan(-0,   -anything)  = -pi
> 
> The original switch statement and this switch expression are semantically equivalent only because of our knowledge that `m` can only assume values 0, 1, 2, or 3. This requires more reasoning than a more verbatim copy of the original statement. Not sure if it is worth.
> 
> The same holds for the switch expressions below.

Yes, the use of switch expressions here is certainly not strictly necessary.

Something that helped convince me it was okay was that the final switch on m in atan2 uses the set of case labels {0, 1, 2, default}., further implying that m can only take on the values {0, 1, 2, 3}.

-------------

PR: https://git.openjdk.org/jdk/pull/12608

From igraves at openjdk.org  Fri Feb 17 19:37:08 2023
From: igraves at openjdk.org (Ian Graves)
Date: Fri, 17 Feb 2023 19:37:08 GMT
Subject: RFR: 8293667: Align jlink's --compress option with jmod's
 --compress option [v9]
In-Reply-To: <5lpo7qc_k7lh5RjNirI1ecqGdaaS25jMORgspMjW6pw=.8a40dc0a-26a6-492b-ace7-32fd5adf40ae@github.com>
References: <JWevwHuR2vF3k-JRxmTAxfNN6g-EBkgG2N9DHn4fkGY=.f9768dfd-cab4-49a9-83b9-d77a1572e917@github.com>
 <OjnRaZmWra2iE7PXRJG6PRB2p0lLVsgsGsWdV1pufUA=.f1bb8159-f38a-48e4-907f-e82e1b1c4a9f@github.com>
 <KROkvc-sXqvRTusiF06EHqrbW0pt7yoQN6oB6TkCpPI=.de6cdbf2-adc1-41df-809c-82ba164330bd@github.com>
 <bs9YRJU8DGv8A7iF8yLGSC6Oi86QJVH6j8xbmp6bW1s=.7c8bee30-955a-4cc7-ac67-e8b390d85bad@github.com>
 <5lpo7qc_k7lh5RjNirI1ecqGdaaS25jMORgspMjW6pw=.8a40dc0a-26a6-492b-ace7-32fd5adf40ae@github.com>
Message-ID: <Pn-e_7eLcUgo549qsqGJQqw-S1N6RfURAcqtAs5UTgc=.d55f5b81-7777-4fa7-a630-8813455fc92d@github.com>

On Fri, 17 Feb 2023 02:12:41 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> Thanks. I note that there is a non-localized warning done this way elsewhere in jlink. May need to make a bug to localize this.
>
> I prefer this one should use the localized message.  The other ones should be followed up in a separate bug as they are unrelated to this one.

Agree! Sorry, got my words mixed up. The existing non-localized behavior should put into another bug.

-------------

PR: https://git.openjdk.org/jdk/pull/11617

From duke at openjdk.org  Fri Feb 17 19:37:59 2023
From: duke at openjdk.org (David M. Lloyd)
Date: Fri, 17 Feb 2023 19:37:59 GMT
Subject: RFR: 8292914: Drop the counter from lambda class names [v8]
In-Reply-To: <GgLfH-ueBQqT-Mfk1mKpKFAt8fYqyjfVJ9lmlsBsCbo=.8dd5b3b4-4e84-4970-9179-1c0399b30edc@github.com>
References: <GgLfH-ueBQqT-Mfk1mKpKFAt8fYqyjfVJ9lmlsBsCbo=.8dd5b3b4-4e84-4970-9179-1c0399b30edc@github.com>
Message-ID: <AdfREeJYVkF6HTsw669hMueQxdGXUXxYc4GetiDuoDk=.5124c8b8-3bea-4baa-bbb1-9383c84bb15f@github.com>

> The class generated for lambda proxies is now defined as a hidden class. This means that the counter, which was used to ensure a unique class name and avoid clashes, is now redundant. In addition to performing redundant work, this also impacts build reproducibility for native image generators which might already have a strategy to cope with hidden classes but cannot cope with indeterminate definition order for lambda proxy classes.
> 
> This solves JDK-8292914 by making lambda proxy names always be stable without any configuration needed. This would also replace #10024.

David M. Lloyd has updated the pull request incrementally with two additional commits since the last revision:

 - Many tests have patterns for lambda class names; update them
 - Update comments and javadoc showin the old pattern

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12579/files
  - new: https://git.openjdk.org/jdk/pull/12579/files/a9d0acc3..145d857f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12579&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12579&range=06-07

  Stats: 62 lines in 47 files changed: 0 ins; 0 del; 62 mod
  Patch: https://git.openjdk.org/jdk/pull/12579.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12579/head:pull/12579

PR: https://git.openjdk.org/jdk/pull/12579

From smarks at openjdk.org  Fri Feb 17 19:56:13 2023
From: smarks at openjdk.org (Stuart Marks)
Date: Fri, 17 Feb 2023 19:56:13 GMT
Subject: RFR: 8298939: Refactor
 open/test/jdk/javax/rmi/ssl/SSLSocketParametersTest.sh to jtreg java test [v3]
In-Reply-To: <y65OxkcJ9OlzgC1Q-o62zILzqMIQA9SQk_pg6zdpe7U=.d7745cdf-f803-45bd-a3fb-8d6bb146c2c2@github.com>
References: <VC_ou2XS44PtyTfwXw0VZRtXcHEbXImlLZKniIPRqOw=.7d10a168-77f8-4552-97a3-8b2570e3fe29@github.com>
 <y65OxkcJ9OlzgC1Q-o62zILzqMIQA9SQk_pg6zdpe7U=.d7745cdf-f803-45bd-a3fb-8d6bb146c2c2@github.com>
Message-ID: <VXfns8mD49MsvScZQA0W-2gsiLMrv4vI3gh-_ARssF4=.b7f3293f-aba6-487d-9769-fecb34f46af8@github.com>

On Tue, 7 Feb 2023 20:38:40 GMT, Matthew Donovan <duke at openjdk.org> wrote:

>> Removed SSLSocketParametersTest.sh script (which just called a Java file) and configured the java code to run directly with jtreg
>
> Matthew Donovan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   added exceptions for cases 4 and 5

test/jdk/javax/rmi/ssl/SSLSocketParametersTest.java line 211:

> 209:                         throw exc;
> 210:                     }
> 211:                 }

Having exception handling in the run() method and also in this switch statement is quite confusing. It obscures the fact that these cases (4 and 5) don't call run() at all. It would be good to find a structure that makes it clear that some test cases are for exceptions that occur at ServerFactory creation time and other exceptions occur when an actual socket connection is attempted.

-------------

PR: https://git.openjdk.org/jdk/pull/11910

From smarks at openjdk.org  Fri Feb 17 20:00:00 2023
From: smarks at openjdk.org (Stuart Marks)
Date: Fri, 17 Feb 2023 20:00:00 GMT
Subject: RFR: 8298939: Refactor
 open/test/jdk/javax/rmi/ssl/SSLSocketParametersTest.sh to jtreg java test [v3]
In-Reply-To: <y65OxkcJ9OlzgC1Q-o62zILzqMIQA9SQk_pg6zdpe7U=.d7745cdf-f803-45bd-a3fb-8d6bb146c2c2@github.com>
References: <VC_ou2XS44PtyTfwXw0VZRtXcHEbXImlLZKniIPRqOw=.7d10a168-77f8-4552-97a3-8b2570e3fe29@github.com>
 <y65OxkcJ9OlzgC1Q-o62zILzqMIQA9SQk_pg6zdpe7U=.d7745cdf-f803-45bd-a3fb-8d6bb146c2c2@github.com>
Message-ID: <N7a59wncar6RelTlTma_DyuWZzbpqu153cVR7pbcO4I=.2ba38549-3ccc-4d35-8cb3-ab677fd7830c@github.com>

On Tue, 7 Feb 2023 20:38:40 GMT, Matthew Donovan <duke at openjdk.org> wrote:

>> Removed SSLSocketParametersTest.sh script (which just called a Java file) and configured the java code to run directly with jtreg
>
> Matthew Donovan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   added exceptions for cases 4 and 5

General comments: the ClientFactory, ServerFactory, and HelloClient classes don't seem to be adding much value. Also, the setup of the HelloImpl service could probably be simplified by not having it extend UnicastRemoteObject and instead calling UnicastRemoteObject.exportObject(). These are held over from the original test and don't have much do with the shell script conversion, though, so you might choose not to undertake these cleanups now. But if you're interested, let me know and we can discuss them further.

-------------

PR: https://git.openjdk.org/jdk/pull/11910

From rriggs at openjdk.org  Fri Feb 17 20:00:04 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 17 Feb 2023 20:00:04 GMT
Subject: RFR: 8298939: Refactor
 open/test/jdk/javax/rmi/ssl/SSLSocketParametersTest.sh to jtreg java test [v3]
In-Reply-To: <VXfns8mD49MsvScZQA0W-2gsiLMrv4vI3gh-_ARssF4=.b7f3293f-aba6-487d-9769-fecb34f46af8@github.com>
References: <VC_ou2XS44PtyTfwXw0VZRtXcHEbXImlLZKniIPRqOw=.7d10a168-77f8-4552-97a3-8b2570e3fe29@github.com>
 <y65OxkcJ9OlzgC1Q-o62zILzqMIQA9SQk_pg6zdpe7U=.d7745cdf-f803-45bd-a3fb-8d6bb146c2c2@github.com>
 <VXfns8mD49MsvScZQA0W-2gsiLMrv4vI3gh-_ARssF4=.b7f3293f-aba6-487d-9769-fecb34f46af8@github.com>
Message-ID: <GrTY71oHZ-tnCU9A0gkYBtvFemypvh38-sbq2tAcnEM=.d4e137cd-4671-4b19-9a47-99fa1a5f89c0@github.com>

On Fri, 17 Feb 2023 19:53:10 GMT, Stuart Marks <smarks at openjdk.org> wrote:

>> Matthew Donovan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   added exceptions for cases 4 and 5
>
> test/jdk/javax/rmi/ssl/SSLSocketParametersTest.java line 211:
> 
>> 209:                         throw exc;
>> 210:                     }
>> 211:                 }
> 
> Having exception handling in the run() method and also in this switch statement is quite confusing. It obscures the fact that these cases (4 and 5) don't call run() at all. It would be good to find a structure that makes it clear that some test cases are for exceptions that occur at ServerFactory creation time and other exceptions occur when an actual socket connection is attempted.

Perhaps some refactoring should be done in a separate PR. 
The stated goal was to remove the use of the shell script; but its easy to start to refactor more and more.

-------------

PR: https://git.openjdk.org/jdk/pull/11910

From simonis at openjdk.org  Fri Feb 17 20:03:54 2023
From: simonis at openjdk.org (Volker Simonis)
Date: Fri, 17 Feb 2023 20:03:54 GMT
Subject: RFR: 8302154: Hidden classes created by LambdaMetaFactory can't be
 unloaded [v2]
In-Reply-To: <gKoLpwlXDxp2uaSKSkMArJl1Ym9VX1hoDFqQTTUpk8w=.e1dce669-5a42-4b66-ac4b-205718c8eb81@github.com>
References: <YoZauVv8zvhdUw-LD25LrsMDItFbg3aXPU3deXwwFdQ=.c2839dea-12e5-4e0e-9579-eac9d8503932@github.com>
 <gKoLpwlXDxp2uaSKSkMArJl1Ym9VX1hoDFqQTTUpk8w=.e1dce669-5a42-4b66-ac4b-205718c8eb81@github.com>
Message-ID: <bYkGnm79U37ob-7VlaEzPlzcJZrFpzn0mnnZxCen5wk=.268d1655-2ed2-4d9c-895f-84de711ee611@github.com>

On Thu, 9 Feb 2023 18:11:18 GMT, Volker Simonis <simonis at openjdk.org> wrote:

>> Prior to [JDK-8239384](https://bugs.openjdk.org/browse/JDK-8239384)/[JDK-8238358](https://bugs.openjdk.org/browse/JDK-8238358) LambdaMetaFactory has created VM-anonymous classes which could easily be unloaded once they were not referenced any more. Starting with JDK 15 and the new "hidden class" based implementation, this is not the case any more, because the hidden classes will be strongly tied to their defining class loader. If this is the default application class loader, these hidden classes can never be unloaded which can easily lead to Metaspace exhaustion (see the [test case in the JBS issue](https://bugs.openjdk.org/secure/attachment/102601/LambdaClassLeak.java)). This is a regression compared to previous JDK versions which some of our applications have been affected from when migrating to JDK 17.
>> 
>> The reason why the newly created hidden classes are strongly linked to their defining class loader is not clear to me. JDK-8239384 mentions it as an "implementation detail":
>> 
>>> *4. the lambda proxy class has the strong relationship with the class loader (that will share the VM metaspace for its defining loader - implementation details)*
>> 
>> From my current understanding the strong link between a hidden class created by `LambdaMetaFactory` and its defining class loader is not strictly required. In order to prevent potential OOMs and fix the regression compared the JDK 14 and earlier I propose to create these hidden classes without the `STRONG` option.
>> 
>> I'll be happy to add the test case as JTreg test to this PR if you think that would be useful.
>
> Volker Simonis has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Remove assertions which insist on Lambda proxy classes being strongly linked to their class loader
>  - Removed unused import of STRONG und updated copyright year

Here are some numbers. I basically measured the overhead in Metaspace and native memory (i.e. `malloc()`) for 10_000 Lambda classes created with `LambdaMetafactory.metafactory()`. For the Metaspace numbers I took the "used" column for both "Class" and "Non-Class" areas of all class loaders (i.e. "Total Usage") reported by `jcmd VM.metaspace show-loaders`. This is basically the same like the "Total" "BlockSz" reported by `jcmd VM.classloader_stats`.

For native memory overhead I took the "malloc" numbers from the "Class" section in the output from `VM.native_memory`. I did run the test program with `-Xint -XX:+UseSerialGC -Xms512m -Xmx512m -XX:MetaspaceSize=100M -Xlog:gc -XX:NativeMemoryTracking=detail LambdaClassLeak 10000` to make sure I have no garbage collections except the explicit one triggered by me. 

The results in the first two columns are the difference between the numbers before and after creating the 10_000 Lambda classes and the results in the last two columns are the numbers after doing a `System.gc()` and potentially unloading the created Lambda classes (because they are all not referenced from the program any more). 

| JDK | Metaspace (kb)  | malloc (kb)  | - after GC -> | Metaspace (kb)  | malloc (kb) | 
|:---:| ---------------:| ------------:| ------------- | ---------------:| -----------:|
| 11  |          16_328 |        6_561 |               |               0 |         232 |
| 15  |          13_624 |          240 |               |          13_624 |          92 |
| 17  |          13_394 |         3_38 |               |          13_394 |          93 |
| tip |          13_451 |          337 |               |          13_451 |          93 |
| fix |          13_437 |        5_957 |               |               0 |          10 |

As you can see, with JDK 11, where Lambda classes are implemented by VM Anonymous classes, the 10_000 classes take up ~16mb of Metaspace and 6mb of native memory. The native memory is required for the `ClassLoaderData` structures because each VM Anonymous class lives in its own `ClassLoaderData`. After a GC, all the Metaspace and most of the native memory gets freed up.

Starting with JDK 15,  Lambda classes are now backed by the newly introduced "Hidden Classes". The Metaspace consumption slightly drops from ~16 to ~13mb (because the classes are a little smaller) and the native consumption drops significantly from ~6mb to 240kb. That's because the newly generated hidden classes are all strongly coupled to their defining class loader and therefor live in its `ClassLoaderData` section. While this saves ~6mb of native memory, it also prevents unloading of these classes.

These numbers haven't changed up to the current JDK development version. With the fix proposed in this PR, we basically trade about ~6mb of native memory (i.e. ~600 bytes per Lambda class) for the ability to easily unload such Lambda classes once they are not referenced any more.

I still think doing this change is reasonable because:
1. `LambdaMetafactory.metafactory()` does not mention that the classes is creates will not be unloadable. And they actually were unloadable up to JDK 11 while they were backed by VM anonymous classes. This is unexpected for users.
2. I'd argue that Metaspace is more "*valuable*" than native memory because it is limited by `-XX:MetaspaceSize` whereas native memory is only limited by the amount of available memory on the system. Also, growing Metaspace will trigger garbage collections which might be unexpected.
3. I think only "real" users of Lambda functions should pay the price for them and not users who don't need them any more.
4. Finally, the PR fixes a regression compared to the JDK 11 behavior. 

In general it seems to me that creating a new  `ClassLoaderData` for each hidden (or VM anonymous) class is a lot of overhead and was probably only done as "a hack" to simplify the implementation of class unloading for such classes. This might have been appropriate in the "early days" when we had just a few VM anonymous classes. But as the usage of `LambdaMetafactory.metafactory()` becomes more common it may make sense to revise the implementation such that for example all hidden classes defined by a class loader can live in a single `ClassLoaderData` structure. I think this should be technically possible although it would complicate the unloading logic (and should therefore be postponed to a later change).

-------------

PR: https://git.openjdk.org/jdk/pull/12493

From duke at openjdk.org  Fri Feb 17 20:30:28 2023
From: duke at openjdk.org (Matthew Donovan)
Date: Fri, 17 Feb 2023 20:30:28 GMT
Subject: RFR: 8298939: Refactor
 open/test/jdk/javax/rmi/ssl/SSLSocketParametersTest.sh to jtreg java test [v3]
In-Reply-To: <VhLDvwJ54UU63L4emLdpQvO425M03Mp8FPoUzU4iusQ=.218d2b73-c6dc-4e22-b62d-b36e3a411898@github.com>
References: <VC_ou2XS44PtyTfwXw0VZRtXcHEbXImlLZKniIPRqOw=.7d10a168-77f8-4552-97a3-8b2570e3fe29@github.com>
 <y65OxkcJ9OlzgC1Q-o62zILzqMIQA9SQk_pg6zdpe7U=.d7745cdf-f803-45bd-a3fb-8d6bb146c2c2@github.com>
 <VhLDvwJ54UU63L4emLdpQvO425M03Mp8FPoUzU4iusQ=.218d2b73-c6dc-4e22-b62d-b36e3a411898@github.com>
Message-ID: <LvZCQmkLUGIlV59xvjkNzq1Z2naPsdW_BDd2B7QDBbs=.bcb7907f-9ce6-4ce9-a910-553e8a64e109@github.com>

On Fri, 17 Feb 2023 15:27:04 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Matthew Donovan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   added exceptions for cases 4 and 5
>
> test/jdk/javax/rmi/ssl/SSLSocketParametersTest.java line 34:
> 
>> 32:  * @run main/othervm SSLSocketParametersTest 5
>> 33:  * @run main/othervm SSLSocketParametersTest 6
>> 34:  * @run main/othervm SSLSocketParametersTest 7
> 
> Is a fresh VM needed for each of these tests?
> From a naive point of view it appears that 1, 2, 3, 4, 6, 7 use the same system properties.
> The tests would complete more quickly if they could run the compatible tests in a single VM.
> Perhaps main() could iterate over the args[n] and run the corresponding test.

I tried this suggestion but test case 6 failed. From the logs, it looked like an object was being re-used and an exception wasn't being thrown when it should have been.

-------------

PR: https://git.openjdk.org/jdk/pull/11910

From forax at openjdk.org  Fri Feb 17 20:36:30 2023
From: forax at openjdk.org (=?UTF-8?B?UsOpbWk=?= Forax)
Date: Fri, 17 Feb 2023 20:36:30 GMT
Subject: RFR: 8302154: Hidden classes created by LambdaMetaFactory can't be
 unloaded [v2]
In-Reply-To: <gKoLpwlXDxp2uaSKSkMArJl1Ym9VX1hoDFqQTTUpk8w=.e1dce669-5a42-4b66-ac4b-205718c8eb81@github.com>
References: <YoZauVv8zvhdUw-LD25LrsMDItFbg3aXPU3deXwwFdQ=.c2839dea-12e5-4e0e-9579-eac9d8503932@github.com>
 <gKoLpwlXDxp2uaSKSkMArJl1Ym9VX1hoDFqQTTUpk8w=.e1dce669-5a42-4b66-ac4b-205718c8eb81@github.com>
Message-ID: <i18if-2pyDbqwLPqLB1lTeQBUuFfrwPhq5pIv8KTnv0=.493ceb86-860b-4633-8a98-ebdbce35db9c@github.com>

On Thu, 9 Feb 2023 18:11:18 GMT, Volker Simonis <simonis at openjdk.org> wrote:

>> Prior to [JDK-8239384](https://bugs.openjdk.org/browse/JDK-8239384)/[JDK-8238358](https://bugs.openjdk.org/browse/JDK-8238358) LambdaMetaFactory has created VM-anonymous classes which could easily be unloaded once they were not referenced any more. Starting with JDK 15 and the new "hidden class" based implementation, this is not the case any more, because the hidden classes will be strongly tied to their defining class loader. If this is the default application class loader, these hidden classes can never be unloaded which can easily lead to Metaspace exhaustion (see the [test case in the JBS issue](https://bugs.openjdk.org/secure/attachment/102601/LambdaClassLeak.java)). This is a regression compared to previous JDK versions which some of our applications have been affected from when migrating to JDK 17.
>> 
>> The reason why the newly created hidden classes are strongly linked to their defining class loader is not clear to me. JDK-8239384 mentions it as an "implementation detail":
>> 
>>> *4. the lambda proxy class has the strong relationship with the class loader (that will share the VM metaspace for its defining loader - implementation details)*
>> 
>> From my current understanding the strong link between a hidden class created by `LambdaMetaFactory` and its defining class loader is not strictly required. In order to prevent potential OOMs and fix the regression compared the JDK 14 and earlier I propose to create these hidden classes without the `STRONG` option.
>> 
>> I'll be happy to add the test case as JTreg test to this PR if you think that would be useful.
>
> Volker Simonis has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Remove assertions which insist on Lambda proxy classes being strongly linked to their class loader
>  - Removed unused import of STRONG und updated copyright year

Hi Volker, in the future, we may change the implementation of lambdas again, by example Valhalla parametric generics, Isolated methods (JDK-8158765), JDK-8087219 or JDK-8001537,  may allow to re-use the same class file/method for all lambdas implementing the same interface. I fear that forcing unloading may block future refactoring.

-------------

PR: https://git.openjdk.org/jdk/pull/12493

From duke at openjdk.org  Fri Feb 17 20:41:16 2023
From: duke at openjdk.org (Matthew Donovan)
Date: Fri, 17 Feb 2023 20:41:16 GMT
Subject: RFR: 8298939: Refactor
 open/test/jdk/javax/rmi/ssl/SSLSocketParametersTest.sh to jtreg java test [v4]
In-Reply-To: <VC_ou2XS44PtyTfwXw0VZRtXcHEbXImlLZKniIPRqOw=.7d10a168-77f8-4552-97a3-8b2570e3fe29@github.com>
References: <VC_ou2XS44PtyTfwXw0VZRtXcHEbXImlLZKniIPRqOw=.7d10a168-77f8-4552-97a3-8b2570e3fe29@github.com>
Message-ID: <AwGYbtYHElwIegMho1esToGmDCY4oCBJ6Kdw7AIl7mg=.c975751e-69cb-4916-af14-7ea88471e47d@github.com>

> Removed SSLSocketParametersTest.sh script (which just called a Java file) and configured the java code to run directly with jtreg

Matthew Donovan 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:

 - added System.exit when exceptions are thrown and refactored for clarity
 - Merge branch 'master' into rmi-sslparams
 - added default switch case and additional refactoring
 - added exceptions for cases 4 and 5
 - clarified cases 4 and 5
 - 8298939: Refactor open/test/jdk/javax/rmi/ssl/SSLSocketParametersTest.sh to jtreg java test

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/11910/files
  - new: https://git.openjdk.org/jdk/pull/11910/files/205226d4..775e2981

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11910&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11910&range=02-03

  Stats: 117973 lines in 3709 files changed: 50697 ins; 26477 del; 40799 mod
  Patch: https://git.openjdk.org/jdk/pull/11910.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11910/head:pull/11910

PR: https://git.openjdk.org/jdk/pull/11910

From duke at openjdk.org  Fri Feb 17 20:41:19 2023
From: duke at openjdk.org (Matthew Donovan)
Date: Fri, 17 Feb 2023 20:41:19 GMT
Subject: RFR: 8298939: Refactor
 open/test/jdk/javax/rmi/ssl/SSLSocketParametersTest.sh to jtreg java test [v3]
In-Reply-To: <9r-bLTPN386eFb7438VgALrjLfRcwjfoO2f5RTjabYQ=.78a0192a-3738-4d0b-ae89-cc1f3e635690@github.com>
References: <VC_ou2XS44PtyTfwXw0VZRtXcHEbXImlLZKniIPRqOw=.7d10a168-77f8-4552-97a3-8b2570e3fe29@github.com>
 <y65OxkcJ9OlzgC1Q-o62zILzqMIQA9SQk_pg6zdpe7U=.d7745cdf-f803-45bd-a3fb-8d6bb146c2c2@github.com>
 <9r-bLTPN386eFb7438VgALrjLfRcwjfoO2f5RTjabYQ=.78a0192a-3738-4d0b-ae89-cc1f3e635690@github.com>
Message-ID: <24Cc7mXtQveH97zLcOxD2gH9P6qWNkdJ--I9IiFtZVo=.66068deb-3ca5-4dcc-aa70-688a9adb4c9a@github.com>

On Fri, 17 Feb 2023 19:33:04 GMT, Stuart Marks <smarks at openjdk.org> wrote:

>> Matthew Donovan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   added exceptions for cases 4 and 5
>
> test/jdk/javax/rmi/ssl/SSLSocketParametersTest.java line 163:
> 
>> 161:                 }
>> 162:             }
>> 163:         }
> 
> It looks like this finally-block is intended to unexport any exported RMI service, which will let the JVM exit. However, this is somewhat fragile. If the unexportObject() call fails with some other exception, the object might remain exported, and the JVM will hang indefinitely. (This has historically been a problem with RMI tests.)
> 
> Since the original version of the test ran each case in a separate JVM, I think it's ok to continue to do the same. The old version of the test called System.exit() along most code paths. It's somewhat odd that exit wasn't called along all code paths. Perhaps those code paths weren't taken, or if they were, the JVM exited of its own accord. In any case, I'd suggest ensuring that exit() is called along all code paths (success and failure) and keeping separate `@run main/othervm` lines in the header to run each case in its own JVM. This is at least equivalent to what the shell script based test was doing.
> 
> As an optimization, it might be reasonable to try to run some subset of the tests in a single JVM. They can't all be run in the same JVM though, because of system properties, so this would require some complexity to support running some cases in the same JVM and some in separate JVMs. It's not clear to me whether that's warranted.

I don't think all of those code paths ever executed. If `System.exit()` is called, regardless of the exit code, `make` treats it as an error:

`TEST RESULT: Failed. Unexpected exit from test [exit code: 0]`

I added a try/catch in `main` so that if an exception is thrown during the test, `System.exit` will be called.

-------------

PR: https://git.openjdk.org/jdk/pull/11910

From duke at openjdk.org  Fri Feb 17 20:41:23 2023
From: duke at openjdk.org (Matthew Donovan)
Date: Fri, 17 Feb 2023 20:41:23 GMT
Subject: RFR: 8298939: Refactor
 open/test/jdk/javax/rmi/ssl/SSLSocketParametersTest.sh to jtreg java test [v3]
In-Reply-To: <GrTY71oHZ-tnCU9A0gkYBtvFemypvh38-sbq2tAcnEM=.d4e137cd-4671-4b19-9a47-99fa1a5f89c0@github.com>
References: <VC_ou2XS44PtyTfwXw0VZRtXcHEbXImlLZKniIPRqOw=.7d10a168-77f8-4552-97a3-8b2570e3fe29@github.com>
 <y65OxkcJ9OlzgC1Q-o62zILzqMIQA9SQk_pg6zdpe7U=.d7745cdf-f803-45bd-a3fb-8d6bb146c2c2@github.com>
 <VXfns8mD49MsvScZQA0W-2gsiLMrv4vI3gh-_ARssF4=.b7f3293f-aba6-487d-9769-fecb34f46af8@github.com>
 <GrTY71oHZ-tnCU9A0gkYBtvFemypvh38-sbq2tAcnEM=.d4e137cd-4671-4b19-9a47-99fa1a5f89c0@github.com>
Message-ID: <HHx0ULasrYAgsymomLA_X-zjJLpta6tTAkWJOO6-oV8=.b3ddf5d9-002c-4362-8261-7e3b92af2461@github.com>

On Fri, 17 Feb 2023 19:57:18 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> test/jdk/javax/rmi/ssl/SSLSocketParametersTest.java line 211:
>> 
>>> 209:                         throw exc;
>>> 210:                     }
>>> 211:                 }
>> 
>> Having exception handling in the run() method and also in this switch statement is quite confusing. It obscures the fact that these cases (4 and 5) don't call run() at all. It would be good to find a structure that makes it clear that some test cases are for exceptions that occur at ServerFactory creation time and other exceptions occur when an actual socket connection is attempted.
>
> Perhaps some refactoring should be done in a separate PR. 
> The stated goal was to remove the use of the shell script; but its easy to start to refactor more and more.

I did a little refactoring here to clarify (I hope) the tests and remove some redundant code.

-------------

PR: https://git.openjdk.org/jdk/pull/11910

From duke at openjdk.org  Fri Feb 17 20:41:27 2023
From: duke at openjdk.org (Matthew Donovan)
Date: Fri, 17 Feb 2023 20:41:27 GMT
Subject: RFR: 8298939: Refactor
 open/test/jdk/javax/rmi/ssl/SSLSocketParametersTest.sh to jtreg java test [v4]
In-Reply-To: <VhLDvwJ54UU63L4emLdpQvO425M03Mp8FPoUzU4iusQ=.218d2b73-c6dc-4e22-b62d-b36e3a411898@github.com>
References: <VC_ou2XS44PtyTfwXw0VZRtXcHEbXImlLZKniIPRqOw=.7d10a168-77f8-4552-97a3-8b2570e3fe29@github.com>
 <y65OxkcJ9OlzgC1Q-o62zILzqMIQA9SQk_pg6zdpe7U=.d7745cdf-f803-45bd-a3fb-8d6bb146c2c2@github.com>
 <VhLDvwJ54UU63L4emLdpQvO425M03Mp8FPoUzU4iusQ=.218d2b73-c6dc-4e22-b62d-b36e3a411898@github.com>
Message-ID: <BZ_ZIq4Fz5lAQhYKMQn896m4O7XVKMuJ6oyDfE4Obao=.d6f7f596-4170-4f0f-8ea0-2c62b134bb43@github.com>

On Fri, 17 Feb 2023 15:17:59 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Matthew Donovan 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:
>> 
>>  - added System.exit when exceptions are thrown and refactored for clarity
>>  - Merge branch 'master' into rmi-sslparams
>>  - added default switch case and additional refactoring
>>  - added exceptions for cases 4 and 5
>>  - clarified cases 4 and 5
>>  - 8298939: Refactor open/test/jdk/javax/rmi/ssl/SSLSocketParametersTest.sh to jtreg java test
>
> test/jdk/javax/rmi/ssl/SSLSocketParametersTest.java line 261:
> 
>> 259:             }
>> 260:             break;
>> 261:         default:
> 
> The default should be retained to produce an error.

I put the default case back

-------------

PR: https://git.openjdk.org/jdk/pull/11910

From darcy at openjdk.org  Fri Feb 17 21:17:10 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 17 Feb 2023 21:17:10 GMT
Subject: RFR: JDK-8302028: Port fdlibm atan2 to Java [v3]
In-Reply-To: <xl79M-V4_2t49GuCudJHQBaJjAcwWl9f2Bv19RbAmdo=.b9c97066-8cf4-4569-8b4b-8b4874e23833@github.com>
References: <xl79M-V4_2t49GuCudJHQBaJjAcwWl9f2Bv19RbAmdo=.b9c97066-8cf4-4569-8b4b-8b4874e23833@github.com>
Message-ID: <jQp4_Sq1K7t3gHJm-OLjIlXw25o2qBQCktunjcFmQp0=.91e61e19-6da1-4159-be65-87145a15dafd@github.com>

> Working down the porting list, next stop, atan2.

Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:

  Correct and test for issue found in code review.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12608/files
  - new: https://git.openjdk.org/jdk/pull/12608/files/8b71e186..2c524913

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12608&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12608&range=01-02

  Stats: 31 lines in 4 files changed: 27 ins; 1 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/12608.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12608/head:pull/12608

PR: https://git.openjdk.org/jdk/pull/12608

From darcy at openjdk.org  Fri Feb 17 21:17:13 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 17 Feb 2023 21:17:13 GMT
Subject: RFR: JDK-8302028: Port fdlibm atan2 to Java [v2]
In-Reply-To: <FSMfXwXXxe2sBtxB5J641Hh9o8WKPX2k7-n2bpOhrWU=.e8281db1-ecc4-43e0-bbe2-1c419e1111f0@github.com>
References: <xl79M-V4_2t49GuCudJHQBaJjAcwWl9f2Bv19RbAmdo=.b9c97066-8cf4-4569-8b4b-8b4874e23833@github.com>
 <TMI7ZKI2Qc9DL_wLKNwMXAtu7hstoL-mrZjEIsv-MT0=.dace04d5-ec7e-40c2-b540-4e1f5e68bd38@github.com>
 <FSMfXwXXxe2sBtxB5J641Hh9o8WKPX2k7-n2bpOhrWU=.e8281db1-ecc4-43e0-bbe2-1c419e1111f0@github.com>
Message-ID: <_uq1PrTFR7VC0cIH1LHbyOUd3XL2iL4-Kl2g09mpqoE=.487ceb7a-814a-44ab-91a7-98d425fa63b0@github.com>

On Fri, 17 Feb 2023 13:50:17 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> Joe Darcy 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:
>> 
>>  - Update regression test.
>>  - Merge branch 'master' into JDK-8302028
>>  - JDK-8302028: Port fdlibm atan2 to Java
>
> src/java.base/share/classes/java/lang/FdLibm.java line 447:
> 
>> 445:             ly = __LO(y);
>> 446:             if (((ix | ((lx | -lx) >> 31)) > 0x7ff0_0000)||
>> 447:                 ((iy |((ly | - ly) >> 31)) > 0x7ff0_0000))    // x or y is NaN
> 
> I think that `>> 31` must be replaced by `>>> 31`.

Well spotted; corrected the code and added additional tests to catch that case. Thanks.

-------------

PR: https://git.openjdk.org/jdk/pull/12608

From duke at openjdk.org  Fri Feb 17 21:24:26 2023
From: duke at openjdk.org (ExE Boss)
Date: Fri, 17 Feb 2023 21:24:26 GMT
Subject: RFR: 8302590: Add String.indexOf(int ch, int fromIndex,
 int toIndex)
In-Reply-To: <uQ65oRaVDfpzm9bYRuo_MvSuZIdepicE3GnB3Omyngs=.fc23545b-141a-47e5-8a6a-aa28ae1375e5@github.com>
References: <uQ65oRaVDfpzm9bYRuo_MvSuZIdepicE3GnB3Omyngs=.fc23545b-141a-47e5-8a6a-aa28ae1375e5@github.com>
Message-ID: <5X_SmwViMWYt3B_Dt_88jEWOT7-IRYywD5kkPa9K988=.6d208a51-d825-4e82-92b5-ca9ff6645667@github.com>

On Thu, 16 Feb 2023 17:16:35 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

> Add an `indexOf()` variant allowing to specify both a lower and an upper bound on the search.

Could?we also?get a?similar?overload for?`String::lastIndexOf`?

-------------

PR: https://git.openjdk.org/jdk/pull/12600

From jvernee at openjdk.org  Fri Feb 17 21:25:26 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Fri, 17 Feb 2023 21:25:26 GMT
Subject: RFR: 8302154: Hidden classes created by LambdaMetaFactory can't be
 unloaded [v2]
In-Reply-To: <bYkGnm79U37ob-7VlaEzPlzcJZrFpzn0mnnZxCen5wk=.268d1655-2ed2-4d9c-895f-84de711ee611@github.com>
References: <YoZauVv8zvhdUw-LD25LrsMDItFbg3aXPU3deXwwFdQ=.c2839dea-12e5-4e0e-9579-eac9d8503932@github.com>
 <gKoLpwlXDxp2uaSKSkMArJl1Ym9VX1hoDFqQTTUpk8w=.e1dce669-5a42-4b66-ac4b-205718c8eb81@github.com>
 <bYkGnm79U37ob-7VlaEzPlzcJZrFpzn0mnnZxCen5wk=.268d1655-2ed2-4d9c-895f-84de711ee611@github.com>
Message-ID: <mdUCR3q15IQlPgv28lLdZHVWkUn67KeHgLMRtlV6UlU=.9ae87930-e6c6-4428-bcb2-76e4578628d5@github.com>

On Fri, 17 Feb 2023 20:01:08 GMT, Volker Simonis <simonis at openjdk.org> wrote:

> (because they are all not referenced from the program any more).

So, it sounds like this is testing a case where `LambdaMetafactory.metafactory` is being called directly?

I'd like to point out that, while I buy that people are doing this (I see enough of this on StackOverflow), `LambdaMetafactory` is a runtime API specifically designed to support a language feature. Calling it directly is an unintended use case. We should cater towards the intended use case instead (the language feature) which benefits from the strong tie to the class loader.

This change also seems to hurt the common case in favor of the rare case. The native memory cost should be multiplied by the ratio of use case that see a regression (lambdas) to the use cases that see an improvement (direct calls to LambdaMetafactory). I think it is safe to say that that ratio is quite large. i.e. we seem to be trading one regression for another, far worse one.

-------------

PR: https://git.openjdk.org/jdk/pull/12493

From darcy at openjdk.org  Fri Feb 17 21:47:24 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 17 Feb 2023 21:47:24 GMT
Subject: RFR: JDK-8302028: Port fdlibm atan2 to Java [v2]
In-Reply-To: <_uq1PrTFR7VC0cIH1LHbyOUd3XL2iL4-Kl2g09mpqoE=.487ceb7a-814a-44ab-91a7-98d425fa63b0@github.com>
References: <xl79M-V4_2t49GuCudJHQBaJjAcwWl9f2Bv19RbAmdo=.b9c97066-8cf4-4569-8b4b-8b4874e23833@github.com>
 <TMI7ZKI2Qc9DL_wLKNwMXAtu7hstoL-mrZjEIsv-MT0=.dace04d5-ec7e-40c2-b540-4e1f5e68bd38@github.com>
 <FSMfXwXXxe2sBtxB5J641Hh9o8WKPX2k7-n2bpOhrWU=.e8281db1-ecc4-43e0-bbe2-1c419e1111f0@github.com>
 <_uq1PrTFR7VC0cIH1LHbyOUd3XL2iL4-Kl2g09mpqoE=.487ceb7a-814a-44ab-91a7-98d425fa63b0@github.com>
Message-ID: <u2JIKy1bpDL7ChGSHyWyQK-ZAnV5DJ-hQydOtjSKaJM=.c81aa811-8fd6-4a3e-93c9-c29b02e98b5f@github.com>

On Fri, 17 Feb 2023 21:12:25 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Well spotted; corrected the code and added additional tests to catch that case. Thanks.

PS From some quick manual inspections, the other recent ports of FDLIBM methods don't look vulnerable to this kind of problem. However, as follow-up work later in 21 I'll implement: JDK-8302800: Augment NaN handling tests of FDLIBM methods.

-------------

PR: https://git.openjdk.org/jdk/pull/12608

From stuefe at openjdk.org  Fri Feb 17 21:48:33 2023
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Fri, 17 Feb 2023 21:48:33 GMT
Subject: RFR: 8302154: Hidden classes created by LambdaMetaFactory can't be
 unloaded [v2]
In-Reply-To: <gKoLpwlXDxp2uaSKSkMArJl1Ym9VX1hoDFqQTTUpk8w=.e1dce669-5a42-4b66-ac4b-205718c8eb81@github.com>
References: <YoZauVv8zvhdUw-LD25LrsMDItFbg3aXPU3deXwwFdQ=.c2839dea-12e5-4e0e-9579-eac9d8503932@github.com>
 <gKoLpwlXDxp2uaSKSkMArJl1Ym9VX1hoDFqQTTUpk8w=.e1dce669-5a42-4b66-ac4b-205718c8eb81@github.com>
Message-ID: <Dy-0mmzpH_xJ-wjUY84EalEwZF4wmJGcRhcazv7-hhU=.5eafbfec-d015-41fb-959e-ee2e223b139e@github.com>

On Thu, 9 Feb 2023 18:11:18 GMT, Volker Simonis <simonis at openjdk.org> wrote:

>> Prior to [JDK-8239384](https://bugs.openjdk.org/browse/JDK-8239384)/[JDK-8238358](https://bugs.openjdk.org/browse/JDK-8238358) LambdaMetaFactory has created VM-anonymous classes which could easily be unloaded once they were not referenced any more. Starting with JDK 15 and the new "hidden class" based implementation, this is not the case any more, because the hidden classes will be strongly tied to their defining class loader. If this is the default application class loader, these hidden classes can never be unloaded which can easily lead to Metaspace exhaustion (see the [test case in the JBS issue](https://bugs.openjdk.org/secure/attachment/102601/LambdaClassLeak.java)). This is a regression compared to previous JDK versions which some of our applications have been affected from when migrating to JDK 17.
>> 
>> The reason why the newly created hidden classes are strongly linked to their defining class loader is not clear to me. JDK-8239384 mentions it as an "implementation detail":
>> 
>>> *4. the lambda proxy class has the strong relationship with the class loader (that will share the VM metaspace for its defining loader - implementation details)*
>> 
>> From my current understanding the strong link between a hidden class created by `LambdaMetaFactory` and its defining class loader is not strictly required. In order to prevent potential OOMs and fix the regression compared the JDK 14 and earlier I propose to create these hidden classes without the `STRONG` option.
>> 
>> I'll be happy to add the test case as JTreg test to this PR if you think that would be useful.
>
> Volker Simonis has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Remove assertions which insist on Lambda proxy classes being strongly linked to their class loader
>  - Removed unused import of STRONG und updated copyright year

Hi Volker,

just a short feedback since I'm entering vacation mode.

> In general it seems to me that creating a new `ClassLoaderData` for each hidden (or VM anonymous) class is a lot of overhead and was probably only done as "a hack" to simplify the implementation of class unloading for such classes. This might have been appropriate in the "early days" when we had just a few VM anonymous classes. But as the usage of `LambdaMetafactory.metafactory()` becomes more common it may make sense to revise the implementation such that for example all hidden classes defined by a class loader can live in a single `ClassLoaderData` structure. I think this should be technically possible although it would complicate the unloading logic (and should therefore be postponed to a later change).

Interesting numbers. I underestimated the impact of native allocations.

A side note, the amount of waste avoided by JEP 371 depends highly on the actual size of the lambda (precisely, how close a lambda would be to the chunk size). That's pretty much random, but nice to know since it can shift the numbers from almost nil overhead to almost twofold overhead.

>I'd argue that Metaspace is more "valuable" than native memory because it is limited by -XX:MetaspaceSize, whereas native memory is only limited by the amount of available memory on the system. Also, growing Metaspace will trigger garbage collections which might be unexpected.

I don't follow that logic, for several reasons:
- Metaspace is more easily reclaimed, since it returns memory to the OS eagerly (since JEP 387). C-Heap, otoh, sticks to the process unless you (atm) manually trim. Depends on the libc used, but with glibc - arguable the main platform - this is the state. We are working on C-heap autotrim, but it is not completed yet. 
So while Metaspace is limited, it recovers from spikes more easily.
- The metaspace GC threshold is an (impreceise) mechanism to trigger GC based on native resource consumption. That this is not affected by C-heap memory is just a side effect of an imperfect implementation - ideally, all native resources associated with a class loader - be it metaspace or C-heap - together would weight into the decision of when to do a GC. In fact, your numbers may be taken as a hint that maybe CLDs should live in Metaspace instead.

---

As I stated before, we do have the ability to prematurely repurpose metaspace before the loader dies via Metaspace::deallocate(). It would be nice if there were a mechanism to trigger this at least from Java. E.g. by making Lambdas closable.

-------------

PR: https://git.openjdk.org/jdk/pull/12493

From rgiulietti at openjdk.org  Fri Feb 17 21:54:24 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Fri, 17 Feb 2023 21:54:24 GMT
Subject: RFR: 8302590: Add String.indexOf(int ch, int fromIndex,
 int toIndex)
In-Reply-To: <5X_SmwViMWYt3B_Dt_88jEWOT7-IRYywD5kkPa9K988=.6d208a51-d825-4e82-92b5-ca9ff6645667@github.com>
References: <uQ65oRaVDfpzm9bYRuo_MvSuZIdepicE3GnB3Omyngs=.fc23545b-141a-47e5-8a6a-aa28ae1375e5@github.com>
 <5X_SmwViMWYt3B_Dt_88jEWOT7-IRYywD5kkPa9K988=.6d208a51-d825-4e82-92b5-ca9ff6645667@github.com>
Message-ID: <grx1dEop1syYY72t2U8qbvvxpcV2OyIxl0IAdhT-LzA=.5622b0a7-ae5f-4f46-8256-9482fccb4582@github.com>

On Fri, 17 Feb 2023 21:21:30 GMT, ExE Boss <duke at openjdk.org> wrote:

>> Add an `indexOf()` variant allowing to specify both a lower and an upper bound on the search.
>
> Could?we also?get a?similar?overload for?`String::lastIndexOf`?

@ExE-Boss See the second half [here](https://mail.openjdk.org/pipermail/core-libs-dev/2023-February/100391.html) for an explanation of why this is (currently) not part of this PR.

-------------

PR: https://git.openjdk.org/jdk/pull/12600

From bpb at openjdk.org  Sat Feb 18 00:18:09 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Sat, 18 Feb 2023 00:18:09 GMT
Subject: RFR: 8302806: (fs) Remove unused enum
 sun.nio.file.SensitivityWatchEventModifier
Message-ID: <FZn8ZF4sN5mtUO8MWPaC0N8nWFwTLkBvcqQeOPwVYeE=.a6e12227-dfa9-4817-adbb-bece72445860@github.com>

This enum is not used in the JDK and did not appear in external source code searches.

-------------

Commit messages:
 - 8302806: (fs) Remove unused enum sun.nio.file.SensitivityWatchEventModifier

Changes: https://git.openjdk.org/jdk/pull/12626/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12626&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8302806
  Stats: 65 lines in 1 file changed: 0 ins; 65 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/12626.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12626/head:pull/12626

PR: https://git.openjdk.org/jdk/pull/12626

From jpai at openjdk.org  Sat Feb 18 00:51:35 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Sat, 18 Feb 2023 00:51:35 GMT
Subject: RFR: 8302664: Fix several incorrect usages of
 Preconditions.checkFromIndexSize
In-Reply-To: <OGxWiIU0cyZnhxHVLd-ulwHSuuV4OEc9GtLBUjZDGfM=.f2d0cdb7-17b2-4c7d-9490-12d95e7352c4@github.com>
References: <OGxWiIU0cyZnhxHVLd-ulwHSuuV4OEc9GtLBUjZDGfM=.f2d0cdb7-17b2-4c7d-9490-12d95e7352c4@github.com>
Message-ID: <H-2SYODzWZY9zA0g101VToxV6GAWAZ4VKm0wJO3Iruc=.4aa395cf-6b1f-4e2f-ae82-bcc290e360e2@github.com>

On Thu, 16 Feb 2023 14:42:52 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change which fixes the usage of `Preconditions.checkFromIndexSize`? This addresses https://bugs.openjdk.org/browse/JDK-8302664.
> 
> There was an oversight when these changes were introduced in https://github.com/openjdk/jdk/pull/4507. I have now gone through that patch again to make sure the relevant places where this fix is needed has been addressed in this current PR.
> 
> I have also looked into other changes in that PR, just to be sure that there aren't any similar fixes needed for other method calls that were introduced in it - they all look fine.
> 
> tier1,tier2 and tier3 testing with this change passed successfully. I thought (and experimented a bit) to add new tests for Deflater/Inflater to catch these byte array indexing issues, but it wasn't straight forward and I would have to write the entire inflate/deflate test just to verify this issue. So I decided to leave out new tests for now in this PR.

Thank you all for the reviews.

-------------

PR: https://git.openjdk.org/jdk/pull/12595

From jpai at openjdk.org  Sat Feb 18 00:51:35 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Sat, 18 Feb 2023 00:51:35 GMT
Subject: Integrated: 8302664: Fix several incorrect usages of
 Preconditions.checkFromIndexSize
In-Reply-To: <OGxWiIU0cyZnhxHVLd-ulwHSuuV4OEc9GtLBUjZDGfM=.f2d0cdb7-17b2-4c7d-9490-12d95e7352c4@github.com>
References: <OGxWiIU0cyZnhxHVLd-ulwHSuuV4OEc9GtLBUjZDGfM=.f2d0cdb7-17b2-4c7d-9490-12d95e7352c4@github.com>
Message-ID: <UqsmHymQ1KB9QVRvD26XVvjy0UaU_JC05dTpgadTGPo=.29800085-8698-46ca-8d43-91ad6e076b9e@github.com>

On Thu, 16 Feb 2023 14:42:52 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change which fixes the usage of `Preconditions.checkFromIndexSize`? This addresses https://bugs.openjdk.org/browse/JDK-8302664.
> 
> There was an oversight when these changes were introduced in https://github.com/openjdk/jdk/pull/4507. I have now gone through that patch again to make sure the relevant places where this fix is needed has been addressed in this current PR.
> 
> I have also looked into other changes in that PR, just to be sure that there aren't any similar fixes needed for other method calls that were introduced in it - they all look fine.
> 
> tier1,tier2 and tier3 testing with this change passed successfully. I thought (and experimented a bit) to add new tests for Deflater/Inflater to catch these byte array indexing issues, but it wasn't straight forward and I would have to write the entire inflate/deflate test just to verify this issue. So I decided to leave out new tests for now in this PR.

This pull request has now been integrated.

Changeset: 43cf8b3d
Author:    Jaikiran Pai <jpai at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/43cf8b3d8067bc7128c98f86d5f8b6fa8bbed80e
Stats:     19 lines in 8 files changed: 0 ins; 0 del; 19 mod

8302664: Fix several incorrect usages of Preconditions.checkFromIndexSize

Reviewed-by: djelinski, dfuchs, alanb

-------------

PR: https://git.openjdk.org/jdk/pull/12595

From duke at openjdk.org  Sat Feb 18 01:43:24 2023
From: duke at openjdk.org (David Schlosnagle)
Date: Sat, 18 Feb 2023 01:43:24 GMT
Subject: RFR: 8302315: Examine cost of clone of primitive arrays compared
 to arraycopy
In-Reply-To: <-mibOqDijYlnk44SsmO1vIsq4lWIQYQIEhIE686C3wE=.ef8847ee-90b6-4080-8532-e9783b22901d@github.com>
References: <-mibOqDijYlnk44SsmO1vIsq4lWIQYQIEhIE686C3wE=.ef8847ee-90b6-4080-8532-e9783b22901d@github.com>
Message-ID: <OdlTsv5ScH6QaNU32wuTvjl4WKQlH5muDNQ1RT5L9O4=.98f8faf9-9f20-4864-8271-01c011289e73@github.com>

On Fri, 17 Feb 2023 09:58:54 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> During work on #12453 @schlosna reported that `array.clone()` might underperform `System.arraycopy` in microbenchmarks and I opted to go with `arraycopy` throughout while investigating.
> 
> Testing on x86 (SandyBridge, AVX2) I observe no difference at all between the setups. On aarch the only difference I can observe is that arraycopy seem curiously slow for input size = 0, otherwise no statistically significant difference. All tests ran on builds from JDK mainline and 21-b9.
> 
> Since the reported difference was small and mostly visible on very large arrays I conclude that the maintainability win we get from using `clone()` is preferable. I've added the microbenchmark provided by @schlosna here.

Marked as reviewed by schlosna at github.com (no known OpenJDK username).

-------------

PR: https://git.openjdk.org/jdk/pull/12613

From mchung at openjdk.org  Sat Feb 18 01:58:29 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Sat, 18 Feb 2023 01:58:29 GMT
Subject: RFR: 8302154: Hidden classes created by LambdaMetaFactory can't be
 unloaded [v2]
In-Reply-To: <bYkGnm79U37ob-7VlaEzPlzcJZrFpzn0mnnZxCen5wk=.268d1655-2ed2-4d9c-895f-84de711ee611@github.com>
References: <YoZauVv8zvhdUw-LD25LrsMDItFbg3aXPU3deXwwFdQ=.c2839dea-12e5-4e0e-9579-eac9d8503932@github.com>
 <gKoLpwlXDxp2uaSKSkMArJl1Ym9VX1hoDFqQTTUpk8w=.e1dce669-5a42-4b66-ac4b-205718c8eb81@github.com>
 <bYkGnm79U37ob-7VlaEzPlzcJZrFpzn0mnnZxCen5wk=.268d1655-2ed2-4d9c-895f-84de711ee611@github.com>
Message-ID: <mCiV2qpn4JzY7zRO8lIEIo-Lq6vpGrnF7wzZf4beYM8=.aa98a46b-d39c-4866-a6cb-731b7e23dd48@github.com>

On Fri, 17 Feb 2023 20:01:08 GMT, Volker Simonis <simonis at openjdk.org> wrote:

> Finally, the PR fixes a regression compared to the JDK 11 behavior.

This is an intended change that improves the C heap memory usage.   In addition, the spec of `LambdaMetafactory` has no guarantee of the spinned classes be unloaded independent of it defining loader.   This is indeed a behavioral change if `LambdaMetafactory` API is called directly instead of via `invokedynamic`.   I can create a CSR to retrofit this behavioral change.

-------------

PR: https://git.openjdk.org/jdk/pull/12493

From duke at openjdk.org  Sat Feb 18 02:43:26 2023
From: duke at openjdk.org (ExE Boss)
Date: Sat, 18 Feb 2023 02:43:26 GMT
Subject: RFR: JDK-8302666: Replace CHM with VarHandle in ForeachOrderedTask
 [v2]
In-Reply-To: <fLSt64PoI3s47g0BLWPMUkim0lmnuZ6wxoBJZppqgqg=.36deb86f-2998-490d-9e29-903e142c72d1@github.com>
References: <HAgE8xmpZT_2-b5ZDr8TgJNgjhVb3D4ZS3sQqA7c6Mo=.389fa590-681c-44a9-9823-8f70a6129797@github.com>
 <fLSt64PoI3s47g0BLWPMUkim0lmnuZ6wxoBJZppqgqg=.36deb86f-2998-490d-9e29-903e142c72d1@github.com>
Message-ID: <be3it2vmk01uSQwSjoQqsm0YheSdnbRXpiOyMh_iTcI=.0632f868-8583-443a-b50d-e35e91206a86@github.com>

On Fri, 17 Feb 2023 11:39:21 GMT, Viktor Klang <duke at openjdk.org> wrote:

>> I noticed when looking at the code that there was no real need to use a CHM to perform the tracking of activation in an ordered fashion on ForEachOrderedTask, but instead a VarHandle can be used, reducing allocations and indirection.
>
> Viktor Klang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Write the initial value of the next reference without using the VarHandle

src/java.base/share/classes/java/util/stream/ForEachOps.java line 515:

> 513:             //
> 514:             @SuppressWarnings("unchecked")
> 515:             var leftDescendant = (ForEachOrderedTask<S, T>)NEXT.getAndSet(this, null);

I?don?t?think that?this?needs a?`@SuppressWarnings("unchecked")`, as?casts of?signature?polymorphic return?values don?t?emit unchecked?warnings (unless?that?changed?recently):
Suggestion:

            var leftDescendant = (ForEachOrderedTask<S, T>) NEXT.getAndSet(this, (ForEachOrderedTask<S, T>) null);

-------------

PR: https://git.openjdk.org/jdk/pull/12320

From duke at openjdk.org  Sat Feb 18 03:35:30 2023
From: duke at openjdk.org (David M. Lloyd)
Date: Sat, 18 Feb 2023 03:35:30 GMT
Subject: RFR: 8292914: Drop the counter from lambda class names [v6]
In-Reply-To: <QmD1r95Ztib9LqUzkJa6MBeZvgR95EXWBIpsgQt38qg=.7c466759-3ce1-4aa1-b2b4-571cad5c70d3@github.com>
References: <GgLfH-ueBQqT-Mfk1mKpKFAt8fYqyjfVJ9lmlsBsCbo=.8dd5b3b4-4e84-4970-9179-1c0399b30edc@github.com>
 <zlDm2W50G6NgRkzmgEpX6MTVs3XyYMnY3tN1YnObWUA=.03a3d8d7-4d20-4fc6-8028-b20a8603b0a6@github.com>
 <QmD1r95Ztib9LqUzkJa6MBeZvgR95EXWBIpsgQt38qg=.7c466759-3ce1-4aa1-b2b4-571cad5c70d3@github.com>
Message-ID: <ZIXD3UpwXTUWUqxAo9pWjBuRNCKeU94qa_c3qnmuCyc=.76035cff-cf88-4993-b87c-14f1bf127d6e@github.com>

On Fri, 17 Feb 2023 02:11:10 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> David M. Lloyd has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Use a unique index for the dumped lambda class instead of a time stamp
>
> `this_class` in the classbyte is shown in the VM logging (`-Xlog:class+nestmates=debug`).  It'd be helpful if it can easily correlate to the dumped file.   For example, 3 lambda proxy classes of the same name of `this_class` but they are unique hidden classes.
> 
> 
> 0.058s][info ][class,nestmates] LookupDefineClass: jdk/internal/module/DefaultRoots$$Lambda$ - with dynamic nest-host jdk.internal.module.DefaultRoots, hidden, strong, with vm annotations
> [0.058s][debug][class,nestmates] Dynamic nestmate: java.base/jdk.internal.module.DefaultRoots$$Lambda$/0x000000080000a970, nest_host jdk.internal.module.DefaultRoots, is hidden
> [0.062s][info ][class,nestmates] LookupDefineClass: jdk/internal/module/DefaultRoots$$Lambda$ - with dynamic nest-host jdk.internal.module.DefaultRoots, hidden, strong, with vm annotations
> [0.062s][debug][class,nestmates] Dynamic nestmate: java.base/jdk.internal.module.DefaultRoots$$Lambda$/0x000000080000b998, nest_host jdk.internal.module.DefaultRoots, is hidden
> [0.068s][info ][class,nestmates] LookupDefineClass: jdk/internal/module/DefaultRoots$$Lambda$ - with dynamic nest-host jdk.internal.module.DefaultRoots, hidden, strong, with vm annotations
> [0.068s][debug][class,nestmates] Dynamic nestmate: java.base/jdk.internal.module.DefaultRoots$$Lambda$/0x000000080000c0b0, nest_host jdk.internal.module.DefaultRoots, is hidden
> 
> 
> What about keeping your original idea - the filename matching the hidden class name if successfully defined.   If it fails at `defineHiddenClass` time, use `lambdaClassName` + counter? 
> 
> Also, `test/jdk/java/lang/StackWalker/VerifyStackTrace.java` tests need update because of the lambda proxy class name change.

I've updated the patch to work as I originally imagined at the suggestion of @mlchung and it looks like the remaining tests are passing, including on Windows now that it is no longer timestamp-based.

-------------

PR: https://git.openjdk.org/jdk/pull/12579

From jwaters at openjdk.org  Sat Feb 18 07:33:23 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Sat, 18 Feb 2023 07:33:23 GMT
Subject: RFR: 8302667: Improve message format when failing to load symbols
 or libraries [v2]
In-Reply-To: <B-eIiBotI3cwCwWY5r2xYPlHfnV4dKJIHJdwg-hbDeQ=.ff83dbdf-e456-48b7-aa7f-e8cf75f71b5a@github.com>
References: <tu4ol4DO1PeplhgjhkYpXLwES142ztBXsM43uQO_CNE=.bfca85a4-2323-487d-9261-964671e00bf3@github.com>
 <B-eIiBotI3cwCwWY5r2xYPlHfnV4dKJIHJdwg-hbDeQ=.ff83dbdf-e456-48b7-aa7f-e8cf75f71b5a@github.com>
Message-ID: <TnonnDW-VMKPoYGAR4Nf4IjPJtA3S-Ci6WUk8MTlvTs=.bd6408f2-53d8-4e89-ac8f-29179fac229c@github.com>

On Fri, 17 Feb 2023 14:08:34 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> DLL_ERROR4 is a macro expanding to an error message when a failure to load a generic item (shared libraries or an exported symbol from said libraries for example) occurs. "Error: loading:" is not a very pretty message, so this small change results in "Error: Failed to load %s" instead, which looks better and also means the message makes more sense if we want to append a reason behind as well, such as "Error: Failed to load libjvm.so because xxx"
>
> Julian Waters 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 'openjdk:master' into patch-6
>  - Error: Failed to load

No problem, what should I define ARG_ERROR18 as?

-------------

PR: https://git.openjdk.org/jdk/pull/12596

From alanb at openjdk.org  Sat Feb 18 08:27:22 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Sat, 18 Feb 2023 08:27:22 GMT
Subject: RFR: 8302806: (fs) Remove unused enum
 sun.nio.file.SensitivityWatchEventModifier
In-Reply-To: <FZn8ZF4sN5mtUO8MWPaC0N8nWFwTLkBvcqQeOPwVYeE=.a6e12227-dfa9-4817-adbb-bece72445860@github.com>
References: <FZn8ZF4sN5mtUO8MWPaC0N8nWFwTLkBvcqQeOPwVYeE=.a6e12227-dfa9-4817-adbb-bece72445860@github.com>
Message-ID: <HqeqM5WV1kmfHpIQOoVTM7ip8UICuLx1h5ZjbAa7Ubc=.bdad6b87-a668-4990-816c-411048a1651e@github.com>

On Sat, 18 Feb 2023 00:11:29 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> This enum is not used in the JDK and did not appear in external source code searches.

This API should probably have been deprecated many releases ago. It's the jdk.unsupported module so it may be possible to remove without first deprecating.

The PR is missing the implementation and test changes.

-------------

PR: https://git.openjdk.org/jdk/pull/12626

From alanb at openjdk.org  Sat Feb 18 09:06:23 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Sat, 18 Feb 2023 09:06:23 GMT
Subject: RFR: 8302315: Examine cost of clone of primitive arrays compared
 to arraycopy
In-Reply-To: <-mibOqDijYlnk44SsmO1vIsq4lWIQYQIEhIE686C3wE=.ef8847ee-90b6-4080-8532-e9783b22901d@github.com>
References: <-mibOqDijYlnk44SsmO1vIsq4lWIQYQIEhIE686C3wE=.ef8847ee-90b6-4080-8532-e9783b22901d@github.com>
Message-ID: <46riE_eriZnNAR7UkR7V9FEnY5OWtlxwX7bWU9HlSgQ=.306b73e7-a1a1-4d44-ad3b-e7f31c8424d3@github.com>

On Fri, 17 Feb 2023 09:58:54 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> During work on #12453 @schlosna reported that `array.clone()` might underperform `System.arraycopy` in microbenchmarks and I opted to go with `arraycopy` throughout while investigating.
> 
> Testing on x86 (SandyBridge, AVX2) I observe no difference at all between the setups. On aarch the only difference I can observe is that arraycopy seem curiously slow for input size = 0, otherwise no statistically significant difference. All tests ran on builds from JDK mainline and 21-b9.
> 
> Since the reported difference was small and mostly visible on very large arrays I conclude that the maintainability win we get from using `clone()` is preferable. I've added the microbenchmark provided by @schlosna here.

Marked as reviewed by alanb (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/12613

From eirbjo at gmail.com  Sat Feb 18 09:28:47 2023
From: eirbjo at gmail.com (=?UTF-8?B?RWlyaWsgQmrDuHJzbsO4cw==?=)
Date: Sat, 18 Feb 2023 10:28:47 +0100
Subject: Speed up StringLatin1.regionMatchesCI
Message-ID: <CA+pBWhtuquRjf03DjCgCrwzDuvgincRRgAFPU3J=HK+XUt2-nw@mail.gmail.com>

Hi,

The following PR suggests we can speed up StringLatin1.regionMatchesCI by
applying 'the oldest ASCII trick in the book':

https://github.com/openjdk/jdk/pull/12632

Thanks,
Eirik.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20230218/a1811cf8/attachment.htm>

From tvaleev at openjdk.org  Sat Feb 18 10:58:10 2023
From: tvaleev at openjdk.org (Tagir F. Valeev)
Date: Sat, 18 Feb 2023 10:58:10 GMT
Subject: RFR: 8302815 Use new Math.clamp method in core libraries
Message-ID: <k_xjmup3YSdUre0Z_XpO-WEBb5XED2FYv8UUZT2ULwc=.86f53f51-cceb-45fd-935d-b054c79a0526@github.com>

For cleanup and dogfooding the new method, it would be nice to use Math.clamp where possible in java.base. See PR #12428.

As Math.clamp performs an additional check that min is not greater than max, I conservatively replaced only those occurrences where I can see that this invariant is always held. There are more occurrences, where clamp can be potentially used but it's unclear whether min <= max is always true.

-------------

Commit messages:
 - 8302815 Use new Math.clamp method in core libraries

Changes: https://git.openjdk.org/jdk/pull/12633/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12633&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8302815
  Stats: 41 lines in 12 files changed: 0 ins; 8 del; 33 mod
  Patch: https://git.openjdk.org/jdk/pull/12633.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12633/head:pull/12633

PR: https://git.openjdk.org/jdk/pull/12633

From lancea at openjdk.org  Sat Feb 18 11:56:40 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Sat, 18 Feb 2023 11:56:40 GMT
Subject: RFR: 8301873: Avoid string decoding in ZipFile.Source.getEntryPos
 [v15]
In-Reply-To: <2Ab-zkCiRlWL6S2TCDzeauJfvacWxgFlC0LpLmeUVhA=.6ff1c130-8e83-4b41-b1bb-9741d068664b@github.com>
References: <FkmdspiHVjkAKFqm5kUgwaf55YH5cBbczS_3krqsdFs=.05eca901-f55f-47d9-b1bc-0cf2f5b87536@github.com>
 <2Ab-zkCiRlWL6S2TCDzeauJfvacWxgFlC0LpLmeUVhA=.6ff1c130-8e83-4b41-b1bb-9741d068664b@github.com>
Message-ID: <XGRNyk93g5-AALDEkYVpn21EX29r0vNQS6r9IfKo7K4=.ba8ae55f-bf7b-44c0-8e7e-5112f54c9a40@github.com>

On Wed, 15 Feb 2023 11:44:17 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

>> After finding a hash match, getEntryPos needs to compare the lookup name up to the encoded entry name in the CEN. This comparison is done by decoding the entry name into a String. The names can then be compared using the String API. This decoding step adds a significat cost to this method.
>> 
>> This PR suggest to update the string comparison such that in the common case where  both the lookup name and the entry name are encoded in ASCII-compatible UTF-8,  decoding can be avoided and the byte arrays can instead be compared direcly. 
>> 
>> ZipCoder is updated with a new method to compare a string with an encoded byte array range.  The default implementation decodes to string (like the current code), while the UTF-8 implementation uses JavaLangAccess.getBytesNoRepl to get the  bytes. Both methods thes uses Arrays.mismatch for comparison with or without matching trailing slashes. 
>> 
>> Additionally, this PR suggest to make the following updates to getEntryPos:
>> 
>> - The try/catch for IAE is redundant and can be safely removed. (initCEN already checks this and will throws IAE for invalid UTF-8). This seems to give a 3-4% speedup on micros)
>> - A new test InvalidBytesInEntryNameOrComment is a added to verify that initCEN does in fact reject invalid UTF-8 in CEN file names and comments. (I found no existing test coverage for this)
>> - The recursion when looking for "name/" matches is replaced with iteration. We keep track of any "name/" match and return it at the end of the search. (I feel this is easier to follow and it also gives a ~30% speedup for addSlash lookups with no regression on regular lookups)
>> 
>> (My though is that including these additional updates in this PR might reduce reviewer overhead given that it touches the exact same code. I might be wrong on this, please advise :)
>> 
>> I'm seeing a ~17% saving on the micro ZipFileGetEntry.getEntryHit (modified to use xalan.jar):
>> 
>> Baseline:
>> 
>> Benchmark                             (size)  Mode  Cnt    Score   Error  Units
>> ZipFileGetEntry.getEntryHit              512  avgt   15   74.941 ? 1.004  ns/op
>> ZipFileGetEntry.getEntryHit             1024  avgt   15   84.943 ? 1.320  ns/op
>> ZipFileGetEntry.getEntryHitUncached      512  avgt   15  120.371 ? 2.386  ns/op
>> ZipFileGetEntry.getEntryHitUncached     1024  avgt   15  126.128 ? 1.075  ns/op
>> ZipFileGetEntry.getEntryMiss             512  avgt   15   23.818 ? 0.838  ns/op
>> ZipFileGetEntry.getEntryMiss            1024  avgt   15   29.762 ? 5.998  ns/op
>> ZipFileGetEntry.getEntryMissUncached     512  avgt   15   59.405 ? 0.545  ns/op
>> ZipFileGetEntry.getEntryMissUncached    1024  avgt   15   71.840 ? 2.455  ns/op
>> ZipFileGetEntry.getEntrySlash            512  avgt   15  135.621 ? 4.341  ns/op
>> ZipFileGetEntry.getEntrySlash           1024  avgt   15  134.190 ? 2.141  ns/op
>> 
>> 
>> 
>> PR:
>> 
>> 
>> Benchmark                             (size)  Mode  Cnt    Score   Error  Units
>> ZipFileGetEntry.getEntryHit              512  avgt   15   62.267 ? 1.329  ns/op
>> ZipFileGetEntry.getEntryHit             1024  avgt   15   72.916 ? 2.428  ns/op
>> ZipFileGetEntry.getEntryHitUncached      512  avgt   15  101.630 ? 1.154  ns/op
>> ZipFileGetEntry.getEntryHitUncached     1024  avgt   15  113.161 ? 0.502  ns/op
>> ZipFileGetEntry.getEntryMiss             512  avgt   15   23.003 ? 1.191  ns/op
>> ZipFileGetEntry.getEntryMiss            1024  avgt   15   23.236 ? 1.114  ns/op
>> ZipFileGetEntry.getEntryMissUncached     512  avgt   15   56.781 ? 1.505  ns/op
>> ZipFileGetEntry.getEntryMissUncached    1024  avgt   15   67.767 ? 1.963  ns/op
>> ZipFileGetEntry.getEntrySlash            512  avgt   15   73.745 ? 2.717  ns/op
>> ZipFileGetEntry.getEntrySlash           1024  avgt   15   75.784 ? 1.051  ns/op
>> 
>> 
>> To assess the impact on startup/warmup, I made a main method class which measures the total time of calling ZipFile.getEntry for all entries in the 109 JAR file dependenies of spring-petclinic. The shows a nice improvement (time in micros):
>> 
>> 
>> Percentile Baseline Patch
>> 50?%          23155 21149
>> 75?%          23598 21454
>> 90?%          23989 21691
>> 95?%          24238 21973
>> 99?%          25270 22446
>> STDEV           792   549
>> Count           500   500
>
> Eirik Bjorsnos has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix a regression where the invalidName was tested instead of comment in the invalid comment test

Thank you Eirik for your patience through the review and testing of your PR.

I think we are in good shape overall.  Mach5 tiers1-6 look good as do the JCK tests for Zip

Best
Lance

-------------

Marked as reviewed by lancea (Reviewer).

PR: https://git.openjdk.org/jdk/pull/12290

From duke at openjdk.org  Sat Feb 18 12:42:40 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Sat, 18 Feb 2023 12:42:40 GMT
Subject: Integrated: 8301873: Avoid string decoding in
 ZipFile.Source.getEntryPos
In-Reply-To: <FkmdspiHVjkAKFqm5kUgwaf55YH5cBbczS_3krqsdFs=.05eca901-f55f-47d9-b1bc-0cf2f5b87536@github.com>
References: <FkmdspiHVjkAKFqm5kUgwaf55YH5cBbczS_3krqsdFs=.05eca901-f55f-47d9-b1bc-0cf2f5b87536@github.com>
Message-ID: <PTKDkIXCZwb-NgmjihEkFkt6JcoMJKTpMuJTvWL1T6U=.a2a18456-8594-4bff-b34d-29fe0472b7c3@github.com>

On Mon, 30 Jan 2023 10:32:38 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

> After finding a hash match, getEntryPos needs to compare the lookup name up to the encoded entry name in the CEN. This comparison is done by decoding the entry name into a String. The names can then be compared using the String API. This decoding step adds a significat cost to this method.
> 
> This PR suggest to update the string comparison such that in the common case where  both the lookup name and the entry name are encoded in ASCII-compatible UTF-8,  decoding can be avoided and the byte arrays can instead be compared direcly. 
> 
> ZipCoder is updated with a new method to compare a string with an encoded byte array range.  The default implementation decodes to string (like the current code), while the UTF-8 implementation uses JavaLangAccess.getBytesNoRepl to get the  bytes. Both methods thes uses Arrays.mismatch for comparison with or without matching trailing slashes. 
> 
> Additionally, this PR suggest to make the following updates to getEntryPos:
> 
> - The try/catch for IAE is redundant and can be safely removed. (initCEN already checks this and will throws IAE for invalid UTF-8). This seems to give a 3-4% speedup on micros)
> - A new test InvalidBytesInEntryNameOrComment is a added to verify that initCEN does in fact reject invalid UTF-8 in CEN file names and comments. (I found no existing test coverage for this)
> - The recursion when looking for "name/" matches is replaced with iteration. We keep track of any "name/" match and return it at the end of the search. (I feel this is easier to follow and it also gives a ~30% speedup for addSlash lookups with no regression on regular lookups)
> 
> (My though is that including these additional updates in this PR might reduce reviewer overhead given that it touches the exact same code. I might be wrong on this, please advise :)
> 
> I'm seeing a ~17% saving on the micro ZipFileGetEntry.getEntryHit (modified to use xalan.jar):
> 
> Baseline:
> 
> Benchmark                             (size)  Mode  Cnt    Score   Error  Units
> ZipFileGetEntry.getEntryHit              512  avgt   15   74.941 ? 1.004  ns/op
> ZipFileGetEntry.getEntryHit             1024  avgt   15   84.943 ? 1.320  ns/op
> ZipFileGetEntry.getEntryHitUncached      512  avgt   15  120.371 ? 2.386  ns/op
> ZipFileGetEntry.getEntryHitUncached     1024  avgt   15  126.128 ? 1.075  ns/op
> ZipFileGetEntry.getEntryMiss             512  avgt   15   23.818 ? 0.838  ns/op
> ZipFileGetEntry.getEntryMiss            1024  avgt   15   29.762 ? 5.998  ns/op
> ZipFileGetEntry.getEntryMissUncached     512  avgt   15   59.405 ? 0.545  ns/op
> ZipFileGetEntry.getEntryMissUncached    1024  avgt   15   71.840 ? 2.455  ns/op
> ZipFileGetEntry.getEntrySlash            512  avgt   15  135.621 ? 4.341  ns/op
> ZipFileGetEntry.getEntrySlash           1024  avgt   15  134.190 ? 2.141  ns/op
> 
> 
> 
> PR:
> 
> 
> Benchmark                             (size)  Mode  Cnt    Score   Error  Units
> ZipFileGetEntry.getEntryHit              512  avgt   15   62.267 ? 1.329  ns/op
> ZipFileGetEntry.getEntryHit             1024  avgt   15   72.916 ? 2.428  ns/op
> ZipFileGetEntry.getEntryHitUncached      512  avgt   15  101.630 ? 1.154  ns/op
> ZipFileGetEntry.getEntryHitUncached     1024  avgt   15  113.161 ? 0.502  ns/op
> ZipFileGetEntry.getEntryMiss             512  avgt   15   23.003 ? 1.191  ns/op
> ZipFileGetEntry.getEntryMiss            1024  avgt   15   23.236 ? 1.114  ns/op
> ZipFileGetEntry.getEntryMissUncached     512  avgt   15   56.781 ? 1.505  ns/op
> ZipFileGetEntry.getEntryMissUncached    1024  avgt   15   67.767 ? 1.963  ns/op
> ZipFileGetEntry.getEntrySlash            512  avgt   15   73.745 ? 2.717  ns/op
> ZipFileGetEntry.getEntrySlash           1024  avgt   15   75.784 ? 1.051  ns/op
> 
> 
> To assess the impact on startup/warmup, I made a main method class which measures the total time of calling ZipFile.getEntry for all entries in the 109 JAR file dependenies of spring-petclinic. The shows a nice improvement (time in micros):
> 
> 
> Percentile Baseline Patch
> 50?%          23155 21149
> 75?%          23598 21454
> 90?%          23989 21691
> 95?%          24238 21973
> 99?%          25270 22446
> STDEV           792   549
> Count           500   500

This pull request has now been integrated.

Changeset: 78f71b4d
Author:    Eirik Bjorsnos <eirbjo at gmail.com>
Committer: Claes Redestad <redestad at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/78f71b4d41f8682ea10b1573106b11c00f150a1c
Stats:     384 lines in 4 files changed: 359 ins; 9 del; 16 mod

8301873: Avoid string decoding in ZipFile.Source.getEntryPos

Reviewed-by: redestad, lancea

-------------

PR: https://git.openjdk.org/jdk/pull/12290

From redestad at openjdk.org  Sat Feb 18 15:21:32 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Sat, 18 Feb 2023 15:21:32 GMT
Subject: RFR: 8302315: Examine cost of clone of primitive arrays compared
 to arraycopy
In-Reply-To: <-mibOqDijYlnk44SsmO1vIsq4lWIQYQIEhIE686C3wE=.ef8847ee-90b6-4080-8532-e9783b22901d@github.com>
References: <-mibOqDijYlnk44SsmO1vIsq4lWIQYQIEhIE686C3wE=.ef8847ee-90b6-4080-8532-e9783b22901d@github.com>
Message-ID: <agGsfVSKmAv10nkubeVp5DMaORyuOzJfrV6aHL4ULnY=.44016fcf-d979-4ab3-8ee5-58dc25ee8abb@github.com>

On Fri, 17 Feb 2023 09:58:54 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> During work on #12453 @schlosna reported that `array.clone()` might underperform `System.arraycopy` in microbenchmarks and I opted to go with `arraycopy` throughout while investigating.
> 
> Testing on x86 (SandyBridge, AVX2) I observe no difference at all between the setups. On aarch the only difference I can observe is that arraycopy seem curiously slow for input size = 0, otherwise no statistically significant difference. All tests ran on builds from JDK mainline and 21-b9.
> 
> Since the reported difference was small and mostly visible on very large arrays I conclude that the maintainability win we get from using `clone()` is preferable. I've added the microbenchmark provided by @schlosna here.

Thanks for reviewing

-------------

PR: https://git.openjdk.org/jdk/pull/12613

From redestad at openjdk.org  Sat Feb 18 15:21:33 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Sat, 18 Feb 2023 15:21:33 GMT
Subject: Integrated: 8302315: Examine cost of clone of primitive arrays
 compared to arraycopy
In-Reply-To: <-mibOqDijYlnk44SsmO1vIsq4lWIQYQIEhIE686C3wE=.ef8847ee-90b6-4080-8532-e9783b22901d@github.com>
References: <-mibOqDijYlnk44SsmO1vIsq4lWIQYQIEhIE686C3wE=.ef8847ee-90b6-4080-8532-e9783b22901d@github.com>
Message-ID: <YWy8ic2X5jQUMQ5fIvQleqslSJbUGLKB5Mxwg3pD48c=.2005b4ad-0414-47df-81f3-fa329de92722@github.com>

On Fri, 17 Feb 2023 09:58:54 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> During work on #12453 @schlosna reported that `array.clone()` might underperform `System.arraycopy` in microbenchmarks and I opted to go with `arraycopy` throughout while investigating.
> 
> Testing on x86 (SandyBridge, AVX2) I observe no difference at all between the setups. On aarch the only difference I can observe is that arraycopy seem curiously slow for input size = 0, otherwise no statistically significant difference. All tests ran on builds from JDK mainline and 21-b9.
> 
> Since the reported difference was small and mostly visible on very large arrays I conclude that the maintainability win we get from using `clone()` is preferable. I've added the microbenchmark provided by @schlosna here.

This pull request has now been integrated.

Changeset: d6716d2e
Author:    Claes Redestad <redestad at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/d6716d2e5471ee794df8833430dd3171b565f78e
Stats:     163 lines in 2 files changed: 92 ins; 55 del; 16 mod

8302315: Examine cost of clone of primitive arrays compared to arraycopy

Reviewed-by: alanb

-------------

PR: https://git.openjdk.org/jdk/pull/12613

From duke at openjdk.org  Sat Feb 18 17:51:28 2023
From: duke at openjdk.org (liach)
Date: Sat, 18 Feb 2023 17:51:28 GMT
Subject: RFR: 8302154: Hidden classes created by LambdaMetaFactory can't be
 unloaded [v2]
In-Reply-To: <gKoLpwlXDxp2uaSKSkMArJl1Ym9VX1hoDFqQTTUpk8w=.e1dce669-5a42-4b66-ac4b-205718c8eb81@github.com>
References: <YoZauVv8zvhdUw-LD25LrsMDItFbg3aXPU3deXwwFdQ=.c2839dea-12e5-4e0e-9579-eac9d8503932@github.com>
 <gKoLpwlXDxp2uaSKSkMArJl1Ym9VX1hoDFqQTTUpk8w=.e1dce669-5a42-4b66-ac4b-205718c8eb81@github.com>
Message-ID: <d_Gql-qwS6HQjqYzkTK3QW1z4V-rmOmiTtQ3iXRZYsU=.f870a67e-a496-4afa-96f4-c9baa1e7c4f8@github.com>

On Thu, 9 Feb 2023 18:11:18 GMT, Volker Simonis <simonis at openjdk.org> wrote:

>> Prior to [JDK-8239384](https://bugs.openjdk.org/browse/JDK-8239384)/[JDK-8238358](https://bugs.openjdk.org/browse/JDK-8238358) LambdaMetaFactory has created VM-anonymous classes which could easily be unloaded once they were not referenced any more. Starting with JDK 15 and the new "hidden class" based implementation, this is not the case any more, because the hidden classes will be strongly tied to their defining class loader. If this is the default application class loader, these hidden classes can never be unloaded which can easily lead to Metaspace exhaustion (see the [test case in the JBS issue](https://bugs.openjdk.org/secure/attachment/102601/LambdaClassLeak.java)). This is a regression compared to previous JDK versions which some of our applications have been affected from when migrating to JDK 17.
>> 
>> The reason why the newly created hidden classes are strongly linked to their defining class loader is not clear to me. JDK-8239384 mentions it as an "implementation detail":
>> 
>>> *4. the lambda proxy class has the strong relationship with the class loader (that will share the VM metaspace for its defining loader - implementation details)*
>> 
>> From my current understanding the strong link between a hidden class created by `LambdaMetaFactory` and its defining class loader is not strictly required. In order to prevent potential OOMs and fix the regression compared the JDK 14 and earlier I propose to create these hidden classes without the `STRONG` option.
>> 
>> I'll be happy to add the test case as JTreg test to this PR if you think that would be useful.
>
> Volker Simonis has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Remove assertions which insist on Lambda proxy classes being strongly linked to their class loader
>  - Removed unused import of STRONG und updated copyright year

This "called directly" usage reminds me of another behavioral change around the time "original" access for lookup was introduced, where a library can no longer create SAM interface instances out of static methods, as the provided lookup had private access (previously full privilege) but couldn't have original access in newer Java.

-------------

PR: https://git.openjdk.org/jdk/pull/12493

From brett.okken.os at gmail.com  Sat Feb 18 18:36:13 2023
From: brett.okken.os at gmail.com (Brett Okken)
Date: Sat, 18 Feb 2023 12:36:13 -0600
Subject: String encodeASCII
Message-ID: <CANBJVOF1CAeOw99A6WFxJc60VOdDCctKxo5RKYtJA_2WUBchjg@mail.gmail.com>

https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/lang/String.java#L976-L981

For String.encodeASCII, with the LATIN1 coder is there any interest in
exploring the performance impacts of utilizing a
byteArrayViewVarHandle to read/write as longs and utilize a bitmask to
identify if negative values are present?

A simple jmh benchmark covering either 0 or 1 non-ascii (negative)
values shows times cut in half (or more) for most scenarios with
strings ranging in length from 3 - ~2000.
VM version: JDK 17.0.6, OpenJDK 64-Bit Server VM, 17.0.6+10
Windows 10 Intel(R) Core(TM) i7-9850H

Hand unrolling the loops shows noted improvement, but does make for
less aesthetically pleasing code.


Benchmark                                  (nonascii)  (size)  Mode
Cnt    Score     Error  Units
AsciiEncodeBenchmark.jdk                         none       3  avgt
4   15.531 ?   1.122  ns/op
AsciiEncodeBenchmark.jdk                         none      10  avgt
4   17.350 ?   0.473  ns/op
AsciiEncodeBenchmark.jdk                         none      16  avgt
4   18.277 ?   0.421  ns/op
AsciiEncodeBenchmark.jdk                         none      23  avgt
4   20.139 ?   0.350  ns/op
AsciiEncodeBenchmark.jdk                         none      33  avgt
4   22.008 ?   0.656  ns/op
AsciiEncodeBenchmark.jdk                         none      42  avgt
4   24.393 ?   1.155  ns/op
AsciiEncodeBenchmark.jdk                         none     201  avgt
4   55.884 ?   0.645  ns/op
AsciiEncodeBenchmark.jdk                         none     511  avgt
4  120.817 ?   2.917  ns/op
AsciiEncodeBenchmark.jdk                         none    2087  avgt
4  471.039 ?  13.329  ns/op
AsciiEncodeBenchmark.jdk                        first       3  avgt
4   15.794 ?   1.494  ns/op
AsciiEncodeBenchmark.jdk                        first      10  avgt
4   18.446 ?   0.780  ns/op
AsciiEncodeBenchmark.jdk                        first      16  avgt
4   20.458 ?   0.394  ns/op
AsciiEncodeBenchmark.jdk                        first      23  avgt
4   22.934 ?   0.422  ns/op
AsciiEncodeBenchmark.jdk                        first      33  avgt
4   25.367 ?   0.178  ns/op
AsciiEncodeBenchmark.jdk                        first      42  avgt
4   28.620 ?   0.678  ns/op
AsciiEncodeBenchmark.jdk                        first     201  avgt
4   80.250 ?   4.376  ns/op
AsciiEncodeBenchmark.jdk                        first     511  avgt
4  185.518 ?   6.370  ns/op
AsciiEncodeBenchmark.jdk                        first    2087  avgt
4  713.213 ?  13.488  ns/op
AsciiEncodeBenchmark.jdk                         last       3  avgt
4   14.991 ?   0.190  ns/op
AsciiEncodeBenchmark.jdk                         last      10  avgt
4   18.284 ?   0.317  ns/op
AsciiEncodeBenchmark.jdk                         last      16  avgt
4   20.591 ?   1.002  ns/op
AsciiEncodeBenchmark.jdk                         last      23  avgt
4   22.560 ?   0.963  ns/op
AsciiEncodeBenchmark.jdk                         last      33  avgt
4   25.521 ?   0.554  ns/op
AsciiEncodeBenchmark.jdk                         last      42  avgt
4   28.484 ?   0.446  ns/op
AsciiEncodeBenchmark.jdk                         last     201  avgt
4   79.434 ?   2.256  ns/op
AsciiEncodeBenchmark.jdk                         last     511  avgt
4  186.639 ?   4.258  ns/op
AsciiEncodeBenchmark.jdk                         last    2087  avgt
4  725.196 ? 149.416  ns/op
AsciiEncodeBenchmark.longCheckCopy               none       3  avgt
4    7.222 ?   0.428  ns/op
AsciiEncodeBenchmark.longCheckCopy               none      10  avgt
4    8.070 ?   0.171  ns/op
AsciiEncodeBenchmark.longCheckCopy               none      16  avgt
4    6.711 ?   0.409  ns/op
AsciiEncodeBenchmark.longCheckCopy               none      23  avgt
4   12.906 ?   3.633  ns/op
AsciiEncodeBenchmark.longCheckCopy               none      33  avgt
4   10.414 ?   0.447  ns/op
AsciiEncodeBenchmark.longCheckCopy               none      42  avgt
4   11.935 ?   1.235  ns/op
AsciiEncodeBenchmark.longCheckCopy               none     201  avgt
4   29.538 ?   3.265  ns/op
AsciiEncodeBenchmark.longCheckCopy               none     511  avgt
4  106.228 ?  68.475  ns/op
AsciiEncodeBenchmark.longCheckCopy               none    2087  avgt
4  494.845 ? 890.985  ns/op
AsciiEncodeBenchmark.longCheckCopy              first       3  avgt
4    7.775 ?   0.278  ns/op
AsciiEncodeBenchmark.longCheckCopy              first      10  avgt
4   13.396 ?   2.072  ns/op
AsciiEncodeBenchmark.longCheckCopy              first      16  avgt
4   13.528 ?   0.702  ns/op
AsciiEncodeBenchmark.longCheckCopy              first      23  avgt
4   17.376 ?   0.360  ns/op
AsciiEncodeBenchmark.longCheckCopy              first      33  avgt
4   16.251 ?   0.203  ns/op
AsciiEncodeBenchmark.longCheckCopy              first      42  avgt
4   17.932 ?   1.773  ns/op
AsciiEncodeBenchmark.longCheckCopy              first     201  avgt
4   39.028 ?   4.699  ns/op
AsciiEncodeBenchmark.longCheckCopy              first     511  avgt
4   92.599 ?  11.078  ns/op
AsciiEncodeBenchmark.longCheckCopy              first    2087  avgt
4  347.728 ?   7.837  ns/op
AsciiEncodeBenchmark.longCheckCopy               last       3  avgt
4    7.472 ?   0.078  ns/op
AsciiEncodeBenchmark.longCheckCopy               last      10  avgt
4    8.371 ?   0.815  ns/op
AsciiEncodeBenchmark.longCheckCopy               last      16  avgt
4    6.766 ?   0.253  ns/op
AsciiEncodeBenchmark.longCheckCopy               last      23  avgt
4   12.879 ?   0.454  ns/op
AsciiEncodeBenchmark.longCheckCopy               last      33  avgt
4   10.491 ?   0.811  ns/op
AsciiEncodeBenchmark.longCheckCopy               last      42  avgt
4   12.435 ?   1.212  ns/op
AsciiEncodeBenchmark.longCheckCopy               last     201  avgt
4   28.507 ?   1.058  ns/op
AsciiEncodeBenchmark.longCheckCopy               last     511  avgt
4   85.763 ?   1.941  ns/op
AsciiEncodeBenchmark.longCheckCopy               last    2087  avgt
4  411.555 ?   3.595  ns/op
AsciiEncodeBenchmark.longCheckCopy_unroll        none       3  avgt
4    5.858 ?   0.637  ns/op
AsciiEncodeBenchmark.longCheckCopy_unroll        none      10  avgt
4    7.031 ?   0.274  ns/op
AsciiEncodeBenchmark.longCheckCopy_unroll        none      16  avgt
4    6.768 ?   0.222  ns/op
AsciiEncodeBenchmark.longCheckCopy_unroll        none      23  avgt
4   10.084 ?   0.102  ns/op
AsciiEncodeBenchmark.longCheckCopy_unroll        none      33  avgt
4    9.876 ?   0.240  ns/op
AsciiEncodeBenchmark.longCheckCopy_unroll        none      42  avgt
4   11.061 ?   0.590  ns/op
AsciiEncodeBenchmark.longCheckCopy_unroll        none     201  avgt
4   29.264 ?   1.690  ns/op
AsciiEncodeBenchmark.longCheckCopy_unroll        none     511  avgt
4   61.920 ?   5.482  ns/op
AsciiEncodeBenchmark.longCheckCopy_unroll        none    2087  avgt
4  309.183 ?  42.354  ns/op
AsciiEncodeBenchmark.longCheckCopy_unroll       first       3  avgt
4    5.687 ?   0.249  ns/op
AsciiEncodeBenchmark.longCheckCopy_unroll       first      10  avgt
4    9.537 ?   0.337  ns/op
AsciiEncodeBenchmark.longCheckCopy_unroll       first      16  avgt
4    9.928 ?   0.329  ns/op
AsciiEncodeBenchmark.longCheckCopy_unroll       first      23  avgt
4   12.510 ?   0.519  ns/op
AsciiEncodeBenchmark.longCheckCopy_unroll       first      33  avgt
4   13.028 ?   0.335  ns/op
AsciiEncodeBenchmark.longCheckCopy_unroll       first      42  avgt
4   13.640 ?   0.219  ns/op
AsciiEncodeBenchmark.longCheckCopy_unroll       first     201  avgt
4   31.046 ?   0.647  ns/op
AsciiEncodeBenchmark.longCheckCopy_unroll       first     511  avgt
4   82.998 ?   5.611  ns/op
AsciiEncodeBenchmark.longCheckCopy_unroll       first    2087  avgt
4  360.294 ?   8.419  ns/op
AsciiEncodeBenchmark.longCheckCopy_unroll        last       3  avgt
4    5.657 ?   0.197  ns/op
AsciiEncodeBenchmark.longCheckCopy_unroll        last      10  avgt
4    6.997 ?   0.081  ns/op
AsciiEncodeBenchmark.longCheckCopy_unroll        last      16  avgt
4    6.890 ?   1.319  ns/op
AsciiEncodeBenchmark.longCheckCopy_unroll        last      23  avgt
4   10.154 ?   0.389  ns/op
AsciiEncodeBenchmark.longCheckCopy_unroll        last      33  avgt
4    9.986 ?   0.592  ns/op
AsciiEncodeBenchmark.longCheckCopy_unroll        last      42  avgt
4   11.481 ?   0.375  ns/op
AsciiEncodeBenchmark.longCheckCopy_unroll        last     201  avgt
4   29.286 ?   0.723  ns/op
AsciiEncodeBenchmark.longCheckCopy_unroll        last     511  avgt
4   61.056 ?   0.977  ns/op
AsciiEncodeBenchmark.longCheckCopy_unroll        last    2087  avgt
4  303.415 ?  17.326  ns/op



    @Benchmark
    public byte[] jdk() {
        final byte[] val = this.data;
        byte[] dst = Arrays.copyOf(val, val.length);
        for (int i = 0; i < dst.length; i++) {
            if (dst[i] < 0) {
                dst[i] = '?';
            }
        }
        return dst;
    }

    @Benchmark
    public byte[] longCheckCopy() {
        final byte[] val = this.data;
        byte[] dst = new byte[val.length];
        int i = 0;
        long word;
        for (int j=dst.length - 7; i < j; i+=8) {
            word = (long)LONG_BYTES.get(val, i);
            LONG_BYTES.set(dst, i, word);
            if ((word & LONG_NEG_MASK) != 0) {
                for (int x=i, y=i+8; x<y; x++) {
                    if (dst[x] < 0) {
                        dst[x] = '?';
                    }
                }
            }
        }
        byte b;
        for (; i < dst.length; i++) {
            b = val[i];
            dst[i] = b < 0 ? (byte) '?' : b;
        }
        return dst;
    }

    @Benchmark
    public byte[] longCheckCopy_unroll() {
        final byte[] val = this.data;
        byte[] dst = new byte[val.length];
        int i = 0;
        long word;
        for (int j=dst.length - 7; i < j; i+=8) {
            word = (long)LONG_BYTES.get(val, i);
            LONG_BYTES.set(dst, i, word);
            if ((word & LONG_NEG_MASK) != 0) {
                if (dst[i] < 0) {
                    dst[i] = '?';
                }
                if (dst[i + 1] < 0) {
                    dst[i + 1] = '?';
                }
                if (dst[i + 2] < 0) {
                    dst[i + 2] = '?';
                }
                if (dst[i + 3] < 0) {
                    dst[i + 3] = '?';
                }
                if (dst[i + 4] < 0) {
                    dst[i + 4] = '?';
                }
                if (dst[i + 5] < 0) {
                    dst[i + 5] = '?';
                }
                if (dst[i + 6] < 0) {
                    dst[i + 6] = '?';
                }
                if (dst[i + 7] < 0) {
                    dst[i + 7] = '?';
                }
            }
        }
        byte b;
        switch (dst.length & 0x7) {
            case 7:
                b = val[i + 6];
                dst[i + 6] = b < 0 ? (byte) '?' : b;
            case 6:
                b = val[i + 5];
                dst[i + 5] = b < 0 ? (byte) '?' : b;
            case 5:
                b = val[i + 4];
                dst[i + 4] = b < 0 ? (byte) '?' : b;
            case 4:
                b = val[i + 3];
                dst[i + 3] = b < 0 ? (byte) '?' : b;
            case 3:
                b = val[i + 2];
                dst[i + 2] = b < 0 ? (byte) '?' : b;
            case 2:
                b = val[i + 1];
                dst[i + 1] = b < 0 ? (byte) '?' : b;
            case 1:
                b = val[i];
                dst[i] = b < 0 ? (byte) '?' : b;
        }
        return dst;
    }


Thanks,

Brett

From eirbjo at gmail.com  Sat Feb 18 18:58:54 2023
From: eirbjo at gmail.com (=?UTF-8?B?RWlyaWsgQmrDuHJzbsO4cw==?=)
Date: Sat, 18 Feb 2023 19:58:54 +0100
Subject: Speed up StringLatin1.regionMatchesCI_UTF16
Message-ID: <CA+pBWhtYAn0o4AXYyseurZnCo579YFj7CEQ=YgqBHwqqRLXBQA@mail.gmail.com>

Hi,

This PR continues the effort to speed up case-insensitive string
comparisons, this time tackling comparison of latin1-coded strings with
utf16-coded strings:

https://github.com/openjdk/jdk/pull/12637

This builds on top of #12632, it makes sense to review that one first.

Thanks,
Eirik.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20230218/35468aaf/attachment.htm>

From briangoetz at openjdk.org  Sat Feb 18 19:16:24 2023
From: briangoetz at openjdk.org (Brian Goetz)
Date: Sat, 18 Feb 2023 19:16:24 GMT
Subject: RFR: 8292914: Drop the counter from lambda class names [v6]
In-Reply-To: <QmD1r95Ztib9LqUzkJa6MBeZvgR95EXWBIpsgQt38qg=.7c466759-3ce1-4aa1-b2b4-571cad5c70d3@github.com>
References: <GgLfH-ueBQqT-Mfk1mKpKFAt8fYqyjfVJ9lmlsBsCbo=.8dd5b3b4-4e84-4970-9179-1c0399b30edc@github.com>
 <zlDm2W50G6NgRkzmgEpX6MTVs3XyYMnY3tN1YnObWUA=.03a3d8d7-4d20-4fc6-8028-b20a8603b0a6@github.com>
 <QmD1r95Ztib9LqUzkJa6MBeZvgR95EXWBIpsgQt38qg=.7c466759-3ce1-4aa1-b2b4-571cad5c70d3@github.com>
Message-ID: <e903pJUoWUVjHOglJrPmrJYsZyvz2nN8IG21JH8HF6I=.e2e1022a-7887-4313-bd90-1b7d32098d36@github.com>

On Fri, 17 Feb 2023 02:11:10 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> David M. Lloyd has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Use a unique index for the dumped lambda class instead of a time stamp
>
> `this_class` in the classbyte is shown in the VM logging (`-Xlog:class+nestmates=debug`).  It'd be helpful if it can easily correlate to the dumped file.   For example, 3 lambda proxy classes of the same name of `this_class` but they are unique hidden classes.
> 
> 
> 0.058s][info ][class,nestmates] LookupDefineClass: jdk/internal/module/DefaultRoots$$Lambda$ - with dynamic nest-host jdk.internal.module.DefaultRoots, hidden, strong, with vm annotations
> [0.058s][debug][class,nestmates] Dynamic nestmate: java.base/jdk.internal.module.DefaultRoots$$Lambda$/0x000000080000a970, nest_host jdk.internal.module.DefaultRoots, is hidden
> [0.062s][info ][class,nestmates] LookupDefineClass: jdk/internal/module/DefaultRoots$$Lambda$ - with dynamic nest-host jdk.internal.module.DefaultRoots, hidden, strong, with vm annotations
> [0.062s][debug][class,nestmates] Dynamic nestmate: java.base/jdk.internal.module.DefaultRoots$$Lambda$/0x000000080000b998, nest_host jdk.internal.module.DefaultRoots, is hidden
> [0.068s][info ][class,nestmates] LookupDefineClass: jdk/internal/module/DefaultRoots$$Lambda$ - with dynamic nest-host jdk.internal.module.DefaultRoots, hidden, strong, with vm annotations
> [0.068s][debug][class,nestmates] Dynamic nestmate: java.base/jdk.internal.module.DefaultRoots$$Lambda$/0x000000080000c0b0, nest_host jdk.internal.module.DefaultRoots, is hidden
> 
> 
> What about keeping your original idea - the filename matching the hidden class name if successfully defined.   If it fails at `defineHiddenClass` time, use `lambdaClassName` + counter? 
> 
> Also, `test/jdk/java/lang/StackWalker/VerifyStackTrace.java` tests need update because of the lambda proxy class name change.

This looks pretty reasonable to me.  As long as @mlchung and @iklam are happy, no objections from me.

-------------

PR: https://git.openjdk.org/jdk/pull/12579

From tvaleev at openjdk.org  Sat Feb 18 21:40:08 2023
From: tvaleev at openjdk.org (Tagir F. Valeev)
Date: Sat, 18 Feb 2023 21:40:08 GMT
Subject: RFR: 8302815 Use new Math.clamp method in core libraries [v2]
In-Reply-To: <k_xjmup3YSdUre0Z_XpO-WEBb5XED2FYv8UUZT2ULwc=.86f53f51-cceb-45fd-935d-b054c79a0526@github.com>
References: <k_xjmup3YSdUre0Z_XpO-WEBb5XED2FYv8UUZT2ULwc=.86f53f51-cceb-45fd-935d-b054c79a0526@github.com>
Message-ID: <V5pROUz9W7-O5FDi8LQ9dgWzsiJKfl9Y9xi_VmYvT4A=.9835b9b3-aeb5-484b-ac57-74d1071ed9da@github.com>

> For cleanup and dogfooding the new method, it would be nice to use Math.clamp where possible in java.base. See PR #12428.
> 
> As Math.clamp performs an additional check that min is not greater than max, I conservatively replaced only those occurrences where I can see that this invariant is always held. There are more occurrences, where clamp can be potentially used but it's unclear whether min <= max is always true.

Tagir F. Valeev has updated the pull request incrementally with one additional commit since the last revision:

  Revert changes in JrtPath, as it seems to be compiled with bootstrap JDK

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12633/files
  - new: https://git.openjdk.org/jdk/pull/12633/files/3f3618ae..be13683b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12633&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12633&range=00-01

  Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/12633.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12633/head:pull/12633

PR: https://git.openjdk.org/jdk/pull/12633

From duke at openjdk.org  Sat Feb 18 22:02:32 2023
From: duke at openjdk.org (Chris Hennick)
Date: Sat, 18 Feb 2023 22:02:32 GMT
Subject: RFR: 8284493: Improve computeNextExponential tail performance and
 accuracy [v16]
In-Reply-To: <GKQOg02og11alcCgOGPGZ2wn41zf6g5RylUm74Glr_k=.e5ad1226-a6ee-412f-8508-08946ef11eae@github.com>
References: <3gh4M864NnJhhWbV7CAj6HcmxGnf8SWTC2Q-uqhGe98=.209577f8-d69e-4794-944f-4379beecf2f7@github.com>
 <GKQOg02og11alcCgOGPGZ2wn41zf6g5RylUm74Glr_k=.e5ad1226-a6ee-412f-8508-08946ef11eae@github.com>
Message-ID: <5cSVNv65TBLN0nZlwnXRqpCyMe1UDJshp3D9ikqoTWY=.680f7565-6a3a-484e-a620-efbdd4f5cf24@github.com>

On Tue, 4 Oct 2022 17:36:56 GMT, Chris Hennick <duke at openjdk.org> wrote:

>> This PR improves both the worst-case performance of `nextExponential` and `nextGaussian` and the distribution of output at the tails. It fixes the following imperfections:
>> 
>> * Repeatedly adding DoubleZigguratTables.exponentialX0 to extra causes a rounding error to accumulate at the tail of the distribution (probably starting around `2*exponentialX0 == 0x1.e46eff20739afp3 ~ 15.1`); this PR fixes that by tracking the multiple of exponentialX0 as a long. (This distortion is worst when `x > 0x1.0p56` since in that case, a rounding error means `extra + x == extra`.
>> * Reduces several equations using `Math.fma`. (This will almost certainly improve performance, and may or may not improve output distribution.)
>> * Uses the newly-extracted `computeWinsorizedNextExponential` function to prevent `nextGaussian` from going into the `nextExponential` tail twice.
>
> Chris Hennick has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add parameter to enable/disable fixed PRNG seed

Keep open @JimLaskey @jddarcy

-------------

PR: https://git.openjdk.org/jdk/pull/8131

From claes.redestad at oracle.com  Sat Feb 18 23:49:21 2023
From: claes.redestad at oracle.com (Claes Redestad)
Date: Sat, 18 Feb 2023 23:49:21 +0000
Subject: String encodeASCII
In-Reply-To: <CANBJVOF1CAeOw99A6WFxJc60VOdDCctKxo5RKYtJA_2WUBchjg@mail.gmail.com>
References: <CANBJVOF1CAeOw99A6WFxJc60VOdDCctKxo5RKYtJA_2WUBchjg@mail.gmail.com>
Message-ID: <4FB46DE3-D300-4928-9F8D-F0B7E112AF97@oracle.com>

Hi,

general comment: String might be one of the trickier places to add a VarHandle dependency, since String is used very early in the bootstrap and depended upon by everything else, so I?d expect such a solution would have to navigate potential circularity issues carefully. It?d be good to experiment with changes to java.lang.String proper to see that the solution that works nice externally is or can be made feasible within String.

Specifically on the performance opportunity then while US-ASCII encoding is probably on the way out we shouldn?t neglect it.

One way to go about this without pulling VarHandles into String might be to use what other encode methods in String does and leverage StringCoding.countPositives:

https://github.com/openjdk/jdk/pull/12640

Testing this on the existing StringEncode microbenchmark, shows a promising speed-up when the input is ASCII-encodable:

Baseline
Benchmark                      (charsetName)  Mode  Cnt      Score     Error  Units
StringEncode.encodeAsciiLong        US-ASCII  avgt    5  26626,025 ? 448,307  ns/op
StringEncode.encodeAsciiShort       US-ASCII  avgt    5     33,336 ?   2,032  ns/op

Patch:
Benchmark                      (charsetName)  Mode  Cnt     Score    Error  Units
StringEncode.encodeAsciiLong        US-ASCII  avgt    5  5492,985 ? 40,066  ns/op
StringEncode.encodeAsciiShort       US-ASCII  avgt    5    28,545 ?  4,883  ns/op

(You might see that this will go back into a scalar loop on encoding failures. That loop could still benefit from unrolling or byteArrayViewVarHandle, but I think you have a bigger problem in an app than raw performance if you have a lot of encoding failures...)

WDYT?

/Claes

18 feb. 2023 kl. 19:36 skrev Brett Okken <brett.okken.os at gmail.com<mailto:brett.okken.os at gmail.com>>:

https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/lang/String.java#L976-L981

For String.encodeASCII, with the LATIN1 coder is there any interest in
exploring the performance impacts of utilizing a
byteArrayViewVarHandle to read/write as longs and utilize a bitmask to
identify if negative values are present?

A simple jmh benchmark covering either 0 or 1 non-ascii (negative)
values shows times cut in half (or more) for most scenarios with
strings ranging in length from 3 - ~2000.
VM version: JDK 17.0.6, OpenJDK 64-Bit Server VM, 17.0.6+10
Windows 10 Intel(R) Core(TM) i7-9850H

Hand unrolling the loops shows noted improvement, but does make for
less aesthetically pleasing code.


Benchmark                                  (nonascii)  (size)  Mode
Cnt    Score     Error  Units
AsciiEncodeBenchmark.jdk                         none       3  avgt
4   15.531 ?   1.122  ns/op
AsciiEncodeBenchmark.jdk                         none      10  avgt
4   17.350 ?   0.473  ns/op
AsciiEncodeBenchmark.jdk                         none      16  avgt
4   18.277 ?   0.421  ns/op
AsciiEncodeBenchmark.jdk                         none      23  avgt
4   20.139 ?   0.350  ns/op
AsciiEncodeBenchmark.jdk                         none      33  avgt
4   22.008 ?   0.656  ns/op
AsciiEncodeBenchmark.jdk                         none      42  avgt
4   24.393 ?   1.155  ns/op
AsciiEncodeBenchmark.jdk                         none     201  avgt
4   55.884 ?   0.645  ns/op
AsciiEncodeBenchmark.jdk                         none     511  avgt
4  120.817 ?   2.917  ns/op
AsciiEncodeBenchmark.jdk                         none    2087  avgt
4  471.039 ?  13.329  ns/op
AsciiEncodeBenchmark.jdk                        first       3  avgt
4   15.794 ?   1.494  ns/op
AsciiEncodeBenchmark.jdk                        first      10  avgt
4   18.446 ?   0.780  ns/op
AsciiEncodeBenchmark.jdk                        first      16  avgt
4   20.458 ?   0.394  ns/op
AsciiEncodeBenchmark.jdk                        first      23  avgt
4   22.934 ?   0.422  ns/op
AsciiEncodeBenchmark.jdk                        first      33  avgt
4   25.367 ?   0.178  ns/op
AsciiEncodeBenchmark.jdk                        first      42  avgt
4   28.620 ?   0.678  ns/op
AsciiEncodeBenchmark.jdk                        first     201  avgt
4   80.250 ?   4.376  ns/op
AsciiEncodeBenchmark.jdk                        first     511  avgt
4  185.518 ?   6.370  ns/op
AsciiEncodeBenchmark.jdk                        first    2087  avgt
4  713.213 ?  13.488  ns/op
AsciiEncodeBenchmark.jdk                         last       3  avgt
4   14.991 ?   0.190  ns/op
AsciiEncodeBenchmark.jdk                         last      10  avgt
4   18.284 ?   0.317  ns/op
AsciiEncodeBenchmark.jdk                         last      16  avgt
4   20.591 ?   1.002  ns/op
AsciiEncodeBenchmark.jdk                         last      23  avgt
4   22.560 ?   0.963  ns/op
AsciiEncodeBenchmark.jdk                         last      33  avgt
4   25.521 ?   0.554  ns/op
AsciiEncodeBenchmark.jdk                         last      42  avgt
4   28.484 ?   0.446  ns/op
AsciiEncodeBenchmark.jdk                         last     201  avgt
4   79.434 ?   2.256  ns/op
AsciiEncodeBenchmark.jdk                         last     511  avgt
4  186.639 ?   4.258  ns/op
AsciiEncodeBenchmark.jdk                         last    2087  avgt
4  725.196 ? 149.416  ns/op
AsciiEncodeBenchmark.longCheckCopy               none       3  avgt
4    7.222 ?   0.428  ns/op
AsciiEncodeBenchmark.longCheckCopy               none      10  avgt
4    8.070 ?   0.171  ns/op
AsciiEncodeBenchmark.longCheckCopy               none      16  avgt
4    6.711 ?   0.409  ns/op
AsciiEncodeBenchmark.longCheckCopy               none      23  avgt
4   12.906 ?   3.633  ns/op
AsciiEncodeBenchmark.longCheckCopy               none      33  avgt
4   10.414 ?   0.447  ns/op
AsciiEncodeBenchmark.longCheckCopy               none      42  avgt
4   11.935 ?   1.235  ns/op
AsciiEncodeBenchmark.longCheckCopy               none     201  avgt
4   29.538 ?   3.265  ns/op
AsciiEncodeBenchmark.longCheckCopy               none     511  avgt
4  106.228 ?  68.475  ns/op
AsciiEncodeBenchmark.longCheckCopy               none    2087  avgt
4  494.845 ? 890.985  ns/op
AsciiEncodeBenchmark.longCheckCopy              first       3  avgt
4    7.775 ?   0.278  ns/op
AsciiEncodeBenchmark.longCheckCopy              first      10  avgt
4   13.396 ?   2.072  ns/op
AsciiEncodeBenchmark.longCheckCopy              first      16  avgt
4   13.528 ?   0.702  ns/op
AsciiEncodeBenchmark.longCheckCopy              first      23  avgt
4   17.376 ?   0.360  ns/op
AsciiEncodeBenchmark.longCheckCopy              first      33  avgt
4   16.251 ?   0.203  ns/op
AsciiEncodeBenchmark.longCheckCopy              first      42  avgt
4   17.932 ?   1.773  ns/op
AsciiEncodeBenchmark.longCheckCopy              first     201  avgt
4   39.028 ?   4.699  ns/op
AsciiEncodeBenchmark.longCheckCopy              first     511  avgt
4   92.599 ?  11.078  ns/op
AsciiEncodeBenchmark.longCheckCopy              first    2087  avgt
4  347.728 ?   7.837  ns/op
AsciiEncodeBenchmark.longCheckCopy               last       3  avgt
4    7.472 ?   0.078  ns/op
AsciiEncodeBenchmark.longCheckCopy               last      10  avgt
4    8.371 ?   0.815  ns/op
AsciiEncodeBenchmark.longCheckCopy               last      16  avgt
4    6.766 ?   0.253  ns/op
AsciiEncodeBenchmark.longCheckCopy               last      23  avgt
4   12.879 ?   0.454  ns/op
AsciiEncodeBenchmark.longCheckCopy               last      33  avgt
4   10.491 ?   0.811  ns/op
AsciiEncodeBenchmark.longCheckCopy               last      42  avgt
4   12.435 ?   1.212  ns/op
AsciiEncodeBenchmark.longCheckCopy               last     201  avgt
4   28.507 ?   1.058  ns/op
AsciiEncodeBenchmark.longCheckCopy               last     511  avgt
4   85.763 ?   1.941  ns/op
AsciiEncodeBenchmark.longCheckCopy               last    2087  avgt
4  411.555 ?   3.595  ns/op
AsciiEncodeBenchmark.longCheckCopy_unroll        none       3  avgt
4    5.858 ?   0.637  ns/op
AsciiEncodeBenchmark.longCheckCopy_unroll        none      10  avgt
4    7.031 ?   0.274  ns/op
AsciiEncodeBenchmark.longCheckCopy_unroll        none      16  avgt
4    6.768 ?   0.222  ns/op
AsciiEncodeBenchmark.longCheckCopy_unroll        none      23  avgt
4   10.084 ?   0.102  ns/op
AsciiEncodeBenchmark.longCheckCopy_unroll        none      33  avgt
4    9.876 ?   0.240  ns/op
AsciiEncodeBenchmark.longCheckCopy_unroll        none      42  avgt
4   11.061 ?   0.590  ns/op
AsciiEncodeBenchmark.longCheckCopy_unroll        none     201  avgt
4   29.264 ?   1.690  ns/op
AsciiEncodeBenchmark.longCheckCopy_unroll        none     511  avgt
4   61.920 ?   5.482  ns/op
AsciiEncodeBenchmark.longCheckCopy_unroll        none    2087  avgt
4  309.183 ?  42.354  ns/op
AsciiEncodeBenchmark.longCheckCopy_unroll       first       3  avgt
4    5.687 ?   0.249  ns/op
AsciiEncodeBenchmark.longCheckCopy_unroll       first      10  avgt
4    9.537 ?   0.337  ns/op
AsciiEncodeBenchmark.longCheckCopy_unroll       first      16  avgt
4    9.928 ?   0.329  ns/op
AsciiEncodeBenchmark.longCheckCopy_unroll       first      23  avgt
4   12.510 ?   0.519  ns/op
AsciiEncodeBenchmark.longCheckCopy_unroll       first      33  avgt
4   13.028 ?   0.335  ns/op
AsciiEncodeBenchmark.longCheckCopy_unroll       first      42  avgt
4   13.640 ?   0.219  ns/op
AsciiEncodeBenchmark.longCheckCopy_unroll       first     201  avgt
4   31.046 ?   0.647  ns/op
AsciiEncodeBenchmark.longCheckCopy_unroll       first     511  avgt
4   82.998 ?   5.611  ns/op
AsciiEncodeBenchmark.longCheckCopy_unroll       first    2087  avgt
4  360.294 ?   8.419  ns/op
AsciiEncodeBenchmark.longCheckCopy_unroll        last       3  avgt
4    5.657 ?   0.197  ns/op
AsciiEncodeBenchmark.longCheckCopy_unroll        last      10  avgt
4    6.997 ?   0.081  ns/op
AsciiEncodeBenchmark.longCheckCopy_unroll        last      16  avgt
4    6.890 ?   1.319  ns/op
AsciiEncodeBenchmark.longCheckCopy_unroll        last      23  avgt
4   10.154 ?   0.389  ns/op
AsciiEncodeBenchmark.longCheckCopy_unroll        last      33  avgt
4    9.986 ?   0.592  ns/op
AsciiEncodeBenchmark.longCheckCopy_unroll        last      42  avgt
4   11.481 ?   0.375  ns/op
AsciiEncodeBenchmark.longCheckCopy_unroll        last     201  avgt
4   29.286 ?   0.723  ns/op
AsciiEncodeBenchmark.longCheckCopy_unroll        last     511  avgt
4   61.056 ?   0.977  ns/op
AsciiEncodeBenchmark.longCheckCopy_unroll        last    2087  avgt
4  303.415 ?  17.326  ns/op



   @Benchmark
   public byte[] jdk() {
       final byte[] val = this.data;
       byte[] dst = Arrays.copyOf(val, val.length);
       for (int i = 0; i < dst.length; i++) {
           if (dst[i] < 0) {
               dst[i] = '?';
           }
       }
       return dst;
   }

   @Benchmark
   public byte[] longCheckCopy() {
       final byte[] val = this.data;
       byte[] dst = new byte[val.length];
       int i = 0;
       long word;
       for (int j=dst.length - 7; i < j; i+=8) {
           word = (long)LONG_BYTES.get(val, i);
           LONG_BYTES.set(dst, i, word);
           if ((word & LONG_NEG_MASK) != 0) {
               for (int x=i, y=i+8; x<y; x++) {
                   if (dst[x] < 0) {
                       dst[x] = '?';
                   }
               }
           }
       }
       byte b;
       for (; i < dst.length; i++) {
           b = val[i];
           dst[i] = b < 0 ? (byte) '?' : b;
       }
       return dst;
   }

   @Benchmark
   public byte[] longCheckCopy_unroll() {
       final byte[] val = this.data;
       byte[] dst = new byte[val.length];
       int i = 0;
       long word;
       for (int j=dst.length - 7; i < j; i+=8) {
           word = (long)LONG_BYTES.get(val, i);
           LONG_BYTES.set(dst, i, word);
           if ((word & LONG_NEG_MASK) != 0) {
               if (dst[i] < 0) {
                   dst[i] = '?';
               }
               if (dst[i + 1] < 0) {
                   dst[i + 1] = '?';
               }
               if (dst[i + 2] < 0) {
                   dst[i + 2] = '?';
               }
               if (dst[i + 3] < 0) {
                   dst[i + 3] = '?';
               }
               if (dst[i + 4] < 0) {
                   dst[i + 4] = '?';
               }
               if (dst[i + 5] < 0) {
                   dst[i + 5] = '?';
               }
               if (dst[i + 6] < 0) {
                   dst[i + 6] = '?';
               }
               if (dst[i + 7] < 0) {
                   dst[i + 7] = '?';
               }
           }
       }
       byte b;
       switch (dst.length & 0x7) {
           case 7:
               b = val[i + 6];
               dst[i + 6] = b < 0 ? (byte) '?' : b;
           case 6:
               b = val[i + 5];
               dst[i + 5] = b < 0 ? (byte) '?' : b;
           case 5:
               b = val[i + 4];
               dst[i + 4] = b < 0 ? (byte) '?' : b;
           case 4:
               b = val[i + 3];
               dst[i + 3] = b < 0 ? (byte) '?' : b;
           case 3:
               b = val[i + 2];
               dst[i + 2] = b < 0 ? (byte) '?' : b;
           case 2:
               b = val[i + 1];
               dst[i + 1] = b < 0 ? (byte) '?' : b;
           case 1:
               b = val[i];
               dst[i] = b < 0 ? (byte) '?' : b;
       }
       return dst;
   }


Thanks,

Brett

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20230218/84378fee/attachment-0001.htm>

From brett.okken.os at gmail.com  Sun Feb 19 01:54:31 2023
From: brett.okken.os at gmail.com (Brett Okken)
Date: Sat, 18 Feb 2023 19:54:31 -0600
Subject: String encodeASCII
In-Reply-To: <4FB46DE3-D300-4928-9F8D-F0B7E112AF97@oracle.com>
References: <CANBJVOF1CAeOw99A6WFxJc60VOdDCctKxo5RKYtJA_2WUBchjg@mail.gmail.com>
 <4FB46DE3-D300-4928-9F8D-F0B7E112AF97@oracle.com>
Message-ID: <CANBJVOGfg3i9dE=WN6dAazGNBqRjeBYkmMnGKtZigdT+EiBQpw@mail.gmail.com>

Thanks for taking a look at this.
That is a pretty good improvement with a much smaller change.
I recognize the intricacies of bootstrapping, but have no expertise. Would
using Unsafe directly be easier? Particularly for shorter strings, doing
the copying and checking together rather than as separate loops seems to
speed things up considerably, even for happy-path of no failures.

Brett

On Sat, Feb 18, 2023 at 5:49 PM Claes Redestad <claes.redestad at oracle.com>
wrote:

> Hi,
>
> general comment: String might be one of the trickier places to add a
> VarHandle dependency, since String is used very early in the bootstrap and
> depended upon by everything else, so I?d expect such a solution would have
> to navigate potential circularity issues carefully. It?d be good to
> experiment with changes to java.lang.String proper to see that the solution
> that works nice externally is or can be made feasible within String.
>
> Specifically on the performance opportunity then while US-ASCII encoding
> is probably on the way out we shouldn?t neglect it.
>
> One way to go about this without pulling VarHandles into String might be
> to use what other encode methods in String does and leverage
> StringCoding.countPositives:
>
> https://github.com/openjdk/jdk/pull/12640
>
> Testing this on the existing StringEncode microbenchmark, shows a
> promising speed-up when the input is ASCII-encodable:
>
> Baseline
> Benchmark                      (charsetName)  Mode  Cnt      Score
> Error  Units
> StringEncode.encodeAsciiLong        US-ASCII  avgt    5  26626,025 ?
> 448,307  ns/op
> StringEncode.encodeAsciiShort       US-ASCII  avgt    5     33,336 ?
> 2,032  ns/op
>
> Patch:
> Benchmark                      (charsetName)  Mode  Cnt     Score    Error
>  Units
> StringEncode.encodeAsciiLong        US-ASCII  avgt    5  5492,985 ? 40,066
>  ns/op
> StringEncode.encodeAsciiShort       US-ASCII  avgt    5    28,545 ?  4,883
>  ns/op
>
> (You might see that this will go back into a scalar loop on encoding
> failures. That loop could still benefit from unrolling or
> byteArrayViewVarHandle, but I think you have a bigger problem in an app
> than raw performance if you have a lot of encoding failures...)
>
> WDYT?
>
> /Claes
>
> 18 feb. 2023 kl. 19:36 skrev Brett Okken <brett.okken.os at gmail.com>:
>
>
> https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/lang/String.java#L976-L981
>
> For String.encodeASCII, with the LATIN1 coder is there any interest in
> exploring the performance impacts of utilizing a
> byteArrayViewVarHandle to read/write as longs and utilize a bitmask to
> identify if negative values are present?
>
> A simple jmh benchmark covering either 0 or 1 non-ascii (negative)
> values shows times cut in half (or more) for most scenarios with
> strings ranging in length from 3 - ~2000.
> VM version: JDK 17.0.6, OpenJDK 64-Bit Server VM, 17.0.6+10
> Windows 10 Intel(R) Core(TM) i7-9850H
>
> Hand unrolling the loops shows noted improvement, but does make for
> less aesthetically pleasing code.
>
>
> Benchmark                                  (nonascii)  (size)  Mode
> Cnt    Score     Error  Units
> AsciiEncodeBenchmark.jdk                         none       3  avgt
> 4   15.531 ?   1.122  ns/op
> AsciiEncodeBenchmark.jdk                         none      10  avgt
> 4   17.350 ?   0.473  ns/op
> AsciiEncodeBenchmark.jdk                         none      16  avgt
> 4   18.277 ?   0.421  ns/op
> AsciiEncodeBenchmark.jdk                         none      23  avgt
> 4   20.139 ?   0.350  ns/op
> AsciiEncodeBenchmark.jdk                         none      33  avgt
> 4   22.008 ?   0.656  ns/op
> AsciiEncodeBenchmark.jdk                         none      42  avgt
> 4   24.393 ?   1.155  ns/op
> AsciiEncodeBenchmark.jdk                         none     201  avgt
> 4   55.884 ?   0.645  ns/op
> AsciiEncodeBenchmark.jdk                         none     511  avgt
> 4  120.817 ?   2.917  ns/op
> AsciiEncodeBenchmark.jdk                         none    2087  avgt
> 4  471.039 ?  13.329  ns/op
> AsciiEncodeBenchmark.jdk                        first       3  avgt
> 4   15.794 ?   1.494  ns/op
> AsciiEncodeBenchmark.jdk                        first      10  avgt
> 4   18.446 ?   0.780  ns/op
> AsciiEncodeBenchmark.jdk                        first      16  avgt
> 4   20.458 ?   0.394  ns/op
> AsciiEncodeBenchmark.jdk                        first      23  avgt
> 4   22.934 ?   0.422  ns/op
> AsciiEncodeBenchmark.jdk                        first      33  avgt
> 4   25.367 ?   0.178  ns/op
> AsciiEncodeBenchmark.jdk                        first      42  avgt
> 4   28.620 ?   0.678  ns/op
> AsciiEncodeBenchmark.jdk                        first     201  avgt
> 4   80.250 ?   4.376  ns/op
> AsciiEncodeBenchmark.jdk                        first     511  avgt
> 4  185.518 ?   6.370  ns/op
> AsciiEncodeBenchmark.jdk                        first    2087  avgt
> 4  713.213 ?  13.488  ns/op
> AsciiEncodeBenchmark.jdk                         last       3  avgt
> 4   14.991 ?   0.190  ns/op
> AsciiEncodeBenchmark.jdk                         last      10  avgt
> 4   18.284 ?   0.317  ns/op
> AsciiEncodeBenchmark.jdk                         last      16  avgt
> 4   20.591 ?   1.002  ns/op
> AsciiEncodeBenchmark.jdk                         last      23  avgt
> 4   22.560 ?   0.963  ns/op
> AsciiEncodeBenchmark.jdk                         last      33  avgt
> 4   25.521 ?   0.554  ns/op
> AsciiEncodeBenchmark.jdk                         last      42  avgt
> 4   28.484 ?   0.446  ns/op
> AsciiEncodeBenchmark.jdk                         last     201  avgt
> 4   79.434 ?   2.256  ns/op
> AsciiEncodeBenchmark.jdk                         last     511  avgt
> 4  186.639 ?   4.258  ns/op
> AsciiEncodeBenchmark.jdk                         last    2087  avgt
> 4  725.196 ? 149.416  ns/op
> AsciiEncodeBenchmark.longCheckCopy               none       3  avgt
> 4    7.222 ?   0.428  ns/op
> AsciiEncodeBenchmark.longCheckCopy               none      10  avgt
> 4    8.070 ?   0.171  ns/op
> AsciiEncodeBenchmark.longCheckCopy               none      16  avgt
> 4    6.711 ?   0.409  ns/op
> AsciiEncodeBenchmark.longCheckCopy               none      23  avgt
> 4   12.906 ?   3.633  ns/op
> AsciiEncodeBenchmark.longCheckCopy               none      33  avgt
> 4   10.414 ?   0.447  ns/op
> AsciiEncodeBenchmark.longCheckCopy               none      42  avgt
> 4   11.935 ?   1.235  ns/op
> AsciiEncodeBenchmark.longCheckCopy               none     201  avgt
> 4   29.538 ?   3.265  ns/op
> AsciiEncodeBenchmark.longCheckCopy               none     511  avgt
> 4  106.228 ?  68.475  ns/op
> AsciiEncodeBenchmark.longCheckCopy               none    2087  avgt
> 4  494.845 ? 890.985  ns/op
> AsciiEncodeBenchmark.longCheckCopy              first       3  avgt
> 4    7.775 ?   0.278  ns/op
> AsciiEncodeBenchmark.longCheckCopy              first      10  avgt
> 4   13.396 ?   2.072  ns/op
> AsciiEncodeBenchmark.longCheckCopy              first      16  avgt
> 4   13.528 ?   0.702  ns/op
> AsciiEncodeBenchmark.longCheckCopy              first      23  avgt
> 4   17.376 ?   0.360  ns/op
> AsciiEncodeBenchmark.longCheckCopy              first      33  avgt
> 4   16.251 ?   0.203  ns/op
> AsciiEncodeBenchmark.longCheckCopy              first      42  avgt
> 4   17.932 ?   1.773  ns/op
> AsciiEncodeBenchmark.longCheckCopy              first     201  avgt
> 4   39.028 ?   4.699  ns/op
> AsciiEncodeBenchmark.longCheckCopy              first     511  avgt
> 4   92.599 ?  11.078  ns/op
> AsciiEncodeBenchmark.longCheckCopy              first    2087  avgt
> 4  347.728 ?   7.837  ns/op
> AsciiEncodeBenchmark.longCheckCopy               last       3  avgt
> 4    7.472 ?   0.078  ns/op
> AsciiEncodeBenchmark.longCheckCopy               last      10  avgt
> 4    8.371 ?   0.815  ns/op
> AsciiEncodeBenchmark.longCheckCopy               last      16  avgt
> 4    6.766 ?   0.253  ns/op
> AsciiEncodeBenchmark.longCheckCopy               last      23  avgt
> 4   12.879 ?   0.454  ns/op
> AsciiEncodeBenchmark.longCheckCopy               last      33  avgt
> 4   10.491 ?   0.811  ns/op
> AsciiEncodeBenchmark.longCheckCopy               last      42  avgt
> 4   12.435 ?   1.212  ns/op
> AsciiEncodeBenchmark.longCheckCopy               last     201  avgt
> 4   28.507 ?   1.058  ns/op
> AsciiEncodeBenchmark.longCheckCopy               last     511  avgt
> 4   85.763 ?   1.941  ns/op
> AsciiEncodeBenchmark.longCheckCopy               last    2087  avgt
> 4  411.555 ?   3.595  ns/op
> AsciiEncodeBenchmark.longCheckCopy_unroll        none       3  avgt
> 4    5.858 ?   0.637  ns/op
> AsciiEncodeBenchmark.longCheckCopy_unroll        none      10  avgt
> 4    7.031 ?   0.274  ns/op
> AsciiEncodeBenchmark.longCheckCopy_unroll        none      16  avgt
> 4    6.768 ?   0.222  ns/op
> AsciiEncodeBenchmark.longCheckCopy_unroll        none      23  avgt
> 4   10.084 ?   0.102  ns/op
> AsciiEncodeBenchmark.longCheckCopy_unroll        none      33  avgt
> 4    9.876 ?   0.240  ns/op
> AsciiEncodeBenchmark.longCheckCopy_unroll        none      42  avgt
> 4   11.061 ?   0.590  ns/op
> AsciiEncodeBenchmark.longCheckCopy_unroll        none     201  avgt
> 4   29.264 ?   1.690  ns/op
> AsciiEncodeBenchmark.longCheckCopy_unroll        none     511  avgt
> 4   61.920 ?   5.482  ns/op
> AsciiEncodeBenchmark.longCheckCopy_unroll        none    2087  avgt
> 4  309.183 ?  42.354  ns/op
> AsciiEncodeBenchmark.longCheckCopy_unroll       first       3  avgt
> 4    5.687 ?   0.249  ns/op
> AsciiEncodeBenchmark.longCheckCopy_unroll       first      10  avgt
> 4    9.537 ?   0.337  ns/op
> AsciiEncodeBenchmark.longCheckCopy_unroll       first      16  avgt
> 4    9.928 ?   0.329  ns/op
> AsciiEncodeBenchmark.longCheckCopy_unroll       first      23  avgt
> 4   12.510 ?   0.519  ns/op
> AsciiEncodeBenchmark.longCheckCopy_unroll       first      33  avgt
> 4   13.028 ?   0.335  ns/op
> AsciiEncodeBenchmark.longCheckCopy_unroll       first      42  avgt
> 4   13.640 ?   0.219  ns/op
> AsciiEncodeBenchmark.longCheckCopy_unroll       first     201  avgt
> 4   31.046 ?   0.647  ns/op
> AsciiEncodeBenchmark.longCheckCopy_unroll       first     511  avgt
> 4   82.998 ?   5.611  ns/op
> AsciiEncodeBenchmark.longCheckCopy_unroll       first    2087  avgt
> 4  360.294 ?   8.419  ns/op
> AsciiEncodeBenchmark.longCheckCopy_unroll        last       3  avgt
> 4    5.657 ?   0.197  ns/op
> AsciiEncodeBenchmark.longCheckCopy_unroll        last      10  avgt
> 4    6.997 ?   0.081  ns/op
> AsciiEncodeBenchmark.longCheckCopy_unroll        last      16  avgt
> 4    6.890 ?   1.319  ns/op
> AsciiEncodeBenchmark.longCheckCopy_unroll        last      23  avgt
> 4   10.154 ?   0.389  ns/op
> AsciiEncodeBenchmark.longCheckCopy_unroll        last      33  avgt
> 4    9.986 ?   0.592  ns/op
> AsciiEncodeBenchmark.longCheckCopy_unroll        last      42  avgt
> 4   11.481 ?   0.375  ns/op
> AsciiEncodeBenchmark.longCheckCopy_unroll        last     201  avgt
> 4   29.286 ?   0.723  ns/op
> AsciiEncodeBenchmark.longCheckCopy_unroll        last     511  avgt
> 4   61.056 ?   0.977  ns/op
> AsciiEncodeBenchmark.longCheckCopy_unroll        last    2087  avgt
> 4  303.415 ?  17.326  ns/op
>
>
>
>    @Benchmark
>    public byte[] jdk() {
>        final byte[] val = this.data;
>        byte[] dst = Arrays.copyOf(val, val.length);
>        for (int i = 0; i < dst.length; i++) {
>            if (dst[i] < 0) {
>                dst[i] = '?';
>            }
>        }
>        return dst;
>    }
>
>    @Benchmark
>    public byte[] longCheckCopy() {
>        final byte[] val = this.data;
>        byte[] dst = new byte[val.length];
>        int i = 0;
>        long word;
>        for (int j=dst.length - 7; i < j; i+=8) {
>            word = (long)LONG_BYTES.get(val, i);
>            LONG_BYTES.set(dst, i, word);
>            if ((word & LONG_NEG_MASK) != 0) {
>                for (int x=i, y=i+8; x<y; x++) {
>                    if (dst[x] < 0) {
>                        dst[x] = '?';
>                    }
>                }
>            }
>        }
>        byte b;
>        for (; i < dst.length; i++) {
>            b = val[i];
>            dst[i] = b < 0 ? (byte) '?' : b;
>        }
>        return dst;
>    }
>
>    @Benchmark
>    public byte[] longCheckCopy_unroll() {
>        final byte[] val = this.data;
>        byte[] dst = new byte[val.length];
>        int i = 0;
>        long word;
>        for (int j=dst.length - 7; i < j; i+=8) {
>            word = (long)LONG_BYTES.get(val, i);
>            LONG_BYTES.set(dst, i, word);
>            if ((word & LONG_NEG_MASK) != 0) {
>                if (dst[i] < 0) {
>                    dst[i] = '?';
>                }
>                if (dst[i + 1] < 0) {
>                    dst[i + 1] = '?';
>                }
>                if (dst[i + 2] < 0) {
>                    dst[i + 2] = '?';
>                }
>                if (dst[i + 3] < 0) {
>                    dst[i + 3] = '?';
>                }
>                if (dst[i + 4] < 0) {
>                    dst[i + 4] = '?';
>                }
>                if (dst[i + 5] < 0) {
>                    dst[i + 5] = '?';
>                }
>                if (dst[i + 6] < 0) {
>                    dst[i + 6] = '?';
>                }
>                if (dst[i + 7] < 0) {
>                    dst[i + 7] = '?';
>                }
>            }
>        }
>        byte b;
>        switch (dst.length & 0x7) {
>            case 7:
>                b = val[i + 6];
>                dst[i + 6] = b < 0 ? (byte) '?' : b;
>            case 6:
>                b = val[i + 5];
>                dst[i + 5] = b < 0 ? (byte) '?' : b;
>            case 5:
>                b = val[i + 4];
>                dst[i + 4] = b < 0 ? (byte) '?' : b;
>            case 4:
>                b = val[i + 3];
>                dst[i + 3] = b < 0 ? (byte) '?' : b;
>            case 3:
>                b = val[i + 2];
>                dst[i + 2] = b < 0 ? (byte) '?' : b;
>            case 2:
>                b = val[i + 1];
>                dst[i + 1] = b < 0 ? (byte) '?' : b;
>            case 1:
>                b = val[i];
>                dst[i] = b < 0 ? (byte) '?' : b;
>        }
>        return dst;
>    }
>
>
> Thanks,
>
> Brett
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20230218/068598cf/attachment-0001.htm>

From alanb at openjdk.org  Sun Feb 19 08:57:22 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Sun, 19 Feb 2023 08:57:22 GMT
Subject: RFR: 8302815 Use new Math.clamp method in core libraries [v2]
In-Reply-To: <V5pROUz9W7-O5FDi8LQ9dgWzsiJKfl9Y9xi_VmYvT4A=.9835b9b3-aeb5-484b-ac57-74d1071ed9da@github.com>
References: <k_xjmup3YSdUre0Z_XpO-WEBb5XED2FYv8UUZT2ULwc=.86f53f51-cceb-45fd-935d-b054c79a0526@github.com>
 <V5pROUz9W7-O5FDi8LQ9dgWzsiJKfl9Y9xi_VmYvT4A=.9835b9b3-aeb5-484b-ac57-74d1071ed9da@github.com>
Message-ID: <p39HBUvKXHb3vPIiEF6yzjm9R0Ez9tRvqo7CDEHFQuk=.83b3b667-24af-426e-a59d-833e5e1a58ca@github.com>

On Sat, 18 Feb 2023 21:40:08 GMT, Tagir F. Valeev <tvaleev at openjdk.org> wrote:

> Revert changes in JrtPath, as it seems to be compiled with bootstrap JDK

Yes, the jrt file system provider is compiled --release 8 to create lib/jrt-fs.jar. That's the plumbing needed to allow IDEs/tools running on JDK 8 access the contents of a target run-time image as a file system.

-------------

PR: https://git.openjdk.org/jdk/pull/12633

From duke at openjdk.org  Sun Feb 19 18:49:06 2023
From: duke at openjdk.org (liach)
Date: Sun, 19 Feb 2023 18:49:06 GMT
Subject: RFR: 8302822:
 Method/Field/Constructor/RecordComponent::getGenericInfo() is not thread safe
Message-ID: <1sDlqlKVNOobyFy71f7ud5uL8_WcMPi1qKNa4ltxFQ0=.63cffbd7-e11a-4d7d-9362-cf215a7584ce@github.com>

8302822: Method/Field/Constructor/RecordComponent::getGenericInfo() is not thread safe

-------------

Commit messages:
 - 8302822: Method/Field/Constructor/RecordComponent::getGenericInfo() is not thread safe

Changes: https://git.openjdk.org/jdk/pull/12643/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12643&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8302822
  Stats: 12 lines in 4 files changed: 8 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/12643.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12643/head:pull/12643

PR: https://git.openjdk.org/jdk/pull/12643

From darcy at openjdk.org  Sun Feb 19 21:37:07 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Sun, 19 Feb 2023 21:37:07 GMT
Subject: RFR: JDK-8302800: Augment NaN handling tests of FDLIBM methods
Message-ID: <mc-_elojltkXx-TJQxeFKmIK6TELw_WBpwoSv7rdgEc=.9b3224a0-c9a0-475e-b7e8-86317d1ac04b@github.com>

Augment NaN-handling tests to include exotic NaN bit patterns. Assuming this changeset goes back first, I'll update https://github.com/openjdk/jdk/pull/12608 to follow the same convention afterward.

-------------

Commit messages:
 - JDK-8302800: Augment NaN handling tests of FDLIBM methods

Changes: https://git.openjdk.org/jdk/pull/12644/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12644&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8302800
  Stats: 198 lines in 7 files changed: 94 ins; 79 del; 25 mod
  Patch: https://git.openjdk.org/jdk/pull/12644.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12644/head:pull/12644

PR: https://git.openjdk.org/jdk/pull/12644

From duke at openjdk.org  Sun Feb 19 23:59:13 2023
From: duke at openjdk.org (Archie L. Cobbs)
Date: Sun, 19 Feb 2023 23:59:13 GMT
Subject: RFR: 8026369: javac potentially ambiguous overload warning needs an
 improved scheme
Message-ID: <IMxp3iCK--jYJ5Ia04i6QPYfnCHQobVcsmlI5aJXdqc=.892abcb8-7f2a-4fe9-aea2-1b1d41098a6d@github.com>

This bug relates to the "potentially ambiguous overload" warning which is enabled by `-Xlint:overloads`.

The warning detects certain ambiguities that can cause problems for lambdas. For example, consider the interface `Spliterator.OfInt`, which declares these two methods:

void forEachRemaining(Consumer<? super Integer> action);
void forEachRemaining(IntConsumer action);

Both methods have the same name, same number of parameters, and take a lambda with the same "shape" in the same argument position. This causes an ambiguity in any code that wants to do this:

    spliterator.forEachRemaining(x -> { ... });

That code won't compile; instead, you'll get this error:

Ambiguity.java:4: error: reference to forEachRemaining is ambiguous
        spliterator.forEachRemaining(x -> { });
                   ^
  both method forEachRemaining(IntConsumer) in OfInt and method forEachRemaining(Consumer<? super Integer>) in OfInt match


The problem reported by the bug is that the warning fails to detect ambiguities which are created purely by inheritance, for example:

interface ConsumerOfInteger {
    void foo(Consumer<Integer> c);
}

interface IntegerConsumer {
    void foo(IntConsumer c);
}

// We should get a warning here...
interface Test extends ConsumerOfInteger, IntegerConsumer {
}


The cause of the bug is that ambiguities are detected on a per-method basis, by checking whether a method is part of an ambiguity pair when we visit that method. So if the methods in an ambiguity pair are inherited from two distinct supertypes, we'll miss the ambiguity.

To fix the problem, we need to look for ambiguities on a per-class level, checking all pairs of methods. However, it's not that simple - we only want to "blame" a class when that class itself, and not some supertype, is responsible for creating the ambiguity. For example, any interface extending `Spliterator.OfInt` will automatically inherit the two ambiguities mentioned above, but these are not the interface's fault so to speak so no warning should be generated. Making things more complicated is the fact that methods can be overridden and declared in generic classes so they only conflict in some subtypes, etc.

So we generate the warning when there are two methods m1 and m2 in a class C such that:

* m1 and m2 consitiute a "potentially ambiguous overload" (using the same definition as before)
* There is no direct supertype T of C such that m1 and m2, or some methods they override, both exist in T and constitute a "potentially ambiguous overload" as members of T
* We haven't already generated a warning for either m1 or m2 in class C

If either method is declared in C, we locate the warning there, but when both methods are inherited, there's no method declaration to point at so the warning is instead located at the class declaration.

I noticed a couple of other minor bugs; these are also being fixed here:

(1) For inherited methods, the method signatures were being reported as they are declared, rather than in the context of the class being visited. As a result, when a methods is inherited from a generic supertype, the ambiguity is less clear. Here's an example:

interface Upper<T> {
    void foo(T c);
}

interface Lower extends Upper<IntConsumer> {
    void foo(Consumer<Integer> c);
}

Currently, the error is reported as:

warning: [overloads] foo(Consumer<Integer>) in Lower is potentially ambiguous with foo(T) in Upper

Reporting the method signatures in the context of the class being visited makes the ambiguity clearer:

warning: [overloads] foo(Consumer<Integer>) in Lower is potentially ambiguous with foo(IntConsumer) in Upper


(2) When a method is identified as part of an ambiguous pair, we were setting a `POTENTIALLY_AMBIGUOUS` flag on it. This caused it to be forever excluded from future warnings. For methods that are declared in the class we're visiting, this makes sense, but it doesn't make sense for inherited methods, because it disqualifies them from participating in the analysis of any other class that also inherits them.

As a result, for a class like the one below, the compiler was only generating one warning instead of three:

public interface SuperIface {
    void foo(Consumer<Integer> c);
}

public interface I1 extends SuperIface { 
    void foo(IntConsumer c);        // warning was generated here
}   

public interface I2 extends SuperIface { 
    void foo(IntConsumer c);        // no warning was generated here
}   

public interface I3 extends SuperIface { 
    void foo(IntConsumer c);        // no warning was generated here
}   


With this patch the `POTENTIALLY_AMBIGUOUS` flag is no longer needed. I wasn't sure whether to renumber all the subsequent flags, or just leave an empty placeholder, so I chose the latter.

Finally, this fix uncovers new warnings in `java.base` and `java.desktop`, so these are now suppressed in the patch.

-------------

Commit messages:
 - Fix incomplete detection of potentially ambiguous method declarations.

Changes: https://git.openjdk.org/jdk/pull/12645/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12645&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8026369
  Stats: 356 lines in 18 files changed: 280 ins; 36 del; 40 mod
  Patch: https://git.openjdk.org/jdk/pull/12645.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12645/head:pull/12645

PR: https://git.openjdk.org/jdk/pull/12645

From jwaters at openjdk.org  Mon Feb 20 07:38:25 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Mon, 20 Feb 2023 07:38:25 GMT
Subject: RFR: 8302667: Improve message format when failing to load symbols
 or libraries [v2]
In-Reply-To: <kZU8OxHl57JAzRBAtLeWjI-MfOnpKtjE0z32sUSHIX8=.aad0c2ef-434a-4a05-86fa-991486f74be1@github.com>
References: <tu4ol4DO1PeplhgjhkYpXLwES142ztBXsM43uQO_CNE=.bfca85a4-2323-487d-9261-964671e00bf3@github.com>
 <B-eIiBotI3cwCwWY5r2xYPlHfnV4dKJIHJdwg-hbDeQ=.ff83dbdf-e456-48b7-aa7f-e8cf75f71b5a@github.com>
 <kZU8OxHl57JAzRBAtLeWjI-MfOnpKtjE0z32sUSHIX8=.aad0c2ef-434a-4a05-86fa-991486f74be1@github.com>
Message-ID: <5yVAQiMfNMmuk5X_nunGuKCxSMdv5id1lv5grz9FhFw=.d76400d8-c35d-4286-a597-00bce215b157@github.com>

On Fri, 17 Feb 2023 17:05:59 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> Julian Waters 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 'openjdk:master' into patch-6
>>  - Error: Failed to load
>
> This change is fine.   
> 
> `expandArgFile` reports `DLL_ERROR4` when it fails to read `@arg-file` which is unrelated to shared libraries.   Would you mind also adding `ARG_ERROR18` to replace `DLL_ERROR4`?

> @mlchung No problem, what should I define `ARG_ERROR18` as?

@mlchung ?

-------------

PR: https://git.openjdk.org/jdk/pull/12596

From stsypanov at openjdk.org  Mon Feb 20 08:14:24 2023
From: stsypanov at openjdk.org (Sergey Tsypanov)
Date: Mon, 20 Feb 2023 08:14:24 GMT
Subject: RFR: 8302822:
 Method/Field/Constructor/RecordComponent::getGenericInfo() is not thread safe
In-Reply-To: <1sDlqlKVNOobyFy71f7ud5uL8_WcMPi1qKNa4ltxFQ0=.63cffbd7-e11a-4d7d-9362-cf215a7584ce@github.com>
References: <1sDlqlKVNOobyFy71f7ud5uL8_WcMPi1qKNa4ltxFQ0=.63cffbd7-e11a-4d7d-9362-cf215a7584ce@github.com>
Message-ID: <cIRqbjcf8yT6GfsJfwlC1u7PTxeTdbXYpoTbv3I7UmQ=.6ef8856b-0555-45e8-8c71-db8e251826ab@github.com>

On Sun, 19 Feb 2023 18:41:18 GMT, liach <duke at openjdk.org> wrote:

> 8302822: Method/Field/Constructor/RecordComponent::getGenericInfo() is not thread safe

Marked as reviewed by stsypanov (Author).

-------------

PR: https://git.openjdk.org/jdk/pull/12643

From redestad at openjdk.org  Mon Feb 20 08:25:25 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Mon, 20 Feb 2023 08:25:25 GMT
Subject: RFR: 8302822:
 Method/Field/Constructor/RecordComponent::getGenericInfo() is not thread safe
In-Reply-To: <1sDlqlKVNOobyFy71f7ud5uL8_WcMPi1qKNa4ltxFQ0=.63cffbd7-e11a-4d7d-9362-cf215a7584ce@github.com>
References: <1sDlqlKVNOobyFy71f7ud5uL8_WcMPi1qKNa4ltxFQ0=.63cffbd7-e11a-4d7d-9362-cf215a7584ce@github.com>
Message-ID: <BI2fC-Y4NYvK4utLF1sNbHkO4Xds1YyXoOW5Ry_dkeo=.b2c5bc6d-3141-461c-a8f4-3666d20f0f16@github.com>

On Sun, 19 Feb 2023 18:41:18 GMT, liach <duke at openjdk.org> wrote:

> 8302822: Method/Field/Constructor/RecordComponent::getGenericInfo() is not thread safe

Marked as reviewed by redestad (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/12643

From jpai at openjdk.org  Mon Feb 20 08:30:25 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 20 Feb 2023 08:30:25 GMT
Subject: RFR: 8302822:
 Method/Field/Constructor/RecordComponent::getGenericInfo() is not thread safe
In-Reply-To: <1sDlqlKVNOobyFy71f7ud5uL8_WcMPi1qKNa4ltxFQ0=.63cffbd7-e11a-4d7d-9362-cf215a7584ce@github.com>
References: <1sDlqlKVNOobyFy71f7ud5uL8_WcMPi1qKNa4ltxFQ0=.63cffbd7-e11a-4d7d-9362-cf215a7584ce@github.com>
Message-ID: <kV1ZOQV_kxX5HR1ZbBHWMwqb5vc_SrhpUrUEEhUkOyQ=.de790785-0c75-4011-96b9-5b059fa1bf47@github.com>

On Sun, 19 Feb 2023 18:41:18 GMT, liach <duke at openjdk.org> wrote:

> 8302822: Method/Field/Constructor/RecordComponent::getGenericInfo() is not thread safe

Hello @liach, I don't follow what this change is achieving. I think I might be missing something though. I read through the linked JIRA which states:

> In the getGenericInfo() methods of Method, Field, Constructor, and RecordComponent, the genericInfo field is read twice, and the second read returned may be null under race conditions.

Considering the `Constructor` class as an example, which looks like this:


@Override
    ConstructorRepository getGenericInfo() {
        // lazily initialize repository if necessary
        if (genericInfo == null) {
            // create and cache generic info repository
            genericInfo =
                ConstructorRepository.make(getSignature(),
                                           getFactory());
        }
        return genericInfo; //return cached repository
    }

I can understand that the `ConstructorRepository.make(getSignature(), getFactory());` might end up getting called more than once in case of race (or if ConstructorRepository.make(getSignature(), getFactory()) really returns null), but those should be harmless races. Plus, the getSignature() isn't expensive, since it returns an already assigned `final` field.
Is there some other race condition here?

The JBS issue also states:

> Class::getGenericInfo() originally had the same issue, but was fixed in 8016236.

I had a look at the RFR https://mail.openjdk.org/pipermail/core-libs-dev/2013-June/017798.html. That's a slightly different issue, from what I understand. In that case, the call to getGenericInfo() was being preceded by a call to some other expensive method. The change there proposed to first call getGenericInfo() and let it be initialized and only then decide whether to call the other expensive methods.
In that change, I can see that the `getGenericInfo()` method on the `Class` class was changed too and that change is almost similar to what's being proposed in this current PR. However, `Class.genericInfo` field is `volatile` and I think that's why Doug changed that method to first write it to a local field and then use that local field for the rest of the work. In the current PR however, which touches `Field`, `Method`, `Constructor` and `RecordComponent`, the `genericInfo` isn't a `volatile` field in any of those classes, so I don't see why this local assignment is needed or would help. Am I missing something?

-------------

PR: https://git.openjdk.org/jdk/pull/12643

From pminborg at openjdk.org  Mon Feb 20 08:39:25 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 20 Feb 2023 08:39:25 GMT
Subject: RFR: 8299852: Modernize ConcurrentHashMap [v3]
In-Reply-To: <AC_zApEcsuBSWzRSEh2VMQcQf-gSm4CyfiMXfy2WbPM=.0439016d-88f2-4892-98f8-a6f1fff2128a@github.com>
References: <AC_zApEcsuBSWzRSEh2VMQcQf-gSm4CyfiMXfy2WbPM=.0439016d-88f2-4892-98f8-a6f1fff2128a@github.com>
Message-ID: <6tLu_xk0LMUNEeaud_jnWZrYBabAfdqHsJcwu0QKRi4=.539f2640-bb69-4cdb-971b-64ad789e3fa8@github.com>

> `java.util.concurrent.ConcurrentHashMap` is relatively old and has not been updated to reflect the current state of Java and can be modernized: 
> 
> * Add `@Serial` annotations 
> * Seal classes and restrict subclassing for internal classes 
> * Use pattern matching for instance 
> * Remove redundant modifiers (such as some final declarations) 
> * Use Objects.requireNonNull for invariant checking 
> * Use diamond operators instead of explicit types 
> * Simplify expressions using Math::max

Per Minborg has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits:

 - Merge master
 - Add @Override annotations
 - Untrack file
 - Modernize ConcurrentHashMap

-------------

Changes: https://git.openjdk.org/jdk/pull/11924/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11924&range=02
  Stats: 534 lines in 1 file changed: 164 ins; 21 del; 349 mod
  Patch: https://git.openjdk.org/jdk/pull/11924.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11924/head:pull/11924

PR: https://git.openjdk.org/jdk/pull/11924

From redestad at openjdk.org  Mon Feb 20 08:50:24 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Mon, 20 Feb 2023 08:50:24 GMT
Subject: RFR: 8302822:
 Method/Field/Constructor/RecordComponent::getGenericInfo() is not thread safe
In-Reply-To: <1sDlqlKVNOobyFy71f7ud5uL8_WcMPi1qKNa4ltxFQ0=.63cffbd7-e11a-4d7d-9362-cf215a7584ce@github.com>
References: <1sDlqlKVNOobyFy71f7ud5uL8_WcMPi1qKNa4ltxFQ0=.63cffbd7-e11a-4d7d-9362-cf215a7584ce@github.com>
Message-ID: <iK2r5ihAvjiWKvSNMWmzhihxqbN88ZHTc2OMpb8yCAo=.25cee88d-9e29-47a3-ad8c-064a50503350@github.com>

On Sun, 19 Feb 2023 18:41:18 GMT, liach <duke at openjdk.org> wrote:

> 8302822: Method/Field/Constructor/RecordComponent::getGenericInfo() is not thread safe

I think of this pattern of reading a to-be-lazily-initialized value into a local as simple hygiene, `volatile` or not. The code might seem solid without it - but stranger things than eliding a field load has happened. Storing into the local variable removes some doubt about how this code will be executed.

-------------

PR: https://git.openjdk.org/jdk/pull/12643

From simonis at openjdk.org  Mon Feb 20 08:52:35 2023
From: simonis at openjdk.org (Volker Simonis)
Date: Mon, 20 Feb 2023 08:52:35 GMT
Subject: RFR: 8302154: Hidden classes created by LambdaMetaFactory can't be
 unloaded [v2]
In-Reply-To: <mdUCR3q15IQlPgv28lLdZHVWkUn67KeHgLMRtlV6UlU=.9ae87930-e6c6-4428-bcb2-76e4578628d5@github.com>
References: <YoZauVv8zvhdUw-LD25LrsMDItFbg3aXPU3deXwwFdQ=.c2839dea-12e5-4e0e-9579-eac9d8503932@github.com>
 <gKoLpwlXDxp2uaSKSkMArJl1Ym9VX1hoDFqQTTUpk8w=.e1dce669-5a42-4b66-ac4b-205718c8eb81@github.com>
 <bYkGnm79U37ob-7VlaEzPlzcJZrFpzn0mnnZxCen5wk=.268d1655-2ed2-4d9c-895f-84de711ee611@github.com>
 <mdUCR3q15IQlPgv28lLdZHVWkUn67KeHgLMRtlV6UlU=.9ae87930-e6c6-4428-bcb2-76e4578628d5@github.com>
Message-ID: <ewjFGq0g_ynpjTzUqGXQ9pjRu9n1N7i2MEW8OY35BxU=.b767f70e-c5ff-455d-bfca-a725384a1b8d@github.com>

On Fri, 17 Feb 2023 21:21:56 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

> > (because they are all not referenced from the program any more).
> 
> So, it sounds like this is testing a case where `LambdaMetafactory.metafactory` is being called directly?
> 
> I'd like to point out that, while I buy that people are doing this (I see enough of this on StackOverflow), `LambdaMetafactory` is a runtime API specifically designed to support a language feature. Calling it directly is an unintended use case.

Sorry, but that's a really weird argument. You can't introduce a new public API and then blame people for using it! If the API is really only intended to support the internal implementation of a language feature than make it private and don't export it.

-------------

PR: https://git.openjdk.org/jdk/pull/12493

From simonis at openjdk.org  Mon Feb 20 08:52:36 2023
From: simonis at openjdk.org (Volker Simonis)
Date: Mon, 20 Feb 2023 08:52:36 GMT
Subject: RFR: 8302154: Hidden classes created by LambdaMetaFactory can't be
 unloaded [v2]
In-Reply-To: <mCiV2qpn4JzY7zRO8lIEIo-Lq6vpGrnF7wzZf4beYM8=.aa98a46b-d39c-4866-a6cb-731b7e23dd48@github.com>
References: <YoZauVv8zvhdUw-LD25LrsMDItFbg3aXPU3deXwwFdQ=.c2839dea-12e5-4e0e-9579-eac9d8503932@github.com>
 <gKoLpwlXDxp2uaSKSkMArJl1Ym9VX1hoDFqQTTUpk8w=.e1dce669-5a42-4b66-ac4b-205718c8eb81@github.com>
 <bYkGnm79U37ob-7VlaEzPlzcJZrFpzn0mnnZxCen5wk=.268d1655-2ed2-4d9c-895f-84de711ee611@github.com>
 <mCiV2qpn4JzY7zRO8lIEIo-Lq6vpGrnF7wzZf4beYM8=.aa98a46b-d39c-4866-a6cb-731b7e23dd48@github.com>
Message-ID: <JXMH4QHVFGdnaH-AOZQAY-cPxGRJq6TI0PGJiseB_UA=.dac73436-bd50-429a-a860-f7abc42d5085@github.com>

On Sat, 18 Feb 2023 01:55:52 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> > Finally, the PR fixes a regression compared to the JDK 11 behavior.
> 
> This is an intended change that improves the C heap memory usage. In addition, the spec of `LambdaMetafactory` has no guarantee of the spinned classes be unloaded independent of it defining loader. This is indeed a behavioral change if `LambdaMetafactory` API is called directly instead of via `invokedynamic`. I can create a CSR to retrofit this behavioral change.

Yes, please. I think that would be helpful.

-------------

PR: https://git.openjdk.org/jdk/pull/12493

From dholmes at openjdk.org  Mon Feb 20 09:37:30 2023
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 20 Feb 2023 09:37:30 GMT
Subject: RFR: 8302154: Hidden classes created by LambdaMetaFactory can't be
 unloaded [v2]
In-Reply-To: <ewjFGq0g_ynpjTzUqGXQ9pjRu9n1N7i2MEW8OY35BxU=.b767f70e-c5ff-455d-bfca-a725384a1b8d@github.com>
References: <YoZauVv8zvhdUw-LD25LrsMDItFbg3aXPU3deXwwFdQ=.c2839dea-12e5-4e0e-9579-eac9d8503932@github.com>
 <gKoLpwlXDxp2uaSKSkMArJl1Ym9VX1hoDFqQTTUpk8w=.e1dce669-5a42-4b66-ac4b-205718c8eb81@github.com>
 <bYkGnm79U37ob-7VlaEzPlzcJZrFpzn0mnnZxCen5wk=.268d1655-2ed2-4d9c-895f-84de711ee611@github.com>
 <mdUCR3q15IQlPgv28lLdZHVWkUn67KeHgLMRtlV6UlU=.9ae87930-e6c6-4428-bcb2-76e4578628d5@github.com>
 <ewjFGq0g_ynpjTzUqGXQ9pjRu9n1N7i2MEW8OY35BxU=.b767f70e-c5ff-455d-bfca-a725384a1b8d@github.com>
Message-ID: <2ZV0893_BOjAOXAvGOYYVbmRHxh3jXmnXusIiVhrgRk=.7c081275-b4e3-4173-97a0-28ecadf89152@github.com>

On Mon, 20 Feb 2023 08:49:38 GMT, Volker Simonis <simonis at openjdk.org> wrote:

> Sorry, but that's a really weird argument. You can't introduce a new public API and then blame people for using it! If the API is really only intended to support the internal implementation of a language feature than make it private and don't export it.

The spec states:

> API Note:
>   These linkage methods are designed to support the evaluation of lambda expressions and method references in the Java Language. 

The API has to be public as the call gets injected into application code.

-------------

PR: https://git.openjdk.org/jdk/pull/12493

From alanb at openjdk.org  Mon Feb 20 09:42:26 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 20 Feb 2023 09:42:26 GMT
Subject: RFR: 8302154: Hidden classes created by LambdaMetaFactory can't be
 unloaded [v2]
In-Reply-To: <2ZV0893_BOjAOXAvGOYYVbmRHxh3jXmnXusIiVhrgRk=.7c081275-b4e3-4173-97a0-28ecadf89152@github.com>
References: <YoZauVv8zvhdUw-LD25LrsMDItFbg3aXPU3deXwwFdQ=.c2839dea-12e5-4e0e-9579-eac9d8503932@github.com>
 <gKoLpwlXDxp2uaSKSkMArJl1Ym9VX1hoDFqQTTUpk8w=.e1dce669-5a42-4b66-ac4b-205718c8eb81@github.com>
 <bYkGnm79U37ob-7VlaEzPlzcJZrFpzn0mnnZxCen5wk=.268d1655-2ed2-4d9c-895f-84de711ee611@github.com>
 <mdUCR3q15IQlPgv28lLdZHVWkUn67KeHgLMRtlV6UlU=.9ae87930-e6c6-4428-bcb2-76e4578628d5@github.com>
 <ewjFGq0g_ynpjTzUqGXQ9pjRu9n1N7i2MEW8OY35BxU=.b767f70e-c5ff-455d-bfca-a725384a1b8d@github.com>
 <2ZV0893_BOjAOXAvGOYYVbmRHxh3jXmnXusIiVhrgRk=.7c081275-b4e3-4173-97a0-28ecadf89152@github.com>
Message-ID: <ikVdKqykd8kCPXDsio75YYXdj97FHeBtmsSOqmlFidM=.5ba507ff-af3f-4c9b-a450-c5d2d96f9869@github.com>

On Mon, 20 Feb 2023 09:34:17 GMT, David Holmes <dholmes at openjdk.org> wrote:

> You can't introduce a new public API and then blame people for using it! If the API is really only intended to support the internal implementation of a language feature than make it private and don't export it.

There are a number of APIs that exist to support the Java Language. LambdaMetafactory makes it clear in the first paragraph of its API docs that it supports the lambda expression and method reference expression features of the Java Language. If a Java compiler compiles these language constructs to invokedynamic instructions then the bootstrap methods have to be standard APIs, otherwise the class files won't work on all VM implementations. The APIs adding to j.l.runtime are similar. Maybe some advance tooling/framework might use them directly but it should be rare.

-------------

PR: https://git.openjdk.org/jdk/pull/12493

From dholmes at openjdk.org  Mon Feb 20 09:47:27 2023
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 20 Feb 2023 09:47:27 GMT
Subject: RFR: 8302822:
 Method/Field/Constructor/RecordComponent::getGenericInfo() is not thread safe
In-Reply-To: <1sDlqlKVNOobyFy71f7ud5uL8_WcMPi1qKNa4ltxFQ0=.63cffbd7-e11a-4d7d-9362-cf215a7584ce@github.com>
References: <1sDlqlKVNOobyFy71f7ud5uL8_WcMPi1qKNa4ltxFQ0=.63cffbd7-e11a-4d7d-9362-cf215a7584ce@github.com>
Message-ID: <JPaMfJY_16Z67AS-nVhP2vXY6PezSpwJZNNttJzqjCQ=.b10a81ae-aa61-45e2-a297-2c3c29c000eb@github.com>

On Sun, 19 Feb 2023 18:41:18 GMT, liach <duke at openjdk.org> wrote:

> 8302822: Method/Field/Constructor/RecordComponent::getGenericInfo() is not thread safe

The field needs to be volatile for these construction races to be thread-safe, otherwise no guarantee that seeing a non-null genericInfo will mean you see any writes done by the factory methods.

-------------

PR: https://git.openjdk.org/jdk/pull/12643

From pminborg at openjdk.org  Mon Feb 20 09:59:27 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 20 Feb 2023 09:59:27 GMT
Subject: RFR: 8301552: Use AtomicReferenceArray for caching instead of CHM
 in ZoneOffset [v8]
In-Reply-To: <ESUpuSgjM_9ocUr1O_7tjY-Pf2sps17BX69XpDtwoEg=.c93d0dbb-372f-4827-8239-cca058a8bf48@github.com>
References: <b228oWPoEJf0lfGgIVXwmo1mATeKWRTivuJ2PbgwAmI=.465a4f9b-7a4b-4bbb-9f94-66d1d889a072@github.com>
 <ESUpuSgjM_9ocUr1O_7tjY-Pf2sps17BX69XpDtwoEg=.c93d0dbb-372f-4827-8239-cca058a8bf48@github.com>
Message-ID: <q5aVKbC-QUUMAC4Z-iiydJiANTmHgV5kkDfgILmqnu8=.04588ea4-0627-4b48-ade0-3c66b1fdef4d@github.com>

On Thu, 9 Feb 2023 13:46:14 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> `ZoneOffset` instances are cached by the `ZoneOffset` class itself for values in the range [-18h, 18h] for each second that is on an even quarter of an hour (i.e. at most 2*18*4+1 = 145 values). 
>> 
>> Instead of using a `ConcurrentHashMap` for caching instanced, we could instead use an `AtomicReferenceArray` with direct slot value access for said even seconds. This will improve performance and reduce the number of object even though the backing array will go from an initial 32 in the CHM to an initial/final 145 in the ARA. The CHM will contain much more objects and array slots for typical numbers of entries in the cache and will compute hash/bucket/collision on the hot code path for each cache access.
>
> Per Minborg has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Remove unused setup method
>  - Rename method in test
>  - Add copyright header

Other potential candidates for using `LazyReferenceArray`:

* java.nio.charset.CoderResult
* ZoneRule
* Locale
* sun.font.FileFontStrike, PhysicalStrike
* sun.security.Token
* sun.security.provider.ParameterCache
* sun.security.ssl.SSLSessionContextImpl
* sun.util.locale.provider.LocaleProviderAdapter

NOTE: The one mentioned above are candidates and further investigation is needed to see if they are actually a fit.

-------------

PR: https://git.openjdk.org/jdk/pull/12346

From rgiulietti at openjdk.org  Mon Feb 20 10:25:29 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Mon, 20 Feb 2023 10:25:29 GMT
Subject: RFR: JDK-8302800: Augment NaN handling tests of FDLIBM methods
In-Reply-To: <mc-_elojltkXx-TJQxeFKmIK6TELw_WBpwoSv7rdgEc=.9b3224a0-c9a0-475e-b7e8-86317d1ac04b@github.com>
References: <mc-_elojltkXx-TJQxeFKmIK6TELw_WBpwoSv7rdgEc=.9b3224a0-c9a0-475e-b7e8-86317d1ac04b@github.com>
Message-ID: <KR6zj5_QCUqe7IzB4GSKjeNqoodcNZ25Ff85gBOIm44=.c73f47d4-85fd-413a-9972-daaf00c7cba4@github.com>

On Sun, 19 Feb 2023 21:30:19 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Augment NaN-handling tests to include exotic NaN bit patterns. Assuming this changeset goes back first, I'll update https://github.com/openjdk/jdk/pull/12608 to follow the same convention afterward.

Otherwise LGTM

test/jdk/java/lang/Math/Tests.java line 41:

> 39:     private Tests(){}; // do not instantiate
> 40: 
> 41:     static volatile double zero = 0.0;

Not directly related to this PR and just out of curiosity: is there a reason for this to be `volatile` and non-`final`?

-------------

PR: https://git.openjdk.org/jdk/pull/12644

From duke at openjdk.org  Mon Feb 20 10:51:57 2023
From: duke at openjdk.org (Viktor Klang)
Date: Mon, 20 Feb 2023 10:51:57 GMT
Subject: RFR: JDK-8302666: Replace CHM with VarHandle in ForeachOrderedTask
 [v3]
In-Reply-To: <HAgE8xmpZT_2-b5ZDr8TgJNgjhVb3D4ZS3sQqA7c6Mo=.389fa590-681c-44a9-9823-8f70a6129797@github.com>
References: <HAgE8xmpZT_2-b5ZDr8TgJNgjhVb3D4ZS3sQqA7c6Mo=.389fa590-681c-44a9-9823-8f70a6129797@github.com>
Message-ID: <G8nat7HA_ssqEUF87ijnOJCx285zNlTChsI2yvGvqEM=.1139145e-3fd6-4be7-afa6-3117e443b7c5@github.com>

> I noticed when looking at the code that there was no real need to use a CHM to perform the tracking of activation in an ordered fashion on ForEachOrderedTask, but instead a VarHandle can be used, reducing allocations and indirection.

Viktor Klang has updated the pull request incrementally with one additional commit since the last revision:

  Updating copyright header of ForEachOps.java and removing unnecessary suppression of an unchecked cast.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12320/files
  - new: https://git.openjdk.org/jdk/pull/12320/files/3b38f942..866d5a39

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12320&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12320&range=01-02

  Stats: 4 lines in 1 file changed: 0 ins; 2 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/12320.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12320/head:pull/12320

PR: https://git.openjdk.org/jdk/pull/12320

From duke at openjdk.org  Mon Feb 20 10:51:58 2023
From: duke at openjdk.org (Viktor Klang)
Date: Mon, 20 Feb 2023 10:51:58 GMT
Subject: RFR: JDK-8302666: Replace CHM with VarHandle in ForeachOrderedTask
 [v2]
In-Reply-To: <8S7Q0oMLcMo96x4Al5iiUspFDcgqk_tRavYCoDM1cbs=.0a3ccbe9-e199-4dbb-a1c1-252b4e906b86@github.com>
References: <HAgE8xmpZT_2-b5ZDr8TgJNgjhVb3D4ZS3sQqA7c6Mo=.389fa590-681c-44a9-9823-8f70a6129797@github.com>
 <fLSt64PoI3s47g0BLWPMUkim0lmnuZ6wxoBJZppqgqg=.36deb86f-2998-490d-9e29-903e142c72d1@github.com>
 <8S7Q0oMLcMo96x4Al5iiUspFDcgqk_tRavYCoDM1cbs=.0a3ccbe9-e199-4dbb-a1c1-252b4e906b86@github.com>
Message-ID: <KxDsE-wyl2kppNaVri8b4ADCrh78wWlPMWNQfHW3h3I=.0c39809b-acd2-4536-a9ac-7caddd4ba209@github.com>

On Fri, 17 Feb 2023 16:48:27 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>> Viktor Klang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Write the initial value of the next reference without using the VarHandle
>
> That's a nice find, looks good. (Update the year in the copyright header.)

@PaulSandoz Thanks for the review, Paul?I've eliminated an unneeded SuppressWarnings, updated the copyright year, and pushed the update here. ?

-------------

PR: https://git.openjdk.org/jdk/pull/12320

From duke at openjdk.org  Mon Feb 20 10:51:58 2023
From: duke at openjdk.org (Viktor Klang)
Date: Mon, 20 Feb 2023 10:51:58 GMT
Subject: RFR: JDK-8302666: Replace CHM with VarHandle in ForeachOrderedTask
 [v2]
In-Reply-To: <be3it2vmk01uSQwSjoQqsm0YheSdnbRXpiOyMh_iTcI=.0632f868-8583-443a-b50d-e35e91206a86@github.com>
References: <HAgE8xmpZT_2-b5ZDr8TgJNgjhVb3D4ZS3sQqA7c6Mo=.389fa590-681c-44a9-9823-8f70a6129797@github.com>
 <fLSt64PoI3s47g0BLWPMUkim0lmnuZ6wxoBJZppqgqg=.36deb86f-2998-490d-9e29-903e142c72d1@github.com>
 <be3it2vmk01uSQwSjoQqsm0YheSdnbRXpiOyMh_iTcI=.0632f868-8583-443a-b50d-e35e91206a86@github.com>
Message-ID: <YYkLg27DuP5coCppzaplA15mOGEIYhfUC1um-_S8RvA=.2882b53d-3b81-49e1-a0c0-e12d0a2ad85f@github.com>

On Sat, 18 Feb 2023 02:40:01 GMT, ExE Boss <duke at openjdk.org> wrote:

>> Viktor Klang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Write the initial value of the next reference without using the VarHandle
>
> src/java.base/share/classes/java/util/stream/ForEachOps.java line 515:
> 
>> 513:             //
>> 514:             @SuppressWarnings("unchecked")
>> 515:             var leftDescendant = (ForEachOrderedTask<S, T>)NEXT.getAndSet(this, null);
> 
> I?don?t?think that?this?needs a?`@SuppressWarnings("unchecked")`, as?casts of?signature?polymorphic return?values don?t?emit unchecked?warnings (unless?that?changed?recently):
> Suggestion:
> 
>             var leftDescendant = (ForEachOrderedTask<S, T>) NEXT.getAndSet(this, (ForEachOrderedTask<S, T>) null);

Thanks for having a look at the PR, you're right, the suppression isn't needed.

-------------

PR: https://git.openjdk.org/jdk/pull/12320

From chegar at openjdk.org  Mon Feb 20 11:03:27 2023
From: chegar at openjdk.org (Chris Hegarty)
Date: Mon, 20 Feb 2023 11:03:27 GMT
Subject: RFR: 8301627: System.exit and Runtime.exit debug logging [v6]
In-Reply-To: <rtvSaGTGh2k6ueBg5TPNkXlBtWcKSlK-9cVFQX2zRpI=.1e076983-271e-4321-bc6a-e1b765c97803@github.com>
References: <OzJeJH5yxolKPChcUisqtzGYF_MU3oOJdx6HPhsXjBw=.15eefe39-efe1-433e-a6ac-02b4a730f264@github.com>
 <rtvSaGTGh2k6ueBg5TPNkXlBtWcKSlK-9cVFQX2zRpI=.1e076983-271e-4321-bc6a-e1b765c97803@github.com>
Message-ID: <8ywMXHeSBxD8CmcwxaTd0NKM9gqxXLEEgGja-Ft4GAQ=.89e3304a-6c4a-4cf7-ae91-9875f0cdd536@github.com>

On Fri, 17 Feb 2023 17:27:50 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> It can be difficult to find the cause of calls to `java.lang.System.exit(status)` and `Runtime.exit(status)` because the Java runtime exits.
>> The status value and stack trace are logged using the System Logger named `java.lang.Runtime` with message level `System.Logger.Level.DEBUG`.
>
> Roger Riggs 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:
> 
>  - Move test to the java/lang/RuntimeTests directory.
>    Added implNote to System.exit.
>    A few javadoc updates for review comments.
>  - Merge branch 'master' into 8301627-log-system-exit
>  - Improve implNote for Runtime.exit() with review suggestions.
>  - Correct System.getLogger link
>  - Add an @implNote to Runtime.exit to describe the java.lang.Runtime logging.
>  - Added try/catch around lookup of logger so exceptions do not prevent System.exit.
>    Added test case with console logger (when java.util.logging) not present.
>    Removed @implNote tag its not appropriate in implementation javadoc.
>    Still looking into when and where the log configuration should be described.
>  - Locate the System logger before taking the shutdown lock
>  - Add logging of calls to Runtime.exit to the system logger "java.lang.Runtime".

I left one trivial comment relating to a typo, but otherwise LGTM.

src/java.base/share/classes/java/lang/Runtime.java line 160:

> 158:      *
> 159:      * @implNote
> 160:      * If the {@linkplain System#getLogger(String) the system logger} for {@code java.lang.Runtime}

Trivially, remove the double "the the" here.

-------------

Marked as reviewed by chegar (Reviewer).

PR: https://git.openjdk.org/jdk/pull/12517

From claes.redestad at oracle.com  Mon Feb 20 11:39:21 2023
From: claes.redestad at oracle.com (Claes Redestad)
Date: Mon, 20 Feb 2023 11:39:21 +0000
Subject: String encodeASCII
In-Reply-To: <CANBJVOGfg3i9dE=WN6dAazGNBqRjeBYkmMnGKtZigdT+EiBQpw@mail.gmail.com>
References: <CANBJVOF1CAeOw99A6WFxJc60VOdDCctKxo5RKYtJA_2WUBchjg@mail.gmail.com>
 <4FB46DE3-D300-4928-9F8D-F0B7E112AF97@oracle.com>
 <CANBJVOGfg3i9dE=WN6dAazGNBqRjeBYkmMnGKtZigdT+EiBQpw@mail.gmail.com>
Message-ID: <9AF41ED6-A16C-4E76-A100-ADC18298E2A9@oracle.com>

Unsafe might be similarly tricky dependency-wise, but perhaps less so. Either solution might work fine if we extract the code for encoding to a utility class that isn?t initialized eagerly with String.class itself.

I?ll file an RFE and get the ?trivial? fix to use StringCoding.countPositives in to establish a better baseline. I?m sure there are ways to beat this, for example with a fused loop. An unrolled and/or VH-based solution like you?ve proposed could at the very least be used to speedup the case of Strings for which we need to replace with ???.

/Claes

19 feb. 2023 kl. 02:54 skrev Brett Okken <brett.okken.os at gmail.com<mailto:brett.okken.os at gmail.com>>:

Thanks for taking a look at this.
That is a pretty good improvement with a much smaller change.
I recognize the intricacies of bootstrapping, but have no expertise. Would using Unsafe directly be easier? Particularly for shorter strings, doing the copying and checking together rather than as separate loops seems to speed things up considerably, even for happy-path of no failures.

Brett

On Sat, Feb 18, 2023 at 5:49 PM Claes Redestad <claes.redestad at oracle.com<mailto:claes.redestad at oracle.com>> wrote:
Hi,

general comment: String might be one of the trickier places to add a VarHandle dependency, since String is used very early in the bootstrap and depended upon by everything else, so I?d expect such a solution would have to navigate potential circularity issues carefully. It?d be good to experiment with changes to java.lang.String proper to see that the solution that works nice externally is or can be made feasible within String.

Specifically on the performance opportunity then while US-ASCII encoding is probably on the way out we shouldn?t neglect it.

One way to go about this without pulling VarHandles into String might be to use what other encode methods in String does and leverage StringCoding.countPositives:

https://github.com/openjdk/jdk/pull/12640<https://urldefense.com/v3/__https://github.com/openjdk/jdk/pull/12640__;!!ACWV5N9M2RV99hQ!O-1OoPjv-Jw1iGFv2-_q5zTiayoRyLJBcSiQ9J5IEun3kcusUeGRjZzOb_dploCjPh_Kjp6FJXr2cIk7Se5Zp4JhLWU$>

Testing this on the existing StringEncode microbenchmark, shows a promising speed-up when the input is ASCII-encodable:

Baseline
Benchmark                      (charsetName)  Mode  Cnt      Score     Error  Units
StringEncode.encodeAsciiLong        US-ASCII  avgt    5  26626,025 ? 448,307  ns/op
StringEncode.encodeAsciiShort       US-ASCII  avgt    5     33,336 ?   2,032  ns/op

Patch:
Benchmark                      (charsetName)  Mode  Cnt     Score    Error  Units
StringEncode.encodeAsciiLong        US-ASCII  avgt    5  5492,985 ? 40,066  ns/op
StringEncode.encodeAsciiShort       US-ASCII  avgt    5    28,545 ?  4,883  ns/op

(You might see that this will go back into a scalar loop on encoding failures. That loop could still benefit from unrolling or byteArrayViewVarHandle, but I think you have a bigger problem in an app than raw performance if you have a lot of encoding failures...)

WDYT?

/Claes

18 feb. 2023 kl. 19:36 skrev Brett Okken <brett.okken.os at gmail.com<mailto:brett.okken.os at gmail.com>>:

https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/lang/String.java#L976-L981<https://urldefense.com/v3/__https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/lang/String.java*L976-L981__;Iw!!ACWV5N9M2RV99hQ!O-1OoPjv-Jw1iGFv2-_q5zTiayoRyLJBcSiQ9J5IEun3kcusUeGRjZzOb_dploCjPh_Kjp6FJXr2cIk7Se5Z_Ook_Ws$>

For String.encodeASCII, with the LATIN1 coder is there any interest in
exploring the performance impacts of utilizing a
byteArrayViewVarHandle to read/write as longs and utilize a bitmask to
identify if negative values are present?

A simple jmh benchmark covering either 0 or 1 non-ascii (negative)
values shows times cut in half (or more) for most scenarios with
strings ranging in length from 3 - ~2000.
VM version: JDK 17.0.6, OpenJDK 64-Bit Server VM, 17.0.6+10
Windows 10 Intel(R) Core(TM) i7-9850H

Hand unrolling the loops shows noted improvement, but does make for
less aesthetically pleasing code.


Benchmark                                  (nonascii)  (size)  Mode
Cnt    Score     Error  Units
AsciiEncodeBenchmark.jdk                         none       3  avgt
4   15.531 ?   1.122  ns/op
AsciiEncodeBenchmark.jdk                         none      10  avgt
4   17.350 ?   0.473  ns/op
AsciiEncodeBenchmark.jdk                         none      16  avgt
4   18.277 ?   0.421  ns/op
AsciiEncodeBenchmark.jdk                         none      23  avgt
4   20.139 ?   0.350  ns/op
AsciiEncodeBenchmark.jdk                         none      33  avgt
4   22.008 ?   0.656  ns/op
AsciiEncodeBenchmark.jdk                         none      42  avgt
4   24.393 ?   1.155  ns/op
AsciiEncodeBenchmark.jdk                         none     201  avgt
4   55.884 ?   0.645  ns/op
AsciiEncodeBenchmark.jdk                         none     511  avgt
4  120.817 ?   2.917  ns/op
AsciiEncodeBenchmark.jdk                         none    2087  avgt
4  471.039 ?  13.329  ns/op
AsciiEncodeBenchmark.jdk                        first       3  avgt
4   15.794 ?   1.494  ns/op
AsciiEncodeBenchmark.jdk                        first      10  avgt
4   18.446 ?   0.780  ns/op
AsciiEncodeBenchmark.jdk                        first      16  avgt
4   20.458 ?   0.394  ns/op
AsciiEncodeBenchmark.jdk                        first      23  avgt
4   22.934 ?   0.422  ns/op
AsciiEncodeBenchmark.jdk                        first      33  avgt
4   25.367 ?   0.178  ns/op
AsciiEncodeBenchmark.jdk                        first      42  avgt
4   28.620 ?   0.678  ns/op
AsciiEncodeBenchmark.jdk                        first     201  avgt
4   80.250 ?   4.376  ns/op
AsciiEncodeBenchmark.jdk                        first     511  avgt
4  185.518 ?   6.370  ns/op
AsciiEncodeBenchmark.jdk                        first    2087  avgt
4  713.213 ?  13.488  ns/op
AsciiEncodeBenchmark.jdk                         last       3  avgt
4   14.991 ?   0.190  ns/op
AsciiEncodeBenchmark.jdk                         last      10  avgt
4   18.284 ?   0.317  ns/op
AsciiEncodeBenchmark.jdk                         last      16  avgt
4   20.591 ?   1.002  ns/op
AsciiEncodeBenchmark.jdk                         last      23  avgt
4   22.560 ?   0.963  ns/op
AsciiEncodeBenchmark.jdk                         last      33  avgt
4   25.521 ?   0.554  ns/op
AsciiEncodeBenchmark.jdk                         last      42  avgt
4   28.484 ?   0.446  ns/op
AsciiEncodeBenchmark.jdk                         last     201  avgt
4   79.434 ?   2.256  ns/op
AsciiEncodeBenchmark.jdk                         last     511  avgt
4  186.639 ?   4.258  ns/op
AsciiEncodeBenchmark.jdk                         last    2087  avgt
4  725.196 ? 149.416  ns/op
AsciiEncodeBenchmark.longCheckCopy               none       3  avgt
4    7.222 ?   0.428  ns/op
AsciiEncodeBenchmark.longCheckCopy               none      10  avgt
4    8.070 ?   0.171  ns/op
AsciiEncodeBenchmark.longCheckCopy               none      16  avgt
4    6.711 ?   0.409  ns/op
AsciiEncodeBenchmark.longCheckCopy               none      23  avgt
4   12.906 ?   3.633  ns/op
AsciiEncodeBenchmark.longCheckCopy               none      33  avgt
4   10.414 ?   0.447  ns/op
AsciiEncodeBenchmark.longCheckCopy               none      42  avgt
4   11.935 ?   1.235  ns/op
AsciiEncodeBenchmark.longCheckCopy               none     201  avgt
4   29.538 ?   3.265  ns/op
AsciiEncodeBenchmark.longCheckCopy               none     511  avgt
4  106.228 ?  68.475  ns/op
AsciiEncodeBenchmark.longCheckCopy               none    2087  avgt
4  494.845 ? 890.985  ns/op
AsciiEncodeBenchmark.longCheckCopy              first       3  avgt
4    7.775 ?   0.278  ns/op
AsciiEncodeBenchmark.longCheckCopy              first      10  avgt
4   13.396 ?   2.072  ns/op
AsciiEncodeBenchmark.longCheckCopy              first      16  avgt
4   13.528 ?   0.702  ns/op
AsciiEncodeBenchmark.longCheckCopy              first      23  avgt
4   17.376 ?   0.360  ns/op
AsciiEncodeBenchmark.longCheckCopy              first      33  avgt
4   16.251 ?   0.203  ns/op
AsciiEncodeBenchmark.longCheckCopy              first      42  avgt
4   17.932 ?   1.773  ns/op
AsciiEncodeBenchmark.longCheckCopy              first     201  avgt
4   39.028 ?   4.699  ns/op
AsciiEncodeBenchmark.longCheckCopy              first     511  avgt
4   92.599 ?  11.078  ns/op
AsciiEncodeBenchmark.longCheckCopy              first    2087  avgt
4  347.728 ?   7.837  ns/op
AsciiEncodeBenchmark.longCheckCopy               last       3  avgt
4    7.472 ?   0.078  ns/op
AsciiEncodeBenchmark.longCheckCopy               last      10  avgt
4    8.371 ?   0.815  ns/op
AsciiEncodeBenchmark.longCheckCopy               last      16  avgt
4    6.766 ?   0.253  ns/op
AsciiEncodeBenchmark.longCheckCopy               last      23  avgt
4   12.879 ?   0.454  ns/op
AsciiEncodeBenchmark.longCheckCopy               last      33  avgt
4   10.491 ?   0.811  ns/op
AsciiEncodeBenchmark.longCheckCopy               last      42  avgt
4   12.435 ?   1.212  ns/op
AsciiEncodeBenchmark.longCheckCopy               last     201  avgt
4   28.507 ?   1.058  ns/op
AsciiEncodeBenchmark.longCheckCopy               last     511  avgt
4   85.763 ?   1.941  ns/op
AsciiEncodeBenchmark.longCheckCopy               last    2087  avgt
4  411.555 ?   3.595  ns/op
AsciiEncodeBenchmark.longCheckCopy_unroll        none       3  avgt
4    5.858 ?   0.637  ns/op
AsciiEncodeBenchmark.longCheckCopy_unroll        none      10  avgt
4    7.031 ?   0.274  ns/op
AsciiEncodeBenchmark.longCheckCopy_unroll        none      16  avgt
4    6.768 ?   0.222  ns/op
AsciiEncodeBenchmark.longCheckCopy_unroll        none      23  avgt
4   10.084 ?   0.102  ns/op
AsciiEncodeBenchmark.longCheckCopy_unroll        none      33  avgt
4    9.876 ?   0.240  ns/op
AsciiEncodeBenchmark.longCheckCopy_unroll        none      42  avgt
4   11.061 ?   0.590  ns/op
AsciiEncodeBenchmark.longCheckCopy_unroll        none     201  avgt
4   29.264 ?   1.690  ns/op
AsciiEncodeBenchmark.longCheckCopy_unroll        none     511  avgt
4   61.920 ?   5.482  ns/op
AsciiEncodeBenchmark.longCheckCopy_unroll        none    2087  avgt
4  309.183 ?  42.354  ns/op
AsciiEncodeBenchmark.longCheckCopy_unroll       first       3  avgt
4    5.687 ?   0.249  ns/op
AsciiEncodeBenchmark.longCheckCopy_unroll       first      10  avgt
4    9.537 ?   0.337  ns/op
AsciiEncodeBenchmark.longCheckCopy_unroll       first      16  avgt
4    9.928 ?   0.329  ns/op
AsciiEncodeBenchmark.longCheckCopy_unroll       first      23  avgt
4   12.510 ?   0.519  ns/op
AsciiEncodeBenchmark.longCheckCopy_unroll       first      33  avgt
4   13.028 ?   0.335  ns/op
AsciiEncodeBenchmark.longCheckCopy_unroll       first      42  avgt
4   13.640 ?   0.219  ns/op
AsciiEncodeBenchmark.longCheckCopy_unroll       first     201  avgt
4   31.046 ?   0.647  ns/op
AsciiEncodeBenchmark.longCheckCopy_unroll       first     511  avgt
4   82.998 ?   5.611  ns/op
AsciiEncodeBenchmark.longCheckCopy_unroll       first    2087  avgt
4  360.294 ?   8.419  ns/op
AsciiEncodeBenchmark.longCheckCopy_unroll        last       3  avgt
4    5.657 ?   0.197  ns/op
AsciiEncodeBenchmark.longCheckCopy_unroll        last      10  avgt
4    6.997 ?   0.081  ns/op
AsciiEncodeBenchmark.longCheckCopy_unroll        last      16  avgt
4    6.890 ?   1.319  ns/op
AsciiEncodeBenchmark.longCheckCopy_unroll        last      23  avgt
4   10.154 ?   0.389  ns/op
AsciiEncodeBenchmark.longCheckCopy_unroll        last      33  avgt
4    9.986 ?   0.592  ns/op
AsciiEncodeBenchmark.longCheckCopy_unroll        last      42  avgt
4   11.481 ?   0.375  ns/op
AsciiEncodeBenchmark.longCheckCopy_unroll        last     201  avgt
4   29.286 ?   0.723  ns/op
AsciiEncodeBenchmark.longCheckCopy_unroll        last     511  avgt
4   61.056 ?   0.977  ns/op
AsciiEncodeBenchmark.longCheckCopy_unroll        last    2087  avgt
4  303.415 ?  17.326  ns/op



   @Benchmark
   public byte[] jdk() {
       final byte[] val = this.data;
       byte[] dst = Arrays.copyOf(val, val.length);
       for (int i = 0; i < dst.length; i++) {
           if (dst[i] < 0) {
               dst[i] = '?';
           }
       }
       return dst;
   }

   @Benchmark
   public byte[] longCheckCopy() {
       final byte[] val = this.data;
       byte[] dst = new byte[val.length];
       int i = 0;
       long word;
       for (int j=dst.length - 7; i < j; i+=8) {
           word = (long)LONG_BYTES.get(val, i);
           LONG_BYTES.set(dst, i, word);
           if ((word & LONG_NEG_MASK) != 0) {
               for (int x=i, y=i+8; x<y; x++) {
                   if (dst[x] < 0) {
                       dst[x] = '?';
                   }
               }
           }
       }
       byte b;
       for (; i < dst.length; i++) {
           b = val[i];
           dst[i] = b < 0 ? (byte) '?' : b;
       }
       return dst;
   }

   @Benchmark
   public byte[] longCheckCopy_unroll() {
       final byte[] val = this.data;
       byte[] dst = new byte[val.length];
       int i = 0;
       long word;
       for (int j=dst.length - 7; i < j; i+=8) {
           word = (long)LONG_BYTES.get(val, i);
           LONG_BYTES.set(dst, i, word);
           if ((word & LONG_NEG_MASK) != 0) {
               if (dst[i] < 0) {
                   dst[i] = '?';
               }
               if (dst[i + 1] < 0) {
                   dst[i + 1] = '?';
               }
               if (dst[i + 2] < 0) {
                   dst[i + 2] = '?';
               }
               if (dst[i + 3] < 0) {
                   dst[i + 3] = '?';
               }
               if (dst[i + 4] < 0) {
                   dst[i + 4] = '?';
               }
               if (dst[i + 5] < 0) {
                   dst[i + 5] = '?';
               }
               if (dst[i + 6] < 0) {
                   dst[i + 6] = '?';
               }
               if (dst[i + 7] < 0) {
                   dst[i + 7] = '?';
               }
           }
       }
       byte b;
       switch (dst.length & 0x7) {
           case 7:
               b = val[i + 6];
               dst[i + 6] = b < 0 ? (byte) '?' : b;
           case 6:
               b = val[i + 5];
               dst[i + 5] = b < 0 ? (byte) '?' : b;
           case 5:
               b = val[i + 4];
               dst[i + 4] = b < 0 ? (byte) '?' : b;
           case 4:
               b = val[i + 3];
               dst[i + 3] = b < 0 ? (byte) '?' : b;
           case 3:
               b = val[i + 2];
               dst[i + 2] = b < 0 ? (byte) '?' : b;
           case 2:
               b = val[i + 1];
               dst[i + 1] = b < 0 ? (byte) '?' : b;
           case 1:
               b = val[i];
               dst[i] = b < 0 ? (byte) '?' : b;
       }
       return dst;
   }


Thanks,

Brett


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20230220/c7d5751f/attachment-0001.htm>

From redestad at openjdk.org  Mon Feb 20 11:55:10 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Mon, 20 Feb 2023 11:55:10 GMT
Subject: RFR: 8302863: Speed up String::encodeASCII using countPositives
Message-ID: <xo42mWnM8O8-KsosrLsJwo2hR0ZuvrwlDfq9VUAA4nM=.c67cc391-6cd1-483e-bd24-4009605553af@github.com>

When encoding Strings to US-ASCII we can speed up the happy path significantly by using `StringCoding.countPositives` as a speculative check for whether there are any chars that needs to be replaced by `'?'`. Once a non-ASCII char is encountered we fall back to the slow loop and replace as needed.

An alternative could be unrolling or using a byte array VarHandle, as show-cased by Brett Okken here: https://mail.openjdk.org/pipermail/core-libs-dev/2023-February/100573.html Having to replace chars with `?` is essentially an encoding error so it might be safe to assume this case is exceptional in practice.

-------------

Commit messages:
 - Cleanup, clone
 - Merge branch 'master' into encodeASCII
 - Improve encodeASCII by leveraging countPositives

Changes: https://git.openjdk.org/jdk/pull/12640/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12640&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8302863
  Stats: 24 lines in 1 file changed: 11 ins; 2 del; 11 mod
  Patch: https://git.openjdk.org/jdk/pull/12640.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12640/head:pull/12640

PR: https://git.openjdk.org/jdk/pull/12640

From duke at openjdk.org  Mon Feb 20 11:55:16 2023
From: duke at openjdk.org (David Schlosnagle)
Date: Mon, 20 Feb 2023 11:55:16 GMT
Subject: RFR: 8302863: Speed up String::encodeASCII using countPositives
In-Reply-To: <xo42mWnM8O8-KsosrLsJwo2hR0ZuvrwlDfq9VUAA4nM=.c67cc391-6cd1-483e-bd24-4009605553af@github.com>
References: <xo42mWnM8O8-KsosrLsJwo2hR0ZuvrwlDfq9VUAA4nM=.c67cc391-6cd1-483e-bd24-4009605553af@github.com>
Message-ID: <CE8R0ay5Nc7Qx8pc9-GWtG6B8wi8-UjG_DPcPhTiphY=.c592b093-811b-4ca8-9707-4abfe95cab51@github.com>

On Sat, 18 Feb 2023 23:26:08 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> When encoding Strings to US-ASCII we can speed up the happy path significantly by using `StringCoding.countPositives` as a speculative check for whether there are any chars that needs to be replaced by `'?'`. Once a non-ASCII char is encountered we fall back to the slow loop and replace as needed.
> 
> An alternative could be unrolling or using a byte array VarHandle, as show-cased by Brett Okken here: https://mail.openjdk.org/pipermail/core-libs-dev/2023-February/100573.html Having to replace chars with `?` is essentially an encoding error so it might be safe to assume this case is exceptional in practice.

src/java.base/share/classes/java/lang/String.java line 976:

> 974:     private static byte[] encodeASCII(byte coder, byte[] val) {
> 975:         if (coder == LATIN1) {
> 976:             byte[] dst = Arrays.copyOf(val, val.length);

Given the tweaks in https://git.openjdk.org/jdk/pull/12613 should this use `val.clone()` (would skip the length check)

Suggestion:

            byte[] dst = val.clone();

src/java.base/share/classes/java/lang/String.java line 982:

> 980:                     if (dst[i] < 0) {
> 981:                         dst[i] = '?';
> 982:                     }

I'm curious if using countPositives (and vectorization) to scan forward would be valuable for long (mostly ASCII) strings or if the method call overhead/non-constant stride is not a win for shorter strings or heavily non-ascii inputs. 

Suggestion:

                for (int i = positives; i < dst.length; i = StringCoding.countPositives(dst, i + 1, dst.length - i);) {
                    if (dst[i] < 0) {
                        dst[i] = '?';
                    }

-------------

PR: https://git.openjdk.org/jdk/pull/12640

From redestad at openjdk.org  Mon Feb 20 11:55:17 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Mon, 20 Feb 2023 11:55:17 GMT
Subject: RFR: 8302863: Speed up String::encodeASCII using countPositives
In-Reply-To: <CE8R0ay5Nc7Qx8pc9-GWtG6B8wi8-UjG_DPcPhTiphY=.c592b093-811b-4ca8-9707-4abfe95cab51@github.com>
References: <xo42mWnM8O8-KsosrLsJwo2hR0ZuvrwlDfq9VUAA4nM=.c67cc391-6cd1-483e-bd24-4009605553af@github.com>
 <CE8R0ay5Nc7Qx8pc9-GWtG6B8wi8-UjG_DPcPhTiphY=.c592b093-811b-4ca8-9707-4abfe95cab51@github.com>
Message-ID: <l7-AC8E99f6a58CDGSI-fSVFClfC11kVFFZt2301aME=.75f57905-030e-48c3-8f4b-f012484f3da0@github.com>

On Sun, 19 Feb 2023 07:24:30 GMT, David Schlosnagle <duke at openjdk.org> wrote:

>> When encoding Strings to US-ASCII we can speed up the happy path significantly by using `StringCoding.countPositives` as a speculative check for whether there are any chars that needs to be replaced by `'?'`. Once a non-ASCII char is encountered we fall back to the slow loop and replace as needed.
>> 
>> An alternative could be unrolling or using a byte array VarHandle, as show-cased by Brett Okken here: https://mail.openjdk.org/pipermail/core-libs-dev/2023-February/100573.html Having to replace chars with `?` is essentially an encoding error so it might be safe to assume this case is exceptional in practice.
>
> src/java.base/share/classes/java/lang/String.java line 976:
> 
>> 974:     private static byte[] encodeASCII(byte coder, byte[] val) {
>> 975:         if (coder == LATIN1) {
>> 976:             byte[] dst = Arrays.copyOf(val, val.length);
> 
> Given the tweaks in https://git.openjdk.org/jdk/pull/12613 should this use `val.clone()` (would skip the length check)
> 
> Suggestion:
> 
>             byte[] dst = val.clone();

Yeah, probably makes sense. On that note I found that `val.clone()` underperform `Arrays.copyOf(val, val.length)` in C1 compiled code: https://bugs.openjdk.org/browse/JDK-8302850 - while this shouldn't affect peak performance it might be cause for a warmup regression.

> src/java.base/share/classes/java/lang/String.java line 982:
> 
>> 980:                     if (dst[i] < 0) {
>> 981:                         dst[i] = '?';
>> 982:                     }
> 
> I'm curious if using countPositives (and vectorization) to scan forward would be valuable for long (mostly ASCII) strings or if the method call overhead/non-constant stride is not a win for shorter strings or heavily non-ascii inputs. 
> 
> Suggestion:
> 
>                 for (int i = positives; i < dst.length; i = StringCoding.countPositives(dst, i + 1, dst.length - i);) {
>                     if (dst[i] < 0) {
>                         dst[i] = '?';
>                     }

There's some overhead doing countPositives calls, and doing it in a loop might provoke poor worst case performance. Im sure you can find inputs for which this is a win, though.

-------------

PR: https://git.openjdk.org/jdk/pull/12640

From redestad at openjdk.org  Mon Feb 20 11:59:22 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Mon, 20 Feb 2023 11:59:22 GMT
Subject: RFR: 8302863: Speed up String::encodeASCII using countPositives
In-Reply-To: <xo42mWnM8O8-KsosrLsJwo2hR0ZuvrwlDfq9VUAA4nM=.c67cc391-6cd1-483e-bd24-4009605553af@github.com>
References: <xo42mWnM8O8-KsosrLsJwo2hR0ZuvrwlDfq9VUAA4nM=.c67cc391-6cd1-483e-bd24-4009605553af@github.com>
Message-ID: <4Lcm1a5JJRJOFwl6MEIem7SZqh7tfOxzawn37JZy75Y=.fea8bde0-6b96-402e-b8a4-93b833edc117@github.com>

On Sat, 18 Feb 2023 23:26:08 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> When encoding Strings to US-ASCII we can speed up the happy path significantly by using `StringCoding.countPositives` as a speculative check for whether there are any chars that needs to be replaced by `'?'`. Once a non-ASCII char is encountered we fall back to the slow loop and replace as needed.
> 
> An alternative could be unrolling or using a byte array VarHandle, as show-cased by Brett Okken here: https://mail.openjdk.org/pipermail/core-libs-dev/2023-February/100573.html Having to replace chars with `?` is essentially an encoding error so it might be safe to assume this case is exceptional in practice.

Baseline:

Benchmark                      (charsetName)  Mode  Cnt      Score     Error  Units
StringEncode.encodeAsciiLong        US-ASCII  avgt    5  26626,025 ? 448,307  ns/op
StringEncode.encodeAsciiShort       US-ASCII  avgt    5     33,336 ?   2,032  ns/op


Patch:

Benchmark                      (charsetName)  Mode  Cnt     Score    Error  Units
StringEncode.encodeAsciiLong        US-ASCII  avgt    5  5492,985 ? 40,066  ns/op
StringEncode.encodeAsciiShort       US-ASCII  avgt    5    28,545 ?  4,883  ns/op

-------------

PR: https://git.openjdk.org/jdk/pull/12640

From duke at openjdk.org  Mon Feb 20 12:15:19 2023
From: duke at openjdk.org (Tingjun Yuan)
Date: Mon, 20 Feb 2023 12:15:19 GMT
Subject: RFR: 8302818: Optimize wrapper sets and immutable sets of Enums
Message-ID: <rpefqcimsLU_qQs5U_F1GSqdXJxD3YtqRLH7FEwN3hU=.aaf15809-464b-43a3-a1e2-758046d7bb52@github.com>

Currently, the two subclasses of `java.util.EnumSet` optimize bulk operations when the argument is also a `EnumSet`, but there is no such optimization for wrapper sets (returned by `Collections.unmodifiableSet`, `Collections.synchronizedSet`, etc.) and immutable sets (returned by `Set.of` methods) of `Enum`s.

This PR introduces optimization classes for these situations.  No public APIs are changed.

-------------

Commit messages:
 - add `import` in SetFactories.java
 - Fix typo
 - Update SetFactories.java
 - make configure not executable
 - Update Collections.java
 - Revert "Merge remote-tracking branch 'origin/optimize-enum-coll' into optimize-enum-coll"
 - Merge remote-tracking branch 'origin/optimize-enum-coll' into optimize-enum-coll
 - Check for unmodifiable sets in `unmodifiableSet`
 - fix error
 - add tests for Set.of factories
 - ... and 12 more: https://git.openjdk.org/jdk/compare/e4d1cff6...7f704c35

Changes: https://git.openjdk.org/jdk/pull/12498/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12498&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8302818
  Stats: 723 lines in 8 files changed: 674 ins; 0 del; 49 mod
  Patch: https://git.openjdk.org/jdk/pull/12498.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12498/head:pull/12498

PR: https://git.openjdk.org/jdk/pull/12498

From duke at openjdk.org  Mon Feb 20 12:15:32 2023
From: duke at openjdk.org (liach)
Date: Mon, 20 Feb 2023 12:15:32 GMT
Subject: RFR: 8302818: Optimize wrapper sets and immutable sets of Enums
In-Reply-To: <rpefqcimsLU_qQs5U_F1GSqdXJxD3YtqRLH7FEwN3hU=.aaf15809-464b-43a3-a1e2-758046d7bb52@github.com>
References: <rpefqcimsLU_qQs5U_F1GSqdXJxD3YtqRLH7FEwN3hU=.aaf15809-464b-43a3-a1e2-758046d7bb52@github.com>
Message-ID: <wXD0UTyqQgtU1WJSX8EU70H_2uYKwOK09Uqk2Ns_oPk=.a01791f6-c380-4827-b09f-1950f7d57b16@github.com>

On Thu, 9 Feb 2023 16:20:31 GMT, Tingjun Yuan <duke at openjdk.org> wrote:

> Currently, the two subclasses of `java.util.EnumSet` optimize bulk operations when the argument is also a `EnumSet`, but there is no such optimization for wrapper sets (returned by `Collections.unmodifiableSet`, `Collections.synchronizedSet`, etc.) and immutable sets (returned by `Set.of` methods) of `Enum`s.
> 
> This PR introduces optimization classes for these situations.  No public APIs are changed.

Just curious, how does this enum set change affect the performance of construction of regular sets via Set.of calls?

On the JBS there's https://bugs.openjdk.org/browse/JDK-8145048 which appears to fit your changes.

Just took a peek again. Besides the critical error of not throwing IAE for duplicate inputs (which you should probably add new test cases for), I think the 2 implementations share the same `toArray` `hashCode`, and the `contains` logic can be pulled to call an abstract `contains(int ordinal)` instead.

Have you submitted an issue at https://bugreport.java.com/bugreport/ ? It will show up a few days later on the JBS. If not, I can create an issue on the JBS for you too as long as you provide a prompt.

Created as https://bugs.openjdk.org/browse/JDK-8302818

I strongly recommend you to add tests of pure-enum and mixed-enum immutable set creation to ensure your code is logically correct. You seems to be developing the JDK in some weird way as you upload changes directly to GitHub Web UI.
I recommend developing according to the docs: see [IDE](https://github.com/openjdk/jdk/blob/master/doc/ide.md) and [building](https://github.com/openjdk/jdk/blob/master/doc/building.md) docs.

Also, try set your console's code page to 437 (US-ASCII), as some non-English consoles have caused build failures for me before. If you need help, you can leave this PR as a work in progress (so we don't spam the openjdk mailing lists) and I can answer your questions about the setup.

src/java.base/share/classes/java/util/Collections.java line 1153:

> 1151:             return (Set<T>) s;
> 1152:         }
> 1153:         if (s instanceof RegularEnumSetCompatible) {

Why not use `if (s instanceof RegularEnumSetCompatible es)` instead?

src/java.base/share/classes/java/util/Collections.java line 1194:

> 1192:         private static final long serialVersionUID = -1110577510253015312L;
> 1193: 
> 1194:         final RegularEnumSetCompatible<? extends E> es;

Can't you just use `<E>` as the type argument instead, for all occurrences? Can avoid a cast in `elementType()` too, and it's compatible argument to superclass constructor.

src/java.base/share/classes/java/util/Collections.java line 2409:

> 2407:         public long[] elements() {
> 2408:             synchronized (mutex) {
> 2409:                 return es.elements();

Is this really safe? `elements()` in `JumboEnumSet` returns the backing array, so this returned array is mutable. Should perform `es.elements().clone()` for more safety.

src/java.base/share/classes/java/util/ImmutableCollections.java line 904:

> 902:     @SuppressWarnings({"varargs", "unchecked", "rawtypes"})
> 903:     static <E> Set<E> setFromArray(E... input) {
> 904:         if (input.length == 0) {

This special case can be removed, as no caller calls with an array with length <= 2

src/java.base/share/classes/java/util/ImmutableCollections.java line 913:

> 911:         try {
> 912:             // Sorry, I have to use a raw type here.
> 913:             es = EnumSet.copyOf((Collection)Arrays.asList(input));  // rejects null

This fails to throw `IllegalArgumentException` on duplicated elements.

src/java.base/share/classes/java/util/ImmutableCollections.java line 1131:

> 1129:             long lastReturned = 0;
> 1130:             final Enum<?>[] universe
> 1131:                 = SharedSecrets.getJavaLangAccess().getEnumConstantsShared(elementType);

I think the convention is to put `SharedSecrets.getJavaLangAccess()` instance in a static final field like `JLA` than calling it every time

src/java.base/share/classes/java/util/ImmutableCollections.java line 1178:

> 1176:                 return (es.elements() & ~elements) == 0;
> 1177:             } else {
> 1178:                 for (Object o : c) {

Can just call super here

src/java.base/share/classes/java/util/JumboEnumSetCompatible.java line 38:

> 36:                 ImmutableCollections.ImmutableJumboEnumSet {
> 37:     Class<E> elementType();
> 38:     long[] elements();

Since long arrays are mutable (unlike the `long elements()` in regular set), might add a note about this, as enum sets never throws CMEs

-------------

PR: https://git.openjdk.org/jdk/pull/12498

From duke at openjdk.org  Mon Feb 20 12:15:34 2023
From: duke at openjdk.org (Tingjun Yuan)
Date: Mon, 20 Feb 2023 12:15:34 GMT
Subject: RFR: 8302818: Optimize wrapper sets and immutable sets of Enums
In-Reply-To: <wXD0UTyqQgtU1WJSX8EU70H_2uYKwOK09Uqk2Ns_oPk=.a01791f6-c380-4827-b09f-1950f7d57b16@github.com>
References: <rpefqcimsLU_qQs5U_F1GSqdXJxD3YtqRLH7FEwN3hU=.aaf15809-464b-43a3-a1e2-758046d7bb52@github.com>
 <wXD0UTyqQgtU1WJSX8EU70H_2uYKwOK09Uqk2Ns_oPk=.a01791f6-c380-4827-b09f-1950f7d57b16@github.com>
Message-ID: <9AMHoKIT62xRYMXc9xHpwNE7JEBz56-UrujSZCttkYo=.5aff623d-d4a1-4b12-82e6-dbdb88d4d363@github.com>

On Thu, 9 Feb 2023 19:37:03 GMT, liach <duke at openjdk.org> wrote:

> Just curious, how does this enum set change affect the performance of construction of regular sets via Set.of calls?

See `ImmutableCollections.setFromArray`, it relies on the fact that `EnumSet.copyOf` will throw a `ClassCastException` if the elements are not enum constants of a same enum class.  Trying to catch an exception is a bit expensive (so maybe I can optimize that).

> On the JBS there's https://bugs.openjdk.org/browse/JDK-8145048 which appears to fit your changes.

I only enhanced `EnumSet`, but not `EnumMap` (yet) so I don't think it fits my changes.

> Just took a peek again. Besides the critical error of not throwing IAE for duplicate inputs (which you should probably add new test cases for), I think the 2 implementations share the same `toArray` `hashCode`, and the `contains` logic can be pulled to call an abstract `contains(int ordinal)` instead.

@liach Thanks for reviewing. I've fixed the issues you've mentioned.

> Have you submitted an issue at https://bugreport.java.com/bugreport/ ? It will show up a few days later on the JBS. If not, I can create an issue on the JBS for you too as long as you provide a prompt.

No I haven't. Submit one for me please. Thanks!

-------------

PR: https://git.openjdk.org/jdk/pull/12498

From duke at openjdk.org  Mon Feb 20 12:15:34 2023
From: duke at openjdk.org (Tingjun Yuan)
Date: Mon, 20 Feb 2023 12:15:34 GMT
Subject: RFR: 8302818: Optimize wrapper sets and immutable sets of Enums
In-Reply-To: <rpefqcimsLU_qQs5U_F1GSqdXJxD3YtqRLH7FEwN3hU=.aaf15809-464b-43a3-a1e2-758046d7bb52@github.com>
References: <rpefqcimsLU_qQs5U_F1GSqdXJxD3YtqRLH7FEwN3hU=.aaf15809-464b-43a3-a1e2-758046d7bb52@github.com>
Message-ID: <wC_jOqHGMaRubCPt3IgyP4vj81uh8GyXpbWbw4g8vU8=.5a4305b2-2243-411e-aff7-bae7bc1da9fd@github.com>

On Thu, 9 Feb 2023 16:20:31 GMT, Tingjun Yuan <duke at openjdk.org> wrote:

> Currently, the two subclasses of `java.util.EnumSet` optimize bulk operations when the argument is also a `EnumSet`, but there is no such optimization for wrapper sets (returned by `Collections.unmodifiableSet`, `Collections.synchronizedSet`, etc.) and immutable sets (returned by `Set.of` methods) of `Enum`s.
> 
> This PR introduces optimization classes for these situations.  No public APIs are changed.

Oops, my bad. Please ignore the merge warning.

I've just add several tests for `Set.of` factories.

By the way, I've just built the JDK successfully on my Mac, and the tests run successfully too. Let me know if it fails on other operating systems.

-------------

PR: https://git.openjdk.org/jdk/pull/12498

From duke at openjdk.org  Mon Feb 20 12:15:36 2023
From: duke at openjdk.org (ExE Boss)
Date: Mon, 20 Feb 2023 12:15:36 GMT
Subject: RFR: 8302818: Optimize wrapper sets and immutable sets of Enums
In-Reply-To: <rpefqcimsLU_qQs5U_F1GSqdXJxD3YtqRLH7FEwN3hU=.aaf15809-464b-43a3-a1e2-758046d7bb52@github.com>
References: <rpefqcimsLU_qQs5U_F1GSqdXJxD3YtqRLH7FEwN3hU=.aaf15809-464b-43a3-a1e2-758046d7bb52@github.com>
Message-ID: <XYir3DDKrqZ3t_ioZ6nbf4WNfgL7Y7F5KE6eHbDbpjY=.b8218f80-05fe-4ebd-b34a-a7669bfd42cf@github.com>

On Thu, 9 Feb 2023 16:20:31 GMT, Tingjun Yuan <duke at openjdk.org> wrote:

> Currently, the two subclasses of `java.util.EnumSet` optimize bulk operations when the argument is also a `EnumSet`, but there is no such optimization for wrapper sets (returned by `Collections.unmodifiableSet`, `Collections.synchronizedSet`, etc.) and immutable sets (returned by `Set.of` methods) of `Enum`s.
> 
> This PR introduces optimization classes for these situations.  No public APIs are changed.

src/java.base/share/classes/java/util/Collections.java line 1152:

> 1150:         if (s.getClass() == UnmodifiableSet.class) {
> 1151:             return (Set<T>) s;
> 1152:         }

To?avoid re?wrapping already?unmodifiable `EnumSet`s, this?should also?check for?those:
Suggestion:

        if (s.getClass() == UnmodifiableSet.class
            || s.getClass() == UnmodifiableRegularEnumSet.class
            || s.getClass() == UnmodifiableJumboEnumSet.class) {
            return (Set<T>) s;
        }

src/java.base/share/classes/java/util/Collections.java line 1158:

> 1156:         if (s instanceof JumboEnumSetCompatible) {
> 1157:             return (Set<T>)new UnmodifiableJumboEnumSet<>((JumboEnumSetCompatible<?>)s);
> 1158:         }

Suggestion:

        if (s.getClass() == UnmodifiableSet.class
            || s.getClass() == UnmodifiableRegularEnumSet.class
            || s.getClass() == UnmodifiableJumboEnumSet.class) {
            return (Set<T>) s;
        }
        if (s instanceof RegularEnumSetCompatible<?> es) {
            return (Set<T>) new UnmodifiableRegularEnumSet<>(es);
        }
        if (s instanceof JumboEnumSetCompatible<?> es) {
            return (Set<T>) new UnmodifiableJumboEnumSet<>(es);
        }

-------------

PR: https://git.openjdk.org/jdk/pull/12498

From claes.redestad at oracle.com  Mon Feb 20 12:56:44 2023
From: claes.redestad at oracle.com (Claes Redestad)
Date: Mon, 20 Feb 2023 12:56:44 +0000
Subject: Speed up StringLatin1.regionMatchesCI_UTF16
In-Reply-To: <CA+pBWhtYAn0o4AXYyseurZnCo579YFj7CEQ=YgqBHwqqRLXBQA@mail.gmail.com>
References: <CA+pBWhtYAn0o4AXYyseurZnCo579YFj7CEQ=YgqBHwqqRLXBQA@mail.gmail.com>
Message-ID: <FB883E94-85E7-4EEB-8980-270F7962F4E9@oracle.com>

RFE filed: https://bugs.openjdk.org/browse/JDK-8302872

/Claes

18 feb. 2023 kl. 19:58 skrev Eirik Bj?rsn?s <eirbjo at gmail.com<mailto:eirbjo at gmail.com>>:

Hi,

This PR continues the effort to speed up case-insensitive string comparisons, this time tackling comparison of latin1-coded strings with utf16-coded strings:

https://github.com/openjdk/jdk/pull/12637

This builds on top of #12632, it makes sense to review that one first.

Thanks,
Eirik.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20230220/eb491272/attachment.htm>

From claes.redestad at oracle.com  Mon Feb 20 12:57:16 2023
From: claes.redestad at oracle.com (Claes Redestad)
Date: Mon, 20 Feb 2023 12:57:16 +0000
Subject: Speed up StringLatin1.regionMatchesCI
In-Reply-To: <CA+pBWhtuquRjf03DjCgCrwzDuvgincRRgAFPU3J=HK+XUt2-nw@mail.gmail.com>
References: <CA+pBWhtuquRjf03DjCgCrwzDuvgincRRgAFPU3J=HK+XUt2-nw@mail.gmail.com>
Message-ID: <3A4EE15A-A9F7-4539-9D16-209B6E127FCB@oracle.com>

RFE filed: https://bugs.openjdk.org/browse/JDK-8302871

/Claes

18 feb. 2023 kl. 10:28 skrev Eirik Bj?rsn?s <eirbjo at gmail.com<mailto:eirbjo at gmail.com>>:

Hi,

The following PR suggests we can speed up StringLatin1.regionMatchesCI by applying 'the oldest ASCII trick in the book':

https://github.com/openjdk/jdk/pull/12632

Thanks,
Eirik.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20230220/08d7b7ea/attachment-0001.htm>

From duke at openjdk.org  Mon Feb 20 13:12:25 2023
From: duke at openjdk.org (liach)
Date: Mon, 20 Feb 2023 13:12:25 GMT
Subject: RFR: 8302822:
 Method/Field/Constructor/RecordComponent::getGenericInfo() is not thread safe
In-Reply-To: <1sDlqlKVNOobyFy71f7ud5uL8_WcMPi1qKNa4ltxFQ0=.63cffbd7-e11a-4d7d-9362-cf215a7584ce@github.com>
References: <1sDlqlKVNOobyFy71f7ud5uL8_WcMPi1qKNa4ltxFQ0=.63cffbd7-e11a-4d7d-9362-cf215a7584ce@github.com>
Message-ID: <aiC6MkXHICLXZPGIidwhW-iOf2Rrl2vOwuNAzEGmix4=.42794134-5feb-43e8-ad7d-73d4c6e23def@github.com>

On Sun, 19 Feb 2023 18:41:18 GMT, liach <duke at openjdk.org> wrote:

> 8302822: Method/Field/Constructor/RecordComponent::getGenericInfo() is not thread safe

We don't fear calling the factory twice for benign races, as the distinct constructor factory instances are behaviorally the same.

The true issue lies in the double getfield operations: Java memory model doesn't require the second read to happen-after a write reflected in the first read, so return this.genericInfo may return null while this.genericInfo == null evaluates to false, in case genericInfo is initialized lazily by another thread. See https://bugs.openjdk.org/browse/JDK-8261404

-------------

PR: https://git.openjdk.org/jdk/pull/12643

From duke at openjdk.org  Mon Feb 20 13:15:03 2023
From: duke at openjdk.org (Tingjun Yuan)
Date: Mon, 20 Feb 2023 13:15:03 GMT
Subject: RFR: 8302818: Optimize wrapper sets and immutable sets of Enums
 [v2]
In-Reply-To: <rpefqcimsLU_qQs5U_F1GSqdXJxD3YtqRLH7FEwN3hU=.aaf15809-464b-43a3-a1e2-758046d7bb52@github.com>
References: <rpefqcimsLU_qQs5U_F1GSqdXJxD3YtqRLH7FEwN3hU=.aaf15809-464b-43a3-a1e2-758046d7bb52@github.com>
Message-ID: <_AbiJ6bjgtuxycI3srvPEhjeYOa_HNwCXgytEsgTETU=.88151cee-12dc-44d8-b748-2cf82ff9b9c4@github.com>

> Currently, the two subclasses of `java.util.EnumSet` optimize bulk operations when the argument is also a `EnumSet`, but there is no such optimization for wrapper sets (returned by `Collections.unmodifiableSet`, `Collections.synchronizedSet`, etc.) and immutable sets (returned by `Set.of` methods) of `Enum`s.
> 
> This PR introduces optimization classes for these situations.  No public APIs are changed.

Tingjun Yuan has updated the pull request incrementally with one additional commit since the last revision:

  Optimize `EnumSet.copyOf` and `Set.copyOf`

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12498/files
  - new: https://git.openjdk.org/jdk/pull/12498/files/7f704c35..41f4a909

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12498&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12498&range=00-01

  Stats: 27 lines in 2 files changed: 22 ins; 2 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/12498.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12498/head:pull/12498

PR: https://git.openjdk.org/jdk/pull/12498

From duke at openjdk.org  Mon Feb 20 13:19:16 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Mon, 20 Feb 2023 13:19:16 GMT
Subject: RFR: 8302871: Speed up StringLatin1.regionMatchesCI
Message-ID: <dnsiX3nRffjGjZXJG7lMAZj2FktEl2Wc1XfFthQ4iJs=.8c41438a-80a4-468f-ae0b-7322c9d6d952@github.com>

This PR suggests we can speed up `StringLatin1.regionMatchesCI` by applying 'the oldest ASCII trick in the book'.

The new static method `CharacterDataLatin1.equalsIgnoreCase` compares two latin1 bytes for equality ignoring case. `StringLatin1.regionMatchesCI` is updated to use `equalsIgnoreCase`

To verify the correctness of `equalsIgnoreCase`, a new test is added  to `EqualsIgnoreCase` with an exhaustive verification that all 256x256 latin1 code point pairs have an `equalsIgnoreCase` consistent with Character.toUpperCase, Character.toLowerCase.

Performance is tested for matching and mismatching cases of code point pairs picked from the ASCII letter, ASCII number and latin1 letter ranges. Results in the first comment below.

-------------

Commit messages:
 - Exhaustive verification needs to cover the case b1 == b2
 - Move multiplication exclusion to the lat1 range branch
 - Speed up StringLatin1.regionMatchesCI by applying the 'oldest ASCII trick in the book'

Changes: https://git.openjdk.org/jdk/pull/12632/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12632&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8302871
  Stats: 158 lines in 4 files changed: 148 ins; 5 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/12632.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12632/head:pull/12632

PR: https://git.openjdk.org/jdk/pull/12632

From duke at openjdk.org  Mon Feb 20 13:19:17 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Mon, 20 Feb 2023 13:19:17 GMT
Subject: RFR: 8302871: Speed up StringLatin1.regionMatchesCI
In-Reply-To: <dnsiX3nRffjGjZXJG7lMAZj2FktEl2Wc1XfFthQ4iJs=.8c41438a-80a4-468f-ae0b-7322c9d6d952@github.com>
References: <dnsiX3nRffjGjZXJG7lMAZj2FktEl2Wc1XfFthQ4iJs=.8c41438a-80a4-468f-ae0b-7322c9d6d952@github.com>
Message-ID: <JWx0OiFib9dJQhDyAqVnz6ErMrDGaLmGK0Fp9nUI25E=.6d174a6f-7eee-4bb7-809b-8438dad22b52@github.com>

On Sat, 18 Feb 2023 09:21:25 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

> This PR suggests we can speed up `StringLatin1.regionMatchesCI` by applying 'the oldest ASCII trick in the book'.
> 
> The new static method `CharacterDataLatin1.equalsIgnoreCase` compares two latin1 bytes for equality ignoring case. `StringLatin1.regionMatchesCI` is updated to use `equalsIgnoreCase`
> 
> To verify the correctness of `equalsIgnoreCase`, a new test is added  to `EqualsIgnoreCase` with an exhaustive verification that all 256x256 latin1 code point pairs have an `equalsIgnoreCase` consistent with Character.toUpperCase, Character.toLowerCase.
> 
> Performance is tested for matching and mismatching cases of code point pairs picked from the ASCII letter, ASCII number and latin1 letter ranges. Results in the first comment below.

Benchmark results:

Baseline:


Benchmark                                  (codePoints)  (size)  Mode  Cnt     Score    Error  Units
RegionMatchesIC.Latin1.regionMatchesIC      ascii-match    1024  avgt   15  2216.525 ? 79.626  ns/op
RegionMatchesIC.Latin1.regionMatchesIC   ascii-mismatch    1024  avgt   15     5.049 ?  0.044  ns/op
RegionMatchesIC.Latin1.regionMatchesIC     number-match    1024  avgt   15   708.977 ? 19.381  ns/op
RegionMatchesIC.Latin1.regionMatchesIC  number-mismatch    1024  avgt   15     3.726 ?  0.036  ns/op
RegionMatchesIC.Latin1.regionMatchesIC       lat1-match    1024  avgt   15  2134.499 ? 23.064  ns/op
RegionMatchesIC.Latin1.regionMatchesIC    lat1-mismatch    1024  avgt   15     4.227 ?  0.070  ns/op


Patch:


Benchmark                                  (codePoints)  (size)  Mode  Cnt     Score    Error  Units
RegionMatchesIC.Latin1.regionMatchesIC      ascii-match    1024  avgt   15   809.729 ? 40.257  ns/op
RegionMatchesIC.Latin1.regionMatchesIC   ascii-mismatch    1024  avgt   15     4.334 ?  0.031  ns/op
RegionMatchesIC.Latin1.regionMatchesIC     number-match    1024  avgt   15   370.814 ? 39.790  ns/op
RegionMatchesIC.Latin1.regionMatchesIC  number-mismatch    1024  avgt   15     3.766 ?  0.072  ns/op
RegionMatchesIC.Latin1.regionMatchesIC       lat1-match    1024  avgt   15  1247.979 ?  7.826  ns/op
RegionMatchesIC.Latin1.regionMatchesIC    lat1-mismatch    1024  avgt   15     4.819 ?  0.026  ns/op

-------------

PR: https://git.openjdk.org/jdk/pull/12632

From duke at openjdk.org  Mon Feb 20 13:19:30 2023
From: duke at openjdk.org (liach)
Date: Mon, 20 Feb 2023 13:19:30 GMT
Subject: RFR: 8302818: Optimize wrapper sets and immutable sets of Enums
 [v2]
In-Reply-To: <_AbiJ6bjgtuxycI3srvPEhjeYOa_HNwCXgytEsgTETU=.88151cee-12dc-44d8-b748-2cf82ff9b9c4@github.com>
References: <rpefqcimsLU_qQs5U_F1GSqdXJxD3YtqRLH7FEwN3hU=.aaf15809-464b-43a3-a1e2-758046d7bb52@github.com>
 <_AbiJ6bjgtuxycI3srvPEhjeYOa_HNwCXgytEsgTETU=.88151cee-12dc-44d8-b748-2cf82ff9b9c4@github.com>
Message-ID: <Pi_7SefGPgQmSkt-GkaUnHRbWhTgfnTw3gyqKnw2yxA=.93f8477f-22d7-472b-bb75-d7c68462a281@github.com>

On Mon, 20 Feb 2023 13:15:03 GMT, Tingjun Yuan <duke at openjdk.org> wrote:

>> Currently, the two subclasses of `java.util.EnumSet` optimize bulk operations when the argument is also a `EnumSet`, but there is no such optimization for wrapper sets (returned by `Collections.unmodifiableSet`, `Collections.synchronizedSet`, etc.) and immutable sets (returned by `Set.of` methods) of `Enum`s.
>> 
>> This PR introduces optimization classes for these situations.  No public APIs are changed.
>
> Tingjun Yuan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Optimize `EnumSet.copyOf` and `Set.copyOf`

src/java.base/share/classes/java/util/EnumSet.java line 186:

> 184:             } else {
> 185:                 while (i.hasNext())
> 186:                     result.add(i.next());

Can't we just use addAll in all cases?

src/java.base/share/classes/java/util/Set.java line 742:

> 740:         E e1 = it.next();
> 741:         if (!it.hasNext()) {
> 742:             return Set.of(e0, e1);

Bad change, doesn't handle e0.equals(e1), and this is getting beyond the original issue

-------------

PR: https://git.openjdk.org/jdk/pull/12498

From duke at openjdk.org  Mon Feb 20 13:19:20 2023
From: duke at openjdk.org (David Schlosnagle)
Date: Mon, 20 Feb 2023 13:19:20 GMT
Subject: RFR: 8302871: Speed up StringLatin1.regionMatchesCI
In-Reply-To: <dnsiX3nRffjGjZXJG7lMAZj2FktEl2Wc1XfFthQ4iJs=.8c41438a-80a4-468f-ae0b-7322c9d6d952@github.com>
References: <dnsiX3nRffjGjZXJG7lMAZj2FktEl2Wc1XfFthQ4iJs=.8c41438a-80a4-468f-ae0b-7322c9d6d952@github.com>
Message-ID: <Z6Wf3Xed8OBwOAfxXRe0_p3cB3IrfvGZp70MMscMBUc=.bc65bdf2-14db-4566-8822-52d74897bf1b@github.com>

On Sat, 18 Feb 2023 09:21:25 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

> This PR suggests we can speed up `StringLatin1.regionMatchesCI` by applying 'the oldest ASCII trick in the book'.
> 
> The new static method `CharacterDataLatin1.equalsIgnoreCase` compares two latin1 bytes for equality ignoring case. `StringLatin1.regionMatchesCI` is updated to use `equalsIgnoreCase`
> 
> To verify the correctness of `equalsIgnoreCase`, a new test is added  to `EqualsIgnoreCase` with an exhaustive verification that all 256x256 latin1 code point pairs have an `equalsIgnoreCase` consistent with Character.toUpperCase, Character.toLowerCase.
> 
> Performance is tested for matching and mismatching cases of code point pairs picked from the ASCII letter, ASCII number and latin1 letter ranges. Results in the first comment below.

src/java.base/share/classes/java/lang/CharacterDataLatin1.java.template line 181:

> 179:          return ( U <= 'Z' // In range A-Z
> 180:                  || (U >= 0xC0 && U <= 0XDE && U != 0xD7)) // ..or A-grave-Thorn, excl. multiplication
> 181:                  && U == (b2 & 0xDF); // b2 has same uppercase

I'm curious if the order of comparisons could alter performance to a small degree. For example, it might be interesting to compare various permutations like below to short circuit reject unequal uppercased b2

Suggestion:

         // uppercase b1 using 'the oldest ASCII trick in the book'
         int U = b1 & 0xDF;
         return (U == (b2 & 0xDF))
             && ((U >= 'A' && U <= 'Z') // In range A-Z
                 || (U >= 0xC0 && U <= 0XDE && U != 0xD7)) // ..or A-grave-Thorn, excl. multiplication

-------------

PR: https://git.openjdk.org/jdk/pull/12632

From duke at openjdk.org  Mon Feb 20 13:19:20 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Mon, 20 Feb 2023 13:19:20 GMT
Subject: RFR: 8302871: Speed up StringLatin1.regionMatchesCI
In-Reply-To: <Z6Wf3Xed8OBwOAfxXRe0_p3cB3IrfvGZp70MMscMBUc=.bc65bdf2-14db-4566-8822-52d74897bf1b@github.com>
References: <dnsiX3nRffjGjZXJG7lMAZj2FktEl2Wc1XfFthQ4iJs=.8c41438a-80a4-468f-ae0b-7322c9d6d952@github.com>
 <Z6Wf3Xed8OBwOAfxXRe0_p3cB3IrfvGZp70MMscMBUc=.bc65bdf2-14db-4566-8822-52d74897bf1b@github.com>
Message-ID: <_mGSxILQqWkEQ4oxqilr8A5FZ2eeu_3A34dZpjduXo0=.55145913-1c2f-4700-9713-81b09d387440@github.com>

On Sat, 18 Feb 2023 19:04:24 GMT, David Schlosnagle <duke at openjdk.org> wrote:

>> This PR suggests we can speed up `StringLatin1.regionMatchesCI` by applying 'the oldest ASCII trick in the book'.
>> 
>> The new static method `CharacterDataLatin1.equalsIgnoreCase` compares two latin1 bytes for equality ignoring case. `StringLatin1.regionMatchesCI` is updated to use `equalsIgnoreCase`
>> 
>> To verify the correctness of `equalsIgnoreCase`, a new test is added  to `EqualsIgnoreCase` with an exhaustive verification that all 256x256 latin1 code point pairs have an `equalsIgnoreCase` consistent with Character.toUpperCase, Character.toLowerCase.
>> 
>> Performance is tested for matching and mismatching cases of code point pairs picked from the ASCII letter, ASCII number and latin1 letter ranges. Results in the first comment below.
>
> src/java.base/share/classes/java/lang/CharacterDataLatin1.java.template line 181:
> 
>> 179:          return ( U <= 'Z' // In range A-Z
>> 180:                  || (U >= 0xC0 && U <= 0XDE && U != 0xD7)) // ..or A-grave-Thorn, excl. multiplication
>> 181:                  && U == (b2 & 0xDF); // b2 has same uppercase
> 
> I'm curious if the order of comparisons could alter performance to a small degree. For example, it might be interesting to compare various permutations like below to short circuit reject unequal uppercased b2
> 
> Suggestion:
> 
>          // uppercase b1 using 'the oldest ASCII trick in the book'
>          int U = b1 & 0xDF;
>          return (U == (b2 & 0xDF))
>              && ((U >= 'A' && U <= 'Z') // In range A-Z
>                  || (U >= 0xC0 && U <= 0XDE && U != 0xD7)) // ..or A-grave-Thorn, excl. multiplication

Yeah, as you noticed this code is tricky and sensitive to the order of operations. I did some quite extensive exploration before ending on the current structure. This particular one seems to improve rejection somewhat at the cost of matches.

Since rejection is relatively speaking already very fast, I think we should favour fast matching here.

Results:


enchmark                                  (codePoints)  (size)  Mode  Cnt     Score    Error  Units
RegionMatchesIC.Latin1.regionMatchesIC      ascii-match    1024  avgt   15   917.796 ? 20.285  ns/op
RegionMatchesIC.Latin1.regionMatchesIC   ascii-mismatch    1024  avgt   15     4.367 ?  0.348  ns/op
RegionMatchesIC.Latin1.regionMatchesIC     number-match    1024  avgt   15   399.656 ? 10.703  ns/op
RegionMatchesIC.Latin1.regionMatchesIC  number-mismatch    1024  avgt   15     4.361 ?  0.664  ns/op
RegionMatchesIC.Latin1.regionMatchesIC       lat1-match    1024  avgt   15  1384.443 ? 22.199  ns/op
RegionMatchesIC.Latin1.regionMatchesIC    lat1-mismatch    1024  avgt   15     4.119 ?  0.451  ns/op

-------------

PR: https://git.openjdk.org/jdk/pull/12632

From duke at openjdk.org  Mon Feb 20 13:19:21 2023
From: duke at openjdk.org (David Schlosnagle)
Date: Mon, 20 Feb 2023 13:19:21 GMT
Subject: RFR: 8302871: Speed up StringLatin1.regionMatchesCI
In-Reply-To: <_mGSxILQqWkEQ4oxqilr8A5FZ2eeu_3A34dZpjduXo0=.55145913-1c2f-4700-9713-81b09d387440@github.com>
References: <dnsiX3nRffjGjZXJG7lMAZj2FktEl2Wc1XfFthQ4iJs=.8c41438a-80a4-468f-ae0b-7322c9d6d952@github.com>
 <Z6Wf3Xed8OBwOAfxXRe0_p3cB3IrfvGZp70MMscMBUc=.bc65bdf2-14db-4566-8822-52d74897bf1b@github.com>
 <_mGSxILQqWkEQ4oxqilr8A5FZ2eeu_3A34dZpjduXo0=.55145913-1c2f-4700-9713-81b09d387440@github.com>
Message-ID: <3ybXhT9NAtZLE4znb2PntN0OlC_bB78F7hC3bRai3a8=.667ebc8b-556c-4725-8251-0606f9f32952@github.com>

On Sat, 18 Feb 2023 19:45:34 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/CharacterDataLatin1.java.template line 181:
>> 
>>> 179:          return ( U <= 'Z' // In range A-Z
>>> 180:                  || (U >= 0xC0 && U <= 0XDE && U != 0xD7)) // ..or A-grave-Thorn, excl. multiplication
>>> 181:                  && U == (b2 & 0xDF); // b2 has same uppercase
>> 
>> I'm curious if the order of comparisons could alter performance to a small degree. For example, it might be interesting to compare various permutations like below to short circuit reject unequal uppercased b2
>> 
>> Suggestion:
>> 
>>          // uppercase b1 using 'the oldest ASCII trick in the book'
>>          int U = b1 & 0xDF;
>>          return (U == (b2 & 0xDF))
>>              && ((U >= 'A' && U <= 'Z') // In range A-Z
>>                  || (U >= 0xC0 && U <= 0XDE && U != 0xD7)) // ..or A-grave-Thorn, excl. multiplication
>
> Yeah, as you noticed this code is tricky and sensitive to the order of operations. I did some quite extensive exploration before ending on the current structure. This particular one seems to improve rejection somewhat at the cost of matches.
> 
> Since rejection is relatively speaking already very fast, I think we should favour fast matching here.
> 
> Results:
> 
> 
> enchmark                                  (codePoints)  (size)  Mode  Cnt     Score    Error  Units
> RegionMatchesIC.Latin1.regionMatchesIC      ascii-match    1024  avgt   15   917.796 ? 20.285  ns/op
> RegionMatchesIC.Latin1.regionMatchesIC   ascii-mismatch    1024  avgt   15     4.367 ?  0.348  ns/op
> RegionMatchesIC.Latin1.regionMatchesIC     number-match    1024  avgt   15   399.656 ? 10.703  ns/op
> RegionMatchesIC.Latin1.regionMatchesIC  number-mismatch    1024  avgt   15     4.361 ?  0.664  ns/op
> RegionMatchesIC.Latin1.regionMatchesIC       lat1-match    1024  avgt   15  1384.443 ? 22.199  ns/op
> RegionMatchesIC.Latin1.regionMatchesIC    lat1-mismatch    1024  avgt   15     4.119 ?  0.451  ns/op

Thanks for confirming

-------------

PR: https://git.openjdk.org/jdk/pull/12632

From duke at openjdk.org  Mon Feb 20 13:27:29 2023
From: duke at openjdk.org (Tingjun Yuan)
Date: Mon, 20 Feb 2023 13:27:29 GMT
Subject: RFR: 8302818: Optimize wrapper sets and immutable sets of Enums
 [v2]
In-Reply-To: <Pi_7SefGPgQmSkt-GkaUnHRbWhTgfnTw3gyqKnw2yxA=.93f8477f-22d7-472b-bb75-d7c68462a281@github.com>
References: <rpefqcimsLU_qQs5U_F1GSqdXJxD3YtqRLH7FEwN3hU=.aaf15809-464b-43a3-a1e2-758046d7bb52@github.com>
 <_AbiJ6bjgtuxycI3srvPEhjeYOa_HNwCXgytEsgTETU=.88151cee-12dc-44d8-b748-2cf82ff9b9c4@github.com>
 <Pi_7SefGPgQmSkt-GkaUnHRbWhTgfnTw3gyqKnw2yxA=.93f8477f-22d7-472b-bb75-d7c68462a281@github.com>
Message-ID: <JeDCIS5QmTe0nJtbCxKAT8YGK4AZGzmA6GOfeggGxWE=.b66de09d-db80-433a-9a1b-2046570f833e@github.com>

On Mon, 20 Feb 2023 13:15:20 GMT, liach <duke at openjdk.org> wrote:

> Bad change, doesn't handle e0.equals(e1), and this is getting beyond the original issue

`Set.of(E, E)` handles duplication. If `coll` is `{Jumbo,Regular}EnumSetCompatible`, then we don't have to create the `HashSet`.

-------------

PR: https://git.openjdk.org/jdk/pull/12498

From duke at openjdk.org  Mon Feb 20 13:32:29 2023
From: duke at openjdk.org (Tingjun Yuan)
Date: Mon, 20 Feb 2023 13:32:29 GMT
Subject: RFR: 8302818: Optimize wrapper sets and immutable sets of Enums
 [v2]
In-Reply-To: <Pi_7SefGPgQmSkt-GkaUnHRbWhTgfnTw3gyqKnw2yxA=.93f8477f-22d7-472b-bb75-d7c68462a281@github.com>
References: <rpefqcimsLU_qQs5U_F1GSqdXJxD3YtqRLH7FEwN3hU=.aaf15809-464b-43a3-a1e2-758046d7bb52@github.com>
 <_AbiJ6bjgtuxycI3srvPEhjeYOa_HNwCXgytEsgTETU=.88151cee-12dc-44d8-b748-2cf82ff9b9c4@github.com>
 <Pi_7SefGPgQmSkt-GkaUnHRbWhTgfnTw3gyqKnw2yxA=.93f8477f-22d7-472b-bb75-d7c68462a281@github.com>
Message-ID: <Q16O2_rvjBF7apQxVl4GMa17VFe1zQWerwjeHiWp1dA=.14c98ebc-a1cc-4822-bde0-dca486b5f187@github.com>

On Mon, 20 Feb 2023 13:16:09 GMT, liach <duke at openjdk.org> wrote:

>> Tingjun Yuan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Optimize `EnumSet.copyOf` and `Set.copyOf`
>
> src/java.base/share/classes/java/util/EnumSet.java line 186:
> 
>> 184:             } else {
>> 185:                 while (i.hasNext())
>> 186:                     result.add(i.next());
> 
> Can't we just use addAll in all cases?

I wonder why the original code didn't use `addAll`, so I didn't change it. ?

-------------

PR: https://git.openjdk.org/jdk/pull/12498

From duke at openjdk.org  Mon Feb 20 13:39:09 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Mon, 20 Feb 2023 13:39:09 GMT
Subject: RFR: 8302871: Speed up StringLatin1.regionMatchesCI [v2]
In-Reply-To: <dnsiX3nRffjGjZXJG7lMAZj2FktEl2Wc1XfFthQ4iJs=.8c41438a-80a4-468f-ae0b-7322c9d6d952@github.com>
References: <dnsiX3nRffjGjZXJG7lMAZj2FktEl2Wc1XfFthQ4iJs=.8c41438a-80a4-468f-ae0b-7322c9d6d952@github.com>
Message-ID: <ilxA1VwMFjFLVPzNOLPMeAW7XSHxtbl-CQTsNI9MKBs=.329eca84-6e35-476e-894e-3e94fb7aab43@github.com>

> This PR suggests we can speed up `StringLatin1.regionMatchesCI` by applying 'the oldest ASCII trick in the book'.
> 
> The new static method `CharacterDataLatin1.equalsIgnoreCase` compares two latin1 bytes for equality ignoring case. `StringLatin1.regionMatchesCI` is updated to use `equalsIgnoreCase`
> 
> To verify the correctness of `equalsIgnoreCase`, a new test is added  to `EqualsIgnoreCase` with an exhaustive verification that all 256x256 latin1 code point pairs have an `equalsIgnoreCase` consistent with Character.toUpperCase, Character.toLowerCase.
> 
> Performance is tested for matching and mismatching cases of code point pairs picked from the ASCII letter, ASCII number and latin1 letter ranges. Results in the first comment below.

Eirik Bjorsnos 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:

 - Align whitespace to make example strings easier to read
 - Merge branch 'master' into regionmatches-latin1-speedup
 - Exhaustive verification needs to cover the case b1 == b2
 - Move multiplication exclusion to the lat1 range branch
 - Speed up StringLatin1.regionMatchesCI by applying the 'oldest ASCII trick in the book'

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12632/files
  - new: https://git.openjdk.org/jdk/pull/12632/files/a583bcd6..59c42298

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12632&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12632&range=00-01

  Stats: 57495 lines in 1316 files changed: 24512 ins; 15682 del; 17301 mod
  Patch: https://git.openjdk.org/jdk/pull/12632.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12632/head:pull/12632

PR: https://git.openjdk.org/jdk/pull/12632

From duke at openjdk.org  Mon Feb 20 13:43:01 2023
From: duke at openjdk.org (Tingjun Yuan)
Date: Mon, 20 Feb 2023 13:43:01 GMT
Subject: RFR: 8302818: Optimize wrapper sets and immutable sets of Enums
 [v3]
In-Reply-To: <rpefqcimsLU_qQs5U_F1GSqdXJxD3YtqRLH7FEwN3hU=.aaf15809-464b-43a3-a1e2-758046d7bb52@github.com>
References: <rpefqcimsLU_qQs5U_F1GSqdXJxD3YtqRLH7FEwN3hU=.aaf15809-464b-43a3-a1e2-758046d7bb52@github.com>
Message-ID: <4SnYa3ngIlTZf3dSheLbE3EkvZaq4FWa1fxXd7rgw-M=.6ffdb81e-930d-438a-9453-a30921745f29@github.com>

> Currently, the two subclasses of `java.util.EnumSet` optimize bulk operations when the argument is also a `EnumSet`, but there is no such optimization for wrapper sets (returned by `Collections.unmodifiableSet`, `Collections.synchronizedSet`, etc.) and immutable sets (returned by `Set.of` methods) of `Enum`s.
> 
> This PR introduces optimization classes for these situations.  No public APIs are changed.

Tingjun Yuan has updated the pull request incrementally with one additional commit since the last revision:

  Use `addAll` in `EnumSet.copyOf`
  
  It seems to be okay to use `addAll` in all cases.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12498/files
  - new: https://git.openjdk.org/jdk/pull/12498/files/41f4a909..098b3fff

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12498&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12498&range=01-02

  Stats: 6 lines in 1 file changed: 0 ins; 5 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/12498.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12498/head:pull/12498

PR: https://git.openjdk.org/jdk/pull/12498

From duke at openjdk.org  Mon Feb 20 13:43:01 2023
From: duke at openjdk.org (Tingjun Yuan)
Date: Mon, 20 Feb 2023 13:43:01 GMT
Subject: RFR: 8302818: Optimize wrapper sets and immutable sets of Enums
 [v2]
In-Reply-To: <Q16O2_rvjBF7apQxVl4GMa17VFe1zQWerwjeHiWp1dA=.14c98ebc-a1cc-4822-bde0-dca486b5f187@github.com>
References: <rpefqcimsLU_qQs5U_F1GSqdXJxD3YtqRLH7FEwN3hU=.aaf15809-464b-43a3-a1e2-758046d7bb52@github.com>
 <_AbiJ6bjgtuxycI3srvPEhjeYOa_HNwCXgytEsgTETU=.88151cee-12dc-44d8-b748-2cf82ff9b9c4@github.com>
 <Pi_7SefGPgQmSkt-GkaUnHRbWhTgfnTw3gyqKnw2yxA=.93f8477f-22d7-472b-bb75-d7c68462a281@github.com>
 <Q16O2_rvjBF7apQxVl4GMa17VFe1zQWerwjeHiWp1dA=.14c98ebc-a1cc-4822-bde0-dca486b5f187@github.com>
Message-ID: <lz36GJfAZM8QwDlmVNWtZwZxOkn9-iCbvf3Ke0IRB_0=.bedc1892-3547-4bb9-b963-94400f959cfc@github.com>

On Mon, 20 Feb 2023 13:29:52 GMT, Tingjun Yuan <duke at openjdk.org> wrote:

> I wonder why the original code didn't use `addAll`, so I didn't change it. ?

It seems to be okay to use `addAll` in all cases. Do we need extra test cases for this?

-------------

PR: https://git.openjdk.org/jdk/pull/12498

From duke at openjdk.org  Mon Feb 20 13:52:18 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Mon, 20 Feb 2023 13:52:18 GMT
Subject: RFR: 8302871: Speed up StringLatin1.regionMatchesCI [v3]
In-Reply-To: <dnsiX3nRffjGjZXJG7lMAZj2FktEl2Wc1XfFthQ4iJs=.8c41438a-80a4-468f-ae0b-7322c9d6d952@github.com>
References: <dnsiX3nRffjGjZXJG7lMAZj2FktEl2Wc1XfFthQ4iJs=.8c41438a-80a4-468f-ae0b-7322c9d6d952@github.com>
Message-ID: <KNC8BUrQ-eJazbuAC2m5Rh4SmmBFTA_WILTgGtlMGZo=.d6b8ab36-9d9b-4313-a348-14332286fcf7@github.com>

> This PR suggests we can speed up `StringLatin1.regionMatchesCI` by applying 'the oldest ASCII trick in the book'.
> 
> The new static method `CharacterDataLatin1.equalsIgnoreCase` compares two latin1 bytes for equality ignoring case. `StringLatin1.regionMatchesCI` is updated to use `equalsIgnoreCase`
> 
> To verify the correctness of `equalsIgnoreCase`, a new test is added  to `EqualsIgnoreCase` with an exhaustive verification that all 256x256 latin1 code point pairs have an `equalsIgnoreCase` consistent with Character.toUpperCase, Character.toLowerCase.
> 
> Performance is tested for matching and mismatching cases of code point pairs picked from the ASCII letter, ASCII number and latin1 letter ranges. Results in the first comment below.

Eirik Bjorsnos has updated the pull request incrementally with one additional commit since the last revision:

  Add clarifying comments and use more descriptive variable names in the latin1 verification EqualsIgnoreCase test

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12632/files
  - new: https://git.openjdk.org/jdk/pull/12632/files/59c42298..84517102

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12632&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12632&range=01-02

  Stats: 16 lines in 1 file changed: 5 ins; 2 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/12632.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12632/head:pull/12632

PR: https://git.openjdk.org/jdk/pull/12632

From duke at openjdk.org  Mon Feb 20 14:00:28 2023
From: duke at openjdk.org (liach)
Date: Mon, 20 Feb 2023 14:00:28 GMT
Subject: RFR: 8302818: Optimize wrapper sets and immutable sets of Enums
 [v2]
In-Reply-To: <JeDCIS5QmTe0nJtbCxKAT8YGK4AZGzmA6GOfeggGxWE=.b66de09d-db80-433a-9a1b-2046570f833e@github.com>
References: <rpefqcimsLU_qQs5U_F1GSqdXJxD3YtqRLH7FEwN3hU=.aaf15809-464b-43a3-a1e2-758046d7bb52@github.com>
 <_AbiJ6bjgtuxycI3srvPEhjeYOa_HNwCXgytEsgTETU=.88151cee-12dc-44d8-b748-2cf82ff9b9c4@github.com>
 <Pi_7SefGPgQmSkt-GkaUnHRbWhTgfnTw3gyqKnw2yxA=.93f8477f-22d7-472b-bb75-d7c68462a281@github.com>
 <JeDCIS5QmTe0nJtbCxKAT8YGK4AZGzmA6GOfeggGxWE=.b66de09d-db80-433a-9a1b-2046570f833e@github.com>
Message-ID: <b0hLzrprfrxS99PT3hvsNT4aW2lzlTtWNAE5vQVGilU=.7db86ac2-4374-4dcf-ae49-03842617ce1b@github.com>

On Mon, 20 Feb 2023 13:24:27 GMT, Tingjun Yuan <duke at openjdk.org> wrote:

>> src/java.base/share/classes/java/util/Set.java line 742:
>> 
>>> 740:         E e1 = it.next();
>>> 741:         if (!it.hasNext()) {
>>> 742:             return Set.of(e0, e1);
>> 
>> Bad change, doesn't handle e0.equals(e1), and this is getting beyond the original issue
>
>> Bad change, doesn't handle e0.equals(e1), and this is getting beyond the original issue
> 
> `Set.of(E, E)` handles duplication. If `coll` is `{Jumbo,Regular}EnumSetCompatible`, then we don't have to create the `HashSet`.

no, Set.copyOf explicitly allows duplications, unlike Set.of. You need to read the specs so you know what you are doing.

-------------

PR: https://git.openjdk.org/jdk/pull/12498

From claes.redestad at oracle.com  Mon Feb 20 14:03:27 2023
From: claes.redestad at oracle.com (Claes Redestad)
Date: Mon, 20 Feb 2023 14:03:27 +0000
Subject: Speed up latin1 case folding
In-Reply-To: <CA+pBWhs6e6hD=Vwb7LuS86kXM0fHTZXohXUBLLaUmap_Crt3jg@mail.gmail.com>
References: <CA+pBWhs6e6hD=Vwb7LuS86kXM0fHTZXohXUBLLaUmap_Crt3jg@mail.gmail.com>
Message-ID: <99DFEDBD-E7A8-4C21-BA9F-8610301C0332@oracle.com>

RFE filed: https://bugs.openjdk.org/browse/JDK-8302877

/Claes

17 feb. 2023 kl. 18:38 skrev Eirik Bj?rsn?s <eirbjo at gmail.com<mailto:eirbjo at gmail.com>>:

Hi,

The following PR suggests we can speed up Character.toUpperCase and Character.toLowerCase for latin1 code points by applying 'the oldest ASCII trick in the book':

https://github.com/openjdk/jdk/pull/12623

Thanks,
Eirik.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20230220/0d32e689/attachment-0001.htm>

From duke at openjdk.org  Mon Feb 20 14:07:00 2023
From: duke at openjdk.org (Tingjun Yuan)
Date: Mon, 20 Feb 2023 14:07:00 GMT
Subject: RFR: 8302818: Optimize wrapper sets and immutable sets of Enums
 [v2]
In-Reply-To: <b0hLzrprfrxS99PT3hvsNT4aW2lzlTtWNAE5vQVGilU=.7db86ac2-4374-4dcf-ae49-03842617ce1b@github.com>
References: <rpefqcimsLU_qQs5U_F1GSqdXJxD3YtqRLH7FEwN3hU=.aaf15809-464b-43a3-a1e2-758046d7bb52@github.com>
 <_AbiJ6bjgtuxycI3srvPEhjeYOa_HNwCXgytEsgTETU=.88151cee-12dc-44d8-b748-2cf82ff9b9c4@github.com>
 <Pi_7SefGPgQmSkt-GkaUnHRbWhTgfnTw3gyqKnw2yxA=.93f8477f-22d7-472b-bb75-d7c68462a281@github.com>
 <JeDCIS5QmTe0nJtbCxKAT8YGK4AZGzmA6GOfeggGxWE=.b66de09d-db80-433a-9a1b-2046570f833e@github.com>
 <b0hLzrprfrxS99PT3hvsNT4aW2lzlTtWNAE5vQVGilU=.7db86ac2-4374-4dcf-ae49-03842617ce1b@github.com>
Message-ID: <b0QINRor4XxF66Y80IEoPgAJqL6p3JOrIeo8VcvzOT8=.93172adc-3b63-48c8-a094-2c0e611644aa@github.com>

On Mon, 20 Feb 2023 13:58:01 GMT, liach <duke at openjdk.org> wrote:

> no, Set.copyOf explicitly allows duplications, unlike Set.of. You need to read the specs so you know what you are doing.

Sorry, my bad. I've fixed that.

-------------

PR: https://git.openjdk.org/jdk/pull/12498

From duke at openjdk.org  Mon Feb 20 14:06:58 2023
From: duke at openjdk.org (Tingjun Yuan)
Date: Mon, 20 Feb 2023 14:06:58 GMT
Subject: RFR: 8302818: Optimize wrapper sets and immutable sets of Enums
 [v4]
In-Reply-To: <rpefqcimsLU_qQs5U_F1GSqdXJxD3YtqRLH7FEwN3hU=.aaf15809-464b-43a3-a1e2-758046d7bb52@github.com>
References: <rpefqcimsLU_qQs5U_F1GSqdXJxD3YtqRLH7FEwN3hU=.aaf15809-464b-43a3-a1e2-758046d7bb52@github.com>
Message-ID: <uKJCtQoZhEvtntaQkqPN9MjYwvHQmgUt5xy7tmhjLrA=.4b3734d2-204b-46a1-a70d-28b9d73ae70c@github.com>

> Currently, the two subclasses of `java.util.EnumSet` optimize bulk operations when the argument is also a `EnumSet`, but there is no such optimization for wrapper sets (returned by `Collections.unmodifiableSet`, `Collections.synchronizedSet`, etc.) and immutable sets (returned by `Set.of` methods) of `Enum`s.
> 
> This PR introduces optimization classes for these situations.  No public APIs are changed.

Tingjun Yuan has updated the pull request incrementally with one additional commit since the last revision:

  Fix `Set.copyOf`

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12498/files
  - new: https://git.openjdk.org/jdk/pull/12498/files/098b3fff..b9699bfe

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12498&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12498&range=02-03

  Stats: 12 lines in 1 file changed: 0 ins; 9 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/12498.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12498/head:pull/12498

PR: https://git.openjdk.org/jdk/pull/12498

From duke at openjdk.org  Mon Feb 20 14:45:09 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Mon, 20 Feb 2023 14:45:09 GMT
Subject: RFR: 8302871: Speed up StringLatin1.regionMatchesCI [v4]
In-Reply-To: <dnsiX3nRffjGjZXJG7lMAZj2FktEl2Wc1XfFthQ4iJs=.8c41438a-80a4-468f-ae0b-7322c9d6d952@github.com>
References: <dnsiX3nRffjGjZXJG7lMAZj2FktEl2Wc1XfFthQ4iJs=.8c41438a-80a4-468f-ae0b-7322c9d6d952@github.com>
Message-ID: <fRAZdIQEidu2hYiazk0b0ePDVe_h2Drf5QHfXb7FfTM=.e04bdb59-dfc8-4cd5-9008-b41fdda7c451@github.com>

> This PR suggests we can speed up `StringLatin1.regionMatchesCI` by applying 'the oldest ASCII trick in the book'.
> 
> The new static method `CharacterDataLatin1.equalsIgnoreCase` compares two latin1 bytes for equality ignoring case. `StringLatin1.regionMatchesCI` is updated to use `equalsIgnoreCase`
> 
> To verify the correctness of `equalsIgnoreCase`, a new test is added  to `EqualsIgnoreCase` with an exhaustive verification that all 256x256 latin1 code point pairs have an `equalsIgnoreCase` consistent with Character.toUpperCase, Character.toLowerCase.
> 
> Performance is tested for matching and mismatching cases of code point pairs picked from the ASCII letter, ASCII number and latin1 letter ranges. Results in the first comment below.

Eirik Bjorsnos has updated the pull request incrementally with two additional commits since the last revision:

 - Add @bug tag to EqualsIgnoreCase test for correct issue JDK-8302871
 - Add @bug tag to EqualsIgnoreCase test for JDK-8302877

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12632/files
  - new: https://git.openjdk.org/jdk/pull/12632/files/84517102..03d3e2cb

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12632&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12632&range=02-03

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/12632.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12632/head:pull/12632

PR: https://git.openjdk.org/jdk/pull/12632

From duke at openjdk.org  Mon Feb 20 14:47:33 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Mon, 20 Feb 2023 14:47:33 GMT
Subject: RFR: 8302877: Speed up latin1 case conversions
Message-ID: <cf9hc-SBdgzB1lpqXGLHKcjT4-T9hLaMs1cCccqBiak=.f7b99e9d-3206-4e67-976f-ea0492ec6b06@github.com>

This PR suggests we speed up Character.toUpperCase and Character.toLowerCase for latin1 code points by applying the 'oldest ASCII trick in the book'.

This takes advantage of the fact that latin1 uppercase code points are always 0x20 lower than their lowercase (with the exception of two code points which uppercase out of latin1).

To verify the correctness of the new implementation, the test `Latin1CaseConversion` is added with an exhaustive verification of toUpperCase/toLowerCase for all latin1 code points.

The implementation needs to balance the performance of the various ranges in latin1. An effort has been made to favour operations on ASCII code points, without causing excessive regression for higher code points.

Performance is benchmarked for 7 chosen sample code points, each representing a range or a special-case.  Results in the first comment.

-------------

Commit messages:
 - Add @bug tag to test
 - Improved whitespace alignment for Param and switch values
 - Correct spelling for "exhaustive"
 - Prefer the term "case conversion" over ""case folding". Refer to 0xB5 as 'Micro Sign' ("Mu" is the Unicode code point it uppercases to)
 - Improve comments for the two special-cased uppercase code points 'Micro Sign' and 'y with Diaeresis'
 - Adjust whitespace
 - Speed up Character.toUpperCase and Character.toLowerCase by applying the 'oldest ASCII trick in the book'

Changes: https://git.openjdk.org/jdk/pull/12623/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12623&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8302877
  Stats: 164 lines in 3 files changed: 143 ins; 0 del; 21 mod
  Patch: https://git.openjdk.org/jdk/pull/12623.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12623/head:pull/12623

PR: https://git.openjdk.org/jdk/pull/12623

From naoto at openjdk.org  Mon Feb 20 14:47:36 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 20 Feb 2023 14:47:36 GMT
Subject: RFR: 8302877: Speed up latin1 case conversions
In-Reply-To: <cf9hc-SBdgzB1lpqXGLHKcjT4-T9hLaMs1cCccqBiak=.f7b99e9d-3206-4e67-976f-ea0492ec6b06@github.com>
References: <cf9hc-SBdgzB1lpqXGLHKcjT4-T9hLaMs1cCccqBiak=.f7b99e9d-3206-4e67-976f-ea0492ec6b06@github.com>
Message-ID: <CgKt3Q0k0hCkg4xxCRBOPDX6fi-zQWxuHX0zoKT3Pio=.af2d552c-dbfe-4acc-a738-94e2e6c3b25d@github.com>

On Fri, 17 Feb 2023 17:31:09 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

> This PR suggests we speed up Character.toUpperCase and Character.toLowerCase for latin1 code points by applying the 'oldest ASCII trick in the book'.
> 
> This takes advantage of the fact that latin1 uppercase code points are always 0x20 lower than their lowercase (with the exception of two code points which uppercase out of latin1).
> 
> To verify the correctness of the new implementation, the test `Latin1CaseConversion` is added with an exhaustive verification of toUpperCase/toLowerCase for all latin1 code points.
> 
> The implementation needs to balance the performance of the various ranges in latin1. An effort has been made to favour operations on ASCII code points, without causing excessive regression for higher code points.
> 
> Performance is benchmarked for 7 chosen sample code points, each representing a range or a special-case.  Results in the first comment.

Looks good to me. I'd rather not use "case folding", as to me it implies "normalizing" but this is simply lowercasing/uppercasing.

test/jdk/java/lang/Character/Latin1CaseFolding.java line 31:

> 29: /**
> 30:  * @test
> 31:  * @summary Provides exchaustive verification of Character.toUpperCase and Character.toLowerCase

typo: "exhaustive"?

-------------

PR: https://git.openjdk.org/jdk/pull/12623

From duke at openjdk.org  Mon Feb 20 14:47:37 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Mon, 20 Feb 2023 14:47:37 GMT
Subject: RFR: 8302877: Speed up latin1 case conversions
In-Reply-To: <cf9hc-SBdgzB1lpqXGLHKcjT4-T9hLaMs1cCccqBiak=.f7b99e9d-3206-4e67-976f-ea0492ec6b06@github.com>
References: <cf9hc-SBdgzB1lpqXGLHKcjT4-T9hLaMs1cCccqBiak=.f7b99e9d-3206-4e67-976f-ea0492ec6b06@github.com>
Message-ID: <hktDVAh_HYJ3M0K4HuX8vQYrdtlufQ6AssH3dOLvx60=.93ed8116-14a8-4ada-a5ca-983ee5e1d838@github.com>

On Fri, 17 Feb 2023 17:31:09 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

> This PR suggests we speed up Character.toUpperCase and Character.toLowerCase for latin1 code points by applying the 'oldest ASCII trick in the book'.
> 
> This takes advantage of the fact that latin1 uppercase code points are always 0x20 lower than their lowercase (with the exception of two code points which uppercase out of latin1).
> 
> To verify the correctness of the new implementation, the test `Latin1CaseConversion` is added with an exhaustive verification of toUpperCase/toLowerCase for all latin1 code points.
> 
> The implementation needs to balance the performance of the various ranges in latin1. An effort has been made to favour operations on ASCII code points, without causing excessive regression for higher code points.
> 
> Performance is benchmarked for 7 chosen sample code points, each representing a range or a special-case.  Results in the first comment.

Benchmark results:

Baseline:


Benchmark                                 (codePoint)  Mode  Cnt  Score   Error  Units
Characters.Latin1CaseConversion.toLowerCase          low  avgt   15  1.267 ? 0.013  ns/op
Characters.Latin1CaseConversion.toLowerCase            A  avgt   15  1.657 ? 0.011  ns/op
Characters.Latin1CaseConversion.toLowerCase            a  avgt   15  1.258 ? 0.005  ns/op
Characters.Latin1CaseConversion.toLowerCase      A-grave  avgt   15  1.656 ? 0.011  ns/op
Characters.Latin1CaseConversion.toLowerCase      a-grave  avgt   15  1.270 ? 0.023  ns/op
Characters.Latin1CaseConversion.toLowerCase           mu  avgt   15  1.261 ? 0.006  ns/op
Characters.Latin1CaseConversion.toLowerCase           yD  avgt   15  1.260 ? 0.005  ns/op
Characters.Latin1CaseConversion.toUpperCase          low  avgt   15  1.284 ? 0.043  ns/op
Characters.Latin1CaseConversion.toUpperCase            A  avgt   15  1.264 ? 0.008  ns/op
Characters.Latin1CaseConversion.toUpperCase            a  avgt   15  1.818 ? 0.016  ns/op
Characters.Latin1CaseConversion.toUpperCase      A-grave  avgt   15  1.261 ? 0.015  ns/op
Characters.Latin1CaseConversion.toUpperCase      a-grave  avgt   15  1.822 ? 0.013  ns/op
Characters.Latin1CaseConversion.toUpperCase           mu  avgt   15  1.823 ? 0.006  ns/op
Characters.Latin1CaseConversion.toUpperCase           yD  avgt   15  1.822 ? 0.008  ns/op


PR:


Benchmark                                 (codePoint)  Mode  Cnt  Score   Error  Units
Characters.Latin1CaseConversion.toLowerCase          low  avgt   15  0.878 ? 0.005  ns/op
Characters.Latin1CaseConversion.toLowerCase            A  avgt   15  1.038 ? 0.009  ns/op
Characters.Latin1CaseConversion.toLowerCase            a  avgt   15  1.036 ? 0.007  ns/op
Characters.Latin1CaseConversion.toLowerCase      A-grave  avgt   15  1.357 ? 0.015  ns/op
Characters.Latin1CaseConversion.toLowerCase      a-grave  avgt   15  1.352 ? 0.003  ns/op
Characters.Latin1CaseConversion.toLowerCase           mu  avgt   15  1.273 ? 0.002  ns/op
Characters.Latin1CaseConversion.toLowerCase           yD  avgt   15  1.352 ? 0.004  ns/op
Characters.Latin1CaseConversion.toUpperCase          low  avgt   15  0.880 ? 0.013  ns/op
Characters.Latin1CaseConversion.toUpperCase            A  avgt   15  0.920 ? 0.071  ns/op
Characters.Latin1CaseConversion.toUpperCase            a  avgt   15  1.055 ? 0.013  ns/op
Characters.Latin1CaseConversion.toUpperCase      A-grave  avgt   15  1.394 ? 0.010  ns/op
Characters.Latin1CaseConversion.toUpperCase      a-grave  avgt   15  1.391 ? 0.009  ns/op
Characters.Latin1CaseConversion.toUpperCase           mu  avgt   15  1.597 ? 0.021  ns/op
Characters.Latin1CaseConversion.toUpperCase           yD  avgt   15  1.354 ? 0.003  ns/op

-------------

PR: https://git.openjdk.org/jdk/pull/12623

From duke at openjdk.org  Mon Feb 20 14:47:39 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Mon, 20 Feb 2023 14:47:39 GMT
Subject: RFR: 8302877: Speed up latin1 case conversions
In-Reply-To: <CgKt3Q0k0hCkg4xxCRBOPDX6fi-zQWxuHX0zoKT3Pio=.af2d552c-dbfe-4acc-a738-94e2e6c3b25d@github.com>
References: <cf9hc-SBdgzB1lpqXGLHKcjT4-T9hLaMs1cCccqBiak=.f7b99e9d-3206-4e67-976f-ea0492ec6b06@github.com>
 <CgKt3Q0k0hCkg4xxCRBOPDX6fi-zQWxuHX0zoKT3Pio=.af2d552c-dbfe-4acc-a738-94e2e6c3b25d@github.com>
Message-ID: <Q1CJmrbsLmHneQMQDvFuSnHwlaFwzs_4FQSgw5Woc7U=.ce74d4ee-941e-40ec-8cd5-7d1d5d0c0b81@github.com>

On Sat, 18 Feb 2023 00:57:14 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>  I'd rather not use "case folding", as to me it implies "normalizing" but this is simply lowercasing/uppercasing.

I guess I was looking for a generic term for uppercase/lowercase. I picked "case conversion" instead.

> test/jdk/java/lang/Character/Latin1CaseFolding.java line 31:
> 
>> 29: /**
>> 30:  * @test
>> 31:  * @summary Provides exchaustive verification of Character.toUpperCase and Character.toLowerCase
> 
> typo: "exhaustive"?

I did an 'exchaustive' search for 'exchaustive' across the code base and found  two comments in `LocaleData` and `LocaleData.cldr` in `jdk/test/jdk/sun/text/resources`.

Would you like me to update these as well while we're here, or should we avoid getting out scope for this PR?

-------------

PR: https://git.openjdk.org/jdk/pull/12623

From redestad at openjdk.org  Mon Feb 20 15:43:28 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Mon, 20 Feb 2023 15:43:28 GMT
Subject: RFR: 8302871: Speed up StringLatin1.regionMatchesCI [v4]
In-Reply-To: <fRAZdIQEidu2hYiazk0b0ePDVe_h2Drf5QHfXb7FfTM=.e04bdb59-dfc8-4cd5-9008-b41fdda7c451@github.com>
References: <dnsiX3nRffjGjZXJG7lMAZj2FktEl2Wc1XfFthQ4iJs=.8c41438a-80a4-468f-ae0b-7322c9d6d952@github.com>
 <fRAZdIQEidu2hYiazk0b0ePDVe_h2Drf5QHfXb7FfTM=.e04bdb59-dfc8-4cd5-9008-b41fdda7c451@github.com>
Message-ID: <03PmkNiBgSaqEQHWdzOBIEFh3itEUkhd3PU7ZqNt8UA=.4531baf5-d8cc-4cc5-9767-af0f1458d87f@github.com>

On Mon, 20 Feb 2023 14:45:09 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

>> This PR suggests we can speed up `StringLatin1.regionMatchesCI` by applying 'the oldest ASCII trick in the book'.
>> 
>> The new static method `CharacterDataLatin1.equalsIgnoreCase` compares two latin1 bytes for equality ignoring case. `StringLatin1.regionMatchesCI` is updated to use `equalsIgnoreCase`
>> 
>> To verify the correctness of `equalsIgnoreCase`, a new test is added  to `EqualsIgnoreCase` with an exhaustive verification that all 256x256 latin1 code point pairs have an `equalsIgnoreCase` consistent with Character.toUpperCase, Character.toLowerCase.
>> 
>> Performance is tested for matching and mismatching cases of code point pairs picked from the ASCII letter, ASCII number and latin1 letter ranges. Results in the first comment below.
>
> Eirik Bjorsnos has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Add @bug tag to EqualsIgnoreCase test for correct issue JDK-8302871
>  - Add @bug tag to EqualsIgnoreCase test for JDK-8302877

src/java.base/share/classes/java/lang/CharacterDataLatin1.java.template line 170:

> 168:      * @return true if the two bytes are considered equals ignoring case in latin1
> 169:      */
> 170:      static boolean equalsIgnoreCase(byte b1, byte b2) {

Perhaps put this in `CharacterDataLatin1`, keeping it close to toLowerCase/toUpperCase that you're changing to use similar logic with #12623 

If you apply #12623 first - how much difference does this make on the micro you're adding with this PR?

-------------

PR: https://git.openjdk.org/jdk/pull/12632

From duke at openjdk.org  Mon Feb 20 16:19:27 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Mon, 20 Feb 2023 16:19:27 GMT
Subject: RFR: 8302871: Speed up StringLatin1.regionMatchesCI [v4]
In-Reply-To: <03PmkNiBgSaqEQHWdzOBIEFh3itEUkhd3PU7ZqNt8UA=.4531baf5-d8cc-4cc5-9767-af0f1458d87f@github.com>
References: <dnsiX3nRffjGjZXJG7lMAZj2FktEl2Wc1XfFthQ4iJs=.8c41438a-80a4-468f-ae0b-7322c9d6d952@github.com>
 <fRAZdIQEidu2hYiazk0b0ePDVe_h2Drf5QHfXb7FfTM=.e04bdb59-dfc8-4cd5-9008-b41fdda7c451@github.com>
 <03PmkNiBgSaqEQHWdzOBIEFh3itEUkhd3PU7ZqNt8UA=.4531baf5-d8cc-4cc5-9767-af0f1458d87f@github.com>
Message-ID: <DX4-EFdkBS7fNnPHtAR2QAm4reh9vBAltau23SdOoQ8=.791d1b18-4b69-48bd-bfc9-06e2f28eb2f2@github.com>

On Mon, 20 Feb 2023 15:40:09 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> Eirik Bjorsnos has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Add @bug tag to EqualsIgnoreCase test for correct issue JDK-8302871
>>  - Add @bug tag to EqualsIgnoreCase test for JDK-8302877
>
> src/java.base/share/classes/java/lang/CharacterDataLatin1.java.template line 170:
> 
>> 168:      * @return true if the two bytes are considered equals ignoring case in latin1
>> 169:      */
>> 170:      static boolean equalsIgnoreCase(byte b1, byte b2) {
> 
> Perhaps put this in `CharacterDataLatin1`, keeping it close to toLowerCase/toUpperCase that you're changing to use similar logic with #12623 
> 
> If you apply #12623 first - how much difference does this make on the micro you're adding with this PR?

Is it not already in CharacterDataLatin1?

Here is a comparison of relying on improvements in `CharacterDataLatin1.toUpperCase/toLowerCase` only vs. using `CharacterDataLatin1.equalsIgnoreCase`:

Character.toUpperCase/toLowerCase only:


Benchmark                                  (codePoints)  (size)  Mode  Cnt     Score    Error  Units
RegionMatchesIC.Latin1.regionMatchesIC      ascii-match    1024  avgt   15  1310.582 ? 84.777  ns/op
RegionMatchesIC.Latin1.regionMatchesIC   ascii-mismatch    1024  avgt   15     4.547 ?  0.545  ns/op
RegionMatchesIC.Latin1.regionMatchesIC     number-match    1024  avgt   15   686.947 ? 11.850  ns/op
RegionMatchesIC.Latin1.regionMatchesIC  number-mismatch    1024  avgt   15     3.836 ?  0.634  ns/op
RegionMatchesIC.Latin1.regionMatchesIC       lat1-match    1024  avgt   15  2107.219 ? 17.662  ns/op
RegionMatchesIC.Latin1.regionMatchesIC    lat1-mismatch    1024  avgt   15     4.924 ?  0.829  ns/op


CharacterDataLatin1.equalsIgnoreCase:


Benchmark                                  (codePoints)  (size)  Mode  Cnt     Score    Error  Units
RegionMatchesIC.Latin1.regionMatchesIC      ascii-match    1024  avgt   15   742.467 ? 34.490  ns/op
RegionMatchesIC.Latin1.regionMatchesIC   ascii-mismatch    1024  avgt   15     3.960 ?  0.046  ns/op
RegionMatchesIC.Latin1.regionMatchesIC     number-match    1024  avgt   15   361.158 ? 37.096  ns/op
RegionMatchesIC.Latin1.regionMatchesIC  number-mismatch    1024  avgt   15     4.039 ?  0.521  ns/op
RegionMatchesIC.Latin1.regionMatchesIC       lat1-match    1024  avgt   15  1158.091 ? 41.617  ns/op
RegionMatchesIC.Latin1.regionMatchesIC    lat1-mismatch    1024  avgt   15     4.358 ?  0.123  ns/op

-------------

PR: https://git.openjdk.org/jdk/pull/12632

From redestad at openjdk.org  Mon Feb 20 16:26:26 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Mon, 20 Feb 2023 16:26:26 GMT
Subject: RFR: 8302871: Speed up StringLatin1.regionMatchesCI [v4]
In-Reply-To: <DX4-EFdkBS7fNnPHtAR2QAm4reh9vBAltau23SdOoQ8=.791d1b18-4b69-48bd-bfc9-06e2f28eb2f2@github.com>
References: <dnsiX3nRffjGjZXJG7lMAZj2FktEl2Wc1XfFthQ4iJs=.8c41438a-80a4-468f-ae0b-7322c9d6d952@github.com>
 <fRAZdIQEidu2hYiazk0b0ePDVe_h2Drf5QHfXb7FfTM=.e04bdb59-dfc8-4cd5-9008-b41fdda7c451@github.com>
 <03PmkNiBgSaqEQHWdzOBIEFh3itEUkhd3PU7ZqNt8UA=.4531baf5-d8cc-4cc5-9767-af0f1458d87f@github.com>
 <DX4-EFdkBS7fNnPHtAR2QAm4reh9vBAltau23SdOoQ8=.791d1b18-4b69-48bd-bfc9-06e2f28eb2f2@github.com>
Message-ID: <pXrtSJWYC3DHlIw3jxQeJofD1IJf0J2jR8swTk9qGpo=.345d231e-e994-4518-8ea5-5b2bd920e523@github.com>

On Mon, 20 Feb 2023 16:16:45 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/CharacterDataLatin1.java.template line 170:
>> 
>>> 168:      * @return true if the two bytes are considered equals ignoring case in latin1
>>> 169:      */
>>> 170:      static boolean equalsIgnoreCase(byte b1, byte b2) {
>> 
>> Perhaps put this in `CharacterDataLatin1`, keeping it close to toLowerCase/toUpperCase that you're changing to use similar logic with #12623 
>> 
>> If you apply #12623 first - how much difference does this make on the micro you're adding with this PR?
>
> Is it not already in CharacterDataLatin1?
> 
> Here is a comparison of relying on improvements in `CharacterDataLatin1.toUpperCase/toLowerCase` only vs. using `CharacterDataLatin1.equalsIgnoreCase`:
> 
> Character.toUpperCase/toLowerCase only:
> 
> 
> Benchmark                                  (codePoints)  (size)  Mode  Cnt     Score    Error  Units
> RegionMatchesIC.Latin1.regionMatchesIC      ascii-match    1024  avgt   15  1310.582 ? 84.777  ns/op
> RegionMatchesIC.Latin1.regionMatchesIC   ascii-mismatch    1024  avgt   15     4.547 ?  0.545  ns/op
> RegionMatchesIC.Latin1.regionMatchesIC     number-match    1024  avgt   15   686.947 ? 11.850  ns/op
> RegionMatchesIC.Latin1.regionMatchesIC  number-mismatch    1024  avgt   15     3.836 ?  0.634  ns/op
> RegionMatchesIC.Latin1.regionMatchesIC       lat1-match    1024  avgt   15  2107.219 ? 17.662  ns/op
> RegionMatchesIC.Latin1.regionMatchesIC    lat1-mismatch    1024  avgt   15     4.924 ?  0.829  ns/op
> 
> 
> CharacterDataLatin1.equalsIgnoreCase:
> 
> 
> Benchmark                                  (codePoints)  (size)  Mode  Cnt     Score    Error  Units
> RegionMatchesIC.Latin1.regionMatchesIC      ascii-match    1024  avgt   15   742.467 ? 34.490  ns/op
> RegionMatchesIC.Latin1.regionMatchesIC   ascii-mismatch    1024  avgt   15     3.960 ?  0.046  ns/op
> RegionMatchesIC.Latin1.regionMatchesIC     number-match    1024  avgt   15   361.158 ? 37.096  ns/op
> RegionMatchesIC.Latin1.regionMatchesIC  number-mismatch    1024  avgt   15     4.039 ?  0.521  ns/op
> RegionMatchesIC.Latin1.regionMatchesIC       lat1-match    1024  avgt   15  1158.091 ? 41.617  ns/op
> RegionMatchesIC.Latin1.regionMatchesIC    lat1-mismatch    1024  avgt   15     4.358 ?  0.123  ns/op

Oops, I lost context and thought this was in `StringLatin1`.

Thanks for running the numbers with #12623. Looks like you're getting big enough of an improvement on top.

-------------

PR: https://git.openjdk.org/jdk/pull/12632

From duke at openjdk.org  Mon Feb 20 16:30:29 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Mon, 20 Feb 2023 16:30:29 GMT
Subject: RFR: 8302871: Speed up StringLatin1.regionMatchesCI [v4]
In-Reply-To: <pXrtSJWYC3DHlIw3jxQeJofD1IJf0J2jR8swTk9qGpo=.345d231e-e994-4518-8ea5-5b2bd920e523@github.com>
References: <dnsiX3nRffjGjZXJG7lMAZj2FktEl2Wc1XfFthQ4iJs=.8c41438a-80a4-468f-ae0b-7322c9d6d952@github.com>
 <fRAZdIQEidu2hYiazk0b0ePDVe_h2Drf5QHfXb7FfTM=.e04bdb59-dfc8-4cd5-9008-b41fdda7c451@github.com>
 <03PmkNiBgSaqEQHWdzOBIEFh3itEUkhd3PU7ZqNt8UA=.4531baf5-d8cc-4cc5-9767-af0f1458d87f@github.com>
 <DX4-EFdkBS7fNnPHtAR2QAm4reh9vBAltau23SdOoQ8=.791d1b18-4b69-48bd-bfc9-06e2f28eb2f2@github.com>
 <pXrtSJWYC3DHlIw3jxQeJofD1IJf0J2jR8swTk9qGpo=.345d231e-e994-4518-8ea5-5b2bd920e523@github.com>
Message-ID: <L-JgKLbOarQM_S3KYtLffTDBJXeuLkNDR_6EGqHdK4g=.f137d2f0-c47c-4c2a-8333-304053c4af2e@github.com>

On Mon, 20 Feb 2023 16:23:32 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> Is it not already in CharacterDataLatin1?
>> 
>> Here is a comparison of relying on improvements in `CharacterDataLatin1.toUpperCase/toLowerCase` only vs. using `CharacterDataLatin1.equalsIgnoreCase`:
>> 
>> Character.toUpperCase/toLowerCase only:
>> 
>> 
>> Benchmark                                  (codePoints)  (size)  Mode  Cnt     Score    Error  Units
>> RegionMatchesIC.Latin1.regionMatchesIC      ascii-match    1024  avgt   15  1310.582 ? 84.777  ns/op
>> RegionMatchesIC.Latin1.regionMatchesIC   ascii-mismatch    1024  avgt   15     4.547 ?  0.545  ns/op
>> RegionMatchesIC.Latin1.regionMatchesIC     number-match    1024  avgt   15   686.947 ? 11.850  ns/op
>> RegionMatchesIC.Latin1.regionMatchesIC  number-mismatch    1024  avgt   15     3.836 ?  0.634  ns/op
>> RegionMatchesIC.Latin1.regionMatchesIC       lat1-match    1024  avgt   15  2107.219 ? 17.662  ns/op
>> RegionMatchesIC.Latin1.regionMatchesIC    lat1-mismatch    1024  avgt   15     4.924 ?  0.829  ns/op
>> 
>> 
>> CharacterDataLatin1.equalsIgnoreCase:
>> 
>> 
>> Benchmark                                  (codePoints)  (size)  Mode  Cnt     Score    Error  Units
>> RegionMatchesIC.Latin1.regionMatchesIC      ascii-match    1024  avgt   15   742.467 ? 34.490  ns/op
>> RegionMatchesIC.Latin1.regionMatchesIC   ascii-mismatch    1024  avgt   15     3.960 ?  0.046  ns/op
>> RegionMatchesIC.Latin1.regionMatchesIC     number-match    1024  avgt   15   361.158 ? 37.096  ns/op
>> RegionMatchesIC.Latin1.regionMatchesIC  number-mismatch    1024  avgt   15     4.039 ?  0.521  ns/op
>> RegionMatchesIC.Latin1.regionMatchesIC       lat1-match    1024  avgt   15  1158.091 ? 41.617  ns/op
>> RegionMatchesIC.Latin1.regionMatchesIC    lat1-mismatch    1024  avgt   15     4.358 ?  0.123  ns/op
>
> Oops, I lost context and thought this was in `StringLatin1`.
> 
> Thanks for running the numbers with #12623. Looks like you're getting big enough of an improvement on top.

Yes, seems `equalsIgnoreCase` carries its weight.

-------------

PR: https://git.openjdk.org/jdk/pull/12632

From plevart at openjdk.org  Mon Feb 20 17:06:31 2023
From: plevart at openjdk.org (Peter Levart)
Date: Mon, 20 Feb 2023 17:06:31 GMT
Subject: RFR: 8302822:
 Method/Field/Constructor/RecordComponent::getGenericInfo() is not thread safe
In-Reply-To: <aiC6MkXHICLXZPGIidwhW-iOf2Rrl2vOwuNAzEGmix4=.42794134-5feb-43e8-ad7d-73d4c6e23def@github.com>
References: <1sDlqlKVNOobyFy71f7ud5uL8_WcMPi1qKNa4ltxFQ0=.63cffbd7-e11a-4d7d-9362-cf215a7584ce@github.com>
 <aiC6MkXHICLXZPGIidwhW-iOf2Rrl2vOwuNAzEGmix4=.42794134-5feb-43e8-ad7d-73d4c6e23def@github.com>
Message-ID: <KnWJ2GDfC3tOc2BdBaC6ZTBunszrwAfwZrFWOIhQZcE=.7d680527-5595-4287-9da9-edd2e7ff2317@github.com>

On Mon, 20 Feb 2023 13:09:50 GMT, liach <duke at openjdk.org> wrote:

>> 8302822: Method/Field/Constructor/RecordComponent::getGenericInfo() is not thread safe
>
> We don't fear calling the factory twice for benign races, as the distinct constructor factory instances are behaviorally the same.
> 
> The true issue lies in the double getfield operations: Java memory model doesn't require the second read to happen-after a write reflected in the first read, so return this.genericInfo may return null while this.genericInfo == null evaluates to false, in case genericInfo is initialized lazily by another thread. See https://bugs.openjdk.org/browse/JDK-8261404

Hi @liach,

I think @dholmes-ora is worried about the fields in the object being returned by the getGenericInfo() method and similar. In above case this means fields in class ConstructorRepository.
I checked it and the entire hierarchy based on sun.reflect.generics.repository.AbstractRepository with subclasses including ConstructorRepository is modeled such that all fields are either:
- volatile and lazily initialized; or
- final and initialized in constructor

Such objects may be published via data race and still be seen consistent on the accepting side.

-------------

PR: https://git.openjdk.org/jdk/pull/12643

From alanb at openjdk.org  Mon Feb 20 17:14:25 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 20 Feb 2023 17:14:25 GMT
Subject: RFR: 8302863: Speed up String::encodeASCII using countPositives
In-Reply-To: <xo42mWnM8O8-KsosrLsJwo2hR0ZuvrwlDfq9VUAA4nM=.c67cc391-6cd1-483e-bd24-4009605553af@github.com>
References: <xo42mWnM8O8-KsosrLsJwo2hR0ZuvrwlDfq9VUAA4nM=.c67cc391-6cd1-483e-bd24-4009605553af@github.com>
Message-ID: <hLlzp3KXnQK8UZ3eJc8VRgt5-WL6s1IZ6S712zHR5As=.2e7c85f3-5f46-4ede-b49e-b0151be161a1@github.com>

On Sat, 18 Feb 2023 23:26:08 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> When encoding Strings to US-ASCII we can speed up the happy path significantly by using `StringCoding.countPositives` as a speculative check for whether there are any chars that needs to be replaced by `'?'`. Once a non-ASCII char is encountered we fall back to the slow loop and replace as needed.
> 
> An alternative could be unrolling or using a byte array VarHandle, as show-cased by Brett Okken here: https://mail.openjdk.org/pipermail/core-libs-dev/2023-February/100573.html Having to replace chars with `?` is essentially an encoding error so it might be safe to assume this case is exceptional in practice.

Marked as reviewed by alanb (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/12640

From pminborg at openjdk.org  Mon Feb 20 17:36:08 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 20 Feb 2023 17:36:08 GMT
Subject: RFR: 8299852: Modernize ConcurrentHashMap [v4]
In-Reply-To: <AC_zApEcsuBSWzRSEh2VMQcQf-gSm4CyfiMXfy2WbPM=.0439016d-88f2-4892-98f8-a6f1fff2128a@github.com>
References: <AC_zApEcsuBSWzRSEh2VMQcQf-gSm4CyfiMXfy2WbPM=.0439016d-88f2-4892-98f8-a6f1fff2128a@github.com>
Message-ID: <o8965C_lMVagi-qCR5tEbxJ_tPGLtDh15nwhL4Y3sVQ=.d036a322-999c-4214-af2e-ca4340040088@github.com>

> `java.util.concurrent.ConcurrentHashMap` is relatively old and has not been updated to reflect the current state of Java and can be modernized: 
> 
> * Add `@Serial` annotations 
> * Seal classes and restrict subclassing for internal classes 
> * Use pattern matching for instance 
> * Remove redundant modifiers (such as some final declarations) 
> * Use Objects.requireNonNull for invariant checking 
> * Use diamond operators instead of explicit types 
> * Simplify expressions using Math::max

Per Minborg has updated the pull request incrementally with one additional commit since the last revision:

  Remove redundant line

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/11924/files
  - new: https://git.openjdk.org/jdk/pull/11924/files/b2dbdd8f..cd4b1365

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11924&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11924&range=02-03

  Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/11924.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11924/head:pull/11924

PR: https://git.openjdk.org/jdk/pull/11924

From alanb at openjdk.org  Mon Feb 20 17:40:26 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 20 Feb 2023 17:40:26 GMT
Subject: RFR: 8302815 Use new Math.clamp method in core libraries [v2]
In-Reply-To: <V5pROUz9W7-O5FDi8LQ9dgWzsiJKfl9Y9xi_VmYvT4A=.9835b9b3-aeb5-484b-ac57-74d1071ed9da@github.com>
References: <k_xjmup3YSdUre0Z_XpO-WEBb5XED2FYv8UUZT2ULwc=.86f53f51-cceb-45fd-935d-b054c79a0526@github.com>
 <V5pROUz9W7-O5FDi8LQ9dgWzsiJKfl9Y9xi_VmYvT4A=.9835b9b3-aeb5-484b-ac57-74d1071ed9da@github.com>
Message-ID: <x4wYWxXT9oJFQpk4omqHYAS4Iodmz1xFzqP7J9jMBIk=.e747a1e9-c0a2-4de0-b75e-dd05ce3652db@github.com>

On Sat, 18 Feb 2023 21:40:08 GMT, Tagir F. Valeev <tvaleev at openjdk.org> wrote:

>> For cleanup and dogfooding the new method, it would be nice to use Math.clamp where possible in java.base. See PR #12428.
>> 
>> As Math.clamp performs an additional check that min is not greater than max, I conservatively replaced only those occurrences where I can see that this invariant is always held. There are more occurrences, where clamp can be potentially used but it's unclear whether min <= max is always true.
>
> Tagir F. Valeev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert changes in JrtPath, as it seems to be compiled with bootstrap JDK

I skimmed through the usages and they look okay. I didn't spot anywhere that it differs to the existing clamping. This is the first update in 2023 for some of these files so I assume you'll bump the copyright year before integrating.

-------------

Marked as reviewed by alanb (Reviewer).

PR: https://git.openjdk.org/jdk/pull/12633

From rriggs at openjdk.org  Mon Feb 20 18:07:52 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 20 Feb 2023 18:07:52 GMT
Subject: RFR: 8301627: System.exit and Runtime.exit debug logging [v7]
In-Reply-To: <OzJeJH5yxolKPChcUisqtzGYF_MU3oOJdx6HPhsXjBw=.15eefe39-efe1-433e-a6ac-02b4a730f264@github.com>
References: <OzJeJH5yxolKPChcUisqtzGYF_MU3oOJdx6HPhsXjBw=.15eefe39-efe1-433e-a6ac-02b4a730f264@github.com>
Message-ID: <r3KGtwiYYKZmbzeRggzGA5eOpCZSQAX0PtpLwkoU7wo=.a0f24c6f-bf27-428b-b326-6ca71e0063cc@github.com>

> It can be difficult to find the cause of calls to `java.lang.System.exit(status)` and `Runtime.exit(status)` because the Java runtime exits.
> The status value and stack trace are logged using the System Logger named `java.lang.Runtime` with message level `System.Logger.Level.DEBUG`.

Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:

  fix double the

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12517/files
  - new: https://git.openjdk.org/jdk/pull/12517/files/3dc13135..acce58f1

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12517&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12517&range=05-06

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/12517.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12517/head:pull/12517

PR: https://git.openjdk.org/jdk/pull/12517

From darcy at openjdk.org  Mon Feb 20 18:14:26 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Mon, 20 Feb 2023 18:14:26 GMT
Subject: RFR: JDK-8302800: Augment NaN handling tests of FDLIBM methods
In-Reply-To: <KR6zj5_QCUqe7IzB4GSKjeNqoodcNZ25Ff85gBOIm44=.c73f47d4-85fd-413a-9972-daaf00c7cba4@github.com>
References: <mc-_elojltkXx-TJQxeFKmIK6TELw_WBpwoSv7rdgEc=.9b3224a0-c9a0-475e-b7e8-86317d1ac04b@github.com>
 <KR6zj5_QCUqe7IzB4GSKjeNqoodcNZ25Ff85gBOIm44=.c73f47d4-85fd-413a-9972-daaf00c7cba4@github.com>
Message-ID: <11htN-POHiMqtqoocGS9TtJJRT6e2z0Xld2Kp20Ahcs=.42f1a98c-09d4-41d6-8840-68e907948a4b@github.com>

On Mon, 20 Feb 2023 10:22:48 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> Augment NaN-handling tests to include exotic NaN bit patterns. Assuming this changeset goes back first, I'll update https://github.com/openjdk/jdk/pull/12608 to follow the same convention afterward.
>
> test/jdk/java/lang/Math/Tests.java line 41:
> 
>> 39:     private Tests(){}; // do not instantiate
>> 40: 
>> 41:     static volatile double zero = 0.0;
> 
> Not directly related to this PR and just out of curiosity: is there a reason for this to be `volatile` and non-`final`?

The comment on the PLATFORM_NAN field was mean to address that -- an attempt to make sure the expression to create the platform NaN gets evaluated at runtime rather than being constant-folded at compile time.

-------------

PR: https://git.openjdk.org/jdk/pull/12644

From eirbjo at gmail.com  Mon Feb 20 18:24:55 2023
From: eirbjo at gmail.com (=?UTF-8?B?RWlyaWsgQmrDuHJzbsO4cw==?=)
Date: Mon, 20 Feb 2023 19:24:55 +0100
Subject: RFD: Consumer.empty()
Message-ID: <CA+pBWhu_U8UsLgfG3dV_7Di4FGkuO3DdwPYg0ALf8TWkfh_D4Q@mail.gmail.com>

Hi,

So I found myself writing some code which sets up a j.u.s.Stream processing
pipeline where the stream can optionally be traced/logged via a peeking
Consumer.

The default should be not to trace, in which case I initially set the
Consumer to null. But then I need to check that trace != null when setting
up the stream. This felt awkward..

Since related code was using Function.identity() as a "no mapping
configured" default, I went looking for Consumer.empty(), only to learn
that no such thing exists.

I can of course just do () -> {}, but I think Consumer.empty() conveys the
purpose a bit more clearly..

Is there some thought behind this not existing? Would it be worth adding?


/**
 * Returns a consumer which performs no operation on its input argument
 *
 * @param <T> the type of the input argument
 * @return a Consumer which performs no operation on its input argument
 */
static <T> Consumer<T> empty() {
    return t -> {};
}
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20230220/5ec07846/attachment.htm>

From eirbjo at gmail.com  Mon Feb 20 19:02:57 2023
From: eirbjo at gmail.com (=?UTF-8?B?RWlyaWsgQmrDuHJzbsO4cw==?=)
Date: Mon, 20 Feb 2023 20:02:57 +0100
Subject: RFD: Consumer.empty()
In-Reply-To: <CA+pBWhu_U8UsLgfG3dV_7Di4FGkuO3DdwPYg0ALf8TWkfh_D4Q@mail.gmail.com>
References: <CA+pBWhu_U8UsLgfG3dV_7Di4FGkuO3DdwPYg0ALf8TWkfh_D4Q@mail.gmail.com>
Message-ID: <CA+pBWhvMNfQn77ePrYygjC-CVU4Dfah-MBAj7vP1Ls-bboOJZg@mail.gmail.com>

Found this answer from smarks:

https://stackoverflow.com/questions/26549659/built-in-java-8-predicate-that-always-returns-true/26553481#26553481

Certainly there is some value in something that has a name vs. a
> written-out lambda, but this value is quite small. We expect that people
> will learn how to read and write x -> true and () -> { } and that their
> usage will become idiomatic. Even the value of Function.identity() over x
> -> x is questionable.


Makes sense. And where would we stop..?

EIrik.

On Mon, Feb 20, 2023 at 7:24 PM Eirik Bj?rsn?s <eirbjo at gmail.com> wrote:

> Hi,
>
> So I found myself writing some code which sets up a j.u.s.Stream
> processing pipeline where the stream can optionally be traced/logged via a
> peeking Consumer.
>
> The default should be not to trace, in which case I initially set the
> Consumer to null. But then I need to check that trace != null when setting
> up the stream. This felt awkward..
>
> Since related code was using Function.identity() as a "no mapping
> configured" default, I went looking for Consumer.empty(), only to learn
> that no such thing exists.
>
> I can of course just do () -> {}, but I think Consumer.empty() conveys the
> purpose a bit more clearly..
>
> Is there some thought behind this not existing? Would it be worth adding?
>
>
> /**
>  * Returns a consumer which performs no operation on its input argument
>  *
>  * @param <T> the type of the input argument
>  * @return a Consumer which performs no operation on its input argument
>  */
> static <T> Consumer<T> empty() {
>     return t -> {};
> }
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20230220/cec1f265/attachment.htm>

From duke at openjdk.org  Mon Feb 20 21:43:26 2023
From: duke at openjdk.org (Brett Okken)
Date: Mon, 20 Feb 2023 21:43:26 GMT
Subject: RFR: 8302863: Speed up String::encodeASCII using countPositives
In-Reply-To: <xo42mWnM8O8-KsosrLsJwo2hR0ZuvrwlDfq9VUAA4nM=.c67cc391-6cd1-483e-bd24-4009605553af@github.com>
References: <xo42mWnM8O8-KsosrLsJwo2hR0ZuvrwlDfq9VUAA4nM=.c67cc391-6cd1-483e-bd24-4009605553af@github.com>
Message-ID: <jwOo63bHsKJ8IAcNj2C8MwCGeZ_SDXxsLT84uNz4mY8=.259edda2-bf61-449d-af8c-a4baa999eab1@github.com>

On Sat, 18 Feb 2023 23:26:08 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> When encoding Strings to US-ASCII we can speed up the happy path significantly by using `StringCoding.countPositives` as a speculative check for whether there are any chars that needs to be replaced by `'?'`. Once a non-ASCII char is encountered we fall back to the slow loop and replace as needed.
> 
> An alternative could be unrolling or using a byte array VarHandle, as show-cased by Brett Okken here: https://mail.openjdk.org/pipermail/core-libs-dev/2023-February/100573.html Having to replace chars with `?` is essentially an encoding error so it might be safe to assume this case is exceptional in practice.

For the happy path of no encoding failures, this "trivial" change is a great improvement.

-------------

Marked as reviewed by bokken at github.com (no known OpenJDK username).

PR: https://git.openjdk.org/jdk/pull/12640

From dholmes at openjdk.org  Mon Feb 20 22:29:26 2023
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 20 Feb 2023 22:29:26 GMT
Subject: RFR: 8302822:
 Method/Field/Constructor/RecordComponent::getGenericInfo() is not thread safe
In-Reply-To: <KnWJ2GDfC3tOc2BdBaC6ZTBunszrwAfwZrFWOIhQZcE=.7d680527-5595-4287-9da9-edd2e7ff2317@github.com>
References: <1sDlqlKVNOobyFy71f7ud5uL8_WcMPi1qKNa4ltxFQ0=.63cffbd7-e11a-4d7d-9362-cf215a7584ce@github.com>
 <aiC6MkXHICLXZPGIidwhW-iOf2Rrl2vOwuNAzEGmix4=.42794134-5feb-43e8-ad7d-73d4c6e23def@github.com>
 <KnWJ2GDfC3tOc2BdBaC6ZTBunszrwAfwZrFWOIhQZcE=.7d680527-5595-4287-9da9-edd2e7ff2317@github.com>
Message-ID: <ESC9l0VKVQSY6Hc7YBSRQuMToI4OjcydJPQvKZDY6BQ=.a938539d-1380-4e2c-a1e7-c8b75c4afa52@github.com>

On Mon, 20 Feb 2023 17:03:33 GMT, Peter Levart <plevart at openjdk.org> wrote:

>> We don't fear calling the factory twice for benign races, as the distinct constructor factory instances are behaviorally the same.
>> 
>> The true issue lies in the double getfield operations: Java memory model doesn't require the second read to happen-after a write reflected in the first read, so return this.genericInfo may return null while this.genericInfo == null evaluates to false, in case genericInfo is initialized lazily by another thread. See https://bugs.openjdk.org/browse/JDK-8261404
>
> Hi @liach,
> 
> I think @dholmes-ora is worried about the fields in the object being returned by the getGenericInfo() method and similar. In above case this means fields in class ConstructorRepository.
> I checked it and the entire hierarchy based on sun.reflect.generics.repository.AbstractRepository with subclasses including ConstructorRepository is modeled such that all fields are either:
> - volatile and lazily initialized; or
> - final and initialized in constructor
> 
> Such objects may be published via data race and still be seen consistent on the accepting side.

Thanks @plevart  that was exactly my concern but I didn't have time to check whether the returned object could be safely published regardless of any race condition. Is it specified that way, or just a fortuitous occurrence?

I would also be concerned about the guarantee of idempotency from the factory method - I hope its requirements in that area are clearly documented.

-------------

PR: https://git.openjdk.org/jdk/pull/12643

From duke at openjdk.org  Mon Feb 20 23:55:24 2023
From: duke at openjdk.org (SWinxy)
Date: Mon, 20 Feb 2023 23:55:24 GMT
Subject: RFR: 8026369: javac potentially ambiguous overload warning needs
 an improved scheme
In-Reply-To: <IMxp3iCK--jYJ5Ia04i6QPYfnCHQobVcsmlI5aJXdqc=.892abcb8-7f2a-4fe9-aea2-1b1d41098a6d@github.com>
References: <IMxp3iCK--jYJ5Ia04i6QPYfnCHQobVcsmlI5aJXdqc=.892abcb8-7f2a-4fe9-aea2-1b1d41098a6d@github.com>
Message-ID: <xVTkB9-V5fVop5Mix7Gk29Ix3JCtAlBZeHR-064qaw0=.b3e9d5c2-4def-4410-8a59-c8c25049f7e4@github.com>

On Sun, 19 Feb 2023 23:52:52 GMT, Archie L. Cobbs <duke at openjdk.org> wrote:

> This bug relates to the "potentially ambiguous overload" warning which is enabled by `-Xlint:overloads`.
> 
> The warning detects certain ambiguities that can cause problems for lambdas. For example, consider the interface `Spliterator.OfInt`, which declares these two methods:
> 
> void forEachRemaining(Consumer<? super Integer> action);
> void forEachRemaining(IntConsumer action);
> 
> Both methods have the same name, same number of parameters, and take a lambda with the same "shape" in the same argument position. This causes an ambiguity in any code that wants to do this:
> 
>     spliterator.forEachRemaining(x -> { ... });
> 
> That code won't compile; instead, you'll get this error:
> 
> Ambiguity.java:4: error: reference to forEachRemaining is ambiguous
>         spliterator.forEachRemaining(x -> { });
>                    ^
>   both method forEachRemaining(IntConsumer) in OfInt and method forEachRemaining(Consumer<? super Integer>) in OfInt match
> 
> 
> The problem reported by the bug is that the warning fails to detect ambiguities which are created purely by inheritance, for example:
> 
> interface ConsumerOfInteger {
>     void foo(Consumer<Integer> c);
> }
> 
> interface IntegerConsumer {
>     void foo(IntConsumer c);
> }
> 
> // We should get a warning here...
> interface Test extends ConsumerOfInteger, IntegerConsumer {
> }
> 
> 
> The cause of the bug is that ambiguities are detected on a per-method basis, by checking whether a method is part of an ambiguity pair when we visit that method. So if the methods in an ambiguity pair are inherited from two distinct supertypes, we'll miss the ambiguity.
> 
> To fix the problem, we need to look for ambiguities on a per-class level, checking all pairs of methods. However, it's not that simple - we only want to "blame" a class when that class itself, and not some supertype, is responsible for creating the ambiguity. For example, any interface extending `Spliterator.OfInt` will automatically inherit the two ambiguities mentioned above, but these are not the interface's fault so to speak so no warning should be generated. Making things more complicated is the fact that methods can be overridden and declared in generic classes so they only conflict in some subtypes, etc.
> 
> So we generate the warning when there are two methods m1 and m2 in a class C such that:
> 
> * m1 and m2 consitiute a "potentially ambiguous overload" (using the same definition as before)
> * There is no direct supertype T of C such that m1 and m2, or some methods they override, both exist in T and constitute a "potentially ambiguous overload" as members of T
> * We haven't already generated a warning for either m1 or m2 in class C
> 
> If either method is declared in C, we locate the warning there, but when both methods are inherited, there's no method declaration to point at so the warning is instead located at the class declaration.
> 
> I noticed a couple of other minor bugs; these are also being fixed here:
> 
> (1) For inherited methods, the method signatures were being reported as they are declared, rather than in the context of the class being visited. As a result, when a methods is inherited from a generic supertype, the ambiguity is less clear. Here's an example:
> 
> interface Upper<T> {
>     void foo(T c);
> }
> 
> interface Lower extends Upper<IntConsumer> {
>     void foo(Consumer<Integer> c);
> }
> 
> Currently, the error is reported as:
> 
> warning: [overloads] foo(Consumer<Integer>) in Lower is potentially ambiguous with foo(T) in Upper
> 
> Reporting the method signatures in the context of the class being visited makes the ambiguity clearer:
> 
> warning: [overloads] foo(Consumer<Integer>) in Lower is potentially ambiguous with foo(IntConsumer) in Upper
> 
> 
> (2) When a method is identified as part of an ambiguous pair, we were setting a `POTENTIALLY_AMBIGUOUS` flag on it. This caused it to be forever excluded from future warnings. For methods that are declared in the class we're visiting, this makes sense, but it doesn't make sense for inherited methods, because it disqualifies them from participating in the analysis of any other class that also inherits them.
> 
> As a result, for a class like the one below, the compiler was only generating one warning instead of three:
> 
> public interface SuperIface {
>     void foo(Consumer<Integer> c);
> }
> 
> public interface I1 extends SuperIface { 
>     void foo(IntConsumer c);        // warning was generated here
> }   
> 
> public interface I2 extends SuperIface { 
>     void foo(IntConsumer c);        // no warning was generated here
> }   
> 
> public interface I3 extends SuperIface { 
>     void foo(IntConsumer c);        // no warning was generated here
> }   
> 
> 
> With this patch the `POTENTIALLY_AMBIGUOUS` flag is no longer needed. I wasn't sure whether to renumber all the subsequent flags, or just leave an empty placeholder, so I chose the latter.
> 
> Finally, this fix uncovers new warnings in `java.base` and `java.desktop`, so these are now suppressed in the patch.

In the `AWTEventMulticaster` class(es), which interfaces are causing the ambiguity?

-------------

PR: https://git.openjdk.org/jdk/pull/12645

From naoto at openjdk.org  Tue Feb 21 00:17:25 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 21 Feb 2023 00:17:25 GMT
Subject: RFR: 8302877: Speed up latin1 case conversions
In-Reply-To: <Q1CJmrbsLmHneQMQDvFuSnHwlaFwzs_4FQSgw5Woc7U=.ce74d4ee-941e-40ec-8cd5-7d1d5d0c0b81@github.com>
References: <cf9hc-SBdgzB1lpqXGLHKcjT4-T9hLaMs1cCccqBiak=.f7b99e9d-3206-4e67-976f-ea0492ec6b06@github.com>
 <CgKt3Q0k0hCkg4xxCRBOPDX6fi-zQWxuHX0zoKT3Pio=.af2d552c-dbfe-4acc-a738-94e2e6c3b25d@github.com>
 <Q1CJmrbsLmHneQMQDvFuSnHwlaFwzs_4FQSgw5Woc7U=.ce74d4ee-941e-40ec-8cd5-7d1d5d0c0b81@github.com>
Message-ID: <UzZau1cG5pNwApw4QrS4HIWlQDXgj32G617BC_TdYK8=.bb876d03-c466-4dbc-8e3c-d62dc1373aa7@github.com>

On Sat, 18 Feb 2023 06:43:27 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

>> test/jdk/java/lang/Character/Latin1CaseFolding.java line 31:
>> 
>>> 29: /**
>>> 30:  * @test
>>> 31:  * @summary Provides exchaustive verification of Character.toUpperCase and Character.toLowerCase
>> 
>> typo: "exhaustive"?
>
> I did an 'exchaustive' search for 'exchaustive' across the code base and found  two comments in `LocaleData` and `LocaleData.cldr` in `jdk/test/jdk/sun/text/resources`.
> 
> Would you like me to update these as well while we're here, or should we avoid getting out scope for this PR?

I'd appreciate it. I don't mind fixing it with this PR.

-------------

PR: https://git.openjdk.org/jdk/pull/12623

From duke at openjdk.org  Tue Feb 21 01:42:41 2023
From: duke at openjdk.org (Archie L. Cobbs)
Date: Tue, 21 Feb 2023 01:42:41 GMT
Subject: RFR: 8026369: javac potentially ambiguous overload warning needs
 an improved scheme [v2]
In-Reply-To: <IMxp3iCK--jYJ5Ia04i6QPYfnCHQobVcsmlI5aJXdqc=.892abcb8-7f2a-4fe9-aea2-1b1d41098a6d@github.com>
References: <IMxp3iCK--jYJ5Ia04i6QPYfnCHQobVcsmlI5aJXdqc=.892abcb8-7f2a-4fe9-aea2-1b1d41098a6d@github.com>
Message-ID: <NlqhxTe-Li08DSIjyYVn5HI9uIAvIHZE4IG0x8tQTQw=.0ae9928e-7814-4356-bf75-11bc4eefc6be@github.com>

> This bug relates to the "potentially ambiguous overload" warning which is enabled by `-Xlint:overloads`.
> 
> The warning detects certain ambiguities that can cause problems for lambdas. For example, consider the interface `Spliterator.OfInt`, which declares these two methods:
> 
> void forEachRemaining(Consumer<? super Integer> action);
> void forEachRemaining(IntConsumer action);
> 
> Both methods have the same name, same number of parameters, and take a lambda with the same "shape" in the same argument position. This causes an ambiguity in any code that wants to do this:
> 
>     spliterator.forEachRemaining(x -> { ... });
> 
> That code won't compile; instead, you'll get this error:
> 
> Ambiguity.java:4: error: reference to forEachRemaining is ambiguous
>         spliterator.forEachRemaining(x -> { });
>                    ^
>   both method forEachRemaining(IntConsumer) in OfInt and method forEachRemaining(Consumer<? super Integer>) in OfInt match
> 
> 
> The problem reported by the bug is that the warning fails to detect ambiguities which are created purely by inheritance, for example:
> 
> interface ConsumerOfInteger {
>     void foo(Consumer<Integer> c);
> }
> 
> interface IntegerConsumer {
>     void foo(IntConsumer c);
> }
> 
> // We should get a warning here...
> interface Test extends ConsumerOfInteger, IntegerConsumer {
> }
> 
> 
> The cause of the bug is that ambiguities are detected on a per-method basis, by checking whether a method is part of an ambiguity pair when we visit that method. So if the methods in an ambiguity pair are inherited from two distinct supertypes, we'll miss the ambiguity.
> 
> To fix the problem, we need to look for ambiguities on a per-class level, checking all pairs of methods. However, it's not that simple - we only want to "blame" a class when that class itself, and not some supertype, is responsible for creating the ambiguity. For example, any interface extending `Spliterator.OfInt` will automatically inherit the two ambiguities mentioned above, but these are not the interface's fault so to speak so no warning should be generated. Making things more complicated is the fact that methods can be overridden and declared in generic classes so they only conflict in some subtypes, etc.
> 
> So we generate the warning when there are two methods m1 and m2 in a class C such that:
> 
> * m1 and m2 consitiute a "potentially ambiguous overload" (using the same definition as before)
> * There is no direct supertype T of C such that m1 and m2, or some methods they override, both exist in T and constitute a "potentially ambiguous overload" as members of T
> * We haven't already generated a warning for either m1 or m2 in class C
> 
> If either method is declared in C, we locate the warning there, but when both methods are inherited, there's no method declaration to point at so the warning is instead located at the class declaration.
> 
> I noticed a couple of other minor bugs; these are also being fixed here:
> 
> (1) For inherited methods, the method signatures were being reported as they are declared, rather than in the context of the class being visited. As a result, when a methods is inherited from a generic supertype, the ambiguity is less clear. Here's an example:
> 
> interface Upper<T> {
>     void foo(T c);
> }
> 
> interface Lower extends Upper<IntConsumer> {
>     void foo(Consumer<Integer> c);
> }
> 
> Currently, the error is reported as:
> 
> warning: [overloads] foo(Consumer<Integer>) in Lower is potentially ambiguous with foo(T) in Upper
> 
> Reporting the method signatures in the context of the class being visited makes the ambiguity clearer:
> 
> warning: [overloads] foo(Consumer<Integer>) in Lower is potentially ambiguous with foo(IntConsumer) in Upper
> 
> 
> (2) When a method is identified as part of an ambiguous pair, we were setting a `POTENTIALLY_AMBIGUOUS` flag on it. This caused it to be forever excluded from future warnings. For methods that are declared in the class we're visiting, this makes sense, but it doesn't make sense for inherited methods, because it disqualifies them from participating in the analysis of any other class that also inherits them.
> 
> As a result, for a class like the one below, the compiler was only generating one warning instead of three:
> 
> public interface SuperIface {
>     void foo(Consumer<Integer> c);
> }
> 
> public interface I1 extends SuperIface { 
>     void foo(IntConsumer c);        // warning was generated here
> }   
> 
> public interface I2 extends SuperIface { 
>     void foo(IntConsumer c);        // no warning was generated here
> }   
> 
> public interface I3 extends SuperIface { 
>     void foo(IntConsumer c);        // no warning was generated here
> }   
> 
> 
> With this patch the `POTENTIALLY_AMBIGUOUS` flag is no longer needed. I wasn't sure whether to renumber all the subsequent flags, or just leave an empty placeholder, so I chose the latter.
> 
> Finally, this fix uncovers new warnings in `java.base` and `java.desktop`, so these are now suppressed in the patch.

Archie L. Cobbs has updated the pull request incrementally with one additional commit since the last revision:

  Remove @SuppressWarnings("overloads") annotations that were added but not needed.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12645/files
  - new: https://git.openjdk.org/jdk/pull/12645/files/591e220c..88a5f993

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12645&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12645&range=00-01

  Stats: 3 lines in 3 files changed: 0 ins; 3 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/12645.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12645/head:pull/12645

PR: https://git.openjdk.org/jdk/pull/12645

From duke at openjdk.org  Tue Feb 21 01:42:43 2023
From: duke at openjdk.org (Archie L. Cobbs)
Date: Tue, 21 Feb 2023 01:42:43 GMT
Subject: RFR: 8026369: javac potentially ambiguous overload warning needs
 an improved scheme
In-Reply-To: <xVTkB9-V5fVop5Mix7Gk29Ix3JCtAlBZeHR-064qaw0=.b3e9d5c2-4def-4410-8a59-c8c25049f7e4@github.com>
References: <IMxp3iCK--jYJ5Ia04i6QPYfnCHQobVcsmlI5aJXdqc=.892abcb8-7f2a-4fe9-aea2-1b1d41098a6d@github.com>
 <xVTkB9-V5fVop5Mix7Gk29Ix3JCtAlBZeHR-064qaw0=.b3e9d5c2-4def-4410-8a59-c8c25049f7e4@github.com>
Message-ID: <YJgBr11LyHU8RSK4zrf_J_htDq3BwoPF3-lN7GghA8U=.6b265890-a328-4b5f-b0b5-4addbd8a9210@github.com>

On Mon, 20 Feb 2023 23:53:05 GMT, SWinxy <duke at openjdk.org> wrote:

> In the `AWTEventMulticaster` class(es), which interfaces are causing the ambiguity?

Ah - my apologies. Those got added during development but were not needed once all the bugs were worked out.

I've removed them and that will also eliminate `client` and `i18n` from review. Thanks!

-------------

PR: https://git.openjdk.org/jdk/pull/12645

From yyang at openjdk.org  Tue Feb 21 02:37:05 2023
From: yyang at openjdk.org (Yi Yang)
Date: Tue, 21 Feb 2023 02:37:05 GMT
Subject: RFR: 8143900: OptimizeStringConcat has an opaque dependency on
 Integer.sizeTable field
Message-ID: <wVJP9KUVBORqE2Y2rPoPzePyKqbUTiE6fKiS1iOw9j4=.91a2c4c5-6da7-461e-8d65-d6e41bb5f4ff@github.com>

Hi, can I have a review for this patch? I noticed a strange field Integer.sizeTable, after digging into its history, I think it could be replaced by an in-place array allocation and initialization.

Thanks.

-------------

Commit messages:
 - 8143900 OptimizeStringConcat has an opaque dependency on Integer.sizeTable field

Changes: https://git.openjdk.org/jdk/pull/12680/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12680&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8143900
  Stats: 105 lines in 3 files changed: 43 ins; 53 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/12680.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12680/head:pull/12680

PR: https://git.openjdk.org/jdk/pull/12680

From duke at openjdk.org  Tue Feb 21 03:39:46 2023
From: duke at openjdk.org (Tingjun Yuan)
Date: Tue, 21 Feb 2023 03:39:46 GMT
Subject: RFR: 8302818: Optimize wrapper sets and immutable sets of Enums
 [v5]
In-Reply-To: <rpefqcimsLU_qQs5U_F1GSqdXJxD3YtqRLH7FEwN3hU=.aaf15809-464b-43a3-a1e2-758046d7bb52@github.com>
References: <rpefqcimsLU_qQs5U_F1GSqdXJxD3YtqRLH7FEwN3hU=.aaf15809-464b-43a3-a1e2-758046d7bb52@github.com>
Message-ID: <iCUdc_FIwQLHeuCd3BDI_JKZMAC0Kup-klsAWtx1Z6s=.78de1e8a-2df2-4b2f-9ebe-ee9170ac86b3@github.com>

> Currently, the two subclasses of `java.util.EnumSet` optimize bulk operations when the argument is also a `EnumSet`, but there is no such optimization for wrapper sets (returned by `Collections.unmodifiableSet`, `Collections.synchronizedSet`, etc.) and immutable sets (returned by `Set.of` methods) of `Enum`s.
> 
> This PR introduces optimization classes for these situations.  No public APIs are changed.

Tingjun Yuan has updated the pull request incrementally with one additional commit since the last revision:

  Set.copyOf: need defensive copy

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12498/files
  - new: https://git.openjdk.org/jdk/pull/12498/files/b9699bfe..0e0b2bf1

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12498&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12498&range=03-04

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/12498.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12498/head:pull/12498

PR: https://git.openjdk.org/jdk/pull/12498

From duke at openjdk.org  Tue Feb 21 06:54:48 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Tue, 21 Feb 2023 06:54:48 GMT
Subject: RFR: 8302871: Speed up StringLatin1.regionMatchesCI [v5]
In-Reply-To: <dnsiX3nRffjGjZXJG7lMAZj2FktEl2Wc1XfFthQ4iJs=.8c41438a-80a4-468f-ae0b-7322c9d6d952@github.com>
References: <dnsiX3nRffjGjZXJG7lMAZj2FktEl2Wc1XfFthQ4iJs=.8c41438a-80a4-468f-ae0b-7322c9d6d952@github.com>
Message-ID: <dgsG0NP-afd68wkXcdpnIS6lRh21-cF1wDsq9mDGnl4=.daf72737-5155-44ef-a6bd-9122acf0feae@github.com>

> This PR suggests we can speed up `StringLatin1.regionMatchesCI` by applying 'the oldest ASCII trick in the book'.
> 
> The new static method `CharacterDataLatin1.equalsIgnoreCase` compares two latin1 bytes for equality ignoring case. `StringLatin1.regionMatchesCI` is updated to use `equalsIgnoreCase`
> 
> To verify the correctness of `equalsIgnoreCase`, a new test is added  to `EqualsIgnoreCase` with an exhaustive verification that all 256x256 latin1 code point pairs have an `equalsIgnoreCase` consistent with Character.toUpperCase, Character.toLowerCase.
> 
> Performance is tested for matching and mismatching cases of code point pairs picked from the ASCII letter, ASCII number and latin1 letter ranges. Results in the first comment below.

Eirik Bjorsnos has updated the pull request incrementally with one additional commit since the last revision:

  Spell fix for 'exhaustive' in comments in sun/text/resources

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12632/files
  - new: https://git.openjdk.org/jdk/pull/12632/files/03d3e2cb..5e9927a4

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12632&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12632&range=03-04

  Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/12632.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12632/head:pull/12632

PR: https://git.openjdk.org/jdk/pull/12632

From duke at openjdk.org  Tue Feb 21 06:58:52 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Tue, 21 Feb 2023 06:58:52 GMT
Subject: RFR: 8302871: Speed up StringLatin1.regionMatchesCI [v6]
In-Reply-To: <dnsiX3nRffjGjZXJG7lMAZj2FktEl2Wc1XfFthQ4iJs=.8c41438a-80a4-468f-ae0b-7322c9d6d952@github.com>
References: <dnsiX3nRffjGjZXJG7lMAZj2FktEl2Wc1XfFthQ4iJs=.8c41438a-80a4-468f-ae0b-7322c9d6d952@github.com>
Message-ID: <0axKMeojwnFwgufDJPLLALvqougnoM2d5FRMVCxoHtc=.dca5737d-97b4-4f48-84ee-f120e16eb31b@github.com>

> This PR suggests we can speed up `StringLatin1.regionMatchesCI` by applying 'the oldest ASCII trick in the book'.
> 
> The new static method `CharacterDataLatin1.equalsIgnoreCase` compares two latin1 bytes for equality ignoring case. `StringLatin1.regionMatchesCI` is updated to use `equalsIgnoreCase`
> 
> To verify the correctness of `equalsIgnoreCase`, a new test is added  to `EqualsIgnoreCase` with an exhaustive verification that all 256x256 latin1 code point pairs have an `equalsIgnoreCase` consistent with Character.toUpperCase, Character.toLowerCase.
> 
> Performance is tested for matching and mismatching cases of code point pairs picked from the ASCII letter, ASCII number and latin1 letter ranges. Results in the first comment below.

Eirik Bjorsnos has updated the pull request incrementally with one additional commit since the last revision:

  Revert "Spell fix for 'exhaustive' in comments in sun/text/resources"
  
  This reverts commit 5e9927a4b35e157fd3fa72fd2663c8bfbecf32bb.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12632/files
  - new: https://git.openjdk.org/jdk/pull/12632/files/5e9927a4..b8139961

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12632&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12632&range=04-05

  Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/12632.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12632/head:pull/12632

PR: https://git.openjdk.org/jdk/pull/12632

From duke at openjdk.org  Tue Feb 21 06:59:47 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Tue, 21 Feb 2023 06:59:47 GMT
Subject: RFR: 8302877: Speed up latin1 case conversions [v2]
In-Reply-To: <cf9hc-SBdgzB1lpqXGLHKcjT4-T9hLaMs1cCccqBiak=.f7b99e9d-3206-4e67-976f-ea0492ec6b06@github.com>
References: <cf9hc-SBdgzB1lpqXGLHKcjT4-T9hLaMs1cCccqBiak=.f7b99e9d-3206-4e67-976f-ea0492ec6b06@github.com>
Message-ID: <mcw6LoHgPL6U3ss2fL6VJPb_YWOs4R-2Xx3G9SLfENk=.fc32c614-53af-42eb-a476-1c91a58ec0b2@github.com>

> This PR suggests we speed up Character.toUpperCase and Character.toLowerCase for latin1 code points by applying the 'oldest ASCII trick in the book'.
> 
> This takes advantage of the fact that latin1 uppercase code points are always 0x20 lower than their lowercase (with the exception of two code points which uppercase out of latin1).
> 
> To verify the correctness of the new implementation, the test `Latin1CaseConversion` is added with an exhaustive verification of toUpperCase/toLowerCase for all latin1 code points.
> 
> The implementation needs to balance the performance of the various ranges in latin1. An effort has been made to favour operations on ASCII code points, without causing excessive regression for higher code points.
> 
> Performance is benchmarked for 7 chosen sample code points, each representing a range or a special-case.  Results in the first comment.

Eirik Bjorsnos has updated the pull request incrementally with one additional commit since the last revision:

  Spell fix for 'exhaustive' in comments in sun/text/resources

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12623/files
  - new: https://git.openjdk.org/jdk/pull/12623/files/57a27d39..70c624d7

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12623&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12623&range=00-01

  Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/12623.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12623/head:pull/12623

PR: https://git.openjdk.org/jdk/pull/12623

From duke at openjdk.org  Tue Feb 21 08:01:28 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Tue, 21 Feb 2023 08:01:28 GMT
Subject: RFR: 8302877: Speed up latin1 case conversions [v2]
In-Reply-To: <UzZau1cG5pNwApw4QrS4HIWlQDXgj32G617BC_TdYK8=.bb876d03-c466-4dbc-8e3c-d62dc1373aa7@github.com>
References: <cf9hc-SBdgzB1lpqXGLHKcjT4-T9hLaMs1cCccqBiak=.f7b99e9d-3206-4e67-976f-ea0492ec6b06@github.com>
 <CgKt3Q0k0hCkg4xxCRBOPDX6fi-zQWxuHX0zoKT3Pio=.af2d552c-dbfe-4acc-a738-94e2e6c3b25d@github.com>
 <Q1CJmrbsLmHneQMQDvFuSnHwlaFwzs_4FQSgw5Woc7U=.ce74d4ee-941e-40ec-8cd5-7d1d5d0c0b81@github.com>
 <UzZau1cG5pNwApw4QrS4HIWlQDXgj32G617BC_TdYK8=.bb876d03-c466-4dbc-8e3c-d62dc1373aa7@github.com>
Message-ID: <jZ_2aUBT_oYutGxgiMmh5EMLYWoj-z93VqEsuHS5yQM=.1db513b8-4bf7-466a-a033-c912647b9198@github.com>

On Tue, 21 Feb 2023 00:14:20 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> I did an 'exchaustive' search for 'exchaustive' across the code base and found  two comments in `LocaleData` and `LocaleData.cldr` in `jdk/test/jdk/sun/text/resources`.
>> 
>> Would you like me to update these as well while we're here, or should we avoid getting out scope for this PR?
>
> I'd appreciate it. I don't mind fixing it with this PR.

Thanks Naoto, I have fixed the spelling in these two unrelated files.

-------------

PR: https://git.openjdk.org/jdk/pull/12623

From duke at openjdk.org  Tue Feb 21 09:37:28 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Tue, 21 Feb 2023 09:37:28 GMT
Subject: RFR: 8302877: Speed up latin1 case conversions [v2]
In-Reply-To: <mcw6LoHgPL6U3ss2fL6VJPb_YWOs4R-2Xx3G9SLfENk=.fc32c614-53af-42eb-a476-1c91a58ec0b2@github.com>
References: <cf9hc-SBdgzB1lpqXGLHKcjT4-T9hLaMs1cCccqBiak=.f7b99e9d-3206-4e67-976f-ea0492ec6b06@github.com>
 <mcw6LoHgPL6U3ss2fL6VJPb_YWOs4R-2Xx3G9SLfENk=.fc32c614-53af-42eb-a476-1c91a58ec0b2@github.com>
Message-ID: <Dc0Aa1UAJeikMEJlfTKSSB1lbBwPY3Bu7b3cSxRkf48=.9e8c2b19-9654-4885-9174-edb852df5e78@github.com>

On Tue, 21 Feb 2023 06:59:47 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

>> This PR suggests we speed up Character.toUpperCase and Character.toLowerCase for latin1 code points by applying the 'oldest ASCII trick in the book'.
>> 
>> This takes advantage of the fact that latin1 uppercase code points are always 0x20 lower than their lowercase (with the exception of two code points which uppercase out of latin1).
>> 
>> To verify the correctness of the new implementation, the test `Latin1CaseConversion` is added with an exhaustive verification of toUpperCase/toLowerCase for all latin1 code points.
>> 
>> The implementation needs to balance the performance of the various ranges in latin1. An effort has been made to favour operations on ASCII code points, without causing excessive regression for higher code points.
>> 
>> Performance is benchmarked for 7 chosen sample code points, each representing a range or a special-case.  Results in the first comment.
>
> Eirik Bjorsnos has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Spell fix for 'exhaustive' in comments in sun/text/resources

A site note: Early and crude experiements using the Vector API indicate that the 'oldest ASCII trick in the book' vectorizes pretty well.

Here's a benchmark comparing the strings "helloworld" and "HelloWorld" repeated 1024 times, followed by either 'A' or 'B' (to force a an expensive mismatch):


Benchmark                    (size)  Mode  Cnt     Score    Error  Units
EqualsIgnoreCase.scalar        1024  avgt   15  6225.624 ? 89.182  ns/op
EqualsIgnoreCase.vectorized    1024  avgt   15  1246.110 ? 14.767  ns/op


I have the feeling that most case-insensitive comparisons are pretty short, so not sure how useful this is IRL.

-------------

PR: https://git.openjdk.org/jdk/pull/12623

From duke at openjdk.org  Tue Feb 21 10:03:28 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Tue, 21 Feb 2023 10:03:28 GMT
Subject: RFR: 8302877: Speed up latin1 case conversions [v2]
In-Reply-To: <Dc0Aa1UAJeikMEJlfTKSSB1lbBwPY3Bu7b3cSxRkf48=.9e8c2b19-9654-4885-9174-edb852df5e78@github.com>
References: <cf9hc-SBdgzB1lpqXGLHKcjT4-T9hLaMs1cCccqBiak=.f7b99e9d-3206-4e67-976f-ea0492ec6b06@github.com>
 <mcw6LoHgPL6U3ss2fL6VJPb_YWOs4R-2Xx3G9SLfENk=.fc32c614-53af-42eb-a476-1c91a58ec0b2@github.com>
 <Dc0Aa1UAJeikMEJlfTKSSB1lbBwPY3Bu7b3cSxRkf48=.9e8c2b19-9654-4885-9174-edb852df5e78@github.com>
Message-ID: <qWTVI7TOpTidxp-44uAW4EaHNw0DQ2NwQg-T9JCcutY=.7c1ccf20-fef4-4fe8-9731-f60e437e47b3@github.com>

On Tue, 21 Feb 2023 09:33:07 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

> I have the feeling that most case-insensitive comparisons are pretty short, so not sure how useful this is IRL.

There seems to be a win from strings of size 32 bytes upwards. (That's probably longer than most keys in TreeMaps using String.CASE_INSENSITIVE_ORDER, such as j.n.h.HttpHeaders)


Benchmark                    (size)  Mode  Cnt   Score   Error  Units
EqualsIgnoreCase.scalar          16  avgt    2  20.608          ns/op
EqualsIgnoreCase.scalar          32  avgt    2  36.510          ns/op
EqualsIgnoreCase.vectorized      16  avgt    2  18.601          ns/op
EqualsIgnoreCase.vectorized      32  avgt    2  12.795          ns/op


This is outside scope for this PR, I just wanted to leave a trace of this observation here for future record.

-------------

PR: https://git.openjdk.org/jdk/pull/12623

From redestad at openjdk.org  Tue Feb 21 10:40:33 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Tue, 21 Feb 2023 10:40:33 GMT
Subject: RFR: 8302877: Speed up latin1 case conversions [v2]
In-Reply-To: <mcw6LoHgPL6U3ss2fL6VJPb_YWOs4R-2Xx3G9SLfENk=.fc32c614-53af-42eb-a476-1c91a58ec0b2@github.com>
References: <cf9hc-SBdgzB1lpqXGLHKcjT4-T9hLaMs1cCccqBiak=.f7b99e9d-3206-4e67-976f-ea0492ec6b06@github.com>
 <mcw6LoHgPL6U3ss2fL6VJPb_YWOs4R-2Xx3G9SLfENk=.fc32c614-53af-42eb-a476-1c91a58ec0b2@github.com>
Message-ID: <vWnEYhacyhcGD-gGaB22K8wLvQU_3ZF9m0cv1IJxdrs=.c0fc41ee-d618-4f97-b3b5-b67b098187df@github.com>

On Tue, 21 Feb 2023 06:59:47 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

>> This PR suggests we speed up Character.toUpperCase and Character.toLowerCase for latin1 code points by applying the 'oldest ASCII trick in the book'.
>> 
>> This takes advantage of the fact that latin1 uppercase code points are always 0x20 lower than their lowercase (with the exception of two code points which uppercase out of latin1).
>> 
>> To verify the correctness of the new implementation, the test `Latin1CaseConversion` is added with an exhaustive verification of toUpperCase/toLowerCase for all latin1 code points.
>> 
>> The implementation needs to balance the performance of the various ranges in latin1. An effort has been made to favour operations on ASCII code points, without causing excessive regression for higher code points.
>> 
>> Performance is benchmarked for 7 chosen sample code points, each representing a range or a special-case.  Results in the first comment.
>
> Eirik Bjorsnos has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Spell fix for 'exhaustive' in comments in sun/text/resources

Looks good. Some nits inline

src/java.base/share/classes/java/lang/CharacterDataLatin1.java.template line 142:

> 140:         }
> 141:         int l = ch | 0x20; // Lowercase using 'oldest ASCII trick in the book'
> 142:         if ( l <= 'z' // In range a-z

Suggestion:

        if (l <= 'z' // In range a-z

test/micro/org/openjdk/bench/java/lang/Characters.java line 92:

> 90:     @Measurement(iterations = 5, time = 1)
> 91:     @Fork(3)
> 92:     public static class Latin1CaseConversions {

Not sure if qualifying this as "Latin1" is necessary, even though that's what you've focused on for this PR. We could easily add some codePoints outside of the latin1 range (now or later) without changing the test. 

While having a switch with some readable names is a nice touch I think we should additionally allow integer codePoint as-is to keep it in line with the outer class, e.g. `default -> Integer.parseInt(codePoint);`

-------------

Marked as reviewed by redestad (Reviewer).

PR: https://git.openjdk.org/jdk/pull/12623

From duke at openjdk.org  Tue Feb 21 11:12:18 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Tue, 21 Feb 2023 11:12:18 GMT
Subject: RFR: 8302877: Speed up latin1 case conversions [v3]
In-Reply-To: <cf9hc-SBdgzB1lpqXGLHKcjT4-T9hLaMs1cCccqBiak=.f7b99e9d-3206-4e67-976f-ea0492ec6b06@github.com>
References: <cf9hc-SBdgzB1lpqXGLHKcjT4-T9hLaMs1cCccqBiak=.f7b99e9d-3206-4e67-976f-ea0492ec6b06@github.com>
Message-ID: <iiq-I9Y0N-vXz5xrdxsD4QMyIlM3YhUdz3jjNktCn9Y=.a5979762-dbbb-4a4f-a9e6-feffdc17beb6@github.com>

> This PR suggests we speed up Character.toUpperCase and Character.toLowerCase for latin1 code points by applying the 'oldest ASCII trick in the book'.
> 
> This takes advantage of the fact that latin1 uppercase code points are always 0x20 lower than their lowercase (with the exception of two code points which uppercase out of latin1).
> 
> To verify the correctness of the new implementation, the test `Latin1CaseConversion` is added with an exhaustive verification of toUpperCase/toLowerCase for all latin1 code points.
> 
> The implementation needs to balance the performance of the various ranges in latin1. An effort has been made to favour operations on ASCII code points, without causing excessive regression for higher code points.
> 
> Performance is benchmarked for 7 chosen sample code points, each representing a range or a special-case.  Results in the first comment.

Eirik Bjorsnos has updated the pull request incrementally with three additional commits since the last revision:

 - Allow any integer codePoint by defaulting to Integer.parseInt
 - Rename Latin1CaseConversions to just CaseConversions
 - Remove a whitespace following 'if ('

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12623/files
  - new: https://git.openjdk.org/jdk/pull/12623/files/70c624d7..bff999c4

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12623&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12623&range=01-02

  Stats: 3 lines in 2 files changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/12623.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12623/head:pull/12623

PR: https://git.openjdk.org/jdk/pull/12623

From duke at openjdk.org  Tue Feb 21 11:12:23 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Tue, 21 Feb 2023 11:12:23 GMT
Subject: RFR: 8302877: Speed up latin1 case conversions [v2]
In-Reply-To: <vWnEYhacyhcGD-gGaB22K8wLvQU_3ZF9m0cv1IJxdrs=.c0fc41ee-d618-4f97-b3b5-b67b098187df@github.com>
References: <cf9hc-SBdgzB1lpqXGLHKcjT4-T9hLaMs1cCccqBiak=.f7b99e9d-3206-4e67-976f-ea0492ec6b06@github.com>
 <mcw6LoHgPL6U3ss2fL6VJPb_YWOs4R-2Xx3G9SLfENk=.fc32c614-53af-42eb-a476-1c91a58ec0b2@github.com>
 <vWnEYhacyhcGD-gGaB22K8wLvQU_3ZF9m0cv1IJxdrs=.c0fc41ee-d618-4f97-b3b5-b67b098187df@github.com>
Message-ID: <LXmWyg_KOlELUH8Ca98n3gVZqvIrRQ0fNxhfL19TRwo=.3d3f57a8-6e9a-411a-8ce2-dea7d3417a1a@github.com>

On Tue, 21 Feb 2023 10:29:24 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> Eirik Bjorsnos has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Spell fix for 'exhaustive' in comments in sun/text/resources
>
> src/java.base/share/classes/java/lang/CharacterDataLatin1.java.template line 142:
> 
>> 140:         }
>> 141:         int l = ch | 0x20; // Lowercase using 'oldest ASCII trick in the book'
>> 142:         if ( l <= 'z' // In range a-z
> 
> Suggestion:
> 
>         if (l <= 'z' // In range a-z

Fixed! (My IDE does not highlight this code, making it a bit harder to spot mistakes like this)

> test/micro/org/openjdk/bench/java/lang/Characters.java line 92:
> 
>> 90:     @Measurement(iterations = 5, time = 1)
>> 91:     @Fork(3)
>> 92:     public static class Latin1CaseConversions {
> 
> Not sure if qualifying this as "Latin1" is necessary, even though that's what you've focused on for this PR. We could easily add some codePoints outside of the latin1 range (now or later) without changing the test. 
> 
> While having a switch with some readable names is a nice touch I think we should additionally allow integer codePoint as-is to keep it in line with the outer class, e.g. `default -> Integer.parseInt(codePoint);`

You are probably right that Latin1 is a bit narrow here, removing the prefix.

I added Integer.parseInt as the default, good idea!

-------------

PR: https://git.openjdk.org/jdk/pull/12623

From duke at openjdk.org  Tue Feb 21 11:14:13 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Tue, 21 Feb 2023 11:14:13 GMT
Subject: RFR: 8302871: Speed up StringLatin1.regionMatchesCI [v7]
In-Reply-To: <dnsiX3nRffjGjZXJG7lMAZj2FktEl2Wc1XfFthQ4iJs=.8c41438a-80a4-468f-ae0b-7322c9d6d952@github.com>
References: <dnsiX3nRffjGjZXJG7lMAZj2FktEl2Wc1XfFthQ4iJs=.8c41438a-80a4-468f-ae0b-7322c9d6d952@github.com>
Message-ID: <AhNijA3f_Yl5Ornr9pqngR3yaepTQNEJeposarKW-Wg=.90a0b345-88dc-4648-a0fb-c83d1dd7e9d5@github.com>

> This PR suggests we can speed up `StringLatin1.regionMatchesCI` by applying 'the oldest ASCII trick in the book'.
> 
> The new static method `CharacterDataLatin1.equalsIgnoreCase` compares two latin1 bytes for equality ignoring case. `StringLatin1.regionMatchesCI` is updated to use `equalsIgnoreCase`
> 
> To verify the correctness of `equalsIgnoreCase`, a new test is added  to `EqualsIgnoreCase` with an exhaustive verification that all 256x256 latin1 code point pairs have an `equalsIgnoreCase` consistent with Character.toUpperCase, Character.toLowerCase.
> 
> Performance is tested for matching and mismatching cases of code point pairs picked from the ASCII letter, ASCII number and latin1 letter ranges. Results in the first comment below.

Eirik Bjorsnos has updated the pull request incrementally with one additional commit since the last revision:

  Remove whitespace following '('

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12632/files
  - new: https://git.openjdk.org/jdk/pull/12632/files/b8139961..d7b1c164

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12632&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12632&range=05-06

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/12632.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12632/head:pull/12632

PR: https://git.openjdk.org/jdk/pull/12632

From duke at openjdk.org  Tue Feb 21 11:22:33 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Tue, 21 Feb 2023 11:22:33 GMT
Subject: RFR: 8302877: Speed up latin1 case conversions [v3]
In-Reply-To: <iiq-I9Y0N-vXz5xrdxsD4QMyIlM3YhUdz3jjNktCn9Y=.a5979762-dbbb-4a4f-a9e6-feffdc17beb6@github.com>
References: <cf9hc-SBdgzB1lpqXGLHKcjT4-T9hLaMs1cCccqBiak=.f7b99e9d-3206-4e67-976f-ea0492ec6b06@github.com>
 <iiq-I9Y0N-vXz5xrdxsD4QMyIlM3YhUdz3jjNktCn9Y=.a5979762-dbbb-4a4f-a9e6-feffdc17beb6@github.com>
Message-ID: <uMH3tqRBRQH_5qCi2Y1iz9gh54_sVw38YbJ5kfbT4vk=.e67ecee7-a713-428a-b87e-9cd67a41dcdd@github.com>

On Tue, 21 Feb 2023 11:12:18 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

>> This PR suggests we speed up Character.toUpperCase and Character.toLowerCase for latin1 code points by applying the 'oldest ASCII trick in the book'.
>> 
>> This takes advantage of the fact that latin1 uppercase code points are always 0x20 lower than their lowercase (with the exception of two code points which uppercase out of latin1).
>> 
>> To verify the correctness of the new implementation, the test `Latin1CaseConversion` is added with an exhaustive verification of toUpperCase/toLowerCase for all latin1 code points.
>> 
>> The implementation needs to balance the performance of the various ranges in latin1. An effort has been made to favour operations on ASCII code points, without causing excessive regression for higher code points.
>> 
>> Performance is benchmarked for 7 chosen sample code points, each representing a range or a special-case.  Results in the first comment.
>
> Eirik Bjorsnos has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Allow any integer codePoint by defaulting to Integer.parseInt
>  - Rename Latin1CaseConversions to just CaseConversions
>  - Remove a whitespace following 'if ('

Thanks for your review and JBS juggling, Claes! 

I'll wait for a final word from @naotoj before integrating.

-------------

PR: https://git.openjdk.org/jdk/pull/12623

From redestad at openjdk.org  Tue Feb 21 11:24:38 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Tue, 21 Feb 2023 11:24:38 GMT
Subject: RFR: 8302871: Speed up StringLatin1.regionMatchesCI [v7]
In-Reply-To: <AhNijA3f_Yl5Ornr9pqngR3yaepTQNEJeposarKW-Wg=.90a0b345-88dc-4648-a0fb-c83d1dd7e9d5@github.com>
References: <dnsiX3nRffjGjZXJG7lMAZj2FktEl2Wc1XfFthQ4iJs=.8c41438a-80a4-468f-ae0b-7322c9d6d952@github.com>
 <AhNijA3f_Yl5Ornr9pqngR3yaepTQNEJeposarKW-Wg=.90a0b345-88dc-4648-a0fb-c83d1dd7e9d5@github.com>
Message-ID: <lTiIOXTbicgBCTT8VaCf3b7FCI__XUub3O5RCPlEOh8=.2e052c53-7837-4517-b3f3-7b9dce93b8f2@github.com>

On Tue, 21 Feb 2023 11:14:13 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

>> This PR suggests we can speed up `StringLatin1.regionMatchesCI` by applying 'the oldest ASCII trick in the book'.
>> 
>> The new static method `CharacterDataLatin1.equalsIgnoreCase` compares two latin1 bytes for equality ignoring case. `StringLatin1.regionMatchesCI` is updated to use `equalsIgnoreCase`
>> 
>> To verify the correctness of `equalsIgnoreCase`, a new test is added  to `EqualsIgnoreCase` with an exhaustive verification that all 256x256 latin1 code point pairs have an `equalsIgnoreCase` consistent with Character.toUpperCase, Character.toLowerCase.
>> 
>> Performance is tested for matching and mismatching cases of code point pairs picked from the ASCII letter, ASCII number and latin1 letter ranges. Results in the first comment below.
>
> Eirik Bjorsnos has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove whitespace following '('

Marked as reviewed by redestad (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/12632

From thartmann at openjdk.org  Tue Feb 21 11:31:00 2023
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Tue, 21 Feb 2023 11:31:00 GMT
Subject: RFR: 8289552: Make intrinsic conversions between bit
 representations of half precision values and floats [v13]
In-Reply-To: <cxn5tjWHWpBzE7cOSGkqvriYsku5W6097w4bua8UtNw=.fb7e49b5-2da6-4bad-a671-6d466c1da7e3@github.com>
References: <jSD6qbxQoXW38OmtLWXZUBQ1ntARgrmhFs3vz45Oehs=.fd1a2fd2-dd39-4c5c-ad18-dcf80d459ff9@github.com>
 <dlR1hXuQFlInPmQJnRhc-h0kVh-vjxQ_iDHdaOAutY8=.dbac1fc9-5a12-4b4b-91ac-d542a828a92d@github.com>
 <66be8SJdxPOqmqsQ1YIwS4zM4GwPerypGIf8IbfxhRs=.1d03c94a-f3e5-40ae-999e-bdd5f328170d@github.com>
 <cxn5tjWHWpBzE7cOSGkqvriYsku5W6097w4bua8UtNw=.fb7e49b5-2da6-4bad-a671-6d466c1da7e3@github.com>
Message-ID: <UgwMh-UiDO_UyoD0DWxFThgXsEFW9uy4rKy36Y6_v8g=.28dd2235-e3ab-4874-89fd-e7a825e91263@github.com>

On Tue, 11 Oct 2022 17:00:53 GMT, Smita Kamath <svkamath at openjdk.org> wrote:

>> I started new testing.
>
> @vnkozlov Thank you for reviewing the patch.

There is an issue with the `_floatToFloat16` intrinsic, leading to incorrect results: [JDK-8302976](https://bugs.openjdk.org/browse/JDK-8302976). @smita-kamath, could you please have a look? Thanks.

-------------

PR: https://git.openjdk.org/jdk/pull/9781

From prappo at openjdk.org  Tue Feb 21 12:17:10 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Tue, 21 Feb 2023 12:17:10 GMT
Subject: RFR: 8302981: Fix a typo in the doc comment for
 java.lang.Record.equals
Message-ID: <OBDkqWn4xawRGJMlZB2Lcm_z9eQ1ZD7pKBJQ8KOsVyg=.d843b460-97fa-462b-bcb8-863da5855dcb@github.com>

Please review this trivial fix.

-------------

Commit messages:
 - Initial commit

Changes: https://git.openjdk.org/jdk/pull/12689/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12689&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8302981
  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/12689.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12689/head:pull/12689

PR: https://git.openjdk.org/jdk/pull/12689

From jpai at openjdk.org  Tue Feb 21 12:49:25 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 21 Feb 2023 12:49:25 GMT
Subject: RFR: 8302981: Fix a typo in the doc comment for
 java.lang.Record.equals
In-Reply-To: <OBDkqWn4xawRGJMlZB2Lcm_z9eQ1ZD7pKBJQ8KOsVyg=.d843b460-97fa-462b-bcb8-863da5855dcb@github.com>
References: <OBDkqWn4xawRGJMlZB2Lcm_z9eQ1ZD7pKBJQ8KOsVyg=.d843b460-97fa-462b-bcb8-863da5855dcb@github.com>
Message-ID: <miPuoIxWw77pvQXe_Z9UJMs_b20IplxhPSH415Trg9s=.26d2e1b0-b248-4521-8cc8-bde00471131e@github.com>

On Tue, 21 Feb 2023 12:09:51 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> Please review this trivial fix.

Marked as reviewed by jpai (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/12689

From prappo at openjdk.org  Tue Feb 21 13:14:39 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Tue, 21 Feb 2023 13:14:39 GMT
Subject: Integrated: 8302981: Fix a typo in the doc comment for
 java.lang.Record.equals
In-Reply-To: <OBDkqWn4xawRGJMlZB2Lcm_z9eQ1ZD7pKBJQ8KOsVyg=.d843b460-97fa-462b-bcb8-863da5855dcb@github.com>
References: <OBDkqWn4xawRGJMlZB2Lcm_z9eQ1ZD7pKBJQ8KOsVyg=.d843b460-97fa-462b-bcb8-863da5855dcb@github.com>
Message-ID: <uR9v2Xbb6ug7SWw7g8a2uBBgwmFT4kKPqXXqGlq7gw4=.29a6cbaf-1c89-4f66-9135-fb5e9cb52dea@github.com>

On Tue, 21 Feb 2023 12:09:51 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> Please review this trivial fix.

This pull request has now been integrated.

Changeset: 8b20aa91
Author:    Pavel Rappo <prappo at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/8b20aa919b810fc5b3856b392bd0d8b1f882c895
Stats:     2 lines in 1 file changed: 0 ins; 0 del; 2 mod

8302981: Fix a typo in the doc comment for java.lang.Record.equals

Reviewed-by: jpai

-------------

PR: https://git.openjdk.org/jdk/pull/12689

From redestad at openjdk.org  Tue Feb 21 13:34:35 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Tue, 21 Feb 2023 13:34:35 GMT
Subject: RFR: 8302863: Speed up String::encodeASCII using countPositives
In-Reply-To: <jwOo63bHsKJ8IAcNj2C8MwCGeZ_SDXxsLT84uNz4mY8=.259edda2-bf61-449d-af8c-a4baa999eab1@github.com>
References: <xo42mWnM8O8-KsosrLsJwo2hR0ZuvrwlDfq9VUAA4nM=.c67cc391-6cd1-483e-bd24-4009605553af@github.com>
 <jwOo63bHsKJ8IAcNj2C8MwCGeZ_SDXxsLT84uNz4mY8=.259edda2-bf61-449d-af8c-a4baa999eab1@github.com>
Message-ID: <FGA7wPftIG2xuyw7WSF3-sTEIU7Z86WGNZjqqd118js=.341039d6-9ee6-4631-842e-7b633a5b7b17@github.com>

On Mon, 20 Feb 2023 21:40:41 GMT, Brett Okken <duke at openjdk.org> wrote:

>> When encoding Strings to US-ASCII we can speed up the happy path significantly by using `StringCoding.countPositives` as a speculative check for whether there are any chars that needs to be replaced by `'?'`. Once a non-ASCII char is encountered we fall back to the slow loop and replace as needed.
>> 
>> An alternative could be unrolling or using a byte array VarHandle, as show-cased by Brett Okken here: https://mail.openjdk.org/pipermail/core-libs-dev/2023-February/100573.html Having to replace chars with `?` is essentially an encoding error so it might be safe to assume this case is exceptional in practice.
>
> For the happy path of no encoding failures, this "trivial" change is a great improvement.

Thanks for reviewing - and thanks @bokken for inspiring this change.

-------------

PR: https://git.openjdk.org/jdk/pull/12640

From redestad at openjdk.org  Tue Feb 21 13:34:37 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Tue, 21 Feb 2023 13:34:37 GMT
Subject: Integrated: 8302863: Speed up String::encodeASCII using countPositives
In-Reply-To: <xo42mWnM8O8-KsosrLsJwo2hR0ZuvrwlDfq9VUAA4nM=.c67cc391-6cd1-483e-bd24-4009605553af@github.com>
References: <xo42mWnM8O8-KsosrLsJwo2hR0ZuvrwlDfq9VUAA4nM=.c67cc391-6cd1-483e-bd24-4009605553af@github.com>
Message-ID: <GvVPayRcMr_HbstEY2dhDqFE5BdLNRrFEuxSF45TQpA=.9fa2f3ac-f9b7-4fa6-a377-0984dd8b69f2@github.com>

On Sat, 18 Feb 2023 23:26:08 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> When encoding Strings to US-ASCII we can speed up the happy path significantly by using `StringCoding.countPositives` as a speculative check for whether there are any chars that needs to be replaced by `'?'`. Once a non-ASCII char is encountered we fall back to the slow loop and replace as needed.
> 
> An alternative could be unrolling or using a byte array VarHandle, as show-cased by Brett Okken here: https://mail.openjdk.org/pipermail/core-libs-dev/2023-February/100573.html Having to replace chars with `?` is essentially an encoding error so it might be safe to assume this case is exceptional in practice.

This pull request has now been integrated.

Changeset: 92dfa117
Author:    Claes Redestad <redestad at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/92dfa1175e4898fc491115e004380780b6862473
Stats:     24 lines in 1 file changed: 11 ins; 2 del; 11 mod

8302863: Speed up String::encodeASCII using countPositives

Reviewed-by: alanb

-------------

PR: https://git.openjdk.org/jdk/pull/12640

From alanb at openjdk.org  Tue Feb 21 14:19:11 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 21 Feb 2023 14:19:11 GMT
Subject: RFR: 8302899: Executors.newSingleThreadExecutor can use Cleaner to
 shutdown executor
Message-ID: <tBrSZRn1GdrWMSRUsdNNyAWpkuS_FvtLwLuUKut6LH0=.cd1a7fcb-dbcf-45eb-b3d3-72ba17087566@github.com>

Executors.newSingleThreadExecutor returns a delegating ExecutorService that has finalizer to shutdown the underlying TPE when the wrapper is finalizable. It goes back to JDK 6 and JDK-6399443. This is the last non-empty finalizer in java.base. Removing it will likely lead to bug reports/complaints as the current behavior goes back to 2006. So the proposal is to just replace it with a Cleaner, trivially done in this case. As part of the changes, I've replaced the existing test with a more modern test that exercises more scenarios.

-------------

Commit messages:
 - Replace older test
 - Initial commit

Changes: https://git.openjdk.org/jdk/pull/12675/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12675&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8302899
  Stats: 147 lines in 2 files changed: 52 ins; 19 del; 76 mod
  Patch: https://git.openjdk.org/jdk/pull/12675.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12675/head:pull/12675

PR: https://git.openjdk.org/jdk/pull/12675

From alanb at openjdk.org  Tue Feb 21 14:30:29 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 21 Feb 2023 14:30:29 GMT
Subject: RFR: 8302871: Speed up StringLatin1.regionMatchesCI [v7]
In-Reply-To: <AhNijA3f_Yl5Ornr9pqngR3yaepTQNEJeposarKW-Wg=.90a0b345-88dc-4648-a0fb-c83d1dd7e9d5@github.com>
References: <dnsiX3nRffjGjZXJG7lMAZj2FktEl2Wc1XfFthQ4iJs=.8c41438a-80a4-468f-ae0b-7322c9d6d952@github.com>
 <AhNijA3f_Yl5Ornr9pqngR3yaepTQNEJeposarKW-Wg=.90a0b345-88dc-4648-a0fb-c83d1dd7e9d5@github.com>
Message-ID: <hfJIZbrr5qSkn0BU1nyriYMyV9cFWN7e1iKHO-bvZks=.a829ef78-fe38-402a-877b-431591d23e15@github.com>

On Tue, 21 Feb 2023 11:14:13 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

>> This PR suggests we can speed up `StringLatin1.regionMatchesCI` by applying 'the oldest ASCII trick in the book'.
>> 
>> The new static method `CharacterDataLatin1.equalsIgnoreCase` compares two latin1 bytes for equality ignoring case. `StringLatin1.regionMatchesCI` is updated to use `equalsIgnoreCase`
>> 
>> To verify the correctness of `equalsIgnoreCase`, a new test is added  to `EqualsIgnoreCase` with an exhaustive verification that all 256x256 latin1 code point pairs have an `equalsIgnoreCase` consistent with Character.toUpperCase, Character.toLowerCase.
>> 
>> Performance is tested for matching and mismatching cases of code point pairs picked from the ASCII letter, ASCII number and latin1 letter ranges. Results in the first comment below.
>
> Eirik Bjorsnos has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove whitespace following '('

src/java.base/share/classes/java/lang/CharacterDataLatin1.java.template line 163:

> 161:         return mapChar;
> 162:     }
> 163:     /**

I assume you should insert a blank line between the two methods.

src/java.base/share/classes/java/lang/CharacterDataLatin1.java.template line 175:

> 173:          }
> 174:          // uppercase b1 using 'the oldest ASCII trick in the book'
> 175:          int U = b1 & 0xDF;

I'm sure some people reading this comment will wonder which book :-) It might be better to drop that bit and if possible, find a better name for "U" as normally variables start with a lower case.

-------------

PR: https://git.openjdk.org/jdk/pull/12632

From alanb at openjdk.org  Tue Feb 21 14:50:28 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 21 Feb 2023 14:50:28 GMT
Subject: RFR: 8302822:
 Method/Field/Constructor/RecordComponent::getGenericInfo() is not thread safe
In-Reply-To: <ESC9l0VKVQSY6Hc7YBSRQuMToI4OjcydJPQvKZDY6BQ=.a938539d-1380-4e2c-a1e7-c8b75c4afa52@github.com>
References: <1sDlqlKVNOobyFy71f7ud5uL8_WcMPi1qKNa4ltxFQ0=.63cffbd7-e11a-4d7d-9362-cf215a7584ce@github.com>
 <aiC6MkXHICLXZPGIidwhW-iOf2Rrl2vOwuNAzEGmix4=.42794134-5feb-43e8-ad7d-73d4c6e23def@github.com>
 <KnWJ2GDfC3tOc2BdBaC6ZTBunszrwAfwZrFWOIhQZcE=.7d680527-5595-4287-9da9-edd2e7ff2317@github.com>
 <ESC9l0VKVQSY6Hc7YBSRQuMToI4OjcydJPQvKZDY6BQ=.a938539d-1380-4e2c-a1e7-c8b75c4afa52@github.com>
Message-ID: <M7y13N2aYjnT35qQK96EQgVvpnm-C7i00gA4D1BzV6Q=.f55976b0-6c08-4982-908e-a2897ef196e8@github.com>

On Mon, 20 Feb 2023 22:26:21 GMT, David Holmes <dholmes at openjdk.org> wrote:

> I would also be concerned about the guarantee of idempotency from the factory method - I hope its requirements in that area are clearly documented.

The spec for the getGenericXXX methods are "Return a" rather than "Return the" so there shouldn't be any expectation on identity. The question about idempotency might be worth checking into as the underlying factory for reflective generic type objects does interact with the defining class loader.

-------------

PR: https://git.openjdk.org/jdk/pull/12643

From rriggs at openjdk.org  Tue Feb 21 14:57:28 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 21 Feb 2023 14:57:28 GMT
Subject: RFR: 8302899: Executors.newSingleThreadExecutor can use Cleaner to
 shutdown executor
In-Reply-To: <tBrSZRn1GdrWMSRUsdNNyAWpkuS_FvtLwLuUKut6LH0=.cd1a7fcb-dbcf-45eb-b3d3-72ba17087566@github.com>
References: <tBrSZRn1GdrWMSRUsdNNyAWpkuS_FvtLwLuUKut6LH0=.cd1a7fcb-dbcf-45eb-b3d3-72ba17087566@github.com>
Message-ID: <8b058YJQlFC0AHvRph6N8RwsBw48U-XsD8A3tcGpkdU=.b70c7f08-f69e-4fcc-8d49-ffe6fbc8406e@github.com>

On Mon, 20 Feb 2023 18:34:17 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> Executors.newSingleThreadExecutor returns a delegating ExecutorService that has finalizer to shutdown the underlying TPE when the wrapper is finalizable. It goes back to JDK 6 and JDK-6399443. This is the last non-empty finalizer in java.base. Removing it will likely lead to bug reports/complaints as the current behavior goes back to 2006. So the proposal is to just replace it with a Cleaner, trivially done in this case. As part of the changes, I've replaced the existing test with a more modern test that exercises more scenarios.

LGTM

src/java.base/share/classes/java/util/concurrent/Executors.java line 192:

> 190:      * @throws NullPointerException if threadFactory is null
> 191:      */
> 192: 

Extra blank line.

-------------

Marked as reviewed by rriggs (Reviewer).

PR: https://git.openjdk.org/jdk/pull/12675

From rriggs at openjdk.org  Tue Feb 21 15:40:36 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 21 Feb 2023 15:40:36 GMT
Subject: Integrated: 8301627: System.exit and Runtime.exit debug logging
In-Reply-To: <OzJeJH5yxolKPChcUisqtzGYF_MU3oOJdx6HPhsXjBw=.15eefe39-efe1-433e-a6ac-02b4a730f264@github.com>
References: <OzJeJH5yxolKPChcUisqtzGYF_MU3oOJdx6HPhsXjBw=.15eefe39-efe1-433e-a6ac-02b4a730f264@github.com>
Message-ID: <6reUCrE8H1jA65u8ZGEUj_SBsdwOEXlj9BjUEEkfMX4=.5f1c0393-e722-47df-8621-d78671cfe857@github.com>

On Fri, 10 Feb 2023 20:33:39 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> It can be difficult to find the cause of calls to `java.lang.System.exit(status)` and `Runtime.exit(status)` because the Java runtime exits.
> The status value and stack trace are logged using the System Logger named `java.lang.Runtime` with message level `System.Logger.Level.DEBUG`.

This pull request has now been integrated.

Changeset: 10b4cc9e
Author:    Roger Riggs <rriggs at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/10b4cc9eb49c14a6be03b3f53e97037529169ed1
Stats:     160 lines in 6 files changed: 160 ins; 0 del; 0 mod

8301627: System.exit and Runtime.exit debug logging

Reviewed-by: alanb, chegar

-------------

PR: https://git.openjdk.org/jdk/pull/12517

From duke at openjdk.org  Tue Feb 21 15:48:25 2023
From: duke at openjdk.org (Viktor Klang)
Date: Tue, 21 Feb 2023 15:48:25 GMT
Subject: RFR: 8302899: Executors.newSingleThreadExecutor can use Cleaner to
 shutdown executor
In-Reply-To: <tBrSZRn1GdrWMSRUsdNNyAWpkuS_FvtLwLuUKut6LH0=.cd1a7fcb-dbcf-45eb-b3d3-72ba17087566@github.com>
References: <tBrSZRn1GdrWMSRUsdNNyAWpkuS_FvtLwLuUKut6LH0=.cd1a7fcb-dbcf-45eb-b3d3-72ba17087566@github.com>
Message-ID: <Yb8iiHeLmWsAjOwzDqzQJwLNLDY50RhuegwRbl6LHuU=.960992f3-c292-4db2-968f-be03fe273d95@github.com>

On Mon, 20 Feb 2023 18:34:17 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> Executors.newSingleThreadExecutor returns a delegating ExecutorService that has finalizer to shutdown the underlying TPE when the wrapper is finalizable. It goes back to JDK 6 and JDK-6399443. This is the last non-empty finalizer in java.base. Removing it will likely lead to bug reports/complaints as the current behavior goes back to 2006. So the proposal is to just replace it with a Cleaner, trivially done in this case. As part of the changes, I've replaced the existing test with a more modern test that exercises more scenarios.

test/jdk/java/util/concurrent/Executors/AutoShutdown.java line 133:

> 131:         while (!terminated) {
> 132:             System.gc();
> 133:             terminated = executor.awaitTermination(100, TimeUnit.MILLISECONDS);

@AlanBateman Perhaps worth having some upper limit as to how long it will wait until failing the test?

-------------

PR: https://git.openjdk.org/jdk/pull/12675

From alanb at openjdk.org  Tue Feb 21 16:39:32 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 21 Feb 2023 16:39:32 GMT
Subject: RFR: 8302899: Executors.newSingleThreadExecutor can use Cleaner to
 shutdown executor
In-Reply-To: <Yb8iiHeLmWsAjOwzDqzQJwLNLDY50RhuegwRbl6LHuU=.960992f3-c292-4db2-968f-be03fe273d95@github.com>
References: <tBrSZRn1GdrWMSRUsdNNyAWpkuS_FvtLwLuUKut6LH0=.cd1a7fcb-dbcf-45eb-b3d3-72ba17087566@github.com>
 <Yb8iiHeLmWsAjOwzDqzQJwLNLDY50RhuegwRbl6LHuU=.960992f3-c292-4db2-968f-be03fe273d95@github.com>
Message-ID: <4k90pf4Nl6DHOAg1ydW0bKgagFH3ZKfH5cb3C7Fazbk=.e1561c56-2508-48f2-9542-cd95d70e264b@github.com>

On Tue, 21 Feb 2023 15:45:17 GMT, Viktor Klang <duke at openjdk.org> wrote:

>> Executors.newSingleThreadExecutor returns a delegating ExecutorService that has finalizer to shutdown the underlying TPE when the wrapper is finalizable. It goes back to JDK 6 and JDK-6399443. This is the last non-empty finalizer in java.base. Removing it will likely lead to bug reports/complaints as the current behavior goes back to 2006. So the proposal is to just replace it with a Cleaner, trivially done in this case. As part of the changes, I've replaced the existing test with a more modern test that exercises more scenarios.
>
> test/jdk/java/util/concurrent/Executors/AutoShutdown.java line 133:
> 
>> 131:         while (!terminated) {
>> 132:             System.gc();
>> 133:             terminated = executor.awaitTermination(100, TimeUnit.MILLISECONDS);
> 
> @AlanBateman Perhaps worth having some upper limit as to how long it will wait until failing the test?

jtreg will look after this. The default timeout is 120s but it can be adjusted with a timeout factor (make time uses a timeout factor of 4). So it would be possible to put a limit on this in the test but it can be problematic, e.g. with debug builds + Xcomp for example.

-------------

PR: https://git.openjdk.org/jdk/pull/12675

From mchung at openjdk.org  Tue Feb 21 17:02:28 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Tue, 21 Feb 2023 17:02:28 GMT
Subject: RFR: 8302667: Improve message format when failing to load symbols
 or libraries [v2]
In-Reply-To: <B-eIiBotI3cwCwWY5r2xYPlHfnV4dKJIHJdwg-hbDeQ=.ff83dbdf-e456-48b7-aa7f-e8cf75f71b5a@github.com>
References: <tu4ol4DO1PeplhgjhkYpXLwES142ztBXsM43uQO_CNE=.bfca85a4-2323-487d-9261-964671e00bf3@github.com>
 <B-eIiBotI3cwCwWY5r2xYPlHfnV4dKJIHJdwg-hbDeQ=.ff83dbdf-e456-48b7-aa7f-e8cf75f71b5a@github.com>
Message-ID: <5HI98VM_T336GbG8atm-0-Vuf9tqbVR9nIFGghIsdE8=.42476df6-adaf-4055-8619-c984954a7c92@github.com>

On Fri, 17 Feb 2023 14:08:34 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> DLL_ERROR4 is a macro expanding to an error message when a failure to load a generic item (shared libraries or an exported symbol from said libraries for example) occurs. "Error: loading:" is not a very pretty message, so this small change results in "Error: Failed to load %s" instead, which looks better and also means the message makes more sense if we want to append a reason behind as well, such as "Error: Failed to load libjvm.so because xxx"
>
> Julian Waters 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 'openjdk:master' into patch-6
>  - Error: Failed to load

What about:


#define ARG_ERROR18      "Error: reading %s"

-------------

PR: https://git.openjdk.org/jdk/pull/12596

From martin at openjdk.org  Tue Feb 21 17:05:29 2023
From: martin at openjdk.org (Martin Buchholz)
Date: Tue, 21 Feb 2023 17:05:29 GMT
Subject: RFR: 8302899: Executors.newSingleThreadExecutor can use Cleaner to
 shutdown executor
In-Reply-To: <tBrSZRn1GdrWMSRUsdNNyAWpkuS_FvtLwLuUKut6LH0=.cd1a7fcb-dbcf-45eb-b3d3-72ba17087566@github.com>
References: <tBrSZRn1GdrWMSRUsdNNyAWpkuS_FvtLwLuUKut6LH0=.cd1a7fcb-dbcf-45eb-b3d3-72ba17087566@github.com>
Message-ID: <cXiwzT16ieQ2yYicKx2v9yXMgEfT1p3-rFqZZutdmPo=.1d51c435-6034-4ef3-9ab4-4f6e2853eed8@github.com>

On Mon, 20 Feb 2023 18:34:17 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> Executors.newSingleThreadExecutor returns a delegating ExecutorService that has finalizer to shutdown the underlying TPE when the wrapper is finalizable. It goes back to JDK 6 and JDK-6399443. This is the last non-empty finalizer in java.base. Removing it will likely lead to bug reports/complaints as the current behavior goes back to 2006. So the proposal is to just replace it with a Cleaner, trivially done in this case. As part of the changes, I've replaced the existing test with a more modern test that exercises more scenarios.

Changes requested by martin (Reviewer).

test/jdk/java/util/concurrent/Executors/AutoShutdown.java line 115:

> 113: 
> 114:     /**
> 115:      * Returns the delegates for the given ExecutorService. The given ExectorService

typo: ExectorService

-------------

PR: https://git.openjdk.org/jdk/pull/12675

From jwaters at openjdk.org  Tue Feb 21 17:14:57 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Tue, 21 Feb 2023 17:14:57 GMT
Subject: RFR: 8302667: Improve message format when failing to load symbols
 or libraries [v3]
In-Reply-To: <tu4ol4DO1PeplhgjhkYpXLwES142ztBXsM43uQO_CNE=.bfca85a4-2323-487d-9261-964671e00bf3@github.com>
References: <tu4ol4DO1PeplhgjhkYpXLwES142ztBXsM43uQO_CNE=.bfca85a4-2323-487d-9261-964671e00bf3@github.com>
Message-ID: <vW57drxW79eNR9cscDHmXI9El9VHDF_LJRBec9f9rec=.2c66ee11-b0b5-4691-88ed-2337509cc2e1@github.com>

> DLL_ERROR4 is a macro expanding to an error message when a failure to load a generic item (shared libraries or an exported symbol from said libraries for example) occurs. "Error: loading:" is not a very pretty message, so this small change results in "Error: Failed to load %s" instead, which looks better and also means the message makes more sense if we want to append a reason behind as well, such as "Error: Failed to load libjvm.so because xxx"

Julian Waters has updated the pull request incrementally with two additional commits since the last revision:

 - expandArgFile
 - ARG_ERROR18

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12596/files
  - new: https://git.openjdk.org/jdk/pull/12596/files/5f4370f8..6b54816a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12596&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12596&range=01-02

  Stats: 2 lines in 2 files changed: 1 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/12596.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12596/head:pull/12596

PR: https://git.openjdk.org/jdk/pull/12596

From jwaters at openjdk.org  Tue Feb 21 17:14:58 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Tue, 21 Feb 2023 17:14:58 GMT
Subject: RFR: 8302667: Improve message format when failing to load symbols
 or libraries [v2]
In-Reply-To: <B-eIiBotI3cwCwWY5r2xYPlHfnV4dKJIHJdwg-hbDeQ=.ff83dbdf-e456-48b7-aa7f-e8cf75f71b5a@github.com>
References: <tu4ol4DO1PeplhgjhkYpXLwES142ztBXsM43uQO_CNE=.bfca85a4-2323-487d-9261-964671e00bf3@github.com>
 <B-eIiBotI3cwCwWY5r2xYPlHfnV4dKJIHJdwg-hbDeQ=.ff83dbdf-e456-48b7-aa7f-e8cf75f71b5a@github.com>
Message-ID: <i50fbH4akwuLvSBz4vYIAfFaJ3Pm_qCY8HlXxrDuvng=.e6744b08-7822-4bb2-894d-bd7a3938b938@github.com>

On Fri, 17 Feb 2023 14:08:34 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> DLL_ERROR4 is a macro expanding to an error message when a failure to load a generic item (shared libraries or an exported symbol from said libraries for example) occurs. "Error: loading:" is not a very pretty message, so this small change results in "Error: Failed to load %s" instead, which looks better and also means the message makes more sense if we want to append a reason behind as well, such as "Error: Failed to load libjvm.so because xxx"
>
> Julian Waters 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 'openjdk:master' into patch-6
>  - Error: Failed to load

Alright, will do, just gimme a moment...

-------------

PR: https://git.openjdk.org/jdk/pull/12596

From naoto at openjdk.org  Tue Feb 21 17:25:28 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 21 Feb 2023 17:25:28 GMT
Subject: RFR: 8302877: Speed up latin1 case conversions [v3]
In-Reply-To: <iiq-I9Y0N-vXz5xrdxsD4QMyIlM3YhUdz3jjNktCn9Y=.a5979762-dbbb-4a4f-a9e6-feffdc17beb6@github.com>
References: <cf9hc-SBdgzB1lpqXGLHKcjT4-T9hLaMs1cCccqBiak=.f7b99e9d-3206-4e67-976f-ea0492ec6b06@github.com>
 <iiq-I9Y0N-vXz5xrdxsD4QMyIlM3YhUdz3jjNktCn9Y=.a5979762-dbbb-4a4f-a9e6-feffdc17beb6@github.com>
Message-ID: <k8qXzZvjzpzAaAZ3clFqtbLroxYT88uJ2YFXC-Lv_t4=.7f278f5a-0873-4cbc-ab27-5b227f7fbed5@github.com>

On Tue, 21 Feb 2023 11:12:18 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

>> This PR suggests we speed up Character.toUpperCase and Character.toLowerCase for latin1 code points by applying the 'oldest ASCII trick in the book'.
>> 
>> This takes advantage of the fact that latin1 uppercase code points are always 0x20 lower than their lowercase (with the exception of two code points which uppercase out of latin1).
>> 
>> To verify the correctness of the new implementation, the test `Latin1CaseConversion` is added with an exhaustive verification of toUpperCase/toLowerCase for all latin1 code points.
>> 
>> The implementation needs to balance the performance of the various ranges in latin1. An effort has been made to favour operations on ASCII code points, without causing excessive regression for higher code points.
>> 
>> Performance is benchmarked for 7 chosen sample code points, each representing a range or a special-case.  Results in the first comment.
>
> Eirik Bjorsnos has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Allow any integer codePoint by defaulting to Integer.parseInt
>  - Rename Latin1CaseConversions to just CaseConversions
>  - Remove a whitespace following 'if ('

LGTM. Thanks for the fix!

-------------

Marked as reviewed by naoto (Reviewer).

PR: https://git.openjdk.org/jdk/pull/12623

From bpb at openjdk.org  Tue Feb 21 17:44:55 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 21 Feb 2023 17:44:55 GMT
Subject: RFR: 8302806: (fs) Remove unused enum
 sun.nio.file.SensitivityWatchEventModifier [v2]
In-Reply-To: <FZn8ZF4sN5mtUO8MWPaC0N8nWFwTLkBvcqQeOPwVYeE=.a6e12227-dfa9-4817-adbb-bece72445860@github.com>
References: <FZn8ZF4sN5mtUO8MWPaC0N8nWFwTLkBvcqQeOPwVYeE=.a6e12227-dfa9-4817-adbb-bece72445860@github.com>
Message-ID: <tf06WYibyZqgHYUYT4h4EkWoyRYDIhsG-JsRPXyRpAU=.458bd37c-1231-4bac-8aec-86a2939cb43b@github.com>

> This enum is not used in the JDK and did not appear in external source code searches.

Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:

  8302806: Remove test

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12626/files
  - new: https://git.openjdk.org/jdk/pull/12626/files/e361bfeb..c980dba9

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12626&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12626&range=00-01

  Stats: 152 lines in 1 file changed: 0 ins; 152 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/12626.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12626/head:pull/12626

PR: https://git.openjdk.org/jdk/pull/12626

From bpb at openjdk.org  Tue Feb 21 17:59:27 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 21 Feb 2023 17:59:27 GMT
Subject: RFR: JDK-8302800: Augment NaN handling tests of FDLIBM methods
In-Reply-To: <mc-_elojltkXx-TJQxeFKmIK6TELw_WBpwoSv7rdgEc=.9b3224a0-c9a0-475e-b7e8-86317d1ac04b@github.com>
References: <mc-_elojltkXx-TJQxeFKmIK6TELw_WBpwoSv7rdgEc=.9b3224a0-c9a0-475e-b7e8-86317d1ac04b@github.com>
Message-ID: <QoMLU0CBVQbRFqyrzP22yxG9IL10Ujc-jRIPT_YsYbo=.582f22ef-5028-4a22-9929-8709919cf668@github.com>

On Sun, 19 Feb 2023 21:30:19 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Augment NaN-handling tests to include exotic NaN bit patterns. Assuming this changeset goes back first, I'll update https://github.com/openjdk/jdk/pull/12608 to follow the same convention afterward.

Marked as reviewed by bpb (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/12644

From fabio19298 at gmail.com  Tue Feb 21 18:21:23 2023
From: fabio19298 at gmail.com (Fabio Romano)
Date: Tue, 21 Feb 2023 13:21:23 -0500
Subject: New class for handling infinite-precision rationals
Message-ID: <CAEuo5R6YpyfDMNDp_YtfahvJshKa8f-q2odFKJ9i57pLLVa5hg@mail.gmail.com>

The Rational class provides operations for arithmetic, rounding,
comparison, hashing, and format conversion. The toString method provides a
canonical representation of a Rational. All the calculations performed have
an exact result, except for the square and nth roots, in which the user can
specify the rounding behavior.
Link to pull request: https://github.com/openjdk/jdk/pull/11982
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20230221/e5f9d779/attachment.htm>

From duke at openjdk.org  Tue Feb 21 18:23:18 2023
From: duke at openjdk.org (Madjosz)
Date: Tue, 21 Feb 2023 18:23:18 GMT
Subject: RFR: 8302983: ZoneRulesProvider.registerProvider() twice will remove
 provider
Message-ID: <AAfM5rBLeq2B3ttHBX_7kw0_rjfIVPSdcEL23HiOhVs=.b17c2586-b0bc-46ad-9501-0cf8363f82b9@github.com>

Fixes JDK-8302983 (and duplicate JDK-8302898)

-------------

Commit messages:
 - 8302983: ZoneRulesProvider.registerProvider() twice will remove provider

Changes: https://git.openjdk.org/jdk/pull/12690/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12690&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8302983
  Stats: 53 lines in 2 files changed: 49 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/12690.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12690/head:pull/12690

PR: https://git.openjdk.org/jdk/pull/12690

From alanb at openjdk.org  Tue Feb 21 18:24:05 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 21 Feb 2023 18:24:05 GMT
Subject: RFR: 8302899: Executors.newSingleThreadExecutor can use Cleaner to
 shutdown executor [v2]
In-Reply-To: <tBrSZRn1GdrWMSRUsdNNyAWpkuS_FvtLwLuUKut6LH0=.cd1a7fcb-dbcf-45eb-b3d3-72ba17087566@github.com>
References: <tBrSZRn1GdrWMSRUsdNNyAWpkuS_FvtLwLuUKut6LH0=.cd1a7fcb-dbcf-45eb-b3d3-72ba17087566@github.com>
Message-ID: <QuBbR3FKXmGzKKHgLzP0vj5UOZgOe6nU2DPiPv3KMYU=.3b33756f-0978-4925-aec2-d804ddab09df@github.com>

> Executors.newSingleThreadExecutor returns a delegating ExecutorService that has finalizer to shutdown the underlying TPE when the wrapper is finalizable. It goes back to JDK 6 and JDK-6399443. This is the last non-empty finalizer in java.base. Removing it will likely lead to bug reports/complaints as the current behavior goes back to 2006. So the proposal is to just replace it with a Cleaner, trivially done in this case. As part of the changes, I've replaced the existing test with a more modern test that exercises more scenarios.

Alan Bateman has updated the pull request incrementally with one additional commit since the last revision:

  Fix typo in comment, remove blank line

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12675/files
  - new: https://git.openjdk.org/jdk/pull/12675/files/1c771f26..3bb4d0cd

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12675&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12675&range=00-01

  Stats: 2 lines in 2 files changed: 0 ins; 1 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/12675.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12675/head:pull/12675

PR: https://git.openjdk.org/jdk/pull/12675

From darcy at openjdk.org  Tue Feb 21 18:36:07 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 21 Feb 2023 18:36:07 GMT
Subject: RFR: JDK-8302800: Augment NaN handling tests of FDLIBM methods
 [v2]
In-Reply-To: <mc-_elojltkXx-TJQxeFKmIK6TELw_WBpwoSv7rdgEc=.9b3224a0-c9a0-475e-b7e8-86317d1ac04b@github.com>
References: <mc-_elojltkXx-TJQxeFKmIK6TELw_WBpwoSv7rdgEc=.9b3224a0-c9a0-475e-b7e8-86317d1ac04b@github.com>
Message-ID: <GzuyRNZpKGIGAMLGLh5hIINKuC4vi5qFQ2T-WdiscuU=.77ddeb86-f8d9-4ee6-8841-81e5c8ee13b3@github.com>

> Augment NaN-handling tests to include exotic NaN bit patterns. Assuming this changeset goes back first, I'll update https://github.com/openjdk/jdk/pull/12608 to follow the same convention afterward.

Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:

  Respond to review feedback.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12644/files
  - new: https://git.openjdk.org/jdk/pull/12644/files/b4f2a1dd..e2b8486d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12644&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12644&range=00-01

  Stats: 4 lines in 1 file changed: 2 ins; 2 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/12644.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12644/head:pull/12644

PR: https://git.openjdk.org/jdk/pull/12644

From darcy at openjdk.org  Tue Feb 21 18:36:09 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 21 Feb 2023 18:36:09 GMT
Subject: Integrated: JDK-8302800: Augment NaN handling tests of FDLIBM methods
In-Reply-To: <mc-_elojltkXx-TJQxeFKmIK6TELw_WBpwoSv7rdgEc=.9b3224a0-c9a0-475e-b7e8-86317d1ac04b@github.com>
References: <mc-_elojltkXx-TJQxeFKmIK6TELw_WBpwoSv7rdgEc=.9b3224a0-c9a0-475e-b7e8-86317d1ac04b@github.com>
Message-ID: <NSbGWswj07mrhJoQqUe1M-J9FviyPCp7_5q8kEcIEQE=.53c9faf1-33df-4cf0-9d87-2b4655508bc5@github.com>

On Sun, 19 Feb 2023 21:30:19 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Augment NaN-handling tests to include exotic NaN bit patterns. Assuming this changeset goes back first, I'll update https://github.com/openjdk/jdk/pull/12608 to follow the same convention afterward.

This pull request has now been integrated.

Changeset: dfce4e19
Author:    Joe Darcy <darcy at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/dfce4e1943f2f95b74b5a9cdde9d738dcffd0b43
Stats:     198 lines in 7 files changed: 94 ins; 79 del; 25 mod

8302800: Augment NaN handling tests of FDLIBM methods

Reviewed-by: bpb

-------------

PR: https://git.openjdk.org/jdk/pull/12644

From simonis at openjdk.org  Tue Feb 21 18:42:30 2023
From: simonis at openjdk.org (Volker Simonis)
Date: Tue, 21 Feb 2023 18:42:30 GMT
Subject: RFR: 8302154: Hidden classes created by LambdaMetaFactory can't be
 unloaded [v2]
In-Reply-To: <gKoLpwlXDxp2uaSKSkMArJl1Ym9VX1hoDFqQTTUpk8w=.e1dce669-5a42-4b66-ac4b-205718c8eb81@github.com>
References: <YoZauVv8zvhdUw-LD25LrsMDItFbg3aXPU3deXwwFdQ=.c2839dea-12e5-4e0e-9579-eac9d8503932@github.com>
 <gKoLpwlXDxp2uaSKSkMArJl1Ym9VX1hoDFqQTTUpk8w=.e1dce669-5a42-4b66-ac4b-205718c8eb81@github.com>
Message-ID: <2nIotFMJtOU6SxkjWHI7_Q-tTVb78xaPACgQMgLFWhY=.2d075f93-bacb-4dfa-86ee-e34d3ff9921a@github.com>

On Thu, 9 Feb 2023 18:11:18 GMT, Volker Simonis <simonis at openjdk.org> wrote:

>> Prior to [JDK-8239384](https://bugs.openjdk.org/browse/JDK-8239384)/[JDK-8238358](https://bugs.openjdk.org/browse/JDK-8238358) LambdaMetaFactory has created VM-anonymous classes which could easily be unloaded once they were not referenced any more. Starting with JDK 15 and the new "hidden class" based implementation, this is not the case any more, because the hidden classes will be strongly tied to their defining class loader. If this is the default application class loader, these hidden classes can never be unloaded which can easily lead to Metaspace exhaustion (see the [test case in the JBS issue](https://bugs.openjdk.org/secure/attachment/102601/LambdaClassLeak.java)). This is a regression compared to previous JDK versions which some of our applications have been affected from when migrating to JDK 17.
>> 
>> The reason why the newly created hidden classes are strongly linked to their defining class loader is not clear to me. JDK-8239384 mentions it as an "implementation detail":
>> 
>>> *4. the lambda proxy class has the strong relationship with the class loader (that will share the VM metaspace for its defining loader - implementation details)*
>> 
>> From my current understanding the strong link between a hidden class created by `LambdaMetaFactory` and its defining class loader is not strictly required. In order to prevent potential OOMs and fix the regression compared the JDK 14 and earlier I propose to create these hidden classes without the `STRONG` option.
>> 
>> I'll be happy to add the test case as JTreg test to this PR if you think that would be useful.
>
> Volker Simonis has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Remove assertions which insist on Lambda proxy classes being strongly linked to their class loader
>  - Removed unused import of STRONG und updated copyright year

I hear your arguments although I don't agree :)

Can we at least get consensus on that the current design to create a new ClassLoaderData for each non-strongly linked Hidden Class just in order to enable simple unloading isn't the greatest design and should eventually be replaced by a more sophisticated implementation which allows non-strongly linked Hidden Classes to share a single ClassLoaderData but still enable unloading for them once they aren't referenced any more?

-------------

PR: https://git.openjdk.org/jdk/pull/12493

From smarks at openjdk.org  Tue Feb 21 19:02:41 2023
From: smarks at openjdk.org (Stuart Marks)
Date: Tue, 21 Feb 2023 19:02:41 GMT
Subject: RFR: 8298939: Refactor
 open/test/jdk/javax/rmi/ssl/SSLSocketParametersTest.sh to jtreg java test [v3]
In-Reply-To: <24Cc7mXtQveH97zLcOxD2gH9P6qWNkdJ--I9IiFtZVo=.66068deb-3ca5-4dcc-aa70-688a9adb4c9a@github.com>
References: <VC_ou2XS44PtyTfwXw0VZRtXcHEbXImlLZKniIPRqOw=.7d10a168-77f8-4552-97a3-8b2570e3fe29@github.com>
 <y65OxkcJ9OlzgC1Q-o62zILzqMIQA9SQk_pg6zdpe7U=.d7745cdf-f803-45bd-a3fb-8d6bb146c2c2@github.com>
 <9r-bLTPN386eFb7438VgALrjLfRcwjfoO2f5RTjabYQ=.78a0192a-3738-4d0b-ae89-cc1f3e635690@github.com>
 <24Cc7mXtQveH97zLcOxD2gH9P6qWNkdJ--I9IiFtZVo=.66068deb-3ca5-4dcc-aa70-688a9adb4c9a@github.com>
Message-ID: <bxSMOO6mhn02dFo7zGDn75ytiKlsIeGnIC4Bi09qKjE=.fab90751-1e42-49e0-8f7e-fae0c40d9230@github.com>

On Fri, 17 Feb 2023 20:32:20 GMT, Matthew Donovan <duke at openjdk.org> wrote:

>> test/jdk/javax/rmi/ssl/SSLSocketParametersTest.java line 163:
>> 
>>> 161:                 }
>>> 162:             }
>>> 163:         }
>> 
>> It looks like this finally-block is intended to unexport any exported RMI service, which will let the JVM exit. However, this is somewhat fragile. If the unexportObject() call fails with some other exception, the object might remain exported, and the JVM will hang indefinitely. (This has historically been a problem with RMI tests.)
>> 
>> Since the original version of the test ran each case in a separate JVM, I think it's ok to continue to do the same. The old version of the test called System.exit() along most code paths. It's somewhat odd that exit wasn't called along all code paths. Perhaps those code paths weren't taken, or if they were, the JVM exited of its own accord. In any case, I'd suggest ensuring that exit() is called along all code paths (success and failure) and keeping separate `@run main/othervm` lines in the header to run each case in its own JVM. This is at least equivalent to what the shell script based test was doing.
>> 
>> As an optimization, it might be reasonable to try to run some subset of the tests in a single JVM. They can't all be run in the same JVM though, because of system properties, so this would require some complexity to support running some cases in the same JVM and some in separate JVMs. It's not clear to me whether that's warranted.
>
> I don't think all of those code paths ever executed. If `System.exit()` is called, regardless of the exit code, `make` treats it as an error:
> 
> `TEST RESULT: Failed. Unexpected exit from test [exit code: 0]`
> 
> I added a try/catch in `main` so that if an exception is thrown during the test, `System.exit` will be called.

My bad, I was confused about the execution environments. In the old test, jtreg invoked the shell script, which in turn invoked the Java test as a standalone Java program. In that environment it's paramount that every code path call System.exit() in order to avoid stale JVMs building up.

The new test is invoked directly by jtreg, which disallows calling System.exit(). Instead, every code path needs to result in the main() method completing somehow, either via a normal return or by throwing an exception directly or letting one propagate from some called method. So, you need to pull out the try/catch and any calls to System.exit(). Sorry about that.

If we're going to stick with a scheme where we're running separate JVM per test, there's no need to unexport any RMI service. When main() returns or throws an exception, jtreg will detect this and terminate the JVM because of /othervm, and any exported RMI services will be destroyed at that time. Thus, the finally-block in `testRmiCommunication` can simply be removed.

-------------

PR: https://git.openjdk.org/jdk/pull/11910

From smarks at openjdk.org  Tue Feb 21 19:08:35 2023
From: smarks at openjdk.org (Stuart Marks)
Date: Tue, 21 Feb 2023 19:08:35 GMT
Subject: RFR: 8298939: Refactor
 open/test/jdk/javax/rmi/ssl/SSLSocketParametersTest.sh to jtreg java test [v4]
In-Reply-To: <AwGYbtYHElwIegMho1esToGmDCY4oCBJ6Kdw7AIl7mg=.c975751e-69cb-4916-af14-7ea88471e47d@github.com>
References: <VC_ou2XS44PtyTfwXw0VZRtXcHEbXImlLZKniIPRqOw=.7d10a168-77f8-4552-97a3-8b2570e3fe29@github.com>
 <AwGYbtYHElwIegMho1esToGmDCY4oCBJ6Kdw7AIl7mg=.c975751e-69cb-4916-af14-7ea88471e47d@github.com>
Message-ID: <hR5KCBz2nKbsQG1ZHsXQ8ENIpqwJrKQCW3yh-Eq6G_c=.a726970f-f736-49c2-b461-88417f190a33@github.com>

On Fri, 17 Feb 2023 20:41:16 GMT, Matthew Donovan <duke at openjdk.org> wrote:

>> Removed SSLSocketParametersTest.sh script (which just called a Java file) and configured the java code to run directly with jtreg
>
> Matthew Donovan 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:
> 
>  - added System.exit when exceptions are thrown and refactored for clarity
>  - Merge branch 'master' into rmi-sslparams
>  - added default switch case and additional refactoring
>  - added exceptions for cases 4 and 5
>  - clarified cases 4 and 5
>  - 8298939: Refactor open/test/jdk/javax/rmi/ssl/SSLSocketParametersTest.sh to jtreg java test

test/jdk/javax/rmi/ssl/SSLSocketParametersTest.java line 221:

> 219:             }
> 220:         }
> 221:     }

Overall this test method makes sense, as it asserts that an IllegalArgumentException must be thrown with the given exception message. (A comment to this effect would be helpful.) As such, the catch of NoSuchAlgorithmException is confusing. I think this is here because SSLContext.getDefault() lists this as a checked exception. If so, then I'd suggest simply propagating it by adding a `throws` clause for this method. This also means adding a `throws` clause to the `runTest()` method, possibly just `throws Exception`. In general this is OK for jtreg tests to propagate any checked exception out of main, since jtreg will handle and report any unexpectedly propagated exceptions. It's thus unnecessary for test code to have catch-clauses for anything that the test isn't actually handling.

-------------

PR: https://git.openjdk.org/jdk/pull/11910

From darcy at openjdk.org  Tue Feb 21 19:11:32 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 21 Feb 2023 19:11:32 GMT
Subject: RFR: 8292914: Drop the counter from lambda class names [v8]
In-Reply-To: <AdfREeJYVkF6HTsw669hMueQxdGXUXxYc4GetiDuoDk=.5124c8b8-3bea-4baa-bbb1-9383c84bb15f@github.com>
References: <GgLfH-ueBQqT-Mfk1mKpKFAt8fYqyjfVJ9lmlsBsCbo=.8dd5b3b4-4e84-4970-9179-1c0399b30edc@github.com>
 <AdfREeJYVkF6HTsw669hMueQxdGXUXxYc4GetiDuoDk=.5124c8b8-3bea-4baa-bbb1-9383c84bb15f@github.com>
Message-ID: <OVAs1Eg5Go4Rz1FBx9e8OSKn7EPJJlfAKFAQvPVhO7s=.ff6541be-db8d-4f44-8edc-10f3255d73f2@github.com>

On Fri, 17 Feb 2023 19:37:59 GMT, David M. Lloyd <duke at openjdk.org> wrote:

>> The class generated for lambda proxies is now defined as a hidden class. This means that the counter, which was used to ensure a unique class name and avoid clashes, is now redundant. In addition to performing redundant work, this also impacts build reproducibility for native image generators which might already have a strategy to cope with hidden classes but cannot cope with indeterminate definition order for lambda proxy classes.
>> 
>> This solves JDK-8292914 by making lambda proxy names always be stable without any configuration needed. This would also replace #10024.
>
> David M. Lloyd has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Many tests have patterns for lambda class names; update them
>  - Update comments and javadoc showin the old pattern

Should this have a CSR for any observable behavioral changes?

-------------

PR: https://git.openjdk.org/jdk/pull/12579

From darcy at openjdk.org  Tue Feb 21 19:14:11 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 21 Feb 2023 19:14:11 GMT
Subject: RFR: JDK-8302028: Port fdlibm atan2 to Java [v4]
In-Reply-To: <xl79M-V4_2t49GuCudJHQBaJjAcwWl9f2Bv19RbAmdo=.b9c97066-8cf4-4569-8b4b-8b4874e23833@github.com>
References: <xl79M-V4_2t49GuCudJHQBaJjAcwWl9f2Bv19RbAmdo=.b9c97066-8cf4-4569-8b4b-8b4874e23833@github.com>
Message-ID: <1Y_ue1ROidrAd3SNicd-lMm7usggq2Li8B5TA8QS3Ck=.a7e6c146-847a-4989-acc5-8b45fd7ede57@github.com>

> Working down the porting list, next stop, atan2.

Joe Darcy 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 NaN regression test infrastructure.
 - Merge branch 'master' into JDK-8302028
 - Correct and test for issue found in code review.
 - Update regression test.
 - Merge branch 'master' into JDK-8302028
 - JDK-8302028: Port fdlibm atan2 to Java

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12608/files
  - new: https://git.openjdk.org/jdk/pull/12608/files/2c524913..82790bbb

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12608&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12608&range=02-03

  Stats: 6881 lines in 292 files changed: 3843 ins; 1365 del; 1673 mod
  Patch: https://git.openjdk.org/jdk/pull/12608.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12608/head:pull/12608

PR: https://git.openjdk.org/jdk/pull/12608

From smarks at openjdk.org  Tue Feb 21 19:17:38 2023
From: smarks at openjdk.org (Stuart Marks)
Date: Tue, 21 Feb 2023 19:17:38 GMT
Subject: RFR: 8298939: Refactor
 open/test/jdk/javax/rmi/ssl/SSLSocketParametersTest.sh to jtreg java test [v4]
In-Reply-To: <AwGYbtYHElwIegMho1esToGmDCY4oCBJ6Kdw7AIl7mg=.c975751e-69cb-4916-af14-7ea88471e47d@github.com>
References: <VC_ou2XS44PtyTfwXw0VZRtXcHEbXImlLZKniIPRqOw=.7d10a168-77f8-4552-97a3-8b2570e3fe29@github.com>
 <AwGYbtYHElwIegMho1esToGmDCY4oCBJ6Kdw7AIl7mg=.c975751e-69cb-4916-af14-7ea88471e47d@github.com>
Message-ID: <YkulgJjK089y6q_x5_mdzBqtWSwgsPnYxrpZYZzF38E=.323e8586-cbe6-4211-a330-9055b841431c@github.com>

On Fri, 17 Feb 2023 20:41:16 GMT, Matthew Donovan <duke at openjdk.org> wrote:

>> Removed SSLSocketParametersTest.sh script (which just called a Java file) and configured the java code to run directly with jtreg
>
> Matthew Donovan 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:
> 
>  - added System.exit when exceptions are thrown and refactored for clarity
>  - Merge branch 'master' into rmi-sslparams
>  - added default switch case and additional refactoring
>  - added exceptions for cases 4 and 5
>  - clarified cases 4 and 5
>  - 8298939: Refactor open/test/jdk/javax/rmi/ssl/SSLSocketParametersTest.sh to jtreg java test

test/jdk/javax/rmi/ssl/SSLSocketParametersTest.java line 151:

> 149:                 throw new RuntimeException("An error occurred during test execution", exc);
> 150:             } else {
> 151:                 System.out.println("Caught expected exception: " + exc);

I'm not quite clear on what the expected exception actually is -- is it an IllegalArgumentException or an IOException? Or does it differ from case to case? It would be good to be precise about exactly which exception is expected to be thrown from which test case. If IOException is caught here only because it's declared to be thrown by some method, and it's incidental to the test, I'd suggest it be propagated. (See my similar comments on testServerFactory.)

-------------

PR: https://git.openjdk.org/jdk/pull/11910

From jlu at openjdk.org  Tue Feb 21 19:34:11 2023
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 21 Feb 2023 19:34:11 GMT
Subject: RFR: 8302512: Update IANA Language Subtag Registry to Version
 2023-02-14
Message-ID: <or0F9vpHLkJyfwpgJfAuFmy8zI1yaZ_H9YAUyiXM3P8=.50952559-8a6d-4e85-bd65-b757d1ae0a3a@github.com>

Incorporate the latest IANA language subtag registry definition (2023-02-14).

-------------

Commit messages:
 - Add missing JBS #s to test header
 - IANA update 2/14/23

Changes: https://git.openjdk.org/jdk/pull/12699/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12699&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8302512
  Stats: 9 lines in 2 files changed: 6 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/12699.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12699/head:pull/12699

PR: https://git.openjdk.org/jdk/pull/12699

From bchristi at openjdk.org  Tue Feb 21 19:41:29 2023
From: bchristi at openjdk.org (Brent Christian)
Date: Tue, 21 Feb 2023 19:41:29 GMT
Subject: RFR: 8302899: Executors.newSingleThreadExecutor can use Cleaner to
 shutdown executor [v2]
In-Reply-To: <QuBbR3FKXmGzKKHgLzP0vj5UOZgOe6nU2DPiPv3KMYU=.3b33756f-0978-4925-aec2-d804ddab09df@github.com>
References: <tBrSZRn1GdrWMSRUsdNNyAWpkuS_FvtLwLuUKut6LH0=.cd1a7fcb-dbcf-45eb-b3d3-72ba17087566@github.com>
 <QuBbR3FKXmGzKKHgLzP0vj5UOZgOe6nU2DPiPv3KMYU=.3b33756f-0978-4925-aec2-d804ddab09df@github.com>
Message-ID: <uQvBTGcKfjRpT4MSozobOPL1ohjTDptqycQD25fGq68=.9c89dfa7-4667-455c-bcca-3888aa94aa0e@github.com>

On Tue, 21 Feb 2023 18:24:05 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Executors.newSingleThreadExecutor returns a delegating ExecutorService that has finalizer to shutdown the underlying TPE when the wrapper is finalizable. It goes back to JDK 6 and JDK-6399443. This is the last non-empty finalizer in java.base. Removing it will likely lead to bug reports/complaints as the current behavior goes back to 2006. So the proposal is to just replace it with a Cleaner, trivially done in this case. As part of the changes, I've replaced the existing test with a more modern test that exercises more scenarios.
>
> Alan Bateman has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix typo in comment, remove blank line

src/java.base/share/classes/java/util/concurrent/Executors.java line 837:

> 835:         }
> 836:     }
> 837: 

You might consider keeping a dedicated subclass ("CleanableDelegatedExecutorService"?). Such a class could save the Cleanable from Cleaner.register(), and override the shutdown() method to call Cleanable.clean(). This would reduce GC reference tracking, for instance in places where newSingleThreadExecutor() is used in a try-with-resources.

-------------

PR: https://git.openjdk.org/jdk/pull/12675

From naoto at openjdk.org  Tue Feb 21 19:46:25 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 21 Feb 2023 19:46:25 GMT
Subject: RFR: 8301119: Support for GB18030-2022
Message-ID: <FXBchbCnbNloQO7Nlh9Ijue_c_YugGk-UC7_-ZAjY2o=.7e1ca01f-8cee-40bb-bb06-6e5670abe661@github.com>

Upgrading the GB18030 charset in the JDK to the latest 2022 standard. Since this is not a compatible upgrade to the existing mapping, a new system property `jdk.charset.GB18030` is introduced. If it is set to "2000", the mapping falls back to the existing mapping based on the 2000 standard, otherwise, it defaults to 2022 mapping. Refer to the corresponding CSR for more detail.

-------------

Commit messages:
 - Check initPhase and don't call System.getProperty if in phase 1
 - Some clean-up
 - Some more fixes
 - removed unnecessary method name composition
 - Removed unnecessary imports
 - aliases fix
 - Move GB18030 into standard charsets provider
 - indentation
 - Removed unused annotation
 - Removed null check
 - ... and 4 more: https://git.openjdk.org/jdk/compare/574b48c6...0f3c25ce

Changes: https://git.openjdk.org/jdk/pull/12518/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12518&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8301119
  Stats: 283 lines in 14 files changed: 129 ins; 41 del; 113 mod
  Patch: https://git.openjdk.org/jdk/pull/12518.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12518/head:pull/12518

PR: https://git.openjdk.org/jdk/pull/12518

From coleenp at openjdk.org  Tue Feb 21 19:52:30 2023
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 21 Feb 2023 19:52:30 GMT
Subject: RFR: 8302154: Hidden classes created by LambdaMetaFactory can't be
 unloaded [v2]
In-Reply-To: <gKoLpwlXDxp2uaSKSkMArJl1Ym9VX1hoDFqQTTUpk8w=.e1dce669-5a42-4b66-ac4b-205718c8eb81@github.com>
References: <YoZauVv8zvhdUw-LD25LrsMDItFbg3aXPU3deXwwFdQ=.c2839dea-12e5-4e0e-9579-eac9d8503932@github.com>
 <gKoLpwlXDxp2uaSKSkMArJl1Ym9VX1hoDFqQTTUpk8w=.e1dce669-5a42-4b66-ac4b-205718c8eb81@github.com>
Message-ID: <kbfSN3qaumbk55MszZS2wq9JAvSfKKB5VCLqXqe3Ogs=.ba6c5fdc-4c7b-42d3-b6bb-3f05e4baf789@github.com>

On Thu, 9 Feb 2023 18:11:18 GMT, Volker Simonis <simonis at openjdk.org> wrote:

>> Prior to [JDK-8239384](https://bugs.openjdk.org/browse/JDK-8239384)/[JDK-8238358](https://bugs.openjdk.org/browse/JDK-8238358) LambdaMetaFactory has created VM-anonymous classes which could easily be unloaded once they were not referenced any more. Starting with JDK 15 and the new "hidden class" based implementation, this is not the case any more, because the hidden classes will be strongly tied to their defining class loader. If this is the default application class loader, these hidden classes can never be unloaded which can easily lead to Metaspace exhaustion (see the [test case in the JBS issue](https://bugs.openjdk.org/secure/attachment/102601/LambdaClassLeak.java)). This is a regression compared to previous JDK versions which some of our applications have been affected from when migrating to JDK 17.
>> 
>> The reason why the newly created hidden classes are strongly linked to their defining class loader is not clear to me. JDK-8239384 mentions it as an "implementation detail":
>> 
>>> *4. the lambda proxy class has the strong relationship with the class loader (that will share the VM metaspace for its defining loader - implementation details)*
>> 
>> From my current understanding the strong link between a hidden class created by `LambdaMetaFactory` and its defining class loader is not strictly required. In order to prevent potential OOMs and fix the regression compared the JDK 14 and earlier I propose to create these hidden classes without the `STRONG` option.
>> 
>> I'll be happy to add the test case as JTreg test to this PR if you think that would be useful.
>
> Volker Simonis has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Remove assertions which insist on Lambda proxy classes being strongly linked to their class loader
>  - Removed unused import of STRONG und updated copyright year

The reason that non-strongly linked classes have their own ClassLoaderData is because it implements the property that when the class loader is no longer loaded, metadata for it can be removed at once.  Even though Metaspace has been redesigned to be less fragmented, this is simpler than removing selected entities inside metaspace.  Replacing it with a more sophisticated design would not an be an improvement.
So I have to disagree with your statement above.

-------------

PR: https://git.openjdk.org/jdk/pull/12493

From naoto at openjdk.org  Tue Feb 21 20:00:26 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 21 Feb 2023 20:00:26 GMT
Subject: RFR: 8302512: Update IANA Language Subtag Registry to Version
 2023-02-14
In-Reply-To: <or0F9vpHLkJyfwpgJfAuFmy8zI1yaZ_H9YAUyiXM3P8=.50952559-8a6d-4e85-bd65-b757d1ae0a3a@github.com>
References: <or0F9vpHLkJyfwpgJfAuFmy8zI1yaZ_H9YAUyiXM3P8=.50952559-8a6d-4e85-bd65-b757d1ae0a3a@github.com>
Message-ID: <mvbATd8t4UfqoAaFHmSe_xvNX5lu-1ZlTeaFreD6hnQ=.d97352d2-2f7b-404e-bc26-cba0c40df28d@github.com>

On Tue, 21 Feb 2023 19:26:46 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Incorporate the latest IANA language subtag registry definition (2023-02-14).

Looks good. Please update the copyright year for the test changes.

test/jdk/java/util/Locale/LanguageSubtagRegistryTest.java line 29:

> 27:  *      8258795 8267038 8287180 8302512
> 28:  * @summary Checks the IANA language subtag registry data update
> 29:  *          (LSR Revision: 2023-2-14) with Locale and Locale.LanguageRange

Add prepending `0` to the month to keep the YYYY-MM-DD format.

-------------

PR: https://git.openjdk.org/jdk/pull/12699

From jlu at openjdk.org  Tue Feb 21 20:08:41 2023
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 21 Feb 2023 20:08:41 GMT
Subject: RFR: 8302512: Update IANA Language Subtag Registry to Version
 2023-02-14 [v2]
In-Reply-To: <or0F9vpHLkJyfwpgJfAuFmy8zI1yaZ_H9YAUyiXM3P8=.50952559-8a6d-4e85-bd65-b757d1ae0a3a@github.com>
References: <or0F9vpHLkJyfwpgJfAuFmy8zI1yaZ_H9YAUyiXM3P8=.50952559-8a6d-4e85-bd65-b757d1ae0a3a@github.com>
Message-ID: <M65a9-Cdfh9cNtFyivbLeL2F8982Aha4ecoLJ2XPsoI=.605031d4-80f4-4065-90bc-373f7e5927dd@github.com>

> Incorporate the latest IANA language subtag registry definition (2023-02-14).

Justin Lu has updated the pull request incrementally with one additional commit since the last revision:

  Copyright + correct date format

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12699/files
  - new: https://git.openjdk.org/jdk/pull/12699/files/2cd597c9..b502f523

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12699&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12699&range=00-01

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/12699.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12699/head:pull/12699

PR: https://git.openjdk.org/jdk/pull/12699

From jlu at openjdk.org  Tue Feb 21 20:08:43 2023
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 21 Feb 2023 20:08:43 GMT
Subject: RFR: 8302512: Update IANA Language Subtag Registry to Version
 2023-02-14 [v2]
In-Reply-To: <mvbATd8t4UfqoAaFHmSe_xvNX5lu-1ZlTeaFreD6hnQ=.d97352d2-2f7b-404e-bc26-cba0c40df28d@github.com>
References: <or0F9vpHLkJyfwpgJfAuFmy8zI1yaZ_H9YAUyiXM3P8=.50952559-8a6d-4e85-bd65-b757d1ae0a3a@github.com>
 <mvbATd8t4UfqoAaFHmSe_xvNX5lu-1ZlTeaFreD6hnQ=.d97352d2-2f7b-404e-bc26-cba0c40df28d@github.com>
Message-ID: <H7Jpu4VynPC8L0Xyl61f_fowgR3de5M_z4gJcn5cSKY=.1aed85a8-86fa-4c02-bdf0-5f2b14076ed1@github.com>

On Tue, 21 Feb 2023 19:56:59 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Copyright + correct date format
>
> test/jdk/java/util/Locale/LanguageSubtagRegistryTest.java line 29:
> 
>> 27:  *      8258795 8267038 8287180 8302512
>> 28:  * @summary Checks the IANA language subtag registry data update
>> 29:  *          (LSR Revision: 2023-2-14) with Locale and Locale.LanguageRange
> 
> Add prepending `0` to the month to keep the YYYY-MM-DD format.

Thanks for catching, fixed

-------------

PR: https://git.openjdk.org/jdk/pull/12699

From martin at openjdk.org  Tue Feb 21 20:19:35 2023
From: martin at openjdk.org (Martin Buchholz)
Date: Tue, 21 Feb 2023 20:19:35 GMT
Subject: RFR: 8302899: Executors.newSingleThreadExecutor can use Cleaner to
 shutdown executor [v2]
In-Reply-To: <QuBbR3FKXmGzKKHgLzP0vj5UOZgOe6nU2DPiPv3KMYU=.3b33756f-0978-4925-aec2-d804ddab09df@github.com>
References: <tBrSZRn1GdrWMSRUsdNNyAWpkuS_FvtLwLuUKut6LH0=.cd1a7fcb-dbcf-45eb-b3d3-72ba17087566@github.com>
 <QuBbR3FKXmGzKKHgLzP0vj5UOZgOe6nU2DPiPv3KMYU=.3b33756f-0978-4925-aec2-d804ddab09df@github.com>
Message-ID: <Iqy-X6mG1K4mH8hjxUvs0ctFFP4lpdm9nj6_737sy3s=.18c8fe89-7fe7-4a81-9ac0-581f3163bdf9@github.com>

On Tue, 21 Feb 2023 18:24:05 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Executors.newSingleThreadExecutor returns a delegating ExecutorService that has finalizer to shutdown the underlying TPE when the wrapper is finalizable. It goes back to JDK 6 and JDK-6399443. This is the last non-empty finalizer in java.base. Removing it will likely lead to bug reports/complaints as the current behavior goes back to 2006. So the proposal is to just replace it with a Cleaner, trivially done in this case. As part of the changes, I've replaced the existing test with a more modern test that exercises more scenarios.
>
> Alan Bateman has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix typo in comment, remove blank line

Allow me to be your top cheerleader for upgrading jdk test infrastructure to junit 5.  It's enough to make me want to write some tests!

test/jdk/java/util/concurrent/Executors/AutoShutdown.java line 57:

> 55:     }
> 56: 
> 57:     private static Stream<Arguments> executorAndQueuedTaskCounts() {

I've long wondered about "cartesian products" of Streams, so off to stackoverflow, which (TIL) advises a chain of flatmaps except at the end where you just put a non-flat map.  So better style seems

    private static Stream<Arguments> executorAndQueuedTaskCounts() {
        int[] queuedTaskCounts = { 0, 1, 2 };
        return executors()
            .flatMap(s -> IntStream.of(queuedTaskCounts)
                     .mapToObj(i -> Arguments.of(s, i)));
    }

-------------

PR: https://git.openjdk.org/jdk/pull/12675

From duke at openjdk.org  Tue Feb 21 20:28:30 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Tue, 21 Feb 2023 20:28:30 GMT
Subject: RFR: 8302871: Speed up StringLatin1.regionMatchesCI [v7]
In-Reply-To: <hfJIZbrr5qSkn0BU1nyriYMyV9cFWN7e1iKHO-bvZks=.a829ef78-fe38-402a-877b-431591d23e15@github.com>
References: <dnsiX3nRffjGjZXJG7lMAZj2FktEl2Wc1XfFthQ4iJs=.8c41438a-80a4-468f-ae0b-7322c9d6d952@github.com>
 <AhNijA3f_Yl5Ornr9pqngR3yaepTQNEJeposarKW-Wg=.90a0b345-88dc-4648-a0fb-c83d1dd7e9d5@github.com>
 <hfJIZbrr5qSkn0BU1nyriYMyV9cFWN7e1iKHO-bvZks=.a829ef78-fe38-402a-877b-431591d23e15@github.com>
Message-ID: <jUSHM1nTkwyjspO5Rn4h-OBQIsE62lvJZK7K-qhq3uI=.94ac5e1c-128e-4991-98d5-c202aa7d0610@github.com>

On Tue, 21 Feb 2023 14:27:03 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Eirik Bjorsnos has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove whitespace following '('
>
> src/java.base/share/classes/java/lang/CharacterDataLatin1.java.template line 175:
> 
>> 173:          }
>> 174:          // uppercase b1 using 'the oldest ASCII trick in the book'
>> 175:          int U = b1 & 0xDF;
> 
> I'm sure some people reading this comment will wonder which book :-) It might be better to drop that bit and if possible, find a better name for "U" as normally variables start with a lower case.

Hi Alan,

I thought I was clever by encoding the 'uppercaseness' in the variable name, but yeah I'll find a better name :)

There is some precedent for using the 'ASCII trick' comment in the JDK.  I found it in ZipFile.isMetaName, which is also where I first learned about this interesting relationship between ASCII (and also latin1) letters.

The comment was first added by Martin Buchholz back in 2016 as part of JDK-8157069, 'Assorted ZipFile improvements'. In 2020, Claes was updating this code and Lance has some input about clarifying the comment. Martin then [chimed in](https://mail.openjdk.org/pipermail/core-libs-dev/2020-May/066363.html) to defend his comment:

> I still like my ancient "ASCII trick" comment.

I think this 'trick', whatever we call it, is sufficiently intricate that it deserves to be called out somehow and that we should not just casually bitmask with these magic constants without any discussion at all. 

An earlier iteration of this PR included a small essay in the javadoc of this method describing the layout and relationship of letters in latin1 and how we can apply that knowledge of the layout to implement the method.

How would you feel about adding that description back to the Javadocs? This would then live close to the similarly implemented toUpperCase and toLowerCase methods currently under review in #12623. 

Here's the updated discussion included in the Javadoc:


    /**
     * Compares two latin1 code points, ignoring case considerations.
     *
     * Implementation note: In ISO/IEC 8859-1, the uppercase and lowercase
     * letters are found in the following code point ranges:
     *
     * 0x41-0x5A: Uppercase ASCII letters: A-Z
     * 0x61-0x7A: Lowercase ASCII letters: a-z
     * 0xC0-0xD6: Uppercase latin1 letters: A-GRAVE - O with Diaeresis
     * 0xD8-0xDE: Uppercase latin1 letters: O with slash - Thorn
     * 0xE0-0xF6: Lowercase latin1 letters: a-grave - o with Diaeresis
     * 0xF8-0xFE: Lowercase latin1 letters: o with slash - thorn
     *
     * While both ASCII letter ranges are contiguous, the latin1 ranges are not:
     *
     * The 'multiplication sign' 0xD7 splits the uppercase range in two.
     * The 'division sign' 0xF7 splits the lowercase range in two.
     *
     * Lowercase letters are found 32 positions (0x20) after their corresponding uppercase letter.
     * The 'division sign' and 'multiplication sign' have the same relative distance.
     *
     * Since 0x20 is a single bit, we can apply the 'oldest ASCII trick in the book' to
     * lowercase any letter by setting the bit:
     *
     * ('C' | 0x20) == 'c'
     *
     * By removing the bit, we can perform the uppercase operation:
     *
     * ('c' & 0xDF) == 'C'
     *
     * Applying this knowledge of the latin1 layout, we can test for equality ignoring case by
     * checking that the code points are either equal, or that one of the code points is a letter
     * which uppercases is the same as the uppercase of the other code point.
     *
     * @param b1 byte representing a latin1 code point
     * @param b2 another byte representing a latin1 code point
     * @return true if the two bytes are considered equals ignoring case in latin1
     */
     static boolean equalsIgnoreCase(byte b1, byte b2) {
         if (b1 == b2) {
             return true;
         }
         int upper = b1 & 0xDF;
         if (upper < 'A') {
             return false;  // Low ASCII
         }
         return (upper <= 'Z' // In range A-Z
                 || (upper >= 0xC0 && upper <= 0XDE && upper != 0xD7)) // ..or A-grave-Thorn, excl. multiplication
                 && upper == (b2 & 0xDF); // b2 has same uppercase
    }

-------------

PR: https://git.openjdk.org/jdk/pull/12632

From martin at openjdk.org  Tue Feb 21 20:30:29 2023
From: martin at openjdk.org (Martin Buchholz)
Date: Tue, 21 Feb 2023 20:30:29 GMT
Subject: RFR: 8302899: Executors.newSingleThreadExecutor can use Cleaner to
 shutdown executor [v2]
In-Reply-To: <4k90pf4Nl6DHOAg1ydW0bKgagFH3ZKfH5cb3C7Fazbk=.e1561c56-2508-48f2-9542-cd95d70e264b@github.com>
References: <tBrSZRn1GdrWMSRUsdNNyAWpkuS_FvtLwLuUKut6LH0=.cd1a7fcb-dbcf-45eb-b3d3-72ba17087566@github.com>
 <Yb8iiHeLmWsAjOwzDqzQJwLNLDY50RhuegwRbl6LHuU=.960992f3-c292-4db2-968f-be03fe273d95@github.com>
 <4k90pf4Nl6DHOAg1ydW0bKgagFH3ZKfH5cb3C7Fazbk=.e1561c56-2508-48f2-9542-cd95d70e264b@github.com>
Message-ID: <Pyef2cyAuj51_8yJnc7rBu91s9XpDtDgdLF1pzD9YKc=.7d42b280-4662-454a-8a29-991a6af6fe99@github.com>

On Tue, 21 Feb 2023 16:36:26 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> test/jdk/java/util/concurrent/Executors/AutoShutdown.java line 133:
>> 
>>> 131:         while (!terminated) {
>>> 132:             System.gc();
>>> 133:             terminated = executor.awaitTermination(100, TimeUnit.MILLISECONDS);
>> 
>> @AlanBateman Perhaps worth having some upper limit as to how long it will wait until failing the test?
>
> jtreg will look after this. The default timeout is 120s but it can be adjusted with a timeout factor (make time uses a timeout factor of 4). So it would be possible to put a limit on this in the test but it can be problematic, e.g. with debug builds + Xcomp for example.

I have written such code many times, and I've always had success with a (jtreg-scaled) 10 second timeout.  E.g.

static final long LONG_DELAY_MS = Utils.adjustTimeout(10_000);

(But that's before I became aware of existence of (slow) Raspberry Pis.)

I continue to feel guilty about never having written a proper gc awaiting library utility for openjdk, like I did for guava here:

https://github.com/google/guava/blob/master/guava-testlib/src/com/google/common/testing/GcFinalization.java

-------------

PR: https://git.openjdk.org/jdk/pull/12675

From naoto at openjdk.org  Tue Feb 21 20:33:26 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 21 Feb 2023 20:33:26 GMT
Subject: RFR: 8302512: Update IANA Language Subtag Registry to Version
 2023-02-14 [v2]
In-Reply-To: <M65a9-Cdfh9cNtFyivbLeL2F8982Aha4ecoLJ2XPsoI=.605031d4-80f4-4065-90bc-373f7e5927dd@github.com>
References: <or0F9vpHLkJyfwpgJfAuFmy8zI1yaZ_H9YAUyiXM3P8=.50952559-8a6d-4e85-bd65-b757d1ae0a3a@github.com>
 <M65a9-Cdfh9cNtFyivbLeL2F8982Aha4ecoLJ2XPsoI=.605031d4-80f4-4065-90bc-373f7e5927dd@github.com>
Message-ID: <YZqlfzSRU5ano5RTOCMUNy7gMpnXbS39VO_BShLPv38=.979de49b-a9d1-4496-9568-81fa967ea0ef@github.com>

On Tue, 21 Feb 2023 20:08:41 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Incorporate the latest IANA language subtag registry definition (2023-02-14).
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Copyright + correct date format

Marked as reviewed by naoto (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/12699

From duke at openjdk.org  Tue Feb 21 20:36:32 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Tue, 21 Feb 2023 20:36:32 GMT
Subject: RFR: 8302871: Speed up StringLatin1.regionMatchesCI [v7]
In-Reply-To: <jUSHM1nTkwyjspO5Rn4h-OBQIsE62lvJZK7K-qhq3uI=.94ac5e1c-128e-4991-98d5-c202aa7d0610@github.com>
References: <dnsiX3nRffjGjZXJG7lMAZj2FktEl2Wc1XfFthQ4iJs=.8c41438a-80a4-468f-ae0b-7322c9d6d952@github.com>
 <AhNijA3f_Yl5Ornr9pqngR3yaepTQNEJeposarKW-Wg=.90a0b345-88dc-4648-a0fb-c83d1dd7e9d5@github.com>
 <hfJIZbrr5qSkn0BU1nyriYMyV9cFWN7e1iKHO-bvZks=.a829ef78-fe38-402a-877b-431591d23e15@github.com>
 <jUSHM1nTkwyjspO5Rn4h-OBQIsE62lvJZK7K-qhq3uI=.94ac5e1c-128e-4991-98d5-c202aa7d0610@github.com>
Message-ID: <rXD4iIFMdlGyHf7E2a4O2Oz6iQmrItoFdp3pREh8yl0=.c407b886-9646-4a83-94a3-8f738e94ea06@github.com>

On Tue, 21 Feb 2023 20:23:11 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/CharacterDataLatin1.java.template line 175:
>> 
>>> 173:          }
>>> 174:          // uppercase b1 using 'the oldest ASCII trick in the book'
>>> 175:          int U = b1 & 0xDF;
>> 
>> I'm sure some people reading this comment will wonder which book :-) It might be better to drop that bit and if possible, find a better name for "U" as normally variables start with a lower case.
>
> Hi Alan,
> 
> I thought I was clever by encoding the 'uppercaseness' in the variable name, but yeah I'll find a better name :)
> 
> There is some precedent for using the 'ASCII trick' comment in the JDK.  I found it in ZipFile.isMetaName, which is also where I first learned about this interesting relationship between ASCII (and also latin1) letters.
> 
> The comment was first added by Martin Buchholz back in 2016 as part of JDK-8157069, 'Assorted ZipFile improvements'. In 2020, Claes was updating this code and Lance has some input about clarifying the comment. Martin then [chimed in](https://mail.openjdk.org/pipermail/core-libs-dev/2020-May/066363.html) to defend his comment:
> 
>> I still like my ancient "ASCII trick" comment.
> 
> I think this 'trick', whatever we call it, is sufficiently intricate that it deserves to be called out somehow and that we should not just casually bitmask with these magic constants without any discussion at all. 
> 
> An earlier iteration of this PR included a small essay in the javadoc of this method describing the layout and relationship of letters in latin1 and how we can apply that knowledge of the layout to implement the method.
> 
> How would you feel about adding that description back to the Javadocs? This would then live close to the similarly implemented toUpperCase and toLowerCase methods currently under review in #12623. 
> 
> Here's the updated discussion included in the Javadoc:
> 
> 
>     /**
>      * Compares two latin1 code points, ignoring case considerations.
>      *
>      * Implementation note: In ISO/IEC 8859-1, the uppercase and lowercase
>      * letters are found in the following code point ranges:
>      *
>      * 0x41-0x5A: Uppercase ASCII letters: A-Z
>      * 0x61-0x7A: Lowercase ASCII letters: a-z
>      * 0xC0-0xD6: Uppercase latin1 letters: A-GRAVE - O with Diaeresis
>      * 0xD8-0xDE: Uppercase latin1 letters: O with slash - Thorn
>      * 0xE0-0xF6: Lowercase latin1 letters: a-grave - o with Diaeresis
>      * 0xF8-0xFE: Lowercase latin1 letters: o with slash - thorn
>      *
>      * While both ASCII letter ranges are contiguous, the latin1 ranges are not:
>      *
>      * The 'multiplication sign' 0xD7 splits the uppercase range in two.
>      * The 'division sign' 0xF7 splits the lowercase range in two.
>      *
>      * Lowercase letters are found 32 positions (0x20) after their corresponding uppercase letter.
>      * The 'division sign' and 'multiplication sign' have the same relative distance.
>      *
>      * Since 0x20 is a single bit, we can apply the 'oldest ASCII trick in the book' to
>      * lowercase any letter by setting the bit:
>      *
>      * ('C' | 0x20) == 'c'
>      *
>      * By removing the bit, we can perform the uppercase operation:
>      *
>      * ('c' & 0xDF) == 'C'
>      *
>      * Applying this knowledge of the latin1 layout, we can test for equality ignoring case by
>      * checking that the code points are either equal, or that one of the code points is a letter
>      * which uppercases is the same as the uppercase of the other code point.
>      *
>      * @param b1 byte representing a latin1 code point
>      * @param b2 another byte representing a latin1 code point
>      * @return true if the two bytes are considered equals ignoring case in latin1
>      */
>      static boolean equalsIgnoreCase(byte b1, byte b2) {
>          if (b1 == b2) {
>              return true;
>          }
>          int upper = b1 & 0xDF;
>          if (upper < 'A') {
>              return false;  // Low ASCII
>          }
>          return (upper <= 'Z' // In range A-Z
>                  || (upper >= 0xC0 && upper <= 0XDE && upper != 0xD7)) // ..or A-grave-Thorn, excl. multiplication
>                  && upper == (b2 & 0xDF); // b2 has same uppercase
>     }

Perhaps @Martin-Buchholz could chime in and also tell us which book he found his ASCII trick in :)

-------------

PR: https://git.openjdk.org/jdk/pull/12632

From tvaleev at openjdk.org  Tue Feb 21 20:39:53 2023
From: tvaleev at openjdk.org (Tagir F. Valeev)
Date: Tue, 21 Feb 2023 20:39:53 GMT
Subject: RFR: 8302815 Use new Math.clamp method in core libraries [v3]
In-Reply-To: <k_xjmup3YSdUre0Z_XpO-WEBb5XED2FYv8UUZT2ULwc=.86f53f51-cceb-45fd-935d-b054c79a0526@github.com>
References: <k_xjmup3YSdUre0Z_XpO-WEBb5XED2FYv8UUZT2ULwc=.86f53f51-cceb-45fd-935d-b054c79a0526@github.com>
Message-ID: <x9AvETt9Izy_oPiBzHuTLn8ME5GHWkl-udew_-jjAW8=.c084c1fb-2495-4650-b789-b3fee360c502@github.com>

> For cleanup and dogfooding the new method, it would be nice to use Math.clamp where possible in java.base. See PR #12428.
> 
> As Math.clamp performs an additional check that min is not greater than max, I conservatively replaced only those occurrences where I can see that this invariant is always held. There are more occurrences, where clamp can be potentially used but it's unclear whether min <= max is always true.

Tagir F. Valeev 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/12633/files
  - new: https://git.openjdk.org/jdk/pull/12633/files/be13683b..e3fb1502

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12633&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12633&range=01-02

  Stats: 8 lines in 8 files changed: 0 ins; 0 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/12633.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12633/head:pull/12633

PR: https://git.openjdk.org/jdk/pull/12633

From tvaleev at openjdk.org  Tue Feb 21 20:39:53 2023
From: tvaleev at openjdk.org (Tagir F. Valeev)
Date: Tue, 21 Feb 2023 20:39:53 GMT
Subject: RFR: 8302815 Use new Math.clamp method in core libraries [v2]
In-Reply-To: <p39HBUvKXHb3vPIiEF6yzjm9R0Ez9tRvqo7CDEHFQuk=.83b3b667-24af-426e-a59d-833e5e1a58ca@github.com>
References: <k_xjmup3YSdUre0Z_XpO-WEBb5XED2FYv8UUZT2ULwc=.86f53f51-cceb-45fd-935d-b054c79a0526@github.com>
 <V5pROUz9W7-O5FDi8LQ9dgWzsiJKfl9Y9xi_VmYvT4A=.9835b9b3-aeb5-484b-ac57-74d1071ed9da@github.com>
 <p39HBUvKXHb3vPIiEF6yzjm9R0Ez9tRvqo7CDEHFQuk=.83b3b667-24af-426e-a59d-833e5e1a58ca@github.com>
Message-ID: <Niq36ljL-AlwQ8DKZmYxEw5D_g0YwcC9gKRn1fzsMyc=.e7fa2da2-f3eb-4313-aaab-4a8154cd20f2@github.com>

On Sun, 19 Feb 2023 08:54:56 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Tagir F. Valeev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Revert changes in JrtPath, as it seems to be compiled with bootstrap JDK
>
>> Revert changes in JrtPath, as it seems to be compiled with bootstrap JDK
> 
> Yes, the jrt file system provider is compiled --release 8 to create lib/jrt-fs.jar. That's the plumbing needed to allow IDEs/tools running on JDK 8 access the contents of a target run-time image as a file system.

@AlanBateman thank you for review! Argh, I always forget about copyright year. Probably it's possible to update jcheck to make this check automated?

-------------

PR: https://git.openjdk.org/jdk/pull/12633

From martin at openjdk.org  Tue Feb 21 20:50:29 2023
From: martin at openjdk.org (Martin Buchholz)
Date: Tue, 21 Feb 2023 20:50:29 GMT
Subject: RFR: 8302871: Speed up StringLatin1.regionMatchesCI [v7]
In-Reply-To: <rXD4iIFMdlGyHf7E2a4O2Oz6iQmrItoFdp3pREh8yl0=.c407b886-9646-4a83-94a3-8f738e94ea06@github.com>
References: <dnsiX3nRffjGjZXJG7lMAZj2FktEl2Wc1XfFthQ4iJs=.8c41438a-80a4-468f-ae0b-7322c9d6d952@github.com>
 <AhNijA3f_Yl5Ornr9pqngR3yaepTQNEJeposarKW-Wg=.90a0b345-88dc-4648-a0fb-c83d1dd7e9d5@github.com>
 <hfJIZbrr5qSkn0BU1nyriYMyV9cFWN7e1iKHO-bvZks=.a829ef78-fe38-402a-877b-431591d23e15@github.com>
 <jUSHM1nTkwyjspO5Rn4h-OBQIsE62lvJZK7K-qhq3uI=.94ac5e1c-128e-4991-98d5-c202aa7d0610@github.com>
 <rXD4iIFMdlGyHf7E2a4O2Oz6iQmrItoFdp3pREh8yl0=.c407b886-9646-4a83-94a3-8f738e94ea06@github.com>
Message-ID: <bYxNp9wXu0hHmU5U7L0AekEKt2hSBAhwpZbFePTlkRw=.8b96e631-82eb-4190-854a-88f3af25716b@github.com>

On Tue, 21 Feb 2023 20:33:41 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

>> Hi Alan,
>> 
>> I thought I was clever by encoding the 'uppercaseness' in the variable name, but yeah I'll find a better name :)
>> 
>> There is some precedent for using the 'ASCII trick' comment in the JDK.  I found it in ZipFile.isMetaName, which is also where I first learned about this interesting relationship between ASCII (and also latin1) letters.
>> 
>> The comment was first added by Martin Buchholz back in 2016 as part of JDK-8157069, 'Assorted ZipFile improvements'. In 2020, Claes was updating this code and Lance has some input about clarifying the comment. Martin then [chimed in](https://mail.openjdk.org/pipermail/core-libs-dev/2020-May/066363.html) to defend his comment:
>> 
>>> I still like my ancient "ASCII trick" comment.
>> 
>> I think this 'trick', whatever we call it, is sufficiently intricate that it deserves to be called out somehow and that we should not just casually bitmask with these magic constants without any discussion at all. 
>> 
>> An earlier iteration of this PR included a small essay in the javadoc of this method describing the layout and relationship of letters in latin1 and how we can apply that knowledge of the layout to implement the method.
>> 
>> How would you feel about adding that description back to the Javadocs? This would then live close to the similarly implemented toUpperCase and toLowerCase methods currently under review in #12623. 
>> 
>> Here's the updated discussion included in the Javadoc:
>> 
>> 
>>     /**
>>      * Compares two latin1 code points, ignoring case considerations.
>>      *
>>      * Implementation note: In ISO/IEC 8859-1, the uppercase and lowercase
>>      * letters are found in the following code point ranges:
>>      *
>>      * 0x41-0x5A: Uppercase ASCII letters: A-Z
>>      * 0x61-0x7A: Lowercase ASCII letters: a-z
>>      * 0xC0-0xD6: Uppercase latin1 letters: A-GRAVE - O with Diaeresis
>>      * 0xD8-0xDE: Uppercase latin1 letters: O with slash - Thorn
>>      * 0xE0-0xF6: Lowercase latin1 letters: a-grave - o with Diaeresis
>>      * 0xF8-0xFE: Lowercase latin1 letters: o with slash - thorn
>>      *
>>      * While both ASCII letter ranges are contiguous, the latin1 ranges are not:
>>      *
>>      * The 'multiplication sign' 0xD7 splits the uppercase range in two.
>>      * The 'division sign' 0xF7 splits the lowercase range in two.
>>      *
>>      * Lowercase letters are found 32 positions (0x20) after their corresponding uppercase letter.
>>      * The 'division sign' and 'multiplication sign' have the same relative distance.
>>      *
>>      * Since 0x20 is a single bit, we can apply the 'oldest ASCII trick in the book' to
>>      * lowercase any letter by setting the bit:
>>      *
>>      * ('C' | 0x20) == 'c'
>>      *
>>      * By removing the bit, we can perform the uppercase operation:
>>      *
>>      * ('c' & 0xDF) == 'C'
>>      *
>>      * Applying this knowledge of the latin1 layout, we can test for equality ignoring case by
>>      * checking that the code points are either equal, or that one of the code points is a letter
>>      * which uppercases is the same as the uppercase of the other code point.
>>      *
>>      * @param b1 byte representing a latin1 code point
>>      * @param b2 another byte representing a latin1 code point
>>      * @return true if the two bytes are considered equals ignoring case in latin1
>>      */
>>      static boolean equalsIgnoreCase(byte b1, byte b2) {
>>          if (b1 == b2) {
>>              return true;
>>          }
>>          int upper = b1 & 0xDF;
>>          if (upper < 'A') {
>>              return false;  // Low ASCII
>>          }
>>          return (upper <= 'Z' // In range A-Z
>>                  || (upper >= 0xC0 && upper <= 0XDE && upper != 0xD7)) // ..or A-grave-Thorn, excl. multiplication
>>                  && upper == (b2 & 0xDF); // b2 has same uppercase
>>     }
>
> Perhaps @Martin-Buchholz could chime in and also tell us which book he found his ASCII trick in :)

"oldest trick in the book" is a phrase that does not necessarily imply existence of an actual book!

Let this evoke an image of a **personal** book of tricks that programmers in the 1960s might have recorded such techniques in.  And the tricks were passed down across generations of programmers!

-------------

PR: https://git.openjdk.org/jdk/pull/12632

From duke at openjdk.org  Tue Feb 21 20:57:43 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Tue, 21 Feb 2023 20:57:43 GMT
Subject: Integrated: 8302877: Speed up latin1 case conversions
In-Reply-To: <cf9hc-SBdgzB1lpqXGLHKcjT4-T9hLaMs1cCccqBiak=.f7b99e9d-3206-4e67-976f-ea0492ec6b06@github.com>
References: <cf9hc-SBdgzB1lpqXGLHKcjT4-T9hLaMs1cCccqBiak=.f7b99e9d-3206-4e67-976f-ea0492ec6b06@github.com>
Message-ID: <j2UqaMozv8HwYxJwclrcNj0r8ubGzjNB1NYjnWZOF04=.19b23953-321d-4418-93ae-f15eed25ed1f@github.com>

On Fri, 17 Feb 2023 17:31:09 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

> This PR suggests we speed up Character.toUpperCase and Character.toLowerCase for latin1 code points by applying the 'oldest ASCII trick in the book'.
> 
> This takes advantage of the fact that latin1 uppercase code points are always 0x20 lower than their lowercase (with the exception of two code points which uppercase out of latin1).
> 
> To verify the correctness of the new implementation, the test `Latin1CaseConversion` is added with an exhaustive verification of toUpperCase/toLowerCase for all latin1 code points.
> 
> The implementation needs to balance the performance of the various ranges in latin1. An effort has been made to favour operations on ASCII code points, without causing excessive regression for higher code points.
> 
> Performance is benchmarked for 7 chosen sample code points, each representing a range or a special-case.  Results in the first comment.

This pull request has now been integrated.

Changeset: ef1f7bd3
Author:    Eirik Bjorsnos <eirbjo at gmail.com>
Committer: Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/ef1f7bd3b80f8777c15ab22b1dff7dfe4f084734
Stats:     166 lines in 5 files changed: 143 ins; 0 del; 23 mod

8302877: Speed up latin1 case conversions

Reviewed-by: naoto, redestad

-------------

PR: https://git.openjdk.org/jdk/pull/12623

From igraves at openjdk.org  Tue Feb 21 21:10:30 2023
From: igraves at openjdk.org (Ian Graves)
Date: Tue, 21 Feb 2023 21:10:30 GMT
Subject: RFR: 8293667: Align jlink's --compress option with jmod's
 --compress option [v2]
In-Reply-To: <WrMY2LsSoiNiZwxPymGn5TDhns5FRyoMUkb1NDqPTkg=.8411c497-47f8-4834-aeda-ff746024a106@github.com>
References: <JWevwHuR2vF3k-JRxmTAxfNN6g-EBkgG2N9DHn4fkGY=.f9768dfd-cab4-49a9-83b9-d77a1572e917@github.com>
 <L0YQ-HpkzstQ-kaNwoO3BxLqgcluDK5Lzt8R9c9ZGSs=.637129c6-047c-4197-8ed2-70d0a203ec90@github.com>
 <z4Lh3mo4wSeVY8LS-NSPsEdCKnBGNmzBkIRKtpecQl8=.4ff4a5d7-b50f-42a7-9e40-6bd71d37da79@github.com>
 <90W6AVU6RNPg3e3UgscPlDJGT2rUaVkduOmuoI8pOJU=.c35ea283-c399-4fda-9e60-3a1b679791ec@github.com>
 <WrMY2LsSoiNiZwxPymGn5TDhns5FRyoMUkb1NDqPTkg=.8411c497-47f8-4834-aeda-ff746024a106@github.com>
Message-ID: <BNb2ETReOl4xfnUM-4NAaUSkkaQd7SNI3jiNCZ-lFJA=.9b59e4fe-cd22-41a9-9105-c23b11b36ce9@github.com>

On Thu, 16 Feb 2023 22:50:25 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> I think, there's also a typo in the next line:
>> 
>> checkCompress(classes, compressPlugin,
>> 
>> should have been:
>> 
>> checkCompress(classes, compressPluginZip0,
>> 
>> I haven't yet looked at the existing test code in `checkCompress` method, but it might need a closer look as to why this test passed. I would have expected it to fail due to the typos.
>
> @jaikiran is right.  This test is to set up `optionsZip0` and `compressPluginZip0` to verify `zip-0`.

Thanks all!

-------------

PR: https://git.openjdk.org/jdk/pull/11617

From dholmes at openjdk.org  Tue Feb 21 21:18:25 2023
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 21 Feb 2023 21:18:25 GMT
Subject: RFR: 8302877: Speed up latin1 case conversions [v3]
In-Reply-To: <iiq-I9Y0N-vXz5xrdxsD4QMyIlM3YhUdz3jjNktCn9Y=.a5979762-dbbb-4a4f-a9e6-feffdc17beb6@github.com>
References: <cf9hc-SBdgzB1lpqXGLHKcjT4-T9hLaMs1cCccqBiak=.f7b99e9d-3206-4e67-976f-ea0492ec6b06@github.com>
 <iiq-I9Y0N-vXz5xrdxsD4QMyIlM3YhUdz3jjNktCn9Y=.a5979762-dbbb-4a4f-a9e6-feffdc17beb6@github.com>
Message-ID: <nLsLehUDD-Cj_q4XSWSJuWA4_h4J5IbbdrIVZ-eJNQs=.fa2e1c5a-8d51-4e69-879e-67e4cde22163@github.com>

On Tue, 21 Feb 2023 11:12:18 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

>> This PR suggests we speed up Character.toUpperCase and Character.toLowerCase for latin1 code points by applying the 'oldest ASCII trick in the book'.
>> 
>> This takes advantage of the fact that latin1 uppercase code points are always 0x20 lower than their lowercase (with the exception of two code points which uppercase out of latin1).
>> 
>> To verify the correctness of the new implementation, the test `Latin1CaseConversion` is added with an exhaustive verification of toUpperCase/toLowerCase for all latin1 code points.
>> 
>> The implementation needs to balance the performance of the various ranges in latin1. An effort has been made to favour operations on ASCII code points, without causing excessive regression for higher code points.
>> 
>> Performance is benchmarked for 7 chosen sample code points, each representing a range or a special-case.  Results in the first comment.
>
> Eirik Bjorsnos has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Allow any integer codePoint by defaulting to Integer.parseInt
>  - Rename Latin1CaseConversions to just CaseConversions
>  - Remove a whitespace following 'if ('

The testcase change is failing to compile:

open/test/micro/org/openjdk/bench/java/lang/Characters.java:115: error: case, default, or '}' expected

-------------

PR: https://git.openjdk.org/jdk/pull/12623

From duke at openjdk.org  Tue Feb 21 21:25:42 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Tue, 21 Feb 2023 21:25:42 GMT
Subject: RFR: 8302877: Speed up latin1 case conversions [v3]
In-Reply-To: <nLsLehUDD-Cj_q4XSWSJuWA4_h4J5IbbdrIVZ-eJNQs=.fa2e1c5a-8d51-4e69-879e-67e4cde22163@github.com>
References: <cf9hc-SBdgzB1lpqXGLHKcjT4-T9hLaMs1cCccqBiak=.f7b99e9d-3206-4e67-976f-ea0492ec6b06@github.com>
 <iiq-I9Y0N-vXz5xrdxsD4QMyIlM3YhUdz3jjNktCn9Y=.a5979762-dbbb-4a4f-a9e6-feffdc17beb6@github.com>
 <nLsLehUDD-Cj_q4XSWSJuWA4_h4J5IbbdrIVZ-eJNQs=.fa2e1c5a-8d51-4e69-879e-67e4cde22163@github.com>
Message-ID: <RxtkFj8maWzmcFTfQIjx7UlFm3FR-u7F_pk3rdCWgwM=.7de7d3d9-eebd-4137-9964-e89155556cd3@github.com>

On Tue, 21 Feb 2023 21:15:33 GMT, David Holmes <dholmes at openjdk.org> wrote:

> The testcase change is failing to compile:
> 
> ```
> open/test/micro/org/openjdk/bench/java/lang/Characters.java:115: error: case, default, or '}' expected
> ```

Darn, this was rather embarrassing!

Since this was just integrated, I guess I'll need to open a new PR for the fix?

-------------

PR: https://git.openjdk.org/jdk/pull/12623

From naoto at openjdk.org  Tue Feb 21 21:31:48 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 21 Feb 2023 21:31:48 GMT
Subject: RFR: 8302877: Speed up latin1 case conversions [v3]
In-Reply-To: <iiq-I9Y0N-vXz5xrdxsD4QMyIlM3YhUdz3jjNktCn9Y=.a5979762-dbbb-4a4f-a9e6-feffdc17beb6@github.com>
References: <cf9hc-SBdgzB1lpqXGLHKcjT4-T9hLaMs1cCccqBiak=.f7b99e9d-3206-4e67-976f-ea0492ec6b06@github.com>
 <iiq-I9Y0N-vXz5xrdxsD4QMyIlM3YhUdz3jjNktCn9Y=.a5979762-dbbb-4a4f-a9e6-feffdc17beb6@github.com>
Message-ID: <Gm25gOuSTwhdaa6-1_kmZPcaipBwT-sxZZuJKXiODLk=.cc673786-e735-443c-a71a-488742b1b42a@github.com>

On Tue, 21 Feb 2023 11:12:18 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

>> This PR suggests we speed up Character.toUpperCase and Character.toLowerCase for latin1 code points by applying the 'oldest ASCII trick in the book'.
>> 
>> This takes advantage of the fact that latin1 uppercase code points are always 0x20 lower than their lowercase (with the exception of two code points which uppercase out of latin1).
>> 
>> To verify the correctness of the new implementation, the test `Latin1CaseConversion` is added with an exhaustive verification of toUpperCase/toLowerCase for all latin1 code points.
>> 
>> The implementation needs to balance the performance of the various ranges in latin1. An effort has been made to favour operations on ASCII code points, without causing excessive regression for higher code points.
>> 
>> Performance is benchmarked for 7 chosen sample code points, each representing a range or a special-case.  Results in the first comment.
>
> Eirik Bjorsnos has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Allow any integer codePoint by defaulting to Integer.parseInt
>  - Rename Latin1CaseConversions to just CaseConversions
>  - Remove a whitespace following 'if ('

Yes please.

https://bugs.openjdk.org/browse/JDK-8303033

-------------

PR: https://git.openjdk.org/jdk/pull/12623

From duke at openjdk.org  Tue Feb 21 21:31:49 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Tue, 21 Feb 2023 21:31:49 GMT
Subject: RFR: 8302877: Speed up latin1 case conversions [v3]
In-Reply-To: <iiq-I9Y0N-vXz5xrdxsD4QMyIlM3YhUdz3jjNktCn9Y=.a5979762-dbbb-4a4f-a9e6-feffdc17beb6@github.com>
References: <cf9hc-SBdgzB1lpqXGLHKcjT4-T9hLaMs1cCccqBiak=.f7b99e9d-3206-4e67-976f-ea0492ec6b06@github.com>
 <iiq-I9Y0N-vXz5xrdxsD4QMyIlM3YhUdz3jjNktCn9Y=.a5979762-dbbb-4a4f-a9e6-feffdc17beb6@github.com>
Message-ID: <bHxHuUqbwQLwSc2A4QEtv6YdBw_MnEPPTAzIcfq0uy0=.75238e82-2df1-42e7-bf5f-ae0c04b69757@github.com>

On Tue, 21 Feb 2023 11:12:18 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

>> This PR suggests we speed up Character.toUpperCase and Character.toLowerCase for latin1 code points by applying the 'oldest ASCII trick in the book'.
>> 
>> This takes advantage of the fact that latin1 uppercase code points are always 0x20 lower than their lowercase (with the exception of two code points which uppercase out of latin1).
>> 
>> To verify the correctness of the new implementation, the test `Latin1CaseConversion` is added with an exhaustive verification of toUpperCase/toLowerCase for all latin1 code points.
>> 
>> The implementation needs to balance the performance of the various ranges in latin1. An effort has been made to favour operations on ASCII code points, without causing excessive regression for higher code points.
>> 
>> Performance is benchmarked for 7 chosen sample code points, each representing a range or a special-case.  Results in the first comment.
>
> Eirik Bjorsnos has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Allow any integer codePoint by defaulting to Integer.parseInt
>  - Rename Latin1CaseConversions to just CaseConversions
>  - Remove a whitespace following 'if ('

I created https://github.com/openjdk/jdk/pull/12701 for this.

Could someone please file a JBS?

-------------

PR: https://git.openjdk.org/jdk/pull/12623

From duke at openjdk.org  Tue Feb 21 21:36:43 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Tue, 21 Feb 2023 21:36:43 GMT
Subject: RFR: 8302877: Speed up latin1 case conversions [v3]
In-Reply-To: <iiq-I9Y0N-vXz5xrdxsD4QMyIlM3YhUdz3jjNktCn9Y=.a5979762-dbbb-4a4f-a9e6-feffdc17beb6@github.com>
References: <cf9hc-SBdgzB1lpqXGLHKcjT4-T9hLaMs1cCccqBiak=.f7b99e9d-3206-4e67-976f-ea0492ec6b06@github.com>
 <iiq-I9Y0N-vXz5xrdxsD4QMyIlM3YhUdz3jjNktCn9Y=.a5979762-dbbb-4a4f-a9e6-feffdc17beb6@github.com>
Message-ID: <8RDZdTFOOIyMzejhh_oAcGIJLf88g-nmr_4c18TRGY0=.45504582-6caf-47c4-ace5-d02db0cbab37@github.com>

On Tue, 21 Feb 2023 11:12:18 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

>> This PR suggests we speed up Character.toUpperCase and Character.toLowerCase for latin1 code points by applying the 'oldest ASCII trick in the book'.
>> 
>> This takes advantage of the fact that latin1 uppercase code points are always 0x20 lower than their lowercase (with the exception of two code points which uppercase out of latin1).
>> 
>> To verify the correctness of the new implementation, the test `Latin1CaseConversion` is added with an exhaustive verification of toUpperCase/toLowerCase for all latin1 code points.
>> 
>> The implementation needs to balance the performance of the various ranges in latin1. An effort has been made to favour operations on ASCII code points, without causing excessive regression for higher code points.
>> 
>> Performance is benchmarked for 7 chosen sample code points, each representing a range or a special-case.  Results in the first comment.
>
> Eirik Bjorsnos has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Allow any integer codePoint by defaulting to Integer.parseInt
>  - Rename Latin1CaseConversions to just CaseConversions
>  - Remove a whitespace following 'if ('

Thanks, #12701 is ready for review.

-------------

PR: https://git.openjdk.org/jdk/pull/12623

From duke at openjdk.org  Tue Feb 21 21:45:30 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Tue, 21 Feb 2023 21:45:30 GMT
Subject: Integrated: 8303033: Build failure with the micro bench mark
Message-ID: <w_H9URC7gSDOrSW9cSui7zbVFFud6Gal9gOq6r9EWy0=.f24d3c56-c19e-46b7-96b6-155f19d6d343@github.com>

The last commit to #12623 introduced a compilation error caused by an extra semicolon. This PR fixes this.

-------------

Commit messages:
 - Fix complication error caused by extra semicolon

Changes: https://git.openjdk.org/jdk/pull/12701/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12701&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8303033
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/12701.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12701/head:pull/12701

PR: https://git.openjdk.org/jdk/pull/12701

From naoto at openjdk.org  Tue Feb 21 21:45:31 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 21 Feb 2023 21:45:31 GMT
Subject: Integrated: 8303033: Build failure with the micro bench mark
In-Reply-To: <w_H9URC7gSDOrSW9cSui7zbVFFud6Gal9gOq6r9EWy0=.f24d3c56-c19e-46b7-96b6-155f19d6d343@github.com>
References: <w_H9URC7gSDOrSW9cSui7zbVFFud6Gal9gOq6r9EWy0=.f24d3c56-c19e-46b7-96b6-155f19d6d343@github.com>
Message-ID: <VB0xTYZoyrPFx7XApUlR3AeBVIVoWcMmg8hHNNPsIME=.a604997e-874a-4a73-96a1-36b7bad13f9c@github.com>

On Tue, 21 Feb 2023 21:27:08 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

> The last commit to #12623 introduced a compilation error caused by an extra semicolon. This PR fixes this.

Marked as reviewed by naoto (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/12701

From duke at openjdk.org  Tue Feb 21 21:45:31 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Tue, 21 Feb 2023 21:45:31 GMT
Subject: Integrated: 8303033: Build failure with the micro bench mark
In-Reply-To: <w_H9URC7gSDOrSW9cSui7zbVFFud6Gal9gOq6r9EWy0=.f24d3c56-c19e-46b7-96b6-155f19d6d343@github.com>
References: <w_H9URC7gSDOrSW9cSui7zbVFFud6Gal9gOq6r9EWy0=.f24d3c56-c19e-46b7-96b6-155f19d6d343@github.com>
Message-ID: <apIByN8G5cs-S32EihCCh2LCqGss-Zxb9QjjM1hNFtk=.14934680-d967-499a-8856-8b639d977087@github.com>

On Tue, 21 Feb 2023 21:27:08 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

> The last commit to #12623 introduced a compilation error caused by an extra semicolon. This PR fixes this.

Thanks for the quick turnaround Naoto. I'll find a suitable way to punish myself for this one!

-------------

PR: https://git.openjdk.org/jdk/pull/12701

From duke at openjdk.org  Tue Feb 21 21:45:32 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Tue, 21 Feb 2023 21:45:32 GMT
Subject: Integrated: 8303033: Build failure with the micro bench mark
In-Reply-To: <w_H9URC7gSDOrSW9cSui7zbVFFud6Gal9gOq6r9EWy0=.f24d3c56-c19e-46b7-96b6-155f19d6d343@github.com>
References: <w_H9URC7gSDOrSW9cSui7zbVFFud6Gal9gOq6r9EWy0=.f24d3c56-c19e-46b7-96b6-155f19d6d343@github.com>
Message-ID: <kn6L6TbffgDfnoVKQ0oQ5oqwMy93FMtQ3mAX0ZKBEDE=.93ae5d4d-5049-4381-82b9-a726a27a5750@github.com>

On Tue, 21 Feb 2023 21:27:08 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

> The last commit to #12623 introduced a compilation error caused by an extra semicolon. This PR fixes this.

This pull request has now been integrated.

Changeset: e950b954
Author:    Eirik Bjorsnos <eirbjo at gmail.com>
Committer: Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/e950b95486d468bbad758d5ba0e5a36445b4cc3c
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8303033: Build failure with the micro bench mark

Reviewed-by: naoto

-------------

PR: https://git.openjdk.org/jdk/pull/12701

From naoto at openjdk.org  Tue Feb 21 21:51:48 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 21 Feb 2023 21:51:48 GMT
Subject: Integrated: 8303033: Build failure with the micro bench mark
In-Reply-To: <apIByN8G5cs-S32EihCCh2LCqGss-Zxb9QjjM1hNFtk=.14934680-d967-499a-8856-8b639d977087@github.com>
References: <w_H9URC7gSDOrSW9cSui7zbVFFud6Gal9gOq6r9EWy0=.f24d3c56-c19e-46b7-96b6-155f19d6d343@github.com>
 <apIByN8G5cs-S32EihCCh2LCqGss-Zxb9QjjM1hNFtk=.14934680-d967-499a-8856-8b639d977087@github.com>
Message-ID: <ARMfpQa8aMn_WkfQ5g2r6wdr5ve5c4bt2tj3CCAFCZU=.16daf65e-0777-4e35-ba04-d6d25e3a46e6@github.com>

On Tue, 21 Feb 2023 21:41:29 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

> Thanks for the quick turnaround Naoto. I'll find a suitable way to punish myself for this one!

Thanks for the quick fix ?

-------------

PR: https://git.openjdk.org/jdk/pull/12701

From duke at openjdk.org  Tue Feb 21 21:53:10 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Tue, 21 Feb 2023 21:53:10 GMT
Subject: RFR: 8302871: Speed up StringLatin1.regionMatchesCI [v8]
In-Reply-To: <dnsiX3nRffjGjZXJG7lMAZj2FktEl2Wc1XfFthQ4iJs=.8c41438a-80a4-468f-ae0b-7322c9d6d952@github.com>
References: <dnsiX3nRffjGjZXJG7lMAZj2FktEl2Wc1XfFthQ4iJs=.8c41438a-80a4-468f-ae0b-7322c9d6d952@github.com>
Message-ID: <j5TbvwLVJlvUENV1DpAiM7yVwP0WZVwIAAZjVR0YCew=.9b029f6c-6a25-4b54-a07d-b67a81f948e6@github.com>

> This PR suggests we can speed up `StringLatin1.regionMatchesCI` by applying 'the oldest ASCII trick in the book'.
> 
> The new static method `CharacterDataLatin1.equalsIgnoreCase` compares two latin1 bytes for equality ignoring case. `StringLatin1.regionMatchesCI` is updated to use `equalsIgnoreCase`
> 
> To verify the correctness of `equalsIgnoreCase`, a new test is added  to `EqualsIgnoreCase` with an exhaustive verification that all 256x256 latin1 code point pairs have an `equalsIgnoreCase` consistent with Character.toUpperCase, Character.toLowerCase.
> 
> Performance is tested for matching and mismatching cases of code point pairs picked from the ASCII letter, ASCII number and latin1 letter ranges. Results in the first comment below.

Eirik Bjorsnos 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:

 - Add whitespace between methods
 - Merge branch 'master' into regionmatches-latin1-speedup
 - Remove whitespace following '('
 - Revert "Spell fix for 'exhaustive' in comments in sun/text/resources"
   
   This reverts commit 5e9927a4b35e157fd3fa72fd2663c8bfbecf32bb.
 - Spell fix for 'exhaustive' in comments in sun/text/resources
 - Add @bug tag to EqualsIgnoreCase test for correct issue JDK-8302871
 - Add @bug tag to EqualsIgnoreCase test for JDK-8302877
 - Add clarifying comments and use more descriptive variable names in the latin1 verification EqualsIgnoreCase test
 - Align whitespace to make example strings easier to read
 - Merge branch 'master' into regionmatches-latin1-speedup
 - ... and 3 more: https://git.openjdk.org/jdk/compare/ea62160f...718fcead

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12632/files
  - new: https://git.openjdk.org/jdk/pull/12632/files/d7b1c164..718fcead

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12632&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12632&range=06-07

  Stats: 4282 lines in 198 files changed: 2630 ins; 1129 del; 523 mod
  Patch: https://git.openjdk.org/jdk/pull/12632.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12632/head:pull/12632

PR: https://git.openjdk.org/jdk/pull/12632

From duke at openjdk.org  Tue Feb 21 21:59:33 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Tue, 21 Feb 2023 21:59:33 GMT
Subject: RFR: 8302871: Speed up StringLatin1.regionMatchesCI [v7]
In-Reply-To: <hfJIZbrr5qSkn0BU1nyriYMyV9cFWN7e1iKHO-bvZks=.a829ef78-fe38-402a-877b-431591d23e15@github.com>
References: <dnsiX3nRffjGjZXJG7lMAZj2FktEl2Wc1XfFthQ4iJs=.8c41438a-80a4-468f-ae0b-7322c9d6d952@github.com>
 <AhNijA3f_Yl5Ornr9pqngR3yaepTQNEJeposarKW-Wg=.90a0b345-88dc-4648-a0fb-c83d1dd7e9d5@github.com>
 <hfJIZbrr5qSkn0BU1nyriYMyV9cFWN7e1iKHO-bvZks=.a829ef78-fe38-402a-877b-431591d23e15@github.com>
Message-ID: <wukr9CAXv6eg4V1zyaY_u4MQzosphMXOT69KQ5qNpXE=.05e4ce9a-dd12-4e4d-bf78-f188a0386bf9@github.com>

On Tue, 21 Feb 2023 14:22:30 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Eirik Bjorsnos has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove whitespace following '('
>
> src/java.base/share/classes/java/lang/CharacterDataLatin1.java.template line 163:
> 
>> 161:         return mapChar;
>> 162:     }
>> 163:     /**
> 
> I assume you should insert a blank line between the two methods.

This has been fixed now.

-------------

PR: https://git.openjdk.org/jdk/pull/12632

From iklam at openjdk.org  Tue Feb 21 22:31:37 2023
From: iklam at openjdk.org (Ioi Lam)
Date: Tue, 21 Feb 2023 22:31:37 GMT
Subject: RFR: 8302154: Hidden classes created by LambdaMetaFactory can't be
 unloaded [v2]
In-Reply-To: <2nIotFMJtOU6SxkjWHI7_Q-tTVb78xaPACgQMgLFWhY=.2d075f93-bacb-4dfa-86ee-e34d3ff9921a@github.com>
References: <YoZauVv8zvhdUw-LD25LrsMDItFbg3aXPU3deXwwFdQ=.c2839dea-12e5-4e0e-9579-eac9d8503932@github.com>
 <gKoLpwlXDxp2uaSKSkMArJl1Ym9VX1hoDFqQTTUpk8w=.e1dce669-5a42-4b66-ac4b-205718c8eb81@github.com>
 <2nIotFMJtOU6SxkjWHI7_Q-tTVb78xaPACgQMgLFWhY=.2d075f93-bacb-4dfa-86ee-e34d3ff9921a@github.com>
Message-ID: <wNtn8_UTyouc5d4GJC3w5f9PZc_-OVxKWpw2s1Sp5yY=.7fa18e35-61e3-4710-9a67-ed110f384ba6@github.com>

On Tue, 21 Feb 2023 18:39:31 GMT, Volker Simonis <simonis at openjdk.org> wrote:

>> Volker Simonis has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Remove assertions which insist on Lambda proxy classes being strongly linked to their class loader
>>  - Removed unused import of STRONG und updated copyright year
>
> I hear your arguments although I don't agree :)
> 
> Can we at least get consensus on that the current design to create a new ClassLoaderData for each non-strongly linked Hidden Class just in order to enable simple unloading isn't the greatest design and should eventually be replaced by a more sophisticated implementation which allows non-strongly linked Hidden Classes to share a single ClassLoaderData but still enable unloading for them once they aren't referenced any more?

@simonis I want to ask a basic question -- what is the reason for your code to call `LambdaMetafactory.metafactory()` directly? It looks like you want to implement so sort of dynamic dispatch. Can equivalent functionality be implemented by the app itself?

If there's a real need for such a style of programming, and it requires some sort of built-in support in by the JDK, maybe we should have a proper API instead of piggy-backing on `LambdaMetafactory.metafactory()`.

I think if you give us more background, we can make this a more productive discussion than focusing on "did we make the right decision N versions ago" without defining what "right" means :-)

I would suggest re-booting this decision in the mailing lists rather than continuing in this PR.

-------------

PR: https://git.openjdk.org/jdk/pull/12493

From igraves at openjdk.org  Tue Feb 21 22:35:03 2023
From: igraves at openjdk.org (Ian Graves)
Date: Tue, 21 Feb 2023 22:35:03 GMT
Subject: RFR: 8293667: Align jlink's --compress option with jmod's
 --compress option [v10]
In-Reply-To: <JWevwHuR2vF3k-JRxmTAxfNN6g-EBkgG2N9DHn4fkGY=.f9768dfd-cab4-49a9-83b9-d77a1572e917@github.com>
References: <JWevwHuR2vF3k-JRxmTAxfNN6g-EBkgG2N9DHn4fkGY=.f9768dfd-cab4-49a9-83b9-d77a1572e917@github.com>
Message-ID: <az7b-JuJieuzK5ms-BWm4GPTLL9bdDkH9ebH_TwrR9s=.74c0b2a5-b0fb-4b8e-aaa6-2f440584f7a5@github.com>

> This is an approach to adding a flag to jlink that will allow --compress to take the same types of arguments as jmod, thus bringing the two into alignment. This likely requires a CSR and a discussion on whether we should deprecate or simply remove the original numeric compression arguments.

Ian Graves has updated the pull request incrementally with one additional commit since the last revision:

  Updates per feedback

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/11617/files
  - new: https://git.openjdk.org/jdk/pull/11617/files/a9a4d4f0..b2c4457f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11617&range=09
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11617&range=08-09

  Stats: 20 lines in 4 files changed: 9 ins; 0 del; 11 mod
  Patch: https://git.openjdk.org/jdk/pull/11617.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11617/head:pull/11617

PR: https://git.openjdk.org/jdk/pull/11617

From duke at openjdk.org  Tue Feb 21 22:37:57 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Tue, 21 Feb 2023 22:37:57 GMT
Subject: RFR: 8302871: Speed up StringLatin1.regionMatchesCI [v9]
In-Reply-To: <dnsiX3nRffjGjZXJG7lMAZj2FktEl2Wc1XfFthQ4iJs=.8c41438a-80a4-468f-ae0b-7322c9d6d952@github.com>
References: <dnsiX3nRffjGjZXJG7lMAZj2FktEl2Wc1XfFthQ4iJs=.8c41438a-80a4-468f-ae0b-7322c9d6d952@github.com>
Message-ID: <_990kr_t2d7W83RQP9S871Hs-supvu4a8A_LAVmiAyw=.2ed8b149-8628-43a1-8c20-92caca5f2983@github.com>

> This PR suggests we can speed up `StringLatin1.regionMatchesCI` by applying 'the oldest ASCII trick in the book'.
> 
> The new static method `CharacterDataLatin1.equalsIgnoreCase` compares two latin1 bytes for equality ignoring case. `StringLatin1.regionMatchesCI` is updated to use `equalsIgnoreCase`
> 
> To verify the correctness of `equalsIgnoreCase`, a new test is added  to `EqualsIgnoreCase` with an exhaustive verification that all 256x256 latin1 code point pairs have an `equalsIgnoreCase` consistent with Character.toUpperCase, Character.toLowerCase.
> 
> Performance is tested for matching and mismatching cases of code point pairs picked from the ASCII letter, ASCII number and latin1 letter ranges. Results in the first comment below.

Eirik Bjorsnos 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:

 - Rename unconventionally named local variable 'U' to 'upper'
 - Merge remote-tracking branch 'origin/master' into regionmatches-latin1-speedup
 - Add whitespace between methods
 - Merge branch 'master' into regionmatches-latin1-speedup
 - Remove whitespace following '('
 - Revert "Spell fix for 'exhaustive' in comments in sun/text/resources"
   
   This reverts commit 5e9927a4b35e157fd3fa72fd2663c8bfbecf32bb.
 - Spell fix for 'exhaustive' in comments in sun/text/resources
 - Add @bug tag to EqualsIgnoreCase test for correct issue JDK-8302871
 - Add @bug tag to EqualsIgnoreCase test for JDK-8302877
 - Add clarifying comments and use more descriptive variable names in the latin1 verification EqualsIgnoreCase test
 - ... and 5 more: https://git.openjdk.org/jdk/compare/7025e4c5...6588ab0f

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12632/files
  - new: https://git.openjdk.org/jdk/pull/12632/files/718fcead..6588ab0f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12632&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12632&range=07-08

  Stats: 20 lines in 6 files changed: 0 ins; 7 del; 13 mod
  Patch: https://git.openjdk.org/jdk/pull/12632.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12632/head:pull/12632

PR: https://git.openjdk.org/jdk/pull/12632

From darcy at openjdk.org  Tue Feb 21 23:03:04 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 21 Feb 2023 23:03:04 GMT
Subject: RFR: JDK-8302028: Port fdlibm atan2 to Java [v5]
In-Reply-To: <xl79M-V4_2t49GuCudJHQBaJjAcwWl9f2Bv19RbAmdo=.b9c97066-8cf4-4569-8b4b-8b4874e23833@github.com>
References: <xl79M-V4_2t49GuCudJHQBaJjAcwWl9f2Bv19RbAmdo=.b9c97066-8cf4-4569-8b4b-8b4874e23833@github.com>
Message-ID: <BzM7dqT1RGYp6221nMtHQTMMHBAwr_ygCp_tIkITMLg=.318687e1-2f26-49c1-955e-f8b6af177e10@github.com>

> Working down the porting list, next stop, atan2.

Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:

  Respond to review feedback.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12608/files
  - new: https://git.openjdk.org/jdk/pull/12608/files/82790bbb..35c2bfef

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12608&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12608&range=03-04

  Stats: 32 lines in 2 files changed: 8 ins; 0 del; 24 mod
  Patch: https://git.openjdk.org/jdk/pull/12608.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12608/head:pull/12608

PR: https://git.openjdk.org/jdk/pull/12608

From darcy at openjdk.org  Tue Feb 21 23:03:05 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 21 Feb 2023 23:03:05 GMT
Subject: RFR: JDK-8302028: Port fdlibm atan2 to Java [v2]
In-Reply-To: <de6qDGg8k_5fRMfIeec1HAwTCLu430OMQ9Tj23YK2SU=.0c44e378-25f5-496b-a1f0-630e8ef6072a@github.com>
References: <xl79M-V4_2t49GuCudJHQBaJjAcwWl9f2Bv19RbAmdo=.b9c97066-8cf4-4569-8b4b-8b4874e23833@github.com>
 <TMI7ZKI2Qc9DL_wLKNwMXAtu7hstoL-mrZjEIsv-MT0=.dace04d5-ec7e-40c2-b540-4e1f5e68bd38@github.com>
 <FSMfXwXXxe2sBtxB5J641Hh9o8WKPX2k7-n2bpOhrWU=.e8281db1-ecc4-43e0-bbe2-1c419e1111f0@github.com>
 <de6qDGg8k_5fRMfIeec1HAwTCLu430OMQ9Tj23YK2SU=.0c44e378-25f5-496b-a1f0-630e8ef6072a@github.com>
Message-ID: <M-ffLNJx9YWeZzOzrklwpx6r1szurBjxELbYz4jAyfM=.6eb0c25e-c9ef-4d44-b041-42d7ecb5925b@github.com>

On Fri, 17 Feb 2023 19:33:07 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/FdLibm.java line 458:
>> 
>>> 456:                 case 0, 1 ->  y;              // atan(+/-0, +anything)  = +/-0
>>> 457:                 case 2    ->  Math.PI + tiny; // atan(+0,   -anything)  =  pi
>>> 458:                 default   -> -Math.PI - tiny; // atan(-0,   -anything)  = -pi
>> 
>> The original switch statement and this switch expression are semantically equivalent only because of our knowledge that `m` can only assume values 0, 1, 2, or 3. This requires more reasoning than a more verbatim copy of the original statement. Not sure if it is worth.
>> 
>> The same holds for the switch expressions below.
>
> Yes, the use of switch expressions here is certainly not strictly necessary.
> 
> Something that helped convince me it was okay was that the final switch on m in atan2 uses the set of case labels {0, 1, 2, default}., further implying that m can only take on the values {0, 1, 2, 3}.

Reverted to switch statements rather than switch expressions.

-------------

PR: https://git.openjdk.org/jdk/pull/12608

From darcy at openjdk.org  Tue Feb 21 23:03:06 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 21 Feb 2023 23:03:06 GMT
Subject: RFR: JDK-8302028: Port fdlibm atan2 to Java [v2]
In-Reply-To: <FSMfXwXXxe2sBtxB5J641Hh9o8WKPX2k7-n2bpOhrWU=.e8281db1-ecc4-43e0-bbe2-1c419e1111f0@github.com>
References: <xl79M-V4_2t49GuCudJHQBaJjAcwWl9f2Bv19RbAmdo=.b9c97066-8cf4-4569-8b4b-8b4874e23833@github.com>
 <TMI7ZKI2Qc9DL_wLKNwMXAtu7hstoL-mrZjEIsv-MT0=.dace04d5-ec7e-40c2-b540-4e1f5e68bd38@github.com>
 <FSMfXwXXxe2sBtxB5J641Hh9o8WKPX2k7-n2bpOhrWU=.e8281db1-ecc4-43e0-bbe2-1c419e1111f0@github.com>
Message-ID: <IUys-16lOe-7fvVH_1HVhTM8EvtG2OVFWG1bJMz2Jvs=.7dc53301-ef25-4c15-8d63-c2e4248b647f@github.com>

On Fri, 17 Feb 2023 14:18:25 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> Joe Darcy 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:
>> 
>>  - Update regression test.
>>  - Merge branch 'master' into JDK-8302028
>>  - JDK-8302028: Port fdlibm atan2 to Java
>
> test/jdk/java/lang/Math/Atan2Tests.java line 214:
> 
>> 212:             /*
>> 213:              * If both arguments are negative infinity, then the result is the
>> 214:              * double value closest to -3*pi/4.
> 
> Perhaps add a note explaining that high precision computation shows that `-3*PI/4.0` is indeed the `double` closest to -3*pi/4.
> Since `PI` is an approximation in the first place, and since there are other two operations (in particular, the multiplication by 3), the claim is not evident.

Note (and manual double-check) added.

-------------

PR: https://git.openjdk.org/jdk/pull/12608

From martin at openjdk.org  Tue Feb 21 23:22:25 2023
From: martin at openjdk.org (Martin Buchholz)
Date: Tue, 21 Feb 2023 23:22:25 GMT
Subject: RFR: 8302871: Speed up StringLatin1.regionMatchesCI [v7]
In-Reply-To: <bYxNp9wXu0hHmU5U7L0AekEKt2hSBAhwpZbFePTlkRw=.8b96e631-82eb-4190-854a-88f3af25716b@github.com>
References: <dnsiX3nRffjGjZXJG7lMAZj2FktEl2Wc1XfFthQ4iJs=.8c41438a-80a4-468f-ae0b-7322c9d6d952@github.com>
 <AhNijA3f_Yl5Ornr9pqngR3yaepTQNEJeposarKW-Wg=.90a0b345-88dc-4648-a0fb-c83d1dd7e9d5@github.com>
 <hfJIZbrr5qSkn0BU1nyriYMyV9cFWN7e1iKHO-bvZks=.a829ef78-fe38-402a-877b-431591d23e15@github.com>
 <jUSHM1nTkwyjspO5Rn4h-OBQIsE62lvJZK7K-qhq3uI=.94ac5e1c-128e-4991-98d5-c202aa7d0610@github.com>
 <rXD4iIFMdlGyHf7E2a4O2Oz6iQmrItoFdp3pREh8yl0=.c407b886-9646-4a83-94a3-8f738e94ea06@github.com>
 <bYxNp9wXu0hHmU5U7L0AekEKt2hSBAhwpZbFePTlkRw=.8b96e631-82eb-4190-854a-88f3af25716b@github.com>
Message-ID: <d4JliesOUX_SDPQOQrSFc2kaByJfA5vYFK-Sz7ij81Y=.ef887b72-d16b-499d-acca-d513a7ae7c6b@github.com>

On Tue, 21 Feb 2023 20:48:04 GMT, Martin Buchholz <martin at openjdk.org> wrote:

>> Perhaps @Martin-Buchholz could chime in and also tell us which book he found his ASCII trick in :)
>
> "oldest trick in the book" is a phrase that does not necessarily imply existence of an actual book!
> 
> Let this evoke an image of a **personal** book of tricks that programmers in the 1960s might have recorded such techniques in.  And the tricks were passed down across generations of programmers!

More to the point, ASCII was obviously **designed** to allow you to uppercase a lower case letter with a single instruction, so "the book" might have been a draft standard before they scrubbed out the interesting history!

-------------

PR: https://git.openjdk.org/jdk/pull/12632

From duke at openjdk.org  Tue Feb 21 23:31:27 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Tue, 21 Feb 2023 23:31:27 GMT
Subject: RFR: 8302871: Speed up StringLatin1.regionMatchesCI [v7]
In-Reply-To: <d4JliesOUX_SDPQOQrSFc2kaByJfA5vYFK-Sz7ij81Y=.ef887b72-d16b-499d-acca-d513a7ae7c6b@github.com>
References: <dnsiX3nRffjGjZXJG7lMAZj2FktEl2Wc1XfFthQ4iJs=.8c41438a-80a4-468f-ae0b-7322c9d6d952@github.com>
 <AhNijA3f_Yl5Ornr9pqngR3yaepTQNEJeposarKW-Wg=.90a0b345-88dc-4648-a0fb-c83d1dd7e9d5@github.com>
 <hfJIZbrr5qSkn0BU1nyriYMyV9cFWN7e1iKHO-bvZks=.a829ef78-fe38-402a-877b-431591d23e15@github.com>
 <jUSHM1nTkwyjspO5Rn4h-OBQIsE62lvJZK7K-qhq3uI=.94ac5e1c-128e-4991-98d5-c202aa7d0610@github.com>
 <rXD4iIFMdlGyHf7E2a4O2Oz6iQmrItoFdp3pREh8yl0=.c407b886-9646-4a83-94a3-8f738e94ea06@github.com>
 <bYxNp9wXu0hHmU5U7L0AekEKt2hSBAhwpZbFePTlkRw=.8b96e631-82eb-4190-854a-88f3af25716b@github.com>
 <d4JliesOUX_SDPQOQrSFc2kaByJfA5vYFK-Sz7ij81Y=.ef887b72-d16b-499d-acca-d513a7ae7c6b@github.com>
Message-ID: <PGdB8YD1ojFfu7vOE-mVz-HAz4JwKsC0bpw0s5DRXQU=.d048722a-63e8-456c-8d0f-749ed413c521@github.com>

On Tue, 21 Feb 2023 23:20:03 GMT, Martin Buchholz <martin at openjdk.org> wrote:

>> "oldest trick in the book" is a phrase that does not necessarily imply existence of an actual book!
>> 
>> Let this evoke an image of a **personal** book of tricks that programmers in the 1960s might have recorded such techniques in.  And the tricks were passed down across generations of programmers!
>
> More to the point, ASCII was obviously **designed** to allow you to uppercase a lower case letter with a single instruction, so "the book" might have been a draft standard before they scrubbed out the interesting history!

Thanks Martin, I will from now on envision a stack of dusty punch cards with carefully scribbled notes on the back, barely held together with a dry and cracked rubber band.

More to the point: Do you have an opinion on the appropriate level of documentation / comments for this kind of 'tricky' code? My goal is that future maintainers should not get scared by the code and help them understand why it became what it is.

-------------

PR: https://git.openjdk.org/jdk/pull/12632

From duke at openjdk.org  Tue Feb 21 23:33:29 2023
From: duke at openjdk.org (Ravali Yatham)
Date: Tue, 21 Feb 2023 23:33:29 GMT
Subject: RFR: 8302791: Add specific ClassLoader object to Proxy
 IllegalArgumentException message
Message-ID: <O5sadWrVYh2fiWVEDQLWPnBPMH73RNHmN4ifU7h4a4k=.490377ab-f81b-4a21-8017-2bc002b0ccc8@github.com>

Added specific class loader object to proxy IllegalArgumentException from which the class was not visible

The bug report for the same: https://bugs.openjdk.org/browse/JDK-8302791

-------------

Commit messages:
 - Added specific ClassLoader object to Proxy IllegalArgumentException

Changes: https://git.openjdk.org/jdk/pull/12641/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12641&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8302791
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/12641.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12641/head:pull/12641

PR: https://git.openjdk.org/jdk/pull/12641

From duke at openjdk.org  Tue Feb 21 23:33:30 2023
From: duke at openjdk.org (Ravali Yatham)
Date: Tue, 21 Feb 2023 23:33:30 GMT
Subject: RFR: 8302791: Add specific ClassLoader object to Proxy
 IllegalArgumentException message
In-Reply-To: <O5sadWrVYh2fiWVEDQLWPnBPMH73RNHmN4ifU7h4a4k=.490377ab-f81b-4a21-8017-2bc002b0ccc8@github.com>
References: <O5sadWrVYh2fiWVEDQLWPnBPMH73RNHmN4ifU7h4a4k=.490377ab-f81b-4a21-8017-2bc002b0ccc8@github.com>
Message-ID: <css7H7VWZ_SIX6T3xzxaO6jiQl8MMDoa-r7q_XGsl2g=.f64f3757-04c4-4d38-96df-3edcdeb0184d@github.com>

On Sun, 19 Feb 2023 08:28:37 GMT, Ravali Yatham <duke at openjdk.org> wrote:

> Added specific class loader object to proxy IllegalArgumentException from which the class was not visible
> 
> The bug report for the same: https://bugs.openjdk.org/browse/JDK-8302791

This contribution is on behalf of my employer, IBM, which is a corporate OCA signatory.

-------------

PR: https://git.openjdk.org/jdk/pull/12641

From duke at openjdk.org  Tue Feb 21 23:33:32 2023
From: duke at openjdk.org (liach)
Date: Tue, 21 Feb 2023 23:33:32 GMT
Subject: RFR: 8302791: Add specific ClassLoader object to Proxy
 IllegalArgumentException message
In-Reply-To: <O5sadWrVYh2fiWVEDQLWPnBPMH73RNHmN4ifU7h4a4k=.490377ab-f81b-4a21-8017-2bc002b0ccc8@github.com>
References: <O5sadWrVYh2fiWVEDQLWPnBPMH73RNHmN4ifU7h4a4k=.490377ab-f81b-4a21-8017-2bc002b0ccc8@github.com>
Message-ID: <XNApj1IhjSCFEUSYMpP6wV5AF9Ve01a8hzIaQN2-MS0=.6105b0b4-b07e-42c7-8484-60d533d9f93e@github.com>

On Sun, 19 Feb 2023 08:28:37 GMT, Ravali Yatham <duke at openjdk.org> wrote:

> Added specific class loader object to proxy IllegalArgumentException from which the class was not visible
> 
> The bug report for the same: https://bugs.openjdk.org/browse/JDK-8302791

src/java.base/share/classes/java/lang/reflect/Proxy.java line 881:

> 879:             if (type != c) {
> 880:                 throw new IllegalArgumentException(c.getName() +
> 881:                         " referenced from a method is not visible from class loader: " + ld.toString());

Isn't the `.toString()` call redundant in string concatenation?

-------------

PR: https://git.openjdk.org/jdk/pull/12641

From duke at openjdk.org  Tue Feb 21 23:33:32 2023
From: duke at openjdk.org (Ravali Yatham)
Date: Tue, 21 Feb 2023 23:33:32 GMT
Subject: RFR: 8302791: Add specific ClassLoader object to Proxy
 IllegalArgumentException message
In-Reply-To: <XNApj1IhjSCFEUSYMpP6wV5AF9Ve01a8hzIaQN2-MS0=.6105b0b4-b07e-42c7-8484-60d533d9f93e@github.com>
References: <O5sadWrVYh2fiWVEDQLWPnBPMH73RNHmN4ifU7h4a4k=.490377ab-f81b-4a21-8017-2bc002b0ccc8@github.com>
 <XNApj1IhjSCFEUSYMpP6wV5AF9Ve01a8hzIaQN2-MS0=.6105b0b4-b07e-42c7-8484-60d533d9f93e@github.com>
Message-ID: <heAVIlnJu4iyf6ZXcUYDb6Bm16rDB-LXaztYs19dyMY=.6d508e1e-6ae1-471e-849e-a58e24fef395@github.com>

On Sun, 19 Feb 2023 16:12:39 GMT, liach <duke at openjdk.org> wrote:

>> Added specific class loader object to proxy IllegalArgumentException from which the class was not visible
>> 
>> The bug report for the same: https://bugs.openjdk.org/browse/JDK-8302791
>
> src/java.base/share/classes/java/lang/reflect/Proxy.java line 881:
> 
>> 879:             if (type != c) {
>> 880:                 throw new IllegalArgumentException(c.getName() +
>> 881:                         " referenced from a method is not visible from class loader: " + ld.toString());
> 
> Isn't the `.toString()` call redundant in string concatenation?

Thanks @liach for reviewing, Fixed this.

-------------

PR: https://git.openjdk.org/jdk/pull/12641

From dholmes at openjdk.org  Tue Feb 21 23:47:29 2023
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 21 Feb 2023 23:47:29 GMT
Subject: RFR: 8302154: Hidden classes created by LambdaMetaFactory can't be
 unloaded [v2]
In-Reply-To: <gKoLpwlXDxp2uaSKSkMArJl1Ym9VX1hoDFqQTTUpk8w=.e1dce669-5a42-4b66-ac4b-205718c8eb81@github.com>
References: <YoZauVv8zvhdUw-LD25LrsMDItFbg3aXPU3deXwwFdQ=.c2839dea-12e5-4e0e-9579-eac9d8503932@github.com>
 <gKoLpwlXDxp2uaSKSkMArJl1Ym9VX1hoDFqQTTUpk8w=.e1dce669-5a42-4b66-ac4b-205718c8eb81@github.com>
Message-ID: <jMP3m1mHlnWg40SZD-k2pQmeTLEBMfEO5xKZa7B66Go=.ceb6545e-bb8f-4d19-986b-1202279c74da@github.com>

On Thu, 9 Feb 2023 18:11:18 GMT, Volker Simonis <simonis at openjdk.org> wrote:

>> Prior to [JDK-8239384](https://bugs.openjdk.org/browse/JDK-8239384)/[JDK-8238358](https://bugs.openjdk.org/browse/JDK-8238358) LambdaMetaFactory has created VM-anonymous classes which could easily be unloaded once they were not referenced any more. Starting with JDK 15 and the new "hidden class" based implementation, this is not the case any more, because the hidden classes will be strongly tied to their defining class loader. If this is the default application class loader, these hidden classes can never be unloaded which can easily lead to Metaspace exhaustion (see the [test case in the JBS issue](https://bugs.openjdk.org/secure/attachment/102601/LambdaClassLeak.java)). This is a regression compared to previous JDK versions which some of our applications have been affected from when migrating to JDK 17.
>> 
>> The reason why the newly created hidden classes are strongly linked to their defining class loader is not clear to me. JDK-8239384 mentions it as an "implementation detail":
>> 
>>> *4. the lambda proxy class has the strong relationship with the class loader (that will share the VM metaspace for its defining loader - implementation details)*
>> 
>> From my current understanding the strong link between a hidden class created by `LambdaMetaFactory` and its defining class loader is not strictly required. In order to prevent potential OOMs and fix the regression compared the JDK 14 and earlier I propose to create these hidden classes without the `STRONG` option.
>> 
>> I'll be happy to add the test case as JTreg test to this PR if you think that would be useful.
>
> Volker Simonis has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Remove assertions which insist on Lambda proxy classes being strongly linked to their class loader
>  - Removed unused import of STRONG und updated copyright year

I also have to disagree with the statement. The unit of unloading is the ClassLoader.

-------------

PR: https://git.openjdk.org/jdk/pull/12493

From dholmes at openjdk.org  Wed Feb 22 00:09:29 2023
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 22 Feb 2023 00:09:29 GMT
Subject: RFR: 8302871: Speed up StringLatin1.regionMatchesCI [v7]
In-Reply-To: <PGdB8YD1ojFfu7vOE-mVz-HAz4JwKsC0bpw0s5DRXQU=.d048722a-63e8-456c-8d0f-749ed413c521@github.com>
References: <dnsiX3nRffjGjZXJG7lMAZj2FktEl2Wc1XfFthQ4iJs=.8c41438a-80a4-468f-ae0b-7322c9d6d952@github.com>
 <AhNijA3f_Yl5Ornr9pqngR3yaepTQNEJeposarKW-Wg=.90a0b345-88dc-4648-a0fb-c83d1dd7e9d5@github.com>
 <hfJIZbrr5qSkn0BU1nyriYMyV9cFWN7e1iKHO-bvZks=.a829ef78-fe38-402a-877b-431591d23e15@github.com>
 <jUSHM1nTkwyjspO5Rn4h-OBQIsE62lvJZK7K-qhq3uI=.94ac5e1c-128e-4991-98d5-c202aa7d0610@github.com>
 <rXD4iIFMdlGyHf7E2a4O2Oz6iQmrItoFdp3pREh8yl0=.c407b886-9646-4a83-94a3-8f738e94ea06@github.com>
 <bYxNp9wXu0hHmU5U7L0AekEKt2hSBAhwpZbFePTlkRw=.8b96e631-82eb-4190-854a-88f3af25716b@github.com>
 <d4JliesOUX_SDPQOQrSFc2kaByJfA5vYFK-Sz7ij81Y=.ef887b72-d16b-499d-acca-d513a7ae7c6b@github.com>
 <PGdB8YD1ojFfu7vOE-mVz-HAz4JwKsC0bpw0s5DRXQU=.d048722a-63e8-456c-8d0f-749ed413c521@github.com>
Message-ID: <JixGIkrtsQX2nya-qbWLfVf_MHOqWofpAsPcHCkpqRo=.842dafa9-84f2-49f2-8f71-f1a80b558a19@github.com>

On Tue, 21 Feb 2023 23:28:52 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

>> More to the point, ASCII was obviously **designed** to allow you to uppercase a lower case letter with a single instruction, so "the book" might have been a draft standard before they scrubbed out the interesting history!
>
> Thanks Martin, I will from now on envision a stack of dusty punch cards with carefully scribbled notes on the back, barely held together with a dry and cracked rubber band.
> 
> More to the point: Do you have an opinion on the appropriate level of documentation / comments for this kind of 'tricky' code? My goal is that future maintainers should not get scared by the code and help them understand why it became what it is.

There are still some books on this :) but from wikipedia:
> during May 1963 the CCITT Working Party on the New Telegraph Alphabet proposed to assign lowercase characters to sticks[[a]](https://en.wikipedia.org/wiki/ASCII#cite_note-NB_Stick-15)[[14]](https://en.wikipedia.org/wiki/ASCII#cite_note-Bemer_1980_Inside-14) 6 and 7,[[15]](https://en.wikipedia.org/wiki/ASCII#cite_note-CCITT_1963-16) and [International Organization for Standardization](https://en.wikipedia.org/wiki/International_Organization_for_Standardization) TC 97 SC 2 voted during October to incorporate the change into its draft standard.[[16]](https://en.wikipedia.org/wiki/ASCII#cite_note-ISO_1963-17) The X3.2.4 task group voted its approval for the change to ASCII at its May 1963 meeting.[[17]](https://en.wikipedia.org/wiki/ASCII#cite_note-18) **Locating the lowercase letters in sticks[[a]](https://en.wikipedia.org/wiki/ASCII#cite_note-NB_Stick-15)[[14]](https://en.wikipedia.org/wiki/ASCII#cite_note-Bemer_1980_Inside-14) 6 and 7 caused the characters to differ in bit pattern f
 rom the upper case by a single bit, which simplified [case-insensitive](https://en.wikipedia.org/wiki/Case-insensitive) character matching and the construction of keyboards and printers.**

Hence the simplicity of the shift key :)

-------------

PR: https://git.openjdk.org/jdk/pull/12632

From martin at openjdk.org  Wed Feb 22 00:48:33 2023
From: martin at openjdk.org (Martin Buchholz)
Date: Wed, 22 Feb 2023 00:48:33 GMT
Subject: RFR: 8302871: Speed up StringLatin1.regionMatchesCI [v7]
In-Reply-To: <JixGIkrtsQX2nya-qbWLfVf_MHOqWofpAsPcHCkpqRo=.842dafa9-84f2-49f2-8f71-f1a80b558a19@github.com>
References: <dnsiX3nRffjGjZXJG7lMAZj2FktEl2Wc1XfFthQ4iJs=.8c41438a-80a4-468f-ae0b-7322c9d6d952@github.com>
 <AhNijA3f_Yl5Ornr9pqngR3yaepTQNEJeposarKW-Wg=.90a0b345-88dc-4648-a0fb-c83d1dd7e9d5@github.com>
 <hfJIZbrr5qSkn0BU1nyriYMyV9cFWN7e1iKHO-bvZks=.a829ef78-fe38-402a-877b-431591d23e15@github.com>
 <jUSHM1nTkwyjspO5Rn4h-OBQIsE62lvJZK7K-qhq3uI=.94ac5e1c-128e-4991-98d5-c202aa7d0610@github.com>
 <rXD4iIFMdlGyHf7E2a4O2Oz6iQmrItoFdp3pREh8yl0=.c407b886-9646-4a83-94a3-8f738e94ea06@github.com>
 <bYxNp9wXu0hHmU5U7L0AekEKt2hSBAhwpZbFePTlkRw=.8b96e631-82eb-4190-854a-88f3af25716b@github.com>
 <d4JliesOUX_SDPQOQrSFc2kaByJfA5vYFK-Sz7ij81Y=.ef887b72-d16b-499d-acca-d513a7ae7c6b@github.com>
 <PGdB8YD1ojFfu7vOE-mVz-HAz4JwKsC0bpw0s5DRXQU=.d048722a-63e8-456c-8d0f-749ed413c521@github.com>
 <JixGIkrtsQX2nya-qbWLfVf_MHOqWofpAsPcHCkpqRo=.842dafa9-84f2-49f2-8f71-f1a80b558a19@github.com>
Message-ID: <f5OUHqyQBUqHQ4NJNK5tRyliXk7XoDMJEaevQvvwbtk=.dd9dd461-69e2-4153-a225-d20482277cd6@github.com>

On Wed, 22 Feb 2023 00:06:51 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Thanks Martin, I will from now on envision a stack of dusty punch cards with carefully scribbled notes on the back, barely held together with a dry and cracked rubber band.
>> 
>> More to the point: Do you have an opinion on the appropriate level of documentation / comments for this kind of 'tricky' code? My goal is that future maintainers should not get scared by the code and help them understand why it became what it is.
>
> There are still some books on this :) but from wikipedia:
>> during May 1963 the CCITT Working Party on the New Telegraph Alphabet proposed to assign lowercase characters to sticks[[a]](https://en.wikipedia.org/wiki/ASCII#cite_note-NB_Stick-15)[[14]](https://en.wikipedia.org/wiki/ASCII#cite_note-Bemer_1980_Inside-14) 6 and 7,[[15]](https://en.wikipedia.org/wiki/ASCII#cite_note-CCITT_1963-16) and [International Organization for Standardization](https://en.wikipedia.org/wiki/International_Organization_for_Standardization) TC 97 SC 2 voted during October to incorporate the change into its draft standard.[[16]](https://en.wikipedia.org/wiki/ASCII#cite_note-ISO_1963-17) The X3.2.4 task group voted its approval for the change to ASCII at its May 1963 meeting.[[17]](https://en.wikipedia.org/wiki/ASCII#cite_note-18) **Locating the lowercase letters in sticks[[a]](https://en.wikipedia.org/wiki/ASCII#cite_note-NB_Stick-15)[[14]](https://en.wikipedia.org/wiki/ASCII#cite_note-Bemer_1980_Inside-14) 6 and 7 caused the characters to differ in bit pattern 
 from the upper case by a single bit, which simplified [case-insensitive](https://en.wikipedia.org/wiki/Case-insensitive) character matching and the construction of keyboards and printers.**
> 
> Hence the simplicity of the shift key :)

More history: IIRC I originally used 'ASCII trick' when I was truly only cared about ASCII, not Latin1 (e.g. ZipFile.isMetaName) and it's a slight misnomer to use "ASCII" here.  But Latin1 followed the precedent of ASCII.

-------------

PR: https://git.openjdk.org/jdk/pull/12632

From martin at openjdk.org  Wed Feb 22 00:53:35 2023
From: martin at openjdk.org (Martin Buchholz)
Date: Wed, 22 Feb 2023 00:53:35 GMT
Subject: RFR: 8302871: Speed up StringLatin1.regionMatchesCI [v7]
In-Reply-To: <f5OUHqyQBUqHQ4NJNK5tRyliXk7XoDMJEaevQvvwbtk=.dd9dd461-69e2-4153-a225-d20482277cd6@github.com>
References: <dnsiX3nRffjGjZXJG7lMAZj2FktEl2Wc1XfFthQ4iJs=.8c41438a-80a4-468f-ae0b-7322c9d6d952@github.com>
 <AhNijA3f_Yl5Ornr9pqngR3yaepTQNEJeposarKW-Wg=.90a0b345-88dc-4648-a0fb-c83d1dd7e9d5@github.com>
 <hfJIZbrr5qSkn0BU1nyriYMyV9cFWN7e1iKHO-bvZks=.a829ef78-fe38-402a-877b-431591d23e15@github.com>
 <jUSHM1nTkwyjspO5Rn4h-OBQIsE62lvJZK7K-qhq3uI=.94ac5e1c-128e-4991-98d5-c202aa7d0610@github.com>
 <rXD4iIFMdlGyHf7E2a4O2Oz6iQmrItoFdp3pREh8yl0=.c407b886-9646-4a83-94a3-8f738e94ea06@github.com>
 <bYxNp9wXu0hHmU5U7L0AekEKt2hSBAhwpZbFePTlkRw=.8b96e631-82eb-4190-854a-88f3af25716b@github.com>
 <d4JliesOUX_SDPQOQrSFc2kaByJfA5vYFK-Sz7ij81Y=.ef887b72-d16b-499d-acca-d513a7ae7c6b@github.com>
 <PGdB8YD1ojFfu7vOE-mVz-HAz4JwKsC0bpw0s5DRXQU=.d048722a-63e8-456c-8d0f-749ed413c521@github.com>
 <JixGIkrtsQX2nya-qbWLfVf_MHOqWofpAsPcHCkpqRo=.842dafa9-84f2-49f2-8f71-f1a80b558a19@github.com>
 <f5OUHqyQBUqHQ4NJNK5tRyliXk7XoDMJEaevQvvwbtk=.dd9dd461-69e2-4153-a225-d20482277cd6@github.com>
Message-ID: <wlKduCbkD5AhEIrqz_e-LlUM6ImLx8C1V7HXlm86zDE=.6d3574c3-b738-4084-87cc-a5e578ab6144@github.com>

On Wed, 22 Feb 2023 00:45:52 GMT, Martin Buchholz <martin at openjdk.org> wrote:

>> There are still some books on this :) but from wikipedia:
>>> during May 1963 the CCITT Working Party on the New Telegraph Alphabet proposed to assign lowercase characters to sticks[[a]](https://en.wikipedia.org/wiki/ASCII#cite_note-NB_Stick-15)[[14]](https://en.wikipedia.org/wiki/ASCII#cite_note-Bemer_1980_Inside-14) 6 and 7,[[15]](https://en.wikipedia.org/wiki/ASCII#cite_note-CCITT_1963-16) and [International Organization for Standardization](https://en.wikipedia.org/wiki/International_Organization_for_Standardization) TC 97 SC 2 voted during October to incorporate the change into its draft standard.[[16]](https://en.wikipedia.org/wiki/ASCII#cite_note-ISO_1963-17) The X3.2.4 task group voted its approval for the change to ASCII at its May 1963 meeting.[[17]](https://en.wikipedia.org/wiki/ASCII#cite_note-18) **Locating the lowercase letters in sticks[[a]](https://en.wikipedia.org/wiki/ASCII#cite_note-NB_Stick-15)[[14]](https://en.wikipedia.org/wiki/ASCII#cite_note-Bemer_1980_Inside-14) 6 and 7 caused the characters to differ in bit pattern
  from the upper case by a single bit, which simplified [case-insensitive](https://en.wikipedia.org/wiki/Case-insensitive) character matching and the construction of keyboards and printers.**
>> 
>> Hence the simplicity of the shift key :)
>
> More history: IIRC I originally used 'ASCII trick' when I was truly only cared about ASCII, not Latin1 (e.g. ZipFile.isMetaName) and it's a slight misnomer to use "ASCII" here.  But Latin1 followed the precedent of ASCII.

> Do you have an opinion on the appropriate level of documentation / comments for this kind of 'tricky' code? 

This code is not that tricky!  And the proposed level of documentation is excessive!  A couple of lines of explanation and perhaps a link to an external document would be good.

It often happens to me that I will write such exhaustive notes for myself when learning a new technology.  A year later I pare it all back because much of it is "obvious in retrospect".

-------------

PR: https://git.openjdk.org/jdk/pull/12632

From sviswanathan at openjdk.org  Wed Feb 22 02:20:00 2023
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Wed, 22 Feb 2023 02:20:00 GMT
Subject: RFR: 8302976: C2 intrinsification of Float.floatToFloat16 and
 Float.float16ToFloat yields different result than the interpreter
Message-ID: <f18TfSibBBm5FLon1VlUN0m6fNUzvOpsUeo7nEAk7JY=.456ddc51-7be7-4484-ad38-1039453b83d6@github.com>

Change the java/lang/float.java and the corresponding shared runtime constant expression evaluation to generate QNaN.
The HW instructions generate QNaNs and not SNaNs for floating point instructions. This happens across double, float, and float16 data types. The most significant bit of mantissa is set to 1 for QNaNs.

-------------

Commit messages:
 - 8302976: C2 intrinsification of Float.floatToFloat16 and Float.float16ToFloat yields different result than the interpreter

Changes: https://git.openjdk.org/jdk/pull/12704/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12704&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8302976
  Stats: 8 lines in 4 files changed: 4 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/12704.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12704/head:pull/12704

PR: https://git.openjdk.org/jdk/pull/12704

From kvn at openjdk.org  Wed Feb 22 02:46:25 2023
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Wed, 22 Feb 2023 02:46:25 GMT
Subject: RFR: 8302976: C2 intrinsification of Float.floatToFloat16 and
 Float.float16ToFloat yields different result than the interpreter
In-Reply-To: <f18TfSibBBm5FLon1VlUN0m6fNUzvOpsUeo7nEAk7JY=.456ddc51-7be7-4484-ad38-1039453b83d6@github.com>
References: <f18TfSibBBm5FLon1VlUN0m6fNUzvOpsUeo7nEAk7JY=.456ddc51-7be7-4484-ad38-1039453b83d6@github.com>
Message-ID: <5DOvibCAPEcdToBLe4Fz_DHNPlsmsmvNAVoKdSsCl7Q=.0aaea866-23ef-4349-ab8c-5fed87e83961@github.com>

On Wed, 22 Feb 2023 02:08:27 GMT, Sandhya Viswanathan <sviswanathan at openjdk.org> wrote:

> Change the java/lang/float.java and the corresponding shared runtime constant expression evaluation to generate QNaN.
> The HW instructions generate QNaNs and not SNaNs for floating point instructions. This happens across double, float, and float16 data types. The most significant bit of mantissa is set to 1 for QNaNs.

Please add regression test.
Also consider creating copies of jdk/java/lang/Float/Binary16Conversion*.java tests in compiler/intrinsics/ and modify them to compare results from Interpreter, runtime and JITed code.

We run compiler/intrinsics/ tests with different SSE and AVX settings to make sure they work in all cases.

-------------

Changes requested by kvn (Reviewer).

PR: https://git.openjdk.org/jdk/pull/12704

From darcy at openjdk.org  Wed Feb 22 03:49:25 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 22 Feb 2023 03:49:25 GMT
Subject: RFR: 8302976: C2 intrinsification of Float.floatToFloat16 and
 Float.float16ToFloat yields different result than the interpreter
In-Reply-To: <f18TfSibBBm5FLon1VlUN0m6fNUzvOpsUeo7nEAk7JY=.456ddc51-7be7-4484-ad38-1039453b83d6@github.com>
References: <f18TfSibBBm5FLon1VlUN0m6fNUzvOpsUeo7nEAk7JY=.456ddc51-7be7-4484-ad38-1039453b83d6@github.com>
Message-ID: <JEgFEsIccl57zXVuY7fdLmASDsTPDBlU-gME9nIjZ8E=.0c61961b-2246-449e-811e-d78c912efade@github.com>

On Wed, 22 Feb 2023 02:08:27 GMT, Sandhya Viswanathan <sviswanathan at openjdk.org> wrote:

> Change the java/lang/float.java and the corresponding shared runtime constant expression evaluation to generate QNaN.
> The HW instructions generate QNaNs and not SNaNs for floating point instructions. This happens across double, float, and float16 data types. The most significant bit of mantissa is set to 1 for QNaNs.

I'd like to see a more informative description of the problem:

"float16 NaN values handled differently with and without intrinsification"

 If that is issue reported, it may not be a problem as opposed to

"incorrect value returned under Float.float16ToFloat intrinsification", etc.

src/java.base/share/classes/java/lang/Float.java line 1101:

> 1099:             return (short)(sign_bit
> 1100:                     | 0x7c00 // max exponent + 1
> 1101:                     | 0x0200 // QNaN

I don't understand what is being done here. From IEEE 754-2019:

"Besides issues such as byte order which affect all data
interchange, certain implementation options allowed by this standard must also be considered:
? for binary formats, how signaling NaNs are distinguished from quiet NaNs
? for decimal formats, whether binary or decimal encoding is used.
This standard does not define how these parameters are to be communicated."

The code in java.lang.Float in particular is meant to be usable on all host CPUs so architecture-specific assumptions about QNAN vs SNAN should be avoided.

-------------

PR: https://git.openjdk.org/jdk/pull/12704

From darcy at openjdk.org  Wed Feb 22 04:05:27 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 22 Feb 2023 04:05:27 GMT
Subject: RFR: 8302976: C2 intrinsification of Float.floatToFloat16 and
 Float.float16ToFloat yields different result than the interpreter
In-Reply-To: <JEgFEsIccl57zXVuY7fdLmASDsTPDBlU-gME9nIjZ8E=.0c61961b-2246-449e-811e-d78c912efade@github.com>
References: <f18TfSibBBm5FLon1VlUN0m6fNUzvOpsUeo7nEAk7JY=.456ddc51-7be7-4484-ad38-1039453b83d6@github.com>
 <JEgFEsIccl57zXVuY7fdLmASDsTPDBlU-gME9nIjZ8E=.0c61961b-2246-449e-811e-d78c912efade@github.com>
Message-ID: <EInxmBVrftoRYR8Dx5B-O94J6zu2M89QaPFK2TNQGoY=.0fa8c3cb-7f4e-462b-8522-3bcf3adb647a@github.com>

On Wed, 22 Feb 2023 03:46:42 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> I'd like to see a more informative description of the problem:
> 
> "float16 NaN values handled differently with and without intrinsification"
> 
> If that is issue reported, it may not be a problem as opposed to
> 
> "incorrect value returned under Float.float16ToFloat intrinsification", etc.

PS The detailed NaN handling is specifically done in a separate test file since the invariants that are true for the software implementation need not be true for a intrinsified hardware-based one.

However, as done for the intrinsics of the transcendental methods (sin, cos, tan), if the float16 conversion intrinsics are used, they should be consistently used or not used regardless of compilation approach (interpreter, C1, C2, etc.).

HTH

-------------

PR: https://git.openjdk.org/jdk/pull/12704

From dholmes at openjdk.org  Wed Feb 22 04:05:30 2023
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 22 Feb 2023 04:05:30 GMT
Subject: RFR: 8302976: C2 intrinsification of Float.floatToFloat16 and
 Float.float16ToFloat yields different result than the interpreter
In-Reply-To: <f18TfSibBBm5FLon1VlUN0m6fNUzvOpsUeo7nEAk7JY=.456ddc51-7be7-4484-ad38-1039453b83d6@github.com>
References: <f18TfSibBBm5FLon1VlUN0m6fNUzvOpsUeo7nEAk7JY=.456ddc51-7be7-4484-ad38-1039453b83d6@github.com>
Message-ID: <nzUBOq3a8MVvd4EmIiPb95fr3JwBnUi1f1SGxWT2UBw=.d715b6e1-aba5-4448-be15-0cb418cc1084@github.com>

On Wed, 22 Feb 2023 02:08:27 GMT, Sandhya Viswanathan <sviswanathan at openjdk.org> wrote:

> Change the java/lang/float.java and the corresponding shared runtime constant expression evaluation to generate QNaN.
> The HW instructions generate QNaNs and not SNaNs for floating point instructions. This happens across double, float, and float16 data types. The most significant bit of mantissa is set to 1 for QNaNs.

I'm also a bit concerned that we are rushing in to "fix" this. IIUC we have three mechanisms for implementing this functionality:

1. The interpreted Java code
2. The compiled non-intrinisc sharedRuntime code
3. The compiler intrinsic that uses a hardware instruction.

Unless the hardware instructions for all relevant CPUs behave exactly the same, then I don't see how we can have parity of behaviour across these three mechanisms.

The observed behaviour may be surprising but it seems not to be a bug. And is this even a real concern - would real programs actually need to peek at the raw bits and so see the difference, or does it suffice to handle Nan's opaquely?

-------------

PR: https://git.openjdk.org/jdk/pull/12704

From darcy at openjdk.org  Wed Feb 22 05:24:29 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 22 Feb 2023 05:24:29 GMT
Subject: RFR: 8302976: C2 intrinsification of Float.floatToFloat16 and
 Float.float16ToFloat yields different result than the interpreter
In-Reply-To: <nzUBOq3a8MVvd4EmIiPb95fr3JwBnUi1f1SGxWT2UBw=.d715b6e1-aba5-4448-be15-0cb418cc1084@github.com>
References: <f18TfSibBBm5FLon1VlUN0m6fNUzvOpsUeo7nEAk7JY=.456ddc51-7be7-4484-ad38-1039453b83d6@github.com>
 <nzUBOq3a8MVvd4EmIiPb95fr3JwBnUi1f1SGxWT2UBw=.d715b6e1-aba5-4448-be15-0cb418cc1084@github.com>
Message-ID: <u4CPxJRd0uJKQf32who9UTr9fPfJWVetIzM8X4OnhCQ=.4f4fdf86-d260-4c13-bbc6-2a198d322994@github.com>

On Wed, 22 Feb 2023 04:03:02 GMT, David Holmes <dholmes at openjdk.org> wrote:

> I'm also a bit concerned that we are rushing in to "fix" this. IIUC we have three mechanisms for implementing this functionality:
> 
>     1. The interpreted Java code
> 
>     2. The compiled non-intrinisc sharedRuntime code
> 
>     3. The compiler intrinsic that uses a hardware instruction.
> 
> 
> Unless the hardware instructions for all relevant CPUs behave exactly the same, then I don't see how we can have parity of behaviour across these three mechanisms.
> 
> The observed behaviour may be surprising but it seems not to be a bug. And is this even a real concern - would real programs actually need to peek at the raw bits and so see the difference, or does it suffice to handle Nan's opaquely?

>From the spec (https://download.java.net/java/early_access/jdk20/docs/api/java.base/java/lang/Float.html#float16ToFloat(short))

"Returns the float value closest to the numerical value of the argument, a floating-point binary16 value encoded in a short. The conversion is exact; all binary16 values can be exactly represented in float. Special cases:

    If the argument is zero, the result is a zero with the same sign as the argument.
    If the argument is infinite, the result is an infinity with the same sign as the argument.
    If the argument is a NaN, the result is a NaN. "

If the float argument is a NaN, you are supposed to get a float16 NaN as a result -- that is all the specification requires. However, the implementation makes stronger guarantees to try to preserve some non-zero NaN significand bits if they are set.

"NaN boxing" is a technique used to put extra information into the significand bits a NaN and pass the around. It is consistent with the intended use of the feature by IEEE 754 and used in various language runtimes: e.g.,

https://piotrduperas.com/posts/nan-boxing
https://leonardschuetz.ch/blog/nan-boxing/ 
https://anniecherkaev.com/the-secret-life-of-nan

The Java specs are careful to avoid mentioning quiet vs signaling NaNs in general discussion.

That said, I think it is reasonable on a given JVM invocation if Float.floatToFloat16(f) gave the same result for input f regardless of in what context it was called.

-------------

PR: https://git.openjdk.org/jdk/pull/12704

From duke at openjdk.org  Wed Feb 22 05:29:28 2023
From: duke at openjdk.org (Amit Kumar)
Date: Wed, 22 Feb 2023 05:29:28 GMT
Subject: RFR: 8299748: java/util/zip/Deinflate.java failing on s390x
In-Reply-To: <gc-FYHxnm-Hn03BxLM-BrP6ZbmIQlfSkhirFoJwz2q0=.da433d42-c36f-413f-ba1e-e00e4bfd2fb3@github.com>
References: <Usxi4wE5GSHHv-cKPfW6OXylhieAypbsidUX_Jo6FSQ=.34104cf0-2243-478f-86ce-9a91905c6755@github.com>
 <nN80i01pPGVl8QlQ09eEEEeFTz5z2hpM6udh2bNJwpU=.925ff5c6-586b-4262-bcd0-fd67d44cfde2@github.com>
 <jyL7HTlmcVxDKffdPqij6GNM0ePfzVxlypfy3hTtOAM=.3347a8dd-4722-4b79-b93e-b20892901c6b@github.com>
 <2eqxeIzcejWahzfAMe-czlbIQ96bV8s_RIkXQsXMtsY=.b329489c-40fc-4e91-9e30-10a3df53711e@github.com>
 <p1li8W4D2kYNZlxTOyvlqVrZWOjGbh6g1JfG6eHxAmE=.389b076c-0943-4cfd-af82-f24a56d1ac61@github.com>
 <mViUt9K-2zX1iclGWss9oGHP1HM3Xigq3ZAI-ZYV9Ww=.851a49c3-c57c-46d7-9b6b-db5ffda2daf1@github.com>
 <_SfmRrzgThXEqx714Hx-z6hyhJedR_j3KqryCcZ7Ks8=.1b7b7dc6-927e-42ce-b659-23c5c9f603c0@github.com>
 <qwjoHqgbDmbLmBVNyUmOUPlt7MQzSNnD8FBEYTMhgNg=.2a376dd3-9192-4acb-b3e3-f470991706eb@github.com>
 <_Q8SmfDM6g63NP7vBn9As_n_X6ejp_W08o9lbmlUq3I=.0967d833-b2a0-498b-ba44-22be4ecd95ff@github.com>
 <gc-FYHxnm-Hn03BxLM-BrP6ZbmIQlfSkhirFoJwz2q0=.da433d42-c36f-413f-ba1e-e00e4bfd2fb3@github.com>
Message-ID: <tJ3oPAL8fMrmUligcHTjOQcbbdCOASVlasop8sNfYzU=.d9d04030-dfc7-4e7b-9e72-02d3ea8cf521@github.com>

On Fri, 17 Feb 2023 09:01:23 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>maybe change the loop to only test levels 0-9 and see if it passes?

`initial size: 525312`

error I'm facing is on level 1 not on -1.


level:1, strategy: 0, dowrap: false
  required size: 553018  <- there is an issue
  required size: 283432
  required size: 526225  <- there is an issue
  required size: 301127
  required size: 409196
level:1, strategy: 0, dowrap: true
  required size: 553012  <- there is an issue
  required size: 44541
  required size: 414324
  required size: 289230
  required size: 176785


this is result for executing test case 2nd time:


level:1, strategy: 0, dowrap: false
  required size: 552979  <- there is an issue
  required size: 549979  <- there is an issue
  required size: 49738
  required size: 116661
  required size: 439574
level:1, strategy: 0, dowrap: true
  required size: 552973  <- there is an issue
  required size: 466730
  required size: 509795
  required size: 94907
  required size: 476173


All other levels are okay, this could be explained by Ilya's patch. What states that `hardware` compression will be used on level 1 and `software` compression will be used on all other levels.

-------------

PR: https://git.openjdk.org/jdk/pull/12283

From mdoerr at openjdk.org  Wed Feb 22 05:39:36 2023
From: mdoerr at openjdk.org (Martin Doerr)
Date: Wed, 22 Feb 2023 05:39:36 GMT
Subject: RFR: 8303040: linux PPC64le: Implementation of Foreign Function &
 Memory API (Preview)
Message-ID: <Yuxy6FrsDAN79ya8w8UIkvytGr25zGllDPtPJ1QbGwc=.182664b2-6d8c-497e-a4ae-95e0ad007cf9@github.com>

Description will get added soon.

-------------

Commit messages:
 - Initial Panama implementation.

Changes: https://git.openjdk.org/jdk/pull/12708/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12708&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8303040
  Stats: 1973 lines in 58 files changed: 1865 ins; 1 del; 107 mod
  Patch: https://git.openjdk.org/jdk/pull/12708.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12708/head:pull/12708

PR: https://git.openjdk.org/jdk/pull/12708

From duke at openjdk.org  Wed Feb 22 07:11:16 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Wed, 22 Feb 2023 07:11:16 GMT
Subject: RFR: 8302871: Speed up StringLatin1.regionMatchesCI [v10]
In-Reply-To: <dnsiX3nRffjGjZXJG7lMAZj2FktEl2Wc1XfFthQ4iJs=.8c41438a-80a4-468f-ae0b-7322c9d6d952@github.com>
References: <dnsiX3nRffjGjZXJG7lMAZj2FktEl2Wc1XfFthQ4iJs=.8c41438a-80a4-468f-ae0b-7322c9d6d952@github.com>
Message-ID: <Yt8f3DV2V3EHrO3B7A0x3KV1g-djrx94rVr8MPqeOYE=.1b03096f-c3da-4092-bb59-36d88c9d5036@github.com>

> This PR suggests we can speed up `StringLatin1.regionMatchesCI` by applying 'the oldest ASCII trick in the book'.
> 
> The new static method `CharacterDataLatin1.equalsIgnoreCase` compares two latin1 bytes for equality ignoring case. `StringLatin1.regionMatchesCI` is updated to use `equalsIgnoreCase`
> 
> To verify the correctness of `equalsIgnoreCase`, a new test is added  to `EqualsIgnoreCase` with an exhaustive verification that all 256x256 latin1 code point pairs have an `equalsIgnoreCase` consistent with Character.toUpperCase, Character.toLowerCase.
> 
> Performance is tested for matching and mismatching cases of code point pairs picked from the ASCII letter, ASCII number and latin1 letter ranges. Results in the first comment below.

Eirik Bjorsnos has updated the pull request incrementally with two additional commits since the last revision:

 - Replace 'oldest ASCII trick in the book' use in toUpperCase, toLowerCase with "by removing (setting) a single bit"
 - Align local variable naming in toLowerCase, toUpperCase with equalsIgnoreCase by using 'lower' and 'upper'

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12632/files
  - new: https://git.openjdk.org/jdk/pull/12632/files/6588ab0f..44d91544

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12632&range=09
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12632&range=08-09

  Stats: 11 lines in 1 file changed: 2 ins; 0 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/12632.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12632/head:pull/12632

PR: https://git.openjdk.org/jdk/pull/12632

From duke at openjdk.org  Wed Feb 22 07:15:44 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Wed, 22 Feb 2023 07:15:44 GMT
Subject: RFR: 8302871: Speed up StringLatin1.regionMatchesCI [v7]
In-Reply-To: <wlKduCbkD5AhEIrqz_e-LlUM6ImLx8C1V7HXlm86zDE=.6d3574c3-b738-4084-87cc-a5e578ab6144@github.com>
References: <dnsiX3nRffjGjZXJG7lMAZj2FktEl2Wc1XfFthQ4iJs=.8c41438a-80a4-468f-ae0b-7322c9d6d952@github.com>
 <AhNijA3f_Yl5Ornr9pqngR3yaepTQNEJeposarKW-Wg=.90a0b345-88dc-4648-a0fb-c83d1dd7e9d5@github.com>
 <hfJIZbrr5qSkn0BU1nyriYMyV9cFWN7e1iKHO-bvZks=.a829ef78-fe38-402a-877b-431591d23e15@github.com>
 <jUSHM1nTkwyjspO5Rn4h-OBQIsE62lvJZK7K-qhq3uI=.94ac5e1c-128e-4991-98d5-c202aa7d0610@github.com>
 <rXD4iIFMdlGyHf7E2a4O2Oz6iQmrItoFdp3pREh8yl0=.c407b886-9646-4a83-94a3-8f738e94ea06@github.com>
 <bYxNp9wXu0hHmU5U7L0AekEKt2hSBAhwpZbFePTlkRw=.8b96e631-82eb-4190-854a-88f3af25716b@github.com>
 <d4JliesOUX_SDPQOQrSFc2kaByJfA5vYFK-Sz7ij81Y=.ef887b72-d16b-499d-acca-d513a7ae7c6b@github.com>
 <PGdB8YD1ojFfu7vOE-mVz-HAz4JwKsC0bpw0s5DRXQU=.d048722a-63e8-456c-8d0f-749ed413c521@github.com>
 <JixGIkrtsQX2nya-qbWLfVf_MHOqWofpAsPcHCkpqRo=.842dafa9-84f2-49f2-8f71-f1a80b558a19@github.com>
 <f5OUHqyQBUqHQ4NJNK5tRyliXk7XoDMJEaevQvvwbtk=.dd9dd461-69e2-4153-a225-d20482277cd6@github.com>
 <wlKduCbkD5AhEIrqz_e-LlUM6ImLx8C1V7H
 Xlm86zDE=.6d3574c3-b738-4084-87cc-a5e578ab6144@github.com>
Message-ID: <f-Ox9ol_xiR5psYimcMLfJTDIHezxMiCoAd9OxW4pBI=.7169e0c8-a70f-45f7-9edd-8658b330aefc@github.com>

On Wed, 22 Feb 2023 00:50:39 GMT, Martin Buchholz <martin at openjdk.org> wrote:

>> More history: IIRC I originally used 'ASCII trick' when I was truly only cared about ASCII, not Latin1 (e.g. ZipFile.isMetaName) and it's a slight misnomer to use "ASCII" here.  But Latin1 followed the precedent of ASCII.
>
>> Do you have an opinion on the appropriate level of documentation / comments for this kind of 'tricky' code? 
> 
> This code is not that tricky!  And the proposed level of documentation is excessive!  A couple of lines of explanation and perhaps a link to an external document would be good.
> 
> It often happens to me that I will write such exhaustive notes for myself when learning a new technology.  A year later I pare it all back because much of it is "obvious in retrospect".

Thanks Martin, David, Alan.  This was instructive (and fun!)

I suggest we condense the comment to something like this:


// Uppercase b1 by removing a single bit
int upper = b1 & 0xDF;
if (upper < 'A') {
    return false;  // Low ASCII
}
...


The similar methods `toLowerCase` `toUpperCase` just above have been updated to follow the same style. (I also updated local variable names there to align better with equalsIgnoreCase)

-------------

PR: https://git.openjdk.org/jdk/pull/12632

From alanb at openjdk.org  Wed Feb 22 07:27:31 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 22 Feb 2023 07:27:31 GMT
Subject: RFR: 8302791: Add specific ClassLoader object to Proxy
 IllegalArgumentException message
In-Reply-To: <O5sadWrVYh2fiWVEDQLWPnBPMH73RNHmN4ifU7h4a4k=.490377ab-f81b-4a21-8017-2bc002b0ccc8@github.com>
References: <O5sadWrVYh2fiWVEDQLWPnBPMH73RNHmN4ifU7h4a4k=.490377ab-f81b-4a21-8017-2bc002b0ccc8@github.com>
Message-ID: <NX5FE2YPsglCCPDpGLEorNik96Hrzq7b5wMF7AwrzHw=.03bdd7d3-8b35-4f4f-9d97-022e6aa91b1a@github.com>

On Sun, 19 Feb 2023 08:28:37 GMT, Ravali Yatham <duke at openjdk.org> wrote:

> Added specific class loader object to proxy IllegalArgumentException from which the class was not visible
> 
> The bug report for the same: https://bugs.openjdk.org/browse/JDK-8302791

src/java.base/share/classes/java/lang/reflect/Proxy.java line 881:

> 879:             if (type != c) {
> 880:                 throw new IllegalArgumentException(c.getName() +
> 881:                         " referenced from a method is not visible from class loader: " + ld);

The ClassLoader string representation may or may not be useful here. One suggestion is to use the class loader name (ld.getName()) if not null, otherwise Objects.toIdentityString(ld).

-------------

PR: https://git.openjdk.org/jdk/pull/12641

From dnsimon at openjdk.org  Wed Feb 22 09:49:58 2023
From: dnsimon at openjdk.org (Doug Simon)
Date: Wed, 22 Feb 2023 09:49:58 GMT
Subject: RFR: 8302976: C2 intrinsification of Float.floatToFloat16 and
 Float.float16ToFloat yields different result than the interpreter
In-Reply-To: <u4CPxJRd0uJKQf32who9UTr9fPfJWVetIzM8X4OnhCQ=.4f4fdf86-d260-4c13-bbc6-2a198d322994@github.com>
References: <f18TfSibBBm5FLon1VlUN0m6fNUzvOpsUeo7nEAk7JY=.456ddc51-7be7-4484-ad38-1039453b83d6@github.com>
 <nzUBOq3a8MVvd4EmIiPb95fr3JwBnUi1f1SGxWT2UBw=.d715b6e1-aba5-4448-be15-0cb418cc1084@github.com>
 <u4CPxJRd0uJKQf32who9UTr9fPfJWVetIzM8X4OnhCQ=.4f4fdf86-d260-4c13-bbc6-2a198d322994@github.com>
Message-ID: <-3z8sZMccXAOTV4KgeqrX6KQTcnSP20B70a293fhQSI=.354c1f98-c5bd-4b7e-a59a-10ff31d7d6b9@github.com>

On Wed, 22 Feb 2023 05:21:48 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> That said, I think it is reasonable on a given JVM invocation if Float.floatToFloat16(f) gave the same result for input f regardless of in what context it was called.

Yes, I'm under the impression that for math API methods like this, the stability of input to output must be preserved for a single JVM invocation. Or are there existing methods for which the interpreter and compiled code execution is allowed to differ?

-------------

PR: https://git.openjdk.org/jdk/pull/12704

From tvaleev at openjdk.org  Wed Feb 22 09:55:00 2023
From: tvaleev at openjdk.org (Tagir F. Valeev)
Date: Wed, 22 Feb 2023 09:55:00 GMT
Subject: Integrated: 8302815 Use new Math.clamp method in core libraries
In-Reply-To: <k_xjmup3YSdUre0Z_XpO-WEBb5XED2FYv8UUZT2ULwc=.86f53f51-cceb-45fd-935d-b054c79a0526@github.com>
References: <k_xjmup3YSdUre0Z_XpO-WEBb5XED2FYv8UUZT2ULwc=.86f53f51-cceb-45fd-935d-b054c79a0526@github.com>
Message-ID: <uneJh9xm0xpMTSGWibl3hpkaSaC5iYGsmwF7VaAdspc=.0b5c502d-06fc-4ea7-b3e9-80ae9d02d551@github.com>

On Sat, 18 Feb 2023 10:50:53 GMT, Tagir F. Valeev <tvaleev at openjdk.org> wrote:

> For cleanup and dogfooding the new method, it would be nice to use Math.clamp where possible in java.base. See PR #12428.
> 
> As Math.clamp performs an additional check that min is not greater than max, I conservatively replaced only those occurrences where I can see that this invariant is always held. There are more occurrences, where clamp can be potentially used but it's unclear whether min <= max is always true.

This pull request has now been integrated.

Changeset: 3f3a1f53
Author:    Tagir F. Valeev <tvaleev at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/3f3a1f534b7f2f5be6d7ded9d9832fa9394e763c
Stats:     45 lines in 11 files changed: 0 ins; 8 del; 37 mod

8302815: Use new Math.clamp method in core libraries

Reviewed-by: alanb

-------------

PR: https://git.openjdk.org/jdk/pull/12633

From alanb at openjdk.org  Wed Feb 22 10:00:31 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 22 Feb 2023 10:00:31 GMT
Subject: RFR: 8301119: Support for GB18030-2022
In-Reply-To: <FXBchbCnbNloQO7Nlh9Ijue_c_YugGk-UC7_-ZAjY2o=.7e1ca01f-8cee-40bb-bb06-6e5670abe661@github.com>
References: <FXBchbCnbNloQO7Nlh9Ijue_c_YugGk-UC7_-ZAjY2o=.7e1ca01f-8cee-40bb-bb06-6e5670abe661@github.com>
Message-ID: <78oXv8oehtNFwbwcPyczGNkWZcLFjxWH4pUDin1KTTI=.ca90d92f-04d2-47cc-8da9-e956f315046f@github.com>

On Fri, 10 Feb 2023 20:35:58 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Upgrading the GB18030 charset in the JDK to the latest 2022 standard. Since this is not a compatible upgrade to the existing mapping, a new system property `jdk.charset.GB18030` is introduced. If it is set to "2000", the mapping falls back to the existing mapping based on the 2000 standard, otherwise, it defaults to 2022 mapping. Refer to the corresponding CSR for more detail.

src/java.base/share/classes/sun/nio/cs/StandardCharsets.java.template line 211:

> 209: 
> 210:     // Lazily initialized system property value
> 211:     private static String GB18030_2000;

I assume this should be a stable field.

-------------

PR: https://git.openjdk.org/jdk/pull/12518

From coffeys at openjdk.org  Wed Feb 22 10:48:55 2023
From: coffeys at openjdk.org (Sean Coffey)
Date: Wed, 22 Feb 2023 10:48:55 GMT
Subject: RFR: 8301119: Support for GB18030-2022
In-Reply-To: <FXBchbCnbNloQO7Nlh9Ijue_c_YugGk-UC7_-ZAjY2o=.7e1ca01f-8cee-40bb-bb06-6e5670abe661@github.com>
References: <FXBchbCnbNloQO7Nlh9Ijue_c_YugGk-UC7_-ZAjY2o=.7e1ca01f-8cee-40bb-bb06-6e5670abe661@github.com>
Message-ID: <S6p8hZiWOrDpXAzaeJ3L4kOIferQtFHKmFaa_1gNTyo=.0a245135-1bf9-47a1-b992-36edcbc2d612@github.com>

On Fri, 10 Feb 2023 20:35:58 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Upgrading the GB18030 charset in the JDK to the latest 2022 standard. Since this is not a compatible upgrade to the existing mapping, a new system property `jdk.charset.GB18030` is introduced. If it is set to "2000", the mapping falls back to the existing mapping based on the 2000 standard, otherwise, it defaults to 2022 mapping. Refer to the corresponding CSR for more detail.

src/java.base/share/classes/sun/nio/cs/StandardCharsets.java.template line 217:

> 215:             if (VM.initLevel() < 1) {
> 216:                 // Cannot get the system property yet. Assumes non-2000
> 217:                 GB18030_2000 = "";

curious - what scenario triggers this call at initLevel < 1 ? would it be better to simply return "false" at that time and leave the GB18030_2000 variable to be set once we're at initLevel >=1  ?  -- or perhaps that would invalidate the workflow of the original caller (which called in at initLevel <1)

-------------

PR: https://git.openjdk.org/jdk/pull/12518

From simonis at openjdk.org  Wed Feb 22 11:23:15 2023
From: simonis at openjdk.org (Volker Simonis)
Date: Wed, 22 Feb 2023 11:23:15 GMT
Subject: RFR: 8302154: Hidden classes created by LambdaMetaFactory can't be
 unloaded [v2]
In-Reply-To: <kbfSN3qaumbk55MszZS2wq9JAvSfKKB5VCLqXqe3Ogs=.ba6c5fdc-4c7b-42d3-b6bb-3f05e4baf789@github.com>
References: <YoZauVv8zvhdUw-LD25LrsMDItFbg3aXPU3deXwwFdQ=.c2839dea-12e5-4e0e-9579-eac9d8503932@github.com>
 <gKoLpwlXDxp2uaSKSkMArJl1Ym9VX1hoDFqQTTUpk8w=.e1dce669-5a42-4b66-ac4b-205718c8eb81@github.com>
 <kbfSN3qaumbk55MszZS2wq9JAvSfKKB5VCLqXqe3Ogs=.ba6c5fdc-4c7b-42d3-b6bb-3f05e4baf789@github.com>
Message-ID: <9Qs4-JH8-M20G-Cu39MHZhbraXHeSGB50zskJFOJlTI=.427e4206-a66e-4aba-92d6-3ac555480daa@github.com>

On Tue, 21 Feb 2023 19:49:24 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> The reason that non-strongly linked classes have their own ClassLoaderData is because it implements the property that when the class loader is no longer loaded, metadata for it can be removed at once. Even though Metaspace has been redesigned to be less fragmented, this is simpler than removing selected entities inside metaspace. Replacing it with a more sophisticated design would not an be an improvement. So I have to disagree with your statement above.

How could it be not an improvement to save ~600 bytes of native memory per class? Sorry, but I start to have real problems to follow this discussion. First you don't want to change strongly linked Hidden Classes to weakly linked ones **because** of the native memory overhead and then you say that a more sophisticated implementation which will eliminate this overhead would **not** be an improvement. I'm puzzled.

-------------

PR: https://git.openjdk.org/jdk/pull/12493

From alanb at openjdk.org  Wed Feb 22 11:38:14 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 22 Feb 2023 11:38:14 GMT
Subject: RFR: 8301119: Support for GB18030-2022
In-Reply-To: <S6p8hZiWOrDpXAzaeJ3L4kOIferQtFHKmFaa_1gNTyo=.0a245135-1bf9-47a1-b992-36edcbc2d612@github.com>
References: <FXBchbCnbNloQO7Nlh9Ijue_c_YugGk-UC7_-ZAjY2o=.7e1ca01f-8cee-40bb-bb06-6e5670abe661@github.com>
 <S6p8hZiWOrDpXAzaeJ3L4kOIferQtFHKmFaa_1gNTyo=.0a245135-1bf9-47a1-b992-36edcbc2d612@github.com>
Message-ID: <Fo1WnNOBMptjHkVUUtdvx4p03Ci1ljacM9bkFux2Qus=.b8082d30-35e9-491e-88a0-d00105f4381b@github.com>

On Wed, 22 Feb 2023 10:46:10 GMT, Sean Coffey <coffeys at openjdk.org> wrote:

> curious - what scenario triggers this call at initLevel < 1 ?

It's not supported, but it is possible that someone might run with -Dfile.encoding=GB18030, in which case the default charset is used before the system properties are initialized in initPhase1. Checking the init level breaks the circularity, the only downside is that can't switch to GB18030-2000 at the same time.

-------------

PR: https://git.openjdk.org/jdk/pull/12518

From redestad at openjdk.org  Wed Feb 22 11:38:16 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Wed, 22 Feb 2023 11:38:16 GMT
Subject: RFR: 8302871: Speed up StringLatin1.regionMatchesCI [v10]
In-Reply-To: <Yt8f3DV2V3EHrO3B7A0x3KV1g-djrx94rVr8MPqeOYE=.1b03096f-c3da-4092-bb59-36d88c9d5036@github.com>
References: <dnsiX3nRffjGjZXJG7lMAZj2FktEl2Wc1XfFthQ4iJs=.8c41438a-80a4-468f-ae0b-7322c9d6d952@github.com>
 <Yt8f3DV2V3EHrO3B7A0x3KV1g-djrx94rVr8MPqeOYE=.1b03096f-c3da-4092-bb59-36d88c9d5036@github.com>
Message-ID: <o8nPvFS7H1eCXYDFaU9hXQH7UXEUNbLyL4iUXF9auNA=.5da1cf45-61f8-4d0a-9867-af6e352cb918@github.com>

On Wed, 22 Feb 2023 07:11:16 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

>> This PR suggests we can speed up `StringLatin1.regionMatchesCI` by applying 'the oldest ASCII trick in the book'.
>> 
>> The new static method `CharacterDataLatin1.equalsIgnoreCase` compares two latin1 bytes for equality ignoring case. `StringLatin1.regionMatchesCI` is updated to use `equalsIgnoreCase`
>> 
>> To verify the correctness of `equalsIgnoreCase`, a new test is added  to `EqualsIgnoreCase` with an exhaustive verification that all 256x256 latin1 code point pairs have an `equalsIgnoreCase` consistent with Character.toUpperCase, Character.toLowerCase.
>> 
>> Performance is tested for matching and mismatching cases of code point pairs picked from the ASCII letter, ASCII number and latin1 letter ranges. Results in the first comment below.
>
> Eirik Bjorsnos has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Replace 'oldest ASCII trick in the book' use in toUpperCase, toLowerCase with "by removing (setting) a single bit"
>  - Align local variable naming in toLowerCase, toUpperCase with equalsIgnoreCase by using 'lower' and 'upper'

Marked as reviewed by redestad (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/12632

From simonis at openjdk.org  Wed Feb 22 13:41:46 2023
From: simonis at openjdk.org (Volker Simonis)
Date: Wed, 22 Feb 2023 13:41:46 GMT
Subject: RFR: 8302154: Hidden classes created by LambdaMetaFactory can't be
 unloaded [v2]
In-Reply-To: <jMP3m1mHlnWg40SZD-k2pQmeTLEBMfEO5xKZa7B66Go=.ceb6545e-bb8f-4d19-986b-1202279c74da@github.com>
References: <YoZauVv8zvhdUw-LD25LrsMDItFbg3aXPU3deXwwFdQ=.c2839dea-12e5-4e0e-9579-eac9d8503932@github.com>
 <gKoLpwlXDxp2uaSKSkMArJl1Ym9VX1hoDFqQTTUpk8w=.e1dce669-5a42-4b66-ac4b-205718c8eb81@github.com>
 <jMP3m1mHlnWg40SZD-k2pQmeTLEBMfEO5xKZa7B66Go=.ceb6545e-bb8f-4d19-986b-1202279c74da@github.com>
Message-ID: <4ntc5zIvBrfwF7J3X0fWgA3n0XPc1Ih29LvVTVs6YwY=.fef99bb7-297a-4060-921d-d3798a2342b4@github.com>

On Tue, 21 Feb 2023 23:44:48 GMT, David Holmes <dholmes at openjdk.org> wrote:

> I also have to disagree with the statement. The unit of unloading is the ClassLoader.

Hidden classes are not normal classes. They are not defined, created or loaded by a class loader. The only reason why hidden classes maintain a link to a *defining class loader* is because they need it to resolve types used by the hidden class's own fields and methods.
 
Some references from [JEP 371: Hidden Classes](https://openjdk.org/jeps/371):

> Dynamically generated classes may only be needed for a limited time, so retaining them for the lifetime of the statically generated class might unnecessarily increase memory footprint. Existing workarounds for this situation, such as per-class class loaders, are cumbersome and inefficient.

> A hidden class can be unloaded when it is no longer reachable, or it can share the lifetime of a class loader so that it is unloaded only when the class loader is garbage collected

> A hidden class is not created by a class loader and has only a loose connection to the class loader deemed to be its defining loader. We can turn these facts to our advantage by allowing a hidden class to be unloaded even if its notional defining loader cannot be reclaimed by the garbage collector.

> By default, Lookup::defineHiddenClass will create a hidden class that can be unloaded regardless of whether its notional defining loader is still alive. That is, when all instances of the hidden class are reclaimed and the hidden class is no longer reachable, it may be unloaded even though its notional defining loader is still reachable. This behavior is useful when a language runtime creates a hidden class to serve multiple classes defined by arbitrary class loaders: The runtime will see an improvement in footprint and performance relative to both `ClassLoader::defineClass()` and Unsafe::defineAnonymousClass()`

The only reason why hidden classes created by `LambdaMetaFactory` are strongly linked to a class loader (at least I haven't heard any other argument until now in this thread) is to *save native memory* and not because it is *logically required*! It's fine for me if you don't want to fix that. I can just not understand why you are all still insisting that creating a new ClassLoaderData object per hidden class is such a great decision and fixing that would not be beneficial.

Hidden classes were designed to be light-weight and easily unloadable (see JEP references above). In the case of `LambdaMetaFactory` we unnecessarily link them strongly to a class loader just because the current implementation is too expensive otherwise. On a side note, the JDK already creates non-strongly linked hidden classes as well, e.g. for `java.lang.invoke.MethodHandles$Lookup.unreflect()`.

-------------

PR: https://git.openjdk.org/jdk/pull/12493

From simonis at openjdk.org  Wed Feb 22 14:10:28 2023
From: simonis at openjdk.org (Volker Simonis)
Date: Wed, 22 Feb 2023 14:10:28 GMT
Subject: RFR: 8302154: Hidden classes created by LambdaMetaFactory can't be
 unloaded [v2]
In-Reply-To: <4ntc5zIvBrfwF7J3X0fWgA3n0XPc1Ih29LvVTVs6YwY=.fef99bb7-297a-4060-921d-d3798a2342b4@github.com>
References: <YoZauVv8zvhdUw-LD25LrsMDItFbg3aXPU3deXwwFdQ=.c2839dea-12e5-4e0e-9579-eac9d8503932@github.com>
 <gKoLpwlXDxp2uaSKSkMArJl1Ym9VX1hoDFqQTTUpk8w=.e1dce669-5a42-4b66-ac4b-205718c8eb81@github.com>
 <jMP3m1mHlnWg40SZD-k2pQmeTLEBMfEO5xKZa7B66Go=.ceb6545e-bb8f-4d19-986b-1202279c74da@github.com>
 <4ntc5zIvBrfwF7J3X0fWgA3n0XPc1Ih29LvVTVs6YwY=.fef99bb7-297a-4060-921d-d3798a2342b4@github.com>
Message-ID: <n5R3USFyIy5Pudlli6969HaQm-7udU5lxkwHU5efnvA=.befa752f-0fca-4a3b-9ba0-68a19b9df9c3@github.com>

On Wed, 22 Feb 2023 13:38:57 GMT, Volker Simonis <simonis at openjdk.org> wrote:

>> I also have to disagree with the statement. The unit of unloading is the ClassLoader.
>
>> I also have to disagree with the statement. The unit of unloading is the ClassLoader.
> 
> Hidden classes are not normal classes. They are not defined, created or loaded by a class loader. The only reason why hidden classes maintain a link to a *defining class loader* is because they need it to resolve types used by the hidden class's own fields and methods.
>  
> Some references from [JEP 371: Hidden Classes](https://openjdk.org/jeps/371):
> 
>> Dynamically generated classes may only be needed for a limited time, so retaining them for the lifetime of the statically generated class might unnecessarily increase memory footprint. Existing workarounds for this situation, such as per-class class loaders, are cumbersome and inefficient.
> 
>> A hidden class can be unloaded when it is no longer reachable, or it can share the lifetime of a class loader so that it is unloaded only when the class loader is garbage collected
> 
>> A hidden class is not created by a class loader and has only a loose connection to the class loader deemed to be its defining loader. We can turn these facts to our advantage by allowing a hidden class to be unloaded even if its notional defining loader cannot be reclaimed by the garbage collector.
> 
>> By default, Lookup::defineHiddenClass will create a hidden class that can be unloaded regardless of whether its notional defining loader is still alive. That is, when all instances of the hidden class are reclaimed and the hidden class is no longer reachable, it may be unloaded even though its notional defining loader is still reachable. This behavior is useful when a language runtime creates a hidden class to serve multiple classes defined by arbitrary class loaders: The runtime will see an improvement in footprint and performance relative to both `ClassLoader::defineClass()` and Unsafe::defineAnonymousClass()`
> 
> The only reason why hidden classes created by `LambdaMetaFactory` are strongly linked to a class loader (at least I haven't heard any other argument until now in this thread) is to *save native memory* and not because it is *logically required*! It's fine for me if you don't want to fix that. I can just not understand why you are all still insisting that creating a new ClassLoaderData object per hidden class is such a great decision and fixing that would not be beneficial.
> 
> Hidden classes were designed to be light-weight and easily unloadable (see JEP references above). In the case of `LambdaMetaFactory` we unnecessarily link them strongly to a class loader just because the current implementation is too expensive otherwise. On a side note, the JDK already creates non-strongly linked hidden classes as well, e.g. for `java.lang.invoke.MethodHandles$Lookup.unreflect()`.

> @simonis I want to ask a basic question -- what is the reason for your code to call `LambdaMetafactory.metafactory()` directly? It looks like you want to implement so sort of dynamic dispatch. Can equivalent functionality be implemented by the app itself?
> 
> If there's a real need for such a style of programming, and it requires some sort of built-in support in by the JDK, maybe we should have a proper API instead of piggy-backing on `LambdaMetafactory.metafactory()`.
> 
> I think if you give us more background, we can make this a more productive discussion than focusing on "did we make the right decision N versions ago" without defining what "right" means :-)
> 
> I would suggest re-booting this decision in the mailing lists rather than continuing in this PR.

The initial reason for this issue comes from here https://github.com/aws/aws-sdk-java-v2/issues/3701. That issue could be solved by caching. However, as I've outlined in my other answers above, I still think that one ClassLoaderData per hidden class is overly expensive and not really required. I'm fine if you don't want to fix that I just don't understand why you think it is a great solution?

-------------

PR: https://git.openjdk.org/jdk/pull/12493

From forax at openjdk.org  Wed Feb 22 14:10:35 2023
From: forax at openjdk.org (=?UTF-8?B?UsOpbWk=?= Forax)
Date: Wed, 22 Feb 2023 14:10:35 GMT
Subject: RFR: 8302154: Hidden classes created by LambdaMetaFactory can't be
 unloaded [v2]
In-Reply-To: <gKoLpwlXDxp2uaSKSkMArJl1Ym9VX1hoDFqQTTUpk8w=.e1dce669-5a42-4b66-ac4b-205718c8eb81@github.com>
References: <YoZauVv8zvhdUw-LD25LrsMDItFbg3aXPU3deXwwFdQ=.c2839dea-12e5-4e0e-9579-eac9d8503932@github.com>
 <gKoLpwlXDxp2uaSKSkMArJl1Ym9VX1hoDFqQTTUpk8w=.e1dce669-5a42-4b66-ac4b-205718c8eb81@github.com>
Message-ID: <xI3lh4YJqG3oFjgs6m6TOWVMbBbhe42sTziMzpgYrmo=.cc2f6def-67ac-4d82-b629-941fe06bd2ba@github.com>

On Thu, 9 Feb 2023 18:11:18 GMT, Volker Simonis <simonis at openjdk.org> wrote:

>> Prior to [JDK-8239384](https://bugs.openjdk.org/browse/JDK-8239384)/[JDK-8238358](https://bugs.openjdk.org/browse/JDK-8238358) LambdaMetaFactory has created VM-anonymous classes which could easily be unloaded once they were not referenced any more. Starting with JDK 15 and the new "hidden class" based implementation, this is not the case any more, because the hidden classes will be strongly tied to their defining class loader. If this is the default application class loader, these hidden classes can never be unloaded which can easily lead to Metaspace exhaustion (see the [test case in the JBS issue](https://bugs.openjdk.org/secure/attachment/102601/LambdaClassLeak.java)). This is a regression compared to previous JDK versions which some of our applications have been affected from when migrating to JDK 17.
>> 
>> The reason why the newly created hidden classes are strongly linked to their defining class loader is not clear to me. JDK-8239384 mentions it as an "implementation detail":
>> 
>>> *4. the lambda proxy class has the strong relationship with the class loader (that will share the VM metaspace for its defining loader - implementation details)*
>> 
>> From my current understanding the strong link between a hidden class created by `LambdaMetaFactory` and its defining class loader is not strictly required. In order to prevent potential OOMs and fix the regression compared the JDK 14 and earlier I propose to create these hidden classes without the `STRONG` option.
>> 
>> I'll be happy to add the test case as JTreg test to this PR if you think that would be useful.
>
> Volker Simonis has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Remove assertions which insist on Lambda proxy classes being strongly linked to their class loader
>  - Removed unused import of STRONG und updated copyright year

Volker, i think you are mixing lambda metafactory and hidden classes.

Hidden Classes have been envision has a way to generate adapters at runtime for languages that run on the JVM.
They replace VM anonymous classes that were both unsafe and always not bound to a classloader.

Lambda metafactory is the entry point to create lambda proxy for Java (the language).
The current implementation is using hidden classes to represent lambda proxy. In the past, it was using VM anonymous classes that why lambdas were not tie to a classloader, the fact that the implementation was using VM anonymous class was leaking.

To unload a Java class, its clasloader has to be unreachable. I see no reason this behavior should not be the same for Java lambdas classes. I believe it's what David is saying too.

Now, for https://github.com/aws/aws-sdk-java-v2/issues/3701, you can fix it by using a ClassValue to cache the class and/or using a hidden class. For me, this has nothing to do with Java lambdas, i.e. nothing to do with the lambda metafactory.

-------------

PR: https://git.openjdk.org/jdk/pull/12493

From pminborg at openjdk.org  Wed Feb 22 14:11:45 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 22 Feb 2023 14:11:45 GMT
Subject: RFR: 8303040: linux PPC64le: Implementation of Foreign Function &
 Memory API (Preview)
In-Reply-To: <Yuxy6FrsDAN79ya8w8UIkvytGr25zGllDPtPJ1QbGwc=.182664b2-6d8c-497e-a4ae-95e0ad007cf9@github.com>
References: <Yuxy6FrsDAN79ya8w8UIkvytGr25zGllDPtPJ1QbGwc=.182664b2-6d8c-497e-a4ae-95e0ad007cf9@github.com>
Message-ID: <_QETLZVuG6pkWyXvp1Plh3rOVjFn_sYEP09AE7MdsAE=.6f20102e-eaa0-4425-bc26-ab95ab6338ee@github.com>

On Wed, 22 Feb 2023 05:31:46 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

> Implementation of "Foreign Function & Memory API" for linux on Power (Little Endian) according to "Power Architecture 64-Bit ELF V2 ABI Specification".
> 
> This PR does not include code for VaList support because it's supposed to get removed by [JDK-8299736](https://bugs.openjdk.org/browse/JDK-8299736). I've kept the related tests disabled for this platform and throw an exception instead. Note that the ABI doesn't precisely specify variable argument lists. Instead, it refers to `<stdarg.h>` (2.2.4 Variable Argument Lists).
> 
> Big Endian support is implemented to some extend, but not complete. E.g. structs with size not divisible by 8 are not passed correctly (see `useABIv2` in CallArranger.java). Big Endian is excluded by selecting `ARCH.equals("ppc64le")` (CABI.java) only.
> 
> There's another limitation: This PR only accepts structures with size divisible by 4. (An `IllegalArgumentException` gets thrown otherwise.) I think arbitrary sizes are not usable on other platforms, either, because `SharedUtils.primitiveCarrierForSize` only accepts powers of 2.
> 
> The ABI has some tricky corner cases related to HFA (Homogeneous Float Aggregate). The same argument may need to get passed in both, a FP reg and a GP reg or stack slot (see "no partial DW rule"). This cases are not covered by the existing tests.
> 
> I had to make changes to shared code and code for other platforms:
> 1. Pass type information when creating `VMStorage` objects from `VMReg`. This is needed for the following reasons:
> - PPC64 ABI requires integer types to get extended to 64 bit (also see CCallingConventionRequiresIntsAsLongs in existing hotspot code). We need to know the type or at least the bit width for that.
> - Floating point load / store instructions need the correct width to select between the correct IEEE 754 formats. The register representation in single FP registers is always IEEE 754 double precision on PPC64.
> - Big Endian also needs usage of the precise size. Storing 8 Bytes and loading 4 Bytes yields different values than on Little Endian!
> 2. It happens that a `NativeMemorySegmentImpl` is used as a raw pointer (with byteSize() == 0) while running TestUpcallScope. Hence, existing size checks don't work (see MemorySegment.java). As a workaround, I'm just skipping the check in this particular case. Please check if this makes sense or if there's a better fix (possibly as separate RFE).

In the most recent version of the Panama FFM API, any memory layout (including struct and padding layouts) are always byte aligned.

-------------

PR: https://git.openjdk.org/jdk/pull/12708

From jcking at openjdk.org  Wed Feb 22 14:36:20 2023
From: jcking at openjdk.org (Justin King)
Date: Wed, 22 Feb 2023 14:36:20 GMT
Subject: RFR: JDK-8303072: Memory leak in exeNullCallerTest.cpp
Message-ID: <CeYIh1UwJeTs52-a3EJQThW5XEymSruJhYB9Qx_nkj0=.d48da304-04b1-41cc-89f3-14f222ef847b@github.com>

Fix trivial memory leak that occurs during tests.

-------------

Commit messages:
 - Memory leak in exeNullCallerTest.cpp

Changes: https://git.openjdk.org/jdk/pull/12715/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12715&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8303072
  Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/12715.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12715/head:pull/12715

PR: https://git.openjdk.org/jdk/pull/12715

From jvernee at openjdk.org  Wed Feb 22 15:20:00 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Wed, 22 Feb 2023 15:20:00 GMT
Subject: RFR: 8302154: Hidden classes created by LambdaMetaFactory can't be
 unloaded [v2]
In-Reply-To: <gKoLpwlXDxp2uaSKSkMArJl1Ym9VX1hoDFqQTTUpk8w=.e1dce669-5a42-4b66-ac4b-205718c8eb81@github.com>
References: <YoZauVv8zvhdUw-LD25LrsMDItFbg3aXPU3deXwwFdQ=.c2839dea-12e5-4e0e-9579-eac9d8503932@github.com>
 <gKoLpwlXDxp2uaSKSkMArJl1Ym9VX1hoDFqQTTUpk8w=.e1dce669-5a42-4b66-ac4b-205718c8eb81@github.com>
Message-ID: <sb06HVTbolT1O8MI9Z7AFc3AgzVfWMhp3HXeVyxm1hw=.27ed9256-4a1c-4b99-bc0c-1613a5ced02e@github.com>

On Thu, 9 Feb 2023 18:11:18 GMT, Volker Simonis <simonis at openjdk.org> wrote:

>> Prior to [JDK-8239384](https://bugs.openjdk.org/browse/JDK-8239384)/[JDK-8238358](https://bugs.openjdk.org/browse/JDK-8238358) LambdaMetaFactory has created VM-anonymous classes which could easily be unloaded once they were not referenced any more. Starting with JDK 15 and the new "hidden class" based implementation, this is not the case any more, because the hidden classes will be strongly tied to their defining class loader. If this is the default application class loader, these hidden classes can never be unloaded which can easily lead to Metaspace exhaustion (see the [test case in the JBS issue](https://bugs.openjdk.org/secure/attachment/102601/LambdaClassLeak.java)). This is a regression compared to previous JDK versions which some of our applications have been affected from when migrating to JDK 17.
>> 
>> The reason why the newly created hidden classes are strongly linked to their defining class loader is not clear to me. JDK-8239384 mentions it as an "implementation detail":
>> 
>>> *4. the lambda proxy class has the strong relationship with the class loader (that will share the VM metaspace for its defining loader - implementation details)*
>> 
>> From my current understanding the strong link between a hidden class created by `LambdaMetaFactory` and its defining class loader is not strictly required. In order to prevent potential OOMs and fix the regression compared the JDK 14 and earlier I propose to create these hidden classes without the `STRONG` option.
>> 
>> I'll be happy to add the test case as JTreg test to this PR if you think that would be useful.
>
> Volker Simonis has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Remove assertions which insist on Lambda proxy classes being strongly linked to their class loader
>  - Removed unused import of STRONG und updated copyright year

I'd like to suggest maybe using another option for turning MethodHandles into interface instances, such as using `MethodHandleProxies` or just lambda expressions which capture the particular `MethodHandle`, which is an option if the target type of the functional interface is statically known:


MethodHandle mh = ...
TargetType instance = (Widget w) -> {
    try {
        return (SomeType) mh.invokeExact(w);
    } catch(Throwable t) {
        throw new RuntimeException(t); // or something more nuanced
    }
};


Most importantly, the above doesn't generate a new class every time, it generates just one. It can be slower in specific situations due to lack of inlining, but in the common use case it's not that bad (I've measure the extra hop through the method handle to be 4ns in the past in microbenchmarks). You could measure the impact for the particular app. (I guess the question is: do you _really_ want a new class to be generated for each MethodHandle?)

-------------

PR: https://git.openjdk.org/jdk/pull/12493

From alanb at openjdk.org  Wed Feb 22 15:22:04 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 22 Feb 2023 15:22:04 GMT
Subject: RFR: 8301119: Support for GB18030-2022
In-Reply-To: <FXBchbCnbNloQO7Nlh9Ijue_c_YugGk-UC7_-ZAjY2o=.7e1ca01f-8cee-40bb-bb06-6e5670abe661@github.com>
References: <FXBchbCnbNloQO7Nlh9Ijue_c_YugGk-UC7_-ZAjY2o=.7e1ca01f-8cee-40bb-bb06-6e5670abe661@github.com>
Message-ID: <TEAzveqaYCtriT9l0ikO71z2k7_mBhd5AD6s2t-YPyw=.253b065a-90f1-4f84-a7de-fdc71326d91d@github.com>

On Fri, 10 Feb 2023 20:35:58 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Upgrading the GB18030 charset in the JDK to the latest 2022 standard. Since this is not a compatible upgrade to the existing mapping, a new system property `jdk.charset.GB18030` is introduced. If it is set to "2000", the mapping falls back to the existing mapping based on the 2000 standard, otherwise, it defaults to 2022 mapping. Refer to the corresponding CSR for more detail.

Overall I think it looks very good, just StandardCharsets.isGB18030_2000 needs attention. Having GB18030 be in java.base in all builds, rather than everywhere except macOS, is okay and makes things a lot simpler.

-------------

PR: https://git.openjdk.org/jdk/pull/12518

From prappo at openjdk.org  Wed Feb 22 15:22:20 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Wed, 22 Feb 2023 15:22:20 GMT
Subject: RFR: 8302815 Use new Math.clamp method in core libraries [v3]
In-Reply-To: <x9AvETt9Izy_oPiBzHuTLn8ME5GHWkl-udew_-jjAW8=.c084c1fb-2495-4650-b789-b3fee360c502@github.com>
References: <k_xjmup3YSdUre0Z_XpO-WEBb5XED2FYv8UUZT2ULwc=.86f53f51-cceb-45fd-935d-b054c79a0526@github.com>
 <x9AvETt9Izy_oPiBzHuTLn8ME5GHWkl-udew_-jjAW8=.c084c1fb-2495-4650-b789-b3fee360c502@github.com>
Message-ID: <He-VgS2FvvHi-RPJtoeJpwVI-U6A_xkjLEGNGg0HRsI=.19cf5b10-85b5-49f9-b737-91b8b63b2fc5@github.com>

On Tue, 21 Feb 2023 20:39:53 GMT, Tagir F. Valeev <tvaleev at openjdk.org> wrote:

>> For cleanup and dogfooding the new method, it would be nice to use Math.clamp where possible in java.base. See PR #12428.
>> 
>> As Math.clamp performs an additional check that min is not greater than max, I conservatively replaced only those occurrences where I can see that this invariant is always held. There are more occurrences, where clamp can be potentially used but it's unclear whether min <= max is always true.
>
> Tagir F. Valeev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update copyright year

I only saw this PR after it has been integrated. A code location that immediately came to mind but was missing in the change is this java/util/concurrent/SubmissionPublisher.java:1273:

       public final void request(long n) {
            if (n > 0L) {
                for (;;) {
                    long p = demand, d = p + n;  // saturate
                    if (casDemand(p, d < p ? Long.MAX_VALUE : d))
                        break;
                }
                startOnSignal(RUN | ACTIVE | REQS);
            }
            else
                onError(new IllegalArgumentException(
                            "non-positive subscription request"));
        }

Seems like a poster child for the new Math.clamp functionality.

-------------

PR: https://git.openjdk.org/jdk/pull/12633

From rgiulietti at openjdk.org  Wed Feb 22 15:32:34 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Wed, 22 Feb 2023 15:32:34 GMT
Subject: RFR: 8302987: Add uniform and spatially equidistributed bounded
 float/double streams to RandomGenerator
Message-ID: <8B2_dePA34zyndM7SzuG6sanXNQmbge8DCIOIfpnTLs=.81cb4f5b-e3d0-4352-8209-eb1ac6197126@github.com>

The `default` method `nextDouble(double origin, double bound)` in `java.util.random.RandomGenerator` aims at generating a uniformly and spatially equidistributed random `double` in the left-closed and right-open range [`origin`, `bound`). It does so by applying the affine transform `origin + (bound - origin) * r` to a uniformly and spatially equidistributed random `double` `r` in the range [0, 1).

Since floating-point arithmetic suffers from small but noticeable rounding errors, this ends up slightly deforming the distribution of `r` when applying the affine transform.

-------------

Commit messages:
 - 8302987: Add uniform and spatially equidistributed bounded float/double streams to RandomGenerator

Changes: https://git.openjdk.org/jdk/pull/12719/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12719&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8302987
  Stats: 253 lines in 1 file changed: 251 ins; 1 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/12719.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12719/head:pull/12719

PR: https://git.openjdk.org/jdk/pull/12719

From rgiulietti at openjdk.org  Wed Feb 22 15:32:34 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Wed, 22 Feb 2023 15:32:34 GMT
Subject: RFR: 8302987: Add uniform and spatially equidistributed bounded
 float/double streams to RandomGenerator
In-Reply-To: <8B2_dePA34zyndM7SzuG6sanXNQmbge8DCIOIfpnTLs=.81cb4f5b-e3d0-4352-8209-eb1ac6197126@github.com>
References: <8B2_dePA34zyndM7SzuG6sanXNQmbge8DCIOIfpnTLs=.81cb4f5b-e3d0-4352-8209-eb1ac6197126@github.com>
Message-ID: <YWavB8Dg_kQ5c0QzUDvGwfJh0jQtBh-pXkqG_EDtcZM=.f50057d6-250d-4dd6-9bc3-e4bbfc8477a9@github.com>

On Wed, 22 Feb 2023 15:23:13 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

> The `default` method `nextDouble(double origin, double bound)` in `java.util.random.RandomGenerator` aims at generating a uniformly and spatially equidistributed random `double` in the left-closed and right-open range [`origin`, `bound`). It does so by applying the affine transform `origin + (bound - origin) * r` to a uniformly and spatially equidistributed random `double` `r` in the range [0, 1).
> 
> Since floating-point arithmetic suffers from small but noticeable rounding errors, this ends up slightly deforming the distribution of `r` when applying the affine transform.

The effect of rounding errors in the affine transform is analyzed in:
Goualard, "Drawing random floating-point numbers from an interval", ACM Transactions on Modeling and Computer Simulation, 2022, 32 (3) available [here] (https://hal.science/hal-03282794v4)

The code in this PR is inspired by that paper, although it proposes another implementation preserving uniformity and equidistribution.

-------------

PR: https://git.openjdk.org/jdk/pull/12719

From rgiulietti at openjdk.org  Wed Feb 22 15:35:21 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Wed, 22 Feb 2023 15:35:21 GMT
Subject: RFR: 8302987: Add uniform and spatially equidistributed bounded
 float/double streams to RandomGenerator
In-Reply-To: <8B2_dePA34zyndM7SzuG6sanXNQmbge8DCIOIfpnTLs=.81cb4f5b-e3d0-4352-8209-eb1ac6197126@github.com>
References: <8B2_dePA34zyndM7SzuG6sanXNQmbge8DCIOIfpnTLs=.81cb4f5b-e3d0-4352-8209-eb1ac6197126@github.com>
Message-ID: <t0d4sX4bRk7qObs-EkxfmBqhuxxO9ARAYBGZDi3QzPI=.61dee8a8-d361-45f6-af49-57d80180e8dd@github.com>

On Wed, 22 Feb 2023 15:23:13 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

> The `default` method `nextDouble(double origin, double bound)` in `java.util.random.RandomGenerator` aims at generating a uniformly and spatially equidistributed random `double` in the left-closed and right-open range [`origin`, `bound`). It does so by applying the affine transform `origin + (bound - origin) * r` to a uniformly and spatially equidistributed random `double` `r` in the range [0, 1).
> 
> Since floating-point arithmetic suffers from small but noticeable rounding errors, this ends up slightly deforming the distribution of `r` when applying the affine transform.

A similar implementation for `float`s will be added once this PR has elicited some interest and the algorithm has undergone a first review.

A CSR and tests will then be added as well.

-------------

PR: https://git.openjdk.org/jdk/pull/12719

From prappo at openjdk.org  Wed Feb 22 15:51:32 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Wed, 22 Feb 2023 15:51:32 GMT
Subject: RFR: 8302815 Use new Math.clamp method in core libraries [v3]
In-Reply-To: <x9AvETt9Izy_oPiBzHuTLn8ME5GHWkl-udew_-jjAW8=.c084c1fb-2495-4650-b789-b3fee360c502@github.com>
References: <k_xjmup3YSdUre0Z_XpO-WEBb5XED2FYv8UUZT2ULwc=.86f53f51-cceb-45fd-935d-b054c79a0526@github.com>
 <x9AvETt9Izy_oPiBzHuTLn8ME5GHWkl-udew_-jjAW8=.c084c1fb-2495-4650-b789-b3fee360c502@github.com>
Message-ID: <l_a3OOnnWIBEV5S43T_ZYSxD_uSEAt36wCBc0VG_v4M=.dbe3fc8b-95ce-431b-9bfd-d01ca815aa29@github.com>

On Tue, 21 Feb 2023 20:39:53 GMT, Tagir F. Valeev <tvaleev at openjdk.org> wrote:

>> For cleanup and dogfooding the new method, it would be nice to use Math.clamp where possible in java.base. See PR #12428.
>> 
>> As Math.clamp performs an additional check that min is not greater than max, I conservatively replaced only those occurrences where I can see that this invariant is always held. There are more occurrences, where clamp can be potentially used but it's unclear whether min <= max is always true.
>
> Tagir F. Valeev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update copyright year

On second thought, maybe not; Math.clamp might actually look more clumsy here. Scratch my previous comment.

-------------

PR: https://git.openjdk.org/jdk/pull/12633

From martin at openjdk.org  Wed Feb 22 16:13:19 2023
From: martin at openjdk.org (Martin Buchholz)
Date: Wed, 22 Feb 2023 16:13:19 GMT
Subject: RFR: 8302871: Speed up StringLatin1.regionMatchesCI [v7]
In-Reply-To: <f-Ox9ol_xiR5psYimcMLfJTDIHezxMiCoAd9OxW4pBI=.7169e0c8-a70f-45f7-9edd-8658b330aefc@github.com>
References: <dnsiX3nRffjGjZXJG7lMAZj2FktEl2Wc1XfFthQ4iJs=.8c41438a-80a4-468f-ae0b-7322c9d6d952@github.com>
 <AhNijA3f_Yl5Ornr9pqngR3yaepTQNEJeposarKW-Wg=.90a0b345-88dc-4648-a0fb-c83d1dd7e9d5@github.com>
 <hfJIZbrr5qSkn0BU1nyriYMyV9cFWN7e1iKHO-bvZks=.a829ef78-fe38-402a-877b-431591d23e15@github.com>
 <jUSHM1nTkwyjspO5Rn4h-OBQIsE62lvJZK7K-qhq3uI=.94ac5e1c-128e-4991-98d5-c202aa7d0610@github.com>
 <rXD4iIFMdlGyHf7E2a4O2Oz6iQmrItoFdp3pREh8yl0=.c407b886-9646-4a83-94a3-8f738e94ea06@github.com>
 <bYxNp9wXu0hHmU5U7L0AekEKt2hSBAhwpZbFePTlkRw=.8b96e631-82eb-4190-854a-88f3af25716b@github.com>
 <d4JliesOUX_SDPQOQrSFc2kaByJfA5vYFK-Sz7ij81Y=.ef887b72-d16b-499d-acca-d513a7ae7c6b@github.com>
 <PGdB8YD1ojFfu7vOE-mVz-HAz4JwKsC0bpw0s5DRXQU=.d048722a-63e8-456c-8d0f-749ed413c521@github.com>
 <JixGIkrtsQX2nya-qbWLfVf_MHOqWofpAsPcHCkpqRo=.842dafa9-84f2-49f2-8f71-f1a80b558a19@github.com>
 <f5OUHqyQBUqHQ4NJNK5tRyliXk7XoDMJEaevQvvwbtk=.dd9dd461-69e2-4153-a225-d20482277cd6@github.com>
 <wlKduCbkD5AhEIrqz_e-LlUM6ImLx8C1V7H
 Xlm86zDE=.6d3574c3-b738-4084-87cc-a5e578ab6144@github.com>
 <f-Ox9ol_xiR5psYimcMLfJTDIHezxMiCoAd9OxW4pBI=.7169e0c8-a70f-45f7-9edd-8658b330aefc@github.com>
Message-ID: <kQUjwQx49nXUAbkb9DPMqYt_tXXeY_Mj-xg11mq9MAo=.c213bbd8-ac1f-4dbc-92c2-07d74971d90d@github.com>

On Wed, 22 Feb 2023 07:12:35 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

>>> Do you have an opinion on the appropriate level of documentation / comments for this kind of 'tricky' code? 
>> 
>> This code is not that tricky!  And the proposed level of documentation is excessive!  A couple of lines of explanation and perhaps a link to an external document would be good.
>> 
>> It often happens to me that I will write such exhaustive notes for myself when learning a new technology.  A year later I pare it all back because much of it is "obvious in retrospect".
>
> Thanks Martin, David, Alan.  This was instructive (and fun!)
> 
> I suggest we condense the comment to something like this:
> 
> 
> // Uppercase b1 by removing a single bit
> int upper = b1 & 0xDF;
> if (upper < 'A') {
>     return false;  // Low ASCII
> }
> ...
> 
> 
> The similar methods `toLowerCase` `toUpperCase` just above have been updated to follow the same style. (I also updated local variable names there to align better with equalsIgnoreCase)

// ASCII and Latin-1 were designed to optimize case-twiddling operations

-------------

PR: https://git.openjdk.org/jdk/pull/12632

From alanb at openjdk.org  Wed Feb 22 16:17:11 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 22 Feb 2023 16:17:11 GMT
Subject: RFR: 8302899: Executors.newSingleThreadExecutor can use Cleaner to
 shutdown executor [v3]
In-Reply-To: <tBrSZRn1GdrWMSRUsdNNyAWpkuS_FvtLwLuUKut6LH0=.cd1a7fcb-dbcf-45eb-b3d3-72ba17087566@github.com>
References: <tBrSZRn1GdrWMSRUsdNNyAWpkuS_FvtLwLuUKut6LH0=.cd1a7fcb-dbcf-45eb-b3d3-72ba17087566@github.com>
Message-ID: <MaSioUrKP7eUCewEjsqWx4aaLQRieUYANatuYhSeZvE=.7f4b9f8e-b56e-4933-8292-dbb0907a4074@github.com>

> Executors.newSingleThreadExecutor returns a delegating ExecutorService that has finalizer to shutdown the underlying TPE when the wrapper is finalizable. It goes back to JDK 6 and JDK-6399443. This is the last non-empty finalizer in java.base. Removing it will likely lead to bug reports/complaints as the current behavior goes back to 2006. So the proposal is to just replace it with a Cleaner, trivially done in this case. As part of the changes, I've replaced the existing test with a more modern test that exercises more scenarios.

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 five additional commits since the last revision:

 - Keep reference to Cleanable
 - Merge
 - Fix typo in comment, remove blank line
 - Replace older test
 - Initial commit

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12675/files
  - new: https://git.openjdk.org/jdk/pull/12675/files/3bb4d0cd..3b135f09

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12675&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12675&range=01-02

  Stats: 2384 lines in 99 files changed: 1621 ins; 425 del; 338 mod
  Patch: https://git.openjdk.org/jdk/pull/12675.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12675/head:pull/12675

PR: https://git.openjdk.org/jdk/pull/12675

From alanb at openjdk.org  Wed Feb 22 16:17:14 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 22 Feb 2023 16:17:14 GMT
Subject: RFR: 8302899: Executors.newSingleThreadExecutor can use Cleaner to
 shutdown executor [v3]
In-Reply-To: <uQvBTGcKfjRpT4MSozobOPL1ohjTDptqycQD25fGq68=.9c89dfa7-4667-455c-bcca-3888aa94aa0e@github.com>
References: <tBrSZRn1GdrWMSRUsdNNyAWpkuS_FvtLwLuUKut6LH0=.cd1a7fcb-dbcf-45eb-b3d3-72ba17087566@github.com>
 <QuBbR3FKXmGzKKHgLzP0vj5UOZgOe6nU2DPiPv3KMYU=.3b33756f-0978-4925-aec2-d804ddab09df@github.com>
 <uQvBTGcKfjRpT4MSozobOPL1ohjTDptqycQD25fGq68=.9c89dfa7-4667-455c-bcca-3888aa94aa0e@github.com>
Message-ID: <eUl4hRP0CwCAxh25Iccw1sdErYqb_juUtM_lxPQOEiU=.b1619df3-a33b-4311-bb03-ca250aabee9f@github.com>

On Tue, 21 Feb 2023 19:38:08 GMT, Brent Christian <bchristi at openjdk.org> wrote:

>> Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
>> 
>>  - Keep reference to Cleanable
>>  - Merge
>>  - Fix typo in comment, remove blank line
>>  - Replace older test
>>  - Initial commit
>
> src/java.base/share/classes/java/util/concurrent/Executors.java line 837:
> 
>> 835:             implements ScheduledExecutorService {
>> 836:         private final ScheduledExecutorService e;
>> 837:         DelegatedScheduledExecutorService(ScheduledExecutorService executor) {
> 
> You might consider keeping a dedicated subclass ("CleanableDelegatedExecutorService"?). Such a class could save the Cleanable from Cleaner.register(), and override the shutdown() method to call Cleanable.clean(). This would reduce GC reference tracking, for instance in places where newSingleThreadExecutor() is used in a try-with-resources.

That might be better as that would clear the reference (so it won't be queued) when explicit shutdown (or closed). We do that in several places (as you know) at the cost of a reference to the Cleanable allowing "this" to escape during construction.

-------------

PR: https://git.openjdk.org/jdk/pull/12675

From duke at openjdk.org  Wed Feb 22 16:33:37 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Wed, 22 Feb 2023 16:33:37 GMT
Subject: RFR: 8302871: Speed up StringLatin1.regionMatchesCI [v11]
In-Reply-To: <dnsiX3nRffjGjZXJG7lMAZj2FktEl2Wc1XfFthQ4iJs=.8c41438a-80a4-468f-ae0b-7322c9d6d952@github.com>
References: <dnsiX3nRffjGjZXJG7lMAZj2FktEl2Wc1XfFthQ4iJs=.8c41438a-80a4-468f-ae0b-7322c9d6d952@github.com>
Message-ID: <sd7RuPZUgt7KggOg_OT5tUxW0Slo0CMfjOBQRfI844c=.1d611efc-7d48-4b61-a879-462a82f994ea@github.com>

> This PR suggests we can speed up `StringLatin1.regionMatchesCI` by applying 'the oldest ASCII trick in the book'.
> 
> The new static method `CharacterDataLatin1.equalsIgnoreCase` compares two latin1 bytes for equality ignoring case. `StringLatin1.regionMatchesCI` is updated to use `equalsIgnoreCase`
> 
> To verify the correctness of `equalsIgnoreCase`, a new test is added  to `EqualsIgnoreCase` with an exhaustive verification that all 256x256 latin1 code point pairs have an `equalsIgnoreCase` consistent with Character.toUpperCase, Character.toLowerCase.
> 
> Performance is tested for matching and mismatching cases of code point pairs picked from the ASCII letter, ASCII number and latin1 letter ranges. Results in the first comment below.

Eirik Bjorsnos has updated the pull request incrementally with one additional commit since the last revision:

  Use improved case-twiddling comment as suggested by Martin

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12632/files
  - new: https://git.openjdk.org/jdk/pull/12632/files/44d91544..ea2f9fa3

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12632&range=10
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12632&range=09-10

  Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/12632.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12632/head:pull/12632

PR: https://git.openjdk.org/jdk/pull/12632

From martin at openjdk.org  Wed Feb 22 16:33:39 2023
From: martin at openjdk.org (Martin Buchholz)
Date: Wed, 22 Feb 2023 16:33:39 GMT
Subject: RFR: 8302871: Speed up StringLatin1.regionMatchesCI [v10]
In-Reply-To: <Yt8f3DV2V3EHrO3B7A0x3KV1g-djrx94rVr8MPqeOYE=.1b03096f-c3da-4092-bb59-36d88c9d5036@github.com>
References: <dnsiX3nRffjGjZXJG7lMAZj2FktEl2Wc1XfFthQ4iJs=.8c41438a-80a4-468f-ae0b-7322c9d6d952@github.com>
 <Yt8f3DV2V3EHrO3B7A0x3KV1g-djrx94rVr8MPqeOYE=.1b03096f-c3da-4092-bb59-36d88c9d5036@github.com>
Message-ID: <ZwyELe_UasYsl4s-6aXe-p1_Wh7DotuAjf1gkoika8s=.d0834fea-1d55-4b77-a33f-09894208909e@github.com>

On Wed, 22 Feb 2023 07:11:16 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

>> This PR suggests we can speed up `StringLatin1.regionMatchesCI` by applying 'the oldest ASCII trick in the book'.
>> 
>> The new static method `CharacterDataLatin1.equalsIgnoreCase` compares two latin1 bytes for equality ignoring case. `StringLatin1.regionMatchesCI` is updated to use `equalsIgnoreCase`
>> 
>> To verify the correctness of `equalsIgnoreCase`, a new test is added  to `EqualsIgnoreCase` with an exhaustive verification that all 256x256 latin1 code point pairs have an `equalsIgnoreCase` consistent with Character.toUpperCase, Character.toLowerCase.
>> 
>> Performance is tested for matching and mismatching cases of code point pairs picked from the ASCII letter, ASCII number and latin1 letter ranges. Results in the first comment below.
>
> Eirik Bjorsnos has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Replace 'oldest ASCII trick in the book' use in toUpperCase, toLowerCase with "by removing (setting) a single bit"
>  - Align local variable naming in toLowerCase, toUpperCase with equalsIgnoreCase by using 'lower' and 'upper'

Marked as reviewed by martin (Reviewer).

test/jdk/java/lang/String/CompactString/EqualsIgnoreCase.java line 89:

> 87:         for (int ab = 0; ab < 256; ab++) {
> 88:             for (int bb = 0; bb < 256; bb++) {
> 89:                 char a = (char) ab, b = (char) bb;

char is an unsigned numeric type, so cleaner is

for (char a = 0; a < 256; a++) 
for (char b = 0; b < 256; b++)

-------------

PR: https://git.openjdk.org/jdk/pull/12632

From duke at openjdk.org  Wed Feb 22 16:33:43 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Wed, 22 Feb 2023 16:33:43 GMT
Subject: RFR: 8302871: Speed up StringLatin1.regionMatchesCI [v7]
In-Reply-To: <kQUjwQx49nXUAbkb9DPMqYt_tXXeY_Mj-xg11mq9MAo=.c213bbd8-ac1f-4dbc-92c2-07d74971d90d@github.com>
References: <dnsiX3nRffjGjZXJG7lMAZj2FktEl2Wc1XfFthQ4iJs=.8c41438a-80a4-468f-ae0b-7322c9d6d952@github.com>
 <AhNijA3f_Yl5Ornr9pqngR3yaepTQNEJeposarKW-Wg=.90a0b345-88dc-4648-a0fb-c83d1dd7e9d5@github.com>
 <hfJIZbrr5qSkn0BU1nyriYMyV9cFWN7e1iKHO-bvZks=.a829ef78-fe38-402a-877b-431591d23e15@github.com>
 <jUSHM1nTkwyjspO5Rn4h-OBQIsE62lvJZK7K-qhq3uI=.94ac5e1c-128e-4991-98d5-c202aa7d0610@github.com>
 <rXD4iIFMdlGyHf7E2a4O2Oz6iQmrItoFdp3pREh8yl0=.c407b886-9646-4a83-94a3-8f738e94ea06@github.com>
 <bYxNp9wXu0hHmU5U7L0AekEKt2hSBAhwpZbFePTlkRw=.8b96e631-82eb-4190-854a-88f3af25716b@github.com>
 <d4JliesOUX_SDPQOQrSFc2kaByJfA5vYFK-Sz7ij81Y=.ef887b72-d16b-499d-acca-d513a7ae7c6b@github.com>
 <PGdB8YD1ojFfu7vOE-mVz-HAz4JwKsC0bpw0s5DRXQU=.d048722a-63e8-456c-8d0f-749ed413c521@github.com>
 <JixGIkrtsQX2nya-qbWLfVf_MHOqWofpAsPcHCkpqRo=.842dafa9-84f2-49f2-8f71-f1a80b558a19@github.com>
 <f5OUHqyQBUqHQ4NJNK5tRyliXk7XoDMJEaevQvvwbtk=.dd9dd461-69e2-4153-a225-d20482277cd6@github.com>
 <wlKduCbkD5AhEIrqz_e-LlUM6ImLx8C1V7H
 Xlm86zDE=.6d3574c3-b738-4084-87cc-a5e578ab6144@github.com>
 <f-Ox9ol_xiR5psYimcMLfJTDIHezxMiCoAd9OxW4pBI=.7169e0c8-a70f-45f7-9edd-8658b330aefc@github.com>
 <kQUjwQx49nXUAbkb9DPMqYt_tXXeY_Mj-xg11mq9MAo=.c213bbd8-ac1f-4dbc-92c2-07d74971d90d@github.com>
Message-ID: <MBMpAbrifq2o4SdgfzX49odU9VxE25nfDShPIUthFUA=.ba07b8da-49d2-4d61-8ddb-f33f5592456e@github.com>

On Wed, 22 Feb 2023 16:10:42 GMT, Martin Buchholz <martin at openjdk.org> wrote:

>> Thanks Martin, David, Alan.  This was instructive (and fun!)
>> 
>> I suggest we condense the comment to something like this:
>> 
>> 
>> // Uppercase b1 by removing a single bit
>> int upper = b1 & 0xDF;
>> if (upper < 'A') {
>>     return false;  // Low ASCII
>> }
>> ...
>> 
>> 
>> The similar methods `toLowerCase` `toUpperCase` just above have been updated to follow the same style. (I also updated local variable names there to align better with equalsIgnoreCase)
>
> // ASCII and Latin-1 were designed to optimize case-twiddling operations

Thanks! This expresses the higher-level benefit succinctly, without getting into the details. I like it!

-------------

PR: https://git.openjdk.org/jdk/pull/12632

From duke at openjdk.org  Wed Feb 22 16:37:45 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Wed, 22 Feb 2023 16:37:45 GMT
Subject: RFR: 8302871: Speed up StringLatin1.regionMatchesCI [v12]
In-Reply-To: <dnsiX3nRffjGjZXJG7lMAZj2FktEl2Wc1XfFthQ4iJs=.8c41438a-80a4-468f-ae0b-7322c9d6d952@github.com>
References: <dnsiX3nRffjGjZXJG7lMAZj2FktEl2Wc1XfFthQ4iJs=.8c41438a-80a4-468f-ae0b-7322c9d6d952@github.com>
Message-ID: <B0NCYVR0qvImkfrktwxoisWCPVmcfJjHRSwes8bz5tY=.e24cca5b-207e-4ced-825d-af01d17b9116@github.com>

> This PR suggests we can speed up `StringLatin1.regionMatchesCI` by applying 'the oldest ASCII trick in the book'.
> 
> The new static method `CharacterDataLatin1.equalsIgnoreCase` compares two latin1 bytes for equality ignoring case. `StringLatin1.regionMatchesCI` is updated to use `equalsIgnoreCase`
> 
> To verify the correctness of `equalsIgnoreCase`, a new test is added  to `EqualsIgnoreCase` with an exhaustive verification that all 256x256 latin1 code point pairs have an `equalsIgnoreCase` consistent with Character.toUpperCase, Character.toLowerCase.
> 
> Performance is tested for matching and mismatching cases of code point pairs picked from the ASCII letter, ASCII number and latin1 letter ranges. Results in the first comment below.

Eirik Bjorsnos has updated the pull request incrementally with one additional commit since the last revision:

  Make the loop variables chars to avoid casting

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12632/files
  - new: https://git.openjdk.org/jdk/pull/12632/files/ea2f9fa3..cc185293

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12632&range=11
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12632&range=10-11

  Stats: 3 lines in 1 file changed: 0 ins; 1 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/12632.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12632/head:pull/12632

PR: https://git.openjdk.org/jdk/pull/12632

From duke at openjdk.org  Wed Feb 22 16:37:48 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Wed, 22 Feb 2023 16:37:48 GMT
Subject: RFR: 8302871: Speed up StringLatin1.regionMatchesCI [v10]
In-Reply-To: <ZwyELe_UasYsl4s-6aXe-p1_Wh7DotuAjf1gkoika8s=.d0834fea-1d55-4b77-a33f-09894208909e@github.com>
References: <dnsiX3nRffjGjZXJG7lMAZj2FktEl2Wc1XfFthQ4iJs=.8c41438a-80a4-468f-ae0b-7322c9d6d952@github.com>
 <Yt8f3DV2V3EHrO3B7A0x3KV1g-djrx94rVr8MPqeOYE=.1b03096f-c3da-4092-bb59-36d88c9d5036@github.com>
 <ZwyELe_UasYsl4s-6aXe-p1_Wh7DotuAjf1gkoika8s=.d0834fea-1d55-4b77-a33f-09894208909e@github.com>
Message-ID: <DKDvJbU1Z8MMQhFNBDQaREjyu-r93limVBhp6K9gkLA=.e12a473c-8ddb-4bb8-82cd-b5aa75926b02@github.com>

On Wed, 22 Feb 2023 16:25:41 GMT, Martin Buchholz <martin at openjdk.org> wrote:

>> Eirik Bjorsnos has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Replace 'oldest ASCII trick in the book' use in toUpperCase, toLowerCase with "by removing (setting) a single bit"
>>  - Align local variable naming in toLowerCase, toUpperCase with equalsIgnoreCase by using 'lower' and 'upper'
>
> test/jdk/java/lang/String/CompactString/EqualsIgnoreCase.java line 89:
> 
>> 87:         for (int ab = 0; ab < 256; ab++) {
>> 88:             for (int bb = 0; bb < 256; bb++) {
>> 89:                 char a = (char) ab, b = (char) bb;
> 
> char is an unsigned numeric type, so cleaner is
> 
> for (char a = 0; a < 256; a++) 
> for (char b = 0; b < 256; b++)

Thanks, fixed. Might have been copied over from processing of code points in the higher planes. Not needed here.

-------------

PR: https://git.openjdk.org/jdk/pull/12632

From briangoetz at openjdk.org  Wed Feb 22 16:42:59 2023
From: briangoetz at openjdk.org (Brian Goetz)
Date: Wed, 22 Feb 2023 16:42:59 GMT
Subject: RFR: 8292914: Drop the counter from lambda class names [v8]
In-Reply-To: <OVAs1Eg5Go4Rz1FBx9e8OSKn7EPJJlfAKFAQvPVhO7s=.ff6541be-db8d-4f44-8edc-10f3255d73f2@github.com>
References: <GgLfH-ueBQqT-Mfk1mKpKFAt8fYqyjfVJ9lmlsBsCbo=.8dd5b3b4-4e84-4970-9179-1c0399b30edc@github.com>
 <AdfREeJYVkF6HTsw669hMueQxdGXUXxYc4GetiDuoDk=.5124c8b8-3bea-4baa-bbb1-9383c84bb15f@github.com>
 <OVAs1Eg5Go4Rz1FBx9e8OSKn7EPJJlfAKFAQvPVhO7s=.ff6541be-db8d-4f44-8edc-10f3255d73f2@github.com>
Message-ID: <LBGzsDjtUc8NXOaNc87nnMPyc34ahbIHOoyX3yqD34c=.b66c1c87-52d5-4495-a5cd-5f0bd41329c7@github.com>

On Tue, 21 Feb 2023 19:08:30 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> David M. Lloyd has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Many tests have patterns for lambda class names; update them
>>  - Update comments and javadoc showin the old pattern
>
> Should this have a CSR for any observable behavioral changes?

@jddarcy The class name is effectively invisible (it's a hidden class) to ordinary code.  The classfile dumper is intended solely for debugging of the code generator itself and its behavior is unspecified.  So I would think that no CSR-able surface exists here.

-------------

PR: https://git.openjdk.org/jdk/pull/12579

From duke at openjdk.org  Wed Feb 22 16:43:02 2023
From: duke at openjdk.org (David M. Lloyd)
Date: Wed, 22 Feb 2023 16:43:02 GMT
Subject: RFR: 8292914: Drop the counter from lambda class names [v8]
In-Reply-To: <AdfREeJYVkF6HTsw669hMueQxdGXUXxYc4GetiDuoDk=.5124c8b8-3bea-4baa-bbb1-9383c84bb15f@github.com>
References: <GgLfH-ueBQqT-Mfk1mKpKFAt8fYqyjfVJ9lmlsBsCbo=.8dd5b3b4-4e84-4970-9179-1c0399b30edc@github.com>
 <AdfREeJYVkF6HTsw669hMueQxdGXUXxYc4GetiDuoDk=.5124c8b8-3bea-4baa-bbb1-9383c84bb15f@github.com>
Message-ID: <zqMC9xu2wx3w4OLoQg8GsbA7kwNojT4ezvtPaYjfDjE=.828d10f8-9107-49d5-a822-aec5b2832455@github.com>

On Fri, 17 Feb 2023 19:37:59 GMT, David M. Lloyd <duke at openjdk.org> wrote:

>> The class generated for lambda proxies is now defined as a hidden class. This means that the counter, which was used to ensure a unique class name and avoid clashes, is now redundant. In addition to performing redundant work, this also impacts build reproducibility for native image generators which might already have a strategy to cope with hidden classes but cannot cope with indeterminate definition order for lambda proxy classes.
>> 
>> This solves JDK-8292914 by making lambda proxy names always be stable without any configuration needed. This would also replace #10024.
>
> David M. Lloyd has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Many tests have patterns for lambda class names; update them
>  - Update comments and javadoc showin the old pattern

Could I please trouble someone for a review?

-------------

PR: https://git.openjdk.org/jdk/pull/12579

From mchung at openjdk.org  Wed Feb 22 16:57:31 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Wed, 22 Feb 2023 16:57:31 GMT
Subject: RFR: 8292914: Drop the counter from lambda class names [v8]
In-Reply-To: <AdfREeJYVkF6HTsw669hMueQxdGXUXxYc4GetiDuoDk=.5124c8b8-3bea-4baa-bbb1-9383c84bb15f@github.com>
References: <GgLfH-ueBQqT-Mfk1mKpKFAt8fYqyjfVJ9lmlsBsCbo=.8dd5b3b4-4e84-4970-9179-1c0399b30edc@github.com>
 <AdfREeJYVkF6HTsw669hMueQxdGXUXxYc4GetiDuoDk=.5124c8b8-3bea-4baa-bbb1-9383c84bb15f@github.com>
Message-ID: <S_jJtHB8U7QBPQoc2omvVOkJ8nTpwI2RPn8awWFp56o=.bf3924cd-5115-4144-b754-e290173b6880@github.com>

On Fri, 17 Feb 2023 19:37:59 GMT, David M. Lloyd <duke at openjdk.org> wrote:

>> The class generated for lambda proxies is now defined as a hidden class. This means that the counter, which was used to ensure a unique class name and avoid clashes, is now redundant. In addition to performing redundant work, this also impacts build reproducibility for native image generators which might already have a strategy to cope with hidden classes but cannot cope with indeterminate definition order for lambda proxy classes.
>> 
>> This solves JDK-8292914 by making lambda proxy names always be stable without any configuration needed. This would also replace #10024.
>
> David M. Lloyd has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Many tests have patterns for lambda class names; update them
>  - Update comments and javadoc showin the old pattern

I'm on vacation.  I'll review later this week.

-------------

PR: https://git.openjdk.org/jdk/pull/12579

From mchung at openjdk.org  Wed Feb 22 17:00:49 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Wed, 22 Feb 2023 17:00:49 GMT
Subject: RFR: 8302667: Improve message format when failing to load symbols
 or libraries [v3]
In-Reply-To: <vW57drxW79eNR9cscDHmXI9El9VHDF_LJRBec9f9rec=.2c66ee11-b0b5-4691-88ed-2337509cc2e1@github.com>
References: <tu4ol4DO1PeplhgjhkYpXLwES142ztBXsM43uQO_CNE=.bfca85a4-2323-487d-9261-964671e00bf3@github.com>
 <vW57drxW79eNR9cscDHmXI9El9VHDF_LJRBec9f9rec=.2c66ee11-b0b5-4691-88ed-2337509cc2e1@github.com>
Message-ID: <1k3a4hmHCfKOQC_B-pKEhTwoRM4lQ21rcEgnyMC-5FQ=.375427a9-3b6d-40e2-90fe-085ded39b1d2@github.com>

On Tue, 21 Feb 2023 17:14:57 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> DLL_ERROR4 is a macro expanding to an error message when a failure to load a generic item (shared libraries or an exported symbol from said libraries for example) occurs. "Error: loading:" is not a very pretty message, so this small change results in "Error: Failed to load %s" instead, which looks better and also means the message makes more sense if we want to append a reason behind as well, such as "Error: Failed to load libjvm.so because xxx"
>
> Julian Waters has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - expandArgFile
>  - ARG_ERROR18

Thanks in making the change.

src/java.base/share/native/libjli/emessages.h line 60:

> 58: #define ARG_ERROR16     "Error: Option %s in %s is not allowed in this context"
> 59: #define ARG_ERROR17     "Error: Cannot specify main class in this context"
> 60: #define ARG_ERROR18     "Error: Could not read %s"

Suggestion:

#define ARG_ERROR18     "Error: Failed to read %s"

-------------

Marked as reviewed by mchung (Reviewer).

PR: https://git.openjdk.org/jdk/pull/12596

From jvernee at openjdk.org  Wed Feb 22 17:05:49 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Wed, 22 Feb 2023 17:05:49 GMT
Subject: RFR: 8303040: linux PPC64le: Implementation of Foreign Function &
 Memory API (Preview)
In-Reply-To: <Yuxy6FrsDAN79ya8w8UIkvytGr25zGllDPtPJ1QbGwc=.182664b2-6d8c-497e-a4ae-95e0ad007cf9@github.com>
References: <Yuxy6FrsDAN79ya8w8UIkvytGr25zGllDPtPJ1QbGwc=.182664b2-6d8c-497e-a4ae-95e0ad007cf9@github.com>
Message-ID: <GhLt8kfe9xOv5TKExx7dncFwLcXPw4uiwfntbmhY2Yg=.f8f36141-9a19-44b3-b10f-977d3e02c4af@github.com>

On Wed, 22 Feb 2023 05:31:46 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

> Implementation of "Foreign Function & Memory API" for linux on Power (Little Endian) according to "Power Architecture 64-Bit ELF V2 ABI Specification".
> 
> This PR does not include code for VaList support because it's supposed to get removed by [JDK-8299736](https://bugs.openjdk.org/browse/JDK-8299736). I've kept the related tests disabled for this platform and throw an exception instead. Note that the ABI doesn't precisely specify variable argument lists. Instead, it refers to `<stdarg.h>` (2.2.4 Variable Argument Lists).
> 
> Big Endian support is implemented to some extend, but not complete. E.g. structs with size not divisible by 8 are not passed correctly (see `useABIv2` in CallArranger.java). Big Endian is excluded by selecting `ARCH.equals("ppc64le")` (CABI.java) only.
> 
> There's another limitation: This PR only accepts structures with size divisible by 4. (An `IllegalArgumentException` gets thrown otherwise.) I think arbitrary sizes are not usable on other platforms, either, because `SharedUtils.primitiveCarrierForSize` only accepts powers of 2.
> 
> The ABI has some tricky corner cases related to HFA (Homogeneous Float Aggregate). The same argument may need to get passed in both, a FP reg and a GP reg or stack slot (see "no partial DW rule"). This cases are not covered by the existing tests.
> 
> I had to make changes to shared code and code for other platforms:
> 1. Pass type information when creating `VMStorage` objects from `VMReg`. This is needed for the following reasons:
> - PPC64 ABI requires integer types to get extended to 64 bit (also see CCallingConventionRequiresIntsAsLongs in existing hotspot code). We need to know the type or at least the bit width for that.
> - Floating point load / store instructions need the correct width to select between the correct IEEE 754 formats. The register representation in single FP registers is always IEEE 754 double precision on PPC64.
> - Big Endian also needs usage of the precise size. Storing 8 Bytes and loading 4 Bytes yields different values than on Little Endian!
> 2. It happens that a `NativeMemorySegmentImpl` is used as a raw pointer (with byteSize() == 0) while running TestUpcallScope. Hence, existing size checks don't work (see MemorySegment.java). As a workaround, I'm just skipping the check in this particular case. Please check if this makes sense or if there's a better fix (possibly as separate RFE).

I will do a more thorough review soon.

Some preliminary comments:

> The ABI has some tricky corner cases related to HFA (Homogeneous Float Aggregate). The same argument may need to get passed in both, a FP reg and a GP reg or stack slot (see "no partial DW rule"). This cases are not covered by the existing tests.

FWIW, we have to do this for Windows vararg floats as well ([here](https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/jdk/internal/foreign/abi/x64/windows/CallArranger.java#L231-L239))

This can be done by `dup`-ing the value, and using 2 `vmStore`s. (each `vmStore` corresponding to a single register/stack location). Doing something similar might be simpler than the `INTEGER_AND_FLOAT` and `STACK_AND_FLOAT` storage types you're using right now. I'm not sure if that is related to the other limitations you mention? Might be interesting to look into. (perhaps as a separate RFE. I don't have a big issue since the current approach stays in PPC-only code)

> I had to make changes to shared code and code for other platforms:
> 
>     1. Pass type information when creating `VMStorage` objects from `VMReg`. This is needed for the following reasons:
> 
> 
>     * PPC64 ABI requires integer types to get extended to 64 bit (also see CCallingConventionRequiresIntsAsLongs in existing hotspot code). We need to know the type or at least the bit width for that.
> 
>     * Floating point load / store instructions need the correct width to select between the correct IEEE 754 formats. The register representation in single FP registers is always IEEE 754 double precision on PPC64.
> 
>     * Big Endian also needs usage of the precise size. Storing 8 Bytes and loading 4 Bytes yields different values than on Little Endian!

I think supplying the `BasicType` is fine. `VMReg` doesn't have any width information attached to it, and that's why a complementary `BasicType` is needed. I'm glad to see that you could make it work with the register masks for `VMStorage` :)

WRT the extension of int -> long. This could potentially also be handled in Java by adding the conversion as a `Cast` binding variant, and then adding the widening casts in `CallArranger`. (I'd be happy to implement the needed changes in shared code if you want, since it touches `BindingSpecializer` which is pretty dense). Since the extension seems to be a figment of the C ABI, that could be preferable, since it has the benefit of the VM code staying ABI-agnostic. This is potentially important if we want to add other ABIs in the future. But, we can also cross that bridge when we get to it (and there are probably more bridges to cross in that case too). So, up to you, really. (It's similar to the discussion surrounding floats for RISCV, if you followed that)

>     2. It happens that a `NativeMemorySegmentImpl` is used as a raw pointer (with byteSize() == 0) while running TestUpcallScope. Hence, existing size checks don't work (see MemorySegment.java). As a workaround, I'm just skipping the check in this particular case. Please check if this makes sense or if there's a better fix (possibly as separate RFE).

Zero-length memory segments are supposed to be resized before they are written to or read from (see [Zero-length memory segments](https://download.java.net/java/early_access/jdk20/docs/api/java.base/java/lang/foreign/MemorySegment.html#wrapping-addresses)). We shouldn't disable the check for them, as that would have far-reaching implications for the safety design of the memory access API.

Can you explain a bit more about where/why/how the issue occurs?

-------------

PR: https://git.openjdk.org/jdk/pull/12708

From duke at openjdk.org  Wed Feb 22 17:08:10 2023
From: duke at openjdk.org (Kasper Nielsen)
Date: Wed, 22 Feb 2023 17:08:10 GMT
Subject: RFR: 8302154: Hidden classes created by LambdaMetaFactory can't be
 unloaded [v2]
In-Reply-To: <gKoLpwlXDxp2uaSKSkMArJl1Ym9VX1hoDFqQTTUpk8w=.e1dce669-5a42-4b66-ac4b-205718c8eb81@github.com>
References: <YoZauVv8zvhdUw-LD25LrsMDItFbg3aXPU3deXwwFdQ=.c2839dea-12e5-4e0e-9579-eac9d8503932@github.com>
 <gKoLpwlXDxp2uaSKSkMArJl1Ym9VX1hoDFqQTTUpk8w=.e1dce669-5a42-4b66-ac4b-205718c8eb81@github.com>
Message-ID: <0ZZLsRlr6IO4jL2VKAcn4geYptqUOdYPUXbd-KQiApo=.d1b3ca63-ca4a-4eef-9d5e-88cc3418ada9@github.com>

On Thu, 9 Feb 2023 18:11:18 GMT, Volker Simonis <simonis at openjdk.org> wrote:

>> Prior to [JDK-8239384](https://bugs.openjdk.org/browse/JDK-8239384)/[JDK-8238358](https://bugs.openjdk.org/browse/JDK-8238358) LambdaMetaFactory has created VM-anonymous classes which could easily be unloaded once they were not referenced any more. Starting with JDK 15 and the new "hidden class" based implementation, this is not the case any more, because the hidden classes will be strongly tied to their defining class loader. If this is the default application class loader, these hidden classes can never be unloaded which can easily lead to Metaspace exhaustion (see the [test case in the JBS issue](https://bugs.openjdk.org/secure/attachment/102601/LambdaClassLeak.java)). This is a regression compared to previous JDK versions which some of our applications have been affected from when migrating to JDK 17.
>> 
>> The reason why the newly created hidden classes are strongly linked to their defining class loader is not clear to me. JDK-8239384 mentions it as an "implementation detail":
>> 
>>> *4. the lambda proxy class has the strong relationship with the class loader (that will share the VM metaspace for its defining loader - implementation details)*
>> 
>> From my current understanding the strong link between a hidden class created by `LambdaMetaFactory` and its defining class loader is not strictly required. In order to prevent potential OOMs and fix the regression compared the JDK 14 and earlier I propose to create these hidden classes without the `STRONG` option.
>> 
>> I'll be happy to add the test case as JTreg test to this PR if you think that would be useful.
>
> Volker Simonis has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Remove assertions which insist on Lambda proxy classes being strongly linked to their class loader
>  - Removed unused import of STRONG und updated copyright year

In all the places I've seen LambdaMetaFactory used, it is because of performance over reflection/non-static method handles. See, for example, https://www.optaplanner.org/blog/2018/01/09/JavaReflectionButMuchFaster.html. I believe Optaplanner is still using it.

There is also quite a number of posts on StackOverflow on people trying to use LambdaMetafactory:
https://stackoverflow.com/search?q=LambdaMetafactory

-------------

PR: https://git.openjdk.org/jdk/pull/12493

From dfuchs at openjdk.org  Wed Feb 22 17:23:08 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 22 Feb 2023 17:23:08 GMT
Subject: RFR: 8302899: Executors.newSingleThreadExecutor can use Cleaner to
 shutdown executor [v3]
In-Reply-To: <MaSioUrKP7eUCewEjsqWx4aaLQRieUYANatuYhSeZvE=.7f4b9f8e-b56e-4933-8292-dbb0907a4074@github.com>
References: <tBrSZRn1GdrWMSRUsdNNyAWpkuS_FvtLwLuUKut6LH0=.cd1a7fcb-dbcf-45eb-b3d3-72ba17087566@github.com>
 <MaSioUrKP7eUCewEjsqWx4aaLQRieUYANatuYhSeZvE=.7f4b9f8e-b56e-4933-8292-dbb0907a4074@github.com>
Message-ID: <xuuT67OjyS-RuT8vDkHjRk8b3ExQ1cEa0x6g_avFY7A=.b149b67b-e9bd-405f-aeb5-6c062a0a2486@github.com>

On Wed, 22 Feb 2023 16:17:11 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Executors.newSingleThreadExecutor returns a delegating ExecutorService that has finalizer to shutdown the underlying TPE when the wrapper is finalizable. It goes back to JDK 6 and JDK-6399443. This is the last non-empty finalizer in java.base. Removing it will likely lead to bug reports/complaints as the current behavior goes back to 2006. So the proposal is to just replace it with a Cleaner, trivially done in this case. As part of the changes, I've replaced the existing test with a more modern test that exercises more scenarios.
>
> 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 five additional commits since the last revision:
> 
>  - Keep reference to Cleanable
>  - Merge
>  - Fix typo in comment, remove blank line
>  - Replace older test
>  - Initial commit

src/java.base/share/classes/java/util/concurrent/Executors.java line 844:

> 842:         @Override
> 843:         public void shutdown() {
> 844:             cleaner.clean();

Hmmm... so now shutdown no longer requires permission. You should probably call super.shutdown() before invoking cleaner.clean(), assuming that shutdown() can be called twice.

-------------

PR: https://git.openjdk.org/jdk/pull/12675

From jvernee at openjdk.org  Wed Feb 22 17:38:55 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Wed, 22 Feb 2023 17:38:55 GMT
Subject: RFR: 8303040: linux PPC64le: Implementation of Foreign Function &
 Memory API (Preview)
In-Reply-To: <GhLt8kfe9xOv5TKExx7dncFwLcXPw4uiwfntbmhY2Yg=.f8f36141-9a19-44b3-b10f-977d3e02c4af@github.com>
References: <Yuxy6FrsDAN79ya8w8UIkvytGr25zGllDPtPJ1QbGwc=.182664b2-6d8c-497e-a4ae-95e0ad007cf9@github.com>
 <GhLt8kfe9xOv5TKExx7dncFwLcXPw4uiwfntbmhY2Yg=.f8f36141-9a19-44b3-b10f-977d3e02c4af@github.com>
Message-ID: <y2p-CbSj9SbHEDucU_oj1oEGq4cA0HO5MbLChaSUdwo=.11c6fa04-b648-4f36-8058-ea0ea64f135d@github.com>

On Wed, 22 Feb 2023 17:03:16 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

> (I'd be happy to implement the needed changes in shared code if you want, since it touches `BindingSpecializer` which is pretty dense)

FYI: https://github.com/openjdk/jdk/compare/master...JornVernee:jdk:I2L (assuming `I2L` has the same semantics as `extsw`). Then just add a `.cast(int.class, long.class)` wherever an `int` is stored.

-------------

PR: https://git.openjdk.org/jdk/pull/12708

From enikitin at openjdk.org  Wed Feb 22 17:43:23 2023
From: enikitin at openjdk.org (Evgeny Nikitin)
Date: Wed, 22 Feb 2023 17:43:23 GMT
Subject: RFR: 8302267: [jittester] Improve separation of test generation
 and execution [v2]
In-Reply-To: <yHw6Lto-nJtPP61cZLDF354osHA-ioeq7_lgpefLvog=.6de22e18-0613-4ffb-a753-b66b95e9d52b@github.com>
References: <yHw6Lto-nJtPP61cZLDF354osHA-ioeq7_lgpefLvog=.6de22e18-0613-4ffb-a753-b66b95e9d52b@github.com>
Message-ID: <HPYLuHpPdXMDXg2kEtUdEDf1FxkfvLwRRomQtM7oybQ=.726d67e9-f4c0-4aa9-98ff-76d89ddf8034@github.com>

> Please review a set of improvements that should improve working with other fuzzing generators and usage of JitTesterDriver with tests generated not by the JITTester:
> 
> - Provide better separation of individual test generation from java file writing, compiling, executing, etc.;
> - Introduce distinct Phases of the generation process (Generation, Compilation, GoldRun and VerificationRun);
> - Extract JItTesterDriver headers generation so that it would be possible to provide other header generators;
> - Introduce error tolerance to not get distracted by OOMEs, intrinsics missing in the compiled code, etc.;
> - Make it possible to specify time limit for an individual test generation;
> - Give better control over temp/workdir creation and cleaning;
> - Unify external process running;
> - Introduce UTF-8 support in external processes' output and human-readable escaping of it;

Evgeny Nikitin has updated the pull request incrementally with one additional commit since the last revision:

  Ignore large files

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12527/files
  - new: https://git.openjdk.org/jdk/pull/12527/files/417e05d7..0d1543a7

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12527&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12527&range=00-01

  Stats: 98 lines in 5 files changed: 77 ins; 8 del; 13 mod
  Patch: https://git.openjdk.org/jdk/pull/12527.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12527/head:pull/12527

PR: https://git.openjdk.org/jdk/pull/12527

From jwaters at openjdk.org  Wed Feb 22 18:05:09 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Wed, 22 Feb 2023 18:05:09 GMT
Subject: RFR: 8302667: Improve message format when failing to load symbols
 or libraries [v4]
In-Reply-To: <tu4ol4DO1PeplhgjhkYpXLwES142ztBXsM43uQO_CNE=.bfca85a4-2323-487d-9261-964671e00bf3@github.com>
References: <tu4ol4DO1PeplhgjhkYpXLwES142ztBXsM43uQO_CNE=.bfca85a4-2323-487d-9261-964671e00bf3@github.com>
Message-ID: <JtpHEXudwIhvzdcXb_ZoTuBnud5VT6KsA2e8tL57rjU=.6c870b51-e843-4962-8a6b-b05480eb3f50@github.com>

> DLL_ERROR4 is a macro expanding to an error message when a failure to load a generic item (shared libraries or an exported symbol from said libraries for example) occurs. "Error: loading:" is not a very pretty message, so this small change results in "Error: Failed to load %s" instead, which looks better and also means the message makes more sense if we want to append a reason behind as well, such as "Error: Failed to load libjvm.so because xxx"

Julian Waters has updated the pull request incrementally with one additional commit since the last revision:

  src/java.base/share/native/libjli/emessages.h
  
  Co-authored-by: Mandy Chung <mandy.chung at oracle.com>

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12596/files
  - new: https://git.openjdk.org/jdk/pull/12596/files/6b54816a..d923ef45

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12596&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12596&range=02-03

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/12596.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12596/head:pull/12596

PR: https://git.openjdk.org/jdk/pull/12596

From jwaters at openjdk.org  Wed Feb 22 18:05:34 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Wed, 22 Feb 2023 18:05:34 GMT
Subject: RFR: 8302667: Improve message format when failing to load symbols
 or libraries [v2]
In-Reply-To: <5HI98VM_T336GbG8atm-0-Vuf9tqbVR9nIFGghIsdE8=.42476df6-adaf-4055-8619-c984954a7c92@github.com>
References: <tu4ol4DO1PeplhgjhkYpXLwES142ztBXsM43uQO_CNE=.bfca85a4-2323-487d-9261-964671e00bf3@github.com>
 <B-eIiBotI3cwCwWY5r2xYPlHfnV4dKJIHJdwg-hbDeQ=.ff83dbdf-e456-48b7-aa7f-e8cf75f71b5a@github.com>
 <5HI98VM_T336GbG8atm-0-Vuf9tqbVR9nIFGghIsdE8=.42476df6-adaf-4055-8619-c984954a7c92@github.com>
Message-ID: <PVW6n4huzR19n9etIfmoeOb4aAIKoRFWRq167edkTBc=.4d894633-248e-478d-9591-08bcfe39849d@github.com>

On Tue, 21 Feb 2023 16:59:18 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> Julian Waters 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 'openjdk:master' into patch-6
>>  - Error: Failed to load
>
> What about:
> 
> 
> #define ARG_ERROR18      "Error: reading %s"

@mlchung Thanks for the review! :)

-------------

PR: https://git.openjdk.org/jdk/pull/12596

From jwaters at openjdk.org  Wed Feb 22 18:05:48 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Wed, 22 Feb 2023 18:05:48 GMT
Subject: Integrated: 8302667: Improve message format when failing to load
 symbols or libraries
In-Reply-To: <tu4ol4DO1PeplhgjhkYpXLwES142ztBXsM43uQO_CNE=.bfca85a4-2323-487d-9261-964671e00bf3@github.com>
References: <tu4ol4DO1PeplhgjhkYpXLwES142ztBXsM43uQO_CNE=.bfca85a4-2323-487d-9261-964671e00bf3@github.com>
Message-ID: <lnib-dJNlZzUDoIT8O5AL-buz3mplQJTJog7PSHExqo=.2c05df41-cb27-486f-ae32-9ca32b6b4e22@github.com>

On Thu, 16 Feb 2023 15:02:38 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> DLL_ERROR4 is a macro expanding to an error message when a failure to load a generic item (shared libraries or an exported symbol from said libraries for example) occurs. "Error: loading:" is not a very pretty message, so this small change results in "Error: Failed to load %s" instead, which looks better and also means the message makes more sense if we want to append a reason behind as well, such as "Error: Failed to load libjvm.so because xxx"

This pull request has now been integrated.

Changeset: 8de841dd
Author:    Julian Waters <jwaters at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/8de841dd19a77f9ff6273a74366c08f33e0cac94
Stats:     3 lines in 2 files changed: 1 ins; 0 del; 2 mod

8302667: Improve message format when failing to load symbols or libraries

Reviewed-by: mchung

-------------

PR: https://git.openjdk.org/jdk/pull/12596

From sviswanathan at openjdk.org  Wed Feb 22 18:19:57 2023
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Wed, 22 Feb 2023 18:19:57 GMT
Subject: RFR: 8302976: C2 intrinsification of Float.floatToFloat16 and
 Float.float16ToFloat yields different result than the interpreter
In-Reply-To: <nzUBOq3a8MVvd4EmIiPb95fr3JwBnUi1f1SGxWT2UBw=.d715b6e1-aba5-4448-be15-0cb418cc1084@github.com>
References: <f18TfSibBBm5FLon1VlUN0m6fNUzvOpsUeo7nEAk7JY=.456ddc51-7be7-4484-ad38-1039453b83d6@github.com>
 <nzUBOq3a8MVvd4EmIiPb95fr3JwBnUi1f1SGxWT2UBw=.d715b6e1-aba5-4448-be15-0cb418cc1084@github.com>
Message-ID: <JX0R1o-u4H3mPMhbwM1Pq8WrUhHfmaw9qCESvgTbfTE=.76b1ffa9-9bae-466d-b497-0eaf2079cb49@github.com>

On Wed, 22 Feb 2023 04:03:02 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Change the java/lang/float.java and the corresponding shared runtime constant expression evaluation to generate QNaN.
>> The HW instructions generate QNaNs and not SNaNs for floating point instructions. This happens across double, float, and float16 data types. The most significant bit of mantissa is set to 1 for QNaNs.
>
> I'm also a bit concerned that we are rushing in to "fix" this. IIUC we have three mechanisms for implementing this functionality:
> 
> 1. The interpreted Java code
> 2. The compiled non-intrinisc sharedRuntime code
> 3. The compiler intrinsic that uses a hardware instruction.
> 
> Unless the hardware instructions for all relevant CPUs behave exactly the same, then I don't see how we can have parity of behaviour across these three mechanisms.
> 
> The observed behaviour may be surprising but it seems not to be a bug. And is this even a real concern - would real programs actually need to peek at the raw bits and so see the difference, or does it suffice to handle Nan's opaquely?

@dholmes-ora @jddarcy @TobiHartmann @vnkozlov   From @dean-long 's comment in the JBS entry, he sees the same result on AARCH64 and Intel, i.e. the output has the QNaN bit set.
Please let me know if we want to proceed with this PR or if it would be good to withdraw this. I am open to either suggestion. Please advice.

-------------

PR: https://git.openjdk.org/jdk/pull/12704

From alanb at openjdk.org  Wed Feb 22 18:20:19 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 22 Feb 2023 18:20:19 GMT
Subject: RFR: 8302899: Executors.newSingleThreadExecutor can use Cleaner to
 shutdown executor [v3]
In-Reply-To: <xuuT67OjyS-RuT8vDkHjRk8b3ExQ1cEa0x6g_avFY7A=.b149b67b-e9bd-405f-aeb5-6c062a0a2486@github.com>
References: <tBrSZRn1GdrWMSRUsdNNyAWpkuS_FvtLwLuUKut6LH0=.cd1a7fcb-dbcf-45eb-b3d3-72ba17087566@github.com>
 <MaSioUrKP7eUCewEjsqWx4aaLQRieUYANatuYhSeZvE=.7f4b9f8e-b56e-4933-8292-dbb0907a4074@github.com>
 <xuuT67OjyS-RuT8vDkHjRk8b3ExQ1cEa0x6g_avFY7A=.b149b67b-e9bd-405f-aeb5-6c062a0a2486@github.com>
Message-ID: <wPxOjT0C81bf2d9f9cZfSBY25mrRUqNFwioDHHA0uNw=.8fd08b6e-0edf-418f-b083-c3fe67caab30@github.com>

On Wed, 22 Feb 2023 17:20:21 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> Hmmm... so now shutdown no longer requires permission. You should probably call super.shutdown() before invoking cleaner.clean(), assuming that shutdown() can be called twice. You could modify the cleanup action to only call shutdown() if isShutdown() returns false.

That's right. It will be a non-issue once the SM goes away but while that execution mode is supported then the shutdown method and the cleaner action have to be different (as it was initially).

-------------

PR: https://git.openjdk.org/jdk/pull/12675

From naoto at openjdk.org  Wed Feb 22 18:22:33 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 22 Feb 2023 18:22:33 GMT
Subject: RFR: 8301119: Support for GB18030-2022 [v2]
In-Reply-To: <FXBchbCnbNloQO7Nlh9Ijue_c_YugGk-UC7_-ZAjY2o=.7e1ca01f-8cee-40bb-bb06-6e5670abe661@github.com>
References: <FXBchbCnbNloQO7Nlh9Ijue_c_YugGk-UC7_-ZAjY2o=.7e1ca01f-8cee-40bb-bb06-6e5670abe661@github.com>
Message-ID: <zjw9cgUgI3rGDV9gW7xcpCuSpDeBi10TK7AZoSjP970=.81f3937a-b471-4bf7-8bc5-ebaf0c9f0ae7@github.com>

> Upgrading the GB18030 charset in the JDK to the latest 2022 standard. Since this is not a compatible upgrade to the existing mapping, a new system property `jdk.charset.GB18030` is introduced. If it is set to "2000", the mapping falls back to the existing mapping based on the 2000 standard, otherwise, it defaults to 2022 mapping. Refer to the corresponding CSR for more detail.

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 16 additional commits since the last revision:

 - Add @Stable annotation
 - Merge branch 'master' into JDK-8301119-GB18030-2022
 - Check initPhase and don't call System.getProperty if in phase 1
 - Some clean-up
 - Some more fixes
 - removed unnecessary method name composition
 - Removed unnecessary imports
 - aliases fix
 - Move GB18030 into standard charsets provider
 - indentation
 - ... and 6 more: https://git.openjdk.org/jdk/compare/0981ec17...b5379b69

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12518/files
  - new: https://git.openjdk.org/jdk/pull/12518/files/0f3c25ce..b5379b69

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12518&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12518&range=00-01

  Stats: 8209 lines in 333 files changed: 4912 ins; 1488 del; 1809 mod
  Patch: https://git.openjdk.org/jdk/pull/12518.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12518/head:pull/12518

PR: https://git.openjdk.org/jdk/pull/12518

From naoto at openjdk.org  Wed Feb 22 18:22:41 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 22 Feb 2023 18:22:41 GMT
Subject: RFR: 8301119: Support for GB18030-2022 [v2]
In-Reply-To: <Fo1WnNOBMptjHkVUUtdvx4p03Ci1ljacM9bkFux2Qus=.b8082d30-35e9-491e-88a0-d00105f4381b@github.com>
References: <FXBchbCnbNloQO7Nlh9Ijue_c_YugGk-UC7_-ZAjY2o=.7e1ca01f-8cee-40bb-bb06-6e5670abe661@github.com>
 <S6p8hZiWOrDpXAzaeJ3L4kOIferQtFHKmFaa_1gNTyo=.0a245135-1bf9-47a1-b992-36edcbc2d612@github.com>
 <Fo1WnNOBMptjHkVUUtdvx4p03Ci1ljacM9bkFux2Qus=.b8082d30-35e9-491e-88a0-d00105f4381b@github.com>
Message-ID: <C8Fp0qE368HZbCo1tQIMBh44wZ19PyfQFcKlKWKcYnc=.1bbcec03-19ad-4f98-aff5-669ab82f2c0a@github.com>

On Wed, 22 Feb 2023 11:34:59 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> src/java.base/share/classes/sun/nio/cs/StandardCharsets.java.template line 217:
>> 
>>> 215:             if (VM.initLevel() < 1) {
>>> 216:                 // Cannot get the system property yet. Assumes non-2000
>>> 217:                 GB18030_2000 = "";
>> 
>> curious - what scenario triggers this call at initLevel < 1 ? would it be better to simply return "false" at that time and leave the GB18030_2000 variable to be set once we're at initLevel >=1  ?  -- or perhaps that would invalidate the workflow of the original caller (which called in at initLevel <1)
>
>> curious - what scenario triggers this call at initLevel < 1 ?
> 
> It's not supported, but it is possible that someone might run with -Dfile.encoding=GB18030, in which case the default charset is used before the system properties are initialized in initPhase1. Checking the init level breaks the circularity, the only downside is that can't switch to GB18030-2000 at the same time.

`Charset` class is initialized *before* system properties are set up, in order to check the JNU encoding (used for file path name) is a supported charset or not. In some OS environments, GB18030 is the native encoding so we need to avoid checking the system property in such a case.

-------------

PR: https://git.openjdk.org/jdk/pull/12518

From jvernee at openjdk.org  Wed Feb 22 18:28:05 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Wed, 22 Feb 2023 18:28:05 GMT
Subject: RFR: 8303040: linux PPC64le: Implementation of Foreign Function &
 Memory API (Preview)
In-Reply-To: <Yuxy6FrsDAN79ya8w8UIkvytGr25zGllDPtPJ1QbGwc=.182664b2-6d8c-497e-a4ae-95e0ad007cf9@github.com>
References: <Yuxy6FrsDAN79ya8w8UIkvytGr25zGllDPtPJ1QbGwc=.182664b2-6d8c-497e-a4ae-95e0ad007cf9@github.com>
Message-ID: <6Kr2C2phn8UoKIB6MbRn0o-0IuGo5BGFaVXVN9jS5Pg=.d59b2968-a811-487a-9775-d7a868bbbda7@github.com>

On Wed, 22 Feb 2023 05:31:46 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

> Implementation of "Foreign Function & Memory API" for linux on Power (Little Endian) according to "Power Architecture 64-Bit ELF V2 ABI Specification".
> 
> This PR does not include code for VaList support because it's supposed to get removed by [JDK-8299736](https://bugs.openjdk.org/browse/JDK-8299736). I've kept the related tests disabled for this platform and throw an exception instead. Note that the ABI doesn't precisely specify variable argument lists. Instead, it refers to `<stdarg.h>` (2.2.4 Variable Argument Lists).
> 
> Big Endian support is implemented to some extend, but not complete. E.g. structs with size not divisible by 8 are not passed correctly (see `useABIv2` in CallArranger.java). Big Endian is excluded by selecting `ARCH.equals("ppc64le")` (CABI.java) only.
> 
> There's another limitation: This PR only accepts structures with size divisible by 4. (An `IllegalArgumentException` gets thrown otherwise.) I think arbitrary sizes are not usable on other platforms, either, because `SharedUtils.primitiveCarrierForSize` only accepts powers of 2.
> 
> The ABI has some tricky corner cases related to HFA (Homogeneous Float Aggregate). The same argument may need to get passed in both, a FP reg and a GP reg or stack slot (see "no partial DW rule"). This cases are not covered by the existing tests.
> 
> I had to make changes to shared code and code for other platforms:
> 1. Pass type information when creating `VMStorage` objects from `VMReg`. This is needed for the following reasons:
> - PPC64 ABI requires integer types to get extended to 64 bit (also see CCallingConventionRequiresIntsAsLongs in existing hotspot code). We need to know the type or at least the bit width for that.
> - Floating point load / store instructions need the correct width to select between the correct IEEE 754 formats. The register representation in single FP registers is always IEEE 754 double precision on PPC64.
> - Big Endian also needs usage of the precise size. Storing 8 Bytes and loading 4 Bytes yields different values than on Little Endian!
> 2. It happens that a `NativeMemorySegmentImpl` is used as a raw pointer (with byteSize() == 0) while running TestUpcallScope. Hence, existing size checks don't work (see MemorySegment.java). As a workaround, I'm just skipping the check in this particular case. Please check if this makes sense or if there's a better fix (possibly as separate RFE).

src/java.base/share/classes/jdk/internal/foreign/PlatformLayouts.java line 266:

> 264:          * The {@code T*} native type.
> 265:          */
> 266:         public static final ValueLayout.OfAddress C_POINTER = ValueLayout.ADDRESS.withBitAlignment(64);

I think this is where the issue with the check in `MemorySegment::copy` comes from. Note how other platforms add a call to `asUnbounded` for the created layout, which makes any pointer boxed using this layout writable/readable (such as the in memory return pointer for upcalls).

-------------

PR: https://git.openjdk.org/jdk/pull/12708

From bpb at openjdk.org  Wed Feb 22 18:31:54 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 22 Feb 2023 18:31:54 GMT
Subject: RFR: 8298619: java/io/File/GetXSpace.java is failing [v2]
In-Reply-To: <6LnAAIclo5mZZgba4XUSTSc72vyNrBinzUlO9-kJXbU=.fe0c5e94-9e36-4484-b8e7-0f19cb10cb05@github.com>
References: <6LnAAIclo5mZZgba4XUSTSc72vyNrBinzUlO9-kJXbU=.fe0c5e94-9e36-4484-b8e7-0f19cb10cb05@github.com>
Message-ID: <9T4v-5BlHPv_K78LO9jzNUD-7RnVA4E-5UWIgkuQmfs=.326cd577-8526-48c3-a94d-5ba5e1d5f5aa@github.com>

> Modify the `Space` instances used for size comparison to be created with total number of bytes derived from the Windows `diskFree` utility instead of Cygwin?s `df`.

Brian Burkhalter has updated the pull request incrementally with two additional commits since the last revision:

 - 8298619: Load GetDiskSpaceInformationW dynamically
 - 8298619: Replace df and diskFree with native calls

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12397/files
  - new: https://git.openjdk.org/jdk/pull/12397/files/9eef8cd9..42ad4cea

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12397&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12397&range=00-01

  Stats: 340 lines in 3 files changed: 206 ins; 97 del; 37 mod
  Patch: https://git.openjdk.org/jdk/pull/12397.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12397/head:pull/12397

PR: https://git.openjdk.org/jdk/pull/12397

From bpb at openjdk.org  Wed Feb 22 18:31:55 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 22 Feb 2023 18:31:55 GMT
Subject: RFR: 8298619: java/io/File/GetXSpace.java is failing [v2]
In-Reply-To: <N2rOY286-pmyGS6g6R_EddIeBAj-cdStUNRMGwvh6tc=.06ec461d-2868-4de0-a0b0-a8e86709ba98@github.com>
References: <6LnAAIclo5mZZgba4XUSTSc72vyNrBinzUlO9-kJXbU=.fe0c5e94-9e36-4484-b8e7-0f19cb10cb05@github.com>
 <DTNziTj7KbkeG3LvpMREAi9WP9XRczQUdP_1-XTvp2c=.b9b78dec-3879-4626-9174-306e57ce83a4@github.com>
 <134wQrl9F4McK30DN1EvRTuqCx-WDMTgym1traoL8fI=.1247d3ff-0413-415a-9f3f-6a30b59f62d5@github.com>
 <Kia7JD1spnBOVIg-KuMO17m5UJClbL8R1SivnOyx8_0=.3950cd71-ce62-47ca-9ac6-0d16071567e3@github.com>
 <N2rOY286-pmyGS6g6R_EddIeBAj-cdStUNRMGwvh6tc=.06ec461d-2868-4de0-a0b0-a8e86709ba98@github.com>
Message-ID: <2qnsd811w7eNF2SE9ZSkCtH0k87zSAMsi262xhyh8eQ=.b83e63dc-e3e7-4e69-858d-b4770abe59e5@github.com>

On Tue, 14 Feb 2023 16:31:48 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>>> Another possibility would be to add a native method to the test itself to invoke [GetDiskSpaceInformationW](https://learn.microsoft.com/en-us/windows/win32/api/fileapi/nf-fileapi-getdiskspaceinformationw) to obtain the value of `CallerTotalAllocationUnits` (in bytes) from the [DISK_SPACE_INFORMATION](https://learn.microsoft.com/en-us/windows/win32/api/fileapi/ns-fileapi-disk_space_information) structure.
>> 
>> That would be more reliable than parsing the output of `fsutil volume` so worth trying. You might have to dig into which of these win32 works with quotas as that seems to be part of the issue. The JDK uses GetDiskFreeSpaceExW. Also this test might have to do a few iterations so that it captures free space info while the system is in quiescence - I suspect some of the reliability issues has been concurrent activity that changes the volume space usage significantly while this test is running.
>
> There has definitely been a problem with quotas on Windows. I set up quotas on actual Windows 11 hardware and replicated the same failure. I am not sure how much lack of system quiescence is to blame, but there would be no harm in building in some robustness for lack of quiescence while we're at it.

Spawning `df` and `diskFree` processes have been replaced with native calls. For a reason as yet undetermined, the Windows function `GetDiskSpaceInformationW` fails to load on Windows Server 2016 so it is loaded dynamically and, if not found, a workaround is used.

-------------

PR: https://git.openjdk.org/jdk/pull/12397

From mcimadamore at openjdk.org  Wed Feb 22 18:34:36 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 22 Feb 2023 18:34:36 GMT
Subject: RFR: 8303040: linux PPC64le: Implementation of Foreign Function &
 Memory API (Preview)
In-Reply-To: <Yuxy6FrsDAN79ya8w8UIkvytGr25zGllDPtPJ1QbGwc=.182664b2-6d8c-497e-a4ae-95e0ad007cf9@github.com>
References: <Yuxy6FrsDAN79ya8w8UIkvytGr25zGllDPtPJ1QbGwc=.182664b2-6d8c-497e-a4ae-95e0ad007cf9@github.com>
Message-ID: <-TEFo_FkmQmlWADKNrtOBByV6R0wOrrsVxDtpwf7J7w=.16c3e1cc-4cd8-4157-ab2c-15b0be9454f8@github.com>

On Wed, 22 Feb 2023 05:31:46 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

> Implementation of "Foreign Function & Memory API" for linux on Power (Little Endian) according to "Power Architecture 64-Bit ELF V2 ABI Specification".
> 
> This PR does not include code for VaList support because it's supposed to get removed by [JDK-8299736](https://bugs.openjdk.org/browse/JDK-8299736). I've kept the related tests disabled for this platform and throw an exception instead. Note that the ABI doesn't precisely specify variable argument lists. Instead, it refers to `<stdarg.h>` (2.2.4 Variable Argument Lists).
> 
> Big Endian support is implemented to some extend, but not complete. E.g. structs with size not divisible by 8 are not passed correctly (see `useABIv2` in CallArranger.java). Big Endian is excluded by selecting `ARCH.equals("ppc64le")` (CABI.java) only.
> 
> There's another limitation: This PR only accepts structures with size divisible by 4. (An `IllegalArgumentException` gets thrown otherwise.) I think arbitrary sizes are not usable on other platforms, either, because `SharedUtils.primitiveCarrierForSize` only accepts powers of 2.
> 
> The ABI has some tricky corner cases related to HFA (Homogeneous Float Aggregate). The same argument may need to get passed in both, a FP reg and a GP reg or stack slot (see "no partial DW rule"). This cases are not covered by the existing tests.
> 
> I had to make changes to shared code and code for other platforms:
> 1. Pass type information when creating `VMStorage` objects from `VMReg`. This is needed for the following reasons:
> - PPC64 ABI requires integer types to get extended to 64 bit (also see CCallingConventionRequiresIntsAsLongs in existing hotspot code). We need to know the type or at least the bit width for that.
> - Floating point load / store instructions need the correct width to select between the correct IEEE 754 formats. The register representation in single FP registers is always IEEE 754 double precision on PPC64.
> - Big Endian also needs usage of the precise size. Storing 8 Bytes and loading 4 Bytes yields different values than on Little Endian!
> 2. It happens that a `NativeMemorySegmentImpl` is used as a raw pointer (with byteSize() == 0) while running TestUpcallScope. Hence, existing size checks don't work (see MemorySegment.java). As a workaround, I'm just skipping the check in this particular case. Please check if this makes sense or if there's a better fix (possibly as separate RFE).

Thanks for looking into this port!

src/java.base/share/classes/java/lang/foreign/MemorySegment.java line 1359:

> 1357:         long size = elementCount * srcElementLayout.byteSize();
> 1358:         srcImpl.checkAccess(srcOffset, size, true);
> 1359:         if (dstImpl instanceof NativeMemorySegmentImpl && dstImpl.byteSize() == 0) {

As Jorn said, this change is not acceptable, as it allows bulk copy disregarding the segment real size. In such cases, the issue is always a missing unsafe resize somewhere in the linker code.

-------------

PR: https://git.openjdk.org/jdk/pull/12708

From bchristi at openjdk.org  Wed Feb 22 18:43:43 2023
From: bchristi at openjdk.org (Brent Christian)
Date: Wed, 22 Feb 2023 18:43:43 GMT
Subject: RFR: 8302899: Executors.newSingleThreadExecutor can use Cleaner to
 shutdown executor [v3]
In-Reply-To: <wPxOjT0C81bf2d9f9cZfSBY25mrRUqNFwioDHHA0uNw=.8fd08b6e-0edf-418f-b083-c3fe67caab30@github.com>
References: <tBrSZRn1GdrWMSRUsdNNyAWpkuS_FvtLwLuUKut6LH0=.cd1a7fcb-dbcf-45eb-b3d3-72ba17087566@github.com>
 <MaSioUrKP7eUCewEjsqWx4aaLQRieUYANatuYhSeZvE=.7f4b9f8e-b56e-4933-8292-dbb0907a4074@github.com>
 <xuuT67OjyS-RuT8vDkHjRk8b3ExQ1cEa0x6g_avFY7A=.b149b67b-e9bd-405f-aeb5-6c062a0a2486@github.com>
 <wPxOjT0C81bf2d9f9cZfSBY25mrRUqNFwioDHHA0uNw=.8fd08b6e-0edf-418f-b083-c3fe67caab30@github.com>
Message-ID: <9dC8dGrfGHxZ4smQrt6qUFTAoisz7GPRDXfoRWAGCmI=.4d8f4b00-b81e-4aca-91ab-29ab9ddd3f82@github.com>

On Wed, 22 Feb 2023 18:02:46 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> src/java.base/share/classes/java/util/concurrent/Executors.java line 844:
>> 
>>> 842:         @Override
>>> 843:         public void shutdown() {
>>> 844:             cleaner.clean();
>> 
>> Hmmm... so now shutdown no longer requires permission. You should probably call super.shutdown() before invoking cleaner.clean(), assuming that shutdown() can be called twice. You could modify the cleanup action to only call shutdown() if isShutdown() returns false.
>
>> Hmmm... so now shutdown no longer requires permission. You should probably call super.shutdown() before invoking cleaner.clean(), assuming that shutdown() can be called twice. You could modify the cleanup action to only call shutdown() if isShutdown() returns false.
> 
> You are right. It will be a non-issue once the SM goes away but while that execution mode is supported then the shutdown method and the cleaner action have to be different (as it was initially).

The cleaning action would not have access to the isShutdown() instance method of the (Phantom-reachable) AutoShutdownDelegatedExecutorService.

-------------

PR: https://git.openjdk.org/jdk/pull/12675

From duke at openjdk.org  Wed Feb 22 18:47:58 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Wed, 22 Feb 2023 18:47:58 GMT
Subject: RFR: 8302871: Speed up StringLatin1.regionMatchesCI [v12]
In-Reply-To: <B0NCYVR0qvImkfrktwxoisWCPVmcfJjHRSwes8bz5tY=.e24cca5b-207e-4ced-825d-af01d17b9116@github.com>
References: <dnsiX3nRffjGjZXJG7lMAZj2FktEl2Wc1XfFthQ4iJs=.8c41438a-80a4-468f-ae0b-7322c9d6d952@github.com>
 <B0NCYVR0qvImkfrktwxoisWCPVmcfJjHRSwes8bz5tY=.e24cca5b-207e-4ced-825d-af01d17b9116@github.com>
Message-ID: <J7Di2ZhG37ghp5kb0_MU7O5FeB41l8k3rXT20sPFQRA=.cc7c2a2b-9427-4553-807f-84e20ab8e304@github.com>

On Wed, 22 Feb 2023 16:37:45 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

>> This PR suggests we can speed up `StringLatin1.regionMatchesCI` by applying 'the oldest ASCII trick in the book'.
>> 
>> The new static method `CharacterDataLatin1.equalsIgnoreCase` compares two latin1 bytes for equality ignoring case. `StringLatin1.regionMatchesCI` is updated to use `equalsIgnoreCase`
>> 
>> To verify the correctness of `equalsIgnoreCase`, a new test is added  to `EqualsIgnoreCase` with an exhaustive verification that all 256x256 latin1 code point pairs have an `equalsIgnoreCase` consistent with Character.toUpperCase, Character.toLowerCase.
>> 
>> Performance is tested for matching and mismatching cases of code point pairs picked from the ASCII letter, ASCII number and latin1 letter ranges. Results in the first comment below.
>
> Eirik Bjorsnos has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Make the loop variables chars to avoid casting

Thanks for reviews Claes and Martin! I'll let this linger a bit before integrating in case Alan has comments after the latest updates.

-------------

PR: https://git.openjdk.org/jdk/pull/12632

From alanb at openjdk.org  Wed Feb 22 18:59:45 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 22 Feb 2023 18:59:45 GMT
Subject: RFR: 8302899: Executors.newSingleThreadExecutor can use Cleaner to
 shutdown executor [v3]
In-Reply-To: <9dC8dGrfGHxZ4smQrt6qUFTAoisz7GPRDXfoRWAGCmI=.4d8f4b00-b81e-4aca-91ab-29ab9ddd3f82@github.com>
References: <tBrSZRn1GdrWMSRUsdNNyAWpkuS_FvtLwLuUKut6LH0=.cd1a7fcb-dbcf-45eb-b3d3-72ba17087566@github.com>
 <MaSioUrKP7eUCewEjsqWx4aaLQRieUYANatuYhSeZvE=.7f4b9f8e-b56e-4933-8292-dbb0907a4074@github.com>
 <xuuT67OjyS-RuT8vDkHjRk8b3ExQ1cEa0x6g_avFY7A=.b149b67b-e9bd-405f-aeb5-6c062a0a2486@github.com>
 <wPxOjT0C81bf2d9f9cZfSBY25mrRUqNFwioDHHA0uNw=.8fd08b6e-0edf-418f-b083-c3fe67caab30@github.com>
 <9dC8dGrfGHxZ4smQrt6qUFTAoisz7GPRDXfoRWAGCmI=.4d8f4b00-b81e-4aca-91ab-29ab9ddd3f82@github.com>
Message-ID: <PTMU4sfj3hzJu21lcrkyfMBH4-QEVokex4x0LB0SPGs=.2fe66175-5af1-49eb-999c-326f350b3027@github.com>

On Wed, 22 Feb 2023 18:41:13 GMT, Brent Christian <bchristi at openjdk.org> wrote:

> The cleaning action would not have access to the isShutdown() instance method of the (Phantom-reachable) AutoShutdownDelegatedExecutorService.

The cleaning action has a reference to the delegate (the underlying ExecutorService) so it can test if it shutdown as Daniel's suggests - it's more of an optimization to avoid doing a second call to shutdown in a privileged action.

-------------

PR: https://git.openjdk.org/jdk/pull/12675

From bchristi at openjdk.org  Wed Feb 22 19:04:49 2023
From: bchristi at openjdk.org (Brent Christian)
Date: Wed, 22 Feb 2023 19:04:49 GMT
Subject: RFR: 8302899: Executors.newSingleThreadExecutor can use Cleaner to
 shutdown executor [v3]
In-Reply-To: <PTMU4sfj3hzJu21lcrkyfMBH4-QEVokex4x0LB0SPGs=.2fe66175-5af1-49eb-999c-326f350b3027@github.com>
References: <tBrSZRn1GdrWMSRUsdNNyAWpkuS_FvtLwLuUKut6LH0=.cd1a7fcb-dbcf-45eb-b3d3-72ba17087566@github.com>
 <MaSioUrKP7eUCewEjsqWx4aaLQRieUYANatuYhSeZvE=.7f4b9f8e-b56e-4933-8292-dbb0907a4074@github.com>
 <xuuT67OjyS-RuT8vDkHjRk8b3ExQ1cEa0x6g_avFY7A=.b149b67b-e9bd-405f-aeb5-6c062a0a2486@github.com>
 <wPxOjT0C81bf2d9f9cZfSBY25mrRUqNFwioDHHA0uNw=.8fd08b6e-0edf-418f-b083-c3fe67caab30@github.com>
 <9dC8dGrfGHxZ4smQrt6qUFTAoisz7GPRDXfoRWAGCmI=.4d8f4b00-b81e-4aca-91ab-29ab9ddd3f82@github.com>
 <PTMU4sfj3hzJu21lcrkyfMBH4-QEVokex4x0LB0SPGs=.2fe66175-5af1-49eb-999c-326f350b3027@github.com>
Message-ID: <jW32gHkKLRiYXM_tzOHyKVfOqEKMl751tP7oNP1gtvs=.51bd26f4-3f19-4b68-8e12-dbc710877cf3@github.com>

On Wed, 22 Feb 2023 18:57:00 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> The cleaning action would not have access to the isShutdown() instance method of the (Phantom-reachable) AutoShutdownDelegatedExecutorService.
>
>> The cleaning action would not have access to the isShutdown() instance method of the (Phantom-reachable) AutoShutdownDelegatedExecutorService.
> 
> The cleaning action has a reference to the delegate (the underlying ExecutorService) so it can test if it shutdown as Daniel suggests - it's more of an optimization to avoid doing a second call to shutdown in a privileged action.

OK, right

-------------

PR: https://git.openjdk.org/jdk/pull/12675

From kvn at openjdk.org  Wed Feb 22 19:19:48 2023
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Wed, 22 Feb 2023 19:19:48 GMT
Subject: RFR: 8302976: C2 intrinsification of Float.floatToFloat16 and
 Float.float16ToFloat yields different result than the interpreter
In-Reply-To: <f18TfSibBBm5FLon1VlUN0m6fNUzvOpsUeo7nEAk7JY=.456ddc51-7be7-4484-ad38-1039453b83d6@github.com>
References: <f18TfSibBBm5FLon1VlUN0m6fNUzvOpsUeo7nEAk7JY=.456ddc51-7be7-4484-ad38-1039453b83d6@github.com>
Message-ID: <3KyL3IP4tHCtZNzoOb3RsDuj0TsNkWBUufxwg4-YePc=.177bed30-9483-483c-90b3-0feab074ca88@github.com>

On Wed, 22 Feb 2023 02:08:27 GMT, Sandhya Viswanathan <sviswanathan at openjdk.org> wrote:

> Change the java/lang/float.java and the corresponding shared runtime constant expression evaluation to generate QNaN.
> The HW instructions generate QNaNs and not SNaNs for floating point instructions. This happens across double, float, and float16 data types. The most significant bit of mantissa is set to 1 for QNaNs.

The proposed fix do exactly what everyone asked - the same result from Java code (Interpreter), runtime (C++ code) and intrinsic (HW instruction). Since HW instruction is already produces QNaNs, PR fixes only Java code (Interpreter) and runtime (C++) code to produce QNaNs.

@TobiHartmann created test which covers all cases and should be added to this PR.

-------------

PR: https://git.openjdk.org/jdk/pull/12704

From duke at openjdk.org  Wed Feb 22 19:35:18 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Wed, 22 Feb 2023 19:35:18 GMT
Subject: RFR: 8302871: Speed up StringLatin1.regionMatchesCI [v13]
In-Reply-To: <dnsiX3nRffjGjZXJG7lMAZj2FktEl2Wc1XfFthQ4iJs=.8c41438a-80a4-468f-ae0b-7322c9d6d952@github.com>
References: <dnsiX3nRffjGjZXJG7lMAZj2FktEl2Wc1XfFthQ4iJs=.8c41438a-80a4-468f-ae0b-7322c9d6d952@github.com>
Message-ID: <LtIEN57XcTW6xwwqEK2vZSwGFgywtNa9XlibXdMgOfQ=.c6c2f0c2-cb91-4619-ad72-5b6b7dc2c951@github.com>

> This PR suggests we can speed up `StringLatin1.regionMatchesCI` by applying 'the oldest ASCII trick in the book'.
> 
> The new static method `CharacterDataLatin1.equalsIgnoreCase` compares two latin1 bytes for equality ignoring case. `StringLatin1.regionMatchesCI` is updated to use `equalsIgnoreCase`
> 
> To verify the correctness of `equalsIgnoreCase`, a new test is added  to `EqualsIgnoreCase` with an exhaustive verification that all 256x256 latin1 code point pairs have an `equalsIgnoreCase` consistent with Character.toUpperCase, Character.toLowerCase.
> 
> Performance is tested for matching and mismatching cases of code point pairs picked from the ASCII letter, ASCII number and latin1 letter ranges. Results in the first comment below.

Eirik Bjorsnos 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 'master' into regionmatches-latin1-speedup
 - Make the loop variables chars to avoid casting
 - Use improved case-twiddling comment as suggested by Martin
 - Replace 'oldest ASCII trick in the book' use in toUpperCase, toLowerCase with "by removing (setting) a single bit"
 - Align local variable naming in toLowerCase, toUpperCase with equalsIgnoreCase by using 'lower' and 'upper'
 - Rename unconventionally named local variable 'U' to 'upper'
 - Merge remote-tracking branch 'origin/master' into regionmatches-latin1-speedup
 - Add whitespace between methods
 - Merge branch 'master' into regionmatches-latin1-speedup
 - Remove whitespace following '('
 - ... and 10 more: https://git.openjdk.org/jdk/compare/ea132c56...fe4efe9f

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12632/files
  - new: https://git.openjdk.org/jdk/pull/12632/files/cc185293..fe4efe9f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12632&range=12
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12632&range=11-12

  Stats: 1397 lines in 120 files changed: 873 ins; 291 del; 233 mod
  Patch: https://git.openjdk.org/jdk/pull/12632.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12632/head:pull/12632

PR: https://git.openjdk.org/jdk/pull/12632

From igraves at openjdk.org  Wed Feb 22 19:39:28 2023
From: igraves at openjdk.org (Ian Graves)
Date: Wed, 22 Feb 2023 19:39:28 GMT
Subject: RFR: 8293667: Align jlink's --compress option with jmod's
 --compress option [v11]
In-Reply-To: <JWevwHuR2vF3k-JRxmTAxfNN6g-EBkgG2N9DHn4fkGY=.f9768dfd-cab4-49a9-83b9-d77a1572e917@github.com>
References: <JWevwHuR2vF3k-JRxmTAxfNN6g-EBkgG2N9DHn4fkGY=.f9768dfd-cab4-49a9-83b9-d77a1572e917@github.com>
Message-ID: <pymW7DaNtQLJOQkM3fSuguFQIaGs4jF9i_urJmW7JOM=.0d251849-b029-4844-818f-a13623a26fe3@github.com>

> This is an approach to adding a flag to jlink that will allow --compress to take the same types of arguments as jmod, thus bringing the two into alignment. This likely requires a CSR and a discussion on whether we should deprecate or simply remove the original numeric compression arguments.

Ian Graves has updated the pull request incrementally with one additional commit since the last revision:

  Adding runtime testing of new compression args

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/11617/files
  - new: https://git.openjdk.org/jdk/pull/11617/files/b2c4457f..74ec4f4b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11617&range=10
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11617&range=09-10

  Stats: 26 lines in 1 file changed: 26 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/11617.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11617/head:pull/11617

PR: https://git.openjdk.org/jdk/pull/11617

From igraves at openjdk.org  Wed Feb 22 19:46:56 2023
From: igraves at openjdk.org (Ian Graves)
Date: Wed, 22 Feb 2023 19:46:56 GMT
Subject: RFR: 8293667: Align jlink's --compress option with jmod's
 --compress option [v11]
In-Reply-To: <pymW7DaNtQLJOQkM3fSuguFQIaGs4jF9i_urJmW7JOM=.0d251849-b029-4844-818f-a13623a26fe3@github.com>
References: <JWevwHuR2vF3k-JRxmTAxfNN6g-EBkgG2N9DHn4fkGY=.f9768dfd-cab4-49a9-83b9-d77a1572e917@github.com>
 <pymW7DaNtQLJOQkM3fSuguFQIaGs4jF9i_urJmW7JOM=.0d251849-b029-4844-818f-a13623a26fe3@github.com>
Message-ID: <ouk-3vlX3OWr2Rwq7rYsnJGHtaFL0kYsQHMHzOff7zw=.df26c92c-b601-4639-834b-eeb8b9f04b1a@github.com>

On Wed, 22 Feb 2023 19:39:28 GMT, Ian Graves <igraves at openjdk.org> wrote:

>> This is an approach to adding a flag to jlink that will allow --compress to take the same types of arguments as jmod, thus bringing the two into alignment. This likely requires a CSR and a discussion on whether we should deprecate or simply remove the original numeric compression arguments.
>
> Ian Graves has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adding runtime testing of new compression args

Added additional test runs in JLinkTest to check runtime images that have been compressed using zip-X style flags.

-------------

PR: https://git.openjdk.org/jdk/pull/11617

From duke at openjdk.org  Wed Feb 22 20:01:52 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Wed, 22 Feb 2023 20:01:52 GMT
Subject: RFR: 8302871: Speed up StringLatin1.regionMatchesCI [v14]
In-Reply-To: <dnsiX3nRffjGjZXJG7lMAZj2FktEl2Wc1XfFthQ4iJs=.8c41438a-80a4-468f-ae0b-7322c9d6d952@github.com>
References: <dnsiX3nRffjGjZXJG7lMAZj2FktEl2Wc1XfFthQ4iJs=.8c41438a-80a4-468f-ae0b-7322c9d6d952@github.com>
Message-ID: <F0qyphqbltdnyRwcfKg96Vh2jkRtliefQlGBRuM7Zcc=.976fa82c-6ad8-4048-b0cf-b03683fa4ecd@github.com>

> This PR suggests we can speed up `StringLatin1.regionMatchesCI` by applying 'the oldest ASCII trick in the book'.
> 
> The new static method `CharacterDataLatin1.equalsIgnoreCase` compares two latin1 bytes for equality ignoring case. `StringLatin1.regionMatchesCI` is updated to use `equalsIgnoreCase`
> 
> To verify the correctness of `equalsIgnoreCase`, a new test is added  to `EqualsIgnoreCase` with an exhaustive verification that all 256x256 latin1 code point pairs have an `equalsIgnoreCase` consistent with Character.toUpperCase, Character.toLowerCase.
> 
> Performance is tested for matching and mismatching cases of code point pairs picked from the ASCII letter, ASCII number and latin1 letter ranges. Results in the first comment below.

Eirik Bjorsnos 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:

 - Merge branch 'master' into regionmatches-latin1-speedup
 - Merge branch 'master' into regionmatches-latin1-speedup
 - Make the loop variables chars to avoid casting
 - Use improved case-twiddling comment as suggested by Martin
 - Replace 'oldest ASCII trick in the book' use in toUpperCase, toLowerCase with "by removing (setting) a single bit"
 - Align local variable naming in toLowerCase, toUpperCase with equalsIgnoreCase by using 'lower' and 'upper'
 - Rename unconventionally named local variable 'U' to 'upper'
 - Merge remote-tracking branch 'origin/master' into regionmatches-latin1-speedup
 - Add whitespace between methods
 - Merge branch 'master' into regionmatches-latin1-speedup
 - ... and 11 more: https://git.openjdk.org/jdk/compare/e7379286...597b346a

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12632/files
  - new: https://git.openjdk.org/jdk/pull/12632/files/fe4efe9f..597b346a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12632&range=13
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12632&range=12-13

  Stats: 9 lines in 5 files changed: 1 ins; 2 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/12632.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12632/head:pull/12632

PR: https://git.openjdk.org/jdk/pull/12632

From naoto at openjdk.org  Wed Feb 22 20:46:50 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 22 Feb 2023 20:46:50 GMT
Subject: RFR: 8302983: ZoneRulesProvider.registerProvider() twice will
 remove provider
In-Reply-To: <AAfM5rBLeq2B3ttHBX_7kw0_rjfIVPSdcEL23HiOhVs=.b17c2586-b0bc-46ad-9501-0cf8363f82b9@github.com>
References: <AAfM5rBLeq2B3ttHBX_7kw0_rjfIVPSdcEL23HiOhVs=.b17c2586-b0bc-46ad-9501-0cf8363f82b9@github.com>
Message-ID: <rhr9eb9K3PR0rwwrPefxCpZS5srfvXWwqAt2Znzf5S0=.f83774c2-9e04-488c-96de-19a3c83d85c0@github.com>

On Tue, 21 Feb 2023 13:44:52 GMT, Madjosz <duke at openjdk.org> wrote:

> Fixes JDK-8302983 (and duplicate JDK-8302898)

Thanks for fixing this. Some comments follow.

test/jdk/java/time/test/java/time/zone/TestZoneRulesProvider.java line 43:

> 41: /**
> 42:  * @summary Tests for ZoneRulesProvider class.
> 43:  * @bug 8299571

Can be collapsed into one line

test/jdk/java/time/test/java/time/zone/TestZoneRulesProvider.java line 119:

> 117:                 return null;
> 118:             }
> 119:         }

Needs a semi-colon, otherwise would not compile.
Anyway, this inner class can be combined with the one in the test above, and made into a separate class.

test/jdk/java/time/test/java/time/zone/TestZoneRulesProvider.java line 123:

> 121:         ZoneRulesProvider.registerProvider(provider);
> 122:         assertTrue(ZoneId.getAvailableZoneIds().contains(zone), "Unexpected non-availability for " + zone);
> 123:         assertNotNull(ZoneId.of(zone), "ZoneId instance for " + zone + " should be obtainable");

If the `zone` does not exist, it will not return `null` but throw an exception. Assertion needs to be modified correctly.

test/jdk/java/time/test/java/time/zone/TestZoneRulesProvider.java line 136:

> 134:         // instantiation check
> 135:         try {
> 136:             assertNotNull(ZoneId.of(zone), "ZoneId instance for " + zone + " should still be obtainable");

Same here.

-------------

Changes requested by naoto (Reviewer).

PR: https://git.openjdk.org/jdk/pull/12690

From dlong at openjdk.org  Wed Feb 22 20:51:53 2023
From: dlong at openjdk.org (Dean Long)
Date: Wed, 22 Feb 2023 20:51:53 GMT
Subject: RFR: 8302976: C2 intrinsification of Float.floatToFloat16 and
 Float.float16ToFloat yields different result than the interpreter
In-Reply-To: <u4CPxJRd0uJKQf32who9UTr9fPfJWVetIzM8X4OnhCQ=.4f4fdf86-d260-4c13-bbc6-2a198d322994@github.com>
References: <f18TfSibBBm5FLon1VlUN0m6fNUzvOpsUeo7nEAk7JY=.456ddc51-7be7-4484-ad38-1039453b83d6@github.com>
 <nzUBOq3a8MVvd4EmIiPb95fr3JwBnUi1f1SGxWT2UBw=.d715b6e1-aba5-4448-be15-0cb418cc1084@github.com>
 <u4CPxJRd0uJKQf32who9UTr9fPfJWVetIzM8X4OnhCQ=.4f4fdf86-d260-4c13-bbc6-2a198d322994@github.com>
Message-ID: <ELPMSTAKtoFd1js9plI0U6lN0Xctupuvh8-J62t3dA8=.5328c9d9-b155-4d46-8964-41ec6e3cbf46@github.com>

On Wed, 22 Feb 2023 05:21:48 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> I'm also a bit concerned that we are rushing in to "fix" this. IIUC we have three mechanisms for implementing this functionality:
>> 
>> 1. The interpreted Java code
>> 2. The compiled non-intrinisc sharedRuntime code
>> 3. The compiler intrinsic that uses a hardware instruction.
>> 
>> Unless the hardware instructions for all relevant CPUs behave exactly the same, then I don't see how we can have parity of behaviour across these three mechanisms.
>> 
>> The observed behaviour may be surprising but it seems not to be a bug. And is this even a real concern - would real programs actually need to peek at the raw bits and so see the difference, or does it suffice to handle Nan's opaquely?
>
>> I'm also a bit concerned that we are rushing in to "fix" this. IIUC we have three mechanisms for implementing this functionality:
>> 
>>     1. The interpreted Java code
>> 
>>     2. The compiled non-intrinisc sharedRuntime code
>> 
>>     3. The compiler intrinsic that uses a hardware instruction.
>> 
>> 
>> Unless the hardware instructions for all relevant CPUs behave exactly the same, then I don't see how we can have parity of behaviour across these three mechanisms.
>> 
>> The observed behaviour may be surprising but it seems not to be a bug. And is this even a real concern - would real programs actually need to peek at the raw bits and so see the difference, or does it suffice to handle Nan's opaquely?
> 
> From the spec (https://download.java.net/java/early_access/jdk20/docs/api/java.base/java/lang/Float.html#float16ToFloat(short))
> 
> "Returns the float value closest to the numerical value of the argument, a floating-point binary16 value encoded in a short. The conversion is exact; all binary16 values can be exactly represented in float. Special cases:
> 
>     If the argument is zero, the result is a zero with the same sign as the argument.
>     If the argument is infinite, the result is an infinity with the same sign as the argument.
>     If the argument is a NaN, the result is a NaN. "
> 
> If the float argument is a NaN, you are supposed to get a float16 NaN as a result -- that is all the specification requires. However, the implementation makes stronger guarantees to try to preserve some non-zero NaN significand bits if they are set.
> 
> "NaN boxing" is a technique used to put extra information into the significand bits a NaN and pass the around. It is consistent with the intended use of the feature by IEEE 754 and used in various language runtimes: e.g.,
> 
> https://piotrduperas.com/posts/nan-boxing
> https://leonardschuetz.ch/blog/nan-boxing/ 
> https://anniecherkaev.com/the-secret-life-of-nan
> 
> The Java specs are careful to avoid mentioning quiet vs signaling NaNs in general discussion.
> 
> That said, I think it is reasonable on a given JVM invocation if Float.floatToFloat16(f) gave the same result for input f regardless of in what context it was called.

We don't know that all HW will produce the same NaN "payload", right?  Instead, we might need interpreter intrinsics.  I assume that is how the trig functions are handled that @jddarcy mentioned.

-------------

PR: https://git.openjdk.org/jdk/pull/12704

From kvn at openjdk.org  Wed Feb 22 21:24:25 2023
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Wed, 22 Feb 2023 21:24:25 GMT
Subject: RFR: 8302976: C2 intrinsification of Float.floatToFloat16 and
 Float.float16ToFloat yields different result than the interpreter
In-Reply-To: <u4CPxJRd0uJKQf32who9UTr9fPfJWVetIzM8X4OnhCQ=.4f4fdf86-d260-4c13-bbc6-2a198d322994@github.com>
References: <f18TfSibBBm5FLon1VlUN0m6fNUzvOpsUeo7nEAk7JY=.456ddc51-7be7-4484-ad38-1039453b83d6@github.com>
 <nzUBOq3a8MVvd4EmIiPb95fr3JwBnUi1f1SGxWT2UBw=.d715b6e1-aba5-4448-be15-0cb418cc1084@github.com>
 <u4CPxJRd0uJKQf32who9UTr9fPfJWVetIzM8X4OnhCQ=.4f4fdf86-d260-4c13-bbc6-2a198d322994@github.com>
Message-ID: <3JDw74vUUrTL3j-7TQ1It-_I_WuqcYrGtk_b7AilH74=.2038c9e0-4262-40f4-aa0d-05f1a1e95e40@github.com>

On Wed, 22 Feb 2023 05:21:48 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> I'm also a bit concerned that we are rushing in to "fix" this. IIUC we have three mechanisms for implementing this functionality:
>> 
>> 1. The interpreted Java code
>> 2. The compiled non-intrinisc sharedRuntime code
>> 3. The compiler intrinsic that uses a hardware instruction.
>> 
>> Unless the hardware instructions for all relevant CPUs behave exactly the same, then I don't see how we can have parity of behaviour across these three mechanisms.
>> 
>> The observed behaviour may be surprising but it seems not to be a bug. And is this even a real concern - would real programs actually need to peek at the raw bits and so see the difference, or does it suffice to handle Nan's opaquely?
>
>> I'm also a bit concerned that we are rushing in to "fix" this. IIUC we have three mechanisms for implementing this functionality:
>> 
>>     1. The interpreted Java code
>> 
>>     2. The compiled non-intrinisc sharedRuntime code
>> 
>>     3. The compiler intrinsic that uses a hardware instruction.
>> 
>> 
>> Unless the hardware instructions for all relevant CPUs behave exactly the same, then I don't see how we can have parity of behaviour across these three mechanisms.
>> 
>> The observed behaviour may be surprising but it seems not to be a bug. And is this even a real concern - would real programs actually need to peek at the raw bits and so see the difference, or does it suffice to handle Nan's opaquely?
> 
> From the spec (https://download.java.net/java/early_access/jdk20/docs/api/java.base/java/lang/Float.html#float16ToFloat(short))
> 
> "Returns the float value closest to the numerical value of the argument, a floating-point binary16 value encoded in a short. The conversion is exact; all binary16 values can be exactly represented in float. Special cases:
> 
>     If the argument is zero, the result is a zero with the same sign as the argument.
>     If the argument is infinite, the result is an infinity with the same sign as the argument.
>     If the argument is a NaN, the result is a NaN. "
> 
> If the float argument is a NaN, you are supposed to get a float16 NaN as a result -- that is all the specification requires. However, the implementation makes stronger guarantees to try to preserve some non-zero NaN significand bits if they are set.
> 
> "NaN boxing" is a technique used to put extra information into the significand bits a NaN and pass the around. It is consistent with the intended use of the feature by IEEE 754 and used in various language runtimes: e.g.,
> 
> https://piotrduperas.com/posts/nan-boxing
> https://leonardschuetz.ch/blog/nan-boxing/ 
> https://anniecherkaev.com/the-secret-life-of-nan
> 
> The Java specs are careful to avoid mentioning quiet vs signaling NaNs in general discussion.
> 
> That said, I think it is reasonable on a given JVM invocation if Float.floatToFloat16(f) gave the same result for input f regardless of in what context it was called.

> We don't know that all HW will produce the same NaN "payload", right? Instead, we might need interpreter intrinsics. I assume that is how the trig functions are handled that @jddarcy mentioned.

Good point. We can't guarantee that all OpenJDK ports HW do the same.

If CPU has corresponding instructions we need to generate a stub during VM startup with HW instructions and use it in all cases (or directly the same instruction in JIT compiled code).
If CPU does not have instruction we should use runtime C++ function in all cases to be consistent.

-------------

PR: https://git.openjdk.org/jdk/pull/12704

From forax at openjdk.org  Wed Feb 22 21:32:35 2023
From: forax at openjdk.org (=?UTF-8?B?UsOpbWk=?= Forax)
Date: Wed, 22 Feb 2023 21:32:35 GMT
Subject: RFR: 8302154: Hidden classes created by LambdaMetaFactory can't be
 unloaded [v2]
In-Reply-To: <0ZZLsRlr6IO4jL2VKAcn4geYptqUOdYPUXbd-KQiApo=.d1b3ca63-ca4a-4eef-9d5e-88cc3418ada9@github.com>
References: <YoZauVv8zvhdUw-LD25LrsMDItFbg3aXPU3deXwwFdQ=.c2839dea-12e5-4e0e-9579-eac9d8503932@github.com>
 <gKoLpwlXDxp2uaSKSkMArJl1Ym9VX1hoDFqQTTUpk8w=.e1dce669-5a42-4b66-ac4b-205718c8eb81@github.com>
 <0ZZLsRlr6IO4jL2VKAcn4geYptqUOdYPUXbd-KQiApo=.d1b3ca63-ca4a-4eef-9d5e-88cc3418ada9@github.com>
Message-ID: <rInYVnkiymZwIqKu5XxwDoMAViRD8adc7C3P3bvsmTI=.eaeac812-edcc-472e-b032-f4b0cde80f45@github.com>

On Wed, 22 Feb 2023 17:05:00 GMT, Kasper Nielsen <duke at openjdk.org> wrote:

>> Volker Simonis has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Remove assertions which insist on Lambda proxy classes being strongly linked to their class loader
>>  - Removed unused import of STRONG und updated copyright year
>
> In all the places I've seen LambdaMetaFactory used, it is because of performance over reflection/non-static method handles. See, for example, https://www.optaplanner.org/blog/2018/01/09/JavaReflectionButMuchFaster.html. I believe Optaplanner is still using it.
> 
> There is also quite a number of posts on StackOverflow on people trying to use LambdaMetafactory:
> https://stackoverflow.com/search?q=LambdaMetafactory

@kaspernielsen, i believe that now that hidden class + class data are part of the public API,
you do not need to use lambda metafactory directly. But it requires Java 17 not 8 or 11.

-------------

PR: https://git.openjdk.org/jdk/pull/12493

From iklam at openjdk.org  Wed Feb 22 21:55:28 2023
From: iklam at openjdk.org (Ioi Lam)
Date: Wed, 22 Feb 2023 21:55:28 GMT
Subject: RFR: 8292914: Drop the counter from lambda class names [v8]
In-Reply-To: <AdfREeJYVkF6HTsw669hMueQxdGXUXxYc4GetiDuoDk=.5124c8b8-3bea-4baa-bbb1-9383c84bb15f@github.com>
References: <GgLfH-ueBQqT-Mfk1mKpKFAt8fYqyjfVJ9lmlsBsCbo=.8dd5b3b4-4e84-4970-9179-1c0399b30edc@github.com>
 <AdfREeJYVkF6HTsw669hMueQxdGXUXxYc4GetiDuoDk=.5124c8b8-3bea-4baa-bbb1-9383c84bb15f@github.com>
Message-ID: <sohQiNe8uovm6Op0kgyyYqIf99wAK9trVuBo5V4NJkY=.6a976436-0475-4369-b08e-e17432608cc1@github.com>

On Fri, 17 Feb 2023 19:37:59 GMT, David M. Lloyd <duke at openjdk.org> wrote:

>> The class generated for lambda proxies is now defined as a hidden class. This means that the counter, which was used to ensure a unique class name and avoid clashes, is now redundant. In addition to performing redundant work, this also impacts build reproducibility for native image generators which might already have a strategy to cope with hidden classes but cannot cope with indeterminate definition order for lambda proxy classes.
>> 
>> This solves JDK-8292914 by making lambda proxy names always be stable without any configuration needed. This would also replace #10024.
>
> David M. Lloyd has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Many tests have patterns for lambda class names; update them
>  - Update comments and javadoc showin the old pattern

This looks ok to me but I?ll defer to Mandy. I?m also on vacation so don?t wait for me :-)

-------------

PR: https://git.openjdk.org/jdk/pull/12579

From sviswanathan at openjdk.org  Wed Feb 22 21:56:28 2023
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Wed, 22 Feb 2023 21:56:28 GMT
Subject: RFR: 8302976: C2 intrinsification of Float.floatToFloat16 and
 Float.float16ToFloat yields different result than the interpreter
In-Reply-To: <3JDw74vUUrTL3j-7TQ1It-_I_WuqcYrGtk_b7AilH74=.2038c9e0-4262-40f4-aa0d-05f1a1e95e40@github.com>
References: <f18TfSibBBm5FLon1VlUN0m6fNUzvOpsUeo7nEAk7JY=.456ddc51-7be7-4484-ad38-1039453b83d6@github.com>
 <nzUBOq3a8MVvd4EmIiPb95fr3JwBnUi1f1SGxWT2UBw=.d715b6e1-aba5-4448-be15-0cb418cc1084@github.com>
 <u4CPxJRd0uJKQf32who9UTr9fPfJWVetIzM8X4OnhCQ=.4f4fdf86-d260-4c13-bbc6-2a198d322994@github.com>
 <3JDw74vUUrTL3j-7TQ1It-_I_WuqcYrGtk_b7AilH74=.2038c9e0-4262-40f4-aa0d-05f1a1e95e40@github.com>
Message-ID: <Qh-jodDHvvIGBSYclNl8Rg4q-gGH6VyzFtZgmqECj3M=.5fce869d-f2c4-4c98-ae2c-982bc7c49d3d@github.com>

On Wed, 22 Feb 2023 21:21:42 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>>> I'm also a bit concerned that we are rushing in to "fix" this. IIUC we have three mechanisms for implementing this functionality:
>>> 
>>>     1. The interpreted Java code
>>> 
>>>     2. The compiled non-intrinisc sharedRuntime code
>>> 
>>>     3. The compiler intrinsic that uses a hardware instruction.
>>> 
>>> 
>>> Unless the hardware instructions for all relevant CPUs behave exactly the same, then I don't see how we can have parity of behaviour across these three mechanisms.
>>> 
>>> The observed behaviour may be surprising but it seems not to be a bug. And is this even a real concern - would real programs actually need to peek at the raw bits and so see the difference, or does it suffice to handle Nan's opaquely?
>> 
>> From the spec (https://download.java.net/java/early_access/jdk20/docs/api/java.base/java/lang/Float.html#float16ToFloat(short))
>> 
>> "Returns the float value closest to the numerical value of the argument, a floating-point binary16 value encoded in a short. The conversion is exact; all binary16 values can be exactly represented in float. Special cases:
>> 
>>     If the argument is zero, the result is a zero with the same sign as the argument.
>>     If the argument is infinite, the result is an infinity with the same sign as the argument.
>>     If the argument is a NaN, the result is a NaN. "
>> 
>> If the float argument is a NaN, you are supposed to get a float16 NaN as a result -- that is all the specification requires. However, the implementation makes stronger guarantees to try to preserve some non-zero NaN significand bits if they are set.
>> 
>> "NaN boxing" is a technique used to put extra information into the significand bits a NaN and pass the around. It is consistent with the intended use of the feature by IEEE 754 and used in various language runtimes: e.g.,
>> 
>> https://piotrduperas.com/posts/nan-boxing
>> https://leonardschuetz.ch/blog/nan-boxing/ 
>> https://anniecherkaev.com/the-secret-life-of-nan
>> 
>> The Java specs are careful to avoid mentioning quiet vs signaling NaNs in general discussion.
>> 
>> That said, I think it is reasonable on a given JVM invocation if Float.floatToFloat16(f) gave the same result for input f regardless of in what context it was called.
>
>> We don't know that all HW will produce the same NaN "payload", right? Instead, we might need interpreter intrinsics. I assume that is how the trig functions are handled that @jddarcy mentioned.
> 
> Good point. We can't guarantee that all OpenJDK ports HW do the same.
> 
> If CPU has corresponding instructions we need to generate a stub during VM startup with HW instructions and use it in all cases (or directly the same instruction in JIT compiled code).
> If CPU does not have instruction we should use runtime C++ function in all cases to be consistent.

Thanks @vnkozlov @dean-long. One last question before I withdraw the PR: As QNaN bit is supported across current architectures like x86, ARM and may be others as well for conversion, couldn't we go ahead with this PR? The architectures that behave differently could then follow the technique suggested by Vladimir Kozlov as and when they implement the intrinsic?

-------------

PR: https://git.openjdk.org/jdk/pull/12704

From bpb at openjdk.org  Wed Feb 22 21:57:25 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 22 Feb 2023 21:57:25 GMT
Subject: RFR: JDK-8302028: Port fdlibm atan2 to Java [v5]
In-Reply-To: <BzM7dqT1RGYp6221nMtHQTMMHBAwr_ygCp_tIkITMLg=.318687e1-2f26-49c1-955e-f8b6af177e10@github.com>
References: <xl79M-V4_2t49GuCudJHQBaJjAcwWl9f2Bv19RbAmdo=.b9c97066-8cf4-4569-8b4b-8b4874e23833@github.com>
 <BzM7dqT1RGYp6221nMtHQTMMHBAwr_ygCp_tIkITMLg=.318687e1-2f26-49c1-955e-f8b6af177e10@github.com>
Message-ID: <SrMHMakjeZTqilRosW8tDWsfYyzPiL4HUzUhyg-2Yew=.17b512c1-7b19-4e09-9f1d-7008ca0547ad@github.com>

On Tue, 21 Feb 2023 23:03:04 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Working down the porting list, next stop, atan2.
>
> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Respond to review feedback.

Looks good.

-------------

Marked as reviewed by bpb (Reviewer).

PR: https://git.openjdk.org/jdk/pull/12608

From darcy at openjdk.org  Wed Feb 22 22:55:05 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 22 Feb 2023 22:55:05 GMT
Subject: Integrated: JDK-8302028: Port fdlibm atan2 to Java
In-Reply-To: <xl79M-V4_2t49GuCudJHQBaJjAcwWl9f2Bv19RbAmdo=.b9c97066-8cf4-4569-8b4b-8b4874e23833@github.com>
References: <xl79M-V4_2t49GuCudJHQBaJjAcwWl9f2Bv19RbAmdo=.b9c97066-8cf4-4569-8b4b-8b4874e23833@github.com>
Message-ID: <yee0CbSNm6rQyL0P9fz-omji-7f4nnNFR34WV4vVDmc=.da483228-fbf5-4175-a44f-8cd3713ade35@github.com>

On Thu, 16 Feb 2023 19:30:06 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Working down the porting list, next stop, atan2.

This pull request has now been integrated.

Changeset: fcaf8714
Author:    Joe Darcy <darcy at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/fcaf871408321ed523cf1c6dd3adf9914f2bf9aa
Stats:     615 lines in 6 files changed: 595 ins; 8 del; 12 mod

8302028: Port fdlibm atan2 to Java

Reviewed-by: bpb

-------------

PR: https://git.openjdk.org/jdk/pull/12608

From john.r.rose at oracle.com  Wed Feb 22 22:55:17 2023
From: john.r.rose at oracle.com (John Rose)
Date: Wed, 22 Feb 2023 14:55:17 -0800
Subject: RFR: 8292914: Drop the counter from lambda class names
In-Reply-To: <GYE-KZUqt6hWkUC-KHrt4X0cCFSuzKDVyQmFAxo9FPc=.26dbc76f-4458-489f-abae-c29c06ce166f@github.com>
References: <GgLfH-ueBQqT-Mfk1mKpKFAt8fYqyjfVJ9lmlsBsCbo=.8dd5b3b4-4e84-4970-9179-1c0399b30edc@github.com>
 <GYE-KZUqt6hWkUC-KHrt4X0cCFSuzKDVyQmFAxo9FPc=.26dbc76f-4458-489f-abae-c29c06ce166f@github.com>
Message-ID: <2F167026-2EA8-4AA9-8709-3EC911B3268E@oracle.com>

On 15 Feb 2023, at 10:34, Mandy Chung wrote:

> On Wed, 15 Feb 2023 17:32:38 GMT, David M. Lloyd <duke at openjdk.org> 
> wrote:
>
>> The class generated for lambda proxies is now defined as a hidden 
>> class. This means that the counter, which was used to ensure a unique 
>> class name and avoid clashes, is now redundant. In addition to 
>> performing redundant work, this also impacts build reproducibility 
>> for native image generators which might already have a strategy to 
>> cope with hidden classes but cannot cope with indeterminate 
>> definition order for lambda proxy classes.
>>
>> This solves JDK-8292914 by making lambda proxy names always be stable 
>> without any configuration needed. This would also replace #10024.
>
> we want the generated classes to be dumped for debugging before the 
> hidden class is defined e.g. to troubleshoot class loading issue (see  
> `-Djdk.internal.lambda.dumpProxyClasses=<path>` system property)
>

I agree with David that the extra counter is a problem.  Further, I 
think it will continue to be a problem in any likely Leyden use cases, 
precisely because it blocks reproducibility and predictability.  So, 
although Brian is right that there are likely to be more problems like 
it in the future, and we will surely want a comprehensive solution, I 
think removing the counter is legitimate incremental progress, not 
likely to be contradicted by future developments.

While I?m agreeing with everybody here I?ll also agree with Mandy:  
We need a simple debugging story, and the global counter make it simple. 
  But surely there are other things we could do as well, including using 
the global counter to name the dump file but *not* to name the class 
itself.  That is, don?t pollute the HC classfile bytes with the 
counter ?noise? but by all means use it to sequence debugging 
activities.

Maybe even better, we could use the ?decorated? class name assigned 
by the JVM, *after* the HC is loaded, to form the dump file name.  One 
easy way to do this is rename the dump file after the JVM loads the HC 
and picks the decoration.

(Note that the decoration is just the I-hash of the class mirror of the 
HC, and *also* has the good property that it does *not* pollute the 
classfile bytes.  It?s OK that each fresh invocation of the JVM is 
likely to choose a different decoration, as long as we don?t try to 
predict it statically.  This means backtraces cannot be fully predicted 
statically; tough luck there.)

Another way to handle it is ask the JVM to do the file dumping.  This 
might seem excessively indirect, given the simple thing we do now in the 
Java code, but? we probably want to be able to ask the JVM (for Leyden 
training runs) to report all class files loaded (especially those 
dynamically generated!) so we can analyze them and do good stuff with 
them.

This implies that, whether or not we dump HC files from Java code, the 
*JVM also has to dump them* somewhere or other.

Where this takes me is:  The responsibility for dumping HC contents 
should be moved from Java code to the JVM.

I still think removing the counter is a good step in isolation, but (as 
Brian says) the root issue is that we want good reporting of HC contents 
for more than just ad hoc debugging.  So we need to think more broadly 
about how to preserve and report HC classfile contents, for Leyden as 
well as ad hoc debugging.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20230222/0d306d2f/attachment-0001.htm>

From bpb at openjdk.org  Wed Feb 22 23:35:08 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 22 Feb 2023 23:35:08 GMT
Subject: RFR: 8302806: (fs) Remove
 com.sun.nio.file.SensitivityWatchEventModifier [v3]
In-Reply-To: <FZn8ZF4sN5mtUO8MWPaC0N8nWFwTLkBvcqQeOPwVYeE=.a6e12227-dfa9-4817-adbb-bece72445860@github.com>
References: <FZn8ZF4sN5mtUO8MWPaC0N8nWFwTLkBvcqQeOPwVYeE=.a6e12227-dfa9-4817-adbb-bece72445860@github.com>
Message-ID: <BT4PUVkkM9_OrNDbIdxPEXYwNzDdBNbF4z1HtaVPw7E=.160b64c6-88ad-4132-9634-3dba35778190@github.com>

> This enum is not used in the JDK and did not appear in external source code searches.

Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:

  8302806: Remove sensitivity from PollingWatchService

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12626/files
  - new: https://git.openjdk.org/jdk/pull/12626/files/c980dba9..e17f66c1

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12626&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12626&range=01-02

  Stats: 21 lines in 1 file changed: 1 ins; 8 del; 12 mod
  Patch: https://git.openjdk.org/jdk/pull/12626.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12626/head:pull/12626

PR: https://git.openjdk.org/jdk/pull/12626

From dlong at openjdk.org  Wed Feb 22 23:59:58 2023
From: dlong at openjdk.org (Dean Long)
Date: Wed, 22 Feb 2023 23:59:58 GMT
Subject: RFR: 8302976: C2 intrinsification of Float.floatToFloat16 and
 Float.float16ToFloat yields different result than the interpreter
In-Reply-To: <3JDw74vUUrTL3j-7TQ1It-_I_WuqcYrGtk_b7AilH74=.2038c9e0-4262-40f4-aa0d-05f1a1e95e40@github.com>
References: <f18TfSibBBm5FLon1VlUN0m6fNUzvOpsUeo7nEAk7JY=.456ddc51-7be7-4484-ad38-1039453b83d6@github.com>
 <nzUBOq3a8MVvd4EmIiPb95fr3JwBnUi1f1SGxWT2UBw=.d715b6e1-aba5-4448-be15-0cb418cc1084@github.com>
 <u4CPxJRd0uJKQf32who9UTr9fPfJWVetIzM8X4OnhCQ=.4f4fdf86-d260-4c13-bbc6-2a198d322994@github.com>
 <3JDw74vUUrTL3j-7TQ1It-_I_WuqcYrGtk_b7AilH74=.2038c9e0-4262-40f4-aa0d-05f1a1e95e40@github.com>
Message-ID: <P9ucKoePjyYMbP7DBvpTYvNlvs1NDr2jIZ4wgkkXvbA=.7aacd71b-35a5-4656-bdc1-1d9c81e838ea@github.com>

On Wed, 22 Feb 2023 21:21:42 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>>> I'm also a bit concerned that we are rushing in to "fix" this. IIUC we have three mechanisms for implementing this functionality:
>>> 
>>>     1. The interpreted Java code
>>> 
>>>     2. The compiled non-intrinisc sharedRuntime code
>>> 
>>>     3. The compiler intrinsic that uses a hardware instruction.
>>> 
>>> 
>>> Unless the hardware instructions for all relevant CPUs behave exactly the same, then I don't see how we can have parity of behaviour across these three mechanisms.
>>> 
>>> The observed behaviour may be surprising but it seems not to be a bug. And is this even a real concern - would real programs actually need to peek at the raw bits and so see the difference, or does it suffice to handle Nan's opaquely?
>> 
>> From the spec (https://download.java.net/java/early_access/jdk20/docs/api/java.base/java/lang/Float.html#float16ToFloat(short))
>> 
>> "Returns the float value closest to the numerical value of the argument, a floating-point binary16 value encoded in a short. The conversion is exact; all binary16 values can be exactly represented in float. Special cases:
>> 
>>     If the argument is zero, the result is a zero with the same sign as the argument.
>>     If the argument is infinite, the result is an infinity with the same sign as the argument.
>>     If the argument is a NaN, the result is a NaN. "
>> 
>> If the float argument is a NaN, you are supposed to get a float16 NaN as a result -- that is all the specification requires. However, the implementation makes stronger guarantees to try to preserve some non-zero NaN significand bits if they are set.
>> 
>> "NaN boxing" is a technique used to put extra information into the significand bits a NaN and pass the around. It is consistent with the intended use of the feature by IEEE 754 and used in various language runtimes: e.g.,
>> 
>> https://piotrduperas.com/posts/nan-boxing
>> https://leonardschuetz.ch/blog/nan-boxing/ 
>> https://anniecherkaev.com/the-secret-life-of-nan
>> 
>> The Java specs are careful to avoid mentioning quiet vs signaling NaNs in general discussion.
>> 
>> That said, I think it is reasonable on a given JVM invocation if Float.floatToFloat16(f) gave the same result for input f regardless of in what context it was called.
>
>> We don't know that all HW will produce the same NaN "payload", right? Instead, we might need interpreter intrinsics. I assume that is how the trig functions are handled that @jddarcy mentioned.
> 
> Good point. We can't guarantee that all OpenJDK ports HW do the same.
> 
> If CPU has corresponding instructions we need to generate a stub during VM startup with HW instructions and use it in all cases (or directly the same instruction in JIT compiled code).
> If CPU does not have instruction we should use runtime C++ function in all cases to be consistent.

> Thanks @vnkozlov @dean-long. One last question before I withdraw the PR: As QNaN bit is supported across current architectures like x86, ARM and may be others as well for conversion, couldn't we go ahead with this PR? The architectures that behave differently could then follow the technique suggested by Vladimir Kozlov as and when they implement the intrinsic?

No, because it's not just the SNaN vs QNaN that is different, but also the NaN "payload" or "boxing" that is different.  For example, the intrinsic gives me different results on aarch64 vs Intel with this test:


public class Foo {
  public static float hf2f(short s) {
    return Float.floatToFloat16(s);
  }
  public static short f2hf(float f) {
    return Float.floatToFloat16(f);
  }
  public static void main(String[] args) {
    float f = Float.intBitsToFloat(0x7fc00000 | 0x2000 );
    System.out.println(Integer.toHexString(f2hf(f)));
    f = Float.intBitsToFloat(0x7fc00000 | 0x20 );
    System.out.println(Integer.toHexString(f2hf(f)));
    f = Float.intBitsToFloat(0x7fc00000 | 0x4);
    System.out.println(Integer.toHexString(f2hf(f)));
    f = Float.intBitsToFloat(0x7fc00000 | 0x2000 | 0x20 | 0x4);
    System.out.println(Integer.toHexString(f2hf(f)));
  }
}

-------------

PR: https://git.openjdk.org/jdk/pull/12704

From darcy at openjdk.org  Thu Feb 23 03:12:11 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Thu, 23 Feb 2023 03:12:11 GMT
Subject: RFR: 8302976: C2 intrinsification of Float.floatToFloat16 and
 Float.float16ToFloat yields different result than the interpreter
In-Reply-To: <-3z8sZMccXAOTV4KgeqrX6KQTcnSP20B70a293fhQSI=.354c1f98-c5bd-4b7e-a59a-10ff31d7d6b9@github.com>
References: <f18TfSibBBm5FLon1VlUN0m6fNUzvOpsUeo7nEAk7JY=.456ddc51-7be7-4484-ad38-1039453b83d6@github.com>
 <nzUBOq3a8MVvd4EmIiPb95fr3JwBnUi1f1SGxWT2UBw=.d715b6e1-aba5-4448-be15-0cb418cc1084@github.com>
 <u4CPxJRd0uJKQf32who9UTr9fPfJWVetIzM8X4OnhCQ=.4f4fdf86-d260-4c13-bbc6-2a198d322994@github.com>
 <-3z8sZMccXAOTV4KgeqrX6KQTcnSP20B70a293fhQSI=.354c1f98-c5bd-4b7e-a59a-10ff31d7d6b9@github.com>
Message-ID: <K2okEDKr1a2kjhzm9aSx2sn9gCYOvxe8IyaBpnb3kAc=.c12d8f23-3c6a-455d-a723-2aacc01377d8@github.com>

On Wed, 22 Feb 2023 09:46:59 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

> > That said, I think it is reasonable on a given JVM invocation if Float.floatToFloat16(f) gave the same result for input f regardless of in what context it was called.
> 
> Yes, I'm under the impression that for math API methods like this, the stability of input to output must be preserved for a single JVM invocation. Or are there existing methods for which the interpreter and compiled code execution is allowed to differ?

A similar but not exactly analagous situation occurs for the intrinsics of various java.lang.Math methods. Many of the methods of interest allow implementation flexibility, subject to various quality of implementation criteria. Those criteria bound the maximum error at a single point, phrased in terms of ulps -- units in the last place, and require semi-monotonicity -- which describes the relation of outputs of adjacent floating-point values.

Taking two compliant implementations of Math.foo(), it is not necessarily a valid implementation to switch between them because the semi-monotonicity constraint can be violated. The solution is to always use or always not use an intrinsic for Math.foo on a given JVM invocation. HTH

-------------

PR: https://git.openjdk.org/jdk/pull/12704

From duke at openjdk.org  Thu Feb 23 03:42:02 2023
From: duke at openjdk.org (Xiaowei Lu)
Date: Thu, 23 Feb 2023 03:42:02 GMT
Subject: RFR: 8302204: Optimize BigDecimal.divide
In-Reply-To: <LsBjupG20ZvkAuKI-gFAPtdg3-glOkS2wAy15hRa-BM=.76ada238-5727-4975-898e-ed6cbadd6203@github.com>
References: <rUC0Dh_-1E0PZNJwM0GRH1KPu6prPotT-oeDTUdqjI4=.a8f7d3b7-a0f2-45a0-ae01-f37ef108d18f@github.com>
 <LsBjupG20ZvkAuKI-gFAPtdg3-glOkS2wAy15hRa-BM=.76ada238-5727-4975-898e-ed6cbadd6203@github.com>
Message-ID: <U2XAwC4slzGNftmkhhncKK7jhntf8zZxV5diF0MwESM=.e815da39-cb82-436b-ba7c-6bf05f4b5f1e@github.com>

On Tue, 14 Feb 2023 03:20:14 GMT, Sergey Kuksenko <skuksenko at openjdk.org> wrote:

>> [JDK-8269667](https://bugs.openjdk.org/browse/JDK-8269667) has uncovered the poor performance of BigDecimal.divide under certain circumstance.
>> 
>> We confront similar situations when benchmarking Spark3 on TPC-DS test kit. According to the flame-graph below, it is StripZeros that spends most of the time of BigDecimal.divide. Hence we propose this patch to optimize stripping zeros.
>> ![?? 1](https://user-images.githubusercontent.com/39413832/218062061-53cd0220-776e-4b72-8b9a-6b0f11707986.png)
>> 
>> Currently, createAndStripZerosToMatchScale() is performed linearly. That is, the target value is parsed from back to front, each time stripping out single ?0?. To optimize, we can adopt the method of binary search. That is, each time we try to strip out ${scale/2} ?0?s. 
>> 
>> The performance looks good. Therotically, time complexity of our method is O(log n), while the current one is O(n). In practice, benchmarks on Spark3 show that 1/3 less time (102s->68s) is spent on TPC-DS query4. We also runs Jtreg and JCK to check correctness, and it seems fine.
>> 
>> More about environment: 
>> we run Spark3.3.0 on Openjdk11, but it seems jdk version doesn?t have much impact on BigDecimal. Spark cluster consists of a main node and 2 core nodes, each has 4cores, 16g memory and 4x500GB storage.
>
> The pr looks promising in terms of performance.
> What makes sense to do:
> 
> *)  Don't rely on external benchmarks. It's fine if such exists, but anyway set of microbenchmarks (using JMH) will be much better. More clear, readable results, etc. E.g., it may show that other operations (for example, sqrt) were speeded up too.
> 
> *) Find boundaries. 
> "divideAndRemainder(bigTenToThe(scaleStep))" may produce non-zero reminder. Find conditions when it happens. How big is performance regression in such cases?
> 
> Some other optimizations:
> *)
> Current code checks only the lowest bit (odd or even) to cut off indivisible cases.
> Making "divideAndRemainder(bigTenToThe(scaleStep))"  - you make check scaleStep lowest bits to do cut off. See "BigInteger.getLowestSetBit()"
> 
> *)
> BigInteger division by int value is faster. It's a special case. What is faster, doing the single division by bigTenToThe(scaleStep) or doing several divisions (split scaleStep to fit into int)? Exploration is required.

@kuksenko Hi, I have updated the performance of this pr, I wonder if that's ok

-------------

PR: https://git.openjdk.org/jdk/pull/12509

From mdoerr at openjdk.org  Thu Feb 23 04:37:49 2023
From: mdoerr at openjdk.org (Martin Doerr)
Date: Thu, 23 Feb 2023 04:37:49 GMT
Subject: RFR: 8303040: linux PPC64le: Implementation of Foreign Function &
 Memory API (Preview) [v2]
In-Reply-To: <Yuxy6FrsDAN79ya8w8UIkvytGr25zGllDPtPJ1QbGwc=.182664b2-6d8c-497e-a4ae-95e0ad007cf9@github.com>
References: <Yuxy6FrsDAN79ya8w8UIkvytGr25zGllDPtPJ1QbGwc=.182664b2-6d8c-497e-a4ae-95e0ad007cf9@github.com>
Message-ID: <SZ9m3BFFwxhPqEQUx1LujV3bCXCdNdejuOTPJI0x7Wo=.74ffb1ac-5069-4e7d-afe4-d83cc550dbfc@github.com>

> Implementation of "Foreign Function & Memory API" for linux on Power (Little Endian) according to "Power Architecture 64-Bit ELF V2 ABI Specification".
> 
> This PR does not include code for VaList support because it's supposed to get removed by [JDK-8299736](https://bugs.openjdk.org/browse/JDK-8299736). I've kept the related tests disabled for this platform and throw an exception instead. Note that the ABI doesn't precisely specify variable argument lists. Instead, it refers to `<stdarg.h>` (2.2.4 Variable Argument Lists).
> 
> Big Endian support is implemented to some extend, but not complete. E.g. structs with size not divisible by 8 are not passed correctly (see `useABIv2` in CallArranger.java). Big Endian is excluded by selecting `ARCH.equals("ppc64le")` (CABI.java) only.
> 
> There's another limitation: This PR only accepts structures with size divisible by 4. (An `IllegalArgumentException` gets thrown otherwise.) I think arbitrary sizes are not usable on other platforms, either, because `SharedUtils.primitiveCarrierForSize` only accepts powers of 2.
> 
> The ABI has some tricky corner cases related to HFA (Homogeneous Float Aggregate). The same argument may need to get passed in both, a FP reg and a GP reg or stack slot (see "no partial DW rule"). This cases are not covered by the existing tests.
> 
> I had to make changes to shared code and code for other platforms:
> 1. Pass type information when creating `VMStorage` objects from `VMReg`. This is needed for the following reasons:
> - PPC64 ABI requires integer types to get extended to 64 bit (also see CCallingConventionRequiresIntsAsLongs in existing hotspot code). We need to know the type or at least the bit width for that.
> - Floating point load / store instructions need the correct width to select between the correct IEEE 754 formats. The register representation in single FP registers is always IEEE 754 double precision on PPC64.
> - Big Endian also needs usage of the precise size. Storing 8 Bytes and loading 4 Bytes yields different values than on Little Endian!
> 2. It happens that a `NativeMemorySegmentImpl` is used as a raw pointer (with byteSize() == 0) while running TestUpcallScope. Hence, existing size checks don't work (see MemorySegment.java). As a workaround, I'm just skipping the check in this particular case. Please check if this makes sense or if there's a better fix (possibly as separate RFE).

Martin Doerr has updated the pull request incrementally with one additional commit since the last revision:

  Clean fix for NativeMemorySegmentImpl issue with byteSize 0.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12708/files
  - new: https://git.openjdk.org/jdk/pull/12708/files/4a5debfc..7315fd20

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12708&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12708&range=00-01

  Stats: 6 lines in 2 files changed: 0 ins; 4 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/12708.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12708/head:pull/12708

PR: https://git.openjdk.org/jdk/pull/12708

From mdoerr at openjdk.org  Thu Feb 23 04:40:04 2023
From: mdoerr at openjdk.org (Martin Doerr)
Date: Thu, 23 Feb 2023 04:40:04 GMT
Subject: RFR: 8303040: linux PPC64le: Implementation of Foreign Function &
 Memory API (Preview) [v2]
In-Reply-To: <-TEFo_FkmQmlWADKNrtOBByV6R0wOrrsVxDtpwf7J7w=.16c3e1cc-4cd8-4157-ab2c-15b0be9454f8@github.com>
References: <Yuxy6FrsDAN79ya8w8UIkvytGr25zGllDPtPJ1QbGwc=.182664b2-6d8c-497e-a4ae-95e0ad007cf9@github.com>
 <-TEFo_FkmQmlWADKNrtOBByV6R0wOrrsVxDtpwf7J7w=.16c3e1cc-4cd8-4157-ab2c-15b0be9454f8@github.com>
Message-ID: <soBwchR-_xdNj-uFG0eZp1xt4LyLOFnzh1YlBLFTwsw=.f0707e4b-6831-4722-90e9-0839b53af181@github.com>

On Wed, 22 Feb 2023 18:31:45 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Martin Doerr has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Clean fix for NativeMemorySegmentImpl issue with byteSize 0.
>
> src/java.base/share/classes/java/lang/foreign/MemorySegment.java line 1359:
> 
>> 1357:         long size = elementCount * srcElementLayout.byteSize();
>> 1358:         srcImpl.checkAccess(srcOffset, size, true);
>> 1359:         if (dstImpl instanceof NativeMemorySegmentImpl && dstImpl.byteSize() == 0) {
> 
> As Jorn said, this change is not acceptable, as it allows bulk copy disregarding the segment real size. In such cases, the issue is always a missing unsafe resize somewhere in the linker code.

Removed this workaround. I'm glad to get rid of it.

-------------

PR: https://git.openjdk.org/jdk/pull/12708

From mdoerr at openjdk.org  Thu Feb 23 04:40:07 2023
From: mdoerr at openjdk.org (Martin Doerr)
Date: Thu, 23 Feb 2023 04:40:07 GMT
Subject: RFR: 8303040: linux PPC64le: Implementation of Foreign Function &
 Memory API (Preview) [v2]
In-Reply-To: <6Kr2C2phn8UoKIB6MbRn0o-0IuGo5BGFaVXVN9jS5Pg=.d59b2968-a811-487a-9775-d7a868bbbda7@github.com>
References: <Yuxy6FrsDAN79ya8w8UIkvytGr25zGllDPtPJ1QbGwc=.182664b2-6d8c-497e-a4ae-95e0ad007cf9@github.com>
 <6Kr2C2phn8UoKIB6MbRn0o-0IuGo5BGFaVXVN9jS5Pg=.d59b2968-a811-487a-9775-d7a868bbbda7@github.com>
Message-ID: <omca4XMShmQR1UCwQ1QBdi3XHv6LlOf5KyVCCo_5BBA=.ab058d67-5eb2-463b-80ca-e3353faab9ab@github.com>

On Wed, 22 Feb 2023 18:23:54 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Martin Doerr has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Clean fix for NativeMemorySegmentImpl issue with byteSize 0.
>
> src/java.base/share/classes/jdk/internal/foreign/PlatformLayouts.java line 266:
> 
>> 264:          * The {@code T*} native type.
>> 265:          */
>> 266:         public static final ValueLayout.OfAddress C_POINTER = ValueLayout.ADDRESS.withBitAlignment(64);
> 
> I think this is where the issue with the check in `MemorySegment::copy` comes from. Note how other platforms add a call to `asUnbounded` for the created layout, which makes any pointer boxed using this layout writable/readable (such as the in memory return pointer for upcalls).

Thanks for the hint! You found it pretty quickly. I had missed that when rebasing my early prototype. Fixed.

-------------

PR: https://git.openjdk.org/jdk/pull/12708

From mdoerr at openjdk.org  Thu Feb 23 04:47:05 2023
From: mdoerr at openjdk.org (Martin Doerr)
Date: Thu, 23 Feb 2023 04:47:05 GMT
Subject: RFR: 8303040: linux PPC64le: Implementation of Foreign Function &
 Memory API (Preview) [v2]
In-Reply-To: <SZ9m3BFFwxhPqEQUx1LujV3bCXCdNdejuOTPJI0x7Wo=.74ffb1ac-5069-4e7d-afe4-d83cc550dbfc@github.com>
References: <Yuxy6FrsDAN79ya8w8UIkvytGr25zGllDPtPJ1QbGwc=.182664b2-6d8c-497e-a4ae-95e0ad007cf9@github.com>
 <SZ9m3BFFwxhPqEQUx1LujV3bCXCdNdejuOTPJI0x7Wo=.74ffb1ac-5069-4e7d-afe4-d83cc550dbfc@github.com>
Message-ID: <ObvdkU6yekW6azQzDoM9-SGayZ5Y3ikHr-VM2TqYqFQ=.e19970d7-af19-4273-b2f7-c7dbb476b23f@github.com>

On Thu, 23 Feb 2023 04:37:49 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> Implementation of "Foreign Function & Memory API" for linux on Power (Little Endian) according to "Power Architecture 64-Bit ELF V2 ABI Specification".
>> 
>> This PR does not include code for VaList support because it's supposed to get removed by [JDK-8299736](https://bugs.openjdk.org/browse/JDK-8299736). I've kept the related tests disabled for this platform and throw an exception instead. Note that the ABI doesn't precisely specify variable argument lists. Instead, it refers to `<stdarg.h>` (2.2.4 Variable Argument Lists).
>> 
>> Big Endian support is implemented to some extend, but not complete. E.g. structs with size not divisible by 8 are not passed correctly (see `useABIv2` in CallArranger.java). Big Endian is excluded by selecting `ARCH.equals("ppc64le")` (CABI.java) only.
>> 
>> There's another limitation: This PR only accepts structures with size divisible by 4. (An `IllegalArgumentException` gets thrown otherwise.) I think arbitrary sizes are not usable on other platforms, either, because `SharedUtils.primitiveCarrierForSize` only accepts powers of 2.
>> 
>> The ABI has some tricky corner cases related to HFA (Homogeneous Float Aggregate). The same argument may need to get passed in both, a FP reg and a GP reg or stack slot (see "no partial DW rule"). This cases are not covered by the existing tests.
>> 
>> I had to make changes to shared code and code for other platforms:
>> 1. Pass type information when creating `VMStorage` objects from `VMReg`. This is needed for the following reasons:
>> - PPC64 ABI requires integer types to get extended to 64 bit (also see CCallingConventionRequiresIntsAsLongs in existing hotspot code). We need to know the type or at least the bit width for that.
>> - Floating point load / store instructions need the correct width to select between the correct IEEE 754 formats. The register representation in single FP registers is always IEEE 754 double precision on PPC64.
>> - Big Endian also needs usage of the precise size. Storing 8 Bytes and loading 4 Bytes yields different values than on Little Endian!
>> 2. It happens that a `NativeMemorySegmentImpl` is used as a raw pointer (with byteSize() == 0) while running TestUpcallScope. Hence, existing size checks don't work (see MemorySegment.java). As a workaround, I'm just skipping the check in this particular case. Please check if this makes sense or if there's a better fix (possibly as separate RFE).
>
> Martin Doerr has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Clean fix for NativeMemorySegmentImpl issue with byteSize 0.

> > (I'd be happy to implement the needed changes in shared code if you want, since it touches `BindingSpecializer` which is pretty dense)
> 
> FYI: [master...JornVernee:jdk:I2L](https://github.com/openjdk/jdk/compare/master...JornVernee:jdk:I2L) (assuming `I2L` has the same semantics as `extsw`). Then just add a `.cast(int.class, long.class)` wherever currently an `int` is `vmStore`d in the PPC CallArranger.

Correct, `extsw` performs a `I2L` conversion. I had thought about this already, but I think my current implementation is more efficient as it combines register moves with the 64 bit extend. Your proposal would generate separate extend and move instructions, right?

-------------

PR: https://git.openjdk.org/jdk/pull/12708

From mdoerr at openjdk.org  Thu Feb 23 04:56:02 2023
From: mdoerr at openjdk.org (Martin Doerr)
Date: Thu, 23 Feb 2023 04:56:02 GMT
Subject: RFR: 8303040: linux PPC64le: Implementation of Foreign Function &
 Memory API (Preview)
In-Reply-To: <GhLt8kfe9xOv5TKExx7dncFwLcXPw4uiwfntbmhY2Yg=.f8f36141-9a19-44b3-b10f-977d3e02c4af@github.com>
References: <Yuxy6FrsDAN79ya8w8UIkvytGr25zGllDPtPJ1QbGwc=.182664b2-6d8c-497e-a4ae-95e0ad007cf9@github.com>
 <GhLt8kfe9xOv5TKExx7dncFwLcXPw4uiwfntbmhY2Yg=.f8f36141-9a19-44b3-b10f-977d3e02c4af@github.com>
Message-ID: <4KT43N8FvdfdmoAeaXw1vEBMP20MhpV5RUTZzeD2DqQ=.39e184f4-e9a3-47bd-9cad-ed9fe51a0d7b@github.com>

On Wed, 22 Feb 2023 17:03:16 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

> I will do a more thorough review soon.

Thanks a lot!

> > The ABI has some tricky corner cases related to HFA (Homogeneous Float Aggregate). The same argument may need to get passed in both, a FP reg and a GP reg or stack slot (see "no partial DW rule"). This cases are not covered by the existing tests.
> 
> FWIW, we have to do this for Windows vararg floats as well ([here](https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/jdk/internal/foreign/abi/x64/windows/CallArranger.java#L231-L239))
> 
> This can be done by `dup`-ing the value, and using 2 `vmStore`s. (each `vmStore` corresponding to a single register/stack location). Doing something similar might be simpler than the `INTEGER_AND_FLOAT` and `STACK_AND_FLOAT` storage types you're using right now. I'm not sure if that is related to the other limitations you mention? Might be interesting to look into. (perhaps as a separate RFE. I don't have a big issue since the current approach stays in PPC-only code)

Maybe I need to think a bit more about it. I don't really like the extra cases for `INTEGER_AND_FLOAT` and `STACK_AND_FLOAT`. On the other side, doing it in the CallArranger would break the design of factoring out the allocation from the binding generation.
In addition, it seems like PPC64 is even more tricky than the Windows case. I need to pass 2 float arguments in a GP reg (or stack slot) plus one of these 2 floats in float register F13. I think this can get implemented more easily in the backend. Do you agree?

-------------

PR: https://git.openjdk.org/jdk/pull/12708

From mdoerr at openjdk.org  Thu Feb 23 06:18:49 2023
From: mdoerr at openjdk.org (Martin Doerr)
Date: Thu, 23 Feb 2023 06:18:49 GMT
Subject: RFR: 8303040: linux PPC64le: Implementation of Foreign Function &
 Memory API (Preview) [v3]
In-Reply-To: <Yuxy6FrsDAN79ya8w8UIkvytGr25zGllDPtPJ1QbGwc=.182664b2-6d8c-497e-a4ae-95e0ad007cf9@github.com>
References: <Yuxy6FrsDAN79ya8w8UIkvytGr25zGllDPtPJ1QbGwc=.182664b2-6d8c-497e-a4ae-95e0ad007cf9@github.com>
Message-ID: <8b3vVrV22RuhdRoRYacXV0ZeghFGgKkC8S_z-iMrzAQ=.dd84b743-8b51-4281-8f5f-f9eff6207bc7@github.com>

> Implementation of "Foreign Function & Memory API" for linux on Power (Little Endian) according to "Power Architecture 64-Bit ELF V2 ABI Specification".
> 
> This PR does not include code for VaList support because it's supposed to get removed by [JDK-8299736](https://bugs.openjdk.org/browse/JDK-8299736). I've kept the related tests disabled for this platform and throw an exception instead. Note that the ABI doesn't precisely specify variable argument lists. Instead, it refers to `<stdarg.h>` (2.2.4 Variable Argument Lists).
> 
> Big Endian support is implemented to some extend, but not complete. E.g. structs with size not divisible by 8 are not passed correctly (see `useABIv2` in CallArranger.java). Big Endian is excluded by selecting `ARCH.equals("ppc64le")` (CABI.java) only.
> 
> There's another limitation: This PR only accepts structures with size divisible by 4. (An `IllegalArgumentException` gets thrown otherwise.) I think arbitrary sizes are not usable on other platforms, either, because `SharedUtils.primitiveCarrierForSize` only accepts powers of 2.
> 
> The ABI has some tricky corner cases related to HFA (Homogeneous Float Aggregate). The same argument may need to get passed in both, a FP reg and a GP reg or stack slot (see "no partial DW rule"). This cases are not covered by the existing tests.
> 
> I had to make changes to shared code and code for other platforms:
> 1. Pass type information when creating `VMStorage` objects from `VMReg`. This is needed for the following reasons:
> - PPC64 ABI requires integer types to get extended to 64 bit (also see CCallingConventionRequiresIntsAsLongs in existing hotspot code). We need to know the type or at least the bit width for that.
> - Floating point load / store instructions need the correct width to select between the correct IEEE 754 formats. The register representation in single FP registers is always IEEE 754 double precision on PPC64.
> - Big Endian also needs usage of the precise size. Storing 8 Bytes and loading 4 Bytes yields different values than on Little Endian!
> 2. It happens that a `NativeMemorySegmentImpl` is used as a raw pointer (with byteSize() == 0) while running TestUpcallScope. Hence, existing size checks don't work (see MemorySegment.java). As a workaround, I'm just skipping the check in this particular case. Please check if this makes sense or if there's a better fix (possibly as separate RFE).

Martin Doerr has updated the pull request incrementally with one additional commit since the last revision:

  Remove size restriction for structs. Add TODO for Big Endian.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12708/files
  - new: https://git.openjdk.org/jdk/pull/12708/files/7315fd20..a4d844f7

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12708&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12708&range=01-02

  Stats: 3 lines in 1 file changed: 1 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/12708.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12708/head:pull/12708

PR: https://git.openjdk.org/jdk/pull/12708

From mdoerr at openjdk.org  Thu Feb 23 06:24:03 2023
From: mdoerr at openjdk.org (Martin Doerr)
Date: Thu, 23 Feb 2023 06:24:03 GMT
Subject: RFR: 8303040: linux PPC64le: Implementation of Foreign Function &
 Memory API (Preview) [v3]
In-Reply-To: <8b3vVrV22RuhdRoRYacXV0ZeghFGgKkC8S_z-iMrzAQ=.dd84b743-8b51-4281-8f5f-f9eff6207bc7@github.com>
References: <Yuxy6FrsDAN79ya8w8UIkvytGr25zGllDPtPJ1QbGwc=.182664b2-6d8c-497e-a4ae-95e0ad007cf9@github.com>
 <8b3vVrV22RuhdRoRYacXV0ZeghFGgKkC8S_z-iMrzAQ=.dd84b743-8b51-4281-8f5f-f9eff6207bc7@github.com>
Message-ID: <POQ0TzX45YoduJT-Dz1XcJyTxOYDlxRJZ8hJkqnGYZE=.f1f5b7cb-2fe4-4142-9ad4-85cdd10b3f1a@github.com>

On Thu, 23 Feb 2023 06:18:49 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> Implementation of "Foreign Function & Memory API" for linux on Power (Little Endian) according to "Power Architecture 64-Bit ELF V2 ABI Specification".
>> 
>> This PR does not include code for VaList support because it's supposed to get removed by [JDK-8299736](https://bugs.openjdk.org/browse/JDK-8299736). I've kept the related tests disabled for this platform and throw an exception instead. Note that the ABI doesn't precisely specify variable argument lists. Instead, it refers to `<stdarg.h>` (2.2.4 Variable Argument Lists).
>> 
>> Big Endian support is implemented to some extend, but not complete. E.g. structs with size not divisible by 8 are not passed correctly (see `useABIv2` in CallArranger.java). Big Endian is excluded by selecting `ARCH.equals("ppc64le")` (CABI.java) only.
>> 
>> There's another limitation: This PR only accepts structures with size divisible by 4. (An `IllegalArgumentException` gets thrown otherwise.) I think arbitrary sizes are not usable on other platforms, either, because `SharedUtils.primitiveCarrierForSize` only accepts powers of 2.
>> 
>> The ABI has some tricky corner cases related to HFA (Homogeneous Float Aggregate). The same argument may need to get passed in both, a FP reg and a GP reg or stack slot (see "no partial DW rule"). This cases are not covered by the existing tests.
>> 
>> I had to make changes to shared code and code for other platforms:
>> 1. Pass type information when creating `VMStorage` objects from `VMReg`. This is needed for the following reasons:
>> - PPC64 ABI requires integer types to get extended to 64 bit (also see CCallingConventionRequiresIntsAsLongs in existing hotspot code). We need to know the type or at least the bit width for that.
>> - Floating point load / store instructions need the correct width to select between the correct IEEE 754 formats. The register representation in single FP registers is always IEEE 754 double precision on PPC64.
>> - Big Endian also needs usage of the precise size. Storing 8 Bytes and loading 4 Bytes yields different values than on Little Endian!
>> 2. It happens that a `NativeMemorySegmentImpl` is used as a raw pointer (with byteSize() == 0) while running TestUpcallScope. Hence, existing size checks don't work (see MemorySegment.java). As a workaround, I'm just skipping the check in this particular case. Please check if this makes sense or if there's a better fix (possibly as separate RFE).
>
> Martin Doerr has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove size restriction for structs. Add TODO for Big Endian.

I have removed the size restriction for structs. Passing a struct consisting of 1 char works (on Little Endian). However, passing a struct consisting of 3 chars doesn't (getting IndexOutOfBoundsException: Out of bound access on segment MemorySegment). Neither on PPC64, nor on x86. Is that known or should I file a bug for that?

-------------

PR: https://git.openjdk.org/jdk/pull/12708

From alanb at openjdk.org  Thu Feb 23 07:17:06 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 23 Feb 2023 07:17:06 GMT
Subject: RFR: 8302806: (fs) Remove
 com.sun.nio.file.SensitivityWatchEventModifier [v3]
In-Reply-To: <BT4PUVkkM9_OrNDbIdxPEXYwNzDdBNbF4z1HtaVPw7E=.160b64c6-88ad-4132-9634-3dba35778190@github.com>
References: <FZn8ZF4sN5mtUO8MWPaC0N8nWFwTLkBvcqQeOPwVYeE=.a6e12227-dfa9-4817-adbb-bece72445860@github.com>
 <BT4PUVkkM9_OrNDbIdxPEXYwNzDdBNbF4z1HtaVPw7E=.160b64c6-88ad-4132-9634-3dba35778190@github.com>
Message-ID: <8-1tIXrVyhqH-Gp2xrkyHGCe5AsprzTXamgDpxxUHsc=.bf94a017-5730-4954-8e2e-d2384cba5653@github.com>

On Wed, 22 Feb 2023 23:35:08 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> This enum is not used in the JDK and did not appear in external source code searches.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8302806: Remove sensitivity from PollingWatchService

You need remove the SENSITIVITY_xxx constants from sun.nio.fs.ExtendedOptions and that will should help identify the code in the polling WatchService implementation that need to be removed.

-------------

PR: https://git.openjdk.org/jdk/pull/12626

From mdoerr at openjdk.org  Thu Feb 23 07:22:08 2023
From: mdoerr at openjdk.org (Martin Doerr)
Date: Thu, 23 Feb 2023 07:22:08 GMT
Subject: RFR: 8303040: linux PPC64le: Implementation of Foreign Function &
 Memory API (Preview) [v3]
In-Reply-To: <8b3vVrV22RuhdRoRYacXV0ZeghFGgKkC8S_z-iMrzAQ=.dd84b743-8b51-4281-8f5f-f9eff6207bc7@github.com>
References: <Yuxy6FrsDAN79ya8w8UIkvytGr25zGllDPtPJ1QbGwc=.182664b2-6d8c-497e-a4ae-95e0ad007cf9@github.com>
 <8b3vVrV22RuhdRoRYacXV0ZeghFGgKkC8S_z-iMrzAQ=.dd84b743-8b51-4281-8f5f-f9eff6207bc7@github.com>
Message-ID: <2lWqgBlo7fvu2MpVr3N46-03iI1Q49y1hqfd7uUBB58=.ba2a9ec5-c824-416d-a431-ca7e33019736@github.com>

On Thu, 23 Feb 2023 06:18:49 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> Implementation of "Foreign Function & Memory API" for linux on Power (Little Endian) according to "Power Architecture 64-Bit ELF V2 ABI Specification".
>> 
>> This PR does not include code for VaList support because it's supposed to get removed by [JDK-8299736](https://bugs.openjdk.org/browse/JDK-8299736). I've kept the related tests disabled for this platform and throw an exception instead. Note that the ABI doesn't precisely specify variable argument lists. Instead, it refers to `<stdarg.h>` (2.2.4 Variable Argument Lists).
>> 
>> Big Endian support is implemented to some extend, but not complete. E.g. structs with size not divisible by 8 are not passed correctly (see `useABIv2` in CallArranger.java). Big Endian is excluded by selecting `ARCH.equals("ppc64le")` (CABI.java) only.
>> 
>> There's another limitation: This PR only accepts structures with size divisible by 4. (An `IllegalArgumentException` gets thrown otherwise.) I think arbitrary sizes are not usable on other platforms, either, because `SharedUtils.primitiveCarrierForSize` only accepts powers of 2.
>> 
>> The ABI has some tricky corner cases related to HFA (Homogeneous Float Aggregate). The same argument may need to get passed in both, a FP reg and a GP reg or stack slot (see "no partial DW rule"). This cases are not covered by the existing tests.
>> 
>> I had to make changes to shared code and code for other platforms:
>> 1. Pass type information when creating `VMStorage` objects from `VMReg`. This is needed for the following reasons:
>> - PPC64 ABI requires integer types to get extended to 64 bit (also see CCallingConventionRequiresIntsAsLongs in existing hotspot code). We need to know the type or at least the bit width for that.
>> - Floating point load / store instructions need the correct width to select between the correct IEEE 754 formats. The register representation in single FP registers is always IEEE 754 double precision on PPC64.
>> - Big Endian also needs usage of the precise size. Storing 8 Bytes and loading 4 Bytes yields different values than on Little Endian!
>> 2. It happens that a `NativeMemorySegmentImpl` is used as a raw pointer (with byteSize() == 0) while running TestUpcallScope. Hence, existing size checks don't work (see MemorySegment.java). As a workaround, I'm just skipping the check in this particular case. Please check if this makes sense or if there's a better fix (possibly as separate RFE).
>
> Martin Doerr has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove size restriction for structs. Add TODO for Big Endian.

I should add tests for the tricky corner cases like the following ones:

EXPORT struct S_FF  f_S_S_FF(float p0, float p1, float p2, float p3, float p4, float p5, float p6, float p7, float p8, float p9, float p10, float p11, struct S_FF p12, float p13) { return p12; }
EXPORT float        f_F_S_FF(float p0, float p1, float p2, float p3, float p4, float p5, float p6, float p7, float p8, float p9, float p10, float p11, struct S_FF p12, float p13) { return p13; }
EXPORT struct S_FF  f_S_SSSSSSS_FF(struct S_FF p0, struct S_FF p1, struct S_FF p2, struct S_FF p3, struct S_FF p4, struct S_FF p5, struct S_FF p6, float p7) { return p6; }
EXPORT float        f_F_SSSSSSS_FF(struct S_FF p0, struct S_FF p1, struct S_FF p2, struct S_FF p3, struct S_FF p4, struct S_FF p5, struct S_FF p6, float p7) { return p7; }

Can I add them to the existing libraries? If so, what is the correct naming scheme and what is needed to get them executed (adding the EXPORT alone is not sufficient). Or should I create a separate test for these cases?
Advice will be appreciated!

-------------

PR: https://git.openjdk.org/jdk/pull/12708

From duke at openjdk.org  Thu Feb 23 07:24:09 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Thu, 23 Feb 2023 07:24:09 GMT
Subject: RFR: 8302871: Speed up StringLatin1.regionMatchesCI [v14]
In-Reply-To: <F0qyphqbltdnyRwcfKg96Vh2jkRtliefQlGBRuM7Zcc=.976fa82c-6ad8-4048-b0cf-b03683fa4ecd@github.com>
References: <dnsiX3nRffjGjZXJG7lMAZj2FktEl2Wc1XfFthQ4iJs=.8c41438a-80a4-468f-ae0b-7322c9d6d952@github.com>
 <F0qyphqbltdnyRwcfKg96Vh2jkRtliefQlGBRuM7Zcc=.976fa82c-6ad8-4048-b0cf-b03683fa4ecd@github.com>
Message-ID: <XED8lqe6CSvbat23n7oRTa-Ae1z4sTH_2WFffXTaVls=.ab7ddc41-314e-479a-a0e3-b99698fcc58d@github.com>

On Wed, 22 Feb 2023 20:01:52 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

>> This PR suggests we can speed up `StringLatin1.regionMatchesCI` by applying 'the oldest ASCII trick in the book'.
>> 
>> The new static method `CharacterDataLatin1.equalsIgnoreCase` compares two latin1 bytes for equality ignoring case. `StringLatin1.regionMatchesCI` is updated to use `equalsIgnoreCase`
>> 
>> To verify the correctness of `equalsIgnoreCase`, a new test is added  to `EqualsIgnoreCase` with an exhaustive verification that all 256x256 latin1 code point pairs have an `equalsIgnoreCase` consistent with Character.toUpperCase, Character.toLowerCase.
>> 
>> Performance is tested for matching and mismatching cases of code point pairs picked from the ASCII letter, ASCII number and latin1 letter ranges. Results in the first comment below.
>
> Eirik Bjorsnos 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:
> 
>  - Merge branch 'master' into regionmatches-latin1-speedup
>  - Merge branch 'master' into regionmatches-latin1-speedup
>  - Make the loop variables chars to avoid casting
>  - Use improved case-twiddling comment as suggested by Martin
>  - Replace 'oldest ASCII trick in the book' use in toUpperCase, toLowerCase with "by removing (setting) a single bit"
>  - Align local variable naming in toLowerCase, toUpperCase with equalsIgnoreCase by using 'lower' and 'upper'
>  - Rename unconventionally named local variable 'U' to 'upper'
>  - Merge remote-tracking branch 'origin/master' into regionmatches-latin1-speedup
>  - Add whitespace between methods
>  - Merge branch 'master' into regionmatches-latin1-speedup
>  - ... and 11 more: https://git.openjdk.org/jdk/compare/31689be3...597b346a

I found this in Appendix A of the 1973 `Draft Proposed Revision of ASCII`. Seems compatibility with existing 6-bit devices might have been the primary concern:


A 6.4 It is expected that devices having the capability of
printing only 64 graphic symbols will continue to be important.
It may be desirable to arrange these devices to print one symbol
for the bit pattern of both upper and lower case of a given
alphabetic letter. To facilitate this, there should be a single-
bit difference between the upper and lowercase representations
of any given letter. Combined with the requirement that a given
case of the alphabet be contiguous, this dictated the assignment
of the alphabet, as shown in columns 4 through 7.

<img width="932" alt="ascii" src="https://user-images.githubusercontent.com/300291/220842000-3efa64fe-9154-4069-9e81-e202d5731f6f.png">

https://ia800606.us.archive.org/17/items/enf-ascii-1972-1975/Image070917152640_text.pdf

-------------

PR: https://git.openjdk.org/jdk/pull/12632

From duke at openjdk.org  Thu Feb 23 07:44:07 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Thu, 23 Feb 2023 07:44:07 GMT
Subject: RFR: 8302871: Speed up StringLatin1.regionMatchesCI [v14]
In-Reply-To: <XED8lqe6CSvbat23n7oRTa-Ae1z4sTH_2WFffXTaVls=.ab7ddc41-314e-479a-a0e3-b99698fcc58d@github.com>
References: <dnsiX3nRffjGjZXJG7lMAZj2FktEl2Wc1XfFthQ4iJs=.8c41438a-80a4-468f-ae0b-7322c9d6d952@github.com>
 <F0qyphqbltdnyRwcfKg96Vh2jkRtliefQlGBRuM7Zcc=.976fa82c-6ad8-4048-b0cf-b03683fa4ecd@github.com>
 <XED8lqe6CSvbat23n7oRTa-Ae1z4sTH_2WFffXTaVls=.ab7ddc41-314e-479a-a0e3-b99698fcc58d@github.com>
Message-ID: <8heTHvSrS9Q2XvuOP1APjeSLy82m8fF9LHSFhCj7YTk=.b6beea59-eabc-4c48-af51-937e1a94d8e0@github.com>

On Thu, 23 Feb 2023 07:21:08 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

> Seems compatibility with existing 6-bit devices might have been the primary concern:

This also explains the placement of brackets, braces, bars, tilde etc. They would look visually similar on 6-bit devices:

<img width="915" alt="image" src="https://user-images.githubusercontent.com/300291/220845393-de12301a-73e2-46fe-a6ce-ce101d0a2b3b.png">

-------------

PR: https://git.openjdk.org/jdk/pull/12632

From dholmes at openjdk.org  Thu Feb 23 08:05:05 2023
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 23 Feb 2023 08:05:05 GMT
Subject: RFR: 8302976: C2 intrinsification of Float.floatToFloat16 and
 Float.float16ToFloat yields different result than the interpreter
In-Reply-To: <f18TfSibBBm5FLon1VlUN0m6fNUzvOpsUeo7nEAk7JY=.456ddc51-7be7-4484-ad38-1039453b83d6@github.com>
References: <f18TfSibBBm5FLon1VlUN0m6fNUzvOpsUeo7nEAk7JY=.456ddc51-7be7-4484-ad38-1039453b83d6@github.com>
Message-ID: <ZVCzVc-0YgyVrcbbgj5t7d-E_7g0bVkRpSbxu-WemHI=.2a1eb2d5-335b-4de6-9e63-04aca3293dbb@github.com>

On Wed, 22 Feb 2023 02:08:27 GMT, Sandhya Viswanathan <sviswanathan at openjdk.org> wrote:

> Change the java/lang/float.java and the corresponding shared runtime constant expression evaluation to generate QNaN.
> The HW instructions generate QNaNs and not SNaNs for floating point instructions. This happens across double, float, and float16 data types. The most significant bit of mantissa is set to 1 for QNaNs.

Changing the Java code to match the semantics of a given architecture's HW instruction risks requiring that other architectures have to implement additional code to match those semantics, potentially impacting the benefit of using an intrinsic in the first place.

Consistent output across all execution contexts is certainly a desirable quality, but at what cost?

-------------

PR: https://git.openjdk.org/jdk/pull/12704

From alanb at openjdk.org  Thu Feb 23 08:31:36 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 23 Feb 2023 08:31:36 GMT
Subject: RFR: 8302899: Executors.newSingleThreadExecutor can use Cleaner to
 shutdown executor [v4]
In-Reply-To: <tBrSZRn1GdrWMSRUsdNNyAWpkuS_FvtLwLuUKut6LH0=.cd1a7fcb-dbcf-45eb-b3d3-72ba17087566@github.com>
References: <tBrSZRn1GdrWMSRUsdNNyAWpkuS_FvtLwLuUKut6LH0=.cd1a7fcb-dbcf-45eb-b3d3-72ba17087566@github.com>
Message-ID: <gCqs5Difq993oMhXzOthVrWAHqCTCQefqYqSF_BP-Dc=.6ecb5e0a-cd13-4936-b0ab-245edc9898e8@github.com>

> Executors.newSingleThreadExecutor returns a delegating ExecutorService that has finalizer to shutdown the underlying TPE when the wrapper is finalizable. It goes back to JDK 6 and JDK-6399443. This is the last non-empty finalizer in java.base. Removing it will likely lead to bug reports/complaints as the current behavior goes back to 2006. So the proposal is to just replace it with a Cleaner, trivially done in this case. As part of the changes, I've replaced the existing test with a more modern test that exercises more scenarios.

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
 - Improve SM scenario
 - Keep reference to Cleanable
 - Merge
 - Fix typo in comment, remove blank line
 - Replace older test
 - Initial commit

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12675/files
  - new: https://git.openjdk.org/jdk/pull/12675/files/3b135f09..449f72b6

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12675&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12675&range=02-03

  Stats: 1834 lines in 125 files changed: 1323 ins; 293 del; 218 mod
  Patch: https://git.openjdk.org/jdk/pull/12675.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12675/head:pull/12675

PR: https://git.openjdk.org/jdk/pull/12675

From redestad at openjdk.org  Thu Feb 23 08:35:04 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Thu, 23 Feb 2023 08:35:04 GMT
Subject: RFR: 8301119: Support for GB18030-2022 [v2]
In-Reply-To: <C8Fp0qE368HZbCo1tQIMBh44wZ19PyfQFcKlKWKcYnc=.1bbcec03-19ad-4f98-aff5-669ab82f2c0a@github.com>
References: <FXBchbCnbNloQO7Nlh9Ijue_c_YugGk-UC7_-ZAjY2o=.7e1ca01f-8cee-40bb-bb06-6e5670abe661@github.com>
 <S6p8hZiWOrDpXAzaeJ3L4kOIferQtFHKmFaa_1gNTyo=.0a245135-1bf9-47a1-b992-36edcbc2d612@github.com>
 <Fo1WnNOBMptjHkVUUtdvx4p03Ci1ljacM9bkFux2Qus=.b8082d30-35e9-491e-88a0-d00105f4381b@github.com>
 <C8Fp0qE368HZbCo1tQIMBh44wZ19PyfQFcKlKWKcYnc=.1bbcec03-19ad-4f98-aff5-669ab82f2c0a@github.com>
Message-ID: <yG5N8VCa7i5JK8uFGZ4am4f5YfkKNPRLn5f5eYox51A=.123fd849-517e-444d-b479-984bc39888de@github.com>

On Wed, 22 Feb 2023 17:52:01 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>>> curious - what scenario triggers this call at initLevel < 1 ?
>> 
>> It's not supported, but it is possible that someone might run with -Dfile.encoding=GB18030, in which case the default charset is used before the system properties are initialized in initPhase1. Checking the init level breaks the circularity, the only downside is that can't switch to GB18030-2000 at the same time.
>
> `Charset` class is initialized *before* system properties are set up, in order to check the JNU encoding (used for file path name) is a supported charset or not. In some OS environments, GB18030 is the native encoding so we need to avoid checking the system property in such a case.

`@Stable` semantics are still fuzzy to me but the rule I've adhered to is that back to back stores to the field - if unavoidable - needs to be idempotent since the JIT (or AOT) may record any non-null value as a compile time constant at any time.

I'd write this to not update the static field if initLevel() < 1. Such calls should be rare and only happen once on a system that has GB18030 as their native encoding.

-------------

PR: https://git.openjdk.org/jdk/pull/12518

From jlu at openjdk.org  Thu Feb 23 08:48:45 2023
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 23 Feb 2023 08:48:45 GMT
Subject: RFR: 8282319: java.util.Locale method to stream available Locales
Message-ID: <QxcV7IwdW13WfT0X0PKyWBWpo_rP588AgHIYiUu3E_Q=.82b88828-e8ec-4f3c-a75a-ec88b589d4e2@github.com>

This PR proposes introducing a new method to Locale which returns Stream<Locale>

It involves adding an additional method to _LocaleServiceProviderPool_ that returns Stream, which _Locale_ can call.

`LocaleServiceProviderPool.streamAllAvaliableLocales()` does not need a defensive copy of `AllAvailableLocales.allAvailableLocales` unlike `LocaleServiceProviderPool.getAllAvaliableLocales()` as the array is hidden by the Stream.

-------------

Commit messages:
 - Adjust test for new method name
 - Update specification for method
 - Update impl to use @since, {@return..., @implNote
 - Further revert of name change
 - Revert changed var name
 - There is no need to retain the set, Stream the array directly
 - Adjust err msg
 - Run w/ data provider
 - Tweak var names
 - Merge branch 'master' into 8282319-Locale-Stream
 - ... and 2 more: https://git.openjdk.org/jdk/compare/7eff5787...6df5c168

Changes: https://git.openjdk.org/jdk/pull/12269/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12269&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8282319
  Stats: 115 lines in 3 files changed: 112 ins; 1 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/12269.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12269/head:pull/12269

PR: https://git.openjdk.org/jdk/pull/12269

From stsypanov at openjdk.org  Thu Feb 23 08:48:47 2023
From: stsypanov at openjdk.org (Sergey Tsypanov)
Date: Thu, 23 Feb 2023 08:48:47 GMT
Subject: RFR: 8282319: java.util.Locale method to stream available Locales
In-Reply-To: <QxcV7IwdW13WfT0X0PKyWBWpo_rP588AgHIYiUu3E_Q=.82b88828-e8ec-4f3c-a75a-ec88b589d4e2@github.com>
References: <QxcV7IwdW13WfT0X0PKyWBWpo_rP588AgHIYiUu3E_Q=.82b88828-e8ec-4f3c-a75a-ec88b589d4e2@github.com>
Message-ID: <7WL_dTHmieqFW3T-zx85ElASEk8SkC9W74d4RDzUjOA=.0f03ae8c-e204-4722-9d9b-727104c0ad99@github.com>

On Fri, 27 Jan 2023 21:48:26 GMT, Justin Lu <jlu at openjdk.org> wrote:

> This PR proposes introducing a new method to Locale which returns Stream<Locale>
> 
> It involves adding an additional method to _LocaleServiceProviderPool_ that returns Stream, which _Locale_ can call.
> 
> `LocaleServiceProviderPool.streamAllAvaliableLocales()` does not need a defensive copy of `AllAvailableLocales.allAvailableLocales` unlike `LocaleServiceProviderPool.getAllAvaliableLocales()` as the array is hidden by the Stream.

src/java.base/share/classes/sun/util/locale/provider/LocaleServiceProviderPool.java line 160:

> 158:      */
> 159:     public static Stream<Locale> streamAvailableLocales() {
> 160:         return AllAvailableLocales.AvailableLocalesSet.stream();

I think we could use `Stream.of(AllAvailableLocales.availableLocalesArray)` here and drop set field.

-------------

PR: https://git.openjdk.org/jdk/pull/12269

From jlu at openjdk.org  Thu Feb 23 08:48:48 2023
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 23 Feb 2023 08:48:48 GMT
Subject: RFR: 8282319: java.util.Locale method to stream available Locales
In-Reply-To: <7WL_dTHmieqFW3T-zx85ElASEk8SkC9W74d4RDzUjOA=.0f03ae8c-e204-4722-9d9b-727104c0ad99@github.com>
References: <QxcV7IwdW13WfT0X0PKyWBWpo_rP588AgHIYiUu3E_Q=.82b88828-e8ec-4f3c-a75a-ec88b589d4e2@github.com>
 <7WL_dTHmieqFW3T-zx85ElASEk8SkC9W74d4RDzUjOA=.0f03ae8c-e204-4722-9d9b-727104c0ad99@github.com>
Message-ID: <xX7L_i5MrVzYX2z5HYWHurPaYiS6mwHjhVZho8IG8So=.c996fca2-a6f1-4f53-9056-771f0a434565@github.com>

On Mon, 30 Jan 2023 07:11:57 GMT, Sergey Tsypanov <stsypanov at openjdk.org> wrote:

>> This PR proposes introducing a new method to Locale which returns Stream<Locale>
>> 
>> It involves adding an additional method to _LocaleServiceProviderPool_ that returns Stream, which _Locale_ can call.
>> 
>> `LocaleServiceProviderPool.streamAllAvaliableLocales()` does not need a defensive copy of `AllAvailableLocales.allAvailableLocales` unlike `LocaleServiceProviderPool.getAllAvaliableLocales()` as the array is hidden by the Stream.
>
> src/java.base/share/classes/sun/util/locale/provider/LocaleServiceProviderPool.java line 160:
> 
>> 158:      */
>> 159:     public static Stream<Locale> streamAvailableLocales() {
>> 160:         return AllAvailableLocales.AvailableLocalesSet.stream();
> 
> I think we could use `Stream.of(AllAvailableLocales.availableLocalesArray)` here and drop set field.

Yes you're right, I had misinterpreted the original bug description. Set is not required, and in fact the array should be streamed directly as you said.

-------------

PR: https://git.openjdk.org/jdk/pull/12269

From redestad at openjdk.org  Thu Feb 23 08:58:02 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Thu, 23 Feb 2023 08:58:02 GMT
Subject: RFR: 8301119: Support for GB18030-2022 [v2]
In-Reply-To: <yG5N8VCa7i5JK8uFGZ4am4f5YfkKNPRLn5f5eYox51A=.123fd849-517e-444d-b479-984bc39888de@github.com>
References: <FXBchbCnbNloQO7Nlh9Ijue_c_YugGk-UC7_-ZAjY2o=.7e1ca01f-8cee-40bb-bb06-6e5670abe661@github.com>
 <S6p8hZiWOrDpXAzaeJ3L4kOIferQtFHKmFaa_1gNTyo=.0a245135-1bf9-47a1-b992-36edcbc2d612@github.com>
 <Fo1WnNOBMptjHkVUUtdvx4p03Ci1ljacM9bkFux2Qus=.b8082d30-35e9-491e-88a0-d00105f4381b@github.com>
 <C8Fp0qE368HZbCo1tQIMBh44wZ19PyfQFcKlKWKcYnc=.1bbcec03-19ad-4f98-aff5-669ab82f2c0a@github.com>
 <yG5N8VCa7i5JK8uFGZ4am4f5YfkKNPRLn5f5eYox51A=.123fd849-517e-444d-b479-984bc39888de@github.com>
Message-ID: <wO2OP3VuH8E8OF6GSkl0a-c6b6Sy1np5d2ThZO1sj1A=.4bb265be-df50-46cc-9976-2334f6f1e9ba@github.com>

On Thu, 23 Feb 2023 08:32:29 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> `Charset` class is initialized *before* system properties are set up, in order to check the JNU encoding (used for file path name) is a supported charset or not. In some OS environments, GB18030 is the native encoding so we need to avoid checking the system property in such a case.
>
> `@Stable` semantics are still fuzzy to me but the rule I've adhered to is that back to back stores to the field - if unavoidable - needs to be idempotent since the JIT (or AOT) may record any non-null value as a compile time constant at any time.
> 
> I'd write this to not update the static field if initLevel() < 1. Such calls should be rare and only happen once on a system that has GB18030 as their native encoding.

Scratch that: as it seems to be important that we don't switch after startup then what this code is really reaching for is `static final` field semantics. Since `StandardCharsets` might be loaded very early a holder class pattern might be necessary:


    isGB18030_2000() { return GB18030Properties.GB18030_2000; }

    private static class GB18030Properties {
        private static final GB18030_2000 = init();
        private static boolean init() {
            if (VM.initLevel() < 1) {
                // Cannot get the system property yet. Assumes non-2000
                return false;
            }
            return "2000".equals(GetPropertyAction.privilegedGetProperty("jdk.charset.GB18030"));
        }
    }

-------------

PR: https://git.openjdk.org/jdk/pull/12518

From alanb at openjdk.org  Thu Feb 23 09:07:10 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 23 Feb 2023 09:07:10 GMT
Subject: RFR: 8301119: Support for GB18030-2022 [v2]
In-Reply-To: <wO2OP3VuH8E8OF6GSkl0a-c6b6Sy1np5d2ThZO1sj1A=.4bb265be-df50-46cc-9976-2334f6f1e9ba@github.com>
References: <FXBchbCnbNloQO7Nlh9Ijue_c_YugGk-UC7_-ZAjY2o=.7e1ca01f-8cee-40bb-bb06-6e5670abe661@github.com>
 <S6p8hZiWOrDpXAzaeJ3L4kOIferQtFHKmFaa_1gNTyo=.0a245135-1bf9-47a1-b992-36edcbc2d612@github.com>
 <Fo1WnNOBMptjHkVUUtdvx4p03Ci1ljacM9bkFux2Qus=.b8082d30-35e9-491e-88a0-d00105f4381b@github.com>
 <C8Fp0qE368HZbCo1tQIMBh44wZ19PyfQFcKlKWKcYnc=.1bbcec03-19ad-4f98-aff5-669ab82f2c0a@github.com>
 <yG5N8VCa7i5JK8uFGZ4am4f5YfkKNPRLn5f5eYox51A=.123fd849-517e-444d-b479-984bc39888de@github.com>
 <wO2OP3VuH8E8OF6GSkl0a-c6b6Sy1np5d2ThZO1sj1A=.4bb265be-df50-46cc-9976-2334f6f1e9ba@github.com>
Message-ID: <jpkQafw1j_0fH0-cumhhoGpqMqfqFXCG-4lHUckF66I=.6e01f41d-7854-4c5a-be59-0eb5e4a78a49@github.com>

On Thu, 23 Feb 2023 08:55:08 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> `@Stable` semantics are still fuzzy to me but the rule I've adhered to is that back to back stores to the field - if unavoidable - needs to be idempotent since the JIT (or AOT) may record any non-null value as a compile time constant at any time.
>> 
>> I'd write this to not update the static field if initLevel() < 1. Such calls should be rare and only happen once on a system that has GB18030 as their native encoding.
>
> Scratch that: as it seems to be important that we don't switch after startup then what this code is really reaching for is `static final` field semantics. Since `StandardCharsets` might be loaded very early a holder class pattern might be necessary:
> 
> 
>     isGB18030_2000() { return GB18030Properties.GB18030_2000; }
> 
>     private static class GB18030Properties {
>         private static final GB18030_2000 = init();
>         private static boolean init() {
>             if (VM.initLevel() < 1) {
>                 // Cannot get the system property yet. Assumes non-2000
>                 return false;
>             }
>             return "2000".equals(GetPropertyAction.privilegedGetProperty("jdk.charset.GB18030"));
>         }
>     }

Right, doing nothing for the initLevel < 1 case means that  `-Dfile.encoding=GB18030 -Djdk.charset.GB18030=2000` would use version 2022 in early startup (JNU encoding init) and then switch to version 2000. Using a holder class seems a better idea than trying to coordinate concurrent writers.

-------------

PR: https://git.openjdk.org/jdk/pull/12518

From duke at openjdk.org  Thu Feb 23 09:13:42 2023
From: duke at openjdk.org (Viktor Klang)
Date: Thu, 23 Feb 2023 09:13:42 GMT
Subject: RFR: JDK-8297605 DelayQueue javadoc is confusing
Message-ID: <RileEs0r_cfhESPODINk_sRE-Fq--_jJGEFqucn2YzU=.4efb95d9-333d-477d-a711-e1024200c260@github.com>

Clarifies the distinction between expiration of the head of DelayQueue and how it relates to `poll`, `take`, and `peek`. See discussion on https://bugs.openjdk.org/browse/JDK-8297605

@DougLea If possible, please weigh in on whether this is in line with your thoughts on the matter.

-------------

Commit messages:
 - JDK-8297605 DelayQueue javadoc is confusing

Changes: https://git.openjdk.org/jdk/pull/12727/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12727&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8297605
  Stats: 14 lines in 1 file changed: 1 ins; 1 del; 12 mod
  Patch: https://git.openjdk.org/jdk/pull/12727.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12727/head:pull/12727

PR: https://git.openjdk.org/jdk/pull/12727

From duke at openjdk.org  Thu Feb 23 09:34:09 2023
From: duke at openjdk.org (Kasper Nielsen)
Date: Thu, 23 Feb 2023 09:34:09 GMT
Subject: RFR: 8302154: Hidden classes created by LambdaMetaFactory can't be
 unloaded [v2]
In-Reply-To: <rInYVnkiymZwIqKu5XxwDoMAViRD8adc7C3P3bvsmTI=.eaeac812-edcc-472e-b032-f4b0cde80f45@github.com>
References: <YoZauVv8zvhdUw-LD25LrsMDItFbg3aXPU3deXwwFdQ=.c2839dea-12e5-4e0e-9579-eac9d8503932@github.com>
 <gKoLpwlXDxp2uaSKSkMArJl1Ym9VX1hoDFqQTTUpk8w=.e1dce669-5a42-4b66-ac4b-205718c8eb81@github.com>
 <0ZZLsRlr6IO4jL2VKAcn4geYptqUOdYPUXbd-KQiApo=.d1b3ca63-ca4a-4eef-9d5e-88cc3418ada9@github.com>
 <rInYVnkiymZwIqKu5XxwDoMAViRD8adc7C3P3bvsmTI=.eaeac812-edcc-472e-b032-f4b0cde80f45@github.com>
Message-ID: <Hqcj76UdcDybDn-I7lyQLZxJaeM9ztMUu7DScDvs2G8=.81e630e3-8e1a-4334-a77a-1cc12a8d2c32@github.com>

On Wed, 22 Feb 2023 21:29:12 GMT, R?mi Forax <forax at openjdk.org> wrote:

>> In all the places I've seen LambdaMetaFactory used, it is because of performance over reflection/non-static method handles. See, for example, https://www.optaplanner.org/blog/2018/01/09/JavaReflectionButMuchFaster.html. I believe Optaplanner is still using it.
>> 
>> There is also quite a number of posts on StackOverflow on people trying to use LambdaMetafactory:
>> https://stackoverflow.com/search?q=LambdaMetafactory
>
> @kaspernielsen, i believe that now that hidden class + class data are part of the public API,
> you do not need to use lambda metafactory directly. But it requires Java 17 not 8 or 11.

@forax I think what attracted people was that you didn't have to add any dependencies (ASM). It is also simpler than having to deal with class files. Maybe once we get the Classfile API people will reconsider. Still, LambdaMetaFactory is just a couple of lines of code. So will probably be hard to resist for some people.

-------------

PR: https://git.openjdk.org/jdk/pull/12493

From coffeys at openjdk.org  Thu Feb 23 09:51:06 2023
From: coffeys at openjdk.org (Sean Coffey)
Date: Thu, 23 Feb 2023 09:51:06 GMT
Subject: RFR: 8301119: Support for GB18030-2022 [v2]
In-Reply-To: <jpkQafw1j_0fH0-cumhhoGpqMqfqFXCG-4lHUckF66I=.6e01f41d-7854-4c5a-be59-0eb5e4a78a49@github.com>
References: <FXBchbCnbNloQO7Nlh9Ijue_c_YugGk-UC7_-ZAjY2o=.7e1ca01f-8cee-40bb-bb06-6e5670abe661@github.com>
 <S6p8hZiWOrDpXAzaeJ3L4kOIferQtFHKmFaa_1gNTyo=.0a245135-1bf9-47a1-b992-36edcbc2d612@github.com>
 <Fo1WnNOBMptjHkVUUtdvx4p03Ci1ljacM9bkFux2Qus=.b8082d30-35e9-491e-88a0-d00105f4381b@github.com>
 <C8Fp0qE368HZbCo1tQIMBh44wZ19PyfQFcKlKWKcYnc=.1bbcec03-19ad-4f98-aff5-669ab82f2c0a@github.com>
 <yG5N8VCa7i5JK8uFGZ4am4f5YfkKNPRLn5f5eYox51A=.123fd849-517e-444d-b479-984bc39888de@github.com>
 <wO2OP3VuH8E8OF6GSkl0a-c6b6Sy1np5d2ThZO1sj1A=.4bb265be-df50-46cc-9976-2334f6f1e9ba@github.com>
 <jpkQafw1j_0fH0-cumhhoGpqMqfqFXCG-4lHUckF66I=.6e01f41d-7854-4c5a-be59-0eb5e4a78a49@github.com>
Message-ID: <ljBTRKBiP-miZ-LTBn4BKKgWtuB-EB8woNMy74YaN68=.4ebd8a62-371d-4dc1-a441-08fa03913f4f@github.com>

On Thu, 23 Feb 2023 09:03:49 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Scratch that: as it seems to be important that we don't switch after startup then what this code is really reaching for is `static final` field semantics. Since `StandardCharsets` might be loaded very early a holder class pattern might be necessary:
>> 
>> 
>>     isGB18030_2000() { return GB18030Properties.GB18030_2000; }
>> 
>>     private static class GB18030Properties {
>>         private static final GB18030_2000 = init();
>>         private static boolean init() {
>>             if (VM.initLevel() < 1) {
>>                 // Cannot get the system property yet. Assumes non-2000
>>                 return false;
>>             }
>>             return "2000".equals(GetPropertyAction.privilegedGetProperty("jdk.charset.GB18030"));
>>         }
>>     }
>
> Right, doing nothing for the initLevel < 1 case means that  `-Dfile.encoding=GB18030 -Djdk.charset.GB18030=2000` would use version 2022 in early startup (JNU encoding init) and then switch to version 2000. Using a holder class seems a better idea than trying to coordinate concurrent writers.

would use of jdk.internal.util.SystemProps be an option here (if having to retrieve that value when we're at VM init level <1 ?

-------------

PR: https://git.openjdk.org/jdk/pull/12518

From alanb at openjdk.org  Thu Feb 23 10:10:08 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 23 Feb 2023 10:10:08 GMT
Subject: RFR: 8301119: Support for GB18030-2022 [v2]
In-Reply-To: <ljBTRKBiP-miZ-LTBn4BKKgWtuB-EB8woNMy74YaN68=.4ebd8a62-371d-4dc1-a441-08fa03913f4f@github.com>
References: <FXBchbCnbNloQO7Nlh9Ijue_c_YugGk-UC7_-ZAjY2o=.7e1ca01f-8cee-40bb-bb06-6e5670abe661@github.com>
 <S6p8hZiWOrDpXAzaeJ3L4kOIferQtFHKmFaa_1gNTyo=.0a245135-1bf9-47a1-b992-36edcbc2d612@github.com>
 <Fo1WnNOBMptjHkVUUtdvx4p03Ci1ljacM9bkFux2Qus=.b8082d30-35e9-491e-88a0-d00105f4381b@github.com>
 <C8Fp0qE368HZbCo1tQIMBh44wZ19PyfQFcKlKWKcYnc=.1bbcec03-19ad-4f98-aff5-669ab82f2c0a@github.com>
 <yG5N8VCa7i5JK8uFGZ4am4f5YfkKNPRLn5f5eYox51A=.123fd849-517e-444d-b479-984bc39888de@github.com>
 <wO2OP3VuH8E8OF6GSkl0a-c6b6Sy1np5d2ThZO1sj1A=.4bb265be-df50-46cc-9976-2334f6f1e9ba@github.com>
 <jpkQafw1j_0fH0-cumhhoGpqMqfqFXCG-4lHUckF66I=.6e01f41d-7854-4c5a-be59-0eb5e4a78a49@github.com>
 <ljBTRKBiP-miZ-LTBn4BKKgWtuB-EB8woNMy74YaN68=.4ebd8a62-371d-4dc1-a441-08fa03913f4f@github.com>
Message-ID: <DZeiL86cxzx9DTJMKK5mvr8ywYt0TTP5V2ex3BkWjKM=.13f06b0c-f341-4b53-9f47-d275135d369f@github.com>

On Thu, 23 Feb 2023 09:48:39 GMT, Sean Coffey <coffeys at openjdk.org> wrote:

> would use of jdk.internal.util.SystemProps be an option here (if having to retrieve that value when we're at VM init level <1 ?

The early startup scenario is early in the system property initialization, specifically SystemProps.Raw.<clinit> which will cause the encoding to be initialized. This has to avoid make use of system properties, otherwise you get a circular initialization issue.

-------------

PR: https://git.openjdk.org/jdk/pull/12518

From mcimadamore at openjdk.org  Thu Feb 23 10:18:08 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 23 Feb 2023 10:18:08 GMT
Subject: RFR: 8303040: linux PPC64le: Implementation of Foreign Function &
 Memory API (Preview) [v3]
In-Reply-To: <2lWqgBlo7fvu2MpVr3N46-03iI1Q49y1hqfd7uUBB58=.ba2a9ec5-c824-416d-a431-ca7e33019736@github.com>
References: <Yuxy6FrsDAN79ya8w8UIkvytGr25zGllDPtPJ1QbGwc=.182664b2-6d8c-497e-a4ae-95e0ad007cf9@github.com>
 <8b3vVrV22RuhdRoRYacXV0ZeghFGgKkC8S_z-iMrzAQ=.dd84b743-8b51-4281-8f5f-f9eff6207bc7@github.com>
 <2lWqgBlo7fvu2MpVr3N46-03iI1Q49y1hqfd7uUBB58=.ba2a9ec5-c824-416d-a431-ca7e33019736@github.com>
Message-ID: <ACdRQT2VWL6V4ENKneuLIcYGicnrQE9cueUicVxlpoU=.b5a3f8a0-9e9e-4785-90e0-c0cf2b947900@github.com>

On Thu, 23 Feb 2023 07:19:24 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

> 
> Can I add them to the existing libraries? If so, what is the correct naming scheme and what is needed to get them executed (adding the EXPORT alone is not sufficient). Or should I create a separate test for these cases? Advice will be appreciated!

There are two kinds of tests for the linker - some tests (e.g. TestDowncallXYZ and TestUpcallXYZ) execute end to end test with several shapes, and make sure that things work.

Then there are ABI specific tests (e.g. see TestXYZCallArranger). These latter tests are typically used to stress tests corners of specific ABIs - and they are easier to write as you can just provide the input (some function descriptor) then test that the resulting set of bindings is the expected one. This allows for much more in-depth testing.

-------------

PR: https://git.openjdk.org/jdk/pull/12708

From mcimadamore at openjdk.org  Thu Feb 23 10:23:05 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 23 Feb 2023 10:23:05 GMT
Subject: RFR: 8303040: linux PPC64le: Implementation of Foreign Function &
 Memory API (Preview) [v2]
In-Reply-To: <ObvdkU6yekW6azQzDoM9-SGayZ5Y3ikHr-VM2TqYqFQ=.e19970d7-af19-4273-b2f7-c7dbb476b23f@github.com>
References: <Yuxy6FrsDAN79ya8w8UIkvytGr25zGllDPtPJ1QbGwc=.182664b2-6d8c-497e-a4ae-95e0ad007cf9@github.com>
 <SZ9m3BFFwxhPqEQUx1LujV3bCXCdNdejuOTPJI0x7Wo=.74ffb1ac-5069-4e7d-afe4-d83cc550dbfc@github.com>
 <ObvdkU6yekW6azQzDoM9-SGayZ5Y3ikHr-VM2TqYqFQ=.e19970d7-af19-4273-b2f7-c7dbb476b23f@github.com>
Message-ID: <3dzZfm_BSXLL_iWAmllX-8YXAe1NWMMPr11zJtedIWU=.8a1dd1df-4eb7-4c72-9a06-f4636e5ec3e4@github.com>

On Thu, 23 Feb 2023 04:44:18 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

> 
> Correct, `extsw` performs a `I2L` conversion. I had thought about this already, but I think my current implementation is more efficient as it combines register moves with the 64 bit extend. Your proposal would generate separate extend and move instructions, right?

Would it be possible to generate a biding cast + move and the recognize the pattern in the HS backend and optimize it away as a `extsw` ?

-------------

PR: https://git.openjdk.org/jdk/pull/12708

From dfuchs at openjdk.org  Thu Feb 23 12:11:10 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 23 Feb 2023 12:11:10 GMT
Subject: RFR: 8302899: Executors.newSingleThreadExecutor can use Cleaner to
 shutdown executor [v4]
In-Reply-To: <gCqs5Difq993oMhXzOthVrWAHqCTCQefqYqSF_BP-Dc=.6ecb5e0a-cd13-4936-b0ab-245edc9898e8@github.com>
References: <tBrSZRn1GdrWMSRUsdNNyAWpkuS_FvtLwLuUKut6LH0=.cd1a7fcb-dbcf-45eb-b3d3-72ba17087566@github.com>
 <gCqs5Difq993oMhXzOthVrWAHqCTCQefqYqSF_BP-Dc=.6ecb5e0a-cd13-4936-b0ab-245edc9898e8@github.com>
Message-ID: <74xfqxyUOKEJ8bVb1SoZ9sqiRnPkEQKRo77zbHYMYzw=.8daec28e-bb04-41e8-af0f-0a7ee85da5b5@github.com>

On Thu, 23 Feb 2023 08:31:36 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Executors.newSingleThreadExecutor returns a delegating ExecutorService that has finalizer to shutdown the underlying TPE when the wrapper is finalizable. It goes back to JDK 6 and JDK-6399443. This is the last non-empty finalizer in java.base. Removing it will likely lead to bug reports/complaints as the current behavior goes back to 2006. So the proposal is to just replace it with a Cleaner, trivially done in this case. As part of the changes, I've replaced the existing test with a more modern test that exercises more scenarios.
>
> 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
>  - Improve SM scenario
>  - Keep reference to Cleanable
>  - Merge
>  - Fix typo in comment, remove blank line
>  - Replace older test
>  - Initial commit

Given that the delegated executor can only be an instance of ThreadPoolExecutor then these new changes LGTM.

-------------

Marked as reviewed by dfuchs (Reviewer).

PR: https://git.openjdk.org/jdk/pull/12675

From eirbjo at gmail.com  Thu Feb 23 12:43:15 2023
From: eirbjo at gmail.com (=?UTF-8?B?RWlyaWsgQmrDuHJzbsO4cw==?=)
Date: Thu, 23 Feb 2023 13:43:15 +0100
Subject: RFD: Invalid CRC in ZipFile, ZipFileSystem
Message-ID: <CA+pBWhvuAJ+x3cdLyocs6RC5UTAV7CBiEv2XN4Ltit_XNW6o7w@mail.gmail.com>

Hi,

While writing various ZIP related tests, I noticed a discrepancy in the
treatment of invalid CRC values:

While ZipInputStream rejects invalid CRC values when consuming streams,
ZipFile and ZipFileSystem do not.

While this is inconsistent, it is perhaps not a bug we want to fix?

In any case, it could perhaps be good to have better test coverage in this
area. Here's a test which validates the current behaviour of ZIS, ZF and
ZFS:

https://github.com/openjdk/jdk/compare/master...eirbjo:jdk:zip-invalid-crc

Any thoughts?

Thanks,
Eirik.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20230223/c46e76f0/attachment.htm>

From jlaskey at openjdk.org  Thu Feb 23 13:23:04 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Thu, 23 Feb 2023 13:23:04 GMT
Subject: RFR: JDK-8302323 Add repeat methods to StringBuilder/StringBuffer
Message-ID: <ygMjzllqk27Dss1q2oRgcNvK_GJdbFVweVHTvF7zpwY=.06d27701-6b42-4663-958e-f8aca9bc2bc5@github.com>

Add the ability to repeatedly append char and CharSequence data to StringBuilder/StringBuffer.

-------------

Commit messages:
 - Clean up fro CSR
 - Add synchronized to StringBuffer repeats
 - AbstractStringBuilder repeat

Changes: https://git.openjdk.org/jdk/pull/12728/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12728&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8302323
  Stats: 340 lines in 5 files changed: 336 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/12728.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12728/head:pull/12728

PR: https://git.openjdk.org/jdk/pull/12728

From rgiulietti at openjdk.org  Thu Feb 23 13:42:02 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Thu, 23 Feb 2023 13:42:02 GMT
Subject: RFR: 8302590: Add String.indexOf(int ch, int fromIndex,
 int toIndex)
In-Reply-To: <uQ65oRaVDfpzm9bYRuo_MvSuZIdepicE3GnB3Omyngs=.fc23545b-141a-47e5-8a6a-aa28ae1375e5@github.com>
References: <uQ65oRaVDfpzm9bYRuo_MvSuZIdepicE3GnB3Omyngs=.fc23545b-141a-47e5-8a6a-aa28ae1375e5@github.com>
Message-ID: <-pIGfRN8AhTpM-sJ4XH6y3T_SEFTB4t7eeKvjtRmnew=.7fdbf5ef-5c7c-4935-b5ab-678ecb8aab57@github.com>

On Thu, 16 Feb 2023 17:16:35 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

> Add an `indexOf()` variant allowing to specify both a lower and an upper bound on the search.

May I ask for comments or for a review?

-------------

PR: https://git.openjdk.org/jdk/pull/12600

From jvernee at openjdk.org  Thu Feb 23 14:53:09 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Thu, 23 Feb 2023 14:53:09 GMT
Subject: RFR: 8303040: linux PPC64le: Implementation of Foreign Function &
 Memory API (Preview) [v2]
In-Reply-To: <ObvdkU6yekW6azQzDoM9-SGayZ5Y3ikHr-VM2TqYqFQ=.e19970d7-af19-4273-b2f7-c7dbb476b23f@github.com>
References: <Yuxy6FrsDAN79ya8w8UIkvytGr25zGllDPtPJ1QbGwc=.182664b2-6d8c-497e-a4ae-95e0ad007cf9@github.com>
 <SZ9m3BFFwxhPqEQUx1LujV3bCXCdNdejuOTPJI0x7Wo=.74ffb1ac-5069-4e7d-afe4-d83cc550dbfc@github.com>
 <ObvdkU6yekW6azQzDoM9-SGayZ5Y3ikHr-VM2TqYqFQ=.e19970d7-af19-4273-b2f7-c7dbb476b23f@github.com>
Message-ID: <rYvBjPaDOBxGQphvt8xwIgnTRbJ8T8-Is36Fu3Q7hKQ=.d1f68069-109f-4abd-98a4-643b6dcd2c24@github.com>

On Thu, 23 Feb 2023 04:44:18 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

> > > (I'd be happy to implement the needed changes in shared code if you want, since it touches `BindingSpecializer` which is pretty dense)
> > 
> > 
> > FYI: [master...JornVernee:jdk:I2L](https://github.com/openjdk/jdk/compare/master...JornVernee:jdk:I2L) (assuming `I2L` has the same semantics as `extsw`). Then just add a `.cast(int.class, long.class)` wherever currently an `int` is `vmStore`d in the PPC CallArranger.
> 
> Correct, `extsw` performs a `I2L` conversion. I had thought about this already, but I think my current implementation is more efficient as it combines register moves with the 64 bit extend. Your proposal would generate separate extend and move instructions, right?

The design philosophy has been to put as much as possible on the Java side, and there are a few reasons for that:
1. For maintainability. Generated assembly is ultimately harder to debug, compared to Java code (especially in interpreted mode using `-Djdk.internal.foreign.*Linker.USE_SPEC=false`). (Though, there might also be some personal bias here)
2. Moving things to the Java side makes it visible to the JIT, which means it has the opportunity to be optimized away, or otherwise optimized together with the surrounding Java code. While anything put into the downcall stub is fixed.
3. If we want to intrisify `linkToNative` in C2 later, having downcall stubs be simple and consistent across platforms makes that much easier. Anything that's special in the native code would have to be replicated by the JIT as well.

So... WRT efficiency, I think it depends. I've found in the past that adding a few more move instructions to the downcall stub didn't visibly affect performance. This might be because the CPU is good at just aliasing the registers instead of performing an actual move, or because it's just noise next to the membar we do on the return path. Ultimately, I don't think it matters much for performance, though (you could measure). I think the maintainability/future-proofing from implementing in Java is more important.

-------------

PR: https://git.openjdk.org/jdk/pull/12708

From duke at openjdk.org  Thu Feb 23 14:54:10 2023
From: duke at openjdk.org (Viktor Klang)
Date: Thu, 23 Feb 2023 14:54:10 GMT
Subject: RFR: JDK-8302666: Replace CHM with VarHandle in ForeachOrderedTask
 [v2]
In-Reply-To: <8S7Q0oMLcMo96x4Al5iiUspFDcgqk_tRavYCoDM1cbs=.0a3ccbe9-e199-4dbb-a1c1-252b4e906b86@github.com>
References: <HAgE8xmpZT_2-b5ZDr8TgJNgjhVb3D4ZS3sQqA7c6Mo=.389fa590-681c-44a9-9823-8f70a6129797@github.com>
 <fLSt64PoI3s47g0BLWPMUkim0lmnuZ6wxoBJZppqgqg=.36deb86f-2998-490d-9e29-903e142c72d1@github.com>
 <8S7Q0oMLcMo96x4Al5iiUspFDcgqk_tRavYCoDM1cbs=.0a3ccbe9-e199-4dbb-a1c1-252b4e906b86@github.com>
Message-ID: <1EOHN-Ou9hTqJWepx5Qm0yUJfGGB2EbndMlEPOuqoXs=.1e2bdbed-5951-49c5-b534-ab60329cf1bb@github.com>

On Fri, 17 Feb 2023 16:48:27 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>> Viktor Klang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Write the initial value of the next reference without using the VarHandle
>
> That's a nice find, looks good. (Update the year in the copyright header.)

@PaulSandoz Could you sponsor this one? ?

-------------

PR: https://git.openjdk.org/jdk/pull/12320

From rriggs at openjdk.org  Thu Feb 23 14:54:12 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 23 Feb 2023 14:54:12 GMT
Subject: RFR: 8302899: Executors.newSingleThreadExecutor can use Cleaner to
 shutdown executor [v4]
In-Reply-To: <gCqs5Difq993oMhXzOthVrWAHqCTCQefqYqSF_BP-Dc=.6ecb5e0a-cd13-4936-b0ab-245edc9898e8@github.com>
References: <tBrSZRn1GdrWMSRUsdNNyAWpkuS_FvtLwLuUKut6LH0=.cd1a7fcb-dbcf-45eb-b3d3-72ba17087566@github.com>
 <gCqs5Difq993oMhXzOthVrWAHqCTCQefqYqSF_BP-Dc=.6ecb5e0a-cd13-4936-b0ab-245edc9898e8@github.com>
Message-ID: <x3mKdGAkZd3plWWLN77vMOsmD-H339CjmEdEHbcCvi0=.9d8707e2-ff81-4a2e-93f0-a9d46b3c3956@github.com>

On Thu, 23 Feb 2023 08:31:36 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Executors.newSingleThreadExecutor returns a delegating ExecutorService that has finalizer to shutdown the underlying TPE when the wrapper is finalizable. It goes back to JDK 6 and JDK-6399443. This is the last non-empty finalizer in java.base. Removing it will likely lead to bug reports/complaints as the current behavior goes back to 2006. So the proposal is to just replace it with a Cleaner, trivially done in this case. As part of the changes, I've replaced the existing test with a more modern test that exercises more scenarios.
>
> 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
>  - Improve SM scenario
>  - Keep reference to Cleanable
>  - Merge
>  - Fix typo in comment, remove blank line
>  - Replace older test
>  - Initial commit

Even better.

-------------

Marked as reviewed by rriggs (Reviewer).

PR: https://git.openjdk.org/jdk/pull/12675

From dfuchs at openjdk.org  Thu Feb 23 14:58:10 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 23 Feb 2023 14:58:10 GMT
Subject: RFR: 8302899: Executors.newSingleThreadExecutor can use Cleaner to
 shutdown executor [v4]
In-Reply-To: <gCqs5Difq993oMhXzOthVrWAHqCTCQefqYqSF_BP-Dc=.6ecb5e0a-cd13-4936-b0ab-245edc9898e8@github.com>
References: <tBrSZRn1GdrWMSRUsdNNyAWpkuS_FvtLwLuUKut6LH0=.cd1a7fcb-dbcf-45eb-b3d3-72ba17087566@github.com>
 <gCqs5Difq993oMhXzOthVrWAHqCTCQefqYqSF_BP-Dc=.6ecb5e0a-cd13-4936-b0ab-245edc9898e8@github.com>
Message-ID: <eVc8KDRmsFb6J4FjKxnXZf40-stg0_s5l4CGoS7aFwc=.8dac62b5-b216-4645-8d83-34998e9601b1@github.com>

On Thu, 23 Feb 2023 08:31:36 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Executors.newSingleThreadExecutor returns a delegating ExecutorService that has finalizer to shutdown the underlying TPE when the wrapper is finalizable. It goes back to JDK 6 and JDK-6399443. This is the last non-empty finalizer in java.base. Removing it will likely lead to bug reports/complaints as the current behavior goes back to 2006. So the proposal is to just replace it with a Cleaner, trivially done in this case. As part of the changes, I've replaced the existing test with a more modern test that exercises more scenarios.
>
> 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
>  - Improve SM scenario
>  - Keep reference to Cleanable
>  - Merge
>  - Fix typo in comment, remove blank line
>  - Replace older test
>  - Initial commit

src/java.base/share/classes/java/util/concurrent/Executors.java line 830:

> 828:      * ExecutorService when the wrapper becomes phantom reachable.
> 829:      */
> 830:     private static class AutoShutdownDelegatedExecutorService

nit: if it's not extended anywhere maybe it could be marked final as well.

-------------

PR: https://git.openjdk.org/jdk/pull/12675

From jvernee at openjdk.org  Thu Feb 23 14:59:05 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Thu, 23 Feb 2023 14:59:05 GMT
Subject: RFR: 8303040: linux PPC64le: Implementation of Foreign Function &
 Memory API (Preview)
In-Reply-To: <4KT43N8FvdfdmoAeaXw1vEBMP20MhpV5RUTZzeD2DqQ=.39e184f4-e9a3-47bd-9cad-ed9fe51a0d7b@github.com>
References: <Yuxy6FrsDAN79ya8w8UIkvytGr25zGllDPtPJ1QbGwc=.182664b2-6d8c-497e-a4ae-95e0ad007cf9@github.com>
 <GhLt8kfe9xOv5TKExx7dncFwLcXPw4uiwfntbmhY2Yg=.f8f36141-9a19-44b3-b10f-977d3e02c4af@github.com>
 <4KT43N8FvdfdmoAeaXw1vEBMP20MhpV5RUTZzeD2DqQ=.39e184f4-e9a3-47bd-9cad-ed9fe51a0d7b@github.com>
Message-ID: <f3daPEMpJb6-fyV-QX1ytgXmmmJObGLxLZd1cPwHa_Y=.517887e5-4b9d-4718-82e5-5f4c02da38db@github.com>

On Thu, 23 Feb 2023 04:53:34 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

> > I will do a more thorough review soon.
> 
> Thanks a lot!
> 
> > > The ABI has some tricky corner cases related to HFA (Homogeneous Float Aggregate). The same argument may need to get passed in both, a FP reg and a GP reg or stack slot (see "no partial DW rule"). This cases are not covered by the existing tests.
> > 
> > 
> > FWIW, we have to do this for Windows vararg floats as well ([here](https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/jdk/internal/foreign/abi/x64/windows/CallArranger.java#L231-L239))
> > This can be done by `dup`-ing the value, and using 2 `vmStore`s. (each `vmStore` corresponding to a single register/stack location). Doing something similar might be simpler than the `INTEGER_AND_FLOAT` and `STACK_AND_FLOAT` storage types you're using right now. I'm not sure if that is related to the other limitations you mention? Might be interesting to look into. (perhaps as a separate RFE. I don't have a big issue since the current approach stays in PPC-only code)
> 
> Maybe I need to think a bit more about it. I don't really like the extra cases for `INTEGER_AND_FLOAT` and `STACK_AND_FLOAT`. On the other side, doing it in the CallArranger would break the design of factoring out the allocation from the binding generation. In addition, it seems like PPC64 is even more tricky than the Windows case. I need to pass 2 float arguments in a GP reg (or stack slot) plus one of these 2 floats in float register F13. I think this can get implemented more easily in the backend. Do you agree?

I think the same arguments apply here. I'll have a more thorough look at the patch and then get back to you on this.

-------------

PR: https://git.openjdk.org/jdk/pull/12708

From jvernee at openjdk.org  Thu Feb 23 15:02:06 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Thu, 23 Feb 2023 15:02:06 GMT
Subject: RFR: 8303040: linux PPC64le: Implementation of Foreign Function &
 Memory API (Preview) [v3]
In-Reply-To: <POQ0TzX45YoduJT-Dz1XcJyTxOYDlxRJZ8hJkqnGYZE=.f1f5b7cb-2fe4-4142-9ad4-85cdd10b3f1a@github.com>
References: <Yuxy6FrsDAN79ya8w8UIkvytGr25zGllDPtPJ1QbGwc=.182664b2-6d8c-497e-a4ae-95e0ad007cf9@github.com>
 <8b3vVrV22RuhdRoRYacXV0ZeghFGgKkC8S_z-iMrzAQ=.dd84b743-8b51-4281-8f5f-f9eff6207bc7@github.com>
 <POQ0TzX45YoduJT-Dz1XcJyTxOYDlxRJZ8hJkqnGYZE=.f1f5b7cb-2fe4-4142-9ad4-85cdd10b3f1a@github.com>
Message-ID: <BAy9luhm8PM4HPzw3ZM37I4w0TDFJ56DM5n7UbuOCLA=.9744389d-5f90-4c9c-ad37-787bfdcae5a8@github.com>

On Thu, 23 Feb 2023 06:21:05 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

> I have removed the size restriction for structs. Passing a struct consisting of 1 char works (on Little Endian). However, passing a struct consisting of 3 chars doesn't (getting IndexOutOfBoundsException: Out of bound access on segment MemorySegment). Neither on PPC64, nor on x86. Is that known or should I file a bug for that?

I think you might be running into: https://bugs.openjdk.org/browse/JDK-8303017 which was recently found. (If you have a simpler test case please add it to the JBS issue, in a comment)

-------------

PR: https://git.openjdk.org/jdk/pull/12708

From jvernee at openjdk.org  Thu Feb 23 15:07:05 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Thu, 23 Feb 2023 15:07:05 GMT
Subject: RFR: 8303040: linux PPC64le: Implementation of Foreign Function &
 Memory API (Preview) [v2]
In-Reply-To: <3dzZfm_BSXLL_iWAmllX-8YXAe1NWMMPr11zJtedIWU=.8a1dd1df-4eb7-4c72-9a06-f4636e5ec3e4@github.com>
References: <Yuxy6FrsDAN79ya8w8UIkvytGr25zGllDPtPJ1QbGwc=.182664b2-6d8c-497e-a4ae-95e0ad007cf9@github.com>
 <SZ9m3BFFwxhPqEQUx1LujV3bCXCdNdejuOTPJI0x7Wo=.74ffb1ac-5069-4e7d-afe4-d83cc550dbfc@github.com>
 <ObvdkU6yekW6azQzDoM9-SGayZ5Y3ikHr-VM2TqYqFQ=.e19970d7-af19-4273-b2f7-c7dbb476b23f@github.com>
 <3dzZfm_BSXLL_iWAmllX-8YXAe1NWMMPr11zJtedIWU=.8a1dd1df-4eb7-4c72-9a06-f4636e5ec3e4@github.com>
Message-ID: <fuCE3G5PEBbCwNPdIpSDdIPLp-SIzFqFfmEpMVQ3d6o=.2f60727b-0a90-4daa-9614-1439bffcc335@github.com>

On Thu, 23 Feb 2023 10:20:31 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> > Correct, `extsw` performs a `I2L` conversion. I had thought about this already, but I think my current implementation is more efficient as it combines register moves with the 64 bit extend. Your proposal would generate separate extend and move instructions, right?
> 
> Would it be possible to generate a biding cast + move and the recognize the pattern in the HS backend and optimize it away as a `extsw` ?

At the moment, there is a forced indirection between the Java code and downcall stub, so the JIT can not do any optimizations that have to take both sides into account. The downcall stub is opaque to the JIT. (though, perhaps in the long run we can add intrinsification of `linkToNative` that can generate the code in the downcall stub as part of the JIT's own IR, which would solve this)

-------------

PR: https://git.openjdk.org/jdk/pull/12708

From rgiulietti at openjdk.org  Thu Feb 23 15:29:09 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Thu, 23 Feb 2023 15:29:09 GMT
Subject: RFR: JDK-8302323 Add repeat methods to StringBuilder/StringBuffer
In-Reply-To: <ygMjzllqk27Dss1q2oRgcNvK_GJdbFVweVHTvF7zpwY=.06d27701-6b42-4663-958e-f8aca9bc2bc5@github.com>
References: <ygMjzllqk27Dss1q2oRgcNvK_GJdbFVweVHTvF7zpwY=.06d27701-6b42-4663-958e-f8aca9bc2bc5@github.com>
Message-ID: <Sq7sbx09dWCuLO1VxKSjClSONgSLW0RuIiwB-UfOOas=.7aaaf870-f4e5-4b07-ba5f-9c15a6360a7c@github.com>

On Thu, 23 Feb 2023 13:13:43 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

> Add the ability to repeatedly append char and CharSequence data to StringBuilder/StringBuffer.

src/java.base/share/classes/java/lang/AbstractStringBuilder.java line 1851:

> 1849:             while (count-- != 0) {
> 1850:                 value[index++] = (byte) c;
> 1851:             }

One could reduce to just one running var rather than two:

int index = this.count;
int limit = index + count;
for (; index != limit; ++index) {
    value[index] = (byte) c;
}

-------------

PR: https://git.openjdk.org/jdk/pull/12728

From jlaskey at openjdk.org  Thu Feb 23 15:35:07 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Thu, 23 Feb 2023 15:35:07 GMT
Subject: RFR: JDK-8302323 Add repeat methods to StringBuilder/StringBuffer
In-Reply-To: <Sq7sbx09dWCuLO1VxKSjClSONgSLW0RuIiwB-UfOOas=.7aaaf870-f4e5-4b07-ba5f-9c15a6360a7c@github.com>
References: <ygMjzllqk27Dss1q2oRgcNvK_GJdbFVweVHTvF7zpwY=.06d27701-6b42-4663-958e-f8aca9bc2bc5@github.com>
 <Sq7sbx09dWCuLO1VxKSjClSONgSLW0RuIiwB-UfOOas=.7aaaf870-f4e5-4b07-ba5f-9c15a6360a7c@github.com>
Message-ID: <4qFY69yWMz7rG2rdafjLuR7N_B_SNqw0ucvIWRV63bE=.127ed93f-6814-4dc8-8546-7ff2f3c4ca99@github.com>

On Thu, 23 Feb 2023 15:17:26 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> Add the ability to repeatedly append char and CharSequence data to StringBuilder/StringBuffer.
>
> src/java.base/share/classes/java/lang/AbstractStringBuilder.java line 1851:
> 
>> 1849:             while (count-- != 0) {
>> 1850:                 value[index++] = (byte) c;
>> 1851:             }
> 
> One could reduce to just one running var rather than two:
> 
> int index = this.count;
> int limit = index + count;
> for (; index != limit; ++index) {
>     value[index] = (byte) c;
> }

True.  Will test to see if there is any performance benefit.

-------------

PR: https://git.openjdk.org/jdk/pull/12728

From stsypanov at openjdk.org  Thu Feb 23 15:37:05 2023
From: stsypanov at openjdk.org (Sergey Tsypanov)
Date: Thu, 23 Feb 2023 15:37:05 GMT
Subject: RFR: 8282319: java.util.Locale method to stream available Locales
In-Reply-To: <QxcV7IwdW13WfT0X0PKyWBWpo_rP588AgHIYiUu3E_Q=.82b88828-e8ec-4f3c-a75a-ec88b589d4e2@github.com>
References: <QxcV7IwdW13WfT0X0PKyWBWpo_rP588AgHIYiUu3E_Q=.82b88828-e8ec-4f3c-a75a-ec88b589d4e2@github.com>
Message-ID: <qWSTzMpfYXXnZpaze3oVaIlK3GBrC40TmNag1vjrjAA=.7306c104-160a-4d1a-b8fc-756f039c7426@github.com>

On Fri, 27 Jan 2023 21:48:26 GMT, Justin Lu <jlu at openjdk.org> wrote:

> This PR adds a new method to java.util.Locale which returns Stream<Locale>
> 
> The contents of the Stream are composed of the same underlying elements as Locale.getAvailableLocales().
> 
> This method allows streaming of the Locale array without creating a defensive copy.

Marked as reviewed by stsypanov (Author).

-------------

PR: https://git.openjdk.org/jdk/pull/12269

From duke at openjdk.org  Thu Feb 23 15:38:26 2023
From: duke at openjdk.org (Viktor Klang)
Date: Thu, 23 Feb 2023 15:38:26 GMT
Subject: RFR: JDK-8297605 DelayQueue javadoc is confusing
In-Reply-To: <RileEs0r_cfhESPODINk_sRE-Fq--_jJGEFqucn2YzU=.4efb95d9-333d-477d-a711-e1024200c260@github.com>
References: <RileEs0r_cfhESPODINk_sRE-Fq--_jJGEFqucn2YzU=.4efb95d9-333d-477d-a711-e1024200c260@github.com>
Message-ID: <PTa2-nQq-RVgRio7ZecTomQ2xhE7trjVwma0UpHuIp8=.d341cca9-453d-43f7-bf78-e00f4c17ee88@github.com>

On Thu, 23 Feb 2023 09:05:49 GMT, Viktor Klang <duke at openjdk.org> wrote:

> Clarifies the distinction between expiration of the head of DelayQueue and how it relates to `poll`, `take`, and `peek`. See discussion on https://bugs.openjdk.org/browse/JDK-8297605
> 
> @DougLea If possible, please weigh in on whether this is in line with your thoughts on the matter.

Reopening this as a new PR due to a weird validation error.

-------------

PR: https://git.openjdk.org/jdk/pull/12727

From duke at openjdk.org  Thu Feb 23 15:38:28 2023
From: duke at openjdk.org (Viktor Klang)
Date: Thu, 23 Feb 2023 15:38:28 GMT
Subject: Withdrawn: JDK-8297605 DelayQueue javadoc is confusing
In-Reply-To: <RileEs0r_cfhESPODINk_sRE-Fq--_jJGEFqucn2YzU=.4efb95d9-333d-477d-a711-e1024200c260@github.com>
References: <RileEs0r_cfhESPODINk_sRE-Fq--_jJGEFqucn2YzU=.4efb95d9-333d-477d-a711-e1024200c260@github.com>
Message-ID: <9gqNaDwceqyol7OUJpZeygt6TDxw5C6P1vlBQLGHKlM=.744db8de-c94f-450d-a77b-5482b40bbb83@github.com>

On Thu, 23 Feb 2023 09:05:49 GMT, Viktor Klang <duke at openjdk.org> wrote:

> Clarifies the distinction between expiration of the head of DelayQueue and how it relates to `poll`, `take`, and `peek`. See discussion on https://bugs.openjdk.org/browse/JDK-8297605
> 
> @DougLea If possible, please weigh in on whether this is in line with your thoughts on the matter.

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/12727

From rgiulietti at openjdk.org  Thu Feb 23 15:43:21 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Thu, 23 Feb 2023 15:43:21 GMT
Subject: RFR: JDK-8302323 Add repeat methods to StringBuilder/StringBuffer
In-Reply-To: <4qFY69yWMz7rG2rdafjLuR7N_B_SNqw0ucvIWRV63bE=.127ed93f-6814-4dc8-8546-7ff2f3c4ca99@github.com>
References: <ygMjzllqk27Dss1q2oRgcNvK_GJdbFVweVHTvF7zpwY=.06d27701-6b42-4663-958e-f8aca9bc2bc5@github.com>
 <Sq7sbx09dWCuLO1VxKSjClSONgSLW0RuIiwB-UfOOas=.7aaaf870-f4e5-4b07-ba5f-9c15a6360a7c@github.com>
 <4qFY69yWMz7rG2rdafjLuR7N_B_SNqw0ucvIWRV63bE=.127ed93f-6814-4dc8-8546-7ff2f3c4ca99@github.com>
Message-ID: <lkDc1gySA_Cn9pFR35jqtkScN_hpWDVH0QZMj7nlcaU=.6c1c4860-d440-459e-b52f-bbac29f97758@github.com>

On Thu, 23 Feb 2023 15:32:36 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/AbstractStringBuilder.java line 1851:
>> 
>>> 1849:             while (count-- != 0) {
>>> 1850:                 value[index++] = (byte) c;
>>> 1851:             }
>> 
>> One could reduce to just one running var rather than two:
>> 
>> int index = this.count;
>> int limit = index + count;
>> for (; index != limit; ++index) {
>>     value[index] = (byte) c;
>> }
>
> True.  Will test to see if there is any performance benefit.

Apart from perf, the less "moving parts" there are, the better I personally understand code ;-)

-------------

PR: https://git.openjdk.org/jdk/pull/12728

From duke at openjdk.org  Thu Feb 23 15:45:08 2023
From: duke at openjdk.org (Viktor Klang)
Date: Thu, 23 Feb 2023 15:45:08 GMT
Subject: RFR: JDK-8297605 DelayQueue javadoc is confusing
Message-ID: <jdJ46gB5VbY2LPrH7oGbtCtU65HGtd7GZ7SB8InbG-A=.8679db0c-28b2-4665-ab92-e89af0ad38e6@github.com>

Clarifies the distinction between expiration of the head of DelayQueue and how it relates to `poll`, `take`, and `peek`. See discussion on https://bugs.openjdk.org/browse/JDK-8297605

@DougLea If possible, please weigh in on whether this is in line with your thoughts on the matter.

-------------

Commit messages:
 - JDK-8297605 DelayQueue javadoc is confusing

Changes: https://git.openjdk.org/jdk/pull/12729/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12729&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8297605
  Stats: 14 lines in 1 file changed: 1 ins; 1 del; 12 mod
  Patch: https://git.openjdk.org/jdk/pull/12729.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12729/head:pull/12729

PR: https://git.openjdk.org/jdk/pull/12729

From duke at openjdk.org  Thu Feb 23 15:45:09 2023
From: duke at openjdk.org (Viktor Klang)
Date: Thu, 23 Feb 2023 15:45:09 GMT
Subject: RFR: JDK-8297605 DelayQueue javadoc is confusing
In-Reply-To: <jdJ46gB5VbY2LPrH7oGbtCtU65HGtd7GZ7SB8InbG-A=.8679db0c-28b2-4665-ab92-e89af0ad38e6@github.com>
References: <jdJ46gB5VbY2LPrH7oGbtCtU65HGtd7GZ7SB8InbG-A=.8679db0c-28b2-4665-ab92-e89af0ad38e6@github.com>
Message-ID: <FLWUELekXUjeGGRgCuoMc9C7iP23No3z1YnUxmCe0Ok=.368cc2e2-8989-4839-8076-b6b25b00ff0f@github.com>

On Thu, 23 Feb 2023 15:36:48 GMT, Viktor Klang <duke at openjdk.org> wrote:

> Clarifies the distinction between expiration of the head of DelayQueue and how it relates to `poll`, `take`, and `peek`. See discussion on https://bugs.openjdk.org/browse/JDK-8297605
> 
> @DougLea If possible, please weigh in on whether this is in line with your thoughts on the matter.

Updated version of #12727

-------------

PR: https://git.openjdk.org/jdk/pull/12729

From dl at openjdk.org  Thu Feb 23 15:55:11 2023
From: dl at openjdk.org (Doug Lea)
Date: Thu, 23 Feb 2023 15:55:11 GMT
Subject: RFR: JDK-8297605 DelayQueue javadoc is confusing
In-Reply-To: <jdJ46gB5VbY2LPrH7oGbtCtU65HGtd7GZ7SB8InbG-A=.8679db0c-28b2-4665-ab92-e89af0ad38e6@github.com>
References: <jdJ46gB5VbY2LPrH7oGbtCtU65HGtd7GZ7SB8InbG-A=.8679db0c-28b2-4665-ab92-e89af0ad38e6@github.com>
Message-ID: <UEKqlfe-KisuHlvfGXi8QbYFgBRk8TnTLjdKRASwG60=.dac7a48c-7449-456a-ac93-2c321fb82ae1@github.com>

On Thu, 23 Feb 2023 15:36:48 GMT, Viktor Klang <duke at openjdk.org> wrote:

> Clarifies the distinction between expiration of the head of DelayQueue and how it relates to `poll`, `take`, and `peek`. See discussion on https://bugs.openjdk.org/browse/JDK-8297605
> 
> @DougLea If possible, please weigh in on whether this is in line with your thoughts on the matter.

Thanks. Adding the word "expired" (plus other adjustments) seems to be the simplest way to avoid confusion.

-------------

PR: https://git.openjdk.org/jdk/pull/12729

From martin at openjdk.org  Thu Feb 23 16:02:25 2023
From: martin at openjdk.org (Martin Buchholz)
Date: Thu, 23 Feb 2023 16:02:25 GMT
Subject: RFR: 8302899: Executors.newSingleThreadExecutor can use Cleaner to
 shutdown executor [v4]
In-Reply-To: <gCqs5Difq993oMhXzOthVrWAHqCTCQefqYqSF_BP-Dc=.6ecb5e0a-cd13-4936-b0ab-245edc9898e8@github.com>
References: <tBrSZRn1GdrWMSRUsdNNyAWpkuS_FvtLwLuUKut6LH0=.cd1a7fcb-dbcf-45eb-b3d3-72ba17087566@github.com>
 <gCqs5Difq993oMhXzOthVrWAHqCTCQefqYqSF_BP-Dc=.6ecb5e0a-cd13-4936-b0ab-245edc9898e8@github.com>
Message-ID: <tG6GP5dWkIktwuoCCQKrwet0dfeF4TfX9VBuLqemQwk=.e6a621ab-af7f-4db4-aab3-99eece42af04@github.com>

On Thu, 23 Feb 2023 08:31:36 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Executors.newSingleThreadExecutor returns a delegating ExecutorService that has finalizer to shutdown the underlying TPE when the wrapper is finalizable. It goes back to JDK 6 and JDK-6399443. This is the last non-empty finalizer in java.base. Removing it will likely lead to bug reports/complaints as the current behavior goes back to 2006. So the proposal is to just replace it with a Cleaner, trivially done in this case. As part of the changes, I've replaced the existing test with a more modern test that exercises more scenarios.
>
> 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
>  - Improve SM scenario
>  - Keep reference to Cleanable
>  - Merge
>  - Fix typo in comment, remove blank line
>  - Replace older test
>  - Initial commit

Two typos to fix:
ExectorService
and and

-------------

Changes requested by martin (Reviewer).

PR: https://git.openjdk.org/jdk/pull/12675

From rriggs at openjdk.org  Thu Feb 23 16:07:47 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 23 Feb 2023 16:07:47 GMT
Subject: RFR: JDK-8302323 Add repeat methods to StringBuilder/StringBuffer
In-Reply-To: <ygMjzllqk27Dss1q2oRgcNvK_GJdbFVweVHTvF7zpwY=.06d27701-6b42-4663-958e-f8aca9bc2bc5@github.com>
References: <ygMjzllqk27Dss1q2oRgcNvK_GJdbFVweVHTvF7zpwY=.06d27701-6b42-4663-958e-f8aca9bc2bc5@github.com>
Message-ID: <HzzC3xoR7t1nNDEK7a6-PdjohKGF3if-nrXXPUc37gQ=.e5e3c948-8dd3-4bf4-affe-b8d983f6a4d6@github.com>

On Thu, 23 Feb 2023 13:13:43 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

> Add the ability to repeatedly append char and CharSequence data to StringBuilder/StringBuffer.

src/java.base/share/classes/java/lang/AbstractStringBuilder.java line 1839:

> 1837:      * @throws StringIndexOutOfBoundsException  if the result overflows the buffer
> 1838:      */
> 1839:     public AbstractStringBuilder repeat(char c, int count) {

The shadowing of the count field is a hidden maintenance trap.

src/java.base/share/classes/java/lang/AbstractStringBuilder.java line 1867:

> 1865: 
> 1866:     private AbstractStringBuilder repeatNull(int count) {
> 1867:         if (count < 0) {

This could be implemented as `repeat("null", count)`. Its not likely to be performance sensitive and be easier to maintain.

src/java.base/share/classes/java/lang/AbstractStringBuilder.java line 1869:

> 1867:         if (count < 0) {
> 1868:             throw new IllegalArgumentException("count is less than zero: " + count);
> 1869:         } else if (count == 0) {

Inconsistent `if ... else if ...` structure compared to method above.

src/java.base/share/classes/java/lang/AbstractStringBuilder.java line 1876:

> 1874:         int length = this.count - offset;
> 1875:         int valueLength = length << coder;
> 1876:         if ((Integer.MAX_VALUE - offset) / count < valueLength) {

Can this check be done with multiply instead of divide?

src/java.base/share/classes/java/lang/AbstractStringBuilder.java line 1879:

> 1877:             throw new OutOfMemoryError("Required length exceeds implementation limit");
> 1878:         }
> 1879:         int limit = count * length;

The meaning of limit should be consistent across uses.  Above it is an index into the buffer; here it is an offset.

src/java.base/share/classes/java/lang/AbstractStringBuilder.java line 1904:

> 1902:     public AbstractStringBuilder repeat(CharSequence cs, int count) {
> 1903:         if (cs == null) {
> 1904:             return repeatNull(count);

Or just replace `cs = "null";` and fall through to the rest.

-------------

PR: https://git.openjdk.org/jdk/pull/12728

From rriggs at openjdk.org  Thu Feb 23 16:25:00 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 23 Feb 2023 16:25:00 GMT
Subject: RFR: 8302590: Add String.indexOf(int ch, int fromIndex,
 int toIndex)
In-Reply-To: <uQ65oRaVDfpzm9bYRuo_MvSuZIdepicE3GnB3Omyngs=.fc23545b-141a-47e5-8a6a-aa28ae1375e5@github.com>
References: <uQ65oRaVDfpzm9bYRuo_MvSuZIdepicE3GnB3Omyngs=.fc23545b-141a-47e5-8a6a-aa28ae1375e5@github.com>
Message-ID: <OY1C6dkxFHJZkbBfHn7lKNN-0HjRhfGq02v6y6UGGhY=.d1468f14-9ab5-4723-9ed4-1bf21163acb9@github.com>

On Thu, 16 Feb 2023 17:16:35 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

> Add an `indexOf()` variant allowing to specify both a lower and an upper bound on the search.

Is there any performance impact? Are there relevant JHM tests? Or should be added.
Also to verify that the intrinsics are still valid though the parameter names have changed.

-------------

PR: https://git.openjdk.org/jdk/pull/12600

From jlaskey at openjdk.org  Thu Feb 23 16:25:05 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Thu, 23 Feb 2023 16:25:05 GMT
Subject: RFR: JDK-8302323 Add repeat methods to StringBuilder/StringBuffer
In-Reply-To: <HzzC3xoR7t1nNDEK7a6-PdjohKGF3if-nrXXPUc37gQ=.e5e3c948-8dd3-4bf4-affe-b8d983f6a4d6@github.com>
References: <ygMjzllqk27Dss1q2oRgcNvK_GJdbFVweVHTvF7zpwY=.06d27701-6b42-4663-958e-f8aca9bc2bc5@github.com>
 <HzzC3xoR7t1nNDEK7a6-PdjohKGF3if-nrXXPUc37gQ=.e5e3c948-8dd3-4bf4-affe-b8d983f6a4d6@github.com>
Message-ID: <_bYC7tIqltee0f4m-9nNRbFGj2Zm0i-KkMrGcTHGJBo=.79a3cdb6-ce8b-43d3-9206-bb6f63fde27a@github.com>

On Thu, 23 Feb 2023 15:52:15 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Add the ability to repeatedly append char and CharSequence data to StringBuilder/StringBuffer.
>
> src/java.base/share/classes/java/lang/AbstractStringBuilder.java line 1839:
> 
>> 1837:      * @throws StringIndexOutOfBoundsException  if the result overflows the buffer
>> 1838:      */
>> 1839:     public AbstractStringBuilder repeat(char c, int count) {
> 
> The shadowing of the count field is a hidden maintenance trap.

I know but Stuart requested it.

> src/java.base/share/classes/java/lang/AbstractStringBuilder.java line 1867:
> 
>> 1865: 
>> 1866:     private AbstractStringBuilder repeatNull(int count) {
>> 1867:         if (count < 0) {
> 
> This could be implemented as `repeat("null", count)`. Its not likely to be performance sensitive and be easier to maintain.

Just being consistent with existing code.

> src/java.base/share/classes/java/lang/AbstractStringBuilder.java line 1869:
> 
>> 1867:         if (count < 0) {
>> 1868:             throw new IllegalArgumentException("count is less than zero: " + count);
>> 1869:         } else if (count == 0) {
> 
> Inconsistent `if ... else if ...` structure compared to method above.

Noted. Will fix.

> src/java.base/share/classes/java/lang/AbstractStringBuilder.java line 1879:
> 
>> 1877:             throw new OutOfMemoryError("Required length exceeds implementation limit");
>> 1878:         }
>> 1879:         int limit = count * length;
> 
> The meaning of limit should be consistent across uses.  Above it is an index into the buffer; here it is an offset.

Not seeing it.

> src/java.base/share/classes/java/lang/AbstractStringBuilder.java line 1904:
> 
>> 1902:     public AbstractStringBuilder repeat(CharSequence cs, int count) {
>> 1903:         if (cs == null) {
>> 1904:             return repeatNull(count);
> 
> Or just replace `cs = "null";` and fall through to the rest.

Same.

-------------

PR: https://git.openjdk.org/jdk/pull/12728

From rriggs at openjdk.org  Thu Feb 23 16:31:24 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 23 Feb 2023 16:31:24 GMT
Subject: RFR: JDK-8302323 Add repeat methods to StringBuilder/StringBuffer
In-Reply-To: <_bYC7tIqltee0f4m-9nNRbFGj2Zm0i-KkMrGcTHGJBo=.79a3cdb6-ce8b-43d3-9206-bb6f63fde27a@github.com>
References: <ygMjzllqk27Dss1q2oRgcNvK_GJdbFVweVHTvF7zpwY=.06d27701-6b42-4663-958e-f8aca9bc2bc5@github.com>
 <HzzC3xoR7t1nNDEK7a6-PdjohKGF3if-nrXXPUc37gQ=.e5e3c948-8dd3-4bf4-affe-b8d983f6a4d6@github.com>
 <_bYC7tIqltee0f4m-9nNRbFGj2Zm0i-KkMrGcTHGJBo=.79a3cdb6-ce8b-43d3-9206-bb6f63fde27a@github.com>
Message-ID: <mGUcSZyFfKexO80Zi7TTMMAQvErZPKt4DFMgl0Lb4-U=.73ab6c90-4bb8-4e1f-896d-18029949d8e1@github.com>

On Thu, 23 Feb 2023 16:20:59 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/AbstractStringBuilder.java line 1867:
>> 
>>> 1865: 
>>> 1866:     private AbstractStringBuilder repeatNull(int count) {
>>> 1867:         if (count < 0) {
>> 
>> This could be implemented as `repeat("null", count)`. Its not likely to be performance sensitive and be easier to maintain.
>
> Just being consistent with existing code.

Better to add less code to maintain later.

>> src/java.base/share/classes/java/lang/AbstractStringBuilder.java line 1879:
>> 
>>> 1877:             throw new OutOfMemoryError("Required length exceeds implementation limit");
>>> 1878:         }
>>> 1879:         int limit = count * length;
>> 
>> The meaning of limit should be consistent across uses.  Above it is an index into the buffer; here it is an offset.
>
> Not seeing it.

Sorry, it was a comment assuming the simpler code in lines 1849-1851 from Raffaello.

>> src/java.base/share/classes/java/lang/AbstractStringBuilder.java line 1904:
>> 
>>> 1902:     public AbstractStringBuilder repeat(CharSequence cs, int count) {
>>> 1903:         if (cs == null) {
>>> 1904:             return repeatNull(count);
>> 
>> Or just replace `cs = "null";` and fall through to the rest.
>
> Same.

Same, don't add more code than necessary.

-------------

PR: https://git.openjdk.org/jdk/pull/12728

From lance.andersen at oracle.com  Thu Feb 23 16:32:52 2023
From: lance.andersen at oracle.com (Lance Andersen)
Date: Thu, 23 Feb 2023 16:32:52 +0000
Subject: RFD: Invalid CRC in ZipFile, ZipFileSystem
In-Reply-To: <CA+pBWhvuAJ+x3cdLyocs6RC5UTAV7CBiEv2XN4Ltit_XNW6o7w@mail.gmail.com>
References: <CA+pBWhvuAJ+x3cdLyocs6RC5UTAV7CBiEv2XN4Ltit_XNW6o7w@mail.gmail.com>
Message-ID: <9B315E4F-C51D-47F3-B7CC-EE750FEC1275@oracle.com>

HI Eirik

On Feb 23, 2023, at 7:43 AM, Eirik Bj?rsn?s <eirbjo at gmail.com<mailto:eirbjo at gmail.com>> wrote:

Hi,

While writing various ZIP related tests, I noticed a discrepancy in the treatment of invalid CRC values:

While ZipInputStream rejects invalid CRC values when consuming streams, ZipFile and ZipFileSystem do not.

While this is inconsistent, it is perhaps not a bug we want to fix?

I believe it is intentional.  Alan, Martin B, do you recall the history?

In any case, it could perhaps be good to have better test coverage in this area. Here's a test which validates the current behaviour of ZIS, ZF and ZFS:

https://github.com/openjdk/jdk/compare/master...eirbjo:jdk:zip-invalid-crc

I will take a look next week

Thank you for your efforts in this area

Best
Lance

Any thoughts?

Thanks,
Eirik.



[cid:E1C4E2F0-ECD0-4C9D-ADB4-B16CA7BCB7FC at home]






Lance Andersen | Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering
1 Network Drive
Burlington, MA 01803
Lance.Andersen at oracle.com<mailto:Lance.Andersen at oracle.com>



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20230223/7c41d914/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: oracle_sig_logo.gif
Type: image/gif
Size: 658 bytes
Desc: oracle_sig_logo.gif
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20230223/7c41d914/oracle_sig_logo.gif>

From jlaskey at openjdk.org  Thu Feb 23 16:37:02 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Thu, 23 Feb 2023 16:37:02 GMT
Subject: RFR: JDK-8302323 Add repeat methods to StringBuilder/StringBuffer
In-Reply-To: <HzzC3xoR7t1nNDEK7a6-PdjohKGF3if-nrXXPUc37gQ=.e5e3c948-8dd3-4bf4-affe-b8d983f6a4d6@github.com>
References: <ygMjzllqk27Dss1q2oRgcNvK_GJdbFVweVHTvF7zpwY=.06d27701-6b42-4663-958e-f8aca9bc2bc5@github.com>
 <HzzC3xoR7t1nNDEK7a6-PdjohKGF3if-nrXXPUc37gQ=.e5e3c948-8dd3-4bf4-affe-b8d983f6a4d6@github.com>
Message-ID: <bJaWF5o0T3SgYh4ebXq41liJ4ytcLM_Xfr7J9F2uBk4=.84820ff2-c69d-4db4-adaa-cb42dcaf2b67@github.com>

On Thu, 23 Feb 2023 15:56:37 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Add the ability to repeatedly append char and CharSequence data to StringBuilder/StringBuffer.
>
> src/java.base/share/classes/java/lang/AbstractStringBuilder.java line 1876:
> 
>> 1874:         int length = this.count - offset;
>> 1875:         int valueLength = length << coder;
>> 1876:         if ((Integer.MAX_VALUE - offset) / count < valueLength) {
> 
> Can this check be done with multiply instead of divide?

This was a recommended pattern when I was working on String. It handles arithmetic overflow. Divide magic there would be confusing.

-------------

PR: https://git.openjdk.org/jdk/pull/12728

From rriggs at openjdk.org  Thu Feb 23 16:37:04 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 23 Feb 2023 16:37:04 GMT
Subject: RFR: JDK-8302323 Add repeat methods to StringBuilder/StringBuffer
In-Reply-To: <ygMjzllqk27Dss1q2oRgcNvK_GJdbFVweVHTvF7zpwY=.06d27701-6b42-4663-958e-f8aca9bc2bc5@github.com>
References: <ygMjzllqk27Dss1q2oRgcNvK_GJdbFVweVHTvF7zpwY=.06d27701-6b42-4663-958e-f8aca9bc2bc5@github.com>
Message-ID: <rW8jOcX3MGF-zvUBZE-hGlLV4B5UXc8wbyZlJaIAgNk=.9a90d4e2-61dc-46ae-92c0-8f22c5b8c450@github.com>

On Thu, 23 Feb 2023 13:13:43 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

> Add the ability to repeatedly append char and CharSequence data to StringBuilder/StringBuffer.

src/java.base/share/classes/java/lang/String.java line 4461:

> 4459: 
> 4460:     /**
> 4461:      * Used to perform copying after the initial insertion. Copying is optimized

It may be worth reinforceing that bytes are being copied, not characters and is used in both IsLatin1 and UTF16 cases with appropriate arguments.

-------------

PR: https://git.openjdk.org/jdk/pull/12728

From martin at openjdk.org  Thu Feb 23 16:39:50 2023
From: martin at openjdk.org (Martin Buchholz)
Date: Thu, 23 Feb 2023 16:39:50 GMT
Subject: RFR: 8302899: Executors.newSingleThreadExecutor can use Cleaner to
 shutdown executor [v4]
In-Reply-To: <gCqs5Difq993oMhXzOthVrWAHqCTCQefqYqSF_BP-Dc=.6ecb5e0a-cd13-4936-b0ab-245edc9898e8@github.com>
References: <tBrSZRn1GdrWMSRUsdNNyAWpkuS_FvtLwLuUKut6LH0=.cd1a7fcb-dbcf-45eb-b3d3-72ba17087566@github.com>
 <gCqs5Difq993oMhXzOthVrWAHqCTCQefqYqSF_BP-Dc=.6ecb5e0a-cd13-4936-b0ab-245edc9898e8@github.com>
Message-ID: <3uOU_Y7rRGGZ4WIicugLBKrDMnFiFJygIwUSgRwC5HM=.8c3ddb7f-1b4d-4a78-8b8e-cb0832b9e350@github.com>

On Thu, 23 Feb 2023 08:31:36 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Executors.newSingleThreadExecutor returns a delegating ExecutorService that has finalizer to shutdown the underlying TPE when the wrapper is finalizable. It goes back to JDK 6 and JDK-6399443. This is the last non-empty finalizer in java.base. Removing it will likely lead to bug reports/complaints as the current behavior goes back to 2006. So the proposal is to just replace it with a Cleaner, trivially done in this case. As part of the changes, I've replaced the existing test with a more modern test that exercises more scenarios.
>
> 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
>  - Improve SM scenario
>  - Keep reference to Cleanable
>  - Merge
>  - Fix typo in comment, remove blank line
>  - Replace older test
>  - Initial commit

src/java.base/share/classes/java/util/concurrent/Executors.java line 832:

> 830:     private static class AutoShutdownDelegatedExecutorService
> 831:             extends DelegatedExecutorService {
> 832:         private final Cleanable cleaner;

"cleaner" is a Cleanable, not a Cleaner. We should consistently use (as we do elsewhere in openjdk)


 private final Cleanable cleanable;


and fix the others to be consistent:


./sun/nio/ch/DatagramChannelImpl.java:115:    private final Cleanable cleaner;
./sun/nio/ch/NioSocketImpl.java:106:    private Cleanable cleaner;
./java/util/concurrent/Executors.java:832:        private final Cleanable cleaner;


(BTW: I find Cleaners much harder to use than old finalize, and it looks like I'm not the only one!)

-------------

PR: https://git.openjdk.org/jdk/pull/12675

From rriggs at openjdk.org  Thu Feb 23 16:42:54 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 23 Feb 2023 16:42:54 GMT
Subject: RFR: JDK-8302323 Add repeat methods to StringBuilder/StringBuffer
In-Reply-To: <ygMjzllqk27Dss1q2oRgcNvK_GJdbFVweVHTvF7zpwY=.06d27701-6b42-4663-958e-f8aca9bc2bc5@github.com>
References: <ygMjzllqk27Dss1q2oRgcNvK_GJdbFVweVHTvF7zpwY=.06d27701-6b42-4663-958e-f8aca9bc2bc5@github.com>
Message-ID: <kd73pqt7CR5_hxkpR5ekp2s7j7K-203INQwJrNVYW-Q=.798df78a-aa6d-4616-a3a3-66b78dfa0cc4@github.com>

On Thu, 23 Feb 2023 13:13:43 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

> Add the ability to repeatedly append char and CharSequence data to StringBuilder/StringBuffer.

src/java.base/share/classes/java/lang/AbstractStringBuilder.java line 1918:

> 1916:         }
> 1917:         int valueLength = length << UTF16;
> 1918:         if ((Integer.MAX_VALUE - this.count) / count < valueLength) {

I think you can omit this check; the call to ensureCapacityInternal will guard against the needed size.

-------------

PR: https://git.openjdk.org/jdk/pull/12728

From mchung at openjdk.org  Thu Feb 23 16:48:07 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Thu, 23 Feb 2023 16:48:07 GMT
Subject: RFR: 8292914: Drop the counter from lambda class names [v8]
In-Reply-To: <zqMC9xu2wx3w4OLoQg8GsbA7kwNojT4ezvtPaYjfDjE=.828d10f8-9107-49d5-a822-aec5b2832455@github.com>
References: <GgLfH-ueBQqT-Mfk1mKpKFAt8fYqyjfVJ9lmlsBsCbo=.8dd5b3b4-4e84-4970-9179-1c0399b30edc@github.com>
 <AdfREeJYVkF6HTsw669hMueQxdGXUXxYc4GetiDuoDk=.5124c8b8-3bea-4baa-bbb1-9383c84bb15f@github.com>
 <zqMC9xu2wx3w4OLoQg8GsbA7kwNojT4ezvtPaYjfDjE=.828d10f8-9107-49d5-a822-aec5b2832455@github.com>
Message-ID: <rkZEp641oxFunHdXo3vuzFIA5dUZ3EVgE6nTT-c20oU=.40dd41c8-affb-417c-ae16-5f8d9df1c563@github.com>

On Wed, 22 Feb 2023 16:40:07 GMT, David M. Lloyd <duke at openjdk.org> wrote:

>> David M. Lloyd has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Many tests have patterns for lambda class names; update them
>>  - Update comments and javadoc showin the old pattern
>
> Could I please trouble someone for a review?

I like John's suggestion to rename the dump file.    The simple change would be to dump the class in a temp file in the dumper directory and then rename it if the hidden class is defined successfully.  @dmlloyd what do u think?

-------------

PR: https://git.openjdk.org/jdk/pull/12579

From rgiulietti at openjdk.org  Thu Feb 23 16:50:06 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Thu, 23 Feb 2023 16:50:06 GMT
Subject: RFR: 8302590: Add String.indexOf(int ch, int fromIndex,
 int toIndex)
In-Reply-To: <OY1C6dkxFHJZkbBfHn7lKNN-0HjRhfGq02v6y6UGGhY=.d1468f14-9ab5-4723-9ed4-1bf21163acb9@github.com>
References: <uQ65oRaVDfpzm9bYRuo_MvSuZIdepicE3GnB3Omyngs=.fc23545b-141a-47e5-8a6a-aa28ae1375e5@github.com>
 <OY1C6dkxFHJZkbBfHn7lKNN-0HjRhfGq02v6y6UGGhY=.d1468f14-9ab5-4723-9ed4-1bf21163acb9@github.com>
Message-ID: <TXvWuYeCAQV7rs493wxN343HuwOnIAZ8O8mcoPkaPc8=.75b0a6dd-64bb-4dd6-969d-c7cff8f8492e@github.com>

On Thu, 23 Feb 2023 16:21:53 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Add an `indexOf()` variant allowing to specify both a lower and an upper bound on the search.
>
> Is there any performance impact? Are there relevant JHM tests? Or should be added.
> Also to verify that the intrinsics are still valid though the parameter names have changed.

@RogerRiggs Which performance impacts are you concerned with? Perhaps the additional invocation detour in `indexOf(int ch, int fromIndex)`?

AFAICT, there's nothing in `vmIntrinsic.[hpp|cpp]` that would relate to the Java parameter names. Only the method name and the (encoded) parameter types appear there. But of course, it would cost nothing to change them back if I'm wrong.

-------------

PR: https://git.openjdk.org/jdk/pull/12600

From mcimadamore at openjdk.org  Thu Feb 23 16:51:08 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 23 Feb 2023 16:51:08 GMT
Subject: RFR: 8303040: linux PPC64le: Implementation of Foreign Function &
 Memory API (Preview) [v2]
In-Reply-To: <fuCE3G5PEBbCwNPdIpSDdIPLp-SIzFqFfmEpMVQ3d6o=.2f60727b-0a90-4daa-9614-1439bffcc335@github.com>
References: <Yuxy6FrsDAN79ya8w8UIkvytGr25zGllDPtPJ1QbGwc=.182664b2-6d8c-497e-a4ae-95e0ad007cf9@github.com>
 <SZ9m3BFFwxhPqEQUx1LujV3bCXCdNdejuOTPJI0x7Wo=.74ffb1ac-5069-4e7d-afe4-d83cc550dbfc@github.com>
 <ObvdkU6yekW6azQzDoM9-SGayZ5Y3ikHr-VM2TqYqFQ=.e19970d7-af19-4273-b2f7-c7dbb476b23f@github.com>
 <3dzZfm_BSXLL_iWAmllX-8YXAe1NWMMPr11zJtedIWU=.8a1dd1df-4eb7-4c72-9a06-f4636e5ec3e4@github.com>
 <fuCE3G5PEBbCwNPdIpSDdIPLp-SIzFqFfmEpMVQ3d6o=.2f60727b-0a90-4daa-9614-1439bffcc335@github.com>
Message-ID: <-q-cx5Voa0dNJS0d8od_Ui7KRqc4fc5VRHxaPjI07X0=.f79a8180-c247-487f-a994-4d0192482a43@github.com>

On Thu, 23 Feb 2023 15:02:48 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

> > > Correct, `extsw` performs a `I2L` conversion. I had thought about this already, but I think my current implementation is more efficient as it combines register moves with the 64 bit extend. Your proposal would generate separate extend and move instructions, right?
> > 
> > 
> > Would it be possible to generate a biding cast + move and the recognize the pattern in the HS backend and optimize it away as a `extsw` ?
> 
> At the moment, there is a forced indirection between the Java code and downcall stub, so the JIT can not do any optimizations that have to take both sides into account. The downcall stub is opaque to the JIT. (though, perhaps in the long run we can add intrinsification of `linkToNative` that can generate the code in the downcall stub as part of the JIT's own IR, which would solve this)

I meant generating `extsw` when emitting the stub (since when we emit the stub we can see the bindings). But I suppose the problem there is that the VM only sees low level bindings such as moves, it doesn't see bindings such as casts.

-------------

PR: https://git.openjdk.org/jdk/pull/12708

From briangoetz at openjdk.org  Thu Feb 23 16:51:13 2023
From: briangoetz at openjdk.org (Brian Goetz)
Date: Thu, 23 Feb 2023 16:51:13 GMT
Subject: RFR: 8292914: Drop the counter from lambda class names [v8]
In-Reply-To: <AdfREeJYVkF6HTsw669hMueQxdGXUXxYc4GetiDuoDk=.5124c8b8-3bea-4baa-bbb1-9383c84bb15f@github.com>
References: <GgLfH-ueBQqT-Mfk1mKpKFAt8fYqyjfVJ9lmlsBsCbo=.8dd5b3b4-4e84-4970-9179-1c0399b30edc@github.com>
 <AdfREeJYVkF6HTsw669hMueQxdGXUXxYc4GetiDuoDk=.5124c8b8-3bea-4baa-bbb1-9383c84bb15f@github.com>
Message-ID: <rJhM0qDiedWF0EKR5AryC_ngYaZ4q2hrDxL5HNNVdGc=.01fea672-0652-40e0-a57f-06ea9cb14a77@github.com>

On Fri, 17 Feb 2023 19:37:59 GMT, David M. Lloyd <duke at openjdk.org> wrote:

>> The class generated for lambda proxies is now defined as a hidden class. This means that the counter, which was used to ensure a unique class name and avoid clashes, is now redundant. In addition to performing redundant work, this also impacts build reproducibility for native image generators which might already have a strategy to cope with hidden classes but cannot cope with indeterminate definition order for lambda proxy classes.
>> 
>> This solves JDK-8292914 by making lambda proxy names always be stable without any configuration needed. This would also replace #10024.
>
> David M. Lloyd has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Many tests have patterns for lambda class names; update them
>  - Update comments and javadoc showin the old pattern

As a separate issue (not intended to block this one), "dump generated 
code for debugging" is common to a number of bootstraps, many of which 
use (or will use) hidden classes, and it would be good to have shared 
infrastructure for this.

On 2/23/2023 11:45 AM, Mandy Chung wrote:
>
> I like John's suggestion to rename the dump file. The simple change 
> would be to dump the class in a temp file in the dumper directory and 
> then rename it if the hidden class is defined successfully. @dmlloyd 
> <https://github.com/dmlloyd> what do u think?
>
> ?
> Reply to this email directly, view it on GitHub 
> <https://github.com/openjdk/jdk/pull/12579#issuecomment-1442096713>, 
> or unsubscribe 
> <https://github.com/notifications/unsubscribe-auth/AABJ4RAMN4FF4LKYPCHO2V3WY6HZVANCNFSM6AAAAAAU5ELQRU>.
> You are receiving this because you commented.Message ID: 
> ***@***.***>
>

-------------

PR: https://git.openjdk.org/jdk/pull/12579

From duke at openjdk.org  Thu Feb 23 16:54:19 2023
From: duke at openjdk.org (David M. Lloyd)
Date: Thu, 23 Feb 2023 16:54:19 GMT
Subject: RFR: 8292914: Drop the counter from lambda class names [v8]
In-Reply-To: <AdfREeJYVkF6HTsw669hMueQxdGXUXxYc4GetiDuoDk=.5124c8b8-3bea-4baa-bbb1-9383c84bb15f@github.com>
References: <GgLfH-ueBQqT-Mfk1mKpKFAt8fYqyjfVJ9lmlsBsCbo=.8dd5b3b4-4e84-4970-9179-1c0399b30edc@github.com>
 <AdfREeJYVkF6HTsw669hMueQxdGXUXxYc4GetiDuoDk=.5124c8b8-3bea-4baa-bbb1-9383c84bb15f@github.com>
Message-ID: <jyxlON3D2mM9JPL0Gew_09YrIqS73jarOrMTbf1I-Is=.665d10df-0099-49d9-a4c1-39587b049dfc@github.com>

On Fri, 17 Feb 2023 19:37:59 GMT, David M. Lloyd <duke at openjdk.org> wrote:

>> The class generated for lambda proxies is now defined as a hidden class. This means that the counter, which was used to ensure a unique class name and avoid clashes, is now redundant. In addition to performing redundant work, this also impacts build reproducibility for native image generators which might already have a strategy to cope with hidden classes but cannot cope with indeterminate definition order for lambda proxy classes.
>> 
>> This solves JDK-8292914 by making lambda proxy names always be stable without any configuration needed. This would also replace #10024.
>
> David M. Lloyd has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Many tests have patterns for lambda class names; update them
>  - Update comments and javadoc showin the old pattern

I took that only as a suggestion; the current implementation achieves the same result by writing the class bytes with *either* the "decorated" name *or* a counter-based name that also indicates that definition has failed.

The concern I would have with writing the bytes and then renaming is that the class name would likely conflict with others unless a counter were employed for all dump files from the start; but then, you end up with files disappearing (from the perspective of the user) as well as the counter appearing "out of sequence" after things get renamed to the decorated name. Also IIRC you could potentially get into file lock weirdness on Windows if the user sees & opens the file after it is written but before it is renamed.

The only drawback to the current implementation in this patch compared to John's suggestion is that the class bytes will not be written until after the class definition is complete (or fails). But I don't see this as much of a drawback.

-------------

PR: https://git.openjdk.org/jdk/pull/12579

From jlaskey at openjdk.org  Thu Feb 23 16:57:26 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Thu, 23 Feb 2023 16:57:26 GMT
Subject: RFR: JDK-8302323 Add repeat methods to StringBuilder/StringBuffer
In-Reply-To: <kd73pqt7CR5_hxkpR5ekp2s7j7K-203INQwJrNVYW-Q=.798df78a-aa6d-4616-a3a3-66b78dfa0cc4@github.com>
References: <ygMjzllqk27Dss1q2oRgcNvK_GJdbFVweVHTvF7zpwY=.06d27701-6b42-4663-958e-f8aca9bc2bc5@github.com>
 <kd73pqt7CR5_hxkpR5ekp2s7j7K-203INQwJrNVYW-Q=.798df78a-aa6d-4616-a3a3-66b78dfa0cc4@github.com>
Message-ID: <zvVvcXD-heQSimjnYYivQL5fZdBKJ4BxVck6Cq1DIKE=.350eaa85-3721-4a48-a993-0cc8d1fef6eb@github.com>

On Thu, 23 Feb 2023 16:40:32 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Add the ability to repeatedly append char and CharSequence data to StringBuilder/StringBuffer.
>
> src/java.base/share/classes/java/lang/AbstractStringBuilder.java line 1918:
> 
>> 1916:         }
>> 1917:         int valueLength = length << UTF16;
>> 1918:         if ((Integer.MAX_VALUE - this.count) / count < valueLength) {
> 
> I think you can omit this check; the call to ensureCapacityInternal will guard against the needed size.

You may be right - I looked over ensureCapacityInternal a few times, just noticing the signed shift. Thx.

-------------

PR: https://git.openjdk.org/jdk/pull/12728

From jvernee at openjdk.org  Thu Feb 23 17:14:37 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Thu, 23 Feb 2023 17:14:37 GMT
Subject: RFR: 8303040: linux PPC64le: Implementation of Foreign Function &
 Memory API (Preview) [v2]
In-Reply-To: <-q-cx5Voa0dNJS0d8od_Ui7KRqc4fc5VRHxaPjI07X0=.f79a8180-c247-487f-a994-4d0192482a43@github.com>
References: <Yuxy6FrsDAN79ya8w8UIkvytGr25zGllDPtPJ1QbGwc=.182664b2-6d8c-497e-a4ae-95e0ad007cf9@github.com>
 <SZ9m3BFFwxhPqEQUx1LujV3bCXCdNdejuOTPJI0x7Wo=.74ffb1ac-5069-4e7d-afe4-d83cc550dbfc@github.com>
 <ObvdkU6yekW6azQzDoM9-SGayZ5Y3ikHr-VM2TqYqFQ=.e19970d7-af19-4273-b2f7-c7dbb476b23f@github.com>
 <3dzZfm_BSXLL_iWAmllX-8YXAe1NWMMPr11zJtedIWU=.8a1dd1df-4eb7-4c72-9a06-f4636e5ec3e4@github.com>
 <fuCE3G5PEBbCwNPdIpSDdIPLp-SIzFqFfmEpMVQ3d6o=.2f60727b-0a90-4daa-9614-1439bffcc335@github.com>
 <-q-cx5Voa0dNJS0d8od_Ui7KRqc4fc5VRHxaPjI07X0=.f79a8180-c247-487f-a994-4d0192482a43@github.com>
Message-ID: <owJKuane2U5y8oCM3Zq0IOPrX_gJWnX9SpDrvkR2mSA=.6d1c4c08-ff4b-4e92-895b-a93eb310115b@github.com>

On Thu, 23 Feb 2023 16:48:30 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> I meant generating extsw when emitting the stub (since when we emit the stub we can see the bindings). But I suppose the problem there is that the VM only sees low level bindings such as moves, it doesn't see bindings such as casts.

Oh, sorry, I see what you mean now. But yeah, the VM stub only handles moves, and I think we want to keep it that way (for reasons outlined). The VM stub can be viewed as a low-level primitive that accepts a set of register/stack values, and moves them into the corresponding locations. It's not really supposed to be doing any kind of processing of the values it receives or returns.

-------------

PR: https://git.openjdk.org/jdk/pull/12708

From jlaskey at openjdk.org  Thu Feb 23 17:30:34 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Thu, 23 Feb 2023 17:30:34 GMT
Subject: RFR: JDK-8302323 Add repeat methods to StringBuilder/StringBuffer
In-Reply-To: <zvVvcXD-heQSimjnYYivQL5fZdBKJ4BxVck6Cq1DIKE=.350eaa85-3721-4a48-a993-0cc8d1fef6eb@github.com>
References: <ygMjzllqk27Dss1q2oRgcNvK_GJdbFVweVHTvF7zpwY=.06d27701-6b42-4663-958e-f8aca9bc2bc5@github.com>
 <kd73pqt7CR5_hxkpR5ekp2s7j7K-203INQwJrNVYW-Q=.798df78a-aa6d-4616-a3a3-66b78dfa0cc4@github.com>
 <zvVvcXD-heQSimjnYYivQL5fZdBKJ4BxVck6Cq1DIKE=.350eaa85-3721-4a48-a993-0cc8d1fef6eb@github.com>
Message-ID: <Jk0aO8GzNJ5akOblfA77PL_pzkBUYKXotm908Ss57jM=.b7b49b47-c803-47d3-a97b-f13d89e04954@github.com>

On Thu, 23 Feb 2023 16:54:10 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/AbstractStringBuilder.java line 1918:
>> 
>>> 1916:         }
>>> 1917:         int valueLength = length << UTF16;
>>> 1918:         if ((Integer.MAX_VALUE - this.count) / count < valueLength) {
>> 
>> I think you can omit this check; the call to ensureCapacityInternal will guard against the needed size.
>
> You may be right - I looked over ensureCapacityInternal a few times, just noticing the signed shift. Thx.

Nope - because of the int multiple ensureCapacityInternal doesn't handle it.

-------------

PR: https://git.openjdk.org/jdk/pull/12728

From igraves at openjdk.org  Thu Feb 23 17:31:02 2023
From: igraves at openjdk.org (Ian Graves)
Date: Thu, 23 Feb 2023 17:31:02 GMT
Subject: RFR: 8293667: Align jlink's --compress option with jmod's
 --compress option [v12]
In-Reply-To: <JWevwHuR2vF3k-JRxmTAxfNN6g-EBkgG2N9DHn4fkGY=.f9768dfd-cab4-49a9-83b9-d77a1572e917@github.com>
References: <JWevwHuR2vF3k-JRxmTAxfNN6g-EBkgG2N9DHn4fkGY=.f9768dfd-cab4-49a9-83b9-d77a1572e917@github.com>
Message-ID: <-4qIO07A7gXvu-H85WoZcoDnaogVJiDtZGiN6GSbLbo=.20488ff1-f838-40c9-943a-16abaebe37aa@github.com>

> This is an approach to adding a flag to jlink that will allow --compress to take the same types of arguments as jmod, thus bringing the two into alignment. This likely requires a CSR and a discussion on whether we should deprecate or simply remove the original numeric compression arguments.

Ian Graves has updated the pull request incrementally with one additional commit since the last revision:

  Tweaking properties

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/11617/files
  - new: https://git.openjdk.org/jdk/pull/11617/files/74ec4f4b..b4339c7c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11617&range=11
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11617&range=10-11

  Stats: 6 lines in 1 file changed: 0 ins; 0 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/11617.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11617/head:pull/11617

PR: https://git.openjdk.org/jdk/pull/11617

From jlaskey at openjdk.org  Thu Feb 23 17:39:10 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Thu, 23 Feb 2023 17:39:10 GMT
Subject: RFR: JDK-8302323 Add repeat methods to StringBuilder/StringBuffer
 [v2]
In-Reply-To: <ygMjzllqk27Dss1q2oRgcNvK_GJdbFVweVHTvF7zpwY=.06d27701-6b42-4663-958e-f8aca9bc2bc5@github.com>
References: <ygMjzllqk27Dss1q2oRgcNvK_GJdbFVweVHTvF7zpwY=.06d27701-6b42-4663-958e-f8aca9bc2bc5@github.com>
Message-ID: <93WJpJLHppFi0Zk0rXLYsJzP14Hp-8dE80OawQ8vCp0=.dd22af95-bbc5-4f77-871e-3738daf6b379@github.com>

> Add the ability to repeatedly append char and CharSequence data to StringBuilder/StringBuffer.

Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:

  PR Cleanup

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12728/files
  - new: https://git.openjdk.org/jdk/pull/12728/files/c4c1e76a..530f5543

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12728&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12728&range=00-01

  Stats: 59 lines in 4 files changed: 5 ins; 25 del; 29 mod
  Patch: https://git.openjdk.org/jdk/pull/12728.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12728/head:pull/12728

PR: https://git.openjdk.org/jdk/pull/12728

From sviswanathan at openjdk.org  Thu Feb 23 17:47:49 2023
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Thu, 23 Feb 2023 17:47:49 GMT
Subject: RFR: 8302976: C2 intrinsification of Float.floatToFloat16 and
 Float.float16ToFloat yields different result than the interpreter
In-Reply-To: <f18TfSibBBm5FLon1VlUN0m6fNUzvOpsUeo7nEAk7JY=.456ddc51-7be7-4484-ad38-1039453b83d6@github.com>
References: <f18TfSibBBm5FLon1VlUN0m6fNUzvOpsUeo7nEAk7JY=.456ddc51-7be7-4484-ad38-1039453b83d6@github.com>
Message-ID: <z57ZwbITNH9KUAWjw24zRhqm8IHVkGWH9tk0Nv9WyYU=.b0d29ed9-20c6-4f6c-8143-76f6141514ce@github.com>

On Wed, 22 Feb 2023 02:08:27 GMT, Sandhya Viswanathan <sviswanathan at openjdk.org> wrote:

> Change the java/lang/float.java and the corresponding shared runtime constant expression evaluation to generate QNaN.
> The HW instructions generate QNaNs and not SNaNs for floating point instructions. This happens across double, float, and float16 data types. The most significant bit of mantissa is set to 1 for QNaNs.

Thankyou very much all for your valuable inputs. I think it is best to withdraw this PR.

-------------

PR: https://git.openjdk.org/jdk/pull/12704

From sviswanathan at openjdk.org  Thu Feb 23 17:47:51 2023
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Thu, 23 Feb 2023 17:47:51 GMT
Subject: Withdrawn: 8302976: C2 intrinsification of Float.floatToFloat16 and
 Float.float16ToFloat yields different result than the interpreter
In-Reply-To: <f18TfSibBBm5FLon1VlUN0m6fNUzvOpsUeo7nEAk7JY=.456ddc51-7be7-4484-ad38-1039453b83d6@github.com>
References: <f18TfSibBBm5FLon1VlUN0m6fNUzvOpsUeo7nEAk7JY=.456ddc51-7be7-4484-ad38-1039453b83d6@github.com>
Message-ID: <adMq9dM7l7WKMyQEb7v9NbOx7dul3tvQlLuN32vz7eo=.d8f5c5d8-3c42-421f-b005-978049a7996d@github.com>

On Wed, 22 Feb 2023 02:08:27 GMT, Sandhya Viswanathan <sviswanathan at openjdk.org> wrote:

> Change the java/lang/float.java and the corresponding shared runtime constant expression evaluation to generate QNaN.
> The HW instructions generate QNaNs and not SNaNs for floating point instructions. This happens across double, float, and float16 data types. The most significant bit of mantissa is set to 1 for QNaNs.

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/12704

From martin at openjdk.org  Thu Feb 23 17:48:46 2023
From: martin at openjdk.org (Martin Buchholz)
Date: Thu, 23 Feb 2023 17:48:46 GMT
Subject: RFR: 8302899: Executors.newSingleThreadExecutor can use Cleaner to
 shutdown executor [v4]
In-Reply-To: <gCqs5Difq993oMhXzOthVrWAHqCTCQefqYqSF_BP-Dc=.6ecb5e0a-cd13-4936-b0ab-245edc9898e8@github.com>
References: <tBrSZRn1GdrWMSRUsdNNyAWpkuS_FvtLwLuUKut6LH0=.cd1a7fcb-dbcf-45eb-b3d3-72ba17087566@github.com>
 <gCqs5Difq993oMhXzOthVrWAHqCTCQefqYqSF_BP-Dc=.6ecb5e0a-cd13-4936-b0ab-245edc9898e8@github.com>
Message-ID: <7iKdkAs4U8Xz9towZe3dUnwQWNze06Z9uvyb-1pvQJY=.399ed6cf-75a2-4718-923b-1ce171d37d40@github.com>

On Thu, 23 Feb 2023 08:31:36 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Executors.newSingleThreadExecutor returns a delegating ExecutorService that has finalizer to shutdown the underlying TPE when the wrapper is finalizable. It goes back to JDK 6 and JDK-6399443. This is the last non-empty finalizer in java.base. Removing it will likely lead to bug reports/complaints as the current behavior goes back to 2006. So the proposal is to just replace it with a Cleaner, trivially done in this case. As part of the changes, I've replaced the existing test with a more modern test that exercises more scenarios.
>
> 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
>  - Improve SM scenario
>  - Keep reference to Cleanable
>  - Merge
>  - Fix typo in comment, remove blank line
>  - Replace older test
>  - Initial commit

test/jdk/java/util/concurrent/Executors/AutoShutdown.java line 118:

> 116:      */
> 117:     private ExecutorService getDelegate(ExecutorService executor) throws Exception {
> 118:         Field eField = Class.forName("java.util.concurrent.Executors$DelegatedExecutorService")

I was under the impression that VarHandle/MethodHandle are generally preferred for writing white box tests (as I did myself in various WhiteBox.java tests).

-------------

PR: https://git.openjdk.org/jdk/pull/12675

From bpb at openjdk.org  Thu Feb 23 17:48:57 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 23 Feb 2023 17:48:57 GMT
Subject: RFR: 8302806: (fs) Remove
 com.sun.nio.file.SensitivityWatchEventModifier [v4]
In-Reply-To: <FZn8ZF4sN5mtUO8MWPaC0N8nWFwTLkBvcqQeOPwVYeE=.a6e12227-dfa9-4817-adbb-bece72445860@github.com>
References: <FZn8ZF4sN5mtUO8MWPaC0N8nWFwTLkBvcqQeOPwVYeE=.a6e12227-dfa9-4817-adbb-bece72445860@github.com>
Message-ID: <ydNj1FoAdu1gQKM45mV7gC0hyWDIWyDv0WoOcVZ3LpY=.ccd4b67e-b179-4a95-a201-1f055eba6f11@github.com>

> This enum is not used in the JDK and did not appear in external source code searches.

Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:

  8302806: Remove ExtendedOptions.SENSITIViTY_xxx and things depending on it

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12626/files
  - new: https://git.openjdk.org/jdk/pull/12626/files/e17f66c1..6172ac39

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12626&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12626&range=02-03

  Stats: 36 lines in 5 files changed: 2 ins; 22 del; 12 mod
  Patch: https://git.openjdk.org/jdk/pull/12626.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12626/head:pull/12626

PR: https://git.openjdk.org/jdk/pull/12626

From rgiulietti at openjdk.org  Thu Feb 23 18:26:09 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Thu, 23 Feb 2023 18:26:09 GMT
Subject: RFR: JDK-8302323 Add repeat methods to StringBuilder/StringBuffer
 [v2]
In-Reply-To: <93WJpJLHppFi0Zk0rXLYsJzP14Hp-8dE80OawQ8vCp0=.dd22af95-bbc5-4f77-871e-3738daf6b379@github.com>
References: <ygMjzllqk27Dss1q2oRgcNvK_GJdbFVweVHTvF7zpwY=.06d27701-6b42-4663-958e-f8aca9bc2bc5@github.com>
 <93WJpJLHppFi0Zk0rXLYsJzP14Hp-8dE80OawQ8vCp0=.dd22af95-bbc5-4f77-871e-3738daf6b379@github.com>
Message-ID: <LTY3P-b7gr2K6eoGZXuk_0mpCrPuKoyegPKc-0FJ3u4=.8abb328e-b906-44d7-8209-69cee3186df3@github.com>

On Thu, 23 Feb 2023 17:39:10 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> Add the ability to repeatedly append char and CharSequence data to StringBuilder/StringBuffer.
>
> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
> 
>   PR Cleanup

src/java.base/share/classes/java/lang/AbstractStringBuilder.java line 1850:

> 1848:         boolean isLatin1 = isLatin1();
> 1849:         if (isLatin1 && StringLatin1.canEncode(c)) {
> 1850:             while (index < limit) {

while (index != limit) {

is probably safer, in particular if `limit` has overflown to `Integer.MIN_VALUE`.
Not sure if this could happen, but...

-------------

PR: https://git.openjdk.org/jdk/pull/12728

From mchung at openjdk.org  Thu Feb 23 18:31:15 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Thu, 23 Feb 2023 18:31:15 GMT
Subject: RFR: 8293667: Align jlink's --compress option with jmod's
 --compress option [v12]
In-Reply-To: <-4qIO07A7gXvu-H85WoZcoDnaogVJiDtZGiN6GSbLbo=.20488ff1-f838-40c9-943a-16abaebe37aa@github.com>
References: <JWevwHuR2vF3k-JRxmTAxfNN6g-EBkgG2N9DHn4fkGY=.f9768dfd-cab4-49a9-83b9-d77a1572e917@github.com>
 <-4qIO07A7gXvu-H85WoZcoDnaogVJiDtZGiN6GSbLbo=.20488ff1-f838-40c9-943a-16abaebe37aa@github.com>
Message-ID: <ActlamARQ-nOweIa1-g456sx1T0OxtV9YyX32EudFw0=.d74edb34-fefe-47de-bc12-9b5765d5d088@github.com>

On Thu, 23 Feb 2023 17:31:02 GMT, Ian Graves <igraves at openjdk.org> wrote:

>> This is an approach to adding a flag to jlink that will allow --compress to take the same types of arguments as jmod, thus bringing the two into alignment. This likely requires a CSR and a discussion on whether we should deprecate or simply remove the original numeric compression arguments.
>
> Ian Graves has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Tweaking properties

Looks good in general.  Minor comments.

src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/DefaultCompressPlugin.java line 96:

> 94:             switch (level) {
> 95:                 case LEVEL_0:
> 96:                     System.err.println(getMessage("warn.prefix") + " " +

Suggestion:

                    System.err.println(getMessage("compress.warn.argumentdeprecated", level));


It can be simpler to out the warning prefix in the message.  Same for line 102 and 107.

src/jdk.jlink/share/classes/jdk/tools/jlink/resources/plugins.properties line 74:

> 72: 
> 73: compress.warn.argumentdeprecated=\
> 74: The {0} argument for --compress has been deprecated and will be removed from a future release

Suggestion:

Warning: The "{0}" argument for --compress is deprecated and may be removed from a future release.

-------------

Marked as reviewed by mchung (Reviewer).

PR: https://git.openjdk.org/jdk/pull/11617

From martin at openjdk.org  Thu Feb 23 18:56:09 2023
From: martin at openjdk.org (Martin Buchholz)
Date: Thu, 23 Feb 2023 18:56:09 GMT
Subject: RFR: JDK-8297605 DelayQueue javadoc is confusing
In-Reply-To: <jdJ46gB5VbY2LPrH7oGbtCtU65HGtd7GZ7SB8InbG-A=.8679db0c-28b2-4665-ab92-e89af0ad38e6@github.com>
References: <jdJ46gB5VbY2LPrH7oGbtCtU65HGtd7GZ7SB8InbG-A=.8679db0c-28b2-4665-ab92-e89af0ad38e6@github.com>
Message-ID: <cfM5AZ1s_z3rmncP1XE6WWUKu_ZDev0qFRBYF32ab7Q=.34bb1ab4-92d8-40cd-bc46-afdf6b6b703b@github.com>

On Thu, 23 Feb 2023 15:36:48 GMT, Viktor Klang <duke at openjdk.org> wrote:

> Clarifies the distinction between expiration of the head of DelayQueue and how it relates to `poll`, `take`, and `peek`. See discussion on https://bugs.openjdk.org/browse/JDK-8297605
> 
> @DougLea If possible, please weigh in on whether this is in line with your thoughts on the matter.

src/java.base/share/classes/java/util/concurrent/DelayQueue.java line 54:

> 52:  * when its delay has expired.  The <em>head</em> of the queue is that
> 53:  * {@code Delayed} element whose delay expired furthest in the
> 54:  * past.  If no delay has expired there is no head and {@code poll}

I like introducing the concept of "expired head".
Aren't we defining "expired head" here, not "head"?

-------------

PR: https://git.openjdk.org/jdk/pull/12729

From rriggs at openjdk.org  Thu Feb 23 19:07:10 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 23 Feb 2023 19:07:10 GMT
Subject: RFR: 8302590: Add String.indexOf(int ch, int fromIndex,
 int toIndex)
In-Reply-To: <uQ65oRaVDfpzm9bYRuo_MvSuZIdepicE3GnB3Omyngs=.fc23545b-141a-47e5-8a6a-aa28ae1375e5@github.com>
References: <uQ65oRaVDfpzm9bYRuo_MvSuZIdepicE3GnB3Omyngs=.fc23545b-141a-47e5-8a6a-aa28ae1375e5@github.com>
Message-ID: <e5NTzUo4CgRNg18roWci0Pcd3r9rNOBQc-PHOwct0c8=.ac46d852-0ec6-4a2c-a708-34c9c709089f@github.com>

On Thu, 16 Feb 2023 17:16:35 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

> Add an `indexOf()` variant allowing to specify both a lower and an upper bound on the search.

There should be no or little impact from the extra level of calls but its worth confirming.

src/java.base/share/classes/java/lang/String.java line 2462:

> 2460:      *
> 2461:      * <p>There are no restrictions on the value of {@code fromIndex} and
> 2462:      * {@code toIndex}. Negative values have the same effect as it they were zero.

"as it" -> "as if"

-------------

PR: https://git.openjdk.org/jdk/pull/12600

From igraves at openjdk.org  Thu Feb 23 19:07:20 2023
From: igraves at openjdk.org (Ian Graves)
Date: Thu, 23 Feb 2023 19:07:20 GMT
Subject: RFR: 8293667: Align jlink's --compress option with jmod's
 --compress option [v12]
In-Reply-To: <ActlamARQ-nOweIa1-g456sx1T0OxtV9YyX32EudFw0=.d74edb34-fefe-47de-bc12-9b5765d5d088@github.com>
References: <JWevwHuR2vF3k-JRxmTAxfNN6g-EBkgG2N9DHn4fkGY=.f9768dfd-cab4-49a9-83b9-d77a1572e917@github.com>
 <-4qIO07A7gXvu-H85WoZcoDnaogVJiDtZGiN6GSbLbo=.20488ff1-f838-40c9-943a-16abaebe37aa@github.com>
 <ActlamARQ-nOweIa1-g456sx1T0OxtV9YyX32EudFw0=.d74edb34-fefe-47de-bc12-9b5765d5d088@github.com>
Message-ID: <jrNWbOjUk6VNeHmq0aXcLgAFhSFCxWF8P13FGYXtoT0=.fbd986a5-1bb6-4b3d-add0-7be54606cf5d@github.com>

On Thu, 23 Feb 2023 18:27:53 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> Ian Graves has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Tweaking properties
>
> src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/DefaultCompressPlugin.java line 96:
> 
>> 94:             switch (level) {
>> 95:                 case LEVEL_0:
>> 96:                     System.err.println(getMessage("warn.prefix") + " " +
> 
> Suggestion:
> 
>                     System.err.println(getMessage("compress.warn.argumentdeprecated", level));
> 
> 
> It can be simpler to out the warning prefix in the message.  Same for line 102 and 107.

That works for me.

-------------

PR: https://git.openjdk.org/jdk/pull/11617

From martin at openjdk.org  Thu Feb 23 19:09:11 2023
From: martin at openjdk.org (Martin Buchholz)
Date: Thu, 23 Feb 2023 19:09:11 GMT
Subject: RFR: JDK-8297605 DelayQueue javadoc is confusing
In-Reply-To: <jdJ46gB5VbY2LPrH7oGbtCtU65HGtd7GZ7SB8InbG-A=.8679db0c-28b2-4665-ab92-e89af0ad38e6@github.com>
References: <jdJ46gB5VbY2LPrH7oGbtCtU65HGtd7GZ7SB8InbG-A=.8679db0c-28b2-4665-ab92-e89af0ad38e6@github.com>
Message-ID: <OYGYb9rb1FGlvH43fBXySfBCl2uj-F0SCmZF5LCfulY=.b690b033-cfb9-43c5-8553-87309fa86768@github.com>

On Thu, 23 Feb 2023 15:36:48 GMT, Viktor Klang <duke at openjdk.org> wrote:

> Clarifies the distinction between expiration of the head of DelayQueue and how it relates to `poll`, `take`, and `peek`. See discussion on https://bugs.openjdk.org/browse/JDK-8297605
> 
> @DougLea If possible, please weigh in on whether this is in line with your thoughts on the matter.

I like extending this approach as follows:
- define "head"
- define "expired head"
- make it clear that some methods operate on all elements (regardless of their expiration status), some only on expired elements.
- ensure that all public methods have an overriding javadoc that makes the distinction clear.  e.g. currently remove() needs such an overriding javadoc.
(writing good spec is hard work!)

-------------

PR: https://git.openjdk.org/jdk/pull/12729

From jlu at openjdk.org  Thu Feb 23 19:09:16 2023
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 23 Feb 2023 19:09:16 GMT
Subject: Integrated: 8302512: Update IANA Language Subtag Registry to Version
 2023-02-14
In-Reply-To: <or0F9vpHLkJyfwpgJfAuFmy8zI1yaZ_H9YAUyiXM3P8=.50952559-8a6d-4e85-bd65-b757d1ae0a3a@github.com>
References: <or0F9vpHLkJyfwpgJfAuFmy8zI1yaZ_H9YAUyiXM3P8=.50952559-8a6d-4e85-bd65-b757d1ae0a3a@github.com>
Message-ID: <1hhzooWrC54oyOD__Fdb5yxWgLAPZOJg-cs2DQGga6c=.307d42ba-f4aa-45d5-a046-85cc8c142ec7@github.com>

On Tue, 21 Feb 2023 19:26:46 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Incorporate the latest IANA language subtag registry definition (2023-02-14).

This pull request has now been integrated.

Changeset: f612dcfe
Author:    Justin Lu <jlu at openjdk.org>
Committer: Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/f612dcfebea7ffd4390f833646ad45d6f0ebd04f
Stats:     10 lines in 2 files changed: 6 ins; 0 del; 4 mod

8302512: Update IANA Language Subtag Registry to Version 2023-02-14

Reviewed-by: naoto

-------------

PR: https://git.openjdk.org/jdk/pull/12699

From duke at openjdk.org  Thu Feb 23 19:09:16 2023
From: duke at openjdk.org (Viktor Klang)
Date: Thu, 23 Feb 2023 19:09:16 GMT
Subject: RFR: JDK-8297605 DelayQueue javadoc is confusing
In-Reply-To: <cfM5AZ1s_z3rmncP1XE6WWUKu_ZDev0qFRBYF32ab7Q=.34bb1ab4-92d8-40cd-bc46-afdf6b6b703b@github.com>
References: <jdJ46gB5VbY2LPrH7oGbtCtU65HGtd7GZ7SB8InbG-A=.8679db0c-28b2-4665-ab92-e89af0ad38e6@github.com>
 <cfM5AZ1s_z3rmncP1XE6WWUKu_ZDev0qFRBYF32ab7Q=.34bb1ab4-92d8-40cd-bc46-afdf6b6b703b@github.com>
Message-ID: <ciIw3hkaioOqcCzL_Yp74PoC_nYicMtMiS7Gd2GNF2k=.d7603146-515a-4a40-b638-acaf69983f02@github.com>

On Thu, 23 Feb 2023 18:53:35 GMT, Martin Buchholz <martin at openjdk.org> wrote:

>> Clarifies the distinction between expiration of the head of DelayQueue and how it relates to `poll`, `take`, and `peek`. See discussion on https://bugs.openjdk.org/browse/JDK-8297605
>> 
>> @DougLea If possible, please weigh in on whether this is in line with your thoughts on the matter.
>
> src/java.base/share/classes/java/util/concurrent/DelayQueue.java line 54:
> 
>> 52:  * when its delay has expired.  The <em>head</em> of the queue is that
>> 53:  * {@code Delayed} element whose delay expired furthest in the
>> 54:  * past.  If no delay has expired there is no head and {@code poll}
> 
> I like introducing the concept of "expired head".
> Aren't we defining "expired head" here, not "head"?

@Martin-Buchholz I read the line before the removed line (The <em>head</em> of the queue is that {@code Delayed} element whose delay expired furthest in the past.) as defining that the head will be the thing with the "soonest" expiry, which is important if one is used to LIFO or FIFO. Any idea on how we could improve that sentence? ?

-------------

PR: https://git.openjdk.org/jdk/pull/12729

From igraves at openjdk.org  Thu Feb 23 19:15:49 2023
From: igraves at openjdk.org (Ian Graves)
Date: Thu, 23 Feb 2023 19:15:49 GMT
Subject: RFR: 8293667: Align jlink's --compress option with jmod's
 --compress option [v13]
In-Reply-To: <JWevwHuR2vF3k-JRxmTAxfNN6g-EBkgG2N9DHn4fkGY=.f9768dfd-cab4-49a9-83b9-d77a1572e917@github.com>
References: <JWevwHuR2vF3k-JRxmTAxfNN6g-EBkgG2N9DHn4fkGY=.f9768dfd-cab4-49a9-83b9-d77a1572e917@github.com>
Message-ID: <f6J6jojhU3IUQU0C8zBHqn0_Lbcbozow2nSEJiQERFM=.e7f32184-4df4-4c20-a4d6-e1825bfd2c1c@github.com>

> This is an approach to adding a flag to jlink that will allow --compress to take the same types of arguments as jmod, thus bringing the two into alignment. This likely requires a CSR and a discussion on whether we should deprecate or simply remove the original numeric compression arguments.

Ian Graves has updated the pull request incrementally with one additional commit since the last revision:

  Tweaking warning messages and shortening them

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/11617/files
  - new: https://git.openjdk.org/jdk/pull/11617/files/b4339c7c..271eb254

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11617&range=12
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11617&range=11-12

  Stats: 10 lines in 2 files changed: 0 ins; 3 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/11617.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11617/head:pull/11617

PR: https://git.openjdk.org/jdk/pull/11617

From naoto at openjdk.org  Thu Feb 23 19:34:44 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 23 Feb 2023 19:34:44 GMT
Subject: RFR: 8301119: Support for GB18030-2022 [v3]
In-Reply-To: <FXBchbCnbNloQO7Nlh9Ijue_c_YugGk-UC7_-ZAjY2o=.7e1ca01f-8cee-40bb-bb06-6e5670abe661@github.com>
References: <FXBchbCnbNloQO7Nlh9Ijue_c_YugGk-UC7_-ZAjY2o=.7e1ca01f-8cee-40bb-bb06-6e5670abe661@github.com>
Message-ID: <DbcSeT1d1ulLxFGuScNUYOimyD_bbHn9miPe9TvlSH8=.a10fd674-22b4-4d6b-ac97-3772babbcd3d@github.com>

> Upgrading the GB18030 charset in the JDK to the latest 2022 standard. Since this is not a compatible upgrade to the existing mapping, a new system property `jdk.charset.GB18030` is introduced. If it is set to "2000", the mapping falls back to the existing mapping based on the 2000 standard, otherwise, it defaults to 2022 mapping. Refer to the corresponding CSR for more detail.

Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:

  Moved the 2000 flag into GB18030

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12518/files
  - new: https://git.openjdk.org/jdk/pull/12518/files/b5379b69..4d4015a9

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12518&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12518&range=01-02

  Stats: 28 lines in 3 files changed: 6 ins; 18 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/12518.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12518/head:pull/12518

PR: https://git.openjdk.org/jdk/pull/12518

From naoto at openjdk.org  Thu Feb 23 19:36:10 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 23 Feb 2023 19:36:10 GMT
Subject: RFR: 8301119: Support for GB18030-2022 [v3]
In-Reply-To: <DZeiL86cxzx9DTJMKK5mvr8ywYt0TTP5V2ex3BkWjKM=.13f06b0c-f341-4b53-9f47-d275135d369f@github.com>
References: <FXBchbCnbNloQO7Nlh9Ijue_c_YugGk-UC7_-ZAjY2o=.7e1ca01f-8cee-40bb-bb06-6e5670abe661@github.com>
 <S6p8hZiWOrDpXAzaeJ3L4kOIferQtFHKmFaa_1gNTyo=.0a245135-1bf9-47a1-b992-36edcbc2d612@github.com>
 <Fo1WnNOBMptjHkVUUtdvx4p03Ci1ljacM9bkFux2Qus=.b8082d30-35e9-491e-88a0-d00105f4381b@github.com>
 <C8Fp0qE368HZbCo1tQIMBh44wZ19PyfQFcKlKWKcYnc=.1bbcec03-19ad-4f98-aff5-669ab82f2c0a@github.com>
 <yG5N8VCa7i5JK8uFGZ4am4f5YfkKNPRLn5f5eYox51A=.123fd849-517e-444d-b479-984bc39888de@github.com>
 <wO2OP3VuH8E8OF6GSkl0a-c6b6Sy1np5d2ThZO1sj1A=.4bb265be-df50-46cc-9976-2334f6f1e9ba@github.com>
 <jpkQafw1j_0fH0-cumhhoGpqMqfqFXCG-4lHUckF66I=.6e01f41d-7854-4c5a-be59-0eb5e4a78a49@github.com>
 <ljBTRKBiP-miZ-LTBn4BKKgWtuB-EB8woNMy74YaN68=.4ebd8a62-371d-4dc1-a441-08fa03913f4f@github.com>
 <DZeiL86cxzx9DTJMKK5mvr8ywYt0TTP5V2ex3BkWjKM=.13f06b0c-f341-4b53-9f47-d275135d369f@github.com>
Message-ID: <B4IvJCeiXPoSRP0Zr5eaSdK6GzcoWoZ6jjytYs80yxw=.546521a6-49b5-4aaf-8b3a-09ddc25aa5d3@github.com>

On Thu, 23 Feb 2023 10:07:22 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> would use of jdk.internal.util.SystemProps be an option here (if having to retrieve that value when we're at VM init level <1 ?
>
>> would use of jdk.internal.util.SystemProps be an option here (if having to retrieve that value when we're at VM init level <1 ?
> 
> The early startup scenario is early in the system property initialization, specifically SystemProps.Raw.<clinit> which will cause the encoding to be initialized. This has to avoid make use of system properties, otherwise you get a circular initialization issue.

> what this code is really reaching for is `static final` field semantics.

Exactly. Introducing the holder pattern in `StandardCharset` would solve the issue, but instead I moved the flag init into `GB18030` so that we can literally make it `static final`.

-------------

PR: https://git.openjdk.org/jdk/pull/12518

From naoto at openjdk.org  Thu Feb 23 20:02:14 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 23 Feb 2023 20:02:14 GMT
Subject: RFR: 8282319: java.util.Locale method to stream available Locales
In-Reply-To: <QxcV7IwdW13WfT0X0PKyWBWpo_rP588AgHIYiUu3E_Q=.82b88828-e8ec-4f3c-a75a-ec88b589d4e2@github.com>
References: <QxcV7IwdW13WfT0X0PKyWBWpo_rP588AgHIYiUu3E_Q=.82b88828-e8ec-4f3c-a75a-ec88b589d4e2@github.com>
Message-ID: <eIxZtTHU52wM5tLjvZ_shX59yv_w7s-ZHQydk0wnuOI=.b494d36b-48e9-4347-8454-968f7c163a36@github.com>

On Fri, 27 Jan 2023 21:48:26 GMT, Justin Lu <jlu at openjdk.org> wrote:

> This PR adds a new method to java.util.Locale which returns Stream<Locale>
> 
> The contents of the Stream are composed of the same underlying elements as Locale.getAvailableLocales().
> 
> This method allows streaming of the Locale array without creating a defensive copy.

Looks good. Some minor comments follow.

src/java.base/share/classes/java/util/Locale.java line 1223:

> 1221:      * {@code Locale} instance equal to {@link Locale#ROOT Locale.ROOT} and
> 1222:      * a {@code Locale} instance equal to {@link Locale#US Locale.US}.
> 1223:      * @implNote Unlike {@code getAvailableLocales()}, this method does

I'd insert a blank line between the method description paragraphs and the following javadoc tags.

src/java.base/share/classes/sun/util/locale/provider/LocaleServiceProviderPool.java line 155:

> 153:      * that are provided by each provider, including the JRE.
> 154:      *
> 155:      * @return a stream of the available locales for all provider classes

Could use {@return } as well.

test/jdk/java/util/Locale/StreamAvailableLocales.java line 26:

> 24:  * @test
> 25:  * @summary Test the implementation
> 26:  * of Locale.streamAvailableLocales()

`availableLocales()`? There are other locations using the name too.

-------------

PR: https://git.openjdk.org/jdk/pull/12269

From jlaskey at openjdk.org  Thu Feb 23 20:08:21 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Thu, 23 Feb 2023 20:08:21 GMT
Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates
 (Preview) [v41]
In-Reply-To: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
Message-ID: <8acQaVjcsJLZjZv02chxRMODQ1wJnJ6zvb5IkaIGH2w=.94b6a788-b129-4623-bd4e-ecaaeb4bce37@github.com>

> Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12).

Jim Laskey has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 56 commits:

 - Merge branch 'master' into 8285932
 - Merge branch 'master' into 8285932
 - Minor correction to javadoc
 - Merge branch 'master' into 8285932
 - CSR review
 - Bring up to date
 - Merge branch 'master' into 8285932
 - Update to JDK 21
 - Merge branch 'master' into 8285932
 - Merge branch 'master' into 8285932
 - ... and 46 more: https://git.openjdk.org/jdk/compare/6b24b4a7...89806d49

-------------

Changes: https://git.openjdk.org/jdk/pull/10889/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=40
  Stats: 9494 lines in 81 files changed: 9395 ins; 29 del; 70 mod
  Patch: https://git.openjdk.org/jdk/pull/10889.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10889/head:pull/10889

PR: https://git.openjdk.org/jdk/pull/10889

From bpb at openjdk.org  Thu Feb 23 21:16:41 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 23 Feb 2023 21:16:41 GMT
Subject: RFR: 8302806: (fs) Remove
 com.sun.nio.file.SensitivityWatchEventModifier [v5]
In-Reply-To: <FZn8ZF4sN5mtUO8MWPaC0N8nWFwTLkBvcqQeOPwVYeE=.a6e12227-dfa9-4817-adbb-bece72445860@github.com>
References: <FZn8ZF4sN5mtUO8MWPaC0N8nWFwTLkBvcqQeOPwVYeE=.a6e12227-dfa9-4817-adbb-bece72445860@github.com>
Message-ID: <W_HuvqiPNipq0E96Q8HUay1iwMrrF2STlKNDYd-D8z0=.0cb78060-fbd1-4070-9397-581c1ba8e5b9@github.com>

> This enum is not used in the JDK and did not appear in external source code searches.

Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:

  8302806: Remove modifier loops

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12626/files
  - new: https://git.openjdk.org/jdk/pull/12626/files/6172ac39..20c9ced3

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12626&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12626&range=03-04

  Stats: 5 lines in 2 files changed: 2 ins; 1 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/12626.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12626/head:pull/12626

PR: https://git.openjdk.org/jdk/pull/12626

From martin at openjdk.org  Thu Feb 23 21:23:11 2023
From: martin at openjdk.org (Martin Buchholz)
Date: Thu, 23 Feb 2023 21:23:11 GMT
Subject: RFR: JDK-8297605 DelayQueue javadoc is confusing
In-Reply-To: <jdJ46gB5VbY2LPrH7oGbtCtU65HGtd7GZ7SB8InbG-A=.8679db0c-28b2-4665-ab92-e89af0ad38e6@github.com>
References: <jdJ46gB5VbY2LPrH7oGbtCtU65HGtd7GZ7SB8InbG-A=.8679db0c-28b2-4665-ab92-e89af0ad38e6@github.com>
Message-ID: <m3sbJeTRxVnt7cx23kGHMaNhpOBfiYWg3fTW6S6XBys=.3f94ea53-90da-460a-80ea-416b91a7e669@github.com>

On Thu, 23 Feb 2023 15:36:48 GMT, Viktor Klang <duke at openjdk.org> wrote:

> Clarifies the distinction between expiration of the head of DelayQueue and how it relates to `poll`, `take`, and `peek`. See discussion on https://bugs.openjdk.org/browse/JDK-8297605
> 
> @DougLea If possible, please weigh in on whether this is in line with your thoughts on the matter.

Here's my attempt:


 * An unbounded {@linkplain BlockingQueue blocking queue} of {@link Delayed}
 * elements, in which an element generally becomes eligible for removal when its
 * delay has expired.
 *
 * <p>An element is considered <em>expired</em> when its {@code
 * getDelay(TimeUnit.NANOSECONDS)} method would return a value less than or
 * equal to zero.
 *
 * <p>An element is considered the <em>head</em> of the queue if it is the
 * element with the earliest expiration time, whether in the past or the future,
 * if there is such an element.
 *
 * <p>An element is considered the <em>expired head</em> of the queue if it is
 * the <em>expired</em> element with the earliest expiration time in the
 * past, if there is such an element.
 * The <em>expired head</em>, when present, is also the <em>head</em>.
 *
 * <p>While this class implements the {@code BlockingQueue} interface, it
 * intentionally violates the general contract of {@code BlockingQueue}, in that
 * the following methods disregard the presence of unexpired elements and only
 * ever remove the <em>expired head</em>:
 *
 * <ul>
 * <li> {@link #poll()}
 * <li> {@link #poll(long,TimeUnit)}
 * <li> {@link #take()}
 * <li> {@link #remove()}
 * </ul>
 *
 * <p>All other methods operate on both expired and unexpired elements.  For
 * example, the {@code size} method returns the count of all elements.  Method
 * {@link peek()} may return the non-null <em>head</em> even when {@code
 * take()} would block waiting for an expired element.
 *
 * <p>This queue does not permit null elements.

-------------

PR: https://git.openjdk.org/jdk/pull/12729

From dholmes at openjdk.org  Thu Feb 23 22:33:06 2023
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 23 Feb 2023 22:33:06 GMT
Subject: RFR: JDK-8303072: Memory leak in exeNullCallerTest.cpp
In-Reply-To: <CeYIh1UwJeTs52-a3EJQThW5XEymSruJhYB9Qx_nkj0=.d48da304-04b1-41cc-89f3-14f222ef847b@github.com>
References: <CeYIh1UwJeTs52-a3EJQThW5XEymSruJhYB9Qx_nkj0=.d48da304-04b1-41cc-89f3-14f222ef847b@github.com>
Message-ID: <hRJ53zb4uPcW87_AHs-dP5RX5VgA9qcp14Pt1fkLf2E=.4761a956-26c1-4360-97e6-9dabca87c3b9@github.com>

On Wed, 22 Feb 2023 14:02:28 GMT, Justin King <jcking at openjdk.org> wrote:

> Fix trivial memory leak that occurs during tests.

Seems fine.

Thanks.

-------------

Marked as reviewed by dholmes (Reviewer).

PR: https://git.openjdk.org/jdk/pull/12715

From lmesnik at openjdk.org  Thu Feb 23 22:43:05 2023
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Thu, 23 Feb 2023 22:43:05 GMT
Subject: RFR: 8302267: [jittester] Improve separation of test generation
 and execution [v2]
In-Reply-To: <HPYLuHpPdXMDXg2kEtUdEDf1FxkfvLwRRomQtM7oybQ=.726d67e9-f4c0-4aa9-98ff-76d89ddf8034@github.com>
References: <yHw6Lto-nJtPP61cZLDF354osHA-ioeq7_lgpefLvog=.6de22e18-0613-4ffb-a753-b66b95e9d52b@github.com>
 <HPYLuHpPdXMDXg2kEtUdEDf1FxkfvLwRRomQtM7oybQ=.726d67e9-f4c0-4aa9-98ff-76d89ddf8034@github.com>
Message-ID: <oXUYNR0ikHyXdaGrSdjl792gVSKWOcseyZSlMjkSfAQ=.71ddfead-bb89-4bdb-a564-7bbd67179d81@github.com>

On Wed, 22 Feb 2023 17:43:23 GMT, Evgeny Nikitin <enikitin at openjdk.org> wrote:

>> Please review a set of improvements that should improve working with other fuzzing generators and usage of JitTesterDriver with tests generated not by the JITTester:
>> 
>> - Provide better separation of individual test generation from java file writing, compiling, executing, etc.;
>> - Introduce distinct Phases of the generation process (Generation, Compilation, GoldRun and VerificationRun);
>> - Extract JItTesterDriver headers generation so that it would be possible to provide other header generators;
>> - Introduce error tolerance to not get distracted by OOMEs, intrinsics missing in the compiled code, etc.;
>> - Make it possible to specify time limit for an individual test generation;
>> - Give better control over temp/workdir creation and cleaning;
>> - Unify external process running;
>> - Introduce UTF-8 support in external processes' output and human-readable escaping of it;
>
> Evgeny Nikitin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Ignore large files

Marked as reviewed by lmesnik (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/12527

From mchung at openjdk.org  Thu Feb 23 23:29:09 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Thu, 23 Feb 2023 23:29:09 GMT
Subject: RFR: 8293667: Align jlink's --compress option with jmod's
 --compress option [v12]
In-Reply-To: <jrNWbOjUk6VNeHmq0aXcLgAFhSFCxWF8P13FGYXtoT0=.fbd986a5-1bb6-4b3d-add0-7be54606cf5d@github.com>
References: <JWevwHuR2vF3k-JRxmTAxfNN6g-EBkgG2N9DHn4fkGY=.f9768dfd-cab4-49a9-83b9-d77a1572e917@github.com>
 <-4qIO07A7gXvu-H85WoZcoDnaogVJiDtZGiN6GSbLbo=.20488ff1-f838-40c9-943a-16abaebe37aa@github.com>
 <ActlamARQ-nOweIa1-g456sx1T0OxtV9YyX32EudFw0=.d74edb34-fefe-47de-bc12-9b5765d5d088@github.com>
 <jrNWbOjUk6VNeHmq0aXcLgAFhSFCxWF8P13FGYXtoT0=.fbd986a5-1bb6-4b3d-add0-7be54606cf5d@github.com>
Message-ID: <1NHHZyvVF43attOtFjq93u6puFcqZV_4BXWeWITtU1Q=.bcd9abf8-00d5-4195-8edd-faf41634629a@github.com>

On Thu, 23 Feb 2023 19:04:33 GMT, Ian Graves <igraves at openjdk.org> wrote:

>> src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/DefaultCompressPlugin.java line 96:
>> 
>>> 94:             switch (level) {
>>> 95:                 case LEVEL_0:
>>> 96:                     System.err.println(getMessage("warn.prefix") + " " +
>> 
>> Suggestion:
>> 
>>                     System.err.println(getMessage("compress.warn.argumentdeprecated", level));
>> 
>> 
>> It can be simpler to out the warning prefix in the message.  Same for line 102 and 107.
>
> That works for me.

I saw you updated plugins.properties but you miss this change.

-------------

PR: https://git.openjdk.org/jdk/pull/11617

From mchung at openjdk.org  Thu Feb 23 23:29:14 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Thu, 23 Feb 2023 23:29:14 GMT
Subject: RFR: 8293667: Align jlink's --compress option with jmod's
 --compress option [v13]
In-Reply-To: <f6J6jojhU3IUQU0C8zBHqn0_Lbcbozow2nSEJiQERFM=.e7f32184-4df4-4c20-a4d6-e1825bfd2c1c@github.com>
References: <JWevwHuR2vF3k-JRxmTAxfNN6g-EBkgG2N9DHn4fkGY=.f9768dfd-cab4-49a9-83b9-d77a1572e917@github.com>
 <f6J6jojhU3IUQU0C8zBHqn0_Lbcbozow2nSEJiQERFM=.e7f32184-4df4-4c20-a4d6-e1825bfd2c1c@github.com>
Message-ID: <SH0aaVAE4ci0bHZ74TWPDjcArd0FGfvtC7RW3qY7lSw=.c9a16a6b-cf81-488c-8c0c-30ddf3107246@github.com>

On Thu, 23 Feb 2023 19:15:49 GMT, Ian Graves <igraves at openjdk.org> wrote:

>> This is an approach to adding a flag to jlink that will allow --compress to take the same types of arguments as jmod, thus bringing the two into alignment. This likely requires a CSR and a discussion on whether we should deprecate or simply remove the original numeric compression arguments.
>
> Ian Graves has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Tweaking warning messages and shortening them

src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/DefaultCompressPlugin.java line 97:

> 95:                 case LEVEL_0:
> 96:                     System.err.println(MessageFormat
> 97:                             .format(getMessage("compress.warn.argumentdeprecated"), LEVEL_0));

Suggestion:

                    System.err.println(getMessage("compress.warn.argumentdeprecated", LEVEL_0));


same applies to L102 and 107.

-------------

PR: https://git.openjdk.org/jdk/pull/11617

From darcy at openjdk.org  Thu Feb 23 23:36:00 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Thu, 23 Feb 2023 23:36:00 GMT
Subject: RFR: JDK-8302040: Port fdlibm sqrt to Java
Message-ID: <rjVM2lWPdsvPcfLF3oNShP-cSN8-P-i16ikUC3sTgIg=.1d4f470d-2ac9-4394-b55e-099affce763f@github.com>

The wheel of FDLIBM porting turns a notch and sqrt comes into play.

While the sqrt operation usually has a hardware implementation that is intrinsified, for completeness a software implementation should be available as well.

-------------

Commit messages:
 - JDK-8302040: Port fdlibm sqrt to Java

Changes: https://git.openjdk.org/jdk/pull/12736/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12736&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8302040
  Stats: 865 lines in 6 files changed: 861 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/12736.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12736/head:pull/12736

PR: https://git.openjdk.org/jdk/pull/12736

From darcy at openjdk.org  Thu Feb 23 23:36:04 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Thu, 23 Feb 2023 23:36:04 GMT
Subject: RFR: JDK-8302040: Port fdlibm sqrt to Java
In-Reply-To: <rjVM2lWPdsvPcfLF3oNShP-cSN8-P-i16ikUC3sTgIg=.1d4f470d-2ac9-4394-b55e-099affce763f@github.com>
References: <rjVM2lWPdsvPcfLF3oNShP-cSN8-P-i16ikUC3sTgIg=.1d4f470d-2ac9-4394-b55e-099affce763f@github.com>
Message-ID: <qYTWP2l6jbtTCQb-He95PVZLX8yqDJLblNxj74EnAsI=.e730e73c-8590-4465-bfc1-8ee504c80520@github.com>

On Thu, 23 Feb 2023 23:28:11 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> The wheel of FDLIBM porting turns a notch and sqrt comes into play.
> 
> While the sqrt operation usually has a hardware implementation that is intrinsified, for completeness a software implementation should be available as well.

src/java.base/share/classes/java/lang/StrictMath.java line 312:

> 310:      * @return  the positive square root of {@code a}.
> 311:      */
> 312:     // @IntrinsicCandidate -- Temporarily disable for testing

I'll revert commenting out the intrinsic annotation before pushing.

-------------

PR: https://git.openjdk.org/jdk/pull/12736

From darcy at openjdk.org  Thu Feb 23 23:38:05 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Thu, 23 Feb 2023 23:38:05 GMT
Subject: RFR: JDK-8302040: Port fdlibm sqrt to Java
In-Reply-To: <rjVM2lWPdsvPcfLF3oNShP-cSN8-P-i16ikUC3sTgIg=.1d4f470d-2ac9-4394-b55e-099affce763f@github.com>
References: <rjVM2lWPdsvPcfLF3oNShP-cSN8-P-i16ikUC3sTgIg=.1d4f470d-2ac9-4394-b55e-099affce763f@github.com>
Message-ID: <EHU0ptpyq1zUnrLhbnGfHjLCXKW_B7MaO8mhneJ0v_4=.8a8b5366-e3e4-416b-99e8-5b2132a60d8b@github.com>

On Thu, 23 Feb 2023 23:28:11 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> The wheel of FDLIBM porting turns a notch and sqrt comes into play.
> 
> While the sqrt operation usually has a hardware implementation that is intrinsified, for completeness a software implementation should be available as well.

In local testing, both the transliteration port and the Fdlibm.java port are consistent with hardware sqrt when run against all float values.

Comparing the various ports, original C sources vs transliteration port:


$ diff -w Sqrt.c  Sqrt.translit.java 
1c1
< /* __ieee754_sqrt(x)
---
>     /**
69a70,71
>     static class Sqrt {
>         private static final double    one     = 1.0, tiny=1.0e-300;
71,86c73,74
< #include "fdlibm.h"
< 
< #ifdef __STDC__
< static  const double    one     = 1.0, tiny=1.0e-300;
< #else
< static  double  one     = 1.0, tiny=1.0e-300;
< #endif
< 
< #ifdef __STDC__
<         double __ieee754_sqrt(double x)
< #else
<         double __ieee754_sqrt(x)
<         double x;
< #endif
< {
<         double z;
---
>         public static double compute(double x) {
>             double z = 0.0;
88c76
<         unsigned r,t1,s1,ix1,q1;
---
>             /*unsigned*/ int r,t1,s1,ix1,q1;
110c98
<                 ix0 |= (ix1>>11); ix1 <<= 21;
---
>                     ix0 |= (ix1>>>11); ix1 <<= 21; // unsigned shift
114c102
<             ix0 |= (ix1>>(32-i));
---
>                 ix0 |= (ix1>>>(32-i)); // unsigned shift
119,120c107,108
<         if(m&1){        /* odd m, double x to make it even */
<             ix0 += ix0 + ((ix1&sign)>>31);
---
>             if((m&1) != 0){        /* odd m, double x to make it even */
>                 ix0 += ix0 + ((ix1&sign)>>>31); // unsigned shift
126c114
<         ix0 += ix0 + ((ix1&sign)>>31);
---
>             ix0 += ix0 + ((ix1&sign)>>>31); // unsigned shift
138c126
<             ix0 += ix0 + ((ix1&sign)>>31);
---
>                 ix0 += ix0 + ((ix1&sign)>>>31); // unsigned shift
140c128
<             r>>=1;
---
>                 r>>>=1; // unsigned shift
147c135
<             if((t<ix0)||((t==ix0)&&(t1<=ix1))) {
---
>                 if((t<ix0)||((t==ix0)&&(Integer.compareUnsigned(t1, ix1) <= 0 ))) { // t1<=ix1
151c139
<                 if (ix1 < t1) ix0 -= 1;
---
>                     if (Integer.compareUnsigned(ix1, t1) < 0) ix0 -= 1; // ix1 < t1
155c143
<             ix0 += ix0 + ((ix1&sign)>>31);
---
>                 ix0 += ix0 + ((ix1&sign)>>>31);
157c145
<             r>>=1;
---
>                 r>>>=1; // unsigned shift
165c153
<                 if (q1==(unsigned)0xffffffff) { q1=0; q += 1;}
---
>                     if (q1==0xffffffff) { q1=0; q += 1;}
167c155
<                     if (q1==(unsigned)0xfffffffe) q+=1;
---
>                         if (q1==0xfffffffe) q+=1;
174c162
<         ix1 =  q1>>1;
---
>             ix1 =  q1>>>1; // unsigned shift
177,178c165,168
<         __HI(z) = ix0;
<         __LO(z) = ix1;
---
>             // __HI(z) = ix0;
>             z = __HI(z, ix0);
>             // __LO(z) = ix1;
>             z = __LO(z, ix1);
180a171
>     }



The the variables declared unsigned, checked to use unsigned right shifts (>>>) and to use the unsigned comparison methods.


$ diff -w  Sqrt.translit.java Sqrt.fdlibm.java 
71c71
<         private static final double    one     = 1.0, tiny=1.0e-300;
---
>         private Sqrt() {throw new UnsupportedOperationException();}
73c73,75
<         public static double compute(double x) {
---
>         private static final double tiny = 1.0e-300;
> 
>         static double compute(double x) {
75c77
<             int     sign = (int)0x80000000;
---
>             int sign = 0x8000_0000;
79,80c81,82
<             ix0 = __HI(x);                  /* high word of x */
<             ix1 = __LO(x);          /* low word of x */
---
>             ix0 = __HI(x);  // high word of x
>             ix1 = __LO(x);  // low word of x
82,85c84,86
<             /* take care of Inf and NaN */
<             if((ix0&0x7ff00000)==0x7ff00000) {
<                 return x*x+x;               /* sqrt(NaN)=NaN, sqrt(+inf)=+inf
<                                                sqrt(-inf)=sNaN */
---
>             // take care of Inf and NaN
>             if((ix0 & 0x7ff0_0000) == 0x7ff0_0000) {
>                 return x*x + x; // sqrt(NaN)=NaN, sqrt(+inf)=+inf, sqrt(-inf)=sNaN
87c88
<             /* take care of zero */
---
>             // take care of zero
89c90,91
<                 if(((ix0&(~sign))|ix1)==0) return x;/* sqrt(+-0) = +-0 */
---
>                 if (((ix0 & (~sign)) | ix1) == 0)
>                     return x; // sqrt(+-0) = +-0
91c93
<                     return (x-x)/(x-x);             /* sqrt(-ve) = sNaN */
---
>                     return (x-x)/(x-x); // sqrt(-ve) = sNaN
93c95
<             /* normalize x */
---
>             // normalize x
95c97
<             if(m==0) {                              /* subnormal x */
---
>             if (m == 0) { // subnormal x
98c100,104
<                     ix0 |= (ix1>>>11); ix1 <<= 21; // unsigned shift
---
>                     ix0 |= (ix1 >>> 11); // unsigned shift
>                     ix1 <<= 21;
>                 }
>                 for(i = 0; (ix0 & 0x0010_0000) == 0; i++) {
>                     ix0 <<= 1;
100d105
<                 for(i=0;(ix0&0x00100000)==0;i++) ix0<<=1;
105,107c110,112
<             m -= 1023;      /* unbias exponent */
<             ix0 = (ix0&0x000fffff)|0x00100000;
<             if((m&1) != 0){        /* odd m, double x to make it even */
---
>             m -= 1023;      // unbias exponent */
>             ix0 = (ix0 & 0x000f_ffff) | 0x0010_0000;
>             if ((m & 1) != 0){        // odd m, double x to make it even
111c116
<             m >>= 1;        /* m = [m/2] */
---
>             m >>= 1;        // m = [m/2]
113c118
<             /* generate sqrt(x) bit by bit */
---
>             // generate sqrt(x) bit by bit
116,117c121,122
<             q = q1 = s0 = s1 = 0;   /* [q,q1] = sqrt(x) */
<             r = 0x00200000;         /* r = moving bit from right to left */
---
>             q = q1 = s0 = s1 = 0;   // [q,q1] = sqrt(x)
>             r = 0x0020_0000;        // r = moving bit from right to left
135c140,141
<                 if((t<ix0)||((t==ix0)&&(Integer.compareUnsigned(t1, ix1) <= 0 ))) { // t1<=ix1
---
>                 if((t < ix0) ||
>                    ((t == ix0) && (Integer.compareUnsigned(t1, ix1) <= 0 ))) { // t1 <= ix1
137c143,145
<                     if(((t1&sign)==sign)&&(s1&sign)==0) s0 += 1;
---
>                     if (((t1 & sign) == sign) && (s1 & sign) == 0) {
>                         s0 += 1;
>                     }
139c147,149
<                     if (Integer.compareUnsigned(ix1, t1) < 0) ix0 -= 1; // ix1 < t1
---
>                     if (Integer.compareUnsigned(ix1, t1) < 0) {  // ix1 < t1
>                         ix0 -= 1;
>                     }
148c158
<             /* use floating add to find out rounding direction */
---
>             // use floating add to find out rounding direction
150,155c160,169
<                 z = one-tiny; /* trigger inexact flag */
<                 if (z>=one) {
<                     z = one+tiny;
<                     if (q1==0xffffffff) { q1=0; q += 1;}
<                     else if (z>one) {
<                         if (q1==0xfffffffe) q+=1;
---
>                 z = 1.0 - tiny; // trigger inexact flag
>                 if (z >= 1.0) {
>                     z = 1.0 + tiny;
>                     if (q1 == 0xffff_ffff) {
>                         q1 = 0;
>                         q += 1;
>                     } else if (z > 1.0) {
>                         if (q1 == 0xffff_fffe) {
>                             q += 1;
>                         }
157c171
<                     } else
---
>                     } else {
161c175,176
<             ix0 = (q>>1)+0x3fe00000;
---
>             }
>             ix0 = (q >> 1) + 0x3fe0_0000;
163c178,180
<             if ((q&1)==1) ix1 |= sign;
---
>             if ((q & 1) == 1) {
>                 ix1 |= sign;
>             }
165d181
<             // __HI(z) = ix0;
167d182
<             // __LO(z) = ix1;

-------------

PR: https://git.openjdk.org/jdk/pull/12736

From darcy at openjdk.org  Thu Feb 23 23:42:05 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Thu, 23 Feb 2023 23:42:05 GMT
Subject: RFR: JDK-8302040: Port fdlibm sqrt to Java
In-Reply-To: <rjVM2lWPdsvPcfLF3oNShP-cSN8-P-i16ikUC3sTgIg=.1d4f470d-2ac9-4394-b55e-099affce763f@github.com>
References: <rjVM2lWPdsvPcfLF3oNShP-cSN8-P-i16ikUC3sTgIg=.1d4f470d-2ac9-4394-b55e-099affce763f@github.com>
Message-ID: <Q9XfwYgplnOvwwf21RZGdEeyjPzTDqMc8LEDt84vOww=.7f42be76-b16d-4a76-80a2-f1fd9f0374c7@github.com>

On Thu, 23 Feb 2023 23:28:11 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> The wheel of FDLIBM porting turns a notch and sqrt comes into play.
> 
> While the sqrt operation usually has a hardware implementation that is intrinsified, for completeness a software implementation should be available as well.

src/java.base/share/classes/java/lang/FdLibm.java line 689:

> 687:             ix0 += (m << 20);
> 688:             z = __HI(z, ix0);
> 689:             z = __LO(z, ix1);

I was tempted to rewrite these line as something like:
`return Double.longBitsToDouble((long)ix0 << 32 | (long)ix1);`
and may do so in a future refactoring.

-------------

PR: https://git.openjdk.org/jdk/pull/12736

From mchung at openjdk.org  Thu Feb 23 23:54:12 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Thu, 23 Feb 2023 23:54:12 GMT
Subject: RFR: 8292914: Drop the counter from lambda class names [v8]
In-Reply-To: <AdfREeJYVkF6HTsw669hMueQxdGXUXxYc4GetiDuoDk=.5124c8b8-3bea-4baa-bbb1-9383c84bb15f@github.com>
References: <GgLfH-ueBQqT-Mfk1mKpKFAt8fYqyjfVJ9lmlsBsCbo=.8dd5b3b4-4e84-4970-9179-1c0399b30edc@github.com>
 <AdfREeJYVkF6HTsw669hMueQxdGXUXxYc4GetiDuoDk=.5124c8b8-3bea-4baa-bbb1-9383c84bb15f@github.com>
Message-ID: <Xe5S5U8DjBjtfnEQfKL87zhlUjIkERrZ0xaR9UaNXH8=.e785e130-0a82-4bae-beb2-39cac82efeb7@github.com>

On Fri, 17 Feb 2023 19:37:59 GMT, David M. Lloyd <duke at openjdk.org> wrote:

>> The class generated for lambda proxies is now defined as a hidden class. This means that the counter, which was used to ensure a unique class name and avoid clashes, is now redundant. In addition to performing redundant work, this also impacts build reproducibility for native image generators which might already have a strategy to cope with hidden classes but cannot cope with indeterminate definition order for lambda proxy classes.
>> 
>> This solves JDK-8292914 by making lambda proxy names always be stable without any configuration needed. This would also replace #10024.
>
> David M. Lloyd has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Many tests have patterns for lambda class names; update them
>  - Update comments and javadoc showin the old pattern

src/java.base/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java line 370:

> 368:                 if (useImplMethodHandle) {
> 369:                     lookup = caller.defineHiddenClassWithClassData(classBytes, implementation, !disableEagerInitialization,
> 370:                         NESTMATE, STRONG);

nit: formatting - align this line to the first argument `classBytes` in L369.

src/java.base/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java line 374:

> 372:                     lookup = caller.defineHiddenClass(classBytes, !disableEagerInitialization, NESTMATE, STRONG);
> 373:                 }
> 374:             } catch (Throwable t) {

suggest to use try-finally in writing the file.


            Lookup lookup = null;
            try {
                if (useImplMethodHandle) {
                    lookup = caller.defineHiddenClassWithClassData(classBytes, implementation, !disableEagerInitialization,
                                                                   NESTMATE, STRONG);
                } else {
                    lookup = caller.defineHiddenClass(classBytes, !disableEagerInitialization, NESTMATE, STRONG);
                }
            } finally {
                // If requested, dump out to a file for debugging purposes
                if (dumper != null) {
                    final String name;
                    if (lookup != null) {
                        String definedName = lookup.lookupClass().getName();
                        int suffixIdx = definedName.lastIndexOf('/');
                        assert suffixIdx != -1;
                        name = lambdaClassName + '.' + definedName.substring(suffixIdx + 1);
                    } else {
                        name = lambdaClassName + ".failed-" + counter.incrementAndGet();
                    }
                    doDump(name, classBytes);
                }
            }
            return lookup.lookupClass();

-------------

PR: https://git.openjdk.org/jdk/pull/12579

From mchung at openjdk.org  Fri Feb 24 00:16:08 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Fri, 24 Feb 2023 00:16:08 GMT
Subject: RFR: 8292914: Drop the counter from lambda class names [v8]
In-Reply-To: <AdfREeJYVkF6HTsw669hMueQxdGXUXxYc4GetiDuoDk=.5124c8b8-3bea-4baa-bbb1-9383c84bb15f@github.com>
References: <GgLfH-ueBQqT-Mfk1mKpKFAt8fYqyjfVJ9lmlsBsCbo=.8dd5b3b4-4e84-4970-9179-1c0399b30edc@github.com>
 <AdfREeJYVkF6HTsw669hMueQxdGXUXxYc4GetiDuoDk=.5124c8b8-3bea-4baa-bbb1-9383c84bb15f@github.com>
Message-ID: <xh7y376By688XtiJh8iffshayWkbjHXbFzLHzxxYCD8=.a44ae88d-5c32-4ccb-bb0e-ca296d6edbd6@github.com>

On Fri, 17 Feb 2023 19:37:59 GMT, David M. Lloyd <duke at openjdk.org> wrote:

>> The class generated for lambda proxies is now defined as a hidden class. This means that the counter, which was used to ensure a unique class name and avoid clashes, is now redundant. In addition to performing redundant work, this also impacts build reproducibility for native image generators which might already have a strategy to cope with hidden classes but cannot cope with indeterminate definition order for lambda proxy classes.
>> 
>> This solves JDK-8292914 by making lambda proxy names always be stable without any configuration needed. This would also replace #10024.
>
> David M. Lloyd has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Many tests have patterns for lambda class names; update them
>  - Update comments and javadoc showin the old pattern

Looks good in general.  Using try-finally will simplify the code as such doDump in the finally block with the appropriate name depending on the condition.

Please also update the copyright end year.

-------------

PR: https://git.openjdk.org/jdk/pull/12579

From igraves at openjdk.org  Fri Feb 24 01:26:41 2023
From: igraves at openjdk.org (Ian Graves)
Date: Fri, 24 Feb 2023 01:26:41 GMT
Subject: RFR: 8293667: Align jlink's --compress option with jmod's
 --compress option [v14]
In-Reply-To: <JWevwHuR2vF3k-JRxmTAxfNN6g-EBkgG2N9DHn4fkGY=.f9768dfd-cab4-49a9-83b9-d77a1572e917@github.com>
References: <JWevwHuR2vF3k-JRxmTAxfNN6g-EBkgG2N9DHn4fkGY=.f9768dfd-cab4-49a9-83b9-d77a1572e917@github.com>
Message-ID: <LAsRVWPz8-wHHcHLHNvh46nJxxc7ZwjUmAFZNL9xdU0=.2e34661d-60f9-4f62-9c45-23517bde3389@github.com>

> This is an approach to adding a flag to jlink that will allow --compress to take the same types of arguments as jmod, thus bringing the two into alignment. This likely requires a CSR and a discussion on whether we should deprecate or simply remove the original numeric compression arguments.

Ian Graves has updated the pull request incrementally with one additional commit since the last revision:

  Additional cleanup

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/11617/files
  - new: https://git.openjdk.org/jdk/pull/11617/files/271eb254..186e0224

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11617&range=13
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11617&range=12-13

  Stats: 7 lines in 1 file changed: 0 ins; 4 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/11617.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11617/head:pull/11617

PR: https://git.openjdk.org/jdk/pull/11617

From bchristi at openjdk.org  Fri Feb 24 01:32:09 2023
From: bchristi at openjdk.org (Brent Christian)
Date: Fri, 24 Feb 2023 01:32:09 GMT
Subject: RFR: 8302899: Executors.newSingleThreadExecutor can use Cleaner to
 shutdown executor [v4]
In-Reply-To: <Pyef2cyAuj51_8yJnc7rBu91s9XpDtDgdLF1pzD9YKc=.7d42b280-4662-454a-8a29-991a6af6fe99@github.com>
References: <tBrSZRn1GdrWMSRUsdNNyAWpkuS_FvtLwLuUKut6LH0=.cd1a7fcb-dbcf-45eb-b3d3-72ba17087566@github.com>
 <Yb8iiHeLmWsAjOwzDqzQJwLNLDY50RhuegwRbl6LHuU=.960992f3-c292-4db2-968f-be03fe273d95@github.com>
 <4k90pf4Nl6DHOAg1ydW0bKgagFH3ZKfH5cb3C7Fazbk=.e1561c56-2508-48f2-9542-cd95d70e264b@github.com>
 <Pyef2cyAuj51_8yJnc7rBu91s9XpDtDgdLF1pzD9YKc=.7d42b280-4662-454a-8a29-991a6af6fe99@github.com>
Message-ID: <LIHo7Z5kYWVho6InzuBQZwX2kplmC87zuHXueUp1HM4=.ebaa6bb2-f972-4ac8-b340-e141f0fbf1ec@github.com>

On Tue, 21 Feb 2023 20:27:44 GMT, Martin Buchholz <martin at openjdk.org> wrote:

>> jtreg will look after this. The default timeout is 120s but it can be adjusted with a timeout factor (make time uses a timeout factor of 4). So it would be possible to put a limit on this in the test but it can be problematic, e.g. with debug builds + Xcomp for example.
>
> I have written such code many times, and I've always had success with a (jtreg-scaled) 10 second timeout.  E.g.
> 
> static final long LONG_DELAY_MS = Utils.adjustTimeout(10_000);
> 
> (But that's before I became aware of existence of (slow) Raspberry Pis.)
> 
> I continue to feel guilty about never having written a proper gc awaiting library utility for openjdk, like I did for guava here:
> 
> https://github.com/google/guava/blob/master/guava-testlib/src/com/google/common/testing/GcFinalization.java

Now there's [jdk.test.lib.util.ForceGC](https://github.com/openjdk/jdk/blob/master/test/lib/jdk/test/lib/util/ForceGC.java).

-------------

PR: https://git.openjdk.org/jdk/pull/12675

From darcy at openjdk.org  Fri Feb 24 01:39:05 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 24 Feb 2023 01:39:05 GMT
Subject: RFR: JDK-8302040: Port fdlibm sqrt to Java
In-Reply-To: <rjVM2lWPdsvPcfLF3oNShP-cSN8-P-i16ikUC3sTgIg=.1d4f470d-2ac9-4394-b55e-099affce763f@github.com>
References: <rjVM2lWPdsvPcfLF3oNShP-cSN8-P-i16ikUC3sTgIg=.1d4f470d-2ac9-4394-b55e-099affce763f@github.com>
Message-ID: <m5oRDeDpx5Btp4o0uk6epGvBJKulf5meouuxN8cu1G0=.628b2e5c-0529-46b4-a841-10729afd6db9@github.com>

On Thu, 23 Feb 2023 23:28:11 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> The wheel of FDLIBM porting turns a notch and sqrt comes into play.
> 
> While the sqrt operation usually has a hardware implementation that is intrinsified, for completeness a software implementation should be available as well.

src/java.base/share/classes/java/lang/FdLibm.java line 696:

> 694:     // The following comment is supplementary information from the FDLIBM sources.
> 695: 
> 696:     /*

I didn't think it was necessary to preserve this supplemental information in both the transliteration port and the mainline sources.

-------------

PR: https://git.openjdk.org/jdk/pull/12736

From mchung at openjdk.org  Fri Feb 24 03:55:11 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Fri, 24 Feb 2023 03:55:11 GMT
Subject: RFR: 8293667: Align jlink's --compress option with jmod's
 --compress option [v14]
In-Reply-To: <LAsRVWPz8-wHHcHLHNvh46nJxxc7ZwjUmAFZNL9xdU0=.2e34661d-60f9-4f62-9c45-23517bde3389@github.com>
References: <JWevwHuR2vF3k-JRxmTAxfNN6g-EBkgG2N9DHn4fkGY=.f9768dfd-cab4-49a9-83b9-d77a1572e917@github.com>
 <LAsRVWPz8-wHHcHLHNvh46nJxxc7ZwjUmAFZNL9xdU0=.2e34661d-60f9-4f62-9c45-23517bde3389@github.com>
Message-ID: <4Ba3xL_HbguCcDjHq_6oXitRzsQ11x68lLMTG4i1aWE=.15162423-12aa-4634-8b2e-6c1a7f1656ac@github.com>

On Fri, 24 Feb 2023 01:26:41 GMT, Ian Graves <igraves at openjdk.org> wrote:

>> This is an approach to adding a flag to jlink that will allow --compress to take the same types of arguments as jmod, thus bringing the two into alignment. This likely requires a CSR and a discussion on whether we should deprecate or simply remove the original numeric compression arguments.
>
> Ian Graves has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Additional cleanup

Marked as reviewed by mchung (Reviewer).

src/jdk.jlink/share/classes/jdk/tools/jlink/resources/plugins.properties line 74:

> 72: 
> 73: compress.warn.argumentdeprecated=\
> 74: Warning: The {0} argument for --compress is deprecated and may be removed from a future release

Suggestion:

Warning: The {0} argument for --compress is deprecated and may be removed in a future release


Sorry missed this in the previous round.  `s/from/in`

-------------

PR: https://git.openjdk.org/jdk/pull/11617

From mdoerr at openjdk.org  Fri Feb 24 04:07:06 2023
From: mdoerr at openjdk.org (Martin Doerr)
Date: Fri, 24 Feb 2023 04:07:06 GMT
Subject: RFR: 8303040: linux PPC64le: Implementation of Foreign Function &
 Memory API (Preview) [v3]
In-Reply-To: <8b3vVrV22RuhdRoRYacXV0ZeghFGgKkC8S_z-iMrzAQ=.dd84b743-8b51-4281-8f5f-f9eff6207bc7@github.com>
References: <Yuxy6FrsDAN79ya8w8UIkvytGr25zGllDPtPJ1QbGwc=.182664b2-6d8c-497e-a4ae-95e0ad007cf9@github.com>
 <8b3vVrV22RuhdRoRYacXV0ZeghFGgKkC8S_z-iMrzAQ=.dd84b743-8b51-4281-8f5f-f9eff6207bc7@github.com>
Message-ID: <HT8kQfjS98dYHeAMcNL5latokRiw3YK8npxl5yCD4hw=.28b19bac-cbfa-4461-a1db-c899c55b7485@github.com>

On Thu, 23 Feb 2023 06:18:49 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> Implementation of "Foreign Function & Memory API" for linux on Power (Little Endian) according to "Power Architecture 64-Bit ELF V2 ABI Specification".
>> 
>> This PR does not include code for VaList support because it's supposed to get removed by [JDK-8299736](https://bugs.openjdk.org/browse/JDK-8299736). I've kept the related tests disabled for this platform and throw an exception instead. Note that the ABI doesn't precisely specify variable argument lists. Instead, it refers to `<stdarg.h>` (2.2.4 Variable Argument Lists).
>> 
>> Big Endian support is implemented to some extend, but not complete. E.g. structs with size not divisible by 8 are not passed correctly (see `useABIv2` in CallArranger.java). Big Endian is excluded by selecting `ARCH.equals("ppc64le")` (CABI.java) only.
>> 
>> There's another limitation: This PR only accepts structures with size divisible by 4. (An `IllegalArgumentException` gets thrown otherwise.) I think arbitrary sizes are not usable on other platforms, either, because `SharedUtils.primitiveCarrierForSize` only accepts powers of 2.
>> 
>> The ABI has some tricky corner cases related to HFA (Homogeneous Float Aggregate). The same argument may need to get passed in both, a FP reg and a GP reg or stack slot (see "no partial DW rule"). This cases are not covered by the existing tests.
>> 
>> I had to make changes to shared code and code for other platforms:
>> 1. Pass type information when creating `VMStorage` objects from `VMReg`. This is needed for the following reasons:
>> - PPC64 ABI requires integer types to get extended to 64 bit (also see CCallingConventionRequiresIntsAsLongs in existing hotspot code). We need to know the type or at least the bit width for that.
>> - Floating point load / store instructions need the correct width to select between the correct IEEE 754 formats. The register representation in single FP registers is always IEEE 754 double precision on PPC64.
>> - Big Endian also needs usage of the precise size. Storing 8 Bytes and loading 4 Bytes yields different values than on Little Endian!
>> 2. It happens that a `NativeMemorySegmentImpl` is used as a raw pointer (with byteSize() == 0) while running TestUpcallScope. Hence, existing size checks don't work (see MemorySegment.java). As a workaround, I'm just skipping the check in this particular case. Please check if this makes sense or if there's a better fix (possibly as separate RFE).
>
> Martin Doerr has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove size restriction for structs. Add TODO for Big Endian.

Some more remarks about other issues:
- Uploaded my simple reproducer to [JDK-8303017](https://bugs.openjdk.org/browse/JDK-8303017)
- Using oversized load / stores is problematic. Don't forget that OpenJDK still supports Big Endian platforms (AIX, s390x).
- Since the membar on the return path was mentioned: I think it would be good to enable UseSystemMemoryBarrier by default on operating systems which support it. Maybe we should discuss this with @robehn.

-------------

PR: https://git.openjdk.org/jdk/pull/12708

From mchung at openjdk.org  Fri Feb 24 06:12:03 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Fri, 24 Feb 2023 06:12:03 GMT
Subject: RFR: 8302791: Add specific ClassLoader object to Proxy
 IllegalArgumentException message
In-Reply-To: <NX5FE2YPsglCCPDpGLEorNik96Hrzq7b5wMF7AwrzHw=.03bdd7d3-8b35-4f4f-9d97-022e6aa91b1a@github.com>
References: <O5sadWrVYh2fiWVEDQLWPnBPMH73RNHmN4ifU7h4a4k=.490377ab-f81b-4a21-8017-2bc002b0ccc8@github.com>
 <NX5FE2YPsglCCPDpGLEorNik96Hrzq7b5wMF7AwrzHw=.03bdd7d3-8b35-4f4f-9d97-022e6aa91b1a@github.com>
Message-ID: <djS9tvmolvVfVi4tQKACDxt1JqAi_DhdILQAF0bWo0E=.6c4248d4-7bca-47d9-a262-c3169c8d9bf2@github.com>

On Wed, 22 Feb 2023 07:24:48 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Added specific class loader object to proxy IllegalArgumentException from which the class was not visible
>> 
>> The bug report for the same: https://bugs.openjdk.org/browse/JDK-8302791
>
> src/java.base/share/classes/java/lang/reflect/Proxy.java line 881:
> 
>> 879:             if (type != c) {
>> 880:                 throw new IllegalArgumentException(c.getName() +
>> 881:                         " referenced from a method is not visible from class loader: " + ld);
> 
> The ClassLoader string representation may or may not be useful here. One suggestion is to use the class loader name (ld.getName()) if not null, otherwise Objects.toIdentityString(ld).

I also think it's helpful to print the name of class loader if present, or the identity string as Alan suggests.

-------------

PR: https://git.openjdk.org/jdk/pull/12641

From mchung at openjdk.org  Fri Feb 24 06:31:12 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Fri, 24 Feb 2023 06:31:12 GMT
Subject: RFR: 8302154: Hidden classes created by LambdaMetaFactory can't be
 unloaded [v2]
In-Reply-To: <gKoLpwlXDxp2uaSKSkMArJl1Ym9VX1hoDFqQTTUpk8w=.e1dce669-5a42-4b66-ac4b-205718c8eb81@github.com>
References: <YoZauVv8zvhdUw-LD25LrsMDItFbg3aXPU3deXwwFdQ=.c2839dea-12e5-4e0e-9579-eac9d8503932@github.com>
 <gKoLpwlXDxp2uaSKSkMArJl1Ym9VX1hoDFqQTTUpk8w=.e1dce669-5a42-4b66-ac4b-205718c8eb81@github.com>
Message-ID: <T8P2Y-w9iwZ0fmtl1UUK3_CbXgKyX63htubfvWHy-Kk=.edf7e40e-5126-47c3-bb71-5bdbe79ba761@github.com>

On Thu, 9 Feb 2023 18:11:18 GMT, Volker Simonis <simonis at openjdk.org> wrote:

>> Prior to [JDK-8239384](https://bugs.openjdk.org/browse/JDK-8239384)/[JDK-8238358](https://bugs.openjdk.org/browse/JDK-8238358) LambdaMetaFactory has created VM-anonymous classes which could easily be unloaded once they were not referenced any more. Starting with JDK 15 and the new "hidden class" based implementation, this is not the case any more, because the hidden classes will be strongly tied to their defining class loader. If this is the default application class loader, these hidden classes can never be unloaded which can easily lead to Metaspace exhaustion (see the [test case in the JBS issue](https://bugs.openjdk.org/secure/attachment/102601/LambdaClassLeak.java)). This is a regression compared to previous JDK versions which some of our applications have been affected from when migrating to JDK 17.
>> 
>> The reason why the newly created hidden classes are strongly linked to their defining class loader is not clear to me. JDK-8239384 mentions it as an "implementation detail":
>> 
>>> *4. the lambda proxy class has the strong relationship with the class loader (that will share the VM metaspace for its defining loader - implementation details)*
>> 
>> From my current understanding the strong link between a hidden class created by `LambdaMetaFactory` and its defining class loader is not strictly required. In order to prevent potential OOMs and fix the regression compared the JDK 14 and earlier I propose to create these hidden classes without the `STRONG` option.
>> 
>> I'll be happy to add the test case as JTreg test to this PR if you think that would be useful.
>
> Volker Simonis has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Remove assertions which insist on Lambda proxy classes being strongly linked to their class loader
>  - Removed unused import of STRONG und updated copyright year

As Remi, others and I explained, whether lambda metafactory uses strong hidden classes or VM anonymous classes (weak hidden classes) is implementation details.   The lambda proxy class is a logical part of the caller class as it's the implementation of the lambda, i.e. strongly-linked with the defining class loader.

-------------

PR: https://git.openjdk.org/jdk/pull/12493

From alanb at openjdk.org  Fri Feb 24 07:00:08 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 24 Feb 2023 07:00:08 GMT
Subject: RFR: 8302806: (fs) Remove
 com.sun.nio.file.SensitivityWatchEventModifier [v5]
In-Reply-To: <W_HuvqiPNipq0E96Q8HUay1iwMrrF2STlKNDYd-D8z0=.0cb78060-fbd1-4070-9397-581c1ba8e5b9@github.com>
References: <FZn8ZF4sN5mtUO8MWPaC0N8nWFwTLkBvcqQeOPwVYeE=.a6e12227-dfa9-4817-adbb-bece72445860@github.com>
 <W_HuvqiPNipq0E96Q8HUay1iwMrrF2STlKNDYd-D8z0=.0cb78060-fbd1-4070-9397-581c1ba8e5b9@github.com>
Message-ID: <9fbd1kEtxdMTCyiOPEYeKUxz2qVQbcd8zIJsjKEi82M=.c43649d6-4e38-4d16-b7d3-58377264aafb@github.com>

On Thu, 23 Feb 2023 21:16:41 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> This enum is not used in the JDK and did not appear in external source code searches.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8302806: Remove modifier loops

src/java.base/linux/classes/sun/nio/fs/LinuxWatchService.java line 229:

> 227: 
> 228:             // no modifiers supported at this time
> 229:             if (modifiers != null) {

Suggestion:

            if (modifiers.length > 0) {

Same thing in PollingWatchService.

-------------

PR: https://git.openjdk.org/jdk/pull/12626

From rehn at openjdk.org  Fri Feb 24 07:15:05 2023
From: rehn at openjdk.org (Robbin Ehn)
Date: Fri, 24 Feb 2023 07:15:05 GMT
Subject: RFR: 8303040: linux PPC64le: Implementation of Foreign Function &
 Memory API (Preview) [v3]
In-Reply-To: <HT8kQfjS98dYHeAMcNL5latokRiw3YK8npxl5yCD4hw=.28b19bac-cbfa-4461-a1db-c899c55b7485@github.com>
References: <Yuxy6FrsDAN79ya8w8UIkvytGr25zGllDPtPJ1QbGwc=.182664b2-6d8c-497e-a4ae-95e0ad007cf9@github.com>
 <8b3vVrV22RuhdRoRYacXV0ZeghFGgKkC8S_z-iMrzAQ=.dd84b743-8b51-4281-8f5f-f9eff6207bc7@github.com>
 <HT8kQfjS98dYHeAMcNL5latokRiw3YK8npxl5yCD4hw=.28b19bac-cbfa-4461-a1db-c899c55b7485@github.com>
Message-ID: <WwyiUptwEdGKfkg8jw0GV_AKXFkyiEMWkQyXg7cTbSo=.b0b4d7d9-9794-4e34-acea-5633bdfad511@github.com>

On Fri, 24 Feb 2023 04:03:53 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

> * Since the membar on the return path was mentioned: I think it would be good to enable UseSystemMemoryBarrier by default on operating systems which support it. Maybe we should discuss this with @robehn.

Changing the default is fine by me.
There is, AFAIK, one case that needs to read the thread state a lot, thus emitting sysmembars alot, JFR with very high sampling rate. Other than that there are no issues that I know about.
Maybe it would be good to test at what sampling interval we notice a change?
Also I think it's not best match to have the flag experimental when we are in some sense using it. Maybe diagnostic?

-------------

PR: https://git.openjdk.org/jdk/pull/12708

From jvernee at openjdk.org  Fri Feb 24 07:21:08 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Fri, 24 Feb 2023 07:21:08 GMT
Subject: RFR: 8303040: linux PPC64le: Implementation of Foreign Function &
 Memory API (Preview) [v3]
In-Reply-To: <HT8kQfjS98dYHeAMcNL5latokRiw3YK8npxl5yCD4hw=.28b19bac-cbfa-4461-a1db-c899c55b7485@github.com>
References: <Yuxy6FrsDAN79ya8w8UIkvytGr25zGllDPtPJ1QbGwc=.182664b2-6d8c-497e-a4ae-95e0ad007cf9@github.com>
 <8b3vVrV22RuhdRoRYacXV0ZeghFGgKkC8S_z-iMrzAQ=.dd84b743-8b51-4281-8f5f-f9eff6207bc7@github.com>
 <HT8kQfjS98dYHeAMcNL5latokRiw3YK8npxl5yCD4hw=.28b19bac-cbfa-4461-a1db-c899c55b7485@github.com>
Message-ID: <wBVqRDFM23KM8fjjPtUFNdW56FYsSpvOAVvHmpdjbzo=.7c429606-ac19-4f36-8e25-459534983924@github.com>

On Fri, 24 Feb 2023 04:03:53 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>     * Uploaded my simple reproducer to [JDK-8303017](https://bugs.openjdk.org/browse/JDK-8303017)

Thanks!

>     * Using oversized load / stores is problematic. Don't forget that OpenJDK still supports Big Endian platforms (AIX, s390x).

You're right. I realized that it's also problematic for heap segments, for which we can't do oversized accesses. I have another solution that splits up the loads/stores into power-of-two sized chunks: https://github.com/openjdk/panama-foreign/compare/foreign-memaccess+abi...JornVernee:panama-foreign:OOB That patch is just a POC at this point though. Also, I don't think it works for BE at the moment (need to flip the offset for BE, I think. Just like we do in Unsafe).

>     * The result of `NativeCallingConvention::calling_convention` is interpreted as size, but it returns the max offset. That's off by one slot. Should I file a bug for that? (PPC64 is not affected because it doesn't use the result.)

I'm not sure there's an issue there. Note that the 'max offset' is computed as `reg.offset() + reg.stack_size()`, so that should get us the size we need to allocate for the stack arguments. (e.g. 2 ints being passed at offset 0 and 4, would make max offset 4 + 4 = 8, which gives the size needed for the 2 ints). Computing the max offset instead of just summing the sizes of the stack arguments is needed since stack arguments can be sparsely placed in some cases on Mac/AArch64.

>     * Since the membar on the return path was mentioned: I think it would be good to enable UseSystemMemoryBarrier by default on operating systems which support it. Maybe we should discuss this with @robehn.

~I don't think we've done that much testing with UseSystemMemoryBarrier since it was added~. I'm a bit nervous about turning it on by default since it's currently also used for JNI. Let's see what Robbin thinks.

-------------

PR: https://git.openjdk.org/jdk/pull/12708

From alanb at openjdk.org  Fri Feb 24 07:31:08 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 24 Feb 2023 07:31:08 GMT
Subject: RFR: 8302871: Speed up StringLatin1.regionMatchesCI [v12]
In-Reply-To: <J7Di2ZhG37ghp5kb0_MU7O5FeB41l8k3rXT20sPFQRA=.cc7c2a2b-9427-4553-807f-84e20ab8e304@github.com>
References: <dnsiX3nRffjGjZXJG7lMAZj2FktEl2Wc1XfFthQ4iJs=.8c41438a-80a4-468f-ae0b-7322c9d6d952@github.com>
 <B0NCYVR0qvImkfrktwxoisWCPVmcfJjHRSwes8bz5tY=.e24cca5b-207e-4ced-825d-af01d17b9116@github.com>
 <J7Di2ZhG37ghp5kb0_MU7O5FeB41l8k3rXT20sPFQRA=.cc7c2a2b-9427-4553-807f-84e20ab8e304@github.com>
Message-ID: <xa9oE9ty5wrXh0xuHXPxkXZgrvw8PXuoq3eG0PJIYmQ=.27ec1d6e-608c-41a3-ae84-d5f0458d572d@github.com>

On Wed, 22 Feb 2023 18:44:57 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

> I'll let this linger a bit before integrating in case Alan has comments after the latest updates.

I plan to look at it, been busy with other things.

-------------

PR: https://git.openjdk.org/jdk/pull/12632

From duke at openjdk.org  Fri Feb 24 07:40:10 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Fri, 24 Feb 2023 07:40:10 GMT
Subject: RFR: 8302871: Speed up StringLatin1.regionMatchesCI [v14]
In-Reply-To: <F0qyphqbltdnyRwcfKg96Vh2jkRtliefQlGBRuM7Zcc=.976fa82c-6ad8-4048-b0cf-b03683fa4ecd@github.com>
References: <dnsiX3nRffjGjZXJG7lMAZj2FktEl2Wc1XfFthQ4iJs=.8c41438a-80a4-468f-ae0b-7322c9d6d952@github.com>
 <F0qyphqbltdnyRwcfKg96Vh2jkRtliefQlGBRuM7Zcc=.976fa82c-6ad8-4048-b0cf-b03683fa4ecd@github.com>
Message-ID: <6xeTkBjTBcOX__GsKL0hpEnJfSGXRP99acR9Txay9c4=.4206ac5a-f7fc-4366-94db-c143d2547dbe@github.com>

On Wed, 22 Feb 2023 20:01:52 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

>> This PR suggests we can speed up `StringLatin1.regionMatchesCI` by applying 'the oldest ASCII trick in the book'.
>> 
>> The new static method `CharacterDataLatin1.equalsIgnoreCase` compares two latin1 bytes for equality ignoring case. `StringLatin1.regionMatchesCI` is updated to use `equalsIgnoreCase`
>> 
>> To verify the correctness of `equalsIgnoreCase`, a new test is added  to `EqualsIgnoreCase` with an exhaustive verification that all 256x256 latin1 code point pairs have an `equalsIgnoreCase` consistent with Character.toUpperCase, Character.toLowerCase.
>> 
>> Performance is tested for matching and mismatching cases of code point pairs picked from the ASCII letter, ASCII number and latin1 letter ranges. Results in the first comment below.
>
> Eirik Bjorsnos 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:
> 
>  - Merge branch 'master' into regionmatches-latin1-speedup
>  - Merge branch 'master' into regionmatches-latin1-speedup
>  - Make the loop variables chars to avoid casting
>  - Use improved case-twiddling comment as suggested by Martin
>  - Replace 'oldest ASCII trick in the book' use in toUpperCase, toLowerCase with "by removing (setting) a single bit"
>  - Align local variable naming in toLowerCase, toUpperCase with equalsIgnoreCase by using 'lower' and 'upper'
>  - Rename unconventionally named local variable 'U' to 'upper'
>  - Merge remote-tracking branch 'origin/master' into regionmatches-latin1-speedup
>  - Add whitespace between methods
>  - Merge branch 'master' into regionmatches-latin1-speedup
>  - ... and 11 more: https://git.openjdk.org/jdk/compare/bd4b71f6...597b346a

Thanks, Alan ? Sponsors, hold your horses! (Not sure how to 'undo' the integrate command)

-------------

PR: https://git.openjdk.org/jdk/pull/12632

From rehn at openjdk.org  Fri Feb 24 07:43:05 2023
From: rehn at openjdk.org (Robbin Ehn)
Date: Fri, 24 Feb 2023 07:43:05 GMT
Subject: RFR: 8303040: linux PPC64le: Implementation of Foreign Function &
 Memory API (Preview) [v3]
In-Reply-To: <wBVqRDFM23KM8fjjPtUFNdW56FYsSpvOAVvHmpdjbzo=.7c429606-ac19-4f36-8e25-459534983924@github.com>
References: <Yuxy6FrsDAN79ya8w8UIkvytGr25zGllDPtPJ1QbGwc=.182664b2-6d8c-497e-a4ae-95e0ad007cf9@github.com>
 <8b3vVrV22RuhdRoRYacXV0ZeghFGgKkC8S_z-iMrzAQ=.dd84b743-8b51-4281-8f5f-f9eff6207bc7@github.com>
 <HT8kQfjS98dYHeAMcNL5latokRiw3YK8npxl5yCD4hw=.28b19bac-cbfa-4461-a1db-c899c55b7485@github.com>
 <wBVqRDFM23KM8fjjPtUFNdW56FYsSpvOAVvHmpdjbzo=.7c429606-ac19-4f36-8e25-459534983924@github.com>
Message-ID: <FPIzIHMG6nWOehx_lww3PUoJ4NistRZBE4sHLeQBBro=.903212c7-3334-4aea-8649-ae3f2df9e44f@github.com>

On Fri, 24 Feb 2023 07:17:30 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

> ~I don't think we've done that much testing with UseSystemMemoryBarrier since it was added~. I'm a bit nervous about turning it on by default since it's currently also used for JNI. Let's see what Robbin thinks.

For reliability:
On every Oracle tier 5 we run these test two groups:
vmTestbase_nsk_jvmti, open/test/hotspot/jtreg/:hotspot_runtime
For each of  linux_x64_debug,  windows_x64, linux_aarch64_debug with sysmembar on.
I picked jvmti as this is very heavy on 'JNI'. No issues reported that I know about.
We also have this test:
SystemMembarHandshakeTransitionTest.java which only JNI transisition with this options.

For performance, the heavy lifting is on reader of thread state and the only case I have identified is JFR.

I suggest changing the default now, if there is issues we have time to revert it back before RDP1.

-------------

PR: https://git.openjdk.org/jdk/pull/12708

From alanb at openjdk.org  Fri Feb 24 07:56:10 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 24 Feb 2023 07:56:10 GMT
Subject: RFR: 8301119: Support for GB18030-2022 [v3]
In-Reply-To: <DbcSeT1d1ulLxFGuScNUYOimyD_bbHn9miPe9TvlSH8=.a10fd674-22b4-4d6b-ac97-3772babbcd3d@github.com>
References: <FXBchbCnbNloQO7Nlh9Ijue_c_YugGk-UC7_-ZAjY2o=.7e1ca01f-8cee-40bb-bb06-6e5670abe661@github.com>
 <DbcSeT1d1ulLxFGuScNUYOimyD_bbHn9miPe9TvlSH8=.a10fd674-22b4-4d6b-ac97-3772babbcd3d@github.com>
Message-ID: <sZ6e3IQf74n8JeZ3jS2RCtNXc3rZVNEhssWPZBF3Syc=.689d0581-f8b8-4d4a-8cbc-bc47868801ba@github.com>

On Thu, 23 Feb 2023 19:34:44 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Upgrading the GB18030 charset in the JDK to the latest 2022 standard. Since this is not a compatible upgrade to the existing mapping, a new system property `jdk.charset.GB18030` is introduced. If it is set to "2000", the mapping falls back to the existing mapping based on the 2000 standard, otherwise, it defaults to 2022 mapping. Refer to the corresponding CSR for more detail.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Moved the 2000 flag into GB18030

Latest version looks good to me, avoids needing stable field or holder class.

-------------

Marked as reviewed by alanb (Reviewer).

PR: https://git.openjdk.org/jdk/pull/12518

From Alan.Bateman at oracle.com  Fri Feb 24 08:21:50 2023
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Fri, 24 Feb 2023 08:21:50 +0000
Subject: RFD: Invalid CRC in ZipFile, ZipFileSystem
In-Reply-To: <9B315E4F-C51D-47F3-B7CC-EE750FEC1275@oracle.com>
References: <CA+pBWhvuAJ+x3cdLyocs6RC5UTAV7CBiEv2XN4Ltit_XNW6o7w@mail.gmail.com>
 <9B315E4F-C51D-47F3-B7CC-EE750FEC1275@oracle.com>
Message-ID: <97ddd4ab-e65b-3c15-08ad-4fa8917859eb@oracle.com>

On 23/02/2023 16:32, Lance Andersen wrote:
> HI Eirik
>
>> On Feb 23, 2023, at 7:43 AM, Eirik Bj?rsn?s <eirbjo at gmail.com> wrote:
>>
>> Hi,
>>
>> While writing various ZIP related tests, I noticed a discrepancy in 
>> the treatment of invalid CRC values:
>>
>> While ZipInputStream rejects invalid CRC values when consuming 
>> streams, ZipFile and ZipFileSystem do not.
>>
>> While this is inconsistent, it is perhaps not a bug we want to fix?
>
> I believe it is intentional. ?Alan, Martin B, do you recall the history?

I think Dave Bristor or Martin looked at this at one point so you might 
have to search JBS for issues where they commented on this topic.

As a general point, the ZIP format can have redundant metadata and there 
can be cases where the CRC-32 isn't available when writing a LOC header. 
At the same time, the APIs work differently in that ZipFile opens a ZIP 
file so it has access to the CEN whereas ZipInputStream is working on a 
stream of ZIP entries and does not read the CEN.? So some 
inconsistencies in the handling is not too surprising.

-Alan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20230224/23b3f2b8/attachment-0001.htm>

From itakiguchi at openjdk.org  Fri Feb 24 08:38:07 2023
From: itakiguchi at openjdk.org (Ichiroh Takiguchi)
Date: Fri, 24 Feb 2023 08:38:07 GMT
Subject: RFR: 8301119: Support for GB18030-2022 [v3]
In-Reply-To: <DbcSeT1d1ulLxFGuScNUYOimyD_bbHn9miPe9TvlSH8=.a10fd674-22b4-4d6b-ac97-3772babbcd3d@github.com>
References: <FXBchbCnbNloQO7Nlh9Ijue_c_YugGk-UC7_-ZAjY2o=.7e1ca01f-8cee-40bb-bb06-6e5670abe661@github.com>
 <DbcSeT1d1ulLxFGuScNUYOimyD_bbHn9miPe9TvlSH8=.a10fd674-22b4-4d6b-ac97-3772babbcd3d@github.com>
Message-ID: <U-4zjhKODj0JRTHSx_FChBEHLABanbxFBr9nmvg8Vks=.f25ff406-6bcc-4376-ac89-609ae5affd32@github.com>

On Thu, 23 Feb 2023 19:34:44 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Upgrading the GB18030 charset in the JDK to the latest 2022 standard. Since this is not a compatible upgrade to the existing mapping, a new system property `jdk.charset.GB18030` is introduced. If it is set to "2000", the mapping falls back to the existing mapping based on the 2000 standard, otherwise, it defaults to 2022 mapping. Refer to the corresponding CSR for more detail.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Moved the 2000 flag into GB18030

Hello @naotoj .
Sorry for bothering you.

I have following question:
- Why GB18030.java.template is in src/jdk.charsets/share/classes/sun/nio/cs/ext/ directory even if the generated code is always stored into sun/nio/cs ?
I think the file should be moved to src/java.base/share/classes/sun/nio/cs and the file name should be GB18030.java instead of GB18030.java.template.
Is there specific reason ?

-------------

PR: https://git.openjdk.org/jdk/pull/12518

From eirbjo at gmail.com  Fri Feb 24 08:43:38 2023
From: eirbjo at gmail.com (=?UTF-8?B?RWlyaWsgQmrDuHJzbsO4cw==?=)
Date: Fri, 24 Feb 2023 09:43:38 +0100
Subject: RFD: Invalid CRC in ZipFile, ZipFileSystem
In-Reply-To: <97ddd4ab-e65b-3c15-08ad-4fa8917859eb@oracle.com>
References: <CA+pBWhvuAJ+x3cdLyocs6RC5UTAV7CBiEv2XN4Ltit_XNW6o7w@mail.gmail.com>
 <9B315E4F-C51D-47F3-B7CC-EE750FEC1275@oracle.com>
 <97ddd4ab-e65b-3c15-08ad-4fa8917859eb@oracle.com>
Message-ID: <CA+pBWhtzAB+D2Rnk+en7X5u8-+yaYjPQyvqsXUna8nNo=4uAEA@mail.gmail.com>

On Fri, Feb 24, 2023 at 9:22 AM Alan Bateman <Alan.Bateman at oracle.com>
wrote:

> As a general point, the ZIP format can have redundant metadata and there
> can be cases where the CRC-32 isn't available when writing a LOC header.
>

ZipInputStream throws exceptions in both of these cases. If the general
purpose bit flag 3 is set, then CRC is set to zero in the LOC, and the
actual CRC is put in the data descriptor immediately following the
compressed data. With this format, an exception is thrown in
ZipInputStream.readEnd:

https://github.com/openjdk/jdk/blob/8f7c4969c28c58ae4b9adeed822707b28be16dd0/src/java.base/share/classes/java/util/zip/ZipInputStream.java#L624-L626

If the CRC-32 values is in the LOC, the exception is thrown when the read
reaches the end of the data, in ZipInputStream.read:

https://github.com/openjdk/jdk/blob/8f7c4969c28c58ae4b9adeed822707b28be16dd0/src/java.base/share/classes/java/util/zip/ZipInputStream.java#L624-L626

(The test I linked to covers both of these two cases)

At the same time, the APIs work differently in that ZipFile opens a ZIP
> file so it has access to the CEN whereas ZipInputStream is working on a
> stream of ZIP entries and does not read the CEN.  So some inconsistencies
> in the handling is not too surprising.
>

Indeed, but I found it a bit amusing that ZipFile (and ZipFileSystem),
which both see the "full picture", are actually the ones to not enforce the
CRC. It does not make complete sense to me from a purely technical point of
view.

Perhaps the CRC in the CEN is less trustworthy across implementations than
the one found in the LOC/Data Descriptor..

Cheers,
Eirik.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20230224/9248b35a/attachment.htm>

From eirbjo at gmail.com  Fri Feb 24 09:27:43 2023
From: eirbjo at gmail.com (=?UTF-8?B?RWlyaWsgQmrDuHJzbsO4cw==?=)
Date: Fri, 24 Feb 2023 10:27:43 +0100
Subject: RFD: Invalid CRC in ZipFile, ZipFileSystem
In-Reply-To: <CA+pBWhtzAB+D2Rnk+en7X5u8-+yaYjPQyvqsXUna8nNo=4uAEA@mail.gmail.com>
References: <CA+pBWhvuAJ+x3cdLyocs6RC5UTAV7CBiEv2XN4Ltit_XNW6o7w@mail.gmail.com>
 <9B315E4F-C51D-47F3-B7CC-EE750FEC1275@oracle.com>
 <97ddd4ab-e65b-3c15-08ad-4fa8917859eb@oracle.com>
 <CA+pBWhtzAB+D2Rnk+en7X5u8-+yaYjPQyvqsXUna8nNo=4uAEA@mail.gmail.com>
Message-ID: <CA+pBWhvE=21b4W2h8jHdT7dQLDa+FWdRaGys=qvCr99uHXPbbQ@mail.gmail.com>

>
> Indeed, but I found it a bit amusing that ZipFile (and ZipFileSystem),
> which both see the "full picture", are actually the ones to not enforce the
> CRC.
>

With the current state of affairs, it is conceivable that a single-event
upset could cause an IF_ICMPNE byte code to be flipped into an IF_ICMPLT
without this being detected by ZipFile or the byte code verifier. Similarly
a constant could be changed giving a candidate in an election 4096 extra
votes, which is what seems to have happened in Belgium in 2003:

https://en.wikipedia.org/wiki/Electronic_voting_in_Belgium

Eirik :-)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20230224/8fbac583/attachment.htm>

From mdoerr at openjdk.org  Fri Feb 24 10:16:08 2023
From: mdoerr at openjdk.org (Martin Doerr)
Date: Fri, 24 Feb 2023 10:16:08 GMT
Subject: RFR: 8303040: linux PPC64le: Implementation of Foreign Function &
 Memory API (Preview) [v3]
In-Reply-To: <FPIzIHMG6nWOehx_lww3PUoJ4NistRZBE4sHLeQBBro=.903212c7-3334-4aea-8649-ae3f2df9e44f@github.com>
References: <Yuxy6FrsDAN79ya8w8UIkvytGr25zGllDPtPJ1QbGwc=.182664b2-6d8c-497e-a4ae-95e0ad007cf9@github.com>
 <8b3vVrV22RuhdRoRYacXV0ZeghFGgKkC8S_z-iMrzAQ=.dd84b743-8b51-4281-8f5f-f9eff6207bc7@github.com>
 <HT8kQfjS98dYHeAMcNL5latokRiw3YK8npxl5yCD4hw=.28b19bac-cbfa-4461-a1db-c899c55b7485@github.com>
 <wBVqRDFM23KM8fjjPtUFNdW56FYsSpvOAVvHmpdjbzo=.7c429606-ac19-4f36-8e25-459534983924@github.com>
 <FPIzIHMG6nWOehx_lww3PUoJ4NistRZBE4sHLeQBBro=.903212c7-3334-4aea-8649-ae3f2df9e44f@github.com>
Message-ID: <EpZEmuoVk-reCoDagN9Xj4j_iHTUN6qlntAdT-w7TXs=.62ae4e09-459a-4ef0-9c80-53909da8f504@github.com>

On Fri, 24 Feb 2023 07:39:15 GMT, Robbin Ehn <rehn at openjdk.org> wrote:

> > ~I don't think we've done that much testing with UseSystemMemoryBarrier since it was added~. I'm a bit nervous about turning it on by default since it's currently also used for JNI. Let's see what Robbin thinks.
> 
> For reliability: On every Oracle tier 5 we run these test two groups: vmTestbase_nsk_jvmti, open/test/hotspot/jtreg/:hotspot_runtime For each of linux_x64_debug, windows_x64, linux_aarch64_debug with sysmembar on. I picked jvmti as this is very heavy on 'JNI'. No issues reported that I know about. We also have this test: SystemMembarHandshakeTransitionTest.java which only JNI transisition with this options.
> 
> For performance, the heavy lifting is on reader of thread state and the only case I have identified is JFR.
> 
> I suggest changing the default now, if there is issues we have time to revert it back before RDP1.

Thanks for your prompt reply! I agree, this is a good time to enable it. Do you want to do it? We'll support it and run tests on our machines and platforms. I think JFR users who want a very high sampling rate can switch it off. Making the flag diagnostic is fine with me, but that shouldn't get discussed in this PR :-)

-------------

PR: https://git.openjdk.org/jdk/pull/12708

From yyang at openjdk.org  Fri Feb 24 10:19:49 2023
From: yyang at openjdk.org (Yi Yang)
Date: Fri, 24 Feb 2023 10:19:49 GMT
Subject: RFR: 8143900: OptimizeStringConcat has an opaque dependency on
 Integer.sizeTable field [v2]
In-Reply-To: <wVJP9KUVBORqE2Y2rPoPzePyKqbUTiE6fKiS1iOw9j4=.91a2c4c5-6da7-461e-8d65-d6e41bb5f4ff@github.com>
References: <wVJP9KUVBORqE2Y2rPoPzePyKqbUTiE6fKiS1iOw9j4=.91a2c4c5-6da7-461e-8d65-d6e41bb5f4ff@github.com>
Message-ID: <upouJcFH3Uw0SXK1OZHRgx5X_fQy9ZI2MbdkjrtjsKs=.c382dad7-a3a7-48f1-a493-db4a2ea80849@github.com>

> Hi, can I have a review for this patch? I noticed a strange field Integer.sizeTable which is used by PhaseStringOpts, after digging into the history, I think it could be replaced by an in-place array allocation and initialization. Before it, we are fetching from Integer.sizeTable and get num of digit in integer by iterating size table, now we fetch from in-place sizeTable and get size from that. The changed IR looks like this:
> 
> ![image](https://user-images.githubusercontent.com/5010047/220239446-7b8b8381-b300-4f2c-a24a-aa19ec9e2f88.png)
> 
> Thanks.

Yi Yang has updated the pull request incrementally with three additional commits since the last revision:

 - whitespace
 - mirror or Integer.stringSize
 - mirror or Integer.stringSize

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12680/files
  - new: https://git.openjdk.org/jdk/pull/12680/files/f1794873..816f05a1

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12680&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12680&range=00-01

  Stats: 193 lines in 1 file changed: 67 ins; 114 del; 12 mod
  Patch: https://git.openjdk.org/jdk/pull/12680.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12680/head:pull/12680

PR: https://git.openjdk.org/jdk/pull/12680

From yyang at openjdk.org  Fri Feb 24 10:19:52 2023
From: yyang at openjdk.org (Yi Yang)
Date: Fri, 24 Feb 2023 10:19:52 GMT
Subject: RFR: 8143900: OptimizeStringConcat has an opaque dependency on
 Integer.sizeTable field
In-Reply-To: <wVJP9KUVBORqE2Y2rPoPzePyKqbUTiE6fKiS1iOw9j4=.91a2c4c5-6da7-461e-8d65-d6e41bb5f4ff@github.com>
References: <wVJP9KUVBORqE2Y2rPoPzePyKqbUTiE6fKiS1iOw9j4=.91a2c4c5-6da7-461e-8d65-d6e41bb5f4ff@github.com>
Message-ID: <HFYUWBBwEZ7Eid9O_RI_wk1a1C8NqjCoQVlmJZyY7GY=.526d6425-0c2d-4614-8a88-0ac9b2e28fe8@github.com>

On Tue, 21 Feb 2023 02:29:44 GMT, Yi Yang <yyang at openjdk.org> wrote:

> Hi, can I have a review for this patch? I noticed a strange field Integer.sizeTable which is used by PhaseStringOpts, after digging into the history, I think it could be replaced by an in-place array allocation and initialization. Before it, we are fetching from Integer.sizeTable and get num of digit in integer by iterating size table, now we fetch from in-place sizeTable and get size from that. The changed IR looks like this:
> 
> ![image](https://user-images.githubusercontent.com/5010047/220239446-7b8b8381-b300-4f2c-a24a-aa19ec9e2f88.png)
> 
> Thanks.

I updated this patch to use the algorithm identical to Integer.stringSize.

-------------

PR: https://git.openjdk.org/jdk/pull/12680

From rehn at openjdk.org  Fri Feb 24 10:45:05 2023
From: rehn at openjdk.org (Robbin Ehn)
Date: Fri, 24 Feb 2023 10:45:05 GMT
Subject: RFR: 8303040: linux PPC64le: Implementation of Foreign Function &
 Memory API (Preview) [v3]
In-Reply-To: <EpZEmuoVk-reCoDagN9Xj4j_iHTUN6qlntAdT-w7TXs=.62ae4e09-459a-4ef0-9c80-53909da8f504@github.com>
References: <Yuxy6FrsDAN79ya8w8UIkvytGr25zGllDPtPJ1QbGwc=.182664b2-6d8c-497e-a4ae-95e0ad007cf9@github.com>
 <8b3vVrV22RuhdRoRYacXV0ZeghFGgKkC8S_z-iMrzAQ=.dd84b743-8b51-4281-8f5f-f9eff6207bc7@github.com>
 <HT8kQfjS98dYHeAMcNL5latokRiw3YK8npxl5yCD4hw=.28b19bac-cbfa-4461-a1db-c899c55b7485@github.com>
 <wBVqRDFM23KM8fjjPtUFNdW56FYsSpvOAVvHmpdjbzo=.7c429606-ac19-4f36-8e25-459534983924@github.com>
 <FPIzIHMG6nWOehx_lww3PUoJ4NistRZBE4sHLeQBBro=.903212c7-3334-4aea-8649-ae3f2df9e44f@github.com>
 <EpZEmuoVk-reCoDagN9Xj4j_iHTUN6qlntAdT-w7TXs=.62ae4e09-459a-4ef0-9c80-53909da8f504@github.com>
Message-ID: <1PZeZa46N1rA3R0IZs-4TIKP5d1gJYMDlWlfv4ApPV8=.6c5fb2fd-2b75-4dc8-979f-87c33bbe6d9d@github.com>

On Fri, 24 Feb 2023 10:12:52 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

> > > ~I don't think we've done that much testing with UseSystemMemoryBarrier since it was added~. I'm a bit nervous about turning it on by default since it's currently also used for JNI. Let's see what Robbin thinks.
> > 
> > 
> > For reliability: On every Oracle tier 5 we run these test two groups: vmTestbase_nsk_jvmti, open/test/hotspot/jtreg/:hotspot_runtime For each of linux_x64_debug, windows_x64, linux_aarch64_debug with sysmembar on. I picked jvmti as this is very heavy on 'JNI'. No issues reported that I know about. We also have this test: SystemMembarHandshakeTransitionTest.java which only JNI transisition with this options.
> > For performance, the heavy lifting is on reader of thread state and the only case I have identified is JFR.
> > I suggest changing the default now, if there is issues we have time to revert it back before RDP1.
> 
> Thanks for your prompt reply! I agree, this is a good time to enable it. Do you want to do it? We'll support it and run tests on our machines and platforms. I think JFR users who want a very high sampling rate can switch it off. Making the flag diagnostic is fine with me, but that shouldn't get discussed in this PR :-)

I will be skiing next week, if you want it now, I suggest you do it, otherwise I can when I'm back.

-------------

PR: https://git.openjdk.org/jdk/pull/12708

From coffeys at openjdk.org  Fri Feb 24 11:01:08 2023
From: coffeys at openjdk.org (Sean Coffey)
Date: Fri, 24 Feb 2023 11:01:08 GMT
Subject: RFR: 8301119: Support for GB18030-2022 [v3]
In-Reply-To: <DbcSeT1d1ulLxFGuScNUYOimyD_bbHn9miPe9TvlSH8=.a10fd674-22b4-4d6b-ac97-3772babbcd3d@github.com>
References: <FXBchbCnbNloQO7Nlh9Ijue_c_YugGk-UC7_-ZAjY2o=.7e1ca01f-8cee-40bb-bb06-6e5670abe661@github.com>
 <DbcSeT1d1ulLxFGuScNUYOimyD_bbHn9miPe9TvlSH8=.a10fd674-22b4-4d6b-ac97-3772babbcd3d@github.com>
Message-ID: <gheAf1iB5AFGkfIwBYGfJdW6VvlIc-OGjuCdRQAoyEw=.7f6710eb-8e4a-4376-816a-f16cd1cc8cef@github.com>

On Thu, 23 Feb 2023 19:34:44 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Upgrading the GB18030 charset in the JDK to the latest 2022 standard. Since this is not a compatible upgrade to the existing mapping, a new system property `jdk.charset.GB18030` is introduced. If it is set to "2000", the mapping falls back to the existing mapping based on the 2000 standard, otherwise, it defaults to 2022 mapping. Refer to the corresponding CSR for more detail.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Moved the 2000 flag into GB18030

Marked as reviewed by coffeys (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/12518

From vromero at openjdk.org  Fri Feb 24 11:23:09 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 24 Feb 2023 11:23:09 GMT
Subject: RFR: 8026369: javac potentially ambiguous overload warning needs
 an improved scheme [v2]
In-Reply-To: <NlqhxTe-Li08DSIjyYVn5HI9uIAvIHZE4IG0x8tQTQw=.0ae9928e-7814-4356-bf75-11bc4eefc6be@github.com>
References: <IMxp3iCK--jYJ5Ia04i6QPYfnCHQobVcsmlI5aJXdqc=.892abcb8-7f2a-4fe9-aea2-1b1d41098a6d@github.com>
 <NlqhxTe-Li08DSIjyYVn5HI9uIAvIHZE4IG0x8tQTQw=.0ae9928e-7814-4356-bf75-11bc4eefc6be@github.com>
Message-ID: <Q5L__4hI_EKmVkQZ6GMyp77cxinOIap14vzgwBs1kF4=.374c3f34-bc0a-4bee-a548-6f454a78314e@github.com>

On Tue, 21 Feb 2023 01:42:41 GMT, Archie L. Cobbs <duke at openjdk.org> wrote:

>> This bug relates to the "potentially ambiguous overload" warning which is enabled by `-Xlint:overloads`.
>> 
>> The warning detects certain ambiguities that can cause problems for lambdas. For example, consider the interface `Spliterator.OfInt`, which declares these two methods:
>> 
>> void forEachRemaining(Consumer<? super Integer> action);
>> void forEachRemaining(IntConsumer action);
>> 
>> Both methods have the same name, same number of parameters, and take a lambda with the same "shape" in the same argument position. This causes an ambiguity in any code that wants to do this:
>> 
>>     spliterator.forEachRemaining(x -> { ... });
>> 
>> That code won't compile; instead, you'll get this error:
>> 
>> Ambiguity.java:4: error: reference to forEachRemaining is ambiguous
>>         spliterator.forEachRemaining(x -> { });
>>                    ^
>>   both method forEachRemaining(IntConsumer) in OfInt and method forEachRemaining(Consumer<? super Integer>) in OfInt match
>> 
>> 
>> The problem reported by the bug is that the warning fails to detect ambiguities which are created purely by inheritance, for example:
>> 
>> interface ConsumerOfInteger {
>>     void foo(Consumer<Integer> c);
>> }
>> 
>> interface IntegerConsumer {
>>     void foo(IntConsumer c);
>> }
>> 
>> // We should get a warning here...
>> interface Test extends ConsumerOfInteger, IntegerConsumer {
>> }
>> 
>> 
>> The cause of the bug is that ambiguities are detected on a per-method basis, by checking whether a method is part of an ambiguity pair when we visit that method. So if the methods in an ambiguity pair are inherited from two distinct supertypes, we'll miss the ambiguity.
>> 
>> To fix the problem, we need to look for ambiguities on a per-class level, checking all pairs of methods. However, it's not that simple - we only want to "blame" a class when that class itself, and not some supertype, is responsible for creating the ambiguity. For example, any interface extending `Spliterator.OfInt` will automatically inherit the two ambiguities mentioned above, but these are not the interface's fault so to speak so no warning should be generated. Making things more complicated is the fact that methods can be overridden and declared in generic classes so they only conflict in some subtypes, etc.
>> 
>> So we generate the warning when there are two methods m1 and m2 in a class C such that:
>> 
>> * m1 and m2 consitiute a "potentially ambiguous overload" (using the same definition as before)
>> * There is no direct supertype T of C such that m1 and m2, or some methods they override, both exist in T and constitute a "potentially ambiguous overload" as members of T
>> * We haven't already generated a warning for either m1 or m2 in class C
>> 
>> If either method is declared in C, we locate the warning there, but when both methods are inherited, there's no method declaration to point at so the warning is instead located at the class declaration.
>> 
>> I noticed a couple of other minor bugs; these are also being fixed here:
>> 
>> (1) For inherited methods, the method signatures were being reported as they are declared, rather than in the context of the class being visited. As a result, when a methods is inherited from a generic supertype, the ambiguity is less clear. Here's an example:
>> 
>> interface Upper<T> {
>>     void foo(T c);
>> }
>> 
>> interface Lower extends Upper<IntConsumer> {
>>     void foo(Consumer<Integer> c);
>> }
>> 
>> Currently, the error is reported as:
>> 
>> warning: [overloads] foo(Consumer<Integer>) in Lower is potentially ambiguous with foo(T) in Upper
>> 
>> Reporting the method signatures in the context of the class being visited makes the ambiguity clearer:
>> 
>> warning: [overloads] foo(Consumer<Integer>) in Lower is potentially ambiguous with foo(IntConsumer) in Upper
>> 
>> 
>> (2) When a method is identified as part of an ambiguous pair, we were setting a `POTENTIALLY_AMBIGUOUS` flag on it. This caused it to be forever excluded from future warnings. For methods that are declared in the class we're visiting, this makes sense, but it doesn't make sense for inherited methods, because it disqualifies them from participating in the analysis of any other class that also inherits them.
>> 
>> As a result, for a class like the one below, the compiler was only generating one warning instead of three:
>> 
>> public interface SuperIface {
>>     void foo(Consumer<Integer> c);
>> }
>> 
>> public interface I1 extends SuperIface { 
>>     void foo(IntConsumer c);        // warning was generated here
>> }   
>> 
>> public interface I2 extends SuperIface { 
>>     void foo(IntConsumer c);        // no warning was generated here
>> }   
>> 
>> public interface I3 extends SuperIface { 
>>     void foo(IntConsumer c);        // no warning was generated here
>> }   
>> 
>> 
>> With this patch the `POTENTIALLY_AMBIGUOUS` flag is no longer needed. I wasn't sure whether to renumber all the subsequent flags, or just leave an empty placeholder, so I chose the latter.
>> 
>> Finally, this fix uncovers new warnings in `java.base` and `java.desktop`, so these are now suppressed in the patch.
>
> Archie L. Cobbs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove @SuppressWarnings("overloads") annotations that were added but not needed.

src/jdk.compiler/share/classes/com/sun/tools/javac/code/Flags.java line 280:

> 278:      * Currently available.
> 279:      */
> 280:     public static final long UNUSED_1 = 1L<<48;

what about just adding the comment saying that this spot is free without declaring an unused flag?

-------------

PR: https://git.openjdk.org/jdk/pull/12645

From alanb at openjdk.org  Fri Feb 24 11:40:05 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 24 Feb 2023 11:40:05 GMT
Subject: RFR: 8301119: Support for GB18030-2022 [v3]
In-Reply-To: <U-4zjhKODj0JRTHSx_FChBEHLABanbxFBr9nmvg8Vks=.f25ff406-6bcc-4376-ac89-609ae5affd32@github.com>
References: <FXBchbCnbNloQO7Nlh9Ijue_c_YugGk-UC7_-ZAjY2o=.7e1ca01f-8cee-40bb-bb06-6e5670abe661@github.com>
 <DbcSeT1d1ulLxFGuScNUYOimyD_bbHn9miPe9TvlSH8=.a10fd674-22b4-4d6b-ac97-3772babbcd3d@github.com>
 <U-4zjhKODj0JRTHSx_FChBEHLABanbxFBr9nmvg8Vks=.f25ff406-6bcc-4376-ac89-609ae5affd32@github.com>
Message-ID: <A2XsV6jvLtc5K_RfoEb1yWVRiSu_TJpgpe0Syc4joek=.a2e0741f-6595-4d05-85b8-00ead2e70cc0@github.com>

On Fri, 24 Feb 2023 08:34:48 GMT, Ichiroh Takiguchi <itakiguchi at openjdk.org> wrote:

> * Why GB18030.java.template is in src/jdk.charsets/share/classes/sun/nio/cs/ext/ directory even if the generated code is always stored into sun/nio/cs ?

That is a good question. It could move, and $PACKAGE replaced with sun.nio.cs, so it would be more obvious from the source location that it is generated into java.base rather than jdk.charsets. Up until now, GB18030 went into java.base on some platforms and jdk.charsets on other platforms. It will be the same for all platforms once this PR is integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/12518

From vromero at openjdk.org  Fri Feb 24 11:53:06 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 24 Feb 2023 11:53:06 GMT
Subject: RFR: 8026369: javac potentially ambiguous overload warning needs
 an improved scheme [v2]
In-Reply-To: <NlqhxTe-Li08DSIjyYVn5HI9uIAvIHZE4IG0x8tQTQw=.0ae9928e-7814-4356-bf75-11bc4eefc6be@github.com>
References: <IMxp3iCK--jYJ5Ia04i6QPYfnCHQobVcsmlI5aJXdqc=.892abcb8-7f2a-4fe9-aea2-1b1d41098a6d@github.com>
 <NlqhxTe-Li08DSIjyYVn5HI9uIAvIHZE4IG0x8tQTQw=.0ae9928e-7814-4356-bf75-11bc4eefc6be@github.com>
Message-ID: <tk3D21HgO9mRKLEvFHiLSqUPBqCBn483UBY8vu_Mb8E=.e9a261cb-752b-420e-967e-fbf09d8ab65b@github.com>

On Tue, 21 Feb 2023 01:42:41 GMT, Archie L. Cobbs <duke at openjdk.org> wrote:

>> This bug relates to the "potentially ambiguous overload" warning which is enabled by `-Xlint:overloads`.
>> 
>> The warning detects certain ambiguities that can cause problems for lambdas. For example, consider the interface `Spliterator.OfInt`, which declares these two methods:
>> 
>> void forEachRemaining(Consumer<? super Integer> action);
>> void forEachRemaining(IntConsumer action);
>> 
>> Both methods have the same name, same number of parameters, and take a lambda with the same "shape" in the same argument position. This causes an ambiguity in any code that wants to do this:
>> 
>>     spliterator.forEachRemaining(x -> { ... });
>> 
>> That code won't compile; instead, you'll get this error:
>> 
>> Ambiguity.java:4: error: reference to forEachRemaining is ambiguous
>>         spliterator.forEachRemaining(x -> { });
>>                    ^
>>   both method forEachRemaining(IntConsumer) in OfInt and method forEachRemaining(Consumer<? super Integer>) in OfInt match
>> 
>> 
>> The problem reported by the bug is that the warning fails to detect ambiguities which are created purely by inheritance, for example:
>> 
>> interface ConsumerOfInteger {
>>     void foo(Consumer<Integer> c);
>> }
>> 
>> interface IntegerConsumer {
>>     void foo(IntConsumer c);
>> }
>> 
>> // We should get a warning here...
>> interface Test extends ConsumerOfInteger, IntegerConsumer {
>> }
>> 
>> 
>> The cause of the bug is that ambiguities are detected on a per-method basis, by checking whether a method is part of an ambiguity pair when we visit that method. So if the methods in an ambiguity pair are inherited from two distinct supertypes, we'll miss the ambiguity.
>> 
>> To fix the problem, we need to look for ambiguities on a per-class level, checking all pairs of methods. However, it's not that simple - we only want to "blame" a class when that class itself, and not some supertype, is responsible for creating the ambiguity. For example, any interface extending `Spliterator.OfInt` will automatically inherit the two ambiguities mentioned above, but these are not the interface's fault so to speak so no warning should be generated. Making things more complicated is the fact that methods can be overridden and declared in generic classes so they only conflict in some subtypes, etc.
>> 
>> So we generate the warning when there are two methods m1 and m2 in a class C such that:
>> 
>> * m1 and m2 consitiute a "potentially ambiguous overload" (using the same definition as before)
>> * There is no direct supertype T of C such that m1 and m2, or some methods they override, both exist in T and constitute a "potentially ambiguous overload" as members of T
>> * We haven't already generated a warning for either m1 or m2 in class C
>> 
>> If either method is declared in C, we locate the warning there, but when both methods are inherited, there's no method declaration to point at so the warning is instead located at the class declaration.
>> 
>> I noticed a couple of other minor bugs; these are also being fixed here:
>> 
>> (1) For inherited methods, the method signatures were being reported as they are declared, rather than in the context of the class being visited. As a result, when a methods is inherited from a generic supertype, the ambiguity is less clear. Here's an example:
>> 
>> interface Upper<T> {
>>     void foo(T c);
>> }
>> 
>> interface Lower extends Upper<IntConsumer> {
>>     void foo(Consumer<Integer> c);
>> }
>> 
>> Currently, the error is reported as:
>> 
>> warning: [overloads] foo(Consumer<Integer>) in Lower is potentially ambiguous with foo(T) in Upper
>> 
>> Reporting the method signatures in the context of the class being visited makes the ambiguity clearer:
>> 
>> warning: [overloads] foo(Consumer<Integer>) in Lower is potentially ambiguous with foo(IntConsumer) in Upper
>> 
>> 
>> (2) When a method is identified as part of an ambiguous pair, we were setting a `POTENTIALLY_AMBIGUOUS` flag on it. This caused it to be forever excluded from future warnings. For methods that are declared in the class we're visiting, this makes sense, but it doesn't make sense for inherited methods, because it disqualifies them from participating in the analysis of any other class that also inherits them.
>> 
>> As a result, for a class like the one below, the compiler was only generating one warning instead of three:
>> 
>> public interface SuperIface {
>>     void foo(Consumer<Integer> c);
>> }
>> 
>> public interface I1 extends SuperIface { 
>>     void foo(IntConsumer c);        // warning was generated here
>> }   
>> 
>> public interface I2 extends SuperIface { 
>>     void foo(IntConsumer c);        // no warning was generated here
>> }   
>> 
>> public interface I3 extends SuperIface { 
>>     void foo(IntConsumer c);        // no warning was generated here
>> }   
>> 
>> 
>> With this patch the `POTENTIALLY_AMBIGUOUS` flag is no longer needed. I wasn't sure whether to renumber all the subsequent flags, or just leave an empty placeholder, so I chose the latter.
>> 
>> Finally, this fix uncovers new warnings in `java.base` and `java.desktop`, so these are now suppressed in the patch.
>
> Archie L. Cobbs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove @SuppressWarnings("overloads") annotations that were added but not needed.

I think a CSR is needed as we will be generating more warnings and projects compiling with -Werror could see compilation errors

-------------

PR: https://git.openjdk.org/jdk/pull/12645

From rgiulietti at openjdk.org  Fri Feb 24 13:39:19 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Fri, 24 Feb 2023 13:39:19 GMT
Subject: RFR: JDK-8302040: Port fdlibm sqrt to Java
In-Reply-To: <rjVM2lWPdsvPcfLF3oNShP-cSN8-P-i16ikUC3sTgIg=.1d4f470d-2ac9-4394-b55e-099affce763f@github.com>
References: <rjVM2lWPdsvPcfLF3oNShP-cSN8-P-i16ikUC3sTgIg=.1d4f470d-2ac9-4394-b55e-099affce763f@github.com>
Message-ID: <sWoL9o59cAFphCT0vYpnL8L5_tFX31ZTN-ogADNn0Bw=.d8a9fdb2-7ebe-4137-a2fe-8bca605dcd66@github.com>

On Thu, 23 Feb 2023 23:28:11 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> The wheel of FDLIBM porting turns a notch and sqrt comes into play.
> 
> While the sqrt operation usually has a hardware implementation that is intrinsified, for completeness a software implementation should be available as well.

Otherwise LGTM

src/java.base/share/classes/java/lang/FdLibm.java line 659:

> 657:                     q1  += r;
> 658:                 }
> 659:                 ix0 += ix0 + ((ix1 & sign) >>> 31);

You may want to add the traditional `// unsigned shift` comment even here, just to be consistent.

test/jdk/java/lang/StrictMath/ExhaustingTests.java line 71:

> 69:             // Since sqrt is correctly rounded, could additionaly the
> 70:             // transliteration or StrictMath sqrt methods to against
> 71:             // Math::sqrt.

I guess this comment has been messed up by some copy&paste activities?
Or is it a ChatGPT output?

test/jdk/java/lang/StrictMath/FdlibmTranslit.java line 653:

> 651:                     q1  += r;
> 652:                 }
> 653:                 ix0 += ix0 + ((ix1&sign)>>>31);

You may want to add the traditional `// unsigned shift` comment even here, just to be consistent.

-------------

PR: https://git.openjdk.org/jdk/pull/12736

From rgiulietti at openjdk.org  Fri Feb 24 13:39:21 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Fri, 24 Feb 2023 13:39:21 GMT
Subject: RFR: JDK-8302040: Port fdlibm sqrt to Java
In-Reply-To: <Q9XfwYgplnOvwwf21RZGdEeyjPzTDqMc8LEDt84vOww=.7f42be76-b16d-4a76-80a2-f1fd9f0374c7@github.com>
References: <rjVM2lWPdsvPcfLF3oNShP-cSN8-P-i16ikUC3sTgIg=.1d4f470d-2ac9-4394-b55e-099affce763f@github.com>
 <Q9XfwYgplnOvwwf21RZGdEeyjPzTDqMc8LEDt84vOww=.7f42be76-b16d-4a76-80a2-f1fd9f0374c7@github.com>
Message-ID: <X1YG4bA78kGZpIOmWV0heVBQhhi8OlgXWhN9-6UkTus=.d1ab64b1-7da4-4701-9aff-1f1ef3ce4509@github.com>

On Thu, 23 Feb 2023 23:39:26 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> The wheel of FDLIBM porting turns a notch and sqrt comes into play.
>> 
>> While the sqrt operation usually has a hardware implementation that is intrinsified, for completeness a software implementation should be available as well.
>
> src/java.base/share/classes/java/lang/FdLibm.java line 689:
> 
>> 687:             ix0 += (m << 20);
>> 688:             z = __HI(z, ix0);
>> 689:             z = __LO(z, ix1);
> 
> I was tempted to rewrite these line as something like:
> `return Double.longBitsToDouble((long)ix0 << 32 | (long)ix1);`
> and may do so in a future refactoring.

That should read
`return Double.longBitsToDouble((long)ix0 << 32 | ix1 & 0xffff_ffffL);`

-------------

PR: https://git.openjdk.org/jdk/pull/12736

From alanb at openjdk.org  Fri Feb 24 13:44:40 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 24 Feb 2023 13:44:40 GMT
Subject: RFR: 8302899: Executors.newSingleThreadExecutor can use Cleaner to
 shutdown executor [v5]
In-Reply-To: <tBrSZRn1GdrWMSRUsdNNyAWpkuS_FvtLwLuUKut6LH0=.cd1a7fcb-dbcf-45eb-b3d3-72ba17087566@github.com>
References: <tBrSZRn1GdrWMSRUsdNNyAWpkuS_FvtLwLuUKut6LH0=.cd1a7fcb-dbcf-45eb-b3d3-72ba17087566@github.com>
Message-ID: <4ZWYgQetrzu3qJhzFrqmdhxBq5Q04NmC_pPWyMVrp-M=.1a950b12-92d5-475d-b55b-148b890d3da7@github.com>

> Executors.newSingleThreadExecutor returns a delegating ExecutorService that has finalizer to shutdown the underlying TPE when the wrapper is finalizable. It goes back to JDK 6 and JDK-6399443. This is the last non-empty finalizer in java.base. Removing it will likely lead to bug reports/complaints as the current behavior goes back to 2006. So the proposal is to just replace it with a Cleaner, trivially done in this case. As part of the changes, I've replaced the existing test with a more modern test that exercises more scenarios.

Alan Bateman has updated the pull request incrementally with one additional commit since the last revision:

  Rename cleaner, fix typo in test comments

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12675/files
  - new: https://git.openjdk.org/jdk/pull/12675/files/449f72b6..fbe61add

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12675&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12675&range=03-04

  Stats: 10 lines in 2 files changed: 4 ins; 0 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/12675.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12675/head:pull/12675

PR: https://git.openjdk.org/jdk/pull/12675

From alanb at openjdk.org  Fri Feb 24 13:44:41 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 24 Feb 2023 13:44:41 GMT
Subject: RFR: 8302899: Executors.newSingleThreadExecutor can use Cleaner to
 shutdown executor [v4]
In-Reply-To: <3uOU_Y7rRGGZ4WIicugLBKrDMnFiFJygIwUSgRwC5HM=.8c3ddb7f-1b4d-4a78-8b8e-cb0832b9e350@github.com>
References: <tBrSZRn1GdrWMSRUsdNNyAWpkuS_FvtLwLuUKut6LH0=.cd1a7fcb-dbcf-45eb-b3d3-72ba17087566@github.com>
 <gCqs5Difq993oMhXzOthVrWAHqCTCQefqYqSF_BP-Dc=.6ecb5e0a-cd13-4936-b0ab-245edc9898e8@github.com>
 <3uOU_Y7rRGGZ4WIicugLBKrDMnFiFJygIwUSgRwC5HM=.8c3ddb7f-1b4d-4a78-8b8e-cb0832b9e350@github.com>
Message-ID: <78y2Fo0ZkrQHTg6Wxe-Hy_Xy-fm3A4QkkGlYa3qT2Qg=.8e7b4c70-4e0d-416f-9c48-2f286fc30cfa@github.com>

On Thu, 23 Feb 2023 16:36:46 GMT, Martin Buchholz <martin at openjdk.org> wrote:

>> Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision:
>> 
>>  - Merge
>>  - Improve SM scenario
>>  - Keep reference to Cleanable
>>  - Merge
>>  - Fix typo in comment, remove blank line
>>  - Replace older test
>>  - Initial commit
>
> src/java.base/share/classes/java/util/concurrent/Executors.java line 832:
> 
>> 830:     private static class AutoShutdownDelegatedExecutorService
>> 831:             extends DelegatedExecutorService {
>> 832:         private final Cleanable cleaner;
> 
> "cleaner" is a Cleanable, not a Cleaner. We should consistently use (as we do elsewhere in openjdk)
> 
> 
>  private final Cleanable cleanable;
> 
> 
> and fix the others to be consistent:
> 
> 
> ./sun/nio/ch/DatagramChannelImpl.java:115:    private final Cleanable cleaner;
> ./sun/nio/ch/NioSocketImpl.java:106:    private Cleanable cleaner;
> ./java/util/concurrent/Executors.java:832:        private final Cleanable cleaner;
> 
> 
> (BTW: I find Cleaners much harder to use than old finalize, and it looks like I'm not the only one!)

I'm rename the Cleaner in AutoShutdownDelegatedExecutorService but I'd prefer not rename fields in other areas, at least not part of this change.

> (BTW: I find Cleaners much harder to use than old finalize, and it looks like I'm not the only one!)

Finalization has many flaws and I think we could add that it was way too easy to add a finalize method without thinking too much about the implications. So yes, Cleaners do force you to separate out the resource and think about concurrency. It is an advanced feature, to be used very sparely, and we should continue to developers to close the resource explicitly.

> test/jdk/java/util/concurrent/Executors/AutoShutdown.java line 118:
> 
>> 116:      */
>> 117:     private ExecutorService getDelegate(ExecutorService executor) throws Exception {
>> 118:         Field eField = Class.forName("java.util.concurrent.Executors$DelegatedExecutorService")
> 
> I was under the impression that VarHandle/MethodHandle are generally preferred for writing white box tests (as I did myself in various WhiteBox.java tests).

I don't think so. If you search the tests for uses of "+open" then you'll see a variety of usages.

-------------

PR: https://git.openjdk.org/jdk/pull/12675

From duke at openjdk.org  Fri Feb 24 14:19:40 2023
From: duke at openjdk.org (David M. Lloyd)
Date: Fri, 24 Feb 2023 14:19:40 GMT
Subject: RFR: 8292914: Drop the counter from lambda class names [v9]
In-Reply-To: <GgLfH-ueBQqT-Mfk1mKpKFAt8fYqyjfVJ9lmlsBsCbo=.8dd5b3b4-4e84-4970-9179-1c0399b30edc@github.com>
References: <GgLfH-ueBQqT-Mfk1mKpKFAt8fYqyjfVJ9lmlsBsCbo=.8dd5b3b4-4e84-4970-9179-1c0399b30edc@github.com>
Message-ID: <O-GBw5DyW_lJsii1xoapcJwjib1_1br9CTTL7DWKfQM=.c6af53df-eb85-41f2-970d-e53ef5e7d7d0@github.com>

> The class generated for lambda proxies is now defined as a hidden class. This means that the counter, which was used to ensure a unique class name and avoid clashes, is now redundant. In addition to performing redundant work, this also impacts build reproducibility for native image generators which might already have a strategy to cope with hidden classes but cannot cope with indeterminate definition order for lambda proxy classes.
> 
> This solves JDK-8292914 by making lambda proxy names always be stable without any configuration needed. This would also replace #10024.

David M. Lloyd has updated the pull request incrementally with one additional commit since the last revision:

  Apply formatting suggestions and update copyright notices

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12579/files
  - new: https://git.openjdk.org/jdk/pull/12579/files/145d857f..a4261e30

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12579&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12579&range=07-08

  Stats: 66 lines in 42 files changed: 10 ins; 10 del; 46 mod
  Patch: https://git.openjdk.org/jdk/pull/12579.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12579/head:pull/12579

PR: https://git.openjdk.org/jdk/pull/12579

From duke at openjdk.org  Fri Feb 24 14:21:12 2023
From: duke at openjdk.org (David M. Lloyd)
Date: Fri, 24 Feb 2023 14:21:12 GMT
Subject: RFR: 8292914: Drop the counter from lambda class names [v8]
In-Reply-To: <Xe5S5U8DjBjtfnEQfKL87zhlUjIkERrZ0xaR9UaNXH8=.e785e130-0a82-4bae-beb2-39cac82efeb7@github.com>
References: <GgLfH-ueBQqT-Mfk1mKpKFAt8fYqyjfVJ9lmlsBsCbo=.8dd5b3b4-4e84-4970-9179-1c0399b30edc@github.com>
 <AdfREeJYVkF6HTsw669hMueQxdGXUXxYc4GetiDuoDk=.5124c8b8-3bea-4baa-bbb1-9383c84bb15f@github.com>
 <Xe5S5U8DjBjtfnEQfKL87zhlUjIkERrZ0xaR9UaNXH8=.e785e130-0a82-4bae-beb2-39cac82efeb7@github.com>
Message-ID: <5z5MvNt94Wsoxog3INc1E0Z2VOKQT2Omzz05aJjv1XI=.738eb963-ec0c-4f2e-b360-cd48cde4e2ac@github.com>

On Thu, 23 Feb 2023 23:50:16 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> David M. Lloyd has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Many tests have patterns for lambda class names; update them
>>  - Update comments and javadoc showin the old pattern
>
> src/java.base/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java line 370:
> 
>> 368:                 if (useImplMethodHandle) {
>> 369:                     lookup = caller.defineHiddenClassWithClassData(classBytes, implementation, !disableEagerInitialization,
>> 370:                         NESTMATE, STRONG);
> 
> nit: formatting - align this line to the first argument `classBytes` in L369.

Done.

> src/java.base/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java line 374:
> 
>> 372:                     lookup = caller.defineHiddenClass(classBytes, !disableEagerInitialization, NESTMATE, STRONG);
>> 373:                 }
>> 374:             } catch (Throwable t) {
> 
> suggest to use try-finally in writing the file.
> 
> 
>             Lookup lookup = null;
>             try {
>                 if (useImplMethodHandle) {
>                     lookup = caller.defineHiddenClassWithClassData(classBytes, implementation, !disableEagerInitialization,
>                                                                    NESTMATE, STRONG);
>                 } else {
>                     lookup = caller.defineHiddenClass(classBytes, !disableEagerInitialization, NESTMATE, STRONG);
>                 }
>             } finally {
>                 // If requested, dump out to a file for debugging purposes
>                 if (dumper != null) {
>                     final String name;
>                     if (lookup != null) {
>                         String definedName = lookup.lookupClass().getName();
>                         int suffixIdx = definedName.lastIndexOf('/');
>                         assert suffixIdx != -1;
>                         name = lambdaClassName + '.' + definedName.substring(suffixIdx + 1);
>                     } else {
>                         name = lambdaClassName + ".failed-" + counter.incrementAndGet();
>                     }
>                     doDump(name, classBytes);
>                 }
>             }
>             return lookup.lookupClass();

Done, with the small difference that I move the `return lookup.lookupClass()` into the `try` block because IntelliJ IDEA thought that `lookup` could be `null` at the point of the `return` statement; I figure, if IDEA can get that wrong then a casual reader might get it wrong too.

-------------

PR: https://git.openjdk.org/jdk/pull/12579

From alanb at openjdk.org  Fri Feb 24 14:36:13 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 24 Feb 2023 14:36:13 GMT
Subject: RFR: 8302871: Speed up StringLatin1.regionMatchesCI [v14]
In-Reply-To: <F0qyphqbltdnyRwcfKg96Vh2jkRtliefQlGBRuM7Zcc=.976fa82c-6ad8-4048-b0cf-b03683fa4ecd@github.com>
References: <dnsiX3nRffjGjZXJG7lMAZj2FktEl2Wc1XfFthQ4iJs=.8c41438a-80a4-468f-ae0b-7322c9d6d952@github.com>
 <F0qyphqbltdnyRwcfKg96Vh2jkRtliefQlGBRuM7Zcc=.976fa82c-6ad8-4048-b0cf-b03683fa4ecd@github.com>
Message-ID: <r66iRYFUQd-sJP_PpnTqWSBt2NX90oTVqbUtI4x8uqU=.974f1434-b6cb-4db5-9247-a2fb0ed5ce14@github.com>

On Wed, 22 Feb 2023 20:01:52 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

>> This PR suggests we can speed up `StringLatin1.regionMatchesCI` by applying 'the oldest ASCII trick in the book'.
>> 
>> The new static method `CharacterDataLatin1.equalsIgnoreCase` compares two latin1 bytes for equality ignoring case. `StringLatin1.regionMatchesCI` is updated to use `equalsIgnoreCase`
>> 
>> To verify the correctness of `equalsIgnoreCase`, a new test is added  to `EqualsIgnoreCase` with an exhaustive verification that all 256x256 latin1 code point pairs have an `equalsIgnoreCase` consistent with Character.toUpperCase, Character.toLowerCase.
>> 
>> Performance is tested for matching and mismatching cases of code point pairs picked from the ASCII letter, ASCII number and latin1 letter ranges. Results in the first comment below.
>
> Eirik Bjorsnos 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:
> 
>  - Merge branch 'master' into regionmatches-latin1-speedup
>  - Merge branch 'master' into regionmatches-latin1-speedup
>  - Make the loop variables chars to avoid casting
>  - Use improved case-twiddling comment as suggested by Martin
>  - Replace 'oldest ASCII trick in the book' use in toUpperCase, toLowerCase with "by removing (setting) a single bit"
>  - Align local variable naming in toLowerCase, toUpperCase with equalsIgnoreCase by using 'lower' and 'upper'
>  - Rename unconventionally named local variable 'U' to 'upper'
>  - Merge remote-tracking branch 'origin/master' into regionmatches-latin1-speedup
>  - Add whitespace between methods
>  - Merge branch 'master' into regionmatches-latin1-speedup
>  - ... and 11 more: https://git.openjdk.org/jdk/compare/6e269b24...597b346a

Marked as reviewed by alanb (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/12632

From alanb at openjdk.org  Fri Feb 24 14:58:08 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 24 Feb 2023 14:58:08 GMT
Subject: RFR: 8302590: Add String.indexOf(int ch, int fromIndex,
 int toIndex)
In-Reply-To: <uQ65oRaVDfpzm9bYRuo_MvSuZIdepicE3GnB3Omyngs=.fc23545b-141a-47e5-8a6a-aa28ae1375e5@github.com>
References: <uQ65oRaVDfpzm9bYRuo_MvSuZIdepicE3GnB3Omyngs=.fc23545b-141a-47e5-8a6a-aa28ae1375e5@github.com>
Message-ID: <Ba1-pAPv01x8R5a7Xs28vdw-Y5WZ8bn253t1lcPF8WU=.cbf398ba-75d6-4ba1-a395-622f3e3a25d7@github.com>

On Thu, 16 Feb 2023 17:16:35 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

> Add an `indexOf()` variant allowing to specify both a lower and an upper bound on the search.

src/java.base/share/classes/java/lang/String.java line 2467:

> 2465:      *
> 2466:      * <p>As consequence of these rules, if {@code fromIndex} is greater than
> 2467:      * or equal to {@code toIndex}, then {@code -1} is returned.

Are there other examples in String where the equivalent of fromIndex > toIndex doesn't throw?

src/java.base/share/classes/java/lang/String.java line 2483:

> 2481:         return isLatin1() ? StringLatin1.indexOf(value, ch, fromIndex, toIndex)
> 2482:                 : StringUTF16.indexOf(value, ch, fromIndex, toIndex);
> 2483:     }

I assume you've add `@since 21` before integrating.

-------------

PR: https://git.openjdk.org/jdk/pull/12600

From rgiulietti at openjdk.org  Fri Feb 24 15:31:07 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Fri, 24 Feb 2023 15:31:07 GMT
Subject: RFR: 8302590: Add String.indexOf(int ch, int fromIndex,
 int toIndex)
In-Reply-To: <Ba1-pAPv01x8R5a7Xs28vdw-Y5WZ8bn253t1lcPF8WU=.cbf398ba-75d6-4ba1-a395-622f3e3a25d7@github.com>
References: <uQ65oRaVDfpzm9bYRuo_MvSuZIdepicE3GnB3Omyngs=.fc23545b-141a-47e5-8a6a-aa28ae1375e5@github.com>
 <Ba1-pAPv01x8R5a7Xs28vdw-Y5WZ8bn253t1lcPF8WU=.cbf398ba-75d6-4ba1-a395-622f3e3a25d7@github.com>
Message-ID: <T0UAk-Qz9RBzYl_R3eePcwtT7uW7TCMg0PrNB7xcGis=.2261b886-16a2-43a9-a0e8-66997dee19c1@github.com>

On Fri, 24 Feb 2023 14:54:50 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Add an `indexOf()` variant allowing to specify both a lower and an upper bound on the search.
>
> src/java.base/share/classes/java/lang/String.java line 2467:
> 
>> 2465:      *
>> 2466:      * <p>As consequence of these rules, if {@code fromIndex} is greater than
>> 2467:      * or equal to {@code toIndex}, then {@code -1} is returned.
> 
> Are there other examples in String where the equivalent of fromIndex > toIndex doesn't throw?

I simply extrapolated the behavior from `indexOf(int ch,int fromIndex), which has a similar note:

     * There is no restriction on the value of {@code fromIndex}. If it
     * is negative, it has the same effect as if it were zero: this entire
     * string may be searched. If it is greater than the length of this
     * string, it has the same effect as if it were equal to the length of
     * this string: {@code -1} is returned.

> src/java.base/share/classes/java/lang/String.java line 2483:
> 
>> 2481:         return isLatin1() ? StringLatin1.indexOf(value, ch, fromIndex, toIndex)
>> 2482:                 : StringUTF16.indexOf(value, ch, fromIndex, toIndex);
>> 2483:     }
> 
> I assume you've add `@since 21` before integrating.

I was reluctant to add it, as it is not yet known when the PR will be integrated. I'll add it in the next commit.

-------------

PR: https://git.openjdk.org/jdk/pull/12600

From rgiulietti at openjdk.org  Fri Feb 24 15:35:06 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Fri, 24 Feb 2023 15:35:06 GMT
Subject: RFR: 8302590: Add String.indexOf(int ch, int fromIndex,
 int toIndex)
In-Reply-To: <T0UAk-Qz9RBzYl_R3eePcwtT7uW7TCMg0PrNB7xcGis=.2261b886-16a2-43a9-a0e8-66997dee19c1@github.com>
References: <uQ65oRaVDfpzm9bYRuo_MvSuZIdepicE3GnB3Omyngs=.fc23545b-141a-47e5-8a6a-aa28ae1375e5@github.com>
 <Ba1-pAPv01x8R5a7Xs28vdw-Y5WZ8bn253t1lcPF8WU=.cbf398ba-75d6-4ba1-a395-622f3e3a25d7@github.com>
 <T0UAk-Qz9RBzYl_R3eePcwtT7uW7TCMg0PrNB7xcGis=.2261b886-16a2-43a9-a0e8-66997dee19c1@github.com>
Message-ID: <KkniribyGhakYm9e1Az7zRXcODJrtqo1aMGP4zIHOA8=.efd150ff-69d3-4a5e-805d-4a93331524bb@github.com>

On Fri, 24 Feb 2023 15:26:35 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/String.java line 2467:
>> 
>>> 2465:      *
>>> 2466:      * <p>As consequence of these rules, if {@code fromIndex} is greater than
>>> 2467:      * or equal to {@code toIndex}, then {@code -1} is returned.
>> 
>> Are there other examples in String where the equivalent of fromIndex > toIndex doesn't throw?
>
> I simply extrapolated the behavior from `indexOf(int ch,int fromIndex), which has a similar note:
> 
>      * There is no restriction on the value of {@code fromIndex}. If it
>      * is negative, it has the same effect as if it were zero: this entire
>      * string may be searched. If it is greater than the length of this
>      * string, it has the same effect as if it were equal to the length of
>      * this string: {@code -1} is returned.

This is the behavior of the underlying implementation as well.

-------------

PR: https://git.openjdk.org/jdk/pull/12600

From rriggs at openjdk.org  Fri Feb 24 15:41:05 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 24 Feb 2023 15:41:05 GMT
Subject: RFR: 8302590: Add String.indexOf(int ch, int fromIndex,
 int toIndex)
In-Reply-To: <T0UAk-Qz9RBzYl_R3eePcwtT7uW7TCMg0PrNB7xcGis=.2261b886-16a2-43a9-a0e8-66997dee19c1@github.com>
References: <uQ65oRaVDfpzm9bYRuo_MvSuZIdepicE3GnB3Omyngs=.fc23545b-141a-47e5-8a6a-aa28ae1375e5@github.com>
 <Ba1-pAPv01x8R5a7Xs28vdw-Y5WZ8bn253t1lcPF8WU=.cbf398ba-75d6-4ba1-a395-622f3e3a25d7@github.com>
 <T0UAk-Qz9RBzYl_R3eePcwtT7uW7TCMg0PrNB7xcGis=.2261b886-16a2-43a9-a0e8-66997dee19c1@github.com>
Message-ID: <BR9EZHJVS9XZJ6dbGGcVIZlr1tI2FgqabVm2k_Eeqqk=.f10d84c2-3fb9-449b-a151-4da09d4757b4@github.com>

On Fri, 24 Feb 2023 15:28:33 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/String.java line 2483:
>> 
>>> 2481:         return isLatin1() ? StringLatin1.indexOf(value, ch, fromIndex, toIndex)
>>> 2482:                 : StringUTF16.indexOf(value, ch, fromIndex, toIndex);
>>> 2483:     }
>> 
>> I assume you've add `@since 21` before integrating.
>
> I was reluctant to add it, as it is not yet known when the PR will be integrated. I'll add it in the next commit.

When the CSR is approved is a good trigger for adding @since.  But its fine to be optimistic in the PR.

-------------

PR: https://git.openjdk.org/jdk/pull/12600

From martin at openjdk.org  Fri Feb 24 15:51:12 2023
From: martin at openjdk.org (Martin Buchholz)
Date: Fri, 24 Feb 2023 15:51:12 GMT
Subject: RFR: 8302899: Executors.newSingleThreadExecutor can use Cleaner to
 shutdown executor [v5]
In-Reply-To: <4ZWYgQetrzu3qJhzFrqmdhxBq5Q04NmC_pPWyMVrp-M=.1a950b12-92d5-475d-b55b-148b890d3da7@github.com>
References: <tBrSZRn1GdrWMSRUsdNNyAWpkuS_FvtLwLuUKut6LH0=.cd1a7fcb-dbcf-45eb-b3d3-72ba17087566@github.com>
 <4ZWYgQetrzu3qJhzFrqmdhxBq5Q04NmC_pPWyMVrp-M=.1a950b12-92d5-475d-b55b-148b890d3da7@github.com>
Message-ID: <Ha7bwxTLRpprjQLRyMJOnhJNnsROuM3F0eats1JZd00=.1fd8f103-4793-42cd-bc0a-a07076452881@github.com>

On Fri, 24 Feb 2023 13:44:40 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Executors.newSingleThreadExecutor returns a delegating ExecutorService that has finalizer to shutdown the underlying TPE when the wrapper is finalizable. It goes back to JDK 6 and JDK-6399443. This is the last non-empty finalizer in java.base. Removing it will likely lead to bug reports/complaints as the current behavior goes back to 2006. So the proposal is to just replace it with a Cleaner, trivially done in this case. As part of this change, I've added a RF to DelegatedExecutorService.shutdown to be consistent with the other methods - this is a benign change and avoids needing to puzzle over why it wasn't there previously. I've replaced the existing test with a more modern test that exercises more scenarios.
>
> Alan Bateman has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rename cleaner, fix typo in test comments

Marked as reviewed by martin (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/12675

From jcking at openjdk.org  Fri Feb 24 15:52:12 2023
From: jcking at openjdk.org (Justin King)
Date: Fri, 24 Feb 2023 15:52:12 GMT
Subject: RFR: JDK-8303072: Memory leak in exeNullCallerTest.cpp
In-Reply-To: <CeYIh1UwJeTs52-a3EJQThW5XEymSruJhYB9Qx_nkj0=.d48da304-04b1-41cc-89f3-14f222ef847b@github.com>
References: <CeYIh1UwJeTs52-a3EJQThW5XEymSruJhYB9Qx_nkj0=.d48da304-04b1-41cc-89f3-14f222ef847b@github.com>
Message-ID: <EiB2Qne8ZzNg3JiPbBagGpahtsch_VxpyVfpOXMBheQ=.5c7cb07a-9cba-43ee-b7f1-1f28565285cd@github.com>

On Wed, 22 Feb 2023 14:02:28 GMT, Justin King <jcking at openjdk.org> wrote:

> Fix trivial memory leak that occurs during tests.

Failing test is unrelated and from an already fix at head issue.

-------------

PR: https://git.openjdk.org/jdk/pull/12715

From jcking at openjdk.org  Fri Feb 24 15:52:13 2023
From: jcking at openjdk.org (Justin King)
Date: Fri, 24 Feb 2023 15:52:13 GMT
Subject: Integrated: JDK-8303072: Memory leak in exeNullCallerTest.cpp
In-Reply-To: <CeYIh1UwJeTs52-a3EJQThW5XEymSruJhYB9Qx_nkj0=.d48da304-04b1-41cc-89f3-14f222ef847b@github.com>
References: <CeYIh1UwJeTs52-a3EJQThW5XEymSruJhYB9Qx_nkj0=.d48da304-04b1-41cc-89f3-14f222ef847b@github.com>
Message-ID: <zZvqMEA64BD7-W8-uFOJZ01WD6EOpkJErHCa4XXUws0=.5c2f330d-fc20-4c1e-a9a8-c751ee18a07c@github.com>

On Wed, 22 Feb 2023 14:02:28 GMT, Justin King <jcking at openjdk.org> wrote:

> Fix trivial memory leak that occurs during tests.

This pull request has now been integrated.

Changeset: 83d77b1c
Author:    Justin King <jcking at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/83d77b1cbb6d0179e9c130d51b7fada2e76e86d3
Stats:     3 lines in 1 file changed: 2 ins; 0 del; 1 mod

8303072: Memory leak in exeNullCallerTest.cpp

Reviewed-by: dholmes

-------------

PR: https://git.openjdk.org/jdk/pull/12715

From mchung at openjdk.org  Fri Feb 24 16:00:12 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Fri, 24 Feb 2023 16:00:12 GMT
Subject: RFR: 8292914: Drop the counter from lambda class names [v9]
In-Reply-To: <O-GBw5DyW_lJsii1xoapcJwjib1_1br9CTTL7DWKfQM=.c6af53df-eb85-41f2-970d-e53ef5e7d7d0@github.com>
References: <GgLfH-ueBQqT-Mfk1mKpKFAt8fYqyjfVJ9lmlsBsCbo=.8dd5b3b4-4e84-4970-9179-1c0399b30edc@github.com>
 <O-GBw5DyW_lJsii1xoapcJwjib1_1br9CTTL7DWKfQM=.c6af53df-eb85-41f2-970d-e53ef5e7d7d0@github.com>
Message-ID: <MmbshPz-LHGnUoKUpINkm4zsAZF5Bh4_y_wpuUI8Xz8=.2a7f88e7-ecc3-4a5a-b342-6029beee8115@github.com>

On Fri, 24 Feb 2023 14:19:40 GMT, David M. Lloyd <duke at openjdk.org> wrote:

>> The class generated for lambda proxies is now defined as a hidden class. This means that the counter, which was used to ensure a unique class name and avoid clashes, is now redundant. In addition to performing redundant work, this also impacts build reproducibility for native image generators which might already have a strategy to cope with hidden classes but cannot cope with indeterminate definition order for lambda proxy classes.
>> 
>> This solves JDK-8292914 by making lambda proxy names always be stable without any configuration needed. This would also replace #10024.
>
> David M. Lloyd has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Apply formatting suggestions and update copyright notices

src/java.base/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java line 380:

> 378:                     final String name;
> 379:                     if (lookup != null) {
> 380:                         final String definedName = lookup.lookupClass().getName();

nit: you could drop `final` for these local variables.   Otherwise, looks good.

-------------

PR: https://git.openjdk.org/jdk/pull/12579

From duke at openjdk.org  Fri Feb 24 16:04:38 2023
From: duke at openjdk.org (Archie L. Cobbs)
Date: Fri, 24 Feb 2023 16:04:38 GMT
Subject: RFR: 8026369: javac potentially ambiguous overload warning needs
 an improved scheme [v3]
In-Reply-To: <IMxp3iCK--jYJ5Ia04i6QPYfnCHQobVcsmlI5aJXdqc=.892abcb8-7f2a-4fe9-aea2-1b1d41098a6d@github.com>
References: <IMxp3iCK--jYJ5Ia04i6QPYfnCHQobVcsmlI5aJXdqc=.892abcb8-7f2a-4fe9-aea2-1b1d41098a6d@github.com>
Message-ID: <NHHLq4y0LkeQGPPSoHjNOquUU0_iafjmkeFZosjoFPs=.22a5e84f-eaba-4e44-b531-dcd9ea9a92c7@github.com>

> This bug relates to the "potentially ambiguous overload" warning which is enabled by `-Xlint:overloads`.
> 
> The warning detects certain ambiguities that can cause problems for lambdas. For example, consider the interface `Spliterator.OfInt`, which declares these two methods:
> 
> void forEachRemaining(Consumer<? super Integer> action);
> void forEachRemaining(IntConsumer action);
> 
> Both methods have the same name, same number of parameters, and take a lambda with the same "shape" in the same argument position. This causes an ambiguity in any code that wants to do this:
> 
>     spliterator.forEachRemaining(x -> { ... });
> 
> That code won't compile; instead, you'll get this error:
> 
> Ambiguity.java:4: error: reference to forEachRemaining is ambiguous
>         spliterator.forEachRemaining(x -> { });
>                    ^
>   both method forEachRemaining(IntConsumer) in OfInt and method forEachRemaining(Consumer<? super Integer>) in OfInt match
> 
> 
> The problem reported by the bug is that the warning fails to detect ambiguities which are created purely by inheritance, for example:
> 
> interface ConsumerOfInteger {
>     void foo(Consumer<Integer> c);
> }
> 
> interface IntegerConsumer {
>     void foo(IntConsumer c);
> }
> 
> // We should get a warning here...
> interface Test extends ConsumerOfInteger, IntegerConsumer {
> }
> 
> 
> The cause of the bug is that ambiguities are detected on a per-method basis, by checking whether a method is part of an ambiguity pair when we visit that method. So if the methods in an ambiguity pair are inherited from two distinct supertypes, we'll miss the ambiguity.
> 
> To fix the problem, we need to look for ambiguities on a per-class level, checking all pairs of methods. However, it's not that simple - we only want to "blame" a class when that class itself, and not some supertype, is responsible for creating the ambiguity. For example, any interface extending `Spliterator.OfInt` will automatically inherit the two ambiguities mentioned above, but these are not the interface's fault so to speak so no warning should be generated. Making things more complicated is the fact that methods can be overridden and declared in generic classes so they only conflict in some subtypes, etc.
> 
> So we generate the warning when there are two methods m1 and m2 in a class C such that:
> 
> * m1 and m2 consitiute a "potentially ambiguous overload" (using the same definition as before)
> * There is no direct supertype T of C such that m1 and m2, or some methods they override, both exist in T and constitute a "potentially ambiguous overload" as members of T
> * We haven't already generated a warning for either m1 or m2 in class C
> 
> If either method is declared in C, we locate the warning there, but when both methods are inherited, there's no method declaration to point at so the warning is instead located at the class declaration.
> 
> I noticed a couple of other minor bugs; these are also being fixed here:
> 
> (1) For inherited methods, the method signatures were being reported as they are declared, rather than in the context of the class being visited. As a result, when a methods is inherited from a generic supertype, the ambiguity is less clear. Here's an example:
> 
> interface Upper<T> {
>     void foo(T c);
> }
> 
> interface Lower extends Upper<IntConsumer> {
>     void foo(Consumer<Integer> c);
> }
> 
> Currently, the error is reported as:
> 
> warning: [overloads] foo(Consumer<Integer>) in Lower is potentially ambiguous with foo(T) in Upper
> 
> Reporting the method signatures in the context of the class being visited makes the ambiguity clearer:
> 
> warning: [overloads] foo(Consumer<Integer>) in Lower is potentially ambiguous with foo(IntConsumer) in Upper
> 
> 
> (2) When a method is identified as part of an ambiguous pair, we were setting a `POTENTIALLY_AMBIGUOUS` flag on it. This caused it to be forever excluded from future warnings. For methods that are declared in the class we're visiting, this makes sense, but it doesn't make sense for inherited methods, because it disqualifies them from participating in the analysis of any other class that also inherits them.
> 
> As a result, for a class like the one below, the compiler was only generating one warning instead of three:
> 
> public interface SuperIface {
>     void foo(Consumer<Integer> c);
> }
> 
> public interface I1 extends SuperIface { 
>     void foo(IntConsumer c);        // warning was generated here
> }   
> 
> public interface I2 extends SuperIface { 
>     void foo(IntConsumer c);        // no warning was generated here
> }   
> 
> public interface I3 extends SuperIface { 
>     void foo(IntConsumer c);        // no warning was generated here
> }   
> 
> 
> With this patch the `POTENTIALLY_AMBIGUOUS` flag is no longer needed. I wasn't sure whether to renumber all the subsequent flags, or just leave an empty placeholder, so I chose the latter.
> 
> Finally, this fix uncovers new warnings in `java.base` and `java.desktop`, so these are now suppressed in the patch.

Archie L. Cobbs has updated the pull request incrementally with one additional commit since the last revision:

  Remove placeholder flag UNUSED_1; just leave a comment instead.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12645/files
  - new: https://git.openjdk.org/jdk/pull/12645/files/88a5f993..0131b9b2

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12645&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12645&range=01-02

  Stats: 3 lines in 1 file changed: 0 ins; 1 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/12645.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12645/head:pull/12645

PR: https://git.openjdk.org/jdk/pull/12645

From duke at openjdk.org  Fri Feb 24 16:04:38 2023
From: duke at openjdk.org (Archie L. Cobbs)
Date: Fri, 24 Feb 2023 16:04:38 GMT
Subject: RFR: 8026369: javac potentially ambiguous overload warning needs
 an improved scheme [v2]
In-Reply-To: <tk3D21HgO9mRKLEvFHiLSqUPBqCBn483UBY8vu_Mb8E=.e9a261cb-752b-420e-967e-fbf09d8ab65b@github.com>
References: <IMxp3iCK--jYJ5Ia04i6QPYfnCHQobVcsmlI5aJXdqc=.892abcb8-7f2a-4fe9-aea2-1b1d41098a6d@github.com>
 <NlqhxTe-Li08DSIjyYVn5HI9uIAvIHZE4IG0x8tQTQw=.0ae9928e-7814-4356-bf75-11bc4eefc6be@github.com>
 <tk3D21HgO9mRKLEvFHiLSqUPBqCBn483UBY8vu_Mb8E=.e9a261cb-752b-420e-967e-fbf09d8ab65b@github.com>
Message-ID: <i1Dp-1K3ywedPnomS8q3-OWhpV_UJ5-th915f_TfKpg=.4c83976e-cedf-4a92-ba70-a64473a249b3@github.com>

On Fri, 24 Feb 2023 11:49:55 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> I think a CSR is needed as we will be generating more warnings and projects compiling with -Werror could see compilation errors

Will do - thanks.

> src/jdk.compiler/share/classes/com/sun/tools/javac/code/Flags.java line 280:
> 
>> 278:      * Currently available.
>> 279:      */
>> 280:     public static final long UNUSED_1 = 1L<<48;
> 
> what about just adding the comment saying that this spot is free without declaring an unused flag?

Works for me - as long as it's OK that this will cause the `Flags` enum constant ordinals to renumber after that point.

Fixed in 0131b9b23a2.

-------------

PR: https://git.openjdk.org/jdk/pull/12645

From duke at openjdk.org  Fri Feb 24 16:08:57 2023
From: duke at openjdk.org (Viktor Klang)
Date: Fri, 24 Feb 2023 16:08:57 GMT
Subject: RFR: JDK-8297605 DelayQueue javadoc is confusing [v2]
In-Reply-To: <jdJ46gB5VbY2LPrH7oGbtCtU65HGtd7GZ7SB8InbG-A=.8679db0c-28b2-4665-ab92-e89af0ad38e6@github.com>
References: <jdJ46gB5VbY2LPrH7oGbtCtU65HGtd7GZ7SB8InbG-A=.8679db0c-28b2-4665-ab92-e89af0ad38e6@github.com>
Message-ID: <AjDnqfwvtOh_qfmB-9JifK1aS0X0Sw5tU79hL-UPGGE=.c2b74002-56a2-4fe8-879f-f11ce8e7b87a@github.com>

> Clarifies the distinction between expiration of the head of DelayQueue and how it relates to `poll`, `take`, and `peek`. See discussion on https://bugs.openjdk.org/browse/JDK-8297605
> 
> @DougLea If possible, please weigh in on whether this is in line with your thoughts on the matter.

Viktor Klang 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 one additional commit since the last revision:

  JDK-8297605 DelayQueue javadoc is confusing

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12729/files
  - new: https://git.openjdk.org/jdk/pull/12729/files/6ef82915..df54e8a7

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12729&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12729&range=00-01

  Stats: 519072 lines in 8393 files changed: 252325 ins; 163470 del; 103277 mod
  Patch: https://git.openjdk.org/jdk/pull/12729.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12729/head:pull/12729

PR: https://git.openjdk.org/jdk/pull/12729

From duke at openjdk.org  Fri Feb 24 16:16:51 2023
From: duke at openjdk.org (David M. Lloyd)
Date: Fri, 24 Feb 2023 16:16:51 GMT
Subject: RFR: 8292914: Drop the counter from lambda class names [v10]
In-Reply-To: <GgLfH-ueBQqT-Mfk1mKpKFAt8fYqyjfVJ9lmlsBsCbo=.8dd5b3b4-4e84-4970-9179-1c0399b30edc@github.com>
References: <GgLfH-ueBQqT-Mfk1mKpKFAt8fYqyjfVJ9lmlsBsCbo=.8dd5b3b4-4e84-4970-9179-1c0399b30edc@github.com>
Message-ID: <SRAOJEAfx--pehiYP3v1MzWkAmSNOQIqvQbDV2uzACc=.d5b9f558-5089-4db1-bcf0-c6174ff13848@github.com>

> The class generated for lambda proxies is now defined as a hidden class. This means that the counter, which was used to ensure a unique class name and avoid clashes, is now redundant. In addition to performing redundant work, this also impacts build reproducibility for native image generators which might already have a strategy to cope with hidden classes but cannot cope with indeterminate definition order for lambda proxy classes.
> 
> This solves JDK-8292914 by making lambda proxy names always be stable without any configuration needed. This would also replace #10024.

David M. Lloyd has updated the pull request incrementally with one additional commit since the last revision:

  Remove final keyword

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12579/files
  - new: https://git.openjdk.org/jdk/pull/12579/files/a4261e30..92300092

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12579&range=09
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12579&range=08-09

  Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/12579.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12579/head:pull/12579

PR: https://git.openjdk.org/jdk/pull/12579

From mchung at openjdk.org  Fri Feb 24 16:16:51 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Fri, 24 Feb 2023 16:16:51 GMT
Subject: RFR: 8292914: Drop the counter from lambda class names [v10]
In-Reply-To: <SRAOJEAfx--pehiYP3v1MzWkAmSNOQIqvQbDV2uzACc=.d5b9f558-5089-4db1-bcf0-c6174ff13848@github.com>
References: <GgLfH-ueBQqT-Mfk1mKpKFAt8fYqyjfVJ9lmlsBsCbo=.8dd5b3b4-4e84-4970-9179-1c0399b30edc@github.com>
 <SRAOJEAfx--pehiYP3v1MzWkAmSNOQIqvQbDV2uzACc=.d5b9f558-5089-4db1-bcf0-c6174ff13848@github.com>
Message-ID: <ops6EdfH0rXK2slUC8bON_AnCBNuAnDD33-4RQI4OwI=.9215a2b5-c32f-41a4-a2bf-0060bfb2f10f@github.com>

On Fri, 24 Feb 2023 16:12:29 GMT, David M. Lloyd <duke at openjdk.org> wrote:

>> The class generated for lambda proxies is now defined as a hidden class. This means that the counter, which was used to ensure a unique class name and avoid clashes, is now redundant. In addition to performing redundant work, this also impacts build reproducibility for native image generators which might already have a strategy to cope with hidden classes but cannot cope with indeterminate definition order for lambda proxy classes.
>> 
>> This solves JDK-8292914 by making lambda proxy names always be stable without any configuration needed. This would also replace #10024.
>
> David M. Lloyd has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove final keyword

Marked as reviewed by mchung (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/12579

From duke at openjdk.org  Fri Feb 24 16:30:08 2023
From: duke at openjdk.org (Viktor Klang)
Date: Fri, 24 Feb 2023 16:30:08 GMT
Subject: RFR: 8302590: Add String.indexOf(int ch, int fromIndex,
 int toIndex)
In-Reply-To: <KkniribyGhakYm9e1Az7zRXcODJrtqo1aMGP4zIHOA8=.efd150ff-69d3-4a5e-805d-4a93331524bb@github.com>
References: <uQ65oRaVDfpzm9bYRuo_MvSuZIdepicE3GnB3Omyngs=.fc23545b-141a-47e5-8a6a-aa28ae1375e5@github.com>
 <Ba1-pAPv01x8R5a7Xs28vdw-Y5WZ8bn253t1lcPF8WU=.cbf398ba-75d6-4ba1-a395-622f3e3a25d7@github.com>
 <T0UAk-Qz9RBzYl_R3eePcwtT7uW7TCMg0PrNB7xcGis=.2261b886-16a2-43a9-a0e8-66997dee19c1@github.com>
 <KkniribyGhakYm9e1Az7zRXcODJrtqo1aMGP4zIHOA8=.efd150ff-69d3-4a5e-805d-4a93331524bb@github.com>
Message-ID: <I_429Bp7gRzXX3CkgAdkwlt3ja0UhzbQTklHBV_Jkfk=.fdf018e6-13ec-4c67-9718-2afc1ceabab9@github.com>

On Fri, 24 Feb 2023 15:32:34 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> I simply extrapolated the behavior from `indexOf(int ch,int fromIndex), which has a similar note:
>> 
>>      * There is no restriction on the value of {@code fromIndex}. If it
>>      * is negative, it has the same effect as if it were zero: this entire
>>      * string may be searched. If it is greater than the length of this
>>      * string, it has the same effect as if it were equal to the length of
>>      * this string: {@code -1} is returned.
>
> This is the behavior of the underlying implementation as well.

Personally I would expect `string.substring(fromIndex, toIndex).indexOf(ch)` to behave isomorphically to `string.indexOf(ch, fromIndex, toIndex)`

-------------

PR: https://git.openjdk.org/jdk/pull/12600

From bpb at openjdk.org  Fri Feb 24 16:35:20 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 24 Feb 2023 16:35:20 GMT
Subject: RFR: 8302806: (fs) Remove
 com.sun.nio.file.SensitivityWatchEventModifier [v6]
In-Reply-To: <FZn8ZF4sN5mtUO8MWPaC0N8nWFwTLkBvcqQeOPwVYeE=.a6e12227-dfa9-4817-adbb-bece72445860@github.com>
References: <FZn8ZF4sN5mtUO8MWPaC0N8nWFwTLkBvcqQeOPwVYeE=.a6e12227-dfa9-4817-adbb-bece72445860@github.com>
Message-ID: <_tucL0gZWMD_bfK_V_jWEunl70NNdP9hH1fxLUrTZ9A=.a928ff9f-7a5d-4482-8ce6-a487f9b03676@github.com>

> This enum is not used in the JDK and did not appear in external source code searches.

Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:

  8302806: s/modifiers != null/modifiers.length > 0/

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12626/files
  - new: https://git.openjdk.org/jdk/pull/12626/files/20c9ced3..c6e3cf96

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12626&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12626&range=04-05

  Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/12626.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12626/head:pull/12626

PR: https://git.openjdk.org/jdk/pull/12626

From rgiulietti at openjdk.org  Fri Feb 24 16:41:16 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Fri, 24 Feb 2023 16:41:16 GMT
Subject: RFR: 8302590: Add String.indexOf(int ch, int fromIndex,
 int toIndex)
In-Reply-To: <I_429Bp7gRzXX3CkgAdkwlt3ja0UhzbQTklHBV_Jkfk=.fdf018e6-13ec-4c67-9718-2afc1ceabab9@github.com>
References: <uQ65oRaVDfpzm9bYRuo_MvSuZIdepicE3GnB3Omyngs=.fc23545b-141a-47e5-8a6a-aa28ae1375e5@github.com>
 <Ba1-pAPv01x8R5a7Xs28vdw-Y5WZ8bn253t1lcPF8WU=.cbf398ba-75d6-4ba1-a395-622f3e3a25d7@github.com>
 <T0UAk-Qz9RBzYl_R3eePcwtT7uW7TCMg0PrNB7xcGis=.2261b886-16a2-43a9-a0e8-66997dee19c1@github.com>
 <KkniribyGhakYm9e1Az7zRXcODJrtqo1aMGP4zIHOA8=.efd150ff-69d3-4a5e-805d-4a93331524bb@github.com>
 <I_429Bp7gRzXX3CkgAdkwlt3ja0UhzbQTklHBV_Jkfk=.fdf018e6-13ec-4c67-9718-2afc1ceabab9@github.com>
Message-ID: <9peQfBSWnJ5Dckv--IE5H0xpIc9GHiaLMhWz7uXCmi4=.b1b77e72-913c-4837-8497-92f1f8d7166a@github.com>

On Fri, 24 Feb 2023 16:27:10 GMT, Viktor Klang <duke at openjdk.org> wrote:

>> This is the behavior of the underlying implementation as well.
>
> Personally I would expect `string.substring(fromIndex, toIndex).indexOf(ch)` to behave isomorphically to `string.indexOf(ch, fromIndex, toIndex)`

Then you would also expect `string.substring(fromIndex).indexOf(ch)` to behave isomorphically to `string.indexOf(ch, fromIndex)` in current releases, right?
It does not.

-------------

PR: https://git.openjdk.org/jdk/pull/12600

From rgiulietti at openjdk.org  Fri Feb 24 16:41:18 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Fri, 24 Feb 2023 16:41:18 GMT
Subject: RFR: 8302590: Add String.indexOf(int ch, int fromIndex,
 int toIndex)
In-Reply-To: <9peQfBSWnJ5Dckv--IE5H0xpIc9GHiaLMhWz7uXCmi4=.b1b77e72-913c-4837-8497-92f1f8d7166a@github.com>
References: <uQ65oRaVDfpzm9bYRuo_MvSuZIdepicE3GnB3Omyngs=.fc23545b-141a-47e5-8a6a-aa28ae1375e5@github.com>
 <Ba1-pAPv01x8R5a7Xs28vdw-Y5WZ8bn253t1lcPF8WU=.cbf398ba-75d6-4ba1-a395-622f3e3a25d7@github.com>
 <T0UAk-Qz9RBzYl_R3eePcwtT7uW7TCMg0PrNB7xcGis=.2261b886-16a2-43a9-a0e8-66997dee19c1@github.com>
 <KkniribyGhakYm9e1Az7zRXcODJrtqo1aMGP4zIHOA8=.efd150ff-69d3-4a5e-805d-4a93331524bb@github.com>
 <I_429Bp7gRzXX3CkgAdkwlt3ja0UhzbQTklHBV_Jkfk=.fdf018e6-13ec-4c67-9718-2afc1ceabab9@github.com>
 <9peQfBSWnJ5Dckv--IE5H0xpIc9GHiaLMhWz7uXCmi4=.b1b77e72-913c-4837-8497-92f1f8d7166a@github.com>
Message-ID: <ipjMvvgPying2FuiSAOLxIDs13CnCyTOTPZ9NMYcwVM=.856a38dc-218f-4579-9986-ef3fb652b6d9@github.com>

On Fri, 24 Feb 2023 16:35:25 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> Personally I would expect `string.substring(fromIndex, toIndex).indexOf(ch)` to behave isomorphically to `string.indexOf(ch, fromIndex, toIndex)`
>
> Then you would also expect `string.substring(fromIndex).indexOf(ch)` to behave isomorphically to `string.indexOf(ch, fromIndex)` in current releases, right?
> It does not.

(I guess you are referring to the fact that `substring()` can throw.)

-------------

PR: https://git.openjdk.org/jdk/pull/12600

From igraves at openjdk.org  Fri Feb 24 17:12:23 2023
From: igraves at openjdk.org (Ian Graves)
Date: Fri, 24 Feb 2023 17:12:23 GMT
Subject: RFR: 8293667: Align jlink's --compress option with jmod's
 --compress option [v15]
In-Reply-To: <JWevwHuR2vF3k-JRxmTAxfNN6g-EBkgG2N9DHn4fkGY=.f9768dfd-cab4-49a9-83b9-d77a1572e917@github.com>
References: <JWevwHuR2vF3k-JRxmTAxfNN6g-EBkgG2N9DHn4fkGY=.f9768dfd-cab4-49a9-83b9-d77a1572e917@github.com>
Message-ID: <TiAl8GHJiNbI-2FFigDlpLIWUprjv4f_X3ViZscpKKE=.0a1f05e9-bfcf-4e38-bfab-a98ce9a9ca14@github.com>

> This is an approach to adding a flag to jlink that will allow --compress to take the same types of arguments as jmod, thus bringing the two into alignment. This likely requires a CSR and a discussion on whether we should deprecate or simply remove the original numeric compression arguments.

Ian Graves has updated the pull request incrementally with one additional commit since the last revision:

  s/from/in

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/11617/files
  - new: https://git.openjdk.org/jdk/pull/11617/files/186e0224..05841fb5

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11617&range=14
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11617&range=13-14

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/11617.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11617/head:pull/11617

PR: https://git.openjdk.org/jdk/pull/11617

From igraves at openjdk.org  Fri Feb 24 17:12:27 2023
From: igraves at openjdk.org (Ian Graves)
Date: Fri, 24 Feb 2023 17:12:27 GMT
Subject: RFR: 8293667: Align jlink's --compress option with jmod's
 --compress option [v14]
In-Reply-To: <4Ba3xL_HbguCcDjHq_6oXitRzsQ11x68lLMTG4i1aWE=.15162423-12aa-4634-8b2e-6c1a7f1656ac@github.com>
References: <JWevwHuR2vF3k-JRxmTAxfNN6g-EBkgG2N9DHn4fkGY=.f9768dfd-cab4-49a9-83b9-d77a1572e917@github.com>
 <LAsRVWPz8-wHHcHLHNvh46nJxxc7ZwjUmAFZNL9xdU0=.2e34661d-60f9-4f62-9c45-23517bde3389@github.com>
 <4Ba3xL_HbguCcDjHq_6oXitRzsQ11x68lLMTG4i1aWE=.15162423-12aa-4634-8b2e-6c1a7f1656ac@github.com>
Message-ID: <l2td_SMJzB1LSTWjGgsKZLyL8IiEm80UE9Gu8Df1zaY=.d2747a3d-382c-40ae-ad06-59778b027ecc@github.com>

On Fri, 24 Feb 2023 03:52:31 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> Ian Graves has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Additional cleanup
>
> src/jdk.jlink/share/classes/jdk/tools/jlink/resources/plugins.properties line 74:
> 
>> 72: 
>> 73: compress.warn.argumentdeprecated=\
>> 74: Warning: The {0} argument for --compress is deprecated and may be removed from a future release
> 
> Suggestion:
> 
> Warning: The {0} argument for --compress is deprecated and may be removed in a future release
> 
> 
> Sorry missed this in the previous round.  `s/from/in`

Got it!

-------------

PR: https://git.openjdk.org/jdk/pull/11617

From naoto at openjdk.org  Fri Feb 24 17:23:25 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 24 Feb 2023 17:23:25 GMT
Subject: RFR: 8301119: Support for GB18030-2022 [v4]
In-Reply-To: <FXBchbCnbNloQO7Nlh9Ijue_c_YugGk-UC7_-ZAjY2o=.7e1ca01f-8cee-40bb-bb06-6e5670abe661@github.com>
References: <FXBchbCnbNloQO7Nlh9Ijue_c_YugGk-UC7_-ZAjY2o=.7e1ca01f-8cee-40bb-bb06-6e5670abe661@github.com>
Message-ID: <-1jawaJzkA_7STPSnbSTZ6O6CgZi4UJa70D-UlkzgGE=.3386f1b5-ab83-4cad-89fa-9313fa3cbf8f@github.com>

> Upgrading the GB18030 charset in the JDK to the latest 2022 standard. Since this is not a compatible upgrade to the existing mapping, a new system property `jdk.charset.GB18030` is introduced. If it is set to "2000", the mapping falls back to the existing mapping based on the 2000 standard, otherwise, it defaults to 2022 mapping. Refer to the corresponding CSR for more detail.

Naoto Sato has updated the pull request incrementally with two additional commits since the last revision:

 - Failed to add the file itself
 - Changed GB18030 from extcs template to stdcs source

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12518/files
  - new: https://git.openjdk.org/jdk/pull/12518/files/4d4015a9..9732e6c8

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12518&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12518&range=02-03

  Stats: 3 lines in 2 files changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/12518.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12518/head:pull/12518

PR: https://git.openjdk.org/jdk/pull/12518

From naoto at openjdk.org  Fri Feb 24 17:23:26 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 24 Feb 2023 17:23:26 GMT
Subject: RFR: 8301119: Support for GB18030-2022 [v3]
In-Reply-To: <U-4zjhKODj0JRTHSx_FChBEHLABanbxFBr9nmvg8Vks=.f25ff406-6bcc-4376-ac89-609ae5affd32@github.com>
References: <FXBchbCnbNloQO7Nlh9Ijue_c_YugGk-UC7_-ZAjY2o=.7e1ca01f-8cee-40bb-bb06-6e5670abe661@github.com>
 <DbcSeT1d1ulLxFGuScNUYOimyD_bbHn9miPe9TvlSH8=.a10fd674-22b4-4d6b-ac97-3772babbcd3d@github.com>
 <U-4zjhKODj0JRTHSx_FChBEHLABanbxFBr9nmvg8Vks=.f25ff406-6bcc-4376-ac89-609ae5affd32@github.com>
Message-ID: <ItbPT4G9FTT2V3dUBPOY6PGOQmidBqQYrfvoWW29JgY=.2cbc927a-04ab-47ee-a5bb-3c6e488190c3@github.com>

On Fri, 24 Feb 2023 08:34:48 GMT, Ichiroh Takiguchi <itakiguchi at openjdk.org> wrote:

> Hello @naotoj . Sorry for bothering you.
> 
> I have following question:
> 
> * Why GB18030.java.template is in src/jdk.charsets/share/classes/sun/nio/cs/ext/ directory even if the generated code is always stored into sun/nio/cs ?
>   I think the file should be moved to src/java.base/share/classes/sun/nio/cs and the file name should be GB18030.java instead of GB18030.java.template.
>   Is there specific reason ?

No, there is not. Thanks for pointing it out. Fixed.

-------------

PR: https://git.openjdk.org/jdk/pull/12518

From mchung at openjdk.org  Fri Feb 24 17:32:12 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Fri, 24 Feb 2023 17:32:12 GMT
Subject: RFR: 8293667: Align jlink's --compress option with jmod's
 --compress option [v15]
In-Reply-To: <TiAl8GHJiNbI-2FFigDlpLIWUprjv4f_X3ViZscpKKE=.0a1f05e9-bfcf-4e38-bfab-a98ce9a9ca14@github.com>
References: <JWevwHuR2vF3k-JRxmTAxfNN6g-EBkgG2N9DHn4fkGY=.f9768dfd-cab4-49a9-83b9-d77a1572e917@github.com>
 <TiAl8GHJiNbI-2FFigDlpLIWUprjv4f_X3ViZscpKKE=.0a1f05e9-bfcf-4e38-bfab-a98ce9a9ca14@github.com>
Message-ID: <cPnL7_QqI1pVkTkFw6-Adlu9gnGJJF5qkkttiCJreFU=.3aacadcb-309e-4eab-adc0-1c8e743ff77a@github.com>

On Fri, 24 Feb 2023 17:12:23 GMT, Ian Graves <igraves at openjdk.org> wrote:

>> This is an approach to adding a flag to jlink that will allow --compress to take the same types of arguments as jmod, thus bringing the two into alignment. This likely requires a CSR and a discussion on whether we should deprecate or simply remove the original numeric compression arguments.
>
> Ian Graves has updated the pull request incrementally with one additional commit since the last revision:
> 
>   s/from/in

Marked as reviewed by mchung (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/11617

From rgiulietti at openjdk.org  Fri Feb 24 17:45:23 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Fri, 24 Feb 2023 17:45:23 GMT
Subject: RFR: 8302590: Add String.indexOf(int ch, int fromIndex,
 int toIndex) [v2]
In-Reply-To: <uQ65oRaVDfpzm9bYRuo_MvSuZIdepicE3GnB3Omyngs=.fc23545b-141a-47e5-8a6a-aa28ae1375e5@github.com>
References: <uQ65oRaVDfpzm9bYRuo_MvSuZIdepicE3GnB3Omyngs=.fc23545b-141a-47e5-8a6a-aa28ae1375e5@github.com>
Message-ID: <IbVMINZH95lDqPcyPdQuUQN5jHa068aDF6RUFa8LZKA=.df6b9e9e-1080-488b-8518-73a77b3d4028@github.com>

> Add an `indexOf()` variant allowing to specify both a lower and an upper bound on the search.

Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:

  8302590: Add String.indexOf(int ch, int fromIndex, int toIndex)

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12600/files
  - new: https://git.openjdk.org/jdk/pull/12600/files/5e6aedac..fdb39c47

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12600&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12600&range=00-01

  Stats: 20 lines in 3 files changed: 9 ins; 0 del; 11 mod
  Patch: https://git.openjdk.org/jdk/pull/12600.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12600/head:pull/12600

PR: https://git.openjdk.org/jdk/pull/12600

From rgiulietti at openjdk.org  Fri Feb 24 17:45:24 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Fri, 24 Feb 2023 17:45:24 GMT
Subject: RFR: 8302590: Add String.indexOf(int ch, int fromIndex,
 int toIndex) [v2]
In-Reply-To: <e5NTzUo4CgRNg18roWci0Pcd3r9rNOBQc-PHOwct0c8=.ac46d852-0ec6-4a2c-a708-34c9c709089f@github.com>
References: <uQ65oRaVDfpzm9bYRuo_MvSuZIdepicE3GnB3Omyngs=.fc23545b-141a-47e5-8a6a-aa28ae1375e5@github.com>
 <e5NTzUo4CgRNg18roWci0Pcd3r9rNOBQc-PHOwct0c8=.ac46d852-0ec6-4a2c-a708-34c9c709089f@github.com>
Message-ID: <sTIj2d6AOMbSKiyDBO4S6FSTRwLGV_dU-JYaztTJDOw=.3163f958-67be-440d-bde5-56341c4ac981@github.com>

On Thu, 23 Feb 2023 17:04:17 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8302590: Add String.indexOf(int ch, int fromIndex, int toIndex)
>
> src/java.base/share/classes/java/lang/String.java line 2462:
> 
>> 2460:      *
>> 2461:      * <p>There are no restrictions on the value of {@code fromIndex} and
>> 2462:      * {@code toIndex}. Negative values have the same effect as it they were zero.
> 
> "as it" -> "as if"

addressed

-------------

PR: https://git.openjdk.org/jdk/pull/12600

From rgiulietti at openjdk.org  Fri Feb 24 17:45:27 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Fri, 24 Feb 2023 17:45:27 GMT
Subject: RFR: 8302590: Add String.indexOf(int ch, int fromIndex,
 int toIndex) [v2]
In-Reply-To: <BR9EZHJVS9XZJ6dbGGcVIZlr1tI2FgqabVm2k_Eeqqk=.f10d84c2-3fb9-449b-a151-4da09d4757b4@github.com>
References: <uQ65oRaVDfpzm9bYRuo_MvSuZIdepicE3GnB3Omyngs=.fc23545b-141a-47e5-8a6a-aa28ae1375e5@github.com>
 <Ba1-pAPv01x8R5a7Xs28vdw-Y5WZ8bn253t1lcPF8WU=.cbf398ba-75d6-4ba1-a395-622f3e3a25d7@github.com>
 <T0UAk-Qz9RBzYl_R3eePcwtT7uW7TCMg0PrNB7xcGis=.2261b886-16a2-43a9-a0e8-66997dee19c1@github.com>
 <BR9EZHJVS9XZJ6dbGGcVIZlr1tI2FgqabVm2k_Eeqqk=.f10d84c2-3fb9-449b-a151-4da09d4757b4@github.com>
Message-ID: <sQSeI61b4o7oMIT2QlE39Y6i54hAUVj0Xsj6z7XKCkw=.a29b8b1a-ac7d-444f-ae57-8d6868ac42bb@github.com>

On Fri, 24 Feb 2023 15:38:22 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> I was reluctant to add it, as it is not yet known when the PR will be integrated. I'll add it in the next commit.
>
> When the CSR is approved is a good trigger for adding @since.  But its fine to be optimistic in the PR.

addressed

-------------

PR: https://git.openjdk.org/jdk/pull/12600

From rgiulietti at openjdk.org  Fri Feb 24 17:48:11 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Fri, 24 Feb 2023 17:48:11 GMT
Subject: RFR: 8302590: Add String.indexOf(int ch, int fromIndex,
 int toIndex) [v2]
In-Reply-To: <sTIj2d6AOMbSKiyDBO4S6FSTRwLGV_dU-JYaztTJDOw=.3163f958-67be-440d-bde5-56341c4ac981@github.com>
References: <uQ65oRaVDfpzm9bYRuo_MvSuZIdepicE3GnB3Omyngs=.fc23545b-141a-47e5-8a6a-aa28ae1375e5@github.com>
 <e5NTzUo4CgRNg18roWci0Pcd3r9rNOBQc-PHOwct0c8=.ac46d852-0ec6-4a2c-a708-34c9c709089f@github.com>
 <sTIj2d6AOMbSKiyDBO4S6FSTRwLGV_dU-JYaztTJDOw=.3163f958-67be-440d-bde5-56341c4ac981@github.com>
Message-ID: <PcNy8ba-uUNC440TO9rRmcpexbbHGSvYwxhLuR5gRzU=.b11e3cb2-e9ee-496d-a6e0-a52f73af2c7d@github.com>

On Fri, 24 Feb 2023 17:40:52 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/String.java line 2462:
>> 
>>> 2460:      *
>>> 2461:      * <p>There are no restrictions on the value of {@code fromIndex} and
>>> 2462:      * {@code toIndex}. Negative values have the same effect as it they were zero.
>> 
>> "as it" -> "as if"
>
> addressed

JMH does not indicate any performance regression.

W.r.t. renaming Java parameters in `@IntrinsicCandidate` methods, I crosschecked with a runtime compiler guy. He confirms that changing names in the Java implementations is irrelevant for the intrinsified code. There might be references to the names in native comments, but this is not the case for `indexOf`. However, to be on the safe side I reverted those renames back to the original.

-------------

PR: https://git.openjdk.org/jdk/pull/12600

From vromero at openjdk.org  Fri Feb 24 18:05:08 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 24 Feb 2023 18:05:08 GMT
Subject: RFR: 8026369: javac potentially ambiguous overload warning needs
 an improved scheme [v3]
In-Reply-To: <NHHLq4y0LkeQGPPSoHjNOquUU0_iafjmkeFZosjoFPs=.22a5e84f-eaba-4e44-b531-dcd9ea9a92c7@github.com>
References: <IMxp3iCK--jYJ5Ia04i6QPYfnCHQobVcsmlI5aJXdqc=.892abcb8-7f2a-4fe9-aea2-1b1d41098a6d@github.com>
 <NHHLq4y0LkeQGPPSoHjNOquUU0_iafjmkeFZosjoFPs=.22a5e84f-eaba-4e44-b531-dcd9ea9a92c7@github.com>
Message-ID: <ZIdOhXQBODF8-99L-8pXK452tKVwhr6fZ7lHpBafq5w=.91267b20-5a36-4ede-acdb-99898bd958be@github.com>

On Fri, 24 Feb 2023 16:04:38 GMT, Archie L. Cobbs <duke at openjdk.org> wrote:

>> This bug relates to the "potentially ambiguous overload" warning which is enabled by `-Xlint:overloads`.
>> 
>> The warning detects certain ambiguities that can cause problems for lambdas. For example, consider the interface `Spliterator.OfInt`, which declares these two methods:
>> 
>> void forEachRemaining(Consumer<? super Integer> action);
>> void forEachRemaining(IntConsumer action);
>> 
>> Both methods have the same name, same number of parameters, and take a lambda with the same "shape" in the same argument position. This causes an ambiguity in any code that wants to do this:
>> 
>>     spliterator.forEachRemaining(x -> { ... });
>> 
>> That code won't compile; instead, you'll get this error:
>> 
>> Ambiguity.java:4: error: reference to forEachRemaining is ambiguous
>>         spliterator.forEachRemaining(x -> { });
>>                    ^
>>   both method forEachRemaining(IntConsumer) in OfInt and method forEachRemaining(Consumer<? super Integer>) in OfInt match
>> 
>> 
>> The problem reported by the bug is that the warning fails to detect ambiguities which are created purely by inheritance, for example:
>> 
>> interface ConsumerOfInteger {
>>     void foo(Consumer<Integer> c);
>> }
>> 
>> interface IntegerConsumer {
>>     void foo(IntConsumer c);
>> }
>> 
>> // We should get a warning here...
>> interface Test extends ConsumerOfInteger, IntegerConsumer {
>> }
>> 
>> 
>> The cause of the bug is that ambiguities are detected on a per-method basis, by checking whether a method is part of an ambiguity pair when we visit that method. So if the methods in an ambiguity pair are inherited from two distinct supertypes, we'll miss the ambiguity.
>> 
>> To fix the problem, we need to look for ambiguities on a per-class level, checking all pairs of methods. However, it's not that simple - we only want to "blame" a class when that class itself, and not some supertype, is responsible for creating the ambiguity. For example, any interface extending `Spliterator.OfInt` will automatically inherit the two ambiguities mentioned above, but these are not the interface's fault so to speak so no warning should be generated. Making things more complicated is the fact that methods can be overridden and declared in generic classes so they only conflict in some subtypes, etc.
>> 
>> So we generate the warning when there are two methods m1 and m2 in a class C such that:
>> 
>> * m1 and m2 consitiute a "potentially ambiguous overload" (using the same definition as before)
>> * There is no direct supertype T of C such that m1 and m2, or some methods they override, both exist in T and constitute a "potentially ambiguous overload" as members of T
>> * We haven't already generated a warning for either m1 or m2 in class C
>> 
>> If either method is declared in C, we locate the warning there, but when both methods are inherited, there's no method declaration to point at so the warning is instead located at the class declaration.
>> 
>> I noticed a couple of other minor bugs; these are also being fixed here:
>> 
>> (1) For inherited methods, the method signatures were being reported as they are declared, rather than in the context of the class being visited. As a result, when a methods is inherited from a generic supertype, the ambiguity is less clear. Here's an example:
>> 
>> interface Upper<T> {
>>     void foo(T c);
>> }
>> 
>> interface Lower extends Upper<IntConsumer> {
>>     void foo(Consumer<Integer> c);
>> }
>> 
>> Currently, the error is reported as:
>> 
>> warning: [overloads] foo(Consumer<Integer>) in Lower is potentially ambiguous with foo(T) in Upper
>> 
>> Reporting the method signatures in the context of the class being visited makes the ambiguity clearer:
>> 
>> warning: [overloads] foo(Consumer<Integer>) in Lower is potentially ambiguous with foo(IntConsumer) in Upper
>> 
>> 
>> (2) When a method is identified as part of an ambiguous pair, we were setting a `POTENTIALLY_AMBIGUOUS` flag on it. This caused it to be forever excluded from future warnings. For methods that are declared in the class we're visiting, this makes sense, but it doesn't make sense for inherited methods, because it disqualifies them from participating in the analysis of any other class that also inherits them.
>> 
>> As a result, for a class like the one below, the compiler was only generating one warning instead of three:
>> 
>> public interface SuperIface {
>>     void foo(Consumer<Integer> c);
>> }
>> 
>> public interface I1 extends SuperIface { 
>>     void foo(IntConsumer c);        // warning was generated here
>> }   
>> 
>> public interface I2 extends SuperIface { 
>>     void foo(IntConsumer c);        // no warning was generated here
>> }   
>> 
>> public interface I3 extends SuperIface { 
>>     void foo(IntConsumer c);        // no warning was generated here
>> }   
>> 
>> 
>> With this patch the `POTENTIALLY_AMBIGUOUS` flag is no longer needed. I wasn't sure whether to renumber all the subsequent flags, or just leave an empty placeholder, so I chose the latter.
>> 
>> Finally, this fix uncovers new warnings in `java.base` and `java.desktop`, so these are now suppressed in the patch.
>
> Archie L. Cobbs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove placeholder flag UNUSED_1; just leave a comment instead.

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java line 2713:

> 2711:      *  overloads are IntConsumer and Consumer&lt;? super Integer&gt;). So we only want
> 2712:      *  to "blame" a class when that class is itself responsible for creating the
> 2713:      *  ambiguity. So we declare that site is "responsible" for the ambigutity between

typo: ambigutity -> ambiguity

-------------

PR: https://git.openjdk.org/jdk/pull/12645

From duke at openjdk.org  Fri Feb 24 18:09:16 2023
From: duke at openjdk.org (Archie L. Cobbs)
Date: Fri, 24 Feb 2023 18:09:16 GMT
Subject: RFR: 8026369: javac potentially ambiguous overload warning needs
 an improved scheme [v4]
In-Reply-To: <IMxp3iCK--jYJ5Ia04i6QPYfnCHQobVcsmlI5aJXdqc=.892abcb8-7f2a-4fe9-aea2-1b1d41098a6d@github.com>
References: <IMxp3iCK--jYJ5Ia04i6QPYfnCHQobVcsmlI5aJXdqc=.892abcb8-7f2a-4fe9-aea2-1b1d41098a6d@github.com>
Message-ID: <La7IUyuwT43IIKFp8OKW0Wd3iGPnVyvTHyJr00XXq8s=.4b0c537d-1fcd-416a-bd4f-7a1e88466be1@github.com>

> This bug relates to the "potentially ambiguous overload" warning which is enabled by `-Xlint:overloads`.
> 
> The warning detects certain ambiguities that can cause problems for lambdas. For example, consider the interface `Spliterator.OfInt`, which declares these two methods:
> 
> void forEachRemaining(Consumer<? super Integer> action);
> void forEachRemaining(IntConsumer action);
> 
> Both methods have the same name, same number of parameters, and take a lambda with the same "shape" in the same argument position. This causes an ambiguity in any code that wants to do this:
> 
>     spliterator.forEachRemaining(x -> { ... });
> 
> That code won't compile; instead, you'll get this error:
> 
> Ambiguity.java:4: error: reference to forEachRemaining is ambiguous
>         spliterator.forEachRemaining(x -> { });
>                    ^
>   both method forEachRemaining(IntConsumer) in OfInt and method forEachRemaining(Consumer<? super Integer>) in OfInt match
> 
> 
> The problem reported by the bug is that the warning fails to detect ambiguities which are created purely by inheritance, for example:
> 
> interface ConsumerOfInteger {
>     void foo(Consumer<Integer> c);
> }
> 
> interface IntegerConsumer {
>     void foo(IntConsumer c);
> }
> 
> // We should get a warning here...
> interface Test extends ConsumerOfInteger, IntegerConsumer {
> }
> 
> 
> The cause of the bug is that ambiguities are detected on a per-method basis, by checking whether a method is part of an ambiguity pair when we visit that method. So if the methods in an ambiguity pair are inherited from two distinct supertypes, we'll miss the ambiguity.
> 
> To fix the problem, we need to look for ambiguities on a per-class level, checking all pairs of methods. However, it's not that simple - we only want to "blame" a class when that class itself, and not some supertype, is responsible for creating the ambiguity. For example, any interface extending `Spliterator.OfInt` will automatically inherit the two ambiguities mentioned above, but these are not the interface's fault so to speak so no warning should be generated. Making things more complicated is the fact that methods can be overridden and declared in generic classes so they only conflict in some subtypes, etc.
> 
> So we generate the warning when there are two methods m1 and m2 in a class C such that:
> 
> * m1 and m2 consitiute a "potentially ambiguous overload" (using the same definition as before)
> * There is no direct supertype T of C such that m1 and m2, or some methods they override, both exist in T and constitute a "potentially ambiguous overload" as members of T
> * We haven't already generated a warning for either m1 or m2 in class C
> 
> If either method is declared in C, we locate the warning there, but when both methods are inherited, there's no method declaration to point at so the warning is instead located at the class declaration.
> 
> I noticed a couple of other minor bugs; these are also being fixed here:
> 
> (1) For inherited methods, the method signatures were being reported as they are declared, rather than in the context of the class being visited. As a result, when a methods is inherited from a generic supertype, the ambiguity is less clear. Here's an example:
> 
> interface Upper<T> {
>     void foo(T c);
> }
> 
> interface Lower extends Upper<IntConsumer> {
>     void foo(Consumer<Integer> c);
> }
> 
> Currently, the error is reported as:
> 
> warning: [overloads] foo(Consumer<Integer>) in Lower is potentially ambiguous with foo(T) in Upper
> 
> Reporting the method signatures in the context of the class being visited makes the ambiguity clearer:
> 
> warning: [overloads] foo(Consumer<Integer>) in Lower is potentially ambiguous with foo(IntConsumer) in Upper
> 
> 
> (2) When a method is identified as part of an ambiguous pair, we were setting a `POTENTIALLY_AMBIGUOUS` flag on it. This caused it to be forever excluded from future warnings. For methods that are declared in the class we're visiting, this makes sense, but it doesn't make sense for inherited methods, because it disqualifies them from participating in the analysis of any other class that also inherits them.
> 
> As a result, for a class like the one below, the compiler was only generating one warning instead of three:
> 
> public interface SuperIface {
>     void foo(Consumer<Integer> c);
> }
> 
> public interface I1 extends SuperIface { 
>     void foo(IntConsumer c);        // warning was generated here
> }   
> 
> public interface I2 extends SuperIface { 
>     void foo(IntConsumer c);        // no warning was generated here
> }   
> 
> public interface I3 extends SuperIface { 
>     void foo(IntConsumer c);        // no warning was generated here
> }   
> 
> 
> With this patch the `POTENTIALLY_AMBIGUOUS` flag is no longer needed. I wasn't sure whether to renumber all the subsequent flags, or just leave an empty placeholder, so I chose the latter.
> 
> Finally, this fix uncovers new warnings in `java.base` and `java.desktop`, so these are now suppressed in the patch.

Archie L. Cobbs has updated the pull request incrementally with one additional commit since the last revision:

  Fix typo in one comment and clarify another.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12645/files
  - new: https://git.openjdk.org/jdk/pull/12645/files/0131b9b2..49cbaece

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12645&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12645&range=02-03

  Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/12645.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12645/head:pull/12645

PR: https://git.openjdk.org/jdk/pull/12645

From duke at openjdk.org  Fri Feb 24 18:09:18 2023
From: duke at openjdk.org (Archie L. Cobbs)
Date: Fri, 24 Feb 2023 18:09:18 GMT
Subject: RFR: 8026369: javac potentially ambiguous overload warning needs
 an improved scheme [v3]
In-Reply-To: <ZIdOhXQBODF8-99L-8pXK452tKVwhr6fZ7lHpBafq5w=.91267b20-5a36-4ede-acdb-99898bd958be@github.com>
References: <IMxp3iCK--jYJ5Ia04i6QPYfnCHQobVcsmlI5aJXdqc=.892abcb8-7f2a-4fe9-aea2-1b1d41098a6d@github.com>
 <NHHLq4y0LkeQGPPSoHjNOquUU0_iafjmkeFZosjoFPs=.22a5e84f-eaba-4e44-b531-dcd9ea9a92c7@github.com>
 <ZIdOhXQBODF8-99L-8pXK452tKVwhr6fZ7lHpBafq5w=.91267b20-5a36-4ede-acdb-99898bd958be@github.com>
Message-ID: <ZTfQHfbgPpb-Gf14HVgZ1Agepn3pLPFpX9VepraESdQ=.d57d9b83-b5e2-4d3a-abea-0646fed69345@github.com>

On Fri, 24 Feb 2023 18:01:56 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> Archie L. Cobbs has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove placeholder flag UNUSED_1; just leave a comment instead.
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java line 2713:
> 
>> 2711:      *  overloads are IntConsumer and Consumer&lt;? super Integer&gt;). So we only want
>> 2712:      *  to "blame" a class when that class is itself responsible for creating the
>> 2713:      *  ambiguity. So we declare that site is "responsible" for the ambigutity between
> 
> typo: ambigutity -> ambiguity

Thanks - fixed.

-------------

PR: https://git.openjdk.org/jdk/pull/12645

From lancea at openjdk.org  Fri Feb 24 18:14:09 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Fri, 24 Feb 2023 18:14:09 GMT
Subject: RFR: 8301119: Support for GB18030-2022 [v4]
In-Reply-To: <-1jawaJzkA_7STPSnbSTZ6O6CgZi4UJa70D-UlkzgGE=.3386f1b5-ab83-4cad-89fa-9313fa3cbf8f@github.com>
References: <FXBchbCnbNloQO7Nlh9Ijue_c_YugGk-UC7_-ZAjY2o=.7e1ca01f-8cee-40bb-bb06-6e5670abe661@github.com>
 <-1jawaJzkA_7STPSnbSTZ6O6CgZi4UJa70D-UlkzgGE=.3386f1b5-ab83-4cad-89fa-9313fa3cbf8f@github.com>
Message-ID: <NCWMZuJeSCZIJ64fwTHe2VgNC01TtAaxVGeRj8fh-x4=.8249b760-5221-4dfe-96bc-30672a3934c2@github.com>

On Fri, 24 Feb 2023 17:23:25 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Upgrading the GB18030 charset in the JDK to the latest 2022 standard. Since this is not a compatible upgrade to the existing mapping, a new system property `jdk.charset.GB18030` is introduced. If it is set to "2000", the mapping falls back to the existing mapping based on the 2000 standard, otherwise, it defaults to 2022 mapping. Refer to the corresponding CSR for more detail.
>
> Naoto Sato has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Failed to add the file itself
>  - Changed GB18030 from extcs template to stdcs source

Marked as reviewed by lancea (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/12518

From jlu at openjdk.org  Fri Feb 24 18:27:30 2023
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 24 Feb 2023 18:27:30 GMT
Subject: RFR: 8282319: java.util.Locale method to stream available Locales
 [v2]
In-Reply-To: <QxcV7IwdW13WfT0X0PKyWBWpo_rP588AgHIYiUu3E_Q=.82b88828-e8ec-4f3c-a75a-ec88b589d4e2@github.com>
References: <QxcV7IwdW13WfT0X0PKyWBWpo_rP588AgHIYiUu3E_Q=.82b88828-e8ec-4f3c-a75a-ec88b589d4e2@github.com>
Message-ID: <Qy9riGxMB2o0xwjBc1BGcLACNF-bLtMyN657jEqslUA=.eef77647-27bf-41d9-8660-ada00cb5b537@github.com>

> This PR adds a new method to java.util.Locale which returns Stream<Locale>
> 
> The contents of the Stream are composed of the same underlying elements as Locale.getAvailableLocales().
> 
> This method allows streaming of the Locale array without creating a defensive copy.

Justin Lu has updated the pull request incrementally with one additional commit since the last revision:

  Doc adjustments, fix method name in test

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12269/files
  - new: https://git.openjdk.org/jdk/pull/12269/files/6df5c168..b2c08e1c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12269&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12269&range=00-01

  Stats: 10 lines in 3 files changed: 3 ins; 2 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/12269.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12269/head:pull/12269

PR: https://git.openjdk.org/jdk/pull/12269

From bpb at openjdk.org  Fri Feb 24 18:30:49 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 24 Feb 2023 18:30:49 GMT
Subject: RFR: 8303175: (fs) Deprecate
 com.sun.nio.file.SensitivityWatchEventModifier for removal
Message-ID: <s7IRC6buEQ5NrNc4XW3lIf6wpdfBksPrIjuTnTO99Gc=.380f3194-e6e7-4c55-b322-2fff1984cd4a@github.com>

Deprecate `SensitivityWatchEventModifier` for now instead of directly removing it as proposed in #12626.

-------------

Commit messages:
 - 8303175: (fs) Deprecate com.sun.nio.file.SensitivityWatchEventModifier for removal

Changes: https://git.openjdk.org/jdk/pull/12746/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12746&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8303175
  Stats: 8 lines in 1 file changed: 7 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/12746.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12746/head:pull/12746

PR: https://git.openjdk.org/jdk/pull/12746

From naoto at openjdk.org  Fri Feb 24 18:31:13 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 24 Feb 2023 18:31:13 GMT
Subject: RFR: 8282319: java.util.Locale method to stream available Locales
 [v2]
In-Reply-To: <Qy9riGxMB2o0xwjBc1BGcLACNF-bLtMyN657jEqslUA=.eef77647-27bf-41d9-8660-ada00cb5b537@github.com>
References: <QxcV7IwdW13WfT0X0PKyWBWpo_rP588AgHIYiUu3E_Q=.82b88828-e8ec-4f3c-a75a-ec88b589d4e2@github.com>
 <Qy9riGxMB2o0xwjBc1BGcLACNF-bLtMyN657jEqslUA=.eef77647-27bf-41d9-8660-ada00cb5b537@github.com>
Message-ID: <uim67-xLTmMq_Mvk1D4dpZ-NvUX4gRm3QP6J9KWofKY=.0fe2cc7d-a691-4dd9-b59f-198a859db576@github.com>

On Fri, 24 Feb 2023 18:27:30 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> This PR adds a new method to java.util.Locale which returns Stream<Locale>
>> 
>> The contents of the Stream are composed of the same underlying elements as Locale.getAvailableLocales().
>> 
>> This method allows streaming of the Locale array without creating a defensive copy.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Doc adjustments, fix method name in test

Marked as reviewed by naoto (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/12269

From bpb at openjdk.org  Fri Feb 24 18:33:21 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 24 Feb 2023 18:33:21 GMT
Subject: Withdrawn: 8302806: (fs) Remove
 com.sun.nio.file.SensitivityWatchEventModifier
In-Reply-To: <FZn8ZF4sN5mtUO8MWPaC0N8nWFwTLkBvcqQeOPwVYeE=.a6e12227-dfa9-4817-adbb-bece72445860@github.com>
References: <FZn8ZF4sN5mtUO8MWPaC0N8nWFwTLkBvcqQeOPwVYeE=.a6e12227-dfa9-4817-adbb-bece72445860@github.com>
Message-ID: <pV0aTJyoTX3LdJUnK2z0cS4m-__Y_kjWHRHrZuZ8cwM=.8d7fc964-96bc-49ce-abf0-6ed8569e5ea2@github.com>

On Sat, 18 Feb 2023 00:11:29 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> This enum is not used in the JDK and did not appear in external source code searches.

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/12626

From lancea at openjdk.org  Fri Feb 24 18:36:13 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Fri, 24 Feb 2023 18:36:13 GMT
Subject: RFR: 8282319: java.util.Locale method to stream available Locales
 [v2]
In-Reply-To: <Qy9riGxMB2o0xwjBc1BGcLACNF-bLtMyN657jEqslUA=.eef77647-27bf-41d9-8660-ada00cb5b537@github.com>
References: <QxcV7IwdW13WfT0X0PKyWBWpo_rP588AgHIYiUu3E_Q=.82b88828-e8ec-4f3c-a75a-ec88b589d4e2@github.com>
 <Qy9riGxMB2o0xwjBc1BGcLACNF-bLtMyN657jEqslUA=.eef77647-27bf-41d9-8660-ada00cb5b537@github.com>
Message-ID: <3_P5D-o1sd8I3HCikS39S5LhEmmMV6f787wwffkuJQU=.5a8e2eee-2b3d-4904-9665-372e82e584ad@github.com>

On Fri, 24 Feb 2023 18:27:30 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> This PR adds a new method to java.util.Locale which returns Stream<Locale>
>> 
>> The contents of the Stream are composed of the same underlying elements as Locale.getAvailableLocales().
>> 
>> This method allows streaming of the Locale array without creating a defensive copy.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Doc adjustments, fix method name in test

src/java.base/share/classes/sun/util/locale/provider/LocaleServiceProviderPool.java line 155:

> 153:      * that are provided by each provider, including the JRE.
> 154:      *
> 155:      * @return a stream of the available locales for all provider classes

Seems weird to have the @return where you moved it to

-------------

PR: https://git.openjdk.org/jdk/pull/12269

From darcy at openjdk.org  Fri Feb 24 18:36:41 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 24 Feb 2023 18:36:41 GMT
Subject: RFR: JDK-8302040: Port fdlibm sqrt to Java [v2]
In-Reply-To: <rjVM2lWPdsvPcfLF3oNShP-cSN8-P-i16ikUC3sTgIg=.1d4f470d-2ac9-4394-b55e-099affce763f@github.com>
References: <rjVM2lWPdsvPcfLF3oNShP-cSN8-P-i16ikUC3sTgIg=.1d4f470d-2ac9-4394-b55e-099affce763f@github.com>
Message-ID: <QjhfjOwLwuPCwmmdaKNXT7USfeHyefsPb9PsroNG2tE=.57f7e2c7-6194-44cf-a521-55ed51cae52c@github.com>

> The wheel of FDLIBM porting turns a notch and sqrt comes into play.
> 
> While the sqrt operation usually has a hardware implementation that is intrinsified, for completeness a software implementation should be available as well.

Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:

  Respond to review feedback.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12736/files
  - new: https://git.openjdk.org/jdk/pull/12736/files/193f51a6..a6505dee

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12736&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12736&range=00-01

  Stats: 19 lines in 4 files changed: 10 ins; 2 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/12736.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12736/head:pull/12736

PR: https://git.openjdk.org/jdk/pull/12736

From darcy at openjdk.org  Fri Feb 24 18:36:42 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 24 Feb 2023 18:36:42 GMT
Subject: RFR: JDK-8302040: Port fdlibm sqrt to Java [v2]
In-Reply-To: <X1YG4bA78kGZpIOmWV0heVBQhhi8OlgXWhN9-6UkTus=.d1ab64b1-7da4-4701-9aff-1f1ef3ce4509@github.com>
References: <rjVM2lWPdsvPcfLF3oNShP-cSN8-P-i16ikUC3sTgIg=.1d4f470d-2ac9-4394-b55e-099affce763f@github.com>
 <Q9XfwYgplnOvwwf21RZGdEeyjPzTDqMc8LEDt84vOww=.7f42be76-b16d-4a76-80a2-f1fd9f0374c7@github.com>
 <X1YG4bA78kGZpIOmWV0heVBQhhi8OlgXWhN9-6UkTus=.d1ab64b1-7da4-4701-9aff-1f1ef3ce4509@github.com>
Message-ID: <3n1vq-ganpngIqmAbwiRl-V9F-NmrawWVdyAWJPt2B0=.7d05b394-0110-48ce-ada9-7ed2e1fdd193@github.com>

On Fri, 24 Feb 2023 13:19:36 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/FdLibm.java line 689:
>> 
>>> 687:             ix0 += (m << 20);
>>> 688:             z = __HI(z, ix0);
>>> 689:             z = __LO(z, ix1);
>> 
>> I was tempted to rewrite these line as something like:
>> `return Double.longBitsToDouble((long)ix0 << 32 | (long)ix1);`
>> and may do so in a future refactoring.
>
> That should read
> `return Double.longBitsToDouble((long)ix0 << 32 | ix1 & 0xffff_ffffL);`

Added new method to combine high and low. In a future refactoring pass, I'll use the method in other locations in FDLIBM where it is applicable.

-------------

PR: https://git.openjdk.org/jdk/pull/12736

From darcy at openjdk.org  Fri Feb 24 18:36:43 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 24 Feb 2023 18:36:43 GMT
Subject: RFR: JDK-8302040: Port fdlibm sqrt to Java [v2]
In-Reply-To: <sWoL9o59cAFphCT0vYpnL8L5_tFX31ZTN-ogADNn0Bw=.d8a9fdb2-7ebe-4137-a2fe-8bca605dcd66@github.com>
References: <rjVM2lWPdsvPcfLF3oNShP-cSN8-P-i16ikUC3sTgIg=.1d4f470d-2ac9-4394-b55e-099affce763f@github.com>
 <sWoL9o59cAFphCT0vYpnL8L5_tFX31ZTN-ogADNn0Bw=.d8a9fdb2-7ebe-4137-a2fe-8bca605dcd66@github.com>
Message-ID: <WWBHT_pd5odM7pZDZye6ue71CD4fM7ahG5-4kmupF1c=.aaa447c7-2e02-41e9-a78a-213e4622bb2f@github.com>

On Fri, 24 Feb 2023 13:31:10 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Respond to review feedback.
>
> test/jdk/java/lang/StrictMath/ExhaustingTests.java line 71:
> 
>> 69:             // Since sqrt is correctly rounded, could additionaly the
>> 70:             // transliteration or StrictMath sqrt methods to against
>> 71:             // Math::sqrt.
> 
> I guess this comment has been messed up by some copy&paste activities?
> Or is it a ChatGPT output?

Fixed mangled text.

-------------

PR: https://git.openjdk.org/jdk/pull/12736

From darcy at openjdk.org  Fri Feb 24 18:40:38 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 24 Feb 2023 18:40:38 GMT
Subject: RFR: JDK-8302040: Port fdlibm sqrt to Java [v3]
In-Reply-To: <rjVM2lWPdsvPcfLF3oNShP-cSN8-P-i16ikUC3sTgIg=.1d4f470d-2ac9-4394-b55e-099affce763f@github.com>
References: <rjVM2lWPdsvPcfLF3oNShP-cSN8-P-i16ikUC3sTgIg=.1d4f470d-2ac9-4394-b55e-099affce763f@github.com>
Message-ID: <bzR0JfDQW03UtxdHgqbcLHlBQzPvp2NitCM6Y_ENdco=.1a3c47be-ebf8-420f-903b-964e82fafddf@github.com>

> The wheel of FDLIBM porting turns a notch and sqrt comes into play.
> 
> While the sqrt operation usually has a hardware implementation that is intrinsified, for completeness a software implementation should be available as well.

Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:

  Add one one unsigned shift comment.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12736/files
  - new: https://git.openjdk.org/jdk/pull/12736/files/a6505dee..7d39761c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12736&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12736&range=01-02

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/12736.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12736/head:pull/12736

PR: https://git.openjdk.org/jdk/pull/12736

From lancea at openjdk.org  Fri Feb 24 18:45:06 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Fri, 24 Feb 2023 18:45:06 GMT
Subject: RFR: 8303175: (fs) Deprecate
 com.sun.nio.file.SensitivityWatchEventModifier for removal
In-Reply-To: <s7IRC6buEQ5NrNc4XW3lIf6wpdfBksPrIjuTnTO99Gc=.380f3194-e6e7-4c55-b322-2fff1984cd4a@github.com>
References: <s7IRC6buEQ5NrNc4XW3lIf6wpdfBksPrIjuTnTO99Gc=.380f3194-e6e7-4c55-b322-2fff1984cd4a@github.com>
Message-ID: <PGFeWlijBYFfgzAyd98Loi7Izx_mExR7ZOHEdcZ8lv0=.d38e30cb-ae22-4f99-b48b-d440e1a5ec35@github.com>

On Fri, 24 Feb 2023 18:23:06 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Deprecate `SensitivityWatchEventModifier` for now instead of directly removing it as proposed in #12626.

Hi Brian,

I believe we need a CSR for this

-------------

PR: https://git.openjdk.org/jdk/pull/12746

From bpb at openjdk.org  Fri Feb 24 18:45:07 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 24 Feb 2023 18:45:07 GMT
Subject: RFR: 8303175: (fs) Deprecate
 com.sun.nio.file.SensitivityWatchEventModifier for removal
In-Reply-To: <PGFeWlijBYFfgzAyd98Loi7Izx_mExR7ZOHEdcZ8lv0=.d38e30cb-ae22-4f99-b48b-d440e1a5ec35@github.com>
References: <s7IRC6buEQ5NrNc4XW3lIf6wpdfBksPrIjuTnTO99Gc=.380f3194-e6e7-4c55-b322-2fff1984cd4a@github.com>
 <PGFeWlijBYFfgzAyd98Loi7Izx_mExR7ZOHEdcZ8lv0=.d38e30cb-ae22-4f99-b48b-d440e1a5ec35@github.com>
Message-ID: <8Wnq38rdIaD6NY8a2XnaEDYlcS4cN3HVJ-AGsGwKGpM=.0241d3b0-f468-4db9-a807-c708ad5c5565@github.com>

On Fri, 24 Feb 2023 18:40:44 GMT, Lance Andersen <lancea at openjdk.org> wrote:

> I believe we need a CSR for this

@LanceAndersen I concur.

-------------

PR: https://git.openjdk.org/jdk/pull/12746

From naoto at openjdk.org  Fri Feb 24 18:46:13 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 24 Feb 2023 18:46:13 GMT
Subject: RFR: 8282319: java.util.Locale method to stream available Locales
 [v2]
In-Reply-To: <Qy9riGxMB2o0xwjBc1BGcLACNF-bLtMyN657jEqslUA=.eef77647-27bf-41d9-8660-ada00cb5b537@github.com>
References: <QxcV7IwdW13WfT0X0PKyWBWpo_rP588AgHIYiUu3E_Q=.82b88828-e8ec-4f3c-a75a-ec88b589d4e2@github.com>
 <Qy9riGxMB2o0xwjBc1BGcLACNF-bLtMyN657jEqslUA=.eef77647-27bf-41d9-8660-ada00cb5b537@github.com>
Message-ID: <djI8beXFqYHTUAXYKIsvtLlGwXEeQzjSkFyDAnYO_YM=.d2b3965d-2ebb-4c9a-9663-27747e1c56e8@github.com>

On Fri, 24 Feb 2023 18:27:30 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> This PR adds a new method to java.util.Locale which returns Stream<Locale>
>> 
>> The contents of the Stream are composed of the same underlying elements as Locale.getAvailableLocales().
>> 
>> This method allows streaming of the Locale array without creating a defensive copy.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Doc adjustments, fix method name in test

src/java.base/share/classes/sun/util/locale/provider/LocaleServiceProviderPool.java line 153:

> 151:      * {@return a stream of the available locales for all provider classes}
> 152:      *
> 153:      * Returns a stream of available locales for all the provider classes.

This line can be removed

-------------

PR: https://git.openjdk.org/jdk/pull/12269

From jlu at openjdk.org  Fri Feb 24 18:46:16 2023
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 24 Feb 2023 18:46:16 GMT
Subject: RFR: 8282319: java.util.Locale method to stream available Locales
 [v2]
In-Reply-To: <3_P5D-o1sd8I3HCikS39S5LhEmmMV6f787wwffkuJQU=.5a8e2eee-2b3d-4904-9665-372e82e584ad@github.com>
References: <QxcV7IwdW13WfT0X0PKyWBWpo_rP588AgHIYiUu3E_Q=.82b88828-e8ec-4f3c-a75a-ec88b589d4e2@github.com>
 <Qy9riGxMB2o0xwjBc1BGcLACNF-bLtMyN657jEqslUA=.eef77647-27bf-41d9-8660-ada00cb5b537@github.com>
 <3_P5D-o1sd8I3HCikS39S5LhEmmMV6f787wwffkuJQU=.5a8e2eee-2b3d-4904-9665-372e82e584ad@github.com>
Message-ID: <0_zm1BN0d7_M2lQaL8hQovM-L2nm_Y3QsOnGj9y35IM=.3d2333d9-f3a8-413b-ac12-f62b66785ee8@github.com>

On Fri, 24 Feb 2023 18:33:20 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Doc adjustments, fix method name in test
>
> src/java.base/share/classes/sun/util/locale/provider/LocaleServiceProviderPool.java line 155:
> 
>> 153:      * that are provided by each provider, including the JRE.
>> 154:      *
>> 155:      * @return a stream of the available locales for all provider classes
> 
> Seems weird to have the @return where you moved it to

>From what I saw in other methods, `@return ...` goes on the bottom (like the line I removed), but the javadoc 16 tag `{@return ... }` goes on the top.

-------------

PR: https://git.openjdk.org/jdk/pull/12269

From lancea at openjdk.org  Fri Feb 24 18:49:06 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Fri, 24 Feb 2023 18:49:06 GMT
Subject: RFR: 8303175: (fs) Deprecate
 com.sun.nio.file.SensitivityWatchEventModifier for removal
In-Reply-To: <s7IRC6buEQ5NrNc4XW3lIf6wpdfBksPrIjuTnTO99Gc=.380f3194-e6e7-4c55-b322-2fff1984cd4a@github.com>
References: <s7IRC6buEQ5NrNc4XW3lIf6wpdfBksPrIjuTnTO99Gc=.380f3194-e6e7-4c55-b322-2fff1984cd4a@github.com>
Message-ID: <MSz4X-JB5Tl6J9W9HuWFtxUwYxh-glU454fnGtcjWc0=.d83d301a-a5bd-49dc-9d22-07d6ab1f0009@github.com>

On Fri, 24 Feb 2023 18:23:06 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Deprecate `SensitivityWatchEventModifier` for now instead of directly removing it as proposed in #12626.

Marked as reviewed by lancea (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/12746

From jlu at openjdk.org  Fri Feb 24 18:51:44 2023
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 24 Feb 2023 18:51:44 GMT
Subject: RFR: 8282319: java.util.Locale method to stream available Locales
 [v3]
In-Reply-To: <QxcV7IwdW13WfT0X0PKyWBWpo_rP588AgHIYiUu3E_Q=.82b88828-e8ec-4f3c-a75a-ec88b589d4e2@github.com>
References: <QxcV7IwdW13WfT0X0PKyWBWpo_rP588AgHIYiUu3E_Q=.82b88828-e8ec-4f3c-a75a-ec88b589d4e2@github.com>
Message-ID: <XYRPIOUKtpHEtoygnBkKpBrB_RcDsjs4X6U-mwu-9K8=.574c661e-e52a-4c20-becc-8d227f7ba51b@github.com>

> This PR adds a new method to java.util.Locale which returns Stream<Locale>
> 
> The contents of the Stream are composed of the same underlying elements as Locale.getAvailableLocales().
> 
> This method allows streaming of the Locale array without creating a defensive copy.

Justin Lu has updated the pull request incrementally with one additional commit since the last revision:

  Description return no longer needed with {@return ...

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12269/files
  - new: https://git.openjdk.org/jdk/pull/12269/files/b2c08e1c..b4d0ceff

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12269&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12269&range=01-02

  Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/12269.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12269/head:pull/12269

PR: https://git.openjdk.org/jdk/pull/12269

From lancea at openjdk.org  Fri Feb 24 19:01:15 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Fri, 24 Feb 2023 19:01:15 GMT
Subject: RFR: 8282319: java.util.Locale method to stream available Locales
 [v3]
In-Reply-To: <0_zm1BN0d7_M2lQaL8hQovM-L2nm_Y3QsOnGj9y35IM=.3d2333d9-f3a8-413b-ac12-f62b66785ee8@github.com>
References: <QxcV7IwdW13WfT0X0PKyWBWpo_rP588AgHIYiUu3E_Q=.82b88828-e8ec-4f3c-a75a-ec88b589d4e2@github.com>
 <Qy9riGxMB2o0xwjBc1BGcLACNF-bLtMyN657jEqslUA=.eef77647-27bf-41d9-8660-ada00cb5b537@github.com>
 <3_P5D-o1sd8I3HCikS39S5LhEmmMV6f787wwffkuJQU=.5a8e2eee-2b3d-4904-9665-372e82e584ad@github.com>
 <0_zm1BN0d7_M2lQaL8hQovM-L2nm_Y3QsOnGj9y35IM=.3d2333d9-f3a8-413b-ac12-f62b66785ee8@github.com>
Message-ID: <Y-8deBLWqXedPstR9iVGr-CxLyxriwsEbhdMBddNNME=.09b2307f-1672-49b2-a5f9-f529df906d21@github.com>

On Fri, 24 Feb 2023 18:39:55 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> src/java.base/share/classes/sun/util/locale/provider/LocaleServiceProviderPool.java line 155:
>> 
>>> 153:      * that are provided by each provider, including the JRE.
>>> 154:      *
>>> 155:      * @return a stream of the available locales for all provider classes
>> 
>> Seems weird to have the @return where you moved it to
>
> From what I saw in other methods, `@return ...` goes on the bottom (like the line I removed), but the javadoc 16 tag `{@return ... }` goes on the top.

OK but then we should be consistent and update all of the methods to use the new tag or  revert the change for consistency

-------------

PR: https://git.openjdk.org/jdk/pull/12269

From kvn at openjdk.org  Fri Feb 24 19:03:09 2023
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Fri, 24 Feb 2023 19:03:09 GMT
Subject: RFR: 8143900: OptimizeStringConcat has an opaque dependency on
 Integer.sizeTable field [v2]
In-Reply-To: <upouJcFH3Uw0SXK1OZHRgx5X_fQy9ZI2MbdkjrtjsKs=.c382dad7-a3a7-48f1-a493-db4a2ea80849@github.com>
References: <wVJP9KUVBORqE2Y2rPoPzePyKqbUTiE6fKiS1iOw9j4=.91a2c4c5-6da7-461e-8d65-d6e41bb5f4ff@github.com>
 <upouJcFH3Uw0SXK1OZHRgx5X_fQy9ZI2MbdkjrtjsKs=.c382dad7-a3a7-48f1-a493-db4a2ea80849@github.com>
Message-ID: <Ec2neRPED-vnTgHvxgHTb91EYn1p3A65kd1bhQLbcSQ=.86e15f2e-c634-427b-b943-9594c378c3bd@github.com>

On Fri, 24 Feb 2023 10:19:49 GMT, Yi Yang <yyang at openjdk.org> wrote:

>> Hi, can I have a review for this patch? I noticed a strange field Integer.sizeTable which is used by PhaseStringOpts, after digging into the history, I think it could be replaced by an in-place array allocation and initialization. Before it, we are fetching from Integer.sizeTable and get num of digit in integer by iterating size table, now we fetch from in-place sizeTable and get size from that. The changed IR looks like this:
>> 
>> ![image](https://user-images.githubusercontent.com/5010047/220239446-7b8b8381-b300-4f2c-a24a-aa19ec9e2f88.png)
>> 
>> Thanks.
>
> Yi Yang has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - whitespace
>  - mirror or Integer.stringSize
>  - mirror or Integer.stringSize

Code looks reasonable and matches `Integer.stringSize()` method. I will test it.

src/hotspot/share/opto/stringopts.cpp line 1163:

> 1161: }
> 1162: 
> 1163: // Mirror of Integer.stringSize, return the count of digits in integer,

`Integer.stringSize() method`

-------------

PR: https://git.openjdk.org/jdk/pull/12680

From vromero at openjdk.org  Fri Feb 24 19:04:07 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 24 Feb 2023 19:04:07 GMT
Subject: RFR: 8026369: javac potentially ambiguous overload warning needs
 an improved scheme [v3]
In-Reply-To: <NHHLq4y0LkeQGPPSoHjNOquUU0_iafjmkeFZosjoFPs=.22a5e84f-eaba-4e44-b531-dcd9ea9a92c7@github.com>
References: <IMxp3iCK--jYJ5Ia04i6QPYfnCHQobVcsmlI5aJXdqc=.892abcb8-7f2a-4fe9-aea2-1b1d41098a6d@github.com>
 <NHHLq4y0LkeQGPPSoHjNOquUU0_iafjmkeFZosjoFPs=.22a5e84f-eaba-4e44-b531-dcd9ea9a92c7@github.com>
Message-ID: <98kTDWOcTYL9jRLZQhDXFjPmHQJQPZg8tGuUhi0Iwlk=.b91510cc-5e55-4090-919f-a5a5cc5b2347@github.com>

On Fri, 24 Feb 2023 16:04:38 GMT, Archie L. Cobbs <duke at openjdk.org> wrote:

>> This bug relates to the "potentially ambiguous overload" warning which is enabled by `-Xlint:overloads`.
>> 
>> The warning detects certain ambiguities that can cause problems for lambdas. For example, consider the interface `Spliterator.OfInt`, which declares these two methods:
>> 
>> void forEachRemaining(Consumer<? super Integer> action);
>> void forEachRemaining(IntConsumer action);
>> 
>> Both methods have the same name, same number of parameters, and take a lambda with the same "shape" in the same argument position. This causes an ambiguity in any code that wants to do this:
>> 
>>     spliterator.forEachRemaining(x -> { ... });
>> 
>> That code won't compile; instead, you'll get this error:
>> 
>> Ambiguity.java:4: error: reference to forEachRemaining is ambiguous
>>         spliterator.forEachRemaining(x -> { });
>>                    ^
>>   both method forEachRemaining(IntConsumer) in OfInt and method forEachRemaining(Consumer<? super Integer>) in OfInt match
>> 
>> 
>> The problem reported by the bug is that the warning fails to detect ambiguities which are created purely by inheritance, for example:
>> 
>> interface ConsumerOfInteger {
>>     void foo(Consumer<Integer> c);
>> }
>> 
>> interface IntegerConsumer {
>>     void foo(IntConsumer c);
>> }
>> 
>> // We should get a warning here...
>> interface Test extends ConsumerOfInteger, IntegerConsumer {
>> }
>> 
>> 
>> The cause of the bug is that ambiguities are detected on a per-method basis, by checking whether a method is part of an ambiguity pair when we visit that method. So if the methods in an ambiguity pair are inherited from two distinct supertypes, we'll miss the ambiguity.
>> 
>> To fix the problem, we need to look for ambiguities on a per-class level, checking all pairs of methods. However, it's not that simple - we only want to "blame" a class when that class itself, and not some supertype, is responsible for creating the ambiguity. For example, any interface extending `Spliterator.OfInt` will automatically inherit the two ambiguities mentioned above, but these are not the interface's fault so to speak so no warning should be generated. Making things more complicated is the fact that methods can be overridden and declared in generic classes so they only conflict in some subtypes, etc.
>> 
>> So we generate the warning when there are two methods m1 and m2 in a class C such that:
>> 
>> * m1 and m2 consitiute a "potentially ambiguous overload" (using the same definition as before)
>> * There is no direct supertype T of C such that m1 and m2, or some methods they override, both exist in T and constitute a "potentially ambiguous overload" as members of T
>> * We haven't already generated a warning for either m1 or m2 in class C
>> 
>> If either method is declared in C, we locate the warning there, but when both methods are inherited, there's no method declaration to point at so the warning is instead located at the class declaration.
>> 
>> I noticed a couple of other minor bugs; these are also being fixed here:
>> 
>> (1) For inherited methods, the method signatures were being reported as they are declared, rather than in the context of the class being visited. As a result, when a methods is inherited from a generic supertype, the ambiguity is less clear. Here's an example:
>> 
>> interface Upper<T> {
>>     void foo(T c);
>> }
>> 
>> interface Lower extends Upper<IntConsumer> {
>>     void foo(Consumer<Integer> c);
>> }
>> 
>> Currently, the error is reported as:
>> 
>> warning: [overloads] foo(Consumer<Integer>) in Lower is potentially ambiguous with foo(T) in Upper
>> 
>> Reporting the method signatures in the context of the class being visited makes the ambiguity clearer:
>> 
>> warning: [overloads] foo(Consumer<Integer>) in Lower is potentially ambiguous with foo(IntConsumer) in Upper
>> 
>> 
>> (2) When a method is identified as part of an ambiguous pair, we were setting a `POTENTIALLY_AMBIGUOUS` flag on it. This caused it to be forever excluded from future warnings. For methods that are declared in the class we're visiting, this makes sense, but it doesn't make sense for inherited methods, because it disqualifies them from participating in the analysis of any other class that also inherits them.
>> 
>> As a result, for a class like the one below, the compiler was only generating one warning instead of three:
>> 
>> public interface SuperIface {
>>     void foo(Consumer<Integer> c);
>> }
>> 
>> public interface I1 extends SuperIface { 
>>     void foo(IntConsumer c);        // warning was generated here
>> }   
>> 
>> public interface I2 extends SuperIface { 
>>     void foo(IntConsumer c);        // no warning was generated here
>> }   
>> 
>> public interface I3 extends SuperIface { 
>>     void foo(IntConsumer c);        // no warning was generated here
>> }   
>> 
>> 
>> With this patch the `POTENTIALLY_AMBIGUOUS` flag is no longer needed. I wasn't sure whether to renumber all the subsequent flags, or just leave an empty placeholder, so I chose the latter.
>> 
>> Finally, this fix uncovers new warnings in `java.base` and `java.desktop`, so these are now suppressed in the patch.
>
> Archie L. Cobbs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove placeholder flag UNUSED_1; just leave a comment instead.

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java line 2719:

> 2717:      *  does not override any other methods (in which case site is responsible).
> 2718:      */
> 2719:     void checkPotentiallyAmbiguousOverloads(JCClassDecl tree, Type site) {

general comments: overall looks correct but I think the code should be split a bit using helper methods, that will help with readability, I think. Side: I'm a bit worried that overuse of streams in this code could imply some performance hit. Of course if the corresponding lint warning is not enabled we will skip it but a lot of projects compile with `-Xlint:all` nowadays.

-------------

PR: https://git.openjdk.org/jdk/pull/12645

From bpb at openjdk.org  Fri Feb 24 19:04:33 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 24 Feb 2023 19:04:33 GMT
Subject: RFR: 8303175: (fs) Deprecate
 com.sun.nio.file.SensitivityWatchEventModifier for removal [v2]
In-Reply-To: <s7IRC6buEQ5NrNc4XW3lIf6wpdfBksPrIjuTnTO99Gc=.380f3194-e6e7-4c55-b322-2fff1984cd4a@github.com>
References: <s7IRC6buEQ5NrNc4XW3lIf6wpdfBksPrIjuTnTO99Gc=.380f3194-e6e7-4c55-b322-2fff1984cd4a@github.com>
Message-ID: <mRL4BzPPcM-KIX3prN-P5REG13aES0ilBAJEPybK-Dk=.8302a2e9-80a5-46c2-8b13-4e2332d47b04@github.com>

> Deprecate `SensitivityWatchEventModifier` for now instead of directly removing it as proposed in #12626.

Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:

  8303175: Move @deprecated above @since; tweak verbiage

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12746/files
  - new: https://git.openjdk.org/jdk/pull/12746/files/694ecfeb..b3ea4f71

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12746&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12746&range=00-01

  Stats: 8 lines in 1 file changed: 3 ins; 2 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/12746.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12746/head:pull/12746

PR: https://git.openjdk.org/jdk/pull/12746

From tsteele at openjdk.org  Fri Feb 24 19:08:54 2023
From: tsteele at openjdk.org (Tyler Steele)
Date: Fri, 24 Feb 2023 19:08:54 GMT
Subject: RFR: 8303186: Missing Classpath exception from Continuation.c
Message-ID: <v0xMlJcLPGNkugPRO4sGW6uJpo7POXpTO0-gKDGu-QA=.af70fd45-0770-41fc-a8b6-38f607aa8b8f@github.com>

This PR adds the Classpath exception to the header file of `src/java.base/share/native/libjava/Continuation.c`.

-------------

Commit messages:
 - Adds classpath exception

Changes: https://git.openjdk.org/jdk/pull/12747/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12747&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8303186
  Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/12747.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12747/head:pull/12747

PR: https://git.openjdk.org/jdk/pull/12747

From lancea at openjdk.org  Fri Feb 24 19:15:06 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Fri, 24 Feb 2023 19:15:06 GMT
Subject: RFR: 8303175: (fs) Deprecate
 com.sun.nio.file.SensitivityWatchEventModifier for removal [v2]
In-Reply-To: <mRL4BzPPcM-KIX3prN-P5REG13aES0ilBAJEPybK-Dk=.8302a2e9-80a5-46c2-8b13-4e2332d47b04@github.com>
References: <s7IRC6buEQ5NrNc4XW3lIf6wpdfBksPrIjuTnTO99Gc=.380f3194-e6e7-4c55-b322-2fff1984cd4a@github.com>
 <mRL4BzPPcM-KIX3prN-P5REG13aES0ilBAJEPybK-Dk=.8302a2e9-80a5-46c2-8b13-4e2332d47b04@github.com>
Message-ID: <B3rV0f7AjsqXQLWWJ9OYI98_eS1HZKDR-wzT3VSja4I=.a443436c-eb3f-42ce-9cfb-f75a48b60336@github.com>

On Fri, 24 Feb 2023 19:04:33 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Deprecate `SensitivityWatchEventModifier` for now instead of directly removing it as proposed in #12626.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8303175: Move @deprecated above @since; tweak verbiage

Marked as reviewed by lancea (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/12746

From bchristi at openjdk.org  Fri Feb 24 19:29:10 2023
From: bchristi at openjdk.org (Brent Christian)
Date: Fri, 24 Feb 2023 19:29:10 GMT
Subject: RFR: 8302899: Executors.newSingleThreadExecutor can use Cleaner to
 shutdown executor [v5]
In-Reply-To: <4ZWYgQetrzu3qJhzFrqmdhxBq5Q04NmC_pPWyMVrp-M=.1a950b12-92d5-475d-b55b-148b890d3da7@github.com>
References: <tBrSZRn1GdrWMSRUsdNNyAWpkuS_FvtLwLuUKut6LH0=.cd1a7fcb-dbcf-45eb-b3d3-72ba17087566@github.com>
 <4ZWYgQetrzu3qJhzFrqmdhxBq5Q04NmC_pPWyMVrp-M=.1a950b12-92d5-475d-b55b-148b890d3da7@github.com>
Message-ID: <KjxrO75VjAgrBUTG1Tp0y_ZAFTbss-f9xKSLLWt2-jU=.692aaa41-a39a-4e59-a84c-578d5d8baed5@github.com>

On Fri, 24 Feb 2023 13:44:40 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Executors.newSingleThreadExecutor returns a delegating ExecutorService that has finalizer to shutdown the underlying TPE when the wrapper is finalizable. It goes back to JDK 6 and JDK-6399443. This is the last non-empty finalizer in java.base. Removing it will likely lead to bug reports/complaints as the current behavior goes back to 2006. So the proposal is to just replace it with a Cleaner, trivially done in this case. As part of this change, I've added a RF to DelegatedExecutorService.shutdown to be consistent with the other methods - this is a benign change and avoids needing to puzzle over why it wasn't there previously. I've replaced the existing test with a more modern test that exercises more scenarios.
>
> Alan Bateman has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rename cleaner, fix typo in test comments

Looks fine. Thanks for doing this, Alan.

-------------

Marked as reviewed by bchristi (Reviewer).

PR: https://git.openjdk.org/jdk/pull/12675

From duke at openjdk.org  Fri Feb 24 19:30:08 2023
From: duke at openjdk.org (Archie L. Cobbs)
Date: Fri, 24 Feb 2023 19:30:08 GMT
Subject: RFR: 8026369: javac potentially ambiguous overload warning needs
 an improved scheme [v3]
In-Reply-To: <98kTDWOcTYL9jRLZQhDXFjPmHQJQPZg8tGuUhi0Iwlk=.b91510cc-5e55-4090-919f-a5a5cc5b2347@github.com>
References: <IMxp3iCK--jYJ5Ia04i6QPYfnCHQobVcsmlI5aJXdqc=.892abcb8-7f2a-4fe9-aea2-1b1d41098a6d@github.com>
 <NHHLq4y0LkeQGPPSoHjNOquUU0_iafjmkeFZosjoFPs=.22a5e84f-eaba-4e44-b531-dcd9ea9a92c7@github.com>
 <98kTDWOcTYL9jRLZQhDXFjPmHQJQPZg8tGuUhi0Iwlk=.b91510cc-5e55-4090-919f-a5a5cc5b2347@github.com>
Message-ID: <LZ7r3Q3pbjdcWCb0h3osWvkTBGXtjnIJY2ZJFu7AcZc=.83196683-0e0f-4308-ac99-431c018af15e@github.com>

On Fri, 24 Feb 2023 19:00:51 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> I think the code should be split a bit using helper methods

OK - will do.

> I'm a bit worried that overuse of streams in this code could imply some performance hit

I asked basically the same question ([in a separate thread](https://mail.openjdk.org/pipermail/compiler-dev/2023-February/022259.html)) two days ago and nobody replied with a definitive answer (not surprising).

However, note also that in that same thread Christoph reported no timing difference between `Stream` vs. `for()` loop ([here](https://mail.openjdk.org/pipermail/compiler-dev/2023-February/022261.html)), although there were more allocations. FWIW.

Sorry to go off on a tangent here, but I'm sure this issue will come up again and it would be nice to have some kind of (informal) policy to go on...

I generally try to follow the "measure first, optimize second" rule to avoid preemptive "optimizations" that come at the expense of code clarity for unproven meaningful benefit.

So I can de-`Stream` the code but are we sure it's worth it? Are we going to have a no `Stream` policy in the compiler code? Why did we develop `Stream`'s if they can't be used in a mainstream tool like `javac`? Where does the madness end? :)

There is also the larger philosophical question as well, which is that if a `Stream` is appreciably slower than the semantically-equivalent `for()` loop, then isn't that a Hotspot problem, not a developer problem?

-------------

PR: https://git.openjdk.org/jdk/pull/12645

From duke at openjdk.org  Fri Feb 24 19:38:05 2023
From: duke at openjdk.org (Madjosz)
Date: Fri, 24 Feb 2023 19:38:05 GMT
Subject: RFR: 8302983: ZoneRulesProvider.registerProvider() twice will
 remove provider
In-Reply-To: <rhr9eb9K3PR0rwwrPefxCpZS5srfvXWwqAt2Znzf5S0=.f83774c2-9e04-488c-96de-19a3c83d85c0@github.com>
References: <AAfM5rBLeq2B3ttHBX_7kw0_rjfIVPSdcEL23HiOhVs=.b17c2586-b0bc-46ad-9501-0cf8363f82b9@github.com>
 <rhr9eb9K3PR0rwwrPefxCpZS5srfvXWwqAt2Znzf5S0=.f83774c2-9e04-488c-96de-19a3c83d85c0@github.com>
Message-ID: <ZLpBWLQj05Tk2GPz-mg6tIQQPmIOPZPPpFdh4Fg_f6s=.0aa35cd6-dd99-4c89-a787-46acb436108c@github.com>

On Wed, 22 Feb 2023 20:41:07 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Fixes JDK-8302983 (and duplicate JDK-8302898)
>
> test/jdk/java/time/test/java/time/zone/TestZoneRulesProvider.java line 123:
> 
>> 121:         ZoneRulesProvider.registerProvider(provider);
>> 122:         assertTrue(ZoneId.getAvailableZoneIds().contains(zone), "Unexpected non-availability for " + zone);
>> 123:         assertNotNull(ZoneId.of(zone), "ZoneId instance for " + zone + " should be obtainable");
> 
> If the `zone` does not exist, it will not return `null` but throw an exception. Assertion needs to be modified correctly.

Which version of TestNG is used for JDK? In JUnit 5 I would just use `assertDoesNotThrow()` in such a case but TestNG seems to lack such method.

-------------

PR: https://git.openjdk.org/jdk/pull/12690

From vromero at openjdk.org  Fri Feb 24 19:52:07 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 24 Feb 2023 19:52:07 GMT
Subject: RFR: 8026369: javac potentially ambiguous overload warning needs
 an improved scheme [v3]
In-Reply-To: <LZ7r3Q3pbjdcWCb0h3osWvkTBGXtjnIJY2ZJFu7AcZc=.83196683-0e0f-4308-ac99-431c018af15e@github.com>
References: <IMxp3iCK--jYJ5Ia04i6QPYfnCHQobVcsmlI5aJXdqc=.892abcb8-7f2a-4fe9-aea2-1b1d41098a6d@github.com>
 <NHHLq4y0LkeQGPPSoHjNOquUU0_iafjmkeFZosjoFPs=.22a5e84f-eaba-4e44-b531-dcd9ea9a92c7@github.com>
 <98kTDWOcTYL9jRLZQhDXFjPmHQJQPZg8tGuUhi0Iwlk=.b91510cc-5e55-4090-919f-a5a5cc5b2347@github.com>
 <LZ7r3Q3pbjdcWCb0h3osWvkTBGXtjnIJY2ZJFu7AcZc=.83196683-0e0f-4308-ac99-431c018af15e@github.com>
Message-ID: <LRcPwyPlnlmp2j66TpinIm9K89EfZZbM7Ll67kM7DLA=.becf5103-4d8e-48d5-b699-9f699935e105@github.com>

On Fri, 24 Feb 2023 19:27:02 GMT, Archie L. Cobbs <duke at openjdk.org> wrote:

>> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java line 2719:
>> 
>>> 2717:      *  does not override any other methods (in which case site is responsible).
>>> 2718:      */
>>> 2719:     void checkPotentiallyAmbiguousOverloads(JCClassDecl tree, Type site) {
>> 
>> general comments: overall looks correct but I think the code should be split a bit using helper methods, that will help with readability, I think. Side: I'm a bit worried that overuse of streams in this code could imply some performance hit. Of course if the corresponding lint warning is not enabled we will skip it but a lot of projects compile with `-Xlint:all` nowadays.
>
>> I think the code should be split a bit using helper methods
> 
> OK - will do.
> 
>> I'm a bit worried that overuse of streams in this code could imply some performance hit
> 
> I asked basically the same question ([in a separate thread](https://mail.openjdk.org/pipermail/compiler-dev/2023-February/022259.html)) two days ago and nobody replied with a definitive answer (not surprising).
> 
> However, note also that in that same thread Christoph reported no timing difference between `Stream` vs. `for()` loop ([here](https://mail.openjdk.org/pipermail/compiler-dev/2023-February/022261.html)), although there were more allocations. FWIW.
> 
> Sorry to go off on a tangent here, but I'm sure this issue will come up again and it would be nice to have some kind of (informal) policy to go on...
> 
> I generally try to follow the "measure first, optimize second" rule to avoid preemptive "optimizations" that come at the expense of code clarity for unproven meaningful benefit.
> 
> So I can de-`Stream` the code but are we sure it's worth it? Are we going to have a no `Stream` policy in the compiler code? Why did we develop `Stream`'s if they can't be used in a mainstream tool like `javac`? Where does the madness end? :)
> 
> There is also the larger philosophical question as well, which is that if a `Stream` is appreciably slower than the semantically-equivalent `for()` loop, then isn't that a Hotspot problem, not a developer problem?

I'm not saying that we should de-stream the code, actually we can do that later on iff there is a performance related complain, but it is true that in the past, I have seen some performance issues and the final culprit have been streams. But you are right it could be that it is not worthy to affect the readability of the code.

-------------

PR: https://git.openjdk.org/jdk/pull/12645

From duke at openjdk.org  Fri Feb 24 19:52:59 2023
From: duke at openjdk.org (Madjosz)
Date: Fri, 24 Feb 2023 19:52:59 GMT
Subject: RFR: 8302983: ZoneRulesProvider.registerProvider() twice will
 remove provider [v2]
In-Reply-To: <AAfM5rBLeq2B3ttHBX_7kw0_rjfIVPSdcEL23HiOhVs=.b17c2586-b0bc-46ad-9501-0cf8363f82b9@github.com>
References: <AAfM5rBLeq2B3ttHBX_7kw0_rjfIVPSdcEL23HiOhVs=.b17c2586-b0bc-46ad-9501-0cf8363f82b9@github.com>
Message-ID: <tE5pT06KucRru80f2pLZD84cnmv8qdAQRMLDMgcU_EE=.c84fb5f0-30b7-43a2-8080-784aec23f6d5@github.com>

> Fixes JDK-8302983 (and duplicate JDK-8302898)

Madjosz has updated the pull request incrementally with one additional commit since the last revision:

  apply review comments

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12690/files
  - new: https://git.openjdk.org/jdk/pull/12690/files/e87cfef8..0c7e5889

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12690&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12690&range=00-01

  Stats: 71 lines in 1 file changed: 31 ins; 33 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/12690.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12690/head:pull/12690

PR: https://git.openjdk.org/jdk/pull/12690

From duke at openjdk.org  Fri Feb 24 19:53:02 2023
From: duke at openjdk.org (Madjosz)
Date: Fri, 24 Feb 2023 19:53:02 GMT
Subject: RFR: 8302983: ZoneRulesProvider.registerProvider() twice will
 remove provider [v2]
In-Reply-To: <ZLpBWLQj05Tk2GPz-mg6tIQQPmIOPZPPpFdh4Fg_f6s=.0aa35cd6-dd99-4c89-a787-46acb436108c@github.com>
References: <AAfM5rBLeq2B3ttHBX_7kw0_rjfIVPSdcEL23HiOhVs=.b17c2586-b0bc-46ad-9501-0cf8363f82b9@github.com>
 <rhr9eb9K3PR0rwwrPefxCpZS5srfvXWwqAt2Znzf5S0=.f83774c2-9e04-488c-96de-19a3c83d85c0@github.com>
 <ZLpBWLQj05Tk2GPz-mg6tIQQPmIOPZPPpFdh4Fg_f6s=.0aa35cd6-dd99-4c89-a787-46acb436108c@github.com>
Message-ID: <nJteZ8aIZU4lrM3kcvgpmwvqftxu1IFjQN0j_QmHW-A=.0ce2fb0e-947f-485c-974d-2defa923d3fd@github.com>

On Fri, 24 Feb 2023 19:35:29 GMT, Madjosz <duke at openjdk.org> wrote:

>> test/jdk/java/time/test/java/time/zone/TestZoneRulesProvider.java line 123:
>> 
>>> 121:         ZoneRulesProvider.registerProvider(provider);
>>> 122:         assertTrue(ZoneId.getAvailableZoneIds().contains(zone), "Unexpected non-availability for " + zone);
>>> 123:         assertNotNull(ZoneId.of(zone), "ZoneId instance for " + zone + " should be obtainable");
>> 
>> If the `zone` does not exist, it will not return `null` but throw an exception. Assertion needs to be modified correctly.
>
> Which version of TestNG is used for JDK? In JUnit 5 I would just use `assertDoesNotThrow()` in such a case but TestNG seems to lack such method.

I just removed the non-`null` assertion as the fact that the call succeeds already is the thing we want to test here.

-------------

PR: https://git.openjdk.org/jdk/pull/12690

From duke at openjdk.org  Fri Feb 24 20:09:07 2023
From: duke at openjdk.org (Archie L. Cobbs)
Date: Fri, 24 Feb 2023 20:09:07 GMT
Subject: RFR: 8026369: javac potentially ambiguous overload warning needs
 an improved scheme [v3]
In-Reply-To: <LRcPwyPlnlmp2j66TpinIm9K89EfZZbM7Ll67kM7DLA=.becf5103-4d8e-48d5-b699-9f699935e105@github.com>
References: <IMxp3iCK--jYJ5Ia04i6QPYfnCHQobVcsmlI5aJXdqc=.892abcb8-7f2a-4fe9-aea2-1b1d41098a6d@github.com>
 <NHHLq4y0LkeQGPPSoHjNOquUU0_iafjmkeFZosjoFPs=.22a5e84f-eaba-4e44-b531-dcd9ea9a92c7@github.com>
 <98kTDWOcTYL9jRLZQhDXFjPmHQJQPZg8tGuUhi0Iwlk=.b91510cc-5e55-4090-919f-a5a5cc5b2347@github.com>
 <LZ7r3Q3pbjdcWCb0h3osWvkTBGXtjnIJY2ZJFu7AcZc=.83196683-0e0f-4308-ac99-431c018af15e@github.com>
 <LRcPwyPlnlmp2j66TpinIm9K89EfZZbM7Ll67kM7DLA=.becf5103-4d8e-48d5-b699-9f699935e105@github.com>
Message-ID: <wFxhY4VU9XEIbb2apCJdg4s5E15-yXlSSl-b6BMyS1k=.327469a7-2050-4dfc-a82f-745e0667381d@github.com>

On Fri, 24 Feb 2023 19:49:18 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>>> I think the code should be split a bit using helper methods
>> 
>> OK - will do.
>> 
>>> I'm a bit worried that overuse of streams in this code could imply some performance hit
>> 
>> I asked basically the same question ([in a separate thread](https://mail.openjdk.org/pipermail/compiler-dev/2023-February/022259.html)) two days ago and nobody replied with a definitive answer (not surprising).
>> 
>> However, note also that in that same thread Christoph reported no timing difference between `Stream` vs. `for()` loop ([here](https://mail.openjdk.org/pipermail/compiler-dev/2023-February/022261.html)), although there were more allocations. FWIW.
>> 
>> Sorry to go off on a tangent here, but I'm sure this issue will come up again and it would be nice to have some kind of (informal) policy to go on...
>> 
>> I generally try to follow the "measure first, optimize second" rule to avoid preemptive "optimizations" that come at the expense of code clarity for unproven meaningful benefit.
>> 
>> So I can de-`Stream` the code but are we sure it's worth it? Are we going to have a no `Stream` policy in the compiler code? Why did we develop `Stream`'s if they can't be used in a mainstream tool like `javac`? Where does the madness end? :)
>> 
>> There is also the larger philosophical question as well, which is that if a `Stream` is appreciably slower than the semantically-equivalent `for()` loop, then isn't that a Hotspot problem, not a developer problem?
>
> I'm not saying that we should de-stream the code, actually we can do that later on, in a separate issue, iff there is a performance related complain, but it is true that in the past, I have seen some performance issues and the final culprit have been streams. But you are right it could be that it is not worthy to affect the readability of the code.

OK thanks, I'll leave it for now - but it would be nice to (someday) do some comprehensive testing so we have a better intuitive understanding of the performance impact of using a `Stream` in any particular situation.

I wonder if there is some IDE tool that could automatically `Stream`ify and/or de-`Stream`ify loops. If so, we could apply it to the entire compiler and compare...

-------------

PR: https://git.openjdk.org/jdk/pull/12645

From vromero at openjdk.org  Fri Feb 24 20:24:05 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 24 Feb 2023 20:24:05 GMT
Subject: RFR: 8026369: javac potentially ambiguous overload warning needs
 an improved scheme [v3]
In-Reply-To: <wFxhY4VU9XEIbb2apCJdg4s5E15-yXlSSl-b6BMyS1k=.327469a7-2050-4dfc-a82f-745e0667381d@github.com>
References: <IMxp3iCK--jYJ5Ia04i6QPYfnCHQobVcsmlI5aJXdqc=.892abcb8-7f2a-4fe9-aea2-1b1d41098a6d@github.com>
 <NHHLq4y0LkeQGPPSoHjNOquUU0_iafjmkeFZosjoFPs=.22a5e84f-eaba-4e44-b531-dcd9ea9a92c7@github.com>
 <98kTDWOcTYL9jRLZQhDXFjPmHQJQPZg8tGuUhi0Iwlk=.b91510cc-5e55-4090-919f-a5a5cc5b2347@github.com>
 <LZ7r3Q3pbjdcWCb0h3osWvkTBGXtjnIJY2ZJFu7AcZc=.83196683-0e0f-4308-ac99-431c018af15e@github.com>
 <LRcPwyPlnlmp2j66TpinIm9K89EfZZbM7Ll67kM7DLA=.becf5103-4d8e-48d5-b699-9f699935e105@github.com>
 <wFxhY4VU9XEIbb2apCJdg4s5E15-yXlSSl-b6BMyS1k=.327469a7-2050-4dfc-a82f-745e0667381d@github.com>
Message-ID: <UD953877MkjcZlJwygP4tGohiJDGDGXhHAqeE0X2FbY=.9194f6e1-a31b-44c9-8a37-3b399a27130d@github.com>

On Fri, 24 Feb 2023 20:05:52 GMT, Archie L. Cobbs <duke at openjdk.org> wrote:

>> I'm not saying that we should de-stream the code, actually we can do that later on, in a separate issue, iff there is a performance related complain, but it is true that in the past, I have seen some performance issues and the final culprit have been streams. But you are right it could be that it is not worthy to affect the readability of the code.
>
> OK thanks, I'll leave it for now - but it would be nice to (someday) do some comprehensive testing so we have a better intuitive understanding of the performance impact of using a `Stream` in any particular situation.
> 
> I wonder if there is some IDE tool that could automatically `Stream`ify and/or de-`Stream`ify loops. If so, we could apply it to the entire compiler and compare...

yes that would be nice to have, although streams have different effects depending on how hot the code path is, so in general they are OK. Inference code is one of the places where I have seen that using streams is not a good idea for example

-------------

PR: https://git.openjdk.org/jdk/pull/12645

From rriggs at openjdk.org  Fri Feb 24 21:38:05 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 24 Feb 2023 21:38:05 GMT
Subject: RFR: 8302590: Add String.indexOf(int ch, int fromIndex,
 int toIndex) [v2]
In-Reply-To: <PcNy8ba-uUNC440TO9rRmcpexbbHGSvYwxhLuR5gRzU=.b11e3cb2-e9ee-496d-a6e0-a52f73af2c7d@github.com>
References: <uQ65oRaVDfpzm9bYRuo_MvSuZIdepicE3GnB3Omyngs=.fc23545b-141a-47e5-8a6a-aa28ae1375e5@github.com>
 <e5NTzUo4CgRNg18roWci0Pcd3r9rNOBQc-PHOwct0c8=.ac46d852-0ec6-4a2c-a708-34c9c709089f@github.com>
 <sTIj2d6AOMbSKiyDBO4S6FSTRwLGV_dU-JYaztTJDOw=.3163f958-67be-440d-bde5-56341c4ac981@github.com>
 <PcNy8ba-uUNC440TO9rRmcpexbbHGSvYwxhLuR5gRzU=.b11e3cb2-e9ee-496d-a6e0-a52f73af2c7d@github.com>
Message-ID: <l47IUVGuNmwe60FfwRdbKCAJxEkYDj38rGHne0d3PJQ=.5d26db2e-ef88-489a-b5cb-22b09d38ff9e@github.com>

On Fri, 24 Feb 2023 17:45:42 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> addressed
>
> JMH does not indicate any performance regression.
> 
> W.r.t. renaming Java parameters in `@IntrinsicCandidate` methods, I crosschecked with a runtime compiler guy. He confirms that changing names in the Java implementations is irrelevant for the intrinsified code. There might be references to the names in native comments, but this is not the case for `indexOf`. However, to be on the safe side I reverted those renames back to the original.

Thanks for confirming

-------------

PR: https://git.openjdk.org/jdk/pull/12600

From naoto at openjdk.org  Fri Feb 24 21:55:07 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 24 Feb 2023 21:55:07 GMT
Subject: RFR: 8302983: ZoneRulesProvider.registerProvider() twice will
 remove provider [v2]
In-Reply-To: <tE5pT06KucRru80f2pLZD84cnmv8qdAQRMLDMgcU_EE=.c84fb5f0-30b7-43a2-8080-784aec23f6d5@github.com>
References: <AAfM5rBLeq2B3ttHBX_7kw0_rjfIVPSdcEL23HiOhVs=.b17c2586-b0bc-46ad-9501-0cf8363f82b9@github.com>
 <tE5pT06KucRru80f2pLZD84cnmv8qdAQRMLDMgcU_EE=.c84fb5f0-30b7-43a2-8080-784aec23f6d5@github.com>
Message-ID: <nRaMUPPLhtiRx8yWeVSv3VgEtR6A8BZtfEr6I-EE9-0=.351d7fab-aaa8-438e-9dd9-abed13b5d2f0@github.com>

On Fri, 24 Feb 2023 19:52:59 GMT, Madjosz <duke at openjdk.org> wrote:

>> Fixes JDK-8302983 (and duplicate JDK-8302898)
>
> Madjosz has updated the pull request incrementally with one additional commit since the last revision:
> 
>   apply review comments

Changes requested by naoto (Reviewer).

test/jdk/java/time/test/java/time/zone/TestZoneRulesProvider.java line 107:

> 105: 
> 106:         // availability check
> 107:         assertTrue(ZoneId.getAvailableZoneIds().contains(zone), "Unexpected non-availability for " + id);

Did you actually run the test??? It still does not compile. Please make sure you run the test under the modified jdk and passes.


STDERR:

-------------

PR: https://git.openjdk.org/jdk/pull/12690

From jlu at openjdk.org  Fri Feb 24 22:00:21 2023
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 24 Feb 2023 22:00:21 GMT
Subject: RFR: 8282319: java.util.Locale method to stream available Locales
 [v3]
In-Reply-To: <Y-8deBLWqXedPstR9iVGr-CxLyxriwsEbhdMBddNNME=.09b2307f-1672-49b2-a5f9-f529df906d21@github.com>
References: <QxcV7IwdW13WfT0X0PKyWBWpo_rP588AgHIYiUu3E_Q=.82b88828-e8ec-4f3c-a75a-ec88b589d4e2@github.com>
 <Qy9riGxMB2o0xwjBc1BGcLACNF-bLtMyN657jEqslUA=.eef77647-27bf-41d9-8660-ada00cb5b537@github.com>
 <3_P5D-o1sd8I3HCikS39S5LhEmmMV6f787wwffkuJQU=.5a8e2eee-2b3d-4904-9665-372e82e584ad@github.com>
 <0_zm1BN0d7_M2lQaL8hQovM-L2nm_Y3QsOnGj9y35IM=.3d2333d9-f3a8-413b-ac12-f62b66785ee8@github.com>
 <Y-8deBLWqXedPstR9iVGr-CxLyxriwsEbhdMBddNNME=.09b2307f-1672-49b2-a5f9-f529df906d21@github.com>
Message-ID: <TTxOmftDjmmAofhxmZko-33dqbiNtu6mZSAtpkAk15k=.d70af2f5-bc85-45b2-9661-45023da1263f@github.com>

On Fri, 24 Feb 2023 18:58:45 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> From what I saw in other methods, `@return ...` goes on the bottom (like the line I removed), but the javadoc 16 tag `{@return ... }` goes on the top.
>
> OK but then we should be consistent and update all of the methods to use the new tag or  revert the change for consistency

Makes sense, will look at both Locale and LocaleServiceProviderPool and update the methods that are applicable for {@return ..}. Thanks Lance

-------------

PR: https://git.openjdk.org/jdk/pull/12269

From rriggs at openjdk.org  Fri Feb 24 22:13:17 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 24 Feb 2023 22:13:17 GMT
Subject: RFR: 8282319: java.util.Locale method to stream available Locales
 [v3]
In-Reply-To: <TTxOmftDjmmAofhxmZko-33dqbiNtu6mZSAtpkAk15k=.d70af2f5-bc85-45b2-9661-45023da1263f@github.com>
References: <QxcV7IwdW13WfT0X0PKyWBWpo_rP588AgHIYiUu3E_Q=.82b88828-e8ec-4f3c-a75a-ec88b589d4e2@github.com>
 <Qy9riGxMB2o0xwjBc1BGcLACNF-bLtMyN657jEqslUA=.eef77647-27bf-41d9-8660-ada00cb5b537@github.com>
 <3_P5D-o1sd8I3HCikS39S5LhEmmMV6f787wwffkuJQU=.5a8e2eee-2b3d-4904-9665-372e82e584ad@github.com>
 <0_zm1BN0d7_M2lQaL8hQovM-L2nm_Y3QsOnGj9y35IM=.3d2333d9-f3a8-413b-ac12-f62b66785ee8@github.com>
 <Y-8deBLWqXedPstR9iVGr-CxLyxriwsEbhdMBddNNME=.09b2307f-1672-49b2-a5f9-f529df906d21@github.com>
 <TTxOmftDjmmAofhxmZko-33dqbiNtu6mZSAtpkAk15k=.d70af2f5-bc85-45b2-9661-45023da1263f@github.com>
Message-ID: <UinlfQjpLXJkQG_htNNgBOxTLSWxZMEoXBbjMyfSTRk=.2d95dd83-e4c7-4c47-8a6c-8744b09e2a00@github.com>

On Fri, 24 Feb 2023 21:57:41 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> OK but then we should be consistent and update all of the methods to use the new tag or  revert the change for consistency
>
> Makes sense, will look at both Locale and LocaleServiceProviderPool and update the methods that are applicable for {@return ..}. Thanks Lance

That's getting a bit far afield of the original issue; a separate issue might be a better way to address those cases. $.02

-------------

PR: https://git.openjdk.org/jdk/pull/12269

From lmesnik at openjdk.org  Fri Feb 24 22:22:51 2023
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Fri, 24 Feb 2023 22:22:51 GMT
Subject: RFR: 8303133: Update ProcessTols.startProcess(...) to exit early if
 process exit before linePredicate is printed.
Message-ID: <cuDocKEsnNWZvi2L_E6XBQ_U0T8qnNCIupmsFxaSjEw=.867a6664-21bc-44fb-aa68-9b9a1e8d36d7@github.com>

The solution proposed by Stefan K

The startProcess() might wait forever for the expected line if the process exits (failed to start). It makes sense to just fail earlier in such cases.

The fix also move
'output = new OutputAnalyzer(this.process);'
in method xrun() to be able to try to print them in waitFor is failed/interrupted.

-------------

Commit messages:
 - 8303133: Update ProcessTols.startProcess(...) to exit early if process exit before linePredicate is printed.

Changes: https://git.openjdk.org/jdk/pull/12751/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12751&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8303133
  Stats: 26 lines in 2 files changed: 16 ins; 3 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/12751.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12751/head:pull/12751

PR: https://git.openjdk.org/jdk/pull/12751

From dcubed at openjdk.org  Fri Feb 24 22:39:05 2023
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Fri, 24 Feb 2023 22:39:05 GMT
Subject: RFR: 8303133: Update ProcessTols.startProcess(...) to exit early
 if process exit before linePredicate is printed.
In-Reply-To: <cuDocKEsnNWZvi2L_E6XBQ_U0T8qnNCIupmsFxaSjEw=.867a6664-21bc-44fb-aa68-9b9a1e8d36d7@github.com>
References: <cuDocKEsnNWZvi2L_E6XBQ_U0T8qnNCIupmsFxaSjEw=.867a6664-21bc-44fb-aa68-9b9a1e8d36d7@github.com>
Message-ID: <Y2kudIYApLTuE37FTNyBTAJJVkhnYRc_UeUtIAJsnPk=.0e0d3b51-f737-4dba-a7f0-6253b954af0b@github.com>

On Fri, 24 Feb 2023 22:15:18 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> The solution proposed by Stefan K
> 
> The startProcess() might wait forever for the expected line if the process exits (failed to start). It makes sense to just fail earlier in such cases.
> 
> The fix also move
> 'output = new OutputAnalyzer(this.process);'
> in method xrun() to be able to try to print them in waitFor is failed/interrupted.

I fixed a typo in the bug's synopsis line so you'll need to update the PR's title.
Use "/issue JDK-8303133" as the quickest way to set it.

-------------

PR: https://git.openjdk.org/jdk/pull/12751

From vromero at openjdk.org  Fri Feb 24 22:41:09 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 24 Feb 2023 22:41:09 GMT
Subject: RFR: 8026369: javac potentially ambiguous overload warning needs
 an improved scheme [v4]
In-Reply-To: <La7IUyuwT43IIKFp8OKW0Wd3iGPnVyvTHyJr00XXq8s=.4b0c537d-1fcd-416a-bd4f-7a1e88466be1@github.com>
References: <IMxp3iCK--jYJ5Ia04i6QPYfnCHQobVcsmlI5aJXdqc=.892abcb8-7f2a-4fe9-aea2-1b1d41098a6d@github.com>
 <La7IUyuwT43IIKFp8OKW0Wd3iGPnVyvTHyJr00XXq8s=.4b0c537d-1fcd-416a-bd4f-7a1e88466be1@github.com>
Message-ID: <a76nqGkGeJn4TPnRRhiwHZTTCOhboaL0TDrbvHA2FLM=.110e0330-aa7a-49ed-8518-1ca076b1a4b3@github.com>

On Fri, 24 Feb 2023 18:09:16 GMT, Archie L. Cobbs <duke at openjdk.org> wrote:

>> This bug relates to the "potentially ambiguous overload" warning which is enabled by `-Xlint:overloads`.
>> 
>> The warning detects certain ambiguities that can cause problems for lambdas. For example, consider the interface `Spliterator.OfInt`, which declares these two methods:
>> 
>> void forEachRemaining(Consumer<? super Integer> action);
>> void forEachRemaining(IntConsumer action);
>> 
>> Both methods have the same name, same number of parameters, and take a lambda with the same "shape" in the same argument position. This causes an ambiguity in any code that wants to do this:
>> 
>>     spliterator.forEachRemaining(x -> { ... });
>> 
>> That code won't compile; instead, you'll get this error:
>> 
>> Ambiguity.java:4: error: reference to forEachRemaining is ambiguous
>>         spliterator.forEachRemaining(x -> { });
>>                    ^
>>   both method forEachRemaining(IntConsumer) in OfInt and method forEachRemaining(Consumer<? super Integer>) in OfInt match
>> 
>> 
>> The problem reported by the bug is that the warning fails to detect ambiguities which are created purely by inheritance, for example:
>> 
>> interface ConsumerOfInteger {
>>     void foo(Consumer<Integer> c);
>> }
>> 
>> interface IntegerConsumer {
>>     void foo(IntConsumer c);
>> }
>> 
>> // We should get a warning here...
>> interface Test extends ConsumerOfInteger, IntegerConsumer {
>> }
>> 
>> 
>> The cause of the bug is that ambiguities are detected on a per-method basis, by checking whether a method is part of an ambiguity pair when we visit that method. So if the methods in an ambiguity pair are inherited from two distinct supertypes, we'll miss the ambiguity.
>> 
>> To fix the problem, we need to look for ambiguities on a per-class level, checking all pairs of methods. However, it's not that simple - we only want to "blame" a class when that class itself, and not some supertype, is responsible for creating the ambiguity. For example, any interface extending `Spliterator.OfInt` will automatically inherit the two ambiguities mentioned above, but these are not the interface's fault so to speak so no warning should be generated. Making things more complicated is the fact that methods can be overridden and declared in generic classes so they only conflict in some subtypes, etc.
>> 
>> So we generate the warning when there are two methods m1 and m2 in a class C such that:
>> 
>> * m1 and m2 consitiute a "potentially ambiguous overload" (using the same definition as before)
>> * There is no direct supertype T of C such that m1 and m2, or some methods they override, both exist in T and constitute a "potentially ambiguous overload" as members of T
>> * We haven't already generated a warning for either m1 or m2 in class C
>> 
>> If either method is declared in C, we locate the warning there, but when both methods are inherited, there's no method declaration to point at so the warning is instead located at the class declaration.
>> 
>> I noticed a couple of other minor bugs; these are also being fixed here:
>> 
>> (1) For inherited methods, the method signatures were being reported as they are declared, rather than in the context of the class being visited. As a result, when a methods is inherited from a generic supertype, the ambiguity is less clear. Here's an example:
>> 
>> interface Upper<T> {
>>     void foo(T c);
>> }
>> 
>> interface Lower extends Upper<IntConsumer> {
>>     void foo(Consumer<Integer> c);
>> }
>> 
>> Currently, the error is reported as:
>> 
>> warning: [overloads] foo(Consumer<Integer>) in Lower is potentially ambiguous with foo(T) in Upper
>> 
>> Reporting the method signatures in the context of the class being visited makes the ambiguity clearer:
>> 
>> warning: [overloads] foo(Consumer<Integer>) in Lower is potentially ambiguous with foo(IntConsumer) in Upper
>> 
>> 
>> (2) When a method is identified as part of an ambiguous pair, we were setting a `POTENTIALLY_AMBIGUOUS` flag on it. This caused it to be forever excluded from future warnings. For methods that are declared in the class we're visiting, this makes sense, but it doesn't make sense for inherited methods, because it disqualifies them from participating in the analysis of any other class that also inherits them.
>> 
>> As a result, for a class like the one below, the compiler was only generating one warning instead of three:
>> 
>> public interface SuperIface {
>>     void foo(Consumer<Integer> c);
>> }
>> 
>> public interface I1 extends SuperIface { 
>>     void foo(IntConsumer c);        // warning was generated here
>> }   
>> 
>> public interface I2 extends SuperIface { 
>>     void foo(IntConsumer c);        // no warning was generated here
>> }   
>> 
>> public interface I3 extends SuperIface { 
>>     void foo(IntConsumer c);        // no warning was generated here
>> }   
>> 
>> 
>> With this patch the `POTENTIALLY_AMBIGUOUS` flag is no longer needed. I wasn't sure whether to renumber all the subsequent flags, or just leave an empty placeholder, so I chose the latter.
>> 
>> Finally, this fix uncovers new warnings in `java.base` and `java.desktop`, so these are now suppressed in the patch.
>
> Archie L. Cobbs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix typo in one comment and clarify another.

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java line 2730:

> 2728:             types.membersClosure(site, false).getSymbols(new ClashFilter(site), RECURSIVE).spliterator(), false)
> 2729:           .map(MethodSymbol.class::cast)
> 2730:           .filter(m -> m.owner.type.tsym != syms.objectType.tsym)

nit: this filter could be folded with the one above, `new ClashFilter(site)`

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java line 2772:

> 2770:                 java.util.List<MethodSymbol> overriddenMethods = list.stream()
> 2771:                   .filter(m2 -> m2 != m)
> 2772:                   .filter(m2 -> overrides.test(m, m2))

can these two filters be folded?

-------------

PR: https://git.openjdk.org/jdk/pull/12645

From rriggs at openjdk.org  Fri Feb 24 22:45:05 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 24 Feb 2023 22:45:05 GMT
Subject: RFR: 8303133: Update ProcessTools.startProcess(...) to exit early
 if process exit before linePredicate is printed.
In-Reply-To: <cuDocKEsnNWZvi2L_E6XBQ_U0T8qnNCIupmsFxaSjEw=.867a6664-21bc-44fb-aa68-9b9a1e8d36d7@github.com>
References: <cuDocKEsnNWZvi2L_E6XBQ_U0T8qnNCIupmsFxaSjEw=.867a6664-21bc-44fb-aa68-9b9a1e8d36d7@github.com>
Message-ID: <w_ZSUtkZNqpoe_WFwrtrgLIG6GkfVvduCyMB7hKJEws=.37e86338-4641-4b6f-acf6-e6f6403f25c7@github.com>

On Fri, 24 Feb 2023 22:15:18 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> The solution proposed by Stefan K
> 
> The startProcess() might wait forever for the expected line if the process exits (failed to start). It makes sense to just fail earlier in such cases.
> 
> The fix also move
> 'output = new OutputAnalyzer(this.process);'
> in method xrun() to be able to try to print them in waitFor is failed/interrupted.

test/lib/jdk/test/lib/process/ProcessTools.java line 224:

> 222:                             //Fail if process finished before printed expected string
> 223:                             latch.countDown();
> 224:                             throw new RuntimeException("Started process is not alive.");

Please add the name to the exception; it will be easier to determine what failed.

test/lib/jdk/test/lib/process/ProcessTools.java line 228:

> 226:                     }
> 227:                 } else {
> 228:                     if (!latch.await(Utils.adjustTimeout(timeout), unit)) {

Checking for liveness in both timeout ==0 and > 0 would be useful.

-------------

PR: https://git.openjdk.org/jdk/pull/12751

From rriggs at openjdk.org  Fri Feb 24 22:48:02 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 24 Feb 2023 22:48:02 GMT
Subject: RFR: 8303133: Update ProcessTools.startProcess(...) to exit early
 if process exit before linePredicate is printed.
In-Reply-To: <cuDocKEsnNWZvi2L_E6XBQ_U0T8qnNCIupmsFxaSjEw=.867a6664-21bc-44fb-aa68-9b9a1e8d36d7@github.com>
References: <cuDocKEsnNWZvi2L_E6XBQ_U0T8qnNCIupmsFxaSjEw=.867a6664-21bc-44fb-aa68-9b9a1e8d36d7@github.com>
Message-ID: <7skkfnA13-wOd1g826jJauge6zy_UNOcu3XL2NYg9PU=.ca64f040-922f-44ae-a418-04e903549b75@github.com>

On Fri, 24 Feb 2023 22:15:18 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> The solution proposed by Stefan K
> 
> The startProcess() might wait forever for the expected line if the process exits (failed to start). It makes sense to just fail earlier in such cases.
> 
> The fix also move
> 'output = new OutputAnalyzer(this.process);'
> in method xrun() to be able to try to print them in waitFor is failed/interrupted.

test/lib/jdk/test/lib/thread/ProcessThread.java line 168:

> 166:                 output = new OutputAnalyzer(this.process);
> 167:                 // Will block...
> 168:                 this.process.waitFor();

It would be useful to capture the exit status here for the log.

-------------

PR: https://git.openjdk.org/jdk/pull/12751

From bpb at openjdk.org  Fri Feb 24 23:25:08 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 24 Feb 2023 23:25:08 GMT
Subject: RFR: JDK-8302040: Port fdlibm sqrt to Java [v3]
In-Reply-To: <bzR0JfDQW03UtxdHgqbcLHlBQzPvp2NitCM6Y_ENdco=.1a3c47be-ebf8-420f-903b-964e82fafddf@github.com>
References: <rjVM2lWPdsvPcfLF3oNShP-cSN8-P-i16ikUC3sTgIg=.1d4f470d-2ac9-4394-b55e-099affce763f@github.com>
 <bzR0JfDQW03UtxdHgqbcLHlBQzPvp2NitCM6Y_ENdco=.1a3c47be-ebf8-420f-903b-964e82fafddf@github.com>
Message-ID: <hphP-0znZ3dnRtePwLTaKPIvvzU9IQFKBBhwrNBIaHk=.4f327a69-ad5b-4a18-97b3-f9211b4aadce@github.com>

On Fri, 24 Feb 2023 18:40:38 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> The wheel of FDLIBM porting turns a notch and sqrt comes into play.
>> 
>> While the sqrt operation usually has a hardware implementation that is intrinsified, for completeness a software implementation should be available as well.
>
> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add one one unsigned shift comment.

Go for it.

-------------

Marked as reviewed by bpb (Reviewer).

PR: https://git.openjdk.org/jdk/pull/12736

From duke at openjdk.org  Sat Feb 25 00:07:45 2023
From: duke at openjdk.org (Madjosz)
Date: Sat, 25 Feb 2023 00:07:45 GMT
Subject: RFR: 8302983: ZoneRulesProvider.registerProvider() twice will
 remove provider [v3]
In-Reply-To: <AAfM5rBLeq2B3ttHBX_7kw0_rjfIVPSdcEL23HiOhVs=.b17c2586-b0bc-46ad-9501-0cf8363f82b9@github.com>
References: <AAfM5rBLeq2B3ttHBX_7kw0_rjfIVPSdcEL23HiOhVs=.b17c2586-b0bc-46ad-9501-0cf8363f82b9@github.com>
Message-ID: <TdzFe2DcY9xBD-ckKlwKYcNdT-bpMDfwgx6sxCDfIYw=.26f261c1-8238-44ed-ad87-ee9d75c96ad1@github.com>

> Fixes JDK-8302983 (and duplicate JDK-8302898)

Madjosz has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:

  apply review comments

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12690/files
  - new: https://git.openjdk.org/jdk/pull/12690/files/0c7e5889..1bcf7bd8

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12690&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12690&range=01-02

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/12690.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12690/head:pull/12690

PR: https://git.openjdk.org/jdk/pull/12690

From lmesnik at openjdk.org  Sat Feb 25 00:19:33 2023
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Sat, 25 Feb 2023 00:19:33 GMT
Subject: RFR: 8303133: Update ProcessTools.startProcess(...) to exit early
 if process exit before linePredicate is printed. [v2]
In-Reply-To: <w_ZSUtkZNqpoe_WFwrtrgLIG6GkfVvduCyMB7hKJEws=.37e86338-4641-4b6f-acf6-e6f6403f25c7@github.com>
References: <cuDocKEsnNWZvi2L_E6XBQ_U0T8qnNCIupmsFxaSjEw=.867a6664-21bc-44fb-aa68-9b9a1e8d36d7@github.com>
 <w_ZSUtkZNqpoe_WFwrtrgLIG6GkfVvduCyMB7hKJEws=.37e86338-4641-4b6f-acf6-e6f6403f25c7@github.com>
Message-ID: <YmcpQdejzr3K-sdRYXjy6iYNw8mJYuu4yjznfMt5DlA=.1792ed04-a995-4cad-b114-ddb1e89d1840@github.com>

On Fri, 24 Feb 2023 22:41:34 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   updated to always check if process is alive.
>
> test/lib/jdk/test/lib/process/ProcessTools.java line 228:
> 
>> 226:                     }
>> 227:                 } else {
>> 228:                     if (!latch.await(Utils.adjustTimeout(timeout), unit)) {
> 
> Checking for liveness in both timeout ==0 and > 0 would be useful.

fixed

> test/lib/jdk/test/lib/thread/ProcessThread.java line 168:
> 
>> 166:                 output = new OutputAnalyzer(this.process);
>> 167:                 // Will block...
>> 168:                 this.process.waitFor();
> 
> It would be useful to capture the exit status here for the log.

It is printed anyway in ProcessTools.getProcessLog(...)

-------------

PR: https://git.openjdk.org/jdk/pull/12751

From lmesnik at openjdk.org  Sat Feb 25 00:19:33 2023
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Sat, 25 Feb 2023 00:19:33 GMT
Subject: RFR: 8303133: Update ProcessTools.startProcess(...) to exit early
 if process exit before linePredicate is printed. [v2]
In-Reply-To: <cuDocKEsnNWZvi2L_E6XBQ_U0T8qnNCIupmsFxaSjEw=.867a6664-21bc-44fb-aa68-9b9a1e8d36d7@github.com>
References: <cuDocKEsnNWZvi2L_E6XBQ_U0T8qnNCIupmsFxaSjEw=.867a6664-21bc-44fb-aa68-9b9a1e8d36d7@github.com>
Message-ID: <YMRU3NTKiOEw7VS24xhISyijlTyeTeqRFzG-P3Uo3BQ=.7f5772b3-17bb-4985-88b9-8d11acc9392e@github.com>

> The solution proposed by Stefan K
> 
> The startProcess() might wait forever for the expected line if the process exits (failed to start). It makes sense to just fail earlier in such cases.
> 
> The fix also move
> 'output = new OutputAnalyzer(this.process);'
> in method xrun() to be able to try to print them in waitFor is failed/interrupted.

Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:

  updated to always check if process is alive.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12751/files
  - new: https://git.openjdk.org/jdk/pull/12751/files/71dad3cc..890dcc34

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12751&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12751&range=00-01

  Stats: 16 lines in 1 file changed: 5 ins; 1 del; 10 mod
  Patch: https://git.openjdk.org/jdk/pull/12751.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12751/head:pull/12751

PR: https://git.openjdk.org/jdk/pull/12751

From kvn at openjdk.org  Sat Feb 25 01:37:19 2023
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Sat, 25 Feb 2023 01:37:19 GMT
Subject: RFR: 8143900: OptimizeStringConcat has an opaque dependency on
 Integer.sizeTable field [v2]
In-Reply-To: <upouJcFH3Uw0SXK1OZHRgx5X_fQy9ZI2MbdkjrtjsKs=.c382dad7-a3a7-48f1-a493-db4a2ea80849@github.com>
References: <wVJP9KUVBORqE2Y2rPoPzePyKqbUTiE6fKiS1iOw9j4=.91a2c4c5-6da7-461e-8d65-d6e41bb5f4ff@github.com>
 <upouJcFH3Uw0SXK1OZHRgx5X_fQy9ZI2MbdkjrtjsKs=.c382dad7-a3a7-48f1-a493-db4a2ea80849@github.com>
Message-ID: <PFqUJxR3nKSS_z9H73S7ZWBwI5fBpB2GGIBpzQsSmDI=.e6de4ad8-2155-4f65-9814-3ee28fc9a7f7@github.com>

On Fri, 24 Feb 2023 10:19:49 GMT, Yi Yang <yyang at openjdk.org> wrote:

>> Hi, can I have a review for this patch? I noticed a strange field Integer.sizeTable which is used by PhaseStringOpts, after digging into the history, I think it could be replaced by an in-place array allocation and initialization. Before it, we are fetching from Integer.sizeTable and get num of digit in integer by iterating size table, now we fetch from in-place sizeTable and get size from that. The changed IR looks like this:
>> 
>> ![image](https://user-images.githubusercontent.com/5010047/220239446-7b8b8381-b300-4f2c-a24a-aa19ec9e2f88.png)
>> 
>> Thanks.
>
> Yi Yang has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - whitespace
>  - mirror or Integer.stringSize
>  - mirror or Integer.stringSize

Testing results seem good. Except one strange failure I put in [JDK-8143900](https://bugs.openjdk.org/browse/JDK-8143900) comment.
You need second review.

-------------

PR: https://git.openjdk.org/jdk/pull/12680

From duke at openjdk.org  Sat Feb 25 03:57:30 2023
From: duke at openjdk.org (Archie L. Cobbs)
Date: Sat, 25 Feb 2023 03:57:30 GMT
Subject: RFR: 8026369: javac potentially ambiguous overload warning needs
 an improved scheme [v5]
In-Reply-To: <IMxp3iCK--jYJ5Ia04i6QPYfnCHQobVcsmlI5aJXdqc=.892abcb8-7f2a-4fe9-aea2-1b1d41098a6d@github.com>
References: <IMxp3iCK--jYJ5Ia04i6QPYfnCHQobVcsmlI5aJXdqc=.892abcb8-7f2a-4fe9-aea2-1b1d41098a6d@github.com>
Message-ID: <kfjz51X87aU9nppjkM08j-GuyuWOQ9m_vzTugkjYxVE=.75e83ec8-5810-43cb-8bd1-2a3b5db76b0d@github.com>

> This bug relates to the "potentially ambiguous overload" warning which is enabled by `-Xlint:overloads`.
> 
> The warning detects certain ambiguities that can cause problems for lambdas. For example, consider the interface `Spliterator.OfInt`, which declares these two methods:
> 
> void forEachRemaining(Consumer<? super Integer> action);
> void forEachRemaining(IntConsumer action);
> 
> Both methods have the same name, same number of parameters, and take a lambda with the same "shape" in the same argument position. This causes an ambiguity in any code that wants to do this:
> 
>     spliterator.forEachRemaining(x -> { ... });
> 
> That code won't compile; instead, you'll get this error:
> 
> Ambiguity.java:4: error: reference to forEachRemaining is ambiguous
>         spliterator.forEachRemaining(x -> { });
>                    ^
>   both method forEachRemaining(IntConsumer) in OfInt and method forEachRemaining(Consumer<? super Integer>) in OfInt match
> 
> 
> The problem reported by the bug is that the warning fails to detect ambiguities which are created purely by inheritance, for example:
> 
> interface ConsumerOfInteger {
>     void foo(Consumer<Integer> c);
> }
> 
> interface IntegerConsumer {
>     void foo(IntConsumer c);
> }
> 
> // We should get a warning here...
> interface Test extends ConsumerOfInteger, IntegerConsumer {
> }
> 
> 
> The cause of the bug is that ambiguities are detected on a per-method basis, by checking whether a method is part of an ambiguity pair when we visit that method. So if the methods in an ambiguity pair are inherited from two distinct supertypes, we'll miss the ambiguity.
> 
> To fix the problem, we need to look for ambiguities on a per-class level, checking all pairs of methods. However, it's not that simple - we only want to "blame" a class when that class itself, and not some supertype, is responsible for creating the ambiguity. For example, any interface extending `Spliterator.OfInt` will automatically inherit the two ambiguities mentioned above, but these are not the interface's fault so to speak so no warning should be generated. Making things more complicated is the fact that methods can be overridden and declared in generic classes so they only conflict in some subtypes, etc.
> 
> So we generate the warning when there are two methods m1 and m2 in a class C such that:
> 
> * m1 and m2 consitiute a "potentially ambiguous overload" (using the same definition as before)
> * There is no direct supertype T of C such that m1 and m2, or some methods they override, both exist in T and constitute a "potentially ambiguous overload" as members of T
> * We haven't already generated a warning for either m1 or m2 in class C
> 
> If either method is declared in C, we locate the warning there, but when both methods are inherited, there's no method declaration to point at so the warning is instead located at the class declaration.
> 
> I noticed a couple of other minor bugs; these are also being fixed here:
> 
> (1) For inherited methods, the method signatures were being reported as they are declared, rather than in the context of the class being visited. As a result, when a methods is inherited from a generic supertype, the ambiguity is less clear. Here's an example:
> 
> interface Upper<T> {
>     void foo(T c);
> }
> 
> interface Lower extends Upper<IntConsumer> {
>     void foo(Consumer<Integer> c);
> }
> 
> Currently, the error is reported as:
> 
> warning: [overloads] foo(Consumer<Integer>) in Lower is potentially ambiguous with foo(T) in Upper
> 
> Reporting the method signatures in the context of the class being visited makes the ambiguity clearer:
> 
> warning: [overloads] foo(Consumer<Integer>) in Lower is potentially ambiguous with foo(IntConsumer) in Upper
> 
> 
> (2) When a method is identified as part of an ambiguous pair, we were setting a `POTENTIALLY_AMBIGUOUS` flag on it. This caused it to be forever excluded from future warnings. For methods that are declared in the class we're visiting, this makes sense, but it doesn't make sense for inherited methods, because it disqualifies them from participating in the analysis of any other class that also inherits them.
> 
> As a result, for a class like the one below, the compiler was only generating one warning instead of three:
> 
> public interface SuperIface {
>     void foo(Consumer<Integer> c);
> }
> 
> public interface I1 extends SuperIface { 
>     void foo(IntConsumer c);        // warning was generated here
> }   
> 
> public interface I2 extends SuperIface { 
>     void foo(IntConsumer c);        // no warning was generated here
> }   
> 
> public interface I3 extends SuperIface { 
>     void foo(IntConsumer c);        // no warning was generated here
> }   
> 
> 
> With this patch the `POTENTIALLY_AMBIGUOUS` flag is no longer needed. I wasn't sure whether to renumber all the subsequent flags, or just leave an empty placeholder, so I chose the latter.
> 
> Finally, this fix uncovers new warnings in `java.base` and `java.desktop`, so these are now suppressed in the patch.

Archie L. Cobbs has updated the pull request incrementally with one additional commit since the last revision:

  Do some refactoring & cleanup suggested in reviews.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12645/files
  - new: https://git.openjdk.org/jdk/pull/12645/files/49cbaece..7d8a54c6

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12645&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12645&range=03-04

  Stats: 158 lines in 1 file changed: 76 ins; 31 del; 51 mod
  Patch: https://git.openjdk.org/jdk/pull/12645.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12645/head:pull/12645

PR: https://git.openjdk.org/jdk/pull/12645

From duke at openjdk.org  Sat Feb 25 03:57:31 2023
From: duke at openjdk.org (Archie L. Cobbs)
Date: Sat, 25 Feb 2023 03:57:31 GMT
Subject: RFR: 8026369: javac potentially ambiguous overload warning needs
 an improved scheme [v4]
In-Reply-To: <a76nqGkGeJn4TPnRRhiwHZTTCOhboaL0TDrbvHA2FLM=.110e0330-aa7a-49ed-8518-1ca076b1a4b3@github.com>
References: <IMxp3iCK--jYJ5Ia04i6QPYfnCHQobVcsmlI5aJXdqc=.892abcb8-7f2a-4fe9-aea2-1b1d41098a6d@github.com>
 <La7IUyuwT43IIKFp8OKW0Wd3iGPnVyvTHyJr00XXq8s=.4b0c537d-1fcd-416a-bd4f-7a1e88466be1@github.com>
 <a76nqGkGeJn4TPnRRhiwHZTTCOhboaL0TDrbvHA2FLM=.110e0330-aa7a-49ed-8518-1ca076b1a4b3@github.com>
Message-ID: <1Ffr-tqo8AxPD6H19yrf_OPfLUdTwcAFHLakCLlE0_w=.9877ea14-8715-4ae8-b6e8-210bd7e2159a@github.com>

On Fri, 24 Feb 2023 22:24:10 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> Archie L. Cobbs has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix typo in one comment and clarify another.
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java line 2730:
> 
>> 2728:             types.membersClosure(site, false).getSymbols(new ClashFilter(site), RECURSIVE).spliterator(), false)
>> 2729:           .map(MethodSymbol.class::cast)
>> 2730:           .filter(m -> m.owner.type.tsym != syms.objectType.tsym)
> 
> nit: this filter could be folded with the one above, `new ClashFilter(site)`

Should be fixed in 7d8a54c6679.

> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java line 2772:
> 
>> 2770:                 java.util.List<MethodSymbol> overriddenMethods = list.stream()
>> 2771:                   .filter(m2 -> m2 != m)
>> 2772:                   .filter(m2 -> overrides.test(m, m2))
> 
> can these two filters be folded?

Should be fixed in 7d8a54c6679.

-------------

PR: https://git.openjdk.org/jdk/pull/12645

From vromero at openjdk.org  Sat Feb 25 04:08:12 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Sat, 25 Feb 2023 04:08:12 GMT
Subject: RFR: 8026369: javac potentially ambiguous overload warning needs
 an improved scheme [v4]
In-Reply-To: <La7IUyuwT43IIKFp8OKW0Wd3iGPnVyvTHyJr00XXq8s=.4b0c537d-1fcd-416a-bd4f-7a1e88466be1@github.com>
References: <IMxp3iCK--jYJ5Ia04i6QPYfnCHQobVcsmlI5aJXdqc=.892abcb8-7f2a-4fe9-aea2-1b1d41098a6d@github.com>
 <La7IUyuwT43IIKFp8OKW0Wd3iGPnVyvTHyJr00XXq8s=.4b0c537d-1fcd-416a-bd4f-7a1e88466be1@github.com>
Message-ID: <PkTEmILJ73U76aqatkz4FJ4yZa5biyx4iMgbES9cMRk=.e8d752a1-af8c-4339-8362-d2187dd19287@github.com>

On Fri, 24 Feb 2023 18:09:16 GMT, Archie L. Cobbs <duke at openjdk.org> wrote:

>> This bug relates to the "potentially ambiguous overload" warning which is enabled by `-Xlint:overloads`.
>> 
>> The warning detects certain ambiguities that can cause problems for lambdas. For example, consider the interface `Spliterator.OfInt`, which declares these two methods:
>> 
>> void forEachRemaining(Consumer<? super Integer> action);
>> void forEachRemaining(IntConsumer action);
>> 
>> Both methods have the same name, same number of parameters, and take a lambda with the same "shape" in the same argument position. This causes an ambiguity in any code that wants to do this:
>> 
>>     spliterator.forEachRemaining(x -> { ... });
>> 
>> That code won't compile; instead, you'll get this error:
>> 
>> Ambiguity.java:4: error: reference to forEachRemaining is ambiguous
>>         spliterator.forEachRemaining(x -> { });
>>                    ^
>>   both method forEachRemaining(IntConsumer) in OfInt and method forEachRemaining(Consumer<? super Integer>) in OfInt match
>> 
>> 
>> The problem reported by the bug is that the warning fails to detect ambiguities which are created purely by inheritance, for example:
>> 
>> interface ConsumerOfInteger {
>>     void foo(Consumer<Integer> c);
>> }
>> 
>> interface IntegerConsumer {
>>     void foo(IntConsumer c);
>> }
>> 
>> // We should get a warning here...
>> interface Test extends ConsumerOfInteger, IntegerConsumer {
>> }
>> 
>> 
>> The cause of the bug is that ambiguities are detected on a per-method basis, by checking whether a method is part of an ambiguity pair when we visit that method. So if the methods in an ambiguity pair are inherited from two distinct supertypes, we'll miss the ambiguity.
>> 
>> To fix the problem, we need to look for ambiguities on a per-class level, checking all pairs of methods. However, it's not that simple - we only want to "blame" a class when that class itself, and not some supertype, is responsible for creating the ambiguity. For example, any interface extending `Spliterator.OfInt` will automatically inherit the two ambiguities mentioned above, but these are not the interface's fault so to speak so no warning should be generated. Making things more complicated is the fact that methods can be overridden and declared in generic classes so they only conflict in some subtypes, etc.
>> 
>> So we generate the warning when there are two methods m1 and m2 in a class C such that:
>> 
>> * m1 and m2 consitiute a "potentially ambiguous overload" (using the same definition as before)
>> * There is no direct supertype T of C such that m1 and m2, or some methods they override, both exist in T and constitute a "potentially ambiguous overload" as members of T
>> * We haven't already generated a warning for either m1 or m2 in class C
>> 
>> If either method is declared in C, we locate the warning there, but when both methods are inherited, there's no method declaration to point at so the warning is instead located at the class declaration.
>> 
>> I noticed a couple of other minor bugs; these are also being fixed here:
>> 
>> (1) For inherited methods, the method signatures were being reported as they are declared, rather than in the context of the class being visited. As a result, when a methods is inherited from a generic supertype, the ambiguity is less clear. Here's an example:
>> 
>> interface Upper<T> {
>>     void foo(T c);
>> }
>> 
>> interface Lower extends Upper<IntConsumer> {
>>     void foo(Consumer<Integer> c);
>> }
>> 
>> Currently, the error is reported as:
>> 
>> warning: [overloads] foo(Consumer<Integer>) in Lower is potentially ambiguous with foo(T) in Upper
>> 
>> Reporting the method signatures in the context of the class being visited makes the ambiguity clearer:
>> 
>> warning: [overloads] foo(Consumer<Integer>) in Lower is potentially ambiguous with foo(IntConsumer) in Upper
>> 
>> 
>> (2) When a method is identified as part of an ambiguous pair, we were setting a `POTENTIALLY_AMBIGUOUS` flag on it. This caused it to be forever excluded from future warnings. For methods that are declared in the class we're visiting, this makes sense, but it doesn't make sense for inherited methods, because it disqualifies them from participating in the analysis of any other class that also inherits them.
>> 
>> As a result, for a class like the one below, the compiler was only generating one warning instead of three:
>> 
>> public interface SuperIface {
>>     void foo(Consumer<Integer> c);
>> }
>> 
>> public interface I1 extends SuperIface { 
>>     void foo(IntConsumer c);        // warning was generated here
>> }   
>> 
>> public interface I2 extends SuperIface { 
>>     void foo(IntConsumer c);        // no warning was generated here
>> }   
>> 
>> public interface I3 extends SuperIface { 
>>     void foo(IntConsumer c);        // no warning was generated here
>> }   
>> 
>> 
>> With this patch the `POTENTIALLY_AMBIGUOUS` flag is no longer needed. I wasn't sure whether to renumber all the subsequent flags, or just leave an empty placeholder, so I chose the latter.
>> 
>> Finally, this fix uncovers new warnings in `java.base` and `java.desktop`, so these are now suppressed in the patch.
>
> Archie L. Cobbs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix typo in one comment and clarify another.

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java line 2736:

> 2734:           .sorted(Comparator.comparing(e -> e.getKey().toString()))
> 2735:           .map(Map.Entry::getValue)
> 2736:           .peek(Collections::reverse)               // seems to help warning ordering

not sure about reversing the order here, it seems to me that if the order is reversed then the warning is shown in the first occurrence of a method instead of in the second which is the offending one. So for example for this code:


    interface I1 {
        void foo(Consumer<Integer> c);
        void foo(IntConsumer c);
    }

the warning is shown for the first method when I think it should be shown for the second which is the one introducing the ambiguity

-------------

PR: https://git.openjdk.org/jdk/pull/12645

From duke at openjdk.org  Sat Feb 25 07:51:16 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Sat, 25 Feb 2023 07:51:16 GMT
Subject: Integrated: 8302871: Speed up StringLatin1.regionMatchesCI
In-Reply-To: <dnsiX3nRffjGjZXJG7lMAZj2FktEl2Wc1XfFthQ4iJs=.8c41438a-80a4-468f-ae0b-7322c9d6d952@github.com>
References: <dnsiX3nRffjGjZXJG7lMAZj2FktEl2Wc1XfFthQ4iJs=.8c41438a-80a4-468f-ae0b-7322c9d6d952@github.com>
Message-ID: <sAOHqzH7pSfMiHXIbqllTRq5Ck5rSaEanQguuNGysgY=.34d5df7a-d0ab-4761-89b9-58651a5f5771@github.com>

On Sat, 18 Feb 2023 09:21:25 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

> This PR suggests we can speed up `StringLatin1.regionMatchesCI` by applying 'the oldest ASCII trick in the book'.
> 
> The new static method `CharacterDataLatin1.equalsIgnoreCase` compares two latin1 bytes for equality ignoring case. `StringLatin1.regionMatchesCI` is updated to use `equalsIgnoreCase`
> 
> To verify the correctness of `equalsIgnoreCase`, a new test is added  to `EqualsIgnoreCase` with an exhaustive verification that all 256x256 latin1 code point pairs have an `equalsIgnoreCase` consistent with Character.toUpperCase, Character.toLowerCase.
> 
> Performance is tested for matching and mismatching cases of code point pairs picked from the ASCII letter, ASCII number and latin1 letter ranges. Results in the first comment below.

This pull request has now been integrated.

Changeset: 17e3769e
Author:    Eirik Bjorsnos <eirbjo at gmail.com>
Committer: Alan Bateman <alanb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/17e3769ed7190c3ba885e6434e1811bca2d66f13
Stats:     166 lines in 4 files changed: 148 ins; 5 del; 13 mod

8302871: Speed up StringLatin1.regionMatchesCI

Reviewed-by: redestad, martin, alanb

-------------

PR: https://git.openjdk.org/jdk/pull/12632

From alanb at openjdk.org  Sat Feb 25 07:52:16 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Sat, 25 Feb 2023 07:52:16 GMT
Subject: Integrated: 8302899: Executors.newSingleThreadExecutor can use Cleaner
 to shutdown executor
In-Reply-To: <tBrSZRn1GdrWMSRUsdNNyAWpkuS_FvtLwLuUKut6LH0=.cd1a7fcb-dbcf-45eb-b3d3-72ba17087566@github.com>
References: <tBrSZRn1GdrWMSRUsdNNyAWpkuS_FvtLwLuUKut6LH0=.cd1a7fcb-dbcf-45eb-b3d3-72ba17087566@github.com>
Message-ID: <WqPlKh4VoNJ1OzW_BVcpEGbDllDjx8gEgQJof92zYXs=.196a4132-8a33-472f-9c5e-83ae92c73dee@github.com>

On Mon, 20 Feb 2023 18:34:17 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> Executors.newSingleThreadExecutor returns a delegating ExecutorService that has finalizer to shutdown the underlying TPE when the wrapper is finalizable. It goes back to JDK 6 and JDK-6399443. This is the last non-empty finalizer in java.base. Removing it will likely lead to bug reports/complaints as the current behavior goes back to 2006. So the proposal is to just replace it with a Cleaner, trivially done in this case. As part of this change, I've added a RF to DelegatedExecutorService.shutdown to be consistent with the other methods - this is a benign change and avoids needing to puzzle over why it wasn't there previously. I've replaced the existing test with a more modern test that exercises more scenarios.

This pull request has now been integrated.

Changeset: 2e78d838
Author:    Alan Bateman <alanb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/2e78d838a5e55e3ef68bc8df2b40615e8bdb0389
Stats:     138 lines in 2 files changed: 53 ins; 11 del; 74 mod

8302899: Executors.newSingleThreadExecutor can use Cleaner to shutdown executor

Reviewed-by: rriggs, martin, dfuchs, bchristi

-------------

PR: https://git.openjdk.org/jdk/pull/12675

From mdoerr at openjdk.org  Sat Feb 25 09:43:04 2023
From: mdoerr at openjdk.org (Martin Doerr)
Date: Sat, 25 Feb 2023 09:43:04 GMT
Subject: RFR: 8303040: linux PPC64le: Implementation of Foreign Function &
 Memory API (Preview) [v3]
In-Reply-To: <1PZeZa46N1rA3R0IZs-4TIKP5d1gJYMDlWlfv4ApPV8=.6c5fb2fd-2b75-4dc8-979f-87c33bbe6d9d@github.com>
References: <Yuxy6FrsDAN79ya8w8UIkvytGr25zGllDPtPJ1QbGwc=.182664b2-6d8c-497e-a4ae-95e0ad007cf9@github.com>
 <8b3vVrV22RuhdRoRYacXV0ZeghFGgKkC8S_z-iMrzAQ=.dd84b743-8b51-4281-8f5f-f9eff6207bc7@github.com>
 <HT8kQfjS98dYHeAMcNL5latokRiw3YK8npxl5yCD4hw=.28b19bac-cbfa-4461-a1db-c899c55b7485@github.com>
 <wBVqRDFM23KM8fjjPtUFNdW56FYsSpvOAVvHmpdjbzo=.7c429606-ac19-4f36-8e25-459534983924@github.com>
 <FPIzIHMG6nWOehx_lww3PUoJ4NistRZBE4sHLeQBBro=.903212c7-3334-4aea-8649-ae3f2df9e44f@github.com>
 <EpZEmuoVk-reCoDagN9Xj4j_iHTUN6qlntAdT-w7TXs=.62ae4e09-459a-4ef0-9c80-53909da8f504@github.com>
 <1PZeZa46N1rA3R0IZs-4TIKP5d1gJYMDlWlfv4ApPV8=.6c5fb2fd-2b75-4dc8-979f-87c33bbe6d9d@github.com>
Message-ID: <MKpTZUOZmOh4qFUl_a_--78OjJPN-WpTHuYHpf6KXhE=.ef8baf31-2c89-4acd-8b33-8f292e6ba4ca@github.com>

On Fri, 24 Feb 2023 10:42:06 GMT, Robbin Ehn <rehn at openjdk.org> wrote:

> > > > ~I don't think we've done that much testing with UseSystemMemoryBarrier since it was added~. I'm a bit nervous about turning it on by default since it's currently also used for JNI. Let's see what Robbin thinks.
> > > 
> > > 
> > > For reliability: On every Oracle tier 5 we run these test two groups: vmTestbase_nsk_jvmti, open/test/hotspot/jtreg/:hotspot_runtime For each of linux_x64_debug, windows_x64, linux_aarch64_debug with sysmembar on. I picked jvmti as this is very heavy on 'JNI'. No issues reported that I know about. We also have this test: SystemMembarHandshakeTransitionTest.java which only JNI transisition with this options.
> > > For performance, the heavy lifting is on reader of thread state and the only case I have identified is JFR.
> > > I suggest changing the default now, if there is issues we have time to revert it back before RDP1.
> > 
> > 
> > Thanks for your prompt reply! I agree, this is a good time to enable it. Do you want to do it? We'll support it and run tests on our machines and platforms. I think JFR users who want a very high sampling rate can switch it off. Making the flag diagnostic is fine with me, but that shouldn't get discussed in this PR :-)
> 
> I will be skiing next week, if you want it now, I suggest you do it, otherwise I can when I'm back.

https://github.com/openjdk/jdk/pull/12753

-------------

PR: https://git.openjdk.org/jdk/pull/12708

From vromero at openjdk.org  Sat Feb 25 12:24:06 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Sat, 25 Feb 2023 12:24:06 GMT
Subject: RFR: 8026369: javac potentially ambiguous overload warning needs
 an improved scheme [v5]
In-Reply-To: <kfjz51X87aU9nppjkM08j-GuyuWOQ9m_vzTugkjYxVE=.75e83ec8-5810-43cb-8bd1-2a3b5db76b0d@github.com>
References: <IMxp3iCK--jYJ5Ia04i6QPYfnCHQobVcsmlI5aJXdqc=.892abcb8-7f2a-4fe9-aea2-1b1d41098a6d@github.com>
 <kfjz51X87aU9nppjkM08j-GuyuWOQ9m_vzTugkjYxVE=.75e83ec8-5810-43cb-8bd1-2a3b5db76b0d@github.com>
Message-ID: <6T8-fJe2Ova0tUXbJPkEQEXB42bLiZnStlHmucaAUTQ=.162c3a53-1409-4710-bc7e-0fe22b8da263@github.com>

On Sat, 25 Feb 2023 03:57:30 GMT, Archie L. Cobbs <duke at openjdk.org> wrote:

>> This bug relates to the "potentially ambiguous overload" warning which is enabled by `-Xlint:overloads`.
>> 
>> The warning detects certain ambiguities that can cause problems for lambdas. For example, consider the interface `Spliterator.OfInt`, which declares these two methods:
>> 
>> void forEachRemaining(Consumer<? super Integer> action);
>> void forEachRemaining(IntConsumer action);
>> 
>> Both methods have the same name, same number of parameters, and take a lambda with the same "shape" in the same argument position. This causes an ambiguity in any code that wants to do this:
>> 
>>     spliterator.forEachRemaining(x -> { ... });
>> 
>> That code won't compile; instead, you'll get this error:
>> 
>> Ambiguity.java:4: error: reference to forEachRemaining is ambiguous
>>         spliterator.forEachRemaining(x -> { });
>>                    ^
>>   both method forEachRemaining(IntConsumer) in OfInt and method forEachRemaining(Consumer<? super Integer>) in OfInt match
>> 
>> 
>> The problem reported by the bug is that the warning fails to detect ambiguities which are created purely by inheritance, for example:
>> 
>> interface ConsumerOfInteger {
>>     void foo(Consumer<Integer> c);
>> }
>> 
>> interface IntegerConsumer {
>>     void foo(IntConsumer c);
>> }
>> 
>> // We should get a warning here...
>> interface Test extends ConsumerOfInteger, IntegerConsumer {
>> }
>> 
>> 
>> The cause of the bug is that ambiguities are detected on a per-method basis, by checking whether a method is part of an ambiguity pair when we visit that method. So if the methods in an ambiguity pair are inherited from two distinct supertypes, we'll miss the ambiguity.
>> 
>> To fix the problem, we need to look for ambiguities on a per-class level, checking all pairs of methods. However, it's not that simple - we only want to "blame" a class when that class itself, and not some supertype, is responsible for creating the ambiguity. For example, any interface extending `Spliterator.OfInt` will automatically inherit the two ambiguities mentioned above, but these are not the interface's fault so to speak so no warning should be generated. Making things more complicated is the fact that methods can be overridden and declared in generic classes so they only conflict in some subtypes, etc.
>> 
>> So we generate the warning when there are two methods m1 and m2 in a class C such that:
>> 
>> * m1 and m2 consitiute a "potentially ambiguous overload" (using the same definition as before)
>> * There is no direct supertype T of C such that m1 and m2, or some methods they override, both exist in T and constitute a "potentially ambiguous overload" as members of T
>> * We haven't already generated a warning for either m1 or m2 in class C
>> 
>> If either method is declared in C, we locate the warning there, but when both methods are inherited, there's no method declaration to point at so the warning is instead located at the class declaration.
>> 
>> I noticed a couple of other minor bugs; these are also being fixed here:
>> 
>> (1) For inherited methods, the method signatures were being reported as they are declared, rather than in the context of the class being visited. As a result, when a methods is inherited from a generic supertype, the ambiguity is less clear. Here's an example:
>> 
>> interface Upper<T> {
>>     void foo(T c);
>> }
>> 
>> interface Lower extends Upper<IntConsumer> {
>>     void foo(Consumer<Integer> c);
>> }
>> 
>> Currently, the error is reported as:
>> 
>> warning: [overloads] foo(Consumer<Integer>) in Lower is potentially ambiguous with foo(T) in Upper
>> 
>> Reporting the method signatures in the context of the class being visited makes the ambiguity clearer:
>> 
>> warning: [overloads] foo(Consumer<Integer>) in Lower is potentially ambiguous with foo(IntConsumer) in Upper
>> 
>> 
>> (2) When a method is identified as part of an ambiguous pair, we were setting a `POTENTIALLY_AMBIGUOUS` flag on it. This caused it to be forever excluded from future warnings. For methods that are declared in the class we're visiting, this makes sense, but it doesn't make sense for inherited methods, because it disqualifies them from participating in the analysis of any other class that also inherits them.
>> 
>> As a result, for a class like the one below, the compiler was only generating one warning instead of three:
>> 
>> public interface SuperIface {
>>     void foo(Consumer<Integer> c);
>> }
>> 
>> public interface I1 extends SuperIface { 
>>     void foo(IntConsumer c);        // warning was generated here
>> }   
>> 
>> public interface I2 extends SuperIface { 
>>     void foo(IntConsumer c);        // no warning was generated here
>> }   
>> 
>> public interface I3 extends SuperIface { 
>>     void foo(IntConsumer c);        // no warning was generated here
>> }   
>> 
>> 
>> With this patch the `POTENTIALLY_AMBIGUOUS` flag is no longer needed. I wasn't sure whether to renumber all the subsequent flags, or just leave an empty placeholder, so I chose the latter.
>> 
>> Finally, this fix uncovers new warnings in `java.base` and `java.desktop`, so these are now suppressed in the patch.
>
> Archie L. Cobbs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Do some refactoring & cleanup suggested in reviews.

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java line 101:

> 99:     // Flag bits indicating which item(s) chosen from a pair of items
> 100:     private static final int FIRST = 0x01;
> 101:     private static final int SECOND = 0x02;

not sure about this flags, won't they clash with the existing flags?

-------------

PR: https://git.openjdk.org/jdk/pull/12645

From vromero at openjdk.org  Sat Feb 25 13:41:16 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Sat, 25 Feb 2023 13:41:16 GMT
Subject: RFR: 8026369: javac potentially ambiguous overload warning needs
 an improved scheme [v5]
In-Reply-To: <kfjz51X87aU9nppjkM08j-GuyuWOQ9m_vzTugkjYxVE=.75e83ec8-5810-43cb-8bd1-2a3b5db76b0d@github.com>
References: <IMxp3iCK--jYJ5Ia04i6QPYfnCHQobVcsmlI5aJXdqc=.892abcb8-7f2a-4fe9-aea2-1b1d41098a6d@github.com>
 <kfjz51X87aU9nppjkM08j-GuyuWOQ9m_vzTugkjYxVE=.75e83ec8-5810-43cb-8bd1-2a3b5db76b0d@github.com>
Message-ID: <zmXwajsexkHVYrThszlpiKVhvbGQk86OAgpl7XUqesk=.54943ead-e540-46e7-b4b4-31595f823206@github.com>

On Sat, 25 Feb 2023 03:57:30 GMT, Archie L. Cobbs <duke at openjdk.org> wrote:

>> This bug relates to the "potentially ambiguous overload" warning which is enabled by `-Xlint:overloads`.
>> 
>> The warning detects certain ambiguities that can cause problems for lambdas. For example, consider the interface `Spliterator.OfInt`, which declares these two methods:
>> 
>> void forEachRemaining(Consumer<? super Integer> action);
>> void forEachRemaining(IntConsumer action);
>> 
>> Both methods have the same name, same number of parameters, and take a lambda with the same "shape" in the same argument position. This causes an ambiguity in any code that wants to do this:
>> 
>>     spliterator.forEachRemaining(x -> { ... });
>> 
>> That code won't compile; instead, you'll get this error:
>> 
>> Ambiguity.java:4: error: reference to forEachRemaining is ambiguous
>>         spliterator.forEachRemaining(x -> { });
>>                    ^
>>   both method forEachRemaining(IntConsumer) in OfInt and method forEachRemaining(Consumer<? super Integer>) in OfInt match
>> 
>> 
>> The problem reported by the bug is that the warning fails to detect ambiguities which are created purely by inheritance, for example:
>> 
>> interface ConsumerOfInteger {
>>     void foo(Consumer<Integer> c);
>> }
>> 
>> interface IntegerConsumer {
>>     void foo(IntConsumer c);
>> }
>> 
>> // We should get a warning here...
>> interface Test extends ConsumerOfInteger, IntegerConsumer {
>> }
>> 
>> 
>> The cause of the bug is that ambiguities are detected on a per-method basis, by checking whether a method is part of an ambiguity pair when we visit that method. So if the methods in an ambiguity pair are inherited from two distinct supertypes, we'll miss the ambiguity.
>> 
>> To fix the problem, we need to look for ambiguities on a per-class level, checking all pairs of methods. However, it's not that simple - we only want to "blame" a class when that class itself, and not some supertype, is responsible for creating the ambiguity. For example, any interface extending `Spliterator.OfInt` will automatically inherit the two ambiguities mentioned above, but these are not the interface's fault so to speak so no warning should be generated. Making things more complicated is the fact that methods can be overridden and declared in generic classes so they only conflict in some subtypes, etc.
>> 
>> So we generate the warning when there are two methods m1 and m2 in a class C such that:
>> 
>> * m1 and m2 consitiute a "potentially ambiguous overload" (using the same definition as before)
>> * There is no direct supertype T of C such that m1 and m2, or some methods they override, both exist in T and constitute a "potentially ambiguous overload" as members of T
>> * We haven't already generated a warning for either m1 or m2 in class C
>> 
>> If either method is declared in C, we locate the warning there, but when both methods are inherited, there's no method declaration to point at so the warning is instead located at the class declaration.
>> 
>> I noticed a couple of other minor bugs; these are also being fixed here:
>> 
>> (1) For inherited methods, the method signatures were being reported as they are declared, rather than in the context of the class being visited. As a result, when a methods is inherited from a generic supertype, the ambiguity is less clear. Here's an example:
>> 
>> interface Upper<T> {
>>     void foo(T c);
>> }
>> 
>> interface Lower extends Upper<IntConsumer> {
>>     void foo(Consumer<Integer> c);
>> }
>> 
>> Currently, the error is reported as:
>> 
>> warning: [overloads] foo(Consumer<Integer>) in Lower is potentially ambiguous with foo(T) in Upper
>> 
>> Reporting the method signatures in the context of the class being visited makes the ambiguity clearer:
>> 
>> warning: [overloads] foo(Consumer<Integer>) in Lower is potentially ambiguous with foo(IntConsumer) in Upper
>> 
>> 
>> (2) When a method is identified as part of an ambiguous pair, we were setting a `POTENTIALLY_AMBIGUOUS` flag on it. This caused it to be forever excluded from future warnings. For methods that are declared in the class we're visiting, this makes sense, but it doesn't make sense for inherited methods, because it disqualifies them from participating in the analysis of any other class that also inherits them.
>> 
>> As a result, for a class like the one below, the compiler was only generating one warning instead of three:
>> 
>> public interface SuperIface {
>>     void foo(Consumer<Integer> c);
>> }
>> 
>> public interface I1 extends SuperIface { 
>>     void foo(IntConsumer c);        // warning was generated here
>> }   
>> 
>> public interface I2 extends SuperIface { 
>>     void foo(IntConsumer c);        // no warning was generated here
>> }   
>> 
>> public interface I3 extends SuperIface { 
>>     void foo(IntConsumer c);        // no warning was generated here
>> }   
>> 
>> 
>> With this patch the `POTENTIALLY_AMBIGUOUS` flag is no longer needed. I wasn't sure whether to renumber all the subsequent flags, or just leave an empty placeholder, so I chose the latter.
>> 
>> Finally, this fix uncovers new warnings in `java.base` and `java.desktop`, so these are now suppressed in the patch.
>
> Archie L. Cobbs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Do some refactoring & cleanup suggested in reviews.

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java line 2765:

> 2763:      *  any other methods; in this case the class is definitely responsible.
> 2764:      */
> 2765:     BiPredicate<MethodSymbol, MethodSymbol> buildResponsiblePredicate(Type site,

this method not only builds the predicate as its name indicates, it also removes methods from the `methodGroups`, not saying that we should split this method but I think that this removing activity should be mentioned in the comment above

-------------

PR: https://git.openjdk.org/jdk/pull/12645

From duke at openjdk.org  Sat Feb 25 16:07:24 2023
From: duke at openjdk.org (Archie L. Cobbs)
Date: Sat, 25 Feb 2023 16:07:24 GMT
Subject: RFR: 8026369: javac potentially ambiguous overload warning needs
 an improved scheme [v6]
In-Reply-To: <IMxp3iCK--jYJ5Ia04i6QPYfnCHQobVcsmlI5aJXdqc=.892abcb8-7f2a-4fe9-aea2-1b1d41098a6d@github.com>
References: <IMxp3iCK--jYJ5Ia04i6QPYfnCHQobVcsmlI5aJXdqc=.892abcb8-7f2a-4fe9-aea2-1b1d41098a6d@github.com>
Message-ID: <7CIC6bBj00Mh18mr-g3j6HszbQzf88ND1OHaCW8_ydk=.b6ad3d5b-8bec-47ff-a091-bc483feaee12@github.com>

> This bug relates to the "potentially ambiguous overload" warning which is enabled by `-Xlint:overloads`.
> 
> The warning detects certain ambiguities that can cause problems for lambdas. For example, consider the interface `Spliterator.OfInt`, which declares these two methods:
> 
> void forEachRemaining(Consumer<? super Integer> action);
> void forEachRemaining(IntConsumer action);
> 
> Both methods have the same name, same number of parameters, and take a lambda with the same "shape" in the same argument position. This causes an ambiguity in any code that wants to do this:
> 
>     spliterator.forEachRemaining(x -> { ... });
> 
> That code won't compile; instead, you'll get this error:
> 
> Ambiguity.java:4: error: reference to forEachRemaining is ambiguous
>         spliterator.forEachRemaining(x -> { });
>                    ^
>   both method forEachRemaining(IntConsumer) in OfInt and method forEachRemaining(Consumer<? super Integer>) in OfInt match
> 
> 
> The problem reported by the bug is that the warning fails to detect ambiguities which are created purely by inheritance, for example:
> 
> interface ConsumerOfInteger {
>     void foo(Consumer<Integer> c);
> }
> 
> interface IntegerConsumer {
>     void foo(IntConsumer c);
> }
> 
> // We should get a warning here...
> interface Test extends ConsumerOfInteger, IntegerConsumer {
> }
> 
> 
> The cause of the bug is that ambiguities are detected on a per-method basis, by checking whether a method is part of an ambiguity pair when we visit that method. So if the methods in an ambiguity pair are inherited from two distinct supertypes, we'll miss the ambiguity.
> 
> To fix the problem, we need to look for ambiguities on a per-class level, checking all pairs of methods. However, it's not that simple - we only want to "blame" a class when that class itself, and not some supertype, is responsible for creating the ambiguity. For example, any interface extending `Spliterator.OfInt` will automatically inherit the two ambiguities mentioned above, but these are not the interface's fault so to speak so no warning should be generated. Making things more complicated is the fact that methods can be overridden and declared in generic classes so they only conflict in some subtypes, etc.
> 
> So we generate the warning when there are two methods m1 and m2 in a class C such that:
> 
> * m1 and m2 consitiute a "potentially ambiguous overload" (using the same definition as before)
> * There is no direct supertype T of C such that m1 and m2, or some methods they override, both exist in T and constitute a "potentially ambiguous overload" as members of T
> * We haven't already generated a warning for either m1 or m2 in class C
> 
> If either method is declared in C, we locate the warning there, but when both methods are inherited, there's no method declaration to point at so the warning is instead located at the class declaration.
> 
> I noticed a couple of other minor bugs; these are also being fixed here:
> 
> (1) For inherited methods, the method signatures were being reported as they are declared, rather than in the context of the class being visited. As a result, when a methods is inherited from a generic supertype, the ambiguity is less clear. Here's an example:
> 
> interface Upper<T> {
>     void foo(T c);
> }
> 
> interface Lower extends Upper<IntConsumer> {
>     void foo(Consumer<Integer> c);
> }
> 
> Currently, the error is reported as:
> 
> warning: [overloads] foo(Consumer<Integer>) in Lower is potentially ambiguous with foo(T) in Upper
> 
> Reporting the method signatures in the context of the class being visited makes the ambiguity clearer:
> 
> warning: [overloads] foo(Consumer<Integer>) in Lower is potentially ambiguous with foo(IntConsumer) in Upper
> 
> 
> (2) When a method is identified as part of an ambiguous pair, we were setting a `POTENTIALLY_AMBIGUOUS` flag on it. This caused it to be forever excluded from future warnings. For methods that are declared in the class we're visiting, this makes sense, but it doesn't make sense for inherited methods, because it disqualifies them from participating in the analysis of any other class that also inherits them.
> 
> As a result, for a class like the one below, the compiler was only generating one warning instead of three:
> 
> public interface SuperIface {
>     void foo(Consumer<Integer> c);
> }
> 
> public interface I1 extends SuperIface { 
>     void foo(IntConsumer c);        // warning was generated here
> }   
> 
> public interface I2 extends SuperIface { 
>     void foo(IntConsumer c);        // no warning was generated here
> }   
> 
> public interface I3 extends SuperIface { 
>     void foo(IntConsumer c);        // no warning was generated here
> }   
> 
> 
> With this patch the `POTENTIALLY_AMBIGUOUS` flag is no longer needed. I wasn't sure whether to renumber all the subsequent flags, or just leave an empty placeholder, so I chose the latter.
> 
> Finally, this fix uncovers new warnings in `java.base` and `java.desktop`, so these are now suppressed in the patch.

Archie L. Cobbs has updated the pull request incrementally with two additional commits since the last revision:

 - Process methods in order so the second method triggers the warning.
 - Clean up previous buildResponsiblePredicate() refactoring, which was incomplete.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12645/files
  - new: https://git.openjdk.org/jdk/pull/12645/files/7d8a54c6..e25ceced

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12645&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12645&range=04-05

  Stats: 32 lines in 3 files changed: 7 ins; 10 del; 15 mod
  Patch: https://git.openjdk.org/jdk/pull/12645.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12645/head:pull/12645

PR: https://git.openjdk.org/jdk/pull/12645

From duke at openjdk.org  Sat Feb 25 16:07:25 2023
From: duke at openjdk.org (Archie L. Cobbs)
Date: Sat, 25 Feb 2023 16:07:25 GMT
Subject: RFR: 8026369: javac potentially ambiguous overload warning needs
 an improved scheme [v4]
In-Reply-To: <PkTEmILJ73U76aqatkz4FJ4yZa5biyx4iMgbES9cMRk=.e8d752a1-af8c-4339-8362-d2187dd19287@github.com>
References: <IMxp3iCK--jYJ5Ia04i6QPYfnCHQobVcsmlI5aJXdqc=.892abcb8-7f2a-4fe9-aea2-1b1d41098a6d@github.com>
 <La7IUyuwT43IIKFp8OKW0Wd3iGPnVyvTHyJr00XXq8s=.4b0c537d-1fcd-416a-bd4f-7a1e88466be1@github.com>
 <PkTEmILJ73U76aqatkz4FJ4yZa5biyx4iMgbES9cMRk=.e8d752a1-af8c-4339-8362-d2187dd19287@github.com>
Message-ID: <ieDiuJJzNO2TiSNlfeceVAB0ZKDhOWOINlg3HSgUR_4=.2110f7f4-ba44-4c05-a3ab-8311a7da453d@github.com>

On Sat, 25 Feb 2023 04:05:29 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> Archie L. Cobbs has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix typo in one comment and clarify another.
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java line 2736:
> 
>> 2734:           .sorted(Comparator.comparing(e -> e.getKey().toString()))
>> 2735:           .map(Map.Entry::getValue)
>> 2736:           .peek(Collections::reverse)               // seems to help warning ordering
> 
> not sure about reversing the order here, it seems to me that if the order is reversed then the warning is shown in the first occurrence of a method instead of in the second which is the offending one. So for example for this code:
> 
> 
>     interface I1 {
>         void foo(Consumer<Integer> c);
>         void foo(IntConsumer c);
>     }
> 
> the warning is shown for the first method when I think it should be shown for the second which is the one introducing the ambiguity
> 
> EDIT, after your last commit, this comment now applies to: `methodGroups.forEach(Collections::reverse);`

The reversing was originally done in order to maintain consistency with the existing regression test outputs. But you are right - it results in visiting the methods backwards.

Fixed in e25ceced163.

-------------

PR: https://git.openjdk.org/jdk/pull/12645

From duke at openjdk.org  Sat Feb 25 16:07:27 2023
From: duke at openjdk.org (Archie L. Cobbs)
Date: Sat, 25 Feb 2023 16:07:27 GMT
Subject: RFR: 8026369: javac potentially ambiguous overload warning needs
 an improved scheme [v5]
In-Reply-To: <zmXwajsexkHVYrThszlpiKVhvbGQk86OAgpl7XUqesk=.54943ead-e540-46e7-b4b4-31595f823206@github.com>
References: <IMxp3iCK--jYJ5Ia04i6QPYfnCHQobVcsmlI5aJXdqc=.892abcb8-7f2a-4fe9-aea2-1b1d41098a6d@github.com>
 <kfjz51X87aU9nppjkM08j-GuyuWOQ9m_vzTugkjYxVE=.75e83ec8-5810-43cb-8bd1-2a3b5db76b0d@github.com>
 <zmXwajsexkHVYrThszlpiKVhvbGQk86OAgpl7XUqesk=.54943ead-e540-46e7-b4b4-31595f823206@github.com>
Message-ID: <kHDAf6VSsTMiO34L5HgR-AlpGcKTgRUyL689crUUaJs=.08571e02-e807-4f17-abef-9d058c2be4ae@github.com>

On Sat, 25 Feb 2023 13:38:05 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> Archie L. Cobbs has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Do some refactoring & cleanup suggested in reviews.
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java line 2765:
> 
>> 2763:      *  any other methods; in this case the class is definitely responsible.
>> 2764:      */
>> 2765:     BiPredicate<MethodSymbol, MethodSymbol> buildResponsiblePredicate(Type site,
> 
> this method not only builds the predicate as its name indicates, it also removes methods from the `methodGroups`, not saying that we should split this method but I think that this removing activity should be mentioned in the comment above

Oops, my bad - previous refactoring was incomplete.

Should be fixed in e25ceced163.

Thanks again for the careful review!

-------------

PR: https://git.openjdk.org/jdk/pull/12645

From aturbanov at openjdk.org  Sat Feb 25 18:10:10 2023
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Sat, 25 Feb 2023 18:10:10 GMT
Subject: RFR: JDK-8302040: Port fdlibm sqrt to Java [v3]
In-Reply-To: <bzR0JfDQW03UtxdHgqbcLHlBQzPvp2NitCM6Y_ENdco=.1a3c47be-ebf8-420f-903b-964e82fafddf@github.com>
References: <rjVM2lWPdsvPcfLF3oNShP-cSN8-P-i16ikUC3sTgIg=.1d4f470d-2ac9-4394-b55e-099affce763f@github.com>
 <bzR0JfDQW03UtxdHgqbcLHlBQzPvp2NitCM6Y_ENdco=.1a3c47be-ebf8-420f-903b-964e82fafddf@github.com>
Message-ID: <YBUz5ymX_sqGNIegnEttXYjVkw7hwZJfarFAtEjET1g=.147d25a0-5de6-418f-afe0-bfa1a61d17af@github.com>

On Fri, 24 Feb 2023 18:40:38 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> The wheel of FDLIBM porting turns a notch and sqrt comes into play.
>> 
>> While the sqrt operation usually has a hardware implementation that is intrinsified, for completeness a software implementation should be available as well.
>
> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add one one unsigned shift comment.

src/java.base/share/classes/java/lang/FdLibm.java line 600:

> 598: 
> 599:             // take care of Inf and NaN
> 600:             if((ix0 & 0x7ff0_0000) == 0x7ff0_0000) {

Suggestion:

            if ((ix0 & 0x7ff0_0000) == 0x7ff0_0000) {

src/java.base/share/classes/java/lang/FdLibm.java line 639:

> 637:             r = 0x0020_0000;        // r = moving bit from right to left
> 638: 
> 639:             while(r != 0) {

Suggestion:

            while (r != 0) {

src/java.base/share/classes/java/lang/FdLibm.java line 641:

> 639:             while(r != 0) {
> 640:                 t = s0 + r;
> 641:                 if(t <= ix0) {

Suggestion:

                if (t <= ix0) {

src/java.base/share/classes/java/lang/FdLibm.java line 655:

> 653:                 t1 = s1 + r;
> 654:                 t  = s0;
> 655:                 if((t < ix0) ||

Suggestion:

                if ((t < ix0) ||

src/java.base/share/classes/java/lang/FdLibm.java line 657:

> 655:                 if((t < ix0) ||
> 656:                    ((t == ix0) && (Integer.compareUnsigned(t1, ix1) <= 0 ))) { // t1 <= ix1
> 657:                     s1  = t1 + r;

Suggestion:

                    s1 = t1 + r;

-------------

PR: https://git.openjdk.org/jdk/pull/12736

From aturbanov at openjdk.org  Sat Feb 25 18:15:05 2023
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Sat, 25 Feb 2023 18:15:05 GMT
Subject: RFR: 8302983: ZoneRulesProvider.registerProvider() twice will
 remove provider [v3]
In-Reply-To: <TdzFe2DcY9xBD-ckKlwKYcNdT-bpMDfwgx6sxCDfIYw=.26f261c1-8238-44ed-ad87-ee9d75c96ad1@github.com>
References: <AAfM5rBLeq2B3ttHBX_7kw0_rjfIVPSdcEL23HiOhVs=.b17c2586-b0bc-46ad-9501-0cf8363f82b9@github.com>
 <TdzFe2DcY9xBD-ckKlwKYcNdT-bpMDfwgx6sxCDfIYw=.26f261c1-8238-44ed-ad87-ee9d75c96ad1@github.com>
Message-ID: <dLZwe8IiDv6NwROACiF9q5xFR2AB8dZLf9YcW1VHO0E=.40fadf2f-c3a4-4291-9418-b9367fbfd12c@github.com>

On Sat, 25 Feb 2023 00:07:45 GMT, Madjosz <duke at openjdk.org> wrote:

>> Fixes JDK-8302983 (and duplicate JDK-8302898)
>
> Madjosz has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:
> 
>   apply review comments

src/java.base/share/classes/java/time/zone/ZoneRulesProvider.java line 319:

> 317:             ZoneRulesProvider old = ZONES.putIfAbsent(zoneId, provider);
> 318:             if (old != null) {
> 319:                 if(!old.equals(provider)) {

Suggestion:

                if (!old.equals(provider)) {

src/java.base/share/classes/java/time/zone/ZoneRulesProvider.java line 322:

> 320:                     // restore old state
> 321:                     ZONES.put(zoneId, old);
> 322:                     provider.provideZoneIds().stream()

Can we drop `.stream()` call and just call `.forEach` directly?

-------------

PR: https://git.openjdk.org/jdk/pull/12690

From aturbanov at openjdk.org  Sat Feb 25 19:14:05 2023
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Sat, 25 Feb 2023 19:14:05 GMT
Subject: RFR: 8302267: [jittester] Improve separation of test generation
 and execution [v2]
In-Reply-To: <HPYLuHpPdXMDXg2kEtUdEDf1FxkfvLwRRomQtM7oybQ=.726d67e9-f4c0-4aa9-98ff-76d89ddf8034@github.com>
References: <yHw6Lto-nJtPP61cZLDF354osHA-ioeq7_lgpefLvog=.6de22e18-0613-4ffb-a753-b66b95e9d52b@github.com>
 <HPYLuHpPdXMDXg2kEtUdEDf1FxkfvLwRRomQtM7oybQ=.726d67e9-f4c0-4aa9-98ff-76d89ddf8034@github.com>
Message-ID: <TofA0mHjbSK2ucNWjeegmyaGnXwo-BDhshhegGfEmvI=.f2e08125-d38e-4ee4-9462-b3ad0bbef6b0@github.com>

On Wed, 22 Feb 2023 17:43:23 GMT, Evgeny Nikitin <enikitin at openjdk.org> wrote:

>> Please review a set of improvements that should improve working with other fuzzing generators and usage of JitTesterDriver with tests generated not by the JITTester:
>> 
>> - Provide better separation of individual test generation from java file writing, compiling, executing, etc.;
>> - Introduce distinct Phases of the generation process (Generation, Compilation, GoldRun and VerificationRun);
>> - Extract JItTesterDriver headers generation so that it would be possible to provide other header generators;
>> - Introduce error tolerance to not get distracted by OOMEs, intrinsics missing in the compiled code, etc.;
>> - Make it possible to specify time limit for an individual test generation;
>> - Give better control over temp/workdir creation and cleaning;
>> - Unify external process running;
>> - Introduce UTF-8 support in external processes' output and human-readable escaping of it;
>
> Evgeny Nikitin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Ignore large files

test/hotspot/jtreg/testlibrary/jittester/src/jdk/test/lib/jittester/HeaderFormatter.java line 38:

> 36: 
> 37:     public static class Builder {
> 38:         private Function<String, String[]>  preRunActions = s -> new String[0];

Suggestion:

        private Function<String, String[]> preRunActions = s -> new String[0];

test/hotspot/jtreg/testlibrary/jittester/src/jdk/test/lib/jittester/HeaderFormatter.java line 78:

> 76:     }
> 77: 
> 78:     public  String getJtregHeader(String mainClassName) {

Suggestion:

    public String getJtregHeader(String mainClassName) {

test/hotspot/jtreg/testlibrary/jittester/src/jdk/test/lib/jittester/ProcessRunner.java line 59:

> 57: 
> 58:         src.chars().forEachOrdered(code -> {
> 59:             if  ((code >= 32) && (code <= 126) && (code != 92) || (code == 9)) {

Suggestion:

            if ((code >= 32) && (code <= 126) && (code != 92) || (code == 9)) {

-------------

PR: https://git.openjdk.org/jdk/pull/12527

From darcy at openjdk.org  Sat Feb 25 21:05:05 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Sat, 25 Feb 2023 21:05:05 GMT
Subject: RFR: JDK-8302040: Port fdlibm sqrt to Java [v3]
In-Reply-To: <qYTWP2l6jbtTCQb-He95PVZLX8yqDJLblNxj74EnAsI=.e730e73c-8590-4465-bfc1-8ee504c80520@github.com>
References: <rjVM2lWPdsvPcfLF3oNShP-cSN8-P-i16ikUC3sTgIg=.1d4f470d-2ac9-4394-b55e-099affce763f@github.com>
 <qYTWP2l6jbtTCQb-He95PVZLX8yqDJLblNxj74EnAsI=.e730e73c-8590-4465-bfc1-8ee504c80520@github.com>
Message-ID: <Llda0SmxQwosS9MOFMIGVAkpd6135qHphMyraYvwEF4=.1a8ac934-2add-4650-b63c-668dba6f7907@github.com>

On Thu, 23 Feb 2023 23:30:46 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> I'll revert commenting out the intrinsic annotation before pushing.

Turns out some VM updates are needed to preserve the intrinsic if this method declaration is changed; I'll be contacting the HotSpot team for assistance.

-------------

PR: https://git.openjdk.org/jdk/pull/12736

From darcy at openjdk.org  Sat Feb 25 23:05:33 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Sat, 25 Feb 2023 23:05:33 GMT
Subject: RFR: JDK-8302040: Port fdlibm sqrt to Java [v4]
In-Reply-To: <rjVM2lWPdsvPcfLF3oNShP-cSN8-P-i16ikUC3sTgIg=.1d4f470d-2ac9-4394-b55e-099affce763f@github.com>
References: <rjVM2lWPdsvPcfLF3oNShP-cSN8-P-i16ikUC3sTgIg=.1d4f470d-2ac9-4394-b55e-099affce763f@github.com>
Message-ID: <xk8b9U2h-ASlH_QtCVhYvcvfBWkrwO89_ngQUFCe0pk=.904f83a5-3fae-4518-bbea-1d7f9ff3081f@github.com>

> The wheel of FDLIBM porting turns a notch and sqrt comes into play.
> 
> While the sqrt operation usually has a hardware implementation that is intrinsified, for completeness a software implementation should be available as well.

Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:

  Implement review feedback.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12736/files
  - new: https://git.openjdk.org/jdk/pull/12736/files/7d39761c..ed06ecbb

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12736&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12736&range=02-03

  Stats: 6 lines in 1 file changed: 0 ins; 0 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/12736.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12736/head:pull/12736

PR: https://git.openjdk.org/jdk/pull/12736

From darcy at openjdk.org  Sat Feb 25 23:05:33 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Sat, 25 Feb 2023 23:05:33 GMT
Subject: RFR: JDK-8302040: Port fdlibm sqrt to Java [v3]
In-Reply-To: <YBUz5ymX_sqGNIegnEttXYjVkw7hwZJfarFAtEjET1g=.147d25a0-5de6-418f-afe0-bfa1a61d17af@github.com>
References: <rjVM2lWPdsvPcfLF3oNShP-cSN8-P-i16ikUC3sTgIg=.1d4f470d-2ac9-4394-b55e-099affce763f@github.com>
 <bzR0JfDQW03UtxdHgqbcLHlBQzPvp2NitCM6Y_ENdco=.1a3c47be-ebf8-420f-903b-964e82fafddf@github.com>
 <YBUz5ymX_sqGNIegnEttXYjVkw7hwZJfarFAtEjET1g=.147d25a0-5de6-418f-afe0-bfa1a61d17af@github.com>
Message-ID: <ZcKc-qNq_rmrJt4o2bkZAj8oB3byiwcw_fQLcFXfh5o=.ceee88a2-0a48-41a1-a4be-3e6a13e10220@github.com>

On Sat, 25 Feb 2023 18:06:46 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

>> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add one one unsigned shift comment.
>
> src/java.base/share/classes/java/lang/FdLibm.java line 639:
> 
>> 637:             r = 0x0020_0000;        // r = moving bit from right to left
>> 638: 
>> 639:             while(r != 0) {
> 
> Suggestion:
> 
>             while (r != 0) {

Thanks for the careful reading; will fix.

-------------

PR: https://git.openjdk.org/jdk/pull/12736

From itakiguchi at openjdk.org  Sun Feb 26 04:39:17 2023
From: itakiguchi at openjdk.org (Ichiroh Takiguchi)
Date: Sun, 26 Feb 2023 04:39:17 GMT
Subject: RFR: 8301119: Support for GB18030-2022 [v3]
In-Reply-To: <ItbPT4G9FTT2V3dUBPOY6PGOQmidBqQYrfvoWW29JgY=.2cbc927a-04ab-47ee-a5bb-3c6e488190c3@github.com>
References: <FXBchbCnbNloQO7Nlh9Ijue_c_YugGk-UC7_-ZAjY2o=.7e1ca01f-8cee-40bb-bb06-6e5670abe661@github.com>
 <DbcSeT1d1ulLxFGuScNUYOimyD_bbHn9miPe9TvlSH8=.a10fd674-22b4-4d6b-ac97-3772babbcd3d@github.com>
 <U-4zjhKODj0JRTHSx_FChBEHLABanbxFBr9nmvg8Vks=.f25ff406-6bcc-4376-ac89-609ae5affd32@github.com>
 <ItbPT4G9FTT2V3dUBPOY6PGOQmidBqQYrfvoWW29JgY=.2cbc927a-04ab-47ee-a5bb-3c6e488190c3@github.com>
Message-ID: <7dEDXuB8aO0XFkF9AaUZwP9chbjr5RFzvz1mYZnIx4g=.5ef6ecc2-829e-4c97-a662-4a51768ab994@github.com>

On Fri, 24 Feb 2023 17:19:22 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Hello @naotoj .
>> Sorry for bothering you.
>> 
>> I have following question:
>> - Why GB18030.java.template is in src/jdk.charsets/share/classes/sun/nio/cs/ext/ directory even if the generated code is always stored into sun/nio/cs ?
>> I think the file should be moved to src/java.base/share/classes/sun/nio/cs and the file name should be GB18030.java instead of GB18030.java.template.
>> Is there specific reason ?
>
>> Hello @naotoj . Sorry for bothering you.
>> 
>> I have following question:
>> 
>> * Why GB18030.java.template is in src/jdk.charsets/share/classes/sun/nio/cs/ext/ directory even if the generated code is always stored into sun/nio/cs ?
>>   I think the file should be moved to src/java.base/share/classes/sun/nio/cs and the file name should be GB18030.java instead of GB18030.java.template.
>>   Is there specific reason ?
> 
> No, there is not. Thanks for pointing it out. Fixed.

Thanks @naotoj .
That's what I expected.

-------------

PR: https://git.openjdk.org/jdk/pull/12518

From tvaleev at openjdk.org  Sun Feb 26 17:28:04 2023
From: tvaleev at openjdk.org (Tagir F. Valeev)
Date: Sun, 26 Feb 2023 17:28:04 GMT
Subject: RFR: JDK-8302323 Add repeat methods to StringBuilder/StringBuffer
 [v2]
In-Reply-To: <_bYC7tIqltee0f4m-9nNRbFGj2Zm0i-KkMrGcTHGJBo=.79a3cdb6-ce8b-43d3-9206-bb6f63fde27a@github.com>
References: <ygMjzllqk27Dss1q2oRgcNvK_GJdbFVweVHTvF7zpwY=.06d27701-6b42-4663-958e-f8aca9bc2bc5@github.com>
 <HzzC3xoR7t1nNDEK7a6-PdjohKGF3if-nrXXPUc37gQ=.e5e3c948-8dd3-4bf4-affe-b8d983f6a4d6@github.com>
 <_bYC7tIqltee0f4m-9nNRbFGj2Zm0i-KkMrGcTHGJBo=.79a3cdb6-ce8b-43d3-9206-bb6f63fde27a@github.com>
Message-ID: <2gGBghKheX9YHPli7u4Vj6ZAko-xS-Lzn_LL33gBkmE=.b1e1f146-f352-488d-a9f6-0f50a4d670c4@github.com>

On Thu, 23 Feb 2023 16:17:00 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/AbstractStringBuilder.java line 1839:
>> 
>>> 1837:      * @throws StringIndexOutOfBoundsException  if the result overflows the buffer
>>> 1838:      */
>>> 1839:     public AbstractStringBuilder repeat(char c, int count) {
>> 
>> The shadowing of the count field is a hidden maintenance trap.
>
> I know but Stuart requested it.

But this method is overridden in the subclasses. We may keep it `count` in subclasses for the API but use different name here for the implementation. What do you think?

-------------

PR: https://git.openjdk.org/jdk/pull/12728

From tvaleev at openjdk.org  Sun Feb 26 17:32:06 2023
From: tvaleev at openjdk.org (Tagir F. Valeev)
Date: Sun, 26 Feb 2023 17:32:06 GMT
Subject: RFR: JDK-8302323 Add repeat methods to StringBuilder/StringBuffer
 [v2]
In-Reply-To: <93WJpJLHppFi0Zk0rXLYsJzP14Hp-8dE80OawQ8vCp0=.dd22af95-bbc5-4f77-871e-3738daf6b379@github.com>
References: <ygMjzllqk27Dss1q2oRgcNvK_GJdbFVweVHTvF7zpwY=.06d27701-6b42-4663-958e-f8aca9bc2bc5@github.com>
 <93WJpJLHppFi0Zk0rXLYsJzP14Hp-8dE80OawQ8vCp0=.dd22af95-bbc5-4f77-871e-3738daf6b379@github.com>
Message-ID: <8wOeJl30Md95Y-nrpWMVZEr3PAi8KwsQjjkKUybEMOE=.7f62f603-cbc8-44d1-ad9d-6a8693a21b3c@github.com>

On Thu, 23 Feb 2023 17:39:10 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> Add the ability to repeatedly append char and CharSequence data to StringBuilder/StringBuffer.
>
> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
> 
>   PR Cleanup

src/java.base/share/classes/java/lang/AbstractStringBuilder.java line 1893:

> 1891:         }
> 1892:         int length = cs.length();
> 1893:         if (length == 1) {

It looks like, handling length == 0 case would be reasonable.

src/java.base/share/classes/java/lang/AbstractStringBuilder.java line 1903:

> 1901:         int total = count * length;
> 1902:         int limit = offset + total;
> 1903:         ensureCapacityInternal(limit);

If I understand correctly, this may cause double reallocation, if inflation is necessary (string to spend is utf16 while current coder is latin1). Can this be optimized, at least for String/ASB inputs? Sorry if I'm missing something.

-------------

PR: https://git.openjdk.org/jdk/pull/12728

From rafael.wth at gmail.com  Sun Feb 26 23:05:05 2023
From: rafael.wth at gmail.com (Rafael Winterhalter)
Date: Mon, 27 Feb 2023 00:05:05 +0100
Subject: Avoiding module-boundaries when bootstrapping
 invokedyanmic/constantdynamic
Message-ID: <CA+DM0Akg2YdhULN+Mo7LTj=CFppvZcLBkTof-0LEAFBWNxQTaQ@mail.gmail.com>

Over the recent years, I have leveraged especially invokedynamic when
instrumenting code. For example, when adding some additional behavior to a
method, a Java agent can add an invokedynamic instruction to the beginning
or the end of it. Of course, the bootstrap method is also supplied by the
agent. The obvious advantage is that the bootstrap method can bind a handle
that points to any class loader, which is often an issue when instrumenting
applications that can use very custom hierarchies of class loaders. Also,
the bootstrap method can create a new class loader as a child of both the
instrumented class and the agent?s class loader. This allows them to write
instrumentation code that interacts with both the agent and the
instrumented class. This makes it possible to define auxiliary classes, for
example when a reactive framework needs a callback, without the need of
class injection.

The remaining issue however is the bootstrap method. The instrumentation
API already offers a way of injecting classes into the bootstrap class
loader, which is of course the right place for such a class-loader
universal dispatcher. However, with the module system, an instrumented
class that is within a named module will not be able to read this bootstrap
class. And it is neither possible (without using internal API) to add a
class to the java.base module that would indeed be visible to all classes,
similar to the lambda metafactory. This leaves me with using the unnamed
module of the bootstrap class path, but this requires importing the module
from all named modules of instrumented classes, something that becomes a
visible reflective change to all code. And which is something I would
ideally want to avoid, also because it might interfere with other code that
uses the unnamed module of the boot loader.

Which brings me to my question; should it be possible to invoke a bootstrap
method without applying module checks? In a way, the bootstrap method is
not a real part of a class, but a mechanism to set up the class. Once it is
initialized, there is no more need to read the module of the bootstrap
loader, so ideally it should not be needed to permanently alter the module
graph.

As an alternative idea, I was wondering if it would be an idea to add a
?generic bootstrap method? to the java.base module. The bootstrap method
could look something like the following:

@FunctionalInterface
interface GenericMetafactory {
  ConcurrentMap<String, GenericMetafactory> factory;
  static CallSite metafactory(MethodHandles.Lookup caller, String
invokedName, MethodType invokedType, String identifier, Object? args) {
    factory.get(identifier).apply(caller, invokedName, args);
  }
  CallSite apply(MethodHandles.Lookup caller, String invokedName,
MethodType invokedType, Object? args);
}

This way, a Java agent could register a dispatcher identified on a random
string prior to instrumenting any code and then add invokedyanmic call
sites with this string to all instrumented code. Since this bootstrap class
lives in the java.base module, no more adjustments would be necessary.

A similar generic bootstrapper could be supplied for use for dynamic
constants.

Thanks, Rafael
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20230227/9381af30/attachment-0001.htm>

From java at rkive.org  Sun Feb 26 23:39:57 2023
From: java at rkive.org (Carl M)
Date: Sun, 26 Feb 2023 18:39:57 -0500 (EST)
Subject: String encoding to ByteBuffer
Message-ID: <1127337400.2205617.1677454797231@email.ionos.com>

I'm looking into adding a fast path case for encoding Strings into ByteBuffers, and wanted to get feedback on a possible approach.  My use case is taking mostly-ASCII, UTF-8 Strings and writing them to the disk/network.  To do this today, there are two approaches which both have drawbacks:

1.  Use String.getBytes(StandardCharsets.UTF_8), and call ByteBuffer.put().  The downside of this approach is that I need to make a copy of the String's byte[] value.    The upside of this approach is that ByteBuffer uses the intrinsic copy methods, which are fast.

2.  Wrap the String in a CharBuffer, and call CharsetEncoder.encode(CharBuffer, ByteBuffer).  This avoids copying the String value.  However, when using the UTF_8 encoder, there is no fastpath for writing to direct ByteBuffers.   sun.nio.cs.UTF_8.encodeLoop() only has fast paths for when the destination is array based.  This allocates less memory, but is overall slower in my JMH benchmark.

To fix this, I looked at adding an overload to CharsetEncoder to accept a String (or a CharSequence), and a ByteBuffer as a destination.  However, this is not easily doable, since it's hard to call it in a loop.  In the case that the String overflows the BB, the caller needs to be able to provide a new BB and resume from where they left off.  The CharBuffer approach works here because it keeps the position last read, and can resume from there.  

To encode a String, we need to know that the character index written to resume with a larger buffer.  However, the return type on CharsetEncoder's encode method is a CoderResult.  The length() method on this can't be called for underflow cases.  This means that there isn't a usable return type here (neither int nor CoderResult can be used).

Another, almost-possible solution I was considering adding a special case to UTF_8 for direct buffer destinations, and a corresponding JLA.encodeASCII overload that accepts a ByteBuffer.  The challenge here is that a wrapped CharBuffer doesn't have an array, and so doesn't get the fast path copying.

The reason I am reaching out here is that I am looking for feedback on my analysis of the existing API.  I am wondering what API compromises could be made to fast path writing Strings to direct buffers, which I feel is probably a common operation.  The only reasonable way I can see to implement is a new return type, which also seems undesirable as well.

Carl

From yyang at openjdk.org  Mon Feb 27 02:07:10 2023
From: yyang at openjdk.org (Yi Yang)
Date: Mon, 27 Feb 2023 02:07:10 GMT
Subject: RFR: 8143900: OptimizeStringConcat has an opaque dependency on
 Integer.sizeTable field [v2]
In-Reply-To: <PFqUJxR3nKSS_z9H73S7ZWBwI5fBpB2GGIBpzQsSmDI=.e6de4ad8-2155-4f65-9814-3ee28fc9a7f7@github.com>
References: <wVJP9KUVBORqE2Y2rPoPzePyKqbUTiE6fKiS1iOw9j4=.91a2c4c5-6da7-461e-8d65-d6e41bb5f4ff@github.com>
 <upouJcFH3Uw0SXK1OZHRgx5X_fQy9ZI2MbdkjrtjsKs=.c382dad7-a3a7-48f1-a493-db4a2ea80849@github.com>
 <PFqUJxR3nKSS_z9H73S7ZWBwI5fBpB2GGIBpzQsSmDI=.e6de4ad8-2155-4f65-9814-3ee28fc9a7f7@github.com>
Message-ID: <KawZ7nCg4aCUnJHJMLAdt5jVlzAtng20397OUiFejKU=.eba4ca68-6056-4289-b719-26ee0bdb3805@github.com>

On Sat, 25 Feb 2023 01:34:40 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

> Testing results seem good. Except one strange failure I put in [JDK-8143900](https://bugs.openjdk.org/browse/JDK-8143900) comment. You need second review.

This seems related to https://bugs.openjdk.org/browse/JDK-8296914

-------------

PR: https://git.openjdk.org/jdk/pull/12680

From yyang at openjdk.org  Mon Feb 27 02:16:21 2023
From: yyang at openjdk.org (Yi Yang)
Date: Mon, 27 Feb 2023 02:16:21 GMT
Subject: RFR: 8143900: OptimizeStringConcat has an opaque dependency on
 Integer.sizeTable field [v3]
In-Reply-To: <wVJP9KUVBORqE2Y2rPoPzePyKqbUTiE6fKiS1iOw9j4=.91a2c4c5-6da7-461e-8d65-d6e41bb5f4ff@github.com>
References: <wVJP9KUVBORqE2Y2rPoPzePyKqbUTiE6fKiS1iOw9j4=.91a2c4c5-6da7-461e-8d65-d6e41bb5f4ff@github.com>
Message-ID: <XPNd_hxtNRtbk8H5IYegQzNB3dpwf595zP3L6Ab3OEQ=.10f4dc93-def6-476e-add1-5fb886aca69c@github.com>

> Hi, can I have a review for this patch? I noticed a strange field Integer.sizeTable which is used by PhaseStringOpts, after digging into the history, I think it could be replaced by an in-place array allocation and initialization. Before it, we are fetching from Integer.sizeTable and get num of digit in integer by iterating size table, now we fetch from in-place sizeTable and get size from that. The changed IR looks like this:
> 
> ![image](https://user-images.githubusercontent.com/5010047/220239446-7b8b8381-b300-4f2c-a24a-aa19ec9e2f88.png)
> 
> Thanks.

Yi Yang has updated the pull request incrementally with one additional commit since the last revision:

  comment from review feedback

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12680/files
  - new: https://git.openjdk.org/jdk/pull/12680/files/816f05a1..8e9b47ba

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12680&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12680&range=01-02

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/12680.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12680/head:pull/12680

PR: https://git.openjdk.org/jdk/pull/12680

From dholmes at openjdk.org  Mon Feb 27 05:22:09 2023
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 27 Feb 2023 05:22:09 GMT
Subject: RFR: 8303133: Update ProcessTools.startProcess(...) to exit early
 if process exit before linePredicate is printed. [v2]
In-Reply-To: <YMRU3NTKiOEw7VS24xhISyijlTyeTeqRFzG-P3Uo3BQ=.7f5772b3-17bb-4985-88b9-8d11acc9392e@github.com>
References: <cuDocKEsnNWZvi2L_E6XBQ_U0T8qnNCIupmsFxaSjEw=.867a6664-21bc-44fb-aa68-9b9a1e8d36d7@github.com>
 <YMRU3NTKiOEw7VS24xhISyijlTyeTeqRFzG-P3Uo3BQ=.7f5772b3-17bb-4985-88b9-8d11acc9392e@github.com>
Message-ID: <AjOfPfyDCivxwdzxRWR4PUeqs2Q94LPtgwEBPAHQ-sY=.19b76733-2d8a-4f6f-81d4-0e05f08b5347@github.com>

On Sat, 25 Feb 2023 00:19:33 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> The solution proposed by Stefan K
>> 
>> The startProcess() might wait forever for the expected line if the process exits (failed to start). It makes sense to just fail earlier in such cases.
>> 
>> The fix also move
>> 'output = new OutputAnalyzer(this.process);'
>> in method xrun() to be able to try to print them in waitFor is failed/interrupted.
>
> Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:
> 
>   updated to always check if process is alive.

I have a number of issues with the changes. I think you have basically addressed the problem of waiting forever if no predicate line was forthcoming, but I think you have introduced a race with normal termination of the process.

test/lib/jdk/test/lib/process/ProcessTools.java line 220:

> 218:             if (timeout > -1) {
> 219:                 // Every second check if process is still alive
> 220:                 boolean succeeded = Utils.waitForCondition(() -> {

This use of `waitForCondition` with a sleep time of zero confused me quite a bit. Now I realize that you are putting `waitForCondition` into a potential busy-poll loop, but then you introduce the one-second timed `await` as part of the condition, thus effectively checking the condition once a second. This seems somewhat convoluted compared to just using a sleep time of 1000ms and changing the `await` to a call to `getCount() > 0`.

test/lib/jdk/test/lib/process/ProcessTools.java line 223:

> 221:                     //Fail if process finished before printed expected string
> 222:                     if (!p.isAlive()) {
> 223:                         latch.countDown();

This `countdown` serves no purpose. The latch is used to coordinate the current thread and the stream pumper thread: the current thread calls `await` and the streamPumper calls `countDown`. Here the current thread is not going to call `await` and it doesn't need to `countDown` to release itself.

test/lib/jdk/test/lib/process/ProcessTools.java line 224:

> 222:                     if (!p.isAlive()) {
> 223:                         latch.countDown();
> 224:                         throw new RuntimeException("Started process " + name + " is not alive.");

This seems problematic. The process has terminated but you don't know why - it may have completed normally and produced all the output such that the `await` below would return immediately with `true`, but you are now going to throw an exception. ???

test/lib/jdk/test/lib/thread/ProcessThread.java line 153:

> 151:         @Override
> 152:         public void xrun() throws Throwable {
> 153:             String name = Thread.currentThread().getName();

The original code passes the name of the `ProcessRunnable` to `startProcess`, not the name of the current thread. It is not obvious/apparent that they are the same. But if they are then it is cheaper to use `name` than do a dynamic query on the current thread.

-------------

Changes requested by dholmes (Reviewer).

PR: https://git.openjdk.org/jdk/pull/12751

From duke at openjdk.org  Mon Feb 27 08:03:05 2023
From: duke at openjdk.org (Viktor Klang)
Date: Mon, 27 Feb 2023 08:03:05 GMT
Subject: RFR: 8302590: Add String.indexOf(int ch, int fromIndex,
 int toIndex) [v2]
In-Reply-To: <ipjMvvgPying2FuiSAOLxIDs13CnCyTOTPZ9NMYcwVM=.856a38dc-218f-4579-9986-ef3fb652b6d9@github.com>
References: <uQ65oRaVDfpzm9bYRuo_MvSuZIdepicE3GnB3Omyngs=.fc23545b-141a-47e5-8a6a-aa28ae1375e5@github.com>
 <Ba1-pAPv01x8R5a7Xs28vdw-Y5WZ8bn253t1lcPF8WU=.cbf398ba-75d6-4ba1-a395-622f3e3a25d7@github.com>
 <T0UAk-Qz9RBzYl_R3eePcwtT7uW7TCMg0PrNB7xcGis=.2261b886-16a2-43a9-a0e8-66997dee19c1@github.com>
 <KkniribyGhakYm9e1Az7zRXcODJrtqo1aMGP4zIHOA8=.efd150ff-69d3-4a5e-805d-4a93331524bb@github.com>
 <I_429Bp7gRzXX3CkgAdkwlt3ja0UhzbQTklHBV_Jkfk=.fdf018e6-13ec-4c67-9718-2afc1ceabab9@github.com>
 <9peQfBSWnJ5Dckv--IE5H0xpIc9GHiaLMhWz7uXCmi4=.b1b77e72-913c-4837-8497-92f1f8d7166a@github.com>
 <ipjMvvgPying2FuiSAOLxIDs13CnCyTOTPZ9NMYcwVM=.856a38dc-218f-4579-9986-ef3fb652b6d9@github.com>
Message-ID: <RuXCxJsLpBdQbAlRaFrlsTehQB8Lf2td3PoYmvTk2bU=.3c43d2a7-03b1-4656-a7ca-d14d709b1341@github.com>

On Fri, 24 Feb 2023 16:37:58 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> Then you would also expect `string.substring(fromIndex).indexOf(ch)` to behave isomorphically to `string.indexOf(ch, fromIndex)` in current releases, right?
>> It does not.
>
> (I guess you are referring to the fact that `substring()` can throw.)

@rgiulietti That's surprising, but if it is as you say, then the indexOf with or without the endIndex should behave identically and not throw.

-------------

PR: https://git.openjdk.org/jdk/pull/12600

From jwaters at openjdk.org  Mon Feb 27 08:28:54 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Mon, 27 Feb 2023 08:28:54 GMT
Subject: RFR: 8303227: JniObjWithEnv should be NullablePointer compliant
Message-ID: <tSmb1smHT4lPI7yJv2Q_Nsy2n3LCdrRPTyhEPuMJTgY=.a356defb-f164-4d2e-9f29-61dc6be96c1f@github.com>

JniObjWithEnv is a struct that is commonly managed by std::unique_ptr. Although it can support managing objects that are not raw pointers, any such objects have to be [NullablePointers](https://en.cppreference.com/w/cpp/named_req/NullablePointer). In the past this has [broken the build when compiler upgrades were carried out](https://bugs.openjdk.org/browse/JDK-8244220), so we should add in the final requirements to make the struct a true NullablePointer once and for all, to prevent similar issues from happening in the future

-------------

Commit messages:
 - JniObjWithEnv should be NullablePointer compliant

Changes: https://git.openjdk.org/jdk/pull/12758/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12758&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8303227
  Stats: 12 lines in 1 file changed: 12 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/12758.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12758/head:pull/12758

PR: https://git.openjdk.org/jdk/pull/12758

From eosterlund at openjdk.org  Mon Feb 27 08:52:07 2023
From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Mon, 27 Feb 2023 08:52:07 GMT
Subject: RFR: 8303040: linux PPC64le: Implementation of Foreign Function &
 Memory API (Preview) [v3]
In-Reply-To: <8b3vVrV22RuhdRoRYacXV0ZeghFGgKkC8S_z-iMrzAQ=.dd84b743-8b51-4281-8f5f-f9eff6207bc7@github.com>
References: <Yuxy6FrsDAN79ya8w8UIkvytGr25zGllDPtPJ1QbGwc=.182664b2-6d8c-497e-a4ae-95e0ad007cf9@github.com>
 <8b3vVrV22RuhdRoRYacXV0ZeghFGgKkC8S_z-iMrzAQ=.dd84b743-8b51-4281-8f5f-f9eff6207bc7@github.com>
Message-ID: <yBDR_4bt2lbdsI_zjxuCMPLOvqKpGi31UcfXXY3Ho98=.c6132aa7-7a4b-4304-bae2-1b950df17fda@github.com>

On Thu, 23 Feb 2023 06:18:49 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> Implementation of "Foreign Function & Memory API" for linux on Power (Little Endian) according to "Power Architecture 64-Bit ELF V2 ABI Specification".
>> 
>> This PR does not include code for VaList support because it's supposed to get removed by [JDK-8299736](https://bugs.openjdk.org/browse/JDK-8299736). I've kept the related tests disabled for this platform and throw an exception instead. Note that the ABI doesn't precisely specify variable argument lists. Instead, it refers to `<stdarg.h>` (2.2.4 Variable Argument Lists).
>> 
>> Big Endian support is implemented to some extend, but not complete. E.g. structs with size not divisible by 8 are not passed correctly (see `useABIv2` in CallArranger.java). Big Endian is excluded by selecting `ARCH.equals("ppc64le")` (CABI.java) only.
>> 
>> There's another limitation: This PR only accepts structures with size divisible by 4. (An `IllegalArgumentException` gets thrown otherwise.) I think arbitrary sizes are not usable on other platforms, either, because `SharedUtils.primitiveCarrierForSize` only accepts powers of 2.
>> 
>> The ABI has some tricky corner cases related to HFA (Homogeneous Float Aggregate). The same argument may need to get passed in both, a FP reg and a GP reg or stack slot (see "no partial DW rule"). This cases are not covered by the existing tests.
>> 
>> I had to make changes to shared code and code for other platforms:
>> 1. Pass type information when creating `VMStorage` objects from `VMReg`. This is needed for the following reasons:
>> - PPC64 ABI requires integer types to get extended to 64 bit (also see CCallingConventionRequiresIntsAsLongs in existing hotspot code). We need to know the type or at least the bit width for that.
>> - Floating point load / store instructions need the correct width to select between the correct IEEE 754 formats. The register representation in single FP registers is always IEEE 754 double precision on PPC64.
>> - Big Endian also needs usage of the precise size. Storing 8 Bytes and loading 4 Bytes yields different values than on Little Endian!
>> 2. It happens that a `NativeMemorySegmentImpl` is used as a raw pointer (with byteSize() == 0) while running TestUpcallScope. Hence, existing size checks don't work (see MemorySegment.java). As a workaround, I'm just skipping the check in this particular case. Please check if this makes sense or if there's a better fix (possibly as separate RFE).
>
> Martin Doerr has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove size restriction for structs. Add TODO for Big Endian.

I don?t think we want this to be on by default on platforms where StoreLoad fences don't cause substantial global overheads. The benefit on such platforms is rather low, and needing the last couple of nanoseconds of transition speed, seems to not be a normal use case that default settings should optimize for. Conversely, the global synchronization can be rather intrusive, especially when it involves handshakes with N threads, and you need to perform global synchronization across the entire machine, for each thread poked. I would be much more afraid of that issue out of the box, than I would be afraid of a couple of nanoseconds slower native transitions.

-------------

PR: https://git.openjdk.org/jdk/pull/12708

From duke at openjdk.org  Mon Feb 27 09:11:10 2023
From: duke at openjdk.org (Glavo)
Date: Mon, 27 Feb 2023 09:11:10 GMT
Subject: RFR: 8299807: newStringNoRepl should avoid copying arrays for
 ASCII compatible charsets [v4]
In-Reply-To: <Vx28T_kz1S269a338ZKHml6BsD2PSys4n_3InHizsEI=.6fa9ef82-7a95-467b-bd05-4217548eed9e@github.com>
References: <Ae0hDkFS2GvkZwo_-RdWic0eDdeq8LbDvM8BJSXF5TM=.681a9737-ade5-48d2-97d9-019e6103a5bb@github.com>
 <Vx28T_kz1S269a338ZKHml6BsD2PSys4n_3InHizsEI=.6fa9ef82-7a95-467b-bd05-4217548eed9e@github.com>
Message-ID: <Tbg07yZcbQe-rSIOqF2ZIv3t-xtBYN2TkmibqNcLDck=.d99c2394-b04a-41e2-92a1-fdc9fd750cb6@github.com>

On Sat, 28 Jan 2023 19:54:32 GMT, Glavo <duke at openjdk.org> wrote:

>> This is the javadoc of `JavaLangAccess::newStringNoRepl`:
>> 
>> 
>>     /**
>>      * Constructs a new {@code String} by decoding the specified subarray of
>>      * bytes using the specified {@linkplain java.nio.charset.Charset charset}.
>>      *
>>      * The caller of this method shall relinquish and transfer the ownership of
>>      * the byte array to the callee since the later will not make a copy.
>>      *
>>      * @param bytes the byte array source
>>      * @param cs the Charset
>>      * @return the newly created string
>>      * @throws CharacterCodingException for malformed or unmappable bytes
>>      */
>> 
>> 
>> It is recorded in the document that it should be able to directly construct strings with parameter byte array to reduce array allocation.
>> 
>> However, at present, `newStringNoRepl` always copies arrays for UTF-8 or other ASCII compatible charsets.
>> 
>> This PR fixes this problem.
>
> Glavo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update

Don't turn it off

-------------

PR: https://git.openjdk.org/jdk/pull/12119

From duke at openjdk.org  Mon Feb 27 09:14:56 2023
From: duke at openjdk.org (Viktor Klang)
Date: Mon, 27 Feb 2023 09:14:56 GMT
Subject: RFR: JDK-8302666: Replace CHM with VarHandle in ForeachOrderedTask
 [v4]
In-Reply-To: <HAgE8xmpZT_2-b5ZDr8TgJNgjhVb3D4ZS3sQqA7c6Mo=.389fa590-681c-44a9-9823-8f70a6129797@github.com>
References: <HAgE8xmpZT_2-b5ZDr8TgJNgjhVb3D4ZS3sQqA7c6Mo=.389fa590-681c-44a9-9823-8f70a6129797@github.com>
Message-ID: <rkiS971vfW6rzjSOY16ReMHJbA-yf7YzPMF6xnkjjG8=.89606151-5614-4714-98c6-c65adfb79514@github.com>

> I noticed when looking at the code that there was no real need to use a CHM to perform the tracking of activation in an ordered fashion on ForEachOrderedTask, but instead a VarHandle can be used, reducing allocations and indirection.

Viktor Klang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits:

 - Updating copyright header of ForEachOps.java and removing unnecessary suppression of an unchecked cast.
 - Write the initial value of the next reference without using the VarHandle
 - JDK-8302666: Replace CHM with VarHandle in ForeachOrderedTask

-------------

Changes: https://git.openjdk.org/jdk/pull/12320/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12320&range=03
  Stats: 26 lines in 1 file changed: 17 ins; 6 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/12320.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12320/head:pull/12320

PR: https://git.openjdk.org/jdk/pull/12320

From asotona at openjdk.org  Mon Feb 27 09:17:51 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 27 Feb 2023 09:17:51 GMT
Subject: RFR: 8294982: Implementation of Classfile API [v20]
In-Reply-To: <9Q436PkBJ4HIYF1ZSYJz_gEL3A1qfpjZKWKc82NVD6k=.7ce49423-395b-430a-9aa5-111106b77937@github.com>
References: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
 <Gluemo5fFOPx_G6KtSgHxWEmiv3FFSTlxRHtc6ZPTuc=.6a2b6930-c7fd-4734-b21b-d2ccec1dabcf@github.com>
 <Qn0tRwNM_VFrkCYp8klyMMUJRCUoB0muZ9E-UkUK8R4=.12a8c8b2-48cc-4ffe-b11e-0180c60bd4bf@github.com>
 <1G9rLfYBxfxcwmzgd7VDXnTfrW252lIui-9sWVAAhn0=.d3e5b0e6-66cc-4322-ae31-282954e9d3ca@github.com>
 <9Q436PkBJ4HIYF1ZSYJz_gEL3A1qfpjZKWKc82NVD6k=.7ce49423-395b-430a-9aa5-111106b77937@github.com>
Message-ID: <bp6VPURfS3ajLjC2RugoLD3qc8T389XZfHcJp63Xghw=.d5593950-b799-4cb4-a7b4-9a1fd69f85fa@github.com>

On Fri, 17 Feb 2023 17:09:51 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Yes, the print structure does not exactly correspond to the Classfile API architecture, but rather to the classfile physical structure and it is partly similar to `javap` output.
>> The common tree structure has been reverse-designed from the desired visual representations in all supported text formats and in all verbosity levels.
>
> Not sure I get this. It seems to me that the same attributes are being printed twice. But, perhaps, the first pass only creates a list with the attribute _names_ and then there is a later pass which print the attributes in full?

Yes, the first is just a list of attribute names, while later there might be printed more attribute details (depending on the verbosity).
Combined or dynamically changed list formats would be inconsistent in various verbosity levels, so duplicate print is preferred for better human and machine readability and consistency. 
There are other cases of duplication in favour of readability. For example some code attributes are printed standalone in a table form, as well as their individual elements are attached to the corresponding bytecode instructions.

-------------

PR: https://git.openjdk.org/jdk/pull/10982

From rgiulietti at openjdk.org  Mon Feb 27 09:41:06 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Mon, 27 Feb 2023 09:41:06 GMT
Subject: RFR: 8302590: Add String.indexOf(int ch, int fromIndex,
 int toIndex) [v2]
In-Reply-To: <RuXCxJsLpBdQbAlRaFrlsTehQB8Lf2td3PoYmvTk2bU=.3c43d2a7-03b1-4656-a7ca-d14d709b1341@github.com>
References: <uQ65oRaVDfpzm9bYRuo_MvSuZIdepicE3GnB3Omyngs=.fc23545b-141a-47e5-8a6a-aa28ae1375e5@github.com>
 <Ba1-pAPv01x8R5a7Xs28vdw-Y5WZ8bn253t1lcPF8WU=.cbf398ba-75d6-4ba1-a395-622f3e3a25d7@github.com>
 <T0UAk-Qz9RBzYl_R3eePcwtT7uW7TCMg0PrNB7xcGis=.2261b886-16a2-43a9-a0e8-66997dee19c1@github.com>
 <KkniribyGhakYm9e1Az7zRXcODJrtqo1aMGP4zIHOA8=.efd150ff-69d3-4a5e-805d-4a93331524bb@github.com>
 <I_429Bp7gRzXX3CkgAdkwlt3ja0UhzbQTklHBV_Jkfk=.fdf018e6-13ec-4c67-9718-2afc1ceabab9@github.com>
 <9peQfBSWnJ5Dckv--IE5H0xpIc9GHiaLMhWz7uXCmi4=.b1b77e72-913c-4837-8497-92f1f8d7166a@github.com>
 <ipjMvvgPying2FuiSAOLxIDs13CnCyTOTPZ9NMYcwVM=.856a38dc-218f-4579-9986-ef3fb652b6d9@github.com>
 <RuXCxJsLpBdQbAlRaFrlsTehQB8Lf2td3PoYmvTk2bU=.3c43d2a7-03b1-4656-a7ca-d14d709b1341@github.com>
Message-ID: <dxq2LtU7jV0xDvb5A7CV9aZlMie0GfwrhWuFuk44J78=.e666c030-21f7-4f66-8bd3-1b545866d5f8@github.com>

On Mon, 27 Feb 2023 08:00:32 GMT, Viktor Klang <duke at openjdk.org> wrote:

>> (I guess you are referring to the fact that `substring()` can throw.)
>
> @rgiulietti That's surprising, but if it is as you say, then the indexOf with or without the endIndex should behave identically and not throw.

@viktorklang-ora I agree that the behavior w.r.t. out-of-range indices is at odd with the `substring()` family, but this inconsistency is already present since the dawn of time ;-)

-------------

PR: https://git.openjdk.org/jdk/pull/12600

From asotona at openjdk.org  Mon Feb 27 10:38:34 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 27 Feb 2023 10:38:34 GMT
Subject: RFR: 8294982: Implementation of Classfile API [v20]
In-Reply-To: <Qn0tRwNM_VFrkCYp8klyMMUJRCUoB0muZ9E-UkUK8R4=.12a8c8b2-48cc-4ffe-b11e-0180c60bd4bf@github.com>
References: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
 <Gluemo5fFOPx_G6KtSgHxWEmiv3FFSTlxRHtc6ZPTuc=.6a2b6930-c7fd-4734-b21b-d2ccec1dabcf@github.com>
 <Qn0tRwNM_VFrkCYp8klyMMUJRCUoB0muZ9E-UkUK8R4=.12a8c8b2-48cc-4ffe-b11e-0180c60bd4bf@github.com>
Message-ID: <EJeQw3PZ5LrbxmlpIogsokswWXQcKsWfgIHmb1qoF20=.52246fe5-2e92-4fa4-af8a-5b3225cd0027@github.com>

On Thu, 16 Feb 2023 10:51:10 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   added 4-byte Unicode text to Utf8EntryTest
>
> src/java.base/share/classes/jdk/internal/classfile/components/ClassPrinter.java line 105:
> 
>> 103:          * @param out consumer of the printed fragments
>> 104:          */
>> 105:         default public void toJson(Consumer<String> out) {
> 
> there are some `public` modifiers here which can be omitted

will fix it, thanks.

-------------

PR: https://git.openjdk.org/jdk/pull/10982

From asotona at openjdk.org  Mon Feb 27 10:45:51 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 27 Feb 2023 10:45:51 GMT
Subject: RFR: 8294982: Implementation of Classfile API [v20]
In-Reply-To: <Qn0tRwNM_VFrkCYp8klyMMUJRCUoB0muZ9E-UkUK8R4=.12a8c8b2-48cc-4ffe-b11e-0180c60bd4bf@github.com>
References: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
 <Gluemo5fFOPx_G6KtSgHxWEmiv3FFSTlxRHtc6ZPTuc=.6a2b6930-c7fd-4734-b21b-d2ccec1dabcf@github.com>
 <Qn0tRwNM_VFrkCYp8klyMMUJRCUoB0muZ9E-UkUK8R4=.12a8c8b2-48cc-4ffe-b11e-0180c60bd4bf@github.com>
Message-ID: <heurkAucA7r8KoKLty2Xe4PyaGuLbYy4rJJ8EeUyUAM=.29a64072-1322-4042-8010-cff4d0f986ae@github.com>

On Thu, 16 Feb 2023 10:54:00 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   added 4-byte Unicode text to Utf8EntryTest
>
> src/java.base/share/classes/jdk/internal/classfile/components/ClassPrinter.java line 140:
> 
>> 138: 
>> 139:     /**
>> 140:      * A tree node holding {@link List} of nested nodes.
> 
> It would perhaps be beneficial to have little examples of what these different nodes are used for. I had to look at `ClassPrinterImpl` to get some idea.

I'll link examples from package-info here.

> src/java.base/share/classes/jdk/internal/classfile/impl/ClassPrinterImpl.java line 745:
> 
>> 743:                     list("stack", "item", Stream.of())));
>> 744:             }
>> 745:             var excHandlers = com.exceptionHandlers().stream().map(exc -> new ExceptionHandler(com.labelToBci(exc.tryStart()), com.labelToBci(exc.tryEnd()), com.labelToBci(exc.handler()), exc.catchType().map(ct -> ct.name().stringValue()).orElse(null))).toList();
> 
> Watch out for very long lines

wil fix it, thanks.

-------------

PR: https://git.openjdk.org/jdk/pull/10982

From rgiulietti at openjdk.org  Mon Feb 27 10:46:59 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Mon, 27 Feb 2023 10:46:59 GMT
Subject: RFR: 8302987: Add uniform and spatially equidistributed bounded
 float/double streams to RandomGenerator [v2]
In-Reply-To: <8B2_dePA34zyndM7SzuG6sanXNQmbge8DCIOIfpnTLs=.81cb4f5b-e3d0-4352-8209-eb1ac6197126@github.com>
References: <8B2_dePA34zyndM7SzuG6sanXNQmbge8DCIOIfpnTLs=.81cb4f5b-e3d0-4352-8209-eb1ac6197126@github.com>
Message-ID: <jebSgNMWkhwmDeoJs_zZi9nzrt7ILZxDY5R89-OazxA=.b8400bf3-ed98-4f16-b667-04e224f0659f@github.com>

> The `default` method `nextDouble(double origin, double bound)` in `java.util.random.RandomGenerator` aims at generating a uniformly and spatially equidistributed random `double` in the left-closed and right-open range [`origin`, `bound`). It does so by applying the affine transform `origin + (bound - origin) * r` to a uniformly and spatially equidistributed random `double` `r` in the range [0, 1).
> 
> Since floating-point arithmetic suffers from small but noticeable rounding errors, this ends up slightly deforming the distribution of `r` when applying the affine transform.

Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:

  8302987: Add uniform and spatially equidistributed bounded float/double streams to RandomGenerator

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12719/files
  - new: https://git.openjdk.org/jdk/pull/12719/files/39f34b1e..68f66cbd

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12719&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12719&range=00-01

  Stats: 8 lines in 1 file changed: 0 ins; 8 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/12719.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12719/head:pull/12719

PR: https://git.openjdk.org/jdk/pull/12719

From rgiulietti at openjdk.org  Mon Feb 27 11:04:49 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Mon, 27 Feb 2023 11:04:49 GMT
Subject: RFR: 8302987: Add uniform and spatially equidistributed bounded
 float/double streams to RandomGenerator [v3]
In-Reply-To: <8B2_dePA34zyndM7SzuG6sanXNQmbge8DCIOIfpnTLs=.81cb4f5b-e3d0-4352-8209-eb1ac6197126@github.com>
References: <8B2_dePA34zyndM7SzuG6sanXNQmbge8DCIOIfpnTLs=.81cb4f5b-e3d0-4352-8209-eb1ac6197126@github.com>
Message-ID: <Do6g_kMmm-kmgdRqtkdyrtQ30Bw61UQDtTeY96s-NiI=.5e0e208f-bc65-4789-94bc-caf0d5df92e5@github.com>

> The `default` method `nextDouble(double origin, double bound)` in `java.util.random.RandomGenerator` aims at generating a uniformly and spatially equidistributed random `double` in the left-closed and right-open range [`origin`, `bound`). It does so by applying the affine transform `origin + (bound - origin) * r` to a uniformly and spatially equidistributed random `double` `r` in the range [0, 1).
> 
> Since floating-point arithmetic suffers from small but noticeable rounding errors, this ends up slightly deforming the distribution of `r` when applying the affine transform.

Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:

  8302987: Add uniform and spatially equidistributed bounded float/double streams to RandomGenerator

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12719/files
  - new: https://git.openjdk.org/jdk/pull/12719/files/68f66cbd..2d1f8e9c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12719&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12719&range=01-02

  Stats: 5 lines in 1 file changed: 0 ins; 0 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/12719.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12719/head:pull/12719

PR: https://git.openjdk.org/jdk/pull/12719

From alanb at openjdk.org  Mon Feb 27 11:05:06 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 27 Feb 2023 11:05:06 GMT
Subject: RFR: 8302590: Add String.indexOf(int ch, int fromIndex,
 int toIndex) [v2]
In-Reply-To: <dxq2LtU7jV0xDvb5A7CV9aZlMie0GfwrhWuFuk44J78=.e666c030-21f7-4f66-8bd3-1b545866d5f8@github.com>
References: <uQ65oRaVDfpzm9bYRuo_MvSuZIdepicE3GnB3Omyngs=.fc23545b-141a-47e5-8a6a-aa28ae1375e5@github.com>
 <Ba1-pAPv01x8R5a7Xs28vdw-Y5WZ8bn253t1lcPF8WU=.cbf398ba-75d6-4ba1-a395-622f3e3a25d7@github.com>
 <T0UAk-Qz9RBzYl_R3eePcwtT7uW7TCMg0PrNB7xcGis=.2261b886-16a2-43a9-a0e8-66997dee19c1@github.com>
 <KkniribyGhakYm9e1Az7zRXcODJrtqo1aMGP4zIHOA8=.efd150ff-69d3-4a5e-805d-4a93331524bb@github.com>
 <I_429Bp7gRzXX3CkgAdkwlt3ja0UhzbQTklHBV_Jkfk=.fdf018e6-13ec-4c67-9718-2afc1ceabab9@github.com>
 <9peQfBSWnJ5Dckv--IE5H0xpIc9GHiaLMhWz7uXCmi4=.b1b77e72-913c-4837-8497-92f1f8d7166a@github.com>
 <ipjMvvgPying2FuiSAOLxIDs13CnCyTOTPZ9NMYcwVM=.856a38dc-218f-4579-9986-ef3fb652b6d9@github.com>
 <RuXCxJsLpBdQbAlRaFrlsTehQB8Lf2td3PoYmvTk2bU=.3c43d2a7-03b1-4656-a7ca-d14d709b1341@github.com>
 <dxq2LtU7jV0xDvb5A7CV9aZlMie0GfwrhWuFuk44J78=.e666c030-21f7-4f66-8bd3-1b545866d5f8@github.com>
Message-ID: <psRZCqJk-RHfgaDe-TZhROF5Nxid8T2xTY1wxARR-Hw=.02712fd2-54c6-43f2-8fb8-7279fc346b77@github.com>

On Mon, 27 Feb 2023 09:37:57 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> @rgiulietti That's surprising, but if it is as you say, then the indexOf with or without the endIndex should behave identically and not throw.
>
> @viktorklang-ora I agree that the behavior w.r.t. out-of-range indices is at odd with the `substring()` family, but this inconsistency is already present since the dawn of time ;-)

Consistency with the indexOf/lastIndexOf methods is good, it makes it look like the method has been there since JDK 1.0. At the same time, it could mean that bugs go undetected, e.g. it would be easy to assume the range is fromIndex + length or to specify the parameters in the wrong order. I don't know if you explored other options but if the new method had a new name then maybe you have the option to throw for out of range index values.

-------------

PR: https://git.openjdk.org/jdk/pull/12600

From vromero at openjdk.org  Mon Feb 27 11:11:07 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Mon, 27 Feb 2023 11:11:07 GMT
Subject: RFR: 8026369: javac potentially ambiguous overload warning needs
 an improved scheme [v5]
In-Reply-To: <kHDAf6VSsTMiO34L5HgR-AlpGcKTgRUyL689crUUaJs=.08571e02-e807-4f17-abef-9d058c2be4ae@github.com>
References: <IMxp3iCK--jYJ5Ia04i6QPYfnCHQobVcsmlI5aJXdqc=.892abcb8-7f2a-4fe9-aea2-1b1d41098a6d@github.com>
 <kfjz51X87aU9nppjkM08j-GuyuWOQ9m_vzTugkjYxVE=.75e83ec8-5810-43cb-8bd1-2a3b5db76b0d@github.com>
 <zmXwajsexkHVYrThszlpiKVhvbGQk86OAgpl7XUqesk=.54943ead-e540-46e7-b4b4-31595f823206@github.com>
 <kHDAf6VSsTMiO34L5HgR-AlpGcKTgRUyL689crUUaJs=.08571e02-e807-4f17-abef-9d058c2be4ae@github.com>
Message-ID: <STm7SDR83SqoSSUplUUGAi_RKhHQa4oL8eq6O8ei25Q=.019cd38e-a19e-4b6c-8ff0-a09749b23bd0@github.com>

On Sat, 25 Feb 2023 16:03:39 GMT, Archie L. Cobbs <duke at openjdk.org> wrote:

>> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java line 2765:
>> 
>>> 2763:      *  any other methods; in this case the class is definitely responsible.
>>> 2764:      */
>>> 2765:     BiPredicate<MethodSymbol, MethodSymbol> buildResponsiblePredicate(Type site,
>> 
>> this method not only builds the predicate as its name indicates, it also removes methods from the `methodGroups`, not saying that we should split this method but I think that this removing activity should be mentioned in the comment above
>
> Oops, my bad - previous refactoring was incomplete.
> 
> Should be fixed in e25ceced163.
> 
> Thanks again for the careful review!

sure, thanks, nice refactoring

-------------

PR: https://git.openjdk.org/jdk/pull/12645

From vromero at openjdk.org  Mon Feb 27 11:15:10 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Mon, 27 Feb 2023 11:15:10 GMT
Subject: RFR: 8026369: javac potentially ambiguous overload warning needs
 an improved scheme [v6]
In-Reply-To: <7CIC6bBj00Mh18mr-g3j6HszbQzf88ND1OHaCW8_ydk=.b6ad3d5b-8bec-47ff-a091-bc483feaee12@github.com>
References: <IMxp3iCK--jYJ5Ia04i6QPYfnCHQobVcsmlI5aJXdqc=.892abcb8-7f2a-4fe9-aea2-1b1d41098a6d@github.com>
 <7CIC6bBj00Mh18mr-g3j6HszbQzf88ND1OHaCW8_ydk=.b6ad3d5b-8bec-47ff-a091-bc483feaee12@github.com>
Message-ID: <Xj4Hm6WdTwtE6punx-MjHNw3LfPMFLPwS0YmSVinpeE=.06192892-d713-417a-b8a2-ab28a9706800@github.com>

On Sat, 25 Feb 2023 16:07:24 GMT, Archie L. Cobbs <duke at openjdk.org> wrote:

>> This bug relates to the "potentially ambiguous overload" warning which is enabled by `-Xlint:overloads`.
>> 
>> The warning detects certain ambiguities that can cause problems for lambdas. For example, consider the interface `Spliterator.OfInt`, which declares these two methods:
>> 
>> void forEachRemaining(Consumer<? super Integer> action);
>> void forEachRemaining(IntConsumer action);
>> 
>> Both methods have the same name, same number of parameters, and take a lambda with the same "shape" in the same argument position. This causes an ambiguity in any code that wants to do this:
>> 
>>     spliterator.forEachRemaining(x -> { ... });
>> 
>> That code won't compile; instead, you'll get this error:
>> 
>> Ambiguity.java:4: error: reference to forEachRemaining is ambiguous
>>         spliterator.forEachRemaining(x -> { });
>>                    ^
>>   both method forEachRemaining(IntConsumer) in OfInt and method forEachRemaining(Consumer<? super Integer>) in OfInt match
>> 
>> 
>> The problem reported by the bug is that the warning fails to detect ambiguities which are created purely by inheritance, for example:
>> 
>> interface ConsumerOfInteger {
>>     void foo(Consumer<Integer> c);
>> }
>> 
>> interface IntegerConsumer {
>>     void foo(IntConsumer c);
>> }
>> 
>> // We should get a warning here...
>> interface Test extends ConsumerOfInteger, IntegerConsumer {
>> }
>> 
>> 
>> The cause of the bug is that ambiguities are detected on a per-method basis, by checking whether a method is part of an ambiguity pair when we visit that method. So if the methods in an ambiguity pair are inherited from two distinct supertypes, we'll miss the ambiguity.
>> 
>> To fix the problem, we need to look for ambiguities on a per-class level, checking all pairs of methods. However, it's not that simple - we only want to "blame" a class when that class itself, and not some supertype, is responsible for creating the ambiguity. For example, any interface extending `Spliterator.OfInt` will automatically inherit the two ambiguities mentioned above, but these are not the interface's fault so to speak so no warning should be generated. Making things more complicated is the fact that methods can be overridden and declared in generic classes so they only conflict in some subtypes, etc.
>> 
>> So we generate the warning when there are two methods m1 and m2 in a class C such that:
>> 
>> * m1 and m2 consitiute a "potentially ambiguous overload" (using the same definition as before)
>> * There is no direct supertype T of C such that m1 and m2, or some methods they override, both exist in T and constitute a "potentially ambiguous overload" as members of T
>> * We haven't already generated a warning for either m1 or m2 in class C
>> 
>> If either method is declared in C, we locate the warning there, but when both methods are inherited, there's no method declaration to point at so the warning is instead located at the class declaration.
>> 
>> I noticed a couple of other minor bugs; these are also being fixed here:
>> 
>> (1) For inherited methods, the method signatures were being reported as they are declared, rather than in the context of the class being visited. As a result, when a methods is inherited from a generic supertype, the ambiguity is less clear. Here's an example:
>> 
>> interface Upper<T> {
>>     void foo(T c);
>> }
>> 
>> interface Lower extends Upper<IntConsumer> {
>>     void foo(Consumer<Integer> c);
>> }
>> 
>> Currently, the error is reported as:
>> 
>> warning: [overloads] foo(Consumer<Integer>) in Lower is potentially ambiguous with foo(T) in Upper
>> 
>> Reporting the method signatures in the context of the class being visited makes the ambiguity clearer:
>> 
>> warning: [overloads] foo(Consumer<Integer>) in Lower is potentially ambiguous with foo(IntConsumer) in Upper
>> 
>> 
>> (2) When a method is identified as part of an ambiguous pair, we were setting a `POTENTIALLY_AMBIGUOUS` flag on it. This caused it to be forever excluded from future warnings. For methods that are declared in the class we're visiting, this makes sense, but it doesn't make sense for inherited methods, because it disqualifies them from participating in the analysis of any other class that also inherits them.
>> 
>> As a result, for a class like the one below, the compiler was only generating one warning instead of three:
>> 
>> public interface SuperIface {
>>     void foo(Consumer<Integer> c);
>> }
>> 
>> public interface I1 extends SuperIface { 
>>     void foo(IntConsumer c);        // warning was generated here
>> }   
>> 
>> public interface I2 extends SuperIface { 
>>     void foo(IntConsumer c);        // no warning was generated here
>> }   
>> 
>> public interface I3 extends SuperIface { 
>>     void foo(IntConsumer c);        // no warning was generated here
>> }   
>> 
>> 
>> With this patch the `POTENTIALLY_AMBIGUOUS` flag is no longer needed. I wasn't sure whether to renumber all the subsequent flags, or just leave an empty placeholder, so I chose the latter.
>> 
>> Finally, this fix uncovers new warnings in `java.base` and `java.desktop`, so these are now suppressed in the patch.
>
> Archie L. Cobbs has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Process methods in order so the second method triggers the warning.
>  - Clean up previous buildResponsiblePredicate() refactoring, which was incomplete.

looks good, thanks for fixing this!

-------------

Marked as reviewed by vromero (Reviewer).

PR: https://git.openjdk.org/jdk/pull/12645

From duke at openjdk.org  Mon Feb 27 11:36:08 2023
From: duke at openjdk.org (Viktor Klang)
Date: Mon, 27 Feb 2023 11:36:08 GMT
Subject: RFR: JDK-8297605 DelayQueue javadoc is confusing
In-Reply-To: <m3sbJeTRxVnt7cx23kGHMaNhpOBfiYWg3fTW6S6XBys=.3f94ea53-90da-460a-80ea-416b91a7e669@github.com>
References: <jdJ46gB5VbY2LPrH7oGbtCtU65HGtd7GZ7SB8InbG-A=.8679db0c-28b2-4665-ab92-e89af0ad38e6@github.com>
 <m3sbJeTRxVnt7cx23kGHMaNhpOBfiYWg3fTW6S6XBys=.3f94ea53-90da-460a-80ea-416b91a7e669@github.com>
Message-ID: <Z3N1gHmihbs4MejnGbL-_b12jI165CtsPwzUsZEh_bg=.f0d9bc7c-2971-4db3-946d-4ff5856b3bb1@github.com>

On Thu, 23 Feb 2023 21:20:27 GMT, Martin Buchholz <martin at openjdk.org> wrote:

> Here's my attempt:
> 
> ```
>  * An unbounded {@linkplain BlockingQueue blocking queue} of {@link Delayed}
>  * elements, in which an element generally becomes eligible for removal when its
>  * delay has expired.
>  *
>  * <p>An element is considered <em>expired</em> when its {@code
>  * getDelay(TimeUnit.NANOSECONDS)} method would return a value less than or
>  * equal to zero.
>  *
>  * <p>An element is considered the <em>head</em> of the queue if it is the
>  * element with the earliest expiration time, whether in the past or the future,
>  * if there is such an element.
>  *
>  * <p>An element is considered the <em>expired head</em> of the queue if it is
>  * the <em>expired</em> element with the earliest expiration time in the
>  * past, if there is such an element.
>  * The <em>expired head</em>, when present, is also the <em>head</em>.
>  *
>  * <p>While this class implements the {@code BlockingQueue} interface, it
>  * intentionally violates the general contract of {@code BlockingQueue}, in that
>  * the following methods disregard the presence of unexpired elements and only
>  * ever remove the <em>expired head</em>:
>  *
>  * <ul>
>  * <li> {@link #poll()}
>  * <li> {@link #poll(long,TimeUnit)}
>  * <li> {@link #take()}
>  * <li> {@link #remove()}
>  * </ul>
>  *
>  * <p>All other methods operate on both expired and unexpired elements.  For
>  * example, the {@code size} method returns the count of all elements.  Method
>  * {@link peek()} may return the non-null <em>head</em> even when {@code
>  * take()} would block waiting for that element to expire.
>  *
>  * <p>This queue does not permit null elements.
> ```

I think that approach sounds good. @DougLea, any opinion on this class javadoc summary?

-------------

PR: https://git.openjdk.org/jdk/pull/12729

From asotona at openjdk.org  Mon Feb 27 11:51:26 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 27 Feb 2023 11:51:26 GMT
Subject: RFR: 8294982: Implementation of Classfile API [v24]
In-Reply-To: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
References: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
Message-ID: <4v-ieGzWVxROeQxyax-xle4OLw7bVqwG3S1EG7NlyR4=.9e3e3d41-ce7a-456c-91c5-cfd11bca3523@github.com>

> This is root pull request with Classfile API implementation, tests and benchmarks initial drop into JDK.
> 
> Following pull requests consolidating JDK class files parsing, generating, and transforming ([JDK-8294957](https://bugs.openjdk.org/browse/JDK-8294957)) will chain to this one.
> 
> Classfile API development is tracked at:
> https://github.com/openjdk/jdk-sandbox/tree/classfile-api-branch
> 
> Development branch of consolidated JDK class files parsing, generating, and transforming is at:
> https://github.com/openjdk/jdk-sandbox/tree/classfile-api-dev-branch
> 
> Classfile API [JEP](https://bugs.openjdk.org/browse/JDK-8280389) and [online API documentation](https://htmlpreview.github.io/?https://raw.githubusercontent.com/openjdk/jdk-sandbox/classfile-api-javadoc-branch/doc/classfile-api/javadoc/java.base/jdk/internal/classfile/package-summary.html) is also available.
> 
> Please take you time to review this non-trivial JDK addition.
> 
> Thank you,
> Adam

Adam Sotona has updated the pull request incrementally with three additional commits since the last revision:

 - added no-lambda comment
 - fixed very long lines
 - removed obsolete public modifiers and added doc examples

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10982/files
  - new: https://git.openjdk.org/jdk/pull/10982/files/1bf62016..9f465f1a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10982&range=23
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10982&range=22-23

  Stats: 156 lines in 3 files changed: 68 ins; 0 del; 88 mod
  Patch: https://git.openjdk.org/jdk/pull/10982.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10982/head:pull/10982

PR: https://git.openjdk.org/jdk/pull/10982

From asotona at openjdk.org  Mon Feb 27 11:58:05 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 27 Feb 2023 11:58:05 GMT
Subject: RFR: 8294982: Implementation of Classfile API [v20]
In-Reply-To: <Qn0tRwNM_VFrkCYp8klyMMUJRCUoB0muZ9E-UkUK8R4=.12a8c8b2-48cc-4ffe-b11e-0180c60bd4bf@github.com>
References: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
 <Gluemo5fFOPx_G6KtSgHxWEmiv3FFSTlxRHtc6ZPTuc=.6a2b6930-c7fd-4734-b21b-d2ccec1dabcf@github.com>
 <Qn0tRwNM_VFrkCYp8klyMMUJRCUoB0muZ9E-UkUK8R4=.12a8c8b2-48cc-4ffe-b11e-0180c60bd4bf@github.com>
Message-ID: <uK2Mntlhl-bj6sd4xoVv-OD_Ap4H5uJWhginLxGQvKQ=.67f31945-ddff-414f-a953-4b27619db1c2@github.com>

On Thu, 16 Feb 2023 11:09:30 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   added 4-byte Unicode text to Utf8EntryTest
>
> src/java.base/share/classes/jdk/internal/classfile/components/ClassRemapper.java line 93:
> 
>> 91: 
>> 92: /**
>> 93:  * ClassRemapper is a {@link jdk.internal.classfile.ClassTransform}, {@link jdk.internal.classfile.FieldTransform},
> 
> Maybe wrap occurrences of `ClassRemapper` with `{@code}` (here and elsewhere)

will fix it, thanks.

> src/java.base/share/classes/jdk/internal/classfile/components/ClassRemapper.java line 168:
> 
>> 166:         public void accept(ClassBuilder clb, ClassElement cle) {
>> 167:             switch (cle) {
>> 168:                 case FieldModel fm ->
> 
> What about NestMembers, NestHost, PermittedSubclasses (and probably others) ?

Right, ClassRemapper is incomplete, will work on it.

> src/java.base/share/classes/jdk/internal/classfile/components/ClassRemapper.java line 306:
> 
>> 304: 
>> 305:         ClassSignature mapClassSignature(ClassSignature signature) {
>> 306:             return ClassSignature.of(signature.typeParameters(),
> 
> Should type parameters also be mapped? (as they might have class bounds). Both here and in `mapMethodSignature`.

Nice catch, will fix it, thanks!

-------------

PR: https://git.openjdk.org/jdk/pull/10982

From rgiulietti at openjdk.org  Mon Feb 27 12:29:07 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Mon, 27 Feb 2023 12:29:07 GMT
Subject: RFR: 8302590: Add String.indexOf(int ch, int fromIndex,
 int toIndex) [v2]
In-Reply-To: <psRZCqJk-RHfgaDe-TZhROF5Nxid8T2xTY1wxARR-Hw=.02712fd2-54c6-43f2-8fb8-7279fc346b77@github.com>
References: <uQ65oRaVDfpzm9bYRuo_MvSuZIdepicE3GnB3Omyngs=.fc23545b-141a-47e5-8a6a-aa28ae1375e5@github.com>
 <Ba1-pAPv01x8R5a7Xs28vdw-Y5WZ8bn253t1lcPF8WU=.cbf398ba-75d6-4ba1-a395-622f3e3a25d7@github.com>
 <T0UAk-Qz9RBzYl_R3eePcwtT7uW7TCMg0PrNB7xcGis=.2261b886-16a2-43a9-a0e8-66997dee19c1@github.com>
 <KkniribyGhakYm9e1Az7zRXcODJrtqo1aMGP4zIHOA8=.efd150ff-69d3-4a5e-805d-4a93331524bb@github.com>
 <I_429Bp7gRzXX3CkgAdkwlt3ja0UhzbQTklHBV_Jkfk=.fdf018e6-13ec-4c67-9718-2afc1ceabab9@github.com>
 <9peQfBSWnJ5Dckv--IE5H0xpIc9GHiaLMhWz7uXCmi4=.b1b77e72-913c-4837-8497-92f1f8d7166a@github.com>
 <ipjMvvgPying2FuiSAOLxIDs13CnCyTOTPZ9NMYcwVM=.856a38dc-218f-4579-9986-ef3fb652b6d9@github.com>
 <RuXCxJsLpBdQbAlRaFrlsTehQB8Lf2td3PoYmvTk2bU=.3c43d2a7-03b1-4656-a7ca-d14d709b1341@github.com>
 <dxq2LtU7jV0xDvb5A7CV9aZlMie0GfwrhWuFuk44J78=.e666c030-21f7-4f66-8bd3-1b545866d5f8@github.com>
 <psRZCqJk-RHfgaDe-TZhROF5Nxid8T2xTY1wxARR-Hw=.02712fd2-54c6-43f2-8fb8-7279fc346b77@github.com>
Message-ID: <QUDwr-0EmtJYuW3HJk99BIQtLYZyB5gtgRsIhN8caU8=.526aff4f-83cc-4236-9d1a-7f0e307ac67b@github.com>

On Mon, 27 Feb 2023 11:02:34 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> @viktorklang-ora I agree that the behavior w.r.t. out-of-range indices is at odd with the `substring()` family, but this inconsistency is already present since the dawn of time ;-)
>
> Consistency with the indexOf/lastIndexOf methods is good, it makes it look like the method has been there since JDK 1.0. At the same time, it could mean that bugs go undetected, e.g. it would be easy to assume the range is fromIndex + length or to specify the parameters in the wrong order. I don't know if you explored other options but if the new method had a new name then maybe you have the option to throw for out of range index values.

@AlanBateman I can propose variants of forward-searching _some-prefix_`IndexOf()` which are consistent with `substring()` in their handling of the indices, but I'd then rather prefer to file another JBS issue and prepare another PR.

The proposed 3 parameters variant of `indexOf()` _is_ the real "primitive" of the family. The other ones are mere shortcuts.

-------------

PR: https://git.openjdk.org/jdk/pull/12600

From alanb at openjdk.org  Mon Feb 27 12:43:32 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 27 Feb 2023 12:43:32 GMT
Subject: RFR: 8302590: Add String.indexOf(int ch, int fromIndex,
 int toIndex) [v2]
In-Reply-To: <QUDwr-0EmtJYuW3HJk99BIQtLYZyB5gtgRsIhN8caU8=.526aff4f-83cc-4236-9d1a-7f0e307ac67b@github.com>
References: <uQ65oRaVDfpzm9bYRuo_MvSuZIdepicE3GnB3Omyngs=.fc23545b-141a-47e5-8a6a-aa28ae1375e5@github.com>
 <Ba1-pAPv01x8R5a7Xs28vdw-Y5WZ8bn253t1lcPF8WU=.cbf398ba-75d6-4ba1-a395-622f3e3a25d7@github.com>
 <T0UAk-Qz9RBzYl_R3eePcwtT7uW7TCMg0PrNB7xcGis=.2261b886-16a2-43a9-a0e8-66997dee19c1@github.com>
 <KkniribyGhakYm9e1Az7zRXcODJrtqo1aMGP4zIHOA8=.efd150ff-69d3-4a5e-805d-4a93331524bb@github.com>
 <I_429Bp7gRzXX3CkgAdkwlt3ja0UhzbQTklHBV_Jkfk=.fdf018e6-13ec-4c67-9718-2afc1ceabab9@github.com>
 <9peQfBSWnJ5Dckv--IE5H0xpIc9GHiaLMhWz7uXCmi4=.b1b77e72-913c-4837-8497-92f1f8d7166a@github.com>
 <ipjMvvgPying2FuiSAOLxIDs13CnCyTOTPZ9NMYcwVM=.856a38dc-218f-4579-9986-ef3fb652b6d9@github.com>
 <RuXCxJsLpBdQbAlRaFrlsTehQB8Lf2td3PoYmvTk2bU=.3c43d2a7-03b1-4656-a7ca-d14d709b1341@github.com>
 <dxq2LtU7jV0xDvb5A7CV9aZlMie0GfwrhWuFuk44J78=.e666c030-21f7-4f66-8bd3-1b545866d5f8@github.com>
 <psRZCqJk-RHfgaDe-TZhROF5Nxid8T2xTY1wxARR-Hw=.02712fd2-54c6-43f2-8fb8-7279fc346b77@github.com>
 <QUDwr-0EmtJYuW3HJk99BIQtLYZyB5gtgRs
 IhN8caU8=.526aff4f-83cc-4236-9d1a-7f0e307ac67b@github.com>
Message-ID: <t-QauwOAS_36CzDBliJdQwJ8TuzxqYQ7ks84UuOeEDQ=.966c2846-743b-42b8-ab35-d91f0f2b8e2e@github.com>

On Mon, 27 Feb 2023 12:25:54 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> Consistency with the indexOf/lastIndexOf methods is good, it makes it look like the method has been there since JDK 1.0. At the same time, it could mean that bugs go undetected, e.g. it would be easy to assume the range is fromIndex + length or to specify the parameters in the wrong order. I don't know if you explored other options but if the new method had a new name then maybe you have the option to throw for out of range index values.
>
> @AlanBateman I can propose variants of forward-searching _some-prefix_`IndexOf()` which are consistent with `substring()` in their handling of the indices, but I'd then rather prefer to file another JBS issue and prepare another PR.
> 
> The proposed 3 parameters variant of `indexOf()` _is_ the real "primitive" of the family. The other ones are mere shortcuts.

Parking this PR while exploration is done into other options is okay.

-------------

PR: https://git.openjdk.org/jdk/pull/12600

From jlaskey at openjdk.org  Mon Feb 27 12:47:03 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Mon, 27 Feb 2023 12:47:03 GMT
Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates
 (Preview) [v42]
In-Reply-To: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
Message-ID: <9XP497xudeRhZKkIpxIgpbqT24eG8SCbfG6TelYtM3M=.f1ad5a76-798c-4e3d-b43b-a25a20210154@github.com>

> Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12).

Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:

  Tighten up reporting of string template errors (fewer messages)

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10889/files
  - new: https://git.openjdk.org/jdk/pull/10889/files/89806d49..85cc7efc

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=41
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=40-41

  Stats: 52 lines in 5 files changed: 27 ins; 7 del; 18 mod
  Patch: https://git.openjdk.org/jdk/pull/10889.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10889/head:pull/10889

PR: https://git.openjdk.org/jdk/pull/10889

From jlaskey at openjdk.org  Mon Feb 27 13:11:32 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Mon, 27 Feb 2023 13:11:32 GMT
Subject: RFR: JDK-8302323 Add repeat methods to StringBuilder/StringBuffer
 [v2]
In-Reply-To: <8wOeJl30Md95Y-nrpWMVZEr3PAi8KwsQjjkKUybEMOE=.7f62f603-cbc8-44d1-ad9d-6a8693a21b3c@github.com>
References: <ygMjzllqk27Dss1q2oRgcNvK_GJdbFVweVHTvF7zpwY=.06d27701-6b42-4663-958e-f8aca9bc2bc5@github.com>
 <93WJpJLHppFi0Zk0rXLYsJzP14Hp-8dE80OawQ8vCp0=.dd22af95-bbc5-4f77-871e-3738daf6b379@github.com>
 <8wOeJl30Md95Y-nrpWMVZEr3PAi8KwsQjjkKUybEMOE=.7f62f603-cbc8-44d1-ad9d-6a8693a21b3c@github.com>
Message-ID: <r6Meqkyh7uZyQnq35l1a-uT8aotf7mlPDHSM9irovQc=.b2bae586-9d24-4961-a2b3-2c33a9746e3e@github.com>

On Sun, 26 Feb 2023 17:29:09 GMT, Tagir F. Valeev <tvaleev at openjdk.org> wrote:

>> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   PR Cleanup
>
> src/java.base/share/classes/java/lang/AbstractStringBuilder.java line 1893:
> 
>> 1891:         }
>> 1892:         int length = cs.length();
>> 1893:         if (length == 1) {
> 
> It looks like, handling length == 0 case would be reasonable.

Agree.

-------------

PR: https://git.openjdk.org/jdk/pull/12728

From asotona at openjdk.org  Mon Feb 27 13:15:40 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 27 Feb 2023 13:15:40 GMT
Subject: RFR: 8294982: Implementation of Classfile API [v25]
In-Reply-To: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
References: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
Message-ID: <z78UQ1fIJ3-fx_YT3M0eYZ84iKTkkoNtQ4rOBsneGCM=.b78b7070-4a82-4cd4-8c68-0be7bd983f48@github.com>

> This is root pull request with Classfile API implementation, tests and benchmarks initial drop into JDK.
> 
> Following pull requests consolidating JDK class files parsing, generating, and transforming ([JDK-8294957](https://bugs.openjdk.org/browse/JDK-8294957)) will chain to this one.
> 
> Classfile API development is tracked at:
> https://github.com/openjdk/jdk-sandbox/tree/classfile-api-branch
> 
> Development branch of consolidated JDK class files parsing, generating, and transforming is at:
> https://github.com/openjdk/jdk-sandbox/tree/classfile-api-dev-branch
> 
> Classfile API [JEP](https://bugs.openjdk.org/browse/JDK-8280389) and [online API documentation](https://htmlpreview.github.io/?https://raw.githubusercontent.com/openjdk/jdk-sandbox/classfile-api-javadoc-branch/doc/classfile-api/javadoc/java.base/jdk/internal/classfile/package-summary.html) is also available.
> 
> Please take you time to review this non-trivial JDK addition.
> 
> Thank you,
> Adam

Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:

  ClassRemapper fixes

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10982/files
  - new: https://git.openjdk.org/jdk/pull/10982/files/9f465f1a..dfb0e00e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10982&range=24
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10982&range=23-24

  Stats: 161 lines in 1 file changed: 88 ins; 0 del; 73 mod
  Patch: https://git.openjdk.org/jdk/pull/10982.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10982/head:pull/10982

PR: https://git.openjdk.org/jdk/pull/10982

From asotona at openjdk.org  Mon Feb 27 13:15:44 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 27 Feb 2023 13:15:44 GMT
Subject: RFR: 8294982: Implementation of Classfile API [v20]
In-Reply-To: <uK2Mntlhl-bj6sd4xoVv-OD_Ap4H5uJWhginLxGQvKQ=.67f31945-ddff-414f-a953-4b27619db1c2@github.com>
References: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
 <Gluemo5fFOPx_G6KtSgHxWEmiv3FFSTlxRHtc6ZPTuc=.6a2b6930-c7fd-4734-b21b-d2ccec1dabcf@github.com>
 <Qn0tRwNM_VFrkCYp8klyMMUJRCUoB0muZ9E-UkUK8R4=.12a8c8b2-48cc-4ffe-b11e-0180c60bd4bf@github.com>
 <uK2Mntlhl-bj6sd4xoVv-OD_Ap4H5uJWhginLxGQvKQ=.67f31945-ddff-414f-a953-4b27619db1c2@github.com>
Message-ID: <PRYiMCCFXATzbAXyFu3FekcW6JUvAAA11RqOikgSGac=.25b957c4-5835-4a38-baa6-3a9b44424a57@github.com>

On Mon, 27 Feb 2023 11:54:53 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/classfile/components/ClassRemapper.java line 168:
>> 
>>> 166:         public void accept(ClassBuilder clb, ClassElement cle) {
>>> 167:             switch (cle) {
>>> 168:                 case FieldModel fm ->
>> 
>> What about NestMembers, NestHost, PermittedSubclasses (and probably others) ?
>
> Right, ClassRemapper is incomplete, will work on it.

fixed

-------------

PR: https://git.openjdk.org/jdk/pull/10982

From asotona at openjdk.org  Mon Feb 27 13:20:47 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 27 Feb 2023 13:20:47 GMT
Subject: RFR: 8294982: Implementation of Classfile API [v26]
In-Reply-To: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
References: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
Message-ID: <RE5D8dgfSeXSzov-yO1XC8X7FQPtgwl8kxZvMfaM4Nc=.ea788d4e-e5cf-440e-bd38-da6d695967f6@github.com>

> This is root pull request with Classfile API implementation, tests and benchmarks initial drop into JDK.
> 
> Following pull requests consolidating JDK class files parsing, generating, and transforming ([JDK-8294957](https://bugs.openjdk.org/browse/JDK-8294957)) will chain to this one.
> 
> Classfile API development is tracked at:
> https://github.com/openjdk/jdk-sandbox/tree/classfile-api-branch
> 
> Development branch of consolidated JDK class files parsing, generating, and transforming is at:
> https://github.com/openjdk/jdk-sandbox/tree/classfile-api-dev-branch
> 
> Classfile API [JEP](https://bugs.openjdk.org/browse/JDK-8280389) and [online API documentation](https://htmlpreview.github.io/?https://raw.githubusercontent.com/openjdk/jdk-sandbox/classfile-api-javadoc-branch/doc/classfile-api/javadoc/java.base/jdk/internal/classfile/package-summary.html) is also available.
> 
> Please take you time to review this non-trivial JDK addition.
> 
> Thank you,
> Adam

Adam Sotona has updated the pull request incrementally with three additional commits since the last revision:

 - Update src/java.base/share/classes/jdk/internal/classfile/components/CodeRelabeler.java
   
   Co-authored-by: Maurizio Cimadamore <54672762+mcimadamore at users.noreply.github.com>
 - Update src/java.base/share/classes/jdk/internal/classfile/components/CodeStackTracker.java
   
   Co-authored-by: Maurizio Cimadamore <54672762+mcimadamore at users.noreply.github.com>
 - Update src/java.base/share/classes/jdk/internal/classfile/components/CodeStackTracker.java
   
   Co-authored-by: Maurizio Cimadamore <54672762+mcimadamore at users.noreply.github.com>

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10982/files
  - new: https://git.openjdk.org/jdk/pull/10982/files/dfb0e00e..7cbd080f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10982&range=25
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10982&range=24-25

  Stats: 3 lines in 2 files changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/10982.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10982/head:pull/10982

PR: https://git.openjdk.org/jdk/pull/10982

From jlaskey at openjdk.org  Mon Feb 27 13:23:38 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Mon, 27 Feb 2023 13:23:38 GMT
Subject: RFR: JDK-8302323 Add repeat methods to StringBuilder/StringBuffer
 [v2]
In-Reply-To: <8wOeJl30Md95Y-nrpWMVZEr3PAi8KwsQjjkKUybEMOE=.7f62f603-cbc8-44d1-ad9d-6a8693a21b3c@github.com>
References: <ygMjzllqk27Dss1q2oRgcNvK_GJdbFVweVHTvF7zpwY=.06d27701-6b42-4663-958e-f8aca9bc2bc5@github.com>
 <93WJpJLHppFi0Zk0rXLYsJzP14Hp-8dE80OawQ8vCp0=.dd22af95-bbc5-4f77-871e-3738daf6b379@github.com>
 <8wOeJl30Md95Y-nrpWMVZEr3PAi8KwsQjjkKUybEMOE=.7f62f603-cbc8-44d1-ad9d-6a8693a21b3c@github.com>
Message-ID: <B473It6XpyE7ngqQY7MuwHgfRthvh3waZBoA1EShSfY=.97416aba-95d9-4abe-95d3-b41f8f9ecafb@github.com>

On Sun, 26 Feb 2023 17:28:08 GMT, Tagir F. Valeev <tvaleev at openjdk.org> wrote:

>> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   PR Cleanup
>
> src/java.base/share/classes/java/lang/AbstractStringBuilder.java line 1903:
> 
>> 1901:         int total = count * length;
>> 1902:         int limit = offset + total;
>> 1903:         ensureCapacityInternal(limit);
> 
> If I understand correctly, this may cause double reallocation, if inflation is necessary (string to spend is utf16 while current coder is latin1). Can this be optimized, at least for String/ASB inputs? Sorry if I'm missing something.

Inflation of a buffer can only happen once. Adding the first copy (append) causing expansion (reallocatio ) and then expanding again to handle the remaining copies is something that happens frequently. Better to expand once for all cases and take the one time hit for transition from Latin1 to UTF16. Make sense?

-------------

PR: https://git.openjdk.org/jdk/pull/12728

From jlaskey at openjdk.org  Mon Feb 27 13:30:47 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Mon, 27 Feb 2023 13:30:47 GMT
Subject: RFR: JDK-8302323 Add repeat methods to StringBuilder/StringBuffer
 [v3]
In-Reply-To: <ygMjzllqk27Dss1q2oRgcNvK_GJdbFVweVHTvF7zpwY=.06d27701-6b42-4663-958e-f8aca9bc2bc5@github.com>
References: <ygMjzllqk27Dss1q2oRgcNvK_GJdbFVweVHTvF7zpwY=.06d27701-6b42-4663-958e-f8aca9bc2bc5@github.com>
Message-ID: <USKIo5-pKuGZ9zfcj1dvmw98vqZBKv3q0sIl9ny1bdM=.54283a18-6f09-4fa1-801a-2298e69b750d@github.com>

> Add the ability to repeatedly append char and CharSequence data to StringBuilder/StringBuffer.

Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:

  Optimize for empty CharSequence

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12728/files
  - new: https://git.openjdk.org/jdk/pull/12728/files/530f5543..01ffb19b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12728&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12728&range=01-02

  Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/12728.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12728/head:pull/12728

PR: https://git.openjdk.org/jdk/pull/12728

From asotona at openjdk.org  Mon Feb 27 13:38:42 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 27 Feb 2023 13:38:42 GMT
Subject: RFR: 8294982: Implementation of Classfile API [v20]
In-Reply-To: <Qn0tRwNM_VFrkCYp8klyMMUJRCUoB0muZ9E-UkUK8R4=.12a8c8b2-48cc-4ffe-b11e-0180c60bd4bf@github.com>
References: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
 <Gluemo5fFOPx_G6KtSgHxWEmiv3FFSTlxRHtc6ZPTuc=.6a2b6930-c7fd-4734-b21b-d2ccec1dabcf@github.com>
 <Qn0tRwNM_VFrkCYp8klyMMUJRCUoB0muZ9E-UkUK8R4=.12a8c8b2-48cc-4ffe-b11e-0180c60bd4bf@github.com>
Message-ID: <Hfba433pWvjDCL3CLuknu03Me1b3Zt4jnhOv--NFsoQ=.31db5bd0-a1ec-4b6b-97a9-361e91d91ac5@github.com>

On Thu, 16 Feb 2023 11:21:29 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   added 4-byte Unicode text to Utf8EntryTest
>
> src/java.base/share/classes/jdk/internal/classfile/components/CodeLocalsShifter.java line 43:
> 
>> 41: 
>> 42: /**
>> 43:  * CodeLocalsShifter is a {@link jdk.internal.classfile.CodeTransform} shifting locals to
> 
> Missing `{@code}` (here and elsewhere)

fixed, thanks.

> src/java.base/share/classes/jdk/internal/classfile/components/CodeStackTracker.java line 53:
> 
>> 51:  *         trackedBuilder.aload(0);
>> 52:  *         trackedBuilder.lconst_0();
>> 53:  *         trackedBuilder.ifThen(...
> 
> missing closed parens?

fixed, thanks.

-------------

PR: https://git.openjdk.org/jdk/pull/10982

From asotona at openjdk.org  Mon Feb 27 13:38:37 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 27 Feb 2023 13:38:37 GMT
Subject: RFR: 8294982: Implementation of Classfile API [v27]
In-Reply-To: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
References: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
Message-ID: <DslcDrsYtIBJD4EO9QHYxONOXqUhJPKc-ovLIsOYXVU=.11c3cf3e-90be-48af-9fc9-ebf78963ea38@github.com>

> This is root pull request with Classfile API implementation, tests and benchmarks initial drop into JDK.
> 
> Following pull requests consolidating JDK class files parsing, generating, and transforming ([JDK-8294957](https://bugs.openjdk.org/browse/JDK-8294957)) will chain to this one.
> 
> Classfile API development is tracked at:
> https://github.com/openjdk/jdk-sandbox/tree/classfile-api-branch
> 
> Development branch of consolidated JDK class files parsing, generating, and transforming is at:
> https://github.com/openjdk/jdk-sandbox/tree/classfile-api-dev-branch
> 
> Classfile API [JEP](https://bugs.openjdk.org/browse/JDK-8280389) and [online API documentation](https://htmlpreview.github.io/?https://raw.githubusercontent.com/openjdk/jdk-sandbox/classfile-api-javadoc-branch/doc/classfile-api/javadoc/java.base/jdk/internal/classfile/package-summary.html) is also available.
> 
> Please take you time to review this non-trivial JDK addition.
> 
> Thank you,
> Adam

Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:

  javadoc fixes

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10982/files
  - new: https://git.openjdk.org/jdk/pull/10982/files/7cbd080f..7002d719

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10982&range=26
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10982&range=25-26

  Stats: 10 lines in 2 files changed: 0 ins; 0 del; 10 mod
  Patch: https://git.openjdk.org/jdk/pull/10982.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10982/head:pull/10982

PR: https://git.openjdk.org/jdk/pull/10982

From asotona at openjdk.org  Mon Feb 27 13:38:45 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 27 Feb 2023 13:38:45 GMT
Subject: RFR: 8294982: Implementation of Classfile API [v20]
In-Reply-To: <oYaLdiYyDVuK_MQipb_p3HpgH_p6xBZByVeG33jPYps=.2282798d-f696-4139-88a5-bbf0f3274ac5@github.com>
References: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
 <Gluemo5fFOPx_G6KtSgHxWEmiv3FFSTlxRHtc6ZPTuc=.6a2b6930-c7fd-4734-b21b-d2ccec1dabcf@github.com>
 <Qn0tRwNM_VFrkCYp8klyMMUJRCUoB0muZ9E-UkUK8R4=.12a8c8b2-48cc-4ffe-b11e-0180c60bd4bf@github.com>
 <oYaLdiYyDVuK_MQipb_p3HpgH_p6xBZByVeG33jPYps=.2282798d-f696-4139-88a5-bbf0f3274ac5@github.com>
Message-ID: <B7FKcVbhFFy0jLPHiOoFz7LMUYVOAoOYN7BzyNsI6NM=.daa3734e-433f-40c5-bd19-7f4c5c4b39d0@github.com>

On Thu, 16 Feb 2023 11:29:51 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/classfile/components/CodeStackTracker.java line 43:
>> 
>>> 41: 
>>> 42: /**
>>> 43:  * CodeStackTracker is a {@link jdk.internal.classfile.CodeTransform} synchronously tracking
>> 
>> Not sure what is meant by `synchronously`
>
> Might want to use `{@code}` (here and elsewhere)

fixed, thanks.

-------------

PR: https://git.openjdk.org/jdk/pull/10982

From rgiulietti at openjdk.org  Mon Feb 27 13:41:44 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Mon, 27 Feb 2023 13:41:44 GMT
Subject: RFR: 8302590: Add String.indexOf(int ch, int fromIndex,
 int toIndex) [v2]
In-Reply-To: <t-QauwOAS_36CzDBliJdQwJ8TuzxqYQ7ks84UuOeEDQ=.966c2846-743b-42b8-ab35-d91f0f2b8e2e@github.com>
References: <uQ65oRaVDfpzm9bYRuo_MvSuZIdepicE3GnB3Omyngs=.fc23545b-141a-47e5-8a6a-aa28ae1375e5@github.com>
 <Ba1-pAPv01x8R5a7Xs28vdw-Y5WZ8bn253t1lcPF8WU=.cbf398ba-75d6-4ba1-a395-622f3e3a25d7@github.com>
 <T0UAk-Qz9RBzYl_R3eePcwtT7uW7TCMg0PrNB7xcGis=.2261b886-16a2-43a9-a0e8-66997dee19c1@github.com>
 <KkniribyGhakYm9e1Az7zRXcODJrtqo1aMGP4zIHOA8=.efd150ff-69d3-4a5e-805d-4a93331524bb@github.com>
 <I_429Bp7gRzXX3CkgAdkwlt3ja0UhzbQTklHBV_Jkfk=.fdf018e6-13ec-4c67-9718-2afc1ceabab9@github.com>
 <9peQfBSWnJ5Dckv--IE5H0xpIc9GHiaLMhWz7uXCmi4=.b1b77e72-913c-4837-8497-92f1f8d7166a@github.com>
 <ipjMvvgPying2FuiSAOLxIDs13CnCyTOTPZ9NMYcwVM=.856a38dc-218f-4579-9986-ef3fb652b6d9@github.com>
 <RuXCxJsLpBdQbAlRaFrlsTehQB8Lf2td3PoYmvTk2bU=.3c43d2a7-03b1-4656-a7ca-d14d709b1341@github.com>
 <dxq2LtU7jV0xDvb5A7CV9aZlMie0GfwrhWuFuk44J78=.e666c030-21f7-4f66-8bd3-1b545866d5f8@github.com>
 <psRZCqJk-RHfgaDe-TZhROF5Nxid8T2xTY1wxARR-Hw=.02712fd2-54c6-43f2-8fb8-7279fc346b77@github.com>
 <QUDwr-0EmtJYuW3HJk99BIQtLYZyB5gtgRs
 IhN8caU8=.526aff4f-83cc-4236-9d1a-7f0e307ac67b@github.com>
 <t-QauwOAS_36CzDBliJdQwJ8TuzxqYQ7ks84UuOeEDQ=.966c2846-743b-42b8-ab35-d91f0f2b8e2e@github.com>
Message-ID: <Ts-2wvW7MK826G_SJlALXWAn7ZDyYHU4UZcXZcaYhKQ=.374dde8e-e5bd-4c88-88b8-88af3733be29@github.com>

On Mon, 27 Feb 2023 12:40:34 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> @AlanBateman I can propose variants of forward-searching _some-prefix_`IndexOf()` which are consistent with `substring()` in their handling of the indices, but I'd then rather prefer to file another JBS issue and prepare another PR.
>> 
>> The proposed 3 parameters variant of `indexOf()` _is_ the real "primitive" of the family. The other ones are mere shortcuts.
>
> Parking this PR while exploration is done into other options is okay.

@AlanBateman Both from an `@apiNote` and from an implementation perspective, the checked _some-prefix_`IndexOf()`variants would better make use of the public 3 params `indexOf()` API point proposed here, rather than relying on `StringLatin1` and `StringUTF16` internals.

Thus, parking this PR would mean that the other PR could not refer to the API point from here until this one is integrated. 

Perhaps I'm missing something.
Is it perhaps better to add the checked variants directly in this PR?

-------------

PR: https://git.openjdk.org/jdk/pull/12600

From dl at openjdk.org  Mon Feb 27 13:47:24 2023
From: dl at openjdk.org (Doug Lea)
Date: Mon, 27 Feb 2023 13:47:24 GMT
Subject: RFR: JDK-8297605 DelayQueue javadoc is confusing [v2]
In-Reply-To: <AjDnqfwvtOh_qfmB-9JifK1aS0X0Sw5tU79hL-UPGGE=.c2b74002-56a2-4fe8-879f-f11ce8e7b87a@github.com>
References: <jdJ46gB5VbY2LPrH7oGbtCtU65HGtd7GZ7SB8InbG-A=.8679db0c-28b2-4665-ab92-e89af0ad38e6@github.com>
 <AjDnqfwvtOh_qfmB-9JifK1aS0X0Sw5tU79hL-UPGGE=.c2b74002-56a2-4fe8-879f-f11ce8e7b87a@github.com>
Message-ID: <bTtl_9MYVpgF4-OimXdihuwRuwXvpbB_9WDagMw72L8=.3cdc5d90-2be1-4b33-bf0f-e07f596e69df@github.com>

On Fri, 24 Feb 2023 16:08:57 GMT, Viktor Klang <duke at openjdk.org> wrote:

>> Clarifies the distinction between expiration of the head of DelayQueue and how it relates to `poll`, `take`, and `peek`. See discussion on https://bugs.openjdk.org/browse/JDK-8297605
>> 
>> @DougLea If possible, please weigh in on whether this is in line with your thoughts on the matter.
>
> Viktor Klang 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 one additional commit since the last revision:
> 
>   JDK-8297605 DelayQueue javadoc is confusing

Yes, lgtm!

-------------

PR: https://git.openjdk.org/jdk/pull/12729

From duke at openjdk.org  Mon Feb 27 14:04:49 2023
From: duke at openjdk.org (Matthew Donovan)
Date: Mon, 27 Feb 2023 14:04:49 GMT
Subject: RFR: 8298939: Refactor
 open/test/jdk/javax/rmi/ssl/SSLSocketParametersTest.sh to jtreg java test [v4]
In-Reply-To: <hR5KCBz2nKbsQG1ZHsXQ8ENIpqwJrKQCW3yh-Eq6G_c=.a726970f-f736-49c2-b461-88417f190a33@github.com>
References: <VC_ou2XS44PtyTfwXw0VZRtXcHEbXImlLZKniIPRqOw=.7d10a168-77f8-4552-97a3-8b2570e3fe29@github.com>
 <AwGYbtYHElwIegMho1esToGmDCY4oCBJ6Kdw7AIl7mg=.c975751e-69cb-4916-af14-7ea88471e47d@github.com>
 <hR5KCBz2nKbsQG1ZHsXQ8ENIpqwJrKQCW3yh-Eq6G_c=.a726970f-f736-49c2-b461-88417f190a33@github.com>
Message-ID: <rVxj1ZAlJjN2UbPG1mCAImP46nB3KEdIWwoDYrAHglY=.099045fb-2be0-4973-94f6-df7c22d08d59@github.com>

On Tue, 21 Feb 2023 19:06:02 GMT, Stuart Marks <smarks at openjdk.org> wrote:

>> Matthew Donovan 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:
>> 
>>  - added System.exit when exceptions are thrown and refactored for clarity
>>  - Merge branch 'master' into rmi-sslparams
>>  - added default switch case and additional refactoring
>>  - added exceptions for cases 4 and 5
>>  - clarified cases 4 and 5
>>  - 8298939: Refactor open/test/jdk/javax/rmi/ssl/SSLSocketParametersTest.sh to jtreg java test
>
> test/jdk/javax/rmi/ssl/SSLSocketParametersTest.java line 221:
> 
>> 219:             }
>> 220:         }
>> 221:     }
> 
> Overall this test method makes sense, as it asserts that an IllegalArgumentException must be thrown with the given exception message. (A comment to this effect would be helpful.) As such, the catch of NoSuchAlgorithmException is confusing. I think this is here because SSLContext.getDefault() lists this as a checked exception. If so, then I'd suggest simply propagating it by adding a `throws` clause for this method. This also means adding a `throws` clause to the `runTest()` method, possibly just `throws Exception`. In general this is OK for jtreg tests to propagate any checked exception out of main, since jtreg will handle and report any unexpectedly propagated exceptions. It's thus unnecessary for test code to have catch-clauses for anything that the test isn't actually handling.

The exception handling has been cleaned up here and the other place you pointed out.

-------------

PR: https://git.openjdk.org/jdk/pull/11910

From duke at openjdk.org  Mon Feb 27 14:04:42 2023
From: duke at openjdk.org (Matthew Donovan)
Date: Mon, 27 Feb 2023 14:04:42 GMT
Subject: RFR: 8298939: Refactor
 open/test/jdk/javax/rmi/ssl/SSLSocketParametersTest.sh to jtreg java test [v5]
In-Reply-To: <VC_ou2XS44PtyTfwXw0VZRtXcHEbXImlLZKniIPRqOw=.7d10a168-77f8-4552-97a3-8b2570e3fe29@github.com>
References: <VC_ou2XS44PtyTfwXw0VZRtXcHEbXImlLZKniIPRqOw=.7d10a168-77f8-4552-97a3-8b2570e3fe29@github.com>
Message-ID: <-i8qOy1y9YRztD9fUlf9uDn1hxk-Een_bssvoJOGm6M=.0d8b70c5-8a72-4eaa-b2b5-095d687a7760@github.com>

> Removed SSLSocketParametersTest.sh script (which just called a Java file) and configured the java code to run directly with jtreg

Matthew Donovan has updated the pull request incrementally with one additional commit since the last revision:

  cleaned up exception handling

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/11910/files
  - new: https://git.openjdk.org/jdk/pull/11910/files/775e2981..44b3ffcb

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11910&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11910&range=03-04

  Stats: 45 lines in 1 file changed: 6 ins; 27 del; 12 mod
  Patch: https://git.openjdk.org/jdk/pull/11910.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11910/head:pull/11910

PR: https://git.openjdk.org/jdk/pull/11910

From duke at openjdk.org  Mon Feb 27 14:04:43 2023
From: duke at openjdk.org (Matthew Donovan)
Date: Mon, 27 Feb 2023 14:04:43 GMT
Subject: RFR: 8298939: Refactor
 open/test/jdk/javax/rmi/ssl/SSLSocketParametersTest.sh to jtreg java test [v3]
In-Reply-To: <bxSMOO6mhn02dFo7zGDn75ytiKlsIeGnIC4Bi09qKjE=.fab90751-1e42-49e0-8f7e-fae0c40d9230@github.com>
References: <VC_ou2XS44PtyTfwXw0VZRtXcHEbXImlLZKniIPRqOw=.7d10a168-77f8-4552-97a3-8b2570e3fe29@github.com>
 <y65OxkcJ9OlzgC1Q-o62zILzqMIQA9SQk_pg6zdpe7U=.d7745cdf-f803-45bd-a3fb-8d6bb146c2c2@github.com>
 <9r-bLTPN386eFb7438VgALrjLfRcwjfoO2f5RTjabYQ=.78a0192a-3738-4d0b-ae89-cc1f3e635690@github.com>
 <24Cc7mXtQveH97zLcOxD2gH9P6qWNkdJ--I9IiFtZVo=.66068deb-3ca5-4dcc-aa70-688a9adb4c9a@github.com>
 <bxSMOO6mhn02dFo7zGDn75ytiKlsIeGnIC4Bi09qKjE=.fab90751-1e42-49e0-8f7e-fae0c40d9230@github.com>
Message-ID: <5xFNiAjWQWp1LHtxoPJpr6-HDdJSQzbozOtbb8PT568=.b11832cf-2e29-4c09-be34-b4de5d954c60@github.com>

On Tue, 21 Feb 2023 18:59:35 GMT, Stuart Marks <smarks at openjdk.org> wrote:

>> I don't think all of those code paths ever executed. If `System.exit()` is called, regardless of the exit code, `make` treats it as an error:
>> 
>> `TEST RESULT: Failed. Unexpected exit from test [exit code: 0]`
>> 
>> I added a try/catch in `main` so that if an exception is thrown during the test, `System.exit` will be called.
>
> My bad, I was confused about the execution environments. In the old test, jtreg invoked the shell script, which in turn invoked the Java test as a standalone Java program. In that environment it's paramount that every code path call System.exit() in order to avoid stale JVMs building up.
> 
> The new test is invoked directly by jtreg, which disallows calling System.exit(). Instead, every code path needs to result in the main() method completing somehow, either via a normal return or by throwing an exception directly or letting one propagate from some called method. So, you need to pull out the try/catch and any calls to System.exit(). Sorry about that.
> 
> If we're going to stick with a scheme where we're running separate JVM per test, there's no need to unexport any RMI service. When main() returns or throws an exception, jtreg will detect this and terminate the JVM because of /othervm, and any exported RMI services will be destroyed at that time. Thus, the finally-block in `testRmiCommunication` can simply be removed.

I removed the finally block.

-------------

PR: https://git.openjdk.org/jdk/pull/11910

From duke at openjdk.org  Mon Feb 27 14:35:14 2023
From: duke at openjdk.org (David M. Lloyd)
Date: Mon, 27 Feb 2023 14:35:14 GMT
Subject: RFR: 8292914: Drop the counter from lambda class names [v10]
In-Reply-To: <SRAOJEAfx--pehiYP3v1MzWkAmSNOQIqvQbDV2uzACc=.d5b9f558-5089-4db1-bcf0-c6174ff13848@github.com>
References: <GgLfH-ueBQqT-Mfk1mKpKFAt8fYqyjfVJ9lmlsBsCbo=.8dd5b3b4-4e84-4970-9179-1c0399b30edc@github.com>
 <SRAOJEAfx--pehiYP3v1MzWkAmSNOQIqvQbDV2uzACc=.d5b9f558-5089-4db1-bcf0-c6174ff13848@github.com>
Message-ID: <A9fZnM9LXemd-wM7SrhSv5gg5BgbYuslibkFJcrAAaA=.0da57806-84be-44a9-876d-44f61fd2a7cd@github.com>

On Fri, 24 Feb 2023 16:16:51 GMT, David M. Lloyd <duke at openjdk.org> wrote:

>> The class generated for lambda proxies is now defined as a hidden class. This means that the counter, which was used to ensure a unique class name and avoid clashes, is now redundant. In addition to performing redundant work, this also impacts build reproducibility for native image generators which might already have a strategy to cope with hidden classes but cannot cope with indeterminate definition order for lambda proxy classes.
>> 
>> This solves JDK-8292914 by making lambda proxy names always be stable without any configuration needed. This would also replace #10024.
>
> David M. Lloyd has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove final keyword

Ah, I see there's an integration blocker because the bug doesn't match the title of the PR.

Should I:

* Open a new bug and change the PR title
* Change the PR title to (inaccurately IMO) match the title of the bug
* Change the bug summary to match the PR
* Something else?

-------------

PR: https://git.openjdk.org/jdk/pull/12579

From duke at openjdk.org  Mon Feb 27 14:42:07 2023
From: duke at openjdk.org (Viktor Klang)
Date: Mon, 27 Feb 2023 14:42:07 GMT
Subject: RFR: JDK-8297605 DelayQueue javadoc is confusing
In-Reply-To: <m3sbJeTRxVnt7cx23kGHMaNhpOBfiYWg3fTW6S6XBys=.3f94ea53-90da-460a-80ea-416b91a7e669@github.com>
References: <jdJ46gB5VbY2LPrH7oGbtCtU65HGtd7GZ7SB8InbG-A=.8679db0c-28b2-4665-ab92-e89af0ad38e6@github.com>
 <m3sbJeTRxVnt7cx23kGHMaNhpOBfiYWg3fTW6S6XBys=.3f94ea53-90da-460a-80ea-416b91a7e669@github.com>
Message-ID: <4_sklfvrR1s8kacKlCQdvB0LeX_jjSK9aXBiWsTRr4A=.691d5958-5c91-42cd-9a5c-c36dd495862a@github.com>

On Thu, 23 Feb 2023 21:20:27 GMT, Martin Buchholz <martin at openjdk.org> wrote:

>> Clarifies the distinction between expiration of the head of DelayQueue and how it relates to `poll`, `take`, and `peek`. See discussion on https://bugs.openjdk.org/browse/JDK-8297605
>> 
>> @DougLea If possible, please weigh in on whether this is in line with your thoughts on the matter.
>
> Here's my attempt:
> 
> 
>  * An unbounded {@linkplain BlockingQueue blocking queue} of {@link Delayed}
>  * elements, in which an element generally becomes eligible for removal when its
>  * delay has expired.
>  *
>  * <p>An element is considered <em>expired</em> when its {@code
>  * getDelay(TimeUnit.NANOSECONDS)} method would return a value less than or
>  * equal to zero.
>  *
>  * <p>An element is considered the <em>head</em> of the queue if it is the
>  * element with the earliest expiration time, whether in the past or the future,
>  * if there is such an element.
>  *
>  * <p>An element is considered the <em>expired head</em> of the queue if it is
>  * the <em>expired</em> element with the earliest expiration time in the
>  * past, if there is such an element.
>  * The <em>expired head</em>, when present, is also the <em>head</em>.
>  *
>  * <p>While this class implements the {@code BlockingQueue} interface, it
>  * intentionally violates the general contract of {@code BlockingQueue}, in that
>  * the following methods disregard the presence of unexpired elements and only
>  * ever remove the <em>expired head</em>:
>  *
>  * <ul>
>  * <li> {@link #poll()}
>  * <li> {@link #poll(long,TimeUnit)}
>  * <li> {@link #take()}
>  * <li> {@link #remove()}
>  * </ul>
>  *
>  * <p>All other methods operate on both expired and unexpired elements.  For
>  * example, the {@code size} method returns the count of all elements.  Method
>  * {@link peek()} may return the non-null <em>head</em> even when {@code
>  * take()} would block waiting for that element to expire.
>  *
>  * <p>This queue does not permit null elements.

@Martin-Buchholz Martin, how would you like to proceed with your proposed wording, would you prefer a suggested edit to this PR, do a separate PR, or otherwise? /cc @AlanBateman (any recommendation, Alan? ? )

-------------

PR: https://git.openjdk.org/jdk/pull/12729

From rriggs at openjdk.org  Mon Feb 27 14:56:12 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 27 Feb 2023 14:56:12 GMT
Subject: RFR: 8292914: Drop the counter from lambda class names [v10]
In-Reply-To: <SRAOJEAfx--pehiYP3v1MzWkAmSNOQIqvQbDV2uzACc=.d5b9f558-5089-4db1-bcf0-c6174ff13848@github.com>
References: <GgLfH-ueBQqT-Mfk1mKpKFAt8fYqyjfVJ9lmlsBsCbo=.8dd5b3b4-4e84-4970-9179-1c0399b30edc@github.com>
 <SRAOJEAfx--pehiYP3v1MzWkAmSNOQIqvQbDV2uzACc=.d5b9f558-5089-4db1-bcf0-c6174ff13848@github.com>
Message-ID: <qMWRVbWxXdhew4hPKZUkepDzGgLyVEFnwK7iS5nNBqw=.6e419ae3-d4a7-4d28-892f-efc39b08112b@github.com>

On Fri, 24 Feb 2023 16:16:51 GMT, David M. Lloyd <duke at openjdk.org> wrote:

>> The class generated for lambda proxies is now defined as a hidden class. This means that the counter, which was used to ensure a unique class name and avoid clashes, is now redundant. In addition to performing redundant work, this also impacts build reproducibility for native image generators which might already have a strategy to cope with hidden classes but cannot cope with indeterminate definition order for lambda proxy classes.
>> 
>> This solves JDK-8292914 by making lambda proxy names always be stable without any configuration needed. This would also replace #10024.
>
> David M. Lloyd has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove final keyword

The cleanest way to be clear is to change the title of the bug and PR to an accurate description of the change.

-------------

PR: https://git.openjdk.org/jdk/pull/12579

From alanb at openjdk.org  Mon Feb 27 15:08:05 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 27 Feb 2023 15:08:05 GMT
Subject: RFR: 8302590: Add String.indexOf(int ch, int fromIndex,
 int toIndex) [v2]
In-Reply-To: <Ts-2wvW7MK826G_SJlALXWAn7ZDyYHU4UZcXZcaYhKQ=.374dde8e-e5bd-4c88-88b8-88af3733be29@github.com>
References: <uQ65oRaVDfpzm9bYRuo_MvSuZIdepicE3GnB3Omyngs=.fc23545b-141a-47e5-8a6a-aa28ae1375e5@github.com>
 <Ba1-pAPv01x8R5a7Xs28vdw-Y5WZ8bn253t1lcPF8WU=.cbf398ba-75d6-4ba1-a395-622f3e3a25d7@github.com>
 <T0UAk-Qz9RBzYl_R3eePcwtT7uW7TCMg0PrNB7xcGis=.2261b886-16a2-43a9-a0e8-66997dee19c1@github.com>
 <KkniribyGhakYm9e1Az7zRXcODJrtqo1aMGP4zIHOA8=.efd150ff-69d3-4a5e-805d-4a93331524bb@github.com>
 <I_429Bp7gRzXX3CkgAdkwlt3ja0UhzbQTklHBV_Jkfk=.fdf018e6-13ec-4c67-9718-2afc1ceabab9@github.com>
 <9peQfBSWnJ5Dckv--IE5H0xpIc9GHiaLMhWz7uXCmi4=.b1b77e72-913c-4837-8497-92f1f8d7166a@github.com>
 <ipjMvvgPying2FuiSAOLxIDs13CnCyTOTPZ9NMYcwVM=.856a38dc-218f-4579-9986-ef3fb652b6d9@github.com>
 <RuXCxJsLpBdQbAlRaFrlsTehQB8Lf2td3PoYmvTk2bU=.3c43d2a7-03b1-4656-a7ca-d14d709b1341@github.com>
 <dxq2LtU7jV0xDvb5A7CV9aZlMie0GfwrhWuFuk44J78=.e666c030-21f7-4f66-8bd3-1b545866d5f8@github.com>
 <psRZCqJk-RHfgaDe-TZhROF5Nxid8T2xTY1wxARR-Hw=.02712fd2-54c6-43f2-8fb8-7279fc346b77@github.com>
 <QUDwr-0EmtJYuW3HJk99BIQtLYZyB5gtgRs
 IhN8caU8=.526aff4f-83cc-4236-9d1a-7f0e307ac67b@github.com>
 <t-QauwOAS_36CzDBliJdQwJ8TuzxqYQ7ks84UuOeEDQ=.966c2846-743b-42b8-ab35-d91f0f2b8e2e@github.com>
 <Ts-2wvW7MK826G_SJlALXWAn7ZDyYHU4UZcXZcaYhKQ=.374dde8e-e5bd-4c88-88b8-88af3733be29@github.com>
Message-ID: <UW5nTQS06VNezdDjHqwYWIrud7siHN5u9EABLpxgir8=.523971c7-30d5-49ab-b932-2f08102baad4@github.com>

On Mon, 27 Feb 2023 13:38:59 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> Parking this PR while exploration is done into other options is okay.
>
> @AlanBateman Both from an `@apiNote` and from an implementation perspective, the checked _some-prefix_`IndexOf()`variants would better make use of the public 3 params `indexOf()` API point proposed here, rather than relying on `StringLatin1` and `StringUTF16` internals.
> 
> Thus, parking this PR would mean that the other PR could not refer to the API point from here until this one is integrated. 
> 
> Perhaps I'm missing something.
> Is it perhaps better to add the checked variants directly in this PR?

The suggestion is to write down some alternatives to the 3-arg indexOf method and work through some examples to see if they are less error prone. It might be that you decide to move forward with the current proposal or it might be that you decide a different method would help avoid some common mistakes.

-------------

PR: https://git.openjdk.org/jdk/pull/12600

From rriggs at openjdk.org  Mon Feb 27 15:50:03 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 27 Feb 2023 15:50:03 GMT
Subject: RFR: 8303198: System and Runtime.exit() resilience to logging errors
Message-ID: <L-cEo4rK2rAwdPUdmq0kG57Kl7atYpSKfupA2ZUTZ4E=.7dafb6d1-eb77-436f-b50f-16998af347af@github.com>

Consolidate logging and handle exceptions by printing to standard error and ignoring the exception.
Exceptions while logging will not interfere with Runtime.exit.

-------------

Commit messages:
 - Consolidate logging and handle exceptions by printing to standard error

Changes: https://git.openjdk.org/jdk/pull/12770/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12770&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8303198
  Stats: 73 lines in 2 files changed: 46 ins; 7 del; 20 mod
  Patch: https://git.openjdk.org/jdk/pull/12770.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12770/head:pull/12770

PR: https://git.openjdk.org/jdk/pull/12770

From rriggs at openjdk.org  Mon Feb 27 15:58:02 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 27 Feb 2023 15:58:02 GMT
Subject: RFR: 8303253: Remove unnecessary calls to super() in java.time value
 based classes
Message-ID: <2ZnntInYL4OsI_0-YwrIRwlOwgNNKjh7i1zA3AZv_eE=.dfba734d-dae5-4546-87e1-3771f4c4b266@github.com>

To simplify future work changing some java.time value based classes to Valhalla value classes, the explicit calls to super() are removed from Duration, Instant, and ZoneOffset.

-------------

Commit messages:
 - 8303253: Remove unnecessary calls to super() in java.time value based classes

Changes: https://git.openjdk.org/jdk/pull/12771/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12771&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8303253
  Stats: 6 lines in 3 files changed: 0 ins; 3 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/12771.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12771/head:pull/12771

PR: https://git.openjdk.org/jdk/pull/12771

From alanb at openjdk.org  Mon Feb 27 16:01:10 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 27 Feb 2023 16:01:10 GMT
Subject: RFR: 8303198: System and Runtime.exit() resilience to logging
 errors
In-Reply-To: <L-cEo4rK2rAwdPUdmq0kG57Kl7atYpSKfupA2ZUTZ4E=.7dafb6d1-eb77-436f-b50f-16998af347af@github.com>
References: <L-cEo4rK2rAwdPUdmq0kG57Kl7atYpSKfupA2ZUTZ4E=.7dafb6d1-eb77-436f-b50f-16998af347af@github.com>
Message-ID: <oXt0im7AfSA3-GpEgTgwiFIruxjnPAG73L97Z0LYeH8=.166aeccc-d299-419f-8feb-06938dae1383@github.com>

On Mon, 27 Feb 2023 15:41:01 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> Consolidate logging and handle exceptions by printing to standard error and ignoring the exception.
> Exceptions while logging will not interfere with Runtime.exit.

src/java.base/share/classes/java/lang/Shutdown.java line 189:

> 187:             } catch (Throwable throwable2) {
> 188:                 // Ignore
> 189:             }

The update means that several threads racing to exit may result in more than one message being logged. I don't think that's a big issue but just wanted to make sure that this was deliberate.

-------------

PR: https://git.openjdk.org/jdk/pull/12770

From rriggs at openjdk.org  Mon Feb 27 16:08:16 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 27 Feb 2023 16:08:16 GMT
Subject: RFR: 8303198: System and Runtime.exit() resilience to logging
 errors
In-Reply-To: <oXt0im7AfSA3-GpEgTgwiFIruxjnPAG73L97Z0LYeH8=.166aeccc-d299-419f-8feb-06938dae1383@github.com>
References: <L-cEo4rK2rAwdPUdmq0kG57Kl7atYpSKfupA2ZUTZ4E=.7dafb6d1-eb77-436f-b50f-16998af347af@github.com>
 <oXt0im7AfSA3-GpEgTgwiFIruxjnPAG73L97Z0LYeH8=.166aeccc-d299-419f-8feb-06938dae1383@github.com>
Message-ID: <rHrPLvyvNcOxOV1HsKVjbg3beRrPxrFa4GF7R4Ry_tQ=.215e28af-60bf-414a-9a13-9c062d98608a@github.com>

On Mon, 27 Feb 2023 15:58:33 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Consolidate logging and handle exceptions by printing to standard error and ignoring the exception.
>> Exceptions while logging will not interfere with Runtime.exit.
>
> src/java.base/share/classes/java/lang/Shutdown.java line 189:
> 
>> 187:             } catch (Throwable throwable2) {
>> 188:                 // Ignore
>> 189:             }
> 
> The update means that several threads racing to exit may result in more than one message being logged. I don't think that's a big issue but just wanted to make sure that this was deliberate.

Yes, its racy, and intentional, but from a diagnostic view, the developer should know that multiple callers were trying to exit. All but one will hang.  
Consolidating the code in a single method is cleaner and with fewer interactions between separate code blocks.

-------------

PR: https://git.openjdk.org/jdk/pull/12770

From naoto at openjdk.org  Mon Feb 27 16:39:25 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 27 Feb 2023 16:39:25 GMT
Subject: Integrated: 8301119: Support for GB18030-2022
In-Reply-To: <FXBchbCnbNloQO7Nlh9Ijue_c_YugGk-UC7_-ZAjY2o=.7e1ca01f-8cee-40bb-bb06-6e5670abe661@github.com>
References: <FXBchbCnbNloQO7Nlh9Ijue_c_YugGk-UC7_-ZAjY2o=.7e1ca01f-8cee-40bb-bb06-6e5670abe661@github.com>
Message-ID: <qgQlYhYos9HSO_KWfSk8FPX1pxdfch9VwquZcrsxiSc=.f6660687-b56d-464c-9e7b-5c349df3b46e@github.com>

On Fri, 10 Feb 2023 20:35:58 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Upgrading the GB18030 charset in the JDK to the latest 2022 standard. Since this is not a compatible upgrade to the existing mapping, a new system property `jdk.charset.GB18030` is introduced. If it is set to "2000", the mapping falls back to the existing mapping based on the 2000 standard, otherwise, it defaults to 2022 mapping. Refer to the corresponding CSR for more detail.

This pull request has now been integrated.

Changeset: a253b460
Author:    Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a253b4602147633a3d2e83775d1feef4f12a5272
Stats:     273 lines in 14 files changed: 117 ins; 41 del; 115 mod

8301119: Support for GB18030-2022

Reviewed-by: alanb, coffeys, lancea

-------------

PR: https://git.openjdk.org/jdk/pull/12518

From duke at openjdk.org  Mon Feb 27 17:24:26 2023
From: duke at openjdk.org (David M. Lloyd)
Date: Mon, 27 Feb 2023 17:24:26 GMT
Subject: Integrated: 8292914: Lambda proxies have unstable names
In-Reply-To: <GgLfH-ueBQqT-Mfk1mKpKFAt8fYqyjfVJ9lmlsBsCbo=.8dd5b3b4-4e84-4970-9179-1c0399b30edc@github.com>
References: <GgLfH-ueBQqT-Mfk1mKpKFAt8fYqyjfVJ9lmlsBsCbo=.8dd5b3b4-4e84-4970-9179-1c0399b30edc@github.com>
Message-ID: <CUuU0HxU-B8Y6Gg5iumwKqnIswW0GkMVZZpJV3Y6oQY=.1b529b56-3678-4f47-b128-cf9d4bb2be99@github.com>

On Wed, 15 Feb 2023 17:32:38 GMT, David M. Lloyd <duke at openjdk.org> wrote:

> The class generated for lambda proxies is now defined as a hidden class. This means that the counter, which was used to ensure a unique class name and avoid clashes, is now redundant. In addition to performing redundant work, this also impacts build reproducibility for native image generators which might already have a strategy to cope with hidden classes but cannot cope with indeterminate definition order for lambda proxy classes.
> 
> This solves JDK-8292914 by making lambda proxy names always be stable without any configuration needed. This could also replace #10024.

This pull request has now been integrated.

Changeset: b527edd3
Author:    David M. Lloyd <david.lloyd at redhat.com>
Committer: Mandy Chung <mchung at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/b527edd3388ad6a0d44a291983b08b2b5c023f8f
Stats:     160 lines in 49 files changed: 31 ins; 15 del; 114 mod

8292914: Lambda proxies have unstable names

Change the name of generated lambda proxy classes so that they no longer have a numerical suffix.

Reviewed-by: mchung

-------------

PR: https://git.openjdk.org/jdk/pull/12579

From fabio19298 at gmail.com  Mon Feb 27 17:24:56 2023
From: fabio19298 at gmail.com (Fabio Romano)
Date: Mon, 27 Feb 2023 18:24:56 +0100
Subject: Made random generation of BigIntegers faster
Message-ID: <CAEuo5R4QwHYfs1w4FuWDKYmhKV4HNzbD+FEYu5Re1wFfwtXP9g@mail.gmail.com>

This enhancement makes the generation of random BigIntegers faster, using
directly a random generated int[] magnitude array instead of a byte[]
array. This permits to call trustedStripLeadingZeroInts() instead of
stripLeadingZeroBytes(), in order to avoid copying the contents of the
byte[] array in an int[] array if not necessary, since, unlike the previous
implementation, the int[] array is not used as an argument by the method of
the Random object used to generate random ints.
Link to Pull request: https://github.com/openjdk/jdk/pull/12775
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20230227/a964659f/attachment.htm>

From naoto at openjdk.org  Mon Feb 27 17:31:08 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 27 Feb 2023 17:31:08 GMT
Subject: RFR: 8303253: Remove unnecessary calls to super() in java.time
 value based classes
In-Reply-To: <2ZnntInYL4OsI_0-YwrIRwlOwgNNKjh7i1zA3AZv_eE=.dfba734d-dae5-4546-87e1-3771f4c4b266@github.com>
References: <2ZnntInYL4OsI_0-YwrIRwlOwgNNKjh7i1zA3AZv_eE=.dfba734d-dae5-4546-87e1-3771f4c4b266@github.com>
Message-ID: <Os9vWNCY_6dqNA0XUaaKFkATDk93fRD0Wlf1JDN6Rm0=.0471afbc-5a83-4ad4-954e-72d5bd9aaaa0@github.com>

On Mon, 27 Feb 2023 15:50:02 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> To simplify future work changing some java.time value based classes to Valhalla value classes, the explicit calls to super() are removed from Duration, Instant, and ZoneOffset.

LGTM

-------------

Marked as reviewed by naoto (Reviewer).

PR: https://git.openjdk.org/jdk/pull/12771

From jlu at openjdk.org  Mon Feb 27 17:37:48 2023
From: jlu at openjdk.org (Justin Lu)
Date: Mon, 27 Feb 2023 17:37:48 GMT
Subject: RFR: 8282319: java.util.Locale method to stream available Locales
 [v4]
In-Reply-To: <QxcV7IwdW13WfT0X0PKyWBWpo_rP588AgHIYiUu3E_Q=.82b88828-e8ec-4f3c-a75a-ec88b589d4e2@github.com>
References: <QxcV7IwdW13WfT0X0PKyWBWpo_rP588AgHIYiUu3E_Q=.82b88828-e8ec-4f3c-a75a-ec88b589d4e2@github.com>
Message-ID: <EE3Qak3d_mhBJffp8BN4bXtfCHwwtZzwRFv6s6u1Vps=.9ba1ec96-1279-490f-83c8-217b29e350f5@github.com>

> This PR adds a new method to java.util.Locale which returns Stream<Locale>
> 
> The contents of the Stream are composed of the same underlying elements as Locale.getAvailableLocales().
> 
> This method allows streaming of the Locale array without creating a defensive copy.

Justin Lu has updated the pull request incrementally with one additional commit since the last revision:

  Switch {@return for @return for consistency

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12269/files
  - new: https://git.openjdk.org/jdk/pull/12269/files/b4d0ceff..3995a038

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12269&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12269&range=02-03

  Stats: 7 lines in 2 files changed: 3 ins; 2 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/12269.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12269/head:pull/12269

PR: https://git.openjdk.org/jdk/pull/12269

From jlu at openjdk.org  Mon Feb 27 17:37:51 2023
From: jlu at openjdk.org (Justin Lu)
Date: Mon, 27 Feb 2023 17:37:51 GMT
Subject: RFR: 8282319: java.util.Locale method to stream available Locales
 [v4]
In-Reply-To: <UinlfQjpLXJkQG_htNNgBOxTLSWxZMEoXBbjMyfSTRk=.2d95dd83-e4c7-4c47-8a6c-8744b09e2a00@github.com>
References: <QxcV7IwdW13WfT0X0PKyWBWpo_rP588AgHIYiUu3E_Q=.82b88828-e8ec-4f3c-a75a-ec88b589d4e2@github.com>
 <Qy9riGxMB2o0xwjBc1BGcLACNF-bLtMyN657jEqslUA=.eef77647-27bf-41d9-8660-ada00cb5b537@github.com>
 <3_P5D-o1sd8I3HCikS39S5LhEmmMV6f787wwffkuJQU=.5a8e2eee-2b3d-4904-9665-372e82e584ad@github.com>
 <0_zm1BN0d7_M2lQaL8hQovM-L2nm_Y3QsOnGj9y35IM=.3d2333d9-f3a8-413b-ac12-f62b66785ee8@github.com>
 <Y-8deBLWqXedPstR9iVGr-CxLyxriwsEbhdMBddNNME=.09b2307f-1672-49b2-a5f9-f529df906d21@github.com>
 <TTxOmftDjmmAofhxmZko-33dqbiNtu6mZSAtpkAk15k=.d70af2f5-bc85-45b2-9661-45023da1263f@github.com>
 <UinlfQjpLXJkQG_htNNgBOxTLSWxZMEoXBbjMyfSTRk=.2d95dd83-e4c7-4c47-8a6c-8744b09e2a00@github.com>
Message-ID: <DUv0DU3rJyskYi1DeUT0lpLe6uYA2vyK9--gqqfS1lw=.1fb90dbc-959f-4602-9355-7b9082e1a474@github.com>

On Fri, 24 Feb 2023 22:10:11 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Makes sense, will look at both Locale and LocaleServiceProviderPool and update the methods that are applicable for {@return ..}. Thanks Lance
>
> That's getting a bit far afield of the original issue; a separate issue might be a better way to address those cases. $.02

Hi Lance and Roger, I have switched the tag {@return to @return for consistency. And like you proposed Roger, I will open a separate issue to address converting the tags.

-------------

PR: https://git.openjdk.org/jdk/pull/12269

From mchung at openjdk.org  Mon Feb 27 17:38:07 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Mon, 27 Feb 2023 17:38:07 GMT
Subject: RFR: 8303253: Remove unnecessary calls to super() in java.time
 value based classes
In-Reply-To: <2ZnntInYL4OsI_0-YwrIRwlOwgNNKjh7i1zA3AZv_eE=.dfba734d-dae5-4546-87e1-3771f4c4b266@github.com>
References: <2ZnntInYL4OsI_0-YwrIRwlOwgNNKjh7i1zA3AZv_eE=.dfba734d-dae5-4546-87e1-3771f4c4b266@github.com>
Message-ID: <l13QXAU-eZk3XdpGrbFAxV0wpz_dEGzDUTtYWzFE7pQ=.50416086-77fb-429f-bd45-1eb0acdbd4ba@github.com>

On Mon, 27 Feb 2023 15:50:02 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> To simplify future work changing some java.time value based classes to Valhalla value classes, the explicit calls to super() are removed from Duration, Instant, and ZoneOffset.

Marked as reviewed by mchung (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/12771

From lancea at openjdk.org  Mon Feb 27 17:38:08 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Mon, 27 Feb 2023 17:38:08 GMT
Subject: RFR: 8303253: Remove unnecessary calls to super() in java.time
 value based classes
In-Reply-To: <2ZnntInYL4OsI_0-YwrIRwlOwgNNKjh7i1zA3AZv_eE=.dfba734d-dae5-4546-87e1-3771f4c4b266@github.com>
References: <2ZnntInYL4OsI_0-YwrIRwlOwgNNKjh7i1zA3AZv_eE=.dfba734d-dae5-4546-87e1-3771f4c4b266@github.com>
Message-ID: <UgDtcQXr62zZe0No0PzALGf37kV_ddOIi6x0b0qVdfQ=.42f3b9fd-03ce-4886-b84d-a4ad369b38a1@github.com>

On Mon, 27 Feb 2023 15:50:02 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> To simplify future work changing some java.time value based classes to Valhalla value classes, the explicit calls to super() are removed from Duration, Instant, and ZoneOffset.

Marked as reviewed by lancea (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/12771

From lancea at openjdk.org  Mon Feb 27 17:43:13 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Mon, 27 Feb 2023 17:43:13 GMT
Subject: RFR: 8282319: java.util.Locale method to stream available Locales
 [v4]
In-Reply-To: <EE3Qak3d_mhBJffp8BN4bXtfCHwwtZzwRFv6s6u1Vps=.9ba1ec96-1279-490f-83c8-217b29e350f5@github.com>
References: <QxcV7IwdW13WfT0X0PKyWBWpo_rP588AgHIYiUu3E_Q=.82b88828-e8ec-4f3c-a75a-ec88b589d4e2@github.com>
 <EE3Qak3d_mhBJffp8BN4bXtfCHwwtZzwRFv6s6u1Vps=.9ba1ec96-1279-490f-83c8-217b29e350f5@github.com>
Message-ID: <XJi-0xk7rq2dZCmiT737s58uCZK3jauN0MW6YmJZcCM=.dc883e26-e33f-4500-966c-fdf8eb2704a6@github.com>

On Mon, 27 Feb 2023 17:37:48 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> This PR adds a new method to java.util.Locale which returns Stream<Locale>
>> 
>> The contents of the Stream are composed of the same underlying elements as Locale.getAvailableLocales().
>> 
>> This method allows streaming of the Locale array without creating a defensive copy.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Switch {@return for @return for consistency

Marked as reviewed by lancea (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/12269

From lancea at openjdk.org  Mon Feb 27 17:43:15 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Mon, 27 Feb 2023 17:43:15 GMT
Subject: RFR: 8282319: java.util.Locale method to stream available Locales
 [v4]
In-Reply-To: <DUv0DU3rJyskYi1DeUT0lpLe6uYA2vyK9--gqqfS1lw=.1fb90dbc-959f-4602-9355-7b9082e1a474@github.com>
References: <QxcV7IwdW13WfT0X0PKyWBWpo_rP588AgHIYiUu3E_Q=.82b88828-e8ec-4f3c-a75a-ec88b589d4e2@github.com>
 <Qy9riGxMB2o0xwjBc1BGcLACNF-bLtMyN657jEqslUA=.eef77647-27bf-41d9-8660-ada00cb5b537@github.com>
 <3_P5D-o1sd8I3HCikS39S5LhEmmMV6f787wwffkuJQU=.5a8e2eee-2b3d-4904-9665-372e82e584ad@github.com>
 <0_zm1BN0d7_M2lQaL8hQovM-L2nm_Y3QsOnGj9y35IM=.3d2333d9-f3a8-413b-ac12-f62b66785ee8@github.com>
 <Y-8deBLWqXedPstR9iVGr-CxLyxriwsEbhdMBddNNME=.09b2307f-1672-49b2-a5f9-f529df906d21@github.com>
 <TTxOmftDjmmAofhxmZko-33dqbiNtu6mZSAtpkAk15k=.d70af2f5-bc85-45b2-9661-45023da1263f@github.com>
 <UinlfQjpLXJkQG_htNNgBOxTLSWxZMEoXBbjMyfSTRk=.2d95dd83-e4c7-4c47-8a6c-8744b09e2a00@github.com>
 <DUv0DU3rJyskYi1DeUT0lpLe6uYA2vyK9--gqqfS1lw=.1fb90dbc-959f-4602-9355-7b9082e1a474@github.com>
Message-ID: <ycDYE-H7zpxGkJkkvisXUSYuR1rWrxgSzRrdVhxj9DI=.4a10a4ea-2ecc-45ea-821e-8a91cd44d821@github.com>

On Mon, 27 Feb 2023 17:32:47 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Hi Lance and Roger, I have switched the tag {@return to @return for consistency. And like you proposed Roger, I will open a separate issue to address converting the tags.

Thank you Justin

-------------

PR: https://git.openjdk.org/jdk/pull/12269

From lmesnik at openjdk.org  Mon Feb 27 17:48:40 2023
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Mon, 27 Feb 2023 17:48:40 GMT
Subject: RFR: 8303133: Update ProcessTools.startProcess(...) to exit early
 if process exit before linePredicate is printed. [v3]
In-Reply-To: <cuDocKEsnNWZvi2L_E6XBQ_U0T8qnNCIupmsFxaSjEw=.867a6664-21bc-44fb-aa68-9b9a1e8d36d7@github.com>
References: <cuDocKEsnNWZvi2L_E6XBQ_U0T8qnNCIupmsFxaSjEw=.867a6664-21bc-44fb-aa68-9b9a1e8d36d7@github.com>
Message-ID: <2zwPlFBvOGNHBmdhn46kSP5Ylmi2j2hT3hxidEodWl0=.d62db320-0811-432d-b15f-a34232f9ded5@github.com>

> The solution proposed by Stefan K
> 
> The startProcess() might wait forever for the expected line if the process exits (failed to start). It makes sense to just fail earlier in such cases.
> 
> The fix also move
> 'output = new OutputAnalyzer(this.process);'
> in method xrun() to be able to try to print them in waitFor is failed/interrupted.

Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:

  fixed conditions.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12751/files
  - new: https://git.openjdk.org/jdk/pull/12751/files/890dcc34..5b7e3897

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12751&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12751&range=01-02

  Stats: 19 lines in 2 files changed: 4 ins; 12 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/12751.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12751/head:pull/12751

PR: https://git.openjdk.org/jdk/pull/12751

From lmesnik at openjdk.org  Mon Feb 27 18:01:11 2023
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Mon, 27 Feb 2023 18:01:11 GMT
Subject: RFR: 8303133: Update ProcessTools.startProcess(...) to exit early
 if process exit before linePredicate is printed. [v2]
In-Reply-To: <AjOfPfyDCivxwdzxRWR4PUeqs2Q94LPtgwEBPAHQ-sY=.19b76733-2d8a-4f6f-81d4-0e05f08b5347@github.com>
References: <cuDocKEsnNWZvi2L_E6XBQ_U0T8qnNCIupmsFxaSjEw=.867a6664-21bc-44fb-aa68-9b9a1e8d36d7@github.com>
 <YMRU3NTKiOEw7VS24xhISyijlTyeTeqRFzG-P3Uo3BQ=.7f5772b3-17bb-4985-88b9-8d11acc9392e@github.com>
 <AjOfPfyDCivxwdzxRWR4PUeqs2Q94LPtgwEBPAHQ-sY=.19b76733-2d8a-4f6f-81d4-0e05f08b5347@github.com>
Message-ID: <iytH_wtutpe_Cnd25gbG8Ww4vE-D6H8ivMfAU5xjhCY=.b5f4d50e-5f83-4877-a283-a0fe47e0d265@github.com>

On Mon, 27 Feb 2023 04:54:57 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   updated to always check if process is alive.
>
> test/lib/jdk/test/lib/process/ProcessTools.java line 220:
> 
>> 218:             if (timeout > -1) {
>> 219:                 // Every second check if process is still alive
>> 220:                 boolean succeeded = Utils.waitForCondition(() -> {
> 
> This use of `waitForCondition` with a sleep time of zero confused me quite a bit. Now I realize that you are putting `waitForCondition` into a potential busy-poll loop, but then you introduce the one-second timed `await` as part of the condition, thus effectively checking the condition once a second. This seems somewhat convoluted compared to just using a sleep time of 1000ms and changing the `await` to a call to `getCount() > 0`.

Using await() is more effective than checking every second. However, might be it is not essential for multi-process synchronization.

> test/lib/jdk/test/lib/process/ProcessTools.java line 224:
> 
>> 222:                     if (!p.isAlive()) {
>> 223:                         latch.countDown();
>> 224:                         throw new RuntimeException("Started process " + name + " is not alive.");
> 
> This seems problematic. The process has terminated but you don't know why - it may have completed normally and produced all the output such that the `await` below would return immediately with `true`, but you are now going to throw an exception. ???

Thanks! You are right, we need to check first if the line has been printed.
However, there is an interesting question the process can exit before streams are read and the latch is set to zero. The documentation says that linePredicate should detect if the process is warmed-up. So it is not expected that it should exit right after the start.

> test/lib/jdk/test/lib/thread/ProcessThread.java line 153:
> 
>> 151:         @Override
>> 152:         public void xrun() throws Throwable {
>> 153:             String name = Thread.currentThread().getName();
> 
> The original code passes the name of the `ProcessRunnable` to `startProcess`, not the name of the current thread. It is not obvious/apparent that they are the same. But if they are then it is cheaper to use `name` than do a dynamic query on the current thread.

Thanks! Fixed, it is a mistake.

-------------

PR: https://git.openjdk.org/jdk/pull/12751

From rriggs at openjdk.org  Mon Feb 27 18:09:31 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 27 Feb 2023 18:09:31 GMT
Subject: RFR: 8282319: java.util.Locale method to stream available Locales
 [v4]
In-Reply-To: <EE3Qak3d_mhBJffp8BN4bXtfCHwwtZzwRFv6s6u1Vps=.9ba1ec96-1279-490f-83c8-217b29e350f5@github.com>
References: <QxcV7IwdW13WfT0X0PKyWBWpo_rP588AgHIYiUu3E_Q=.82b88828-e8ec-4f3c-a75a-ec88b589d4e2@github.com>
 <EE3Qak3d_mhBJffp8BN4bXtfCHwwtZzwRFv6s6u1Vps=.9ba1ec96-1279-490f-83c8-217b29e350f5@github.com>
Message-ID: <JZ-hfshlj8g7BG3DsnhTVx-zIgL_2EnvAW3mYNi7qwU=.dd409c06-d692-4291-8232-059bd68355d9@github.com>

On Mon, 27 Feb 2023 17:37:48 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> This PR adds a new method to java.util.Locale which returns Stream<Locale>
>> 
>> The contents of the Stream are composed of the same underlying elements as Locale.getAvailableLocales().
>> 
>> This method allows streaming of the Locale array without creating a defensive copy.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Switch {@return for @return for consistency

Marked as reviewed by rriggs (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/12269

From rriggs at openjdk.org  Mon Feb 27 18:14:32 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 27 Feb 2023 18:14:32 GMT
Subject: Integrated: 8303253: Remove unnecessary calls to super() in java.time
 value based classes
In-Reply-To: <2ZnntInYL4OsI_0-YwrIRwlOwgNNKjh7i1zA3AZv_eE=.dfba734d-dae5-4546-87e1-3771f4c4b266@github.com>
References: <2ZnntInYL4OsI_0-YwrIRwlOwgNNKjh7i1zA3AZv_eE=.dfba734d-dae5-4546-87e1-3771f4c4b266@github.com>
Message-ID: <q5YuKefc2YzBwVCwImbBixN-qs0ynodMn2KL97c6MC8=.ee62b2ed-3f92-4a16-bb9b-af8c75d4ef8a@github.com>

On Mon, 27 Feb 2023 15:50:02 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> To simplify future work changing some java.time value based classes to Valhalla value classes, the explicit calls to super() are removed from Duration, Instant, and ZoneOffset.

This pull request has now been integrated.

Changeset: 4c169d2d
Author:    Roger Riggs <rriggs at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/4c169d2d7c3082a278946175874777f78d45b0bc
Stats:     6 lines in 3 files changed: 0 ins; 3 del; 3 mod

8303253: Remove unnecessary calls to super() in java.time value based classes

Reviewed-by: naoto, mchung, lancea

-------------

PR: https://git.openjdk.org/jdk/pull/12771

From rgiulietti at openjdk.org  Mon Feb 27 18:25:08 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Mon, 27 Feb 2023 18:25:08 GMT
Subject: RFR: 8302590: Add String.indexOf(int ch, int fromIndex,
 int toIndex) [v2]
In-Reply-To: <UW5nTQS06VNezdDjHqwYWIrud7siHN5u9EABLpxgir8=.523971c7-30d5-49ab-b932-2f08102baad4@github.com>
References: <uQ65oRaVDfpzm9bYRuo_MvSuZIdepicE3GnB3Omyngs=.fc23545b-141a-47e5-8a6a-aa28ae1375e5@github.com>
 <Ba1-pAPv01x8R5a7Xs28vdw-Y5WZ8bn253t1lcPF8WU=.cbf398ba-75d6-4ba1-a395-622f3e3a25d7@github.com>
 <T0UAk-Qz9RBzYl_R3eePcwtT7uW7TCMg0PrNB7xcGis=.2261b886-16a2-43a9-a0e8-66997dee19c1@github.com>
 <KkniribyGhakYm9e1Az7zRXcODJrtqo1aMGP4zIHOA8=.efd150ff-69d3-4a5e-805d-4a93331524bb@github.com>
 <I_429Bp7gRzXX3CkgAdkwlt3ja0UhzbQTklHBV_Jkfk=.fdf018e6-13ec-4c67-9718-2afc1ceabab9@github.com>
 <9peQfBSWnJ5Dckv--IE5H0xpIc9GHiaLMhWz7uXCmi4=.b1b77e72-913c-4837-8497-92f1f8d7166a@github.com>
 <ipjMvvgPying2FuiSAOLxIDs13CnCyTOTPZ9NMYcwVM=.856a38dc-218f-4579-9986-ef3fb652b6d9@github.com>
 <RuXCxJsLpBdQbAlRaFrlsTehQB8Lf2td3PoYmvTk2bU=.3c43d2a7-03b1-4656-a7ca-d14d709b1341@github.com>
 <dxq2LtU7jV0xDvb5A7CV9aZlMie0GfwrhWuFuk44J78=.e666c030-21f7-4f66-8bd3-1b545866d5f8@github.com>
 <psRZCqJk-RHfgaDe-TZhROF5Nxid8T2xTY1wxARR-Hw=.02712fd2-54c6-43f2-8fb8-7279fc346b77@github.com>
 <QUDwr-0EmtJYuW3HJk99BIQtLYZyB5gtgRs
 IhN8caU8=.526aff4f-83cc-4236-9d1a-7f0e307ac67b@github.com>
 <t-QauwOAS_36CzDBliJdQwJ8TuzxqYQ7ks84UuOeEDQ=.966c2846-743b-42b8-ab35-d91f0f2b8e2e@github.com>
 <Ts-2wvW7MK826G_SJlALXWAn7ZDyYHU4UZcXZcaYhKQ=.374dde8e-e5bd-4c88-88b8-88af3733be29@github.com>
 <UW5nTQS06VNezdDjHqwYWIrud7siHN5u9EABLpxgir8=.523971c7-30d5-49ab-b932-2f08102baad4@github.com>
Message-ID: <aIi7ms-C449gkHdOVngwl2AQiVwpwzBm3vWy5HBgoOU=.b52a8b60-e247-4333-8110-c4dfb326efe0@github.com>

On Mon, 27 Feb 2023 15:05:05 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> @AlanBateman Both from an `@apiNote` and from an implementation perspective, the checked _some-prefix_`IndexOf()`variants would better make use of the public 3 params `indexOf()` API point proposed here, rather than relying on `StringLatin1` and `StringUTF16` internals.
>> 
>> Thus, parking this PR would mean that the other PR could not refer to the API point from here until this one is integrated. 
>> 
>> Perhaps I'm missing something.
>> Is it perhaps better to add the checked variants directly in this PR?
>
> The suggestion is to write down some alternatives to the 3-arg indexOf method and work through some examples to see if they are less error prone. It might be that you decide to move forward with the current proposal or it might be that you decide a different method would help avoid some common mistakes.

An obvious alternative that comes to mind is an additional `checkedIndexOf(int ch, int fromIndex, int toIndex)` that behaves like `substring()` in checking the indices, and like the 3 params `indexOf()` when not throwing.

Depending on the invocation context, this might help in some cases, in particular when the arguments have not been validated before: a programmer can then rely on the "battery-included" check.

-------------

PR: https://git.openjdk.org/jdk/pull/12600

From darcy at openjdk.org  Mon Feb 27 18:26:51 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Mon, 27 Feb 2023 18:26:51 GMT
Subject: RFR: JDK-8302040: Port fdlibm sqrt to Java [v5]
In-Reply-To: <rjVM2lWPdsvPcfLF3oNShP-cSN8-P-i16ikUC3sTgIg=.1d4f470d-2ac9-4394-b55e-099affce763f@github.com>
References: <rjVM2lWPdsvPcfLF3oNShP-cSN8-P-i16ikUC3sTgIg=.1d4f470d-2ac9-4394-b55e-099affce763f@github.com>
Message-ID: <ydzE4UeDk8qDeT_rwe6YkxniMdBiSMSuteVLJOTEVn8=.5a15a4a5-1e65-4a4b-871d-3ff010d7fa12@github.com>

> The wheel of FDLIBM porting turns a notch and sqrt comes into play.
> 
> While the sqrt operation usually has a hardware implementation that is intrinsified, for completeness a software implementation should be available as well.

Joe Darcy 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:

 - Enable intrinsic for StrictMath.sqrt; thanks to Tobias Hartmann for assistance with the HotSpot updates.
 - Merge branch 'master' into JDK-8302040
 - Implement review feedback.
 - Add one one unsigned shift comment.
 - Respond to review feedback.
 - JDK-8302040: Port fdlibm sqrt to Java

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12736/files
  - new: https://git.openjdk.org/jdk/pull/12736/files/ed06ecbb..f7a40d53

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12736&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12736&range=03-04

  Stats: 2865 lines in 76 files changed: 1654 ins; 745 del; 466 mod
  Patch: https://git.openjdk.org/jdk/pull/12736.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12736/head:pull/12736

PR: https://git.openjdk.org/jdk/pull/12736

From darcy at openjdk.org  Mon Feb 27 18:47:48 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Mon, 27 Feb 2023 18:47:48 GMT
Subject: RFR: JDK-8302040: Port fdlibm sqrt to Java [v5]
In-Reply-To: <ydzE4UeDk8qDeT_rwe6YkxniMdBiSMSuteVLJOTEVn8=.5a15a4a5-1e65-4a4b-871d-3ff010d7fa12@github.com>
References: <rjVM2lWPdsvPcfLF3oNShP-cSN8-P-i16ikUC3sTgIg=.1d4f470d-2ac9-4394-b55e-099affce763f@github.com>
 <ydzE4UeDk8qDeT_rwe6YkxniMdBiSMSuteVLJOTEVn8=.5a15a4a5-1e65-4a4b-871d-3ff010d7fa12@github.com>
Message-ID: <aJJ8VjoovY5_IlY0xi9wkO2JMvpZY4LiJk80Z9ye2qk=.e6df1a48-3f45-4fec-a0ee-5e547ee4496f@github.com>

On Mon, 27 Feb 2023 18:26:51 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> The wheel of FDLIBM porting turns a notch and sqrt comes into play.
>> 
>> While the sqrt operation usually has a hardware implementation that is intrinsified, for completeness a software implementation should be available as well.
>
> Joe Darcy 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:
> 
>  - Enable intrinsic for StrictMath.sqrt; thanks to Tobias Hartmann for assistance with the HotSpot updates.
>  - Merge branch 'master' into JDK-8302040
>  - Implement review feedback.
>  - Add one one unsigned shift comment.
>  - Respond to review feedback.
>  - JDK-8302040: Port fdlibm sqrt to Java

Adding hotspot-compiler to get get explicit review of small changes to enable intrinsics support for  StrictMath.sqrt after it was changed from a native method to a Java one. Specific VM changes:


diff --git a/src/hotspot/share/classfile/vmIntrinsics.hpp b/src/hotspot/share/classfile/vmIntrinsics.hpp
index 02be97362c7dc..6d1ad75ae688c 100644
--- a/src/hotspot/share/classfile/vmIntrinsics.hpp
+++ b/src/hotspot/share/classfile/vmIntrinsics.hpp
@@ -202,8 +202,8 @@ class methodHandle;
   do_intrinsic(_maxF_strict,              java_lang_StrictMath,   max_name,           float2_float_signature,    F_S)   \
   do_intrinsic(_minD_strict,              java_lang_StrictMath,   min_name,           double2_double_signature,  F_S)   \
   do_intrinsic(_maxD_strict,              java_lang_StrictMath,   max_name,           double2_double_signature,  F_S)   \
-  /* Special flavor of dsqrt intrinsic to handle the "native" method in StrictMath. Otherwise the same as in Math. */   \
-  do_intrinsic(_dsqrt_strict,             java_lang_StrictMath,   sqrt_name,          double_double_signature,   F_SN)  \
+  /* Additional dsqrt intrinsic to directly handle the sqrt method in StrictMath. Otherwise the same as in Math. */     \
+  do_intrinsic(_dsqrt_strict,             java_lang_StrictMath,   sqrt_name,          double_double_signature,   F_S)   \
                                                                                                                         \
   do_intrinsic(_floatIsInfinite,          java_lang_Float,        isInfinite_name,    float_bool_signature,      F_S)   \
    do_name(     isInfinite_name,                                  "isInfinite")                                         \
diff --git a/src/hotspot/share/interpreter/abstractInterpreter.cpp b/src/hotspot/share/interpreter/abstractInterpreter.cpp
index 875211d6d0527..8d6ef06754cfe 100644
--- a/src/hotspot/share/interpreter/abstractInterpreter.cpp
+++ b/src/hotspot/share/interpreter/abstractInterpreter.cpp
@@ -148,7 +148,7 @@ AbstractInterpreter::MethodKind AbstractInterpreter::method_kind(const methodHan
       case vmIntrinsics::_fmaD:              return java_lang_math_fmaD;
       case vmIntrinsics::_fmaF:              return java_lang_math_fmaF;
       case vmIntrinsics::_dsqrt:             return java_lang_math_sqrt;
-      case vmIntrinsics::_dsqrt_strict:      return native;
+      case vmIntrinsics::_dsqrt_strict:      return java_lang_math_sqrt;
       case vmIntrinsics::_Reference_get:     return java_lang_ref_reference_get;
       case vmIntrinsics::_Object_init:
         if (RegisterFinalizersAtInit && m->code_size() == 1) {

-------------

PR: https://git.openjdk.org/jdk/pull/12736

From kvn at openjdk.org  Mon Feb 27 18:48:43 2023
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Mon, 27 Feb 2023 18:48:43 GMT
Subject: RFR: 8143900: OptimizeStringConcat has an opaque dependency on
 Integer.sizeTable field [v3]
In-Reply-To: <XPNd_hxtNRtbk8H5IYegQzNB3dpwf595zP3L6Ab3OEQ=.10f4dc93-def6-476e-add1-5fb886aca69c@github.com>
References: <wVJP9KUVBORqE2Y2rPoPzePyKqbUTiE6fKiS1iOw9j4=.91a2c4c5-6da7-461e-8d65-d6e41bb5f4ff@github.com>
 <XPNd_hxtNRtbk8H5IYegQzNB3dpwf595zP3L6Ab3OEQ=.10f4dc93-def6-476e-add1-5fb886aca69c@github.com>
Message-ID: <1hTcUqaVvcRRhyMHFXbJOZfjOXEFs2VRcFOKsklEEeE=.4457cda4-afcd-43eb-ae33-2bb967cf3a01@github.com>

On Mon, 27 Feb 2023 02:16:21 GMT, Yi Yang <yyang at openjdk.org> wrote:

>> Hi, can I have a review for this patch? I noticed a strange field Integer.sizeTable which is used by PhaseStringOpts, after digging into the history, I think it could be replaced by an in-place array allocation and initialization. Before it, we are fetching from Integer.sizeTable and get num of digit in integer by iterating size table, now we fetch from in-place sizeTable and get size from that. The changed IR looks like this:
>> 
>> ![image](https://user-images.githubusercontent.com/5010047/220239446-7b8b8381-b300-4f2c-a24a-aa19ec9e2f88.png)
>> 
>> Thanks.
>
> Yi Yang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   comment from review feedback

Looks good.

-------------

Marked as reviewed by kvn (Reviewer).

PR: https://git.openjdk.org/jdk/pull/12680

From kvn at openjdk.org  Mon Feb 27 18:48:46 2023
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Mon, 27 Feb 2023 18:48:46 GMT
Subject: RFR: 8143900: OptimizeStringConcat has an opaque dependency on
 Integer.sizeTable field [v2]
In-Reply-To: <KawZ7nCg4aCUnJHJMLAdt5jVlzAtng20397OUiFejKU=.eba4ca68-6056-4289-b719-26ee0bdb3805@github.com>
References: <wVJP9KUVBORqE2Y2rPoPzePyKqbUTiE6fKiS1iOw9j4=.91a2c4c5-6da7-461e-8d65-d6e41bb5f4ff@github.com>
 <upouJcFH3Uw0SXK1OZHRgx5X_fQy9ZI2MbdkjrtjsKs=.c382dad7-a3a7-48f1-a493-db4a2ea80849@github.com>
 <PFqUJxR3nKSS_z9H73S7ZWBwI5fBpB2GGIBpzQsSmDI=.e6de4ad8-2155-4f65-9814-3ee28fc9a7f7@github.com>
 <KawZ7nCg4aCUnJHJMLAdt5jVlzAtng20397OUiFejKU=.eba4ca68-6056-4289-b719-26ee0bdb3805@github.com>
Message-ID: <hInA3YRtPEF4vfp9K8AKUMPTwMdUTtPYvqm4c8RTTbU=.cd84da0e-3f31-4dbd-a38f-7bd9c1821788@github.com>

On Mon, 27 Feb 2023 02:04:13 GMT, Yi Yang <yyang at openjdk.org> wrote:

> > Testing results seem good. Except one strange failure I put in [JDK-8143900](https://bugs.openjdk.org/browse/JDK-8143900) comment. You need second review.
> 
> This seems related to https://bugs.openjdk.org/browse/JDK-8296914

[JDK-8296914 ](https://bugs.openjdk.org/browse/JDK-8296914)was closed as duplicate of still opened [JDK-8270202](https://bugs.openjdk.org/browse/JDK-8270202)

-------------

PR: https://git.openjdk.org/jdk/pull/12680

From martin at openjdk.org  Mon Feb 27 20:12:21 2023
From: martin at openjdk.org (Martin Buchholz)
Date: Mon, 27 Feb 2023 20:12:21 GMT
Subject: RFR: JDK-8297605 DelayQueue javadoc is confusing
In-Reply-To: <m3sbJeTRxVnt7cx23kGHMaNhpOBfiYWg3fTW6S6XBys=.3f94ea53-90da-460a-80ea-416b91a7e669@github.com>
References: <jdJ46gB5VbY2LPrH7oGbtCtU65HGtd7GZ7SB8InbG-A=.8679db0c-28b2-4665-ab92-e89af0ad38e6@github.com>
 <m3sbJeTRxVnt7cx23kGHMaNhpOBfiYWg3fTW6S6XBys=.3f94ea53-90da-460a-80ea-416b91a7e669@github.com>
Message-ID: <jTNA5IGsXt8szGzobAncx9EXwDIn-JYor5oUyWW3iXM=.2208a83c-c44d-4916-ba88-498cfd614d2d@github.com>

On Thu, 23 Feb 2023 21:20:27 GMT, Martin Buchholz <martin at openjdk.org> wrote:

>> Clarifies the distinction between expiration of the head of DelayQueue and how it relates to `poll`, `take`, and `peek`. See discussion on https://bugs.openjdk.org/browse/JDK-8297605
>> 
>> @DougLea If possible, please weigh in on whether this is in line with your thoughts on the matter.
>
> Here's my attempt:
> 
> 
>  * An unbounded {@linkplain BlockingQueue blocking queue} of {@link Delayed}
>  * elements, in which an element generally becomes eligible for removal when its
>  * delay has expired.
>  *
>  * <p>An element is considered <em>expired</em> when its {@code
>  * getDelay(TimeUnit.NANOSECONDS)} method would return a value less than or
>  * equal to zero.
>  *
>  * <p>An element is considered the <em>head</em> of the queue if it is the
>  * element with the earliest expiration time, whether in the past or the future,
>  * if there is such an element.
>  *
>  * <p>An element is considered the <em>expired head</em> of the queue if it is
>  * the <em>expired</em> element with the earliest expiration time in the
>  * past, if there is such an element.
>  * The <em>expired head</em>, when present, is also the <em>head</em>.
>  *
>  * <p>While this class implements the {@code BlockingQueue} interface, it
>  * intentionally violates the general contract of {@code BlockingQueue}, in that
>  * the following methods disregard the presence of unexpired elements and only
>  * ever remove the <em>expired head</em>:
>  *
>  * <ul>
>  * <li> {@link #poll()}
>  * <li> {@link #poll(long,TimeUnit)}
>  * <li> {@link #take()}
>  * <li> {@link #remove()}
>  * </ul>
>  *
>  * <p>All other methods operate on both expired and unexpired elements.  For
>  * example, the {@code size} method returns the count of all elements.  Method
>  * {@link peek()} may return the non-null <em>head</em> even when {@code
>  * take()} would block waiting for that element to expire.
>  *
>  * <p>This queue does not permit null elements.

> @Martin-Buchholz Martin, how would you like to proceed with your proposed wording, would you prefer a suggested edit to this PR, do a separate PR, or otherwise? /cc @AlanBateman (any recommendation, Alan? thinking )

Talked me into it - I will dust off my github/skara skillz and make a new PR.  

I wonder if there's now a way to override javadoc for remove() without creating a new method body.

-------------

PR: https://git.openjdk.org/jdk/pull/12729

From aturbanov at openjdk.org  Mon Feb 27 21:01:32 2023
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Mon, 27 Feb 2023 21:01:32 GMT
Subject: RFR: 8303266: Prefer ArrayList to LinkedList in JImageTask
Message-ID: <NFrcgY-0XTStyKGm1VDX1F6Ww-rBDdAxoOIc4Dg1I8M=.99d9f44b-f1a2-4432-8580-98d21ad57109@github.com>

`LinkedList` is used as a field `jdk.tools.jimage.JImageTask.OptionsValues#jimages`
It's created, filled (with `add`) and then iterated. No removes from the head or something like this. `ArrayList` should be preferred as more efficient and widely used (more chances for JIT) collection.

-------------

Commit messages:
 - [PATCH] Prefer ArrayList to LinkedList in JImageTask

Changes: https://git.openjdk.org/jdk/pull/12760/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12760&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8303266
  Stats: 3 lines in 1 file changed: 0 ins; 1 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/12760.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12760/head:pull/12760

PR: https://git.openjdk.org/jdk/pull/12760

From igraves at openjdk.org  Mon Feb 27 21:08:56 2023
From: igraves at openjdk.org (Ian Graves)
Date: Mon, 27 Feb 2023 21:08:56 GMT
Subject: Integrated: 8293667: Align jlink's --compress option with jmod's
 --compress option
In-Reply-To: <JWevwHuR2vF3k-JRxmTAxfNN6g-EBkgG2N9DHn4fkGY=.f9768dfd-cab4-49a9-83b9-d77a1572e917@github.com>
References: <JWevwHuR2vF3k-JRxmTAxfNN6g-EBkgG2N9DHn4fkGY=.f9768dfd-cab4-49a9-83b9-d77a1572e917@github.com>
Message-ID: <4h6cvcBdB2QQElYoXV-qCq9mlQx9lOi8BZk3rdA69Eg=.c8be015f-6334-4c6d-b09a-39fe1a5f353c@github.com>

On Fri, 9 Dec 2022 21:42:15 GMT, Ian Graves <igraves at openjdk.org> wrote:

> This is an approach to adding a flag to jlink that will allow --compress to take the same types of arguments as jmod, thus bringing the two into alignment. This likely requires a CSR and a discussion on whether we should deprecate or simply remove the original numeric compression arguments.

This pull request has now been integrated.

Changeset: 784f7b14
Author:    Ian Graves <igraves at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/784f7b146264ee8eb382f0cc90514018fc5d16d0
Stats:     150 lines in 6 files changed: 110 ins; 19 del; 21 mod

8293667: Align jlink's --compress option with jmod's --compress option

Reviewed-by: mchung

-------------

PR: https://git.openjdk.org/jdk/pull/11617

From jlaskey at openjdk.org  Mon Feb 27 21:16:02 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Mon, 27 Feb 2023 21:16:02 GMT
Subject: RFR: 8303266: Prefer ArrayList to LinkedList in JImageTask
In-Reply-To: <NFrcgY-0XTStyKGm1VDX1F6Ww-rBDdAxoOIc4Dg1I8M=.99d9f44b-f1a2-4432-8580-98d21ad57109@github.com>
References: <NFrcgY-0XTStyKGm1VDX1F6Ww-rBDdAxoOIc4Dg1I8M=.99d9f44b-f1a2-4432-8580-98d21ad57109@github.com>
Message-ID: <Y5Aa97yJOz02UFr7V7Gh6_o6pUigeSrkrODqBrMad0c=.042b0533-6459-42db-80bd-f314dc9fea0e@github.com>

On Mon, 27 Feb 2023 11:33:38 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> `LinkedList` is used as a field `jdk.tools.jimage.JImageTask.OptionsValues#jimages`
> It's created, filled (with `add`) and then iterated. No removes from the head or something like this. `ArrayList` should be preferred as more efficient and widely used (more chances for JIT) collection.

LGTM. Not sure why he used that but may have started with a linked list hashmap to track duplicate files and the dropped down to linked list. At any rate, should be fine.

-------------

Marked as reviewed by jlaskey (Reviewer).

PR: https://git.openjdk.org/jdk/pull/12760

From dholmes at openjdk.org  Mon Feb 27 21:58:34 2023
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 27 Feb 2023 21:58:34 GMT
Subject: RFR: 8303133: Update ProcessTools.startProcess(...) to exit early
 if process exit before linePredicate is printed. [v2]
In-Reply-To: <iytH_wtutpe_Cnd25gbG8Ww4vE-D6H8ivMfAU5xjhCY=.b5f4d50e-5f83-4877-a283-a0fe47e0d265@github.com>
References: <cuDocKEsnNWZvi2L_E6XBQ_U0T8qnNCIupmsFxaSjEw=.867a6664-21bc-44fb-aa68-9b9a1e8d36d7@github.com>
 <YMRU3NTKiOEw7VS24xhISyijlTyeTeqRFzG-P3Uo3BQ=.7f5772b3-17bb-4985-88b9-8d11acc9392e@github.com>
 <AjOfPfyDCivxwdzxRWR4PUeqs2Q94LPtgwEBPAHQ-sY=.19b76733-2d8a-4f6f-81d4-0e05f08b5347@github.com>
 <iytH_wtutpe_Cnd25gbG8Ww4vE-D6H8ivMfAU5xjhCY=.b5f4d50e-5f83-4877-a283-a0fe47e0d265@github.com>
Message-ID: <neoWMMhcBTYNO_1O49a7G05U5nCbv-Db8XO_Hf5Swxc=.7dc3a3b0-7b8c-4146-a565-1c06689b29d9@github.com>

On Mon, 27 Feb 2023 17:55:40 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> test/lib/jdk/test/lib/process/ProcessTools.java line 224:
>> 
>>> 222:                     if (!p.isAlive()) {
>>> 223:                         latch.countDown();
>>> 224:                         throw new RuntimeException("Started process " + name + " is not alive.");
>> 
>> This seems problematic. The process has terminated but you don't know why - it may have completed normally and produced all the output such that the `await` below would return immediately with `true`, but you are now going to throw an exception. ???
>
> Thanks! You are right, we need to check first if the line has been printed.
> However, there is an interesting question the process can exit before streams are read and the latch is set to zero. The documentation says that linePredicate should detect if the process is warmed-up. So it is not expected that it should exit right after the start.

Yes there remains a race, if the process exits but the streamPumper has not yet had the chance to call `countDown` then we would again throw the exception. Perhaps all we can do is give a little extra time after decting a dead process?

if (!p.isAlive()) {
  if (latch.getCount() > 0) {
    // Give some extra time for the StreamPumper to run after the process completed
   Thread.sleep(1000); 
   if (latch.getCount() > 0) {
    throw new RuntimeException("Started process " + name + " but it terminated without the expected output");
  }
}

-------------

PR: https://git.openjdk.org/jdk/pull/12751

From bpb at openjdk.org  Mon Feb 27 22:05:20 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Mon, 27 Feb 2023 22:05:20 GMT
Subject: RFR: 8298619: java/io/File/GetXSpace.java is failing [v3]
In-Reply-To: <6LnAAIclo5mZZgba4XUSTSc72vyNrBinzUlO9-kJXbU=.fe0c5e94-9e36-4484-b8e7-0f19cb10cb05@github.com>
References: <6LnAAIclo5mZZgba4XUSTSc72vyNrBinzUlO9-kJXbU=.fe0c5e94-9e36-4484-b8e7-0f19cb10cb05@github.com>
Message-ID: <2d5h6HANV8vMQbQnVvsuiYiO_n1IG-2zQuz-facvwK0=.ca21cf4e-5f06-4893-a115-c9adb5310fff@github.com>

> Modify the `Space` instances used for size comparison to be created with total number of bytes derived from the Windows `diskFree` utility instead of Cygwin?s `df`.

Brian Burkhalter 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:

 - 8298619: Change getSpace0() to return a boolean; print warning if total size is estimated instead of exact
 - Merge
 - 8298619: Load GetDiskSpaceInformationW dynamically
 - 8298619: Replace df and diskFree with native calls
 - 8298619: java/io/File/GetXSpace.java is failing

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12397/files
  - new: https://git.openjdk.org/jdk/pull/12397/files/42ad4cea..114857c1

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12397&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12397&range=01-02

  Stats: 75244 lines in 1898 files changed: 35620 ins; 19510 del; 20114 mod
  Patch: https://git.openjdk.org/jdk/pull/12397.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12397/head:pull/12397

PR: https://git.openjdk.org/jdk/pull/12397

From lmesnik at openjdk.org  Mon Feb 27 22:12:22 2023
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Mon, 27 Feb 2023 22:12:22 GMT
Subject: RFR: 8303133: Update ProcessTools.startProcess(...) to exit early
 if process exit before linePredicate is printed. [v4]
In-Reply-To: <cuDocKEsnNWZvi2L_E6XBQ_U0T8qnNCIupmsFxaSjEw=.867a6664-21bc-44fb-aa68-9b9a1e8d36d7@github.com>
References: <cuDocKEsnNWZvi2L_E6XBQ_U0T8qnNCIupmsFxaSjEw=.867a6664-21bc-44fb-aa68-9b9a1e8d36d7@github.com>
Message-ID: <WhrXkOR21gMdOuf0h-qjbsNU3zbyfEKyFfa6hjbcoaM=.7da26bd1-64e0-4b98-9948-3fa5acbd964e@github.com>

> The solution proposed by Stefan K
> 
> The startProcess() might wait forever for the expected line if the process exits (failed to start). It makes sense to just fail earlier in such cases.
> 
> The fix also move
> 'output = new OutputAnalyzer(this.process);'
> in method xrun() to be able to try to print them in waitFor is failed/interrupted.

Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:

  added some extra time to dead process.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12751/files
  - new: https://git.openjdk.org/jdk/pull/12751/files/5b7e3897..02770459

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12751&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12751&range=02-03

  Stats: 6 lines in 1 file changed: 4 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/12751.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12751/head:pull/12751

PR: https://git.openjdk.org/jdk/pull/12751

From dholmes at openjdk.org  Mon Feb 27 22:56:35 2023
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 27 Feb 2023 22:56:35 GMT
Subject: RFR: 8303133: Update ProcessTools.startProcess(...) to exit early
 if process exit before linePredicate is printed. [v4]
In-Reply-To: <WhrXkOR21gMdOuf0h-qjbsNU3zbyfEKyFfa6hjbcoaM=.7da26bd1-64e0-4b98-9948-3fa5acbd964e@github.com>
References: <cuDocKEsnNWZvi2L_E6XBQ_U0T8qnNCIupmsFxaSjEw=.867a6664-21bc-44fb-aa68-9b9a1e8d36d7@github.com>
 <WhrXkOR21gMdOuf0h-qjbsNU3zbyfEKyFfa6hjbcoaM=.7da26bd1-64e0-4b98-9948-3fa5acbd964e@github.com>
Message-ID: <NsODt2vd5lZRGJl3zpXe-EECa6tu5-sc8fo5KL8J4lc=.c416ced5-4f3f-409b-8266-eaece60ff85c@github.com>

On Mon, 27 Feb 2023 22:12:22 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> The solution proposed by Stefan K
>> 
>> The startProcess() might wait forever for the expected line if the process exits (failed to start). It makes sense to just fail earlier in such cases.
>> 
>> The fix also move
>> 'output = new OutputAnalyzer(this.process);'
>> in method xrun() to be able to try to print them in waitFor is failed/interrupted.
>
> Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:
> 
>   added some extra time to dead process.

test/lib/jdk/test/lib/process/ProcessTools.java line 227:

> 225:                         // Give some extra time for the StreamPumper to run after the process completed
> 226:                         Thread.sleep(1000);
> 227:                         if (latch.getCount() > 0) {

Nit: we use > 0 here but != 0 above.

test/lib/jdk/test/lib/process/ProcessTools.java line 228:

> 226:                         Thread.sleep(1000);
> 227:                         if (latch.getCount() > 0) {
> 228:                             throw new RuntimeException("Started process " + name + " is not alive.");

Nit: the message is not very informative - we expect the process to die, the problem is it died before giving the necessary output. Suggestion:
> "Started process " + name + "terminated before producing the expected output"

-------------

PR: https://git.openjdk.org/jdk/pull/12751

From rriggs at openjdk.org  Mon Feb 27 23:02:04 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 27 Feb 2023 23:02:04 GMT
Subject: RFR: 8303266: Prefer ArrayList to LinkedList in JImageTask
In-Reply-To: <NFrcgY-0XTStyKGm1VDX1F6Ww-rBDdAxoOIc4Dg1I8M=.99d9f44b-f1a2-4432-8580-98d21ad57109@github.com>
References: <NFrcgY-0XTStyKGm1VDX1F6Ww-rBDdAxoOIc4Dg1I8M=.99d9f44b-f1a2-4432-8580-98d21ad57109@github.com>
Message-ID: <SRkNnBmskx51DnEokSPJfkixT_BwxPAVNIWEODzMhFU=.ffba06e1-cda9-444f-a3be-b0f12b61b7aa@github.com>

On Mon, 27 Feb 2023 11:33:38 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> `LinkedList` is used as a field `jdk.tools.jimage.JImageTask.OptionsValues#jimages`
> It's created, filled (with `add`) and then iterated. No removes from the head or something like this. `ArrayList` should be preferred as more efficient and widely used (more chances for JIT) collection.

IMHO, there is not enough value in this change to continue the review.  It should be closed without integrating.

-------------

PR: https://git.openjdk.org/jdk/pull/12760

From dholmes at openjdk.org  Mon Feb 27 23:03:08 2023
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 27 Feb 2023 23:03:08 GMT
Subject: RFR: 8303198: System and Runtime.exit() resilience to logging
 errors
In-Reply-To: <rHrPLvyvNcOxOV1HsKVjbg3beRrPxrFa4GF7R4Ry_tQ=.215e28af-60bf-414a-9a13-9c062d98608a@github.com>
References: <L-cEo4rK2rAwdPUdmq0kG57Kl7atYpSKfupA2ZUTZ4E=.7dafb6d1-eb77-436f-b50f-16998af347af@github.com>
 <oXt0im7AfSA3-GpEgTgwiFIruxjnPAG73L97Z0LYeH8=.166aeccc-d299-419f-8feb-06938dae1383@github.com>
 <rHrPLvyvNcOxOV1HsKVjbg3beRrPxrFa4GF7R4Ry_tQ=.215e28af-60bf-414a-9a13-9c062d98608a@github.com>
Message-ID: <N34EJ3kiSqBJmGfUkD_q6XgOWQXX1dpoymE2dhL7Oqg=.23a3c4ee-584e-4297-88ab-b0b09a3b2609@github.com>

On Mon, 27 Feb 2023 16:05:44 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/Shutdown.java line 189:
>> 
>>> 187:             } catch (Throwable throwable2) {
>>> 188:                 // Ignore
>>> 189:             }
>> 
>> The update means that several threads racing to exit may result in more than one message being logged. I don't think that's a big issue but just wanted to make sure that this was deliberate.
>
> Yes, its racy, and intentional, but from a diagnostic view, the developer should know that multiple callers were trying to exit. All but one will hang.  
> Consolidating the code in a single method is cleaner and with fewer interactions between separate code blocks.

I can't tell if the thread identity will be included in the log the message?

I'm not so sure it is useful to allow competing exit calls to all log their intent. I would have kept the logging itself inside the locked region as per the original code.

-------------

PR: https://git.openjdk.org/jdk/pull/12770

From lmesnik at openjdk.org  Mon Feb 27 23:11:27 2023
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Mon, 27 Feb 2023 23:11:27 GMT
Subject: RFR: 8303133: Update ProcessTools.startProcess(...) to exit early
 if process exit before linePredicate is printed. [v5]
In-Reply-To: <cuDocKEsnNWZvi2L_E6XBQ_U0T8qnNCIupmsFxaSjEw=.867a6664-21bc-44fb-aa68-9b9a1e8d36d7@github.com>
References: <cuDocKEsnNWZvi2L_E6XBQ_U0T8qnNCIupmsFxaSjEw=.867a6664-21bc-44fb-aa68-9b9a1e8d36d7@github.com>
Message-ID: <hlXbi3Q4oMDDZqLqbALqBa2NWocRhWR3wVqXclqDf2I=.3f588a06-e52e-46b3-85ac-a863487557b4@github.com>

> The solution proposed by Stefan K
> 
> The startProcess() might wait forever for the expected line if the process exits (failed to start). It makes sense to just fail earlier in such cases.
> 
> The fix also move
> 'output = new OutputAnalyzer(this.process);'
> in method xrun() to be able to try to print them in waitFor is failed/interrupted.

Leonid Mesnik has updated the pull request incrementally with two additional commits since the last revision:

 - latch != updated
 - message improved

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12751/files
  - new: https://git.openjdk.org/jdk/pull/12751/files/02770459..5ecb0047

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12751&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12751&range=03-04

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/12751.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12751/head:pull/12751

PR: https://git.openjdk.org/jdk/pull/12751

From lmesnik at openjdk.org  Mon Feb 27 23:11:40 2023
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Mon, 27 Feb 2023 23:11:40 GMT
Subject: RFR: 8303133: Update ProcessTools.startProcess(...) to exit early
 if process exit before linePredicate is printed. [v4]
In-Reply-To: <NsODt2vd5lZRGJl3zpXe-EECa6tu5-sc8fo5KL8J4lc=.c416ced5-4f3f-409b-8266-eaece60ff85c@github.com>
References: <cuDocKEsnNWZvi2L_E6XBQ_U0T8qnNCIupmsFxaSjEw=.867a6664-21bc-44fb-aa68-9b9a1e8d36d7@github.com>
 <WhrXkOR21gMdOuf0h-qjbsNU3zbyfEKyFfa6hjbcoaM=.7da26bd1-64e0-4b98-9948-3fa5acbd964e@github.com>
 <NsODt2vd5lZRGJl3zpXe-EECa6tu5-sc8fo5KL8J4lc=.c416ced5-4f3f-409b-8266-eaece60ff85c@github.com>
Message-ID: <p2dlS5-AS5hmktqz1zZ7J-UoIdXy6lD6063R43LeFX0=.73d12749-cc59-4485-8d56-6da4e0e756c3@github.com>

On Mon, 27 Feb 2023 22:48:46 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   added some extra time to dead process.
>
> test/lib/jdk/test/lib/process/ProcessTools.java line 227:
> 
>> 225:                         // Give some extra time for the StreamPumper to run after the process completed
>> 226:                         Thread.sleep(1000);
>> 227:                         if (latch.getCount() > 0) {
> 
> Nit: we use > 0 here but != 0 above.

let use > in all places

-------------

PR: https://git.openjdk.org/jdk/pull/12751

From rriggs at openjdk.org  Mon Feb 27 23:23:07 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 27 Feb 2023 23:23:07 GMT
Subject: RFR: 8303198: System and Runtime.exit() resilience to logging
 errors
In-Reply-To: <N34EJ3kiSqBJmGfUkD_q6XgOWQXX1dpoymE2dhL7Oqg=.23a3c4ee-584e-4297-88ab-b0b09a3b2609@github.com>
References: <L-cEo4rK2rAwdPUdmq0kG57Kl7atYpSKfupA2ZUTZ4E=.7dafb6d1-eb77-436f-b50f-16998af347af@github.com>
 <oXt0im7AfSA3-GpEgTgwiFIruxjnPAG73L97Z0LYeH8=.166aeccc-d299-419f-8feb-06938dae1383@github.com>
 <rHrPLvyvNcOxOV1HsKVjbg3beRrPxrFa4GF7R4Ry_tQ=.215e28af-60bf-414a-9a13-9c062d98608a@github.com>
 <N34EJ3kiSqBJmGfUkD_q6XgOWQXX1dpoymE2dhL7Oqg=.23a3c4ee-584e-4297-88ab-b0b09a3b2609@github.com>
Message-ID: <AjFM7Sr5prjExOZXr8btOHIZUtXzTSFSxJZjt2o6Li0=.b040ecaa-a1f1-45f9-9497-ffea36730530@github.com>

On Mon, 27 Feb 2023 23:00:45 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Yes, its racy, and intentional, but from a diagnostic view, the developer should know that multiple callers were trying to exit. All but one will hang.  
>> Consolidating the code in a single method is cleaner and with fewer interactions between separate code blocks.
>
> I can't tell if the thread identity will be included in the log the message?
> 
> I'm not so sure it is useful to allow competing exit calls to all log their intent. I would have kept the logging itself inside the locked region as per the original code.

The main diagnostic is the logged message with the stack trace. The println version is present as a diagnostic if logging is mis-configured.

If the developer is looking to mitigate calls to Runtime.Exit, then they are advised to check all paths and will appreciate not having to wait for a different thread to win the race.

-------------

PR: https://git.openjdk.org/jdk/pull/12770

From jlu at openjdk.org  Tue Feb 28 00:15:05 2023
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 28 Feb 2023 00:15:05 GMT
Subject: RFR: 8303232: java.util.Date.parse(String) and java.util.Date(String)
 don't declare thrown IllegalArgumentException
Message-ID: <6S1UF7DvwvaGLJJhkX8DlBiV57SImGBxyDMLYohzfwU=.1937701d-8be4-4a1f-85e8-c6ad19ccc72a@github.com>

The method `java.util.Date.parse(String)` and as a result, constructor `java.util.Date(String)` throw an `IllegalArgumentException`. This exception is not properly referenced in the javadoc, and this PR simply adds the throws javadoc tag to make it apparent.

-------------

Commit messages:
 - Add @throws for Date(String), Date.parse(String)

Changes: https://git.openjdk.org/jdk/pull/12779/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12779&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8303232
  Stats: 5 lines in 1 file changed: 4 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/12779.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12779/head:pull/12779

PR: https://git.openjdk.org/jdk/pull/12779

From jpai at openjdk.org  Tue Feb 28 01:32:02 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 28 Feb 2023 01:32:02 GMT
Subject: RFR: 8303232: java.util.Date.parse(String) and
 java.util.Date(String) don't declare thrown IllegalArgumentException
In-Reply-To: <6S1UF7DvwvaGLJJhkX8DlBiV57SImGBxyDMLYohzfwU=.1937701d-8be4-4a1f-85e8-c6ad19ccc72a@github.com>
References: <6S1UF7DvwvaGLJJhkX8DlBiV57SImGBxyDMLYohzfwU=.1937701d-8be4-4a1f-85e8-c6ad19ccc72a@github.com>
Message-ID: <079Fm8FPQgnR50HhQOlkBaGPDDfH1R2FIEesuXFzeiM=.44dfd116-c592-4ef5-b98a-fb3d6cb8ceed@github.com>

On Tue, 28 Feb 2023 00:07:05 GMT, Justin Lu <jlu at openjdk.org> wrote:

> The method `java.util.Date.parse(String)` and as a result, constructor `java.util.Date(String)` throw an `IllegalArgumentException`. This exception is not properly referenced in the javadoc, and this PR simply adds the throws javadoc tag to make it apparent.

Hello Justin, this doc-only change looks good to me. In the past, we have created CSR for changes like these where the javadoc was updated to clarify the existing behaviour. I think this too will need one.

-------------

Marked as reviewed by jpai (Reviewer).

PR: https://git.openjdk.org/jdk/pull/12779

From dholmes at openjdk.org  Tue Feb 28 02:45:06 2023
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 28 Feb 2023 02:45:06 GMT
Subject: RFR: 8303133: Update ProcessTools.startProcess(...) to exit early
 if process exit before linePredicate is printed. [v5]
In-Reply-To: <hlXbi3Q4oMDDZqLqbALqBa2NWocRhWR3wVqXclqDf2I=.3f588a06-e52e-46b3-85ac-a863487557b4@github.com>
References: <cuDocKEsnNWZvi2L_E6XBQ_U0T8qnNCIupmsFxaSjEw=.867a6664-21bc-44fb-aa68-9b9a1e8d36d7@github.com>
 <hlXbi3Q4oMDDZqLqbALqBa2NWocRhWR3wVqXclqDf2I=.3f588a06-e52e-46b3-85ac-a863487557b4@github.com>
Message-ID: <mWUdXQ-xdLuppbPxuKfumbKie-ZjLwRZzStPSRu11r4=.9b243eaa-cff6-4949-a74a-37f4a0335baa@github.com>

On Mon, 27 Feb 2023 23:11:27 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> The solution proposed by Stefan K
>> 
>> The startProcess() might wait forever for the expected line if the process exits (failed to start). It makes sense to just fail earlier in such cases.
>> 
>> The fix also move
>> 'output = new OutputAnalyzer(this.process);'
>> in method xrun() to be able to try to print them in waitFor is failed/interrupted.
>
> Leonid Mesnik has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - latch != updated
>  - message improved

This seems okay to me now. Thanks.

-------------

Marked as reviewed by dholmes (Reviewer).

PR: https://git.openjdk.org/jdk/pull/12751

From dholmes at openjdk.org  Tue Feb 28 02:48:03 2023
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 28 Feb 2023 02:48:03 GMT
Subject: RFR: 8303198: System and Runtime.exit() resilience to logging
 errors
In-Reply-To: <AjFM7Sr5prjExOZXr8btOHIZUtXzTSFSxJZjt2o6Li0=.b040ecaa-a1f1-45f9-9497-ffea36730530@github.com>
References: <L-cEo4rK2rAwdPUdmq0kG57Kl7atYpSKfupA2ZUTZ4E=.7dafb6d1-eb77-436f-b50f-16998af347af@github.com>
 <oXt0im7AfSA3-GpEgTgwiFIruxjnPAG73L97Z0LYeH8=.166aeccc-d299-419f-8feb-06938dae1383@github.com>
 <rHrPLvyvNcOxOV1HsKVjbg3beRrPxrFa4GF7R4Ry_tQ=.215e28af-60bf-414a-9a13-9c062d98608a@github.com>
 <N34EJ3kiSqBJmGfUkD_q6XgOWQXX1dpoymE2dhL7Oqg=.23a3c4ee-584e-4297-88ab-b0b09a3b2609@github.com>
 <AjFM7Sr5prjExOZXr8btOHIZUtXzTSFSxJZjt2o6Li0=.b040ecaa-a1f1-45f9-9497-ffea36730530@github.com>
Message-ID: <pOA8BdTlG7co7FF8u3gjWUPjAQZT7Kkg7nz7m_LK3Vk=.cb497b97-e55c-4a15-9dc2-15fb94241bde@github.com>

On Mon, 27 Feb 2023 23:20:07 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> I can't tell if the thread identity will be included in the log the message?
>> 
>> I'm not so sure it is useful to allow competing exit calls to all log their intent. I would have kept the logging itself inside the locked region as per the original code.
>
> The main diagnostic is the logged message with the stack trace. The println version is present as a diagnostic if logging is mis-configured.
> 
> If the developer is looking to mitigate calls to Runtime.Exit, then they are advised to check all paths and will appreciate not having to wait for a different thread to win the race.

But does that logging include the thread identity? If multiple threads can race to exit and all log, then the developer/user needs to know which logging came from which thread.

-------------

PR: https://git.openjdk.org/jdk/pull/12770

From lmesnik at openjdk.org  Tue Feb 28 02:51:15 2023
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Tue, 28 Feb 2023 02:51:15 GMT
Subject: RFR: 8303133: Update ProcessTools.startProcess(...) to exit early
 if process exit before linePredicate is printed. [v5]
In-Reply-To: <mWUdXQ-xdLuppbPxuKfumbKie-ZjLwRZzStPSRu11r4=.9b243eaa-cff6-4949-a74a-37f4a0335baa@github.com>
References: <cuDocKEsnNWZvi2L_E6XBQ_U0T8qnNCIupmsFxaSjEw=.867a6664-21bc-44fb-aa68-9b9a1e8d36d7@github.com>
 <hlXbi3Q4oMDDZqLqbALqBa2NWocRhWR3wVqXclqDf2I=.3f588a06-e52e-46b3-85ac-a863487557b4@github.com>
 <mWUdXQ-xdLuppbPxuKfumbKie-ZjLwRZzStPSRu11r4=.9b243eaa-cff6-4949-a74a-37f4a0335baa@github.com>
Message-ID: <nHNjOj4DHuuVRjar-i2-C3Ydv5mYfST5uEDAgoNBWQw=.6ae14152-76d5-40a1-bc62-65591966ce0e@github.com>

On Tue, 28 Feb 2023 02:42:33 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Leonid Mesnik has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - latch != updated
>>  - message improved
>
> This seems okay to me now. Thanks.

@dholmes-ora, Thank you for your comments.

-------------

PR: https://git.openjdk.org/jdk/pull/12751

From mdoerr at openjdk.org  Tue Feb 28 02:56:02 2023
From: mdoerr at openjdk.org (Martin Doerr)
Date: Tue, 28 Feb 2023 02:56:02 GMT
Subject: RFR: 8303040: linux PPC64le: Implementation of Foreign Function &
 Memory API (Preview) [v3]
In-Reply-To: <yBDR_4bt2lbdsI_zjxuCMPLOvqKpGi31UcfXXY3Ho98=.c6132aa7-7a4b-4304-bae2-1b950df17fda@github.com>
References: <Yuxy6FrsDAN79ya8w8UIkvytGr25zGllDPtPJ1QbGwc=.182664b2-6d8c-497e-a4ae-95e0ad007cf9@github.com>
 <8b3vVrV22RuhdRoRYacXV0ZeghFGgKkC8S_z-iMrzAQ=.dd84b743-8b51-4281-8f5f-f9eff6207bc7@github.com>
 <yBDR_4bt2lbdsI_zjxuCMPLOvqKpGi31UcfXXY3Ho98=.c6132aa7-7a4b-4304-bae2-1b950df17fda@github.com>
Message-ID: <ENLX70-M4AuDLEPyUCu-xX1MOLLvJlhXty07Dw1NwmU=.a12be47f-458c-42f8-a657-ad18097c907f@github.com>

On Mon, 27 Feb 2023 08:49:18 GMT, Erik ?sterlund <eosterlund at openjdk.org> wrote:

> I don?t think we want this to be on by default on platforms where StoreLoad fences don't cause substantial global overheads. The benefit on such platforms is rather low, and needing the last couple of nanoseconds of transition speed, seems to not be a normal use case that default settings should optimize for. Conversely, the global synchronization can be rather intrusive, especially when it involves handshakes with N threads, and you need to perform global synchronization across the entire machine, for each thread poked. I would be much more afraid of that issue out of the box, than I would be afraid of a couple of nanoseconds slower native transitions.

Hi Erik, StoreLoad fences cause substantial overhead on any multi-socket system including x86_64. The benefit may be small on single-socket systems, but can the VM distinguish? We are currently looking for benchmarks which show a negative effect of enabling it. Seems like the SPEC benchmarks don't care about it. Note that we typically use only one membarrier syscall when we handshake all threads. If you know any workload which suffers, would be great to know. David is currently also checking benchmarks. We should discuss further details in https://github.com/openjdk/jdk/pull/12753.

-------------

PR: https://git.openjdk.org/jdk/pull/12708

From duke at openjdk.org  Tue Feb 28 03:36:14 2023
From: duke at openjdk.org (Archie L. Cobbs)
Date: Tue, 28 Feb 2023 03:36:14 GMT
Subject: Integrated: 8026369: javac potentially ambiguous overload warning
 needs an improved scheme
In-Reply-To: <IMxp3iCK--jYJ5Ia04i6QPYfnCHQobVcsmlI5aJXdqc=.892abcb8-7f2a-4fe9-aea2-1b1d41098a6d@github.com>
References: <IMxp3iCK--jYJ5Ia04i6QPYfnCHQobVcsmlI5aJXdqc=.892abcb8-7f2a-4fe9-aea2-1b1d41098a6d@github.com>
Message-ID: <B-0L2Tb7KAyVr1ZnWvPRvSDxzntwoxFY-bY5ta_ecFs=.638328a4-0633-4f84-9126-1bd038250511@github.com>

On Sun, 19 Feb 2023 23:52:52 GMT, Archie L. Cobbs <duke at openjdk.org> wrote:

> This bug relates to the "potentially ambiguous overload" warning which is enabled by `-Xlint:overloads`.
> 
> The warning detects certain ambiguities that can cause problems for lambdas. For example, consider the interface `Spliterator.OfInt`, which declares these two methods:
> 
> void forEachRemaining(Consumer<? super Integer> action);
> void forEachRemaining(IntConsumer action);
> 
> Both methods have the same name, same number of parameters, and take a lambda with the same "shape" in the same argument position. This causes an ambiguity in any code that wants to do this:
> 
>     spliterator.forEachRemaining(x -> { ... });
> 
> That code won't compile; instead, you'll get this error:
> 
> Ambiguity.java:4: error: reference to forEachRemaining is ambiguous
>         spliterator.forEachRemaining(x -> { });
>                    ^
>   both method forEachRemaining(IntConsumer) in OfInt and method forEachRemaining(Consumer<? super Integer>) in OfInt match
> 
> 
> The problem reported by the bug is that the warning fails to detect ambiguities which are created purely by inheritance, for example:
> 
> interface ConsumerOfInteger {
>     void foo(Consumer<Integer> c);
> }
> 
> interface IntegerConsumer {
>     void foo(IntConsumer c);
> }
> 
> // We should get a warning here...
> interface Test extends ConsumerOfInteger, IntegerConsumer {
> }
> 
> 
> The cause of the bug is that ambiguities are detected on a per-method basis, by checking whether a method is part of an ambiguity pair when we visit that method. So if the methods in an ambiguity pair are inherited from two distinct supertypes, we'll miss the ambiguity.
> 
> To fix the problem, we need to look for ambiguities on a per-class level, checking all pairs of methods. However, it's not that simple - we only want to "blame" a class when that class itself, and not some supertype, is responsible for creating the ambiguity. For example, any interface extending `Spliterator.OfInt` will automatically inherit the two ambiguities mentioned above, but these are not the interface's fault so to speak so no warning should be generated. Making things more complicated is the fact that methods can be overridden and declared in generic classes so they only conflict in some subtypes, etc.
> 
> So we generate the warning when there are two methods m1 and m2 in a class C such that:
> 
> * m1 and m2 consitiute a "potentially ambiguous overload" (using the same definition as before)
> * There is no direct supertype T of C such that m1 and m2, or some methods they override, both exist in T and constitute a "potentially ambiguous overload" as members of T
> * We haven't already generated a warning for either m1 or m2 in class C
> 
> If either method is declared in C, we locate the warning there, but when both methods are inherited, there's no method declaration to point at so the warning is instead located at the class declaration.
> 
> I noticed a couple of other minor bugs; these are also being fixed here:
> 
> (1) For inherited methods, the method signatures were being reported as they are declared, rather than in the context of the class being visited. As a result, when a methods is inherited from a generic supertype, the ambiguity is less clear. Here's an example:
> 
> interface Upper<T> {
>     void foo(T c);
> }
> 
> interface Lower extends Upper<IntConsumer> {
>     void foo(Consumer<Integer> c);
> }
> 
> Currently, the error is reported as:
> 
> warning: [overloads] foo(Consumer<Integer>) in Lower is potentially ambiguous with foo(T) in Upper
> 
> Reporting the method signatures in the context of the class being visited makes the ambiguity clearer:
> 
> warning: [overloads] foo(Consumer<Integer>) in Lower is potentially ambiguous with foo(IntConsumer) in Upper
> 
> 
> (2) When a method is identified as part of an ambiguous pair, we were setting a `POTENTIALLY_AMBIGUOUS` flag on it. This caused it to be forever excluded from future warnings. For methods that are declared in the class we're visiting, this makes sense, but it doesn't make sense for inherited methods, because it disqualifies them from participating in the analysis of any other class that also inherits them.
> 
> As a result, for a class like the one below, the compiler was only generating one warning instead of three:
> 
> public interface SuperIface {
>     void foo(Consumer<Integer> c);
> }
> 
> public interface I1 extends SuperIface { 
>     void foo(IntConsumer c);        // warning was generated here
> }   
> 
> public interface I2 extends SuperIface { 
>     void foo(IntConsumer c);        // no warning was generated here
> }   
> 
> public interface I3 extends SuperIface { 
>     void foo(IntConsumer c);        // no warning was generated here
> }   
> 
> 
> With this patch the `POTENTIALLY_AMBIGUOUS` flag is no longer needed. I wasn't sure whether to renumber all the subsequent flags, or just leave an empty placeholder, so I chose the latter.
> 
> Finally, this fix uncovers new warnings in `java.base` and `java.desktop`, so these are now suppressed in the patch.

This pull request has now been integrated.

Changeset: 1e3c9fd6
Author:    Archie L. Cobbs <archie.cobbs at gmail.com>
Committer: Vicente Romero <vromero at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/1e3c9fd67efd8428f702c7a3e26ac2b60e0fe618
Stats:     399 lines in 16 files changed: 319 ins; 37 del; 43 mod

8026369: javac potentially ambiguous overload warning needs an improved scheme

Reviewed-by: vromero

-------------

PR: https://git.openjdk.org/jdk/pull/12645

From thartmann at openjdk.org  Tue Feb 28 06:59:06 2023
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Tue, 28 Feb 2023 06:59:06 GMT
Subject: RFR: JDK-8302040: Port fdlibm sqrt to Java [v5]
In-Reply-To: <ydzE4UeDk8qDeT_rwe6YkxniMdBiSMSuteVLJOTEVn8=.5a15a4a5-1e65-4a4b-871d-3ff010d7fa12@github.com>
References: <rjVM2lWPdsvPcfLF3oNShP-cSN8-P-i16ikUC3sTgIg=.1d4f470d-2ac9-4394-b55e-099affce763f@github.com>
 <ydzE4UeDk8qDeT_rwe6YkxniMdBiSMSuteVLJOTEVn8=.5a15a4a5-1e65-4a4b-871d-3ff010d7fa12@github.com>
Message-ID: <HaEj8OXpu8xpU1w7d7NO8GOJs7QSy-HcGdC7Vg6192A=.d2ee5eee-fd7c-4f5c-a0a8-795c1cb61804@github.com>

On Mon, 27 Feb 2023 18:26:51 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> The wheel of FDLIBM porting turns a notch and sqrt comes into play.
>> 
>> While the sqrt operation usually has a hardware implementation that is intrinsified, for completeness a software implementation should be available as well.
>
> Joe Darcy 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:
> 
>  - Enable intrinsic for StrictMath.sqrt; thanks to Tobias Hartmann for assistance with the HotSpot updates.
>  - Merge branch 'master' into JDK-8302040
>  - Implement review feedback.
>  - Add one one unsigned shift comment.
>  - Respond to review feedback.
>  - JDK-8302040: Port fdlibm sqrt to Java

Hotspot changes look good to me.

-------------

Marked as reviewed by thartmann (Reviewer).

PR: https://git.openjdk.org/jdk/pull/12736

From tvaleev at openjdk.org  Tue Feb 28 07:48:09 2023
From: tvaleev at openjdk.org (Tagir F. Valeev)
Date: Tue, 28 Feb 2023 07:48:09 GMT
Subject: RFR: JDK-8302323 Add repeat methods to StringBuilder/StringBuffer
 [v3]
In-Reply-To: <USKIo5-pKuGZ9zfcj1dvmw98vqZBKv3q0sIl9ny1bdM=.54283a18-6f09-4fa1-801a-2298e69b750d@github.com>
References: <ygMjzllqk27Dss1q2oRgcNvK_GJdbFVweVHTvF7zpwY=.06d27701-6b42-4663-958e-f8aca9bc2bc5@github.com>
 <USKIo5-pKuGZ9zfcj1dvmw98vqZBKv3q0sIl9ny1bdM=.54283a18-6f09-4fa1-801a-2298e69b750d@github.com>
Message-ID: <QKaOV1nP_VHkxb2_D3gSsjGDvipvpsXsk966A9ArB44=.8fdc237c-0eee-4b50-a0ce-b7ee8d73131f@github.com>

On Mon, 27 Feb 2023 13:30:47 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> Add the ability to repeatedly append char and CharSequence data to StringBuilder/StringBuffer.
>
> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Optimize for empty CharSequence

src/java.base/share/classes/java/lang/AbstractStringBuilder.java line 1903:

> 1901:             throw new OutOfMemoryError("Required length exceeds implementation limit");
> 1902:         }
> 1903:         int total = count * length;

We may avoid division if we use the long type:


long totalLong = ((long) count) * length;
if (totalLong > Integer.MAX_VALUE - offset) {
    throw new OutOfMemoryError("Required length exceeds implementation limit");
}
int total = (int) totalLong;


Should be faster.

-------------

PR: https://git.openjdk.org/jdk/pull/12728

From tvaleev at openjdk.org  Tue Feb 28 07:48:10 2023
From: tvaleev at openjdk.org (Tagir F. Valeev)
Date: Tue, 28 Feb 2023 07:48:10 GMT
Subject: RFR: JDK-8302323 Add repeat methods to StringBuilder/StringBuffer
 [v2]
In-Reply-To: <B473It6XpyE7ngqQY7MuwHgfRthvh3waZBoA1EShSfY=.97416aba-95d9-4abe-95d3-b41f8f9ecafb@github.com>
References: <ygMjzllqk27Dss1q2oRgcNvK_GJdbFVweVHTvF7zpwY=.06d27701-6b42-4663-958e-f8aca9bc2bc5@github.com>
 <93WJpJLHppFi0Zk0rXLYsJzP14Hp-8dE80OawQ8vCp0=.dd22af95-bbc5-4f77-871e-3738daf6b379@github.com>
 <8wOeJl30Md95Y-nrpWMVZEr3PAi8KwsQjjkKUybEMOE=.7f62f603-cbc8-44d1-ad9d-6a8693a21b3c@github.com>
 <B473It6XpyE7ngqQY7MuwHgfRthvh3waZBoA1EShSfY=.97416aba-95d9-4abe-95d3-b41f8f9ecafb@github.com>
Message-ID: <8mvMgUUDpakHB9axNcdhqXpukNrfal8uwTt0P99my9A=.6e0c7eb9-d522-4288-8757-465ff6db77f6@github.com>

On Mon, 27 Feb 2023 13:20:48 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/AbstractStringBuilder.java line 1903:
>> 
>>> 1901:         int total = count * length;
>>> 1902:         int limit = offset + total;
>>> 1903:         ensureCapacityInternal(limit);
>> 
>> If I understand correctly, this may cause double reallocation, if inflation is necessary (string to spend is utf16 while current coder is latin1). Can this be optimized, at least for String/ASB inputs? Sorry if I'm missing something.
>
> Inflation of a buffer can only happen once. Adding the first copy (append) causing expansion (reallocatio ) and then expanding again to handle the remaining copies is something that happens frequently. Better to expand once for all cases and take the one time hit for transition from Latin1 to UTF16. Make sense?

I see. Well it's possible to create `ensureCapacityAndCoderInternal(capacity, coder)`, which handles both at once. It can be useful in other places as well. Probably this should be considered as a separate enhancement, outside of this PR.

-------------

PR: https://git.openjdk.org/jdk/pull/12728

From duke at openjdk.org  Tue Feb 28 07:49:17 2023
From: duke at openjdk.org (Madjosz)
Date: Tue, 28 Feb 2023 07:49:17 GMT
Subject: RFR: 8302983: ZoneRulesProvider.registerProvider() twice will
 remove provider [v4]
In-Reply-To: <AAfM5rBLeq2B3ttHBX_7kw0_rjfIVPSdcEL23HiOhVs=.b17c2586-b0bc-46ad-9501-0cf8363f82b9@github.com>
References: <AAfM5rBLeq2B3ttHBX_7kw0_rjfIVPSdcEL23HiOhVs=.b17c2586-b0bc-46ad-9501-0cf8363f82b9@github.com>
Message-ID: <32bmWmdJSojCpNplpArpbXwn6LD2qHIZSZfOccJKjC4=.9d60aeba-8ae5-40c6-ac78-241ef4002d1a@github.com>

> Fixes JDK-8302983 (and duplicate JDK-8302898)

Madjosz has updated the pull request incrementally with one additional commit since the last revision:

  whitespace, remove stream()

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12690/files
  - new: https://git.openjdk.org/jdk/pull/12690/files/1bcf7bd8..fa728668

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12690&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12690&range=02-03

  Stats: 3 lines in 1 file changed: 0 ins; 1 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/12690.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12690/head:pull/12690

PR: https://git.openjdk.org/jdk/pull/12690

From alanb at openjdk.org  Tue Feb 28 08:27:05 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 28 Feb 2023 08:27:05 GMT
Subject: RFR: 8303232: java.util.Date.parse(String) and
 java.util.Date(String) don't declare thrown IllegalArgumentException
In-Reply-To: <6S1UF7DvwvaGLJJhkX8DlBiV57SImGBxyDMLYohzfwU=.1937701d-8be4-4a1f-85e8-c6ad19ccc72a@github.com>
References: <6S1UF7DvwvaGLJJhkX8DlBiV57SImGBxyDMLYohzfwU=.1937701d-8be4-4a1f-85e8-c6ad19ccc72a@github.com>
Message-ID: <OVwxwDSRBx5RLMAza-stSPWPQWwEh4Os7KdnV7Q6Xp4=.b2e5661e-e727-40b2-ac27-26379f4ef0aa@github.com>

On Tue, 28 Feb 2023 00:07:05 GMT, Justin Lu <jlu at openjdk.org> wrote:

> The method `java.util.Date.parse(String)` and as a result, constructor `java.util.Date(String)` throw an `IllegalArgumentException`. This exception is not properly referenced in the javadoc, and this PR simply adds the throws javadoc tag to make it apparent.

The changes adds a new testable assertion to the Date(String) constructor so it will need a CSR. For the parse method then it's mostly a doc update as the method description already documents that it throws IAE, it's just didn't declare with @throws for some reason.

-------------

PR: https://git.openjdk.org/jdk/pull/12779

From tvaleev at openjdk.org  Tue Feb 28 09:08:08 2023
From: tvaleev at openjdk.org (Tagir F. Valeev)
Date: Tue, 28 Feb 2023 09:08:08 GMT
Subject: RFR: JDK-8302323 Add repeat methods to StringBuilder/StringBuffer
 [v3]
In-Reply-To: <USKIo5-pKuGZ9zfcj1dvmw98vqZBKv3q0sIl9ny1bdM=.54283a18-6f09-4fa1-801a-2298e69b750d@github.com>
References: <ygMjzllqk27Dss1q2oRgcNvK_GJdbFVweVHTvF7zpwY=.06d27701-6b42-4663-958e-f8aca9bc2bc5@github.com>
 <USKIo5-pKuGZ9zfcj1dvmw98vqZBKv3q0sIl9ny1bdM=.54283a18-6f09-4fa1-801a-2298e69b750d@github.com>
Message-ID: <BBOOKmlaC3alsp0DkupwaVnVRWlfBuMv_eZf8p5Fh4o=.c9da6e7f-16b3-4251-93e3-0d339e1c6cca@github.com>

On Mon, 27 Feb 2023 13:30:47 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> Add the ability to repeatedly append char and CharSequence data to StringBuilder/StringBuffer.
>
> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Optimize for empty CharSequence

src/java.base/share/classes/java/lang/AbstractStringBuilder.java line 1879:

> 1877:      * @since 21
> 1878:      * @throws IllegalArgumentException  if {@code count} is less than zero
> 1879:      * @throws IndexOutOfBoundsException  if the result overflows the buffer

Can `IndexOutOfBoundsException` be really thrown? We don't have any index here. From the implementation I see that only `OutOfMemoryError` and `IllegalArgumentException` can be thrown.

Also, I see a small descrepancy between messages in this method and `String.repeat`. The latter has:


     * @throws  IllegalArgumentException if the {@code count} is
     *          negative.
     *
     * @since 11
     */
    public String repeat(int count) {
        if (count < 0) {
            throw new IllegalArgumentException("count is negative: " + count);
        }


Probably it's better to reuse the same wording ("is negative" instead of "is less than zero") for consistency?

-------------

PR: https://git.openjdk.org/jdk/pull/12728

From jhendrikx at openjdk.org  Tue Feb 28 09:08:11 2023
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Tue, 28 Feb 2023 09:08:11 GMT
Subject: RFR: JDK-8302323 Add repeat methods to StringBuilder/StringBuffer
 [v3]
In-Reply-To: <QKaOV1nP_VHkxb2_D3gSsjGDvipvpsXsk966A9ArB44=.8fdc237c-0eee-4b50-a0ce-b7ee8d73131f@github.com>
References: <ygMjzllqk27Dss1q2oRgcNvK_GJdbFVweVHTvF7zpwY=.06d27701-6b42-4663-958e-f8aca9bc2bc5@github.com>
 <USKIo5-pKuGZ9zfcj1dvmw98vqZBKv3q0sIl9ny1bdM=.54283a18-6f09-4fa1-801a-2298e69b750d@github.com>
 <QKaOV1nP_VHkxb2_D3gSsjGDvipvpsXsk966A9ArB44=.8fdc237c-0eee-4b50-a0ce-b7ee8d73131f@github.com>
Message-ID: <LLfaL_h1m-du72iDyOc8rk0GXK7O6M99GEZZlXPffxU=.c9891c50-ceda-4414-b5fb-e38f2945f209@github.com>

On Tue, 28 Feb 2023 07:43:13 GMT, Tagir F. Valeev <tvaleev at openjdk.org> wrote:

>> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Optimize for empty CharSequence
>
> src/java.base/share/classes/java/lang/AbstractStringBuilder.java line 1903:
> 
>> 1901:             throw new OutOfMemoryError("Required length exceeds implementation limit");
>> 1902:         }
>> 1903:         int total = count * length;
> 
> We may avoid division if we use the long type:
> 
> 
> long totalLong = ((long) count) * length;
> if (totalLong > Integer.MAX_VALUE - offset) {
>     throw new OutOfMemoryError("Required length exceeds implementation limit");
> }
> int total = (int) totalLong;
> 
> 
> Should be faster.

I'm a bit surprised this (and the original code) is throwing `OutOfMemoryError` when running into the max array size. It is not truly an out of memory error, but being an `Error`, it would evade standard catch `Exception` blocks.  I would think this is more of an `IllegalStateException` or perhaps something array specific.

`OutOfMemoryError` is documented pretty specifically that an object allocation failed after exhaustive GC, but no allocation or GC happened:

>Thrown when the Java Virtual Machine cannot allocate an object because it is out of memory, and no more memory could be made available by the garbage collector.

... which is not happening here at all. This leads me to believe the error is not used correctly here.

Other reasons I find it surprising: `StringBuilder` is not documented to throw this anywhere, it seems to just leak through from various methods implemented by `AbstractStringBuilder`.

-------------

PR: https://git.openjdk.org/jdk/pull/12728

From duke at openjdk.org  Tue Feb 28 09:11:19 2023
From: duke at openjdk.org (ExE Boss)
Date: Tue, 28 Feb 2023 09:11:19 GMT
Subject: RFR: JDK-8302666: Replace CHM with VarHandle in ForeachOrderedTask
 [v4]
In-Reply-To: <rkiS971vfW6rzjSOY16ReMHJbA-yf7YzPMF6xnkjjG8=.89606151-5614-4714-98c6-c65adfb79514@github.com>
References: <HAgE8xmpZT_2-b5ZDr8TgJNgjhVb3D4ZS3sQqA7c6Mo=.389fa590-681c-44a9-9823-8f70a6129797@github.com>
 <rkiS971vfW6rzjSOY16ReMHJbA-yf7YzPMF6xnkjjG8=.89606151-5614-4714-98c6-c65adfb79514@github.com>
Message-ID: <srz55riYaEYkSOblDe_7bYJ1SCiuopS9C2Cb9sH0Yk8=.c6fe3708-421b-4a67-9720-b65405ec38b1@github.com>

On Mon, 27 Feb 2023 09:14:56 GMT, Viktor Klang <duke at openjdk.org> wrote:

>> I noticed when looking at the code that there was no real need to use a CHM to perform the tracking of activation in an ordered fashion on ForEachOrderedTask, but instead a VarHandle can be used, reducing allocations and indirection.
>
> Viktor Klang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits:
> 
>  - Updating copyright header of ForEachOps.java and removing unnecessary suppression of an unchecked cast.
>  - Write the initial value of the next reference without using the VarHandle
>  - JDK-8302666: Replace CHM with VarHandle in ForeachOrderedTask

src/java.base/share/classes/java/util/stream/ForEachOps.java line 513:

> 511:             // of right subtree (if any, which can be this task's right sibling)
> 512:             //
> 513:             var leftDescendant = (ForEachOrderedTask<S, T>)NEXT.getAndSet(this, null);

Casting the?`null` is?required for?the?resolved method?descriptor to?be?`(ForEachOrderedTask, ForEachOrderedTask)ForEachOrderedTask` instead?of?`(ForEachOrderedTask, Object)ForEachOrderedTask`, which?prevents unnecessary type?conversion `LambdaForm`s from?being?introduced and?allows [`VarHandle::withInvokeExactBehavior`] to?be?used:
Suggestion:

            var leftDescendant = (ForEachOrderedTask<S, T>) NEXT.getAndSet(this, (ForEachOrderedTask<S, T>) null);


[`VarHandle::withInvokeExactBehavior`]: https://docs.oracle.com/en/java/javase/19/docs/api/java.base/java/lang/invoke/VarHandle.html#withInvokeExactBehavior()

-------------

PR: https://git.openjdk.org/jdk/pull/12320

From duke at openjdk.org  Tue Feb 28 09:44:00 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Tue, 28 Feb 2023 09:44:00 GMT
Subject: RFR: 8302872: Speed up StringLatin1.regionMatchesCI_UTF16
Message-ID: <4SMUYcB8RTO3-nB444DCUHNcdDCmcO7WtCBCf7Gc9KM=.c8f2ab0b-1b72-461b-88e8-135318e092cc@github.com>

This PR continues the efforts from #12632 to speed up case-insensitive string matching.

We now tackle case-insensitive comparison of mixed-coder strings, implemented in `StringLatin1.regionMatchesCI_UTF16`

Key insights:

- If the UTF16 code point is also in latin1 range, we can leverage improvements from 12632 directly by calling `CharacterDataLatin1.equalsIgnoreCase`
- There are exactly 7 non-latin1 Unicode code points which case fold into the latin1 range. We can special-case our comparison of these code points by adding the method `CharacterDataLatin1.latin1CaseFold`.
- To avoid checking of `a == b` twice, this check is lifted out of `CharacterDataLatin1.equalsIgnoreCase` and the two callers are updated to check that `a != b` before calling the method. 
 
For completeness, the RegionMatches test is updated to also compare Turkic dotted/dotless 'i's against the uppercase ASCII 'I', not just the lowercase one.  Not stricktly related to the purpose of this PR, but it did help catch a regression introduced in an earlier iteration of the PR.   

To guard against regressions caused by future changes to the set of Unicode code points folding into latin1, a new test is added to `EqualsIgnoreCase` which identifies all such code points and verifies they are compared correcty.

Performance is tested for matching and mismatching cases of selected code point pairs picked from the ASCII letter, ASCII number, latin1 letter and non-latin Unicode letter ranges. Results in the first comment below.

-------------

Commit messages:
 - Inline local variable
 - latin1CaseFold was moved to CharacterDataLatin1
 - Move latin1CaseFold to CharacterDataLatin1
 - Improve latin1CaseFold javadocs
 - Simplify comments
 - Prefer fast matching by comparing for equality before checking latin1 range
 - Improve Javadocs of latin1CaseFold
 - Be consistent in comments
 - CharacterData.latin1LowerCase was renamed to latin1CaseFold
 - Hoist equality check out of CharacterDataLatin1.equalsIgnoreCase
 - ... and 13 more: https://git.openjdk.org/jdk/compare/f2b03f9a...92755920

Changes: https://git.openjdk.org/jdk/pull/12637/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12637&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8302872
  Stats: 169 lines in 5 files changed: 155 ins; 2 del; 12 mod
  Patch: https://git.openjdk.org/jdk/pull/12637.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12637/head:pull/12637

PR: https://git.openjdk.org/jdk/pull/12637

From duke at openjdk.org  Tue Feb 28 09:44:02 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Tue, 28 Feb 2023 09:44:02 GMT
Subject: RFR: 8302872: Speed up StringLatin1.regionMatchesCI_UTF16
In-Reply-To: <4SMUYcB8RTO3-nB444DCUHNcdDCmcO7WtCBCf7Gc9KM=.c8f2ab0b-1b72-461b-88e8-135318e092cc@github.com>
References: <4SMUYcB8RTO3-nB444DCUHNcdDCmcO7WtCBCf7Gc9KM=.c8f2ab0b-1b72-461b-88e8-135318e092cc@github.com>
Message-ID: <pX_gO_-6yujPk_iElIdqX58A9R0MNgPtW34D8vYgFcE=.8e0eefeb-32d6-44fb-916c-c87774e0ffb9@github.com>

On Sat, 18 Feb 2023 18:22:49 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

> This PR continues the efforts from #12632 to speed up case-insensitive string matching.
> 
> We now tackle case-insensitive comparison of mixed-coder strings, implemented in `StringLatin1.regionMatchesCI_UTF16`
> 
> Key insights:
> 
> - If the UTF16 code point is also in latin1 range, we can leverage improvements from 12632 directly by calling `CharacterDataLatin1.equalsIgnoreCase`
> - There are exactly 7 non-latin1 Unicode code points which case fold into the latin1 range. We can special-case our comparison of these code points by adding the method `CharacterDataLatin1.latin1CaseFold`.
> - To avoid checking of `a == b` twice, this check is lifted out of `CharacterDataLatin1.equalsIgnoreCase` and the two callers are updated to check that `a != b` before calling the method. 
>  
> For completeness, the RegionMatches test is updated to also compare Turkic dotted/dotless 'i's against the uppercase ASCII 'I', not just the lowercase one.  Not stricktly related to the purpose of this PR, but it did help catch a regression introduced in an earlier iteration of the PR.   
> 
> To guard against regressions caused by future changes to the set of Unicode code points folding into latin1, a new test is added to `EqualsIgnoreCase` which identifies all such code points and verifies they are compared correcty.
> 
> Performance is tested for matching and mismatching cases of selected code point pairs picked from the ASCII letter, ASCII number, latin1 letter and non-latin Unicode letter ranges. Results in the first comment below.

Benchmark results:

Baseline:


Benchmark                                 (codePoints)  (size)  Mode  Cnt      Score     Error  Units
RegionMatchesIC.Mixed.regionMatchesIC      ascii-match    1024  avgt   15   1497.391 ?  22.350  ns/op
RegionMatchesIC.Mixed.regionMatchesIC   ascii-mismatch    1024  avgt   15      5.346 ?   0.165  ns/op
RegionMatchesIC.Mixed.regionMatchesIC     number-match    1024  avgt   15    364.034 ?   5.561  ns/op
RegionMatchesIC.Mixed.regionMatchesIC  number-mismatch    1024  avgt   15      4.036 ?   0.171  ns/op
RegionMatchesIC.Mixed.regionMatchesIC       lat1-match    1024  avgt   15   2674.043 ? 174.669  ns/op
RegionMatchesIC.Mixed.regionMatchesIC    lat1-mismatch    1024  avgt   15      6.493 ?   0.230  ns/op
RegionMatchesIC.Mixed.regionMatchesIC      utf16-match    1024  avgt   15  12630.314 ? 212.472  ns/op
RegionMatchesIC.Mixed.regionMatchesIC   utf16-mismatch    1024  avgt   15     14.796 ?   0.359  ns/op



PR:


Benchmark                                 (codePoints)  (size)  Mode  Cnt     Score    Error  Units
RegionMatchesIC.Mixed.regionMatchesIC      ascii-match    1024  avgt   15  1449.499 ? 14.350  ns/op
RegionMatchesIC.Mixed.regionMatchesIC   ascii-mismatch    1024  avgt   15     3.450 ?  0.082  ns/op
RegionMatchesIC.Mixed.regionMatchesIC     number-match    1024  avgt   15   362.582 ?  2.963  ns/op
RegionMatchesIC.Mixed.regionMatchesIC  number-mismatch    1024  avgt   15     3.259 ?  0.021  ns/op
RegionMatchesIC.Mixed.regionMatchesIC       lat1-match    1024  avgt   15  1625.513 ? 14.305  ns/op
RegionMatchesIC.Mixed.regionMatchesIC    lat1-mismatch    1024  avgt   15     3.858 ?  0.027  ns/op
RegionMatchesIC.Mixed.regionMatchesIC      utf16-match    1024  avgt   15  1422.722 ? 85.581  ns/op
RegionMatchesIC.Mixed.regionMatchesIC   utf16-mismatch    1024  avgt   15     3.756 ?  0.089  ns/op

-------------

PR: https://git.openjdk.org/jdk/pull/12637

From aturbanov at openjdk.org  Tue Feb 28 09:56:05 2023
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Tue, 28 Feb 2023 09:56:05 GMT
Subject: RFR: 8303266: Prefer ArrayList to LinkedList in JImageTask
In-Reply-To: <SRkNnBmskx51DnEokSPJfkixT_BwxPAVNIWEODzMhFU=.ffba06e1-cda9-444f-a3be-b0f12b61b7aa@github.com>
References: <NFrcgY-0XTStyKGm1VDX1F6Ww-rBDdAxoOIc4Dg1I8M=.99d9f44b-f1a2-4432-8580-98d21ad57109@github.com>
 <SRkNnBmskx51DnEokSPJfkixT_BwxPAVNIWEODzMhFU=.ffba06e1-cda9-444f-a3be-b0f12b61b7aa@github.com>
Message-ID: <rGQeRZCPQo5Qo-viRbg-1I7ASACILVBUBjqhSowfZ6g=.eb451f69-0fe3-4ab6-8ac8-34d84775aab3@github.com>

On Mon, 27 Feb 2023 22:59:42 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> `LinkedList` is used as a field `jdk.tools.jimage.JImageTask.OptionsValues#jimages`
>> It's created, filled (with `add`) and then iterated. No removes from the head or something like this. `ArrayList` should be preferred as more efficient and widely used (more chances for JIT) collection.
>
> IMHO, there is not enough value in this change to continue the review.  It should be closed without integrating.

@RogerRiggs
I believe it's [common](https://twitter.com/stuartmarks/status/1241522641707532289) [knowledge](https://mobile.twitter.com/kuksenk0/status/1299412730672304128) that LinkedList is not a best collection nowadays.
OpenJDK source code is a reference implementation, and people look at its code.
And when people see that OpenJDK guys use LinkedList (As I can see it's still have 234 usages in OpenJDK), it's confusing and creates questions.
I believe cleaning OpenJDK repository from outdated usages could speed up LinkedList obsoleteness.

-------------

PR: https://git.openjdk.org/jdk/pull/12760

From alanb at openjdk.org  Tue Feb 28 10:54:12 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 28 Feb 2023 10:54:12 GMT
Subject: RFR: JDK-8302323 Add repeat methods to StringBuilder/StringBuffer
 [v3]
In-Reply-To: <USKIo5-pKuGZ9zfcj1dvmw98vqZBKv3q0sIl9ny1bdM=.54283a18-6f09-4fa1-801a-2298e69b750d@github.com>
References: <ygMjzllqk27Dss1q2oRgcNvK_GJdbFVweVHTvF7zpwY=.06d27701-6b42-4663-958e-f8aca9bc2bc5@github.com>
 <USKIo5-pKuGZ9zfcj1dvmw98vqZBKv3q0sIl9ny1bdM=.54283a18-6f09-4fa1-801a-2298e69b750d@github.com>
Message-ID: <rC1mJDTd2jvqllZPL8vup7wzqWpmtoDtltsVjYtZVzU=.d10c7e57-1b60-4579-9f7a-bd9dab367c6b@github.com>

On Mon, 27 Feb 2023 13:30:47 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> Add the ability to repeatedly append char and CharSequence data to StringBuilder/StringBuffer.
>
> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Optimize for empty CharSequence

src/java.base/share/classes/java/lang/AbstractStringBuilder.java line 1872:

> 1870:      * {@code CharSequence} length.
> 1871:      *
> 1872:      * @param cs     a {@code CharSequence}

append(CharSequence, int, int) has  "If s is null, then this method appends characters as if the s parameter was a sequence containing the four characters "null".". It looks like the proposal is to allow cs be null, in which case you'll need similar javadoc. In passing, append(CharSequence) is inheriting the method description from Appendable so it has the wrong parameter name.

-------------

PR: https://git.openjdk.org/jdk/pull/12728

From duke at openjdk.org  Tue Feb 28 10:56:06 2023
From: duke at openjdk.org (Viktor Klang)
Date: Tue, 28 Feb 2023 10:56:06 GMT
Subject: RFR: JDK-8302666: Replace CHM with VarHandle in ForeachOrderedTask
 [v4]
In-Reply-To: <srz55riYaEYkSOblDe_7bYJ1SCiuopS9C2Cb9sH0Yk8=.c6fe3708-421b-4a67-9720-b65405ec38b1@github.com>
References: <HAgE8xmpZT_2-b5ZDr8TgJNgjhVb3D4ZS3sQqA7c6Mo=.389fa590-681c-44a9-9823-8f70a6129797@github.com>
 <rkiS971vfW6rzjSOY16ReMHJbA-yf7YzPMF6xnkjjG8=.89606151-5614-4714-98c6-c65adfb79514@github.com>
 <srz55riYaEYkSOblDe_7bYJ1SCiuopS9C2Cb9sH0Yk8=.c6fe3708-421b-4a67-9720-b65405ec38b1@github.com>
Message-ID: <GzQB_bOFOTmBxTbEdDEP9cNAWbvlu2auV1dDdO2CcYk=.8b68645a-86f9-4171-9c45-3b285b977ca1@github.com>

On Tue, 28 Feb 2023 09:04:21 GMT, ExE Boss <duke at openjdk.org> wrote:

>> Viktor Klang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits:
>> 
>>  - Updating copyright header of ForEachOps.java and removing unnecessary suppression of an unchecked cast.
>>  - Write the initial value of the next reference without using the VarHandle
>>  - JDK-8302666: Replace CHM with VarHandle in ForeachOrderedTask
>
> src/java.base/share/classes/java/util/stream/ForEachOps.java line 513:
> 
>> 511:             // of right subtree (if any, which can be this task's right sibling)
>> 512:             //
>> 513:             var leftDescendant = (ForEachOrderedTask<S, T>)NEXT.getAndSet(this, null);
> 
> Casting the?`null` is?required for?the?resolved method?descriptor to?be?`(ForEachOrderedTask, ForEachOrderedTask)ForEachOrderedTask` instead?of?`(ForEachOrderedTask, Object)ForEachOrderedTask`, which?prevents unnecessary type?conversion `LambdaForm`s from?being?introduced and?allows [`VarHandle::withInvokeExactBehavior`] to?be?used:
> Suggestion:
> 
>             var leftDescendant = (ForEachOrderedTask<S, T>) NEXT.getAndSet(this, (ForEachOrderedTask<S, T>) null);
> 
> 
> [`VarHandle::withInvokeExactBehavior`]: https://docs.oracle.com/en/java/javase/19/docs/api/java.base/java/lang/invoke/VarHandle.html#withInvokeExactBehavior()

@ExE-Boss Ah, sorry, it was meant to be there. :)

-------------

PR: https://git.openjdk.org/jdk/pull/12320

From alanb at openjdk.org  Tue Feb 28 10:57:11 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 28 Feb 2023 10:57:11 GMT
Subject: RFR: JDK-8302323 Add repeat methods to StringBuilder/StringBuffer
 [v3]
In-Reply-To: <USKIo5-pKuGZ9zfcj1dvmw98vqZBKv3q0sIl9ny1bdM=.54283a18-6f09-4fa1-801a-2298e69b750d@github.com>
References: <ygMjzllqk27Dss1q2oRgcNvK_GJdbFVweVHTvF7zpwY=.06d27701-6b42-4663-958e-f8aca9bc2bc5@github.com>
 <USKIo5-pKuGZ9zfcj1dvmw98vqZBKv3q0sIl9ny1bdM=.54283a18-6f09-4fa1-801a-2298e69b750d@github.com>
Message-ID: <SPViIDziFwA27BNcNy-nKE8sL0eUCm8HG-VP07XrSKI=.ba658e3a-0581-4e9a-ac7c-048b33920d32@github.com>

On Mon, 27 Feb 2023 13:30:47 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> Add the ability to repeatedly append char and CharSequence data to StringBuilder/StringBuffer.
>
> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Optimize for empty CharSequence

src/java.base/share/classes/java/lang/AbstractStringBuilder.java line 1837:

> 1835:      * @since 21
> 1836:      * @throws IllegalArgumentException  if {@code count} is less than zero
> 1837:      * @throws IndexOutOfBoundsException  if the result overflows the buffer

IOOBE is for cases when an index is out of range so maybe that should be looked at again.

-------------

PR: https://git.openjdk.org/jdk/pull/12728

From lancea at openjdk.org  Tue Feb 28 11:04:05 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Tue, 28 Feb 2023 11:04:05 GMT
Subject: RFR: 8303232: java.util.Date.parse(String) and
 java.util.Date(String) don't declare thrown IllegalArgumentException
In-Reply-To: <6S1UF7DvwvaGLJJhkX8DlBiV57SImGBxyDMLYohzfwU=.1937701d-8be4-4a1f-85e8-c6ad19ccc72a@github.com>
References: <6S1UF7DvwvaGLJJhkX8DlBiV57SImGBxyDMLYohzfwU=.1937701d-8be4-4a1f-85e8-c6ad19ccc72a@github.com>
Message-ID: <6ujF4i1k2T0ep4Dyg1kqDkr4ujdCTuVxYqqvt0bWCtQ=.92c483e7-72f0-4403-acd7-6064e1d673aa@github.com>

On Tue, 28 Feb 2023 00:07:05 GMT, Justin Lu <jlu at openjdk.org> wrote:

> The method `java.util.Date.parse(String)` and as a result, constructor `java.util.Date(String)` throw an `IllegalArgumentException`. This exception is not properly referenced in the javadoc, and this PR simply adds the throws javadoc tag to make it apparent.

Thanks for getting the CSR submitted  Justin (and it is already approved).

-------------

Marked as reviewed by lancea (Reviewer).

PR: https://git.openjdk.org/jdk/pull/12779

From duke at openjdk.org  Tue Feb 28 11:09:37 2023
From: duke at openjdk.org (Viktor Klang)
Date: Tue, 28 Feb 2023 11:09:37 GMT
Subject: RFR: JDK-8302666: Replace CHM with VarHandle in ForeachOrderedTask
 [v5]
In-Reply-To: <HAgE8xmpZT_2-b5ZDr8TgJNgjhVb3D4ZS3sQqA7c6Mo=.389fa590-681c-44a9-9823-8f70a6129797@github.com>
References: <HAgE8xmpZT_2-b5ZDr8TgJNgjhVb3D4ZS3sQqA7c6Mo=.389fa590-681c-44a9-9823-8f70a6129797@github.com>
Message-ID: <9Th3ZUGlDBxNXHg6dkVO63m-qFw8OV1b6nDqJF0H6SA=.fdf383c0-8914-40b0-806e-c1d8b2e2045e@github.com>

> I noticed when looking at the code that there was no real need to use a CHM to perform the tracking of activation in an ordered fashion on ForEachOrderedTask, but instead a VarHandle can be used, reducing allocations and indirection.

Viktor Klang has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:

  Updating copyright header of ForEachOps.java and removing unnecessary suppression of an unchecked cast.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12320/files
  - new: https://git.openjdk.org/jdk/pull/12320/files/b4b241e2..a5c6b0d0

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12320&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12320&range=03-04

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/12320.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12320/head:pull/12320

PR: https://git.openjdk.org/jdk/pull/12320

From duke at openjdk.org  Tue Feb 28 11:13:11 2023
From: duke at openjdk.org (Viktor Klang)
Date: Tue, 28 Feb 2023 11:13:11 GMT
Subject: RFR: JDK-8297605 DelayQueue javadoc is confusing
In-Reply-To: <jTNA5IGsXt8szGzobAncx9EXwDIn-JYor5oUyWW3iXM=.2208a83c-c44d-4916-ba88-498cfd614d2d@github.com>
References: <jdJ46gB5VbY2LPrH7oGbtCtU65HGtd7GZ7SB8InbG-A=.8679db0c-28b2-4665-ab92-e89af0ad38e6@github.com>
 <m3sbJeTRxVnt7cx23kGHMaNhpOBfiYWg3fTW6S6XBys=.3f94ea53-90da-460a-80ea-416b91a7e669@github.com>
 <jTNA5IGsXt8szGzobAncx9EXwDIn-JYor5oUyWW3iXM=.2208a83c-c44d-4916-ba88-498cfd614d2d@github.com>
Message-ID: <PQFZ955F0TjeTPtLYJ1MDojAdVd8rCToGV76AUR-J-M=.93f943ac-1aee-4044-9149-ea650082ea35@github.com>

On Mon, 27 Feb 2023 20:09:12 GMT, Martin Buchholz <martin at openjdk.org> wrote:

>> Here's my attempt:
>> 
>> 
>>  * An unbounded {@linkplain BlockingQueue blocking queue} of {@link Delayed}
>>  * elements, in which an element generally becomes eligible for removal when its
>>  * delay has expired.
>>  *
>>  * <p>An element is considered <em>expired</em> when its {@code
>>  * getDelay(TimeUnit.NANOSECONDS)} method would return a value less than or
>>  * equal to zero.
>>  *
>>  * <p>An element is considered the <em>head</em> of the queue if it is the
>>  * element with the earliest expiration time, whether in the past or the future,
>>  * if there is such an element.
>>  *
>>  * <p>An element is considered the <em>expired head</em> of the queue if it is
>>  * the <em>expired</em> element with the earliest expiration time in the
>>  * past, if there is such an element.
>>  * The <em>expired head</em>, when present, is also the <em>head</em>.
>>  *
>>  * <p>While this class implements the {@code BlockingQueue} interface, it
>>  * intentionally violates the general contract of {@code BlockingQueue}, in that
>>  * the following methods disregard the presence of unexpired elements and only
>>  * ever remove the <em>expired head</em>:
>>  *
>>  * <ul>
>>  * <li> {@link #poll()}
>>  * <li> {@link #poll(long,TimeUnit)}
>>  * <li> {@link #take()}
>>  * <li> {@link #remove()}
>>  * </ul>
>>  *
>>  * <p>All other methods operate on both expired and unexpired elements.  For
>>  * example, the {@code size} method returns the count of all elements.  Method
>>  * {@link peek()} may return the non-null <em>head</em> even when {@code
>>  * take()} would block waiting for that element to expire.
>>  *
>>  * <p>This queue does not permit null elements.
>
>> @Martin-Buchholz Martin, how would you like to proceed with your proposed wording, would you prefer a suggested edit to this PR, do a separate PR, or otherwise? /cc @AlanBateman (any recommendation, Alan? thinking )
> 
> Talked me into it - I will dust off my github/skara skillz and make a new PR.  
> 
> I wonder if there's now a way to override javadoc for remove() without creating a new method body.

@Martin-Buchholz I guess `remove` could be overridden and just delegate to `super`?

-------------

PR: https://git.openjdk.org/jdk/pull/12729

From alanb at openjdk.org  Tue Feb 28 11:28:06 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 28 Feb 2023 11:28:06 GMT
Subject: RFR: 8303175: (fs) Deprecate
 com.sun.nio.file.SensitivityWatchEventModifier for removal [v2]
In-Reply-To: <mRL4BzPPcM-KIX3prN-P5REG13aES0ilBAJEPybK-Dk=.8302a2e9-80a5-46c2-8b13-4e2332d47b04@github.com>
References: <s7IRC6buEQ5NrNc4XW3lIf6wpdfBksPrIjuTnTO99Gc=.380f3194-e6e7-4c55-b322-2fff1984cd4a@github.com>
 <mRL4BzPPcM-KIX3prN-P5REG13aES0ilBAJEPybK-Dk=.8302a2e9-80a5-46c2-8b13-4e2332d47b04@github.com>
Message-ID: <UwTYhNKsinnZDppqa0-ivzSLOnhYvYB1lQWojCVpH90=.c528101d-afd2-49dc-a5dd-b9891c39c1d7@github.com>

On Fri, 24 Feb 2023 19:04:33 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Deprecate `SensitivityWatchEventModifier` for now instead of directly removing it as proposed in #12626.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8303175: Move @deprecated above @since; tweak verbiage

src/jdk.unsupported/share/classes/com/sun/nio/file/SensitivityWatchEventModifier.java line 40:

> 38:  * {@code WatchService} is used only on macOS and likely to be removed
> 39:  * in a future release when a version based on the native file event
> 40:  * notification facility becomes available.

I agree it's time to deprecate this extension but I think the reasoning will need a few rounds to get right. As background, JDK-8285956 changed the default sensitivity from medium to high in JDK 19 so the need to bump the event (and thus reducing the polling interval) has mostly gone away. So maybe we should thinking about changing PollingWatchService it to ignore the these modifiers (like it is done with the native implementations). If we did that then it would be easy to word the deprecation text as it could just say that the modifier originally provided a hint to polling based WatchService implementations but is no longer used.

src/jdk.unsupported/share/classes/com/sun/nio/file/SensitivityWatchEventModifier.java line 45:

> 43:  */
> 44: 
> 45: @Deprecated(since="7", forRemoval = true)

I assume this should be "21" rather than "7"

-------------

PR: https://git.openjdk.org/jdk/pull/12746

From jwaters at openjdk.org  Tue Feb 28 12:24:06 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Tue, 28 Feb 2023 12:24:06 GMT
Subject: RFR: 8303227: JniObjWithEnv should be NullablePointer compliant
In-Reply-To: <tSmb1smHT4lPI7yJv2Q_Nsy2n3LCdrRPTyhEPuMJTgY=.a356defb-f164-4d2e-9f29-61dc6be96c1f@github.com>
References: <tSmb1smHT4lPI7yJv2Q_Nsy2n3LCdrRPTyhEPuMJTgY=.a356defb-f164-4d2e-9f29-61dc6be96c1f@github.com>
Message-ID: <8wTd9iI_1rDUu5qmdvfgGHEXuvdDK4qdoK3L-hmgbws=.9634da5b-3091-47e5-a5ad-eed18d48d9d7@github.com>

On Mon, 27 Feb 2023 08:19:53 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> JniObjWithEnv is a struct that is commonly managed by std::unique_ptr. Although it can support managing objects that are not raw pointers, any such objects have to be [NullablePointers](https://en.cppreference.com/w/cpp/named_req/NullablePointer). In the past this has [broken the build when compiler upgrades were carried out](https://bugs.openjdk.org/browse/JDK-8244220), so we should add in the final requirements to make the struct a true NullablePointer once and for all, to prevent similar issues from happening in the future

@alexeysemenyukoracle Sorry for the ping, just wanted to avoid the PR getting buried since I don't know any other jpackage reviewers

-------------

PR: https://git.openjdk.org/jdk/pull/12758

From jlaskey at openjdk.org  Tue Feb 28 13:23:09 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Tue, 28 Feb 2023 13:23:09 GMT
Subject: RFR: JDK-8302323 Add repeat methods to StringBuilder/StringBuffer
 [v3]
In-Reply-To: <BBOOKmlaC3alsp0DkupwaVnVRWlfBuMv_eZf8p5Fh4o=.c9da6e7f-16b3-4251-93e3-0d339e1c6cca@github.com>
References: <ygMjzllqk27Dss1q2oRgcNvK_GJdbFVweVHTvF7zpwY=.06d27701-6b42-4663-958e-f8aca9bc2bc5@github.com>
 <USKIo5-pKuGZ9zfcj1dvmw98vqZBKv3q0sIl9ny1bdM=.54283a18-6f09-4fa1-801a-2298e69b750d@github.com>
 <BBOOKmlaC3alsp0DkupwaVnVRWlfBuMv_eZf8p5Fh4o=.c9da6e7f-16b3-4251-93e3-0d339e1c6cca@github.com>
Message-ID: <wadnkf_DBayoMAXzsHZT6CAx1o5tRB4m1htqk6x0QN4=.677e2bc2-a31e-4eaa-a5c1-955769fd5ec1@github.com>

On Tue, 28 Feb 2023 07:50:18 GMT, Tagir F. Valeev <tvaleev at openjdk.org> wrote:

>> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Optimize for empty CharSequence
>
> src/java.base/share/classes/java/lang/AbstractStringBuilder.java line 1879:
> 
>> 1877:      * @since 21
>> 1878:      * @throws IllegalArgumentException  if {@code count} is less than zero
>> 1879:      * @throws IndexOutOfBoundsException  if the result overflows the buffer
> 
> Can `IndexOutOfBoundsException` be really thrown? We don't have any index here. From the implementation I see that only `OutOfMemoryError` and `IllegalArgumentException` can be thrown.
> 
> Also, I see a small descrepancy between messages in this method and `String.repeat`. The latter has:
> 
> 
>      * @throws  IllegalArgumentException if the {@code count} is
>      *          negative.
>      *
>      * @since 11
>      */
>     public String repeat(int count) {
>         if (count < 0) {
>             throw new IllegalArgumentException("count is negative: " + count);
>         }
> 
> 
> Probably it's better to reuse the same wording ("is negative" instead of "is less than zero") for consistency?

You are correct about `IndexOutOfBoundsException`. Earlier versions used methods that threw `IndexOutOfBoundsException`. Also, changing to "is negative"

-------------

PR: https://git.openjdk.org/jdk/pull/12728

From jlaskey at openjdk.org  Tue Feb 28 13:29:49 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Tue, 28 Feb 2023 13:29:49 GMT
Subject: RFR: JDK-8302323 Add repeat methods to StringBuilder/StringBuffer
 [v4]
In-Reply-To: <ygMjzllqk27Dss1q2oRgcNvK_GJdbFVweVHTvF7zpwY=.06d27701-6b42-4663-958e-f8aca9bc2bc5@github.com>
References: <ygMjzllqk27Dss1q2oRgcNvK_GJdbFVweVHTvF7zpwY=.06d27701-6b42-4663-958e-f8aca9bc2bc5@github.com>
Message-ID: <_xWE2kNbPX4koybMJrD8UQDGjU0qX5LVCzKo_o2V-Vs=.aa3615ee-9786-41b5-b2fa-d2da40c35482@github.com>

> Add the ability to repeatedly append char and CharSequence data to StringBuilder/StringBuffer.

Jim Laskey has updated the pull request incrementally with two additional commits since the last revision:

 - Remove @throws IndexOutOfBoundsException
 - Change error report to use "is negative"

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12728/files
  - new: https://git.openjdk.org/jdk/pull/12728/files/01ffb19b..9a157ce7

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12728&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12728&range=02-03

  Stats: 13 lines in 3 files changed: 3 ins; 6 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/12728.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12728/head:pull/12728

PR: https://git.openjdk.org/jdk/pull/12728

From jlaskey at openjdk.org  Tue Feb 28 13:29:55 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Tue, 28 Feb 2023 13:29:55 GMT
Subject: RFR: JDK-8302323 Add repeat methods to StringBuilder/StringBuffer
 [v3]
In-Reply-To: <SPViIDziFwA27BNcNy-nKE8sL0eUCm8HG-VP07XrSKI=.ba658e3a-0581-4e9a-ac7c-048b33920d32@github.com>
References: <ygMjzllqk27Dss1q2oRgcNvK_GJdbFVweVHTvF7zpwY=.06d27701-6b42-4663-958e-f8aca9bc2bc5@github.com>
 <USKIo5-pKuGZ9zfcj1dvmw98vqZBKv3q0sIl9ny1bdM=.54283a18-6f09-4fa1-801a-2298e69b750d@github.com>
 <SPViIDziFwA27BNcNy-nKE8sL0eUCm8HG-VP07XrSKI=.ba658e3a-0581-4e9a-ac7c-048b33920d32@github.com>
Message-ID: <hjDj6s5ztXBSu9UCnHPnA1QC2Dv6-h8urksE-eN5arQ=.6ca7a17e-f860-402f-8a71-979dca31d235@github.com>

On Tue, 28 Feb 2023 10:54:14 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Optimize for empty CharSequence
>
> src/java.base/share/classes/java/lang/AbstractStringBuilder.java line 1837:
> 
>> 1835:      * @since 21
>> 1836:      * @throws IllegalArgumentException  if {@code count} is less than zero
>> 1837:      * @throws IndexOutOfBoundsException  if the result overflows the buffer
> 
> IOOBE is for cases when an index is out of range so maybe that should be looked at again.

See above. Removed.

> src/java.base/share/classes/java/lang/AbstractStringBuilder.java line 1872:
> 
>> 1870:      * {@code CharSequence} length.
>> 1871:      *
>> 1872:      * @param cs     a {@code CharSequence}
> 
> append(CharSequence, int, int) has  "If s is null, then this method appends characters as if the s parameter was a sequence containing the four characters "null".". It looks like the proposal is to allow cs be null, in which case you'll need similar javadoc. In passing, append(CharSequence) is inheriting the method description from Appendable so it has the wrong parameter name.

Changing

-------------

PR: https://git.openjdk.org/jdk/pull/12728

From rgiulietti at openjdk.org  Tue Feb 28 13:31:56 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Tue, 28 Feb 2023 13:31:56 GMT
Subject: RFR: 8302590: Add String.indexOf(int ch, int fromIndex,
 int toIndex) [v3]
In-Reply-To: <uQ65oRaVDfpzm9bYRuo_MvSuZIdepicE3GnB3Omyngs=.fc23545b-141a-47e5-8a6a-aa28ae1375e5@github.com>
References: <uQ65oRaVDfpzm9bYRuo_MvSuZIdepicE3GnB3Omyngs=.fc23545b-141a-47e5-8a6a-aa28ae1375e5@github.com>
Message-ID: <VY-Hm8owXgm5vjfxkW7wmnb_TqRsZyMSme4HcSTywyo=.f48897d4-c587-4594-b0b1-b79703e6ec33@github.com>

> Add an `indexOf()` variant allowing to specify both a lower and an upper bound on the search.

Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:

  8302590: Add String.indexOf(int ch, int fromIndex, int toIndex)

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12600/files
  - new: https://git.openjdk.org/jdk/pull/12600/files/fdb39c47..d627e558

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12600&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12600&range=01-02

  Stats: 72 lines in 2 files changed: 72 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/12600.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12600/head:pull/12600

PR: https://git.openjdk.org/jdk/pull/12600

From rgiulietti at openjdk.org  Tue Feb 28 13:33:05 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Tue, 28 Feb 2023 13:33:05 GMT
Subject: RFR: 8302590: Add String.indexOf(int ch, int fromIndex,
 int toIndex) [v2]
In-Reply-To: <IbVMINZH95lDqPcyPdQuUQN5jHa068aDF6RUFa8LZKA=.df6b9e9e-1080-488b-8518-73a77b3d4028@github.com>
References: <uQ65oRaVDfpzm9bYRuo_MvSuZIdepicE3GnB3Omyngs=.fc23545b-141a-47e5-8a6a-aa28ae1375e5@github.com>
 <IbVMINZH95lDqPcyPdQuUQN5jHa068aDF6RUFa8LZKA=.df6b9e9e-1080-488b-8518-73a77b3d4028@github.com>
Message-ID: <BuKnt1d5jjvCnymDI884FPSGxIgjQ7saYI1KJt9Pg3U=.2cc3e3de-8b61-40d0-87b8-58526d27d5b7@github.com>

On Fri, 24 Feb 2023 17:45:23 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> Add an `indexOf()` variant allowing to specify both a lower and an upper bound on the search.
>
> Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8302590: Add String.indexOf(int ch, int fromIndex, int toIndex)

Added a `checkedIndexOf(int ch, int fromIndex, int toIndex)` variant that throws if
`0 <= fromIndex <= toIndex <= this.length()`
is not met.
Otherwise it behaves like `indexOf(int ch, int fromIndex, int toIndex)`.

-------------

PR: https://git.openjdk.org/jdk/pull/12600

From rgiulietti at openjdk.org  Tue Feb 28 13:38:08 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Tue, 28 Feb 2023 13:38:08 GMT
Subject: RFR: 8302590: Add String.indexOf(int ch, int fromIndex,
 int toIndex) [v3]
In-Reply-To: <VY-Hm8owXgm5vjfxkW7wmnb_TqRsZyMSme4HcSTywyo=.f48897d4-c587-4594-b0b1-b79703e6ec33@github.com>
References: <uQ65oRaVDfpzm9bYRuo_MvSuZIdepicE3GnB3Omyngs=.fc23545b-141a-47e5-8a6a-aa28ae1375e5@github.com>
 <VY-Hm8owXgm5vjfxkW7wmnb_TqRsZyMSme4HcSTywyo=.f48897d4-c587-4594-b0b1-b79703e6ec33@github.com>
Message-ID: <iRwQhvs_dM9q8-PU9l4Oe5Km3mbTLX3zr_bjER2V6So=.76033687-91d0-40f8-8a83-3311132efeed@github.com>

On Tue, 28 Feb 2023 13:31:56 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> Add an `indexOf()` variant allowing to specify both a lower and an upper bound on the search.
>
> Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8302590: Add String.indexOf(int ch, int fromIndex, int toIndex)

[CSR](https://bugs.openjdk.org/browse/JDK-8302680) updated accordingly.

-------------

PR: https://git.openjdk.org/jdk/pull/12600

From prappo at openjdk.org  Tue Feb 28 13:39:49 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Tue, 28 Feb 2023 13:39:49 GMT
Subject: RFR: 8303350: Fix mistyped {@code}
Message-ID: <Si2xSZHXw8_KzOOGK8zTHu1yVJ_20lIc15mg_LovvCk=.5a7c6041-71c3-4208-8110-6a9a13f66857@github.com>

Please review this trivial fix.

-------------

Commit messages:
 - Initial commit

Changes: https://git.openjdk.org/jdk/pull/12784/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12784&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8303350
  Stats: 6 lines in 3 files changed: 0 ins; 0 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/12784.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12784/head:pull/12784

PR: https://git.openjdk.org/jdk/pull/12784

From aturbanov at openjdk.org  Tue Feb 28 13:59:08 2023
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Tue, 28 Feb 2023 13:59:08 GMT
Subject: RFR: JDK-8302040: Port fdlibm sqrt to Java [v5]
In-Reply-To: <ydzE4UeDk8qDeT_rwe6YkxniMdBiSMSuteVLJOTEVn8=.5a15a4a5-1e65-4a4b-871d-3ff010d7fa12@github.com>
References: <rjVM2lWPdsvPcfLF3oNShP-cSN8-P-i16ikUC3sTgIg=.1d4f470d-2ac9-4394-b55e-099affce763f@github.com>
 <ydzE4UeDk8qDeT_rwe6YkxniMdBiSMSuteVLJOTEVn8=.5a15a4a5-1e65-4a4b-871d-3ff010d7fa12@github.com>
Message-ID: <nOUSrn_2Vsr9WYjP_4TqlJE-xF_Ar5PKtGUo4NEGLM8=.3ff5c21c-4b0d-456c-8d19-1b3b4b426416@github.com>

On Mon, 27 Feb 2023 18:26:51 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> The wheel of FDLIBM porting turns a notch and sqrt comes into play.
>> 
>> While the sqrt operation usually has a hardware implementation that is intrinsified, for completeness a software implementation should be available as well.
>
> Joe Darcy 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:
> 
>  - Enable intrinsic for StrictMath.sqrt; thanks to Tobias Hartmann for assistance with the HotSpot updates.
>  - Merge branch 'master' into JDK-8302040
>  - Implement review feedback.
>  - Add one one unsigned shift comment.
>  - Respond to review feedback.
>  - JDK-8302040: Port fdlibm sqrt to Java

Marked as reviewed by aturbanov (Committer).

-------------

PR: https://git.openjdk.org/jdk/pull/12736

From alanb at openjdk.org  Tue Feb 28 14:12:26 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 28 Feb 2023 14:12:26 GMT
Subject: RFR: 8303198: System and Runtime.exit() resilience to logging
 errors
In-Reply-To: <pOA8BdTlG7co7FF8u3gjWUPjAQZT7Kkg7nz7m_LK3Vk=.cb497b97-e55c-4a15-9dc2-15fb94241bde@github.com>
References: <L-cEo4rK2rAwdPUdmq0kG57Kl7atYpSKfupA2ZUTZ4E=.7dafb6d1-eb77-436f-b50f-16998af347af@github.com>
 <oXt0im7AfSA3-GpEgTgwiFIruxjnPAG73L97Z0LYeH8=.166aeccc-d299-419f-8feb-06938dae1383@github.com>
 <rHrPLvyvNcOxOV1HsKVjbg3beRrPxrFa4GF7R4Ry_tQ=.215e28af-60bf-414a-9a13-9c062d98608a@github.com>
 <N34EJ3kiSqBJmGfUkD_q6XgOWQXX1dpoymE2dhL7Oqg=.23a3c4ee-584e-4297-88ab-b0b09a3b2609@github.com>
 <AjFM7Sr5prjExOZXr8btOHIZUtXzTSFSxJZjt2o6Li0=.b040ecaa-a1f1-45f9-9497-ffea36730530@github.com>
 <pOA8BdTlG7co7FF8u3gjWUPjAQZT7Kkg7nz7m_LK3Vk=.cb497b97-e55c-4a15-9dc2-15fb94241bde@github.com>
Message-ID: <PjgBCRv4imyKJhQM2coolbc-w1dj2gFBsedKqaU0Nks=.3b927667-c4e2-4697-bd69-1984074bfbcf@github.com>

On Tue, 28 Feb 2023 02:45:36 GMT, David Holmes <dholmes at openjdk.org> wrote:

> But does that logging include the thread identity? If multiple threads can race to exit and all log, then the developer/user needs to know which logging came from which thread.

That's really up to the Logger and its configuration. If j.u.logging is used then formatters can be configured to put the thread ID into the log records. With 3rd party logging libraries there seems to be several choices, like %t for the thread name.

The main usage for this logging is to be able to find code in tests, plugins, etc. that is calling System.exit and causing the test runner or container to exit. So I think it's less about "which thread" and more about "which code".

-------------

PR: https://git.openjdk.org/jdk/pull/12770

From asotona at openjdk.org  Tue Feb 28 14:13:02 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Tue, 28 Feb 2023 14:13:02 GMT
Subject: RFR: 8294982: Implementation of Classfile API [v20]
In-Reply-To: <K6w7vBBPpKz30feZIbgFNfjMhIFfle8RT87XgCYyCjw=.1fc7973b-529e-482d-a459-ac02b66e9901@github.com>
References: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
 <Gluemo5fFOPx_G6KtSgHxWEmiv3FFSTlxRHtc6ZPTuc=.6a2b6930-c7fd-4734-b21b-d2ccec1dabcf@github.com>
 <K6w7vBBPpKz30feZIbgFNfjMhIFfle8RT87XgCYyCjw=.1fc7973b-529e-482d-a459-ac02b66e9901@github.com>
Message-ID: <WklxQuifDr3hfm1Nb9cVtbMG7wgXDz_baMWM2LxNVCs=.867d191c-70a5-4bd9-957b-72d56aa6d6b3@github.com>

On Thu, 16 Feb 2023 12:55:06 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   added 4-byte Unicode text to Utf8EntryTest
>
> src/java.base/share/classes/jdk/internal/classfile/impl/SplitConstantPool.java line 217:
> 
>> 215:                 }
>> 216:             };
>> 217:             // Doing a full scan here yields fall-off-the-cliff performance results,
> 
> Understanding checkpoint: the parent is a class reader, which holds some class bytes. The class reader is set up in a way that constant pool entries are read "on-demand" - that is, if I ask the class reader "give me CP entry 42", the classreader will only build that entry (assuming 42 is a valid index) and give me back that entry. Also, the class reader will save the read constant in an internal array, to avoid re-reading the classfile bytes multiple times.
> 
> So, what this code here does is: when we create an entry map, we populate the map with the entries from the parent reader - but we only add entries that were already looked up (e.g. we do not bother reading _all_ entries, and adding all of them to the entry map).
> 
> But, when `findEntry` is called, if we see that we can't find the entry, and we know that there might be constant pool entries from the parent reader still unread, we force a full scan of the parent reader pool and try again.
> 
> Correct?

Right, it is a multi-stage inflation, where partial-only inflation improves performance of frequent use cases significantly and full scan is a fall-back.

-------------

PR: https://git.openjdk.org/jdk/pull/10982

From asotona at openjdk.org  Tue Feb 28 14:23:24 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Tue, 28 Feb 2023 14:23:24 GMT
Subject: RFR: 8294982: Implementation of Classfile API [v20]
In-Reply-To: <01V72lRVYH7rB1NrPpkVKhvj1mksmrelMMTMrHFQ2hk=.4b2c22f3-d9c6-4778-be53-1fb055969f6a@github.com>
References: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
 <Gluemo5fFOPx_G6KtSgHxWEmiv3FFSTlxRHtc6ZPTuc=.6a2b6930-c7fd-4734-b21b-d2ccec1dabcf@github.com>
 <01V72lRVYH7rB1NrPpkVKhvj1mksmrelMMTMrHFQ2hk=.4b2c22f3-d9c6-4778-be53-1fb055969f6a@github.com>
Message-ID: <Zxf7g-vn0s38BsgM_KaED6NmCIgrDnNuk6Zq7OEh2IU=.207180e4-83d0-4a7b-ac43-1e9ffacdd686@github.com>

On Thu, 16 Feb 2023 13:40:49 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   added 4-byte Unicode text to Utf8EntryTest
>
> src/java.base/share/classes/jdk/internal/classfile/constantpool/ConstantPoolBuilder.java line 75:
> 
>> 73:     static ConstantPoolBuilder of(ClassModel classModel) {
>> 74:         ClassReader reader = (ClassReader) classModel.constantPool();
>> 75:         return reader.optionValue(Classfile.Option.Key.CP_SHARING)
> 
> Question: the fact that, when transforming, the new constant pool is the same as the old one, plus some "appended" entries at the end, is a pretty crucial property to ensure that existing code that is not transformed (e.g. unknown attributes) remains legal after transformation. But it seems that, if the `CP_SHARING` option is not passed, we build a brand new constant pool, in which case there's no guarantee that old indices will still point to the same position. Doesn't that lead to issue with unknown attributes?
> 
> I guess my question is: shouldn't the semantics properties/guarantees of a classfile transform be specified regardless of the options being passed in? E.g. it's ok if using different options ends up with different performance model, but I'm a bit worried if options can affect correctness of the transform?

If you propose `constantPoolSharing(false)` should automatically imply `processUnknownAttributes(false)` - it would avoid potential invalid CP entries in the unknown attributes and we may consider that dependency between the two options.
However on the other side there might be unknown attributes completely independent of CP and for such the transformation is safe. Strong options implication would force users to create custom attribute mappers for such attributes.
Current options independence gives user power to configure transformations flexibly, however on the other side it allows to produce classes with invalid CP entries in unknown attributes.

-------------

PR: https://git.openjdk.org/jdk/pull/10982

From asotona at openjdk.org  Tue Feb 28 14:37:47 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Tue, 28 Feb 2023 14:37:47 GMT
Subject: RFR: 8294982: Implementation of Classfile API [v20]
In-Reply-To: <01V72lRVYH7rB1NrPpkVKhvj1mksmrelMMTMrHFQ2hk=.4b2c22f3-d9c6-4778-be53-1fb055969f6a@github.com>
References: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
 <Gluemo5fFOPx_G6KtSgHxWEmiv3FFSTlxRHtc6ZPTuc=.6a2b6930-c7fd-4734-b21b-d2ccec1dabcf@github.com>
 <01V72lRVYH7rB1NrPpkVKhvj1mksmrelMMTMrHFQ2hk=.4b2c22f3-d9c6-4778-be53-1fb055969f6a@github.com>
Message-ID: <dy09oa0LABN_9yw4UZp3PDDpGwLtD8Vip0wWDJ3v1_0=.38c04f5b-e517-4113-ab33-effeb255aa6e@github.com>

On Thu, 16 Feb 2023 13:47: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:
>> 
>>   added 4-byte Unicode text to Utf8EntryTest
>
> src/java.base/share/classes/jdk/internal/classfile/impl/AttributeHolder.java line 38:
> 
>> 36:     private final List<Attribute<?>> attributes = new ArrayList<>();
>> 37: 
>> 38:     public AttributeHolder() {
> 
> default constructor

yes, it is a default constructor, do you suggest to remove it?

-------------

PR: https://git.openjdk.org/jdk/pull/10982

From jpai at openjdk.org  Tue Feb 28 15:03:13 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 28 Feb 2023 15:03:13 GMT
Subject: RFR: 8303350: Fix mistyped {@code}
In-Reply-To: <Si2xSZHXw8_KzOOGK8zTHu1yVJ_20lIc15mg_LovvCk=.5a7c6041-71c3-4208-8110-6a9a13f66857@github.com>
References: <Si2xSZHXw8_KzOOGK8zTHu1yVJ_20lIc15mg_LovvCk=.5a7c6041-71c3-4208-8110-6a9a13f66857@github.com>
Message-ID: <GNA47jn1WpRf3iJ_KAVC2AeRmky18NEK5o-XehSBtNs=.87ac4554-501f-496f-9749-fac9be873801@github.com>

On Tue, 28 Feb 2023 13:31:06 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> Please review this trivial fix.

The changes look fine to me.

-------------

Marked as reviewed by jpai (Reviewer).

PR: https://git.openjdk.org/jdk/pull/12784

From rriggs at openjdk.org  Tue Feb 28 15:30:18 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 28 Feb 2023 15:30:18 GMT
Subject: RFR: JDK-8302323 Add repeat methods to StringBuilder/StringBuffer
 [v3]
In-Reply-To: <LLfaL_h1m-du72iDyOc8rk0GXK7O6M99GEZZlXPffxU=.c9891c50-ceda-4414-b5fb-e38f2945f209@github.com>
References: <ygMjzllqk27Dss1q2oRgcNvK_GJdbFVweVHTvF7zpwY=.06d27701-6b42-4663-958e-f8aca9bc2bc5@github.com>
 <USKIo5-pKuGZ9zfcj1dvmw98vqZBKv3q0sIl9ny1bdM=.54283a18-6f09-4fa1-801a-2298e69b750d@github.com>
 <QKaOV1nP_VHkxb2_D3gSsjGDvipvpsXsk966A9ArB44=.8fdc237c-0eee-4b50-a0ce-b7ee8d73131f@github.com>
 <LLfaL_h1m-du72iDyOc8rk0GXK7O6M99GEZZlXPffxU=.c9891c50-ceda-4414-b5fb-e38f2945f209@github.com>
Message-ID: <YoLVKLBLVOXIjPfQSBAKPHcNFQf-R6EXZLKNHbpc05k=.97e60701-7502-4115-af91-bca8a6726388@github.com>

On Tue, 28 Feb 2023 09:05:44 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/AbstractStringBuilder.java line 1903:
>> 
>>> 1901:             throw new OutOfMemoryError("Required length exceeds implementation limit");
>>> 1902:         }
>>> 1903:         int total = count * length;
>> 
>> We may avoid division if we use the long type:
>> 
>> 
>> long totalLong = ((long) count) * length;
>> if (totalLong > Integer.MAX_VALUE - offset) {
>>     throw new OutOfMemoryError("Required length exceeds implementation limit");
>> }
>> int total = (int) totalLong;
>> 
>> 
>> Should be faster.
>
> I'm a bit surprised this (and the original code) is throwing `OutOfMemoryError` when running into the max array size. It is not truly an out of memory error, but being an `Error`, it would evade standard catch `Exception` blocks.  I would think this is more of an `IllegalStateException` or perhaps something array specific.
> 
> `OutOfMemoryError` is documented pretty specifically that an object allocation failed after exhaustive GC, but no allocation or GC happened:
> 
>>Thrown when the Java Virtual Machine cannot allocate an object because it is out of memory, and no more memory could be made available by the garbage collector.
> 
> ... which is not happening here at all. This leads me to believe the error is not used correctly here.
> 
> Other reasons I find it surprising: `StringBuilder` is not documented to throw this anywhere, it seems to just leak through from various methods implemented by `AbstractStringBuilder`.

OOME is used for a number of not-strictly out of memory conditions, for example off-heap allocation and allocations that can't succeed because they exceed implementation limits.

-------------

PR: https://git.openjdk.org/jdk/pull/12728

From mcimadamore at openjdk.org  Tue Feb 28 15:33:08 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 28 Feb 2023 15:33:08 GMT
Subject: RFR: 8294982: Implementation of Classfile API [v20]
In-Reply-To: <dy09oa0LABN_9yw4UZp3PDDpGwLtD8Vip0wWDJ3v1_0=.38c04f5b-e517-4113-ab33-effeb255aa6e@github.com>
References: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
 <Gluemo5fFOPx_G6KtSgHxWEmiv3FFSTlxRHtc6ZPTuc=.6a2b6930-c7fd-4734-b21b-d2ccec1dabcf@github.com>
 <01V72lRVYH7rB1NrPpkVKhvj1mksmrelMMTMrHFQ2hk=.4b2c22f3-d9c6-4778-be53-1fb055969f6a@github.com>
 <dy09oa0LABN_9yw4UZp3PDDpGwLtD8Vip0wWDJ3v1_0=.38c04f5b-e517-4113-ab33-effeb255aa6e@github.com>
Message-ID: <iNzjTSVc4ZGs_KXdwxPPnwmhnhRyc0ygAT7iFN8mzCs=.a03ee9dc-9d3a-49a7-a09d-ed0cc07fafc2@github.com>

On Tue, 28 Feb 2023 14:33:58 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/classfile/impl/AttributeHolder.java line 38:
>> 
>>> 36:     private final List<Attribute<?>> attributes = new ArrayList<>();
>>> 37: 
>>> 38:     public AttributeHolder() {
>> 
>> default constructor
>
> yes, it is a default constructor, do you suggest to remove it?

Yes, it's inside the implementation, it's not like it's used as a placeholder for javadoc or anything?

-------------

PR: https://git.openjdk.org/jdk/pull/10982

From prappo at openjdk.org  Tue Feb 28 15:43:36 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Tue, 28 Feb 2023 15:43:36 GMT
Subject: Integrated: 8303350: Fix mistyped {@code}
In-Reply-To: <Si2xSZHXw8_KzOOGK8zTHu1yVJ_20lIc15mg_LovvCk=.5a7c6041-71c3-4208-8110-6a9a13f66857@github.com>
References: <Si2xSZHXw8_KzOOGK8zTHu1yVJ_20lIc15mg_LovvCk=.5a7c6041-71c3-4208-8110-6a9a13f66857@github.com>
Message-ID: <aLhW_1hUQUS1wd5eIU5qyYiTsyB83RBtGdN8Yv5ZiVk=.7c36ef4d-fad7-48e0-87a4-770d797cb42a@github.com>

On Tue, 28 Feb 2023 13:31:06 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> Please review this trivial fix.

This pull request has now been integrated.

Changeset: dc5ea6ae
Author:    Pavel Rappo <prappo at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/dc5ea6aeb500d531b4ba49c8e95bf97744cc6c33
Stats:     6 lines in 3 files changed: 0 ins; 0 del; 6 mod

8303350: Fix mistyped {@code}

Reviewed-by: jpai

-------------

PR: https://git.openjdk.org/jdk/pull/12784

From asotona at openjdk.org  Tue Feb 28 16:02:35 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Tue, 28 Feb 2023 16:02:35 GMT
Subject: RFR: 8294982: Implementation of Classfile API [v28]
In-Reply-To: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
References: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
Message-ID: <gn9i38a6nzEV47JphuQyTIZKHiEtooPCsphRtCWmJpc=.1643778c-762a-4944-bf3d-11a73aa4d266@github.com>

> This is root pull request with Classfile API implementation, tests and benchmarks initial drop into JDK.
> 
> Following pull requests consolidating JDK class files parsing, generating, and transforming ([JDK-8294957](https://bugs.openjdk.org/browse/JDK-8294957)) will chain to this one.
> 
> Classfile API development is tracked at:
> https://github.com/openjdk/jdk-sandbox/tree/classfile-api-branch
> 
> Development branch of consolidated JDK class files parsing, generating, and transforming is at:
> https://github.com/openjdk/jdk-sandbox/tree/classfile-api-dev-branch
> 
> Classfile API [JEP](https://bugs.openjdk.org/browse/JDK-8280389) and [online API documentation](https://htmlpreview.github.io/?https://raw.githubusercontent.com/openjdk/jdk-sandbox/classfile-api-javadoc-branch/doc/classfile-api/javadoc/java.base/jdk/internal/classfile/package-summary.html) is also available.
> 
> Please take you time to review this non-trivial JDK addition.
> 
> Thank you,
> Adam

Adam Sotona has updated the pull request incrementally with two additional commits since the last revision:

 - BytecodeHelpers fix
 - javadoc and long lines fixes

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10982/files
  - new: https://git.openjdk.org/jdk/pull/10982/files/7002d719..58c9d2c0

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10982&range=27
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10982&range=26-27

  Stats: 35 lines in 4 files changed: 15 ins; 1 del; 19 mod
  Patch: https://git.openjdk.org/jdk/pull/10982.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10982/head:pull/10982

PR: https://git.openjdk.org/jdk/pull/10982

From asotona at openjdk.org  Tue Feb 28 16:02:45 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Tue, 28 Feb 2023 16:02:45 GMT
Subject: RFR: 8294982: Implementation of Classfile API [v20]
In-Reply-To: <01V72lRVYH7rB1NrPpkVKhvj1mksmrelMMTMrHFQ2hk=.4b2c22f3-d9c6-4778-be53-1fb055969f6a@github.com>
References: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
 <Gluemo5fFOPx_G6KtSgHxWEmiv3FFSTlxRHtc6ZPTuc=.6a2b6930-c7fd-4734-b21b-d2ccec1dabcf@github.com>
 <01V72lRVYH7rB1NrPpkVKhvj1mksmrelMMTMrHFQ2hk=.4b2c22f3-d9c6-4778-be53-1fb055969f6a@github.com>
Message-ID: <50yzjqQcSR2lSq7mh-eV1gY6jX8bVtLIq3xBG21IedI=.8fa3a973-87f9-4507-a168-0ce358c7770a@github.com>

On Thu, 16 Feb 2023 13:43:32 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   added 4-byte Unicode text to Utf8EntryTest
>
> src/java.base/share/classes/jdk/internal/classfile/impl/BytecodeHelpers.java line 54:
> 
>> 52:  */
>> 53: public class BytecodeHelpers {
>> 54: //    public static Map<ConstantDesc, Opcode> constantsToOpcodes = new HashMap<>(16);
> 
> Should this be removed?

yes, fixed, thanks.

> src/java.base/share/classes/jdk/internal/classfile/impl/BytecodeHelpers.java line 56:
> 
>> 54: //    public static Map<ConstantDesc, Opcode> constantsToOpcodes = new HashMap<>(16);
>> 55: 
>> 56:     public BytecodeHelpers() {
> 
> Should this also be removed (same as default constructor) ?

I set the constructor to private as there are no instances created.

> src/java.base/share/classes/jdk/internal/classfile/impl/EntryMap.java line 30:
> 
>> 28:  * An open-chain multimap used to map nonzero hashes to indexes (of either CP
>> 29:  * elements or BSM entries).  Code transformed from public domain implementation
>> 30:  * (http://java-performance.info/implementing-world-fastest-java-int-to-int-hash-map/).
> 
> Could not open this link - seems to redirect to main page

Direct link does not work, I've fixed it to point to the home page.

> src/java.base/share/classes/jdk/internal/classfile/impl/EntryMap.java line 192:
> 
>> 190:         return (int)s;
>> 191:     }
>> 192: }
> 
> Watch for newlines

fixed, thanks.

-------------

PR: https://git.openjdk.org/jdk/pull/10982

From psandoz at openjdk.org  Tue Feb 28 16:13:51 2023
From: psandoz at openjdk.org (Paul Sandoz)
Date: Tue, 28 Feb 2023 16:13:51 GMT
Subject: RFR: JDK-8302666: Replace CHM with VarHandle in ForeachOrderedTask
 [v5]
In-Reply-To: <9Th3ZUGlDBxNXHg6dkVO63m-qFw8OV1b6nDqJF0H6SA=.fdf383c0-8914-40b0-806e-c1d8b2e2045e@github.com>
References: <HAgE8xmpZT_2-b5ZDr8TgJNgjhVb3D4ZS3sQqA7c6Mo=.389fa590-681c-44a9-9823-8f70a6129797@github.com>
 <9Th3ZUGlDBxNXHg6dkVO63m-qFw8OV1b6nDqJF0H6SA=.fdf383c0-8914-40b0-806e-c1d8b2e2045e@github.com>
Message-ID: <1LzrIgu7t_JjtaAd-i9yJeTqlANUbXKEPimWpEGPJu0=.b5478cfa-2a00-4532-8dc7-8c545fe0bd48@github.com>

On Tue, 28 Feb 2023 11:09:37 GMT, Viktor Klang <duke at openjdk.org> wrote:

>> I noticed when looking at the code that there was no real need to use a CHM to perform the tracking of activation in an ordered fashion on ForEachOrderedTask, but instead a VarHandle can be used, reducing allocations and indirection.
>
> Viktor Klang has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:
> 
>   Updating copyright header of ForEachOps.java and removing unnecessary suppression of an unchecked cast.

src/java.base/share/classes/java/util/stream/ForEachOps.java line 513:

> 511:             // of right subtree (if any, which can be this task's right sibling)
> 512:             //
> 513:             var leftDescendant = (ForEachOrderedTask<S, T>)NEXT.getAndSet(this, (ForEachOrderedTask<S, T>)null);

The reference cast on the argument is not required. `VarHandle`'s by default have `MethodHandle` invoke semantics (but without the throwing Throwable):

https://docs.oracle.com/en/java/javase/19/docs/api/java.base/java/lang/invoke/VarHandle.html#invoke

VarHandle's have been engineered so such reference casts on the arguments can be optimized away. This makes them much easier to use than MethodHandles.

-------------

PR: https://git.openjdk.org/jdk/pull/12320

From asotona at openjdk.org  Tue Feb 28 16:20:06 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Tue, 28 Feb 2023 16:20:06 GMT
Subject: RFR: 8294982: Implementation of Classfile API [v20]
In-Reply-To: <01V72lRVYH7rB1NrPpkVKhvj1mksmrelMMTMrHFQ2hk=.4b2c22f3-d9c6-4778-be53-1fb055969f6a@github.com>
References: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
 <Gluemo5fFOPx_G6KtSgHxWEmiv3FFSTlxRHtc6ZPTuc=.6a2b6930-c7fd-4734-b21b-d2ccec1dabcf@github.com>
 <01V72lRVYH7rB1NrPpkVKhvj1mksmrelMMTMrHFQ2hk=.4b2c22f3-d9c6-4778-be53-1fb055969f6a@github.com>
Message-ID: <LdTyBMeXb0wC8SSMsKaYiA96EfJdCdAWKpjACqq4EhU=.147fc67f-9e40-4184-b5f6-da6865c042f6@github.com>

On Thu, 16 Feb 2023 14:41:16 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   added 4-byte Unicode text to Utf8EntryTest
>
> src/java.base/share/classes/jdk/internal/classfile/impl/ConcreteEntry.java line 58:
> 
>> 56: import jdk.internal.classfile.jdktypes.PackageDesc;
>> 57: 
>> 58: public abstract sealed class ConcreteEntry {
> 
> Why the name `concrete` ? Am I missing something (e.g. existence of "non-concrete" pool entries?)

XyzEntryImpl naming convention would be better, I'll adjust it.

> src/java.base/share/classes/jdk/internal/classfile/impl/DirectCodeBuilder.java line 658:
> 
>> 656:             mruParent = parent;
>> 657:             mruParentTable = table;
>> 658:             return mruParentTable[lab.getContextInfo()] - 1;
> 
> Am I correct that this code can misbehave e.g. if `computeIfAbsent` ends up creating a brand new `table` array - in which case, all array elements are set to `0` - meaning we end up returning `-1`. Is that what we want?

Yes, -1 indicates the label has not been resolved yet.

-------------

PR: https://git.openjdk.org/jdk/pull/10982

From asotona at openjdk.org  Tue Feb 28 16:25:25 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Tue, 28 Feb 2023 16:25:25 GMT
Subject: RFR: 8294982: Implementation of Classfile API [v20]
In-Reply-To: <01V72lRVYH7rB1NrPpkVKhvj1mksmrelMMTMrHFQ2hk=.4b2c22f3-d9c6-4778-be53-1fb055969f6a@github.com>
References: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
 <Gluemo5fFOPx_G6KtSgHxWEmiv3FFSTlxRHtc6ZPTuc=.6a2b6930-c7fd-4734-b21b-d2ccec1dabcf@github.com>
 <01V72lRVYH7rB1NrPpkVKhvj1mksmrelMMTMrHFQ2hk=.4b2c22f3-d9c6-4778-be53-1fb055969f6a@github.com>
Message-ID: <3ywCIdn2B1u8zBJqrwo97WEuDeuo4anQFScLoq5B85I=.f5140ddb-03d0-4bd2-9d87-be7e97a297dd@github.com>

On Thu, 16 Feb 2023 14:47:52 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   added 4-byte Unicode text to Utf8EntryTest
>
> src/java.base/share/classes/jdk/internal/classfile/impl/InstructionData.java line 47:
> 
>> 45:  * InstructionData
>> 46:  */
>> 47: public class InstructionData {
> 
> As CodeImpl seems to be the only client of this, I wonder if we could move the static cache in there?

yes, will fix it

> src/java.base/share/classes/jdk/internal/classfile/impl/LabelImpl.java line 65:
> 
>> 63: 
>> 64:     public int getContextInfo() {
>> 65:         return contextInfo;
> 
> This seems to be the BCI - should we change names to reflect that? (`contextInfo` seems very vague)

yes, will fix it

-------------

PR: https://git.openjdk.org/jdk/pull/10982

From bpb at openjdk.org  Tue Feb 28 17:14:10 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 28 Feb 2023 17:14:10 GMT
Subject: RFR: 8303175: (fs) Deprecate
 com.sun.nio.file.SensitivityWatchEventModifier for removal [v2]
In-Reply-To: <UwTYhNKsinnZDppqa0-ivzSLOnhYvYB1lQWojCVpH90=.c528101d-afd2-49dc-a5dd-b9891c39c1d7@github.com>
References: <s7IRC6buEQ5NrNc4XW3lIf6wpdfBksPrIjuTnTO99Gc=.380f3194-e6e7-4c55-b322-2fff1984cd4a@github.com>
 <mRL4BzPPcM-KIX3prN-P5REG13aES0ilBAJEPybK-Dk=.8302a2e9-80a5-46c2-8b13-4e2332d47b04@github.com>
 <UwTYhNKsinnZDppqa0-ivzSLOnhYvYB1lQWojCVpH90=.c528101d-afd2-49dc-a5dd-b9891c39c1d7@github.com>
Message-ID: <_d6lgOAEF0u6NsSe2BmzHVwvqVAiivndlFN8c5Z5pYI=.5bcbc290-ceab-431a-b54b-756789770014@github.com>

On Tue, 28 Feb 2023 11:24:59 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8303175: Move @deprecated above @since; tweak verbiage
>
> src/jdk.unsupported/share/classes/com/sun/nio/file/SensitivityWatchEventModifier.java line 40:
> 
>> 38:  * {@code WatchService} is used only on macOS and likely to be removed
>> 39:  * in a future release when a version based on the native file event
>> 40:  * notification facility becomes available.
> 
> I agree it's time to deprecate this extension but I think the reasoning will need a few rounds to get right. As background, JDK-8285956 changed the default sensitivity from medium to high in JDK 19 so the need to bump the sensitivity level (and thus reducing the polling interval) has mostly gone away. So maybe we should thinking about changing PollingWatchService it to ignore the these modifiers (like it is done with the native implementations). If we did that then it would be easy to word the deprecation text as it could just say that the modifier originally provided a hint to polling based WatchService implementations but is no longer used.

Should the suggested change to PollingWatchService be addressed in the context of this PR or separately?

-------------

PR: https://git.openjdk.org/jdk/pull/12746

From ethan at mccue.dev  Tue Feb 28 17:16:08 2023
From: ethan at mccue.dev (Ethan McCue)
Date: Tue, 28 Feb 2023 12:16:08 -0500
Subject: JEP-198 - Lets start talking about JSON
In-Reply-To: <CA+NR86i-m0-wq+Vdx8EXK1QLP-8eqamevCq5okz7t=j4LZswNA@mail.gmail.com>
References: <CA+NR86hGVP2F948jFH3qo7fDQsc-W6HP-1YK6LVSCJTL5yQ+mA@mail.gmail.com>
 <CAK6PxWPA9hVqsczSrPFr6cdWgedhfamVJL0OE8fqZd7uA6j9qA@mail.gmail.com>
 <CAGXNUvbsRiVYEZPVy9RG7gYJm+wy0wPL3Y=6_6qqPJ6ya9SMoQ@mail.gmail.com>
 <CA+NR86ixwVNMsJPkK8LUMavPy7Wxaa=EGCrJvxaqqf7r8sG3eg@mail.gmail.com>
 <CA+NR86gtkdF6D2mCu+jzgwopsrO5kjiBereRZUBScM4bctZwrg@mail.gmail.com>
 <CA+NR86i-m0-wq+Vdx8EXK1QLP-8eqamevCq5okz7t=j4LZswNA@mail.gmail.com>
Message-ID: <CA+NR86iiZb80dnzYE20BEYyO6QMQ+_7yY1ogYuj+fB4fxQoJiA@mail.gmail.com>

As an update to my character arc, I documented and wrote up an explanation
for the prototype library I was working on.[1]

And I've gotten a good deal of feedback on reddit[2] and in private.

I think its relevant to the conversation here in the sense of

- There are more of rzwitserloot's objections to read on the general
concept JSON as a built in.[3]
- There are a lot of well reasoned objections to the manner in which I am
interpreting a JSON tree, as well
as objections to the usage of a tree as the core. JEP 198's current writeup
(which I know is subject to a rewrite/retraction)
presumes that an immutable tree would be the core data structure.
- The peanut gallery might be interested in a "base" to implement whatever
their take on an API should be.

For that last category, I have a method-handle proxy written up for those
who want to try the "push parser into a pull parser"
transformation I alluded to in my first email of this thread.

[1]: https://mccue.dev/pages/2-26-23-json
[2]:
https://www.reddit.com/r/java/comments/11cyoh1/please_try_my_json_library/
[3]: Including one that reddit took down, but can be seen through reveddit
https://www.reveddit.com/y/rzwitserloot/?after=t1_jacpsj6&limit=1&sort=new&show=t1_jaa3x0q&removal_status=all

On Fri, Dec 16, 2022 at 6:23 PM Ethan McCue <ethan at mccue.dev> wrote:

> Sidenote about "Project Galahad" - I know Graal uses json for a few things
> including a reflection-config.json. Food for thought.
>
> > the java.util.log experiment shows that trying to ?core-librarize? needs
> that the community at large already fulfills with third party deps isn?t a
> good move,
>
> I, personally, do not have much historical context for java.util.log. What
> feels distinct about providing a JSON api is that
> logging is an implicitly global thing. If a JSON api doesn't fill all
> ecosystem niches, multiple can be used alongside
> each other.
>
> > The root issue with JSON is that you just can?t tell how to interpret
> any given JSON token
>
> The point where this could be an issue is numbers. Once something is
> identified as a number we can
>
> 1. Parse it immediately. Using a long and falling back to a BigInteger.
> For decimals its harder to know
> whether to use a double or BigDecimal internally. In the library I've been
> copy pasting from to build
> a prototype that last one is an explicit option and it defaults to doubles
> for the whole parse.
> 2. Store the string and parse it upon request. We can still model it as a
> Json.Number, but the
> work of interpreting is deferred.
>
> But in general, making a tree of json values doesn't particularly affect
> our ability to interpret it
> in a certain way. That interpretation is just positional. That's just as
> true as when making assertions
> in the form of class structure and field types as it is when making
> assertions in the form of code.[2]
>
>     record Thing(Instant a) {}
>
>     // vs.
>
>     Decoder.field(json, "a", a -> Instant.ofEpochSecond(Decoder.long_(a)))
>
> If anything, using a named type as a lookup key for a deserialization
> function is the less obvious
> way to do this.
>
> > I?m not sure how to square this circle
> > I don?t like the idea of shipping a non-data-binding JSON API in the
> core libs.
>
> I think the way to cube this rhombus is to find ways to like the idea of a
> non-data-binding JSON API. ?\_(?)_/?
>
> My personal journey with that is reaching its terminus here I think.
>
> Look on the bright side though - there are legit upsides to explicit tree
> plucking!
>
> Yeah, the friction per field is slightly higher, but the relative
> friction of custom types, or multiple construction methods for a
> particular type, or maintaining compatibility with
> legacy representations, or even just handling a top level list of things -
> its much lower.
>
> And all that complexity - that an instant is made by looking for a long or
> that it is parsed from a string in a
> particular format - it lives in Java code you can see, touch, feel and
> taste.
>
> I know "nobody does this"[2] but it's not that bad, actually.
>
> [1]: I do apologize for the code sketches consistently being "what I think
> an interaction with a tree api should look like."
> That is what I have been thinking about for a while so it's hard to resist.
> [2]: https://youtu.be/dOgfWXw9VrI?t=1225
>
> On Thu, Dec 15, 2022 at 6:34 PM Ethan McCue <ethan at mccue.dev> wrote:
>
>> > are pure JSON parsers really the go-to for most people?
>>
>> Depends on what you mean by JSON parsers and it depends on what you mean
>> by people.
>>
>> To the best of my knowledge, both python and Javascript do not include
>> streaming, databinding, or path navigation capabilities in their json
>> parsers.
>>
>>
>> On Thu, Dec 15, 2022 at 6:26 PM Ethan McCue <ethan at mccue.dev> wrote:
>>
>>> > The 95%+ use case for working with JSON for your average java coder is
>>> best done with data binding.
>>>
>>> To be brave yet controversial: I'm not sure this is neccesarily true.
>>>
>>> I will elaborate and respond to the other points after a hot cocoa, but
>>> the last point is part of why I think that tree-crawling needs _something_
>>> better as an API to fit the bill.
>>>
>>> With my sketch that set of requirements would be represented as
>>>
>>>     record Thing(
>>>         List<Long> xs
>>>     ) {
>>>         static Thing fromJson(Json json)
>>>             var defaultList = List.of(0L);
>>>             return new Thing(Decoder.optionalNullableField(
>>>                 json
>>>                 "xs",
>>>                 Decoder.oneOf(
>>>                     Decoder.array(Decoder.oneOf(
>>>                         x -> Long.parseLong(Decoder.string(x)),
>>>                         Decoder::long
>>>                     ))
>>>                     Decoder.null_(defaultList),
>>>                     x -> List.of(Decoder.long_(x))
>>>                 ),
>>>                 defaultList
>>>             ));
>>>         )
>>>     }
>>>
>>> Which isn't amazing at first glance, but also
>>>
>>>    {}
>>>    {"xs": null}
>>>    {"xs": 5}
>>>    {"xs": [5]}   {"xs": ["5"]}
>>>    {"xs": [1, "2", "3"]}
>>>
>>> these are some wildly varied structures. You could make a solid argument
>>> that something which silently treats these all the same is
>>> a bad API for all the reasons you would consider it a good one.
>>>
>>> On Thu, Dec 15, 2022 at 6:18 PM Johannes Lichtenberger <
>>> lichtenberger.johannes at gmail.com> wrote:
>>>
>>>> I'll have to read the whole thing, but are pure JSON parsers really the
>>>> go-to for most people? I'm a big advocate of providing also something
>>>> similar to XPath/XQuery and that's IMHO JSONiq (90% XQuery). I might be
>>>> biased, of course, as I'm working on Brackit[1] in my spare time (which is
>>>> also a query compiler and intended to be used with proven optimizations by
>>>> document stores / JSON stores), but also can be used as an in-memory query
>>>> engine.
>>>>
>>>> kind regards
>>>> Johannes
>>>>
>>>> [1] https://github.com/sirixdb/brackit
>>>>
>>>> Am Do., 15. Dez. 2022 um 23:03 Uhr schrieb Reinier Zwitserloot <
>>>> reinier at zwitserloot.com>:
>>>>
>>>>> A recent Advent-of-Code puzzle also made me double check the support
>>>>> of JSON in the java core libs and it is indeed a curious situation that the
>>>>> java core libs don?t cater to it particularly well.
>>>>>
>>>>> However, I?m not seeing an easy way forward to try to close this hole
>>>>> in the core library offerings.
>>>>>
>>>>> If you need to stream huge swaths of JSON, generally there?s a clear
>>>>> unit size that you can just databind. Something like:
>>>>>
>>>>> String jsonStr = """ { "version": 5, "data": [
>>>>>   -- 1 million relatively small records in this list --
>>>>>   ] } """;
>>>>>
>>>>>
>>>>> The usual swath of JSON parsers tend to support this (giving you a
>>>>> stream of java instances created by databinding those small records one by
>>>>> one), or if not, the best move forward is presumably to file a pull request
>>>>> with those projects; the java.util.log experiment shows that trying to
>>>>> ?core-librarize? needs that the community at large already fulfills with
>>>>> third party deps isn?t a good move, especially if the core library variant
>>>>> tries to oversimplify to avoid the trap of being too opinionated (which
>>>>> core libs shouldn?t be). In other words, the need for ?stream this JSON for
>>>>> me? style APIs is even more exotic that Ethan is suggesting.
>>>>>
>>>>> I see a fundamental problem here:
>>>>>
>>>>>
>>>>>    - The 95%+ use case for working with JSON for your average java
>>>>>    coder is best done with data binding.
>>>>>    - core libs doesn?t want to provide it, partly because it?s got a
>>>>>    large design space, partly because the field?s already covered by GSON and
>>>>>    Jackson-json; java.util.log proves this doesn?t work. At least, I gather
>>>>>    that?s what Ethan thinks and I agree with this assessment.
>>>>>    - A language that claims to be ?batteries included? that doesn?t
>>>>>    ship with a JSON parser in this era is dubious, to say the least.
>>>>>
>>>>>
>>>>> I?m not sure how to square this circle. Hence it feels like core-libs
>>>>> needs to hold some more fundamental debates first:
>>>>>
>>>>>
>>>>>    - Maybe it?s time to state in a more or less official decree that
>>>>>    well-established, large design space jobs will remain the purview of
>>>>>    dependencies no matter how popular it has, unless being part of the
>>>>>    core-libs adds something more fundamental the third party deps cannot bring
>>>>>    to the table (such as language integration), or the community standardizes
>>>>>    on a single library (JSR310?s story, more or less). JSON parsing would
>>>>>    qualify as ?well-established? (GSON and Jackson) and ?large design space?
>>>>>    as Ethan pointed out.
>>>>>    - Given that 99% of java projects, even really simple ones, start
>>>>>    with maven/gradle and a list of deps, is that really a problem?
>>>>>
>>>>>
>>>>> I?m honestly not sure what the right answer is. On one hand, the npm
>>>>> ecosystem seems to be doing very well even though their ?batteries
>>>>> included? situation is an utter shambles. Then again, the notion that your
>>>>> average nodejs project includes 10x+ more dependencies than other languages
>>>>> is likely a significant part of the security clown fiesta going on over
>>>>> there as far as 3rd party deps is concerned, so by no means should java
>>>>> just blindly emulate their solutions.
>>>>>
>>>>> I don?t like the idea of shipping a non-data-binding JSON API in the
>>>>> core libs. The root issue with JSON is that you just can?t tell how to
>>>>> interpret any given JSON token, because that?s not how JSON is used in
>>>>> practice. What does 5 mean? Could be that I?m to take that as an int,
>>>>> or as a double, or perhaps even as a j.t.Instant (epoch-millis), and
>>>>> defaulting behaviour (similar to j.u.Map?s .getOrDefault is *very*
>>>>> convenient to parse most JSON out there in the real world - omitting k/v
>>>>> pairs whose value is still on default is very common). That?s what makes
>>>>> those databind libraries so enticing: Instead of trying to pattern match my
>>>>> way into this behaviour:
>>>>>
>>>>>
>>>>>    - If the element isn?t there at all or null, give me a
>>>>>    list-of-longs with a single 0 in it.
>>>>>    - If the element is a number, make me a list-of-longs with 1 value
>>>>>    in it, that is that number, as long.
>>>>>    - If the element is a string, parse it into a long, then get me a
>>>>>    list with this one long value (because IEEE double rules mean sometimes you
>>>>>    have to put these things in string form or they get mangled by javascript-
>>>>>    eval style parsers).
>>>>>
>>>>>
>>>>> And yet the above is quite common, and can easily be done by a
>>>>> databinder, which sees you want a List<Long> for a field whose
>>>>> default value is List.of(1L), and, armed with that knowledge, can
>>>>> transit the JSON into java in that way.
>>>>>
>>>>> You don?t *need* databinding to cater to this idea: You could for
>>>>> example have a jsonNode.asLong(123) method that would parse a string
>>>>> if need be, even. But this has nothing to do with pattern matching either.
>>>>>
>>>>>  --Reinier Zwitserloot
>>>>>
>>>>>
>>>>> On 15 Dec 2022 at 21:30:17, Ethan McCue <ethan at mccue.dev> wrote:
>>>>>
>>>>>> I'm writing this to drive some forward motion and to nerd-snipe those
>>>>>> who know better than I do into putting their thoughts into words.
>>>>>>
>>>>>> There are three ways to process JSON[1]
>>>>>> - Streaming (Push or Pull)
>>>>>> - Traversing a Tree (Realized or Lazy)
>>>>>> - Declarative Databind (N ways)
>>>>>>
>>>>>> Of these, JEP-198 explicitly ruled out providing "JAXB style type
>>>>>> safe data binding."
>>>>>>
>>>>>> No justification is given, but if I had to insert my own: mapping the
>>>>>> Json model to/from the Java/JVM object model is a cursed combo of
>>>>>> - Huge possible design space
>>>>>> - Unpalatably large surface for backwards compatibility
>>>>>> - Serialization! Boo![2]
>>>>>>
>>>>>> So for an artifact like the JDK, it probably doesn't make sense to
>>>>>> include. That tracks.
>>>>>> It won't make everyone happy, people like databind APIs, but it
>>>>>> tracks.
>>>>>>
>>>>>> So for the "read flow" these are the things to figure out.
>>>>>>
>>>>>>                 | Should Provide? | Intended User(s) |
>>>>>> ----------------+-----------------+------------------+
>>>>>>  Streaming Push |                 |                  |
>>>>>> ----------------+-----------------+------------------+
>>>>>>  Streaming Pull |                 |                  |
>>>>>> ----------------+-----------------+------------------+
>>>>>>  Realized Tree  |                 |                  |
>>>>>> ----------------+-----------------+------------------+
>>>>>>  Lazy Tree      |                 |                  |
>>>>>> ----------------+-----------------+------------------+
>>>>>>
>>>>>> At which point, we should talk about what "meets needs of Java
>>>>>> developers using JSON" implies.
>>>>>>
>>>>>> JSON is ubiquitous. Most kinds of software us schmucks write could
>>>>>> have a reason to interact with it.
>>>>>> The full set of "user personas" therefore aren't practical for me to
>>>>>> talk about.[3]
>>>>>>
>>>>>> JSON documents, however, are not so varied.
>>>>>>
>>>>>> - There are small ones (1-10kb)
>>>>>> - There are medium ones (10-1000kb)
>>>>>> - There are big ones (1000kb-???)
>>>>>>
>>>>>> - There are shallow ones
>>>>>> - There are deep ones
>>>>>>
>>>>>> So that feels like an easier direction to talk about it from.
>>>>>>
>>>>>>
>>>>>> This repo[4] has some convenient toy examples of how some of those
>>>>>> APIs look in libraries
>>>>>> in the ecosystem. Specifically the Streaming Pull and Realized Tree
>>>>>> models.
>>>>>>
>>>>>>         User r = new User();
>>>>>>         while (true) {
>>>>>>             JsonToken token = reader.peek();
>>>>>>             switch (token) {
>>>>>>                 case BEGIN_OBJECT:
>>>>>>                     reader.beginObject();
>>>>>>                     break;
>>>>>>                 case END_OBJECT:
>>>>>>                     reader.endObject();
>>>>>>                     return r;
>>>>>>                 case NAME:
>>>>>>                     String fieldname = reader.nextName();
>>>>>>                     switch (fieldname) {
>>>>>>                         case "id":
>>>>>>                             r.setId(reader.nextString());
>>>>>>                             break;
>>>>>>                         case "index":
>>>>>>                             r.setIndex(reader.nextInt());
>>>>>>                             break;
>>>>>>                         ...
>>>>>>                         case "friends":
>>>>>>                             r.setFriends(new ArrayList<>());
>>>>>>                             Friend f = null;
>>>>>>                             carryOn = true;
>>>>>>                             while (carryOn) {
>>>>>>                                 token = reader.peek();
>>>>>>                                 switch (token) {
>>>>>>                                     case BEGIN_ARRAY:
>>>>>>                                         reader.beginArray();
>>>>>>                                         break;
>>>>>>                                     case END_ARRAY:
>>>>>>                                         reader.endArray();
>>>>>>                                         carryOn = false;
>>>>>>                                         break;
>>>>>>                                     case BEGIN_OBJECT:
>>>>>>                                         reader.beginObject();
>>>>>>                                         f = new Friend();
>>>>>>                                         break;
>>>>>>                                     case END_OBJECT:
>>>>>>                                         reader.endObject();
>>>>>>                                         r.getFriends().add(f);
>>>>>>                                         break;
>>>>>>                                     case NAME:
>>>>>>                                         String fn = reader.nextName();
>>>>>>                                         switch (fn) {
>>>>>>                                             case "id":
>>>>>>
>>>>>> f.setId(reader.nextString());
>>>>>>                                                 break;
>>>>>>                                             case "name":
>>>>>>
>>>>>> f.setName(reader.nextString());
>>>>>>                                                 break;
>>>>>>                                         }
>>>>>>                                         break;
>>>>>>                                 }
>>>>>>                             }
>>>>>>                             break;
>>>>>>                     }
>>>>>>             }
>>>>>>
>>>>>> I think its not hard to argue that the streaming apis are brutalist.
>>>>>> The above is Gson, but Jackson, moshi, etc
>>>>>> seem at least morally equivalent.
>>>>>>
>>>>>> Its hard to write, hard to write *correctly*, and theres is a curious
>>>>>> protensity towards pairing it
>>>>>> with anemic, mutable models.
>>>>>>
>>>>>> That being said, it handles big documents and deep documents really
>>>>>> well. It also performs
>>>>>> pretty darn well and is good enough as a "fallback" when the intended
>>>>>> user experience
>>>>>> is through something like databind.
>>>>>>
>>>>>> So what could we do meaningfully better with the language we have
>>>>>> today/will have tommorow?
>>>>>>
>>>>>> - Sealed interfaces + Pattern matching could give a nicer model for
>>>>>> tokens
>>>>>>
>>>>>>         sealed interface JsonToken {
>>>>>>             record Field(String name) implements JsonToken {}
>>>>>>             record BeginArray() implements JsonToken {}
>>>>>>             record EndArray() implements JsonToken {}
>>>>>>             record BeginObject() implements JsonToken {}
>>>>>>             record EndObject() implements JsonToken {}
>>>>>>             // ...
>>>>>>         }
>>>>>>
>>>>>>         // ...
>>>>>>
>>>>>>         User r = new User();
>>>>>>         while (true) {
>>>>>>             JsonToken token = reader.peek();
>>>>>>             switch (token) {
>>>>>>                 case BeginObject __:
>>>>>>                     reader.beginObject();
>>>>>>                     break;
>>>>>>                 case EndObject __:
>>>>>>                     reader.endObject();
>>>>>>                     return r;
>>>>>>                 case Field("id"):
>>>>>>                     r.setId(reader.nextString());
>>>>>>                     break;
>>>>>>                 case Field("index"):
>>>>>>                     r.setIndex(reader.nextInt());
>>>>>>                     break;
>>>>>>
>>>>>>                 // ...
>>>>>>
>>>>>>                 case Field("friends"):
>>>>>>                     r.setFriends(new ArrayList<>());
>>>>>>                     Friend f = null;
>>>>>>                     carryOn = true;
>>>>>>                     while (carryOn) {
>>>>>>                         token = reader.peek();
>>>>>>                         switch (token) {
>>>>>>                 // ...
>>>>>>
>>>>>> - Value classes can make it all more efficient
>>>>>>
>>>>>>         sealed interface JsonToken {
>>>>>>             value record Field(String name) implements JsonToken {}
>>>>>>             value record BeginArray() implements JsonToken {}
>>>>>>             value record EndArray() implements JsonToken {}
>>>>>>             value record BeginObject() implements JsonToken {}
>>>>>>             value record EndObject() implements JsonToken {}
>>>>>>             // ...
>>>>>>         }
>>>>>>
>>>>>> - (Fun One) We can transform a simpler-to-write push parser into a
>>>>>> pull parser with Coroutines
>>>>>>
>>>>>>     This is just a toy we could play with while making something in
>>>>>> the JDK. I'm pretty sure
>>>>>>     we could make a parser which feeds into something like
>>>>>>
>>>>>>         interface Listener {
>>>>>>             void onObjectStart();
>>>>>>             void onObjectEnd();
>>>>>>             void onArrayStart();
>>>>>>             void onArrayEnd();
>>>>>>             void onField(String name);
>>>>>>             // ...
>>>>>>         }
>>>>>>
>>>>>>     and invert a loop like
>>>>>>
>>>>>>         while (true) {
>>>>>>             char c = next();
>>>>>>             switch (c) {
>>>>>>                 case '{':
>>>>>>                     listener.onObjectStart();
>>>>>>                     // ...
>>>>>>                 // ...
>>>>>>             }
>>>>>>         }
>>>>>>
>>>>>>     by putting a Coroutine.yield in the callback.
>>>>>>
>>>>>>     That might be a meaningful simplification in code structure, I
>>>>>> don't know enough to say.
>>>>>>
>>>>>> But, I think there are some hard questions like
>>>>>>
>>>>>> - Is the intent[5] to be make backing parser for ecosystem databind
>>>>>> apis?
>>>>>> - Is the intent that users who want to handle big/deep documents fall
>>>>>> back to this?
>>>>>> - Are those new language features / conveniences enough to offset the
>>>>>> cost of committing to a new api?
>>>>>> - To whom exactly does a low level api provide value?
>>>>>> - What benefit is standardization in the JDK?
>>>>>>
>>>>>> and just generally - who would be the consumer(s) of this?
>>>>>>
>>>>>> The other kind of API still on the table is a Tree. There are two
>>>>>> ways to handle this
>>>>>>
>>>>>> 1. Load it into `Object`. Use a bunch of instanceof checks/casts to
>>>>>> confirm what it actually is.
>>>>>>
>>>>>>         Object v;
>>>>>>         User u = new User();
>>>>>>
>>>>>>         if ((v = jso.get("id")) != null) {
>>>>>>             u.setId((String) v);
>>>>>>         }
>>>>>>         if ((v = jso.get("index")) != null) {
>>>>>>             u.setIndex(((Long) v).intValue());
>>>>>>         }
>>>>>>         if ((v = jso.get("guid")) != null) {
>>>>>>             u.setGuid((String) v);
>>>>>>         }
>>>>>>         if ((v = jso.get("isActive")) != null) {
>>>>>>             u.setIsActive(((Boolean) v));
>>>>>>         }
>>>>>>         if ((v = jso.get("balance")) != null) {
>>>>>>             u.setBalance((String) v);
>>>>>>         }
>>>>>>         // ...
>>>>>>         if ((v = jso.get("latitude")) != null) {
>>>>>>             u.setLatitude(v instanceof BigDecimal ? ((BigDecimal)
>>>>>> v).doubleValue() : (Double) v);
>>>>>>         }
>>>>>>         if ((v = jso.get("longitude")) != null) {
>>>>>>             u.setLongitude(v instanceof BigDecimal ? ((BigDecimal)
>>>>>> v).doubleValue() : (Double) v);
>>>>>>         }
>>>>>>         if ((v = jso.get("greeting")) != null) {
>>>>>>             u.setGreeting((String) v);
>>>>>>         }
>>>>>>         if ((v = jso.get("favoriteFruit")) != null) {
>>>>>>             u.setFavoriteFruit((String) v);
>>>>>>         }
>>>>>>         if ((v = jso.get("tags")) != null) {
>>>>>>             List<Object> jsonarr = (List<Object>) v;
>>>>>>             u.setTags(new ArrayList<>());
>>>>>>             for (Object vi : jsonarr) {
>>>>>>                 u.getTags().add((String) vi);
>>>>>>             }
>>>>>>         }
>>>>>>         if ((v = jso.get("friends")) != null) {
>>>>>>             List<Object> jsonarr = (List<Object>) v;
>>>>>>             u.setFriends(new ArrayList<>());
>>>>>>             for (Object vi : jsonarr) {
>>>>>>                 Map<String, Object> jso0 = (Map<String, Object>) vi;
>>>>>>                 Friend f = new Friend();
>>>>>>                 f.setId((String) jso0.get("id"));
>>>>>>                 f.setName((String) jso0.get("name"));
>>>>>>                 u.getFriends().add(f);
>>>>>>             }
>>>>>>         }
>>>>>>
>>>>>> 2. Have an explicit model for Json, and helper methods that do said
>>>>>> casts[6]
>>>>>>
>>>>>>
>>>>>> this.setSiteSetting(readFromJson(jsonObject.getJsonObject("site")));
>>>>>> JsonArray groups = jsonObject.getJsonArray("group");
>>>>>> if(groups != null)
>>>>>> {
>>>>>> int len = groups.size();
>>>>>> for(int i=0; i<len; i++)
>>>>>> {
>>>>>> JsonObject grp = groups.getJsonObject(i);
>>>>>> SNMPSetting grpSetting = readFromJson(grp);
>>>>>> String grpName = grp.getString("dbgroup", null);
>>>>>> if(grpName != null && grpSetting != null)
>>>>>> this.groupSettings.put(grpName, grpSetting);
>>>>>> }
>>>>>> }
>>>>>> JsonArray hosts = jsonObject.getJsonArray("host");
>>>>>> if(hosts != null)
>>>>>> {
>>>>>> int len = hosts.size();
>>>>>> for(int i=0; i<len; i++)
>>>>>> {
>>>>>> JsonObject host = hosts.getJsonObject(i);
>>>>>> SNMPSetting hostSetting = readFromJson(host);
>>>>>> String hostName = host.getString("dbhost", null);
>>>>>> if(hostName != null && hostSetting != null)
>>>>>> this.hostSettings.put(hostName, hostSetting);
>>>>>> }
>>>>>> }
>>>>>>
>>>>>> I think what has become easier to represent in the language nowadays
>>>>>> is that explicit model for Json.
>>>>>> Its the 101 lesson of sealed interfaces.[7] It feels nice and clean.
>>>>>>
>>>>>>         sealed interface Json {
>>>>>>             final class Null implements Json {}
>>>>>>             final class True implements Json {}
>>>>>>             final class False implements Json {}
>>>>>>             final class Array implements Json {}
>>>>>>             final class Object implements Json {}
>>>>>>             final class String implements Json {}
>>>>>>             final class Number implements Json {}
>>>>>>         }
>>>>>>
>>>>>> And the cast-and-check approach is now more viable on account of
>>>>>> pattern matching.
>>>>>>
>>>>>>         if (jso.get("id") instanceof String v) {
>>>>>>             u.setId(v);
>>>>>>         }
>>>>>>         if (jso.get("index") instanceof Long v) {
>>>>>>             u.setIndex(v.intValue());
>>>>>>         }
>>>>>>         if (jso.get("guid") instanceof String v) {
>>>>>>             u.setGuid(v);
>>>>>>         }
>>>>>>
>>>>>>         // or
>>>>>>
>>>>>>         if (jso.get("id") instanceof String id &&
>>>>>>                 jso.get("index") instanceof Long index &&
>>>>>>                 jso.get("guid") instanceof String guid) {
>>>>>>             return new User(id, index, guid, ...); // look ma, no
>>>>>> setters!
>>>>>>         }
>>>>>>
>>>>>>
>>>>>> And on the horizon, again, is value types.
>>>>>>
>>>>>> But there are problems with this approach beyond the performance
>>>>>> implications of loading into
>>>>>> a tree.
>>>>>>
>>>>>> For one, all the code samples above have different behaviors around
>>>>>> null keys and missing keys
>>>>>> that are not obvious from first glance.
>>>>>>
>>>>>> This won't accept any null or missing fields
>>>>>>
>>>>>>         if (jso.get("id") instanceof String id &&
>>>>>>                 jso.get("index") instanceof Long index &&
>>>>>>                 jso.get("guid") instanceof String guid) {
>>>>>>             return new User(id, index, guid, ...);
>>>>>>         }
>>>>>>
>>>>>> This will accept individual null or missing fields, but also will
>>>>>> silently ignore
>>>>>> fields with incorrect types
>>>>>>
>>>>>>         if (jso.get("id") instanceof String v) {
>>>>>>             u.setId(v);
>>>>>>         }
>>>>>>         if (jso.get("index") instanceof Long v) {
>>>>>>             u.setIndex(v.intValue());
>>>>>>         }
>>>>>>         if (jso.get("guid") instanceof String v) {
>>>>>>             u.setGuid(v);
>>>>>>         }
>>>>>>
>>>>>> And, compared to databind where there is information about the
>>>>>> expected structure of the document
>>>>>> and its the job of the framework to assert that, I posit that the
>>>>>> errors that would be encountered
>>>>>> when writing code against this would be more like
>>>>>>
>>>>>>     "something wrong with user"
>>>>>>
>>>>>> than
>>>>>>
>>>>>>     "problem at users[5].name, expected string or null. got 5"
>>>>>>
>>>>>> Which feels unideal.
>>>>>>
>>>>>>
>>>>>> One approach I find promising is something close to what Elm does
>>>>>> with its decoders[8]. Not just combining assertion
>>>>>> and binding like what pattern matching with records allows, but
>>>>>> including a scheme for bubbling/nesting errors.
>>>>>>
>>>>>>     static String string(Json json) throws JsonDecodingException {
>>>>>>         if (!(json instanceof Json.String jsonString)) {
>>>>>>             throw JsonDecodingException.of(
>>>>>>                     "expected a string",
>>>>>>                     json
>>>>>>             );
>>>>>>         } else {
>>>>>>             return jsonString.value();
>>>>>>         }
>>>>>>     }
>>>>>>
>>>>>>     static <T> T field(Json json, String fieldName, Decoder<? extends
>>>>>> T> valueDecoder) throws JsonDecodingException {
>>>>>>         var jsonObject = object(json);
>>>>>>         var value = jsonObject.get(fieldName);
>>>>>>         if (value == null) {
>>>>>>             throw JsonDecodingException.atField(
>>>>>>                     fieldName,
>>>>>>                     JsonDecodingException.of(
>>>>>>                             "no value for field",
>>>>>>                             json
>>>>>>                     )
>>>>>>             );
>>>>>>         }
>>>>>>         else {
>>>>>>             try {
>>>>>>                 return valueDecoder.decode(value);
>>>>>>             } catch (JsonDecodingException e) {
>>>>>>                 throw JsonDecodingException.atField(
>>>>>>                         fieldName,
>>>>>>                         e
>>>>>>                 );
>>>>>>             }  catch (Exception e) {
>>>>>>                 throw JsonDecodingException.atField(fieldName,
>>>>>> JsonDecodingException.of(e, value));
>>>>>>             }
>>>>>>         }
>>>>>>     }
>>>>>>
>>>>>> Which I think has some benefits over the ways I've seen of working
>>>>>> with trees.
>>>>>>
>>>>>>
>>>>>>
>>>>>> - It is declarative enough that folks who prefer databind might be
>>>>>> happy enough.
>>>>>>
>>>>>>         static User fromJson(Json json) {
>>>>>>             return new User(
>>>>>>                 Decoder.field(json, "id", Decoder::string),
>>>>>>                 Decoder.field(json, "index", Decoder::long_),
>>>>>>                 Decoder.field(json, "guid", Decoder::string),
>>>>>>             );
>>>>>>         }
>>>>>>
>>>>>>         / ...
>>>>>>
>>>>>>         List<User> users = Decoders.array(json, User::fromJson);
>>>>>>
>>>>>> - Handling null and optional fields could be less easily conflated
>>>>>>
>>>>>>     Decoder.field(json, "id", Decoder::string);
>>>>>>
>>>>>>     Decoder.nullableField(json, "id", Decoder::string);
>>>>>>
>>>>>>     Decoder.optionalField(json, "id", Decoder::string);
>>>>>>
>>>>>>     Decoder.optionalNullableField(json, "id", Decoder::string);
>>>>>>
>>>>>>
>>>>>> - It composes well with user defined classes
>>>>>>
>>>>>>     record Guid(String value) {
>>>>>>         Guid {
>>>>>>             // some assertions on the structure of value
>>>>>>         }
>>>>>>     }
>>>>>>
>>>>>>     Decoder.string(json, "guid", guid -> new
>>>>>> Guid(Decoder.string(guid)));
>>>>>>
>>>>>>     // or even
>>>>>>
>>>>>>     record Guid(String value) {
>>>>>>         Guid {
>>>>>>             // some assertions on the structure of value
>>>>>>         }
>>>>>>
>>>>>>         static Guid fromJson(Json json) {
>>>>>>             return new Guid(Decoder.string(guid));
>>>>>>         }
>>>>>>     }
>>>>>>
>>>>>>     Decoder.string(json, "guid", Guid::fromJson);
>>>>>>
>>>>>>
>>>>>> - When something goes wrong, the API can handle the fiddlyness of
>>>>>> capturing information for feedback.
>>>>>>
>>>>>>     In the code I've sketched out its just what field/index things
>>>>>> went wrong at. Potentially
>>>>>>     capturing metadata like row/col numbers of the source would be
>>>>>> sensible too.
>>>>>>
>>>>>>     Its just not reasonable to expect devs to do extra work to get
>>>>>> that and its really nice to give it.
>>>>>>
>>>>>> There are also some downsides like
>>>>>>
>>>>>> -  I do not know how compatible it would be with lazy trees.
>>>>>>
>>>>>>      Lazy trees being the only way that a tree api could handle big
>>>>>> or deep documents.
>>>>>>      The general concept as applied in libraries like json-tree[9] is
>>>>>> to navigate without
>>>>>>      doing any work, and that clashes with wanting to instanceof
>>>>>> check the info at the
>>>>>>      current path.
>>>>>>
>>>>>> - It *almost* gives enough information to be a general schema approach
>>>>>>
>>>>>>     If one field fails, that in the model throws an exception
>>>>>> immediately. If an API should
>>>>>>     return "errors": [...], that is inconvenient to construct.
>>>>>>
>>>>>> - None of the existing popular libraries are doing this
>>>>>>
>>>>>>      The only mechanics that are strictly required to give this sort
>>>>>> of API is lambdas. Those have
>>>>>>      been out for a decade. Yes sealed interfaces make the data model
>>>>>> prettier but in concept you
>>>>>>      can build the same thing on top of anything.
>>>>>>
>>>>>>      I could argue that this is because of "cultural momentum" of
>>>>>> databind or some other reason,
>>>>>>      but the fact remains that it isn't a proven out approach.
>>>>>>
>>>>>>      Writing Json libraries is a todo list[10]. There are a lot of
>>>>>> bad ideas and this might be one of the,
>>>>>>
>>>>>> - Performance impact of so many instanceof checks
>>>>>>
>>>>>>     I've gotten a 4.2% slowdown compared to the "regular" tree code
>>>>>> without the repeated casts.
>>>>>>
>>>>>>     But that was with a parser that is 5x slower than Jacksons.
>>>>>> (using the same benchmark project as for the snippets).
>>>>>>     I think there could be reason to believe that the JIT does well
>>>>>> enough with repeated instanceof
>>>>>>     checks to consider it.
>>>>>>
>>>>>>
>>>>>> My current thinking is that - despite not solving for large or deep
>>>>>> documents - starting with a really "dumb" realized tree api
>>>>>> might be the right place to start for the read side of a potential
>>>>>> incubator module.
>>>>>>
>>>>>> But regardless - this feels like a good time to start more concrete
>>>>>> conversations. I fell I should cap this email since I've reached the point
>>>>>> of decoherence and haven't even mentioned the write side of things
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> [1]: http://www.cowtowncoder.com/blog/archives/2009/01/entry_131.html
>>>>>> [2]: https://security.snyk.io/vuln/maven?search=jackson-databind
>>>>>> [3]: I only know like 8 people
>>>>>> [4]:
>>>>>> https://github.com/fabienrenaud/java-json-benchmark/blob/master/src/main/java/com/github/fabienrenaud/jjb/stream/UsersStreamDeserializer.java
>>>>>> [5]: When I say "intent", I do so knowing full well no one has been
>>>>>> actively thinking of this for an entire Game of Thrones
>>>>>> [6]:
>>>>>> https://github.com/yahoo/mysql_perf_analyzer/blob/master/myperf/src/main/java/com/yahoo/dba/perf/myperf/common/SNMPSettings.java
>>>>>> [7]: https://www.infoq.com/articles/data-oriented-programming-java/
>>>>>> [8]:
>>>>>> https://package.elm-lang.org/packages/elm/json/latest/Json-Decode
>>>>>> [9]: https://github.com/jbee/json-tree
>>>>>> [10]: https://stackoverflow.com/a/14442630/2948173
>>>>>> [11]: In 30 days JEP-198 it will be recognizably PI days old for the
>>>>>> 2nd time in its history.
>>>>>> [12]: To me, the fact that is still an open JEP is more a social
>>>>>> convenience than anything. I could just as easily writing this exact same
>>>>>> email about TOML.
>>>>>>
>>>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20230228/bc002f42/attachment-0001.htm>

From ethan at mccue.dev  Tue Feb 28 17:17:12 2023
From: ethan at mccue.dev (Ethan McCue)
Date: Tue, 28 Feb 2023 12:17:12 -0500
Subject: JEP-198 - Lets start talking about JSON
In-Reply-To: <CA+NR86iiZb80dnzYE20BEYyO6QMQ+_7yY1ogYuj+fB4fxQoJiA@mail.gmail.com>
References: <CA+NR86hGVP2F948jFH3qo7fDQsc-W6HP-1YK6LVSCJTL5yQ+mA@mail.gmail.com>
 <CAK6PxWPA9hVqsczSrPFr6cdWgedhfamVJL0OE8fqZd7uA6j9qA@mail.gmail.com>
 <CAGXNUvbsRiVYEZPVy9RG7gYJm+wy0wPL3Y=6_6qqPJ6ya9SMoQ@mail.gmail.com>
 <CA+NR86ixwVNMsJPkK8LUMavPy7Wxaa=EGCrJvxaqqf7r8sG3eg@mail.gmail.com>
 <CA+NR86gtkdF6D2mCu+jzgwopsrO5kjiBereRZUBScM4bctZwrg@mail.gmail.com>
 <CA+NR86i-m0-wq+Vdx8EXK1QLP-8eqamevCq5okz7t=j4LZswNA@mail.gmail.com>
 <CA+NR86iiZb80dnzYE20BEYyO6QMQ+_7yY1ogYuj+fB4fxQoJiA@mail.gmail.com>
Message-ID: <CA+NR86h=dDA7X=xY45BWKSET0o1BxZySKDLKwYT2XAj=-WDeTg@mail.gmail.com>

Link to the proxy which I forgot to include

https://gist.github.com/bowbahdoe/eb29d172351162408eab5e4ee9d84fec

On Tue, Feb 28, 2023 at 12:16 PM Ethan McCue <ethan at mccue.dev> wrote:

> As an update to my character arc, I documented and wrote up an explanation
> for the prototype library I was working on.[1]
>
> And I've gotten a good deal of feedback on reddit[2] and in private.
>
> I think its relevant to the conversation here in the sense of
>
> - There are more of rzwitserloot's objections to read on the general
> concept JSON as a built in.[3]
> - There are a lot of well reasoned objections to the manner in which I am
> interpreting a JSON tree, as well
> as objections to the usage of a tree as the core. JEP 198's current
> writeup (which I know is subject to a rewrite/retraction)
> presumes that an immutable tree would be the core data structure.
> - The peanut gallery might be interested in a "base" to implement whatever
> their take on an API should be.
>
> For that last category, I have a method-handle proxy written up for those
> who want to try the "push parser into a pull parser"
> transformation I alluded to in my first email of this thread.
>
> [1]: https://mccue.dev/pages/2-26-23-json
> [2]:
> https://www.reddit.com/r/java/comments/11cyoh1/please_try_my_json_library/
> [3]: Including one that reddit took down, but can be seen through reveddit
> https://www.reveddit.com/y/rzwitserloot/?after=t1_jacpsj6&limit=1&sort=new&show=t1_jaa3x0q&removal_status=all
>
> On Fri, Dec 16, 2022 at 6:23 PM Ethan McCue <ethan at mccue.dev> wrote:
>
>> Sidenote about "Project Galahad" - I know Graal uses json for a few
>> things including a reflection-config.json. Food for thought.
>>
>> > the java.util.log experiment shows that trying to ?core-librarize?
>> needs that the community at large already fulfills with third party deps
>> isn?t a good move,
>>
>> I, personally, do not have much historical context for java.util.log.
>> What feels distinct about providing a JSON api is that
>> logging is an implicitly global thing. If a JSON api doesn't fill all
>> ecosystem niches, multiple can be used alongside
>> each other.
>>
>> > The root issue with JSON is that you just can?t tell how to interpret
>> any given JSON token
>>
>> The point where this could be an issue is numbers. Once something is
>> identified as a number we can
>>
>> 1. Parse it immediately. Using a long and falling back to a BigInteger.
>> For decimals its harder to know
>> whether to use a double or BigDecimal internally. In the library I've
>> been copy pasting from to build
>> a prototype that last one is an explicit option and it defaults to
>> doubles for the whole parse.
>> 2. Store the string and parse it upon request. We can still model it as a
>> Json.Number, but the
>> work of interpreting is deferred.
>>
>> But in general, making a tree of json values doesn't particularly affect
>> our ability to interpret it
>> in a certain way. That interpretation is just positional. That's just as
>> true as when making assertions
>> in the form of class structure and field types as it is when making
>> assertions in the form of code.[2]
>>
>>     record Thing(Instant a) {}
>>
>>     // vs.
>>
>>     Decoder.field(json, "a", a -> Instant.ofEpochSecond(Decoder.long_(a)))
>>
>> If anything, using a named type as a lookup key for a deserialization
>> function is the less obvious
>> way to do this.
>>
>> > I?m not sure how to square this circle
>> > I don?t like the idea of shipping a non-data-binding JSON API in the
>> core libs.
>>
>> I think the way to cube this rhombus is to find ways to like the idea of
>> a non-data-binding JSON API. ?\_(?)_/?
>>
>> My personal journey with that is reaching its terminus here I think.
>>
>> Look on the bright side though - there are legit upsides to explicit tree
>> plucking!
>>
>> Yeah, the friction per field is slightly higher, but the relative
>> friction of custom types, or multiple construction methods for a
>> particular type, or maintaining compatibility with
>> legacy representations, or even just handling a top level list of things
>> - its much lower.
>>
>> And all that complexity - that an instant is made by looking for a long
>> or that it is parsed from a string in a
>> particular format - it lives in Java code you can see, touch, feel and
>> taste.
>>
>> I know "nobody does this"[2] but it's not that bad, actually.
>>
>> [1]: I do apologize for the code sketches consistently being "what I
>> think an interaction with a tree api should look like."
>> That is what I have been thinking about for a while so it's hard to
>> resist.
>> [2]: https://youtu.be/dOgfWXw9VrI?t=1225
>>
>> On Thu, Dec 15, 2022 at 6:34 PM Ethan McCue <ethan at mccue.dev> wrote:
>>
>>> > are pure JSON parsers really the go-to for most people?
>>>
>>> Depends on what you mean by JSON parsers and it depends on what you mean
>>> by people.
>>>
>>> To the best of my knowledge, both python and Javascript do not include
>>> streaming, databinding, or path navigation capabilities in their json
>>> parsers.
>>>
>>>
>>> On Thu, Dec 15, 2022 at 6:26 PM Ethan McCue <ethan at mccue.dev> wrote:
>>>
>>>> > The 95%+ use case for working with JSON for your average java coder
>>>> is best done with data binding.
>>>>
>>>> To be brave yet controversial: I'm not sure this is neccesarily true.
>>>>
>>>> I will elaborate and respond to the other points after a hot cocoa, but
>>>> the last point is part of why I think that tree-crawling needs _something_
>>>> better as an API to fit the bill.
>>>>
>>>> With my sketch that set of requirements would be represented as
>>>>
>>>>     record Thing(
>>>>         List<Long> xs
>>>>     ) {
>>>>         static Thing fromJson(Json json)
>>>>             var defaultList = List.of(0L);
>>>>             return new Thing(Decoder.optionalNullableField(
>>>>                 json
>>>>                 "xs",
>>>>                 Decoder.oneOf(
>>>>                     Decoder.array(Decoder.oneOf(
>>>>                         x -> Long.parseLong(Decoder.string(x)),
>>>>                         Decoder::long
>>>>                     ))
>>>>                     Decoder.null_(defaultList),
>>>>                     x -> List.of(Decoder.long_(x))
>>>>                 ),
>>>>                 defaultList
>>>>             ));
>>>>         )
>>>>     }
>>>>
>>>> Which isn't amazing at first glance, but also
>>>>
>>>>    {}
>>>>    {"xs": null}
>>>>    {"xs": 5}
>>>>    {"xs": [5]}   {"xs": ["5"]}
>>>>    {"xs": [1, "2", "3"]}
>>>>
>>>> these are some wildly varied structures. You could make a solid
>>>> argument that something which silently treats these all the same is
>>>> a bad API for all the reasons you would consider it a good one.
>>>>
>>>> On Thu, Dec 15, 2022 at 6:18 PM Johannes Lichtenberger <
>>>> lichtenberger.johannes at gmail.com> wrote:
>>>>
>>>>> I'll have to read the whole thing, but are pure JSON parsers really
>>>>> the go-to for most people? I'm a big advocate of providing also something
>>>>> similar to XPath/XQuery and that's IMHO JSONiq (90% XQuery). I might be
>>>>> biased, of course, as I'm working on Brackit[1] in my spare time (which is
>>>>> also a query compiler and intended to be used with proven optimizations by
>>>>> document stores / JSON stores), but also can be used as an in-memory query
>>>>> engine.
>>>>>
>>>>> kind regards
>>>>> Johannes
>>>>>
>>>>> [1] https://github.com/sirixdb/brackit
>>>>>
>>>>> Am Do., 15. Dez. 2022 um 23:03 Uhr schrieb Reinier Zwitserloot <
>>>>> reinier at zwitserloot.com>:
>>>>>
>>>>>> A recent Advent-of-Code puzzle also made me double check the support
>>>>>> of JSON in the java core libs and it is indeed a curious situation that the
>>>>>> java core libs don?t cater to it particularly well.
>>>>>>
>>>>>> However, I?m not seeing an easy way forward to try to close this hole
>>>>>> in the core library offerings.
>>>>>>
>>>>>> If you need to stream huge swaths of JSON, generally there?s a clear
>>>>>> unit size that you can just databind. Something like:
>>>>>>
>>>>>> String jsonStr = """ { "version": 5, "data": [
>>>>>>   -- 1 million relatively small records in this list --
>>>>>>   ] } """;
>>>>>>
>>>>>>
>>>>>> The usual swath of JSON parsers tend to support this (giving you a
>>>>>> stream of java instances created by databinding those small records one by
>>>>>> one), or if not, the best move forward is presumably to file a pull request
>>>>>> with those projects; the java.util.log experiment shows that trying to
>>>>>> ?core-librarize? needs that the community at large already fulfills with
>>>>>> third party deps isn?t a good move, especially if the core library variant
>>>>>> tries to oversimplify to avoid the trap of being too opinionated (which
>>>>>> core libs shouldn?t be). In other words, the need for ?stream this JSON for
>>>>>> me? style APIs is even more exotic that Ethan is suggesting.
>>>>>>
>>>>>> I see a fundamental problem here:
>>>>>>
>>>>>>
>>>>>>    - The 95%+ use case for working with JSON for your average java
>>>>>>    coder is best done with data binding.
>>>>>>    - core libs doesn?t want to provide it, partly because it?s got a
>>>>>>    large design space, partly because the field?s already covered by GSON and
>>>>>>    Jackson-json; java.util.log proves this doesn?t work. At least, I gather
>>>>>>    that?s what Ethan thinks and I agree with this assessment.
>>>>>>    - A language that claims to be ?batteries included? that doesn?t
>>>>>>    ship with a JSON parser in this era is dubious, to say the least.
>>>>>>
>>>>>>
>>>>>> I?m not sure how to square this circle. Hence it feels like core-libs
>>>>>> needs to hold some more fundamental debates first:
>>>>>>
>>>>>>
>>>>>>    - Maybe it?s time to state in a more or less official decree that
>>>>>>    well-established, large design space jobs will remain the purview of
>>>>>>    dependencies no matter how popular it has, unless being part of the
>>>>>>    core-libs adds something more fundamental the third party deps cannot bring
>>>>>>    to the table (such as language integration), or the community standardizes
>>>>>>    on a single library (JSR310?s story, more or less). JSON parsing would
>>>>>>    qualify as ?well-established? (GSON and Jackson) and ?large design space?
>>>>>>    as Ethan pointed out.
>>>>>>    - Given that 99% of java projects, even really simple ones, start
>>>>>>    with maven/gradle and a list of deps, is that really a problem?
>>>>>>
>>>>>>
>>>>>> I?m honestly not sure what the right answer is. On one hand, the npm
>>>>>> ecosystem seems to be doing very well even though their ?batteries
>>>>>> included? situation is an utter shambles. Then again, the notion that your
>>>>>> average nodejs project includes 10x+ more dependencies than other languages
>>>>>> is likely a significant part of the security clown fiesta going on over
>>>>>> there as far as 3rd party deps is concerned, so by no means should java
>>>>>> just blindly emulate their solutions.
>>>>>>
>>>>>> I don?t like the idea of shipping a non-data-binding JSON API in the
>>>>>> core libs. The root issue with JSON is that you just can?t tell how to
>>>>>> interpret any given JSON token, because that?s not how JSON is used in
>>>>>> practice. What does 5 mean? Could be that I?m to take that as an int,
>>>>>> or as a double, or perhaps even as a j.t.Instant (epoch-millis), and
>>>>>> defaulting behaviour (similar to j.u.Map?s .getOrDefault is *very*
>>>>>> convenient to parse most JSON out there in the real world - omitting k/v
>>>>>> pairs whose value is still on default is very common). That?s what makes
>>>>>> those databind libraries so enticing: Instead of trying to pattern match my
>>>>>> way into this behaviour:
>>>>>>
>>>>>>
>>>>>>    - If the element isn?t there at all or null, give me a
>>>>>>    list-of-longs with a single 0 in it.
>>>>>>    - If the element is a number, make me a list-of-longs with 1
>>>>>>    value in it, that is that number, as long.
>>>>>>    - If the element is a string, parse it into a long, then get me a
>>>>>>    list with this one long value (because IEEE double rules mean sometimes you
>>>>>>    have to put these things in string form or they get mangled by javascript-
>>>>>>    eval style parsers).
>>>>>>
>>>>>>
>>>>>> And yet the above is quite common, and can easily be done by a
>>>>>> databinder, which sees you want a List<Long> for a field whose
>>>>>> default value is List.of(1L), and, armed with that knowledge, can
>>>>>> transit the JSON into java in that way.
>>>>>>
>>>>>> You don?t *need* databinding to cater to this idea: You could for
>>>>>> example have a jsonNode.asLong(123) method that would parse a string
>>>>>> if need be, even. But this has nothing to do with pattern matching either.
>>>>>>
>>>>>>  --Reinier Zwitserloot
>>>>>>
>>>>>>
>>>>>> On 15 Dec 2022 at 21:30:17, Ethan McCue <ethan at mccue.dev> wrote:
>>>>>>
>>>>>>> I'm writing this to drive some forward motion and to nerd-snipe
>>>>>>> those who know better than I do into putting their thoughts into words.
>>>>>>>
>>>>>>> There are three ways to process JSON[1]
>>>>>>> - Streaming (Push or Pull)
>>>>>>> - Traversing a Tree (Realized or Lazy)
>>>>>>> - Declarative Databind (N ways)
>>>>>>>
>>>>>>> Of these, JEP-198 explicitly ruled out providing "JAXB style type
>>>>>>> safe data binding."
>>>>>>>
>>>>>>> No justification is given, but if I had to insert my own: mapping
>>>>>>> the Json model to/from the Java/JVM object model is a cursed combo of
>>>>>>> - Huge possible design space
>>>>>>> - Unpalatably large surface for backwards compatibility
>>>>>>> - Serialization! Boo![2]
>>>>>>>
>>>>>>> So for an artifact like the JDK, it probably doesn't make sense to
>>>>>>> include. That tracks.
>>>>>>> It won't make everyone happy, people like databind APIs, but it
>>>>>>> tracks.
>>>>>>>
>>>>>>> So for the "read flow" these are the things to figure out.
>>>>>>>
>>>>>>>                 | Should Provide? | Intended User(s) |
>>>>>>> ----------------+-----------------+------------------+
>>>>>>>  Streaming Push |                 |                  |
>>>>>>> ----------------+-----------------+------------------+
>>>>>>>  Streaming Pull |                 |                  |
>>>>>>> ----------------+-----------------+------------------+
>>>>>>>  Realized Tree  |                 |                  |
>>>>>>> ----------------+-----------------+------------------+
>>>>>>>  Lazy Tree      |                 |                  |
>>>>>>> ----------------+-----------------+------------------+
>>>>>>>
>>>>>>> At which point, we should talk about what "meets needs of Java
>>>>>>> developers using JSON" implies.
>>>>>>>
>>>>>>> JSON is ubiquitous. Most kinds of software us schmucks write could
>>>>>>> have a reason to interact with it.
>>>>>>> The full set of "user personas" therefore aren't practical for me to
>>>>>>> talk about.[3]
>>>>>>>
>>>>>>> JSON documents, however, are not so varied.
>>>>>>>
>>>>>>> - There are small ones (1-10kb)
>>>>>>> - There are medium ones (10-1000kb)
>>>>>>> - There are big ones (1000kb-???)
>>>>>>>
>>>>>>> - There are shallow ones
>>>>>>> - There are deep ones
>>>>>>>
>>>>>>> So that feels like an easier direction to talk about it from.
>>>>>>>
>>>>>>>
>>>>>>> This repo[4] has some convenient toy examples of how some of those
>>>>>>> APIs look in libraries
>>>>>>> in the ecosystem. Specifically the Streaming Pull and Realized Tree
>>>>>>> models.
>>>>>>>
>>>>>>>         User r = new User();
>>>>>>>         while (true) {
>>>>>>>             JsonToken token = reader.peek();
>>>>>>>             switch (token) {
>>>>>>>                 case BEGIN_OBJECT:
>>>>>>>                     reader.beginObject();
>>>>>>>                     break;
>>>>>>>                 case END_OBJECT:
>>>>>>>                     reader.endObject();
>>>>>>>                     return r;
>>>>>>>                 case NAME:
>>>>>>>                     String fieldname = reader.nextName();
>>>>>>>                     switch (fieldname) {
>>>>>>>                         case "id":
>>>>>>>                             r.setId(reader.nextString());
>>>>>>>                             break;
>>>>>>>                         case "index":
>>>>>>>                             r.setIndex(reader.nextInt());
>>>>>>>                             break;
>>>>>>>                         ...
>>>>>>>                         case "friends":
>>>>>>>                             r.setFriends(new ArrayList<>());
>>>>>>>                             Friend f = null;
>>>>>>>                             carryOn = true;
>>>>>>>                             while (carryOn) {
>>>>>>>                                 token = reader.peek();
>>>>>>>                                 switch (token) {
>>>>>>>                                     case BEGIN_ARRAY:
>>>>>>>                                         reader.beginArray();
>>>>>>>                                         break;
>>>>>>>                                     case END_ARRAY:
>>>>>>>                                         reader.endArray();
>>>>>>>                                         carryOn = false;
>>>>>>>                                         break;
>>>>>>>                                     case BEGIN_OBJECT:
>>>>>>>                                         reader.beginObject();
>>>>>>>                                         f = new Friend();
>>>>>>>                                         break;
>>>>>>>                                     case END_OBJECT:
>>>>>>>                                         reader.endObject();
>>>>>>>                                         r.getFriends().add(f);
>>>>>>>                                         break;
>>>>>>>                                     case NAME:
>>>>>>>                                         String fn =
>>>>>>> reader.nextName();
>>>>>>>                                         switch (fn) {
>>>>>>>                                             case "id":
>>>>>>>
>>>>>>> f.setId(reader.nextString());
>>>>>>>                                                 break;
>>>>>>>                                             case "name":
>>>>>>>
>>>>>>> f.setName(reader.nextString());
>>>>>>>                                                 break;
>>>>>>>                                         }
>>>>>>>                                         break;
>>>>>>>                                 }
>>>>>>>                             }
>>>>>>>                             break;
>>>>>>>                     }
>>>>>>>             }
>>>>>>>
>>>>>>> I think its not hard to argue that the streaming apis are brutalist.
>>>>>>> The above is Gson, but Jackson, moshi, etc
>>>>>>> seem at least morally equivalent.
>>>>>>>
>>>>>>> Its hard to write, hard to write *correctly*, and theres is a
>>>>>>> curious protensity towards pairing it
>>>>>>> with anemic, mutable models.
>>>>>>>
>>>>>>> That being said, it handles big documents and deep documents really
>>>>>>> well. It also performs
>>>>>>> pretty darn well and is good enough as a "fallback" when the
>>>>>>> intended user experience
>>>>>>> is through something like databind.
>>>>>>>
>>>>>>> So what could we do meaningfully better with the language we have
>>>>>>> today/will have tommorow?
>>>>>>>
>>>>>>> - Sealed interfaces + Pattern matching could give a nicer model for
>>>>>>> tokens
>>>>>>>
>>>>>>>         sealed interface JsonToken {
>>>>>>>             record Field(String name) implements JsonToken {}
>>>>>>>             record BeginArray() implements JsonToken {}
>>>>>>>             record EndArray() implements JsonToken {}
>>>>>>>             record BeginObject() implements JsonToken {}
>>>>>>>             record EndObject() implements JsonToken {}
>>>>>>>             // ...
>>>>>>>         }
>>>>>>>
>>>>>>>         // ...
>>>>>>>
>>>>>>>         User r = new User();
>>>>>>>         while (true) {
>>>>>>>             JsonToken token = reader.peek();
>>>>>>>             switch (token) {
>>>>>>>                 case BeginObject __:
>>>>>>>                     reader.beginObject();
>>>>>>>                     break;
>>>>>>>                 case EndObject __:
>>>>>>>                     reader.endObject();
>>>>>>>                     return r;
>>>>>>>                 case Field("id"):
>>>>>>>                     r.setId(reader.nextString());
>>>>>>>                     break;
>>>>>>>                 case Field("index"):
>>>>>>>                     r.setIndex(reader.nextInt());
>>>>>>>                     break;
>>>>>>>
>>>>>>>                 // ...
>>>>>>>
>>>>>>>                 case Field("friends"):
>>>>>>>                     r.setFriends(new ArrayList<>());
>>>>>>>                     Friend f = null;
>>>>>>>                     carryOn = true;
>>>>>>>                     while (carryOn) {
>>>>>>>                         token = reader.peek();
>>>>>>>                         switch (token) {
>>>>>>>                 // ...
>>>>>>>
>>>>>>> - Value classes can make it all more efficient
>>>>>>>
>>>>>>>         sealed interface JsonToken {
>>>>>>>             value record Field(String name) implements JsonToken {}
>>>>>>>             value record BeginArray() implements JsonToken {}
>>>>>>>             value record EndArray() implements JsonToken {}
>>>>>>>             value record BeginObject() implements JsonToken {}
>>>>>>>             value record EndObject() implements JsonToken {}
>>>>>>>             // ...
>>>>>>>         }
>>>>>>>
>>>>>>> - (Fun One) We can transform a simpler-to-write push parser into a
>>>>>>> pull parser with Coroutines
>>>>>>>
>>>>>>>     This is just a toy we could play with while making something in
>>>>>>> the JDK. I'm pretty sure
>>>>>>>     we could make a parser which feeds into something like
>>>>>>>
>>>>>>>         interface Listener {
>>>>>>>             void onObjectStart();
>>>>>>>             void onObjectEnd();
>>>>>>>             void onArrayStart();
>>>>>>>             void onArrayEnd();
>>>>>>>             void onField(String name);
>>>>>>>             // ...
>>>>>>>         }
>>>>>>>
>>>>>>>     and invert a loop like
>>>>>>>
>>>>>>>         while (true) {
>>>>>>>             char c = next();
>>>>>>>             switch (c) {
>>>>>>>                 case '{':
>>>>>>>                     listener.onObjectStart();
>>>>>>>                     // ...
>>>>>>>                 // ...
>>>>>>>             }
>>>>>>>         }
>>>>>>>
>>>>>>>     by putting a Coroutine.yield in the callback.
>>>>>>>
>>>>>>>     That might be a meaningful simplification in code structure, I
>>>>>>> don't know enough to say.
>>>>>>>
>>>>>>> But, I think there are some hard questions like
>>>>>>>
>>>>>>> - Is the intent[5] to be make backing parser for ecosystem databind
>>>>>>> apis?
>>>>>>> - Is the intent that users who want to handle big/deep documents
>>>>>>> fall back to this?
>>>>>>> - Are those new language features / conveniences enough to offset
>>>>>>> the cost of committing to a new api?
>>>>>>> - To whom exactly does a low level api provide value?
>>>>>>> - What benefit is standardization in the JDK?
>>>>>>>
>>>>>>> and just generally - who would be the consumer(s) of this?
>>>>>>>
>>>>>>> The other kind of API still on the table is a Tree. There are two
>>>>>>> ways to handle this
>>>>>>>
>>>>>>> 1. Load it into `Object`. Use a bunch of instanceof checks/casts to
>>>>>>> confirm what it actually is.
>>>>>>>
>>>>>>>         Object v;
>>>>>>>         User u = new User();
>>>>>>>
>>>>>>>         if ((v = jso.get("id")) != null) {
>>>>>>>             u.setId((String) v);
>>>>>>>         }
>>>>>>>         if ((v = jso.get("index")) != null) {
>>>>>>>             u.setIndex(((Long) v).intValue());
>>>>>>>         }
>>>>>>>         if ((v = jso.get("guid")) != null) {
>>>>>>>             u.setGuid((String) v);
>>>>>>>         }
>>>>>>>         if ((v = jso.get("isActive")) != null) {
>>>>>>>             u.setIsActive(((Boolean) v));
>>>>>>>         }
>>>>>>>         if ((v = jso.get("balance")) != null) {
>>>>>>>             u.setBalance((String) v);
>>>>>>>         }
>>>>>>>         // ...
>>>>>>>         if ((v = jso.get("latitude")) != null) {
>>>>>>>             u.setLatitude(v instanceof BigDecimal ? ((BigDecimal)
>>>>>>> v).doubleValue() : (Double) v);
>>>>>>>         }
>>>>>>>         if ((v = jso.get("longitude")) != null) {
>>>>>>>             u.setLongitude(v instanceof BigDecimal ? ((BigDecimal)
>>>>>>> v).doubleValue() : (Double) v);
>>>>>>>         }
>>>>>>>         if ((v = jso.get("greeting")) != null) {
>>>>>>>             u.setGreeting((String) v);
>>>>>>>         }
>>>>>>>         if ((v = jso.get("favoriteFruit")) != null) {
>>>>>>>             u.setFavoriteFruit((String) v);
>>>>>>>         }
>>>>>>>         if ((v = jso.get("tags")) != null) {
>>>>>>>             List<Object> jsonarr = (List<Object>) v;
>>>>>>>             u.setTags(new ArrayList<>());
>>>>>>>             for (Object vi : jsonarr) {
>>>>>>>                 u.getTags().add((String) vi);
>>>>>>>             }
>>>>>>>         }
>>>>>>>         if ((v = jso.get("friends")) != null) {
>>>>>>>             List<Object> jsonarr = (List<Object>) v;
>>>>>>>             u.setFriends(new ArrayList<>());
>>>>>>>             for (Object vi : jsonarr) {
>>>>>>>                 Map<String, Object> jso0 = (Map<String, Object>) vi;
>>>>>>>                 Friend f = new Friend();
>>>>>>>                 f.setId((String) jso0.get("id"));
>>>>>>>                 f.setName((String) jso0.get("name"));
>>>>>>>                 u.getFriends().add(f);
>>>>>>>             }
>>>>>>>         }
>>>>>>>
>>>>>>> 2. Have an explicit model for Json, and helper methods that do said
>>>>>>> casts[6]
>>>>>>>
>>>>>>>
>>>>>>> this.setSiteSetting(readFromJson(jsonObject.getJsonObject("site")));
>>>>>>> JsonArray groups = jsonObject.getJsonArray("group");
>>>>>>> if(groups != null)
>>>>>>> {
>>>>>>> int len = groups.size();
>>>>>>> for(int i=0; i<len; i++)
>>>>>>> {
>>>>>>> JsonObject grp = groups.getJsonObject(i);
>>>>>>> SNMPSetting grpSetting = readFromJson(grp);
>>>>>>> String grpName = grp.getString("dbgroup", null);
>>>>>>> if(grpName != null && grpSetting != null)
>>>>>>> this.groupSettings.put(grpName, grpSetting);
>>>>>>> }
>>>>>>> }
>>>>>>> JsonArray hosts = jsonObject.getJsonArray("host");
>>>>>>> if(hosts != null)
>>>>>>> {
>>>>>>> int len = hosts.size();
>>>>>>> for(int i=0; i<len; i++)
>>>>>>> {
>>>>>>> JsonObject host = hosts.getJsonObject(i);
>>>>>>> SNMPSetting hostSetting = readFromJson(host);
>>>>>>> String hostName = host.getString("dbhost", null);
>>>>>>> if(hostName != null && hostSetting != null)
>>>>>>> this.hostSettings.put(hostName, hostSetting);
>>>>>>> }
>>>>>>> }
>>>>>>>
>>>>>>> I think what has become easier to represent in the language nowadays
>>>>>>> is that explicit model for Json.
>>>>>>> Its the 101 lesson of sealed interfaces.[7] It feels nice and clean.
>>>>>>>
>>>>>>>         sealed interface Json {
>>>>>>>             final class Null implements Json {}
>>>>>>>             final class True implements Json {}
>>>>>>>             final class False implements Json {}
>>>>>>>             final class Array implements Json {}
>>>>>>>             final class Object implements Json {}
>>>>>>>             final class String implements Json {}
>>>>>>>             final class Number implements Json {}
>>>>>>>         }
>>>>>>>
>>>>>>> And the cast-and-check approach is now more viable on account of
>>>>>>> pattern matching.
>>>>>>>
>>>>>>>         if (jso.get("id") instanceof String v) {
>>>>>>>             u.setId(v);
>>>>>>>         }
>>>>>>>         if (jso.get("index") instanceof Long v) {
>>>>>>>             u.setIndex(v.intValue());
>>>>>>>         }
>>>>>>>         if (jso.get("guid") instanceof String v) {
>>>>>>>             u.setGuid(v);
>>>>>>>         }
>>>>>>>
>>>>>>>         // or
>>>>>>>
>>>>>>>         if (jso.get("id") instanceof String id &&
>>>>>>>                 jso.get("index") instanceof Long index &&
>>>>>>>                 jso.get("guid") instanceof String guid) {
>>>>>>>             return new User(id, index, guid, ...); // look ma, no
>>>>>>> setters!
>>>>>>>         }
>>>>>>>
>>>>>>>
>>>>>>> And on the horizon, again, is value types.
>>>>>>>
>>>>>>> But there are problems with this approach beyond the performance
>>>>>>> implications of loading into
>>>>>>> a tree.
>>>>>>>
>>>>>>> For one, all the code samples above have different behaviors around
>>>>>>> null keys and missing keys
>>>>>>> that are not obvious from first glance.
>>>>>>>
>>>>>>> This won't accept any null or missing fields
>>>>>>>
>>>>>>>         if (jso.get("id") instanceof String id &&
>>>>>>>                 jso.get("index") instanceof Long index &&
>>>>>>>                 jso.get("guid") instanceof String guid) {
>>>>>>>             return new User(id, index, guid, ...);
>>>>>>>         }
>>>>>>>
>>>>>>> This will accept individual null or missing fields, but also will
>>>>>>> silently ignore
>>>>>>> fields with incorrect types
>>>>>>>
>>>>>>>         if (jso.get("id") instanceof String v) {
>>>>>>>             u.setId(v);
>>>>>>>         }
>>>>>>>         if (jso.get("index") instanceof Long v) {
>>>>>>>             u.setIndex(v.intValue());
>>>>>>>         }
>>>>>>>         if (jso.get("guid") instanceof String v) {
>>>>>>>             u.setGuid(v);
>>>>>>>         }
>>>>>>>
>>>>>>> And, compared to databind where there is information about the
>>>>>>> expected structure of the document
>>>>>>> and its the job of the framework to assert that, I posit that the
>>>>>>> errors that would be encountered
>>>>>>> when writing code against this would be more like
>>>>>>>
>>>>>>>     "something wrong with user"
>>>>>>>
>>>>>>> than
>>>>>>>
>>>>>>>     "problem at users[5].name, expected string or null. got 5"
>>>>>>>
>>>>>>> Which feels unideal.
>>>>>>>
>>>>>>>
>>>>>>> One approach I find promising is something close to what Elm does
>>>>>>> with its decoders[8]. Not just combining assertion
>>>>>>> and binding like what pattern matching with records allows, but
>>>>>>> including a scheme for bubbling/nesting errors.
>>>>>>>
>>>>>>>     static String string(Json json) throws JsonDecodingException {
>>>>>>>         if (!(json instanceof Json.String jsonString)) {
>>>>>>>             throw JsonDecodingException.of(
>>>>>>>                     "expected a string",
>>>>>>>                     json
>>>>>>>             );
>>>>>>>         } else {
>>>>>>>             return jsonString.value();
>>>>>>>         }
>>>>>>>     }
>>>>>>>
>>>>>>>     static <T> T field(Json json, String fieldName, Decoder<?
>>>>>>> extends T> valueDecoder) throws JsonDecodingException {
>>>>>>>         var jsonObject = object(json);
>>>>>>>         var value = jsonObject.get(fieldName);
>>>>>>>         if (value == null) {
>>>>>>>             throw JsonDecodingException.atField(
>>>>>>>                     fieldName,
>>>>>>>                     JsonDecodingException.of(
>>>>>>>                             "no value for field",
>>>>>>>                             json
>>>>>>>                     )
>>>>>>>             );
>>>>>>>         }
>>>>>>>         else {
>>>>>>>             try {
>>>>>>>                 return valueDecoder.decode(value);
>>>>>>>             } catch (JsonDecodingException e) {
>>>>>>>                 throw JsonDecodingException.atField(
>>>>>>>                         fieldName,
>>>>>>>                         e
>>>>>>>                 );
>>>>>>>             }  catch (Exception e) {
>>>>>>>                 throw JsonDecodingException.atField(fieldName,
>>>>>>> JsonDecodingException.of(e, value));
>>>>>>>             }
>>>>>>>         }
>>>>>>>     }
>>>>>>>
>>>>>>> Which I think has some benefits over the ways I've seen of working
>>>>>>> with trees.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> - It is declarative enough that folks who prefer databind might be
>>>>>>> happy enough.
>>>>>>>
>>>>>>>         static User fromJson(Json json) {
>>>>>>>             return new User(
>>>>>>>                 Decoder.field(json, "id", Decoder::string),
>>>>>>>                 Decoder.field(json, "index", Decoder::long_),
>>>>>>>                 Decoder.field(json, "guid", Decoder::string),
>>>>>>>             );
>>>>>>>         }
>>>>>>>
>>>>>>>         / ...
>>>>>>>
>>>>>>>         List<User> users = Decoders.array(json, User::fromJson);
>>>>>>>
>>>>>>> - Handling null and optional fields could be less easily conflated
>>>>>>>
>>>>>>>     Decoder.field(json, "id", Decoder::string);
>>>>>>>
>>>>>>>     Decoder.nullableField(json, "id", Decoder::string);
>>>>>>>
>>>>>>>     Decoder.optionalField(json, "id", Decoder::string);
>>>>>>>
>>>>>>>     Decoder.optionalNullableField(json, "id", Decoder::string);
>>>>>>>
>>>>>>>
>>>>>>> - It composes well with user defined classes
>>>>>>>
>>>>>>>     record Guid(String value) {
>>>>>>>         Guid {
>>>>>>>             // some assertions on the structure of value
>>>>>>>         }
>>>>>>>     }
>>>>>>>
>>>>>>>     Decoder.string(json, "guid", guid -> new
>>>>>>> Guid(Decoder.string(guid)));
>>>>>>>
>>>>>>>     // or even
>>>>>>>
>>>>>>>     record Guid(String value) {
>>>>>>>         Guid {
>>>>>>>             // some assertions on the structure of value
>>>>>>>         }
>>>>>>>
>>>>>>>         static Guid fromJson(Json json) {
>>>>>>>             return new Guid(Decoder.string(guid));
>>>>>>>         }
>>>>>>>     }
>>>>>>>
>>>>>>>     Decoder.string(json, "guid", Guid::fromJson);
>>>>>>>
>>>>>>>
>>>>>>> - When something goes wrong, the API can handle the fiddlyness of
>>>>>>> capturing information for feedback.
>>>>>>>
>>>>>>>     In the code I've sketched out its just what field/index things
>>>>>>> went wrong at. Potentially
>>>>>>>     capturing metadata like row/col numbers of the source would be
>>>>>>> sensible too.
>>>>>>>
>>>>>>>     Its just not reasonable to expect devs to do extra work to get
>>>>>>> that and its really nice to give it.
>>>>>>>
>>>>>>> There are also some downsides like
>>>>>>>
>>>>>>> -  I do not know how compatible it would be with lazy trees.
>>>>>>>
>>>>>>>      Lazy trees being the only way that a tree api could handle big
>>>>>>> or deep documents.
>>>>>>>      The general concept as applied in libraries like json-tree[9]
>>>>>>> is to navigate without
>>>>>>>      doing any work, and that clashes with wanting to instanceof
>>>>>>> check the info at the
>>>>>>>      current path.
>>>>>>>
>>>>>>> - It *almost* gives enough information to be a general schema
>>>>>>> approach
>>>>>>>
>>>>>>>     If one field fails, that in the model throws an exception
>>>>>>> immediately. If an API should
>>>>>>>     return "errors": [...], that is inconvenient to construct.
>>>>>>>
>>>>>>> - None of the existing popular libraries are doing this
>>>>>>>
>>>>>>>      The only mechanics that are strictly required to give this sort
>>>>>>> of API is lambdas. Those have
>>>>>>>      been out for a decade. Yes sealed interfaces make the data
>>>>>>> model prettier but in concept you
>>>>>>>      can build the same thing on top of anything.
>>>>>>>
>>>>>>>      I could argue that this is because of "cultural momentum" of
>>>>>>> databind or some other reason,
>>>>>>>      but the fact remains that it isn't a proven out approach.
>>>>>>>
>>>>>>>      Writing Json libraries is a todo list[10]. There are a lot of
>>>>>>> bad ideas and this might be one of the,
>>>>>>>
>>>>>>> - Performance impact of so many instanceof checks
>>>>>>>
>>>>>>>     I've gotten a 4.2% slowdown compared to the "regular" tree code
>>>>>>> without the repeated casts.
>>>>>>>
>>>>>>>     But that was with a parser that is 5x slower than Jacksons.
>>>>>>> (using the same benchmark project as for the snippets).
>>>>>>>     I think there could be reason to believe that the JIT does well
>>>>>>> enough with repeated instanceof
>>>>>>>     checks to consider it.
>>>>>>>
>>>>>>>
>>>>>>> My current thinking is that - despite not solving for large or deep
>>>>>>> documents - starting with a really "dumb" realized tree api
>>>>>>> might be the right place to start for the read side of a potential
>>>>>>> incubator module.
>>>>>>>
>>>>>>> But regardless - this feels like a good time to start more concrete
>>>>>>> conversations. I fell I should cap this email since I've reached the point
>>>>>>> of decoherence and haven't even mentioned the write side of things
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> [1]:
>>>>>>> http://www.cowtowncoder.com/blog/archives/2009/01/entry_131.html
>>>>>>> [2]: https://security.snyk.io/vuln/maven?search=jackson-databind
>>>>>>> [3]: I only know like 8 people
>>>>>>> [4]:
>>>>>>> https://github.com/fabienrenaud/java-json-benchmark/blob/master/src/main/java/com/github/fabienrenaud/jjb/stream/UsersStreamDeserializer.java
>>>>>>> [5]: When I say "intent", I do so knowing full well no one has been
>>>>>>> actively thinking of this for an entire Game of Thrones
>>>>>>> [6]:
>>>>>>> https://github.com/yahoo/mysql_perf_analyzer/blob/master/myperf/src/main/java/com/yahoo/dba/perf/myperf/common/SNMPSettings.java
>>>>>>> [7]: https://www.infoq.com/articles/data-oriented-programming-java/
>>>>>>> [8]:
>>>>>>> https://package.elm-lang.org/packages/elm/json/latest/Json-Decode
>>>>>>> [9]: https://github.com/jbee/json-tree
>>>>>>> [10]: https://stackoverflow.com/a/14442630/2948173
>>>>>>> [11]: In 30 days JEP-198 it will be recognizably PI days old for the
>>>>>>> 2nd time in its history.
>>>>>>> [12]: To me, the fact that is still an open JEP is more a social
>>>>>>> convenience than anything. I could just as easily writing this exact same
>>>>>>> email about TOML.
>>>>>>>
>>>>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20230228/468b47c0/attachment-0001.htm>

From naoto at openjdk.org  Tue Feb 28 18:21:06 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 28 Feb 2023 18:21:06 GMT
Subject: RFR: 8303232: java.util.Date.parse(String) and
 java.util.Date(String) don't declare thrown IllegalArgumentException
In-Reply-To: <6S1UF7DvwvaGLJJhkX8DlBiV57SImGBxyDMLYohzfwU=.1937701d-8be4-4a1f-85e8-c6ad19ccc72a@github.com>
References: <6S1UF7DvwvaGLJJhkX8DlBiV57SImGBxyDMLYohzfwU=.1937701d-8be4-4a1f-85e8-c6ad19ccc72a@github.com>
Message-ID: <Q7NhF5XBpjU8SnEHMxO1l75v_D7cSL7OwBsfaMOhp4k=.80988498-d8d0-4f7b-a7e6-a92880a1765a@github.com>

On Tue, 28 Feb 2023 00:07:05 GMT, Justin Lu <jlu at openjdk.org> wrote:

> The method `java.util.Date.parse(String)` and as a result, constructor `java.util.Date(String)` throw an `IllegalArgumentException`. This exception is not properly referenced in the javadoc, and this PR simply adds the throws javadoc tag to make it apparent.

Marked as reviewed by naoto (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/12779

From asemenyuk at openjdk.org  Tue Feb 28 18:24:04 2023
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Tue, 28 Feb 2023 18:24:04 GMT
Subject: RFR: 8303227: JniObjWithEnv should be NullablePointer compliant
In-Reply-To: <tSmb1smHT4lPI7yJv2Q_Nsy2n3LCdrRPTyhEPuMJTgY=.a356defb-f164-4d2e-9f29-61dc6be96c1f@github.com>
References: <tSmb1smHT4lPI7yJv2Q_Nsy2n3LCdrRPTyhEPuMJTgY=.a356defb-f164-4d2e-9f29-61dc6be96c1f@github.com>
Message-ID: <GGikOMhQFFYmZOlXDEQVbXRegulmcZZcmsMRQhDJsaY=.cccec70e-a674-4a26-876a-e2b242a33426@github.com>

On Mon, 27 Feb 2023 08:19:53 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> JniObjWithEnv is a struct that is commonly managed by std::unique_ptr. Although it can support managing objects that are not raw pointers, any such objects have to be [NullablePointers](https://en.cppreference.com/w/cpp/named_req/NullablePointer). In the past this has [broken the build when compiler upgrades were carried out](https://bugs.openjdk.org/browse/JDK-8244220), so we should add in the final requirements to make the struct a true NullablePointer once and for all, to prevent similar issues from happening in the future

Marked as reviewed by asemenyuk (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/12758

From darcy at openjdk.org  Tue Feb 28 18:37:23 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 28 Feb 2023 18:37:23 GMT
Subject: Integrated: JDK-8302040: Port fdlibm sqrt to Java
In-Reply-To: <rjVM2lWPdsvPcfLF3oNShP-cSN8-P-i16ikUC3sTgIg=.1d4f470d-2ac9-4394-b55e-099affce763f@github.com>
References: <rjVM2lWPdsvPcfLF3oNShP-cSN8-P-i16ikUC3sTgIg=.1d4f470d-2ac9-4394-b55e-099affce763f@github.com>
Message-ID: <XeZ4L5ien53hmaVs9V9NJrcgnZtBdidDCscM5O0i400=.3940f2f9-4f6b-4018-a15a-33a968e758bf@github.com>

On Thu, 23 Feb 2023 23:28:11 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> The wheel of FDLIBM porting turns a notch and sqrt comes into play.
> 
> While the sqrt operation usually has a hardware implementation that is intrinsified, for completeness a software implementation should be available as well.

This pull request has now been integrated.

Changeset: 61e88675
Author:    Joe Darcy <darcy at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/61e8867591f02f568776eed7211c4a83c56b8170
Stats:     875 lines in 8 files changed: 869 ins; 0 del; 6 mod

8302040: Port fdlibm sqrt to Java

Reviewed-by: bpb, thartmann, aturbanov

-------------

PR: https://git.openjdk.org/jdk/pull/12736

From jwaters at openjdk.org  Tue Feb 28 18:39:15 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Tue, 28 Feb 2023 18:39:15 GMT
Subject: Integrated: 8303227: JniObjWithEnv should be NullablePointer compliant
In-Reply-To: <tSmb1smHT4lPI7yJv2Q_Nsy2n3LCdrRPTyhEPuMJTgY=.a356defb-f164-4d2e-9f29-61dc6be96c1f@github.com>
References: <tSmb1smHT4lPI7yJv2Q_Nsy2n3LCdrRPTyhEPuMJTgY=.a356defb-f164-4d2e-9f29-61dc6be96c1f@github.com>
Message-ID: <NOW4K9U26OGPFwIc1DP_WdbfKWUeQtmbLFI7gSGMQMU=.299019f5-a8be-4b03-b4ae-89993750c1f8@github.com>

On Mon, 27 Feb 2023 08:19:53 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> JniObjWithEnv is a struct that is commonly managed by std::unique_ptr. Although it can support managing objects that are not raw pointers, any such objects have to be [NullablePointers](https://en.cppreference.com/w/cpp/named_req/NullablePointer). In the past this has [broken the build when compiler upgrades were carried out](https://bugs.openjdk.org/browse/JDK-8244220), so we should add in the final requirements to make the struct a true NullablePointer once and for all, to prevent similar issues from happening in the future

This pull request has now been integrated.

Changeset: 50dc041e
Author:    Julian Waters <jwaters at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/50dc041ee69eb62454bbf5c47a9545c6183d43d1
Stats:     12 lines in 1 file changed: 12 ins; 0 del; 0 mod

8303227: JniObjWithEnv should be NullablePointer compliant

Reviewed-by: asemenyuk

-------------

PR: https://git.openjdk.org/jdk/pull/12758

From rriggs at openjdk.org  Tue Feb 28 19:36:07 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 28 Feb 2023 19:36:07 GMT
Subject: RFR: 8303133: Update ProcessTools.startProcess(...) to exit early
 if process exit before linePredicate is printed. [v5]
In-Reply-To: <hlXbi3Q4oMDDZqLqbALqBa2NWocRhWR3wVqXclqDf2I=.3f588a06-e52e-46b3-85ac-a863487557b4@github.com>
References: <cuDocKEsnNWZvi2L_E6XBQ_U0T8qnNCIupmsFxaSjEw=.867a6664-21bc-44fb-aa68-9b9a1e8d36d7@github.com>
 <hlXbi3Q4oMDDZqLqbALqBa2NWocRhWR3wVqXclqDf2I=.3f588a06-e52e-46b3-85ac-a863487557b4@github.com>
Message-ID: <k6AD-E-SWCPxaWPreWARjwasMOFsmAx0c9zamzGRBMw=.f107afe1-f0e4-41db-97de-2c091d4c0296@github.com>

On Mon, 27 Feb 2023 23:11:27 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> The solution proposed by Stefan K
>> 
>> The startProcess() might wait forever for the expected line if the process exits (failed to start). It makes sense to just fail earlier in such cases.
>> 
>> The fix also move
>> 'output = new OutputAnalyzer(this.process);'
>> in method xrun() to be able to try to print them in waitFor is failed/interrupted.
>
> Leonid Mesnik has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - latch != updated
>  - message improved

Marked as reviewed by rriggs (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/12751

From brian.goetz at oracle.com  Tue Feb 28 19:48:00 2023
From: brian.goetz at oracle.com (Brian Goetz)
Date: Tue, 28 Feb 2023 14:48:00 -0500
Subject: JEP-198 - Lets start talking about JSON
In-Reply-To: <CA+NR86hGVP2F948jFH3qo7fDQsc-W6HP-1YK6LVSCJTL5yQ+mA@mail.gmail.com>
References: <CA+NR86hGVP2F948jFH3qo7fDQsc-W6HP-1YK6LVSCJTL5yQ+mA@mail.gmail.com>
Message-ID: <23c6e4b3-71d9-fa5f-f64a-1e1ae73dcb3d@oracle.com>

As you can probably imagine, I've been thinking about these topics for 
quite a while, ever since we started working on records and pattern 
matching.? It sounds like a lot of your thoughts have followed a similar 
arc to ours.

I'll share with you some of our thoughts, but I can't be engaging in a 
detailed back-and-forth right now -- we have too many other things going 
on, and this isn't yet on the front burner.? I think there's a right 
time for this work, and we're not quite there yet, but we'll get there 
soon enough and we'll pick up the ball again then.

To the existential question: yes, there should be a simpler, built-in 
way to parse JSON.? And, as you observe, the railroad diagram in the 
JSON spec is a graphical description of an algebraic data type.? One of 
the great simplifying effects of having algebraic data types (records + 
sealed classes) in the language is that many data modeling problems 
collapse down to the point where considerably less creativity is 
required of an API.? Here's the JSON API one can write after literally 
only 30 seconds of thought:

> sealed interface JsonValue{
>
> record JsonString(String s)implements JsonValue{ }
>
> record JsonNumber(double d)implements JsonValue{ }
>
> record JsonNull()implements JsonValue{ }
>
> record JsonBoolean(booleanb)implements JsonValue{ }
>
> record JsonArray(List<JsonValue> values)implements JsonValue{ }
>
> record JsonObject(Map<String, JsonValue> pairs)implements JsonValue{ }
>
> }
>

It matches the JSON spec almost literally, and you can use pattern 
matching to parse a document.? (OK, there's some tiny bit of creativity 
here in that True/False have been collapsed to a single JsonBoolean 
type, but you get my point.)

But, we're not quite ready to put this API into the JDK, because the 
language isn't *quite* there yet.? Records give you nice pattern 
matching, but they come at a cost; they're very specific and have rigid 
ideas about initialization, which ripples into a number of constraints 
on an implementation (i.e., much harder to parse lazily.)? So we're 
waiting until we have deconstruction patterns (next up on the patterns 
parade) so that the records above can be interfaces and still support 
pattern matching (and more flexibility in implementation, including 
using value classes when they arrive.)? It's not a long hop, though.

I agree with your assessment of streaming models; for documents too 
large to fit into memory, we'll let someone else provide a specialized 
solution.? Streaming and fully-materialized-tree are not the only two 
options; there are plenty of points in the middle.

As to API idioms, these can be layered.? The lazy-tree model outlined 
above can be a foundation for data binding, dynamic mapping to records, 
jsonpath, etc.? But once you've made the streaming-vs-materialized 
choice in favor of materialized, it's hard to imagine not having 
something like the above at the base of the tower.

The question you raise about error handling is one that infuses pattern 
matching in general.? Pattern matching allows us to collapse what would 
be a thousand questions -- "does key X exist?? is it mapped to a 
number?? is the number in the range of byte?" -- each with their own 
failure-handling path, into a single question.? That's great for 
reliable and readable code, but it does make errors more opaque, because 
it is more like the red "check engine" light on your dashboard.? 
(Something like JSONPath could generate better error messages since 
you've given it a declarative description of an assumed structural 
invariant.)? But, imperative code that has to treat each structural 
assumption as a possible control-flow point is a disaster; we've seen 
too much code like this already.

The ecosystem is big enough that there will be lots of people with 
strong opinions that "X is the only sensible way to do it" (we've 
already seen X=databinding on this thread), but the reality is that 
there are multiple overlapping audiences here, and we have to be clear 
which audiences we are prioritizing.? We can have that debate when the 
time is right.

So, we'll get there, but we're waiting for one or two more bits of 
language evolution to give us the substrate for the API that feels right.

Hope this helps,
-Brian


On 12/15/2022 3:30 PM, Ethan McCue wrote:
> I'm writing this to drive some forward motion and to nerd-snipe those 
> who know better than I do into putting their thoughts into words.
>
> There are three ways to process JSON[1]
> - Streaming (Push or Pull)
> - Traversing a Tree (Realized or Lazy)
> - Declarative Databind (N ways)
>
> Of these, JEP-198 explicitly ruled out providing "JAXB style type safe 
> data binding."
>
> No justification is given, but if I had to insert my own: mapping the 
> Json model to/from the Java/JVM object model is a cursed combo of
> - Huge possible design space
> - Unpalatably large surface for backwards compatibility
> - Serialization! Boo![2]
>
> So for an artifact like the JDK, it probably doesn't make sense to 
> include. That tracks.
> It won't make everyone happy, people like databind APIs, but it tracks.
>
> So for the "read flow" these are the things to figure out.
>
> ? ? ? ? ? ? ? ? | Should Provide? | Intended User(s) |
> ----------------+-----------------+------------------+
> ?Streaming Push | ? ? ? ? ? ? ? ? | ? ? ? ? ? ? ? ? ?|
> ----------------+-----------------+------------------+
> ?Streaming Pull | ? ? ? ? ? ? ? ? | ? ? ? ? ? ? ? ? ?|
> ----------------+-----------------+------------------+
> ?Realized Tree ?| ? ? ? ? ? ? ? ? | ? ? ? ? ? ? ? ? ?|
> ----------------+-----------------+------------------+
> ?Lazy Tree ? ? ?| ? ? ? ? ? ? ? ? | ? ? ? ? ? ? ? ? ?|
> ----------------+-----------------+------------------+
>
> At which point, we should talk about what "meets needs of Java 
> developers using JSON" implies.
>
> JSON is ubiquitous. Most kinds of software us schmucks write could 
> have a reason to interact with it.
> The full set of "user personas" therefore aren't practical for me to 
> talk about.[3]
>
> JSON documents, however, are not so varied.
>
> - There are small ones (1-10kb)
> - There are medium ones (10-1000kb)
> - There are big ones (1000kb-???)
>
> - There are shallow ones
> - There are deep ones
>
> So that feels like an easier direction to talk about it from.
>
>
> This repo[4] has some convenient toy examples of how some of those 
> APIs look in libraries
> in the ecosystem. Specifically the Streaming Pull and Realized Tree 
> models.
>
> ? ? ? ? User r = new User();
> ? ? ? ? while (true) {
> ? ? ? ? ? ? JsonToken token = reader.peek();
> ? ? ? ? ? ? switch (token) {
> ? ? ? ? ? ? ? ? case BEGIN_OBJECT:
> ? ? ? ? ? ? ? ? ? ? reader.beginObject();
> ? ? ? ? ? ? ? ? ? ? break;
> ? ? ? ? ? ? ? ? case END_OBJECT:
> ? ? ? ? ? ? ? ? ? ? reader.endObject();
> ? ? ? ? ? ? ? ? ? ? return r;
> ? ? ? ? ? ? ? ? case NAME:
> ? ? ? ? ? ? ? ? ? ? String fieldname = reader.nextName();
> ? ? ? ? ? ? ? ? ? ? switch (fieldname) {
> ? ? ? ? ? ? ? ? ? ? ? ? case "id":
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? r.setId(reader.nextString());
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? break;
> ? ? ? ? ? ? ? ? ? ? ? ? case "index":
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? r.setIndex(reader.nextInt());
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? break;
> ? ? ? ? ? ? ? ? ? ? ? ? ...
> ? ? ? ? ? ? ? ? ? ? ? ? case "friends":
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? r.setFriends(new ArrayList<>());
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? Friend f = null;
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? carryOn = true;
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? while (carryOn) {
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? token = reader.peek();
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? switch (token) {
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? case BEGIN_ARRAY:
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? reader.beginArray();
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? break;
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? case END_ARRAY:
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? reader.endArray();
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? carryOn = false;
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? break;
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? case BEGIN_OBJECT:
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? reader.beginObject();
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? f = new Friend();
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? break;
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? case END_OBJECT:
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? reader.endObject();
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? r.getFriends().add(f);
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? break;
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? case NAME:
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? String fn = reader.nextName();
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? switch (fn) {
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? case "id":
> f.setId(reader.nextString());
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? break;
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? case "name":
> f.setName(reader.nextString());
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? break;
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? }
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? break;
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? }
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? }
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? break;
> ? ? ? ? ? ? ? ? ? ? }
> ? ? ? ? ? ? }
>
> I think its not hard to argue that the streaming apis are brutalist. 
> The above is Gson, but Jackson, moshi, etc
> seem at least morally equivalent.
>
> Its hard to write, hard to write *correctly*, and theres is a curious 
> protensity towards pairing it
> with anemic, mutable models.
>
> That being said, it handles big documents and deep documents really 
> well. It also performs
> pretty darn well and is good enough as a "fallback" when the intended 
> user experience
> is through something like databind.
>
> So what could we do meaningfully better with the language we have 
> today/will have tommorow?
>
> - Sealed interfaces + Pattern matching could give a nicer model for tokens
>
> ? ? ? ? sealed interface JsonToken {
> ? ? ? ? ? ? record Field(String name) implements JsonToken {}
> ? ? ? ? ? ? record BeginArray() implements JsonToken {}
> ? ? ? ? ? ? record EndArray() implements JsonToken {}
> ? ? ? ? ? ? record BeginObject() implements JsonToken {}
> ? ? ? ? ? ? record EndObject() implements JsonToken {}
> ? ? ? ? ? ? // ...
> ? ? ? ? }
>
> ? ? ? ? // ...
>
> ? ? ? ? User r = new User();
> ? ? ? ? while (true) {
> ? ? ? ? ? ? JsonToken token = reader.peek();
> ? ? ? ? ? ? switch (token) {
> ? ? ? ? ? ? ? ? case BeginObject __:
> ? ? ? ? ? ? ? ? ? ? reader.beginObject();
> ? ? ? ? ? ? ? ? ? ? break;
> ? ? ? ? ? ? ? ? case EndObject __:
> ? ? ? ? ? ? ? ? ? ? reader.endObject();
> ? ? ? ? ? ? ? ? ? ? return r;
> ? ? ? ? ? ? ? ? case Field("id"):
> ? ? ? ? ? ? ? ? ? ? r.setId(reader.nextString());
> ? ? ? ? ? ? ? ? ? ? break;
> ? ? ? ? ? ? ? ? case Field("index"):
> ? ? ? ? ? ? ? ? ? ? r.setIndex(reader.nextInt());
> ? ? ? ? ? ? ? ? ? ? break;
>
> ? ? ? ? ? ? ? ? // ...
>
> ? ? ? ? ? ? ? ? case Field("friends"):
> ? ? ? ? ? ? ? ? ? ? r.setFriends(new ArrayList<>());
> ? ? ? ? ? ? ? ? ? ? Friend f = null;
> ? ? ? ? ? ? ? ? ? ? carryOn = true;
> ? ? ? ? ? ? ? ? ? ? while (carryOn) {
> ? ? ? ? ? ? ? ? ? ? ? ? token = reader.peek();
> ? ? ? ? ? ? ? ? ? ? ? ? switch (token) {
> ? ? ? ? ? ? ? ? // ...
>
> - Value classes can make it all more efficient
>
> ? ? ? ? sealed interface JsonToken {
> ? ? ? ? ? ? value record Field(String name) implements JsonToken {}
> ? ? ? ? ? ? value record BeginArray() implements JsonToken {}
> ? ? ? ? ? ? value record EndArray() implements JsonToken {}
> ? ? ? ? ? ? value record BeginObject() implements JsonToken {}
> ? ? ? ? ? ? value record EndObject() implements JsonToken {}
> ? ? ? ? ? ? // ...
> ? ? ? ? }
>
> - (Fun One) We can transform a simpler-to-write push parser into a 
> pull parser with Coroutines
>
> ? ? This is just a toy we could play with while making something in 
> the JDK. I'm pretty sure
> ? ? we could make a parser which feeds into something like
>
> ? ? ? ? interface Listener {
> ? ? ? ? ? ? void onObjectStart();
> ? ? ? ? ? ? void onObjectEnd();
> ? ? ? ? ? ? void onArrayStart();
> ? ? ? ? ? ? void onArrayEnd();
> ? ? ? ? ? ? void onField(String name);
> ? ? ? ? ? ? // ...
> ? ? ? ? }
>
> ? ? and invert a loop like
>
> ? ? ? ? while (true) {
> ? ? ? ? ? ? char c = next();
> ? ? ? ? ? ? switch (c) {
> ? ? ? ? ? ? ? ? case '{':
> ? ? ? ? ? ? ? ? ? ? listener.onObjectStart();
> ? ? ? ? ? ? ? ? ? ? // ...
> ? ? ? ? ? ? ? ? // ...
> ? ? ? ? ? ? }
> ? ? ? ? }
>
> ? ? by putting a Coroutine.yield in the callback.
>
> ? ? That might be a meaningful simplification in code structure, I 
> don't know enough to say.
>
> But, I think there are some hard questions like
>
> - Is the intent[5] to be make backing parser for ecosystem databind apis?
> - Is the intent that users who want to handle big/deep documents fall 
> back to this?
> - Are those new language features / conveniences enough to offset the 
> cost of committing to a new api?
> - To whom exactly does a low level api provide value?
> - What benefit is standardization in the JDK?
>
> and just generally - who would be the consumer(s) of this?
>
> The other kind of API still on the table is a Tree. There are two ways 
> to handle this
>
> 1. Load it into `Object`. Use a bunch of instanceof checks/casts to 
> confirm what it actually is.
>
> ? ? ? ? Object v;
> ? ? ? ? User u = new User();
>
> ? ? ? ? if ((v = jso.get("id")) != null) {
> ? ? ? ? ? ? u.setId((String) v);
> ? ? ? ? }
> ? ? ? ? if ((v = jso.get("index")) != null) {
> ? ? ? ? ? ? u.setIndex(((Long) v).intValue());
> ? ? ? ? }
> ? ? ? ? if ((v = jso.get("guid")) != null) {
> ? ? ? ? ? ? u.setGuid((String) v);
> ? ? ? ? }
> ? ? ? ? if ((v = jso.get("isActive")) != null) {
> ? ? ? ? ? ? u.setIsActive(((Boolean) v));
> ? ? ? ? }
> ? ? ? ? if ((v = jso.get("balance")) != null) {
> ? ? ? ? ? ? u.setBalance((String) v);
> ? ? ? ? }
> ? ? ? ? // ...
> ? ? ? ? if ((v = jso.get("latitude")) != null) {
> ? ? ? ? ? ? u.setLatitude(v instanceof BigDecimal ? ((BigDecimal) 
> v).doubleValue() : (Double) v);
> ? ? ? ? }
> ? ? ? ? if ((v = jso.get("longitude")) != null) {
> ? ? ? ? ? ? u.setLongitude(v instanceof BigDecimal ? ((BigDecimal) 
> v).doubleValue() : (Double) v);
> ? ? ? ? }
> ? ? ? ? if ((v = jso.get("greeting")) != null) {
> ? ? ? ? ? ? u.setGreeting((String) v);
> ? ? ? ? }
> ? ? ? ? if ((v = jso.get("favoriteFruit")) != null) {
> ? ? ? ? ? ? u.setFavoriteFruit((String) v);
> ? ? ? ? }
> ? ? ? ? if ((v = jso.get("tags")) != null) {
> ? ? ? ? ? ? List<Object> jsonarr = (List<Object>) v;
> ? ? ? ? ? ? u.setTags(new ArrayList<>());
> ? ? ? ? ? ? for (Object vi : jsonarr) {
> ? ? ? ? ? ? ? ? u.getTags().add((String) vi);
> ? ? ? ? ? ? }
> ? ? ? ? }
> ? ? ? ? if ((v = jso.get("friends")) != null) {
> ? ? ? ? ? ? List<Object> jsonarr = (List<Object>) v;
> ? ? ? ? ? ? u.setFriends(new ArrayList<>());
> ? ? ? ? ? ? for (Object vi : jsonarr) {
> ? ? ? ? ? ? ? ? Map<String, Object> jso0 = (Map<String, Object>) vi;
> ? ? ? ? ? ? ? ? Friend f = new Friend();
> ? ? ? ? ? ? ? ? f.setId((String) jso0.get("id"));
> ? ? ? ? ? ? ? ? f.setName((String) jso0.get("name"));
> ? ? ? ? ? ? ? ? u.getFriends().add(f);
> ? ? ? ? ? ? }
> ? ? ? ? }
>
> 2. Have an explicit model for Json, and helper methods that do said 
> casts[6]
>
>
> this.setSiteSetting(readFromJson(jsonObject.getJsonObject("site")));
> JsonArray groups = jsonObject.getJsonArray("group");
> if(groups != null)
> {
> int len = groups.size();
> for(int i=0; i<len; i++)
> {
> JsonObject grp = groups.getJsonObject(i);
> SNMPSetting grpSetting = readFromJson(grp);
> String grpName = grp.getString("dbgroup", null);
> if(grpName != null && grpSetting != null)
> this.groupSettings.put(grpName, grpSetting);
> }
> }
> JsonArray hosts = jsonObject.getJsonArray("host");
> if(hosts != null)
> {
> int len = hosts.size();
> for(int i=0; i<len; i++)
> {
> JsonObject host = hosts.getJsonObject(i);
> SNMPSetting hostSetting = readFromJson(host);
> String hostName = host.getString("dbhost", null);
> if(hostName != null && hostSetting != null)
> this.hostSettings.put(hostName, hostSetting);
> }
> }
>
> I think what has become easier to represent in the language nowadays 
> is that explicit model for Json.
> Its the 101 lesson of sealed interfaces.[7] It feels nice and clean.
>
> ? ? ? ? sealed interface Json {
> ? ? ? ? ? ? final class Null implements Json {}
> ? ? ? ? ? ? final class True implements Json {}
> ? ? ? ? ? ? final class False implements Json {}
> ? ? ? ? ? ? final class Array implements Json {}
> ? ? ? ? ? ? final class Object implements Json {}
> ? ? ? ? ? ? final class String implements Json {}
> ? ? ? ? ? ? final class Number implements Json {}
> ? ? ? ? }
>
> And the cast-and-check approach is now more viable on account of 
> pattern matching.
>
> ? ? ? ? if (jso.get("id") instanceof String v) {
> ? ? ? ? ? ? u.setId(v);
> ? ? ? ? }
> ? ? ? ? if (jso.get("index") instanceof Long v) {
> ? ? ? ? ? ? u.setIndex(v.intValue());
> ? ? ? ? }
> ? ? ? ? if (jso.get("guid") instanceof String v) {
> ? ? ? ? ? ? u.setGuid(v);
> ? ? ? ? }
>
> ? ? ? ? // or
>
> ? ? ? ? if (jso.get("id") instanceof String id &&
> ? ? ? ? ? ? ? ? jso.get("index") instanceof Long index &&
> ? ? ? ? ? ? ? ? jso.get("guid") instanceof String guid) {
> ? ? ? ? ? ? return new User(id, index, guid, ...); // look ma, no setters!
> ? ? ? ? }
>
>
> And on the horizon, again, is value types.
>
> But there are problems with this approach beyond the performance 
> implications of loading into
> a tree.
>
> For one, all the code samples above have different behaviors around 
> null keys and missing keys
> that are not obvious from first glance.
>
> This won't accept any null or missing fields
>
> ? ? ? ? if (jso.get("id") instanceof String id &&
> ? ? ? ? ? ? ? ? jso.get("index") instanceof Long index &&
> ? ? ? ? ? ? ? ? jso.get("guid") instanceof String guid) {
> ? ? ? ? ? ? return new User(id, index, guid, ...);
> ? ? ? ? }
>
> This will accept individual null or missing fields, but also will 
> silently ignore
> fields with incorrect types
>
> ? ? ? ? if (jso.get("id") instanceof String v) {
> ? ? ? ? ? ? u.setId(v);
> ? ? ? ? }
> ? ? ? ? if (jso.get("index") instanceof Long v) {
> ? ? ? ? ? ? u.setIndex(v.intValue());
> ? ? ? ? }
> ? ? ? ? if (jso.get("guid") instanceof String v) {
> ? ? ? ? ? ? u.setGuid(v);
> ? ? ? ? }
>
> And, compared to databind where there is information about the 
> expected structure of the document
> and its the job of the framework to assert that, I posit that the 
> errors that would be encountered
> when writing code against this would be more like
>
> ? ? "something wrong with user"
>
> than
>
> ? ? "problem at users[5].name, expected string or null. got 5"
>
> Which feels unideal.
>
>
> One approach I find promising is something close to what Elm does with 
> its decoders[8]. Not just combining assertion
> and binding like what pattern matching with records allows, but 
> including a scheme for bubbling/nesting errors.
>
> ? ? static String string(Json json) throws JsonDecodingException {
> ? ? ? ? if (!(json instanceof Json.String jsonString)) {
> ? ? ? ? ? ? throw JsonDecodingException.of(
> ? ? ? ? ? ? ? ? ? ? "expected a string",
> ? ? ? ? ? ? ? ? ? ? json
> ? ? ? ? ? ? );
> ? ? ? ? } else {
> ? ? ? ? ? ? return jsonString.value();
> ? ? ? ? }
> ? ? }
>
> ? ? static <T> T field(Json json, String fieldName, Decoder<? extends 
> T> valueDecoder) throws JsonDecodingException {
> ? ? ? ? var jsonObject = object(json);
> ? ? ? ? var value = jsonObject.get(fieldName);
> ? ? ? ? if (value == null) {
> ? ? ? ? ? ? throw JsonDecodingException.atField(
> ? ? ? ? ? ? ? ? ? ? fieldName,
> ? ? ? ? ? ? ? ? ? ? JsonDecodingException.of(
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? "no value for field",
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? json
> ? ? ? ? ? ? ? ? ? ? )
> ? ? ? ? ? ? );
> ? ? ? ? }
> ? ? ? ? else {
> ? ? ? ? ? ? try {
> ? ? ? ? ? ? ? ? return valueDecoder.decode(value);
> ? ? ? ? ? ? } catch (JsonDecodingException e) {
> ? ? ? ? ? ? ? ? throw JsonDecodingException.atField(
> ? ? ? ? ? ? ? ? ? ? ? ? fieldName,
> ? ? ? ? ? ? ? ? ? ? ? ? e
> ? ? ? ? ? ? ? ? );
> ? ? ? ? ? ? } ?catch (Exception e) {
> ? ? ? ? ? ? ? ? throw JsonDecodingException.atField(fieldName, 
> JsonDecodingException.of(e, value));
> ? ? ? ? ? ? }
> ? ? ? ? }
> ? ? }
>
> Which I think has some benefits over the ways I've seen of working 
> with trees.
>
>
>
> - It is declarative enough that folks who prefer databind might be 
> happy enough.
>
> ? ? ? ? static User fromJson(Json json) {
> ? ? ? ? ? ? return new User(
> ? ? ? ? ? ? ? ? Decoder.field(json, "id", Decoder::string),
> ? ? ? ? ? ? ? ? Decoder.field(json, "index", Decoder::long_),
> ? ? ? ? ? ? ? ? Decoder.field(json, "guid", Decoder::string),
> ? ? ? ? ? ? );
> ? ? ? ? }
>
> ? ? ? ? / ...
>
> ? ? ? ? List<User> users = Decoders.array(json, User::fromJson);
>
> - Handling null and optional fields could be less easily conflated
>
> ? ? Decoder.field(json, "id", Decoder::string);
>
> ? ? Decoder.nullableField(json, "id", Decoder::string);
>
> ? ? Decoder.optionalField(json, "id", Decoder::string);
>
> ? ? Decoder.optionalNullableField(json, "id", Decoder::string);
>
>
> - It composes well with user defined classes
>
> ? ? record Guid(String value) {
> ? ? ? ? Guid {
> ? ? ? ? ? ? // some assertions on the structure of value
> ? ? ? ? }
> ? ? }
>
> ? ? Decoder.string(json, "guid", guid -> new Guid(Decoder.string(guid)));
>
> ? ? // or even
>
> ? ? record Guid(String value) {
> ? ? ? ? Guid {
> ? ? ? ? ? ? // some assertions on the structure of value
> ? ? ? ? }
>
> ? ? ? ? static Guid fromJson(Json json) {
> ? ? ? ? ? ? return new Guid(Decoder.string(guid));
> ? ? ? ? }
> ? ? }
>
> ? ? Decoder.string(json, "guid", Guid::fromJson);
>
>
> - When something goes wrong, the API can handle the fiddlyness of 
> capturing information for feedback.
>
> ? ? In the code I've sketched out its just what field/index things 
> went wrong at. Potentially
> ? ? capturing metadata like row/col numbers of the source would be 
> sensible too.
>
> ? ? Its just not reasonable to expect devs to do extra work to get 
> that and its really nice to give it.
>
> There are also some downsides like
>
> - ?I do not know how compatible it would be with lazy trees.
>
> ? ? ?Lazy trees being the only way that a tree api could handle big or 
> deep documents.
> ? ? ?The general concept as applied in libraries like json-tree[9] is 
> to navigate without
> ? ? ?doing any work, and that clashes with wanting to instanceof check 
> the info at the
> ? ? ?current path.
>
> - It *almost* gives enough information to be a general schema approach
>
> ? ? If one field fails, that in the model throws an exception 
> immediately. If an API should
> ? ? return "errors": [...], that is inconvenient to construct.
>
> - None of the existing popular libraries are doing this
>
> ? ? ?The only mechanics that are strictly required to give this sort 
> of API is lambdas. Those have
> ? ? ?been out for a decade. Yes sealed interfaces make the data model 
> prettier but in concept you
> ? ? ?can build the same thing on top of anything.
>
> ? ? ?I could argue that this is because of "cultural momentum" of 
> databind or some other reason,
> ? ? ?but the fact remains that it isn't a proven out approach.
>
> ? ? ?Writing Json libraries is a todo list[10]. There are a lot of bad 
> ideas and this might be one of the,
>
> - Performance impact of so many instanceof checks
>
> ? ? I've gotten a 4.2% slowdown compared to the "regular" tree code 
> without the repeated casts.
>
> ? ? But that was with a parser that is 5x slower than Jacksons. (using 
> the same benchmark project as for the snippets).
> ? ? I think there could be reason to believe that the JIT does well 
> enough with repeated instanceof
> ? ? checks to consider it.
>
>
> My current thinking is that - despite not solving for large or deep 
> documents - starting with a really "dumb" realized tree api
> might be the right place to start for the read side of a potential 
> incubator module.
>
> But regardless - this feels like a good time to start more concrete 
> conversations. I fell I should cap this email since I've reached the 
> point of decoherence and haven't even mentioned the write side of things
>
>
>
>
> [1]: http://www.cowtowncoder.com/blog/archives/2009/01/entry_131.html
> [2]: https://security.snyk.io/vuln/maven?search=jackson-databind
> [3]: I only know like 8 people
> [4]: 
> https://github.com/fabienrenaud/java-json-benchmark/blob/master/src/main/java/com/github/fabienrenaud/jjb/stream/UsersStreamDeserializer.java
> [5]: When I say "intent", I do so knowing full well no one has been 
> actively thinking of this for an entire Game of Thrones
> [6]: 
> https://github.com/yahoo/mysql_perf_analyzer/blob/master/myperf/src/main/java/com/yahoo/dba/perf/myperf/common/SNMPSettings.java
> [7]: https://www.infoq.com/articles/data-oriented-programming-java/
> [8]: https://package.elm-lang.org/packages/elm/json/latest/Json-Decode
> [9]: https://github.com/jbee/json-tree
> [10]: https://stackoverflow.com/a/14442630/2948173
> [11]: In 30 days JEP-198 it will be recognizably PI days old for the 
> 2nd time in its history.
> [12]: To me, the fact that is still an open JEP is more a social 
> convenience than anything. I could just as easily writing this exact 
> same email about TOML.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20230228/ffac5f29/attachment-0001.htm>

From smarks at openjdk.org  Tue Feb 28 19:48:10 2023
From: smarks at openjdk.org (Stuart Marks)
Date: Tue, 28 Feb 2023 19:48:10 GMT
Subject: RFR: 8302590: Add String.indexOf(int ch, int fromIndex,
 int toIndex) [v3]
In-Reply-To: <VY-Hm8owXgm5vjfxkW7wmnb_TqRsZyMSme4HcSTywyo=.f48897d4-c587-4594-b0b1-b79703e6ec33@github.com>
References: <uQ65oRaVDfpzm9bYRuo_MvSuZIdepicE3GnB3Omyngs=.fc23545b-141a-47e5-8a6a-aa28ae1375e5@github.com>
 <VY-Hm8owXgm5vjfxkW7wmnb_TqRsZyMSme4HcSTywyo=.f48897d4-c587-4594-b0b1-b79703e6ec33@github.com>
Message-ID: <ZZPOOWMagAfp8h9jFakH3bMjJO1SNkR_0An8UdGMEU4=.b56add44-942d-4b55-a3f4-a69a3f96e226@github.com>

On Tue, 28 Feb 2023 13:31:56 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> Add an `indexOf()` variant allowing to specify both a lower and an upper bound on the search.
>
> Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8302590: Add String.indexOf(int ch, int fromIndex, int toIndex)

In concept, having APIs that search a string subrange is a fine idea. Unfortunately the exception handling policy is an issue. We need to think through this carefully.

Currently, almost everything that takes some kind of String index or subrange will throw IndexOutOfBoundsException if the arguments are ill-specified in some fashion. There are a few notable outliers though:

    indexOf(int ch, int fromIndex)
    indexOf(String str, int fromIndex)
    lastIndexOf(int ch, int fromIndex)
    lastIndexOf(String str, int fromIndex)
    regionMatches(boolean ignoreCase, int toffset, String other, int ooffset, int len)
    regionMatches(int toffset, String other, int ooffset, int len)

They don't throw any exceptions for ill-defined values; instead, they return -1 or false which is indistinguishable from "not found". These APIs date all the way back to 1.0. Note that the JDK 1.0 String wasn't internally consistent. For example, other 1.0-era methods like `substring` throw StringIndexOutOfBoundsException.

The prevailing API style since that time has been to check arguments and throw the appropriate exceptions, instead of masking ill-defined values by returning "not found". This tends to reveal errors earlier instead of covering them up. Compared to the existing `indexOf` methods (which specify a single starting index), the new `indexOf` method specifies a subrange; this allows a new class of "end < start" errors. It seems strange not to throw any exception for this additional class of errors.

In understand the desire to be consistent with the existing methods. Adding a new non-throwing method seems like a mistake though. It's perpetuating an old API design mistake for the sake of consistency, while also being inconsistent with current API design style.

I also don't think it's necessary to have both throwing and non-throwing methods.

I'd suggest returning to the original `indexOf(ch, from, to)` proposal, but instead having it check its subrange arguments and throwing IndexOutOfBoundsException. I don't think the exception handling inconsistency with the existing methods is that bad. If people really, really object to it, then maybe it would be necessary to choose a new name for the new method (and not introduce two versions). But choosing a good name is hard, and it introduces issues such as discoverability and questions about how the new thing differs from the existing methods, so I'm skeptical that choosing a different name would be any better.

Another possible mitigation is to add API notes to highlight the unusual behavior of the old non-throwing methods. Some of these old methods don't mention their handling of illegal index values at all. (This could be done as part of a separate PR.)

-------------

PR: https://git.openjdk.org/jdk/pull/12600

From duke at openjdk.org  Tue Feb 28 20:28:56 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Tue, 28 Feb 2023 20:28:56 GMT
Subject: RFR: 8303401: Add a Vector API equalsIgnoreCase micro benchmark
Message-ID: <FbxtEB-ECOJ65eF7cdhkISphjqC4Ks1jxYgbML2_xwk=.56cf8152-e227-4412-9e30-0ecb020a65f3@github.com>

This PR suggests we add a vectorized equalsIgnoreCase benchmark to the set of benchmarks in `org.openjdk.bench.jdk.incubator.vector`. This benchmark serves as an example of how vectorization can be useful also in the area of text processing. It takes advantage of the fact that ASCII and Latin-1 were designed to optimize case-twiddling operations.

The code came about during the work on #12632, where vectorization was deemed out of scope.

Benchmark results:


Benchmark                             (size)  Mode  Cnt     Score   Error  Units
EqualsIgnoreCaseBenchmark.scalar          16  avgt   15    20.671 ? 0.718  ns/op
EqualsIgnoreCaseBenchmark.scalar          32  avgt   15    46.155 ? 3.258  ns/op
EqualsIgnoreCaseBenchmark.scalar          64  avgt   15    68.248 ? 1.767  ns/op
EqualsIgnoreCaseBenchmark.scalar         128  avgt   15   148.948 ? 0.890  ns/op
EqualsIgnoreCaseBenchmark.scalar        1024  avgt   15  1090.708 ? 7.540  ns/op
EqualsIgnoreCaseBenchmark.vectorized      16  avgt   15    21.872 ? 0.232  ns/op
EqualsIgnoreCaseBenchmark.vectorized      32  avgt   15    11.378 ? 0.097  ns/op
EqualsIgnoreCaseBenchmark.vectorized      64  avgt   15    13.703 ? 0.135  ns/op
EqualsIgnoreCaseBenchmark.vectorized     128  avgt   15    21.632 ? 0.735  ns/op
EqualsIgnoreCaseBenchmark.vectorized    1024  avgt   15   105.509 ? 7.493  ns/op

-------------

Commit messages:
 - Remove references to 'the oldest ASCII trick in the book'
 - Merge branch 'master' into vectorized-equalsignorecase
 - Fix "using applying"
 - Benchmark for exploring a vectorized latin1 equalsIgnoreCase

Changes: https://git.openjdk.org/jdk/pull/12790/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12790&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8303401
  Stats: 152 lines in 1 file changed: 152 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/12790.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12790/head:pull/12790

PR: https://git.openjdk.org/jdk/pull/12790

From bpb at openjdk.org  Tue Feb 28 20:42:45 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 28 Feb 2023 20:42:45 GMT
Subject: RFR: 8303175: (fs) Deprecate
 com.sun.nio.file.SensitivityWatchEventModifier for removal [v3]
In-Reply-To: <s7IRC6buEQ5NrNc4XW3lIf6wpdfBksPrIjuTnTO99Gc=.380f3194-e6e7-4c55-b322-2fff1984cd4a@github.com>
References: <s7IRC6buEQ5NrNc4XW3lIf6wpdfBksPrIjuTnTO99Gc=.380f3194-e6e7-4c55-b322-2fff1984cd4a@github.com>
Message-ID: <uqagw1aTNOykMlo6W9qqxDe9-Krq9ZGFX9qcMXQt_iI=.c4077e5c-35a3-4cd8-9379-fd57a176128e@github.com>

> Deprecate `SensitivityWatchEventModifier` for now instead of directly removing it as proposed in #12626.

Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:

  8303175: Change since value of @Deprecated annotation from 7 to 21

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12746/files
  - new: https://git.openjdk.org/jdk/pull/12746/files/b3ea4f71..f00174e5

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12746&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12746&range=01-02

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/12746.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12746/head:pull/12746

PR: https://git.openjdk.org/jdk/pull/12746

From bpb at openjdk.org  Tue Feb 28 20:42:50 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 28 Feb 2023 20:42:50 GMT
Subject: RFR: 8303175: (fs) Deprecate
 com.sun.nio.file.SensitivityWatchEventModifier for removal [v2]
In-Reply-To: <UwTYhNKsinnZDppqa0-ivzSLOnhYvYB1lQWojCVpH90=.c528101d-afd2-49dc-a5dd-b9891c39c1d7@github.com>
References: <s7IRC6buEQ5NrNc4XW3lIf6wpdfBksPrIjuTnTO99Gc=.380f3194-e6e7-4c55-b322-2fff1984cd4a@github.com>
 <mRL4BzPPcM-KIX3prN-P5REG13aES0ilBAJEPybK-Dk=.8302a2e9-80a5-46c2-8b13-4e2332d47b04@github.com>
 <UwTYhNKsinnZDppqa0-ivzSLOnhYvYB1lQWojCVpH90=.c528101d-afd2-49dc-a5dd-b9891c39c1d7@github.com>
Message-ID: <klZAb3LPDF7dCO1xi94JFzpnxIDzTU3cGF15D59mRHs=.79828aa3-92ee-4e5f-b9fb-c67eca60ac62@github.com>

On Tue, 28 Feb 2023 11:09:33 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8303175: Move @deprecated above @since; tweak verbiage
>
> src/jdk.unsupported/share/classes/com/sun/nio/file/SensitivityWatchEventModifier.java line 45:
> 
>> 43:  */
>> 44: 
>> 45: @Deprecated(since="7", forRemoval = true)
> 
> I assume this should be "21" rather than "7"

_Mea culpa_. Fixed in f00174e5f70295dff2aa2abd16559dbc81696d2d.

-------------

PR: https://git.openjdk.org/jdk/pull/12746

From jvernee at openjdk.org  Tue Feb 28 21:06:23 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Tue, 28 Feb 2023 21:06:23 GMT
Subject: RFR: 8303040: linux PPC64le: Implementation of Foreign Function &
 Memory API (Preview) [v3]
In-Reply-To: <8b3vVrV22RuhdRoRYacXV0ZeghFGgKkC8S_z-iMrzAQ=.dd84b743-8b51-4281-8f5f-f9eff6207bc7@github.com>
References: <Yuxy6FrsDAN79ya8w8UIkvytGr25zGllDPtPJ1QbGwc=.182664b2-6d8c-497e-a4ae-95e0ad007cf9@github.com>
 <8b3vVrV22RuhdRoRYacXV0ZeghFGgKkC8S_z-iMrzAQ=.dd84b743-8b51-4281-8f5f-f9eff6207bc7@github.com>
Message-ID: <ubsdQFbNzTtdhNeZwCJyA5BRc2mR4AmQwk6hgJOlBy0=.6974c426-eeb2-4212-8038-9a8e00a0e7de@github.com>

On Thu, 23 Feb 2023 06:18:49 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> Implementation of "Foreign Function & Memory API" for linux on Power (Little Endian) according to "Power Architecture 64-Bit ELF V2 ABI Specification".
>> 
>> This PR does not include code for VaList support because it's supposed to get removed by [JDK-8299736](https://bugs.openjdk.org/browse/JDK-8299736). I've kept the related tests disabled for this platform and throw an exception instead. Note that the ABI doesn't precisely specify variable argument lists. Instead, it refers to `<stdarg.h>` (2.2.4 Variable Argument Lists).
>> 
>> Big Endian support is implemented to some extend, but not complete. E.g. structs with size not divisible by 8 are not passed correctly (see `useABIv2` in CallArranger.java). Big Endian is excluded by selecting `ARCH.equals("ppc64le")` (CABI.java) only.
>> 
>> There's another limitation: This PR only accepts structures with size divisible by 4. (An `IllegalArgumentException` gets thrown otherwise.) I think arbitrary sizes are not usable on other platforms, either, because `SharedUtils.primitiveCarrierForSize` only accepts powers of 2.
>> 
>> The ABI has some tricky corner cases related to HFA (Homogeneous Float Aggregate). The same argument may need to get passed in both, a FP reg and a GP reg or stack slot (see "no partial DW rule"). This cases are not covered by the existing tests.
>> 
>> I had to make changes to shared code and code for other platforms:
>> 1. Pass type information when creating `VMStorage` objects from `VMReg`. This is needed for the following reasons:
>> - PPC64 ABI requires integer types to get extended to 64 bit (also see CCallingConventionRequiresIntsAsLongs in existing hotspot code). We need to know the type or at least the bit width for that.
>> - Floating point load / store instructions need the correct width to select between the correct IEEE 754 formats. The register representation in single FP registers is always IEEE 754 double precision on PPC64.
>> - Big Endian also needs usage of the precise size. Storing 8 Bytes and loading 4 Bytes yields different values than on Little Endian!
>> 2. It happens that a `NativeMemorySegmentImpl` is used as a raw pointer (with byteSize() == 0) while running TestUpcallScope. Hence, existing size checks don't work (see MemorySegment.java). As a workaround, I'm just skipping the check in this particular case. Please check if this makes sense or if there's a better fix (possibly as separate RFE).
>
> Martin Doerr has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove size restriction for structs. Add TODO for Big Endian.

This looks good overall I think, though I'll stick to my previous suggestion to try and move more logic into Java.

Also, I recommend adding a test in `java/foreign/callarranger` similar to the tests already found there. They call the CallGenerator directly and then check the binding recipe. This could prove useful if we need to refactor shared code for whatever reason, since those tests run on (almost) every platform, so can be used to do some basic sanity checking.

src/hotspot/cpu/ppc/downcallLinker_ppc.cpp line 133:

> 131:   Register callerSP            = R2, // C/C++ uses R2 as TOC, but we can reuse it here
> 132:            tmp                 = R11_scratch1, // same as shuffle_reg
> 133:            call_target_address = R12_scratch2; // same as _abi._scratch2 (ABIv2 requires this reg!)

Do I understand correctly that the ABI requires the register to be used for the call to be `R12`? How does that make a difference? I guess in some cases the callee might want to know the address through which it is called? (so it looks at `R12`)

src/hotspot/cpu/ppc/downcallLinker_ppc.cpp line 154:

> 152:   // (abi_reg_args is abi_minframe plus space for 8 argument register spill slots)
> 153:   assert(_abi._shadow_space_bytes == frame::abi_minframe_size, "expected space according to ABI");
> 154:   int allocated_frame_size = frame::abi_minframe_size + MAX2(_input_registers.length(), 8) * BytesPerWord;

This is hard-coding an assumption about the ABI that's being called. Ok for now.

If it needs to be addressed in the future, it could be done by adding another field to `ABIDescriptor` like `min_stack_arg_bytes`, or something like that (which is set to zero for other ABIs). It seems to be different from `shadow_space` since it's also used by the caller to put stack arguments.

src/hotspot/cpu/ppc/downcallLinker_ppc.cpp line 343:

> 341: 
> 342:   __ flush();
> 343:   // Disassembler::decode((u_char*)start, (u_char*)__ pc(), tty);

Leftover commented code?

(note that the stub can also be disassembled with `-Xlog:foreign+downcall=trace` now)

src/hotspot/cpu/ppc/foreignGlobals_ppc.cpp line 229:

> 227: 
> 228: void ArgumentShuffle::pd_generate(MacroAssembler* masm, VMStorage tmp, int in_stk_bias, int out_stk_bias, const StubLocations& locs) const {
> 229:   Register callerSP = as_Register(tmp); // preset

It looks like `tmp` is being used to hold the caller's SP. I'm guessing this can not be computed the same way as we do on x86 and aarch64? (based on `RBP`, `RFP_BIAS`)

If you want, you could add another register argument to `pd_generate` that is just invalid/unused on other platforms. That way you could use `tmp` for the shuffling instead of having to go through the stack. (looks like `R0` is already used in some cases as a temp register)

src/hotspot/cpu/ppc/upcallLinker_ppc.cpp line 137:

> 135:   ArgumentShuffle arg_shuffle(in_sig_bt, total_in_args, out_sig_bt, total_out_args, &in_conv, &out_conv, shuffle_reg);
> 136:   // The Java call uses the JIT ABI, but we also call C.
> 137:   int out_arg_area = MAX2(frame::jit_out_preserve_size + arg_shuffle.out_arg_bytes(), (int)frame::abi_reg_args_size);

We need `frame::abi_reg_args_size` since we call `on_entry`/`on_exit` which require the stack space I guess?

src/hotspot/cpu/ppc/upcallLinker_ppc.cpp line 240:

> 238:   __ ld(call_target_address, in_bytes(Method::from_compiled_offset()), R19_method);
> 239:   __ mtctr(call_target_address);
> 240:   __ bctrl();

Ok, I see. I guess there is some special purpose register called `CTR` which we are moving to for `bctrl` here. Does ABIv2 require that move to always come from `R12`? (from the comment in downcallLinker).

(I'm trying to understand the requirements for possibly tweaking shared code).

src/hotspot/cpu/ppc/upcallLinker_ppc.cpp line 347:

> 345:   FunctionDescriptor* fd = (FunctionDescriptor*)fd_addr;
> 346:   fd->set_entry(fd_addr + sizeof(FunctionDescriptor));
> 347: #endif

Had to do a double take. Looks like we're not the only one who are using the name `FunctionDescriptor` :)

src/hotspot/cpu/ppc/upcallLinker_ppc.cpp line 356:

> 354:   }
> 355: #endif
> 356:   //blob->print_on(tty);

Leftover commented code?

src/java.base/share/classes/jdk/internal/foreign/abi/ppc64/CallArranger.java line 68:

> 66: public abstract class CallArranger {
> 67:     // Linux PPC64 Little Endian uses ABI v2.
> 68:     private static final boolean useABIv2 = ByteOrder.nativeOrder() == ByteOrder.LITTLE_ENDIAN;

Now that I'm here. This could be a potentially interesting case for having 2 subclasses of CallArranger: one for `useABIv2 == true` and one for `false`.

src/java.base/share/classes/jdk/internal/foreign/abi/ppc64/CallArranger.java line 81:

> 79:         new VMStorage[] { f1, f2, f3, f4, f5, f6, f7, f8 }, // FP output
> 80:         new VMStorage[] { r0, r2, r3, r4, r5, r6, r7, r8, r9, r10, r11, r12 }, // volatile GP
> 81:         new VMStorage[] { f0, f1, f2, f3, f4, f5, f6, f7, f8, f9, f10, f11, f12, f13 }, // volatile FP

Note that argument registers are assumed volatile, so they don't have to be duplicated here.

src/java.base/share/classes/jdk/internal/foreign/abi/ppc64/CallArranger.java line 286:

> 284:                 // "no partial DW rule": Mark first stack slot to get filled.
> 285:                 // Note: Can only happen with forArguments = true.
> 286:                 VMStorage overlappingReg = null;

`overlappingReg` is initialized along all branches, so it's not needed to assign `null` here.

src/java.base/share/classes/jdk/internal/foreign/abi/ppc64/CallArranger.java line 293:

> 291:                 } else {
> 292:                     overlappingReg = new VMStorage(StorageType.STACK_AND_FLOAT,
> 293:                                                    (short) STACK_SLOT_SIZE, (int) stackOffset - 4);

I think you could remove the mixed VMStorage types here relatively easily by returning a `VMStorage[][]`, where each element is a single element array, but then for the `needOverlapping` case add another element to the array for the extra store.

Then when unboxing a `STRUCT_HFA`,  `dup` the result of the `bufferLoad` and then do 2 `vmStore`s (one for each element).

For boxing, you could just ignore the extra storage, and just `vmLoad` the first one (or, whichever one you like :))

src/java.base/share/classes/jdk/internal/foreign/abi/ppc64/TypeClass.java line 66:

> 64:     }
> 65: 
> 66:     static boolean isHomogeneousFloatAggregate(MemoryLayout type, boolean useABIv2) {

Note that we had to make some changes to this routine on AArch64, since it didn't properly account for nested structs/unions and arrays. See: https://github.com/openjdk/panama-foreign/pull/780

Just as a heads up, in case PPC needs changes too.

src/java.base/share/classes/jdk/internal/foreign/abi/ppc64/linux/LinuxPPC64CallArranger.java line 33:

> 31:  * PPC64 CallArranger specialized for Linux ABI.
> 32:  */
> 33: public class LinuxPPC64CallArranger extends CallArranger {

I don't really see the point in having a separate subclass with `CallArranger` being abstract, unless you are planning to add other implementations later?

(edit: see also later comment in CallArranger https://github.com/openjdk/jdk/pull/12708#discussion_r1120753657)

-------------

PR: https://git.openjdk.org/jdk/pull/12708

From ecaspole at openjdk.org  Tue Feb 28 21:07:07 2023
From: ecaspole at openjdk.org (Eric Caspole)
Date: Tue, 28 Feb 2023 21:07:07 GMT
Subject: RFR: 8303401: Add a Vector API equalsIgnoreCase micro benchmark
In-Reply-To: <FbxtEB-ECOJ65eF7cdhkISphjqC4Ks1jxYgbML2_xwk=.56cf8152-e227-4412-9e30-0ecb020a65f3@github.com>
References: <FbxtEB-ECOJ65eF7cdhkISphjqC4Ks1jxYgbML2_xwk=.56cf8152-e227-4412-9e30-0ecb020a65f3@github.com>
Message-ID: <mJTjGv7eLWioXNibMA_RPGr9xk9uAGH8TfgcZRKJ9pA=.b5df0d2f-0aa1-45d3-bf77-9703e1e40af7@github.com>

On Tue, 28 Feb 2023 15:59:26 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

> This PR suggests we add a vectorized equalsIgnoreCase benchmark to the set of benchmarks in `org.openjdk.bench.jdk.incubator.vector`. This benchmark serves as an example of how vectorization can be useful also in the area of text processing. It takes advantage of the fact that ASCII and Latin-1 were designed to optimize case-twiddling operations.
> 
> The code came about during the work on #12632, where vectorization was deemed out of scope.
> 
> Benchmark results:
> 
> 
> Benchmark                             (size)  Mode  Cnt     Score   Error  Units
> EqualsIgnoreCaseBenchmark.scalar          16  avgt   15    20.671 ? 0.718  ns/op
> EqualsIgnoreCaseBenchmark.scalar          32  avgt   15    46.155 ? 3.258  ns/op
> EqualsIgnoreCaseBenchmark.scalar          64  avgt   15    68.248 ? 1.767  ns/op
> EqualsIgnoreCaseBenchmark.scalar         128  avgt   15   148.948 ? 0.890  ns/op
> EqualsIgnoreCaseBenchmark.scalar        1024  avgt   15  1090.708 ? 7.540  ns/op
> EqualsIgnoreCaseBenchmark.vectorized      16  avgt   15    21.872 ? 0.232  ns/op
> EqualsIgnoreCaseBenchmark.vectorized      32  avgt   15    11.378 ? 0.097  ns/op
> EqualsIgnoreCaseBenchmark.vectorized      64  avgt   15    13.703 ? 0.135  ns/op
> EqualsIgnoreCaseBenchmark.vectorized     128  avgt   15    21.632 ? 0.735  ns/op
> EqualsIgnoreCaseBenchmark.vectorized    1024  avgt   15   105.509 ? 7.493  ns/op

I am not an expert in Vector API but in terms of JMH structure it looks good.

-------------

Marked as reviewed by ecaspole (Committer).

PR: https://git.openjdk.org/jdk/pull/12790

From svaillancourt at add123.com  Tue Feb 28 21:14:20 2023
From: svaillancourt at add123.com (Sage Vaillancourt)
Date: Tue, 28 Feb 2023 16:14:20 -0500
Subject: 8281301: Map.of() calls with null argument should throw more
 contextual information.
Message-ID: <CAN3pdeVe6jdU0WEdyBkO9y6vVgpJURkOd4QxZkurf=ceK-oFhw@mail.gmail.com>

Hi there. It's my first time posting to the development list, so
please forgive any formatting errors.

My proposed change is pretty small. Basically, a pattern I see with
some frequency is calling Objects.requireNonNull(object, "objectName")
before (or within) Map.of(), because otherwise there's not much of a
way to tell _which_ parameter caused the exception. Even just an index
and key/value hint would make tracking down these types of errors
easier without that bit of boilerplate.

I'd expect that any performance impact to be negligible, already being
off the happy path, here.

Diff as I'm imagining it, but very open to suggestions:

diff --git a/src/java.base/share/classes/java/util/ImmutableCollections.java
b/src/java.base/share/classes/java/util/ImmutableCollections.java
index 3de7e1d5eae..814c1a9ec1b 100644
--- a/src/java.base/share/classes/java/util/ImmutableCollections.java
+++ b/src/java.base/share/classes/java/util/ImmutableCollections.java
@@ -1103,8 +1103,8 @@ class ImmutableCollections {
         private final V v0;

         Map1(K k0, V v0) {
-            this.k0 = Objects.requireNonNull(k0);
-            this.v0 = Objects.requireNonNull(v0);
+            this.k0 = Objects.requireNonNull(k0, () -> "Key in map
entry was null");
+            this.v0 = Objects.requireNonNull(v0, () -> "Value in map
entry was null");
         }

         @Override
@@ -1183,9 +1183,9 @@ class ImmutableCollections {

             for (int i = 0; i < input.length; i += 2) {
                 @SuppressWarnings("unchecked")
-                    K k = Objects.requireNonNull((K)input[i]);
+                    K k = Objects.requireNonNull((K)input[i], () ->
"Key for map entry " + (i / 2) + " was null");
                 @SuppressWarnings("unchecked")
-                    V v = Objects.requireNonNull((V)input[i+1]);
+                    V v = Objects.requireNonNull((V)input[i+1], () ->
"Value for map entry " + (i / 2) + " was null");
                 int idx = probe(k);
                 if (idx >= 0) {
                     throw new IllegalArgumentException("duplicate key: " + k);

-- 
This email message may contain privileged or confidential information, and 
is for the use of intended recipients only. Do not share with or forward to 
additional parties except as necessary to conduct the business for which 
this email (and attachments) was clearly intended. If you have received 
this message in error, please immediately advise the sender by reply email 
and then delete this message.

From forax at univ-mlv.fr  Tue Feb 28 21:24:44 2023
From: forax at univ-mlv.fr (Remi Forax)
Date: Tue, 28 Feb 2023 22:24:44 +0100 (CET)
Subject: JEP-198 - Lets start talking about JSON
In-Reply-To: <23c6e4b3-71d9-fa5f-f64a-1e1ae73dcb3d@oracle.com>
References: <CA+NR86hGVP2F948jFH3qo7fDQsc-W6HP-1YK6LVSCJTL5yQ+mA@mail.gmail.com>
 <23c6e4b3-71d9-fa5f-f64a-1e1ae73dcb3d@oracle.com>
Message-ID: <372744828.589866.1677619484912.JavaMail.zimbra@u-pem.fr>

> From: "Brian Goetz" <brian.goetz at oracle.com>
> To: "Ethan McCue" <ethan at mccue.dev>, "core-libs-dev"
> <core-libs-dev at openjdk.java.net>
> Sent: Tuesday, February 28, 2023 8:48:00 PM
> Subject: Re: JEP-198 - Lets start talking about JSON

> As you can probably imagine, I've been thinking about these topics for quite a
> while, ever since we started working on records and pattern matching. It sounds
> like a lot of your thoughts have followed a similar arc to ours.

> I'll share with you some of our thoughts, but I can't be engaging in a detailed
> back-and-forth right now -- we have too many other things going on, and this
> isn't yet on the front burner. I think there's a right time for this work, and
> we're not quite there yet, but we'll get there soon enough and we'll pick up
> the ball again then.

> To the existential question: yes, there should be a simpler, built-in way to
> parse JSON. And, as you observe, the railroad diagram in the JSON spec is a
> graphical description of an algebraic data type. One of the great simplifying
> effects of having algebraic data types (records + sealed classes) in the
> language is that many data modeling problems collapse down to the point where
> considerably less creativity is required of an API. Here's the JSON API one can
> write after literally only 30 seconds of thought:

>> sealed interface JsonValue {

>> record JsonString (String s)implements JsonValue { }

>> record JsonNumber (double d)implements JsonValue { }

>> record JsonNull ()implements JsonValue { }

>> record JsonBoolean ( boolean b)implements JsonValue { }

>> record JsonArray (List< JsonValue > values)implements JsonValue { }

>> record JsonObject (Map<String, JsonValue > pairs)implements JsonValue { }

>> }
> It matches the JSON spec almost literally, and you can use pattern matching to
> parse a document. (OK, there's some tiny bit of creativity here in that
> True/False have been collapsed to a single JsonBoolean type, but you get my
> point.)

> But, we're not quite ready to put this API into the JDK, because the language
> isn't *quite* there yet. Records give you nice pattern matching, but they come
> at a cost; they're very specific and have rigid ideas about initialization,
> which ripples into a number of constraints on an implementation (i.e., much
> harder to parse lazily.) So we're waiting until we have deconstruction patterns
> (next up on the patterns parade) so that the records above can be interfaces
> and still support pattern matching (and more flexibility in implementation,
> including using value classes when they arrive.) It's not a long hop, though.

> I agree with your assessment of streaming models; for documents too large to fit
> into memory, we'll let someone else provide a specialized solution. Streaming
> and fully-materialized-tree are not the only two options; there are plenty of
> points in the middle.

> As to API idioms, these can be layered. The lazy-tree model outlined above can
> be a foundation for data binding, dynamic mapping to records, jsonpath, etc.
> But once you've made the streaming-vs-materialized choice in favor of
> materialized, it's hard to imagine not having something like the above at the
> base of the tower.

> The question you raise about error handling is one that infuses pattern matching
> in general. Pattern matching allows us to collapse what would be a thousand
> questions -- "does key X exist? is it mapped to a number? is the number in the
> range of byte?" -- each with their own failure-handling path, into a single
> question. That's great for reliable and readable code, but it does make errors
> more opaque, because it is more like the red "check engine" light on your
> dashboard. (Something like JSONPath could generate better error messages since
> you've given it a declarative description of an assumed structural invariant.)
> But, imperative code that has to treat each structural assumption as a possible
> control-flow point is a disaster; we've seen too much code like this already.

> The ecosystem is big enough that there will be lots of people with strong
> opinions that "X is the only sensible way to do it" (we've already seen
> X=databinding on this thread), but the reality is that there are multiple
> overlapping audiences here, and we have to be clear which audiences we are
> prioritizing. We can have that debate when the time is right.

> So, we'll get there, but we're waiting for one or two more bits of language
> evolution to give us the substrate for the API that feels right.

> Hope this helps,
> -Brian
You can "simulate" deconstructors by using when + instanceof, 

Let say we an interface with a deconstructor that can deconstruct the instance of that interface as a tuple of points 
interface Point { 
record $(int x, int y) {} 
$ deconstructor(); 
} 

If there is an implementation, the deconstructor is just an implementation of an instance method "deconstructor" 
class PointImpl implements Point { 
private int x; 
private int y; 

public PointImpl(int x, int y) { 
this.x = x; 
this.y = y; 
} 

@Override 
public $ deconstructor() { 
return new $(x, y); 
} 
} 

Then inside a switch, "case Point(int x, int y)" can be translated to "case Point p when deconstructor() instanceof Point.$(int x, int y)", like this 
public static void main(String[] args) { 
Point point = new PointImpl(3, 4); 
var value = switch (point) { 
case Point p when p.deconstructor() instanceof Point.$(int x, int y) -> x + y; 
default -> throw new MatchException("oops", null); 
}; 
System.out.println(value); 
} 

R?mi 

> On 12/15/2022 3:30 PM, Ethan McCue wrote:

>> I'm writing this to drive some forward motion and to nerd-snipe those who know
>> better than I do into putting their thoughts into words.

>> There are three ways to process JSON[1]
>> - Streaming (Push or Pull)
>> - Traversing a Tree (Realized or Lazy)
>> - Declarative Databind (N ways)

>> Of these, JEP-198 explicitly ruled out providing "JAXB style type safe data
>> binding."

>> No justification is given, but if I had to insert my own: mapping the Json model
>> to/from the Java/JVM object model is a cursed combo of
>> - Huge possible design space
>> - Unpalatably large surface for backwards compatibility
>> - Serialization! Boo![2]

>> So for an artifact like the JDK, it probably doesn't make sense to include. That
>> tracks.
>> It won't make everyone happy, people like databind APIs, but it tracks.

>> So for the "read flow" these are the things to figure out.

>> | Should Provide? | Intended User(s) |
>> ----------------+-----------------+------------------+
>> Streaming Push | | |
>> ----------------+-----------------+------------------+
>> Streaming Pull | | |
>> ----------------+-----------------+------------------+
>> Realized Tree | | |
>> ----------------+-----------------+------------------+
>> Lazy Tree | | |
>> ----------------+-----------------+------------------+

>> At which point, we should talk about what "meets needs of Java developers using
>> JSON" implies.

>> JSON is ubiquitous. Most kinds of software us schmucks write could have a reason
>> to interact with it.
>> The full set of "user personas" therefore aren't practical for me to talk
>> about.[3]

>> JSON documents, however, are not so varied.

>> - There are small ones (1-10kb)
>> - There are medium ones (10-1000kb)
>> - There are big ones (1000kb-???)

>> - There are shallow ones
>> - There are deep ones

>> So that feels like an easier direction to talk about it from.

>> This repo[4] has some convenient toy examples of how some of those APIs look in
>> libraries
>> in the ecosystem. Specifically the Streaming Pull and Realized Tree models.

>> User r = new User();
>> while (true) {
>> JsonToken token = reader.peek();
>> switch (token) {
>> case BEGIN_OBJECT:
>> reader.beginObject();
>> break;
>> case END_OBJECT:
>> reader.endObject();
>> return r;
>> case NAME:
>> String fieldname = reader.nextName();
>> switch (fieldname) {
>> case "id":
>> r.setId(reader.nextString());
>> break;
>> case "index":
>> r.setIndex(reader.nextInt());
>> break;
>> ...
>> case "friends":
>> r.setFriends(new ArrayList<>());
>> Friend f = null;
>> carryOn = true;
>> while (carryOn) {
>> token = reader.peek();
>> switch (token) {
>> case BEGIN_ARRAY:
>> reader.beginArray();
>> break;
>> case END_ARRAY:
>> reader.endArray();
>> carryOn = false;
>> break;
>> case BEGIN_OBJECT:
>> reader.beginObject();
>> f = new Friend();
>> break;
>> case END_OBJECT:
>> reader.endObject();
>> r.getFriends().add(f);
>> break;
>> case NAME:
>> String fn = reader.nextName();
>> switch (fn) {
>> case "id":
>> f.setId(reader.nextString());
>> break;
>> case "name":
>> f.setName(reader.nextString());
>> break;
>> }
>> break;
>> }
>> }
>> break;
>> }
>> }

>> I think its not hard to argue that the streaming apis are brutalist. The above
>> is Gson, but Jackson, moshi, etc
>> seem at least morally equivalent.

>> Its hard to write, hard to write *correctly*, and theres is a curious protensity
>> towards pairing it
>> with anemic, mutable models.

>> That being said, it handles big documents and deep documents really well. It
>> also performs
>> pretty darn well and is good enough as a "fallback" when the intended user
>> experience
>> is through something like databind.

>> So what could we do meaningfully better with the language we have today/will
>> have tommorow?

>> - Sealed interfaces + Pattern matching could give a nicer model for tokens

>> sealed interface JsonToken {
>> record Field(String name) implements JsonToken {}
>> record BeginArray() implements JsonToken {}
>> record EndArray() implements JsonToken {}
>> record BeginObject() implements JsonToken {}
>> record EndObject() implements JsonToken {}
>> // ...
>> }

>> // ...

>> User r = new User();
>> while (true) {
>> JsonToken token = reader.peek();
>> switch (token) {
>> case BeginObject __:
>> reader.beginObject();
>> break;
>> case EndObject __:
>> reader.endObject();
>> return r;
>> case Field("id"):
>> r.setId(reader.nextString());
>> break;
>> case Field("index"):
>> r.setIndex(reader.nextInt());
>> break;

>> // ...

>> case Field("friends"):
>> r.setFriends(new ArrayList<>());
>> Friend f = null;
>> carryOn = true;
>> while (carryOn) {
>> token = reader.peek();
>> switch (token) {
>> // ...

>> - Value classes can make it all more efficient

>> sealed interface JsonToken {
>> value record Field(String name) implements JsonToken {}
>> value record BeginArray() implements JsonToken {}
>> value record EndArray() implements JsonToken {}
>> value record BeginObject() implements JsonToken {}
>> value record EndObject() implements JsonToken {}
>> // ...
>> }

>> - (Fun One) We can transform a simpler-to-write push parser into a pull parser
>> with Coroutines

>> This is just a toy we could play with while making something in the JDK. I'm
>> pretty sure
>> we could make a parser which feeds into something like

>> interface Listener {
>> void onObjectStart();
>> void onObjectEnd();
>> void onArrayStart();
>> void onArrayEnd();
>> void onField(String name);
>> // ...
>> }

>> and invert a loop like

>> while (true) {
>> char c = next();
>> switch (c) {
>> case '{':
>> listener.onObjectStart();
>> // ...
>> // ...
>> }
>> }

>> by putting a Coroutine.yield in the callback.

>> That might be a meaningful simplification in code structure, I don't know enough
>> to say.

>> But, I think there are some hard questions like

>> - Is the intent[5] to be make backing parser for ecosystem databind apis?
>> - Is the intent that users who want to handle big/deep documents fall back to
>> this?
>> - Are those new language features / conveniences enough to offset the cost of
>> committing to a new api?
>> - To whom exactly does a low level api provide value?
>> - What benefit is standardization in the JDK?

>> and just generally - who would be the consumer(s) of this?

>> The other kind of API still on the table is a Tree. There are two ways to handle
>> this

>> 1. Load it into `Object`. Use a bunch of instanceof checks/casts to confirm what
>> it actually is.

>> Object v;
>> User u = new User();

>> if ((v = jso.get("id")) != null) {
>> u.setId((String) v);
>> }
>> if ((v = jso.get("index")) != null) {
>> u.setIndex(((Long) v).intValue());
>> }
>> if ((v = jso.get("guid")) != null) {
>> u.setGuid((String) v);
>> }
>> if ((v = jso.get("isActive")) != null) {
>> u.setIsActive(((Boolean) v));
>> }
>> if ((v = jso.get("balance")) != null) {
>> u.setBalance((String) v);
>> }
>> // ...
>> if ((v = jso.get("latitude")) != null) {
>> u.setLatitude(v instanceof BigDecimal ? ((BigDecimal) v).doubleValue() :
>> (Double) v);
>> }
>> if ((v = jso.get("longitude")) != null) {
>> u.setLongitude(v instanceof BigDecimal ? ((BigDecimal) v).doubleValue() :
>> (Double) v);
>> }
>> if ((v = jso.get("greeting")) != null) {
>> u.setGreeting((String) v);
>> }
>> if ((v = jso.get("favoriteFruit")) != null) {
>> u.setFavoriteFruit((String) v);
>> }
>> if ((v = jso.get("tags")) != null) {
>> List<Object> jsonarr = (List<Object>) v;
>> u.setTags(new ArrayList<>());
>> for (Object vi : jsonarr) {
>> u.getTags().add((String) vi);
>> }
>> }
>> if ((v = jso.get("friends")) != null) {
>> List<Object> jsonarr = (List<Object>) v;
>> u.setFriends(new ArrayList<>());
>> for (Object vi : jsonarr) {
>> Map<String, Object> jso0 = (Map<String, Object>) vi;
>> Friend f = new Friend();
>> f.setId((String) jso0.get("id"));
>> f.setName((String) jso0.get("name"));
>> u.getFriends().add(f);
>> }
>> }

>> 2. Have an explicit model for Json, and helper methods that do said casts[6]

>> this.setSiteSetting(readFromJson(jsonObject.getJsonObject("site")));
>> JsonArray groups = jsonObject.getJsonArray("group");
>> if(groups != null)
>> {
>> int len = groups.size();
>> for(int i=0; i<len; i++)
>> {
>> JsonObject grp = groups.getJsonObject(i);
>> SNMPSetting grpSetting = readFromJson(grp);
>> String grpName = grp.getString("dbgroup", null);
>> if(grpName != null && grpSetting != null)
>> this.groupSettings.put(grpName, grpSetting);
>> }
>> }
>> JsonArray hosts = jsonObject.getJsonArray("host");
>> if(hosts != null)
>> {
>> int len = hosts.size();
>> for(int i=0; i<len; i++)
>> {
>> JsonObject host = hosts.getJsonObject(i);
>> SNMPSetting hostSetting = readFromJson(host);
>> String hostName = host.getString("dbhost", null);
>> if(hostName != null && hostSetting != null)
>> this.hostSettings.put(hostName, hostSetting);
>> }
>> }

>> I think what has become easier to represent in the language nowadays is that
>> explicit model for Json.
>> Its the 101 lesson of sealed interfaces.[7] It feels nice and clean.

>> sealed interface Json {
>> final class Null implements Json {}
>> final class True implements Json {}
>> final class False implements Json {}
>> final class Array implements Json {}
>> final class Object implements Json {}
>> final class String implements Json {}
>> final class Number implements Json {}
>> }

>> And the cast-and-check approach is now more viable on account of pattern
>> matching.

>> if (jso.get("id") instanceof String v) {
>> u.setId(v);
>> }
>> if (jso.get("index") instanceof Long v) {
>> u.setIndex(v.intValue());
>> }
>> if (jso.get("guid") instanceof String v) {
>> u.setGuid(v);
>> }

>> // or

>> if (jso.get("id") instanceof String id &&
>> jso.get("index") instanceof Long index &&
>> jso.get("guid") instanceof String guid) {
>> return new User(id, index, guid, ...); // look ma, no setters!
>> }

>> And on the horizon, again, is value types.

>> But there are problems with this approach beyond the performance implications of
>> loading into
>> a tree.

>> For one, all the code samples above have different behaviors around null keys
>> and missing keys
>> that are not obvious from first glance.

>> This won't accept any null or missing fields

>> if (jso.get("id") instanceof String id &&
>> jso.get("index") instanceof Long index &&
>> jso.get("guid") instanceof String guid) {
>> return new User(id, index, guid, ...);
>> }

>> This will accept individual null or missing fields, but also will silently
>> ignore
>> fields with incorrect types

>> if (jso.get("id") instanceof String v) {
>> u.setId(v);
>> }
>> if (jso.get("index") instanceof Long v) {
>> u.setIndex(v.intValue());
>> }
>> if (jso.get("guid") instanceof String v) {
>> u.setGuid(v);
>> }

>> And, compared to databind where there is information about the expected
>> structure of the document
>> and its the job of the framework to assert that, I posit that the errors that
>> would be encountered
>> when writing code against this would be more like

>> "something wrong with user"

>> than

>> "problem at users[5].name, expected string or null. got 5"

>> Which feels unideal.

>> One approach I find promising is something close to what Elm does with its
>> decoders[8]. Not just combining assertion
>> and binding like what pattern matching with records allows, but including a
>> scheme for bubbling/nesting errors.

>> static String string(Json json) throws JsonDecodingException {
>> if (!(json instanceof Json.String jsonString)) {
>> throw JsonDecodingException.of(
>> "expected a string",
>> json
>> );
>> } else {
>> return jsonString.value();
>> }
>> }

>> static <T> T field(Json json, String fieldName, Decoder<? extends T>
>> valueDecoder) throws JsonDecodingException {
>> var jsonObject = object(json);
>> var value = jsonObject.get(fieldName);
>> if (value == null) {
>> throw JsonDecodingException.atField(
>> fieldName,
>> JsonDecodingException.of(
>> "no value for field",
>> json
>> )
>> );
>> }
>> else {
>> try {
>> return valueDecoder.decode(value);
>> } catch (JsonDecodingException e) {
>> throw JsonDecodingException.atField(
>> fieldName,
>> e
>> );
>> } catch (Exception e) {
>> throw JsonDecodingException.atField(fieldName, JsonDecodingException.of(e,
>> value));
>> }
>> }
>> }

>> Which I think has some benefits over the ways I've seen of working with trees.

>> - It is declarative enough that folks who prefer databind might be happy enough.

>> static User fromJson(Json json) {
>> return new User(
>> Decoder.field(json, "id", Decoder::string),
>> Decoder.field(json, "index", Decoder::long_),
>> Decoder.field(json, "guid", Decoder::string),
>> );
>> }

>> / ...

>> List<User> users = Decoders.array(json, User::fromJson);

>> - Handling null and optional fields could be less easily conflated

>> Decoder.field(json, "id", Decoder::string);

>> Decoder.nullableField(json, "id", Decoder::string);

>> Decoder.optionalField(json, "id", Decoder::string);

>> Decoder.optionalNullableField(json, "id", Decoder::string);

>> - It composes well with user defined classes

>> record Guid(String value) {
>> Guid {
>> // some assertions on the structure of value
>> }
>> }

>> Decoder.string(json, "guid", guid -> new Guid(Decoder.string(guid)));

>> // or even

>> record Guid(String value) {
>> Guid {
>> // some assertions on the structure of value
>> }

>> static Guid fromJson(Json json) {
>> return new Guid(Decoder.string(guid));
>> }
>> }

>> Decoder.string(json, "guid", Guid::fromJson);

>> - When something goes wrong, the API can handle the fiddlyness of capturing
>> information for feedback.

>> In the code I've sketched out its just what field/index things went wrong at.
>> Potentially
>> capturing metadata like row/col numbers of the source would be sensible too.

>> Its just not reasonable to expect devs to do extra work to get that and its
>> really nice to give it.

>> There are also some downsides like

>> - I do not know how compatible it would be with lazy trees.

>> Lazy trees being the only way that a tree api could handle big or deep
>> documents.
>> The general concept as applied in libraries like json-tree[9] is to navigate
>> without
>> doing any work, and that clashes with wanting to instanceof check the info at
>> the
>> current path.

>> - It *almost* gives enough information to be a general schema approach

>> If one field fails, that in the model throws an exception immediately. If an API
>> should
>> return "errors": [...], that is inconvenient to construct.

>> - None of the existing popular libraries are doing this

>> The only mechanics that are strictly required to give this sort of API is
>> lambdas. Those have
>> been out for a decade. Yes sealed interfaces make the data model prettier but in
>> concept you
>> can build the same thing on top of anything.

>> I could argue that this is because of "cultural momentum" of databind or some
>> other reason,
>> but the fact remains that it isn't a proven out approach.

>> Writing Json libraries is a todo list[10]. There are a lot of bad ideas and this
>> might be one of the,

>> - Performance impact of so many instanceof checks

>> I've gotten a 4.2% slowdown compared to the "regular" tree code without the
>> repeated casts.

>> But that was with a parser that is 5x slower than Jacksons. (using the same
>> benchmark project as for the snippets).
>> I think there could be reason to believe that the JIT does well enough with
>> repeated instanceof
>> checks to consider it.

>> My current thinking is that - despite not solving for large or deep documents -
>> starting with a really "dumb" realized tree api
>> might be the right place to start for the read side of a potential incubator
>> module.

>> But regardless - this feels like a good time to start more concrete
>> conversations. I fell I should cap this email since I've reached the point of
>> decoherence and haven't even mentioned the write side of things

>> [1]: [ http://www.cowtowncoder.com/blog/archives/2009/01/entry_131.html |
>> http://www.cowtowncoder.com/blog/archives/2009/01/entry_131.html ]
>> [2]: [ https://security.snyk.io/vuln/maven?search=jackson-databind |
>> https://security.snyk.io/vuln/maven?search=jackson-databind ]
>> [3]: I only know like 8 people
>> [4]: [
>> https://github.com/fabienrenaud/java-json-benchmark/blob/master/src/main/java/com/github/fabienrenaud/jjb/stream/UsersStreamDeserializer.java
>> |
>> https://github.com/fabienrenaud/java-json-benchmark/blob/master/src/main/java/com/github/fabienrenaud/jjb/stream/UsersStreamDeserializer.java
>> ]
>> [5]: When I say "intent", I do so knowing full well no one has been actively
>> thinking of this for an entire Game of Thrones
>> [6]: [
>> https://github.com/yahoo/mysql_perf_analyzer/blob/master/myperf/src/main/java/com/yahoo/dba/perf/myperf/common/SNMPSettings.java
>> |
>> https://github.com/yahoo/mysql_perf_analyzer/blob/master/myperf/src/main/java/com/yahoo/dba/perf/myperf/common/SNMPSettings.java
>> ]
>> [7]: [ https://www.infoq.com/articles/data-oriented-programming-java/ |
>> https://www.infoq.com/articles/data-oriented-programming-java/ ]
>> [8]: [ https://package.elm-lang.org/packages/elm/json/latest/Json-Decode |
>> https://package.elm-lang.org/packages/elm/json/latest/Json-Decode ]
>> [9]: [ https://github.com/jbee/json-tree | https://github.com/jbee/json-tree ]
>> [10]: [ https://stackoverflow.com/a/14442630/2948173 |
>> https://stackoverflow.com/a/14442630/2948173 ]
>> [11]: In 30 days JEP-198 it will be recognizably PI days old for the 2nd time in
>> its history.
>> [12]: To me, the fact that is still an open JEP is more a social convenience
>> than anything. I could just as easily writing this exact same email about TOML.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20230228/ac342b2f/attachment-0001.htm>

From bpb at openjdk.org  Tue Feb 28 21:30:05 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 28 Feb 2023 21:30:05 GMT
Subject: RFR: 8298619: java/io/File/GetXSpace.java is failing [v3]
In-Reply-To: <2qnsd811w7eNF2SE9ZSkCtH0k87zSAMsi262xhyh8eQ=.b83e63dc-e3e7-4e69-858d-b4770abe59e5@github.com>
References: <6LnAAIclo5mZZgba4XUSTSc72vyNrBinzUlO9-kJXbU=.fe0c5e94-9e36-4484-b8e7-0f19cb10cb05@github.com>
 <DTNziTj7KbkeG3LvpMREAi9WP9XRczQUdP_1-XTvp2c=.b9b78dec-3879-4626-9174-306e57ce83a4@github.com>
 <134wQrl9F4McK30DN1EvRTuqCx-WDMTgym1traoL8fI=.1247d3ff-0413-415a-9f3f-6a30b59f62d5@github.com>
 <Kia7JD1spnBOVIg-KuMO17m5UJClbL8R1SivnOyx8_0=.3950cd71-ce62-47ca-9ac6-0d16071567e3@github.com>
 <N2rOY286-pmyGS6g6R_EddIeBAj-cdStUNRMGwvh6tc=.06ec461d-2868-4de0-a0b0-a8e86709ba98@github.com>
 <2qnsd811w7eNF2SE9ZSkCtH0k87zSAMsi262xhyh8eQ=.b83e63dc-e3e7-4e69-858d-b4770abe59e5@github.com>
Message-ID: <egxFmKc8oFy7aJVd6vnNWB_jcd2sP8-FC9Y0Dm6qUtw=.71d85ca0-aaad-44be-815d-aa8d0635a940@github.com>

On Wed, 22 Feb 2023 18:26:49 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> There has definitely been a problem with quotas on Windows. I set up quotas on actual Windows 11 hardware and replicated the same failure. I am not sure how much lack of system quiescence is to blame, but there would be no harm in building in some robustness for lack of quiescence while we're at it.
>
> Spawning `df` and `diskFree` processes have been replaced with native calls. For a reason as yet undetermined, the Windows function `GetDiskSpaceInformationW` fails to load on Windows Server 2016 so it is loaded dynamically and, if not found, a workaround is used.

Testing in the CI against the latest commit 114857c1fbc6ea6ad0ee9ccce10cb886e8c62469 has passed more than 500 iterations on Windows with no failures.

-------------

PR: https://git.openjdk.org/jdk/pull/12397

From tvaleev at openjdk.org  Tue Feb 28 21:32:08 2023
From: tvaleev at openjdk.org (Tagir F. Valeev)
Date: Tue, 28 Feb 2023 21:32:08 GMT
Subject: RFR: JDK-8302323 Add repeat methods to StringBuilder/StringBuffer
 [v4]
In-Reply-To: <_xWE2kNbPX4koybMJrD8UQDGjU0qX5LVCzKo_o2V-Vs=.aa3615ee-9786-41b5-b2fa-d2da40c35482@github.com>
References: <ygMjzllqk27Dss1q2oRgcNvK_GJdbFVweVHTvF7zpwY=.06d27701-6b42-4663-958e-f8aca9bc2bc5@github.com>
 <_xWE2kNbPX4koybMJrD8UQDGjU0qX5LVCzKo_o2V-Vs=.aa3615ee-9786-41b5-b2fa-d2da40c35482@github.com>
Message-ID: <qKPn8vBmfVyPDFzVErulfsIcHbxjnJFULK5QOl1TyeU=.9990b4b2-84ed-426d-a8ba-f85fb4b3c8f3@github.com>

On Tue, 28 Feb 2023 13:29:49 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> Add the ability to repeatedly append char and CharSequence data to StringBuilder/StringBuffer.
>
> Jim Laskey has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Remove @throws IndexOutOfBoundsException
>  - Change error report to use "is negative"

Marked as reviewed by tvaleev (Committer).

-------------

PR: https://git.openjdk.org/jdk/pull/12728

From rgiulietti at openjdk.org  Tue Feb 28 22:16:16 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Tue, 28 Feb 2023 22:16:16 GMT
Subject: RFR: 8302590: Add String.indexOf(int ch, int fromIndex,
 int toIndex) [v3]
In-Reply-To: <ZZPOOWMagAfp8h9jFakH3bMjJO1SNkR_0An8UdGMEU4=.b56add44-942d-4b55-a3f4-a69a3f96e226@github.com>
References: <uQ65oRaVDfpzm9bYRuo_MvSuZIdepicE3GnB3Omyngs=.fc23545b-141a-47e5-8a6a-aa28ae1375e5@github.com>
 <VY-Hm8owXgm5vjfxkW7wmnb_TqRsZyMSme4HcSTywyo=.f48897d4-c587-4594-b0b1-b79703e6ec33@github.com>
 <ZZPOOWMagAfp8h9jFakH3bMjJO1SNkR_0An8UdGMEU4=.b56add44-942d-4b55-a3f4-a69a3f96e226@github.com>
Message-ID: <NAX4dOhVY1A9u4xEh7iQvmgnetnNu0urwdiu2OkUuyY=.4cdd0631-cdc6-4796-9467-65f4c213bef4@github.com>

On Tue, 28 Feb 2023 19:45:02 GMT, Stuart Marks <smarks at openjdk.org> wrote:

>> Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8302590: Add String.indexOf(int ch, int fromIndex, int toIndex)
>
> In concept, having APIs that search a string subrange is a fine idea. Unfortunately the exception handling policy is an issue. We need to think through this carefully.
> 
> Currently, almost everything that takes some kind of String index or subrange will throw IndexOutOfBoundsException if the arguments are ill-specified in some fashion. There are a few notable outliers though:
> 
>     indexOf(int ch, int fromIndex)
>     indexOf(String str, int fromIndex)
>     lastIndexOf(int ch, int fromIndex)
>     lastIndexOf(String str, int fromIndex)
>     regionMatches(boolean ignoreCase, int toffset, String other, int ooffset, int len)
>     regionMatches(int toffset, String other, int ooffset, int len)
> 
> They don't throw any exceptions for ill-defined values; instead, they return -1 or false which is indistinguishable from "not found". These APIs date all the way back to 1.0. Note that the JDK 1.0 String wasn't internally consistent. For example, other 1.0-era methods like `substring` throw StringIndexOutOfBoundsException.
> 
> The prevailing API style since that time has been to check arguments and throw the appropriate exceptions, instead of masking ill-defined values by returning "not found". This tends to reveal errors earlier instead of covering them up. Compared to the existing `indexOf` methods (which specify a single starting index), the new `indexOf` method specifies a subrange; this allows a new class of "end < start" errors. It seems strange not to throw any exception for this additional class of errors.
> 
> In understand the desire to be consistent with the existing methods. Adding a new non-throwing method seems like a mistake though. It's perpetuating an old API design mistake for the sake of consistency, while also being inconsistent with current API design style.
> 
> I also don't think it's necessary to have both throwing and non-throwing methods.
> 
> I'd suggest returning to the original `indexOf(ch, from, to)` proposal, but instead having it check its subrange arguments and throwing IndexOutOfBoundsException. I don't think the exception handling inconsistency with the existing methods is that bad. If people really, really object to it, then maybe it would be necessary to choose a new name for the new method (and not introduce two versions). But choosing a good name is hard, and it introduces issues such as discoverability and questions about how the new thing differs from the existing methods, so I'm skeptical that choosing a different name would be any better.
> 
> Another possible mitigation is to add API notes to highlight the unusual behavior of the old non-throwing methods. Some of these old methods don't mention their handling of illegal index values at all. (This could be done as part of a separate PR.)

@stuart-marks I agree.

My insistence on preserving old (but bad) behavior was well intended, but I'm now convinced that the new 3 params `indexOf()` better throws on illegal indices.

I'll thus add a check in its implementation, adapt the spec, remove the additional `checkedIndexOf()` method, and add API notes to the existing methods to highlight their unusual behavior w.r.t. illegal indices (assuming that adding these notes can be done in the same CSR issue).

-------------

PR: https://git.openjdk.org/jdk/pull/12600

From sviswanathan at openjdk.org  Tue Feb 28 22:23:05 2023
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Tue, 28 Feb 2023 22:23:05 GMT
Subject: RFR: 8303401: Add a Vector API equalsIgnoreCase micro benchmark
In-Reply-To: <FbxtEB-ECOJ65eF7cdhkISphjqC4Ks1jxYgbML2_xwk=.56cf8152-e227-4412-9e30-0ecb020a65f3@github.com>
References: <FbxtEB-ECOJ65eF7cdhkISphjqC4Ks1jxYgbML2_xwk=.56cf8152-e227-4412-9e30-0ecb020a65f3@github.com>
Message-ID: <JBmPENNJZ1DNlhvT1mhBhNw_5MeygqGQzgTvmkc6RR8=.968294ce-f8c7-410f-acee-f78ac68b6b2e@github.com>

On Tue, 28 Feb 2023 15:59:26 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

> This PR suggests we add a vectorized equalsIgnoreCase benchmark to the set of benchmarks in `org.openjdk.bench.jdk.incubator.vector`. This benchmark serves as an example of how vectorization can be useful also in the area of text processing. It takes advantage of the fact that ASCII and Latin-1 were designed to optimize case-twiddling operations.
> 
> The code came about during the work on #12632, where vectorization was deemed out of scope.
> 
> Benchmark results:
> 
> 
> Benchmark                             (size)  Mode  Cnt     Score   Error  Units
> EqualsIgnoreCaseBenchmark.scalar          16  avgt   15    20.671 ? 0.718  ns/op
> EqualsIgnoreCaseBenchmark.scalar          32  avgt   15    46.155 ? 3.258  ns/op
> EqualsIgnoreCaseBenchmark.scalar          64  avgt   15    68.248 ? 1.767  ns/op
> EqualsIgnoreCaseBenchmark.scalar         128  avgt   15   148.948 ? 0.890  ns/op
> EqualsIgnoreCaseBenchmark.scalar        1024  avgt   15  1090.708 ? 7.540  ns/op
> EqualsIgnoreCaseBenchmark.vectorized      16  avgt   15    21.872 ? 0.232  ns/op
> EqualsIgnoreCaseBenchmark.vectorized      32  avgt   15    11.378 ? 0.097  ns/op
> EqualsIgnoreCaseBenchmark.vectorized      64  avgt   15    13.703 ? 0.135  ns/op
> EqualsIgnoreCaseBenchmark.vectorized     128  avgt   15    21.632 ? 0.735  ns/op
> EqualsIgnoreCaseBenchmark.vectorized    1024  avgt   15   105.509 ? 7.493  ns/op

Thanks a lot for this micro benchmark.

test/micro/org/openjdk/bench/jdk/incubator/vector/EqualsIgnoreCaseBenchmark.java line 85:

> 83: 
> 84:             // ASCII and Latin-1 were designed to optimize case-twiddling operations
> 85:             ByteVector lowerA = va.or((byte) 0x20);

Just curious, here you use lower whereas in scalar code upper is being used. Any reasons?

test/micro/org/openjdk/bench/jdk/incubator/vector/EqualsIgnoreCaseBenchmark.java line 88:

> 86: 
> 87:             // Determine which bytes represent ASCII or Latin-1 letters:
> 88:             VectorMask<Byte> asciiLetter = lowerA.lt((byte) '{').and(lowerA.lt((byte) 0x60).not());

We do have GT/GE/NE etc comparison operators supported in Vector API, which you can use here and other places in this benchmark. e.g.
You could do lowerA.compare(GE, (byte)0x60) instead of using lt() followed not(). BTW did you mean to use GT here?

You will need to do the following import:
import static  jdk.incubator.vector.VectorOperators.*;

-------------

PR: https://git.openjdk.org/jdk/pull/12790

From rriggs at openjdk.org  Tue Feb 28 22:25:16 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 28 Feb 2023 22:25:16 GMT
Subject: RFR: JDK-8302323 Add repeat methods to StringBuilder/StringBuffer
 [v4]
In-Reply-To: <_xWE2kNbPX4koybMJrD8UQDGjU0qX5LVCzKo_o2V-Vs=.aa3615ee-9786-41b5-b2fa-d2da40c35482@github.com>
References: <ygMjzllqk27Dss1q2oRgcNvK_GJdbFVweVHTvF7zpwY=.06d27701-6b42-4663-958e-f8aca9bc2bc5@github.com>
 <_xWE2kNbPX4koybMJrD8UQDGjU0qX5LVCzKo_o2V-Vs=.aa3615ee-9786-41b5-b2fa-d2da40c35482@github.com>
Message-ID: <3IXNL5BRGeGHKKECeqqMLc3YBCzz-KjbYSJuNVGkAbI=.15d558ef-047e-41a2-a290-e82479ef19c1@github.com>

On Tue, 28 Feb 2023 13:29:49 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> Add the ability to repeatedly append char and CharSequence data to StringBuilder/StringBuffer.
>
> Jim Laskey has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Remove @throws IndexOutOfBoundsException
>  - Change error report to use "is negative"

Changes requested by rriggs (Reviewer).

src/java.base/share/classes/java/lang/AbstractStringBuilder.java line 1835:

> 1833:      * @return  a reference to this object.
> 1834:      *
> 1835:      * @since 21

@since should be last / after \throws; here and in the other method added.

src/java.base/share/classes/java/lang/StringBuffer.java line 713:

> 711:     /**
> 712:      * @since 21
> 713:      * @throws IllegalArgumentException {@inheritDoc}

@throws comes before @since here and in StringBuilder.

-------------

PR: https://git.openjdk.org/jdk/pull/12728

From vromero at openjdk.org  Tue Feb 28 22:31:04 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Tue, 28 Feb 2023 22:31:04 GMT
Subject: RFR: 8297587: Upgrade JLine to 3.22.0
In-Reply-To: <Y2xdMkQ3uIpXOWBKdAlVyEiGEmDF4YsAWqV0Tf_dp9A=.200485d2-cc87-41bf-86dc-ad85c25d4f0e@github.com>
References: <Y2xdMkQ3uIpXOWBKdAlVyEiGEmDF4YsAWqV0Tf_dp9A=.200485d2-cc87-41bf-86dc-ad85c25d4f0e@github.com>
Message-ID: <JFReixI_VejP9NtDVIc6O67eLUxCMW6OCfQAeHGi6ns=.5babe1a6-6cbe-47f7-9897-8f46bb297255@github.com>

On Fri, 17 Feb 2023 10:20:46 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> This is a proposal to upgrade the JLine inside JDK to 3.22.0. It was done by:
> -for shared/classes, taking a diff between JLine 3.20.0 and the existing JDK version, copying the JLine 3.22.0 into the JDK, repackaing, re-appling the patch (including trailing space removal, UTF-8 characters replacement, addition of inputStreamWrapper), and adjusting TerminalProvider
> -for Windows, mostly copying the JLine 3.22.0 code into the JDK, and adjusting based on old changes

some nit comments for your consideration, approved

src/jdk.internal.le/share/classes/jdk/internal/org/jline/reader/impl/LineReaderImpl.java line 5086:

> 5084:         if (groupName) {
> 5085:             Comparator<String> groupComparator = getGroupComparator();
> 5086:             Map<String, Map<Object, Candidate>> sorted;

Candidate and String both implement Comparable, probably that could be used to provide a more specific common supertype

src/jdk.internal.le/share/classes/jdk/internal/org/jline/utils/NonBlocking.java line 147:

> 145:             this.input = input;
> 146:             this.decoder = decoder;
> 147:             this.bytes = ByteBuffer.allocate(2048);

wow, big difference in allocation size

-------------

Marked as reviewed by vromero (Reviewer).

PR: https://git.openjdk.org/jdk/pull/12614

From duke at openjdk.org  Tue Feb 28 22:58:35 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Tue, 28 Feb 2023 22:58:35 GMT
Subject: RFR: 8303401: Add a Vector API equalsIgnoreCase micro benchmark
 [v2]
In-Reply-To: <FbxtEB-ECOJ65eF7cdhkISphjqC4Ks1jxYgbML2_xwk=.56cf8152-e227-4412-9e30-0ecb020a65f3@github.com>
References: <FbxtEB-ECOJ65eF7cdhkISphjqC4Ks1jxYgbML2_xwk=.56cf8152-e227-4412-9e30-0ecb020a65f3@github.com>
Message-ID: <qty6xIURvmc42SDYdR8aOh9R0VyjRa6aIVO3UKBwuu4=.98aa44d9-5a33-47ad-8b86-afd9724a19f6@github.com>

> This PR suggests we add a vectorized equalsIgnoreCase benchmark to the set of benchmarks in `org.openjdk.bench.jdk.incubator.vector`. This benchmark serves as an example of how vectorization can be useful also in the area of text processing. It takes advantage of the fact that ASCII and Latin-1 were designed to optimize case-twiddling operations.
> 
> The code came about during the work on #12632, where vectorization was deemed out of scope.
> 
> Benchmark results:
> 
> 
> Benchmark                             (size)  Mode  Cnt     Score   Error  Units
> EqualsIgnoreCaseBenchmark.scalar          16  avgt   15    20.671 ? 0.718  ns/op
> EqualsIgnoreCaseBenchmark.scalar          32  avgt   15    46.155 ? 3.258  ns/op
> EqualsIgnoreCaseBenchmark.scalar          64  avgt   15    68.248 ? 1.767  ns/op
> EqualsIgnoreCaseBenchmark.scalar         128  avgt   15   148.948 ? 0.890  ns/op
> EqualsIgnoreCaseBenchmark.scalar        1024  avgt   15  1090.708 ? 7.540  ns/op
> EqualsIgnoreCaseBenchmark.vectorized      16  avgt   15    21.872 ? 0.232  ns/op
> EqualsIgnoreCaseBenchmark.vectorized      32  avgt   15    11.378 ? 0.097  ns/op
> EqualsIgnoreCaseBenchmark.vectorized      64  avgt   15    13.703 ? 0.135  ns/op
> EqualsIgnoreCaseBenchmark.vectorized     128  avgt   15    21.632 ? 0.735  ns/op
> EqualsIgnoreCaseBenchmark.vectorized    1024  avgt   15   105.509 ? 7.493  ns/op

Eirik Bjorsnos has updated the pull request incrementally with one additional commit since the last revision:

  Use GE, LE, NE operations instead of the lt,not combinations. Use uppercase in vectorized code to match the scalar version.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12790/files
  - new: https://git.openjdk.org/jdk/pull/12790/files/c01a464d..d8c0c2ed

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12790&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12790&range=00-01

  Stats: 18 lines in 1 file changed: 7 ins; 4 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/12790.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12790/head:pull/12790

PR: https://git.openjdk.org/jdk/pull/12790

From duke at openjdk.org  Tue Feb 28 23:01:09 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Tue, 28 Feb 2023 23:01:09 GMT
Subject: RFR: 8303401: Add a Vector API equalsIgnoreCase micro benchmark
 [v2]
In-Reply-To: <JBmPENNJZ1DNlhvT1mhBhNw_5MeygqGQzgTvmkc6RR8=.968294ce-f8c7-410f-acee-f78ac68b6b2e@github.com>
References: <FbxtEB-ECOJ65eF7cdhkISphjqC4Ks1jxYgbML2_xwk=.56cf8152-e227-4412-9e30-0ecb020a65f3@github.com>
 <JBmPENNJZ1DNlhvT1mhBhNw_5MeygqGQzgTvmkc6RR8=.968294ce-f8c7-410f-acee-f78ac68b6b2e@github.com>
Message-ID: <Uk2xi-y36F-jRE79OciOaFyWv7KA0V910Frp111-gJ8=.0c6e9251-787d-4c2e-9d51-41a600511dd6@github.com>

On Tue, 28 Feb 2023 22:19:46 GMT, Sandhya Viswanathan <sviswanathan at openjdk.org> wrote:

>> Eirik Bjorsnos has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Use GE, LE, NE operations instead of the lt,not combinations. Use uppercase in vectorized code to match the scalar version.
>
> test/micro/org/openjdk/bench/jdk/incubator/vector/EqualsIgnoreCaseBenchmark.java line 85:
> 
>> 83: 
>> 84:             // ASCII and Latin-1 were designed to optimize case-twiddling operations
>> 85:             ByteVector lowerA = va.or((byte) 0x20);
> 
> Just curious, here you use lower whereas in scalar code upper is being used. Any reasons?

I can't remember the exact reason. Perhaps I thought I could get simpler range checking of the Latin-1 code points because they are almost at the end of the Latin-1 range.

I changed the vectorized version to use uppercase for better alignment with the scalar version.

> test/micro/org/openjdk/bench/jdk/incubator/vector/EqualsIgnoreCaseBenchmark.java line 88:
> 
>> 86: 
>> 87:             // Determine which bytes represent ASCII or Latin-1 letters:
>> 88:             VectorMask<Byte> asciiLetter = lowerA.lt((byte) '{').and(lowerA.lt((byte) 0x60).not());
> 
> We do have GT/GE/NE etc comparison operators supported in Vector API, which you can use here and other places in this benchmark. e.g.
> You could do lowerA.compare(GE, (byte)0x60) instead of using lt() followed not(). BTW did you mean to use GT here?
> 
> You will need to do the following import:
> import static  jdk.incubator.vector.VectorOperators.*;

Thanks, that's a lot more readable! This checks that bytes are in the range => (byte) 'A', <= (byte) 'A', so I think this "not less than" was a poor man's compare(GE, (byte) 'A') here.

I've updated the code to use LE, GE, NE where appropriate

-------------

PR: https://git.openjdk.org/jdk/pull/12790

From duke at openjdk.org  Tue Feb 28 23:08:29 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Tue, 28 Feb 2023 23:08:29 GMT
Subject: RFR: 8303401: Add a Vector API equalsIgnoreCase micro benchmark
 [v3]
In-Reply-To: <FbxtEB-ECOJ65eF7cdhkISphjqC4Ks1jxYgbML2_xwk=.56cf8152-e227-4412-9e30-0ecb020a65f3@github.com>
References: <FbxtEB-ECOJ65eF7cdhkISphjqC4Ks1jxYgbML2_xwk=.56cf8152-e227-4412-9e30-0ecb020a65f3@github.com>
Message-ID: <ZkTx9cf88J3ykf4e6UbrJx97xSfXwsoTqbeU6XIIpcY=.3b663092-7084-42b2-a9fd-a762eb1389b2@github.com>

> This PR suggests we add a vectorized equalsIgnoreCase benchmark to the set of benchmarks in `org.openjdk.bench.jdk.incubator.vector`. This benchmark serves as an example of how vectorization can be useful also in the area of text processing. It takes advantage of the fact that ASCII and Latin-1 were designed to optimize case-twiddling operations.
> 
> The code came about during the work on #12632, where vectorization was deemed out of scope.
> 
> Benchmark results:
> 
> 
> Benchmark                             (size)  Mode  Cnt     Score   Error  Units
> EqualsIgnoreCaseBenchmark.scalar          16  avgt   15    20.671 ? 0.718  ns/op
> EqualsIgnoreCaseBenchmark.scalar          32  avgt   15    46.155 ? 3.258  ns/op
> EqualsIgnoreCaseBenchmark.scalar          64  avgt   15    68.248 ? 1.767  ns/op
> EqualsIgnoreCaseBenchmark.scalar         128  avgt   15   148.948 ? 0.890  ns/op
> EqualsIgnoreCaseBenchmark.scalar        1024  avgt   15  1090.708 ? 7.540  ns/op
> EqualsIgnoreCaseBenchmark.vectorized      16  avgt   15    21.872 ? 0.232  ns/op
> EqualsIgnoreCaseBenchmark.vectorized      32  avgt   15    11.378 ? 0.097  ns/op
> EqualsIgnoreCaseBenchmark.vectorized      64  avgt   15    13.703 ? 0.135  ns/op
> EqualsIgnoreCaseBenchmark.vectorized     128  avgt   15    21.632 ? 0.735  ns/op
> EqualsIgnoreCaseBenchmark.vectorized    1024  avgt   15   105.509 ? 7.493  ns/op

Eirik Bjorsnos has updated the pull request incrementally with two additional commits since the last revision:

 - Uppercase Thorn is 0xDE
 - Update 'a' to 'A' and 'z' to 'Z' in comments

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12790/files
  - new: https://git.openjdk.org/jdk/pull/12790/files/d8c0c2ed..6bc04db0

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12790&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12790&range=01-02

  Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/12790.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12790/head:pull/12790

PR: https://git.openjdk.org/jdk/pull/12790

From sviswanathan at openjdk.org  Tue Feb 28 23:16:04 2023
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Tue, 28 Feb 2023 23:16:04 GMT
Subject: RFR: 8303401: Add a Vector API equalsIgnoreCase micro benchmark
 [v3]
In-Reply-To: <ZkTx9cf88J3ykf4e6UbrJx97xSfXwsoTqbeU6XIIpcY=.3b663092-7084-42b2-a9fd-a762eb1389b2@github.com>
References: <FbxtEB-ECOJ65eF7cdhkISphjqC4Ks1jxYgbML2_xwk=.56cf8152-e227-4412-9e30-0ecb020a65f3@github.com>
 <ZkTx9cf88J3ykf4e6UbrJx97xSfXwsoTqbeU6XIIpcY=.3b663092-7084-42b2-a9fd-a762eb1389b2@github.com>
Message-ID: <tiCDvotoSiPEZImn6NJs6m8telgjQynnJfKwiH22Gf8=.e37d678b-b189-4b42-8afe-615870b9693b@github.com>

On Tue, 28 Feb 2023 23:08:29 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

>> This PR suggests we add a vectorized equalsIgnoreCase benchmark to the set of benchmarks in `org.openjdk.bench.jdk.incubator.vector`. This benchmark serves as an example of how vectorization can be useful also in the area of text processing. It takes advantage of the fact that ASCII and Latin-1 were designed to optimize case-twiddling operations.
>> 
>> The code came about during the work on #12632, where vectorization was deemed out of scope.
>> 
>> Benchmark results:
>> 
>> 
>> Benchmark                             (size)  Mode  Cnt     Score   Error  Units
>> EqualsIgnoreCaseBenchmark.scalar          16  avgt   15    20.671 ? 0.718  ns/op
>> EqualsIgnoreCaseBenchmark.scalar          32  avgt   15    46.155 ? 3.258  ns/op
>> EqualsIgnoreCaseBenchmark.scalar          64  avgt   15    68.248 ? 1.767  ns/op
>> EqualsIgnoreCaseBenchmark.scalar         128  avgt   15   148.948 ? 0.890  ns/op
>> EqualsIgnoreCaseBenchmark.scalar        1024  avgt   15  1090.708 ? 7.540  ns/op
>> EqualsIgnoreCaseBenchmark.vectorized      16  avgt   15    21.872 ? 0.232  ns/op
>> EqualsIgnoreCaseBenchmark.vectorized      32  avgt   15    11.378 ? 0.097  ns/op
>> EqualsIgnoreCaseBenchmark.vectorized      64  avgt   15    13.703 ? 0.135  ns/op
>> EqualsIgnoreCaseBenchmark.vectorized     128  avgt   15    21.632 ? 0.735  ns/op
>> EqualsIgnoreCaseBenchmark.vectorized    1024  avgt   15   105.509 ? 7.493  ns/op
>
> Eirik Bjorsnos has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Uppercase Thorn is 0xDE
>  - Update 'a' to 'A' and 'z' to 'Z' in comments

Looks good to me.

-------------

Marked as reviewed by sviswanathan (Reviewer).

PR: https://git.openjdk.org/jdk/pull/12790

From duke at openjdk.org  Tue Feb 28 23:16:06 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Tue, 28 Feb 2023 23:16:06 GMT
Subject: RFR: 8303401: Add a Vector API equalsIgnoreCase micro benchmark
 [v3]
In-Reply-To: <tiCDvotoSiPEZImn6NJs6m8telgjQynnJfKwiH22Gf8=.e37d678b-b189-4b42-8afe-615870b9693b@github.com>
References: <FbxtEB-ECOJ65eF7cdhkISphjqC4Ks1jxYgbML2_xwk=.56cf8152-e227-4412-9e30-0ecb020a65f3@github.com>
 <ZkTx9cf88J3ykf4e6UbrJx97xSfXwsoTqbeU6XIIpcY=.3b663092-7084-42b2-a9fd-a762eb1389b2@github.com>
 <tiCDvotoSiPEZImn6NJs6m8telgjQynnJfKwiH22Gf8=.e37d678b-b189-4b42-8afe-615870b9693b@github.com>
Message-ID: <t-HpSNgzAhOpZSkbVndbUEH5SazTjCqIicXY-aNccyU=.dbf169f4-dfe6-4910-84ad-235f1d161ef1@github.com>

On Tue, 28 Feb 2023 23:11:35 GMT, Sandhya Viswanathan <sviswanathan at openjdk.org> wrote:

>> Eirik Bjorsnos has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Uppercase Thorn is 0xDE
>>  - Update 'a' to 'A' and 'z' to 'Z' in comments
>
> Looks good to me.

Thanks, @sviswa7! Would you sponsor this?

-------------

PR: https://git.openjdk.org/jdk/pull/12790

From psandoz at openjdk.org  Tue Feb 28 23:59:05 2023
From: psandoz at openjdk.org (Paul Sandoz)
Date: Tue, 28 Feb 2023 23:59:05 GMT
Subject: RFR: 8303401: Add a Vector API equalsIgnoreCase micro benchmark
 [v3]
In-Reply-To: <ZkTx9cf88J3ykf4e6UbrJx97xSfXwsoTqbeU6XIIpcY=.3b663092-7084-42b2-a9fd-a762eb1389b2@github.com>
References: <FbxtEB-ECOJ65eF7cdhkISphjqC4Ks1jxYgbML2_xwk=.56cf8152-e227-4412-9e30-0ecb020a65f3@github.com>
 <ZkTx9cf88J3ykf4e6UbrJx97xSfXwsoTqbeU6XIIpcY=.3b663092-7084-42b2-a9fd-a762eb1389b2@github.com>
Message-ID: <9-AO2GbDnVHYorecmrS9E_taG8k1cSDlKh1EkP9pyGI=.ac709e82-647c-4684-915b-fd783441200c@github.com>

On Tue, 28 Feb 2023 23:08:29 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

>> This PR suggests we add a vectorized equalsIgnoreCase benchmark to the set of benchmarks in `org.openjdk.bench.jdk.incubator.vector`. This benchmark serves as an example of how vectorization can be useful also in the area of text processing. It takes advantage of the fact that ASCII and Latin-1 were designed to optimize case-twiddling operations.
>> 
>> The code came about during the work on #12632, where vectorization was deemed out of scope.
>> 
>> Benchmark results:
>> 
>> 
>> Benchmark                             (size)  Mode  Cnt     Score   Error  Units
>> EqualsIgnoreCaseBenchmark.scalar          16  avgt   15    20.671 ? 0.718  ns/op
>> EqualsIgnoreCaseBenchmark.scalar          32  avgt   15    46.155 ? 3.258  ns/op
>> EqualsIgnoreCaseBenchmark.scalar          64  avgt   15    68.248 ? 1.767  ns/op
>> EqualsIgnoreCaseBenchmark.scalar         128  avgt   15   148.948 ? 0.890  ns/op
>> EqualsIgnoreCaseBenchmark.scalar        1024  avgt   15  1090.708 ? 7.540  ns/op
>> EqualsIgnoreCaseBenchmark.vectorized      16  avgt   15    21.872 ? 0.232  ns/op
>> EqualsIgnoreCaseBenchmark.vectorized      32  avgt   15    11.378 ? 0.097  ns/op
>> EqualsIgnoreCaseBenchmark.vectorized      64  avgt   15    13.703 ? 0.135  ns/op
>> EqualsIgnoreCaseBenchmark.vectorized     128  avgt   15    21.632 ? 0.735  ns/op
>> EqualsIgnoreCaseBenchmark.vectorized    1024  avgt   15   105.509 ? 7.493  ns/op
>
> Eirik Bjorsnos has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Uppercase Thorn is 0xDE
>  - Update 'a' to 'A' and 'z' to 'Z' in comments

test/micro/org/openjdk/bench/jdk/incubator/vector/EqualsIgnoreCaseBenchmark.java line 67:

> 65:     public void scalar(Blackhole blackhole) {
> 66:         blackhole.consume(scalarEqualsIgnoreCase(a, b, len));
> 67:     }

If you like there is no need to explicitly use a black hole, instead declare the benchmark method to return `boolean` and return the result of the call. JMH will do the right thing. I find that a little more concise and easier to read.

-------------

PR: https://git.openjdk.org/jdk/pull/12790